JP2009199400A - 管理サーバ、データ処理方法、プログラム - Google Patents

Abstract

【課題】 管理サーバがデバイス監視装置へ送信した処理コマンドの処理結果が取得できなかった場合であっても、次のデバイス監視装置からのコマンドの問い合せを利用して取得する前回の処理コマンドの処理結果に基づく適切な処理を可能とすることである。
【解決手段】
管理サーバ１０６がデバイス監視モジュール１０２Ａに送信した処理コマンドによる処理結果を受信できなかった場合、デバイス監視モジュール１０２Ａからの新たにコマンド取得の要求を受信する。この際、管理サーバ１０６は該新たなコマンド取得の要求の応答として、処理結果を受信できなかった処理コマンドの処理結果を判断するためにデバイス監視モジュール１０２Ａの設定情報を要求するコマンドを送信する（Ｓ２２３）ことを特徴とする。
【選択図】 図２

Description

本発明は、ネットワーク通信を用いたプリンタや複写機、複合機などのデバイスを管理するデバイス管理システムにおけるデバイス管理方法及び管理サーバに関するものである。

従来から、インターネット上に管理サーバを設置し、ネットワークを介して顧客先のデバイスを管理するメンテナンスシステムが知られている。

この従来のメンテナンスシステムでは、例えば、デバイスステータスやプリント枚数等の情報は、デバイスを監視するデバイス監視装置から送信される情報を収集して、デバイスの管理を行っていた。

この場合、デバイスを管理する上で必要な情報は、デバイス監視装置の設置時に、サービスマンが設定を行う。

デバイス監視装置は顧客のファイアウォール（ＦＷ）内に設置され、設定されたスケジュールやプログラムの条件に従って情報送信することによって収集を行っていた。

また、デバイスの特別な情報を一時的に取得したい場合や、デバイス監視装置の設定情報を更新したい場合に備えて、デバイス監視装置は定期的に管理サーバに対して、コマンド処理がないか問い合わせの通信を行わせていた。

管理者はデバイス管理サーバに特別な処理を走らせたい場合には、管理サーバにコマンドを発行し、管理サーバはそのコマンド処理問い合わせのレスポンスにて、コマンドを送信し処理を実行させていた。

最近では、デバイス自体にデバイスを監視するプログラムを走らせるケースもあり、以後、デバイス監視装置及び監視プログラムを有するデバイスなどをデバイス監視モジュールという言葉で説明する。

管理サーバは、処理コマンドをデバイス監視モジュールへ送信した後、管理サーバ側から顧客先のＦＷ内への通信を開始する事ができない。

よって、デバイス監視モジュールから何らかの理由で処理結果が返されなかった場合に、デバイス監視モジュールのステータスがわからなくなってしまうという問題がでてきた。

例えば、障害解析の手法として特許文献１がある。特許文献１では、アプリケーションプロセスを監視し、障害が発生する箇所を明確化し、アプリケーション上で同じプロセスを使用しないことで障害を回避する技術が開示されている。
特開平８−３０４７６号公報

ここで、上記なような課題を本発明のシステムに関して具体的に説明する。

まず、管理サーバがデバイス監視モジュールに対し、監視対象のデバイスの情報の送信スケジュールを変更するための処理コマンドを送信したとする。

デバイス監視モジュールは、自身の通信スケジュールを変更し、処理コマンドが成功したことを管理サーバに返すときに、一時的な通信障害が発生し、管理サーバと通信できなくなったとする。管理サーバでは、処理結果をデバイス監視モジュールから受信する事ができないので、処理コマンドの本当の処理結果に関わらず、異常終了をデバイス管理者に通知してしまうという問題があった。

また、上記のような障害が発生した場合には、継続して他の処理コマンドをデバイス監視モジュールに送信したいとき、本来であれば送信できる処理コマンドも途中で中断してデバイス管理者に障害解析を依頼する必要があった。

このような場合、特許文献１のように障害の内容や要因を解析することが考えられるが、処理結果が受信できないなど、解析する材料が少なく困難である。

このように、デバイス監視モジュールと管理サーバ間の処理コマンドと結果のやり取りの中では、問題のあるコマンドの特定が困難で、予め回避することは難しい。

本発明は、上記の課題を解決するためになされたもので、本発明は、管理サーバがデバイス監視装置へ送信した処理コマンドの処理結果が取得できなかった場合であっても、次のデバイス監視装置からのコマンドの問い合せを利用して取得する前回の処理コマンドの処理結果に基づく適切な処理が可能な手法を提供することを目的とする。

上記目的を達成する本発明の情報処理装置は以下に示す構成を備える。

ファイアウォール内のデバイス監視装置とインターネットを介して通信可能なファイアウォール外に設置された管理サーバであって、前記デバイス監視装置への処理コマンドを記憶する記憶手段と、前記デバイス監視装置からのコマンド取得の要求を受信する受信手段と、前記受信手段により受信した要求の応答として、前記記憶手段に記憶された処理コマンドを送信するコマンド送信手段とを備え、前記コマンド送信手段により送信した処理コマンドによる処理結果を受信できなかった場合、前記受信手段が前記デバイス監視装置からの新たにコマンド取得の要求を受信した際に、前記コマンド送信手段は該新たなコマンド取得の要求の応答として、処理結果を受信できなかった前記処理コマンドの処理結果を判断するためにデバイス監視装置の設定情報を要求するコマンドを送信することを特徴とする。

本発明によれば、管理サーバがデバイス監視装置へ送信した処理コマンドの処理結果が取得できなかった場合であっても、次のデバイス監視装置からのコマンドの問い合せを利用して取得する前回の処理コマンドの処理結果に基づく適切な処理が可能となる。

次に本発明を実施するための最良の形態について図面を参照して説明する。

＜システム構成の説明＞
〔第１実施形態〕
図１は、本発明の実施形態を示す管理システムの構成を説明するブロック図である。なお、管理サーバがインターネットを介してイントラネット環境内のデバイスを監視するデバイス監視装置と通信する管理システムの例である。また、本例は、デバイスとしてプリンタや複写機、複合機などを例とするが、これらに限定されるものではない。

また、デバイス監視装置という場合には、上記デバイスを監視するデバイス監視装置を監視する装置を含むものとする。さらに、管理サーバは、ファイアウォール内のデバイスを監視するデバイス監視装置と通信可能に構成され、管理サーバは、ファイアウォール外に設けられている。

図１において、１０８は顧客のイントラネット環境を示している。イントラネット環境１０８内には、インターネット１１０との接続ポイントであるファイアウォール１０５が設置されている。また、外部へのＨＴＴＰやＨＴＴＰＳ通信を１台のマシンがコントロールできるようにプロキシサーバ１０４が設置されている。

１０１はデバイスで、顧客のネットワークに設置されたＭＦＰ（Ｍｕｌｔｉ Ｆｕｎｃｔｉｏｎ Ｐｒｉｎｔｅｒ）やＳＦＰ（Ｓｉｎｇｌｅ Ｆｕｎｃｔｉｏｎ Ｐｒｉｎｔｅｒ）を示している。これらプリント・複写などの機能をもつ機器の事をここではデバイスと呼ぶ。

デバイス１０１は、ネットワーク内に１台でも、複数台あってもよい。

１０２はデバイス監視装置で、デバイス１０１のステータス監視を行うデバイス監視モジュール１０２Ａを備える。

デバイス監視装置１０２は、デバイス１０１のステータス情報を取得し、外部の管理サーバ１０６へ送信を行う。デバイス監視モジュール１０２Ａは、デバイス監視を行うソフトウェアプログラムなので、デバイスに組み込む形態でも、ＰＣや専用のハードに組み込まれる形態で存在してもかまわない。

