ユーザセッションからクライアントシステムへのトウェイン関数呼出しをリモーティングするためのシステムおよび方法
ユーザセッションの範囲内におけるトウェイン関数呼出しをクライアントシステムにリモーティングするメカニズムが開示される。サーバ上のトウェインアプリケーションによって行なわれたトウェイン関数呼出しをフックすることにより、トウェイン関数呼出しは、仮想接続を介してクライアントシステムにリモーティングされ得る。サーバベースのトウェインアプリケーションに対応するプロキシアプリケーションは、クライアントシステム上で作成される。プロキシアプリケーションは、サーバと通信し、トウェインフレームワークの残りに対して適切な関数呼出しを行なう。仮想接続を介して送信されたメッセージは、送信前にフィルタリングされ、それにより必要とされる通信トラフィックの量を制限する。仮想チャネル上の帯域幅を効率的に使用するために、マルチプレクサおよびデマルチプレクサが利用される。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明の説明的な実施形態は、概ね画像データ処理に関し、より具体的には、サーバ上でホストされるユーザセッションから、トウェイン（Ｔｗａｉｎ）準拠の画像収集デバイスと通信するクライアントシステムへの、アプリケーションのリモーティングに関する。
【背景技術】
【０００２】
トウェインは、イメージングアプリケーションのための標準的なフレームワークである。アプリケーションは、トウェイン準拠のドキュメントスキャナ、デジタルカメラ、および画像データベースを制御するために、周知のＡＰＩを呼び出す。トウェインデバイスとともに使用されるベンダー供給のハードウェアドライバは、インターフェースおよび能力の周知のセットに準拠する。トウェインアーキテクチャについての標準的なフレームワークは、ワシントン州ＲｅｄｍｏｎｄのＭｉｃｒｏｓｏｆｔ ＣｏｒｐｏｒａｔｉｏｎからのＷＯＲＤなどのトウェインアプリケーション、または写真編集アプリケーションを含む。アークテクチャは、ベンダー供給のハードウェアドライバを制御するアプリケーションによって呼び出されるＡＰＩを供給する構成要素であるデータソースマネジャー（ＤＳＭ）をも含む。ワシントン州ＲｅｄｍｏｎｄのＭｉｃｒｏｓｏｆｔ ＣｏｒｐｏｒａｔｉｏｎからのＷＩＮＤＯＷＳ（登録商標）オペレーティングシステムについて、データマネジャーは、ＷＩＮＤＯＷＳ（登録商標）とともに出荷されるＤＬＬ ｔｗａｉｎ＿３２．ｄｌｌにおいて見いだされる。構成要素は一般的であり、基礎を成す画像ハードウェアの知識を有しない。標準的なトウェインアーキテクチャにさらに含まれるものは、特定のデバイスのためのベンダー供給のドライバであるデータソース（ＤＳ）である。データソースは、ＵＳＢ、ＦＩＲＥＷＩＲＥ、Ｐａｒａｌｌｅｌ、ＳＣＳＩ、ＩＲ、ＢＬＵＥＴＯＯＴＨ、ＩＥＥＥ １３９４プロトコル、Ｗｉ−Ｆｉプロトコル、または他のワイヤレスプロトコルなどのいくかのプロトコルのうちの一つを使用して、画像収集デバイスにデータを送信する（ｔａｌｋ ｔｏ）ことを担う。イメージングデバイスは、スキャナ、デジタルカメラ、またはソフトウェアアプリケーションであり得る。
【０００３】
図１（従来技術）は、従来のトウェインアーキテクチャを示す。従来のトウェインアーキテクチャは、接続されたモニター４とともに、ユーザ６によって利用されるコンピュータ２を含む。コンピュータ２は、写真編集アプリケーションなどのトウェインアプリケーション８を含む。トウェインアプリケーション８は、データソースマネジャー１０に対して関数呼出しを行なう。データソースマネジャー１０は、アプリケーションがベンダーデータソース１２にアクセスし得るためのＡＰＩ、およびコンピュータ２と通信する画像収集デバイスの製造およびモデリングするためのベンダー供給のハードウェアドライバを提供する。示されるトウェインアーキテクチャは、コンピュータへのＵＳＢ１４インターフェースを含む。トウェイン準拠のスキャナ１６は、ＵＳＢインターフェース１４を介してコンピュータシステムにつなげられる。
【０００４】
残念ながら、トウェインアプリケーションによって利用されるトウェイン準拠のデバイスを制御するための従来の技術は、分散型のマルチユーザ、マルチセッション環境においては、特に首尾よく作用するというわけではない。たとえば、遠隔クライアントシステムについて複数のユーザセッションをホストするサーバは、各トウェイン準拠のデバイスについて固有のベンダー特有のハードウェアドライバとともにロードされなければならない。単一のユーザについての単一のデバイスを制御するためには問題ではない一方で、複数のデバイスはサーバが複数のドライバを含むことを必要とする。さらに、ユーザセッションをサポートするサーバについて、仮想チャネルはセッションごとに一つのアプリケーションをサポートする。このことは、複数のトウェイン準拠のデバイスが同一のセッションの範囲内でサポートされることを妨げ、同時にセッションにおいて二つ以上のトウェインアプリケーションを使用することを妨げる。
【発明の開示】
【課題を解決するための手段】
【０００５】
（発明の概要）
本発明の説明的な実施形態は、ユーザセッションの範囲内におけるトウェイン関数呼出しをクライアントシステムに対してリモーティングするメカニズムを提供する。サーバ上のトウェインアプリケーションによって行なわれたトウェイン関数呼出しをフックすることによって、トウェイン関数呼出しは、クライアントシステムへの仮想接続を介してリモーティングされ得る。サーバベースのトウェインアプリケーションに対応するプロキシアプリケーションは、クライアントシステム上で作成される。プロキシアプリケーションは、サーバと通信し、トウェインフレームワークの残りに対して適切な関数呼出しを行なう。プロキシアプリケーションの使用は、複数のアプリケーションおよびデバイスが同時にサポートされることを可能にする。仮想接続を介して送信されたメッセージは、送信前にフィルタリングされ、それにより必要とされる通信トラフィックの量を制限する。マルチプレクサおよびデマルチプレクサは、仮想チャネル上の帯域幅を効率的に使用するために利用される。本発明はさらに、仮想チャネルを介した送信の前に画像データを圧縮する。
【０００６】
一実施形態において、クライアントに関連する画像収集装置を制御するための方法は、プレゼンテーションレベルプロトコルを使用してサーバと通信するクライアントを提供するステップを含む。クライアントは、サーバ上で実行するアプリケーションに関連するプロキシアプリケーションを実行している。方法は、プレゼンテーションレベルプロトコルを使用してネットワークを介してサーバから、クライアントに関連する画像収集デバイスに向けられたコマンドを、プロキシアプリケーションにおいて受信するステップをさらに含む。方法は、受信されたコマンドを画像収集デバイスに対して発行するステップをさらに含む。方法は、発行されたコマンドへの応答を画像収集デバイスから受信するステップと、受信された応答を次にプレゼンテーションレベルプロトコルを使用してネットワークを介してサーバに送信するステップとをさらに含む。
【０００７】
別の実施形態において、トウェインクライアント環境においてクライアントに関連する画像収集デバイスを遠隔に制御するための方法は、ネットワークを介してクライアントから画像収集イベントを受信するステップを含む。方法は、受信されたイベントをイベントに関連するアプリケーションプログラムに提供するステップをさらに含む。方法は、送信されたイベントに対する応答をアプリケーションプログラムから受信するステップと、受信された応答を次にネットワークを介してクライアントに送信するステップとをさらに含む。
【０００８】
一実施形態において、クライアントと通信する画像収集デバイスを制御するための方法は、クライアントと通信する画像収集デバイスに向けられたコマンドをサーバから受信するステップを含む。方法はまた、クライアントと通信する画像収集デバイスに対して、受信されたコマンドに基づいてＴＷＡＩＮ ＡＰＩ呼出しを発行するステップと、発行されたコマンドに対する応答を画像収集デバイスから受信するステップとを含む。方法はまた、受信された応答をサーバに送信する。
【発明を実施するための最良の形態】
【０００９】
本発明のこれらのおよび他の局面は、以下の詳細な説明および添付の図面から容易に明らかになり、それらは説明することを意図したものであり本発明を限定することを意図したものではない。
【００１０】
本発明の説明的な実施形態は、クライアントシステムと通信する複数のトウェイン準拠デバイス、および／またはユーザセッションにおいて実行する複数のトウェインアプリケーションを、ユーザセッションがサポートすることを可能にする。ユーザセッションにおいて実行するトウェインアプリケーションからトウェイン関数呼出しをフックすることにより、関数呼出しは、プレゼンテーションレベルプロトコルを使用して、処理のためにクライアントシステム上のプロキシアプリケーションにリダイレクトされ得る。プロキシアプリケーションは、クライアントシステム上で作成され、サーバ上のユーザセッションにおいて実行する各アプリケーションに対応する。クライアントシステム４０上のメッセージは、必須の通信のみをサーバに送信するようにフィルタリングされる。
【００１１】
図２Ａは、本発明の一実施形態を実行するために適切な環境を示す。サーバ２０は、ネットワーク３０を介してクライアントシステム４０に接続される。サーバ２０は、一つ以上のユーザセッション２２および２４をホストする。ユーザセッションは、トウェイン準拠アプリケーション２６および２８の実行中のインスタンスを含み得る。トウェインアプリケーション２６および２８からのトウェイン関数呼出しは、プレゼンテーションレベルプロトコルを介して、クライアントシステム４０上の対応するトウェインプロキシプロセス４２および４４に送信される。スキャナＡ５０およびスキャナＢ６０は、クライアントシステム４０と通信し、サーバ２０上のユーザセッション２４において実行するアプリケーション２６および２８から発信されかつクライアントシステムにおいて処理されるコマンドによって制御される。サーバ２０とクライアントシステム４０との間の通信のメカニクス（ｍｅｃｈａｎｉｃｓ）は、以下の図２Ｂにおいてより詳細に探求される。
【００１２】
図２Ｂは、図２Ａの環境をより詳細に示す。サーバ２０はユーザセッション２４をホストする。ユーザセッション２４は、それぞれリダイレクタモジュール７０および７２と連絡を取るトウェインアプリケーション２６および２８を含む。リダイレクタモジュール７０および７２は、エントリポイントをトウェイン＿３２．ｄｌｌの中に（エントリポイントをＤＳＭの中に）フックするサーバ側フックＤＬＬである。リダイレクタモジュール７０および７２は、トウェインアプリケーション２６および２８からのすべてのトウェイン呼出しをインタセプトし、その呼出しをクライアントシステム４０に転送する。リダイレクタモジュール７０および７２はまた、ＪＰＥＧ圧縮を使用して圧縮されることをリクエストされた画像を復元する（ｕｎｃｏｍｐｒｅｓｓ）。リダイレクタモジュール７０および７２は、セッションマネジャー７４によってホストされるトウェインマルチプレクサ７６と連絡を取る。ＩＣＡアーキテクチャにおいて、セッションマネジャー７４はＷＦＳｈｅｌｌ Ｐｒｏｃｅｓｓである。
【００１３】
トウェインマルチプレクサ７６は、セッションマネジャー７４において稼動するサーバ側仮想チャネルモジュールであり、クライアントとサーバとの間のトウェイン通信を管理するために使用される。トウェインマルチプレクサ７６は、セッション２４において実行するトウェインアプリケーションに関連するリダイレクタモジュール７０および７２からペイロードを受信する。トウェインマルチプレクサ７６は、仮想チャネル３２についてのサイズ制限に従って、ペイロードをより小さなパケットのシーケンスに分割する。次にパケットは、クライアントシステムへの移行のために仮想チャネルに書き込まれる。トウェインマルチプレクサ７６は、リクエストをクライアントシステム４０に伝え、クライアントから受信された応答を返す。トウェインマルチプレクサ７６は、リクエストと応答とが一致するかどうかを知らず、応答を待たない。したがって、トウェインマルチプレクサ７６は、なんらかの応答を受信する前に、異なるトウェインアプリケーション２６および２８からのいくつかのリクエストを受信および転送し得る。トウェインマルチプレクサ７６はまた、入ってくるパケットをペイロードに組み立て、次にペイロードは適切なリダイレクタモジュール７０および７２にルーティングされる。
【００１４】
仮想チャネル３２は、ネットワーク３０を介して、パケットをクライアントシステム４０に移送する。パケットは、厳密に順序付けられたシーケンスにおいて仮想チャネル３２に送信される。トウェインデマルチプレクサ（デマックス（ｄｅｍｕｘ））８０は、仮想チャネル３２を介して、クライアントシステム上のパケットを受信する。トウェインデマルチプレクサ８０は、クライアントシステム上でアーキテクチャ４１をサポートするプレゼンテーションレベルプロトコルにプラグインするクライアント側仮想チャネルドライバである（たとえばデマックスはＩＣＡクライアントにプラグインする）。トウェインデマルチプレクサ８０は、トウェインリクエストを、厳密に順序付けられたパケットのシーケンスとして受信する。トウェインデマルチプレクサ８０は、入ってくるパケットをペイロードに組み立てる。入ってくるパケットの受信中にエラーチェックが実行され得る。ペイロードが完全に受信されると、トウェインデマルチプレクサ８０は、ペイロードをプロキシアプリケーション４３および４５に転送する。正しいプロキシアプリケーション４３および４５は、ペイロードにおけるフィールドを検査することによって識別される。クライアントシステム上のトウェインデマックス８０は、登録（ｒｅｇｉｓｔｅｒ）されたプロキシアプリケーション４３および４５のリスティングを保持する。プロキシアプリケーション４３および４５が新しいプロキシアプリケーションであり、それゆえに登録されていない場合、トウェインデマックス８０はプロキシアプリケーションを作成する。
【００１５】
プロキシアプリケーション４３および４５は、クライアントシステム４０上のコンテナプロセス５１および５３によってホストされ、サーバ上のトウェインアプリケーション２６および２８に対応する。プロキシアプリケーション４３および４５は、トウェインデマルチプレクサを用いた登録の後、トウェインデマルチプレクサ８０から受信されトウェインアプリケーション２６および２８によって発信されたコマンドを処理する。プロキシアプリケーション４３および４５は、クライアントシステム４０と通信中のスキャナ５０および６０についてベンダー特有の（ｖｅｎｄｏｒ−ｓｐｅｃｉｆｉｃ）ドライバ９４および９６を制御するために、ＤＳＭ９０および９２に対してＡＰＩ呼出しを行なう。プロキシアプリケーション４３および４５は、コンテナプロセスとして実行するので、対応するセキュリティの発行なしに、動的なリンクされたライブラリを実行するコンテクストを提供する。プロキシアプリケーションはまた、データソース９４および９６によって生成されたメッセージを受信する。
【００１６】
データソースＵＩ９４および９６が使用可能にされると（たとえばスキャンするダイアログボックス）、プロキシアプリケーション４３および４５は、受信されるすべてのメッセージを処理することによって、もともとのトウェインアプリケーションをシミュレートする。たとえば、ＷＩＮＤＯＷＳ（登録商標）環境において、プロキシアプリケーションは、画像収集デバイス上でボタンが押されたことを示すメッセージなどの、受信されたすべてのＷＩＮＤＯＷＳ（登録商標）メッセージについて、ＭＳＧ＿ＰＲＯＣＥＳＳＥＶＥＮＴコマンドを呼び出し得る。メッセージがトウェインによって所有されない場合、そのメッセージが対象とするアプリケーションがメッセージを正常に処理する。しかし、メッセージがトウェイン通知である場合、通知ペイロードは、サーバ２０上のリダイレクタモジュール７０および７２に転送されて次にトウェインアプリケーション２６および２８上に転送される場所から、トウェインデマックス８０へと送信される。次にトウェインアプリケーション２６および２８は、通知に応答して新しいコマンドを発行し得る。この場合、トウェインコマンドはクライアントシステムに送信される。
【００１７】
トウェイン通知であり得るメッセージのみが仮想チャネルを介して転送されるので、クライアント側におけるメッセージの初期スクリーニングは、ネットワークトラフィックを減少させる。ネットワークトラフィックは、送信前におけるビットマップのＪＰＧへの圧縮によっても減少され得る。クライアントシステム４０と通信する画像収集デバイスによって収集された画像データは、サーバ２０への送信前に所定のルールに基づいて圧縮され得る。たとえば、ピクセル位置あたり２ビット以上を有する画像データは送信前に圧縮され得る一方で、ピクセル位置あたり１ビットの比率を有する画像データは圧縮なしに送信され得る。同様に、画像データは、サーバに送信されるサイズが最も小さいアルゴリズムの出力を用いた二つ以上の圧縮アルゴリズムを用いて圧縮され得る。圧縮はプロキシアプリケーション４３および４５において行なわれ、解凍（ｄｅｃｏｍｐｒｅｓｓｉｏｎ）はトウェインリダイレクタモジュール７０および７２において行なわれる。
【００１８】
当業者は、ユーザがクライアントシステムを介してアクセスするサーバ上にセッションを作成するために使用されるサーバ２０およびクライアントシステム４０における構成要素が、展開されるアーキテクチャに依存して変化することを認識する。例示的なプレゼンテーションレベルサポーティングアーキテクチャは、フロリダ州Ｆｏｒｔ ＬａｕｄｅｒｄａｌｅのＣｉｔｒｉｘ Ｓｙｓｔｅｍｓ Ｉｎｃ．からのＩｎｄｅｐｅｎｄｅｎｔ Ｃｏｍｐｕｔｉｎｇ Ａｒｃｈｉｔｅｃｔｕｒｅ（ＩＣＡ）、ワシントン州ＲｅｄｍｏｎｄのＭｉｃｒｏｓｏｆｔ ＣｏｒｐｏｒａｔｉｏｎからのＲｅｍｏｔｅ Ｄｅｓｋｔｏｐ Ｐｒｏｔｏｃｏｌ（ＲＤＰ）、およびＸ−Ｏｐｅｎ ＣｏｎｓｏｒｔｉｕｍからのＸ−Ｗｉｎｄｏｗ Ｐｒｏｔｏｃｏｌを含む。たとえばＩＣＡアーキテクチャにおいて、クライアント側のプレゼンテーションレベルサポーティングアーキテクチャ４１はＩＣＡクライアントであり、サーバ２０はサーバがホストするユーザセッションを作成および保持するためにメタフレームプレゼンテーションサーバ（ＭＥＴＡＦＲＡＭＥ ＰＲＥＳＥＮＴＡＴＩＯＮ ＳＥＲＶＥＲ）を展開する。ＲＤＰアーキテクチャ、Ｘ−Ｏｐｅｎアーキテクチャ、または他のプレゼンテーションレベルプロトコルサポーティングアーキテクチャからの同様の構成要素もまた、本発明の範囲の範囲内において展開され得る。
【００１９】
多くの実施形態において、クライアントシステム４０およびサーバ２０は、カリフォルニア州Ｐａｌｏ ＡｌｔｏのＨｅｗｌｅｔｔ−Ｐａｃｋａｒｄ Ｃｏｒｐｏｒａｔｉｏｎ、およびテキサス州Ｒｏｕｎｄ ＲｏｃｋのＤｅｌｌ Ｃｏｒｐｏｒａｔｉｏｎによって製造される種類の、パーソナルコンピュータまたはコンピュータサーバとして提供される。図３Ａおよび３Ｂは、クライアントシステム２０およびサーバ４０として有用な代表的なコンピュータ２００のブロック図を示す。図３Ａおよび３Ｂに示されるように、各コンピュータ２００は、中央処理ユニット２０２および主メモリユニット２０４を含む。各コンピュータ２００は、一つ以上の入力／出力デバイス２３０ａ〜２３０ｎ（一般的に参照番号２３０を使用して参照される）、および中央処理ユニット２０２と通信するキャッシュメモリ２４０などの他のオプション的要素をも含み得る。
【００２０】
中央処理ユニット２０２は、主メモリユニット２０４から取り出された命令に対して応答および処理をする任意の論理回路網である。多くの実施形態において、中央処理ユニットは次のようなマイクロプロセッサによって提供される。すなわち、カリフォルニア州Ｍｏｕｎｔａｉｎ ＶｉｅｗのＩｎｔｅｌ Ｃｏｒｐｏｒａｔｉｏｎによって製造される、８０８８、８０２８６、８０３８６、８０４８６、Ｐｅｎｔｉｕｍ（登録商標）、Ｐｅｎｔｉｕｍ（登録商標）Ｐｒｏ、Ｐｅｎｔｉｕｍ（登録商標）ＩＩ、Ｃｅｌｅｒｏｎ、またはＸｅｏｎプロセッサ。イリノイ州ＳｃｈａｕｍｂｕｒｇのＭｏｔｏｒｏｌａ Ｃｏｒｐｏｒａｔｉｏｎによって製造される、６８０００、６８０１０、６８０２０、６８０３０、６８０４０、ＰｏｗｅｒＰＣ６０１、ＰｏｗｅｒＰＣ６０４、ＰｏｗｅｒＰＣ６０４ｅ、ＭＰＣ６０３ｅ、ＭＰＣ６０３ｅｉ、ＭＰＣ６０３ｅｖ、ＭＰＣ６０３ｒ、ＭＰＣ６０３ｐ、ＭＰＣ７４０、ＭＰＣ７４５、ＭＰＣ７５０、ＭＰＣ７５５、ＭＰＣ７４００、ＭＰＣ７４１０、ＭＰＣ７４４１、ＭＰＣ７４４５、ＭＰＣ７４４７、ＭＰＣ７４５０、ＭＰＣ７４５１、ＭＰＣ７４５５、またはＭＰＣ７４５７プロセッサ。カリフォルニア州Ｓａｎｔａ ＣｌａｒａのＴｒａｎｓｍｅｔａ Ｃｏｒｐｏｒａｔｉｏｎによって製造される、Ｃｒｕｓｏｅ ＴＭ５８００、Ｃｒｕｓｏｅ ＴＭ５６００、Ｃｒｕｓｏｅ ＴＭ５５００、Ｃｒｕｓｏｅ ＴＭ５４００、Ｅｆｆｉｃｅｏｎ ＴＭ８６００、Ｅｆｆｉｃｅｏｎ ＴＭ８３００、またはＥｆｆｉｃｅｏｎ ＴＭ８６２０プロセッサ。ニューヨーク州Ｗｈｉｔｅ ＰｌａｉｎｓのＩｎｔｅｒｎａｔｉｏｎａｌ Ｂｕｓｉｎｅｓｓ Ｍａｃｈｉｎｅｓによって製造される、ＲＳ／６０００プロセッサ、ＲＳ６４、ＲＳ ６４ ＩＩ、Ｐ２ＳＣ、ＰＯＷＥＲ３、ＲＳ６４ ＩＩＩ、ＰＯＷＥＲ３−ＩＩ、ＲＳ ６４ ＩＶ、ＰＯＷＥＲ４、ＰＯＷＥＲ４＋、ＰＯＷＥＲ５、またはＰＯＷＥＲ６プロセッサ。またはカリフォルニア州ＳｕｎｎｙｖａｌｅのＡｄｖａｎｃｅｄ Ｍｉｃｒｏ Ｄｅｖｉｃｅｓによって製造される、ＡＭＤ Ｏｐｔｅｒｏｎ、ＡＭＤ Ａｔｈａｌｏｎ ６４ ＦＸ、ＡＭＤ Ａｔｈａｌｏｎ、またはＡＭＤ Ｄｕｒｏｎプロセッサ。
【００２１】
主メモリユニット２０４は、データを格納する能力があり、任意の記憶位置がマイクロプロセッサ２０２によって直接的にアクセスされることが可能な、次のような一つ以上のメモリチップであり得る。すなわち、スタティックランダムアクセスメモリ（ＳＲＡＭ）、Ｂｕｒｓｔ ＳＲＡＭまたはＳｙｎｃｈＢｕｒｓｔ ＳＲＡＭ（ＢＳＲＡＭ）、ダイナミックランダムアクセスメモリ（ＤＲＡＭ）、Ｆａｓｔ Ｐａｇｅ Ｍｏｄｅ ＤＲＡＭ（ＦＰＭ ＤＲＡＭ）、Ｅｎｈａｎｃｅｄ ＤＲＡＭ（ＥＤＲＡＭ）、Ｅｘｔｅｎｄｅｄ Ｄａｔａ Ｏｕｔｐｕｔ ＲＡＭ （ＥＤＯ ＲＡＭ）、Ｅｘｔｅｎｄｅｄ Ｄａｔａ Ｏｕｔｐｕｔ ＤＲＡＭ（ＥＤＯ ＤＲＡＭ）、Ｂｕｒｓｔ Ｅｘｔｅｎｄｅｄ Ｄａｔａ Ｏｕｔｐｕｔ ＤＲＡＭ（ＢＥＤＯ ＤＲＡＭ）、Ｅｎｈａｎｃｅｄ ＤＲＡＭ（ＥＤＲＡＭ）、同期式ＤＲＡＭ（ＳＤＲＡＭ）、ＪＥＤＥＣ ＳＲＡＭ、ＰＣ１００ ＳＤＲＡＭ、Ｄｏｕｂｌｅ Ｄａｔａ Ｒａｔｅ ＳＤＲＡＭ（ＤＤＲ ＳＤＲＡＭ）、Ｅｎｈａｎｃｅｄ ＳＤＲＡＭ（ＥＳＤＲＡＭ）、ＳｙｎｃＬｉｎｋ ＤＲＡＭ（ＳＬＤＲＡＭ）、Ｄｉｒｅｃｔ Ｒａｍｂｕｓ ＤＲＡＭ（ＤＲＤＲＡＭ）、または強誘電体ＲＡＭ（ＦＲＡＭ）。
【００２２】
図３Ａに示される実施形態において、プロセッサ２０２はシステムバス２２０（より詳細に以下に記述される）を介して主メモリ２０４と通信する。図３Ｂは、プロセッサがメモリポートを介して主メモリ２０４と直接的に通信するコンピュータ２００の実施形態を示す。たとえば、図３Ｂにおいて、主メモリ２０４はＤＲＤＲＡＭであり得る。
【００２３】
図３Ａおよび３Ｂは、主プロセッサ２０２が、「バックサイド」バスと呼ばれることもある二次バスを介してキャッシュメモリ２４０と直接的に通信する実施形態を示す。他の実施形態において、主プロセッサ２０２はシステムバス２２０を使用してキャッシュメモリ２４０と通信する。キャッシュメモリ２４０は、一般的に主メモリ２０４よりも速い応答時間を有し、一般的にＳＲＡＭ、ＢＳＲＡＭ、またはＥＤＲＡＭによって提供される。
【００２４】
図３Ａに示される実施形態において、プロセッサ２０２はローカルシステムバスを介して種々のＩ／Ｏデバイス２３０と通信する。ＶＥＳＡ ＶＬバス、ＩＳＡバス、ＥＩＳＡバス、ＭｉｃｒｏＣｈａｎｎｅｌＡｒｃｈｉｔｅｃｔｕｒｅ（ＭＣＡ）バス、ＰＣＩバス、ＰＣＩ−Ｘバス、ＰＣＩ−Ｅｘｐｒｅｓｓバス、またはＮｕバスを含む種々のバスが、中央処理ユニット２０２をＩ／Ｏデバイス２３０に接続するために使用され得る。Ｉ／Ｏデバイスがビデオディスプレイである実施形態について、プロセッサ２０２はディスプレイと通信するためにＡｄｖａｎｃｅｄ Ｇｒａｐｈｉｃｓ Ｐｏｒｔ（ＡＧＰ）を使用し得る。図３Ｂは、主プロセッサ２０２がＨｙｐｅｒＴｒａｎｓｐｏｒｔ、Ｒａｐｉｄ Ｉ／Ｏ、またはＩｎｆｉｎｉＢａｎｄを介して、Ｉ／Ｏデバイス２３０ｂと直接的に通信するコンピュータ２００の実施形態を示す。図３Ｂはまた、ローカルバスおよび直接通信が混合された実施形態を示す。すなわち、プロセッサ２０２は、Ｉ／Ｏデバイス２３０ｂと直接的に通信しながら、ローカル相互接続バスを使用してＩ／Ｏデバイス２３０ａと通信する。
【００２５】
コンピュータシステム２００において、多岐にわたるＩ／Ｏデバイス２３０が存在し得る。入力デバイスは、キーボード、マウス、トラックパッド、トラックボール、マイクロホン、およびドローイングタブレット（ｄｒａｗｉｎｇ ｔａｂｌｅｔ）を含む。出力デバイスは、ビデオディスプレイ、スピーカ、インクジェットプリンタ、レーザプリンタ、および昇華型（ｄｙｅ−ｓｕｂｌｉｍａｔｉｏｎ）プリンタを含む。Ｉ／Ｏデバイスは、コンピュータシステム２００のために、次のような大容量記憶装置をも提供し得る。すなわち、ハードディスクドライブ、３．５インチ、５．２５インチディスクまたはＺＩＰディスクを受け入れるためのフロッピー（登録商標）ディスクドライブ、ＣＤ−ＲＯＭドライブ、ＣＤ−Ｒ／ＲＷドライブ、ＤＶＤ−ＲＯＭドライブ、種々のフォーマットのテープドライブ、およびカリフォルニア州Ｌｏｓ ＡｌａｍｉｔｏｓのＴｗｉｎｔｅｃｈ Ｉｎｄｕｓｔｒｙ， Ｉｎｃ．によって製造されるＵＳＢフラッシュドライブの一連のデバイスなどのＵＳＢ記憶デバイス。
【００２６】
さらなる実施形態においては、Ｉ／Ｏデバイス２３０は、システムバス２２０と次のような外部通信バスとの間のブリッジであり得る。すなわち、ＵＳＢバス、Ａｐｐｌｅ Ｄｅｓｋｔｏｐバス、ＲＳ−２３２シリアル接続、ＳＣＳＩバス、ＦｉｒｅＷｉｒｅバス、ＦｉｒｅＷｉｒｅ８００バス、Ｅｔｈｅｒｎｅｔ（登録商標）バス、ＡｐｐｌｅＴａｌｋ（登録商標）バス、Ｇｉｇａｂｉｔ Ｅｔｈｅｒｎｅｔ（登録商標）バス、Ａｓｙｎｃｈｒｏｎｏｕｓ Ｔｒａｎｓｆｅｒ Ｍｏｄｅバス、ＨＩＰＰＩバス、Ｓｕｐｅｒ ＨＩＰＰＩバス、ＳｅｒｉａｌＰｌｕｓバス、ＳＣＩ／ＬＡＭＰバス、ＦｉｂｒｅＣｈａｎｎｅｌバス、またはＳｅｒｉａｌ Ａｔｔａｃｈｅｄ小型コンピュータシステムインターフェースバス。
【００２７】
図３Ａおよび３Ｂに示される種類の汎用デスクトップコンピュータは、システム資源に対するタスクおよびアクセスのスケジューリングを制御するオペレーティングシステムの制御下で一般的に稼動する。代表的なオペレーティングシステムは、数ある中で次のものを含む。すなわち、ワシントン州ＲｅｄｍｏｎｄのＭｉｃｒｏｓｏｆｔ Ｃｏｒｐ．によって製造されるＭＩＣＲＯＳＯＦＴ ＷＩＮＤＯＷＳ（登録商標）、カリフォルニア州ＣｕｐｅｒｔｉｎｏのＡｐｐｌｅ Ｃｏｍｐｕｔｅｒによって製造されるＭａｃＯＳ、ニューヨーク州ＡｒｍｏｎｋのＩｎｔｅｒｎａｔｉｏｎａｌ Ｂｕｓｉｎｅｓｓ Ｍａｃｈｉｎｅｓによって製造されるＯＳ／２、およびユタ州Ｓａｌｔ Ｌａｋｅ ＣｉｔｙのＣａｌｄｅｒａ Ｃｏｒｐ．によって配信される無料で利用可能なオペレーティングシステムであるＬｉｎｕｘ。
【００２８】
クライアントシステム２４と通信するデバイスがモバイルデバイスである実施形態について、クライアントデバイスは次のようなＪＡＶＡ（登録商標）使用可能な携帯電話であり得る。すなわち、イリノイ州ＳｃｈａｕｍｂｕｒｇのＭｏｔｏｒｏｌａ Ｃｏｒｐ．によって製造される、ｉ５０ｓｘ、ｉ５５ｓｒ、ｉ５８ｓｒ、ｉ８５ｓ、ｉ８８ｓ、ｉ９０ｃ、ｉ９５ｃｌ、またはｉｍ１１０００。日本の京都の京セラ株式会社によって製造される６０３５または７１３５。または韓国のソウルのＳａｍｓｕｎｇ Ｅｌｅｃｔｒｏｎｉｃｓ Ｃｏ．，Ｌｔｄ．によって製造されるｉ３００またはｉ３３０。クライアントシステムと通信するデバイス２４がモバイルである別の実施形態において、デバイスは、カリフォルニア州ＭｉｌｐｉｔａｓのｐａｌｍＯｎｅ，Ｉｎｃ．によって製造されるＴｕｎｇｓｔｅｎ Ｗ、ＶＩＩ、ＶＩＩｘ、ｉ７０５などのＰａｌｍオペレーティングシステムの制御下で稼動する携帯情報端末（ＰＤＡ）であり得る。さらなる実施形態においては、クライアントシステム４と通信するデバイス２４は、ＰｏｃｋｅｔＰＣオペレーティングシステムの制御下において稼動する、次のような携帯情報端末（ＰＤＡ）であり得る。すなわち、カリフォルニア州Ｐａｌｏ ＡｌｔｏのＨｅｗｌｅｔｔ−Ｐａｃｋａｒｄ Ｃｏｒｐｏｒａｔｉｏｎによって製造される、ｉＰＡＱ ４１５５、ｉＰＡＱ ５５５５、ｉＰＡＱ １９４５、ｉＰＡＱ ２２１５、およびｉＰＡＱ ４２５５。カリフォルニア州ＷａｌｎｕｔのＶｉｅｗＳｏｎｉｃによって製造されるＶｉｅｗＳｏｎｉｃ Ｖ３６。またはニューヨーク州Ｎｅｗ ＹｏｒｋのＴｏｓｈｉｂａ Ａｍｅｒｉｃａ，Ｉｎｃ．によって製造されるＴｏｓｈｉｂａ ＰｏｃｋｅｔＰＣ ｅ４０５。さらに別の実施形態において、クライアントシステム２４と通信するデバイスは、カリフォルニア州ＭｉｌｐｉｔａｓのｐａｌｍＯｎｅ，Ｉｎｃ．によって製造されるＴｒｅｏ １８０、Ｔｒｅｏ ２７０、またはＴｒｅｏ ６００などの組合わせ型ＰＤＡ／電話デバイスである。さらに別の実施形態において、クライアントシステム２４と通信するデバイスは、Ｍｏｔｏｒｏｌａ Ｃｏｒｐ．によって製造されるＭＰｘ２００などのＰｏｃｋｅｔＰＣオペレーティングシステムの制御下で稼動する携帯電話である。
【００２９】
図４Ａは、画像収集デバイスに向けられたコマンドを処理するための本発明の一実施形態におけるクライアントシステムによって辿られるステップのシーケンスのフローチャートである。シーケンスは、プレゼンテーションレベルプロトコルを使用して送信され画像収集デバイスに向けられたコマンドをクライアントシステム４０が受信するときに始まる（ステップ４００）。コマンドは、トウェインプロキシアプリケーションによってクライアントシステム上で受信され、画像収集デバイスに転送される（ステップ４０２）。コマンドは、受信されたコマンドに基づいて、結果としてトウェインＡＰＩ呼出しになり得る。コマンドは、受信されたコマンドに基づいて、デバイスドライバ呼出しをも必要とし得る。あるいは、コマンドは画像収集デバイス／プロセスに対して直接的に発行され得る。同様に、受信されたコマンドは、ユーザに示されているダイアログボックスの表示を抑制するための指示、および／または抑制されたダイアログボックスの代わりの第２のダイアログボックスの表示などの、画像収集デバイスに対する別のコマンドの発行を必要とし得る。その後、コマンドに対する応答は、画像収集デバイスから受信され（ステップ４０４）、トウェインアプリケーションをホストするサーバに送信される（ステップ４０６）。画像収集デバイスから受信された応答は、画像を表すデータであり得る。
【００３０】
本発明の説明的な実施形態は、クライアントシステムのためのセキュリティをも提供する。ユーザセッションにおいてトウェインアプリケーションから画像収集デバイスに送信されたコマンドは、実行前に肯定的なユーザ応答を受信することを必要とされ得る。たとえば、ＵＩを表示していないクライアントシステムにつながれた画像収集デバイスに対してコマンドが送信されているという状況は、コマンドが画像収集デバイスに対して送信されていることをクライアントシステムにおいて示すためのポップアップダイアログを必要とすることによって対処されることができる。クライアントシステムにおけるユーザからの肯定的な応答の後にのみ実際のコマンドが送信されるようなリダイレクタモジュールの構成は、セッションにおいて実行するアプリケーションによる画像収集デバイスの「隠された（ｓｔｅａｌｔｈ）」操作を防止する。
【００３１】
ステップの上述のシーケンスは単一のサーバからの単一のコマンドの受信に焦点を当てているが、当業者は、本発明の範囲の範囲内においてステップの代替的シーケンスが生じ得ることを認識する。たとえば、第２のコマンドはまた、クライアントに関連する画像収集デバイスに向けられたプレゼンテーションレベルプロトコルを使用して、第２のサーバから受信され得る。あるいは、サーバはクライアントに関連する第２の画像収集デバイスに向けられた第２のコマンドを発行し得る。同様に、クライアントシステムに関連する第２の画像収集デバイスは、プレゼンテーションレベルプロトコルを使用して第２のサーバからコマンドを受信し得る。
【００３２】
図４Ｂは、画像収集イベントを処理するための本発明の一実施形態におけるサーバシステムによって辿られるステップのシーケンスのフローチャートである。シーケンスは、サーバがネットワークを介してクライアントシステムから画像収集イベントを受信するときに始まる（ステップ４２０）。たとえば、スキャナ上でボタンが押されることは、イベントを生成する。画像収集デバイスイベントは、サーバ２０上の関連するトウェインアプリケーションプログラム２６および２８に提供される（ステップ４２２）。アプリケーションプログラムは、送信されたイベントに対して応答を生成し（ステップ４２４）、受信された応答をネットワークを介してクライアントシステムに送信する。
【００３３】
本明細書において論じられる本発明の実施形態の多くは、クライアントシステム上に常駐するトウェインフレームワークの残りを用いたユーザセッションの範囲内で実行するトウェインアプリケーションに関して論じられてきたが、他の実装も可能であることも留意されるべきである。たとえば、トウェインアプリケーションは、サーバ上で実行し得るが、クライアントシステム上で稼動するトウェインフレームワーク（ＤＳＭおよびＤＳ）の残りを用いたユーザセッションにおいては実行され得ない。二者間の通信は、プレゼンテーションレベルプロトコルを使用することなく実行され得る。同様に、本明細書に含まれる記載は、サーバ上のユーザセッションにおけるトウェインアプリケーションをホストしながらクライアントシステムに対してトウェインフレームワークのＤＳＭおよびＤＳ部分をリモーティングすることを論じてきたが、本発明の範囲の範囲内で他の実装が可能である。たとえば、ＤＳがクライアントシステムに対してリモーティングされた一方で、ＤＳＭはサーバ上にも位置し得る。そのような場合、ＤＳＭからＤＳへの呼出しは、サーバにおいてインタセプトされ得、クライアントシステムに送信され得る。
【００３４】
すでに示されたクライアントサーバアーキテクチャに加えて、本発明の説明的な実施形態は、「パススルー」アーキテクチャを可能にし、そこでは、クライアントシステムと通信する画像収集デバイスは、ネットワークを介してサーバ上のプロキシクライアントにアクセスするクライアントまたはシンクライアントである。たとえば、図５Ａは、サーバ５１０上で実行するプロキシクライアント５２０にアクセスするトウェインイメージングデバイスをホストするＷｉｎＣＥ使用可能なＰＤＡ５００を示す。プロキシクライアント５１０は、サーバ５５０と制御仮想チャネル５３０および通信仮想５４０を確立するＩＣＡクライアントであり得る。サーバ５５０は、セッションの範囲内において実行するアプリケーション５７０のインスタンスを用いたセッション５６０を含む。ＷｉｎＣＥ ＰＤＡ５００は、上記に概要を述べたメカニズムと整合性のある第２のサーバ５５０の中にマップされ得る。
【００３５】
同様に、図５Ｂは、プロキシクライアントおよびユーザセッションの両方が同一のサーバによってサポートされる代替的なアーキテクチャを示す。図５Ｂにおいて、画像収集デバイス６０５はクライアントデバイス６００と通信する。クライアントデバイス６００はサーバ６１０と通信する。サーバ６１０は、プロキシクライアント６２０およびユーザセッション６３０の両方を含む。ユーザセッション６３０は、実行中のアプリケーション６４０のインスタンスを含む。画像収集デバイス６０５は、プロキシクライアント６２０を介してサーバ６１０上のユーザセッション６３０の中にマップされ得る。当業者は、本発明の範囲の範囲内において追加の実装および代替的なアーキテクチャも可能であることを認識する。
【００３６】
本発明は、一つ以上の製品の上または中において具体化される一つ以上のコンピュータ可読プログラムとして提供され得る。製品は、フロッピー（登録商標）ディスク、ハードディスク、コンパクトディスク、デジタル汎用ディスク、フラッシュメモリカード、ＰＲＯＭ、ＲＡＭ、ＲＯＭ、または磁気テープであり得る。一般的に、コンピュータ可読プログラムは任意のプログラミング言語において実装され得る。使用されることのできる言語のいくつかの例は、Ｃ、Ｃ＋＋、Ｃ＃、またはＪＡＶＡ（登録商標）を含む。ソフトウェアプログラムは、オブジェクトコードとして一つ以上の製品の上または中において格納され得る。
【００３７】
本発明は特定の好ましい実施形態に関して示され記述された一方で、添付の特許請求の範囲によって定義される本発明の精神および範囲から逸脱することなく、形態および詳細において種々の変更がなされ得ることが当業者によって理解されるべきである。
【図面の簡単な説明】
【００３８】
【図１】図１（従来技術）は、従来のトウェインアークテクチャのブロック図を示す。
【図２Ａ】図２Ａは、本発明の説明的な実施形態を実行するために適切な環境を示す。
【図２Ｂ】図２Ｂは、図２Ａの環境をより詳細に示す。
【図３Ａ】図３Ａは、本発明と関連して有用なコンピュータの実施形態を示すブロック図である。
【図３Ｂ】図３Ｂは、本発明と関連して有用なコンピュータの実施形態を示すブロック図である。
【図４Ａ】図４Ａは、画像収集デバイスに向けられたコマンドを処理するための本発明の実施形態におけるクライアントシステムによって辿られるステップのシーケンスのフローチャートである。
【図４Ｂ】図４Ｂは、画像収集イベントを処理するための本発明の実施形態におけるサーバシステムによって辿られるステップのシーケンスのフローチャートである。
【図５Ａ】図５Ａは、パススルー環境にけるプロキシクライアントの使用を示す本発明の実施形態のブロック図である。
【図５Ｂ】図５Ｂは、パススルー環境にけるプロキシクライアントの使用を示す本発明の別の実施形態のブロック図であり、プロキシクライアントはユーザセッションをホストするサーバ上に位置させられる。
【技術分野】
【０００１】
本発明の説明的な実施形態は、概ね画像データ処理に関し、より具体的には、サーバ上でホストされるユーザセッションから、トウェイン（Ｔｗａｉｎ）準拠の画像収集デバイスと通信するクライアントシステムへの、アプリケーションのリモーティングに関する。
【背景技術】
【０００２】
トウェインは、イメージングアプリケーションのための標準的なフレームワークである。アプリケーションは、トウェイン準拠のドキュメントスキャナ、デジタルカメラ、および画像データベースを制御するために、周知のＡＰＩを呼び出す。トウェインデバイスとともに使用されるベンダー供給のハードウェアドライバは、インターフェースおよび能力の周知のセットに準拠する。トウェインアーキテクチャについての標準的なフレームワークは、ワシントン州ＲｅｄｍｏｎｄのＭｉｃｒｏｓｏｆｔ ＣｏｒｐｏｒａｔｉｏｎからのＷＯＲＤなどのトウェインアプリケーション、または写真編集アプリケーションを含む。アークテクチャは、ベンダー供給のハードウェアドライバを制御するアプリケーションによって呼び出されるＡＰＩを供給する構成要素であるデータソースマネジャー（ＤＳＭ）をも含む。ワシントン州ＲｅｄｍｏｎｄのＭｉｃｒｏｓｏｆｔ ＣｏｒｐｏｒａｔｉｏｎからのＷＩＮＤＯＷＳ（登録商標）オペレーティングシステムについて、データマネジャーは、ＷＩＮＤＯＷＳ（登録商標）とともに出荷されるＤＬＬ ｔｗａｉｎ＿３２．ｄｌｌにおいて見いだされる。構成要素は一般的であり、基礎を成す画像ハードウェアの知識を有しない。標準的なトウェインアーキテクチャにさらに含まれるものは、特定のデバイスのためのベンダー供給のドライバであるデータソース（ＤＳ）である。データソースは、ＵＳＢ、ＦＩＲＥＷＩＲＥ、Ｐａｒａｌｌｅｌ、ＳＣＳＩ、ＩＲ、ＢＬＵＥＴＯＯＴＨ、ＩＥＥＥ １３９４プロトコル、Ｗｉ−Ｆｉプロトコル、または他のワイヤレスプロトコルなどのいくかのプロトコルのうちの一つを使用して、画像収集デバイスにデータを送信する（ｔａｌｋ ｔｏ）ことを担う。イメージングデバイスは、スキャナ、デジタルカメラ、またはソフトウェアアプリケーションであり得る。
【０００３】
図１（従来技術）は、従来のトウェインアーキテクチャを示す。従来のトウェインアーキテクチャは、接続されたモニター４とともに、ユーザ６によって利用されるコンピュータ２を含む。コンピュータ２は、写真編集アプリケーションなどのトウェインアプリケーション８を含む。トウェインアプリケーション８は、データソースマネジャー１０に対して関数呼出しを行なう。データソースマネジャー１０は、アプリケーションがベンダーデータソース１２にアクセスし得るためのＡＰＩ、およびコンピュータ２と通信する画像収集デバイスの製造およびモデリングするためのベンダー供給のハードウェアドライバを提供する。示されるトウェインアーキテクチャは、コンピュータへのＵＳＢ１４インターフェースを含む。トウェイン準拠のスキャナ１６は、ＵＳＢインターフェース１４を介してコンピュータシステムにつなげられる。
【０００４】
残念ながら、トウェインアプリケーションによって利用されるトウェイン準拠のデバイスを制御するための従来の技術は、分散型のマルチユーザ、マルチセッション環境においては、特に首尾よく作用するというわけではない。たとえば、遠隔クライアントシステムについて複数のユーザセッションをホストするサーバは、各トウェイン準拠のデバイスについて固有のベンダー特有のハードウェアドライバとともにロードされなければならない。単一のユーザについての単一のデバイスを制御するためには問題ではない一方で、複数のデバイスはサーバが複数のドライバを含むことを必要とする。さらに、ユーザセッションをサポートするサーバについて、仮想チャネルはセッションごとに一つのアプリケーションをサポートする。このことは、複数のトウェイン準拠のデバイスが同一のセッションの範囲内でサポートされることを妨げ、同時にセッションにおいて二つ以上のトウェインアプリケーションを使用することを妨げる。
【発明の開示】
【課題を解決するための手段】
【０００５】
（発明の概要）
本発明の説明的な実施形態は、ユーザセッションの範囲内におけるトウェイン関数呼出しをクライアントシステムに対してリモーティングするメカニズムを提供する。サーバ上のトウェインアプリケーションによって行なわれたトウェイン関数呼出しをフックすることによって、トウェイン関数呼出しは、クライアントシステムへの仮想接続を介してリモーティングされ得る。サーバベースのトウェインアプリケーションに対応するプロキシアプリケーションは、クライアントシステム上で作成される。プロキシアプリケーションは、サーバと通信し、トウェインフレームワークの残りに対して適切な関数呼出しを行なう。プロキシアプリケーションの使用は、複数のアプリケーションおよびデバイスが同時にサポートされることを可能にする。仮想接続を介して送信されたメッセージは、送信前にフィルタリングされ、それにより必要とされる通信トラフィックの量を制限する。マルチプレクサおよびデマルチプレクサは、仮想チャネル上の帯域幅を効率的に使用するために利用される。本発明はさらに、仮想チャネルを介した送信の前に画像データを圧縮する。
【０００６】
一実施形態において、クライアントに関連する画像収集装置を制御するための方法は、プレゼンテーションレベルプロトコルを使用してサーバと通信するクライアントを提供するステップを含む。クライアントは、サーバ上で実行するアプリケーションに関連するプロキシアプリケーションを実行している。方法は、プレゼンテーションレベルプロトコルを使用してネットワークを介してサーバから、クライアントに関連する画像収集デバイスに向けられたコマンドを、プロキシアプリケーションにおいて受信するステップをさらに含む。方法は、受信されたコマンドを画像収集デバイスに対して発行するステップをさらに含む。方法は、発行されたコマンドへの応答を画像収集デバイスから受信するステップと、受信された応答を次にプレゼンテーションレベルプロトコルを使用してネットワークを介してサーバに送信するステップとをさらに含む。
【０００７】
別の実施形態において、トウェインクライアント環境においてクライアントに関連する画像収集デバイスを遠隔に制御するための方法は、ネットワークを介してクライアントから画像収集イベントを受信するステップを含む。方法は、受信されたイベントをイベントに関連するアプリケーションプログラムに提供するステップをさらに含む。方法は、送信されたイベントに対する応答をアプリケーションプログラムから受信するステップと、受信された応答を次にネットワークを介してクライアントに送信するステップとをさらに含む。
【０００８】
一実施形態において、クライアントと通信する画像収集デバイスを制御するための方法は、クライアントと通信する画像収集デバイスに向けられたコマンドをサーバから受信するステップを含む。方法はまた、クライアントと通信する画像収集デバイスに対して、受信されたコマンドに基づいてＴＷＡＩＮ ＡＰＩ呼出しを発行するステップと、発行されたコマンドに対する応答を画像収集デバイスから受信するステップとを含む。方法はまた、受信された応答をサーバに送信する。
【発明を実施するための最良の形態】
【０００９】
本発明のこれらのおよび他の局面は、以下の詳細な説明および添付の図面から容易に明らかになり、それらは説明することを意図したものであり本発明を限定することを意図したものではない。
【００１０】
本発明の説明的な実施形態は、クライアントシステムと通信する複数のトウェイン準拠デバイス、および／またはユーザセッションにおいて実行する複数のトウェインアプリケーションを、ユーザセッションがサポートすることを可能にする。ユーザセッションにおいて実行するトウェインアプリケーションからトウェイン関数呼出しをフックすることにより、関数呼出しは、プレゼンテーションレベルプロトコルを使用して、処理のためにクライアントシステム上のプロキシアプリケーションにリダイレクトされ得る。プロキシアプリケーションは、クライアントシステム上で作成され、サーバ上のユーザセッションにおいて実行する各アプリケーションに対応する。クライアントシステム４０上のメッセージは、必須の通信のみをサーバに送信するようにフィルタリングされる。
【００１１】
図２Ａは、本発明の一実施形態を実行するために適切な環境を示す。サーバ２０は、ネットワーク３０を介してクライアントシステム４０に接続される。サーバ２０は、一つ以上のユーザセッション２２および２４をホストする。ユーザセッションは、トウェイン準拠アプリケーション２６および２８の実行中のインスタンスを含み得る。トウェインアプリケーション２６および２８からのトウェイン関数呼出しは、プレゼンテーションレベルプロトコルを介して、クライアントシステム４０上の対応するトウェインプロキシプロセス４２および４４に送信される。スキャナＡ５０およびスキャナＢ６０は、クライアントシステム４０と通信し、サーバ２０上のユーザセッション２４において実行するアプリケーション２６および２８から発信されかつクライアントシステムにおいて処理されるコマンドによって制御される。サーバ２０とクライアントシステム４０との間の通信のメカニクス（ｍｅｃｈａｎｉｃｓ）は、以下の図２Ｂにおいてより詳細に探求される。
【００１２】
図２Ｂは、図２Ａの環境をより詳細に示す。サーバ２０はユーザセッション２４をホストする。ユーザセッション２４は、それぞれリダイレクタモジュール７０および７２と連絡を取るトウェインアプリケーション２６および２８を含む。リダイレクタモジュール７０および７２は、エントリポイントをトウェイン＿３２．ｄｌｌの中に（エントリポイントをＤＳＭの中に）フックするサーバ側フックＤＬＬである。リダイレクタモジュール７０および７２は、トウェインアプリケーション２６および２８からのすべてのトウェイン呼出しをインタセプトし、その呼出しをクライアントシステム４０に転送する。リダイレクタモジュール７０および７２はまた、ＪＰＥＧ圧縮を使用して圧縮されることをリクエストされた画像を復元する（ｕｎｃｏｍｐｒｅｓｓ）。リダイレクタモジュール７０および７２は、セッションマネジャー７４によってホストされるトウェインマルチプレクサ７６と連絡を取る。ＩＣＡアーキテクチャにおいて、セッションマネジャー７４はＷＦＳｈｅｌｌ Ｐｒｏｃｅｓｓである。
【００１３】
トウェインマルチプレクサ７６は、セッションマネジャー７４において稼動するサーバ側仮想チャネルモジュールであり、クライアントとサーバとの間のトウェイン通信を管理するために使用される。トウェインマルチプレクサ７６は、セッション２４において実行するトウェインアプリケーションに関連するリダイレクタモジュール７０および７２からペイロードを受信する。トウェインマルチプレクサ７６は、仮想チャネル３２についてのサイズ制限に従って、ペイロードをより小さなパケットのシーケンスに分割する。次にパケットは、クライアントシステムへの移行のために仮想チャネルに書き込まれる。トウェインマルチプレクサ７６は、リクエストをクライアントシステム４０に伝え、クライアントから受信された応答を返す。トウェインマルチプレクサ７６は、リクエストと応答とが一致するかどうかを知らず、応答を待たない。したがって、トウェインマルチプレクサ７６は、なんらかの応答を受信する前に、異なるトウェインアプリケーション２６および２８からのいくつかのリクエストを受信および転送し得る。トウェインマルチプレクサ７６はまた、入ってくるパケットをペイロードに組み立て、次にペイロードは適切なリダイレクタモジュール７０および７２にルーティングされる。
【００１４】
仮想チャネル３２は、ネットワーク３０を介して、パケットをクライアントシステム４０に移送する。パケットは、厳密に順序付けられたシーケンスにおいて仮想チャネル３２に送信される。トウェインデマルチプレクサ（デマックス（ｄｅｍｕｘ））８０は、仮想チャネル３２を介して、クライアントシステム上のパケットを受信する。トウェインデマルチプレクサ８０は、クライアントシステム上でアーキテクチャ４１をサポートするプレゼンテーションレベルプロトコルにプラグインするクライアント側仮想チャネルドライバである（たとえばデマックスはＩＣＡクライアントにプラグインする）。トウェインデマルチプレクサ８０は、トウェインリクエストを、厳密に順序付けられたパケットのシーケンスとして受信する。トウェインデマルチプレクサ８０は、入ってくるパケットをペイロードに組み立てる。入ってくるパケットの受信中にエラーチェックが実行され得る。ペイロードが完全に受信されると、トウェインデマルチプレクサ８０は、ペイロードをプロキシアプリケーション４３および４５に転送する。正しいプロキシアプリケーション４３および４５は、ペイロードにおけるフィールドを検査することによって識別される。クライアントシステム上のトウェインデマックス８０は、登録（ｒｅｇｉｓｔｅｒ）されたプロキシアプリケーション４３および４５のリスティングを保持する。プロキシアプリケーション４３および４５が新しいプロキシアプリケーションであり、それゆえに登録されていない場合、トウェインデマックス８０はプロキシアプリケーションを作成する。
【００１５】
プロキシアプリケーション４３および４５は、クライアントシステム４０上のコンテナプロセス５１および５３によってホストされ、サーバ上のトウェインアプリケーション２６および２８に対応する。プロキシアプリケーション４３および４５は、トウェインデマルチプレクサを用いた登録の後、トウェインデマルチプレクサ８０から受信されトウェインアプリケーション２６および２８によって発信されたコマンドを処理する。プロキシアプリケーション４３および４５は、クライアントシステム４０と通信中のスキャナ５０および６０についてベンダー特有の（ｖｅｎｄｏｒ−ｓｐｅｃｉｆｉｃ）ドライバ９４および９６を制御するために、ＤＳＭ９０および９２に対してＡＰＩ呼出しを行なう。プロキシアプリケーション４３および４５は、コンテナプロセスとして実行するので、対応するセキュリティの発行なしに、動的なリンクされたライブラリを実行するコンテクストを提供する。プロキシアプリケーションはまた、データソース９４および９６によって生成されたメッセージを受信する。
【００１６】
データソースＵＩ９４および９６が使用可能にされると（たとえばスキャンするダイアログボックス）、プロキシアプリケーション４３および４５は、受信されるすべてのメッセージを処理することによって、もともとのトウェインアプリケーションをシミュレートする。たとえば、ＷＩＮＤＯＷＳ（登録商標）環境において、プロキシアプリケーションは、画像収集デバイス上でボタンが押されたことを示すメッセージなどの、受信されたすべてのＷＩＮＤＯＷＳ（登録商標）メッセージについて、ＭＳＧ＿ＰＲＯＣＥＳＳＥＶＥＮＴコマンドを呼び出し得る。メッセージがトウェインによって所有されない場合、そのメッセージが対象とするアプリケーションがメッセージを正常に処理する。しかし、メッセージがトウェイン通知である場合、通知ペイロードは、サーバ２０上のリダイレクタモジュール７０および７２に転送されて次にトウェインアプリケーション２６および２８上に転送される場所から、トウェインデマックス８０へと送信される。次にトウェインアプリケーション２６および２８は、通知に応答して新しいコマンドを発行し得る。この場合、トウェインコマンドはクライアントシステムに送信される。
【００１７】
トウェイン通知であり得るメッセージのみが仮想チャネルを介して転送されるので、クライアント側におけるメッセージの初期スクリーニングは、ネットワークトラフィックを減少させる。ネットワークトラフィックは、送信前におけるビットマップのＪＰＧへの圧縮によっても減少され得る。クライアントシステム４０と通信する画像収集デバイスによって収集された画像データは、サーバ２０への送信前に所定のルールに基づいて圧縮され得る。たとえば、ピクセル位置あたり２ビット以上を有する画像データは送信前に圧縮され得る一方で、ピクセル位置あたり１ビットの比率を有する画像データは圧縮なしに送信され得る。同様に、画像データは、サーバに送信されるサイズが最も小さいアルゴリズムの出力を用いた二つ以上の圧縮アルゴリズムを用いて圧縮され得る。圧縮はプロキシアプリケーション４３および４５において行なわれ、解凍（ｄｅｃｏｍｐｒｅｓｓｉｏｎ）はトウェインリダイレクタモジュール７０および７２において行なわれる。
【００１８】
当業者は、ユーザがクライアントシステムを介してアクセスするサーバ上にセッションを作成するために使用されるサーバ２０およびクライアントシステム４０における構成要素が、展開されるアーキテクチャに依存して変化することを認識する。例示的なプレゼンテーションレベルサポーティングアーキテクチャは、フロリダ州Ｆｏｒｔ ＬａｕｄｅｒｄａｌｅのＣｉｔｒｉｘ Ｓｙｓｔｅｍｓ Ｉｎｃ．からのＩｎｄｅｐｅｎｄｅｎｔ Ｃｏｍｐｕｔｉｎｇ Ａｒｃｈｉｔｅｃｔｕｒｅ（ＩＣＡ）、ワシントン州ＲｅｄｍｏｎｄのＭｉｃｒｏｓｏｆｔ ＣｏｒｐｏｒａｔｉｏｎからのＲｅｍｏｔｅ Ｄｅｓｋｔｏｐ Ｐｒｏｔｏｃｏｌ（ＲＤＰ）、およびＸ−Ｏｐｅｎ ＣｏｎｓｏｒｔｉｕｍからのＸ−Ｗｉｎｄｏｗ Ｐｒｏｔｏｃｏｌを含む。たとえばＩＣＡアーキテクチャにおいて、クライアント側のプレゼンテーションレベルサポーティングアーキテクチャ４１はＩＣＡクライアントであり、サーバ２０はサーバがホストするユーザセッションを作成および保持するためにメタフレームプレゼンテーションサーバ（ＭＥＴＡＦＲＡＭＥ ＰＲＥＳＥＮＴＡＴＩＯＮ ＳＥＲＶＥＲ）を展開する。ＲＤＰアーキテクチャ、Ｘ−Ｏｐｅｎアーキテクチャ、または他のプレゼンテーションレベルプロトコルサポーティングアーキテクチャからの同様の構成要素もまた、本発明の範囲の範囲内において展開され得る。
【００１９】
多くの実施形態において、クライアントシステム４０およびサーバ２０は、カリフォルニア州Ｐａｌｏ ＡｌｔｏのＨｅｗｌｅｔｔ−Ｐａｃｋａｒｄ Ｃｏｒｐｏｒａｔｉｏｎ、およびテキサス州Ｒｏｕｎｄ ＲｏｃｋのＤｅｌｌ Ｃｏｒｐｏｒａｔｉｏｎによって製造される種類の、パーソナルコンピュータまたはコンピュータサーバとして提供される。図３Ａおよび３Ｂは、クライアントシステム２０およびサーバ４０として有用な代表的なコンピュータ２００のブロック図を示す。図３Ａおよび３Ｂに示されるように、各コンピュータ２００は、中央処理ユニット２０２および主メモリユニット２０４を含む。各コンピュータ２００は、一つ以上の入力／出力デバイス２３０ａ〜２３０ｎ（一般的に参照番号２３０を使用して参照される）、および中央処理ユニット２０２と通信するキャッシュメモリ２４０などの他のオプション的要素をも含み得る。
【００２０】
中央処理ユニット２０２は、主メモリユニット２０４から取り出された命令に対して応答および処理をする任意の論理回路網である。多くの実施形態において、中央処理ユニットは次のようなマイクロプロセッサによって提供される。すなわち、カリフォルニア州Ｍｏｕｎｔａｉｎ ＶｉｅｗのＩｎｔｅｌ Ｃｏｒｐｏｒａｔｉｏｎによって製造される、８０８８、８０２８６、８０３８６、８０４８６、Ｐｅｎｔｉｕｍ（登録商標）、Ｐｅｎｔｉｕｍ（登録商標）Ｐｒｏ、Ｐｅｎｔｉｕｍ（登録商標）ＩＩ、Ｃｅｌｅｒｏｎ、またはＸｅｏｎプロセッサ。イリノイ州ＳｃｈａｕｍｂｕｒｇのＭｏｔｏｒｏｌａ Ｃｏｒｐｏｒａｔｉｏｎによって製造される、６８０００、６８０１０、６８０２０、６８０３０、６８０４０、ＰｏｗｅｒＰＣ６０１、ＰｏｗｅｒＰＣ６０４、ＰｏｗｅｒＰＣ６０４ｅ、ＭＰＣ６０３ｅ、ＭＰＣ６０３ｅｉ、ＭＰＣ６０３ｅｖ、ＭＰＣ６０３ｒ、ＭＰＣ６０３ｐ、ＭＰＣ７４０、ＭＰＣ７４５、ＭＰＣ７５０、ＭＰＣ７５５、ＭＰＣ７４００、ＭＰＣ７４１０、ＭＰＣ７４４１、ＭＰＣ７４４５、ＭＰＣ７４４７、ＭＰＣ７４５０、ＭＰＣ７４５１、ＭＰＣ７４５５、またはＭＰＣ７４５７プロセッサ。カリフォルニア州Ｓａｎｔａ ＣｌａｒａのＴｒａｎｓｍｅｔａ Ｃｏｒｐｏｒａｔｉｏｎによって製造される、Ｃｒｕｓｏｅ ＴＭ５８００、Ｃｒｕｓｏｅ ＴＭ５６００、Ｃｒｕｓｏｅ ＴＭ５５００、Ｃｒｕｓｏｅ ＴＭ５４００、Ｅｆｆｉｃｅｏｎ ＴＭ８６００、Ｅｆｆｉｃｅｏｎ ＴＭ８３００、またはＥｆｆｉｃｅｏｎ ＴＭ８６２０プロセッサ。ニューヨーク州Ｗｈｉｔｅ ＰｌａｉｎｓのＩｎｔｅｒｎａｔｉｏｎａｌ Ｂｕｓｉｎｅｓｓ Ｍａｃｈｉｎｅｓによって製造される、ＲＳ／６０００プロセッサ、ＲＳ６４、ＲＳ ６４ ＩＩ、Ｐ２ＳＣ、ＰＯＷＥＲ３、ＲＳ６４ ＩＩＩ、ＰＯＷＥＲ３−ＩＩ、ＲＳ ６４ ＩＶ、ＰＯＷＥＲ４、ＰＯＷＥＲ４＋、ＰＯＷＥＲ５、またはＰＯＷＥＲ６プロセッサ。またはカリフォルニア州ＳｕｎｎｙｖａｌｅのＡｄｖａｎｃｅｄ Ｍｉｃｒｏ Ｄｅｖｉｃｅｓによって製造される、ＡＭＤ Ｏｐｔｅｒｏｎ、ＡＭＤ Ａｔｈａｌｏｎ ６４ ＦＸ、ＡＭＤ Ａｔｈａｌｏｎ、またはＡＭＤ Ｄｕｒｏｎプロセッサ。
【００２１】
主メモリユニット２０４は、データを格納する能力があり、任意の記憶位置がマイクロプロセッサ２０２によって直接的にアクセスされることが可能な、次のような一つ以上のメモリチップであり得る。すなわち、スタティックランダムアクセスメモリ（ＳＲＡＭ）、Ｂｕｒｓｔ ＳＲＡＭまたはＳｙｎｃｈＢｕｒｓｔ ＳＲＡＭ（ＢＳＲＡＭ）、ダイナミックランダムアクセスメモリ（ＤＲＡＭ）、Ｆａｓｔ Ｐａｇｅ Ｍｏｄｅ ＤＲＡＭ（ＦＰＭ ＤＲＡＭ）、Ｅｎｈａｎｃｅｄ ＤＲＡＭ（ＥＤＲＡＭ）、Ｅｘｔｅｎｄｅｄ Ｄａｔａ Ｏｕｔｐｕｔ ＲＡＭ （ＥＤＯ ＲＡＭ）、Ｅｘｔｅｎｄｅｄ Ｄａｔａ Ｏｕｔｐｕｔ ＤＲＡＭ（ＥＤＯ ＤＲＡＭ）、Ｂｕｒｓｔ Ｅｘｔｅｎｄｅｄ Ｄａｔａ Ｏｕｔｐｕｔ ＤＲＡＭ（ＢＥＤＯ ＤＲＡＭ）、Ｅｎｈａｎｃｅｄ ＤＲＡＭ（ＥＤＲＡＭ）、同期式ＤＲＡＭ（ＳＤＲＡＭ）、ＪＥＤＥＣ ＳＲＡＭ、ＰＣ１００ ＳＤＲＡＭ、Ｄｏｕｂｌｅ Ｄａｔａ Ｒａｔｅ ＳＤＲＡＭ（ＤＤＲ ＳＤＲＡＭ）、Ｅｎｈａｎｃｅｄ ＳＤＲＡＭ（ＥＳＤＲＡＭ）、ＳｙｎｃＬｉｎｋ ＤＲＡＭ（ＳＬＤＲＡＭ）、Ｄｉｒｅｃｔ Ｒａｍｂｕｓ ＤＲＡＭ（ＤＲＤＲＡＭ）、または強誘電体ＲＡＭ（ＦＲＡＭ）。
【００２２】
図３Ａに示される実施形態において、プロセッサ２０２はシステムバス２２０（より詳細に以下に記述される）を介して主メモリ２０４と通信する。図３Ｂは、プロセッサがメモリポートを介して主メモリ２０４と直接的に通信するコンピュータ２００の実施形態を示す。たとえば、図３Ｂにおいて、主メモリ２０４はＤＲＤＲＡＭであり得る。
【００２３】
図３Ａおよび３Ｂは、主プロセッサ２０２が、「バックサイド」バスと呼ばれることもある二次バスを介してキャッシュメモリ２４０と直接的に通信する実施形態を示す。他の実施形態において、主プロセッサ２０２はシステムバス２２０を使用してキャッシュメモリ２４０と通信する。キャッシュメモリ２４０は、一般的に主メモリ２０４よりも速い応答時間を有し、一般的にＳＲＡＭ、ＢＳＲＡＭ、またはＥＤＲＡＭによって提供される。
【００２４】
図３Ａに示される実施形態において、プロセッサ２０２はローカルシステムバスを介して種々のＩ／Ｏデバイス２３０と通信する。ＶＥＳＡ ＶＬバス、ＩＳＡバス、ＥＩＳＡバス、ＭｉｃｒｏＣｈａｎｎｅｌＡｒｃｈｉｔｅｃｔｕｒｅ（ＭＣＡ）バス、ＰＣＩバス、ＰＣＩ−Ｘバス、ＰＣＩ−Ｅｘｐｒｅｓｓバス、またはＮｕバスを含む種々のバスが、中央処理ユニット２０２をＩ／Ｏデバイス２３０に接続するために使用され得る。Ｉ／Ｏデバイスがビデオディスプレイである実施形態について、プロセッサ２０２はディスプレイと通信するためにＡｄｖａｎｃｅｄ Ｇｒａｐｈｉｃｓ Ｐｏｒｔ（ＡＧＰ）を使用し得る。図３Ｂは、主プロセッサ２０２がＨｙｐｅｒＴｒａｎｓｐｏｒｔ、Ｒａｐｉｄ Ｉ／Ｏ、またはＩｎｆｉｎｉＢａｎｄを介して、Ｉ／Ｏデバイス２３０ｂと直接的に通信するコンピュータ２００の実施形態を示す。図３Ｂはまた、ローカルバスおよび直接通信が混合された実施形態を示す。すなわち、プロセッサ２０２は、Ｉ／Ｏデバイス２３０ｂと直接的に通信しながら、ローカル相互接続バスを使用してＩ／Ｏデバイス２３０ａと通信する。
【００２５】
コンピュータシステム２００において、多岐にわたるＩ／Ｏデバイス２３０が存在し得る。入力デバイスは、キーボード、マウス、トラックパッド、トラックボール、マイクロホン、およびドローイングタブレット（ｄｒａｗｉｎｇ ｔａｂｌｅｔ）を含む。出力デバイスは、ビデオディスプレイ、スピーカ、インクジェットプリンタ、レーザプリンタ、および昇華型（ｄｙｅ−ｓｕｂｌｉｍａｔｉｏｎ）プリンタを含む。Ｉ／Ｏデバイスは、コンピュータシステム２００のために、次のような大容量記憶装置をも提供し得る。すなわち、ハードディスクドライブ、３．５インチ、５．２５インチディスクまたはＺＩＰディスクを受け入れるためのフロッピー（登録商標）ディスクドライブ、ＣＤ−ＲＯＭドライブ、ＣＤ−Ｒ／ＲＷドライブ、ＤＶＤ−ＲＯＭドライブ、種々のフォーマットのテープドライブ、およびカリフォルニア州Ｌｏｓ ＡｌａｍｉｔｏｓのＴｗｉｎｔｅｃｈ Ｉｎｄｕｓｔｒｙ， Ｉｎｃ．によって製造されるＵＳＢフラッシュドライブの一連のデバイスなどのＵＳＢ記憶デバイス。
【００２６】
さらなる実施形態においては、Ｉ／Ｏデバイス２３０は、システムバス２２０と次のような外部通信バスとの間のブリッジであり得る。すなわち、ＵＳＢバス、Ａｐｐｌｅ Ｄｅｓｋｔｏｐバス、ＲＳ−２３２シリアル接続、ＳＣＳＩバス、ＦｉｒｅＷｉｒｅバス、ＦｉｒｅＷｉｒｅ８００バス、Ｅｔｈｅｒｎｅｔ（登録商標）バス、ＡｐｐｌｅＴａｌｋ（登録商標）バス、Ｇｉｇａｂｉｔ Ｅｔｈｅｒｎｅｔ（登録商標）バス、Ａｓｙｎｃｈｒｏｎｏｕｓ Ｔｒａｎｓｆｅｒ Ｍｏｄｅバス、ＨＩＰＰＩバス、Ｓｕｐｅｒ ＨＩＰＰＩバス、ＳｅｒｉａｌＰｌｕｓバス、ＳＣＩ／ＬＡＭＰバス、ＦｉｂｒｅＣｈａｎｎｅｌバス、またはＳｅｒｉａｌ Ａｔｔａｃｈｅｄ小型コンピュータシステムインターフェースバス。
【００２７】
図３Ａおよび３Ｂに示される種類の汎用デスクトップコンピュータは、システム資源に対するタスクおよびアクセスのスケジューリングを制御するオペレーティングシステムの制御下で一般的に稼動する。代表的なオペレーティングシステムは、数ある中で次のものを含む。すなわち、ワシントン州ＲｅｄｍｏｎｄのＭｉｃｒｏｓｏｆｔ Ｃｏｒｐ．によって製造されるＭＩＣＲＯＳＯＦＴ ＷＩＮＤＯＷＳ（登録商標）、カリフォルニア州ＣｕｐｅｒｔｉｎｏのＡｐｐｌｅ Ｃｏｍｐｕｔｅｒによって製造されるＭａｃＯＳ、ニューヨーク州ＡｒｍｏｎｋのＩｎｔｅｒｎａｔｉｏｎａｌ Ｂｕｓｉｎｅｓｓ Ｍａｃｈｉｎｅｓによって製造されるＯＳ／２、およびユタ州Ｓａｌｔ Ｌａｋｅ ＣｉｔｙのＣａｌｄｅｒａ Ｃｏｒｐ．によって配信される無料で利用可能なオペレーティングシステムであるＬｉｎｕｘ。
【００２８】
クライアントシステム２４と通信するデバイスがモバイルデバイスである実施形態について、クライアントデバイスは次のようなＪＡＶＡ（登録商標）使用可能な携帯電話であり得る。すなわち、イリノイ州ＳｃｈａｕｍｂｕｒｇのＭｏｔｏｒｏｌａ Ｃｏｒｐ．によって製造される、ｉ５０ｓｘ、ｉ５５ｓｒ、ｉ５８ｓｒ、ｉ８５ｓ、ｉ８８ｓ、ｉ９０ｃ、ｉ９５ｃｌ、またはｉｍ１１０００。日本の京都の京セラ株式会社によって製造される６０３５または７１３５。または韓国のソウルのＳａｍｓｕｎｇ Ｅｌｅｃｔｒｏｎｉｃｓ Ｃｏ．，Ｌｔｄ．によって製造されるｉ３００またはｉ３３０。クライアントシステムと通信するデバイス２４がモバイルである別の実施形態において、デバイスは、カリフォルニア州ＭｉｌｐｉｔａｓのｐａｌｍＯｎｅ，Ｉｎｃ．によって製造されるＴｕｎｇｓｔｅｎ Ｗ、ＶＩＩ、ＶＩＩｘ、ｉ７０５などのＰａｌｍオペレーティングシステムの制御下で稼動する携帯情報端末（ＰＤＡ）であり得る。さらなる実施形態においては、クライアントシステム４と通信するデバイス２４は、ＰｏｃｋｅｔＰＣオペレーティングシステムの制御下において稼動する、次のような携帯情報端末（ＰＤＡ）であり得る。すなわち、カリフォルニア州Ｐａｌｏ ＡｌｔｏのＨｅｗｌｅｔｔ−Ｐａｃｋａｒｄ Ｃｏｒｐｏｒａｔｉｏｎによって製造される、ｉＰＡＱ ４１５５、ｉＰＡＱ ５５５５、ｉＰＡＱ １９４５、ｉＰＡＱ ２２１５、およびｉＰＡＱ ４２５５。カリフォルニア州ＷａｌｎｕｔのＶｉｅｗＳｏｎｉｃによって製造されるＶｉｅｗＳｏｎｉｃ Ｖ３６。またはニューヨーク州Ｎｅｗ ＹｏｒｋのＴｏｓｈｉｂａ Ａｍｅｒｉｃａ，Ｉｎｃ．によって製造されるＴｏｓｈｉｂａ ＰｏｃｋｅｔＰＣ ｅ４０５。さらに別の実施形態において、クライアントシステム２４と通信するデバイスは、カリフォルニア州ＭｉｌｐｉｔａｓのｐａｌｍＯｎｅ，Ｉｎｃ．によって製造されるＴｒｅｏ １８０、Ｔｒｅｏ ２７０、またはＴｒｅｏ ６００などの組合わせ型ＰＤＡ／電話デバイスである。さらに別の実施形態において、クライアントシステム２４と通信するデバイスは、Ｍｏｔｏｒｏｌａ Ｃｏｒｐ．によって製造されるＭＰｘ２００などのＰｏｃｋｅｔＰＣオペレーティングシステムの制御下で稼動する携帯電話である。
【００２９】
図４Ａは、画像収集デバイスに向けられたコマンドを処理するための本発明の一実施形態におけるクライアントシステムによって辿られるステップのシーケンスのフローチャートである。シーケンスは、プレゼンテーションレベルプロトコルを使用して送信され画像収集デバイスに向けられたコマンドをクライアントシステム４０が受信するときに始まる（ステップ４００）。コマンドは、トウェインプロキシアプリケーションによってクライアントシステム上で受信され、画像収集デバイスに転送される（ステップ４０２）。コマンドは、受信されたコマンドに基づいて、結果としてトウェインＡＰＩ呼出しになり得る。コマンドは、受信されたコマンドに基づいて、デバイスドライバ呼出しをも必要とし得る。あるいは、コマンドは画像収集デバイス／プロセスに対して直接的に発行され得る。同様に、受信されたコマンドは、ユーザに示されているダイアログボックスの表示を抑制するための指示、および／または抑制されたダイアログボックスの代わりの第２のダイアログボックスの表示などの、画像収集デバイスに対する別のコマンドの発行を必要とし得る。その後、コマンドに対する応答は、画像収集デバイスから受信され（ステップ４０４）、トウェインアプリケーションをホストするサーバに送信される（ステップ４０６）。画像収集デバイスから受信された応答は、画像を表すデータであり得る。
【００３０】
本発明の説明的な実施形態は、クライアントシステムのためのセキュリティをも提供する。ユーザセッションにおいてトウェインアプリケーションから画像収集デバイスに送信されたコマンドは、実行前に肯定的なユーザ応答を受信することを必要とされ得る。たとえば、ＵＩを表示していないクライアントシステムにつながれた画像収集デバイスに対してコマンドが送信されているという状況は、コマンドが画像収集デバイスに対して送信されていることをクライアントシステムにおいて示すためのポップアップダイアログを必要とすることによって対処されることができる。クライアントシステムにおけるユーザからの肯定的な応答の後にのみ実際のコマンドが送信されるようなリダイレクタモジュールの構成は、セッションにおいて実行するアプリケーションによる画像収集デバイスの「隠された（ｓｔｅａｌｔｈ）」操作を防止する。
【００３１】
ステップの上述のシーケンスは単一のサーバからの単一のコマンドの受信に焦点を当てているが、当業者は、本発明の範囲の範囲内においてステップの代替的シーケンスが生じ得ることを認識する。たとえば、第２のコマンドはまた、クライアントに関連する画像収集デバイスに向けられたプレゼンテーションレベルプロトコルを使用して、第２のサーバから受信され得る。あるいは、サーバはクライアントに関連する第２の画像収集デバイスに向けられた第２のコマンドを発行し得る。同様に、クライアントシステムに関連する第２の画像収集デバイスは、プレゼンテーションレベルプロトコルを使用して第２のサーバからコマンドを受信し得る。
【００３２】
図４Ｂは、画像収集イベントを処理するための本発明の一実施形態におけるサーバシステムによって辿られるステップのシーケンスのフローチャートである。シーケンスは、サーバがネットワークを介してクライアントシステムから画像収集イベントを受信するときに始まる（ステップ４２０）。たとえば、スキャナ上でボタンが押されることは、イベントを生成する。画像収集デバイスイベントは、サーバ２０上の関連するトウェインアプリケーションプログラム２６および２８に提供される（ステップ４２２）。アプリケーションプログラムは、送信されたイベントに対して応答を生成し（ステップ４２４）、受信された応答をネットワークを介してクライアントシステムに送信する。
【００３３】
本明細書において論じられる本発明の実施形態の多くは、クライアントシステム上に常駐するトウェインフレームワークの残りを用いたユーザセッションの範囲内で実行するトウェインアプリケーションに関して論じられてきたが、他の実装も可能であることも留意されるべきである。たとえば、トウェインアプリケーションは、サーバ上で実行し得るが、クライアントシステム上で稼動するトウェインフレームワーク（ＤＳＭおよびＤＳ）の残りを用いたユーザセッションにおいては実行され得ない。二者間の通信は、プレゼンテーションレベルプロトコルを使用することなく実行され得る。同様に、本明細書に含まれる記載は、サーバ上のユーザセッションにおけるトウェインアプリケーションをホストしながらクライアントシステムに対してトウェインフレームワークのＤＳＭおよびＤＳ部分をリモーティングすることを論じてきたが、本発明の範囲の範囲内で他の実装が可能である。たとえば、ＤＳがクライアントシステムに対してリモーティングされた一方で、ＤＳＭはサーバ上にも位置し得る。そのような場合、ＤＳＭからＤＳへの呼出しは、サーバにおいてインタセプトされ得、クライアントシステムに送信され得る。
【００３４】
すでに示されたクライアントサーバアーキテクチャに加えて、本発明の説明的な実施形態は、「パススルー」アーキテクチャを可能にし、そこでは、クライアントシステムと通信する画像収集デバイスは、ネットワークを介してサーバ上のプロキシクライアントにアクセスするクライアントまたはシンクライアントである。たとえば、図５Ａは、サーバ５１０上で実行するプロキシクライアント５２０にアクセスするトウェインイメージングデバイスをホストするＷｉｎＣＥ使用可能なＰＤＡ５００を示す。プロキシクライアント５１０は、サーバ５５０と制御仮想チャネル５３０および通信仮想５４０を確立するＩＣＡクライアントであり得る。サーバ５５０は、セッションの範囲内において実行するアプリケーション５７０のインスタンスを用いたセッション５６０を含む。ＷｉｎＣＥ ＰＤＡ５００は、上記に概要を述べたメカニズムと整合性のある第２のサーバ５５０の中にマップされ得る。
【００３５】
同様に、図５Ｂは、プロキシクライアントおよびユーザセッションの両方が同一のサーバによってサポートされる代替的なアーキテクチャを示す。図５Ｂにおいて、画像収集デバイス６０５はクライアントデバイス６００と通信する。クライアントデバイス６００はサーバ６１０と通信する。サーバ６１０は、プロキシクライアント６２０およびユーザセッション６３０の両方を含む。ユーザセッション６３０は、実行中のアプリケーション６４０のインスタンスを含む。画像収集デバイス６０５は、プロキシクライアント６２０を介してサーバ６１０上のユーザセッション６３０の中にマップされ得る。当業者は、本発明の範囲の範囲内において追加の実装および代替的なアーキテクチャも可能であることを認識する。
【００３６】
本発明は、一つ以上の製品の上または中において具体化される一つ以上のコンピュータ可読プログラムとして提供され得る。製品は、フロッピー（登録商標）ディスク、ハードディスク、コンパクトディスク、デジタル汎用ディスク、フラッシュメモリカード、ＰＲＯＭ、ＲＡＭ、ＲＯＭ、または磁気テープであり得る。一般的に、コンピュータ可読プログラムは任意のプログラミング言語において実装され得る。使用されることのできる言語のいくつかの例は、Ｃ、Ｃ＋＋、Ｃ＃、またはＪＡＶＡ（登録商標）を含む。ソフトウェアプログラムは、オブジェクトコードとして一つ以上の製品の上または中において格納され得る。
【００３７】
本発明は特定の好ましい実施形態に関して示され記述された一方で、添付の特許請求の範囲によって定義される本発明の精神および範囲から逸脱することなく、形態および詳細において種々の変更がなされ得ることが当業者によって理解されるべきである。
【図面の簡単な説明】
【００３８】
【図１】図１（従来技術）は、従来のトウェインアークテクチャのブロック図を示す。
【図２Ａ】図２Ａは、本発明の説明的な実施形態を実行するために適切な環境を示す。
【図２Ｂ】図２Ｂは、図２Ａの環境をより詳細に示す。
【図３Ａ】図３Ａは、本発明と関連して有用なコンピュータの実施形態を示すブロック図である。
【図３Ｂ】図３Ｂは、本発明と関連して有用なコンピュータの実施形態を示すブロック図である。
【図４Ａ】図４Ａは、画像収集デバイスに向けられたコマンドを処理するための本発明の実施形態におけるクライアントシステムによって辿られるステップのシーケンスのフローチャートである。
【図４Ｂ】図４Ｂは、画像収集イベントを処理するための本発明の実施形態におけるサーバシステムによって辿られるステップのシーケンスのフローチャートである。
【図５Ａ】図５Ａは、パススルー環境にけるプロキシクライアントの使用を示す本発明の実施形態のブロック図である。
【図５Ｂ】図５Ｂは、パススルー環境にけるプロキシクライアントの使用を示す本発明の別の実施形態のブロック図であり、プロキシクライアントはユーザセッションをホストするサーバ上に位置させられる。
【特許請求の範囲】
【請求項１】
クライアントに関連する画像収集デバイスを制御するための方法であって、該方法は、
（ａ）プレゼンテーションレベルプロトコルを使用してサーバと通信するクライアントを提供するステップであって、該クライアントは、サーバ上で実行するアプリケーションに関連するプロキシアプリケーションを実行する、ステップと、
（ｂ）該クライアントに関連する画像収集デバイスに向けられたコマンドを、ネットワークを介してサーバから、該プロキシアプリケーションにおいて受信するステップと、
（ｃ）該受信されたコマンドを該関連する画像収集デバイスに対して発行するステップと、
（ｄ）該発行されたイベントに対する応答を該画像収集デバイスから受信するステップと、
（ｅ）該受信された応答をネットワークを介して該サーバに送信するステップと
を包含する、方法。
【請求項２】
前記ステップ（ｂ）が、ＩＣＡ、ＲＤＰおよびＸ−ＷＩＮＤＯＷＳから成るグループから選択される一つのプロトコルを使用して、ネットワークを介してサーバから、クライアントに関連する画像収集デバイスに向けられたコマンドを受信することを包含する、請求項１に記載の方法。
【請求項３】
前記ステップ（ｃ）が、前記受信されたコマンドに基づいて前記画像収集デバイスにＴＷＡＩＮ ＡＰＩ呼出しを発行することを包含する、請求項１に記載の方法。
【請求項４】
前記ステップ（ｃ）が、前記受信されたコマンドに基づいて前記画像収集デバイスにデバイスドライバ呼出しを発行することを包含する、請求項１に記載の方法。
【請求項５】
前記ステップ（ｃ）が、前記受信されたコマンドに基づいて前記画像収集デバイスにコマンドを直接的に発行することを包含する、請求項１に記載の方法。
【請求項６】
前記ステップ（ｃ）が、前記受信されたコマンドに基づいて前記関連する画像収集デバイスにコマンドを発行することを包含し、発行されたコマンドが、ユーザに対するダイアログボックスの表示を抑制するための指示を含む、請求項１に記載の方法。
【請求項７】
前記抑制されたダイアログボックスの代わりにユーザに対して第２のダイアログボックスを表示するステップをさらに包含する、請求項６に記載の方法。
【請求項８】
前記クライアントに関連する前記画像収集デバイスに向けられた第２のコマンドを、前記ネットワークを介して第２のサーバから受信するステップをさらに包含する、請求項１に記載の方法。
【請求項９】
前記クライアントに関連する第２の画像収集デバイスに向けられた第２のコマンドを、前記ネットワークを介して前記サーバから受信するステップをさらに包含する、請求項１に記載の方法。
【請求項１０】
前記クライアントに関連する第２の画像収集デバイスに向けられた第２のコマンドを、前記ネットワークを介して第２のサーバから受信するステップをさらに包含する、請求項１に記載の方法。
【請求項１１】
前記ステップ（ｄ）が、画像を表すデータを前記画像収集デバイスから受信することを包含する、請求項１に記載の方法。
【請求項１２】
前記ステップ（ｅ）が、
（ｅ−１）圧縮された画像データを前記サーバに送信すること
をさらに包含する、請求項１１に記載の方法。
【請求項１３】
前記ステップ（ｅ）が、
（ｅ−１）前記圧縮された画像データを前記サーバに送信する前に前記画像データが各ピクセル位置について二つ以上のビットを含むことを決定すること
をさらに包含する、請求項１２に記載の方法。
【請求項１４】
ステップ（ｅ−２）が、
（ｅ−２−１）第１の圧縮された画像データを形成するために第１の圧縮アルゴリズムを使用して前記画像データを圧縮することと、
（ｅ−２−２）第２の圧縮された画像データを形成するために第２の圧縮アルゴリズムを使用して前記画像データを圧縮することと、
（ｅ−２−３）該第１の圧縮された画像データおよび該第２の圧縮された画像データのうちのより小さいほうを送信のために選択することと
を包含する、請求項１３に記載の方法。
【請求項１５】
前記サーバへの送信中に圧縮された画像データを圧縮するステップをさらに包含する、請求項１２に記載の方法。
【請求項１６】
前記ステップ（ｄ）の前に、
前記クライアントのユーザから入力を受信するステップと、
該受信された入力を前記サーバに送信するかどうかを決定するステップと
をさらに包含する、請求項１に記載の方法。
【請求項１７】
クライアントに関連する画像収集装置を制御するための方法であって、該方法は、
画像収集イベントをネットワークを介してクライアントから受信するステップと、
該受信されたイベントを該イベントに関連するアプリケーションプログラムに提供するステップと、
送信されたイベントに対する応答を該アプリケーションプログラムから受信するステップと、
該受信された応答を該アプリケーションプログラムに関連するプロキシアプリケーションにネットワークを介して送信するステップであって、該プロキシアプリケーションは、該クライアント上で実行する、ステップと
を包含する、方法。
【請求項１８】
ステップ（ｂ）が、
（ｂ−１）前記受信されたイベントから、該受信されたイベントに関連するアプリケーションプログラムを決定することと、
（ｂ−２）該受信されたイベントを該決定されたアプリケーションプログラムに提供することと
を包含する、請求項１７に記載の方法。
【請求項１９】
ステップ（ｃ）が、インタセプトされたＴＷＡＩＮ ＡＰＩ呼出しをネットワークを介して受信することを包含する、請求項１７に記載の方法。
【請求項２０】
前記クライアントに関連する装置によって収集された画像を表すデータをネットワークを介して該クライアントから受信するステップをさらに包含する、請求項１７に記載の方法。
【請求項２１】
前記受信された画像収集データを解凍するステップをさらに包含する、請求項２０に記載の方法。
【請求項２２】
前記ネットワークを介して第２のクライアントから画像収集イベントを受信することをさらに包含する、請求項１７に記載の方法。
【請求項２３】
前記第２のクライアントから受信された前記画像収集イベントを前記イベントに関連するアプリケーションプログラムの第２のインスタンスに提供するステップをさらに包含する、請求項２２に記載の方法。
【請求項２４】
クライアントに関連する画像収集デバイスを制御するためのコンピュータ可読プログラム手段を具体化した製品であって、該クライアントはプレゼンテーションレベルプロトコルを使用してサーバと通信し、該クライアントはサーバ上で実行するトウェインアプリケーションに関連するプロキシアプリケーションをさらに実行し、該製品は、
該クライアントに関連する画像収集デバイスに向けられたコマンドをネットワークを介してサーバから受信するためのコンピュータ可読プログラム手段と、
該関連する画像収集デバイス上で実行する該プロキシアプリケーションに対して該受信されたコマンドを発行するためのコンピュータ可読プログラム手段と、
該発行されたイベントに対する応答を該画像収集デバイスから受信するためのコンピュータ可読プログラム手段と、
該受信された応答をネットワークを介して該サーバに送信するためのコンピュータ可読プログラム手段と
を含む、製品。
【請求項２５】
画像収集デバイスに向けられたコマンドを受信するための前記コンピュータ可読プログラム手段が、ＩＣＡ、ＲＤＰおよびＸ−ＷＩＮＤＯＷＳから成るグループから選択されるプロトコルを使用して、クライアントに関連する画像収集デバイスに向けられたコマンドをネットワークを介してサーバから受信するためのコンピュータ可読プログラム手段をさらに含む、請求項２４に記載の製品。
【請求項２６】
前記関連する画像収集デバイスに対して前記受信されたコマンドを発行するための前記コンピュータ可読プログラム手段が、該受信されたコマンドに基づいて該画像収集デバイスに対してＴＷＡＩＮ ＡＰＩ呼出しを発行するためのコンピュータ可読プログラム手段をさらに含む、請求項２４に記載の製品。
【請求項２７】
クライアントと通信する画像収集デバイスを制御するための方法であって、該方法は、
該クライアントと通信する該画像収集デバイスに向けられたコマンドをサーバから受信するステップと、
該受信されたコマンドに基づいて、該クライアントと通信する該画像収集デバイスに対してＴＷＡＩＮ ＡＰＩ呼出しを発行するステップと、
該発行されたコマンドに対する応答を該画像収集デバイスから受信するステップと、
該受信された応答を該サーバに送信するステップと
を包含する、方法。
【請求項２８】
ステップ（ｂ）が、前記受信されたコマンドに基づいて前記画像収集デバイスに対してデバイスドライバ呼出しを発行することを包含する、請求項２７に記載の方法。
【請求項２９】
ステップ（ｂ）が、前記受信されたコマンドに基づいて前記画像収集デバイスに対してコマンドを直接的に発行することを包含する、請求項２７に記載の方法。
【請求項３０】
ステップ（ｂ）が、前記受信されたコマンドに基づいて前記画像収集デバイスに対してコマンドを発行することを包含し、該発行されたコマンドがユーザに対するダイアログボックスの表示を抑制する指示を包含する、請求項２７に記載の方法。
【請求項３１】
前記抑制されたダイアログボックスの代わりにユーザに対して第２のダイアログボックスを表示するステップをさらに包含する、請求項３０に記載の方法。
【請求項３２】
前記クライアントに関連する前記画像収集デバイスに向けられた第２のコマンドをネットワークを介して第２のサーバから受信するステップをさらに包含する、請求項２７に記載の方法。
【請求項３３】
前記クライアントに関連する第２の画像収集デバイスに向けられた第２のコマンドを前記サーバから受信するステップをさらに包含する、請求項２７に記載の方法。
【請求項３４】
前記クライアントに関連する第２の画像収集デバイスに向けられた第２のコマンドをネットワークを介して第２のサーバから受信するステップをさらに包含する、請求項２７に記載の方法。
【請求項３５】
ステップ（ｃ）が、前記画像収集デバイスから画像を表すデータを受信することを包含する、請求項２７に記載の方法。
【請求項３６】
ステップ（ｄ）が、
（ｄ−１）前記画像データが各ピクセル位置について一つのビットを含むことを決定することと、
（ｄ−２）該画像データをネットワークを介して前記サーバに送信することと
を包含する、請求項３５に記載の方法。
【請求項３７】
ステップ（ｄ）が、
（ｄ−１）前記画像データが各ピクセル位置について二つ以上のビットを含むことを決定することと、
（ｄ−２）該画像データを圧縮することと、
（ｄ−３）該圧縮された画像データをネットワークを介して前記サーバに送信することと
を包含する、請求項３５に記載の方法。
【請求項３８】
ステップ（ｄ−２）が、
（ｄ−２−１）第１の圧縮された画像データを形成するために第１の圧縮アルゴリズムを使用して前記画像データを圧縮することと、
（ｄ−２−２）第２の圧縮された画像データを形成するために第２の圧縮アルゴリズムを使用して前記画像データを圧縮することと、
（ｄ−２−３）該第１の圧縮された画像データおよび該第２の圧縮された画像データのうちのより小さいほうを送信のために選択することと
を包含する、請求項３７に記載の方法。
【請求項３９】
前記サーバへの送信中に圧縮された画像データを圧縮するステップをさらに包含する、請求項３７に記載の方法。
【請求項４０】
ステップ（ｃ）の前に、
前記クライアントのユーザから入力を受信するステップと、
該受信された入力を前記サーバに送信するかどうかを決定するステップと
をさらに包含する、請求項２７に記載の方法。
【請求項１】
クライアントに関連する画像収集デバイスを制御するための方法であって、該方法は、
（ａ）プレゼンテーションレベルプロトコルを使用してサーバと通信するクライアントを提供するステップであって、該クライアントは、サーバ上で実行するアプリケーションに関連するプロキシアプリケーションを実行する、ステップと、
（ｂ）該クライアントに関連する画像収集デバイスに向けられたコマンドを、ネットワークを介してサーバから、該プロキシアプリケーションにおいて受信するステップと、
（ｃ）該受信されたコマンドを該関連する画像収集デバイスに対して発行するステップと、
（ｄ）該発行されたイベントに対する応答を該画像収集デバイスから受信するステップと、
（ｅ）該受信された応答をネットワークを介して該サーバに送信するステップと
を包含する、方法。
【請求項２】
前記ステップ（ｂ）が、ＩＣＡ、ＲＤＰおよびＸ−ＷＩＮＤＯＷＳから成るグループから選択される一つのプロトコルを使用して、ネットワークを介してサーバから、クライアントに関連する画像収集デバイスに向けられたコマンドを受信することを包含する、請求項１に記載の方法。
【請求項３】
前記ステップ（ｃ）が、前記受信されたコマンドに基づいて前記画像収集デバイスにＴＷＡＩＮ ＡＰＩ呼出しを発行することを包含する、請求項１に記載の方法。
【請求項４】
前記ステップ（ｃ）が、前記受信されたコマンドに基づいて前記画像収集デバイスにデバイスドライバ呼出しを発行することを包含する、請求項１に記載の方法。
【請求項５】
前記ステップ（ｃ）が、前記受信されたコマンドに基づいて前記画像収集デバイスにコマンドを直接的に発行することを包含する、請求項１に記載の方法。
【請求項６】
前記ステップ（ｃ）が、前記受信されたコマンドに基づいて前記関連する画像収集デバイスにコマンドを発行することを包含し、発行されたコマンドが、ユーザに対するダイアログボックスの表示を抑制するための指示を含む、請求項１に記載の方法。
【請求項７】
前記抑制されたダイアログボックスの代わりにユーザに対して第２のダイアログボックスを表示するステップをさらに包含する、請求項６に記載の方法。
【請求項８】
前記クライアントに関連する前記画像収集デバイスに向けられた第２のコマンドを、前記ネットワークを介して第２のサーバから受信するステップをさらに包含する、請求項１に記載の方法。
【請求項９】
前記クライアントに関連する第２の画像収集デバイスに向けられた第２のコマンドを、前記ネットワークを介して前記サーバから受信するステップをさらに包含する、請求項１に記載の方法。
【請求項１０】
前記クライアントに関連する第２の画像収集デバイスに向けられた第２のコマンドを、前記ネットワークを介して第２のサーバから受信するステップをさらに包含する、請求項１に記載の方法。
【請求項１１】
前記ステップ（ｄ）が、画像を表すデータを前記画像収集デバイスから受信することを包含する、請求項１に記載の方法。
【請求項１２】
前記ステップ（ｅ）が、
（ｅ−１）圧縮された画像データを前記サーバに送信すること
をさらに包含する、請求項１１に記載の方法。
【請求項１３】
前記ステップ（ｅ）が、
（ｅ−１）前記圧縮された画像データを前記サーバに送信する前に前記画像データが各ピクセル位置について二つ以上のビットを含むことを決定すること
をさらに包含する、請求項１２に記載の方法。
【請求項１４】
ステップ（ｅ−２）が、
（ｅ−２−１）第１の圧縮された画像データを形成するために第１の圧縮アルゴリズムを使用して前記画像データを圧縮することと、
（ｅ−２−２）第２の圧縮された画像データを形成するために第２の圧縮アルゴリズムを使用して前記画像データを圧縮することと、
（ｅ−２−３）該第１の圧縮された画像データおよび該第２の圧縮された画像データのうちのより小さいほうを送信のために選択することと
を包含する、請求項１３に記載の方法。
【請求項１５】
前記サーバへの送信中に圧縮された画像データを圧縮するステップをさらに包含する、請求項１２に記載の方法。
【請求項１６】
前記ステップ（ｄ）の前に、
前記クライアントのユーザから入力を受信するステップと、
該受信された入力を前記サーバに送信するかどうかを決定するステップと
をさらに包含する、請求項１に記載の方法。
【請求項１７】
クライアントに関連する画像収集装置を制御するための方法であって、該方法は、
画像収集イベントをネットワークを介してクライアントから受信するステップと、
該受信されたイベントを該イベントに関連するアプリケーションプログラムに提供するステップと、
送信されたイベントに対する応答を該アプリケーションプログラムから受信するステップと、
該受信された応答を該アプリケーションプログラムに関連するプロキシアプリケーションにネットワークを介して送信するステップであって、該プロキシアプリケーションは、該クライアント上で実行する、ステップと
を包含する、方法。
【請求項１８】
ステップ（ｂ）が、
（ｂ−１）前記受信されたイベントから、該受信されたイベントに関連するアプリケーションプログラムを決定することと、
（ｂ−２）該受信されたイベントを該決定されたアプリケーションプログラムに提供することと
を包含する、請求項１７に記載の方法。
【請求項１９】
ステップ（ｃ）が、インタセプトされたＴＷＡＩＮ ＡＰＩ呼出しをネットワークを介して受信することを包含する、請求項１７に記載の方法。
【請求項２０】
前記クライアントに関連する装置によって収集された画像を表すデータをネットワークを介して該クライアントから受信するステップをさらに包含する、請求項１７に記載の方法。
【請求項２１】
前記受信された画像収集データを解凍するステップをさらに包含する、請求項２０に記載の方法。
【請求項２２】
前記ネットワークを介して第２のクライアントから画像収集イベントを受信することをさらに包含する、請求項１７に記載の方法。
【請求項２３】
前記第２のクライアントから受信された前記画像収集イベントを前記イベントに関連するアプリケーションプログラムの第２のインスタンスに提供するステップをさらに包含する、請求項２２に記載の方法。
【請求項２４】
クライアントに関連する画像収集デバイスを制御するためのコンピュータ可読プログラム手段を具体化した製品であって、該クライアントはプレゼンテーションレベルプロトコルを使用してサーバと通信し、該クライアントはサーバ上で実行するトウェインアプリケーションに関連するプロキシアプリケーションをさらに実行し、該製品は、
該クライアントに関連する画像収集デバイスに向けられたコマンドをネットワークを介してサーバから受信するためのコンピュータ可読プログラム手段と、
該関連する画像収集デバイス上で実行する該プロキシアプリケーションに対して該受信されたコマンドを発行するためのコンピュータ可読プログラム手段と、
該発行されたイベントに対する応答を該画像収集デバイスから受信するためのコンピュータ可読プログラム手段と、
該受信された応答をネットワークを介して該サーバに送信するためのコンピュータ可読プログラム手段と
を含む、製品。
【請求項２５】
画像収集デバイスに向けられたコマンドを受信するための前記コンピュータ可読プログラム手段が、ＩＣＡ、ＲＤＰおよびＸ−ＷＩＮＤＯＷＳから成るグループから選択されるプロトコルを使用して、クライアントに関連する画像収集デバイスに向けられたコマンドをネットワークを介してサーバから受信するためのコンピュータ可読プログラム手段をさらに含む、請求項２４に記載の製品。
【請求項２６】
前記関連する画像収集デバイスに対して前記受信されたコマンドを発行するための前記コンピュータ可読プログラム手段が、該受信されたコマンドに基づいて該画像収集デバイスに対してＴＷＡＩＮ ＡＰＩ呼出しを発行するためのコンピュータ可読プログラム手段をさらに含む、請求項２４に記載の製品。
【請求項２７】
クライアントと通信する画像収集デバイスを制御するための方法であって、該方法は、
該クライアントと通信する該画像収集デバイスに向けられたコマンドをサーバから受信するステップと、
該受信されたコマンドに基づいて、該クライアントと通信する該画像収集デバイスに対してＴＷＡＩＮ ＡＰＩ呼出しを発行するステップと、
該発行されたコマンドに対する応答を該画像収集デバイスから受信するステップと、
該受信された応答を該サーバに送信するステップと
を包含する、方法。
【請求項２８】
ステップ（ｂ）が、前記受信されたコマンドに基づいて前記画像収集デバイスに対してデバイスドライバ呼出しを発行することを包含する、請求項２７に記載の方法。
【請求項２９】
ステップ（ｂ）が、前記受信されたコマンドに基づいて前記画像収集デバイスに対してコマンドを直接的に発行することを包含する、請求項２７に記載の方法。
【請求項３０】
ステップ（ｂ）が、前記受信されたコマンドに基づいて前記画像収集デバイスに対してコマンドを発行することを包含し、該発行されたコマンドがユーザに対するダイアログボックスの表示を抑制する指示を包含する、請求項２７に記載の方法。
【請求項３１】
前記抑制されたダイアログボックスの代わりにユーザに対して第２のダイアログボックスを表示するステップをさらに包含する、請求項３０に記載の方法。
【請求項３２】
前記クライアントに関連する前記画像収集デバイスに向けられた第２のコマンドをネットワークを介して第２のサーバから受信するステップをさらに包含する、請求項２７に記載の方法。
【請求項３３】
前記クライアントに関連する第２の画像収集デバイスに向けられた第２のコマンドを前記サーバから受信するステップをさらに包含する、請求項２７に記載の方法。
【請求項３４】
前記クライアントに関連する第２の画像収集デバイスに向けられた第２のコマンドをネットワークを介して第２のサーバから受信するステップをさらに包含する、請求項２７に記載の方法。
【請求項３５】
ステップ（ｃ）が、前記画像収集デバイスから画像を表すデータを受信することを包含する、請求項２７に記載の方法。
【請求項３６】
ステップ（ｄ）が、
（ｄ−１）前記画像データが各ピクセル位置について一つのビットを含むことを決定することと、
（ｄ−２）該画像データをネットワークを介して前記サーバに送信することと
を包含する、請求項３５に記載の方法。
【請求項３７】
ステップ（ｄ）が、
（ｄ−１）前記画像データが各ピクセル位置について二つ以上のビットを含むことを決定することと、
（ｄ−２）該画像データを圧縮することと、
（ｄ−３）該圧縮された画像データをネットワークを介して前記サーバに送信することと
を包含する、請求項３５に記載の方法。
【請求項３８】
ステップ（ｄ−２）が、
（ｄ−２−１）第１の圧縮された画像データを形成するために第１の圧縮アルゴリズムを使用して前記画像データを圧縮することと、
（ｄ−２−２）第２の圧縮された画像データを形成するために第２の圧縮アルゴリズムを使用して前記画像データを圧縮することと、
（ｄ−２−３）該第１の圧縮された画像データおよび該第２の圧縮された画像データのうちのより小さいほうを送信のために選択することと
を包含する、請求項３７に記載の方法。
【請求項３９】
前記サーバへの送信中に圧縮された画像データを圧縮するステップをさらに包含する、請求項３７に記載の方法。
【請求項４０】
ステップ（ｃ）の前に、
前記クライアントのユーザから入力を受信するステップと、
該受信された入力を前記サーバに送信するかどうかを決定するステップと
をさらに包含する、請求項２７に記載の方法。
【図１】
【図２Ａ】
【図２Ｂ】
【図３Ａ】
【図３Ｂ】
【図４Ａ】
【図４Ｂ】
【図５Ａ】
【図５Ｂ】
【図２Ａ】
【図２Ｂ】
【図３Ａ】
【図３Ｂ】
【図４Ａ】
【図４Ｂ】
【図５Ａ】
【図５Ｂ】
【公表番号】特表２００８−５１５２７８（Ｐ２００８−５１５２７８Ａ）
【公表日】平成２０年５月８日（２００８．５．８）
【国際特許分類】
【出願番号】特願２００７−５３３４５５（Ｐ２００７−５３３４５５）
【出願日】平成１７年６月８日（２００５．６．８）
【国際出願番号】ＰＣＴ／ＵＳ２００５／０２０３４５
【国際公開番号】ＷＯ２００６／０３６２３０
【国際公開日】平成１８年４月６日（２００６．４．６）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．Ｂｌｕｅｔｏｏｔｈ
２．ＦＲＡＭ
３．Ｌｉｎｕｘ
【出願人】（５０２２３９３１３）サイトリックス システムズ， インコーポレイテッド (36)
【Ｆターム（参考）】
【公表日】平成２０年５月８日（２００８．５．８）
【国際特許分類】
【出願日】平成１７年６月８日（２００５．６．８）
【国際出願番号】ＰＣＴ／ＵＳ２００５／０２０３４５
【国際公開番号】ＷＯ２００６／０３６２３０
【国際公開日】平成１８年４月６日（２００６．４．６）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．Ｂｌｕｅｔｏｏｔｈ
２．ＦＲＡＭ
３．Ｌｉｎｕｘ
【出願人】（５０２２３９３１３）サイトリックス システムズ， インコーポレイテッド (36)
【Ｆターム（参考）】
[ Back to top ]