JP2006202283A

JP2006202283A - 被監視装置関連情報を抽出する方法、システム及びコンピュータプログラム

Info

Publication number: JP2006202283A
Application number: JP2006004237A
Authority: JP
Inventors: Tetsuro Motoyama; 哲郎元山; Avery Fong; フォングアヴェリー
Original assignee: Ricoh Co Ltd
Current assignee: Ricoh Co Ltd
Priority date: 2005-01-11
Filing date: 2006-01-11
Publication date: 2006-08-03
Also published as: EP1679821B1; EP1679821A1; US20060155846A1; DE602006001753D1; US7467195B2; JP2012027920A; JP5090562B2

Abstract

【課題】オブジェクト識別子にアクセスするためのSNMPリクエストを区別する。
【解決手段】ネットワークを介して接続された被監視装置と関連する情報をSNMPプロトコルを用いて抽出する方法。メモリにアクセスして前記被監視装置にアクセスするためのアクセス情報を取得する。前記アクセス情報は、（１）前記被監視装置から取得する一種類のステータスと、（２）前記被監視装置から前記一種類のステータス情報を取得するために用いるアクセス文字列とを含む。前記アクセス文字列を分析して、前記アクセス文字列が記憶されているかどうか判断し、前記アクセス文字列が記憶されているとき、前記アクセス文字列が所定の文字列を含むかどうか判断する。
【選択図】図６２

Description

本発明はネットワークを介した装置の監視に関する。特に、複数のプロトコルを用いてネットワークを介して装置を遠隔監視する方法、装置、コンピュータプログラム、およびそのコンピュータプログラムを格納した記憶媒体に関する。

広く知られているように、コンピュータシステムにはハードウェアとソフトウェアが含まれる。ソフトウェアはコンピュータシステムを構成するハードウェア部品を動作させ管理するために作られた命令のリストを含んでいる。一般に、コンピュータシステムは相互にインターフェイスする様々なハードウェア部品や装置を含んでいる。コンピュータにはスタンドアロンのものやネットワークで接続されたものがある。ネットワークタイプのコンピュータシステムは、複数の装置がネットワークに接続されており、そのネットワークを介して通信が行われる。

さらに、ハードウェア装置間の通信を可能とするために、ハードウェア装置が協働的に機能するように、ハードウェア装置を動作させるソフトウェアが構成されていなければならない。さらに、通信を容易にするため、ハードウェア装置を監視し、各ハードウェア装置が効率的に機能していることを保証するために、その状態を知っていることが望ましい。

本特許出願のために、複数の個別の装置またはハードウェア装置を制御、設定、監視するハードウェア装置を監視装置と呼び、監視装置により制御、設定、監視されているハードウェア装置を「被監視装置」と呼ぶ。

ネットワーク上のハードウェア装置は、メンテナンス、使用、その他の目的のために監視されていることが望ましい。しかし、ハードウェア装置とインターフェイスに関する製造者の違いを考慮すると、監視装置がネットワークに接続された他のいろいろな装置と通信することは困難である。このような不利益により、ネットワーク管理者は、そのネットワークに接続された装置の性能と効率についての重要な情報を取得することができない。

シンプルネットワークマネージメントプロトコル（SNMP）は、今日、データ通信ネットワーク上の装置、電気通信システム、その他のグローバル到達可能装置を監視および管理するためのデファクトスタンダードである。実際には、コンピュータ及び関連装置を取り扱うすべての組織は、ローカルエリアネットワークやワイドエリアネットワークを通じて各装置を集中的に監視、診断、設定できることを期待している。SNMPはこのようなインターラクションを実現するプロトコルである。

装置がSNMPリクエストに応答するために、SNMPリクエストを正しく解釈し、そのリクエストにより要求されたアクションを実行し、SNMPリプライを生成することができるようにするソフトウェアを装置に備えることが望ましい。SNMPエージェントソフトウェアは、一般的にネットワークの構成要素に備えられたサブシステムソフトウェアモジュールである。

システムにより使用されるオブジェクトは、一般に管理情報ベース（MIB）と呼ばれる。MIBは装置の監視に関する情報のデータベースでもある。MIBの例としては、二、三例を挙げると、イーサネット（登録商標）インターフェイスにフォーカスしたイーサネット（登録商標）MIB、802.1Dブリッジ管理用のオブジェクトを定義するブリッジMIB等がある。

装置の監視にSNMPを使用することは困難である。それは、有効なキーが無ければ解読困難な値がプライベートMIBに含まれているからである。自社のネットワークに接続されたいろいろな装置を監視するためにSNMPを使用している会社は、その会社の独占情報として維持されるユニークな識別子／キーを生成する。通例、結果は二値または整数の値として表示される。このように、SNMPを用いても、監視されている装置（「被監視装置」）から受信した結果は、被監視装置の状態をユーザが理解可能な形でユーザに提供することはできない。

さらに、SNMPを用いても、有効なキーなしに被監視装置についての詳細な情報を取得し、プライベートMIBにアクセスして、二値または整数値として取得した結果を解読することは困難である。また、与えられたプロトコル（例えば、SNMPまたはHTTP/HTML）は、タイムアウトやロストパケット等のいろいろな理由でうまく機能しないこともある。また、複数のプロトコルを用いて与えられた装置から抽出した情報は、各プロトコルでダブっているかも知れない。従って、このような状況において装置からのデータ抽出をうまく管理しないと、プロトコルによっては他のプロトコルよりも多くのリソースを必要とするものもあるので、時間とメモリの効率が悪くなる。また、一部のプロトコルを用いて情報抽出をすれば、他のプロトコルを用いるよりも少ない処理量と費用で情報を抽出することができるかも知れない。さらにまた、あるプロトコルを用いて取得した情報は、他のプロトコルを用いて取得した情報よりも監視装置にとって有用であるかも知れない。

図３８Aないし３８Cは、被監視装置に関する情報が抽出されるHTMLファイルの例を示す。図３８Aは、異なるカラートナーの状態を示す装置のウェブページである。一部の監視システムは、特定のテキストを探すことにより、ステータス情報を取得する。例えば、ブラックトナーカートリッジの状態を取得するため、テキスト「ブラックトナー」を探す。図３８Bは、一部の監視システムの問題を示す装置のウェブページである。ある色の画像化部の状態を取得するために、システムはその色のテキスト（すなわち、ブラック、シアン、マゼンタ、イエロー）の１つを探す。しかし、システムはトナーカートリッジに関するテキスト「ブラック」を見つけ、それをステータス情報としてしまうので、カラー画像化部の正しいステータス情報は取得できない。同じウェブページ上で同じテキストが使用されている異なるステータス情報を取得することにより問題が発生する。通常、ステータス情報はテキストが最初に出てきたときに取得される。図３８Cは、装置の他のウェブページであり、システムは、総ページ数、総印刷ジョブ数、使用した紙の総枚数のステータス情報をテキスト「Total」のところに表示する。最初の「Total」を見つけ、間違って総印刷ジョブ数や使用用紙枚数のステータス情報を間違って割り当ててしまう。このように、例えば、異なる装置のHTMLファイルから情報を抽出するには異なる方法が必要である。

本発明のシステムと方法は、ネットワークに接続された装置を監視可能とすることにより、上記問題を解決する。従って、ネットワークを介して装置を監視する方法を説明する。

該方法はハードウェアアクセスモジュールを介して第１のデータベースにアクセスするステップを含み、前記第１のデータベースは複数の通信プロトコルをサポートするように構成されている。第１のデータベースには、被監視装置の製造者やモデル情報等、様々な情報を取得するため複数の通信プロトコルにより使用される情報が格納されている。通信プロトコルが複数の通信プロトコルから選択され、選択された通信プロトコルが被監視装置からステータス情報を受信するように設定される。該方法は、前記第１のデータベースから選択された通信プロトコルと情報を用いて前記被監視装置を評価するステップと、前記アクセスされた装置からステータス情報を受信するステップと、前記受信したステータス情報を第２のデータベース（DeviceODBC）に格納するステップとを有する。

他の実施形態において、本発明はネットワークを介して装置を監視する方法を提供する。複数の通信プロトコルは被監視装置から情報を読み出すために使用される。例えば、SNMPプロトコルが最初に被監視装置にアクセスするために選択され、SNMPプロトコルを用いて効率的に読み出せるように構成された装置情報が取得される。その後、前記装置がその他のHTTPおよびFTPプロトコル等をサポートしているとき、SNMPプロトコルを用いて効率的に読み出すことができない情報を取得するために、それらのプロトコルを選択する。プロトコルの選択は、データベースに格納されたサポート情報と併せてプロトコルマネージャにより実行される。

本発明において、例えばLANやWANなどのネットワークに接続された少なくとも１つの装置（被監視装置）の監視が監視システムにより可能となる。前記被監視装置はユニークIPアドレスを有する。被監視装置に割り当てられたIPアドレスと、前記被監視装置のベンダー／製造者の詳細とは、データベースに格納される。ネットワークをスキャンして装置に問い合わせることにより、装置のIPアドレスを取得できる。その方法は既知である。それゆえ、監視される装置のIPアドレスはすでに取得され、データベースに格納されていると仮定する。

本発明は、被監視装置から受け取ったHTML情報から必要な情報をいかに抽出するかを特定している。一旦、被監視装置のウェブページにアクセスすると（すなわち、IPアドレスと特定されたポートを通じて）、被監視装置に対応するウェブページが表示される。そのウェブページの情報はキーと値のペアである。例えば、カラープリンターのウェブページにおいて、トナーレベルは「ブラック１００％」のように表示される。HTML/XMLパーサを用いて、ウェブページの情報から必要な情報を読み出すためにそのページを解釈する。HTML／XMLパーサを用いてウェブページから抽出した必要情報とパラメータ値はサポートデータベースに格納される。

本発明は、ここで説明したように、監視システムによりサポートされた被監視装置のベンダーと装置モデルも特定する。被監視装置のいろいろなベンダーがそのベンダー固有のやり方で被監視装置に関する情報を提示しているので、本発明により被監視装置のベンダーとモデルを特定して被監視装置の動作状態を判断することができる。

本発明の一態様によると、ネットワークを介して接続された被監視装置に関するステータス情報を抽出するために用いる、それぞれ通信プロトコルと関連した複数のプロトコルオブジェクトを初期化する方法、システム、及びコンピュータプログラム製品が提供される。これらは、（１）前記それぞれの通信プロトコル中の一通信プロトコルを選択し、（２）前記選択された通信プロトコルを用いて前記装置にアクセスするための情報を第１のメモリから読み出し、（３）前記選択された通信プロトコルと前記第１のメモリから読み出した情報を用いて前記装置にアクセスして前記装置に関するベンダー情報の取得を試み、（４）前記ベンダー情報が前記装置から取得されたかどうか判断し、（５）前記ベンダー情報が前記装置から取得された場合、前記通信プロトコルをそれぞれ用いて前記ステータス情報を抽出するサポート情報を第２のメモリから取得し、前記ベンダー情報と前記それぞれのサポート情報を前記複数のプロトコルオブジェクトの各プロトコルオブジェクトに格納し、（６）前記ベンダー情報が前記装置から取得されなかった場合、前記ベンダー情報を取得するまで、または前記通信プロトコルの各通信プロトコルが選択されるまで、前記（１）から（５）を繰り返す。

本発明の他の態様によると、ネットワークを介して接続された被監視装置からどの種類のステータス情報を取得するかを判断する方法、システム、及びコンピュータプログラム製品が提供される。これらは、（１）前記装置からステータス情報を抽出するために用いる複数の通信プロトコルから一の通信プロトコルを選択し、（２）前記選択された通信プロトコルと関連するプロトコルオブジェクトを第１のメモリから読み出し、（３）前記一種類のステータス情報が第２のメモリにあるかどうか判断し、（４）前記判断において前記一種類のステータス情報が前記第２のメモリにあると判断された場合、前記プロトコルオブジェクトに格納されたステータス情報のウェイトが前記第２のメモリに格納された同種類のステータス情報と関連する対応するウェイトより大きいかどうかチェックし、（５）（ａ）前記判断において前記一種類のステータス情報が前記第２のメモリにないと判断された場合、または（ｂ）前記判断において前記一種類のステータス情報が前記第２のメモリにあるが、前記プロトコルオブジェクトに格納されたステータス情報のウェイトが前記第２のメモリに格納された同種類のステータス情報と関連する対応するウェイトより大きいと判断された場合、前記選択された通信プロトコルと前記プロトコルオブジェクトに含まれた前記装置を抽出する情報とを用いて前記装置にアクセスして前記ステータス情報を取得する。前記プロトコルオブジェクトは、一種類のステータス情報、前記ステータス情報の重み、前記前記選択された通信プロトコルを用いて前記装置から前記一種類のステータス情報を抽出するための情報を少なくとも含み、前記第２のメモリは前記装置から前もって抽出したステータス情報を有する。

本発明のさらに他の態様によると、ネットワークを介して接続された少なくとも１つの監視装置に関する情報を管理する方法、システム、及びコンピュータプログラム製品が提供される。これらは、（１）前記少なくとも１つの被監視装置からステータス情報を抽出するために用いる複数の通信プロトコルから一の通信プロトコルを選択し、（２）前記選択された通信プロトコルと関連するプロトコルオブジェクトを第１のメモリから読み出し、（３）前記選択された通信プロトコルによりサポートされた前記少なくとも１つの被監視装置の一の被監視装置のベンダー名を前記プロトコルオブジェクトから取得し、（４）前記取得されたベンダー名に対応するモデル名を前記プロトコルオブジェクトから取得し、（５）前記取得したベンダー名とモデル名を用いて表現ストリング（文字列）を生成し、（６）前記表現ストリング（文字列）が第２のメモリにあるかどうか判断し、（７）前記判断において前記表現ストリング（文字列）が前記第２のメモリに無いと判断した場合、前記表現ストリング（文字列）を前記プロトコルオブジェクトと関連づけて前記第２のメモリに格納する。前記プロトコルオブジェクトは、前記少なくとも１つの被監視装置のベンダーとモデルの情報を含む。

本発明のさらに他の態様によると、ネットワークを介して接続された被監視装置からステータス情報を抽出するのに必要な情報を管理する方法、システム、コンピュータプログラム製品が提供される。これらは、（１）前記被監視装置から前記ステータス情報を取得するために用いられる複数の通信プロトコルの一通信プロトコルを選択し、第１のメモリから表現ストリングを読み出し、（３）前記表現ストリングから前記ベンダー名と前記対応するモデル名を抽出し、（４）前記抽出されたベンダー名と前記抽出されたモデル名が前記被監視装置のベンダー名とモデル名にそれぞれマッチするかどうか判断し、（５）前記抽出されたベンダー名と前記抽出されたモデル名が前記被監視装置のベンダー名とモデル名にそれぞれマッチする場合、前記選択された通信プロトコルを用いて前記装置にアクセスして前記ステータス情報を取得する。前記表現ストリングは、前記選択された通信プロトコルによりサポートされたベンダー名と対応するモデル名を含む。

本発明のさらに他の態様によると、どの通信プロトコルをネットワーク装置に関するステータス情報を取得するために用いることができるか判断する方法、システム、コンピュータプログラム製品が提供される。これらは、複数の通信プロトコルから一通信プロトコルを選択し、（２）前記選択された通信プロトコルを用いて前記ネットワーク装置にアクセスするための情報を前記ネットワーク装置と関連したデバイスオブジェクトから取得し、（３）前記選択された通信プロトコルと前記デバイスオブジェクトから取得した前記ネットワーク装置にアクセスするための情報とを用いて前記ネットワーク装置にアクセスできるか判断し、（４）前記判断において、前記通信プロトコルを用いて前記ネットワーク装置にアクセスできないと判断した場合、前記選択された通信プロトコルを用いて前記ネットワーク装置にアクセスするための情報を前記デバイスオブジェクトから削除し、（５）前記判断において、前記通信プロトコルを用いて前記ネットワーク装置にアクセスできると判断した場合、さらにテストをして、前記選択された通信プロトコルを用いて前記ネットワーク装置から前記ステータス情報を抽出することができるか判断する。

さらに、前記さらなるテストは、（１）前記選択された通信プロトコルを用いて前記ネットワーク装置のベンダーを前記ネットワーク装置から取得できるかどうか判断し、（２）前記判断において前記選択された通信プロトコルを用いて前記ベンダーを取得できないと判断した場合、前記選択された通信プロトコルがジェネリックベンダーをサポートするかどうかチェックし、前記選択された通信プロトコルが前記ジェネリックベンダーをサポートしない場合、前記選択された通信プロトコルを用いて前記ネットワーク装置にアクセスするための情報を前記デバイスオブジェクトから削除し、（３）前記判断において前記選択された通信プロトコルを用いて前記ベンダーを取得できると判断した場合、前記ネットワーク装置から前記ベンダーを取得して前記選択された通信プロトコルによりその取得したベンダーがサポートされているかどうか判断し、（４）前記取得したベンダーが前記選択された通信プロトコルによりサポートされていない場合、前記選択された通信プロトコルが前記ジェネリックベンダーをサポートしているかどうかチェックし、前記選択された通信プロトコルが前記ジェネリックベンダーをサポートされていない場合、前記選択された通信プロトコルを用いて前記ネットワーク装置にアクセスするための前記情報を前記デバイスオブジェクトから削除し、（５）前記取得されたベンダーが前記選択された通信プロトコルによりサポートされている場合、モデル情報に関するさらなるテストを実行する。

また、モデル情報に関するさらなるテストの実行は、（１）前記ネットワーク装置のモデルが前記選択された通信プロトコルを用いて前記ネットワーク装置から取得できるかどうか判断し、（２）前記判断において前記モデルが前記選択された通信プロトコルを用いて取得できないと判断された場合、前記選択された通信プロトコルがジェネリックベンダーをサポートしているかどうかチェックし、前記選択された通信プロトコルがジェネリックベンダーをサポートしていない場合、前記選択された通信プロトコルを用いて前記ネットワーク装置にアクセスするための前記情報を前記デバイスオブジェクトから削除し、（３）前記判断において、前記モデルが前記選択された通信プロトコルを用いて取得可能であると判断された場合、前記ネットワーク装置から前記モデルを取得し、前記取得したモデルが前記選択された通信プロトコルによりサポートされているかどうか判断し、（４）前記取得したモデルが前記選択された通信プロトコルによりサポートされていない場合、前記選択された通信プロトコルが前記ジェネリックモデルをサポートしているかどうかチェックし、前記選択された通信プロトコルが前記ジェネリックモデルをサポートしていない場合、前記選択された通信プロトコルを用いて前記ネットワーク装置にアクセスするための前記情報を前記デバイスオブジェクトから削除する。
また、本発明の他の態様によると、ネットワークを介して接続された被監視装置に関する情報を選択された通信プロトコルを用いて抽出する方法、システム、及びコンピュータプログラム製品が提供される。これらは、（１）第１のメモリから複数の実装識別子を読み出すステップを有し、各実装識別子は、（Ａ）前記選択された通信プロトコルを用いて前記被監視装置にアクセスして前記被監視装置のベンダー及びモデルの情報を取得する第１のアクセス関数と、（Ｂ）前記選択された通信プロトコルを用いて前記被監視装置にアクセスして前記被監視装置のステータス情報を取得する第２のアクセス関数とを特定するものである。前記方法は、（２）前記複数の実装識別子から一実装識別子を選択するステップと、（３）前記選択された通信プロトコルと前記選択された一実装識別子に関連した前記第１のアクセス関数とを用いて前記装置にアクセスして前記装置と関連するベンダーとモデルの情報を取得するように試みるステップと、（４）前記装置から前記ベンダーとモデルの情報を取得したか判断するステップと、（５）前記ベンダーとモデルの情報を前記装置から取得したと判断した場合、前記選択された一実装識別子を前記取得されたベンダーとモデルの情報と関連づけて第２のメモリに格納するステップと、（６）前記ベンダーとモデルの情報を前記装置から取得しなかったと判断した場合、前記ベンダーとモデルの情報を取得するまで、または前記複数の実装識別の各実装識別子が選択されるまで、前記選択するステップ、アクセスするステップ、及び判断するステップを繰り返すステップと、をさらに有する。

さらにまた、本発明の他の態様によると、ネットワークを介して接続された異なる装置のうち一の被監視装置に関する情報を抽出するために選択された通信プロトコルにより用いられるように構成された情報を管理する方法、システム、及びコンピュータプログラム製品が提供される。これらは、（１）メモリから複数の実装識別子を読み出すステップを有し、各実装識別子は、（Ａ）前記選択された通信プロトコルを用いて前記被監視装置にアクセスして前記被監視装置のベンダー及びモデルの情報を取得する第１のアクセス関数と、（Ｂ）前記選択された通信プロトコルを用いて前記被監視装置にアクセスして前記被監視装置のステータス情報を取得する第２のアクセス関数とを特定する。前記方法は、さらに、（２）前記複数の実装識別子のうち一の実装識別子を選択するステップと、（３）第1の記憶手段にアクセスして前記選択された通信プロトコルを用いて前記第1のアクセス関数と前記第2のアクセス関数のうち少なくとも一方を用いて前記被監視装置にアクセスするためのサポート情報を取得するステップと、をさらに有し、前記サポート情報は、前記被監視装置から前記ステータス情報または前記ベンダーとモデルの情報を取得するために使用する前提条件情報を含む。前記方法は、さらにまた、（４）少なくとも１つの第２の記憶手段に前記サポート情報を格納するステップをさらに有し、前記前提条件情報により、前記被監視装置から取得可能な一種類の関心情報の記憶領域が制限される。ここで、前記第1の記憶手段と第2の記憶手段は、同一の記憶手段であってもよい。

さらにまた、本発明の他の態様によると、ネットワークを介して接続された被監視装置に関連する情報を抽出する方法、システム、及びコンピュータプログラム製品が提供される。これらは、（１）第１のメモリにアクセスして前記被監視装置にアクセスするためのアクセス情報を取得するステップを有し、前記アクセス情報は、前記被監視装置から取得する種類のステータス情報と前記被監視装置から前記種類のステータス情報を取得するために用いる前提条件情報とを含み、前記前提条件情報は、前記被監視装置から取得可能な前記種類のステータス情報の記憶領域を制限するために用いられる情報である。前記方法は、さらに、（２）前記被監視装置にアクセスして前記被監視装置に関連する情報文字列を取得するステップと、（３）前記前提条件情報を用いて前記情報文字列から前記種類のステータス情報に対応する情報を抽出するステップと、（４）前記被監視装置のIPアドレス等の識別情報と関連づけて前記抽出した情報を格納するステップと、を有する。

