JP4869050B2 - 管理装置及び管理方法 - Google Patents

Description

本発明は、例えばネットワーク通信を用いた管理装置および管理方法に関する。特に、本発明は、ネットワークを介して遠隔でデバイスを管理するデバイス監視プログラムの送信データをコントロールする管理装置および管理方法に関する。

従来、インターネット上に管理サーバを設置し、ネットワークを介して顧客先のデバイスを管理するメンテナンスシステムが知られている。この従来のメンテナンスシステムでは、管理サーバは、監視対象のデバイスと同じサイトに設置されたデバイス監視装置から送信される例えばデバイスステータスやプリント枚数等の情報を収集してデバイスの管理を行っていた。この場合、デバイスを管理する上で必要な収集条件情報、例えば管理サーバにどのような情報を送信するかのスケジュール設定は、デバイス監視装置の設置時にサービスマンが行う。なお、最近では、デバイス自体にデバイスを監視するプログラムを走らせるケースもある。この場合、デバイスにデバイス監視装置が内蔵されていることになる。そこでデバイス監視装置という言葉を使わずに、以後デバイス監視モジュールという言葉で説明を行うことにする。デバイス監視モジュールは、独立したデバイス監視装置のほか、デバイスに内蔵されたデバイス監視装置を含む。

このようなメンテナンスシステムにおいて、少数のデバイスを管理する上で問題にならなかった通信・ハードウェアの非効率な部分が、大量の台数のデバイスを管理する管理サーバでは、大きな影響を生じる場合が出てきた。そこで特許文献１には、監視対象の装置に対して、該監視装置が通知する通知内容を選択し設定することで、通信の冗長性を回避する技術が開示されている。
特開平０７−１３７３５８号公報

しかしながら、特許文献１の技術では、メンテナンスを行う上で必要な情報が動的に変更するような場合に対応できなかった。例えばジャムに係わる情報を初期設定においては必要ないとユーザが判断し、監視対象装置から通知しないように設定したとする。しかし、途中でジャムに係わる情報が必要になった場合に、以前の設定では対応できない。特に監視対象デバイス数が多い場合には、特許文献１の技術では、結局の所、最初から全ての通知をＯＮにするかもしれない。

本発明は上記従来例に鑑みてなされたもので、ハードウェア・ネットワークリソースの効率的な運用を動的に行えるメンテナンスに係わる仕組みを提供することを目的とする。

上記目的を達成するために本発明は以下の構成を備える。

管理される複数の被管理装置と通信可能な管理装置であって、
前記被管理装置から状態コードを受信する第１受信手段と、
状態コードに関連付けられた保守情報を記憶する記憶手段から、前記第１受信手段により受信した状態コードに関連付けられた保守情報を取得する取得手段と、
前記取得手段により取得した保守情報を出力する出力手段と、
前記記憶手段に登録されたデバイス識別情報に対応するデバイスが監視対象として有効か無効かを設定する設定手段と、
デバイス識別情報が前記記憶手段に登録されているか否かを検索する検索手段と、
前記被管理装置から自発的に送信されてくる、前記管理装置が新たに送信すべき情報がないかの確認を行うための確認コマンドを受信する第２受信手段と、
保守情報に対応した状態コードの通知設定を含む通知設定情報を前記被管理装置に送信する送信手段とを有し、
前記送信手段は、前記検索手段による検索の結果、前記第２受信手段により受信した前記確認コマンドに含まれるデバイス識別情報が見つかった場合に、当該デバイス識別情報に関して監視対象として無効の設定がなされていると、前記状態コードの通知を行うことなく前記確認コマンドの送信を前記被管理装置に行わせる通知設定情報を、前記被管理装置に送信する。

本発明により、ハードウェア・ネットワークリソースの効率的な運用を動的に行えるメンテナンスに係わる仕組みを提供できるという効果を奏する。

［第１実施形態］
＜本実施形態のデバイス管理システムの全体構成例＞
図１において、システム１０８は顧客のネットワークシステム（イントラネット）を示している。イントラネットには、インターネットとの接続ポイントであるファイアウォール１０５が設置（構築）されている。また、外部へのＨＴＴＰやＨＴＴＰＳ通信を１台のマシンがコントロールできるようにプロクシサーバ１０４が設置されている。そして、ファイアウォール１０５により、外部からの不正なネットワークアクセスを拒否できセキュリティを守ることができる。

デバイス１０１や１０２は、被管理装置として、顧客のネットワークに設置されたＭＦＰ（Ｍｕｌｔｉ Ｆｕｎｃｔｉｏｎ Ｐｒｉｎｔｅｒ）やＳＦＰ（Ｓｉｎｇｌｅ Ｆｕｎｃｔｉｏｎ Ｐｒｉｎｔｅｒ）が示されている。これらプリント・複写などの機能をもつ機器の事をここではデバイスと呼ぶ。各デバイスには、デバイス監視モジュール１０１ａ，１０２ａが組み込まれている。このデバイス監視モジュールがデバイスのステータスを監視し、外部の管理サーバ１０６と通信を行う。また、デバイス監視モジュールは、デバイス監視を行うプログラムなので、デバイスに組み込む形態でも、ＰＣや専用のハードに組み込まれる形態で実行してもかまわない。クライアント１０３は、一般のユーザが業務等で使用するパーソナルコンピュータ（ＰＣ）を表している。インターネット１１０には、イントラネット１０８に類似した別顧客のネットワークが多数接続されている。

管理サーバ１０６は、インターネット上に設置され各顧客のネットワークに設置されているデバイス監視モジュールと通信を行う事によって、デバイスの情報を収集し、管理している。管理サーバ１０６の収集するデバイスの情報（これを管理情報と呼ぶ。）とは、デバイスの各種動作モード設定や、カウンタ値、稼動ログ、各パーツの使用度合い（使用頻度）を表すカウンタ値などの稼動情報、及びハード障害やジャム等の障害情報である。また、管理サーバ１０６は、各デバイスに対して通知設定情報の更新やリブートなどのコマンド指示を行う。この際の通信手段としては、ＨＴＴＰやＨＴＴＰＳなどのプロトコルを介したＳＯＡＰ（Ｓｉｍｐｌｅ Ｏｂｊｅｃｔ Ａｃｃｅｓｓ Ｐｒｏｔｏｃｏｌ）を利用した通信などがある。ＳＯＡＰとは、ネットワーク経由でオブジェクト間の通信を行うためのプロトコルである。ＳＯＡＰでは、ＸＭＬによって記述されるデータ構造が定義され、転送用のプロトコルとしては、ＨＴＴＰやＳＭＴＰが用いられる。管理サーバ１０６に実装されているＳＯＡＰプロセッサは、ＳＯＡＰにしたがって記述されたオブジェクトを解析（パース）し、処理を実行する。管理サーバ１０６は、デバイス監視モジュール及びデバイスを制御するために、デバイス監視モジュールに対してコマンドを発行する。

管理サーバ１０６の管理者１０７は、監視対象のデバイスから収集した管理情報を表示部に監視画面として表示させて、デバイスの状態を監視することができる。管理情報の一例を図１の管理情報１１１に、監視画面の一例を図１の監視画面１１２に示す。

また通知設定情報とは、デバイス監視モジュールが管理サーバに送信すべき情報の種類や送信すべきタイミング（スケジュール）を記述した情報である。デバイス監視モジュールは、管理サーバ１０６から与えられる通知設定情報に従って、デバイスの状態等を示す情報を、その情報に関連して指定されたスケジュールで、管理サーバ１０６に送信する。

＜情報処理装置のハードウェア構成ブロック図＞
図３は、一般的な情報処理装置のハードウェア構成を示すブロック図である。例えば、図１における管理サーバ１０６のハードウェア構成例に該当する。また管理される側（顧客側）のネットワーク環境に設置された情報処理装置の模範的なハードウェア構成を示すブロック図とすることも出来る。

全体を制御するためのＣＰＵ３０２と、システム起動に必要なブートプログラムを記憶するための読み出し専用メモリであるＲＯＭ３０３と、ＣＰＵ３０２でプログラムを実行する際に必要とされる作業メモリであるＲＡＭ３０４とを含む。又、ネットワーク上で通信を行うためのネットワークインターフェース（Ｉ／Ｆ）３０５と、表示デバイス３０９にデバイス監視モジュールとの通信内容等を表示するための表示制御部３０６とを含む。この時ＣＰＵ３０２はネットワークインターフェース（Ｉ／Ｆ）３０５を制御する通信制御手段としてい機能する。更に、管理サーバ１０６を管理するオペレータからの入力デバイス３１０や３１１、入力を受け付ける入力制御部３０７を含む。また、ＣＰＵ３０２で実行するプログラムやデバイス監視モジュールから送られた各デバイスの稼働情報などを格納する磁気ディスク等の不揮発性の記憶装置３０８を含む。

管理サーバ１０６は、デバイス監視モジュールからの定期的な稼働情報通知や不定期的な異常状態の通知、コマンド取得リクエストをネットワークＩ／Ｆ３０５を介して受信し取得する。また、ユーザからデバイス監視モジュール１０２への設定変更や動作要求などのコマンド入力は、入力制御部３０７を介して常時受け付けている。

定期的に通知される稼働情報には、各種カウンタ値や稼働ログなどが含まれており、管理サーバ１０６は稼動情報を基にデバイスを所有している顧客に対して毎月請求する定期メンテナンス料を算出する。又、デバイスに使用されているパーツが推奨寿命に対してどのくらい消耗しているのかをレポートの形で出力する。管理サーバ１０６はこの稼働情報を記憶装置２０８に逐次格納する。一方、オペレータは格納された稼働情報を適宜参照して顧客への請求額を決定する。

