JP4723868B2 - ネットワーク装置から状態情報を得るために用いられるプロトコルを管理するための方法及びシステム - Google Patents

Description

本発明は、ネットワークに接続された装置をモニタリングする方法に関する。本発明は、特に、複数のプロトコルを用いてネットワーク接続された装置のリモートモニタリングのための方法、システム及びコンピュータプログラムプロダクトに関する。

一般に知られているように、コンピュータシステムはハードウェアとソフトウェアとを含む。ソフトウェアは、コンピュータシステムを構成するハードウェア構成要素を動作し、管理するために作成される命令のリストを含む。代表的には、コンピュータシステムはスタンドアロンタイプ又はネットワーク化されたタイプである。ネットワーク化されたタイプのコンピュータシステムにおいては、複数の別個の装置がネットワークに接続され、それ故、それら別個の装置の間の通信はネットワークにより可能にされる。

更に、ハードウェア装置を動作するためのソフトウェアは、ハードウェア装置が協調的に機能することが可能であるようにハードウェア装置間の通信を可能にするために構成される必要がある。更に、そのような通信を容易にするために、又、ハードウェア装置は、各々のハードウェア装置が効率的な方式で機能することを確実にするために認識される各々のハードウェア装置の状態はモニタリングされることが望ましい。

本特許出願の目的について、本発明者は、複数の別個の装置又はハードウェア装置を制御し、構成し又はモニタリングするハードウェア装置をモニタリング装置と呼び、そのモニタリング装置により制御され、構成され又はモニタリングされるハードウェア装置を“モニタリングされる装置”と呼ぶこととする。

ネットワークにおいて位置付けられたハードウェア装置に対して、それらの装置は維持、使用又は他の目的のためにモニタリングされることが望ましい。しかしながら、ハードウェア装置及びインタフェースに関連する製造メーカーの違いに鑑みて、モニタリング装置が、ネットワークに接続された種々の他の装置と通信することは困難であり得る。そのような不利点は、ネットワーク管理者がネットワークに接続された装置の性能及び効率に関する重要な情報を得ることのないようにする可能性が最も高い。

ＳＮＭＰ（Ｓｉｍｐｌｅ Ｎｅｔｗｏｒｋ Ｍａｎａｇｅｍｅｎｔ Ｐｒｏｔｏｃｏｌ）は、今日、データ通信ネットワーク、情報通信システム及び他のグローバル可到達装置のモニタリング及び管理のためのデファクトインダストリスタンダードとなっている。実際には、コンピュータ及び関連装置を扱う全ての組織は、ローカルエリアネットワーク及び広域ネットワークに亘ってそのような装置各々を中央でモニタし、診断し及び構成することができることを期待している。ＳＮＭＰはこのような相互作用を可能にするプロトコルである。

装置がＳＮＭＰ要求に応じるためには、ＳＮＭＰ要求を正確に理解し、その要求により要求された動作を実行し、ＳＮＭＰ応答を生成することを可能にするソフトウェアを装置に備えることが好ましい。ＳＮＭＰエージェントソフトウェアは、代表的には、ネットワークエンティティに存在するサブシステムソフトウェアモジュールである。

システムにより実行されるオブジェクトの収集は、一般に、ＭＩＢ（Ｍａｎａｇｅｍｅｎｔ Ｉｎｆｏｒｍａｔｉｏｎ Ｂａｓｅ）と呼ばれる。ＭＩＢは又、装置のモニタリングに関する情報を有するデータベースであることが可能である。他のＭＩＢの例としては、２、３例を挙げると、イーサネット（登録商標）インタフェースに重点を置いたイーサネット（登録商標）ＭＩＢと、８０２．１Ｄの管理のためのオブジェクトを規定するブリッジＭＩＢとを含む。

プライベートＭＩＢは有効キーなしで解読することが困難である値を含むため、装置をモニタリングするためにＳＮＭＰを用いることは困難である。ネットワークに接続された種々の装置をモニタリングするためにＳＮＭＰを用いる企業は、その企業の機密情報として維持される一意の識別子／キーを作成する。大部分において、結果は２値又は整数値として表示される。それ故、ＳＮＭＰを用いる場合、モニタリングされている装置“被モニタリング装置”から受信された結果は、ユーザ理解可能方式でモニタリングされる装置の状態をユーザに提供することができない。

更に、ＳＮＭＰを用いる場合、２値又は整数値として得られる結果を解読するためにプライベートＭＩＢにアクセスすること又は有効キーなしで被モニタリング装置に関する詳細情報を得ることは困難である。更に、所定のプロトコル（例えば、ＳＮＭＰ又はＨＴＴＰ／ＨＴＭＬ）は、例えば、タイムアウトパケット又は損失パケット等の種々の理由のために失敗する可能性がある。従って、装置からのデータの抽出がそのような状況下で適切に管理されない場合、一部のプロトコルは他のプロトコルに比べてより多くの資源を必要とするために、時間及びメモリの非効率性がもたらされる。更に、一部のプロトコルを用いる情報抽出は、他のプロトコルを用いることに比べて、必要とする処理及びメモリはかなり少ないことが可能である。更に、あるプロトコルにより得られる一部の情報は、他のプロトコルにより得られる情報に比べて、装置をモニタリングするためにより有用であることが可能である。

本発明のシステム及び方法は、ネットワークに接続された装置のモニタリングを可能にすることにより、上記の問題点に対する解決方法を扱う。従って、ネットワークに通信可能であるように結合された別個の装置間で装置をモニタリングする方法について開示する。

その方法は、ハードウェアアクセスモジュールにより第１データベースにアクセスする段階であって、第１データベースは複数の通信プロトコルを支援する、段階を含む。第１データベースは、被モニタリング装置のモデル情報及び製造メーカーのような種々の情報を得るために複数の通信プロトコルにより用いられる情報と共に記憶される。
通信プロトコルは複数の通信プロトコルの中から選択され、選択された通信プロトコルは被モニタリング装置から状態情報を受信する。その方法は、第１データベースからの選択された通信プロトコル及び情報を用い、被アクセス装置から状態情報を受信し、及び第２データベース（ＤｅｖｉｃｅＯＤＢＣ）に受信された状態情報を記憶して、被モニタリング装置にアクセスする段階を更に含む。

他の実施形態においては、本発明は、ネットワークに通信可能であるように結合された個別の装置間の装置をモニタリングする方法を提供する。複数の通信プロトコルが被モニタリング装置から情報を受信するために用いられることが可能である。例えば、ＳＮＭＰプロトコルは被モニタリング装置にアクセスするために、先ず、選択され、ＳＮＭＰプロトコルを用いて効率的に検索される装置情報が得られる。続いて、装置が付加プロトコルを支援する場合、ＨＴＴＰプロトコルおよびＦＴＰプロトコルが、ＳＮＭＰプロトコルを用いて、効率的な検索ができなかった情報を得るために選択される。プロトコルの選択は、データベースに記憶された支援情報に関連して、プロトコルマネージャにより実行される。

本発明においては、モニタリングシステムは、例えば、ＬＡＮ又はＷＡＮのようなネットワークに接続された少なくとも１つの装置（被モニタリング装置）をモニタリングすることが可能である。被モニタリング装置は、一意のＩＰアドレスを有する。被モニタリング装置に割り当てられたＩＰアドレス及び被モニタリング装置のためのベンダ／製造メーカーについての詳細はデータベースに記憶される。ネットワークをスキャンすること及び装置に問い合わせすることにより、装置のＩＰアドレスを得ることができる。そのような方法は既知である。それ故、モニタリングされるべき装置のＩＰアドレスはデータベースに既に取得され、記憶されていることが仮定される。

本発明は、被モニタリング装置から受信されたＨＴＭＬ情報から必要な情報をどのように抽出するかを指定する。一旦、被モニタリング装置のウェブページ位置がアクセスされる（即ち、ＩＰアドレス及び指定されたポートにより）と、被モニタリング装置に対応する固有のウェブページが表示される。ウェブページにおける情報は、キー及び値の対のフォームの状態にある。例えば、トナーレベルは、カラープリンタのウェブページにおいて“黒色１００％”として示されることが可能である。ＨＴＭＬ／ＸＭＬパーサが、ウェブページにおける情報から必要な情報を検索するためにページの情報解析を行うために用いられる。ＨＴＭＬ／ＸＭＬパーサを用いて、ウェブページから抽出された、必要な情報及びパラメータ値は、ＤｅｖｉｃｅＯＤＢＣに記憶される。

本発明は又、ここで説明するようなモニタリングシステムにより支援される装置モデル及び被モニタリング装置の種々のベンダを識別する。被モニタリング装置の種々のベンダはベンダ固有の方法で被モニタリング装置についての情報を提供するため、本発明は、被モニタリング装置のベンダ及びモデルの識別が被モニタリング装置の作動状態を決定することを可能にする。

本発明の一特徴に従って、ネットワークに通信可能であるように結合された被モニタリング装置に関連する状態情報を抽出するために用いられるそれぞれの通信プロトコルに関連する複数のプロトコルオブジェクトを初期化する、方法、システム及びコンピュータプログラムプロダクトであって：
（１）それぞれの通信プロトコル間で通信プロトコルを選択する段階;（２）選択された通信プロトコルを用いて、装置にアクセスするために、第１メモリから情報を検索する段階;（３）装置に関連するベンダ情報を得るように試みるために第１メモリから検索された情報と選択された通信プロトコルとを用いて装置にアクセスする段階；（４）ベンダ情報が装置から得られたかどうかを判定する段階；（５）ベンダ情報が装置から得られた場合、それぞれの通信プロトコルの各々を用いて、状態情報を抽出するために支援情報を第２メモリから得、複数のプロトコルオブジェクトの各々におけるそれぞれの支援情報及びベンダ情報を記憶する段階；並びに（６）ベンダ情報が装置から得られなかった場合、ベンダ情報が得られるまで又はそれぞれの通信プロトコルの各々の通信プロトコルが選択されるまで、処理段階を繰り返す段階；
を有する方法、システム及びコンピュータプログラムプロダクトを提供する
本発明の他の特徴に従って、ネットワークに通信可能であるように結合された被モニタリング装置からどの状態情報が抽出されるべきかを決定するための、方法、システム及びコンピュータプログラムプロダクトであって：
（１）装置から状態情報を抽出するために用いられる複数の通信プロトコルの中から通信プロトコルを選択する段階；（２）選択された通信プロトコルに関連するプロトコルオブジェクトを第１メモリから検索する段階であって、プロトコルオブジェクトは、選択された通信プロトコルを用いて、少なくとも、状態情報のタイプと、状態情報の重みと、装置からの状態情報のタイプを抽出するための情報とを含む、段階；（３）状態情報のタイプが第２メモリに存在するかどうかを判定する段階であって、第２メモリは装置から前に抽出された状態情報から構成されている、段階；（４）前記の判定する段階が、状態情報のタイプが第２メモリに存在することを判定した場合、プロトコルオブジェクトに記憶された状態情報の重みが、第２メモリに記憶された同じタイプの状態情報に関連する対応する重みより大きいかどうかをチェックする段階；並びに（５）（ａ）前記の判定する段階が、状態情報のタイプが第２メモリに存在しないことを判定した場合、又は（ｂ）前記の判定する段階が、状態情報のタイプが第２メモリに存在することを判定し、前記のチェックする段階が、状態情報の重みが第２メモリに記憶された同じタイプの状態情報に関連する対応する重みより大きいことを判定した場合、状態情報を得るためにプロトコルオブジェクトに含まれる装置を抽出するための情報と選択された通信プロトコルとを用いて装置にアクセスする段階；
を有する方法、システム及びコンピュータプログラムプロダクトを提供する。

本発明の他の特徴に従って、ネットワークに通信可能であるように結合された少なくとも１つの被モニタリング装置に関連する情報を管理するための、方法、システム及びコンピュータプログラムプロダクトであって：
（１）少なくとも１つの被モニタリング装置から状態情報を抽出するために用いられる複数の通信プロトコル間から通信プロトコルを選択する段階；（２）選択された通信プロトコルに関連するプロトコルオブジェクトを第１メモリから検索する段階であって、プロトコルオブジェクトは、少なくとも１つの被モニタリング装置のベンダ及びモデル情報を含む、段階；（３）選択された通信プロトコルにより支援される少なくとも１つの被モニタリング装置についての被モニタリング装置のベンダ名をプロトコルオブジェクトから得る段階；（４）得られたモデル名に対応するモデル名をプロトコルオブジェクトから得る段階；（５）得られたベンダ名と得られたモデル名とを用いて記述的ストリングを生成する段階；（６）記述的ストリングが第２メモリに存在するかどうかを判定する段階；並びに（７）前記の判定する段階が、記述的ストリングが第２メモリに存在しないことを判定した場合、プロトコルオブジェクトに関連して第２メモリにその記述的措置リングを記憶する段階；
を有する方法、システム及びコンピュータプログラムプロダクトを提供する。

本発明の他の特徴に従って、ネットワークに通信可能であるように結合された少なくとも１つの被モニタリング装置から状態情報を抽出するために必要な情報を管理するための、方法、システム及びコンピュータプログラムプロダクトであって：
（１）被モニタリング装置から状態じょうほうを抽出するために用いられる複数の通信プロトコルの中から通信プロトコルを選択する段階；（２）第１メモリから記述的ストリングを検索する段階であって、記述的ストリングは、選択された通信プロトコルにより支援される対応するモデル名及びベンダ名を含む、段階；（３）記述的ストリングから対応するモデル名とベンダ名とを抽出する段階；（４）抽出されたベンダ名及び抽出されたモデル名が被モニタリング装置のベンダ名及びモデル名それぞれに適合するかどうかを判定する段階；並びに（５）前記の判定する段階が、抽出されたベンダ名及び抽出されたモデル名が被モニタリング装置のベンダ名及びモデル名それぞれに適合することを判定した場合、選択された通信プロトコルを用いて状態情報を得るために装置にアクセスする段階；
を有する方法、システム及びコンピュータプログラムプロダクトを提供する。

本発明の他の特徴に従って、必要に応じて、ネットワーク装置に関連する状態情報を抽出するために通信プロトコルを用いることができることを判定するための方法、システム及びコンピュータプログラムプロダクトであって：
（１）複数の通信プロトコルの中から通信プロトコルを選択する段階；（２）選択された通信プロトコルを用いて、ネットワーク装置にアクセスするための情報を、ネットワーク装置に関連する装置オブジェクトから得る段階；（３）装置オブジェクトから得られたネットワーク装置にアクセスするための情報と選択された通信プロトコルとを用いて、ネットワーク装置にアクセスすることができるかどうかを判定する段階；（４）前記の判定する段階が、ネットワーク装置が選択された通信プロトコルを用いてアクセスされることができない場合、選択された通信プロトコルを用いて、ネットワーク装置にアクセスするための情報を装置オブジェクトから取り除く段階；並びに（５）前記の判定する段階が、ネットワーク装置が選択された通信プロトコルを用いてアクセスされることができる場合、ネットワーク装置型状態情報を抽出するために選択された通信プロトコルを用いることができるかどうかを判定するために更なるテストを実行する段階；
を有する方法、システム及びコンピュータプログラムプロダクトを提供する。

更に、更なるテストを実行する段階は：（１）選択された通信プロトコルを用いて、ネットワーク装置からネットワーク装置のベンダを得ることができるかどうかを判定する手順；（２）前記の判定する手順が、選択された通信プロトコルを用いてベンダを得ることができないことを判定した場合、選択された通信プロトコルが一般ベンダを支援するかどうかをチェックする手順であって、選択された通信プロトコルが一般ベンダを支援しない場合、選択された通信プロトコルを用いてネットワーク装置にアクセスするための情報を装置オブジェクトから取り除く手順；（４）得られたベンダが選択された通信プロトコルにより支援されない場合、選択された通信プロトコルが一般ベンダを支援するかどうかをチェックする手順であって、選択された通信プロトコルが一般ベンダを支援しない場合、選択された通信プロトコルを用いてネットワーク装置にアクセスするための情報を装置オブジェクトから取り除く手順；並びに（５）得られたベンダが選択された通信プロトコルにより支援される場合、モデル情報に関連する更なるテストを実行する手順；
から構成される。

更に、モデル情報に関連する更なるテストを実行する手順は：選択された通信プロトコルを用いてネットワーク装置から、ネットワーク装置のモデルをえることができるかどうかを判定する段；（２）前記の判定する段階が、選択された通信プロトコルを用いてモデルを得ることができないことを判定した場合、選択さえた通信プロトコルが一般モデルを支援するかどうかをチェックする段階であって、選択された通信プロトコルが一般モデルを支援しない場合、選択された通信プロトコルをもしいてネットワーク装置にアクセスするための情報を装置オブジェクトから取り除く段；並びに（３）得られたモデルが選択された通信プロトコルにより支援されない場合、選択された通信プロトコルが一般モデルを支援するかどうかをチェックする段であって、選択された通信プロトコルが一般モデルを支援しない場合、選択された通信プロトコルを用いてネットワーク装置にアクセスするための情報を装置オブジェクトから取り除く段；
から構成される。

図１は、装置の動作をモニタリングし、診断し、制御するための種々の装置及びコンピュータを有する模式図を示している。特に、図１は、例えば、コンピュータワークステーション１７、１８、２０及び２２に接続された狭域ネットワーク（ＬＡＮ）のような第１ネットワーク１６を含む。それらのワークステーションは、例えば、パーソナルコンピュータ装置、Ｕｎｉｘ（登録商標）ベースのコンピュータ、Ｌｉｎｕｘベースのコンピュータ又はＡｐｐｌｅ社のＭａｃｉｎｔｏｓｈｅを含むいずれのタイプのコンピュータであることが可能である。又、ディジタル画像形成装置２４、ファックス装置２８及びプリンタ３２はネットワーク１６に接続される。当業者は理解するであろうように、ディジタルコピー器／プリンタ２４及びファックス装置２８の２つの又はそれ以上の構成要素は、一体化された“画像形成装置”に結合されることができる。例えば、コピー器／プリンタ２４、ファックス装置２８、プリンタ３１並びにワークステーション１７、１８、２０及び２２は機器又は被モニタ装置と呼ぶことが可能である。一部の構成においては、１つ又はそれ以上のワークステーションを事務所用電気製品に代えることが可能である。又、いずれのワークステーション１７、１８、２０及び２２並びに事務所用電気製品２７は、ネットワーク１６において被モニタ装置をポーリングするため、及びモニタリング装置に収集されたデータを送信するために、中間モニタリング装置として機能することができる。

そのような事務所の電気製品の一例としては、株式会社リコー製のｅＣａｂｉｎｅｔ（登録商標）がある。又、ファックスサーバ（図示せず）はネットワーク１６に接続され、電話、ケーブル又は無線コネクションを有することが可能である。各々のディジタルコピー器／プリンタ２４、ファックス装置２８及びプリンタ３２は又、ネットワーク１６に接続されることに加えて、従来の電話コネクション２６及び／又はケーブルコネクション３０及び／又は無線コネクション３４それぞれを含むことが可能である。下で説明するように、被モニタリング装置２４、２８及び３２は、直接電話コネクション、無線コネクション又はケーブルコネクションにより又はネットワーク１６により、例えば、インターネットを介して、モニタリング装置と又呼ばれる、リモートモニタリング、診断及び制御ステーションと通信する。

他の代表的なビジネス環境下では、被モニタリング装置は、例えば、多機能イメージング装置、スキャナ、プロジェクタ、会議システム及びシュレッダ等を含むことが可能である。他の用途においては、ネットワーク１６は、被モニタリング装置が例えば、マイクロ波オーブン、洗浄器、乾燥器、皿洗い器、家庭用娯楽システム、冷蔵庫、炊飯器、加熱器、エアコン、温水器、セキュリティカメラ等のような電気製品又はメータ（電気、ガス、水）である家庭用ネットワークであることが可能である。

図１において、広域ネットワーク（ＷＡＮ）（例えば、インターネット又はその後継器）は、一般に、参照番号１０により表される。ＷＡＮ１０は、プラーベートＷＡＮ、公衆ＷＡＮ又はハイブリッドタイプであることが可能である。ＷＡＮ１０は、参照番号１２Ａ乃至１２Ｉにより表される複数相互接続されたルータ及びコンピュータを含む。ＷＡＮに亘って通信する方法は、“Ｓｉｍｐｌｅ Ｍａｉｌ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ”と題されたＲＦＣ８２１、“ＡＲＰＡインターネットテキストメッセージのフォーマットのための規格”と題されたＲＦＣ８２２、“ファイル転送プロトコル（ＦＴＰ）”と題されたＲＦＣ９５９、“多目的インターネットメール拡張仕様（ＭＩＭＥ）パート１：インターネットメッセージ本体”と題されたＲＦＣ２０４５、“Ａｎ Ｅｘｔｅｎｓｉｂｌｅ Ｍｅｓｓａｇｅ Ｆｏｒｍａｔ ｆｏｒ Ｄｅｌｉｖｅｒｙ Ｓｔａｔｕｓ Ｎｏｔｉｆｉｃａｔｉｏｎｓ”と題されたＲＦＣ１８９４、“Ｐｏｓｔ Ｏｆｆｉｃｅ Ｐｒｏｔｏｃｏｌ−バージョン３”と題されたＲＦＣ１９３９、“Ｈｙｐｅｒｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ−ＨＴＴＰ／１．１”ｔｏｄａｉｓａｒｅｔａ ＲＦＣ
２０６８、“Ａｎ Ｅｘｔｅｎｓｉｂｌｅ Ｍｅｓｓａｇｅ Ｆｏｒｍａｔ ｆｏｒ Ｍｅｓｓａｇｅ Ｄｉｓｐｏｒｔｉｏｎ Ｎｏｔｉｆｉｃａｔｉｏｎｓ”と題されたＲＦＣ２２９８を含む、ｗｗｗ．ｉｅｔｆ．ｏｒｇ／ｒｆｃ．ｈｔｍｌにおけるＩｎｔｅｒｎｅｔ Ｅｎｇｉｎｅｅｒｉｎｇ Ｔａｓｋ Ｆｏｒｃｅ（ＩＥＴＦ）から利用可能な一連のＲＦＣ（Ｒｅｑｕｅｓｔ ｆｏｒ Ｃｏｍｍｅｎｔｓ）により周知である。これらのリファレンスの各々のコンテンツは、それらの援用によって発明の説明を一部代替する。

通信に関する伝送制御プロトコル／インターネットプロトコル（ＴＣＰ／ＩＰ）については、例えば、１９９４年にＡｄｄｉｓｏｎ−Ｗｅｓｌｅｙ Ｐｕｂｌｉｓｈｉｎｇ Ｃｏｍｐａｎｙから出版された、Ｗ．Ｒ．Ｓｔｅｖｅｎｓ著、文献“ＴＣＰ／ＩＰ Ｉｌｌｕｓｔｒａｔｅｄ”，Ｖｏｌ．１，Ｔｈｅ ｐｒｏｔｏｃｏｌｓに記載されており、その文献の全体のコンテンツの援用によって発明の説明を一部代替する。又、Ｃｏｍｅｒ及びＳｔｅｖｅｎｓ著、“Ｉｎｔｅｒｎｅｔｗｏｒｋｉｎｇ ｗｉｔｈ ＴＣＰ／ＩＰ”，Ｖｏｌ．１−３の援用によって発明の説明を一部代替する。

