JP2004234645A - 画像形成装置の監視装置、該監視装置による制御方法、及び該制御方法を実行するプログラム、並びに管理装置、該管理装置による制御方法、及び該制御方法を実行するプログラム - Google Patents

Abstract

【課題】 管理装置からの遠隔操作により監視装置が作動するモジュールのアップデートを効率よく行うことを可能としたデバイス監視装置を提供する。
【解決手段】 監視装置は管理装置との間で電子メールによる通信を行う。監視装置は、管理装置から電子メールにより監視装置内のモジュールをアップデートするための他のモジュールを受信したことに応じて、自動的に作動中の前記モジュールを前記他のモジュールにアップデートする。監視装置は、管理装置から電子メールにより前記モジュールのバージョン情報の取得要求を受信した場合、バージョン情報を収集する。監視装置は、収集したバージョン情報を電子メールにより管理装置に返信する。
【選択図】 図１４

Description

本発明は、画像形成装置の監視装置、該監視装置による制御方法、及び該制御方法を実行するプログラム、並びに管理装置、該管理装置による制御方法、及び該制御方法を実行するプログラムに関し、特に、１台以上の画像形成装置（特に機能複合型複写機を初めとする印刷事務機）を監視下に置き、当該画像形成装置の情報を収集すると共に収集した情報を管理サーバ（管理装置）へ通知する監視装置、該監視装置による制御方法、及び該制御方法を実行するプログラム、並びに１台以上の監視装置を管理下に置き情報を収集する管理装置、該管理装置による制御方法、及び該制御方法を実行するプログラムに関する。

従来、情報処理機能を有する装置（ホスト）と監視装置とを通信媒体により通信可能に構成し、監視装置を介して複写機等の装置の状態を遠隔から監視する遠隔監視システムが存在する。この種の遠隔監視システムにおいては、遠隔地に設置されている監視装置が作動するその内部のモジュール（プログラム）のアップデート（バージョンアップ）を遠隔地から行う方法は存在していたが、その場合、ホストとアップデート対象の監視装置が、互いに通信可能に接続されて、この通信可能に接続された状態で確実にアップデートデータの転送を行って監視装置のモジュールのアップデートを行い、次いでアップデートしたモジュールが所望のモジュールにアップデートされているか否かの確認を行い、ホストと監視装置との接続を切断するというものであった。

尚、上記に関連した従来例としては各種の提案がなされている（例えば、特許文献１参照。）。
特開２０００−３２２２４４号公報

しかしながら、上記従来の遠隔監視システムにおいては次のような問題があった。遠隔監視システムのホストは、複数の監視装置を管理下に置いているため、監視装置のモジュールをアップデートするためにアップデート対象の監視装置１台ずつと通信可能に接続してアップデート処理を行う必要があり、この作業は膨大なものであり、従来技術では円滑にアップデート処理を行うことは困難であった。

本発明は、上述した点に鑑みなされたものであり、管理装置からの遠隔操作により監視装置が作動するモジュールのアップデートを効率よく行うことを可能としたデバイス監視装置、該監視装置による制御方法、及び該制御方法を実行するプログラム、並びに管理装置、該管理装置による制御方法、及び該制御方法を実行するプログラムを提供することを目的とする。

上記目的を達成するために、請求項１記載の監視装置は、監視対象とする少なくとも１つの画像形成装置から通信により情報を取得すると共に管理装置と通信可能な監視装置であって、前記管理装置との間で電子メールによる通信を行う電子メール手段と、前記管理装置から電子メールにより、前記監視装置が作動する第１のモジュールをアップデートするための第２のモジュールを前記電子メール手段が受信したことに応じて自動的に作動中の前記第１のモジュールを前記受信した第２のモジュールにアップデートする処理手段と、前記管理装置から電子メールにより前記第１のモジュールのバージョン情報の取得要求を前記電子メール手段が受信した場合、前記バージョン情報を収集する情報収集手段と、前記情報収集手段により収集した前記バージョン情報を電子メールにより前記管理装置に返信する返信手段と、を有することを特徴とする。

請求項２記載の監視装置は、請求項１に記載の監視装置において、更に、前記管理装置から、少なくとも前記第２のモジュール及びインストールスクリプトを含むアップデート指示電子メールと、前記監視装置内の各第１のモジュール個別のバージョン及び前記監視装置全体のバージョンを示す前記バージョン情報の取得を要求する取得要求電子メールとを受信する受信手段を有し、前記処理手段は、前記受信手段により受信した前記アップデート指示電子メールに含まれる前記インストールスクリプトを起動し、作動中の前記第１のモジュールを前記受信手段により受信した前記アップデート指示電子メールに含まれる前記第２のモジュールにアップデートし、前記情報収集手段は、前記受信手段により受信した前記取得要求電子メールに応じて、前記バージョン情報を収集し、前記返信手段は、前記情報収集手段により収集した前記バージョン情報を前記管理装置に電子メールで返信することを特徴とする。

請求項３記載の監視装置は、請求項１に記載の監視装置において、前記電子メール手段が受信した電子メールの内容を解読する解読手段を有し、前記処理手段は、前記解読手段による前記受信した電子メールの内容の解読により前記管理装置からの前記第１のモジュールのアップデートの指示を解釈し、該解釈した電子メールの内容に応じた処理を行うことを特徴とする。

請求項４記載の管理装置は、監視対象とする複数の画像形成装置から通信により情報を取得する複数の監視装置を管理下に置くことが可能な管理装置であって、前記複数の監視装置それぞれに一括して前記複数の監視装置それぞれが作動する第１のモジュールの第２のモジュールへのアップデートを電子メールを用いて指示する指示手段と、前記複数の監視装置それぞれに一括して前記第１のモジュールのバージョン情報の取得要求を電子メールにより行う取得要求手段と、前記複数の監視装置それぞれから前記バージョン情報を前記取得要求手段の行う前記バージョン情報の取得要求のための電子メールの返信として取得する取得手段と、を有することを特徴とする。

請求項５記載の管理装置は、請求項４に記載の管理装置において、前記指示手段は、前記複数の監視装置それぞれに一括して、少なくとも前記複数の監視装置それぞれの第１のモジュールをアップデートするための前記第２のモジュール及びインストールスクリプトを含むアップデート指示電子メールを送信し、前記取得要求手段は、前記複数の監視装置それぞれに一括して、前記監視装置内の各モジュール個別のバージョン及び前記監視装置全体のバージョンを示す前記バージョン情報の取得を要求する取得要求電子メールを送信し、前記取得手段は、前記複数の監視装置それぞれから、前記取得要求手段が送信する取得要求電子メールの返信として前記バージョン情報を受信することを特徴とする。

請求項６記載の管理装置は、請求項８に記載の管理装置において、前記指示手段の前記第１のモジュールの前記第２のモジュールへのアップデートの指示に基づく前記第１のモジュールのアップデート後にとるべきバージョンのバージョン情報と、前記取得手段により取得した前記バージョン情報とを比較し、前記第１のモジュールに対するアップデート処理の成否を確認する成否確認手段を有することを特徴とする。

請求項７記載の管理装置は、請求項６に記載の管理装置において、前記指示手段は、前記成否確認手段により前記第１のアップデートモジュールに対するアップデート処理が失敗と確認された監視装置に対して一括して再度前記第１のモジュールのアップデートの指示を行なうことを特徴とする。

請求項８記載の管理装置は、請求項６に記載の管理装置において、前記第１のモジュールのアップデート後にとるべきバージョンのバージョン情報は、前記監視装置全体のバージョンを示す第２のバージョン情報であり、前記第２のバージョン情報は前記監視装置の個別の各第１のモジュールの組合せに対応することを特徴とする。

請求項９記載の制御方法は、監視対象とする少なくとも１つの画像形成装置から通信により情報を取得すると共に管理装置と通信可能な監視装置による制御方法であって、前記管理装置との間で電子メールによる通信を行う通信ステップと、前記管理装置から電子メールにより前記監視装置が作動する第１のモジュールをアップデートするための第２のモジュールを前記通信ステップにおいて受信したことに応じて自動的に作動中の前記第１のモジュールを前記受信した第２のモジュールにアップデートする処理ステップと、前記管理装置から電子メールにより前記第１のモジュールのバージョン情報の取得要求を前記通信ステップにおいて受信した場合、前記バージョン情報を収集する情報収集ステップと、前記情報収集ステップにより収集した前記バージョン情報を電子メールにより前記管理装置に返信する返信ステップと、を有することを特徴とする。