さらにまた、本発明の他の態様によると、ネットワークを介して接続された被監視装置と関連する情報をSNMPプロトコルを用いて抽出する方法、システム、及びコンピュータプログラム製品が提供される。これらは、（１）メモリにアクセスして前記被監視装置にアクセスするためのアクセス情報を取得するステップを有し、前記アクセス情報は、（Ａ）前記被監視装置から取得する一種類のステータス情報と、（Ｂ）前記被監視装置から前記一種類のステータス情報を取得するために用いるアクセス文字列とを含む。前記方法は、さらに、（２）前記アクセス文字列を分析して、前記アクセス文字列が記憶されていたかどうか判断し、前記アクセス文字列が記憶されていたとき、前記アクセス文字列が所定の文字列を含むかどうか判断するステップと、（３）前記分析するステップにおいて、前記アクセス文字列が記憶されていて、前記アクセス文字列が前記所定の文字列を含むと判断した場合、第１のSNMPアクセス関数を用いて前記被監視装置にアクセスして前記一種類のステータス情報と関連した値を取得するステップと、（４）前記分析するステップにおいて、前記アクセス文字列が記憶されていないか、または前記アクセス文字列が前記所定の文字列を含まないと判断した場合、第２のSNMPアクセス関数を用いて前記被監視装置にアクセスして前記一種類のステータス情報と関連した値を取得するステップと、を有する。前記メモリにアクセスするステップは、前記メモリにアクセスして前記被監視装置から取得すべき前記一種類のステータス情報に対応するオブジェクト識別子情報を取得するステップを有する。

さらにまた、本発明の他の態様によると、選択された通信プロトコルにより使用される、ネットワークを介して接続された異なる装置のうちの被監視装置に関するステータス情報を抽出するように構成されたアクセス情報を表すデータをエンコードする方法、システム、及びコンピュータプログラム製品が提供される。これらは、（１）前記被監視装置のベンダー情報用のメモリ領域をバッファに確保するステップと、前記ベンダー情報を前記バッファに書き込むステップと、前記被監視装置のモデル情報用のメモリ領域をバッファに確保するステップと、を有し、前記モデル情報用のメモリ領域は前記ベンダー情報用のメモリ領域に関連づけられる。前記方法は、さらに、前記バッファに前記モデル情報を書き込むステップと、前記被監視装置から前記ステータス情報を取得するための前提条件情報を含む、前記被監視装置にアクセスするためのサポート情報用のメモリ領域をバッファに確保するステップと、を有し、前記サポート情報用のメモリ領域は、前記ベンダー情報用のメモリ領域及び前記モデル情報用のメモリ領域と関連づけられる。前記方法は、さらにまた、前記バッファに前記サポート情報を書き込むステップをさらに有し、前記前提条件情報により、前記被監視装置から取得可能な一種類の関心情報の記憶領域が制限される。

さらにまた、本発明の他の態様によると、選択された通信プロトコルにより使用される、ネットワークを介して接続された異なる装置のうちの被監視装置に関するステータス情報を抽出するように構成されたアクセス情報を表すデータを含むメモリを有する監視装置が提供される。前記監視装置は、（１）複数の実装識別子を第１の記憶手段から読み出す読み出し手段を有し、各実装識別子により、前記被監視装置のモデル情報、一意的識別子、及びステータス情報のうち少なくとも１つを取得するために、前記選択された通信プロトコルを用いて前記被監視装置にアクセスするように定義された少なくとも１つのアクセス関数が特定される。前記監視装置は、さらに、（２）前記複数の実装識別子から一実装識別子を選択する選択手段と、（３）前記少なくとも１つのアクセス関数を用いて、第２の記憶手段にアクセスして前記被監視装置にアクセスするサポート情報を取得する取得手段と、を含み、前記サポート情報は、前記被監視装置から前記モデル情報、前記一意的識別子、及び前記ステータス情報のうちの前記少なくとも１つを取得するために使用する前提条件情報を含む。前記監視装置は、さらにまた、前記被監視装置の実装識別子及びベンダー情報と関連づけて前記サポート情報を前記アクセス情報を表すデータとして生成する生成手段を有し、前記前提条件情報により、前記被監視装置から取得可能な一種類の関心情報の記憶領域が制限されることを特徴とする監視装置。

図１は、いろいろな装置と、その装置の動作を監視、診断、制御するコンピュータとを示す概略図である。具体的に、図１は、コンピュータワークステーション１７、１８、２０および２２に接続されたローカルエリアネットワーク（LAN）等の第１のネットワーク１６を含む。ワークステーションは、例えば、パーソナルコンピュータ、UNIX（登録商標）ベースのコンピュータ、リナックスベースのコンピュータ、アップルマッキントッシュ等を含むいかなるタイプのコンピュータであってもよい。また、デジタル画像形成装置２４、ファックス２８、プリンター３２もネットワーク１６に接続されている。当業者には明らかであるが、デジタルコピー／プリンター２４とファクシミリ２８を２つ以上組み合わせて、一体の「画像形成装置」とすることができる。例えば、コピー／プリンター２４、ファックス２８、プリンター３２、ワークステーション１７、１８、２０、２２をマシンと呼び、あるいは被監視装置と呼ぶこともある。システム構成によっては、１以上のワークステーションはビジネスオフィス機器であってもよい。また、いかなるビジネスオフィス機器／装置をネットワーク１６に付加してもよい。また、ワークステーション１７、１８、２０、２２、およびオフィス機器２７は中間監視装置として機能することもでき、ネットワーク１６上の被監視装置からデータを集め、集めたデータを監視装置に送信する。

このようなビジネスオフィス機器の一例は、株式会社リコーのeCabinet（登録商標）である。また、ファクシミリサーバ（図示せず）をネットワーク１６に接続して、電話、ケーブル、または無線で接続してもよい。デジタルコピー／プリンター２４、ファクシミリ２８、プリンター３２は、各々ネットワーク１６に接続されているのに加えて、従来の電話、ケーブル、または無線接続２６、３０、３４も有する。以下に説明するように、被監視装置２４、２８、３２は、監視装置とも呼ぶ遠隔監視・診断・制御ステーションと通信する。この通信は、例えば、ネットワーク１６とインターネットを介して、または電話、無線、またはケーブル接続を介して直接行われる。

他のビジネス環境において、被監視装置には、多機能画像化装置、スキャナー、プロジェクター、テレビ会議システム、およびシュレッダー等の装置が含まれてもよい。他のアプリケーションにおいて、ネットワーク１６はホームネットワークでもよく、その場合、被監視装置は（電気、ガス、水道等の）メータであってもよく、例えば、電子レンジ、洗濯機、乾燥機、食器洗い機、ホームエンターテイメントシステム、冷蔵庫、炊飯器、ヒーター空調機、温水器、セキュリティカメラ等の機器であってもよい。

図１において、ワイドエリアネットワーク（WAN）（例えば、インターネットやその後継ネットワーク）を参照符号１０で示した。WAN１０は、プライベートWANでも、パブリックWANでも、ハイブリッドタイプであってもよい。WAN１０は、相互接続された複数のコンピュータとルータを含み、これらは参照符号１２A-１２Iで示した。WANを介した通信方式は、インターネットエンジニアリングタスクフォース（IETF）から入手可能な一連のRequest for Comments（RFC）により知られている。、ウェブサイトwww.ietf.org/rfc.htmlを参照。例えば、RFC 821「Simple Mail Transfer Protocol」、RFC 822「Standard for the Format of ARPA Internet Text Message」、RFC 959「File Transfer Protocol(FTP)」、RFC 2045「Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies」、RFC 1894「An Extensible Message Format for Delivery Status Notifications」、RFC 1939「Post Office protocol−Version 3」、RFC 2068「Hypertext Transfer Protocol−HTTP/1.1」、及びRFC 2298「An Extensible Message Format for Message Disposition Notifications」等がある。これら引用文献の内容は参照によりここに援用する。

トランスミッションコントロールプロトコル／インターネットプロトコル（TCP/IP）に関連する通信は、例えば、W.R. Stevens著「TCP/IP Illustrated」Vol. 1, The Protocols、Addison-Wesley Publishing Company、1994年に説明されている。この書籍の内容はすべてここに参照により援用する。Comer、Stevens著「TCP/IPによるインターネットワーキング」第１巻ないし第３巻もここに引用によりその全体を援用する。

引き続き図１を参照して、ファイヤーウォール５０AがWAN１０とネットワーク１６との間に接続されている。ファイヤーウォールは、その一方の側にある権限を与えられたコンピュータだけが、他方の側にあるネットワーク、コンピュータ、個別パーツにアクセスできるようにする装置である。ファイヤーウォールは商業的に入手可能な既知の装置またはソフトウェア（例えば、Zone Labs社のZoneAlarm）である。同様に、ファイヤーウォール５０Bと５０Cは、WAN１０をネットワーク５２とワークステーション４２からそれぞれ分離している。ファイアウォールに関するさらに詳細は、W.R.Cheswick及びS.M.Bellovin著「Firewalls and Internet Security」（AddisonWesley Publishing、1994年）とD.B.Chapman及びE.D.Zwicky著「Building Internet Firewalls」（O’Reilly&Associates, Inc.、1995年）に載っている。これら２冊の引用文献の内容はここに参照により援用する。

ネットワーク５２は従来のネットワークであり、複数のワークステーション５６、６２、６８、７４を含んでいる。これらのワークステーションは分散され、一つの会社の異なる部署（例えば、販売、注文処理、会計、請求、マーケティング、生産、設計エンジニアリング、カスタマーサービス等）に配置されている。ネットワーク５２を介して接続されたワークステーションに加え、ネットワーク５２には直接接続されていないワークステーション４２も設けられている。ワークステーション４２に接続されたディスク４６に格納されたデータベース中の情報を、ネットワーク５２に直接接続されたワークステーションで、WAN１０を介して適当な暗号化およびプロトコルを用いて共有することもできる。また、ワークステーション４２は電話線、ケーブルネットワーク、及び／またはワイヤレスネットワーク４４に直接接続され、ディスク４６中のデータベースにはその電話線、ケーブルネットワーク、またはワイヤレスネットワーク４４を通してアクセスできる。本発明で使用するケーブルネットワークは、一般的にテレビジョン番組を伝送するために使用するケーブルネットワーク、一般的にコンピュータ等で使用するデジタルデータの高速通信を提供するケーブル、またはその他望ましいタイプのケーブルを用いて実現される。

他の実施形態において、ワークステーション４２はラップトップコンピュータ、PDA、パームトップコンピュータ、またはネットワーク機能を有した携帯電話であってもよい。これらの装置を用いてディスク４６に格納されたデータベース中の情報にアクセスしてもよい。

デジタルコピー／プリンター２４、オフィス機器２７、ファクシミリ２８、プリンター３２それぞれに関する情報は、ディスク４６、５４、５８、６４、７０、７６に格納された１以上のデータベースに入れられる。既知のデータベースには、（１）マイクロソフト、IBM、オラクル、サイベースのSQLデータベース、（２）その他のリレーショナルデータベース、（３）非リレーショナルデータベース（例えば、オブジェクティビティ、JYDソフトウェアエンジニアリング、オリエントテクノロジーのオブジェクト指向データベースを含む）などがある。販売、受注処理、会計、請求、カスタマーサービス、マーケティング、生産、エンジニアリング部門は各々自分のデータベースを有しても、１以上のデータベースを共有してもよい。データベースを格納するために使用する各ディスクは、ハードディスクまたは光ディスク等の不揮発メモリである。あるいは、データベースは、固体および／または半導体メモリデバイス等のいかなる記憶デバイスに格納してもよい。例えば、ディスク６４にはマーケティングデータベースを格納し、ディスク５８には生産データベースを格納し、ディスク７０にはエンジニアリングデータベースを格納し、ディスク７６にはカスタマーサービスデータベースを格納してもよい。あるいは、ディスク５４と４６に１以上のデータベースを格納してもよい。

ワークステーション５６、６２、６８、７４、４２は、WAN１０への接続に加えて、監視・診断・制御されるマシン／装置とのセキュアな接続をするために、電話線、ケーブル、ワイヤレスネットワークに接続されていてもよい。また、通信媒体の一つが故障したとき、バックアップとして他の通信媒体を自動的に用いて通信を行う。

本発明の特徴は、「ストアアンドフォワード」モードの通信（例えば、インターネット電子メール、以下単に電子メールとも呼ぶ）、すなわちマシンを診断・制御するためのそのマシンとコンピュータ／監視システムとの間の送信を使用することにある。あるいは、FTPやハイパーテキストトランスファープロトコル（HTTP）のような直接のエンドツーエンドの（例えば、最終目的地とのソケット接続を用いた）接続をする通信モードを用いて、メッセージの送信を実現する。

図２は、図１に例示したデジタルコピー／プリンター２４の機械的構成を示す図である。図２において、１０１はスキャナー用のファンであり、１０２はレーザプリンターで使用されるポリゴンミラーであり、１０３はレーザ（図示せず）からの光をコリメートするために使用するFθレンズである。参照数字１０４はスキャナーからの光を検出するセンサーを指す。参照数字１０５は、スキャナーからの光をセンサー１０４にフォーカスするレンズを指し、参照数字１０６は感光体ドラム１３２上の画像を消去するために用いる消去ランプを指す。チャージングコロナユニット１０７および現像ローラ１０８がある。参照数字１０９はスキャンする文書を照射するためのランプを指し、構成要素１１０、１１１、１１２は光をセンサー１０４に反射するミラーを指す。ドラムミラー１１３は、ポリゴンミラー１０２からの光を感光体ドラム１３２に反射するために設けられている。ファン１１４は、デジタル画像形成装置のチャージングエリアを冷却するために使用する。第１の用紙送りローラ１１５は、第１の給紙カセット１１７から用紙を給紙するために使用する。参照数字１１６はマニュアル給紙テーブルを指す。同様に、第２の給紙ローラ１１８は第２のカセット１１９と併せて使用する。参照数字１２０はリレーローラを指し、１２１はレジストレーションローラを指し、１２２は画像濃度センサーを指し、１２３はトランスファー／セパレーションコロナユニットを指す。参照数字１２４はクリーニングユニットを指し、１２５はバキュームファンを指し、１２６は転送ベルトを指し、１２７はプレッシャーローラを指し、１２８はエグジットローラを指す。ホットローラ１２９は用紙にトナーを定着するために使用され、１３０は排気ファンを指し、メインモータ１３１はデジタルコピー／プリンター２４をドライブするために使用する。

図３は、図２のデジタルコピー／プリンター２４の電子部品を示すブロック図である。CPU１６０は装置のコントローラとして機能するマイクロプロセッサである。ランダムアクセスメモリ（RAM）１６２は、デジタルコピー／プリンター２４の動作パラメータ等の動的に変化する情報を格納する。不揮発メモリ（例えば、リードオンリーメモリ（ROM）１６４またはフラッシュメモリ）は、デジタルコピー／プリンター２４を記述する静的状態データ（例えば、装置のモデル名、モデル番号、シリアル番号、およびデフォルトパラメータ）のみでなく、そのデジタルコピー／プリンターを動作させるプログラムコードを格納している。

マルチポートネットワークインターフェイス１６６が設けられ、デジタルコピー／プリンター２４は少なくとも１つの通信ネットワークを介して外部の装置と通信可能である。参照数字１６８は、電話、ワイヤレス、またはケーブルラインを表し、参照数字１７０はネットワーク１６８とは別のタイプのネットワークを表す。マルチポートネットワークインターフェイスに関するさらに詳細は、図４を参照して説明する。インターフェイスコントローラ１７２はオペレーションパネル１７４をシステムバス１８６に接続するために使用する。オペレーションパネル１７４は、デジタルコピー／プリンター２４の標準的入出力装置を含んでいる。標準的入出力装置とは、例えば、コピーボタンや、コピー枚数、拡大／縮小、濃度等の画像形成装置の動作を制御するためのキーなどである。また、液晶ディスプレイパネルがオペレーションパネル１７４に含まれており、デジタルコピー／プリンター２４のパラメータやメッセージをユーザに表示する。

ローカル接続インターフェイス１７１は、RS232、パラレルプリンターポート、USB、IEEE1394等のローカルポートを介した接続である。ファイヤーワイヤ（IEEE1394）は、Wickelgren,I著「ファイヤーワイヤに関する事実」（IEEESpectrum、1997年4月、Vol.34、Number4、19-25ページ）に記載されている。その内容はすべてここに参照により援用する。エラー検出と再送信を含む「信頼できる」通信プロトコルを使用することが好ましい。

ストレージインターフェイス１７６は、システムバス１８６にストレージ装置を接続する。例えば、ストレージ装置はフラッシュメモリ１７８とディスク１８２を含む。フラッシュメモリ１７８は従来の電気的消去可能プログラマブルリードオンリーメモリ（EEPROM）で代替することができる。ディスク１８２は、ハードディスクドライブ、光ディスクドライブ、および／またはフロッピー（登録商標）ディスクドライブである。接続１８０を介して付加的記憶装置をデジタルコピー／プリンター２４に接続してもよい。フラッシュメモリ１７８は、デジタルコピー／プリンター２４の製品寿命にわたって頻繁には変化しないパラメータを表す準静的状態データを格納するために使用する。このようなパラメータには、例えば、デジタルコピー／プリンターのオプションや設定が含まれる。オプションインターフェイス１８４により、外部インターフェイス等の付加的ハードウェアをデジタルコピー／プリンター２４に接続することができる。クロック／タイマー１８７を用いて時間と日付を常に把握したり、経過時間を測定したりすることができる。

図３は、デジタルコピー／プリンター２４を構成するいろいろなセクションも示している。参照数字２０２はソータを指し、デジタルコピー／プリンター２４の出力をソートするために使用するセンサーおよびアクチュエータを含んでいる。デュプレクサ２００によりデュプレックス動作を実行することができる。デュプレクサ２００は従来のセンサーとアクチュエータを含む。大容量トレイユニット１９８が設けられ、多量の用紙を用紙トレイに保持することができる。デュプレクサ２００と同様に、トレイユニット１９８も従来のセンサーとアクチュエータを含む。

給紙コントローラ１９６を用いて、デジタル画像形成装置の給紙動作を制御することができる。スキャナー１９４を用いて画像をスキャンしてデジタル画像形成装置に取り込むことができる。スキャナー１９４は、光源、ミラー等の従来のスキャンエレメントを含んでいる。また、ホームポジションセンサー等のスキャナーセンサーを用い、スキャナーがホームポジションにいるかどうか判断する。また、ランプサーミスターを用い、スキャンランプが正しく動作することを保証する。プリンター／イメージャ１９２は、デジタル画像形成装置の出力を印刷する。従来のレーザ印刷メカニズム、トナーセンサー、及び画像濃度センサーを有している。フューザ１９０は、高温ローラを用いてトナーを用紙上に溶かす。エグジットセンサと、フューザ１９０がオーバーヒートしないことを保証するサーミスターと、オイルセンサーとを含む。また、オプショナルユニットインターフェイス１８８があり、デジタル画像形成装置の任意的構成要素への接続に使用される。任意的構成要素とは、例えば、自動文書フィーダ、異なるタイプのソータ／コレータ、その他デジタル画像形成装置に付加できる構成要素である。他のエレメントには、その装置の位置を特定することができるGPSなどが含まれる。

図４は複数ポートネットワークインターフェイス１６６の詳細を示す図である。デジタル画像形成装置は以下のインターフェイスを介して外部装置と通信することができる：トークンリングインターフェイス２２０、ケーブル回線で高速接続を提供するケーブルモデムユニット２２２、電話ライン１６８Aに接続された従来の電話インターフェイス２２４、ワイヤレスインターフェイス２２８、LAN１７０に接続されたイーサネット（登録商標）インターフェイス２３０。その他のインターフェイスとしてデジタル加入者ライン（DSL）（オリジナルDSL、コンセントリックDSL、アシンメトリックDSL）もあるが、これに限定されない。単一の装置でローカルエリアネットワークと電話ラインの両方に接続できる製品がインテルから商業的に入手可能であり、Intel Pro 10/100+Modemとして知られている。

CPU、その他のマイクロプロセッサ、または回路が監視プロセスを実行し、デジタル画像形成装置の各センサーの状態を監視する。シーケンスプロセスを用いて、デジタル画像形成装置を制御し動作させるための命令コードを実行する。また、（１）デジタル画像形成装置の動作全般を制御するために実行される中央システム制御プロセスと、（２）デジタル画像形成装置に接続された外部装置との信頼できる通信を確保するために使用する通信プロセスがある。システム制御プロセスは、静的メモリ（例えば、図３に示したROM１６４）、準静的メモリ（例えば、フラッシュメモリ１７８やディスク１８２）、動的メモリ（例えば、RAM１６２、フラッシュメモリ１７８、ディスク１８２等の揮発性または不揮発性メモリ）のデータ記憶を監視および制御する。また、静的メモリはROM１６４以外のデバイスであってもよく、例えばフラッシュメモリ１７８やディスク１８２のいずれかを含む不揮発メモリであってもよい。

上記の通り、デジタル画像形成装置について詳細を説明したが、本発明は他のビジネスオフィスマシンや装置にも同様に適用可能である。他のビジネスオフィスマシンや装置とは、例えば、アナログコピー、ファクシミリ、スキャナー、プリンター、ファクシミリサーバ、プロジェクター、会議機器、シュレッダー、その他のビジネスオフィスマシン、ビジネスオフィスアプライアンス、その他の機器（例えば、電子レンジ、VCR、DVD、デジタルカメラ、携帯電話、パームトップコンピュータ）などである。また、本発明には、ストアアンドフォワードまたはダイレクト接続ベースの通信を用いて動作するその他の装置も含む。そのような装置には、（ガス、水道、電気のメータシステムを含む）メータシステム、自動販売機、動作中の監視や遠隔診断が必要となるようなその他の機械的装置（例えば、自動車、オートバイ、洗濯機、乾燥機）などが含まれる。また、特定目的のマシンやコンピュータの監視に加え、本発明は汎用コンピュータの監視、制御、診断に使用でき、その場合は、その汎用コンピュータが監視及び／または制御される装置となる。

図５は、本発明の別のシステムのシステム図であり、異なる装置やサブシステムがWAN１０に接続されている。しかし、これらの装置やサブシステムの各々は、本発明の一部として必ずしも必須のものではない。図５に示した各コンポーネントやサブシステムは、個々に本発明の一部である。さらに、図１に示した構成要素を図５に示したWAN１０に接続してもよい。図５には、イントラネット２６０−１に接続されたファイヤーウォール５０−１が示されている。イントラネット２６０−１に接続されたサービスマシン２５４は、データベースフォーマットで格納されたデータ２５６を含むか、そのデータ２５６に接続されている。データ２５６には、被監視装置の履歴、性能、故障情報や、その他の動作、故障、設定に関する統計情報等、または被監視装置にどのコンポーネントや任意的機器が含まれているか等を示す構成情報が含まれている。サービスマシン２５４は、被監視装置にデータを送信するように要求し、またはその被監視装置にリモート制御および／または診断テストを実行することを要求する装置またはコンピュータである。サービスマシン２５４は、いかなるタイプの装置でもよく、好ましくは汎用コンピュータなどのコンピュータ化された装置を用いて実施される。また、サービスマシン２５４は、請求、会計、サービス処理、パーツトラッキング、およびレポートを含む様々なデータベースを有するネットワーク上の複数のコンピュータにより構成される。