図１を続けて参照するに、ファイアウォール５０Ａは、ＷＡＮ１０とネットワーク１６との間に接続される。ファイアウォールは、ファイアウォールの一の側において許可されたコンピュータのみがネットワーク、コンピュータ又はファイアウォールの他の側における個別の部品にアクセスすることが可能である装置である。ファイアウォールは周知であり、市販されている装置及び／又はソフトウェア（例えば、Ｚｏｎｅ Ｌａｂｓ社製のＺｏｎｅ Ａｌａｒｍ）である。同様に、ファイアウォール５０Ｂ及び５０Ｃは、ネットワーク５２及びワークステーション４２それぞれからＷＡＮ１０を分離する。ファイアウォールに関する追加の詳細については、文献、“Ｆｉｒｅｗａｌｌｓ ａｎｄ Ｉｎｔｅｒｎｅｔ Ｓｅｃｕｒｉｔｙ”ｂｙＷ．Ｒ．Ｃｈｅｓｗｉｃｋ ａｎｄ Ｓ．Ｍ．Ｂｅｌｌｏｖｉｎ，１９９４，Ａｄｄｉｓｏｎ Ｗｅｓｌｅｙ Ｐｕｂｌｉｓｈｉｎｇと、文献、“Ｂｕｉｌｄｉｎｇ Ｉｎｔｅｒｎａｔ Ｆｉｒｅｗａｌｌｓ”ｂｙＤ．Ｂ．Ｃｈａｐｍａｎ ａｎｄ Ｅ．Ｄ．Ｚｗｉｃｋｙ，１９９５，Ｏ‘Ｒｅｉｌｌｙ ＆ Ａｓｓｏｃｉａｔｅｓ，Ｉｎｃ．において見出すことができる。その文献の全体のコンテンツの援用によって発明の説明を一部代替する。

ネットワーク５２は従来のネットワークであり、複数のワークステーション５６、６２、６８及び７４を含む。これらのワークステーションは、１つの企業の異なる部署（例えば、営業、購買、経理、広報、マーケティング、製造、デザインエンジニアリング及び顧客サービス部）内に分布された状態で位置付けられることが可能である。ネットワーク５２により接続されたワークステーションに加えて、ネットワーク５２に直接、接続されないワークステーション４２を又、備えることが可能である。ワークステーション４２に接続されたディスク４６に記憶されたデータベースにおける情報は、ネットワーク５２に直接、接続されたワークステーションに対してＷＡＮ１０に亘って適切な暗号化及びプロトコルを用いて共有されることが可能である。又、ワークステーション４２は、電話回線への直接接続及び／又はケーブルネットワーク及び／又は無線ネットワーク４４を含み、ディスク４６におけるデータベースは電話回線、ケーブルネットワーク又は無線ネットワーク４４によりアクセスされることが可能である。本発明により用いるケーブルネットワークは、テレビジョンプログラミングを担持するために典型的に用いられるケーブルネットワーク、コンピュータと共に典型的に用いられるディジタルデータの高速通信を提供するケーブル、又はいずれの他の所望のタイプのケーブルを用いて、実施されることが可能である。

他の実施形態においては、ワークステーション４２は、ラップトップコンピュータ、ＰＤＡ、パームトップコンピュータ又はネットワーク能力を有する携帯電話であることが可能である。これらの装置は、ディスク４６に記憶されたデータベースに記憶された情報にアクセスするために用いられることが可能である。

ディジタルコピー器／プリンタ２４、オフィス電気製品２７、ファックス装置２８又はプリンタ３２それぞれに関する情報は、ディスク４６、５４、５８，６４、７０及び７６に記憶された１つ又はそれ以上のデータベースに記憶されることが可能である。基地のデータベースは、（１）Ｍｉｃｒｏｓｏｆｔ、ＩＢＭ、Ｏｒａｃｌｅ及びＳｙｂａｓｅによるＳＱＬデータベース、（２）他の関連データベース、及び（３）非関連データベース（Ｏｂｊｅｃｔｉｖｉｔｙ、ＪＹＤ Ｓｏｆｔｗａｒｅ Ｅｎｇｉｎｅｅｒｉｎｇ及びＯｒｉｅｎｔ Ｔｅｃｈｎｏｌｏｇｙからのオブジェクト指向データべースを含む）、を含む。各々の営業、購買、経理、広報、マーケティング、製造、デザインエンジニアリング及び顧客サービス部は、それらの部署自体のデータベースを有することが可能である、又は１つ又はそれ以上のデータベースを共有することが可能である。データベースを記憶するために用いられる各々のディスクは、ハードディスク又は光ディスクのような不揮発性メモリである。代替として、データベースは、固体メモリ装置及び／又は半導体メモリ装置を含むいずれの記憶装置に記憶されることが可能である。例えば、ディスク６４はマーケティングデータベースを記憶することが可能であり、ディスク５８は製造データベースを記憶することが可能であり、ディスク７０はエンジニアリングデータベースを記憶することが可能であり、及びディスク７６は顧客サービスデータベースを記憶することが可能である。代替として、ディスク５４及び５６は１つ又はそれ以上のデータベースを記憶することが可能である。

ＷＡＮ１０に接続されるワークステーション５６、６２、６８、７４及び４２に加えて、これらのワークステーションは又、モニタされる、診断される及び／又は制御される機械／装置への安全な接続を提供するための、電話回線、ケーブルネットワーク又は無線ネットワークへの接続を含むことが可能である。更に、通信媒体の一が適切に動作しない場合、他の通信媒体の１つが、通信のためのバックアップとして自動的に使用されることが可能である。

本発明の特徴は、機械を診断及び制御するためのコンピュータ／モニタリングシステムと機械との間の通信又は伝送の“蓄積型（ｓｔｏｒｅ−ａｎｄ−ｆｏｒｗａｒｄ）”モード（例えば、インターネットの電子メール、又は、ここでは、ｅ−ｍａｉｌという）を使用することである。代替として、伝送されるメッセージは、ＦＴＰ及びＨＴＴＰ（Ｈｙｐｅｒ Ｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）のような直接的な端末間接続（例えば、最終目的地へのソケットコネクション）を形成する通信のモードを用いて、実施されることが可能である。

図２は、図１に示しているディジタルコピー器／プリンタ２４の機械的レイアウトを示している。図２において、参照番号１０１はスキャナのためのファンであり、参照番号１０２はレーザプリンタと共に用いられる多面鏡であり、参照番号１０３はレーザ（図示せず）からの光をコリメートするために用いられるＦθレンズを表す。参照番号１０４スキャナからの光を検出するためのセンサを表す。参照番号１０５はスキャナからセンサに光を焦点合わせするためのレンズを表し、参照番号１０６は感光ドラム１３２において画像を消去するために用いるクエンチングランプを表す。帯電コロナユニット１０７及び現像ローラ１０８を備えている。参照番号１０９はスキャンされる文書を描写するためのランプを表し、要素１１０、１１１及び１１２はセンサ１０４に光を反射するための鏡を表す。ドラム鏡１１３は、多面鏡１０２からもたらされる光を感光ドラム１３２に反射するために備えられる。ファン１１４はディジタル画像形成装置の帯電領域を冷やすために用いられ、第１給紙ローラ１１５は第１給紙カセット１１７から紙を供給するために用いられ、参照番号１１６はマニュアル給紙テーブルを表す。同様に、第２給紙ローラ１１８は第２カセット１１９と連動して用いられる。参照番号１２０は中継ローラを表し、参照番号１２１はレジストレーションローラを表し、１２２は画像密度センサを表し、１２３は転写／分離コロナユニットを表す。参照番号１２４はクリーニングユニットを表し、１２５は真空ファンを表し、１２６は搬送ベルトを表し、１２７は圧力ローラを表し、そして１２８は出口ローラを表す。加熱ローラ１２９は紙にトナーを固定するために用いられ、１３０は排気ファンを表し、主モータ１３１はディジタルコピー器／プリンタ２４を駆動するために用いられる。

図３は、図２のディジタルコピー器／プリンタ２４の電気的構成要素を示すブロック図であり、ＣＰＵ１６０はその装置の制御装置として機能するマイクロプロセッサである。ランダムアクセスメモリ（ＲＡＭ）１６２は、ディジタルコピー器／プリンタ２４の動作パラメータを含む帯電情報を動的に記憶する。不揮発性メモリ（例えば、読み出し専用メモリ（ＲＯＭ）又はフラッシュメモリ）は、ディジタルコピー器／プリンタを作動させるために用いられるプログラムコードとコピー器／プリンタを表す静的状態データ（例えば、モデル名、モデル番号、装置のシリアルナンバー及びデフォルトパラメータ）とを記憶する。

マルチポートネットワークインタフェース１６６は、ディジタルコピー器／プリンタ２４が少なくとも１つの通信ネットワークにより外部装置と通信することを可能にするように備えられている。参照番号１６８は電話、無線又はケーブル回線を表し、参照番号１７０は１６８において認識されるネットワークとは異なる他の種類のネットワークを表す。マルチポートネットワークインタフェースの更なる詳細については、図４を参照して説明することとする。インタフェース制御器１７２は、システムバス１８６に操作パネルを接続するために用いられる。操作パネル１７４は、例えば、コピーの枚数、縮小／拡大、暗さ／明るさ等のような画像形成装置の操作を制御するためのコピーボタン、キーを含むディジタルコピー器／プリンタ２４においてみられる標準的な入力及び出力装置を含む。更に、液晶表示装置が、ユーザに対してディジタルコピー器／プリンタ２４のメッセージ及びパラメータを表示するために操作パネル１７４内に含まれることが可能である。

ローカルコネクションインタフェース１７１は、ＲＳ２３２、パラレルプリンタポート、ＵＳＢ及びＩＥＥＥ １３９４のようなローカルポートによる接続である。ＦｉｒｅＷｉｒｅ（ＩＥＥＥ １３９４）は、Ｗｉｃｋｌｇｒｅｎ，Ｉ．，“Ｔｈｅ Ｆａｃｔｓ Ａｂｏｕｔ “ＦｉｒｅＷｉｒｅ”，ＩＥＥＥ Ｓｐｅｃｔｒｕｍ， Ａｐｒｉｌ １９９７，Ｖｏｌ．３４，Ｎｕｍｂｅｒ ４，ｐｐ．１９−２５において説明されており、その文献の全体のコンテンツの援用によって発明の説明を一部代替する。好適には、エラー検出及び再送を含む“高信頼性”通信プロトコルが用いられる。

ストレージインタフェース１７６はシステムバス１８６に記憶装置を接続する。例えば、記憶装置は、従来の電気的消却プログラム可能型読取専用メモリ（ＥＥＰＲＯＭ：Ｅｌｅｃｔｒｉｃａｌｌｙ Ｅｒａｓａｂｌｅ Ｐｒｏｇｒａｍｍａｂｌｅ Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）により置き換えることができるフラッシュメモリ１７８、及びディスク１８２を有する。ディスク１８２は、ハードディスク、光ディスク及び／又はフロッピー（登録商標）ディスクドライブであることが可能である。付加メモリ装置は、コネクション１８０によりディジタルコピー器／プリンタ２４に接続されることが可能である。フラッシュメモリ１７８は、装置２４の寿命に亘って殆ど変わらない、ディジタルコピー器／プリンタ２４のパラメータを表す半静的状態データを記憶するために用いられる。そのようなパラメータは、例えば、ディジタルコピー器／プリンタのオプション及び設定を含む。任意インタフェース１８４は、外部のインタフェースのような付加ハードウェアがディジタルコピー器／プリンタ２４に接続されることを可能にする。クロック／タイマー１８７は、時間及び月日の両方を常に把握し、又、経過時間を測定するために利用される。

図３は又、ディジタルコピー器／プリンタ２４を構成する種々の部分を示している。参照番号２０２はソータを表し、ディジタルコピー器／プリンタ２４の出力をソーティングするために用いられるアクチュエータ及びセンサを含む。デュプレクサ２００は従来のセンサ及びアクチュエータを含む。大きい容量のトレーユニット１９８は、紙トレーが大量のシートを保持するために備えられる。デュプレクサと同様に、トレーユニット１９８は又、従来のセンサ及びアクチュエータを含む。

給紙制御器１９６は、ディジタル画像形成装置に及びそれにより給紙する操作を制御するために用いられる。スキャナ１９４はディジタル画像形成装置に画像をスキャンするために用いられ、光、鏡等のような従来のスキャニング要素を含む。更に、スキャナセンサは、スキャナがホームポジションにあることを決定するためにホームポジションセンサとして用いられ、ランプサーミスタはスキャンランプの正確な操作を確実にするために用いられる。プリンタ／イメージャ１９２はディジタル画像形成装置の出力をプリントし、従来のレーザプリント機構と、トナーセンサと、画像密度センサとを含む。フューザ１９０は、高温ローラを用いてページ上でトナーを溶かすために用いられ、出口センサと、フューザ１９０が過熱されないようにするサーミスタと、オイルセンサとを含む。更に、例えば、自動文書供給器、異なる種類のソータ／コレータ、又はディジタル画像形成装置に付加されることができる他の要素のような、ディジタル画像形成装置の任意の要素に接続するために用いられる、任意のユニットインタフェース１８８がある。

図４は、マルチポートネットワークインタフェース１６６についての詳細を示している。ディジタル画像形成装置は、トークンリングインタ、電話回線１６８Ａに接続された従来の電話インタフェース２２４、無線インタフェース、又はＬＡＮ１７０に接続されたイーサネット（登録商標）インタフェースにより、外部装置に通信することが可能である。他のインタフェースとして、ＤＳＬ（Ｄｉｇｉｔａｌ Ｓｕｂｓｃｒｉｂｅｒ Ｌｉｎｅ）（オリジナルＤＳＬ、同心ＤＳＬ及び非対称ＤＳＬ）を含むことが可能であるが、これらに限定されない。ＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）及び電話回線の両方に接続される信号装置はＩｎｔｅｌ社から市販されており、Ｉｎｔｅｌ Ｐｒｏ １０／１００＋Ｍｏｄｅｍとして知られている。

ＣＰＵ若しくは他のマイクロプロセッサ又は回路構成は、ディジタル画像形成装置のセンサの各々の状態をモニタするためにモニタリング処理を実行し、順序付け処理がディジタル画像形成装置を制御し、操作するために用いられる。更に、ディジタル画像形成装置の全体的操作を制御するために実行される（１）中央システム制御処理と、ディジタル画像形成装置に接続された外部装置への高信頼性の通信を確実にするために用いられる（２）通信処理とがある。システム制御処理は、静的状態メモリ（例えば、図３のＲＯＭ１６４）、セミ静的メモリ（例えば、フラッシュメモリ１７８又はディスク１８２）又は動的状態メモリ（例えば、揮発性又は不揮発性メモリ）（例えば、ＲＡＭ１６２、フラッシュメモリ１７８又はディスク１８２）におけるデータ記憶をモニタし、制御する。更に、静的状態メモリは、例えば、フラッシュメモリ１７８か又はディスク１８２のどちらかを含む不揮発性メモリのようなＲＯＭ１６４以外の素子であることが可能である。

上記の詳細説明はディジタル画像形成装置に関するものであるが、本発明は、例えば、アナログコピー装置、ファックス装置、スキャナ、プリンタ、ファックスサーバ、プロジェクタ、会議装置、シュレッダ、他の事務用機器又は事務所用電気製品のような他の事務所用機器又は装置、若しくは、他の電気製品（例えば、電子レンジ、ＶＣＲ、ＤＶＤ、ディジタルカメラ、携帯電話、パームトップコンピュータ）に同等に適用可能である。更に、本発明は、蓄積型（ｓｔｏｒｅ−ａｎｄ−ｆｏｒｗａｒｄ）又は直接接続ベースの通信を用いて動作する他の種類の装置を含む。そのような装置は、検針システム（ガス、水道、電気検針システムを含む）、自動販売機、又は、操作又はリモート診断の間にモニタされる必要がある、いずれの機械的装置（例えば、自動車、洗浄器、乾燥器）を含む。特殊用途の機器及びコンピュータのモニタリングに加えて、本発明は、モニタリングされる及び／又は制御される一般用途のコンピュータをモニタリング、制御及び診断するために用いられることができる。

図５は、異なる装置及びサブシステムがＷＡＮ１０に接続されている、本発明の他のシステムを示す図である。しかしながら、本発明の一部としてこれらの装置又はサブシステムの各々を有する必要はない。図５における各々の構成要素又はサブシステムは、本発明の個別の部分である。更に、図１に示す要素は、図５に示すＷＡＮ１０に接続されることが可能である。図５において、インターネット２６０−１に接続されたファイアウォール５０−１を示している。インターネット２６０−１に接続されたサービスマシン２５４は、データベースフォーマットに記憶されることが可能であるデータ２５６を含み、又はそれに接続されている。データ２５６は、履歴、性能、故障、並びに、被モニタリング装置の操作、故障又は設定若しくはコンピュータ又は任意装置が非モニタリング装置により含まれるというような設定情報、を含む。サービスマシン２５４は、データを伝送するために被モニタリング装置を必要とし、又は、リモート制御及び／又は診断テストが被モニタリング装置において実施されることが必要である、コンピュータ又は装置として実施されることが可能である。サービスマシン２５４はいずれの種類の装置として実施されることが可能であり、好ましくは、一般用途コンピュータのようなコンピュータ化された装置を用いて実施される。又、サービスマシン２５４は、ビリング、アカウンティング、サービス処理、パーツ追跡及びレポートを含む種々多様なデータベースを有するネットワークに亘って、複数のコンピュータから成ることが可能である。

図５の他のサブシステムは、ファイアウォール５０−２、イントラネット２６０−２及びそれらの接続されたプリンタ２６２を含む。このサブシステムにおいて、プリンタ２６２により（及び、同様に、コピー装置２８６により）電子メッセージを送信する及び受信する機能が、（１）回路構成、（２）マイクロプロセッサ又は（３）プリンタ２６２に組み込まれた又はそれの内部に含まれたいずれの他の種類のハードウェア（即ち、別個の一般用途のコンピュータを用いることなく）、により実行される。

代替の種類のサブシステムは、Ａｍｅｒｉｃａ Ｏｎｌｉｎｅ、Ｅａｒｔｈｌｉｎｋ及びＮｉｆｔｙｓｅｒｖｅのような既知の営利会社を含む、いずれのタイプのインターネットサービスプロバイダ（ＩＳＰ）であることが可能であるインターネットサービスプロバイダ２６４の利用を含む。このようなサブシステムにおいて、コンピュータ２６６は、ディジタル又はアナログモデム（例えば、電話回線モデムと、ケーブルモデムと、ＡＤＳＬ（Ａｓｙｍｍｅｔｒｉｃ Ｄｉｇｉｔａｌ Ｓｕｂｓｃｒｉｂｅｒ Ｌｉｎｅ）に亘って使用されるモデムのようないずれの種類の通信を用いるモデムと、高周波モデム、光ファイバモデム又は赤外光線を用いる装置のような無線モデムと）によりＩＳＰ２６４に接続される。更に、事務所用装置２６８はコンピュータ２６６に接続される。事務所用装置２６８（又は、図５に示す、いずれの他の装置）の代替として、ディジタルコピー装置、いずれの主対の電気製品、セキュリティシステム、又は電気、水道又はガスユーティリティメータのようなユーティリティメータ、又はいずれのここで述べた他の装置のような、異なる種類の機器をモニタリングする、又は制御することが可能である。

又、図５に、ネットワーク２７４に接続されたファイアウォール５０−３を示している。ネットワーク２７４はいずれの種類のコンピュータネットワーク（例えば、イーサネット（登録商標）又はトークンリングネットワーク）として実施されることが可能である。ネットワークを制御するために用いられることが可能であるネットワーキングソフトウェアは、Ｎｏｖｅｌｌ社又はＭｉｃｒｏｓｏｆｔ社から市販されているソフトウェアを含むいずれの好ましいネットワーキングソフトウェアを含む。ネットワーク２７４は、必要に応じて、インターネットとして実施されることが可能である。ネットワーク２７４に接続されたコンピュータ２７２は、事務所用装置２７８から情報を得るために用いられ、ネットワークに接続された種々の機器において起こった問題を示すレポート及びネットワーク２７４に接続された装置の月間使用レポートのようなレポートを作成することが可能である。この実施形態においては、コンピュータ２７６は事務所用装置２７８とネットワーク２７４との間に接続されている。このコンピュータはネットワークから通信を受信し、適切なコマンド、データ又はいずれの他の情報を事務所用装置２７８に転送する。

事務所用装置２７８とコンピュータ２７６との間の通信は、高周波コネクション、電気的コネクション及び光コネクション（例えば、赤外線コネクション又は光ファイバコネクション）を含む有線ベースの又は無線方式を用いて実現されることが可能である。同様に、図５に示している種々のネットワーク及びイントラネットの各々は、高周波ネットワークのような無線ネットワークの確立により含まれるいずれの好ましい方式を用いて確立されることが可能である。ここで説明している無線通信は、Ｂｌｕｅｔｏｏｔｈ仕様（ワールドワイドウェブサイトｗｗｗ．ｂｌｕｅｔｏｏｔｈ．ｃｏｍで利用可能である）の状態で開示された周波数ホッピング無線技術のような拡散コード及び周波数ホッピング技術を用いる技術を含む拡散スペクトル技術を用いて確立されることが可能であり、その援用によって発明の説明を一部代替する。

図５に示す他のサブシステムは、ファイアウォール５０−４、イントラネット２６０−４、イントラネットに接続されたコンピュータ２８２、事務所用電気製品１８５及びコピー装置２８６を有する。コンピュータ２８２は、レポートを作成し、診断又は制御手順を要求するために用いられる。このような診断及び制御手順は、事務所用電気製品１８５及びコピー装置２８６又は図５に示されている又は図５と共に用いられるいずれの他の装置に関連して実行されることが可能である。図５は複数のファイアウォールを示しており、ファイアウォールは好適であるが、オプションの装置、それ故、本発明は、必要に応じて、ファイアウォールの使用なしで操作されることが可能である。ネットワーク化された装置のモニタリング及び制御のために、サービスマシン２５４の代わりに、いずれのコンピュータ（２６６、２７２又は２８２）を用いることができる。更に、いずれのコンピュータは、ウェブにより必要な装置情報又は使用情報を検索するために、サービスマシン２５４にアクセスすることが可能である。

