(57)【要約】【課題】マルチベンダ環境における種々のデバイスの監視を可能にする。【解決手段】監視システムに通信可能に結合した１つまたは複数の被監視デバイスと、その１つまたは複数の被監視デバイスに関する情報を有するデータベースとを有し、監視システムが被監視デバイスに関する情報を取り出すためにデータベースにアクセスすることを可能にし、データベースから取り出された情報を第１データ構造体に設定し、データベースからの情報を用いて被監視デバイスが監視システムによってサポートされるかどうかを判定し、被監視デバイスが監視システムによってサポートされると判定された場合、被監視デバイスのステータス情報を取得するために被監視デバイスとの通信を確立する。【選択図】図１
2004213654.tif 000002
【特許請求の範囲】
【請求項１】
監視システムに通信可能に結合した１つまたは複数の被監視デバイスと、該１つまたは複数の被監視デバイスに関する情報を有するデータベースとを有する通信システムにおいて、前記監視システムで前記被監視デバイスに関する情報を取得および保守する方法であって、
（ａ）前記監視システムが前記被監視デバイスに関する情報を取り出すために前記データベースにアクセスするステップと、
（ｂ）前記データベースから取り出された情報を第１データ構造体に設定するステップと、
（ｃ）前記データベースからの情報を使用して被監視デバイスが前記監視システムによってサポートされるかどうかを判定するステップと、
（ｄ）前記被監視デバイスが前記監視システムによってサポートされると判定された場合、前記被監視デバイスのステータス情報を取得するために前記被監視デバイスとの通信を確立するステップと、
を含む被監視デバイスに関する情報を取得および保守する方法。
【請求項２】
前記被監視デバイスのベンダおよびモデルに関する情報を前記データベースに格納する請求項１に記載の被監視デバイスに関する情報を取得および保守する方法。
【請求項３】
ステップ（ｂ）は、ベンダ、モデルに関する情報、および被監視デバイスの固有識別子を取得するための情報を取り出すことをさらに含み、
ステップ（ｄ）は、ＨＴＴＰ通信プロトコルを使用して実行される、
請求項１に記載の被監視デバイスに関する情報を取得および保守する方法。
【請求項４】
それぞれの被監視デバイスのウェブページから情報を取り出すことをさらに含む請求項３に記載の被監視デバイスに関する情報を取得および保守する方法。
【請求項５】
前記監視システムによってサポートされる被監視デバイスのベンダに関する情報を格納すること、および
被監視デバイスのモデルを該被監視デバイスのウェブページから取得するために使用される情報を格納すること、
をさらに含む請求項４に記載の被監視デバイスに関する情報を取得および保守する方法。
【請求項６】
前記データベースから取り出された情報を前記第１データ構造体の複数のフィールドに設定することをさらに含み、前記第１データ構造体は、
被監視デバイスのベンダに関する情報を有する第１フィールドと、
前記被監視デバイスのモデル情報を有するウェブページへの参照を有する第２フィールドと、
前記被監視デバイスのウェブページからモデル情報を取得するために使用される情報を有する第３フィールドと、
を含む請求項４に記載の被監視デバイスに関する情報を取得および保守する方法。
【請求項７】
監視システムで１つまたは複数の被監視デバイスに関する情報を取得および保守する方法であって、
（ａ）前記被監視デバイスに関するベンダ情報およびベンダモデル情報をデータベースに格納するステップと、
（ｂ）監視システムが前記格納されているベンダ情報およびベンダモデル情報を取り出すために前記データベースにアクセスするステップと、
（ｃ）前記データベースから取り出されたベンダ情報を第１データ構造体に設定するステップと、
（ｄ）前記第１データ構造体に設定されるべきさらなるベンダ情報が残っていない場合、ベンダモデル情報を第２データ構造体に設定するステップと、
（ｅ）前記データベースからの情報を使用して被監視デバイスが前記監視システムによってサポートされるかどうかを判定するステップと、
（ｆ）被監視デバイスが前記監視システムによってサポートされると判定された場合、該被監視デバイスとの通信を確立することであって、それによって、該被監視デバイスのステータス情報を取得する、通信を確立するステップと、
を含む１つまたは複数の被監視デバイスに関する情報を取得および保守する方法。
【請求項８】
ステップ（ｃ）は、被監視デバイスのベンダ名、該被監視デバイスのモデル名を有するウェブページ、および該ウェブページから該モデル名を取得するための情報を前記第１データ構造体のサブデータ構造体に設定すること、
をさらに含む請求項７に記載の１つまたは複数の被監視デバイスに関する情報を取得および保守する方法。
【請求項９】
前記第１データ構造体の前記サブデータ構造体をデータ構造体ベクタに追加すること、
前記モデル名および前記第１データ構造体の前記サブデータ構造体をデータ構造体マップに追加すること、および
前記ベンダ名および前記データ構造体マップを、ベンダモデルＩＤマップを表すデータ構造体に追加すること、
をさらに含む請求項８に記載の１つまたは複数の被監視デバイスに関する情報を取得および保守する方法。
【請求項１０】
（ｉ）前記データ構造体ベクタからのエントリを使用することであって、それによって、被監視デバイスのウェブページにアクセスする、エントリを使用すること、
（ｉｉ）前記アクセスされた被監視デバイスのベンダを、前記第１データ構造体の前記サブデータ構造体内のベンダ名として識別すること、
（ｉｉｉ）前記第１データ構造体の前記サブデータ構造体内の情報を使用して前記ウェブページから前記被監視デバイスのモデル名を取得すること、および
（ｉｖ）前記被監視デバイスの前記モデル名が前記監視システムによってサポートされるかどうかを判定するために、前記モデル名を前記第２データ構造体に格納されている情報と比較すること、
をさらに含む請求項９に記載の１つまたは複数の被監視デバイスに関する情報を取得および保守する方法。
【請求項１１】
前記監視システムが前記ウェブページにアクセスすることができない場合または前記モデル名を前記ウェブページから取得することができない場合に、前記データ構造体ベクタのすべての要素についてステップ（ｉ）ないし（ｉｖ）を反復すること、および
前記データ構造体ベクタのすべての要素にわたる反復後に前記監視システムが前記被監視デバイスの前記ベンダおよびモデル名を取得することに不成功である場合、前記被監視デバイスは前記監視システムによってサポートされないと判定すること、
をさらに含む請求項１０に記載の１つまたは複数の被監視デバイスに関する情報を取得および保守する方法。
【請求項１２】
監視システムに通信可能に結合した１つまたは複数の被監視デバイスと、該１つまたは複数の被監視デバイスに関する情報を有するデータベースとを有する通信システムにおいて、前記監視システムで前記被監視デバイスに関する情報を取得および保守する装置であって、
前記監視システムが前記被監視デバイスに関する情報を取り出すために前記データベースにアクセスすることを可能にする手段と、
前記データベースから取り出された情報を第１データ構造体に設定する手段と、
前記データベースからの情報を使用して被監視デバイスが前記監視システムによってサポートされるかどうかを判定する手段と、
前記被監視デバイスが前記監視システムによってサポートされると判定された場合、前記被監視デバイスのステータス情報を取得するためにＨＴＴＰプロトコルを使用して前記被監視デバイスとの通信を確立する手段と、
を備える監視デバイスに関する情報を取得および保守する装置。
【請求項１３】
前記被監視デバイスのベンダおよびモデルに関する情報を前記データベースに格納する手段、
をさらに備える請求項１２に記載の被監視デバイスに関する情報を取得および保守する装置。
【請求項１４】
情報を第１データ構造体に設定する手段は、ベンダ、モデルに関する情報、および被監視デバイスの固有識別子を取得するための情報を取り出す手段をさらに備える請求項１２に記載の被監視デバイスに関する情報を取得および保守する装置。
【請求項１５】
それぞれの被監視デバイスのウェブページから情報を取り出す手段、
をさらに備える請求項１４に記載の被監視デバイスに関する情報を取得および保守する装置。
【請求項１６】
前記監視システムによってサポートされる被監視デバイスのベンダに関する情報を格納する手段と、
被監視デバイスのモデルを該被監視デバイスのウェブページから取得するために使用される情報を格納する手段と、
をさらに備える請求項１５に記載の被監視デバイスに関する情報を取得および保守する装置。
【請求項１７】
監視システムで１つまたは複数の被監視デバイスに関する情報を取得および保守する装置であって、
前記被監視デバイスに関するベンダ情報およびベンダモデル情報をデータベースに格納する手段と、
監視システムが前記格納されているベンダ情報およびベンダモデル情報を取り出すために前記データベースにアクセスすることを可能にする手段と、
前記データベースから取り出されたベンダ情報を第１データ構造体に設定する手段と、
前記第１データ構造体に設定されるべきさらなるベンダ情報が残っていない場合、ベンダモデル情報を第２データ構造体に設定する手段と、
前記データベースからの情報を使用して被監視デバイスが前記監視システムによってサポートされるかどうかを判定する手段と、
被監視デバイスが前記監視システムによってサポートされると判定された場合、該被監視デバイスとの通信を確立する手段であって、それによって、該被監視デバイスのステータス情報を取得する、通信を確立する手段と、
を備える１つまたは複数の被監視デバイスに関する情報を取得および保守する装置。
【請求項１８】
監視システムに通信可能に結合した１つまたは複数の被監視デバイスを有する通信システムにおいて、被監視デバイスのステータス情報を取得する方法であって、
（ｉ）ＨＴＴＰプロトコルを使用して前記被監視デバイスとの通信セッションを作成するステップと、
（ｉｉ）前記被監視デバイスのウェブページに、該ウェブページに表示される情報を取得するためにアクセスするステップと、
（ｉｉｉ）前記被監視デバイスの前記ステータス情報を取得するために、第１および第２データ構造体ベクタを使用して前記表示される情報を解析するステップと、
（ｉｖ）前記ウェブページに表示される前記情報をすべて解析した後、または所望のステータス情報を取得した後、前記通信セッションを終結させるステップと、
を含む被監視デバイスのステータス情報を取得する方法。
【請求項１９】
前記被監視デバイスの複数のウェブページについて、ステップ（ｉ）〜（ｉｖ）を反復することをさらに含む請求項１８に記載の被監視デバイスのステータス情報を取得する方法。
【請求項２０】
前記情報を解析するステップは、第１および第２データ構造体ベクタを使用して実行され、それによって、表示される情報の１行について一度に前記被監視デバイスの前記ウェブページから情報を探索し取得する、
請求項１８に記載の被監視デバイスのステータス情報を取得する方法。
【請求項２１】
前記ウェブページに表示される情報からキーを識別するステップ、および
前記キーに対応する値を識別するステップ、
をさらに含む請求項１８に記載の被監視デバイスのステータス情報を取得する方法。
【請求項２２】
前記キーに対応する値を識別するステップは、前記第１および第２データ構造体ベクタの要素の複数のフィールドを使用して実行される、
請求項２１に記載の被監視デバイスのステータス情報を取得する方法。
【請求項２３】
前記第１データ構造体ベクタの前記要素の前記複数のフィールドは、nPosition、sDelimiter、およびnInLinePositionフィールドを含み、
前記第２データ構造体ベクタの前記要素の前記複数のフィールドは、nCounterおよびbValueObtainedフィールドを含む、
請求項２２に記載の被監視デバイスのステータス情報を取得する方法。
【請求項２４】
前記キーを識別するステップは、前記第１データ構造体ベクタの第１フィールドからのデータを使用して実行され、
前記キーに対応する値を識別するステップは、前記第１および第２データ構造体ベクタの要素の複数のフィールドからのデータを使用することによって実行される、
請求項２１に記載の被監視デバイスのステータス情報を取得する方法。
【請求項２５】
前記第１および第２データ構造体ベクタの要素間の一対一対応を提供すステップ、
をさらに含む請求項１８に記載の被監視デバイスのステータス情報を取得する方法。
【請求項２６】
キーに対応する値が前記ウェブページからの情報の解析された行から取得された場合、前記被監視デバイスに関する情報を有するマップに、該キーおよび値に対応する情報を追加すること、
をさらに含む請求項２５に記載の被監視デバイスのステータス情報を取得する方法。
【請求項２７】
被監視デバイスから情報を取得する方法であって、
（ｉ）ＨＴＴＰプロトコルを使用して前記被監視デバイスにアクセスするステップと、
（ｉｉ）前記被監視デバイスのウェブページに表示される情報を取り出すステップと、
（ｉｉｉ）第１および第２データ構造体ベクタを使用して前記取り出された情報から識別子を探索するために前記表示される情報を解析するステップと、
（ｉｖ）前記取り出された情報から前記識別子に対応する値を検索するステップと、
を含む被監視デバイスから情報を取得する方法。
【請求項２８】
前記ウェブページに表示される情報の各行について、または所望の情報が前記ウェブページから取得されるまで、ステップ（ｉｉｉ）および（ｉｖ）を反復することをさらに含む請求項２７に記載の被監視デバイスから情報を取得する方法。
【請求項２９】
前記情報を解析するステップは、表示される情報の各行について、ならびに前記第１および第２データ構造体ベクタの各要素について実行される、
請求項２７に記載の被監視デバイスから情報を取得する方法。
【請求項３０】
前記識別子に対応する値を検索するステップは、前記第１および第２データ構造体ベクタの要素の複数のフィールドに配置される情報を使用して実行される、
請求項２７に記載の被監視デバイスから情報を取得する方法。
【請求項３１】
前記第１データ構造体ベクタの前記要素の前記複数のフィールドは、nPosition、sDelimiter、およびnInLinePositionフィールドを含み、
前記第２データ構造体ベクタの前記要素の前記複数のフィールドは、nCounterおよびbValueObtainedフィールドを含む、
請求項３０に記載の被監視デバイスから情報を取得する方法。
【請求項３２】
前記識別子を探索するために前記表示される情報を解析するステップは、前記第１データ構造体ベクタの第１フィールドからのデータを使用して実行され、
前記識別子に対応する値を識別するステップは、前記第１および第２データ構造体ベクタの要素の複数のフィールドからのデータを使用して実行される、
請求項２７に記載の被監視デバイスから情報を取得する方法。
【請求項３３】
前記第１および第２データ構造体ベクタの要素間の一対一対応を提供するステップ、
をさらに含む請求項２７に記載の被監視デバイスから情報を取得する方法。
【請求項３４】
前記識別子に対応する前記値が前記ウェブページからの解析された情報から取得された場合、前記被監視デバイスに関する情報を有するマップに、該識別子に対応する情報および該識別子に対応する前記値を追加すること、
をさらに含む請求項３３に記載の被監視デバイスから情報を取得する方法。
【請求項３５】
監視システムに通信可能に結合した１つまたは複数の被監視デバイスを有する通信システムにおいて、被監視デバイスのウェブページから情報を取得する方法であって、
前記ウェブページに表示される情報を取り出すステップと、
第１および第２データ構造体ベクタを使用して前記表示される情報を解析するステップとであって、前記取り出された情報からのキーおよび対応する値を探索するために実行される、該情報を解析するステップと、
前記第１および第２データ構造体ベクタに対応するベクタ反復子を前記第１および第２データ構造体ベクタの最初にセットするステップと、
を含む被監視デバイスのウェブページから情報を取得する方法。
【請求項３６】
前記ベクタ反復子がそれぞれの第１および第２データ構造体ベクタの最後に来るまで前記解析するステップを実行するステップ、および
前記第１および第２データ構造体ベクタの次の要素を指すように前記ベクタ反復子をインクリメントするステップ、
をさらに含む請求項３５に記載の被監視デバイスのウェブページから情報を取得する方法。
【請求項３７】
前記第１および第２データ構造体ベクタの要素の複数のフィールドに配置される情報を使用して、前記キーに対応する値を取得すること、
をさらに含む請求項３６に記載の被監視デバイスのウェブページから情報を取得する方法。
【請求項３８】
前記キーに対応する値を前記ウェブページからの表示される情報の行から取得することができない場合、前記第１および第２データ構造体ベクタの次の要素を指すようにカウンタを更新しベクタ反復子をインクリメントすること、
をさらに含む請求項３７に記載の被監視デバイスのウェブページから情報を取得する方法。
【請求項３９】
前記キーおよび対応する値に関する情報を、該対応する値が前記ウェブページからの表示される情報の行から取得された場合に前記被監視デバイスに関する情報を有するマップに追加すること、
をさらに含む請求項３８に記載の被監視デバイスのウェブページから情報を取得する方法。
【請求項４０】
被監視デバイスのウェブページから情報を取得する方法であって、
（ｉ）前記ウェブページに表示される情報を読み込むステップと、
（ｉｉ）前記読み込まれた情報を解析するステップと、
（ｉｉｉ）前記ウェブページに表示される情報の各行について、第１および第２データ構造体ベクタの各要素を使用して、キーおよび対応する値情報を判定するステップと、
（ｉｖ）キーおよび対応する値情報が要素に対して見つかった場合、前記第１および第２データ構造体ベクタのそれぞれから該要素を除去するステップと、
を含む被監視デバイスのウェブページから情報を取得する方法。
【請求項４１】
前記キーに対応する情報のすべての値が取得されるまで、前記ウェブページに表示される情報の各行についてステップｉｉ）ないしｉｖ）を反復すること、
をさらに含む請求項４０に記載の被監視デバイスのウェブページから情報を取得する方法。
【請求項４２】
前記第１および第２データ構造体ベクタのすべての要素についてキーおよび値情報を判定するステップ、
をさらに含む請求項４１に記載の被監視デバイスのウェブページから情報を取得する方法。
【請求項４３】
前記第１および第２データ構造体ベクタの間の一対一対応を提供するステップ、
をさらに含む請求項４１に記載の被監視デバイスのウェブページから情報を取得する方法。
【請求項４４】
前記キーおよび対応する値に対応する情報を、該対応する値が前記解析された情報から取得された場合に前記被監視デバイスに関する情報を有するマップに追加すること、
をさらに含む請求項４３に記載の被監視デバイスのウェブページから情報を取得する方法。
【請求項４５】
監視システムに通信可能に結合した１つまたは複数の被監視デバイスを有する通信システムにおいて、被監視デバイスのステータス情報を取得する装置であって、
ＨＴＴＰプロトコルを使用して前記被監視デバイスとの通信セッションを作成する手段と、
前記被監視デバイスのウェブページに、該ウェブページに表示される情報を取得するためにアクセスする手段と、
前記被監視デバイスの前記ステータス情報を取得するために、第１および第２データ構造体ベクタを使用して前記表示される情報を解析する手段と、
前記ウェブページに表示される前記情報をすべて解析した後、または所望のステータス情報を取得した後、前記通信セッションを終結させる手段と、
を備える被監視デバイスのステータス情報を取得する装置。
【請求項４６】
監視システムに通信可能に結合した１つまたは複数の被監視デバイスを有する通信システムにおいて、被監視デバイスから情報を取得する装置であって、
ＨＴＴＰプロトコルを使用して前記被監視デバイスにアクセスする手段と、
前記被監視デバイスのウェブページに表示される情報を取り出す手段と、
第１および第２データ構造体ベクタを使用して前記取り出された情報から識別子を探索するために前記表示される情報を解析する手段と、
前記取り出された情報から前記識別子に対応する値を検索する手段と、
を備える被監視デバイスから情報を取得する装置。
【請求項４７】
被監視デバイスのウェブページから情報を取得する装置であって、
前記被監視デバイスのウェブページに表示される情報を読み込む手段と、
前記読み込まれた情報を解析する手段と、
前記ウェブページに表示される情報の各行について、第１および第２データ構造体ベクタの各要素を使用して、キーおよび対応する値情報を判定する手段と、
キーおよび対応する値情報が要素に対して見つかった場合、前記第１および第２データ構造体ベクタのそれぞれから該要素を除去する手段と、
を備える被監視デバイスのウェブページから情報を取得する装置。
【請求項４８】
被監視デバイスから情報を取得するための処理をコンピュータに実行させるコンピュータプログラム製品であって、
前記被監視デバイスのウェブページに表示される情報を読み込むロジックと、
前記読み込まれた情報を解析するロジックと、
前記ウェブページに表示される情報の各行について、第１および第２データ構造体ベクタの各要素を使用して、キーおよび対応する値情報を判定するロジックと、
キーおよび対応する値情報が要素に対して見つかった場合、前記第１および第２データ構造体ベクタのそれぞれから該要素を除去するロジックと、
を備えるコンピュータプログラム製品。
【請求項４９】
被監視デバイスのステータス情報を取得する方法であって、
（ｉ）ＨＴＴＰプロトコルを使用して前記被監視デバイスとの通信セッションを作成するステップと、
（ｉｉ）前記被監視デバイスのウェブページに、該ウェブページに表示される情報を取得するためにアクセスするステップと、
（ｉｉｉ）第１および第２データ構造体ベクタを使用して、前記ウェブページから取得した情報を解析するステップと、
（ｉｖ）前記ウェブページに表示される前記情報をすべて解析した後、または所望のステータス情報を取得した後、前記通信セッションを終結させるステップと、
を含む被監視デバイスのステータス情報を取得する方法。
【請求項５０】
監視システムに通信可能に結合した１つまたは複数の被監視デバイスを有する通信システムにおいて、被監視デバイスのステータス情報を取得する方法であって、
（ａ）被監視デバイスに関する情報を有するデータベースにアクセスするステップと、
（ｂ）前記データベースから前記情報を取り出すステップと、
（ｃ）前記取り出された情報をマップ構造体に設定するステップと、
（ｄ）前記マップ構造体からの情報を使用して前記被監視デバイスに関連する１つまたは複数のウェブページから前記ステータス情報を取得するステップと、
を含む被監視デバイスのステータス情報を取得する方法。
【請求項５１】
前記データベースが前記被監視デバイスの前記１つまたは複数のウェブページからステータス情報を抽出するために使用されるさらなる情報を有しなくなるまで、前記ステータス情報を取得するために前記データベースから情報を取り出すステップを反復すること、
をさらに含む請求項５０に記載の被監視デバイスのステータス情報を取得する方法。
【請求項５２】
前記マップ構造体に前記被監視デバイスの１つまたは複数のウェブページに関する情報を提供するステップ、および
前記マップ構造体からの情報を使用するステップであって、それによって、前記被監視デバイスのステータス情報を取得する、情報を使用するステップ、
をさらに含む請求項５０に記載の被監視デバイスのステータス情報を取得する方法。
【請求項５３】
ステップ（ａ）は、前記被監視デバイスのベンダおよびベンダモデル識別子情報を識別すること、
をさらに含む請求項５０に記載の被監視デバイスのステータス情報を取得する方法。
【請求項５４】
前記被監視デバイスのベンダおよびベンダモデル情報に関連する１つまたは複数のウェブページを判定すること、
をさらに含む請求項５３に記載の被監視デバイスのステータス情報を取得する方法。
【請求項５５】
前記データベースから情報を取り出すステップ（ｂ）は、
前記被監視デバイスのステータスを判定するために使用されるベンダおよびベンダモデル識別子情報を有する前記データベース内のテーブルへのインタフェースを提供すること、および
前記被監視デバイスの前記ベンダおよびベンダモデル情報に関連する前記１つまたは複数のウェブページを判定すること、
をさらに含む請求項５０に記載の被監視デバイスのステータス情報を取得する方法。
【請求項５６】
前記被監視デバイスに関連する前記１つまたは複数のウェブページから前記被監視デバイスの前記ステータス情報を判定するために使用されるベンダおよびベンダモデル識別子情報を有するテーブルへのインタフェースを提供すること、
をさらに含む請求項５５に記載の被監視デバイスのステータス情報を取得する方法。
【請求項５７】
監視システムに通信可能に結合した１つまたは複数の被監視デバイスを有する通信システムにおいて、被監視デバイスのステータス情報を取得する際に使用するためにデータベースから取り出された情報を再編成する方法であって、
前記データベースにアクセスし、被監視デバイスのステータス情報を取得するために使用される情報を取り出すステップと、
前記データベースから取り出された情報をデータ構造体に設定するステップであって、該データ構造体からの該情報が使用されて、それによって、前記被監視デバイスに関連する１つまたは複数のウェブページからステータス情報が取得される、情報をデータ構造体に設定するステップと、
を含むデータベースから取り出された情報を再編成する方法。
【請求項５８】
前記被監視デバイスの前記ステータス情報を取得するために使用される情報を前記データベースの第１および第２テーブルに格納するステップ、
をさらに含む請求項５７に記載のデータベースから取り出された情報を再編成する方法。
【請求項５９】
前記データ構造体に設定するステップは、呼出しシーケンスを開始して前記データベースの前記第１および第２テーブルから情報を取得することによって実行される、
請求項５７に記載のデータベースから取り出された情報を再編成する方法。
【請求項６０】
前記被監視デバイスの前記ステータス情報を取得する際に使用するためのさらなる情報が前記第１および第２テーブルから取り出されなくなるまで前記呼出しシーケンスを反復すること、
をさらに含む請求項５８に記載のデータベースから取り出された情報を再編成する方法。
【請求項６１】
被監視デバイスに関連する１つまたは複数のウェブページからステータス情報を取り出す際に使用するためにデータベースから情報を取得する方法であって、
（ａ）前記被監視デバイスの前記１つまたは複数のウェブページに対応する識別子を取得するステップと、
（ｂ）前記識別子をフィルタとして使用してデータベースに格納されている情報をフィルタリングするステップと、
（ｃ）前記フィルタリングされた情報を前記データベースの１つまたは複数のテーブルに格納するステップと、
（ｄ）前記１つまたは複数のテーブルに格納された前記フィルタリングされた情報を使用するステップであって、それによって、前記被監視デバイスのステータス情報を取得する、情報を使用するステップと、
を含むデータベースから情報を取得する方法。
【請求項６２】
ステップ（ａ）は、
前記被監視デバイスの特定のベンダおよびモデルに関連するウェブページ情報ならびに対応するベンダモデル識別子を前記データベースから取得すること、および
前記取得されたウェブページ情報およびベンダモデル識別子をデータ構造体ベクタに入れること、
をさらに含む請求項６１に記載のデータベースから情報を取得する方法。
【請求項６３】
ステップ（ｂ）は、
前記フィルタによって指定されるベンダモデル識別子の範囲内の情報を取り出すために、前記データ構造体ベクタに入れられた情報をフィルタリングすること、
をさらに含む請求項６１に記載のデータベースから情報を取得する方法。
【請求項６４】
監視システムに通信可能に結合した１つまたは複数の被監視デバイスを有する通信システムにおいて、被監視デバイスのステータス情報を取得するシステムであって、
被監視デバイスに関する情報を有するデータベースにアクセスする手段と、
前記データベースから前記情報を取り出す手段と、
前記取り出された情報をマップ構造体に設定する手段と、
前記マップ構造体からの情報を使用して前記被監視デバイスに関連する１つまたは複数のウェブページから前記ステータス情報を取得する手段と、
を備える被監視デバイスのステータス情報を取得するシステム。
【請求項６５】
前記データベースが前記被監視デバイスの前記１つまたは複数のウェブページからステータス情報を抽出する際に使用するためのさらなる情報を有しなくなるまで、前記ステータス情報を取得するために前記データベースから情報を取り出すことを反復する手段、
をさらに備える請求項６４に記載の被監視デバイスのステータス情報を取得するシステム。
【請求項６６】
前記マップ構造体は、前記被監視デバイスの１つまたは複数のウェブページに関する情報を提供し、該ウェブページからステータス情報が探索される、
請求項６４に記載の被監視デバイスのステータス情報を取得するシステム。
【請求項６７】
前記データベースにアクセスする手段は、前記被監視デバイスのベンダおよびベンダモデル識別子情報を識別する手段をさらに含む、
請求項６４に記載の被監視デバイスのステータス情報を取得するシステム。
【請求項６８】
前記被監視デバイスのベンダおよびベンダモデル情報に関連する１つまたは複数のウェブページを判定する手段、
をさらに備える請求項６７に記載の被監視デバイスのステータス情報を取得するシステム。
【請求項６９】
前記データベースから情報を取り出す手段は、
前記被監視デバイスのステータスを判定するために使用されるベンダおよびベンダモデル識別子情報を有する前記データベース内のテーブルへのインタフェースと、
前記被監視デバイスの前記ベンダおよびベンダモデル情報に関連する前記１つまたは複数のウェブページを判定する手段と、
をさらに備える請求項６４に記載の被監視デバイスのステータス情報を取得するシステム。
【請求項７０】
前記被監視デバイスに関連する前記１つまたは複数のウェブページから前記被監視デバイスの前記ステータス情報を判定するために使用されるベンダおよびベンダモデル識別子情報を有するテーブルへのインタフェース、
をさらに備える請求項６９に記載の被監視デバイスのステータス情報を取得するシステム。
【請求項７１】
監視システムに通信可能に結合した１つまたは複数の被監視デバイスを有する通信システムにおいて、被監視デバイスのステータス情報を取得する際に使用するためにデータベースから取り出された情報を再編成するシステムであって、
前記データベースにアクセスし、被監視デバイスのステータス情報を取得するために使用される情報を取り出す手段と、
前記データベースから取り出された情報をデータ構造体に設定する手段であって、該データ構造体からの該情報が使用されて、それによって、前記被監視デバイスに関連する１つまたは複数のウェブページからステータス情報が取得される、情報をデータ構造体に設定する手段と、
を備えるデータベースから取り出された情報を再編集するシステム。
【請求項７２】
前記被監視デバイスの前記ステータス情報を取得するために使用される情報を前記データベースの第１および第２テーブルに格納する手段、
をさらに備える請求項７１に記載のデータベースから取り出された情報を再編成するシステム。
【請求項７３】
前記内部データ構造体に設定する手段は、呼出しシーケンスを開始して、それによって、前記データベースの前記第１および第２テーブルから情報を取得する、
請求項７１に記載のデータベースから取り出された情報を再編成するシステム。
【請求項７４】
前記被監視デバイスの前記ステータス情報を取得する際に使用するためのさらなる情報が前記第１および第２テーブルから取り出されなくなるまで前記呼出しシーケンスを反復する手段、
をさらに備える請求項７３に記載のデータベースから取り出された情報を再編成するシス
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネットワークに接続されたデバイスを監視する分野に関する。特に、本発明は、監視システムによってサポートされる被監視デバイスに関連する情報を取得および保守する技術に関する。
［関連出願への相互参照］
【０００２】
本出願は、同一権利者による同時係属中の、「Architecture  of  The  Remote  Monitoring  of  Devices  Through  the  Local  Monitoring  Station  and  Sending  to  the  Central  Station  in  Which  the  Multiple  Vendors  are  Supported」と題する２００２年２月２７日出願の米国特許出願第６０／３５９，６４８号に関連し、これは全体として参照により本明細書に援用される。本出願は、以下の同一権利者による同時係属中の出願に関連する：「Method  and  System  for  Monitoring  Network  Connected  Devices  with  Multiple  Protocols」と題する２００２年８月２２日出願の米国特許出願第１０／２２５，２９０号、「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  and  System  of  Remote  Support  of  Device  Using  Email」と題する２００１年１月９日出願の米国特許出願第０９／７５６，１２０号、「Method  and  Apparatus  for  Modifying  Remote  Devices  monitored  by  a  Monitoring  System」と題する２００２年５月３１日出願の米国特許出願、「Method  and  System  for  Remote  Support  of  Device  Using  Email  Based  Upon  Pop3  With  Decryption  Capability  Through  Virtual  Function」と題する２００１年１０月１５日出願の米国特許出願第０９／９７５，９３５号、「Method  and  System  of  Remote  Support  of  Device  Using  Email  Through  Data  Transfer  Module」と題する２００１年９月１７日出願の米国特許出願第０９／９５３，３５８号、「Method  and  System  to  Use  HTTP  and  Html/xml  for  Monitoring  the  Devices」と題する２００２年６月５日出願の米国特許出願第１０／１６２，４０２号、「Method  for  Scrambling  Information  about  Network  Devices  That  is  Placed  in  Email  Message」と題する２００２年５月３１日出願の米国特許出願第１０／１５７，９０３号、「Method  and  System  to  Use  Http  and  Html/xml  for  Monitoring  the  Devices」と題する２００２年６月５日出願の米国特許出願第１０／１６２，４０２号、「Universal  Controller  in  The  Wireless  Networked  Environment」と題する２００１年８月６日出願の米国特許出願第０９／９２１，７０７号、「System，Method，and  Computer  Program  Product  for  Sending  Remote  Device  Configuration  Information  to  a  Monitor  Using  E-Mail」と題する２００１年９月１７日出願の米国特許出願第０９／９５３，３５９号、本出願と同時係属中の「Method  and  system  for  using  vectors  of  data  structures  for  extracting  information  from  web  pages  of  remotely  monitored  devices」と題する米国特許出願、および本出願と同時係属中の「method  and  system  for  using  internal  data  structures  for  storing  information  related  to  remotely  monitored  devices」と題する米国特許出願。上記のすべての出願の開示は全体として参照により本明細書に援用される。
【背景技術】
【０００３】
一般的に知られているように、コンピュータシステムはハードウェアおよびソフトウェアを含む。ソフトウェアは、コンピュータシステムを構成するハードウェアコンポーネントを動作させ管理するために作成された命令のリストを含む。通常、コンピュータシステムは互いにインタフェースをとりあう種々のハードウェアコンポーネント／デバイスを含む。コンピュータシステムは、スタンドアロン型でもネットワーク接続型でもよい。ネットワーク接続型コンピュータシステムでは、複数の別個のデバイスがネットワークに接続されることにより、これらの別個のデバイス間の通信がネットワークを通じて可能となる。
【０００４】
また、ハードウェアデバイスを動作させるソフトウェアは、ハードウェアデバイス間の通信を可能にするために、ハードウェアデバイスが協調的に機能することができるように構成される必要がある。さらに、このような通信を容易にする目的で、各ハードウェアデバイスが効率的に機能していることを保証するために、ハードウェアデバイスが監視され、各ハードウェアデバイスのステータスが識別されることも望ましい。
【０００５】
ここでは、複数の別個のデバイスまたはハードウェアデバイスを構成または監視しているハードウェアデバイスを監視デバイスと呼び、監視デバイスによって監視されているハードウェアデバイスを「被監視デバイス」と呼ぶこととする。
【０００６】
ネットワーク上に配置されるハードウェアデバイスについて、これらのデバイスが保守、使用等の目的で監視されることが望ましい。しかし、ハードウェアデバイスおよびインタフェースに関連する製造元の相違を考えると、監視デバイスが、ネットワークに接続された種々の他のデバイスと通信することは困難なことがある。このような欠点は、ネットワークに接続されたデバイスのパフォーマンスおよび効率に関する重大な情報をネットワーク管理者が取得するのを妨げる可能性が非常に高い。
【０００７】
Ｓｉｍｐｌｅ  Ｎｅｔｗｏｒｋ  Ｍａｎａｇｅｍｅｎｔ  Ｐｒｏｔｏｃｏｌ（ＳＮＭＰ）は今日、データ通信ネットワーク上のデバイス、電気通信システムおよび他のグローバルに到達可能なデバイスの監視および管理のための事実上の業界標準である。実際上、コンピュータおよび関連デバイスを取り扱うあらゆる組織は、ローカルエリアネットワークおよび広域ネットワークを通じてそのようなそれぞれのデバイスを集中的に監視、診断、および構成することができることを期待している。ＳＮＭＰは、この相互作用を可能にするプロトコルである。
【０００８】
デバイスがＳＮＭＰリクエストに応答するためには、デバイスが適切にＳＮＭＰリクエストを解釈し、そのリクエストによって要求されるアクションを実行し、ＳＮＭＰリプライを生成することを可能にするソフトウェアをデバイスに装備することが望ましい。ＳＮＭＰエージェントソフトウェアは通常、ネットワークエンティティに存在するサブシステムソフトウェアモジュールである。
【０００９】
システムによって実装されるオブジェクトのコレクションは一般に管理情報ベース（ＭＩＢ）と呼ばれる。ＭＩＢは、デバイスの監視に関連する情報を有するデータベースであってもよい。他のＭＩＢの例としては、いくつか列挙すれば、イーサネットインタフェースを中心に扱うイーサネットＭＩＢ、８０２．１Ｄブリッジの管理のためのオブジェクトを定義するブリッジＭＩＢがある。
【発明の開示】
【発明が解決しようとする課題】
【００１０】
デバイスを監視するためにＳＮＭＰを使用することは困難である。というのは、プライベートＭＩＢは、有効なキーなしに解読するのが難しい値を含むからである。会社のネットワークに接続された種々のデバイスを監視するためにＳＮＭＰを使用している会社は、会社の機密情報として保守される固有の識別子／キーを作成する。たいてい、その結果は２進または整数値として表示される。したがって、ＳＮＭＰを使用する場合、監視されているデバイス（「被監視デバイス」）から受信される結果は、ユーザに理解可能な形で被監視デバイスのステータスをユーザに提供することができない。
【００１１】
さらに、ＳＮＭＰを使用する場合、２進または整数値として取得された結果を解読するために、有効なキーまたはプライベートＭＩＢへのアクセスなしに被監視デバイスに関する詳細な情報を取得することは困難である。
【課題を解決するための手段】
【００１２】
本発明は、ネットワークに接続されたデバイスの監視、ならびに監視システムによってサポートされる被監視デバイスに関する情報の取得および保守を可能にすることによって上記の問題の解決を図る。
【００１３】
監視システムによってサポートされるベンダおよびモデルに関する情報がデータベースに格納される。そのデータベースを用いて、監視システムによってサポートされるベンダおよびモデルを判定することにより、基礎となるコードを実際に変更することなく、サポートされるベンダおよびモデルを変更することが容易になる。被監視デバイスのそれぞれが監視システムによってサポートされるかどうかを判定するためにデータベースに複数回アクセスすることをなくすことによって、監視システムの効率が改善される。データベースへの最小限回数のアクセスを実行することによって、監視システムによりサポートされる被監視デバイスのベンダおよびモデルに関するすべての情報の取り出しを容易にし、好ましくはデータベースへの１回のアクセスで所望の情報を取り出すことによって、監視システムの効率は改善される。取り出された情報は、監視システムによってサポートされるデータベースのデータ構造体に格納される。Ｈｙｐｅｒｔｅｘｔ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ（ＨＴＴＰ）を用いて、被監視デバイスからの情報にアクセスしてもよい。
【００１４】
本発明の一態様は、監視システムに通信可能に結合した１つまたは複数の被監視デバイスと、その１つまたは複数の被監視デバイスに関する情報を有するデータベースとを有する通信システムにおいて、監視システムで被監視デバイスに関する情報を取得および保守する方法を提供する。この方法は、ａ）監視システムが被監視デバイスに関する情報を取り出すためにデータベースにアクセスすることを可能にすること、ｂ）データベースから取り出された情報を第１データ構造体に設定すること、ｃ）データベースからの情報を用いて被監視デバイスが監視システムによってサポートされるかどうかを判定すること、およびｄ）被監視デバイスが監視システムによってサポートされると判定された場合、被監視デバイスのステータス情報を取得するために被監視デバイスとの通信を確立すること、を含む。
【００１５】
もう１つの態様では、本発明は、監視システムで１つまたは複数の被監視デバイスに関する情報を取得および保守する方法を提供する。この方法は、ａ）被監視デバイスに関するベンダ情報およびベンダモデル情報をデータベースに格納すること、ｂ）監視システムが格納されているベンダ情報およびベンダモデル情報を取り出すためにデータベースにアクセスすることを可能にすること、ｃ）データベースから取り出されたベンダ情報を第１データ構造体に設定すること、ｄ）第１データ構造体に設定されるべきさらなるベンダ情報が残っていない場合、ベンダモデル情報を第２データ構造体に設定すること、ｅ）データベースからの情報を用いて被監視デバイスが監視システムによってサポートされるかどうかを判定すること、およびｆ）被監視デバイスが監視システムによってサポートされると判定された場合、被監視デバイスとの通信を確立することであって、それによって、被監視デバイスのステータス情報を取得する、通信を確立すること、を含む。
【００１６】
本発明はまた、本明細書に記載される監視システムによってサポートされる被監視デバイスの種々のベンダおよびデバイスモデルを識別する。被監視デバイスの種々のベンダはベンダ固有の方法で被監視デバイスに関する情報を提示するので、本発明は、被監視デバイスのベンダおよびモデルを識別して、被監視デバイスの動作ステータスを判定することを可能にする。
【００１７】
本発明のさらに完全な理解と、本発明に付随する利点の多くは、本発明が以下の詳細な説明を添付図面とともに考察して参照することによってより一層理解されるようになるとともに、容易に得られるであろう。
【発明の効果】
【００１８】
本発明によれば、マルチベンダ環境における種々のデバイスの監視を可能にし、さらに、ユーザが理解しやすい、またはユーザが利用しやすい方法で、詳細な情報を取り出し表示することを容易にする。また、格納される監視される情報は、ＦＴＰまたは電子メールを通じて送出することも可能である。
【発明を実施するための最良の形態】
【００１９】
図１は、種々のデバイスと、デバイスの動作を監視、診断および制御するコンピュータとを有する概略図を示している。具体的には、図１は、コンピュータワークステーション１７、１８、２０および２２に接続されたローカルエリアネットワーク（ＬＡＮ）のような第１ネットワーク１６を含む。ワークステーションは、例えばＩＢＭのパーソナルコンピュータの互換デバイス、Ｕｎｉｘベースのコンピュータ、ＬｉｎｕｘベースのコンピュータまたはＡｐｐｌｅ  Ｍａｃｉｎｔｏｓｈを含む、いかなるタイプのコンピュータであってもよい。ネットワーク１６には、ディジタル画像形成装置２４、ファクシミリ機２８、およびプリンタ３２も接続されている。当業者には認識されるように、ディジタル画像形成装置２４およびファクシミリ機２８の２つ以上のコンポーネントが、統合された「画像形成装置」へと組み合わされてもよい。例えば、画像形成装置２４、ファクシミリ機２８、およびプリンタ３２ならびにワークステーション１７、１８、２０および２２は、マシンまたは被監視デバイスと呼ばれてもよい。いくつかの構成では、１つまたは複数のワークステーションが事務用機器へと転換されてもよい。
【００２０】
このような事務用機器の一例は、Ricoh  Corporationから販売されているｅＣａｂｉｎｅｔ（登録商標）である。また、ファクシミリサーバ（図示せず）がネットワーク１６に接続され、電話、サービス総合ディジタル網（ＩＳＤＮ）、ケーブルまたは無線接続を有していてもよい。ディジタル画像形成装置２４、ファクシミリ機２８、およびプリンタ３２のそれぞれは、ネットワーク１６に接続されていることに加えて、それぞれ従来の電話および／またはＩＳＤＮおよび／またはケーブルおよび／または無線接続２６、３０および３４を含んでもよい。以下で説明するように、被監視デバイス２４、２８および３２はそれぞれ、例えばネットワーク１６経由でインターネットを通じて、または直接の電話、ＩＳＤＮ、無線、もしくはケーブル接続によって、監視デバイスとも呼ばれるリモートの監視・診断・制御ステーションと通信する。
【００２１】
もう１つの例示的なビジネス環境では、被監視デバイスは、多機能イメージングデバイス、スキャナ、プロジェクタ、会議システムおよびシュレッダのようなデバイスを含んでもよい。もう１つの応用形態として、ネットワーク１６はホームネットワークであってもよく、その場合、被監視デバイスは計器（電気、ガス、水道）ならびに、例えば電子レンジ、洗濯機、乾燥機、皿洗い機、家庭用娯楽システム、冷蔵庫、炊飯器、ヒータ、エアコン、湯沸器、セキュリティカメラのような機器である。
【００２２】
図１で、広域ネットワーク（ＷＡＮ）（例えばインターネットおよびその後継）が包括的に１０で示されている。ＷＡＮ１０は、プライベートＷＡＮ、パブリックＷＡＮまたは混成型のいずれでもよい。ＷＡＮ１０は、１２Ａ〜１２Ｉで示される複数の相互接続されたコンピュータおよびルータを含む。ＷＡＮを通じて通信する方法は、Ｉｎｔｅｒｎｅｔ  Ｅｎｇｉｎｅｅｒｉｎｇ  Ｔａｓｋ  Ｆｏｒｃｅ（ＩＥＴＦ）からhttp://www.ietf.org/rfc.htmlで入手可能な一連のＲｅｑｕｅｓｔ  ｆｏｒ  Ｃｏｍｍｅｎｔｓ（ＲＦＣ）文書を通じて既知であり、これには、「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３」と題するＲＦＣ１９３９、「Hypertext  Transfer  Protocol−HTTP/1.1」と題するＲＦＣ２０６８、および「An  Extensible  Message  Format  for  Message  Disposition  Notifications」と題するＲＦＣ２２９８がある。これらの参考文献のそれぞれの内容は参照により本明細書に援用される。
【００２３】
Ｔｒａｎｓｍｉｓｓｉｏｎ  Ｃｏｎｔｒｏｌ  Ｐｒｏｔｏｃｏｌ／Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ（ＴＣＰ／ＩＰ）関連の通信は、例えば、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，AddisonWesley  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  Technologiesから販売されているオブジェクト指向データベースを含む）がある。顧客サービス、営業、製造、および技術部門のそれぞれが、自己の固有のデータベースを有してもよく、１つまたは複数のデータベースを共有してもよい。データベースを格納するために使用されるディスクはそれぞれ、ハードディスクまたは光ディスクのような不揮発性メモリである。別法として、データベースは、固体および／または半導体メモリデバイスを含むいかなるストレージデバイスに格納されてもよい。例えば、ディスク６４には営業データベースが格納され、ディスク５８には製造データベースが格納され、ディスク７０には技術データベースが格納され、ディスク７６には顧客サービスデータベースが格納されてもよい。別法として、ディスク５４および４６には、データベースのうちの１つまたは複数が格納されてもよい。
【００２８】
ワークステーション５６、６２、６８、７４および４２がＷＡＮ１０に接続されることに加えて、これらのワークステーションは、監視、診断および／または制御されるマシン／デバイスへの安全な接続を提供するために、電話回線、ＩＳＤＮ、ケーブル、または無線ネットワークへの接続を含んでもよい。さらに、通信媒体の１つが正しく動作していない場合に、他の１つが通信のためにバックアップとして自動的に使用されてもよい。
【００２９】
本発明の特徴は、マシンを診断および制御するためにマシンとコンピュータ／監視システムの間の通信（例えばインターネット電子メール、本明細書においてＥメールともいう）または送信の「蓄積転送」モードの使用である。別法として、送信されるメッセージは、ＦＴＰやＨｙｐｅｒ  Ｔｅｘｔ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ（ＨＴＴＰ）のような直接のエンドツーエンド接続（例えば、最終宛先へのソケット接続を用いて）を行う通信モードを用いて実施されてもよい。
【００３０】
図２は、図１に示したディジタル画像形成装置２４の機械的配置を示している。図２において、１０１はスキャナのためのファンであり、１０２はレーザプリンタで使用されるポリゴンミラーであり、１０３はレーザ（図示せず）からの光をコリメートするために使用されるＦΘレンズを表す。１０４はスキャナからの光を検出するセンサを表す。１０５はスキャナからセンサ１０４への光の焦点を合わせるレンズを表し、１０６は光導電性ドラム１３２上の画像を消去するために使用されるクエンチングランプを表す。帯電コロナユニット１０７および現像ローラ１０８がある。１０９はスキャンされるドキュメントを照明するために使用されるランプを表し、１１０、１１１、および１１２は、センサ１０４へ光を反射するミラーを表す。ドラムミラー１１３がポリゴンミラー１０２から発する光を光導電性ドラム１３２へ反射するために提供される。ファン１１４がディジタル画像形成装置の帯電領域を冷却するために使用され、第１給紙ローラ１１５が第１用紙カセット１１７から給紙するために使用され、１１６は手差しテーブルを表す。同様に、第２給紙ローラ１１８が第２カセット１１９とともに使用される。１２０はリレーローラを表し、１２１は見当合わせローラを表し、１２２は画像濃度センサを表し、１２３は転写／分離コロナユニットを表す。１２４はクリーニングユニットを表し、１２５は吸引ファンを表し、１２６は搬送ベルトを表し、１２７は圧力ローラを表し、１２８は出口ローラを表す。熱ローラ１２９がトナーを用紙上に定着させるために使用され、１３０は排気ファンを表し、主モータ１３１がディジタル画像形成装置２４を駆動するために使用される。
【００３１】
図３は、図２のディジタル画像形成装置２４の電子コンポーネントを示すブロック図である。ＣＰＵ１６０は、装置のコントローラとして作用するマイクロプロセッサである。ランダムアクセスメモリ（ＲＡＭ）１６２は、ディジタル画像形成装置２４の動作パラメータを含む動的に変化する情報を格納する。不揮発性メモリ（例えば、読み出し専用メモリ（ＲＯＭ）１６４またはフラッシュメモリ）は、画像形成装置２４を記述する静的状態データ（例えば、複写機のモデル番号、シリアル番号、およびデフォルトパラメータ）とともに、ディジタル画像形成装置を動作させるために使用されるプログラムコードを格納する。
【００３２】
マルチポートネットワークインタフェース１６６は、ディジタル画像形成装置２４が少なくとも１つの通信ネットワークを通じて外部デバイスと通信することを可能にするために提供される。１６８は電話、ＩＳＤＮ、またはケーブル回線を表し、１７０は、１６８で識別されるネットワークとは異なるもう１つのタイプのネットワークを表す。マルチポートネットワークインタフェースについてさらに詳細には図５に関して記載される。インタフェースコントローラ１７２は、操作パネル１７４をシステムバス１８６に接続するために使用される。操作パネル１７４は、ディジタル画像形成装置２４に見られる標準的な入出力デバイスを含み、これには複写ボタンや、例えば複写枚数、拡大縮小、明暗等のような画像形成装置の動作を制御するためのキーが含まれる。さらに、ディジタル画像形成装置２４のパラメータおよびメッセージをユーザに対して表示するために、液晶ディスプレイが操作パネル１７４内に含まれてもよい。
【００３３】
ローカル接続インタフェース１７１は、ＲＳ２３２、パラレルプリンタポート、ＵＳＢ、およびＩＥＥＥ１３９４のようなローカルポートを通じての接続である。ＦｉｒｅＷｉｒｅ（ＩＥＥＥ１３９４）は、Wickelgren，I．著「The  Facts  About  FireWire」IEEE  Spectrum，April  1997，Vol．34，Number  4，pp.19-25、に記載されており、その内容全体が参照により本明細書に援用される。好ましくは、誤り検出および再送を含む「信頼性のある」通信プロトコルが使用される。
【００３４】
ストレージインタフェース１７６は、ストレージデバイスをシステムバス１８６に接続する。例えば、ストレージデバイスとしては、フラッシュメモリ１７８（これは、従来の電気的消去可能プログラム可能読み出し専用メモリ（ＥＥＰＲＯＭ）によって置換可能である）、およびディスク１８２がある。ディスク１８２は、ハードディスク、光ディスク、および／またはフロッピーディスクドライブのいずれでもよい。追加的なメモリデバイスが、接続１８０を通じてディジタル画像形成装置２４に接続されてもよい。フラッシュメモリ１７８は、装置２４の寿命にわたってあまり頻繁に変化しないディジタル画像形成装置２４のパラメータを記述する準静的状態データを格納するために使用される。このようなパラメータとしては、例えば、ディジタル画像形成装置のオプションおよびコンフィグレーションがある。オプションインタフェース１８４は、外部インタフェースのような追加的ハードウェアがディジタル画像形成装置２４に接続されることを可能にする。クロック／タイマ１８７は、日時を追跡するとともに経過時間を測定するために利用される。
【００３５】
図３は、ディジタル画像形成装置２４を構成する種々のセクションも示している。２０２はソータを表し、ディジタル画像形成装置２４の出力をソートするために使用されるセンサおよびアクチュエータを含む。デュプレクサ２００は、両面印刷動作の実行を可能にする。デュプレクサ２００は、従来のセンサおよびアクチュエータを含む。大容量トレーユニット１９８が、大量の用紙を保持する用紙トレーを可能にするために提供される。デュプレクサ２００と同様、トレーユニット１９８もまた従来のセンサおよびアクチュエータを含む。
【００３６】
給紙コントローラ１９６が、ディジタル画像形成デバイスへの、およびこれを通る給紙動作を制御するために使用される。スキャナ１９４は、画像をスキャンしてディジタル画像形成デバイスに取り込むために使用され、ライト、ミラー等のような従来のスキャニング要素を含む。さらに、スキャナがホームポジションにあるかどうかを判定するためのホームポジションセンサのようなスキャナセンサが使用され、ランプサーミスタがスキャニングランプの正しい動作を保証するために使用される。プリンタ／イメージャ１９２が、ディジタル画像形成デバイスの出力を印刷し、従来のレーザ印刷機構、トナーセンサ、および画像濃度センサを含む。定着器１９０は、高温ローラを用いてページ上にトナーを定着させるために使用され、出口センサ、定着器１９０が過熱していないことを保証するためのサーミスタ、およびオイルセンサを含む。さらに、自動ドキュメントフィーダ、異なるタイプのソータ／コレータ等のディジタル画像形成デバイスに追加可能な要素のような、ディジタル画像形成デバイスのオプション要素に接続するために使用されるオプションユニットインタフェース１８８がある。
【００３７】
図４は、マルチポートネットワークインタフェース１６６の詳細を示す。ディジタル画像形成デバイスは、トークンリングインタフェース２２０、ケーブルを通じての高速接続を有するケーブルモデムユニット２２２、電話回線１６８Ａに接続する従来の電話インタフェース２２４、ＩＳＤＮ回線１６８Ｂに接続するＩＳＤＮインタフェース２２６、無線インタフェース２２８、またはＬＡＮ１７０に接続するイーサネットインタフェース２３０を通じて、外部デバイスと通信し得る。他のインタフェースとしては、限定はされないが、ディジタル加入者回線（ＤＳＬ）（オリジナルＤＳＬ、同軸ＤＳＬ、および非対称ＤＳＬ）があり得る。単体でローカルエリアネットワークおよび電話回線の両方に接続するデバイスがIntelから市販されており、Ｉｎｔｅｌ  Ｐｒｏ  １０／１００＋Ｍｏｄｅｍとして既知である。
【００３８】
ＣＰＵまたは他のマイクロプロセッサもしくは回路が、ディジタル画像形成デバイスのセンサそれぞれの状態を監視する監視プロセスを実行し、シーケンス制御プロセスが、ディジタル画像形成デバイスを制御し動作させるために使用されるコードの命令を実行するために使用される。さらに、（１）ディジタル画像形成デバイスの全体動作を制御するために実行される中央システム制御プロセス、および（２）ディジタル画像形成デバイスに接続される外部デバイスとの信頼性のある通信を保証するために使用される通信プロセスがある。システム制御プロセスは、静的状態メモリ（例えば図３のＲＯＭ１６４）、準静的メモリ（例えば、フラッシュメモリ１７８またはディスク１８２）、または動的状態メモリ（例えば、揮発性または不揮発性メモリ（例えば、ＲＡＭ１６２またはフラッシュメモリ１７８またはディスク１８２））内のデータストレージを監視および制御する。さらに、静的状態メモリは、ＲＯＭ１６４以外の、フラッシュメモリ１７８またはディスク１８２のいずれかを含む不揮発性メモリのようなデバイスであってもよい。
【００３９】
上記の詳細は、ディジタル画像形成デバイスに関して説明されているが、本発明は、アナログ複写機、ファクシミリ機、スキャナ、プリンタ、ファクシミリサーバ、プロジェクタ、会議機器、シュレッダのような他の事務用マシンもしくはデバイスや、他の事務用マシン、事務用機器、または他の機器（例えば、電子レンジ、ＶＣＲ、ディジタルカメラ、携帯電話機、パームトップコンピュータ）にも同様に適用可能である。さらに、本発明は、蓄積転送型、または直接接続方式の通信を用いて動作する他のタイプのデバイスを含む。このようなデバイスには、動作または遠隔診断中に監視されることを必要とする計測システム（ガス、水道、または電気計測システムを含む）、自動販売機、またはいかなる機械的デバイス（例えば自動車）も含まれる。特定用途のマシンおよびコンピュータを監視することに加えて、本発明は、監視および／または制御されるデバイスとなる汎用コンピュータを監視、制御、および診断するためにも使用可能である。
【００４０】
図５は、種々のデバイスおよびサブシステムがＷＡＮ１０に接続される本発明の代替システム図を示している。しかし、これらのデバイスまたはサブシステムのそれぞれを本発明の一部として有する必要はない。図５に示されている各コンポーネントまたはサブシステムは個別に本発明の一部である。さらに、図１に示した要素が図５に示されるＷＡＮ１０に接続されてもよい。図５において、イントラネット２６０−１に接続されたファイアウォール５０−１が示されている。イントラネット２６０−１に接続されたサービスマシン２５４はその内部に、またはそれに接続されて、データベースフォーマットで格納可能なデータ２５６を有する。データ２５６には、履歴、性能、故障や、被監視デバイスの動作もしくは障害もしくは設定の統計情報、または被監視デバイスとともにどのコンポーネントもしくはオプション機器が含まれているかというようなコンフィグレーション情報等の任意の他の情報も含まれる。サービスマシン２５４は、被監視デバイスに対してデータを送信するよう要求し、または遠隔制御および／または診断テストが被監視デバイス上で実行されることを要求するデバイスまたはコンピュータとして実施されてもよい。サービスマシン２５４は、いかなるタイプのデバイスとして実施されてもよいが、好ましくは、汎用コンピュータのようなコンピュータ化されたデバイスを用いて実施される。
【００４１】
図５のもう１つのサブシステムは、ファイアウォール５０−２、イントラネット２６０−２、およびそれに接続されたプリンタ２６２を含む。このサブシステムでは、プリンタ２６２による（および同様に複写機２８６による）電子メッセージの送受信の機能が、（１）回路、（２）マイクロプロセッサ、または（３）プリンタ２６２内に含まれ、またはそれに装着された（すなわち、別個の汎用コンピュータを使用しない）任意の他のタイプのハードウェア、によって実行される。
【００４２】
代替的タイプのサブシステムとしては、インターネットサービスプロバイダ２６４の使用が含まれる。これはいかなるタイプのインターネットサービスプロバイダ（ＩＳＰ）であってもよく、America  Online、Earthlink、およびNiftyserveのような既知の営利会社を含む。このサブシステムでは、コンピュータ２６６がディジタルまたはアナログモデム（例えば、電話回線モデム、ケーブルモデム、サービス総合ディジタル網（ＩＳＤＮ）回線もしくは非対称ディジタル加入者回線（ＡＤＳＬ）を通じて使用されるモデムのような任意のタイプの配線を使用するモデム、フレームリレー通信を使用するモデム、無線周波モデムのような無線モデム、光ファイバモデム、または赤外光波を使用するデバイス）を通じてＩＳＰ２６４に接続される。さらに、事務用デバイス２６８がコンピュータ２６６に接続される。事務用デバイス２６８（または図５に示されている任意の他のデバイス）の代替例として、ディジタル複写機、任意のタイプの機器、セキュリティシステム、もしくは電気、水道、もしくはガス需要計器のような需要計器、または本明細書に論じられる任意の他のデバイスのような、異なるタイプのマシンが監視または制御されてもよい。
【００４３】
また図５には、ネットワーク２７４に接続されたファイアウォール５０−３も示されている。ネットワーク２７４は、いかなるタイプのコンピュータネットワーク（例えば、イーサネットまたはトークンリングネットワーク）として実施されてもよい。ネットワークを制御するために使用可能なネットワーキングソフトウェアとしては、NovellやMicrosoftから市販されているソフトウェアを含むいかなる所望のネットワーキングソフトウェアも含まれる。ネットワーク２７４は、所望であれば、イントラネットとして実施されてもよい。ネットワーク２７４に接続されるコンピュータ２７２は、事務用デバイス２７８から情報を取得し、ネットワークに接続されている種々のマシンで発生した問題を示すレポートや、ネットワーク２７４に接続されているデバイスの月別使用状況レポートのようなレポートを生成するために使用されてもよい。この実施形態では、コンピュータ２７６は、事務用デバイス２７８とネットワーク２７４の間に接続される。このコンピュータは、ネットワークからの通信を受信し、適当なコマンドもしくはデータ、または任意の他の情報を、事務用デバイス２７８に転送する。
【００４４】
事務用デバイス２７８とコンピュータ２７６の間の通信は、有線または無線のいずれの方法を用いて行われてもよい。これには、以下のものに限定されないが、無線周波接続、電気接続および光接続（例えば、赤外線接続、または光ファイバ接続）がある。同様に、図５に示されている種々のネットワークおよびイントラネットのそれぞれは、無線周波ネットワークのような無線ネットワークの確立によるものを含むいかなる所望の方法を用いて確立されてもよい。本明細書に記載される無線通信は、拡散符号を使用する技法や、Ｂｌｕｅｔｏｏｔｈ  Ｓｐｅｃｉｆｉｃａｔｉｏｎ  ＬＯＡ（ワールドワイドウェブサイトwww.bluetooth.comで入手可能）（これは参照により本明細書に援用される）に開示されている周波数ホッピング無線技法のような周波数ホッピング技法を含むスペクトラム拡散技法を用いて確立されてもよい。
【００４５】
図５に示されているもう１つのサブシステムは、ファイアウォール５０−４、イントラネット２６０−４、それに接続されたコンピュータ２８２、事務用機器２８５および複写機２８６を含む。コンピュータ２８２は、レポートを生成し、診断または制御手続きを要求するために使用されてもよい。これらの診断および制御手続きは、事務用機器２８５および複写機２８６、または図５に示され、もしくは図５とともに使用されるいかなる他のデバイスに関して実行されてもよい。図５は複数のファイアウォールを示しているが、ファイアウォールは好ましいけれども随意の機器であり、したがって本発明は、所望であればファイアウォールを使用せずに運用されてもよい。ネットワーク接続された機器の監視および制御のため、いかなるコンピュータ（２６６、２７２または２８２）も２５４の代わりに使用されることが可能である。
【００４６】
図６Ａは、コンポーネント３０２、３０４、３０６、３０８、３１０、３１２、３１４、３１６、および３１８を含む典型的な電子メール交換システムに接続されたデバイス／機器３００を示している。これは従来の方法で実施されてよく、前掲のStevensのFigure  28.1を改変したものである。コンピュータインタフェース３０２が、本明細書に記載される任意のアプリケーションユニットまたはデバイス／機器３００とインタフェースをとる。図６Ａは、デバイス／機器３００が送信側である場合を示しているが、送信および受信の機能は図６Ａで逆にしてもよい。さらに、所望であれば、ユーザはデバイス／機器３００とインタフェースをとることを全く必要とされなくてもよい。次に、コンピュータインタフェース３０２はメールエージェント３０４と相互作用する。Ｕｎｉｘ用の普及しているメールエージェントとしては、ＭＨ、Ｂｅｒｋｅｌｅｙ  Ｍａｉｌ、Ｅｌｍ、およびＭｕｓｈがある。Ｗｉｎｄｏｗｓファミリのオペレーティングシステム用のメールエージェントとしては、Ｍｉｃｒｏｓｏｆｔ  ＯｕｔｌｏｏｋおよびＭｉｃｒｏｓｏｆｔ  Ｏｕｔｌｏｏｋ  Ｅｘｐｒｅｓｓがある。コンピュータインタフェース３０２の要求時に、メールエージェント３０４は、送信されるべき電子メールメッセージを作成し、所望であれば、送信されるべきこれらのメッセージをキュー３０６に入れる。送信されるべきメールはメッセージ転送エージェント（ＭＴＡ）３０８に転送される。Ｕｎｉｘシステム用の普通のＭＴＡはＳｅｎｄｍａｉｌである。通常、メッセージ転送エージェント３０８と３１２は、ＴＣＰ／ＩＰ接続３１０を用いて交信する。特に、メッセージ転送エージェント３０８と３１２の間の通信は、いかなるサイズのネットワーク（例えば、ＷＡＮまたはＬＡＮ）を通じて行われてもよい。さらに、メッセージ転送エージェント３０８および３１２は、いかなる通信プロトコルを使用してもよい。本発明の一実施形態では、図６Ａの要素３０２および３０４は、アプリケーションユニットの使用を監視するためのライブラリに存在する。
【００４７】
メッセージ転送エージェント３１２から、電子メールメッセージはユーザメールボックス３１４に格納され、これがメールエージェント３１６に転送され、最終的に、受信端末として機能する端末３１８のユーザに送信される。
【００４８】
この「蓄積転送」プロセスは、送信側メールエージェント３０４を、メール受信側との直接接続が確立されるまで待機しなければならないことから解放する。ネットワーク遅延のため、通信には相当の時間を要することがあり、その間アプリケーションは応答しなくなる。このような無応答は一般に、アプリケーションユニットのユーザにとって受け入れ難い。電子メールを蓄積転送プロセスとして使用することによって、障害後の再送試行が一定期間（例えば３日間）自動的に行われる。一代替実施形態では、アプリケーションは、１つまたは複数の別個のスレッドに通信要求を渡すことによって、待機を避けることができる。その場合、それらのスレッドが受信側端末３１８との通信を制御し、一方でアプリケーションはユーザインタフェースへの応答を再開する。さらにもう１つの実施形態では、ユーザが続行前に通信を完了したい場合、受信側端末との直接通信が使用される。このような直接通信は、送信側と受信側の端末間のファイアウォールによって遮断されないいかなるプロトコルを利用することも可能である。このようなプロトコルの例としては、Ｔｅｌｎｅｔ、Ｆｉｌｅ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ（ＦＴＰ）およびＨｙｐｅｒ  Ｔｅｘｔ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ（ＨＴＴＰ）がある。
【００４９】
インターネットのようなパブリックＷＡＮは一般に、安全であるとはみなされていない。したがって、メッセージを秘密に保ちたい場合、パブリックＷＡＮ（および多企業プライベートＷＡＮ）を通じて送信されるメッセージを暗号化することができる。本発明とともに使用可能な暗号化メカニズムが既知であり市販されている。例えば、Ｕｎｉｘオペレーティングシステムで使用するためのＣ＋＋ライブラリ関数crypt()がSun  Microsystemsから入手可能である。暗号化および復号化ソフトウェアパッケージが既知であり市販されており、これも本発明とともに使用してもよい。１つのこのようなパッケージは、McAfeeから市販されているＰＧＰ  Ｖｉｒｔｕａｌ  Ｐｒｉｖａｔｅ  Ｎｅｔｗｏｒｋ（ＶＰＮ）である。
【００５０】
図６Ａの一般的構成の代替例として、コンピュータインタフェース３０２、メールエージェント３０４、メールキュー３０６およびメッセージ転送エージェント３０８として機能する単一のコンピュータを使用してもよい。図６Ｂに示すように、デバイス／機器３００は、メッセージ転送エージェント３０８を含むコンピュータ３０１に接続される。
【００５１】
別の代替構成が図６Ｃに示されている。この構成では、メッセージ転送エージェント３０８はデバイス／機器３００の一部として形成される。さらに、メッセージ転送エージェント３０８はＴＣＰ／ＩＰ接続３１０によってメッセージ転送エージェント３１２に接続される。図６Ｃの実施形態では、デバイス／機器３００が電子メール機能を有し、ＴＣＰ／ＩＰ接続３１０に直接接続される。図６Ｃの実施形態の１つの用途として、電子メール機能付きのファクシミリ機（例えば、ＲＦＣ２３０５（インターネットメールを用いたファクシミリの簡易モード）で規定されるような）をデバイス／機器３００として使用することがある。
【００５２】
図６Ｄは、デバイス／機器３００がそれ自体は電子メールを直接受信する機能を有しないが、メッセージ転送エージェント３０８およびメールボックス３１４を含むメールサーバ／ＰＯＰ３サーバへの接続３１０を有し、デバイス／機器３００がＰＯＰ３プロトコルを用いてメールサーバから受信メールを取り出すようなシステムを示している。
【００５３】
図７は、メールを転送する一代替実施態様を示しており、前に参照したStevensのFigure28．3を改変したものである。図７は、それぞれの側にリレーシステムを有する電子メールシステムを示している。図７の構成は、組織における１つのシステムがメールハブとして作用することを可能にする。図７には、２つのメールエージェント３０４と３１６の間に接続された４つのＭＴＡがある。これらのＭＴＡとしては、ローカルＭＴＡ３２２Ａ、リレーＭＴＡ３２８Ａ、リレーＭＴＡ３２８Ｂ、およびローカルＭＴＡ３２２Ｄがある。本発明とともに使用可能な、メールメッセージに使用される最も普通のプロトコルはＳＭＴＰ（Simple  Mail  Transfer  Protocol）であるが、いかなる所望のメールプロトコルを利用してもよい。図７において、３２０は、コンピュータインタフェース３０２、メールエージェント３０４、およびローカルＭＴＡ３２２Ａを含む送信側ホストを表す。デバイス／機器３００は送信側ホスト３２０に接続され、または別法としてその内部に含まれる。もう１つの場合として、デバイス／機器３００およびホスト３２０が１つのマシン内にあり、ホスト機能がデバイス／機器３００に組み込まれてもよい。他のローカルＭＴＡ３２２Ｂ、３２２Ｃ、３２２Ｅおよび３２２Ｆも含まれてよい。送受信されるメールは、リレーＭＴＡ３２８Ａのメールのキュー３０６Ｂにキューイングされてもよい。メッセージは、ＴＣＰ／ＩＰ接続３１０（例えば、インターネット接続または任意の他のタイプのネットワークをはさむ接続）を越えて転送される。
【００５４】
送信されたメッセージは、リレーＭＴＡ３２８Ｂによって受信され、所望であれば、メールのキュー３０６Ｃに格納される。次にメールは受信側ホスト３４２のローカルＭＴＡ３２２Ｄに転送される。メールは、１つまたは複数のユーザメールボックス３１４に入れられ、続いてメールエージェント３１６に転送され、最後に端末３１８のユーザに転送されてもよい。所望であれば、メールは、ユーザとのやりとりなしに端末に直接転送されてもよい。
【００５５】
図５のコンピュータ２６６および２７６を含めて、本発明で使用される種々のコンピュータは、図８に示すように実施されてもよい。さらに、本発明で使用されるいかなる他のコンピュータも、所望であれば、図５のサービスマシン２５４、コンピュータ２７２、およびコンピュータ２８２を含めて、図８に示すコンピュータと同様に実施されてもよい。しかし、図８に示すあらゆる要素がそれらのコンピュータそれぞれに必要なわけではない。
【００５６】
図８において、コンピュータ３６０はＣＰＵ３６２を含む。ＣＰＵは、Intel、AMD、Motorola、HitachiおよびNECのような会社からの市販のマイクロプロセッサを含むいかなるタイプのプロセッサとして実施されてもよい。ＲＡＭ３６４のようなワーキングメモリ、および無線デバイス３６８と通信する無線インタフェース３６６がある。インタフェース３６６とデバイス３６８の間の通信は、いかなる無線媒体（例えば、電波または光波）を使用してもよい。電波は、符号分割多重アクセス（ＣＤＭＡ）通信のようなスペクトラム拡散技法を用いて、またはＢｌｕｅｔｏｏｔｈ仕様に開示されているもののような周波数ホッピング技法を用いて実施されてもよい。
【００５７】
コンピュータ３６０は、ＲＯＭ３７０およびフラッシュメモリ３７１を含むが、いかなる他のタイプの不揮発性メモリ（例えば、消去可能プログラム可能ＲＯＭ、またはＥＥＰＲＯＭ）がフラッシュメモリ３７１に加えて、またはその代わりに使用されてもよい。入力コントローラ３７２には、キーボード３７４およびマウス３７６が接続される。シリアルデバイス３８０に接続されるシリアルインタフェース３７８がある。さらに、パラレルインタフェース３８２がパラレルデバイス３８４に接続され、ユニバーサルシリアルバス（ＵＳＢ）インタフェース３８６がユニバーサルシリアルバスデバイス３８８に接続され、ＩＥＥＥ１３９４インタフェース３９８に接続される、普通ファイヤワイヤデバイスと呼ばれるＩＥＥＥ１３９４デバイス４００もある。システムバス３９０が、コンピュータ３６０の種々の要素を接続する。ディスクコントローラ３９６が、フロッピーディスクドライブ３９４およびハードディスクドライブ３９２に接続される。通信コントローラ４０６は、コンピュータ３６０が電話回線４０２またはネットワーク４０４を通じて他のコンピュータと（例えば電子メールメッセージを送信することによって）通信することを可能にする。Ｉ／Ｏ（入出力）コントローラ４０８が、例えばＳＣＳＩ（Small  Computer  System  Interface）バスを用いてプリンタ４１０およびハードディスク４１２に接続される。また、ＣＲＴ（ブラウン管）４１４に接続されるディスプレイコントローラ４１６もあるが、液晶ディスプレイ、発光ダイオードディスプレイ、プラズマディスプレイ等を含む任意の他のタイプのディスプレイが使用されてもよい。
【００５８】
次に図９Ａを参照すると、本発明の一例示的な実施形態によるシステム９００全体の概略図が示されている。システム９００は、複数のデバイス、例えば、レーザプリンタ９０８、スキャナ９１０、ネットワークデバイス９１２、および多機能プリンタ９１４を含み、すべてがネットワーク１００に接続されているように示されている。これらの複数のデバイスは本明細書では包括的に「被監視デバイス」と呼ばれる。システム９００はまた、ワークステーション／監視システム９０２（以下コントローラ９０２という）も含む。その詳細は図１０に示される。これは、被監視デバイス９０８、９１０、９１２および９１４を監視および制御するためにネットワーク１００に接続される。被監視デバイス９０８、９１０、９１２、および９１４のそれぞれには固有のアドレスロケータが与えられる。例えば、デバイスに割り当てられるＩＰアドレスが、そのデバイスの固有アドレスロケータの役割を果たす。したがって、コントローラ９０２のユーザは、それぞれの被監視デバイスに割り当てられた固有のＩＰアドレスにアクセスすることによって、被監視デバイス９０８〜９１４のうちのそれぞれのデバイスにアクセスすることができる。理解されるように、本発明は、ネットワークに接続されるデバイスを一意的に識別するためにＩＰアドレスを使用することには限定されない。
【００５９】
コントローラ９０２は、被監視デバイス９０８〜９１４のうちのデバイスにアクセスすると、そのデバイスに割り当てられているウェブページを表示する。このウェブページは、トラブルシューティング情報を含むそのデバイスの動作ステータスに関する詳細情報を含む。例えば、コントローラ９０２は、レーザプリンタ９０８に割り当てられているウェブページにアクセスしてそれを表示する。ウェブページは、トナーレベル、紙詰まりの指示、プリンタトレー内の印刷用紙の量等の詳細を含む、レーザプリンタ９０８の動作ステータス／詳細を含む。同様に、レーザプリンタの動作履歴もウェブページに表示されることがある。好ましくは、レーザプリンタ９０８の固有の動作詳細はそのウェブページの固有のフィールドに表示されるであろう。同様に、被監視デバイス９０８〜９１４のそれぞれの動作ステータス／詳細が、それぞれのウェブページに表示される。
【００６０】
理解されるように、コントローラ９０２はネットワーク１００に物理的に接続されても無線結合してもよい。例えば、個人情報端末（ＰＤＡ）９２０またはラップトップコンピュータ９２２が、ネットワーク１００に無線結合しているように図示されているが、これらがコントローラ９０２として使用されてもよい。アクセスポイント９２４が、ネットワーク１００とＰＤＡ９２０またはラップトップコンピュータ９２２との間の無線通信を可能にするインタフェースとして作用する。以下、本発明は、コントローラ９０２が、ネットワークに接続されている被監視デバイスのステータスを制御および監視すると仮定して説明される。
【００６１】
ネットワーク１００は、コントローラ９０２と被監視デバイス９０８〜９１４の間の通信を容易にして、このような被監視デバイスの監視および制御を可能にする。ネットワークに接続されるデバイスの個数は本発明を限定するものではない。理解されるように、ネットワーク１００は、ローカルエリアネットワーク（ＬＡＮ）または広域ネットワーク（ＷＡＮ）のいずれでもよい。同様に、被監視デバイス９０８、９１０、９１２、および９１４は単に例示として示されている。
【００６２】
コントローラ９０２は、ストレージデバイス９０４およびデータベース９０６に通信可能に結合する。ストレージデバイス９０４としては、ハードディスク、光ディスク、および／または外部ディスクドライブがある。データベース９０６は、ストレージデバイス９０４に通信可能にリンクされ、ストレージデバイス９０４に格納されているデータの容易な検索および取り出しのための関係データベース管理システム（ＲＤＢＭＳ）を含む。ストレージデバイス９０４は、好ましくは、被監視デバイス９０８〜９１４のそれぞれに関する詳細情報を格納する。例えば、レーザプリンタ９０８の製造元によって供給されるその製造元、モデル、ならびに種々の機能およびトラブルシューティングの詳細のような詳細情報がストレージデバイス９０４に格納される。また、所定の基準値と比較しての、レーザプリンタの動作ステータスに関する偏差値もまたストレージデバイス９０４に格納されてもよい。データベース９０６およびストレージデバイス９０４はコントローラ９０２に通信可能に結合しているように記載されているが、理解されるように、コントローラ９０２は、ストレージデバイスおよびデータベースがその内部に設置されて構成されてもよい。このような場合、ストレージデバイス９０４およびデータベース９０６はコントローラ９０２の内部にあるものとして描かれるであろう。
【００６３】
コントローラ９０２には、複数のデバイス９０８〜９１４の監視および制御を容易にするためにソフトウェアがインストールされ、その詳細は図１０に示される。コントローラ９０２が複数のデバイス９０８〜９１４を監視するためにＨｙｐｅｒ  Ｔｅｘｔ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ（ＨＴＴＰ）が使用され、複数のデバイス９０８〜９１４から受信されるデータは、ＨＴＭＬもしくはＸＭＬフォーマット、または任意の他のウェブブラウザ言語の形態で提示される。
【００６４】
図９Ａはイメージングデバイスのみを示しているが、監視デバイスと複数の被監視デバイスの間で情報を通信するためのネットワークは、機器および計器がネットワークに接続されたホームネットワークを含んでもよい。理解されるように、コントローラ／ワークステーション９０２によって収集されるデータは、さらに処理をするために、Ｅメール、ＦＴＰ、またはいかなる他の通信プロトコル手段を通じてリモートデバイスへ送信されてもよい。図９Ｂは、本発明の一例示的な実施形態による被監視デバイスの例示的なウェブページインタフェースを示している。
【００６５】
図１０は、本発明の一例示的な実施形態によるデータの監視およびそのインタフェース関数で使用されるシステム１０００を示している。システム１０００は、ＮＴまたはＷｉｎｄｏｗｓ  ２０００におけるサービスやＵｎｉｘにおけるデーモンのようなコンピュータ常駐プログラムであるモジュールMonitorService１００４を含む。また、システム１０００には、Timerモジュール１００２およびMonitorモジュール１００６も含まれる。モジュール１００２および１００６は、MonitorService１００４によって呼び出されるライブラリ関数である。例えば、MonitorService１００４は、InitTimer１００３関数を呼び出すことによってTimerモジュール１００２を初期化し、obtainDelayAndAction(int  &，int  &)関数を呼び出すことによって遅延およびアクションパラメータを取得する。init()関数もまた、図１３に示すようなMonitorモジュール１００６内の種々のモジュールを初期化するためにMonitorService１００４によって呼び出される。init()関数は、被監視デバイスに割り当てられたＩＰアドレスを取得するために最初に呼び出される。
【００６６】
被監視デバイスのＩＰアドレスが取得されると、そのＩＰアドレスは、監視システムが被監視デバイスと交信して、例えば製造元やモデル情報のような情報を取得するために使用される。システム１０００によって実行される関数を以下で説明する。
【００６７】
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モジュール１００６は、図１０に示したようなインタフェース関数によって定義されるタスクを完了するために、DeviceODBC１１０４、DeviceFactory１１０６、VendorModel１１０８、HTTP_HTML１１１２、SupportInfoODBC１１１４、Device１１１０のような他のサブモジュールを管理するMonitorManager１１０２を含む。具体的には、DeviceODBCサブモジュール１１０４およびSupportInfoODBCサブモジュール１１１４は、被監視デバイスからデバイス固有情報を取得するためにアクセスされる。SupportInfoODBCサブモジュール１１１４は、好ましくは、プロトコルHTTP_HTMLサブモジュール１１１２にアタッチされる。というのは、SupportInfoODBCサブモジュール１１１４によって取得される情報は、HTTP_HTMLサブモジュール１１１２にローカライズされることが好ましいからである。サブモジュール間で実行される呼出し関数は以下のように定義される。
【００７３】
主要インタフェース
このセクションは、パッケージ間の主要インタフェースのみを論ずる。以下は、パッケージ間のインタフェースの完全なリストではない。例えば、一部のパッケージはinit関数を有する必要があるかもしれない。
【００７４】
void  updateConfig(std::map<infoType，std::string>  &)
この関数が呼び出される前に、get関数がVendorModelパッケージからヌル文字列を返す場合には、呼出し関数は製造元およびモデルのエントリを置き換えるべきではない。この関数は、DeviceODBC内の現在のレコードのデバイス情報データベースを更新する。この関数は、下記のgetConfigが最初に呼び出される場合に非常に効率的である。まず、この関数は、ＩＰアドレスがDeviceODBCにおいて同一であるかどうかをチェックする。ＩＰアドレスフィールドが同一でない場合、正しいＩＰアドレスのレコードがデータベースから取得される。そして、他のフィールドがコピーされ、レコードが更新される。
【００７５】
bool  getConfig(std::map<infoType，std::string>  &)
この関数は、所与のフォーマットでデバイス情報に対するＯＤＢＣからマップを取得する。関数は、返されるデータがあればtrueを返し、もはやデータがなければfalseを返す。
【００７６】
bool  saveStatus(std::map<infoType，std::string>  &)
この関数は、ステータス情報をＯＤＢＣに保存する。関数は、保存が成功すればtrueを返し、さもなければfalseを返す。
【００７７】
void  setIPAddress(std::string  &)
この関数は、交信されるべきデバイスのＩＰアドレスをセットする。この関数はVendorModelおよびHTTP_HTMLパッケージに共通である。
【００７８】
bool  getVendor(std::string  &)
この関数は、ＩＰアドレスにおける製造元を獲得する。製造元が取得された場合、関数はtrueを返す。プロセス中にエラーが検出された場合、関数はヌル文字列とともにfalseを返す。関数はVendorModelおよびHTTP_HTMLパッケージに共通である。
【００７９】
bool  getModel(std::string  &)
この関数はデバイスのモデルを獲得する。モデルが取得された場合、関数はtrueを返す。プロセス中にエラーが検出された場合、関数はヌル文字列とともにfalseを返す。関数はVendorModelおよびHTTP_HTMLパッケージに共通である。
【００８０】
bool getUniqueID(std::string & out_sID)
この関数はデバイスの固有ＩＤを返す。固有ＩＤが取得された場合、関数はtrueを返す。プロセス中にエラーが検出された場合、関数はヌル文字列とともにfalseを返す。関数はVendorModelおよびHTTP_HTMLパッケージに共通である。
【００８１】
bool  getVendorModelID(int  &  out_nID)
この関数はデバイスのベンダモデルＩＤを返す。そのＩＤが取得された場合、関数はtrueを返す。プロセス中にエラーが検出された場合、関数はfalseを返す。この関数はVendorModelおよびHTTP_HTMLパッケージに共通である。
【００８２】
Cdevice  *  createDevice(std::string  &  in_sIP，CHTTP_HTML  &  in_HTTP_HTML，int  &  in_nVendorModelID，std::string  &  in_sUniqueID)
この関数は、指定のデバイスをDeviceFactoryに作成する。関数は、作成が成功すれば、作成されたデバイスへポインタを返し、さもなければ０を返す。
【００８３】
bool  getStatus(std::map<infoType，std::string>  &)
この関数は、デバイスからステータス情報を取得する。関数は、ステータスが返されればtrueを返し、ステータスを取得することができなければfalseを返す。この関数はDeviceおよびHTTP_HTMLパッケージに共通である。
【００８４】
void  setIPAddressAndID(std::string  &  in_sIP，int  in_nID)
この関数はＩＰアドレスおよびベンダモデルＩＤをセットする。
【００８５】
bool  getVendorInfo(std::string  &  out_sVendor，std::string  &  out_sWebPage，CkeyValueInfo  &  out_KeyValueInfo)
この関数は、ベンダ名の文字列、ベンダからモデル情報を取得するためのウェブページ、モデルのCKeyValueInfo構造体を出力する。関数は、データが取得されればtrueを返し、もはやデータが得られなければヌル文字列およびヌルデータとともにfalseを返す。falseが返された場合、データポインタはデータの最初にリセットされる。
【００８６】
bool  getVendorModelInfo(std::string  &  out_sVendor，std::string  &  out_sModel，int  &  out_nID，std::string  &  out_sWebPage，CkeyValueInfo  &  out_KeyValueInfo)
この関数は、ベンダ名、モデル名の文字列、ベンダモデルＩＤ、固有ＩＤを取得するためのウェブページ、および固有ＩＤに対するCKeyValueInfo構造体を出力する。関数は、データが取得されればtrueを返し、もはやデータが得られなければヌル文字列およびヌルデータとともにfalseを返す。falseが返された場合、データポインタはデータの最初にリセットされる。
【００８７】
void  setVendorModelID(int  in_nID)
この関数は、ウェブページ情報を獲得するためにSupportInfoODBCによって使用されるVendorModelID値をセットする。
【００８８】
bool  getWebPageInfo(std::string  &  out_sWebPage，CkeyValueInfo  &  out_KeyValueInfo)
この関数は、前の関数によってセットされたベンダモデルＩＤに対するウェブページおよびCKeyValueInfo構造体を出力する。関数は、情報が返されればtrueを返し、もはやデータが得られなければヌル情報とともにfalseを返す。falseが返された場合、データポインタは、セットされている現在のベンダモデルＩＤの最初にリセットされる。返された情報は、HTTP_HTMLパッケージのマップ構造体に格納される。
【００８９】
図１２は、図１１に示したHTTP_HTMLサブモジュール１１１２およびSupportInfoODBCサブモジュール１１１４が、HTTP_HTMLサブモジュール１１１２によって受信されるキー値に関連する値の取り出しのための情報を交換するために使用されるデータ構造体を示している。通常、多数のベンダが、それぞれのウェブページに表示される、被監視デバイスに関連するキー情報を識別するために、ベンダ固有の識別子および命名法を使用している。例えば、プリンタデバイスによって印刷されるページ数を決めるため、Hewlett  Packardは「Page  Count」機能を使用する一方、Xeroxは「Total  Sheet  Delivered」機能を用いてそれを識別する。本発明の特徴は、図１２に示すようなデータ構造体／CKeyValueInfo構造体１２００を使用することによって、ベンダ間の相違を克服し、それによりデバイス固有情報を識別する標準化された統一的方法を提供し、その情報に対応する値を抽出することである。
【００９０】
CKeyValueInfoは通常、データ文字列またはキー文字列の形態で被監視デバイスから受信される情報から値情報を識別するために作成されるデータ構造体である。CKeyValueInfoは複数のフィールドを含み、各フィールドは図１２に示す情報によって表される。CKeyValueInfo構造体１２００は、文字列キーを表すsKeyフィールド１２０４と、その文字列内で値情報が位置し得る位置の個数について示す、好ましくはＨＴＭＬフォーマットのタグに基づく値であるnPositionフィールド１２０６を含む。例えば、監視を受けているプリンタデバイスのPage  Countは、キーワードに続く２番目の位置に見つかるかもしれない。sType１２０８は、被監視デバイスの表示されたウェブページから取り出すことができる情報の型を表す。
【００９１】
例えば被監視デバイスのモデル名のような値がキー（Product  Name）と同じデータ行内に見つかる場合、nPositionフィールドは「０」である。sDelimiter１２１０は、キーに関連する値を抽出するために使用される特定のデリミタを示す。CKeyValueInfoは、被監視デバイスからＨＴＭＬフォーマットで受信される情報から値情報を抽出する方法を示す。
【００９２】
図１３は、図１０に示したMonitorモジュール１００６の呼出しシーケンスを説明するためにinit関数のシーケンスを示している。MonitorManager１１０２は、被監視デバイスに関する情報を取得し、被監視デバイスに割り当てられているＩＰアドレスを用いて被監視デバイスと通信する。MonitorManager１１０２は、DeviceODBC１１０４にアクセスして、被監視デバイスに関するコンフィグレーション情報を取得する。MonitorManager１１０２に返されるコンフィグレーション情報には、例えば、被監視デバイスのＩＰアドレス、被監視デバイスのベンダ／製造元およびモデル情報がある。ＩＰアドレスが取得されると、MonitorManager１１０２は、被監視デバイスからデバイス固有情報を取得するためにそのＩＰアドレスをセットする。ベンダ、モデル、固有ＩＤ、およびベンダモデルＩＤを被監視デバイスから取得するためにHTTP_HTML１１１２が使用される。
【００９３】
ベンダ、モデル情報および固有ＩＤが取得されると、MonitorManager１１０２は、被監視デバイスから受信された情報でデータベースを更新する。さらに、MonitorManager１１０２は、DeviceFactory１１０６を通じてソフトウェアデバイスオブジェクトを作成する。ベンダ／製造元からの各デバイスモデルには固有の識別子が割り当てられていることがあり、効率を高めるために識別子を用いてベンダからのモデルを表すことが好ましい。というのは、識別子は通常、４バイト以下しか必要としないからである。
【００９４】
ベンダ、モデルおよび固有ＩＤのような値情報を被監視デバイスから抽出する方法は、図１２に示した形態でSupportInfoODBC１１１４から取得される。さらに、どの特定のウェブページにアクセスする必要があるかは、SupportInfoODBC１１１４内にある情報によって支配される。ＩＰアドレス、ベンダモデルＩＤおよび固有ＩＤが取得されると、被監視デバイスのソフトウェアオブジェクトがDeviceFactoryモジュール１１０６を用いて作成される。ソフトウェアオブジェクトが作成されると、ベンダ、モデル、および固有ＩＤが、各被監視デバイスのステータス情報を格納するDeviceODBCデータベースにセットされるように、DeviceODBC内の情報が更新される。更新は、MonitorManager１１０２によって、updateConfig関数１１０９により実行される。
【００９５】
図１４は、HTTP_HTMLパッケージ１１１２によって、定期的に監視されるデバイスのステータス情報を取り出すために使用される例示的なマップデータ構造体１４００を示している。マップ構造体すなわちデータ構造体１４００は、Ｃ＋＋の標準テンプレートの一部である。しかし、他の言語が、キーおよび値情報がテーブル状の構造体内に配置されるような同様のデータ構造体を有することも可能である。マップ構造体１４００の第１レベル１４０２は、別のマップ構造体１４０４に関連づけられるキーを含む。マップ構造体１４０４では第１レベル１４０２からのキーが値に関連づけられる。第２レベルマップ１４０４は、フィールド１４０６で指定されるウェブページをキーとし、フィールド１４０８で指定されるCKeyValueInfoのベクタを値として含む。
【００９６】
MonitorManager１１０２によって使用されるデータ構造体を以下に示す。このデータ構造体は、１つの被監視デバイスに関する情報を反映する。データ構造体は、連絡担当者の電子メールアドレスを電話番号に加えて含む。次のテーブル１はDeviceInfo構造体を示す。
【表１】
2004213654.tif 000003
【００９７】
図１５は、本発明の図１３に示したDeviceFactory１１０６によって作成されMonitorManager１１０２によって使用されるデバイスへの参照のベクタ１５００を示している。MonitorManager１１０２は、被監視デバイスのステータスを繰り返し取得することができるように、DeviceFactory１１０６によって作成されたデバイスポインタ１５０２、１５０４をベクタに格納する。被監視デバイスのポーリングは、getStatusコマンドを発行することによってデバイスオブジェクトに対して実行される。それぞれのソフトウェアオブジェクトのステータスが取得されると、このステータスはDeviceODBC１１０４を通じて更新される。
【００９８】
図１６は、図１０に示したmonitorStatus関数のシーケンスを示している。MonitorManager１１０２は、HTTP_HTML１１１２を通じて、物理デバイスに接続されているソフトウェアデバイスオブジェクトのステータスを取得し、受信したステータスをMonitorManager１１０２によりDeviceODBC１１０４を通じてデータベースに格納する。このプロセスは、図１５に示したベクタに格納されているすべての被監視デバイスにわたって繰り返される。
【００９９】
図１７Ａおよび１７Ｂは、HTTP_HTMLモジュール１１１２（図１１）を通じての情報収集をサポートするテーブル構造体を示している。図１７Ａ〜Ｂに示すテーブルは、好ましくは、SupportInfoODBC１１１４を通じて監視システム９０２（図９）と通信するデータベースに格納される。具体的には、図１７Ａは、４個のテーブルを、それぞれのデータベースフィールドとともに示している。KeyValueテーブル１７０４は、例えば、ウェブページＩＤ、対象となるパラメータ値を抽出するために使用されるキー文字列情報、ＨＴＭＬ構造内の値位置、値の型、値がキー文字列と同じデータ内に配置されている場合のデリミタ、値がキー文字列と同じデータ内に配置されている場合の値のnInLinePosition、およびキー文字列に対する標準の列挙子のような情報を含む。
【０１００】
VendorModelWebPageテーブル１７０６は、ウェブページＩＤを実際のウェブページ文字列と関連づける。KeyEnumTable１７０８は、標準列挙およびそれらの説明を含む。VendorModelInformationテーブル１７１０は、被監視デバイスに対するベンダ関連情報を含み、VendorModelUniqueIDテーブル１７１２は、デバイスから固有ＩＤを取得するために使用される情報を含む。
【０１０１】
図１７Ｃは、図１７Ａ〜Ｂに示した３つのテーブル内に格納される例示的なデータを示している。ＩＰアドレステーブル１７０２は、デバイスをＩＰアドレスに関連づける特定のネットワーク環境の一例である。この例では、ウェブＩＤの最初の４桁の数字は、ベンダモデルＩＤの最初の４桁の数字から取られている。KeyValueテーブル１７０４では、１７１４および１７１６で識別されるモデル（１０１）は２個の異なるキー文字列、「Machine  Model」および「Product  Name」を有する。さらに、Machine  ModelおよびProduct  Nameは異なる値位置に配置されている。Machine  ModelはＨＴＭＬにおける次のタグ付きデータから取得されるのに対して、Product  Nameは同じ行から取得される。Product  Nameは、実際のモデル名からデリミタ「:」で分けられる。本発明によって使用される例示的なenum型は以下のものを含む。これらのenum型は単に例示であり、したがって本発明を限定するものと解釈されてはならない。
【０１０２】
infoType（typedef  int  infoType）
このセクションは、infoType（int）の定義を記述する。値範囲０〜９９はデータ型に割り当てられる。値範囲１００〜４９９はデバイス情報に割り当てられる。値範囲５００〜１９９９は標準ＭＩＢパラメータを含む共通パラメータに割り当てられる。値範囲２０００〜３９９９はRicoh固有情報に割り当てられる。値範囲４０００〜４９９９はXeroxに割り当てられる。値範囲５０００〜５９９９はLexmarkに割り当てられる。値範囲６０００〜６９９９はHPに割り当てられる。値は以下のように定義される。
【０１０３】
infoType｛eNotDefine＝0，eDeviceInformation=1，eStatusInformation＝2，eManufacturer＝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};
【０１０４】
ErrorCode
このセクションは、本明細書記載時に定義されているエラーコードを記述する。プロジェクトが進むにつれて、より多くのエラーコードを追加することができる。範囲０〜９９は予約されている。範囲１００〜１９９はＳＭＴＰ、２００〜２９９はＰＯＰ３、３００〜３９９はソケット、および４００〜４９９はＨＴＴＰに対するものである。他の範囲は必要があれば定義される。
【０１０５】
enum  EerrorCode（eNoError＝0，eUnknownError＝1，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）;
【０１０６】
図１８は、複数の被監視デバイスから情報を収集するために複数のプロトコルが使用される、現在のシステムの拡張を示している。このような拡張の一例は、ＳＮＭＰ１８０４およびＨＴＴＰ１８０６の両方のプロトコルを用いて被監視デバイスのステータス情報を収集するものである。複数のプロトコルにより、監視ステーションがより広い範囲のデータを収集することが可能となる。さらに、複数のプロトコルにより、より多くのデバイスが監視されることが可能となる。例えば、いくつかのデバイスはただ１つのプロトコルしかサポートしていないかもしれない。プロトコルマネージャ(Protocolmanager)１８０２が選択プロセスを実行し、所与の複数のプロトコルのうちで、被監視デバイスから情報を取り出すためにより良く構成されたプロトコルを選択する。例えば、紙詰まりステータスを取り出すには、いくつかのベンダのデバイスに対しては、ＨＴＴＰプロトコルよりもＳＮＭＰプロトコルのほうが適していると判定された。既知のデバイスに対して、このような優先順位はあらかじめ定められ、SupportInfoODBC１１１４のようなデータベースに格納される。プロトコルマネージャ１８０２は、SupportInfoODBC１１１４を参照して、所定の優先順位を識別し、被監視デバイスと通信するためのプロトコルを適宜選択する。
【０１０７】
もう１つの実施形態では、被監視デバイスから情報を取り出すために複数のプロトコルが使用される。例えば、被監視デバイスにアクセスするためにHTTP_HTMLプロトコルがまず選択され、HTTP_HTMLプロトコルを用いて効率的に取り出されるように構成されているデバイス情報が取得される。次に、HTTP_HTMLプロトコルを用いて効率的に取り出すことができなかった情報を取得するためにＳＮＭＰプロトコルが選択される。プロトコルの選択は、SupportInfoODBC１１１４に格納されているサポート情報を用いて、プロトコルマネージャによって実行される。
【０１０８】
図１９は、被監視デバイスに関する情報を電子メールで所望の当事者に送信する概略図を示している。必要な情報を取得した後、ワークステーション９０２は、Ｓｉｍｐｌｅ  Ｍａｉｌ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ（ＳＭＴＰ）サーバ１９０２を用いて、Ｐｏｓｔ  Ｏｆｆｉｃｅ  Ｐｒｏｔｏｃｏｌ  Ｖｅｒｓｉｏｎ  ３（ＰＯＰ３）（ＩＥＴＦ  Networking  Group  Request  For  Comments［ＲＦＣ］：１９３９）をサポートするメールサーバ１９０８を通じて、その必要情報を中央監視ワークステーション１９１０へ送出する。ワークステーション９０２は、ＳＭＴＰ（ＳＭＴＰはＩＥＴＦ  ＲＦＣ８２１に規定されている）およびおそらくはＭｕｌｔｉｐｕｒｐｏｓｅ  Ｉｎｔｅｒｎｅｔ  Ｍａｉｌ  Ｅｘｔｅｎｓｉｏｎｓ（ＭＩＭＥ）を用いて電子メールを送信する。ワークステーション９０２は、ＴＣＰ／ＩＰモデルまたはＩＳＯ７層モデルのアプリケーション層およびその上にあるメールメッセージを生成する。別法として、ワークステーション９０２は、電子メールを用いて必要情報を送出するためにＳＭＴＰプロセッサを含んでもよい。電子メールは、ＳＭＴＰサーバ１９０２から送出されると、ファイアウォール１９０６を通る。
【０１０９】
デバイスの監視情報を含む電子メールが、その情報を受信するネットワークのファイアウォール１９０４に到着すると、メールはＰＯＰ３のメールサーバ１９０８へ転送される。中央監視ワークステーション１９１０は、定期的にメールサーバ１９０８にアクセスして、到着した電子メールを取得し、ＰＯＰ３によりメールおよびその内容を解析し、必要情報をデータベース１９１２に格納する。データベース１９１２は、被監視デバイスの特性および履歴に関連する追加情報を含む。中央監視ワークステーション１９１０は、必要なアクションをとるために、取得されたデータの分析を実行することができる。別法として、中央監視ワークステーション１９１０がメール受信機能を含み、ファイアウォール１９０４が電子メールを中央監視ワークステーション１９１０に直接転送してもよい。
【０１１０】
図２０は、図１１に示したHTTP_HTML（１１１２）パッケージのクラスダイヤグラムを示している。HTTP_HTML（１１１２）パッケージは、Ｈｙｐｅｒｔｅｘｔ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ（ＨＴＴＰ）を用いて監視されている例えばネットワークプリンタ９０８（図９）のようなデバイスのベンダ、モデル、固有ＩＤ、およびベンダモデルＩＤを判定することを担当する。この情報がネットワークプリンタについて取得されると、ＨＴＴＰを用いてネットワークプリンタからステータス情報を取得するためにパッケージ１１１２が使用される。CHTTP_HTML（２０００）クラスは、パッケージ１１１２がＨＴＴＰを用いてネットワークプリンタのウェブサーバにアクセスすることによってネットワークプリンタに関する情報を取得するためのインタフェースである。CHTTP_HTML（２０００）は、このタスクを実行するためにパッケージ１１１２内の他のクラスを管理する。CHTTP（２００４）クラスはＨＴＴＰプロトコルを実装する。CHTTP（２００４）は、ネットワークプリンタとのＨＴＴＰセッションを作成して、そのウェブサーバのウェブページから情報を取得する。CHTTP（２００２）は、Microsoft  Foundation  Classライブラリ（ＭＦＣ）のクラスCInternetSession（２００８）、CHttpConnection（２０１０）、およびCHttpFile（２０１２）を用いてＨＴＴＰプロトコルを実装する。CHTMLProcessor（２００２）クラスは、ネットワークプリンタから取得されるＨＴＭＬファイルを処理し、ＨＴＭＬファイルから所望の情報を取得する。CHTTP_HTML（２０００）クラスは、SupportInfoODBC（１１１４）パッケージを用いて、監視システムによってサポートされるネットワークプリンタのベンダおよびモデルに関する情報を取得する。本明細書における説明はネットワークプリンタに言及しているが、本システムは例えば複写機、スキャナ、およびファクシミリ機のような任意のネットワークデバイスにも適用可能である。
【０１１１】
CHTTP_HTML（２０００）クラスは、ネットワークプリンタがシステムによってサポートされているかどうかを判定する。ネットワークプリンタがサポートされている場合、CHTTP_HTML（２０００）はネットワークプリンタとのＨＴＴＰセッションを作成して、ネットワークプリンタのウェブページから情報を取得する。CHTTP_HTML（２０００）の公開(public)および非公開(private)関数をテーブル２に示す。これらの関数によって使用されるCHTTP_HTML（２０００）の属性をテーブル３に示す。
【０１１２】
テーブル２：CHTTP_HTMLの公開および非公開関数
【表２】
2004213654.tif 000004
【０１１３】
テーブル３：CHTTP_HTMLの属性
【表３】
2004213654.tif 000005
【０１１４】
CHTMLProcessor（２００２）クラスは、ＨＴＭＬファイルの行を解析して、ネットワークプリンタ９０８（図９）に関する特定の情報を取得する。CHTMLProcessor（２００２）の公開および非公開関数をテーブル４に示す。これらの関数によって使用されるCHTMLProcessor（２００２）の属性をテーブル５に示す。
【０１１５】
テーブル４：CHTMLProcessorの公開および非公開関数
【表４】
2004213654.tif 000006
【０１１６】
テーブル５：CHTMLProcessorの属性
【表５】
2004213654.tif 000007
【０１１７】
図２１は、CHTTP_HTML（２０００）のinit()関数を実行するシーケンスダイヤグラムを示している。init()は、システムによってサポートされるネットワークプリンタのベンダおよびモデルに関する情報を取得し保守する。init()は、この情報を取得し保守するために、CHTTP_HTML（２０００）の関数setVendorModelInfoVector()およびsetVendorModelIDMap()を呼び出す。setVendorModelInfoVector()は、システムによってサポートされるネットワークプリンタのベンダに関する情報およびネットワークプリンタのモデルをそのウェブページから取得するために使用される情報を取得し保守する。
【０１１８】
setVendorModelInfoVector()は、この情報をデータベースから取得するために、SupportInfoODBC（１１１４）のgetVendorInfo()を呼び出す。setVendorModelInfoVector()は、図２２に示すようなベクタにその情報を格納する。SupportInfoODBC（１１１４）のgetVendorInfo()は、システムによってサポートされるすべてのベンダを取得するために複数回呼び出される。setVendorModelIDMap()は、ベンダ、モデルに関する情報、ベンダモデルＩＤ、およびネットワークプリンタの固有識別子をそのウェブページから取得するために使用される情報を取得し保守する。
【０１１９】
setVendorModelIDMap()は、この情報をデータベースから取得するために、SupportInfoODBC（１１１４）のgetVendorModelInfo()を呼び出す。setVendorModelIDMap()は、図２３に示すようなマップにその情報を格納する。SupportInfoODBC（１１１４）のgetVendorModelInfo()は、システムによってサポートされるすべてのモデルを取得するために複数回呼び出される。システムによってサポートされるネットワークプリンタのベンダおよびモデルに関する情報を格納することによって、ネットワークプリンタがサポートされているかどうかを判定するためにデータベースを定期的にオープンしクローズする必要がなくなる。データベースは、システムによってサポートされるベンダおよびモデルに関するすべての情報を取得するために１回オープンされクローズされる。システム自身の構造体に格納されている情報をチェックすることによって、システムは、特定のネットワークプリンタがサポートされているかどうかを判定することができる。
【０１２０】
図２２は、システムによってサポートされるネットワークプリンタのベンダに関する情報、およびネットワークプリンタのモデルをそのウェブページから取得するために使用される情報を格納するためにクラスCHTTP_HTML（２０００）によって使用されるベクタm_VendorModelInfoVector（２２００）を示している。m_VendorModelInfoVector（２２００）は、構造体CVendorModelInfo（２２０２）を含む。構造体CVendorModelInfo（２２０２）は、ネットワークプリンタのベンダ名の文字列、モデル名が見出されるネットワークプリンタのウェブページの文字列、およびそのウェブページからモデル名を取得するために使用される情報を含む構造体CKeyValueInfo（２２０４）を含む。構造体CKeyValueInfo（２２０４）は図１２に記載されている。システムがベクタm_VendorModelInfoVector（２２００）からのエントリを使用するとき、システムは、構造体CVendorModelInfo（２２０２）に対応するウェブページにアクセスしようとする。システムがそのウェブページにアクセスすることができる場合、ネットワークプリンタのベンダは構造体CVendorModelInfo（２２０２）内のベンダ名であると判定される。
【０１２１】
ネットワークプリンタのモデル名は、構造体CVendorModelInfo（２２０２）の構造体CKeyValueInfo（２２０４）内の情報を用いてウェブページから取得される。モデル名がウェブページから取得された場合、好ましくは、図２３で後述するマップm_VendorModelIDMapを用いて、モデルがサポートされているかどうかを判定するチェックがなされる。システムがウェブページにアクセスすることができない場合、またはモデル名をウェブページから取得することができない場合、システムは、ベンダを判定することができ、かつモデル名を取得することができるまで、ベクタ内の次の要素に進む。システムが、ベンダを判定してモデル名を取得することなくベクタ全体を調べ尽くしてしまった場合、ネットワークプリンタはシステムによってサポートされていないと判定される。ベクタは、同じベンダ名を有する複数のエントリを有してもよい。この可能性があるのは、ベンダがネットワークプリンタの複数のファミリを有し、各ファミリはモデル名が見出される異なるウェブページを有するかもしれないからである。また、ベンダが複数のネットワークデバイス（すなわち、スキャナ、ファクシミリ機）を有し、各ネットワークデバイスはモデル名が見出される異なるウェブページを有してもよい。
【０１２２】
図２３は、ベンダ、モデルに関する情報、ベンダモデルＩＤ、およびネットワークプリンタの固有識別子をそのウェブページから取得するために使用される情報を格納するためにクラスCHTTP_HTML（２０００）によって使用されるマップm_VendorModelIDMap（２３００）を示している。m_VendorModelIDMap（２３００）のキーはベンダ名を表す文字列である。m_VendorModelIDMap（２３００）の値は別のマップ（２３０２）構造体である。マップ（２３０２）のキーはモデル名を表す文字列である。マップ（２３０２）の値は構造体CVendorModelID（２３０４）である。構造体CVendorModelID（２３０４）は、ベンダモデルＩＤの整数、固有識別子が見出されるネットワークプリンタのウェブページの文字列、およびそのウェブページから固有識別子を取得するために使用される情報を含む構造体CKeyValueInfo（２３０６）を含む。構造体CKeyValueInfo（２３０６）についてさらに詳細には図１２に記載されている。上記のようにベクタm_VendorModelInfoVector内の情報を用いてベンダ名およびモデル名が取得された後、システムはこのマップを使用する。ベンダ名は、m_VendorModelIDMap（２３００）からマップ（２３０２）を取得するためのキーとして使用される。モデル名は、マップ（２３０２）から構造体CVendorModelID（２３０４）を取得するためのキーとして使用される。ネットワークプリンタに関連するベンダモデルＩＤは、構造体CVendorModelID（２３０４）のm_nVendorModelIDメンバから取得される。システムは、構造体CVendorModelID（２３０４）のm_sWebPageForUniqueIDメンバに対応するネットワークプリンタのウェブページにアクセスする。システムがそのウェブページのアクセスに成功することができた場合、ネットワークプリンタの固有ＩＤが、構造体CvendorModelID（２３０４）の構造体CKeyValueInfo（２３０６）内の情報を用いてそのウェブページから取得される。システムがウェブページにアクセスすることができない場合、または固有ＩＤをウェブページから取得することができない場合、固有ＩＤがネットワークプリンタに対して乱数ジェネレータを用いて生成される。モデル名がマップ（２３０２）内のキーとして見つからない場合、そのモデルはシステムによってサポートされていないと判定される。
【０１２３】
ベクタm_VendorModelInfoVector（２２００）およびマップm_VendorModelIDMap（２３００）は、データベース内の情報を表現するために使用されるシステムの内部構造体である。ベクタm_VendorModelInfoVector（２２００）はサポートデータベースのVendorModelInformationテーブルを表し、マップm_VendorModelIDMap（２３００）はサポートデータベースのVendorModelAndUniqueIDsテーブルを表す。サポートデータベースからの情報をこれらの内部構造体に格納することによって、システムはより効率的になる。というのは、所望の情報を取得するために定期的にデータベースにアクセスする必要がないからである。
【０１２４】
図２４は、CHTTP_HTMLのinit()関数を実行するフローチャートを示している。ステップ２４０２で、システムは、サポートデータベース内にまだ他にベンダ情報があるかどうかを判定する。まだ他に情報がある場合、ステップ２４０４で、ベンダ名、モデル名が探索されるウェブページ、およびモデル名をそのウェブページから取得するために使用される情報が取得される。ステップ２４０６で、この情報は構造体CVendorModelInfo（２２０２）に格納された後、ステップ２４０８で、図２２に示したようなベクタ（２２００）内にプッシュされる。その後、システムはステップ２４０２に戻り、サポートデータベース内にまだ他にベンダ情報があるかどうかを調べる。サポートデータベース内にもはやベンダ情報がない場合、システムはステップ２４１０を実行し、サポートデータベース内にまだ他にベンダモデル情報があるかどうかを判定する。まだ他にベンダモデル情報がある場合、ステップ２４１２で、ベンダ名、モデル名、ベンダモデルＩＤ、固有識別子が探索されるウェブページ、および固有識別子をそのウェブページから取得するために使用される情報が取得される。ステップ２４１４で、ベンダモデルＩＤ、固有識別子が探索されるウェブページ、および固有識別子をそのウェブページから取得するために使用される情報が、構造体CVendorModelIDに格納される。ステップ２４１６で、モデル名および構造体CVendorModelIDは図２３に示したようなマップ（２３０２）に追加され、ベンダ名およびマップ（２３０２）は図２３に示したようなマップm_VendorModelIDMap（２３００）に追加される。その後、システムはステップ２４１０に戻り、サポートデータベース内にまだ他にベンダモデル情報があるかどうかを判定する。サポートデータベース内にもはやベンダモデル情報がない場合、init()関数が完了する。
【０１２５】
図２５は、CHTTP_HTML（２０００）のgetStatus()関数を実行するシーケンスダイヤグラムを示している。この関数は、ステータス情報をネットワークプリンタのウェブページから取得する。取得されるステータス情報はネットワークプリンタのベンダおよびモデルに左右されるので、あるネットワークプリンタから取得されるステータス情報のタイプは、別のネットワークプリンタのものとは異なるかもしれない。CHTTP_HTMLは、特定のベンダおよびモデルのネットワークプリンタからどのようなステータス情報を取得すべきかに関する情報を含む図１４に示したマップ（１４００）構造体を含む。マップ（１４００）は、ステータス情報をネットワークプリンタのウェブページから取得する方法に関する情報を含む。CHTTP_HTML（２０００）は、CHTTP（２００４）のcreateHTTPSession()を呼び出すことによってネットワークプリンタとのＨＴＴＰセッションを作成する。ＨＴＴＰセッションが作成された後、CHTTP_HTML（２０００）がCHTTP（２００４）のsendGetRequest()を呼び出すと、ウェブページにアクセスするためにＨＴＴＰ
GETリクエストがネットワークプリンタへ送信される。GETリクエストが成功した場合、CHTTP_HTML（２０００）はCHTMLProcessor（２００２）のsetDataSearchInfo()を呼び出して、CHTMLProcessor（２００２）に、ステータス情報をネットワークプリンタのウェブページから取得する方法に関する情報を提供する。CHTTP_HTML（２０００）はCHTTP（２００４）のgetNextLineOfHTML()を呼び出して、ネットワークプリンタのウェブページから１行を取得する。CHTTP_HTML（２０００）はウェブページのこの行を、CHTMLProcessor（２００２）の関数searchDataFromHTML()に渡す。
【０１２６】
CHTMLProcessor（２００２）はこの行からステータス情報を、もしそれが存在すれば、取得する。CHTTP_HTML（２０００）は、ウェブページの最後に到達するか、またはすべてのステータス情報がウェブページから取得されるまで、CHTTP（２００４）のgetNextLineOfHTML()を呼び出してからCHTMLProcessor（２００２）のsearchDataFromHTML()を呼び出すことを続ける。CHTTP_HTML（２０００）は、CHTMLProcessor（２００２）のgetDataFromHTML()を呼び出して、ウェブページから取得されたステータス情報を獲得する。ネットワークプリンタのステータス情報は複数のウェブページに存在するかもしれないので、CHTTP（２００４）のsendGetRequest()からCHTMLProcessor（２００２）のgetDataFromHTML()までの呼出しシーケンスは、ステータス情報を含むネットワークプリンタの各ウェブページごとに繰り返される。すべてのステータス情報が取得された後、CHTTP_HTML（２０００）はCHTTP（２００４）のcloseHTTPSession()を呼び出して、ネットワークプリンタとのＨＴＴＰセッションをクローズする。
【０１２７】
図２６は、ネットワークプリンタのウェブページから情報を取得するためにクラスCHTMLProcessorによって使用されるベクタm_KeyValueVector（２６００）およびm_LocateValueVector（２６０４）を示している。ベクタm_KeyValueVector（２６００）は構造体CKeyValueInfo（２６０２）を含む。構造体CKeyValueInfo（２６０２）は、ネットワークプリンタのウェブページから情報を探索し取得するために使用される情報を含む。構造体CKeyValueInfo（２６０２）は図１２にさらに詳細に記載されている。構造体CKeyValueInfo（２６０２）のsKeyメンバは、ウェブページ上の情報に対するキーを探索するために使用される。構造体CKeyValueInfo（２６０２）のnPosition、sDelimiter、およびnInLinePositionメンバは、ウェブページ上の情報の値を探索し取得するために使用される。nPosition、sDelimiter、およびnInLinePositionは、ウェブページ上のsKeyに関する情報の値の位置を与える。ベクタm_LocateValueVector（２６０４）は構造体CLocateValueInfo（２６０６）を含む。構造体CLocateValueInfo（２６０６）は、ウェブページ上の情報を見つけたかどうかの状態に関する情報を含む。構造体CLocateValueInfo（２６０６）のm_bKeyFoundは、キーが見つかったかどうかを判定する。構造体CLocateValueInfo（２６０６）のm_bValueObtainedは、値が取得されたかどうかを判定する。構造体CLocateValueInfo（２６０６）のm_nCounterは、情報の値を検索する際のキーに関する現在のデータ位置を判定するために使用される。２つのベクタの間には一対一対応がある。したがって、m_KeyValueVector（２６００）内の構造体CKeyValueInfoはm_LocateValueVector（２６０４）内の構造体CLocateValueInfoに対応する。両方のベクタは同数の要素を有する。ベクタはともに、ネットワークプリンタに関する情報をそのウェブページから取得するために使用される。
【０１２８】
図２７は、CHTMLProcessor２００２（図２０）のsearchDataFromHTML()関数を実行するフローチャートを示している。ネットワークプリンタのウェブページからの１行がこの関数に渡される。各行は、ネットワークプリンタの所望の情報のキーおよび値を求めて検索される。ステップ２７０２および２７０４で、ベクタm_KeyValueVectorおよびm_LocateValueVectorに対応するベクタ反復子がベクタの最初にセットされる。ベクタ反復子はベクタ内の要素を指す。ステップ２７０６で、ベクタ反復子の一方がベクタの最後にあるかどうかを調べるチェックがなされる。両方のベクタは同サイズであるので、一方のベクタ反復子のみをチェックすればよいであろう。ベクタ反復子がベクタの最後にある場合、ステップ２７０８でsearchDataFromHTML()関数は終了する。
【０１２９】
ステップ２７１０で、m_LocateValueVectorに対するベクタ反復子によって指されているCLocateValueInfoのm_bKeyFoundメンバがtrueであるかどうかを判定するチェックがなされる。CLocateValueInfoのm_bKeyFoundメンバは、m_KeyValueVectorに対するベクタ反復子によって指されているCKeyValueInfoのsKeyメンバがウェブページの前の行に見つかったかどうかを判定する。m_bKeyFoundがtrueでない場合、ステップ２７１２が実行される。ステップ２７１２で、m_KeyValueVectorに対するベクタ反復子によって指されているCKeyValueInfoのsKeyメンバがチェックされ、関数に渡されたウェブページの行にsKeyが存在するかどうかが判定される。sKeyがウェブページの行に見つからない場合、ステップ２７２０で、m_KeyValueVectorおよびm_LocateValueVectorに対するベクタ反復子が、ベクタ内の次の要素を指すようにインクリメントされ、システムはステップ２７０６の実行に進む。
【０１３０】
ステップ２７１２で、sKeyがウェブページの行に見つかった場合、ステップ２７１４で、m_LocateValueVectorに対するベクタ反復子によって指されているCLocateValueInfoのm_bKeyFoundメンバがtrueにセットされる。次に、ステップ２７１６で、m_KeyValueVectorに対するベクタ反復子によって指されているCKeyValueInfoのnPosition、sDelimiter、およびnInLinePositionメンバを用いて、ウェブページの行からsKeyに対応する値を取得する。値をウェブページの現在の行から取得することができない場合、CLocateValueInfoのm_nCounterが更新される。m_nCounterは、ウェブページ内のsKeyからのデータ位置を追跡し、その後、ステップ２７２０に示すように、m_KeyValueVectorおよびm_LocateValueVectorに対するベクタ反復子が、ベクタ内の次の要素を指すようにインクリメントされる。値がウェブページの行から取得された場合、ステップ２７１８で、sKeyに対応するCKeyValueInfoのeStdEnumメンバおよび取得された値が、ネットワークプリンタに関するすべての情報を含むマップに追加される。また、ステップ２７２２を実行する前に、CLocateValueInfoのm_bValueObtainedメンバがtrueにセットされる。
【０１３１】
ステップ２７１０でm_LocateValueVectorに対するベクタ反復子によって指されているCLocateValueInfoのm_bKeyFoundメンバがtrueである場合、ステップ２７２２が実行される。ステップ２７２２で、m_LocateValueVectorに対するベクタ反復子によって指されているCLocateValueInfoのm_bValueObtainedメンバがtrueであるかどうかを調べるチェックがなされる。CLocateValueInfoのm_bValueObtainedメンバは、CKeyValueInfoのsKeyに対応する値がウェブページの行から取得されたかどうかを示す。CLocateValueInfoのm_bValueObtainedがfalseである場合、ステップ２７２４が実行される。ステップ２７２４で、CKeyValueInfoのnPosition、sDelimiter、およびnInLinePositionメンバならびにCLocateValueInfoのm_nCounterを用いて、ウェブページの行からsKeyに対応する値を取得する。sKeyに対応する値をウェブページの行から取得することができない場合、CLocateValueInfoのm_nCounterが更新され、次にステップ２７２０が処理される。しかし、sKeyに対応する値を取得することができた場合、次にステップ２７１８が処理される。ステップ２７２０および２７１８は上記で説明したので、ここでは繰り返さない。
【０１３２】
ステップ２７２２でCLocateValueInfoのm_bValueObtainedがtrueである場合、ステップ２７２６で、反復子に対応する要素がm_KeyValueVectorおよびm_LocateValueVectorから除去され、その後ステップ２７０６が実行される。
【０１３３】
上記のように、２つのベクタを用いて情報を取得することにより、ウェブページ全体を一度に１データずつ検索するのではなく、ウェブページの各行ですべてのデータを検索することが可能となる。これにより、ウェブページから取得する必要のある各情報ごとにネットワークプリンタから同一ウェブページを読み出すことが不要となる。
【０１３４】
図２８は、２つのベクタm_KeyValueVector（２８００）およびm_LocateValueVector（２８０２）ならびにネットワークプリンタのウェブページ（２８０４）からの行の例示的な概略図を示している。ウェブページ（２８０４）の行は、ネットワークプリンタから一度に１行ずつ読み込まれる。行から取得することができるデータ要素は太字で示されている。理解されるように、ウェブページのＨＴＭＬタグ内の情報は、ネットワークプリンタに関する所望の情報を含まない。情報のキーおよび値を取得すべき場所はデータ要素である。ウェブページの各行について、ベクタm_KeyValueVector（２８００）およびm_LocateValueVector（２８０２）の各要素がシステムによって使用され、キーおよび値情報が判定される。この例におけるウェブページの第１行については、m_LocateValueVector（２８０２）内の第１要素に対するm_bKeyFoundがfalseである場合、システムは、m_KeyValueVector（２８００）内の第１要素の文字列sKeyを第１行内で検索する。すなわち、システムは「Black」を第１行で検索することになる。システムが「Black」を第１行に見つけたかどうかにかかわらず、システムはm_KeyValueVector（２８００）およびm_LocateValueVector（２８０２）内の次の要素に進み、同じステップを次の要素について繰り返す。ベクタm_KeyValueVector（２８００）およびm_LocateValueVector（２８０２）内のすべての要素がチェックされ、構造体CKeyValueInfoのsKeyメンバが第１行に見つかるかどうかが判定される。
【０１３５】
図２８の例示的な概略図では、ウェブページ（２８０４）の第３行で初めて、m_KeyValueVector（２８００）の第１要素のsKey「Black」が見つかる。sKeyが見つかったので、m_LocateValueVector（２８０２）の第１要素のm_bKeyFoundがtrueにセットされる。次にシステムは、m_KeyValueVector（２８００）の第１要素のnPosition、sDelimiter、およびnInLinePositionを用いてsKeyに対応する値を取得しようと試みる。m_KeyValueVector（２８００）の第１要素に対して、nPositionは２である。これは、情報の値がsKey「Black」から２データ要素だけ離れていることを意味する。m_LocateValueVector（２８０２）の第１要素のm_nCounterは、遭遇するデータ要素の個数を追跡する。「Black」の後にはデータ要素がないので、m_nCounterは０のままとなる。ベクタの残りの２要素がチェックされ、キーが見つかるかどうかが調べられる。第４行で、m_LocateValueVector（２８０２）の第１要素のm_bKeyFoundがtrueであるので、データ要素がその行で検索される。データ要素が見つからないので、m_LocateValueVector（２８０２）の第１要素のm_nCounterは０のままとなる。再びベクタの残りの２要素がチェックされ、キーが見つかるかどうかが調べられる。
【０１３６】
図２８のウェブページ（２８０４）の第６行で初めて、次のデータ要素「&nbsp;」が見つかることに気づくであろう。m_LocateValueVector（２８０２）の第１要素のm_nCounterが１にインクリメントされる。m_KeyValueVector（２８００）の第１要素に対してnPositionは２であるので、情報の値には到達していない。再びベクタの残りの２要素がチェックされ、キーが見つかるかどうかが調べられる。ウェブページ（２８０４）の第７行で、次のデータ要素「100%」が見つかる。m_LocateValueVector（２８０２）の第１要素のm_nCounterが２にインクリメントされる。m_KeyValueVector（２８００）の第１要素に対してnPositionは２であるので、情報の値に到達した。m_KeyValueVector（２８００）の第１要素に対して、sDelimiterの値は「%」であり、nInLinePositionの値は０であるので、値は「%」の前の文字列に対応する。したがって、情報の値は１００である。情報の値が取得されたので、各ベクタ内の第１要素がベクタから除去され、残りは２要素のみとなる。ベクタの残りの２要素がチェックされ、キーが見つかるかどうかが調べられる。このプロセスは、情報に対するすべての値が見つかるまで、ウェブページ（２８０４）の各行について繰り返される。２つのベクタを使用することにより、ベクタが１つの要素を含むか複数の要素を含むかにかかわらず、すべての情報をウェブページの各行で検索することができる。
【０１３７】
図２９は、CHTTP_HTML（２０００）のgetVendorModelID()を実行するシーケンスダイヤグラムを示している。この関数はネットワークプリンタのベンダモデルＩＤを返す。この関数は、図１５に記載したCHTTP_HTML（２０００）のマップ構造体m_VendorModelMapの設定も行う。このマップ構造体は、ステータス情報が監視されるすべてのネットワークプリンタを含む。このマップ構造体は、アクセスされるネットワークプリンタのウェブページに関する情報と、そのウェブページから何を抽出すべきかに関する情報とを提供する。CHTTP_HTML（２０００）は、SupportInfoODBC（１１１４）パッケージのsetVendorModelID()を呼び出す。この関数は、ネットワークプリンタの特定のベンダおよびモデルに関連する情報のみにアクセスするために、SupportInfoODBC（１１１４）パッケージをセットアップする。CHTTP_HTML（２０００）は、SupportInfoODBC（１１１４）パッケージのgetWebPageInfo()を呼び出す。この関数は、ウェブページおよびCKeyValueInfoのベクタを返す。CKeyValueInfoは、ウェブページからステータス情報を抽出するために必要な情報を提供する。ウェブページおよびCKeyValueInfoのベクタは、マップ構造体m_VendorModelMapに入れられる。CHTTP_HTML（２０００）は、ネットワークプリンタの特定のベンダおよびモデルのウェブページからステータス情報を抽出するために使用されるすべての情報を取得する目的で、SupportInfoODBC（１１１４）パッケージのgetWebPageInfo()を、それがfalseを返すまで複数回呼び出す。
【０１３８】
図３０は、図１１に示したSupportInfoODBC（１１１４）パッケージのクラスダイヤグラムを示している。このパッケージは、データベースにアクセスして、システムによってサポートされるネットワークプリンタのベンダおよびモデルに関する情報を取得する。SupportInfoODBCパッケージは、ネットワークプリンタのウェブページから情報を取得するために使用される情報をデータベースから取得する。CSupportInfoODBC（３０００）クラスは、このパッケージのためのインタフェースであり、このパッケージ内の他のクラスを管理して以下のタスクを実行する。CVendorModelInfomationData（３００２）クラスは、ネットワークプリンタのベンダおよびモデルをそのウェブページの１つから判定するために使用される情報をデータベースから取得する。CVendorModelAndUniqueIDsData（３００４）クラスは、ネットワークプリンタの固有識別子をそのウェブページの１つから判定するために使用される情報をデータベースから取得する。CKeyValueData（３００６）クラスは、ネットワークプリンタのウェブページからステータス情報を取得するために使用される情報をデータベースから取得する。CVendorModelWebPageData（３００８）クラスは、どのウェブページがネットワークプリンタのベンダおよびモデルに関連しているかを判定する情報をデータベースから取得する。CVendorModelInfomationTable（３０１０）クラスは、ネットワークプリンタのベンダおよびモデルをそのウェブページの１つから判定するために使用される情報を含むサポートデータベース内のテーブル（VendorModelInfomationテーブル）へのインタフェースを提供する。CVendorModelAndUniqueIDsTable（３０１２）クラスは、ネットワークプリンタの固有識別子をそのウェブページの１つから判定するために使用される情報を含むサポートデータベース内のテーブル（VendorModelAndUniqueIDsテーブル）へのインタフェースを提供する。CKeyValueTable（３０１４）クラスは、ネットワークプリンタのウェブページからステータス情報を取得するために使用される情報を含むサポートデータベース内のテーブル（KeyValueテーブル）へのインタフェースを提供する。CVendorModelWebPageTable（３０１６）クラスは、どのウェブページがネットワークプリンタのベンダおよびモデルに関連しているかを判定する情報を含むサポートデータベース内のテーブル（VendorModelWebPageテーブル）へのインタフェースを提供する。CVendorModelInfomationTable（３０１０）、CVendorModelAndUniqueIDsTable（３０１２）、CKeyValueTable（３０１４）、およびCVendorModelWebPageTable（３０１６）はすべて、Microsoft  Foundation  Class（ＭＦＣ）ライブラリのCRecordset（３０１８）から派生したクラスである。
【０１３９】
図３１は、HTTP_HTML（１１１２）パッケージのgetVendorModelID()を実行するシーケンスダイヤグラムを示している。この関数呼出しのシーケンスは、図１４に記載したHTTP_HTML（１１１２）パッケージのテーブル構造体を設定する。このテーブル構造体は、ネットワークプリンタの特定のベンダおよびモデルに対するステータス情報を取得するために使用される。このシーケンスダイヤグラムにおける関数呼出しのシーケンスは、データベースに格納されている情報をシステム内の内部構造体に変更するために使用される。データベース内の情報は、システムが容易にデータを使用するようには編成されていないことがある。この理由は、データベースの要求はシステムの要求とは異なるからである。したがって、データベースのテーブルからの情報にアクセスし、システムが使用するのに便利な内部構造体にそのデータを格納することが好ましい。図３１のシーケンスダイヤグラムは、データベースから取得される情報を内部構造体に変更する方法である。
【０１４０】
図３１において、HTTP_HTML（１１１２）は、CSupportInfoODBC（３０００）のsetVendorModelID()を呼び出す。次に、CSupportInfoODBC（３０００）は、CVendorModelWebPageData（３００８）のsetVendorModelID()を呼び出す。この関数は、ネットワークプリンタのベンダおよびモデルに関連するすべてのウェブページをデータベースから取得する。HTTP_HTML（１１１２）は、CSupportInfoODBC（３０００）のgetWebPageInfo()を呼び出す。次に、CSupportInfoODBC（３０００）は、CVendorModelWebPageData（３００８）のgetWebPageAndID()を呼び出し、ネットワークプリンタのベンダおよびモデルに関連するウェブページを取得する。CSupportInfoODBC（３０００）は、CKeyValueData（３００６）のsetVendorModelWebID()を呼び出し、ネットワークプリンタの特定のウェブページから取得することができるすべてのステータス情報を含むデータベース内のテーブルにアクセスする。CSupportInfoODBC（３０００）は、CKeyValueData（３００６）のgetKeyValueInfo()を呼び出し、ネットワークプリンタのウェブページからステータス情報を取得するために使用される情報を取得する。CSupportInfoODBC（３０００）は、ネットワークプリンタのウェブページに関連するすべてのステータス情報を取得するために使用されるすべての情報を獲得するために、CKeyValueData（３００６）のgetKeyValueInfo()を複数回呼び出す。CSupportInfoODBC（３０００）のgetWebPageInfo()、CVendorModelWebPageData（３００８）のgetWebPageAndID()、ならびにCKeyValueData（３００６）のsetVendorModelWebID()およびgetKeyValueInfo()を呼び出すシーケンスは、getWebPageAndID()がfalseを返すまで繰り返される。この呼出しシーケンスは、サポートデータベースの２つのテーブル（KeyValueテーブルおよびVendorModelWebPageテーブル）から取得される情報を、特定のベンダおよびモデルのネットワークプリンタのウェブページからすべてのステータス情報を取得するために使用される内部テーブル構造体に格納することができる情報に変更する。
【０１４１】
図３２は、CSupportInfoODBCのsetVendorModelID()を実行するフローチャートを示している。setVendorModelID()は、ネットワークプリンタの特定のベンダおよびモデルに関連するすべてのウェブページならびにそれに対応するベンダモデルＩＤをサポートデータベースのテーブルVendorModelWebPageから取得して、それをベクタに入れる。ステップ３２０２で、ベンダモデルＩＤの範囲に対応するフィルタが指定される。ベンダモデルＩＤの範囲は、ネットワークプリンタの特定のベンダおよびモデルに関連するウェブページに対応する。フィルタをセットすることにより、データベース内のテーブルは、好ましくは、それがオープンされる時にフィルタを満足するテーブル内のエントリを含む。したがって、フィルタのベンダモデルＩＤの範囲内にあるベンダモデルＩＤを有するすべてのエントリがテーブルに含まれることになる。ステップ３２０４で、サポートデータベースのテーブルがオープンされる。ステップ３２０６で、システムは、データベースのテーブルの最後に到達したかどうかをチェックする。テーブルの最後に到達していない場合、ステップ３２０８で、ベンダモデルＩＤおよび対応するウェブページがペア構造体に入れられ、そのペア構造体がベクタに入れられる。テーブルの最後に到達した場合、システムは、下記のステップ３２１２に記載されるタスクを実行する。ステップ３２１０で、システムは、データベースのテーブル内の次のエントリに移動した後、反復のためにステップ３２０６に回される。
【０１４２】
ステップ３２１２で、ベンダモデルＩＤおよびウェブページのペアを含むベクタに対する反復子がベクタの最初にセットされる。ステップ３２１４で、データベースのテーブルがクローズされ、ステップ３２１６で、setVendorModelID()の実行が完了する。ベクタは、図３３に記載するCSupportInfoODBCのgetWebPageInfo()で使用される。
【０１４３】
図３３は、CSupportInfoODBCのgetWebPageInfo()を実行するフローチャートを示している。この関数は、ネットワークプリンタの所与のベンダおよびモデルのウェブページと、そのウェブページから取得することができるステータス情報とを返す。ステップ３３０２で、ネットワークプリンタの特定のベンダおよびモデルに対するウェブページおよびベンダモデルＩＤが、図３２に記載したベクタから取得される。ステップ３３０４で、システムは、ネットワークプリンタに対してまだ他にウェブページおよびベンダモデルＩＤがあるかどうかを判定する。ウェブページまたはベンダモデルＩＤがもはや残っていない場合、ステップ３３２０で、CSupportInfoODBCのgetWebPageInfo()の実行が完了する。しかし、まだ他にウェブページまたはベンダモデルＩＤが存在する場合、ステップ３３０６で、サポートデータベースのテーブルKeyValueが、ネットワークプリンタのベンダモデルＩＤをフィルタとして用いてオープンされる。フィルタは、データベースのテーブルがオープンされる時に同じベンダモデルＩＤを有するテーブル内のエントリのみがテーブルに存在するように、ベンダモデルＩＤにセットされる。ステップ３３０８は、テーブルが空であるかどうかを判定するためのチェックを行う。空である場合、ステップ３３０２が続いて実行される。しかし、テーブルが空でない場合、ステップ３３１０が実行される。
【０１４４】
図３３のステップ３３１０で、ネットワークプリンタのウェブページから抽出される必要があるステータス情報に関する情報が、サポートデータベースのテーブルVendorModelWebPageから取得される。ステップ３３１２で、その情報はベクタに入れられ、ステップ３３１４で、システムはデータベースのテーブル内の次のエントリに移動する。ステップ３３１６で、システムは、データベースのテーブルの最後にいるかどうかを判定する。最後でない場合、システムはステップ３３１０を実行する。しかし、データベースのテーブルの最後に到達した場合、ステップ３３１８で、データベースのテーブルがクローズされ、ステップ３３２０で、CSupportInfoODBCのgetWebPageInfo()が完了する。
【０１４５】
本発明は、特定のプライベート管理情報ベース（ＭＩＢ）情報を有することさえなしに、マルチベンダ環境における種々のデバイスの監視を可能にし、さらに、ユーザが理解しやすい、またはユーザが利用しやすい方法で、詳細な情報を取り出し表示することを容易にする。また、格納される監視される情報は、参照により本明細書に援用される同時係属出願に記載されているように、ＦＴＰまたは電子メールを通じて送出することも可能である。
【０１４６】
本発明は、ネットワークに接続された、監視を必要とする数個のデバイスを含むように示されているが、理解されるように、本発明の精神および範囲から逸脱することなく、数個より多くのデバイスがネットワークに接続されてもよい。また、本発明は、種々のデバイスが監視および制御されることを必要とするようなホーム環境に適用されてもよい。
【０１４７】
本発明は、特定のプライベート管理情報ベース（ＭＩＢ）情報を有することさえなしに、マルチベンダ環境における種々のデバイスの監視を可能にし、さらに、ユーザが理解しやすい、またはユーザが利用しやすい方法で、詳細な情報を取り出し表示することを容易にする。
【０１４８】
コンピュータ技術の当業者には明らかなように、本発明のコントローラは、本明細書の教示に従ってプログラムされた従来の汎用ディジタルコンピュータまたはマイクロプロセッサを用いて都合よく実施されてもよい。ソフトウェア技術の当業者には明らかなように、適当なソフトウェアコーディングが、本明細書の教示に基づいて、通常の技術を有するプログラマによって容易に作成されることが可能である。当業者には容易に明らかなように、本発明は、特定用途向け集積回路の作成によって、または従来のコンポーネント回路の適当なネットワークを相互接続することによって実施されてもよい。
【０１４９】
本発明は、本発明のプロセスを実行するようにコンピュータをプログラムするために使用可能な命令を含む記憶媒体であるコンピュータプログラム製品を含む。記憶媒体としては、以下のものには限定されないが、フロッピーディスク、光ディスク、ＣＤ−ＲＯＭ、および光磁気ディスクを含むいかなるタイプのディスク、ＲＯＭ、ＲＡＭ、ＥＰＲＯＭ、ＥＥＰＲＯＭ、磁気もしくは光カード、または電子的命令を格納するのに好適ないかなるタイプの媒体もあり得る。
【０１５０】
明らかに、上記の教示に照らして、本発明の数多くの変更および変形が可能である。したがって、添付の特許請求の範囲の記載の範囲内で、本発明は本明細書に具体的に記載された以外の形で実施されてもよいと理解すべきである。
【図面の簡単な説明】
【０１５１】
【図１】インターネットを通じてコンピュータおよびデータベースのネットワークに接続された、３つのネットワーク接続された事務用デバイスを示す図である。
【図２】ディジタル画像形成装置のコンポーネントを示す図である。
【図３】図２に示されるディジタル画像形成装置の電子コンポーネントを示す図である。
【図４】図３に示されるマルチポート通信インタフェースの詳細を示す図である。
【図５】事務用デバイスが、ネットワークに直接接続されるか、またはネットワークに接続されたコンピュータに接続される、代替システム構成を示す図である。
【図６Ａ】電子メールを用いたアプリケーションユニットとの間の情報の流れを示すブロック図である。
【図６Ｂ】アプリケーションユニットに接続されたコンピュータがメッセージ転送エージェント（ＭＴＡ）としても働く、電子メールを用いた通信の代替方法を示す図である。
【図６Ｃ】アプリケーションユニットが、電子メールを交換するメッセージ転送エージェントを含む、電子メールを用いた通信の代替方法を示す図である。
【図６Ｄ】メールサーバが機器／デバイスのメールを受信するＰＯＰ３サーバとして、および機器／デバイスのメールを送信するＳｉｍｐｌｅ  Ｍａｉｌ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ（ＳＭＴＰ）サーバとして作用する、電子メールを用いた通信の代替方法を示す図である。
【図７】インターネットを越えてメッセージを送信する代替方法を示す図である。
【図８】機器／デバイスに接続され電子メールメッセージを通信するために使用され得る例示的なコンピュータを示す図である。
【図９Ａ】本発明の一例示的な実施形態によるシステム全体の概略図である。
【図９Ｂ】本発明の一例示的な実施形態による被監視デバイスの例示的なウェブページインタフェースを示す図である。
【図１０】本発明の一例示的な実施形態によるデータの監視に使用されるモジュールおよびそのインタフェース関数を示す図である。
【図１１】Monitorモジュール内の詳細およびサブモジュール間のその呼出し関数を示す図である。
【図１２】本発明の図１１に示されるHTTP_HTMLサブモジュールおよびSupportInfoODBCサブモジュールによって使用されるデータ構造体を示す図である。
【図１３】本発明の図１０に示されるMonitorモジュール１００６のinit関数のシーケンスを示す図である。
【図１４】本発明の図１１に示されるHTTP_HTMLサブモジュールによって使用される例示的なマップデータ構造体を示す図である。
【図１５】本発明の図１３に示されるDeviceFactoryによって作成されMonitorManagerによって使用されるデバイスへの参照のベクタを示す図である。
【図１６】図１０に示されるmonitorStatus関数のシーケンスを示す図である。
【図１７Ａ】ＨＴＴＰを通じて情報収集をサポートするデータベースに格納されたテーブル関係を示す図である。
【図１７Ｂ】ＨＴＴＰを通じて情報収集をサポートするデータベースに格納されたテーブル関係を示す図である。
【図１７Ｃ】ＨＴＴＰを通じて情報収集をサポートするデータベースに格納されたテーブル関係を示す図である。
【図１８】複数のプロトコルが複数の被監視デバイスから情報を収集するために使用される本発明のもう１つの実施形態を示す図である。
【図１９】被監視デバイスに関する情報を所望の当事者に電子メールで送信する概略図である。
【図２０】図１１に示されるHTTP_HTMLパッケージのクラスダイヤグラムである。
【図２１】図２０に示されるCHTTP_HTMLのinit()関数を実行するシーケンスダイヤグラムである。
【図２２】図２０に示されるクラスCHTTP_HTMLによって使用されるベクタを示す図である。
【図２３】ベンダ、モデル、ベンダモデルＩＤに関する情報、および被監視デバイスの固有識別子をそのウェブページから取得するために使用される情報を格納するために、図２０に示されるクラスCHTTP_HTMLによって使用されるマップを示す図である。
【図２４】図２０に示されるCHTTP_HTMLのinit()関数を実行するフローチャートである。
【図２５】図２０に示されるCHTTP_HTMLのgetStatus()関数を実行するシーケンスダイヤグラムである。
【図２６】被監視デバイスのウェブページから情報を取得するために図２０に示されるクラスCHTMLProcessorによって使用されるベクタを示す図である。
【図２７】図２０に示されるクラスCHTMLProcessorのsearchDataFromHTML()関数を実行するフローチャートである。
【図２８】２つのベクタm_KeyValueVectorおよびm_LocateValueVectorならびに被監視デバイスのウェブページからの行の例示的な概略図である。
【図２９】図２０に示されるCHTTP_HTMLのgetVendorModelID()関数を実行するシーケンスダイヤグラムである。
【図３０】図１１に示されるSupportInfoODBCパッケージのクラスダイヤグラムである。
【図３１】図２０に示されるHTTP_HTMLパッケージのgetVendorModelID()関数を実行するシーケンスダイヤグラムである。
【図３２】図３１に示されるCSupportInfoODBCのsetVendorModelID()を実行するフローチャートである。
【図３３】図３１に示されるCSupportInfoODBCのgetWebPageInfo()を実行するフローチャートである。
【符号の説明】
【０１５２】
１０    広域ネットワーク
１６、５２  ネットワーク
17、18、20、22、42、56、62、68、74    ワークステーション（ＷＳ）
２４    画像形成装置
２８    ファクシミリ装置
３２    プリンタ
46、54、58、64、70、76    ディスク
５0Ａ、50Ｂ、50Ｃ    ファイアウォール
【図１】
2004213654.tif 000008
【図２】
2004213654.tif 000009
【図３】
2004213654.tif 000010
【図４】
2004213654.tif 000011
【図５】
2004213654.tif 000012
【図６Ａ】
2004213654.tif 000013
【図６Ｂ】
2004213654.tif 000014
【図６Ｃ】
2004213654.tif 000015
【図６Ｄ】
2004213654.tif 000016
【図７】
2004213654.tif 000017
【図８】
2004213654.tif 000018
【図９Ａ】
2004213654.tif 000019
【図９Ｂ】
2004213654.tif 000020
【図１０】
2004213654.tif 000021
【図１１】
2004213654.tif 000022
【図１２】
2004213654.tif 000023
【図１３】
2004213654.tif 000024
【図１４】
2004213654.tif 000025
【図１５】
2004213654.tif 000026
【図１６】
2004213654.tif 000027
【図１７Ａ】
2004213654.tif 000028
【図１７Ｂ】
2004213654.tif 000029
【図１７Ｃ】
2004213654.tif 000030
【図１８】
2004213654.tif 000031
【図１９】
2004213654.tif 000032
【図２０】
2004213654.tif 000033
【図２１】
2004213654.tif 000034
【図２２】
2004213654.tif 000035
【図２３】
2004213654.tif 000036
【図２４】
2004213654.tif 000037
【図２５】
2004213654.tif 000038
【図２６】
2004213654.tif 000039
【図２７】
2004213654.tif 000040
【図２８】
2004213654.tif 000041
【図２９】
2004213654.tif 000042
【図３０】
2004213654.tif 000043
【図３１】
2004213654.tif 000044
【図３２】
2004213654.tif 000045
【図３３】
2004213654.tif 000046