JP4557655B2 - マルチプロトコル遠隔監視システム内のネットワーク装置から情報を抽出するための方法、システム及びコンピュータプログラム - Google Patents

Description

本発明は、ネットワークに接続された装置を監視することに関する。特に、複数のプロトコルを用いてネットワーク接続された装置を遠隔監視する方法、システム及びコンピュータプログラム（プロダクト）に関連する。

一般に知られているように、コンピュータシステムはハードウエアとソフトウエアを含む。ソフトウエアは命令のリストを含み、そのリストは、コンピュータシステムを構成するハードウエア要素を動作させ及び管理するように作成される。一般に、コンピュータシステムは、互いにインターフェースをとり合う様々なハードウエア要素／装置を含む。コンピュータシステムは、スタンドアローン型でもネットワーク型でもよい。ネットワーク型のコンピュータシステムでは、複数の個々の装置がネットワークに接続され、それら個々の装置間の通信はネットワークを通じて可能になる。

更に、ハードウエア装置を動作させるソフトウエアは、ハードウエア装置間の通信が行われるように構築され、ハードウエア装置が協同的に機能するようにする必要がある。更に、そのような通信を促進するために、ハードウエア装置が監視され、各ハードウエア装置の状態が確認され、各ハードウエア装置が効率的に機能することを保証することも望ましい。

本願に関し、発明者は、複数の個々の装置又は複数のハードウエア装置を制御し、構築し又は監視するハードウエア装置を、「監視装置」（監視する装置）として言及し、その監視装置により制御され、構築され又は監視されるハードウエア装置を、「被監視装置」（監視される装置）として言及することにしている。

ネットワーク上に設けられたハードウエア装置に関し、それらの装置は、保守点検、利用その他の目的のために監視されることが望まれる。しかしながら、ハードウエア装置及びインターフェースに関する製造業者の相違の観点からは、監視する装置が、ネットワークに接続された他の様々な装置と通信することは困難であるかもしれない。そのような不都合は、ネットワーク管理者が、パフォーマンスに関する重要な情報を取得することを及びネットワークに接続された装置の実効性をほとんど妨げる傾向にある。

シンプルネットワーク管理プロトコル（ＳＮＭＰ）は、データ通信ネットワーク、テレコミュニケーションシステムその他のグローバルに到達可能な装置における装置の監視及び管理のための事実上の業界標準である。実際に、コンピュータ及び関連装置を取り扱う機構は、局所的及び広域的なネットワークにおけるそのような装置の各々を中枢的に監視、診断及び構築できることを予定する。ＳＮＭＰはそのようなやりとりを可能にするプロトコルである。

装置がＳＮＭＰの要求に応じるには、その装置にソフトウエアを装備することが望ましく、そのソフトウエアは、ＳＮＭＰ要求を適切に解釈し、その要求により求められる動作を実行し、ＳＮＭＰ応答を作成することを可能にするものである。ＳＮＭＰエージェントソフトウエアは、典型的には、ネットワークエンティティに存するサブシステムソフトウエアモジュールである。システムにより行われるオブジェクトの集合は、一般に管理情報ベース（ＭＩＢ）と呼ばれる。また、ＭＩＢは装置の監視に関する情報を備えたデータベースでもよい。ＭＩＢの具体例は、いくつかの例を挙げると、イーサーネットインターフェースに着目するイーサーネットＭＩＢ；８０２．１Ｄブリッジの管理に対するオブジェクトを決めるブリッジＭＩＢを含む。

プライベートＭＩＢは、有効な鍵（キー）なしには暗号化を解除することが困難な値を含むので、監視する装置にＳＮＭＰを用いることは困難である。ネットワークに接続される様々な装置を監視するＳＮＭＰを用いる企業は、その企業の財産情報として保持される固有の識別子／キーを作成する。多くの場合に、その結果は２進値又は整数値として表示される。従って、ＳＮＭＰを用いて、監視される装置（被監視装置）から受信した結果は、ユーザに包括的な方法で被監視装置のステータスをユーザに与えることが困難である。

更に、ＳＮＭＰを用いて、有効な鍵なしに、又は２進値若しくは整数値として取得した結果の暗号化を解除するためにプライベートＭＩＢにアクセスすることなしに、ある者が、被監視装置に関する詳細な情報を得ることは困難である。更に、所与のプロトコル（例えば、ＳＮＭＰ又はＨＴＴＰ／ＨＴＭＬ）は、時間切れ又はパケット喪失のような様々な理由で不具合をおこすかもしれない。従って、不具合に応じて、連続的に複数のプロトコルを利用して、装置の監視が行われる場合には、複数のプロトコルを用いて所与の装置から引き出されるいくらかの情報は、プロトコル毎に重複するかもしれない。従って、装置からのデータ抽出がそのような状況で適切に管理されないならば、あるプロトコルは他のプロトコルより多くのリソースを要求するので、時間及びメモリの非効率的な利用をもたらす。更に、あるプロトコルを用いる情報抽出は、他のものを利用するよりも少ない処理及びメモリを要するかもしれない。更に、あるプロトコルを通じて得られた情報は、その監視装置にとって、他のプロトコルにより得られたものより有用であるかもしれない。

［関連出願］
本願は、以下の米国特許出願に関連する：
１．西暦２０００年５月１７日付け出願の「Ｍｅｔｈｏｄ ａｎｄ Ｓｙｓｔｅｍ ｏｆ Ｒｅｍｏｔｅ Ｄｉａｇｎｏｓｔｉｃ，Ｃｏｎｔｒｏｌ， ａｎｄ Ｉｎｆｏｒｍａｔｉｏｎ Ｃｏｌｌｅｃｔｉｏｎ ｕｓｉｎｇ ａ Ｄｙｎａｍｉｃ Ｌｉｎｋｅｄ Ｌｉｂｒａｒｙ ｏｆ Ｍｕｌｔｉｐｌｅ Ｆｏｒｍａｔｓ ａｎｄ Ｍｕｌｔｉｐｌｅ Ｐｒｏｔｏｃｏｌｓ ｗｉｔｈ Ｉｎｔｅｌｌｉｇｅｎｔ Ｆｏｒｍａｔｔｅｒ」と題する第０９／４５３，９３７号；
２．西暦２００１年１月９日付出願の「Ｍｅｔｈｏｄ ａｎｄ Ｓｙｓｔｅｍ ｏｆ Ｒｅｍｏｔｅ Ｓｕｐｐｏｒｔ ｏｆ Ｄｅｖｉｃｅ Ｕｓｉｎｇ Ｅｍａｉｌ」と題する第０９／７５６，１２０号；
３．西暦２００１年２月１４日付出願の「Ｍｅｔｈｏｄ ａｎｄ Ｓｙｓｔｅｍ ｏｆ Ｒｅｍｏｔｅ Ｄｉａｇｎｏｓｔｉｃ，Ｃｏｎｔｒｏｌ，ａｎｄ Ｉｎｆｏｒｍａｔｉｏｎ Ｃｏｌｌｅｃｔｉｏｎ ｕｓｉｎｇ ａ Ｄｙｎａｍｉｃ Ｌｉｎｋｅｄ Ｌｉｂｒａｒｙ ｏｆ Ｍｕｌｔｉｐｌｅ Ｆｏｒｍａｔｓ ａｎｄ Ｍｕｌｔｉｐｌｅ Ｐｒｏｔｏｃｏｌｓ ｗｉｔｈ Ｔｈｒｅｅ−Ｌｅｖｅｌ Ｆｏｒｍａｔｔｉｎｇ」と題する第０９／７８２，０６４号；
４．西暦２００１年８月６日付出願の「Ｕｎｉｖｅｒｓａｌ Ｃｏｎｔｒｏｌｌｅｒ ｉｎ Ｔｈｅ Ｗｉｒｅｌｅｓｓ Ｎｅｔｗｏｒｋｅｄ Ｅｎｖｉｒｏｎｍｅｎｔ」と題する第０９／９２１，７０７号；
５．西暦２００１年９月１７日付出願の「Ｍｅｔｈｏｄ ａｎｄ Ｓｙｓｔｅｍ ｏｆ Ｒｅｍｏｔｅ Ｓｕｐｐｏｒｔ ｏｆ Ｄｅｖｉｃｅ Ｕｓｉｎｇ Ｅｍａｉｌ Ｔｈｒｏｕｇｈ Ｄａｔａ Ｔｒａｎｓｆｅｒ Ｍｏｄｕｌｅ」と題する第０９／９５３，３５８号；
６．西暦２００１年９月１７日付出願の「Ｍｅｔｈｏｄ ａｎｄ Ｓｙｓｔｅｍ ｆｏｒ Ｒｅｍｏｔｅ Ｓｕｐｐｏｒｔ ｏｆ Ｄｅｖｉｃｅ ｕｓｉｎｇ Ｅｍａｉｌ ｆｏｒ Ｓｅｎｄｉｎｇ Ｉｎｆｏｒｍａｔｉｏｎ Ｒｅｌａｔｅｄ ｔｏ ａ Ｍｏｎｉｔｏｒｅｄ Ｄｅｖｉｃｅ」と題する第０９／９５３，３５９号；
７．西暦２００１年１０月１５日付出願の「Ｍｅｔｈｏｄ ａｎｄ Ｓｙｓｔｅｍ ｆｏｒ Ｒｅｍｏｔｅ Ｓｕｐｐｏｒｔ ｏｆ Ｄｅｖｉｃｅ Ｕｓｉｎｇ Ｅｍａｉｌ Ｂａｓｅｄ Ｕｐｏｎ Ｐｏｐ３ Ｗｉｔｈ Ｄｅｃｒｙｐｔｉｏｎ Ｃａｐａｂｉｌｉｔｙ Ｔｈｒｏｕｇｈ Ｖｉｒｔｕａｌ Ｆｕｎｃｔｉｏｎ」と題する第０９／９７５，９３５号；
８．西暦２００２年２月１１日付出願の「Ｍｅｔｈｏｄ ａｎｄ Ａｐｐａｒａｔｕｓ Ｕｔｉｌｉｚｉｎｇ Ｃｏｍｍｕｎｉｃａｔｉｏｎ Ｍｅａｎｓ Ｈｉｅｒａｒｃｈｙ ｔｏ Ｃｏｎｆｉｇｕｒｅ ｏｒ Ｍｏｎｉｔｏｒ ａｎ Ｉｎｔｅｒｆａｃｅ Ｄｅｖｉｃｅ」と題する第１０／０６８，８６１号；
９．西暦２００２年５月１３日付出願の「Ｖｅｒｉｆｉｃａｔｉｏｎ Ｓｃｈｅｍｅ ｆｏｒ Ｅｍａｉｌ Ｍｅｓｓａｇｅ Ｃｏｎｔａｉｎｉｎｇ Ｉｎｆｏｒｍａｔｉｏｎ Ａｂｏｕｔ Ｒｅｍｏｔｅｌｙ Ｍｏｎｉｔｏｒｅｄ Ｄｅｖｉｃｅｓ」と題する第１０／１４２，９８９号；
１０．西暦２００２年５月１３日付出願の「Ｍｅｔｈｏｄ ｆｏｒ Ｓｃｒａｍｂｌｉｎｇ Ｉｎｆｏｒｍａｔｉｏｎ Ｉｎｆｏｒｍａｔｉｏｎ ａｂｏｕｔ Ｍｅｔｗｏｒｋ Ｄｅｖｉｃｅｓ Ｔｈａｔ ｉｓ Ｐｌａｃｅｄ ｉｎ Ｅｍａｉｌ Ｍｅｓｓａｇｅ」と題する第１０／１４２，９９２号；
１１．西暦２００２年５月３１日付出願の「Ｍｅｔｈｏｄ ａｎｄ Ａｐｐａｒａｔｕｓ ｆｏｒ Ｍｏｄｉｆｙｉｎｇ Ｒｅｍｏｔｅ Ｄｅｖｉｃｅｓ Ｍｏｎｉｔｏｒｅｄ ｂｙ ａ Ｍｏｎｉｔｏｒｉｎｇ Ｓｙｓｔｅｍ」と題する第１０／１５７，９０３号；
１２．西暦２００２年６月５日付出願の「Ｍｅｔｈｏｄ ａｎｄ Ｓｙｓｔｅｍ ｔｏ Ｕｓｅ ＨＴＴＰ ａｎｄ Ｈｔｍｌ／Ｘｍｌ ｆｏｒ Ｍｏｎｉｔｏｒｉｎｇ ｔｈｅ Ｄｅｖｉｃｅｓ」と題する第１０／１６２，４０２号；
１３．出願番号０９／５７５，７０２の継続である西暦２００２年６月１３日付出願の「Ｍｅｔｈｏｄ ａｎｄ Ｓｙｓｔｅｍ ｏｆ Ｒｅｍｏｔｅ Ｐｏｓｉｔｉｏｎ Ｒｅｐｏｒｔｉｎｇ Ｄｅｖｉｃｅ」と題する第１０／１６７，４９７号（米国特許番号第６，４２１，６０８号）；
１４．西暦２００２年８月２２日付出願の「Ｍｅｔｈｏｄ ａｎｄ Ｓｙｓｔｅｍ ｆｏｒ Ｍｏｎｉｔｏｒｉｎｇ Ｎｅｔｗｏｒｋ Ｃｏｎｎｅｃｔｅｄ Ｄｅｖｉｃｅｓ ｗｉｔｈ Ｍｕｌｔｉｐｌｅ Ｐｒｏｔｏｃｏｌｓ」と題する第１０／２２５，２９０号；
１５．西暦２００２年１２月２６日付出願の「Ｍｅｔｈｏｄ ｏｆ Ａｃｃｅｓｓｉｎｇ Ｉｎｆｏｒｍａｔｉｏｎ ｆｒｏｍ Ｄａｔａｂａｓｅ ｔｏ ｂｅ ｕｓｅｄ ｔｏ Ｏｂｔａｉｎ Ｓｔａｔｕｓ Ｉｎｆｏｒｍａｔｉｏｎ ｆｒｏｍ ｔｈｅ Ｗｅｂ Ｐａｇｅｓ ｏｆ Ｒｅｍｏｔｅｌｙ Ｍｏｎｉｔｏｒｅｄ Ｄｅｖｉｃｅｓ」と題する第１０／３２８，００３号；
１６．西暦２００２年１２月２６日付出願の「Ｍｅｔｈｏｄ ｏｆ ｕｓｉｎｇ Ｉｎｔｅｒｎａｌ Ｓｔｒｕｃｔｕｒｅ ｔｏ Ｓｔｏｒｅ Ｄａｔａｂａｓｅ Ｉｎｆｏｒｍａｔｉｏｎ ｆｏｒ Ｍｕｌｔｉｐｌｅ Ｖｅｎｄｏｒ ａｎｄ Ｍｏｄｅｌ Ｓｕｐｐｏｒｔ ｆｏｒ Ｒｅｍｏｔｅｌｙ Ｍｏｎｉｔｏｒｅｄ Ｄｅｖｉｃｅｓ」と題する第１０／３２８，００８号；
１７．西暦２００２年１２月２６日付出願の「Ｍｅｔｈｏｄ ｏｆ ｕｓｉｎｇ Ｖｅｃｔｏｒｓ ｏｆ Ｓｔｒｕｃｔｕｒｅ ｆｏｒ Ｅｘｔｒａｃｔｉｎｇ Ｉｎｆｏｒｍａｔｉｏｎ ｆｒｏｍ ｔｈｅ Ｗｅｂ Ｐａｇｅｓ ｏｆ Ｒｅｍｏｔｅｌｙ Ｍｏｎｉｔｏｒｅｄ Ｄｅｖｉｃｅｓ」と題する第１０／３２８，０２６号；
１８．西暦２００３年２月２６日付出願の「Ｍｅｔｈｏｄ ａｎｄ Ｓｙｓｔｅｍ ｆｏｒ Ｍｏｎｉｔｏｒｉｎｇ Ｎｅｔｗｏｒｋ Ｃｏｎｎｅｃｔｅｄ Ｄｅｖｉｃｅｓ ｗｉｔｈ Ｍｕｌｔｉｐｌｅ Ｐｒｏｔｏｃｏｌｓ」と題する第１０／３７２，９３９号；
１９．西暦２００３年６月１３日付出願の「Ｍｅｔｈｏｄ ｆｏｒ Ｅｆｆｉｃｉｅｎｔｌｙ Ｓｔｏｒｉｎｇ Ｉｎｆｏｒｍａｔｉｏｎ ｕｓｅｄ ｔｏ Ｅｘｔｒａｃｔ Ｓｔａｔｕｓ Ｉｎｆｏｒｍａｔｉｏｎ ｆｒｏｍ ａ Ｄｅｖｉｃｅ Ｃｏｕｐｌｅｄ ｔｏ ａ Ｎｅｔｗｏｒｋ ｉｎ ａ Ｍｕｌｔｉ−Ｐｒｏｔｏｃｏｌ Ｒｅｍｏｔｅ Ｍｏｎｉｔｏｒｉｎｇ Ｓｙｓｔｅｍ」と題する第１０／４６０，１５０号；
２０．西暦２００３年６月１３日付出願の「Ｍｅｔｈｏｄ ｆｏｒ Ｅｆｆｉｃｉｅｎｔｌｙ Ｅｘｔｒａｃｔｉｎｇ Ｓｔａｔｕｓ Ｉｎｆｏｒｍａｔｉｏｎ Ｒｅｌａｔｅｄ ｔｏ ａ Ｄｅｖｉｃｅ Ｃｏｕｐｌｅｄ ｔｏ ａ Ｎｅｔｗｏｒｋ ｉｎ ａ Ｍｕｌｔｉ−Ｐｒｏｔｏｃｏｌ Ｒｅｍｏｔｅ Ｍｏｎｉｔｏｒｉｎｇ Ｓｙｓｔｅｍ」と題する第１０／４６０，１５１号；
２１．西暦２００３年６月１３日付出願の「Ｍｅｔｈｏｄ ｆｏｒ Ｐａｒｓｉｎｇ ａｎ Ｉｎｆｏｒｍａｔｉｏｎ Ｓｔｒｉｎｇ ｔｏ Ｅｘｔｒａｃｔ Ｒｅｑｕｅｓｔｅｄ Ｉｎｆｏｒｍａｔｉｏｎ Ｒｅｒａｔｅｄ ｔｏ ａ Ｄｅｖｉｃｅ Ｃｏｕｐｌｅｄ ｔｏ ａ Ｎｅｔｗｏｒｋ ｉｎ ａ Ｍｕｌｔｉ−Ｐｒｏｔｏｃｏｌ Ｒｅｍｏｔｅ Ｍｏｎｉｔｏｒｉｎｇ Ｓｙｓｔｅｍ」と題する第１０／４６０，４０４号；及び
２２．西暦２００３年６月１３日付出願の「Ｍｅｔｈｏｄ ａｎｄ Ｅｘｔｒａｃｔｉｎｇ Ｖｅｎｄｏｒ ａｎｄ Ｍｏｄｅｌ Ｉｎｆｏｒｍａｔｉｏｎ ｉｎ ａ Ｍｕｌｔｉ−Ｐｒｏｔｏｃｏｌ Ｒｅｍｏｔｅ Ｍｏｎｉｔｏｒｉｎｇ Ｓｙｓｔｅｍ」と題する第１０／４６０，４０８号。