１０３はクライアントＰＣで、一般のユーザが業務等で使用するパーソナルコンピュータ（ＰＣ）で構成される。１１０はインターネットを示しており、イントラネット環境１０８に類似した別顧客のネットワークが無数に接続されている。１００はローカルエリアネットワーク（ＬＡＮ）である。

１０６は管理サーバで、インターネット１１０上に設置され各顧客のネットワークに設置されているデバイス監視モジュールと通信を行う事によって、デバイスの情報を収集し、データベース（ＤＢ）１０６Ａで管理している。

ここで、管理サーバ１０６の収集するデバイスの情報とは、デバイスの動作モード設定や、カウンタ値、稼動ログ、各パーツの使用度合いを表すカウンタ値などの稼動情報、及びハード障害やジャム等の障害情報である。

また、管理サーバ１０６は、各デバイスに対して設定情報の更新やリブートなどのコマンド指示を行う。この際の通信手段としては、ＨＴＴＰやＨＴＴＰＳなどのプロトコルを介したＳＯＡＰを利用した通信などがある。

また、通信手段に関しては、管理サーバ１０６とデバイスとの間で通信ができればいいので、ＨＴＴＰやＨＴＴＰＳに限定するものではない。

例えば、図１の例では、デバイス監視モジュールは監視対象であるデバイスの情報を取得し、ＨＴＴＰＳを利用してプロキシサーバ１０４とファイアウォール１０５を介して、管理サーバ１０６にデータを送信している。

管理サーバ１０６は、デバイス監視モジュール及びデバイスを制御するために、デバイス監視モジュールに対してコマンドを発行する。１０７はデバイス管理者ＰＣで、ネットワークを介して管理サーバ１０６と所定のプロトコルで通信を行い、管理サーバ１０６が管理すべきデバイスの追加の指示を含む各種の指示を行う。管理サーバ１０６には、記憶装置で構成されるデータベース１０６Ａを備え、データベース１０６Ａは、デバイス監視装置１０２に対する処理コマンドを記憶する領域が確保されている。

＜本実施形態の通信シーケンスの概略＞
図２は、図１に示したデバイス監視モジュール１０２Ａと管理サーバ１０６とデバイス管理者のＰＣと間の通信シーケンス例の一部を表した図である。なお、Ｓ２０１〜Ｓ２２８は通信シーケンスを示す。

なお、図２では、デバイス管理者のＰＣ１０７から管理サーバ１０６に対して、Ｓ２０５で、「監視対象デバイスの追加」が指示され、管理サーバ１０６からデバイス監視モジュール１０２Ａに対して、Ｓ２１０で、「監視対象デバイスの追加」の指示を行う例を示す。また、Ｓ２１８で、「設定情報の要求」を管理サーバ１０６からデバイス監視モジュール１０２Ａに行う例を示す。

しかしながら、これは通信シーケンスの概略の説明であって、実際は、これに限定されない。

Ｓ２０１は、デバイス監視モジュール１０２Ａの通常スケジュール通信の一種で、コマンド取得通信を表している。

デバイス監視モジュール１０２Ａは、デバイス１０１から取得したステータス情報を管理サーバ１０６へ送信しているが、その他に管理サーバ１０６に対して定期的、または非定期に通信してデバイス監視モジュール１０２Ａに対して指示要求がないかを確かめる。

Ｓ２０２は、コマンド取得要求を受信した管理サーバ１０６が、デバイス監視モジュール１０２Ａの認証を行い、送信すべきコマンドが存在しないかの確認する処理を表している。

管理サーバ１０６は、デバイス監視モジュール１０２Ａに送信すべき指示がないことを確認する。そして、管理サーバ１０６は、Ｓ２０３のｈｔｔｐ ｒｅｓｐｏｎｓｅで、コマンドがないことを表す応答をＳ２０４でデバイス監視モジュール１０２Ａに送信する。

Ｓ２０５は、デバイス管理者のＰＣ１０７が管理サーバ１０６を通じて、デバイス監視モジュール１０２Ａに、新しい監視対象であるＤｅｖｉｃｅ Ａを登録する、監視対象デバイス登録の指示を表している。

ここでは、対象となるデバイス監視モジュールの識別ＩＤや、デバイス監視モジュールがデバイスを監視するために必要な、デバイスの識別ＩＤが登録される。さらに、ＩＰ Ａｄｄｒｅｓｓ情報、その他オプション情報なども登録される。

管理サーバ１０６は、Ｓ２０５によって、ＰＣ１０７から受信した監視対象デバイス登録指示をＳ２０６にて、データベース１０６Ａに登録し、対象のデバイス監視モジュールからコマンド取得要求の通信を待つ。

管理サーバ１０６は、Ｓ２０７によって、再びデバイス監視モジュール１０２Ａからコマンド取得要求を受信すると、Ｓ２０８にて、デバイス監視モジュール１０２Ａの認証を行う。

その後、データベース１０６Ａ内に記憶していた監視対象のデバイスを登録する処理コマンドをＳ２０９で、管理サーバ１０６は、ｈｔｔｐ ｒｅｓｐｏｎｓｅとしてデバイス監視モジュール１０２Ａに送信する（Ｓ２１０）。

また、管理サーバ１０６は、上記Ｓ２１０に対応する指示を送信したときに、デバイス監視モジュール１０２Ａから処理結果を受信することを予想するので、タイマをセットする。

これは、デバイス監視モジュール１０２Ａで何か障害が発生したときに、通常の監視処理さえ行わなくなってしまう場合に、サービスマンへ通知し、トラブルシュートを行う必要があるためである。

デバイス監視モジュール１０２Ａは、Ｓ２１０にて、管理対象デバイス登録の指示を管理サーバ１０６から受信すると、Ｓ２１１にて監視デバイスリストの設定更新を行う。

次に、Ｓ２１２にて、無事に設定更新処理が完了すると、デバイス監視モジュール１０２Ａは、問題なく処理が完了したことを伝える。そして、Ｓ２１３は、コマンド処理結果を管理サーバ１０６に送信することを表している。

しかし、このとき、図中ではデバイス監視モジュール１０２Ａと管理サーバ１０６間で通信障害等の原因で一時的に通信ができなくなってしまう事を仮定している。

管理サーバ１０６では、デバイス監視モジュール１０２Ａから処理結果を受信するために、タイマを設定しており、障害等で規定時間内に処理結果を受信できなかった場合には、処理に問題があったことを検知する。

ここで、処理結果がデバイス監視モジュール１０２Ａから返ってこなかったことには２つの要因が考えられる。

１つの要因は、処理途中で、プログラムのバグ等により処理が停止してしまっているとき。もう１つの要因は、処理が正常に終了しているが、処理結果を管理サーバ１０６に通知できなかったときである。

ここでは、管理サーバ１０６がどちらの状態になっているかを切り分けるために、前回指示に対応したコマンドを、管理サーバ１０６がデバイス監視モジュール１０２Ａに対して発行する。

前回の指示コマンドは、監視対象のデバイス登録指示だったので、デバイス監視モジュール１０２Ａの設定情報を出力させ、登録処理を行ったＤｅｖｉｃｅ Ａが登録されているか確認を行う。

Ｓ２１４で、管理サーバ１０６は、上記タイマのタイムアウトを検知すると、前回コマンド指示の内容から、デバイス監視モジュール１０２Ａの設定送信指示を発行する。また、発行した処理コマンドをデータベース１０６Ａに保管する。

一方、Ｓ２１３の通信時に発生した障害が一時的なものであった場合、デバイス監視モジュール１０２Ａは、Ｓ２１５にてコマンド取得通信を行う。ここで、実際にデバイス監視モジュール１０２Ａで処理が停止する障害が発生していた場合、Ｓ２１５の通信は送信されないので、タイムアウト等を利用して、ＰＣ１０７のデバイス管理者へ通知を行う必要があるが、ここでは説明を省略する。

