(57)【特許請求の範囲】
【請求項１】
制御デバイスと、該制御デバイスによりモニタされるハードウェアデバイス（以下、インタフェースデバイス）とがネットワークに接続されたコンピュータシステムにおいて、前記制御デバイスがインタフェースデバイスの通信プロトコルを確立する方法であって、
前記制御デバイスは、
前記インタフェースデバイスのロケーションを認識するステップと、
インタフェースデバイスの各種情報を格納するデータベース内の、前記インタフェースデバイスのロケーションを前記認識したロケーションで更新するステップと、
前記インタフェースデバイスの製造元のアイデンティティについて前記インタフェースデバイスに問い合わせるステップと、
前記インタフェースデバイスの製造元のアイデンティティについての前記インタフェースへの前記問い合わせが成功した場合、前記データベース内の、前記インタフェースデバイスの製造元のアイデンティティを前記インタフェースデバイスから取得したアイデンティティで更新するステップと、
前記インタフェースデバイスの製造元のアイデンティティについての前記インタフェースデバイスへの前記問い合わせが成功した場合、前記インタフェースデバイスのモデルのアイデンティティについて、前記インタフェースデバイスの前記製造元の前記アイデンティティを利用して前記インタフェースデバイスに問い合わせるステップと、
前記インタフェースデバイスのモデルのアイデンティティについての前記インタフェースデバイスへの前記問い合わせが成功した場合、前記データベース内の、前記インタフェースデバイスのモデルのアイデンティティを前記インタフェースデバイスから取得したアイデンティティで更新するステップと、
前記データベースに格納された情報に基づいて前記インタフェースデバイスの通信プトロコルを確立するステップと、
を実行することを特徴とするインタフェースデバイスの通信プロトコル確立方法。
【請求項２】
前記インタフェースデバイスの製造元のアイデンティティについての前記インタフェースデバイスへの前記問い合わせが成功し、かつ、前記インタフェースデバイスのモデルのアイデンティティについての前記インタフェースデバイスへの前記問い合わせが成功しない場合、通信プロトコルを確立する前記ステップは、前記インタフェースデバイスの前記製造元に特定のプロトコルに従って前記インタフェースデバイスの通信プロトコルを確立することを特徴とする請求項１に記載のインタフェースデバイスの通信プロトコル確立方法。
【請求項３】
前記インタフェースデバイスの製造元のアイデンティティについての前記インタフェースデバイスへの前記問い合わせが成功せず、かつ、前記インタフェースデバイスのモデルのアイデンティティについての前記インタフェースデバイスへの前記問い合わせが成功しない場合、通信プロトコルを確立する前記ステップは、全デバイスに共通のプロトコルに従って前記インタフェースデバイスの通信プロトコルを確立することを特徴とする請求項１に記載のインタフェースデバイスの通信プロトコル確立方法。
【請求項４】
前記インタフェースデバイスの製造元のアイデンティティについての前記インタフェースデバイスへの前記問い合わせが成功せず、かつ、前記インタフェースデバイスのモデルのアイデンティティについての前記インタフェースデバイスへの前記問い合わせが成功しない場合、通信プロトコルを確立する前記ステップは、少なくとも１つのインタフェースデバイス製造元に共通のプロトコルに従って前記インタフェースデバイスの通信プロトコルを確立することを特徴とする請求項１に記載のインタフェースデバイスの通信プロトコル確立方法。
【請求項５】
前記インタフェースデバイスの製造元のアイデンティティについての前記インタフェースデバイスへの前記問い合わせが成功せず、かつ、前記インタフェースデバイスのモデルのアイデンティティについての前記インタフェースデバイスへの前記問い合わせが成功しない場合、通信プロトコルを確立する前記ステップは、前記インタフェースデバイスの識別された製造元のうち少なくとも１つの既知のモデルに共通のプロトコルに従って前記インタフェースデバイスの通信プロトコルを確立することを特徴とする請求項１に記載のインタフェースデバイスの通信プロトコル確立方法。
【請求項６】
前記インタフェースデバイスのモデルのアイデンティティについて前記インタフェースデバイスに問い合わせる前記ステップは、前記インタフェースデバイスの前記製造元の前記アイデンティティを利用し、前記インタフェースデバイスの前記製造元に特定のモデル識別コードを用いて前記インタフェースデバイスに問い合わせることを特徴とする請求項１に記載のインタフェースデバイスの通信プロトコル確立方法。
【請求項７】
前記制御デバイスは、
前記インタフェースデバイスの製造元のアイデンティティについて前記インタフェースデバイスに問い合わせる前記ステップの前に、前記インタフェースデバイスの固有のＩＤについて前記インタフェースデバイスに問い合わせるステップを実行することを特徴とする請求項１に記載のインタフェースデバイスの通信プロトコル確立方法。
【請求項８】
前記インタフェースデバイスの前記固有のＩＤは、前記インタフェースデバイスの製造元によって前記インタフェースデバイスに指定された固有のデータシーケンスであることを特徴とする請求項７に記載のインタフェースデバイスの通信プロトコル確立方法。
【請求項９】
前記データベース内の前記インタフェースデバイスのロケーションを更新する前記ステップは、前記データベース内の前記インタフェースデバイスの前記固有のＩＤを更新することを含むことを特徴とする請求項７に記載のインタフェースデバイスの通信プロトコル確立方法。
【請求項１０】
前記制御デバイスは、簡易ネットワーク管理プロトコル（ＳＮＭＰ）を用いて前記インタフェースデバイスに前記問い合わせを行うことを特徴とする請求項１に記載のインタフェースデバイスの通信プロトコル確立方法。
【請求項１１】
前記インタフェースデバイスのロケーションを認識する前記ステップは、前記インタフェースデバイスが前記制御デバイスと電気接続されていることを自動検出することによって達成されることを特徴とする請求項１に記載のインタフェースデバイスの通信プロトコル確立方法。
【請求項１２】
前記インタフェースデバイスのロケーションを認識する前記ステップは、ユーザの入力によって達成されることを特徴とする請求項１に記載のインタフェースデバイスの通信プロトコル確立方法。
【請求項１３】
前記制御デバイスおよび前記インタフェースデバイスは、ネットワークによって互いに接続されるネットワーク化されたコンピュータデバイスであることを特徴とする請求項１に記載のインタフェースデバイスの通信プロトコル確立方法。
【請求項１４】
前記インタフェースデバイスのロケーションを認識する前記ステップは、前記インタフェースデバイスのネットワークロケーションが変更したことを検出することによって達成されることを特徴とする請求項１３に記載のインタフェースデバイスの通信プロトコル確立方法。
【請求項１５】
前記インタフェースデバイスのロケーションは、前記ネットワーク上の前記インタフェースデバイスのネットワークロケーションであることを特徴とする請求項１３に記載のインタフェースデバイスの通信プロトコル確立方法。
【請求項１６】
前記インタフェースデバイスのネットワークロケーションは、インターネットアドレスであることを特徴とする請求項１５に記載のインタフェースデバイスの通信プロトコル確立方法。
【請求項１７】
前記データベースは、データベースファイル形式に依存しないインタフェースによってアクセスされ得ることを特徴とする請求項１に記載のインタフェースデバイスの通信プロトコル確立方法。
【請求項１８】
前記データベースは、ＯＤＢＣ（Open  Database  Connectivity）規格に対応していることを特徴とする請求項１７に記載のインタフェースデバイスの通信プロトコル確立方法。
【請求項１９】
前記データベースの少なくとも一部は、第２のデータベースに重複していることを特徴とする請求項１に記載のインタフェースデバイスの通信プロトコル確立方法。
【請求項２０】
前記第２のデータベースは、前記制御デバイスからの電子メールによるデータ転送を利用して、前記データベースの少なくとも一部とともに更新されることを特徴とする請求項１９に記載のインタフェースデバイスの通信プロトコル確立方法。
【請求項２１】
電子メールによる前記データ転送は、簡易メール転送通信プロトコル（ＳＭＴＰ）を利用することを特徴とする請求項２０に記載のインタフェースデバイスの通信プロトコル確立方法。
【請求項２２】
ネットワークに接続されるハードウェアデバイス（以下、インタフェースデバイス）をモニタし、該インタフェースデバイスの通信プロトコルを確立する制御デバイスであって、
インタフェースデバイスの各種情報を格納するデータベースと、
前記インタフェースデバイスのロケーションを認識する手段と、
前記データベース内の、前記インタフェースデバイスのロケーションを前記認識したロケーションで更新する手段と、
前記インタフェースデバイスの製造元のアイデンティティについて前記インタフェースデバイスに問い合わせる手段と、
前記インタフェースデバイスの製造元のアイデンティティについての前記インタフェースデバイスへの前記問い合わせが成功した場合、前記データベース内の、前記インタフェースデバイスの製造元のアイデンティティを前記インタフェースデバイスから取得したアイデンティティで更新する手段と、
前記インタフェースデバイスの製造元のアイデンティティについての前記インタフェースデバイスへの前記問い合わせが成功した場合、前記インタフェースデバイスの前記製造元の前記アイデンティティを利用して、前記インタフェースデバイスのモデルのアイデンティティについて前記インタフェースデバイスに問い合わせる手段と、
前記インタフェースデバイスのモデルのアイデンティティについての前記インタフェースデバイスへの前記問い合わせが成功した場合、前記データベース内の、前記インタフェースデバイスのモデルのアイデンティティを前記インタフェースデバイスから取得したアイデンティティで更新する手段と、
前記データベースに格納された情報に基づいて、前記インタフェースデバイスの通信プロトコルを確立する手段と、
を備えることを特徴とする制御デバイス。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、コンピュータシステム上のハードウェアのモニタ（monitoring）、コンフィギュレーション（configuration）、またはインストレーション（installation）に係り、詳しくは、インタフェースデバイスの通信プロトコルを確立する方法及びその制御デバイスに関する。
なお、本出願は、２００１年１月９日に出願された「Method  and  System  of  Remote  Support  of  Device  Using  Email」という名称の同時係属中の米国特許出願第０９／７５６，１２０号に関連する（参照により本明細書に援用される）。
【０００２】
【従来の技術】
一般に、コンピュータシステムはハードウェアおよびソフトウェアを含む。ハードウェアは実際の物理的な計算機であるが、ソフトウェアはハードウェアを動作させるための命令のリストである。通常、コンピュータシステムは、互いにインタフェースする様々なハードウェアデバイスを含む。ハードウェアデバイスが互いにインタフェースする場合、ハードウェアを動作させるソフトウェアは、ハードウェアデバイス間の通信を可能にするようにハードウェアがコンフィギュレーションされ、それによって、ハードウェアデバイスが協調動作（operate  cooperatively）できるようにする必要がある。また、ハードウェアデバイスがモニタされることも望ましい。ここでは、コンフィギュレーションしているまたはモニタしているハードウェアデバイスを制御デバイス（controlling  device）と呼ぶことにする。同様に、協調動作するようにコンフィギュレーションされているか、または制御デバイスによりモニタされているハードウェアデバイスを、インタフェースデバイス（interfacing  device）と呼ぶことにする。また、通信プロトコルを通信手段と呼ぶことにする。
【０００３】
ハードウェアデバイスが初めて互いにインタフェースする場合、ハードウェアデバイスを動作させるソフトウェアは、協調動作を可能にするようにコンフィギュレーションされていないのが普通である。したがって、コンピュータハードウェアデバイスをともにインストールする際に重要な部分は、ソフトウェアのコンフィギュレーションである。ある構成では、ユーザは、コンピュータハードウェアを開き、ジャンパまたはディップスイッチを物理的に設定することによって、コンピュータハードウェアを手動でコンフィギュレーションする必要がある。またある構成では、インストレーションプロセスは、ユーザがフロッピーディスクからソフトウェアをロードして、ハードウェアデバイスをコンフィギュレーションすることを含む。ハードウェアデバイスを自動的にコンフィギュレーションできるソフトウェアデバイスをコンピュータハードウェアに備えさせる試みもなされてきた。しかしながら、これらの試みにはいくつかの明らかな欠点および欠陥がある。
【０００４】
欠点のひとつは、自動ハードウェアインストレーションソフトウェアは、そのソフトウェアに特別にプログラムされていない新たなデバイスまたは新たな製造元に適合する能力が限られていることである。従来技術では、制御デバイスがインタフェースデバイスの特定モデルを認識しない場合、自動コンフィギュレーションは不可能である。換言すれば、従来技術では、制御デバイスがあるインタフェースデバイスのモデルを予測するようにプログラムされていない場合、自動ハードウェアコンフィギュレーションは成功しないであろう。このような状況では、ユーザは、コンフィギュレーション通信手段を手動でハードウェアデバイスにインストールする必要がある。
【０００５】
従来技術の別の欠点は、インタフェースデバイスの特定のモデルが識別できない場合、制御デバイスが部分的にハードウェアデバイスをコンフィギュレーションすることが不可能なことである。換言すれば、制御デバイスが、あるインタフェースデバイスの特定モデルを識別できない場合、インタフェースデバイスが協調動作するようにコンフィギュレーションされることはない。この結果、動作不能で実質的に役に立たないコンフィギュレーションされていないインタフェースデバイスとなる。
【０００６】
ネットワーク上に設置されるハードウェアデバイスの場合、これらハードウェアデバイスは、保守、使用、または他の目的のために監視されることが望ましい。しかしながら、製造元とインタフェースデバイスのモデルとの間で異なる通信手段が与えられた場合、ネットワーク上で制御デバイスが様々なインタフェースデバイスと通信することは困難である。この欠点は、ネットワークの管理者がネットワーク上のインタフェースデバイスの性能および効率についての重要な情報を得ることができないため、問題になっている。
［発明の概要］
【０００７】
【発明が解決しようとする課題】
したがって、本発明の目的は、上記の従来技術の欠点を克服する方法および装置を提供することである。詳しくは本発明は、制御デバイスがインタフェースデバイスと協調動作できるように、インタフェースデバイスの通信手段（通信プロトコル）を確立する方法及びその制御デバイスを提供することを目的とする。
【０００８】
【課題を解決するための手段】
一般的には、制御デバイスは、インタフェースデバイスと通信するコンピュータハードウェアデバイスである。インタフェースデバイスはまた、プリンタ、スキャナ、デジタルコピー機、スタンプマシン（stamp  machine：押印装置）などのオフィスデバイス、または家庭電化製品である。制御デバイスは、インタフェースデバイスの製造元のアイデンティティについてインタフェースデバイスに問い合わせる。インタフェースデバイスの製造元のアイデンティティが確定すると、それに基づいて、制御デバイスは、インタフェースデバイスのモデルのアイデンティティについてインタフェースデバイスに問い合わせる。問い合わせによりインタフェースデバイスから得た情報に基づいて、制御デバイスは、ソフトウェアファクトリを通じてソフトウェアオブジェクトを作成することにより、インタフェースデバイスとの通信手段を確立する。
【０００９】
この方法は、ハードウェアデバイスとインタフェースデバイスとの間の通信手段を確立する階層的アプローチである。本発明の一実施形態によると、いったんインタフェースデバイスの製造元が制御デバイスにより確定されると、制御デバイスは、インタフェースデバイスの識別された製造元に特定の通信手段を用いてインタフェースデバイスのモデルを確定することができるため、この階層的アプローチは有利である。換言すれば、いったん制御デバイスがインタフェースデバイスの製造元を確定すると、インタフェースデバイスのモデルを確定するために特定の製造元の知識を利用することができる。
【００１０】
この階層的アプローチの１つの利点は、このアプローチが、制御デバイスとインタフェースデバイスとの間で最も有効な通信手段を確立する効果的なメカニズムであることである。このことは、いったん制御デバイスがインタフェースデバイスの製造元を識別すると、制御デバイスがインタフェースデバイスのモデル特定の通信手段を確定することが可能なため、極めて明白である。換言すれば、いったんインタフェースデバイスの製造元が識別されると、制御デバイスは、インタフェースデバイスについて、インタフェースデバイスのモデルを解読するのに十分な情報を有する。この利点は、制御デバイスがインタフェースデバイスの実際のモデルを確定する方法についてある汎用性を提供するため、重要である。
【００１１】
ある場合では、インタフェースデバイスのモデルは、インタフェースデバイスへの問い合わせから容易に識別することができ、問い合わせから得たそのような情報を用いて、制御デバイスはインタフェースデバイスの識別されたモデルに特定の通信手段に従って通信手段を確立することができる。
【００１２】
場合によっては、制御デバイスは、インタフェースデバイスへの問い合わせによるインタフェースデバイスのモデルの識別が不可能なことがある。そのような場合、本発明の制御デバイスは、有効な通信手段を確立するために代替的手段を採用することができる。そのような手段の１つは、インタフェースデバイスの製造元と電子的に通信し、最新のソフトウェア通信手段およびモデル識別コードをダウンロードすることである。そのような構成では、最新の製造元情報を有する制御デバイスの、特定モデルについてのインタフェースデバイスへの再問い合わせは成功し得る。
【００１３】
他の場合では、制御デバイスは、インタフェースデバイスの製造元と電子的に通信することが不可能なことがある。しかしながらこれらの場合、制御デバイスは、そのインタフェースデバイスの製造元からの他のモデルの通信手段の使用を試みることによって、インタフェースデバイスの通信手段を解読することが可能であり得る。これは試行錯誤プロセスであり、インタフェースデバイスの最大のコンフィギュレーション性（configurability）を侵すことになり得るが、インタフェースデバイスは動作可能または監視可能と見なされる。
【００１４】
これらの構成全てにおいて、インタフェースデバイスの製造元は既知でなければならない。このことは、インタフェースデバイスの製造元およびモデルが非常に多く、製造元などの、インタフェースデバイスについての何らかの付加的情報なしに、インタフェースデバイスの通信手段を解読することは不可能であり実用的でもないため、明らかなことである。
【００１５】
本発明の別の利点は、インタフェースデバイスが用いる通信手段に適合する制御デバイスの機能である。インタフェースデバイスの製造元またはモデルのいずれかが確定不可能であるような場合、制御デバイスは、全てのデバイスに共通の通信手段を用いることが可能であり得る。あるいは、製造元は識別可能だがモデルが識別不可能である場合、制御デバイスは、識別された製造元の全デバイスに特定の通信手段を利用することができる。あるいは、ハードウェアデバイスは基本的な共通機構を有しており、そのタイプのハードウェアデバイス全てがその機構を有しており、かつ全てが同じ通信手段を利用することはよく知られている。したがって、本発明の一実施形態によると、本発明の制御デバイスは、標準的な通信手段を用いてそれら共通機構を利用することができる。これをさらに発展させると、ある特定の製造元の全デバイスは、その製造元に特定のいくつかの特殊機構を有し得る。これらの機構は全て、特定モデルに関係なく同じ通信手段を共有し得る。制御デバイスがインタフェースデバイスの製造元を識別可能である場合、制御デバイスは、インタフェースデバイスの具体的なモデルを識別しなくても通信を最大限に活用することができる。当然、ある特定のインタフェースデバイスのモデルが確定可能である場合、制御デバイスは、インタフェースデバイスのその特定モデルに関連する全通信手段を識別可能である。
【００１６】
したがって、制御デバイスが、通信手段を確立するためにインタフェースデバイスから得ることができる情報を利用することにより、インタフェースデバイスとの通信手段の有効性を最大限にすることができるため、本発明は従来技術よりも改良されている。
【００１７】
本発明はまた、自己学習型、すなわちスマートデバイスであるという利点を有する。制御デバイスがインタフェースデバイスと対話すると、制御デバイスは、ある特定の製造元または特定のクラスのインタフェースデバイスモデルの通信手段の特質を学習することができる。制御デバイスは、インタフェースデバイスをプロービングする試行錯誤プロセスにより、インタフェースデバイスからいくつかの通信手段を解読することが可能であり得る。この利点により、インタフェースデバイスの製造元またはモデルを容易に識別することができないときでも、インタフェースデバイスの確立された通信手段を最大限に活用することができる。
【００１８】
【発明の実施の形態】
本発明の一実施形態では、制御デバイスがインタフェースデバイスの通信手段を確立する方法は、インタフェースデバイスのロケーションを認識するステップ、データベースにおいてインタフェースデバイスのロケーションを更新するステップ、インタフェースデバイスの製造元のアイデンティティについてインタフェースデバイスに問い合わせるステップ、インタフェースデバイスの製造元についての問い合わせが成功した場合、データベースにおいてインタフェースデバイスの製造元を更新するステップ、インタフェースデバイスの製造元のアイデンティティについてのインタフェースデバイスへの問い合わせが成功した場合、インタフェースデバイスのモデルのアイデンティティについて、製造元のアイデンティティを利用してインタフェースデバイスに問い合わせるステップ、インタフェースデバイスのモデルのアイデンティティについての問い合わせが成功した場合、第１のデータベースにおいてインタフェースデバイスのモデルのアイデンティティを更新するステップ、データベースに格納された情報に従って、インタフェースデバイスの通信手段を確立するステップの各ステップを含む。
【００１９】
本発明の実施形態において、インタフェースデバイスの製造元のアイデンティティについてのインタフェースデバイスへの問い合わせが成功し、インタフェースデバイスのモデルのアイデンティティについてのインタフェースデバイスへの問い合わせが成功しない場合、インタフェースデバイスの通信手段を確立するステップは、そのインタフェースデバイスの製造元の全デバイスに特定のインタフェースプロトコルに従う。
【００２０】
本発明の実施形態において、インタフェースデバイスの製造元のアイデンティティについてのインタフェースデバイスへの問い合わせが成功せず、インタフェースデバイスのモデルのアイデンティティについてのインタフェースデバイスへの問い合わせも成功しない場合、インタフェースデバイスの通信手段を確立するステップは、全デバイスに共通のインタフェースプロトコルに従う。
【００２１】
本発明の実施形態において、インタフェースデバイスのモデルのアイデンティティについてインタフェースデバイスに問い合わせるステップは、インタフェースデバイスの製造元のアイデンティティを利用して、インタフェースデバイスの製造元に特定のモデル識別コードを用いてインタフェースデバイスに問い合わせる。
【００２２】
本発明の実施形態において、先の方法は、インタフェースデバイスの製造元のアイデンティティについてインタフェースデバイスに問い合わせるステップの前に、インタフェースデバイスの固有のＩＤ（identification）によりインタフェースデバイスに問い合わせるステップを更に含む。
【００２３】
本発明の実施形態において、インタフェースデバイスの固有のＩＤは、インタフェースデバイスの製造元によってインタフェースデバイスに指定された固有のデータシーケンスである。
【００２４】
本発明の実施形態において、データベースにおいてインタフェースデバイスのロケーションを更新するステップは、データベースにおいてインタフェースデバイスの固有のＩＤを更新することを含む。
【００２５】
本発明の実施形態において、インタフェースデバイスには、簡易ネットワーク管理プロトコル（Simple  Network  Management  Protocol；SNMP）を用いて問い合わせが行われる。
【００２６】
本発明の実施形態において、インタフェースデバイスのロケーションを認識するステップは、インタフェースデバイスが制御デバイスに電気的に接続されていることを自動的に検出することによって達成される。
【００２７】
本発明の実施形態において、インタフェースデバイスのロケーションを認識するステップは、ユーザの入力によって達成される。
【００２８】
本発明の実施形態において、制御デバイスとインタフェースデバイスは、ネットワークによって互いに接続されたネットワークコンピュータデバイスである。本発明の実施形態において、インタフェースデバイスのロケーションを認識するステップは、インタフェースデバイスのネットワークロケーションが変更されたことを制御デバイスが検出することによって達成される。本発明の実施形態において、インタフェースデバイスのロケーションは、ネットワーク上のインタフェースデバイスのネットワークロケーションである。本発明の実施形態において、インタフェースデバイスのネットワークロケーションは、インターネットアドレスである。
【００２９】
本発明の実施形態において、データベースは、データベースファイル形式に依存しないインタフェースによってアクセスすることができる。本発明の実施形態において、第１のデータベースはＯＤＢＣ（Open  Database  Connectivity）規格に対応している。
【００３０】
本発明の実施形態において、データベースの少なくとも一部は、第２のデータベースと重複している。
【００３１】
本発明の実施形態において、第２のデータベースは、電子メールによる転送を利用して、データベースの少なくとも一部で更新される。本発明の実施形態において、電子メールによる転送データは、簡易メール転送プロトコル（Simple  Mail  Transfer  Protocol；ＳＭＴＰ）を利用する。
【００３２】
削除
【００３３】
次に、図面を参照して本発明の好ましい実施形態を説明する。なお、図面において、同様の参照番号は同一または同様の部分を指している。
【００３４】
図１を参照すると、様々なハードウェアデバイスとコンピュータネットワークとの間の対話の例示的説明図が示されている。ワークステーション１０は例示的な制御デバイスであり、データベース２０にデータを格納するようにされている。カメラ１２は、ワークステーション１０に直接接続され、ワークステーション１０上に自動的にコンフィギュレーションされるか、またはワークステーション１０によってモニタされることが可能なインタフェースデバイスを示す。ワークステーション１０は、ローカルエリアネットワーク（ＬＡＮ）１８にも接続される。ＬＡＮ１８は、ＰＯＰ３サーバ１４、ＳＭＴＰサーバ１６、プリンタモデルＡ２２、およびゲートウェイサーバ２６に接続される。プリンタモデルＡ２２は、ネットワークプリンタであるインタフェースデバイスを示す。ＳＭＴＰサーバ１６は、ワークステーション１０などの、ＬＡＮ１８に接続されたワークステーションからメールを送信するために動作する簡易メール転送プロトコル（ＳＭＴＰ）サーバである。複数のワークステーションがＬＡＮ１８に接続可能であり、ワークステーション１０は例示的なワークステーションにすぎないことは、当業者には理解されよう。これら複数のワークステーションは制御デバイスでもあり得るか、またはこれら他のワークステーションは、ハードウェアデバイスの自動コンフィギュレーションまたは監視のためにワークステーション１０に依存し得る。ＰＯＰ３サーバ１４は、ＬＡＮ１８に接続されたワークステーション１０および他のワークステーション（図示せず）宛ての電子メールを受信するＰＯＰ（Post  Office  Protocol）サーバである。ゲートウェイサーバ２６は、ＬＡＮ１８がワイドエリアネットワーク（ＷＡＮ）２４内で通信することを可能にする。ＷＡＮ２４は、インターネットであるか、または別のタイプのワイドエリアネットワークであり得る。
【００３５】
ＬＡＮ３４、ゲートウェイサーバ２８、プリンタモデルＢ３０、ＳＭＴＰサーバ４２、ＰＯＰ３サーバ４０、ワークステーション３２、データベース３８、およびスキャナ３６は、それぞれＬＡＮ１８、ゲートウェイサーバ２６、プリンタモデルＡ２２、ＳＭＴＰサーバ１６、ＰＯＰ３サーバ１４、ワークステーション１０、データベース２０、およびカメラ１２とそれぞれ類似するものとして図示されている。これら類似のデバイスおよびローカルエリアネットワークは、２つのローカルエリアネットワーク１８および３４がワイドエリアネットワーク２４にどのように接続され得るかを示している。さらに、ＬＡＮ３４は、ＬＡＮ１８またはＬＡＮ３４のいずれかのインタフェースデバイスと協調動作するようにコンフィギュレーションされ得る複数のワークステーション（図示せず）を含む場合がある。
【００３６】
たとえば、プリンタモデルＡ２２を操作するようにワークステーション３２をコンフィギュレーションすることができ、ワークステーション１０がスキャナ３６とともにプリンタモデルＡ２２を操作するようにコンフィギュレーションされ得る。これは、ローカルエリアネットワーク（ＬＡＮ）１８とローカルエリアネットワーク（ＬＡＮ）３４との間での、ゲートウェイサーバ２６および２８によりイネーブルされるワイドエリアネットワーク（ＷＡＮ）２４を介した通信により可能になる。
【００３７】
スキャナ３６は、ワークステーション３２に直接接続されたインタフェースデバイスとして、カメラ１２に類似している。プリンタモデルＢ３０は、プリンタモデルＡ２２とは異なるモデルであるが、おそらく異なる製造元（製造業者）であるという点を除いては、プリンタモデルＡ２２に類似している。
【００３８】
データベース２０およびデータベース３８は、カメラ１２、プリンタモデルＡ２２、プリンタモデルＢ３０、およびスキャナ３６などの様々なインタフェースデバイスに関連する情報を格納する。ワークステーション１０および３２は、これらのインタフェースデバイスを備えた他のワークステーション（図示せず）間で通信するために、ＬＡＮ１８およびＬＡＮ３４を介してこれらのワークステーション（図示せず）と通信している。本発明の実施形態において、ワークステーション１０は、図１に示すインタフェースデバイス１２、２２、３０、および３６のすべての制御デバイスであり得る。本発明の他の実施形態において、ワークステーション１０およびワークステーション３２の両方が、ローカルエリアネットワーク（ＬＡＮ）３４において通信するようにされている制御デバイスであり得る。したがって、インタフェースデバイスに関連する情報を、インタフェースデバイスと通信するための通信手段の確立を可能にするためにデータベース３８に格納することができる。ネットワークは複雑であることが多いため、ネットワーク上には、ワークステーション１０やワークステーション３２などのいくつかの制御デバイスが存在することが必要である場合もある。また、このような制御デバイス１０、３２が、インタフェースデバイス１２、２２、３０、および３６の有用性を最大にするためにデータを交換することが最も効率的である。したがって、データベース２０上に格納されたデータは、ＳＭＴＰサーバ１６を介して、かつＬＡＮ１８、ゲートウェイサーバ２６、ＷＡＮ２４、ゲートウェイサーバ２８、およびＬＡＮ３４を経由してＰＯＰ３サーバ４０に電子メールメッセージを送信することにより、データベース３８上で定期的に更新することができる。次に、ワークステーション３２は、ワークステーション１０からＰＯＰ３サーバ４０を介して電子メールメッセージをダウンロードするようにされ得る。電子メールメッセージの内容は、データベース２０上に格納されてデータベース３８上にコピーされるコンフィギュレーションデータを含み得る。ワークステーション３２は、ワークステーション１０およびワークステーション３２に事前にプログラムされている電子メール交換の特定の通信手段に基づいて、電子メールメッセージを受信してデータベース３８を自動更新するようにされている。同様に、データベース２０は、ＳＭＴＰサーバ４２、ＬＡＮ３４、ゲートウェイサーバ２８、ＷＡＮ２４、ゲートウェイサーバ２６、ＬＡＮ１８、およびＰＯＰ３サーバ１４を利用して同一の方法で、データベース３８に格納されたデータから更新することができる。
【００３９】
図２は、様々なハードウェアデバイス間の通信手段による対話の例示的な説明図である。プリンタ５２、５４、６８、および８０は、制御デバイス４４に接続される例示的インタフェースデバイスである。これらのインタフェースデバイス５２、５４、６８、および８０は、ブロック５０、５８、７０、および７８で示される簡易ネットワーク管理プロトコル（ＳＮＭＰ）を介して通信する。ＳＮＭＰは、ネットワーク管理アプリケーションがデバイスに問い合わせをするために用いることができる一般的な通信手段である。ＳＮＭＰは、開放型システム間相互接続（ＯＳＩ）アプリケーション層において動作する。インターネットベースのＳＮＭＰは、ほとんどのネットワーク管理ソフトウェアの基準である。ＳＮＭＰはＩＰネットワーク管理プロトコル上のＵＤＰ（User  Datagram  Protocol）として設計され、事実上いかなるネットワークタイプも管理可能であり、ルータおよびブリッジとしてのＩＰ（インターネットプロトコル）を含むまでになっている。ＳＮＭＰは、ＩＰ環境において広く使用されている。ＳＮＭＰは、イーサネットならびにＯＳＩトランスポートに対して実施することができる。ＳＮＭＰはインターネット規格であり、インターネットプロトコルの上で動作する。インタフェースデバイスがＳＮＭＰを介して通信する必要がなく、類似の通信手段を用いて通信可能であることは、当業者には理解されよう。
【００４０】
インタフェースデバイスプリンタ５２は、ベンダ固有の通信手段５０を介して制御デバイス４４と通信する。インタフェースデバイスプリンタ５４は、ＳＮＭＰ５８およびＩＰ５６を介して制御デバイス４４と通信する。プリンタ５４はネットワークプリンタであり、それゆえ、制御デバイス４４と直接接続されていない。したがって、ＳＮＭＰはプリンタ５４に関してＩＰと重複している。インタフェースデバイスプリンタ８０は、ワイドエリアネットワーク（ＷＡＮ）７６に接続され、プリンタ５４と同様にＳＮＭＰ７８およびＩＰ５６を介して制御デバイス４４と通信する。プリンタ６８は、ワークステーション７２に直接接続され、ベンダ固有の通信手段７０を介してワークステーション７２と通信する。ワークステーション７２はＩＰ７４を介してＷＡＮ７６と通信し、次いでＩＰ５６を介して通信手段デバイスと通信する。ＳＮＭＰ５８、５０、７０、および７８は全て同一である。ＩＰ５６およびＴＣＰ／ＩＰ７４もまた同一である。
【００４１】
制御デバイス４４は、ＯＤＢＣ４８を介してデータベース４６と通信する。ＯＤＢＣは、様々なリレーショナルおよび非リレーショナルデータベースプログラムによって作成されたデータベースが共通のインタフェースによってアクセスされることを可能にする規格である。このようなリレーショナルおよび非リレーショナルデータベースプログラムには、Ｍicrosoft  Ａccess、Ｍicrosoft  ＦoxＰro、およびＯracleが含まれる。インタフェースは、インタフェースファイル形式とは無関係である。ＯＤＢＣに依存することによって、例えばＡccessファイルからレコードを読み出すために同じコードを使用するアプリケーションを書き込むことができる。
【００４２】
ＳＭＴＰサーバ６６は電子メールを送信するようにされており、簡易メッセージ転送プロトコル（ＳＭＴＰ）６４およびＩＰ５６を用いてローカルエリアネットワーク（図示せず）を介して制御デバイス４４に接続される。ＰＯＰ３サーバ６２は制御デバイス４４から電子メールを受信するようにされており、ＰＯＰ３プロトコル６０およびＩＰ５６を用いて制御デバイス４４と通信する。
【００４３】
図３は、種々のインタフェースデバイスモデルについて確立された通信手段の階層的関係を示す。ブロック８２は、全インタフェースデバイスに共通の確立された通信手段である。ブロック８４および８６は、２つの例示的製造元である製造業者（製造業者Ａおよび製造業者Ｂ）の通信手段を示す。ブロック８４は、製造業者Ａの全インタフェースデバイスに共通の確立された通信手段であり、ブロック８６は、製造業者Ｂの全インタフェースデバイスに共通の確立された通信手段である。ブロック８４および８６はブロック８２の一部である。ブロック８４の一部であるブロック８８および９０は、通信手段の異なる種々のインタフェースデバイスの通信手段で、ブロック８８はモデルＡに特定のインタフェースデバイス通信手段、ブロック９０はモデルＢに特定のインタフェースデバイスの通信手段である。ブロック８８および９０は、ブロック８２の一部であるブロック８４の一部である。ブロック９２および９４はブロック８８および９０と類似しているが、例示的製造業者Ｂに特定のものであり、ブロック９２はモデルＣに特定のインタフェースデバイスの通信手段、ブロック９４はモデルＤに特定のインタフェースデバイスの通信手段である。
【００４４】
この図３は、通信手段の階層を示している。概して、ブロック８２の全通信手段は、ブロック８２内のブロックとも共通している。しかしながら、ブロック８４、８８、９０、８６、９２、および９４の通信手段は、ブロック８２の通信手段と必ずしも完全な互換性を有しているとは限らない。
【００４５】
図４は、本発明の実施形態を示すフローチャートであり、制御デバイスの通信手段の階層的関係を利用して、インタフェースデバイスの通信手段を確立するフローチャートを示している。
【００４６】
ブロック９６は、制御デバイスがインタフェースデバイスのロケーションを認識することを示す。本発明の一実施形態において、インタフェースデバイスのロケーションの認識は、インタフェースデバイスが制御デバイスに電気接続されていることを自動検出することによって達成される。この自動検出は、ハードウェアデバイスまたはハードウェアコンポーネントの任意の接続であってもよい。この自動検出は、ハードウェアデバイスへの信号の全入出力を監視および追跡するソフトウェアプログラムを含むハードウェアデバイスによって達成されることが多い。したがって、新たなハードウェアデバイスまたはコンポーネントがそのようなハードウェアデバイスに接続されると、その存在が検出されることになる。
【００４７】
他の実施形態において、インタフェースデバイスのロケーションを認識するステップは、ユーザの入力によって達成される。このような実施形態では、ユーザは、新たなインタフェースデバイスが制御デバイスに接続されたことを示すデータを制御デバイスに入力することができる。このような入力は、実際はインタフェースデバイスをコンフィギュレーションさせるためのコマンドであり得るが、ユーザのデータ入力はインタフェースデバイスのロケーションを含んでいなければならない。インタフェースデバイスのロケーションは、ネットワーク上のインタフェースデバイスのネットワークロケーションか、またはおそらくインタフェースデバイスが接続されるハードウェアデバイス上のポートであり得る。
【００４８】
いくつかの実施形態において、インタフェースデバイスのロケーションは、ハードウェアデバイス上のポートまたはネットワークデバイスのネットワークロケーションの両方を含み得る。
【００４９】
他の実施形態において、インタフェースデバイスのロケーションを認識するステップは、インタフェースデバイスのネットワークロケーションが変更されたことを検出する制御デバイスによって達成される。これらの実施形態において、制御デバイスは、インタフェースデバイスを識別することが可能であり得るが、異なるロケーションにあるものに限る。この異なるロケーションはネットワークロケーション、ハードウェアデバイス上のデータポート、またはそれらの組み合わせのいずれかであり得る。
【００５０】
インタフェースデバイスのロケーションを認識する手段が多種多様のイベントを含み得ることは、当業者には理解されよう。これらイベントに共通の特徴は、制御デバイスがインタフェースデバイスの存在を認識することである。このロケーション認識は、自動コンフィギュレーションのプロセスを開始する、または制御デバイスに電気的に接続される新たなデバイスをモニタするという目的を果たし得るか、あるいはインタフェースデバイスの確立された通信手段を確認または更新するプロセスの開始であり得る。
【００５１】
ブロック９８は、制御デバイスがインタフェースデバイスの固有のＩＤについてインタフェースデバイスに問い合わせることを示す。固有のＩＤは連続番号、製造番号、ＭＡＣアドレスまたは他の規格コードであって、特定のインタフェースデバイスを識別するのに用いることができる、特定のインタフェースデバイスに固有のものであり得る。この情報は、インタフェースデバイスが参照および広くアクセスされるように、制御デバイスがインタフェースデバイスを識別し、そのアイデンティティを記録するために有用である。
【００５２】
ブロック１００は、データベース内のインタフェースデバイスのロケーションおよび固有のＩＤの更新を示す。この説明のために、データベースは秩序良く構造化および編成されたデータの集合として定義され、これにより当該情報に迅速にアクセスすることが可能になる。したがって、データベースは、簡単に参照できるようにアクセスおよび更新可能な揮発性または不揮発性メモリからなることができる。ブロック９６において一度インタフェースデバイスのロケーションが認識されると、データベースにおいて参照するためにその情報を更新することが重要である。さらに、インタフェースデバイスの固有のＩＤについての問い合わせの後、将来その情報を参照するために保存することが重要である。いくつかの実施形態において、インタフェースデバイスのロケーションおよび固有のＩＤはデータベースにおいて互いに関連付けられ、それにより、インタフェースデバイスがその固有のＩＤ、あるいはコンピュータまたはネットワーク上のそのロケーションによって参照され得る。同様に、本発明の実施形態において、インタフェースデバイスのＩＤは、そのロケーションからその固有のＩＤへ、またはその逆へ、変換され得る。
【００５３】
インタフェースデバイスのロケーションを有するデータベースを更新する手段は、そのインタフェースデバイスがどこに設置されているかを識別するために、任意のネットワークの記憶装置またはインタフェースデバイスの物理ロケーションを含むことは、当業者には理解されよう。さらに、データベースがデータを格納するようにされたいかなる種類のメモリを含んでもよいことは、当業者には理解されよう。
【００５４】
ブロック１０２において、インタフェースデバイスはインタフェースデバイスの製造元（製造業者）に関する問い合わせを受ける。インタフェースデバイスの製造元についてインタフェースデバイスに問い合わせる手段は、インタフェースデバイスの製造元情報にアクセスするいかなる通信手段をも含み得ることは、当業者には理解されよう。このような通信手段は、制御デバイスからインタフェースデバイスへ信号を送信し、インタフェースデバイスから受信した応答から製造元を確定することを含み得る。インタフェースデバイスへの問い合わせは、インタフェースデバイスから製造元を示す信号を受信することのみを含むこともできる。さらに、インタフェースデバイスへの問い合わせは、インタフェースデバイスから発せられたインタフェースデバイスの製造元を示す信号を解析することを含み得る。
【００５５】
ブロック１０４および１０６は、制御デバイスが製造元についての問い合わせに成功した場合、データベース内のインタフェースデバイスの製造元のアイデンティティを更新することを示す。データベースにおいてインタフェースデバイスの製造元を更新する手段は、インタフェースデバイスの製造元の参照として用いられ得る情報のいかなる格納にも関係することは、当業者には理解されよう。製造元のアイデンティティについての問い合わせが成功しない場合、制御デバイスはその情報でデータベースを更新することができない。したがって、製造元についての問い合わせが成功しない場合、プロセスはブロック１１４に進む。これについては後で説明する。
【００５６】
ブロック１０８において、インタフェースデバイスはインタフェースデバイスのモデルについての問い合わせを受ける。この問い合わせは、インタフェースデバイスの製造元のアイデンティティを用いる。さらに、ブロック１０８において実行されるステップは、ブロック１０４の製造元についての問い合わせが成功しなかった場合は実行されない。本発明の実施形態において、モデルについての問い合わせは、識別された製造元のインタフェースデバイスに特定の通信手段を用いることにより、インタフェースデバイスの識別された製造元を利用する。本発明の実施形態において、インタフェースデバイスのモデルについてのインタフェースデバイスへの問い合わせは、制御デバイスが特定の製造元との通信によって、その製造元のインタフェースデバイスの通信手段に関する知識を更新することを含む。このような通信は、ユーザまたは電子的な自動通信によってなされ、通信手段レコードを更新し得る。インタフェースデバイスのモデルのアイデンティティを得るために製造元デバイスのアイデンティティを用いた、インタフェースデバイスへの問い合わせの手段は、インタフェースデバイスのモデルの解読を助けるために製造元情報を利用するいかなるプロセスまたはメカニズムによっても達成され得ることは、当業者には理解されよう。
【００５７】
ブロック１１０および１１２において、モデルについての問い合わせが成功した場合、インタフェースデバイスのモデルのアイデンティティはデータベースにおいて更新される。インタフェースデバイスのモデルのアイデンティティでデータベースを更新する手段は、その後にインタフェースデバイスのモデルアイデンティティにアクセスするために参照することができるいかなる種類のデータ格納をも含むことは、当業者には理解されよう。
【００５８】
ブロック１１４は、制御デバイスが、データベースに格納された情報に基づいてインタフェースデバイスの通信手段（通信プロトコル）を確立することを示す。本発明の実施形態において、制御デバイスは、ネットワーク上の制御デバイスに接続された他のデバイスの代わりに働く。実施形態において、制御デバイスは、ハードウェアデバイスがインタフェースデバイスと協調的に対話することができるほど十分な情報を有すると、他のハードウェアデバイスがインタフェースデバイスと通信できるように、その情報および通信手段をそれらのハードウェアデバイスに伝達する。本発明の実施形態において、制御デバイスは、データベースに格納された情報に基づいて自らをコンフィギュレーションする。
【００５９】
データベースに格納された情報は、インタフェースデバイスの製造元またはインタフェースデバイスのモデル、インタフェースデバイスの製造元のみ、あるいはインタフェースデバイスのモデルおよび製造元両方に関して情報を含まない場合がある。制御デバイスがインタフェースデバイスに関するデータベースにアクセスして得られる情報量に基づいて、制御デバイスはインタフェースデバイスとの協調的対話のための通信手段を解読することができる。インタフェースデバイスについてどのような情報がわかっているかによって、少なくとも１つの他のハードウェアデバイスとともにインタフェースデバイスが動作することを可能にするインタフェースデバイスの通信手段が識別され得る。データベースに格納された情報に基づいて少なくとも１つのデバイスを制御してインタフェースデバイスとインタフェースする手段が、そのインタフェースデバイスの識別されたモデルまたは製造元とそのインタフェースデバイスに関連する通信手段との識別された関係を利用することは、当業者には理解されよう。
【００６０】
図５は、デバイスの通信手段の階層的関係を利用してインタフェースデバイスのためのデバイスをコンフィギュレーションする、本発明の一実施形態を示すフローチャートである。
【００６１】
ブロック１１６は、制御デバイスが、インタフェースデバイスの製造元およびモデル両方についてインタフェースデバイスに問い合わせることを示す。インタフェースデバイスの製造元のアイデンティティおよびモデルのアイデンティティについてインタフェースデバイスに問い合わせる手段は、インタフェースデバイスの製造元およびモデル両方の情報にアクセスするいかなる通信手段によっても達成され得ることは、当業者には理解されよう。このような通信手段は、制御デバイスからインタフェースデバイスへ信号を送信し、インタフェースデバイスから受信した応答から製造元を確定することを含み得る。インタフェースデバイスへの問い合わせは、インタフェースデバイスから製造元およびモデルを示す信号を受信することのみを含むこともできる。さらに、インタフェースデバイスへの問い合わせは、インタフェースデバイスから発せられた、インタフェースデバイスの製造元を示す信号を解析することを含み得る。
【００６２】
ブロック１１８において、制御デバイスは、インタフェースデバイスへの問い合わせによりインタフェースデバイスの製造元が識別されたかを判定する。製造元が識別された場合、プロセスはブロック１２０へ流れる。これについては後で説明する。インタフェースデバイスの製造元が識別されない場合、インタフェースデバイスの製造元もモデルもインタフェースデバイスへの問い合わせにより識別されていないと見なされ得る。インタフェースデバイスのモデルが識別されない場合、インタフェースデバイスの製造元もまた識別されないため、これは極めて明らかである。インタフェースデバイスの製造元は、例えば、ハードウェアに顧客サポートを提供する組織である。このような顧客サポートは、インタフェースデバイスについてソフトウェアドライバを配布することを必然的に含む。
【００６３】
ブロック１１６におけるインタフェースデバイスへの問い合わせがインタフェースデバイスの製造元またはモデルのいずれかを識別しない場合、プロセスはブロック１１８からブロック１２６へ流れる。ブロック１２６において、制御デバイスは、全インタフェースデバイスに共通の通信手段を用いてインタフェースデバイスの通信手段を確立する。
【００６４】
ブロック１１８でインタフェースデバイスの製造元が識別された場合、ブロック１２０において、制御デバイスは、インタフェースデバイスへの問い合わせによりインタフェースデバイスのモデルが識別されたかを判定する。モデルが識別される場合、プロセスはブロック１２２に流れる。これについては後で説明する。モデルが識別されない場合、プロセスはブロック１２４に流れる。ブロック１２４において、制御デバイスは、そのインタフェースデバイスの製造元の全インタフェースデバイスに共通の通信手段を用いて、インタフェースデバイスの通信手段を確立する。
【００６５】
全インタフェースデバイスに共通であるか、そのインタフェースデバイスの製造元の全インタフェースデバイスに共通であるか、またはそのインタフェースデバイスのモデルに特定の通信手段である通信手段を用いて、インタフェースデバイスの通信手段を確立する手段は、インタフェースデバイスの階層的な通信手段を操作してインタフェースデバイスの機能性および活用性を最大にするいかなるプロセスによっても達成されることを、当業者は理解すべきである。
【００６６】
ブロック１２０でインタフェースデバイスのモデルが識別された場合、ブロック１２２において、制御デバイスは少なくとも１つのデバイスをコンフィギュレーションして、そのインタフェースデバイスのモデルに特定の通信手段を用いてインタフェースデバイスとインタフェースする。
【００６７】
図６は、この例示的アーキテクチャにおいて実施される、モジュール間の主要インタフェースを示す。ここで示される関数は、以下で説明する。
【００６８】
(１)  void  initSendTimer（void）
この関数は、SendTimerを初期化する。特に、この関数はSendTimerオブジェクトをトリガし、レジストリからタイミング情報を得る。
【００６９】
(２)  void  obtainDelayAndAction（int  &  out_nDelay、int  &  out_nAction）
この関数は、::Sleep関数（１０００を乗算する必要がある）およびアクションインジケータ（０または１）について秒単位で遅延時間を戻す。
【００７０】
(３)  int  initMonitorSendDLL（void）
この関数は、monitorSendDLLを初期化する。さらに、この関数はモニタされるデバイスを作成する。return  intは、０がエラーなしと定義されるエラーコードである。
【００７１】
(４)  int  sendConfig（void）
この関数は、ＯＤＢＣからデバイス情報を取得してそれを送信する。return  intは、０がエラーなしと定義されるエラーコードである。
【００７２】
(５)  int  monitorStatus（int  in_nAction）
この関数は、エラーチェックのための事前設定情報を監視する。さらに、in_nActionが１つである場合、この関数は付加的情報を監視し、それをローカルデータベースに格納するとともに宛先に送信する。return  intは、０がエラーなしと定義されるエラーコードである。
【００７３】
(６)  int  endDLL（void）
この関数は、オブジェクトを閉じる前にMonitorSend  DLLをクリーンアップする。return  intは、０がエラーなしと定義されるエラーコードである。
【００７４】
(７)  int  initReceiveStoreDLL（void）
この関数は、DLLの様々な部分を初期化する。return  intは、０がエラーなしと定義されるエラーコードである。
【００７５】
(８)  int  getMailAndUpdateDatabase（void）
この関数は、ReceiveStore  DLLをトリガしてＰＯＰ３サーバにアクセスし、メールの検索、検索したメールのパース、メールの削除、および抽出データのＯＤＢＣを介したデータベースへの格納を行なう。return  intは、０がエラーなしと定義されるエラーコードである。
【００７６】
(９)  int  endDLL（void）
この関数は、オブジェクトを閉じる前にReceiveStoreDLLをクリーンアップする。return  intは、０がエラーなしと定義されるエラーコードである。
【００７７】
図７は、本発明の１つの例示的実施形態によるMonitor_Send  DLLコンフィギュレーションの概略を示す。図７に示すMonitor_Send  DLLパッケージに含まれる関数は、以下で説明する。
【００７８】
(１)  change  updateConfig（std::map＜infoType、std::string＞&）
この関数は、ＯＤＢＣ内の現在レコードのデバイス情報データベースを更新する。この関数は、更新目的のためにＩＰアドレスおよび固有のＩＤを重視する（keys  on）。この関数は、固有のＩＤを追加し、製造元およびモデルがMonitorSendパッケージのＩＰアドレスにおいてデバイスに不正確に割り当てられている場合にこれらを更新するために主に用いられる。ＩＰアドレスおよび固有のＩＤを有するレコードがない場合、この関数は渡されたデータをデータベースに追加する。固有のＩＤは存在するがＩＰアドレスが変更されている場合、この関数はＩＰアドレスを更新する。戻り値変更はenum｛NoChange=0，UpDateRecord，AddRecord，ChangeIPaddress｝である。
【００７９】
(２)  bool  getConfig（std::map＜infoType、std::string＞&）
この関数は、デバイス情報についてのＯＤＢＣからのマップを所与の形式で取得する。この関数は、戻されたデータがある場合は真を戻し、それ以上データがない場合には偽を戻す。
【００８０】
(３)  bool  saveStatus（std::map＜infoType、std::string＞&）
この関数は、ＯＤＢＣにステータス情報を保存する。この関数は、保存が成功した場合には真を戻し、そうでない場合には偽を戻す。
【００８１】
(４)  bool  checkManufacturer（std::string&）
この関数は、渡された製造元のＩＰアドレスが正しいことをチェックする。製造元が正しい場合、関数は真を戻し、そうでない場合には偽に戻り、ストリング中の正しい製造元に戻る。
【００８２】
(５)  modelError  checkModel（std::string&）
この関数は、渡されたモデルのＩＰアドレスが正しいことをチェックする。ModelErrorは、｛ModelNoError=0，WrongModel，ModelInformationUnavailable｝を有するenumタイプである。WrongModelが検出される場合、正しいモデル名が戻されたストリングに入れられる。
【００８３】
(６)  CAbsDevice*createDevice（std::string&in_sIP、CSNMP&in_SNMP、std::string&in_sManufacturer、std::string&in_sModel）
この関数は、Device  Factory（デバイスファクトリ）においてその仕様のデバイスを作成する。この関数は、作成が成功した場合は作成したデバイスにポインタを戻し、そうでない場合には０に戻す。最後の２つのパラメータは、デフォルトとして空ストリングを有する。
【００８４】
(７)  bool  getUniqueID（std::string&out_sID）
この関数は、デバイスから固有のＩＤを戻す。この関数は、固有のＩＤが戻された場合は真を戻し、そうでない場合には偽を戻す。
【００８５】
(８)  bool  getStatus（std::map＜infoType、std::string＞&）
この関数は、デバイスからステータス情報を取得する。この関数は、ステータスが戻される場合には真を戻し、ステータスが取得され得ない場合には偽を戻す。この関数は、戻る前のエラーステータスを保持する変数をリセットする。
【００８６】
(９)  void  checkErrorStatus（void）
この関数は、デバイスをトリガして内部に保存されるエラーステータスをチェックする。
【００８７】
(１０)  errorCode  startSend（infoType）
この関数は、Data  Transfer（データ転送）をトリガして、infoTypeに指定されるデータを送信する準備をする。この関数はerrorCodeを戻す。
【００８８】
(１１)  errorCode  dataSend（std::map＜infoType、std::string＞&）
Data  Transferにおけるこの関数は、受信データを適切にフォーマット、暗号化、および符号化した後で適切な宛先へ送信する。この関数はerrorCodeを戻す。
【００８９】
(１２)  errorCode  endSend（void）
Data  Transferにおけるこの関数は、データ送信を終了させる。この関数はerrorCodeを戻す。
【００９０】
図８は、この例示的アーキテクチャにおいて実施される、MonitorSend初期化シーケンスを示す。
【００９１】
図９は、この例示的アーキテクチャにおいて実施される、コンフィギュレーション送信シーケンスを示す。
【００９２】
図１０は、この例示的アーキテクチャにおいて実施される、ステータス送信シーケンスを示す。
【００９３】
図１１は、本発明の１つの例示的実施によるReceiveStore  DLLコンフィギュレーションの概略を示す。図１１に示すReceiveStore  DLLパッケージに含まれる関数は、以下で説明する。
【００９４】
(１)  bool  getInformationType（infoType&)
この関数は、DataRetrieverをトリガしてＰＯＰ３データの取得を試み、取得した電子メールのデータタイプを確定する。この関数は、電子メールが取得された場合には真を戻し、その時にＰＯＰ３サーバにそれ以上電子メールがない場合には偽を戻す。
【００９５】
(２)  bool  getInformation（std::map＜infoType、std::string＞&）
この関数は、ＤａｔａＲｅｔｒｉｅｖｅｒから電子メールの情報内容を検索する。この関数は、情報が戻された場合には真を戻し、電子メールメッセージ内に入手可能なデータセットがそれ以上ない場合には偽を戻す。
【００９６】
(３)  change  updateConfig（std::map＜infoType、std::string＞&）
この関数は、ＯＤＢＣ内の現在レコードのデバイス情報データベースを更新する。この関数は、更新目的のためにＩＰアドレスおよび固有のＩＤを重視する。この関数は、固有のＩＤを追加し、製造元およびモデルがMonitorSendパッケージのＩＰアドレスにおいてデバイスに不正確に割り当てられている場合、これらを更新するために主に用いられる。ＩＰアドレスおよび固有のＩＤを有するレコードがない場合、この関数は渡されたデータをデータベースに追加する。固有のＩＤは存在するがＩＰアドレスが変更されている場合、この関数はＩＰアドレスを更新する。戻り値変更はenum｛NoChange=0，UpDateRecord，AddRecord，ChangeIPaddress｝である。
【００９７】
(４)  bool  saveStatus（std::map＜infoType、std::string＞&）
この関数は、ＯＤＢＣ内にステータス情報を保存する。この関数は、保存が成功した場合には真を戻し、そうでない場合には偽を戻す。
【００９８】
図１２の表は、データ構造およびそれが監視された１つのデバイスに関する情報をどのように反映するかを示す。データ構造は、担当者の電子メールアドレスならびに電話番号を含む。このデータ構造は一般には使用されていない。しかしながら、この構造はデータベース構造を反映する。
【００９９】
以下のセクションでは、システム内で用いられる主要なenumタイプを説明する。
【０１００】
＜infoType＞
このセクションでは、この書き込み時におけるinfoType  enumの定義を説明する。プロジェクトの進行に伴い、さらにinfoType値が追加され得る。データタイプには０〜９９の値が割り当てられる。Device  Information（デバイス情報）には１００〜４９９の値が割り当てられる。共通のパラメータおよび規格のＭＩＢパラメータには５００〜９９９の値が割り当てられる。Ricoh固有の情報には１０００〜２９９９が割り当てられる。Xeroxには３０００〜３９９９が割り当てられる。Lexmarkには４０００〜４９９９が割り当てられる。EPSONには５０００〜５９９９が割り当てられる。ＨＰには６０００〜６９９９が割り当てられる。例えば、値は以下のように定義される。
enum  infoType｛NotDefine=0，DeviceInformation，StatusInformation，Manufacturer=100，Model，UniqueID，IPAddress，CompanyName，Street，City，State，ZipCode，Location，ContactPerson，PhoneNumber，EmailAddress，DateTime=500，HrDeviceErrors，LowPaper，NoPaper，LowToner，NoToner，DoorOpen，Jammed，Offline，ServiceRequested，PrtGeneralConfigChanges，PrtLifeCount，PrtAlertDesc1，PrtAlertDesc2，PrtAlertDesc3，PrtAlertDesc4，PrtAlertDesc5，RicohEngineCounterTotal=1000，RicohEngineCounterPrinter，RicohEngineCounterFax，RicohEngineCounterCopier，XeroxYellowTonerCartridge=3000，XeroxMagentaTonerCartridge，XeroxCyanTonerCartridge，XeroxBlackTonerCartridge，XeroxPrinterCartridge｝
【０１０１】
＜errorCode＞
このセクションでは、この書き込み時に定義されるエラーコードを説明する。プロジェクトの進行に伴い、さらなるエラーコードが追加され得る。０〜９９は保存される。１００〜１９９はＳＭＴＰに、２００〜２９９はＰＯＰ３に、３００〜３９９はSocketに割り当てられる。必要であれば他の範囲も定義されるであろう。
enum  errorCode(NoError=0，UnknownError=1，SendHeloCommandFailed=100，SendMailCommandFailed，SendRcptCommandFailed，SendDataCommandFailed，SendDataFailed，SendQuitCommandFailed，SendUserCommandFailed=200，SendPassCommandFailed，SendStatCommandFailed，SendRetrCommandFailed，SendDeleCommandFailed，SendQuitPop3CommandFailed，CreateSocketFailed=300，ConnectSocketFailed)；
【０１０２】
本発明の好ましい実施形態の上記説明は、例示および説明のために提示された。網羅的であること、開示された厳密な形態に本発明を限定することは意図されておらず、上記の教示に鑑みて多くの変更および変形が可能である。たとえば、本明細書に記載または図示される任意の１つまたは複数の概念は、関連出願第０９／７５６，１２０号に開示されるシステムおよび／または方法に適用することができる。さらに、関連出願第０９／７５６，１２０号に記載されるいかなる概念または特徴も、本明細書に開示されるシステムまたは方法に適用することができる。本実施形態は本発明の原理およびその実用的用途を最良に説明するために選択および記載され、それによって当業者は、意図される特定の使用に適するような様々な変更を伴って、本発明および様々な実施形態を利用することが可能である。本発明の範囲は、併記の特許請求の範囲によってのみ定義されることを意図される。
【０１０３】
【発明の効果】
本発明によれば、通信手段の階層を利用して、制御デバイスとインタフェースデバイスとの間で最も有効な通信手段を確立することができる。
【図面の簡単な説明】
【図１】  複数のハードウェアデバイスとコンピュータネットワークとの関係を示す。
【図２】  種々のハードウェアデバイス間での通信に利用される種々の通信手段を示す。
【図３】  インタフェース通信手段の階層を示す。
【図４】  制御デバイスが本発明の実施形態によりインタフェースデバイスと通信手段を確立するための通信手段の階層的関係を利用するフローチャートである。
【図５】  制御デバイスが本発明の別の実施形態によりインタフェースデバイスと通信手段を確立するための通信手段の階層的関係を利用するフローチャートである。
【図６】  主要なインタフェースのモジュールを備える本発明の例示的アーキテクチャを示す。
【図７】  本発明の１つの例示的な実施によるMonitorSend  DLLコンフィギュレーションを示す。
【図８】  本発明の１つの例示的な実施によるMonitorSend初期化シーケンスを示す。
【図９】  本発明の１つの例示的な実施によるコンフィギュレーション送信シーケンスを示す。
【図１０】  本発明の１つの例示的な実施によるステータス送信シーケンスを示す。
【図１１】  本発明の１つの例示的な実施によるReceiveStore  DLLコンフィギュレーションを示す。
【図１２】  データ構造およびそれが監視された１つのデバイスに関する情報をどのように反映するかを示す。
【符号の説明】
１０、３２  ワークステーション
１４、４０  ＰＯＰ３サーバ
１６、４２  ＳＭＴＰサーバ
２０、３８  データベース
２２  プリンタモデルＡ
２６、２８  ゲートウェイサーバ
３０  プリンタモデルＢ
３２  ワークステーション
４４  制御デバイス
４６  データベース
５０、７０  ベンダ固有の通信手段
６２  ＰＯＰ３サーバ
６６  ＳＭＴＰサーバ
７２  ワークステーション
８２  全インタフェースデバイスに共通の確立された通信手段
８４  製造業者Ａの全インタフェースデバイスに共通の確立された通信手段
８６  製造業者Ｂの全インタフェースデバイスに共通の確立された通信手段
８８  モデルＡに特定のインタフェースデバイス通信手段
９０  モデルＢに特定のインタフェースデバイス通信手段
９２  モデルＣに特定のインタフェースデバイス通信手段
９４  モデルＤに特定のインタフェースデバイス通信手段
【図１】
0004244136.tif 000002
【図２】
0004244136.tif 000003
【図３】
0004244136.tif 000004
【図４】
0004244136.tif 000005
【図５】
0004244136.tif 000006
【図６】
0004244136.tif 000007
【図７】
0004244136.tif 000008
【図８】
0004244136.tif 000009
【図９】
0004244136.tif 000010
【図１０】
0004244136.tif 000011
【図１１】
0004244136.tif 000012
【図１２】
0004244136.tif 000013