(57)【要約】【課題】ネットワークに通信可能に結合したリモート被監視デバイスに関連する要求情報を効率的に抽出する方法を提供する。【解決手段】本方法は、デバイスのＩＰアドレスを取得すること、ＨＴＴＰプロトコルおよびＩＰアドレスを用いてデバイスにアクセスすることであって、それによって、デバイスに関連する情報文字列を取得する、アクセスすること、情報文字列から要求情報を抽出すること、情報文字列内で追加的デバイス情報を探索すること、かつ追加的デバイス情報が見つかった場合、追加的デバイス情報を抽出すること（ここで、この追加的デバイス情報は要求されなかった情報である）、および要求情報、および探索するステップで見つかった追加的デバイス情報を、デバイスのＩＰアドレスに関連づけてキャッシュすること、とを含む。【選択図】  図３９
2005004735.tif 000002
【特許請求の範囲】
【請求項１】
ネットワークに通信可能に結合したリモート被監視デバイスに関連する要求情報を抽出する方法であって、
前記デバイスのＩＰアドレスを取得するステップと、
ＨＴＴＰプロトコルおよび前記ＩＰアドレスを用いて前記デバイスにアクセスし、前記デバイスに関連する情報文字列を取得するステップと、
前記情報文字列から前記要求情報を抽出するステップと、
前記情報文字列内で追加的な非要求デバイス情報を探索し、該追加的デバイス情報が見つかった場合、該追加的デバイス情報を抽出するステップと、
前記要求情報、および前記探索するステップで抽出された追加的デバイス情報を、前記デバイスの前記ＩＰアドレスに関連づけてキャッシュするステップと、
を含む要求情報を抽出する方法。
【請求項２】
前記取得された情報文字列はＳＧＭＬベースの情報文字列である請求項１に記載の要求情報を抽出する方法。
【請求項３】
前記要求情報は前記デバイスに関連するベンダ情報であり、前記追加的デバイス情報は前記デバイスに関連するモデル情報である請求項１に記載の要求情報を抽出する方法。
【請求項４】
前記取得された情報文字列はＨＴＭＬベースの情報文字列である請求項２に記載の要求情報を抽出する方法。
【請求項５】
前記取得された情報文字列はＸＭＬベースの情報文字列である請求項２に記載の要求情報を抽出する方法。
【請求項６】
前記取得された情報文字列はタイトル文字列を含む請求項４に記載の要求情報を抽出する方法。
【請求項７】
前記要求情報を抽出するステップは、
前記情報文字列を解析して、ベンダ情報を取得するステップ、前記ベンダ情報をサポート対象ベンダのリストと比較するステップを含む請求項１に記載の要求情報を抽出する方法。
【請求項８】
ネットワークに通信可能に結合したリモート被監視デバイスに関連する要求情報を抽出するシステムであって、
ＨＴＴＰプロトコルをサポートするように構成され、前記デバイスに関連する情報を抽出するためにＨＴＴＰプロトコルによって使用される情報を格納するデータベースと、
ＨＴＴＰプロトコルおよび前記デバイスのＩＰアドレスを用いて前記デバイスにアクセスすることによって前記デバイスに関連する情報文字列を取得するように構成されたハードウェアアクセスモジュールと、
前記情報文字列から前記要求情報を抽出するために前記情報文字列を処理し、前記情報文字列内で追加的な非要求デバイス情報を探索し、該追加的デバイス情報が見つかった場合、該追加的デバイス情報を抽出するように構成されたプロセッサと、
前記要求情報、および前記プロセッサによって抽出された追加的デバイス情報を、前記デバイスの前記ＩＰアドレスに関連づけて格納するように構成されたキャッシュと、
を備える要求情報を抽出するシステム。
【請求項９】
前記取得された情報文字列はＳＧＭＬベースの情報文字列である請求項８に記載の要求情報を抽出するシステム。
【請求項１０】
前記要求情報は前記デバイスに関連するベンダ情報であり、前記追加的デバイス情報は前記デバイスに関連するモデル情報である請求項８に記載の要求情報を抽出するシステム。
【請求項１１】
前記取得された情報文字列はＨＴＭＬベースの情報文字列である請求項９に記載の要求情報を抽出するシステム。
【請求項１２】
前記取得された情報文字列はＸＭＬベースの情報文字列である請求項９に記載の要求情報を抽出するシステム。
【請求項１３】
前記取得された情報文字列はタイトル文字列を含む請求項１１に記載の要求情報を抽出するシステム。
【請求項１４】
前記プロセッサは、前記情報文字列を解析することによってベンダ情報を取得し、該ベンダ情報をサポート対象ベンダのリストと比較するように構成される請求項８に記載の要求情報を抽出するシステム。
【請求項１５】
ネットワークに通信可能に結合したリモート被監視デバイスに関連する要求情報を抽出するためのコンピュータ使用可能媒体を有するコンピュータプログラム製品であって、
前記デバイスのＩＰアドレスを取得する命令と、
ＨＴＴＰプロトコルおよび前記ＩＰアドレスを用いて前記デバイスにアクセスする命令であって、それによって前記デバイスに関連する情報文字列を取得する、アクセスする命令と、
前記情報文字列から前記要求情報を抽出する命令と、
前記情報文字列内で追加的な非要求デバイス情報を探索する、かつ該追加的デバイス情報が見つかった場合、該追加的デバイス情報を抽出する命令と、
前記要求情報、および前記探索するステップで抽出された追加的デバイス情報を、前記デバイスの前記ＩＰアドレスに関連づけてキャッシュする命令と、
を備えるコンピュータプログラム製品。
【請求項１６】
ネットワークに通信可能に結合したリモート被監視デバイスに関連する要求情報を抽出するシステムであって、
前記デバイスのＩＰアドレスを取得する手段と、
ＨＴＴＰプロトコルおよび前記ＩＰアドレスを用いて前記デバイスにアクセスし、前記デバイスに関連する情報文字列を取得するする手段と、
前記情報文字列から前記要求情報を抽出する手段と、
前記情報文字列内で追加的な非要求デバイス情報を探索し、該追加的デバイス情報が見つかった場合、該追加的デバイス情報を抽出する手段と、
前記要求情報、および前記探索するステップで抽出された追加的デバイス情報を、前記デバイスの前記ＩＰアドレスに関連づけてキャッシュする手段と、
を備える要求情報を抽出するシステム。
【請求項１７】
ネットワークに通信可能に結合した別個のデバイスのうちのリモート被監視デバイスに関連するステータス情報を抽出するために複数の通信プロトコルに対して使用されるように構成された情報を格納する方法であって、
前記複数の通信プロトコルのうちから通信プロトコルを選択するステップと、
前記選択された通信プロトコルを用いて前記デバイスにアクセスするための情報が内部ストレージテーブルに格納されているかどうかを判断するステップと、
前記判断するステップが、前記選択された通信プロトコルを用いて前記デバイスにアクセスするための前記情報が前記内部ストレージテーブルに格納されていないと判断する場合、外部情報ストレージユニットにアクセスして、前記選択された通信プロトコルを用いて前記デバイスにアクセスするための前記情報を取得するステップと、
前記外部情報ストレージユニットから取得された、前記選択された通信プロトコルを用いて前記デバイスにアクセスするための前記情報を、前記内部ストレージテーブルに格納するステップと、
を含む情報を格納する方法。
【請求項１８】
前記選択された通信プロトコルに対する情報は、前記ネットワークに通信可能に結合した前記別個のデバイスのそれぞれに対する共通の情報を抽出するための情報を含む請求項１７に記載の情報を格納する方法。
【請求項１９】
前記選択された通信プロトコルに対する情報は、前記別個のデバイスのうち、共通のベンダからのデバイスに対する共通の情報を抽出するための情報を含む請求項１７に記載の情報を格納する方法。
【請求項２０】
前記選択された通信プロトコルに対する情報は、前記別個のデバイスのうち、共通のベンダおよびモデル情報を有するデバイスに対する共通の情報を抽出するための情報を含む請求項１７に記載の情報を格納する方法。
【請求項２１】
前記選択された通信プロトコルは、ＨＴＭＬ／ＸＭＬプロトコルおよびＳＮＭＰプロトコルのいずれかである請求項１７に記載の情報を格納する方法。
【請求項２２】
ネットワークに通信可能に結合した別個のデバイスのうちのリモート被監視デバイスに関連するステータス情報を抽出するために複数の通信プロトコルに対して使用されるように構成された情報を効率的に格納するシステムであって、
複数の通信プロトコルをサポートするように構成された情報ストレージユニットであって、該複数の通信プロトコルのうちの選択された通信プロトコルのために使用される情報を格納する情報ストレージユニットと、
前記複数の通信プロトコルを用いて前記デバイスにアクセスするための情報を格納するように構成されたストレージテーブルと、
前記選択された通信プロトコルを用いて前記デバイスにアクセスするための情報が前記ストレージテーブルに格納されているかどうかを判断し、前記選択された通信プロトコルを用いて前記デバイスにアクセスするための情報が前記ストレージテーブルに格納されていないと判断する場合に、前記情報ストレージユニットにアクセスすることによって前記選択された通信プロトコルを用いて前記デバイスにアクセスするための情報を取得するように構成されたプロセッサと、
を備え、
前記プロセッサは、前記情報ストレージユニットから取得された前記デバイスにアクセスするための前記情報を前記ストレージテーブルに格納するように構成される、
情報を格納するシステム。
【請求項２３】
前記選択された通信プロトコルに対する情報は、前記ネットワークに通信可能に結合した前記別個のデバイスのそれぞれに対する共通の情報を抽出するための情報を含む請求項２２に記載の情報を格納するシステム。
【請求項２４】
前記選択された通信プロトコルに対する情報は、前記別個のデバイスのうち、共通のベンダからのデバイスに対する共通の情報を抽出するための情報を含む請求項２２に記載の情報を格納するシステム。
【請求項２５】
前記選択された通信プロトコルに対する情報は、前記別個のデバイスのうち、共通のベンダおよびモデル情報を有するデバイスに対する共通の情報を抽出するための情報を含む請求項２２に記載の情報を格納するシステム。
【請求項２６】
前記情報ストレージユニットは、ＨＴＭＬ／ＸＭＬプロトコル、ＳＮＭＰプロトコル、または該プロトコルの両方で前記デバイスにアクセスするために前記プロセッサによって使用される情報を格納するように構成される請求項２２に記載の情報を格納するシステム。
【請求項２７】
ネットワークに通信可能に結合した別個のデバイスのうちのリモート被監視デバイスに関連するステータス情報を抽出するために複数の通信プロトコルに対して使用されるように構成された情報を効率的に格納するためのコンピュータ使用可能媒体を有するコンピュータプログラム製品であって、
前記複数の通信プロトコルのうちから通信プロトコルを選択する命令と、
前記選択された通信プロトコルを用いて前記デバイスにアクセスするための情報が内部ストレージテーブルに格納されているかどうかを判断する命令と、
前記判断するステップが、前記選択された通信プロトコルを用いて前記デバイスにアクセスするための前記情報が前記内部ストレージテーブルに格納されていないと判断する場合、外部情報ストレージユニットにアクセスする命令であって、それによって、前記選択された通信プロトコルを用いて前記デバイスにアクセスするための前記情報を取得する、アクセスする命令と、
前記外部情報ストレージユニットから取得された、前記選択された通信プロトコルを用いて前記デバイスにアクセスするための前記情報を、前記内部ストレージテーブルに格納する命令と、
を備えるコンピュータプログラム製品。
【請求項２８】
ネットワークに通信可能に結合した別個のデバイスのうちのリモート被監視デバイスに関連するステータス情報を抽出するために複数の通信プロトコルに対して使用されるように構成された情報を効率的に格納するシステムであって、
前記複数の通信プロトコルのうちから通信プロトコルを選択する手段と、
前記選択された通信プロトコルを用いて前記デバイスにアクセスするための情報が内部ストレージテーブルに格納されているかどうかを判断する手段と、
前記判断する手段が、前記選択された通信プロトコルを用いて前記デバイスにアクセスするための前記情報が前記内部ストレージテーブルに格納されていないと判断する場合、外部情報ストレージユニットにアクセスして、前記選択された通信プロトコルを用いて前記デバイスにアクセスするための前記情報を取得する手段と、
前記外部情報ストレージユニットから取得された、前記選択された通信プロトコルを用いて前記デバイスにアクセスするための前記情報を、前記内部ストレージテーブルに格納する手段と、
を備える情報を格納するシステム。
【請求項２９】
情報文字列を解析することによって、ネットワークに通信可能に結合したリモート被監視デバイスに関連する要求情報を抽出する、情報文字列を解析する方法であって、
ＨＴＴＰプロトコルを用いて前記デバイスにアクセスして、前記デバイスに関連する情報文字列を取得する、アクセスするステップと、
前記要求情報のタイプに基づいて、前記デバイスから前記要求情報を最適に抽出するためのデータ抽出情報を判定するステップと、
前記データ抽出情報に従って前記情報文字列を解析して、前記情報文字列内のサブ文字列を識別するステップと、
前記情報文字列、識別されたサブ文字列、および前記データ抽出情報に基づいて前記要求情報を判定するステップと、
を含む情報文字列を解析する方法。
【請求項３０】
前記データ抽出情報は、前記デバイスから前記要求情報を最適に抽出するためのキーワード、タイプ、および位置情報を含む請求項２９に記載の情報文字列を解析する方法。
【請求項３１】
前記要求情報を判定するステップは、有限状態機械の方法を用いて、前記データ抽出情報および前記識別されたサブ文字列に基づいて、前記情報文字列から前記要求情報を抽出することを含む請求項２９に記載の情報文字列を解析する方法。
【請求項３２】
前記解析するステップは、前記情報文字列のうちＨＴＭＬスクリプトに関連する部分を無視するステップを含む請求項２９に記載の情報文字列を解析する方法。
【請求項３３】
情報文字列を解析することによって、ネットワークに通信可能に結合したリモート被監視デバイスに関連する要求情報を抽出する、情報文字列を解析するシステムであって、
前記デバイスから前記要求情報を最適に抽出するためのデータ抽出情報を格納するように構成されたデータ抽出テーブルと、
ＨＴＴＰプロトコルを用いて前記デバイスにアクセスすることによって前記デバイスに関連する情報文字列を取得し、前記要求情報のタイプに基づいて前記データ抽出テーブルから前記データ抽出情報を取得するように構成されたプロセッサと、
を備え、
前記プロセッサは、前記データ抽出情報に従って前記情報文字列を解析することによって前記情報文字列内のサブ文字列を識別し、前記情報文字列、識別されたサブ文字列、および前記データ抽出情報に基づいて前記要求情報を判定するように構成される、
情報文字列を解析するシステム。
【請求項３４】
前記データ抽出情報は、前記デバイスから前記要求情報を最適に抽出するためのキーワード、タイプ、および位置情報を含む請求項３３に記載の情報文字列を解析するシステム。
【請求項３５】
前記プロセッサは、有限状態機械の方法を用いて、前記データ抽出情報および前記識別されたサブ文字列に基づいて、前記情報文字列から前記要求情報を抽出するように構成される請求項３３に記載の情報文字列を解析するシステム。
【請求項３６】
前記プロセッサは、前記情報文字列のうちＨＴＭＬスクリプトに関連する部分を無視するように構成される請求項３３に記載の情報文字列を解析するシステム。
【請求項３７】
情報文字列を解析することによって、ネットワークに通信可能に結合したリモート被監視デバイスに関連する要求情報を抽出する、情報文字列を解析するためのコンピュータ使用可能媒体を有するコンピュータプログラム製品であって、
ＨＴＴＰプロトコルを用いて前記デバイスにアクセスして、前記デバイスに関連する情報文字列を取得する命令と、
前記要求情報のタイプに基づいて、前記デバイスから前記要求情報を最適に抽出するためのデータ抽出情報を判定する命令と、
前記データ抽出情報に従って前記情報文字列を解析して、前記情報文字列内のサブ文字列を識別する命令と、
前記情報文字列、識別されたサブ文字列、および前記データ抽出情報に基づいて前記要求情報を判定する命令と、
を備えるコンピュータプログラム製品。
【請求項３８】
前記データ抽出情報は、前記デバイスから前記要求情報を最適に抽出するためのキーワード、タイプ、および位置情報を含む請求項３７に記載のコンピュータプログラム製品。
【請求項３９】
前記要求情報を判定する命令は、有限状態機械の方法を用いて、前記データ抽出情報および前記識別されたサブ文字列に基づいて、前記情報文字列から前記要求情報を抽出する命令を含む請求項３７に記載のコンピュータプログラム製品。
【請求項４０】
前記解析する命令は、
前記情報文字列のうちＨＴＭＬスクリプトに関連する部分を無視する命令、
を含む請求項３７に記載のコンピュータプログラム製品。
【請求項４１】
情報文字列を解析することによって、ネットワークに通信可能に結合したリモート被監視デバイスに関連する要求情報を抽出する、情報文字列を解析するシステムであって、
ＨＴＴＰプロトコルを用いて前記デバイスにアクセスして、前記デバイスに関連する情報文字列を取得する手段と、
前記要求情報のタイプに基づいて、前記デバイスから前記要求情報を最適に抽出するためのデータ抽出情報を判定する手段と、
前記データ抽出情報に従って前記情報文字列を解析して、前記情報文字列内のサブ文字列を識別する手段と、
前記情報文字列、識別されたサブ文字列、および前記データ抽出情報に基づいて前記要求情報を判定する手段と、
を備える情報文字列を解析するシステム。
【請求項４２】
ネットワークに通信可能に結合したリモート被監視デバイスに関連するステータス情報を抽出する方法であって、
複数の通信プロトコルのうちの第１通信プロトコルを用いて前記デバイスから取得されるべき要求第１ステータス値を決定するステップと、
前記複数の通信プロトコルのうちの第２通信プロトコルを用いて前記デバイスから取得されるべき要求第２ステータス値を決定するステップと、
前記デバイスにアクセスして、前記第１通信プロトコルを用いて前記要求第１ステータス値を抽出するステップと、
前記抽出された第１ステータス値をそれぞれの固有識別子と関連づけてデバイスステータスマップに格納するステップと、
前記第２通信プロトコルを用いて前記デバイスにアクセスして、前記要求第２ステータス値のうち前記デバイスステータスマップに格納されていないステータス値を抽出するステップと、
を含むステータス情報を抽出する方法。
【請求項４３】
前記第１通信プロトコルはＳＮＭＰであり、前記第２通信プロトコルはＨＴＴＰである請求項４２に記載のステータス情報を抽出する方法。
【請求項４４】
前記デバイスから取得されるべき前記要求第１ステータス値を第１データ構造体に格納するステップと、
前記デバイスから取得されるべき前記要求第２ステータス値を第２データ構造体に格納するステップと、
をさらに含む請求項４２に記載のステータス情報を効率的に抽出する方法。
【請求項４５】
前記第２通信プロトコルを用いて前記デバイスにアクセスするステップは、
前記第１通信プロトコルを用いて前記デバイスから前に抽出され、前記デバイスステータスマップに格納されている要求ステータス値を、前記第２データ構造体から削除するステップと、
前記第２通信プロトコルを用いて前記デバイスにアクセスして、前記第２データ構造体に登録されている前記要求第２ステータス値を抽出するステップと、
を含む請求項４４に記載のステータス情報を効率的に抽出する方法。
【請求項４６】
ネットワークに通信可能に結合したリモート被監視デバイスに関連するステータス情報を抽出するシステムであって、
複数の通信プロトコルのうちの第１通信プロトコルを用いて前記デバイスから取得されるべき要求第１ステータス値を格納するように構成された第１データ構造体と、
前記複数の通信プロトコルのうちの第２通信プロトコルを用いて前記デバイスから取得されるべき要求第２ステータス値を格納するように構成された第２データ構造体と、
（１）前記デバイスにアクセスすることによって前記第１通信プロトコルを用いて前記要求第１ステータス値を抽出し、（２）それぞれの抽出された第１ステータス値をそれぞれの固有識別子と関連づけてデバイスステータスマップに格納し、（３）前記第２通信プロトコルを用いて前記デバイスにアクセスすることによって前記要求第２ステータス値のうち前記デバイスステータスマップに格納されていないステータス値を抽出する、ように構成されたプロセッサと、
を備えるステータス情報を抽出するシステム。
【請求項４７】
前記第１通信プロトコルはＳＮＭＰであり、前記第２通信プロトコルはＨＴＴＰである請求項４６に記載のステータス情報を抽出するシステム。
【請求項４８】
前記プロセッサは、前記第１通信プロトコルを用いて前記デバイスから前に抽出され前記デバイスステータスマップに格納されている要求ステータス値を前記第２データ構造体から削除し、前記第２通信プロトコルを用いて前記デバイスにアクセスするによって前記第２データ構造体に登録されている前記要求第２ステータス値を抽出するようにさらに構成される請求項４６に記載のステータス情報を抽出するシステム。
【請求項４９】
ネットワークに通信可能に結合したリモート被監視デバイスに関連するステータス情報を効率的に抽出するためのコンピュータ使用可能媒体を有するコンピュータプログラム製品であって、
複数の通信プロトコルのうちの第１通信プロトコルを用いて前記デバイスから取得されるべき要求第１ステータス値を決定する命令と、
前記複数の通信プロトコルのうちの第２通信プロトコルを用いて前記デバイスから取得されるべき要求第２ステータス値を決定する命令と、
前記デバイスにアクセスして、前記第１通信プロトコルを用いて前記要求第１ステータス値を抽出する命令と、
それぞれの抽出された第１ステータス値をそれぞれの固有識別子と関連づけてデバイスステータスマップに格納する命令と、
前記第２通信プロトコルを用いて前記デバイスにアクセスして、前記要求第２ステータス値のうち前記デバイスステータスマップに格納されていないステータス値を抽出する命令と、
を備えるコンピュータプログラム製品。
【請求項５０】
前記第１通信プロトコルはＳＮＭＰであり、前記第２通信プロトコルはＨＴＴＰである請求項４９に記載のコンピュータプログラム製品。
【請求項５１】
前記デバイスから取得されるべき前記要求第１ステータス値を第１データ構造体に格納する命令と、
前記デバイスから取得されるべき前記要求第２ステータス値を第２データ構造体に格納する命令と、
をさらに備える請求項４９に記載のコンピュータプログラム製品。
【請求項５２】
前記第２通信プロトコルを用いて前記デバイスにアクセスする命令は、
前記第１通信プロトコルを用いて前記デバイスから前に抽出され、前記デバイスステータスマップに格納されている要求ステータス値を、前記第２データ構造体から削除する命令と、
前記第２通信プロトコルを用いて前記デバイスにアクセスして、前記第２データ構造体に登録されている前記要求第２ステータス値を抽出する命令と、
を含む請求項５１に記載のコンピュータプログラム製品。
【請求項５３】
ネットワークに通信可能に結合したリモート被監視デバイスに関連するステータス情報を抽出するシステムであって、
複数の通信プロトコルのうちの第１通信プロトコルを用いて前記デバイスから取得されるべき要求第１ステータス値を決定する手段と、
前記複数の通信プロトコルのうちの第２通信プロトコルを用いて前記デバイスから取得されるべき要求第２ステータス値を決定する手段と、
前記デバイスにアクセスして、前記第１通信プロトコルを用いて前記要求第１ステータス値を抽出する手段と、
それぞれの抽出された第１ステータス値をそれぞれの固有識別子と関連づけてデバイスステータスマップに格納する手段と、
前記第２通信プロトコルを用いて前記デバイスにアクセスして、前記要求第２ステータス値のうち前記デバイスステータスマップに格納されていないステータス値を抽出する手段と、
を備えるステータス情報を効率的に抽出するシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネットワークに接続されたデバイスの監視技術に関する。特に、本発明は、複数のプロトコルを用いた、ネットワーク接続されたデバイスのリモート監視のための情報抽出・格納・解析方法、システム、およびコンピュータプログラム製品に関する。
【０００２】
［関連出願への相互参照］
本出願は、以下の同一権利者による同時係属中の米国特許出願に関連する：
１．出願第０９／４５３，９３７号、名称：「Method  and  System  of  Remote  Diagnostic，Control，and  Information  Collection  using  a  Dynamic  Linked  Library  of  Multiple  Formats  and  Ｍultiple  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  of  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  of  Monitoring  Network  Connected  Devices  with  Multiple  Protocols」、出願日：２００３年２月２６日。
上記の米国特許および米国特許出願のそれぞれの開示は全体として参照により本明細書に援用される。
【背景技術】
【０００３】
一般的に知られているように、コンピュータシステムはハードウェアおよびソフトウェアを含む。ソフトウェアは、コンピュータシステムを構成するハードウェアコンポーネントを動作させ管理するために作成された命令のリストを含む。通常、コンピュータシステムは互いにインタフェースをとりあうさまざまなハードウェアコンポーネント／デバイスを含む。コンピュータシステムは、スタンドアロン型でもネットワーク接続型でもよい。ネットワーク接続型コンピュータシステムでは、複数の別個のデバイスがネットワークに接続されることにより、これらの別個のデバイス間の通信がネットワーク経由で可能としている（例えば、非特許文献１〜３参照）。
【０００４】
【非特許文献１】Goldfart，C.，The  SGML  Handbook，Clarendon  Press  (１９９０)
【非特許文献２】Castro，E.，HTML  for  the  World  Wide  Web，Peachpit  Press，Berkeley  (１９９６)
【非特許文献３】Megginson，D.，Structuring  XML  Documents，Prentice  Hall，NJ  (１９９８)
【発明の開示】
【発明が解決しようとする課題】
【０００５】
ネットワーク接続型コンピュータシステムにおいて、ハードウェアデバイスを動作させるソフトウェアは、ハードウェアデバイス間の通信を可能にするために、ハードウェアデバイスが協調的に機能することができるように構成されなければならない。さらに、このような通信を容易にする目的で、各ハードウェアデバイスが効率的に機能していることを保証するために、ハードウェアデバイスが監視され、各ハードウェアデバイスのステータスが識別されることも望ましい。
【０００６】
ここで、複数の別個のデバイスまたはハードウェアデバイスを制御し、構成し、または監視しているハードウェアデバイスを監視デバイスと呼び、監視デバイスによって制御され、構成され、または監視されているハードウェアデバイスを「被監視デバイス」と呼ぶことにする。
【０００７】
ネットワーク上に配置されるハードウェアデバイスについて、これらのデバイスが保守、使用等の目的で監視されることが望ましい。しかし、ハードウェアデバイスおよびインタフェースに関連する製造元の相違を考えると、監視デバイスが、ネットワークに接続された種々の他のデバイスと通信することは困難なことがある。このような欠点は、ネットワークに接続されたデバイスのパフォーマンスおよび効率に関する重大な情報をネットワーク管理者が取得するのを妨げる可能性が非常に高い。
【０００８】
Simple  Network  Management  Protocol（ＳＮＭＰ）は今日、データ通信ネットワーク上のデバイス、電気通信システムおよび他のグローバルに到達可能なデバイスの監視および管理のための事実上の業界標準である。実際上、コンピュータおよび関連デバイスを取り扱うあらゆる組織は、ローカルエリアネットワークおよび広域ネットワークを越えてそれぞれのそのようなデバイスを集中的に監視、診断、および構成することができることを期待している。ＳＮＭＰは、この相互作用を可能にするプロトコルである。
【０００９】
デバイスがＳＮＭＰリクエストに応答するためには、デバイスが適切にＳＮＭＰリクエストを解釈し、そのリクエストによって要求されるアクションを実行し、ＳＮＭＰリプライを生成することを可能にするソフトウェアをデバイスに装備することが望ましい。ＳＮＭＰエージェントソフトウェアは通常、ネットワークエンティティに存在するサブシステムソフトウェアモジュールである。
【００１０】
システムによって実施されるオブジェクトのコレクションは一般に管理情報ベース（ＭＩＢ）と呼ばれる。ＭＩＢは、デバイスの監視に関連する情報を有するデータベースであってもよい。他のＭＩＢの例としては、いくつか列挙すれば、イーサネットインタフェースを中心に扱うイーサネットＭＩＢ、８０２．１Ｄブリッジの管理のためのオブジェクトを定義するブリッジＭＩＢがある。
【００１１】
デバイスを監視するためにＳＮＭＰを使用することは困難である。というのは、プライベートＭＩＢは、有効なキーなしに解読するのが難しい値を含むからである。会社のネットワークに接続された種々のデバイスを監視するためにＳＮＭＰを使用している会社は、会社の機密情報として保持される固有の識別子／キーを作成する。たいてい、その結果は２進または整数値として表示される。したがって、ＳＮＭＰを使用する場合、監視されているデバイス（「被監視デバイス」）から受信される結果は、ユーザに理解可能な形で被監視デバイスのステータスをユーザに提供することができない。
【００１２】
また、ＳＮＭＰを使用する場合、２進または整数値として取得された結果を解読するために、有効なキーまたはプライベートＭＩＢへのアクセスなしに被監視デバイスに関する詳細な情報を取得することは困難である。さらに、所与のプロトコル（例えばＳＮＭＰまたはＨＴＴＰ／ＨＴＭＬ）が、タイムアウトやロストパケットのような種々の理由で失敗するかもしれない。したがって、デバイスの監視が、障害に応答して複数のプロトコルを用いて順次遂行される場合、複数のプロトコルを用いて所与のデバイスから抽出される一部の情報が各プロトコルに対して複製されるかもしれない。よって、デバイスからのデータの抽出がこのような状況で適切に管理されない場合、一部のプロトコルが他のプロトコルより多くのリソースを要求するために、時間およびメモリの効率が悪くなる。さらに、一部のプロトコルを用いた情報抽出は、他のプロトコルを用いた場合よりもはるかに少ない処理およびメモリしか必要としないかもしれない。
【課題を解決するための手段】
【００１３】
本発明のシステムおよび方法は、ネットワークに接続されたデバイスの監視を可能にすることによって上記の問題の解決を図る。したがって、ネットワークに通信可能に結合した別個のデバイスのうちの１つのデバイスを監視する方法が記述される。
【００１４】
本方法は、ハードウェアアクセスモジュール経由で第１データベースにアクセスすることを含む。第１データベースは、複数の通信プロトコルをサポートするように構成される。第１データベースには、被監視デバイスの製造元およびモデル情報のような種々の情報を取得するために、複数の通信プロトコルによって使用される情報が格納される。通信プロトコルが複数の通信プロトコルから選択される。選択される通信プロトコルは、被監視デバイスからステータス情報を受信するように構成される。本方法はさらに、選択された通信プロトコルおよび第１データベースからの情報を用いて被監視デバイスにアクセスすること、アクセスされたデバイスからステータス情報を受信すること、および受信したステータス情報を第２データベース（DeviceODBC）に格納することを含む。
【００１５】
１つの実施形態では、本発明は、ネットワークに通信可能に結合した別個のデバイスのうちの１つのデバイスを監視する方法を提供する。被監視デバイスから情報を取り出すために複数の通信プロトコルを使用してもよい。例えば、被監視デバイスにアクセスするために、ＳＮＭＰプロトコルがまず選択され、ＳＮＭＰプロトコルを用いて効率的に取り出されるように構成されたデバイス情報が取得される。次に、ＳＮＭＰプロトコルを用いて効率的に取り出すことができなかった情報を取得するためにＨＴＴＰプロトコルが選択される。プロトコルの選択は、データベースに格納されたサポート情報を用いて、プロトコルマネージャによって実行される。
【００１６】
本発明では、監視システムが、例えばＬＡＮまたはＷＡＮのようなネットワークに接続された少なくとも１つのデバイス（被監視デバイス）を監視することを可能にする。被監視デバイスは、固有のＩＰアドレスを有するように構成される。被監視デバイスに割り当てられるＩＰアドレス、および被監視デバイスのベンダ／製造元の詳細が、データベースに格納される。ネットワークをスキャンし、デバイスに問合せをすることによって、デバイスのＩＰアドレスを取得することができる。このような方法は既知である。したがって、監視されるべきデバイスのＩＰアドレスは既に獲得され、データベースに格納されていると仮定する。
【００１７】
本発明は、被監視デバイスから受信されるＨＴＭＬ情報から必要な情報を抽出する方法を指定する。被監視デバイスのウェブページ位置に（すなわち、ＩＰアドレスおよび指定されたポートを通じて）アクセスすると、被監視デバイスに対応する特定のウェブページが表示される。ウェブページ内の情報は、キーおよび値の対の形態である。例えば、トナーレベルは、カラープリンタウェブページ内に「Black  100%」として示されるかもしれない。ウェブページ内の情報から要求情報を取り出すために、ＨＴＭＬ／ＸＭＬパーサを用いてページを解析する。ＨＴＭＬ／ＸＭＬパーサを用いてウェブページから抽出された要求情報およびパラメータ値はDeviceODBCデータベースに格納される。
【００１８】
本発明の一態様では、ネットワーク接続された別個のデバイスのうちの１つのデバイスを監視する方法が記述される。本方法は、ハードウェアアクセスモジュール経由で第１データベースにアクセスすることを含む。第１データベースは複数の通信プロトコルをサポートするように構成される。第１データベースには、被監視デバイスの製造元およびモデル情報等の種々の情報を判定するために、複数の通信プロトコルによって使用される情報が格納される。通信プロトコルが複数の通信プロトコルから選択される。選択される通信プロトコルは、被監視デバイスからステータス情報等の種々の情報を受信するために使用される。本方法はさらに、選択された通信プロトコルおよび第１データベースからの情報を用いて被監視デバイスにアクセスすること、アクセスされたデバイスからステータス情報を受信すること、および受信したステータス情報を第２データベースに格納することを含む。
【００１９】
本発明のもう１つの態様では、ネットワークに通信可能に結合した別個のデバイスのうちの１つのデバイスを監視するシステムが提供される。本システムは、複数の通信プロトコルをサポートするように構成された第１データベースを含む。第１データベースは、デバイスに関する情報を抽出するために複数の通信プロトコルによって使用される情報を有する。デバイスは、デバイスから製造元、モデル、固有ＩＤ、およびステータス情報のような種々の情報を受信するために複数の通信プロトコルから選択される通信プロトコルを用いてアクセスされる。その通信プロトコルをサポートする第１データベースからの情報も使用される。本システムはさらに、データ文字列の形態でデバイスからステータス情報を受信するハードウェアアクセスモジュールと、第１データベースからの情報を用いてデバイスのステータス情報値を抽出するためにデータ文字列を処理するプロセッサと、抽出されたステータス情報値を格納する第２データベースとを含む。
【００２０】
本発明はまた、本明細書に記載されるような監視システムによってサポートされる被監視デバイスの種々のベンダおよびデバイスモデルも識別する。被監視デバイスの種々のベンダがベンダ固有の方法で被監視デバイスに関する情報を提示するので、本発明は、被監視デバイスのベンダおよびモデルの識別が、被監視デバイスの動作ステータスを決定することを可能にする。
【００２１】
本発明の一態様によれば、ネットワークに通信可能に結合したリモート被監視デバイスに関連する要求情報を抽出する方法、システム、およびコンピュータプログラム製品が提供される。これは、（１）デバイスのＩＰアドレスを取得すること、（２）ＨＴＴＰプロトコルおよびＩＰアドレスを用いてデバイスにアクセスすることであって、それによって、デバイスに関連する情報文字列を取得する、アクセスすること、（３）情報文字列から要求情報を抽出すること、（４）情報文字列から追加的デバイス情報を抽出すること（ここで追加的デバイス情報は要求されなかった情報である）、および（５）要求情報、追加的デバイス情報、およびＩＰアドレスをキャッシュすることを含む。
【００２２】
本発明のさらなる態様によれば、ネットワークに通信可能に結合した別個のデバイスのうちのリモート被監視デバイスに関連するステータス情報を抽出するために複数の通信プロトコルによって使用されるように構成された情報を効率的に格納する方法、システム、およびコンピュータプログラム製品が提供される。これは、（１）複数の通信プロトコルのうちから通信プロトコルを選択すること、（２）選択された通信プロトコルに対する情報が内部ストレージテーブルに格納されているかどうかを判断すること、（３）判断するステップが、選択された通信プロトコルを用いてデバイスにアクセスするための情報が内部ストレージテーブルに格納されていないと判断する場合、外部情報ストレージユニットにアクセスすることであって、それによって、選択された通信プロトコルを用いてデバイスにアクセスするための情報を取得する、アクセスすること、および（４）判断するステップが、選択された通信プロトコルを用いてデバイスにアクセスするための情報が内部ストレージテーブルに格納されていると判断した場合、内部ストレージテーブルにアクセスすることであって、それによって、選択された通信プロトコルを用いてデバイスにアクセスするための情報を取得する、アクセスすることを含む。
【００２３】
本発明のもう１つの態様によれば、情報文字列を解析してネットワークに通信可能に結合したリモート被監視デバイスに関連する要求情報を抽出する方法、システム、およびコンピュータプログラム製品が提供される。これは、（１）ＨＴＴＰプロトコルを用いてデバイスにアクセスすることであって、それによって、デバイスに関連する情報文字列を取得する、アクセスすること、（２）要求情報のタイプに基づいて、デバイスから要求情報を最適に抽出するためのデータ抽出情報を判定すること、（３）データ抽出情報に従って情報文字列を解析することであって、それによって、情報文字列内のサブ文字列を識別する、解析すること、および（４）情報文字列、識別されたサブ文字列、およびデータ抽出情報に基づいて要求情報を判定することを含む。
【００２４】
本発明のさらにもう１つの態様によれば、ネットワークに通信可能に結合したリモート被監視デバイスに関連するステータス情報を効率的に抽出する方法、システム、およびコンピュータプログラム製品が提供される。これは、（１）複数の通信プロトコルのうちの第１通信プロトコルを用いてデバイスから取得されるべき要求第１ステータス値を判定すること、（２）複数の通信プロトコルのうちの第２通信プロトコルを用いてデバイスから取得されるべき要求第２ステータス値を判定すること、（３）デバイスにアクセスすることであって、それによって、第１通信プロトコルを用いて要求第１ステータス値を抽出する、アクセスすること、（４）それぞれの抽出された第１ステータス値をそれぞれの固有識別子と関連づけてデバイスステータスマップに格納すること、および（５）第２通信プロトコルを用いてデバイスにアクセスすることであって、それによって、要求第２ステータス値のうちデバイスステータスマップに格納されていないステータス値を抽出する、アクセスすることを含む。
【００２５】
本発明のさらに完全な理解と、本発明に付随する利点の多くは、以下の詳細な説明を添付図面とともに考察して参照することによって本発明がより一層理解されるようになるとともに、容易に得られるであろう。
【発明を実施するための最良の形態】
【００２６】
図１は、種々のデバイスと、デバイスの動作を監視、診断、および制御するコンピュータとを有する概略図を示している。具体的には、図１は、コンピュータワークステーション１７、１８、２０、および２２に接続されたローカルエリアネットワーク（ＬＡＮ）のような第１ネットワーク１６を含む。ワークステーションは、例えばパーソナルコンピュータデバイス、Ｕｎｉｘベースのコンピュータ、Ｌｉｎｕｘベースのコンピュータ、またはＡｐｐｌｅ  Ｍａｃｉｎｔｏｓｈ等の、いかなるタイプのコンピュータであってもよい。ネットワーク１６には、デジタル画像形成装置２４、ファクシミリ機２８、およびプリンタ３２も接続されている。デジタル画像形成装置２４およびファクシミリ機２８の２つ以上のコンポーネントを組み合わせて、統合された「画像形成装置」としてもよいということが当業者には理解されよう。例えば、画像形成装置２４、ファクシミリ機２８、プリンタ３２、ならびにワークステーション１７、１８、２０、および２２は、マシンまたは被監視デバイスと呼ばれてもよい。いくつかの構成では、１つまたは複数のワークステーションが事務用機器へと転換されてもよい。さらに、いかなるネットワーク事務用機器／デバイスがネットワーク１６に取り付けられてもよい。
【００２７】
このような事務用機器の一例として、Ricoh  Corporationから販売されているｅＣａｂｉｎｅｔ（登録商標）がある。また、ファクシミリサーバ（図示せず）がネットワーク１６に接続され、電話、ケーブル、または無線接続を有していてもよい。デジタル画像形成装置２４、ファクシミリ機２８、およびプリンタ３２のそれぞれは、ネットワーク１６に接続されていることに加えて、それぞれ従来の電話および／またはケーブルおよび／または無線接続２６、３０、および３４を含んでもよい。以下で説明するように、被監視デバイス２４、２８、および３２は、例えばネットワーク１６経由でインターネットを通じて、または直接の電話、無線、もしくはケーブル接続によって、監視デバイスとも呼ばれるリモート監視・診断・制御ステーションと通信する。
【００２８】
もう１つの例示的なビジネス環境では、被監視デバイスは、多機能イメージングデバイス、スキャナ、プロジェクタ、会議システム、およびシュレッダのようなデバイスを含んでもよい。もう１つの応用例として、ネットワーク１６はホームネットワークであってもよく、その場合、被監視デバイスは計器（電気、ガス、水道）または例えば電子レンジ、洗濯機、乾燥機、皿洗い機、家庭用娯楽システム、冷蔵庫、炊飯器、ヒータ、エアコン、湯沸器、セキュリティカメラのような機器である。
【００２９】
図１で、広域ネットワーク（ＷＡＮ）（例えばインターネットまたはその後継）が包括的に１０で示されている。ＷＡＮ１０は、プライベートＷＡＮ、パブリックＷＡＮ、または混成型のいずれでもよい。ＷＡＮ１０は、１２Ａ〜１２Ｉで示される複数の相互接続されたコンピュータおよびルータを含む。ＷＡＮを通じて通信する方法は、Internet  Engineering  Task  Force（ＩＥＴＦ）からwww．Ietf．org/rfc．htmlで入手可能な一連のRequest  for  Comments（ＲＦＣ）文書を通じて既知であり、これには、「Simple  Mail  Transfer  Protocol」と題するＲＦＣ８２１；「Standard  for  the  Format  of  ARPA  Internet  Text  Message」と題するＲＦＣ８２２；「File  Transfer  Protocol  (FTP)」と題するＲＦＣ９５９；「Multipurpose  Internet  Mail  Extensions（MIME）Part  One：Format  of  Internet  Message  Bodies」と題するＲＦＣ２０４５；「An  Extensible  Message  Format  for  Delivery  Status  Notifications」と題するＲＦＣ１８９４；「Post  Office  protocol−Version  3」と題するＲＦＣ１９３９；「Hypertext  Transfer  Protocol−HTTP/1．1」と題するＲＦＣ２０６８；および「An  Extensible  Message  Format  for  Message  Disposition  Notifications」と題するＲＦＣ２２９８がある。これらの参考文献のそれぞれの内容は参照により本明細書に援用される。
【００３０】
Transmission  Control  Protocol/Internet  Protocol（ＴＣＰ／ＩＰ）関連の通信は、例えば、Addison-Wesley  Publishing  Companyから１９９４年に出版された、W．R．Stevens著の書籍「TCP/IP  Illustrated」，Vol．1，The  Protocols、に記載されており、その内容全体が参照により本明細書に援用される。ComerとStevensによる「Internetworking  with  TCP/IP」の第１〜３巻もまた全体として参照により本明細書に援用される。
【００３１】
図１の説明を続けると、ファイアウォール５０ＡがＷＡＮ１０とネットワーク１６の間に接続されている。ファイアウォールは、ファイアウォールの一方の側にある権限のあるコンピュータのみが、ファイアウォールの他方の側にあるネットワーク、コンピュータ、または個別部分にアクセスすることを可能にするデバイスである。ファイアウォールは既知の市販のデバイスおよび／またはソフトウェアである（例えば、Zone  Labsから販売されているＺｏｎｅＡｌａｒｍ）。同様に、ファイアウォール５０Ｂおよび５０Ｃは、ＷＡＮ１０をそれぞれネットワーク５２およびワークステーション４２から分離する。ファイアウォールについてさらに詳細には、W，R，Cheswick，and  S．M．Bellovin著「Firewalls  and  Internet  Security」，1994，Addison  Wesley  Publishing、およびD．B．Chapman  and  E．D．Zwicky著「Building  Internet  Firewalls」，1995，O’Reilly  &  Associates，Inc、に見ることができる。これらの２つの参考文献の内容全体が参照により本明細書に援用される。
【００３２】
ネットワーク５２は従来のネットワークであり、複数のワークステーション５６、６２、６８、および７４を含む。これらのワークステーションは、単一の会社内の異なる部門（例えば、営業、製造、設計技術、および顧客サービス部門）内に分散して配置されてもよい。ネットワーク５２経由で接続されるワークステーションに加えて、ネットワーク５２に直接接続されていないワークステーション４２も提供される。ワークステーション４２に接続されたディスク４６に格納されているデータベース内の情報は、適当な暗号化およびプロトコルを用いてＷＡＮ１０を通じて、ネットワーク５２に直接接続されたワークステーションと共有されてもよい。また、ワークステーション４２は、電話回線および／またはケーブルネットワークおよび／または無線ネットワーク４４への直接接続を含み、ディスク４６内のデータベースは、電話回線、ケーブルネットワークを通じて、または無線ネットワーク４４経由でアクセスされてもよい。本発明によって使用されるケーブルネットワークは、通常はテレビ番組を伝送するために使用されるケーブルネットワーク、通常はコンピュータ等で使用されるデジタルデータの高速通信用に提供されるケーブル、またはいかなる他の所望のタイプのケーブルを用いて実施されてもよい。
【００３３】
もう１つの実施形態では、ワークステーション４２は、ネットワーク機能付きのラップトップコンピュータ、ＰＤＡ、パームトップコンピュータ、または携帯電話機であってもよい。これらのデバイスは、ディスク４６に格納されたデータベースに格納されている情報にアクセスするために使用されてもよい。
【００３４】
事務用マシン、業務用デバイスまたは事務用機器２４、２８、および３２に関連する情報はそれぞれ、ディスク４６、５４、５８、６４、７０、および７６に格納された１つまたは複数のデータベースに格納されてもよい。既知のデータベースとしては（１）Microsoft、IBM、Oracle、およびSybaseによるＳＱＬデータベース；（２）他の関係データベース；ならびに（３）非関係データベース（Objectivity、JYD  Software  Engineering、およびOrient  Ｔechnologiesから販売されているオブジェクト指向データベース等）がある。顧客サービス、営業、製造、および技術部門のそれぞれが、自己の固有のデータベースを有してもよく、あるいは１つまたは複数のデータベースを共有してもよい。データベースを格納するために使用される各ディスクは、ハードディスクまたは光ディスクのような不揮発性メモリである。別法として、データベースは、固体および／または半導体メモリデバイス等のいかなるストレージデバイスに格納されてもよい。例えば、ディスク６４に営業データベースが格納され、ディスク５８に製造データベースが格納され、ディスク７０に技術データベースが格納され、ディスク７６に顧客サービスデータベースが格納されてもよい。別法として、ディスク５４および４６に、１つまたは複数のデータベースが格納されてもよい。
【００３５】
ワークステーション５６、６２、６８、７４、および４２がＷＡＮ１０に接続されることに加えて、これらのワークステーションは、監視、診断、および／または制御されるマシン／デバイスへの安全な接続を提供するために、電話回線、ケーブル、または無線ネットワークへの接続を含んでもよい。さらに、通信媒体の１つが正しく動作していない場合に、他の１つが通信のためにバックアップとして自動的に使用されてもよい。
【００３６】
本発明の特徴は、マシンを診断および制御するためにマシンとコンピュータ／監視システムの間の通信（例えばインターネット電子メール、本明細書ではＥメールともいう）または送信の「蓄積転送」モードを使用することである。別法として、送信されるメッセージは、ＦＴＰやHyper Text  Transfer  Protocol（ＨＴＴＰ）のような直接のエンドツーエンド接続（例えば、最終宛先へのソケット接続を用いて）を行う通信モードを用いて実施されてもよい。
【００３７】
図２は、図１に示したデジタル画像形成装置２４の機械的配置を示している。図２において、１０１はスキャナのためのファンであり、１０２はレーザプリンタで使用されるポリゴンミラーであり、１０３はレーザ（図示せず）からの光をコリメートするために使用されるＦθレンズを表す。参照番号１０４はスキャナからの光を検出するセンサを表す。参照番号１０５はスキャナからセンサ１０４への光の焦点を合わせるレンズを表し、参照番号１０６は光導電性ドラム１３２上の画像を消去するために使用されるクエンチングランプを表す。帯電コロナユニット１０７および現像ローラ１０８がある。参照番号１０９は、スキャンされるドキュメントを照明するために使用されるランプを表し、要素１１０、１１１、および１１２は、センサ１０４へ光を反射するミラーを表す。ドラムミラー１１３が、ポリゴンミラー１０２から発する光を光導電性ドラム１３２へ反射するために提供される。ファン１１４がデジタル画像形成装置の帯電領域を冷却するために使用され、第１給紙ローラ１１５が第１用紙カセット１１７から給紙するために使用され、参照番号１１６は手差しテーブルを表す。同様に、第２給紙ローラ１１８が第２カセット１１９とともに使用される。参照番号１２０はリレーローラを表し、１２１は見当合わせローラを表し、１２２は画像濃度センサを表し、１２３は転写／分離コロナユニットを表す。参照番号１２４はクリーニングユニットを表し、１２５は吸引ファンを表し、１２６は搬送ベルトを表し、１２７は圧力ローラを表し、１２８は出口ローラを表す。熱ローラ１２９がトナーを用紙上に定着させるために使用され、１３０は排気ファンを表し、主モータ１３１がデジタル画像形成装置２４を駆動するために使用される。
【００３８】
図３は、図２のデジタル画像形成装置２４の電子コンポーネントを示すブロック図である。ＣＰＵ１６０は、装置のコントローラとして作用するマイクロプロセッサである。ランダムアクセスメモリ（ＲＡＭ）１６２は、デジタル画像形成装置２４の動作パラメータを含む動的に変化する情報を格納する。不揮発性メモリ（例えば、読み出し専用メモリ（ＲＯＭ）１６４またはフラッシュメモリ）は、画像形成装置２４を記述する静的状態データ（例えば、複写機のモデル番号、シリアル番号、およびデフォルトパラメータ）とともに、デジタル画像形成装置を動作させるために使用されるプログラムコードを格納する。
【００３９】
マルチポートネットワークインタフェース１６６は、デジタル画像形成装置２４が少なくとも１つの通信ネットワークを通じて外部デバイスと通信することを可能にするために提供される。参照番号１６８は電話、またはケーブル回線を表し、番号１７０は、１６８で識別されるネットワークとは異なるもう１つのタイプのネットワークを表す。マルチポートネットワークインタフェースについてのさらなる詳細が図４に関して記載される。インタフェースコントローラ１７２は、操作パネル１７４をシステムバス１８６に接続するために使用される。操作パネル１７４は、デジタル画像形成装置２４に見られる標準的な入出力デバイスを含み、これには複写ボタンや、例えば複写枚数、拡大縮小、濃淡等のような画像形成装置の動作を制御するためのキーが含まれる。さらに、デジタル画像形成装置２４のパラメータおよびメッセージをユーザに対して表示するために、液晶ディスプレイが操作パネル１７４内に含まれてもよい。
【００４０】
ローカル接続インタフェース１７１は、ＲＳ２３２、パラレルプリンタポート、ＵＳＢ、およびＩＥＥＥ１３９４のようなローカルポートを通じての接続である。FireWire（ＩＥＥＥ１３９４）は、Wickelgren，I．著「The  Facts  About  FireWire」，IEEE  Spectrum，April  1997，Vol．34，Number  4，pp．19−25、に記載されており、その内容全体が参照により本明細書に援用される。好ましくは、誤り検出および再送を含む「信頼性のある」通信プロトコルが使用される。
【００４１】
ストレージインタフェース１７６は、ストレージデバイスをシステムバス１８６に接続する。例えば、ストレージデバイスとしては、フラッシュメモリ１７８（これは、従来の電気的消去可能プログラム可能読み出し専用メモリ（ＥＥＰＲＯＭ）によって置換可能である）、およびディスク１８２がある。ディスク１８２は、ハードディスク、光ディスク、および／またはフロッピーディスクドライブのいずれでもよい。追加的なメモリデバイスが、接続１８０経由でデジタル画像形成装置２４に接続されてもよい。フラッシュメモリ１７８は、デジタル画像形成装置２４の寿命にわたってあまり頻繁に変化しない装置２４のパラメータを記述する準静的状態データを格納するために使用される。このようなパラメータとしては、例えば、デジタル画像形成装置のオプションおよびコンフィグレーションがある。オプションインタフェース１８４は、外部インタフェースのような追加的ハードウェアがデジタル画像形成装置２４に接続されることを可能にする。クロック／タイマ１８７は、日時を追跡するとともに経過時間を測定するために利用される。
【００４２】
図３は、デジタル画像形成装置２４を構成する種々のセクションも示している。参照番号２０２はソータを表し、デジタル画像形成装置２４の出力をソートするために使用されるセンサおよびアクチュエータを含む。デュプレクサ２００は、両面印刷動作の実行を可能にする。デュプレクサ２００は、従来のセンサおよびアクチュエータを含む。大容量トレーユニット１９８が、大量の用紙を保持する用紙トレーを可能にするために提供される。デュプレクサ２００と同様、トレーユニット１９８もまた従来のセンサおよびアクチュエータを含む。
【００４３】
給紙コントローラ１９６が、デジタル画像形成デバイスへの、およびこれを通る給紙動作を制御するために使用される。スキャナ１９４は、画像をスキャンしてデジタル画像形成デバイスに取り込むために使用され、ライト、ミラー等のような従来のスキャニング要素を含む。さらに、スキャナがホームポジションにあるかどうかを判定するためのホームポジションセンサのようなスキャナセンサが使用され、ランプサーミスタがスキャニングランプの正しい動作を保証するために使用される。プリンタ／イメージャ１９２が、デジタル画像形成デバイスの出力を印刷し、従来のレーザ印刷機構、トナーセンサ、および画像濃度センサを含む。定着器１９０は、高温ローラを用いてページ上にトナーを定着させるために使用され、出口センサ、定着器１９０が過熱していないことを保証するためのサーミスタ、およびオイルセンサを含む。さらに、自動ドキュメントフィーダ、異なるタイプのソータ／コレータ等のデジタル画像形成デバイスに追加可能な要素のような、デジタル画像形成デバイスのオプション要素に接続するために使用されるオプションユニットインタフェース１８８がある。他の要素として、デバイスの位置を識別することができるＧＰＳユニットがある。
【００４４】
図４は、マルチポートネットワークインタフェース１６６の詳細を示す。デジタル画像形成デバイスは、トークンリングインタフェース２２０、ケーブルを通じての高速接続を有するケーブルモデムユニット２２２、電話回線１６８Ａに接続する従来の電話インタフェース２２４、無線インタフェース２２８、またはＬＡＮ１７０に接続するイーサネットインタフェース２３０を通じて、外部デバイスと通信してもよい。他のインタフェースとしては、限定はされないが、デジタル加入者回線（ＤＳＬ）（オリジナルＤＳＬ、同軸ＤＳＬ、および非対称ＤＳＬ）があり得る。単体でローカルエリアネットワークおよび電話回線の両方に接続するデバイスがIntelから市販されており、Ｉntel  Ｐro  １０／１００＋Ｍodemとして既知である。
【００４５】
ＣＰＵまたは他のマイクロプロセッサもしくは回路が、デジタル画像形成デバイスの各センサの状態を監視する監視プロセスを実行し、シーケンス制御プロセスが、デジタル画像形成デバイスを制御し動作させるために使用されるコードの命令を実行するために使用される。さらに、（１）デジタル画像形成デバイスの動作全体を制御するために実行される中央システム制御プロセス、および（２）デジタル画像形成デバイスに接続される外部デバイスとの信頼性のある通信を保証するために使用される通信プロセスがある。システム制御プロセスは、静的状態メモリ（例えば図３のＲＯＭ１６４）、準静的メモリ（例えば、フラッシュメモリ１７８またはディスク１８２）、または動的状態メモリ（例えば、揮発性または不揮発性メモリ（例えば、ＲＡＭ１６２、フラッシュメモリ１７８、またはディスク１８２））内のデータストレージを監視および制御する。さらに、静的状態メモリは、ＲＯＭ１６４以外の、フラッシュメモリ１７８またはディスク１８２のいずれかを含む不揮発性メモリのようなデバイスであってもよい。
【００４６】
上記の詳細は、デジタル画像形成デバイスに関して説明されているが、本発明は、アナログ複写機、ファクシミリ機、スキャナ、プリンタ、ファクシミリサーバ、プロジェクタ、会議機器、シュレッダのような他の事務用マシンもしくはデバイスや、他の事務用マシン、事務用機器、または他の機器（例えば、電子レンジ、ＶＣＲ、デジタルカメラ、携帯電話機、パームトップコンピュータ）にも同様に適用可能である。さらに、本発明は、蓄積転送型、または直接接続方式の通信を用いて動作する他のタイプのデバイスを含む。このようなデバイスには、動作またはリモート診断中に監視されることを必要とする計測システム（ガス、水道、または電気計測システム等）、自動販売機、またはいかなる機械的デバイス（例えば自動車）も含まれる。特定用途のマシンおよびコンピュータを監視することに加えて、本発明は、監視および／または制御されるデバイスとなる汎用コンピュータを監視、制御、および診断するためにも使用可能である。
【００４７】
図５は、種々のデバイスおよびサブシステムがＷＡＮ１０に接続される本発明の代替システム図を示している。しかし、これらのデバイスまたはサブシステムのそれぞれを本発明の一部として有する必要はない。図５に示す各コンポーネントまたはサブシステムは個別に本発明の一部である。さらに、図１に示した要素が図５に示すＷＡＮ１０に接続されてもよい。図５において、イントラネット２６０−１に接続されたファイアウォール５０−１が示されている。イントラネット２６０−１に接続されたサービスマシン２５４はその内部に、またはそれに接続されて、データベースフォーマットで格納可能なデータ２５６を有する。データ２５６には、履歴、性能、故障や、被監視デバイスの動作もしくは障害もしくは設定の統計情報、または被監視デバイスとともにどのコンポーネントもしくはオプション機器が含まれているかというようなコンフィグレーション情報等のいかなる他の情報も含まれる。サービスマシン２５４は、被監視デバイスに対してデータを送信するよう要求し、またはリモート制御および／または診断テストが被監視デバイス上で実行されることを要求するデバイスまたはコンピュータとして実施されてもよい。サービスマシン２５４は、いかなるタイプのデバイスとして実施されてもよいが、好ましくは、汎用コンピュータのようなコンピュータ化されたデバイスを用いて実施される。
【００４８】
図５のもう１つのサブシステムは、ファイアウォール５０−２、イントラネット２６０−２、およびそれに接続されたプリンタ２６２を含む。このサブシステムでは、プリンタ２６２による（および同様に複写機２８６による）電子メッセージの送受信の機能が、（１）回路、（２）マイクロプロセッサ、または（３）プリンタ２６２内に含まれ、もしくはそれに装着された（すなわち、別個の汎用コンピュータを使用しない）他のタイプのハードウェア、によって実行される。
【００４９】
代替的タイプのサブシステムとしては、インターネットサービスプロバイダ２６４を使用するものが含まれる。これはAmerica  Online、Earthlink、およびNiftyserveのような既知の営利会社を含むいかなるタイプのインターネットサービスプロバイダ（ＩＳＰ）であってもよい。このサブシステムでは、コンピュータ２６６がデジタルまたはアナログモデム（例えば、電話回線モデム、ケーブルモデム、非対称デジタル加入者回線（ＡＤＳＬ）を通じて使用されるモデムのような任意のタイプの配線を使用するモデム、フレームリレー通信を使用するモデム、無線周波モデムのような無線モデム、光ファイバモデム、または赤外光波を使用するデバイス）を通じてＩＳＰ２６４に接続される。さらに、事務用デバイス２６８がコンピュータ２６６に接続される。事務用デバイス２６８（または図５に示されている任意の他のデバイス）の代替形態として、デジタル複写機、任意のタイプの機器、セキュリティシステム、もしくは電気、水道、またはガス需要計器のような需要計器、または本明細書に記載される任意の他のデバイスのような、異なるタイプのマシンが監視または制御されてもよい。
【００５０】
また図５には、ネットワーク２７４に接続されたファイアウォール５０−３も示されている。ネットワーク２７４は、いかなるタイプのコンピュータネットワーク（例えば、イーサネットまたはトークンリングネットワーク）として実施されてもよい。ネットワークを制御するために使用可能なネットワーキングソフトウェアとしては、NovellやMicrosoftから市販されているソフトウェア等のいかなる所望のネットワーキングソフトウェアも含まれる。ネットワーク２７４は、所望であれば、イントラネットとして実施されてもよい。ネットワーク２７４に接続されるコンピュータ２７２は、事務用デバイス２７８から情報を取得し、ネットワークに接続されている種々のマシンで発生した問題を示すレポートや、ネットワーク２７４に接続されているデバイスの月別使用状況レポートのようなレポートを作成するために使用されてもよい。この実施形態では、コンピュータ２７６は、事務用デバイス２７８とネットワーク２７４の間に接続される。このコンピュータは、ネットワークからの通信を受信し、適当なコマンドもしくはデータ、または任意の他の情報を、事務用デバイス２７８に転送する。
【００５１】
事務用デバイス２７８とコンピュータ２７６の間の通信は、有線または無線のいずれの方法を用いて行われてもよい。これには、以下のものに限定されないが、無線周波接続、電気接続、および光接続（例えば、赤外線接続、または光ファイバ接続）がある。同様に、図５に示されている種々のネットワークおよびイントラネットのそれぞれは、無線周波ネットワークのような無線ネットワークの確立によるものを含むいかなる所望の方法を用いて確立されてもよい。本明細書に記載される無線通信は、拡散符号を使用する技法や、Bluetooth  Specification（ワールドワイドウェブサイトwww．Bluetooth．comで入手可能）（これは参照により本明細書に援用される）に開示されている周波数ホッピング無線技法のような周波数ホッピング技法等のスペクトラム拡散技法を用いて確立されてもよい。
【００５２】
図５に示されているもう１つのサブシステムは、ファイアウォール５０−４、イントラネット２６０−４、それに接続されたコンピュータ２８２、事務用機器２８５および複写機２８６を含む。コンピュータ２８２は、レポートを作成し、診断または制御手続きを要求するために使用されてもよい。これらの診断および制御手続きは、事務用機器２８５および複写機２８６、または図５に示され、もしくは図５とともに使用されるいかなる他のデバイスに関して実行されてもよい。図５は複数のファイアウォールを示しているが、ファイアウォールは好ましいけれども随意の機器であり、したがって本発明は、所望であればファイアウォールを使用せずに運用されてもよい。ネットワーク接続された機器の監視および制御のため、いかなるコンピュータ（２６６、２７２、または２８２）も２５４の代わりに使用することができる。
【００５３】
図６Ａは、コンポーネント３０２、３０４、３０６、３０８、３１０、３１２、３１４、３１６、および３１８を含む通常の電子メール交換システムに接続されたデバイス／機器３００を示している。これは従来のように実施されてよく、前掲のStevensの文献のFigure  28．1を改変したものである。コンピュータインタフェース３０２が、本明細書に記載される任意のアプリケーションユニットまたはデバイス／機器３００とインタフェースをとる。図６Ａは、デバイス／機器３００が送信側である場合を示しているが、送信および受信の機能は図６Ａで逆にしてもよい。さらに、所望であれば、ユーザはデバイス／機器３００とインタフェースをとることを全く必要としなくてもよい。次に、コンピュータインタフェース３０２はメールエージェント３０４と相互作用する。Ｕｎｉｘ用の普及しているメールエージェントとしては、ＭＨ、Ｂｅｒｋｅｌｅｙ  Ｍａｉｌ、Ｅｌｍ、およびＭｕｓｈがある。Ｗｉｎｄｏｗｓファミリのオペレーティングシステム用のメールエージェントとしては、Ｍｉｃｒｏｓｏｆｔ  ＯｕｔｌｏｏｋおよびＭｉｃｒｏｓｏｆｔ  Ｏｕｔｌｏｏｋ  Ｅｘｐｒｅｓｓがある。コンピュータインタフェース３０２の要求時に、メールエージェント３０４は、送信されるべき電子メールメッセージを作成し、所望であれば、送信されるべきこれらのメッセージをキュー３０６に入れる。送信されるべきメールはメッセージ転送エージェント（ＭＴＡ）３０８に転送される。Ｕｎｉｘシステム用の普通のＭＴＡとしてはＳｅｎｄｍａｉｌがある。通常、メッセージ転送エージェント３０８と３１２は、ＴＣＰ／ＩＰ接続３１０を用いて交信する。特に、メッセージ転送エージェント３０８と３１２の間の通信は、いかなるサイズのネットワーク（例えば、ＷＡＮまたはＬＡＮ）を通じて行われてもよい。さらに、メッセージ転送エージェント３０８および３１２は、いかなる通信プロトコルを使用してもよい。本発明の一実施形態では、図６Ａの要素３０２および３０４は、アプリケーションユニットの使用を監視するためのライブラリに存在する。
【００５４】
メッセージ転送エージェント３１２から、電子メールメッセージはユーザメールボックス３１４に格納され、これがメールエージェント３１６に転送され、最終的に、受信端末として機能する端末３１８のユーザに送信される。
【００５５】
この「蓄積転送」プロセスは、送信側メールエージェント３０４を、メール受信側との直接接続が確立されるまで待機しなければならないことから解放する。ネットワーク遅延のため、通信には相当の時間を要することがあり、その間アプリケーションは応答しなくなる。このような応答性の遅延は一般に、アプリケーションユニットのユーザにとって受け入れ難いであろう。電子メールを蓄積転送プロセスとして使用することによって、障害後の再送試行が一定期間（例えば３日間）自動的に行われる。一代替実施形態では、アプリケーションは、１つまたは複数の別個のスレッドに通信要求を渡すことによって、待機を避けることができる。その場合、それらのスレッドが受信側端末３１８との通信を制御し、一方でアプリケーションはユーザインタフェースへの応答を再開する。さらにもう１つの実施形態では、ユーザが続行前に通信を完了したい場合、受信側端末との直接通信が使用される。このような直接通信は、送信側と受信側の端末間のファイアウォールによって遮断されないいかなるプロトコルを利用することも可能である。このようなプロトコルの例としては、Telnet、File  Transfer  Protocol（ＦＴＰ）、およびHyper  Text  Transfer  Protocol（ＨＴＴＰ）がある。
【００５６】
インターネットのようなパブリックＷＡＮは一般に、安全であるとはみなされていない。したがって、メッセージを秘密に保ちたい場合、パブリックＷＡＮ（および多企業プライベートＷＡＮ）を通じて送信されるメッセージを暗号化することができる。暗号化メカニズムが既知であって市販されており、本発明とともに使用され得る。例えば、Ｕｎｉｘオペレーティングシステムで使用するために、Ｃ＋＋ライブラリ関数crypt()がSun  Microsystemsから入手可能である。暗号化および復号化ソフトウェアパッケージが既知であって市販されており、これも本発明とともに使用され得る。１つのこのようなパッケージとして、PGP  Corporationから入手可能なＰＧＰがある。
【００５７】
図６Ａの一般的構成の代替形態として、コンピュータインタフェース３０２、メールエージェント３０４、メールキュー３０６、およびメッセージ転送エージェント３０８として機能する単一のコンピュータを使用してもよい。図６Ｂに示すように、デバイス／機器３００はコンピュータ３０１に接続され、コンピュータ３０１はメッセージ転送エージェント３０８を含む。
【００５８】
別の代替構成を図６Ｃに示す。この構成では、メッセージ転送エージェント３０８はデバイス／機器３００の一部として形成される。さらに、メッセージ転送エージェント３０８は、ＴＣＰ／ＩＰ接続３１０によってメッセージ転送エージェント３１２に接続される。図６Ｃの実施形態では、デバイス／機器３００が電子メール機能を有し、ＴＣＰ／ＩＰ接続３１０に直接接続される。図６Ｃの実施形態の１つの用途として、電子メール機能付きのファクシミリ機（例えば、ＲＦＣ２３０５（インターネットメールを用いたファクシミリの簡易モード）で規定されるような）をデバイス／機器３００として使用することがある。
【００５９】
図６Ｄは、デバイス／機器３００がそれ自体は電子メールを直接受信する機能を有さないが、メッセージ転送エージェント３０８およびメールボックス３１４を含むメールサーバ／ＰＯＰ３サーバへの接続３１０を有することにより、デバイス／機器３００がＰＯＰ３プロトコルを用いてメールサーバから受信メールを取り出すシステムを示している。
【００６０】
図７は、メールを転送する一代替実施態様を示しており、前に参照したStevensの文献のFigure  28．3を改変したものである。図７は、それぞれの側にリレーシステムを有する電子メールシステムを示している。図７の構成は、組織における１つのシステムがメールハブとして作用することを可能にする。図７には、２つのメールエージェント３０４と３１６の間に接続された４つのＭＴＡがある。これらのＭＴＡとしては、ローカルＭＴＡ３２２Ａ、リレーＭＴＡ３２８Ａ、リレーＭＴＡ３２８Ｂ、およびローカルＭＴＡ３２２Ｄがある。本発明とともに使用可能な、メールメッセージに使用される最も普通のプロトコルはＳＭＴＰ（Simple  Mail  Transfer  Protocol）であるが、いかなる所望のメールプロトコルを利用してもよい。図７において、３２０は、コンピュータインタフェース３０２、メールエージェント３０４、およびローカルＭＴＡ３２２Ａを含む送信側ホストを表す。デバイス／機器３００は送信側ホスト３２０に接続され、または別法としてその内部に含まれる。もう１つの場合として、デバイス／機器３００およびホスト３２０が１つのマシン内にあり、ホスト機能がデバイス／機器３００に組み込まれてもよい。他のローカルＭＴＡ３２２Ｂ、３２２Ｃ、３２２Ｅ、および３２２Ｆも含まれてよい。送受信されるメールは、リレーＭＴＡ３２８Ａのメールのキュー３０６Ｂにキューイングされてもよい。メッセージは、ＴＣＰ／ＩＰ接続３１０（例えば、インターネット接続または任意の他のタイプのネットワークをはさむ接続）を越えて転送される。
【００６１】
送信されたメッセージは、リレーＭＴＡ３２８Ｂによって受信され、所望であれば、メールのキュー３０６Ｃに格納される。次にメールは受信側ホスト３４２のローカルＭＴＡ３２２Ｄに転送される。メールは、１つまたは複数のユーザメールボックス３１４に入れられ、続いてメールエージェント３１６に転送され、最後に端末３１８のユーザに転送されてもよい。所望であれば、メールは、ユーザとの対話なしに端末に直接転送されてもよい。
【００６２】
図５のコンピュータ２６６および２７６を含む、本発明で使用される種々のコンピュータは、図８に示すように実施されてもよい。さらに、本発明で使用されるいかなる他のコンピュータも、所望であれば、図５のサービスマシン２５４、コンピュータ２７２、およびコンピュータ２８２を含む、図８に示すコンピュータと同様に実施されてもよい。しかし、図８に示すあらゆる要素がそれらの各コンピュータに必要なわけではない。
【００６３】
図８において、コンピュータ３６０はＣＰＵ３６２を含む。これは、Intel、AMD、Motorola、HitachiおよびNECのような会社からの市販のマイクロプロセッサを含むいかなるタイプのプロセッサとして実施されてもよい。ＲＡＭ３６４のようなワーキングメモリ、および無線デバイス３６８と通信する無線インタフェース３６６がある。インタフェース３６６とデバイス３６８の間の通信は、いかなる無線媒体（例えば、電波または光波）を使用してもよい。電波は、符号分割多元接続（ＣＤＭＡ）通信のようなスペクトラム拡散技法を用いて、またはBluetooth仕様に開示されているもののような周波数ホッピング技法を用いて実施されてもよい。
【００６４】
コンピュータ３６０は、ＲＯＭ３７０およびフラッシュメモリ３７１を含むが、いかなる他のタイプの不揮発性メモリ（例えば、消去可能プログラム可能ＲＯＭ、またはＥＥＰＲＯＭ）をフラッシュメモリ３７１に加えて、またはその代わりに使用してもよい。入力コントローラ３７２には、キーボード３７４およびマウス３７６が接続される。シリアルデバイス３８０に接続されるシリアルインタフェース３７８がある。さらに、パラレルインタフェース３８２がパラレルデバイス３８４に接続され、ユニバーサルシリアルバス（ＵＳＢ）インタフェース３８６がユニバーサルシリアルバスデバイス３８８に接続され、ＩＥＥＥ１３９４インタフェース３９８に接続される、一般にファイヤワイヤデバイスと呼ばれるＩＥＥＥ１３９４デバイス４００もある。システムバス３９０が、コンピュータ３６０の種々の要素を接続する。ディスクコントローラ３９６が、フロッピーディスクドライブ３９４およびハードディスクドライブ３９２に接続される。通信コントローラ４００は、コンピュータ３６０が電話回線４０２またはネットワーク４０４を通じて他のコンピュータと（例えば電子メールメッセージを送信することによって）通信することを可能にする。Ｉ／Ｏ（入出力）コントローラ４０８が、例えばＳＣＳＩ（Small  Computer  System  Interface）バスを用いてプリンタ４１０およびハードディスク４１２に接続される。また、ＣＲＴ（ブラウン管）４１４に接続されるディスプレイコントローラ４１６もあるが、液晶ディスプレイ、発光ダイオードディスプレイ、プラズマディスプレイ等を含むいかなる他のタイプのディスプレイを使用してもよい。
【００６５】
次に図９を参照すると、本発明の例示的な一実施形態によるシステム９００全体の概略図が示されている。システム９００は、複数のデバイス、例えば、レーザプリンタ９０８および９１０、ネットワークＳＮＭＰデバイス９１２、ならびに多機能プリンタ９１４を含み、すべてがネットワーク１００に接続されているように示されている。デバイス９０８、９１０、９１２、および９１４は本明細書では包括的に「被監視デバイス」と呼ばれる。システム９００はまた、ワークステーション／監視システム９０２（以下コントローラ９０２という）も含む。これは、被監視デバイス９０８、９１０、９１２、および９１４を監視および制御するためにネットワーク１００に接続される。被監視デバイス９０８、９１０、９１２、および９１４のそれぞれには固有のアドレスが与えられる。例えば、デバイスに割り当てられるＩＰアドレスが、そのデバイスにアクセスするための固有アドレスの役割を果たす。したがって、コントローラ９０２のユーザは、それぞれの被監視デバイスに割り当てられた固有のＩＰアドレスにアクセスすることによって、被監視デバイスのうちのそれぞれのデバイスにアクセスすることができる。本発明は、ネットワークに接続されるデバイスを一意的に識別するためにＩＰアドレスを使用することには限定されないことは理解されよう。
【００６６】
また、システム９００は、ネットワーク１００および他のネットワークに通信可能に結合したデバイスの間で電子メールメッセージの転送を容易にするためにネットワーク１００に接続されたＳＭＴＰ電子メールサーバ９３０も含む。ネットワークに通信可能に結合したデバイスの間で電子メールメッセージの転送を容易にするＳＭＴＰメールサーバの動作は、関連する同時係属中の米国特許出願第０９／９５３，３５８号、第０９／９５３，３５９号、第０９／９７５，９３５号、および第１０／１４２，９９２号にさらに詳細に記載されている。上記で述べたように、それらの特許出願の内容は参照により本明細書に援用される。
【００６７】
コントローラ９０２は、被監視デバイス９０８、９１０、９１２、および９１４のうちのデバイスにアクセスすると、種々の通信プロトコル（例えばＳＮＭＰおよびＨＴＴＰ）を通じてデバイスの情報を取得する。このような情報は、トラブルシューティング情報等のそのデバイスの動作ステータスに関する詳細情報を含む。例えば、コントローラ９０２は、特定のデバイスにアクセスしてその紙詰まりエラー情報を取得し、その紙詰まりを解消するためにそのデバイスの担当者にメッセージを送信してもよい。レーザプリンタ９０８の動作ステータス／詳細は、トナーレベル、紙詰まりの指示、プリンタトレー内の印刷用紙の量等の詳細を含む。
【００６８】
コントローラ９０２はネットワーク１００に物理的に接続されても無線結合してもよいということは理解されよう。例えば、携帯情報端末（ＰＤＡ）またはラップトップコンピュータ（図示せず）が、コントローラ９０２として使用されてもよい。したがって、アクセスポイントが、ネットワーク１００とＰＤＡまたはラップトップコンピュータとの間の無線通信を可能にするインタフェースとして作用してもよい。以下、本発明は、コントローラ９０２が、ネットワークに接続されている被監視デバイスのステータスを制御および監視すると仮定して説明される。
【００６９】
ネットワーク１００は、コントローラ９０２と被監視デバイス９０８、９１０、９１２、および９１４の間の通信を容易にして、このような被監視デバイスの監視および制御を可能にする。ネットワークに接続されるデバイスの個数は本発明を限定するものではない。ネットワーク１００は、ローカルエリアネットワーク（ＬＡＮ）または広域ネットワーク（ＷＡＮ）のいずれでもよいということは理解されよう。同様に、被監視デバイス９０８、９１０、９１２、および９１４は単に例示として示されている。
【００７０】
コントローラ９０２は、情報ストレージデバイス９０５およびデータベース９０７に通信可能に結合する。ストレージデバイス９０５としては、ハードディスク、光ディスク、および／または外部ディスクドライブがあり得る。データベース９０７は、ストレージデバイス９０５に通信可能にリンクされ、ストレージデバイス９０５に格納されているデータの容易な検索および取り出しのための関係データベース管理システム（ＲＤＢＭＳ）を含む。ストレージデバイス９０５は、好ましくは、被監視デバイス９０８、９１０、９１２、および９１４のそれぞれに関する詳細情報を格納する。例えば、レーザプリンタ９０８の製造元、モデル、ならびに種々の機能およびトラブルシューティングの詳細のような詳細情報がストレージデバイス９０５に格納される。また、所定の基準値と比較しての、レーザプリンタの動作ステータスに関する偏差値もまたストレージデバイス９０５に格納されてもよい。データベース９０７およびストレージデバイス９０５はコントローラ９０２に通信可能に結合しているように記載されているが、コントローラ９０２は、ストレージデバイスおよびデータベースがその内部に設置されて構成されてもよいということは理解されよう。このような場合、ストレージデバイス９０７およびデータベース９０５はコントローラ９０２の内部にあるものとして描かれるであろう。
【００７１】
また、システム９００は、メールサーバ９４０、データベース９０９、およびワークステーション９０３が通信可能に接続される第２ネットワーク１１０も含む。ワークステーション９０３は、情報ストレージデバイス９０４およびデータベース９０６に通信可能に結合する。ストレージデバイス９０４としては、ハードディスク、光ディスク、および／または外部ディスクドライブがあり得る。データベース９０６は、ストレージデバイス９０４に通信可能にリンクされ、ストレージデバイス９０４に格納されているデータの容易な検索および取り出しのための関係データベース管理システム（ＲＤＢＭＳ）を含む。また、ネットワーク１００およびネットワーク１１０は、それぞれネットワーク１００および１１０に結合しているファイアウォールユニット９６０および９７０を通じてリモート接続される。したがって、電子メールメッセージが、ＨＴＴＰまたはＦＴＰを用いてワークステーション９０２と９０３の間で交換されることが可能である。ネットワーク１１０は上記のネットワーク５２または２６０−１と同等であり、ワークステーション９０３はサービスマシン２５４と同等である。ワークステーション９０３は、接続されているデバイスにサービスを提供するために複数のネットワークからデータを収集することができる。
【００７２】
コントローラ９０２には、複数のデバイス９０８、９１０、９１２、および９１４の監視および制御を容易にするためにソフトウェアがインストールされる。コントローラ９０２が複数のデバイス９０８〜９１４を監視するためにSimple  Network  Management  Protocol（ＳＮＭＰ）およびHyper  Text  Transfer  Protocol（ＨＴＴＰ）が使用され、複数のデバイス９０８〜９１４から受信されるデータは、参照符号９５０によって示されるように、ＡＳＮ．１バイナリフォーマットまたはＨＴＭＬもしくはＸＭＬフォーマットの形で提示される。
【００７３】
図９はイメージングデバイスのみを示しているが、監視デバイスと複数の被監視デバイスの間で情報を通信するためのネットワークは、機器および計器がネットワークに接続されたホームネットワークを含んでもよい。コントローラ／ワークステーション９０２によって収集されるデータは、さらに処理をするために、Ｅメール、ＦＴＰ、またはいかなる他の通信プロトコル手段を通じてリモートデバイスへ送信されてもよいということは理解されよう。
【００７４】
＜監視システムのアーキテクチャ＞
図１０は、本発明の例示的な一実施形態による、リモートデバイスに関連するデータの監視において使用される監視システム１０００（および関連するインタフェース関数）を示している。監視システム１０００は、ＮＴまたはＷｉｎｄｏｗｓ  ２０００におけるサービスやＵｎｉｘにおけるデーモンのようなコンピュータ常駐プログラムであるソフトウェアモジュールMonitorService１００４を含む。好ましい一実施形態では、監視システムはオブジェクト指向ソフトウェア環境を用いて実施される。また、監視システム１０００には、Timerモジュール１００２およびMonitorモジュール１００６も含まれる。Timerモジュール１００２およびMonitorモジュール１００６は、MonitorServiceモジュール１００４によって呼び出されるライブラリ関数である。例えば、MonitorService１００４は、InitTimer１００３関数を呼び出すことによってTimerモジュール１００２を初期化し、obtainDelayAndAction（int  &，int  &）関数を呼び出すことによって遅延およびアクションのパラメータを取得する。init()関数もまた、図１３に示すようなMonitorモジュール１００６内の種々のモジュールを初期化するためにMonitorServiceモジュール１００４によって呼び出される。init()関数は、既知の方法を通じて収集されるＩＰアドレスを含む外部ソースを通じて被監視デバイスに割り当てられているＩＰアドレスを取得するために使用可能である。Monitorモジュール１００６は、以下でさらに詳細に説明するサポートデータベース１０２４およびモニタデータベース１０１４に通信可能に結合する。
【００７５】
被監視デバイスのＩＰアドレスが取得されると、そのＩＰアドレスは、監視システムが被監視デバイスと交信して、製造元（ベンダ）やモデル情報のような情報を取得するために使用される。監視システム１０００によって実行されるいくつかの関数としては以下のものがある：
【００７６】
void  initTimer（void）
この関数はTimerを初期化する。特に、この関数はTimerオブジェクトをトリガしてレジストリからタイミング情報を獲得する。
【００７７】
void  obtainDelayAndAction（int  &  out_nDelay，int  &  out_nAction）
この関数は、::Sleep関数のための秒単位の遅延時間（１０００倍することが必要）、およびアクションインジケータを返す。
【００７８】
int  init（void）
この関数はMonitorを初期化する。さらに、監視されるべきデバイスを作成する。返値intはエラーコードであり、ゼロがエラーなしと定義される。
【００７９】
int  monitorStatus（int  in_nAction）
この関数はプリセット情報を監視する。返値intはエラーコードであり、ゼロがエラーなしと定義される。
【００８０】
int  end（void）
この関数は、オブジェクトをクローズする前にMonitorをクリーンアップする。返値intはエラーコードであり、ゼロがエラーなしと定義される。
【００８１】
＜Monitorモジュール＞
図１１は、種々のソフトウェアサブモジュールを含むMonitorモジュール１００６の構成の詳細およびMonitorモジュール１００６のサブモジュール間の呼出し関数を示している。Monitorモジュール１００６は、図１０に示したようなインタフェース関数によって定義されるタスクを完了するために、（DeviceODBCモジュール１１０４、Deviceモジュール１１１０、HWaccessモジュール１１１６、およびSupportInfoODBCモジュール１１１４等の）他のサブモジュールを管理するMonitorManagerモジュール１１０２を含む。具体的には、DeviceODBCモジュール１１０４およびSupportInfoODBCモジュール１１１４は、標準的なインタフェースを通じて外部デバイス情報にアクセスするためにアクセスされる。MonitorManagerモジュール１１０２はHWaccessモジュール１１１６経由でSupportInfoODBCモジュール１１１４に結合する。HWaccessモジュール１１１６は、複数の通信プロトコル（例えばＨＴＴＰおよびＳＮＭＰ）のうちの選択された通信プロトコルを用いて被監視デバイスにアクセスするために、データベース１０２４に接続されたSupportInfoODBCモジュール１１１４を通じて取得される情報を用いて被監視デバイスからベンダ、モデル、固有ＩＤ、およびステータス情報を取得する。
【００８２】
SupportInfoODBCモジュール１１１４に存在する情報は、複数の通信プロトコルをサポートするために使用される。例えば、SupportInfoODBCモジュール１１１４は、種々の通信プロトコルをサポートし、ベンダおよびデバイスモデルに固有の種々の通信プロトコルによって使用され得る情報を格納するために作成されてもよい。被監視デバイスが、通信プロトコルおよびSupportInfoODBC１１１４に格納されている情報を用いてアクセスされると、被監視デバイスから受信されるステータス情報がDeviceODBCモジュール１１０４を通じてモニタデータベース１０１４に格納される。それぞれのMonitorソフトウェアモジュールについては以下でさらに詳細に説明する。
【００８３】
以下は、上記のMonitorモジュール間のインタフェースの不完全なリストおよび説明である。例えば、一部のモジュールは、都合の良いフォーマットで情報を取得するために、「init」関数または追加的関数を有する必要があるかもしれない。
【００８４】
void  updateConfig（std::map＜infoType，std::string＞  &）
この関数が呼び出される前に、get関数がVendorModelモジュールからヌル文字列を返す場合には、呼出し関数は製造元およびモデルのエントリを置き換えないほうが好ましい。この関数は、DeviceODBC１１０４を通じてカレントレコードのデバイス情報データベースを更新する。この関数は、下記のgetConfigが最初に呼び出される場合に非常に効率的である。
【００８５】
bool  obtainConfig（std::map＜infoType，std::string＞  &）
この関数は、所与のフォーマットでデバイス情報に対してDeviceODBC１１０４を通じてマップを取得する。関数は、返されるデータがあればtrueを返し、もはやデータがなければfalseを返す。
【００８６】
bool  saveStatus（std::map＜infoType，std::string＞  &）)
この関数は、DeviceODBC１１０４を通じてデータベース１０１４にステータス情報を保存する。関数は、保存が成功すればtrueを返し、さもなければfalseを返す。
【００８７】
Cdevice  *  createDevice（std::string  &  in_sIP，CHWaccess  &  in_Hwaccess，std::string  &  in_sCommunity）
この関数は、in_sIPおよびin_sCommunityに基づいて、CHWaccessを通じてハードウェアに接続されるデバイスを作成する。デバイスを作成することができない場合、関数は０を返す。したがって、呼出し側オブジェクトは、返されるオブジェクトポインタが０であるか否かをチェックしなければならない。
【００８８】
bool  canAccessHW（void）
この関数は、ハードウェアがネットワークを通じてアクセス可能であればtrueを返し、さもなければfalseを返す。
【００８９】
bool  getVendor（std::string  &  out_sVendor）
この関数はベンダ名を返す。デバイスがシステムによってサポートされないがＳＮＭＰまたはＨＴＴＰを通じてアクセス可能である場合、文字列は「GENERIC」を含む。プロセス中にエラーが検出される場合、関数はヌル文字列とともにfalseを返す。さもなければ関数はtrueを返す。
【００９０】
bool  getModel（std::string  &  out_sModel）
この関数はデバイスのモデルを獲得する。モデルが取得された場合、関数はtrueを返す。プロセス中にエラーが検出される場合、関数はヌル文字列とともにfalseを返す。
【００９１】
bool  getUniqueID（std::string  &  out_sUniqueID）
この関数はデバイスの固有ＩＤを返す。固有ＩＤが取得された場合、関数はtrueを返す。プロセス中にエラーが検出される場合、関数はヌル文字列とともにfalseを返す。
【００９２】
bool  obtainStatus（map＜infoType，std::string＞&  out_StatusMap）
この関数はステータスマップを返す。関数は、ステータスが返される場合にtrueを返し、ステータスを取得できなければfalseを返す。なお、この関数はHWaccessおよびDeviceモジュールから異なるマップを返すことに留意されたい。Deviceモジュールでは、エラーステータス情報が、HWaccessから返されるマップに追加され、エラーステータス情報はゼロにクリアされる。
【００９３】
enum  checkErrorStatus（void）
この関数は、ＳＮＭＰを通じてプリンタのエラーバイトを取得することをトリガする。enum型および値はクラス内で定義されなければならない。enum値は値eNoErrorSinceClearAndNoErrorDetected、eNoErrorSinceClearAndErrorDetected、eErrorSinceClearAndNoErrorDetected、eErrorSinceClearAndErrorDetectedを含まなければならない。
【００９４】
bool  obtainErrorStatus(map＜infoType，std::string＞&  out_ErrorStatusMap)
この関数はエラーステータス情報を取得する。関数は、ステータスが返される場合にtrueを返し、ステータスを取得できなければfalseを返す。
【００９５】
void  clearErrorStatus（void）
この関数は、最後のobtainStatus関数呼出しまたはclearErrorStatus以降に蓄積したエラーステータスをクリアする。
【００９６】
void  initBegin（void）
この関数は、特にソフトウェアデバイスオブジェクトを作成するために、HWaccessを通じて初期化プロセスを開始する。
【００９７】
void  initEnd（void）
この関数は、HWaccessを通じて初期化プロセスを終了し、デバイスオブジェクト作成が完了したことを示す。
【００９８】
bool  canAccessIP(std::string  &  in_sIP，std::string  &  in_sCommunity)
この関数は、デバイスがＩＰアドレスにおいてアクセス可能であればtrueを返し、さもなければfalseを返す。
【００９９】
bool  obtainVendor（std::string  &  out_sVendor，std::string  &  in_sIP，std::string  &  in_sCommunity）
この関数はベンダを取得する。関数は、動作が成功すればtrueを返し、さもなければ空文字列とともにfalseを返す。
【０１００】
bool  obtainModel（std::string  &  out_sModelName，std::string  &  in_sIP，std::string  &  in_sCommunity）
この関数はモデル名を取得する。関数は、動作が成功すればtrueを返し、さもなければ空文字列とともにfalseを返す。
【０１０１】
bool  obtainUniqueID（std::string  &  out_sUniqueID，std::string  &  in_sIP，std::string  &  in_sCommunity）
この関数は固有ＩＤを取得する。関数は、動作が成功すればtrueを返し、さもなければ空文字列とともにfalseを返す。
【０１０２】
ErrorCode  obtainErrorStatus（char  &  out_cError，std::string  &  in_sIP，std::string  &  in_sCommunity）
この関数は、ＳＮＭＰを通じてエラーステータスバイトを取得する。関数は、動作が成功すればtrueを返し、さもなければゼロバイトとともにfalseを返す。EerrorCodeは下記で定義する。
【０１０３】
bool  obtainStatus（map＜infoType，std::string＞&  out_StatusMap，std::string  &  in_sIP，std::string  &  in_sVendor，std::string  &  in_sModel，std::string  &  in_sCommunity）
この関数はデバイスのステータスを取得する。関数は、動作が成功すればtrueを返し、さもなければ空マップとともにfalseを返す。
【０１０４】
bool  obtainSNMPVendor（std::string  &  out_sVendor，std::string  &  out_sOIDVendor，std::string  &  out_sOIDModelLocation，std::string  &  out_sOIDUniqueID）
この関数は、ＳＮＭＰの場合に、ベンダの名前、そのベンダＯＩＤ、モデル情報が格納されているＯＩＤ、および固有ＩＤを取得することができるＯＩＤを取得する。この関数は、データが返される場合にtrueを返し、もはやデータが利用可能でなければfalseを返してすべての文字列にヌル文字列がセットされる。
【０１０５】
bool  obtainSNMPVendorStatus（infoType  &  out_nNum，std::string  &  out_sOID，std::string  &  in_sVendor）
この関数は、ＳＮＭＰの場合に、所与のベンダに対するinfoTypeおよびそのinfoTypeに関連するＯＩＤを取得する。取得されるinfoTypeおよびＯＩＤの対は、所与のベンダからのすべてのデバイスによってサポートされる。この関数は、データが返される場合にtrueを返し、もはやデータが利用可能でなければfalseを返してすべての文字列にヌル文字列がセットされる。注意：GENERICが、すべてのベンダに共通のベンダである。
【０１０６】
bool  obtainSNMPModelStatus（infoType  &  out_nNum，std::string  &  out_sOID，std::string  &  in_sVendor，std::string  &  in_sModel）
この関数は、ＳＮＭＰの場合に、所与のベンダおよびモデルに対するinfoTypeおよびそのinfoTypeに関連するＯＩＤを取得する。この関数は、データが返される場合にtrueを返し、もはやデータが利用可能でなければfalseを返してすべての文字列にヌル文字列がセットされる。
【０１０７】
bool  obtainSupportedVendorModel（std::string  &  out_sVendor，std::tring  &  out_sModel，int  &  out_nDelay）
この関数は、ＨＴＴＰを通じてウェブサイトにアクセスするための遅延とともに、ベンダおよびサポート対象モデルを取得する。ベンダおよびモデルに対してＳＮＭＰのみがサポートされる場合、out_nDelayは−１となる。同じベンダの複数のインスタンスがあってもよいが、モデルは所与のベンダに対して固有である。この関数は、データが返される場合にtrueを返し、もはやデータが利用可能でなければfalseを返してすべての文字列にヌル文字列がセットされる。
【０１０８】
bool  obtainHTTPWebUniqueIDForVendor（std::string  &  out_sWebPage，SkeyValueInfo  &  out_KeyValueInfo，std::string  &  in_sVendor)
この関数は、所与のベンダに対するウェブページおよび固有ＩＤのSKeyValueInfo構造体を取得する。同じベンダが複数のウェブページを有してもよい。この関数は、データが返される場合にtrueを返し、もはやデータが利用可能でなければfalseを返してすべての値にヌル値がセットされる。
【０１０９】
bool  obtainHTTPWebPageInfoForVendorModel（std::string  &  out_sWebPage，std::vector＜SkeyValueInfo＞&  out_KeyValueInfoVector，std::string  &  in_sVendor，std::string  &  in_sModel)
この関数は、所与のベンダおよびモデルに対するウェブページおよびそのウェブページに関連するSKeyValueInfo構造体のベクタを取得する。同じベンダおよびモデルが複数のウェブページを有してもよい。この関数は、データが返される場合にtrueを返し、もはやデータが利用可能でなければfalseを返してすべての値にヌル値がセットされる。
【０１１０】
図１２Ａは、HWaccessモジュール１１１６によって受信されるキー値に関連する値の取り出しのための情報を交換するために、図１１に示したHWaccessモジュール１１１６およびSupportODBCモジュール１１１４によって使用されるデータ構造体を示している。例えば、図１２Ａに示すSKeyValueInfoデータ構造体は、所与のウェブページ内の特定の情報タイプ（m_infoType１２０２に対応する）に対応する情報を取得する方法を決めるために使用される。通常、多数のベンダが、それぞれのウェブページに表示される、被監視デバイスに関連するキー情報を識別するために、ベンダ固有の識別子および命名法を使用している。例えば、プリンタデバイスによって印刷されるページ数を決めるため、Hewlett
Packardは「Page  Count」機能を使用する一方、Xeroxは「Total  Sheet  Delivered」機能を用いてそれを識別する。本発明の特徴は、データ構造体／SKeyValueInfo構造体１２００を使用することによって、ベンダ間の相違を克服し、それによりデバイス固有情報を識別する標準化された統一的方法を提供し、その情報に対応する値を抽出することである。SKeyValueInfoデータ構造体１２００は、公開の属性を含む。
【０１１１】
SKeyValueInfoは通常、データ文字列またはキー文字列の形態で被監視デバイスから受信される情報から値情報を識別するために作成されるデータ構造体である。SKeyValueInfoは複数のフィールドを含み、各フィールドは図１２Ａに示す情報によって表される。SKeyValueInfo構造体１２００は、文字列キーを表すm_sKeyフィールド１２０４と、その文字列内で値情報が位置し得る位置の個数を示す、好ましくはタグに基づく値であるm_nPositionフィールド１２０６を含む。例えば、監視を受けているプリンタデバイスのPage
Countは、キーワードに続く２番目の位置に見つかるかもしれない。m_sType１２０８は、被監視デバイスの表示されるウェブページから取り出すことができる情報のタイプを表す。
【０１１２】
例えば被監視デバイスのモデル名のような値がキー（Product  Name）と同じデータ行内に見つかる場合、m_nPositionフィールドは「０」である。m_sDelimiter１２１０は、キーに関連する値を抽出するために使用される特定のデリミタを示す。
【０１１３】
SKeyValueInfoデータ構造体は、被監視デバイスからＨＴＭＬフォーマットで受信される情報から値情報を抽出する方法を示す。図１２Ｂは、オブジェクト識別子（ＯＩＤ）を情報タイプ（m_infoType）と関連づける例示的データ構造体を示している。
【０１１４】
図１３は、図１０に示したMonitorモジュール１００６の呼出しシーケンスを説明するためにinit関数のシーケンスを示している。MonitorManager１１０２は、HWaccessモジュール１１１６を初期化して初期化関数を開始する。次に、MonitorManager１１０２は、被監視デバイスに関する情報を取得し、被監視デバイスに割り当てられているＩＰアドレスを用いて被監視デバイスと通信する。MonitorManager１１０２は、DeviceODBC１１０４にアクセスして、被監視デバイスのコンフィグレーション情報を取得する。MonitorManager１１０２に返されるコンフィグレーション情報としては、例えば、被監視デバイスのＩＰアドレス、ならびに被監視デバイスのベンダ／製造元およびモデル情報がある。ＩＰアドレスが取得されると、MonitorManager１１０２は、CDeviceFactoryクラス２００１を通じてDeviceモジュール１１１０のクラス構造に基づくソフトウェアオブジェクトを作成するためにそのＩＰアドレスをセットする。デバイスソフトウェアオブジェクトの作成に成功すると、HWaccessモジュール１１１６を用いてベンダ、モデル、および固有ＩＤが被監視デバイスから取得され、作成されたデバイスソフトウェアオブジェクトに格納される。
【０１１５】
ベンダ、モデル情報、および固有ＩＤがデバイスソフトウェアオブジェクトから取得されると、MonitorManager１１０２は、被監視デバイスから受信された情報でデータベース（例えばDeviceODBC１１０４）を更新する。
【０１１６】
ベンダ、モデルおよび固有ＩＤのような値情報を被監視デバイスから抽出する方法はSupportODBC１１１４から取得される。
【０１１７】
図１４は、図１１に示したMonitorManagerモジュール１１０２によって被監視デバイスのステータスを判定するためのステータスモニタ関数のシーケンスを示している。このプロセスは、図１５に示すベクタに格納されているすべての被監視デバイスにわたって繰り返される。
【０１１８】
図１５を参照すると、図１３および図１４に示したCDeviceFactory１１０６によって作成されMonitorManager１１０２によって使用されるデバイスへの参照を有するベクタ１５００が示されている。MonitorManager１１０２は、CDeviceFactory１１０６によって作成された、例えばCDeviceオブジェクトへのポインタ１５０２、およびCDeviceオブジェクトへのポインタ１５０４のようなデバイスポインタをベクタに格納する。ベクタシーケンスは、被監視デバイスのステータスを取得するために反復される。被監視デバイスのポーリングは、obtainStatusコマンドを発行することによってデバイスオブジェクトに対して実行される。それぞれのソフトウェアオブジェクトのステータスが取得されると、このステータスはDeviceODBC１１０４を通じて更新される。ステータスモニタシーケンスについては図１４で上述したので、ここでは繰り返さない。
【０１１９】
表１に示すDeviceInfo構造体は、１つの被監視デバイス例に関する情報を反映する。DeviceInfo構造体は、連絡担当者の電子メールアドレスを電話番号とともに含む。
【０１２０】
【表１】
2005004735.tif 000003
【０１２１】
図１６は、HWaccessモジュール１１１６（図１１）を通じての情報収集をサポートするテーブル構造を示している。図１６に示すテーブルは、好ましくは、SupportInfoODBC１１１４（図１１）を通じて監視システム９０２（図９）と通信するデータベースに格納される。具体的には、図１６は、種々のテーブルを、それぞれのフィールドとともに示している。テーブル１６０２、１６０４、１６０６、および１６１０は、ＳＮＭＰによって使用されるオブジェクト識別子（ＯＩＤ）に関係づけられている。HTML−ModelKeyValueテーブル１６１４は、例えば、nVendorModelWebpageID、対象となるパラメータ値を抽出するために使用されるキー文字列情報、ＨＴＭＬ構造内の値位置、値の型、値がキー文字列と同じデータ内に配置されている場合のデリミタ、値がキー文字列と同じデータ内に配置されている場合の値のnInLinePosition、およびキー文字列に対する標準の列挙子のような情報を含む。
【０１２２】
VendorModelWebPageテーブル１６１２は、ウェブページＩＤを実際のウェブページ文字列と関連づける。EnumCorrespondenceテーブル１６１８は、標準列挙およびそれらの説明を含む。UniqueIDWebPageテーブル１６０８は、被監視デバイスに対するベンダ関連情報を含み、ここで固有ＩＤはデバイスから取得される。VendorModelWebPageテーブル１６１２は、特定ベンダの特定モデルからの被監視デバイスに固有の情報を含む。
【０１２３】
本発明によって使用される例示的なenum型は以下のものを含む。（これらのenum型は単に例示であり、したがって本発明を限定するものと解釈されてはならない。）
【０１２４】
infoType（typedef  int  infoType）
このセクションは、infoType（int）の定義を記述する。値範囲０〜９９はデータ型に割り当てられる。値範囲１００〜４９９はデバイス情報に割り当てられる。値範囲５００〜１９９９は標準ＭＩＢパラメータを含む共通パラメータに割り当てられる。範囲２０００〜３９９９はRicoh固有情報に割り当てられる。範囲４０００〜４９９９はXeroxに割り当てられる。範囲５０００〜５９９９は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
以下のコードは単なる例示であり、より多くのコードを既存のセットに追加してもよい。範囲０〜９９は予約されている。範囲１００〜１９９はＳＭＴＰ、２００〜２９９はＰＯＰ３、３００〜３９９はソケット、および４００〜４９９はＨＴＴＰに対するものである。他の指定されていない範囲は必要があればユーザによって定義されてもよい。
【０１２７】
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モジュールに格納する。ステップ１７０６で、ソフトウェアデバイスオブジェクトを作成する一方で、ベンダおよび／またはモデルに固有の情報等のデバイスオブジェクトのタイプに固有の情報とそのアクセス方法を、第１データベースから取得し、HWaccessモジュールに格納する。
【０１２９】
図１８は、デバイスからのステータス情報取り出しの各ステップを示す。このプロセスは、初期化時に作成されるすべてのデバイスに対して使用される。ステップ１８０２で、プロセスは、すべてのプロトコルが処理されたかどうかをチェックする。すべてのプロトコルが処理された場合、取得されたステータスおよび固有ＩＤを第２データベース１０１４に格納する。プロトコルが完了していない場合、ステップ１８０４で、次のプロトコルを選択する。次に、ステップ１８０６で、システムは、選択されたプロトコルを通じてデバイスにアクセスし、第１データベースから取得されたHWaccessに格納されている情報を用いてステータスを取得する。ステップ１８０８で、システムは、各ステータスが収集されたかどうかをチェックする。収集されていない場合、実行はステップ１８０２に進む。各ステータスが収集された場合、ステップ１８１０で、システムはステータス情報および固有ＩＤを第２データベースに格納する。
【０１３０】
各Monitorサブモジュール（DeviceODBC、Device、HWaccess、およびSupportODBC）のアーキテクチャ（例えばクラス構造）および主要な関数について以下でさらに詳細に説明する。
【０１３１】
＜DeviceODBCモジュール＞
図１９は、DeviceODBCモジュール１１０４内のクラス構造を示している。DeviceODBCモジュール１１０４は、クラスCDeviceODBC１９０１、CDeviceInfoData１９０２、およびCDeviceHistoryData１９０３を含む。さらに２つのクラスCDeviceInfoTable１９０４およびCDeviceHistoryTable１９０５は、Open  Database  Connectivity（ＯＤＢＣ）を通じてデータベース内のテーブルと接続するための（Microsoft  Foundation  Classの）CRecordSet１９０６のサブクラスである。CDeviceODBCクラス１９０１は、図１１に指定されているインタフェースを提供する。
【０１３２】
＜Deviceモジュール＞
図２０は、Deviceモジュール１１１０のクラス構造を示している。Deviceモジュール１１１０は、クラスCDeviceFactory２００１およびCDevice２００２を含む。図２０に示されているように、CDeviceFactoryクラス２００１は、HWaccessモジュール１１１６へのインタフェースクラスであって対応するデバイスのＩＰアドレス、ベンダ名、モデル名、および固有識別を含むソフトウェアデバイスオブジェクト（CDevice２００２）を作成する。
【０１３３】
図２１は、図１３に示したものより詳細な、デバイス作成シーケンスを示している。CMonitorManagerクラスのソフトウェアオブジェクトがDeviceODBCモジュール１１０４に格納されているＩＰアドレスを取得した後、オブジェクトはクラスCDevice２００２のソフトウェアデバイスオブジェクトを作成しようと試みる。CDeviceFactoryクラス２００２のオブジェクトが、作成されたソフトウェアデバイスオブジェクトがそのＩＰアドレスを通じて（後述のCHWaccess２３０１経由で）実際にハードウェアデバイスにアクセス可能かどうかをテストする。また、CDeviceFactoryクラス２００１は、デバイスの完全性をチェックした後、作成されたデバイスが良好である場合はソフトウェアデバイスオブジェクトを返し（ポインタが非ゼロである）、さもなければデバイスオブジェクトを返さない（ポインタはゼロ）。
【０１３４】
＜HWAccessモジュール＞
図２２は、HWAccessモジュール１１１６の構成を示している。HWAccessモジュール１１１６は、Accessモジュール２２０１内に、SNMPモジュール２２０２およびHTTPモジュール２２０３のような被監視デバイスにアクセスするために使用されるプロトコルに関連するモジュールを、アクセスクラスとともに含む。Access、SNMP、およびHTTPモジュールについては以下でさらに詳細に説明する。
【０１３５】
HWAccessモジュール内で利用可能な公開関数には以下のものがある。
【０１３６】
bool  initiateHTTP（string  ＆  in_sIP，int  in_nDelay）；
この関数は、ＩＰアドレスに対応するデバイスとのＨＴＴＰセッションを開始する。この関数は、ＨＴＴＰセッションを開始することができる場合にtrueを返す。さもなければfalseを返す。
【０１３７】
bool  obtainTitleFromHomePage（string  &  out_sTitle）；
この関数は、デバイスのホームページからタイトルを取得する。この関数は、タイトルを取得できる場合にtrueおよびタイトルの文字列を返す。さもなければ、falseおよび空文字列を返す。
【０１３８】
bool  obtainDataFromHTMLFile（map＜infoType，string＞&  out_Value，string&  in_sWebPage，vector＜SkeyValueInfo＞&  in_KeyValueInfoVector）；;
この関数は、デバイスのウェブページから所望の情報を取得する。この関数は、情報を取得できる場合にtrueおよび所望の情報のマップを返す。所望の情報はマップに追加される。この関数は、ウェブページにアクセス可能でない場合には、マップを変更せずにfalseを返す。
【０１３９】
bool  closeHTTP()；
この関数は、デバイスに対するＨＴＴＰセッションをクローズする。
【０１４０】
bool  initiateSNMP（string&  in_sIP，string&  in_sCommunity）；
この関数は、ＩＰアドレスに対応するデバイスに対するＳＮＭＰセッションを開始する。この関数は、ＳＮＭＰセッションを開始することができる場合にtrueを返す。さもなければfalseを返す。
【０１４１】
bool  obtainValueFromGetRequest（string&  out_sValue，string&  in_sOID）；
この関数は、ＳＮＭＰのGETリクエストを通じて入力ＯＩＤに関連する文字列値を取得する。この関数は、ＯＩＤに関連する文字列値を取得できる場合にtrueおよびその文字列値を返す。さもなければ、falseおよび空文字列を返す。この関数は、trueの場合に空文字列を返す可能性がある。
【０１４２】
bool  obtainValueFromGetNextRequest(string&  out_sValue，string&  in_sOID)；
この関数は、ＳＮＭＰのGET  NEXTリクエストを通じて入力ＯＩＤに関連する文字列値を取得する。この関数は、trueおよび入力ＯＩＤを含む次のＯＩＤに関連する文字列値を返す。さもなければ、falseおよび空文字列を返す。ＳＮＭＰのGET  NEXTリクエストは、ＭＩＢ内の入力ＯＩＤに続くＯＩＤに関連する値を取得する。この関数は、trueの場合に空文字列を返す可能性がある。
【０１４３】
bool  obtainValueFromGetNextRequest（string&  out_sValue）；
この関数は、ＳＮＭＰのGET  NEXTリクエストを通じて次のＯＩＤに関連する文字列値を取得する。この関数は、trueおよび同じ名前の別の関数でセットされたＯＩＤを含む次のＯＩＤに関連する文字列値を返す。さもなければ、falseおよび空文字列を返す。ＳＮＭＰのGET  NEXTリクエストは、ＭＩＢ内の入力ＯＩＤに続くＯＩＤに関連する値を取得する。この関数は、trueの場合に空文字列を返す可能性がある。
【０１４４】
bool  closeSNMP（）；
この関数は、デバイスに対するＳＮＭＰセッションをクローズする。この関数は、ＳＮＭＰセッションをクローズすることができる場合にtrueを返す。さもなければfalseを返す。
【０１４５】
＜Accessモジュール＞
Accessモジュール２２０１は、ネットワークデバイスからの情報にアクセスするための種々のネットワークプロトコルを管理する。Accessモジュール２２０１は、SNMPモジュール２２０２と対話して、ＳＮＭＰを用いてデバイスから情報を取得する。さらに、Accessモジュール２２０１は、HTTPモジュール２２０３と対話して、ＨＴＴＰを用いてデバイスから情報を取得する。
【０１４６】
図２３は、Accessモジュール２２０１のクラス構造を示している。Accessモジュール２２０１は、クラスCHWaccess２３０１、CSNMPAccess２３０２、およびCHTTPAccess２３０３を含む。CHWaccessクラス２３０１は、Accessモジュール２２０１のインタフェースクラスである。なお、CHWaccessクラス２３０１は、上記のHWaccess１１１６内に記述されるすべての公開関数を含むことに留意されたい。クラスCSNMPAccess２３０２およびCHTTPAccess２３０３は、それぞれＳＮＭＰおよびＨＴＴＰをサポートするプロトコルへのインタフェースクラスである。さらに、これらの２つのクラスは、共通ステータス情報エンティティ、ベンダ固有情報エンティティ（利用可能な場合）、およびベンダモデル固有情報エンティティに従ってデバイスにアクセスする方法に関連する情報を格納する。このモジュールに関連するデータ構造体については以下で説明する。
【０１４７】
図２４は、Accessモジュール２２０１内のクラスのオブジェクトを初期化するための、CHWaccessクラス２３０１のinitBegin関数に関連するシーケンスを示している。まず、プロセスは、組込みＣ＋＋関数newを用いてSupportODBCクラスオブジェクトを作成し、initBeginを通じてそれをCSNMPAccessおよびCHTTPAccessクラス内のオブジェクトに渡す。するとCSNMPAccessおよびCHTTPAccessクラスオブジェクトは、SupportODBCオブジェクトを用いて、以下で説明するデータ構造体に従って必要な情報を取得する。
【０１４８】
図２５は、ＳＮＭＰおよびＨＴＴＰプロトコルを通じて特定のＩＰアドレスでデバイスにアクセス可能かどうかをチェックするための、CHWaccessクラス２３０１のcanAccessIP関数に関連するシーケンスを示している。まず、CSNMPAccessオブジェクトへのcanAccessIP呼出しを通じてＳＮＭＰをチェックする。ＳＮＭＰを通じてデバイスにアクセス可能な場合、canAccessIP関数はデバイスにアクセス可能であることを示し、関数initializeSNMPおよびcloseSNMPが呼び出される。ＳＮＭＰアクセスが失敗した場合、所与のＩＰアドレスでＨＴＴＰアクセスが可能かどうかを判断するためにCHTTPAccessオブジェクトが呼び出される。
【０１４９】
図２６は、デバイスからベンダ名を取得した後、SupportODBCモジュール１１１４のオブジェクトからのベンダ関連情報を格納するための、CHWaccessクラス２３０１のobtainVendor関数に関連するシーケンスを示している。ＳＮＭＰのほうが必要とするリソースが少ないため、シーケンスはまず、ＳＮＭＰプロトコルを用いてデバイスにアクセスしベンダ情報を取得しようと試みる。ベンダは識別されたが、サポート対象ベンダリストにない場合、関数は復帰する。ベンダが識別されてサポートされている場合、CSNMPAccessクラスオブジェクトは、SupportODBCモジュールを通じてサポートデータベース１０２４にアクセスし、当該特定ベンダのステータスチェックのために使用されるベンダに関連するＯＩＤ（複数可）を獲得する。ＳＮＭＰがベンダ名を獲得することに失敗した場合、ＨＴＴＰを用いてベンダ名を獲得する。ベンダ名が取得され、システムによってサポートされている場合、CSNMPAccessクラスオブジェクトは、initWithVendor関数を通じて、特定ベンダのステータスチェックのために使用されるベンダに関連するＯＩＤ（複数可）を獲得するように命令される。本発明では、CHTTPAccessに格納されるべきベンダ共通情報はない。しかし、情報が同一ベンダのデバイス間で共通であり、ＨＴＴＰを通じて収集することができる場合、SupportODBCのためにインタフェース関数が定義され、その関数が、ベンダを識別した後にCHTTPAccessクラスオブジェクトによって呼び出されることにより、その情報を格納することができる。
【０１５０】
図２７は、デバイスモデル情報を取得するための、CHWaccessクラス２３０１のobtainModel関数に関連するシーケンスを示している。プロセスは、上記のobtainVendor関数の場合と類似している。しかし、１つの相違点として、CHTTPAccessクラスオブジェクトは、モデル情報を取得した後にSupportODBCモジュールを呼び出すことにより、ベンダおよびモデル固有のステータスの情報取り出し方法を取得することができる。
【０１５１】
図２８は、第１にＳＮＭＰを通じて、第２に、ＳＮＭＰが失敗した場合に、ＨＴＴＰを通じて、デバイスから固有ＩＤを取得するための、CHWaccessクラス２３０１のobtainUniqueID関数に関連するシーケンスを示している。なお、ＨＴＴＰプロトコルは、ウェブページの名前およびウェブページから固有ＩＤを抽出する方法の情報を取得するためにSupportODBCにアクセスする必要があることに留意されたい。
【０１５２】
図２９は、まずＳＮＭＰを用いて、次にＨＴＴＰを用いて、デバイスからステータスを取得するための、CHWaccessクラス２３０１のobtainStatus関数に関連するシーケンスを示している。このプロセスのさらなる説明については、「Method  of  using  Vectors  of  Structures  for  Extracting  Information  from  the  Web  Pages  of  Remotely  Monitored  Devices」と題する２００２年１２月２６日出願の同時係属中の米国特許出願第１０／３２８，０２６号（参照により本明細書に援用される）を参照されたい。しかし、以下でさらに詳細に説明するように、ＨＴＴＰのために、前にＳＮＭＰ部分で取得された情報は、デバイスから取得されるべきステータス情報のリストから削除されることに留意されたい。
【０１５３】
図３０Ａおよび図３０Ｂは、SupportODBCモジュール１１１４から取得されるサポート情報を格納するための、CHTTPAccessによって使用される２つのデータ構造体を示している。第１のデータ構造体３０１０は、ベンダ（第１列）、モデル（第２列）およびデバイスによるＨＴＴＰの処理に必要な遅延を示している。第２のデータ構造体３０２０は、特定のモデルおよびベンダのデバイスからのステータス情報の取り出しに使用される情報のベクタを含む。
【０１５４】
図３１Ａおよび図３１Ｂは、SupportODBCモジュール１１１４内のオブジェクトから取得されるサポート情報を格納するための、CSNMPAccessクラスによって使用される２つのデータ構造体を示しており、CHTTPAccessによって使用される図３０Ａおよび図３０Ｂのデータ構造体に類似している。第１のデータ構造体３１１０は、マップデータ構造体内に、キーとしてのベンダと、値としてのモデルのベクタとを含む。第２のデータ構造体３１２０は、ベンダおよびモデル情報（マップのキーフィールド内の「GENERIC」を含む）と、ベクタSOIDinfoType（標準情報および対応するＯＩＤを含む）を含む。「GENERIC」文字列は、すべてのデバイスの間で共通な情報を表す。ＳＮＭＰを通じての特定のデバイスのステータスは、以下の３個の異なるソースから取得される：すべてのデバイス間で共通の情報、特定のベンダからのデバイス間で共通の情報、ならびにベンダおよびモデルに固有の情報。一部のモデル情報はSupportODBCモジュール１１１４にはないかもしれない。その場合、最初の２つのソースが使用される。システムがベンダをサポートしていない場合、第１の情報ソースのみが使用される。
【０１５５】
＜SNMPモジュール＞
SNMPモジュール２２０２は、ＳＮＭＰを用いてネットワークデバイスに関する情報を取得することを担当する。デバイスは、デバイスに関する情報を含む。SNMPモジュール２２０２はその情報にアクセスし、ＯＩＤを用いて所望の情報を抽出する。
【０１５６】
図３２は、SNMPモジュール２２０２（HWAccessモジュール１１１６のサブモジュール）のクラス構造を示している。SNMPモジュール２２０２は、CSNMPクラス３２０１、CSnmpSessionクラス３２０２、およびCSnmpUtilityクラス３２０３を含む。これらのクラスは、ＳＮＭＰプロトコルを通じて被監視ハードウェアデバイスから情報を取得するために使用される。
【０１５７】
図３３Ａは、所与のＯＩＤに対する値を獲得するための、CSNMPクラス３２０１の関数obtainValueFromGetRequestに関連するシーケンスを示している。
【０１５８】
図３３Ｂは、所与のＯＩＤに対する値を獲得するための、CSNMPクラス３２０１の関数obtainValueFromGetNextRequestに関連するシーケンスを示している。
【０１５９】
＜HTTPモジュール＞
HTTPモジュール２２０３は、ＨＴＴＰを用いてネットワークデバイスに関する情報を取得することを担当する。ネットワーク上の被監視デバイスは、ＨＴＭＬファイルを含むウェブサーバを含むかもしれない。HTTPモジュール２２０３はＨＴＭＬファイルにアクセスし、それらのＨＴＭＬファイルから所望の情報を抽出する。HTTPモジュール２２０３は、ＨＴＭＬファイル（複数可）のホームページのタイトルを取得することも担当する。
【０１６０】
図３４は、HTTPモジュール２２０３（HWAccessモジュール１１１６のサブモジュール）のクラス構造を示している。HTTPモジュール２２０３は、CHTTPクラス３４０１、CHTMLProcessorクラス３４０２、CHTMLTextProcessorクラス３４０３、CHTTPSessionクラス３４０４、ならびに３個のＭＦＣクラスCInternetSession３４０５、CHttpConnection３４０６、およびCHttpFile３４０７を含む。これらのクラスは、ＨＴＭＬフォーマットに基づいてＨＴＴＰプロトコルを通じて被監視ハードウェアデバイスから情報を取得するために使用される。
【０１６１】
図３５Ａは、ＨＴＭＬファイルから情報を獲得するための、CHTTPクラスのobtainTitleFromHomePage関数に関連するシーケンス図を示している。
【０１６２】
図３５Ｂは、ＨＴＭＬファイルから情報を獲得するための、CHTTPクラスのobtainDataFromHTMLFile関数に関連するシーケンス図を示している。
【０１６３】
図３６は、CHTMLTextProcessorクラスに関連する関数によってＨＴＭＬデータストリームを解析するために使用される状態遷移を示している。なお、図３６は、ＨＴＭＬファイルの一般的解析を示しているのではなく、デバイスを監視するためにＨＴＭＬファイルから最小限必要な情報を獲得するための解析を示していることに留意されたい。例えば、開始タグ内のSCRIPTおよびいかなる属性も無視される。この解析プロセスについては、以下で図４１に関してさらに詳細に説明する。
【０１６４】
＜SupportODBCモジュール＞
図３７は、SupportODBCモジュールのクラス構造を示している。末尾が「Table」のクラスは、上記のデータベース内のテーブルにアクセスするためにＭＦＣ内のCRecordから導出される。
【０１６５】
図３８は、CSupportODBC関数obtainHTTPWebPageInfoForVendorModelに対するシーケンス図を示している。この関数は２つのデータベーステーブルにアクセスすることに留意されたい。
【０１６６】
＜監視方法＞
図３９は、本発明による、ネットワークに通信可能に結合したリモート被監視デバイスに関連する要求情報を抽出する方法を示している。例えば、要求情報は、デバイスのベンダまたはモデルに関連する情報であり得る。さらに、特定のデバイスについて、要求情報が抽出される時に、追加的な非要求情報が直ちに取得可能なこともある。
【０１６７】
ステップ３９０１で、監視データを抽出すべきターゲットデバイスのＩＰアドレスを取得する。通常、この情報は少なくともサポートデータベース１０２４に格納されることになり、SupportODBCモジュール１１１４によって取得される。
【０１６８】
ステップ３９０２で、ＨＴＴＰプロトコルおよびＩＰアドレスを用いてデバイスにアクセスし、デバイスに関連する情報文字列を取得する。例えば、情報文字列は、デバイスのメモリに存在するＨＴＭＬファイルから抽出されてもよい。
【０１６９】
ステップ３９０３で、所定の方法に従って情報文字列を処理し、ベンダ情報等のデバイスに関連する要求情報を抽出する。ただし、取得された情報文字列は、特に要求されなかった有用なデバイス情報も含むかもしれない。
【０１７０】
そこで、ステップ３９０４で、情報文字列内で追加的デバイス情報を探索する。例えば、モデル情報は、デバイスに格納されているＨＴＭＬファイル内のベンダ情報の近くに見つかることが多い。追加的な非要求情報が情報文字列内に見つかった場合、その情報を抽出する。
【０１７１】
最後に、ステップ３９０５で、ステップ３９０３および３９０４で抽出された要求情報および追加的デバイス情報を、デバイスのＩＰアドレスに関連づけてキャッシュする。したがって、抽出された追加的情報は、別の時刻や別の通信プロトコルでは取得される必要がない。
【０１７２】
図４０は、本発明による、ネットワークに通信可能に結合した別個のデバイスのうちのリモート被監視デバイスに関連するステータス情報を抽出するために複数の通信プロトコルによって使用されるように構成された情報を効率的に格納する方法を示している。特に、デバイス情報の抽出をサポートするのに必要な情報は、個別のデバイスに基づいてDeviceモジュールによって格納されるのではなく、プロトコル、ベンダ、およびモデル情報に基づいてHWaccessモジュールによって格納される。サポート情報は、図３０Ａ、図３０Ｂ、図３１Ａおよび図３１Ｂに示したデータ構造体に格納される。さらに、サポート情報は、ベンダおよびモデル情報がデバイスについて収集される初期化時に、SupportODBCを通じて抽出され、これらのデータ構造体に格納される。
【０１７３】
ステップ４００１で、複数の通信プロトコル（ＳＮＭＰ、ＨＴＴＰ等）のうちから、デバイスにアクセスするために使用する通信プロトコルを選択する。
【０１７４】
次に、ステップ４００２で、特定のデバイスにアクセスするために選択された通信プロトコルをサポートするのに必要な情報が、内部ストレージテーブルに現在格納されているか、それともサポートデータベース１０２４にのみ格納されているかの問合せを行う。ステップ４００２の問合せに対する回答が、選択された通信プロトコルをサポートするのに必要な情報が内部ストレージテーブルに格納されていないという回答である場合、ステップ４００３および４００４を実行する。さもなければ、ステップ４００５を実行する。
【０１７５】
ステップ４００３で、選択された通信プロトコルをサポートするのに必要な情報をサポートデータベース１０２４から取得する。
【０１７６】
最後に、ステップ４００４で、サポートデータベース１０２４から取得された、選択された通信プロトコルをサポートするのに必要な情報を、例えば図３０Ａ、図３０Ｂ、図３１Ａ、および図３１Ｂに示した内部ストレージテーブルに格納する。
【０１７７】
図４１は、本発明による、情報文字列を解析してネットワークに通信可能に結合したリモート被監視デバイスに関連する要求情報を抽出する方法を示している。
【０１７８】
ステップ４１０１で、ＨＴＴＰプロトコルを用いて特定のデバイスにアクセスし、そのデバイスに関連する情報文字列を取得する。例えば、情報文字列は、デバイスに格納されているＨＴＭＬファイルから取得されてもよい。
【０１７９】
次に、ステップ４１０２で、要求情報のタイプに基づいて、デバイスから要求情報を最適に抽出するためのデータ抽出情報を判定する。好ましい一実施形態では、データ抽出情報としては、デバイスから要求情報を最適に抽出するためのキーワード、タイプ、および位置情報がある。例えば、データ抽出情報としては、図１２Ａに示したSKeyValueInfoデータ構造体内の情報があり得る。
【０１８０】
ステップ４１０３で、取得された情報文字列をデータ抽出情報に従って解析し、情報文字列内の種々のサブ文字列を識別する。例えば、「</script」のようなＨＴＭＬタグがステップ４１０３で抽出され識別される。
【０１８１】
最後に、ステップ４１０４で、情報文字列、識別されたサブ文字列、およびデータ抽出情報に基づいて要求情報を判定する。このステップで、図３６に示した有限状態機械の方法を用いて、データ抽出情報および識別されたサブ文字列に基づいて、要求情報が情報文字列から抽出される。例えば、ＨＴＭＬスクリプト情報は無視されてもよい。なお、ステップ４１０４の探索プロセスは、要求情報を抽出するためのマップとして働くデータ抽出情報（例えばSKeyValueInfo）の使用を通じて最適化される。上記の図１２Ａのデータ要素の関連する説明を参照されたい。
【０１８２】
図４２は、本発明による、ネットワークに通信可能に結合したリモート被監視デバイスに関連するステータス情報を効率的に抽出する方法を示している。
【０１８３】
ステップ４２０１で、第１通信プロトコル（例えばＳＮＭＰ）を用いてデバイスから取得すべきステータス値の第１ターゲットリストを決定する。通常、この情報は、サポートデータベース１０２４に最初に格納された後、図３１Ａおよび図３１Ｂのデータ構造体に格納される。
【０１８４】
次に、ステップ４２０２で、第２通信プロトコル（例えばＨＴＴＰ）を用いてデバイスから取得すべきステータス値の第２ターゲットリストを決定する。ステップ４２０２は、プロトコルが異なることを別にすれば、ステップ４２０１と類似している。なお、種々の理由で、第１および第２ターゲットリストは通常、抽出すべき同じステータス値を含まないことに留意されたい。
【０１８５】
ステップ４２０３で、上記の方法を用いることにより、第１通信プロトコルを用いて被監視デバイスにアクセスし、ステータス値の第１ターゲットリストのステータス値を抽出する。
【０１８６】
次に、ステップ４２０４で、ステップ４２０３でデバイスから取得されたステータス値をデバイスステータスマップに追加する。デバイスステータスマップは、抽出されたステータス値を、それぞれのinfoTypeの所定の固有識別子に関連づけて格納する。なお、特定のデバイスに対するデバイスステータスマップ内の各識別子はプロトコルとは無関係であることに留意されたい。
【０１８７】
最後に、ステップ４２０５で、第２通信プロトコルを用いて被監視デバイスにアクセスし、ステータス値の第２ターゲットリストのステータス値のうち、デバイスステータスマップにまだ格納されていないステータス値を抽出する。したがって、ステータス値の第２ターゲットリストは、まず、重複をチェックするために、デバイスステータスマップと比較されなければならない。これにより、別の通信プロトコルを用いて既に取得されたステータス値を抽出しようとしてリソースが浪費されることがなくなる。
【０１８８】
本発明は、ネットワークに接続された、監視を必要とする数個のデバイスを含むように示されているが、本発明の精神および範囲から逸脱することなく、いかなる個数のデバイスがネットワークに接続されてもよいことが理解される。また、本発明は、種々のデバイスが監視および制御されることを必要とするようなホーム環境に適用されてもよい。
【０１８９】
本発明は、特定のプライベート管理情報ベース（ＭＩＢ）情報を有することさえなしに、マルチベンダ環境における種々のデバイスの監視を可能にし、さらに、ユーザが理解しやすい、またはユーザが利用しやすいように、詳細な情報を取り出し表示することを容易にする。
【０１９０】
コンピュータ技術分野の当業者には明らかなように、本発明のコントローラは、本明細書の教示に従ってプログラムされた従来の汎用デジタルコンピュータまたはマイクロプロセッサを用いて都合よく実施されてもよい。ソフトウェア技術分野の当業者には明らかなように、適当なソフトウェアコーディングが、本明細書の教示に基づいて、通常の技術を有するプログラマによって容易に作成されることが可能である。当業者には直ちに明らかなように、本発明は、特定用途向け集積回路の作成によって、または従来のコンポーネント回路の適当なネットワークを相互接続することによって実施されてもよい。
【０１９１】
本発明は、本発明のプロセスを実行するようにコンピュータをプログラムするために使用可能な命令を含む記憶媒体に存在するコンピュータプログラム製品を含む。記憶媒体としては、以下のものには限定されないが、フロッピーディスク、光ディスク、ＣＤ−ＲＯＭ、および光磁気ディスクを含むいかなるタイプのディスク、ＲＯＭ、ＲＡＭ、ＥＰＲＯＭ、ＥＥＰＲＯＭ、磁気もしくは光カード、または電子的命令を格納するのに好適ないかなるタイプの媒体もあり得る。
【０１９２】
明らかに、上記の教示に照らして、本発明の数多くの変更および変形が可能である。したがって、添付の特許請求の範囲内で、本発明は本明細書に具体的に記載された以外の形で実施され得ることは理解される。
【図面の簡単な説明】
【０１９３】
【図１】インターネットを通じてコンピュータおよびデータベースのネットワークに接続された、３つのネットワーク接続された事務用デバイスを示す。
【図２】デジタル画像形成装置のコンポーネントを示す。
【図３】図２に示されるデジタル画像形成装置の電子コンポーネントを示す。
【図４】図３に示されるマルチポート通信インタフェースの詳細を示す。
【図５】事務用デバイスが、ネットワークに直接接続されるか、またはネットワークに接続されたコンピュータに接続される、代替システム構成を示す。
【図６Ａ】電子メールを用いたアプリケーションユニットとの間の情報の流れを示すブロック図である。
【図６Ｂ】アプリケーションユニットに接続されたコンピュータがメッセージ転送エージェント（ＭＴＡ）としても働く、電子メールを用いた通信の代替方法を示す。
【図６Ｃ】アプリケーションユニットが、電子メールを交換するメッセージ転送エージェントを含む、電子メールを用いた通信の代替方法を示す。
【図６Ｄ】メールサーバが機器／デバイスのメールを受信するＰＯＰ３サーバとして、および機器／デバイスのメールを送信するSimple  Mail  Transfer  Protocol（ＳＭＴＰ）サーバとして働く、電子メールを用いた通信の代替方法を示す。
【図７】インターネットを越えてメッセージを送信する代替方法を示す。
【図８】機器／デバイスに接続され電子メールメッセージを通信するために使用され得る例示的コンピュータを示す。
【図９】本発明の例示的な一実施形態によるシステム全体の概略図である。
【図１０】本発明の例示的な一実施形態によるデータの監視に使用されるモジュールおよびそれらのインタフェース関数を示す。
【図１１】Monitorモジュール内の詳細およびサブモジュール間のその呼出し関数を示す。
【図１２Ａ】図１１に示されるHWaccessサブモジュールおよびSupportInfoODBCサブモジュールによって使用されるデータ構造体を示す。
【図１２Ｂ】オブジェクト識別子（ＯＩＤ）を情報タイプと関連づける例示的データ構造体を示す。
【図１３】図１０に示されるMonitorモジュールのinit関数のシーケンスを示す。
【図１４】図１１に示されるMonitorManagerによって被監視デバイスのステータスを判定するステータスモニタ関数の例示的シーケンスを示す。
【図１５】図１３に示されるCDeviceFactoryによって作成されMonitorManagerによって使用されるデバイスへの参照のベクタを示す。
【図１６】図１１に示されるHWaccessモジュールを通じて情報収集をサポートするためにデータベースに格納されるテーブル関係を示す。
【図１７】HWaccessモジュールに情報を格納するステップを示す例示的フローチャートである。
【図１８】複数のプロトコルを用いてネットワークデバイスを監視するステップを示す例示的フローチャートである。
【図１９】DeviceODBCモジュールのクラス構造を示す。
【図２０】本発明によるDeviceモジュールのクラス構造を示す。
【図２１】本発明によるデバイスソフトウェアオブジェクト作成シーケンスを示す。
【図２２】ＳＮＭＰおよびＨＴＴＰ等の、デバイスにアクセスするために使用される異なるプロトコルを含むHWAccessモジュール構造を、Accessモジュール内のアクセスクラスとともに示す。
【図２３】本発明によるHWAccessモジュールのインタフェースクラスであるCHWaccessクラスを示す。
【図２４】プロセスがSupportODBCクラスオブジェクトを作成しそれをCSNMPAccessクラスオブジェクトおよびCHTTPAccessクラスオブジェクトの両方に、それらのinitBegin関数を通じて渡す、HWAccessモジュール内の３個のクラスの初期化プロセスを示す。
【図２５】本発明による、デバイスがＳＮＭＰおよびＨＴＴＰプロトコルを通じて特定のＩＰアドレスでアクセス可能かどうかをチェックするプロセスを示す。
【図２６】デバイスからベンダ名を取得した後、SupportODBCから取得されるベンダ関連情報を格納するシーケンスを示す。
【図２７】本発明によるモデル情報を取得するシーケンスを示す。
【図２８】本発明による、第１にＳＮＭＰを通じて、第２に、ＳＮＭＰが失敗した場合、ＨＴＴＰを通じて、デバイスから固有ＩＤを取得するシーケンスを示す。
【図２９】本発明による、まずＳＮＭＰ、次にＨＴＴＰにより、デバイスからステータスを取得するシーケンスを示す。
【図３０Ａ】システムによってサポートされるデバイスに関する情報を管理するためにCHTTPAccessによって使用されるデータ構造体を示す。
【図３０Ｂ】デバイスからのステータス情報にアクセスするために使用される情報を管理するためにCHTTPAccessによって使用されるデータ構造体を示す。
【図３１Ａ】システムによってサポートされるデバイスに関する情報を管理するためにCSNMPAccessによって使用されるデータ構造体を示す。
【図３１Ｂ】デバイスからのステータス情報にアクセスするために使用される情報を管理するためにCSNMPAccessによって使用されるデータ構造体を示す。
【図３２】ＳＮＭＰプロトコルを通じてデバイスから情報を取得するために使用される３個のクラスを含む、SNMPモジュールクラス構造を示す。
【図３３Ａ】所与のＯＩＤに対する値を獲得するために使用されるCSNMP関数（obtainValueFromGetRequest）の呼出しシーケンスを示す。
【図３３Ｂ】所与のＯＩＤに対する値を獲得するために使用されるCSNMP関数（obtainValueFromGetNextRequest）の呼出しシーケンスを示す。
【図３４】ＨＴＭＬフォーマットに基づいてＨＴＴＰプロトコルを通じてデバイスから情報を取得するために使用されるクラスを含む、HTTPモジュールクラス構造を示す。
【図３５Ａ】デバイスに関連するＨＴＭＬファイルから情報を獲得するために使用されるCHTTP関数（obtainTitleFromHomePage）の呼出しシーケンスを示す。
【図３５Ｂ】デバイスに関連するＨＴＭＬファイルから情報を獲得するために使用されるCHTTP関数（obtainDataFromHTMLFile）の呼出しシーケンスを示す。
【図３６】CHTMLTextProcessor内のＨＴＭＬファイルを解析するために使用される状態遷移図を示す。
【図３７】本発明によるSupportODBCモジュールクラス構造を示す。
【図３８】CSupportODBC関数obtainHTTPWebPageInfoForVendorModelを用いたシーケンス図を示す。
【図３９】本発明による、ネットワークに通信可能に結合したリモート被監視デバイスに関連する要求情報を抽出する方法のフローチャートである。
【図４０】本発明による、ネットワークに通信可能に結合した別個のデバイスのうちのリモート被監視デバイスに関連するステータス情報を抽出するために、複数の通信プロトコルによって使用されるように構成された情報を効率的に格納する方法のフローチャートである。
【図４１】本発明による、情報文字列を解析してネットワークに通信可能に結合したリモート被監視デバイスに関連する要求情報を抽出する方法のフローチャートである。
【図４２】本発明による、ネットワークに通信可能に結合したリモート被監視デバイスに関連するステータス情報を効率的に抽出する方法のフローチャートである。
【図１】
2005004735.tif 000004
【図２】
2005004735.tif 000005
【図３】
2005004735.tif 000006
【図４】
2005004735.tif 000007
【図５】
2005004735.tif 000008
【図６Ａ】
2005004735.tif 000009
【図６Ｂ】
2005004735.tif 000010
【図６Ｃ】
2005004735.tif 000011
【図６Ｄ】
2005004735.tif 000012
【図７】
2005004735.tif 000013
【図８】
2005004735.tif 000014
【図９】
2005004735.tif 000015
【図１０】
2005004735.tif 000016
【図１１】
2005004735.tif 000017
【図１２Ａ】
2005004735.tif 000018
【図１２Ｂ】
2005004735.tif 000019
【図１３】
2005004735.tif 000020
【図１４】
2005004735.tif 000021
【図１５】
2005004735.tif 000022
【図１６】
2005004735.tif 000023
【図１７】
2005004735.tif 000024
【図１８】
2005004735.tif 000025
【図１９】
2005004735.tif 000026
【図２０】
2005004735.tif 000027
【図２１】
2005004735.tif 000028
【図２２】
2005004735.tif 000029
【図２３】
2005004735.tif 000030
【図２４】
2005004735.tif 000031
【図２５】
2005004735.tif 000032
【図２６】
2005004735.tif 000033
【図２７】
2005004735.tif 000034
【図２８】
2005004735.tif 000035
【図２９】
2005004735.tif 000036
【図３０Ａ】
2005004735.tif 000037
【図３０Ｂ】
2005004735.tif 000038
【図３１Ａ】
2005004735.tif 000039
【図３１Ｂ】
2005004735.tif 000040
【図３２】
2005004735.tif 000041
【図３３Ａ】
2005004735.tif 000042
【図３３Ｂ】
2005004735.tif 000043
【図３４】
2005004735.tif 000044
【図３５Ａ】
2005004735.tif 000045
【図３５Ｂ】
2005004735.tif 000046
【図３６】
2005004735.tif 000047
【図３７】
2005004735.tif 000048
【図３８】
2005004735.tif 000049
【図３９】
2005004735.tif 000050
【図４０】
2005004735.tif 000051
【図４１】
2005004735.tif 000052
【図４２】
2005004735.tif 000053