JP2004220214A - 管理装置 - Google Patents

Abstract

【課題】複数台の監視対象装置に対して監視を行う監視装置における処理負荷を軽減した遠隔監視システムを提供する。
【解決手段】周辺機器３〜５のメンテナンス情報をそれぞれ収集する複数の監視装置（１）と、該監視装置（１）に通信回線８を介して接続され、該複数の監視装置（１）を一元的に管理する管理サーバ６とからなる遠隔監視システムにおいて、監視装置（１）の各々が、前記収集されたメンテナンス情報及び自装置の識別情報を含む電子メールを定期的に管理サーバ６へ送信する。この電子メールを受信した管理サーバ６が、該電子メールに含まれるメンテナンス情報を抽出する。また、監視装置ごとに電子メールの受信情報を記録するデータベースにおける、前記送信された電子メールに含まれる識別情報が表す監視装置に対応する受信情報を更新し、前記データベースを参照して異常な監視装置を検出する。
【選択図】 図１

Description

【０００１】
【発明の属する技術分野】
本発明は、管理装置に関し、特に、複数の監視装置を一元的に管理する管理サーバと通信可能な、複数の周辺機器の少なくともカウンタを含むメンテナンス情報を管理する管理装置に関する。
【０００２】
【従来の技術】
従来、画像形成装置のような事務機器を含む各種コンピュータ機器を遠隔監視する方法として、コンピュータ機器が接続されたネットワーク内に監視装置を設置し、該監視装置によってネットワークを介してコンピュータ機器を監視し、該監視装置から管理サーバへ監視結果情報を転送する技術が知られている。
【０００３】
また、ユーザ拠点側にて利用されている端末装置へ管理サーバから応答の要求を行い、該端末装置から応答を受けることによって管理サーバが、端末装置自体または端末装置における電話回線への発信機能が正常であると確認する技術が知られている（例えば、特許文献１参照）。
【０００４】
【特許文献１】
特開平０４−０５６５６０号公報
【０００５】
【発明が解決しようとする課題】
しかしながら、上記の特許文献１に記載の従来の技術において、管理サーバは、応答要求の送信とその応答の受信の２回の情報転送が必要であり、しかも、監視対象装置（端末装置）が複数存在する場合、管理サーバは、その２回の情報転送をその台数分行う必要がある。
【０００６】
また複数台の監視対象装置（端末装置）に対して管理サーバが応答要求を送信する際、それを一斉に行うか、または時差送信を行うが、いずれの場合でも、管理サーバでは、監視対象装置（端末装置）ごとに、応答があったか否かを判定する必要がある。
【０００７】
このように、複数台の監視対象装置（端末装置）に対して監視を行う管理サーバにおける処理の負荷が非常に高いという問題があった。
【０００８】
本発明はこのような問題点に鑑みてなされたものであって、複数台の監視対象装置に対して監視を行う監視装置における処理負荷を軽減した遠隔監視システムを提供することを目的とする。
【０００９】
【課題を解決するための手段】
上記目的を達成するために、本発明によれば、複数の監視装置を一元的に管理する管理サーバと通信可能な、複数の周辺機器の少なくともカウンタを含むメンテナンス情報を管理する管理装置であって、前記周辺機器のメンテナンス情報を管理する管理手段と、定期的に前記管理サーバへ識別ＩＤを含む確認情報を通知するようにする通信制御手段とを有し、前記通信制御手段は、前記管理手段により管理されるメンテナンス情報を前記管理サーバに通知し、前記管理サーバでは前記通信制御手段による通知の通知履歴に基づく監視対象管理情報を作成することを特徴とする管理装置が提供される。
【００１０】
【発明の実施の形態】
以下、本発明の実施の形態を、図面を参照して説明する。
【００１１】
［第１の実施の形態］
図１は、本発明に係る管理装置を含む遠隔監視システムの第１の実施の形態の全体構成を示す図である。
【００１２】
本遠隔監視システムでは、センタ側管理サーバ６及び拠点側管理サーバ２が、一般的な情報処理装置によってそれぞれ構成され、インターネット等の通信回線８を介し、所定のプロトコル１０によって互いに通信可能である。拠点側管理サーバ２及びセンタ側管理サーバ６は、例えばメールサーバやルータの機能を掌る部分として想定することができる。
【００１３】
センタ側管理サーバ６と拠点側管理サーバ２とは、通信回線８を介して、所定のプロトコル１０で接続されるが、不正アクセスを防ぐために、またファイアウォールを越すために、一般的なプロトコル（ＳＭＴＰ）や認証も設けるようにする。
【００１４】
監視装置１が、ネットワーク９を介して画像形成装置３〜５及びパーソナルコンピュータ（以下「ＰＣ」という）１２に接続され、画像形成装置３〜５及びＰＣ１２の稼動情報や障害情報（詳しくは後述）を収集すると共に、画像形成装置３〜５及びＰＣ１２の制御プログラムなどを更新する機能を備え、更に、収集した情報を、拠点側管理サーバ２を介してセンタ側管理サーバ６に転送する機能を備える。
【００１５】
パーソナルコンピュータ（以下「ＰＣ」という）７がネットワークを介してセンタ側管理サーバ６に接続され、センタ側管理サーバ６のクライアントコンピュータとして動作する。ＰＣ７は各種情報処理を実行するとともに、センタ側管理サーバ６で収集された情報を共有することができる。
【００１６】
なお図１では、監視装置１と拠点側管理サーバ２とが別体として設置され、またＰＣ７とセンタ側管理サーバ６とが別体として設置されているが、監視装置１と拠点側管理サーバ２とを１つの装置にし、またＰＣ７とセンタ側管理サーバ６とを１つの装置にしてもよい。これを、図１中において点線枠にて示す。
【００１７】
なおまた、図１中には、監視装置１を１つしか図示しないが、実際には、複数の監視装置がネットワーク９に接続されるとともに、各監視装置によってそれぞれ監視される画像形成装置及びＰＣがネットワーク９に接続され、センタ側管理サーバ６が、それら複数の監視装置を一元的に管理する。複数の監視装置の各々が後述する各種処理／制御を実現する。
【００１８】
画像形成装置３〜５は、具体的にはプリンタ（電子写真方式及びインクジェット方式を含む）、ファクシミリ装置、スキャナ、プリンタ及びファクシミリ機能が統合的に設けられたデジタル複合機、プリントサーバなどのうちのいずれかである。
【００１９】
ＰＣ１２は、例えば、所定のアプリケーションデータをＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）、プリンタドライバを介してＰＤＬ（Ｐａｇｅ Ｄｅｓｃｒｉｐｔｉｏｎ Ｌａｎｇｕａｇｅ）データに変換し、該ＰＤＬデータを画像形成装置３〜５のいずれかに送信する機能を備える。
【００２０】
なお、監視装置１は、画像形成装置３〜５及びＰＣ１２からメンテナンス情報を収集する。メンテナンス情報は、稼動情報に少なくとも障害情報を含むものであり、稼動情報は、画像形成装置３〜５では、それら装置の状態、トナー残量、用紙サイズ毎の印刷枚数等であり、ＰＣ１２では、ＰＣ１２内のＣＰＵ及びメモリの稼動状況、有料アプリケーション使用状況等である。障害情報は、画像形成装置３〜５でのジャム情報やＰＣ１２での再起動回数情報等である。こうしたメンテナンス情報の定義は、後述の第２及び第３の実施の形態でも適用される。
【００２１】
図２は、監視装置１のハードウェア構成を示すブロック図である。監視装置１は、一般な情報処理装置が備える構成に加えて、複数の各種用途のインターフェイスを備えている。
【００２２】
図中、ＣＰＵ２０１は、監視装置１内の各構成部品を個別に及び／又は統合的に制御する。バス２０２では、監視装置１内の各構成部品間のデータの受け渡しが行われる。ＲＡＭ２０３は、電気的に情報を記憶でき、かつ書き換え可能なメモリである。フラッシュＲＯＭ（ＦｌａｓｈＲＯＭ）２０４は、電気的に書き換え可能であり、かつ電源がオフされても情報を記憶可能な不揮発性メモリである。ネットワークインターフェイス（ＮｅｔｗｏｒｋＩ／Ｆ）２０５，２０６は、ネットワーク９経由で外部と情報交換を行うインターフェイスである。シリアルインターフェイス（ＳｅｒｉａｌＩ／Ｆ）２０７は、ＲＳ２３２Ｃシリアル通信にて情報交換を行うインターフェイスである。デバッグインターフェイス（ＤｅｂｕｇＩ／Ｆ）２０８は、デバッグ用途に用いるシリアル通信部である。
【００２３】
なお、この監視装置１に、キーボード等の入力装置、表示部、表示制御部などを備えるようにしてもよいが、ネットワークインターフェイス（ＮｅｔｗｏｒｋＩ／Ｆ）２０５，２０６に、例えばサービスマンのＰＣを接続し、このＰＣによって監視装置１内の設定プログラムを起動することで、監視装置１の設定変更を行なうことができる。そのため、入力装置、表示部、表示部駆動部などを必ずしも備える必要がなく、これらを備えないことで、安価に装置を構築可能となる。
【００２４】
また、拠点側管理サーバ２、ＰＣ１２、センタ側管理サーバ６、ＰＣ７はそれぞれ、一般的な情報処理装置が備える構成を備えていればよいので、それらのハードウェア構成の詳しい説明は省略する。
【００２５】
次に、図３及び図４を参照して、画像形成装置３〜５及びＰＣ１２に対して監視装置１によって行われる障害監視について説明する。
【００２６】
図３は、監視装置１において実行される障害情報確認プログラムの処理手順を示すフローチャートである。なおここで、監視装置１から拠点側管理サーバ２、センタ側管理サーバ６、ＰＣ７への情報送信はＳＭＴＰ（Ｓｉｍｐｌｅ Ｍａｉｌ ＴｒａｎｓｆｅｒＰｒｏｔｏｃｏｌ）で行い、それらからの情報受信はＰＯＰ（Ｐｏｓｔ Ｏｆｆｉｃｅ Ｐｒｏｔｏｃｏｌ）で行うものとする。
【００２７】
ステップＳ３０１で、監視装置１が、画像形成装置３〜５やＰＣ１２から障害情報の取得を、ネットワーク９を介して特定のプロトコルにより試みる。
【００２８】
ステップＳ３０２で、ステップＳ３０１における試みの結果、障害情報を取得できたか否かを判断する。取得できた場合、ステップＳ３０３に進んで、取得した障害情報を拠点側管理サーバ２またはセンタ側管理サーバ６に送信する。取得できない場合、ステップＳ３０５に進む。
【００２９】
ステップＳ３０４では、障害情報が拠点側管理サーバ２またはセンタ側管理サーバ６に正しく送信されたことを確認するために、応答確認プログラム（図４を参照して後述）を起動する。
【００３０】
ステップＳ３０５で、所定時間（例えば１分）待機する。
【００３１】
ステップＳ３０６で、所定時間の待機中に障害情報確認プログラム処理への終了指示があったか否かを判断し、指示があった場合は本プログラム処理を終了し、指示がない場合は、ステップＳ３０１に戻り、本プログラム処理を再度実行する。
【００３２】
図４は、監視装置１において実行される応答確認プログラムの処理手順を示すフローチャートである。このプログラムは、前述のように図３のステップＳ３０４によって起動される。
【００３３】
ステップＳ３０７で、監視装置１が所定時間（例えば３０秒）待機する。
【００３４】
ステップＳ３０８で、拠点側管理サーバ２またはセンタ側管理サーバ６から応答が返信されたことをチェックする。
【００３５】
ステップＳ３０９で、ステップＳ３０８でのチェックの結果、拠点側管理サーバ２またはセンタ側管理サーバ６から応答が返信されていれば本プログラム処理を終了する。応答が返信されていなければステップＳ３１０へ進み、所定の応答確認最大時間（例えば３０分）が経過したか否かを判断する。経過していなければステップＳ３０７へ戻って引き続き、応答返信チェックを行う。経過していればステップＳ３１１へ進む。
【００３６】
ステップＳ３１１では、今までに障害情報を送信した回数が所定回数（例えば１回）以下であるか否かを判断する。所定回数以下である場合、すなわち例えば、今回はじめて障害情報を送信した場合はステップＳ３１２に進んで、障害情報を拠点側管理サーバ２またはセンタ側管理サーバ６に再度送信し、ステップＳ３０７に戻る。障害情報送信回数が所定回数を超えている場合は、本プログラム処理を終了する。
【００３７】
次に、図５及び図６を参照して、監視装置１によって行われるカウンタ情報の収集処理について説明する。カウンタ情報は、画像形成装置３〜５及びＰＣ１２に関する前述の稼動情報であり、この収集処理はカウンタ情報取得プログラムとカウンタ情報送信プログラムによって行われる。
【００３８】
図５は、監視装置１において実行されるカウンタ情報取得プログラムの処理手順を示すフローチャートである。この処理は、画像形成装置３〜５及びＰＣ１２の各々に対して実行される。
【００３９】
ステップＳ４０１で、監視装置１が、画像形成装置３〜５及びＰＣ１２のカウンタ情報を、ネットワーク９を介して特定のプロトコルにより取得する。
【００４０】
ステップＳ４０２で、監視装置１が、画像形成装置３〜５及びＰＣ１２から取得したカウンタ情報を記憶部（ＲＡＭ２０３）に保存する。なお、監視装置１が画像形成装置３〜５及びＰＣ１２から取得するデータ形式と、拠点側管理サーバ２またはセンタ側管理サーバ６へ送信するデータ形式とが異なる場合には、この保存時点でデータ変換しておいてもよい。また、拠点側管理サーバ２またはセンタ側管理サーバ６からカウンタ情報の送信要求があった時点で、このデータ変換を行なうようにしてもよい。
【００４１】
ステップＳ４０３で、監視装置１は所定時間（例えば６０分）待機する。
【００４２】
ステップＳ４０４で、この所定時間の待機中に本カウンタ情報取得プログラムへの終了指示があったか否かを判断する。終了指示があった場合は本プログラム処理を終了し、終了指示がなければステップＳ４０１に戻り、本プログラム処理を再度行う。
【００４３】
図６は、監視装置１において実行されるカウンタ情報送信プログラムの処理手順を示すフローチャートである。
【００４４】
ステップＳ４０５で、監視装置１がＰＯＰサーバに対して、拠点側管理サーバ２またはセンタ側管理サーバ６からカウンタ情報送信要求メールが送られているか否かを問い合わせる。
【００４５】
ステップＳ４０６で、この問い合わせの結果、カウンタ情報送信要求メールが送られていると判断した場合は、ステップＳ４０７へ進む。カウンタ情報送信要求メールが送られていないと判断した場合は、ステップＳ４１０へ進む。
【００４６】
ステップＳ４０７では、カウンタ情報が記憶部（ＲＡＭ２０３）に保存されているか否かを判断する。保存されている場合はステップＳ４０８に進み、保存されているカウンタ情報を拠点側管理サーバ２またはセンタ側管理サーバ６に送信する。センタ側管理サーバ６に送信されたカウンタ情報は、前述したようにＰＣ７において共有され、例えばオペレータにより参照され得る。
【００４７】
ステップＳ４０７で、カウンタ情報が記憶部（ＲＡＭ２０３）に保存されていないと判断された場合は、ステップＳ４０９に進んで、カウンタ情報が未収集であるという情報を拠点側管理サーバ２またはセンタ側管理サーバ６に送信する。
【００４８】
ステップＳ４１０で、監視装置１は所定時間（例えば３分）待機する。
【００４９】
ステップＳ４１１で、所定時間の待機中に本カウンタ情報送信プログラムの終了を指示されたか否かを判断し、終了を指示された場合は、本プログラム処理を終了する。そうでない場合は、ステップＳ４０５に戻り、本プログラム処理を再度行う。
【００５０】
なお、ステップＳ４０６で、カウンタ情報送信要求メールが送られていないと判断された場合は、ステップＳ４１０、Ｓ４１１へ進み、プログラム終了が指示されたと判断されるまで、ステップＳ４０５〜Ｓ４１０の処理を繰り返し実行する。
【００５１】
以上のように、図３〜図６に示す各処理が実行されることにより、ユーザ先にて利用される画像形成装置やＰＣなどのメンテナンス情報がセンタ側管理サーバ６またはＰＣ７において遠隔にて一元的に集中管理されることになる。
【００５２】
次に、図７を参照して、画像形成装置３、４、５を制御する各コントローラについて説明する。各コントローラは同一の構成であるので、１つだけを説明する。
【００５３】
図７は、画像形成装置３〜５の１つを制御するコントローラの構成を示すブロック図である。
【００５４】
コントローラは、図７に示すように、ＣＰＵ回路部３０７を有し、ＣＰＵ回路部３０７は、ＣＰＵ（図示せず）、ＲＯＭ３０８、ＲＡＭ３０９、ハードディスク装置（ＨＤＤ）３１０を備え、ＲＯＭ３０８に格納されている制御プログラムにより後述の各構成部３０２、３０３、３０４、３０５、３０６、３１１、３１２、３１３、３１４、３１５を総括的に制御する。ＲＡＭ３０９は、制御データを一時的に保持し、またＣＰＵによる演算処理の作業領域として用いられる。ハードディスク装置３１０は、制御にプログラムに必要な情報や各構成部３０２、３０３、３０４、３０５、３０６、３１１、３１２、３１３、３１４、３１５から受信した情報を記憶する。
【００５５】
原稿給送装置制御部３０２は、原稿給送装置（図示せず）をＣＰＵ回路部３０７からの指示に基づき駆動制御する。イメージリーダ制御部３０３は、スキャナユニット（図示せず）、イメージセンサ（図示せず）などに対して駆動制御を行い、イメージセンサから出力されたアナログ画像信号を画像信号制御部３０４に転送する。
【００５６】
画像信号制御部３０４は、転送されたアナログ画像信号をデジタル信号に変換し、このデジタル信号に対して各種画像処理を施す。その後、このデジタル信号をビデオ信号に変換してプリンタ制御部３０５に出力する。画像信号制御部３０４の処理動作は、ＣＰＵ回路部３０７により制御される。
【００５７】
外部Ｉ／Ｆ３０６は、ネットワーク９を介してＰＣ１２から入力されたデジタル画像信号に各種処理を施し、このデジタル画像信号をビデオ信号に変換してプリンタ制御部３０５に出力する。また、外部Ｉ／Ｆ３０６はネットワーク９を介して図示しないデバイス管理装置と通信を行う。
【００５８】
プリンタ制御部３０５は、上述のように画像信号制御部３０４または外部Ｉ／Ｆ３０６から入力されたビデオ信号に基づき、露光制御部（図示せず）を駆動する。
【００５９】
操作部３１１は、画像形成に関する各種機能を設定する複数のキーなどを有し、各キーの操作に対応したキー信号をＣＰＵ回路部３０７に出力する。表示部３１２は、操作部３１１による設定状態を表示するとともに、ＣＰＵ回路部３０７からの信号に基づき対応する情報を表示する。
【００６０】
ソータ制御部３１３及びフィニッシャ制御部３１４は、外部Ｉ／Ｆ３０６を経由したユーザからの入力または操作部３１１からの設定に基づいてＣＰＵ回路部３０７から出力される信号に従って動作する。状態検知部３１５は、各構成部からの状態情報を収集し、異常検知等の判断を行い、判断結果をＣＰＵ回路部３０７に通知する。この通知に基づき、ＣＰＵ回路部３０７は表示部３１２に異常を表示したり、外部Ｉ／Ｆ３０６を経由してＰＣ１２等へ異常を通知する。
【００６１】
図８は、画像形成装置のソフトウェア（タスク）構成を示す図である。
【００６２】
タスクマネージャＡ−１０１は、複数のタスクを同時に管理するためのものである。紙搬送部タスク群Ａ−１０２は、原稿および画像形成されるシートの搬送を司るタスク群である。シーケンス制御タスクＡ−１０３は、画像形成装置全体の管理を行うタスクである。通信タスクＡ−１０４は、デバイス管理装置と通信を行うためのタスクである。管理用データ作成タスクＡ−１０５は、本実施の形態に係る遠隔管理用データを作成するためタスクである。
【００６３】
また画像形成装置では、画像形成ごとに用紙サイズ別、モード別、紙種別、カラー別の稼動情報のカウントを行っている。これらのカウントは管理用データ作成タスクＡ−１０５にて行われ、画像形成装置内の記憶部（ＲＡＭ３０９等）に格納される。
【００６４】
同様に、管理用データ作成タスクＡ−１０５によって、ジャム、エラー、アラームなどのステータス情報（障害情報）が所定のデータフォーマットで画像形成装置内の記憶部に格納される。
【００６５】
さらに、画像形成装置内の各構成部ごとに構成消耗部品の交換寿命情報と、使用度数を表すカウンタ値とを持っており、管理用データ作成タスクＡ−１０５によって、それらが画像形成装置の記憶部に格納される。
【００６６】
状態監視タスクＡ−１０６は、画像形成装置内の異常（ジャム、エラー、アラーム）を検知したり、予め設定された各構成部のステータス変化を検知したりする。そして、こうした検知結果を、管理用データ作成タスクＡ−１０５を介して画像形成装置の記憶部に格納する。
【００６７】
これら記憶部に格納された情報は、所定のタイミングや監視装置１からの情報の要求に応じて監視装置１に通知される。
【００６８】
図９は、図１における監視装置１及びセンタ側管理サーバ６の内部機能構成を示すブロック図である。なお、センタ側管理サーバ６をＰＣ７に読み替えたり、またはセンタ側管理サーバ６とＰＣ７との一体装置に読み替えたりしてもよい。さらに、監視装置１を、拠点側管理サーバ２に読み替えたり、または監視装置１と拠点側管理サーバ２との一体装置に読み替えたりしてもよい。
【００６９】
監視装置１は、外部との通信を行うための通信処理部６０２、メールを送信するメール通信部６０３、監視装置１内のプログラムのタスク管理を行うタイマ処理部６０４、定期的にメールを作成して定期通信作成部６０５にメール送信を行わせる定期通信作成部６０５、メール作成に必要な情報であるメール作成情報６０６から構成される。
【００７０】
センタ側管理サーバ６は、外部と通信するための通信処理部６０８、メールを受信して定期通信メール解析部６１０に転送するメール処理部６０９、受信メールを解析する定期通信メール解析部６１０、メール解析で得られた情報を保存するためのデータベース６１１、センタ側管理サーバ６内のプログラムのタスク管理を行うタイマ処理部６１２、後述する定期通信管理部６１３で行うべき処理内容を示す処理設定情報６１４、通知メールを作成する通知メール作成部６１５、通知メール作成部６１５でのメール作成に必要な情報であるメール作成情報６１６から構成される。定期通信管理部６１３は、データベース６１１を定期的に監視して、処理設定情報６１４が示す処理内容に従って処理を行い、その結果に従って、通知メール作成部６１５に通知メールの作成を依頼する。
【００７１】
図１０は、図９のメール作成情報６０６の一例を示す図である。
【００７２】
メール作成情報６０６は、少なくともメール宛先アドレス７０１、メール発信元アドレス７０２、サブジェクト内容７０３から構成される。なお、メール送受信処理に関わる情報、例えばＳＭＴＰサーバのアドレス、ＰＯＰサーバのアドレス、各サーバへの認証情報等はメール処理部６０３で保持されており、メール作成情報６０６には含まれない。また通信処理部６０２では、自分のＩＰアドレスとネットマスク、外部と通信するためのゲートウェイアドレスを持っており、外部との通信処理のための情報もメール作成情報６０６には含まれない。
【００７３】
図１１は、図９のメール作成情報６１５の一例を示す図である。
【００７４】
メール作成情報６１５は、メールの宛先アドレス８０１、メール発信元のアドレス８０２、本メールが異常のある監視装置の一覧を送信するためのメールであることを示すサブジェクト内容８０３、メール内容のテンプレート８０４をもつ。
【００７５】
図１２は、監視装置１からセンタ側管理サーバ６へ送信されるメールの内容の一例を示す図である。
【００７６】
監視装置１からのメールには、宛先アドレス９０３、送信元アドレス９０２、サブジェクト９０４のほか、送信時刻９０１と、送信元情報９０５〜９０９とが付加される。
【００７７】
図１３は、センタ側管理サーバ６から予め設定された宛先に送信されるメールの内容の一例を示す図である。
【００７８】
センタ側管理サーバ６からのメールには、宛先アドレス１００３、送信元アドレス１００２、サブジェクト１００４のほか、メール内容のテンプレート８０４から作成された詳細内容１０１０が、送信時刻１００１と送信元情報１００５〜１００９とともに付加される。
【００７９】
次に、図１４〜図１６を参照して、監視装置１及びセンタ側管理サーバ６の処理動作を説明する。
【００８０】
図１４は、監視装置１において実行される定期メール送信処理の手順を示すフローチャートである。
【００８１】
監視装置１は、複数の画像形成装置３〜５やＰＣ１２を含む周辺機器からメンテナンス情報を収集して記憶部（ＲＡＭ２０３）に格納する。
【００８２】
また監視装置１は、タイマ処理部６０４からの信号に従って定期的に定期通信作成部６０５を起動する（Ｓ４５１）。起動した定期通信作成部６０５は、メール作成情報６０６から送信元、送信先（センタ側管理サーバ６）、サブジェクト情報を取得して（ステップＳ４５２）、自装置が正常な通信機能を有していることを示す確認メールを作成し（ステップＳ４５３）、該確認メールをメール処理部６０３に渡し、送信を依頼する（ステップＳ４５４）。メール処理部６０３は、該確認メールの送信依頼を受け取ると、メッセージＩＤ及び日付の他、メール交換に必要な情報を付加して（ステップＳ４５５）、外部のメールサーバに該メールを、通信処理部６０２を経由して送信する（ステップＳ４５６）。なお、この確認メールには、記憶部（ＲＡＭ２０３）に格納されたメンテナンス情報が含まれる。
【００８３】
図１５は、センタ側管理サーバ６において実行されるメール受信処理の手順を示すフローチャートである。なお、ステップＳ５０２においては、管理対象となる複数の監視装置からのメールを受信することとなる。
【００８４】
センタ側管理サーバ６の通信処理部６０８は、センタ側管理サーバ６宛のメールを受信すると、メール処理部６０９に渡す（ステップＳ５０１）。メール処理部６０９は、渡されたメールを定期通信メール解析部６１０に渡す（ステップＳ５０２）。
【００８５】
定期通信メール解析部６１０では、渡されたメールについてサブジェクトを解析する（ステップＳ５０３）。その結果、サブジェクトに、予め設定されている文字列、例えば”Ｂｅａｃｏｎ”があるか否かを判別する（ステップＳ５０４）。”Ｂｅａｃｏｎ”があれば、受信メールが定期送信のメール（確認メール）とみなしてステップＳ５０６へ進み、なければ定期送信のメール（確認メール）ではないとみなして、該受信メールを廃棄する（ステップＳ５０５）。
【００８６】
ステップＳ５０６では、定期通信メール解析部６１０は、定期送信のメールのサブジェクトから送信元ＩＤを取り出す（ステップＳ５０６）。定期送信のメール（確認メール）は、複数の監視装置のうちのどの監視装置からも送信され得るため、送信元ＩＤを取り出すことによって監視装置が特定され得る。上述の図１２に示す一例では、サブジェクトが”Ｂｅａｃｏｎ ｆｒｏｍ ａｇｅｎｔ００１＿２１１”であり、”ｆｒｏｍ”の後の文字列”ａｇｅｎｔ００１＿２１１”
を送信元ＩＤとする。
【００８７】
続いて、定期通信メール解析部６１０は、メールを受信した日付時刻をセンタ側管理サーバ６のタイマ処理部６１２から取得し（ステップＳ５０７）、上記の送信元ＩＤと日付時刻とを対応付けてデータベース６１１に登録する（ステップＳ５０８）。なお既に、同じ送信元ＩＤで日付時刻が対応付けて登録されている場合、その日付時刻を更新する。なお、受信メールに含まれるメンテナンス情報もデータベース６１１に格納される。このステップＳ５０８の処理に基づいてデータベース６１１に登録／更新された監視対象管理情報がセンタ側管理サーバ６において作成される。このように各々の監視装置による通知タイミングの監視に基づく通知がなされ、ステップＳ５０１〜Ｓ５０８の処理が実行されるので、センタ側管理サーバ６は、応答要求の送信とその応答の受信の２回の情報転送を必要としなかったり、また複数台の監視対象装置（監視装置）に対して管理サーバが応答要求を一斉に行うか、または時差送信を行うかする必要もないので、監視対象装置の管理の負荷を軽減することができる。
【００８８】
また、複数の監視装置からのメールがステップＳ５０２においてセンタ側管理サーバ６にて受信されるが、この各監視装置から通知されたメールによるステップＳ５０２での受信タイミングが集中しないことが望まれる。そこで、各々の監視装置には、ステップＳ５０２における受信タイミングが集中しないようなメール通知タイミングが設定されている。また、この各々の監視装置におけるメール通知タイミングを変更すべくセンタ側管理サーバ６には、複数の監視装置に対してまとめて通知タイミングを更新させるよう指示する手段（通信処理部）を有し、各々の監視装置では、指示された通知タイミングに更新を行う機能が備わっている。
【００８９】
図１６は、センタ側管理サーバ６において実行される定期メール送信処理の手順を示すフローチャートであり、図１５に示すフローチャートの処理に基づいて実行されるものである。
【００９０】
センタ側管理サーバ６の定期通信管理部６１３は、予めタイミング間隔が設定されたタイマ処理部６１２から指示されるタイミングで、データベース６１１に記憶された監視対象管理情報を取得する（ステップＳ５０９）とともに、処理設定情報６１４から作業手順情報を取得する（ステップＳ５１０）。この作業手順情報は、データベースに記憶された監視対象管理情報から所定の条件に該当する監視装置を特定／選択する処理に利用される。
【００９１】
図１１に示す処理設定情報６１４の一例には、「３日以上定期送信メールを送信していない監視装置を探し、そうした各監視装置の送信元ＩＤの一覧を作成して通知メールに添付して送信するように」という主旨の作業手順情報が記載されている。以下、この作業手順情報に基づき加工された監視対象管理情報を作成する処理について説明する。無論、所定の条件としてはこれに限定されるものではなく、適宜顧客環境などを鑑みた所定の条件が所定設定手順６１４に格納される。
【００９２】
定期通信管理部６１３は、取得した作業手順情報に従い、まず、センタ側管理サーバ６のタイマ処理部６１２から現在時刻を取得する（ステップＳ５１１）。
【００９３】
そして定期通信管理部６１３は、現在時刻より３日以上古い日付時刻をもつ送信元ＩＤを選択し（ステップＳ５１２でＹＥＳ）、選択された監視装置の送信元ＩＤの一覧（監視対象管理情報）を作成する（ステップＳ５１３）。なお、現在時刻より所定日以上（例えば３日以上）古い日付時刻が存在しない場合（ステップＳ５１２でＮＯ）、本処理を終了する。
【００９４】
定期通信管理部６１３は、所定の条件に基づき加工された一覧（監視対象管理情報）を通知メール作成部６１５に渡す。通知メール作成部６１５は、メール作成情報６１６に基づき、渡された一覧を添付ファイルとしてメールを作成する（ステップＳ５１４）。ここで作成されたメールの例を図１３に示す。
【００９５】
作成されたメールは、メール処理部６０９を通して、予め設定されている宛先に送信される（ステップＳ５１５）。
【００９６】
以上のようにして、本発明の第１の実施の形態によれば、監視装置１を含む複数の監視装置がそれぞれ、定期的にメールをセンタ側管理サーバ６に送信し、センタ側管理サーバ６では、定期的に送信されるメールを受信することで、所定期間に亘ってメールを送ってこない監視装置があるか否かを判定し、こうした監視装置が存在すると判定した場合、予め設定された宛先にこうした監視装置の異常を通知する。
【００９７】
第１の実施の形態では、センタ側管理サーバ６が定期送信のメールであるか否かを判別する方法として、メールのサブジェクトに含まれる特定の文字列を使用したが、これに代わって、メール本文の内容に特定の文字列やコードを埋め込んで、定期送信のメールであることを示す方法や、監視対象となる送信元のメールアドレスを予め登録しておき、この登録アドレスと照合することにより、定期送信のメールであることを判別する方法を用いるようにしてもよい。
【００９８】
また第１の実施の形態では、センタ側管理サーバ６の定期通信管理部６１３が、定期送信メールを受信した日付時刻の参照元として、センタ側管理サーバ６内の時刻を用いたが、定期送信メール内に記録されている送信日付を利用するようにしてもよく、この場合でも同様の作用効果を得られる。さらに、定期通信管理部６１３は、送信元を判別する方法として、メールのサブジェクトから送信元情報を取り出したが、これに代わって、予め送信元アドレスと送信元情報との対応表を保持しておき、送信メールの送信元アドレスから送信元ＩＤを取得するようにしてもよく、また、メールの本文に送信元ＩＤを記録しておいて、その送信元ＩＤを利用するようにしてもよい。さらにまた、送信元ＩＤに代わって、監視装置のユーザ名称、監視装置に対応付けられたＩＤ，監視装置のＩＰアドレスまたはＭＡＣアドレスなどの利用であってもよい。
【００９９】
［第２の実施の形態］
次に第２の実施の形態を説明する。
【０１００】
第２の実施の形態の構成は、基本的に第１の実施の形態の構成と同じであるので、第２の実施の形態の説明においては、第１の実施の形態の構成を流用し、異なる部分だけを説明するようにする。
【０１０１】
図１７は、第２の実施の形態における監視装置１ａ及びセンタ側管理サーバ６の内部機能構成を示すブロック図である。監視装置１ａは第１の実施の形態における監視装置１に対応する。なお第２の実施の形態でも、センタ側管理サーバ６をＰＣ７に読み替えたり、またはセンタ側管理サーバ６とＰＣ７との一体装置に読み替えたりしてもよい。さらに、監視装置１ａを、拠点側管理サーバ２に読み替えたり、または監視装置１ａと拠点側管理サーバ２との一体装置に読み替えたりしてもよい。
【０１０２】
第２の実施の形態では、図１７に破線で囲んで示すように、監視装置１ａが、定期通信演算部１３０１、定期処理記録情報１３０２、タイミング規則情報１３０３、タイマ処理部１３０４を備える点が第１の実施の形態と異なっている。この点を除いては、第１の実施の形態と同一である。
【０１０３】
定期通信演算部１３０１は、メール作成履歴情報を基にして、次回にメールを送信すべきタイミングを決定する。定期処理記録情報１３０２は、前回のメール送信時期、メール送信回数、次回にメールを送信すべき時期からなるメール作成履歴情報であり、その一例を図１８に示す。タイミング規則情報１３０３は、送信回数に関する各種条件に応じて設定される次回メール送信タイミングに関するメール内容からなる情報であり、その一例を図１９に示す。タイマ処理部１３０４は、監視装置１ａ内のプログラムのタスク管理を行う。なお、タイマ処理部１３０４は、第１の実施の形態のタイマ処理部６０４を流用してもよい。
【０１０４】
図２０は、センタ側管理サーバ６のデータベース６１１が保持する、第２の実施の形態における情報の一例を示す図である。
【０１０５】
データベース６１１には、第１の実施の形態と同様の送信元ＩＤ、（前回）受信日のほか、次回受信予定日が記録される。
【０１０６】
図２１は、第２の実施の形態における監視装置１ａにおいて実行される定期メール送信処理の手順を示すフローチャートである。
【０１０７】
監視装置１ａは、タイマ処理部１３０２からの信号に従って定期的に定期通信演算部１３０１を起動する（Ｓ１１０１）。起動された定期通信演算部１３０１は、タイマ処理部１３０２から現在時刻を取得する（Ｓ１１０２）。続いて定期通信演算部１３０１は、定期処理記録情報１３０２からメール作成履歴情報（定期処理記録情報）を取得する（Ｓ１１０３）。該情報を基に、現在時刻が次回送信時期に到達しているか否かを判別する（Ｓ１１０４）。次回送信時期に到達していない場合、本定期メール送信処理を終了する。次回送信時期に到達しているか過ぎている場合、定期通信演算部１３０１は、タイミング規則情報１３０３を参照し（Ｓ１１０５）、送信回数に関する条件が合致する次回送信タイミングに対応するメール内容を読み出して（Ｓ１１０６）、該メール内容を定期通信作成部６０５に渡す（Ｓ１１０７）。同時にタイミング規則情報１３０３における「送信回数設定」に従い次回送信時期を決定して、定期処理記録情報１３０２を更新する。
【０１０８】
例えば、図１８に示す定期処理記録情報１３０２の例を適用される監視装置において、現在時刻が次回送信時期に到達していたとすると、図１９に示すタイミング規則情報１３０３の例における条件「送信回数が１０回未満（５回以上）」が対応するので、次回送信時期が５月１２日（＝５月１０日の２日後）、送信回数が９回（＝８回＋１）、前回送信時期が５月１０日となる。そしてこの場合に定期通信作成部６０５に渡されるメール内容は、「２ ｄａｙｓ ａｆｔｅｒ」である。また例えば、図１８に示す定期処理記録情報１３０２の例を適用される監視装置において、現在時刻が次回送信時期を過ぎているとすると、図１９に示すタイミング規則情報１３０３の例における条件「送信時期が過ぎている」が対応するので、次回送信時期が５月１１日（＝５月１０日の１日後）、送信回数が１回、前回送信時期が５月１０日となる。そしてこの場合に定期通信作成部６０５に渡されるメール内容は、「１ ｄａｙ ａｆｔｅｒ」である。
【０１０９】
図２１に戻って、定期通信作成部６０５は、定期通信演算部１３０１からメール内容を受けると、メール作成情報６０６から送信元ＩＤ、送信先アドレス、サブジェクト情報（第１の実施の形態と同じ”Ｂｅａｃｏｎ”の文字列）を取得して（Ｓ１１０８）、送信メールを作成（Ｓ１１０９）し、メール処理部６０３に渡す。メール処理部６０３は、これを受け取るとメッセージＩＤ及び日付の他、メール交換に必要な情報を付加（Ｓ１１１０）して、メールサーバに該メールを、通信処理部６０２を経由して送信する（Ｓ１１１１）。
【０１１０】
図２２は、第２の実施の形態におけるセンタ側管理サーバ６において実行されるメール受信処理の手順を示すフローチャートである。
【０１１１】
センタ側管理サーバ６の通信処理部６０８は、センタ側管理サーバ６宛のメールを受信する（Ｓ１２０１）と、それをメール処理部６０９に渡す。メール処理部６０９は、定期通信メール解析部６１０に渡す（Ｓ１２０２）。定期通信メール解析部６１０は、受信メールに対してサブジェクトを解析する（Ｓ１２０３）。その結果、予め設定されている、定期送信メールであることを表す文字列（ここでは、文字列”Ｂｅａｃｏｎ”）がサブジェクトに存在するか否かを判別する（Ｓ１２０４）。存在すればステップＳ１２０６へ進み、存在しなければステップＳ１２０５へ進む。ステップＳ１２０５では、受信メールを廃棄する（Ｓ１２０５）。
【０１１２】
ステップＳ１２０６では、定期通信メール解析部６１０は、受信メールのサブジェクトから送信元ＩＤを取り出す（Ｓ１２０６）。続いて、メールを受信した日付時刻をタイマ処理部６１２から取得する（Ｓ１２０７）。続いて定期通信メール解析部６１０は、メール内容を取得し（Ｓ１２０８）、該メール内容とステップＳ１２０７で取得した日付時刻とを基にして次回受信時刻を計算する（Ｓ１２０９）。得られた次回受信時刻を、ステップＳ１２０６で取り出された送信元ＩＤと対応付けてデータベース６１１に監視対象管理情報を記録／更新する（Ｓ１２１０）。
【０１１３】
図２３は、第２の実施の形態におけるセンタ側管理サーバ６において実行される定期メール送信処理の手順を示すフローチャートである。
【０１１４】
センタ側管理サーバ６の定期通信管理部６１３は、予めタイミング間隔が設定されたタイマ処理部６１２から指示されるタイミングで、データベース６１１に記憶された監視対象管理情報を取得する（ステップＳ１２１１）とともに、処理設定情報６１４から作業手順情報を取得する（ステップＳ１２１２）。
【０１１５】
例えば、処理設定情報６１４から取得された作業手順情報には、「現在時刻が次回受信時刻を過ぎている監視装置を探し、そうした各監視装置の送信元ＩＤの一覧を作成して通知メールに添付して送信するように」という主旨の作業手順情報が記載されている。定期通信管理部６１３は、取得した作業手順情報に従い、まず、センタ側管理サーバ６のタイマ処理部６１２から現在時刻を取得する（ステップＳ１２１３）。
【０１１６】
そして定期通信管理部６１３は、現在時刻が次回受信時刻を過ぎている所定の条件を満たす監視装置の送信元ＩＤを単数或は複数選択し（ステップＳ１２１４でＹＥＳ）、選択された監視装置の送信元ＩＤの一覧を加工後の監視対象管理情報として作成する（ステップＳ１２１５）。なお、現在時刻が次回受信時刻を過ぎている監視装置が存在しない場合（ステップＳ１２１４でＮＯ）、本処理を終了する。
【０１１７】
定期通信管理部６１３は、作成した一覧を通知メール作成部６１５に渡す。通知メール作成部６１５は、メール作成情報６１６に基づき、渡された一覧を添付ファイルとしてメールを作成する（ステップＳ１２１６）。
【０１１８】
作成されたメールは、メール処理部６０９を通して、予め設定されている宛先に送信される（ステップＳ１２１７）。
【０１１９】
以上のようにして、本発明の第２の実施の形態によれば、監視装置１ａがセンタ側管理サーバ６に次回のメール送信タイミングを通知するようにして、この次回のメール送信タイミングにおいてメールが監視装置１ａから届かないことをもって、センタ側管理サーバ６が監視装置１ａの異常を検出するようにする。このように、次回のメール送信タイミングを監視装置１ａ側で設定することが可能であるため、例えば予め監視装置１ａが１週間停止することがわかっている場合、その１週間を織り込んだ次回のメール送信タイミングを監視装置１ａがセンタ側管理サーバ６に通知することで、この監視装置１ａの異常の誤検出を防止することができる。
【０１２０】
上記第２の実施の形態では、次回送信時期に関連するメール内容をメール本文に記載して、監視装置１ａからセンタ側管理サーバ６に送信し、センタ側管理サーバ６側でメール内容を基に次回受信日時を算出するようにしているが、これに代わって、メール本文中に次回送信日時自体を記載して、センタ側管理サーバ６側はその日時をそのまま次回受信日時としてもよい。
【０１２１】
［第３の実施の形態］
次に第３の実施の形態を説明する。
【０１２２】
上記の第１及び第２の実施の形態では、監視装置を遠隔監視システムに新たに追加する場合、センタ側管理サーバのデータベースに新たな監視装置の情報を手動で追加する必要があった。また、監視装置を遠隔監視システムから取り外す場合、センタ側管理サーバのデータベースから該監視装置の情報を手動で抹消する必要があった。第３の実施の形態では、こうした手動の作業を不要にしたものである。
【０１２３】
第３の実施の形態の構成は、基本的に第１の実施の形態の構成と同じであるので、第３の実施の形態の説明においては、第１の実施の形態の構成を流用し、異なる部分だけを説明するようにする。
【０１２４】
図２４は、第３の実施の形態における監視装置１及びセンタ側管理サーバ６ａの内部機能構成を示すブロック図である。センタ側管理サーバ６ａは第１の実施の形態におけるセンタ側管理サーバ６に対応する。なお第３の実施の形態でも、センタ側管理サーバ６ａをＰＣ７に読み替えたり、またはセンタ側管理サーバ６ａとＰＣ７との一体装置に読み替えたりしてもよい。さらに、監視装置１を、拠点側管理サーバ２に読み替えたり、または監視装置１と拠点側管理サーバ２との一体装置に読み替えたりしてもよい。
【０１２５】
第３の実施の形態では、図２４に破線で囲んで示すように、センタ側管理サーバ６ａが、ＩＤ管理部２４０１、処理設定情報２４０２、タイマ処理部２４０３を備える点が第１の実施の形態と異なっている。この点を除いては、第１の実施の形態と同一である。
【０１２６】
ＩＤ管理部２４０１は、受信メールを基にしてデータベース６１１での送信元ＩＤ情報などの入力、更新、削除を行う。処理設定情報２４０２は、データベース６１１内の情報の削除条件を示す。タイマ処理部２４０３は、センタ側管理サーバ６ａ内のプログラムのタスク管理を行う。
【０１２７】
なお、第３の実施の形態におけるメール作成情報６０６も、図１０に示す第１の実施の形態におけるメール作成情報の一例と同じ情報を持つ。また、第３の実施の形態における監視装置１から送信されるメール内容も、図１２に示す第１の実施の形態におけるメール内容の一例と同じ内容を持つ。
【０１２８】
図２５は、第３の実施の形態における処理設定情報２４０２の一例を示す図である。データベース６１１内に格納された情報のうちで、ここで示す条件に一致するものは、データベース６１１から削除される。
【０１２９】
図２６は、データベース６１１に格納された情報の一例を示す図である。送信元ＩＤ、受信回数、初回受信日、前回受信日から構成される。
【０１３０】
第３の実施の形態における監視装置１の処理動作は、図１４に示す第１の実施の形態における監視装置１の処理動作と同じであるので、ここでの説明は省略する。
【０１３１】
図２７は、第３の実施の形態におけるセンタ側管理サーバ６ａにおいて実行されるメール受信処理の手順を示すフローチャートである。
【０１３２】
センタ側管理サーバ６ａの通信処理部６０８は、センタ側管理サーバ６ａ宛のメールを受信すると、メール処理部６０９に渡す（ステップＳ１５０１）。メール処理部６０９は、渡されたメールを定期通信メール解析部６１０に渡す（ステップＳ１５０２）。
【０１３３】
定期通信メール解析部６１０では、渡されたメールについてサブジェクトを解析する（ステップＳ１５０３）。その結果、サブジェクトに、予め設定されている文字列、例えば”Ｂｅａｃｏｎ”があるか否かを判別する（ステップＳ１５０４）。”Ｂｅａｃｏｎ”があれば、受信メールが定期送信のメール（確認メール）とみなしてステップＳ１５０６へ進み、なければ定期送信のメール（確認メール）ではないとみなして、該受信メールを廃棄する（ステップＳ１５０５）。
【０１３４】
ステップＳ１５０６では、定期通信メール解析部６１０は、定期送信のメールのサブジェクトから送信元ＩＤを取り出す（ステップＳ１５０６）。定期送信のメール（確認メール）は、複数の監視装置のうちのどの監視装置からも送信され得るため、送信元ＩＤを取り出すことによって監視装置が特定され得る。上述の図１２に示す一例では、サブジェクトが”Ｂｅａｃｏｎ ｆｒｏｍ ａｇｅｎｔ００１＿２１１”であり、”ｆｒｏｍ”の後の文字列”ａｇｅｎｔ００１＿２１
１”を送信元ＩＤとする。
【０１３５】
続いて、定期通信メール解析部６１０は、メールを受信した日付時刻をセンタ側管理サーバ６ａのタイマ処理部２４０３から取得する（ステップＳ１５０７）。そして定期通信メール解析部６１０は、データベース６１１を参照して、ステップＳ１５０６で取り出された送信元ＩＤがデータベース６１１に登録されているか否かを判別する（Ｓ１５０８）。登録されていればステップＳ１５１０に進み、登録されていなければステップＳ１５０９に進んで、データベース６１１に該送信元ＩＤを新規登録し、監視対象管理情報を更新し、初回受信日を設定する（Ｓ１５０９）。ステップＳ１５１０では、データベース６１１の監視対象管理情報のなかで、ステップＳ１５０６で取り出された送信元ＩＤに対応する受信回数及び前回受信日を更新する（Ｓ１５１０）。
【０１３６】
図２８は、第３の実施の形態におけるセンタ側管理サーバ６ａにおいて実行されるＩＤ管理処理の手順を示すフローチャートである。
【０１３７】
ＩＤ管理部６１３は、タイマ処理部６１２からの信号に従って定期的に、データベース６１１を参照して、例えば図２６に示す情報を取得する（Ｓ１５１１）。また処理設定情報６１４から、例えば図２５に示す削除条件（作業手順）を取得する（Ｓ１５１２）。さらにＩＤ管理部６１３は、センタ側管理サーバ６ａのタイマ処理部２４０３から現在日時（現在時刻）を取得する（Ｓ１５１３）。以下の説明では、現在日付が５月１４日と仮定する。
【０１３８】
ＩＤ管理部６１３は、データベース６１１の情報と処理設定情報２４０２からの削除条件とを基にして、所定の条件であるところ削除条件に当てはまる情報がデータベース６１１の監視対象管理情報中に存在するか否かを判別する（Ｓ１５１４）。例えば、図２６に示すデータベース６１１内の情報のうち、送信元ＩＤが「ａｇｅｎｔ００１＿２１１」である情報を、図２５に示す削除条件と照合すると、「受信回数が２０回以上で「（前回受信日−初回受信日）／受信回数＋前回受信日」が現在日付より前（ならば対象情報を削除する）」という削除条件が適用される。ここで対象とする情報では、（前回受信日−初回受信日）が２０３日、受信回数が４４回であるので、「（前回受信日−初回受信日）／受信回数」は４．６日と算出され、「（前回受信日−初回受信日）／受信回数＋前回受信日」が５月１９日となり、現在日付５月１４日よりも後である。したがって、送信元ＩＤが「ａｇｅｎｔ００１＿２１１」である情報は削除対象外である。
【０１３９】
次に、図２６に示すデータベース６１１内の情報のうち、送信元ＩＤが「ａｇｅｎｔ１２２＿０４５」である情報を、図２５に示す削除条件と照合すると、「受信回数が２０回以上で「（前回受信日−初回受信日）／受信回数＋前回受信日」が現在日付より前（ならば対象情報を削除する）」という削除条件が適用される。ここで対象とする情報では、（前回受信日−初回受信日）が１２２日、受信回数が２６回であるので、「（前回受信日−初回受信日）／受信回数」は４．７日と算出され、「（前回受信日−初回受信日）／受信回数＋前回受信日」が５月１１日となり、現在日付５月１４日よりも前である。したがって、送信元ＩＤが「ａｇｅｎｔ１２２＿０４５」である情報は削除対象である。同様に、図２６に示すデータベース６１１内の他の情報に対して処理を行う。その結果、送信元ＩＤ「ａｇｅｎｔ１２２＿０４５」の情報だけが削除対象であり、この情報だけがデータベース６１１から削除され、監視対象管理情報が更新される（Ｓ１５１５）。
【０１４０】
このように管理されるデータベース６１１に対して、第３の実施の形態におけるセンタ側管理サーバ６ａが定期メール送信処理を実行し、監視装置に異常があると、予め設定された宛先に該異常が通知されるが、この定期メール送信処理は、図１６に示す第１の実施の形態のセンタ側管理サーバ６において実行される定期メール送信処理と同一であるので、その説明を省略する。
【０１４１】
以上のように第３の実施の形態では、複数の監視装置からセンタ側管理サーバに定期的に情報を送信し、センタ側管理サーバでは受信した情報をデータベースに格納する。そして、新たな監視装置に関する情報は自動的にデータベースに格納される。また、センタ側管理サーバでは、あらかじめ設定されている削除条件にあう監視装置に対応する情報をデータベースから自動的に削除する。これにより、センタ側管理サーバ管理者によるセンタ側管理サーバ上のデータベースへの監視装置の登録が不要となる。また、監視装置を取り外した場合、該監視装置の情報をデータベースからセンタ側管理サーバ管理者によって削除する手間が不要となる。また、監視装置の異常を所定の宛先に通知するセンタ側管理サーバでは、上記削除条件を満たした監視装置に関する無駄な異常通知を行わないで済む。
【０１４２】
なお、上記の第３の実施の形態では、定期通信のメール（確認メール）であるか否かを判別する方法として、サブジェクトに含まれる文字列、例えば”Ｂｅａｃｏｎ”を使用したが、これに代わって、定期通信のメールのメール本文に所定の文字列やコードを埋め込んで、これを判別の材料としたり、定期通信のメールを送信すべき送信元の情報を予め登録しておき、該登録情報が定期送信メールに記載されているか否かによって判別するようにしたりしてもよい。
【０１４３】
また、上記の第３の実施の形態では、定期送信メールがセンタ側管理サーバに届いた日付を受信日として削除条件に利用しているが、これに代わって、定期送信メール内に記録されている送信日付を利用するようにしても同様の作用効果を得ることができる。
【０１４４】
さらに、上記の第３の実施の形態では、送信元を判別する方法として、サブジェクトから送信元ＩＤを取り出したが、これに代わって、予め送信元アドレスと送信元ＩＤとの対応表を保持しておき、送信元アドレスから送信元ＩＤを取得するようにしたり、メールの本文に送信元ＩＤを記録しておき、その記録を利用するようにしてもよい。
【０１４５】
［他の実施の形態］
なお、本発明の目的は、前述の各実施の形態の機能を実現するソフトウェアのプログラムコードを記録した記憶媒体を、システムまたは装置に供給し、そのシステムまたは装置のコンピュータ（またはＣＰＵ、ＭＰＵ等）が記憶媒体に格納されたプログラムコードを読み出して実行することによっても達成される。
【０１４６】
この場合、記憶媒体から読み出されたプログラムコード自体が前述した各実施の形態の機能を実現することになり、そのプログラムコードを記憶した記憶媒体は本発明を構成することになる。
【０１４７】
また、プログラムコードを供給するための記憶媒体としては、例えば、フロッピー（登録商標）ディスク、ハードディスク、光磁気ディスク、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、ＣＤ−ＲＷ、ＤＶＤ−ＲＯＭ、ＤＶＤ−ＲＡＭ、ＤＶＤ−ＲＷ、ＤＶＤ−Ｒ、磁気テープ、不揮発性のメモリカード、ＲＯＭ等を用いることができる。
【０１４８】
また、コンピュータが読み出したプログラムコードを実行することにより、上記の各実施の形態の機能が実現されるだけでなく、そのプログラムコードの指示に基づき、コンピュータ上で稼動しているＯＳ（オペレーティングシステム）等が実際の処理の一部または全部を行い、その処理によって前述した各実施の形態の機能が実現される場合も含まれる。
【０１４９】
更に、記憶媒体から読み出されたプログラムコードが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書き込まれた後、そのプログラムコードの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵ等が実際の処理の一部または全部を行い、その処理によって前述した各実施の形態の機能が実現される場合も含まれる。
【０１５０】
以上のように、本発明の各種の実施の形態を示して説明したが、以下に本発明の実施態様の例を列挙する。
【０１５１】
〔実施態様１〕 複数の監視装置を一元的に管理する管理サーバと通信可能な、複数の周辺機器の少なくともカウンタを含むメンテナンス情報を管理する管理装置であって、
前記周辺機器のメンテナンス情報を管理する管理手段と、
定期的に前記管理サーバへ識別ＩＤを含む確認情報を通知するようにする通信制御手段とを有し、
前記通信制御手段は、前記管理手段により管理されるメンテナンス情報を前記管理サーバに通知し、前記管理サーバでは前記通信制御手段による通知の通知履歴に基づく監視対象管理情報を作成することを特徴とする管理装置。
【０１５２】
〔実施態様２〕 前記監視対象管理情報は、前記通知履歴が所定条件に当てはまる管理装置を特定可能なリストの情報であることを特徴とする実施態様１に記載の管理装置。
【０１５３】
〔実施態様３〕 所定の管理装置を前記監視対象管理情報に含めるか否かを判断する判断手段を更に有し、前記判断手段により含めると判断された管理装置は前記監視対象管理情報に含まれ、前記リストの情報には複数の管理装置を特定可能な情報が含まれることを特徴とする実施態様１又は実施態様２に記載の管理装置。
【０１５４】
〔実施態様４〕 確認情報であることを識別可能な識別子を前記確認情報に含めるように前記確認情報を作成する作成手段を更に有し、前記通信制御手段は、タイマに従い定期的に、前記作成手段により作成された確認情報を通信回線を介して前記管理サーバに通知することを特徴とする実施態様１から実施態様３の何れかに記載の管理装置。
【０１５５】
〔実施態様５〕 前記作成手段は、自装置の識別ＩＤをメールに含めるようにし、前記識別子を前記メールのサブジェクトに含めるようにすることを特徴とする実施態様４に記載の管理装置。
【０１５６】
〔実施態様６〕 前記監視装置には前記監視対象管理情報を通知する第２制御手段が備えられることを特徴とする実施態様１から実施態様５の何れかに記載の管理装置。
【０１５７】
〔実施態様７〕前記管理サーバには前記通知制御手段を介しての定期的に前記確認情報の通知の次回の予定時刻が記録されており、予定時刻に前記監視装置からの情報が未着であることに応じて前記監視装置の異常が検知されることを特徴とする実施態様１から実施態様６の何れかに記載の管理装置。
【０１５８】
〔実施態様８〕 前記管理サーバは、前記識別ＩＤが既に登録されたものであるか否かを判別し、該判別に応じて前記識別ＩＤに対応する監視装置を新規に登録することを特徴とする実施態様１から実施態様７の何れかに記載の管理装置。
【０１５９】
〔実施態様９〕 前記管理サーバは、所定の通知履歴条件に基づき前記識別ＩＤを監視対象から削除することを特徴とする実施態様１から実施態様８の何れかに記載の管理装置。
【０１６０】
【発明の効果】
以上詳述したように本発明によれば、複数の監視装置がそれぞれ、定期的に電子メールを管理サーバに送信し、管理サーバでは、定期的に送信される電子メールを受信することで、所定期間に亘って電子メールを送ってこない監視装置があるか否かを判定し、こうした監視装置が存在すると判定した場合、予め設定された宛先にこうした監視装置の異常を通知する。
【０１６１】
これにより、複数の監視装置を一元的に管理する管理サーバにおける処理負荷を軽減することができる。
【０１６２】
また、監視装置が管理サーバに次回のメール送信タイミングを通知するようにして、この次回のメール送信タイミングにおいて電子メールが監視装置から届かないことをもって、管理サーバが監視装置の異常を検出するようにする。
【０１６３】
このように、次回のメール送信タイミングを監視装置側で設定することが可能であるため、例えば監視装置が所定期間に亘って動作を停止しても、それを監視装置の異常であると誤検出することを防止することができる。
【０１６４】
さらに、複数の監視装置から管理サーバに定期的に情報を送信し、管理サーバでは受信した情報をデータベースに格納する。そして、新たな監視装置に関する情報は自動的にデータベースに格納される。また、管理サーバでは、あらかじめ設定されている削除条件にあう監視装置に対応する情報をデータベースから自動的に削除する。
【０１６５】
これにより、管理サーバ管理者による管理サーバ上のデータベースへの監視装置の登録が不要となる。また、監視装置を取り外した場合、該監視装置の情報をデータベースから管理サーバ管理者によって削除する手間が不要となる。また、監視装置の異常を所定の宛先に通知する管理サーバでは、上記削除条件を満たした監視装置に関する無駄な異常通知を行わないで済む。
【図面の簡単な説明】
【図１】本発明に係る遠隔監視システムの第１の実施の形態の全体構成を示す図である。
【図２】監視装置のハードウェア構成を示すブロック図である。
【図３】監視装置において実行される障害情報確認プログラムの処理手順を示すフローチャートである。
【図４】監視装置において実行される応答確認プログラムの処理手順を示すフローチャートである。
【図５】監視装置において実行されるカウンタ情報取得プログラムの処理手順を示すフローチャートである。
【図６】監視装置において実行されるカウンタ情報送信プログラムの処理手順を示すフローチャートである。
【図７】画像形成装置の１つを制御するコントローラの構成を示すブロック図である。
【図８】画像形成装置のソフトウェア（タスク）構成を示す図である。
【図９】図１における監視装置及びセンタ側管理サーバの内部機能構成を示すブロック図である。
【図１０】図９のメール作成情報の一例を示す図である。
【図１１】図９の処理設定情報の一例を示す図である。
【図１２】監視装置から送信されるメール内容の一例を示す図である。
【図１３】センタ側管理サーバから送信されるメール内容の一例を示す図である。
【図１４】監視装置において実行される定期メール送信処理の手順を示すフローチャートである。
【図１５】センタ側管理サーバにおいて実行されるメール受信処理の手順を示すフローチャートである。
【図１６】センタ側管理サーバにおいて実行される定期メール送信処理の手順を示すフローチャートである。
【図１７】第２の実施の形態における監視装置及びセンタ側管理サーバの内部機能構成を示すブロック図である。
【図１８】前回のメール送信時期、メール送信回数、次回にメールを送信すべき時期からなる定期処理記録情報（メール作成履歴情報）の一例を示す図である。
【図１９】送信回数に関する各種条件に応じて設定される次回メール送信タイミングに関するメール内容からなるタイミング規則情報の一例を示す図である。
【図２０】センタ側管理サーバのデータベースが保持する、第２の実施の形態における情報の一例を示す図である。
【図２１】第２の実施の形態における監視装置において実行される定期メール送信処理の手順を示すフローチャートである。
【図２２】第２の実施の形態におけるセンタ側管理サーバにおいて実行されるメール受信処理の手順を示すフローチャートである。
【図２３】第２の実施の形態におけるセンタ側管理サーバにおいて実行される定期メール送信処理の手順を示すフローチャートである。
【図２４】第３の実施の形態における監視装置及びセンタ側管理サーバの内部機能構成を示すブロック図である。
【図２５】第３の実施の形態における処理設定情報の一例を示す図である。
【図２６】データベースに格納された情報の一例を示す図である。
【図２７】第３の実施の形態におけるセンタ側管理サーバにおいて実行されるメール受信処理の手順を示すフローチャートである。
【図２８】第３の実施の形態におけるセンタ側管理サーバにおいて実行されるＩＤ管理処理の手順を示すフローチャートである。
【符号の説明】
１ 監視装置
２ 拠点側管理サーバ
３〜５ 画像形成装置（周辺機器）
６ センタ側管理サーバ（管理サーバ）
７ パーソナルコンピュータ（ＰＣ、管理サーバ）
８ 通信回線
９ ネットワーク
１０ 所定のプロトコル
１２ パーソナルコンピュータ（ＰＣ、周辺機器）
６０２ 通信処理部
６０３ メール処理部
６０４ タイマ処理部
６０５ 定期通信作成部
６０６ メール作成情報
６０８ 通信処理部
６０９ メール処理部
６１０ 定期通信メール解析部
６１１ データベース
６１２ タイマ処理部
６１３ 定期通信管理部
６１４ 処理設定情報
６１５ 通知メール作成部
６１６ メール作成情報

Claims (1)

1. 複数の監視装置を一元的に管理する管理サーバと通信可能な、複数の周辺機器の少なくともカウンタを含むメンテナンス情報を管理する管理装置であって、
   前記周辺機器のメンテナンス情報を管理する管理手段と、
   定期的に前記管理サーバへ識別ＩＤを含む確認情報を通知するようにする通信制御手段とを有し、
   前記通信制御手段は、前記管理手段により管理されるメンテナンス情報を前記管理サーバに通知し、前記管理サーバでは前記通信制御手段による通知の通知履歴に基づく監視対象管理情報を作成することを特徴とする管理装置。

Images