不定期的に通知されるデバイスの異常状態を表す情報には、稼働情報に加えて、発生したハード障害やジャムなどのエラー、障害の予兆を示す、消耗品切れを示すアラーム情報が含まれている。管理サーバ１０６はこの情報を受け取ると、情報の緊急度に基づいて処理を決定する。受け取った情報が、デバイスの故障など、デバイスが異常状態を表すものであり、すぐに復旧させる必要のある障害情報だった場合には、その対象のデバイスを管理しているオペレータに電子メールを送信する。さらに記憶装置２０８に逐次格納すると共にディスプレイ２０９上に表示することで、デバイスが異常状態に陥っている旨をオペレータに通知する。一方、受け取った情報がジャムやアラームのように緊急度が低い場合には、記憶装置２０８に逐次格納し、電子メールの送信が必要かどうか、ディスプレイ２０９に表示させる必要があるかどうかその時の障害に応じて処理を行う。オペレータは、ディスプレイ２０９上の表示内容からデバイスの状態を判断し、必要に応じて障害復旧作業をサービスマンに指示をする。

デバイス監視モジュールからのコマンド取得リクエストは、任意のタイミングで常時受け付ける。管理サーバ１０６はコマンド取得リクエストを受ける都度、管理サーバ１０６内の記憶装置２０８を確認し、デバイス監視モジュールへの送信すべきコマンドが設定されていたら、デバイス監視モジュールへコマンドを送信する。このコマンド取得リクエストのことを、被管理装置であるデバイスから自発的に管理装置１０６に対して新たに管理装置１０６から指示すべき情報がないかの確認を行うためのコマンドという意味で確認コマンドや確認リクエストと呼ぶこともある。

＜本システム全体における処理シーケンスの概略＞
図２は、本実施形態に係るデバイス監視モジュール１０１ａあるいは監視モジュール１０２ａと管理サーバ１０６との通信シーケンス例の一部を表した図である。尚、図２では、サーバ管理者から管理サーバ１０６に対して、デバイスの「新機種情報登録」Ｓ２０１や、デバイスの「機種属性情報登録」Ｓ２０２、デバイスの「機種追加属性情報登録」Ｓ２１５を行なう例を示す。これは入力シーケンスの概略の説明であって、これに限定されず、他の情報を入力する場合もある。図２においてサーバ管理者は人であり、管理サーバに対して適切な値を入力指示する。管理サーバ１０６は該入力指示を受け付けて、シーケンスに従って処理を行う。

Ｓ２０１およびＳ２０２は、サーバ管理者が管理サーバ１０６に対して、デバイスに係わる新機の情報の登録を表している。Ｓ２０１では、デバイスの機種名やデバイスＩＤ、製品スペック、製品カテゴリなど、市場に投入された新機種の基本的情報を登録する。製品スペックには、例えば速度等の性能や、提供する機能などを示す情報が含まれる。製品カテゴリは、例えば「プリンタ」や「複合機」などといった製品の分類を示す情報が含まれる。

Ｓ２０２では、新規管理対象である機種のエラー情報、パーツ情報を登録している。これらのエラーコード情報、パーツ情報（図９で詳しく説明）は、ある機種のデバイスを管理する上で必要な保守情報である。エラー情報には、管理サーバ１０６がサポートするデバイスが出力するエラーコードと、例えばエラーコード毎に関連づけられた説明等が含まれる。パーツ情報には、例えばデバイスから出力されるパーツのコードに関連付けられた説明情報等が含まれる。

これら、状態コードに対応する保守情報は、管理サーバ１０６に接続された端末の表示部に表示されたり、管理サーバ１０６にインターネット経由でアクセスしてきた端末装置にＨＴＭＬ情報として出力されたりする。また、電子メールにより管理サーバ１０６からメールサーバ経由でサービスマンの携帯端末装置に送信出力されることもある。

尚、デバイス１機種をメンテナンスをするには、エラー情報、パーツ情報、アラーム情報、ジャム情報、パーツ情報など複数の保守情報（以後この保守情報のことを、機種依存デバイスマスタデータと呼ぶこともある）が必要になる。図２のシーケンス図では、保守情報として、エラー情報と、パーツ情報が登録されたことを表しており、この登録シーケンスが行われる。

Ｓ２０３では、設置先でデバイス管理を開始するための設定作業を表している。この作業は、保守を行うサービスマンにより例えばデバイスの操作パネルから行われる。

Ｓ２０４では、設置しているデバイス監視モジュールから、管理サーバ１０６と通信可能かの確認を行う通信テストを行う。この通信テストは、被管理装置としてのデバイスが設置されたことを意味する設置確認通知も兼ねる。通信テストとして、例えばテスト用メッセージが送られる。このテスト用メッセージを受信した管理サーバ１０６は、テスト用メッセージに含まれるデバイス監視モジュールのＩＤを基に認証を行う。デバイス監視モジュールのＩＤは、デバイス監視モジュールがデバイスと一体の場合にはデバイスの登録時に、独立している場合にはデバイス監視装置の登録時に、管理サーバ１０６に登録される。なおデバイス監視装置とはユーザ側のネットワーク上で複数の画像形成装置を監視し、該監視結果を管理サーバ１０６に通知する、デバイス監視モジュールと同様の機能を備えた仲介装置を指す。

例えば、受信したメッセージに含まれるデバイス監視モジュールのＩＤと予め登録されたＩＤとが一致すれば認証は成功と判定できる。認証が成功だった場合には、監視対象であるデバイスＩＤの確認を行う。なお、以後の説明ではデバイス監視モジュールのＩＤとデバイスＩＤとを別のものとして説明するが、１つのＩＤで共通化しても良い。通信テストで受信したデバイスＩＤを、管理サーバ１０６に登録されているデバイスＩＤの中から検索し、ヒットすればテスト用メッセージの送信元デバイスは監視対象のデバイスである。そしてそのデバイスＩＤ（後述の図５のデバイスＩＤ５１８に相当）に関連づけて登録されたデバイス情報から、管理サーバ１０６はデバイスの詳細情報を得ることができる。ここで、ＨＴＴＰ応答として、通信テストが問題なく完了したことを示す通信テスト完了情報をデバイス監視モジュールに送信する。この通信テスト完了情報が、Ｓ２０７で表されている。

通信テストが問題なく完了すると、Ｓ２０８にてデバイス監視モジュールは、通知設定情報リクエストを管理サーバ１０６に送信する。これは、デバイス監視モジュールがどのようなスケジュールにしたがってデータを管理サーバ１０６に送信するか、また、どのイベントに関するデータを管理サーバ１０６で必要とするかの問い合わせを行う要求である。

Ｓ２１０にて、管理サーバ１０６は、通知設定情報リクエストに含まれるデバイスＩＤに基づいて、そのデバイスＩＤに関連づけられて登録された機種依存デバイスマスタデータを特定し、そこから管理サーバ１０６が管理可能な情報を読み取る。より具体的にはデバイスが管理サーバ１０６に送信可能な状態コードのうち保守情報が関連付けられた状態コードがどれかを判断する。例えば、この機種依存デバイスマスタデータに保守に用いられる保守情報として、エラー情報とパーツ情報とが含まれていれば、管理サーバ１０６は対応する状態コードを監視対象と判断する。そして、それら状態コードをデバイスから通知する通知設定情報を作成する。なお実際にはデバイスＩＤに機種依存デバイスマスタデータとを直接関連付けても良いし、またデバイスＩＤにデバイス機種情報を関連付け、該デバイス機種情報と機種依存デバイスマスタデータとを関連付けても良い。

一方、対応して保守情報が登録されていない状態コード情報を受信しても保守に利用できないので読み捨ててしまう。該背景もあり、エラー情報及びパーツ情報が登録されている場合には、管理サーバ１０６は基本データとしての課金カウンタ情報に加え、エラー情報とパーツ情報とを、対象のデバイス監視モジュールが送信すべき状態コードとして記述した通知設定情報を作成する。またデバイス監視モジュールが送信すべき状態コードを管理サーバに送信するスケジュール（タイミング）も作成され、通知設定情報に記述される。さらに、管理サーバ１０６は、デバイス監視モジュールが管理サーバ１０６に対してに対して情報要求を行う機会を与えるためのコマンド取得リクエスのスケジュールも、通知設定情報内のスケジュールに含まれている。このコマンド取得リクエストにより、ファイアウォール１０５があり管理サーバ１０６からデバイス監視モジュールに対して指示を自発的に行えない環境でも、管理サーバ１０６はデバイス監視モジュールに対して指示を行うことが出来る。

Ｓ２１１では、Ｓ２０８の通知設定情報リクエストに対するＨＴＴＰレスポンスとして、Ｓ２１０で作成された通知設定情報（例えば後述の図７）を、デバイス監視モジュールに対して送信する。

Ｓ２１２、Ｓ２１４は、デバイス監視モジュールが通常の管理状態に入り、通常の通信を行っていることを意味している。Ｓ２１１では、管理サーバ１０６から受信した通知設定情報に従って、指定された状態コードを送信する。例えば、図２では状態コードにはエラー情報が含まれており、その通知スケジュールは検知直後であるとする。そこで、監視対象のデバイスにエラーが発生し、デバイス監視モジュールがエラーを検知した場合には、即時に管理サーバ１０６へエラー情報を送信する。