図５に示した他のサブシステムには、ファイヤーウォール５０-２、イントラネット２６０-２、それに接続されたプリンター２６２が含まれる。このサブシステムにおいて、プリンター２６２（同様にコピー機２８６）による電子メッセージを送受信する機能は、（１）回路、（２）マイクロプロセッサ、（３）プリンター２６２に含まれた、または搭載されたその他のタイプのハードウェアにより（すなわち、別の汎用コンピュータを使用せずに）実行される。

別のタイプのサブシステムには、インターネットサービスプロバイダー２６４の使用を含む。そのインターネットサービスプロバイダー２６４は、いかなるタイプのインターネットサービスプロバイダー（ISP）でもよく、アメリカオンライン、イーサリンク、ニフティサーブ等の既知の事業会社を含む。このサブシステムにおいて、コンピュータ２６６はデジタルまたはアナログモデム（例えば、電話ラインモデム、ケーブルモデム、非対称デジタル加入者ライン（ADSL）で使用されるモデム、フレームリレー通信を使用するモデム、無線周波数モデム等のワイヤレスモデム、光ファイバーモデム、赤外線を使用する装置）を介してISP２６４に接続されている。さらに、ビジネスオフィス装置２６８はコンピュータ２６６に接続されている。ビジネスオフィス装置２６８（または図５に示したその他の装置）ではなく、異なるタイプのマシンを監視または制御してもよい。異なるタイプのマシンとは、例えば、デジタルコピー、すべてのタイプの機器、セキュリティシステム、ユーティリティメータ、（例えば、電気、水道、ガスのユーティリティメータ）、その他のここで説明する装置を含む。

図５には、ネットワーク２７４に接続されたファイヤーウォール５０-３も示されている。ネットワーク２７４はいかなるタイプのコンピュータネットワークでもよい（例えば、イーサネット（登録商標）またはトークンリングネットワーク）。ネットワークを制御するために使用するネットワークソフトウェアには、ノベルまたはマイクロソフトから商業的に入手可能なソフトウェア等を含むネットワークソフトウェアが含まれる。ネットワーク２７４は、必要に応じてイントラネットであってもよい。ネットワーク２７４に接続されたコンピュータ２７２は、ビジネスオフィス装置２７８から情報を取得し、ネットワークに接続されたいろいろなマシンで発生した問題を示すレポートや、ネットワーク２７４に接続された装置の月間使用レポート等を生成するために使用される。本実施形態において、コンピュータ２７６はビジネスオフィス装置２７８とネットワーク２７４の間に接続されている。このコンピュータはネットワークからの通信を受信し、適当なコマンド、データ、またはその他の情報をビジネスオフィス装置２７８に転送する。

ビジネスオフィス装置２７８とコンピュータ２７６の間の通信は、有線ベースまたはワイヤレス方式を使用してなされる。その方式には、例えば、ラジオ周波数接続、電気的接続、光接続（例えば、赤外線接続や光ファイバー接続）等が含まれるが、これに限定されない。同様に、図５に示したいろいろなネットワークやイントラネットは、所望の方式でよく、例えば、無線周波数ネットワーク等のワイヤレスネットワーク方式でもよい。ここに説明したワイヤレス通信は、拡散コードとブルートゥース仕様書（ウェブサイトwww.bluetooth.comで入手可能である）に開示された周波数ホッピングワイヤレス技術等を用いる技術を含む拡散スペクトルを用いて行うことができる。このブルートゥース仕様書はここに参照により援用する。

図５に示した他のサブシステムには、ファイヤーウォール５０-４、イントラネット２６０-４、それに接続されたコンピュータ２８２、ビジネスオフィス機器２８５、コピー機２８６が含まれる。コンピュータ２８２を用いて、レポートを生成し、診断または制御プロシージャを要求する。これらの診断および制御プロシージャは、ビジネスオフィス機器２８５、コピー機２８６、または図５に示したその他の装置、またはそれらとともに使用する装置に対して実行してもよい。図５は複数のファイヤーウォールを示しているが、ファイヤーウォールは好ましいが任意的な機器であり、それゆえ、本発明はファイヤーウォールなしで使用することもできる。ネットワークされた機器の監視および制御のために、コンピュータ２５４ではなくどのコンピュータ（２６６、２７２、または２８２）を使用することもできる。また、いずれかのコンピュータがコンピュータ２５４にアクセスして、必要な装置情報や使用情報を、ウェブを介して読み出してもよい。

図６Aは、典型的な電子メール交換システムに接続された装置／機器３００を示しており、コンポーネント３０２、３０４、３０６、３０８、３１０、３１２、３１４、３１６、３１８を含んでいる。このシステムは従来例であり、上記引用文献（Stevens）の図２８．１に基づき作成した。コンピュータインターフェイス３０２は、ここに説明したいかなるアプリケーションユニットや装置／機器３００ともインターフェイスする。図６Aでは装置／機器３００は送信元であるが、図６Aの送信と受信の機能は逆にしてもよい。さらにまた、もし望ましければ、ユーザは装置／機器３００とインターフェイスする必要は必ずしもない。コンピュータインターフェイス３０２はメールエージェント３０４とインターラクトする。Unix（登録商標）用のメールエージェントとしては、MH、バークレーメール、Ｅｌｍ、Mushなどが人気がある。ウィンドウズ（登録商標）ファミリーのオペレーティングシステム用のメールエージェントには、マイクロソフトアウトルックとマイクロソフトアウトルックエクスプレスがある。コンピュータインターフェイス３０２の要求により、メールエージェント３０４は送信する電子メールメッセージを作成し、必要であれば、送信するこれらのメッセージをキュー３０６に入れる。送信すべきメールはメッセージトランスファーエージェント（MTA）３０８に送られる。Unix（登録商標）システム用の一般的なMTAはSendmailである。メッセージトランスファーエージェント３０８と３１２は、一般的には、TCP/IP接続３１０を用いて通信する。特に、メッセージトランスファーエージェント３０８と３１２の間の通信は、ネットワーク（例えば、WANまたはLAN）の大きさによらずに生じる。さらに、メッセージトランスファーエージェント３０８と３１２はどの通信プロトコルを使用してもよい。本発明の一実施形態において、図６Aの構成要素３０２と３０４は、アプリケーションユニットの使用を監視するライブラリにある。

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

送信メールエージェント３０４は、この「ストアアンドフォワード」プロセスにより、メール受信者との直接接続が確立されるまで待つ必要が無くなる。ネットワーク遅延により、通信にはかなりの時間を要し、その間アプリケーションは応答しない。このような応答の遅延は、アプリケーションユニットのユーザには一般に受け入れがたいものである。電子メールをストアアンドフォワードプロセスとして使用することにより、通信が失敗した後一定期間（例えば３日間）、自動的に再送を試みることができる。別の実施形態において、アプリケーションは、１以上の別のスレッドに通信要求を送ることにより、待たなくて済む。これらのスレッドは、受信端末３１８との通信を制御することができ、一方、アプリケーションは、ユーザインターフェイスに再度応答をすることができる。さらに別の実施形態において、ユーザが通信を完了させたいと思っている場合、受信端末との直接通信を使用する。このような直接通信には、送受信端末間のファイヤーウォールによりブロックされないプロトコルであればいかなるものを使用することもできる。そのようなプロトコルの例としては、Telnet、ファイルトランスファープロトコル（FTP）、ハイパーテキストトランスファープロトコル（HTTP）等がある。

インターネット等のパブリックWANは、一般的に安全であるとは言えない。それゆえ、メッセージを秘匿したいときは、パブリックWAN（および複数企業のプライベートWAN）を介して送信するメッセージは暗号化する。暗号化メカニズムは既知であり、商業的に入手可能であり、本発明とともに使用することができる。例えば、C++ライブラリ関数crypt()をサンマイクロシステムズから入手して、Unix（登録商標）オペレーティングシステムで使用することができる。暗号化および復号ソフトウェアパッケージが知られており、商業的に入手可能であり、本発明で使用することができる。パッケージの例として、PGPコーポレーションが出しているPGPがある。

図６Aの一般的構造の替わりとして、コンピュータインターフェイス３０２、メールエージェント３０４、メールキュー３０６、メッセージトランスファーエージェント３０８として機能する単一のコンピュータを使ってもよい。図６Bに示したように、装置／機器３００はコンピュータ３０１に接続されており、そのコンピュータ３０１はメッセージトランスファーエージェント３０８を含む。

さらに別の構成を図６Cに示したが、この構成ではメッセージトランスファーエージェント３０８が装置／機器３００の一部となっている。さらに、メッセージトランスファーエージェント３０８はメッセージトランスファーエージェント３１２とTCP/IP接続３１０により接続されている。図６Cの実施形態において、装置／機器３００は、電子メール機能を有するTCP/IP接続３１０に直接接続されている。図６Cの実施形態の使用には、（例えば、RFC２３０５（インターネットメールを用いた単一モードのファクシミリ）に規定された）電子メール機能を有するファクシミリを装置／機器３００として使用することが含まれる。

図６Dに示したシステムは、装置／機器３００が自分では電子メールを直接受信する能力を有していないが、メッセージトランスファーエージェント３０８とメールボックス３１４を含むメールサーバ／POP3サーバとの接続３１０を有し、装置／機器３００がPOP3プロトコルを使用してメールサーバから受信メールを読み出す。

図７は、メール転送の別の実施形態を示す図であり、前に参照した引用文献（Stevens）の図２８．３に基づき作成したものである。図７は、リレーシステムを各端に有する電子メールシステムを示す。図７の構成により、組織の一システムをメールハブとして機能させることができる。図７において、２つのメールエージェント３０４と３１６の間に４つのMTAが接続されている。その４つのMTAは、ローカルMTA３２２A、リレーMTA３２８A、リレーMTA３２８B、およびローカルMTA３２２Dである。メールメッセージで最も一般的なプロトコルはSMTP（シンプルメールトランスファープロトコル）であり、このプロトコルを本発明に使用することができるが、他のメールプロトコルを使用することもできる。図７において、参照数字３２０はコンピュータインターフェイス３０２、メールエージェント３０４、ローカルMTA３２２Aを含む送信ホストを指す。装置／機器３００はこの送信ホスト３２０に接続されるか、あるいはその中に含まれている。他の場合として、装置／機器３００とホスト３２０は、ホスト機能が装置／機器３００に組み込まれた１つのマシンであってもよい。他のローカルMTA３２２B、３２２C、３２２E、３２２Fが含まれていてもよい。送受信メールは、リレーMTA３２８Aのメールキュー３０６Bの待ち行列に入れられる。メッセージはTCP/IP接続３１０（例えば、インターネット接続またはその他のタイプのネットワークにわたる接続）により転送される。

送信メッセージはリレーMTA３２８Bにより受信され、必要に応じてメールキュー３０６Cに格納される。メールはその後受信ホスト３４２のローカルMTA３２２Dに転送される。メールは１つ以上のユーザメールボックス３１４に入れられ、その後メールエージェント３１６に転送され、最後に端末３１８のユーザに転送される。必要に応じて、メールは、ユーザによる関与無しに端末に直接転送される。

図５のコンピュータ２６６と２７６を含めて、本発明で使用される様々なコンピュータは、図８に示したようなものである。さらに、本発明で使用される他のコンピュータは、図８に示したコンピュータと同様なものであり、必要に応じて、図５に示したサービスマシン２５４、コンピュータ２７２、コンピュータ２８２を含んでもよい。しかし、これらのコンピュータの各々において、図８に示したすべての構成要素が必要なわけではない。

図８において、コンピュータ３６０はCPU３６２を含む。このCPU３６２は、インテル、AMD、モトローラ、日立、NEC等の会社から商業的に入手可能なマイクロプロセッサを含む、いかなるタイプのプロセッサであってもよい。RAM３６４等のワーキングメモリと、ワイヤレスデバイス３６８と通信するワイヤレスインターフェイス３６６がある。インターフェイス３６６とデバイス３６８の間の通信には、いかなる無線媒体（例えば、ラジオ波や光波）を使用してもよい。ラジオ波は、符号分割多重アクセス（CDMA）通信等の拡散スペクトル技術や、ブルートゥース仕様書に開示されている周波数ホッピング技術を用いてもよい。

コンピュータ３６０はROM３７０とフラッシュメモリ３７１とを含むが、他のいかなるタイプの不揮発性メモリ（例えば、消去可能プログラマブルROM、またはEEPROM）をフラッシュメモリ３７１に加え、またはそれの替わりに使用してもよい。入力コントローラ３７２にはキーボード３７４およびマウス３７６が接続されている。シリアルインターフェイス３７８があり、シリアルデバイス３８０が接続されている。また、パラレルインターフェイス３８２はパラレルデバイス３８４に接続されており、ユニバーサルシリアルバス（USB）インターフェイス３８６はユニバーサルシリアルバスデバイス３８８に接続されており、またIEEE1394デバイス４００（一般に、ファイヤーワイヤデバイスと呼ばれる）があり、IEEE1394インターフェイス３９８に接続されている。システムバス３９０にはコンピュータ３６０のいろいろな構成要素を接続する。ディスクコントローラ３９６には、フレキシブルディスクドライブ３９４とハードディスクドライブ３９２が接続されている。コンピュータ３６０は、通信コントローラ４０６により、ネットワーク４０４を介して、（例えば、電子メールメッセージを送信することにより）他のコンピュータと通信することができる。I/O（入出力）コントローラ４０８には、例えば、SCSI（Small Computer System Interface）バスを用いてプリンター４１０とハードディスク４１２が接続されている。CRT（陰極線管）４１４が接続されたディスプレイコントローラ４１６もある。ディスプレイはいかなるタイプでもよく、例えば液晶ディスプレイ、発光ダイオードディスプレイ、プラズマディスプレイ等であってもよい。

図９は、本発明の一実施形態によるシステム９００の全体を示す概略図である。システム９００は、レーザプリンター９０８、スキャナー９１０、ネットワーク装置９１２、多機能プリンター９１４など複数の装置を含んでおり、これらはすべてネットワーク１００に接続されている。これら複数の装置は一般的にここで「被監視装置」と呼ぶ。システム９００には、ネットワーク１００に接続され被監視装置９０８、９１０、９１２、９１４を監視および制御するワークステーション／監視システム９０２（以下、コントローラ９０２と呼ぶ）も含まれている。各被監視装置９０８、９１０、９１２、９１４には一意的なアドレスが与えられている。例えば、装置に割り当てられたIPアドレスはその装置の一意的なアドレスとして機能する。このように、コントローラ９０２のユーザは、それぞれの被監視装置に割り当てられた一意的なIPアドレスにアクセスすることにより、各被監視装置９０８-９１４にアクセスすることができる。当然のことながら、本発明においては、ＩＰアドレスを用いてネットワークに接続された装置を一意的に特定する必要は必ずしもない。

コントローラ９０２は、被監視装置９０８-９１４の１つにアクセスする際、SNMP及び／またはHTTPプロトコルでいろいろな情報を取得する。情報の例としては、トラブルシューティング情報を含む、装置の動作状態に関する詳細な情報がある。例えば、コントローラ９０２は、ある装置にアクセスし、そのジャム位置を取得し、そのジャムを解消するためにその装置の管理者にメッセージを送信する。レーザプリンター９０８の動作状態／詳細情報には、トナーレベル、ペーパージャムの表示、プリンタートレイにある印刷用紙の枚数等の詳細情報が含まれる。

当然のことながら、コントローラ９０２はネットワーク１００と物理的に接続されていても、ワイヤレスで結合されていてもよい。例えば、パーソナルデジタルアシスタント（PDA）９２０やラップトップコンピュータ９２２は、ネットワーク１００にワイヤレスに結合しているように示されているが、コントローラ９０２として使用することもできる。アクセスポイント９２４は、ネットワーク１００とPDA９２２またはラップトップコンピュータ９２２との間のワイヤレス通信を可能とするインターフェイスとして機能する。ここからは、コントローラ９０２がネットワークに接続されている被監視装置の状態を制御および監視するという仮定の下に本発明を説明する。

ネットワーク１００により、コントローラ９０２と被監視装置９０８−９１４の間の通信が容易になり、被監視装置の監視と制御が可能となる。ネットワークに接続された装置の数は、本発明を限定するものではない。当然のことながら、ネットワーク１００はローカルエリアネットワーク（LAN）またはワイドエリアネットワーク（WAN）である。同様に、被監視装置９０８、９１０、９１２、９１４は例として示されたものである。

コントローラ９０２は、記憶装置９０４とデータベース９０６に通信可能に結合している。記憶装置９０４には、ハードディスクドライブ、光ディスクドライブ、及び／または外部ディスクドライブが含まれる。データベース９０６は記憶装置９０４に通信可能にリンクされており、記憶装置９０４に格納されたデータを容易に検索し読み出すためのリレーショナルデータベースマネージメントシステム（RDBMS）を含んでいる。記憶装置９０４は、好ましくは、各被監視装置９０８−９１４に関する詳細情報を格納している。例えば、レーザプリンター９０８のメーカー、モデル、いろいろな機能およびトラブルシューティングの詳細等の詳細情報が記憶装置９０４に格納されている。また、所定の基準値と比較したレーザプリンターの動作状態に関する偏差値を記憶装置９０４に格納してもよい。データベース９０６と記憶装置９０４はコントローラに通信可能に結合していると説明したが、当然のことながら、コントローラ９０２が記憶装置と一体に構成され、データベースがそれにインストールされていてもよい。そのような場合、記憶装置９０６とデータベース９０４はコントローラ９０２に内蔵されているものとして示す。

コントローラ９０２は、複数の装置９０８−９１４の監視と制御を容易にするために、ソフトウェアでインストールされてもよい。コントローラ９０２は複数の装置９０８−９１４を監視するためにシンプルネットワークマネージメントプロトコル（SNMP）、ファイルトランスファープロトコル（FTP）、およびハイパーテキストトランスファープロトコル（HTTP）を使用する。その複数の装置９０８−９１４から受信したデータは９５０で示したようにASN.1バイナリーフォーマット、HTMLフォーマット、またはXMLフォーマットの形式で表される。

図９には画像化装置のみを示したが、監視装置と複数の被監視装置の間で情報を通信するためのネットワークには、機器とメータがネットワークに接続されたホームネットワークを含めてもよい。当然のことながら、コントローラ／ワークステーション９０２により収集されたデータは、さらに処理するために、電子メール、FTP、その他の通信プロトコル手段を介してリモート装置に送信される。ワークステーション９０２、PDA９２０、またはラップトップコンピュータ９２２は、データを収集し、それを格納または通信プロトコルを使って送信するコントローラでもよく、そのコントローラはネットワークに接続されているどの装置であってもよい。どのネットワーク装置（例えば、プリンター）にも、ネットワーク中の他の装置の状態を監視し、収集したデータを格納し、および／または収集したデータを他の通信プロトコル手段（例えば、電子メール、FTP）を通じて送信することができる監視システムの機能を持たせることができる。

監視システムのアーキテクチャ
図１０は、本発明の一実施形態による、リモート装置に関連したデータの監視に使用される監視システム１０００（および、関連するインターフェイス機能）を示す。監視システム１０００は、ソフトウェアモジュールMonitorService１００４を含む。このソフトウェアモジュールMonitorService１００４は、NTやウィンドウズ（登録商標）２０００のサービスやUnix（登録商標）のデーモン等のコンピュータ常駐プログラムである。好ましい実施形態において、監視システムはオブジェクト指向ソフトウェア環境を用いて実装されている。また、Timer（タイマー）モジュール１００２とMonitor（モニター）モジュール１００６が監視システム１０００に含まれている。タイマーモジュール１００２とMonitorモジュール１００６は、MonitorService（モニターサービス）モジュール１００４により呼び出されるライブラリ関数である。例えば、MonitorService１００４は、InitTimer１００３関数を呼び出してTimerモジュール１００２を初期化し、obtainDelayAndAction(int&,int&)関数を呼び出して遅延および動作パラメータを取得する。図１３に示したように、init()関数は、MonitorServiceモジュール１００４によっても呼び出され、Monitorモジュール１００６のいろいろなモジュールを初期化する。init()関数を用いて、既知の方法で収集されたIPアドレス、パラメータ名、パラメータ値を含む外部ソースを通じて、被監視装置に割り当てられたIPアドレスとパラメータ値を取得することができる。Monitorモジュール１００６は、サポートデータベース１０２４と監視データベース１０１４に通信可能に結合される。これらのデータベースは後でより詳しく説明する。

一旦被監視装置のIPアドレスを取得すると、監視システムは、そのIPアドレスを用いて被監視装置にコンタクトして製造者（ベンダー）およびモデル等の情報を取得する。監視システム１０００により実行される関数には以下の関数がある。

void initTimer(void)
この関数はタイマーを初期化する。特に、この関数がトリガーになって、Timerオブジェクトがレジストリからタイミング情報を入手する。

void obtainDelayAndAction(int & out_nDelay, int & out_nAction)
この関数は、Sleep関数（１０００倍する必要がある）と動作インジケータのために、秒単位の遅延時間を返す。動作インジケータは以下のように定義されている：０＝イベントチェック中；１＝被監視データを送信中；２＝データを監視してローカルデータベースに格納中。

int init(void)
この関数はMonitorを初期化する。また、監視される装置を生成する。戻り値はエラーコードであり、ゼロはエラーなしを表すと決められている。

int monitorStatus(int in_nAction)
この関数はプリセット情報を監視する。戻り値はエラーコードであり、ゼロはエラーなしを表すと決められている。

int end(void)
この関数はオブジェクトをクローズする前にMonitorをクリーンアップする。戻り値はエラーコードであり、ゼロはエラーなしを表すと決められている。

モニターモジュール
図１１は、Monitor（モニター）モジュール１００６の構造の詳細を示し、いろいろなソフトウェアサブモジュールとサブモジュール間の呼び出し関数とを含んでいる。Monitorモジュール１００６は、多数のモジュールにより使用されるクラスを含むCommon（コモン）モジュール１１０１、及び他のサブモジュール（DeviceODCBモジュール１１０４、Device（デバイス）モジュール１１１０、HWaccess（HWアクセス）モジュール１１１６）を管理するMonitorManager（モニターマネージャ）モジュール１１０２とを含み、図１０に示したようにインターフェイス機能により規定されたタスクを完了する。具体的に、DeviceODBC（デバイスODBC）モジュール１１０４は、標準インターフェイスを通じて外部装置情報にアクセスするために、アクセスされる。HWaccessモジュール１１１６は、複数の通信プロトコル（例えば、HTTP、SNMP、FTP）のうちから選択された通信プロトコルを用いて、被監視装置からベンダー、モデル、一意的ID、ステータス情報を取得する。各Monitorソフトウェアモジュールは、以下により詳細に説明する。