図６Ａは、典型的なｅ−ｍａｉｌ交換システムに接続された装置／電気製品３００を示しており、それは、構成要素３０２、３０４、３０６、３０８、３１０、３１２、３１４、３１６及び３１６を含み、従来の方式で実施されることが可能であり、上で参照したＳｔｅｖｅｎｓによる文献における図２８．１からアレンジされている。コンピュータインタフェース３０２は、ここで説明している、いずれのアプリケーションユニット又は装置／電気製品３００と接続される。図６Ａは、装置／電気製品３００が送信器であることを示しており、送信及び受信機能は図６Ａにおけるものとは逆になっている。更に、必要に応じて、ユーザは装置／電気製品３００と接続する必要は全くない。コンピュータインタフェース３０２は、次いで、メールエージェント３０４と相互作用する。Ｕｎｉｘ（登録商標）に対するポピュラーメールエージェントは、ＭＨ、Ｂｅｒｋｅｌｅｙ Ｍａｉｌ、Ｅｌｍ及びＭｕｓｈを含む。オペレーティングシステムのＷｉｎｄｏｗｓ（登録商標）ファミリに対するメールエージェントは、Ｍｉｃｒｏｓｏｆｔ Ｏｕｔｌｏｏｋ及びＭｉｃｒｏｓｏｆｔ Ｏｕｔｌｏｏｋ Ｅｘｐｒｅｓｓを含む。コンピュータインタフェース３０２の要請により、メールエージェント３０４は、送信されるｅ−ｍａｉｌメッセージを作成し、必要に応じて、送信されるそのようなメッセージをキュー３０６に置く。送信されるべきメールはメッセージトランスファエージェント（ＭＴＡ：Ｍｅｓｓａａｇｅ Ｔｒａｎｓｆｅｒ Ａｇｅｎｔ）３０８に転送される。Ｕｎｉｘ（登録商標）システムに対する共通ＭＴＡはＳｅｎｄｍａｉｌである。典型的には、メッセージトランスファエージェント３０８及び３１２は、ＴＣＰ／ＩＰコネクション３１０を用いて通信を交換する。特に、メッセージトランスファエージェント３０８と３１２との間の通信はいずれのサイズのネットワーク（例えば、ＷＡＮ又はＬＡＮ）に亘って存在することが可能である。更に、メッセージトランスファエージェント３０８及び３１２はいずれの通信プロトコルを用いることが可能である。本発明の一実施形態においては、図６Ａの要素３０２および３０４は、アプリケーションユニットの使用をモニタリングするためにライブラリに存在する。

メッセージトランスファエージェント３１２から、ｅ−ｍａｉｌメッセージはユーザメールボックス３１４に記憶され、メールエージェント３１６に転送され、最終的に、受信端末として機能する端末３１８においてユーザに送信される。

この“蓄積型（ｓｔｏｒｅ−ａｎｄ−ｆｏｒｗａｒｄ）”プロセスは、直接接続がメール受信者と確立されるまで待つ必要があることから、送信メールエージェント３０４を解放する。ネットワーク遅延のために、通信は、アプリケーションが感応しない実質的時間量を必要とする。そのような感応性における遅延は、一般に、アプリケーションユニットのユーザには受け入れられない。蓄積型プロセスとしてｅ−ｍａｉｌを用いることにより、固定された時間の期間（例えば、３日）の間、故障が自動的に生じた後、再送信が試みられる。代替の実施形態においては、アプリケーションは、１つ又はそれ以上の個別のスレッドに通信要求を渡すことにより、待つことを回避することができる。そのようなスレッドは、このとき、受信端末３１８との通信を制御することができる一方、アプリケーションは、再び、ユーザインタフェースへの応答を開始する。ユーザが継続する前に終了した通信を有するように望む、他の実施形態においては、受信端末との直接通信が用いられる。そのような直接通信は、送信端末と受信端末との間のファイアウォールによりブロックされないいずれのプロトコルを用いることができる。そのようなプロトコルの例としては、Ｔｅｌｎｅｔ、ＦＴＰ（Ｆｉｌｅ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）及びＨＴＴＰ（Ｈｙｐｅｒ Ｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）がある。

インターネットのような公衆ＷＡＮは、一般に、安全であるとはみなされない。それ故、メッセージの機密性を保つことが望まれる場合、公衆ＷＡＮ（及び、他企業プレイベートＷＡＮ）に亘って伝送されるメッセージを暗号化することができる。暗号化機構は周知であって、市販されており、本発明と共に用いられることが可能である。例えば、Ｃ＋＋ライブラリ機能、ｃｒｙｐｔ（）は、Ｕｎｉｘ（登録商標）オペレーティングシステムと共に使用するためにＳｕｎ Ｍｉｃｒｏｓｙｓｔｅｍｓ社から市販されている。暗号化及び復号化ソフトウェアパッケージは周知であって、市販されており、本発明と共にしようされることが又、可能である。そのようなパッケージの１つはＰＧＰ社から市販されているＰＧＰである。

図６Ａの一般的構造に対する代替としては、コンピュータインタフェース３０２、メールエージェント３０４、メールキュー３０６及びメッセージトランスファエージェント３０８として機能する単一のコンピュータを用いることが可能である。更に、メッセージトランスファエージェント３０８は、ＴＣＰ／ＩＰコネクション３１０によりメッセージトランスファエージエンと３１２に接続される。図６Ｃの実施形態においては、装置／電気製品３００は、ｅ−ｍａｉｌの能力を用いてＴＣＰ／ＩＰコネクション３１０に直接接続される。図６Ｃの実施形態の１つを使用することは、装置／電気製品３００としてｅ−ｍａｉｌの能力と共にファックス装置を用いることを含む（例えば、ＲＦＣ２３０５において規定されるように（インターネットメールを用いるファックスの簡単なモード））。

図６Ｄは、装置／電気製品３００は、それ自体によりｅ−ｍａｉｌを直接受信する能力を有しないが、装置／電気製品３００はメールサーバからメールを受信するためにＰＯＰ３プロトコルを用いるように、メールボックス３１４及びメッセージトランスファエージェント３０８を含むメールサーバ／ＰＯＰ３サーバへのコネクション３１０を有する。

図７は、メールを転送するための代替の実施形態を示しており、上で参照したＳｔｅｖｅｎｓによる文献の図２８．３から適合化されたものである。図７は、各々の端部にリレーシステムを有する電子メールシステムを示している。図７の構成は、機構における一システムがメールハブとして機能することを可能にする。図７においては、２つのメールエージェント３０４及び３１６の間に接続された４つのＭＴＡが存在する。これらのＭＴＡは、ローカルＭＴＡ３２２Ａ、リレーＭＴＡ３２８Ａ、リレーＭＴＡ３２８Ｂ及びローカルＭＴＡ３２２Ｄを含む。メールメッセージのために用いられる最も一般的なプロトコルは、本発明と共に用いられることができるＳＭＴＰ（Ｓｉｍｐｌｅ Ｍａｉｌ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）であるが、いずれの好ましいメールプロトコルを用いることが可能である。図７において、参照番号３２０は、コンピュータインタフェース３０２、メールエージェント３０４及びローカルＭＴＡ３２２Ａ を含む送信ホストを表す。装置／電気製品３００は、送信ホスト３２０に接続され、又は、代替として、送信ホスト３２０内に含まれる。他の場合には、装置／電気製品３００及びホスト３２０は、ホストの能力が装置／電気製品３００に組み込まれた１つの機器の状態にあることが可能である。他のローカルＭＴＡ３２２Ｂ、３２２Ｃ、３２２Ｅ及び３２２Ｆを又、含むことが可能である。送信及び受信されるメールは、リレーＭＴＡ３２８Ａのメールのキュー３０６Ｂにおいてキューイングされることが可能である。メッセージはＴＣＰ／ＩＰコネクション３１０（例えば、インターネットコネクション又はいずれの他の種類のネットワークにおけるコネクション）において転送される。

送信されたメッセージは、リレーＭＴＡ３２８Ｂにより受信され、必要に応じて、メールのキュー３０６Ｃに記憶される。メールは、次いで、受信ホスト３４２のローカルＭＴＡ３２２Ｄに転送される。メールは、１つ又はそれ以上のユーザメールボックス３１４に置かれ、続いて、メールエージェント３１６に転送され、最終的に、端末３１８においてユーザに転送されることが可能である。必要に応じて、メールはユーザインタラクションなしで端末に直接、転送されることが可能である。

図５のコンピュータ２６６及び２７６を含む、本発明において用いられる種々のコンピュータは、図８に示すように実施されることが可能である。更に、必要に応じて、図５のサービスマシン２５４、コンピュータ２７２及びコンピュータ２８２を含む、本発明において用いられるいずれの他のコンピュータは、図８に示すコンピュータと類似する方式で実施されることが可能である。しかしながら、図８に示している要素の全てが、それらのコンピュータの各々において必要とされるとは限らない。

図８においては、コンピュータ３６０は、例えば、Ｉｎｔｅｌ、ＡＭＤ、Ｍｏｔｏｒｏｌａ、日立及びＮＥＣのような企業から市販されているマイクロプロセッサを含むいずれのタイプのプロセッサとして実施されることが可能であるＣＰＵ３６２を含む。ＲＡＭ３６４のような作用メモリがあり、無線インタフェース３６６は無線装置３６８と通信する。インタフェース３６６と装置３６８との間の通信はいずれの無線媒体（例えば、高周波又は光波）を用いることが可能である。高周波は、Ｂｌｕｅｔｏｏｔｈ仕様において開示されているような周波数ホッピング技術を用いて又はＣＤＭＡ（Ｃｏｄｅ Ｄｉｖｉｓｉｏｎ Ｍｕｌｔｉｐｌｅ Ａｃｃｅｓｓ）通信のようなスペクトル拡散技術を用いて、実施されることが可能である。

コンピュータ３６０はＲＯＭ３７０とフラッシュメモリ３７１とを含むが、いずれの他の種類の不揮発性メモリ（例えば、電気的消却プログラム可能ＲＯＭ、即ち、ＥＥＰＲＯＭ）をフラッシュメモリ３７１に付加して又はそれに代えて用いることが可能である。入力制御器３７２はキーボード３７４及びマウス３７１に接続されている。シリアル装置３８０に接続されたシリアルインタフェース３７８がある。更に、パラレルインタフェース３８２はパラレル装置３８４に接続され、ユニバーサルシリアルバス（ＵＳＢ）インタフェース３８６はユニバーサルシリアルバス装置３８８に接続され、又、ＩＥＥＥ １３９４装置３９８に接続された、一般に、ファイアワイア（ｆｉｒｅ ｗｉｒｅ）装置と呼ばれるＩＥＥＥ １３９４装置４００がある。システムバス３９０はコンピュータ３６０の種々の要素に接続している。ディスク制御器３９６は、フロッピー（登録商標）ディスクドライブ３９４及びハードディスクドライブ３９２に接続される。通信制御器４０６は、コンピュータ３６０がネットワーク４０４に亘って他のコンピュータ（例えば、ｅ−ｍａｉｌメッセージを送信することにより）通信することを可能にする。Ｉ／Ｏ（Ｉｎｐｕｔ／Ｏｕｔｐｕｔ）制御器４０８は、例えば、ＳＣＳＩ（Ｓｍａｌｌ Ｃｏｍｐｕｔｅｒ Ｓｙｓｔｅｍ Ｉｎｔｅｒｆａｃｅ）バスを用いて、ハードディスク４１２及びプリンタ４１０に接続される。又、ＣＲＴ（陰極線管）４１４に接続された表示制御器４１６があるが、液晶表示装置、発光ダイオード表示装置、プラズマ表示装置等を含む、いずれの他の種類の表示装置を用いることが可能である。

ここで、図９を参照するに、本発明の代表的な実施形態に従った、全体的なシステム９００の模式図を示している。システム９００は、複数の装置であって、例えば、レーザプリンタ９０８、スキャナ９１０、ネットワーク装置９１２及び多機能プリンタ９１４を含むように示されており、全てはネットワーク１００に接続されている。これらの複数の装置は、一般に、ここでは、“被モニタリング装置”という。システム９００は又、被モニタリング装置９０８、９１０、９１２及び９１４をモニタリングし、制御するためのネットワーク１００に接続されたワークステーション／モニタリングシステム９０２（以下、制御器９０２という）を含む。各々の被モニタリング装置９０８、９１０、９１２及び９１４には一意のアドレスが与えられている。例えば、ある装置に割り当てられたＩＰアドレスは、その装置に対する一意のアドレスとなる。それ故、制御器９０２においてユーザは、それぞれの被モニタリング装置に割り当てられた一意のＩＰアドレスにアクセスすることにより被モニタリング装置９０８乃至９１４の間のそれぞれの装置にアクセスすることができる。本発明は、ネットワークに接続された装置を一意に識別するためにＩＰアドレスを用いることに限定されるものではないことを理解することができるであろう。

被モニタリング装置９０８乃至９１４の間の装置にアクセスするとき、制御器９０２は、ＳＮＭＰ又は／及びＨＴＴＰプロトコルにより種々の情報を得る。そのような情報は、トラブルシューティング情報を含む装置の動作状態に関する詳細情報を含む。例えば、制御器９０２は、特定の装置のジャム（ｊａｍ）位置を得て、アクセスし、そのジャムを取り除くようにその装置の担当者にメッセージを送信する。レーザプリンタ９０８の動作状態／詳細は、トナーレベル、ペーパージャムの兆候、プリンタのトレーのプリント用紙の品質等のような詳細を含む。

制御器９０２はネットワーク１００に物理的に接続されることが可能であり、又は無線で結合されることが可能であることが理解されるであろう。例えば、ネットワーク１００に無線で結合されたように示されている携帯情報端末（ＰＤＡ）９２０又はラップトップコンピュータ９２２は又、制御器９２２として用いられることが可能である。アクセスポイント９２４は、ネットワーク１００とＰＤＡ９２２又はラップトップコンピュータ９２２との間の無線通信を可能にするインタフェースとして機能する。以下、本発明は、制御器９０２はネットワークに接続された被モニタリング装置の状態を制御し、モニタリングすることを前提として説明することとする。

ネットワーク１００は、そのような被モニタリング装置の制御及びモニタリングを可能にする被モニタリング装置９０８乃至９１４と制御器９０２との間の通信を容易にする。ネットワークに接続されている装置の数は、本発明においては限定されない。ネットワーク１００はローカルエリアネットワーク（ＬＡＮ）又は広域ネットワーク（ＷＡＮ）であることが可能である。同様に、被モニタリング装置９０８、９１０、９１２及び９１４は単なる例示として示されている。

制御器９０２は、記憶装置９０４及びデータベース９０６に通信可能であるように結合されている。記憶装置９０４は、ハードディスク、光ディスク及び／又は外部ディスク装置を含む。データベース９０６は記憶装置９０４に通信可能であるようにリンクされ、記憶装置９０４に記憶されたデータの容易な検索のためのＲＤＢＭＳ（Ｒｅｌａｔｉｏｎａｌ Ｄａｔａｂａｓｅ Ｍａｎａｇｅｍｅｎｔ Ｓｙｓｔｅｍ）を含む。記憶装置９０４は、好ましくは、被モニタリング装置９０８乃至９１４の各々に関する詳細データを記憶している。例えば、レーザプリンタ９０８の型、モデル、種々の機能及びトラブルシューティングの詳細のような詳細情報は記憶装置９０４に記憶されている。又、所定の基準値と比較される、レーザプリンタの動作状態についての偏差値は又、記憶装置９０４に記憶されることが可能である。データベース９０６及び記憶装置９０４は制御器９０２に通信可能であるように結合されると説明したが、制御器９０２はインストールされるデータベース及び設置される記憶装置と共に構築されることが可能であることが理解されるであろう。そのような場合、記憶装置９０６及びデータベース９０４は制御器９０２に内在するとして示される。

制御器９０２は、複数の装置９０８乃至９１４の制御及びモニタリングを用にするためにソフトウェアと共にインストールされる。シンプルネットワーク管理プロトコル（ＳＮＭＰ）、ファイル転送プロトコル（ＦＴＰ）及びハイパーテキスト転送プロトコル（ＨＴＴＰ）は複数の装置９０８乃至９１４をモニタリングするための制御器９０２により用いられ、複数の装置９０８乃至９１４から受信されたデータは、参照番号９５０に示すように、ＡＳＮ．１バイナリフォーマット、ＨＴＴＭフォーマット又はＸＭＬフォーマットの方式で提供される。

図９はイメージング装置のみを示しているが、モニタリング装置と複数の被モニタリング装置との間で情報を通信するためのネットワークは、電気製品と検針装置がネットワークに接続されている家庭用ネットワークを含むことが可能である。制御器／ワークステーション９０２により収集されたデータは、ｅ−ｍａｉｌ、ＦＴＰ又は更なる処理のためのリモート装置に対するいずれの他の通信プロトコル手段により送信されることができる。ワークステーション９０２、ＰＤＡ９２０又はラップトップ９２２は、データを収集し、データを記憶し、通信プロトコルによりデータを送信する制御器であることが可能であるが、制御器はネットワークに接続されたいずれの装置であることが可能であることが理解されるであろう。いずれのネットワーク装置（例えば、プリンタ）は、ネットワークにおいて他の装置の状態をモニタリングし、収集されたデータを記憶し、及び／又はいずれの他の通信プロトコル手段（例えば、ｅ−ｍａｉｌ、ＦＴＰ）により収集されたデータを送信することが可能であるモニタリングシステムを含むことができる。Ｘｅｒｏｘ Ｄｏｃｕｍｅｎｔ ４０２５及びＨＰ ＬａｓｅｒＪｅｔ ９０００は両方共、ｅ−ｍａｉｌを送信することができる。

モニタリングシステムアーキテクチャ
図１０は、本発明の代表的な実施形態に従ったリモート装置に関連したデータのモニタリングにおいて用いられるモニタリングシステム１０００（及び、関連インタフェース機能）を示している。モニタリングシステム１０００は、例えば、ＮＴにおけるＳｅｒｖｉｃｅ、ＷＩｎｄｏｗｓ ２０００及びＵｎｉｘ（登録商標）におけるＤａｅｍｏｎのようなコンピュータ駐在プログラムであるソフトウェアモジュールＭｏｎｉｔｏｅＳｅｒｖｉｓｅ １００４を含む。好ましい実施形態においては、モニタリングシステムは、オブジェクト指向ソフトウェア環境を用いて実施される。又、タイマーモジュール１００２及びモニタモジュール１００６はモニタリングシステム１０００に含まれる。タイマーモジュール１００２及びモニタモジュール１００６は、モニタサービスモジュール１００４により呼び出されるライブラリ機能である。例えば、モニタサービスモジュール１００４はＩｎｉｔＴｉｍｅｒ１００３機能と呼び出すことによりタイマーモジュール１００２を初期化し、ｏｂｔａｉｎＤｅｌａｙＡｎｄＡｃｔｉｏｎ（ｉｎｔ＆，ｉｎｔ＆）機能を呼び出すことにより遅延パラメータ及びアクションパラメータを得る。ｉｎｉｔ（）機能は又、図１３に示しように、モニタモジュール１００６における種々のモジュールを初期化するためのモニタサービスモジュール１００４と呼ばれる。ｉｎｉｔ（）機能は、既知の方法により収集されたＩＰアドレス、パラメータ名及び値を含む外部ソースにより被モニタリング装置に割り当てられたＩＰアドレス及びパラメータ値を得るために用いられることができる。モニタモジュール１００６は、下で更に詳細に説明するように、支援データベース１０２４に及びモニタデータベース１０１４に通信可能であるように結合されている。

一旦、被モニタ装置のＩＰアドレスが得られると、ＩＰアドレスは、製造メーカー（ベンダ）及びモデル情報のような情報を得るために被モニタリング装置と連絡をとるモニタリングシステムにより用いられる。モニタリングシステム１０００により実行される一部の機能には次のような機能がある。

ｖｏｉｄ ｉｎｉｔＴｉｍｅｒ（ｖｏｉｄ）
この機能はタイマーを初期化する。特に、この機能はレジストリからタイミング情報を得るためにタイマーオブジェクトをトリガする。

ｖｏｉｄ ｏｂｔａｉｎＤｅｌａｙＡｎｄＡｃｔｉｏｎ（ｉｎｔ＆ｏｕｔ＿ｎＤｅｌａｙ，ｉｎｔ＆ｏｕｔ＿ｎＡｃｔｉｏｎ）
この機能は、アクションインジケータ及びスリープ機能（１０００を掛ける必要がある）に対してすぐに遅延時間を返送する。アクションインジケータは、次のように規定される。即ち、０＝イベントチェッキング；１＝被モニタリングデータを送信する；及び、２＝データをモニタリングし、ローカルデータベースに記憶する。

ｉｎｔ ｉｎｉｔ（ｖｏｉｄ）
この機能はモニタを初期化する。更に、それは装置がモニタリングされるようにする。リターンｉｎｔはエラーがないとして０が定義されるエラーコードである。
ｉｎｔ ｍｏｎｉｔｏｒＳｔａｔｕｓ（ｉｎｔ ｉｎ＿ｎＡｃｔｉｏｎ）
この機能はプリセット情報である。リターンｉｎｔはエラーがないとして０が定義されるエラーコードである。

ｉｎｔ ｅｎｄ（ｖｏｉｄ）
この機能は、オブジェクトを閉じる前にモニタをきれいにする。リターンｉｎｔはエラーがないとして０が定義されるエラーコードである。

モニタモジュール
図１１は、種々のソフトウェアサブモジュールと、モニタモジュール１００６のサブモジュール間の呼び出し機能とを含むモニタモジュール１００６の構造の詳細を示している。モニタモジュール１００６は、多くのモジュールにより用いられるクラスを含む共通モジュール１１０１、図１０に示すようにインタフェース機能により規定されるタスクを終了するために、他のサブモジュール（装置ＯＤＢＣモジュール１００４、装置モジュール１１１０及びＨＷａｃｃｅｓｓモジュール１１１６を含む）を管理するモニタマネージャモジュール１１０２を含む。特に、装置ＯＤＢＣモジュール１１０４は、標準インタフェースにより外部装置情報にアクセスするために、アクセスされる。ＨＷａｃｃｅｓｓモジュール１１１６は、複数の通信プロトコルからの選択された通信プロトコル（例えば、ＨＴＴＰ、ＳＮＭＰ及びＦＴＰ）を用いて、被モニタリング装置からベンダ、モデル、一意のＩＤ及び状態情報を得る。

次に、上記のモニタモジュール間のインタフェースの一部の列挙及び説明を行う。例えば、一部のモジュールは、変換フォーマットにおいて情報を得るために“ｉｎｉｔ”機能又は付加機能を有する必要がある。

ｖｏｉｄ ｕｐｄａｔａＣｏｎｆｉｇ（ｓｔｄ：：ｍａｐ＜ｉｎｆｏＴｙｐｅ，ｓｔｄ：：ｓｔｒｉｎｇ＞＆）
この機能が呼び出される前に、呼び出し機能は、獲得された機能がヌルストリングを返送する場合、ベンダおよびモデルエントリを置き換えないことが好ましい。この機能は、装置ＯＤＢＣモジュール１１０４において現在の記録の装置情報データベースを更新する。この機能は、下のＯｂｔａｉｎＣｏｎｆｉｇが最初に呼び出されるとき、最も効率的である。先ず、この機能は、ＩＰアドレスが装置ＯＤＢＣモジュール１１０４において同じであるかどうかを調べる。ＩＰアドレスフィールドが同じでない場合、正確なＩＰアドレスを有する記録がデータベースから得られる。次いで、他のフィールドがコピーされ、記録は更新される。

ｂｏｏｌ ｏｂｔａｉｎＣｏｎｆｉｇ（ｓｔｄ：：ｍａｐ＜ｉｎｆｏＴｙｐｅ，ｓｔｄ：：ｓｔｒｉｎｇ＞＆，ｓｔｄ：：ｍａｐ＜ｓｔｄ：：ｓｔｒｉｎｇ，ｓｔｄ：：ｖｅｃｔｏｒ＜ＳＰａｒａｍｅｔｅｒ＞＞＆）
この機能は、所定のフォーマットにおける装置情報に対する装置ＯＤＢＣモジュール１１０４からマップを、並びにプロトコル及び関連パラメータのマップを得る。この機能は、データが返送される場合、真を返送し、更なるデータが存在しない場合、偽を返送する。