また、デバイス監視モジュールが送信すべき状態コードを追加することもできる。例えばＳ２０１で機種情報を登録したときには、管理サーバ１０６はデバイスの状態コード「アラーム」を処理できなかったとする。そしてその後、管理サーバ１０６のバージョンアップなどによりアラームコードに対応する保守情報が登録され対応が可能になったものとする。そこでサーバ管理者は、Ｓ２１５にて、追加の保守情報であるアラーム情報を、管理サーバ１０６の該当する機種の機種依存デバイスマスタデータとして登録する。管理サーバ１０６では、対象機種のデバイスに対して、管理できる情報が増えることになる。最初に設置した対象デバイスは、アラームの情報を送信してこないよう設定されているので、管理サーバ１０６にアラーム情報が送信されてこない。

そして、管理サーバ１０６は、通常送信のひとつであるコマンド取得リクエスがデバイス監視モジュールから送信されてくるのを待つ。コマンド取得リクエスは、デバイス監視モジュールが、通知設定情報に設定されたスケジュールに従って管理サーバ１０６に対して送信する。例えばコマンド取得リクエストは定期的に通知されてくる。Ｓ２１６では、デバイス監視モジュールが設定されたスケジュール通信にしたがって、管理サーバ１０６に対して、コマンド取得リクエスを送信してくることを表している。

Ｓ２１８においては、確認コマンドとしてのコマンド取得リクエスを受信した管理サーバ１０６は、デバイス監視モジュールを認証し、デバイスＩＤを確認する。これは、Ｓ２０６と同様である。その後、該当するデバイスＩＤに関して、機種依存デバイスマスタ情報を参照し、内容に変更がなかったか、その他、デバイス監視モジュールに発行するリクエストがないか判定する。この判定は、例えば管理者による内容の変更時に、変更された項目に関して更新された旨を示す更新フラグをセットし、それがデバイスに通知された際にその更新フラグをリセットするなどの操作を行うことで、実現できる。この更新フラグが後述の図１０の１１１９に対応する。

本例では、ここで機種依存デバイスマスタデータの通知設定情報が更新されていると判定する。これによって該当するデバイスのデバイス監視モジュールに対し、再度通知設定情報を構成し直す必要があることがわかる。そこで、Ｓ２１９で、管理サーバ１０６は、通知設定情報リクエストの発行を促す要求（単にリクエスト、又は、通信リクエストと呼ぶこともある）をデバイス監視モジュールに送信する。なおS２１９で具体的にどのようなリクエストの発行を管理サーバ１０６からデバイス監視モジュールに発行するかは、その都度のデータベース内容により適宜変更される。図２ではgetConfiguration(request)が示されている。Ｓ２２０においては、コマンド発行リクエストを受けたデバイス監視モジュールは、管理サーバ１０６に対して、通知設定情報リクエストの通信を行う。

Ｓ２２２において、通知設定情報リクエストを受信した管理サーバ１０６は、対象デバイスの機種依存デバイスマスタデータを読む。そして、基本スケジュール設定と、エラー、パーツ、アラームの情報を送信するようにデバイス監視モジュールへ送信情報の設定を行う。

＜管理サーバ１０６のソフトウエア構成例＞
図４は、管理サーバ１０６における、デバイス監視モジュールへの適切な通知設定情報の作成および発行を行うアプリケーションプログラム４００の機能を示すブロック図である。

アプリケーションプログラム４００は、ユーザからマスタデータの入力を受け付けるマスタデータ入力部４０３を有する。マスタデータは２種類存在する。第１の種類は、デバイスの機種に依存した機種依存デバイスマスタデータである。機種依存デバイスマスタデータは、例えばデバイスの製品名や製品スペックなどデバイスの基本的な機種の情報や、エラーやアラームなどデバイス機種に依存するコード情報を含む。第２の種類は、監視対象となるデバイスのデバイスＩＤや設置場所である顧客の情報など、監視対象であるデバイスに固有の情報である監視対象デバイスマスタデータである。アプリケーションが通知設定情報の発行は、２種類のマスタデータを参照して行われる（後述の図１３で詳しく説明）。また、マスタデータの入力は、例えばデバイスの製造者が提供するプロファイルデータの読み込みや、あるいはユーザによる手動操作で実現される。

また、アプリケーションプログラム４００は、入力されたマスタデータをマスタデータ記憶部４０１へ保管処理するマスタデータ入出力部４０２を有する。

また、アプリケーションプログラム４００は、デバイス監視モジュール４２０との通信を行う通信Ｉ／Ｆ部４０４と通信コマンド解釈部４０７とを有する。通信コマンド解釈部４０７は、デバイス監視モジュール４２０から受信したデータから、デバイス監視モジュール４２０の識別ＩＤや通信コマンドを取り出す。又通信コマンド解釈部４０７は、デバイス監視モジュール４２０へ送信する、通信用フォーマットに従った形式のデータを生成する。

また、アプリケーションプログラム４００は通知設定情報発行部４０５を有する。通知設定情報発行部４０５は、デバイス監視モジュール４２０に新規の通知設定情報を送信する必要があるか、また、送信スケジュールを要求されたときに、対象のデバイス監視モジュール４２０に適切な通知設定情報を作成する。この通知設定情報発行部４０５はマスタデータ入出力部４０２から、機種依存デバイスマスタ情報と監視対象デバイスマスタ情報を呼び出し、デバイス監視モジュール４２０にとって適切な送信設定を決定する。

さらに、アプリケーションプログラム４００は、デバイスデータ取得部４０８と、取得データ入出力部４０９と、取得データ記憶部４１０と、取得データ表示部４０６とを有する。デバイスデータ取得部４０８は、通常監視状態においてデバイス監視モジュール４２０から受信するデバイスステータスデータを通信コマンド解釈部４０７から受け取る。取得データ記憶部４１０は、デバイスデータ取得部４０８で取得したデバイスステータス情報を格納する。取得データ入出力部４０９は、取得データ記憶部４１０への入出力処理を管理する。また、取得データ表示部４０６は、ユーザへデバイスから取得したステータスデータを表示する。

＜本実施形態に係わるデータ及びプログラム＞
以下、管理サーバ１０６及びデバイスで処理されるプログラム、データについて詳しく説明する。まず、以下の１．及び２．で管理サーバ１０６におけるデータベースの全体概要、及び、処理されるプログラム及びデータについて図５、６を併用しながら説明する。また、以下の７．でデバイスにより処理されるプログラム及びデータについて図１２を併用して説明す。また、以下の３．及び４．で管理サーバ１０６からデバイス側に送信される情報を図７、８を併用して説明する。そして最後に、１．で説明した管理サーバ１０６におけるデータベースの詳細を図９、１０を併用して説明する。

＜１．管理サーバ１０６の全体データベース例＞
図５は、図３のＲＯＭ３０３又は記憶装置３０８に不揮発的に記憶されるプログラム及びデータの構成例を示す図である。尚、図５には、本実施形態に関連深いプログラム及びデータのみを示し、他は省略している。ただし、図５に示すマスタデータは更新されるため、ＲＯＭに格納する場合には、書き替え可能なＲＯＭを用いる必要がある。

図５においてシステムプログラム５０１はＯＳ等の装置の基礎的な制御を行なうプログラムである。デバイス管理プログラム５０２は、管理サーバ１０６のデバイス管理全体を制御する。かかるデバイス管理プログラム５０２の本実施形態に関連する部分は、以下に図１３，図１４，図１５，図１６を参照して説明される。ユーザインターフェースプログラム５０３は、ユーザからのマスタデータ入力あるいはデバイス状態の表示出力などを制御する。ユーザインターフェース・プログラム５０３は、ユーザからの入力されたマスタデータを所定のデータベースへ保管する。ユーザ／管理デバイス／認証プログラム５０４は、マスタデータを入力するユーザ又はデバイスステータスデータを送信するデバイス監視モジュールを認証する。

メッセージ送受信プログラム５０５は、デバイス監視モジュールとの間でインターネット１１０を介してコマンドを含むメッセージ送受信の制御をする。受信コマンド解析プログラム５０６は、デバイス監視モジュール４２０から受信したメッセージに含まれるコマンドを解析して、それに対応する処理の実行を指示する。処理プログラム５０７は、受信コマンド解析プログラム５０６の解析結果に対応して実行される。例えば、受信したコマンドがコマンド取得リクエストと解析されれば、リクエスト送信処理プログラム５０８を実行する。また、通知設定情報の受信と解析されれば、通知設定情報送信処理プログラム５０９を実行する。あるいは、デバイスのステータス受信と解析すればステータス受信処理プログラム５１０を実行する。ここには、本実施形態に関連する受信コマンドを示したが、これに限定されない。

機種依存データベース（以下機種依存ＤＢと略記）５１１は、管理サーバ１０６で保管する機種依存デバイスマスタデータのデータベースである。機種依存ＤＢ５１１には、デバイス依存マスタデータが登録される。例えば、本実施形態ではデバイス機種情報、デバイスの製品名称やスペックを表すデバイス機種基本情報５１２、機種別のエラー情報をあらわすデバイス機種依存エラー情報５１３などが登録される。また、機種別のアラーム情報をあらわすデバイス機種依存アラーム情報５１４、その他、デバイス機種依存ジャム情報５１５、デバイス機種依存パーツ情報５１６なども登録される。