上で説明したMonitorモジュール間のインターフェイスの一部を以下に説明する。例えば、モジュールによっては、便利なフォーマットで情報を取得するために、「init」その他の関数が必要である。

void updateConfig(std::map<infoType, std::string> &)
この関数を呼ぶ前に、呼んでいる関数は、obtain関数がnullストリングを返した場合、ベンダーとモデルのエントリーを置き換えないことが好ましい。この関数は、DeviceODBC１１０４の装置情報データベースのカレントレコードを更新する。この関数は、下記のObtainConfigが最初に呼ばれた時に最も効率的である。この関数は、最初に、IPアドレスがDeviceODBC１１０４と同じかどうかをチェックする。IPアドレスフィールドが同じでない場合、正しいIPアドレスのレコードをデータベースから取得する。そして、他のフィールドがコピーされ、レコードが更新される。

bool obtainConfig(std::map<infoType, std::string> &, std::map<std::string, std::vector<SParameter>> &)
この関数は、DeviceODBC１１０４から所与のフォーマットの装置情報のマップと、プロトコルとそれに関連するパラメータのマップとを取得する。この関数は返すデータがあれば真を返し、データがもうなければ偽を返す。

bool saveStatus(std::map<infoType, std::string> &)
この関数は、ステータス情報をDeviceODBC１１０４に保存する。保存が成功した場合、真を返し、失敗した場合、偽を返す。

CDevice * createDevice(const std::string & in_sIP, CHWaccess & in_HWaccess, std::map<std::string, std::vector<SParameter>> & in_ProtocolParameters)
この関数は、in_sIPとin_ProtocolParametersに基づき装置を生成する。生成された装置は、CHWaccessを通じてハードウェアに接続される。装置を生成できないとき、０を返す。したがって、呼んでいるオブジェクトは、リターンオブジェクトポインタが０かどうかをチェックしなければならない。

bool canAccessHW(void)
この関数は、ハードウェアがネットワークを通じてアクセスできる時に真を返し、そうでない時に偽を返す。

bool getVendor(std::string & out_sVendor)
この関数はベンダー名を返す。その装置がシステムによってサポートされていないが、プロトコルの１つを通してアクセス可能なときは、ストリングに「GENERIC」と表示される。プロセス中でエラーを検出すると、本関数はnullストリングと偽を返す。そうでない時は真を返す。

bool getModel(std::string & out_sModel)
この関数は装置のモデルを取得する。モデルを取得すると、関数は真を返す。プロセス中でエラーを検出すると、本関数はnullストリングと偽を返す。

bool getUniqueID(std::string & out_sUniqueID)
この関数は装置の一意的IDを返す。一意的IDを取得すると、関数は真を返す。プロセス中でエラーを検出すると、本関数はnullストリングと偽を返す。

bool obtainStatus(map<infoType, std::string> & out_StatusMap)
この関数は状態マップを返す。本関数は、状態が返されたとき真を返し、状態を取得できなかったとき偽を返す。この関数はHWaccessとDeviceモジュールでは異なるマップを返すことに注意を要する。Deviceモジュールでは、イベントステータス情報はHWaccessから返されたマップに付加され、クリアされる。

enum
checkEventStatus(void)
この関数はネットワーク装置のイベントを取得するトリガーとして機能する。enumタイプと値はクラスで定義しなければならない。enum値は値eNoEventSinceClearAndNoEventDetected、eNoEventSinceClearAndEventDetected、eEventSinceClearAndNoEventDetected、及びeEventSinceClearAndEventDetectedを含まねばならない。

bool
obtainEventStatus(std::map<infoType, std:: string> &
out_EventStatusMap)
この関数はイベントステータス情報を取得する。本関数は、状態が返されたとき真を返し、状態を取得できなかったとき偽を返す。

void clearEventStatus(void)
この関数は最後のobtainStatusまたはclearEventStatusのファンクションコール以降に集積されたイベントステータスをクリアする。

void initBegin(void)
この関数は、HWaccessを通じて初期化プロセスを開始し、具体的にはソフトウェアデバイスオブジェクトを生成する初期化プロセスを生成する。

void initEnd(void)
この関数はHWaccessを通じて初期化プロセスを終了させるが、これはデバイスオブジェクトの生成が終了することを示す。

bool canAccessIP(const std::string & in_sIP, std::map<std::string, std::vector<SParameter>> & in_ProtocolParameters)
この関数は、IPアドレスで装置にアクセスできるとき真を返し、そうでないとき偽を返す。

bool obtainVendor(std::string & out_sVendor,
std::map<std::string, std::vector<SParameter>> & inOut_ProtocolParameters, const std::string & in_sIP)
この関数はベンダーを取得する。この関数は、正常に動作したとき真を返し、そうでなければ空のストリングとともに偽を返す。このファンクションコールの間、プロトコルが調べられ、特定のプロトコルがステータス監視に使用できないとき、そのプロトコルはinOut_ProtocolParametersから削除される。

bool obtainModel(std::string & out_sModelName, std::map<std::string, std::vector<SParameter>> & inOut_ProtocolParameters, const std::string & in_sIP)
この関数はモデル名を取得する。この関数は、正常に動作したとき真を返し、そうでなければ空のストリングとともに偽を返す。このファンクションコールの間、プロトコルが調べられ、特定のプロトコルがステータス監視に使用できないとき、そのプロトコルはinOut_ProtocolParametersから削除される。

bool obtainUniqueID(std::string & out_sUniqueID, std::map<std::string, std::vector<SParameter>> & inOut_ProtocolParameters, const std::string & in_sIP)
この関数は一意的IDを取得する。この関数は、正常に動作したとき真を返し、そうでなければ空のストリングとともに偽を返す。このファンクションコールの間、プロトコルが調べられ、特定のプロトコルがステータス監視に使用できないとき、そのプロトコルはinOut_ProtocolParametersから削除される。

EerrorCode obtainEventStatus(std::map<infoType, std::string> & out_StatusMap, const std::string & in_sIP, std::map<std::string, std::vector<SParameter>> & in_ProtocolParameters)
この関数はイベントステータスを取得する。ErrorCodeは後で定義する。

bool obtainStatus(std::map<infoType, std::string> & out_StatusMap, const std::string & in_sIP, const std::string & in_sVendor, const std::string & in_sModel, std::map<std::string, std::vector<SParameter>> & in_ProtocolParameters)
この関数は装置のステータスを取得する。この関数は、正常に動作したときは真を返し、そうでないときは空のマップとともに偽を返す。

図１２は、図１１に示したように、HWaccessモジュール１１１６により受信されたキー値と関連する値の読み出しの情報を交換するために、HWaccessモジュール１１１６により使用されるデータ構造を示す図である。例えば、図１２に示したように、SKeyValueInfoデータ構造は、所与のウェブページ内の（m_infoType１２０２に対応する）特定の情報タイプに対応する情報をいかに取得するかを決定するために使用される。一般に、多数のベンダーは、ベンダー特有の識別子と用語を使用して、それぞれのウェブページに表示された被監視装置に関するキー情報を特定する。例えば、プリンター装置により印刷されるページ数を決定するために、あるベンダーは「Page Count」を使用し、他のベンダーは「Total Sheet Delivered」を使用する。本発明の特徴は、ベンダーごとの違いを克服し、それにより装置特有の情報を識別する標準化され統一的方法を提供し、データ構造/SKeyValueInfo構造１２００を使用することにより、その情報に対応する値を抽出することである。SKeyValueInfoデータ構造１２００は公開された属性を含んでいる。

SKeyValueInfoは、データストリングまたはキーストリングの形式で被監視装置から受信した情報から、値情報を特定するために生成されたデータ構造である。SKeyValueInfoは複数のフィールドを含み、各フィールドは図１２に示した情報により表される。SKeyValueInfo構造１２００は、ストリングキーを表すm_sKeyフィールド１２０４と、好ましくは値情報の位置を特定できるストリング中の位置の数を示すタグベースの値であるm_nPositionフィールド１２０６と、m_nInLinePositionフィールド１２１２とを含む。例えば、プリンター装置のPage Countは、監視することを前提として、キーワードに続く第２の位置に見つかる。m_sType１２０８は、被監視装置の表示されたウェブページから読み出すことができる情報のタイプを表す。

例えば、被監視装置のモデル名がキー（製品名）の同じデータライン内に見つかった時、m_nPositionフィールドは「０」である。m_sDelimitor１２１０は、そのキーと関連する値を抽出するために使用される特定のデリミターを示す。SKeyValueInfoデータ構造は、HTMLフォーマットで被監視装置から受信した情報から値情報をいかに抽出するかを示す。

図１３は、図１０に示した、Monitorモジュール１００６の呼び出しシーケンスを説明するinit()関数のシーケンスを示す。MonitorManager１１０２は、HWaccessモジュール１１１６を初期化して初期化関数を開始する。そして、MonitorManager１１０２は被監視装置に関する情報を取得し、被監視装置に割り当てられたIPアドレスを用いてその被監視装置と通信する。MonitorManager１１０２は、DeviceODBC１１０４にアクセスし被監視装置の設定情報を取得する。MonitorManager１１０２に返される設定情報は、例えば、被監視装置のIPアドレス、各プロトコルのパラメータ名とそれに関連する値、被監視装置のベンダー／製造者及びモデル情報が含む。一旦IPアドレスを取得すると、MonitorManager１１０２は、各プロトコルについてそのIPアドレス、パラメータ名、それに関連する値を設定し、図３５のCDeviceFactoryクラス１３０２を通じてDeviceモジュール１１１０のクラス構造に基づきソフトウェアオブジェクトを生成する。デバイスソフトウェアオブジェクトが正常に生成されると、HWaccessモジュール１１１６を用いて、被監視装置からベンダー、モデル、一意的IDを取得し、生成されたデバイスソフトウェアオブジェクトに格納する。

一旦デバイスソフトウェアオブジェクトからベンダー、モデル情報、一意的IDを取得すると、MonitorManager１１０２は被監視装置から受信した情報でデータベース（例えば、DeviceODBC１１０４）を更新する。図１３には１つの装置を示したが、obtainConfigからupdateConfigまでのステップを繰り返し、外部ソースで指示された装置すべてをカバーする。また、図２３、２４、２５、２６に示した各プロトコルが初期化される。図２４、２５、２６に示したODBCに対応するデータベーステーブルにアクセスし、アクセスされた装置からのステータス情報の収集が速くなるように、アクセスされた装置の必要情報を外部記憶から内部データ構造に転送する。

図１４は、図１１に示した、MonitorManagerモジュール１１０２による被監視装置のステータスを決定するためのステータス監視機能のシーケンスを示す。DeviceからHWaccessにobtainStatus関数が発行されると、CHWaccessクラスは、以下に説明するように、異なるパラメータを用いて、抽象型クラスを通じて図２３、２４、２５、２６に示した各プロトコルに対してobtainStatus関数コールを順次発行する。各プロトコルモジュールは被監視装置からステータス情報を抽出するのに必要な情報をすでにキャッシュしている。その被監視装置は、図１３に示した初期化時にすでにアクセスされている。それゆえ、ステータス情報は、ステータス監視の際に外部ソースにアクセスすることなく、被監視装置から素早く抽出することができる。このプロセスは、図１５に示したベクトルに格納されたすべての被監視装置について繰り返される。

図１５を参照して、ベクトル１５００が示されており、図１３と１４に示されたように、図３５のCDeviceFactory１３０２により生成され、MonitorManager１１０２により使用される装置を参照している。MonitorManager１１０２は、例えば、図３５のCDeviceFactory１３０２により生成されたCDeviceオブジェクト１５０２へのポインタ、CDeviceオブジェクト１５０４へのポインタ等のデバイスポインタをベクトルに格納している。ベクトルシーケンスが繰り返され、被監視装置のステータスを取得する。obtainStatusコマンドを発行することにより、装置オブジェクトに被監視装置のポーリングを実行する。各ソフトウェアオブジェクトのステータスを一旦取得すると、そのステータスはDeviceODBC１１０４を通じて更新される。ステータス監視シーケンスは、図１４を参照して上で説明したので、ここでは説明を繰り返さない。

テーブルIに示したDeviceInfo構造は、被監視装置の一例に関する情報を示している。DeviceInfo構造は、連絡を取る人物の電話番号に加えて電子メールアドレスを含んでいる。

監視データベース
図１９は監視データベースの組織を示し、各被監視装置の装置情報を含んでいる（表１も参照）。図１９に示したように、各通信プロトコル（例えば、SNMP、HTTP、FTP）に対して一組のパラメータが、各被監視装置の装置情報DeviceInfo１９０２と関連している。さらに、１つのプロトコル（例えば、SNMP１９０８、HTTP１９１０、FTP１９１２）の各パラメータの組は、パラメータ名と値のペア（例えば、sPar1NameとsPar1Value）のリストとしてまとめられている。各プロトコルのパラメータ数は、図１９に示した数よりも少ない場合も多い場合もあることに注意すべきである。例えば、ある被監視装置については、ユーザ名とパスワードはFTPパラメータとして格納され、一方、コミュニティ名とパスワードはSNMPパラメータとして格納される。図１９に示したように、監視データベースはDeviceHistory１９０４とEnumCorrespondence１９０６に関する情報も含む。

図１７はSParameterデータ構造１７００を示し、このデータ構造はいろいろな通信プロトコルにより使用されるパラメータをパスするために使用される。Sparameterは２つのフィールドを含む。SParameterは２つのフィールドm_sParName１７０２とm_sParValue１７０４を含み、それぞれパラメータの名前と値を表す。

図１８は、マップ構造１８００を示し、このマップ構造は、監視データベースから取得した各プロトコルのパラメータのベクトルを各被監視装置に関連するソフトウェアオブジェクトにパスするために使用される。マップ構造１８００は、各プロトコル／キーフィールド１８０２、１８０４、１８０６を、図１７に示したSParameterフォーマットに従って構成した対応するパラメータ１８０８、１８１０、１８１２のベクトルそれぞれと関連づける。例えば、SNMPプロトコル１８０２の場合、パラメータベクトル１８０８は、SNMPプロトコルを用いて被監視装置にアクセスするために使用するパラメータ名、パラメータ値ペアのリストを含んでいる。例えば、ベクトル１８０８に格納されるSNMPパラメータ名は、対応するパラメータ値とともに「コミュニティ名」と「パスワード」を含んでいてもよい。しかし、マップ構造１８００では、プロトコルとそれに付随するパラメータベクトルの数はいくつでもよく、図１８に示したSNMP、HTTP、FTPプロトコルに限定されない。

サポートデータベース
図２０ないし図２２は、図１０に示したサポートデータベース１０２４の構成を示す。サポートデータベースは、各被監視装置からステータス情報を抽出するのに必要な情報を含み、通信プロトコルにより構成されている。例えば、図２０は、被監視装置から情報を抽出するために使用するSNMP関係のサポート情報のサポートデータベースの構成を示し、データ構造SNMPVendor２００２、SNMPComVendorStatus２００４、EnumCorrespondence２００６、SNMPVendorModelStatus２００８を含む。サポートデータベースのデータ構造は、抽出を制御するパラメータと合わせて、抽出するステータス情報のタイプを一意的に特定するパラメータを含む。例えば、SNMPComVendorStatusデータ構造２００４は、抽出する情報のタイプ（例えば、トナーレベル）を特定するnENUMフィールド２００９と、他のプロトコルに関する抽出情報の重みや重要性を示すnRelativePriorityフィールド２０１０を含む。このように、同じ情報が２以上のプロトコルを用いて被監視装置から抽出される場合、nRelativePriority値がどのプロトコルで抽出された値を使用するかに関する表示を与える。例えば、HTTPはトナーレベルの高低を表示する情報だけを抽出でき、一方、SNMPプロトコルは残りのトナーのパーセンテージを抽出できる場合、SNMPのトナーレベルの優先レベルがHTTPの対応する値よりも高くなるであろう。また、サポートデータベースでは、プロトコル全体にデフォルトの優先値をつけてもよい。一実施形態において、プロトコル値が0から32,000の範囲であるシステムにおいて、SNMPプロトコルには優先値10,000を与える。

図２１と２２は、サポートデータベース１０２４のHTTPとFTP部分に含まれるデータ構造を示し、図２０を参照して上で説明したデータ構造に類似したデータ構造を含んでいる。

本発明で使用するenumタイプの例は、以下に定義するinfoTypeである。（enumタイプは単なる一例であり、本発明を限定するものとして解釈してはならない。）
infoType (typedef int infoType)
このセクションではinfoType(int)の定義を説明する。データタイプには０から９９までの範囲の値が割り当てられている。１００から４９９までの値の範囲が装置情報に割り当てられている。５００から１９９９の値の範囲が標準MIBパラメータを含む共通パラメータに割り当てられている。２０００から３９９９の範囲がリコー特有の情報に割り当てられている。４０００から４９９９の範囲がVendor1に割り当てられている。５０００から５９９９の範囲がVendor2に割り当てられている。６０００から６９９９までの範囲がVendor3に割り当てられている。値は以下のように決められる：
infoType{eNotDefine=0,eDeviceInformation=1,eStatusInformation=2,eVendor=100,eModel,eUniqueID,eIPAddress,eCompanyName,eStreet,eCity,eState,eZipCode,eLocation,eContactPerson,ePhoneNumber,eEMailAddress,eDateTime=500,eHrDeviceErrors,eLowPaper,eNoPaper,eLowToner,eNoToner,eDoorOpen,eJammed,eOffline,eServiceRequested,ePrtGeneralConfigChanges=600,ePrtLifeCount,ePrtAlertDesc1,ePrtAlertDesc2,ePrtAlertDesc3,ePrtAlertDesc4,ePrtAlertDesc5,eBlack=700,eMagenta,eCyan,eYellow,eTonerCollector=800,eBlackDeveloper=810,eColorDeveloper,eFuser=820,eDrum=830,eTransfer=840,eMaintenanceKit=850,eOilKit=860,eStationInfo1=901,eStationInfo2,eStationInfo3,eStationInfo4,eStationInfo5,eRicohEngineCounterTotal=2000,eRicohEngineCounterPrinter,eRicohEngineCounterFax,eRicohEngineCounterCopier}.
EerrorCode
以下のコードは単なる一例であり、より多くのコードを既存のセットに加えてもよい。範囲0-99は予約されている。範囲１００−１９９はSMTP用、２００−２９９はPOP3用、３００−３９９はSocket用、４００−４９９はHTTP用、５００−５９９はFTP用である。その他の明記しなかった範囲は、必要に応じてユーザが定義してもよい。

Enum EerrorCode(eNoError=0,eUnknownError=1,eSomeError,eCompleteFailure,eSomeDeviceCreationError=20,eCreateDeviceError,eNoDeviceCreated,eObtainConfigError,eSaveStatusError,eObtainUniqueIDError,eObtainStatusError,eStartSendError,eSomeDataSendError,eCompleteDataSendFailure,eEndSendError,eSendHeloCommandFailed=100,eSendMailCommandFailed,eSendRcptCommandFailed,eSendDataCommandFailed,eSendDataFailed,eSendQuitCommandFailed,eSendUserCommandFailed=200,eSendPassCommandFailed,eSendStatCommandFailed,eSendRetrCommandFailed,eSendDeleCommandFailed,eSendQuitPop3CommandFailed,eCreateSocketFailed=300,eConnectSocketFailed,eBadRequest=400,eUnauthorized,ePaymentRequired,eForbidden,eNotFound,eMethodNotAllowed,eNotAcceptable,eProxyAuthenticationRequired,eRequestTimeOut,eConflict,eGone,eLengthRequired,ePreconditionFailed,eRequestEntityTooLarge,eRequestURITooLarge,eUnsupportedMediaType,eRequestedRangeNotSatisfiable,eExpectationFailed,eInternalServerError=450,eNotImplemented,eBadGateway,eServiceUnavailable,eGatewayTimeOut,eHTTPVersionNotSupported,eMultipleChoices=480,eMovedPermanently,eFound,eSeeOther,eNotModified,eUseProxy,eTemporaryRedirect).
DeviceODBCモジュールの抽象型クラス
図１６は、本発明によるDeviceODBCモジュールクラス構造を示し、CabsProtocolParametersクラス構造がDeviceODBCモジュール内でどのように使用されるかを示している。CAbsProtocolParametersクラスは、監視データベース１０１４とインターフェイスし通信プロトコルを用いて被監視装置にアクセスするための情報を取得するように設計されている。CabsProtocolParametersクラスはプロトコルに依存しない２つの仮想関数を有する：
(1)std::string obtainProtocolName(void);及び
(2)bool obtainParameterVector(std::vector<SParameter> & out_ParameterVector, const std::string in_sIP)。
これらの関数を用いて、CDeviceODBCクラスは、プロトコルを特定することなくCabsProtocolParameterタイプへのポインタを通じて、同じ数のプロトコル、及びそれに関連するパラメータ名もしくは値を取り扱うことができる。取得した各装置の情報（例えば、IPアドレス）は、図１８のデータ構造に格納され、obtainConfig関数を通してMonitorManagerモジュール１１０２に送られる。CDeviceODBCの観点から、プロトコル名及びそれに関連したパラメータ名と値を取得するために使用するオブジェクトはすべて、CAbsProtocolパラメータの一種であると考えられる。新しいプロトコルが追加されると、新しいオブジェクトが生成され、CabsProtocolParametersクラスへのポインタのベクトルに格納される。他の関数を変更する必要はない。

