被監視装置に格納されたウェブページからステータス情報を抽出するための方法、システム及びコンピュータプログラム
【課題】被監視装置のウェブページから正しいステータス情報を取得する。
【解決手段】ネットワーク上の被監視装置に格納されたウェブページのスクリプトからHTTP通信プロトコルを用いてステータス情報を抽出する。パラメータストリング及びウェブページの身元を、ベンダー及びモデル情報に基づいて取得し；ウェブページにアクセスし、スクリプトにてウェブページのラインを取得し；分析し、パラメータストリングが捜し出されたかを判別する。パラメータが捜し出されるまでアクセス及び分析を反復し全てのパラメータストリングが捜し出されているか否かを判別する。捜し出されていない場合、全てのパラメータストリングが捜し出されるまで、アクセス、分析、反復及び判別を反復する。全てのパラメータストリングがスクリプトにて捜し出された場合には、最後に捜し出されたパラメータストリングの場所に基づいてウェブページからステータス情報を抽出する。
【解決手段】ネットワーク上の被監視装置に格納されたウェブページのスクリプトからHTTP通信プロトコルを用いてステータス情報を抽出する。パラメータストリング及びウェブページの身元を、ベンダー及びモデル情報に基づいて取得し；ウェブページにアクセスし、スクリプトにてウェブページのラインを取得し；分析し、パラメータストリングが捜し出されたかを判別する。パラメータが捜し出されるまでアクセス及び分析を反復し全てのパラメータストリングが捜し出されているか否かを判別する。捜し出されていない場合、全てのパラメータストリングが捜し出されるまで、アクセス、分析、反復及び判別を反復する。全てのパラメータストリングがスクリプトにて捜し出された場合には、最後に捜し出されたパラメータストリングの場所に基づいてウェブページからステータス情報を抽出する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明はネットワークに接続された装置の監視に関する。特に、複数のプロトコルを用いてネットワークに接続された装置を遠隔監視する方法、システム、コンピュータプログラムおよびその関連製品に関する。
【背景技術】
【０００２】
広く知られているように、コンピュータシステムにはハードウェアとソフトウェアが含まれる。ソフトウェアはコンピュータシステムを構成するハードウェア部品を動作させ管理するために作られた命令のリストを含んでいる。一般に、コンピュータシステムは相互にインターフェイスする様々なハードウェア部品や装置を含んでいる。コンピュータシステムにはスタンドアロン型やネットワーク接続型等がある。ネットワークタイプのコンピュータシステムでは、複数の装置各々がネットワークに接続されており、そのネットワークを介して個々の装置間で通信が行われる。
【０００３】
さらに、ハードウェア装置が協働的に機能するように、ハードウェア装置間の通信を可能とするために、ハードウェア装置を動作させるソフトウェアが構成されていなければならない。さらに、そのような通信を支援するため、ハードウェア装置を監視し、指定されたハードウェア装置各々の状態を監視し、各ハードウェア装置が効率的に機能していることを保証することが望ましい。
【０００４】
本特許出願に関し、複数の個別の装置またはハードウェア装置を制御、設定又は監視するハードウェア装置を監視装置と呼び、監視装置により制御、設定又は監視されているハードウェア装置を「被監視装置」と呼ぶ。
【０００５】
ネットワーク上のハードウェア装置に関し、これらの装置は、メンテナンス、使用、その他の目的のために監視されることが望ましい。しかし、ハードウェア装置とインターフェイスに関する製造者の違いを考慮すると、監視装置がネットワークに接続された他のいろいろな装置と通信することは困難かもしれない。このような不利益により、ネットワーク管理者は、そのネットワークに接続された装置の性能（パフォーマンス）と効率についての重要な情報を取得することが妨げられる傾向がある。
【０００６】
シンプルネットワークマネージメントプロトコル（SNMP）は、今日、データ通信ネットワーク上の装置、電気通信システム、その他のグローバルに到達可能な装置を監視および管理するためのデファクトスタンダードである。実際には、コンピュータ及び関連装置を取り扱うすべての組織は、ローカルエリアネットワークやワイドエリアネットワークを通じてそのような各装置を集中的に監視、診断、設定できることを期待している。SNMPはこのようなやりとり（インターラクション）を実現するプロトコルである。
【０００７】
装置がSNMPリクエストに応答するために、SNMPリクエストを正しく解釈し、そのリクエストにより要求されたアクションを実行し、SNMPリプライを生成することができるようにするソフトウェアを装置に備えることが望ましい。SNMPエージェントソフトウェアは、一般的にネットワークの構成要素（エンティティ）に備わるサブシステムソフトウェアモジュールである。
【０００８】
システムにより使用されるオブジェクトの集まりは、一般に管理情報ベース（MIB）と呼ばれる。MIBは装置の監視に関する情報を有するデータベースでもある。MIBの例としては、二、三例を挙げると、イーサネット（登録商標）インターフェイスにフォーカスしたイーサネット（登録商標）MIB、802.1Dブリッジ管理用のオブジェクトを定義するブリッジMIB等がある。
【０００９】
装置の監視にSNMPを使用することは困難である。なぜなら、有効なキーが無ければ解読困難な値がプライベートMIBに含まれているからである。自社のネットワークに接続されたいろいろな装置を監視するためにSNMPを使用している会社は、その会社の独占情報として維持されるユニークな識別子／キーを生成する。通例、結果は二値または整数の値として表示される。このように、SNMPを用いても、監視されている装置（被監視装置）から受信した結果は、被監視装置の状態をユーザが理解可能な形でユーザに提供することはできない。
【００１０】
さらに、SNMPを用いても、有効なキーなしに被監視装置についての詳細な情報を取得し、又はプライベートMIBにアクセスして、バイナリまたは整数値として取得した結果を解読することは困難である。また、与えられたプロトコル（例えば、SNMPまたはHTTP/HTML）は、時間切れ（タイムアウト）やパケット喪失等のいろいろな理由でうまく機能しないこともある。また、複数のプロトコルを用いて与えられた装置から抽出した情報は、各プロトコルでダブっているかもしれない。従って、このような状況において装置からのデータ抽出をうまく管理しないと、プロトコルによっては他のプロトコルよりも多くのリソースを必要とするものもあるので、時間とメモリの効率が悪くなる。更に、或るプロトコルを用いて情報抽出をすれば、他のプロトコルを用いるよりも少ない処理量と費用で情報を抽出することができるかもしれない。さらにまた、或るプロトコルを用いて取得した情報は、他のプロトコルを用いて取得した情報よりも監視装置にとって有用であるかもしれない。
【００１１】
本発明は以下の文献で参照及び説明される様々な技術を利用してもよい。列挙される文献各々の内容全体は本願のリファレンスに組み入れられる。
【非特許文献１】Goldfart,C.,The SGML Handbook,Clarendon Press(1990)
【非特許文献２】Castro,E.,HTML for the World Wide Web,Peachpit Press,Berkeley(1996)
【非特許文献３】Megginson,D.,Structuring XML Documents,Prentice Hall,NJ(1998)
【発明の開示】
【発明が解決しようとする課題】
【００１２】
本発明の課題である上記問題の解決は、ネットワークに接続された装置を監視可能とする本発明のシステムと方法によりなされる。以下、ネットワークに通信可能に接続された個々の装置の間で装置を監視する方法が説明される。
【課題を解決するための手段】
【００１３】
該方法はハードウェアアクセスモジュールを介して第１のデータベースにアクセスするステップを含み、前記第１のデータベースは複数の通信プロトコルをサポートするように構成されている。第１のデータベースには、被監視装置の製造者やモデル情報等、様々な情報を取得するための、複数の通信プロトコルにより使用される情報が格納されている。通信プロトコルは複数の通信プロトコルから選択され、選択された通信プロトコルは被監視装置から状態情報（ステータス情報）を受信するように機能する。該方法は、前記第１のデータベースから選択された通信プロトコルと情報を用いて前記被監視装置にアクセスするステップと、前記アクセスした装置からステータス情報を受信するステップと、前記受信したステータス情報を第２のデータベース（DeviceODBC）に格納するステップとを有する。
【発明を実施するための最良の形態】
【００１４】
他の実施形態において、本発明はネットワークに通信可能に接続された個々の装置の間で装置を監視する方法を提供する。複数の通信プロトコルは被監視装置から情報を検索するために使用される。例えば、SNMPプロトコルが最初に被監視装置にアクセスするために選択され、SNMPプロトコルを用いて効率的に読み出せるように構成された装置情報が取得される。その後、前記装置が追加的なプロトコルをサポートしている場合、SNMPプロトコルを用いて効率的に読み出すことができない情報を取得するために、HTTP及びFTPプロトコルが選択される。プロトコルの選択は、データベースに格納されたサポート情報と併せてプロトコルマネージャにより実行される。
【００１５】
本発明において、例えばLANやWANなどのネットワークに接続された少なくとも１つの装置（被監視装置）の監視が監視システムにより可能となる。前記被監視装置は固有の（ユニークな）IPアドレスを有する。被監視装置に割り当てられたIPアドレスや、前記被監視装置のベンダー／製造者の詳細は、データベースに格納される。ネットワークをスキャンして装置に問い合わせることにより、装置のIPアドレスを取得できる。その方法は既知である。それゆえ、監視される装置のIPアドレスはすでに取得され、データベースに格納されていると仮定する。
【００１６】
本発明は、被監視装置から受け取ったHTML情報から必要な情報をいかに抽出するかを特定する。一旦、被監視装置のウェブページにアクセスすると（すなわち、IPアドレスと特定されたポートを通じて）、被監視装置に対応する特定のウェブページが表示される。そのウェブページの情報はキーと値のペアの形式をとる。例えば、カラープリンターのウェブページにおいて、トナーレベルは「ブラック１００％」のように表示される。HTML/XMLパーサを用いて、ウェブページの情報から必要な情報を読み出すためにそのページを解釈する。HTML／XMLパーサを用いてウェブページから抽出した必要な情報とパラメータ値はサポートデータベースに格納される。
【００１７】
本発明は、ここで説明されるように、監視システムによりサポートされた被監視装置の様々なベンダー及び装置モデルを特定する。被監視装置のいろいろなベンダーはそのベンダー固有のやり方で被監視装置に関する情報を提示するので、本発明により被監視装置のベンダーとモデルを特定して被監視装置の動作状態を判断することができる。
【００１８】
本発明の一態様によると、ネットワークに通信可能に結合された被監視装置に関する情報をHTTP通信プロトコルを用いて検索するための方法、システム及びコンピュータプログラム製品が提供される。これらは、被監視装置のベンダー及びモデル情報を第１メモリから検索し；ベンダー及びモデル情報に基づいて、被監視装置の装置情報を得るためにHTTPプロトコルを用いて被監視装置にアクセスするよう構成された少なくとも１つのアクセス機能を決定し、その少なくとも１つのアクセス機能は、（１）被監視装置に格納されたウェブページ中のタグから装置情報を取得するよう形成された第１アクセス機能及び（２）ウェブページ中のスクリプトから装置情報を取得するよう構築された第２アクセス機能の少なくとも１つを含み；装置情報の取得を試みるために少なくとも１つのアクセス機能の各アクセス機能及びHTTPプロトコルを用いて被監視装置にアクセスし；及びアクセスステップで取得された装置情報をベンダー及びモデル情報と関連付けて第２メモリに格納する。
【００１９】
本発明の他の態様によると、被監視装置に格納されたウェブページのスクリプトから抽象(abstract)クラスインターフェースを用いてステータス情報を抽出するための方法、システム及びコンピュータプログラム製品がもたらされる。抽象クラスインターフェースは、ステータス情報を抽出するのに使用されるサポート情報を取得するよう構築される第１機能と、ウェブページのスクリプトからサポート情報を用いてステータス情報を抽出するよう構築される第２機能とを含む。本方法は：（１）被監視装置のベンダー及びモデル情報を第１メモリから検索するステップ；（２）被監視装置から取得するステータス情報の少なくとも１つのタイプをベンダー及びモデル情報に基づいて判定するステップ；（３）抽象クラスインターフェースの第１関数を用いて、ベンダー及びモデル情報並びにウェブページに基づいて、サポート情報を取得するステップ；（４）HTTPプロトコル、取得したサポート情報及び抽象クラスインターフェースの第２機能を利用して被監視装置にアクセスし、ウェブページのスクリプトから少なくとも１つのタイプのステータス情報を取得するステップ；及び（５）アクセスステップで取得したステータス情報をベンダー及びモデル情報に関連付けて第２メモリに格納するステップを有する。
【００２０】
本発明の他の形態によると、ネットワークに通信可能に接続された被監視装置に関連するステータス情報をHTTP通信プロトコルを用いて検索するための方法、システム及びコンピュータプログラム製品がもたらされる。本方法は、被監視装置のベンダー及びモデル情報を第１メモリから検索するステップ；ベンダー及びモデル情報に基づいて少なくとも１つの手段識別子を検索するステップであって、手段識別子の各々は、ステータス情報を取得するためにHTTPプロトコルを用いて被監視装置にアクセスするように構築された対応するアクセス機能を識別し、少なくとも１つの手段識別子は、（１）被監視装置に格納されたウェブページ中のタグから装置情報を取得するよう形成された第１アクセス機能及び（２）ウェブページ中のスクリプトから装置情報を取得するよう構築された第２アクセス機能の少なくとも１つを確認するところのステップ；少なくとも１つの手段識別子の手段識別子を選択するステップ；ベンダー及びモデル情報並びに選択された手段識別子に基づいて、手段識別子に対応するアクセス機能を利用して、ウェブページからステータス情報を取得するのに使用されるパラメータ値を第１メモリから検索するステップ；手段識別子に対応するアクセス機能、パラメータ値及びHTTPプロトコルを用いて被監視装置にアクセスし、ステータス情報の取得を試みるステップ；及びアクセスステップで取得したステータス情報をベンダー及びモデル情報に関連付けて第２メモリに格納するステップを有する。
【００２１】
本発明の他の形態によると、ネットワークに通信可能に接続された被監視装置に格納されたウェブページのスクリプトからステータス情報をHTTP通信プロトコルを用いて検索するための方法、システム及びコンピュータプログラム製品がもたらされる。本方法は、（１）ベンダー及びモデル情報に基づいて、ウェブページのスクリプトからステータス情報を抽出するのに使用される少なくとも１つのパラメータストリング（文字列）及びウェブページの身元を取得するステップ；（２）ウェブページの身元及びHTTPプロトコルを用いてウェブページにアクセスし、スクリプト中のウェブページのラインを取得するステップ；（３）ウェブページの取得したラインを分析し、少なくとも１つのパラメータストリングのパラメータストリングが取得したライン中に発見されるか否かを確認するステップ；（４）パラメータストリングが取得したライン中に見出されなかったことが分析ステップで確認された場合に、パラメータストリングが発見されるまで、アクセス及び分析のステップが反復されるステップ；（５）パラメータストリングが取得したライン中に発見されたことが分析ステップで確認された場合に、少なくとも１つのパラメータストリング中の全てのパラメータストリングが発見されているか否かを確認するステップ；（６）少なくとも１つのパラメータストリング中の全てのパラメータストリングは発見されていないことが確認ステップで確認された場合に、少なくとも１つのパラメータストリング中の全てのパラメータストリングが発見されるまで、アクセス、分析、反復及び確認のステップを反復するステップ；及び（７）スクリプト中で全てのパラメータストリングが発見されたことが確認ステップで確認された場合に、最後に発見されたパラメータストリングの場所に基づいてウェブページからステータス情報を抽出するステップ；を有する。
【００２２】
本願は以下の米国特許出願に関連する。
【００２３】
１．西暦２０００年５月１７日付けで出願された“Method and System of Remote Diagnostic,Control,and Information Collection using a Dynamic Linked Library of Multiple Formats and Multiple Protocols with Intelligent Formatter”と題する米国特許出願第０９／４５３，９３７号；
２．西暦２００１年１月９日付けで出願された“Method and System of Remote Support of Device Using Email”と題する米国特許出願第０９／７５６，１２０号；
３．西暦２００１年２月１４日付けで出願された“Method and System of Remote Diagnostic Control,and Information Collection using a Dynamic Linked Library of Multiple Formats and Multiple Protocols with Three-Level Formatting”と題する米国特許出願第０９／７８２，０６４号；
４．西暦２００１年８月６日付けで出願された“Universal Controller in The Wireless Networked Environment”と題する米国特許出願第０９／９２１，７０７号；
５．西暦２００１年９月１７日付けで出願された“Method and System of Remote Support of Device Using Email Through Data Transfer Module”と題する米国特許出願第０９／９５３，３５８号；
６．西暦２００１年９月１７日付けで出願された“Method and System for Remote Support of Device using Email for Sending Information Related to a Monitored Device”と題する米国特許出願第０９／９５３，３５９号；
７．西暦２００１年１０月１５日付けで出願された“Method and System for Remote Support of Device Using Email Based Upon Pop3 With Decryption Capability Through Virtual Function”と題する米国特許出願第０９／９７５，９３５号；
８．西暦２００２年２月１１日付けで出願された“Method and Apparatus Utilizing Communication Means Hierarchy to Configure or Monitor an Interface Device”と題する米国特許出願第１０／０６８，８６１号；
９．西暦２００２年５月１３日付けで出願された“Verification Scheme for Email Message Containing Information About Remotely Monitored Devices”と題する米国特許出願第１０／１４２，９８９号；
１０．西暦２００２年５月１３日付けで出願された“Method for Scrambling Information about Network Devices That is Placed in Email Message”と題する米国特許出願第１０／１４２，９９２号；
１１．西暦２００２年５月３１日付けで出願された“Method and Apparatus for Modifying Remote Devices Monitored by a Monitoring System”と題する米国特許出願第１０／１５７，９０３号；
１２．西暦２００２年６月５日付けで出願された“Method and System to Use HTTP and Html/Xml for Monitoring the Devices”と題する米国特許出願第１０／１６２，４０２号；
１３．西暦２００２年６月１３日付けで出願された“Method and System of Remote Position Reporting Device”と題する米国特許出願第１０／１６７，４９７号−継続出願第０９／５７５，７０２号−（米国特許第６，４２１，６０８号）；
１４．西暦２００２年８月２２日付けで出願された“Method and System for Monitoring Network Connected Devices with Multiple Protocols”と題する米国特許出願第１０／２２５，２９０号；
１５．西暦２００２年１２月２６日付けで出願された“Method and Accessing Information from Database to be used to Obtain Status Information from the Web Pages of Remotely Monitored Devices”と題する米国特許出願第１０／３２８，００３号；
１６．西暦２００２年１２月２６日付けで出願された“Method of using Internal Structure to Store Database Information for Multiple Vendor and Model Support for Remotely Monitored Devices”と題する米国特許出願第１０／３２８，００８号；
１７．西暦２００２年１２月２６日付けで出願された“Method of using Vectors of Structures for Extracting Information from the Web Pages of Remotely Monitored Devices”と題する米国特許出願第１０／３２８，０２６号；
１８．西暦２００３年２月２６日付けで出願された“Method and System for Monitoring Network Connected Devices with Multiple Protocols”と題する米国特許出願第１０／３７２，９３９号；
１９．西暦２００３年６月１３日付けで出願された“Method for Efficiently Storing Information used to Extract Status Information from a Device Coupled to a Network in a Multi-Protocol Remote Monitoring System”と題する米国特許出願第１０／４６０，１５０号；
２０．西暦２００３年６月１３日付けで出願された“Method for Efficiently Extracting Status Information Related to a Device Coupled to a Network in a Multi-Protocol Remote Monitoring System”と題する米国特許出願第１０／４６０，１５１号；
２１．西暦２００３年６月１３日付けで出願された“Method for Parsing an Information String to Extract Requested Information Related to a Device Coupled to a Network in a Multi-Protocol Remote Monitoring System”と題する米国特許出願第１０／４６０，４０４号；
２２．西暦２００３年６月１３日付けで出願された“Method and System for Extracting Vendor and Model Information in a Multi-Protocol Remote Monitoring System”と題する米国特許出願第１０／４６０，４０８号；
２３．西暦２００３年９月２６日付けで出願された“Method and System for Extracting Information from Networked Devices in a Multi-Protocol Remote Monitoring System”と題する米国特許出願第１０／６７０，５０５号；
２４．西暦２００３年９月２６日付けで出願された“Method and System for Supporting Multiple Protocols Used to Monitor Networked Deices in a Remote Monitoring System”と題する米国特許出願第１０／６７０，６０４号；
２５．西暦２００４年１月２７日付けで出願された“Method and System for Determining the Type of Status Information to Extract from Networked Devices in a Multi-Protocol Remote Monitoring System”と題する米国特許出願第１０／７６７，４６７号；
２６．西暦２００４年１月２７日付けで出願された“Method and System for Managing Protocols Used to Obtain Status Information from a Network Device”と題する米国特許出願第１０／７６４，５２７号；
２７．西暦２００４年１月２７日付けで出願された“Method and System for Managing Vendor and Model Information in a Multi-Protocol Remote Monitoring System”と題する米国特許出願第１０／７６４，５６９号；
２８．西暦２００４年１月２７日付けで出願された“Method and System for Initializing Protocol Information Used to Extract Status Information from Networked Devices”と題する米国特許出願第１０／７６４，５８２号；
２９．西暦２００４年８月２７日付けで出願された米国特許出願第１０／９２７，１５８号；
３０．西暦２００４年８月２７日付けで出願された米国特許出願第１０／９２７，２５７号；
３１．西暦２００４年８月２７日付けで出願された米国特許出願第１０／９２７，２８３号；
３２．西暦２００５年１月１１日付けで出願された米国特許出願第１０／０３２，０３９号；
３３．西暦２００５年１月１１日付けで出願された米国特許出願第１０／０３２，０１６号；
３４．西暦２００５年１月１１日付けで出願された米国特許出願第１０／０３２，０６３号；
３５．西暦２００５年１月１１日付けで出願された米国特許出願第１０／０３２，００８号；
３６．西暦２００５年１月１１日付けで出願された米国特許出願第１０／０３２，１９２号；
３７．本願基礎出願と共に出願された“Method and System for Use of Abstract Classes for Script Implementation of HTTP to Obtain Information from Devices”と題する出願−代理人管理番号２７１２０５ＵＳ−（ＲＳＩＤ １−４６１）；
３８．本願基礎出願と共に出願された“Database for Multiple Implementation of HTTP to Obtain Information from Devices”と題する出願−代理人管理番号２７１２０３ＵＳ−（ＲＳＩＤ １−４６２）；
３９．本願基礎出願と共に出願された“Method and System for Script Implementation of HTTP to Obtain Information from Remote Devices”と題する出願−代理人管理番号２７１２０７ＵＳ−（ＲＳＩＤ １−４６０）。
【００２４】
上記の米国特許及び特許出願各々の開示内容全体は本願のリファレンスに組み入れられる。
【００２５】
添付した図面を参照して以下の詳細な説明を読めば、本発明及びその結果得られる多くの利点をよりよく理解し、獲得することができる。
【実施例１】
【００２６】
図１は、いろいろな装置と、その装置の動作を監視、診断及び制御するコンピュータとを示す概略図である。具体的に、図１は、コンピュータワークステーション１７、１８、２０および２２に接続されたローカルエリアネットワーク（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）で代替することができる。ディスク１８２は、ハードディスクドライブ、光ディスクドライブ、および／またはフロッピー（登録商標）ディスクドライブである。接続１８０を介して付加的記憶装置をデジタルコピー／プリンター２４に接続してもよい。フラッシュメモリ１７８は、デジタルコピー／プリンター２４の製品寿命にわたって頻繁には変化しないパラメータを表す準静的状態(semi-static state)データを格納するために使用する。このようなパラメータには、例えば、デジタルコピー／プリンターのオプションや設定が含まれる。オプションインターフェイス１８４により、外部インターフェイス等の付加的ハードウェアをデジタルコピー／プリンター２４に接続することができる。クロック／タイマー１８７を用いて時間と日付を常に把握したり、経過時間を測定したりすることができる。
【００４２】
図３は、デジタルコピー／プリンター２４を構成するいろいろなセクションも示している。参照番号２０２はソータを指し、デジタルコピー／プリンター２４の出力をソートするために使用するセンサーおよびアクチュエータを含んでいる。デュプレクサ２００によりデュプレックス動作を実行することができる。デュプレクサ２００は従来のセンサーとアクチュエータを含む。大容量トレイユニット１９８が設けられ、多量の用紙を用紙トレイに保持することができる。デュプレクサ２００と同様に、トレイユニット１９８も従来のセンサーとアクチュエータを含む。
【００４３】
給紙コントローラ１９６を用いて、デジタル画像形成装置の給紙動作を制御することができる。スキャナー１９４を用いて画像をスキャンしてデジタル画像形成装置に取り込むことができる。スキャナー１９４は、光源、ミラー等の従来のスキャンエレメントを含んでいる。また、ホームポジションセンサー等のスキャナーセンサーを用い、スキャナーがホームポジションにいるかどうか判断する。また、ランプサーミスターを用い、スキャンランプが正しく動作することを保証する。プリンター／イメージャ１９２は、デジタル画像形成装置の出力を印刷する。従来のレーザ印刷メカニズム、トナーセンサー、及び画像濃度センサーを有している。フューザ１９０は、高温ローラを用いてトナーを用紙上に溶かす。エグジットセンサと、フューザ１９０がオーバーヒートしないことを保証するサーミスターと、オイルセンサーとを含む。また、オプショナルユニットインターフェイス１８８があり、デジタル画像形成装置の任意的構成要素への接続に使用される。任意的構成要素とは、例えば、自動文書フィーダ、異なるタイプのソータ／コレータ、その他デジタル画像形成装置に付加できる構成要素である。他のエレメントには、その装置の位置を特定することができるGPSなどが含まれる。
【００４４】
図４は複数ポートネットワークインターフェイス１６６の詳細を示す図である。デジタル画像形成装置は、セルラインターフェース２２７、無線インターフェイス２２８又は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）を通じて送信することができる監視システムの機能を持たせることができる。ゼロックスDocuPrinter4025及びHPLaserJet9000は双方とも電子メールを送信できる。
【００７２】
監視ステーション９０２はSMTPを介して電子メールでステータス情報を遠隔地に送信できる。図９に示されるように、監視ステーション９０２はSMTPサーバ９２６を介して電子メールでステータス情報を遠隔地に又は遠隔ネットワークに送信する。遠隔地には電子メールを受信するためのPOP3サーバ９３０が備わる。ワークステーション９４０はPOP3サーバ９０３と通信し、ステータス情報を含む電子メールを検索する。ワークステーション９４０はステータス情報をデータベース９６０に格納してもよい。電子メールにより、ステータス情報が遠隔地に容易に伝送されるようにできる。ステータス情報は電子メールメッセージ中に又は添付物（アタッチメント）中にあってもよい。ステータス情報はセキュアな（安全な）データ伝送を行うためにエンコード（暗号化）されてもよい。FTP、HTTPのような他のプロトコル又はウェブサービスを利用して情報を遠隔地に転送してもよい。
【００７３】
監視システムのアーキテクチャ
図１０は、本発明の一実施形態による、リモート装置に関連したデータの監視に使用される監視システム１０００（および、関連するインターフェイス機能）を示す。監視システム１０００は、ソフトウェアモジュール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モジュール１００６は、多数のモジュールにより使用されるクラスを含むCommon（コモン）モジュール１１０１、及び他のサブモジュール（DeviceODCBモジュール１１０４、Device（デバイス）モジュール１１１０、HWaccess（HWアクセス）モジュール１１１６）を管理するMonitorManager（モニターマネージャ）モジュール１１０２とを含み、図１０に示したようにインターフェイス機能により規定されたタスクを完了する。具体的に、DeviceODBC（デバイスODBC）モジュール１１０４は、標準インターフェイスを通じて外部装置情報にアクセスするために、アクセスされる。HWaccessモジュール１１１６は、複数の通信プロトコル（例えば、HTTP、SNMP、FTP）のうちから選択された通信プロトコルを用いて、被監視装置からベンダー、モデル、一意なID、ステータス情報を取得する。各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)
この関数は装置のステータスを取得する。この関数は、正常に動作したときは真を返し、そうでないときは空のマップとともに偽を返す。
【０１０２】
図１３は、図１０に示した、Monitorモジュール１００６の呼び出しシーケンスを説明するinit()関数のシーケンスを示す。MonitorManager１１０２は、HWaccessモジュール１１１６を初期化して初期化関数を開始する。そして、MonitorManager１１０２は被監視装置に関する情報を取得し、被監視装置に割り当てられたIPアドレスを用いてその被監視装置と通信する。MonitorManager１１０２は、DeviceODBC１１０４にアクセスし被監視装置の設定情報を取得する。MonitorManager１１０２に返される設定情報は、例えば、被監視装置のIPアドレス、各プロトコルのパラメータ名とそれに関連する値、被監視装置のベンダー／製造者及びモデル情報が含む。一旦IPアドレスを取得すると、MonitorManager１１０２は、各プロトコルについてそのIPアドレス、パラメータ名、それに関連する値を設定し、Deviceモジュール１１１０の装置についてソフトウェアオブジェクトを生成する。デバイスソフトウェアオブジェクトが正常に生成されると、HWaccessモジュール１１１６を用いて、被監視装置からベンダー、モデル、一意的IDを取得し、生成されたデバイスソフトウェアオブジェクトに格納する。
【０１０３】
一旦デバイスソフトウェアオブジェクトからベンダー、モデル情報、一意的IDを取得すると、MonitorManager１１０２は被監視装置から受信した情報でデータベース（例えば、DeviceODBC１１０４）を更新する。図１２には１つの装置を示しているが、obtainConfigからupdateConfigまでのステップを繰り返し、外部ソースで指示された装置すべてをカバーする。また、図２１，３１，３２，３３に示した各プロトコルが初期化される。図２１，３１，３２，３３に示したODBCに対応するデータベーステーブルにアクセスし、アクセスされた装置からのステータス情報の収集が速くなるように、アクセスされた装置の必要情報を外部記憶から内部データ構造に転送する。
【０１０４】
図１３は、図１１に示した、MonitorManagerモジュール１１０２による被監視装置のステータスを決定するためのステータス監視機能のシーケンスを示す。DeviceからHWaccessにobtainStatus関数が発行されると、CHWaccessクラスは、以下に説明するように、異なるパラメータを用いて、抽象型クラスを通じて図２１，３１，３２，３３に示した各プロトコルに対してobtainStatus関数コールを順次発行する。各プロトコルモジュールは被監視装置からステータス情報を抽出するのに必要な情報をすでにキャッシュしている。その被監視装置は、図１２に示した初期化時にすでにアクセスされている。それゆえ、ステータス情報は、ステータス監視の際に外部ソースにアクセスすることなく、被監視装置から素早く抽出することができる。このプロセスは、図１４に示したベクトルに格納されたすべての被監視装置について繰り返される。
【０１０５】
図１４を参照して、ベクトル１５００が示されており、図１２と１３に示されるように、図１１のデバイスモジュール１１１０内で生成され、MonitorManager１１０２により使用される装置を参照している。MonitorManager１１０２は、例えば、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部分に含まれるデータ構造を示し、図１８を参照して上で説明したデータ構造に類似したデータ構造を含んでいる。図１８−２０に示されるEnumCorrespondenceデータ構造は、そのサポートデータベースにおける全てのプロトコルについてそのデータベース構造で共用され、図１７に示されるのと同じデータ構造である。
【０１１２】
図１９では、被監視装置から情報を取得するために使用するHTTPプロトコルについて２組のデータ構造が示されている。一方は、「タグ」（Tag）のプレフィックス（接頭辞）を用いてラベルが付され、被監視装置のウェブページ中のタグにある情報を抽出するためのサポート情報を用意する。もう一方のデータ行動は、「スクリプト」（Script）のプレフィックスを用いてラベルが付され、被監視装置のウェブページ中のジャバ(Java（登録商標）)スクリプトに含まれる情報を抽出するためのサポート情報を用意する。
【０１１３】
図２０は被監視装置のFTPファイルから情報を抽出するのに使用されるサポート情報を含むデータ構造を示す。
【０１１４】
本発明で使用するenumタイプの例は、以下に定義するinfoTypeである。（enumタイプは単なる一例であり、本発明を限定するものとして解釈してはならない。）
infoType (typedef int infoType)
このセクションではinfoType(int)の定義を説明する。データタイプには０から９９までの範囲の値が割り当てられている。１００から４９９までの値の範囲が装置情報に割り当てられている。５００から１９９９の値の範囲が標準MIBパラメータを含む共通パラメータに割り当てられている。２０００から３９９９の範囲がリコー特有の情報に割り当てられている。４０００から４９９９の範囲がゼロックスに割り当てられている。５０００から５９９９の範囲がレックスマーク(Lexmark)に割り当てられている。６０００から６９９９までの範囲がHPに割り当てられている。値は以下のように決められる：
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).
HWaccessモジュールの抽象型クラス
図２１は、HWaccessパッケージを示すパッケージ図である。このパッケージは、監視されるネットワーク装置を特定し、いろいろなネットワークプロトコル（例えば、SNMP、HTTP、FTP）を用いてそのネットワーク装置に関する情報を取得する役割を担う。このパッケージは、パッケージHTTP２３０２、SNMP２３０４、FTP２３０６、及びクラスCHWaccess２３００、CAbsProtocol２３０８、CrecordSet２３１０を含む。パッケージHTTP２３０２、SNMP２３０４、FTP２３０６は、ネットワーク装置にアクセスしそれらから情報を取得するためのネットワークプロトコルを実装する。例えば、HTTPパッケージ２３０２は、ネットワーク装置のウェブページにアクセスしそのウェブページから情報を取得するためのHTTPプロトコルを実装する。クラスCHWaccess２３００はすべてのプロトコルパッケージを管理し、ネットワーク装置から必要な情報を取得する。クラスCAbsProtocol２３０８は如何なるプロトコルをも表す抽象型クラスである。このクラスは、CHWaccess２３００及びプロトコルパッケージ間のインターフェイスを提供する。クラスCAbsProtocol２３０８は、図２１に示した一組の共通関数をCHWaccess２３００に提供する。すべてのプロトコルは、CHWaccess２３００に必要な情報を提供する。後に出てくる図面で説明するように、CAbsProtocol２３０８から導かれるクラスは、適当なプロトコルについて各関数のメソッドを提供する。クラスCRecordSet２３１０は、マイクロソフトファウンデーションクラスのクラスである。このクラスにより用意される各プロトコルパッケージは、データベースにアクセスして、ネットワーク装置のどのベンダーのどのモデルがサポートされ且つそのネットワーク装置からどんな情報を取得するかという情報を取得することができる。CabsProtcolのクラス仕様についてはアペンディックス１を参照されたい。
【０１１６】
図２１に示されるようなプロトコルパッケージ（HTTP２３０２,SNMP２３０４,FTP２３０６）の各々は或るクラスを含み、そのクラスは装置から情報を取得するためのネットワーク装置へのアクセスを管理する。クラスは抽象クラスCabsProtocol２３０８から導出され、そのクラスは、ネットワーク装置から情報にアクセスするプロトコルを実行する方法を用意する。抽象クラスはインターフェイス機能だけを提供し、如何なるプロセスも実行しない。抽象クラスから導出されたクラスは、インターフェイス機能のプロセスを実行する方法を提供する。抽象クラスの導出されるクラスは多数存在し、導出された様々なクラスはインターフェイス機能のプロセスを様々に実行できる。例えばCAbsProtocolのインターフェイス機能はObtainStatus()である。図３１に示される導出されたクラスCSNMPProtocolはネットワーク装置のステータス情報をSNMPを用いて取得する方法を提供する関数ObtainStatus()を含み、図３３に示される導出されたクラスCHTTPProtocolはネットワーク装置のステータス情報をHTTPを用いて取得する方法を提供する関数obtainStatus()を含む。Hwaccessパッケージの設計（デザイン）により、CabsProtocolの導出されたクラスを含む新たなパッケージを追加することで、新たなプロトコルがシステムに追加可能であり、そのクラスは新たなプロトコルを用いてネットワーク装置にアクセスする新たなパッケージを管理する。抽象クラスはシステムの将来的な拡張を可能にする。
【０１１７】
図２２は、ネットワーク装置にアクセスしてそれから情報を取得するためのプロトコルをすべて保持する、図２１のHWaccessパッケージで使用されるデータ構造を示している。図２２に示したデータ構造は、CAbsProtocol２３０８へのポインタのベクトル５００である。クラスCHWaccess２３００は、このデータ構造体を含み、使用する。ベクトル５００は、CAbsProtocol２３０８から導き出されたクラスへのポインタを含んでいるが、CHWaccess２３００は、そのベクトルをCAbsProtocol２３０８へのポインタを含むとみなし、仮想ファンクションコールメカニズムによりCAbsProtocol２３０８のインターフェイス関数を呼び出す。CHWaccess２３００は、実際には、CAbsProtocol２３０８の派生クラスのインターフェイス関数を呼び出す。例えば、ベクトルの第１のエントリーのCAbsProtocolへのポインタ５０２は、図３１に示される派生クラスCSNMPProtocolへのポインタであり、ベクトルの第２のエントリーのCAbsProtocolへのポインタ５０４は、図３３に示される派生クラスCHTTPProtocolへのポインタであり、ベクトルの第３のエントリーのCAbsProtocolへのポインタ５０６は、図３２に示される派生クラスCFTPProtocolへのポインタでもよい。そこで、CHWaccess２３００がベクトルのCabsProtocol２３０８のインターフェイス関数を呼び出すとき、実際にはCSNMPProtocol、CHTTPProtocol、CFTPProtocolのインターフェイス関数を呼び出している。ベクトル５００の抽象型クラスCAbsProtocol２３０８を使用することにより、どのプロトコルを使用してもネットワーク装置にアクセスして、そのネットワーク装置から情報を取得することができる。抽象型クラスCAbsProtocol２３０８は、どのプロトコルが使用されているかの詳細を隠蔽する。
【０１１８】
図２３はモニタパッケージのinit()が呼び出された場合のHWaccessパッケージの初期化を行うシーケンス図である。監視される装置から情報へアクセスするために全てのプロトコルオブジェクトが作成及び初期化される。CHWaccessの関数initBegin()の呼出は全てのプロトコルオブジェクト（CAbsProtocolから派生する全て）を作成する。各プロトコルオブジェクトのinitBegin()は、被監視装置のベンダー、モデル及び固有のIDを確認するのに使用されるサポート情報を初期化するために呼び出される。CHWaccessのinitEnd()が呼び出される前に、プロトコルオブジェクト及びCHWaccessの関数が呼び出され、装置にアクセスし、全プロトコルについてその装置のベンダー、モデル及び固有のID情報を取得及び初期化する。CHWaccessのinitEnd()が呼び出される時点までに、各プロトコルオブジェクトは全ての情報（そのプロトコルがサポートする被監視装置のステータス情報を取得するのに必要な情報）を用意する。各プロトコルオブジェクトのinitEnd()は、初期化後に不要なデータ構造全てを削除（クリーンアップ）する。
【０１１９】
図２４はHWaccessパッケージのcanAccessIP()を示すシーケンス図であり、装置が何らかのプロトコルでアクセス可能であるか否かを確認するためのものである。プロトコルオブジェクトの１つがそのIPアドレスに対応する装置にアクセス可能になるまで、CHWaccessは各プロトコルオブジェクトのcanAccessIP()を呼び出す。どのプロトコルオブジェクトも装置にアクセスできなければ、CHWaccessのcanAccessIP()は偽を返し、その装置は将来監視されない。
【０１２０】
図２５Ａ，２５Ｂは２つのシーケンス図を示し、プロトコルオブジェクトから装置の固有のＩＤ、モデル及びベンダーを取得し、ベンダー及びモデル情報と共に他のプロトコルオブジェクトを初期化する２つの異なる筋書き(シナリオ)を示す。装置のベンダー及びモデル情報をプロトコルオブジェクトが一旦取得すると、プロトコルオブジェクトはその装置についてのサポート内容を更新し、その装置からステータス情報を取得できるようにする。他のプロトコルオブジェクトは、その装置についてそれらのサポート内容を更新できるように、その装置からステータス情報を取得できるように、装置のベンダー及びモデル情報についての情報を受信することを要する。CHWaccessのobtainUniqueID(),obtainModel()及びobtainVendor()は図２５A及び２５B双方で呼び出されている。CHWaccessは、装置の固有のID、モデル及びベンダーを取得し且つベンダー及びモデル情報で他のプロトコルオブジェクト全てを初期化するのに必要なプロトコルオブジェクトを同程度に多く使用する。CHWaccessは装置の所与のIPアドレスについてベンダー、モデル及び固有のIDを維持する。図２５Aの或るシナリオでは、CHWaccessは、プロトコルオブジェクトのVendorModelUniqueID()を呼出、そのプロトコルオブジェクトから全ての情報を取得する。そして、CHWaccessは、他のプロトコルオブジェクト全てのinitWithVendorModel()を呼び出すことで、ベンダー及びモデル情報と共に他の全てのプロトコルオブジェクトを初期化する。図２５Bの別のシナリオでは、CHWaccessは、プロトコルオブジェクトのobtainVendorModelUniqueID()を呼び出し、プロトコルオブジェクトからそのベンダーだけを取得する。CHWaccessは別のプロトコルオブジェクトのobtainModel()及びobtainUniqueID()を呼び出し、モデル及び固有のIDを取得する。そしてCHWaccessは、他の全てのプロトコルオブジェクトのinitWithVendorModel()を呼び出すことで、ベンダー及びモデル情報と共に他の全てのプロトコルオブジェクトを初期化する。
【０１２１】
図２６は、図１６のプロトコルパラメータマップ１８００をいかに更新して、どのプロトコルを使用してネットワーク装置からステータス情報を取得するかを説明するフローチャートを示す。図２６のステップを実行し、プロトコルについてネットワーク装置のベンダー名とモデル名を取得する。ステップ３７０２において、プロトコルを用いてネットワーク装置にアクセスできるか検査する。マップ１８００の情報を用いてそのプロトコルをによりネットワーク装置にアクセスする。そのプロトコルを通じてそのネットワーク装置にアクセスできない場合、ステップ３７０４において、プロトコルパラメータマップ１８００からそのプロトコルを削除し、ステップ３７１４において、マップ１８００の更新を終了する。そのネットワーク装置にそのプロトコルを通じてアクセスできるとき、ステップ３７０６において、そのネットワーク装置のベンダーをそのプロトコルを用いて取得できるかどうかチェックする。ベンダーを取得できないとき、ステップ３７０７において、ジェネリック(GENERIC)ベンダーがそのプロトコルでサポートされているかどうかチェックする。プロトコルがジェネリックベンダーをサポートしているとは、プロトコルがその装置のベンダーを取得できないまたはサポートしていないときでさえも、プロトコルがすべての装置に共通のステータス情報（共通ステータス情報）を取得できることを意味する。そのプロトコルによりジェネリックベンダーがサポートされていないとき、ステップ３７０４において、そのプロトコルはプロトコルパラメータマップ１８００から削除され、ステップ３７１４において、マップ１８００の更新が完了する。そのプロトコルがジェネリックベンダーをサポートしているとき、そのプロトコルはプロトコルパラメータマップ１８００に残され、ステップ３７１４において、マップの更新が完了する。ステップ３７０６においてベンダーを取得できる場合、ステップ３７０８において、そのネットワーク装置のベンダーがそのプロトコルでサポートされているかどうかチェックする。ベンダーがそのプロトコルによりサポートされていないとき、ステップ３７０７において、ジェネリックベンダーがそのプロトコルによりサポートされているかどうかチェックする。ステップ３７０７以降のステップのシーケンスは説明済みである。
【０１２２】
ベンダーがそのプロトコルでサポートされているとき、ステップ３７１０において、そのネットワーク装置のモデルがそのプロトコルを用いて取得できるかどうか判断する。モデルを取得できないとき、ステップ３７１１において、ジェネリックモデルがそのプロトコルでサポートされているかどうかをチェックする。プロトコルがジェネリックモデルをサポートしているとは、プロトコルがその装置のモデルを取得できず、またはサポートしていなくても、そのプロトコルがベンダーのすべての装置に共通なステータス情報（特定ベンダーステータス情報）を取得できることを意味する。ジェネリックモデルをプロトコルがサポートしていないとき、ステップ３７０４において、そのプロトコルはプロトコルパラメータマップ１８００から削除され、ステップ３７１４において、マップ１８００の更新が終了する。ジェネリックモデルがプロトコルによりサポートされているとき、そのプロトコルはプロトコルパラメータマップ１８００に残され、ステップ３７１４においてマップの更新を終了する。ステップ３７１０でモデルを取得できるとき、ステップ３７１２において、そのネットワーク装置のモデルがプロトコルによりサポートされているかどうか判断する。そのモデルがプロトコルでサポートされていないとき、ステップ３７１１で、ジェネリックモデルをそのプロトコルがサポートしているかどうかチェックする。ステップ３７１１に続くステップのシーケンスについては説明済みである。そのモデルがプロトコルによりサポートされているとき、そのプロトコルを用いてネットワーク装置のステータス情報を取得でき、ステップ３７１４でプロトコルパラメータマップ１８００の更新は終了する。ベンダーとモデルが取得またはサポートされていないとき、そのプロトコルはプロトコルパラメータマップ１８００から削除され、ステータス情報の取得には使用されない。プロトコルに応じて図２６に示したプロセスにいくつかの変形例（バリエーション）がある。HTTPとFTPはフローチャートの説明通りだが、ベンダーがサポートされているがモデルとジェネリックモデルはサポートされていない場合でさえも、SNMPはサポートされ、ステータス情報を取得するために使用されてもよい。
【０１２３】
上で説明したように、ベンダーとモデルが取得またはサポートされていなくても、SNMPによりステータス情報をネットワーク装置から取得できる。ネットワーク装置がSNMPをサポートし、SNMPによりアクセスできる限り、そのネットワーク装置の管理情報ベース（MIB）から情報を取得することができる。ステップ３７０２において、ネットワーク装置がSNMPを通じてアクセスできないとき、ステップ３７０４で、SNMPプロトコルはプロトコルパラメータマップ１４００から削除される。しかし、そのネットワーク装置にSNMPでアクセスできる場合、ベンダーやモデルが取得及びサポートされているかどうかにかかわらず、SNMPプロトコルはプロトコルパラメータマップ１８００に残される。SNMPをサポートするネットワーク装置はMIBを提供し、リモートシステムはそのネットワーク装置から情報を常に取得可能である。しかし、ネットワーク装置から取得可能な情報のタイプと数は、ベンダーとモデルが取得およびサポートされるかどうかに依存する。ベンダーとモデルが取得され、かつ知られていれば、SNMPによりネットワーク装置からより多くの情報を取得することができる。ベンダーとモデルを取得できなくても、SNMPはすべての装置が提供できる情報は取得可能である。例えば、システムの説明やシステムが動作している時間等は取得可能である。SNMPは次の３つの条件の下でネットワーク装置から情報を取得するために使用できる：（１）ベンダーとモデルがサポートされている；（２）ベンダーはサポートされているが、モデルはサポートされていない；（３）ベンダーもモデルもサポートされていない。HTTPとFTPは、SNMPのような特徴は有していない。SNMPは、すべてのネットワーク装置が従うことができる標準MIBを有しており、情報を取得できるが、ウェブページとFTPファイルは、ベンダーとモデルが異なるネットワーク装置では異なる。ネットワーク装置が情報を取得するために従うウェブページとFTPファイルの標準はない。
【０１２４】
図２７は、すべてのプロトコルを用いてネットワーク装置に関するステータス情報を取得するプロセスを説明するためのフローチャートである。図２５A及び２５Bを参照して説明したようにプロトコルオブジェクトが、それでサポートするネットワーク装置のベンダーとモデルに関する情報で初期化され後、そのプロトコルオブジェクトはネットワーク装置からステータス情報を取得するために使用可能である。そのプロトコルオブジェクトは、図１８，１９及び２０のサポートデータベースからの情報を含むデータ構造を用いて、所与のベンダーとモデルについてステータス情報をいかに取得するかに関する情報を含む。図２２を参照して説明したCAbsProtocol２３０８へのポインタのベクトルを使用して、すべてのプロトコルオブジェクトについてステータス情報を取得する。フローチャートのプロセスは、そのベクトルを一回通る。ステップ３１２２において、CAbsProtocolへのポインタのベクトルからプロトコルオブジェクトを取得する。プロトコルオブジェクトは、ネットワーク装置にアクセスするためのネットワークプロトコル（例えば、SNMP、HTTP、FTP）の１つに対応する。ステップ３１２４において、ベクトルから取得できるプロトコルオブジェクトがあるかどうか検査する。この検査は、ベクトルの終わりに来たかどうか判断することによりなされる。プロトコルオブジェクトがもう取得できなければ、ステップ３１２６において、すべてのプロトコルオブジェクトを用いてネットワーク装置からステータス情報を取得し終わっている。ベクトルから取得したプロトコルオブジェクトがあれば、ステップ３１２８において、そのプロトコルオブジェクトを用いてネットワーク装置のステータス情報を取得する。プロトコルオブジェクトを用いてステータス情報を取得した後、ステップ３１２２に戻り、他のプロトコルオブジェクトを用いてステータス情報をさらに取得する。
【０１２５】
図２８は、様々なプロトコルで取得するステータス情報を維持するために使用するデータ構造を示している。このデータ構造は、そのステータス情報を取得するためにどのプロトコルが使用されたかに関する情報を維持していない。データ構造はマップ724である。マップ７２４に対するキー７２６はinfoTypeである。infoTypeは情報のタイプを表す番号である。マップ７２４に対する値７２８はペアである。ペアはストリングと整数よりなる。ペア中のストリングは、infoTypeに対応するネットワーク装置から取得したステータス情報である。ペア中の整数は、プロトコルから取得したステータス情報の重みまたは優先度である。一例として、infoTypeが７００であり、それがプリンターカートリッジのブラックトナーのレベルを表す場合、そのペアはストリング「７５％」と整数１００００を含むかもしれない。ストリング「７５％」はカートリッジに７５％のトナーが残っていることを示し、整数１００００はそのステータス情報の重みまたは優先度である。CSNMPProtocol２４０２、CHTTPProtocol２５０２、CFTPProtocol２６０２は、ネットワーク装置から取得したステータス情報をマップ７２４に追加する。
【０１２６】
図２９は、図２１のプロトコルパッケージのそれぞれで使用されるパッケージ図を示し、ここでXXXはSNMP、HTTP、またはFTPのいずれかである。抽象クラスCAbsProtocolは、装置から情報を取得するインターフェイス関数を提供するが、その情報を取得するメソッドは提供しない。CAbsProtocolから派生するクラスは、装置から情報を取得する新しいプロトコルを追加しやすくする方法を提供する。CXXXProtocolImp1クラスは、XXXパッケージのインターフェイスであり、そのパッケージ内の他のすべてのクラス／パッケージを管理する。CXXXProtocolImp1はCabsProtocolから派生するので、このクラスは与えられたプロトコルで装置から情報を取得する方法を提供する。XXXaccessパッケージは、その装置にアクセスしてその装置から情報を取得するプロトコルを実装する。XXXODBCパッケージは、サポートデータベースからプロトコルサポート情報を取得する。この情報には、そのプロトコルがサポートするベンダー及びモデルの情報、その装置からベンダー、モデル、及び一意的識別子に関する情報をいかにして取得するかの情報、及びその装置からステータス情報をいかに取得するかの情報が含まれる。図３１，３２は、SNMP及びFTPの場合に具体的にこのパッケージ図を使用したものである。装置からステータス情報を取得するために使用する新しいプロトコルはいずれも、そのパッケージ図のこの構造に従う。そのような新しいプロトコルの１つとしてウェブサービスがある。また、様々なプロトコル実装もパッケージ図のこの構造に従ってよい。
【０１２７】
図３０は、図２１のプロトコルパッケージのそれぞれで使用可能な別のパッケージ図を示し、ここでXXXはSNMP、HTTP、またはFTPのいずれかである。このパッケージ図はどのプロトコルにも適用可能であるが、図３３に示されるようにHTTPプロトコルを例として説明する。このパッケージ構造は、装置から情報を取得する新たなプロトコルの実装を拡張可能にする。情報を取得するためのプロトコルの既存の実装が情報の新しいフォーマット（例えば、HTTPの別の実装を要する図４０及び４２に示したウェブページの例）に対してうまく機能しない場合、この拡張が必要である。図２９に示したように、このパッケージ図により、抽象クラスCAbsProtocolも使用される。CXXXProtocolクラスはCabsProtocolから派生する。CXXXProtocolは、XXXパッケージに対しインターフェイスを提供し、装置から情報を取得する異なる方法に対応するすべてのクラスを管理する。
【０１２８】
クラスCXXXProtocolImp1とCXXXProtocolImp2は、同じプロトコルを用いて情報を取得する異なる方法を使用する。CXXXProtocolImp1クラスは、装置から情報を取得するための実装を提供し、パッケージXXXaccess1及びXXXODBC1を用いる。XXXaccess1パッケージは、その装置にアクセスしてその装置から情報を取得するプロトコルを実装する。XXXODBC1パッケージは、データベースからプロトコルサポート情報を取得する。この情報には、そのプロトコルがサポートするベンダー及びモデル、その装置からベンダー、モデル、及び一意的識別子に関する情報をいかにして取得するかの情報、及びその装置からステータス情報をいかに取得するかの情報が含まれる。CXXXProtocolImp2クラスは、CXXXProtocolImp1と同じプロトコルを用いて装置から情報を取得するための他の実装である。CXXXProtocolImp2は、パッケージXXXaccess2とXXXODBC2を使用する。XXXaccess2パッケージは、その装置にアクセスしてその装置から情報を取得するプロトコルを実装する。XXXODBC2パッケージは、XXXODBC1と同様に、データベースからプロトコルサポート情報を取得する。このパッケージの設計により、プロトコルの新しい実装が可能となる。新しい実装が必要なとき、そのプロトコルを用いて装置にアクセスし、サポートデータベースから情報を取得するために、他の実装クラスがサポートパッケージとともに追加される。本発明の実施形態は、新しい実装の新しい装置とともに、すでにサポートされている装置から情報を取得するための既存の実装でも機能する。
【０１２９】
SNMPとFTPのパッケージ図は、図２９のパッケージ構造に従い、図３１及び３２に示されている。このシステムのHTTPのパッケージ図は、図３０のパッケージ構造に従い、図３３に示されている。
【０１３０】
図３１は、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を使用してデータベースから情報を取得する。
【０１３１】
図３２は、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パッケージの場合のパッケージ図を示し、図３０に示したパッケージ図に基づく。このパッケージは、ウェブページから情報を取得するためのHTTPの２つの実装例を含んでいる。このパッケージは、図２１を参照して上で説明したように、抽象クラスCAbsProtocolを使用する。CHTTPProtocolクラスはCAbsProtocolから派生する。CHTTPProtocolは、HTTPパッケージのためのインターフェイスであり、装置から情報を取得するHTTPの２つの異なる実装例に対応するパッケージを管理する。tagHTTPImplementationパッケージは、装置のウェブページのタグから情報を取得するためのHTTPの実行手段である。tagHTTPImplementationパッケージは、関連する米国特許出願第１１／０３２，０３９の実施例として説明されており、そのパッケージは第２HTTPImplementationと呼ばれる。TagHTTPImplementationパッケージはTagHTTPODBCパッケージを用いて、サポートされる装置及びその装置から情報を如何にして取得するかについてのサポート情報をデータベースから取得する。ScriptHTTPImplementationパッケージは、図４０及び４２に示したような装置のウェブページのジャバスクリプトから情報を取得するためのHTTPの他の実行手段を提供する。ScriptHTTPImplementationパッケージは、ScriptHTTPODBCパッケージを用いて、サポートされる装置及びその装置から情報をいかに取得するかに関するサポート情報をデータベースから取得する。ScriptHTTPIMplementationパッケージによるHTTPの第２の実行手段は、情報がウェブページのジャバスクリプト中に有る場合に、装置から情報を取得する問題を取り扱う。HTTP_HTMLToolは１つのパッケージとして示されているが、それは２つの実装パッケージにより使用されるオブジェクトを含むネームスペースである。ネームスペースを用いることにより、それが含むオブジェクトをHTTPパッケージ内で使用できる。これにより、HTTPのすべてのクラス及びパッケージがネームスペースのオブジェクトを共有することができる。HTTPパッケージは、HTTPが装置に関する情報を取得するためのインターフェイスを提供する抽象クラスCAbsHTTPImplementationを含む。アペンディックス２はCAbsHTTPImplementationのクラス仕様を提供する。CAbsHTTPImplementationから派生したクラスは、その情報を実際に取得する方法を提供する。TagHTTPImplementation及びScriptHTTPIMplementationパッケージは、情報を取得する方法を規定するCAbsHTTPImplementationから派生したクラスを含む。このHTTPパッケージの設計により、将来の拡張が可能である。現在の実行手段が装置のウェブページから情報を取得できなかった場合、或る実行手段とODBCパッケージを追加することにより、新しい実行手段のデザインを追加することができる。
【０１３３】
図３４では、CHTTPProtocolクラスのデータ構造m_ImplementationMapが同じエンティティ内に示される。マップ構造m_ImplementationMapのキーは、CAbsHTTPImplementationクラスへのポインタである。キーは抽象クラスCAbsHTTPImplementationへのポインタであるが、そのポインタは実際にはCAbsHTTPImplementationの派生クラスを指す。図３４は、CAbsHTTPImplementationの２つの派生クラスであるCFirstHTTPImplementationとCSecondHTTPImplementationに対応するマップのサンプルエントリーを示す。マップの値は、キーで指し示された実装クラスが使用されるかどうかを示すブール値である。このマップは、システムがスタートする際、CHTTPProtocolのコンストラクタが呼び出されるときに初期化される。このマップは、情報を取得するHTTPの様々な全ての実現手段で占められ、そのブール値は偽に設定される。どの装置を監視するかを判断するディスカバリープロセス中に（初期化中に）、どの実装が必要かを判断する。装置から情報取得するために或る実行手段が必要な場合、そのブール値は真に設定される。ディスカバリープロセスが完了した後、実行手段に対応するブール値が偽であったならば その実行手段はマップから削除される。
【０１３４】
図３５では、サンプルエントリーと共に、CHTTPProtocolクラスのマップ構造m_VendorModelSupportMapを示す図である。このマップを用いて、被監視装置の特定のベンダー及びモデルの情報を取得するために、HTTPのどの実行手段を使用するかを判断する。そのマップのキーは、ベンダー及びモデル名の連結を含むストリングである。そのキーに対応する値は、抽象クラスCAbsHTTPImplementationに対するポインタのベクトルである。ポインターは、実際にはCAbsHTTPImplementationの派生クラスの１つを指し示す。ベクトルは、或るベンダ及びモデルに関するステータス情報を取得するためのHTTPの全ての実行手段を含む。マップm_VendorModelSupportMapは、システムのディスカバリープロセスの間に（初期化の際）占められる。
【０１３５】
図３６Ａ，３６Ｂ，３６Ｃのシーケンス図はinitWithVendor(),initWithModel()及びinitWithVendorModel()のCHTTPProtocolの関数のプロセスを示す。これらの関数はHTTPプロトコルの実行手段全てを初期化し、特定のベンダー、特定のモデル又は特定のベンダー及びモデルに関する装置のステータス（状態）を取得するために、各実行手段が情報を有するようにする。これらの関数は、SNMP又はFTPのような別のプロトコルがその装置のベンダー及び／又はモデルを発見したときはいつでも及びHTTPプロトコルオブジェクトが装置についてのHTTPサポート内容の存否を確認するためにベンダー及び／又はモデルで初期化されることを要するときはいつでも呼び出される。
【０１３６】
図３７のフローチャートはCHTTPProtocolの関数obtainStatus()のプロセスを示し、マップm_VendorModelSupportMapを利用する。このプロセスは、関数への入力がステータス情報を取得するのに適切な情報を含んでいるか否かを確認する。含んでなければこの関数は偽を返す。関数の入力が適切な情報を含んでいたならば、このプロセスはベンダー及びモデルに関するHTTPサポートの有無を確認する。無ければ関数は偽を返す。ベンダー及びモデルがHTTPでサポートされていたならば、そのベンダー及びモデルをサポートするHTTPの全ての実行手段は、装置のウェブページからステータス情報を取得する。HTTPの全ての実行手段が装置から何らかのステータス情報を得ることに失敗すると、その関数は偽を返す。そうでなければ関数は真を返す。
【０１３７】
図３８は、TagHTTPImplementationパッケージに関するパッケージ図である。このパッケージは、装置のウェブページのタグから情報を取得するためにHTTPを実装する。クラスCTagHTTPImplementationは、このパッケージのインターフェイスであり、装置のウェブページから情報を取得するメソッドを実装するように他のクラス及びパッケージを管理する。CTagHTTPImplementationは、CAbsHTTPImplementationから派生したクラスである。TagHTTPODBCパッケージとHTTP_HTMLToolパッケージは、図３３を参照しながら既に説明された。クラスCTagHTMLProcessorは、装置のウェブページを処理して、所望の情報を取得する。このクラスは、特定のフォーマットのウェブページのテキストを処理して所望の情報を取得する方法を含む。より具体的には、このクラスはウェブページを処理し、そのウェブページでは、情報を発見するためのキーワードが複数の箇所に登場する。
【０１３８】
図３９は、CTagHTTPImplementationのマップ構造m_VendorModelWebInfoMapを示す図である。このマップ構造は、装置のウェブページからその装置のステータス情報を取得するために、HTTPのタグ実行手段により使用される。そのマップのキーは、装置のベンダー名のストリングである。そのマップの値は、与えられたモデルの装置のウェブページからステータス情報を取得するために用いられる情報を含む他のマップである。内部マップのキーは、装置のモデル名のストリングであり、その値は、ウェブページに関する情報とウェブページからステータス情報をいかに取得するかに関する情報とを含むベクトル構造SWebPageInfoである。構造SwebPageInfoは、ウェブページから或る一つの情報を取得するために必要なすべての情報を提供する構造SPreconKeyValueInfoを含む。マップ構造は、HTTPのタグ実行手段用のサポートデータベースのテーブルからの情報で占められる。CTagHTTPImplementationはTagHTTPODBCパッケージを用いてデータベースのテーブルから情報を取得する。
【０１３９】
図４０はシステムがステータス情報を抽出するための装置のウェブページ例である。このウェブページサンプルは装置のステータス情報を含むジャバスクリプトを使用する。
【０１４０】
図４１では、HTMLソースファイルの一部が示され、このファイルの結果ウェブページは図４０に示されるようにブラウザ上で表示される。ファイルはHTMLタグ及びジャバスクリプト双方を示す。様々なトナーレベルについての情報はジャバスクリプトで発見される。
【０１４１】
図４２はシステムがステータス情報を抽出するための装置の別のウェブページ例である。このウェブページサンプルも装置のステータス情報を含むジャバスクリプトを使用する。
【０１４２】
図４３では、HTMLソースファイルの一部が示され、このファイルの結果ウェブページは図４２に示されるようにブラウザ上で表示される。ファイルはHTMLタグ及びジャバスクリプト双方を示す。黒色のトナーレベルについての情報はジャバスクリプトで発見される。
【０１４３】
図４４ではScriptHTTPImplementationパッケージ用のパッケージ図が示される。このパッケージはHTTPを実装し、図４０，４２に示されるような装置のウェブページのジャバスクリプトから情報を取得する。クラスCScriptHTTPImplementationは、このパッケージのインターフェイスであり、他のクラス及びパッケージを管理し、装置のウェブページのジャバスクリプトから情報を取得する方法を実行する。CScriptHTTPImplementationはCAbsHTTPImplementationから導出されるクラスである。アペンディックス３はCScriptHTTPImplementationのクラス仕様を示す。ScriptHTTPODBCパッケージ及びHTTP_HTMLToolパッケージは図３３に関連して説明済みである。クラスScriptHTMLProcessorは装置のウェブページを処理し、装置のウェブページからジャバスクリプトのみを取得する。クラスCabsScriptProcessはステータス情報を取得するためにジャバスクリプトを処理する抽象クラスである。アペンディックス４はCabsScriptProcessのクラス仕様を示す。クラスCAbsScriptProcessは一組の共通関数を用意し、ウェブページのタグから情報を取得するため及びウェブページのジャバスクリプトから情報を取得するために使用されるデータ構造を初期化する。CabsScriptProcessから導出されたクラスは関数各々についての方法をもたらす。本方法は装置のウェブページ、モデル及びベンダーに依存する。様々な派生クラスがインターフェイス関数の処理を様々に処理できるように、抽象クラスの派生クラスは多数存在してよい。抽象クラスは新たな装置が加えられることを許可し、その情報はウェブページのジャバスクリプト中に存在する。
【０１４４】
図４５ではCScriptHTTPImplementationのマップ構造m_VendorModuleInfoMapが示され、そのマップ構造はHTTPのスクリプト実効手段により使用され、装置のウェブページのジャバスクリプトからその装置のモデル名を取得する。マップのキーは装置のベンダー名のストリングである。マップの値は構造SModuleInfoのベクトルである。構造SModuleInfoは、装置のベンダー名のストリングと、モデル名を含む装置のウェブページのストリングと、（装置のモデル名を取得するためにウェブページ中のジャバスクリプトを処理する）抽象クラスCAbsScriptProcessに対するポインタとを含む。ポインタはCAbsScriptProcessの派生クラスを指す。
【０１４５】
図４６では、CScriptHTTPImplementationのマップ構造m_UniqueIDInforMapが示され、このマップ構造は、装置のウェブページのジャバスクリプトからその装置固有の識別子を取得するために、HTTPのスクリプト実行手段により使用される。固有の識別子は装置を確認する文字列（ストリング）であり、例えばシリアル番号やMACアドレスである。マップに対するキーは、装置のベンダー及びモデル名の連結であるストリングである。その値は構造SUniqueIDInfoである。構造SUniqueIDInfoは、装置のベンダー名のストリングと、装置のモデル名のストリングと、固有の識別子を含む装置のウェブページのストリングと、（装置固有の識別子を取得するためにウェブページ中のジャバスクリプトを処理する）抽象クラスCAbsScriptProcessに対するポインタとを含む。ポインタはCAbsScriptProcessの派生クラスを指す。
【０１４６】
図４７では、CScriptHTTPImplementationのマップ構造m_StatusMapが示され、このマップ構造は、装置のウェブページのジャバスクリプトからその装置固有の識別子を取得するために、HTTPのスクリプト実行手段により使用される。マップのキーは或るストリングであり、そのストリングは装置のベンダー及びモデル名の連結である。その値は構造SwebPageStatusのベクトルである。構造SWebPageStatusは、ウェブページのストリングと、ウェブページから取得可能なステータス情報及びウエイト（優先度）のマップ構造と、（装置のステータス情報を取得するためにウェブページ中のジャバスクリプトを処理する）抽象クラスCAbsScriptProcessに対するポインタとを含む。ポインタはCAbsScriptProcessの派生クラスを指す。
【０１４７】
３つのマップ構造は例えばディスカバリープロセスのようなシステムの初期化中に占められる。CAbsScriptProcessの派生クラス全てが作成され、システムの初期化中に初期化される。派生クラスはウェブページのジャバスクリプトから所望の情報を抽出するのに必要な情報と共に初期化される。システムの初期化後に、装置のウェブページからステータス情報を周期的に取得するためにマップ構造m_StatusMapのみが必要とされる。従って、初期化後に、構造m_VendorModelInfoMap及びm_UniqueIDInfoMapはもはや必要ないので削除（クリーンアップ）される。
【０１４８】
図４８では、ScriptHTTPImplementationパッケージによるステータス情報取得手順を示すフローチャートが示される。第１ステップはIPアドレスが空(empty)であるか否かを検査する。IPアドレスが空でなければ本プロセスは偽を返す。そうでなければ本方法は装置のベンダー及びモデル名がHTTPのスクリプト実行手段によりサポートされているか否かを確認する。ベンダー及びモデルがサポートされていなかったならば、本プロセスは偽を返す。そうでなければ本方法はHTTPにより装置のウェブページへのアクセスに要する遅延時間を設定する。次に装置とHTTPセッションが始められる。HTTPセッションが開始できなかったならば、本プロセスは偽を返す。そうでなければ本プロセスは或る装置のウェブページ全てを取得し、そのウェブページのジャバスクリプト中にはステータス情報が含まれている。ウェブページの各々について、本プロセスは以下に説明される手順を用いてジャバスクリプトからステータス情報を取得する。ウェブページからステータス情報を取得した後に、本プロセスはその装置とのHTTPセッションを終了する。HTTPのスクリプト実行手段によりステータス情報がその装置から一切取得されなくなったならば、本プロセスは偽を返す。そうでなければ本プロセスは真を返す。
【０１４９】
ウェブページのジャバスクリプトからステータス情報を取得する際に、本プロセスは、どの情報が取得されることを要するかを確認する。これは、他のプロトコルにより又は他のHTTPの実行により既に取得済みのステータス情報を検査することでなされる。ウェブページから取得されるべきステータス情報が取得されていない場合或いは取得されているが低い重み（優先度）であった場合、本プロセスはステータス情報を取得する。全てのステータス情報が既に取得済みであったならば、ウェブページからステータス情報を取得するプロセスは完了する。そうでなければ本プロセスはステータス情報を取得するためにスクリプトプロセッサを初期化する。初期化はCAbsScriptProcessのstart()関数を呼び出すことを含む。そしてこのプロセスはスクリプトプロセッサを用いてステータス情報を取得する。ステータス情報の取得は、CAbsScriptProcessのtransformData()関数を呼び出すことを含む。図４９はtransformData()関数を用いてステータス情報を取得する様子の詳細を示す。スクリプトプロセッサを用いてステータス情報を取得すると、ウェブページからステータス情報を取得するプロセスは完了する。
【０１５０】
図４９では、ScriptHTTPImplementationパッケージのスクリプトからステータス情報を取得するプロセスを説明するためのフローチャートが示される。第１に本プロセスはHTTPセッションを用いてウェブページへのアクセスを試みる。ウェブページにアクセスできなかったならば本プロセスは偽を返す。そうでなければ本プロセスはウェブページからライン(line)を取得する。ウェブページからラインが取得されると、本プロセスはそのラインがジャバスクリプトの一部であるか否かを確認する。一部でなければ、本システムはウェブページから次のラインを取得する。そうでなければ、本プロセスはスクリプトプロセッサを用いてそのジャバスクリプトからステータス情報を取得する。スクリプトプロセッサがジャバスクリプトのラインからステータス情報を取得しなかったならば、本システムはウェブページから次のラインを取得する。そうでなければ本プロセスはスクリプトプロセッサから取得したステータス情報が必要か否かを確認する（スクリプトプロセッサで取得されたもの以上のウエイトを有するステータス情報が、他のプロトコルにより又はHTTPの他の実行手段により既に取得済みであったならば、ステータス情報は不要かもしれない。）。ステータス情報が必要とされるならば、本プロセスはそのステータス情報を格納する。ステータス情報は図２８に示されるマップ構造に位置づけられる。ステータス情報を格納した後に又はステータス情報が不要であった場合に、本プロセスは、より多くのステータス情報がウェブページのジャバスクリプトから取得される必要の有無を確認する。より多くのステータス情報が取得されなければならない場合、システムはウェブページから次のラインを取得する。取得されるべき更なるステータス情報が無かった場合又はウェブページから取得可能な更なるラインが無かった場合、本プロセスは、ジャバスクリプトから取得される何らかのステータス情報の有無を確認する。ステータス情報が一切取得されないならば、本プロセスは偽を返す。そうでなければ本プロセスは真を返す。
【０１５１】
図５０はScriptHTTPODBCパッケージを示すクラス図である。このパッケージはサポートデータベースとインターフェイスをとり、装置のウェブページのジャバスクリプトからモデル名、固有の識別子及びステータス情報を抽出するのに使用される情報を取得する。CScriptHTTPODBCクラスは、このパッケージに関するインターフェイスであり、他のクラスを管理し、サポートデータベースのテーブルから適切な情報を取得する。アペンディックス５はCScriptHTTPPODBCのクラス仕様を示す。CXXXDataクラス及びその対応するCXXXTableクラスは、テーブルから情報を取得するための、図１９に示されるサポートデータベースのXXXテーブルへのアクセス権を与える。このパッケージは、様々な装置のウェブページのジャバスクリプトを処理するのに使用されるCAbsScriptProcessの全ての派生クラス、CYYYScriptProcessを含む。各派生クラスは、ステータス情報を取得するのに使用されるデータ構造を設定し（putParameters()関数）、ステータス情報を取得するためにプロセスを初期化し（start()関数）、ジャバスクリプトからステータス情報を取得し(transformData()関数)、及びステータス情報を取得するプロセスを終了する(end()関数)ための方法を用意する。HTTPのスクリプト実行手段によりサポートされる新たな装置の追加は、その装置のCAbsScriptProcessから導出される新たなクラスの追加を要する。CScriptHTTPODBCの関数setupCreateFunctionMap()は、CAbsScriptProcessの派生クラス全てについてデータ構造を作成及び設定する。
【０１５２】
図５１に示される状態図は、情報を取得するためにCAbsScriptProcessの派生クラスにより装置のウェブページのジャバスクリプトを処理するためのものである。この状態図はCAbsScriptProcessのtransformData()関数に対応する。アペンディックス４はCAbsScriptProcessのクラス仕様を示す。CAbsScriptProcessで規定される１つの
構造及び２つのenum（列挙）がある。enumEReturnはtransformData()関数によって使用され、装置のウェブページのジャバスクリプトから情報を取得する際に関数の結果を返す。enumEStateはtransformData()関数によって使用され、ジャバスクリプトから情報を取得するプロセスの状態を確認する。状態図中のほとんどの状態はenumEStateに関連する。構造SinfoStructureはウェブページのジャバスクリプトから情報を取得するのに使用される。CAbsScriptProcessの派生クラスはenums及び構造の利用の際に変化する。或る派生クラスはtransformData()でenumEReturnの２値のみを利用するが、別の派生クラスは４つ全てを使用するかもしれない。或る派生クラスはenumEStateの２値のみを用いて所望の情報を取得するが、別の派生クラスは３つだけ又は４つを使用するかもしれない。或る派生クラスは、ウェブページから情報を取得するためのtypeSInfoStructureである帰属メンバを含み、別の派生クラスはウェブページから複数の情報を取得するためのSinfoStructureのベクトルである帰属メンバを含むかもしれない。
【０１５３】
状態図では、enumEStateの値に対応する５つの状態全てが示されているが、ジャバスクリプトから所望の情報を取得する際に全ての装置について全てが使用されなくてもよい。状態数や、状態間の遷移に使用される構造SinfoStructureにおけるm_sParの数は、ベクトル、モデル及びウェブページに依存する。状態図は状態eStartから始まる。このプロセスは、structSInfoStructureのストリングm_sPar1がジャバスクリプトのライン中に発見されるまで、このeStart状態のままである。ベンダー、モデル及びウェブページに対応するプロセスが、データの抽出前にm_sPar1を発見することだけを必要としていたならば、次の状態は抽出状態であり、ジャバスクリプトのラインから情報が抽出される。こうしてこのプロセスは完了する。そうでなければ次の状態はePrecon1である。このプロセスは、structSInfoStructureのストリングm_sPar2がジャバスクリプトのライン中に発見されるまで、ePrecon1のままである。本プロセスが、データ抽出前に、発見されるべきm_sPar2を要するベンダー、モデル及びウェブページに関連するならば、次の状態は抽出状態であり、ジャバスクリプトのラインから情報が抽出される。かくてこのプロセスは完了する。そうでなければ次の状態はePrecon2である。状態ePrecon2及びePrecon3の遷移は状態ePrecon1のものと同様であるが、structSInfoStructureのストリングm_sPar3及びm_sPar4が生じる状態遷移を引き起こす点が異なる。プロセスが状態ePrecon5にあると、そのプロセスは、構造SInfoStructureのm_sPar5がジャバスクリプトのライン中に発見されるまでその状態にとどまる。次の状態は抽出状態であり、このプロセスは終了する。ジャバスクリプトから情報を得る際に、５つのストリングm_sPar1乃至m_sPar5は、所望の情報を取得するのに必要なほとんどのストリングであるべきである。
【０１５４】
図５２はCAbsScriptProcessの２つの派生クラスで使用されるデータ構造サンプルを示す。CAbsScriptProcess、CSamsungStatusCLP550ScriptProcessの第1派生クラスは、structSInfoStructureのベクトルを用いて、装置のウェブページのジャバスクリプトからカラートナーレベルを得る。トナーレベルの各々はステータス情報を取得するために3つのストリングm_sPar1ないしm_sPar3を要する。従って情報を取得するためのプロセスは、ステータス情報がジャバスクリプトから抽出される前に、３つの状態を介して進行する−eStart、ePrecon1及びePrecon2。第２の派生クラス（CsamsungStatusML2550ScriptProcess）は、structSInfoStructureをそれ自身で使用し、装置のウェブページのジャバスクリプトから黒色のトナーレベルを取得する。黒色のトナーレベルを得るためにトナーレベルは２つのストリングm_sPar1及びm_sPar2を要する。従ってその情報を取得するためのプロセスは、ブラックトナーレベルがジャバスクリプトから抽出される前に、2つの段階を通じて進行する−eStart及びePrecon1。アペンディクス６，７はCSamsungStatusCLP550ScriptProcess及びCsamsungStatusML2550ScriptProcessのクラス仕様をそれぞれ示す。
【０１５５】
図５３では、ウェブページのサンプルを使用して、CAbsScriptProcessの派生クラスがジャバスクリプトを含む装置のウェブページをどのように処理するかを示す。structSInfoStructureのサンプル値はウェブページの下に示されている。この例では取得されているステータス情報は、シアン色のトナーレベルである。structSInfoStructureの３つのストリング（パラメータ）m_sPar1、m_sPar２及びm_sPar３がステータス情報を見つけるのに必要とされる。structSInfoStructureのEstate m_Stateは遭遇したストリングを追跡し続けるのに使用される。structSInfoStructureの区切り符号（デリミタ）m_sDelimiter及びstructSInfoStructureの位置m_nInLinePositionは、ステータス情報を含むラインからステータス情報を抽出するのに必要とされる。ウェブページのラインは、全てのステータス情報が取得されるまで或いはウェブページの最後に遭遇するまで読み取られる。ジャバスクリプトの一部であるラインのみが、CAbsScriptProcessのtransformData()に伝送される。structSInfoStructureのm_Stateの初期値はeStartである。ジャバスクリプトのラインはCAbsScriptProcessのtransformData()に伝送される。ライン“関数RemainTonerOption()”がそこに伝送されると、structSInfoStructureのm_sPar1がライン中で発見される。structSInfoStructureのm_StateはePrecon1である。ジャバスクリプトの更なるラインはm_Stateに対する変更なしに伝送される。ライン“else”がそこに伝送されると、structSInfoStructureのm_sPar2がライン中で発見される。structSInfoStructureのm_StateはePrecon2である。ジャバスクリプトの更なるラインは、ライン“varCyanTonerPre=100”がそこに伝送されるまで、m_Stateに対する変更なしに伝送される。structSInfoStructureのm_sPar3はライン中で発見され、structSInfoStructureのm_sDelimiter及びm_nInLinePositionの値を用いてそのラインからステータス情報が抽出される。M_sDelimiterはステータス情報を区切るキャラクタであり、m_nInLinePositionはステータス情報に遭遇する前にどの程度多くのデリミタが有るかを決定する数である。ステータス情報が最初のデリミタより先にある場合には、m_nInLinePositionは０である。シアントナーレベルについてジャバスクリプトから「１００」の値が得られると、更なるウェブページは取得されることを要しない。
【０１５６】
図５４はCAbsScriptProcessの派生クラスのプロセスを示すフローチャートであり、装置のウェブページから情報を抽出するためのものである。このフローチャートは図５３で説明されたようなシアントナーレベルを抽出するのに使用されるサンプルプロセスである。このプロセスはCAbsScriptProcessのtransformData()に対応する。CAbsScriptProcessの派生クラスのtransformData()の方法はベンダー及びモデルによって変化するが、ステータス情報を見出すためにステータスを使うことは、ステータス情報を取得するための共通の手法である。
【０１５７】
図５５Aはウェブページから情報を抽出するのに使用される構造structSInfoStructureのメンバを示す。この構造は、アペンディックス４で示されるCAbsScriptProcessで規定され、CAbsScriptProcessの全ての派生クラスで使用可能である。ストリングm_sParXXXをCAbsScriptProcessの派生クラスで使用し、所望の情報を含むウェブページのラインを見出す。所望の情報を見出すのに全てのストリングが必要なわけではなく、５つのストリングm_sParXXXを利用可能にすることで、所望の情報を見出すのに５つ全てのストリングを要するかもしれない将来的な装置に備えた柔軟性を可能にする。ストリングm_sDelimiter及び整数m_nInLinePositionは、情報を含むウェブページのラインから所望の情報を抽出するのに使用される。infoTypeのm_nENUMは、シアントナーレベルを表現するeCyanや、装置で印刷されるページ総数を表現するePrtLifeCountのように、抽出されるべき情報のタイプを表現する数である。EStateのm_Stateは、ウェブページから所望の状態を突き止めるので、構造の状態を追跡し続けるのに使用される。それは開始状態でeStateに初期化され、各ストリングm_sParXXXに出会うと状態を変える。
【０１５８】
CAbsScriptProcess、その派生クラス及びその構造SInfoStructureの説明及び利用法に関し、ウェブページのスクリプトからデータを取得することに焦点が当てられてきたが、それらの構造及び方法の有用性はウェブページのタグからデータを抽出することに適用されてもよく、その場合m_sParXXXはデータを取得するための或るタグに対応する。
【０１５９】
図５５Bは図５５Aの構造SinfoStructureのメンバのサンプル値を示す。この構造は装置のシアントナーレベル（m_nENUM=eCyan）をそのウェブページから見出すのに使用される。m_sPar1ないしm_sPar3の３つのストリングのみが所望の情報を見出すのに必要とされる。m_sPar4及びm_sPar5の残りの２つはエンプティであり、使用されない。M_sDelimiterのキャラクタ‘＝’及び‘，’並びにm_nInLinePositionの１を用いて、所望の情報が存在するラインからそれを抽出する。
【０１６０】
ネットワークに接続された監視が必要な少数の装置について本発明を示したが、当然のことながら、本発明の精神と範囲から逸脱することなく、ネットワークに接続される装置の数はいくつでもよい。また、本発明は、いろいろな装置を監視かつ制御する必要があるような家庭環境に適用してもよい。
【０１６１】
本発明の実施形態によれば、マルチベンダー環境において、いろいろな装置の監視が可能となり、特定のプライベートなマネージメント情報ベース（MIB）情報を持たなくても、詳細な情報を検索し、ユーザが理解しやすく扱いやすい方法で表示することを促す。さらに、読み出した情報は、SMTP、FTP、ウェブサービス等のいろいろな方法を用いて再配信することができる。
【０１６２】
コンピュータ技術の当業者には明らかであるように、本発明のコントローラは、本発明の教示によりプログラムされた、通常の汎用デジタルコンピュータまたはマイクロプロセッサとしてもよい。本開示の教示に基づく知識を備えたプログラマーは容易に適当なソフトウェアのコーディングをでき、ソフトウェア技術の当業者には明らかである。本発明は、特定用途用集積回路や従来のコンポーネント回路を適当に配線して相互接続することによっても実施することができ、これは当該分野の当業者には明らかである。
【０１６３】
本発明はコンピュータをプログラムし本発明のプロセスを実行させる命令を含むコンピュータプログラム、およびそのコンピュータプログラムが格納された記録媒体を含む。記録媒体には、フロッピディスク、光ディスク、CD-ROM、光磁気ディスク、ROM、RAM、EPROM、EEPROM、磁気または光カード、その他の電子的命令を格納するのに好適ないかなる媒体も含む。
【０１６４】
上記の教示を考慮して本発明を様々に修正したり、バリエーションを考えたりすることができる。従って、当然のことながら、添付したクレームの範囲内で、ここに具体的に説明したものとは別の実施形態により本発明を実施することができる。
【０１６５】
以下に、付録（アペンディックス）を示す。
【図面の簡単な説明】
【０１６６】
【図１】インターネットを介してコンピュータおよびデータベースのネットワークに接続された、ネットワーク化されたビジネスオフィス装置群を示す図である。
【図２】デジタル画像形成装置の構成を示す図である。
【図３】図２に示したデジタル画像形成装置の電子的構成を示す図である。
【図４】図３に示した複数ポート通信インターフェイスの詳細を示す図である。
【図５】ビジネスオフィス装置がネットワークに直接接続された、またはネットワークに接続されたコンピュータに接続された別のシステム構成を示す図である。
【図６Ａ】電子メールを用いたアプリケーション部への及びそこからの情報の流れを示すブロック図である。
【図６Ｂ】電子メールを用いた通信の別の方法を示す図（アプリケーション部に接続されたコンピュータはメッセージ転送エージェント（MTA）としても機能する）である。
【図６Ｃ】電子メールを用いた通信の別の方法を示す図（アプリケーション部は電子メールを交換するメッセージ転送エージェントを含む）である。
【図６Ｄ】メールサーバがPOP3サーバとして機能して機器／装置のメールを受信し、シンプルメール転送プロトコル（SMTP）サーバとして機能してその機器／装置のメールを送信する、電子メールを用いた通信の別の方法を示す図である。
【図７】インターネットを通してメッセージを送信する別の方法を示す図である。
【図８】機器／装置に接続し、電子メールメッセージを通信するために使用するコンピュータの一例を示す図である。
【図９】本発明の一実施形態によるシステム全体を示す概略図である。
【図１０】本発明の一実施形態による、データの監視に使用するモジュールとそのインターフェイス機能を示す図である。
【図１１】監視モジュールの詳細とサブモジュール間の呼び出し機能を示す図である。
【図１２】図１０に示した監視モジュールのinit関数のシーケンスを示す図である。
【図１３】図１１に示した、監視マネージャにより監視される装置の状態を判断する状態監視機能のシーケンスの一例を示す図である。
【図１４】図１２に示した、CDeviceFactoryにより生成され監視マネージャにより使用される、装置を示すベクトルを示す図である。
【図１５】本発明の一実施形態による、被監視装置へのアクセスに必要なパラメータ値を格納するために使用するSParameterデータ構造を示す図である。
【図１６】本発明の一実施形態による、被監視装置へのアクセスに必要なパラメータ値を格納するために使用するマップ構造を示す図である。
【図１７】本発明の一実施形態で使用する監視データベースの構成を示す図である。
【図１８】本発明の一実施形態による通信プロトコルにより構成されたサポートデータベースの構成を示す図である。
【図１９】本発明の一実施形態によるHTTPプロトコル用のサポートデータベースの構成を示す図である。
【図２０】本発明の一実施形態による通信プロトコルにより構成されたサポートデータベースの構成を示す図である。
【図２１】本発明の一実施形態によるHWaccessモジュールのクラス構造を示す図である。
【図２２】本発明の一実施形態による、被監視装置にアクセスしその被監視装置からステータス情報を取得するために必要な情報を維持する、図２１のHWaccessモジュールで使用されるデータ構造を示す図である。
【図２３】関しパッケージのinit関数が呼び出された場合のHwaccessパッケージの初期化シーケンス図である。
【図２４】装置が何らかのプロトコルでアクセス可能か否かを判別するために、HWaccessパッケージのcanAccessIP()のシーケンス図である。
【図２５Ａ】HwaccessパッケージのobtainVendor(),obtainModel()及びobtainUniqueID()関数のシーケンス図である。
【図２５Ｂ】HwaccessパッケージのobtainVendor(),obtainModel()及びobtainUniqueID()関数のシーケンス図である。
【図２６】本発明の一実施形態による、どのプロトコルを使用して被監視装置のステータス情報を取得するかを判断するために、被監視装置を表すソフトウェアオブジェクトで使用されるデータ構造がどのように更新されるかを示すフローチャートである。
【図２７】本発明の一実施形態による、すべての通信プロトコルを用いて被監視装置からステータス情報を取得する過程を示すフローチャートである。
【図２８】本発明の一実施形態による、各プロトコルについて、ある特定のベンダーとモデルに関する被監視装置のステータス情報を格納及び維持するために使用するデータ構造を示す図である。
【図２９】図２１の各プロトコルパッケージを示すパッケージ図（「XXX」はHTTP、FTP、SNMP等である）を示す。
【図３０】図２１の各プロトコルパッケージを示す別のパッケージ図（「XXX」はHTTP、FTP、SNMP等である）を示す。
【図３１】SNMPパッケージのクラス構造を示す図である。
【図３２】FTPパッケージのパッケージ図を示すである。
【図３３】スクリプト中のウェブページ及びタグからの情報抽出をサポートするHTTPパッケージのパッケージ図である。
【図３４】CHTTPProtocolクラスのデータ構造m_ImplementationMapを示す図である。
【図３５】CHTTPProtocolクラスのデータ構造m_VendorModelSupportMapを示す図である。
【図３６Ａ】CHTTPProtocolのinitWithVendor()関数のシーケンス図を示す。
【図３６Ｂ】CHTTPProtocolのinitWithModel()関数のシーケンス図を示す。
【図３６Ｃ】CHTTPProtocolのinitWithVendorModel()関数のシーケンス図を示す。
【図３７】HTTPを介して装置のステータス情報を取得するフローチャートである。
【図３８】装置のウェブページのタグから情報を抽出するためのTagHTTPImplementationパッケージのパッケージ図を示す。
【図３９】CScriptHTTPImplementationクラスのマップ構造m_VendorModelWebInfoMapを示す図である。
【図４０】システムがステータス情報を抽出するための装置のウェブページ例を示す図である。
【図４１】図４０のウェブページの表示を生成するジャバスクリプト及びHTMLタグの一部を示す図である。
【図４２】本発明のシステムがステータス情報を抽出するための装置の別のウェブページ例を示す図である。
【図４３】図４２のウェブページの表示を生成するジャバスクリプト及びHTMLタグの一部を示す図である。
【図４４】装置のウェブページのスクリプトから情報を抽出する、ScriptHTTPImplementationパッケージのパッケージ図を示す。
【図４５】モデル名、固有のID及びステータス情報を装置のウェブページから取得するのに使用されるCScriptHTTPImplementationクラスのデータ構造を示す図である。
【図４６】モデル名、固有のID及びステータス情報を装置のウェブページから取得するのに使用されるCScriptHTTPImplementationクラスのデータ構造を示す図である。
【図４７】モデル名、固有のID及びステータス情報を装置のウェブページから取得するのに使用されるCScriptHTTPImplementationクラスのデータ構造を示す図である。
【図４８】ScriptHTTPImplementationによりステータス情報を取得するプロセスを説明するフローチャートである。
【図４９】ScriptHTTPImplementationパッケージによりウェブページのスクリプトからステータス情報を取得するプロセスを説明するフローチャートである。
【図５０】ScriptHTTPODBCパッケージのクラス図を示す。
【図５１】導出されたCabsScriptProcessのクラスにより装置のウェブページのジャバスクリプトを処理する状態図を示す。
【図５２】CabsScriptProcessの２つの導出されたクラスにより使用されるサンプルデータ構造を示す。
【図５３】ジャバスクリプトを含む装置のウェブページを導出されたCabsScriptProcessのクラスがどのように処理するかを示す図である。
【図５４】装置のウェブページから情報を抽出するために、CabsScriptProcessの導出されたクラスのプロセスを示す図である。
【図５５Ａ】ウェブページから情報を抽出するために使用される構造SInfoStructureの構成メンバを示す図である。
【図５５Ｂ】図５５Aの構造SInfoStructureの構成メンバのサンプル値を示す図である。
【符号の説明】
【０１６７】
２４ デジタルコピー／プリンター
２７ オフィス機器
２８ ファクシミリ
３２ プリンター
５０Ａ ファイヤーウォール
５０Ｂ ファイヤーウォール
５０Ｃ ファイヤーウォール
１６６ 多ポートネットワークI/F
１７２ IFコントローラ
１７４ 操作パネル
１７６ 記憶I/F
１７８ フラッシュメモリ
１８４ オプションI/F
１８７ クロック／タイマー
１７１ ローカル接続
１８８ オプショナルユニットインターフェイス
１９０ フューザ
１９２ プリンター／イメージャ
１９４ スキャナー
１９６ ペーパーフィードコントローラ
１９８ 大容量トレイ部
２００ デュプレクサ
２０２ ソータ
【技術分野】
【０００１】
本発明はネットワークに接続された装置の監視に関する。特に、複数のプロトコルを用いてネットワークに接続された装置を遠隔監視する方法、システム、コンピュータプログラムおよびその関連製品に関する。
【背景技術】
【０００２】
広く知られているように、コンピュータシステムにはハードウェアとソフトウェアが含まれる。ソフトウェアはコンピュータシステムを構成するハードウェア部品を動作させ管理するために作られた命令のリストを含んでいる。一般に、コンピュータシステムは相互にインターフェイスする様々なハードウェア部品や装置を含んでいる。コンピュータシステムにはスタンドアロン型やネットワーク接続型等がある。ネットワークタイプのコンピュータシステムでは、複数の装置各々がネットワークに接続されており、そのネットワークを介して個々の装置間で通信が行われる。
【０００３】
さらに、ハードウェア装置が協働的に機能するように、ハードウェア装置間の通信を可能とするために、ハードウェア装置を動作させるソフトウェアが構成されていなければならない。さらに、そのような通信を支援するため、ハードウェア装置を監視し、指定されたハードウェア装置各々の状態を監視し、各ハードウェア装置が効率的に機能していることを保証することが望ましい。
【０００４】
本特許出願に関し、複数の個別の装置またはハードウェア装置を制御、設定又は監視するハードウェア装置を監視装置と呼び、監視装置により制御、設定又は監視されているハードウェア装置を「被監視装置」と呼ぶ。
【０００５】
ネットワーク上のハードウェア装置に関し、これらの装置は、メンテナンス、使用、その他の目的のために監視されることが望ましい。しかし、ハードウェア装置とインターフェイスに関する製造者の違いを考慮すると、監視装置がネットワークに接続された他のいろいろな装置と通信することは困難かもしれない。このような不利益により、ネットワーク管理者は、そのネットワークに接続された装置の性能（パフォーマンス）と効率についての重要な情報を取得することが妨げられる傾向がある。
【０００６】
シンプルネットワークマネージメントプロトコル（SNMP）は、今日、データ通信ネットワーク上の装置、電気通信システム、その他のグローバルに到達可能な装置を監視および管理するためのデファクトスタンダードである。実際には、コンピュータ及び関連装置を取り扱うすべての組織は、ローカルエリアネットワークやワイドエリアネットワークを通じてそのような各装置を集中的に監視、診断、設定できることを期待している。SNMPはこのようなやりとり（インターラクション）を実現するプロトコルである。
【０００７】
装置がSNMPリクエストに応答するために、SNMPリクエストを正しく解釈し、そのリクエストにより要求されたアクションを実行し、SNMPリプライを生成することができるようにするソフトウェアを装置に備えることが望ましい。SNMPエージェントソフトウェアは、一般的にネットワークの構成要素（エンティティ）に備わるサブシステムソフトウェアモジュールである。
【０００８】
システムにより使用されるオブジェクトの集まりは、一般に管理情報ベース（MIB）と呼ばれる。MIBは装置の監視に関する情報を有するデータベースでもある。MIBの例としては、二、三例を挙げると、イーサネット（登録商標）インターフェイスにフォーカスしたイーサネット（登録商標）MIB、802.1Dブリッジ管理用のオブジェクトを定義するブリッジMIB等がある。
【０００９】
装置の監視にSNMPを使用することは困難である。なぜなら、有効なキーが無ければ解読困難な値がプライベートMIBに含まれているからである。自社のネットワークに接続されたいろいろな装置を監視するためにSNMPを使用している会社は、その会社の独占情報として維持されるユニークな識別子／キーを生成する。通例、結果は二値または整数の値として表示される。このように、SNMPを用いても、監視されている装置（被監視装置）から受信した結果は、被監視装置の状態をユーザが理解可能な形でユーザに提供することはできない。
【００１０】
さらに、SNMPを用いても、有効なキーなしに被監視装置についての詳細な情報を取得し、又はプライベートMIBにアクセスして、バイナリまたは整数値として取得した結果を解読することは困難である。また、与えられたプロトコル（例えば、SNMPまたはHTTP/HTML）は、時間切れ（タイムアウト）やパケット喪失等のいろいろな理由でうまく機能しないこともある。また、複数のプロトコルを用いて与えられた装置から抽出した情報は、各プロトコルでダブっているかもしれない。従って、このような状況において装置からのデータ抽出をうまく管理しないと、プロトコルによっては他のプロトコルよりも多くのリソースを必要とするものもあるので、時間とメモリの効率が悪くなる。更に、或るプロトコルを用いて情報抽出をすれば、他のプロトコルを用いるよりも少ない処理量と費用で情報を抽出することができるかもしれない。さらにまた、或るプロトコルを用いて取得した情報は、他のプロトコルを用いて取得した情報よりも監視装置にとって有用であるかもしれない。
【００１１】
本発明は以下の文献で参照及び説明される様々な技術を利用してもよい。列挙される文献各々の内容全体は本願のリファレンスに組み入れられる。
【非特許文献１】Goldfart,C.,The SGML Handbook,Clarendon Press(1990)
【非特許文献２】Castro,E.,HTML for the World Wide Web,Peachpit Press,Berkeley(1996)
【非特許文献３】Megginson,D.,Structuring XML Documents,Prentice Hall,NJ(1998)
【発明の開示】
【発明が解決しようとする課題】
【００１２】
本発明の課題である上記問題の解決は、ネットワークに接続された装置を監視可能とする本発明のシステムと方法によりなされる。以下、ネットワークに通信可能に接続された個々の装置の間で装置を監視する方法が説明される。
【課題を解決するための手段】
【００１３】
該方法はハードウェアアクセスモジュールを介して第１のデータベースにアクセスするステップを含み、前記第１のデータベースは複数の通信プロトコルをサポートするように構成されている。第１のデータベースには、被監視装置の製造者やモデル情報等、様々な情報を取得するための、複数の通信プロトコルにより使用される情報が格納されている。通信プロトコルは複数の通信プロトコルから選択され、選択された通信プロトコルは被監視装置から状態情報（ステータス情報）を受信するように機能する。該方法は、前記第１のデータベースから選択された通信プロトコルと情報を用いて前記被監視装置にアクセスするステップと、前記アクセスした装置からステータス情報を受信するステップと、前記受信したステータス情報を第２のデータベース（DeviceODBC）に格納するステップとを有する。
【発明を実施するための最良の形態】
【００１４】
他の実施形態において、本発明はネットワークに通信可能に接続された個々の装置の間で装置を監視する方法を提供する。複数の通信プロトコルは被監視装置から情報を検索するために使用される。例えば、SNMPプロトコルが最初に被監視装置にアクセスするために選択され、SNMPプロトコルを用いて効率的に読み出せるように構成された装置情報が取得される。その後、前記装置が追加的なプロトコルをサポートしている場合、SNMPプロトコルを用いて効率的に読み出すことができない情報を取得するために、HTTP及びFTPプロトコルが選択される。プロトコルの選択は、データベースに格納されたサポート情報と併せてプロトコルマネージャにより実行される。
【００１５】
本発明において、例えばLANやWANなどのネットワークに接続された少なくとも１つの装置（被監視装置）の監視が監視システムにより可能となる。前記被監視装置は固有の（ユニークな）IPアドレスを有する。被監視装置に割り当てられたIPアドレスや、前記被監視装置のベンダー／製造者の詳細は、データベースに格納される。ネットワークをスキャンして装置に問い合わせることにより、装置のIPアドレスを取得できる。その方法は既知である。それゆえ、監視される装置のIPアドレスはすでに取得され、データベースに格納されていると仮定する。
【００１６】
本発明は、被監視装置から受け取ったHTML情報から必要な情報をいかに抽出するかを特定する。一旦、被監視装置のウェブページにアクセスすると（すなわち、IPアドレスと特定されたポートを通じて）、被監視装置に対応する特定のウェブページが表示される。そのウェブページの情報はキーと値のペアの形式をとる。例えば、カラープリンターのウェブページにおいて、トナーレベルは「ブラック１００％」のように表示される。HTML/XMLパーサを用いて、ウェブページの情報から必要な情報を読み出すためにそのページを解釈する。HTML／XMLパーサを用いてウェブページから抽出した必要な情報とパラメータ値はサポートデータベースに格納される。
【００１７】
本発明は、ここで説明されるように、監視システムによりサポートされた被監視装置の様々なベンダー及び装置モデルを特定する。被監視装置のいろいろなベンダーはそのベンダー固有のやり方で被監視装置に関する情報を提示するので、本発明により被監視装置のベンダーとモデルを特定して被監視装置の動作状態を判断することができる。
【００１８】
本発明の一態様によると、ネットワークに通信可能に結合された被監視装置に関する情報をHTTP通信プロトコルを用いて検索するための方法、システム及びコンピュータプログラム製品が提供される。これらは、被監視装置のベンダー及びモデル情報を第１メモリから検索し；ベンダー及びモデル情報に基づいて、被監視装置の装置情報を得るためにHTTPプロトコルを用いて被監視装置にアクセスするよう構成された少なくとも１つのアクセス機能を決定し、その少なくとも１つのアクセス機能は、（１）被監視装置に格納されたウェブページ中のタグから装置情報を取得するよう形成された第１アクセス機能及び（２）ウェブページ中のスクリプトから装置情報を取得するよう構築された第２アクセス機能の少なくとも１つを含み；装置情報の取得を試みるために少なくとも１つのアクセス機能の各アクセス機能及びHTTPプロトコルを用いて被監視装置にアクセスし；及びアクセスステップで取得された装置情報をベンダー及びモデル情報と関連付けて第２メモリに格納する。
【００１９】
本発明の他の態様によると、被監視装置に格納されたウェブページのスクリプトから抽象(abstract)クラスインターフェースを用いてステータス情報を抽出するための方法、システム及びコンピュータプログラム製品がもたらされる。抽象クラスインターフェースは、ステータス情報を抽出するのに使用されるサポート情報を取得するよう構築される第１機能と、ウェブページのスクリプトからサポート情報を用いてステータス情報を抽出するよう構築される第２機能とを含む。本方法は：（１）被監視装置のベンダー及びモデル情報を第１メモリから検索するステップ；（２）被監視装置から取得するステータス情報の少なくとも１つのタイプをベンダー及びモデル情報に基づいて判定するステップ；（３）抽象クラスインターフェースの第１関数を用いて、ベンダー及びモデル情報並びにウェブページに基づいて、サポート情報を取得するステップ；（４）HTTPプロトコル、取得したサポート情報及び抽象クラスインターフェースの第２機能を利用して被監視装置にアクセスし、ウェブページのスクリプトから少なくとも１つのタイプのステータス情報を取得するステップ；及び（５）アクセスステップで取得したステータス情報をベンダー及びモデル情報に関連付けて第２メモリに格納するステップを有する。
【００２０】
本発明の他の形態によると、ネットワークに通信可能に接続された被監視装置に関連するステータス情報をHTTP通信プロトコルを用いて検索するための方法、システム及びコンピュータプログラム製品がもたらされる。本方法は、被監視装置のベンダー及びモデル情報を第１メモリから検索するステップ；ベンダー及びモデル情報に基づいて少なくとも１つの手段識別子を検索するステップであって、手段識別子の各々は、ステータス情報を取得するためにHTTPプロトコルを用いて被監視装置にアクセスするように構築された対応するアクセス機能を識別し、少なくとも１つの手段識別子は、（１）被監視装置に格納されたウェブページ中のタグから装置情報を取得するよう形成された第１アクセス機能及び（２）ウェブページ中のスクリプトから装置情報を取得するよう構築された第２アクセス機能の少なくとも１つを確認するところのステップ；少なくとも１つの手段識別子の手段識別子を選択するステップ；ベンダー及びモデル情報並びに選択された手段識別子に基づいて、手段識別子に対応するアクセス機能を利用して、ウェブページからステータス情報を取得するのに使用されるパラメータ値を第１メモリから検索するステップ；手段識別子に対応するアクセス機能、パラメータ値及びHTTPプロトコルを用いて被監視装置にアクセスし、ステータス情報の取得を試みるステップ；及びアクセスステップで取得したステータス情報をベンダー及びモデル情報に関連付けて第２メモリに格納するステップを有する。
【００２１】
本発明の他の形態によると、ネットワークに通信可能に接続された被監視装置に格納されたウェブページのスクリプトからステータス情報をHTTP通信プロトコルを用いて検索するための方法、システム及びコンピュータプログラム製品がもたらされる。本方法は、（１）ベンダー及びモデル情報に基づいて、ウェブページのスクリプトからステータス情報を抽出するのに使用される少なくとも１つのパラメータストリング（文字列）及びウェブページの身元を取得するステップ；（２）ウェブページの身元及びHTTPプロトコルを用いてウェブページにアクセスし、スクリプト中のウェブページのラインを取得するステップ；（３）ウェブページの取得したラインを分析し、少なくとも１つのパラメータストリングのパラメータストリングが取得したライン中に発見されるか否かを確認するステップ；（４）パラメータストリングが取得したライン中に見出されなかったことが分析ステップで確認された場合に、パラメータストリングが発見されるまで、アクセス及び分析のステップが反復されるステップ；（５）パラメータストリングが取得したライン中に発見されたことが分析ステップで確認された場合に、少なくとも１つのパラメータストリング中の全てのパラメータストリングが発見されているか否かを確認するステップ；（６）少なくとも１つのパラメータストリング中の全てのパラメータストリングは発見されていないことが確認ステップで確認された場合に、少なくとも１つのパラメータストリング中の全てのパラメータストリングが発見されるまで、アクセス、分析、反復及び確認のステップを反復するステップ；及び（７）スクリプト中で全てのパラメータストリングが発見されたことが確認ステップで確認された場合に、最後に発見されたパラメータストリングの場所に基づいてウェブページからステータス情報を抽出するステップ；を有する。
【００２２】
本願は以下の米国特許出願に関連する。
【００２３】
１．西暦２０００年５月１７日付けで出願された“Method and System of Remote Diagnostic,Control,and Information Collection using a Dynamic Linked Library of Multiple Formats and Multiple Protocols with Intelligent Formatter”と題する米国特許出願第０９／４５３，９３７号；
２．西暦２００１年１月９日付けで出願された“Method and System of Remote Support of Device Using Email”と題する米国特許出願第０９／７５６，１２０号；
３．西暦２００１年２月１４日付けで出願された“Method and System of Remote Diagnostic Control,and Information Collection using a Dynamic Linked Library of Multiple Formats and Multiple Protocols with Three-Level Formatting”と題する米国特許出願第０９／７８２，０６４号；
４．西暦２００１年８月６日付けで出願された“Universal Controller in The Wireless Networked Environment”と題する米国特許出願第０９／９２１，７０７号；
５．西暦２００１年９月１７日付けで出願された“Method and System of Remote Support of Device Using Email Through Data Transfer Module”と題する米国特許出願第０９／９５３，３５８号；
６．西暦２００１年９月１７日付けで出願された“Method and System for Remote Support of Device using Email for Sending Information Related to a Monitored Device”と題する米国特許出願第０９／９５３，３５９号；
７．西暦２００１年１０月１５日付けで出願された“Method and System for Remote Support of Device Using Email Based Upon Pop3 With Decryption Capability Through Virtual Function”と題する米国特許出願第０９／９７５，９３５号；
８．西暦２００２年２月１１日付けで出願された“Method and Apparatus Utilizing Communication Means Hierarchy to Configure or Monitor an Interface Device”と題する米国特許出願第１０／０６８，８６１号；
９．西暦２００２年５月１３日付けで出願された“Verification Scheme for Email Message Containing Information About Remotely Monitored Devices”と題する米国特許出願第１０／１４２，９８９号；
１０．西暦２００２年５月１３日付けで出願された“Method for Scrambling Information about Network Devices That is Placed in Email Message”と題する米国特許出願第１０／１４２，９９２号；
１１．西暦２００２年５月３１日付けで出願された“Method and Apparatus for Modifying Remote Devices Monitored by a Monitoring System”と題する米国特許出願第１０／１５７，９０３号；
１２．西暦２００２年６月５日付けで出願された“Method and System to Use HTTP and Html/Xml for Monitoring the Devices”と題する米国特許出願第１０／１６２，４０２号；
１３．西暦２００２年６月１３日付けで出願された“Method and System of Remote Position Reporting Device”と題する米国特許出願第１０／１６７，４９７号−継続出願第０９／５７５，７０２号−（米国特許第６，４２１，６０８号）；
１４．西暦２００２年８月２２日付けで出願された“Method and System for Monitoring Network Connected Devices with Multiple Protocols”と題する米国特許出願第１０／２２５，２９０号；
１５．西暦２００２年１２月２６日付けで出願された“Method and Accessing Information from Database to be used to Obtain Status Information from the Web Pages of Remotely Monitored Devices”と題する米国特許出願第１０／３２８，００３号；
１６．西暦２００２年１２月２６日付けで出願された“Method of using Internal Structure to Store Database Information for Multiple Vendor and Model Support for Remotely Monitored Devices”と題する米国特許出願第１０／３２８，００８号；
１７．西暦２００２年１２月２６日付けで出願された“Method of using Vectors of Structures for Extracting Information from the Web Pages of Remotely Monitored Devices”と題する米国特許出願第１０／３２８，０２６号；
１８．西暦２００３年２月２６日付けで出願された“Method and System for Monitoring Network Connected Devices with Multiple Protocols”と題する米国特許出願第１０／３７２，９３９号；
１９．西暦２００３年６月１３日付けで出願された“Method for Efficiently Storing Information used to Extract Status Information from a Device Coupled to a Network in a Multi-Protocol Remote Monitoring System”と題する米国特許出願第１０／４６０，１５０号；
２０．西暦２００３年６月１３日付けで出願された“Method for Efficiently Extracting Status Information Related to a Device Coupled to a Network in a Multi-Protocol Remote Monitoring System”と題する米国特許出願第１０／４６０，１５１号；
２１．西暦２００３年６月１３日付けで出願された“Method for Parsing an Information String to Extract Requested Information Related to a Device Coupled to a Network in a Multi-Protocol Remote Monitoring System”と題する米国特許出願第１０／４６０，４０４号；
２２．西暦２００３年６月１３日付けで出願された“Method and System for Extracting Vendor and Model Information in a Multi-Protocol Remote Monitoring System”と題する米国特許出願第１０／４６０，４０８号；
２３．西暦２００３年９月２６日付けで出願された“Method and System for Extracting Information from Networked Devices in a Multi-Protocol Remote Monitoring System”と題する米国特許出願第１０／６７０，５０５号；
２４．西暦２００３年９月２６日付けで出願された“Method and System for Supporting Multiple Protocols Used to Monitor Networked Deices in a Remote Monitoring System”と題する米国特許出願第１０／６７０，６０４号；
２５．西暦２００４年１月２７日付けで出願された“Method and System for Determining the Type of Status Information to Extract from Networked Devices in a Multi-Protocol Remote Monitoring System”と題する米国特許出願第１０／７６７，４６７号；
２６．西暦２００４年１月２７日付けで出願された“Method and System for Managing Protocols Used to Obtain Status Information from a Network Device”と題する米国特許出願第１０／７６４，５２７号；
２７．西暦２００４年１月２７日付けで出願された“Method and System for Managing Vendor and Model Information in a Multi-Protocol Remote Monitoring System”と題する米国特許出願第１０／７６４，５６９号；
２８．西暦２００４年１月２７日付けで出願された“Method and System for Initializing Protocol Information Used to Extract Status Information from Networked Devices”と題する米国特許出願第１０／７６４，５８２号；
２９．西暦２００４年８月２７日付けで出願された米国特許出願第１０／９２７，１５８号；
３０．西暦２００４年８月２７日付けで出願された米国特許出願第１０／９２７，２５７号；
３１．西暦２００４年８月２７日付けで出願された米国特許出願第１０／９２７，２８３号；
３２．西暦２００５年１月１１日付けで出願された米国特許出願第１０／０３２，０３９号；
３３．西暦２００５年１月１１日付けで出願された米国特許出願第１０／０３２，０１６号；
３４．西暦２００５年１月１１日付けで出願された米国特許出願第１０／０３２，０６３号；
３５．西暦２００５年１月１１日付けで出願された米国特許出願第１０／０３２，００８号；
３６．西暦２００５年１月１１日付けで出願された米国特許出願第１０／０３２，１９２号；
３７．本願基礎出願と共に出願された“Method and System for Use of Abstract Classes for Script Implementation of HTTP to Obtain Information from Devices”と題する出願−代理人管理番号２７１２０５ＵＳ−（ＲＳＩＤ １−４６１）；
３８．本願基礎出願と共に出願された“Database for Multiple Implementation of HTTP to Obtain Information from Devices”と題する出願−代理人管理番号２７１２０３ＵＳ−（ＲＳＩＤ １−４６２）；
３９．本願基礎出願と共に出願された“Method and System for Script Implementation of HTTP to Obtain Information from Remote Devices”と題する出願−代理人管理番号２７１２０７ＵＳ−（ＲＳＩＤ １−４６０）。
【００２４】
上記の米国特許及び特許出願各々の開示内容全体は本願のリファレンスに組み入れられる。
【００２５】
添付した図面を参照して以下の詳細な説明を読めば、本発明及びその結果得られる多くの利点をよりよく理解し、獲得することができる。
【実施例１】
【００２６】
図１は、いろいろな装置と、その装置の動作を監視、診断及び制御するコンピュータとを示す概略図である。具体的に、図１は、コンピュータワークステーション１７、１８、２０および２２に接続されたローカルエリアネットワーク（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）で代替することができる。ディスク１８２は、ハードディスクドライブ、光ディスクドライブ、および／またはフロッピー（登録商標）ディスクドライブである。接続１８０を介して付加的記憶装置をデジタルコピー／プリンター２４に接続してもよい。フラッシュメモリ１７８は、デジタルコピー／プリンター２４の製品寿命にわたって頻繁には変化しないパラメータを表す準静的状態(semi-static state)データを格納するために使用する。このようなパラメータには、例えば、デジタルコピー／プリンターのオプションや設定が含まれる。オプションインターフェイス１８４により、外部インターフェイス等の付加的ハードウェアをデジタルコピー／プリンター２４に接続することができる。クロック／タイマー１８７を用いて時間と日付を常に把握したり、経過時間を測定したりすることができる。
【００４２】
図３は、デジタルコピー／プリンター２４を構成するいろいろなセクションも示している。参照番号２０２はソータを指し、デジタルコピー／プリンター２４の出力をソートするために使用するセンサーおよびアクチュエータを含んでいる。デュプレクサ２００によりデュプレックス動作を実行することができる。デュプレクサ２００は従来のセンサーとアクチュエータを含む。大容量トレイユニット１９８が設けられ、多量の用紙を用紙トレイに保持することができる。デュプレクサ２００と同様に、トレイユニット１９８も従来のセンサーとアクチュエータを含む。
【００４３】
給紙コントローラ１９６を用いて、デジタル画像形成装置の給紙動作を制御することができる。スキャナー１９４を用いて画像をスキャンしてデジタル画像形成装置に取り込むことができる。スキャナー１９４は、光源、ミラー等の従来のスキャンエレメントを含んでいる。また、ホームポジションセンサー等のスキャナーセンサーを用い、スキャナーがホームポジションにいるかどうか判断する。また、ランプサーミスターを用い、スキャンランプが正しく動作することを保証する。プリンター／イメージャ１９２は、デジタル画像形成装置の出力を印刷する。従来のレーザ印刷メカニズム、トナーセンサー、及び画像濃度センサーを有している。フューザ１９０は、高温ローラを用いてトナーを用紙上に溶かす。エグジットセンサと、フューザ１９０がオーバーヒートしないことを保証するサーミスターと、オイルセンサーとを含む。また、オプショナルユニットインターフェイス１８８があり、デジタル画像形成装置の任意的構成要素への接続に使用される。任意的構成要素とは、例えば、自動文書フィーダ、異なるタイプのソータ／コレータ、その他デジタル画像形成装置に付加できる構成要素である。他のエレメントには、その装置の位置を特定することができるGPSなどが含まれる。
【００４４】
図４は複数ポートネットワークインターフェイス１６６の詳細を示す図である。デジタル画像形成装置は、セルラインターフェース２２７、無線インターフェイス２２８又は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）を通じて送信することができる監視システムの機能を持たせることができる。ゼロックスDocuPrinter4025及びHPLaserJet9000は双方とも電子メールを送信できる。
【００７２】
監視ステーション９０２はSMTPを介して電子メールでステータス情報を遠隔地に送信できる。図９に示されるように、監視ステーション９０２はSMTPサーバ９２６を介して電子メールでステータス情報を遠隔地に又は遠隔ネットワークに送信する。遠隔地には電子メールを受信するためのPOP3サーバ９３０が備わる。ワークステーション９４０はPOP3サーバ９０３と通信し、ステータス情報を含む電子メールを検索する。ワークステーション９４０はステータス情報をデータベース９６０に格納してもよい。電子メールにより、ステータス情報が遠隔地に容易に伝送されるようにできる。ステータス情報は電子メールメッセージ中に又は添付物（アタッチメント）中にあってもよい。ステータス情報はセキュアな（安全な）データ伝送を行うためにエンコード（暗号化）されてもよい。FTP、HTTPのような他のプロトコル又はウェブサービスを利用して情報を遠隔地に転送してもよい。
【００７３】
監視システムのアーキテクチャ
図１０は、本発明の一実施形態による、リモート装置に関連したデータの監視に使用される監視システム１０００（および、関連するインターフェイス機能）を示す。監視システム１０００は、ソフトウェアモジュール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モジュール１００６は、多数のモジュールにより使用されるクラスを含むCommon（コモン）モジュール１１０１、及び他のサブモジュール（DeviceODCBモジュール１１０４、Device（デバイス）モジュール１１１０、HWaccess（HWアクセス）モジュール１１１６）を管理するMonitorManager（モニターマネージャ）モジュール１１０２とを含み、図１０に示したようにインターフェイス機能により規定されたタスクを完了する。具体的に、DeviceODBC（デバイスODBC）モジュール１１０４は、標準インターフェイスを通じて外部装置情報にアクセスするために、アクセスされる。HWaccessモジュール１１１６は、複数の通信プロトコル（例えば、HTTP、SNMP、FTP）のうちから選択された通信プロトコルを用いて、被監視装置からベンダー、モデル、一意なID、ステータス情報を取得する。各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)
この関数は装置のステータスを取得する。この関数は、正常に動作したときは真を返し、そうでないときは空のマップとともに偽を返す。
【０１０２】
図１３は、図１０に示した、Monitorモジュール１００６の呼び出しシーケンスを説明するinit()関数のシーケンスを示す。MonitorManager１１０２は、HWaccessモジュール１１１６を初期化して初期化関数を開始する。そして、MonitorManager１１０２は被監視装置に関する情報を取得し、被監視装置に割り当てられたIPアドレスを用いてその被監視装置と通信する。MonitorManager１１０２は、DeviceODBC１１０４にアクセスし被監視装置の設定情報を取得する。MonitorManager１１０２に返される設定情報は、例えば、被監視装置のIPアドレス、各プロトコルのパラメータ名とそれに関連する値、被監視装置のベンダー／製造者及びモデル情報が含む。一旦IPアドレスを取得すると、MonitorManager１１０２は、各プロトコルについてそのIPアドレス、パラメータ名、それに関連する値を設定し、Deviceモジュール１１１０の装置についてソフトウェアオブジェクトを生成する。デバイスソフトウェアオブジェクトが正常に生成されると、HWaccessモジュール１１１６を用いて、被監視装置からベンダー、モデル、一意的IDを取得し、生成されたデバイスソフトウェアオブジェクトに格納する。
【０１０３】
一旦デバイスソフトウェアオブジェクトからベンダー、モデル情報、一意的IDを取得すると、MonitorManager１１０２は被監視装置から受信した情報でデータベース（例えば、DeviceODBC１１０４）を更新する。図１２には１つの装置を示しているが、obtainConfigからupdateConfigまでのステップを繰り返し、外部ソースで指示された装置すべてをカバーする。また、図２１，３１，３２，３３に示した各プロトコルが初期化される。図２１，３１，３２，３３に示したODBCに対応するデータベーステーブルにアクセスし、アクセスされた装置からのステータス情報の収集が速くなるように、アクセスされた装置の必要情報を外部記憶から内部データ構造に転送する。
【０１０４】
図１３は、図１１に示した、MonitorManagerモジュール１１０２による被監視装置のステータスを決定するためのステータス監視機能のシーケンスを示す。DeviceからHWaccessにobtainStatus関数が発行されると、CHWaccessクラスは、以下に説明するように、異なるパラメータを用いて、抽象型クラスを通じて図２１，３１，３２，３３に示した各プロトコルに対してobtainStatus関数コールを順次発行する。各プロトコルモジュールは被監視装置からステータス情報を抽出するのに必要な情報をすでにキャッシュしている。その被監視装置は、図１２に示した初期化時にすでにアクセスされている。それゆえ、ステータス情報は、ステータス監視の際に外部ソースにアクセスすることなく、被監視装置から素早く抽出することができる。このプロセスは、図１４に示したベクトルに格納されたすべての被監視装置について繰り返される。
【０１０５】
図１４を参照して、ベクトル１５００が示されており、図１２と１３に示されるように、図１１のデバイスモジュール１１１０内で生成され、MonitorManager１１０２により使用される装置を参照している。MonitorManager１１０２は、例えば、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部分に含まれるデータ構造を示し、図１８を参照して上で説明したデータ構造に類似したデータ構造を含んでいる。図１８−２０に示されるEnumCorrespondenceデータ構造は、そのサポートデータベースにおける全てのプロトコルについてそのデータベース構造で共用され、図１７に示されるのと同じデータ構造である。
【０１１２】
図１９では、被監視装置から情報を取得するために使用するHTTPプロトコルについて２組のデータ構造が示されている。一方は、「タグ」（Tag）のプレフィックス（接頭辞）を用いてラベルが付され、被監視装置のウェブページ中のタグにある情報を抽出するためのサポート情報を用意する。もう一方のデータ行動は、「スクリプト」（Script）のプレフィックスを用いてラベルが付され、被監視装置のウェブページ中のジャバ(Java（登録商標）)スクリプトに含まれる情報を抽出するためのサポート情報を用意する。
【０１１３】
図２０は被監視装置のFTPファイルから情報を抽出するのに使用されるサポート情報を含むデータ構造を示す。
【０１１４】
本発明で使用するenumタイプの例は、以下に定義するinfoTypeである。（enumタイプは単なる一例であり、本発明を限定するものとして解釈してはならない。）
infoType (typedef int infoType)
このセクションではinfoType(int)の定義を説明する。データタイプには０から９９までの範囲の値が割り当てられている。１００から４９９までの値の範囲が装置情報に割り当てられている。５００から１９９９の値の範囲が標準MIBパラメータを含む共通パラメータに割り当てられている。２０００から３９９９の範囲がリコー特有の情報に割り当てられている。４０００から４９９９の範囲がゼロックスに割り当てられている。５０００から５９９９の範囲がレックスマーク(Lexmark)に割り当てられている。６０００から６９９９までの範囲がHPに割り当てられている。値は以下のように決められる：
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).
HWaccessモジュールの抽象型クラス
図２１は、HWaccessパッケージを示すパッケージ図である。このパッケージは、監視されるネットワーク装置を特定し、いろいろなネットワークプロトコル（例えば、SNMP、HTTP、FTP）を用いてそのネットワーク装置に関する情報を取得する役割を担う。このパッケージは、パッケージHTTP２３０２、SNMP２３０４、FTP２３０６、及びクラスCHWaccess２３００、CAbsProtocol２３０８、CrecordSet２３１０を含む。パッケージHTTP２３０２、SNMP２３０４、FTP２３０６は、ネットワーク装置にアクセスしそれらから情報を取得するためのネットワークプロトコルを実装する。例えば、HTTPパッケージ２３０２は、ネットワーク装置のウェブページにアクセスしそのウェブページから情報を取得するためのHTTPプロトコルを実装する。クラスCHWaccess２３００はすべてのプロトコルパッケージを管理し、ネットワーク装置から必要な情報を取得する。クラスCAbsProtocol２３０８は如何なるプロトコルをも表す抽象型クラスである。このクラスは、CHWaccess２３００及びプロトコルパッケージ間のインターフェイスを提供する。クラスCAbsProtocol２３０８は、図２１に示した一組の共通関数をCHWaccess２３００に提供する。すべてのプロトコルは、CHWaccess２３００に必要な情報を提供する。後に出てくる図面で説明するように、CAbsProtocol２３０８から導かれるクラスは、適当なプロトコルについて各関数のメソッドを提供する。クラスCRecordSet２３１０は、マイクロソフトファウンデーションクラスのクラスである。このクラスにより用意される各プロトコルパッケージは、データベースにアクセスして、ネットワーク装置のどのベンダーのどのモデルがサポートされ且つそのネットワーク装置からどんな情報を取得するかという情報を取得することができる。CabsProtcolのクラス仕様についてはアペンディックス１を参照されたい。
【０１１６】
図２１に示されるようなプロトコルパッケージ（HTTP２３０２,SNMP２３０４,FTP２３０６）の各々は或るクラスを含み、そのクラスは装置から情報を取得するためのネットワーク装置へのアクセスを管理する。クラスは抽象クラスCabsProtocol２３０８から導出され、そのクラスは、ネットワーク装置から情報にアクセスするプロトコルを実行する方法を用意する。抽象クラスはインターフェイス機能だけを提供し、如何なるプロセスも実行しない。抽象クラスから導出されたクラスは、インターフェイス機能のプロセスを実行する方法を提供する。抽象クラスの導出されるクラスは多数存在し、導出された様々なクラスはインターフェイス機能のプロセスを様々に実行できる。例えばCAbsProtocolのインターフェイス機能はObtainStatus()である。図３１に示される導出されたクラスCSNMPProtocolはネットワーク装置のステータス情報をSNMPを用いて取得する方法を提供する関数ObtainStatus()を含み、図３３に示される導出されたクラスCHTTPProtocolはネットワーク装置のステータス情報をHTTPを用いて取得する方法を提供する関数obtainStatus()を含む。Hwaccessパッケージの設計（デザイン）により、CabsProtocolの導出されたクラスを含む新たなパッケージを追加することで、新たなプロトコルがシステムに追加可能であり、そのクラスは新たなプロトコルを用いてネットワーク装置にアクセスする新たなパッケージを管理する。抽象クラスはシステムの将来的な拡張を可能にする。
【０１１７】
図２２は、ネットワーク装置にアクセスしてそれから情報を取得するためのプロトコルをすべて保持する、図２１のHWaccessパッケージで使用されるデータ構造を示している。図２２に示したデータ構造は、CAbsProtocol２３０８へのポインタのベクトル５００である。クラスCHWaccess２３００は、このデータ構造体を含み、使用する。ベクトル５００は、CAbsProtocol２３０８から導き出されたクラスへのポインタを含んでいるが、CHWaccess２３００は、そのベクトルをCAbsProtocol２３０８へのポインタを含むとみなし、仮想ファンクションコールメカニズムによりCAbsProtocol２３０８のインターフェイス関数を呼び出す。CHWaccess２３００は、実際には、CAbsProtocol２３０８の派生クラスのインターフェイス関数を呼び出す。例えば、ベクトルの第１のエントリーのCAbsProtocolへのポインタ５０２は、図３１に示される派生クラスCSNMPProtocolへのポインタであり、ベクトルの第２のエントリーのCAbsProtocolへのポインタ５０４は、図３３に示される派生クラスCHTTPProtocolへのポインタであり、ベクトルの第３のエントリーのCAbsProtocolへのポインタ５０６は、図３２に示される派生クラスCFTPProtocolへのポインタでもよい。そこで、CHWaccess２３００がベクトルのCabsProtocol２３０８のインターフェイス関数を呼び出すとき、実際にはCSNMPProtocol、CHTTPProtocol、CFTPProtocolのインターフェイス関数を呼び出している。ベクトル５００の抽象型クラスCAbsProtocol２３０８を使用することにより、どのプロトコルを使用してもネットワーク装置にアクセスして、そのネットワーク装置から情報を取得することができる。抽象型クラスCAbsProtocol２３０８は、どのプロトコルが使用されているかの詳細を隠蔽する。
【０１１８】
図２３はモニタパッケージのinit()が呼び出された場合のHWaccessパッケージの初期化を行うシーケンス図である。監視される装置から情報へアクセスするために全てのプロトコルオブジェクトが作成及び初期化される。CHWaccessの関数initBegin()の呼出は全てのプロトコルオブジェクト（CAbsProtocolから派生する全て）を作成する。各プロトコルオブジェクトのinitBegin()は、被監視装置のベンダー、モデル及び固有のIDを確認するのに使用されるサポート情報を初期化するために呼び出される。CHWaccessのinitEnd()が呼び出される前に、プロトコルオブジェクト及びCHWaccessの関数が呼び出され、装置にアクセスし、全プロトコルについてその装置のベンダー、モデル及び固有のID情報を取得及び初期化する。CHWaccessのinitEnd()が呼び出される時点までに、各プロトコルオブジェクトは全ての情報（そのプロトコルがサポートする被監視装置のステータス情報を取得するのに必要な情報）を用意する。各プロトコルオブジェクトのinitEnd()は、初期化後に不要なデータ構造全てを削除（クリーンアップ）する。
【０１１９】
図２４はHWaccessパッケージのcanAccessIP()を示すシーケンス図であり、装置が何らかのプロトコルでアクセス可能であるか否かを確認するためのものである。プロトコルオブジェクトの１つがそのIPアドレスに対応する装置にアクセス可能になるまで、CHWaccessは各プロトコルオブジェクトのcanAccessIP()を呼び出す。どのプロトコルオブジェクトも装置にアクセスできなければ、CHWaccessのcanAccessIP()は偽を返し、その装置は将来監視されない。
【０１２０】
図２５Ａ，２５Ｂは２つのシーケンス図を示し、プロトコルオブジェクトから装置の固有のＩＤ、モデル及びベンダーを取得し、ベンダー及びモデル情報と共に他のプロトコルオブジェクトを初期化する２つの異なる筋書き(シナリオ)を示す。装置のベンダー及びモデル情報をプロトコルオブジェクトが一旦取得すると、プロトコルオブジェクトはその装置についてのサポート内容を更新し、その装置からステータス情報を取得できるようにする。他のプロトコルオブジェクトは、その装置についてそれらのサポート内容を更新できるように、その装置からステータス情報を取得できるように、装置のベンダー及びモデル情報についての情報を受信することを要する。CHWaccessのobtainUniqueID(),obtainModel()及びobtainVendor()は図２５A及び２５B双方で呼び出されている。CHWaccessは、装置の固有のID、モデル及びベンダーを取得し且つベンダー及びモデル情報で他のプロトコルオブジェクト全てを初期化するのに必要なプロトコルオブジェクトを同程度に多く使用する。CHWaccessは装置の所与のIPアドレスについてベンダー、モデル及び固有のIDを維持する。図２５Aの或るシナリオでは、CHWaccessは、プロトコルオブジェクトのVendorModelUniqueID()を呼出、そのプロトコルオブジェクトから全ての情報を取得する。そして、CHWaccessは、他のプロトコルオブジェクト全てのinitWithVendorModel()を呼び出すことで、ベンダー及びモデル情報と共に他の全てのプロトコルオブジェクトを初期化する。図２５Bの別のシナリオでは、CHWaccessは、プロトコルオブジェクトのobtainVendorModelUniqueID()を呼び出し、プロトコルオブジェクトからそのベンダーだけを取得する。CHWaccessは別のプロトコルオブジェクトのobtainModel()及びobtainUniqueID()を呼び出し、モデル及び固有のIDを取得する。そしてCHWaccessは、他の全てのプロトコルオブジェクトのinitWithVendorModel()を呼び出すことで、ベンダー及びモデル情報と共に他の全てのプロトコルオブジェクトを初期化する。
【０１２１】
図２６は、図１６のプロトコルパラメータマップ１８００をいかに更新して、どのプロトコルを使用してネットワーク装置からステータス情報を取得するかを説明するフローチャートを示す。図２６のステップを実行し、プロトコルについてネットワーク装置のベンダー名とモデル名を取得する。ステップ３７０２において、プロトコルを用いてネットワーク装置にアクセスできるか検査する。マップ１８００の情報を用いてそのプロトコルをによりネットワーク装置にアクセスする。そのプロトコルを通じてそのネットワーク装置にアクセスできない場合、ステップ３７０４において、プロトコルパラメータマップ１８００からそのプロトコルを削除し、ステップ３７１４において、マップ１８００の更新を終了する。そのネットワーク装置にそのプロトコルを通じてアクセスできるとき、ステップ３７０６において、そのネットワーク装置のベンダーをそのプロトコルを用いて取得できるかどうかチェックする。ベンダーを取得できないとき、ステップ３７０７において、ジェネリック(GENERIC)ベンダーがそのプロトコルでサポートされているかどうかチェックする。プロトコルがジェネリックベンダーをサポートしているとは、プロトコルがその装置のベンダーを取得できないまたはサポートしていないときでさえも、プロトコルがすべての装置に共通のステータス情報（共通ステータス情報）を取得できることを意味する。そのプロトコルによりジェネリックベンダーがサポートされていないとき、ステップ３７０４において、そのプロトコルはプロトコルパラメータマップ１８００から削除され、ステップ３７１４において、マップ１８００の更新が完了する。そのプロトコルがジェネリックベンダーをサポートしているとき、そのプロトコルはプロトコルパラメータマップ１８００に残され、ステップ３７１４において、マップの更新が完了する。ステップ３７０６においてベンダーを取得できる場合、ステップ３７０８において、そのネットワーク装置のベンダーがそのプロトコルでサポートされているかどうかチェックする。ベンダーがそのプロトコルによりサポートされていないとき、ステップ３７０７において、ジェネリックベンダーがそのプロトコルによりサポートされているかどうかチェックする。ステップ３７０７以降のステップのシーケンスは説明済みである。
【０１２２】
ベンダーがそのプロトコルでサポートされているとき、ステップ３７１０において、そのネットワーク装置のモデルがそのプロトコルを用いて取得できるかどうか判断する。モデルを取得できないとき、ステップ３７１１において、ジェネリックモデルがそのプロトコルでサポートされているかどうかをチェックする。プロトコルがジェネリックモデルをサポートしているとは、プロトコルがその装置のモデルを取得できず、またはサポートしていなくても、そのプロトコルがベンダーのすべての装置に共通なステータス情報（特定ベンダーステータス情報）を取得できることを意味する。ジェネリックモデルをプロトコルがサポートしていないとき、ステップ３７０４において、そのプロトコルはプロトコルパラメータマップ１８００から削除され、ステップ３７１４において、マップ１８００の更新が終了する。ジェネリックモデルがプロトコルによりサポートされているとき、そのプロトコルはプロトコルパラメータマップ１８００に残され、ステップ３７１４においてマップの更新を終了する。ステップ３７１０でモデルを取得できるとき、ステップ３７１２において、そのネットワーク装置のモデルがプロトコルによりサポートされているかどうか判断する。そのモデルがプロトコルでサポートされていないとき、ステップ３７１１で、ジェネリックモデルをそのプロトコルがサポートしているかどうかチェックする。ステップ３７１１に続くステップのシーケンスについては説明済みである。そのモデルがプロトコルによりサポートされているとき、そのプロトコルを用いてネットワーク装置のステータス情報を取得でき、ステップ３７１４でプロトコルパラメータマップ１８００の更新は終了する。ベンダーとモデルが取得またはサポートされていないとき、そのプロトコルはプロトコルパラメータマップ１８００から削除され、ステータス情報の取得には使用されない。プロトコルに応じて図２６に示したプロセスにいくつかの変形例（バリエーション）がある。HTTPとFTPはフローチャートの説明通りだが、ベンダーがサポートされているがモデルとジェネリックモデルはサポートされていない場合でさえも、SNMPはサポートされ、ステータス情報を取得するために使用されてもよい。
【０１２３】
上で説明したように、ベンダーとモデルが取得またはサポートされていなくても、SNMPによりステータス情報をネットワーク装置から取得できる。ネットワーク装置がSNMPをサポートし、SNMPによりアクセスできる限り、そのネットワーク装置の管理情報ベース（MIB）から情報を取得することができる。ステップ３７０２において、ネットワーク装置がSNMPを通じてアクセスできないとき、ステップ３７０４で、SNMPプロトコルはプロトコルパラメータマップ１４００から削除される。しかし、そのネットワーク装置にSNMPでアクセスできる場合、ベンダーやモデルが取得及びサポートされているかどうかにかかわらず、SNMPプロトコルはプロトコルパラメータマップ１８００に残される。SNMPをサポートするネットワーク装置はMIBを提供し、リモートシステムはそのネットワーク装置から情報を常に取得可能である。しかし、ネットワーク装置から取得可能な情報のタイプと数は、ベンダーとモデルが取得およびサポートされるかどうかに依存する。ベンダーとモデルが取得され、かつ知られていれば、SNMPによりネットワーク装置からより多くの情報を取得することができる。ベンダーとモデルを取得できなくても、SNMPはすべての装置が提供できる情報は取得可能である。例えば、システムの説明やシステムが動作している時間等は取得可能である。SNMPは次の３つの条件の下でネットワーク装置から情報を取得するために使用できる：（１）ベンダーとモデルがサポートされている；（２）ベンダーはサポートされているが、モデルはサポートされていない；（３）ベンダーもモデルもサポートされていない。HTTPとFTPは、SNMPのような特徴は有していない。SNMPは、すべてのネットワーク装置が従うことができる標準MIBを有しており、情報を取得できるが、ウェブページとFTPファイルは、ベンダーとモデルが異なるネットワーク装置では異なる。ネットワーク装置が情報を取得するために従うウェブページとFTPファイルの標準はない。
【０１２４】
図２７は、すべてのプロトコルを用いてネットワーク装置に関するステータス情報を取得するプロセスを説明するためのフローチャートである。図２５A及び２５Bを参照して説明したようにプロトコルオブジェクトが、それでサポートするネットワーク装置のベンダーとモデルに関する情報で初期化され後、そのプロトコルオブジェクトはネットワーク装置からステータス情報を取得するために使用可能である。そのプロトコルオブジェクトは、図１８，１９及び２０のサポートデータベースからの情報を含むデータ構造を用いて、所与のベンダーとモデルについてステータス情報をいかに取得するかに関する情報を含む。図２２を参照して説明したCAbsProtocol２３０８へのポインタのベクトルを使用して、すべてのプロトコルオブジェクトについてステータス情報を取得する。フローチャートのプロセスは、そのベクトルを一回通る。ステップ３１２２において、CAbsProtocolへのポインタのベクトルからプロトコルオブジェクトを取得する。プロトコルオブジェクトは、ネットワーク装置にアクセスするためのネットワークプロトコル（例えば、SNMP、HTTP、FTP）の１つに対応する。ステップ３１２４において、ベクトルから取得できるプロトコルオブジェクトがあるかどうか検査する。この検査は、ベクトルの終わりに来たかどうか判断することによりなされる。プロトコルオブジェクトがもう取得できなければ、ステップ３１２６において、すべてのプロトコルオブジェクトを用いてネットワーク装置からステータス情報を取得し終わっている。ベクトルから取得したプロトコルオブジェクトがあれば、ステップ３１２８において、そのプロトコルオブジェクトを用いてネットワーク装置のステータス情報を取得する。プロトコルオブジェクトを用いてステータス情報を取得した後、ステップ３１２２に戻り、他のプロトコルオブジェクトを用いてステータス情報をさらに取得する。
【０１２５】
図２８は、様々なプロトコルで取得するステータス情報を維持するために使用するデータ構造を示している。このデータ構造は、そのステータス情報を取得するためにどのプロトコルが使用されたかに関する情報を維持していない。データ構造はマップ724である。マップ７２４に対するキー７２６はinfoTypeである。infoTypeは情報のタイプを表す番号である。マップ７２４に対する値７２８はペアである。ペアはストリングと整数よりなる。ペア中のストリングは、infoTypeに対応するネットワーク装置から取得したステータス情報である。ペア中の整数は、プロトコルから取得したステータス情報の重みまたは優先度である。一例として、infoTypeが７００であり、それがプリンターカートリッジのブラックトナーのレベルを表す場合、そのペアはストリング「７５％」と整数１００００を含むかもしれない。ストリング「７５％」はカートリッジに７５％のトナーが残っていることを示し、整数１００００はそのステータス情報の重みまたは優先度である。CSNMPProtocol２４０２、CHTTPProtocol２５０２、CFTPProtocol２６０２は、ネットワーク装置から取得したステータス情報をマップ７２４に追加する。
【０１２６】
図２９は、図２１のプロトコルパッケージのそれぞれで使用されるパッケージ図を示し、ここでXXXはSNMP、HTTP、またはFTPのいずれかである。抽象クラスCAbsProtocolは、装置から情報を取得するインターフェイス関数を提供するが、その情報を取得するメソッドは提供しない。CAbsProtocolから派生するクラスは、装置から情報を取得する新しいプロトコルを追加しやすくする方法を提供する。CXXXProtocolImp1クラスは、XXXパッケージのインターフェイスであり、そのパッケージ内の他のすべてのクラス／パッケージを管理する。CXXXProtocolImp1はCabsProtocolから派生するので、このクラスは与えられたプロトコルで装置から情報を取得する方法を提供する。XXXaccessパッケージは、その装置にアクセスしてその装置から情報を取得するプロトコルを実装する。XXXODBCパッケージは、サポートデータベースからプロトコルサポート情報を取得する。この情報には、そのプロトコルがサポートするベンダー及びモデルの情報、その装置からベンダー、モデル、及び一意的識別子に関する情報をいかにして取得するかの情報、及びその装置からステータス情報をいかに取得するかの情報が含まれる。図３１，３２は、SNMP及びFTPの場合に具体的にこのパッケージ図を使用したものである。装置からステータス情報を取得するために使用する新しいプロトコルはいずれも、そのパッケージ図のこの構造に従う。そのような新しいプロトコルの１つとしてウェブサービスがある。また、様々なプロトコル実装もパッケージ図のこの構造に従ってよい。
【０１２７】
図３０は、図２１のプロトコルパッケージのそれぞれで使用可能な別のパッケージ図を示し、ここでXXXはSNMP、HTTP、またはFTPのいずれかである。このパッケージ図はどのプロトコルにも適用可能であるが、図３３に示されるようにHTTPプロトコルを例として説明する。このパッケージ構造は、装置から情報を取得する新たなプロトコルの実装を拡張可能にする。情報を取得するためのプロトコルの既存の実装が情報の新しいフォーマット（例えば、HTTPの別の実装を要する図４０及び４２に示したウェブページの例）に対してうまく機能しない場合、この拡張が必要である。図２９に示したように、このパッケージ図により、抽象クラスCAbsProtocolも使用される。CXXXProtocolクラスはCabsProtocolから派生する。CXXXProtocolは、XXXパッケージに対しインターフェイスを提供し、装置から情報を取得する異なる方法に対応するすべてのクラスを管理する。
【０１２８】
クラスCXXXProtocolImp1とCXXXProtocolImp2は、同じプロトコルを用いて情報を取得する異なる方法を使用する。CXXXProtocolImp1クラスは、装置から情報を取得するための実装を提供し、パッケージXXXaccess1及びXXXODBC1を用いる。XXXaccess1パッケージは、その装置にアクセスしてその装置から情報を取得するプロトコルを実装する。XXXODBC1パッケージは、データベースからプロトコルサポート情報を取得する。この情報には、そのプロトコルがサポートするベンダー及びモデル、その装置からベンダー、モデル、及び一意的識別子に関する情報をいかにして取得するかの情報、及びその装置からステータス情報をいかに取得するかの情報が含まれる。CXXXProtocolImp2クラスは、CXXXProtocolImp1と同じプロトコルを用いて装置から情報を取得するための他の実装である。CXXXProtocolImp2は、パッケージXXXaccess2とXXXODBC2を使用する。XXXaccess2パッケージは、その装置にアクセスしてその装置から情報を取得するプロトコルを実装する。XXXODBC2パッケージは、XXXODBC1と同様に、データベースからプロトコルサポート情報を取得する。このパッケージの設計により、プロトコルの新しい実装が可能となる。新しい実装が必要なとき、そのプロトコルを用いて装置にアクセスし、サポートデータベースから情報を取得するために、他の実装クラスがサポートパッケージとともに追加される。本発明の実施形態は、新しい実装の新しい装置とともに、すでにサポートされている装置から情報を取得するための既存の実装でも機能する。
【０１２９】
SNMPとFTPのパッケージ図は、図２９のパッケージ構造に従い、図３１及び３２に示されている。このシステムのHTTPのパッケージ図は、図３０のパッケージ構造に従い、図３３に示されている。
【０１３０】
図３１は、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を使用してデータベースから情報を取得する。
【０１３１】
図３２は、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パッケージの場合のパッケージ図を示し、図３０に示したパッケージ図に基づく。このパッケージは、ウェブページから情報を取得するためのHTTPの２つの実装例を含んでいる。このパッケージは、図２１を参照して上で説明したように、抽象クラスCAbsProtocolを使用する。CHTTPProtocolクラスはCAbsProtocolから派生する。CHTTPProtocolは、HTTPパッケージのためのインターフェイスであり、装置から情報を取得するHTTPの２つの異なる実装例に対応するパッケージを管理する。tagHTTPImplementationパッケージは、装置のウェブページのタグから情報を取得するためのHTTPの実行手段である。tagHTTPImplementationパッケージは、関連する米国特許出願第１１／０３２，０３９の実施例として説明されており、そのパッケージは第２HTTPImplementationと呼ばれる。TagHTTPImplementationパッケージはTagHTTPODBCパッケージを用いて、サポートされる装置及びその装置から情報を如何にして取得するかについてのサポート情報をデータベースから取得する。ScriptHTTPImplementationパッケージは、図４０及び４２に示したような装置のウェブページのジャバスクリプトから情報を取得するためのHTTPの他の実行手段を提供する。ScriptHTTPImplementationパッケージは、ScriptHTTPODBCパッケージを用いて、サポートされる装置及びその装置から情報をいかに取得するかに関するサポート情報をデータベースから取得する。ScriptHTTPIMplementationパッケージによるHTTPの第２の実行手段は、情報がウェブページのジャバスクリプト中に有る場合に、装置から情報を取得する問題を取り扱う。HTTP_HTMLToolは１つのパッケージとして示されているが、それは２つの実装パッケージにより使用されるオブジェクトを含むネームスペースである。ネームスペースを用いることにより、それが含むオブジェクトをHTTPパッケージ内で使用できる。これにより、HTTPのすべてのクラス及びパッケージがネームスペースのオブジェクトを共有することができる。HTTPパッケージは、HTTPが装置に関する情報を取得するためのインターフェイスを提供する抽象クラスCAbsHTTPImplementationを含む。アペンディックス２はCAbsHTTPImplementationのクラス仕様を提供する。CAbsHTTPImplementationから派生したクラスは、その情報を実際に取得する方法を提供する。TagHTTPImplementation及びScriptHTTPIMplementationパッケージは、情報を取得する方法を規定するCAbsHTTPImplementationから派生したクラスを含む。このHTTPパッケージの設計により、将来の拡張が可能である。現在の実行手段が装置のウェブページから情報を取得できなかった場合、或る実行手段とODBCパッケージを追加することにより、新しい実行手段のデザインを追加することができる。
【０１３３】
図３４では、CHTTPProtocolクラスのデータ構造m_ImplementationMapが同じエンティティ内に示される。マップ構造m_ImplementationMapのキーは、CAbsHTTPImplementationクラスへのポインタである。キーは抽象クラスCAbsHTTPImplementationへのポインタであるが、そのポインタは実際にはCAbsHTTPImplementationの派生クラスを指す。図３４は、CAbsHTTPImplementationの２つの派生クラスであるCFirstHTTPImplementationとCSecondHTTPImplementationに対応するマップのサンプルエントリーを示す。マップの値は、キーで指し示された実装クラスが使用されるかどうかを示すブール値である。このマップは、システムがスタートする際、CHTTPProtocolのコンストラクタが呼び出されるときに初期化される。このマップは、情報を取得するHTTPの様々な全ての実現手段で占められ、そのブール値は偽に設定される。どの装置を監視するかを判断するディスカバリープロセス中に（初期化中に）、どの実装が必要かを判断する。装置から情報取得するために或る実行手段が必要な場合、そのブール値は真に設定される。ディスカバリープロセスが完了した後、実行手段に対応するブール値が偽であったならば その実行手段はマップから削除される。
【０１３４】
図３５では、サンプルエントリーと共に、CHTTPProtocolクラスのマップ構造m_VendorModelSupportMapを示す図である。このマップを用いて、被監視装置の特定のベンダー及びモデルの情報を取得するために、HTTPのどの実行手段を使用するかを判断する。そのマップのキーは、ベンダー及びモデル名の連結を含むストリングである。そのキーに対応する値は、抽象クラスCAbsHTTPImplementationに対するポインタのベクトルである。ポインターは、実際にはCAbsHTTPImplementationの派生クラスの１つを指し示す。ベクトルは、或るベンダ及びモデルに関するステータス情報を取得するためのHTTPの全ての実行手段を含む。マップm_VendorModelSupportMapは、システムのディスカバリープロセスの間に（初期化の際）占められる。
【０１３５】
図３６Ａ，３６Ｂ，３６Ｃのシーケンス図はinitWithVendor(),initWithModel()及びinitWithVendorModel()のCHTTPProtocolの関数のプロセスを示す。これらの関数はHTTPプロトコルの実行手段全てを初期化し、特定のベンダー、特定のモデル又は特定のベンダー及びモデルに関する装置のステータス（状態）を取得するために、各実行手段が情報を有するようにする。これらの関数は、SNMP又はFTPのような別のプロトコルがその装置のベンダー及び／又はモデルを発見したときはいつでも及びHTTPプロトコルオブジェクトが装置についてのHTTPサポート内容の存否を確認するためにベンダー及び／又はモデルで初期化されることを要するときはいつでも呼び出される。
【０１３６】
図３７のフローチャートはCHTTPProtocolの関数obtainStatus()のプロセスを示し、マップm_VendorModelSupportMapを利用する。このプロセスは、関数への入力がステータス情報を取得するのに適切な情報を含んでいるか否かを確認する。含んでなければこの関数は偽を返す。関数の入力が適切な情報を含んでいたならば、このプロセスはベンダー及びモデルに関するHTTPサポートの有無を確認する。無ければ関数は偽を返す。ベンダー及びモデルがHTTPでサポートされていたならば、そのベンダー及びモデルをサポートするHTTPの全ての実行手段は、装置のウェブページからステータス情報を取得する。HTTPの全ての実行手段が装置から何らかのステータス情報を得ることに失敗すると、その関数は偽を返す。そうでなければ関数は真を返す。
【０１３７】
図３８は、TagHTTPImplementationパッケージに関するパッケージ図である。このパッケージは、装置のウェブページのタグから情報を取得するためにHTTPを実装する。クラスCTagHTTPImplementationは、このパッケージのインターフェイスであり、装置のウェブページから情報を取得するメソッドを実装するように他のクラス及びパッケージを管理する。CTagHTTPImplementationは、CAbsHTTPImplementationから派生したクラスである。TagHTTPODBCパッケージとHTTP_HTMLToolパッケージは、図３３を参照しながら既に説明された。クラスCTagHTMLProcessorは、装置のウェブページを処理して、所望の情報を取得する。このクラスは、特定のフォーマットのウェブページのテキストを処理して所望の情報を取得する方法を含む。より具体的には、このクラスはウェブページを処理し、そのウェブページでは、情報を発見するためのキーワードが複数の箇所に登場する。
【０１３８】
図３９は、CTagHTTPImplementationのマップ構造m_VendorModelWebInfoMapを示す図である。このマップ構造は、装置のウェブページからその装置のステータス情報を取得するために、HTTPのタグ実行手段により使用される。そのマップのキーは、装置のベンダー名のストリングである。そのマップの値は、与えられたモデルの装置のウェブページからステータス情報を取得するために用いられる情報を含む他のマップである。内部マップのキーは、装置のモデル名のストリングであり、その値は、ウェブページに関する情報とウェブページからステータス情報をいかに取得するかに関する情報とを含むベクトル構造SWebPageInfoである。構造SwebPageInfoは、ウェブページから或る一つの情報を取得するために必要なすべての情報を提供する構造SPreconKeyValueInfoを含む。マップ構造は、HTTPのタグ実行手段用のサポートデータベースのテーブルからの情報で占められる。CTagHTTPImplementationはTagHTTPODBCパッケージを用いてデータベースのテーブルから情報を取得する。
【０１３９】
図４０はシステムがステータス情報を抽出するための装置のウェブページ例である。このウェブページサンプルは装置のステータス情報を含むジャバスクリプトを使用する。
【０１４０】
図４１では、HTMLソースファイルの一部が示され、このファイルの結果ウェブページは図４０に示されるようにブラウザ上で表示される。ファイルはHTMLタグ及びジャバスクリプト双方を示す。様々なトナーレベルについての情報はジャバスクリプトで発見される。
【０１４１】
図４２はシステムがステータス情報を抽出するための装置の別のウェブページ例である。このウェブページサンプルも装置のステータス情報を含むジャバスクリプトを使用する。
【０１４２】
図４３では、HTMLソースファイルの一部が示され、このファイルの結果ウェブページは図４２に示されるようにブラウザ上で表示される。ファイルはHTMLタグ及びジャバスクリプト双方を示す。黒色のトナーレベルについての情報はジャバスクリプトで発見される。
【０１４３】
図４４ではScriptHTTPImplementationパッケージ用のパッケージ図が示される。このパッケージはHTTPを実装し、図４０，４２に示されるような装置のウェブページのジャバスクリプトから情報を取得する。クラスCScriptHTTPImplementationは、このパッケージのインターフェイスであり、他のクラス及びパッケージを管理し、装置のウェブページのジャバスクリプトから情報を取得する方法を実行する。CScriptHTTPImplementationはCAbsHTTPImplementationから導出されるクラスである。アペンディックス３はCScriptHTTPImplementationのクラス仕様を示す。ScriptHTTPODBCパッケージ及びHTTP_HTMLToolパッケージは図３３に関連して説明済みである。クラスScriptHTMLProcessorは装置のウェブページを処理し、装置のウェブページからジャバスクリプトのみを取得する。クラスCabsScriptProcessはステータス情報を取得するためにジャバスクリプトを処理する抽象クラスである。アペンディックス４はCabsScriptProcessのクラス仕様を示す。クラスCAbsScriptProcessは一組の共通関数を用意し、ウェブページのタグから情報を取得するため及びウェブページのジャバスクリプトから情報を取得するために使用されるデータ構造を初期化する。CabsScriptProcessから導出されたクラスは関数各々についての方法をもたらす。本方法は装置のウェブページ、モデル及びベンダーに依存する。様々な派生クラスがインターフェイス関数の処理を様々に処理できるように、抽象クラスの派生クラスは多数存在してよい。抽象クラスは新たな装置が加えられることを許可し、その情報はウェブページのジャバスクリプト中に存在する。
【０１４４】
図４５ではCScriptHTTPImplementationのマップ構造m_VendorModuleInfoMapが示され、そのマップ構造はHTTPのスクリプト実効手段により使用され、装置のウェブページのジャバスクリプトからその装置のモデル名を取得する。マップのキーは装置のベンダー名のストリングである。マップの値は構造SModuleInfoのベクトルである。構造SModuleInfoは、装置のベンダー名のストリングと、モデル名を含む装置のウェブページのストリングと、（装置のモデル名を取得するためにウェブページ中のジャバスクリプトを処理する）抽象クラスCAbsScriptProcessに対するポインタとを含む。ポインタはCAbsScriptProcessの派生クラスを指す。
【０１４５】
図４６では、CScriptHTTPImplementationのマップ構造m_UniqueIDInforMapが示され、このマップ構造は、装置のウェブページのジャバスクリプトからその装置固有の識別子を取得するために、HTTPのスクリプト実行手段により使用される。固有の識別子は装置を確認する文字列（ストリング）であり、例えばシリアル番号やMACアドレスである。マップに対するキーは、装置のベンダー及びモデル名の連結であるストリングである。その値は構造SUniqueIDInfoである。構造SUniqueIDInfoは、装置のベンダー名のストリングと、装置のモデル名のストリングと、固有の識別子を含む装置のウェブページのストリングと、（装置固有の識別子を取得するためにウェブページ中のジャバスクリプトを処理する）抽象クラスCAbsScriptProcessに対するポインタとを含む。ポインタはCAbsScriptProcessの派生クラスを指す。
【０１４６】
図４７では、CScriptHTTPImplementationのマップ構造m_StatusMapが示され、このマップ構造は、装置のウェブページのジャバスクリプトからその装置固有の識別子を取得するために、HTTPのスクリプト実行手段により使用される。マップのキーは或るストリングであり、そのストリングは装置のベンダー及びモデル名の連結である。その値は構造SwebPageStatusのベクトルである。構造SWebPageStatusは、ウェブページのストリングと、ウェブページから取得可能なステータス情報及びウエイト（優先度）のマップ構造と、（装置のステータス情報を取得するためにウェブページ中のジャバスクリプトを処理する）抽象クラスCAbsScriptProcessに対するポインタとを含む。ポインタはCAbsScriptProcessの派生クラスを指す。
【０１４７】
３つのマップ構造は例えばディスカバリープロセスのようなシステムの初期化中に占められる。CAbsScriptProcessの派生クラス全てが作成され、システムの初期化中に初期化される。派生クラスはウェブページのジャバスクリプトから所望の情報を抽出するのに必要な情報と共に初期化される。システムの初期化後に、装置のウェブページからステータス情報を周期的に取得するためにマップ構造m_StatusMapのみが必要とされる。従って、初期化後に、構造m_VendorModelInfoMap及びm_UniqueIDInfoMapはもはや必要ないので削除（クリーンアップ）される。
【０１４８】
図４８では、ScriptHTTPImplementationパッケージによるステータス情報取得手順を示すフローチャートが示される。第１ステップはIPアドレスが空(empty)であるか否かを検査する。IPアドレスが空でなければ本プロセスは偽を返す。そうでなければ本方法は装置のベンダー及びモデル名がHTTPのスクリプト実行手段によりサポートされているか否かを確認する。ベンダー及びモデルがサポートされていなかったならば、本プロセスは偽を返す。そうでなければ本方法はHTTPにより装置のウェブページへのアクセスに要する遅延時間を設定する。次に装置とHTTPセッションが始められる。HTTPセッションが開始できなかったならば、本プロセスは偽を返す。そうでなければ本プロセスは或る装置のウェブページ全てを取得し、そのウェブページのジャバスクリプト中にはステータス情報が含まれている。ウェブページの各々について、本プロセスは以下に説明される手順を用いてジャバスクリプトからステータス情報を取得する。ウェブページからステータス情報を取得した後に、本プロセスはその装置とのHTTPセッションを終了する。HTTPのスクリプト実行手段によりステータス情報がその装置から一切取得されなくなったならば、本プロセスは偽を返す。そうでなければ本プロセスは真を返す。
【０１４９】
ウェブページのジャバスクリプトからステータス情報を取得する際に、本プロセスは、どの情報が取得されることを要するかを確認する。これは、他のプロトコルにより又は他のHTTPの実行により既に取得済みのステータス情報を検査することでなされる。ウェブページから取得されるべきステータス情報が取得されていない場合或いは取得されているが低い重み（優先度）であった場合、本プロセスはステータス情報を取得する。全てのステータス情報が既に取得済みであったならば、ウェブページからステータス情報を取得するプロセスは完了する。そうでなければ本プロセスはステータス情報を取得するためにスクリプトプロセッサを初期化する。初期化はCAbsScriptProcessのstart()関数を呼び出すことを含む。そしてこのプロセスはスクリプトプロセッサを用いてステータス情報を取得する。ステータス情報の取得は、CAbsScriptProcessのtransformData()関数を呼び出すことを含む。図４９はtransformData()関数を用いてステータス情報を取得する様子の詳細を示す。スクリプトプロセッサを用いてステータス情報を取得すると、ウェブページからステータス情報を取得するプロセスは完了する。
【０１５０】
図４９では、ScriptHTTPImplementationパッケージのスクリプトからステータス情報を取得するプロセスを説明するためのフローチャートが示される。第１に本プロセスはHTTPセッションを用いてウェブページへのアクセスを試みる。ウェブページにアクセスできなかったならば本プロセスは偽を返す。そうでなければ本プロセスはウェブページからライン(line)を取得する。ウェブページからラインが取得されると、本プロセスはそのラインがジャバスクリプトの一部であるか否かを確認する。一部でなければ、本システムはウェブページから次のラインを取得する。そうでなければ、本プロセスはスクリプトプロセッサを用いてそのジャバスクリプトからステータス情報を取得する。スクリプトプロセッサがジャバスクリプトのラインからステータス情報を取得しなかったならば、本システムはウェブページから次のラインを取得する。そうでなければ本プロセスはスクリプトプロセッサから取得したステータス情報が必要か否かを確認する（スクリプトプロセッサで取得されたもの以上のウエイトを有するステータス情報が、他のプロトコルにより又はHTTPの他の実行手段により既に取得済みであったならば、ステータス情報は不要かもしれない。）。ステータス情報が必要とされるならば、本プロセスはそのステータス情報を格納する。ステータス情報は図２８に示されるマップ構造に位置づけられる。ステータス情報を格納した後に又はステータス情報が不要であった場合に、本プロセスは、より多くのステータス情報がウェブページのジャバスクリプトから取得される必要の有無を確認する。より多くのステータス情報が取得されなければならない場合、システムはウェブページから次のラインを取得する。取得されるべき更なるステータス情報が無かった場合又はウェブページから取得可能な更なるラインが無かった場合、本プロセスは、ジャバスクリプトから取得される何らかのステータス情報の有無を確認する。ステータス情報が一切取得されないならば、本プロセスは偽を返す。そうでなければ本プロセスは真を返す。
【０１５１】
図５０はScriptHTTPODBCパッケージを示すクラス図である。このパッケージはサポートデータベースとインターフェイスをとり、装置のウェブページのジャバスクリプトからモデル名、固有の識別子及びステータス情報を抽出するのに使用される情報を取得する。CScriptHTTPODBCクラスは、このパッケージに関するインターフェイスであり、他のクラスを管理し、サポートデータベースのテーブルから適切な情報を取得する。アペンディックス５はCScriptHTTPPODBCのクラス仕様を示す。CXXXDataクラス及びその対応するCXXXTableクラスは、テーブルから情報を取得するための、図１９に示されるサポートデータベースのXXXテーブルへのアクセス権を与える。このパッケージは、様々な装置のウェブページのジャバスクリプトを処理するのに使用されるCAbsScriptProcessの全ての派生クラス、CYYYScriptProcessを含む。各派生クラスは、ステータス情報を取得するのに使用されるデータ構造を設定し（putParameters()関数）、ステータス情報を取得するためにプロセスを初期化し（start()関数）、ジャバスクリプトからステータス情報を取得し(transformData()関数)、及びステータス情報を取得するプロセスを終了する(end()関数)ための方法を用意する。HTTPのスクリプト実行手段によりサポートされる新たな装置の追加は、その装置のCAbsScriptProcessから導出される新たなクラスの追加を要する。CScriptHTTPODBCの関数setupCreateFunctionMap()は、CAbsScriptProcessの派生クラス全てについてデータ構造を作成及び設定する。
【０１５２】
図５１に示される状態図は、情報を取得するためにCAbsScriptProcessの派生クラスにより装置のウェブページのジャバスクリプトを処理するためのものである。この状態図はCAbsScriptProcessのtransformData()関数に対応する。アペンディックス４はCAbsScriptProcessのクラス仕様を示す。CAbsScriptProcessで規定される１つの
構造及び２つのenum（列挙）がある。enumEReturnはtransformData()関数によって使用され、装置のウェブページのジャバスクリプトから情報を取得する際に関数の結果を返す。enumEStateはtransformData()関数によって使用され、ジャバスクリプトから情報を取得するプロセスの状態を確認する。状態図中のほとんどの状態はenumEStateに関連する。構造SinfoStructureはウェブページのジャバスクリプトから情報を取得するのに使用される。CAbsScriptProcessの派生クラスはenums及び構造の利用の際に変化する。或る派生クラスはtransformData()でenumEReturnの２値のみを利用するが、別の派生クラスは４つ全てを使用するかもしれない。或る派生クラスはenumEStateの２値のみを用いて所望の情報を取得するが、別の派生クラスは３つだけ又は４つを使用するかもしれない。或る派生クラスは、ウェブページから情報を取得するためのtypeSInfoStructureである帰属メンバを含み、別の派生クラスはウェブページから複数の情報を取得するためのSinfoStructureのベクトルである帰属メンバを含むかもしれない。
【０１５３】
状態図では、enumEStateの値に対応する５つの状態全てが示されているが、ジャバスクリプトから所望の情報を取得する際に全ての装置について全てが使用されなくてもよい。状態数や、状態間の遷移に使用される構造SinfoStructureにおけるm_sParの数は、ベクトル、モデル及びウェブページに依存する。状態図は状態eStartから始まる。このプロセスは、structSInfoStructureのストリングm_sPar1がジャバスクリプトのライン中に発見されるまで、このeStart状態のままである。ベンダー、モデル及びウェブページに対応するプロセスが、データの抽出前にm_sPar1を発見することだけを必要としていたならば、次の状態は抽出状態であり、ジャバスクリプトのラインから情報が抽出される。こうしてこのプロセスは完了する。そうでなければ次の状態はePrecon1である。このプロセスは、structSInfoStructureのストリングm_sPar2がジャバスクリプトのライン中に発見されるまで、ePrecon1のままである。本プロセスが、データ抽出前に、発見されるべきm_sPar2を要するベンダー、モデル及びウェブページに関連するならば、次の状態は抽出状態であり、ジャバスクリプトのラインから情報が抽出される。かくてこのプロセスは完了する。そうでなければ次の状態はePrecon2である。状態ePrecon2及びePrecon3の遷移は状態ePrecon1のものと同様であるが、structSInfoStructureのストリングm_sPar3及びm_sPar4が生じる状態遷移を引き起こす点が異なる。プロセスが状態ePrecon5にあると、そのプロセスは、構造SInfoStructureのm_sPar5がジャバスクリプトのライン中に発見されるまでその状態にとどまる。次の状態は抽出状態であり、このプロセスは終了する。ジャバスクリプトから情報を得る際に、５つのストリングm_sPar1乃至m_sPar5は、所望の情報を取得するのに必要なほとんどのストリングであるべきである。
【０１５４】
図５２はCAbsScriptProcessの２つの派生クラスで使用されるデータ構造サンプルを示す。CAbsScriptProcess、CSamsungStatusCLP550ScriptProcessの第1派生クラスは、structSInfoStructureのベクトルを用いて、装置のウェブページのジャバスクリプトからカラートナーレベルを得る。トナーレベルの各々はステータス情報を取得するために3つのストリングm_sPar1ないしm_sPar3を要する。従って情報を取得するためのプロセスは、ステータス情報がジャバスクリプトから抽出される前に、３つの状態を介して進行する−eStart、ePrecon1及びePrecon2。第２の派生クラス（CsamsungStatusML2550ScriptProcess）は、structSInfoStructureをそれ自身で使用し、装置のウェブページのジャバスクリプトから黒色のトナーレベルを取得する。黒色のトナーレベルを得るためにトナーレベルは２つのストリングm_sPar1及びm_sPar2を要する。従ってその情報を取得するためのプロセスは、ブラックトナーレベルがジャバスクリプトから抽出される前に、2つの段階を通じて進行する−eStart及びePrecon1。アペンディクス６，７はCSamsungStatusCLP550ScriptProcess及びCsamsungStatusML2550ScriptProcessのクラス仕様をそれぞれ示す。
【０１５５】
図５３では、ウェブページのサンプルを使用して、CAbsScriptProcessの派生クラスがジャバスクリプトを含む装置のウェブページをどのように処理するかを示す。structSInfoStructureのサンプル値はウェブページの下に示されている。この例では取得されているステータス情報は、シアン色のトナーレベルである。structSInfoStructureの３つのストリング（パラメータ）m_sPar1、m_sPar２及びm_sPar３がステータス情報を見つけるのに必要とされる。structSInfoStructureのEstate m_Stateは遭遇したストリングを追跡し続けるのに使用される。structSInfoStructureの区切り符号（デリミタ）m_sDelimiter及びstructSInfoStructureの位置m_nInLinePositionは、ステータス情報を含むラインからステータス情報を抽出するのに必要とされる。ウェブページのラインは、全てのステータス情報が取得されるまで或いはウェブページの最後に遭遇するまで読み取られる。ジャバスクリプトの一部であるラインのみが、CAbsScriptProcessのtransformData()に伝送される。structSInfoStructureのm_Stateの初期値はeStartである。ジャバスクリプトのラインはCAbsScriptProcessのtransformData()に伝送される。ライン“関数RemainTonerOption()”がそこに伝送されると、structSInfoStructureのm_sPar1がライン中で発見される。structSInfoStructureのm_StateはePrecon1である。ジャバスクリプトの更なるラインはm_Stateに対する変更なしに伝送される。ライン“else”がそこに伝送されると、structSInfoStructureのm_sPar2がライン中で発見される。structSInfoStructureのm_StateはePrecon2である。ジャバスクリプトの更なるラインは、ライン“varCyanTonerPre=100”がそこに伝送されるまで、m_Stateに対する変更なしに伝送される。structSInfoStructureのm_sPar3はライン中で発見され、structSInfoStructureのm_sDelimiter及びm_nInLinePositionの値を用いてそのラインからステータス情報が抽出される。M_sDelimiterはステータス情報を区切るキャラクタであり、m_nInLinePositionはステータス情報に遭遇する前にどの程度多くのデリミタが有るかを決定する数である。ステータス情報が最初のデリミタより先にある場合には、m_nInLinePositionは０である。シアントナーレベルについてジャバスクリプトから「１００」の値が得られると、更なるウェブページは取得されることを要しない。
【０１５６】
図５４はCAbsScriptProcessの派生クラスのプロセスを示すフローチャートであり、装置のウェブページから情報を抽出するためのものである。このフローチャートは図５３で説明されたようなシアントナーレベルを抽出するのに使用されるサンプルプロセスである。このプロセスはCAbsScriptProcessのtransformData()に対応する。CAbsScriptProcessの派生クラスのtransformData()の方法はベンダー及びモデルによって変化するが、ステータス情報を見出すためにステータスを使うことは、ステータス情報を取得するための共通の手法である。
【０１５７】
図５５Aはウェブページから情報を抽出するのに使用される構造structSInfoStructureのメンバを示す。この構造は、アペンディックス４で示されるCAbsScriptProcessで規定され、CAbsScriptProcessの全ての派生クラスで使用可能である。ストリングm_sParXXXをCAbsScriptProcessの派生クラスで使用し、所望の情報を含むウェブページのラインを見出す。所望の情報を見出すのに全てのストリングが必要なわけではなく、５つのストリングm_sParXXXを利用可能にすることで、所望の情報を見出すのに５つ全てのストリングを要するかもしれない将来的な装置に備えた柔軟性を可能にする。ストリングm_sDelimiter及び整数m_nInLinePositionは、情報を含むウェブページのラインから所望の情報を抽出するのに使用される。infoTypeのm_nENUMは、シアントナーレベルを表現するeCyanや、装置で印刷されるページ総数を表現するePrtLifeCountのように、抽出されるべき情報のタイプを表現する数である。EStateのm_Stateは、ウェブページから所望の状態を突き止めるので、構造の状態を追跡し続けるのに使用される。それは開始状態でeStateに初期化され、各ストリングm_sParXXXに出会うと状態を変える。
【０１５８】
CAbsScriptProcess、その派生クラス及びその構造SInfoStructureの説明及び利用法に関し、ウェブページのスクリプトからデータを取得することに焦点が当てられてきたが、それらの構造及び方法の有用性はウェブページのタグからデータを抽出することに適用されてもよく、その場合m_sParXXXはデータを取得するための或るタグに対応する。
【０１５９】
図５５Bは図５５Aの構造SinfoStructureのメンバのサンプル値を示す。この構造は装置のシアントナーレベル（m_nENUM=eCyan）をそのウェブページから見出すのに使用される。m_sPar1ないしm_sPar3の３つのストリングのみが所望の情報を見出すのに必要とされる。m_sPar4及びm_sPar5の残りの２つはエンプティであり、使用されない。M_sDelimiterのキャラクタ‘＝’及び‘，’並びにm_nInLinePositionの１を用いて、所望の情報が存在するラインからそれを抽出する。
【０１６０】
ネットワークに接続された監視が必要な少数の装置について本発明を示したが、当然のことながら、本発明の精神と範囲から逸脱することなく、ネットワークに接続される装置の数はいくつでもよい。また、本発明は、いろいろな装置を監視かつ制御する必要があるような家庭環境に適用してもよい。
【０１６１】
本発明の実施形態によれば、マルチベンダー環境において、いろいろな装置の監視が可能となり、特定のプライベートなマネージメント情報ベース（MIB）情報を持たなくても、詳細な情報を検索し、ユーザが理解しやすく扱いやすい方法で表示することを促す。さらに、読み出した情報は、SMTP、FTP、ウェブサービス等のいろいろな方法を用いて再配信することができる。
【０１６２】
コンピュータ技術の当業者には明らかであるように、本発明のコントローラは、本発明の教示によりプログラムされた、通常の汎用デジタルコンピュータまたはマイクロプロセッサとしてもよい。本開示の教示に基づく知識を備えたプログラマーは容易に適当なソフトウェアのコーディングをでき、ソフトウェア技術の当業者には明らかである。本発明は、特定用途用集積回路や従来のコンポーネント回路を適当に配線して相互接続することによっても実施することができ、これは当該分野の当業者には明らかである。
【０１６３】
本発明はコンピュータをプログラムし本発明のプロセスを実行させる命令を含むコンピュータプログラム、およびそのコンピュータプログラムが格納された記録媒体を含む。記録媒体には、フロッピディスク、光ディスク、CD-ROM、光磁気ディスク、ROM、RAM、EPROM、EEPROM、磁気または光カード、その他の電子的命令を格納するのに好適ないかなる媒体も含む。
【０１６４】
上記の教示を考慮して本発明を様々に修正したり、バリエーションを考えたりすることができる。従って、当然のことながら、添付したクレームの範囲内で、ここに具体的に説明したものとは別の実施形態により本発明を実施することができる。
【０１６５】
以下に、付録（アペンディックス）を示す。
【図面の簡単な説明】
【０１６６】
【図１】インターネットを介してコンピュータおよびデータベースのネットワークに接続された、ネットワーク化されたビジネスオフィス装置群を示す図である。
【図２】デジタル画像形成装置の構成を示す図である。
【図３】図２に示したデジタル画像形成装置の電子的構成を示す図である。
【図４】図３に示した複数ポート通信インターフェイスの詳細を示す図である。
【図５】ビジネスオフィス装置がネットワークに直接接続された、またはネットワークに接続されたコンピュータに接続された別のシステム構成を示す図である。
【図６Ａ】電子メールを用いたアプリケーション部への及びそこからの情報の流れを示すブロック図である。
【図６Ｂ】電子メールを用いた通信の別の方法を示す図（アプリケーション部に接続されたコンピュータはメッセージ転送エージェント（MTA）としても機能する）である。
【図６Ｃ】電子メールを用いた通信の別の方法を示す図（アプリケーション部は電子メールを交換するメッセージ転送エージェントを含む）である。
【図６Ｄ】メールサーバがPOP3サーバとして機能して機器／装置のメールを受信し、シンプルメール転送プロトコル（SMTP）サーバとして機能してその機器／装置のメールを送信する、電子メールを用いた通信の別の方法を示す図である。
【図７】インターネットを通してメッセージを送信する別の方法を示す図である。
【図８】機器／装置に接続し、電子メールメッセージを通信するために使用するコンピュータの一例を示す図である。
【図９】本発明の一実施形態によるシステム全体を示す概略図である。
【図１０】本発明の一実施形態による、データの監視に使用するモジュールとそのインターフェイス機能を示す図である。
【図１１】監視モジュールの詳細とサブモジュール間の呼び出し機能を示す図である。
【図１２】図１０に示した監視モジュールのinit関数のシーケンスを示す図である。
【図１３】図１１に示した、監視マネージャにより監視される装置の状態を判断する状態監視機能のシーケンスの一例を示す図である。
【図１４】図１２に示した、CDeviceFactoryにより生成され監視マネージャにより使用される、装置を示すベクトルを示す図である。
【図１５】本発明の一実施形態による、被監視装置へのアクセスに必要なパラメータ値を格納するために使用するSParameterデータ構造を示す図である。
【図１６】本発明の一実施形態による、被監視装置へのアクセスに必要なパラメータ値を格納するために使用するマップ構造を示す図である。
【図１７】本発明の一実施形態で使用する監視データベースの構成を示す図である。
【図１８】本発明の一実施形態による通信プロトコルにより構成されたサポートデータベースの構成を示す図である。
【図１９】本発明の一実施形態によるHTTPプロトコル用のサポートデータベースの構成を示す図である。
【図２０】本発明の一実施形態による通信プロトコルにより構成されたサポートデータベースの構成を示す図である。
【図２１】本発明の一実施形態によるHWaccessモジュールのクラス構造を示す図である。
【図２２】本発明の一実施形態による、被監視装置にアクセスしその被監視装置からステータス情報を取得するために必要な情報を維持する、図２１のHWaccessモジュールで使用されるデータ構造を示す図である。
【図２３】関しパッケージのinit関数が呼び出された場合のHwaccessパッケージの初期化シーケンス図である。
【図２４】装置が何らかのプロトコルでアクセス可能か否かを判別するために、HWaccessパッケージのcanAccessIP()のシーケンス図である。
【図２５Ａ】HwaccessパッケージのobtainVendor(),obtainModel()及びobtainUniqueID()関数のシーケンス図である。
【図２５Ｂ】HwaccessパッケージのobtainVendor(),obtainModel()及びobtainUniqueID()関数のシーケンス図である。
【図２６】本発明の一実施形態による、どのプロトコルを使用して被監視装置のステータス情報を取得するかを判断するために、被監視装置を表すソフトウェアオブジェクトで使用されるデータ構造がどのように更新されるかを示すフローチャートである。
【図２７】本発明の一実施形態による、すべての通信プロトコルを用いて被監視装置からステータス情報を取得する過程を示すフローチャートである。
【図２８】本発明の一実施形態による、各プロトコルについて、ある特定のベンダーとモデルに関する被監視装置のステータス情報を格納及び維持するために使用するデータ構造を示す図である。
【図２９】図２１の各プロトコルパッケージを示すパッケージ図（「XXX」はHTTP、FTP、SNMP等である）を示す。
【図３０】図２１の各プロトコルパッケージを示す別のパッケージ図（「XXX」はHTTP、FTP、SNMP等である）を示す。
【図３１】SNMPパッケージのクラス構造を示す図である。
【図３２】FTPパッケージのパッケージ図を示すである。
【図３３】スクリプト中のウェブページ及びタグからの情報抽出をサポートするHTTPパッケージのパッケージ図である。
【図３４】CHTTPProtocolクラスのデータ構造m_ImplementationMapを示す図である。
【図３５】CHTTPProtocolクラスのデータ構造m_VendorModelSupportMapを示す図である。
【図３６Ａ】CHTTPProtocolのinitWithVendor()関数のシーケンス図を示す。
【図３６Ｂ】CHTTPProtocolのinitWithModel()関数のシーケンス図を示す。
【図３６Ｃ】CHTTPProtocolのinitWithVendorModel()関数のシーケンス図を示す。
【図３７】HTTPを介して装置のステータス情報を取得するフローチャートである。
【図３８】装置のウェブページのタグから情報を抽出するためのTagHTTPImplementationパッケージのパッケージ図を示す。
【図３９】CScriptHTTPImplementationクラスのマップ構造m_VendorModelWebInfoMapを示す図である。
【図４０】システムがステータス情報を抽出するための装置のウェブページ例を示す図である。
【図４１】図４０のウェブページの表示を生成するジャバスクリプト及びHTMLタグの一部を示す図である。
【図４２】本発明のシステムがステータス情報を抽出するための装置の別のウェブページ例を示す図である。
【図４３】図４２のウェブページの表示を生成するジャバスクリプト及びHTMLタグの一部を示す図である。
【図４４】装置のウェブページのスクリプトから情報を抽出する、ScriptHTTPImplementationパッケージのパッケージ図を示す。
【図４５】モデル名、固有のID及びステータス情報を装置のウェブページから取得するのに使用されるCScriptHTTPImplementationクラスのデータ構造を示す図である。
【図４６】モデル名、固有のID及びステータス情報を装置のウェブページから取得するのに使用されるCScriptHTTPImplementationクラスのデータ構造を示す図である。
【図４７】モデル名、固有のID及びステータス情報を装置のウェブページから取得するのに使用されるCScriptHTTPImplementationクラスのデータ構造を示す図である。
【図４８】ScriptHTTPImplementationによりステータス情報を取得するプロセスを説明するフローチャートである。
【図４９】ScriptHTTPImplementationパッケージによりウェブページのスクリプトからステータス情報を取得するプロセスを説明するフローチャートである。
【図５０】ScriptHTTPODBCパッケージのクラス図を示す。
【図５１】導出されたCabsScriptProcessのクラスにより装置のウェブページのジャバスクリプトを処理する状態図を示す。
【図５２】CabsScriptProcessの２つの導出されたクラスにより使用されるサンプルデータ構造を示す。
【図５３】ジャバスクリプトを含む装置のウェブページを導出されたCabsScriptProcessのクラスがどのように処理するかを示す図である。
【図５４】装置のウェブページから情報を抽出するために、CabsScriptProcessの導出されたクラスのプロセスを示す図である。
【図５５Ａ】ウェブページから情報を抽出するために使用される構造SInfoStructureの構成メンバを示す図である。
【図５５Ｂ】図５５Aの構造SInfoStructureの構成メンバのサンプル値を示す図である。
【符号の説明】
【０１６７】
２４ デジタルコピー／プリンター
２７ オフィス機器
２８ ファクシミリ
３２ プリンター
５０Ａ ファイヤーウォール
５０Ｂ ファイヤーウォール
５０Ｃ ファイヤーウォール
１６６ 多ポートネットワークI/F
１７２ IFコントローラ
１７４ 操作パネル
１７６ 記憶I/F
１７８ フラッシュメモリ
１８４ オプションI/F
１８７ クロック／タイマー
１７１ ローカル接続
１８８ オプショナルユニットインターフェイス
１９０ フューザ
１９２ プリンター／イメージャ
１９４ スキャナー
１９６ ペーパーフィードコントローラ
１９８ 大容量トレイ部
２００ デュプレクサ
２０２ ソータ
【特許請求の範囲】
【請求項１】
ネットワークに通信可能に結合された被監視装置に格納されたウェブページのスクリプトからHTTP通信プロトコルを用いてステータス情報を抽出する方法であって、
ウェブページのスクリプトからステータス情報を抽出するのに使用される少なくとも１つのパラメータストリング及びウェブページの身元を、ベンダー及びモデル情報に基づいて取得する取得ステップと、
ウェブページの身元及びHTTPプロトコルを用いて前記ウェブページにアクセスし、前記スクリプトにてウェブページのラインを取得するアクセスステップと、
取得したウェブページのラインを分析し、前記少なくとも１つのパラメータストリング中のパラメータストリングが、取得したラインの中で捜し出されたか否かを判別する分析ステップと、
前記パラメータストリングが取得したラインの中で捜し出されなかったことが分析ステップで確認された場合に、前記パラメータが捜し出されるまで前記アクセス及び分析ステップを反復する反復ステップと、
前記パラメータストリングが取得したラインの中で捜し出されたことが分析ステップで確認された場合に、前記少なくとも１つのパラメータストリングの全てのパラメータストリングが捜し出されているか否かを判別する判別ステップと、
前記少なくとも１つのパラメータストリングの全てのパラメータストリングが捜し出されていないことが前記判別ステップで確認された場合に、前記少なくとも１つのパラメータストリングの全てのパラメータストリングが捜し出されるまで前記アクセス、分析、反復及び判別ステップを反復するステップと、
全てのパラメータストリングが前記スクリプトにて捜し出されたことが前記判別ステップで確認された場合に、最後に捜し出されたパラメータストリングの場所に基づいて前記ウェブページからステータス情報を抽出する抽出ステップと、
を有することを特徴とする方法。
【請求項２】
前記抽出ステップで取得したステータス情報を前記ベンダー及びモデル情報に関連付けて第２メモリに格納するステップ
を更に有することを特徴とする請求項１記載の方法。
【請求項３】
被監視装置のベンダー及びモデル情報を第１メモリから検索するステップ
を更に有することを特徴とする請求項１記載の方法。
【請求項４】
前記抽出ステップが、
最後のパラメータストリングが捜し出された取得済みラインからステータス情報を取得するステップを有する
ことを特徴とする請求項１記載の方法。
【請求項５】
前記アクセスステップが、
被監視装置に格納されたHTMLファイルにアクセスし、ジャバスクリプトからHTMLファイルのラインを取得するステップを有する
ことを特徴とする請求項１記載の方法。
【請求項６】
ネットワークに通信可能に結合された被監視装置に格納されたウェブページのスクリプトからHTTP通信プロトコルを用いてステータス情報を抽出するコンピュータシステムであって、
ウェブページのスクリプトからステータス情報を抽出するのに使用される少なくとも１つのパラメータストリング及びウェブページの身元を、ベンダー及びモデル情報に基づいて取得する取得手段と、
ウェブページの身元及びHTTPプロトコルを用いて前記ウェブページにアクセスし、前記スクリプトにてウェブページのラインを取得するアクセス手段と、
取得したウェブページのラインを分析し、前記少なくとも１つのパラメータストリング中のパラメータストリングが、取得したラインの中で捜し出されたか否かを判別する分析手段と、
前記パラメータストリングが取得したラインの中で捜し出されなかったことが前記分析手段で確認された場合に、前記パラメータが捜し出されるまで前記アクセス手段及び分析手段の動作を反復させる反復手段と、
前記パラメータストリングが取得したラインの中で捜し出されたことが分析手段で確認された場合に、前記少なくとも１つのパラメータストリングの全てのパラメータストリングが捜し出されているか否かを判別する判別手段と、
前記少なくとも１つのパラメータストリングの全てのパラメータストリングが捜し出されていないことが前記判別手段で確認された場合に、前記少なくとも１つのパラメータストリングの全てのパラメータストリングが捜し出されるまで前記アクセス手段、前記分析手段、前記反復手段及び前記判別手段の動作を反復させる手段と、
全てのパラメータストリングが前記スクリプトにて捜し出されたことが前記判別手段で確認された場合に、最後に捜し出されたパラメータストリングの場所に基づいて前記ウェブページからステータス情報を抽出する抽出手段と、
を有することを特徴とするコンピュータシステム。
【請求項７】
前記抽出手段で取得したステータス情報を前記ベンダー及びモデル情報に関連付けて第２メモリに格納する手段
を更に有することを特徴とする請求項６記載のコンピュータシステム。
【請求項８】
被監視装置のベンダー及びモデル情報を第１メモリから検索する手段
を更に有することを特徴とする請求項６記載のコンピュータシステム。
【請求項９】
前記抽出手段が、
最後のパラメータストリングが捜し出された取得済みラインからステータス情報を取得する手段を有する
ことを特徴とする請求項６記載のコンピュータシステム。
【請求項１０】
前記アクセス手段が、
被監視装置に格納されたHTMLファイルにアクセスし、ジャバスクリプトからHTMLファイルのラインを取得する手段を有する
ことを特徴とする請求項６記載のコンピュータシステム。
【請求項１１】
コンピュータシステムで実行する命令を含むコンピュータプログラムであって、ネットワークに通信可能に結合された被監視装置に格納されたウェブページのスクリプトからHTTP通信プロトコルを用いてステータス情報をコンピュータシステムに抽出させ、当該コンピュータプログラムは、
ウェブページのスクリプトからステータス情報を抽出するのに使用される少なくとも１つのパラメータストリング及びウェブページの身元を、ベンダー及びモデル情報に基づいて取得する取得ステップと、
ウェブページの身元及びHTTPプロトコルを用いて前記ウェブページにアクセスし、前記スクリプトにてウェブページのラインを取得するアクセスステップと、
取得したウェブページのラインを分析し、前記少なくとも１つのパラメータストリング中のパラメータストリングが、取得したラインの中で捜し出されたか否かを判別する分析ステップと、
前記パラメータストリングが取得したラインの中で捜し出されなかったことが分析ステップで確認された場合に、前記パラメータが捜し出されるまで前記アクセス及び分析ステップを反復する反復ステップと、
前記パラメータストリングが取得したラインの中で捜し出されたことが分析ステップで確認された場合に、前記少なくとも１つのパラメータストリングの全てのパラメータストリングが捜し出されているか否かを判別する判別ステップと、
前記少なくとも１つのパラメータストリングの全てのパラメータストリングが捜し出されていないことが前記判別ステップで確認された場合に、前記少なくとも１つのパラメータストリングの全てのパラメータストリングが捜し出されるまで前記アクセス、分析、反復及び判別ステップを反復するステップと、
全てのパラメータストリングが前記スクリプトにて捜し出されたことが前記判別ステップで確認された場合に、最後に捜し出されたパラメータストリングの場所に基づいて前記ウェブページからステータス情報を抽出する抽出ステップと、
をコンピュータシステムに実行させる命令を有することを特徴とするコンピュータプログラム。
【請求項１２】
前記抽出ステップで取得したステータス情報を前記ベンダー及びモデル情報に関連付けて第２メモリに格納するステップ
を更にコンピュータシステムに実行させる請求項１１記載のコンピュータプログラム。
【請求項１３】
被監視装置のベンダー及びモデル情報を第１メモリから検索するステップ
を更にコンピュータシステムに実行させる請求項１１記載のコンピュータプログラム。
【請求項１４】
前記抽出ステップが、
最後のパラメータストリングが捜し出された取得済みラインからステータス情報を取得するステップを有する
ことを特徴とする請求項１１記載のコンピュータプログラム。
【請求項１５】
前記アクセスステップが、
被監視装置に格納されたHTMLファイルにアクセスし、ジャバスクリプトからHTMLファイルのラインを取得するステップを有する
ことを特徴とする請求項１１記載のコンピュータプログラム。
【請求項１】
ネットワークに通信可能に結合された被監視装置に格納されたウェブページのスクリプトからHTTP通信プロトコルを用いてステータス情報を抽出する方法であって、
ウェブページのスクリプトからステータス情報を抽出するのに使用される少なくとも１つのパラメータストリング及びウェブページの身元を、ベンダー及びモデル情報に基づいて取得する取得ステップと、
ウェブページの身元及びHTTPプロトコルを用いて前記ウェブページにアクセスし、前記スクリプトにてウェブページのラインを取得するアクセスステップと、
取得したウェブページのラインを分析し、前記少なくとも１つのパラメータストリング中のパラメータストリングが、取得したラインの中で捜し出されたか否かを判別する分析ステップと、
前記パラメータストリングが取得したラインの中で捜し出されなかったことが分析ステップで確認された場合に、前記パラメータが捜し出されるまで前記アクセス及び分析ステップを反復する反復ステップと、
前記パラメータストリングが取得したラインの中で捜し出されたことが分析ステップで確認された場合に、前記少なくとも１つのパラメータストリングの全てのパラメータストリングが捜し出されているか否かを判別する判別ステップと、
前記少なくとも１つのパラメータストリングの全てのパラメータストリングが捜し出されていないことが前記判別ステップで確認された場合に、前記少なくとも１つのパラメータストリングの全てのパラメータストリングが捜し出されるまで前記アクセス、分析、反復及び判別ステップを反復するステップと、
全てのパラメータストリングが前記スクリプトにて捜し出されたことが前記判別ステップで確認された場合に、最後に捜し出されたパラメータストリングの場所に基づいて前記ウェブページからステータス情報を抽出する抽出ステップと、
を有することを特徴とする方法。
【請求項２】
前記抽出ステップで取得したステータス情報を前記ベンダー及びモデル情報に関連付けて第２メモリに格納するステップ
を更に有することを特徴とする請求項１記載の方法。
【請求項３】
被監視装置のベンダー及びモデル情報を第１メモリから検索するステップ
を更に有することを特徴とする請求項１記載の方法。
【請求項４】
前記抽出ステップが、
最後のパラメータストリングが捜し出された取得済みラインからステータス情報を取得するステップを有する
ことを特徴とする請求項１記載の方法。
【請求項５】
前記アクセスステップが、
被監視装置に格納されたHTMLファイルにアクセスし、ジャバスクリプトからHTMLファイルのラインを取得するステップを有する
ことを特徴とする請求項１記載の方法。
【請求項６】
ネットワークに通信可能に結合された被監視装置に格納されたウェブページのスクリプトからHTTP通信プロトコルを用いてステータス情報を抽出するコンピュータシステムであって、
ウェブページのスクリプトからステータス情報を抽出するのに使用される少なくとも１つのパラメータストリング及びウェブページの身元を、ベンダー及びモデル情報に基づいて取得する取得手段と、
ウェブページの身元及びHTTPプロトコルを用いて前記ウェブページにアクセスし、前記スクリプトにてウェブページのラインを取得するアクセス手段と、
取得したウェブページのラインを分析し、前記少なくとも１つのパラメータストリング中のパラメータストリングが、取得したラインの中で捜し出されたか否かを判別する分析手段と、
前記パラメータストリングが取得したラインの中で捜し出されなかったことが前記分析手段で確認された場合に、前記パラメータが捜し出されるまで前記アクセス手段及び分析手段の動作を反復させる反復手段と、
前記パラメータストリングが取得したラインの中で捜し出されたことが分析手段で確認された場合に、前記少なくとも１つのパラメータストリングの全てのパラメータストリングが捜し出されているか否かを判別する判別手段と、
前記少なくとも１つのパラメータストリングの全てのパラメータストリングが捜し出されていないことが前記判別手段で確認された場合に、前記少なくとも１つのパラメータストリングの全てのパラメータストリングが捜し出されるまで前記アクセス手段、前記分析手段、前記反復手段及び前記判別手段の動作を反復させる手段と、
全てのパラメータストリングが前記スクリプトにて捜し出されたことが前記判別手段で確認された場合に、最後に捜し出されたパラメータストリングの場所に基づいて前記ウェブページからステータス情報を抽出する抽出手段と、
を有することを特徴とするコンピュータシステム。
【請求項７】
前記抽出手段で取得したステータス情報を前記ベンダー及びモデル情報に関連付けて第２メモリに格納する手段
を更に有することを特徴とする請求項６記載のコンピュータシステム。
【請求項８】
被監視装置のベンダー及びモデル情報を第１メモリから検索する手段
を更に有することを特徴とする請求項６記載のコンピュータシステム。
【請求項９】
前記抽出手段が、
最後のパラメータストリングが捜し出された取得済みラインからステータス情報を取得する手段を有する
ことを特徴とする請求項６記載のコンピュータシステム。
【請求項１０】
前記アクセス手段が、
被監視装置に格納されたHTMLファイルにアクセスし、ジャバスクリプトからHTMLファイルのラインを取得する手段を有する
ことを特徴とする請求項６記載のコンピュータシステム。
【請求項１１】
コンピュータシステムで実行する命令を含むコンピュータプログラムであって、ネットワークに通信可能に結合された被監視装置に格納されたウェブページのスクリプトからHTTP通信プロトコルを用いてステータス情報をコンピュータシステムに抽出させ、当該コンピュータプログラムは、
ウェブページのスクリプトからステータス情報を抽出するのに使用される少なくとも１つのパラメータストリング及びウェブページの身元を、ベンダー及びモデル情報に基づいて取得する取得ステップと、
ウェブページの身元及びHTTPプロトコルを用いて前記ウェブページにアクセスし、前記スクリプトにてウェブページのラインを取得するアクセスステップと、
取得したウェブページのラインを分析し、前記少なくとも１つのパラメータストリング中のパラメータストリングが、取得したラインの中で捜し出されたか否かを判別する分析ステップと、
前記パラメータストリングが取得したラインの中で捜し出されなかったことが分析ステップで確認された場合に、前記パラメータが捜し出されるまで前記アクセス及び分析ステップを反復する反復ステップと、
前記パラメータストリングが取得したラインの中で捜し出されたことが分析ステップで確認された場合に、前記少なくとも１つのパラメータストリングの全てのパラメータストリングが捜し出されているか否かを判別する判別ステップと、
前記少なくとも１つのパラメータストリングの全てのパラメータストリングが捜し出されていないことが前記判別ステップで確認された場合に、前記少なくとも１つのパラメータストリングの全てのパラメータストリングが捜し出されるまで前記アクセス、分析、反復及び判別ステップを反復するステップと、
全てのパラメータストリングが前記スクリプトにて捜し出されたことが前記判別ステップで確認された場合に、最後に捜し出されたパラメータストリングの場所に基づいて前記ウェブページからステータス情報を抽出する抽出ステップと、
をコンピュータシステムに実行させる命令を有することを特徴とするコンピュータプログラム。
【請求項１２】
前記抽出ステップで取得したステータス情報を前記ベンダー及びモデル情報に関連付けて第２メモリに格納するステップ
を更にコンピュータシステムに実行させる請求項１１記載のコンピュータプログラム。
【請求項１３】
被監視装置のベンダー及びモデル情報を第１メモリから検索するステップ
を更にコンピュータシステムに実行させる請求項１１記載のコンピュータプログラム。
【請求項１４】
前記抽出ステップが、
最後のパラメータストリングが捜し出された取得済みラインからステータス情報を取得するステップを有する
ことを特徴とする請求項１１記載のコンピュータプログラム。
【請求項１５】
前記アクセスステップが、
被監視装置に格納されたHTMLファイルにアクセスし、ジャバスクリプトからHTMLファイルのラインを取得するステップを有する
ことを特徴とする請求項１１記載のコンピュータプログラム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６Ａ】
【図６Ｂ】
【図６Ｃ】
【図６Ｄ】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【図２５Ａ】
【図２５Ｂ】
【図２６】
【図２７】
【図２８】
【図２９】
【図３０】
【図３１】
【図３２】
【図３３】
【図３４】
【図３５】
【図３６Ａ】
【図３６Ｂ】
【図３６Ｃ】
【図３７】
【図３８】
【図３９】
【図４０】
【図４１】
【図４２】
【図４３】
【図４４】
【図４５】
【図４６】
【図４７】
【図４８】
【図４９】
【図５０】
【図５１】
【図５２】
【図５３】
【図５４】
【図５５Ａ】
【図５５Ｂ】
【図２】
【図３】
【図４】
【図５】
【図６Ａ】
【図６Ｂ】
【図６Ｃ】
【図６Ｄ】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【図２５Ａ】
【図２５Ｂ】
【図２６】
【図２７】
【図２８】
【図２９】
【図３０】
【図３１】
【図３２】
【図３３】
【図３４】
【図３５】
【図３６Ａ】
【図３６Ｂ】
【図３６Ｃ】
【図３７】
【図３８】
【図３９】
【図４０】
【図４１】
【図４２】
【図４３】
【図４４】
【図４５】
【図４６】
【図４７】
【図４８】
【図４９】
【図５０】
【図５１】
【図５２】
【図５３】
【図５４】
【図５５Ａ】
【図５５Ｂ】
【公開番号】特開２００７−９５０５５（Ｐ２００７−９５０５５Ａ）
【公開日】平成１９年４月１２日（２００７．４．１２）
【国際特許分類】
【出願番号】特願２００６−２５９３２５（Ｐ２００６−２５９３２５）
【出願日】平成１８年９月２５日（２００６．９．２５）
【公序良俗違反の表示】
特許法第６４条第２項第４号の規定により図面の一部または全部を不掲載とする。
（特許庁注：以下のものは登録商標）
１．マッキントッシュ
２．リナックス
【出願人】（０００００６７４７）株式会社リコー (37,907)
【Ｆターム（参考）】
【公開日】平成１９年４月１２日（２００７．４．１２）
【国際特許分類】
【出願日】平成１８年９月２５日（２００６．９．２５）
【公序良俗違反の表示】
特許法第６４条第２項第４号の規定により図面の一部または全部を不掲載とする。
（特許庁注：以下のものは登録商標）
１．マッキントッシュ
２．リナックス
【出願人】（０００００６７４７）株式会社リコー (37,907)
【Ｆターム（参考）】
[ Back to top ]