監視対象データベース（以下監視対象ＤＢと略記）５１７は、管理サーバ１０６で保管する監視対象デバイスマスタデータのデータベースである。監視対象ＤＢ５１７には、本実施形態では監視対象デバイスの識別子となるデバイス識別ＩＤ５１８や、監視対象となるデバイスの機種情報５１９などが含まれる。管理サーバ１０６は、このデバイスの機種情報５１９により対応する機種依存デバイスマスタデータとの関連付けを特定することができる。その他、データベースに登録を行ったが、監視を無効にしておくことのできる監視対象有効フラグ５２０、監視対象の通知設定情報を保存しておく送信設定情報５２１なども含まれる。

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

デバイスＩＤ６０１は、デバイス監視モジュール４２０から送信されるデバイスのＩＤである。通信入力メソッド６０２は、デバイス監視モジュール４２０が送信してくる入力メソッドを表している。入力メソッドは例えばコードで表されている。図２の通知設定情報リクエスト（Ｓ２０８）やコマンド取得リクエス（Ｓ２１６）などは、入力メソッドの例である。入力データ６０３は、デバイス監視モジュールが送信してくる入力データである。例えば、入力メソッドがカウンタの入力を意味するコードであれば、入力データ部には、受信したカウンタ番号とカウンタ値とが格納される。図２の例では、データ送信（Ｓ２１１）で送られるデータがその例である。

通知設定情報６０４には、対象デバイスに関連付けられた機種依存デバイスマスタデータ（保守情報）が、機種依存ＤＢ５１１から抽出されて保存される。６０５には、対象デバイスに関連付けられた監視対象デバイスマスタデータが、監視対象ＤＢ５１７から抽出されて保存される。アプリケーションプログラム４００は、デバイス監視モジュール４２０から通知設定情報リクエストを受信すると、対象のそれぞれのマスタデータのデータベース５１１，５１７を参照する。

そして、通知設定情報リクエストの送信元のデバイス監視モジュールに適切な通知設定情報を決定し、作成する。ここで作成した通知設定情報は、設定情報領域６０６に出力される。ここで出力される情報が図７に示されている。この設計情報領域６０６に通知設定情報を出力するタイミングは、１１１９のフラグが更新を示す場合である。

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

＜３．管理サーバ１０６からデバイス側に送信される通知設定情報＞
図７は、管理サーバ１０６からデバイス監視モジュール４２０へ送信される通知設定情報を模式的に表した図である。図７で、通知設定情報７０２は、管理サーバ１０６が受信した通知設定情報リクエストに対応した応答である。通知設定情報７０２は、図２のＳ２０８，Ｓ２２０において受信する通知設定情報リクエストに対する応答である。

通知設定情報７０２には、通知設定情報のヘッダ情報が含まれる。このほか通知設定情報７０２には、以下のように、データタイプを示す情報、各データタイプに属するデータを示すための情報（データＩＤ）、また各データに関する送信設定（オンまたはオフ）、スケジュール通信の間隔等の情報が含まれている。

その具体例として、タイプデータ７０３は、イベントタイプであることを示すデータである。例えば予め定めた値のコードが割り当てられる。イベントタイプとは、該当するイベントが発生した場合に、速やかに送信されるデータであることを示す。それに続けて、データ内容（データＩＤ）と、送信設定とが含まれる。図７では、イベントタイプのデータとして、機種依存エラーコード７０４が含まれている。また、送信設定７０５には、デバイス監視モジュールから機種依存エラーコード７０４を管理サーバに対して送信する（オン）か否（オフ）かを示す送信設定が関連づけられている。図７では送信設定７０５の値はオンである。データ７０３，７０４，７０５は、デバイス監視モジュール４２０に対して、監視対象であるデバイスにエラーが発生した場合には、即時に管理サーバに送信を行うということを指示している。また、データ７０６，７０７，７０８は、監視対象であるデバイスにアラームが発生した場合でも、情報を管理サーバに送信しないということを示している。データ７０９，７１０，７１１は、監視対象であるデバイスにジャムが発生した場合には、ジャムというイベント発生後、即時に管理サーバに送信を行うということを示している。

データタイプ７１５は、スケジュールタイプであることを示すデータである。それに続くデータＩＤ７１６には、スケジュールタイプのデータＩＤとして、印刷カウントデータのデータＩＤが含まれる。また、送信設定７１７には、送信設定として「オン」の値が含まれている。スケジュールタイプについては、送信されるスケジュールが更に含まれている。開始日時７１８には、スケジュール送信を行う上で、基準となる送信開始日時が含まれる。送信間隔７１９には、スケジュール送信を行う際の送信間隔時間が含まれる。データ７１５，７１６，７１７，７１８，７１９では、監視対象デバイスの印刷カウンタデータは、指定された送信開始日をはじめとして、指定の送信間隔でスケジュール通信として、送信を行うという事を示している。データ７２０，７２１，７２２，７２３，７２４は、監視対象デバイスの設定情報は、指定の送信開始日をはじめとして、指定の送信間隔でスケジュール通信として、送信を行うという事を指示している。データ７２５，７２６，７２７，７２８，７２９では、デバイス監視モジュール４２０自身が、管理サーバ１０６に対して、コマンド取得リクエスを行うように指示している。このときの送信開始日時と、送信間隔も、その他の通信と同様に、指定している。

＜４．管理サーバ１０６からの応答情報＞
図８は、管理サーバ１０６がデバイス監視モジュールから受信したコマンド取得リクエストに対する、管理サーバ１０６によるデバイス側への応答である。応答８０１には、応答であることを示すコードが含まれる。応答８０１は図２のＳ２１９に相当する。