請求項１０記載の制御方法は、請求項９に記載の制御方法において、更に、前記管理装置から、少なくとも前記第２のモジュール及びインストールスクリプトを含むアップデート指示電子メールと、前記監視装置内の各モジュール個別のバージョン及び前記監視装置全体のバージョンを示す前記バージョン情報の取得を要求する取得要求電子メールとを受信する受信ステップを有し、前記処理ステップは、前記受信ステップにおいて受信した前記アップデート指示電子メールに含まれるインストールスクリプトを起動し、作動中の前記第１のモジュールを前記受信ステップにおいて受信した前記アップデート指示メールに含まれる第２のモジュールにアップデートし、前記情報収集ステップは、前記受信ステップにより受信した前記取得要求電子メールに応じて、前記バージョン情報を収集し、前記返信ステップは、前記情報収集ステップにおいて収集した前記バージョン情報を前記管理装置に電子メールで返信することを特徴とする。

請求項１１記載の制御方法は、請求項９に記載の制御方法において、前記通信ステップにおいて受信した電子メールの内容を解読する解読ステップを有し、前記処理ステップは、前記解読ステップにおける前記受信した電子メールの内容の解読により前記管理装置の指示を解釈し、該解釈した電子メールの内容に応じた処理を行うことを特徴とする。

請求項１２記載の制御方法は、監視対象とする複数の画像形成装置から通信により情報を取得する複数の監視装置を管理下に置くことが可能な管理装置による制御方法であって、前記複数の監視装置それぞれに一括して前記複数の監視装置それぞれが作動する第１のモジュールの第２のモジュールへのアップデートを電子メールを用いて指示する指示ステップと、前記複数の監視装置それぞれに一括して前記第１のモジュールのバージョン情報の取得要求を電子メールにより行う取得要求ステップと、前記複数の監視装置それぞれから前記バージョン情報を前記取得要求ステップにおける前記バージョン情報の取得要求のための電子メールの返信として取得する取得ステップと、を有することを特徴とする。

請求項１３記載の制御方法は、請求項１２に記載の制御方法において、前記指示ステップは、前記複数の監視装置それぞれに一括して、少なくとも前記複数の監視装置それぞれの第１のモジュールをアップデートするための前記第２のモジュール及びインストールスクリプトを含むアップデート指示電子メールを送信し、前記取得要求ステップは、前記複数の監視装置それぞれに一括して、前記監視装置内の各モジュール個別のバージョン及び前記監視装置全体のバージョンを示す前記バージョン情報の取得を要求する取得要求電子メールを送信し、前記取得ステップは、前記複数の監視装置それぞれから、前記取得要求ステップにおいて送信する取得要求電子メールの返信として前記バージョン情報を受信することを特徴とする。

請求項１４記載の制御方法は、請求項１２に記載の制御方法において、前記指示ステップにおける前記第１のモジュールの前記第２のモジュールへのアップデートの指示に基づく前記第１のモジュールのアップデート後にとるべきバージョンのバージョン情報と前記取得ステップにより取得した前記バージョン情報とを比較し、前記第１のモジュールに対するアップデート処理の成否を確認する成否確認ステップを有することを特徴とする。

請求項１５記載の制御方法は、請求項１２に記載の制御方法において、前記指示ステップは、前記成否確認ステップにより前記第１のモジュールに対するアップデート処理が失敗と確認された監視装置に対して一括して再度前記アップデートを行なうことを特徴とする。

請求項１６記載の制御方法は、請求項１５に記載の制御方法において、前記第１のモジュールのアップデート後にとるべきバージョンは、前記監視装置全体のバージョンを示す第２のバージョン情報であり、前記第２のバージョン情報は前記監視装置の個別の各モジュールの組合せに対応することを特徴とする。

請求項１７記載のプログラムは、監視対象とする少なくとも１つの画像形成装置から通信により情報を取得すると共に管理装置と通信可能な監視装置による制御方法をコンピュータに実行させるプログラムであって、前記制御方法は、前記管理装置との間で電子メールによる通信を行う通信ステップと、前記管理装置から電子メールにより前記監視装置が作動する第１のモジュールをアップデートするための第２のモジュールを前記通信ステップにおいて受信したことに応じて自動的に作動中の前記第１のモジュールを前記受信した第２のモジュールにアップデートする処理ステップと、前記管理装置から電子メールにより前記第１のモジュールのバージョン情報の取得要求を前記通信ステップにおいて受信した場合、前記バージョン情報を収集する情報収集ステップと、前記情報収集ステップにより収集した前記バージョン情報を電子メールにより前記管理装置に返信する返信ステップと、を有することを特徴とする。

請求項１８記載のプログラムは、監視対象とする複数の画像形成装置から通信により情報を取得する複数の監視装置を管理下に置くことが可能な管理装置による制御方法をコンピュータに実行させるプログラムであって、前記制御方法は、前記複数の監視装置それぞれに一括して前記複数の監視装置それぞれが作動する第１のモジュールの第２のモジュールへのアップデートを電子メールを用いて指示する指示ステップと、前記複数の監視装置それぞれに一括して前記第１のモジュールのバージョン情報の取得要求を電子メールにより行う取得要求ステップと、前記複数の監視装置それぞれから前記バージョン情報を前記取得要求ステップにおける前記バージョン情報の取得要求のための電子メールの返信として取得する取得ステップと、を有することを特徴とする。

本発明によれば、管理装置が管理下に置く複数の監視装置の装置内のモジュールを、効率よく遠隔操作により一括してアップデートすることが可能となる。これにより、従来のように、管理装置がアップデート対象の監視装置１台ずつと通信可能に接続してアップデート処理を行うという膨大な作業を不要とすることが出来る。

以下、本発明の実施の形態を図面に基づいて詳細に説明する。

図１は本発明の実施の形態に係る監視装置と管理装置とを備えるデバイス遠隔監視システムの全体構成例を示す概念図である。デバイス遠隔監視システムは、本発明に係る監視装置としての監視装置１、拠点側管理サーバ２、デバイス３、４、５、本発明に係る管理装置としてのセンタ側管理サーバ６、センタ側クライアントＰＣ７、通信回線８、ＬＡＮ（Local Area Network）９から構成されている。図中１０は通信プロトコルである。

デバイス遠隔監視システムには、デバイス３〜５の監視を統括するセンタ側として少なくとも一般的な情報処理装置が備える構成を有するセンタ側管理サーバ６が存在し、更に、情報を蓄積するためのデータベース１１と、センタ側管理サーバ６にＬＡＮ９で接続され且つ単独で或いはセンタ側管理サーバ６のクライアントとして動作可能なセンタ側クライアントＰＣ７とが存在する。センタ側管理サーバ６と拠点側管理サーバ２とは、インターネット等の通信回線８を介し、所定の通信プロトコル１０で通信可能となっている。本実施の形態では、拠点側管理サーバ２やセンタ側管理サーバ６への不正アクセスを防止するためと、デバイス遠隔監視システムのネットワークにおけるファイアウォールを越す（通過する）ために、一般的なプロトコル（ＳＭＴＰ（Simple Mail Transfer Protocol））や認証機能も設けられている。尚、本例実施の形態では、センタ側管理サーバ６を１つしか図示していないが、後述する障害監視、カウンタ情報収集など目的に応じセンタ側管理サーバ６を複数存在させる構成も想定している。

一方、デバイス遠隔監視システムには、該システムの拠点側として拠点側管理サーバ２が存在し、デバイス３、４、５や不図示のパーソナルコンピュータの情報を収集する監視装置１がＬＡＮ９に接続されている。監視装置１は、ＬＡＮ９を介して通信可能な各種のデバイス３、４、５の稼動情報や障害情報を含むメンテナンス情報を収集すると共に、デバイス３、４、５の制御プログラムなどを更新するように制御する機能を備え、収集された情報を拠点側管理サーバ２を介してセンタ側管理サーバ６に転送する機能を備える。