上記米国特許及び米国特許出願各々の開示内容は、本願の参考に供せられる。

本発明は、以下の参考文献の著者及び年度により指定される文献により参照及び説明される様々な技術を利用することを含む。以下に列挙される各文献の内容は本願の参考に供せられる。
Ｇｌｏｄｆａｒ，Ｃ．，Ｔｈｅ ＳＧＭＬ Ｈａｎｄｂｏｏｋ，Ｃｌａｒｅｎｄｏｎ Ｐｒｅｓｓ（１９９０） Ｃａｓｔｒｏ，Ｅ．，ＨＴＭＬ ｆｏｒ ｔｈｅ Ｗｏｒｌｄ Ｗｉｄｅ Ｗｅｂ，Ｐｅａｃｈｐｉｔ Ｐｒｅｓｓ，Ｂｅｒｋｅｌｅｙ（１９９６） Ｍｅｇｇｉｎｓｏｎ，Ｄ．，Ｓｔｒｕｃｔｕｒｉｎｇ ＸＭＬ Ｄｏｃｕｍｅｎｔｓ，Ｐｒｅｎｔｉｃｅ Ｈａｌｌ，ＮＪ（１９９８）

本発明の課題は、ネットワークに接続された装置の監視を可能にすることで、上述した問題に対処するシステム及び方法を得ることである。従って、ネットワークに通信可能に接続された個々の装置の中の装置を監視する方法が説明される。

本方法は、ハードウエアアクセスモジュールを通じて第１データベースにアクセスすることを含み、その第１データベースは複数の通信プロトコルをサポートするように構築される。製造業者や、被監視装置のモデル情報のような様々な情報を得るために、第１データベースは、複数の通信プロトコルで使用される情報と共に格納される。通信プロトコルは、複数の通信プロトコルの中から選択され、選択された通信プロトコルは被監視装置からステータス情報を受けるように構築される。本方法は、更に、第１データベースから選択した通信プロトコル及び情報を用いて被監視装置にアクセスし、アクセスした装置からステータス情報を受信し、受信したステータス情報を第２データベース（装置ＯＤＢＣ）に格納する。

他の態様では、本発明は、ネットワークに通信可能に接続された個々の装置の中の装置を監視する方法を与える。複数の通信プロトコルは、被監視装置から情報を検索するために使用されてもよい。例えば、ＳＮＭＰプロトコルは被監視装置にアクセスするために最初に選択され、ＳＮＭＰプロトコルを用いて効率的に検索されるように構築された装置情報が得られる。以後に、その装置が付加的なプロトコルをサポートする場合に、ＨＴＴＰ及びＦＴＰプロトコルが情報を得るために選択され、その情報は、ＳＮＭＰプロトコルを用いて効率的な検索をすることができないものである。プロトコルの選択は、データベースに格納されたサポート情報に関連してプロトコルマネジャにより実行される。

本発明では、監視システムは、例えばＬＡＮ又はＷＡＮのようなネットワークに接続された少なくとも１つの装置（被監視装置）の監視を可能にする。被監視装置は固有のＩＰアドレスを有するように構築される。被監視装置に割り当てられたＩＰアドレス、及び被監視装置に関するベンダ／製造業者の詳細は、データベースに格納される。ネットワークを操作し、装置を調べることで、装置のＩＰアドレスを取得することができる。そのような方法は既知である。従って、監視される装置のＩＰアドレスは既に取得され、データベースに格納されていることが想定される。

本発明は、被監視装置から受信したＨＴＭＬ情報から、必要な情報をどのようにして抽出するかを述べる。（ＩＰアドレス及び指定されたポートを通じて）被監視装置のウェブページ場所が一旦アクセスされると、被監視装置に対応する特定のウェブページが表示される。ウェブページ内の情報は、キー及び値のペアの形式で存在する。例えば、トナーレベルは、カラープリンタのウェブページで「黒１００％」のように示されてもよい。ＨＴＭＬ／ＸＭＬパーサは、ウェブページ内の情報から、必要な情報を引き出す際に、ページを分解するために使用される。ＨＴＭＬ／ＸＭＬパーサを用いてウェブページから抽出された必要な情報及びパラメータ値は、装置ＯＤＢＣデータベースに格納される。

本発明の一態様では、個々の装置の中の装置に接続されたネットワークを監視する方法が述べられる。本方法は、ハードウエアアクセスモジュールを介して第１データベースにアクセスすることを含み、第１データベースは複数の通信プロトコルをサポートするよう構築される。被監視装置に関する製造業者及びモデル情報を含む様々な情報を判別するために、第１データベースは複数の通信プロトコルにより使用される情報と共に格納される。複数の通信プロトコルの中から通信プロトコルが選択され、選択された通信プロトコルは、ステータス情報を含む様々な情報を被監視装置から受信するために使用される。本方法は、更に、第１データベースから選択した通信プロトコル及び情報を用いて被監視装置にアクセスし、アクセスした装置からステータス情報を受信し、受信したステータス情報を第２データベースに格納する。

本発明は、また、被監視装置の様々なベンダ及び装置モデルを判別し、それらは上述されるようにして監視システムによりサポートされる。被監視装置の様々なベンダは、ベンダ固有の方法で被監視装置に関する情報を与えるので、本発明は、被監視装置の動作状態を決定するために、被監視装置のベンダ及びモデルの判別を可能にする。

本発明の一態様によれば、ネットワークに通信可能に接続された個々の装置の中の被監視装置にアクセスするために、複数の通信プロトコルに使用されるよう構築された情報を格納する方法、システム及びコンピュータプログラムプロダクトが与えられ、それらは：（１）装置によりサポートされる少なくとも１つの通信プロトコルを用いて装置にアクセスするために第１メモリから情報を抽出すること；（２）第１メモリから抽出した、装置にアクセスするための情報を第２メモリに格納すること；（３）複数の通信プロトコルの中から通信プロトコルを選択すること；及び（４）選択された通信プロトコル及び第１メモリから抽出され第２メモリに格納された情報を用いて装置にアクセスすることから成る。

本発明の一態様によれば、ネットワークに通信可能に接続された個々の装置の中の被監視装置に関連するステータス情報を抽出するために、複数の通信プロトコルに使用されるよう構築された情報を格納する方法、システム及びコンピュータプログラムプロダクトが与えられ、それらは：（１）複数の通信プロトコルを用いて、ステータス情報を抽出するためのサポート情報を第１メモリから抽出すること；（２）第１メモリから取得した、複数の通信プロトコルを用いて装置にアクセスするための情報を第２メモリに格納すること；（３）複数の通信プロトコルの中から通信プロトコルを選択すること；及び（４）ステータス情報を抽出するために、選択された通信プロトコル及び第２メモリに格納された情報を用いて装置にアクセスすることから成り、そのステータス情報は、抽象的なソフトウエアクラスに関連する仮想的なインターフェース機能を用いて抽出され、仮想的なインターフェース機能は複数の通信プロトコルの各々に共通である。

添付図面に関して以下の詳細な説明を参照することで、より良く理解されるのと同様に、本発明の更に完全な認識及びそれに附随する多くの利点が得られることは明白であろう。

図１は、装置の動作を監視し、診断し及び制御する様々な装置及びコンピュータを含む概略図である。特に、図１は、コンピュータワークステーション１７，１８，２０，２２に接続されたローカルエリアネットワーク（ＬＡＮ）のような第１ネットワーク１６を含んでいる。ワークステーションは、例えばパーソナルコンピュータ装置、ユニックス形式のコンピュータ、リナックス形式のコンピュータ又はアップルマッキントッシュを含むいかなるタイプのコンピュータでもよい。また、ネットワーク１６には、ディジタル画像形成装置２４、ファクシミリ装置２８及びプリンタ３２が接続されている。当業者に理解されるように、ディジタル複写機／プリンタ２４及びファクシミリ装置２８の２以上の素子が、一体的な「画像形成装置」に組み合わせられてもよい。例えば、複写機／プリンタ２４、ファクシミリ装置２８、プリンタ３２及びワークステーション１７，１８，２０，２２は、機器又は被監視装置と呼ばれてもよい。ある態様では、１以上のワークステーションが業務用オフィス機器に転換される。更に、いかなるネットワーク業務用オフィス機器／装置もネットワーク１６に取り付けることができる。いかなるワークステーション１７，１８，２０，２２及びオフィス機器２７も、ネットワーク１６上で被監視装置をポーリングし、収集したデータを監視装置に送信する中間的な監視装置として機能することが可能である。

そのような業務用オフィス機器の一例は、リコーコーポレーション（登録商標）のイーキャビネット（ｅＣａｂｉｎｅｔ）（登録商標）である。また、（不図示の）ファクシミリサーバは、ネットワーク１６に接続されてもよく、電話機、有線又は無線の接続を有してもよい。ネットワーク１６に接続されることに加えて、ディジタル複写機／プリンタ２４、ファクシミリ装置２８及びプリンタ３２の各々も、通常の電話機及び／又は有線及び／又は無線の接続２６，３０，３４をそれぞれ含んでもよい。以下に説明されるように、被監視装置２４，２８，３２は、例えばネットワーク１６を介するインターネットを通じて又は直接的な電話、有線又は無線の接続によって、監視装置とも言及される遠隔的な監視、診断及び制御ステーションと通信する。

他の業務環境では、被監視装置は、多機能画像処理装置、スキャナ、プロジェクタ、会議システム及びシュレッダのような装置を含んでもよい。他のアプリケーションでは、ネットワーク１６はホームネットワークでもよく、そこでは被監視装置は計測器（電気、ガス、水道）又は以下のような機器である：電子レンジオーブン、洗濯機、乾燥機、食器洗浄機、家庭娯楽システム、冷蔵庫、炊飯器、ヒーター、空調機、温水器、セキュリティカメラ。

図１では、広域ネットワーク（ＷＡＮ）（例えば、インターネット又はその代替物）が、全体的に１０として示される。ＷＡＮ１０は、私的なＷＡＮ、公的なＷＡＮ又はハイブリッド形式とすることができる。ＷＡＮ１０は、１２Ａ−１２Ｉにより示される複数の相互接続されたコンピュータ及びルータを含む。ＷＡＮにおける通信方法は、ｗｗｗ．ｉｅｔｆ．ｏｒｇ／ｒｆｃ．ｈｔｍｌのインターネットエンジニアリングフォース（ＩＥＴＦ）から入手可能な一連の要請コメント（ＲＦＣ）ドキュメントにより知られており、以下のものを含む：“Ｓｉｍｐｌｅ Ｍａｉｌ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ”と題するＲＦＣ８２１；“Ｓｔａｎｄａｒｄ ｆｏｒ ｔｈｅ Ｆｏｒｍａｔ ｏｆ ＡＲＰＡ Ｉｎｔｅｒｎｅｔ Ｔｅｘｔ Ｍｅｓｓａｇｅ”と題するＲＦＣ８２２；“Ｆｉｌｅ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ（ＦＴＰ）”と題するＲＦＣ９５９；“Ｍｕｌｔｉｐｕｒｐｏｓｅ Ｉｎｔｅｒｎｅｔ Ｍａｉｌ Ｅｘｔｅｎｓｉｏｎｓ（ＭＩＭＥ）Ｐａｒｔ Ｏｎｅ”と題するＲＦＣ２０４５；“Ａｎ Ｅｘｔｅｎｓｉｂｌｅ Ｍｅｓｓａｇｅ Ｆｏｒｍａｔ ｆｏｒ Ｄｅｌｉｖｅｒｙ Ｓｔａｔｕｓ Ｎｏｔｉｆｉｃａｔｉｏｎｓ”と題するＲＦＣ１８９４；“Ｐｏｓｔ Ｏｆｆｉｃｅ Ｐｒｏｔｏｃｏｌ−Ｖｅｒｓｉｏｎ ３”と題するＲＦＣ１９３９；“Ｈｙｐｅｒｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ−ＨＴＴＰ／１．１”と題するＲＦＣ２０６８；及び“Ａｎ Ｅｘｔｅｎｓｉｂｌｅ Ｍｅｓｓａｇｅ Ｆｏｒｍａｔ ｆｏｒ Ｍｅｓｓａｇｅ Ｄｉｓｐｏｓｉｔｉｏｎ Ｎｏｔｉｆｉｃａｔｉｏｎｓ”と題するＲＦＣ２２９８。