ｂｏｏｌ ｓａｖｅＳｔａｔｕｓ（ｓｔｄ：：ｍａｐ＜ｉｎｆｏＴｙｐｅ，ｓｔｄ：：ｓｔｒｉｎｇ＞＆）
この機能は装置ＯＤＢＣモジュール１１０４に状態情報を記憶する。この機能は、記憶が成功したとき、真を返送し、そうでないときは、偽を返送する。

Ｃｄｅｖｉｃｅ ^＊ ｃｒｅａｔｅＤｅｖｉｃｅ（ｃｏｎｓｔ ｓｔｄ：：ｓｔｒｉｎｇ＆ｉｎ＿ｓＩＰ，ＣＨＷａｃｃｅｓｓ＆ｉｎ＿ＨＷａｃｃｅｓｓ，ｓｔｄ：：ｍａｐ＜ｓｔｄ：：ｓｔｒｉｎｇ，ｓｔｄ：：ｖｅｃｔｏｒ＜ＳＰａｒａｍｅｔｅｒ＞＞＆ｉｎ＿ＰｒｏｔｏｃｏｌＰａｒａｍｅｔｅｒｓ）
この機能は、ｉｎ＿ｓＩＰとｉｎ＿ＰｒｏｔｏｃｏｌＰａｒａｍｅｔｅｒｓとに基づいて
装置を与える。与えられた装置はＣＨＷａｃｃｅｓｓによりハードウェアに接続される。装置を与えることができない場合、その機能は０を返送する。それ故、呼び出しオブジェクトは、返送オブジェクトポインタが０であるか又は０でないかを調べる必要がある。

ｂｏｏｌ ｃａｎＡｃｃｅｓｓＨＷ（ｖｏｉｄ）
この機能は、ハードウェアがネットワークによりアクセスされることができるとき、真を返送し、そうでないとき、偽を返送する。

ｂｏｏｌ ｇｅｔＶｅｎｄｅｒ（ｓｔｄ：：ｓｔｒｉｎｇ＆ｏｕｔ＿ｓＶｅｎｄｅｒ）
この機能はベンダ名を返送する。装置がシステムにより支援されているが、プロトコルの１つによりアクセスされることができない場合、そのストリングは“ＧＥＮＥＲＩＣ”を含む。プロトコルにおいてエラーが検出される場合、その機能はヌルストリングを返送する。そうでない場合、その機能は真を返送する。

ｂｏｏｌ ｇｅｔＭｏｄｅｌ（ｓｔｄ：：ｓｔｒｉｎｇ＆ｏｕｔ＿ｓＭｏｄｅｌ）
この機能は装置のモデルを得る。モデルが得られる場合、この機能は真を返送する。エラーがプロセスにおいて検出される場合、その関数はヌルストリングを伴って偽を返送する。

ｂｏｏｌ ｇｅｔＵｎｉｑｕｅＩＤ（ｓｔｄ：：ｓｔｒｉｎｇ＆ｏｕｔ＿ｓＵｎｉｑｕｅＩＤ）
この機能は装置の一意のＩＤを返送する。一意のＩＤが得られる場合、この機能は真を返送する。エラーがプロセスにおいて検出された場合、その機能はヌルストリングを伴って偽を返送する。

ｂｏｏｌ ｏｂｔａｉｎＳｔａｔｕｓ（ｍａｐ＜ｉｎｆｏＴｙｐｅ，ｓｔｄ：：ｓｔｒｉｎｇ＞＆ｏｕｔ＿ＳｔａｔｕｓＭａｐ）
この機能は状態マップを返送する。この機能は、状態が返送されるとき、真を返送し、状態が得られないとき、偽を返送する。この機能は、ＨＷａｃｃｅｓｓ及び装置モジュールからの異なるマップを返送することに留意されたい。装置モジュールにおいて、イベント状態情報は、ＨＷａｃｃｅｓｓからのマップに加えられ、消去される。

ｅｎｕｍ ｃｈｅｃｋＥｖｅｎｔＳｔａｔｕｓ（ｖｏｉｄ）
この機能はネットワーク装置のイベントを得るようにトリガする。ｅｎｕｍタイプ及び値はクラスにおいて規定される必要がある。ｅｎｕｍ値は、ｅＮｏＥｖｅｎｔＳｉｎｃｅＣｌｅａｒＡｎｄＮｏＥｖｅｎｔＤｅｔｅｃｔｅｄ、ｅＮｏＥｖｅｎｔＳｉｎｃｅＣｌｅａｒＡｎｄＥｖｅｎｔＤｅｔｅｃｔｅｄ、ｅＥｖｅｎｔＳｉｎｃｅＣｌｅａｒＡｎｄＮｏＥｖｅｎｔＤｅｔｅｃｔｅｄ、ｅＥｖｅｎｔＳｉｎｃｅＣｌｅａｒＡｎｄＥｖｅｎｔＤｅｔｅｃｔｅｄを含む必要がある。

ｂｏｏｌ ｏｂｔａｉｎＥｖｅｎＳｔａｔｕｓ（ｓｔｄ：：ｍａｐ＜ｉｎｆｏＴｙｐｅ，ｓｔｄ：：ｓｔｒｉｎｇ＞＆ｏｕｔ＿ＥｖｅｎｔＳｔａｔｕｓＭａｐ）
この機能はイベント状態情報を得る。この機能は、状態が返送されるとき、真を返送し、状態が得られないとき、偽を返送する。

ｖｏｉｄ ｃｌｅａｒＥｖｅｎｔＳｔａｔｕｓ（ｖｏｉｄ）
この機能は、最後のｏｂｔａｉｎＳｔａｔｕｓ機能がＥｖｅｎｔＳｔａｔｕｓを呼び出す又は消去するため、蓄積されたイベント状態を消去する。

ｖｏｉｄ ｉｎｉｔＢｅｇｉｎ（ｖｏｉｄ）
この機能は、特に、ソフトウェア装置オブジェクトを与えるために、ＨＷａｃｃｅｓｓにより初期化プロセスを開始する。

ｖｏｉｄ ｉｎｉｔＥｎｄ（ｖｏｉｄ）
この機能は、特に、装置オブジェクト付与が終了したことを表すＨＷａｃｃｅｓｓにより初期化プロセスを終了する。

ｂｏｏｌ ｃａｎＡｃｃｅｓｓＩＰ（ｃｏｎｔ ｓｔｄ：：ｓｔｒｉｎｇ＆ｉｎ＿ｓＩＰ，ｓｔｄ：：ｍａｐ＜ｓｔｄ：：ｓｔｒｉｎｇ， ｓｔｄ：：ｖｅｃｔｏｒ＜ＳＰａｒａｍｅｔｅｒ＞＞＆ｉｎ＿ＰｒｏｔｏｃｏｌＰａｒａｍｅｔｅｒｓ）
この機能は、装置がＩＰアドレスにおいてアクセスされることができるとき、真を返送し、そうでないとき、偽を返送する。

ｂｏｏｔ ｏｂｔａｉｎＶｅｎｄｅｒ（ｓｔｄ：：ｓｔｒｉｎｇ＆ｏｕｔ＿ｓＶｅｎｄｅｒ，ｓｔｄ：：ｍａｐ＜ｓｔｄ：：ｓｔｒｉｎｇ，ｓｔｄ：：ｖｅｃｔｏｒ＜ＳＰａｒａｍｅｔｅｒ＞＞＆ｉｎＯｕｔ＿ＰｒｏｔｏｃｏｌＰａｒａｍｅｔｅｒｓ，ｃｏｎｓｔ ｓｔｄ：：ｓｔｒｉｎｇ＆ｉｎ＿ｓＩＰ）
この機能はベンダを得る。この機能は、動作が成功する場合、真を返送し、そうでない場合、空ストリングを伴って偽を返送する。この機能呼び出しの間、プロトコルは調べられ、特定のプロトコルが状態モニタリングのために用いられない場合、そのプロトコルはｉｎＯｕｔ＿ＰｒｏｔｏｃｏｌＰａｒａｍｅｔｅｒｓから削除される。

ｂｏｏｔ ｏｂｔａｉｎＭｏｄｅｌ（ｓｔｄ：：ｓｔｒｉｎｇ＆ｏｕｔ＿ｓＭｏｄｅｌＮａｍｅ，ｓｔｄ：：ｍａｐ＜ｓｔｄ：：ｓｔｒｉｎｇ，ｓｔｄ：：ｖｅｃｔｏｒ＜ＳＰａｒａｍｅｔｅｒ＞＞＆ｉｎＯｕｔ＿ＰｒｏｔｏｃｏｌＰａｒａｍｅｔｅｒｓ，ｃｏｎｓｔ ｓｔｄ：：ｓｔｒｉｎｇ＆ｉｎ＿ｓＩＰ）
この機能はモデル名を得る。この機能は、動作が成功する場合、真を返送し、そうでない場合、空ストリングを伴って偽を返送する。この機能呼び出しの間、プロトコルは調べられ、特定のプロトコルが状態モニタリングのために用いられない場合、そのプロトコルはｉｎＯｕｔ＿ＰｒｏｔｏｃｏｌＰａｒａｍｅｔｅｒｓから削除される。

ｂｏｏｔ ｏｂｔａｉｎＵｎｉｑｕｅＩＤ（ｓｔｄ：：ｓｔｒｉｎｇ＆ｏｕｔ＿ｓＵｎｉｑｕｅＩＤ，ｓｔｄ：：ｍａｐ＜ｓｔｄ：：ｓｔｒｉｎｇ，ｓｔｄ：：ｖｅｃｔｏｒ＜ＳＰａｒａｍｅｔｅｒ＞＞＆ｉｎＯｕｔ＿ＰｒｏｔｏｃｏｌＰａｒａｍｅｔｅｒｓ，ｃｏｎｓｔ ｓｔｄ：：ｓｔｒｉｎｇ＆ｉｎ＿ｓＩＰ）
この機能は一意のＩＤを得る。この機能は、動作が成功する場合、真を返送し、そうでない場合、空ストリングを伴って偽を返送する。この機能呼び出しの間、プロトコルは調べられ、特定のプロトコルが状態モニタリングのために用いられない場合、そのプロトコルはｉｎＯｕｔ＿ＰｒｏｔｏｃｏｌＰａｒａｍｅｔｅｒｓから削除される。
ＥｅｒｒｏｒＣｏｄｅ ｏｂｔａｉｎＥｖｅｎｔ Ｓｔａｔｕｓ（ｓｔｄ：：ｍａｐ＜ｉｎｆｏＴＹｐｅ，ｓｔｄ：：ｓｔｒｉｎｇ＞＆ｏｕｔ＿ＳｔａｑｔｕｓＭａｐ， コンｓｔｓｔｄ：：ｓｔｉｎｇ＆ｉｎ＿ｓＩＰ，ｓｔｄ：：ｍａｐ＜ｓｔｄ：：ｓｔｒｉｎｇ，ｓｔｄ：：ｖｅｃｔｏｒ＜Ｓｐａｒａｍｅｔｅｒ＞＞＆ｉｎ＿ＰｒｏｔｏｃｏｌＰａｒａｍｅｔｅｒｓ）
この機能はイベント状態を得る。ＥｒｒｏｒＣｏｄｅは下のように定義される。

ｂｏｏｔ ｏｂｔａｉｎＳｔａｔｕｓ（ｓｔｄ：：ｍａｐ＜ｉｎｆｏＴｙｐｅ，：：ｓｔｒｉｎｇ＞＆ｏｕｔ＿ＳｔａｔｕｓＭａｐ，ｃｏｎｓｔ ｓｔｄ：：ｓｔｒｉｎｇ＆ｉｎ＿ｓＩＰ，ｃｏｎｓｔ ｓｔｄ：：ｓｔｒｉｎｇ＆ｉｎ＿ｓＶｅｎｄｅｒ，ｃｏｎｓｔ ｓｔｄ：：ｓｔｒｉｎｇ＆ｉｎ＿ｓＭｏｄｅｌ，ｓｔｄ：：ｍａｐ＜ｓｔｄ：：ｓｔｒｉｎｇ，ｓｔｄ：：ｖｅｃｔｏｒ＜ＳＰａｒａｍｅｔｅｒ＞＞＆ｉｎ＿ＰｒｏｔｏｃｏｌＰａｒａｍｅｔｅｒｓ）
この機能は装置の状態を得る。この機能は、動作が成功する場合、真を返送し、そうでない場合、空マップを伴って偽を返送する。

図１２は、ＨＷａｃｃｅｓｓモジュール１１１６により受信されたキー値に関連する値の受信のために情報を交換するために、図１１に示すようなＨＷａｃｃｅｓｓモジュール１１１６により用いられるデータ構造を示している。例えば、図１２に示すようなＳＫｅｙＶａｌｕｅＩｎｆｏデータ構造は、所定のウェブページにおける特定の情報タイプ（ｍ＝ｉｎｆｏＴｙｐｅ１２０２に対応する）に対応する情報を得る方法を決定するために用いられる。典型的には、数多くのベンダは、被モニタリング装置に関するそれぞれのウェブページに表示されるキー情報を識別するために、ベンダ固有識別子及び命名法を用いる。例えば、プリンタ装置によりプリントされるページ数を決定するために、Ｈｅｗｌｅｔｔ Ｐａｃｋａｒｄ社は“ページカウント”機能を用いる一方、Ｘｅｒｏｘ社は、“給紙されたトータルシート”機能を用いて同様に識別する。本発明の機能は、ベンダ毎の多様性を克服するためのものであり、それ故、装置固有情報を識別する標準化され且つ一貫した方法を提供し、装置固有データ構造／ＳｋｅｙＶａｌｕｅＩｎｆｏ構造１２００を用いることにより情報に対応する値を抽出する。ＳｋｅｙＶａｌｕｅＩｎｆｏデータ構造１２００は公である属性を含む。

ＳｋｅｙＶａｌｕｅＩｎｆｏは、典型的には、データストリング又はキーストリングの方式で被モニタリング装置から受信された情報からの値情報を識別するために生成されたデータ構造である。ＳｋｅｙＶａｌｕｅＩｎｆｏは複数のフィールドを含み、各々のフィールドは図１２に示す情報により表される。ＳｋｅｙＶａｌｕｅＩｎｆｏ構造１２００は
、ストリングキーを表すｍ＿ｓＫｅｙフィールド１２０４と、値情報が位置付けされることが可能である、好ましくは、ストリングにおける位置の数を示すタグベースの値であるｍ＿ｎＰｏｓｉｔｉｏｎフィールド１２０６と、ｍ＿ｎＩｎＬｉｎｅＰｏｓｉｔｉｏｎフィールド１２１２とを含む。例えば、モニタリングの対象となるプリンタ装置のページカウントを、キーワードの次の第２位置に見つけることが可能である。ｍ＿ｓＴｙｐｅ１２０８は、被モニタリング装置の表示されたウェブページから検索することができる情報のタイプを表す。

例えば、被モニタリング装置のモデル名のような値がキー（製品名）の同じデータラインにおいて見つけられるとき、ｍ＿ｎＰｏｓｉｔｉｏｎフィールドは“０”であり、ｍ＿ｓＤｅｌｉｍｉｔｅｒ１２１０は、キーに関連する値を抽出するために用いられる特定のデリミタを示している。ＳＫｅｙＶａｌｕｅＩｎｆｏデータ構造は、ＨＴＭＬフォーマットにおいて被モニタリング装置から受信された情報からの値情報の抽出の方法を示している。

図１３は、図１０に示しているモニタモジュール１００６の呼び出しシーケンスを表す一連のｉｎｉｔ（）機能を示している。モニタマネージャ１１０２は、初期化機能を開始するためにＨＷａｃｃｅｓｓモジュール１１１６を初期化する。続いて、モニタマネージャ１１０２は被モニタリング装置に関する情報を得、被モニタリング装置と通信するために被モニタリング装置に割り当てられたＩＰアドレスを用いる。モニタマネージャ１１０２は、被モニタリング装置のコンフィグレーション情報を得るためにＤｅｖｉｃｅＯＤＢＣ１１０４にアクセスする。モニタマネージャ１１０２に返送されたコンフィグレーション情報は、例えば、被モニタリング装置のＩＰアドレスと、各々のプロトコルのためのパラメータ名及び関連値と、ベンダ／製造メーカー及び被モニタリング装置のモデル情報とを含む。一旦、ＩＰアドレスが得られると、モニタマネージャ１１０２は、図３５のＣＤｅｖｉｃｅＦａｃｔｏｒｙクラス１３０２により装置モジュール１１１０のクラス構造に基づいてソフトウェアオブジェクトを生成するために、ＩＰアドレスと、パラメータ名と、各々のプロトコルについての関連値とを設定する。装置ソフトウェアオブジェクトが連続的に生成されるとき、ＨＷａｃｃｅｓｓモジュール１１１６は、生成された装置ソフトウェアオブジェクトに記憶されるべき被モニタリング装置からの一意のＩＤと、モデルと、ベンダとを得るために用いられる。

一旦、ベンダと、モデルと、一意のＩＤとが装置ソフトウェアオブジジェクトから得られると、ＭｏｎｉｔｏｒＭｎａｇｅｒ１１０２は、被モニタリング装置から受信された情報を用いてデータベース（例えば、ＤｅｖｉｃｅＯＤＢＣ１１０４）を更新する。図１３は１つの装置を示しているが、ｏｂｔａｉｎＣｏｎｆｉｇからｕｐｄａｔｅＣｏｎｆｉｇまでの段階は、外部ソースにおいて特定の装置全てを網羅するために繰り返される。更に、図２３、２４、２５及び２６において指定された各々のプロトコルが初期化される。図２４、２５及び２６におけるＯＤＢＣに対応するデータベーステーブルはアクセスされ、被アクセス装置に対する必要な情報は、被アクセス装置からの状態情報収集がより早くなるように、外部記憶装置から内部データ構造に転送される。

図１４は、図１１に示すような、ＭｏｎｉｔｏｒＭｎａｇｅｒ１１０２により被モニタリング装置の状態を決定するための一連の状態モニタ機能を示している。ｏｂｔａｉｎＳｔａｔｕｓ機能が装置から生じてＨＷａｃｃｅｓｓにいくとき、下で説明するように、ＣＨＷａｃｃｅｓｓクラスは順に、異なるパラメータを有する抽象クラスにより、図２３、２４、２５及び２６において説明されている各々のプロトコルに対するｏｂｔａｉｎＳｔａｔｕｓ機能呼び出しを発する。各々のプロトコルモジュールは、被モニタリング装置から状態情報を抽出するために必要な情報を既に貯えており、その情報は図１３で表している初期化時間の間に一度アクセスされたものである。それ故、状態情報は、状態モニタリングの間に外部ソースにアクセスすることなく、被モニタリング装置から即座に抽出されることができる。このプロセスは、図１５に示すようなベクトルにおいて記憶された被モニタリング装置全てに亘って繰り返される。

図１５を参照するに、図１３及び１４に示すように、モニタマネージャ１１０２により及び図３５のＣＤｅｖｉｃｅＦａｃｔｏｒｙ１３０２により生成されＤｅｖｉｃｅに対して基準を有するベクトル１５００を示している。モニタマネージャ１１０２は、例えば、そのベクトルにおいて、図３５のＣＤｅｖｉｃｅＦａｃｔｏｒｙ１３０２により生成されたＣＤｅｖｉｃｅオブジェクト１５０４へのポインタ及びＣＤｅｖｉｃｅオブジェクト１５０２へのポインタのように、装置ポインタを記憶する。ベクトルシーケンスは、被モニタリング装置の状態を得るために繰り返される。被モニタリング装置のポーリングは、ｏｂｔａｉｎＳｔａｔｕｓコマンドを出すことにより装置オブジェクトに亘って実行される。一旦、ソフトウェアオブジェクトの各々の状態が得られると、そのような状態はＤｅｖｉｃｅＯＤＢＣ１１０４により更新される。状態モニタシーケンスについては図１４のところで説明したので、ここでは繰り返して説明しない。

テーブル１に示すＤｅｖｉｃｅＩｎｆｏ構造は、一例の被モニタリング装置に関する情報を示している。ＤｅｖｉｃｅＩｎｆｏ構造は、電話番号に加えて、コンタクトする人のｅ−ｍａｉｌアドレスを含む。

モニタリングデータベース
図１９は、各々の被モニタリング装置（又、図１を参照されたい）に対する装置情報を含むモニタデータベースの構成を示している。図１９に示すように、パラメータの集合、即ち、各々の通信プロトコル（例えば、ＳＮＭＰ、ＨＴＴＰ及びＦＴＰ）各々の１つの集合は、各々の被モニタリング装置に対する装置情報ＤｅｖｉｃｅＩｎｆｏ１９０２に関連している。更に、特定のプロトコル（例えば、ＳＮＭＰ１９０８、ＨＴＴＰ１９１０及びＦＴＰ１９１２）に対するパラメータの各々の集合は、例えば、ｓＰａｒ１Ｎａｍｅ及びｓＰａｒ１Ｖａｌｕｅ等のパラメータ名及び値の対のリストとして構成される。各々のプロトコルに対するパラメータ数は、図１９に示す数より短い場合も長い場合もあり得る。例えば、ユーザ名及びパスワードはＦＴＰパラメータとして記憶されることが可能である一方、コミュニティ名及びパスワードは所定の被モニタリング装置に対するＳＮＭＰパラメータとして記憶されることが可能である。図１９に示しているように、モニタデータベースは又、ＤｅｖｉｃｅＨｉｓｔｏｒｙ１９０４及びＥｎｕｍＣｏｒｒｅｓｐｏｎｄｅｎｃｅ１９０６に関連する情報を含む。図１７は、種々の通信プロトコルにより用いられるパラメータを渡すために用いられるＳＰａｒａｍｅｔｅｒデータ構造１７００を示している。ＳＰａｒａｍｅｔｅｒは２つのファイル、即ち、ｍ＿ｓＰａｒＮａｍｅ１７０２及びｍ＿ｓＰａｒＶａｌｕｅ１７０４を含み、それらはパラメータの名前および値をそれぞれ表す。

図１８は、各々の被モニタリング装置に関連したソフトウェアオブジェクトにモニタデータベースから得られた各々のプロトコルに対するパラメータのベクトルを渡すために用いられるマップ構造１８００を示している。マップ構造１８００は、各々のプロトコル／キーフィールド１８０２、１８０４及び１８０６を、図１７に示すＳＰａｒａｍｅｔｅｒフォーマットに従って配列された、パラメータ１８０８、１８１０及び１８１２それぞれの対応するベクトルに関連付ける。例えば、ＳＮＭＰプロトコル１８０２に対して、パラメータ１８０８のベクトルは、ＳＮＭＰプロトコルを有する被モニタリング装置にアクセスするために用いられる、パラメータ名、パラメータ値の対のリストを含むことが可能である。例えば、ベクトル１８０８に記憶されたＳＮＭＰパラメータ名は、対応するパラメータ値と共に、“コミュニティ名”及び“パスワード”を含むことが可能である。しかしながら、マップ構造１８００の構成はいずれの数のプロトコル及び関連パラメータベクトルを可能とし、図１８に示すＳＮＭＰ、ＨＴＴＰ及びＦＴＰプロトコルに限定されるものではない。