尚、監視装置１と拠点側管理サーバ２、センタ側クライアントＰＣ７とセンタ側管理サーバ６は、互いに情報の共有を行うことができれば、本実施の形態のように別々の構成として設置してもよいし、それぞれの機能を併せ持つ単一の装置（監視装置１の機能と拠点側管理サーバ２の機能を併せ持つ単一の装置、センタ側クライアントＰＣ７の機能とセンタ側管理サーバ６の機能を併せ持つ単一の装置）として設置してもよい。図１に２点鎖線枠にてその様子を示す。以後、本例実施の形態では監視装置１が外部のセンタ側管理サーバ６と通信を行う時は拠点側管理サーバ２を介しての通信を行うこととするが、拠点側管理サーバ２に監視装置１の機能を兼用させるようにしてもよい。以後、監視装置１とセンタ側管理サーバ６とが互いに情報の送受信を行うものとして説明する。

また、図１では、監視装置１、拠点側管理サーバ２がそれぞれ１つしか示されていないが、実際の運用においては、複数の監視装置１、複数の拠点側管理サーバ２と、これら複数の監視装置１と複数の拠点側管理サーバ２とを一元的に管理するセンタ側管理サーバ６とを通信回線８を介し通信可能とすることで、デバイス遠隔監視システムが構築されている。

デバイス３〜５としては、画像形成装置としてのプリンタ（電子写真方式及びインクジェット方式を含む）や、画像読取装置としてのスキャナや、画像通信装置としてのファクシミリや、画像形成装置としてのプリンタ機能及びファクシミリ機能を統合的に備えたデジタル複合機や、情報処理装置としてのパーソナルコンピュータや、情報処理装置としてのプリントサーバなどが挙げられる。尚、画像形成装置につていは後述の記載において詳しく説明することとする。更に、不図示のパーソナルコンピュータは、図７において５０１で示すようにＬＡＮ９に接続されており、例えば、所定のアプリケーションデータをＯＳ（Operating System）、プリンタドライバを介してＰＤＬ（Page Description Language）データに生成し、該生成したＰＤＬデータをデバイス３、４、５に出力させるべく送信する機能を備える。

そして、監視装置１は、デバイス３〜５（プリンタ、ファクシミリ、複合機等）の稼動状態やトナー残量や用紙サイズ毎の印刷枚数等の稼動情報、パーソナルコンピュータにおけるＣＰＵの状況やメモリ使用状況や有料アプリケーション使用状況等の稼動情報、デバイス３〜５における用紙のジャム情報、パーソナルコンピュータでの再起動回数等の各種障害情報、等を少なくとも含むメンテナンス情報を収集する。

図２は、図１における監視装置１のハードウェア構成を示すブロック図である。監視装置１は、一般的な情報処理装置が備える構成、即ち、ＣＰＵ２０１、バス２０２、ＲＡＭ２０３、Ｆｌａｓｈ（フラッシュ）ＲＯＭ２０４に加えて、複数の各種用途のインタフェース（以下Ｉ／Ｆと略称）、即ち、Ｎｅｔｗｏｒｋ（ネットワーク）Ｉ／Ｆ２０５，２０６、Ｓｅｒｉａｌ（シリアル）Ｉ／Ｆ２０７、Ｄｅｂｕｇ（デバッグ）Ｉ／Ｆ２０８を備えている。

ＣＰＵ２０１は、各構成部品２０３〜２０８を個別に又は総統合的に制御するものであり、フラッシュＲＯＭ２０４に格納されたプログラムに基づき後述の図３〜図６、図９、図１５〜図１６のフローチャートに示す処理を実行する。バス２０２は、図２の監視装置１を構成する部品間のデータを受け渡す共通信号路である。ＲＡＭ２０３は、電気的に情報を記憶でき且つ書き換え可能な記憶手段である。フラッシュＲＯＭ２０４は、電気的に情報を書き換え可能であり且つ電源が無くなっても情報を記憶可能な不揮発性記憶手段である。ネットワークＩ／Ｆ２０５、２０６は、ネットワーク経由で外部と情報交換を行うインタフェースである。シリアルＩ／Ｆ２０７は、ＲＳ２３２Ｃシリアル通信にて情報交換を行うインタフェースである。デバッグＩ／Ｆ２０８は、デバッグ用途に用いるシリアル通信部であるところのインタフェースである。

尚、監視装置１にはキーボード等の入力デバイス、表示部、表示制御部などを備えるようにしてもよいが、後述するように監視装置１のネットワークＩ／Ｆ２０５、２０６に例えばサービスマンが所持するＰＣを接続し、該ＰＣ側から監視装置１内の設定プログラムを起動することで監視装置１の設定変更を行うことが可能である。これにより、監視装置１に入力デバイス、表示部、表示部制御部を備えなくともよいようにすることで安価に監視装置１を構築可能としている。

また、拠点側管理サーバ２、パーソナルコンピュータ（不図示）、センタ側管理サーバ６、センタ側クライアントＰＣ７については、一般的な情報処理装置が備える構成を備えていればよいので、詳しい説明は省略する。

図３は、図１における監視装置１が実行する障害情報確認処理のフローチャートである。図４は、図１における監視装置１が実行する応答確認処理のフローチャートである。監視装置１から拠点側管理サーバ２或いはセンタ側管理サーバ６（以下ホスト６（以下、全文修正済み）と称する）或いはセンタ側クライアントＰＣ７に対する情報送信は上記ＳＭＴＰ(Simple Mail Transfer Protocol)で行い、情報受信はＰＯＰ（Post Office Protocol）により行う場合について図３の障害情報確認処理、及び図４の応答確認処理を説明する。

図３において、監視装置１は監視対象のデバイス３〜５の障害情報を確認する障害情報確認プログラムを起動し、監視対象のデバイス３〜５それぞれに関し、以下のステップＳ３０１〜ステップＳ３０５の処理を行うことにより、例えば１分間隔で障害情報確認処理を行っている。先ずステップＳ３０１において、監視装置１はＬＡＮ９を介して監視対象のデバイス３〜５に対し障害情報を取得しに行く。次にステップＳ３０２において、上記ステップＳ３０１で障害情報を取得したかどうかを判定し、障害情報を取得したと判断した場合はステップＳ３０３に進む。

ステップＳ３０３において、監視装置１はホスト６に対し、上記ステップＳ３０２において取得した障害情報を送信する。次にステップＳ３０４において、監視装置１はホスト６からの応答を待つ応答確認処理（図４）を実行する。一方、ステップＳ３０２において、障害情報を取得しなかったと判断した場合は、ステップＳ３０５に進み、監視装置１は１分間隔で障害情報の確認を行うために、１分間待機し、その後ステップＳ３０１に戻る。

図４において、監視装置１は図３におけるステップＳ３０３でホスト６へ障害情報を送信した後、ステップＳ３０４で起動される応答確認処理を実行する。本処理は、監視装置１から障害情報をホスト６が受け取った場合、受け取ったことを示す情報をホスト６から監視装置１宛に電子メール（以下メールと略称）で通知するものである。応答確認処理においては、監視装置１は以下のステップＳ３０８〜ステップＳ３１０の処理を例えば３０秒間隔で繰り返しながら、最高３０分間ホスト６からの応答を待ち、その間に応答がなければホスト６に対し１回のみ障害情報の再送処理を行う。

ステップＳ３０８では、監視装置１は上記３０秒間隔で処理を行うための３０秒待機を行う。次にステップＳ３０９において、監視装置１はホスト６からのメールを受信し、ステップＳ３１０において、受信したメールが障害情報受信を示す応答メールかどうかをチェックする。ステップＳ３１０において、受信したメールの内容が応答メールであると判断した場合は、本応答確認処理を終了する。一方、ステップＳ３１０において、応答メールでないと判断した場合は、本応答確認プログラムが起動されてから３０分以内であればステップＳ３０８に戻り、本応答確認プログラムが起動されてから３０分を超えた場合はステップＳ３１１に進む。

ステップＳ３１１において、監視装置１はホスト６に対する障害情報の送信回数が１回であるか否かを判別し、障害情報の送信の回数が１回ではない場合、即ち、既にホスト６に障害情報の再送を行っていた場合には、処理を終了する。一方、ステップＳ３１１において、障害情報の送信回数が１回である場合、即ち、まだ１回もホスト６に障害情報を再送していない場合は、ステップＳ３１２において、監視装置１は障害情報をホスト６へ再送する。これにより、障害情報の再送は１回のみ行われることになる。