伝送制御プロトコル／インターネットプロトコル（ＴＣＰ／ＩＰ）に関する通信は、例えば、以下の書籍に記載されており、その全内容は本願の参考に供される：“ＴＣＰ／ＩＰ Ｉｌｌｕｓｔｒａｔｅｄ”，Ｖｏｌ．１，Ｔｈｅ Ｐｒｏｔｏｃｏｌｓ，ｂｙ Ｗ．Ｒ．Ｓｔｅｖｅｓ，ｆｒｏｍ Ａｄｄｉｓｏｎ−Ｗｅｓｌｅｙ Ｐｕｂｌｉｓｈｉｎｇ Ｃｏｍｐａｎｙ，１９９４。“Ｉｎｔｅｒｎｅｔｗｏｒｋｉｎｇ ｗｉｔｈ ＴＣＰ／ＩＰ”ｂｙ Ｃｏｍｅｒ ａｎｄ Ｓｔｅｖｅｎｓの１−３巻の内容も参考に供される。

続いて図１を参照するに、ファイヤウォール５０ＡがＷＡＮ１０及びネットワーク１６の間に接続される。ファイヤウォールは、ファイヤウォールの一方の側の認証されたコンピュータのみが、ファイヤウォールの他方の側のネットワーク、コンピュータ又は個々の部分にアクセスすることを可能にする。ファイヤウォール自体は既知であり、商業的に入手可能な装置及び／又はソフトウエアである（例えば、ゾーンラブ（Ｚｏｎｅ Ｌａｂｓ）によるゾーンアラーム（ＺｏｎｅＡｌａｒｍ））。同様に、ファイヤウォール５０Ｂ，５０ＣはＷＡＮ１０をネットワーク５２及びワークステーション４２からそれぞれ分離する。ファイヤウォールの詳細は、以下の文献に見られる：“Ｆｉｒｅｗａｌｌｓ ａｎｄ Ｉｎｔｅｒｎｅｔ Ｓｅｃｕｒｉｔｙ”ｂｙ Ｗ．Ｒ．Ｃｈｅｓｗｉｃｋ，ａｎｄ Ｓ．Ｍ．Ｂｅｌｌｏｎ，１９９４，ＡｄｄｉｓｏｎＷｅｓｌｅｙ Ｐｕｂｌｉｓｈｉｎｇ； “Ｂｕｉｌｄｉｎｇ Ｉｎｔｅｒｎｅｔ Ｆｉｅｒｅｗａｌｌｓ”ｂｙ Ｄ．Ｂ．Ｃｈａｐｍａｎ ａｎｄ Ｅ．Ｄ．Ｚｗｉｃｋｙ，１９９５，Ｏ’Ｒｅｉｌｌｙ ＆ Ａｓｓｏｃｉａｔｅｓ，Ｉｎｃ．これら２つの参考文献の全内容も本願の参考に供される。

ネットワーク５２は通常のネットワークであり、複数のワークステーション５６，６２，６８，７４を含む。これらのワークステーションは、単一企業における異なる部門（例えば、販売、注文処理、財務、支払請求、マーケティング、製造、設計技術、及び顧客サービス部）に関する分散形式に設けられてもよい。ネットワーク５２を通じて接続されるワークステーションに加えて、ネットワーク５２に直接的には接続されていないワークステーション４２も設けられる。ワークステーション４２に接続されたディスク４６に格納されたデータベース内の情報は、ＷＡＮ１０における適切な暗号化及びプロトコルを用いて、ネットワーク５２に直接的に接続されたワークステーションと共用されてもよい。また、ワークステーション４２は、電話回線及び／又はケーブルネットワーク及び／又は無線ネットワーク４４と直接的な接続を有し、ディスク４６内のデータベースは電話回線、ケーブルネットワーク又は無線ネットワーク４４を通じてアクセスされてもよい。本発明により使用されるケーブルネットワークは、テレビジョン番組を搬送するのに一般的に使用されるケーブルネットワーク、コンピュータ等に一般的に使用される高速ディジタルデータ通信を可能にするケーブル、その他の任意の所望のケーブル形式を用いて実現されてもよい。

別の例では、ワークステーション４２は、ラップトップコンピュータ、ＰＤＡ、パームトップコンピュータ、又はネットワーク通信可能なセルラ電話機とすることができる。これらの装置は、ディスク４６に格納されたデータベース内の情報にアクセスするのに使用される。

ディジタル複写機／プリンタ２４、オフィス機器２７、ファクシミリ装置２８又はプリンタ３２に関する情報は、ディスク４６，５４，５８，６４，７０，７６内の１以上のデータベースにそれぞれ格納されてもよい。既存のデータベースには、（１）マイクロソフト、ＩＢＭ、オラクル及びサイベースによるＳＱＬデータベース；（２）他の関連するデータベース；及び（３）関連しないデータベース（オブジェクティビティ・ＪＹＤソフトウエアエンジニアリング・オリエントテクノロジによるオブジェクト指向データベース等）が含まれる。販売、注文処理、財務、請求、顧客サービス、マーケティング、製造及び技術の部門の各々は、それら自身のデータベースを所有してもよいし、１以上のデータベースを共用してもよい。データベースを格納するのに使用されるディスクの各々は、ハードディスク又は光ディスクのような不揮発性メモリである。或いは、データベースは、ソリッドステート及び／又は半導体メモリ装置を含むいかなる貯蔵装置に格納されてもよい。例えば、ディスク６４はマーケティングのデータベースと共に格納され、ディスク５８は製造のデータベースと供に格納され、ディスク７０は技術のデータベースと供に格納され、ディスク７６は顧客サービスのデータベースと共に格納されてもよい。或いは、ディスク５４，４６は１以上のデータベースと共に格納されてもよい。

ＷＡＮ１０に接続されるワークステーション５６，６２，６８，７４，４２に加えて、これらのワークステーションも、監視、診断及び／又は制御される機器／装置に対するセキュア接続を与える電話回線、ケーブル又は無線ネットワークへの接続を含んでもよい。更に、通信媒体の１つが適切に動作していない場合に、他のものが通信用のバックアップとして自動的に使用されてもよい。

本発明の特徴は、機器を診断及び制御する機器及びコンピュータ／監視システム間の通信（例えば、ここでは電子メールとも呼ばれるインターネット電子メール）又は伝送に関する「格納及び転送」モードを利用することである。或いは、伝送されるメッセージは、ＦＴＰ及びハイパーテキスト転送プロトコル（ＨＴＴＰ）のような（例えば最終的な宛先へのソケット接続を利用する）直接的なエンドトゥエンド通信を行う通信モードを利用して処理されてもよい。

図２は図１に示されたディジタル複写機／プリンタ２４の機械的レイアウトを示す。図２では、１０１はスキャナ用のファンであり、１０２はレーザプリンタと共に使用されるポリゴンミラーであり、１０３は（不図示の）レーザからの光を平行化するのに使用されるＦθレンズである。参照番号１０４はスキャナからの光を検出するセンサを示す。参照番号１０５はセンサ１０４上のスキャナからの光を集光するレンズを示し、参照番号１０６は、光電導性ドラム１３２における画像を消去するのに使用される消光ランプ（ｑｕｅｎｃｈｉｎｇ ｌａｍｐ）を示す。帯電コロナ部１０７及び現像ローラ１０８も存在する。参照番号１０９は、スキャンされた書類を示すのに使用されるランプを示し、要素１１０，１１１，１１２はセンサ１０４に光を反射させるミラーを示す。ドラムミラー１１３は、ポリゴンミラー１０２から発する光を光電導性ドラム１３２に反射させるよう用意される。ファン１１４はディジタル画像形成装置の帯電領域を冷却するのに使用され、第１の用紙供給ローラ１１５は第１の要しカセット１１７から用紙を供給するために使用され、参照番号１１６は手動供給テーブルを示す。同様に、第２の用紙供給ローラ１１８は第２のカセット１１９に関連して使用される。参照番号１２０は中継ローラを示し、１２１は位置決めローラを示し、１２２は画像密度センサを示し、１２３は伝送／分離コロナ部を示す。参照番号１２４はクリーニング部を示し、１２５は排気ファンを示し、１２６は伝送ベルトを示し、１２７は加圧ローラを示し、１２８は排出ローラを示す。ホットローラ１２９はトナーを用紙上に固定させるために使用され、１３０は排気ファンを示し、メインモータ１３１はディジタル複写機／プリンタ２４を駆動するのに使用される。

図３は図２のディジタル複写機／プリンタ２４の電子素子を示すブロック図であり、ＣＰＵ１６０は本装置のコントローラとして動作するマイクロプロセッサである。ランダムアクセスメモリ（ＲＡＭ）１６２は、ディジタル複写機／プリンタ２４の動作パラメータを含む動的に蓄える情報を格納する。不揮発性メモリ（例えば、読み取り専用メモリ（ＲＯＭ）１６４又はフラッシュメモリ）は、複写機／プリンタ２４を記述する、静的な状態データ（例えば、モデル名、モデル番号、装置の製造番号及びデフォルトパラメータ）と共にディジタル画像形成装置を実行させるプログラムコードを格納する。

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

ローカル接続インターフェース１７１は、ＲＳ２３２、並列プリンタポート、ＵＳＢ及びＩＥＥＥ１３９４のようなローカルポートを介する接続部である。ファイヤワイヤ（ＩＥＥＥ１３９４）については、以下の文献に記載されており、その全内容が本願の参考に供される：Ｗｉｃｋｅｌｇｒｅｎ，Ｉ．，“Ｔｈｅ Ｆａｃｔｓ Ａｂｏｕｔ ＦｉｒｅＷｉｒｅ”，ＩＥＥＥ Ｓｐｅｃｔｒｕｍ，Ａｐｒｉｌ １９９７，Ｖｏｌ．３４，Ｎｕｍｂｅｒ ４，ｐｐ．１９−２５。好ましくは、誤り検出及び再送のような「信頼性のある」通信プロトコルが使用される。

格納インターフェース１７６は格納装置をシステムバス１８６に接続する。例えば、格納装置はフラッシュメモリ１７８を含み、このメモリは既存の電気的に消去可能プログラム可能な読み取り専用メモリ（ＥＥＰＲＯＭ）及びディスク１８２で置き換えることができる。ディスク１８２は、ハードディスク、光ディスク及び／又はフロッピディスクドライブであってもよい。付加的なメモリ装置が接続部１８０を通じてディジタル複写機／プリンタ２４に接続されてもよい。フラッシュメモリ１７８は、装置２４の寿命の中で頻繁には変化しない、ディジタル複写機／プリンタ２４のパラメータを記述する準静的な状態データを格納するために使用される。そのようなパラメータは、例えば、ディジタル画像形成装置のオプション及びコンフィギュレーションを含む。オプションインターフェース１８４は、外部インターフェースのような付加的なハードウエアが、ディジタル複写機／プリンタ２４に接続されることを可能にする。クロック／タイマ１８７は、時間及びデータの双方を追跡すること及び経過時間を測定することに使用される。

また、図３はディジタル複写機／プリンタ２４を形成する様々な部分も示す。参照番号２０２はソーターを示し、ディジタル複写機／プリンタ２４の出力を並べ換えるのに使用されるセンサ及びアクチュエータを含む。デュプレクサ２００は２重の動作を実行可能にする。デュプレクサ２００は通常のセンサ及びアクチュエータを含む。大容量トレイ部１９８は、用紙トレイが大量の用紙を保持することを可能にするよう用意される。デュプレクサ２００と同様に、トレイ部１９８は通常のセンサ及びアクチュエータも含む。

用紙供給コントローラ１９６は、ディジタル画像形成装置へ及びそれを介する用紙を供給する動作を制御するのに使用される。スキャナ１９４は、ディジタル画像形成装置内に画像をスキャンするために使用され、光線、鏡等のような既存の走査用素子を含む。更に、スキャナセンサは、スキャナがホームポジションにあることを判定するためのホーム位置センサを使用され、ランプサーミスタは走査用ランプの適切な動作を保証するために使用される。プリンタ／画像処理部１９２は、ディジタル画像形成装置の出力を印刷し、従来のレーザ印刷機構、トナーセンサ及び画像密度センサを含む。定着機構（フューザ）１９０は、高温ローラを用いて用紙にトナーを定着させるために使用され、排出センサ、フューザ１９０がオーバーヒートしないことを保証するためのサーミスタ及びオイルセンサを含む。更に、ディジタル画像形成装置に付加することの可能な自動書類フィーダ、異種のソーター／コレーターその他の要素のような、ディジタル画像形成装置の選択的な要素に接続するためのオプショナル装置インターフェースがある。他の要素は、装置の位置を判別可能なＧＰＳ装置を含む。

図４は、マルチポートネットワークインターフェース１６６の詳細を示す。ディジタル画像形成装置は、トークンリングインターフェース２２０、ケーブルに対して高速接続を行うケーブルモデム部２２２、電話回線１６８Ａに接続する既存の電話インターフェース２２４、無線インターフェース２２８又はＬＡＮ１７０に接続するイーサーネットインターフェース２３０を通じて外部装置と通信する。他のインターフェースは、限定ではないが、ディジタル加入者回線（ＤＳＬ）（オリジナルＤＳＬ、集中ＤＳＬ及び非対称ＤＳＬ）を含んでもよい。ローカルエリアネットワーク及び電話回線の双方に接続する単独の装置は、インテルから商業的に入手可能であり、インテルプロ１０／１００＋モデムとして知られている。

ＣＰＵ若しくは他のマイクロプロセッサ又は回路は、ディジタル画像形成装置の各センサの状態を監視するための監視プロセスを実行し、ディジタル画像形成装置を制御及び操作するのに使用されるコード命令を実行するためにシーケンス処理が実行される。更に、（１）ディジタル画像形成装置の動作全体を制御するよう実行される中央システム制御プロセス及び（２）ディジタル画像形成装置に接続される外部装置との安全な通信を保証するために使用される通信プロセスがある。システム制御プロセスは、静的な状態メモリ（例えば、図３のＲＯＭ１６４）、準静的なメモリ（例えば、フラッシュメモリ１７８又はディスク１８２）又は動的な状態メモリ（例えば、揮発性又は不揮発性メモリ（例えば、ＲＡＭ１６２，フラッシュメモリ１７８又はディスク１８２））におけるデータ格納を監視及び制御する。更に、スタティック状態メモリは、フラッシュメモリ１７８又はディスク１８２を含む不揮発性メモリのようなＲＯＭ１６４以外の装置でもよい。

上記の説明は、ディジタル画像形成装置に関して記述されたが、本発明は、アナログ複写機、ファクシミリ装置、スキャナ、プリンタ、ファクシミリサーバ、プロジェクタ、会議装置、シュレッダ、他の業務用オフィス装置、業務用オフィス機器その他の機器（例えば、電子レンジオーブン、ＶＣＲ、ＤＶＤ、ディジタルカメラ、セルラ電話機、パームトップコンピュータ）のような他の業務用オフィス機器又は装置に等しく適用可能である。更に、本発明は、格納−及び−転送又は直接接続形式の通信を用いて動作する他の種類の装置を含む。そのような装置は、計測システム（ガス、水道又は電気の計測システムを含む）、自動販売機、又は動作中に監視されること若しくは遠隔的な診断を要する何らかの装置（例えば、自動車、洗濯機、乾燥機）を含む。特定用途の機器及びコンピュータを監視することに加えて、本発明は、制御される及び／又は制御される装置になり得る汎用コンピュータを監視、制御及び診断するのに使用可能である。