支援データベース
図２０乃至２２は、図１０に示している支援データベース１０２４の構成を示している。各々の被モニタリング装置から状態情報を抽出するために必要な情報を含む支援データベースは通信プロトコルにより構成される。例えば、被モニタリング装置から情報を抽出するために用いられるＳＮＭＰ関連支援情報のための支援データベースの構成を示す図２０は、ＳＮＭＰＶｅｃｔｏｒ２００２、ＳＮＭＰＣｏｍＶｅｎｄｏｅＳｔａｔｕｓ２００４、ＥｎｕｍＣｏｒｒｅｓｐｏｎｄｅｎｃｅ２００６及びＳＮＭＰＶｅｎｄｅｒＭｏｄｅｌＳｔａｔｕｓ２００８データ構造を含む。支援データベースにおける所定のデータ構造は、抽出を制御するパラメータと共に、抽出される状態情報のタイプを一意に識別するパラメータを含むことが可能である。例えば、ＳＮＭＰＣｏｍＶｅｎｄｏｒＳｔａｔｕｓデータベース構造２００４は、抽出される情報（例えば、トナーレベル）のタイプを識別するＥＮＵＭフィールド２００９と、他のプロトコルに関連する抽出された情報の重要性又は重みを表すｎＲｅｌａｔｉｖｅＰｒｉｏｒｉｔｙフィールド２０１０とを含む。それ故、同じ情報が、２つ以上のプロトコルを用いて、被モニタリング装置から抽出されることが可能である場合、ｎＲｅｌａｔｉｖｅＰｒｉｏｒｉｔｙ値は、プロトコルの抽出された値が用いられる必要がある相対的表示を与える。例えば、ＨＴＴＰは、トナーレベルが“高い”か又は“低い”かを示す情報を抽出することができる一方、ＳＮＭＰプロトコルが残りのトナーの割合のレベルを抽出することができる場合、ＳＮＭＰに対するトナーレベルについての優先順位レベルは対応するＨＴＴＰの値より高い。更に、支援データベースは、プロトコル値が０乃至３２，０００の範囲内にあるシステムにおいて優先順位値１０，０００を与える。

図２１及び２２は、支援データべース１０２４にＨＴＴＰ及びＦＴＰ位置に含まれるデータ構造を示し、図２０に関連して上で説明したデータ構造に類似しているデータ構造を含む。

本発明により用いられる代表的なｅｎｕｍタイプは、下で説明するｉｎｆｏＴｙｐｅである（ｅｎｕｍタイプは単なる例示であって、それ故、本発明を限定するように解釈されるべきではない）。

ｉｎｆｏＴｙｐｅ（ｔｙｐｅｄｅｆ ｉｎｔ ｉｎｆｏＴｙｐｅ）
この段落は、ｉｎｆｏＴｙｐｅ（ｉｎｔ）の定義について説明する。０乃至９９の値の範囲はデータタイプに割り当てられる。１００乃至４９９の値の範囲はＤｅｉｖｉｃｅ Ｉｎｆｏｒｍａｔｉｏｎに割り当てられる。５００乃至１９９９の値の範囲は、標準的ＭＩＢのパラメータを含む共通パラメータに割り当てられる。範囲２０００乃至３９９９はリコー社固有情報に割り当てられる。範囲４０００乃至４９９９はＸｅｒｏｘに割り当てられる。範囲５０００乃至５９９９はＬｅｘｍａｒｋに割り当てられる。範囲６０００乃至６９９９はＨＰに割り当てられる、値は次のように定義される。

即ち、ｉｎｆｏｔｙｐｅ｛ｅＮｏｔＤｅｆｉｎｅ＝０，ｅＤｅｖｉｃｅＩｎｆｏｒｍａｔｉｏｎ＝１，ｅＳｔａｔｕｓＩｎｆｏｒｍａｔｉｏｎ＝２，ｅＶｅｎｄｏｒ＝１００，ｅＭｏｄｅｌ，ｅＵｎｉｑｕｅＩＤ，ｅＩＰＡｄｄｒｅｓｓ，ｅＣｏｍｐａｎｙＮａｍｅ，ｅＳｔｒｅｅｔ，ｅＣｉｔｙ，ｅＳｔａｔｅ，ｅＺｉｐＣｏｄｅ，ｅＬｏｃａｔｉｏｎ，ｅＣｏｎｔａｃｔＰｅｒｓｏｎ，ｅＰｈｏｎｅＮｕｍｂｅｒ，ｅＥＭａｉｌＡｄｄｒｅｓｓ，ｅＤａｔｅＴｉｍｅ＝５００，ｅＨｒＤｅｖｉｃｅＥｒｒｏｒｓ，ｅＬｏｗＰａｐｅｒ，ｅＮｏＰａｐｅｒ，ｅＬｏｗＴｏｎｅｒ，ｅＮｏＴｏｎｅｒ，ｅＤｏｏｒＯｐｅｎ，ｅＪａｍｍｅｄ，ｅＯｆｆｌｉｎｅ，ｅＳｅｒｖｉｃｅＲｅｑｕｅｓｔｅｄ，ｅＰｒｔＧｅｎｅｒａｌＣｏｎｆｉｇＣｈａｎｇｅｓ＝６００，ａＰｒｔＬｉｆｅＣｏｎｕｎｔ，ｅＰｒｔＡｌｅｒｔＤｅｓｃ１，ｅＰｒｔＡｌｅｒｔＤｅｓｃ２，ｅＰｒｔＡｌｅｒｔＤｅｓｃ３，ｅＰｒｔＡｌｅｒｔＤｅｓｃ４，ｅＰｒｔＡｌｅｒｔＤｅｓｃ５，ｅＢｌａｃｋ＝７００，ｅＭａｇｅｎｔａ，ｅＣｙａｎ，ｅＹｅｌｌｏｗ，ｅＴｏｎｅｒＣｏｌｌｅｃｔｏｒ＝８００，ｅＢｌａｃｋＤｅｖｅｌｏｐｅｒ＝８１０，ｅＣｏｌｏｒＤｅｖｅｌｏｐｅｒ，ｅＦｕｓｅｒ＝８２０，ｅＤｒｕｍ＝８３０，ｅＴｒａｎｓｆｅｒ＝８４０，ｅＭａｉｎｔｅｎａｎｃｅＫｉｔ＝８５０，ｅＯｉｌＫｉｔ＝８６０，ｅＳｔａｔｉｏｎＩｎｆｏ１＝９０１，ｅＳｔａｔｉｏｎＩｎｆｏ２，ｅＳｔａｔｉｏｎＩｎｆｏ３，ｅＳｔａｔｉｏｎＩｎｆｏ４，ｅＳｔａｔｉｏｎＩｎｆｏ５，ｅＲｉｃｏｈＥｎｇｉｎｅＣｏｕｎｔｅｒＴｏｔａｌ＝２０００，ｅＲｉｃｏｈＥｎｇｉｎｅＣｏｕｎｔｅｒＰｒｉｎｔｅｒ，ｅＲｉｃｏｈＥｎｇｉｎｅＣｏｕｎｔｅｒＦａｘ，ｅＲｉｃｏｈＥｎｇｉｎｅＣｏｕｎｔｅｒＣｏｐｉｅｒ｝、である。

ＥｅｒｒｏｒＣｏｄｅ
次に示すコードは単なる例示であり、更なるコードを示す集合に追加することが可能である。０乃至９９の範囲は残しておく。範囲１００乃至１９９はＳＭＴＰのためのものであり、範囲２００乃至２９９はＰＯＰ３のためのものであり、範囲３００乃至３９９はＳｏｃｋｅｔのためのものであり、範囲４００乃至４９９はＨＴＴＰのためのものであり、範囲５００乃至５９９はＦＴＰのためのものである。他の規定されていない範囲は、必要に応じて、ユーザにより規定されることが可能である。

即ち、ｅｒｕｍ ＥｓｒｏｏｒＣｏｄｅ（ｅＮｏＥｒｒｏｒ＝０，ｅＵｎｋｏｗｎＥｒｒｏｒ＝１，ｅＳｏｍｅＥｒｒｏｒ，ｅＤｏｍｐｌｅｔｅＦａｌｕｅｒ，ｅＳｏｍｅＤｅｖｉｃｅＣｒｅａｔｉｏｎＥｒｒｏｒ＝２０，ｅＤｅｖｉｃｅＣｒｅａｔｉｏｎＥｒｒｏｒ，ｅＮｏＤｅｖｉｃｅＣｒｅａｔｅｄ，ｅＯｂｔａｉｎＣｏｎｆｉｇＥｒｒｏｒ，ｅＳａｖｅＳｔａｔｕｓＥｒｒｏｒ，ｅＯｂｔａｉｎＵｎｉｑｕｅＩＤＥｒｒｏｒ，ｅＯｂｔａｉｎＳｔａｔｕｓＥｒｒｏｒ，ｅＳｔａｒｔＳｅｎｄＥｒｒｏｒ，ｅＳｏｍｅＤａｔａ ＳｅｎｄＥｒｒｏｒ，ｅＣｏｍｐｌｅｔｅＤａｔａＳｅｎｄＦａｌｕｒｅ，ｅＥｎｄＳｅｎｄＥｒｒｏｒ，ｅＳｅｎｄＨｅｌｏＣｏｍｍｎａｎｄＦａｉｌｅｄ＝１００，ｅＳｅｎｄＭａｉｌＣｏｍｍｎａｄＦａｉｌｅｄ，ｅＳｅｎｄ ＲｃｐｔＣｏｍｍａｎｄＦａｉｌｅｄ，ｅＳｅｎｄＤａｔａＣｏｍｍａｎｄ Ｆａｉｌｅｄ，ｅＳｅｎｄＤａｔａＦａｉｌｅｄ，ｅＳｅｎｄＱｕｉｔＣｏｍｍａｎｄ Ｆａｉｌｅｄ，ｅＳｅｎｄＵｓｅｒＣｏｍｍａｎｄＦａｉｌｅｄ＝２００，ｅＳｅｎｄＰａｓｓＣｏｍｍａｎｄＦａｉｌｅｄ，ｅＳｅｎｄＱｕｉｔ Ｐｏｐ３ＣｏｍｍａｎｄＦａｉｌｅｄ，ｅＣｒｅａｔｅＳｏｃｋｅｔＦａｉｌｅｄ＝３００，ｅＣｏｎｎｅｃｔＳｏｃｋｅｔＦａｉｌｅｄ，ｅＢａｄＲｅｑｕｅｓｔ＝４００，ｅＵｎａｕｔｈｏｒｉｚｅｄ，ｅＰａｙｍａｎｔＲｅｑｕｅｓｔｅｄ，ｅＦｏｒｂｉｄｄｅｎ，ｅＮｏｔＦｏｕｎｄ，ｅＭｅｔｈｏｄｎｏｔＡｌｌｏｗｅｄ，ｅＮＯｔＡｃｃｅｐｔａｂｌｅ，ｅＰｒｏｘｙＡｕｔｈｅｎｔｉｃａｔｉｏｎＲｅｑｕｅｓｔｅｄ，ｅＲｅｑｕｅｓｔＴｉｍｅＯｕｔ，ｅＣｏｎｆｌｉｃｔ，ｅＧｏｎｅ，ｅＬｅｎｇｔｈＲｅｑｕｅｓｔｅｄ，ｅＰｒｅｃｏｎｄｉｔｉｏｎＦａｉｌｅｄ，ｅＲｅｑｕｅｓｔＥｎｔｉｔｙＴｏｏＬａｒｇｅ，ｅＲｅｑｕｅｓｔＵＲＩＴｏｏｌａｒｇｅ，ｅＩｎｔａｒｎａｌＳｅｒｖｅｒＥｒｒｏｒ＝４５０，ｗＮｏｔＩｍｐｌｅｍｅｎｔｅｄ，ｅＢａｄＧａｔｅｗａｙ，ｅＳｅｒｖｉｃｅＵｎａｖａｉｌａｂｌｅ，ｅＧａｔｅｗａｙＴｉｍｅＯｕｔ，ｅＨＴＴＰＶｅｒｓｉｏｎＮｏｔＳｕｐｐｏｒｔｅｄ，ｅＭｕｌｔｉｐｌｅＣｈｏｉｃｅｓ＝４８０，ｅＭｏｖｅｄＰｅｒｍａｎｅｎｔｌｙ，ｅＦｏｕｎｄ，ｅＳｅｅＯｔｈｅｒ，ｅｎｏｔＭｏｄｉｆｉｅｄ，ｅＵｓｅＰｒｏｘｙ，ｅＴｅｍｐｏｒａｒｙＲｉｄｉｒｅｃｔ）、である。

装置ＯＤＢＣモジュールにおける抽象クラス
図１６は、本発明に従った装置ＯＤＢＣモジュールクラス構造について示しており、ＣＡｂｓＰｒｏｔｏｃｏｌＰａｒａｍｅｔｅｒｓクラスが装置ＯＤＢＣモジュールにおいてどのように用いられるかを示している。ＣＡｂｓＰｒｏｔｏｃｏｌＰａｒａｍｅｔｅｒｓクラスは、特定の通信プロトコルを用いて、被モニタリング装置にアクセスするための情報を得るために及びモニタデータベース１０１４と接続するようにデザインされている。ＣＡｂｓＰｒｏｔｏｃｏｌＰａｒａｍｅｔｅｒｓクラスは、次のようなプロトコルに依存しない２つの仮想関数を有する。
（１）ｓｔｄ：：ｓｔｒｉｎｇ ｏｂｔａｉｎＰｒｏｔｏｃｏｌＮａｍｅ（ｖｏｉｄ）及び、
（２）ｂｏｏｌ ｏｂｔａｉｎＰａｒａｍｅｔｅｒＶｅｃｔｏｒ（ｓｔｄ：：ｖｅｃｔｏｒ＜ＳＰａｒａｍｅｔｅｒ＞＆ｏｕｔ＿ＰａｒａｍｅｔｅｒＶｅｃｔｏｒ，ｃｏｎｓｔ ｓｔｄ：：ｓｔｒｉｎｇ ｉｎ＿ｓＩＰ）
ＨＷａｃｃｅｓｓモジュールにおける抽象クラス
図２３はＨＷａｃｃｅｓｓパッケージのためのパッケージを示す図である。このパッケージは、種々のネットワークプロトコル（例えば、ＳＮＭＰ、ＨＴＴＰ及びＦＴＰ）
を用いてネットワーク装置に関する情報を得、モニタリングされるネットワーク装置を識別するために責任を負う。このパッケージは、ＨＴＴＰ２３０２、ＳＮＭＰ２３０４及びＦＴＰ２３０６のパッケージ、並びに、ＣＨＷａｃｃｅｓｓ２３００，ＣＡｂｓＰｒｏｔｏｃｏｌ２３０８及びＣＲｅｃｏｒｄＳｅｔ２３１０のクラスを含む。パッケージＨＴＴＰ２３０２、ＳＮＭＰ２３０４及びＦＴＰ２３０６は、それらから情報を得るためにネットワーク装置にアクセスするためのネットワークプロトコルを実行する。例えば、ＨＴＴＰパッケージ２３０２は、ウェブページから情報を得るためにネットワーク装置のウェブページにアクセスするためのＨＴＴＰプロトコルを実行する。クラスＣＨＷａｃｃｅｓｓ２３００は、ネットワーク装置から必要な情報を得るためにプロトコルパッケージ全てを管理する。クラスＣＡｂｓＰｒｏｔｏｃｏｌ２３０８は、いずれかのプロトコルを表す抽象クラスである。このクラスは、ＣＨＷａｃｃｅｓｓ２３００とプロトコルパッケージとの間のインタフェースを提供する。クラスＣＡｂｓＰｒｏｔｏｃｏｌ２３０８は、全てのプロトコル２３０８が必要な情報をＣＨＷａｃｃｅｓｓ２３００に提供するＣＨＷａｃｃｅｓｓ２３００に、図２３に示すような共通機能の集合を提供する。後で図に示すようなＣＡｂｓＰｒｏｔｏｃｏｌ２３０８からもたらされるクラスは、適切なプロトコルのための機能の各々に対して方法を提供する。クラスＣＲｅｃｏｒｄＳｅｔ２３１０は、どのネットワーク装置のベンダ及びモデルが支援されるか及びそれらのネットワーク装置からどのような情報を得るべきかについての情報を得るためにデータベースへの各々のプロトコルパッケージアクセスを提供するＭｉｃｒｏｓｏｆｔ Ｆｏｕｎｄａｔｉｏｎ Ｃｌａｓｓのクラスである。

図２４は、ＳＮＭＰパッケージ２３０４のためのパッケージを示す図である。このパッケージは、ＳＮＭＰプロトコルによりネットワーク装置から得られる情報及びＳＮＭＰプロトコルにより支援されるネットワーク装置のベンダ及びモデルを決定するために、並びに、ネットワーク装置から情報を得るためにＳＮＭＰプロトコルによりネットワーク装置にアクセスするために責任を負う。このパッケージは、パッケージＳＮＭＰａｃｃｅｓｓ２４０４及びＳＮＭＰＯＤＢＣ２４０６とクラスＣＳＮＭＰＰｒｏｔｏｃｏｌ２４０１とを含み、図２３に示すようなクラスＣＡｂｓＰｒｏｔｏｃｏｌ２４００とＣＲｅｃｏｒｄＳｅｔ２４０８とを用いる。ＳＮＭＰａｃｃｅｓｓ２４０４は、ネットワーク装置にアクセスするため及びネットワーク装置から情報を得るためにＳＮＭＰプロトコルを実行する。ＳＮＭＰＯＤＢＣパッケージ２４０６は、ＳＮＭＰプロトコルにより支援された
ネットワーク装置のネットワークのベンダ及びモデルに関してデータベースからの情報にアクセスし、それを得、その情報はＳＮＭＰプロトコルによりネットワーク装置から得られる。ＣＳＮＭＰＰｒｏｔｏｃｏｌクラス２４０２はＣＡｂｓＰｒｏｔｏｃｏｌクラス２４００からもたらされるクラスである。ＣＳＮＭＰＰｒｏｔｏｃｏｌ２４０２は、ＳＮＭＰプロトコルを用いて、ネットワーク装置から必要な情報を得る。ＣＳＮＭＰＰｒｏｔｏｃｏｌ２４０２は、図２３に示すようなＣＡｂｓＰｒｏｔｏｃｏｌ２４００のインタフェース機能全てに対する方法を提供する。図２４は又、ＣＳＮＭＰＰｒｏｔｏｃｏｌ２４０２が用いるパッケージＳＮＭＰａｃｃｅｓｓ２４０４とＳＮＭＰＯＤＢＣ２４０６との機能を示している。ＳＮＭＰＯＤＢＣパッケージ２４０６は、データベースから情報を得るためにクラスＣＲｅｃｏｒｄＳｅｔ２４０８を用いる。

図２５は、ＨＴＴＰパッケージ２３０２のためのパッケージを示す図である。このパッケージは、ＨＴＴＰプロトコルによりネットワーク装置から得られる情報及びＨＴＴＰプロトコルにより支援されるネットワーク装置のベンダ及びモデルと決定するために、並びに、ネットワーク装置から情報を得るためにＨＴＴＰプロトコルによりネットワーク装置にアクセスするために、責任を負う。このパッケージは、図２３に示すように、パッケージＨＴＴＰａｃｃｅｓｓ２５０４及びＨＴＴＰＯＤＢＣ２５０６と、クラスＣＨＴＴＰＰｒｏｔｏｃｏｌ２５０２とを含み、クラスＣＡｂｓＰｒｏｔｏｃｏｌ２５００及びＣＲｅｃｏｒｄＳｅｔ２５０８を用いる。ＨＴＴＰａｃｃｅｓｓパッケージ２５０４は、ネットワーク装置にアクセスするために及びネットワーク装置から情報を得るためにＨＴＴＰプロトコルを実行する。ＨＴＴＰＯＤＢＣパッケージ２５０６は、ＨＴＴＰプロトコルによりネットワーク装置から得られる情報と、ＨＴＴＰプロトコルにより支援されるネットワーク装置のベンダ及びモデルに関するデータベースからの情報にアクセスし、それらを得る。ＣＨＴＴＰＰｒｏｔｏｃｏｌクラス２５０２はＣＡｂｓＰｒｏｔｏｃｏｌクラス２５００からもたらされるクラスである。ＣＨＴＴＰＰｒｏｔｏｃｏｌ２５０２は、ＨＴＴＰプロトコルを用いて、ネットワーク装置から必要な情報を得る。ＣＨＴＴＰＰｒｏｔｏｃｏｌ２５０２は、図２３に示すようなＣＡｂｓＰｒｏｔｏｃｏｌ２５００のインタフェース機能全てに対する方法を提供する。図２５は又、ＣＨＴＴＰＰｒｏｔｏｃｏｌ２５０２が用いるパッケージＨＴＴＰａｃｃｅｓｓ２５０４とＨＴＴＰＯＤＢＣ２５０６との機能を示している。ＨＴＴＰＯＤＢＣパッケージ２５０６は、データベースから情報を得るためにクラスＣＲｅｃｏｒｄＳｅｔ２５０８を用いる。

図２５は、ＦＴＰパッケージ２３０６のためのパッケージを示す図である。このパッケージは、ＦＴＰプロトコルによりネットワーク装置から得られる情報及びＦＴＰプロトコルにより支援されるネットワーク装置のベンダ及びモデルと決定するために、並びに、ネットワーク装置から情報を得るためにＦＴＰプロトコルによりネットワーク装置にアクセスするために、責任を負う。このパッケージは、図２３に示すように、パッケージＦＴＰａｃｃｅｓｓ２６０４及びＦＴＰＯＤＢＣ２６０６と、クラスＣＦＴＰＰｒｏｔｏｃｏｌ２６０２とを含み、クラスＣＡｂｓＰｒｏｔｏｃｏｌ２６００及びＣＲｅｃｏｒｄＳｅｔ２６０８を用いる。ＦＴＰａｃｃｅｓｓパッケージ２６０４は、ネットワーク装置にアクセスするために及びネットワーク装置から情報を得るためにＦＴＰプロトコルを実行する。ＦＴＰＯＤＢＣパッケージ２６０６は、ＦＴＰプロトコルによりネットワーク装置から得られる情報と、ＦＴＰプロトコルにより支援されるネットワーク装置のベンダ及びモデルに関するデータベースからの情報にアクセスし、それらを得る。ＣＦＴＰＰｒｏｔｏｃｏｌクラス２６０２はＣＡｂｓＰｒｏｔｏｃｏｌクラス２６００からもたらされるクラスである。ＣＦＴＰＰｒｏｔｏｃｏｌ２６０２は、ＦＴＰプロトコルを用いて、ネットワーク装置から必要な情報を得る。ＣＦＴＰＰｒｏｔｏｃｏｌ２６０２は、図２３に示すようなＣＡｂｓＰｒｏｔｏｃｏｌ２６００のインタフェース機能全てに対する方法を提供する。図２６は又、ＣＦＴＰＰｒｏｔｏｃｏｌ２６０２が用いるパッケージＦＴＰａｃｃｅｓｓ２６０４とＦＴＰＯＤＢＣ２６０６との機能を示している。ＦＴＰＯＤＢＣパッケージ２６０６は、データベースから情報を得るためにクラスＣＲｅｃｏｒｄＳｅｔ２６０８を用いる。