管理サーバ１０６は、Ｓ２１５にてコマンド取得通信を受信すると、Ｓ２１６にて認証を行い、データベース１０６Ａ内にコマンドの有無を確認する。

このときに、Ｓ２１４にて発行した設定送信指示がデータベース１０６Ａ内にあるので、この設定送信指示をＳ２１７でｈｔｔｐ ｒｅｓｐｏｎｓｅとして送信する。

この送信設定指示を意味するＳ２１８の通信をデバイス監視モジュール１０２Ａが受信すると、Ｓ２１９にて設定情報を出力して送信準備を行う。

デバイス監視モジュール１０２Ａは、Ｓ２２０にて、設定情報を管理サーバ１０６へ送信する。

Ｓ２２１にて管理サーバ１０６は、デバイス監視モジュール１０２Ａの設定情報を受信する。このときに、前回コマンド指示のデバイス登録処理が無事に処理されているかを判断し、登録されていれば、デバイス管理者のＰＣ１０７がＳ２０５にて設定した監視デバイス登録の処理が無事に成功したと判断する。

また、Ｓ２２２にて、管理サーバ１０６はｈｔｔｐ ｒｅｓｐｏｎｓｅ（内容ｎｕｌｌ）を生成して、Ｓ２２３で、デバイス監視モジュール１０２Ａに返す。Ｓ２２３の通信レスポンスを受信したデバイス監視モジュール１０２ＡはＳ２２４にて、設定情報送信処理の成功した事を送信するための準備を行う。

Ｓ２２５にて、デバイス監視モジュール１０２Ａは管理サーバ１０６に対して処理結果を送信する。Ｓ２２６にて、管理サーバ１０６は処理が正常に完了したことを受信し、Ｓ２２７で、レスポンスを生成し、Ｓ２２８で、デバイス監視モジュール１０２Ａへ送信する。

＜本実施形態の管理サーバの構成例＞
図３は、図１に示した管理サーバ１０６のハードウェア構成例を示すブロック図である。

なお、管理サーバ１０６は汎用のコンピュータ等で構成される。

図３に示す管理サーバ１０６において、３０２は全体を制御するためのＣＰＵである。３０３はＲＯＭで、システム起動に必要なブートプログラムを記憶するための読み出し専用メモリである。３０１は内部バスで、ＣＰＵ３０２と他のデバイスとを接続する。

３０４はＲＡＭで、ＣＰＵ３０２でプログラムを実行する際に必要とされる作業メモリとして機能する。

３０５はＮｅｔｗｏｒｋ Ｉ／Ｆで、Ｎｅｔｗｏｒｋ上で通信を行う。３０６は表示制御部で、ディスプレイ３０９にデバイス監視モジュールとの通信内容等を表示するための表示制を行う。

３０７は入力制御部で、管理サーバ１０６を管理するオペレータが操作する入力デバイス３１０、３１１からの入力を制御する。

３０８は記憶装置で、ＣＰＵ３０２で実行するプログラムや、デバイス監視モジュール１０２Ａから送られた各デバイスの稼働情報などを格納する。記憶装置３０８は、磁気ディスク等の外部記憶装置で構成され、上述したデータベース１０６Ａとしても機能する記憶領域が確保されている。

管理サーバ１０６は、デバイス監視モジュール１０２Ａからの定期的な稼働情報通知や不定期的な異常状態の通知、コマンドリクエストをＮｅｔｗｏｒｋ Ｉ／Ｆ３０５を介して常時受けている。

又、デバイス管理者のＰＣ１０７から管理サーバ１０６への設定変更や動作要求などのコマンド入力は、入力制御部３０７を介して常時受け付けている。

定期的に通知される稼働情報には、各種カウンタ値や稼働ログなどが含まれており、管理サーバ１０６は稼動情報を基にデバイスを所有している顧客に対して毎月請求する定期メンテナンス料を算出する。

又、デバイスに使用されているパーツが推奨寿命に対してどのくらい消耗しているのかをレポートの形で出力する。

管理サーバ１０６はこの稼働情報を記憶装置３０８に逐次格納する一方、オペレータは格納された稼働情報を適宜参照して顧客への請求額を決定する処理を行う。

不定期的に通知されるデバイスの異常状態を表す情報には、稼働情報に加えて、発生したハード障害やジャムなどのエラー／アラーム情報が含まれている。

管理サーバ１０６はこの情報を受け取ると、情報の緊急度に基づいて処理を決定する。例えば管理サーバ１０６が受け取った情報が、デバイスの故障など、デバイスが異常状態を表すものであり、すぐに復旧させる必要のある障害情報だった場合には、通知処理を行う。具体的には、その対象のデバイスを管理しているオペレータに電子メールでその旨を送信する。

さらに記憶装置３０８に逐次格納すると共にディスプレイ３０９上に表示することで、デバイスが異常状態に陥っている旨をオペレータに通知する。

一方、管理サーバ１０６が受け取った情報がジャムやアラームのように緊急度が低い場合には、記憶装置３０８に逐次格納し、電子メールの送信が必要かどうか、ディスプレイ３０９に表示させる必要があるかどうかそのときの障害に応じて処理を行う。

オペレータは、ディスプレイ３０９上の表示内容からデバイスの状態を判断し、必要に応じて障害復旧作業をサービスマンに指示をする。

管理サーバ１０６は、デバイス監視モジュール１０２Ａからのコマンド取得通信を、任意のタイミングで常時受け付ける。管理サーバ１０６はコマンド取得通信を受ける毎に、管理サーバ１０６内の記憶装置３０８を確認し、デバイス監視モジュール１０２Ａへの送信すべきコマンドが設定されていたら、デバイス監視モジュール１０２Ａへコマンドを送信する。

デバイス監視モジュール１０２Ａへコマンドを送信すると、ステータスを「処理中」へ変更する。また同じタイミングでタイマの設定を行う。

管理サーバ１０６は、タイマがタイムアウトした場合や、「処理中」のステータス時に、デバイス監視モジュールからコマンド取得通信を受信すると、ステータスを「不明」に変更し、前回コマンドが処理されたか処理されなかったかを確認するコマンドを発行する。

＜本実施形態の管理サーバのソフトウエア構成例＞
図４は、図１に示した管理サーバ１０６における、デバイス監視モジュール１０２Ａへのコマンド処理の確認を行うアプリケーションプログラムの機能を示すブロック図である。

図４において、アプリケーションプログラムは、デバイス管理者からデバイス監視モジュール１０２Ａへのコマンド指示入力を受け付ける指示入力部４０３を有する。

指示入力部４０３では、指示に伴う設定情報を入力でき、例えば、デバイス監視モジュール１０２Ａに新規監視対象デバイスを登録したい場合には、デバイスの識別ＩＤや、ＩＰ Ａｄｄｒｅｓｓその他オプション情報の入力が行われる。ここで、デバイス監視モジュール１０２Ａに新規監視対象デバイスを登録したい場合、デバイス管理者のＰＣ１０７より指示が入力される。

４０２は指示情報ＤＢ入出力部で、アプリケーションプログラムは、入力の行われたコマンド指示を、指示情報保管部４０１へ保管処理する。４０４は通信Ｉ／Ｆで、デバイス監視モジュール１０２Ａとの通信を行う。

４０７は通信コマンド解釈部で、デバイス監視モジュール１０２Ａから受信したデータから識別ＩＤや通信コマンドをデータとして取り出す。又、通信コマンド解釈部４０７は、デバイス監視モジュール１０２Ａへ送信するデータを通信用フォーマットへ成型する処理を行う。