図５は、図１における監視装置１がデバイス３〜５やパーソナルコンピュータのカウンタ情報を取得するカウンタ情報取得処理のフローチャートであり、図６は、図１における監視装置１がデバイス３〜５やパーソナルコンピュータのカウンタ情報をホスト６に送信するカウンタ情報送信処理を示すフローチャートである。本実施の形態でのカウンタ情報とは、デバイス３〜５やパーソナルコンピュータの上記メンテナンス情報の一部或いは全てを含む情報であり、図５，６の処理は各デバイスのそれぞれに対して実行される。

図５において、監視装置１はカウンタ情報を取得するカウンタ情報取得プログラムを起動し、監視対象のデバイス３〜５それぞれに関し、以下のステップＳ４０１〜ステップＳ４０３の処理を例えば６０分間隔で行うことによりホスト６からのカウンタ情報の取得要求に備えている。先ずステップＳ４０１において、監視装置１は各デバイスからカウンタ情報を取得する。次にステップＳ４０２において、監視装置１は上記ステップＳ４０１で各デバイスから取得したカウンタ情報を、ホスト６からのカウンタ情報要求に備えフラッシュＲＯＭ２０４に保存する。ここで、各デバイスから取得するカウンタ情報のデータ形式とホスト６へ送信するカウンタ情報のデータ形式が異なる場合には、このカウンタ情報の保存の時点でデータ変換しておくことも可能である。また、このデータ変換をホスト６からカウンタ情報要求があった時点で行う方法もある。次にステップＳ４０３において、監視装置１は６０分後に同様のカウンタ情報の取得処理を行うために、６０分待機し、その後ステップＳ４０１に戻る。

図６において、監視装置１はホスト６からのカウンタ情報の要求に対しカウンタ情報を送るためにカウンタ情報送信プログラムを起動する。ホスト６は監視装置１に対してカウンタ情報要求コマンドを含むメールを送信することで、カウンタ情報を要求する。本カウンタ情報送信処理は、例えば３分間隔でホスト６からのメールをチェックし、カウンタ情報の要求に備える。先ずステップＳ４０５において、監視装置１はホスト６からのカウンタ情報の要求の有無をチェックする。次いでステップＳ４０６において、カウンタ情報の要求があるか否かを判別し、要求がないしと判断した場合は、ステップＳ４１０へ進む。一方、ステップＳ４０６において、カウンタ情報の要求ありと判断した場合は、ステップＳ４０７に進む。

ステップＳ４０７においては、監視装置１は上述の図５のカウンタ情報取得処理によりカウンタ情報を保存しているかどうかを判断する。カウンタ情報が保存されている場合は、ステップＳ４０８において、監視装置１は保存してあるカウンタ情報をホスト６へ送信する。本処理が実行されることにより監視装置１からホスト６に送信されたカウンタ情報は、上記で説明したようにセンタ側クライアントＰＣ７において共有され、例えばオペレータによる参照が可能となっている。一方、カウンタ情報が保存されていない場合は、監視装置１はカウンタ情報が未収集である旨をホスト６へ通知する。ステップＳ４１０では、監視装置１は例えば３分間隔でホスト６からのカウンタ情報の要求をチェックするため３分待機する。

このように、図３の障害情報確認処理、図４の応答確認処理、図５のカウンタ情報所得処置、及び図６のカウンタ情報送信処理が実行されることにより、ユーザに利用される画像形成装置やパーソナルコンピュータなどのデバイスにおけるメンテナンス情報を遠隔から一元的に集中管理することができる。

図７は上記図１におけるデバイス３〜５の一例である画像形成装置の全体を制御するコントローラの構成例を示すブロック図である。画像形成装置のコントローラは、原稿給送装置制御部５０２、イメージリーダ制御部５０３、画像信号制御部５０４、プリンタ制御部５０５、外部Ｉ／Ｆ５０６、ＣＰＵ回路部５０７、ソータ制御部５１３、フィニッシャ制御部５１４、状態検知部５１５を備えている。図７において、５１１は画像形成装置の操作部、５１２は画像形成装置の表示部、５０１は画像形成装置にＬＡＮ９を介して接続されたコンピュータである。

ＣＰＵ回路部５０７は、ＣＰＵ（図示略）、ＲＡＭ５０８、ＲＯＭ５０９、ハードディスク（ＨＤＤ）５１０を備えている。ＣＰＵは、ＲＯＭ５０８に格納されている制御プログラムに基づき、原稿給送装置制御部５０２、イメージリーダ制御部５０３、画像信号制御部５０４、プリンタ制御部５０５、外部Ｉ／Ｆ５０６、操作部５１１、表示部５１２、ソータ制御部５１３、フィニッシャ制御部５１４、状態検知部５１５を制御する。ＲＯＭ５０８は、制御プログラムを格納する。ＲＡＭ５０９は、制御データを一時的に保持し、また制御に伴う演算処理の作業領域として用いられる。ハードディスク５１０は、制御プログラムに必要な情報や、原稿給送装置制御部５０２〜状態検知部５１５から受信した情報を記憶する。

原稿給送装置制御部５０２は、原稿積載部にセットされた原稿を原稿読取位置へ自動的に給送する原稿給送装置（図示略）をＣＰＵ回路部５０７からの指示に基づき駆動制御する。イメージリーダ制御部５０３は、原稿を走査するスキャナユニット（図示略）、原稿の光学像を電気信号に光電変換するイメージセンサ（図示略）などに対する駆動制御を行い、イメージセンサから出力されたアナログ画像信号を画像信号制御部５０４に転送する。画像信号制御部５０４は、アナログ画像信号をデジタル信号に変換した後に各処理を施し、このデジタル信号をビデオ信号に変換してプリンタ制御部５０５に出力する。画像信号制御部５０４による処理動作は、ＣＰＵ回路部５０７により制御される。

外部Ｉ／Ｆ５０６は、ＬＡＮ９及び不図示のＬＡＮインタフェースを介してコンピュータ５０１から入力されたデジタル画像信号に各種処理を施し、このデジタル画像信号をビデオ信号に変換してプリンタ制御部５０５に出力する。また、外部Ｉ／Ｆ５０６は、ＬＡＮ９及びＬＡＮインタフェースを介して監視装置１と通信を行う。プリンタ制御部５０５は、入力されたビデオ信号に基づき、感光体に対する露光を制御する露光制御部（図示略）を駆動する。操作部５１１は、画像形成に関する各種機能を設定する複数のキー、設定状態を示す情報を表示するための表示部などを有し、各キーの操作に対応するキー信号をＣＰＵ回路部５０７に出力すると共に、ＣＰＵ回路部５０７からの信号に基づき対応する情報を表示部５１２に表示する。

ソータ制御部５１３は、画像形成が完了した用紙を仕分けるソータ機構（図示略）を駆動制御する。フィニッシャ制御部５１４は、画像形成が完了した用紙の後処理（用紙に穴を開けるパンチ処理、用紙を綴じるステイプル処理など）を行うフィニッシャ機構（図示略）を駆動制御する。ソータ制御部５１３、フィニッシャ制御部５１４は、外部Ｉ／Ｆ５０６を経由したユーザからの入力または操作部５１１からの設定により、ＣＰＵ回路部５０７からの信号に基づき動作する。状態検知部５１５は、図示の各ブロックからの状態情報を収集し、異常検知等の検知及び検知結果に基づく判断を行い、判断結果をＣＰＵ回路部５０７に通知する。ＣＰＵ回路部５０７は、この通知に従い表示部５１２に異常を表示し、外部Ｉ／Ｆ５０６を経由してコンピュータ５０１等へ異常を通知する。

図８は、図７の画像形成装置のソフトウェア構成を示すブロック図である。画像形成装置は、タスクマネージャＡ−１０１、紙搬送部タスク群Ａ−１０２、シーケンス制御タスクＡ−１０３、通信タスクＡ−１０４、管理用データ作成タスクＡ−１０５、状態監視タスクＡ−１０６を備えている。

タスクマネージャＡ−１０１は、複数のタスクを同時に管理するためのものである。紙搬送部タスク群Ａ−１０２は、原稿及び画像形成される用紙の搬送を司るタスク群である。シーケンス制御タスクＡ−１０３は、画像形成装置全体の管理を行うタスクである。通信タスクＡ−１０４は、監視装置１と通信を行うためのタスクである。