HWaccessモジュールの抽象型クラス
図２３は、HWaccessパッケージを示すパッケージ図である。このパッケージは、監視するネットワーク装置を特定し、いろいろなネットワークプロトコル（例えば、SNMP、HTTP、FTP）を用いてそのネットワーク装置に関する情報を取得する役割を担う。このパッケージは、パッケージHTTP２３０２、SNMP２３０４、FTP２３０６、及びクラスCHWaccess２３００、CAbsProtocol２３０８、CrecordSet２３１０を含む。パッケージHTTP２３０２、SNMP２３０４、FTP２３０６は、ネットワーク装置にアクセスしそれから情報を取得するためのネットワークプロトコルを実装する。例えば、HTTPパッケージ２３０２は、ネットワーク装置のウェブページにアクセスしそのウェブページから情報を取得するためのHTTPプロトコルを実装する。クラスCHWaccess２３００はすべてのプロトコルパッケージを管理し、ネットワーク装置から必要な情報を取得する。クラスCAbsProtocol２３０８は任意のプロトコルを表す抽象型クラスである。このクラスは、CHWaccess２３００とプロトコルパッケージ間のインターフェイスを提供する。クラスCAbsProtocol２３０８は、CHWaccess２３００に図２３に示した一組の共通関数を提供する。すべてのプロトコルは、CHWaccess２３００に必要な情報を提供する。後に出てくる図面で説明するように、CAbsProtocol２３０８から導かれるクラスは、適当なプロトコルについて各関数のメソッドを提供する。クラスCRecordSet２３１０は、マイクロソフトファウンデーションクラスのクラスである。各プロトコルパッケージは、このクラスによりデータベースにアクセスして、ネットワーク装置のどのベンダーのどのモデルがサポートされそのネットワーク装置から何の情報を取得するかという情報を取得することができる。

図２４は、SNMPパッケージ２３０４の第１の実施形態を示すパッケージ図である。図２４に示したコンポーネントの多くが、図６３に示すSNMPパッケージの第２の実施形態にも組み込まれることに留意せよ。このパッケージにより、SNMPプロトコルによりサポートされたネットワーク装置のベンダーとモデルおよびSNMPプロトコルによりネットワーク装置から取得する情報を決定し、SNMPプロトコルを通じてネットワーク装置にアクセスしてそのネットワーク装置から情報を取得する役割を担う。上記パッケージは、パッケージSNMPaccess２４０４とSNMPODBC２４０６およびクラスCSNMPProtocol２４０２を含み、図２３に示したようにクラスCAbsProtocol２４００とCRecordSet２４０８を使用する。SNMPaccessパッケージ２４０４は、ネットワーク装置にアクセスしそれから情報を取得するためのSNMPプロトコルを実装する。SNMPODBCパッケージ２４０６は、データベースにアクセスして、SNMPプロトコルによりサポートされたネットワーク装置のベンダーとモデルと、SNMPプロトコルによりそのネットワーク装置から取得する情報とに関する情報を取得する。CSNMPProtocolクラス２４０２は、CAbsProtocolクラス２４００から導き出されたクラスである。CSNMPProtocol２４０２は、SNMPプロトコルを用いてネットワーク装置から必要な情報を取得する。CSNMPProtocol２４０２は、図２３に示したようにCAbsProtocol２４００のすべてのインターフェイス関数のメソッドを提供する。図２４は、CSNMPProtocol２４０２が使用するパッケージSNMPaccess２４０４とSNMPODBC２４０６の関数を示している。SNMPODBCパッケージ２４０６は、クラスCRecordSet２４０８を使用してデータベースから情報を取得する。

図25は、HTTPパッケージ２３０２の第１の実施形態を示すパッケージ図である。図25に示したコンポーネントの多くが、図41に示すHTTPパッケージの第２の実施形態にも組み込まれることに留意せよ。このパッケージは、HTTPプロトコルによりサポートされたネットワーク装置のベンダーとモデルおよびHTTPプロトコルによりそのネットワーク装置から取得する情報を決定し、HTTPプロトコルでそのネットワーク装置にアクセスしてそのネットワーク装置から情報を取得する役割を担う。このパッケージは、パッケージHTTPaccess２５０４とHTTPODBC２５０６およびクラスCHTTPProtocol２５０２を含み、図２３に示したようにクラスCAbsProtocol２５００とCRecordSet２５０８を使用する。HTTPaccessパッケージ２５０４は、HTTPプロトコルを実装し、ネットワーク装置にアクセスしてそのネットワーク装置から情報を取得する。HTTPODBCパッケージ２５０６は、データベースにアクセスし、そのデータベースからHTTPプロトコルによりサポートされたネットワーク装置のベンダーとモデルと、HTTPプロトコルによりそのネットワーク装置から取得する情報とに関する情報を取得する。CHTTPProtocolクラス２５０２は、CAbsProtocolクラス２５００から導き出されたクラスである。CHTTPProtocol２５０２は、HTTPプロトコルを用いてネットワーク装置から必要な情報を取得する。CHTTPProtocol２５０２は、図２３を参照して説明したように、CAbsProtocol２５００のインターフェイス関数すべてにメソッドを提供する。図２５は、CHTTPProtocol２５０２が使用するパッケージHTTPaccess２５０４とHTTPODBC２５０６の関数も示している。HTTPODBCパッケージ２５０６は、クラスCRecordSet２５０８を用いてデータベースから情報を取得する。

図２６は、FTPパッケージ２３０６を示すパッケージ図である。このパッケージは、FTPプロトコルによりサポートされたネットワーク装置のベンダー及びモデルと、FTPプロトコルによりそのネットワーク装置から取得する情報とを決定し、FTPプロトコルによりそのネットワーク装置にアクセスして、そのネットワーク装置から情報を取得する役割を担っている。このパッケージは、パッケージFTPaccess２６０４とFTPODBC２６０２およびクラスCFTPProtocol２６０２を含み、図２３を参照して説明したようにクラスCAbsProtocol２６００とCRecordSet２６０８を使用する。FTPaccessパッケージ２６０４は、ネットワーク装置にアクセスし、そのネットワーク装置から情報を取得するためのFTPプロトコルを実装している。FTPODBCパッケージ２６０６は、データベースにアクセスし、FTPプロトコルによりサポートされたネットワーク装置のベンダーとモデル、およびFTPプロトコルによりそのネットワーク装置から取得する情報、に関する情報をそのデータベースから取得する。CFTPProtocolクラス２６０２は、CAbsProtocolクラス２６００から導き出されたクラスである。CFTPProtocol２６０２は、FTPプロトコルを用いてネットワーク装置から必要な情報を取得する。CFTPProtocol２６０２は、図２３を参照して説明したように、CAbsProtocol２６００のインターフェイス関数すべてのメソッドを提供する。図２６は、CFTPProtocol２６０２が使用するパッケージFTPaccess２６０４とFTPODBC２６０６の関数も示している。FTPODBCパッケージ２６０６は、クラスCRecordSet２６０８を用いてデータベースから情報を取得する。

各プロトコルパッケージHTTP２３０２、SNMP２３０４、FTP２３０６は、図２３から２６を参照して説明したように、ネットワーク装置へのアクセスを管理してその装置から情報を取得するクラスを含んでいる。そのクラスは、ネットワーク装置からの情報にアクセスするプロトコルを実行するメソッドを提供する抽象型クラスCAbsProtocol２３０８から導き出される。抽象型クラスは、インターフェイス関数のみを提供し、プロセスは何も実行しない。抽象型クラスから導き出されたクラスは、インターフェイス関数を実行するメソッドを提供する。抽象型クラスの派生クラスは多数あるので、異なる派生クラスがインターフェイス関数のプロセスを異なるように実行することができる。例えば、CAbsProtocolのインターフェイス関数はobtainStatus()である。派生クラスCSNMPProtocol２４０２は、SNMPを用いてネットワーク装置のステータス情報を取得するメソッドを提供する関数obtainStatus()を含み、一方、派生クラスCHTTPProtocol２５０２はHTTPを用いてネットワーク装置のステータス情報を取得するメソッドを提供する関数obtainStatus()を含む。HWaccessパッケージの設計によれば、新しいパッケージ（その新しいパッケージを管理するCAbsProtocolの派生クラスを含む）を付加することにより、新しいプロトコルをシステムに追加して、その新しいプロトコルを用いてネットワーク装置にアクセスすることができる。抽象型クラスによりシステムを将来的に拡張することができる。

図２７A−２７Dは、ネットワーク装置にアクセスしてそれから情報を取得するためのプロトコルをすべて保持する、図２３のHWaccessパッケージで使用されるデータ構造を示している。図２７Aに示したデータ構造は、CAbsProtocol２３０８へのポインタのベクトル５００である。クラスCHWaccess２３００は、このデータ構造体を含み、使用する。ベクトル５００は、CAbsProtocol２３０８から導き出されたクラスへのポインタを含んでいるが、CHWaccess２３００は、そのベクトルをCAbsProtocol２３０８へのポインタを含むとみなし、仮想ファンクションコールメカニズムを通してCAbsProtocol２３０８のインターフェイス関数を呼び出す。CHWaccess２３００は、実際には、CAbsProtocol２３０８の派生クラスのインターフェイス関数を呼び出す。例えば、ベクトルの第１のエントリーのCAbsProtocolへのポインタ５０２は、派生クラスCSNMPProtocol２４０２へのポインタであり、ベクトルの第２のエントリーのCAbsProtocolへのポインタ５０４は、派生クラスCHTTPProtocol２５０２へのポインタであり、ベクトルの第３のエントリーのCAbsProtocolへのポインタ５０６は、派生クラスCFTPProtocol２６０２へのポインタである。そこで、CHWaccess２３００がベクトルのCabsProtocol２３０８のインターフェイス関数を呼び出すとき、実際にはCSNMPProtocol２４０２、CHTTPProtocol２５０２、CFTPProtocol２６０２のインターフェイス関数を呼び出している。ベクトル５００の抽象型クラスCAbsProtocol２３０８を使用することにより、どのプロトコルを使用してもネットワーク装置にアクセスして、そのネットワーク装置から情報を取得することができる。抽象型クラスCAbsProtocol２３０８は、どのプロトコルが使用されているかの詳細を隠蔽する。

図２７Bは、CSNMPProtocolにより使用されるデータ構造を示し、このデータ構造は、SNMPにより監視されるネットワーク装置のベンダーとモデルに関する情報と、そのネットワーク装置からステータス情報を取得するために使用する情報とを保持する。このデータ構造はマップ５１０である。マップ５１０のキーは、ネットワーク装置のベンダー名を表すストリング５１２である。マップ５１０の値は他のマップ５１４である。マップ５１４のキーは、ネットワーク装置のモデル名を表すストリング５１６である。マップ５１４の値はペアのベクトル５１８である。そのペアには構造SOIDinfoTypeと整数が含まれている。構造SOIDinfoTypeは、SNMPを用いてネットワーク装置から単一のステータス情報を取得するために使用する情報を含む。それゆえ、ペアのベクトル５１８は、特定のベンダーとモデルのネットワーク装置のステータス情報をすべて取得するための情報を含む。マップ５１０の情報は、図２８を参照して説明したプロセスを用いて初期化される。マップ５１０は、ベンダーのストリング５１２とモデルのストリング５１６のエントリーの一例を示している。

図２７Cは、CHTTPProtocolにより使用されるデータ構造を示し、このデータ構造には、HTTPにより監視されているネットワーク装置のベンダーとモデルに関する情報と、そのネットワーク装置からステータス情報を取得するために使用する情報とを保持される。このデータ構造はマップ５２０である。マップ５２０のキーは、ネットワーク装置のベンダー名を表すストリング５２２である。マップ５２０の値は他のマップ５２４である。マップ５２４のキーは、ネットワーク装置のモデル名を表すストリング５２６である。マップ５２４への値はSWebPageInfoのベクトル５２８である。構造SWebPageInfoは、HTTPを用いてネットワーク装置のウェブページからステータス情報をすべて取得するために使用する情報を含んでいる。それゆえ、SWebPageInfoのベクトル５２８は、そのウェブページのすべてから特定のベンダーとモデルのネットワーク装置のステータス情報をすべて取得するための情報を含んでいる。マップ520の情報は、図２８を参照して説明したプロセスを用いて初期化される。マップ５２０は、ベンダーのストリング５２２とモデルのストリング５２６のエントリーの一例を示している。

図２７Dは、CFTPProtocolにより使用されるデータ構造を示し、このデータ構造は、FTPにより監視されているネットワーク装置のベンダーと、モデルに関する情報と、そのネットワーク装置からステータス情報を取得するために使用する情報とを保持する。そのデータ構造はマップ５３０である。マップ５３０のキーは、ネットワーク装置のベンダー名を表すストリング５３２である。マップ５３０の値は他のマップ５３４である。マップ５３４のキーは、ネットワーク装置のモデル名を表すストリング５３６である。マップ５３４の値はSDirFileStatusInfoのベクトル５３８である。構造SDirFileStatusInfoは、FTPを用いてネットワーク装置のFTPファイルからすべてのステータス情報を取得するために使用する情報を含む。それゆえ、SDirFileStatusInfoのベクトル５３８は、そのFTPファイルのすべてから特定のベンダーとモデルのネットワーク装置のステータス情報のすべてを取得するために使用する情報を含む。マップ５３０の情報は、図２８を参照して説明したプロセスを用いて初期化される。マップ５３０は、ベンダーのストリング５３２とモデルのストリング５３６のエントリーの一例を示している。

図２８は、システムにより監視されるネットワーク装置のベンダーに関する情報で、すべてのプロトコルオブジェクトを初期化するプロセスを示すフローチャートである。同様のプロセスを用いて、システムにより監視されるネットワーク装置のモデルに関する情報で、すべてのプロトコルオブジェクトを初期化する。ネットワーク装置が監視されている場合、何の情報をそのネットワーク装置から取得する必要があるかを決定するために、そのネットワーク装置のベンダーとモデルを知っておく必要がある。ネットワーク装置にアクセスして情報を取得するために使用する各プロトコルオブジェクトは、そのネットワーク装置から何の情報をいかに取得するかを決定するために、ベンダーとモデルを知っている必要がある。初期化を必要とするプロトコルオブジェクトは、CabsProtocol２３０８から導かれたクラスに相当するものであり、CSNMPProtocol、CHTTPProtocol、CFTPProtocolである。プロトコルオブジェクトの初期化では、そのプロトコルに対応する図２７B、２７C、及び２７Dを参照して説明したデータ構造に情報を追加する。システムの設計によれば、図２７B、２７C、２７Dのデータ構造に追加される情報はデータベースから来たものであるが、テキストファイルやスプレッドシートなど他の外部ソースから来たものであってもよい。図２７Aを参照して説明したCAbsProtocol２３０８へのポインタのベクトルを使用して、すべてのプロトコルオブジェクトを初期化する。フローチャートのプロセスはベクトルを２回通る。１回目にベクトルを通るとき、プロトコルオブジェクトを用いてネットワーク装置のベンダーを見つける。ベンダー名がプロトコルオブジェクトの１つから取得できた場合、ベクトルを２回目に通るとき、すべてのプロトコルオブジェクトはそのベンダー名で初期化される。ステップ６０２において、CAbsProtocolへのポインタのベクトルからプロトコルオブジェクトを取得する。プロトコルオブジェクトは、ネットワーク装置にアクセスするためのプロトコル（例えば、SNMP、HTTP、FTP）の１つに対応する。ステップ６０４において、ベクトルから取得できるプロトコルオブジェクトがあるかどうかチェックする。このチェックは、ベクトルの終わりに来たかどうか判断することによりなされる。もしプロトコルオブジェクトがもうなければ、システムはネットワーク装置のベンダー名を取得できない。ベンダー名の取得とネットワーク装置のプロトコルオブジェクトの初期化とに失敗したプロトコルオブジェクトは、すべてステップ６０６で終了する。ベクトルから取得したプロトコルオブジェクトがあれば、そのプロトコルオブジェクトを用いて、ステップ６０８においてネットワーク装置のベンダー名を取得する。ステップ６１０において、プロトコルオブジェクトがネットワーク装置のベンダー名を取得可能であるかどうかをチェックする。プロトコルオブジェクトは、ネットワーク装置のベンダーを決定するために使用する情報をデータベースから取得する。プロトコルオブジェクトがベンダー名を取得することができないとき、ステップ６０２に戻り、ベクトルの他のプロトコルオブジェクトを用いてベンダー名を取得することを試みる。プロトコルオブジェクトからベンダー名を取得できた場合、ステップ６１２においてそのプロトコルオブジェクトをそのベンダー名で初期化する。プロトコルオブジェクトは、取得したベンダー名のネットワーク装置からステータス情報をいかに取得するかに関する情報で初期化される。情報は図２７B、２７C、２７Dを参照して説明したようにデータ構造に追加される。ステップ６１４において、CAbsProtocolへのポインタのベクトルからプロトコルオブジェクトを取得する。ステップ６１６において、ベクトルから取得できるプロトコルオブジェクトがあるかどうかチェックする。プロトコルオブジェクトをこれ以上取得できないとき、すべてのプロトコルオブジェクトはベンダー名が初期化されており、すべてのプロトコルオブジェクトの初期化はステップ６０６で終了する。すべてのプロトコルオブジェクトはベンダーに関する情報が更新されている。ベクトルから取得されたプロトコルオブジェクトがあれば、ステップ６１８においてそのプロトコルオブジェクトをベンダー名で初期化する。ステップ６１２と同様に、プロトコルオブジェクトを、取得したベンダー名のネットワーク装置からステータス情報をいかに取得するかに関する情報で初期化する。プロトコルオブジェクトをベンダー名で初期化したのち、ステップ６１４に戻って、他のプロトコルオブジェクトをベンダー名で初期化する。

図２８のステップ６０８において、プロトコルオブジェクトはネットワーク装置のベンダー名を取得する。SNMP、HTTP、FTPプロトコルオブジェクトは、ネットワーク装置にアクセスして、ベンダー名を取得することができる。どこでベンダー名を見つけることができるかに関する情報は、データベースから得られる。データベースは、プロトコルによりサポートされたネットワーク装置のベンダーに関する情報とともに、ネットワーク装置のベンダー名を探すための情報を提供する。SNMPの場合、ベンダー名と関連する企業オブジェクト識別子と、ネットワーク装置のMIBにあるその企業オブジェクト識別子を見つけるために使用するオブジェクト識別子とに関する情報を用いて、SNMPプロトコルオブジェクトは、ベンダー名を取得する。HTTPの場合、ウェブページとそのウェブページ内の位置に関する情報を用いて、HTTPプロトコルオブジェクトは、ベンダー名を取得する。FTPの場合、FTPファイルとそのFTPファイル内の位置に関する情報を用いて、FTPプロトコルオブジェクトは、ベンダー名を取得する。

図２９A−２９Dは、異なるプロトコルのベンダーとモデルのネットワーク装置のステータス情報を取得するために使用する異なるデータ構造を示している。異なるプロトコルを用いて同一のステータス情報を取得することもできる。しかし、１つのプロトコルにより取得されるステータス情報は他のプロトコルにより取得される情報よりも多いことがあるので、より多くの情報を取得できるプロトコルから取得したステータス情報を使用した方がよい。例えば、プリンターカートリッジのトナーレベルは、SNMPとHTTPを用いてネットワークプリンターから取得できる。SNMPにより取得されるトナーレベルのステータス情報は、「フル」、「OK」、または「エンプティ」であり、一方、HTTPにより取得される同じステータス情報は、トナー残量のパーセンテージであるかも知れない。このような場合、HTTPを用いて取得したステータス情報の方が情報量は多いので、HTTPにより取得したステータス情報を使用すればよい。図２９A−２９Dに示したデータ構造により、最も情報の多いステータス情報を確実に取得することができる。図２９Aは、SNMPプロトコルを用いて特定のベンダーとモデルのネットワーク装置のステータス情報を取得するために使用するデータ構造を示している。そのデータ構造はペア（例えば、７０２と７０４）のベクトル７００であり、そのペアは構造SOIDinfoType７０６と整数よりなる。構造SOIDinfoType７０６は、SNMPを用いてネットワーク装置から特定のステータス情報を取得するために用いる情報を含んでいる。SOIDinfoType７０６の構造は図２９Aに示されている。ペア中の整数はステータス情報の重みまたは優先度を決定する。整数値が大きいほど、取得されるステータス情報は情報が多いので採用されやすい。整数値が小さければ小さいほど、他のプロトコルから得られた同じステータス情報が採用されやすい。CSNMPProtocol２４０２は、ベクトル７００を用いて、何のステータス情報をネットワーク装置から取得するかを決定する。ベクトル７００に入れられる情報は、特定のベンダーとモデルについて図２７Bのデータ構造から取得される。

図２９Bは、HTTPプロトコルを用いて特定のベンダーとモデルのネットワーク装置のステータス情報を取得するために使用するデータ構造を示す。そのデータ構造はペア（例えば、７１０と７１２）のベクトル７０８であり、そのペアは構造SKeyValueInfo７１４と整数よりなる。構造SKeyValueInfo７１４は、HTTPを用いてネットワーク装置のウェブページから特定のステータス情報を取得するために使用する情報を含む。SKeyValueInfo７１４の構造は図２９Bに示されている。ペア中の整数はステータス情報の重みまたは優先度を決定する。CHTTPProtocol２５０２は、ネットワーク装置から何のステータス情報を取得するかを決定するためにベクトル７０８を使用する。ベクトル７０８に入っている情報は、特定のベンダーおよびモデルについて図２７Cのデータ構造から取得される。

図２９Cは、FTPプロトコルを用いて特定のベンダーおよびモデルのネットワーク装置のステータス情報を取得するために使用するデータ構造を示している。そのデータ構造はペア（例えば、７１８と７２０）のベクトル７１６であり、そのペアは構造SKeyInfoType７２２と整数よりなる。構造SKeyInfoType７２２は、FTPを用いてネットワーク装置のFTPファイルから特定のステータス情報を取得するために使用する情報を含む。SKeyInfoType７２２の構造は図２９Cに示されている。ペア中の整数はステータス情報の重みまたは優先度を決定する。CFTPProtocol２６０２はベクトル７１６を使用して、ネットワーク装置から何のステータス情報を取得するかを決定する。ベクトル７１６に入っている情報は、特定のベンダーおよびモデルについて図２７Dのデータ構造から取得される。

図２９Dは、様々なプロトコルで取得するステータス情報を維持するために使用するデータ構造を示している。そのステータス情報を取得するためにどのプロトコルが使用されたかに関する情報は維持していない。そのデータ構造はマップ724である。マップ７２４へのキー７２６はinfoTypeである。infoTypeは情報のタイプを表す番号である。マップ７２４の値はペアである。ペアはストリングと整数よりなる。ペア中のストリングは、infoTypeに対応するネットワーク装置から取得したステータス情報である。ペア中の整数は、プロトコルから取得したステータス情報の重みまたは優先度である。一例として、infoTypeが７００であり、プリンターカートリッジのブラックトナーのレベルを表す場合、そのペアはストリング「７５％」と整数１００００を含んでいるとする。ストリング「７５％」はカートリッジに７５％のトナーが残っていることを示し、整数１００００はそのステータス情報の重みまたは優先度である。CSNMPProtocol２４０２、CHTTPProtocol２５０２、CFTPProtocol２６０２は、ネットワーク装置から取得したステータス情報をマップ７２４に追加する。