図５は、異なる装置及びサブシステムがＷＡＮ１０に接続されている本発明の別のシステム図を示す。しかしながら、これらの装置又はサブシステムの各々を本発明の一部として備える必要性はない。図５に示されるコンピュータ又はサブシステムの各々は、個別的には、本発明の一部である。更に、図１に示される要素は、図５に示されるＷＡＮ１０に接続されてもよい。図５では、イントラネット２６０−１に接続されたファイヤウォール５０−１が示されている。イントラネット２６０−１に接続されたサービス機器２５４がそこに含まれ、或いはデータベース形式で格納されるデータ２５６に接続される。データ２５６は、履歴、パフォーマンス、誤動作及び何らかの他の情報又はコンフィギュレーション情報を含み、他の情報は、被監視装置の動作、不具合又は設定に関する静的な情報を示し、コンフィギュレーション情報は、素子又は選択的な装置が被監視装置に含まれることを示す。サービス機器２５４は、被監視装置がデータを送信することを要求し、被監視装置に関して遠隔制御及び／又は診断検査が行われることを要求する装置又はコンピュータとして実現されてもよい。サービス機器２５４は、いかなる種類の装置として実現されてもよいが、汎用コンピュータのようなコンピュータ装置を用いて実現されることが好ましい。また、サービス機器２５４は、請求、財務、サービス処理、部分的トラッキング及び報告を含む様々なデータベースと共にネットワーク上の複数のコンピュータから構成されてもよい。

図５の他のサブシステムは、ファイヤウォール５０−２、イントラネット２６０−２及びそれに接続されたプリンタ２６２を含む。このサブシステムでは、プリンタ２６２による電子メッセージの送受信機能は（複写機２８６と同様に）、（１）回路、（２）マイクロプロセッサ又は（３）プリンタ２６２内に含まれる又は搭載される他の何らかの種類のハードウエアにより（即ち、別個の汎用コンピュータを用いることなしに）実行される。

他の種類のサブシステムは、アメリカ・オンライン、アースリンク及びニフティサーブのような既知の営利企業を含むいかなるインターネットサービスプロバイダ（ＩＳＰ）であってもよいところのインターネットサービスプロバイダ２６４を利用することを含む。このサブシステムでは、コンピュータ２６６はディジタル又はアナログモデム（例えば、電話回線モデム、ケーブルモデム、非対称ディジタル加入者回線（ＡＤＳＬ）上で使用されるような任意の種類の接続を利用するモデム、フレームリレー通信を利用するモデム、無線周波数モデムのような無線モデム、光ファイバモデム、又は赤外線波を利用する装置）を介してＩＰＳ２６４に接続される。更に、業務用オフィス装置２６８はコンピュータ２６６に接続される。業務用オフィス装置２６８（又は図５に示される他のいかなる装置）に関する代替例として、ディジタル複写機、任意の種類の機器、セキュリティシステム、又は電気、水道若しくはガス使用量のメーターのような計測器その他の説明済みの装置のような別種の装置が監視され又は制御されてもよい。

図５には、ネットワーク２７４に接続されるファイヤウォール５０−３も示されている。ネットワーク２７４は、いかなる種類のコンピュータネットワークとして実現されてもよい（例えば、イーサーネット又はトークンリングネットワーク）。ネットワークを制御するのに使用されるネットワーキングソフトウエアは、ノベル又はマイクロソフトから商業的に入手可能なソフトウエアを含む所望のいかなるネットワークソフトウエアを含む。ネットワーク２７４は、望まれるならば、イントラネットとして実現されてもよい。ネットワーク２７４に接続されるコンピュータ２７２は、業務用オフィス装置２７８から情報を取得すること、並びにネットワークに接続された様々な機器にて生じる問題を示すレポート及びネットワーク２７４に接続される装置の月々の利用報告のような報告を生成することに使用されてもよい。この例では、コンピュータ２７６は業務用オフィス装置２７８及びネットワーク２７４の間に接続される。このコンピュータは、ネットワークからの通信内容を受信し、適切な命令、データその他の情報を業務用オフィス装置２７８に転送する。

業務用オフィス装置２７８及びコンピュータ２７６の間の通信は、限定ではないが、無線周波数接続、電気的接続及び光接続（例えば、赤外線接続又は光ファイバ接続）を含む有線又は無線方式を利用して行ってもよい。同様に、図５に示される様々なネットワーク及びイントラネットの各々は、無線周波数ネットワークのような無線ネットワークの確立を含む何らかの所望の方法を用いて設定される。ここに述べられている無線通信は、スペクトル拡散技術を用いて行ってもよく、スペクトル拡散技術は、（ワールドワイドウェブサイトｗｗｗ．ｂｌｕｅｔｏｏｔｈ．ｃｏｍにて入手可能な）ブルートゥース仕様により開示される周波数ホッピング無線技術のような拡散コード及び周波数ホッピング技術を利用し、これは本願の参考に供せられる。

図５に示される他のサブシステムは、ファイヤウォール５０−４、イントラネット２６０−４、それに接続されるコンピュータ２８２、業務用オフィス機器２８５及び複写機２８６を含む。コンピュータ２８２はレポートを作成し、診断又は制御手順を要求する。これらの診断及び制御手順は、図５に示される又はそれらと共に使用される、業務用オフィス装置２８５及び複写機２８６その他任意の装置に関して行われてもよい。図５は複数のファイヤウォールを示しており、ファイヤウォールは好ましいものであるが、選択的な装備であり、従って本発明はファイヤウォールを用いることなしに使用されてもよい。ネットワーク装置の監視及び制御に関し、２５４に代えていかなるコンピュータ（２６６，２７２又は２８２）を使用することもできる。更に、任意のコンピュータが、ウェブを介して必要な装置情報又は利用度情報を検索してもよい。

図６Ａは、典型的な電子メール交換システムに接続された装置／機器３００を示し、その装置／機器は、要素３０２，３０４，３０６，３０８，３１０，３１２，３１４，３１８を含み、通常の手法で実現されてもよく、上記のスティーブンス（Ｓｔｅｖｅｎｓ）による図２８．１に採用されてもよい。コンピュータインターフェース３０２は、ここに説明されるいかなるアプリケーションユニット又は装置／機器ともインターフェースをとる。装置／機器３００がセンダー（送信側）であることを図６Ａは示すが、送信及び受信する機能は図６Ａにて反転されてもよい。更に、望まれるならば、ユーザは装置／機器３００とインターフェースをとることを全く必要としないかもしれない。コンピュータインターフェース３０２はメールエージェント３０４とやりとりを行う。ユニックス用の普及しているメールエージェントは、エムエイチ（ＭＨ）、バークレーメール、イーエルエム（Ｅｌｍ）及びムッシュ（Ｍｕｓｈ）を含む。オペレーティングシステムのウインドウズファミリ用のメールエージェントは、マイクロソフトアウトルック及びマイクロソフトアウトルックエクスプレスを含む。コンピュータインターフェース３０２の要求の際に、メールエージェント３０４は、送信される電子メールメッセージを作成し、望まれるならば、送信されるそれらのメッセージをキュー３０６内に置く。送信されるメールは、メール転送エージェント（ＭＴＡ）３０８に転送される。ユニックスシステム用の一般的なＭＴＡはセンドメール（Ｓｅｎｄｍａｉｌ）である。典型的には、メッセージ転送エージェント３０８，３１２は、ＴＣＰ／ＩＰ接続３１０を用いて通信内容を交換する。メッセージ転送エージェント３０８及び３１２の間の通信は、いかなるサイズのネットワーク（例えば、ＷＡＮ，ＬＡＮ）で生じてもよいことに留意を要する。更に、メッセージ転送エージェント３０８，３１２はいかなる通信プロトコルを利用してもよい。本発明の一実施例では、図６Ａの要素３０２，３０４は、アプリケーションユニットの利用度を監視するために、ライブラリ内にある。

メッセージ転送エージェント３１２からの電子メールメッセージは、ユーザメールボックス３１４に格納され、メールエージェント３１６に転送され、最終的には、受信端末として機能する端末３１８のユーザに伝送される。

この「ストア・アンド・フォワード（格納及び転送）」プロセスは、送信メールエージェント３０４が、電子メール受領者との直接的な接続が確立されるまで待機しなければならない要請を軽減する。ネットワーク遅延に起因して、その通信は、アプリケーションが非応答である期間のかなりの時間を必要とする。そのような非応答の遅延は、アプリケーションユニットのユーザに、通常的には受け入れられないかもしれない。ストア・アンド・フォワード・プロセスのような電子メールを用いることで、一定期間（例えば、３日間）の間に、不具合後の再送の試行が自動的に行われる。他の実施例では、１以上の別個のスレッドに通信要求を伝送することで、そのアプリケーションは、待機を回避することができる。これらのスレッドは、受信端末３１８との通信を制御することができ、そのアプリケーションはユーザインターフェースに再び応答し始めることができる。ユーザが継続前に通信を完了することを希望する更なる別の実施例では、受信端末との直接的な通信が使用される。そのような直接的な通信は、送信及び受信の端末間のファイヤウォールによって遮断されないいかなるプロトコルも利用可能である。そのようなプロトコルの例は、テルネット、ファイル転送プロトコル（ＦＴＰ）及びハイパーテキスト転送プロトコル（ＨＴＴＰ）を含む。

インターネットのような公のＷＡＮは、一般に、安全であるとは考えられない。従って、メッセージを秘密に維持することが望まれるならば、その公のＷＡＮ（及び多企業プライベートＷＡＮ）で伝送されるメッセージは暗号化可能である。暗号化手法は既知であり、商業的に入手可能であり、本発明に使用されてもよい。例えば、Ｃ＋＋ライブラリ関数、ｃｒｙｐｔ（）は、ユニックスオペレーティングシステムに対する用途に対して、サンマイクロシステムズから入手可能である。暗号化及び暗号解除のソフトウエアパッケージは既知であり、商業的に入手可能であり、これも本発明に使用可能である。そのような１つのパッケージはＰＧＰコーポレーションから入手可能なＰＧＰである。

図６Ａの一般的な構成の代替例として、コンピュータインターフェース３０２、メールエージェント３０４、メールキュー３０６及びメッセージ伝送エージェント３０８として機能する単独のコンピュータが使用されてもよい。図６Ｂに示されるように、装置／機器３００は、メッセージ伝送エージェント３０８を含むコンピュータ３０１に接続される。

図６Ｃには、更なる別の構成が示され、メッセージ伝送エージェント３０８が装置／機器３００の一部として形成される。更に、メッセージ転送エージェント３０８は、ＴＣＰ／ＩＰ接続部３１０によりメッセージ転送エージェント３１２に接続される。図６Ｃの実施例では、装置／機器３００は、電子メール機能に関するＴＣＰ／ＩＰ接続部３１０に直接的に接続される。図６Ｃの１つの利用例は、（例えば、ＲＦＣ２３０５（インターネットメールを利用するファクシミリのシンプルモード）に規定されるような）電子メール機能を有するファクシミリ装置を装置／機器３００として使用することを含む。

図６Ｄは、装置／機器３１０がそれ自身は電子メールを直接的に受信する機能を有しないが、メッセージ転送エージェント３０８及びメールボックス３１４を含むメールサーバ／ＰＯＰ３サーバに対する接続部３１０を有するシステムを示し、装置／機器３００は、受信したメールをメールサーバから検索するＰＯＰ３プロトコルを利用する。

図７はメールを伝送する別の実施例を示し、前述のスティーブンス等の図２８．３によるものである。図７は、各端末で中継システムを有する電子メールシステムを示す。図７の態様は、組織上の１つのシステムがメールハブ（ｍａｉｌ ｈｕｂ）として機能することを可能にする。図７では、２つのメールエージェント３０４，３１６の間に接続された４つのＭＴＡが存在する。これらのＭＴＡは、ローカルＭＴＡ３２２Ａ、中継ＭＴＡ３２８Ａ、中継ＭＴＡ３２８Ｂ及びローカルＭＴＡ３２２Ｄを含む。所望のいかなるメールプロトコルが使用されてもよいが、メールメッセージに使用される本発明に使用されてもよい最も一般的なプロトコルはＳＭＴＰ（シンプルメール転送プロトコル）である。図７では、３２０は送信ホストを示し、送信ホストはコンピュータインターフェース３０２、メールエージェント３０４及びローカルＭＴＡ３２２Ａを含む。装置／機器３００は、送信ホスト３２０に接続される、或いはその中に含まれる。別の例としては、装置／機器３００及びホスト３２０は、ホスト機能が装置／機器３００に組み込まれている１つの装置内に設置可能である。また、他のローカルＭＴＡ３２２Ｂ，３２２Ｃ，３２２Ｅ及び３２２Ｆが含まれてもよい。送信される及び受信されるメールは、中継ＭＴＡ３２８Ａのメールのキュー３０６Ｂ内で待ち並んでもよい。メッセージはＴＣＰ／ＩＰ接続３１０（例えば、インターネット接続、又は他の任意の種類のネットワークによる接続）により転送される。

送信されたメッセージは中継ＭＴＡ３２８Ｂで受信され、望まれるならば、メールのキュー３０６Ｃに格納される。その後メールは受信ホスト３４２のローカルＭＴＡ３２２Ｄに転送される。メールは１以上のユーザメールボックス３１４内に置かれ、以後メールエージェント３１６に転送され、最終的には端末３１８におけるユーザに転送される。望まれるならば、メールはユーザの介在なしに端末に直接的に転送されてもよい。

本発明で使用される様々なコンピュータは、図５のコンピュータ２６６，２７６を含み、図８に示されるように実現されてもよい。更に、本発明に使用される他のいかなるコンピュータも図８に示されるコンピュータと同様に実現されてもよく、望まれるならば、図５のサービス機器２５４，コンピュータ２７２及びコンピュータ２８２を含む。しかしながら、図８に示される全ての要素がこれらのコンピュータの各々に必須ではない。

図８では、コンピュータ３６０はＣＰＵ３６２を含み、ＣＰＵは、インテル、ＡＭＤ、モトローラ、日立及びＮＥＣのような企業から商業的に入手可能なマイクロプロセッサを含むいかなる種類のプロセッサで実現されてもよい。ＲＡＭ３６４のようなワーキングメモリや、無線装置３６８と通信する無線インターフェース３６６等が存在する。インターフェース３６６及び装置３６８間の通信は、いかなる無線媒体（建生場、無線電波又は光波）を利用してもよい。無線電波は、符号分割多重接続（ＣＤＭＡ）通信のようなスペクトル拡散技術により、或いはブルートゥース規格に開示されているような周波数ホッピング技術により利用されてもよい。

コンピュータ３６０はＲＯＭ３７０及びフラッシュメモリ３７１を含むが、他のいかなる種類の不揮発性メモリ（例えば、消去可能プログラム可能ＲＯＭ又はＥＥＰＲＯＭ）が、フラッシュメモリに加えて又はそれに代えて使用されてもよい。入力コントローラ３７２は、キーボード３７４及びマウス３７６に接続される。シリアル装置３８０に接続されたシリアルインターフェースも存在する。更に、パラレルインターフェース３８２が並列化装置３８４に接続され、ユニバーサルシリアルバス（ＵＳＢ）インターフェース３８６がユニバーサルシリアルバス装置３８８に接続され、ＩＥＥＥ１３９４インターフェース３９８に接続される、ファイヤウォール装置と一般に呼ばれるＩＥＥＥ１３９４装置４００も存在する。システムバス３９０はコンピュータ３６０の様々な要素を接続する。ディスクコントローラ３９６は、フロッピディスクドライブ３９４及びハードディスクドライブ３９２に接続される。通信コントローラ４０６は、コンピュータ３６０が、（例えば、電子メールメッセージを送信することで）ネットワーク４０４上で他のコンピュータと通信することを可能にする。Ｉ／Ｏ（入力／出力）コントローラ４０８は、例えばＳＣＳＩ（スモールコンピュータシステムインターフェース）バスを利用して、プリンタ４１０及びハードディスク４１２に接続される。また、ＣＲＴ（陰極線管）４１４に接続されるディスプレイコントローラ４１６も存在するが、液晶ディスプレイ、発光ダイオードディスプレイ、プラズマディスプレイ等を含む他のいかなる種類のディスプレイが使用されてもよい。