図２３乃至２６に示すような、各々のプロトコルパッケージ、ＨＴＴＰ２３０２、ＳＮＭＰ２３０４及びＦＴＰ２３０６は、装置から情報を得るためにネットワーク装置へのアクセスを管理するクラスを含む。そのクラスは、ネットワーク装置からの情報にアクセスするためにプロトコルを実行する方法を備える抽象クラスＣＡｂｓＰｒｏｔｏｏｃｏｌ２３０８からもたらされる。抽象クラスはインタフェース機能のみを提供するが、いずれのプロセスを実行することはない。その抽象クラスから導き出されたクラスはインタフェース機能のためのプロセスを実行する方法を提供する。異なる導き出されたクラスがインタフェース機能のプロセスを異なるように実行することができるように、抽象クラスについて、多くの導き出されたクラスが存在することが可能である。例えば、ＣＡｂｓＰｒｏｔｏｃｏｌのインタフェース機能はｏｂｔａｉｎＳｔａｔｕｓ（）である。導き出されたクラスＣＳＮＭＰＰｒｏｔｏｃｏｌ２４０２ｈａ，ＳＮＭＰを用いて練っておワーク装置の状態情報を得るための方法を提供する機能ｏｂｔａｉｎＳｔａｔｕｓ（）を含む一方、導き出されたクラスＣＨＴＴＰＰｒｏｔｏｃｏｌ２５０２は、ＨＴＴＰを用いてネットワーク装置の状態情報を得るための方法を提供する機能ｏｂｔａｉｎＳｔａｔｕｓ（）を含む。ＨＷａｃｃｅｓｓパッケージのデザインから、新しいプロトコルを用いてネットワーク装置にアクセスするために新しいパッケージを管理するＣＡｂｓＰｒｏｔｏｃｏｌの導き出されたクラスを含む新しいパッケージを加えることにより、新しいプロトコルはそのシステムに加えられることができる。抽象クラスは、システムの将来の拡張を可能にする。

図２７Ａ乃至２７Ｄは、ネットワーク装置から情報を得るように及びアクセスするようにプロトコル全てを維持するために図２３のＨＷａｃｃｅｓｓパッケージに用いられるデータ構造を示している。図２７Ａにおいて、データ構造はＣＡｂｓＰｒｏｔｏｃｏｌ２３０８に対するポインタのベクトル５００である。クラスＣＨＷａｃｃｅｓｓ２３００はこのデータ構造を含み、用いる。ベクトル５００がＣＡｂｓＰｒｏｔｏｃｏｌ２３０８から導き出されたクラスにポインタを含むにも拘らず、ＣＨＷａｃｃｅｓｓ２３００は、ＣＡｂｓＰｒｏｔｏｃｏｌ２３０８にポインタを含むようにベクトルをみて、仮想機能呼び出し機構によりＣＡｂｓＰｒｏｔｏｃｏｌ２３０８のインタフェース機能を呼び出す。実際には、ＣＨＷａｃｃｅｓｓ２３００は、ＣＡｂｓＰｒｏｔｏｃｏｌ２３０８の導き出されたクラスのインタフェース機能を呼び出す。例えば、ベクトルの第１エントリにおけるＣＡｂｓＰｒｏｔｏｃｏｌ５０２に対するポインタは導き出されたクラスＣＳＮＭＰＰｒｏｔｏｃｏｌ２４０２に対するポインタであることが可能であり、ベクトルの第２エントリにおけるＣＡｂｓＰｒｏｔｏｃｏｌ５０４に対するポインタは導き出されたクラスＣＨＴＴＰＰｒｏｔｏｃｏｌ２５０２に対するポインタであることが可能であり、ベクトルの第３エントリにおけるＣＡｂｓＰｒｏｔｏｃｏｌ５０６に対するポインタは導き出されたクラスＣＦＴＰＰｒｏｔｏｃｏｌ２６０２に対するポインタであることが可能である。従って、ＣＨＷａｃｃｅｓｓ２３００がベクトルにおいてＣＡｂｓＰｒｏｔｏｃｏｌ２３０８のインタフェース機能を呼び出すとき、それは、実際には、ＣＳＮＭＰＰｒｏｔｏｃｏｌ２４０２、ＣＨＴＴＰＰｒｏｔｏｃｏｌ２５０２及びＣＦＴＰＰｒｏｔｏｃｏｌ２６０２のインタフェース機能を呼び出す。ベクトルにおける抽象クラスＣＡｂｓＰｒｏｔｏｃｏｌ２３０８の使用は、いずれのプロトコルがネットワーク装置からの情報にアクセスし及びその情報を得るために用いられるようにする。抽象クラスＣＡｂｓＰｒｏｔｏｃｏｌ２３０８は、どのプロトコルが用いられているかについての詳細を隠す。

図２７Ｂは、それらから状態情報を得るために用いられる情報とＳＮＭＰによりモニタリングされるネットワーク装置のベンダ及びモデルに関する情報とを維持するためにＣＳＮＭＰＰｒｏｔｏｃｏｌにより用いられるデータ構造を示している。そのデータ構造はマップ５１０である。マップ５１０に対するキーは、ネットワーク装置のベンダ名を表すストリング５１２である。マップ５１０に対する値は他のマップ５１４である。マップ５１４に対するキーはネットワーク装置のモデル名を表すストリング５１６である。マップ５１４の値は対のベクトル５１８である。それらの対は構造ＳＯＩＤｉｎｆｏＴｙｐｅと整数とを含む。構造ＳＯＩＤｉｎｆｏＴｙｐｅは、ＳＮＭＰを用いたネットワーク装置から単一の状態情報を得るために用いられる情報を含む。それ故、対のベクトル５１８は、固有のベンダ及びモデルに対してネットワーク装置についての状態情報全てを得るための情報を含む。マップ５１０は、図２８において説明するプロセスを用いて、情報と共に初期化される。マップ５１０は、ベンダについてのストリング５１２及びモデルについてのストリング５１６に対するサンプルエントリを示している。

図２７Ｃは、それらから状態情報を得るために用いられる情報とＨＴＴＰによりモニタリングされるネットワーク装置のベンダ及びモデルに関する情報とを維持するためにＣＨＴＴＰＰｒｏｔｏｃｏｌにより用いられるデータ構造を示している。そのデータ構造はマップ５２０である。マップ５２０に対するキーは、ネットワーク装置のベンダ名を表すストリング５２２である。マップ５２０に対する値は他のマップ５２４である。マップ５２４に対するキーはネットワーク装置のモデル名を表すストリング５２６である。マップ５２４の値はＳＷｅｂＰａｇｅＩｎｆｏのベクトル５２８である。構造ＳＷｅｂＰａｇｅＩｎｆｏは、ＨＴＴＰを用いてネットワーク装置のウェブページから状態情報全てを得るために用いられる情報を含む。それ故、ＳＷｅｂＰａｇｅＩｎｆｏのベクトル５２８は、ウェブページの全てから固有のベンダ及びモデルに対してネットワーク装置についての状態情報全てを得るための情報を含む。マップ５２０は、図２８において説明するプロセスを用いて、情報と共に初期化される。マップ５２０は、ベンダについてのストリング５２２及びモデルについてのストリング５２６に対するサンプルエントリを示している。

図２７Ｄは、それらから状態情報を得るために用いられる情報とＦＴＰによりモニタリングされるネットワーク装置のベンダ及びモデルに関する情報とを維持するためにＣＦＴＰＰｒｏｔｏｃｏｌにより用いられるデータ構造を示している。そのデータ構造はマップ５３０である。マップ５３０に対するキーは、ネットワーク装置のベンダ名を表すストリング５３２である。マップ５３０に対する値は他のマップ５３４である。マップ５３４に対するキーはネットワーク装置のモデル名を表すストリング５３６である。マップ５３４の値はＳＤｉｒＦｉｌｅＳｔａｔｕｓＩｎｆｏのベクトル５３８である。構造ＳＤｉｒＦｉｌｅＳｔａｔｕｓＩｎｆｏは、ＦＴＰを用いてネットワーク装置のＦＴＰファイルから状態情報全てを得るために用いられる情報を含む。それ故、ＳＤｉｒＦｉｌｅＳｔａｔｕｓＩｎｆｏのベクトル５３８は、ＦＴＰファイルの全てから固有のベンダ及びモデルに対してネットワーク装置についての状態情報全てを得るために用いられる情報を含む。マップ５３０は、図２８において説明するプロセスを用いて、情報と共に初期化される。マップ５３０は、ベンダについてのストリング５３２及びモデルについてのストリング５３６に対するサンプルエントリを示している。

図２８は、システムによりモニタリングされるネットワーク装置のベクトルに関する情報と共にプロトコルオブジェクト全てを初期化するプロセスを示すフローチャートを示している。類似するプロセスは、システムによりモニタリングされるネットワーク装置のモデルに関する情報と共にプロトコルオブジェクト全てを初期化するために用いられる。モニタリングされる所定のネットワーク装置に対して、ネットワーク装置のベンダ及びモデルは、どのような情報がネットワーク装置から得られる必要があるかを判定するために、知られる必要がある。ネットワーク装置からの情報にアクセスするため及びその情報を得るために用いられる各々のプロトコルオブジェクトは、どのようにネットワーク装置から情報を得るか及びどのような情報を得るかについて判定するために、ベンダ及びモデルを知る必要がある。初期化を必要とするプロトコルオブジェクトは、ＣＳＮＭＰＰｒｏｔｏｃｏｌ、ＣＨＴＴＰｒｏｔｏｃｏｌ及びＣＦＴＰＰｒｏｔｏｃｏｌであるＣＡｂｓＰｒｏｔｏｃｏｌ２３０８から導き出されたクラスに対応するプロトコルオブジェクトである。プロトコルオブジェクトの初期化は、プロトコルに対応する図２７Ｂ、２７Ｃ及び２７Ｄに示しているデータ構造への付加情報を含む。システムのデザインは、図２７Ｂ、２７Ｃ及び２７Ｄのデータ構造に付加された情報はデータベースからもたらされるが、それらはテキストファイル又はスプレッドシートのような他の外部ソースからもたらされることが可能である。図２７Ａに示すＣＡｂｓＰｒｏｔｏｃｏｌ２３０８に対するポインタのベクトルはプロトコルオブジェクト全てを初期化するために用いられる。そのフローチャートのプロセスは、そのベクトルにより２回進められる。１回目は、そのベクトルにより進められ、プロトコルオブジェクトはネットワーク装置のベクトルを見つけるために用いられる。ベンダ名がプロトコルオブジェクトの１つから得られる場合、プロトコルオブジェクト全ては、ベクトルが２回目を進められるとき、ベンダ名と共に初期化される。段階６０２において、プロトコルオブジェクトはＣＡｂｓＰｒｏｔｏｃｏｌに対してポインタのベクトルから得られる。プロトコルオブジェクトは、ネットワーク装置（例えば、ＳＮＭＰ、ＨＴＴＰ及びＦＴＰ）にアクセスするためにプロセスの１つに対応する。段階６０４において、ベクトルから得ることができるいずれの更なるプロトコルオブジェクトがあるかどうかを判定するためにチェックがなされる。このチェックは、ベクトルの終点が達したかどうかを判定することによりなされる。更なるプロトコルオブジェクトが得られない場合、システムはネットワーク装置のベンダ名を得ることができない。ネットワーク装置のプロトコルオブジェクトの初期化及びベンダ名を得ることができなかったプロトコルオブジェクト全ては段階６０６で終了する。ベクトルから得られるプロトコルオブジェクトある場合、そのプロトコルオブジェクトは、段階６０８においてネットワーク装置のベンダ名を得るために用いられる。段階６１０において、プロトコルオブジェクトがネットワーク装置のベンダ名を得ることができるかどうかを判定するためにチェックがなされる。プロトコルオブジェクトは、ネットワーク装置のベンダを判定するために用いられるデータベースから情報を得る。ベンダ名がプロトコルオブジェクトにより得られない場合、プロセスは、段階６０２に戻ることにより、ベクトルにおいて他のプロトコルオブジェクトを用いるベンダ名を得るように試みる。ベンダ名がプロトコルオブジェクトから得られる場合、プロセスは、段階６１２においてそのベンダ名と共にプロトコルオブジェクトを初期する。プロトコルオブジェクトは、得られたベンダ名のネットワーク装置から状態情報を得る方法についての情報と共に初期化される。図２７Ｂ、２７Ｃ及び２７Ｄで示されているデータ構造に情報が付加される。段階６１４において、プロトコルオブジェクトはＣＡｂｓＰｒｏｔｏｃｏｌに対してポインタのベクトルから得られる。段階６１６において、ベクトルから得ることができるいずれの更なるプロトコルオブジェクトがあるかどうかを判定するためにチェックがなされる。更なるプロトコルオブジェクトが得られない場合、プロトコルオブジェクト全てはベンダ名を共に初期化され、プロトコルオブジェクト全ての初期化は段階６０６において終了する。プロトコルオブジェクト全てはベンダに関する情報を更新した。ベクトルから得られるプロトコルオブジェクトがない場合、段階６１８においてベンダ名とともにプロトコルオブジェクトを初期化する。丁度段階６１２のように、プロトコルオブジェクトは、得られたベンダ名のネットワークオブジェクトから状態情報を得る方法に関する情報と共に初期化される。ベンダ名と共にプロトコルオブジェクトを初期化した後、プロセスは、段階６１４に戻ることによりベンダ名と共に他のプロトコルオブジェクトを初期化する。

図２８の段階６０８において、プロトコルオブジェクトはネットワーク装置のベンダ名を得る。ＳＮＭＰ、ＨＴＴＰ及びＦＴＰプロトコルオブジェクトはベンダ名を得るためにネットワーク装置にアクセスすることができる。ベンダ名が見つけられることに関する情報はデータベースから得られる。プロトコルにより支援されるネットワーク装置のベクトルに関する情報と共に、データベースはネットワーク装置のベンダ名を位置づけるために情報を提供する。ＳＮＭＰに対して、ネットワーク装置のＭＩＢにおいて企業オブジェクト識別子を位置付けるために用いられるオブジェクト識別子及びベンダ名に関連する企業オブジェクト識別子に関する情報は、ベンダ名を得るためにＳＮＭＰプロトコルオブジェクトにより用いられる。ＨＴＴＰに対して、ウェブページにおける位置とウェブページに関する情報は、ベンダ名を得るためにＨＴＴＰプロトコルオブジェクトにより用いられる。ＦＴＰに対して、ＦＴＰファイルにおける位置とＦＴＰファイルに関する情報は、ベンダ名を得るためにプロトコルオブジェクトにより用いられる。

図２９Ａ乃至２９Ｄは、異なるプロトコルに対する固有のベンダ及びモデルのネットワーク装置の状態情報を得るために用いられる異なるデータ構造を示している。異なるプロトコルは同じ状態情報を得るために用いられることが可能である。しかしながら、１つのプロトコルにより得られた状態情報は、更なる情報を提供するプロトコルから得られる状態情報が用いられる必要があるように、他の情報以上の情報を提供することが可能である。例えば、プリンタカートリッジのトナーレベルは、ＳＮＭＰ及びＨＴＴＰを用いて、ネットワークプリンタから得られる。ＳＮＭＰにより得られたトナーレベルについての状態情報は“ＦＵＬＬ”、“ＯＫ”
又は“ＥＭＰＴＹ”であることが可能である一方、ＨＴＴＰにより得られる同じ状態情報は、残っているトナーの割合であることが可能である。個の例においては、ＨＴＴＰを用いて得られる状態情報は、ＨＴＴＰにより得られる状態情報が用いられる必要があるように、更に報知性が高いものとなっている。図２９Ａ乃至２９Ｄのデータ構造は、最も報知性の高い状態情報が得られるように、構成される。図２９Ａは、ＳＮＭＰプロトコルを用いて、固有のベンダ及びモデルのネットワーック装置に対する状態情報を得るために用いられるデータ構造を示している。そのデータ構造は、対が構造ＳＯＩＤｉｎｆｏＴｙｐｅ７０６及び整数から成る対（例えば、７０２及び７０４）のベクトル７００である。構造ＳＯＩＤｉｎｆｏＴｙｐｅ７０６は、ＳＮＭＰを用いて、ネットワーク装置から固有の状態情報を得るために用いられる情報を含む。ＳＯＩＤｉｎｆｏＴｙｐｅ７０６の構造については図２９Ａに示している。その対の整数は状態情報の優先順位又は重みを決定する。その整数の値がより大きい程、より報知性が高いため、得られた状態情報はより保持される傾向にある。その整数の値がより小さい程、他のプロトコルから得られた同じ状態情報が保持される傾向にある。ＣＳＮＭＰＰｒｏｔｏｃｏｌ２４０２は、どのような状態情報をネットワーク装置から得るべきかを決定するためにベクトル７００を用いる。ベクトル７００に置かれた情報は、固有のベンダ及びモデルに対して、図２７Ｂにおけるデータ構造から得られる。

図２９Ｂは、ＨＴＴＰプロトコルを用いて、固有のベンダ及びモデルのネットワーク装置についての状態情報を得るために用いられるデータ構造を示している。そのデータ構造は、対が構造ＳＫｅｙＶａｌｕｅＩｎｆｏ７１４及び整数から成る対（例えば、７１０及び７１２）のベクトル７０８である。構造ＳＫｅｙＶａｌｕｅＩｎｆｏ７１４は、ＨＴＴＰを用いて、ネットワーク装置のウェブページから固有の状態情報を得るために用いられる情報を含む。ＳＫｅｙＶａｌｕｅＩｎｆｏ７１４の構造については図２９Ｂに示している。そのような対における整数は状態情報の優先順位又は重みを決定する。ＣＨＴＴＰＰｒｏｔｏｃｏｌ２５０２は、どのような状態情報をネットワーク装置から得るべきかを決定するためにベクトル７０８を用いる。ベクトル７０８に置かれた情報は、固有のベンダ及びモデルについて図２７Ｃにおけるデータ構造から得られる。

図２９Ｃは、ＦＴＰプロトコルを用いて、固有のベンダ及びモデルのネットワーク装置についての状態情報を得るために用いられるデータ構造を示している。そのデータ構造は、対が構造ＳＫｅｙＩｎｆｏＴｙｐｅ７２２及び整数から成る対（例えば、７１８及び７２０）のベクトル７１６である。構造ＳＫｅｙＩｎｆｏＴｙｐｅ７２２は、ＦＴＰを用いて、ＦＴＰファイルから固有の状態情報を得るために用いられる情報を含む。ＳＫｅｙＩｎｆｏｔｙｐｅ７２２の構造については図２９Ｃに示している。そのような対における整数は状態情報の優先順位又は重みを決定する。ＣＦＴＰＰｒｏｔｏｃｏｌ２６０２は、どのような状態情報をネットワーク装置から得るべきかを決定するためにベクトル７１６を用いる。ベクトル７１６に置かれた情報は、固有のベンダ及びモデルについて図２７Ｄにおけるデータ構造から得られる。

図２９Ｄは、種々のプロトコルにより得られた状態情報を維持するために用いられるデータ構造を示している。それは、どのプロトコルが状態情報を得るために用いられたかに関する情報を維持しない。そのデータ構造はマップ７２４である。マップ７２４に対するキー７２６はｉｎｆｏＴｙｐｅである。ｉｎｆｏＴｙｐｅは情報のタイプを表す数である。マップ７２４に対する値７２８は対である。その対はストリング及び整数から成る。その対におけるストリングは、ｉｎｆｏＴｙｐｅに対応するネットワーク装置から得られる状態情報である。その対における整数は、プロトコルから得られる状態情報の優先順位又は重みである。例として、プリンタカートリッジにおける黒色トナーのレベルを表すことが可能である７００のｉｎｆｏＴｙｐｅに対して、そのような対はすとリング“７５％”及び整数１００００を有することが可能である。ストリング“７５％”は、トナーの７５％がカートリッジに残っていること、及び整数１００００は状態情報の優先順位又は重みであることを表す。ＣＳＮＭＰＰｒｏｔｏｃｏｌ２４０２，ＣＨＴＴＰＰｒｏｔｏｃｏｌ２５０２及びＣＦＴＰＰｒｏｔｏｃｏｌ２６０２は、マップ７２４に対してネットワーク装置から得られる状態情報を付加する。

図３０は、図２７Ｄ、２９Ｃ及び２９Ｄのデータ構造がＦＴＰプロトコルを用いてネットワーク装置から状態情報を得るためにどのように用いられるかについての例を示している。サンプルデータを含むマップ８００は図２７Ｄに示すようなデータ構造に対応する。マップ８００におけるサンプルデータは、ＦＴＰを用いて、モデルＡｆｉｃｉｏ１２０とベンダＲｉｃｏｈに対するネットワーク装置についての状態情報にアクセスするために情報を提供する。ベクトルにおける各々の構造、即ち、ＳＤｉｒＦｉｌｅＳｔａｔｕｓＩｎｆｏ１、ＳＤｉｒＦｉｌｅＳｔａｔｕｓＩｎｆｏ２及びＳＤｉｒＦｉｌｅＳｔａｔｕｓＩｎｆｏ３は、ネットワーク装置におけるＦＴＰファイルからの状態情報にアクセスするために情報を提供する。ＳＤｉｒＦｉｌｅＳｔａｔｕｓＩｎｆｏ１８０２は、ｄｉｒｅｃｔｏｒｙ／ｐｕｂにおいてＦＴＰファイルｓｔａｔｕｓ．ｔｘｔからネットワーク装置からの状態情報にアクセスするための情報を含む。ＳｋｅｙＩｎｆｏＴｙｐｅ及び整数の対のベクトルを用いて、ＦＴＰファイルから５つの状態情報の値を得ることができる。ベクトルの対における各々のＳｋｅｙＩｎｆｏＴｙｐｅは、図３０に示すようなｉｎｆｏＴｙｐｅに対応する異なる状態情報に対応する。マップ８０４は、図２９Ｄに示すようなデータ構造に対応するサンプルデータを含む。マップ８０４は、他のプロトコルにより前に得られた状態情報を含む。マップ８０４は、ｉｎｆｏＴｙｐｅ６００、６１０及び７００に対応する３つの状態情報を含む。ｉｎｆｏＴｙｐｅ６００についての状態情報は、５００の重みをもつ場合“ペーパーが少ない”である。ｉｎｆｏＴｙｐｅ６１０についての状態情報は、１００００の重みをもつ場合“２４３２１”である。