図３０は、FTPプロトコルを用いてネットワーク装置からステータス情報を取得するために、図２７D、２９C、２９Dのデータ構造がいかに使用されるかの一例を示している。サンプルデータを含むマップ８００は、図２７Dを参照して説明したデータ構造に対応する。マップ８００のサンプルデータは、FTPを用いてベンダーであるリコーとモデルであるAficio１２０のネットワーク装置のステータス情報にアクセスするための情報を提供する。ベクトルの各構造SDirFileStatusInfo1、SDirFileStatusInfo2、SDirFileStatusInfo3は、ネットワーク装置のFTPファイルからのステータス情報にアクセスするための情報を提供する。SDirFileStatusInfo1 ８０２は、ディレクトリ/pubのFTPファイルstatus.txtから、ネットワーク装置からのステータス情報にアクセスするための情報を含む。SKeyInfoTypeと整数のペアのベクトルを用いて、FTPファイルから５つのステータス情報値を取得できる。ベクトルペアの各SKeyInfoTypeは、図３０に示したinfoTypeに対応する異なるステータス情報に対応する。マップ８０４は、図２９Dを参照して説明したデータ構造に対応するサンプルデータを含んでいる。マップ８０４は、前もって他のプロトコルにより取得したステータス情報を含んでいる。マップ８０４は、infoType６００、６１０、７００に対応する３種類のステータス情報を含んでいる。infoType６００のステータス情報は、「ローペーパー（Low Paper）」であり、その重みは５００である。infoType６１０のステータス情報は、「２４３２１」であり、その重みは１００００である。

infoType７０のステータス情報は「OK」であり、その重みは２５００である。FTPプロトコルを用いて何のステータス情報が取得されるかを決定するため、取得するステータス情報を含むベクトル８０６が生成される。ベクトル８０６に加えられる情報は、マップ８００の情報（より具体的には、構造SDirFileStatusInfo1８０２のペアのベクトル）とマップ８０４のステータス情報により決定される。マップ８００から取得するステータス情報がマップ８０４にはまだ取得されていない場合、ステータス情報を取得するために必要な情報をベクトル８０６に加える。マップ８００から取得されるステータス情報がマップ８０４に取得されている場合、FTPプロトコルにより取得されるステータス情報はマップ８０４のステータス情報より情報が多いかどうかを、重みを比較してチェックする。ベクトル８０６にステータス情報を取得するための情報を加えるのは、FTPにより取得されたステータス情報の重みがマップ８０４にすでにあるステータス情報の重みよりも大きい場合だけである。SDirFileStatusInfo1に対応するFTPにより取得されるステータス情報は、infoType６００、６１０、６２０、７００、７１０である。infoType６２０と７１０はステータス情報マップ８０４にないので、FTPを用いてステータス情報を取得する必要がある。それゆえ、６２０（SKeyInfoType3）と７１０（SKeyInfoType5）に対応するステータス情報を取得するために使用する情報が、ベクトル８０６に加えられる。infoType６００と７００はステータス情報マップ８０４にある。８０２に示したように、これらのinfoTypeのFTPにより取得されるステータス情報の重みは、ステータス情報マップ８０４中のそれらの重みよりも大きい。そのため、FTPによりこれらの２つのinfoTypeについて取得されたステータス情報は、マップ８０４にあるステータス情報より情報が多い。それゆえ、infoType６００（SKeyInfoType1）と７００（SKeyInfoType4）のステータス情報を取得するための情報がベクトル８０６に加えられる。infoType６１０はステータス情報マップ８０４にある。８０２に示したこのinfoTypeのFTPにより得られるステータス情報の重みは、ステータス情報マップ８０４の重みより小さい。FTPによりこのinfoTypeについて取得されたステータス情報は、マップ８０４にあるステータス情報より情報が少ない。それゆえ、infoType６１０（SKeyInfoType2）のステータス情報を取得するための情報は、ベクトル８０６には加えられない。FTPプロトコルは、このベクトル８０６を使用し、infoType６００、６２０、７００、７１０のステータス情報を取得する。２つのステータス情報値がステータス情報マップ８０４に加えられ、FTPによりステータス情報を取得できれば、ステータス情報マップ８０４の２つのステータス情報値が上書きされる。図３０は、FTPプロトコルの場合、データ構造をいかに使用してステータス情報を取得するかを示す例である。図２７B、２７C、２９A、２９Bのデータ構造を使用する同様のプロセスを使用して、SNMPとHTTPのステータス情報を取得する。

図３１Aは、ステータス情報を取得する方法を示すフローチャートである。すべてのプロトコルでここに説明する方法を使用できる。プロトコルオブジェクトを使用してステータス情報を取得する前に、プロトコルオブジェクトはステータス情報が他のプロトコルオブジェクトによりすでに取得されているかどうかをチェックする。ステータス情報がすでに取得されている場合、これから取得するステータス情報が他のプロトコルオブジェクトからすでに取得されたものよりも情報が多いかどうかをチェックしなければならない。最も情報が多いステータス情報が保存される。フローチャートの方法により、最も情報が多いステータス情報を確実に取得することができる。図２７B、２７C、２７Dのデータ構造５１０、５２０、５３０が対応するプロトコルにより使用され、どのステータス情報を取得するかを決定する。ステップ３１０２において、ネットワーク装置からステータス情報を取得するために使用する情報を含むペアのベクトルが、エントリー無しに生成される。ペアのベクトルは、使用されるプロトコルに応じて、図２９Aから２９Cのデータ構造７００、７０８、７１６の１つに対応する。ステップ３１０４において、与えられたベンダーとモデルのネットワーク装置から１種類のステータス情報を取得するために使用する情報を取得する。すべてのプロトコルオブジェクトは、サポートするすべてのベンダーとモデルについて何のステータス情報を取得するかに関する情報を保持している。図２８を参照して説明した初期化プロセスにより、すべてのプロトコルオブジェクトがこの情報で初期化される。１つのステータス情報を取得するために使用される情報は、使用するプロトコルに応じて図２９A、２９B、２９Cの構造SOIDinfoType７０６、SKeyValueInfo７１４、SKeyInfoType７２２の１つに格納される。ステップ３１０６において、ネットワーク装置からステータス情報を取得するために使用される情報がまだあるかチェックする。情報がもうなければ、ステップ３１０２で生成されたペアのベクトルは、そのプロトコルについてそのネットワーク装置からすべてのステータス情報を取得するために必要なすべての情報を含んでいる。ステップ３１０８において、プロトコルオブジェクトは、ペアのベクトルを使用してネットワーク装置からステータス情報を取得し、そのステータス情報は、図２９Dを参照して説明したステータス情報マップ７２４に格納される。プロトコルによるステータス情報の取得は、ステップ３１１０で完了する。ネットワーク装置からステータス情報を取得するために使用するより多くの情報があれば、ステップ３１１２において、そのステータス情報がすでに取得されているかどうかをチェックする。このチェックは、図２９Dを参照して説明したように、ステータス情報を含むマップを見て、そのステータス情報がマップにすでにあるかどうか調べることにより行われる。ステータス情報がマップになければ、ステップ３１１４において、ペアのベクトルにステータス情報を取得するために使用する情報を加える。その情報をペアのベクトルに加えた後、ステップ３１０４に戻り、ステータス情報を取得するために使用される情報をさらに取得する。ステータス情報がすでに取得されていたら、ステップ３１１６において、すでに取得されたステータス情報の重みまたは優先度を、プロトコルを通して取得できるステータス情報の重みまたは優先度と比較する。ネットワーク装置のステータス情報のマップ中にあるステータス情報の重みまたは優先度がプロトコルにより取得されるステータス情報の重みまたは優先度よりも大きい場合、そのステータス情報を取得するために使用する情報はペアのベクトルに加えない。ステップ３１０４に戻り、ステータス情報を取得するために使用される情報をさらに取得する。マップ中のステータス情報の重みまたは優先度がそのプロトコルにより取得されるステータス情報の重みまたは優先度より大きくない場合、ステップ３１１４において、ステータス情報を取得するために使用される情報をペアのベクトルに加える。その情報をペアのベクトルに加えた後、ステップ３１０４に戻り、ステータス情報を取得するために使用される情報をさらに取得する。

図３１Bは、すべてのプロトコルを用いてネットワーク装置に関するステータス情報を取得するプロセスを説明するためのフローチャートである。図２８を参照して説明したようにプロトコルオブジェクトがサポートするネットワーク装置のベンダーとモデルに関する情報でそのプロトコルオブジェクトを初期化した後、そのプロトコルオブジェクトをネットワーク装置からステータス情報を取得するために使用することができる。そのプロトコルオブジェクトは、図２７B、２７C、２７Dを参照して説明した、データ構造を用いてベンダーとモデルについてステータス情報をいかに取得するかに関する情報を含む。図２７Aを参照して説明したCAbsProtocol２３０８へのポインタのベクトルを使用して、すべてのプロトコルオブジェクトについてステータス情報を取得する。フローチャートのプロセスは、そのベクトルを一回通る。ステップ３１２２において、CAbsProtocolへのポインタのベクトルからプロトコルオブジェクトを取得する。プロトコルオブジェクトは、ネットワーク装置にアクセスするためのネットワークプロトコル（例えば、SNMP、HTTP、FTP）の１つに対応する。ステップ３１２４において、ベクトルから取得できるプロトコルオブジェクトがあるかどうかチェックする。このチェックは、ベクトルの終わりに来たかどうか判断することによりなされる。プロトコルオブジェクトがもう取得できなければ、ステップ３１２６において、すべてのプロトコルオブジェクトを用いてネットワーク装置からステータス情報を取得し終わっていることになる。ベクトルから取得したプロトコルオブジェクトがあれば、ステップ３１２８において、そのプロトコルオブジェクトを用いてネットワーク装置のステータス情報を取得する。プロトコルオブジェクトを用いてステータス情報を取得した後、ステップ３１２２に戻り、他のプロトコルオブジェクトを用いてステータス情報をさらに取得する。

図３２Aは、プロトコルによりサポートされたネットワーク装置のベンダーとモデルに関する情報を保持するために使用するデータ構造を示す。また、図３２Bはそのデータ構造で使用する情報の一例を示す。サポートされたベンダーとモデル、およびそれからステータス情報をいかに取得するかに関するデータベースの情報の構成はプロトコルごとに異なる。それゆえ、異なるプロトコルの場合にサポートされたベンダーとモデルのデータベースからの取得方法は、プロトコルにより異なる。サポートされたベンダーとモデルへのアクセスを簡単にするため、すべてのプロトコルについて、この情報を格納しアクセスするためにマップ構造を使用することができる。図３２Aは、ベンダーモデルサポートマップ３２００を示す。マップ３２００へのキー３２０２は、プロトコルによりサポートされたベンダーとモデルに関する情報を含むストリングである。マップ３２００の値３２０４は、ベンダーとモデルに関する情報（ベンダーモデル識別番号等）を表すために使用することができる整数である。マップ構造を選択してプロトコルによりサポートされたベンダーとモデルに関する情報を載せた理由は、マップ構造がキーを容易に発見するルックアップメカニズムを有するからである。このように、ベンダーとモデルがマップにあるかどうかの判断は容易である。図３２Aではデータベースから取得した異なるプロトコルによるベンダーおよびモデルに関する情報を示したが、テキストファイルやスプレッドシートなど外部ソースから情報を取得してもよい。

図３２Bは、ベンダーモデルサポートマップ３２０６とそのサンプルエントリーを示す。マップ３２０６のキー３２０８はベンダー名、セパレータ「%%%%%」、及びモデル名を含むストリングである。例えば、ベンダー「Vendor1」とモデル「Model1」の場合、マップ３２０６のキー３２０８のストリングは「Vendor1%%%%%Model1」である。この例ではセパレータとして「%%%%%」を使用したが、ベンダー名及びモデル名の一部と混同されないセパレータなら何でもよく、例えば「@@@@@」でもよい。セパレータを使用する理由は、ベンダーとモデルを区別し、ベンダーとモデルをストリングから容易に取得するためである。マップ３２０６の値３２１０は整数１である。マップ３２０６の値３２１０はいかなる整数であってもよい。各プロトコルについてベンダーモデルサポートマップ３２００が保持される。

図３３は、プロトコルによりサポートされたベンダーとモデルをすべて含む、図３２Aのベンダーモデルサポートマップ３２００にサポートされたベンダーとモデルを加える方法を示すフローチャートである。ステップ３３０２において、データベースからベンダーとモデルを取得する。ベンダーとモデルをデータベースからいかに取得するかは、プロトコルごとに異なる。これはサポートされたベンダーとモデルを含むデータベースのテーブルに依存する。ステップ３３０４において、データベースから取得するベンダーとモデルがあるかどうかをチェックする。取得するものがなければ、ステップ３３０６において、ベンダーモデルサポートマップ３２００にサポートされたベンダーとモデルを入れる方法は終了する。ベンダーモデルサポートマップ３２００は、プロトコルによりサポートされたベンダーとモデルをすべて含む。サポートされたベンダーとモデルの情報を取得するためにデータベースにアクセスする必要はもうない。データベースから取得したベンダーとモデルがあるとき、ステップ３３０８において、ベンダーモデルサポートマップ３２００のキーとして使用するストリングを生成する。ストリングはベンダー名、セパレータ、及びモデル名により構成されている。前述の通り、セパレータはベンダー名やモデル名の一部と混同されないストリングであれば何でもよい。ステップ３３１０において、そのベンダー名、セパレータ、モデル名からなるストリングがベンダーモデルサポートマップ３２００にすでにあるかどうか判断する。そのストリングがマップ３２００にすでにあれば、ステップ３３０２において、データベースから他のベンダーとモデルを取得する。そのストリングがマップ３２００になければ、そのストリングと整数をマップ３２００に加える。そのストリングをマップ３２００に加えた後、ステップ３３０２において、データベースから他のベンダーとモデルを取得する。

図３４は、図３２Aのベンダーモデルサポートマップ３２００から一プロトコルによりサポートされたベンダーとモデルを取得する方法を説明するためのフローチャートである。ステップ３４０２において、キーのストリングをベンダーモデルサポートマップ３２００から取得する。ステップ３４０４において、マップ３２００から取得するためにまだキーがあるかどうかチェックする。キーがもうなければ、プロトコルによりサポートされたベンダーとモデルはすべて取得されており、ステップ３４０６において、ベンダーとモデルの取得を終了する。キーのストリングをマップ３２００から取得すると、ステップ３４０８において、セパレータの前のサブストリングを取得してベンダー名を取得する。ステップ３４１０において、セパレータの後のサブストリングを取得してモデル名を取得する。その後、ステップ３４０６において、ベンダーとモデルの取得が終了する。マップ３２００のエントリーをすべて通ると、プロトコルによりサポートされたベンダーとモデルがすべて取得できる。

図３５は、デバイスパッケージを示すパッケージ図である。このパッケージは、ネットワーク装置を表すソフトウェアオブジェクトを生成する役割を担っている。デバイスパッケージ１３００は、CDeviceFactory１３０２とCDevice１３０４の２つのクラスにより構成されている。クラスCDeviceFactory１３０２は、ネットワーク装置のソフトウェアオブジェクトを生成して初期化する役割を担っている。ソフトウェアオブジェクトの初期化には、ネットワーク装置のベンダー、モデル、一意的識別子を決定し、そのネットワーク装置にアクセスするために使用できるプロトコルを設定することが含まれる。ネットワーク装置にアクセスできないとき、そのネットワーク装置のソフトウェアオブジェクトは生成されない。クラスCDevice１３０４は、ネットワーク装置のソフトウェアオブジェクトを表す。CDevice１３０４は、ネットワーク装置に関する情報を保持し、そのネットワーク装置に関するステータス情報を取得する。CDevice１３０４は、HWaccessパッケージ１３０６（図２３を参照して説明した）を用いて、いろいろなプロトコルを通してネットワーク装置にアクセスし、その装置から情報を取得する。

図３６Aは、ネットワーク装置にアクセスするためにどのプロトコルを使用するかを決定するために、ネットワーク装置を表すソフトウェアオブジェクト（図３５を参照して説明したCDevice１３０４）により使用されるデータ構造を示す。CDevice１３０４はプロトコルパラメータマップ１４００を含む。マップ１４００のキー１４０２は、プロトコル（例えば、SNMP、HTTP、FTP）を表すストリングである。マップ１４００の値１４０４は、構造SParameterのベクトルである。構造SParameter１４０６は、与えられたプロトコルについて、ネットワーク装置にアクセスするために使用する情報を含む。SParameter１４０６は、ネットワーク装置のベンダーとモデルの特徴ではなく、そのネットワーク装置の特徴である情報を含んでいる。例えば、その情報は、SNMPによりそのネットワーク装置にアクセスするためのコミュニティ名であってもよく、FTPによりそのネットワーク装置にアクセスするためのユーザ名とパスワードであってもよい。これらは、SNMPまたはFTPによりいずれかのネットワーク装置にアクセスするために使用する共通情報である。DeviceODBCを通して取得されたデータベースからの情報は、ネットワーク装置にいろいろなプロトコルを通じてアクセスできるように、マップに加えられる。マップ中のプロトコルのエントリーは、そのプロトコルがそのネットワーク装置にアクセスできず、ベンダーとモデルがそのプロトコルによりサポートされていないとき、削除される。一部のプロトコルは、ベンダーとモデルがそのプロトコルによりサポートされていなくても、ネットワーク装置にアクセスする。例えばSNMPはそのようなプロトコルの例である。

図３６Bは、ネットワーク装置の図３６Aのプロトコルパラメータマップ１４００のサンプルデータを示している。ネットワーク装置は、２つのプロトコルSNMPとFTPを用いてステータス情報を取得する。ネットワーク装置のマップ１４１０は、キー「SNMP」と「FTP」の２つのエントリーを含む。SNMPを用いてネットワーク装置にアクセスするには、コミュニティ名が必要である。SNMPのSParameterのベクトルは、コミュニティ名に関する情報を含む。１つのSParameterにパラメータ名COMMUNITYとパラメータ値「private」を用いて、ネットワーク装置へのアクセスを可能にする。ネットワーク装置にFTPを用いてアクセスするためには、ユーザ名とパスワードが必要である。FTPの場合、SParameterのベクトルは、ユーザ名とパスワードに関する情報を含む。１つのSparameterについてパラメータ名USERNAMEとパラメータ値「abc」を用い、他のSparameterについてパラメータ名PASSWORDとパラメータ値「xyz」を用い、ネットワーク装置へのアクセスを可能とする。

図３７は、図３６Aのプロトコルパラメータマップ１４００をいかに更新して、どのプロトコルを使用してネットワーク装置からステータス情報を取得するかを説明するフローチャートである。図３７のステップを実行し、プロトコルについてネットワーク装置のベンダー名とモデル名を取得する。ステップ３７０２において、プロトコルを用いてネットワーク装置にアクセスできるかチェックする。マップ１４００の情報を用いてそのプロトコルを通じてネットワーク装置にアクセスする。そのプロトコルを通じてそのネットワーク装置にアクセスできない場合、ステップ３７０４において、プロトコルパラメータマップ１４００からそのプロトコルを削除し、ステップ３７１４において、マップ１４００の更新を終了する。そのネットワーク装置にそのプロトコルを通じてアクセスできるとき、ステップ３７０６において、そのネットワーク装置のベンダーをそのプロトコルを用いて取得できるかどうかチェックする。ベンダーを取得できないとき、ステップ３７０７において、ジェネリックベンダーがそのプロトコルでサポートされているかどうかチェックする。プロトコルがジェネリックベンダーをサポートしているとは、プロトコルがその装置のベンダーを取得できないか、またはサポートしていないときでも、プロトコルがすべての装置に共通なステータス情報（共通ステータス情報）を取得することできることを意味する。そのプロトコルによりジェネリックベンダーがサポートされていないとき、ステップ３７０４において、そのプロトコルはプロトコルパラメータマップ１４００から削除され、ステップ３７１４において、マップ１４００の更新が終了する。そのプロトコルがジェネリックベンダーをサポートしているとき、そのプロトコルはプロトコルパラメータマップ１４００に残され、ステップ３７１４において、マップの更新が終了する。ステップ３７０６においてベンダーを取得できる場合、ステップ３７０８において、そのネットワーク装置のベンダーがそのプロトコルでサポートされているかどうかチェックする。ベンダーがそのプロトコルによりサポートされていないとき、ステップ３７０７において、ジェネリックベンダーがそのプロトコルによりサポートされているかどうかチェックする。ステップ３７０７以降のステップのシーケンスは上で説明した。

ベンダーがそのプロトコルでサポートされているとき、ステップ３７１０において、そのネットワーク装置のモデルがそのプロトコルを用いて取得できるかどうか判断する。モデルを取得できないとき、ステップ３７１１において、ジェネリックモデルがそのプロトコルでサポートされているかどうかをチェックする。プロトコルがジェネリックモデルをサポートしているとは、プロトコルがその装置のモデルを取得できず、またはサポートしていなくても、そのプロトコルがベンダーのすべての装置に共通なステータス情報（特定ベンダーステータス情報）を取得できることを意味する。ジェネリックモデルをプロトコルがサポートしていないとき、ステップ３７０４において、そのプロトコルはプロトコルパラメータマップ１４００から削除され、ステップ３７１４において、マップ１４００の更新が終了する。ジェネリックモデルがプロトコルによりサポートされているとき、そのプロトコルはプロトコルパラメータマップ１４００に残され、ステップ３７１４においてマップの更新を終了する。ステップ３７１０でモデルを取得できるとき、ステップ３７１２において、そのネットワーク装置のモデルがプロトコルによりサポートされているかどうか判断する。そのモデルがプロトコルでサポートされていないとき、ステップ３７１１で、ジェネリックモデルをそのプロトコルがサポートしているかどうかチェックする。ステップ３７１１に続くステップのシーケンスについてはすでに説明した。そのモデルがプロトコルによりサポートされているとき、そのプロトコルを用いてネットワーク装置のステータス情報を取得でき、ステップ３７１４でプロトコルパラメータマップ１４００の更新は終了する。ベンダーとモデルが取得またはサポートされていないとき、そのプロトコルはプロトコルパラメータマップ１４００から削除され、ステータス情報の取得には使用されない。プロトコルに応じて図３７に示したプロセスにはバリエーションがある。HTTPとFTPはフローチャートの説明通りだが、SNMPは、ベンダーがサポートされてもモデルとジェネリックモデルがサポートされていない場合でも、サポートされ、ステータス情報を取得するために使用することができる。