４０５は設定指示発行部で、デバイス監視モジュール１０２Ａにコマンド指示を送信する必要があるか、ステータスを「不明」に変更したときに、対象のデバイス監視モジュールに適切なコマンド指示を決定する処理を行う。この設定指示発行部４０５は、通常ステータスのときに、指示情報ＤＢから指示の有無を確認する処理を行う。また、設定指示発行部４０５は、デバイス監視モジュールが「不明」ステータスになった時に、前回コマンド指示の処理がどのように終了したかを確認するためのコマンドを発行する。

４０８は設定ステータス管理部で、アプリケーションプログラムは、通常監視状態にデバイス監視モジュール１０２Ａから受信するステータスを管理する処理を行う。

４０９はステータス保管部で、設定ステータス管理部４０８より受けたステータスをステータス保管部４１０へ入出力を行う。また、４０６は結果表示部で、デバイス管理者のＰＣ１０７へデバイスから取得したステータスデータを表示する処理を行う。

＜管理サーバ１０６の記憶装置の構成例＞
図５は、図３に示した管理サーバ１０６が備えるＲＯＭ３０３又は記憶装置３０８に不揮発的に記憶されるプログラム及びデータの構成例を示す図である。尚、図５には、本実施形態にて用いるプログラム及びデータのみを示し、他は省略している。

図５において、５０１はＯＳ等の装置の基礎的な制御を行うシステムプログラムである。５０２はデバイス管理プログラムで、本管理サーバのデバイス管理全体を制御する。かかるデバイス管理プログラム５０２の本実施形態に関連する部分は、以下に図１０を参照して説明される。

５０３はユーザインタフェース・プログラムで、デバイス管理者からのマスタデータ入力あるいはデバイス状態の表示出力などを制御する。ユーザインタフェース・プログラム５０３は、ユーザからの入力されたデバイス監視モジュール１０２Ａへのコマンド指示を所定のデータベースへ保管する。５０４はユーザ／管理デバイス／認証プログラムで、デバイス監視モジュールを認証する。

５０５はメッセージ送受信プログラムで、デバイス監視モジュール１０２Ａとの間でインターネット１１０を介してコマンドを含むメッセージ送受信を制御する。

５０６は受信コマンド解析プログラムで、デバイス監視モジュール１０２Ａから受信したメッセージに含まれるコマンドを解析して、それに対応する処理の実行を指示する。

５０７は各処理プログラムで、受信コマンド解析プログラム５０６の解析結果に対応して実行される。各処理プログラム５０７は、例えば、コマンドリクエストと解析すればリクエスト送信処理５０８を実行し、設定情報受信と解析すればスケジュール設定情報送信処理５０９を実行する。また、各処理プログラム５０７は、デバイスのステータス受信と解析すればステータス受信処理５１０を実行する。ここには、本実施形態に関連する受信コマンドを示したが。これに限定されない。

５１１はデバイス監視モジュール別ステータスＤＢで、管理サーバ１０６のデータベース１０６Ａで保管するデータベース空間を表す。デバイス監視モジュール別ステータスＤＢ５１１には、デバイス監視モジュール機種基本情報５１２、本実施形態ではデバイス監視モジュールを一意に特定する識別ＩＤ情報５１３が含まれる。

さらに、デバイス監視モジュール別ステータスＤＢ５１１には、管理サーバ１０６がデバイス監視装置１０２へ最後に送信したコマンド送信時刻である最終指示送信時刻５１４、現在指示ステータス５１５が含まれる。

さらに、デバイス監視モジュール別ステータスＤＢ５１１には、その他、デバイス監視モジュールへ最後に送信した前回送信指示記録５１６などが含まれる。

５１７はデバイス監視モジュール別マスタデータＤＢで、管理サーバ１０６のデータベース１０６Ａで保管するデータベース空間を表す。デバイス監視モジュール別マスタデータＤＢ５１７には、本実施形態ではコマンド指示送信先であるデバイス監視モジュールの識別子となるデバイス監視モジュール識別ＩＤ５１８が含まれる。また、デバイス監視モジュール別マスタデータＤＢ５１７には、デバイス監視モジュール１０２Ａの形態やアプリケーションバージョンなどの情報を含むデバイス監視モジュール機種情報５１９が含まれる。また、デバイス監視モジュール別マスタデータＤＢ５１７には、その他、データベースに登録を行ったが、監視を無効にしておくことのできる監視対象有効ステータス５２０、監視対象の送信設定を保存しておく送信設定情報５２１などが含まれる。

図６は、図３に示したＲＡＭ３０４に一時記憶されるデータの構成例を示す図である。尚、図６にも、本実施形態に関連深いプログラム及びデータのみを示し、他は省略している。

図６において、６０１はデバイス監視モジュール識別ＩＤで、デバイス監視モジュール１０２Ａから送信される。６０２は通信入力メソッドで、デバイス監視モジュール１０２Ａから送信される。

６０３は通信入力データで、デバイス監視モジュール１０２Ａから送信される。例えば、メソッドとして、カウンタ種の入力を意味し、入力データ部には、実際のカウンタ番号とカウンタ値が格納される。

６０４は送信指示ステータス判定情報で、デバイス監視モジュール別のステータスをタイマと通信メソッドにより判定した情報として記憶される。

６０５は現在設定情報で、デバイス監視モジュールの処理ステータスが「不明」となった時に、デバイス監視モジュール１０２Ａから受信する。アプリケーションプログラムは、デバイス監視モジュール１０２Ａから設定情報のメソッドを受信すると、前回のコマンド指示が正常に処理されていた場合の設定情報を予測する。そして、アプリケーションは、予測情報と受信した現在の設定情報を比較する事で、前回送信したコマンド指示が処理されたのか、処理されていないのかを判定する。６０６は指示送信後設定情報である。

６０７はプログラムロード領域で、図３に示したプログラムをＣＰＵ３０２が実行するためプログラムをロードする記憶領域である。

＜管理サーバからの通信データの構成例＞
図７は、図１に示した管理サーバ１０６からデバイス監視モジュール１０２Ａへ送信されるコマンド指示情報２１０を模式的に表した図である。

図７において、７０１は、管理サーバが受信したスケジュール情報リクエストに対応したＲｅｓｐｏｎｓｅを表している。図２のコマンド指示シーケンスであるＳ２１０，Ｓ２１８に相当する。

７０２は通信結果で、デバイス監視モジュールからのコマンド取得通信を問題なく受信したことを示す情報である。

７０３はトラッキングＩＤで、管理サーバ１０６が発行したコマンド指示に対し、一意に特定できる番号を発行していることを表す情報である。このトラッキングＩＤ７０３を割り振る事で、コマンド処理が完了したときに、処理結果とトラッキングＩＤの両方を受信することで、管理サーバ１０６の指示したコマンドがどのような結果になったのか、突合せをする事ができる。

７０４はコマンド指示で、本例は、管理サーバ１０６がデバイス監視モジュール１０２Ａへ送信する監視デバイスの追加を指示するコマンド指示である。

７０５はデバイスの識別子で、コマンド指示に必要な設定情報である。７０６はＩＰアドレスで、コマンド指示に必要な設定情報である。７０７はオプションフラグで、コマンド指示に必要な設定情報である。なお、このオプション情報７０７はコマンドの種類によって設定情報が変更されるので、限定するものではない。

＜デバイス監視モジュールからの通信データの構成例＞
図８は、図１に示したデバイス監視モジュールから管理サーバ１０６へ送信されるコマンド処理結果情報を模式的に表した図である。本例は、図２に示したＳ２１３、Ｓ２２５で処理されるコマンド処理結果情報に対応する。

