異なる複数のアクセス手段により機器からステータス情報を取得できる監視装置であって、第一のアクセス手段により前記機器から第一のステータス情報を取得し、記憶する手段と、第二のアクセス手段により前記機器から第二のステータス情報を取得した場合、前記第一のアクセス手段と第二のアクセス手段に対応するステータス情報の優先度を参照して、第一のステータス情報と第二のステータス情報のいずれを採用するかを判断する手段と、前記第二のアクセス手段を採用すると判断した場合、前記第二のステータス情報により、前記記憶した第一のステータス情報を上書きする手段とを有する監視装置。前記優先度はステータス情報の情報量の多さに基づく、請求項1に記載の監視装置。前記アクセス手段はプロトコルである、請求項1に記載の監視装置。異なる複数のアクセス手段によりアクセス可能な機器と、第一のアクセス手段により前記機器から第一のステータス情報を取得し、記憶し、第二のアクセス手段により前記機器から第二のステータス情報を取得した場合、前記第一のアクセス手段と第二のアクセス手段に対応するステータス情報の優先度を参照して、第一のステータス情報と第二のステータス情報のいずれを採用するかを判断し、前記第二のアクセス手段を採用すると判断した場合、前記第二のステータス情報により、前記記憶した第一のステータス情報を上書きする監視装置とを有する監視システム。異なる複数のアクセス手段により機器からステータス情報を取得できる監視装置における方法であって、第一のアクセス手段により前記機器から第一のステータス情報を取得し、記憶する段階と、第二のアクセス手段により前記機器から第二のステータス情報を取得した場合、前記第一のアクセス手段と第二のアクセス手段に対応するステータス情報の優先度を参照して、第一のステータス情報と第二のステータス情報のいずれを採用するかを判断する段階と、前記第二のアクセス手段を採用すると判断した場合、前記第二のステータス情報により、前記記憶した第一のステータス情報を上書きする段階とを有する方法。コンピュータを、異なる複数のアクセス手段により機器からステータス情報を取得できる監視装置として動作させるコンピュータプログラムであって、前記コンピュータに、第一のアクセス手段により前記機器から第一のステータス情報を取得し、記憶する段階と、第二のアクセス手段により前記機器から第二のステータス情報を取得した場合、前記第一のアクセス手段と第二のアクセス手段に対応するステータス情報の優先度を参照して、第一のステータス情報と第二のステータス情報のいずれを採用するかを判断する段階と、前記第二のアクセス手段を採用すると判断した場合、前記第二のステータス情報により、前記記憶した第一のステータス情報を上書きする段階とを実行させるコンピュータプログラム。請求項6に記載のコンピュータプログラムを記憶した、コンピュータ読み取り可能媒体。本発明のシステムと方法は、ネットワークに接続された装置を監視可能とすることにより、上記問題を解決する。従って、ネットワークを介して装置を監視する方法を説明する。該方法はハードウェアアクセスモジュールを介して第1のデータベースにアクセスするステップを含み、前記第1のデータベースは複数の通信プロトコルをサポートするように構成されている。第1のデータベースには、被監視装置の製造者やモデル情報等、様々な情報を取得するため複数の通信プロトコルにより使用される情報が格納されている。通信プロトコルが複数の通信プロトコルから選択され、選択された通信プロトコルが被監視装置からステータス情報を受信するように設定される。該方法は、前記第1のデータベースから選択された通信プロトコルと情報を用いて前記被監視装置を評価するステップと、前記アクセスされた装置からステータス情報を受信するステップと、前記受信したステータス情報を第2のデータベースDeviceODBCに格納するステップとを有する。他の実施形態において、本発明はネットワークを介して装置を監視する方法を提供する。複数の通信プロトコルは被監視装置から情報を読み出すために使用される。例えば、SNMPプロトコルが最初に被監視装置にアクセスするために選択され、SNMPプロトコルを用いて効率的に読み出せるように構成された装置情報が取得される。その後、前記装置がその他のHTTPおよびFTPプロトコル等をサポートしているとき、SNMPプロトコルを用いて効率的に読み出すことができない情報を取得するために、それらのプロトコルを選択する。プロトコルの選択は、データベースに格納されたサポート情報と併せてプロトコルマネージャにより実行される。本発明において、例えばLANやWANなどのネットワークに接続された少なくとも1つの装置被監視装置の監視が監視システムにより可能となる。前記被監視装置はユニークIPアドレスを有する。被監視装置に割り当てられたIPアドレスと、前記被監視装置のベンダー/製造者の詳細とは、データベースに格納される。ネットワークをスキャンして装置に問い合わせることにより、装置のIPアドレスを取得できる。その方法は既知である。それゆえ、監視される装置のIPアドレスはすでに取得され、データベースに格納されていると仮定する。本発明は、被監視装置から受け取ったHTML情報から必要な情報をいかに抽出するかを特定している。一旦、被監視装置のウェブページにアクセスするとすなわち、IPアドレスと特定されたポートを通じて、被監視装置に対応するウェブページが表示される。そのウェブページの情報はキーと値のペアである。例えば、カラープリンターのウェブページにおいて、トナーレベルはブラック100のように表示される。HTMLXMLパーサを用いて、ウェブページの情報から必要な情報を読み出すためにそのページを解釈する。HTML/XMLパーサを用いてウェブページから抽出した必要情報とパラメータ値はサポートデータベースに格納される。本発明は、ここで説明したように、監視システムによりサポートされた被監視装置のベンダーと装置モデルも特定する。被監視装置のいろいろなベンダーがそのベンダー固有のやり方で被監視装置に関する情報を提示しているので、本発明により被監視装置のベンダーとモデルを特定して被監視装置の動作状態を判断することができる。本発明の一態様によると、ネットワークを介して接続された被監視装置に関するステータス情報を抽出するために用いる、それぞれ通信プロトコルと関連した複数のプロトコルオブジェクトを初期化する方法、システム、及びコンピュータプログラム製品が提供される。これらは、1前記それぞれの通信プロトコル中の一通信プロトコルを選択し、2前記選択された通信プロトコルを用いて前記装置にアクセスするための情報を第1のメモリから読み出し、3前記選択された通信プロトコルと前記第1のメモリから読み出した情報を用いて前記装置にアクセスして前記装置に関するベンダー情報の取得を試み、4前記ベンダー情報が前記装置から取得されたかどうか判断し、5前記ベンダー情報が前記装置から取得された場合、前記通信プロトコルをそれぞれ用いて前記ステータス情報を抽出するサポート情報を第2のメモリから取得し、前記ベンダー情報と前記それぞれのサポート情報を前記複数のプロトコルオブジェクトの各プロトコルオブジェクトに格納し、6前記ベンダー情報が前記装置から取得されなかった場合、前記ベンダー情報を取得するまで、または前記通信プロトコルの各通信プロトコルが選択されるまで、前記1から5を繰り返す。本発明の他の態様によると、ネットワークを介して接続された被監視装置からどの種類のステータス情報を取得するかを判断する方法、システム、及びコンピュータプログラム製品が提供される。これらは、1前記装置からステータス情報を抽出するために用いる複数の通信プロトコルから一の通信プロトコルを選択し、2前記選択された通信プロトコルと関連するプロトコルオブジェクトを第1のメモリから読み出し、3前記一種類のステータス情報が第2のメモリにあるかどうか判断し、4前記判断において前記一種類のステータス情報が前記第2のメモリにあると判断された場合、前記プロトコルオブジェクトに格納されたステータス情報のウェイトが前記第2のメモリに格納された同種類のステータス情報と関連する対応するウェイトより大きいかどうかチェックし、5a前記判断において前記一種類のステータス情報が前記第2のメモリにないと判断された場合、またはb前記判断において前記一種類のステータス情報が前記第2のメモリにあるが、前記プロトコルオブジェクトに格納されたステータス情報のウェイトが前記第2のメモリに格納された同種類のステータス情報と関連する対応するウェイトより大きいと判断された場合、前記選択された通信プロトコルと前記プロトコルオブジェクトに含まれた前記装置を抽出する情報とを用いて前記装置にアクセスして前記ステータス情報を取得する。前記プロトコルオブジェクトは、一種類のステータス情報、前記ステータス情報の重み、前記前記選択された通信プロトコルを用いて前記装置から前記一種類のステータス情報を抽出するための情報を少なくとも含み、前記第2のメモリは前記装置から前もって抽出したステータス情報を有する。本発明のさらに他の態様によると、ネットワークを介して接続された少なくとも1つの監視装置に関する情報を管理する方法、システム、及びコンピュータプログラム製品が提供される。これらは、1前記少なくとも1つの被監視装置からステータス情報を抽出するために用いる複数の通信プロトコルから一の通信プロトコルを選択し、2前記選択された通信プロトコルと関連するプロトコルオブジェクトを第1のメモリから読み出し、3前記選択された通信プロトコルによりサポートされた前記少なくとも1つの被監視装置の一の被監視装置のベンダー名を前記プロトコルオブジェクトから取得し、4前記取得されたベンダー名に対応するモデル名を前記プロトコルオブジェクトから取得し、5前記取得したベンダー名とモデル名を用いて表現ストリング文字列を生成し、6前記表現ストリング文字列が第2のメモリにあるかどうか判断し、7前記判断において前記表現ストリング文字列が前記第2のメモリに無いと判断した場合、前記表現ストリング文字列を前記プロトコルオブジェクトと関連づけて前記第2のメモリに格納する。前記プロトコルオブジェクトは、前記少なくとも1つの被監視装置のベンダーとモデルの情報を含む。本発明のさらに他の態様によると、ネットワークを介して接続された被監視装置からステータス情報を抽出するのに必要な情報を管理する方法、システム、コンピュータプログラム製品が提供される。これらは、1前記被監視装置から前記ステータス情報を取得するために用いられる複数の通信プロトコルの一通信プロトコルを選択し、第1のメモリから表現ストリングを読み出し、3前記表現ストリングから前記ベンダー名と前記対応するモデル名を抽出し、4前記抽出されたベンダー名と前記抽出されたモデル名が前記被監視装置のベンダー名とモデル名にそれぞれマッチするかどうか判断し、5前記抽出されたベンダー名と前記抽出されたモデル名が前記被監視装置のベンダー名とモデル名にそれぞれマッチする場合、前記選択された通信プロトコルを用いて前記装置にアクセスして前記ステータス情報を取得する。前記表現ストリングは、前記選択された通信プロトコルによりサポートされたベンダー名と対応するモデル名を含む。本発明のさらに他の態様によると、どの通信プロトコルをネットワーク装置に関するステータス情報を取得するために用いることができるか判断する方法、システム、コンピュータプログラム製品が提供される。これらは、複数の通信プロトコルから一通信プロトコルを選択し、2前記選択された通信プロトコルを用いて前記ネットワーク装置にアクセスするための情報を前記ネットワーク装置と関連したデバイスオブジェクトから取得し、3前記選択された通信プロトコルと前記デバイスオブジェクトから取得した前記ネットワーク装置にアクセスするための情報とを用いて前記ネットワーク装置にアクセスできるか判断し、4前記判断において、前記通信プロトコルを用いて前記ネットワーク装置にアクセスできないと判断した場合、前記選択された通信プロトコルを用いて前記ネットワーク装置にアクセスするための情報を前記デバイスオブジェクトから削除し、5前記判断において、前記通信プロトコルを用いて前記ネットワーク装置にアクセスできると判断した場合、さらにテストをして、前記選択された通信プロトコルを用いて前記ネットワーク装置から前記ステータス情報を抽出することができるか判断する。さらに、前記さらなるテストは、1前記選択された通信プロトコルを用いて前記ネットワーク装置のベンダーを前記ネットワーク装置から取得できるかどうか判断し、2前記判断において前記選択された通信プロトコルを用いて前記ベンダーを取得できないと判断した場合、前記選択された通信プロトコルがジェネリックベンダーをサポートするかどうかチェックし、前記選択された通信プロトコルが前記ジェネリックベンダーをサポートしない場合、前記選択された通信プロトコルを用いて前記ネットワーク装置にアクセスするための情報を前記デバイスオブジェクトから削除し、3前記判断において前記選択された通信プロトコルを用いて前記ベンダーを取得できると判断した場合、前記ネットワーク装置から前記ベンダーを取得して前記選択された通信プロトコルによりその取得したベンダーがサポートされているかどうか判断し、4前記取得したベンダーが前記選択された通信プロトコルによりサポートされていない場合、前記選択された通信プロトコルが前記ジェネリックベンダーをサポートしているかどうかチェックし、前記選択された通信プロトコルが前記ジェネリックベンダーをサポートされていない場合、前記選択された通信プロトコルを用いて前記ネットワーク装置にアクセスするための前記情報を前記デバイスオブジェクトから削除し、5前記取得されたベンダーが前記選択された通信プロトコルによりサポートされている場合、モデル情報に関するさらなるテストを実行する。また、モデル情報に関するさらなるテストの実行は、1前記ネットワーク装置のモデルが前記選択された通信プロトコルを用いて前記ネットワーク装置から取得できるかどうか判断し、2前記判断において前記モデルが前記選択された通信プロトコルを用いて取得できないと判断された場合、前記選択された通信プロトコルがジェネリックベンダーをサポートしているかどうかチェックし、前記選択された通信プロトコルがジェネリックベンダーをサポートしていない場合、前記選択された通信プロトコルを用いて前記ネットワーク装置にアクセスするための前記情報を前記デバイスオブジェクトから削除し、3前記判断において、前記モデルが前記選択された通信プロトコルを用いて取得可能であると判断された場合、前記ネットワーク装置から前記モデルを取得し、前記取得したモデルが前記選択された通信プロトコルによりサポートされているかどうか判断し、4前記取得したモデルが前記選択された通信プロトコルによりサポートされていない場合、前記選択された通信プロトコルが前記ジェネリックモデルをサポートしているかどうかチェックし、前記選択された通信プロトコルが前記ジェネリックモデルをサポートしていない場合、前記選択された通信プロトコルを用いて前記ネットワーク装置にアクセスするための前記情報を前記デバイスオブジェクトから削除する。また、本発明の他の態様によると、ネットワークを介して接続された被監視装置に関する情報を選択された通信プロトコルを用いて抽出する方法、システム、及びコンピュータプログラム製品が提供される。これらは、1第1のメモリから複数の実装識別子を読み出すステップを有し、各実装識別子は、A前記選択された通信プロトコルを用いて前記被監視装置にアクセスして前記被監視装置のベンダー及びモデルの情報を取得する第1のアクセス関数と、B前記選択された通信プロトコルを用いて前記被監視装置にアクセスして前記被監視装置のステータス情報を取得する第2のアクセス関数とを特定するものである。前記方法は、2前記複数の実装識別子から一実装識別子を選択するステップと、3前記選択された通信プロトコルと前記選択された一実装識別子に関連した前記第1のアクセス関数とを用いて前記装置にアクセスして前記装置と関連するベンダーとモデルの情報を取得するように試みるステップと、4前記装置から前記ベンダーとモデルの情報を取得したか判断するステップと、5前記ベンダーとモデルの情報を前記装置から取得したと判断した場合、前記選択された一実装識別子を前記取得されたベンダーとモデルの情報と関連づけて第2のメモリに格納するステップと、6前記ベンダーとモデルの情報を前記装置から取得しなかったと判断した場合、前記ベンダーとモデルの情報を取得するまで、または前記複数の実装識別の各実装識別子が選択されるまで、前記選択するステップ、アクセスするステップ、及び判断するステップを繰り返すステップと、をさらに有する。さらにまた、本発明の他の態様によると、ネットワークを介して接続された異なる装置のうち一の被監視装置に関する情報を抽出するために選択された通信プロトコルにより用いられるように構成された情報を管理する方法、システム、及びコンピュータプログラム製品が提供される。これらは、1メモリから複数の実装識別子を読み出すステップを有し、各実装識別子は、A前記選択された通信プロトコルを用いて前記被監視装置にアクセスして前記被監視装置のベンダー及びモデルの情報を取得する第1のアクセス関数と、B前記選択された通信プロトコルを用いて前記被監視装置にアクセスして前記被監視装置のステータス情報を取得する第2のアクセス関数とを特定する。前記方法は、さらに、2前記複数の実装識別子のうち一の実装識別子を選択するステップと、3第1の記憶手段にアクセスして前記選択された通信プロトコルを用いて前記第1のアクセス関数と前記第2のアクセス関数のうち少なくとも一方を用いて前記被監視装置にアクセスするためのサポート情報を取得するステップと、をさらに有し、前記サポート情報は、前記被監視装置から前記ステータス情報または前記ベンダーとモデルの情報を取得するために使用する前提条件情報を含む。前記方法は、さらにまた、4少なくとも1つの第2の記憶手段に前記サポート情報を格納するステップをさらに有し、前記前提条件情報により、前記被監視装置から取得可能な一種類の関心情報の記憶領域が制限される。ここで、前記第1の記憶手段と第2の記憶手段は、同一の記憶手段であってもよい。さらにまた、本発明の他の態様によると、ネットワークを介して接続された被監視装置に関連する情報を抽出する方法、システム、及びコンピュータプログラム製品が提供される。これらは、1第1のメモリにアクセスして前記被監視装置にアクセスするためのアクセス情報を取得するステップを有し、前記アクセス情報は、前記被監視装置から取得する種類のステータス情報と前記被監視装置から前記種類のステータス情報を取得するために用いる前提条件情報とを含み、前記前提条件情報は、前記被監視装置から取得可能な前記種類のステータス情報の記憶領域を制限するために用いられる情報である。前記方法は、さらに、2前記被監視装置にアクセスして前記被監視装置に関連する情報文字列を取得するステップと、3前記前提条件情報を用いて前記情報文字列から前記種類のステータス情報に対応する情報を抽出するステップと、4前記被監視装置のIPアドレス等の識別情報と関連づけて前記抽出した情報を格納するステップと、を有する。さらにまた、本発明の他の態様によると、ネットワークを介して接続された被監視装置と関連する情報をSNMPプロトコルを用いて抽出する方法、システム、及びコンピュータプログラム製品が提供される。これらは、1メモリにアクセスして前記被監視装置にアクセスするためのアクセス情報を取得するステップを有し、前記アクセス情報は、A前記被監視装置から取得する一種類のステータス情報と、B前記被監視装置から前記一種類のステータス情報を取得するために用いるアクセス文字列とを含む。前記方法は、さらに、2前記アクセス文字列を分析して、前記アクセス文字列が記憶されていたかどうか判断し、前記アクセス文字列が記憶されていたとき、前記アクセス文字列が所定の文字列を含むかどうか判断するステップと、3前記分析するステップにおいて、前記アクセス文字列が記憶されていて、前記アクセス文字列が前記所定の文字列を含むと判断した場合、第1のSNMPアクセス関数を用いて前記被監視装置にアクセスして前記一種類のステータス情報と関連した値を取得するステップと、4前記分析するステップにおいて、前記アクセス文字列が記憶されていないか、または前記アクセス文字列が前記所定の文字列を含まないと判断した場合、第2のSNMPアクセス関数を用いて前記被監視装置にアクセスして前記一種類のステータス情報と関連した値を取得するステップと、を有する。前記メモリにアクセスするステップは、前記メモリにアクセスして前記被監視装置から取得すべき前記一種類のステータス情報に対応するオブジェクト識別子情報を取得するステップを有する。さらにまた、本発明の他の態様によると、選択された通信プロトコルにより使用される、ネットワークを介して接続された異なる装置のうちの被監視装置に関するステータス情報を抽出するように構成されたアクセス情報を表すデータをエンコードする方法、システム、及びコンピュータプログラム製品が提供される。これらは、1前記被監視装置のベンダー情報用のメモリ領域をバッファに確保するステップと、前記ベンダー情報を前記バッファに書き込むステップと、前記被監視装置のモデル情報用のメモリ領域をバッファに確保するステップと、を有し、前記モデル情報用のメモリ領域は前記ベンダー情報用のメモリ領域に関連づけられる。前記方法は、さらに、前記バッファに前記モデル情報を書き込むステップと、前記被監視装置から前記ステータス情報を取得するための前提条件情報を含む、前記被監視装置にアクセスするためのサポート情報用のメモリ領域をバッファに確保するステップと、を有し、前記サポート情報用のメモリ領域は、前記ベンダー情報用のメモリ領域及び前記モデル情報用のメモリ領域と関連づけられる。前記方法は、さらにまた、前記バッファに前記サポート情報を書き込むステップをさらに有し、前記前提条件情報により、前記被監視装置から取得可能な一種類の関心情報の記憶領域が制限される。さらにまた、本発明の他の態様によると、選択された通信プロトコルにより使用される、ネットワークを介して接続された異なる装置のうちの被監視装置に関するステータス情報を抽出するように構成されたアクセス情報を表すデータを含むメモリを有する監視装置が提供される。前記監視装置は、1複数の実装識別子を第1の記憶手段から読み出す読み出し手段を有し、各実装識別子により、前記被監視装置のモデル情報、一意的識別子、及びステータス情報のうち少なくとも1つを取得するために、前記選択された通信プロトコルを用いて前記被監視装置にアクセスするように定義された少なくとも1つのアクセス関数が特定される。前記監視装置は、さらに、2前記複数の実装識別子から一実装識別子を選択する選択手段と、3前記少なくとも1つのアクセス関数を用いて、第2の記憶手段にアクセスして前記被監視装置にアクセスするサポート情報を取得する取得手段と、を含み、前記サポート情報は、前記被監視装置から前記モデル情報、前記一意的識別子、及び前記ステータス情報のうちの前記少なくとも1つを取得するために使用する前提条件情報を含む。前記監視装置は、さらにまた、前記被監視装置の実装識別子及びベンダー情報と関連づけて前記サポート情報を前記アクセス情報を表すデータとして生成する生成手段を有し、前記前提条件情報により、前記被監視装置から取得可能な一種類の関心情報の記憶領域が制限されることを特徴とする監視装置。図1は、いろいろな装置と、その装置の動作を監視、診断、制御するコンピュータとを示す概略図である。具体的に、図1は、コンピュータワークステーション17、18、20および22に接続されたローカルエリアネットワークLAN等の第1のネットワーク16を含む。ワークステーションは、例えば、パーソナルコンピュータ、UNIX登録商標ベースのコンピュータ、リナックスベースのコンピュータ、アップルマッキントッシュ等を含むいかなるタイプのコンピュータであってもよい。また、デジタル画像形成装置24、ファックス28、プリンター32もネットワーク16に接続されている。当業者には明らかであるが、デジタルコピー/プリンター24とファクシミリ28を2つ以上組み合わせて、一体の画像形成装置とすることができる。例えば、コピー/プリンター24、ファックス28、プリンター32、ワークステーション17、18、20、22をマシンと呼び、あるいは被監視装置と呼ぶこともある。システム構成によっては、1以上のワークステーションはビジネスオフィス機器であってもよい。また、いかなるビジネスオフィス機器/装置をネットワーク16に付加してもよい。また、ワークステーション17、18、20、22、およびオフィス機器27は中間監視装置として機能することもでき、ネットワーク16上の被監視装置からデータを集め、集めたデータを監視装置に送信する。このようなビジネスオフィス機器の一例は、株式会社リコーのeCabinet登録商標である。また、ファクシミリサーバ図示せずをネットワーク16に接続して、電話、ケーブル、または無線で接続してもよい。デジタルコピー/プリンター24、ファクシミリ28、プリンター32は、各々ネットワーク16に接続されているのに加えて、従来の電話、ケーブル、または無線接続26、30、34も有する。以下に説明するように、被監視装置24、28、32は、監視装置とも呼ぶ遠隔監視診断制御ステーションと通信する。この通信は、例えば、ネットワーク16とインターネットを介して、または電話、無線、またはケーブル接続を介して直接行われる。他のビジネス環境において、被監視装置には、多機能画像化装置、スキャナー、プロジェクター、テレビ会議システム、およびシュレッダー等の装置が含まれてもよい。他のアプリケーションにおいて、ネットワーク16はホームネットワークでもよく、その場合、被監視装置は電気、ガス、水道等のメータであってもよく、例えば、電子レンジ、洗濯機、乾燥機、食器洗い機、ホームエンターテイメントシステム、冷蔵庫、炊飯器、ヒーター空調機、温水器、セキュリティカメラ等の機器であってもよい。図1において、ワイドエリアネットワークWAN例えば、インターネットやその後継ネットワークを参照符号10で示した。WAN10は、プライベートWANでも、パブリックWANでも、ハイブリッドタイプであってもよい。WAN10は、相互接続された複数のコンピュータとルータを含み、これらは参照符号12A12Iで示した。WANを介した通信方式は、インターネットエンジニアリングタスクフォースIETFから入手可能な一連のRequestforCommentsRFCにより知られている。、ウェブサイトwwwietforgrfchtmlを参照。例えば、RFC821SimpleMailTransferProtocol、RFC822StandardfortheFormatofARPAInternetTextMessage、RFC959FileTransferProtocol、RFC2045MultipurposeInternetMailExtensionsPartOneFormatofInternetMessageBodies、RFC1894AnExtensibleMessageFormatforDeliveryStatusNotifications、RFC1939PostOfficeprotocol-Version3、RFC2068HypertextTransferProtocol-HTTP11、及びRFC2298AnExtensibleMessageFormatforMessageDispositionNotifications等がある。これら引用文献の内容は参照によりここに援用する。トランスミッションコントロールプロトコル/インターネットプロトコルTCPIPに関連する通信は、例えば、WRStevens著TCPIPIllustratedVol1TheProtocols、AddisonWesleyPublishingCompany、1994年に説明されている。この書籍の内容はすべてここに参照により援用する。Comer、Stevens著TCPIPによるインターネットワーキング第1巻ないし第3巻もここに引用によりその全体を援用する。引き続き図1を参照して、ファイヤーウォール50AがWAN10とネットワーク16との間に接続されている。ファイヤーウォールは、その一方の側にある権限を与えられたコンピュータだけが、他方の側にあるネットワーク、コンピュータ、個別パーツにアクセスできるようにする装置である。ファイヤーウォールは商業的に入手可能な既知の装置またはソフトウェア例えば、ZoneLabs社のZoneAlarmである。同様に、ファイヤーウォール50Bと50Cは、WAN10をネットワーク52とワークステーション42からそれぞれ分離している。ファイアウォールに関するさらに詳細は、WRCheswick及びSMBellovin著FirewallsandInternetSecurityAddisonWesleyPublishing、1994年とDBChapman及びEDZwicky著BuildingInternetFirewallsO’ReillyAssociatesInc、1995年に載っている。これら2冊の引用文献の内容はここに参照により援用する。ネットワーク52は従来のネットワークであり、複数のワークステーション56、62、68、74を含んでいる。これらのワークステーションは分散され、一つの会社の異なる部署例えば、販売、注文処理、会計、請求、マーケティング、生産、設計エンジニアリング、カスタマーサービス等に配置されている。ネットワーク52を介して接続されたワークステーションに加え、ネットワーク52には直接接続されていないワークステーション42も設けられている。ワークステーション42に接続されたディスク46に格納されたデータベース中の情報を、ネットワーク52に直接接続されたワークステーションで、WAN10を介して適当な暗号化およびプロトコルを用いて共有することもできる。また、ワークステーション42は電話線、ケーブルネットワーク、及び/またはワイヤレスネットワーク44に直接接続され、ディスク46中のデータベースにはその電話線、ケーブルネットワーク、またはワイヤレスネットワーク44を通してアクセスできる。本発明で使用するケーブルネットワークは、一般的にテレビジョン番組を伝送するために使用するケーブルネットワーク、一般的にコンピュータ等で使用するデジタルデータの高速通信を提供するケーブル、またはその他望ましいタイプのケーブルを用いて実現される。他の実施形態において、ワークステーション42はラップトップコンピュータ、PDA、パームトップコンピュータ、またはネットワーク機能を有した携帯電話であってもよい。これらの装置を用いてディスク46に格納されたデータベース中の情報にアクセスしてもよい。デジタルコピー/プリンター24、オフィス機器27、ファクシミリ28、プリンター32それぞれに関する情報は、ディスク46、54、58、64、70、76に格納された1以上のデータベースに入れられる。既知のデータベースには、1マイクロソフト、IBM、オラクル、サイベースのSQLデータベース、2その他のリレーショナルデータベース、3非リレーショナルデータベース例えば、オブジェクティビティ、JYDソフトウェアエンジニアリング、オリエントテクノロジーのオブジェクト指向データベースを含むなどがある。販売、受注処理、会計、請求、カスタマーサービス、マーケティング、生産、エンジニアリング部門は各々自分のデータベースを有しても、1以上のデータベースを共有してもよい。データベースを格納するために使用する各ディスクは、ハードディスクまたは光ディスク等の不揮発メモリである。あるいは、データベースは、固体および/または半導体メモリデバイス等のいかなる記憶デバイスに格納してもよい。例えば、ディスク64にはマーケティングデータベースを格納し、ディスク58には生産データベースを格納し、ディスク70にはエンジニアリングデータベースを格納し、ディスク76にはカスタマーサービスデータベースを格納してもよい。あるいは、ディスク54と46に1以上のデータベースを格納してもよい。ワークステーション56、62、68、74、42は、WAN10への接続に加えて、監視診断制御されるマシン/装置とのセキュアな接続をするために、電話線、ケーブル、ワイヤレスネットワークに接続されていてもよい。また、通信媒体の一つが故障したとき、バックアップとして他の通信媒体を自動的に用いて通信を行う。本発明の特徴は、ストアアンドフォワードモードの通信例えば、インターネット電子メール、以下単に電子メールとも呼ぶ、すなわちマシンを診断制御するためのそのマシンとコンピュータ/監視システムとの間の送信を使用することにある。あるいは、FTPやハイパーテキストトランスファープロトコルHTTPのような直接のエンドツーエンドの例えば、最終目的地とのソケット接続を用いた接続をする通信モードを用いて、メッセージの送信を実現する。図2は、図1に例示したデジタルコピー/プリンター24の機械的構成を示す図である。図2において、101はスキャナー用のファンであり、102はレーザプリンターで使用されるポリゴンミラーであり、103はレーザ図示せずからの光をコリメートするために使用するFθレンズである。参照数字104はスキャナーからの光を検出するセンサーを指す。参照数字105は、スキャナーからの光をセンサー104にフォーカスするレンズを指し、参照数字106は感光体ドラム132上の画像を消去するために用いる消去ランプを指す。チャージングコロナユニット107および現像ローラ108がある。参照数字109はスキャンする文書を照射するためのランプを指し、構成要素110、111、112は光をセンサー104に反射するミラーを指す。ドラムミラー113は、ポリゴンミラー102からの光を感光体ドラム132に反射するために設けられている。ファン114は、デジタル画像形成装置のチャージングエリアを冷却するために使用する。第1の用紙送りローラ115は、第1の給紙カセット117から用紙を給紙するために使用する。参照数字116はマニュアル給紙テーブルを指す。同様に、第2の給紙ローラ118は第2のカセット119と併せて使用する。参照数字120はリレーローラを指し、121はレジストレーションローラを指し、122は画像濃度センサーを指し、123はトランスファー/セパレーションコロナユニットを指す。参照数字124はクリーニングユニットを指し、125はバキュームファンを指し、126は転送ベルトを指し、127はプレッシャーローラを指し、128はエグジットローラを指す。ホットローラ129は用紙にトナーを定着するために使用され、130は排気ファンを指し、メインモータ131はデジタルコピー/プリンター24をドライブするために使用する。図3は、図2のデジタルコピー/プリンター24の電子部品を示すブロック図である。CPU160は装置のコントローラとして機能するマイクロプロセッサである。ランダムアクセスメモリRAM162は、デジタルコピー/プリンター24の動作パラメータ等の動的に変化する情報を格納する。不揮発メモリ例えば、リードオンリーメモリROM164またはフラッシュメモリは、デジタルコピー/プリンター24を記述する静的状態データ例えば、装置のモデル名、モデル番号、シリアル番号、およびデフォルトパラメータのみでなく、そのデジタルコピー/プリンターを動作させるプログラムコードを格納している。マルチポートネットワークインターフェイス166が設けられ、デジタルコピー/プリンター24は少なくとも1つの通信ネットワークを介して外部の装置と通信可能である。参照数字168は、電話、ワイヤレス、またはケーブルラインを表し、参照数字170はネットワーク168とは別のタイプのネットワークを表す。マルチポートネットワークインターフェイスに関するさらに詳細は、図4を参照して説明する。インターフェイスコントローラ172はオペレーションパネル174をシステムバス186に接続するために使用する。オペレーションパネル174は、デジタルコピー/プリンター24の標準的入出力装置を含んでいる。標準的入出力装置とは、例えば、コピーボタンや、コピー枚数、拡大/縮小、濃度等の画像形成装置の動作を制御するためのキーなどである。また、液晶ディスプレイパネルがオペレーションパネル174に含まれており、デジタルコピー/プリンター24のパラメータやメッセージをユーザに表示する。ローカル接続インターフェイス171は、RS232、パラレルプリンターポート、USB、IEEE1394等のローカルポートを介した接続である。ファイヤーワイヤIEEE1394は、WickelgrenI著ファイヤーワイヤに関する事実IEEESpectrum、1997年4月、Vol34、Number4、1925ページに記載されている。その内容はすべてここに参照により援用する。エラー検出と再送信を含む信頼できる通信プロトコルを使用することが好ましい。ストレージインターフェイス176は、システムバス186にストレージ装置を接続する。例えば、ストレージ装置はフラッシュメモリ178とディスク182を含む。フラッシュメモリ178は従来の電気的消去可能プログラマブルリードオンリーメモリEEPROMで代替することができる。ディスク182は、ハードディスクドライブ、光ディスクドライブ、および/またはフロッピー登録商標ディスクドライブである。接続180を介して付加的記憶装置をデジタルコピー/プリンター24に接続してもよい。フラッシュメモリ178は、デジタルコピー/プリンター24の製品寿命にわたって頻繁には変化しないパラメータを表す準静的状態データを格納するために使用する。このようなパラメータには、例えば、デジタルコピー/プリンターのオプションや設定が含まれる。オプションインターフェイス184により、外部インターフェイス等の付加的ハードウェアをデジタルコピー/プリンター24に接続することができる。クロック/タイマー187を用いて時間と日付を常に把握したり、経過時間を測定したりすることができる。図3は、デジタルコピー/プリンター24を構成するいろいろなセクションも示している。参照数字202はソータを指し、デジタルコピー/プリンター24の出力をソートするために使用するセンサーおよびアクチュエータを含んでいる。デュプレクサ200によりデュプレックス動作を実行することができる。デュプレクサ200は従来のセンサーとアクチュエータを含む。大容量トレイユニット198が設けられ、多量の用紙を用紙トレイに保持することができる。デュプレクサ200と同様に、トレイユニット198も従来のセンサーとアクチュエータを含む。給紙コントローラ196を用いて、デジタル画像形成装置の給紙動作を制御することができる。スキャナー194を用いて画像をスキャンしてデジタル画像形成装置に取り込むことができる。スキャナー194は、光源、ミラー等の従来のスキャンエレメントを含んでいる。また、ホームポジションセンサー等のスキャナーセンサーを用い、スキャナーがホームポジションにいるかどうか判断する。また、ランプサーミスターを用い、スキャンランプが正しく動作することを保証する。プリンター/イメージャ192は、デジタル画像形成装置の出力を印刷する。従来のレーザ印刷メカニズム、トナーセンサー、及び画像濃度センサーを有している。フューザ190は、高温ローラを用いてトナーを用紙上に溶かす。エグジットセンサと、フューザ190がオーバーヒートしないことを保証するサーミスターと、オイルセンサーとを含む。また、オプショナルユニットインターフェイス188があり、デジタル画像形成装置の任意的構成要素への接続に使用される。任意的構成要素とは、例えば、自動文書フィーダ、異なるタイプのソータ/コレータ、その他デジタル画像形成装置に付加できる構成要素である。他のエレメントには、その装置の位置を特定することができるGPSなどが含まれる。図4は複数ポートネットワークインターフェイス166の詳細を示す図である。デジタル画像形成装置は以下のインターフェイスを介して外部装置と通信することができる:トークンリングインターフェイス220、ケーブル回線で高速接続を提供するケーブルモデムユニット222、電話ライン168Aに接続された従来の電話インターフェイス224、ワイヤレスインターフェイス228、LAN170に接続されたイーサネット登録商標インターフェイス230。その他のインターフェイスとしてデジタル加入者ラインDSLオリジナルDSL、コンセントリックDSL、アシンメトリックDSLもあるが、これに限定されない。単一の装置でローカルエリアネットワークと電話ラインの両方に接続できる製品がインテルから商業的に入手可能であり、IntelPro10100Modemとして知られている。CPU、その他のマイクロプロセッサ、または回路が監視プロセスを実行し、デジタル画像形成装置の各センサーの状態を監視する。シーケンスプロセスを用いて、デジタル画像形成装置を制御し動作させるための命令コードを実行する。また、1デジタル画像形成装置の動作全般を制御するために実行される中央システム制御プロセスと、2デジタル画像形成装置に接続された外部装置との信頼できる通信を確保するために使用する通信プロセスがある。システム制御プロセスは、静的メモリ例えば、図3に示したROM164、準静的メモリ例えば、フラッシュメモリ178やディスク182、動的メモリ例えば、RAM162、フラッシュメモリ178、ディスク182等の揮発性または不揮発性メモリのデータ記憶を監視および制御する。また、静的メモリはROM164以外のデバイスであってもよく、例えばフラッシュメモリ178やディスク182のいずれかを含む不揮発メモリであってもよい。上記の通り、デジタル画像形成装置について詳細を説明したが、本発明は他のビジネスオフィスマシンや装置にも同様に適用可能である。他のビジネスオフィスマシンや装置とは、例えば、アナログコピー、ファクシミリ、スキャナー、プリンター、ファクシミリサーバ、プロジェクター、会議機器、シュレッダー、その他のビジネスオフィスマシン、ビジネスオフィスアプライアンス、その他の機器例えば、電子レンジ、VCR、DVD、デジタルカメラ、携帯電話、パームトップコンピュータなどである。また、本発明には、ストアアンドフォワードまたはダイレクト接続ベースの通信を用いて動作するその他の装置も含む。そのような装置には、ガス、水道、電気のメータシステムを含むメータシステム、自動販売機、動作中の監視や遠隔診断が必要となるようなその他の機械的装置例えば、自動車、オートバイ、洗濯機、乾燥機などが含まれる。また、特定目的のマシンやコンピュータの監視に加え、本発明は汎用コンピュータの監視、制御、診断に使用でき、その場合は、その汎用コンピュータが監視及び/または制御される装置となる。図5は、本発明の別のシステムのシステム図であり、異なる装置やサブシステムがWAN10に接続されている。しかし、これらの装置やサブシステムの各々は、本発明の一部として必ずしも必須のものではない。図5に示した各コンポーネントやサブシステムは、個々に本発明の一部である。さらに、図1に示した構成要素を図5に示したWAN10に接続してもよい。図5には、イントラネット260-1に接続されたファイヤーウォール50-1が示されている。イントラネット260-1に接続されたサービスマシン254は、データベースフォーマットで格納されたデータ256を含むか、そのデータ256に接続されている。データ256には、被監視装置の履歴、性能、故障情報や、その他の動作、故障、設定に関する統計情報等、または被監視装置にどのコンポーネントや任意的機器が含まれているか等を示す構成情報が含まれている。サービスマシン254は、被監視装置にデータを送信するように要求し、またはその被監視装置にリモート制御および/または診断テストを実行することを要求する装置またはコンピュータである。サービスマシン254は、いかなるタイプの装置でもよく、好ましくは汎用コンピュータなどのコンピュータ化された装置を用いて実施される。また、サービスマシン254は、請求、会計、サービス処理、パーツトラッキング、およびレポートを含む様々なデータベースを有するネットワーク上の複数のコンピュータにより構成される。図5に示した他のサブシステムには、ファイヤーウォール502、イントラネット2602、それに接続されたプリンター262が含まれる。このサブシステムにおいて、プリンター262同様にコピー機286による電子メッセージを送受信する機能は、1回路、2マイクロプロセッサ、3プリンター262に含まれた、または搭載されたその他のタイプのハードウェアによりすなわち、別の汎用コンピュータを使用せずに実行される。別のタイプのサブシステムには、インターネットサービスプロバイダー264の使用を含む。そのインターネットサービスプロバイダー264は、いかなるタイプのインターネットサービスプロバイダーISPでもよく、アメリカオンライン、イーサリンク、ニフティサーブ等の既知の事業会社を含む。このサブシステムにおいて、コンピュータ266はデジタルまたはアナログモデム例えば、電話ラインモデム、ケーブルモデム、非対称デジタル加入者ラインADSLで使用されるモデム、フレームリレー通信を使用するモデム、無線周波数モデム等のワイヤレスモデム、光ファイバーモデム、赤外線を使用する装置を介してISP264に接続されている。さらに、ビジネスオフィス装置268はコンピュータ266に接続されている。ビジネスオフィス装置268または図5に示したその他の装置ではなく、異なるタイプのマシンを監視または制御してもよい。異なるタイプのマシンとは、例えば、デジタルコピー、すべてのタイプの機器、セキュリティシステム、ユーティリティメータ、例えば、電気、水道、ガスのユーティリティメータ、その他のここで説明する装置を含む。図5には、ネットワーク274に接続されたファイヤーウォール503も示されている。ネットワーク274はいかなるタイプのコンピュータネットワークでもよい例えば、イーサネット登録商標またはトークンリングネットワーク。ネットワークを制御するために使用するネットワークソフトウェアには、ノベルまたはマイクロソフトから商業的に入手可能なソフトウェア等を含むネットワークソフトウェアが含まれる。ネットワーク274は、必要に応じてイントラネットであってもよい。ネットワーク274に接続されたコンピュータ272は、ビジネスオフィス装置278から情報を取得し、ネットワークに接続されたいろいろなマシンで発生した問題を示すレポートや、ネットワーク274に接続された装置の月間使用レポート等を生成するために使用される。本実施形態において、コンピュータ276はビジネスオフィス装置278とネットワーク274の間に接続されている。このコンピュータはネットワークからの通信を受信し、適当なコマンド、データ、またはその他の情報をビジネスオフィス装置278に転送する。ビジネスオフィス装置278とコンピュータ276の間の通信は、有線ベースまたはワイヤレス方式を使用してなされる。その方式には、例えば、ラジオ周波数接続、電気的接続、光接続例えば、赤外線接続や光ファイバー接続等が含まれるが、これに限定されない。同様に、図5に示したいろいろなネットワークやイントラネットは、所望の方式でよく、例えば、無線周波数ネットワーク等のワイヤレスネットワーク方式でもよい。ここに説明したワイヤレス通信は、拡散コードとブルートゥース仕様書ウェブサイトwwwbluetoothcomで入手可能であるに開示された周波数ホッピングワイヤレス技術等を用いる技術を含む拡散スペクトルを用いて行うことができる。このブルートゥース仕様書はここに参照により援用する。図5に示した他のサブシステムには、ファイヤーウォール504、イントラネット2604、それに接続されたコンピュータ282、ビジネスオフィス機器285、コピー機286が含まれる。コンピュータ282を用いて、レポートを生成し、診断または制御プロシージャを要求する。これらの診断および制御プロシージャは、ビジネスオフィス機器285、コピー機286、または図5に示したその他の装置、またはそれらとともに使用する装置に対して実行してもよい。図5は複数のファイヤーウォールを示しているが、ファイヤーウォールは好ましいが任意的な機器であり、それゆえ、本発明はファイヤーウォールなしで使用することもできる。ネットワークされた機器の監視および制御のために、コンピュータ254ではなくどのコンピュータ266、272、または282を使用することもできる。また、いずれかのコンピュータがコンピュータ254にアクセスして、必要な装置情報や使用情報を、ウェブを介して読み出してもよい。図6Aは、典型的な電子メール交換システムに接続された装置/機器300を示しており、コンポーネント302、304、306、308、310、312、314、316、318を含んでいる。このシステムは従来例であり、上記引用文献Stevensの図28.1に基づき作成した。コンピュータインターフェイス302は、ここに説明したいかなるアプリケーションユニットや装置/機器300ともインターフェイスする。図6Aでは装置/機器300は送信元であるが、図6Aの送信と受信の機能は逆にしてもよい。さらにまた、もし望ましければ、ユーザは装置/機器300とインターフェイスする必要は必ずしもない。コンピュータインターフェイス302はメールエージェント304とインターラクトする。Unix登録商標用のメールエージェントとしては、MH、バークレーメール、Elm、Mushなどが人気がある。ウィンドウズ登録商標ファミリーのオペレーティングシステム用のメールエージェントには、マイクロソフトアウトルックとマイクロソフトアウトルックエクスプレスがある。コンピュータインターフェイス302の要求により、メールエージェント304は送信する電子メールメッセージを作成し、必要であれば、送信するこれらのメッセージをキュー306に入れる。送信すべきメールはメッセージトランスファーエージェントMTA308に送られる。Unix登録商標システム用の一般的なMTAはSendmailである。メッセージトランスファーエージェント308と312は、一般的には、TCPIP接続310を用いて通信する。特に、メッセージトランスファーエージェント308と312の間の通信は、ネットワーク例えば、WANまたはLANの大きさによらずに生じる。さらに、メッセージトランスファーエージェント308と312はどの通信プロトコルを使用してもよい。本発明の一実施形態において、図6Aの構成要素302と304は、アプリケーションユニットの使用を監視するライブラリにある。電子メールメッセージは、メッセージトランスファーエージェント312からユーザメールボックス314に格納され、メールエージェント316に転送され、最終的に受信端末として機能する端末318のユーザに送信される。送信メールエージェント304は、このストアアンドフォワードプロセスにより、メール受信者との直接接続が確立されるまで待つ必要が無くなる。ネットワーク遅延により、通信にはかなりの時間を要し、その間アプリケーションは応答しない。このような応答の遅延は、アプリケーションユニットのユーザには一般に受け入れがたいものである。電子メールをストアアンドフォワードプロセスとして使用することにより、通信が失敗した後一定期間例えば3日間、自動的に再送を試みることができる。別の実施形態において、アプリケーションは、1以上の別のスレッドに通信要求を送ることにより、待たなくて済む。これらのスレッドは、受信端末318との通信を制御することができ、一方、アプリケーションは、ユーザインターフェイスに再度応答をすることができる。さらに別の実施形態において、ユーザが通信を完了させたいと思っている場合、受信端末との直接通信を使用する。このような直接通信には、送受信端末間のファイヤーウォールによりブロックされないプロトコルであればいかなるものを使用することもできる。そのようなプロトコルの例としては、Telnet、ファイルトランスファープロトコルFTP、ハイパーテキストトランスファープロトコルHTTP等がある。インターネット等のパブリックWANは、一般的に安全であるとは言えない。それゆえ、メッセージを秘匿したいときは、パブリックWANおよび複数企業のプライベートWANを介して送信するメッセージは暗号化する。暗号化メカニズムは既知であり、商業的に入手可能であり、本発明とともに使用することができる。例えば、Cライブラリ関数cryptをサンマイクロシステムズから入手して、Unix登録商標オペレーティングシステムで使用することができる。暗号化および復号ソフトウェアパッケージが知られており、商業的に入手可能であり、本発明で使用することができる。パッケージの例として、PGPコーポレーションが出しているPGPがある。図6Aの一般的構造の替わりとして、コンピュータインターフェイス302、メールエージェント304、メールキュー306、メッセージトランスファーエージェント308として機能する単一のコンピュータを使ってもよい。図6Bに示したように、装置/機器300はコンピュータ301に接続されており、そのコンピュータ301はメッセージトランスファーエージェント308を含む。さらに別の構成を図6Cに示したが、この構成ではメッセージトランスファーエージェント308が装置/機器300の一部となっている。さらに、メッセージトランスファーエージェント308はメッセージトランスファーエージェント312とTCPIP接続310により接続されている。図6Cの実施形態において、装置/機器300は、電子メール機能を有するTCPIP接続310に直接接続されている。図6Cの実施形態の使用には、例えば、RFC2305インターネットメールを用いた単一モードのファクシミリに規定された電子メール機能を有するファクシミリを装置/機器300として使用することが含まれる。図6Dに示したシステムは、装置/機器300が自分では電子メールを直接受信する能力を有していないが、メッセージトランスファーエージェント308とメールボックス314を含むメールサーバ/POP3サーバとの接続310を有し、装置/機器300がPOP3プロトコルを使用してメールサーバから受信メールを読み出す。図7は、メール転送の別の実施形態を示す図であり、前に参照した引用文献Stevensの図28.3に基づき作成したものである。図7は、リレーシステムを各端に有する電子メールシステムを示す。図7の構成により、組織の一システムをメールハブとして機能させることができる。図7において、2つのメールエージェント304と316の間に4つのMTAが接続されている。その4つのMTAは、ローカルMTA322A、リレーMTA328A、リレーMTA328B、およびローカルMTA322Dである。メールメッセージで最も一般的なプロトコルはSMTPシンプルメールトランスファープロトコルであり、このプロトコルを本発明に使用することができるが、他のメールプロトコルを使用することもできる。図7において、参照数字320はコンピュータインターフェイス302、メールエージェント304、ローカルMTA322Aを含む送信ホストを指す。装置/機器300はこの送信ホスト320に接続されるか、あるいはその中に含まれている。他の場合として、装置/機器300とホスト320は、ホスト機能が装置/機器300に組み込まれた1つのマシンであってもよい。他のローカルMTA322B、322C、322E、322Fが含まれていてもよい。送受信メールは、リレーMTA328Aのメールキュー306Bの待ち行列に入れられる。メッセージはTCPIP接続310例えば、インターネット接続またはその他のタイプのネットワークにわたる接続により転送される。送信メッセージはリレーMTA328Bにより受信され、必要に応じてメールキュー306Cに格納される。メールはその後受信ホスト342のローカルMTA322Dに転送される。メールは1つ以上のユーザメールボックス314に入れられ、その後メールエージェント316に転送され、最後に端末318のユーザに転送される。必要に応じて、メールは、ユーザによる関与無しに端末に直接転送される。図5のコンピュータ266と276を含めて、本発明で使用される様々なコンピュータは、図8に示したようなものである。さらに、本発明で使用される他のコンピュータは、図8に示したコンピュータと同様なものであり、必要に応じて、図5に示したサービスマシン254、コンピュータ272、コンピュータ282を含んでもよい。しかし、これらのコンピュータの各々において、図8に示したすべての構成要素が必要なわけではない。図8において、コンピュータ360はCPU362を含む。このCPU362は、インテル、AMD、モトローラ、日立、NEC等の会社から商業的に入手可能なマイクロプロセッサを含む、いかなるタイプのプロセッサであってもよい。RAM364等のワーキングメモリと、ワイヤレスデバイス368と通信するワイヤレスインターフェイス366がある。インターフェイス366とデバイス368の間の通信には、いかなる無線媒体例えば、ラジオ波や光波を使用してもよい。ラジオ波は、符号分割多重アクセスCDMA通信等の拡散スペクトル技術や、ブルートゥース仕様書に開示されている周波数ホッピング技術を用いてもよい。コンピュータ360はROM370とフラッシュメモリ371とを含むが、他のいかなるタイプの不揮発性メモリ例えば、消去可能プログラマブルROM、またはEEPROMをフラッシュメモリ371に加え、またはそれの替わりに使用してもよい。入力コントローラ372にはキーボード374およびマウス376が接続されている。シリアルインターフェイス378があり、シリアルデバイス380が接続されている。また、パラレルインターフェイス382はパラレルデバイス384に接続されており、ユニバーサルシリアルバスUSBインターフェイス386はユニバーサルシリアルバスデバイス388に接続されており、またIEEE1394デバイス400一般に、ファイヤーワイヤデバイスと呼ばれるがあり、IEEE1394インターフェイス398に接続されている。システムバス390にはコンピュータ360のいろいろな構成要素を接続する。ディスクコントローラ396には、フレキシブルディスクドライブ394とハードディスクドライブ392が接続されている。コンピュータ360は、通信コントローラ406により、ネットワーク404を介して、例えば、電子メールメッセージを送信することにより他のコンピュータと通信することができる。IO入出力コントローラ408には、例えば、SCSISmallComputerSystemInterfaceバスを用いてプリンター410とハードディスク412が接続されている。CRT陰極線管414が接続されたディスプレイコントローラ416もある。ディスプレイはいかなるタイプでもよく、例えば液晶ディスプレイ、発光ダイオードディスプレイ、プラズマディスプレイ等であってもよい。図9は、本発明の一実施形態によるシステム900の全体を示す概略図である。システム900は、レーザプリンター908、スキャナー910、ネットワーク装置912、多機能プリンター914など複数の装置を含んでおり、これらはすべてネットワーク100に接続されている。これら複数の装置は一般的にここで被監視装置と呼ぶ。システム900には、ネットワーク100に接続され被監視装置908、910、912、914を監視および制御するワークステーション/監視システム902以下、コントローラ902と呼ぶも含まれている。各被監視装置908、910、912、914には一意的なアドレスが与えられている。例えば、装置に割り当てられたIPアドレスはその装置の一意的なアドレスとして機能する。このように、コントローラ902のユーザは、それぞれの被監視装置に割り当てられた一意的なIPアドレスにアクセスすることにより、各被監視装置908914にアクセスすることができる。当然のことながら、本発明においては、IPアドレスを用いてネットワークに接続された装置を一意的に特定する必要は必ずしもない。コントローラ902は、被監視装置908914の1つにアクセスする際、SNMP及び/またはHTTPプロトコルでいろいろな情報を取得する。情報の例としては、トラブルシューティング情報を含む、装置の動作状態に関する詳細な情報がある。例えば、コントローラ902は、ある装置にアクセスし、そのジャム位置を取得し、そのジャムを解消するためにその装置の管理者にメッセージを送信する。レーザプリンター908の動作状態/詳細情報には、トナーレベル、ペーパージャムの表示、プリンタートレイにある印刷用紙の枚数等の詳細情報が含まれる。当然のことながら、コントローラ902はネットワーク100と物理的に接続されていても、ワイヤレスで結合されていてもよい。例えば、パーソナルデジタルアシスタントPDA920やラップトップコンピュータ922は、ネットワーク100にワイヤレスに結合しているように示されているが、コントローラ902として使用することもできる。アクセスポイント924は、ネットワーク100とPDA922またはラップトップコンピュータ922との間のワイヤレス通信を可能とするインターフェイスとして機能する。ここからは、コントローラ902がネットワークに接続されている被監視装置の状態を制御および監視するという仮定の下に本発明を説明する。ネットワーク100により、コントローラ902と被監視装置908-914の間の通信が容易になり、被監視装置の監視と制御が可能となる。ネットワークに接続された装置の数は、本発明を限定するものではない。当然のことながら、ネットワーク100はローカルエリアネットワークLANまたはワイドエリアネットワークWANである。同様に、被監視装置908、910、912、914は例として示されたものである。コントローラ902は、記憶装置904とデータベース906に通信可能に結合している。記憶装置904には、ハードディスクドライブ、光ディスクドライブ、及び/または外部ディスクドライブが含まれる。データベース906は記憶装置904に通信可能にリンクされており、記憶装置904に格納されたデータを容易に検索し読み出すためのリレーショナルデータベースマネージメントシステムRDBMSを含んでいる。記憶装置904は、好ましくは、各被監視装置908-914に関する詳細情報を格納している。例えば、レーザプリンター908のメーカー、モデル、いろいろな機能およびトラブルシューティングの詳細等の詳細情報が記憶装置904に格納されている。また、所定の基準値と比較したレーザプリンターの動作状態に関する偏差値を記憶装置904に格納してもよい。データベース906と記憶装置904はコントローラに通信可能に結合していると説明したが、当然のことながら、コントローラ902が記憶装置と一体に構成され、データベースがそれにインストールされていてもよい。そのような場合、記憶装置906とデータベース904はコントローラ902に内蔵されているものとして示す。コントローラ902は、複数の装置908-914の監視と制御を容易にするために、ソフトウェアでインストールされてもよい。コントローラ902は複数の装置908-914を監視するためにシンプルネットワークマネージメントプロトコルSNMP、ファイルトランスファープロトコルFTP、およびハイパーテキストトランスファープロトコルHTTPを使用する。その複数の装置908-914から受信したデータは950で示したようにASN1バイナリーフォーマット、HTMLフォーマット、またはXMLフォーマットの形式で表される。図9には画像化装置のみを示したが、監視装置と複数の被監視装置の間で情報を通信するためのネットワークには、機器とメータがネットワークに接続されたホームネットワークを含めてもよい。当然のことながら、コントローラ/ワークステーション902により収集されたデータは、さらに処理するために、電子メール、FTP、その他の通信プロトコル手段を介してリモート装置に送信される。ワークステーション902、PDA920、またはラップトップコンピュータ922は、データを収集し、それを格納または通信プロトコルを使って送信するコントローラでもよく、そのコントローラはネットワークに接続されているどの装置であってもよい。どのネットワーク装置例えば、プリンターにも、ネットワーク中の他の装置の状態を監視し、収集したデータを格納し、および/または収集したデータを他の通信プロトコル手段例えば、電子メール、FTPを通じて送信することができる監視システムの機能を持たせることができる。監視システムのアーキテクチャ図10は、本発明の一実施形態による、リモート装置に関連したデータの監視に使用される監視システム1000および、関連するインターフェイス機能を示す。監視システム1000は、ソフトウェアモジュールMonitorService1004を含む。このソフトウェアモジュールMonitorService1004は、NTやウィンドウズ登録商標2000のサービスやUnix登録商標のデーモン等のコンピュータ常駐プログラムである。好ましい実施形態において、監視システムはオブジェクト指向ソフトウェア環境を用いて実装されている。また、Timerタイマーモジュール1002とMonitorモニターモジュール1006が監視システム1000に含まれている。タイマーモジュール1002とMonitorモジュール1006は、MonitorServiceモニターサービスモジュール1004により呼び出されるライブラリ関数である。例えば、MonitorService1004は、InitTimer1003関数を呼び出してTimerモジュール1002を初期化し、obtainDelayAndAction関数を呼び出して遅延および動作パラメータを取得する。図13に示したように、init関数は、MonitorServiceモジュール1004によっても呼び出され、Monitorモジュール1006のいろいろなモジュールを初期化する。init関数を用いて、既知の方法で収集されたIPアドレス、パラメータ名、パラメータ値を含む外部ソースを通じて、被監視装置に割り当てられたIPアドレスとパラメータ値を取得することができる。Monitorモジュール1006は、サポートデータベース1024と監視データベース1014に通信可能に結合される。これらのデータベースは後でより詳しく説明する。一旦被監視装置のIPアドレスを取得すると、監視システムは、そのIPアドレスを用いて被監視装置にコンタクトして製造者ベンダーおよびモデル等の情報を取得する。監視システム1000により実行される関数には以下の関数がある。voidinitTimerこの関数はタイマーを初期化する。特に、この関数がトリガーになって、Timerオブジェクトがレジストリからタイミング情報を入手する。voidobtainDelayAndActionこの関数は、Sleep関数1000倍する必要があると動作インジケータのために、秒単位の遅延時間を返す。動作インジケータは以下のように定義されている:0=イベントチェック中;1=被監視データを送信中;2=データを監視してローカルデータベースに格納中。intinitこの関数はMonitorを初期化する。また、監視される装置を生成する。戻り値はエラーコードであり、ゼロはエラーなしを表すと決められている。intmonitorStatusこの関数はプリセット情報を監視する。戻り値はエラーコードであり、ゼロはエラーなしを表すと決められている。intendこの関数はオブジェクトをクローズする前にMonitorをクリーンアップする。戻り値はエラーコードであり、ゼロはエラーなしを表すと決められている。モニターモジュール図11は、Monitorモニターモジュール1006の構造の詳細を示し、いろいろなソフトウェアサブモジュールとサブモジュール間の呼び出し関数とを含んでいる。Monitorモジュール1006は、多数のモジュールにより使用されるクラスを含むCommonコモンモジュール1101、及び他のサブモジュールDeviceODCBモジュール1104、Deviceデバイスモジュール1110、HWaccessHWアクセスモジュール1116を管理するMonitorManagerモニターマネージャモジュール1102とを含み、図10に示したようにインターフェイス機能により規定されたタスクを完了する。具体的に、DeviceODBCデバイスODBCモジュール1104は、標準インターフェイスを通じて外部装置情報にアクセスするために、アクセスされる。HWaccessモジュール1116は、複数の通信プロトコル例えば、HTTP、SNMP、FTPのうちから選択された通信プロトコルを用いて、被監視装置からベンダー、モデル、一意的ID、ステータス情報を取得する。各Monitorソフトウェアモジュールは、以下により詳細に説明する。上で説明したMonitorモジュール間のインターフェイスの一部を以下に説明する。例えば、モジュールによっては、便利なフォーマットで情報を取得するために、initその他の関数が必要である。voidupdateConfigこの関数を呼ぶ前に、呼んでいる関数は、obtain関数がnullストリングを返した場合、ベンダーとモデルのエントリーを置き換えないことが好ましい。この関数は、DeviceODBC1104の装置情報データベースのカレントレコードを更新する。この関数は、下記のObtainConfigが最初に呼ばれた時に最も効率的である。この関数は、最初に、IPアドレスがDeviceODBC1104と同じかどうかをチェックする。IPアドレスフィールドが同じでない場合、正しいIPアドレスのレコードをデータベースから取得する。そして、他のフィールドがコピーされ、レコードが更新される。boolobtainConfigこの関数は、DeviceODBC1104から所与のフォーマットの装置情報のマップと、プロトコルとそれに関連するパラメータのマップとを取得する。この関数は返すデータがあれば真を返し、データがもうなければ偽を返す。boolsaveStatusこの関数は、ステータス情報をDeviceODBC1104に保存する。保存が成功した場合、真を返し、失敗した場合、偽を返す。CDevicecreateDeviceこの関数は、insIPとinProtocolParametersに基づき装置を生成する。生成された装置は、CHWaccessを通じてハードウェアに接続される。装置を生成できないとき、0を返す。したがって、呼んでいるオブジェクトは、リターンオブジェクトポインタが0かどうかをチェックしなければならない。boolcanAccessHWこの関数は、ハードウェアがネットワークを通じてアクセスできる時に真を返し、そうでない時に偽を返す。boolgetVendorこの関数はベンダー名を返す。その装置がシステムによってサポートされていないが、プロトコルの1つを通してアクセス可能なときは、ストリングにGENERICと表示される。プロセス中でエラーを検出すると、本関数はnullストリングと偽を返す。そうでない時は真を返す。boolgetModelこの関数は装置のモデルを取得する。モデルを取得すると、関数は真を返す。プロセス中でエラーを検出すると、本関数はnullストリングと偽を返す。boolgetUniqueIDこの関数は装置の一意的IDを返す。一意的IDを取得すると、関数は真を返す。プロセス中でエラーを検出すると、本関数はnullストリングと偽を返す。boolobtainStatusこの関数は状態マップを返す。本関数は、状態が返されたとき真を返し、状態を取得できなかったとき偽を返す。この関数はHWaccessとDeviceモジュールでは異なるマップを返すことに注意を要する。Deviceモジュールでは、イベントステータス情報はHWaccessから返されたマップに付加され、クリアされる。enumcheckEventStatusこの関数はネットワーク装置のイベントを取得するトリガーとして機能する。enumタイプと値はクラスで定義しなければならない。enum値は値eNoEventSinceClearAndNoEventDetected、eNoEventSinceClearAndEventDetected、eEventSinceClearAndNoEventDetected、及びeEventSinceClearAndEventDetectedを含まねばならない。boolobtainEventStatusこの関数はイベントステータス情報を取得する。本関数は、状態が返されたとき真を返し、状態を取得できなかったとき偽を返す。voidclearEventStatusこの関数は最後のobtainStatusまたはclearEventStatusのファンクションコール以降に集積されたイベントステータスをクリアする。voidinitBeginこの関数は、HWaccessを通じて初期化プロセスを開始し、具体的にはソフトウェアデバイスオブジェクトを生成する初期化プロセスを生成する。voidinitEndこの関数はHWaccessを通じて初期化プロセスを終了させるが、これはデバイスオブジェクトの生成が終了することを示す。boolcanAccessIPこの関数は、IPアドレスで装置にアクセスできるとき真を返し、そうでないとき偽を返す。boolobtainVendorこの関数はベンダーを取得する。この関数は、正常に動作したとき真を返し、そうでなければ空のストリングとともに偽を返す。このファンクションコールの間、プロトコルが調べられ、特定のプロトコルがステータス監視に使用できないとき、そのプロトコルはinOutProtocolParametersから削除される。boolobtainModelこの関数はモデル名を取得する。この関数は、正常に動作したとき真を返し、そうでなければ空のストリングとともに偽を返す。このファンクションコールの間、プロトコルが調べられ、特定のプロトコルがステータス監視に使用できないとき、そのプロトコルはinOutProtocolParametersから削除される。boolobtainUniqueIDこの関数は一意的IDを取得する。この関数は、正常に動作したとき真を返し、そうでなければ空のストリングとともに偽を返す。このファンクションコールの間、プロトコルが調べられ、特定のプロトコルがステータス監視に使用できないとき、そのプロトコルはinOutProtocolParametersから削除される。EerrorCodeobtainEventStatusこの関数はイベントステータスを取得する。ErrorCodeは後で定義する。boolobtainStatusこの関数は装置のステータスを取得する。この関数は、正常に動作したときは真を返し、そうでないときは空のマップとともに偽を返す。図12は、図11に示したように、HWaccessモジュール1116により受信されたキー値と関連する値の読み出しの情報を交換するために、HWaccessモジュール1116により使用されるデータ構造を示す図である。例えば、図12に示したように、SKeyValueInfoデータ構造は、所与のウェブページ内のminfoType1202に対応する特定の情報タイプに対応する情報をいかに取得するかを決定するために使用される。一般に、多数のベンダーは、ベンダー特有の識別子と用語を使用して、それぞれのウェブページに表示された被監視装置に関するキー情報を特定する。例えば、プリンター装置により印刷されるページ数を決定するために、あるベンダーはPageCountを使用し、他のベンダーはTotalSheetDeliveredを使用する。本発明の特徴は、ベンダーごとの違いを克服し、それにより装置特有の情報を識別する標準化され統一的方法を提供し、データ構造SKeyValueInfo構造1200を使用することにより、その情報に対応する値を抽出することである。SKeyValueInfoデータ構造1200は公開された属性を含んでいる。SKeyValueInfoは、データストリングまたはキーストリングの形式で被監視装置から受信した情報から、値情報を特定するために生成されたデータ構造である。SKeyValueInfoは複数のフィールドを含み、各フィールドは図12に示した情報により表される。SKeyValueInfo構造1200は、ストリングキーを表すmsKeyフィールド1204と、好ましくは値情報の位置を特定できるストリング中の位置の数を示すタグベースの値であるmnPositionフィールド1206と、mnInLinePositionフィールド1212とを含む。例えば、プリンター装置のPageCountは、監視することを前提として、キーワードに続く第2の位置に見つかる。msType1208は、被監視装置の表示されたウェブページから読み出すことができる情報のタイプを表す。例えば、被監視装置のモデル名がキー製品名の同じデータライン内に見つかった時、mnPositionフィールドは0である。msDelimitor1210は、そのキーと関連する値を抽出するために使用される特定のデリミターを示す。SKeyValueInfoデータ構造は、HTMLフォーマットで被監視装置から受信した情報から値情報をいかに抽出するかを示す。図13は、図10に示した、Monitorモジュール1006の呼び出しシーケンスを説明するinit関数のシーケンスを示す。MonitorManager1102は、HWaccessモジュール1116を初期化して初期化関数を開始する。そして、MonitorManager1102は被監視装置に関する情報を取得し、被監視装置に割り当てられたIPアドレスを用いてその被監視装置と通信する。MonitorManager1102は、DeviceODBC1104にアクセスし被監視装置の設定情報を取得する。MonitorManager1102に返される設定情報は、例えば、被監視装置のIPアドレス、各プロトコルのパラメータ名とそれに関連する値、被監視装置のベンダー/製造者及びモデル情報が含む。一旦IPアドレスを取得すると、MonitorManager1102は、各プロトコルについてそのIPアドレス、パラメータ名、それに関連する値を設定し、図35のCDeviceFactoryクラス1302を通じてDeviceモジュール1110のクラス構造に基づきソフトウェアオブジェクトを生成する。デバイスソフトウェアオブジェクトが正常に生成されると、HWaccessモジュール1116を用いて、被監視装置からベンダー、モデル、一意的IDを取得し、生成されたデバイスソフトウェアオブジェクトに格納する。一旦デバイスソフトウェアオブジェクトからベンダー、モデル情報、一意的IDを取得すると、MonitorManager1102は被監視装置から受信した情報でデータベース例えば、DeviceODBC1104を更新する。図13には1つの装置を示したが、obtainConfigからupdateConfigまでのステップを繰り返し、外部ソースで指示された装置すべてをカバーする。また、図23、24、25、26に示した各プロトコルが初期化される。図24、25、26に示したODBCに対応するデータベーステーブルにアクセスし、アクセスされた装置からのステータス情報の収集が速くなるように、アクセスされた装置の必要情報を外部記憶から内部データ構造に転送する。図14は、図11に示した、MonitorManagerモジュール1102による被監視装置のステータスを決定するためのステータス監視機能のシーケンスを示す。DeviceからHWaccessにobtainStatus関数が発行されると、CHWaccessクラスは、以下に説明するように、異なるパラメータを用いて、抽象型クラスを通じて図23、24、25、26に示した各プロトコルに対してobtainStatus関数コールを順次発行する。各プロトコルモジュールは被監視装置からステータス情報を抽出するのに必要な情報をすでにキャッシュしている。その被監視装置は、図13に示した初期化時にすでにアクセスされている。それゆえ、ステータス情報は、ステータス監視の際に外部ソースにアクセスすることなく、被監視装置から素早く抽出することができる。このプロセスは、図15に示したベクトルに格納されたすべての被監視装置について繰り返される。図15を参照して、ベクトル1500が示されており、図13と14に示されたように、図35のCDeviceFactory1302により生成され、MonitorManager1102により使用される装置を参照している。MonitorManager1102は、例えば、図35のCDeviceFactory1302により生成されたCDeviceオブジェクト1502へのポインタ、CDeviceオブジェクト1504へのポインタ等のデバイスポインタをベクトルに格納している。ベクトルシーケンスが繰り返され、被監視装置のステータスを取得する。obtainStatusコマンドを発行することにより、装置オブジェクトに被監視装置のポーリングを実行する。各ソフトウェアオブジェクトのステータスを一旦取得すると、そのステータスはDeviceODBC1104を通じて更新される。ステータス監視シーケンスは、図14を参照して上で説明したので、ここでは説明を繰り返さない。テーブルIに示したDeviceInfo構造は、被監視装置の一例に関する情報を示している。DeviceInfo構造は、連絡を取る人物の電話番号に加えて電子メールアドレスを含んでいる。監視データベース図19は監視データベースの組織を示し、各被監視装置の装置情報を含んでいる表1も参照。図19に示したように、各通信プロトコル例えば、SNMP、HTTP、FTPに対して一組のパラメータが、各被監視装置の装置情報DeviceInfo1902と関連している。さらに、1つのプロトコル例えば、SNMP1908、HTTP1910、FTP1912の各パラメータの組は、パラメータ名と値のペア例えば、sPar1NameとsPar1Valueのリストとしてまとめられている。各プロトコルのパラメータ数は、図19に示した数よりも少ない場合も多い場合もあることに注意すべきである。例えば、ある被監視装置については、ユーザ名とパスワードはFTPパラメータとして格納され、一方、コミュニティ名とパスワードはSNMPパラメータとして格納される。図19に示したように、監視データベースはDeviceHistory1904とEnumCorrespondence1906に関する情報も含む。図17はSParameterデータ構造1700を示し、このデータ構造はいろいろな通信プロトコルにより使用されるパラメータをパスするために使用される。Sparameterは2つのフィールドを含む。SParameterは2つのフィールドmsParName1702とmsParValue1704を含み、それぞれパラメータの名前と値を表す。図18は、マップ構造1800を示し、このマップ構造は、監視データベースから取得した各プロトコルのパラメータのベクトルを各被監視装置に関連するソフトウェアオブジェクトにパスするために使用される。マップ構造1800は、各プロトコル/キーフィールド1802、1804、1806を、図17に示したSParameterフォーマットに従って構成した対応するパラメータ1808、1810、1812のベクトルそれぞれと関連づける。例えば、SNMPプロトコル1802の場合、パラメータベクトル1808は、SNMPプロトコルを用いて被監視装置にアクセスするために使用するパラメータ名、パラメータ値ペアのリストを含んでいる。例えば、ベクトル1808に格納されるSNMPパラメータ名は、対応するパラメータ値とともにコミュニティ名とパスワードを含んでいてもよい。しかし、マップ構造1800では、プロトコルとそれに付随するパラメータベクトルの数はいくつでもよく、図18に示したSNMP、HTTP、FTPプロトコルに限定されない。サポートデータベース図20ないし図22は、図10に示したサポートデータベース1024の構成を示す。サポートデータベースは、各被監視装置からステータス情報を抽出するのに必要な情報を含み、通信プロトコルにより構成されている。例えば、図20は、被監視装置から情報を抽出するために使用するSNMP関係のサポート情報のサポートデータベースの構成を示し、データ構造SNMPVendor2002、SNMPComVendorStatus2004、EnumCorrespondence2006、SNMPVendorModelStatus2008を含む。サポートデータベースのデータ構造は、抽出を制御するパラメータと合わせて、抽出するステータス情報のタイプを一意的に特定するパラメータを含む。例えば、SNMPComVendorStatusデータ構造2004は、抽出する情報のタイプ例えば、トナーレベルを特定するnENUMフィールド2009と、他のプロトコルに関する抽出情報の重みや重要性を示すnRelativePriorityフィールド2010を含む。このように、同じ情報が2以上のプロトコルを用いて被監視装置から抽出される場合、nRelativePriority値がどのプロトコルで抽出された値を使用するかに関する表示を与える。例えば、HTTPはトナーレベルの高低を表示する情報だけを抽出でき、一方、SNMPプロトコルは残りのトナーのパーセンテージを抽出できる場合、SNMPのトナーレベルの優先レベルがHTTPの対応する値よりも高くなるであろう。また、サポートデータベースでは、プロトコル全体にデフォルトの優先値をつけてもよい。一実施形態において、プロトコル値が0から32000の範囲であるシステムにおいて、SNMPプロトコルには優先値10000を与える。図21と22は、サポートデータベース1024のHTTPとFTP部分に含まれるデータ構造を示し、図20を参照して上で説明したデータ構造に類似したデータ構造を含んでいる。本発明で使用するenumタイプの例は、以下に定義するinfoTypeである。enumタイプは単なる一例であり、本発明を限定するものとして解釈してはならない。infoTypeこのセクションではinfoTypeの定義を説明する。データタイプには0から99までの範囲の値が割り当てられている。100から499までの値の範囲が装置情報に割り当てられている。500から1999の値の範囲が標準MIBパラメータを含む共通パラメータに割り当てられている。2000から3999の範囲がリコー特有の情報に割り当てられている。4000から4999の範囲がVendor1に割り当てられている。5000から5999の範囲がVendor2に割り当てられている。6000から6999までの範囲がVendor3に割り当てられている。値は以下のように決められる:infoTypeeNotDefine0eDeviceInformation1eStatusInformation2eVendor100eModeleUniqueIDeIPAddresseCompanyNameeStreeteCityeStateeZipCodeeLocationeContactPersonePhoneNumbereEMailAddresseDateTime500eHrDeviceErrorseLowPapereNoPapereLowTonereNoTonereDoorOpeneJammedeOfflineeServiceRequestedePrtGeneralConfigChanges600ePrtLifeCountePrtAlertDesc1ePrtAlertDesc2ePrtAlertDesc3ePrtAlertDesc4ePrtAlertDesc5eBlack700eMagentaeCyaneYelloweTonerCollector800eBlackDeveloper810eColorDevelopereFuser820eDrum830eTransfer840eMaintenanceKit850eOilKit860eStationInfo1901eStationInfo2eStationInfo3eStationInfo4eStationInfo5eRicohEngineCounterTotal2000eRicohEngineCounterPrintereRicohEngineCounterFaxeRicohEngineCounterCopierEerrorCode以下のコードは単なる一例であり、より多くのコードを既存のセットに加えてもよい。範囲099は予約されている。範囲100-199はSMTP用、200-299はPOP3用、300-399はSocket用、400-499はHTTP用、500-599はFTP用である。その他の明記しなかった範囲は、必要に応じてユーザが定義してもよい。EnumEerrorCodeDeviceODBCモジュールの抽象型クラス図16は、本発明によるDeviceODBCモジュールクラス構造を示し、CabsProtocolParametersクラス構造がDeviceODBCモジュール内でどのように使用されるかを示している。CAbsProtocolParametersクラスは、監視データベース1014とインターフェイスし通信プロトコルを用いて被監視装置にアクセスするための情報を取得するように設計されている。CabsProtocolParametersクラスはプロトコルに依存しない2つの仮想関数を有する:stdstringobtainProtocolName及びboolobtainParameterVector。これらの関数を用いて、CDeviceODBCクラスは、プロトコルを特定することなくCabsProtocolParameterタイプへのポインタを通じて、同じ数のプロトコル、及びそれに関連するパラメータ名もしくは値を取り扱うことができる。取得した各装置の情報例えば、IPアドレスは、図18のデータ構造に格納され、obtainConfig関数を通してMonitorManagerモジュール1102に送られる。CDeviceODBCの観点から、プロトコル名及びそれに関連したパラメータ名と値を取得するために使用するオブジェクトはすべて、CAbsProtocolパラメータの一種であると考えられる。新しいプロトコルが追加されると、新しいオブジェクトが生成され、CabsProtocolParametersクラスへのポインタのベクトルに格納される。他の関数を変更する必要はない。HWaccessモジュールの抽象型クラス図23は、HWaccessパッケージを示すパッケージ図である。このパッケージは、監視するネットワーク装置を特定し、いろいろなネットワークプロトコル例えば、SNMP、HTTP、FTPを用いてそのネットワーク装置に関する情報を取得する役割を担う。このパッケージは、パッケージHTTP2302、SNMP2304、FTP2306、及びクラスCHWaccess2300、CAbsProtocol2308、CrecordSet2310を含む。パッケージHTTP2302、SNMP2304、FTP2306は、ネットワーク装置にアクセスしそれから情報を取得するためのネットワークプロトコルを実装する。例えば、HTTPパッケージ2302は、ネットワーク装置のウェブページにアクセスしそのウェブページから情報を取得するためのHTTPプロトコルを実装する。クラスCHWaccess2300はすべてのプロトコルパッケージを管理し、ネットワーク装置から必要な情報を取得する。クラスCAbsProtocol2308は任意のプロトコルを表す抽象型クラスである。このクラスは、CHWaccess2300とプロトコルパッケージ間のインターフェイスを提供する。クラスCAbsProtocol2308は、CHWaccess2300に図23に示した一組の共通関数を提供する。すべてのプロトコルは、CHWaccess2300に必要な情報を提供する。後に出てくる図面で説明するように、CAbsProtocol2308から導かれるクラスは、適当なプロトコルについて各関数のメソッドを提供する。クラスCRecordSet2310は、マイクロソフトファウンデーションクラスのクラスである。各プロトコルパッケージは、このクラスによりデータベースにアクセスして、ネットワーク装置のどのベンダーのどのモデルがサポートされそのネットワーク装置から何の情報を取得するかという情報を取得することができる。図24は、SNMPパッケージ2304の第1の実施形態を示すパッケージ図である。図24に示したコンポーネントの多くが、図63に示すSNMPパッケージの第2の実施形態にも組み込まれることに留意せよ。このパッケージにより、SNMPプロトコルによりサポートされたネットワーク装置のベンダーとモデルおよびSNMPプロトコルによりネットワーク装置から取得する情報を決定し、SNMPプロトコルを通じてネットワーク装置にアクセスしてそのネットワーク装置から情報を取得する役割を担う。上記パッケージは、パッケージSNMPaccess2404とSNMPODBC2406およびクラスCSNMPProtocol2402を含み、図23に示したようにクラスCAbsProtocol2400とCRecordSet2408を使用する。SNMPaccessパッケージ2404は、ネットワーク装置にアクセスしそれから情報を取得するためのSNMPプロトコルを実装する。SNMPODBCパッケージ2406は、データベースにアクセスして、SNMPプロトコルによりサポートされたネットワーク装置のベンダーとモデルと、SNMPプロトコルによりそのネットワーク装置から取得する情報とに関する情報を取得する。CSNMPProtocolクラス2402は、CAbsProtocolクラス2400から導き出されたクラスである。CSNMPProtocol2402は、SNMPプロトコルを用いてネットワーク装置から必要な情報を取得する。CSNMPProtocol2402は、図23に示したようにCAbsProtocol2400のすべてのインターフェイス関数のメソッドを提供する。図24は、CSNMPProtocol2402が使用するパッケージSNMPaccess2404とSNMPODBC2406の関数を示している。SNMPODBCパッケージ2406は、クラスCRecordSet2408を使用してデータベースから情報を取得する。図25は、HTTPパッケージ2302の第1の実施形態を示すパッケージ図である。図25に示したコンポーネントの多くが、図41に示すHTTPパッケージの第2の実施形態にも組み込まれることに留意せよ。このパッケージは、HTTPプロトコルによりサポートされたネットワーク装置のベンダーとモデルおよびHTTPプロトコルによりそのネットワーク装置から取得する情報を決定し、HTTPプロトコルでそのネットワーク装置にアクセスしてそのネットワーク装置から情報を取得する役割を担う。このパッケージは、パッケージHTTPaccess2504とHTTPODBC2506およびクラスCHTTPProtocol2502を含み、図23に示したようにクラスCAbsProtocol2500とCRecordSet2508を使用する。HTTPaccessパッケージ2504は、HTTPプロトコルを実装し、ネットワーク装置にアクセスしてそのネットワーク装置から情報を取得する。HTTPODBCパッケージ2506は、データベースにアクセスし、そのデータベースからHTTPプロトコルによりサポートされたネットワーク装置のベンダーとモデルと、HTTPプロトコルによりそのネットワーク装置から取得する情報とに関する情報を取得する。CHTTPProtocolクラス2502は、CAbsProtocolクラス2500から導き出されたクラスである。CHTTPProtocol2502は、HTTPプロトコルを用いてネットワーク装置から必要な情報を取得する。CHTTPProtocol2502は、図23を参照して説明したように、CAbsProtocol2500のインターフェイス関数すべてにメソッドを提供する。図25は、CHTTPProtocol2502が使用するパッケージHTTPaccess2504とHTTPODBC2506の関数も示している。HTTPODBCパッケージ2506は、クラスCRecordSet2508を用いてデータベースから情報を取得する。図26は、FTPパッケージ2306を示すパッケージ図である。このパッケージは、FTPプロトコルによりサポートされたネットワーク装置のベンダー及びモデルと、FTPプロトコルによりそのネットワーク装置から取得する情報とを決定し、FTPプロトコルによりそのネットワーク装置にアクセスして、そのネットワーク装置から情報を取得する役割を担っている。このパッケージは、パッケージFTPaccess2604とFTPODBC2602およびクラスCFTPProtocol2602を含み、図23を参照して説明したようにクラスCAbsProtocol2600とCRecordSet2608を使用する。FTPaccessパッケージ2604は、ネットワーク装置にアクセスし、そのネットワーク装置から情報を取得するためのFTPプロトコルを実装している。FTPODBCパッケージ2606は、データベースにアクセスし、FTPプロトコルによりサポートされたネットワーク装置のベンダーとモデル、およびFTPプロトコルによりそのネットワーク装置から取得する情報、に関する情報をそのデータベースから取得する。CFTPProtocolクラス2602は、CAbsProtocolクラス2600から導き出されたクラスである。CFTPProtocol2602は、FTPプロトコルを用いてネットワーク装置から必要な情報を取得する。CFTPProtocol2602は、図23を参照して説明したように、CAbsProtocol2600のインターフェイス関数すべてのメソッドを提供する。図26は、CFTPProtocol2602が使用するパッケージFTPaccess2604とFTPODBC2606の関数も示している。FTPODBCパッケージ2606は、クラスCRecordSet2608を用いてデータベースから情報を取得する。各プロトコルパッケージHTTP2302、SNMP2304、FTP2306は、図23から26を参照して説明したように、ネットワーク装置へのアクセスを管理してその装置から情報を取得するクラスを含んでいる。そのクラスは、ネットワーク装置からの情報にアクセスするプロトコルを実行するメソッドを提供する抽象型クラスCAbsProtocol2308から導き出される。抽象型クラスは、インターフェイス関数のみを提供し、プロセスは何も実行しない。抽象型クラスから導き出されたクラスは、インターフェイス関数を実行するメソッドを提供する。抽象型クラスの派生クラスは多数あるので、異なる派生クラスがインターフェイス関数のプロセスを異なるように実行することができる。例えば、CAbsProtocolのインターフェイス関数はobtainStatusである。派生クラスCSNMPProtocol2402は、SNMPを用いてネットワーク装置のステータス情報を取得するメソッドを提供する関数obtainStatusを含み、一方、派生クラスCHTTPProtocol2502はHTTPを用いてネットワーク装置のステータス情報を取得するメソッドを提供する関数obtainStatusを含む。HWaccessパッケージの設計によれば、新しいパッケージその新しいパッケージを管理するCAbsProtocolの派生クラスを含むを付加することにより、新しいプロトコルをシステムに追加して、その新しいプロトコルを用いてネットワーク装置にアクセスすることができる。抽象型クラスによりシステムを将来的に拡張することができる。図27A-27Dは、ネットワーク装置にアクセスしてそれから情報を取得するためのプロトコルをすべて保持する、図23のHWaccessパッケージで使用されるデータ構造を示している。図27Aに示したデータ構造は、CAbsProtocol2308へのポインタのベクトル500である。クラスCHWaccess2300は、このデータ構造体を含み、使用する。ベクトル500は、CAbsProtocol2308から導き出されたクラスへのポインタを含んでいるが、CHWaccess2300は、そのベクトルをCAbsProtocol2308へのポインタを含むとみなし、仮想ファンクションコールメカニズムを通してCAbsProtocol2308のインターフェイス関数を呼び出す。CHWaccess2300は、実際には、CAbsProtocol2308の派生クラスのインターフェイス関数を呼び出す。例えば、ベクトルの第1のエントリーのCAbsProtocolへのポインタ502は、派生クラスCSNMPProtocol2402へのポインタであり、ベクトルの第2のエントリーのCAbsProtocolへのポインタ504は、派生クラスCHTTPProtocol2502へのポインタであり、ベクトルの第3のエントリーのCAbsProtocolへのポインタ506は、派生クラスCFTPProtocol2602へのポインタである。そこで、CHWaccess2300がベクトルのCabsProtocol2308のインターフェイス関数を呼び出すとき、実際にはCSNMPProtocol2402、CHTTPProtocol2502、CFTPProtocol2602のインターフェイス関数を呼び出している。ベクトル500の抽象型クラスCAbsProtocol2308を使用することにより、どのプロトコルを使用してもネットワーク装置にアクセスして、そのネットワーク装置から情報を取得することができる。抽象型クラスCAbsProtocol2308は、どのプロトコルが使用されているかの詳細を隠蔽する。図27Bは、CSNMPProtocolにより使用されるデータ構造を示し、このデータ構造は、SNMPにより監視されるネットワーク装置のベンダーとモデルに関する情報と、そのネットワーク装置からステータス情報を取得するために使用する情報とを保持する。このデータ構造はマップ510である。マップ510のキーは、ネットワーク装置のベンダー名を表すストリング512である。マップ510の値は他のマップ514である。マップ514のキーは、ネットワーク装置のモデル名を表すストリング516である。マップ514の値はペアのベクトル518である。そのペアには構造SOIDinfoTypeと整数が含まれている。構造SOIDinfoTypeは、SNMPを用いてネットワーク装置から単一のステータス情報を取得するために使用する情報を含む。それゆえ、ペアのベクトル518は、特定のベンダーとモデルのネットワーク装置のステータス情報をすべて取得するための情報を含む。マップ510の情報は、図28を参照して説明したプロセスを用いて初期化される。マップ510は、ベンダーのストリング512とモデルのストリング516のエントリーの一例を示している。図27Cは、CHTTPProtocolにより使用されるデータ構造を示し、このデータ構造には、HTTPにより監視されているネットワーク装置のベンダーとモデルに関する情報と、そのネットワーク装置からステータス情報を取得するために使用する情報とを保持される。このデータ構造はマップ520である。マップ520のキーは、ネットワーク装置のベンダー名を表すストリング522である。マップ520の値は他のマップ524である。マップ524のキーは、ネットワーク装置のモデル名を表すストリング526である。マップ524への値はSWebPageInfoのベクトル528である。構造SWebPageInfoは、HTTPを用いてネットワーク装置のウェブページからステータス情報をすべて取得するために使用する情報を含んでいる。それゆえ、SWebPageInfoのベクトル528は、そのウェブページのすべてから特定のベンダーとモデルのネットワーク装置のステータス情報をすべて取得するための情報を含んでいる。マップ520の情報は、図28を参照して説明したプロセスを用いて初期化される。マップ520は、ベンダーのストリング522とモデルのストリング526のエントリーの一例を示している。図27Dは、CFTPProtocolにより使用されるデータ構造を示し、このデータ構造は、FTPにより監視されているネットワーク装置のベンダーと、モデルに関する情報と、そのネットワーク装置からステータス情報を取得するために使用する情報とを保持する。そのデータ構造はマップ530である。マップ530のキーは、ネットワーク装置のベンダー名を表すストリング532である。マップ530の値は他のマップ534である。マップ534のキーは、ネットワーク装置のモデル名を表すストリング536である。マップ534の値はSDirFileStatusInfoのベクトル538である。構造SDirFileStatusInfoは、FTPを用いてネットワーク装置のFTPファイルからすべてのステータス情報を取得するために使用する情報を含む。それゆえ、SDirFileStatusInfoのベクトル538は、そのFTPファイルのすべてから特定のベンダーとモデルのネットワーク装置のステータス情報のすべてを取得するために使用する情報を含む。マップ530の情報は、図28を参照して説明したプロセスを用いて初期化される。マップ530は、ベンダーのストリング532とモデルのストリング536のエントリーの一例を示している。図28は、システムにより監視されるネットワーク装置のベンダーに関する情報で、すべてのプロトコルオブジェクトを初期化するプロセスを示すフローチャートである。同様のプロセスを用いて、システムにより監視されるネットワーク装置のモデルに関する情報で、すべてのプロトコルオブジェクトを初期化する。ネットワーク装置が監視されている場合、何の情報をそのネットワーク装置から取得する必要があるかを決定するために、そのネットワーク装置のベンダーとモデルを知っておく必要がある。ネットワーク装置にアクセスして情報を取得するために使用する各プロトコルオブジェクトは、そのネットワーク装置から何の情報をいかに取得するかを決定するために、ベンダーとモデルを知っている必要がある。初期化を必要とするプロトコルオブジェクトは、CabsProtocol2308から導かれたクラスに相当するものであり、CSNMPProtocol、CHTTPProtocol、CFTPProtocolである。プロトコルオブジェクトの初期化では、そのプロトコルに対応する図27B、27C、及び27Dを参照して説明したデータ構造に情報を追加する。システムの設計によれば、図27B、27C、27Dのデータ構造に追加される情報はデータベースから来たものであるが、テキストファイルやスプレッドシートなど他の外部ソースから来たものであってもよい。図27Aを参照して説明したCAbsProtocol2308へのポインタのベクトルを使用して、すべてのプロトコルオブジェクトを初期化する。フローチャートのプロセスはベクトルを2回通る。1回目にベクトルを通るとき、プロトコルオブジェクトを用いてネットワーク装置のベンダーを見つける。ベンダー名がプロトコルオブジェクトの1つから取得できた場合、ベクトルを2回目に通るとき、すべてのプロトコルオブジェクトはそのベンダー名で初期化される。ステップ602において、CAbsProtocolへのポインタのベクトルからプロトコルオブジェクトを取得する。プロトコルオブジェクトは、ネットワーク装置にアクセスするためのプロトコル例えば、SNMP、HTTP、FTPの1つに対応する。ステップ604において、ベクトルから取得できるプロトコルオブジェクトがあるかどうかチェックする。このチェックは、ベクトルの終わりに来たかどうか判断することによりなされる。もしプロトコルオブジェクトがもうなければ、システムはネットワーク装置のベンダー名を取得できない。ベンダー名の取得とネットワーク装置のプロトコルオブジェクトの初期化とに失敗したプロトコルオブジェクトは、すべてステップ606で終了する。ベクトルから取得したプロトコルオブジェクトがあれば、そのプロトコルオブジェクトを用いて、ステップ608においてネットワーク装置のベンダー名を取得する。ステップ610において、プロトコルオブジェクトがネットワーク装置のベンダー名を取得可能であるかどうかをチェックする。プロトコルオブジェクトは、ネットワーク装置のベンダーを決定するために使用する情報をデータベースから取得する。プロトコルオブジェクトがベンダー名を取得することができないとき、ステップ602に戻り、ベクトルの他のプロトコルオブジェクトを用いてベンダー名を取得することを試みる。プロトコルオブジェクトからベンダー名を取得できた場合、ステップ612においてそのプロトコルオブジェクトをそのベンダー名で初期化する。プロトコルオブジェクトは、取得したベンダー名のネットワーク装置からステータス情報をいかに取得するかに関する情報で初期化される。情報は図27B、27C、27Dを参照して説明したようにデータ構造に追加される。ステップ614において、CAbsProtocolへのポインタのベクトルからプロトコルオブジェクトを取得する。ステップ616において、ベクトルから取得できるプロトコルオブジェクトがあるかどうかチェックする。プロトコルオブジェクトをこれ以上取得できないとき、すべてのプロトコルオブジェクトはベンダー名が初期化されており、すべてのプロトコルオブジェクトの初期化はステップ606で終了する。すべてのプロトコルオブジェクトはベンダーに関する情報が更新されている。ベクトルから取得されたプロトコルオブジェクトがあれば、ステップ618においてそのプロトコルオブジェクトをベンダー名で初期化する。ステップ612と同様に、プロトコルオブジェクトを、取得したベンダー名のネットワーク装置からステータス情報をいかに取得するかに関する情報で初期化する。プロトコルオブジェクトをベンダー名で初期化したのち、ステップ614に戻って、他のプロトコルオブジェクトをベンダー名で初期化する。図28のステップ608において、プロトコルオブジェクトはネットワーク装置のベンダー名を取得する。SNMP、HTTP、FTPプロトコルオブジェクトは、ネットワーク装置にアクセスして、ベンダー名を取得することができる。どこでベンダー名を見つけることができるかに関する情報は、データベースから得られる。データベースは、プロトコルによりサポートされたネットワーク装置のベンダーに関する情報とともに、ネットワーク装置のベンダー名を探すための情報を提供する。SNMPの場合、ベンダー名と関連する企業オブジェクト識別子と、ネットワーク装置のMIBにあるその企業オブジェクト識別子を見つけるために使用するオブジェクト識別子とに関する情報を用いて、SNMPプロトコルオブジェクトは、ベンダー名を取得する。HTTPの場合、ウェブページとそのウェブページ内の位置に関する情報を用いて、HTTPプロトコルオブジェクトは、ベンダー名を取得する。FTPの場合、FTPファイルとそのFTPファイル内の位置に関する情報を用いて、FTPプロトコルオブジェクトは、ベンダー名を取得する。図29ア-29Dは、異なるプロトコルのベンダーとモデルのネットワーク装置のステータス情報を取得するために使用する異なるデータ構造を示している。異なるプロトコルを用いて同一のステータス情報を取得することもできる。しかし、1つのプロトコルにより取得されるステータス情報は他のプロトコルにより取得される情報よりも多いことがあるので、より多くの情報を取得できるプロトコルから取得したステータス情報を使用した方がよい。例えば、プリンターカートリッジのトナーレベルは、SNMPとHTTPを用いてネットワークプリンターから取得できる。SNMPにより取得されるトナーレベルのステータス情報は、フル、OK、またはエンプティであり、一方、HTTPにより取得される同じステータス情報は、トナー残量のパーセンテージであるかも知れない。このような場合、HTTPを用いて取得したステータス情報の方が情報量は多いので、HTTPにより取得したステータス情報を使用すればよい。図29A-29Dに示したデータ構造により、最も情報の多いステータス情報を確実に取得することができる。図29Aは、SNMPプロトコルを用いて特定のベンダーとモデルのネットワーク装置のステータス情報を取得するために使用するデータ構造を示している。そのデータ構造はペア例えば、702と704のベクトル700であり、そのペアは構造SOIDinfoType706と整数よりなる。構造SOIDinfoType706は、SNMPを用いてネットワーク装置から特定のステータス情報を取得するために用いる情報を含んでいる。SOIDinfoType706の構造は図29Aに示されている。ペア中の整数はステータス情報の重みまたは優先度を決定する。整数値が大きいほど、取得されるステータス情報は情報が多いので採用されやすい。整数値が小さければ小さいほど、他のプロトコルから得られた同じステータス情報が採用されやすい。CSNMPProtocol2402は、ベクトル700を用いて、何のステータス情報をネットワーク装置から取得するかを決定する。ベクトル700に入れられる情報は、特定のベンダーとモデルについて図27Bのデータ構造から取得される。図29Bは、HTTPプロトコルを用いて特定のベンダーとモデルのネットワーク装置のステータス情報を取得するために使用するデータ構造を示す。そのデータ構造はペア例えば、710と712のベクトル708であり、そのペアは構造SKeyValueInfo714と整数よりなる。構造SKeyValueInfo714は、HTTPを用いてネットワーク装置のウェブページから特定のステータス情報を取得するために使用する情報を含む。SKeyValueInfo714の構造は図29Bに示されている。ペア中の整数はステータス情報の重みまたは優先度を決定する。CHTTPProtocol2502は、ネットワーク装置から何のステータス情報を取得するかを決定するためにベクトル708を使用する。ベクトル708に入っている情報は、特定のベンダーおよびモデルについて図27Cのデータ構造から取得される。図29Cは、FTPプロトコルを用いて特定のベンダーおよびモデルのネットワーク装置のステータス情報を取得するために使用するデータ構造を示している。そのデータ構造はペア例えば、718と720のベクトル716であり、そのペアは構造SKeyInfoType722と整数よりなる。構造SKeyInfoType722は、FTPを用いてネットワーク装置のFTPファイルから特定のステータス情報を取得するために使用する情報を含む。SKeyInfoType722の構造は図29Cに示されている。ペア中の整数はステータス情報の重みまたは優先度を決定する。CFTPProtocol2602はベクトル716を使用して、ネットワーク装置から何のステータス情報を取得するかを決定する。ベクトル716に入っている情報は、特定のベンダーおよびモデルについて図27Dのデータ構造から取得される。図29Dは、様々なプロトコルで取得するステータス情報を維持するために使用するデータ構造を示している。そのステータス情報を取得するためにどのプロトコルが使用されたかに関する情報は維持していない。そのデータ構造はマップ724である。マップ724へのキー726はinfoTypeである。infoTypeは情報のタイプを表す番号である。マップ724の値はペアである。ペアはストリングと整数よりなる。ペア中のストリングは、infoTypeに対応するネットワーク装置から取得したステータス情報である。ペア中の整数は、プロトコルから取得したステータス情報の重みまたは優先度である。一例として、infoTypeが700であり、プリンターカートリッジのブラックトナーのレベルを表す場合、そのペアはストリング75と整数10000を含んでいるとする。ストリング75はカートリッジに75のトナーが残っていることを示し、整数10000はそのステータス情報の重みまたは優先度である。CSNMPProtocol2402、CHTTPProtocol2502、CFTPProtocol2602は、ネットワーク装置から取得したステータス情報をマップ724に追加する。図30は、FTPプロトコルを用いてネットワーク装置からステータス情報を取得するために、図27D、29C、29Dのデータ構造がいかに使用されるかの一例を示している。サンプルデータを含むマップ800は、図27Dを参照して説明したデータ構造に対応する。マップ800のサンプルデータは、FTPを用いてベンダーであるリコーとモデルであるAficio120のネットワーク装置のステータス情報にアクセスするための情報を提供する。ベクトルの各構造SDirFileStatusInfo1、SDirFileStatusInfo2、SDirFileStatusInfo3は、ネットワーク装置のFTPファイルからのステータス情報にアクセスするための情報を提供する。SDirFileStatusInfo1802は、ディレクトリpubのFTPファイルstatustxtから、ネットワーク装置からのステータス情報にアクセスするための情報を含む。SKeyInfoTypeと整数のペアのベクトルを用いて、FTPファイルから5つのステータス情報値を取得できる。ベクトルペアの各SKeyInfoTypeは、図30に示したinfoTypeに対応する異なるステータス情報に対応する。マップ804は、図29Dを参照して説明したデータ構造に対応するサンプルデータを含んでいる。マップ804は、前もって他のプロトコルにより取得したステータス情報を含んでいる。マップ804は、infoType600、610、700に対応する3種類のステータス情報を含んでいる。infoType600のステータス情報は、ローペーパーLowPaperであり、その重みは500である。infoType610のステータス情報は、24321であり、その重みは10000である。infoType70のステータス情報はOKであり、その重みは2500である。FTPプロトコルを用いて何のステータス情報が取得されるかを決定するため、取得するステータス情報を含むベクトル806が生成される。ベクトル806に加えられる情報は、マップ800の情報より具体的には、構造SDirFileStatusInfo1802のペアのベクトルとマップ804のステータス情報により決定される。マップ800から取得するステータス情報がマップ804にはまだ取得されていない場合、ステータス情報を取得するために必要な情報をベクトル806に加える。マップ800から取得されるステータス情報がマップ804に取得されている場合、FTPプロトコルにより取得されるステータス情報はマップ804のステータス情報より情報が多いかどうかを、重みを比較してチェックする。ベクトル806にステータス情報を取得するための情報を加えるのは、FTPにより取得されたステータス情報の重みがマップ804にすでにあるステータス情報の重みよりも大きい場合だけである。SDirFileStatusInfo1に対応するFTPにより取得されるステータス情報は、infoType600、610、620、700、710である。infoType620と710はステータス情報マップ804にないので、FTPを用いてステータス情報を取得する必要がある。それゆえ、620SKeyInfoType3と710SKeyInfoType5に対応するステータス情報を取得するために使用する情報が、ベクトル806に加えられる。infoType600と700はステータス情報マップ804にある。802に示したように、これらのinfoTypeのFTPにより取得されるステータス情報の重みは、ステータス情報マップ804中のそれらの重みよりも大きい。そのため、FTPによりこれらの2つのinfoTypeについて取得されたステータス情報は、マップ804にあるステータス情報より情報が多い。それゆえ、infoType600SKeyInfoType1と700SKeyInfoType4のステータス情報を取得するための情報がベクトル806に加えられる。infoType610はステータス情報マップ804にある。802に示したこのinfoTypeのFTPにより得られるステータス情報の重みは、ステータス情報マップ804の重みより小さい。FTPによりこのinfoTypeについて取得されたステータス情報は、マップ804にあるステータス情報より情報が少ない。それゆえ、infoType610SKeyInfoType2のステータス情報を取得するための情報は、ベクトル806には加えられない。FTPプロトコルは、このベクトル806を使用し、infoType600、620、700、710のステータス情報を取得する。2つのステータス情報値がステータス情報マップ804に加えられ、FTPによりステータス情報を取得できれば、ステータス情報マップ804の2つのステータス情報値が上書きされる。図30は、FTPプロトコルの場合、データ構造をいかに使用してステータス情報を取得するかを示す例である。図27B、27C、29A、29Bのデータ構造を使用する同様のプロセスを使用して、SNMPとHTTPのステータス情報を取得する。図31Aは、ステータス情報を取得する方法を示すフローチャートである。すべてのプロトコルでここに説明する方法を使用できる。プロトコルオブジェクトを使用してステータス情報を取得する前に、プロトコルオブジェクトはステータス情報が他のプロトコルオブジェクトによりすでに取得されているかどうかをチェックする。ステータス情報がすでに取得されている場合、これから取得するステータス情報が他のプロトコルオブジェクトからすでに取得されたものよりも情報が多いかどうかをチェックしなければならない。最も情報が多いステータス情報が保存される。フローチャートの方法により、最も情報が多いステータス情報を確実に取得することができる。図27B、27C、27Dのデータ構造510、520、530が対応するプロトコルにより使用され、どのステータス情報を取得するかを決定する。ステップ3102において、ネットワーク装置からステータス情報を取得するために使用する情報を含むペアのベクトルが、エントリー無しに生成される。ペアのベクトルは、使用されるプロトコルに応じて、図29Aから29Cのデータ構造700、708、716の1つに対応する。ステップ3104において、与えられたベンダーとモデルのネットワーク装置から1種類のステータス情報を取得するために使用する情報を取得する。すべてのプロトコルオブジェクトは、サポートするすべてのベンダーとモデルについて何のステータス情報を取得するかに関する情報を保持している。図28を参照して説明した初期化プロセスにより、すべてのプロトコルオブジェクトがこの情報で初期化される。1つのステータス情報を取得するために使用される情報は、使用するプロトコルに応じて図29A、29B、29Cの構造SOIDinfoType706、SKeyValueInfo714、SKeyInfoType722の1つに格納される。ステップ3106において、ネットワーク装置からステータス情報を取得するために使用される情報がまだあるかチェックする。情報がもうなければ、ステップ3102で生成されたペアのベクトルは、そのプロトコルについてそのネットワーク装置からすべてのステータス情報を取得するために必要なすべての情報を含んでいる。ステップ3108において、プロトコルオブジェクトは、ペアのベクトルを使用してネットワーク装置からステータス情報を取得し、そのステータス情報は、図29Dを参照して説明したステータス情報マップ724に格納される。プロトコルによるステータス情報の取得は、ステップ3110で完了する。ネットワーク装置からステータス情報を取得するために使用するより多くの情報があれば、ステップ3112において、そのステータス情報がすでに取得されているかどうかをチェックする。このチェックは、図29Dを参照して説明したように、ステータス情報を含むマップを見て、そのステータス情報がマップにすでにあるかどうか調べることにより行われる。ステータス情報がマップになければ、ステップ3114において、ペアのベクトルにステータス情報を取得するために使用する情報を加える。その情報をペアのベクトルに加えた後、ステップ3104に戻り、ステータス情報を取得するために使用される情報をさらに取得する。ステータス情報がすでに取得されていたら、ステップ3116において、すでに取得されたステータス情報の重みまたは優先度を、プロトコルを通して取得できるステータス情報の重みまたは優先度と比較する。ネットワーク装置のステータス情報のマップ中にあるステータス情報の重みまたは優先度がプロトコルにより取得されるステータス情報の重みまたは優先度よりも大きい場合、そのステータス情報を取得するために使用する情報はペアのベクトルに加えない。ステップ3104に戻り、ステータス情報を取得するために使用される情報をさらに取得する。マップ中のステータス情報の重みまたは優先度がそのプロトコルにより取得されるステータス情報の重みまたは優先度より大きくない場合、ステップ3114において、ステータス情報を取得するために使用される情報をペアのベクトルに加える。その情報をペアのベクトルに加えた後、ステップ3104に戻り、ステータス情報を取得するために使用される情報をさらに取得する。図31Bは、すべてのプロトコルを用いてネットワーク装置に関するステータス情報を取得するプロセスを説明するためのフローチャートである。図28を参照して説明したようにプロトコルオブジェクトがサポートするネットワーク装置のベンダーとモデルに関する情報でそのプロトコルオブジェクトを初期化した後、そのプロトコルオブジェクトをネットワーク装置からステータス情報を取得するために使用することができる。そのプロトコルオブジェクトは、図27B、27C、27Dを参照して説明した、データ構造を用いてベンダーとモデルについてステータス情報をいかに取得するかに関する情報を含む。図27Aを参照して説明したCAbsProtocol2308へのポインタのベクトルを使用して、すべてのプロトコルオブジェクトについてステータス情報を取得する。フローチャートのプロセスは、そのベクトルを一回通る。ステップ3122において、CAbsProtocolへのポインタのベクトルからプロトコルオブジェクトを取得する。プロトコルオブジェクトは、ネットワーク装置にアクセスするためのネットワークプロトコル例えば、SNMP、HTTP、FTPの1つに対応する。ステップ3124において、ベクトルから取得できるプロトコルオブジェクトがあるかどうかチェックする。このチェックは、ベクトルの終わりに来たかどうか判断することによりなされる。プロトコルオブジェクトがもう取得できなければ、ステップ3126において、すべてのプロトコルオブジェクトを用いてネットワーク装置からステータス情報を取得し終わっていることになる。ベクトルから取得したプロトコルオブジェクトがあれば、ステップ3128において、そのプロトコルオブジェクトを用いてネットワーク装置のステータス情報を取得する。プロトコルオブジェクトを用いてステータス情報を取得した後、ステップ3122に戻り、他のプロトコルオブジェクトを用いてステータス情報をさらに取得する。図32Aは、プロトコルによりサポートされたネットワーク装置のベンダーとモデルに関する情報を保持するために使用するデータ構造を示す。また、図32Bはそのデータ構造で使用する情報の一例を示す。サポートされたベンダーとモデル、およびそれからステータス情報をいかに取得するかに関するデータベースの情報の構成はプロトコルごとに異なる。それゆえ、異なるプロトコルの場合にサポートされたベンダーとモデルのデータベースからの取得方法は、プロトコルにより異なる。サポートされたベンダーとモデルへのアクセスを簡単にするため、すべてのプロトコルについて、この情報を格納しアクセスするためにマップ構造を使用することができる。図32Aは、ベンダーモデルサポートマップ3200を示す。マップ3200へのキー3202は、プロトコルによりサポートされたベンダーとモデルに関する情報を含むストリングである。マップ3200の値3204は、ベンダーとモデルに関する情報ベンダーモデル識別番号等を表すために使用することができる整数である。マップ構造を選択してプロトコルによりサポートされたベンダーとモデルに関する情報を載せた理由は、マップ構造がキーを容易に発見するルックアップメカニズムを有するからである。このように、ベンダーとモデルがマップにあるかどうかの判断は容易である。図32Aではデータベースから取得した異なるプロトコルによるベンダーおよびモデルに関する情報を示したが、テキストファイルやスプレッドシートなど外部ソースから情報を取得してもよい。図32Bは、ベンダーモデルサポートマップ3206とそのサンプルエントリーを示す。マップ3206のキー3208はベンダー名、セパレータ、及びモデル名を含むストリングである。例えば、ベンダーVendor1とモデルModel1の場合、マップ3206のキー3208のストリングはVendor1Model1である。この例ではセパレータとしてを使用したが、ベンダー名及びモデル名の一部と混同されないセパレータなら何でもよく、例えばでもよい。セパレータを使用する理由は、ベンダーとモデルを区別し、ベンダーとモデルをストリングから容易に取得するためである。マップ3206の値3210は整数1である。マップ3206の値3210はいかなる整数であってもよい。各プロトコルについてベンダーモデルサポートマップ3200が保持される。図33は、プロトコルによりサポートされたベンダーとモデルをすべて含む、図32Aのベンダーモデルサポートマップ3200にサポートされたベンダーとモデルを加える方法を示すフローチャートである。ステップ3302において、データベースからベンダーとモデルを取得する。ベンダーとモデルをデータベースからいかに取得するかは、プロトコルごとに異なる。これはサポートされたベンダーとモデルを含むデータベースのテーブルに依存する。ステップ3304において、データベースから取得するベンダーとモデルがあるかどうかをチェックする。取得するものがなければ、ステップ3306において、ベンダーモデルサポートマップ3200にサポートされたベンダーとモデルを入れる方法は終了する。ベンダーモデルサポートマップ3200は、プロトコルによりサポートされたベンダーとモデルをすべて含む。サポートされたベンダーとモデルの情報を取得するためにデータベースにアクセスする必要はもうない。データベースから取得したベンダーとモデルがあるとき、ステップ3308において、ベンダーモデルサポートマップ3200のキーとして使用するストリングを生成する。ストリングはベンダー名、セパレータ、及びモデル名により構成されている。前述の通り、セパレータはベンダー名やモデル名の一部と混同されないストリングであれば何でもよい。ステップ3310において、そのベンダー名、セパレータ、モデル名からなるストリングがベンダーモデルサポートマップ3200にすでにあるかどうか判断する。そのストリングがマップ3200にすでにあれば、ステップ3302において、データベースから他のベンダーとモデルを取得する。そのストリングがマップ3200になければ、そのストリングと整数をマップ3200に加える。そのストリングをマップ3200に加えた後、ステップ3302において、データベースから他のベンダーとモデルを取得する。図34は、図32Aのベンダーモデルサポートマップ3200から一プロトコルによりサポートされたベンダーとモデルを取得する方法を説明するためのフローチャートである。ステップ3402において、キーのストリングをベンダーモデルサポートマップ3200から取得する。ステップ3404において、マップ3200から取得するためにまだキーがあるかどうかチェックする。キーがもうなければ、プロトコルによりサポートされたベンダーとモデルはすべて取得されており、ステップ3406において、ベンダーとモデルの取得を終了する。キーのストリングをマップ3200から取得すると、ステップ3408において、セパレータの前のサブストリングを取得してベンダー名を取得する。ステップ3410において、セパレータの後のサブストリングを取得してモデル名を取得する。その後、ステップ3406において、ベンダーとモデルの取得が終了する。マップ3200のエントリーをすべて通ると、プロトコルによりサポートされたベンダーとモデルがすべて取得できる。図35は、デバイスパッケージを示すパッケージ図である。このパッケージは、ネットワーク装置を表すソフトウェアオブジェクトを生成する役割を担っている。デバイスパッケージ1300は、CDeviceFactory1302とCDevice1304の2つのクラスにより構成されている。クラスCDeviceFactory1302は、ネットワーク装置のソフトウェアオブジェクトを生成して初期化する役割を担っている。ソフトウェアオブジェクトの初期化には、ネットワーク装置のベンダー、モデル、一意的識別子を決定し、そのネットワーク装置にアクセスするために使用できるプロトコルを設定することが含まれる。ネットワーク装置にアクセスできないとき、そのネットワーク装置のソフトウェアオブジェクトは生成されない。クラスCDevice1304は、ネットワーク装置のソフトウェアオブジェクトを表す。CDevice1304は、ネットワーク装置に関する情報を保持し、そのネットワーク装置に関するステータス情報を取得する。CDevice1304は、HWaccessパッケージ1306図23を参照して説明したを用いて、いろいろなプロトコルを通してネットワーク装置にアクセスし、その装置から情報を取得する。図36Aは、ネットワーク装置にアクセスするためにどのプロトコルを使用するかを決定するために、ネットワーク装置を表すソフトウェアオブジェクト図35を参照して説明したCDevice1304により使用されるデータ構造を示す。CDevice1304はプロトコルパラメータマップ1400を含む。マップ1400のキー1402は、プロトコル例えば、SNMP、HTTP、FTPを表すストリングである。マップ1400の値1404は、構造SParameterのベクトルである。構造SParameter1406は、与えられたプロトコルについて、ネットワーク装置にアクセスするために使用する情報を含む。SParameter1406は、ネットワーク装置のベンダーとモデルの特徴ではなく、そのネットワーク装置の特徴である情報を含んでいる。例えば、その情報は、SNMPによりそのネットワーク装置にアクセスするためのコミュニティ名であってもよく、FTPによりそのネットワーク装置にアクセスするためのユーザ名とパスワードであってもよい。これらは、SNMPまたはFTPによりいずれかのネットワーク装置にアクセスするために使用する共通情報である。DeviceODBCを通して取得されたデータベースからの情報は、ネットワーク装置にいろいろなプロトコルを通じてアクセスできるように、マップに加えられる。マップ中のプロトコルのエントリーは、そのプロトコルがそのネットワーク装置にアクセスできず、ベンダーとモデルがそのプロトコルによりサポートされていないとき、削除される。一部のプロトコルは、ベンダーとモデルがそのプロトコルによりサポートされていなくても、ネットワーク装置にアクセスする。例えばSNMPはそのようなプロトコルの例である。図36Bは、ネットワーク装置の図36Aのプロトコルパラメータマップ1400のサンプルデータを示している。ネットワーク装置は、2つのプロトコルSNMPとFTPを用いてステータス情報を取得する。ネットワーク装置のマップ1410は、キーSNMPとFTPの2つのエントリーを含む。SNMPを用いてネットワーク装置にアクセスするには、コミュニティ名が必要である。SNMPのSParameterのベクトルは、コミュニティ名に関する情報を含む。1つのSParameterにパラメータ名COMMUNITYとパラメータ値privateを用いて、ネットワーク装置へのアクセスを可能にする。ネットワーク装置にFTPを用いてアクセスするためには、ユーザ名とパスワードが必要である。FTPの場合、SParameterのベクトルは、ユーザ名とパスワードに関する情報を含む。1つのSparameterについてパラメータ名USERNAMEとパラメータ値abcを用い、他のSparameterについてパラメータ名PASSWORDとパラメータ値xyzを用い、ネットワーク装置へのアクセスを可能とする。図37は、図36Aのプロトコルパラメータマップ1400をいかに更新して、どのプロトコルを使用してネットワーク装置からステータス情報を取得するかを説明するフローチャートである。図37のステップを実行し、プロトコルについてネットワーク装置のベンダー名とモデル名を取得する。ステップ3702において、プロトコルを用いてネットワーク装置にアクセスできるかチェックする。マップ1400の情報を用いてそのプロトコルを通じてネットワーク装置にアクセスする。そのプロトコルを通じてそのネットワーク装置にアクセスできない場合、ステップ3704において、プロトコルパラメータマップ1400からそのプロトコルを削除し、ステップ3714において、マップ1400の更新を終了する。そのネットワーク装置にそのプロトコルを通じてアクセスできるとき、ステップ3706において、そのネットワーク装置のベンダーをそのプロトコルを用いて取得できるかどうかチェックする。ベンダーを取得できないとき、ステップ3707において、ジェネリックベンダーがそのプロトコルでサポートされているかどうかチェックする。プロトコルがジェネリックベンダーをサポートしているとは、プロトコルがその装置のベンダーを取得できないか、またはサポートしていないときでも、プロトコルがすべての装置に共通なステータス情報共通ステータス情報を取得することできることを意味する。そのプロトコルによりジェネリックベンダーがサポートされていないとき、ステップ3704において、そのプロトコルはプロトコルパラメータマップ1400から削除され、ステップ3714において、マップ1400の更新が終了する。そのプロトコルがジェネリックベンダーをサポートしているとき、そのプロトコルはプロトコルパラメータマップ1400に残され、ステップ3714において、マップの更新が終了する。ステップ3706においてベンダーを取得できる場合、ステップ3708において、そのネットワーク装置のベンダーがそのプロトコルでサポートされているかどうかチェックする。ベンダーがそのプロトコルによりサポートされていないとき、ステップ3707において、ジェネリックベンダーがそのプロトコルによりサポートされているかどうかチェックする。ステップ3707以降のステップのシーケンスは上で説明した。ベンダーがそのプロトコルでサポートされているとき、ステップ3710において、そのネットワーク装置のモデルがそのプロトコルを用いて取得できるかどうか判断する。モデルを取得できないとき、ステップ3711において、ジェネリックモデルがそのプロトコルでサポートされているかどうかをチェックする。プロトコルがジェネリックモデルをサポートしているとは、プロトコルがその装置のモデルを取得できず、またはサポートしていなくても、そのプロトコルがベンダーのすべての装置に共通なステータス情報特定ベンダーステータス情報を取得できることを意味する。ジェネリックモデルをプロトコルがサポートしていないとき、ステップ3704において、そのプロトコルはプロトコルパラメータマップ1400から削除され、ステップ3714において、マップ1400の更新が終了する。ジェネリックモデルがプロトコルによりサポートされているとき、そのプロトコルはプロトコルパラメータマップ1400に残され、ステップ3714においてマップの更新を終了する。ステップ3710でモデルを取得できるとき、ステップ3712において、そのネットワーク装置のモデルがプロトコルによりサポートされているかどうか判断する。そのモデルがプロトコルでサポートされていないとき、ステップ3711で、ジェネリックモデルをそのプロトコルがサポートしているかどうかチェックする。ステップ3711に続くステップのシーケンスについてはすでに説明した。そのモデルがプロトコルによりサポートされているとき、そのプロトコルを用いてネットワーク装置のステータス情報を取得でき、ステップ3714でプロトコルパラメータマップ1400の更新は終了する。ベンダーとモデルが取得またはサポートされていないとき、そのプロトコルはプロトコルパラメータマップ1400から削除され、ステータス情報の取得には使用されない。プロトコルに応じて図37に示したプロセスにはバリエーションがある。HTTPとFTPはフローチャートの説明通りだが、SNMPは、ベンダーがサポートされてもモデルとジェネリックモデルがサポートされていない場合でも、サポートされ、ステータス情報を取得するために使用することができる。上で説明したように、ベンダーとモデルが取得またはサポートされていなくても、SNMPによりステータス情報をネットワーク装置から取得できる。ネットワーク装置がSNMPをサポートし、SNMPによりアクセスできる限り、そのネットワーク装置の管理情報ベースMIBから情報を取得することができる。ステップ3702において、ネットワーク装置がSNMPを通じてアクセスできないとき、ステップ3704で、SNMPプロトコルはプロトコルパラメータマップ1400から削除される。しかし、そのネットワーク装置にSNMPでアクセスできる場合、ベンダーやモデルが取得及びサポートされているかどうかにかかわらず、SNMPプロトコルはプロトコルパラメータマップ1400に残される。SNMPをサポートするネットワーク装置はMIBを提供し、リモートシステムはそのネットワーク装置から情報を常に取得可能である。しかし、ネットワーク装置から取得可能な情報のタイプと数は、ベンダーとモデルが取得およびサポートされるかどうかに依存する。ベンダーとモデルが取得され、かつ知られていれば、SNMPによりネットワーク装置からより多くの情報を取得することができる。ベンダーとモデルを取得できなくても、SNMPはすべての装置が提供できる情報は取得可能である。例えば、システムの説明やシステムが動作している時間等は取得可能である。SNMPは次の3つの条件の下でネットワーク装置から情報を取得するために使用できる:1ベンダーとモデルがサポートされている;2ベンダーはサポートされているが、モデルはサポートされていない;3ベンダーもモデルもサポートされていない。HTTPとFTPは、SNMPのような特徴は有していない。SNMPは、すべてのネットワーク装置が従うことができる標準MIBを有しており、情報を取得できるが、ウェブページとFTPファイルは、ベンダーとモデルが異なるネットワーク装置では異なる。ネットワーク装置が情報を取得するために従うウェブページとFTPファイルの標準はない。図38Aないし38Cを参照して上で説明した問題を解決するため、本発明の実施形態は、被監視装置のHTMLファイルから情報を抽出する複数の方法を可能とし、HTMLファイルのフォーマットに応じて、さらに別の方法の拡張を可能とするように設計されている。HTTPプロトコルを例に挙げて説明するが、ここに説明する方法は他のプロトコルにも適用可能である。図39は、図23のプロトコルパッケージのそれぞれで使用されるパッケージを示すパッケージ図であり、ここでXXXはSNMP、HTTP、またはFTPのいずれかである。抽象クラスCabsProtocolは、装置から情報を取得するインターフェイス関数を提供するが、その情報を取得するメソッドは提供しない。CabsProtocolから派生するクラスは、装置から情報を取得する新しいプロトコルを追加しやすくする方法を提供する。CXXXProtocolImp1クラスは、XXXパッケージのインターフェイスであり、そのパッケージ内の他のすべてのクラス/パッケージを管理する。CXXXProtocolImp1はCabsProtocolから派生するので、このクラスは与えられたプロトコルで装置から情報を取得する方法を提供する。XXXaccessパッケージは、その装置にアクセスしてその装置から情報を取得するプロトコルを実装する。XXXODBCパッケージは、サポートデータベースからプロトコルサポート情報を取得する。この情報には、そのプロトコルがサポートするベンダー及びモデルの情報、その装置からいかにしてベンダー、モデル、及び一意的識別子に関する情報を取得するかの情報、及びその装置からステータス情報をいかに取得するかの情報が含まれる。図24、25、及び26は、SNMP、HTTP、及びFTPの場合に具体的にこのパッケージ図を使用したものである。装置からステータス情報を取得するために使用する新しいプロトコルはいずれも、そのパッケージ図のこの構造に従う。新しいプロトコルの1つとしてウェブサービスがある。また、プロトコルの異なる実装もパッケージ図のこの構造に従うことができる。図40は、図23のプロトコルパッケージのそれぞれで使用される別のパッケージ図であり、ここでXXXはSNMP、HTTP、またはFTPのいずれかである。このパッケージ図はどのプロトコルにも適用可能であるが、HTTPプロトコルを例として説明する。このパッケージ構造により、装置から情報を取得するプロトコルの新しい実装の拡張が可能となる。情報を取得するためのプロトコルの既存の実装が情報の新しいフォーマット例えば、図38B及び38Cに示したウェブページの例に対してうまく機能しない場合、この拡張が必要である。このパッケージ図は、図39に示したように、抽象クラスCAbsProtocolも使用する。CXXXProtocolクラスはCabsProtocolから派生する。CXXXProtocolは、XXXパッケージに対しインターフェイスを提供し、装置から情報を取得する異なる方法に対応するすべてのクラスを管理する。クラスCXXXProtocolImp1とCXXXProtocolImp2は、同じプロトコルを用いて情報を取得する異なる方法を実装する。CXXXProtocolImp1クラスは、装置から情報を取得するための実装を提供し、パッケージXXXaccess1とXXXODBC1を用いる。XXXaccess1パッケージは、その装置にアクセスしてその装置から情報を取得するプロトコルを実装する。XXXODBC1パッケージは、データベースからプロトコルサポート情報を取得する。この情報には、そのプロトコルがサポートするベンダー及びモデル、その装置からいかにしてベンダー、モデル、及び一意的識別子に関する情報を取得するかの情報、及びその装置からステータス情報をいかに取得するかの情報が含まれる。CXXXProtocolImp2クラスは、CXXXProtocolImp1と同じプロトコルを用いて装置から情報を取得するための他の実装である。CXXXProtocolImp2は、パッケージXXXaccess2とXXXODBC2を使用する。XXXaccess2パッケージは、その装置にアクセスしてその装置から情報を取得するプロトコルを実装する。XXXODBC2パッケージは、XXXODBC1と同様に、データベースからプロトコルサポート情報を取得する。このパッケージの設計により、プロトコルの新しい実装が可能となる。新しい実装が必要なとき、そのプロトコルを用いて装置にアクセスし、サポートデータベースから情報を取得するために、他の実装クラスがサポートパッケージとともに追加される。本発明の実施形態は、新しい実装の新しい装置とともに、すでにサポートされている装置から情報を取得するための既存の実装でも機能する。SNMPとFTPのパッケージ図は、図39のパッケージ構造に従い、図24と26に示されている。このシステムのHTTPのパッケージ図は、図40のパッケージ構造に従う。図41は、HTTPの場合のパッケージ図の第2の実施形態を示す図であり、図25と40に示したパッケージ図に基づく。このパッケージは、図38Aないし38Cに示したウェブページから情報を取得するためのHTTPの2つの実装を含んでいる。このパッケージは、図39を参照して上で説明したように、抽象クラスCabsProtocolを使用する。CHTTPProtocolクラスはCabsProtocolから派生する。CHTTPProtocolは、HTTPパッケージのためのインターフェイスであり、装置から情報を取得するHTTPの2つの異なる実装に対応する。FirstHTTPImplementationパッケージは、図38Aに示した装置のウェブページから情報を取得するためのHTTPの実装である。FirstHTTPImplementationパッケージは、上で説明したように、情報を取得するためのHTTPの実装に対応する。FirstHTTPImplementationパッケージは、FirstHTTPODBCパッケージを用いて、サポートされた装置と、その装置から情報をいかに取得するかに関するサポート情報をデータベースから取得する。SecondHTTPImplementationパッケージは、図38B及び38Cに示したような装置のウェブページから情報を取得するためのHTTPの他の実装を提供する。SecondHTTPImplementationパッケージは、SecondHTTPODBCパッケージを用いて、サポートされた装置と、その装置から情報をいかに取得するかに関するサポート情報をデータベースから取得する。SecondHTTPIMplementationパッケージによるHTTPの第2の実装は、図38B及び38Cを参照して上に説明したように、同じキーを異なるステータス情報を取得するために用いる時に、装置から情報を取得する問題を処理する。HTTPHTMLToolをパッケージとして示したが、2つの実装パッケージにより使用されるオブジェクトを含むネームスペースである。ネームスペースを用いることにより、それが含むオブジェクトをHTTPパッケージ内で使用できる。これにより、HTTPのすべてのクラス及びパッケージがネームスペースのオブジェクトを共有することができる。HTTPパッケージは、HTTPが装置に関する情報を取得するためのインターフェイスを提供する抽象クラスCAbsHTTPImplementationを含む。CAbsHTTPImplementationから派生したクラスは、その情報を実際に取得する方法を提供する。FirstHTTPImplementationパッケージとSecondHTTPIMplementationパッケージは、情報を取得する方法を規定するCAbsHTTPImplementationから派生したクラスを含む。このHTTPパッケージの設計により、将来の拡張が可能である。現在の実装が装置のウェブページから情報取得できない場合、一実装とODBCパッケージを追加することにより、新しい実装の設計を追加することができる。図42は、抽象クラスCAbsHTTPImplementationのクラス仕様を示す図である。この抽象クラスは、装置から情報すなわち、ステータス情報、ベンダー名、及び一意的識別子を取得するためのインターフェイスを提供する。しかし、その抽象クラスは、情報を取得するための実際の方法は提供しない。CAbsHTTPImplementationから派生したクラスがこの情報を取得する方法を提供する。それゆえ、CAbsHTTPImplementationから派生した各クラスは、この情報を取得する異なる方法を提供することができる。よって、抽象クラスを使用することにより設計が柔軟になる。図43と44は、図41のCHTTPProtocolクラスのデータ構造mImplementationMapとmVendorModelSupportMapを説明する図である。図43において、マップ構造mImplementationMapのキーは、CAbsHTTPImplementationクラスへのポインターである。キーは抽象クラスCAbsHTTPImplementationへのポインターであるが、そのポインタ-は実際にはCAbsHTTPImplementationの派生クラスをポイントする。図43は、CAbsHTTPImplementationの2つの派生クラスであるCFirstHTTPImplementationとCSecondHTTPImplementationに対応するマップのサンプルエントリーを示す図である。マップの値は、キーでポイントされた実装クラスが使用されるかどうかを示すブール値である。このマップは、システムがスタートする際、CHTTPProtocolのコンストラクタがプライベート関数initImplementationMapを呼び出す時に初期化される。このプライベート関数は、情報を取得するHTTPのすべての異なる実装をマップにエントリーし、そのブール値を偽に設定する。どの装置を監視するかを判断するディスカバリープロセス初期化中に、どの実装が必要かを判断する。装置から情報取得するために一実装が必要な場合、そのブール値を真に設定する。ディスカバリープロセスが完了した後、対応するブール値が偽である実装はマップから削除される。図44は、サンプルエントリーを有するマップ構造mVendorModelSupportMapを示す図である。このマップを用いて、被監視装置のベンダーとモデルの情報を取得するために、HTTPのどの実装を使用するかを判断する。そのマップのキーは、装置のベンダー名を表すストリングである。そのキーに対応する値は他のマップである。内側のマップにおいて、キーは装置のモデル名のストリングであり、値は抽象クラスCAbsHTTPImplementationへのポインターである。mImplementationMapに関してのみ、そのポインターは、実際にはCAbsHTTPImplementationの派生クラスをポイントし、その派生クラスが装置のモデルに対するHTTPの実装を提供する。実際、そのポインターは、マップmImplementationMapのポインターの1つに対応する。マップmVendorModelSupportMapには、システムの初期化の際、そのシステムがどの装置を監視するか決定するにつれ、エントリーが追加される。図45は、CHTTPProtocolの関数canAccessIPを示すフローチャートである。その関数canAccessIPは、ベンダーとモデル名を取得でき、そのベンダーとモデルがHTTPをサポートしている場合、マップmVendorModelSupportMapに実装を追加する。この関数は、システムが監視している各装置に対して呼び出され、その装置がHTTPによりサポートしているかどうかを決定する。この関数は、その装置から情報を取得するためにどのHTTP実装を用いるかを決定する。この関数は、マップmImplementationMapについてループとなっており、与えられた実装を用いて装置のベンダー、モデル、及び一意的識別子を取得するまで、そのマップのキーがポイントした実装を使用する。図46は、CHTTPProtocolの関数obtainStatusを示すフローチャートである。その関数obtainStatusは、マップmVendorModelSupportMapを使用する。HTTPの適当な実装は、入力されたベンダーとモデルに基づいて使用される。図47は、FirstHTTPImplementationパッケージを示すパッケージ図である。このパッケージは、装置のウェブページ図38Aのウェブページ等から情報を取得するためにHTTPを実装する。クラスCFirstHTTPImplementationは、このパッケージのインターフェイスであり、装置のウェブページから情報を取得する一メソッドを実装する他のクラス及びパッケージを管理する。CFirstHTTPImplementationは、CAbsHTTPImplementationから派生したクラスである。アペンディックス1は、CFirstHTTPImplementationの関数、定義タイプ、クラス属性を示す。FirstHTTPODBCパッケージとHTTPHTMLToolパッケージは、図41を参照して上に説明した。クラスCFirstHTMLProcessorは、装置のウェブページを処理して、所望の情報を取得する。CFirstHTMLProcessorは、特定フォーマットのウェブページのテキストを処理する方法を含み、所望の情報を取得する。アペンディックス3は、CFirstHTMLProcessorの関数、定義タイプ、クラス属性を示す。図48は、FirstHTTPImplementationパッケージを示すパッケージ図である。このパッケージは、装置のウェブページ図38Bと38Cのウェブページ等から情報を取得するためにHTTPを実装する。より具体的に、このパッケージは、情報を特定するためのキーワードが複数回現れるウェブページを処理する。クラスCSecondHTTPImplementationは、このパッケージのインターフェイスであり、装置のウェブページから情報を取得する他のメソッドを実装する他のクラス及びパッケージを管理する。CSecondHTTPImplementationは、CAbsHTTPImplementationから派生したクラスである。アペンディックス2は、CSecondHTTPImplementationの関数、定義タイプ、及びクラス属性を示す。SecondHTTPODBCパッケージとHTTPHTMLToolパッケージは、図41を参照して上に説明した。クラスCSecondHTMLProcessorは、装置のウェブページを処理して、所望の情報を取得する。このクラスは、特定フォーマットのウェブページのテキストを処理する方法を含み、所望の情報を取得する。より具体的に、このクラスは、情報を特定するためのキーワードが複数の箇所に現れるウェブページを処理する。アペンディックス4は、CSecondHTMLProcessorの関数、定義タイプ、クラス属性を示す。図49は、装置のウェブページ図38Aに示したウェブページ等から情報を取得するためのHTTPの第1の実装に対するサポートデータベースのテーブルを示す図である。これらのテーブルは、図21に示したテーブルに相当するが、2カ所変わっている。第1に、図21のEnumCorrespondenceを除いて、テーブル名に1を付加した。1を用いて、そのテーブルが装置から情報を取得するためのHTTPの第1の実装に対応することを示す。第2に、同じベンダーが1モデルに対して1つ以上のウェブページを有する場合もあるので、HTTPVendorModel1は他のテーブルに一意的には関連しない。図50は、装置のウェブページ図38Bと38Cに示したウェブページ等から情報を取得するためのHTTPの第2の実装に対するサポートデータベースのテーブルを示す図である。これらのテーブルは、名前の終わりが1ではなくて2であることと、HTTPStatusKeyValueのテーブル名にPrecondition前提条件が加えられていることを除いて、図49のサポートデータベースのテーブルと同じ名前を有する。2を用いて、そのテーブルがHTTPの第2の実装に対応することを示している。第2の実装のテーブルは、3つのテーブルHTTPVendorModel2、HTTPUniqueIDWebPage2、HTTPPreconditionStatusKeyValue2にsPreconditionエントリーが追加されている点で、第1の実装のテーブルと異なる。所望の情報を特定するキーワードがウェブページ上で2回以上現れる時、sPreconditionエントリーを用いてそのウェブページから情報を取得する。sPreconditionの使用について以下により詳しく説明する。sPreconditionが空の場合、所望の情報を取得する第2の実装のプロセスは、その所望の情報を取得する第1の実装のプロセスと同じである。ここで、前提条件Preconditionについて説明する。図38Bを参照して説明したように、画像化部ImagingUnitsのBlackの寿命をステータス情報として取得したい場合、従来の技術では、ウェブページ上で単にBlackというストリングのみを探し、それに対応する値をステータス情報としていたので、最初に出てくるトナーカートリッジのBlackに対応する値Okを間違って取得してしまう。そこで、画像化部ImagingUnitsというストリングが事前にあることを前提条件としてBlackというストリングを探し、それに対応する値100を取得することにより、画像化部のBlackの寿命をステータス情報として正しく取得することができる。図51は、FirstHTTPOFDBCパッケージを示すクラス図である。このパッケージは、装置のウェブページから情報を取得するために、図47に示したFirstHTTPImplementationパッケージにより使用されるサポートデータベースの情報へのアクセスを提供する。CHTTPODBC1クラスは、このパッケージへのインターフェイスであり、サポートデータベースのテーブルから適当な情報を取得するために他のクラスを管理する。CXXXData1クラスとそれに対応するCXXXTable1クラスは、テーブルから情報を取得するために、図49のサポートデータベースのXXXテーブルへのアクセスを提供する。図52は、SecondHTTPOFDBCパッケージを示すクラス図である。このパッケージは、装置のウェブページから情報を取得するために、図48に示したSecondHTTPImplementationパッケージにより使用されるサポートデータベースの情報へのアクセスを提供する。CHTTPODBC2クラスは、このパッケージへのインターフェイスであり、サポートデータベースのテーブルから適当な情報を取得するために他のクラスを管理する。CXXXData2クラスとそれに対応するCXXXTable2クラスは、テーブルから情報を取得するために、図50のサポートデータベースのXXXテーブルへのアクセスを提供する。装置のウェブページから所望の情報を取得するFirstHTTPImplementationパッケージにより使用される方法は、2002年12月26日に出願した関連出願第10328026号遠隔監視された装置のウェブページから情報を取り出すために構造のベクトルを用いる方法に記載されている。その内容は、ここに参照により援用する。FirstHTTPImplementationパッケージの方法は、最初に出てきたキーワードを用いて所望の情報を特定するが、こうして得られた情報は、場合によっては正しくない。上で説明したように、第1のHTTP実装が処理できない問題を解決するため、新しいシステムは以下のことを実現するように設計されている:1所望の情報を特定するために使用するキーワードが2回以上出てくるウェブページから所望の情報を正しく取得する新しいメソッドを追加する;22つのメソッドFirstHTTPIMplementationとSecondHTTPImplementationが所望の情報を取得できない新しいウェブページがある場合、新しいメソッドの追加を可能とする;及び3システムが装置のウェブページから以前取得した所望の情報を取得できるようにバックワードコンパチブルとする。図40と41によるHTTPパッケージの設計により、これらの望ましい特徴が可能となる。図41にSecondHTTPIMplementationパッケージを加え、サポートデータベースに図50のテーブルを加えることにより、所望の情報を特定するキーワードが複数回出てくる装置のウェブページから情報を取得するHTTPの実装が追加される。図41の抽象クラスCAbsHTTPImplementationと図40のパッケージ構造により、装置のウェブページから情報を取得するHTTPの新しい実装を追加することができる。いかにしてウェブページから情報を取得するかに関する情報を提供する新しいテーブルがデータベースに追加される。図41に示したCHTTPProtocolは、ウェブページから情報を取得するHTTPの適当な実装を管理し、使用する。図45と46は、CHTTPProtocolがHTTPの異なる実装をいかに管理し使用するかを説明するフローチャートである。本システムの実施形態は、新しいウェブページのための新しいHTTPの実装とともに、以前のウェブページから情報を取得できるように、以前のHTTPの実装も含み、使用する。図53は、CSecondHTTPImplementationのマップ構造mVendorModelWebInfoMapを示す図である。このマップ構造は、装置のウェブページからその装置のステータス情報を取得するために、HTTPの第2の実装により使用される。そのマップのキーは、装置のベンダー名を表すストリングである。そのマップの値は、与えられたモデルの装置ウェブページからステータス情報を取得するために用いられる情報を含む他のマップである。内部マップのキーは、装置のモデル名のストリングであり、その値は、ウェブページに関する情報とウェブページからステータス情報をいかに取得するかに関する情報を含む構造SwebPageInfoのベクトルである。構造SwebPageInfoは、ウェブページから一片の情報を取得するために必要なすべての情報を提供する構造SpreconKeyValueInfoを含む。SPreconKeyValueInfoは、ストリング属性sPreconditionを加えてHTTPの第1の実装を用いてウェブページから一片の情報を取得するために使用する構造SKeyValueInfoと同様である。アペンディックス5は、SpreconKeyValueInfoの構造使用を示す。HTTPの第1の実装は構造SKeyValueInfoを使用し、HTTPの第2の実装は構造SPreconKeyValueInfoを使用する。マップ構造には、図50に示したように、HTTPの第2の実装のサポートデータベースのテーブルからの情報がエントリーされるCSecondHTTPImplementationは、SecondHTTPODBMパッケージを用いてデータベースのテーブルから情報を取得する。図54は、CSecondHTTPImplementationのマップ構造mModelWebInfoForVendorMapを示す図である。このマップ構造は、装置のウェブページからその装置のモデルを取得するために、HTTPの第2の実装により使用される。そのマップのキーは、装置のベンダー名を表すストリングである。値は、モデル名を含むウェブページとそのモデル名をいかに取得するかに関するベンダーのサポートされたモデルの情報を含むペアのベクトルである。マップ構造には、図50に示したように、HTTPの第2の実装のサポートデータベースのテーブルからの情報がエントリーされる図55は、CSecondHTTPImplementationのマップ構造mVendorModelUniqueIDInfoMapを示す図である。このマップ構造は、装置のウェブページからその装置の一意的識別子を取得するために、HTTPの第2の実装により使用される。一意的識別子は、装置を特定するストリング例えば、シリアルナンバーまたはMACアドレス等である。そのマップのキーは、装置のベンダー名を表すストリングである。その値は、その装置のモデルの一意的識別子を取得するために使用される情報を含む他のマップである。内部マップのキーはそのモデル名のストリングであり、値はウェブページ及びそのウェブページから一意的識別子をいかに取得するかに関する情報を含む構造SwebPageInfoである。マップ構造には、図50に示したように、HTTPの第2の実装のサポートデータベースのテーブルからの情報がエントリーされる図56は、CSecondHTTPImplementationの関数obtainStatusを示すフローチャートである。この関数は、マップ構造mVendorModelWebInfoMapを用いて装置のウェブページからステータス情報を取得するために使用される。obtainStatusで呼ばれた関数selectEntriesは、HTTPを解して装置からどのステータス情報を取得するかを決定する。装置のベンダーとモデルに対応する情報を取得する。selectEntriesは、どの情報を取得するかに関する情報を含むベクトルlocInputVectorを返す。一部の情報はステータスマップinOutDataにすでに存在する。その場合、HTTPにより取得されるステータス情報がステータスマップ中のステータス情報より高い優先度または重みを有する場合、selectEntriesはこの情報をベクトルlocInputVectorに入れてHTTPによりそのステータス情報が確実に取得されるようにする。obtainStatusで呼ばれたobtainDataFromHTMLFileは、ウェブページのすべてのステータス情報を取得する。obtainDataFromHTMLFileは、クラスCSecondHTMLProcessorのオブジェクトを用いて、ウェブページからのデータを処理してステータス情報を取得する。この関数により使用されるメソッドは、第1の実装により使用されるメソッドと同様である。第2の実装は構造SPreconKeyValueInfoを使用し、一方、第1の実装は構造SKeyValueInfoを使用する点で異なる。図57と58は、ベクトル構造mKeyValueVectorとmLocateValueVectorを示す。これらのベクトル構造は、HTTPの第2の実装を用いてウェブページからのデータを処理して所望の情報を取得するために、CSecondHTMLProcessorで使用される。図57において、ベクトルmKeyValueVectorは、被監視装置のウェブページから各種のステータス情報をいかに取得するかに関する情報を含む。構造SPreconKeyValueInfoは、ウェブページのステータス情報を特定し取り出すために使用される情報を提供する。図58において、ベクトルmLocateValueVectorは、ステータス情報を取り出すためにウェブページから取得する情報の処理に使用される。2つのベクトルは、ステータス情報を取り出すプロセスでともに使用される。mKeyValueVectorとmLocateValueVectorの間には1対1の対応関係がある。mKeyValueVectorの最初のエントリーをmLocateValueVectorお最初のエントリーとともに用いて、ステータス情報を取得する。以下、2つのベクトルの残りのエントリーも同様である。図57と58のベクトル構造は、HTTPの第1の実装に使用されるベクトル構造と同様である。これは、関連出願第10328026号に記載した。図59は、上記関連出願第10328026号の図26を修正したものである。上記関連出願からの変更点は、例えば、構造名CではなくSを用いるとSKeyValueInfoの属性メンバーの名称を変更したことである。CFirstHTMLProcessorは、上記関連出願で説明したメソッドを用いて、これらの2つのベクトル構造を用いてウェブページからステータス情報を取得する。この関連出願第10328026号の内容は、ここに参照により援用する。図60は、図57と58のベクトル構造を設定するために使用するCsecondHTMLProcessorの関数initDataSearchInfoのフローチャートである。この関数は、ウェブページからステータス情報を取得する前にCSecondHTMLProcessorの関数obtainDataFromHTMLFileにより呼び出される。ベクトルmKeyValueVectorの各SPreconKeyValueInfoについて、ベクトルmLocateValueVectorに入れられたSLocateValueInfoがある。SPreconKeyValueInfoのmsPrecondition属性ストリングが空であるとき、SLocateValueInfoの属性mbPreconditionOKは真に設定され、それによりステータス情報を特定する前提条件はないことを示す。msPreconditionストリングが空でない場合、mbPreconditionOKを偽に設定する。HTTPの第1の実装と同様に、HTTPの第2の実装は、HTML文書のテキストタグ無しエレメントからステータス情報を取得する。アペンディックス6は、図38Bに対応するウェブページからステータス情報のHTML文書の一部を示す。HTML文書のテキストは太字になっている。図61は、ステータス情報を取得するためのCSecondHTMLProcessorの関数searchAndObtainDataFromValueによるテキスト処理を示すフローチャートである。この関数は図57と58のベクトル構造を使用する。この関数は、ウェブページからテキストタグ無しエレメントを取得する時にCSecondHTMLProcessorの関数obtainDataFromHTMLFileにより呼び出される。searchAndObtainDataFromValueのプロセスは、ステータス情報を特定するキー値が複数回出てくる場合を処理する。その場合には、前提条件preconditionストリングを使用する。プロセスは、最初に前提条件preconditionストリングを探す。前提条件preconditionストリングが見つかると、キー値を探す。キー値が見つかると、ステータス情報を取り出すことができる。ウェブページ上の同じキー値に対する各種のステータス情報は、一意的な前提条件preconditionストリングを有する。アペンディックス6の例を参照して、キー値ブラックを用いて、ブラックトナーカートリッジ及びブラック画像化ユニットのステータスを見つける。前提条件preconditionを使用しないと、Okは、ブラックトナーカートリッジとブラック画像化ユニットの両方のステータスである。ブラックトナーカートリッジのステータスに対してトナーカートリッジ、及びブラック画像化ユニットのステータスに対して画像化ユニットという前提条件preconditionを用いると、両方で正しいステータス情報を取得できる。SprecondKeyValueInfoのmsPreconditionが空の場合、それに対応するmbPreconditionOKが真となり、SPreconKeyValueInfoのステータス情報を取得するプロセスはHTTPの第1の実装を使用してステータス情報を取得するプロセスと完全に同じである。本システムの実施形態は、装置のMIBのすべての情報を取得するためにSNMPGetとGetNextの両方のリクエストを実装する。本願発明者による以前の出願の実施形態では、SNMPのGetNextリクエストだけを使用していたため、システムが装置のMIBのすべての情報にアクセスする能力を制限していた。以前のシステムでは、データベースは、装置のMIBからどの情報を取り出すかを決定するオブジェクト識別子のストリングを含んでいた。本発明の好ましい実施形態においては、オブジェクト識別子のストリングは、オブジェクト識別子とともにSNMPリクエストの種類に関する情報を含む。そのストリング中のオブジェクト識別子には、Getリクエストを実行すべきことを示すためGを先頭に付加し、GetNextリクエストを実行すべきことを示すためNを先頭に付加する。オブジェクト識別子の前に文字がなければ、デフォルトでGetNextリクエストを実行する。オブジェクト識別子の前にGとN以外の文字がある場合、リクエストは実行されない。オブジェクト識別子のストリングが空であるか、または文字Nだけを含む場合、GetNextリクエストを実行する。図62は、SNMPを用いて異なるベンダーとモデルの装置から情報を取得するために用いられるサポートデータベースのテーブルのサンプルエントリーを示す図である。図63は、SNMPパッケージのクラス図であり、図24に示したパッケージ図に基づく。留意すべきことは、オブジェクト識別子のストリングにリクエストのタイプが組み込まれていることである。図64は、SNMPaccessパッケージを示すクラス図である。CSNMPaccessクラスはこのパッケージのインターフェイスであり、データを取得するために使用するSNMPリクエストのタイプを決定する。クラスCSNMP、CSnmpSession、及びCsnmpUtilityは、装置のMIBから情報を取得するためにSNMPプロトコルを実装する。図65は、SNMP要求タイプとオブジェクト識別子の情報を含む文字列のSNMP要求の処理を示すフローチャートである。プロセスは、CSNMPaccessの関数obtainValueに続く。SNMPリクエストがうまくいくと、obtainValueFromXXXRequestはoutsValueに値を割り当てる。ここで、XXXはGetまたはGetNextである。outsValueについて空のストリングが返される。ネットワークに接続された監視が必要な少数の装置について本発明を示したが、当然のことながら、本発明の精神と範囲から逸脱することなく、ネットワークに接続される装置の数はいくつでもよい。また、本発明は、いろいろな装置を監視かつ制御する必要があるような家庭環境に適用してもよい。本発明の実施形態によれば、マルチベンダー環境において、いろいろな装置の監視が可能となり、特定のプライベートなマネージメント情報ベースMIB情報を有さなくても、詳細な情報を読み出し、ユーザが理解しやすく扱いやすい方法で表示することができる。さらにまた、読み出した情報は、SMTP、FTP、ウェブサービス等のいろいろな方法を用いて再配信することができる。本発明のコントローラは、本発明の教示によりプログラムされた、従来の汎用デジタルコンピュータまたはマイクロプロセッサであり、コンピュータ技術の当業者には明らかである。熟練したプログラマーは本開示の教示に基づき容易に適当なソフトウェアのコーディングをでき、ソフトウェア技術の当業者には明らかである。本発明は、特定用途用集積回路や従来のコンポーネント回路を適当に配線して相互接続することによっても実施することができ、これは当該分野の当業者には明らかである。本発明はコンピュータをプログラムし本発明のプロセスを実行させる命令を含むコンピュータプログラム、およびそのコンピュータプログラムが格納された記録媒体を含む。記録媒体には、フレキシブルディスク、光ディスク、CDROM、光磁気ディスク、ROM、RAM、EPROM、EEPROM、磁気または光カード、その他の電子的命令を格納するのに好適ないかなる媒体も含む。上記の教示を考慮して本発明を様々に修正したり、バリエーションを考えたりすることができる。従って、当然のことながら、添付したクレームの範囲内で、ここに具体的に説明したものとは別の実施形態により本発明を実施することができる。なお、上記の実施形態に関して以下の付記を記す。付記1ネットワークを介して接続された被監視装置と関連する情報をSNMPプロトコルを用いて抽出する方法であって、メモリにアクセスして前記被監視装置にアクセスするためのアクセス情報を取得するステップを有し、前記アクセス情報は、1前記被監視装置から取得する一種類のステータス情報と、2前記被監視装置から前記一種類のステータス情報を取得するために用いるアクセス文字列とを含み、前記方法は、前記アクセス文字列を分析して、前記アクセス文字列が記憶されていたかどうか判断し、前記アクセス文字列が記憶されていたとき、前記アクセス文字列が所定の文字列を含むかどうか判断するステップと、前記分析するステップにおいて、前記アクセス文字列が記憶されていて、前記アクセス文字列が前記所定の文字列を含むと判断した場合、第1のSNMPアクセス関数を用いて前記被監視装置にアクセスして前記一種類のステータス情報と関連した値を取得するステップと、前記分析するステップにおいて、前記アクセス文字列が記憶されていないか、または前記アクセス文字列が前記所定の文字列を含まないと判断した場合、第2のSNMPアクセス関数を用いて前記被監視装置にアクセスして前記一種類のステータス情報と関連した値を取得するステップと、をさらに有し、前記メモリにアクセスするステップは、前記メモリにアクセスして前記被監視装置から取得すべき前記一種類のステータス情報に対応するオブジェクト識別子情報を取得するステップを有することを特徴とする方法。付記2付記1に記載の方法であって、前記分析するステップは、前記アクセス文字列を分析して、前記アクセス文字列が記憶されている場合、前記アクセス文字列の第1のエレメントが前記所定の文字列であるかどうかを判断するステップを有することを特徴とする方法。付記3付記1に記載の方法であって、前記第1のSNMPアクセス関数はSNMPのGet関数であり、前記第2のSNMPアクセス関数はSNMPのGetNext関数であることを特徴とする方法。付記4付記1に記載の方法であって、前記メモリにアクセスするステップは、前記被監視装置にアクセスするための前記アクセス情報を格納するように構成された外部記憶装置に複数の通信プロトコルを用いてアクセスするステップをさらに有することを特徴とする方法。付記5ネットワークを介して接続された被監視装置と関連する情報をSNMPプロトコルを用いて抽出する監視装置であって、メモリにアクセスして前記被監視装置にアクセスするためのアクセス情報を取得する手段を有し、前記アクセス情報は、1前記被監視装置から取得する一種類のステータスと、2前記被監視装置から前記一種類のステータス情報を取得するために用いるアクセス文字列とを含み、前記被監視装置は、前記アクセス文字列を分析して、前記アクセス文字列が記憶されているかどうか判断し、前記アクセス文字列が記憶されているとき、前記アクセス文字列が所定の文字列を含むかどうか判断する手段と、前記分析する手段において、前記アクセス文字列が記憶されていて、前記アクセス文字列が前記所定の文字列を含むと判断した場合、第1のSNMPアクセス関数を用いて前記被監視装置にアクセスして前記一種類のステータス情報と関連した値を取得する手段と、前記分析する手段において、前記アクセス文字列が記憶されてないか、または前記アクセス文字列が前記所定の文字列を含まないと判断した場合、第2のSNMPアクセス関数を用いて前記被監視装置にアクセスして前記一種類のステータス情報と関連した値を取得する手段と、をさらに有し、前記メモリにアクセスする手段は、前記メモリにアクセスして前記被監視装置から取得すべき前記一種類のステータス情報に対応するオブジェクト識別子情報を取得する手段を有することを特徴とする監視装置。付記6付記5に記載の監視装置であって、前記分析する手段は、前記アクセス文字列を分析して、前記アクセス文字列が記憶されている場合、前記アクセス文字列の第1のエレメントが前記所定の文字列であるかどうかを判断する手段を有することを特徴とする監視装置。付記7付記5に記載の監視装置であって、前記第1のSNMPアクセス関数はSNMPのGet関数であり、前記第2のSNMPアクセス関数はSNMPのGetNext関数であることを特徴とする監視装置。付記8付記5に記載の監視装置であって、前記メモリにアクセスする手段は、前記被監視装置にアクセスするための前記アクセス情報を格納するように構成された外部記憶装置に複数の通信プロトコルを用いてアクセスする手段をさらに有することを特徴とする監視装置。付記9コンピュータに付記1ないし4いずれか一項に記載の方法を実行させることを特徴とするコンピュータプログラム。