ｉｎｆｏＴｙｐｅ７０についての状態情報は、２５００の重みを持つ場合“良好”である。ＦＴＰプロトコルを用いてどの状態情報が得られるかを決定するために、ベクトル８０６が得られるべき状態情報を得るために生成される。ベクトル８０６に付加されるべき情報は、マップ８００における情報（特に、構造ＳＤｉｒＦｉｌｅＳｔａｔｕｓＩｎｆｏ１８０２における対のベクトル）とマップ８０４における状態情報とにより決定される。マップ８００から得られる状態情報がマップ８０４において未だ得られていない場合、プロセスは、ベクトル８０６における状態情報を得るために必要な情報を付加する。マップ８００から得られる状態情報がマップ８０４において既に得られている場合、ＦＴＰにより得られる状態情報が重みを比較することによりマップ８０４における状態情報より法知性が高いかどうかをチェックする。ＦＴＰにより得られた状態情報の重みがマップ８０４において既に得られた状態情報より重みが大きい場合にのみ、状態情報を得るために情報をベクトル８０６に付加する。ＳＤｉｒＦｉｌｅＳｔａｔｕｓＩｎｆｏ１ ８０２に対応するＦＴＰにより得られる状態情報は、ｆｉｌｅＴｙｐｅ６００、６１０、６２０，７００及び７１０である。ｉｎｆｏＴｙｐｅ６２０及び７１０は、状態情報がＦＴＰを用いて得られる必要があるように、状態情報マップ８０４にはない。それ故、６２０（ＳＫｅｙＩｎｆｏＴｙｐｅ３）及び７１０（ＳＫｅｙＩｎｆｏＴｙｐｅ５）に対応する状態情報を得るために用いられる情報がベクトル８０６に付加される。ｉｎｆｏＴｙｐｅ６００及び７００は状態情報マップ８０４にある。８０２において示されるようなこれらのｉｎｆｏＴｙｐｅに対するＦＴＰにより得られる状態情報の重みは、状態情報マップ８０４におけるそれらの重みより大きい。従って、ＦＴＰによりこれら２つのｉｎｆｏＴｙｐｅに対して得られた状態情報は、マップ８０４にある状態情報より報知性が高い。それ故、ｉｎｆｏＴｙｐｅ６００（ＳＫｅｙＩｎｆｏＴｙｐｅ１）及び７００（ＳＫｅｙＩｎｆｏＴｙｐｅ４）についての状態情報を得るための情報がベクトル８０６に付加される。ｉｎｆｏＴｙｐｅ６１０は状態情報マップ８０４にある。８０２において示されているようなこのｉｎｆｏＴｙｐｅに対してＦＴＰにより得られる状態情報の重みは状態情報マップ８０４における重みより小さい。従って、ＦＴｐによりこのｉｎｆｏＴｙｐｅにたいして得られる状態情報は、マップ８０４にある状態情報より報知性が低い。それ故、ｉｎｆｏＴｙｐｅ６１０（ＳＫｅｙＩｎｆｏＴｙｐｅ２）についての状態情報を得るための情報はベクトル８０６には付加されない。このベクトル８０６は、ｉｎｆｏＴｙｐｅ６００、６２０，７００及び７１０についての状態情報を得るためにＦＴＰプロトコルにより用いられる。２つの状態情報値が状態情報マップに付加され、２つの状態情報値は、ＦＴＰが状態情報を得ることに成功する場合、状態情報マップ８０４において重ね書きされる。図３０は、ＦＴＰプロトコルについての状態情報を得るためにどのようにデータ構造が用いられるかについての例を示している。図２７Ｂ、２７Ｃ、２９Ａ及び２９Ｂのデータ構造を用いる類似プロセスは、ＳＮＭＰ及びＨＴＴＰについての状態情報を得るために用いられる。

図３１Ａは、状態情報を得る方法を示すフローチャートである。全てのプロトコルはここで示す同じ方法を用いる。固有の状態情報を得るためにプロトコルオブジェクトを用いる前に、プロトコルオブジェクトは、状態情報が他のプロトコルオブジェクトにより既に得られたかどうかを判定するためにチェックする。状態情報が既に得られている場合、状態情報が、他のプロトコルオブジェクトから既に得られたもの以外の更なる情報を得るかどうかを判定するようにチェックする必要がある。最も報知性の高い状態情報は保持される。このフローチャートの方法は、最も報知性が高い状態情報が得られるように構成される。図２７Ｂ、２７Ｃ及び２７Ｄのデータ構造５１０、５２０および５３０は、どのような状態情報が得られるべきかを決定するために対応するプロトコルにより用いられる。段階３１０２において、ネットワーク装置から状態情報を得るために用いられる情報を含む対のベクトルがエントリを伴わずに生成される。その対のベクトルは、用いられるプロトコルに依存して、図１９Ａ乃至２９Ｃのデータ構造７００、７０８又は７１６の１つに対応する。段階３１０４において、所定のベンダ及びモデルのネットワーク装置から状態情報を得るために用いられる情報が得られる。全てのプロトコルオブジェクトは、全てのベクトル及びモデルに対してどのような状態情報をそれが支援するかについての情報を維持する。プロトコルオブジェクト全ては、図２８に示している初期化プロセルによりこの情報と共に初期化される。１つの状態情報を得るために用いられる情報は、用いられるプロトコルに依存して、図２９Ａ、２９Ｂ及び２９Ｃの構造ＳＯＩＤｉｎｆｏＴｙｐｅ７０６、ＳＫｅｙＶａｌｕｅＩｎｆｏ７１４及びＳＫｅｙＩｎｆｏＴｙｐｅ７２２の１つに記憶される。段階３１０６において、ネットワーク装置から状態情報を得るために用いられるいずれの更なる情報があるかどうかを決定するためのチェックがなされる。更なる情報がない場合、段階３１０２において生成された対のベクトルは、そのプロトコルについてのネットワークからの状態情報全てを得る必要がある情報全てを含んでいる。段階３０８において、プロトコルオブジェクトはネットワーク装置から状態情報を得るために対のベクトルを用い、状態情報は図１９Ｄに示す状態情報マップ７２４に位置付けられる。プロトコルにより状態情報を得ることは段階３１１０において終了する。ネットワーク装置から状態情報を得るために用いられる更なる情報が存在する場合、段階３１１２において、状態情報が既に得られたかどうかについて判定するためにチェックする。これは、上位タイ情報がそのマップに既に存在するかどうかを判定するために図２９Ｄに示す状態情報を含むマップを調べることによりなされる。状態情報がそのマップに存在しない場合、段階３１１４において、対のベクトルに対して状態情報を得るために用いられる情報を付加する。対のベクトルに情報を付加した後、状態情報を得るために用いられる更なる情報を得るために段階３１０４に戻る。状態情報が既に得られている場合、段階３１１６においてそのプロトコルにより得られることができる状態情報の優先順位又は重みを用いて既に得られた状態情報の重みを比較する。ネットワーク装置の状態情報についてのマップにおける状態情報の優先順位又は重みがそのプロトコルにより得られる状態情報の優先順位又は重みより大きい場合、対のベクトルに対して状態情報を得るために用いられる情報は付加されない。それに代えて、状態情報を得るために用いられる状態情報を得るために段階３１０４に戻る。マップにおける状態情報の優先順位又は重みがそのプロトコルにより得られる状態情報の優先順位又は重みより大きくない場合、段階３１１４において対のベクトルに対して状態情報を得るために用いられる情報を付加する。対のベクトルに情報を付加した後、状態情報を得るために用いられる更なる情報を得るために段階３１０４に戻る。

図３１Ｂは、プロトコル全てを用いて、ネットワーク装置に関する状態情報を得るプロセスについて示すフローチャートである。プロトコルオブジェクトが、図２８に示すように、それが支援するネットワーク装置のベンダ及びモデルに関する情報と共に初期化された後、そのプロトコルオブジェクトはネットワーク装置から状態情報を得るために用いられることができる。プロトコルオブジェクトは、図２７Ｂ、２７Ｃ及び２７Ｄにおいて示すようなデータ構造を用いて、所定のベンダ及びモデルについての状態情報をどのように得るべきかについての情報を含む。図２７ＡにしメスＣＡｂｓＰｒｏｔｏｃｏｌ２３０８に対するポインタのベクトルは、プロトコルオブジェクト全てについての状態情報を得るために用いられる。そのフローチャートのプロセスは、一回、そのベクトルにより進められる。段階３１２２において、プロトコルオブジェクトはＣＡｂｓＰｒｏｔｏｃｏｌに対してポインタのベクトルから得られる。プロトコルオブジェクトはネットワーク装置（例えば、ＳＮＭＰ、ＨＴＴＰ及びＦＴＰ）にアクセスするためにネットワークプロトコルの１つに対応する。段階３１２４において、そのベクトルから得ることができるいずれの更なるプロトコルオブジェクトが存在するかどうかについて判定するためにチェックがなされる。このチェックは、ベクトルの終点が到達したかどうかを判定することによりなされる。更なるプロトコルオブジェクトが得られない場合、システムは、段階３１２６においてプロトコルオブジェクト全てを用いてネットワーク装置から状態情報を得るためにプロトコルオブジェクトを用いる。プロトコルオブジェクトを用いて状態情報を得た後、段階３１２２に戻ることにより他のプロトコルオブジェクトを用いて更なる状態情報を得る。 図３２Ａは、所定のプロトコルにより支援されているネットワーク装置のベンダ及びモデルについての情報を維持するために用いられるデータ構造を示している一方、図３２Ｂは、データ構造において用いられる情報の例を示している。支援されているベンダ及びモデルについてのデータベースにおける情報の構成及びそれらから状態情報をどのように得るかはプロトコルにより変化する。それ故、異なるプロトコルについてのデータベースから支援されるベンダ及びモデルを得ることは互いに異なる。支援されるベンダ及びモデルのアクセスを簡単化して、プロトコルすべてに対してこの情報にアクセスするため及びこの情報を記憶するためにマップ構造を用いることができる。図３２Ａはベンダモデル支援マップ３２００を示している。マップ３２００に対するキー３２０２は、プロトコルにより支援されるベンダ及びモデルについての情報を含むストリングである。マップ３２００に対する値３２０４は、ベクトルモデル識別数のようなベンダ及びモデルに関連する情報を表すために用いられることができる整数である。プロトコルにより支援されたベンダ及びモデルについての情報を含むようにマップ構造が選択される理由は、マップ構造がマップにおいてキーを容易にみつけるためにルックアップ機構を有するためであった。それ故、ベンダ及びモデルがマップにどのように記憶されるかを決定することは容易である。異なるプロトコルに対するベンダ及びモデルについての情報を示す図３２Ａについての説明はデータベースから導き出されたが、情報は、テキストファイル又はスプレッドシートのようないずれの外部ソースからもたらされる。

図３２Ｂは、マップにおいてサンプルエントリをもつベンダモデル支援マップ３２０６を示している。マップ３２０６に対するキー３２０８は、ベンダ名、セパレータ“％％％％％”及びモデル名である。例えば、ベンダ“Ｘｅｒｏｘ”及びモデル“ＮＣ６０”に対しては、マップ３２０６に対するキー３２０８についてのストリングは“Ｘｅｒｏｘ％％％％％ＮＣ６０”である。セパレータ“％％％％％”は例として用いられたが、
“＠＠＠＠＠”のようなベンダ名又はモデル名の一部とみなされないセパレータが用いられることができる。セパレータが用いられる理由は、ベンダ及びモデルをストリングから容易に得ることができるように、ベンダをモデルと区別して用いるためである。マップ３２０６に対する値３２１０は整数１である。マップ３２０６に対する値３２１０はいずれの整数であることが可能である。各々のプロトコルは、ベンダモデル支援マップ３２００を維持する。

図３３は、プロトコルにより支援されるベンダ及びモデル全てを含むように図３２Ａのベンダモデル支援マップ３２００を支援するベンダ及びモデルを付加する方法について示すフローチャートである。段階３３０２において、ベンダ及びモデルはデータベースから得られる。ベンダ及びモデルがデータベースからどのように得られるかはプロトコルにより異なる。これは、支援されるベンダ及びモデルを含むデータベースにおけるテーブルに依存する。段階３３０４において、データベースかた得られる更なるベンダ及びモデル情報が存在するかどうかを判定するためにチェックがなされる。得られる更なる情報が存在しない、支援されるベンダ及びモデルと共にベンダモデル支援マップ３２００を格納する方法は段階３３０６において終了する。ベンダモデル支援マップ３２００はプロトコルにより支援されるベンダ及びモデル全てを含む。支援されたベンダ及びモデル情報を得るためにデータベースへの更なるアクセスは必要ない。データベースから得られるベンダ及びモデルが存在する場合、段階３３０８において、ベンダモデル支援マップ３２００に対するキーとして用いられるストリングを生成する。そのストリングは、ベンダ名、セパレータ及びモデル名から成る。上記のように、セパレータは、ベンダ名又はモデル名の一部とみなされないいずれのストリングであることが可能である。段階３３１０において、ベンダ名、セパレータ及びモデル名を構成するストリングがベンダモデル支援マップ３２００に既に存在するかどうかを判定するためにチェックがなされる。そのストリングがマップ３２００に既に存在する場合、段階３３０２において、データベースから他のベンダ及びモデルを得る。そのストリングがマップ３２００に存在しない場合、マップ３２００にストリング及び整数を付加する。そのストリングがマップ３２００に付加された後、段階３３０２においてデータベースから他のベンダ及びモデルを得る。

図３４は、図３２のベンダモデル支援マップ３２００からのプロトコルにより支援されるベンダ及びモデルを得る方法について示すフローチャートである。段階３４０２において、キーに対するストリングはベンダモデル支援マップ３２００から得られる。段階３４０４において、マップ３２００から得られるいずれの更なるキーが存在するかどうかを判定するためにチェックがなされる。更にキーが存在しない場合、プロトコルにより支援されるベンダ及びモデル全てが得られており、ベンダ及びモデルを得ることは段階３４０６において終了する。キーに対するストリングがマップ３２００にから得られる場合、段階３４０８において、セパレータがベンダ名を得る前にサブストリングを得る。段階３４１０において、セパレータがモデル名を得た後、サブストリングを得る。次いで、段階３４０６において、ベンダ及びモデルを得ることは終了する。マップ３２００においてエントリ全てを完了することにより、プロトコルにより支援されるベンダ及びモデル全てを得ることができる。

図３５は、装置パッケージのパッケージを示す図である。パッケージは、ネットワーク装置を表すソフトウェアオブジェクトを生成するために責任を負う。装置パッケージ１３００は、２つのクラス、ＣＤｅｖｉｃｅＦａｃｔｏｒｙ１３０２及びＣＤｅｖｉｃｅ１３０４から成る。クラスＣＤｅｖｉｃｅＦａｃｔｏｒｙ１３０２は、ネットワーク装置に対してソフトウェアオブジェクトを生成し、初期化するために責任を負う。ソフトウェアオブジェクトの初期化は、ネットワーク装置にアクセスするために用いることができるプロトコルの設定と、ネットワーク装置のベンダ、モデル及び一意の識別子を決定とを含む。ネットワーク装置にアクセスすることができない場合、ネットワークに対するソフトウェアオブジェクトは生成されない。クラスＣＤｅｖｉｃｅ１３０４はネットワーク装置に対してソフトウェアオブジェクトを表す。ＣＤｅｖｉｃｅ１３０４はネットワーク装置についての情報を維持し、ネットワーク装置についての状態情報を得る。ＣＤｅｖｉｃｅ１３０４は、装置から情報を得るために種々のプロトコルによりネットワーク装置にアクセスするために、図２３に示すＨＷａｃｃｅｓｓパッケージを用いる。

図３６Ａは、どのプロトコルがネットワーク装置にアクセスするために用いられるかを判定するために、図３５に示すようなネットワーク装置、即ち、ＣＤｅｖｉｃｅ１３０４を表すソフトウェアオブジェクトにより用いられるデータ構造を示している。ＣＤｅｖｉｃｅ１３０４はプロトコルパラメータマップ１４００を含む。マップ１４００に対するキー１４０２は、プロトコル（例えば、ＳＮＭＰ、ＨＴＴＰ、ＦＴＰ）を表すストリングである。マップ１４００に対する値１４０４は、構造ＳＰａｒａｍｅｔｅｒのベクトルである。構造ＳＰａｐａｍｅｔｅｒ１４０６は、ネットワーク装置のベンダ及びモデルの特徴より装置の特徴を備えた情報を含む。例えば、その情報はＳＮＭＰによりネットワーク装置にアクセスするためにコニュニティ名であることが可能であり、又はその情報はＦＴＰによりネットワーク装置にアクセスするためにユーザ名及びパスワードであることが可能である。これらな、ＳＮＭＰ又はＦＴＰによりいずれのネットワーク装置にアクセスするために用いられる共通情報値である。ＤｅｖｉｃｅＯＤＢＣパッケージにより得られたデータベースからの情報は、ネットワーク装置が種々のプロトコルによりアクセスされることができるように、そのマップに付加される。プロトコルがプロトコルを用いてネットワーク装置にアクセスすることができない場合及びベンダ及びモデルがプロトコルにより支援されない場合、そのマップにおけるエントリはそのプロトコルに対して取り除かれる。一部のプロトコルは、ベンダ及びモデルがプロトコルにより支援されない場合にも拘らず、ネットワーク装置にアクセスする。そのようなプロトコルの１つはＳＮＭＰである。

図３６Ｂは、ネットワーク装置に対する図３６Ａのプロトコルパラメータマップ１４００におけるサンプルデータを示している。ネットワーク装置は、状態情報ＳＮＭＰ及びＦＴＰを得るために２つのプロトコルを用いる。それ故、ネットワーク装置のためのマップ１４１０は、キー“ＳＮＭＰ”及び“ＦＴＰ”に対して２つのエントリを含む。ＳＮＭＰを用いてネットワーク装置にアクセスするために、コミュニティ名が必要である。ＳＮＭＰに対するＳＰａｒａｍｅｔｅｒのベクトルはコミュニティ名についての情報を含む。コミュニティのパラメータ名及び“私的”のパラメータ値は、１つのＳＰａｒａｍｅｔｅｒがネットワーク装置へのアクセスを可能とするように、用いられる。ＦＴＰを用いてネットワークにアクセスするために、ユーザ名及びパスワードが必要である。ＦＴＰのためのＳＰａｒａｍｅｔｅｒのベクトルはユーザ名及びパスワードについての情報を含む。パラメータ名“ａｂｃ”をもつユーザ名のパラメータ名は、一のＳＰａｒａｍｅｔｅｒに対して用いられ、パラメータ名“ｘｙｚ”をもつパスワードのパラメータ名は、ネットワーク装置にアクセスすることを可能にするように他のＳＰａｒａｍｅｔｅｒに対して用いられる。

図３７は、どのプロトコルがネットワーク装置から状態情報を得るために用いられるかを判定するために、図３６Ａのプロトコルパラメータマップ１４００がどのようにアップデートされるかを表すフローチャートを示している。図３７における各段階は、プロトコルに対するネットワーク装置のベンダ名及びモデル名を得るために実行される。段階３７０２において、ネットワーク装置がプロトコルを用いてアクセスされることができるかどうかを判定するためにチェックがなされる。ネットワーク装置は、マップ１４００において情報を用いてプロトコルによりアクセスされる。ネットワーク装置がプロトコルによりアクセスされることができない場合、そのプロトコルは段階３７０４においてプロトコルパラメータマップ１４００から取り除かれ、マップ１４００の更新は段階３７１４において終了する。ネットワーク装置がプロトコルによりアクセスされることができる場合、段階３７０６において、プロトコルを用いてネットワーク装置のベンダを得ることができるかどうかを判定するためにチェックがなされる。ベンダを得ることができない場合、段階３７０７において、ＧＥＮＥＲＩＣベンダがプロトコルにより支援されているかどうかについてのチェックがなされる。ＧＥＮＥＲＩＣベンダが装置のベンダを得ることができないかそれを支持しないに拘らず、全ての装置に共通の状態情報（共通の状態情報）をプロトコルが得ることができるプロトコル手段に対してＧＥＮＥＲＩＣベンダを支援する。ＧＥＮＥＲＩＣベンダがプロトコルにより支援されない場合、段階３７０４において、そのプロトコルはプロトコルパラメータマップ１４００から取り除かれ、段階３７１４において、マップ１４００の更新は終了する。ＧＥＮＥＲＩＣベンダがプロトコルにより支援される場合、そのプロトコルはプロトコルパラメータマップ１４００に残り、段階３７１４において、マップの更新は終了する。段階３７０６において、ベンダを得ることができる場合、段階３７０８において、ネットワーク装置のベンダがプロトコルにより支援されているかどうかを判定するためにチェックがなされる。ベンダがプロトコルにより支援されていない場合、段階３７０７において、ＧＥＮＥＲＩＣベンダがプロトコルにより支援されているかどうかのチェックがなされる。段階３７０７に続く段階のシーケンスについては、上で説明した。

ベンダがプロトコルにより支援されている場合、プロトコルを用いてネットワーク装置のモデルを得ることができるかどうかを判定するためにチェックがなされる。そのモデルを得ることができない場合、段階３７１１において、一般モデルがプロトコルにより支援されるかどうかのチェックがなされる。ＧＥＮＥＲＩＣベンダが装置のモデルを得ることができないかそれを支持しないに拘らず、ベンダの全ての装置に共通の状態情報（ベンダ固有の状態情報）をプロトコルが得ることができるプロトコル手段に対してＧＥＮＥＲＩＣモデルを支援する。ＧＥＮＥＲＩＣベンダがプロトコルにより支援されない場合、段階３７０４において、そのプロトコルはプロトコルパラメータマップ１４００から取り除かれ、段階３７１４において、マップ１４００の更新は終了する。ＧＥＮＥＲＩＣモデルがプロトコルにより支援される場合、そのプロトコルはプロトコルパラメータマップ１４００に残り、段階３７１４において、マップの更新は終了する。段階３７１０において、ベンダを得ることができる場合、段階３７１２において、ネットワーク装置のモデルがプロトコルにより支援されているかどうかを判定するためにチェックがなされる。モデルがプロトコルにより支援されていない場合、段階３７１１において、ＧＥＮＥＲＩＣモデルがプロトコルにより支援されているかどうかのチェックがなされる。段階３７１１に続く段階のシーケンスについては、上で説明した。モデルがプロトコルにより支援される場合、プロトコルをネットワーク装置に対して状態情報を得るために用いることができ、プロトコルパラメータマップ１４００の更新は段階３７１４において終了する。ベンダ及びモデルが得られず又は支援されていない場合、プロトコルはプロトコルパラメータマップ１４００から取り除かれ、そのプロトコルは状態情報を得るためには用いられない。プロトコルに依存して図３７において示されるプロセスに対して変形が存在する。ＨＴＴＰ及びＦＴＰはフローチャートにおける説明に従い、ＳＮＭＰは、ベンダは支援されているが、モデル及び一般モデルは支援されていない場合であっても、状態情報を得るために支援され、用いられる。

上記のように、ベンダ及びモデルが得られない又は支援されない場合であっても、状態情報をネットワーク装置からＳＮＭＰにより得ることができる。ネットワーク装置がＳＮＭＰを支援し、ＳＮＭＰによりアクセスされることができる限り、ＳＮＭＰプロトコルは、段階３７０４において、プロトコルパラメータマップ１４００から取り除かれることが可能である。しかしながら、ネットワーク装置はＳＮＭＰによりアクセスされることができ、ベンダ又はモデルが得られ及び支援されるか否かに拘らず、ＳＮＭＰプロトコルはプロトコルパラメータマップ１４００に維持される。ＳＮＭＰを支援するネットワーク装置はＭＩＢを提供し、それ故、リモートシステムは、常に、装置から情報を得ることができる。しかしながら、ネットワーク装置から得ることができる情報のタイプ及び数は、ベンダ及びモデルが得られ、支援されるかどうかに依存する。ＳＮＭＰによりネットワーク装置らか得ることができる更なる情報は、ベンダ及びモデルが得られ、周知であることである。ベンダ及びモデルを得ることができない場合、ＳＮＭＰは又、システム説明書又はシステムが作動した時間のような、全ての装置が提供する情報を得ることができる。次のような３つの条件下でネットワーク装置から情報を得るためにＳＮＭＰを用いることができる。即ち、（１）ベンダ及びモデルは支援されている、（２）ベンダは支援され、モデルは支援されていない、及び（３）ベンダ及びモデルは支援されていない、の３つの条件である。ＨＴＴＰ及びＦＴＰはＳＮＭＰとしての特性を有している。ＳＮＭＰが、情報を得ることができるように、全てのネットワーク装置が従うことができる規準ＭＩＢを有する場合、ウェブページ及びＦＴＰファイルは異なるベンダ及びモデルのネットワーク装置間で変化する。ネットワーク装置が情報を得るために従うＦＴＰファイル及びウェブページについての基準はない。