図９を参照するに、本発明の実施例によるシステム９００の全体的な概略図が示される。システム９００は、例えば、レーザプリンタ９０８、スキャナ９１０、ネットワーク装置９１２、多機能プリンタ９１４のような全てネットワーク１００に接続された複数の装置を含むように描かれている。これら複数の装置は一般的には「被監視装置」として言及される。また、システム９００は、被監視装置９０８，９１０，９１２，９１４を監視及び制御するための、ネットワーク１００に接続されたワークステーション／監視システム９０２（以下、コントローラ９０２として言及される）を含む。被監視装置９０８，９１０，９１２，９１４の各々には固有のアドレスが与えられる。例えば、装置に割り当てられたＩＰアドレスは、その装置に固有のアドレスとしてはたらく。従って、被監視装置各自に割り当てられた固有のＩＰアドレスにアクセスすることで、コントローラ９０２におけるユーザは、被監視装置９０８−９１４中の各装置にアクセスすることができる。本発明は、ネットワークに接続された装置を一意に識別する際に、ＩＰアドレスを利用することに限定されないことは、理解されるであろう。

コントローラ９０２は、被監視装置９０８−９１４中の装置にアクセスし、ＳＮＭＰ及び／又はＨＴＴＰプロトコルにより様々な情報を取得する。そのような情報は、トラブルシューティング情報を含む装置の動作状態に関する詳細な情報を含む。例えば、コントローラ９０２は、特定の装置のジャムロケーションにアクセス及び取得し、その混雑を解消するためその装置に関する人物にメッセージを送る。レーザプリンタ９０８の動作状態／詳細は、トナーレベル、用紙詰まりの表示、印刷トレイ内の印刷用紙量等を含む。

コントローラ９０２は、ネットワーク１００に物理的に接続される或いは無線で結合されてもよいことが、理解されるであろう。例えば、ネットワーク１００に無線で結合されるように示されるパーソナルディジタルアシスタント（ＰＤＡ）９２０又はラップトップコンピュータ９２２が、コントローラ９０２として使用されてもよい。アクセスポイント９２４は、ネットワーク１００及びＰＤＡ９２２又はラップトップコンピュータ９２２間の無線通信を可能にするインターフェースとして機能する。以後、本発明は、ネットワークに接続された被監視装置の状態をコントローラ９０２が制御及び監視することを前提に説明される。

ネットワーク１００は、コントローラ９０２及び被監視装置９０８−９１４間の通信を支援し、そのような被監視装置の監視及び制御を可能にする。本発明では、ネットワークに接続される装置数は限定されない。ネットワーク１００は、ローカルエリアネットワーク（ＬＡＮ）又は広域ネットワーク（ＷＡＮ）であってもよいことが理解されるであろう。同様に、被監視装置９０８，９１０，９１２，９１４は例示的に示されているに過ぎない。

コントローラ９０２は、格納装置９０４及びデータベース９０６に通信可能に結合される。格納装置９０４は、ハードディスク、光ディスク及び／又は外部ディスクドライブを含む。データベース９０６は、格納装置９０４に通信可能にリンクされ、格納装置９０４に格納されたデータの調査及び検索を簡単にする関連データベース管理システム（ＲＤＢＭＳ）を含む。格納装置９０４は、被監視装置９０８−９１４の各々に関する詳細情報を格納することが好ましい。例えば、レーザプリンタ９０８に関する構造、型及び様々な機能のような詳細情報や、トラブルシューティングの詳細が、格納装置９０４に格納される。また、レーザプリンタの動作状態に関する、所定の基準値と比較した際の逸脱値も、格納装置９０４に格納されてもよい。データベース９０６及び格納装置９０４はコントローラ９０２に通信可能に結合されるように記述されるが、コントローラ９０２が格納装置及びそこにインストールされるデータベースと共に構築されてもよいことが理解されるであろう。そのような場合には、格納装置９０６及びデータベース９０４は、コントローラ９０２内部にあるように描かれていたであろう。

コントローラ９０２には、複数の装置９０８−９１４の監視及び制御を促進するためのソフトウエアがインストールされる。シンプルネットワーク管理プロトコル（ＳＮＭＰ）、ファイル転送プロトコル（ＦＴＰ）及びハイパーテキスト転送プロトコル（ＨＴＴＰ）は、複数の装置９０８−９１４を監視するコントローラ９０２によって使用され、複数の装置９０８−９１４から受信したデータは、９５０に示されるように、ＡＳＮ．１バイナリフォーマット、ＨＴＭＬ又はＸＭＬフォーマットの形式で提示される。

図９は画像処理装置のみを描いているが、監視装置及び複数の被監視装置間の情報を通信するネットワークは、機器及び計器がネットワークに接続されたホームネットワークを含んでもよい。コントローラ／ワークステーション９０２により集められたデータは、電子メール、ＦＴＰその他任意の通信プロトコル手段を通じて、更なる処理のために遠隔装置に送信可能であることが、理解されるであろう。

［監視システムアーキテクチャ］
図１０は、本発明の実施例による、遠隔装置に関連するデータの監視に使用される監視システム１０００（及び関連するインターフェース機能）を示す。監視システム１０００は、ソフトウエアモジュールのモニタサービス１００４を含み、そのモジュールはＮＴ又はウインドウズ２０００におけるサービス及びユニックスにおけるデーモン（Ｄａｅｍｏｎ）のようなコンピュータ常駐プログラムである。好適実施例では、監視システムは、オブジェクト指向型ソフトウエア環境で実現される。また、タイマーモジュール１００２及びモニタモジュール１００６も監視システム１０００に含まれている。タイマーモジュール１００２及びモニタモジュール１００６は、モニタサービスモジュール１００４により呼び出されるライブラリ関数である。例えば、モニタサービス１００４は、初期化タイマ（ＩｎｉｔＴｉｍｅｒ）１００３の関数を呼び出すことでタイマーモジュール１００２を初期化し、遅延及び動作取得（ｏｂｔａｉｎＤｅｌａｙＡｎｄＡｃｔｉｏｎ）（ｉｎｔ ＆，ｉｎｔ＆）の関数を呼び出すことで、遅延及び動作パラメータを取得する。イニット（）（ｉｎｉｔ（））の関数は、図１３に示されるような、監視モジュール１００６内の様々なモジュールを初期化するために、モニタサービスモジュール１００４によっても呼び出される。ｉｎｉｔ（）関数は、ＩＰアドレス、パラメータ名及び既知の方法で収集された値を含む外部ソースを通じて、被監視装置に割り当てられたＩＰアドレス及びパラメータ値を取得するために使用可能である。モニタモジュール１００６は、以下に詳細に説明される、サポートデータベース１０２４及びモニタデータベース１０１４に通信可能に接続される。

ひとたび被監視装置のＩＰアドレスが取得されると、そのＩＰアドレスは、被監視装置と連絡をとり、製造業者（ベンダ）及びモデル情報のような情報を得るために使用される。監視装置１０００によって実行されるいくつかの機能は、以下のものを含む：
ボイドイニットタイマー（ｖｏｉｄ ｉｎｉｔＴｉｍｅｒ）（ボイド）
この関数は、タイマーを初期化する。特に、この関数は、レジストリからタイミング情報を得るためにタイマーオブジェクトに契機（トリガ）を与える。

ボイドオブテインディレイアンドアクション（ｉｎｔ＆ｏｕｔ＿ｎＤｅｌａｙ，ｉｎｔ＆ｏｕｔ＿ｎＡｃｔｉｏｎ）
この関数は、：：スリープ（：：Ｓｌｅｅｐ）関数（複数の１０００に必要）及びアクションインジケータに関する遅延を秒数で返す。アクションインジケータは、次のように定められる：０＝イベントチェック；１＝監視されるデータを送信すること；２＝監視し、データをローカルデータベースに格納すること。

イントイニット（ｉｎｔ ｉｎｉｔ）（ボイド）
この関数は、モニタを初期化する。更に、これは監視される装置を作成する。リターンイントは、ゼロがエラー無しとして規定されるところのエラーコードである。

イントモニタステータス（ｉｎｔ ｉｎ＿ｎＡｃｔｉｏｎ）
この関数は情報を事前に設定する。リターンイントは、ゼロがエラー無しとして規定されるところのエラーコードである。

イントエンド（ボイド）
この関数は、オブジェクトを閉じる前にモニタをきれいにする。リターンイントは、ゼロがエラー無しとして規定されるところのエラーコードである。

［モニタモジュール］
図１１は、モニタモジュール１００６の詳細構造を示し、様々なソフトウエアサブモジュールを含み、モニタモジュールのサブモジュール間の呼出関数を含む。モニタモジュール１００６は、図１０に示されるようなインターフェース関数で規定されるタスクを完了するための、多くのモジュールで使用されるクラスを含む共通モジュール１１０１と、他のサブモジュール（デバイスＯＤＢＣモジュール１１０４、デバイスモジュール１１１０及びＨＷアクセスモジュール１１１６を含む）を管理するモニタマネジャモジュール１１０２とを含む。具体的には、デバイスＯＤＢＣモジュール１１０４は、標準的なインターフェースを通じて外部装置情報にアクセスするためにアクセスされる。ＨＷアクセスモジュール１１１６は、複数の通信プロトコル（例えば、ＨＴＴＰ、ＳＮＭＰ及びＦＴＰ）の中から選択された通信プロトコルを用いて、被監視装置からベンダ、モデル、固有ＩＤ及びステータスの情報を取得する。モニタソフトウエアモジュールの各々は以下に更に詳細に説明される。

以下は、上述のモニタモジュール中のインターフェースの部分的な列挙及び説明である。例えば、いくつかのモジュールは、利用しやすいフォーマットで情報を得るために、「イニット」関数又は付加的な関数を有することを必要とするかもしれない。

ボイドアップデートコンフィグ（ｖｏｉｄ ｕｐｄａｔｅＣｏｎｆｉｇ）（ｓｔｄ：：ｍａｐ＜ｉｎｆｏＴｙｐｅ，ｓｔｄ：：ｓｔｒｉｎｇ＞＆）
この関数が呼び出される前に、呼出関数は、取得関数が空白文字列（ヌルストリング）を返す場合に、ベンダ及びモデルの入力を置換しないことが好ましい。この関数は、デバイスＯＤＢＣ１１０４における現在の記録に関する装置上法データベースを更新する。この関数は、以下のオブテインコンフィグが初期に呼び出される場合に最も効率的である。先ず、この関数は、ＩＰアドレスがデバイスＯＤＢＣ１１０４におけるものと同じであるか否かを検査する。ＩＰアドレスフィールドが同じでなければ、現在のＩＰアドレスに関する記録が、そのデータベースから取得される。そして、他のフィールドがコピーされ、記録が更新される。

ブールオブテインコンフィグ（ｂｏｏｌ ｏｂｔａｉｎＣｏｎｆｉｇ）（ｓｔｄ：：ｍａｐ＜ｉｎｆｏＴｙｐｅ，ｓｔｄ：：ｓｔｒｉｎｇ＞＆，ｓｔｄ：：ｍａｐ＜ｓｔｄ：：ｓｔｒｉｎｇ，ｓｔｄ：：ｖｅｃｔｏｒ＜ＳＰｒａｍｅｔｅｒ＞＞＆）
この関数は、装置情報に関するデバイスＯＤＢＣ１１０４から所与のフォーマットのマップ、プロトコルのマップ及び関連するパラメータを取得する。この関数は、返されるデータが存在する場合には真を返し、それ以上データが無ければ偽を返す。

ブールセーブステータス（ｂｏｏｌ ｓａｖｅＳｔａｔｕｓ）（ｓｔｄ：：ｍａｐ＜ｉｎｆｏＴｙｐｅ，ｓｔｄ：：ｓｔｒｉｎｇ＞＆）
この関数はステータス情報をデバイスＯＤＢＣ１１０４に保存する。この関数は、保存が成功すると真を返し、そうでなければ偽を返す。

シーデバイス＊クリエイトデバイス（ＣＤｅｖｉｃｅ＊ｃｒｅａｔｅＤｅｖｉｃｅ）（ｃｏｎｓｔ ｓｔｄ：：ｓｔｒｉｎｇ＆ｉｎ＿ｓＩＰ，ＣＨＷａｃｃｅｓｓ＆ｉｎ＿ＨＷａｃｃｅｓｓ，ｓｔｄ：：ｍａｐ＜ｓｔｄ：：ｓｔｒｉｎｇ，ｓｔｄ：：ｖｅｃｔｏｒ＜ＳＰａｒａｍｅｔｅｒ＞＞＆ｉｎ＿ＰｒｏｔｏｃｏｌＰａｒａｍｅｔｅｒｓ）
この関数は、ｉｎ＿ｓＩＰ及びｉｎ＿プロトコルパラメータに基づいて、装置を作成する。作成された装置は、ＣＨＷアクセスによりハードウエアに接続される。装置を作成することができない場合には、この関数は０を返す。従って、呼び出すオブジェクトは、リターンオブジェクトポインタが０であるか否かを検査すべきである。

ブールキャンアクセスＨＷ（ｂｏｏｌ ｃａｎＡｃｃｅｓｓＨＷ）（ボイド）
この関数は、ハードウエアがネットワークを通じてアクセス可能ならば真を返し、層でなければ偽を返す。

ブールゲットベンダ（ｂｏｏｌ ｇｅｔＶｅｎｄｏｒ）（ｓｔｄ：：ｓｔｒｉｎｇ＆ｏｕｔ＿ｓＶｅｎｄｏｒ）
この関数はベンダ名を返す。装置がシステムによりサポートされないが、プロトコルの１つを通じてアクセス可能であるならば、文字列（ストリング）は「ジェネリック（ＧＥＮＥＲＩＣ）」を含む。処理中にエラーが検出されると、この関数はヌルストリングと共に偽を返す。そうでなければ、関数は真を返す。

ブールゲットモデル（ｂｏｏｌ ｇｅｔＭｏｄｅｌ）（ｓｔｄ：：ｓｔｒｉｎｇ＆ｏｕｔ＿ｓＭｏｄｅｌ）
この関数は装置の型（モデル）を取得する。モデルが取得されると、この関数は真を返す。処理中にエラーが検出されると、この関数はヌルストリングと共に偽を返す。

ブールゲットユニークＩＤ（ｂｏｏｌ ｇｅｔＵｎｉｑｕｅＩＤ）（ｓｔｄ：：ｓｔｒｉｎｇ＆ｏｕｔ＿ｓＵｎｉｑｕｅＩＤ）
この関数は装置に固有のＩＤを返す。固有のＩＤが取得されると、この関数は真を返す。処理中にエラーが検出されると、この関数はヌルストリングと共に偽を返す。

ブールオブテインステータス（ｂｏｏｌ ｏｂｔａｉｎＳｔａｔｕｓ）（ｍａｐ＜ｉｎｆｏＴｙｐｅ，ｓｔｄ：：ｓｔｒｉｎｇ＞＆ｏｕｔ＿ＳｔａｔｕｓＭａｐ）
この関数は、ステータスマップを返す。この関数は、ステータスが返される場合に真を返し、ステータスを返すことができない場合に偽を返す。この関数は、ＨＷアクセス及び装置モジュールから異なるマップを返すことに留意を要する。装置モジュールでは、イベントステータス情報が、ＨＷアクセスから返されたマップに付加され、クリアされる。

イナムチェックイベントステータス（ｅｎｕｍ ｃｈｅｃｋＥｖｅｎｔＳｔａｔｕｓ）（ボイド）
この関数は、ネットワーク装置のイベントを取得するための契機を与える。イナム（ｅｎｕｍ）タイプ及び値がクラス内で定義されるべきである。イナム値は、以下の値を含む：ｅＮｏＥｖｅｎｔＳｉｎｃｅＣｌｅａｒＡｎｄＮｏＥｖｅｎｔＤｅｔｅｃｔｅｄ，ｅＮｏＥｖｅｎｔＳｉｎｃｅＣｌｅａｒＡｎｄＥｖｅｎｔＤｅｔｅｃｔｅｄ，ｅＥｖｅｎｔＳｉｎｃｅＣｌｅａｒＡｎｄＮｏＥｖｅｎｔＤｅｔｅｃｔｅｄ，ｅＥｖｅｎｔＳｉｎｃｅＣｌｅａｒＡｎｄＥｖｅｎｔＤｅｔｅｃｔｅｄ。