図８において、８０１はコマンド処理結果情報で、管理サーバから受信したコマンド処理を実行した処理結果に対応する。

８０２はクライアント識別情報で、デバイス監視モジュール１０２Ａから出力される情報である。８０３はデバイス監視モジュールの識別ＩＤである。８０４は監視形態で、デバイス監視モジュール１０２Ａがデバイスに組み込まれているタイプなのか、独立した専用ハードで動いているのか、ＰＣ上のソフトなのかを示す情報である。

８０５はアプリケーションバージョン（ａｐｐＶｅｒｓｉｏｎ）で、アプリケーションのバージョンを示す情報である。８０６はタイムスタンプ（ｔｉｍｅＳｔａｍｐ）で、この通信を発行した現在時刻を示す情報である。

８０７は指示結果情報で、コマンド処理結果の詳細を示す情報である。８０８はトラッキングＩＤで、管理サーバ１０６がコマンド送信と同時に発行する識別情報である。８０９は処理結果で、コマンドの処理結果が成功かを示す情報である。なお、コマンドの処理結果が失敗となる時、処理結果８０９は、エラーコード番号を含むエラー情報ができるだけ詳細に表現される。８１０は処理実行時刻で、デバイス監視モジュール１０２Ａで処理を実行した時刻である。８１１は詳細情報で、その他のオプション情報である。

図９は、図１に示したデバイス監視モジュール１０２Ａから管理サーバ１０６へ送信されるデバイス監視装置の設定情報を模式的に表した図である。本例は、図２に示したコマンド指示の処理を示すＳ２２０に対応するデバイス監視装置の設定情報である。

図９において、９０１はデバイス監視装置の設定情報で、大別してクライアント識別情報８０２と、クライアント設定情報９０７から構成されている。

デバイス監視装置の設定情報９０１は、管理サーバ１０６から受信した設定情報要求に対応した、現在のデバイス監視モジュール１０２Ａの設定情報である。

なお、図９に示す８０２〜８０６の情報は、図８にて説明しているデバイス監視モジュール１０２Ａのクライアント識別情報と同じ情報である。

９０７はクライアント設定情報で、デバイス監視モジュール１０２Ａにより設定される設定情報である。９０８は送信先ＵＲＬ情報で、デバイスの監視装置の通信先である管理サーバ１０６のＵＲＬを特定する情報である。

９０９は全送信設定情報で、デバイス監視モジュール１０２Ａが取り扱う情報で、データ種９１０、送信タイミング９１１、スケジュール情報９１２、有効・無効９１３、拡張情報９１４を含んでいる。

全送信設定情報９０９には、例えば、監視対象のデバイスがＭＦＰであるときに、デバイスのステータス情報は、使用枚数、使用頻度、使用機能、ファームウェアバージョンなどが含まれる。これらの情報をデバイス監視モジュール１０２Ａから管理サーバ１０６へ必要なスケジュール間隔で送信している。

また、全送信設定情報９０９には、エラーやアラームなどのイベント系の情報も含まれる。これは、データ種９１０にＩＤ定義して、取り扱うデータをＩＤで示している。

なお、送信タイミング９１１には、各カウンタの送信タイミングを特定する情報が設定される。スケジュール情報９１２には送信スケジュールを特定する情報が設定される。有効・無効９１３にはステータスを特定する情報が設定される。また、拡張情報９１４には、拡張機能を特定する情報が設定される。

９１５は監視対象デバイスリストで、デバイス監視モジュール１０２Ａの監視対象であるデバイスのリストが出力される。９１６には、監視対象であるデバイスの識別子を出力する。９１７はＩＰアドレスで、対象となるデバイスのＩＰ Ａｄｄｒｅｓｓの情報を出力する。９１８はオプションフラグで、デバイスを監視するために必要なオプション情報を出力する。

＜本実施形態の管理サーバの動作例＞
上記構成に基づいて、本実施形態の管理サーバのデータ処理例を説明する。

尚、以下のデータ処理例では、処理を単純化するためにデバイス監視モジュールは同じデバイス監視モジュールで管理されているものとして説明する。

しかし、実際には、複数のデバイス監視モジュールがデバイスを管理しており、その場合にはデバイス監視モジュールに対しては独立の処理となるが、そのための処理手順は明らかである。

本実施形態では、デバイス監視モジュールから何らかの通信があった場合に管理サーバが通信メソッドを認識し、処理結果を受信しなかった場合に、現在の設定情報をコマンド指示し、設定情報から前回コマンド処理が実行されているかを判断する例を示す。

また、デバイス監視装置１０２のデバイス監視モジュール１０２Ａが監視するデバイスは、画像形成装置の例を示す。なお、デバイス監視装置１０２は、デバイスとの一例である画像形成装置内、または、イントラネット環境１０８内の情報処理装置内に設けられる構成であってもよい。

さらに、デバイス監視モジュール１０２Ａがデバイスとの一例である画像形成装置内に備える記憶装置にインストールされて、画像形成装置のＣＰＵが当該デバイス監視モジュール１０２Ａを実行する構成としてもよい。同様に、デバイス監視モジュール１０２Ａがイントラネット環境１０８内の情報処理装置内に備える記憶装置にインストールされて、情報処理装置のＣＰＵが当該デバイス監視モジュール１０２Ａを実行する構成としてもよい。

図１０は、本実施形態を示す管理サーバにおけるデータ処理手順の一例を示すフローチャートである。本例は、管理サーバ１０６がデバイスから通信リクエストを受けた場合、または、デバイス管理者のＰＣ１０７からコマンド指示を受けたときの処理例である。

なお、Ｓ１００１〜Ｓ１０１３は各ステップを示し、各ステップは、管理サーバ１０６のＣＰＵ３０２が記憶装置３０８から制御プログラムをＲＡＭ３０４にロードして実行することで実現される。

また、本例は、デバイス管理者のＰＣ１０７から処理コマンドが要求される場合を示すが、デバイス管理者が管理サーバ１０６のユーザインタフェースを介して処理コマンドを指示する構成としてもよい。

ここで、処理コマンドには、デバイス監視装置１０２が監視するデバイスのデバイス情報、又は監視スケジュールを登録させる処理コマンドが含まれる。同様に、処理コマンドには、デバイス監視装置１０２が監視するデバイスのデバイス情報、又は監視スケジュールを削除または更新させる処理コマンドが含まれる。

Ｓ１００１で、管理サーバ１０６は、ユーザインタフェースを用いてデバイス管理者のＰＣ１０７からのコマンド指示があるか否かをＣＰＵ３０２が判断する。ここで、デバイス管理者のＰＣ１０７からコマンド指示が要求されているとＣＰＵ３０２が判断した場合は、Ｓ１００２へ進む。そして、Ｓ１００２で、コマンド指示をデータベース１０６Ａへ保管し、Ｓ１００３へ進む。ここで、コマンド指示は、ＰＣ１０７から受信する処理コマンドによる。

一方、Ｓ１００１で、デバイス管理者のＰＣ１０７からコマンド指示が要求されていないとＣＰＵ３０２が判断した場合は、Ｓ１００３へ進む。

そして、Ｓ１００３で、ネットワークを介してデバイスからコマンドを取得する通信要求を受信しているかをＣＰＵ３０２が確認する。ここで、ＣＰＵ３０２がデバイスからコマンドを取得する通信要求を受信していないと判断した場合は、Ｓ１００１へ進み、再度、デバイス管理者のＰＣ１０７からコマンド指示を受け付ける。

なお、Ｓ１００１〜Ｓ１００３の間に、デバイス監視モジュール１０２Ａはカウンタ情報などほかのステータス情報を管理サーバ１０６に対して送信してくるかもしれないが、ここではその説明を省略する。