フィールド８０２は、管理サーバ１０６がＳ２１６に対応してコマンド取得リクエストを受信成功したか、失敗したかを示すコードである。フィールド８０３は、処理を完了した日時である。フィールド８０４は、受信失敗時の詳細説明である。フィールド８０５は、コマンド情報（例えば図２のgetConfiguration(request）に相当）である。これは、監視対象デバイスに指示するべきコマンドがある場合に出力される。

＜５．機種依存デバイスマスタデータの例＞
図９は、図５で説明した機種依存デバイスマスタデータＤＢ５１１の詳細を示す。

図９の機種依存データベース９０１は、機種依存データベースの一部を表しており、ＰｒｏｄｕｃｔＡという製品に関する機種情報が格納されている。デバイス機種基本情報９０２には、ＰｒｏｄｕｃｔＡのデバイス機種情報と共に、対応する仕様に関する情報が保管されている。仕様に関する情報には、例えば、デバイスのクラス情報や、１分間に何枚のプリントができるのか、カラー機なのか、白黒機なのか、といった製品の基本スペック情報が含まれる。トナー情報９０３は、対象デバイスで使用できるトナーの情報である。カラー機であった場合には、各色のトナー製品情報９０４，９０５，９０６，９０７が保管される。ここには、製品名の情報だけでなく、推奨寿命枚数などのトナー属性情報も一緒に保存される。

エラー情報９０８には、ＰｒｏｄｕｃｔＡ製品に実装されているエラーコードに関する情報が保存されている。フィールド９０９、９１０には、各エラーコードと、そのエラーコードの説明・対応方法などが関連付けられて保存されている。フィールド９１１には、ＰｒｏｄｕｃｔＡ製品に実装されているアラームコードに関する情報が保存されている。フィールド９１２，９１３では、各アラームコードと、そのアラームコードの説明・対応方法などが関連付けられている。フィールド９１４には、ＰｒｏｄｕｃｔＡ製品に実装されているジャムコードに関する情報が保管されている。フィールド９１５、９１６では、各ジャムコードと、そのジャムコードの説明・製品のどの場所でジャムが発生しているのかなどの情報が関連付けられている。フィールド９１７、９１８、９１９では、各パーツコードとそのパーツコードの説明・パーツ製品名・推奨寿命などの情報が関連付けられている。また、フィールド９２０、９２１には、この機種依存マスタがいつ作成されたのか、いつ更新したのかなどの情報が保存される。

＜６．監視対象デバイスマスタデータの例＞
図１０は、図５で説明した監視対象デバイスマスタデータＤＢ５１７の詳細を示す。

図１０の監視対象データベース１１０１は、監視対象デバイスマスタデータの一部を表しており、監視対象デバイスＡというデバイスに関するデバイス情報が格納されている。フィールド１１０２には、監視対象デバイスＡのデバイスＩＤが保存されている。管理サーバ１０６は、デバイス監視モジュールが送信してくるデバイスの情報と、このデバイスＩＤの情報とを利用して、受信したデバイスの情報がどのデバイスの情報なのかを判断する事ができる。フィールド１１０３には、監視対象デバイスＡの製品情報が格納される。この製品情報は、図９の機種依存デバイスマスタと関連付けられ、監視対象のデバイスのエラー情報やアラーム情報、その他の属性情報が、この製品情報を通じて利用可能となる。

フィールド１１０４は、監視対象として、有効にするか、無効にするかを設定する事のできるフラグを意味している。例えば、一時的に管理サーバ１０６で監視対象からはずしたい場合などに、このフラグをオフにすることで監視対象から外れる事になる。また、例えば、監視対象有効フラグ１１０４が「有効」から「無効」に変更された場合には、デバイス監視モジュールから、デバイスに関するデータは送信する必要がなくなる。これを受けて管理サーバ１０６のアプリケーションプログラム４００は、全てのデバイス情報の送信設定をオフに変更する。しかし、また監視対象フラグが「無効」から「有効」へと変更されることもあり得るので、コマンド取得リクエスはスケジュールしておく必要がある。

フィールド１１０５は、監視対象デバイスに関する、現在の通知設定情報を格納する場所である。このほか、監視対象デバイスには、どのバージョンのファームウェアが実装されているかを格納する場所等も含まれる。

フィールド１１０６は、監視対象デバイスの顧客情報を保存する。フィールド１１０７、１１０８、１１０９のそれぞれに、顧客名、担当者名、設置場所を保管することによって、デバイスに緊急のエラーが発生した場合でも、すぐに、対象のデバイスがどの顧客の所有物なのかをシステムユーザに通知する事ができる。フィールド１１１０は、監視対象デバイスのネットワーク情報を保管する。フィールド１１１１、１１１２、１１１３には、それぞれ監視対象デバイスのデバイス名やＩＰアドレス、ＭＡＣアドレスなど保存する。フィールド１１１４は、監視対象デバイスの顧客先管理担当者の情報（管理者情報）を保管する。フィールド１１１５、１１１６には、顧客先でデバイスそのものの調子を管理している管理者の名前とメールアドレスを保管する。また、１１１７、１１１８には、顧客先で、デバイスのトナーなどの消耗品を管理している管理者の名前とメールアドレスを保管する。

フィールド１１１９には、機種依存デバイスマスタと監視対象デバイスマスタをあわせて、スケジュール通信を変更するべき情報が更新されたかどうかを示すフラグ情報が保管される。この１１９の設定値更新フラグは機種依存デバイスマスタ及び監視対象デバイスマスタのいずれか又は双方が更新された場合に更新を示すフラグが設定される。

このようにデバイスのステータス情報が変化すると、管理サーバ１０６で必要な情報も変化する。これによって、デバイス監視モジュールへスケジュール変更の依頼を行うが、依頼の必要になった時に、この設定値変更フラグをつけておく。１１２０、１１２１には、このテーブルがはじめて作成された日時や、最終更新の日時が保管される。

＜デバイスのハードウェア構成ブロック図＞
図１１は、デバイス内の制御部のブロック図である。ここではデバイス内でデバイス監視モジュールが処理を行う例を表している。デバイス監視モジュールはデバイス内の制御部１７００内で処理され、デバイスの個別情報の管理や、デバイスのステータス情報を管理サーバに送信するなどの処理を行う。デバイスの制御部１７００では、主として、プリントやスキャンなどプログラムの制御処理を行い、そのほかに、デバイス監視モジュールなどの各アプリケーションが制御されている。

制御部１７００の各構成要素は、システムバス１７１６及び画像バス１７１７に接続されている。 ＲＯＭ１７０４にはデバイスの制御プログラム及び、デバイス監視プログラムが格納されており、ＣＰＵ１７０７で実行される。 ＲＡＭ１７０５は、プログラムを実行するためのワークメモリエリアであり、デバイス監視プログラムが監視を行ううえで必要なデバイスのステータス情報や、画像データを一時記憶するための画像メモリでもある。記憶装置１７０６は不揮発性の記憶装置であり、複写機１０１の再起動後も保持しておく必要のある各種動作モード設定や、カウンタ値、稼働ログなどが記憶される。ネットワークＩ／Ｆ１７０２はＬＡＮと接続するためのインタフェース部であり、ＬＡＮを介して管理サーバと通信を行う。回線Ｉ／Ｆ部１７０３は、ＩＳＤＮや公衆電話網に接続され、ＲＯＭ１７０４内の通信制御プログラムにより制御され、ＩＳＤＮ Ｉ／Ｆやモデム、ＮＣＵ（ネットワークコントロールユニット）を介して遠隔の端末とデータの送受信を行う。ファクシミリの送受信もこの回線Ｉ／Ｆ部１７３０を使用して行う。操作部１７０１には表示手段やキー入力手段が内蔵されており、これらはＣＰＵ１７０７にて制御される。操作者は、キー入力手段を通してスキャナ読み取りやプリント出力に関する各種設定指示や、作動／停止指示を行う。

以上のデバイスがシステムバス１７１６上に配置される。 ＩＯ制御部１７０８は、システムバス１７１６と画像データを高速で転送する画像バス１７１７とを接続するためのバスブリッジである。画像バス１７１７は、ＰＣＩバスまたはＩＥＥＥ１３９４で構成される。画像バス１７１７上には以下のデバイスが配置される。デジタルＩ／Ｆ部１７１１は、デバイスのリーダ部１７１５やプリンタ部１７１４と制御部とを接続し、画像データの同期系／非同期系の変換を行う。また、リーダ部１７１５やプリンタ部１７１４内の各所に配置した前述の各種センサが検出した情報は、このデジタルＩ／Ｆ部１７１１、及びＩＯ制御部１７０８を介してシステムバス１７１６へ流れる。画像処理部１７０９は、入力及び出力画像データに対し補正／加工／編集を行う。画像回転部１７１０は画像データの回転を行う。画像圧縮伸長部１７１２は、多値画像データはＪＰＥＧ、２値画像データはＪＢＩＧ／ＭＭＲ／ＭＲ／ＭＨの圧縮伸張処理を行う。画像密度変換部１７１３は、出力用画像データに対して解像度変換等を行う。

ＣＰＵ１７０７で実行される制御プログラムにより、ＣＰＵ１７０７は記憶装置１７０６内のカウンタ値や稼働ログなどの稼動情報や障害情報を読み出してデバイスのステータス情報として管理サーバ１０６へ、ネットワークＩ／Ｆ１７０２を介して送信する。

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

システムプログラム１８０１はＯＳ等の装置の基礎的な制御を行なうプログラムである。１８０２はデバイスの管理を制御するデバイス管理プログラムである。メッセージ送受信プログラム１８０３は、管理サーバ１０６から設定指示等を受信する、または、デバイスのステータス情報やコマンド取得リクエストを管理サーバ１０６へ送信するための送受信を制御する。

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

各種プログラム１８０６は、通知設定情報解析プログラム１８０５の解析結果に対応して実行される。例えば、イベント情報送信処理プログラム１８０７は、デバイスでイベントが発生した場合には、イベントデータを管理サーバ１０６に送信するタイミングを決定し、決定したタイミングでイベント情報送信処理を実行する。例えば、そのタイミングは、イベント発生後、所定の期間内（例えば直ちに）にそのイベントの発生を通知するメッセージを管理サーバ１０６に送信する。また、スケジュール送信処理プログラム１８０８はメッセージを送信し、カウンタ情報送信処理プログラム１８０９はカウンタ情報を送信する。スケジュール設定変更処理プログラム１８１０は、デバイス監視モジュールが管理している通知設定情報を、管理サーバ１０６から受信した最新の通知設定情報で更新する。

デバイスＩＤ１８１１は、デバイスを管理サーバ１０６内で識別するためのデバイスＩＤを表している。また、記憶装置内には、デバイスの状態が保管してあるデバイス状態ＤＢ１８１２が管理されている。この中には、デバイスのファームウェアやデバイスのタイプなどデバイスの基本情報１８１３などが保存されている。このほか、今までに発生したエラー情報１８１４、アラーム情報１８１５、ジャム情報１８１６などのイベント情報、パーツの消耗度１８１７（パーツ情報）なども保存されている。また、デバイスのカウンタデータＤＢ１８１８には、課金カウンタ１８１９や機能カウンタ１８２０など、デバイスの状態を示す値の内、特にカウンタ類が保存されている。記憶領域１８２１は、図１７に示したプログラム（後述）をＣＰＵ１７０７が実行するためロードする記憶領域である。なお、図１２におけるエラー情報、アラーム情報、ジャム情報、パーツ情報は管理サーバ１０６側における保守情報としてのそれらとは区別され、エラー、アラーム、ジャム、パーツ消耗の履歴又は一時記憶情報を指すものとする。

なお図１１ではデバイス監視モジュールはデバイスに内蔵されているため、デバイスＩＤがデバイス監視モジュールのＩＤを兼ねる。しかし、両者が別体の場合には、デバイス監視モジュールが管理サーバの認証を受けるために、デバイス監視モジュールに固有のＩＤがデータベースに用意されている。

＜フローチャートの説明＞
以下では、まず本実施形態における管理サーバ１０６のデバイス監視に係わるメインのフローチャートを図１３を用いて説明し、その後に、メインフローチャートにおける各ステップの詳細を、図１４乃至１７を用いて説明する。

＜本実施形態の管理サーバ１０６のデバイス監視動作例＞
上記構成に基づいて、本実施形態の管理サーバ１０６のデバイスを監視する動作例を説明する。尚、以下の動作例では、処理を単純化するために、単一のデバイス監視モジュールがデバイスを監視するものとして説明する。しかし、実際には、複数のデバイス監視モジュールがデバイスを監視していることもあり得る。その場合には各デバイス監視モジュールに対して、以下に説明する処理を実行する必要がある。

本動作例では、デバイス監視モジュールから何らかの通信があった場合に管理サーバ１０６が通信メソッドを認識し、デバイス監視モジュール４２０からの送信すべき情報が管理サーバ１０６にとって必要十分な情報となるように送信設定を指示する例を示す。

図１３は、管理サーバ１０６がデバイス監視モードにあるときに、デバイスからリクエストを受けた場合の振る舞いに関するフローチャートである。ここでのデバイス監視モードとは、図２におけるS２０１乃至S２２９における各ステップの外部からのデータ入力を監視する処理全てを含むものとする。また、図１１は、管理サーバ１０６が、管理者から機種依存デバイスマスタデータの更新を受けたときに振る舞い、または、ユーザによる監視対象デバイスの登録のリクエストを受けたときの振る舞いに関する処理を表す。なおリクエストとは、デバイス監視モジュールから管理サーバ１０６に対して送信される要求メッセージであり、通信テストや通知設定情報に従ったデータ送信等を含む。

このフローチャートで表す動作例は、管理サーバ１０６内のデータベースの設定値によって、デバイス監視モジュールに適切な通信設定を管理サーバ１０６が自動的に決定し、設定情報を送信することを特徴とする。

また、ここでの動作例では、デバイス監視モジュールはデバイスに内蔵されているものとして、管理サーバ１０６はデバイスと通信を行うものとする。

まずＳ１３０１は、管理サーバ１０６の内部処理であるループの開始を表している。これによって、管理サーバ１０６はデバイスの監視モードに入る。Ｓ１３０２にて、管理サーバ１０６は、ネットワークＩ／Ｆを通じてデバイスから通信を受信したか否か判定する。ここで想定されるデバイスからの通信は、図２のＳ２０４、Ｓ２０８、Ｓ２１２、Ｓ２１６、Ｓ２２０等が想定される。デバイスからの通信があった場合には、Ｓ１３０５へ進み、通信相手であるデバイスは、管理サーバ１０６内に登録されているデバイスＩＤと一致するか判定する。デバイスからの各種リクエストには、デバイス識別子（デバイスID）が含まれており、詳細にはこの各種リクエストの各々に含まれるデバイス識別子が管理サーバ１０６内のDBに登録されているか否かを検索・判定する。なお、S１３０２の判定対象となる、デバイス識別子としては、デバイス監視モジュールIDに代用することもできるが、以下では、デバイス識別子としてデバイスIDを例に説明を行っていく。

一方ステップ１３０２にて、管理サーバ１０６がデバイスから通信を受信しなかった場合に、Ｓ１３０３へ進み、管理者による操作等に応じて機種依存データベース５１１の更新があるか判定する。管理サーバ１０６は、Ｓ１３０３で、機種依存データベース５１１の更新があった場合に、Ｓ１３０６へ進み、更新された機種と関連するデバイスのマスタデータを監視対象データベース５１７から抽出する。例えば更新された機種依存マスタデータに含まれるデバイス機種基本情報９０２と一致するデバイス機種情報１１０３を持つ監視対象マスタデータを、関連するデバイスのマスタデータとして抽出できる。そして、その抽出した監視対象デバイスマスタデータの設定値更新フラグ１１１９をセットする。

機種依存データベース５１１が更新された場合には、更新された機種に関連するデバイスは通信内容に影響を受ける。そのため、対象となるデバイスの設定値更新フラグ１１１９（図１０）をセットする。例えば、ある機種のアラーム情報が追加された場合には、今後管理サーバ１０６で対象機種のアラーム情報をコントロールする事ができるようになる。そこで、デバイスから管理サーバ１０６に対してアラーム情報を送信するようにデバイスの通知設定情報を更新する必要がある。ここでは、管理サーバ１０６からデバイスに対して主体的に通知設定情報を更新することはできないので、デバイスから通信があるのを待ち、デバイスからの通信を機械に更新を行う。そこで機種依存データベースが更新されていることをデータベース内に記録しておくために、Ｓ１３０６では、設定値更新フラグをセットしておく。

この処理が終わると、Ｓ１３１２へ進み、ループの最初のステップであるＳ１３０１へ戻る。Ｓ１３０３にて、管理者による機種依存マスタの更新がなかった場合に、Ｓ１３０４へ進む。Ｓ１３０４では、管理サーバ１０６はユーザによる監視対象データベースの更新があるか判定する。管理サーバ１０６は、Ｓ１３０４にて、ユーザによる監視対象データベースの更新があると判定された場合には、Ｓ１３０７に進む。監視対象データベースへの更新が、通知設定情報の更新を必要とする更新であった場合に、監視対象デバイスの設定値更新フラグ１１１９をセットし、対象デバイスからの通信に備える。

Ｓ１３０４にて、ユーザからの更新がないと判定された場合には、Ｓ１３１２へ進み、監視モードのループへ戻る。Ｓ１３０７にて、設定変更フラグをセットした後に、Ｓ１３１２へ進み、監視モードのループへ戻る。

Ｓ１３０５にて、リクエストを送信してきたデバイスの識別子（デバイスＩＤ）が、管理サーバ１０６の管理する監視対象データベースに登録されているか判定する。ここで、登録されていなかった場合には、Ｓ１３１１へ進み、未登録デバイス用の通信処理を行う。デバイスは、通常、その設置前にまず管理サーバ１０６に監視対象デバイスを登録してから、顧客サイトにデバイスを設置し、デバイスから管理サーバ１０６へ通信を行う。しかし必ずしもそのように運用が行われるとは限らず、デバイスの設置が最初に行われ、デバイスの登録を行う前に、デバイスからの通信が先に行われてしまうことがある。このようなケースでは、顧客側で設定処理を終わらせてしまって、登録が行われた段階で、管理を始めればいい。実際の管理システムの処理としては、Ｓ１３１１にて記述するような処理を行う。また、未登録デバイス通信処理は、図１５で説明を行う。

Ｓ１３０５にて、リクエストの発行元デバイスの識別子が監視対象デバイスマスタに登録されている場合には、Ｓ１３０８へ進む。Ｓ１３０８において管理サーバ１０６は、そのリクエストに含まれるメソッドを参照して通信テストのリクエストか否かを判定する。Ｓ１３０８で、受信したリクエストが通信テストであった場合には、S１３１３、S１３１４を実行した後、Ｓ１３１０へ進む。Ｓ１３１０において管理サーバ１０６は、デバイス監視モジュールから送信されてくる通知設定情報リクエストの（ｇｅｔＣｏｎｆｉｇｕｒａｔｉｏメソッド）の通信処理を行う。この通知設定情報リクエストは、図２のＳ２０８に相当する。また、Ｓ１３０８にて、通信メソッドが通信テストでないと判定された場合には、Ｓ１３０９へ進みスケジュール系通信処理を行う。これら、ｇｅｔＣｏｎｆｉｇｕｒａｔｉｏｎ通信処理と、スケジュール系通信処理に関しては、それぞれ図１４及び図１６のフローチャートで説明を行う。

＜Ｓ１３１０の詳細フローチャート＞
図１４は、図１３のＳ１３１０の通知設定情報リクエスト（ｇｅｔＣｏｎｆｉｇｕｒａｔｉｏｎ）通信処理の詳細処理を表す。ｇｅｔＣｏｎｆｉｇｕｒａｔｉｏｎ通信処理が開始されると、Ｓ１４０１にて、監視対象デバイスマスタの有効無効ステータスを、監視対象有効フラグ１１０４を参照して判定する。対象デバイスの監視対象有効フラグが「無効」であった場合には、Ｓ１４０２へ進む。Ｓ１４０２では、全通信機能のうち、コマンド取得リクエスのみ送信する通知設定情報を作成し、通信の応答として通知設定情報を対象デバイスへ送信する。このようにすることで、現在管理対象でないデバイスからの通信を最小限に抑えることができる。また、コマンド取得リクエスを設定する理由は、将来、監視対象有効フラグ１１０４が有効になった場合に、再度、対象デバイスの送信設定を変更し、必要なデータを送信するようにコントロールを行う必要があるからである。S１４０１で検索されたデバイスIDに対して監視対象として無効の設定がなされていると、Ｓ１４０２にて、状態コードの通知を行うことなくコマンド取得リクエストのみを送信をデバイスに行わせる通知設定情報の作成する。そして、作成した通知設定情報をデバイスに対して遠隔指示する。そして、図１４でのｇｅｔＣｏｎｆｉｇｕｒａｔｉｏｎ通信処理を終了する。

Ｓ１４０１にて、該当デバイスが有効の状態であった場合には、Ｓ１４０３へ進み、対象デバイスの機種情報から、該当する機種依存デバイスマスタデータを読みだす。ここでS１４０１でYESと判定する場合として、一旦、S１４０２の遠隔指示を行った後に、同一デバイスIDのデバイスについて、再度、監視対象として有効である設定がなされた場合がある。例えば、ユーザ先のデバイスの遠隔監視を一時的に停止し、その後に、再度遠隔監視を開始する場合がこれに相当する。

次にＳ１４０４へ進み、機種依存マスタデータを参照して、通知設定情報を作成し（図７参照）、それをデバイスに送信する。そのためには、例えば図７のフォーマットを予めテンプレートとして用意しておき、属性情報の有無に合わせて送信設定のオン／オフを切り替えればよい。送信開始日時が必要な属性情報については、例えば、現在の時間を送信開始日時としてセットする。送信間隔が必要な属性については、予め決められた長さを送信間隔としてセットする。

なお、図１２では、Ｓ１４０４以降を、以下の説明のように実行している。すなわち、Ｓ１４０４では全ての属性情報を管理サーバ１０６が処理できるか判定する。処理できると判定された場合、Ｓ１４０５へ進む。属性情報がすべて処理できない場合には、Ｓ１４０６へ進む。Ｓ１４０５では、通信を行ってきたデバイスに対し、管理サーバ１０６が管理を行う事のできる全ての機能を有効にする通信設定を行い、通信の応答として、対象のデバイスに送信設定情報を送信する。Ｓ１４０６では機種依存デバイスマスタに登録してある属性情報をベースにコントロールのできる通信種類を決定し、リクエストを行ったデバイスに対して応答として送信設定情報を指示（送信）する。それぞれのステップでデバイスに送信設定を返す事でｇｅｔＣｏｎｆｉｇｕｒａｔｉｏｎの通信処理を終了する。なお、ここでのコントロールできるとは、管理サーバ１０６が、デバイスから何れかの種類の状態コードを受信した場合に、該受信した状態コードに対応した保守情報をデータベースから取得し、オペレータ等のユーザに対応すべき情報を提示できることを指す。

＜Ｓ１３１１の詳細フローチャート＞
図１５は、図１３のＳ１３１１の未登録デバイス通信処理の詳細処理を表す。未登録デバイス通信処理が開始されると、Ｓ１５０１にて受信したメッセージに含まれるメソッドが通信テストを意味するものなのか、それ以外のものなのか判定する。もし、メソッドが通信テストであった場合には、S１５０６、S１５０７を実行した後、Ｓ１５０３へ進む。Ｓ１５０３では、全通信機能のうち、コマンド取得リクエストのみを有効にした通知設定情報を作成し、通信の応答として作成した通知設定情報を送信する。これでデバイスに対して送信指示を完了する。また、Ｓ１５０１にて、通信テストでないと判定された場合、Ｓ１５０２へ進む。Ｓ１５０２では、受信したメッセージがコマンド取得リクエスかそれ以外かを確認する。ここで通信のタイプがコマンド取得リクエスであった場合には、Ｓ１５０４に進み、その通信に関しては何も処理を行わず、デバイスに対して正常に通信が完了したことを伝える情報を送信する。また、Ｓ１５０２にてメッセージがコマンド取得リクエスではないと判定されたときには、Ｓ１５０５へ進み、システムとデバイス間で障害が発生している可能性があるので、この事象をシステム管理者へ伝える通知を行う。この通知は例えばディスプレイや音声などのメッセージ出力により、システム管理者に伝達される。

＜Ｓ１３０９の詳細フローチャートスケジュール形通信処理＞
図１６は、図１３のＳ１３０９のスケジュール系通信処理の詳細処理を表す。スケジュール系通信処理が開始されると、Ｓ１６０１にて、通信の種類がコマンド取得リクエストなのか、それ以外なのかが判定される。この確認処理によって、通信の種類がコマンド取得リクエストだった場合には、Ｓ１６０２へ進む。またそれ以外の通信処理だった場合には、Ｓ１６０３に進む。

Ｓ１６０３では、監視対象デバイスマスタデータの監視対象有効フラグ１１０４を参照し、「有効」がセットされていた場合には、Ｓ１６０６へ進む。Ｓ１６０６では状態コードを含む通信データを受信し、図５に示されるデータベースに保存する。そして、デバイス監視モジュールに対しては、受信したデータが正常処理されたことを意味する返信を行う。

次にＳ１６１０にて、受信したデータ（状態コード）に関連付けられた保守情報を機種依存デバイスマスタデータDB５１１から読込み取得する。そして、取得した保守情報を出力する。保守情報の出力形態としては、ネットワークインターフェース３０５を介しての所定装置へのネットワーク通知、電子メール送信、表示部３０９へのモニタ表示等様々な可視化の為の出力形態を適用できる。

一方、Ｓ１６０３にてデバイスが無効状態に設定されていた場合には、Ｓ１６０７へ進み、受信データを破棄し、通信が正常に終了した事をデバイスに返信する。

S１６０２では、監視対象デバイスマスタデータの設定値更新フラグ１１１９を参照し、データベースに記憶された保守情報の更新を判定する。ここで設定値更新フラグがセットされていた場合には、Ｓ１６０５へ進み、通信対象デバイスに対して通知設定情報リクエスト（ｇｅｔＣｏｎｆｉｇｕｒａｔｉｏｎメソッド）を要求するメッセージを送信する（図２のＳ２１９）。その後、Ｓ１６０８で通知設定情報リクエスト（ｇｅｔＣｏｎｆｉｇｕｒａｔｉｏｎ）を受信したら、Ｓ１３１０のｇｅｔＣｏｎｆｉｇｕｒａｔｉｏｎ通信処理（図１４）を行う。この処理が完了したら、Ｓ１６０９にて、監視対象デバイスマスタデータの、対象デバイスの設定値更新フラグ１１０４をクリアする。

Ｓ１６０２にて、監視対象デバイスマスタの設定値更新フラグ１１０４がセットされていなかった場合には、Ｓ１６０４に進む。Ｓ１６０４では、通信データを正しく受信し、正常に処理が終了した事をデバイス監視モジュール伝える処理を行う。

上記の動作を行う事により、常に管理サーバ１０６は管理対象のデバイスからデバイスを管理するうえで必要十分な情報を受信することができ、ネットワーク帯域・ハードウェアリソースを無駄に使用することなく効率のよいデバイス監視を行う事ができる。

＜本実施形態のデバイスの動作例＞
図１１に示した構成に基づいて、本実施形態のデバイスの動作例を説明する。本動作例では、管理サーバ１０６からコマンド取得リクエストの返信として指示があったときに、デバイス監視モジュールが通信メソッドを認識し、メソッドによって異なる処理を実行する動作例を示す。

図１７は、デバイス監視モジュールに電源が入り、通常のデバイス監視モードになった時の振る舞い、または、管理サーバ１０６からコマンド取得リクエストを受信した場合の振る舞いに関する処理を表すフローチャートである。

Ｓ１９０１では、デバイス監視モジュールが起動し、通知設定情報を保持しているかどうかの判断をしている。ここで、通知設定情報を保持していた場合に、ステップ１９０２へ進み、デバイス監視モジュールは通常デバイス監視状態へ入る。Ｓ１９０１で、スケジュール送信設定情報を持っていなかった場合には、Ｓ１９１２へ進み、通知設定情報のリクエストを管理サーバ１０６に対して行う。

デバイス監視モジュールは、Ｓ１９０２にて通常監視状態に入ったのち、Ｓ１９０３で、通知設定情報中のコマンド取得リクエスの発行時期に達していないか判定する。コマンドリ取得クエストの発行時期に至っていない場合には、Ｓ１９１４へ進み、デバイスの状態を読み出す。そして、Ｓ１９１５でデバイス監視モジュールは、通知設定情報に基づき、その他のデバイスステータス情報を管理サーバ１０６へ送信する。

Ｓ１９０３にて、デバイス監視モジュールがコマンド取得リクエストの発行条件にマッチした場合には、Ｓ１９０４へ進み、管理サーバ１０６に対して、コマンド取得リクエスト（ｇｅｔＯｐｅｒａｔｉｏｎＬｉｓｔ）を送信する。Ｓ１９０５にて管理サーバ１０６からのコマンド取得リクエストを待機する。リクエストがなかった場合、例えばタイムアウトした場合には、処理を終了して、ループに戻る。管理サーバ１０６からリクエストを受信した場合にはＳ１９０６へ進み、そのメッセージの内容を解析する。解析の結果が、受信したリクエストがコマンド発行要求であった場合には、ステップ１９１１からＳ１９１２へ進み、通知設定情報リクエスト（ｇｅｔＣｏｎｆｉｇｕｒａｔｉｏｎ）を送信する。その後、Ｓ１９１３にて、管理サーバ１０６から通知設定情報を受信し、デバイス監視モジュール自身の通知設定情報として保存する。もちろんそのまま保存するのではなく、適当に加工して保存しても良い。その後、Ｓ１９１０にて、コマンド実行結果を管理サーバ１０６に送信し、処理を終了する。また、Ｓ１９１１にて、コマンド発行要求ではなく、その他のリクエストを受信した場合には、Ｓ１９０９にて、指示されたコマンドを実行し、Ｓ１９１０へ進む。Ｓ１９１０では、コマンドの実行結果を管理サーバ１０６に送信し、処理を完了させる。

Ｓ１９０１で、デバイス監視モジュールが起動後に通知設定情報を持っていると判定された場合には、Ｓ１９１２へ進み、通知設定情報リクエスト（ｇｅｔＣｏｎｉｇｕｒａｔｉｏｎ）を発行する。その後、Ｓ１９１３にて、受信した通知設定情報をデバイス監視モジュールの自身の通知設定情報として保存し、Ｓ１９１０へ進む。Ｓ１９１０では、コマンドの実行結果を管理サーバ１０６へ送信して、終了する。

以上の手順により本実施形態の管理サーバは、管理サーバの処理対象となる情報の種類に応じた属性情報をデバイス監視モジュールに送信させるべく、デバイス監視モジュールの持つ通知設定情報を更新できる。この通知設定情報の更新は、管理者やユーザの介入なしに行われる。そのため、デバイス監視モジュールから管理サーバに対して送信される情報には、管理サーバで破棄される無駄な情報が含まれず、無駄なネットワークトラフィックを抑制することができる。また管理サーバの処理資源も無駄に使用されず、処理効率の向上を図ることができる。

管理サーバにてマスタデータが準備できていないデバイスに関しては、そのデバイスからデータを受信しても、そのデータを活用することができない。従って、機種個別のマスタデータの登録がなされていないデバイスからの通知はサーバ側で取得しない設定にしている。これにより、ネットワークトラフィック、サーバのＣＰＵやメモリリソースなどを有効活用できる。

これに加えて、上述の実施形態では、機種個別のマスタデータが途中で新規に登録されたような場合に、その登録されたマスタデータを活用すべく、対応する通知を有効に変更できるので、ハードウェア・ネットワークリソースの効率的な運用を動的に行える。

なお本発明は、複数の機器（例えばホストコンピュータ、インターフェース機器、リーダ、プリンタなど）から構成されるシステムに適用しても、一つの機器からなる装置（例えば、複写機、ファクシミリ装置など）に適用してもよい。また本発明の目的は、前述の実施形態の機能を実現するプログラムコードを記録した記録媒体を、システムあるいは装置に供給し、そのシステムあるいは装置のコンピュータが記憶媒体に格納されたプログラムコードを読み出し実行することによっても達成される。この場合、記憶媒体から読み出されたプログラムコード自体が前述した実施形態の機能を実現することになり、そのプログラムコード自体およびプログラムコードを記憶した記憶媒体は本発明を構成することになる。

また、本発明には、プログラムコードの指示に基づき、コンピュータ上で稼働しているオペレーティングシステム（ＯＳ）などが実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれる。さらに、記憶媒体から読み出されたプログラムコードが、コンピュータに挿入された機能拡張カードやコンピュータに接続された機能拡張ユニットに備わるメモリに書込まれた場合についても、本発明は適用される。その場合、書き込まれたプログラムコードの指示に基づき、その機能拡張カードや機能拡張ユニットに備わるＣＰＵなどが実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される。

本実施形態の複写機、被管理装置及び管理サーバ１０６とのインターネットを介した接続関係を示す図である。 本実施形態のデバイス監視モジュールと管理サーバ１０６とユーザとの間の通信シーケンス例を表した図である。 本実施形態の管理サーバ１０６のハードウェア構成例を示すブロック図である。 本実施形態の管理サーバ１０６のアプリケーションプログラムの機能ブロック図である。 本実施形態の管理サーバ１０６の記憶構成例を示す図である。 本実施形態の管理サーバ１０６の記憶構成例を示す図である。 本実施形態の管理サーバ１０６から被管理装置へ送信される情報例を表した図である。 本実施形態のユーザが管理サーバ１０６を介して被管理装置へ入力したリクエストの例を表した図である。 本実施形態の管理サーバ１０６が保管する被管理デバイスの製品情報を表した図である。 本実施形態の管理サーバ１０６が保管する被管理デバイスの個別管理情報を表した図である。 本実施形態のデバイスのハードウェア構成例を示すブロック図である。 本実施形態のデバイスの記憶構成例を示す図である。 本実施形態の管理サーバ１０６がデバイスに送信データスケジュールを返信する際の全体の流れを表すフローチャートである。 本実施形態の管理サーバ１０６がデバイスからスケジュールリクエストを受信した際の流れを表すフローチャートである。 本実施形態の管理サーバ１０６が未登録のデバイスからリクエストを受信した際の流れを表すフローチャートである。 本実施形態の管理サーバ１０６がデバイスからデバイス監視を受信した際の流れを表すフローチャートである。 本実施形態のデバイスが管理サーバ１０６から設定コマンドを受けるときの流れを表すフローチャートである。

Claims (13)

1. 管理される複数の被管理装置と通信可能な管理装置であって、
   前記被管理装置から状態コードを受信する第１受信手段と、
   状態コードに関連付けられた保守情報を記憶する記憶手段から、前記第１受信手段により受信した状態コードに関連付けられた保守情報を取得する取得手段と、
   前記取得手段により取得した保守情報を出力する出力手段と、
   前記記憶手段に登録されたデバイス識別情報に対応するデバイスが監視対象として有効か無効かを設定する設定手段と、
   デバイス識別情報が前記記憶手段に登録されているか否かを検索する検索手段と、
   前記被管理装置から自発的に送信されてくる、前記管理装置が新たに送信すべき情報がないかの確認を行うための確認コマンドを受信する第２受信手段と、
   保守情報に対応した状態コードの通知設定を含む通知設定情報を前記被管理装置に送信する送信手段とを有し、
   前記送信手段は、前記検索手段による検索の結果、前記第２受信手段により受信した前記確認コマンドに含まれるデバイス識別情報が見つかった場合に、当該デバイス識別情報に関して監視対象として無効の設定がなされていると、前記状態コードの通知を行うことなく前記確認コマンドの送信を前記被管理装置に行わせる通知設定情報を、前記被管理装置に送信することを特徴とする管理装置。
2. 前記送信手段は、前記第２受信手段により再度、確認コマンドを受信した際に、前記検索手段により前記確認コマンドに含まれるデバイス識別情報が前記記憶手段から見つかり、且つ、該見つかったデバイス識別情報に関して監視対象として有効の設定がなされていた場合に、前記状態コードの通知を前記被管理装置に行わせる通知設定情報を前記被管理装置に送信することを特徴とする請求項１に記載の管理装置。
3. 前記記憶手段に記憶された保守情報の更新の有無を判定する更新判定手段と、
   前記送信手段は、前記更新判定手段により前記保守情報が更新されたと判定された場合に、更新後の保守情報に対応した状態コードの通知設定を含む通知設定情報を前記被管理装置に送信することを特徴とする請求項１または２に記載の管理装置。
4. 前記被管理装置から送信されるデバイスの設置確認通知を受信する第３受信手段と、
   前記第３受信手段により前記デバイスの設置確認通知を受信した場合に、前記被管理装置が前記管理装置に対して送信可能な状態コードのうち、前記記憶手段に記憶される保守情報が関連付けられて記憶されている状態コードを判断する判断手段とを更に有し、
   前記送信手段は、前記判断手段により保守情報が関連付けられていると判断された状態コードの通知設定を含む通知設定情報を、前記被管理装置に送信することを特徴とする請求項１乃至３のいずれか１項に記載の管理装置。
5. 前記被管理装置から送信されるデバイスの設置確認通知を受信する第３受信手段を更に有し、
   前記検索手段は、前記第３受信手段によって受信した前記デバイスの設置確認通知に含まれるデバイス識別情報が前記記憶手段に登録されているか否かを検索し、
   前記送信手段は、前記検索手段による検索の結果、対象のデバイス識別情報が前記記憶手段に登録されていなかった場合に、前記状態コードの通知を行うことなく前記確認コマンドの送信を前記被管理装置に行わせる通知設定情報を、前記被管理装置に送信することを特徴とする請求項１乃至３のいずれか１項に記載の管理装置。
6. 前記被管理装置のネットワーク環境は、前記管理装置からの自発的なアクセスを拒否するべく、ファイアウォールが構築されていることを特徴とする請求項１乃至５のいずれか１項に記載の管理装置。
7. 管理される複数の被管理装置と通信可能な管理装置における管理方法であって、
   前記被管理装置から状態コードを受信する第１受信工程と、
   状態コードに関連付けられた保守情報を記憶する記憶手段から、前記第１受信工程により受信した状態コードに関連付けられた保守情報を取得する取得工程と、
   前記取得工程により取得した保守情報を出力する出力工程と、
   前記記憶手段に登録されたデバイス識別情報に対応するデバイスが監視対象として有効か無効かを設定する設定工程と、
   デバイス識別情報が前記記憶手段に登録されているか否かを検索する検索工程と、
   前記被管理装置から自発的に送信されてくる、前記管理装置が新たに送信すべき情報がないかの確認を行うための確認コマンドを受信する第２受信工程と、
   保守情報に対応した状態コードの通知設定を含む通知設定情報を前記被管理装置に送信する送信工程とを有し、
   前記送信工程では、前記検索工程による検索の結果、前記第２受信工程により受信した前記確認コマンドに含まれるデバイス識別情報が見つかった場合に、当該デバイス識別情報に関して監視対象として無効の設定がなされていると、前記状態コードの通知を行うことなく前記確認コマンドの送信を前記被管理装置に行わせる通知設定情報を、前記被管理装置に送信することを特徴とする管理方法。
8. 前記送信工程では、前記第２受信工程により再度、確認コマンドを受信した際に、前記検索工程により前記確認コマンドに含まれるデバイス識別情報が前記記憶手段から見つかり、且つ、該見つかったデバイス識別情報に関して監視対象として有効の設定がなされていた場合に、前記状態コードの通知を前記被管理装置に行わせる通知設定情報を前記被管理装置に送信することを特徴とする請求項７に記載の管理方法。
9. 前記記憶手段に記憶された保守情報の更新の有無を判定する更新判定工程と、
   前記送信工程では、前記更新判定工程により前記保守情報が更新されたと判定された場合に、更新後の保守情報に対応した状態コードの通知設定を含む通知設定情報を前記被管理装置に送信することを特徴とする請求項７または８に記載の管理方法。
10. 前記被管理装置から送信されるデバイスの設置確認通知を受信する第３受信工程と、
    前記第３受信工程により前記デバイスの設置確認通知を受信した場合に、前記被管理装置が前記管理装置に対して送信可能な状態コードのうち、前記記憶手段に記憶される保守情報が関連付けられて記憶されている状態コードを判断する判断工程とを有し、
    前記送信工程では、前記判断工程により保守情報が関連付けられていると判断された状態コードの通知設定を含む通知設定情報を、前記被管理装置に送信することを特徴とする請求項７乃至９のいずれか１項に記載の管理方法。
11. 前記被管理装置から送信されるデバイスの設置確認通知を受信する第３受信工程を更に有し、
    前記検索工程は、前記第３受信工程によって受信した前記デバイスの設置確認通知に含まれるデバイス識別情報が前記記憶手段に登録されているか否かを検索する検索し、
    前記送信工程では、前記検索工程による検索の結果、対象のデバイス識別情報が前記記憶手段に登録されていなかった場合に、前記状態コードの通知を行うことなく前記確認コマンドの送信を前記被管理装置に行わせる通知設定情報を前記被管理装置に送信することを特徴とする請求項７乃至９のいずれか１項に記載の管理方法。
12. 前記被管理装置のネットワーク環境は、前記管理装置からの自発的なアクセスを拒否するべく、ファイアウォールが構築されていることを特徴とする請求項７乃至１１のいずれか１項に記載の管理方法。
13. 請求項１乃至６のいずれか１項に記載された管理装置としてコンピュータを機能させるためのプログラム。

Images