(57)【要約】【課題】特別な装置を追加することなく死活監視が可能な画像形成システムを提供する。【解決手段】  画像形成装置２の情報送信部２００は、管理情報４００を送信する。フロントエンドサーバー１ａの管理情報取得部１００は、画像形成装置２から管理情報４００を取得する。バックエンドサーバー１ｂの分析部１１０は、管理情報取得部１００により取得された管理情報４００を分析する。フロントエンドサーバー１ａの間隔指示部１２０は、分析部１１０に対して、特定時間間隔で、メッセージ４１０を蓄積する。死活監視部１３０は、分析部１１０により取得されていないメッセージ４１０の数をカウントして、メッセージ４１０の数が特定の閾値以上になった場合、分析部１１０が稼働していないと判断する。【選択図】図３
2019045965.tif 000002
【特許請求の範囲】
【請求項１】
画像形成装置と、該画像形成装置の管理を行うためのサーバーとを含む画像形成システムであって、
前記画像形成装置は、
前記サーバーへ管理情報を送信する情報送信部を備え、
前記サーバーは、
前記画像形成装置から前記管理情報を取得する管理情報取得部と、
前記管理情報取得部により取得された前記管理情報を分析する分析部と、
前記分析部に対して、特定時間間隔で、取得された場合にその旨を示させる指示を蓄積する間隔指示部と、
前記間隔指示部により蓄積された前記指示のうち、前記分析部により取得されていない前記指示の数をカウントして、前記指示の数が特定の閾値以上になった場合、前記分析部が稼働していないと判断する死活監視部とを備える
ことを特徴とする画像形成システム。
【請求項２】
前記指示は、前記分析部により取得された場合に破棄されるメッセージであり、
前記死活監視部は、前記メッセージの数を、前記指示の数としてカウントする
ことを特徴とする請求項１に記載の画像形成システム。
【請求項３】
前記分析部は、ウェブ用のインターフェイスを備えないでバックエンド処理を行う
ことを特徴とする請求項１又は２に記載の画像形成システム。
【請求項４】
画像形成装置の管理を行うためのサーバーであって、
前記画像形成装置から管理情報を取得する管理情報取得部と、
前記管理情報取得部により取得された前記管理情報を分析する分析部と、
前記分析部に対して、特定時間間隔で、取得された場合にその旨を示させる指示を蓄積する間隔指示部と、
前記間隔指示部により蓄積された前記指示のうち、前記分析部により取得されていない前記指示の数をカウントして、前記指示の数が特定の閾値以上になった場合、前記分析部が稼働していないと判断する死活監視部とを備える
ことを特徴とするサーバー。
【請求項５】
画像形成装置の管理を行うためのサーバーにより実行される画像形成方法であって、前記サーバーは、
前記画像形成装置から管理情報を取得し、
取得された前記管理情報を分析し、
特定時間間隔で、取得された場合にその旨を示させる指示を蓄積し、
蓄積された前記指示のうち、取得されていない前記指示の数をカウントして、前記指示の数が特定の閾値以上になった場合、稼働していないと判断する
ことを特徴とする画像形成方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、画像形成システム、サーバー、及び画像形成方法に係り、特にサーバーの少なくとも一部の死活監視を行う画像形成システム、サーバー、及び画像形成方法に関する。
【背景技術】
【０００２】
従来から、文書や画像を印刷可能な複合機（Multifunctional Peripheral, MFP）等の画像形成装置が存在する。
また、これらの画像形成装置の保守管理を行うサーバーを含む画像形成システムも存在する。この画像形成システムでは、実際に装置やプロセス等が活動（稼働）しているか否かを監視する死活監視を行うことがあった。
【０００３】
ここで、従来の死活監視を行うシステムとして、特許文献１を参照すると、サーバー群に含まれるサーバー各々について、データの送受信が行われているか否かを監視する死活監視サーバーの技術が開示されている。死活監視サーバーは、データの送受信が行われていないとの監視結果が得られた場合に、データの送受信に用いられる第１のネットワークを介して、監視結果が得られたサーバーに死活監視用データを送信する。また、死活監視サーバーは、送信した死活監視用データに対する応答がない場合に、第１のネットワークとは別の第２のネットワークを介して、サーバー群に含まれるサーバー各々に任意の処理を分散させて実行させる分散装置に、応答がなかったサーバーを通知する。
特許文献１の技術によれば、死活監視を確実かつ迅速に実行することができる。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２０１３−１８６４８１号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
しかしながら、特許文献１の技術は、死活監視のために、分散装置のような別の装置が必要となっていた。
【０００６】
本発明は、このような状況に鑑みてなされたものであって、上述の問題点を解消する画像形成システムを提供することを課題とする。
【課題を解決するための手段】
【０００７】
本発明の画像形成システムは、画像形成装置と、該画像形成装置の管理を行うためのサーバーとを含む画像形成システムであって、前記画像形成装置は、前記サーバーへ管理情報を送信する情報送信部を備え、前記サーバーは、前記画像形成装置から前記管理情報を取得する管理情報取得部と、前記管理情報取得部により取得された前記管理情報を分析する分析部と、前記分析部に対して、特定時間間隔で、取得された場合にその旨を示させる指示を蓄積する間隔指示部と、前記間隔指示部により蓄積された前記指示のうち、前記分析部により取得されていない前記指示の数をカウントして、前記指示の数が特定の閾値以上になった場合、前記分析部が稼働していないと判断する死活監視部とを備えることを特徴とする。
本発明の画像形成システムは、前記指示は、前記分析部により取得された場合に破棄されるメッセージであり、前記死活監視部は、前記メッセージの数を、前記指示の数としてカウントすることを特徴とする。
本発明の画像形成システムは、前記分析部は、ウェブ用のインターフェイスを備えないでバックエンド処理を行うことを特徴とする。
本発明のサーバーは、画像形成装置の管理を行うためのサーバーであって、前記画像形成装置から管理情報を取得する管理情報取得部と、前記管理情報取得部により取得された前記管理情報を分析する分析部と、前記分析部に対して、特定時間間隔で、取得された場合にその旨を示させる指示を蓄積する間隔指示部と、前記間隔指示部により蓄積された前記指示のうち、前記分析部により取得されていない前記指示の数をカウントして、前記指示の数が特定の閾値以上になった場合、前記分析部が稼働していないと判断する死活監視部とを備えることを特徴とする。
本発明の画像形成方法は、画像形成装置の管理を行うためのサーバーにより実行される画像形成方法であって、前記サーバーは、前記画像形成装置から管理情報を取得し、取得された前記管理情報を分析し、特定時間間隔で、取得された場合にその旨を示させる指示を蓄積し、蓄積された前記指示のうち、取得されていない前記指示の数をカウントして、前記指示の数が特定の閾値以上になった場合、稼働していないと判断することを特徴とする。
【発明の効果】
【０００８】
本発明によれば、特定時間間隔で、分析部に対して、取得された場合にその旨を示させる指示を蓄積し、取得されていない指示の数をカウントして、分析部が稼働していないと判断することで、別の装置を追加する必要なく、死活監視を行うことが可能な画像形成システムを提供することができる。
【図面の簡単な説明】
【０００９】
【図１】本発明の実施の形態に係る画像形成システムのシステム構成図である。
【図２】図１に示すフロントエンドサーバー及びバックエンドサーバーの制御構成を示すブロック図である。
【図３】本発明の実施の形態に係る画像形成システムの機能構成を示すブロック図である。
【図４】本発明の実施の形態に係る死活監視処理のフローチャートである。
【図５】図４に示す死活監視処理の概念図である。
【発明を実施するための形態】
【００１０】
＜実施の形態＞
〔画像形成システムＸのシステム構成〕
まず、図１を参照して、本発明の実施の形態に係る画像形成システムＸのシステム構成について説明する。
画像形成システムＸは、サーバー１、画像形成装置２−１、……、２−ｎ、及び端末３が、ネットワーク５を介して、接続されて構成される。
また、以下において、画像形成装置２−１、……、２−ｎのいずれかを示す場合、単に「画像形成装置２」と称する。
【００１１】
サーバー１は、遠隔で画像形成装置２の保守管理を行うためのサーバー群である。サーバー１は、ＰＣ（Personal Computer）や汎用機等のサーバーであってもよい。これらのサーバー１は、各画像形成装置２を遠隔管理し、主に課金、保守、サービス対応を行う。また、サーバー１は、いわゆる「クラウド」上のサーバーであってもよい。また、サーバー１は、画像処理、ＯＣＲ（Optical Character Recognition）処理、分類処理、及び、Ｅメールや共有フォルダー（文書ボックス、保存フォルダー）や業務若しくは事務用のＤＭＳ（Document Management System）等への送信処理を実行してもよい。また、サーバー１は、アプリケーションソフトウェア（Application Software、以下、単に「アプリ」という。）を実行することが可能であってもよい。
なお、サーバー１は、イントラネット内のサーバーであってもよい。
【００１２】
また、サーバー群であるサーバー１は、本実施形態においては、フロントエンドサーバー１ａ並びにバックエンドサーバー１ｂを含んでいる。
このうち、フロントエンドサーバー１ａは、保守監視用のＨＴＴＰプロトコルによるＷＷＷ（World Wide Web）等のインターフェイス等により、端末３を介して管理する管理者へのユーザーインターフェイスを提供する「フロントエンド」の処理を実行するサーバーである。
また、バックエンドサーバー１ｂは、監視対象となる画像形成装置２の統計等を行うためのバッチ処理等を行う「バックエンド」のサーバーである。本実施形態において、このバックエンドサーバー１ｂは、後述するように、ＷＷＷ等のインターフェイスを備えていない。また、バックエンドサーバー１ｂは、ＩＰｖ４等のＩＰアドレス等が設定されず、ＴＣＰ／ＩＰの各種プロトコルでアクセスが不可能（エンドポイントなし）であってもよい。このため、バックエンドサーバー１ｂの機能について、実際に稼働しているか否かを監視する死活監視を行う場合に、単にＩＰアドレスを指定したｐｉｎｇやＨＴＴＰプロトコルのｗｇｅｔ等で実行することはできなくてもよい。
なお、以下において、フロントエンドサーバー１ａ及びバックエンドサーバー１ｂのいずれかを示す場合にも、単に「サーバー１」と称する。
【００１３】
画像形成装置２は、顧客環境に設置されたＭＦＰ、ネットワークスキャナー、ドキュメントスキャナー、ネットワークＦＡＸ、スキャナー機能付きのプリンター等のドキュメント機器である。
また、画像形成装置２は、カラー若しくは白黒印刷、ファクシミリ送受信、ネットワークファクシミリ送受信、複写、スキャンによる電子文書化、ネットワークスキャン、電子文書を格納する文書ボックス等の各種の機能を備えていてもよい。また、画像形成装置２は、印刷機能を有するＭＦＰやプリンター等の場合、感光体ドラム、露光部、現像部、転写部、及び定着部等を備えている。これにより、画像形成装置２は、帯電、露光、現像、転写、定着からなる画像形成プロセスを実行することで、記録紙にトナー像を記録し、印刷することが可能である。
また、画像形成装置２は、画像形成システムＸの保守管理対象である。このため、保守管理用の専用のアプリがインストールされてもよい。これにより、画像形成装置２は、管理情報４００（図３）をサーバー１へ送信可能であってもよい。
【００１４】
端末３は、画像形成システムＸの管理者用の端末である。端末３は、ＰＣ、スマートフォン、ＰＤＡ（Personal Data Assistant）、その他の専用端末等であってもよい。端末３は、ＷＷＷブラウザー等を介して、フロントエンドサーバー１ａのＷＷＷ等のインターフェイスにより提供される管理画面等から、画像形成装置２の管理を行う。また、端末３は、このＷＷＷ等のインターフェイスを介して、バックエンドサーバー１ｂによる保守管理の分析結果等を閲覧することも可能である。
【００１５】
ネットワーク５は、ＬＡＮ（Local Area Network）等のイントラネット（Intranet）、インターネットや携帯電話網等のＷＡＮ（Wide Area Network）等のネットワークである。
サーバー１及び各画像形成装置２は、ルーター（Router）やゲートウェイ（Gateway）等を介して、ネットワーク５に接続されていてもよい。また、ネットワーク５は、ＶＰＮ（Virtual Private Network）を構成していてもよい。
【００１６】
次に、図２により、サーバー１の構成について説明する。
サーバー１は、制御部１０、ネットワーク送受信部１５、及び記憶部１９を含んでいる。
【００１７】
制御部１０は、ＧＰＰ（General Purpose Processor）、ＣＰＵ（Central Processing Unit、中央処理装置）、ＭＰＵ（Micro Processing Unit）、ＤＳＰ（Digital Signal Processor）、ＧＰＵ（Graphics Processing Unit）、ＡＳＩＣ（Application Specific Processor、特定用途向けプロセッサー）等の情報処理手段である。
制御部１０は、記憶部１９のＲＯＭやＳＳＤやＨＤＤに記憶されている制御プログラムを読み出して、この制御プログラムをＲＡＭに展開させて実行することで、後述する機能ブロックの各手段として動作させられる。
また、制御部１０は、後述するように、フロントエンドサーバー１ａでは制御部１０ａ（図３）、バックエンドサーバー１ｂでは制御部１０ｂとして構成されていてもよい。
【００１８】
ネットワーク送受信部１５は、ネットワーク５に接続するためのＬＡＮボードや無線送受信機等を含むネットワーク接続手段である。
【００１９】
記憶部１９は、一時的でない記録媒体を用いた記憶手段である。記憶部１９は、主記憶部として、ＲＡＭ（Random Access Memory）等を含んでいてもよい。また、記憶部１９は、補助記憶部として、ＲＯＭ（Read Only Memory）、ｅＭＭＣ（embedded Multi Media Card）、ＳＳＤ（Solid State Drive）等のフラッシュメモリーのストレージ、及びＨＤＤ（Hard Disk Drive）等含んでいてもよい。この場合、記憶部１９の補助記憶部には、サーバー１の動作制御を行うための制御プログラムが記憶されていてもよい。
【００２０】
また、記憶部１９は、サーバー１のフロントエンドサーバー１ａ及びバックエンドサーバー１ｂの間で、ネットワーク５や専用ネットワークを介して共有されたり、相互アクセス可能であったりしてもよい。このため、記憶部１９は、ｉＳＣＳＩで接続されたストレージサーバーやＮＡＳ（Network Attached Storage）等であってもよい。また、記憶部１９の一部のディレクトリ（フォルダー）等のみが、フロントエンドサーバー１ａ及びバックエンドサーバー１ｂの間で共有や相互アクセスされたり、ユーザー単位で共有や相互アクセスされたりしてもよい。
【００２１】
なお、制御部１０は、ＲＡＭやＲＯＭやフラッシュメモリー等を内蔵していてもよい。
【００２２】
〔画像形成システムＸの機能構成〕
ここで、図３を参照し、本発明の実施の形態に係る画像形成システムＸの機能構成について説明する。
フロントエンドサーバー１ａの制御部１０ａは、管理情報取得部１００、間隔指示部１２０、死活監視部１３０、及びインターフェイス部１４０を備えている。
また、記憶部１９は、管理情報ＤＢ３００、キュー３１０、及び分析データ３２０を格納する。
バックエンドサーバー１ｂの制御部１０ｂは、分析部１１０を備えている。
また、画像形成装置２は、情報送信部２００を備えている。
【００２３】
管理情報取得部１００は、画像形成装置２の情報送信部２００から管理情報４００を取得して、管理情報ＤＢ３００に格納する。
【００２４】
分析部１１０は、管理情報取得部１００により取得された管理情報４００を分析する。また、分析部１１０は、ＷＷＷ等のインターフェイスを備えないでバックエンド処理を行う。分析部１１０は、例えば、数時間〜数日毎等の間隔で、バッチ処理により、この分析をバックエンド処理として実行してもよい。また、分析部１１０は、制御部１０ｂのインスタンス、プロセス、タスク、スレッド等として実現されていてもよい。また、分析部１１０は、ＩＰアドレスやエンドポイントを設定されておらず、ＴＣＰ／ＩＰやＨＴＴＰプロトコル等でアクセスできなくてもよい。
また、分析部１１０は、キュー３１０からメッセージ４１０を取得すると、何もせずに破棄（削除、消去）する。つまり、分析部１１０は、メッセージ４１０をトリガーとして、分析等の処理は行わない。しかしながら、本実施形態においては、メッセージ４１０が破棄されて存在しなくなること自体により、分析部１１０が当該メッセージ４１０を取得した「その旨」を、死活監視部１３０に示すことが可能となる。
【００２５】
間隔指示部１２０は、分析部１１０に対して、特定時間間隔で、取得された場合にその旨を示させる指示を蓄積する。また、本実施形態において、この指示は、分析部１１０により取得された場合に破棄されるメッセージ４１０である。また、本実施形態において、間隔指示部１２０は、メッセージ４１０をキュー３１０に蓄積する。このため、間隔指示部１２０は、ＯＳの機能等であるｃｒｏｎやタスクスケジューラー等（以下、単に「スケジューラー」という。）におけるタスクとして設定されていてもよい。また、間隔指示部１２０は、このタスクとして、専用のメッセンジャーのアプリケーションやＦＴＰ（File Transfer Program）やプロセス間通信等でメッセージ４１０を作成して送信し、キュー３１０に蓄積するよう指示してもよい。また、間隔指示部１２０は、特定時間間隔として、例えば、数ミリ秒〜数十秒程度の時間を用いてもよく、一秒〜数秒程度の時間を用いることがより好適である。
【００２６】
死活監視部１３０は、分析部１１０の死活監視を行う。死活監視部１３０は、間隔指示部１２０により蓄積された指示のうち、分析部１１０により取得されていない指示の数をカウントする。本実施形態においては、死活監視部１３０は、キュー３１０に蓄積されたメッセージ４１０の数を、指示の数としてカウントする。また、死活監視部１３０は、メッセージ４１０等の指示の数が特定の閾値以上になった場合、分析部１１０が稼働していない（「死」、ダウン）と判断する。この特定の閾値としては、例えば、特定の時間以内に、二つ以上になった場合等が設定されていてもよい。
なお、死活監視部１３０は、分析部１１０がダウンしていると判断した場合、端末３へ警告（アラート）を報知してもよい。また、この場合、死活監視部１３０は、分析を中止させたり、他の分析部１１０を備えるサーバーに分析を振り分けたりしてもよい。
また、死活監視部１３０は、メッセージ４１０等の指示の数が特定の閾値未満の場合、分析部１１０が稼働している（「活」、アライブ）と判断してもよい。この場合、死活監視部１３０は、分析部１１０へ分析のコマンドで指示を送信することを許可してもよい。
また、死活監視部１３０は、フロントサーバー１ａにおいて、カプセル化されていたり、「ジェイル」化されたり、仮想サーバーの処理部として実現されたりして、外部から実行が停止されにくいように構成されてもよい。
【００２７】
インターフェイス部１４０は、ＨＴＴＰプロトコルを用いて、ＷＷＷにより端末３からアクセスするためのＨＴＭＬ（Hyper Text Makeup Language）や画像データ等を送信するＡｐａｃｈｅ（登録商標）、ＩＩＳ（登録商標）等のＷＷＷサーバープログラムであってもよい。また、インターフェイス部１４０は、ＣＧＩ（Common Gateway Interface）、ＡＳＰ、ＰＨＰ、Ｊａｖａ（登録商標）サーブレット等により、画像形成装置２の保守管理を行うためのウェブアプリケーション（以下、「管理アプリ」という。）を実行することも可能であってもよい。また、この管理アプリ上から、分析データ３２０を、「．ｃｓｖ」やタブ区切り等のデータ列を示す形式のファイルで取得したり、グラフ等で閲覧したりすることも可能であってもよい。
【００２８】
情報送信部２００は、情報送信部２００は、フロントエンドサーバー１ａへ保守管理用の管理情報４００を送信する。
【００２９】
管理情報ＤＢ３００は、管理情報４００を格納するデータベースである。この管理情報ＤＢ３００は、分析部１１０から参照可能である。
【００３０】
キュー３１０は、間隔指示部１２０による指示であるメッセージ４１０を格納するキュー３１０（queue）形式等のバッファーである。キュー３１０は、間隔指示部１２０と、分析部１１０とが共有して、読み込み及び書き込み可能であってもよい。
なお、キュー３１０には、メッセージ４１０の他に、各種ジョブやバックエンドサーバー１ｂへのコマンド等の指示も含まれていてもよい。
【００３１】
分析データ３２０は、分析部１１０により管理情報４００を分析した結果のデータである。分析データ３２０は、例えば、各画像形成装置２の稼働状況、故障状況、保守管理状況、課金状況等を示すデータであってもよい。
【００３２】
管理情報４００は、画像形成装置２から送信される保守管理用の記録データである。管理情報４００は、例えば、画像形成装置２のＩＤ、イベント、当該イベントの発生時刻をログとして含んでいてもよい。
【００３３】
メッセージ４１０は、分析部１１０により取得された場合に破棄される指示のデータである。本実施形態において、メッセージ４１０は、死活監視用のテキストメッセージ４１０等である。また、メッセージ４１０は、例えば、分析部１１０により取得されても何もせずに削除されるような分析部１１０用のコマンド等が含まれていてもよい。
【００３４】
ここで、フロントエンドサーバー１ａの制御部１０ａは、記憶部１９に記憶された制御プログラムを実行することで、管理情報取得部１００、間隔指示部１２０、死活監視部１３０、及びインターフェイス部１４０として機能させられる。
また、バックエンドサーバー１ｂの制御部１０ｂは、図示しない記憶部に記憶された制御プログラムを実行することで、分析部１１０として機能させられる。
また、上述のサーバー１、画像形成装置２の各部は、本発明の画像形成方法を実行するハードウェア資源となる。
また、上述の機能構成の一部又は任意の組み合わせをＩＣやプログラマブルロジック等でハードウェア的に構成してもよい。
【００３５】
〔画像形成システムＸによる死活監視処理〕
次に、図４〜図５を参照して、本発明の実施の形態に係る画像形成システムＸによる死活監視処理の説明を行う。
本実施形態の死活監視処理は、主にサーバー１において、画像形成装置から管理情報４００を取得する。また、取得された管理情報４００を分析する。そして、特定時間間隔で、取得された場合に破棄されるメッセージ４１０をキュー３１０に蓄積する。そして、蓄積されたメッセージ４１０のうち、取得されていないものの数をカウントする。この際、指示の数が、特定の時間以内に二つ以上になった場合、稼働していないと判断する。
本実施形態の死活監視処理は、主にフロントエンドサーバー１ａの制御部１０ａが記憶部１９に記憶されたプログラムを、バックエンドサーバー１ｂの制御部１０ｂが記憶部に記憶された制御プログラムを、各部と協働し、ハードウェア資源を用いて実行する。
以下で、図４のフローチャートを参照して、処理の詳細をステップ毎に説明する。
【００３６】
（ステップＳ１０１）
まず、フロントエンドサーバー１ａの管理情報取得部１００が、管理情報取得処理を行う。
ここでは、まず、イベント等の発生時に、画像形成装置の情報送信部２００が管理情報４００を作成して、ネットワーク５を介して、フロントエンドサーバー１ａへ送信する。
管理情報取得部１００は、この管理情報４００を取得すると、管理情報ＤＢ３００に格納する。この際、管理情報取得部１００は、ログの種類等に対応して、管理情報４００を統計処理しやすいように分類し、格納してもよい。
【００３７】
（ステップＳ２０１）
次に、バックエンドサーバー１ｂの分析部１１０が、分析処理を行う。
分析部１１０は、フロントエンドサーバー１ａの記憶部１９の管理情報ＤＢ３００にアクセスし、管理情報４００を分析する。分析部１１０は、スケジューラーで時間を設定したり、管理情報ＤＢ３００に蓄積された管理情報４００の容量が特定値以上になったことをトリガーとしたりして、蓄積された管理情報４００から統計の処理等をバッチ処理等として実行する。分析部１１０は、この分析の結果を、分析データ３２０としてフロントエンドサーバー１ａの記憶部１９に格納する。
なお、分析部１１０は、フロントエンドサーバー１ａの制御部１０ａによるキュー３１０へのバッチ処理開始のコマンド等の指示により、バッチ処理等を開始してもよい。
【００３８】
（ステップＳ１０２）
次に、フロントエンドサーバー１ａの間隔指示部１２０が、間隔指示処理を行う。
間隔指示部１２０は、特定時間間隔で、取得された場合にその旨を示させる指示を蓄積する。本実施形態においては、死活監視の対象となるのは分析部１１０であるので、分析部１１０宛ての指示をキュー３１０に蓄積する。
図５（ａ）によると、間隔指示部１２０は、スケジューラーとして、特定時間間隔で、キュー３１０に分析部１１０宛てのメッセージ４１０を蓄積する。分析部１１０は、下記で示すように、このメッセージ４１０を取得する。
【００３９】
（ステップＳ２０２）
次に、バックエンドサーバー１ｂの分析部１１０が、指示取得稼働報告処理を行う。
図５（ｂ）によると、分析部１１０は、特定時間間隔でキュー３１０を参照し、メッセージ４１０を取得すると、破棄する。分析部１１０は、特に、このメッセージ４１０をトリガーに分析等の処理は行わない。このように、分析部１１０は、蓄積されたメッセージ４１０を破棄することで、メッセージ４１０が取得された旨を、間接的に死活監視部１３０へ示すことが可能となる。つまり、本実施形態において、分析部１１０は、稼働（アライブ）していることを示すことが可能となる。
【００４０】
（ステップＳ１０３）
次に、死活監視部１３０が、指示カウント処理を行う。
図５（ｃ）によると、監視対象サーバーが何らかの理由でダウンし、メッセージ４１０を取得する処理を行えなくなった場合、キュー３１０にメッセージ４１０が溜まってゆく。
このため、本実施形態において、死活監視部１３０は、間隔指示部１２０により蓄積された指示のうち、分析部１１０により取得されていない指示であるメッセージ４１０の数を数える（カウント）。本実施形態においては、死活監視部１３０は、例えば、特定時間間隔で、キュー３１０に蓄積されたままのメッセージ４１０の数を数える。
なお、死活監視部１３０は、特定時間間隔より、数ミリ秒〜数秒長いような時間間隔で、メッセージ４１０の個数をカウントしてもよい。
【００４１】
（ステップＳ１０４）
次に、死活監視部１３０が、閾値以上か否かを判断する。死活監視部１３０は、指示の数が特定の閾値以上になった場合、Ｙｅｓと判断する。図５（ｃ）の例では、死活監視部１３０は、メッセージ４１０が特定の時間以内に二つ以上、キュー３１０に蓄積されている場合に、Ｙｅｓと判断する。死活監視部１３０は、それ以外の場合には、Ｎｏと判断する。
Ｙｅｓの場合、死活監視部１３０は、処理をステップＳ１０５に進める。
Ｎｏの場合、死活監視部１３０は、処理をステップＳ１０６に進める。
【００４２】
（ステップＳ１０５）
メッセージ４１０が閾値以上蓄積されていた場合、死活監視部１３０が、非稼働判断処理を行う。
死活監視部１３０は、分析部１１０がダウンしているとして、端末３に対してアラートを報知する。死活監視部１３０は、この報知を、電子メールやチャットやメッセンジャー等で行ってもよい。また、死活監視部１３０は、ＳＭＳやチャット等で、管理者に直接、アラートの連絡を送信してもよい。このアラートを受信した管理者は、分析部１１０のダウンの原因を判断して、端末３から、バックエンドサーバー１ｂを再起動させる等して復旧させてもよい。
また、死活監視部１３０は、分析部１１０による分析を中止させたり、他の分析部１１０を備えるサーバーに分析を振り分けたりしてもよい。
その後、死活監視部１３０は、本実施形態に係る死活監視処理を終了する。
【００４３】
（ステップＳ１０６）
メッセージ４１０が閾値以上蓄積されていなかった場合、死活監視部１３０が、稼働判断処理を行う。
また、死活監視部１３０は、分析部１１０がアライブとして、分析部１１０へ分析のコマンドで指示を送信することを許可してもよい。この場合、死活監視部１３０は、バッチ処理の時刻を設定し、キュー３１０へのバッチ処理のコマンドを送信してもよい。
以上により、本発明の実施の形態に係る死活監視処理を終了する。
【００４４】
以上のように構成することで、以下のような効果を得ることができる。
従来、特許文献１のような技術では、死活監視のために、分散装置のような別の装置が必要となっていた。
これに対して、本発明の実施の形態に係る画像形成システムＸは、画像形成装置２と、画像形成装置２の管理を行うためのサーバー１ａ、１ｂとを含む画像形成システムである。画像形成装置２は、サーバーへ管理情報４００を送信する情報送信部２００を備える。また、サーバー１ａは、管理情報取得部１００と、間隔指示部１２０と、死活監視部１３０とを備える。サーバー１ｂは、分析部１１０を備える。管理情報取得部１００は、画像形成装置２から管理情報４００を取得する。分析部１１０は、管理情報取得部１００により取得された管理情報４００を分析する。間隔指示部１２０は、分析部１１０に対して、特定時間間隔で、取得された場合にその旨を示させる指示を蓄積する。死活監視部１３０は、間隔指示部１２０により蓄積された指示のうち、分析部１１０により取得されていない指示の数をカウントして、指示の数が特定の閾値以上になった場合、分析部１１０が稼働していないと判断する。
このように構成することで、分散装置のような別の装置がなくても、分析部１１０の死活監視を容易に行うことが可能となる。
【００４５】
また、従来は、バックエンド処理を行うサーバー等に監視用のエージェントをインストールし、そのエージェントにてサーバーの状態を定期的に死活監視する方式があった。
このような方式では、別途エージェントをバックエンド処理を行うサーバー等にインストールする必要があり、エージェントをインストールできない環境では、死活監視を行うことができなかった。また、このようなエージェントにより死活監視を行わせると、サーバーの処理時間や記憶容量等のリソースを大きく消費していた。
これに対して、本発明の実施の形態に係る画像形成システムＸは、分析部１１０の死活監視を、別途、バックエンドサーバー１ｂ等にエージェントをインストールをせずに実現することが可能となる。また、例えば、間隔指示部１２０として、スケジューラーによるタスク等を設定し、指示を蓄積させるだけで、死活監視を実現することが可能となる。
【００４６】
また、従来、分析データ３２０のようなデータの蓄積が行われているか否かを監視して死活監視を行うことも考えられていた。
しかしながら、このようにデータの蓄積が行われているかどうかは、分析ファイル等が開かれ、書き込まれている途中では、正確に判断できないことがあった。また、リアルタイム（即時的）に分析部１１０の停止を知ることはできなかった。
これに対して、本発明の実施の形態に係る画像形成システムＸは、指示は、分析部１１０により取得された場合に破棄されるメッセージ４１０であり、死活監視部１３０は、メッセージ４１０の数を、指示の数としてカウントすることを特徴とする。
このように構成し、監視対象の分析部１１０と死活監視部１３０とが共通で参照するキュー３１０にメッセージ４１０を蓄積し、キュー３１０のメッセージ４１０の数が閾値以上に達した場合に、監視対象の分析部１１０が何らかの問題が発生してダウンしていると判断する。これにより、メッセージ４１０の数を数えるだけで、容易に死活監視を実現することが可能となる。
【００４７】
また、従来、サーバーの死活監視の方法としては、ＨＴＴＰプロトコル等でアクセス可能なネットワーク接続された、エンドポイントを備える装置に対して、一定間隔で、ｐｉｎｇを行ったり、ｗｇｅｔ等でアライブであるか否かを判断したりする方式があった。しかしながら、このような方式では、ＴＣＰ／ＩＰ及びＨＴＴＰプロトコルでアクセス可能な装置しか監視することはできなかった。
これに対して、本発明の実施の形態に係る画像形成システムＸは、分析部１１０は、ＷＷＷ等のウェブ用のインターフェイスを備えないでバックエンド処理を行うことを特徴とする。
このように構成することで、エンドポイントを備えなかったり、ウェブ用のインターフェイスを持なかったり、ｐｉｎｇをブロックして応答しなかったり、ｗｇｅｔ等で死活監視を行うことができなかったりするような分析部１１０についても、容易に死活監視が可能となる。
【００４８】
〔他の実施の形態〕
なお、上述の実施の形態においては、「取得された場合にその旨を示させる指示」として、メッセージ４１０を蓄積する例について示した。
しかしながら、分析部１１０は、「その旨」として、データ自体を書き込んだり、変更したり、取得（参照）したことをタイムスタンプ等で認識可能にしたりするような他の手段により、メッセージ４１０等を加工して示してもよい。
また、メッセージ４１０の代わりに、分析部１１０に取得された場合にその旨を示させる指示として、電子メール、チャットデータ、特定名のファイル、ロックファイル、スタック用データ、ビット列、フラグ等（以下、「メール等」という。）を用いてもよい。
このようにメール等を用いる場合、分析部１１０は、メール等もメッセージ４１０と同様に破棄してもよい。また、死活監視部１３０は、上述のメール等を用いている場合、これの数をカウントしてもよい。
また、「その旨」を示す手段として、他の手段を用いている場合には、分析部１１０は、他の手段によりメッセージ４１０やメール等を加工してもよい。この場合、死活監視部１３０は、各指示について、他の手段により示された数を数えてもよい。
このように構成することで、メッセージ４１０を蓄積できないような環境であっても、サーバーの死活監視を行うことが可能になり、柔軟な構成に対応できる。
【００４９】
また、上述の実施の形態に係るサーバー１における、フロントエンドサーバー１ａ及びバックエンドサーバー１ｂの構成は一例である。つまり、サーバー１のうち、任意のサーバー群で構成可能である。たとえば、サーバー１のフロントエンドサーバー１ａ及びバックエンドサーバー１ｂは、単一のサーバーであってもよく、サーバー内の仮想マシンや論理若しくは物理ＣＰＵ等で区別されて構成されていてもよい。また、フロントエンドサーバー１ａ及びバックエンドサーバー１ｂ以外のサーバーを備えていてもよく、処理の軽重に応じて複数のサーバーの台数を可変にして用いてもよい。また、フロントエンドサーバー１ａ及びバックエンドサーバー１ｂの間は、専用の高速ネットワークで接続されていてもよい。また、後述するスケジューリング、死活監視、データベース等の機能部用に、それぞれ専用のサーバーを用意してもよい。また、死活監視として、バックエンドサーバー１ｂの分析部１１０ではなく、他のサーバーについて行ってもよい。
また、上述の各機能部も、フロントエンドサーバー１ａ及びバックエンドサーバー１ｂのいずれに含まれていても、複数含まれていても、機能部の一部がなくてもよい。
【００５０】
また、本発明は、画像形成装置以外の情報処理装置の管理にも適用できる。たとえば、ネットワークスキャナー、スキャナーをＵＳＢ等で別途接続したサーバー等を用いる構成であってもよい。
【００５１】
また、上記実施の形態の構成及び動作は例であって、本発明の趣旨を逸脱しない範囲で適宜変更して実行することができることは言うまでもない。
【符号の説明】
【００５２】
１  サーバー
１ａ  フロントエンドサーバー
１ｂ  バックエンドサーバー
２  画像形成装置
３  端末
５  ネットワーク
１０、１０ａ、１０ｂ  制御部
１５  ネットワーク送受信部
１９  記憶部
１００  管理情報取得部
１１０  分析部
１２０  間隔指示部
１３０  死活監視部
１４０  インターフェイス部
２００  情報送信部
３００  管理情報ＤＢ
３１０  キュー
３２０  分析データ
４００  管理情報
４１０  メッセージ
【図１】
2019045965.tif 000003
【図２】
2019045965.tif 000004
【図３】
2019045965.tif 000005
【図４】
2019045965.tif 000006
【図５】
2019045965.tif 000007