一方、Ｓ１００３で、デバイスからコマンドを取得する通信要求を受信しているとＣＰＵ３０２が判断した場合、Ｓ１００４へ進む。

そして、Ｓ１００４で、管理サーバ１０６のデータベース１０６Ａ内に、デバイス管理モジュールに対する処理コマンドによるコマンド指示が保管されているかどうかをＣＰＵ３０２が確認する。

ここで、データベース１０６Ａ内に送信すべきコマンドが保管されていないとＣＰＵ３０２が判断した場合には、Ｓ１００１へ戻る。

一方、Ｓ１００４で、送信すべきコマンドが保管されているとＣＰＵ３０２が判断した場合は、Ｓ１００５へ進む。そして、Ｓ１００５で、管理サーバ１０６のＣＰＵ３０２は、コマンド取得通信のレスポンスとしてコマンド指示に対応する処理コマンドをデバイス監視モジュール１０２Ａに送信する。

その後、デバイス監視モジュール１０２Ａでは、処理コマンドが実行され、管理サーバ１０６では、処理結果を受信するが、何かの障害によって処理結果を受信できない状態となっている場合がある。

次に、Ｓ１００６で、デバイス監視モジュール１０２Ａから処理結果を受信しているか否かをＣＰＵ３０２が判断する。ここで、デバイス監視モジュール１０２Ａから処理結果を受信しているとＣＰＵ３０２が判断した場合は、Ｓ１０１３へ進む。

そして、Ｓ１０１３で、管理サーバ１０６内のデータベース１０６Ａを確認し、他に送信すべき処理コマンドがないかをＣＰＵ３０２が確認する。ここで、すべての処理コマンドが処理されているために、他に送信すべき処理コマンドがないとＣＰＵ３０２が判断した場合は、本処理を終了する。一方、Ｓ１０３で、他に送信すべき処理コマンドがあるとＣＰＵ３０２が判断した場合には、Ｓ１００５へ戻る。

一方、Ｓ１００６で、デバイスからの処理結果を受信していないとＣＰＵ３０２が判断した場合は、Ｓ１００７へ進む。

そして、Ｓ１００７で、ＣＰＵ３０２は、タイムアウト、または受信した通信の種類から障害を検知する。

そして、Ｓ１００８では、再度、デバイス監視モジュール１０２Ａからコマンドを取得する通信要求を受信しているかをＣＰＵ３０２が判断し、一定期間以上受信していないと判断した場合には、Ｓ１０１２へ進む。

そして、Ｓ１０１２で、処理結果を「失敗」として、障害が発生していることを管理者（ユーザ）のＰＣ１０７に通知して、本処理を終了する。これにより、デバイス管理者が障害が発生していることを認知する。

一方、Ｓ１００８で、デバイス監視モジュール１０２Ａからコマンドを取得する通信要求を受信しているとＣＰＵ３０２が判断した場合には、Ｓ１００９へ進む。

そして、Ｓ１００９で、ＣＰＵ３０２は、設定情報を送信させるオペレーション指示を発行し、デバイス監視モジュール１０２Ａへ送信する。次に、Ｓ１０１０で、デバイス監視モジュール１０２Ａから設定情報をＣＰＵ３０２が受信する。なお、Ｓ１００９のタイミングにおいては、既に送信した処理コマンドの処理結果を判断するための設定情報を要求する処理コマンドを優先して送信する。

つまり、Ｓ１００９のタイミングにおいて、データベース１０６Ａには、既に他の処理コマンドが記憶されている場合があるが、ＣＰＵ３０２はデータベース１０６Ａに記憶されている他の処理コマンドよりも設定情報を要求する処理コマンドを優先して送信する。

そして、Ｓ１０１１で、受信した設定情報を確認して、前回送信した処理コマンドが反映されているかどうかの確認をＣＰＵ３０２が行う。ここで、前回コマンドが成功し、設定情報に反映されているとＣＰＵ３０２が判断した場合には、Ｓ１０１３へ進み、次に送信すべき処理コマンドがあるか確認を行う。

一方、Ｓ１０１１で、前回コマンドが失敗し、設定情報に反映されていないとＣＰＵ３０２が判断した場合には、Ｓ１０１２へ進む。

そして、Ｓ１０１２で、処理結果を「失敗」として、障害が発生していることを管理者のＰＣ１０７に通知して、本処理を終了する。

本処理では、デバイス管理者のＰＣ１０７から処理コマンドを受け、デバイス監視モジュール１０２Ａに処理コマンドを送信したが、処理の途中でステータスが「不明」になってしまった場合、管理サーバ１０６は以下の判断を行う。

具体的には、管理サーバ１０６は前回の処理コマンドの処理結果を確認できる設定情報を出力させる処理コマンドをデバイス監視モジュール１０２Ａに対して動的に発行する。そして、管理サーバ１０６は、デバイス監視モジュール１０２Ａから受信した現在の設定値より前回の処理コマンドの処理が成功しているか、失敗しているかの判断を行う。

このように、処理コマンドの処理中に障害が発生しても、管理サーバ１０６から能動的に障害のステータスを取得するコマンドを発行することによって、対応する必要があるものなのか、そうでないのかを判断する。

これにより、ファイアウォールオール外の管理サーバ１０６は、ファイアウォール内でデバイスを監視するイントラネット環境１０８に依存する障害が発生した場合に、自動的にステータスを把握して処理を継続できる。

また、プログラムバグのような内部の障害の時には、処理を継続せずにデバイス管理者へ現在のデバイス管理モジュールの設定を含めて通知を行うことができる。

これにより、デバイス管理システムのデバイス監視モジュールの一方向からの通信のみ可能な状態のときでも、管理サーバ１０６は効率よく処理コマンドをデバイス監視装置１０２に送信して、適切な指示を行う事ができる。

図１１は、図１に示したデバイス１０１内の制御部１０１Ａの構成を説明するブロック図である。本例は、リーダ部１７１５とプリンタ部１７１４を備える複合機をデバイス１０１として、デバイス１０１内でデバイス監視モジュールの処理を説明する。

また、デバイス監視モジュールは、デバイス１０１内の制御部１０１Ａ内で、デバイスの個別情報の管理や、デバイスのステータス情報を管理サーバに送信するなどの処理を行う。

デバイス１０１の制御部１０１Ａでは、主として、プリントやスキャンなどプログラムの制御処理を行い、そのほかに、デバイス監視モジュールなどの各アプリケーションが制御されている。

図１１に示すように、制御部１０１Ａの各構成要素は、システムバス１７１６及び画像バス１７１７に接続されている。ＲＯＭ１７０４にはデバイスの制御プログラム及び、デバイス監視プログラムが格納されており、ＣＰＵ１７０７で実行される。

ＲＡＭ１７０５は、プログラムを実行するためのワークメモリエリアである。また、ＲＡＭ１７０５はデバイス監視プログラムが監視を行う上で必要なデバイスのステータス情報や、画像データを一時記憶するための画像メモリとしても機能する。

記憶装置１７０６は不揮発性の記憶装置であり、デバイス１０１の再起動後も保持しておく必要のある各種動作モード設定や、カウンタ値、稼働ログなどが記憶される。

Ｎｅｔｗｏｒｋ Ｉ／Ｆ１７０２は、ＬＡＮ１００と接続するためのインタフェース部であり、ＬＡＮ１００，インターネット１１０を介して管理サーバ１０６と通信を行う。回線Ｉ／Ｆ部１７０３は、ＩＳＤＮや公衆電話網に接続され、ＲＯＭ１７０４内の通信制御プログラムにより制御される。また、回線Ｉ／Ｆ部１７０３は、ＩＳＤＮ Ｉ／Ｆやモデム、ＮＣＵ（Ｎｅｔｗｏｒｋ Ｃｏｎｔｒｏｌ Ｕｎｉｔ）を介して遠隔の端末とデータの送受信を行う。