ブールオブテインイベントステータス（ｂｏｏｌ ｏｂｔａｉｎＥｖｅｎｔＳｔａｔｕｓ）（ｓｔｄ：：ｍａｐ＜ｉｎｆｏＴｙｐｅ，ｓｔｄ：：ｓｔｒｉｎｇ＞＆ｏｕｔ＿ＥｖｅｎｔＳｔａｔｕｓＭａｐ）
この関数は、イベントステータス情報を取得する。この関数は、ステータスが返される場合に真を返し、ステータスが取得できない場合に偽を返す。

ボイドクリアイベントステータス（ｖｏｉｄ ｃｌｅａｒＥｖｅｎｔＳｔａｔｕｓ）（ボイド）
この関数は、最後のオブテインステータス関数呼出又はクリアイベントステータス以来蓄積されたイベント情報をクリアする。

ボイドイニットビギン（ｖｏｉｄ ｉｎｉｔＢｅｇｉｎ）（ボイド）
この関数は、ＨＷアクセスを通じて、特にソフトウエア装置オブジェクトを作成するために、初期化プロセスを開始する。

ボイドイニットエンド（ｖｏｉｄ ｉｎｉｔＥｎｄ）（ボイド）
この関数は、装置オブジェクト作成が終了したことを示すＨＷアクセスにより、初期化プロセスを終了する。

ブールキャンアクセスＩＰ（ｂｏｏｌ ｃａｎＡｃｃｅｓｓＩＰ）（ｃｏｎｓｔ ｓｔｄ：：ｓｔｒｉｎｇ＆ｉｎ＿ｓＩＰ，ｓｔｄ：：ｍａｐ＜ｓｔｄ：：ｓｔｒｉｎｇ，ｓｔｄ：：ｖｅｃｔｏｒ＜ＳＰａｒａｍｅｔｅｒ＞＞＆ｉｎ＿ＰｒｏｔｏｃｏｌＰａｒａｍｅｔｅｒ）
この関数は、装置がそのＩＰアドレスでアクセス可能な場合に真を返し、そうでなければ偽を返す。

ブールオブテインベンダ（ｂｏｏｌ ｏｂｔａｉｎＶｅｎｄｏｒ）（ｓｔｄ：：ｓｔｒｉｎｇ＆ｏｕｔ＿ｓＶｅｎｄｏｒ，ｓｔｄ：：ｍａｐ＜ｓｔｄ：：ｓｔｒｉｎｇ，ｓｔｄ：：ｖｅｃｔｏｒ＜ＳＰａｒａｍｅｔｅｒ＞＞＆ｉｎＯｕｔ＿ＰｒｏｔｏｃｏｌＰａｒａｍｅｔｅｒ，ｃｏｎｓｔ ｓｔｄ：：ｓｔｒｉｎｇ＆ｉｎ＿ｓＩＰ）
この関数はベンダを取得する。この関数は、動作が成功すると真を返し、そうでなければ、空白文字列と共に偽を返す。この関数の呼出中に、プロトコルは検査され、ステータス監視に特定のプロトコルが利用できない場合に、そのプロトコルはインアウト＿プロトコルパラメータから削除される。

ブールオブテインモデル（ｂｏｏｌ ｏｂｔａｉｎＭｏｄｅｌ）（ｓｔｄ：：ｓｔｒｉｎｇ＆ｏｕｔ＿ｓＭｏｄｅｌＮａｍｅ，ｓｔｄ：：ｍａｐ＜ｓｔｄ：：ｓｔｒｉｎｇ，ｓｔｄ：：ｖｅｃｔｏｒ＜ＳＰａｒａｍｅｔｅｒ＞＞＆ｉｎＯｕｔ＿ＰｒｏｔｏｃｏｌＰａｒａｍｅｔｅｒ，ｃｏｎｓｔ ｓｔｄ：：ｓｔｒｉｎｇ＆ｉｎ＿ｓＩＰ）
この関数は、モデル名を取得する。この関数は、動作が成功すると真を返し、そうでなければ、空白文字列と共に偽を返す。この関数の呼出中に、プロトコルは検査され、ステータス監視に特定のプロトコルが利用できない場合に、そのプロトコルはインアウト＿プロトコルパラメータから削除される。

ブールオブテインユニークＩＤ（ｂｏｏｌ ｏｂｔａｉｎＵｎｉｑｕｅＩＤ）（ｓｔｄ：：ｓｔｒｉｎｇ＆ｏｕｔ＿ｓＵｎｉｑｕｅＩＤ，ｓｔｄ：：ｍａｐ＜ｓｔｄ：：ｓｔｒｉｎｇ，ｓｔｄ：：ｖｅｃｔｏｒ＜ＳＰａｒａｍｅｔｅｒ＞＞＆ｉｎＯｕｔ＿ＰｒｏｔｏｃｏｌＰａｒａｍｅｔｅｒｓ，ｃｏｎｓｔ ｓｔｄ：：ｓｔｒｉｎｇ＆ｉｎ＿ｓＩＰ）
この関数は、固有のＩＤを取得する。この関数は、動作が成功すると真を返し、そうでなければ、空白文字列と共に偽を返す。この関数の呼出中に、プロトコルは検査され、ステータス監視に特定のプロトコルが利用できない場合に、そのプロトコルはインアウト＿プロトコルパラメータから削除される。

イーエラーコードオブテインイベントステータス（ＥｅｒｒｏｒＣｏｄｅ ｏｂｔａｉｎＥｖｅｎｔＳｔａｔｕｓ）（ｓｔｄ：：ｍａｐ＜ｉｎｆｏＴｙｐｅ，ｓｔｄ：：ｓｔｒｉｎｇ＞＆ｏｕｔ＿ＳｔａｔｕｓＭａｐ，ｃｏｎｓｔ ｓｔｄ：：ｓｔｒｉｎｇ＆ｉｎ＿ｓＩＰ，ｓｔｄ：：ｍａｐ＜ｓｔ：：ｓｔｒｉｎｇ，ｓｔｄ：：ｖｅｃｔｏｒ＜ＳＰａｒａｍｅｔｅｒ＞＞＆ｉｎ＿ＰｒｏｔｏｃｏｌＰａｒａｍｅｔｅｒｓ）
この関数は、イベントステータスを取得する。イーエラーコードは以下のように定められる。

ブールオブテインステータス（ｂｏｏｌ ｏｂｔａｉｎＳｔａｔｕｓ）（ｓｔｄ：：ｍａｐ＜ｉｎｆｏ Ｔｙｐｅ，ｓｔｄ：：ｓｔｒｉｎｇ＞＆ｏｕｔ＿ＳｔａｔｕｓＭａｐ，ｃｏｎｓｔ ｓｔｄ：：ｓｔｒｉｎｇ＆ｉｎ＿ｓＩＰ，ｃｏｎｓｔ ｓｔｄ：：ｓｔｒｉｎｇ＆ｉｎ＿ｓＶｅｎｄｏｒ，ｃｏｎｓｔ ｓｔｄ：：ｓｔｒｉｎｇ＆ｉｎ＿ｓＭｏｄｅｌ，ｓｔｄ：：ｍａｐ＜ｓｔｄ：：ｓｔｒｉｎｇ，ｓｔｄ：：ｖｅｃｔｏｒ＜Ｓｐａｒａｍｅｔｅｒ＞＞＆ｉｎ＿ＰｒｏｔｏｃｏｌＰａｒａｍｅｔｅｒｓ）
この関数は、装置のステータスを取得する。この関数は、動作が成功すると真を返し、そうでなければ、空白のマップと共に偽を返す。

図１２は、図１１に示されるような、ＨＷアクセスモジュールにより受信されたキーの値に関連する値の検索用の情報を交換するための、ＨＷアクセスモジュール１１１６により使用されるデータ構造を示す。例えば、図１２に示されるようなエスキー値情報データ（ＳＫｅｙＶａｌｕｅＩｎｆｏ ｄａｔａ）構造は、所与のウェブページ内で特定の情報形式に対応する情報（エムインフォタイプ（ｍ＿ｉｎｆｏＴｙｐｅ）１２０２に対応する）の取得方法を決定するために使用される。典型的には、ベンダの多数がベンダ固有の識別子及び専門語を使用し、キー情報を識別し、それら各自のウェブページに表示し、被監視装置に関連付ける。例えば、プリンタ装置で印刷される多数の用紙を判別するために、ヒューレットパッカード社は「ページ数」属性を使用するが、ゼロックス社は「配給した用紙合計」属性を用いてそれを判別する。本発明による特徴は、ベンダ毎の相違を克服し、それにより、装置固有の情報を識別する標準的且つ画一的な方法を提供し、データ構造／エスキー値インフォ構造１２００を用いることでその情報に対応する値を引き出す。エスキー値インフォ構造１２００は、公の属性を含む。

エスキー値インフォは、典型的には、情報からの値情報を判別するために作成されたデータ構造であり、その情報は、データストリング又はキーストリングの形式で被監視装置から受信されたものである。エスキー値インフォは複数のフィールドを含み、各フィールドは図１２に示される情報によって表現される。エスキー値インフォ構造１２００は、ストリングキーを表現するエムエスキーフィールド１２０４と、値情報を位置付けることが可能な文字列中の位置の数を示すタグ値であることが好ましいエムエヌポジション（ｍ＿ｎＰｏｓｉｔｉｏｎ）フィールド１２０６と、エムエヌインラインポジション（ｍ＿ｎＩｎＬｉｎｅＰｏｓｉｔｉｏｎ）フィールド１２１２とを含む。例えば、監視に委ねられるプリンタ装置のページ数は、キーワードに続く２番目の位置にて発見される。エムエスタイプ（ｍ＿ｓＴｙｐｅ）１２０８は、被監視装置に関する表示されたウェブページから検索可能な情報タイプを表現する。

例えば、被監視装置のモデル名のような値が、キー（製品名）の同一データライン内に見出されると、エムエヌポジションフィールドは“０”である。エムエスデリミタ（ｍ＿ｓＤｅｌｉｍｉｔｅｒ）１２１０は、キーに関連する値を抽出するために使用される特定の区切り符号を示す。エスキー値インフォデータ構造は、被監視装置からＨＴＭＬフォーマットで受信した情報から値情報を引き出す方法を示す。

図１３は、図１０に示されるようなモニタモジュール１００６の呼び出しシーケンスを記述する、イニット（）関数のシーケンスを示す。モニタマネジャ１１０２は、初期化関数を開始させるため、ＨＷアクセスモジュール１１１６を初期化する。その後に、モニタマネジャ１１０２は、被監視装置に関する情報を取得し、その被監視装置に割り当てられたＩＰアドレスを利用して、被監視装置と通信する。モニタマネジャ１１０２は、装置ＯＤＢＣ１１０４にアクセスし、被監視装置のコンフィギュレーション情報を取得する。モニタマネジャ１１０２に返されるコンフィギュレーション情報は、例えば、被監視装置のＩＰアドレス、各プロトコルに関連するパラメータ名及び値、被監視装置に関するベンダ／製造業者並びにモデル情報を含む。ひとたびＩＰアドレスが取得されると、モニタマネジャ１１０２は、ＩＰアドレス、各プロトコルに関するパラメータ名及び値を設定し、シーデバイスファクトリクラス２００１により、デバイスモジュール１１１０のクラス構造に基づいて、ソフトウエアオブジェクトを作成する。デバイスソフトウエアオブジェクトが良好に作成されると、ＨＷアクセスモジュール１１１６は、作成されたデバイスソフトウエアオブジェクトに格納されるベンダ、モデル及び固有ＩＤを被監視装置から取得するために使用される。

ベンダ、モデル情報及び固有ＩＤがデバイスソフトウエアオブジェクトからひとたび得られると、モニタマネジャ１１０２は、被監視装置から受信した情報を用いてデータベース（例えば、デバイスＯＤＢＣ１１０４）を更新する。図１３は１つの装置しか示していないが、オブテインコンフィグからアップデートコンフィグまでのステップは、外部ソースにより指定される全ての装置を網羅するように反復される。更に、図２３，２４に示される各プロセスがイニシャライズされる。図２４におけるＯＤＢＣに対応するデータベーステーブルがアクセスされ、アクセスされた装置に必要な情報は、外部格納部から内部データ構造まで転送され、アクセスした装置からのステータス情報の収集が速まるようにする。

図１４は、図１１に示されるようなモニタマネジャモジュール１１０２によって、被監視装置の状態を判定するためのステータスモニタ関数のシーケンスを示す。オブテインステータス関数が、デバイスからＨＷアクセスに発行されると、今度はＣＨＷアクセスクラスが、以下に説明されるように、抽象クラスを通じて異なるパラメータと共に図２３，２４に説明される各プロトコルにオブテインステータス関数呼出を発行する。各プロトコルモジュールは、被監視装置からステータス情報を抽出するのに必要な情報を既にキャッシュしており、その必要な情報は、図１３にて説明された初期化期間の間に既にアクセス済みである。従って、ステータス監視中に外部ソースにアクセスせずに、ステータス情報は被監視装置から速やかに抽出可能である。このプロセスは、図１５に示されるベクトルに含まれる被監視装置の全てにわたって反復される。

図１５を参照するに、図１３，１４に示されるようにして、Ｃデバイスファクトリ１１０６により作成され且つモニタマネジャ１１０２により使用されるデバイスに対するリファレンスを有するベクトル１５００が示されている。モニタマネジャ１１０２は、例えばＣデバイスオブジェクト１５０２に対するポインタ、及びＣデバイスファクトリ１１０６により作成されたＣデバイスオブジェクト１５０４に対するポインタのようなデバイスポインタをベクトル中に格納する。ベクトルシーケンスは、被監視装置の状態を得るように反復される。被監視装置に対するポーリングは、そのデバイスオブジェクト上で、オブテインステータス・コマンドを発行することによって実行される。ソフトウエアオブジェクト各々のステータスが取得されると、そのようなステータスはデバイスＯＤＢＣ１１０４によって更新される。ステータスモニタシーケンスは、図１４にて説明済みであり、ここでは繰り返さない。

表１に示されるデバイス情報の構造は、被監視装置の一例に関する情報を示す。デバイス情報の構造は、電話番号に加えて、連絡先の人の電子メールアドレスを含む。

表１

［モニタデータベース］
図１９は、モニタデータベースの組織を示し、被監視装置各々についての装置情報（表１参照。）を含む。図１９に示されるように、一群のパラメータ、各通信プロトコル（例えば、ＳＮＭＰ、ＨＴＴＰ及びＦＴＰ）に関する１つの集合は、被監視装置各々についての装置情報のデバイスインフォ（ＤｅｖｉｃｅＩｎｆｏ）１９０２に関連する。更に、特定のプロトコル（例えば、ＳＮＭＰ１９０８、ＨＴＴＰ１９１０及びＦＴＰ１９１２）に関するパラメータ群の各々は、例えば、ｓＰａｒ１Ｎａｍｅ及びｓＰａｒ１Ｖａｌｕｅのように、パラメータ名及び値の組（ペア）のリストとして組織される。各プロトコルに関するパラメータ数は、図１９に示される数より少なくてもよいし、多くてもよい。例えば、ユーザ名及びパスワードはＦＴＰパラメータとして格納される一方、団体名及びパスワードは所与の被監視装置に関してＳＮＭＰパラメータとして格納されてもよい。図１９に示されるように、モニタデータベースも、デバイスヒストリ（ＤｅｖｉｃｅＨｉｓｔｏｒｙ）１９０４及びイナムコレスポンデンス（ＥｎｕｍＣｏｒｒｅｓｐｏｎｄｅｎｃｅ）１９０６に関する情報を含む。