上で説明したように、ベンダーとモデルが取得またはサポートされていなくても、SNMPによりステータス情報をネットワーク装置から取得できる。ネットワーク装置がSNMPをサポートし、SNMPによりアクセスできる限り、そのネットワーク装置の管理情報ベース（MIB）から情報を取得することができる。ステップ３７０２において、ネットワーク装置がSNMPを通じてアクセスできないとき、ステップ３７０４で、SNMPプロトコルはプロトコルパラメータマップ１４００から削除される。しかし、そのネットワーク装置にSNMPでアクセスできる場合、ベンダーやモデルが取得及びサポートされているかどうかにかかわらず、SNMPプロトコルはプロトコルパラメータマップ１４００に残される。SNMPをサポートするネットワーク装置はMIBを提供し、リモートシステムはそのネットワーク装置から情報を常に取得可能である。しかし、ネットワーク装置から取得可能な情報のタイプと数は、ベンダーとモデルが取得およびサポートされるかどうかに依存する。ベンダーとモデルが取得され、かつ知られていれば、SNMPによりネットワーク装置からより多くの情報を取得することができる。ベンダーとモデルを取得できなくても、SNMPはすべての装置が提供できる情報は取得可能である。例えば、システムの説明やシステムが動作している時間等は取得可能である。SNMPは次の３つの条件の下でネットワーク装置から情報を取得するために使用できる：（１）ベンダーとモデルがサポートされている；（２）ベンダーはサポートされているが、モデルはサポートされていない；（３）ベンダーもモデルもサポートされていない。HTTPとFTPは、SNMPのような特徴は有していない。SNMPは、すべてのネットワーク装置が従うことができる標準MIBを有しており、情報を取得できるが、ウェブページとFTPファイルは、ベンダーとモデルが異なるネットワーク装置では異なる。ネットワーク装置が情報を取得するために従うウェブページとFTPファイルの標準はない。

図３８Aないし３８Cを参照して上で説明した問題を解決するため、本発明の実施形態は、被監視装置のHTMLファイルから情報を抽出する複数の方法を可能とし、HTMLファイルのフォーマットに応じて、さらに別の方法の拡張を可能とするように設計されている。HTTPプロトコルを例に挙げて説明するが、ここに説明する方法は他のプロトコルにも適用可能である。

図３９は、図２３のプロトコルパッケージのそれぞれで使用されるパッケージを示すパッケージ図であり、ここでXXXはSNMP、HTTP、またはFTPのいずれかである。抽象クラスCabsProtocolは、装置から情報を取得するインターフェイス関数を提供するが、その情報を取得するメソッドは提供しない。CabsProtocolから派生するクラスは、装置から情報を取得する新しいプロトコルを追加しやすくする方法を提供する。CXXXProtocolImp1クラスは、XXXパッケージのインターフェイスであり、そのパッケージ内の他のすべてのクラス／パッケージを管理する。CXXXProtocolImp1はCabsProtocolから派生するので、このクラスは与えられたプロトコルで装置から情報を取得する方法を提供する。XXXaccessパッケージは、その装置にアクセスしてその装置から情報を取得するプロトコルを実装する。XXXODBCパッケージは、サポートデータベースからプロトコルサポート情報を取得する。この情報には、そのプロトコルがサポートするベンダー及びモデルの情報、その装置からいかにしてベンダー、モデル、及び一意的識別子に関する情報を取得するかの情報、及びその装置からステータス情報をいかに取得するかの情報が含まれる。図２４、２５、及び２６は、SNMP、HTTP、及びFTPの場合に具体的にこのパッケージ図を使用したものである。装置からステータス情報を取得するために使用する新しいプロトコルはいずれも、そのパッケージ図のこの構造に従う。新しいプロトコルの１つとしてウェブサービスがある。また、プロトコルの異なる実装もパッケージ図のこの構造に従うことができる。

図４０は、図２３のプロトコルパッケージのそれぞれで使用される別のパッケージ図であり、ここでXXXはSNMP、HTTP、またはFTPのいずれかである。このパッケージ図はどのプロトコルにも適用可能であるが、HTTPプロトコルを例として説明する。このパッケージ構造により、装置から情報を取得するプロトコルの新しい実装の拡張が可能となる。情報を取得するためのプロトコルの既存の実装が情報の新しいフォーマット（例えば、図３８B及び３８Cに示したウェブページの例）に対してうまく機能しない場合、この拡張が必要である。このパッケージ図は、図３９に示したように、抽象クラスCAｂｓProtocolも使用する。CXXXProtocolクラスはCabsProtocolから派生する。CXXXProtocolは、XXXパッケージに対しインターフェイスを提供し、装置から情報を取得する異なる方法に対応するすべてのクラスを管理する。

クラスCXXXProtocolImp1とCXXXProtocolImp2は、同じプロトコルを用いて情報を取得する異なる方法を実装する。CXXXProtocolImp1クラスは、装置から情報を取得するための実装を提供し、パッケージXXXaccess1とXXXODBC1を用いる。XXXaccess1パッケージは、その装置にアクセスしてその装置から情報を取得するプロトコルを実装する。XXXODBC1パッケージは、データベースからプロトコルサポート情報を取得する。この情報には、そのプロトコルがサポートするベンダー及びモデル、その装置からいかにしてベンダー、モデル、及び一意的識別子に関する情報を取得するかの情報、及びその装置からステータス情報をいかに取得するかの情報が含まれる。CXXXProtocolImp2クラスは、CXXXProtocolImp1と同じプロトコルを用いて装置から情報を取得するための他の実装である。CXXXProtocolImp2は、パッケージXXXaccess2とXXXODBC2を使用する。XXXaccess2パッケージは、その装置にアクセスしてその装置から情報を取得するプロトコルを実装する。XXXODBC2パッケージは、XXXODBC1と同様に、データベースからプロトコルサポート情報を取得する。このパッケージの設計により、プロトコルの新しい実装が可能となる。新しい実装が必要なとき、そのプロトコルを用いて装置にアクセスし、サポートデータベースから情報を取得するために、他の実装クラスがサポートパッケージとともに追加される。本発明の実施形態は、新しい実装の新しい装置とともに、すでにサポートされている装置から情報を取得するための既存の実装でも機能する。

SNMPとFTPのパッケージ図は、図３９のパッケージ構造に従い、図２４と２６に示されている。このシステムのHTTPのパッケージ図は、図４０のパッケージ構造に従う。

図４１は、HTTPの場合のパッケージ図の第２の実施形態を示す図であり、図２５と４０に示したパッケージ図に基づく。このパッケージは、図３８Aないし３８Cに示したウェブページから情報を取得するためのHTTPの２つの実装を含んでいる。このパッケージは、図３９を参照して上で説明したように、抽象クラスCabsProtocolを使用する。CHTTPProtocolクラスはCabsProtocolから派生する。CHTTPProtocolは、HTTPパッケージのためのインターフェイスであり、装置から情報を取得するHTTPの２つの異なる実装に対応する。FirstHTTPImplementationパッケージは、図３８Aに示した装置のウェブページから情報を取得するためのHTTPの実装である。FirstHTTPImplementationパッケージは、上で説明したように、情報を取得するためのHTTPの実装に対応する。FirstHTTPImplementationパッケージは、FirstHTTPODBCパッケージを用いて、サポートされた装置と、その装置から情報をいかに取得するかに関するサポート情報をデータベースから取得する。SecondHTTPImplementationパッケージは、図３８B及び３８Cに示したような装置のウェブページから情報を取得するためのHTTPの他の実装を提供する。SecondHTTPImplementationパッケージは、SecondHTTPODBCパッケージを用いて、サポートされた装置と、その装置から情報をいかに取得するかに関するサポート情報をデータベースから取得する。SecondHTTPIMplementationパッケージによるHTTPの第２の実装は、図３８B及び３８Cを参照して上に説明したように、同じキーを異なるステータス情報を取得するために用いる時に、装置から情報を取得する問題を処理する。HTTP_HTMLToolをパッケージとして示したが、２つの実装パッケージにより使用されるオブジェクトを含むネームスペースである。ネームスペースを用いることにより、それが含むオブジェクトをHTTPパッケージ内で使用できる。これにより、HTTPのすべてのクラス及びパッケージがネームスペースのオブジェクトを共有することができる。HTTPパッケージは、HTTPが装置に関する情報を取得するためのインターフェイスを提供する抽象クラスCAbsHTTPImplementationを含む。CAbsHTTPImplementationから派生したクラスは、その情報を実際に取得する方法を提供する。FirstHTTPImplementationパッケージとSecondHTTPIMplementationパッケージは、情報を取得する方法を規定するCAbsHTTPImplementationから派生したクラスを含む。このHTTPパッケージの設計により、将来の拡張が可能である。現在の実装が装置のウェブページから情報取得できない場合、一実装とODBCパッケージを追加することにより、新しい実装の設計を追加することができる。

図４２は、抽象クラスCAbsHTTPImplementationのクラス仕様を示す図である。この抽象クラスは、装置から情報（すなわち、ステータス情報、ベンダー名、及び一意的識別子）を取得するためのインターフェイスを提供する。しかし、その抽象クラスは、情報を取得するための実際の方法は提供しない。CAbsHTTPImplementationから派生したクラスがこの情報を取得する方法を提供する。それゆえ、CAbsHTTPImplementationから派生した各クラスは、この情報を取得する異なる方法を提供することができる。よって、抽象クラスを使用することにより設計が柔軟になる。

図４３と４４は、図４１のCHTTPProtocolクラスのデータ構造m_ImplementationMapとm_VendorModelSupportMapを説明する図である。図４３において、マップ構造m_ImplementationMapのキーは、CAbsHTTPImplementationクラスへのポインターである。キーは抽象クラスCAbsHTTPImplementationへのポインターであるが、そのポインタ−は実際にはCAbsHTTPImplementationの派生クラスをポイントする。図４３は、CAbsHTTPImplementationの２つの派生クラスであるCFirstHTTPImplementationとCSecondHTTPImplementationに対応するマップのサンプルエントリーを示す図である。マップの値は、キーでポイントされた実装クラスが使用されるかどうかを示すブール値である。このマップは、システムがスタートする際、CHTTPProtocolのコンストラクタがプライベート関数initImplementationMap()を呼び出す時に初期化される。このプライベート関数は、情報を取得するHTTPのすべての異なる実装をマップにエントリーし、そのブール値を偽に設定する。どの装置を監視するかを判断するディスカバリープロセス（初期化）中に、どの実装が必要かを判断する。装置から情報取得するために一実装が必要な場合、そのブール値を真に設定する。ディスカバリープロセスが完了した後、対応するブール値が偽である実装はマップから削除される。

図４４は、サンプルエントリーを有するマップ構造m_VendorModelSupportMapを示す図である。このマップを用いて、被監視装置のベンダーとモデルの情報を取得するために、HTTPのどの実装を使用するかを判断する。そのマップのキーは、装置のベンダー名を表すストリングである。そのキーに対応する値は他のマップである。内側のマップにおいて、キーは装置のモデル名のストリングであり、値は抽象クラスCAbsHTTPImplementationへのポインターである。m_ImplementationMapに関してのみ、そのポインターは、実際にはCAbsHTTPImplementationの派生クラスをポイントし、その派生クラスが装置のモデルに対するHTTPの実装を提供する。実際、そのポインターは、マップm_ImplementationMapのポインターの１つに対応する。マップm_VendorModelSupportMapには、システムの初期化の際、そのシステムがどの装置を監視するか決定するにつれ、エントリーが追加される。

図４５は、CHTTPProtocolの関数canAccessIP()を示すフローチャートである。その関数canAccessIP()は、ベンダーとモデル名を取得でき、そのベンダーとモデルがHTTPをサポートしている場合、マップm_VendorModelSupportMapに実装を追加する。この関数は、システムが監視している各装置に対して呼び出され、その装置がHTTPによりサポートしているかどうかを決定する。この関数は、その装置から情報を取得するためにどのHTTP実装を用いるかを決定する。この関数は、マップm_ImplementationMapについてループとなっており、与えられた実装を用いて装置のベンダー、モデル、及び一意的識別子を取得するまで、そのマップのキーがポイントした実装を使用する。

図４６は、CHTTPProtocolの関数obtainStatus()を示すフローチャートである。その関数obtainStatus()は、マップm_VendorModelSupportMapを使用する。HTTPの適当な実装は、入力されたベンダーとモデルに基づいて使用される。

図４７は、FirstHTTPImplementationパッケージを示すパッケージ図である。このパッケージは、装置のウェブページ（図３８Aのウェブページ等）から情報を取得するためにHTTPを実装する。クラスCFirstHTTPImplementationは、このパッケージのインターフェイスであり、装置のウェブページから情報を取得する一メソッドを実装する他のクラス及びパッケージを管理する。CFirstHTTPImplementationは、CAbsHTTPImplementationから派生したクラスである。アペンディックス１は、CFirstHTTPImplementationの関数、定義タイプ、クラス属性を示す。FirstHTTPODBCパッケージとHTTP_HTMLToolパッケージは、図４１を参照して上に説明した。クラスCFirstHTMLProcessorは、装置のウェブページを処理して、所望の情報を取得する。CFirstHTMLProcessorは、特定フォーマットのウェブページのテキストを処理する方法を含み、所望の情報を取得する。アペンディックス3は、CFirstHTMLProcessorの関数、定義タイプ、クラス属性を示す。

図４８は、FirstHTTPImplementationパッケージを示すパッケージ図である。このパッケージは、装置のウェブページ（図３８Bと３８Cのウェブページ等）から情報を取得するためにHTTPを実装する。より具体的に、このパッケージは、情報を特定するためのキーワードが複数回現れるウェブページを処理する。クラスCSecondHTTPImplementationは、このパッケージのインターフェイスであり、装置のウェブページから情報を取得する他のメソッドを実装する他のクラス及びパッケージを管理する。CSecondHTTPImplementationは、CAbsHTTPImplementationから派生したクラスである。アペンディックス2は、CSecondHTTPImplementationの関数、定義タイプ、及びクラス属性を示す。SecondHTTPODBCパッケージとHTTP_HTMLToolパッケージは、図４１を参照して上に説明した。クラスCSecondHTMLProcessorは、装置のウェブページを処理して、所望の情報を取得する。このクラスは、特定フォーマットのウェブページのテキストを処理する方法を含み、所望の情報を取得する。より具体的に、このクラスは、情報を特定するためのキーワードが複数の箇所に現れるウェブページを処理する。アペンディックス4は、CSecondHTMLProcessorの関数、定義タイプ、クラス属性を示す。

図４９は、装置のウェブページ（図３８Aに示したウェブページ等）から情報を取得するためのHTTPの第１の実装に対するサポートデータベースのテーブルを示す図である。これらのテーブルは、図２１に示したテーブルに相当するが、２カ所変わっている。第１に、図２１のEnumCorrespondenceを除いて、テーブル名に「_1」を付加した。「_1」を用いて、そのテーブルが装置から情報を取得するためのHTTPの第1の実装に対応することを示す。第２に、同じベンダーが１モデルに対して１つ以上のウェブページを有する場合もあるので、HTTPVendorModel_1は他のテーブルに一意的には関連しない。

図５０は、装置のウェブページ（図３８Bと３８Cに示したウェブページ等）から情報を取得するためのHTTPの第２の実装に対するサポートデータベースのテーブルを示す図である。これらのテーブルは、名前の終わりが１ではなくて２であることと、HTTPStatusKeyValueのテーブル名に「Precondition（前提条件）」が加えられていることを除いて、図４９のサポートデータベースのテーブルと同じ名前を有する。「２」を用いて、そのテーブルがHTTPの第２の実装に対応することを示している。第２の実装のテーブルは、３つのテーブルHTTPVendorModel_2、HTTPUniqueIDWebPage_2、HTTPPreconditionStatusKeyValue_2にsPreconditionエントリーが追加されている点で、第１の実装のテーブルと異なる。所望の情報を特定するキーワードがウェブページ上で２回以上現れる時、sPreconditionエントリーを用いてそのウェブページから情報を取得する。sPreconditionの使用について以下により詳しく説明する。sPreconditionが空の場合、所望の情報を取得する第２の実装のプロセスは、その所望の情報を取得する第１の実装のプロセスと同じである。

ここで、前提条件（Precondition）について説明する。図３８Bを参照して説明したように、画像化部（Imaging Units）のBlackの寿命をステータス情報として取得したい場合、従来の技術では、ウェブページ上で単にBlackというストリングのみを探し、それに対応する値をステータス情報としていたので、最初に出てくるトナーカートリッジのBlackに対応する値「Ok」を間違って取得してしまう。そこで、画像化部（Imaging Units）というストリングが事前にあることを前提条件としてBlackというストリングを探し、それに対応する値「１００％」を取得することにより、画像化部のBlackの寿命をステータス情報として正しく取得することができる。

図５１は、FirstHTTPOFDBCパッケージを示すクラス図である。このパッケージは、装置のウェブページから情報を取得するために、図４７に示したFirstHTTPImplementationパッケージにより使用されるサポートデータベースの情報へのアクセスを提供する。CHTTPODBC_1クラスは、このパッケージへのインターフェイスであり、サポートデータベースのテーブルから適当な情報を取得するために他のクラスを管理する。CXXXData_1クラスとそれに対応するCXXXTable_1クラスは、テーブルから情報を取得するために、図４９のサポートデータベースのXXXテーブルへのアクセスを提供する。

図５２は、SecondHTTPOFDBCパッケージを示すクラス図である。このパッケージは、装置のウェブページから情報を取得するために、図４８に示したSecondHTTPImplementationパッケージにより使用されるサポートデータベースの情報へのアクセスを提供する。CHTTPODBC_2クラスは、このパッケージへのインターフェイスであり、サポートデータベースのテーブルから適当な情報を取得するために他のクラスを管理する。CXXXData_2クラスとそれに対応するCXXXTable_2クラスは、テーブルから情報を取得するために、図５０のサポートデータベースのXXXテーブルへのアクセスを提供する。

装置のウェブページから所望の情報を取得するFirstHTTPImplementationパッケージにより使用される方法は、2002年12月26日に出願した関連出願第10/328,026号「遠隔監視された装置のウェブページから情報を取り出すために構造のベクトルを用いる方法」に記載されている。その内容は、ここに参照により援用する。FirstHTTPImplementationパッケージの方法は、最初に出てきたキーワードを用いて所望の情報を特定するが、こうして得られた情報は、場合によっては正しくない。

上で説明したように、第1のHTTP実装が処理できない問題を解決するため、新しいシステムは以下のことを実現するように設計されている：（１）所望の情報を特定するために使用するキーワードが２回以上出てくるウェブページから所望の情報を正しく取得する新しいメソッドを追加する；（２）２つのメソッド（FirstHTTPIMplementationとSecondHTTPImplementation）が所望の情報を取得できない新しいウェブページがある場合、新しいメソッドの追加を可能とする；及び（３）システムが装置のウェブページから以前取得した所望の情報を取得できるようにバックワードコンパチブルとする。

図４０と４１によるHTTPパッケージの設計により、これらの望ましい特徴が可能となる。図４１にSecondHTTPIMplementationパッケージを加え、サポートデータベースに図５０のテーブルを加えることにより、所望の情報を特定するキーワードが複数回出てくる装置のウェブページから情報を取得するHTTPの実装が追加される。図４１の抽象クラスCAbsHTTPImplementationと図４０のパッケージ構造により、装置のウェブページから情報を取得するHTTPの新しい実装を追加することができる。いかにしてウェブページから情報を取得するかに関する情報を提供する新しいテーブルがデータベースに追加される。図４１に示したCHTTPProtocolは、ウェブページから情報を取得するHTTPの適当な実装を管理し、使用する。図４５と４６は、CHTTPProtocolがHTTPの異なる実装をいかに管理し使用するかを説明するフローチャートである。本システムの実施形態は、新しいウェブページのための新しいHTTPの実装とともに、以前のウェブページから情報を取得できるように、以前のHTTPの実装も含み、使用する。

図５３は、CSecondHTTPImplementationのマップ構造m_VendorModelWebInfoMapを示す図である。このマップ構造は、装置のウェブページからその装置のステータス情報を取得するために、HTTPの第２の実装により使用される。そのマップのキーは、装置のベンダー名を表すストリングである。そのマップの値は、与えられたモデルの装置ウェブページからステータス情報を取得するために用いられる情報を含む他のマップである。内部マップのキーは、装置のモデル名のストリングであり、その値は、ウェブページに関する情報とウェブページからステータス情報をいかに取得するかに関する情報を含む構造SwebPageInfoのベクトルである。構造SwebPageInfoは、ウェブページから一片の情報を取得するために必要なすべての情報を提供する構造SpreconKeyValueInfoを含む。SPreconKeyValueInfoは、ストリング属性sPreconditionを加えてHTTPの第１の実装を用いてウェブページから一片の情報を取得するために使用する構造SKeyValueInfoと同様である。アペンディックス５は、SpreconKeyValueInfoの構造使用を示す。HTTPの第１の実装は構造SKeyValueInfoを使用し、HTTPの第２の実装は構造SPreconKeyValueInfoを使用する。マップ構造には、図５０に示したように、HTTPの第２の実装のサポートデータベースのテーブルからの情報がエントリーされるCSecondHTTPImplementationは、SecondHTTPODBMパッケージを用いてデータベースのテーブルから情報を取得する。

図５４は、CSecondHTTPImplementationのマップ構造m_ModelWebInfoForVendorMapを示す図である。このマップ構造は、装置のウェブページからその装置のモデルを取得するために、HTTPの第２の実装により使用される。そのマップのキーは、装置のベンダー名を表すストリングである。値は、モデル名を含むウェブページとそのモデル名をいかに取得するかに関するベンダーのサポートされたモデルの情報を含むペアのベクトルである。マップ構造には、図５０に示したように、HTTPの第２の実装のサポートデータベースのテーブルからの情報がエントリーされる
図５５は、CSecondHTTPImplementationのマップ構造m_VendorModelUniqueIDInfoMapを示す図である。このマップ構造は、装置のウェブページからその装置の一意的識別子を取得するために、HTTPの第２の実装により使用される。一意的識別子は、装置を特定するストリング（例えば、シリアルナンバーまたはMACアドレス等）である。そのマップのキーは、装置のベンダー名を表すストリングである。その値は、その装置のモデルの一意的識別子を取得するために使用される情報を含む他のマップである。内部マップのキーはそのモデル名のストリングであり、値はウェブページ及びそのウェブページから一意的識別子をいかに取得するかに関する情報を含む構造SwebPageInfoである。マップ構造には、図５０に示したように、HTTPの第２の実装のサポートデータベースのテーブルからの情報がエントリーされる
図５６は、CSecondHTTPImplementationの関数obtainStatus()を示すフローチャートである。この関数は、マップ構造m_VendorModelWebInfoMapを用いて装置のウェブページからステータス情報を取得するために使用される。obtainStatus()で呼ばれた関数selectEntries()は、HTTPを解して装置からどのステータス情報を取得するかを決定する。装置のベンダーとモデルに対応する情報を取得する。selectEntries()は、どの情報を取得するかに関する情報を含むベクトルloc_InputVectorを返す。一部の情報はステータスマップinOut_Dataにすでに存在する。その場合、HTTPにより取得されるステータス情報がステータスマップ中のステータス情報より高い優先度（または重み）を有する場合、selectEntries()はこの情報をベクトルloc_InputVectorに入れてHTTPによりそのステータス情報が確実に取得されるようにする。obtainStatus()で呼ばれたobtainDataFromHTMLFile()は、ウェブページのすべてのステータス情報を取得する。obtainDataFromHTMLFile()は、クラスCSecondHTMLProcessorのオブジェクトを用いて、ウェブページからのデータを処理してステータス情報を取得する。この関数により使用されるメソッドは、第１の実装により使用されるメソッドと同様である。第２の実装は構造SPreconKeyValueInfoを使用し、一方、第１の実装は構造SKeyValueInfoを使用する点で異なる。

