【課題】マルチベンダー環境において様々なデバイスの監視を可能とし、特定のプライベートなマネージメント情報ベース情報を有さなくても、詳細な情報を読み出し、表示する。
【解決手段】被監視デバイスに関するベンダー情報を取得するために選択された通信プロトコルを用いて被監視デバイスにアクセスし、アクセス可能データファイルからステータス情報を抽出するアクセス関数を特定する情報を第１のメモリから取得し、取得したベンダー情報とアクセス関数情報に基づきストリングを生成し、生成されたストリングに応じて第２のメモリから、アクセス関数に関連したデータ処理オブジェクトの情報と、被監視デバイスから抽出するステータス情報のタイプおよびステータス情報に関連する重みを含む情報マップとを読み出し、ステータス情報を取得するため、アクセス関数、情報マップ、および選択された通信プロトコルを用いて被監視デバイスにアクセスする。

【発明の詳細な説明】
【技術分野】
【０００１】
本発明はネットワークを介した装置（デバイス）の監視に関する。特に、複数のプロトコルを用いてネットワークを介して装置（デバイス）を遠隔監視する方法、装置、コンピュータプログラム、およびそのコンピュータプログラムを格納した記憶媒体に関する。
【背景技術】
【０００２】
広く知られているように、コンピュータシステムにはハードウェアとソフトウェアが含まれる。ソフトウェアはコンピュータシステムを構成するハードウェア部品を動作させ管理するために作られた命令のリストを含んでいる。一般に、コンピュータシステムは相互にインターフェイスする様々なハードウェア部品や装置（デバイス）を含んでいる。コンピュータにはスタンドアロンのものやネットワークで接続されたものがある。ネットワークタイプのコンピュータシステムは、複数の装置（デバイス）がネットワークに接続されており、そのネットワークを介して通信が行われる。
【０００３】
さらに、ハードウェア装置（デバイス）間の通信を可能とするために、ハードウェア装置（デバイス）が協働的に機能するように、ハードウェア装置（デバイス）を動作させるソフトウェアが構成されていなければならない。さらに、通信を容易にするため、ハードウェア装置（デバイス）を監視（モニター）し、各ハードウェア装置（デバイス）が効率的に機能していることを保証するために、その状態を知っていることが望ましい。
【０００４】
本特許出願のために、複数の個別の装置（デバイス）またはハードウェア装置（デバイス）を制御、設定、監視するハードウェア装置（デバイス）を監視装置（デバイス）と呼び、監視装置（デバイス）により制御、設定、監視されているハードウェア装置（デバイス）を「被監視装置（デバイス）」と呼ぶ。
【０００５】
ネットワーク上のハードウェア装置（デバイス）は、メンテナンス、使用、その他の目的のために監視されていることが望ましい。しかし、ハードウェア装置（デバイス）とインターフェイスに関する製造者の違いを考慮すると、監視装置（デバイス）がネットワークに接続された他の様々な装置（デバイス）と通信することは困難である。このような不利益により、ネットワーク管理者は、そのネットワークに接続された装置（デバイス）の性能と効率についての重要な情報を取得することができない。
【０００６】
シンプルネットワークマネージメントプロトコル（SNMP）は、今日、データ通信ネットワーク上の装置（デバイス）、電気通信システム、その他のグローバル到達可能装置（デバイス）（globally reachable devices）を監視および管理するためのデファクトスタンダードである。実際には、コンピュータと関連装置（デバイス）とを取り扱うすべての組織は、ローカルエリアネットワークやワイドエリアネットワークを通じて各装置（デバイス）を集中的に監視、診断、設定できることを期待している。SNMPはこのようなインターラクションを実現するプロトコルである。
【０００７】
装置（デバイス）がSNMPリクエストに応答するために、SNMPリクエストを正しく解釈し、そのリクエストにより要求されたアクションを実行し、SNMPリプライを生成することができるようにするソフトウェアを装置（デバイス）に備えることが望ましい。SNMPエージェントソフトウェアは一般的にネットワークエンティティに備えられたサブシステムソフトウェアモジュールである。
【０００８】
システムにより使用されるオブジェクトは一般にマネージメントインフォメーションベース（MIB）と呼ばれる。MIBは装置（デバイス）の監視に関する情報のデータベースでもある。MIBの例としては、２、３例を挙げると、イーサネット（登録商標）インターフェイスにフォーカスしたイーサネット（登録商標）MIB、802.1Dブリッジ管理用のオブジェクトを定義するブリッジMIB等がある。
【０００９】
装置（デバイス）の監視にSNMPを使用することは困難である。それは、正しい鍵が無ければ解読困難な値がプライベートなMIBに含まれているからである。自社のネットワークに接続された様々な装置（デバイス）を監視するためにSNMPを使用している会社は、その会社の独占情報として維持されているユニークな識別子／鍵を作っている。通例、結果は２値または整数値として表示される。このように、SNMPを用いて、監視されている装置（デバイス）（被監視装置（デバイス））から受信した結果は、被監視装置（デバイス）の状態をユーザが理解可能な形でユーザに提供することはできない。
【００１０】
さらに、SNMPを用いても、正しい鍵なしに被監視装置（デバイス）についての詳細な情報を取得し、プライベートMIBにアクセスして、２値または整数値として取得した結果を解読することは困難である。また、既存のプロトコル（例えば、SNMPやHTTP/HTML）は、タイムアウトやロストパケット等の様々な理由でうまく機能しない。また、複数のプロトコルを用いて既存の装置（デバイス）から抽出した情報は、各プロトコルに対してダブっているかも知れない。従って、このような状況において装置（デバイス）からのデータの抽出をうまく管理しないと、プロトコルによっては他のプロトコルよりも多くのリソースを必要とするものもあるので、時間と費用の効率が悪くなる。また、一部のプロトコルを用いれば、他のプロトコルを用いるよりも少ない処理量と費用で情報を抽出することができる。さらにまた、あるプロトコルを用いて取得した情報は、他のプロトコルを用いて取得した情報よりも監視装置（デバイス）にとって便利である。
【００１１】
現在の監視システムにおいて、各プロトコル（例えば、SNMP、FTP、HTTP）は単一のフォーマットに対応した単一の方法を用いて被監視装置（デバイス）からデータを抽出するものと仮定する。例えば、SNMPプロトコルは、SNMPコマンドGetNextを用いてオブジェクト識別子（OID）に対応する値を取得する。さらにまた、HTMLを用いたHTTPプロトコルはキー値（Key
Value）、キー値に対する相対的な位置、デリミターに対するインラインの位置を用いて値を取得する。しかし、本願の発明者は、この仮定はFTPプロトコルとXMLでは成り立たないということを見いだした。例えば、被監視装置（デバイス）から抽出すべきデータはベンダーおよびFTPファイルに応じて異なる。XMLの場合、ベンダーによってタグネームは異なる。
【００１２】
図３８Ａ−Ｃは、FTPファイル（サンプル１−３）に関わる上記問題の例を示す図である。サンプル１−３は、あるベンダーの装置（デバイス）において、FTPプロトコルを通して取得できる異なるファイルの例である。各ファイルから情報を抽出するには、異なるメソッドが必要である。以前の発明においては、既存のプロトコルのすべての情報は同一フォーマットであると仮定されている。SNMPとHTTP/HTMLは、同一メソッドに従って関係する情報を抽出する。しかし、FTPのように、HTTP/XMLデータを処理するには異なるメソッドが必要である可能性もある。その理由は、製造者が違うか、同じ製造者でもモデルが違えば、XMLフォーマットのデータのデータ構造は異なるからである。
【００１３】
図３８Aは、ネットワークプリンターのインプットトレイ、アウトプットトレイ、プリンター言語に関する情報を含むFTPファイルの一例を示す。各トレイおよび各プリンター言語に関する情報を含むラインからのみ情報を抽出する監視システムが必要とされている。このようなシステムは、「インプットトレイ」、「アウトプットトレイ」、または「プリンター言語」というテキストを探すことにより、何のタイプの情報を抽出することができるか判断しなければならない。情報のタイプを判断した後、システムはカラムヘディング（すなわち、点線）の次のステータス情報を抽出しなければならない。カラムヘディングに続く各ラインは、テーブルの終わりに来るまで、ひとかたまりの情報であると見なされる。
【００１４】
図３８Bは、プリンターのプリントジョブに関する情報を含むFTPファイルの一例を示す。監視システムはこのファイル内の情報のタイプをプリントジョブとみなし、カラムヘディングに続くステータス情報を抽出する。カラムヘディングに続く各ラインは、テーブルの終わりに来るまでひとかたまりの情報とみなされる。図３８AのFTPファイルと異なり、このFTPには１つのタイプの情報しか含まれていないので、情報のタイプを判断する必要はない。
【００１５】
図３８Cはプリンターのシステムログに関する情報を含むFTPファイルの一例を示す。監視システムは、何の情報を抽出したのかを、各ラインのキーテキスト（例えば、ncsd、inetd、snmpd、papserver、その他「[」と「(xx)」の間のテキスト）を探すことにより判断しなければならない。各タイプの情報について、システムはキーテキストに対応するラインをそのタイプのステータス情報として取り扱う。場合によっては、１つのタイプのステータス情報は、図３８Cの次のライン
【００１６】
【数１】

のように、複数のラインにまたがっていることもある。このような場合、システムはこの２つのラインをタイプsnmpdのステータス情報として取り扱う。図３８A-Cを参照して説明したように、FTPファイルに異なる処理を施して被監視装置（デバイス）からステータス情報を取得する必要があることは明らかである。
【発明の開示】
【課題を解決するための手段】
【００１７】
本発明のシステムと方法は、ネットワークに接続された装置（デバイス）を監視可能とすることにより、上記問題を解決する。従って、ネットワークを介して装置（デバイス）を監視する方法を説明する。
【００１８】
該方法はハードウェアアクセスモジュールを介して第１のデータベースにアクセスするステップを含み、前記第１のデータベースは複数の通信プロトコルをサポートするように構成されている。第１のデータベースには、被監視装置（デバイス）の製造者やモデル情報等、様々な情報を取得するため複数の通信プロトコルにより使用される情報が格納されている。通信プロトコルは複数の通信プロトコルから選択され、選択された通信プロトコルは被監視装置（デバイス）からステータス情報を受信するために設定される。該方法は、前記第１のデータベースから前記選択された通信プロトコルと情報を用いて前記被監視装置（デバイス）を評価するステップと、前記評価された装置（デバイス）からステータス情報を受信するステップと、前記受信したステータス情報を第２のデータベース（DeviceODBC）に格納するステップとを有する。
【００１９】
他の実施形態において、本発明はネットワークを介して装置（デバイス）を監視する方法を提供する。複数の通信プロトコルは被監視装置（デバイス）から情報を読み出すために使用される。例えば、SNMPプロトコルが最初に被監視装置（デバイス）にアクセスするために選択され、SNMPプロトコルを用いて効率的に読み出すように構成された装置（デバイス）情報が取得される。その後、前記装置（デバイス）がその他のプロトコルをサポートしているとき、SNMPプロトコルを用いて効率的に読み出すことができない情報を取得するために、HTTPおよびFTPプロトコルが選択される。プロトコルの選択は、データベースに格納されたサポート情報に関してプロトコルマネージャにより実行される。
【００２０】
本発明において、例えばLANやWANなどのネットワークに接続された少なくとも１つの装置（デバイス）（被監視装置（デバイス））の監視が監視システムにより可能となる。前記被監視装置（デバイス）はユニークIPアドレスを有するように構成されている。被監視装置（デバイス）に割り当てられたIPアドレスと前記被監視装置（デバイス）のベンダー／製造者の詳細は、データベースに格納される。ネットワークをスキャンして装置（デバイス）に問い合わせることにより、装置（デバイス）のIPアドレスを取得できる。その方法は既知である。それゆえ、監視される装置（デバイス）のIPアドレスはすでに取得され、データベースに格納されていると仮定する。
【００２１】
本発明は、被監視装置（デバイス）から受信したHTML情報から必要な情報をいかに抽出するかを特定している。一旦被監視装置（デバイス）のウェブページにアクセスすると（すなわち、IPアドレスと指定ポートを通じて）、被監視装置（デバイス）に対応する指定ウェブページが表示される。そのウェブページの情報はキーと値のペアである。例えば、トナーレベルは、カラープリンターのウェブページにおいて、「ブラック１００％」と表示される。HTML/XMLパーサを用いて、ウェブページの情報から必要な情報を読み出すためにそのページを解釈する。HTML／XMLパーサを用いてウェブページから抽出した必要情報とパラメータ値はDeviceODBCデータベースに格納される。
【００２２】
本発明は、ここで説明した監視システムによりサポートされた被監視装置（デバイス）のベンダーと装置（デバイス）モデルとを特定する。被監視装置（デバイス）の様々なベンダーがベンダー固有のやり方で被監視装置（デバイス）に関する情報を提示しているので、本発明により被監視装置（デバイス）のベンダーとモデルを特定して被監視装置（デバイス）の動作状態を決定することができる。
【００２３】
本発明によれば、ネットワークを介して被監視装置（デバイス）に関するステータス情報を抽出するために使用する通信プロトコルに関連する少なくとも１つのデータ処理オブジェクトを初期化する方法、システム、およびコンピュータプログラムが提供される。これは、（１）被監視装置（デバイス）に関するベンダー情報を取得する前記被監視装置（デバイス）にアクセスするステップと、（２）前記被監視装置（デバイス）のアクセス可能データファイルから前記通信プロトコルを用いて前記ステータス情報を抽出するアクセス関数に関係する情報をサポートメモリから取得するステップと、ここで前記アクセス可能データファイルはそれぞれのデータファイルタイプを有し、（３）前記少なくとも１つのデータ処理オブジェクトのそれぞれのデータ処理オブジェクトに前記ベンダー情報と前記アクセス関数情報を格納するステップと、（４）前記少なくとも１つのデータ処理オブジェクトの各々について前記取得ステップと格納ステップを繰り返すステップとを含む。
【００２４】
本発明によれば、ネットワークを介して被監視装置（デバイス）に関係するステータス情報を抽出するために使用する通信プロトコルに関連したデータ処理オブジェクトを生成する方法、システム、コンピュータプログラムが提供される。これは、（１）前記被監視装置（デバイス）に関係した少なくともベンダー情報を取得するために前記通信プロトコルを用いて前記被監視装置（デバイス）にアクセスするステップと、（２）前記被監視装置（デバイス）のアクセス可能データファイルから前記ステータス情報を抽出するためのアクセス関数に関係する情報を第１のメモリから取得するステップと、（３）前記取得したベンダー情報とアクセス関数情報を用いてストリングを生成するステップと、（４）前記生成されたストリングに対応する生成関数に関係する情報を第２のメモリから取得するステップと、（５）前記取得された生成関数を用いて前記データ処理オブジェクトを生成するステップとを有する。
【００２５】
本発明によれば、ネットワークを介して被監視装置（デバイス）に関するステータス情報を選択された通信プロトコルについて抽出する方法、システム、コンピュータプログラムが提供される。これは、（１）前記被監視装置（デバイス）に関する少なくともベンダー情報を取得するために前記選択された通信プロトコルを用いて前記被監視装置（デバイス）にアクセスするステップと、（２）前記被監視装置（デバイス）のアクセス可能データファイルから前記ステータス情報を抽出するアクセス関数を特定する情報を第１のメモリから取得するステップと、（３）前記取得したベンダー情報とアクセス関数情報に基づきストリングを生成するステップと、（４）前記アクセス関数に関連したデータ処理オブジェクトの情報と、前記被監視装置（デバイス）から抽出すべきステータス情報の少なくともタイプと前記ステータス情報に関連する重みを含む情報マップとを、前記生成されたストリングに応じた第２のメモリから読み出すステップと、（５）前記ステータス情報を取得するために、前記アクセス関数、前記情報マップ、および前記選択された通信プロトコルを用いて前記被監視装置（デバイス）にアクセスするステップとを有する。
【００２６】
本発明とそれに付随する多数の有利な点は、添付した図面を参照して以下の詳細な説明を読めばよりよく理解できるであろう。
【発明を実施するための最良の形態】
【００２７】
図１は、様々な装置（デバイス）と、その装置（デバイス）の動作を監視、診断、制御するコンピュータ（システムとも呼ぶ）とを示す概略図である。具体的に、図１は、コンピュータワークステーション１７、１８、２０および２２に接続された、ローカルエリアネットワーク（LAN）等の第１のネットワーク１６を含む。ワークステーションは、例えば、パーソナルコンピュータ、UNIX（登録商標）ベースのコンピュータ、リナックスベースのコンピュータ、アップルマッキントッシュ等いかなるタイプのコンピュータであってもよい。また、デジタルコピー／プリンター２４、ファックス２８、プリンター３２もネットワーク１６に接続されている。デジタルコピー／プリンターはネットワークスキャナーとしても機能する。当業者には明らかであるが、デジタルコピー／プリンター２４とファクシミリ２８を組み合わせて、一体の「画像形成装置」とすることができる。例えば、コピー／プリンター２４、ファックス、プリンター３２、ワークステーション１７、１８、２０、２２をマシン、あるいは被監視装置（デバイス）と呼ぶ。コンフィギュレーションによっては、１以上のワークステーションをビジネスオフィス機器に替えてもよい。また、いかなるビジネスオフィス機器／装置（デバイス）をネットワーク１６に付加してもよい。また、ワークステーション１７、１８、２０、２２、およびオフィス機器２７は中間監視装置（デバイス）として機能することもでき、ネットワーク１６上の被監視装置（デバイス）からデータを集め、集めたデータを監視装置（デバイス）に送信する。
【００２８】
このようなビジネスオフィス機器の一例は、株式会社リコーのeCabinetである。また、ファクシミリサーバ（図示せず）をネットワーク１６に接続して、電話、ケーブル、または無線で接続してもよい。デジタルコピー／プリンター２４、ファクシミリ２８、プリンター３２は各々ネットワーク１６に接続されているのに加えて、従来の電話、ケーブル、または無線接続２６、３０、３４も有する。以下に説明するように、被監視装置（デバイス）２４、２８、３２は、例えば、ネットワーク１６とインターネットを経由して、または電話、無線、またはケーブル接続を介して監視装置（デバイス）とも呼ぶリモート監視・診断・制御ステーションと通信する。
【００２９】
他のビジネス環境において、被監視装置（デバイス）は、多機能画像化装置（デバイス）、スキャナー、プロジェクター、テレビ会議システム、およびシュレッダー等の装置（デバイス）を含む。他のアプリケーションにおいて、ネットワーク１６はホームネットワークでもよく、その場合、被監視装置（デバイス）は（電気、ガス、水道）メータであってもよく、例えば、電子レンジ、洗濯機、乾燥機、食器洗い機、ホームエンターテイメントシステム、冷蔵庫、炊飯器、ヒーター空調機、温水器、セキュリティカメラ等の機器であってもよい。
【００３０】
図１において、ワイドエリアネットワーク（WAN）（例えば、インターネットやその後継ネットワーク）１０が示されている。WAN１０は、プライベートWANでも、パブリックWANでも、ハイブリッドタイプであってもよい。WAN１０は、相互接続された複数のコンピュータとルータ１２A-１２Iを含んでいる。WANによる通信方式は、インターネットエンジニアリングタスクフォース（IETF）（ウェブサイト：www.ietf.org/rfc.html）から入手可能なリクエストフォーコメント（RFC）文書を通して知ることができ、例えば以下の文書がある：RFC821「Simple Mail Transfer Protocol」；RFC822「Standard for the Format of ARPA Internet Text」；RFC959「File Transfer Protocol(FTP)」；RFC2045「Multipurpose Internet Mail Extensions(MIME) Part One: Format of Internet Message Bodies」；RFC1894「An Extensible Message Format for Delivery Status Notifications」；RFC1939「Post Office protocol-Version 3」；RFC2068「Hypertext Transfer Protocol ?HTTP/1.1」；およびRFC2298「An Extensible Message Format for Message Disposition Notifications」。これら引用文献の内容は参照によりここに援用する。
【００３１】
トランスミッションコントロールプロトコル／インターネットプロトコル（TCP/IP）関係の通信は、例えば、W.R. Stevens著、プロトコル第一巻「TCP/IPイラストレイテッド」（Addison-Wesley Publishing Company社、1994年）に説明されている。この文献の内容は参照によりここに援用する。Comer、Stevens著「TCP/IPによるインターネットワーキング」第１巻〜第３巻もここに引用によりその全体を援用する。
【００３２】
引き続き図１を参照して、ファイヤーウォール５０AがWAN１０とネットワーク１６との間に接続されている。ファイヤーウォールは、その一方の側にある権限を与えられたコンピュータだけが、他方の側にあるネットワーク、コンピュータ、個別パーツにアクセスできるようにする装置（デバイス）である。ファイヤーウォールは商業的に入手可能な既知の装置またはソフトウェア（例えば、Zone Labs社のZoneAlarm）である。同様に、ファイヤーウォール５０Bと５０Cは、WAN１０をネットワーク５２とワークステーション４２からそれぞれ分離している。ファイヤーウォールに関するさらに詳細は、W.R. CheswickおよびS.M. Bellovin著「ファイヤーウォールとインターネットセキュリティ」（Addison Wesley Publishing、1994年）、およびD.B. ChapmanおよびE.D. Zwicky著「インターネットファイヤーウォールの構築」（O’Reilly & Associates, Inc.、1995年）に記載されている。この２つの引用文献の内容もすべて参照により援用する。
【００３３】
ネットワーク５２は従来のネットワークであり、複数のワークステーション５６、６２、６８、７４を含んでいる。これらのワークステーションは分散され、一つの会社の異なる部署（例えば、販売、注文処理、会計、請求、マーケティング、生産、デザインエンジニアリング、カスタマーサービス等）に配置されている。ネットワーク５２を介して接続されたワークステーションに加え、ネットワーク５２には直接接続されていないワークステーション４２も設けられている。ワークステーション４２に接続されたディスク４６に格納されたデータベース中の情報を、ネットワーク５２に直接接続されたワークステーションで、WAN１０を介して適当な暗号化およびプロトコルを用いて共有することもできる。また、ワークステーション４２は電話線、ケーブルネットワーク、ワイヤレスネットワーク４４に直接接続され、ディスク４６中のデータベースにはその電話線、ケーブルネットワーク、ワイヤレスネットワーク４４を通してアクセスできる。本発明で使用するケーブルネットワークは、典型的にはテレビジョン番組を送信するために使用するケーブルネットワーク、一般にはコンピュータ等で使用するデジタルデータの高速通信を提供するケーブル、またはその他望ましいタイプのケーブルを用いて実現される。
【００３４】
他の実施形態において、ワークステーション４２はラップトップコンピュータ、PDA、パームトップコンピュータ、またはネットワーク機能を有した携帯電話であってもよい。これらの装置（デバイス）を用いてディスク４６に格納されたデータベース中の情報にアクセスしてもよい。
【００３５】
デジタルコピー／プリンター２４、オフィス機器２７、ファクシミリ２８、プリンター３２それぞれに関する情報は、ディスク４６、５４、５８、６４、７０、７６に格納された１以上のデータベースに入れられる。既知のデータベースには、（１）マイクロソフト、IBM、オラクル、サイベースのSQLデータベース、（２）その他のリレーショナルデータベース、（３）非リレーショナルデータベース（例えば、オブジェクティビティ、JYDソフトウェアエンジニアリング、オリエントテクノロジー）などがある。販売、受注処理、会計、請求、カスタマーサービス、マーケティング、生産、エンジニアリング部門は各々自分のデータベースを有しても、１以上のデータベースを共有してもよい。データベースを格納するために使用する各ディスクは、ハードディスクまたは光ディスク等の不揮発メモリである。あるいは、データベースは、固体および／または半導体メモリデバイス等の記憶デバイスに格納してもよい。例えば、ディスク６４にはマーケティングデータベースを格納し、ディスク５８には生産データベースを格納し、ディスク７０にはエンジニアリングデータベースを格納し、ディスク７６にはカスタマーサービスデータベースを格納してもよい。あるいは、ディスク５４と４６に１以上のデータベースを格納してもよい。
【００３６】
ワークステーション５６、６２、６８、７４、４２は、WAN１０への接続に加えて、監視・診断・制御されるマシン／装置（デバイス）とのセキュアな接続をするために、電話線、ケーブル、ワイヤレスネットワークに接続されていてもよい。また、通信媒体の一つが故障したとき、バックアップとして他の通信媒体を自動的に用いて通信をおこなう。
【００３７】
本発明の特徴は「ストアアンドフォワード」モードの通信（例えば、インターネット電子メール、単に電子メールとも呼ぶ）、すなわちマシンを診断・制御するためのそのマシンとコンピュータ／監視システムとの間の送信を使用することにある。あるいは、FTPやハイパーテキストトランスファープロトコル（HTTP）のような直接のエンドツーエンドの（例えば、最終目的地とのソケット接続を用いた）接続をする通信モードを用いて、メッセージの送信が実現される。
【００３８】
図２は、図１に例示したデジタルコピー／プリンターの機械的レイアウトを示す図である。図２において、１０１はスキャナー用のファンであり、１０２はレーザプリンターで使用されるポリゴンミラーであり、１０３はレーザ（図示せず）からの光をコリメートするために使用するFθレンズである。参照数字１０４はスキャナーからの光を検出するセンサーを指す。参照数字１０５は、スキャナーからの光をセンサー１０４にフォーカスさせるレンズを指し、参照数字１０６は感光体ドラム１３２上の画像を消去するために用いる消去ランプを指す。チャージングコロナユニット１０７および現像ローラ１０８がある。参照数字１０９はスキャンする文書を照射するためのランプを指し、エレメント１１０、１１１、１１２は光をセンサー１０４に反射するミラーを指す。ドラムミラー１１３は、ポリゴンミラー１０２からの光を感光体ドラム１３２に反射するために設けられている。ファン１１４はデジタル画像形成装置のチャージングエリアを冷却するために使用する。第１の紙送りローラ１１５は、第１の給紙カセット１１７から用紙を給紙するために使用する。参照数字１１６はマニュアル給紙テーブルを指す。同様に、第２の給紙ローラ１１８は第２のカセット１１９に関して使用する。参照数字１２０はリレーローラを指し、１２１はレジストレーションローラを指し、１２２は画像濃度センサーを指し、１２３はトランスファー／セパレーションコロナユニットを指す。参照数字１２４はクリーニングユニットを指し、１２５はバキュームファンを指し、１２６は転送ベルトを指し、１２７はプレッシャーローラを指し、１２８はエグジットローラを指す。ホットローラ１２９は用紙にトナーを定着するために使用され、１３０は排気ファンを指し、メインモータ１３１はデジタルコピー／プリンター２４をドライブするために使用する。
【００３９】
図３は、図２のデジタルコピー／プリンター２４の電子部品を示すブロック図である。CPU１６０は装置のコントローラとして機能するマイクロプロセッサである。ランダムアクセスメモリ（RAM）１６２は、デジタルコピー／プリンター２４の動作パラメータ等の動的に変化する情報を格納する。不揮発メモリ（例えば、リードオンリーメモリ（ROM）１６４またはフラッシュメモリ）は、デジタルコピー／プリンター２４を記述する静的データ（例えば、装置（デバイス）のモデル名、モデル番号、シリアル番号、およびデフォルトパラメータ）のみでなく、そのデジタルコピー／プリンターを動作させるプログラムコードを格納している。
【００４０】
マルチポートネットワークインターフェイス１６６が設けられ、デジタルコピー／プリンター２４は少なくとも１つの通信ネットワークを介して外部の装置（デバイス）と通信可能である。参照数字１６８は、電話、ワイヤレス、またはケーブルラインを表し、参照数字１７０はネットワーク１６８とは別のタイプのネットワークを表す。マルチポートネットワークインターフェイスに関するさらに詳細は、図４を参照して説明する。インターフェイスコントローラ１７２はオペレーションパネル１７４をシステムバス１８６に接続するために使用する。オペレーションパネル１７４は、デジタルコピー／プリンター２４に取り付けられた標準的入出力装置（デバイス）を含んでいる。標準的入出力装置（デバイス）とは、例えば、コピーボタンや、コピー枚数、拡大／縮小、濃く／薄く等の画像形成装置の動作を制御するためのキーなどである。また、液晶ディスプレイパネルがオペレーションパネル１７４に含まれており、デジタルコピー／プリンター２４のパラメータやメッセージをユーザに表示する。
【００４１】
ローカル接続インターフェイス１７１は、RS232、パラレルプリンターポート、USB、IEEE1394等のローカルポートを介した接続である。ファイヤーワイヤ（IEEE１３９４）は、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）を介して送信するメッセージは暗号化する。暗号化メカニズムは既知であり、商業的に入手可能であり、本発明とともに使用することができる。例えば、Unix（登録商標）オペレーティングシステムで使用するためのC++ライブラリ関数crypt()をサンマイクロシステムズから入手可能である。暗号化および復号ソフトウェアパッケージが知られており、商業的に入手可能であり、本発明とともに使用できる。パッケージの例として、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アドレスにアクセスすることにより、被監視装置（デバイス）９０８−９１４それぞれにアクセスすることができる。当然のことながら、本発明ではネットワークに接続された装置（デバイス）をユニークに特定するためにIPアドレスを必ずしも使用しなくてもよい。
【００６６】
監視ステーションであるコントローラ９０２は、被監視装置（デバイス）９０８−９１４の１つにアクセスした時、SNMPおよび／またはHTTPプロトコルを介して様々な情報を取得する。情報の例としては、トラブルシューティング情報を含む、装置（デバイス）の動作状態に関する詳細な情報がある。例えば、コントローラ９０２は、ある装置（デバイス）にアクセスし、そのジャム位置を取得し、そのジャムを解消するためにその装置（デバイス）の担当者にメッセージを送信する。レーザプリンター９０８の動作状態・詳細には、トナーレベル、ペーパージャムの表示、プリンタートレイにある印刷用紙の枚数等の詳細を含まれている。
【００６７】
当然のことながら、コントローラ９０２はネットワーク１００と物理的に接続されていても、ワイヤレスで結合されていてもよい。例えば、パーソナルデジタルアシスタント（PDA）９２０やラップトップコンピュータ９２２は、ネットワーク１００にワイヤレスに結合しているように示されているが、コントローラ９０２として使用することもできる。アクセスポイント９２４は、ネットワーク１００とPDA９２２またはラップトップコンピュータ９２２との間のワイヤレス通信を可能とするインターフェイスとして機能する。ここからは、コントローラ９０２がネットワークに接続されている被監視装置（デバイス）の状態を制御および監視するという仮定の下に本発明を説明する。ネットワーク１００はコントローラ９０２と被監視装置（デバイス）９０８−９１４の間の通信を容易にし、上記被監視装置（デバイス）の監視と制御を可能とする。ネットワークに接続された装置（デバイス）の数は、本発明を限定するものではない。当然のことながら、ネットワーク１００はローカルエリアネットワーク（LAN）またはワイドエリアネットワーク（WAN）である。同様に、被監視装置（デバイス）９０８、９１０、９１２、９１４は例として示されたものである。
【００６８】
コントローラ９０２は記憶装置（デバイス）９０４とデータベース９０６に通信可能に結合している。記憶装置（デバイス）９０４はハードディスク、光ディスク、及び／または外部のディスクドライブを含む。データベース９０６は記憶装置（デバイス）９０４に通信可能にリンクされており、記憶装置（デバイス）９０４に格納されたデータを容易に検索し読み出すためのリレーショナルデータベースマネージメントシステム（RDBMS）を含んでいる。記憶装置（デバイス）９０４は、好ましくは、被監視装置（デバイス）９０８−９１４の各々に関する詳細情報を格納している。例えば、レーザプリンター９０８のメーカー、モデル、様々な機能およびトラブルシューティングの詳細等の詳細情報が記憶装置（デバイス）９０４に格納される。また、所定の基準値と比較したレーザプリンターの動作状態に関する偏差値も記憶装置（デバイス）９０４に格納されてもよい。データベース９０６と記憶装置（デバイス）９０４はコントローラに通信可能に結合していると説明したが、当然のことながら、コントローラ９０２は記憶装置（デバイス）と一体で、データベースがそれにインストールされてもよい。そのような場合、記憶装置（デバイス）９０６とデータベース９０４はコントローラ９０２に内蔵されているものとして示される。
【００６９】
コントローラ９０２は、複数の装置（デバイス）９０８−９１４の監視と制御を容易にするために、ソフトウェアでインストールされてもよい。コントローラ９０２は複数の装置（デバイス）９０８−９１４を監視するためにシンプルネットワークマネージメントプロトコル（SNMP）、ファイルトランスファープロトコル（FTP）、およびハイパーテキストトランスファープロトコル（HTTP）を使用し、その複数の装置（デバイス）９０８−９１４から受信したデータは９５０で示したようにASN.1バイナリーフォーマット、HTMLフォーマット、またはXMLフォーマットの形式で表される。
【００７０】
図９には画像装置（デバイス）のみを示したが、監視装置（デバイス）と複数の被監視装置（デバイス）の間で情報を通信するネットワークには、機器とメータがネットワークに接続されたホームネットワークを含んでいてもよい。当然のことながら、コントローラ・ワークステーション９０２により収集されたデータは、さらに処理するために、電子メール、FTP、その他の通信プロトコル手段を介してリモート装置（デバイス）に送信される。ワークステーション９０２、PDA９２０、またはラップトップコンピュータ９２２は、データを収集し、それを格納または通信プロトコルを使って送信するコントローラとすることができるが、コントローラはネットワークに接続されているどの装置（デバイス）であってもよい。どのネットワーク装置（デバイス）（例えば、プリンター）にも、ネットワーク中の他の装置（デバイス）の状態を監視し、収集したデータを格納し、および／または収集したデータを他の通信プロトコル手段（例えば、電子メール、FTP）を通じて送信することができる監視システムの機能を持たせることができる。ゼロックス社のドキュメント４０２５とHPレーザジェット９０００はともに電子メールを送信する能力を有している。
【００７１】
監視システムのアーキテクチャ
図１０は、本発明の一実施形態による、リモート装置（デバイス）に関連したデータの監視に使用される監視システム１０００（および、付随するインターフェイス機能）を示す。監視システム１０００はソフトウェアモジュールMonitorService１００４を含む。このソフトウェアモジュールMonitorService１００４はNTやウィンドウズ（登録商標）２０００のサービスおよびUnix（登録商標）のデーモン等のコンピュータ常駐プログラムである。好ましい実施形態において、監視システムはオブジェクト指向ソフトウェア環境を用いて実装されている。また、Timer（タイマー）モジュール１００２とMonitor（モニター）モジュール１００６が監視システム１０００に含まれている。タイマーモジュール１００２とMonitorモジュール１００６は、MonitorService（モニターサービス）モジュール１００４により呼び出されるライブラリ関数である。例えば、MonitorService１００４はInitTimer１００３関数を呼び出してTimerモジュール１００２を初期化し、obtainDelayAndAction(int&,int&)関数を呼び出して遅延および動作パラメータを取得する。init()関数は、図１３に示したように、Monitorモジュール１００６の様々なモジュールを初期化するために、MonitorServiceモジュール１００４によっても呼び出される。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 Module
図１１は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から削除される。
【００９８】
ErrorCode obtainEventStatus(std::map<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フィールド１２１２とを含む。このm_nPositionフィールド１２０６は、好ましくは、値情報の位置を特定できるストリング中の位置の数を示すタグベースの値である。例えば、プリンター装置（デバイス）のPage Countは、監視することを前提として、キーワードの次の２番目の位置に見つかる。m_sType１２０８は、被監視装置（デバイス）の表示されたウェブページから読み出すことができる情報のタイプを表す。
【０１０２】
キー（Product Name）の同じデータライン内に値（例えば、被監視装置（デバイス）のモデル名）が見つかった時、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は２つのフィールドm_sParName１７０２とm_sParValue１７０４を含み、それぞれパラメータの名前と値を表す。
【０１１０】
図１８は、監視データベースから取得した各プロトコルのパラメータのベクトルを、各被監視装置（デバイス）に関連するソフトウェアオブジェクトにパスするために使用するマップ構造体（構造）１８００を示す。マップ構造体（構造）１８００は、各プロトコル／キーフィールド１８０２、１８０４、１８０６を、図１７に示したSParameterフォーマットに従って構成した、対応するパラメータ１８０８、１８１０、１８１２のベクトルそれぞれと関連づける。例えば、SNMPプロトコル１８０２について、パラメータベクトル１８０８はSNMPプロトコルを用いて被監視装置（デバイス）にアクセスするために使用するパラメータ名、パラメータ値ペアのリストを含んでもよい。例えば、ベクトル１８０８に格納されるSNMPパラメータ名は、対応するパラメータ値とともに「コミュニティ名」と「パスワード」を含んでもよい。しかし、マップ構造体（構造）１８００の組織のプロトコルとそれに付随するパラメータベクトルの数はいくつでもよく、図１８に示したSNMP、HTTP、FTPプロトコルに限定はされない。
【０１１１】
サポートデータベース
図２０−２２は、図１０に示したサポートデータベース１０２４の組織を示す。サポートデータベースは、各被監視装置（デバイス）からのステータス情報を抽出するのに必要な情報を含み、通信プロトコルにより組織化されている。例えば、図２０は、被監視装置（デバイス）から情報を抽出するために使用するSNMP関係のサポート情報のサポートデータベースの組織を表し、SNMPVendor２００２、SNMPComVendorStatus２００４、EnumCorrespondence２００６、SNMPVendorModelStatus２００８データ構造体（構造）を含む。サポートデータベースのデータ構造体（構造）は、抽出を制御するパラメータと合わせて、抽出するステータス情報のタイプをユニークに特定するパラメータを含む。例えば、SNMPComVendorStatusデータ構造体（構造）２００４は抽出する情報のタイプ（例えば、トナーレベル）を特定するnENUMフィールド２００９と、他のプロトコルに関する抽出情報のウェイトや重要性を示すnRelativePriorityフィールド２０１０を含む。このように、同じ情報が２以上のプロトコルを用いて被監視装置（デバイス）から抽出される場合、nRelativePriority値はどのプロトコルで抽出された値を使用するかに関する表示を与える。例えば、HTTPはトナーレベルが高低を表示する情報だけを抽出でき、一方、SNMPプロトコルは残りのトナーのパーセンテージを抽出できる場合、SNMPのトナーレベルの優先レベルがHTTPの対応する値よりも高くなるであろう。また、サポートデータベースは、プロトコル全体のデフォルトの優先レベルを提供してもよい。一実施形態において、プロトコル値が０から32,000の範囲であるシステムにおいて、SNMPプロトコルは優先値10,000を与えられる。
【０１１２】
図２１と２２は、サポートデータベース１０２４のHTTPおよびFTP部分に含まれるデータ構造体（構造）を示し、図２０を参照して上で説明したデータ構造体（構造）に類似したデータ構造体（構造）を含んでいる。
【０１１３】
本発明で使用するenumタイプの例は下で定義するinfoTypeである。（enumタイプは単なる一例であり、本発明を限定するものとして解釈してはならない。）
infoType (typedef int infoType)
このセクションはinfoType(int)の定義を説明する。データタイプには０から９９までの範囲の値が割り当てられている。１００から４９９までの値の範囲が装置（デバイス）情報に割り当てられている。５００から１９９９の値の範囲が標準MIBパラメータを含む共通パラメータに割り当てられている。２０００から３９９９の範囲がリコー特有の情報に割り当てられている。４０００から４９９９の範囲がゼロックスに割り当てられている。５０００から５９９９の範囲がレックスマークに割り当てられている。６０００から６９９９がHPに割り当てられている。値は次のように定義されている。
【０１１４】
【表２】

EerrorCode
以下のコードは単なる一例であり、より多くのコードを既存のセットに加えてもよい。範囲０−９９は予約されている。範囲１００−１９９はSMTP用、２００−２９９はPOP3用、３００−３９９はSocket用、４００−４９９はHTTP用、５００−５９９はFTP用である。その他の明記しなかった範囲は、必要に応じてユーザが定義してもよい。
【０１１５】
【表３】


DeviceODBCモジュールの抽象型クラス
図１６は、本発明によるDeviceODBCモジュールクラス構造体（構造）を示し、DeviceODBCモジュール内でCAbsProtocolParametersをどのように使用するかを示している。CAbsProtocolParametersクラスは監視データベース１０１４とインターフェイスし、通信プロトコルを用いて被監視装置（デバイス）にアクセスする情報を取得するように設計されている。CabsProtocolParametersクラスはプロトコルに依存する２つの仮想関数を有する：
（１）std::string obtainProtocolName(void)；
（２）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プロトコルを通じてネットワーク装置（デバイス）にアクセスしてそのネットワーク装置（デバイス）から情報を取得する。そのパッケージはパッケージSNMPaccess２４０４とSNMPODBC２４０６およびクラスCSNMPProtocol２４０２を含み、図２３に示したようにクラスCAbsProtocol２４００とCRecordSet２４０８を使用する。SNMPaccessパッケージ２４０４はネットワーク装置（デバイス）にアクセスしそれから情報を取得するためにSNMPプロトコルを実装する。SNMPODBCパッケージ２４０６は、SNMPプロトコルによりサポートされたネットワーク装置（デバイス）のベンダーとモデルとSNMPプロトコルによりそのネットワーク装置（デバイス）から取得する情報に関する情報をデータベースにアクセスして取得する。CSNMPProtocolクラス２４０２はCAbsProtocolクラス２４００から導き出されたクラスである。CSNMPProtocol２４０２はSNMPプロトコルを用いてネットワーク装置（デバイス）から必要な情報を取得する。CSNMPProtocol２４０２は図２３に示したようにCAbsProtocol２４００のすべてのインターフェイス関数のメソッドを提供する。図２４は、CSNMPProtocol２４０２が使用するパッケージSNMPaccess２４０４とSNMPODBC２４０６の関数を示している。SNMPODBCパッケージ２４０６はクラスCRecordSet２４０８を使用しデータベースから情報を取得する。
【０１１８】
図２５は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はSNMPにより監視されるネットワーク装置（デバイス）のベンダーとモデルに関する情報と、それからステータス情報を取得するために使用する情報とを維持するためにCSNMPProtocolにより使用されるデータ構造体（構造）を示している。データ構造体（構造）はマップ５１０である。マップ５１０へのキーはネットワーク装置（デバイス）のベンダー名を表すストリング５１２である。マップ５１０への値は他のマップ５１４である。マップ５１４へのキーはネットワーク装置（デバイス）のモデル名を表すストリング５１６である。マップ５１４への値はペアのベクトル５１８である。そのペアには構造体（構造）SOIDinfoTypeと整数が含まれている。構造体（構造）SOIDinfoTypeはSNMPを用いてネットワーク装置（デバイス）から単一のステータス情報を取得するために使用する情報を含む。それゆえ、ペアのベクトル５１８は特定のベンダーとモデルのネットワーク装置（デバイス）のステータス情報をすべて取得するための情報を含む。マップ５１０は図２８を参照して説明したプロセスを用いて情報が初期化される。マップ５１０はベンダーのストリング５１２とモデルのストリング５１６のエントリー例を示している。
【０１２３】
図２７Cは、HTTPにより監視されているネットワーク装置（デバイス）のベンダーとモデルに関する情報と、それらからステータス情報を取得するために使用する情報とを維持するためにCHTTPProtocolにより使用されるデータ構造体（構造）を示す。データ構造体（構造）はマップ５２０である。マップ５２０へのキーはネットワーク装置（デバイス）のベンダー名を表すストリング５２２である。マップ５２０への値は他のマップ５２４である。マップ５２４へのキーはネットワーク装置（デバイス）のモデル名を表すストリング５２６である。マップ５２４への値はSWebPageInfoのベクトル５２８である。構造体（構造）SWebPageInfoは、HTTPを用いてネットワーク装置（デバイス）のウェブページからステータス情報をすべて取得するために使用する情報を含んでいる。それゆえ、SWebPageInfoのベクトル５２８は、そのウェブページのすべてから特定のベンダーとモデルのネットワーク装置（デバイス）のステータス情報をすべて取得するための情報を含んでいる。マップ５２０は図２８を参照して説明したプロセスを用いて情報が初期化される。マップ５２０は、ベンダーのストリング５２２とモデルのストリング５２６のエントリーの一例を示している。
【０１２４】
図２７Dは、FTPにより監視されるネットワーク装置（デバイス）のベンダーとモデルに関する情報と、それらからステータス情報を取得するために使用する情報とを維持するためにCFTPProtocolにより使用されるデータ構造体（構造）を示す。データ構造はマップ５３０である。マップ５３０へのキーはネットワーク装置（デバイス）のベンダー名を表すストリング５３２である。マップ５３０への値は他のマップ５３４である。マップ５３４へのキーはネットワーク装置（デバイス）のモデル名を表すストリング５３６である。マップ５３４への値は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は、様々なプロトコルで取得するステータス情報を維持するために使用するデータ構造体（構造）を示している。そのステータス情報を取得するためにどのプロトコルが使用されたかに関する情報は維持していない。このデータ構造体（構造）はマップ７２４である。マップ７２４へのキー７２６は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）のステータス情報を取得するための情報はベクトル８０６には加えない。このベクトル８０６はinfoType６００、６２０、７００、７１０のステータス情報を取得するため、FTPプロトコルにより使用される。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はベンダーモデルサポートマップ３２０６とそのサンプルエントリーを示す。マップ３２０６へのキー３２０８はベンダー名、セパレータ「%%%%%」、モデル名を含むストリングである。例えば、ベンダー「Xerox」とモデル「NC60」の場合、マップ３２０６へのキー３２０８のストリングは「Xerox%%%%%NC60」である。この例ではセパレータとして「%%%%%」を使用したが、ベンダー名とモデル名の一部と混同されないセパレータなら何でもよく、例えば「@@@@@」でもよい。セパレータを使用する理由は、ベンダーとモデルを区別し、ベンダーとモデルをストリングから容易に取得するためである。マップ３２０６への値３２１０は整数１である。マップ３２０６への値３２１０はいかなる整数であってもよい。各プロトコルについてベンダーモデルサポートマップ３２００が維持される。
【０１３７】
図３３は、プロトコルによりサポートされたベンダーとモデルをすべて含む、図３２Aのベンダーモデルサポートマップ３２００にサポートされたベンダーとモデルを加える方法を示すフローチャートである。ステップ３３０２において、データベースからベンダーとモデルを取得する。ベンダーとモデルをデータベースからいかに取得するかはプロトコルごとに異なる。これはサポートされたベンダーとモデルを含むデータベースのテーブルに依存する。ステップ３３０４において、データベースから取得するベンダーとモデルがあるかどうかをチェックする。取得するものがなければ、ステップ３３０６においてベンダーモデルサポートテーブル３２００にサポートされたベンダーとモデルを入れる方法は終了する。ベンダーモデルサポートマップ３２００はプロトコルによりサポートされたベンダーとモデルをすべて含む。サポートされたベンダーとモデルの情報を取得するためにデータベースにアクセスする必要はもうない。データベースから取得したベンダーとモデルがあるとき、ステップ３３０８においてベンダーモデルサポートマップ３２００のキーとして使用されるストリングを生成する。ストリングはベンダー名、セパレータ、モデル名を含む。前述の通り、セパレータはベンダー名やモデル名の一部と混同されないストリングであれば何でもよい。ステップ３３１０において、そのベンダー名、セパレータ、モデル名からなるストリングがベンダーモデルサポートマップ３２００にすでに有るかどうかチェックする。そのストリングがマップ３２００にすでにあれば、ステップ３３０２においてデータベースから他のベンダーとモデルを取得する。そのストリングがマップ３２００に無ければ、そのストリングと整数をマップ３２００に加える。そのストリングをマップ３２００に加えた後、ステップ３３０２においてデータベースから他のベンダーとモデルを取得する。
【０１３８】
図３４は、図３２Aのベンダーモデルサポートマップ３２００からプロトコルによりサポートされたベンダーとモデルを取得する方法を説明するためのフローチャートである。ステップ３４０２において、キーのストリングをベンダーモデルサポートマップ３２００から取得する。ステップ３４０４において、マップ３２００から取得するためにまだキーが有るかどうかチェックする。キーがもうなければ、プロトコルによりサポートされたベンダーとモデルはすべて取得されており、ステップ３４０６でベンダーとモデルの取得が終了する。キーのストリングをマップ３２００から取得すると、ステップ３４０８においてベンダー名を取得するためにセパレータの前のサブストリングを取得する。ステップ３４１０において、モデル名を取得するため、セパレータの後のサブストリングを取得する。その後、ステップ３４０６において、ベンダーとモデルの取得が終了する。マップ３２００のエントリーをすべて通り、プロトコルによりサポートされたベンダーとモデルがすべて取得できる。
【０１３９】
図３５はデバイスパッケージを示すパッケージ図である。このパッケージはネットワーク装置（デバイス）を表すソフトウェアオブジェクトを生成する役割を担っている。デバイスパッケージ１３００はCDeviceFactory１３０２とCDevice１３０４の２つのクラスにより構成されている。クラスCDeviceFactory１３０２はネットワーク装置（デバイス）のソフトウェアオブジェクトを生成し初期化する役割を担っている。ソフトウェアオブジェクトの初期化は、ネットワーク装置（デバイス）のベンダー、モデル、ユニーク識別子を決定し、そのネットワーク装置（デバイス）にアクセスするために使用できるプロトコルを設定することを含んでいる。ネットワーク装置（デバイス）にアクセスできないとき、ネットワーク装置（デバイス）のソフトウェアオブジェクトは生成されない。クラスCDevice１３０４はネットワーク装置（デバイス）のソフトウェアオブジェクトを表す。CDevice１３０４はネットワーク装置（デバイス）に関する情報を維持し、そのネットワーク装置（デバイス）に関するステータス情報を取得する。CDevice１３０４は、装置（デバイス）から情報を取得するために、様々なプロトコルを通してネットワーク装置（デバイス）にアクセスするために、HWaccessパッケージ１３０６を用いる。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のベクトルはコミュニティ名に関する情報を含む。パラメータ名COMMUNITYとパラメータ値「private」を用いて、１つのSParameterにネットワーク装置（デバイス）にアクセスさせる。ネットワーク装置（デバイス）にFTPを用いてアクセスするためには、ユーザ名とパスワードが必要である。FTPのSParameterのベクトルはユーザ名とパスワードに関する情報を含む。パラメータ名USERNAMEとパラメータ値「abc」を用い１つのSParameterをネットワーク装置（デバイス）にアクセスさせ、パラメータ名PASSWORDとパラメータ値「xyz」を用い、他のSParameterをネットワーク装置（デバイス）にアクセスさせる。
【０１４２】
図３７は、ネットワーク装置（デバイス）からステータス情報を取得するためにどのプロトコルを使用するかを決定するために、図３６Aのプロトコルパラメータマップ１４００をいかに更新するかを説明するフローチャートである。図３７のステップを実行し、プロトコルについてネットワーク装置（デバイス）のベンダー名とモデル名を取得する。ステップ３７０２において、プロトコルを用いてネットワーク装置（デバイス）にアクセスできる化チェックする。ネットワーク装置（デバイス）はマップ１４００の情報を用いてそのプロトコルを通じてアクセスする。そのプロトコルを通じてそのネットワーク装置（デバイス）にアクセスできないとき、ステップ３７０４においてプロトコルパラメータマップ１４００からそのプロトコルを削除し、ステップ３７１４でマップ１４００の更新が終了する。そのネットワーク装置（デバイス）にそのプロトコルを通じてアクセスできるとき、ステップ３７０６でそのネットワーク装置（デバイス）のベンダーをそのプロトコルを用いて取得できるかどうかチェックする。ベンダーを取得できないとき、ステップ３７０７において、ジェネリックベンダーがそのプロトコルでサポートされているかどうかチェックする。プロトコルがジェネリックベンダーをサポートしているとは、プロトコルがその装置（デバイス）のベンダーを取得できないか、またはサポートしていないときでも、プロトコルがすべての装置（デバイス）に共通なステータス情報（共通ステータス情報）を取得することできることを意味する。そのプロトコルによりジェネリックベンダーがサポートされていないとき、ステップ３７０４でそのプロトコルはプロトコルパラメータマップ１４００から削除され、ステップ３７１４でマップ１４００の更新が終了する。そのプロトコルがジェネリックベンダーをサポートしているとき、そのプロトコルはプロトコルパラメータマップ１４００に残され、ステップ３７１４でマップの更新が終了する。ステップ３７０６でベンダーを取得できたとき、ステップ３７０８でそのネットワーク装置（デバイス）のベンダーがプロトコルでサポートされているかどうかチェックする。ベンダーがそのプロトコルによりサポートされていないとき、ステップ３７０７でジェネリックベンダーがそのプロトコルによりサポートされているかどうかチェックする。ステップ３７０７以降のステップのシーケンスは上で説明した。
【０１４３】
ベンダーがそのプロトコルでサポートされているとき、ステップ３７１０で、値とワーク装置（デバイス）のモデルがそのプロトコルを用いて取得できるかどうかチェックする。モデルを取得できないとき、ステップ３７１１で、ジェネリックモデルがそのプロトコルでサポートされているかどうかをチェックする。プロトコルがジェネリックモデルをサポートしているとは、装置（デバイス）のモデルを取得できず、またはサポートしていなくても、プロトコルがベンダーのすべての装置（デバイス）に共通なステータス情報（ベンダースペシフィックステータス情報）を取得できることを意味する。ジェネリックモデルをプロトコルがサポートしていないとき、ステップ３７０４でそのプロトコルはプロトコルパラメータマップ１４００から削除され、ステップ３７１４でマップ１４００の更新が終了する。ジェネリックモデルがプロトコルによりサポートされているとき、そのプロトコルはプロトコルパラメータマップ１４００に残され、マップの更新はステップ３７１４で終了する。ステップ３７１０でモデルを取得できるとき、ステップ３７１２でそのネットワーク装置（デバイス）のモデルがプロトコルによりサポートされているかどうかチェックする。そのモデルがプロトコルでサポートされていないとき、ステップ３７１１で、ジェネリックモデルをそのプロトコルがサポートしているかどうかチェックする。ステップ３７１１に続くステップのシーケンスについてはすでに説明した。そのモデルがプロトコルによりサポートされているとき、そのプロトコルを用いてネットワーク装置（デバイス）のステータス情報を取得でき、ステップ３７１４でプロトコルパラメータマップ１４００の更新は終了する。ベンダーとモデルが取得またはサポートされていないとき、そのプロトコルはプロトコルパラメータマップ１４００から削除し、そのプロトコルはステータス情報を取得するためには使用されない。プロトコルに応じて図３７に示したプロセスにはバリエーションがある。HTTPとFTPはフローチャートの説明通りだが、ベンダーがサポートされモデルとジェネリックモデルはサポートされていなくても、SNMPはサポートされステータス情報を取得するために使用することができる。
【０１４４】
上で説明したように、ベンダーとモデルが取得またはサポートされていなくても、ステータス情報をネットワーク装置（デバイス）からSNMPにより取得できる。ネットワーク装置（デバイス）がSNMPをサポートし、またSNMPによりアクセスできる限り、そのネットワーク装置（デバイス）の管理情報ベース（MIB）から情報を取得することができる。ステップ３７０２において、ネットワーク装置（デバイス）がSNMPを通じてアクセスできないとき、ステップ３７０４でSNMPプロトコルはプロトコルパラメータマップ１４００から削除される。しかし、ネットワーク装置（デバイス）にSNMPでアクセスできるとき、ベンダーやモデルが取得及びサポートされているかどうかにかかわらず、SNMPプロトコルはプロトコルパラメータマップ１４００に残される。SNMPをサポートするネットワーク装置（デバイス）は、リモートシステムがその装置（デバイス）から情報を常に取得可能であるように、MIBを提供する。しかし、ネットワーク装置（デバイス）から取得可能な情報のタイプと数は、ベンダーとモデルが取得およびサポートされるかどうかに依存する。ベンダーとモデルが取得され、かつ既知であれば、SNMPによりネットワーク装置（デバイス）からより多くの情報を取得することができる。ベンダーとモデルを取得できなくても、SNMPはすべての装置（デバイス）が提供できる情報は取得可能である。例えば、システム説明やシステムが稼働している時間等は取得可能である。SNMPは次の３つの条件の下でネットワーク装置（デバイス）から情報を取得するために使用できる：（１）ベンダーとモデルがサポートされている；（２）ベンダーはサポートされているが、モデルはサポートされていない；（３）ベンダーもモデルもサポートされていない。HTTPとFTPはSNMPのような特徴は有していない。情報を取得できるようにすべてのネットワーク装置（デバイス）が従うことができる標準MIBをSNMPが有している場合、ウェブページとFTPファイルは異なるベンダーとモデルのネットワーク装置（デバイス）ごとに異なる。ネットワーク装置（デバイス）が情報を取得するために従うウェブページとFTPファイルの標準はない。
【０１４５】
図３９は、infoTypeの抽出を処理するために使用されるオブジェクトへのインターフェイスを定義する抽象型クラスと、被監視装置（デバイス）から取得された情報からの対応する値を示している。infoTypeは情報のタイプを示す非ゼロ整数値である。例えば、７００のinfoTypeはブラックトナーレベルに関する情報に対応する。infoTypeの値の例は上で説明した。関数transformData()とend()は、被監視装置（デバイス）からの情報から抽出したinfoTypeとそれに対応する値を返す。入力ストリングから１つ以上のinfoTypeと対応値を得ることができるとき、transformData()とend()の出力は値とinfoTypeのペアのベクトルと定義することができる。関数putParameters()は、infoTypeと値を抽出するためにtransformData()とend()により使用されるオブジェクトの情報を提供する。同様に、putParameters()を修正して、transformData()を通じてより複雑な抽出メソッドを可能とすることができる。抽象型クラスはinfoTypeと値を抽出するためにインターフェイス関数を提供する。CAbsDevDataProcessの派生クラスは関数が被監視装置（デバイス）からinfoTypeと値を抽出する実際のメソッドを提供する。抽象型クラスにより、infoTypeと値を抽出する新しいメソッドの新しいクラスをシステムに加えることができる。
【０１４６】
図４０は、図２６に示したFTPモジュールのクラスストラクチャの改良を示している。関数名は同じだが、obtainFTPVendor()、obtainFTPDirFileInfo()、obtainValueFromFTPFile()、obtainDataFromFTPFile()のパラメータは変更した。主な変更点は、CAbsDevDataFTPFile()へのポインタと重みマップにおいて、被監視装置（デバイス）から情報を取得するために用いる情報を置き換えた点である。装置（デバイス）から情報を取得するために使用する情報は、CAbsDevDataProcessのオブジェクトにカプセル化される。重みマップは、FTPで被監視装置（デバイス）から取得した情報が他のプロトコルですでに取得されていた同じ情報より情報が多いかどうかを決定するために用いられる。図５９乃至６１に示した補遺１から３は、関係クラス、すなわちCFTPProtocol、CFTPODBC、CFTPaccessの仕様を数字で示している。CFTPProtocolはFTPモジュールを管理して装置（デバイス）から情報を取得する。CFTOPDBCは、情報を取得するためにFTPを介してアクセスできる装置（デバイス）のベンダーとモデルおよび情報の取得方法を決定するためにデータベースにアクセスするFTPODBCパッケージを管理する。CFTPaccessは、装置（デバイス）にアクセスするFTPセッションを提供するFTPaccessパッケージを管理する。これらの補遺はデータ構造とインターフェイス関数を示している。
【０１４７】
図４１はFTPODBCパッケージの構造を示す。それはFTPaccessパッケージの派生クラスCXXXDevDataProcessを使用する。図６０に示した補遺２は、これらの追加されたクラスのオブジェクトを生成する関数createXXX()を示す。CFTPODBCのコンストラクタにおいて、関数init()とsetupCreateFunctionMap()が呼び出される。関数init()はデータベースからFTPがサポートされているベンダーとモデルに関する情報を取得する。関数setupCreateFunctionMap()は、ストリング（マップのキー）と生成関数（マップのキーに対応する値）へのポインタよりなるマップm_createFunctionMapアトリビュートにエントリーする。マップのキーはベンダー名、モデル名、ディレクトリ名、ファイル名よりなるストリングである。ディレクトリ名とファイル名は、情報を装置（デバイス）から抽出するFTPファイルに対応する。その値は、装置（デバイス）から抽出された情報からinfoTypeと値を抽出するために使用する派生クラスCAbsDevDataProcessの１つを生成する関数へのポインタである。マップにはFTPをサポートするすべての装置（デバイス）に関する情報が含まれる。
【０１４８】
図４２は、派生クラスCXXXDevDataProcessがパッケージに加えられたFTPaccessパッケージを示す。CAbsDevDataProcessの派生クラスはデバイスから取得された情報からデータを抽出する異なるメソッドを提供する。データを抽出する新しいメソッドがある時、新しいクラス、すなわち異なるデータフォーマットを有する新しいFTPファイルを追加することができる。
【０１４９】
図４３から４５は、CFTPProtocolクラスのm_VendorModelSupportMap、m_VendorInfoVector、m_SupportStatusInfoMapをそれぞれ示している。これらのデータ構造の情報はすべてODBCパッケージを通してデータベースから取得できる。
【０１５０】
図４３はFTPプロトコルによりサポートされたベンダーとモデルを示す。
【０１５１】
図４４は、被監視装置（デバイス）のベンダー、モデル、ユニークIDに関する情報を取得するCFTPProtocolクラスにより使用されるSVendorInfoストラクトのベクトルを示す。m_sXXXDirとm_sXXXFileは、モデル名とユニークIDを抽出できるFTPファイルのディレクトリとファイル名を示す。CAbsDevDataProcessへのポインタm_pAbsDevDataProcessはFTPファイルからモデル名とユニークIDを抽出する方法を提供する。
【０１５２】
図４５は、被監視装置（デバイス）から情報を抽出するために使用するマップ構造を示す。マップ構造中のベンダーとモデルに対してSDirFileStatusInfoストラクトのベクトルがある。ベンダーとモデルは情報を抽出する複数のFTPファイルを有することもある。各FTPファイルに対して、SDirFileStatusInfoストラクトが対応する。m_sDirectoryとm_sFileはFTPファイルのディレクトリとファイル名を示し、infoTypeと値を装置（デバイス）のFTPファイルから抽出することができる。CAbsDevDataProcessへのポインタm_pAbsDevDataProcessはFTPファイルからinfoTypeと値を抽出するメソッドを提供する。マップm_InfoTypeMapは、FTPファイルから取得したinfoTypeと値が他のプロトコルを通じて取得した情報より情報が多いかどうかを決定するために使用する重みマップである。
【０１５３】
図４６から５１はCFTPODBCで使用するデータ構造を示している。これらの構造には、図２２を参照して説明したようにデータベースから取得した情報が入っている。
【０１５４】
図４６は、FTPファイルのディレクトリとファイル名に関する情報を含むマップ構造であり、infoTypeと値はFTPサポートがあるすべてのベンダーとモデルについて抽出可能である。各ディレクトリとファイル名に対して、対応する識別子がある。
【０１５５】
図４７は、図４６のベンダーとモデルについてマップのSDirFileIDInfoのベクトルの１つを格納するために使用される。図４６と４７は図２２のデータベース構造を取り扱うために使用する。図４８は図３２Bと同様である。
【０１５６】
図４９は、エントリーの一例が入ったm_createFunctionMapのデータ構造を示す。テーブルの左側（マップのキー）は、ベンダー名、モデル名、ディレクトリ名、ファイル名により構成され文字「%」で分離されているストリングを示す。ベンダー名、モデル名、ディレクトリ名、ファイル名の一部でなければ「%」以外のいかなる文字を用いてもよい。ストリングはFTPファイルに対応し、情報をそれから抽出することができる。テーブルの左側は、ベンダー名、ディレクトリ名、ファイル名、ディレクトリ名、ファイル名が文字「%」で分離されたストリングでもよい。このストリングは装置（デバイス）のモデル名とユニークIDを含むベンダーのFTPファイルに対応する。テーブルの右側（マップの値）はcreateXXX()関数のポインタを含む。これらの関数は図４１と４２のCXXXDevDataProcessのオブジェクトを生成する。このテーブルには、CFTPODBCのコンストラクタで呼び出される関数setupCreateFunctionMap()が入っている。このテーブルは、ベンダー、モデル、ディレクトリ、ファイル名（または、ベンダー、ディレクトリ、ファイル、ディレクトリ、ファイル）に対応する適当なCXXXDevDataProcessオブジェクトを生成するために使用される。ベンダー、モデル、ディレクトリ、ファイル名の各組み合わせに対して、ベンダーとモデルがFTPをサポートすれば情報を抽出するためのCAbsDevDataProcessの派生クラスがある。このように、ベンダー、モデル、ディレクトリ、ファイル名の各組み合わせに対してCAbsDevDataProcessの派生クラスを生成するcreateXXX()関数がある。例えば、FTPファイルsyslogを有するリコージェネリックデバイス（すべてのリコーデバイス）について、装置（デバイス）から情報を抽出するためにCSyslogDevDataProcessを生成するm_createFunctionMapにcreateSyslog()へのポインタがある。ベンダー、ディレクトリ、ファイル、ディレクトリ、ファイルを含むキーについても同様である。CFTPODBCのコンストラクタがsetupCreateFunctionMap()を呼び出す時、このマップはハードコードされていなければならない。このマップのデータは他のソースからは来ない。
【０１５７】
図５０は、CFTPODBCのm_DirFileInfoDevDataProcessMapのデータ構造を示している。このデータ構造は、被監視装置（デバイス）からステータス情報を取得するために使用されるCFTPProtocolに送られる情報を含む。テーブルの左側（マップのキー）は、図４９と同様に、ベンダー名、モデル名、ディレクトリ名、ファイル名が文字「%」で分けられたストリングである。しかし、テーブルの右側（マップの値）は、CAbsDevDataProcessへのポインタとマップよりなるペアが示されている。ポインタはCAbsDevDataProcessクラスのタイプであるが、図４１と４２に示したCAbsDevDataProcessから導かれたクラスの１つである。派生クラスは図４９のテーブルに対応する関数の１つにより生成される。図４９のテーブルのキーに対応するcreateXXX()関数は、同じキーに対応する図５０のテーブルに入れられるCAbsDevDataProcessの派生クラスを生成する。例えば、図４９のテーブル中のキー「RICOJ%GENERIC%%stat」に対応する関数createStat()は、CStatDevDataProcessオブジェクトを生成し、それを同じキーに対応する図５０のテーブルに入れる。図５０のペアのマップInfoTypeWeightMapはinfoTypeとそれに関連する重みを示している。これらの値はnRelativePriorityとnENUMに対応する図２２から取得される。このマップは、他のプロトコルを介してすでに取得されたステータスデータのinfoTypeがFTPにより取得される情報より優先度が低いかどうかをチェックするのに用いる。このマップ構造は図２２のデータベースからの情報で初期化される。図５６Aから５６Cはテーブルにいかにエントリーするかを示している。データベースの情報が、CXXXDevDataProcessオブジェクトが装置（デバイス）から取得した情報からinfoTypeと値をいかに抽出するかを知るように、putParameter()関数を通してCXXXDevDataProcessオブジェクトにいかに送られるかに注意せよ。
【０１５８】
図５１は、CFTPODBCのm_VendorDevDataProcessMapのデータ構造を示している。このデータ構造は、装置（デバイス）からモデルとユニークIDを取得するために使用する情報を含む。テーブルの左側は、ベンダー名、ディレクトリ名、ファイル名、ディレクトリ名、ファイル名が文字「%」で区切られたストリングである。第１のディレクトリとファイル名は装置（デバイス）のモデル名を含むFTPファイルに対応する。第２のディレクトリとファイル名は装置（デバイス）のユニークIDを含むFTPファイルに対応する。右側はCAbsDevDataProcessタイプオブジェクトへのポインタである。しかし、実際のタイプは図４１と４２のCAbsDevDataProcessの派生クラスの一つへのポインタであり、図４９のテーブル中のcreateXXX()関数の一つにより生成される。このマップ構造は、図２２のデータベースからの情報で初期化される。図５５Aと５５Bはテーブルにいかにエントリーが入れられるかを示している。装置（デバイス）からモデル名とユニークIDをいかに抽出するかをCXXXDevDataProcessオブジェクトが知るように、putParameter()関数を通じてCXXXDevDataProcessオブジェクトにデータベースの情報がいかに送られるかに特に注意せよ。
【０１５９】
図５２Aと５２Bは関数initBegin()を通じたCFTPProtocolの初期化を示している。第１に、この関数はFTPODBCパッケージを通じてデータベースからFTPサポートのあるベンダーとモデルを取得する。CFTPProtocolはベンダーとモデルを取得するためCFTPODBCパッケージのobtainFTPSupportVendorModel()を呼び出す。CFTPProtocolはサポートされているすべてのベンダーとモデルが入っている。次に、データベースから取得した各ベンダーとモデルについて、装置（デバイス）からinfoTypeと値を抽出するために使用する情報を、FTPODBCを通じてデータベースから取得する。CFTPProtocolはCFTPODBCのobtainFTPDirFileInfo()を呼び出し、ディレクトリ、ファイル、重みマップ、CXXXDevDataProcessオブジェクトを取得する。この関数により返された情報はCFTPProtocolに入れられ、装置（デバイス）から情報を取得するために必要とされる。最後に、FTPをサポートしているすべてのベンダーのモデル名とユニークIDをいかに取得するかについての情報を、FTPODBCパッケージを通してデータベースから取得する。CFTPProtocolはCFTPODBCのobtainFTPVendor()を呼び出し、ベンダー、ディレクトリ、モデル名が有る場所のファイル、ユニークIDがある場所のディレクトリとファイル、CXXXDevDataProcessオブジェクトを取得する。この関数により返される情報はすべてCFTPProtocolに入れられ、装置（デバイス）のモデル名とユニークIDを取得するために使用される。
【０１６０】
図５３は、特定のベンダーとモデルの装置（デバイス）のステータス情報を取得するCFTPProtocolの関数obtainStatus()を示すフローチャートである。最初に、CFTPProtocolが装置（デバイス）とのFTPセッションを初期化する。次に、CFTPProtocolはそのプライベート関数obtainStatusUsingSDirFileStatusInfoVector()を呼び出して、装置（デバイス）からベンダースペシフィックステータス情報の取得を試みる。ベンダースペシフィックステータス情報は、特定のベンダーのいかなるモデルからでも取得可能な情報である。「ジェネリック」はベンダーに関連するすべてのモデルから取得できる情報を示す。次に、CFTPProtocolはそのプライベート関数obtainStatusUsingSDirFileStatusInfoVector()を呼び出すことにより、装置（デバイス）からその装置（デバイス）のモデルに固有のステータス情報を取得することを試みる。最後に、CFTPProtocolはFTPセッションを閉じる。
【０１６１】
図５４は上記のobtainStatus()関数により使用されるプライベート関数obtainStatusUsingSDirFileStatusInfoVector()のフローチャートを示す。このフローチャートは、スタートから４つめのステップにおいて、プライベート関数selectInfoTypeMap()も組み込む。selectInfoTypeMap()は、重みマップとすべてのプロトコルを通して取得したステータス情報すべてを含むステータスマップとを処理し、FTPを通して取得した情報の重みが他のプロトコルによりすでに取得されている情報の重みより大きいかどうかを決定する。obtainStatusUsingSDirFileStatusInfoVector()は、まず各情報の重みに基づきFTPによりどの情報が取得されるかを決定するため、selectInfoTypeMap()を呼び出す。その後、obtainStatuUsingSDirFileStatusInfoVector()はobtainDataFromFTPFile()を呼び出し、FTPファイルからすべてのステータス情報を取得する。ディレクトリ名、ファイル名、重みマップ、CXXXDevDataProcessオブジェクトはFTPファイルからステータス情報を取得するためにこの関数に送られる。
【０１６２】
図５５Aと５５Bは、CFTPODBCのパブリック関数obtainFTPVendor()のフローチャートを示す。まず、CFTPODBCはベンダー、ディレクトリ名、ファイル名、FTPファイルからモデル名を取得するために使用するキー、ディレクトリ名、ファイル名、FTPファイルからユニークIDを取得するために使用するキーを取得する。次に、ベンダー、ディレクトリ、ファイル、ディレクトリ、ファイル名とこれらを区切る「%」からストリングを形成する。図４９のテーブルm_createFunctionMapのキーとして使用するストリングを用いて、createXXX()関数の１つを呼び出し、CAbsDevDataProcessの派生クラスの１つを生成する。FTPファイルからモデルとユニークIDを見つけるために使用するキーはputParameter()関数によりCAbsDevDataProcessの派生クラスに置かれる。CFTPODBCがこの情報をCFTPProtocolに提供できるように、CAbsDevDataProcessの派生クラスは図５１のテーブルm_VendorDevDataProcessMapに置かれる。
【０１６３】
図５６A−５６CはCFTPODBCのパブリック関数obtainFTPDirFileInfo()のフローチャートを示している。ベンダーとモデル名を入力されると、この関数はFTPファイルのディレクトリとファイル名、重みマップ、装置（デバイス）からinfoTypeと値を取得するために使用されるCXXXDevDataProcessを返す。ベンダーとモデルは、ステータス情報を取得することができる１以上のFTPファイルを有している。このように、この関数は、ステータス情報を取得できるすべてのFTPファイルと、装置（デバイス）からステータス情報をいかに抽出するかということとに関する情報を取得するため、同じ入力ベンダーとモデルに対して、複数回呼び出される。この関数は図４６のマップm_VendorModelSupportMapを用い、入力ベンダーとモデルについてすべてのFTPファイルを取得する。装置（デバイス）からステータス情報を取得するために使用されるベンダー、モデル、ディレクトリ、ファイル名に対してCXXXDevDataProcessオブジェクトを生成する適当なcreateXXX()関数を使用するために、図４９のマップm_createFunctionMapを使用する。一旦CXXXDevDataProcessオブジェクトを生成すると、FTPファイルからステータス情報を取得するための情報をデータベースから取得し、putParameters()関数を通してCXXXDevDataProcessオブジェクトと重みマップに格納する。入力ベンダーとモデルのFTPファイルからステータス情報を取得するために使用するすべての情報は、この関数により返されるだけでなく、図５０のマップm_DirFileInfoDevDataProcessMapに格納される。
【０１６４】
図５７はCFTPaccessの関数obtainValueFromFTPFile()のフローチャートを示している。この関数は、入力infoType（in_infoType）に対応するFTPファイルから単一の値を取得する。このシステムにおいて、この関数は装置（デバイス）のモデル名とユニークIDを取得するために使用されるが、他のいかなるタイプの情報を取得するためにも使用できる。このフローチャートにはm_FTPFileProcessorのobtainValueFromFile()の関数が組み込まれている。この関数において、装置（デバイス）のFTPファイルが最初に開かれる。そして、FTPファイルからラインを取得する。そのラインはtransformData()関数を通してFTPファイルに対応するCXXXDevDataProcessオブジェクトに格納される。infoTypeと値がラインから抽出されたとき、transformData()により返される。所望のinfoTypeを取得したかどうかチェックする。もし所望のinfoTypeでなければ、関数がFTPファイルからラインを継続的に取得し、所望のinfoTypeが得られるまで、CXXXDevDataProcessオブジェクトのtransformData()関数に入れる。FTPファイルの終わりに来たら、CXXXDevDataProcessオブジェクトが呼び出され、infoTypeと値を取得し、所望のinfoTypeであるかどうかチェックする。
【０１６５】
図５８は、CFTPaccessの関数obtainDataFromFTPFile()のフローチャートを示している。この関数はFTPファイルから１以上の情報を取得する。このシステムにおいて、この関数はinfoTypeと値を含むマップ（in_WeightMap）で特定された装置（デバイス）のステータス情報を取得するために使用される。フローチャートにはm_FTPFileProcessorのobtainDataFromFTPFile()の機能が組み込まれている。この関数では、装置（デバイス）のFTPファイルが最初に開かれる。そして、FTPファイルからラインを取得する。そのラインをtransformData()関数を通じてFTPファイルに対応するCXXXDevDataProcessに入れる。そのラインからinfoTypeと値が抽出されれば、transformData()により返される。infoTypeが重みマップにあるinfoTypeであるかどうかチェックする。もしそうなら、そのinfoTypeの重みがデータマップ中のinfoTypeの重みよりも大きい場合にのみ、そのinfoTypeをデータマップに加える。そのinfoTypeが所望のものでないとき、関数が引き続きFTPファイルからラインを取得し、CXXXDevDataProcessオブジェクトのtransformData()関数に入れ、重みマップにある所望のinfoTypeのいずれかを取得する。FTPファイルの終わりに来たとき、CXXXDevDataProcessオブジェクトのend()関数を呼び出し、infoTypeと値を取得し、所望のinfoTypeであるかどうかチェックする。監視が必要でネットワークに接続された少数の装置（デバイス）を含めて本発明を示したが、当然のことながら、本発明の精神と範囲から逸脱することなく、ネットワークに接続する装置（デバイス）の数はいくつであってもよい。また、本発明は様々な装置（デバイス）を監視かつ制御する必要があるホーム環境に適用してもよい。
【０１６６】
本発明によれば、マルチベンダー環境において様々な装置（デバイス）の監視が可能となり、特定のプライベートなマネージメント情報ベース（MIB）情報を有さなくても、詳細な情報を読み出し、ユーザが理解しやすく扱いやすいやり方で表示することができる。
【０１６７】
実施形態においては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のデータ構造を更新して決定するかを示すフローチャートである。
【図３８Ａ】FTPを用いて異なるタイプのファイルから異なるタイプのデータを抽出することができる必要性の一例を示す図である。
【図３８Ｂ】FTPを用いて異なるタイプのファイルから異なるタイプのデータを抽出することができる必要性の一例を示す図である。
【図３８Ｃ】FTPを用いて異なるタイプのファイルから異なるタイプのデータを抽出することができる必要性の一例を示す図である。
【図３９】infoTypeの抽出を処理するために使用するオブジェクトのインターフェイスを規定する抽象型クラスと、被監視装置（デバイス）から取得した情報からの対応する値を示す図である。
【図４０】図２６に示したFTPモジュールのクラス構造を改良したものを示す図である。
【図４１】FTPODVBCパッケージの変化を示す図であって、FTPaccessパッケージの導出クラスCXXXDevDataProcessを使用するものである。
【図４２】FTPaccessパッケージを示し、導出クラスCXXXDevDataProcessはそのパッケージに加えられる。
【図４３】CFTPProtocolクラスのデータ構造m_VendorModelSupportMapを示す図である。
【図４４】CFTPProtocolクラスのデータ構造m_VendorInfoVectorを示す図である。
【図４５】CFTPProtocolクラスのデータ構造m_SupportStatusInfoMapを示す図である。
【図４６】CFTPODBCで使用されるデータ構造を示す図である。
【図４７】CFTPODBCで使用されるデータ構造を示す図である。
【図４８】CFTPODBCで使用されるデータ構造を示す図である。
【図４９】CFTPODBCで使用されるデータ構造を示す図である。
【図５０】CFTPODBCで使用されるデータ構造を示す図である。
【図５１】CFTPODBCで使用されるデータ構造を示す図である。
【図５２Ａ】関数initBegin()を用いたCFTPProtocolの初期化を示す図である。
【図５２Ｂ】関数initBegin()を用いたCFTPProtocolの初期化を示す図である。
【図５３】CFTPProtocolの関数obtainStatus()を示すフローチャートである。
【図５４】obtainStatus()関数により使用されるプライベート関数obtainStatusUsingSDirFileStatusInfoVentor()を示すフローチャートである。
【図５５Ａ】CFTPODBCのパブリック関数obtainFTPVendorを示すフローチャートである。
【図５５Ｂ】CFTPODBCのパブリック関数obtainFTPVendorを示すフローチャートである。
【図５６Ａ】CFTPODBCのパブリック関数obtainFTPDirFileInfor()を示すフローチャートである。
【図５６Ｂ】CFTPODBCのパブリック関数obtainFTPDirFileInfor()を示すフローチャートである。
【図５６Ｃ】CFTPODBCのパブリック関数obtainFTPDirFileInfor()を示すフローチャートである。
【図５７】CFTPaccessの関数obtainValueFromFTPFile()を示すフローチャートである。
【図５８】CFTPaccessの関数obtainDataFromFTPFile()を示すフローチャートである。
【図５９Ａ】補遺１CFTPProtocolクラス仕様を示す図である。
【図５９Ｂ】補遺１CFTPProtocolクラス仕様（続き）を示す図である。
【図５９Ｃ】補遺１CFTPProtocolクラス仕様（続き）を示す図である。
【図５９Ｄ】補遺１CFTPProtocolクラス仕様（続き）を示す図である。
【図６０Ａ】補遺２CFTPODBCクラス仕様を示す図である。
【図６０Ｂ】補遺２CFTPODBCクラス仕様（続き）を示す図である。
【図６０Ｃ】補遺２CFTPODBCクラス仕様（続き）を示す図である。
【図６０Ｄ】補遺２CFTPODBCクラス仕様（続き）を示す図である。
【図６１Ａ】補遺３CFTPaccessクラス仕様を示す図である。
【図６１Ｂ】補遺３CFTPaccessクラス仕様（続き）を示す図である。
【符号の説明】
【０１７３】
２４ デジタルコピー／プリンター
２７ オフィス機器
２８ ファクシミリ
３２ プリンター
５０Ａ ファイヤーウォール
５０Ｂ ファイヤーウォール
５０Ｃ ファイヤーウォール
１６６ 多ポートネットワークI/F
１７２ IFコントローラ
１７４ 操作パネル
１７６ 記憶I/F
１７８ フラッシュメモリ
１８４ オプションI/F
１８７ クロック／タイマー
１７１ ローカル接続
１８８ オプショナルユニットインターフェイス
１９０ フューザ
１９２ プリンター／イメージャ
１９４ スキャナー
１９６ ペーパーフィードコントローラ
１９８ 大容量トレイ部
２００ デュプレクサ
２０２ ソータ

【特許請求の範囲】
【請求項１】
ネットワークを介して被監視デバイスに関するステータス情報を選択された通信プロトコルにより抽出する方法であって、
前記被監視デバイスに関する少なくともベンダー情報を取得するために前記選択された通信プロトコルを用いて前記被監視デバイスにアクセスするステップと、
前記被監視デバイスのアクセス可能データファイルから前記ステータス情報を抽出するアクセス関数を特定する情報を第１のメモリから取得するステップと、
前記取得したベンダー情報と前記取得したアクセス関数情報に基づきストリングを生成するステップと、
前記生成されたストリングに応じて第２のメモリから、（１）前記アクセス関数に関連したデータ処理オブジェクトの情報と、（２）前記被監視デバイスから抽出するステータス情報の少なくともタイプおよび前記ステータス情報に関連する重みを含む情報マップとを読み出すステップと、
前記ステータス情報を取得するため、前記アクセス関数、前記情報マップ、および前記選択された通信プロトコルを用いて前記被監視デバイスにアクセスするステップとを有することを特徴とする方法。
【請求項２】
請求項１に記載の方法であって、
前記被監視デバイスに関するモデル情報を取得するため前記被監視デバイスにアクセスするステップをさらに有し、
前記生成するステップは前記ベンダーと前記モデル情報を用いて前記ストリングを生成するステップを有することを特徴とする方法。
【請求項３】
請求項１に記載の方法であって、
前記被監視デバイスから前記ステータス情報を抽出するために仕様する複数の通信プロトコルの各々について、前記アクセス、取得、生成、読み出し、およびアクセスステップを繰り返すステップをさらに有することを特徴とする方法。
【請求項４】
請求項１に記載の方法であって、
SNMP、HTTP、およびFTPから前記通信プロトコルを選択するステップをさらに有することを特徴とする方法。
【請求項５】
ネットワークを介して被監視デバイスに関するステータス情報を選択された通信プロトコルにより抽出する装置であって、
前記被監視デバイスに関する少なくともベンダー情報を取得するために前記選択された通信プロトコルを用いて前記被監視デバイスにアクセスする手段と、
前記被監視デバイスのアクセス可能データファイルから前記ステータス情報を抽出するアクセス関数を特定する情報を第１のメモリから取得する手段と、
前記取得したベンダー情報と前記取得したアクセス関数情報に基づきストリングを生成する手段と、
前記生成されたストリングに応じて第２のメモリから、（１）前記アクセス関数に関連したデータ処理オブジェクトの情報と、（２）前記被監視デバイスから抽出するステータス情報の少なくともタイプおよび前記ステータス情報に関連する重みを含む情報マップとを読み出す手段と、
前記ステータス情報を取得するため、前記アクセス関数、前記情報マップ、および前記選択された通信プロトコルを用いて前記被監視デバイスにアクセスする手段とを有することを特徴とする装置。
【請求項６】
請求項５に記載の装置であって、
前記被監視デバイスに関するモデル情報を取得するため前記被監視デバイスにアクセスする手段をさらに有し、
前記生成する手段は前記ベンダーと前記モデル情報を用いて前記ストリングを生成する手段を有することを特徴とする装置。
【請求項７】
請求項５に記載の装置であって、
SNMP、HTTP、およびFTPから前記通信プロトコルを選択する手段をさらに有することを特徴とする装置。
【請求項８】
コンピュータに、ネットワークを介して被監視デバイスに関するステータス情報を選択された通信プロトコルにより抽出させるためのコンピュータプログラムであって、
前記被監視デバイスに関する少なくともベンダー情報を取得するために前記選択された通信プロトコルを用いて前記被監視デバイスにアクセスするステップと、
前記被監視デバイスのアクセス可能データファイルから前記ステータス情報を抽出するアクセス関数を特定する情報を第１のメモリから取得するステップと、
前記取得したベンダー情報と前記取得したアクセス関数情報に基づきストリングを生成するステップと、
前記生成されたストリングに応じて第２のメモリから、（１）前記アクセス関数に関連したデータ処理オブジェクトの情報と、（２）前記被監視デバイスから抽出するステータス情報の少なくともタイプおよび前記ステータス情報に関連する重みを含む情報マップとを読み出すステップと、
前記ステータス情報を取得するため、前記アクセス関数、前記情報マップ、および前記選択された通信プロトコルを用いて前記被監視デバイスにアクセスするステップとをコンピュータに実行させることを特徴とするコンピュータプログラム。
【請求項９】
請求項８に記載のコンピュータプログラムであって、
前記被監視デバイスに関するモデル情報を取得するため前記被監視デバイスにアクセスするステップをさらに前記コンピュータに実行させ、
前記生成するステップは前記ベンダーと前記モデル情報を用いて前記ストリングを生成するステップを含むことを特徴とするコンピュータプログラム。
【請求項１０】
請求項８に記載のコンピュータプログラムであって、
前記被監視デバイスから前記ステータス情報を抽出するために仕様する複数の通信プロトコルの各々について、前記アクセス、取得、生成、読み出し、およびアクセスステップを繰り返すステップをさらに前記コンピュータに実行させることを特徴とするコンピュータプログラム。
【請求項１１】
請求項８に記載のコンピュータプログラムであって、
SNMP、HTTP、およびFTPから前記通信プロトコルを選択するステップをさらに前記コンピュータに実行させることを特徴とするコンピュータプログラム。
【請求項１２】
請求項８ないし１１に記載のコンピュータプログラムを格納したコンピュータ読み取り可能記憶媒体。

【図１】

【図２】

【図３】

【図４】

【図５】

【図６Ａ】

【図６Ｂ】

【図６Ｃ】

【図６Ｄ】

【図７】

【図８】

【図９】

【図１０】

【図１１】

【図１２】

【図１３】

【図１４】

【図１５】

【図１６】

【図１７】

【図１８】

【図１９】

【図２０】

【図２１】

【図２２】

【図２３】

【図２４】

【図２５】

【図２６】

【図２７Ａ】

【図２７Ｂ】

【図２７Ｃ】

【図２７Ｄ】

【図２８】

【図２９Ａ】

【図２９Ｂ】

【図２９Ｃ】

【図２９Ｄ】

【図３０】

【図３１Ａ】

【図３１Ｂ】

【図３２Ａ】

【図３２Ｂ】

【図３３】

【図３４】

【図３５】

【図３６Ａ】

【図３６Ｂ】

【図３７】

【図３８Ａ】

【図３８Ｂ】

【図３８Ｃ】

【図３９】

【図４０】

【図４１】

【図４２】

【図４３】

【図４４】

【図４５】

【図４６】

【図４７】

【図４８】

【図４９】

【図５０】

【図５１】

【図５２Ａ】

【図５２Ｂ】

【図５３】

【図５４】

【図５５Ａ】

【図５５Ｂ】

【図５６Ａ】

【図５６Ｂ】

【図５６Ｃ】

【図５７】

【図５８】

【図５９Ａ】

【図５９Ｂ】

【図５９Ｃ】

【図５９Ｄ】

【図６０Ａ】

【図６０Ｂ】

【図６０Ｃ】

【図６０Ｄ】

【図６１Ａ】

【図６１Ｂ】

【公開番号】特開２００６−１０７４６０（Ｐ２００６−１０７４６０Ａ）
【公開日】平成１８年４月２０日（２００６．４．２０）
【国際特許分類】
【出願番号】特願２００５−２４６５３６（Ｐ２００５−２４６５３６）
【出願日】平成１７年８月２６日（２００５．８．２６）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．リナックス
２．マッキントッシュ
【出願人】（０００００６７４７）株式会社リコー (37,907)
【Ｆターム（参考）】