管理用データ作成タスクＡ−１０５は、本実施の形態の遠隔管理用データを作成するためのタスクである。画像形成装置では、画像形成処理ごとに用紙サイズ別、処理モード別、用紙種別、白黒／カラー別の稼動情報のカウントを行っている。これらの稼動情報のカウントは管理用データ作成タスクＡ−１０５にて行われ、画像形成装置内のハードディスク５１０に格納されている。同様にして、ジャム、エラー、アラームなどのステータス情報（障害情報）が所定のデータフォーマットで画像形成装置内のハードディスク５１０に格納される。更に、画像形成装置内の各部ごとに、消耗部品の交換寿命と、消耗部品の使用度数を表したカウンタ（部品カウンタ）を持っており、管理用データ作成タスクＡ−１０５の中でカウントされた結果が画像形成装置のハードディスク５１０に格納される。

状態監視タスクＡ−１０６は、画像形成装置内の異常（ジャム、エラー、アラーム）を検知するか、予め設定されたデバイスのステータス変化を検知するタスクであり、検知に伴いステータス情報が所定のデータフォーマットで画像形成装置内のハードディスク５１０に格納される。

図９は、図１における監視装置１においてホスト６からの指令を含むメールを受け取り、指示に従った処理を行うためのメール受信処理のフローチャートである。本メール受信処理は、スケジューリングされていると共に定期的に実行されるものであり、ホスト６から送信されるメールを一通受信するか、或いはメールを全て受信し終えることにより終了する。

先ずステップＳ７０１では、監視装置１はメールサーバ上にメールが到着しているかどうかを確認する。ステップＳ７０１において、メールサーバ上にメールが到着していない場合は、本メール受信処理を終了する。ステップＳ７０１において、メールサーバ上にメールが到着していた場合は、ステップＳ７０２において、監視装置１はメールサーバからメール一通のみを受信してくる。次にステップＳ７０３において、監視装置１は受信したメールがホスト６からのメールかどうかを判定する。本実施の形態においては、監視装置１側でホスト６のメールアドレスを認識しているため、送信元のメールアドレスがホスト６のメールアドレスか否かによって、受信したメールがホスト６からのメールか否かの判定を行っている。

ステップＳ７０３において、上記受信したメールがホスト６からのメールではないと判断した場合は、監視装置１はそのメールはゴミメールであると判断して破棄し、上記ステップＳ７０１に戻り、次のメールを受信する。ステップＳ７０３において、上記受信したメールがホスト６からのメールであると判断した場合は、監視装置１はメールを解読することによりホスト６の指令（要求）を解釈し、ステップＳ７０４において、その指令に相応しい処理プログラムを起動し、本メール受信プログラムを終了する。

本実施の形態において、後述する、モジュールアップデート処理、バージョン情報取得処理もホスト６からのメールによる指示により行われ、本メール受信プログラムによってメールを受け取り、それぞれアップデートコマンド処理プログラム（図１１）、バージョン収集処理プログラム(図１２)を起動して、モジュールアップデート処理、バージョン情報取得処理を実行する。また、図９のメール受信処理は後述する図１１や図１２の処理を実行させるためのみに行なわれるものに限定されるものではなく、この処理により、ＨＴＴＰやＦＴＰに比べ、監視装置１を宛先とする電子メールは、監視装置１が設置されているユーザ環境に受信され易く、様々な指示をホスト６から容易に行なえるという効果を得ることが出来る。つまり、ユーザ側に設置された監視装置１へＨＴＴＰやＦＴＰによりアクセスしようとしても、セキュリティーの関係から外部からのアクセスは禁止され不都合を生じることがあるが、これを未然に防ぐことができる。

図１０はホスト６から送信されるモジュールアップデート指示コマンドメール（電子メール）に添付されるデータの形式を示す図である。該モジュールアップデート指示コマンドメールは、監視装置１が作動するモジュールのアップデートを指示するためのものである。本データは、インストールシェルスクリプト８０１と、アップデートするモジュール（本体）８０２とから構成されており、圧縮、暗号化され、モジュールアップデート指示コマンドメールに添付される。インストールシェルスクリプト８０１は、監視装置１上のオペレーションシステムで実行可能なコマンドが、条件付きの起動制御なども含め一つ以上記載されたものであり、監視装置１の記憶部にファイルとして格納され、該格納されたそのファイルが監視装置１により実行される。

インストールシェルスクリプト８０１内には、常駐モジュールの停止、アップデートモジュールの停止などインストールの前処理用のコマンドと、モジュール８０２を監視装置１内に格納するためのコピーコマンドと、アップデート後の再起動などの後処理用コマンドが記載されている。尚、インストールシェルスクリプト８０１の内容は、アップデートするモジュール８０２の性格（常駐、非常駐、共有ライブラリなど）により異なる。

例えば、必要なときにのみ起動される非常駐プログラムであるバージョン取得プログラム（図１２で後述）は、アップデート対象モジュールが起動されていないタイミングで（本実施の形態では、アップデート対象モジューが起動中はモジュールの更新処理がエラーとなるため、成功するまで更新処理を再試行する）アップデート対象モジュールのアップデートが可能であり、起動されていないアップデート対象モジュールは、次回必要な時に起動される際には、既にアップデートされており、アップデートされたモジュールの起動後、更にこのアップデートされたモジュールの再起動（後処理）は不要である。

また、ソフトウェアモジュールのアップデートにもともない、共有メモリ（Ｆｌａｓｈ（フラッシュ）ＲＯＭ２０４）上のデータが不要になり破棄をしたい場合や、所定のモジュールのアップデートが行なわれ、モジュール稼動の安定性を重視するような場合に、後処理として再起動が必要になる。

図１１は、図９のメール受信処理におけるコマンド処理プログラムの起動に応じて実行されるコマンド処理としてのアップデートコマンド処理のフローチャートである。図１１のアップデートコマンド処理は、上記図９に示した監視装置１のメール受信処理において、ホスト６からモジュールアップデート指示を含むメールを受け取り（ステップＳ７０３でＹＥＳ）、受信したメールがアップデート指示と解釈された場合に、ステップＳ７０４で起動される。

ステップＳ９０１において、監視装置１はホスト６から受信したメールの添付ファイルをＲＡＭ２０３上で復号化及び解凍し、上記図１０に示したインストールシェルスクリプト８０１及びモジュール８０２から構成されるデータを取り出す。次にステップＳ９０２において、監視装置１はインストールシェルスクリプト８０１を起動し、モジュール８０２をインストールする（即ち、監視装置１で動作中のモジュールをモジュール８０２にアップデートする）。常駐モジュールとしては、例えば、デバイスエラー監視モジュールや、常駐モジュールのハングアップを監視するモジュールが挙げられる。そして、ステップS９０２においてインストールされたインストールシェルスクリプト８０１に基づきアップデート対象となる夫々の常駐及び非常駐モジュールの動作を停止するとともに、その後に、アップデート対象モジュール（図８の８０２）の置き換えが行なわれる。

このモジュールのアップデート処理についてもう少し詳しく説明すると、例えば、監視装置１内で、印刷枚数のカウンタ情報を収集し或いは通知するなどの印刷に対する課金にかかわる課金処理が動作している場合に、この課金処理動作をしているモジュールのアップデートを即座に行なうことは、課金処理に重大な支障をきたしてしまう恐れがある。そこで、このような課金処理などの重要処理にかかわるモジュールのアップデートを行なう場合には、モジュールの動作が終了するまで待機するようにして、モジュールの動作終了後にアップデート処理を行なうようにすればよい。

また、別の例としては監視装置１の所定のタイミングにおける再起動直後に、監視装置１がアップデート対象となるモジュールのアップデートを行なうようにする処理コマンドを、インストールシェルスクリプト８０１に記載しても良い。

図１２は、図９のメール受信処理におけるコマンド処理プログラムの起動に応じて実行されるコマンド処理としてのバージョン収集処理のフローチャートであり、このバージョン収集処理は、上記図９に示した監視装置１のメール受信処理において、ホスト６からバージョン情報取得指示を含むメールを受け取ったと判別した場合に（ステップＳ７０３）、ステップＳ７０４で起動される。