図５７と５８は、ベクトル構造m_KeyValueVectorとm_LocateValueVectorを示す。これらのベクトル構造は、HTTPの第２の実装を用いてウェブページからのデータを処理して所望の情報を取得するために、CSecondHTMLProcessorで使用される。図５７において、ベクトルm_KeyValueVectorは、被監視装置のウェブページから各種のステータス情報をいかに取得するかに関する情報を含む。構造SPreconKeyValueInfoは、ウェブページのステータス情報を特定し取り出すために使用される情報を提供する。図５８において、ベクトルm_LocateValueVectorは、ステータス情報を取り出すためにウェブページから取得する情報の処理に使用される。２つのベクトルは、ステータス情報を取り出すプロセスでともに使用される。m_KeyValueVectorとm_LocateValueVectorの間には１対１の対応関係がある。m_KeyValueVectorの最初のエントリーをm_LocateValueVectorお最初のエントリーとともに用いて、ステータス情報を取得する。以下、２つのベクトルの残りのエントリーも同様である。

図５７と５８のベクトル構造は、HTTPの第１の実装に使用されるベクトル構造と同様である。これは、関連出願第10/328,026号に記載した。図５９は、上記関連出願第10/328,026号の図２６を修正したものである。上記関連出願からの変更点は、例えば、構造名（CではなくSを用いる）とSKeyValueInfoの属性メンバーの名称を変更したことである。CFirstHTMLProcessorは、上記関連出願で説明したメソッドを用いて、これらの２つのベクトル構造を用いてウェブページからステータス情報を取得する。この関連出願第10/328,026号の内容は、ここに参照により援用する。

図６０は、図５７と５８のベクトル構造を設定するために使用するCsecondHTMLProcessorの関数initDataSearchInfo()のフローチャートである。この関数は、ウェブページからステータス情報を取得する前にCSecondHTMLProcessorの関数obtainDataFromHTMLFile()により呼び出される。

ベクトルm_KeyValueVectorの各SPreconKeyValueInfoについて、ベクトルm_LocateValueVectorに入れられたSLocateValueInfoがある。SPreconKeyValueInfoのm_sPrecondition属性ストリングが空であるとき、SLocateValueInfoの属性m_bPreconditionOKは真に設定され、それによりステータス情報を特定する前提条件はないことを示す。m_sPreconditionストリングが空でない場合、m_bPreconditionOKを偽に設定する。

HTTPの第1の実装と同様に、HTTPの第2の実装は、HTML文書のテキスト（タグ無しエレメント）からステータス情報を取得する。アペンディックス６は、図３８Bに対応するウェブページからステータス情報のHTML文書の一部を示す。HTML文書のテキストは太字になっている。図６１は、ステータス情報を取得するためのCSecondHTMLProcessorの関数searchAndObtainDataFromValue()によるテキスト処理を示すフローチャートである。この関数は図５７と５８のベクトル構造を使用する。この関数は、ウェブページからテキスト（タグ無しエレメント）を取得する時にCSecondHTMLProcessorの関数obtainDataFromHTMLFile()により呼び出される。searchAndObtainDataFromValue()のプロセスは、ステータス情報を特定するキー値が複数回出てくる場合を処理する。その場合には、前提条件（precondition）ストリングを使用する。プロセスは、最初に前提条件（precondition）ストリングを探す。前提条件（precondition）ストリングが見つかると、キー値を探す。キー値が見つかると、ステータス情報を取り出すことができる。ウェブページ上の同じキー値に対する各種のステータス情報は、一意的な前提条件（precondition）ストリングを有する。アペンディックス６の例を参照して、キー値「ブラック」を用いて、ブラックトナーカートリッジ及びブラック画像化ユニットのステータスを見つける。前提条件（precondition）を使用しないと、「Ok」は、ブラックトナーカートリッジとブラック画像化ユニットの両方のステータスである。ブラックトナーカートリッジのステータスに対して「トナーカートリッジ」、及びブラック画像化ユニットのステータスに対して「画像化ユニット」という前提条件（precondition）を用いると、両方で正しいステータス情報を取得できる。

SprecondKeyValueInfoのm_sPreconditionが空の場合、それに対応するm_bPreconditionOKが真となり、SPreconKeyValueInfoのステータス情報を取得するプロセスはHTTPの第1の実装を使用してステータス情報を取得するプロセスと完全に同じである。

本システムの実施形態は、装置のMIBのすべての情報を取得するためにSNMPGetとGetNextの両方のリクエストを実装する。本願発明者による以前の出願の実施形態では、SNMPのGetNextリクエストだけを使用していたため、システムが装置のMIBのすべての情報にアクセスする能力を制限していた。以前のシステムでは、データベースは、装置のMIBからどの情報を取り出すかを決定するオブジェクト識別子のストリングを含んでいた。本発明の好ましい実施形態においては、オブジェクト識別子のストリングは、オブジェクト識別子とともにSNMPリクエストの種類に関する情報を含む。そのストリング中のオブジェクト識別子には、Getリクエストを実行すべきことを示すため「G」を先頭に付加し、GetNextリクエストを実行すべきことを示すため「N」を先頭に付加する。オブジェクト識別子の前に文字がなければ、デフォルトでGetNextリクエストを実行する。オブジェクト識別子の前に「G」と「N」以外の文字がある場合、リクエストは実行されない。オブジェクト識別子のストリングが空であるか、または文字「N」だけを含む場合、GetNextリクエストを実行する。

図６２は、SNMPを用いて異なるベンダーとモデルの装置から情報を取得するために用いられるサポートデータベースのテーブルのサンプルエントリーを示す図である。

図６３は、SNMPパッケージのクラス図であり、図２４に示したパッケージ図に基づく。留意すべきことは、オブジェクト識別子のストリングにリクエストのタイプが組み込まれていることである。

図６４は、SNMPaccessパッケージを示すクラス図である。CSNMPaccessクラスはこのパッケージのインターフェイスであり、データを取得するために使用するSNMPリクエストのタイプを決定する。クラスCSNMP、CSnmpSession、及びCsnmpUtilityは、装置のMIBから情報を取得するためにSNMPプロトコルを実装する。

図６５は、SNMP要求タイプとオブジェクト識別子の情報を含む文字列のSNMP要求の処理を示すフローチャートである。プロセスは、CSNMPaccessの関数obtainValue()に続く。SNMPリクエストがうまくいくと、obtainValueFromXXXRequest()はout_sValueに値を割り当てる。ここで、XXXはGetまたはGetNextである。out_sValueについて空のストリングが返される。

ネットワークに接続された監視が必要な少数の装置について本発明を示したが、当然のことながら、本発明の精神と範囲から逸脱することなく、ネットワークに接続される装置の数はいくつでもよい。また、本発明は、いろいろな装置を監視かつ制御する必要があるような家庭環境に適用してもよい。

本発明の実施形態によれば、マルチベンダー環境において、いろいろな装置の監視が可能となり、特定のプライベートなマネージメント情報ベース（MIB）情報を有さなくても、詳細な情報を読み出し、ユーザが理解しやすく扱いやすい方法で表示することができる。さらにまた、読み出した情報は、SMTP、FTP、ウェブサービス等のいろいろな方法を用いて再配信することができる。

本発明のコントローラは、本発明の教示によりプログラムされた、従来の汎用デジタルコンピュータまたはマイクロプロセッサであり、コンピュータ技術の当業者には明らかである。熟練したプログラマーは本開示の教示に基づき容易に適当なソフトウェアのコーディングをでき、ソフトウェア技術の当業者には明らかである。本発明は、特定用途用集積回路や従来のコンポーネント回路を適当に配線して相互接続することによっても実施することができ、これは当該分野の当業者には明らかである。

本発明はコンピュータをプログラムし本発明のプロセスを実行させる命令を含むコンピュータプログラム、およびそのコンピュータプログラムが格納された記録媒体を含む。記録媒体には、フレキシブルディスク、光ディスク、CD-ROM、光磁気ディスク、ROM、RAM、EPROM、EEPROM、磁気または光カード、その他の電子的命令を格納するのに好適ないかなる媒体も含む。

上記の教示を考慮して本発明を様々に修正したり、バリエーションを考えたりすることができる。従って、当然のことながら、添付したクレームの範囲内で、ここに具体的に説明したものとは別の実施形態により本発明を実施することができる。

添付した図面を参照して以下の詳細な説明を読めば、本発明とその結果得られる多くの利点とをよりよく理解し、獲得することができる。
インターネットを介してコンピュータおよびデータベースのネットワークに接続された、ネットワーク化された３つのビジネスオフィス装置群を示す図である。デジタル画像形成装置の構成を示す図である。図２に示したデジタル画像形成装置の電子的構成を示す図である。図３に示した複数ポート通信インターフェイスの詳細を示す図である。ビジネスオフィス装置がネットワークに直接接続された、またはネットワークに接続されたコンピュータに接続された別のシステム構成を示す図である。電子メールを用いたアプリケーション部との間の情報のフローを示すブロック図である。アプリケーション部に接続されたコンピュータがメッセージ転送エージェント（MTA）としても機能する、電子メールを用いた通信の別の方法を示す図である。アプリケーション部が電子メールを交換するメッセージ転送エージェントを含む、電子メールを用いた通信の別の方法を示す図である。メールサーバがPOP3サーバとして機能して機器／装置のメールを受信し、シンプルメール転送プロトコル（SMTP）サーバとして機能してその機器／装置のメールを送信する、電子メールを用いた通信の別の方法を示す図である。インターネットを通してメッセージを送信する別の方法を示す図である。機器／装置に接続し、電子メールメッセージを通信するために使用するコンピュータの一例を示す図である。本発明の一実施形態による、システム全体を示す概略図である。本発明の一実施形態による、データの監視に使用するモジュールとそのインターフェイス機能を示す図である。監視モジュールの詳細とサブモジュール間の呼び出し機能を示す図である。図１１に示したHWaccessにより使用されるデータ構造を示す図である。図１０に示した監視モジュールのinit関数のシーケンスを示す図である。図１１に示した、監視マネージャにより監視される装置の状態を判断する状態監視機能のシーケンスの一例を示す図である。図１３に示した、CDeviceFactoryにより生成され監視マネージャにより使用される、装置を示すベクトルを示す図である。抽象型クラスCAbsProtocolParametersを含むDeviceODBCモジュールのクラス構造を示す図である。本発明の一実施形態による、被監視装置にアクセスするために必要なパラメータ値を格納するために使用するSParameterデータ構造を示す図である。本発明の一実施形態による、被監視装置にアクセスするために必要なパラメータ値を格納するために使用するマップ構造を示す図である。本発明の一実施形態で使用する監視データベースの構成を示す図である。本発明の一実施形態による通信プロトコルにより構成されたサポートデータベースの構成を示す図である。本発明の一実施形態による通信プロトコルにより構成されたサポートデータベースの構成を示す図である。本発明の一実施形態による通信プロトコルにより構成されたサポートデータベースの構成を示す図である。本発明の一実施形態によるHWaccessモジュールのクラス構造を示す図である。本発明の一実施形態によるSNMPモジュールのクラス構造を示す図である。本発明の一実施形態によるHTTPモジュールのクラス構造を示す図である。本発明の一実施形態によるFTPモジュールのクラス構造を示す図である。本発明の一実施形態による、被監視装置にアクセスしその被監視装置からステータス情報を取得するために必要な情報を維持する、図２３のHWaccessモジュールで使用されるデータ構造を示す図である。本発明の一実施形態による、被監視装置にアクセスしその被監視装置からステータス情報を取得するために必要な情報を維持する、図２３のHWaccessモジュールで使用されるデータ構造を示す図である。本発明の一実施形態による、被監視装置にアクセスしその被監視装置からステータス情報を取得するために必要な情報を維持する、図２３のHWaccessモジュールで使用されるデータ構造を示す図である。本発明の一実施形態による、被監視装置にアクセスしその被監視装置からステータス情報を取得するために必要な情報を維持する、図２３のHWaccessモジュールで使用されるデータ構造を示す図である。本発明の一実施形態による、被監視装置のベンダー情報でプロトコルオブジェクトを初期化する過程を示すフローチャートである。本発明の一実施形態による、各プロトコルについて、あるベンダーとモデルに関する被監視装置のステータス情報を取得するために使用するデータ構造を示す図である。本発明の一実施形態による、各プロトコルについて、あるベンダーとモデルに関する被監視装置のステータス情報を取得するために使用するデータ構造を示す図である。本発明の一実施形態による、各プロトコルについて、あるベンダーとモデルに関する被監視装置のステータス情報を取得するために使用するデータ構造を示す図である。本発明の一実施形態による、各プロトコルについて、あるベンダーとモデルに関する被監視装置のステータス情報を取得するために使用するデータ構造を示す図である。本発明の一実施形態による、FTPプロトコルを用いて被監視装置からステータス情報を取得するために使用する、図２７D、２９C、２９Dのデータ構造のデータ例を示す図である。本発明の一実施形態による、一通信プロトコルにおいて被監視装置からステータス情報を取得する過程を示すフローチャートである。本発明の一実施形態による、すべての通信プロトコルを用いて被監視装置からステータス情報を取得する過程を示すフローチャートである。本発明の一実施形態による、あるプロトコルでサポートされた被監視装置のベンダーとモデルに関する情報を維持するために用いられるデータ構造を示す図である。図３２Aに示したデータ構造の一例を示す。本発明の一実施形態による、サポートされたベンダーとモデルを図３２Aのデータ構造に加える方法を示すフローチャートである。本発明の一実施形態による、図３２Aのデータ構造から一プロトコルによりサポートされたベンダーおよびモデルを取得する方法を示すフローチャートである。本発明の一実施形態によるデバイスモジュールのクラス構造を示す図である。本発明の一実施形態による、どのプロトコルを用いて被監視装置にアクセスするかを判断するために、被監視装置を表すソフトウェアオブジェクトにより使用されるデータ構造を示す図である。図３６Aのデータ構造のデータ例を示す図である。本発明の一実施形態による、どのプロトコルを使用して被監視装置のステータス情報を取得するかを判断するために、図３６Aのデータ構造をどのように更新するかを示すフローチャートである。被監視装置で利用可能なHTMLファイルの例を示す図である。被監視装置で利用可能なHTMLファイルの例を示す図である。被監視装置で利用可能なHTMLファイルの例を示す図である。図２３の各プロトコルパッケージを示すパッケージ図である。ここで、「XXX」はHTTP、FTP、SNMP等である。図２３の各プロトコルパッケージを示す別のパッケージ図である。ここで「XXX」はHTTP、FTP、SNMP等である。本発明の一実施形態によるHTTPプロトコルのパッケージ図である。抽象クラスCAbsHTTPImplementationのクラス仕様を示す図である。図４１のCHTTPProtocolクラスのデータ構造m_ImplementationMapを示す図である。図４１のCHTTPProtocolクラスのデータ構造m_VendorModelSupportMapを示す図である。 CHTTPProtocolクラスの関数canAccessIP()を示すフローチャートである。 CHTTPProtocolクラスの関数obtainStatus()を示すフローチャートである。 FirstHTTPImplementationパッケージを示すパッケージ図である。 SecondHTTPImplementationパッケージを示すパッケージ図である。 HTTPの第１実装により使用されるサポートデータベースのテーブルを示す図である。 HTTPの第２実装により使用されるサポートデータベースのテーブルを示す図である。 FirstHTTPODBCパッケージのクラス構造を示す図である。 SecondHTTPODBCパッケージのクラス構造を示す図である。 CSecondHTTPImplementationクラスのマップ構造m_VendorModelWebInfoMapを示す図である。 CSecondHTTPImplementationクラスのマップ構造m_ModelWebInfoForVendorMapを示す図である。 CSecondHTTPImplementationクラスのマップ構造m_VendorModelUniqueIDInfoMapを示す図である。 CSecondHTTPImplementationクラスの関数obtainStatus()を示すフローチャートである。 CSecondHTMLProcessorクラスにより使用されるベクトル構造m_KeyValueVector及びm_LocateValueVectorを示す図である。 CSecondHTMLProcessorクラスにより使用されるベクトル構造m_KeyValueVector及びm_LocateValueVectorを示す図である。 CFirstHTMLProcessorクラスにより使用される、HTTPの第１実装で使用されるベクトル構造m_KeyValueVector及びm_LocateValueVectorを示す図である。 CSecondHTMLProcessorクラスの関数initDataSearchInfo()を示すフローチャートである。 CSecondHTMLProcessorクラスの関数searchAndObtainDataFromValue()によるテキスト処理を示すフローチャートである。 SNMPプロトコルを用いてステータス情報を取得するために使用するサポートデータベーステーブルのエントリー例を示す図である。 SNMPパッケージのクラス構造を示す図である。 SNMPaccessパッケージのクラス構造を示す図である。 SNMP要求タイプとオブジェクト識別子の情報を含む文字列のSNMP要求の処理を示すフローチャートである。

符号の説明

２４デジタルコピー／プリンター
２７オフィス機器
２８ファクシミリ
３２プリンター
５０Ａファイヤーウォール
５０Ｂファイヤーウォール
５０Ｃファイヤーウォール
１６６多ポートネットワークI/F
１７２ IFコントローラ
１７４操作パネル
１７６記憶I/F
１７８フラッシュメモリ
１８４オプションI/F
１８７クロック／タイマー
１７１ローカル接続
１８８オプショナルユニットインターフェイス
１９０フューザ
１９２プリンター／イメージャ
１９４スキャナー
１９６ペーパーフィードコントローラ
１９８大容量トレイ部
２００デュプレクサ
２０２ソータ

Claims

ネットワークを介して接続された被監視装置と関連する情報をSNMPプロトコルを用いて抽出する方法であって、
メモリにアクセスして前記被監視装置にアクセスするためのアクセス情報を取得するステップを有し、
前記アクセス情報は、（１）前記被監視装置から取得する一種類のステータス情報と、（２）前記被監視装置から前記一種類のステータス情報を取得するために用いるアクセス文字列とを含み、
前記方法は、
前記アクセス文字列を分析して、前記アクセス文字列が記憶されていたかどうか判断し、前記アクセス文字列が記憶されていたとき、前記アクセス文字列が所定の文字列を含むかどうか判断するステップと、
前記分析するステップにおいて、前記アクセス文字列が記憶されていて、前記アクセス文字列が前記所定の文字列を含むと判断した場合、第１のSNMPアクセス関数を用いて前記被監視装置にアクセスして前記一種類のステータス情報と関連した値を取得するステップと、
前記分析するステップにおいて、前記アクセス文字列が記憶されていないか、または前記アクセス文字列が前記所定の文字列を含まないと判断した場合、第２のSNMPアクセス関数を用いて前記被監視装置にアクセスして前記一種類のステータス情報と関連した値を取得するステップと、をさらに有し、
前記メモリにアクセスするステップは、前記メモリにアクセスして前記被監視装置から取得すべき前記一種類のステータス情報に対応するオブジェクト識別子情報を取得するステップを有することを特徴とする方法。
請求項１に記載の方法であって、
前記分析するステップは、前記アクセス文字列を分析して、前記アクセス文字列が記憶されている場合、前記アクセス文字列の第１のエレメントが前記所定の文字列であるかどうかを判断するステップを有することを特徴とする方法。
請求項１に記載の方法であって、
前記第１のSNMPアクセス関数はSNMPのGet関数であり、前記第２のSNMPアクセス関数はSNMPのGetNext関数であることを特徴とする方法。
請求項１に記載の方法であって、
前記メモリにアクセスするステップは、
前記被監視装置にアクセスするための前記アクセス情報を格納するように構成された外部記憶装置に複数の通信プロトコルを用いてアクセスするステップをさらに有することを特徴とする方法。
ネットワークを介して接続された被監視装置と関連する情報をSNMPプロトコルを用いて抽出する監視装置であって、
メモリにアクセスして前記被監視装置にアクセスするためのアクセス情報を取得する手段を有し、
前記アクセス情報は、（１）前記被監視装置から取得する一種類のステータスと、（２）前記被監視装置から前記一種類のステータス情報を取得するために用いるアクセス文字列とを含み、
前記被監視装置は、
前記アクセス文字列を分析して、前記アクセス文字列が記憶されているかどうか判断し、前記アクセス文字列が記憶されているとき、前記アクセス文字列が所定の文字列を含むかどうか判断する手段と、
前記分析する手段において、前記アクセス文字列が記憶されていて、前記アクセス文字列が前記所定の文字列を含むと判断した場合、第１のSNMPアクセス関数を用いて前記被監視装置にアクセスして前記一種類のステータス情報と関連した値を取得する手段と、
前記分析する手段において、前記アクセス文字列が記憶されてないか、または前記アクセス文字列が前記所定の文字列を含まないと判断した場合、第２のSNMPアクセス関数を用いて前記被監視装置にアクセスして前記一種類のステータス情報と関連した値を取得する手段と、をさらに有し、
前記メモリにアクセスする手段は、前記メモリにアクセスして前記被監視装置から取得すべき前記一種類のステータス情報に対応するオブジェクト識別子情報を取得する手段を有することを特徴とする監視装置。
請求項５に記載の監視装置であって、
前記分析する手段は、前記アクセス文字列を分析して、前記アクセス文字列が記憶されている場合、前記アクセス文字列の第１のエレメントが前記所定の文字列であるかどうかを判断する手段を有することを特徴とする監視装置。
請求項５に記載の監視装置であって、
前記第１のSNMPアクセス関数はSNMPのGet関数であり、前記第２のSNMPアクセス関数はSNMPのGetNext関数であることを特徴とする監視装置。
請求項５に記載の監視装置であって、
前記メモリにアクセスする手段は、
前記被監視装置にアクセスするための前記アクセス情報を格納するように構成された外部記憶装置に複数の通信プロトコルを用いてアクセスする手段をさらに有することを特徴とする監視装置。
コンピュータに請求項１ないし４いずれか一項に記載の方法を実行させることを特徴とするコンピュータプログラム。