ファクシミリの送受信もこの回線Ｉ／Ｆ部１７３０を使用して行う。

操作部１７０１には表示手段やキー入力手段が内蔵されており、これらはＣＰＵ１７０７にて制御される。操作者は、キー入力手段を通してリーダ部１７１５の読み取りや、プリンタ部１７１４のプリント出力に関する各種設定指示や、作動／停止指示を行う。以上のデバイスがシステムバス１７１６上に配置される。

ＩＯ制御部１７０８は、システムバス１７１６と画像データを高速で転送する画像バス１７１７とを接続するためのバスブリッジである。

画像バス１７１７は、ＰＣＩバスまたはＩＥＥＥ１３９４で構成される。画像バス１７１７上には以下のデバイスが配置される。デジタルＩ／Ｆ部１７１１は、デバイスのリーダ部１７１５やプリンタ部１７１４と制御部とを接続し、画像データの同期系／非同期系の変換を行う。

また、リーダ部１７１５やプリンタ部１７１４内の各所に配置した前述の各種センサが検出した情報は、このデジタルＩ／Ｆ部１７１１、及びＩＯ制御部１７０８を介してシステムバス１７１６へ入出力される。

画像処理部１７０９は、入力及び出力画像データに対し補正／加工／編集を行う。画像回転部１７１０は画像データの回転を行う。

画像圧縮伸長部１７１２は、多値画像データはＪＰＥＧ、２値画像データはＪＢＩＧ／ＭＭＲ／ＭＲ／ＭＨの圧縮伸張処理を行う。画像密度変換部１７１３は、出力用画像データに対して解像度変換等を行う。

ＣＰＵ１７０７がＲＡＭ１７０５にロードして実行される制御プログラムにより、ＣＰＵ１７０７は記憶装置１７０６内のカウンタ値や稼働ログなどの稼動情報や障害情報を読み出してデバイスのステータス情報として管理サーバ１０６へ送信する。

＜デバイスの記憶部構成例＞
図１２は、図１１に示したＲＯＭ１７０４又は記憶装置１７０６に不揮発的に記憶されるプログラム及びデータの構成例を示す図である。尚、図１２には、本実施形態に対応するプログラム及びデータのみを示し、他は省略している。

図１２において、１８０１はＯＳ等の装置の基礎的な制御を行うシステム基本プログラムである。１８０２はデバイスの管理を制御するデバイス管理プログラムである。

１８０３はメッセージ送受信プログラムで、管理サーバ１０６から設定指示等を受信する、または、デバイス１０１のステータス情報やコマンドリクエストを管理サーバ１０６へ送信するための送受信を制御する。

１８０４は受信コマンド解析プログラムで、管理サーバ１０６から受信した通信に含まれているコマンドを解析し、何を行うかを決定する。１８０５はスケジュール設定情報解析プログラムで、受信コマンド解析プログラム１８０４にて受信したコマンドが、スケジュール情報の設定であった場合に、どの種類のデータをどのスケジュールで管理サーバ１０６に送信するのかを決定する。

１８０６は各処理プログラムで、スケジュール設定情報解析プログラム１８０５の解析結果に対応して実行される。例えば、デバイスでイベントが発生した場合には、イベントデータはどのタイミングで管理サーバに送信すればいいのか、解析結果を確認し、その解析結果に応じてイベント情報送信処理を実行する。

各処理プログラム１８０６は、各処理プログラム１８０６のイベント情報送信処理プログラム１８０７、スケジュール送信処理プログラム１８０８、カウンタ情報送信処理プログラム１８０９、スケジュール設定変更処理プログラム１８１０から構成される。

１８１１はデバイス識別子で、デバイスを管理サーバ１０６内で識別する情報である。

また、１８１２はデバイス状態ＤＢで、記憶装置で管理され、デバイスの状態が保管してある。このデバイス状態ＤＢ１８１２の中には、デバイスのファームウェアやデバイスのタイプなど、デバイスの基本情報１８１３が保管されている。

また、デバイス状態ＤＢ１８１２の中には、今までに発生したエラー情報１８１４、アラーム情報１８１５、ジャム情報１８１６などのイベント情報、パーツの消耗度を示すパーツ情報１８１７などが保管されている。

また、１８１８はデバイスカウンタデータＤＢで、課金カウンタ１８１９や機能カウンタ１８２０が保管されている。１８２１はプログラムロード領域で、ＣＰＵ１７０７が図１２に示したプログラムを実行するためロードする記憶領域である。

図１３は、図２に示したデバイス監視モジュール１２１Ａと管理サーバ１０６との間の通信を規定しているコマンド処理リスト１３０１の例を示す図である。

図２に示したデバイス監視モジュール１２１Ａと管理サーバ１０６は、コマンド処理リスト１３０１内のいずれかのコマンド処理を実行して、コマンド指示と設定値の確認を行う。

例えば、コマンドで「ａｄｄＤｅｖｉｃｅ」、「ｍｏｄｉｆｙＤｅｖｉｃｅ」、「ｄｅｌｅｔｅＤｅｖｉｃｅ」など管理対象のデバイスを変更した場合、処理結果を確認するコマンドは、「ｐｏｓｔＣｏｎｆｉｇｕｒａｔｉｏｎ」となる。

〔第２実施形態〕
以下、図１４に示すメモリマップを参照して本発明に係る情報処理装置で読み取り可能なデータ処理プログラムの構成について説明する。

図１４は、本発明に係る情報処理装置で読み取り可能な各種データ処理プログラムを格納する記憶媒体のメモリマップを説明する図である。

なお、特に図示しないが、記憶媒体に記憶されるプログラム群を管理する情報、例えばバージョン情報，作成者等も記憶され、かつ、プログラム読み出し側のＯＳ等に依存する情報、例えばプログラムを識別表示するアイコン等も記憶される場合もある。

さらに、各種プログラムに従属するデータも上記ディレクトリに管理されている。また、各種プログラムをコンピュータにインストールするためのプログラムや、インストールするプログラムが圧縮されている場合に、解凍するプログラム等も記憶される場合もある。

本実施形態における図１０に示す機能が外部からインストールされるプログラムによって、ホストコンピュータにより遂行されていてもよい。そして、その場合、ＣＤ−ＲＯＭやフラッシュメモリやＦＤ等の記憶媒体により、あるいはネットワークを介して外部の記憶媒体から、プログラムを含む情報群を出力装置に供給される場合でも本発明は適用されるものである。

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

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

従って、プログラムの機能を有していれば、オブジェクトコード、インタプリタにより実行されるプログラム、ＯＳに供給するスクリプトデータ等、プログラムの形態を問わない。

プログラムを供給するための記憶媒体としては、例えばフレキシブルディスク、ハードディスク、光ディスク、光磁気ディスク、ＭＯ、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、ＣＤ−ＲＷ、磁気テープ、不揮発性のメモリカード、ＲＯＭ、ＤＶＤなどを用いることができる。

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

その他、プログラムの供給方法としては、クライアントコンピュータのブラウザを用いてインターネットのホームページに接続する。そして、該ホームページから本発明のコンピュータプログラムそのもの、もしくは、圧縮され自動インストール機能を含むファイルをハードディスク等の記録媒体にダウンロードすることによっても供給できる。また、本発明のプログラムを構成するプログラムコードを複数のファイルに分割し、それぞれのファイルを異なるホームページからダウンロードすることによっても実現可能である。つまり、本発明の機能処理をコンピュータで実現するためのプログラムファイルを複数のユーザに対してダウンロードさせるＷＷＷサーバやｆｔｐサーバ等も本発明の請求項に含まれるものである。