ステップＳ１００１において、監視装置１は監視装置１内に格納されている各モジュール（プログラム、シェルスクリプト、ライブラリなど）個別のバージョン情報及び監視装置１全体としてのバージョン情報を収集（“Software Version"）し、ホスト６に対する返信データを生成する。本実施の形態において、返信データはテキスト形式であり、印刷すると図１３に示す形式となる。次にステップＳ１００２において、監視装置１は上記ステップＳ１００１で生成したバージョン情報をファイルとしてメールに添付し、ホスト６へ送信する。

図１３は上記図１２のバージョン収集処理により生成したバージョン情報の印刷例を示す図である。図中１１０２で示す列に、１１０１で示す列の項目またはモジュールのバージョンが記載される。尚、バージョンの表記は、全項目共通フォーマット部分(例えば、”Software Version”では１.０.００まで)と、それに続く自由記述部分（右側列）から構成される。本実施の形態におけるモジュールアップデート処理においては、後述するように自動的にアップデートの成否を判断するが、その際、モジュール個別のバージョンは判断材料とせず、先頭行に“Software Version"で示すソフトウェアバージョンの値のみを判断材料とする。

具体的には、図１３における列１１０１の個別のモジュールのバージョンアップが全て正常に終了した場合に、これらのバージョンアップされた個別のモジュールのバージョンを示すバージョン情報が監視装置１で保持され、ステップ１００１において、これらのバージョン情報が収集されて、ソフトウェアバージョンが更新される。つまり、Ｓ１００２においてホスト６に返信されるメール中のバージョン情報が最新のものであれば、正常にソフトウェアモジュールのアップデートが行なわれたことを意味する。

また、ソフトウェアバージョンは、図１３における列１１０１に示される様々なモジュールの組合せを示すものであり、このソフトウェアバージョンにより、夫々のモジュールのバージョンを比較することなく、監視装置１におけるソフトウェアのアップデートの成否を確認することができる。

バージョン情報を監視装置１からホスト６へ通知する方法として、例えば、図１０に示されるインストールシェルスクリプト８０１に、監視装置１がモジュールの更新後にホスト６宛てに自発的に更新後のバージョン情報をイベント通知される処理を行なわせるコマンドを記載しても良いが、ホスト６が、モジュールのアップデートの成否をも監視装置１から受信する電子メールを利用して確認するようにすれば、監視装置１から自発的にホスト６にコネクションを張り成否を通知してくるような形態にくらべて、そのコネクションを張る必要もなくホスト６の処理負荷をより一層軽減することができる。

図１４はホスト６を含むホスト６側主導で行われる、ホスト６の管理下の単数或いは複数の監視装置１のモジュールを一括アップデートする一括アップデート処理のフローチャートである。また、図１５は、図１４における一括アップデート処理を行う目的で、ホスト６に接続したセンタ側クライアントＰＣ７上で動作する一括アップデートプログラムにおけるアップロード処理開始前のセンタ側クライアントＰＣ７の画面を示す図である。

Window１３０１には、アップデート対象とするモジュールを有する、ホスト６管理下の監視装置１を一覧表示する。図中では詳細に記載していないが、ホスト６管理下の全ての監視装置１に対して同じアップデートを行わない場合に備え、アップデート処理対象の監視装置１を上記一覧に追加又は上記一覧から削除する機能もある。１３０２は、各監視装置１の現在のソフトウェアバージョンを示している。１３０３は、各監視装置１から最終バージョン情報を取得した時間を示している。本実施の形態では、監視装置１を設置した後、または監視装置１に対しモジュールのアップデートを行った後、必ずバージョン情報を取得しているため、１３０２、１３０３に示すバージョン及び時刻は各監視装置１の最新の情報となっている。１３０４は、今回のアップデート後、各監視装置１のソフトウェアバージョンとなるべき値を示している。

ステップＳ１２０１において、ホスト６は上記図１０で説明したモジュールアップデート用の添付ファイルを作成する。次にステップＳ１２０３において、ホスト６はアップデート処理対象とするホスト６管理下の監視装置１全てに対し、モジュールアップデート指示を含み且つ上記ステップＳ１２０１で作成したアップデート用の添付ファイルを添付したメールを送信する。ステップＳ１２０２において、ホスト６は全アップデート処理対象の監視装置１に対しステップＳ１２０３の処理をし終えたかどうかを判断している。

次にステップＳ１２０５において、ホスト６はアップデート処理対象とするホスト６管理下の監視装置１全てに対し、バージョン情報取得指示を含むメールを送信する。ステップＳ１２０４において、ホスト６は全アップデート処理対象の監視装置１に対しステップＳ１２０５の処理をし終えたかどうかを判断している。尚、本バージョン情報取得処理はアップデート処理後の各監視装置１の状態を得るための処理である。そのため、各監視装置１がアップデート指示メールを受け取りアップデート処理を完了する十分な時間をおいて、本バージョン情報取得処理を行わなければならない。この十分な時間は、アップデートの前処理と後処理の違いのため、モジュールにより異なる。

図１０で説明したように、アップデートされたモージュールの再起動などの後処理があり、実測上把握されている再起動時間が１０分である場合、１０分以上の時間をおいた後、ホスト６から本バージョン取得メールが監視装置１に発せられる。このバージョン取得メールを送るまでにホスト６側で待機する時間は、アップデートモジュールのバージョンに対応するものであり、つまり、所定のバージョンにおけるアップデートモジュールの内容に、どのような処理（後処理、前処理）が含まれるかにより異なる。図１５、図１６に様々な監視装置１における様々なバージョンがホスト６に管理されているが、各監視装置１のアップデートを行なう場合に、そのバージョンによってホスト６は異なる時間を採用する。

次にステップＳ１２０６〜ステップＳ１２１０において、ホスト６は各監視装置１におけるモジュールのアップデート処理の成否の確認を行う。即ち、ステップＳ１２０６では、ホスト６は全アップデート処理対象の監視装置１に対しステップＳ１２０７〜ステップＳ１２１０の処理を行ったかどうかを判断している。ステップＳ１２０７において、上記ステップＳ１２０５で送信したバージョン情報取得要求に対する返事がなかった場合は、アップデート成否の判断ができないため、アップデート処理は失敗とみなし、ステップＳ１２１０に進む。ステップＳ１２０７において、上記ステップＳ１２０５で送信したバージョン情報取得要求に対する返事が得られていた場合は、ステップＳ１２０８に進む。

ステップＳ１２０８において、ホスト６は取得した情報内のソフトウェアバージョン（図１３に示す"Software Version"）の値とアップデート処理後に、全アップデート処理対象の監視装置１がとるべきソフトウェアバージョン１３０４（図１５）とを比較する。ステップＳ１２０９において、上記ステップＳ１２０８の比較の結果、正しくアップデートされていると判断した場合は、ステップＳ１２０６に戻り、ホスト６は他の処理対象の監視装置１についてステップＳ１２０７〜Ｓ１２１０の処理をする。ステップＳ１２０９において、上記ステップＳ１２０８の比較の結果、正しくアップデートされていないと判断した場合は、ステップＳ１２１０に進む。ステップＳ１２１０においては、アップデート失敗の場合の処理として、ホスト６はアップデート失敗した監視装置１を識別する情報を記憶する。

図１６は上記図１５で示したセンタ側クライアントＰＣ７上の画面の、全アップデート処理対象の監視装置１に対して上記図１４の処理を行った後の状態を示す画面である。Window１４０１上において、１４０２はステップＳ１２０５で得たアップデート後のバージョンを示し、１４０３はステップＳ１２０５によりバージョン情報を取得した時刻を示している。アップロード失敗と判断されステップＳ１２１０の処理を行った監視装置１には、１４０５で示す欄にチェックを表示し、失敗したことを明示している。これら監視装置１は、現在のソフトウェアバージョン１４０２と、アップデート後とるべきソフトウェアバージョン１４０４とが異なっている。

尚、本実施の形態ではアップロード失敗を図１６のWindow１４０１上に明示しただけであったが、これに限定されるものではなく、ステップＳ１２１０で保存した情報（アップデート失敗した監視装置１を識別する情報）を元に、該当する監視装置１に対するアップデート処理を自動的に再試行することも可能である。