図１７は、様々な通信プロトコルで使用されるパラメータを伝送するのに使用されるＳパラメータデータ構造１７００を示す。Ｓパラメータは、パラメータの名称及び値をそれぞれ表現する次の２つのフィールドを含む：ｍ＿ｓＰａｒＮａｍｅ１７０２及びｍ＿ｓＰａｒＶａｌｕｅ１７０４。

図１８は、モニタデータベースから取得された各プロトコル用のパラメータのベクトルを、被監視装置各々に関連するソフトウエアオブジェクトに伝送するために使用されるマップ構造１８００を示す。マップ構造１８００は、図１７に示されるＳパラメータフォーマットに従って、プロトコル／キーフィールド１８０２，１８０４，１８０６の各々を、対応するベクトルパラメータ１８０８，１８１０，１８１２にそれぞれ関連付ける。例えば、ＳＮＭＰプロトコル１８０２、パラメータのベクトル１８０８はパラメータ名、パラメータ値の組のリストを含み、それらはＳＮＭＰプロトコルで被監視装置にアクセスするのに使用される。例えば、ベクトル１８０８に格納されるＳＮＭＰパラメータ名は、対応するパラメータ値と共に、「団体名」及び「パスワード」を含むかもしれない。しかしながら、マップ構造１８００の組織は、プロトコル及び関連パラメータベクトルのいかなる数も許容し、図１８に示されるＳＮＭＰ，ＨＴＴＰ及びＦＴＰプロトコルに限定されないことに留意を要する。

［サポートデータベース］
図２０−２２は、図１０に示されるサポートデータベース１０２４の組織を示す。被監視装置の各々から状態情報を抽出するのに必要な情報を含むサポートデータベースは、通信プロトコルによって組織される。例えば、図２０は被監視装置から情報を引き出すために使用されるＳＮＭＰ関連サポート情報用のサポートデータベースの組織を示し、ＳＮＭＰベンダ（ＳＮＭＰＶｅｎｄｏｒ）２００２、ＳＮＭＰコムベンダステータス（ＳＮＭＰＣｏｍＶｅｎｄｏｒＳｔａｔｕｓ）２００４、イナムコレスポンデンス（ＥｎｕｍＣｏｒｒｅｓｐｏｎｄｅｎｃｅ）２００６及びＳＮＭＰベンダモデルステータス（ＳＮＭＰＶｅｎｄｏｒＭｏｄｅｌＳｔａｔｕｓ）２００８のデータ構造を含む。サポートデータベースの所与のデータ構造は、抽出されるステータス情報の種類を一意に識別するパラメータを、抽出を制御するパラメータと共に含んでもよい。例えば、ＳＮＭＰコムベンダステータスデータ構造２００４は、抽出される情報のタイプを示すｎＥＮＵＭフィールド２００９（例えば、トナーレベル）、他のプロトコルに関する抽出される情報のウエイト又は重要度を示すｎ相対的優先度（ｎＲｅｌａｔｉｖｅＰｒｉｏｒｉｔｙ）フィールド２０１０を含む。従って、１より多くのプロトコルを用いて同じ情報が被監視装置から抽出される場合に、ｎ相対的優先度の値は、プロトコルの抽出値のどれが使用されるべきかの相対的な指標を与える。例えば、トナーレベルが「高い」又は「低い」を示す情報しかＨＴＴＰが抽出できず、トナー残量のパーセンテージレベルをＳＮＭＰプロトコルが抽出可能であるならば、ＳＮＭＰに関するトナーレベルの優先度は、ＨＴＴＰの対応する値よりも高いであろう。更に、サポートデータベースは、プロトコル全体についてのデフォルト優先度の値を与えてもよい。一例では、あるシステムにて、プロトコル値が０乃至３２０００の範囲内にあるＳＮＭＰプロトコルに、優先度値１００００が与えられる。

図２１及び２２は、サポートデータベース１０２４のＨＴＴＰ及びＦＴＰの部分に含まれるデータ構造を示し、図２０に関して上述したデータ構造に類似するデータ構造を含む。

本発明で使用されるイナムタイプの例は、以下に規定される情報種別（インフォタイプ）
である。（このイナムタイプは、単なる例示であり、本発明を限定するものとして解釈されるべきではない。）
インフォタイプ（ｔｙｐｅｄｅｆ ｉｎｔ ｉｎｆｏ Ｔｙｐｅ）
このセクションは、インフォタイプ（ｉｎｔ）の定義を説明する。０乃至９９の範囲内の値が、データタイプに割り当てられる。１００乃至４９９の範囲内の値は、デバイス情報に割り当てられる。５００乃至１９９９の範囲内の値は、標準的なＭＩＢパラメータを含む共通パラメータに割り当てられる。２０００乃至３９９９の範囲は、リコー特有情報に割り当てられる。４０００乃至４９９９はゼロックスに割り当てられる。５０００乃至５９９９の範囲はレックスマークに割り当てられる。６０００乃至６９９９の範囲はＨＰに割り当てられる。これらの値は以下のように定められる。

Ｅエラーコード（ＥｅｒｒｏｒＣｏｄｅ）
以下のコードは単なる例であり、更なるコードが存在する集合に割り当てられてもよい。０−９９の範囲は予約される。１００−１９９の範囲はＳＭＴＰ用であり、２００−２９９はＰＯＰ３用であり、３００−３９９はソケット用であり、４００−４９９はＨＴＴＰ用であり、５００−５９９はＦＴＰ用である。他の指定されていない範囲は、必要ならば、ユーザによって定められてもよい。

デバイスＯＤＢＣモジュールにおける抽象クラス
図１６は、本発明によるデバイスＯＤＢＣモジュールクラス構造を示し、デバイスＯＤＢＣモジュール内でＣＡｂｓプロトコルパラメータクラス構造がどのように使用されるかを示す。ＣＡｂｓプロトコルパラメータクラスは、モニタデータベース１０１４とインターフェースをとるように、及び特定の通信プロトコルで被監視装置にアクセスするための情報を取得するように設計される。ＣＡｂｓプロトコルパラメータクラスは、プロトコル非依存性の２つの仮想的関数を有する：
（１）ｓｔｄ：：ストリング オブテインプロトコルネーム（ｓｔｄ：：ｓｔｒｉｎ ｏｂｔａｉｎＰｒｏｔｏｃｏｌＮａｍｅ）（ボイド）；及び
（２）ブール オブテインパラメータベクトル（ｂｏｏｌ ｏｂｔａｉｎＰａｒａｍｅｔｅｒＶｅｃｔｏｒ）（ｓｔｄ：：ｖｅｃｔｏｒ＜ＳＰａｒａｍｅｔｅｒ＞＆ｏｕｔ＿ＰａｒａｍｅｔｅｒＶｅｃｔｏｒ，ｃｏｎｓｔ ｓｔｄ：：ｓｔｒｉｎｇ ｉｎ＿ｓＩＰ）。

これらの関数を用いて、ＣデバイスＯＤＢＣクラスは、プロトコル並びにそれらの関連するパラメータ名及び値の多くを、プロトコルを識別せずに、ＣＡｂｓプロトコルパラメータタイプに対するポインタを通じて処理することができる。各装置について取得した情報（例えば、ＩＰアドレス）は、図１８のデータ構造に格納され、オブテインコンフィグ関数によりモニタマネジャモジュール１１０２に伝送される。ＣデバイスＯＤＢＣの観点からは、プロトコル名並びに関連するパラメータ名及び値を取得するのに使用したオブジェクトの全ては、ＣＡｂｓプロトコルパラメータの一種であると考えられる。従って、新たなパラメータが付加されると、新しいオブジェクトが作成され、ＣＡｂｓプロトコルパラメータクラスに対するベクトルポインタに格納される。他の関数は変更される必要がない。

ＨＷアクセスモジュールにおけるアブストラクトクラス
図２３は、本発明によるＨＷアクセスモジュールクラス構造を示し、ＣＡｂｓプロトコルクラス構造がＨＷアクセスモジュール内でどのように使用されるかを示す。ＣＡｂｓプロトコルクラスは、サポートデータベース１０２４とインターフェースをとるように、及び特定の通信プロトコルで被監視装置からステータス情報を抽出するためのサポート情報を取得するように設計される。ＣＡｂｓプロトコルクラスは、上述した仮想的関数を有する：イニットビギン（ｉｎｉｔＢｅｇｉｎ），イニットエンド（ｉｎｉｔＥｎｄ），きゃんアクセスＩＰ（ｃａｎＡｃｃｅｓｓＩＰ），オブテインベンダ（ｏｂｔａｉｎＶｅｎｄｏｒ），オブテインモデル（ｏｂｔａｉｎＭｏｄｅｌ），オブテインユニークＩＤ（ｏｂｔａｉｎＵｎｉｑｕｅＩＤ），オブテインイベントステータス（ｏｂｔａｉｎＥｖｅｎｔＳｔａｔｕｓ）及びオブテインステータス（ｏｂｔａｉｎＳｔａｔｕｓ）。しかしながら、オブテインイベントステータス及びオブテインステータスの関数のパラメータは、異なるタイプである。ｓｔｄ：：ｍａｐ＜ｉｎｆｏＴｙｐｅ，ｓｔｄ：：ｓｔｒｉｎｇ＞ではなく、ステータスタイプは、ｓｔｄ：：ｍａｐ＜ｉｎｆｏＴｙｐｅ，ｓｔｄ：：ｐａｉｒ＜ｓｔｄ：：ｓｔｒｉｎｇ，ｉｎｔ＞＞である。これは、ｎ相対優先度（ｎＲｅｌａｔｉｖｅＰｒｉｏｒｉｔｙ）の受け入れを可能にし、上述したように、最高の優先度のステータス情報が取得されることを可能にする。各装置及び各プロトコルに関し、システムは、その装置について取得されることの可能な特定のインフォタイプが、ステータスマップデータに既にあるか否かを検査することができる。それがステータスマップデータになければ、その特定のインフォタイプは、そのプロトコルに関して抽出される情報に加えられる。それがステータスマップデータにあれば、ｎ相対優先度が比較される。ステータスマップデータ中の優先度がより高い又は同じであるならば、そのインフォタイプはそのプロトコルを用いて取得されない。ステータスマップデータ中の優先度がより低かったならば、そのインフォタイプは抽出される情報に加えられ、ステータスマップデータ内で置換される。

ＣＡｂｓプロトコルクラスは、プロトコル非依存性の２つの他の仮想的関数を有する：
（１）ボイドイニットウィズベンダ（ｖｏｉｄ ｉｎｉｔＷｉｔｈＶｅｎｄｏｒ）（ｓｔｄ：：ｍａｐ＜ｓｔｄ：：ｓｔｒｉｎｇ，ｓｔｄ：：ｖｅｃｔｏｒ＜ＳＰａｒａｍｅｔｅｒ＞＞＆ｉｎＯｕｔ＿ＰｒｏｔｏｃｏｌＰａｒａｍｅｔｅｒ，ｃｏｎｓｔ ｓｔｄ：：ｓｔｒｉｎｇ＆ｉｎ＿ｓＶｅｎｄｏｒ）；及び
（２）ボイドイニットウィズモデル（ｖｏｉｄ ｉｎｉｔＷｉｔｈＭｏｄｅｌ）（ｓｔｄ：：ｍａｐ＜ｓｔｄ：：ｓｔｒｉｎｇ，ｓｔｄ：：ｖｅｃｔｏｒ＜ＳＰａｒａｍｅｔｅｒ＞＞＆ｉｎＯｕｔ＿ＰｒｏｔｏｃｏｌＰａｒａｍｅｔｅｒ，ｃｏｎｓｔ ｓｔｄ：：ｓｔｒｉｎｇ＆ｉｎ＿ｓＭｏｄｅｌ）
図２４は、図２３に示されるＨＴＴＰ，ＳＮＭＰ及びＦＴＰモジュール内の一定のクラス構造並びにＣＡｂｓプロトコルクラスに対する対応関係を示す。“ＸＸＸ”は特定のプロトコル（例えば、ＨＴＴＰ，ＳＮＭＰ又はＦＴＰ）を示すこと、及び本発明はプロトコル数を拡張するように設計され得ることに留意を要する。このようにＣＡｂｓプロトコルを利用することは、主要な関数を変更せずに、ＣＨＷアクセスクラスが更なるプロトコルサポートを行うことを可能にする。新たなプロトコルがサポートされるように付加されると、その新たなプロトコルは図２３及び２４の構造に従うべきである。従って、ＣＨＷアクセスクラスのみが、付加されたプロトコルオブジェクトを作成すること及びＣＡｂｓプロトコルオブジェクトポインタのベクトルにそれを設けることを必要とする。

監視方法
図２５は、ネットワークに通信可能に接続される個々の装置の中の被監視装置にアクセスするために、複数の通信プロトコルに使用されるよう構築される情報を格納する方法における各ステップを示す。

ステップ２５０２では、装置によってサポートされる少なくとも１つの通信プロトコルを利用して、装置にアクセスするための情報を取得するように、第１メモリにアクセスする。好適実施例では、外部情報格納装置は、図１９に示されるデバイス情報を含むモニタデータベース１０１４である。例えば、（１）装置のＩＰアドレス、（２）ＦＴＰを用いて装置にアクセスするためのユーザ名及びパスワード又は（３）ＳＮＭＰを用いて装置にアクセスするための団体名及びパスワードを取得するために、第１メモリにアクセスしてもよい。

ステップ２５０４では、第１メモリから取得した装置にアクセスするための情報が、第２メモリに格納される。好適実施例では、第２メモリは、複数の通信プロトコル各々に対するパラメータ名及びパラメータ値の組のベクトルより成る。更に、好適実施例では、装置にアクセスするための情報は、その装置に関連するソフトウエアオブジェクトに格納される。図１３参照。

次に、ステップ２５０６では、通信プロトコル（例えば、ＨＴＴＰ，ＳＮＭＰ，ＦＴＰ等）が、装置にアクセスするための複数の通信プロトコルの中から選択される。

最後に、ステップ２５０８では、選択された通信プロトコル及び第２メモリに格納された情報を用いることで、装置はアクセスされる。図２５は、ネットワークに通信可能に接続された個々の装置中の被監視装置にアクセスするために、複数の通信プロトコルに使用されるよう構築された情報を効率的に格納する方法における各ステップを示す。

本発明は、ネットワークに接続され、監視を要する少数の装置を含むように示されたが、本発明の精神及び範囲から逸脱せずに、任意の数の装置がネットワークに接続されてもよいことが理解されるであろう。また、本発明は、様々な装置が監視及び制御されることを要する家庭環境に適用されてもよい。

本発明は、マルチベンダ環境にある様々な装置の監視を可能にし、更に、特定のプライベート管理情報ベース（ＭＩＢ）情報を所有せずに、ユーザの理解可能な又はユーザフレンドリな方法で詳細な情報を抽出及び表示することを支援する。

本発明のコントローラは、コンピュータ技術分野の当業者に明らかなように、本発明の教示内容に従ってプログラムされた汎用ディジタルコンピュータ又はマイクロプロセッサを用いて、好都合に実現されてもよい。適切なソフトウエアコードは、ソフトウエア技術分野の当業者に明らかなように、本発明の教示内容に基づいて、通常のプログラマにより容易に準備できる。また、本発明は、当業者に明らかなように、特定用途向け集積回路を用意することで、又は通常の素子回路の適切なネットワークを相互接続することで実現されてもよい。

本発明は、命令を含む記憶媒体に存するコンピュータプログラムプロダクトを含み、その命令は、本発明によるプロセスを実行するようにコンピュータをプログラムするのに使用可能である。記憶媒体は、限定ではないが、フロップディスク、光ディスク、ＣＤ−ＲＯＭ及び磁気光ディスクを含むいかなるタイプのディスクも、ＲＯＭ、ＲＡＭ、ＥＰＲＯＭ、ＥＥＰＲＯＭ、磁気又は光カード、又は電子命令を格納するのに適したいかなるタイプの媒体も包含可能である。