本発明については、ネットワークに接続されるモニタリングを必要とする、幾つかの装置を含むように示したが、本発明の範囲及び主旨から逸脱することなく、いずれの数の装置をネットワークに接続すること可能であることを理解されるであろう。又、本発明は、種々の装置がモニタリングされ、制御される家庭環境において適用されることが可能である。

本発明は、特定の私的な管理情報ベース（ＭＩＢ）情報を有することさえなく、ユーザによる理解可能又はユーザフレンドリな方式で詳細情報を検索し、表示する他のファシリティ及び複数ベンダの環境下で種々の装置のモニタリングを可能にする。

本発明の制御器は、コンピュータ技術分野における熟達した技術者に理解できるように、本発明の明細書の記載内容に従ってプログラム去れるマイクロプロセッサまたは従来の汎用のディジタルコンピュータを用いて便利に実施されることが可能である。適切なソフトウェアコーディングは、ソフトウェア技術分野における熟達した技術者に理解されるように、本発明の開示内容に基づいて熟練プログラマにより容易に準備されることができる。本発明は又、当業者により容易に理解できるように、従来のコンピュータ回路の適切なネットワークに相互接続することにより特定用途向け集積回路の作製により実行されることが可能である。

本発明は、本発明のプロセスを実行するようにコンピュータをプログラムするために用いることができる命令を含む記憶媒体に備えられたコンピュータプログラムプロダクトを含む。記憶媒体は、フロッピー（登録商標）ディスク、光ディスク、ＣＤ−ＲＯＭ及び光磁気ディスクを含むいずれの種類のディスク、ＲＯＭ、ＲＡＭ、ＥＰＲＯＭ、ＥＥＰＲＯＭ、磁気カード、光カード、又は電子的命令を記憶するために適切ないずれの種類の媒体を含むことができるが、それらに限定されるものではない。

明らかに、上記の開示に照らして、数多くの本発明の変更及び修正が可能である。従って、同時提出の特許請求の範囲における範囲内で、以上で具体的に説明した内容以外の他の方式で本発明を実施することが可能である。

本発明に従って、コンピュータ及びデータベースのネットワークに接続された３つのネットワーク化された事務所用装置を示している。 ディジタル画像形成装置の構成要素を示す図である。 図２に示すディジタル画像形成装置の電気的構成要素を示す図である。 図３に示す多ポート通信インタフェースの詳細を示す図である。 事務所用装置がネットワークに直接接続されたか又はネットワークに接続されたコンピュータに接続された、他のシステム構成を示す図である。 電子メールを用いてアプリケーションユニットへの及びそれからの情報の流れを示すブロック図である。 アプリケーションユニットに接続されたコンピュータが又、メッセージトランスファエージェント（ＭＴＡ）として機能する、電子メールを用いる他の通信方法を示す図である。 電子メールを交換するためのメッセージトランスファエージェントをアプリケーションユニットが含む、電子メールを用いる他の通信方法を示す図である。 電気製品／装置に対してメールを受信するためのＰＯＰ３サーバとして及び電気製品／装置に対してメールを送信するためのＳＭＴＰ（Ｓｉｍｐｌｅ Ｍａｉｌ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）としてメールサーバが機能する、電子メールを用いる他の通信方法を示す図である。 インターネットによりメッセージを送信する他の方法を示す図である。 電気製品／装置に接続され、電子メールメッセージを通信するために用いられることが可能である代表的なコンピュータを示す図である。 本発明の代表的な実施形態に従った全体的システムを模式的に表す図である。 本発明の代表的な実施形態に従ったインタフェース機能及びデータのモニタリングにおいて用いるモジュールを示す図である。 サブモジュール間の呼び出しモジュール及びモニタモジュールにおける細部を示す図である。 図１１に示すＨＷａｃｃｅｓｓサブモジュールにより用いられるデータ構造を示す図である。 図１０に示すも似たモジュールのｉｎｉｔ機能のシーケンスを示す図である。 図１１に示す、モニタマネージャにより被モニタリング装置の状態を判定するための状態モニタ機能の代表的なシーケンスを示す図である。 図１３に示す、モニタマネージャにより用いられ、ＣＤｅｖｉｃｅＦａｃｔｏｒｙにより生成される装置に対する基準のベクトルを示す図である。 抽象クラスＣＡｂｓＰｒｏｔｏｃｏｌＰａｒａｍｅｔｅｒｓを含む装置ＯＤＢＣモジュールのクラス構造を示す図である。 本発明に従った被モニタリング装置にアクセスするために必要なパラメータ値を記憶するために用いられるＳＰａｒａｍｅｔｅｒデータ構造を示す図である。 本発明に従った被モニタリング装置にアクセスするために必要なパラメータ値を記憶するために用いられるマップを示す図である。 本発明において用いられるモニタデータベースの構成を示す図である。 本発明による通信プロトコルに従って配置された支援データベースの構成を示す図である。 本発明による通信プロトコルに従って配置された支援データベースの構成を示す図である。 本発明による通信プロトコルに従って配置された支援データベースの構成を示す図である。 本発明に従ったＨＷａｃｃｅｓｓモジュールのクラス構造を示す図である。 本発明に従ったＳＮＭＰモジュールのクラス構造を示す図である。 本発明に従ったＨＴＴＰモジュールのクラス構造を示す図である。 本発明に従ったＦＴＰモジュールのクラス構造を示す図である。 本発明に従った被モニタリング装置から状態情報を得るためと被モニタリング装置にアクセスするためとに必要な情報を維持するために図２３のＨＷａｃｃｅｓｓモジュールにおいて用いられるデータ構造を示す図である。 本発明に従った被モニタリング装置から状態情報を得るためと被モニタリング装置にアクセスするためとに必要な情報を維持するために図２３のＨＷａｃｃｅｓｓモジュールにおいて用いられるデータ構造を示す図である。 本発明に従った被モニタリング装置から状態情報を得るためと被モニタリング装置にアクセスするためとに必要な情報を維持するために図２３のＨＷａｃｃｅｓｓモジュールにおいて用いられるデータ構造を示す図である。 本発明に従った被モニタリング装置から状態情報を得るためと被モニタリング装置にアクセスするためとに必要な情報を維持するために図２３のＨＷａｃｃｅｓｓモジュールにおいて用いられるデータ構造を示す図である。 本発明に従った被モニタリング装置のベンダ情報と共にプロトコルオブジェクトを初期化するプロセスを示すフローチャートである。 本発明に従った各々のプロトコルに対する固有のベンダ及びモデルの日モニタ装置の状態情報を得るために用いられるデータ構造を示す図である。 本発明に従った各々のプロトコルに対する固有のベンダ及びモデルの日モニタ装置の状態情報を得るために用いられるデータ構造を示す図である。 本発明に従った各々のプロトコルに対する固有のベンダ及びモデルの日モニタ装置の状態情報を得るために用いられるデータ構造を示す図である。 本発明に従った各々のプロトコルに対する固有のベンダ及びモデルの日モニタ装置の状態情報を得るために用いられるデータ構造を示す図である。 本発明に従ったＦＴＰプロトコルを用いて被モニタリング装置から状態情報を得る、図２７Ｄ、２９Ｃ及び２９Ｄのデータ構造に対するサンプリデータの例を示す図である。 本発明に従った通信プロトコルに対して被モニタリング装置から状態情報を得るプロセスを示すフローチャートである。 本発明に従った通信プロトコルの全てを用いて被モニタリング装置から状態情報を得るプロセスを示すフローチャートである。 本発明に従った所定のプロトコルにより支援される被モニタリング装置のベンダ及びモデルについての情報を維持するために用いられるデータ構造を示す図である。 図３２Ａにしメスデータ構造の例を示す図である。 本発明に従った図３２Ａのデータ構造に支援されたベンダ及びモデルを付加する方法を示すフローチャートである。 本発明に従った図３２Ａのデータ構造からのプロトコルにより支援されるベンダ及びモデルを得る方法を示すフローチャートである。 本発明に従った装置モジュールのクラス構造を示す図である。 本発明に従った被モニタリング装置にアクセスするためにどのプロトコルが用いられるかを判定するために被モニタリング装置を表すソフトウェアオブジェクトにより用いられるデータ構造を示す図である。 図３６Ａのデータ構造におけるサンプルデータを示す図である。 本発明に従った被モニタリング装置に対して状態情報を得るためにどのプロトコルが用いられるかを判定するために図３６Ａのデータ構造がどのように更新されるかを示すフローチャートである。

符号の説明

１０ 広域ネットワーク（ＷＡＮ）
１２Ａ乃至１２Ｉ ルータ及びコンピュータ
１６ 第１ネットワーク
１７、１８、２０、２２ ワークステーション
２４ ディジタル画像形成装置
２６ 電話コネクション
２７ 事務所用電気製品
２８ ファックス装置
３０ ケーブルコネクション
３２ プリンタ
３４ 無線コネクション
５０Ａ乃至５０Ｃ ファイアウォール
５０−１乃至５０−４ ファイアウォール
５２ ネットワーク
５４ ディスク
５６ ワークステーション
５８ ディスク
６０ ケーブルコネクション
６２ ワークステーション
６４ ディスク
６６ ケーブルコネクション
６８ ワークステーション
７０ ディスク
７２ ケーブルコネクション
７４ ワークステーション
７６ ディスク
８０ ケーブルコネクション
１０１ ファン
１０２ 多面鏡
１０３ Ｆθレンズ
１０４ センサ
１０５ レンズ
１０６ クエンチングランプ
１０７ 帯電コロナユニット
１０８ 現像ローラ
１０９ ランプ
１１０乃至１１２ 鏡
１１３ ドラム鏡
１１４ ファン
１１５ 第１給紙ローラ
１１６ マニュアル給紙テーブル
１１７ 第１給紙カセット
１１８ 第２給紙ローラ
１１９ 第２給紙カセット
１２０ 中継ローラ
１２１ レジストレーションローラ
１２２ 画像密度センサ
１２３ 転写／分離コロナユニット
１２４ クリーニングユニット
１２５ 真空ファン
１２６ 搬送ベルト
１２７ 圧力ローラ
１２８ 出口ローラ
１２９ 加熱ローラ
１３０ 排気ファン
１３１ 主モータ
１６０ ＣＰＵ
１６２ ＲＡＭ
１６４ ＲＯＭ
１６６ マルチポートネットワークインタフェース
１６８ 電話、無線又はケーブル回線
１７０ ネットワーク
１７１ ローカルコネクション
１７２ Ｉ／Ｆ制御器
１７４ 操作パネル
１７６ ストレージＩ／Ｆ
１７８ フラッシュメモリ
１８０ コネクション
１８２ ディスク
１８６ システムバス
１８４ 任意インタフェース
１８７ クロック／タイマー
１８８ 任意ユニットインタフェース
１９０ フューザ
１９２ プリンタ／イメージャ
１９４ スキャナ
１９６ 給紙制御器
１９８ 大容量トレーユニット
２００ デュプレクサ
２０２ ソータ
２２０ トークンリングインタフェース
２２２ ケーブルモデム
２２４ 電話インタフェース
２２８ 無線インタフェース
２３０ イーサネットインタフェース
２５４ サービスマシン
２５６ データ
２６０−１、２６０−２ インターネット
２６２ プリンタ
２６４ インターネットサービスプロバイダ
２６６ コンピュータ
２６８ 事務所用装置
２７２ コンピュータ
２７４ ネットワーク
２７６ コンピュータ
２７８ 事務所用装置
２８２ コンピュータ
２８５ 事務所用電気製品
２８６ コピー装置
３００ 装置／電気製品
３０２ 装置／電気製品へのコンピュータインタフェース
３０４ メールエージェント
３０６ 送信されるメールのキュー
３０８ メッセージトランスファエージェント
３１０ ＴＣＰ／ＩＰコネクション
３１２ メッセージトランスファエージェント
３１４ ユーザメールボックス
３１６ メールエージェント
３１８ 端末のユーザ
３２０ 送信ホスト
３２２Ａ乃至３２２Ｆ ローカルＭＴＡ
３２８Ａ、３２１Ｂ リレーＭＴＡ
３４２ 受信ホスト
３６０ コンピュータ
３６２ ＣＰＵ
３６４ ＲＡＭ
３６６ 無線インタフェース
３６８ 無線装置
３７０ ＲＯＭ
３７１ フラッシュメモリ
３７２ 入力制御器
３７４ キーボード
３７６ マウス
３７８ シリアルインタフェース
３８０ シリアル装置
３８２ パラレルインタフェース
３８４ パラレル装置
３８６ ユニバーサルシリアルバスインタフェース
３８８ ユニバーサルシリアルバス装置
３９０ システムバス
３９２ ハードディスク
３９４ フロッピードライブ
３９６ ディスク制御器
３９８ ＩＥＥＥ １３９４インタフェース
４００ ＩＥＥＥ １３９４インタフェース
４０４ ネットワーク
４０６ 通信制御器
４０８ Ｉ／Ｏ制御器
４１０ プリンタ
４１２ ハードディスク
４１４ ＣＲＴ
４１６ 表示制御器
９００ システム
９０２ モニタリングステーション
９０４ ディスク
９０６ データベース
９０８ リコーレーザプリンタ
９１０ ネットワークスキャナ
９１２ ベンダ１ ネットワーク装置
９１４ リコーＭＦＰ
９２４ アクセスポート
１００２ タイマーモジュール
１００４ モニタサービスサービス
１００６ モニタモジュール
１０１４ モニタデータベース
１０２４ 支援データベース
１１０１ 共通モジュール
１１０２ モニタマネージャモジュール
１１０４ ＤｅｖｉｃｅＯＤＢＣモジュール
１１１０ 装置モジュール
１１１６ ＨＷａｃｃｅｓｓモジュール
１２００ ＳｋｅｙＶａｌｕｅＩｎｆｏ構造
１２０２ ｉｎｆｏＴｙｐｅ
１２０４ ｍ＿ｓＫｅｙフィールド
１２０６ ｍ＿ｎＰｏｓｉｔｉｏｎフィールド
１２０８ ｍ＿ｓＴｙｐｅフィールド
１２１０ ｍ＿ｓＤｅｌｉｍｉｔｅｒフィールド
１２１２ ｍ＿ｎＩｎＬｉｎｅＰｏｓｉｔｉｏｎフィールド
１５００ ベクトル
１５０２、１５０４ ＣＤｅｖｉｃｅオブジェクトへのポインタ
１７００ データ構造
１８００ マップ構造
１８０２ ＳＮＭＰプロトコル
１８０４ ＨＴＴＰプロトコル
１８０６ ＦＴＰプロトコル
１８０８、１８１０、１８１２ パラメータ
１９０２ 装置情報ＤｅｖｉｃｅＩｎｆｏ
１９０４ ＤｅｖｉｃｅＨｉｓｔｏｒｙ
１９０６ ＥｎｕｍＣｏｒｒｅｓｐｏｎｄｅｎｃｅ
１９０８ ＳＮＭＰプロトコル
１９１０ ＨＴＴＰプロトコル
１９１２ ＦＴＰプロトコル
２００２ ＳＮＭＰＶｅｃｔｏｒデータ構造
２００４ ＳＮＭＰＣｏｍＶｅｎｄｏｅＳｔａｔｕｓデータ構造
２００６ ＥｎｕｍＣｏｒｒｅｓｐｏｎｄｅｎｃｅデータ構造
２００８ ＳＮＭＰＶｅｎｄｅｒＭｏｄｅｌＳｔａｔｕｓデータ構造
２３００ ＣＨＷａｃｃｅｓｓクラス
２３０２ ＨＴＴＰパッケージ
２３０４ ＳＮＭＰパッケージ
２３０６ ＦＴＰパッケージ
２３０８ ＣＡｂｓＰｒｏｔｏｃｏｌクラス
２３１０ ＣＲｅｃｏｒｄＳｅｔクラス
２４００ ＣＡｂｓＰｒｏｔｏｃｏｌクラス
２４０２ ＣＳＮＭＰＰｒｏｔｏｃｏｌクラス
２４０４ ＳＮＭＰａｃｃｅｓｓパッケージ
２４０６ ＳＮＭＰＯＤＢＣパッケージ
２４０８ ＣＲｅｃｏｒｄＳｅｔクラス
２５００ クラスＣＡｂｓＰｒｏｔｏｃｏｌ
２５０２ クラスＣＨＴＴＰＰｒｏｔｏｃｏｌ
２５０４ パッケージＨＴＴＰａｃｃｅｓｓ
２５０６ パッケージＨＴＴＰＯＤＢＣ
２５０８ クラスＣＲｅｃｏｒｄＳｅｔ
２６００ クラスＣＡｂｓＰｒｏｔｏｃｏｌ
２６０２ クラスＣＦＴＰＰｒｏｔｏｃｏｌ
２６０４ パッケージＦＴＰａｃｃｅｓｓ
２６０６ ＦＴＰＯＤＢＣパッケージ
２６０８ クラスＣＲｅｃｏｒｄＳｅｔ

Claims (6)

1. モニタリング装置が、ネットワークに通信可能であるように結合された被モニタリング装置からどのようなタイプの状態情報を抽出するべきかを決定する方法であって、
   前記モニタリング装置が、前記被モニタリング装置から状態情報を抽出するために用いられる複数の通信プロトコルの中から通信プロトコルを選択する段階と、
   前記モニタリング装置が、選択された通信プロトコルに関連するプロトコルオブジェクトを第１メモリから検索する段階であって、前記プロトコルオブジェクトは、少なくとも、一タイプの状態情報と、状態情報の優先順序と、前記の選択された通信プロトコルを用いて前記被モニタリング装置から前記一タイプの状態情報を抽出するための前記被モニタリング装置へのアクセス情報を含むコンフィグレーション情報とを含む、段階と、
   前記モニタリング装置が、前記一タイプの状態情報が第２メモリに存在するかどうかを判定する段階と、
   前記の判定する段階が、前記一タイプの状態情報が前記第２メモリに存在することを判定した場合、前記モニタリング装置が、前記プロトコルオブジェクトに含まれた前記一タイプの状態情報の優先順位が、前記第２メモリに記憶された同じタイプの状態情報の優先順位より大きいかどうかをチェックする段階と、
   （１）前記の判定する段階が、前記一タイプの状態情報が前記第２メモリに存在しないことを判定した場合、又は（２）前記の判定する段階が、前記一タイプの状態情報が前記第２メモリに存在することを判定し、前記一タイプの状態情報の優先順位が、前記第２メモリに記憶された同じタイプの状態情報の優先順位より大きい場合、前記モニタリング装置が、前記状態情報を得るために前記プロトコルオブジェクトに含まれる前記被モニタリング装置から前記一タイプの状態情報を抽出するためのコンフィグレーション情報と前記の選択された通信プロトコルとを用いて、前記被モニタリング装置から前記一タイプの状態情報を抽出する段階とを含むことを特徴とする方法。
2. ネットワークに通信可能であるように結合された被モニタリング装置からどのようなタイプの状態情報を抽出するべきかを決定するシステムであって、
   前記装置から状態情報を抽出するために用いられる複数の通信プロトコルの中から通信プロトコルを選択する手段と、
   選択された通信プロトコルに関連するプロトコルオブジェクトを第１メモリから検索する手段であって、前記プロトコルオブジェクトは、少なくとも、一タイプの状態情報と、状態情報の優先順序と、前記の選択された通信プロトコルを用いて前記装置から前記一タイプの状態情報を抽出するための前記被モニタリング装置へのアクセス情報を含むコンフィグレーション情報とを含む、手段と、
   前記一タイプの状態情報が第２メモリに存在するかどうかを判定する手段と、
   前記の判定する手段が、前記一タイプの状態情報が前記第２メモリに存在することを判定した場合、前記プロトコルオブジェクトに含まれた前記一タイプの状態情報の優先順位が、前記第２メモリに記憶された同じタイプの状態情報の優先順位より大きいかどうかをチェックする手段と、
   （１）前記の判定する手段が、前記一タイプの状態情報が前記第２メモリに存在しないことを判定した場合、又は（２）前記の判定する手段が、前記一タイプの状態情報が前記第２メモリに存在することを判定し、前記一タイプの状態情報の優先順位が、前記第２メモリに記憶された同じタイプの状態情報の優先順位より大きい場合、前記状態情報を得るために前記プロトコルオブジェクトに含まれる前記装置から前記一タイプの状態情報を抽出するためのコンフィグレーション情報と前記の選択された通信プロトコルとを用いて、前記装置から前記一タイプの状態情報を抽出する手段とを有することを特徴とするシステム。
3. 前記の判定する手段は、
   前記一タイプの状態情報が前記第２メモリの状態情報マップに存在するかどうかを判定する手段であって、前記状態情報マップは少なくとも１つのエントリを有し、各々のエントリは、状態情報タイプと、状態情報値と、状態情報の優先順位とを含む、ことを特徴とする、請求項２に記載のシステム。
4. 前記の選択する手段は、
   ＳＮＭＰ、ＨＴＴＰ及びＦＴＰの中から通信プロトコルを選択する手段を有することを特徴とする、請求項２に記載のシステム。
5. 前記状態情報の優先順位は、他の複数の通信プロトコルを用いて抽出された同じタイプの状態情報に関連する状態情報の相対的情報値を表すことを特徴とする、請求項２に記載のシステム。
6. ネットワークに通信可能であるように結合された被モニタリング装置からどのようなタイプの状態情報を抽出するべきかを決定するためのコンピュータプログラムであって、コンピュータに、
   前記装置から状態情報を抽出するために用いられる複数の通信プロトコルの中から通信プロトコルを選択する段階と、
   選択された通信プロトコルに関連するプロトコルオブジェクトを第１メモリから検索する段階であって、前記プロトコルオブジェクトは、少なくとも、一タイプの状態情報と、状態情報の優先順序と、前記の選択された通信プロトコルを用いて前記装置から前記一タイプの状態情報を抽出するための前記被モニタリング装置へのアクセス情報を含むコンフィグレーション情報とを含む、段階と、
   前記一タイプの状態情報が第２メモリに存在するかどうかを判定する段階と、
   前記の判定する段階が、前記一タイプの状態情報が前記第２メモリに存在することを判定した場合、前記モニタリング装置が、前記プロトコルオブジェクトに含まれた前記一タイプの状態情報の優先順位が、前記第２メモリに記憶された同じタイプの状態情報の優先順位より大きいかどうかをチェックする段階と、
   （１）前記の判定する段階が、前記一タイプの状態情報が前記第２メモリに存在しないことを判定した場合、又は（２）前記の判定する段階が、前記一タイプの状態情報が前記第２メモリに存在することを判定し、前記一タイプの状態情報の優先順位が、前記第２メモリに記憶された同じタイプの状態情報の優先順位より大きい場合、前記モニタリング装置が、前記状態情報を得るために前記プロトコルオブジェクトに含まれる前記被モニタリング装置から前記一タイプの状態情報を抽出するためのコンフィグレーション情報と前記の選択された通信プロトコルとを用いて、前記被モニタリング装置から前記一タイプの状態情報を抽出する段階とを含むことを特徴とするコンピュータプログラム。

Images