以上説明したように、本実施の形態によれば、監視装置１がホスト６（センタ側管理サーバ６）からモジュールアップデート指示メールを受信した場合、動作中のモジュールを受信したモジュールにアップデートし、ホスト６からバージョン情報取得要求メールを受信した場合、モジュールのバージョン情報を収集すると共に収集したバージョン情報をホスト６に返信するので、監視装置１がホスト６からの遠隔操作により監視装置１内のモジュールのアップデートを効率よく行うことが可能となる。これにより、従来のようなアップデート対象の監視装置１台ずつに対しコネクションを張りアップデート処理を行うという煩雑な作業が不要となる。

また、ホスト６は監視装置１それぞれに一括して、少なくともアップデートするモジュール及びインストールシェルスクリプトを含むモジュールアップデート指示メールを送信し、監視装置１それぞれに一括して、監視装置１内の各モジュール個別及び監視装置１全体のバージョン情報の取得を要求するバージョン情報取得要求メールを送信し、監視装置１それぞれから取得要求の返信としてバージョン情報をメールで受信するので、ホスト６が管理下に置く複数の監視装置１の装置内のモジュールを、遠隔操作により一括してアップデートすることが可能となる。これにより、従来のようなアップデート対象の監視装置１台ずつに対しコネクションを張りアップデート処理を行うという膨大な作業が不要となる。

また、ホスト６はモジュールのアップデートの指示を実行後、バージョン情報の取得要求及びバージョン情報の取得を実行し、アップデート後にとるべきバージョンと取得したバージョン情報とを比較し、モジュールのアップデート処理の成否を確認するので、遠隔操作による管理下にある監視装置１の装置内のモジュールアップデートの成否を自動的に判定することが可能となる。これにより、監視装置１におけるアップデートの状況を的確に管理することが可能となる。

上記本発明の実施の形態では、デバイス遠隔監視システムを図１に示す構成としたが、本発明はこれに限定されるものではなく、監視装置、センタ側管理サーバ、拠点側管理サーバ、デバイス等の設置台数、ネットワークの設置形態、監視対象とするデバイスの種類は任意とすることが可能である。

また、本発明の目的は、上述した実施の形態の機能を実現するソフトウェアのプログラムコードを記録した記憶媒体を、システム或いは装置に供給し、そのシステム或いは装置のコンピュータ（またはＣＰＵやＭＰＵ等）が記憶媒体に格納されたプログラムコードを読み出して実行することによっても達成されることはいうまでもない。

この場合、記憶媒体から読み出されたプログラムコード自体が前述した実施の形態の機能を実現することになり、そのプログラムコード及び該プログラムコードを記憶した記憶媒体は本発明を構成することになる。

また、プログラムコードを供給するための記憶媒体としては、例えば、ＲＡＭ、フロッピー（登録商標）ディスク、ハードディスク、光ディスク、光磁気ディスク、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、ＣＤ−ＲＷ、ＤＶＤ−ＲＯＭ、ＤＶＤ−ＲＡＭ、ＤＶＤ−ＲＷ、ＤＶＤ＋ＲＷ、磁気テープ、不揮発性のメモリカード、ＲＯＭ、ＥＥＰＲＯＭ等を用いることができる。または、プログラムコードをネットワークを介してダウンロードしてもよい。

また、コンピュータが読み出したプログラムコードを実行することにより、上記実施の形態の機能が実現されるだけでなく、そのプログラムコードの指示に基づき、コンピュータ上で稼動しているＯＳ（オペレーティングシステム）等が実際の処理の一部または全部を行い、その処理によって前述した実施の形態の機能が実現される場合も含まれることはいうまでもない。

更に、記憶媒体から読み出されたプログラムコードが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書き込まれた後、そのプログラムコードの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵ等が実際の処理の一部または全部を行い、その処理によって前述した実施の形態の機能が実現される場合も含まれることはいうまでもない。

以上説明したように、本発明によれば、監視装置は管理装置からアップデートするモジュールを受信した場合、作動中の監視装置内のモジュールを受信したモジュールにアップデートし、管理装置からバージョン情報の取得要求を受信した場合、バージョン情報を収集し管理装置に返信するので、監視装置が管理装置からの遠隔操作により監視装置内のモジュールのアップデートを効率よく行うことが可能となる。これにより、従来のように、管理装置がアップデート対象の監視装置１台ずつと通信可能に接続してアップデート処理を行うという膨大な作業を不要とすることができる。

本発明の実施の形態に係る監視装置と管理装置とを備えるデバイス遠隔監視システムの全体構成例を示す概念図である。 図１における監視装置のハードウェア構成を示すブロック図である。 監視装置が実行する障害情報確認処理のフローチャートである。 図３におけるステップＳ３０４の応答確認処理のフローチャートである。 監視装置が実行するカウンタ情報取得処理のフローチャートである。 監視装置の実行するカウンタ情報送信処理のフローチャートである。 図１におけるデバイスの一例としての画像形成装置の全体を制御するコントローラの構成を示すブロック図である。 図７の画像形成装置のソフトウェア構成を示す図である。 監視装置が実行するメール受信処理のフローチャートである。 図１における管理装置から送信されるモジュールアップデート指示コマンドメールに添付されるデータの形式を示す図である。 図９のメール受信処理におけるコマンド処理プログラムの起動に応じて実行されるコマンド処理としてのアップデートコマンド処理のフローチャートである。 図９のメール受信プログラムにおけるコマンド処理プログラムの起動に応じて実行されるコマンド処理として実行されるバージョン収集処理のフローチャートである。 図１２のバージョン収集処理プログラムにより生成したバージョン情報の印刷例を示す図である。 監視装置のモジュールを一括アップデートする一括アップデート処理のフローチャートである。 図１４の一括アップデート処理におけるアップロード処理開始前の図１におけるセンタ側ＰＣの画面を示す図である。 一括アップデート処理におけるアップロード結果が表示された図１におけるセンタ側ＰＣの画面を示す図である。

符号の説明

１ 監視装置
２ 拠点側管理サーバ
３、４、５ デバイス
６ センタ側管理サーバ（指示手段、取得要求手段、取得手段、成否確認手段）
７ センタ側クライアントＰＣ
８ 通信回線
９ ＬＡＮ
１０ 通信プロトコル
１１ データベース
２０１ ＣＰＵ（処理手段、情報収集手段）
２０５、２０６ ネットワークＩ／Ｆ（返信手段、受信手段）

Claims (18)

1. 監視対象とする少なくとも１つの画像形成装置から通信により情報を取得すると共に管理装置と通信可能な監視装置であって、
   前記管理装置との間で電子メールによる通信を行う電子メール手段と、
   前記管理装置から電子メールにより、前記監視装置が作動する第１のモジュールをアップデートするための第２のモジュールを前記電子メール手段が受信したことに応じて自動的に作動中の前記第１のモジュールを前記受信した第２のモジュールにアップデートする処理手段と、
   前記管理装置から電子メールにより前記第１のモジュールのバージョン情報の取得要求を前記電子メール手段が受信した場合、前記バージョン情報を収集する情報収集手段と、
   前記情報収集手段により収集した前記バージョン情報を電子メールにより前記管理装置に返信する返信手段と、を有することを特徴とする監視装置。
2. 更に、前記管理装置から、少なくとも前記第２のモジュール及びインストールスクリプトを含むアップデート指示電子メールと、前記監視装置内の各第１のモジュール個別のバージョン及び前記監視装置全体のバージョンを示す前記バージョン情報の取得を要求する取得要求電子メールとを受信する受信手段を有し、
   前記処理手段は、前記受信手段により受信した前記アップデート指示電子メールに含まれる前記インストールスクリプトを起動し、作動中の前記第１のモジュールを前記受信手段により受信した前記アップデート指示電子メールに含まれる前記第２のモジュールにアップデートし、前記情報収集手段は、前記受信手段により受信した前記取得要求電子メールに応じて、前記バージョン情報を収集し、前記返信手段は、前記情報収集手段により収集した前記バージョン情報を前記管理装置に電子メールで返信することを特徴とする請求項１に記載の監視装置。