明らかに、本発明に関する様々な修正及び変形が、上記の教示内容により可能である。従って、添付の特許請求の範囲内で、ここに具体的に記述されたものとは異なって本発明が実現されるかもしれないことが、理解されるべきである。

インターネットを通じてコンピュータ及びデータベースのネットワークに接続された３つの業務用オフィス装置を示す図である。 ディジタル画像形成装置の要素を示す図である。 図２に示される装置を構成するディジタル画像に関する電子部品を示す図である。 図３に示されるマルチポート通信インターフェースの詳細を示す図である。 業務用オフィス装置がネットワークに直接的に接続される又はネットワークに接続されたコンピュータに接続される別のシステム構成を示す図である。 電子メールを用いるアプリケーション部への及びそこからの情報の流れを示すブロック図である。 アプリケーション部に接続されたコンピュータもメッセージ伝送エージェント（ＭＴＡ）として機能する電子メールを用いる別の通信方法を示す図である。 アプリケーション部が電子メールを交換するメッセージ伝送エージェントを含む電子メールを用いる別の通信方法を示す図である。 機器／装置のためにメールを受信するＰＯＰ３サーバとして及び機器／装置のためにメールを送信するシンプルメール伝送プロトコル（ＳＭＴＰ）サーバとしてメールサーバが機能する、電子メールを用いる別の通信方法を示す図である。 インターネットを通じてメッセージを送信する別の方法を示す図である。 機器／装置に接続され、電子メールメッセージを通信するために使用されるコンピュータ例を示す図である。 本発明の実施例によるシステム全体の概略図である。 本発明の実施例によるデータの監視及びそれらのインターフェース機能に使用されるモジュールを示す図である。 サブモジュール間のモニタモジュール及びそれらの呼出関数内部の詳細を示す図である。 図１１に示されるＨＷアクセスサブモジュールにより使用されるデータ構造を示す図である。 図１０に示されるモニタモジュールの初期化関数のシーケンスを示す図である。 図１１に示されるような、モニタマネジャにより監視される装置のステータスを判定するステータス監視関数のシーケンス例を示す図である。 図１３に示されるような、Ｃデバイスファクトリにより作成されモニタマネジャにより使用される装置に対するリファレンスのベクトルを示す図である。 抽象的なクラスＣＡｂｓプロトコルパラメータを含む装置ＯＤＢＣモジュールのクラス構造を示す図である。 本発明による、監視される装置にアクセスするのに必要なパラメータ値を格納するために使用されるＳパラメータデータ構造を示す。 本発明による、監視される装置にアクセスするのに必要なパラメータ値を格納するのに使用されるマップ構造を示す。 本発明に使用されるモニタデータベースの組織を示す図である。 本発明による通信プロトコルに従って編成されるサポートデータベースの組織を示す図である。 本発明による通信プロトコルに従って編成されるサポートデータベースの組織を示す図である。 本発明による通信プロトコルに従って編成されるサポートデータベースの組織を示す図である。 本発明によるＨＷアクセスクラス構造を示す図である。 本発明によるＨＷアクセスクラス構造を示す図である。 本発明による、ネットワークに通信可能に接続された個々の装置の中の被監視装置にアクセスするために、複数の通信プロトコルに使用されるよう構成される情報を格納する方法を示す図である。

符号の説明

１０ 広域ネットワーク
１２Ａ−１２Ｉ コンピュータ又はルータ
１６ ネットワーク
１７，１８，２０，２２
ワークステーション
２４ ディジタル画像処理装置
２７ オフィス機器
２８ ファクシミリ装置
３２ プリンタ
４２，５６，６２，６８，７４ ワークステーション
４６，５４，５８，６４，７０，７６ ディスク
５０ ファイヤウォール
１０１ スキャナ用ファン
１０２ ポリゴンミラー
１０３ Ｆθレンズ
１０４ センサ
１０５ レンズ
１０６ クエンチングランプ
１０７ 帯電コロナ部
１０８ ローラ
１０９ ランプ
１１０，１１１，１１２ ミラー
１１３ ドラムミラー
１１４ ファン
１１５ 用紙供給ローラ
１１６ 手差し供給テーブル
１１７ 用紙カセット
１１８ 用紙供給ローラ
１１９ カセット
１２０ 中継ローラ
１２１ 位置決めローラ
１２２ 画像密度センサ
１２３ 伝送／分離コロナ部
１２４ クリーニング部
１２５ 真空ファン
１２６ 伝送ベルト
１２７ 圧縮ローラ
１２８ 排出ローラ
１２９ ホットローラ
１３０ 排気ファン
１３１ メインモータ
１３２ 光伝導性ドラム
１６０ ＣＰＵ
１６２ ＲＡＭ
１６４ ＲＯＭ
１６６ マルチポートネットワークインターフェース
１６８ 回線
１７０ ネットワーク
１７２ インターフェースコントローラ
１７４ 操作パネル
１７６ 格納インターフェース
１７８ フラッシュメモリ
１８０ 接続部
１８２ ディスク
１８４ オプションインターフェース
１８７ クロック／タイマー １７１ ローカル接続部
１８８ オプションユニットインターフェース
１９０ フューザ
１９２ プリンタ／画像処理部
１９４ スキャナ
１９６ 用紙供給コントローラ
１９８ 大容量トレイユニット
２００ デュプレクサ
２０２ ソーター
２２０ トークンリングインターフェース
２２２ ケーブルモデム
２２４ 電話インターフェース
２２８ 無線インターフェース
２３０ イーサネットインターフェース
２５４ サービス機器
２５６ データ
２６０ イントラネット
２６２ プリンタ
２６４ インターネットサービスプロバイダ
２６６ コンピュータ
２６８ ビジネスオフィス装置
２７２ コンピュータ
２７４ ネットワーク
２７６ コンピュータ
２７８ ビジネスオフィス装置
２８２ コンピュータ
２８６ 複写機
３００ 装置／機器
３０２ 装置／機器用のコンピュータインターフェース
３０４ メールエージェント
３０６ 送信するメールの待ち行列
３０８ メッセージ伝送エージェント
３１０ ＴＣＰ／ＩＰ接続部
３１２ メッセージ伝送エージェント
３１４ ユーザメールボックス
３１６ メールエージェント
３１８ 端末におけるユーザ
３０１ コンピュータ
３２２ ローカルＭＴＡ
３２８ 中継ＭＴＡ
３６０ コンピュータ
３６２ ＣＰＵ
３６４ ＲＡＭ
３６６ 無線インターフェース
３６８ 無線装置
３７０ ＲＯＭ
３７１ フラッシュメモリ
３７２ 入力コントローラ
３７４ キーボード
３７６ マウス
３７８ シリアルインターフェース
３８０ シリアル装置
３８２ パラレルインターフェース
３８４ パラレス装置
３８６ ユニバーサルシリアルバスインターフェース
３８８ ユニバーサルシリアルバス装置
３９０ システムバス
３９２ ハードディスク
３９４ フロッピドライブ
３９６ ディスクコントローラ
３９８ ＩＥＥＥ１３９４インターフェース
４００ ＩＥＥＥ１３９４装置
４０４ ネットワーク
４０６ 通信コントローラ
４０８ 入出力コントローラ
４１０ プリンタ
４１２ ハードディスク
４１４ ＣＲＴ
４１６ ディスプレイコントローラ
１００ ネットワーク
９０２ モニタステーション
９０４ データ
９０６ データベース
９０８ リコーレーザプリンタ
９１０ ネットワークスキャナ
９１２ ベンダ１のネットワーク装置
９１４ リコーＭＦＰ
９２０ ＰＤＡ
９２２ ラップトップコンピュータ
９２４ アクセスポイント
１００２ タイマーモジュール
１００４ モニタサービスモジュール
１００６ モニタモジュール
１０１４ モニタデータベース
１０２４ サポートデータベース
１１０１ Ｓキーバリューインフォ共通モジュール
１１０２ モニタマネジャモジュール
１１０４ デバイスＯＤＢＣモジュール
１１１６ ＨＷアクセスモジュール
１１１０ デバイスモジュール
１２００ データ構造
１５００ ベクトル
１５０２，１５０４ Ｃデバイスオブジェクト用ポインタ
１７００ Ｓパラメータデータ構造
１８００ マップ構造
１８０２，１８０４，１８０６ プロトコル／キーフィールド
１８０８，１８１０，１８１２ パラメータのベクトル
１９０２ デバイス情報
１９０４ デバイス履歴

Claims (21)

1. ネットワークに通信可能に接続された個々の装置の中の被監視装置に関連するステータス情報を抽出するために、複数の通信プロトコルに使用されるよう構築されたサポート情報を格納する方法であって、
   複数の通信プロトコルを利用して前記ステータス情報を抽出するための前記サポート情報を、第１メモリから引き出すステップと、
   前記複数の通信プロトコルを用いて前記被監視装置にアクセスするために前記第１メモリから取得した情報を第２メモリに格納するステップと、
   複数の通信プロトコルの中から通信プロトコルを選択するステップと、
   前記ステータス情報を抽出するために、選択した通信プロトコル及び前記第２メモリに格納された情報を利用して、前記被監視装置にアクセスするステップと、
   を有し、前記ステータス情報は、アブストラクトソフトウエアクラスに関連する仮想的インターフェース関数を用いて抽出され、前記仮想的インターフェース関数は、複数の通信プロトコルの各々に共通し、前記サポート情報は、個々の通信プロトコルにより抽出される前記ステータス情報のタイプ及び該タイプの相対的優先度データを少なくとも示す、
   ことを特徴とする方法。
2. 前記複数の通信プロトコルを用いて前記ステータス情報を抽出するための情報が、プロトコル依存性のデータ構造の第２メモリに格納される
   ことを特徴とする請求項１記載の方法。
3. 前記相対的優先度データが、前記少なくとも１つの通信プロトコルの各々を用いて取得可能なステータス情報の少なくとも１つのタイプの品質指標を含む
   ことを特徴とする請求項１記載の方法。
4. 前記被監視装置にアクセスするステップが、
   前記複数の通信プロトコルの少なくとも１つの通信プロトコルのステータス情報の少なくとも１つのタイプに関連する相対的優先度データを利用して前記ステータス情報を抽出するステップを有する
   ことを特徴とする請求項１記載の方法。
5. 前記選択するステップが、
   ＳＮＭＰ，ＨＴＴＰ及びＦＴＰの中から通信プロトコルを選択するステップを有する
   ことを特徴とする請求項１記載の方法。
6. 前記アクセスするステップが、
   各第２メモリに格納され前記被監視装置にアクセスするのに必要な情報を、選択した通信プロトコルを用いて前記被監視装置に送信するステップを有する
   ことを特徴とする請求項１記載の方法。
7. 前記アクセスするステップが、
   送信された情報を被監視装置によって受信するステップと、
   受信した情報を前記被監視装置によって処理するステップと
   を有することを特徴とする請求項６記載の方法。
8. ネットワークに通信可能に接続された個々の装置の中の被監視装置に関連するステータス情報を抽出するために、複数の通信プロトコルに使用されるよう構築されたサポート情報を格納するシステムであって、
   複数の通信プロトコルを利用して前記ステータス情報を抽出するためのサポート情報を、第１メモリから引き出す手段と、
   前記複数の通信プロトコルを用いて前記被監視装置にアクセスするために前記第１メモリから取得した情報を第２メモリに格納する手段と、
   複数の通信プロトコルの中から通信プロトコルを選択する手段と、
   前記ステータス情報を抽出するために、選択した通信プロトコル及び前記第２メモリに格納された情報を利用して、前記被監視装置にアクセスする手段と、
   を有し、前記ステータス情報は、アブストラクトソフトウエアクラスに関連する仮想的インターフェース関数を用いて抽出され、前記仮想的インターフェース関数は、複数の通信プロトコルの各々に共通し、前記サポート情報は、個々の通信プロトコルにより抽出される前記ステータス情報のタイプ及び該タイプの相対的優先度データを少なくとも示す、
   ことを特徴とするシステム。
9. 前記複数の通信プロトコルを用いて前記ステータス情報を抽出するための情報が、プロトコル依存性のデータ構造の第２メモリに格納される
   ことを特徴とする請求項８記載のシステム。
10. 前記相対的優先度データが、前記少なくとも１つの通信プロトコルの各々を用いて取得可能なステータス情報の少なくとも１つのタイプの品質指標を含む
    ことを特徴とする請求項８記載のシステム。
11. 前記被監視装置にアクセスする手段が、
    前記複数の通信プロトコルの少なくとも１つの通信プロトコルのステータス情報の少なくとも１つのタイプに関連する相対的優先度データを利用して前記ステータス情報を抽出する手段を有する
    ことを特徴とする請求項８記載のシステム。
12. 前記選択する手段が、
    ＳＮＭＰ，ＨＴＴＰ及びＦＴＰの中から通信プロトコルを選択する手段を有する
    ことを特徴とする請求項８記載のシステム。
13. 前記アクセスする手段が、
    各第２メモリに格納され前記被監視装置にアクセスするのに必要な情報を、選択した通信プロトコルを用いて前記被監視装置に送信する手段を有する
    ことを特徴とする請求項８記載のシステム。
14. 前記アクセスする手段が、
    送信された情報を前記被監視装置にて受信する手段と、
    受信した情報を前記被監視装置にて処理する手段と
    を有することを特徴とする請求項１３記載のシステム。
15. ネットワークに通信可能に接続された個々の装置の中の被監視装置に関連するステータス情報を抽出するために、複数の通信プロトコルに使用されるよう構築されたサポート情報を格納する、コンピュータで利用可能な媒体内のコンピュータプログラムであって、
    複数の通信プロトコルを利用して前記ステータス情報を抽出するためのサポート情報を、第１メモリから引き出させる命令と、
    前記複数の通信プロトコルを用いて前記被監視装置にアクセスするために前記第１メモリから取得した情報を第２メモリに格納させる命令と、
    複数の通信プロトコルの中から通信プロトコルを選択させる命令と、
    前記ステータス情報を抽出するために、選択した通信プロトコル及び前記第２メモリに格納された情報を利用して、前記被監視装置にアクセスさせる命令と
    を有し、前記ステータス情報は、アブストラクトソフトウエアクラスに関連する仮想的インターフェース関数を用いて抽出され、前記仮想的インターフェース関数は、複数の通信プロトコルの各々に共通し、前記サポート情報は、個々の通信プロトコルにより抽出される前記ステータス情報のタイプ及び該タイプの相対的優先度データを少なくとも示す、
    ことを特徴とするコンピュータプログラム。
16. 前記複数の通信プロトコルを用いて前記ステータス情報を抽出するための情報が、プロトコル依存性のデータ構造の第２メモリに格納される
    ことを特徴とする請求項１５記載のコンピュータプログラム。
17. 前記相対的優先度データが、前記少なくとも１つの通信プロトコルの各々を用いて取得可能なステータス情報の少なくとも１つのタイプの品質指標を含む
    ことを特徴とする請求項１５記載のコンピュータプログラム。
18. 前記被監視装置にアクセスさせる命令が、
    前記複数の通信プロトコルの少なくとも１つの通信プロトコルのステータス情報の少なくとも１つのタイプに関連する相対的優先度データを利用して前記ステータス情報を抽出させる命令を有する
    ことを特徴とする請求項１５記載のコンピュータプログラム。
19. 前記選択させる命令が、
    ＳＮＭＰ，ＨＴＴＰ及びＦＴＰの中から通信プロトコルを選択させる命令を有する
    ことを特徴とする請求項１５記載のコンピュータプログラム。
20. 前記アクセスさせる命令が、
    各第２メモリに格納され前記被監視装置にアクセスするのに必要な情報を、選択した通信プロトコルを用いて前記被監視装置に送信させる命令を有する
    ことを特徴とする請求項１５記載のコンピュータプログラム。
21. 前記アクセスさせる命令が、
    送信された情報を前記被監視装置によって受信させる命令と、
    受信した情報を前記被監視装置によって処理させる命令と
    を有することを特徴とする請求項２０記載のコンピュータプログラム。