また、本発明のプログラムを暗号化してＣＤ−ＲＯＭ等の記憶媒体に格納してユーザに配布し、所定の条件をクリアしたユーザに対し、インターネットを介してホームページから暗号化を解く鍵情報をダウンロードさせる。そして、その鍵情報を使用することにより暗号化されたプログラムを実行してコンピュータにインストールさせて実現することも可能である。

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

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

本発明は上記実施形態に限定されるものではなく、本発明の趣旨に基づき種々の変形（各実施形態の有機的な組合せを含む）が可能であり、それらを本発明の範囲から除外するものではない。

本発明の様々な例と実施形態を示して説明したが、当業者であれば、本発明の趣旨と範囲は、本明細書内の特定の説明に限定されるのではない。

本発明の実施形態を示す管理システムの構成を説明するブロック図である。 図１に示したデバイス監視モジュールと管理サーバとデバイス管理者のＰＣと間の通信シーケンス例の一部を表した図である。 図１に示した管理サーバのハードウェア構成例を示すブロック図である。 図１に示した管理サーバにおける、デバイス監視モジュールへのコマンド処理の確認を行うアプリケーションプログラムの機能を示すブロック図である。 図３に示した管理サーバが備えるＲＯＭ又は記憶装置に不揮発的に記憶されるプログラム及びデータの構成例を示す図である。 図３に示したＲＡＭに一時記憶されるデータの構成例を示す図である。 図１に示した管理サーバからデバイス監視モジュールへ送信されるコマンド指示情報を模式的に表した図である。 図１に示したデバイス監視モジュールから管理サーバへ送信されるコマンド処理結果情報を模式的に表した図である。 図１に示したデバイス監視モジュールから管理サーバへ送信されるデバイス監視装置の設定情報を模式的に表した図である。 本実施形態を示す管理サーバにおける第１のデータ処理手順の一例を示すフローチャートである。 図１に示したデバイス内の制御部の構成を説明するブロック図である。 図１１に示したＲＯＭ又は記憶装置に不揮発的に記憶されるプログラム及びデータの構成例を示す図である。 図２に示したデバイス監視モジュールと管理サーバとの間の通信を規定しているコマンド処理リストの例を示す図である。 本発明に係る管理サーバで読み取り可能な各種データ処理プログラムを格納する記憶媒体のメモリマップを説明する図である。

符号の説明

１０１ デバイス
１０２ デバイス監視装置
１０２Ａ デバイス監視モジュール
１０５ ファイアウォール
１０６ 管理サーバ
１０６Ａ データベース（ＤＢ）
１０７ ＰＣ

Claims (11)

1. ファイアウォール内のデバイス監視装置とインターネットを介して通信可能なファイアウォール外に設置された管理サーバであって、
   前記デバイス監視装置への処理コマンドを記憶する記憶手段と、
   前記デバイス監視装置からのコマンド取得の要求を受信する受信手段と、
   前記受信手段により受信した要求の応答として、前記記憶手段に記憶された処理コマンドを送信するコマンド送信手段とを備え、
   前記コマンド送信手段により送信した処理コマンドによる処理結果を受信できなかった場合、前記受信手段が前記デバイス監視装置からの新たにコマンド取得の要求を受信した際に、前記コマンド送信手段は該新たなコマンド取得の要求の応答として、処理結果を受信できなかった前記処理コマンドの処理結果を判断するためにデバイス監視装置の設定情報を要求するコマンドを送信することを特徴とする管理サーバ。
2. 前記コマンド送信手段による処理結果を受信できなかった前記処理コマンドの処理結果を判断するためにデバイス監視装置の設定情報を要求するコマンドの送信は、前記記憶手段に既に他の処理コマンドが記憶されていた場合であっても、優先して行われることを特徴とする請求項１に記載の管理サーバ。
3. 前記コマンド送信手段により、処理結果を受信できなかった前記処理コマンドの処理結果を判断するために送信されたデバイス監視装置の設定情報を要求するコマンドに対する前記デバイス監視装置の応答に基づき、当該処理結果が成功であったか否かを判断する判断手段と、
   前記判断手段により処理結果が失敗であったと判断された場合、当該処理結果が失敗であった旨を出力する出力手段と、
   前記判断手段により処理結果が成功であったと判断された場合、前記コマンド送信手段が、前記デバイス監視装置の設定情報を要求するコマンドに対する前記デバイス監視装置の応答が行われた通信を利用して、前記記憶手段に記憶された処理コマンドを送信することを特徴とする請求項１または２に記載の管理サーバ。
4. 前記処理コマンドは、前記デバイス監視装置が監視するデバイスのデバイス情報、または監視スケジュールの登録、削除または更新処理を行せるためのコマンドであることを特徴とする請求項１乃至請求項３の何れか１項に記載の管理サーバ。
5. 前記デバイス監視装置が監視するデバイスは画像形成装置であって、前記デバイス監視装置は情報処理装置または画像形成装置に設けたことを特徴とする請求項１乃至請求項４の何れか１項に記載の管理サーバ。
6. ファイアウォール内のデバイス監視装置とインターネットを介して通信可能なファイアウォール外に設置された管理サーバにおけるデータ処理方法であって、
   前記デバイス監視装置への処理コマンドを記憶手段に記憶する記憶ステップと、
   前記デバイス監視装置からのコマンド取得の要求を受信する受信ステップと、
   前記受信ステップにより受信した要求の応答として、前記記憶手段に記憶された処理コマンドを送信するコマンド送信ステップとを備え、
   前記コマンド送信ステップにより送信した処理コマンドによる処理結果を受信できなかった場合、前記受信ステップが前記デバイス監視装置からの新たにコマンド取得の要求を受信した際に、前記コマンド送信ステップは該新たなコマンド取得の要求の応答として、処理結果を受信できなかった前記処理コマンドの処理結果を判断するためにデバイス監視装置の設定情報を要求するコマンドを送信することを特徴とするデータ処理方法。
7. 前記コマンド送信ステップによる処理結果を受信できなかった前記処理コマンドの処理結果を判断するためにデバイス監視装置の設定情報を要求するコマンドの送信は、前記記憶手段に既に他の処理コマンドが記憶されていた場合であっても、優先して行われることを特徴とする請求項６に記載のデータ処理方法。
8. 前記コマンド送信ステップにより、処理結果を受信できなかった前記処理コマンドの処理結果を判断するために送信されたデバイス監視装置の設定情報を要求するコマンドに対する前記デバイス監視装置の応答に基づき、当該処理結果が成功であったか否かを判断する判断ステップと、
   前記判断ステップにより処理結果が失敗であったと判断された場合、当該処理結果が失敗であった旨を出力する出力ステップと、
   前記判断ステップにより処理結果が成功であったと判断された場合、前記コマンド送信ステップが、前記デバイス監視装置の設定情報を要求するコマンドに対する前記デバイス監視装置の応答が行われた通信を利用して、前記記憶手段に記憶された処理コマンドを送信することを特徴とする請求項６または７に記載のデータ処理方法。
9. 前記処理コマンドは、前記デバイス監視装置が監視するデバイスのデバイス情報、または監視スケジュールの登録、削除または更新処理を行せるためのコマンドであることを特徴とする請求項６乃至請求項８の何れか１項に記載のデータ処理方法。
10. 前記デバイス監視装置が監視するデバイスは画像形成装置であって、前記デバイス監視装置は情報処理装置または画像形成装置に設けたことを特徴とする請求項６乃至請求項９の何れか１項に記載のデータ処理方法。
11. 請求項６〜９のいずれか１項に記載のデータ処理方法をコンピュータに実行させることを特徴とするプログラム。

Images