3. 前記電子メール手段が受信した電子メールの内容を解読する解読手段を有し、前記処理手段は、前記解読手段による前記受信した電子メールの内容の解読により前記管理装置からの前記第１のモジュールのアップデートの指示を解釈し、該解釈した電子メールの内容に応じた処理を行うことを特徴とする請求項１に記載の監視装置。
4. 監視対象とする複数の画像形成装置から通信により情報を取得する複数の監視装置を管理下に置くことが可能な管理装置であって、
   前記複数の監視装置それぞれに一括して前記複数の監視装置それぞれが作動する第１のモジュールの第２のモジュールへのアップデートを電子メールを用いて指示する指示手段と、
   前記複数の監視装置それぞれに一括して前記第１のモジュールのバージョン情報の取得要求を電子メールにより行う取得要求手段と、
   前記複数の監視装置それぞれから前記バージョン情報を前記取得要求手段の行う前記バージョン情報の取得要求のための電子メールの返信として取得する取得手段と、を有することを特徴とする管理装置。
5. 前記指示手段は、前記複数の監視装置それぞれに一括して、少なくとも前記複数の監視装置それぞれの第１のモジュールをアップデートするための前記第２のモジュール及びインストールスクリプトを含むアップデート指示電子メールを送信し、前記取得要求手段は、前記複数の監視装置それぞれに一括して、前記監視装置内の各モジュール個別のバージョン及び前記監視装置全体のバージョンを示す前記バージョン情報の取得を要求する取得要求電子メールを送信し、前記取得手段は、前記複数の監視装置それぞれから、前記取得要求手段が送信する取得要求電子メールの返信として前記バージョン情報を受信することを特徴とする請求項４に記載の管理装置。
6. 前記指示手段の前記第１のモジュールの前記第２のモジュールへのアップデートの指示に基づく前記第１のモジュールのアップデート後にとるべきバージョンのバージョン情報と、前記取得手段により取得した前記バージョン情報とを比較し、前記第１のモジュールに対するアップデート処理の成否を確認する成否確認手段を有することを特徴とする請求項４に記載の管理装置。
7. 前記指示手段は、前記成否確認手段により前記第１のアップデートモジュールに対するアップデート処理が失敗と確認された監視装置に対して一括して再度前記第１のモジュールのアップデートの指示を行なうことを特徴とする請求項６に記載の管理装置。
8. 前記第１のモジュールのアップデート後にとるべきバージョンのバージョン情報は、前記監視装置全体のバージョンを示す第２のバージョン情報であり、前記第２のバージョン情報は前記監視装置の個別の各第１のモジュールの組合せに対応することを特徴とする請求項６に記載の管理装置。
9. 監視対象とする少なくとも１つの画像形成装置から通信により情報を取得すると共に管理装置と通信可能な監視装置による制御方法であって、
   前記管理装置との間で電子メールによる通信を行う通信ステップと、
   前記管理装置から電子メールにより前記監視装置が作動する第１のモジュールをアップデートするための第２のモジュールを前記通信ステップにおいて受信したことに応じて自動的に作動中の前記第１のモジュールを前記受信した第２のモジュールにアップデートする処理ステップと、
   前記管理装置から電子メールにより前記第１のモジュールのバージョン情報の取得要求を前記通信ステップにおいて受信した場合、前記バージョン情報を収集する情報収集ステップと、
   前記情報収集ステップにより収集した前記バージョン情報を電子メールにより前記管理装置に返信する返信ステップと、を有することを特徴とする制御方法。
10. 更に、前記管理装置から、少なくとも前記第２のモジュール及びインストールスクリプトを含むアップデート指示電子メールと、前記監視装置内の各モジュール個別のバージョン及び前記監視装置全体のバージョンを示す前記バージョン情報の取得を要求する取得要求電子メールとを受信する受信ステップを有し、
    前記処理ステップは、前記受信ステップにおいて受信した前記アップデート指示電子メールに含まれるインストールスクリプトを起動し、作動中の前記第１のモジュールを前記受信ステップにおいて受信した前記アップデート指示メールに含まれる第２のモジュールにアップデートし、前記情報収集ステップは、前記受信ステップにより受信した前記取得要求電子メールに応じて、前記バージョン情報を収集し、前記返信ステップは、前記情報収集ステップにおいて収集した前記バージョン情報を前記管理装置に電子メールで返信することを特徴とする請求項９に記載の制御方法。
11. 前記通信ステップにおいて受信した電子メールの内容を解読する解読ステップを有し、前記処理ステップは、前記解読ステップにおける前記受信した電子メールの内容の解読により前記管理装置の指示を解釈し、該解釈した電子メールの内容に応じた処理を行うことを特徴とする請求項９に記載の制御方法。
12. 監視対象とする複数の画像形成装置から通信により情報を取得する複数の監視装置を管理下に置くことが可能な管理装置による制御方法であって、
    前記複数の監視装置それぞれに一括して前記複数の監視装置それぞれが作動する第１のモジュールの第２のモジュールへのアップデートを電子メールを用いて指示する指示ステップと、
    前記複数の監視装置それぞれに一括して前記第１のモジュールのバージョン情報の取得要求を電子メールにより行う取得要求ステップと、
    前記複数の監視装置それぞれから前記バージョン情報を前記取得要求ステップにおける前記バージョン情報の取得要求のための電子メールの返信として取得する取得ステップと、を有することを特徴とする制御方法。
13. 前記指示ステップは、前記複数の監視装置それぞれに一括して、少なくとも前記複数の監視装置それぞれの第１のモジュールをアップデートするための前記第２のモジュール及びインストールスクリプトを含むアップデート指示電子メールを送信し、前記取得要求ステップは、前記複数の監視装置それぞれに一括して、前記監視装置内の各モジュール個別のバージョン及び前記監視装置全体のバージョンを示す前記バージョン情報の取得を要求する取得要求電子メールを送信し、前記取得ステップは、前記複数の監視装置それぞれから、前記取得要求ステップにおいて送信する取得要求電子メールの返信として前記バージョン情報を受信することを特徴とする請求項１２に記載の制御方法。
14. 前記指示ステップにおける前記第１のモジュールの前記第２のモジュールへのアップデートの指示に基づく前記第１のモジュールのアップデート後にとるべきバージョンのバージョン情報と前記取得ステップにより取得した前記バージョン情報とを比較し、前記第１のモジュールに対するアップデート処理の成否を確認する成否確認ステップを有することを特徴とする請求項１２に記載の制御方法。
15. 前記指示ステップは、前記成否確認ステップにより前記第１のモジュールに対するアップデート処理が失敗と確認された監視装置に対して一括して再度前記アップデートを行なうことを特徴とする請求項１２に記載の制御方法。
16. 前記第１のモジュールのアップデート後にとるべきバージョンは、前記監視装置全体のバージョンを示す第２のバージョン情報であり、前記第２のバージョン情報は前記監視装置の個別の各モジュールの組合せに対応することを特徴とする請求項１５に記載の制御方法。
17. 監視対象とする少なくとも１つの画像形成装置から通信により情報を取得すると共に管理装置と通信可能な監視装置による制御方法をコンピュータに実行させるプログラムであって、前記制御方法は、
    前記管理装置との間で電子メールによる通信を行う通信ステップと、
    前記管理装置から電子メールにより前記監視装置が作動する第１のモジュールをアップデートするための第２のモジュールを前記通信ステップにおいて受信したことに応じて自動的に作動中の前記第１のモジュールを前記受信した第２のモジュールにアップデートする処理ステップと、
    前記管理装置から電子メールにより前記第１のモジュールのバージョン情報の取得要求を前記通信ステップにおいて受信した場合、前記バージョン情報を収集する情報収集ステップと、
    前記情報収集ステップにより収集した前記バージョン情報を電子メールにより前記管理装置に返信する返信ステップと、を有することを特徴とするプログラム。
18. 監視対象とする複数の画像形成装置から通信により情報を取得する複数の監視装置を管理下に置くことが可能な管理装置による制御方法をコンピュータに実行させるプログラムであって、前記制御方法は、
    前記複数の監視装置それぞれに一括して前記複数の監視装置それぞれが作動する第１のモジュールの第２のモジュールへのアップデートを電子メールを用いて指示する指示ステップと、
    前記複数の監視装置それぞれに一括して前記第１のモジュールのバージョン情報の取得要求を電子メールにより行う取得要求ステップと、
    前記複数の監視装置それぞれから前記バージョン情報を前記取得要求ステップにおける前記バージョン情報の取得要求のための電子メールの返信として取得する取得ステップと、を有することを特徴とするプログラム。

Images