JP5451397B2 - リモートインターラクションに応答してビデオコンテンツを配信するためのアーキテクチャー - Google Patents

Description

関連出願の相互参照

[0001]本願は、３５ U.S.C. １１９（ｅ）の規定の下で、２００６年１１月１日に出願され、「CONTENT ACCESS USING COMPRESSION」と題する米国仮特許出願第６０／８６３，８８８号、及び２００７年１０月３０日に出願され、「ARCHITECTUREFOR DELIVERY OF VIDEO CONTENT RESPONSIVE TO REMOTE INTERACTION」と題する米国通常特許出願第１１／９２９，７７３号に基づく優先権を主張しており、これらの出願明細書の記載は、ここにそのまま援用される。

[0002]本発明は、リモートインターラクションに応答してビデオコンテンツを配信するためのアーキテクチャーに係る。特に、本発明は、連続するビデオフレームを対話形式である装置に対して通信することに係る。

[0003]クライアント−サーバーアーキテクチャーは、多くの異なるタイプのネットワーク環境において、種々なコンテクストにて使用される。あるネットワーク環境においては、帯域幅制限が、クライアントサーバーアーキテクチャーを使用する上での主たる制約要因の１つとなる。このような帯域幅制約環境は、ワイヤードネットワーク及びワイヤレスネットワークの両者及びこのようなネットワークの組合せ／ハイブリッドにおいて生ずることがある。ワイヤレスネットワークを例にとると、クライアント装置は、これに加えて、例えば、処理能力、メモリ及び電力（即ち、バッテリー）制限を含む装置能力に関してリソース制約を被ることがある。ウエブブラウザアプリケーションの如き、比較的に大量の帯域幅及び処理能力を消費するエンドユーザーアプリケーションにおいては、モバイルクライアント装置において実行されるときに、ユーザーの知覚認識が満足できないような事態となることがある。これらのユーザーの知覚認識が満足できないような事態は、ウエブブラウジングセッションにて予想される高速対話性を与える能力が低いことから生ずることが多い。セルラー電話の如き多くのモバイルクライアント装置は、このようなアプリケーションのフルフィーチャーバージョンを十分に支援することができないことがある。

[0004]これに併せて、ウエブサイトは、絶えずよりフィーチャーリッチとなり且つ種々な補助ソフトウエア（アニメーションプラグインの如き）を利用することが増えてきてしまい、これらは、多くのモバイルクライアント装置においては支援できないものである。多くのモバイルクライアント装置に対してコンテンツのビデオ送信をしようとすると、帯域幅制限のため、又、既存のクライアント−サーバーアーキテクチャーではこのような制限を十分に調整することができないため、ユーザーの知覚認識が満足できないような事態が生じてしまうことが多い。種々な面を有する帯域幅及び能力制約されたモバイル装置において生ずるフルフィーチャーブラウジング知覚認識を支援し且つこれら同じ装置に対する他のアプリケーションの使用を支援する必要性がある。本発明の実施形態は、その他の必要性にも向けられる。

[0005]種々な実施形態において、本発明は、ネットワークを通じてビデオフレームを通信するためのアーキテクチャーに関するシステム及び方法を提供する。一実施形態では、システムは、第１の装置に存在する第１のエンジンを含み、前記第１のエンジンは、前記ネットワークを通じて送信するためのプログラムのユーザーインターフェースの連続するビデオフレームをエンコーディングするように構成される。前記ビデオフレームのエンコーディングは、１つ以上のフィードバックパラメータに基づいており、且つビデオ圧縮技法を含む。同じ実施形態において、前記システムは、前記プログラムに機能的に結合される第１のコマンド処理エンジンを含む。同じ実施形態において、前記システムは、第２の装置に存在する第２のエンジンを含み、前記第２のエンジンは、前記ネットワークを通した送信後に前記連続するビデオフレームをデコーディングするように構成される。同じ実施形態において、前記システムは、前記第１のコマンド処理エンジンに機能的に結合され且つ前記第２の装置のユーザー入力を前記第１のコマンド処理エンジンを介して前記プログラムへ通信するように構成される第２のコマンド処理エンジンを含む。

[0006]別の実施形態においては、前記連続するビデオフレームに関連したオーディオストリームもまたエンコーディング及びデコーディングされる。更に別の実施形態においては、ユーザーインターフェースを有する複数のプログラムがあり、前記複数のプログラムの各々は、対応する複数の第１のエンジン及び対応する複数の第１のコマンド処理エンジンを有する。更に又、前記複数のプログラムは、オペレーティングシステムの１つのインスタンスにおいて実行され、ユーザーマネージャエンジンは、前記ネットワークを通じて対応する複数の第２の装置へ送信するため前記複数のプログラムの各々の連続するビデオフレームをロードバランス形式にてエンコーディングするように構成される。

[0007]更に別の実施形態では、前記第２の装置は、ビューイングアプリケーションを含み、前記ビューイングアプリケーションは、前記第１のエンジンに機能的に結合され且つ前記連続するビデオフレームを表示するように構成される。同じ実施形態において、前記ビューイングアプリケーションは、更に、前記コマンド処理エンジンに機能的に結合され且つ前記プログラムへのユーザー入力の通信を行うように構成される。

[0008]更に別の実施形態では、方法は、前記複数のプログラムに対応する複数のオーディオストリームをインターセプトするステップと、前記複数のオーディオストリームの各々を前記複数のプログラムに対応する複数の処理識別子のうちの１つに関連付けるステップと、前記複数のオーディオストリームをエンコーディングするステップと、前記関連付けられた処理識別子に基づいて前記複数のオーディオストリームをルーティングするステップと、を含む。

[0009]当業者であれば、本発明は、広範囲に亘る種々なシステム及び方法において実施できることが認識されよう。

一実施形態による本発明のクライアント−サーバーアーキテクチャーのある幾つかの態様を例示するブロック図である。 一実施形態によるサーバーに関する本発明のある幾つかの態様を例示するブロック図である。 一実施形態によるサーバー、オーディオサーバー及びクライアントを含む本発明のアーキテクチャーオーバービューのある幾つかの態様を例示するブロック図である。 一実施形態によるクライアントに関する本発明のある幾つかの態様を例示するブロック図である。 一実施形態によるマルチユーザーソフトウエアアーキテクチャーのある幾つかの態様を例示する図である。 一実施形態による連続するビデオフレームを取り込むためのある幾つかの支援態様を例示するフローチャートである。 一実施形態による連続するビデオフレームを送るためのある幾つかの支援態様を例示するフローチャートである。 一実施形態によるクライアント−サーバー交換のある幾つかの態様を例示する図である。 一実施形態によるサーバー内での付随する交換を含むクライアント−サーバー交換のある幾つかの態様を例示する図である。 一実施形態によるリモートインターラクションのためのクライアント−サーバーアーキテクチャーに関連して使用するのに適した典型的なコンピュータシステムを例示している。

[0020]当業者であれば、これら図は、１つ又は幾つかの実施形態による本発明の動作の単なる実施例を示すだけのものであり、本発明の本質的な特徴から逸脱せずに、他のアーキテクチャー、方法ステップ、交換及び動作のモードを使用できることが認識されよう。

[0021]本発明の１つの又は幾つかの実施形態を示している添付図面に関して、本発明について、以下、より十分に説明する。本発明は、多くの異なる形にて実施することができるものであり、ここに説明する実施形態に限定されるものではない。むしろ、これらの実施形態は、本発明の開示を完全なものとし、当業者に対して本発明の原理を十分に理解させるために提示されるものである。

[0022]例示の目的で、本発明の実施形態について、サーバー又は典型的なモバイルクライアント装置の如きモバイルクライアント装置に関連して説明する。ここでは、本発明の理解を助けるため、サーバー及びモバイルクライアント装置に関する実施形態について、種々な特定の詳細につき説明する。しかしながら、これら特定の詳細は、例示のためのものであり、特許請求の範囲に限定される本発明の範囲を制限するものではない。特に、当業者であれば、本発明は、例えば、ワイヤードネットワークにおいて動作するクライアント装置を含む広範囲に亘る種々なコンテクストに関して使用できるものであることが認識されよう。又、本発明の実施形態は、ウエブブラウジングアプリケーションに関連して説明するが、これら説明は、実施例を例示しようとしているものであり、特許請求の範囲に限定されたような本発明の範囲を制限するものではない。本発明の種々な実施形態は、オペレーティングシステム（ＯＳ）を含む多くの種々なタイプのプログラム、ワードプロセシング、スプレッドシート、プレゼンテーション及びデータベースアプリケーションを含む広範囲に亘る種々なアプリケーションに関して使用することができる。

[0023]ある幾つかの実施形態では、本発明は、マイクロソフト社から入手できるマイクロソフトＯＳ、リナックスの種々なバージョン、ユニックスの種々なバージョン、アップルコンピュータ社から入手できるマックＯＳ及び／又は他のオペレーティングシステムの如きＯＳを実行する従来のサーバーコンピュータシステムにおいて、少なくとも部分的に実施される。ある幾つかの実施形態では、本発明は、マイクロソフトウインドーズビスタ又はエックスピー（又は別のウインドーズバージョン）、マックＯＳエックス（又は別のマックＯＳバージョン）、リナックスの種々なバージョン、ユニックスの種々なバージョン、又はコンピューティング装置における種々なオペレーションを全体的に管理するように設計された他のＯＳの如きＯＳを実行する通常のパーソナルコンピュータシステムにおいて実施される。

[0024]更に又、本発明は、例えば、個人向け携帯情報端末（ＰＤＡ）、セルホン、１つ以上のコンピューティングリソースが遠隔的に配置されていてネットワークを介してアクセスされ、種々なオペレーティングシステムにて実行されるようなコンピューティング装置の如きパーソナルコンピュータ以外の装置にて実施され、又はそのような装置に関連して実施することのできるものである。本発明は、アドオンソフトウエアとして含ませることができ、又、本発明は、コンピュータシステムに添付されるアプリケーションのフィーチャーとなることもでき、又、本発明は、ハードウエアに埋め込まれた機能として実施することもできる。

[0025]本発明により生成される出力は、スクリーンに表示され、リモート装置に記憶され、データベース又は他の記憶機構に記憶され、プリントされ、又は、その他の任意の仕方にて使用することができるものである。更に又、ある幾つかの実施形態では、本発明は、キーボード（種々な形式におけるスクリーンベースの又は物理的なキーボード）、スクロールホイール、ナンバーパッド、スタイラスベースの入力、タッチスクリーン又はタッチパッドの如き入力装置を介してコンピュータシステムへ与えられる入力を使用する。このような構成部分は、それらの動作、互いのインターラクション及びパーソナルコンピュータの中央処理装置とのインターラクションを含めて、コンピュータシステムの技術分野において良く知られているので、ここでは説明しない。

[0026]モジュールに関してここに説明するどのソフトウエア部分も、別々のソフトウエアモジュールを含む必要はない。ここに説明するどのソフトウエア構成も、単なる実施例であり、本発明の種々な実施形態の範囲内で他の構成も考えることができる。用語「エンジン」は、ここでは、関連する機能又は種々の機能を果たす任意のソフトウエア又はハードウエアコンフィギュレーションを示すのに使用される。

[0027]本明細書において、「一実施形態」又は「ある実施形態」としているのは、それら実施形態に関して説明された特定の特徴、構造又は特性が本発明の少なくとも１つの実施形態に含まれることを意味している。本明細書の種々な場所に出て来る表現「一実施形態において」は、必ずしも同じ実施形態を指しているものではない。本明細書の種々な場所に出て来る表現「ある幾つかの実施形態において」は、必ずしも、全てが、実施形態のその同じ組を指しているものではない。本明細書の種々な場所に出て来る表現「種々な実施形態」は、必ずしも、全てが、実施形態の同じ組を指しているものではない。

１．システム
[0028]図１は、一実施形態による本発明のシステム１００のある幾つかの態様を例示するブロック図である。このシステム１００は、サーバーアプリケーション１（１０２）、サーバーアプリケーション２（１０４）、サーバーアプリケーション３（１０６）、及びサーバーアプリケーションｎ（１１０）までの広範囲に亘る数の付加的なサーバーアプリケーション（省略符号１０８で表される）を含む、サーバー２００にて実行される多数のサーバーアプリケーションインスタンスを含むクライアントサーバーアーキテクチャーを使用する。用語「サーバーアプリケーション」は、ここでは、サーバー側アプリケーション、即ち、１つ以上のサーバーにて実行されるアプリケーションを示すのに使用される。サーバーアプリケーションｎ（１１０）は、任意の所定ポイントでシステム１００において実行されることのあるサーバーアプリケーションインスタンスの数を表している。サーバー２００は、複数のサーバーアプリケーションインスタンス１０２−１１０の間で複数のユーザーを管理する働きをするユーザーマネージャモジュール５０２も含む。ユーザーマネージャモジュール５０２は、図５において説明されており、サーバー２００にて実行される可能性のある複数のユーザーマネージャのうちの１つを表している。サーバー２００は、ＯＳ下位サーバーアプリケーション１０２−１１０のうちの１つのインスタンスを実行する。別の実施形態では、１つ以上のアプリケーションインスタンスを各々が含むＯＳの複数のインスタンスを実行することができる。

[0029]図１は、複数のサーバーアプリケーション１０２−１１０を例示しているが、他の実施形態では、例えば、ＯＳを含む、多数の異なるタイプのプログラムを交互に使用することができる。図１に例示したサーバーアプリケーション１０２−１１０は、例えば、１つ以上のサーバーファーム環境におけるように、１つのサーバー２００又は任意数のサーバーにおいて実行することができる。サーバーアプリケーション１０２−１１０は、各々、異なるサーバーアプリケーションのインスタンスを含むものであってもよいし、全て、１つのサーバーアプリケーションのインスタンスを含むものであってもよい。例えば、各サーバーアプリケーション１０２−１１０は、ウエブブラウジングアプリケーションの別々のインスタンスを含むことができる。

Ａ.サーバー
[0030]サーバーアプリケーション１（１０２）について更に詳述するに、典型的なサーバーアプリケーションインスタンスとして、サーバーアプリケーション１（１０２）は、アプリケーション１１２、プラグイン１１４、オーディオデータ生成器１１６、オーディオエンコーダーモジュール１２０、ビデオエンコーダーモジュール１２４及びコマンド処理モジュール１２６を含む。ビデオエンコーダーモジュール１２４は、フィードバックパラメータ１２５を使用する。

[0031]ビデオエンコーダー１２４は、アプリケーション１１２に機能的に結合され、アプリケーション１１２のユーザーインターフェース（ＵＩ）の連続するキャプチャ（１２２）を受け取り、ネットワーク１２８を介して送信するためビデオフレームへとエンコーディングするように構成される。ＵＩの連続するキャプチャ（１２２）は、図２に例示され説明されるような別のモジュール（画像管理モジュール２１６）により、アプリケーション１１２から取り込まれビデオエンコーダー１２４へと転送されるデータを含む。本明細書を通して使用される用語「ユーザーインターフェース」は、広範囲に亘る種々なコンピュータプログラムに関連した任意のユーザーインターフェースの全て又は部分を指している。

[0032]アプリケーションＵＩキャプチャ（１２２）のエンコーディングは、特定のエンコーディング又はビデオ圧縮フォーマットに限定されず、Ｈ.２６４の如きビデオ圧縮標準の使用からビデオ圧縮の全体的にカスタマイズされた形式のビデオ圧縮、ビデオ圧縮標準の変形形式等まで広範囲に亘るビデオ圧縮技法を含むことができる。

[0033]オーディオエンコーダーモジュール１２０は、アプリケーション１１２のオーディオデータ生成器１１６に機能的に結合され、ネットワーク１２８を介して送信するためオーディオデータ生成器１１６のオーディオキャプチャ１１８（例えば、オーディオストリーム）をエンコードされたオーディオストリームへと変換するように構成される。オーディオキャプチャ１１８は、オーディオデータ生成器１１６からオーディオエンコーダーモジュール１２０へと転送されるデータを含む。

[0034]オーディオデータ生成器１１６は、アプリケーション１１２に機能的に結合され、オーディオデータ添付アプリケーション１１２を生成するように構成される。プラグイン１１４は、アプリケーション１１２及びコマンド処理モジュール１２６に機能的に結合される。プラグイン１１４は、アプリケーション１１２とコマンド処理モジュール１２６との間のインターフェースを行うように構成される。

[0035]サーバー２００については、図２において更に説明する。

Ｃ.クライアント
[0036]システム１００は、クライアント１（４００）、クライアント２（１３２）、クライアント３（１３４）、及びクライアントｎ（１３８）まで広範囲に亘る種々な付加的なクライアント（省略符号１３６で表される）を含む多数のクライアントを含む。ここで、クライアントｎ（１３８）は、任意の所定の点においてシステムに関わることのあるクライアントの数を表している。図１に例示されるように、異なるクライアントは、異なる非関連クライアント装置を含む。

[0037]クライアント１（４００）について更に詳述するに、典型的なクライアントとして、クライアント１（４００）は、オーディオデコーダーモジュール１４２、ビデオデコーダーモジュール１４４、コマンド処理モジュール１４６、ビューイングアプリケーション１４８、及びスピーカー１５０を含むことができる。ビデオデコーダーモジュール１４４は、ビデオエンコーダーモジュール１２４によりエンコードされ、クライアント１（４００）による受信のためネットワーク１２８を通して送信されてきた連続するビデオフレームをデコーディングするように構成される。ビデオデコーダーモジュール１４４は、ビューイングアプリケーション１４８に機能的に結合され、クライアント１（４００）にそれらビデオフレームを表示するためデコードされたビデオフレームをビューイングアプリケーション１４８へと通信するように構成される。

[0038]クライアント１（４００）は、スピーカー１５０を含み、オーディオデコーダーモジュール１４２は、スピーカー１５０に機能的に結合される。オーディオデコーダーモジュール１４２は、オーディオエンコーダーモジュール１２０によりエンコードされ、クライアント１（４００）による受信のためネットワーク１２８を通して送信されてきたオーディオキャプチャをデコーディングするように構成される。オーディオストリームをデコーディングした後、オーディオデコーダーモジュール１４２は、クライアント１（４００）からオーディオ出力するためデコードされたオーディオをスピーカー１５０へと通信することができる。

[0039]ビューイングアプリケーション１４８は、ユーザー入力を受け取り、そのユーザー入力をコマンド処理モジュール１４６へと通信するように構成される。コマンド処理モジュール１４６は、そのユーザー入力を、ネットワーク１２８を介してアプリケーション１０２のコマンド処理モジュール１２６へと通信し戻すように構成される。コマンド処理モジュール１２６は、そのユーザー入力を、プラグイン１１４を介してアプリケーション１１２へと通信するように構成される。

[0040]プラグイン１１４は、図１に示したシステム１００を介してアプリケーション１１２のリモート対話型使用を行う。プラグイン１１４は、拡張であることもできる。別の実施形態では、アプリケーション１１２は、特別なプラグインを必要としない範囲で、本発明のクライアント−サーバーアーキテクチャーにて使用できるようにカスタマイズすることができる。更に別の実施形態では、プラグインも、どのような特別なアプリケーション変更も必要とされないようにすることができる。

[0041]コマンド処理モジュール１４６は、１つ以上のフィードバックパラメータ（１２５）をコマンド処理モジュール１２６へ通信するように構成される。コマンド処理モジュール１２６は、それら１つ以上のフィードバックパラメータ１２５をビデオエンコーダーモジュール１２４及びオーディオエンコーダーモジュール１２０へと通信し、連続するアプリケーションＵＩキャプチャ１２２及びオーディオキャプチャ１１８のエンコーディングがそれぞれそこで行われるようにするように構成される。それら１つ以上のフィードバックパラメータ１２５は、ネットワーク１２８の少なくとも部分に関連した帯域幅パラメータ、クライアント１（４００）のデバイスパラメータ又はクライアント１（４００）に対するユーザー入力を含む広範囲に亘るパラメータを含むことができる。

[0042]それら１つ以上のフィードバックパラメータ（１２５）は、推定又は測定帯域幅データポイントを含む帯域幅パラメータを含むことができる。典型的な帯域幅パラメータは、サーバー２００とクライアント１（４００）との間で移動する特定のパケットの測定に基づいた推定帯域幅（例えば、スループット値を得るため送出データがどのくらい移動時間により分割されるか）又はネットワークプロトコルからのものを含めてネットワーク１２８から得られる又はネットワーク１２８に関連した得られる他の帯域幅情報を含むことができる。それら１つ以上のフィードバックパラメータ（１２５）は、例えば、特定のフォーマット又は形式にて行われるエンコーディングのためのユーザー要求を含むクライアント１（４００）に対するユーザー入力を含むことができる。そのような要求は、ビューイングアプリケーション１４８により要求され通信されるものである。それ１つ以上のフィードバックパラメータ（１２５）は、クライアント１（４００）のディスプレイ解像度（例えば、ＣＧＡ、ＱＶＧＡ、ＶＧＡ、ＮＴＳＣ、ＰＡＬ、ＷＶＧＡ、ＳＶＧＡ、ＸＧＡ等）を含むことができる。それら１つ以上のフィードバックパラメータ１２５は、他のスクリーンパラメータ（例えば、スクリーンサイズ、リフレッシュ能力、バックライティング能力、スクリーン技法等）又はクライアント装置（例えば、デバイスプロセッサ、ＧＰＳ又は他の位置特定技法により可能とされる場合においてビデオフレーム、位置を記憶するのに使用することのできるメモリ等）の他のパラメータを含むことができる。前述した典型的なフィードバックパラメータのどれも、互いに又は他のフィードバックパラメータと組み合わせて使用することを排除していることを意味しているものではない。ある幾つかの実施形態では、ビデオエンコーダーモジュール１２４は、それらの１つ以上のフィードバックパラメータ（１２５）にそのビデオサンプルレートを少なくとも部分的に基づかせるように構成することができる。

[0043]図１に示す複数のクライアントは、各クライアント各々がそれ自身の１つ以上のフィードバックパラメータを有する異なるタイプのクライアント装置を含む可能性があるものとして、例示されている。

[0044]クライアント１（４００）については、図４において更に説明する。

[0045]当業者であれば、図１に例示したクライアントサーバーアーキテクチャーは、単なる実施例であり、本発明は、多くの他のアーキテクチャー及び環境を使用して実施されるものであることは、認識されよう。

[0046]図２は、一実施形態による本発明のある幾つかの態様を例示するブロック図である。サーバー２００は、ユーザーマネージャモジュール５０２、サーバーアプリケーション１（１０２）、アプリケーション１１２、プラグイン１１４、オーディオデータ生成器１１６、オーディオエンコーダーモジュール１２０、画像管理モジュール２１６、メモリ２１８、ビデオエンコーダーモジュール１２４（フィードバックパラメータ１２５を含む）、コマンド処理モジュール１２６及び整列モジュール２２４を含む。コマンド処理モジュール１２６は、クライアントインタープリタサブモジュール２２８を含み、プラグイン１１４は、クライアントインプリメンタサブモジュール２０８を含む。図１に例示した構成部分と同じ数をもって図２に例示された構成部分は、図１のそれらの各構成部分に対応しており、従って、それらの一般的動作は、繰り返されない。１つの実行アプリケーションがサーバー２００に関して例示されているのであるが、サーバーアプリケーション１０２は、サーバー２００にて実行される複数のサーバーアプリケーションの代表的インスタンスとして例示されており、それら複数のサーバーアプリケーションの各々は、それ自身の別々のクライアントと関連付けられている（クライアントは、この例図には示されていない）。

[0047]画像管理モジュール２１６は、アプリケーション１１２のＵＩを取り込み（そのＵＩがスクリーンに現れるとき）、そのキャプチャをメモリ２１８に記憶させるように作用する。スクリーンスクレイピングの如き任意のキャプチャ処理を使用することができ、画像管理モジュール２１６は、このキャプチャを任意の希望のレートで行うことができる。画像管理モジュール２１６は、又、アプリケーションＵＩの直前のキャプチャを現在のキャプチャと比較し、そのアプリケーションＵＩの特定の区域に何か変化が生じたかを決定する。このような比較動作のために、任意の画像／ビデオフレームマッチング処理を使用することができる。画像管理モジュール２１６は、この機能を繰り返し行うように作用する。

[0048]もし、画像管理モジュール２１６が問題の特定の区域における何らかの変化を検出する場合には、その問題の区域が変化したことを示すため、デルタフラグがセットされる。変化を検出するとき、画像管理モジュール２１６は、ＵＩレンダリングされたデータのネイティブフォーマットを圧縮及びクライアント装置への送信のためにより適したビデオフレームフォーマットへと変換する作用をする（例えば、カラースペース変換、データフォーマット変換等）。画像管理モジュール２１６は、その画像を再フォーマット化されたビデオフレームに対してリサイズするように作用する。図２の実施形態では、適用できるクライアント装置の複数のパラメータが１つ以上のフィードバックパラメータ１２５に含まれており、画像管理モジュール２１６がクライアントデバイスパラメータに基づいて再フォーマット化及びリサイズを行うことができるようにしている（適切なパラメータが画像管理モジュール２１６へ通信される）。

[0049]画像管理モジュール２１６は、デルタフラグがセットされているかを周期的にチェックする（そのサンプル間隔に基づいて）。もし、チェック中にデルタフラグがセットされている検出される場合には、メモリ２１８における再フォーマット化／リサイズされたビデオフレームが、クライアント装置へ送信するためビデオエンコーダーモジュール１２４によりエンコードされる。

[0050]コマンド処理モジュール１２６のクライアントインタープリタサブモジュール２２８は、クライアント装置４００から受け取られたデータを解釈し、ビデオエンコーダーモジュール１２４、オーディオエンコーダーモジュール１２０及びアプリケーション１１２に関して使用するためこのデータ（例えば、ユーザーコマンド等）を翻訳する作用をする。クライアントインタープリタサブモジュール２２８は、エンコーディングに使用するためフィードバックパラメータ１２５をビデオエンコーダーモジュール１２４及びオーディオエンコーダー１２０へと通すように作用する。

[0051]コマンド処理モジュール１２６のクライアントインタープリタサブモジュール２２８は、プラグイン１１４及びそのクライアントインプリメンタサブモジュール２０８に関して使用するためクライアント受信データを翻訳する作用をする。ユーザー入力を通信し返すのに、クライアント装置は、クライアント装置のスクリーンに対する座標（カーソル等の）をコマンド処理１２６へ通す。クライアントインタープリタサブモジュール２２８は、アプリケーションＵＩ及びクライアント装置のビューポイントに関する対応する位置を決定するように作用する。それから、クライアントインタープリタサブモジュール２２８は、そのクライアントインプリメンタサブモジュール２０８による使用のためその翻訳された座標をプラグイン１１４へ通信する。クライアントインプリメンタサブモジュール２０８は、通常のユーザー入力からアプリケーション１１２に適当なフォーマットへと翻訳し、それから、その翻訳された入力をアプリケーション１１２へと直接に投入するように作用する。

[0052]整列モジュール２２４は、ビデオエンコーダーモジュール１２４によりエンコードされたビデオフレームとオーディオエンコーダーモジュール１２０によりエンコードされたオーディオとを相関させてクロススタンプし、アプリケーション１１２のＵＩに関連したビデオフレーム及びオーディオストリームがクライアント装置４００において容易に整合されるようにする。画像管理モジュール２１６は、又、全ての画像にタイムスタンプ
するように動作し、オーディオデータ生成器１１６からオーディオを取り込む動作は、又、オーディオストリームにタイムスタンプするように動作し、これは共に、当業者には理解されるように、整列モジュール２２４による下流整列のためである。別の実施形態では、オーディオ及びビデオフレームの全ての整列／マッチングは、クライアント装置にて行うことができる。

[0053]当業者であれば、図２の例示は、単なる実施例であり、本発明は、多くの他の仕方にて実施できることは理解されよう。

[0054]図３は、一実施形態によるサーバー、オーディオサーバー及びクライアントを含む、本発明のアーキテクチャーオーバービューのある幾つかの態様を例示する機能ブロック図３００である。この実施形態では、オーディオは、専用オーディオサーバー３０４からクライアントへ送られる。機能ブロック図３００は、サーバー３０２、オーディオサーバー３０４及びクライアント３０６を含み、クライアント３０６は、ネットワーク３１０を介して（接続３１２及び３１６を介して）サーバー３０２及びオーディオサーバー３０４に機能的にリンクされる。サーバー３０２は、接続３０８を介してオーディオサーバー３０４に機能的にリンクされる。サーバー３０２は、アプリケーション３１８、プラグイン３２２、オーディオデータ生成器３２０、ビデオエンコーダーモジュール３２４（フィードバックパラメータ３２５を含む）、コマンド処理モジュール３２６、オーディオインターセプタモジュール３３０、ＰＩＤ（処理識別子）マネージャモジュール３３２及びタイムスタンプマネージャモジュール３３４を含む。

[0055]ビデオエンコーダーモジュール３２４は、図２にて説明したように動作し、ビデオエンコーダーモジュール１２４と類似である（及びフィードバックパラメータ１２５に関してフィードバックパラメータ３２５についても同様である）。ビデオエンコーダーモジュール３２４は、アプリケーションＵＩキャプチャ３２８をエンコードし、エンコードされたビデオフレームをクライアント３０６への送信のため通信する。アプリケーションＵＩキャプチャを得る処理において、その結果生ずるＵＩキャプチャは、タイムスタンプされる。タイムスタンプマネージャモジュール３３４は、ＵＩキャプチャのタイムスタンプを行う。コマンド処理モジュール３２６は、図２において説明されたように動作し、コマンド処理モジュール１２６と類似である。

[0056]１つの実行アプリケーションがサーバー３０２に関して例示されているが、アプリケーション３１８は、サーバー３０２にて実行される複数のアプリケーションの代表的インスタンスとして例示されており、それら複数のアプリケーションの各々は、それ自身のビデオエンコーダー及びコマンド処理モジュールを有しており、それ自身の別々のクライアントに関連付けられている。オーディオデータ生成器３２０は、アプリケーション３１８のためのオーディオストリーム（図示せず）をレンダリングする。オーディオインターセプタモジュール３３０は、オーディオサーバー３０４へリダイレクトするためこのオーディオストリームをインターセプト又はトラップし、そのオーディオストリームにタイプスタンプすることができる。タイムスタンプマネージャモジュール３３４は、オーディオストリームのタイムスタンプを行うことができる。オーディオインターセプタモジュール３３０は、カスタマイズされたＤＬＬ（ダイナミックリンクライブラリ）を使用して、オーディオストリームのこのようなリダイレクションを行うことができる。ＰＩＤマネージャモジュール３３２は、サーバー３０２にて実行される複数のアプリケーションの異なる処理ＩＤを検出して管理する作用をする。ＰＩＤマネージャモジュール３３２は、オーディオサーバーへリダイレクトされる各オーディオストリームにその関連するアプリケーションの処理ＩＤをスタンプすることができる。

[0057]オーディオサーバー３０４は、オーディオストリーム処理モジュール３３６及びＰＩＤ認証モジュール３３８を含む。オーディオストリーム処理モジュール３３６は、サーバー３０２にて実行されるアプリケーションから受け取られたオーディオストリームをエンコードし、希望の任意の変換（サンプルレート、ビット深さ、チャネルカウント、バッファサイズ等の変換）を行うように作用する。図３の実施形態では、各オーディオストリームをその宛先クライアント装置へと向けるのに、そのユーザーデータグラムプロトコルポートが使用され（図示せず）、他の実施形態では、他のプロトコルを使用することができる。オーディオストリーム処理モジュール３３６は、各オーディオストリームを、そのオーディオストリームの対応するクライアント装置（即ち、そのオーディオストリームに対応するビデオフレームを表示するクライアント装置）に関連したポートへと向ける。オーディオストリーム処理モジュール３３６は、ＰＩＤ認証モジュール３３８と関連して動作して、サーバー３０２から流れる複数のオーディオストリームを確証して適当なポートへと向けるようにする。

[0058]クライアント３０６は、ビデオデコーダーモジュール３４０、オーディオデコーダーモジュール３４２、コマンド処理モジュール３４４及びオーディオ／ビデオ同期モジュール３４６を含む。クライアント３０６がサーバー３０２からの適用できるオーディオ及びビデオストリーム（即ち、クライアント３０６に対して例示されたアプリケーションのオーディオ及びビデオストリーム）を受け取りデコードした後、オーディオ／ビデオ同期モジュール３４６は、両方のストリームのタイムスタンプを相関させ、オーディオデコーダーモジュール３４２及びビデオデコーダーモジュール３４０と関連して作動して、それぞれスピーカー３４８及びビューイングアプリケーション３５０への出力を同期化する。

[0059]当業者であれば、図３の例示は、単なる実施例であり、本発明は、多くの他の仕方にて実施できることが認識されよう。

[0060]図４は、一実施形態によるクライアントに関する本発明のある幾つかの態様を例示するブロック図である。クライアント４００は、ビデオデコーダーモジュール１４４、オーディオデコーダーモジュール１４２、オーディオ／ビデオ同期モジュール４０６、コマンド処理モジュール１４６、スピーカー１５０、ビューイングアプリケーション１４８、及び接続４１０、４１２及び４１４を含む。

[0061]ビデオデコーダーモジュール１４４は、接続４１２を介してエンコードされたビデオフレームを受け取り、一方、オーディオデコーダーモジュール１４２は、接続４１４を介してエンコードされたオーディオストリームを受け取る。オーディオ／ビデオ同期モジュール４０６は、それぞれスピーカー１５０及びビューイングアプリケーション１４８を介して同期出力するため、オーディオストリーム及びビデオフレームのタイムスタンプ又は他のタイプの識別子のマッチングを行うように作用する。オーディオデコーダーモジュール１４２、ビデオデコーダーモジュール１４４及びビューイングアプリケーション１４８は、全て、ビデオエンコーディング、オーディオエンコーディング等のサンプルレート及び／又は圧縮を変えることを含めて、コマンド処理モジュール１４６へのフィードバックを行い、サーバー側アプリケーションへフィードバックパラメータを通信し返すように作用することができる（図４には例示せず）。

[0062]コマンド処理モジュール１４６は、あるセッションの開始時又はあるセッション中にビデオ及び／又はオーディオエンコーディングに使用するためクライアント４００のフィードバックパラメータを通すように作用する。このようなフィードバックパラメータとしては、次のパラメータ、即ち、ディスプレイ解像度、スクリーンサイズ、プロセッサ識別又は能力、メモリ能力／パラメータ、スピーカー能力等のうちの１つ以上のものを含むことができる。

[0063]ビューイングアプリケーション１４８は、サーバー側アプリケーションのＵＩの部分の連続するビデオフレームを表示する。ビューイングアプリケーション１４８は、サーバーへ送信し返すため、ユーザーコマンドを含むユーザー入力コントロールのコマンド処理モジュール１４６への通信を行うように作用する。サーバーへ返されるクライアントユーザー入力コントロールとしては、例えば、キーボード（種々な形式におけるスクリーンベースの又は物理的キーボード）、スクロールホイール、ナンバーパッド、スタイラスベースの入力、タッチスクリーン又はタッチパッド等からの入力を含むことができる。ビューイングアプリケーション１４８は、テキストエントリーのためローカルテキストボックスを開けるが如き送出のため特定のユーザー入力を集約する作用をする。

[0064]当業者であれば、図４の例示は、単なる実施例であり、本発明は、多くの他の仕方にて実施することができるものであることは認識されよう。

[0065]図５は、一実施形態によるマルチユーザーソフトウエアアーキテクチャーのある幾つかの態様を例示する図５００である。ユーザーマネージャモジュール５０２は、ワーカースレッド５０４、ワーカースレッド５０６及び広範囲に亘る数の付加的なワーカースレッド（省略符号５０８によって表される）を含み、「ワーカースレッドｎ」は、ワーカースレッド５１０により表されている。ワーカースレッド５１０は、任意の所定のポイントでシステムにて実行されることのあるワーカースレッドの全数を表している。各ワーカースレッドは、アクティブユーザーのリストに対応しており、アクティブユーザーのリストは、種々な数のアクティブユーザーを含むことがあり得る。図５に例示されるように、ワーカースレッド５０４は、スレッドサイクル５１２に対応し、ワーカースレッド５０６は、スレッドサイクル５１４に対応し、省略符号５０８により表された可変数のワーカースレッドは、省略符号５１８により表された同じ可変数のスレッドサイクルに対応し、ワーカースレッド５１０は、スレッドサイクル５１６に対応している。図５に例示されるように、ワーカースレッド５０４は、ユーザー１（５２０）、ユーザー２（５２２）、ユーザー３（５２４）及びユーザー４（５２６）を通して循環し、ワーカースレッド５０６は、ユーザー５（５２８）、ユーザー６（５３０）及びユーザー７（５３２）を通して循環し、ワーカースレッド５１６は、ユーザー８（５３４）、ユーザー９（５３６）、ユーザー１０（５３８）、ユーザー１１（５４０）及びユーザー１２（５４２）を通して循環する。図５に例示したワーカースレッドによって支援されるユーザーの数は、任意の時点でのスナップショットを表しているものであり、任意の所定のスレッドにより支援されるユーザーの数は、動的に変化するものである。

[0066]ユーザーマネージャモジュール５０２は、システムに加えられた更に別のユーザーを管理するため付加的なワーカースレッドをインスタンス化する前に有限数のワーカースレッドをインスタンス化するように設定することができる。図５に例示した全アーキテクチャーにおけるワーカースレッドの数は、種々な実施形態により変化するものである。ワーカースレッド当たりに割当てられるアクティブユーザーの数に関するパラメータも、種々な実施形態により変化するものである。

[0067]ユーザーマネージャモジュール５０２は、アプリケーションの複数のインスタンス（図１に例示されるように）が実行されるようなサーバー（図１に例示されるように）に対して作動する。従って、ユーザーマネージャモジュール５０２は、複数のアプリケーションインスタンスの環境において複数のユーザーを管理するように作用する。図１の全システムに対して新しいユーザーが導入されるとき、その新しいユーザーは、特定のクライアントと特定のサーバー側アプリケーションとの間のインターラクションを行うためワーカースレッド（５０４−５１０）に割り当てられる。

[0068]図５に例示した実施形態は、複数のユーザーが単一のスレッドに割り当てられているところを例示しているのであるが、他の実施形態では、単一のユーザーをそれ自身の単一のスレッドに割り当てることができる。他の実施形態では、全システムの現在のローディング／使用、本発明の実施形態をオペレーティングする各サービスのプロバイダーのユーザサービスポリシー等の如き１つ以上のファクタに依存して、ユーザーを共有スレッド又は専用スレッドへと割り当てることができる。

[0069]ユーザーマネージャモジュール５０２は、各ワーカースレッドがアクティブユーザーのそれらの各リストを通して循環して各ユーザーのための１つのアクティブイベントを処理するとき、多くの仕方にて複数のユーザーのロードバランシングを行う。処理されるアクティブイベントとしては、（ａ）クライアントへの１つのビデオフレーム更新の送出又は（ｂ）クライアントのビューイングアプリケーション及びサーバー側アプリケーション／ＵＩに関する状態情報の更新がある。ユーザー１が図１のサーバーアプリケーション１（１０２）に関連付けられるような場合について例示すると、ワーカースレッド５１２は、前述の（ａ）及び（ｂ）を行うため、ユーザー１（５２０）からユーザー４（５２６）の各ビデオエンコーダー／コマンド処理モジュールの間でタイムスライスを行い、この状態では、ビデオエンコーダーモジュール１２４及びコマンド処理モジュール１２６は、ユーザー１（５２０）のビデオエンコーダー／コマンド処理モジュールを含む。オーディオデータが送られるべき時には、クライアントへそのエンコードされたオーディオストリームを連続して送るため、別のスレッド（図示せず）がオーディオエンコーダーモジュール１２０に機能的に結合される。

[0070]このように作動することにより、どの単一ユーザーも、処理集中セッション（例えば、高解像度、高フレームレートビデオに対して）の結果として、別のユーザーが同じスレッドによるサービスを受けるような事態を被ることはなくなる。これについては、図７に関して以下に更に説明する。他の実施形態では、ユーザー当たり２以上のアクティブイベントを処理することができる。他の実施形態では、適用できるユーザーに対する下位アプリケーションアクティビティのレベル、本発明の実施形態をオペレーティングする各サービスのプロバイダーのユーザーのサービスポリシー等を含む広範囲に亘るファクタに基づいて、ユーザー当たり可変数のアクティブイベントを処理することができる。

[0071]ユーザーマネージャモジュール５０２は、処理集中ユーザー及び処理軽量ユーザーの間のロードバランシングを行うため、異なるワーカースレッドの間で特定のユーザーを移すことができる。例えば、もし、１つのワーカースレッドによってサービスを受ける複数のユーザーが高フレームレートビデオのサービスを受ける必要がある場合には、ユーザーマネージャモジュール５０２は、そのような１つ以上のユーザーを、処理軽量ユーザーのみにサービスしている別のスレッド又は処理軽量ユーザーに主としてサービスしている別のスレッドへと移すことができる。別のスレッドをこの目的のためインスタンス化することもできる。当業者であれば分かるように、ユーザーは、オブジェクトとして取り扱うことができ、オブジェクトがスレッドの間で転送される時に、別のスレッドへと移すことができる。このようなオブジェクト移動のタイミングは、ユーザーの知覚認識の混乱を最小とするため、クライアント装置のビューイングアプリケーションによるビデオフレームの表示の特定の継ぎ目とすることができる。

[0072]当業者であれば、図５の例示は、単なる例示であり、本発明は、多くの他の仕方にて実施できることが認識できよう。

[0073]図６は、一実施形態による連続するビデオフレームを取り込むためのある幾つかの態様を例示するフローチャート６００である。アプリケーションへのプラグインにより又はアプリケーション自体により、最初に、オペレーション６０２（メモリへのアプリケーションＵＩのレンダリング）が行われる。オペレーション６０２は、アプリケーションのＵＩを、そのＵＩがスクリーンに現れるときに、取り込み、そのキャプチャをメモリバッファ（図２の２１８）にセーブするように作動する。そのＵＩをスクリーンに実際に表示する必要はないが、使用することがある。それから、オペレーション６０４（前のアプリケーションＵＩキャプチャからのデルタ変化があるか？）は、何らかの変化が生じているかを決定するため、そのアプリケーションＵＩの直前のキャプチャを現在のキャプチャと比較するように作動する。このようなデルタ変化チェッキングオペレーションは、例えば、現在のＵＩキャプチャのピクセルブロックをハッシングすること及びそれらハッシュ値を前のＵＩキャプチャから生成されたアナログピクセルハッシュテーブルと比較することを含む広範囲の多数の仕方にて行うことができる。この時、それらハッシュ値は、例えば、連続するビデオフレームのブロックのマッチング、基準フレームに対するブロックのマッチング等、使用される任意の圧縮方法において可能性のある使用のためにも利用することができる。別の仕方として、例えば、そのアプリケーションにより、オペレーション６０２の前にある変化が起きる時を、サーバーに通知することができる。

[0074]もし、オペレーション６０４により、デルタ変化がないと決定される場合には、オペレーション６０２が繰り返し行われる前に、オペレーション６０６（遅延）がタイマー（図示せず）により実施される。もし、オペレーション６０４により、デルタ変化があると決定される場合には、オペレーション６０８（適当なフォーマットへの変換）が行われる。オペレーション６０８は、そのＵＩレンダリングされたデータのネイティブフォーマットを、クライアント装置に表示するためネットワークを通しての送信及び圧縮により適した別のフォーマットへと変換するように作動する（例えば、カラースペース変換、データフォーマット変換等）。

[0075]それから、オペレーション６１０（リサイズ）が行われる。オペレーション６１０は、そのＵＩレンダリングされたデータに固有のネイティブスクリーンサイズを、クライアント装置（セルラーホン、ハンドヘルドコンピュータ等）に表示するのにより適した別のサイズへとリサイズするように作動する。オペレーション６１０は、サーバー側アプリケーションへ通信されるクライアント装置の１つ以上のフィードバックパラメータ（図示せず）及びその添付ビデオエンコーダインスタンス化を利用することができる。それから、オペレーション６１２（エンコーダーのためメモリに記憶）が続いて行われ、その変換されたビデオフレームがビデオエンコーダーによる使用のために記憶させられる。それから、オペレーション６１４（必要とされるビデオ更新のフラグ）が続いて行われ、ビデオ更新が必要とされるかを決定するオペレーション（図７のオペレーション７１２（ビデオ更新が必要とされるか？）参照）による使用のための指示がセットされる。それから、オペレーション６１６（遅延）が続いて行われ、これは、オペレーション６０２が繰り返し行われる前に、タイマー（図示せず）により実施することができる。

[0076]当業者であれば、図６の例示は、単なる実施例であり、本発明は、他の多くの仕方にて実施することができるものであることは認識できよう。

[0077]図７は、一実施形態による連続するビデオフレームを送るためのある幾つかの支援態様を例示するフローチャート７００である。ユーザーＮの更新、７０２は、ステップのシーケンスの開始を表しており、これらステップのシーケンスは、アクティブユーザーの適用できるワーカースレッドのリストにおける各ユーザーに対して図５のワーカースレッドにより行われるステップを表している。ワーカースレッドは、最初に、オペレーション７０４（チャネルのリードバック）を行う。それから、オペレーション７０６（ユーザーについて処理すべきデータがあるか？）が続いて行われ、ここでは、ユーザーＮに対して適切なものが処理する必要のあるネットワークから来ているかの決定がなされる。ユーザーＮに適切なデータが検出されることに応答して、オペレーション７０８（ネットワークイベントの処理）が続いて行われる。ユーザーＮに適切な入来データとしては、例えば、サーバー側アプリケーションＵＩの特定の部分に対するズームインの試みの如き、クライアント装置へのユーザー入力に関する情報がある（クライアント装置にて実行されるビューイングアプリケーションにて表示されるサーバー側アプリケーションＵＩのビデオフレームにより示されるような）。オペレーション７０８は、そのような処理される情報をその次の宛先へと通信することを含むことができ、例えば、もし、ズームコマンドがクライアントから送られる場合には、そのズームコマンドは、そのワーカースレッドがその次の適用できるオペレーションへと進む前に、適当に処理されてサーバー側アプリケーションへと送られる。

[0078]オペレーション７０８（ネットワークイベントの処理）の後、又は、オペレーション７０６（ユーザーに対する処理すべきデータはあるか？）による否定的決定の後、オペレーション７１０（更新が必要とされるか？）が行われる。オペレーション７１０は、適用できるユーザーに対する最後のビデオフレームが送られた時に、又は、より特定すると、オペレーション７１２（ビデオ更新が必要とされるか？）が最後に行われた時にセットされているカウンター（図示せず）に依存する。もし、そのカウンターが終点にまだ達していない場合には、それらオペレーションを行うワーカースレッドは、オペレーション７１８（Ｎのインクリメント）に進み、次の適用できるユーザーに対する図７に例示したステップのシーケンスを開始させる。カウンターは、サーバーからクライアントへ通信される連続するビデオフレームに対するフレームレート、より特定すると、許容フレームレートを制御する。これについて、オペレーション７１２（ビデオ更新が必要とされるか？）に関して更に後述する。例えば、秒当たり１０回の許容フレームレートの場合には、カウンターは、１００ミリ秒まで（例えば、１００ミリ秒から零まで、又はその逆）カウントするように設定される。

[0079]オペレーション７１０（更新が必要とされるか？）が肯定的に決定される場合には、オペレーション７１２（ビデオ更新が必要とされるか？）が行われる。オペレーション７１２は、図６に関して説明したように、「ビデオ更新が必要とされるか？」のフラグをチェックすること、又はあるそのような同様のオペレーションを含むことができる。オペレーション７１２は、クライアントのビューイングアプリケーションにおいてクライアントにより表示されるサーバー側アプリケーションの部分に何か変化があるかを決定するように作動する。もし、オペレーション７１２が肯定的に決定される場合には、オペレーション７１４（必要とされるビデオ情報を取得する）が行われる。オペレーション７１４は、アプリケーションＵＩの最後に送信されたビデオフレームからそのアプリケーションＵＩのビデオフレームを更新するのに必要とされるビデオフレーム情報を得るように作動し、このオペレーションは、ビデオフレーム／圧縮標準、カスタマイズされた方法、及びそれらの組み合わせたものを含む広範囲に亘るビデオフレーム／圧縮技法を利用することができる。

[0080]オペレーション７１４（必要とされるビデオ情報を取得する）が行われた時、オペレーション７１６（ネットワークイベントを送る）が行われる。オペレーション７１６は、クライアントへ、１つのビデオフレーム更新、又は、クライアントのビューイングアプリケーション及びサーバー側アプリケーション／ＵＩに関する更新状態情報を送るように作動する。オペレーション７１６は、ユーザーＮのための適用できるデータを、これを行うためのユーザーＮのネットワーク接続のためのキューに入れることができる。

[0081]もし、オペレーション７１２が否定的に決定されており、クライアントのビューイングアプリケーション及びサーバー側アプリケーション／ＵＩに関する更新状態情報がある場合には、オペレーション７１６（ネットワークイベントを送る）がさらに行われる。

[0082]ユーザー当たり１つのビデオフレーム更新（又は状態情報更新）のみを送信することにより、複数のユーザーにサービスしているワーカースレッドは、１つのユーザーがワーカースレッドの時間を相当に消費してしまって他の特定のユーザーに障害を与えるようなことなく、そのアクティブユーザーリストにおけるユーザーの全てを通して循環してサービスを与えるようにすることができる。その支援されるユーザーの全てに亘るワーカースレッドのロードが増大するにつれて、そのワーカースレッドのアクティブユーザーの全てに対するサービス時間は、次第に増大する。従って、ロードバランシングがこのようにして本来的に埋め込まれている。付加的なロードバランシングについては、図５に関して説明される。

[0083]当業者であれば、図７の例示は単なる実施例であり、本発明は、他の多くの仕方にて実施できることが認識されよう。

[0084]図８は、一実施形態によるクライアントサーバー交換８００のある幾つかの態様を例示する図である。クライアントサーバー交換８００は、サーバー８０２とクライアント装置８０４との間のセッション交換を示している。ここに説明するように、サーバー８０２は、任意のサーバー側マシンであることができ、図８に記述されるようなオペレーションを行うように関連して動作するような、１つのファシリティーに配置されるか又は地理的に分散されるかする多数のサーバーを含むことができる。これらのサーバーは、認証サーバー、データベースサーバー等を含むことができる。

[0085]クライアント装置８０４は、ユーザーがクライアント装置８０４にてビューイングアプリケーションを起動させるオペレーション８０６でクライアントサーバー交換８００を開始させる。（用語「クライアント装置」は、図８に関してのみ使用される。何故ならば、クライアント装置のパラメータについて本明細書を通じて説明されており、用語「クライアント」は、入れ換え可能なようにも使用できるからである。）それから、そのビューイングアプリケーションは、オペレーション８０８によりネットワーク接続を介してサーバー８０２への接続を開くようにする。オペレーション８０８は、当業者には理解されるように、１つ以上の標準インターネットプロトコル又はそれらの変形を使用する。オペレーション８０８は、このセッションにおけるユーザー８０２による使用のため、ユーザーのアイデンティティ（例えば、電話番号、キャリアアカウント等による）及びクライアント装置（８０４）のディスプレイ解像度及びサイズをサーバー８０２へ通すように作動する。それから、サーバー８０２は、オペレーション８１０を行い、このオペレーション８１０は、サーバーアプリケーションインスタンスを起動させて用意し、このサーバーアプリケーションは、ユーザーの初期設定に基づいてカスタマイズされる。この実施形態では、ユーザーの初期設定は、それらがユーザーのアイデンティティと関連付けられているようなデータベース（図示せず）からフェッチされる。オペレーション８１０につき、そのサーバーアプリケーションは、仮想フレームバッファにおいてレンダリングされる。別の実施形態では、サーバーアプリケーションは、スクリーンへレンダリングされる。

[0086]それから、オペレーション８１２が続いて行われ、このオペレーションでは、オーディオ／ビデオエンコーダーモジュール及び付属コマンド処理モジュールが起動され、クライアント装置８０４に対するカスタマイズされたエンコーディングのため、クライアント装置（８０４）のディスプレイ解像度及びサイズが供給される。コマンド処理及びエンコーダーモジュールには、又、ユーザーのアイデンティティに関連したサービスのレベルが供給され、特定のユーザーには、このシステムを使用する他のユーザーに対する優先レベルが供給される。その後、オペレーション８１４において示されるように、ビデオエンコーダーは、サーバーアプリケーションのＵＩのビデオフレームを変換しエンコードすることができる（例えば、そのサーバーアプリケーションによりレンダリングされたビデオフレームを、そのサーバーアプリケーションのネイティブレンダリング解像度からＱＶＧＡ解像度へと変換すること。何故ならば、クライアント装置８０４は、ＱＶＧＡ解像度を支援しているからである。）。このビデオエンコーダーモジュールは、又、クライアント装置（８０４）のスクリーンサイズ内に適当にはまり込み又はそれと適当に協働するようにするため、サーバーアプリケーションのネイティブＵＩサイズレンダリングをリサイズする。オーディオエンコーダーモジュールは、クライアント装置８０４のスピーカー能力に基づいてサーバーアプリケーションのオーディオストリーム出力をエンコードする（例えば、もし、クライアント装置がセルラーホンであることが知られている場合には、オーディオは、エンコードされた品質がその特定の電話のスピーカー能力又はセルラーホンに対して使用されるデフォルトレベルを越えないようにエンコードされる。）。矢印８１６は、クライアント装置８０４へのエンコードされたオーディオ及びビデオの通信を例示している。

[0087]オペレーション８１８がその後に続いて行われ、このオペレーションでは、ビューイングアプリケーションのデコーダーモジュール（オーディオ及びビデオ）が受信したオーディオ及びビデオフレームをデコードする。オペレーション８２０により示されるように、ビデオフレームは、クライアントのビューイングアプリケーションにて表示され、オーディオは、クライアント装置（８０４）のスピーカーへと出力される（オーディオが存在しクライアント８０４がミュートにない場合）。

[0088]オペレーション８２２がその後に続いて行われ、このオペレーションでは、クライアント側のオペレーション８２４でも表されているように、サーバー８０２とクライアント装置８０４との間の一連の発信インターラクション（矢印８２６及び８２８により表されている）を示している。オペレーション８２２は、ＵＩ又はオーディオ出力が変化する時のみ、サーバーアプリケーションが情報をエンコーダーモジュールへ送り、エンコーダーが、クライアント装置８０４へ送信するためこの情報をエンコードすることを示している。従って、もし、サーバーアプリケーションのＵＩ又はオーディオに関して何も変化がない場合には、オーディオ／ビデオ情報はエンコードされず、クライアント装置８０４へ送られない。こうして、サーバー（８０２）のビデオエンコーダーは、ＵＩの変化に基づき、非同期的にビデオフレームを通信する。ビデオは、ＵＩ変化を表示するためのビデオフレームとして送られるのであり、ビデオフレームフォーマットの外のコマンドとして送られるのではない。

[0089]オペレーション８２４は、仮想アプリケーションとのユーザー対話を示しており、ユーザーの入力は、パラメータへと変換され、サーバーアプリケーションへと戻されるように示されている。オペレーション８２２は、更に、サーバー側コマンド処理モジュールが、サーバーアプリケーションＵＩにて動作するようにユーザー入力パラメータを翻訳し、サーバーアプリケーションＵＩがそれに応じて変化することを示している。オペレーション８２４は、更に、仮想アプリケーションへのユーザー入力から生じたエンコードされたオーディオ及びビデオが受信され、デコードされ、ビューイングアプリケーションにて表示されることを示して、この循環シーケンスを完了する。

[0090]当業者であれば、図８の例示は、単なる実施例であり、本発明は、多くの他の仕方にて実施することができるものであることは認識されよう。

[0091]図９は、一実施形態によるクライアント−サーバー交換９００のある幾つかの態様を例示する図である。クライアント−サーバー交換９００は、サーバー９０３とクライアント９０４との間のセッション交換を示しており、エンコーダー／コマンド処理モジュール９０２とアプリケーション９０６（共にサーバー９０３にて実行される）との間の付属する交換もまた示している。アプリケーション９０６は、この実施形態ではウエブブラウジングアプリケーションを含む。エンコーダー／コマンド処理モジュール９０２は、オーディオ及びビデオエンコーダーモジュール、及びコマンド処理モジュールを含む。当業者には理解されるように、エンコーダー／コマンド処理モジュール９０２との交換とは、特定すると、これらモジュールのうちの１つとの交換を含むものである。別の実施形態では、エンコーダー／コマンド処理モジュール９０２として同様に置かれた機能要素は、ビデオエンコーダーモジュール及びコマンド処理モジュールを含むことができるが、オーディオエンコーダーモジュールは含まない。ここに説明するように、サーバー９０３は、任意のサーバー側マシンを指しており、図９に記述しているオペレーションを行うように動作するような、１つのファシリティーに配設され又は地理的に分散された多数のサーバーを含むことができる。これらのサーバーは、認証サーバー、データベースサーバー等を含むことができる。

[0092]クライアント９０４は、接続を開くオペレーション９０８でクライアントサーバー交換９００を開始させる。サーバー９０３は、接続確認のオペレーション９１０で応答する。それから、クライアント９０４は、オペレーション９１２を通して、スクリーンサイズ及び他の装置パラメータを含めて、その能力をエンコーダー／コマンド処理モジュール９０２へ送る。それら装置パラメータは、デバイスプロセッサ、メモリ、スクリーン特性等を含む広範囲に亘る種々なデバイスパラメータを含むことができる。それから、クライアント９０４は、ＵＲＬを、オペレーション９１４を通して送り、これは、セーブされたＵＲＬ（例えば、ホームページ）又はクライアント９０４のユーザーにより入力されたＵＲＬを含むことができる。それから、エンコーダー／コマンド処理モジュール９０２は、そのＵＲＬを、オペレーション９１６を通してアプリケーション９０６へ通信し、それから、アプリケーション９０６は、オペレーション９１８により、そのＵＲＬをロードする。アプリケーション９０６は、又、そのＵＲＬに関連したウエブページの幅（ｗ）及び高さ（ｈ）を、オペレーション９２０によりエンコーダー／コマンド処理モジュール９０２へと通す。それから、エンコーダー／コマンド処理モジュール９０２は、オペレーション９２２により、ウエブページサイズ並びにクライアントのビューポートを特徴付けるパラメータ、例えば、コーナー座標（ｘ、ｙ）及び関連ズームファクタ（ｚ）を含むクライアントスクリーンで見られるビューポートを、クライアント９０４へ通信する。

[0093]それから、当業者に知られた多くの技法に従って、オペレーション９２４を通して、ウエブページビューポート（ビューポートが関連するブラウザＵＩの部分）のスクリーンキャプチャが行われる。それから、ビューポートを通して見ることのできるウエブページのビデオフレームが、オペレーション９２６によりクライアント９０４へ通信される。それから、可変サンプル間隔９２８の後、その後のスクリーンキャプチャ９３０が行われ、その関連するビデオフレームは、オペレーション９３２を通して通信される。可変要素を示すのに普通に使用される矢印記号９２９は、この新規な特徴を示すため可変サンプル間隔９２８に交差するようにして例示されている。

[0094]非同期フィードバックチャネルにより、オペレーション９３４を通してフィードバックが行われる。このフィードバックは、クライアントデバイスパラメータ、ユーザー入力パラメータ及び／又はサーバー９０３とクライアント９０４との間でやり取りされるパケットの測定値に基づいた帯域幅パラメータの如き推定帯域幅パラメータを含む１つ以上のフィードバックパラメータに基づいて、サンプル間隔９２８を変えるのに使用される。ＲＴＣＰプロトコル又はそのような同様のプロトコル（標準化された又はカスタマイズされた）が、オペレーション９３６により例示されているように、このようなフィードバックを与えることに関して使用される。省略符号９３８及びサイクル９４０は、ビデオフレームをクライアント９０４へ送るサーバー９０３とのインターラクションの反復性を例示している。

[0095]サンプル間隔９２８は、見られる下位ウエブページの変化レートに基づいて少なくとも部分的に変えることもできる。例えば、もし、クライアント９０４により見られる下位ウエブページにおいて少しの変化しか検出されないか、又は全く変化が検出されない場合には、フレームサンプル間隔は上向きに調整される。同様に、非常にダイナミックなウエブページ又はウエブページ内のコンテンツの場合には、フレームサンプル間隔は下向きに調整される。

[0096]クライアント９０４のユーザーは、オペレーション９４２にて示されるように、ウエブページの別の部分を見るため、ウエブページが見られるビューポートを移動することができ、この場合において、ｘ′及びｙ′は、そのビューポートの新しいパラメータを含む。それから、その新しいビューポートに整合するウエブページの新しい部分が、オペレーション９４４を通して取り込まれ、その新しいビューポートのビデオフレームが、オペレーション９４６を通してクライアント９０４へ通信される。

[0097]クライアント９０４のユーザーは、オペレーション９４８において示されるように、そのビューポートを再び移動することができ、この場合において、ｘ″及びｙ″は、そのビューポートの新しいパラメータを含む。この時、その新しいビューポートは、そのサーバーブラウザウインドウに表示されるところを越えて延在してしまい、従って、ブラウザ自体、オペレーション９５０にて示されるように、ウエブページの希望の部分を取り込むためスクロールしなければならない。オペレーション９５２を通して示されるように、適当にスクロールした後、その新しいビューポートのスクリーンキャプチャが得られ、その結果のビデオフレームがオペレーション９５６を通して通信される。

[0098]クライアント９０４のユーザーは、オペレーション９５８を通して示されるように、マウス又はマウス均等物（例えば、タッチスクリーン上のフィンガータップ等、多方向ボタン、トラックポイント、カーソル移動スタイラス等）を使用することもでき、ここでは、マウスダウン運動がなされ、そのマウスの新しい座標が（ａ,ｂ）として通される。クライアント９０４は、このようなオペレーションにおいて、クライアント装置のスクリーンに対する座標を、エンコーダー／コマンド処理モジュール９０２へと戻し、エンコーダー／コマンド処理モジュール９０２は、ビューポート及び下位ウエブページに対する対応する位置を決定する。図９に記述されている実施形態では、サーバー９０３は、下位ウインドウズＯＳを実行して、適当な位置情報を有するマウスメッセージがブラウザ９０６に関連したウインドウへと入れられるようにする（レンダリングのために使用される実際のスクリーンがあてもなくても）。これは、オペレーション９６０を通して例示されており、スクリーンカーソルは、その結果として、アプリケーション９０６を移動させ、前述したように、ビデオフレームにてクライアント９０４へと通信し返される。他のオペレーティングシステムに関連して使用される他の実施形態では、当業者により理解されるように、利用できる場合にはそのような同様の機能を使用することができ、又は、ある幾つかの類似の他のそのような技法を使用することができる。

[0099]オペレーション９６２、９６４、９６６及び９６８は、類似の仕方にて動作する同様のマウス駆動イベントを示している。他の入力駆動コントロールイベント（キーパッドエントリの如き）も同じ仕方にて動作することができる。９７０、９７２、９７４、９７６にて示した種々なタイプのオペレーションについて前述しており、省略符号９８０及びサイクル９８２は、クライアント９０４とサーバー９０３との間のセッションが続く限り、インターラクションを発信するところを例示している。

[0100]当業者であれば、図９の例示は単なる実施例であり、本発明は、その他の多くの仕方にて実施することのできるものであることは認識されよう。

[0101]図１０は、一実施形態によるリモートインターラクションのためのクライアント−サーバーアーキテクチャーに関連して使用するに適した典型的なコンピュータシステムを例示している。図示されるように、コンピュータシステム１０００は、サーバーとして動作するコンピュータ又はクライアントとして動作するコンピュータを表すことができ、図１０に例示した一般的構成部分は、当業者により理解されるように、各個々の表現でもって変えることのできるものである。コンピュータシステム１０００は、１つ以上のプロセッサ１００２を含むことができ、又、システムメモリ１００４を含むことができる。更に又、コンピュータシステム１０００は、１つ以上のデバイスの形の記憶装置１００６（ハードドライブ、光又は別のタイプのディスク、フラッシュメモリを含む電子メモリ等の如き）、入力／出力装置１００８（キーボード（種々な形式のスクリーンベースの又は物理的なもの）、スクロールホイール、ナンバーパッド、スタイラスベースの入力、タッチスクリーン又はタッチパッド等）として）、及び通信インターフェース１０１０（ＬＡＮ、ＷＡＮ、ワイヤード又はワイヤレスネットワーク等に接続するための）を含むことができる。これらの要素は、１つ以上のバスで表されるシステムバス１０１２を介して互いに結合される。システムバス１０１２が複数のバスを表す場合には、それら複数のバスは、１つ以上のバスブリッジ（図示せず）によりブリッジされる。ある幾つかの実施形態においてクライアント装置を表す時には、プロセッサ１００２は、コントローラを含むことができ、システムメモリ１００４及び記憶装置１００６は、１つの密着形態メモリ構成部分を含むことができる。

[0102]これらの要素の各々は、当業分野にて知られているそれらの通常の機能を果たす。種々な実施形態では、コンピューティングシステム１０００は、少なくとも部分的により大きなコンピューティングシステムへと組み入れることができる。システムメモリ１００４及び記憶装置１００６は、本発明の１つ以上の前述した実施形態の種々な態様を実施するプログラミング命令のワーキングコピー又は永久コピーを記憶するのに使用される。前述したどのソフトウエア部分も、別々のソフトウエアモジュールを含む必要はない。前述したどのソフトウエア構成も、単なる実施例であり、本発明の種々な実施形態の範囲内でその他の構成を考えることができるものである。用語「エンジン」は、ここでは、関連する機能又は諸機能を果たす任意のソフトウエア又はハードウエア構成、又はそれらの組合せを示すのに使用されている。

[0103]本発明のある幾つかの実施形態に関して、モジュールは、種々な機能を実施するものとして説明される。代替実施形態では、それらモジュールの部分又は全ては、ハードウエアにて実施することができ、例えば、代わりに１つ以上のアプリケーション特定用途向け集積回路（ＡＳＩＣ）を使用して実施することができる。

[0104]前述したことの全てにおいて、そのような実施形態は、単なる例示の目的だけのものであり、本発明の必須の特性から逸脱せずに、他の実施形態も同様に提供することができることは、理解されよう。

[0105]本発明について、１つの可能な実施形態に関して特に詳細に説明してきた。当業者であれば、本発明は、他の実施形態にて実施することができることは理解されよう。先ず第１に、各構成部分の特定の名称、用語の使用、属性、データ構造又はその他のプログラミング又は構成的特徴は、それに限定するものでも重要なものでもなく、本発明又はその特徴を実施する機構は、種々な名称、フォーマット又はプロトコルを有することができる。更に又、本システムは、前述したように、ハードウエアとソフトウエアとの組合せにより実施でき、又は、全体的にハードウエア要素にて実施することができる。又、ここで説明したような種々な構成部分の間への機能の特定の分担は、単なる例示であり、これに限定するものでなく、単一のシステムにより行われる機能を複数の構成部分により行うこともできるし、複数の構成部分により行われる機能を単一の構成部分により行うようにすることもできる。

[0106]前述の説明のうちのある幾つかの部分は、本発明の特徴をアルゴリズム及び情報に関するオペレーションの記号的表現の形にて与えている。これらのアルゴリムによる記述及び表現は、データ処理における当業者が、当業分野における他の当業者に対して自己の成果を最も効果的に伝えるために使用される手段である。これらのオペレーションは、機能的又は論理的に説明されるのであるが、コンピュータプログラムによって実施されることは理解されよう。更に又、これらのオペレーションの構成をモジュールとして示すこと又は機能的名称にて示すことも、その一般性を損なうことなく可能であり、時には、この方が便宜的であることも分かっている。

[0107]前述の説明から明らかなように、特に断らない限り、本明細書を通じて、「決定する」又は「表示する」等の用語を用いて説明していることは、物理的（電子的）量として表されたデータを、コンピュータシステムメモリ又はレジスタ又は他の同様の情報記憶装置、送信又は表示装置内で取扱い及び変換するようなコンピュータシステム又は同様の電子的コンピューティング装置の動作及び処理を指している。

[0108]本発明の特定の態様は、アルゴリズムの形にて前述した処理ステップ及び命令を含む。本発明の処理ステップ及び命令は、ソフトウエア、ファームウエア又はハードウエアにて実施することができ、ソフトウエアにて実施されるときには、実時間ネットワークオペレーティングシステムにより使用される種々なプラットフォームから実在するようにダウンロードされオペレーティングされることもできるとういうことに、注意されたい。

[0109]本発明は、ここでのオペレーションを行うためのシステムにも関する。このシステムは、必要とされる目的に特に合わせて構成することができ、又、このシステムは、コンピュータによりアクセスできるコンピュータ読み取り可能な媒体に記憶されたコンピュータプログラムにより選択的にアクティべートされ又はリコンフィギュレーションされるコンピュータ（種々な実施形態に依存して、サーバー、パーソナルコンピュータ、タブレットデバイス、ハンドヘルドコンピュータ、ＰＤＡ、セルラーホン等を含む任意のタイプのコンピュータを含む）を含むことができる。このようなコンピュータプログラムは、これらに限定されるものではないが、フロッピーディスクを含む任意のタイプのディスク、光ディスク、ＣＤ-ＲＯＭ、磁気-光ディスク、読み取り専用メモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、ＥＰＲＯＭ、ＥＥＰＲＯＭ、磁気又は光カード、アプリケーション特定用途向け集積回路（ＡＳＩＣ）、又は電子命令を記憶するのに適した任意のタイプの媒体の如きコンピュータ読み取り可能な記憶媒体であって、各々がコンピュータシステムバスに結合されているようなコンピュータ読み取り可能な記憶媒体に記憶させておくことができる。更に又、本明細書において述べられているコンピュータは、単一プロセッサを含むものであっても、又は、コンピューティング能力を増大させるためマルチコア設計を含むマルチプロセッサ設計を使用するアーキテクチャーであってもよい。

[0110]ここに説明したアルゴリムズ及びオペレーションは、本来的には、特定のコンピュータ又は他のシステムに関連付けられているものではない。ここで教示したプログラムでもって、種々な汎用システムを使用することもでき、又は、必要とされる方法ステップを行うためより特化したシステムを構成すると都合がよい場合があることも理解されよう。これらの種々なシステムのために必要とされる構成については、均等の変形と共に、当業者には明らかなことであろう。更に又、本発明は、特定のプログラム言語に関して説明されていない。ここに説明した本発明の教示を実施するのに、種々なプログラミング言語を使用することができることは理解されよう。

[0111]本発明は、種々なトポロジーを通して広範囲に亘る種々なコンピュータネットワークに良好に適合するものである。この分野内において、大規模ネットワークのコンフィギュレーション及び管理は、インターネットの如きネットワークを通して異なるコンピュータ及び記憶装置に通信により結合される記憶装置及びコンピュータを含む。

[0112]最後に、本明細書において使用されている用語は、主として理解を容易にする目的で使用されているだけのものであり、本発明の主題を限定しようとして選択されるものではないことに、注意されたい。従って、本発明の開示は、例示しようとしているだけのものであり、本発明の範囲をこれに限定しようとしているものではなく、本発明の範囲は、特許請求の範囲に記載されるところである。

Claims (24)

1. ネットワークを通じてビデオフレームを通信するためのシステムであって、
   サーバーのアプリケーションにおける、連続するユーザーインターフェースをキャプチャし、連続するキャプチャのうちの各キャプチャを直前のキャプチャと比較し、直前のキャプチャと異なるキャプチャを特定し、特定されたキャプチャを対応するビデオフレームに変換し、可変のレートでビデオフレームをリサイズするように構成された、画像管理エンジンであって、前記変換は、１つ以上のフィードバックパラメータ及びビデオ変換技法に基づき、前記リサイズは、１つ以上のフィードバックパラメータ及びリサイズ技法に基づく、画像管理エンジンと、
   前記ネットワークを通じて送信するために前記ビデオフレームをエンコーディングするように構成されたビデオエンコーダエンジンであって、前記ビデオフレームのエンコーディングが、１つ以上のフィードバックパラメータに基づいており、ビデオ圧縮技法を含む、ビデオエンコーダエンジンと、
   ネットワークを介して、前記アプリケーションに関連するユーザ入力を受信するように構成された第１のコマンド処理エンジンと、
   前記エンジンを実行するプロセッサと、
   を備えるシステム。
2. 前記アプリケーションに機能的に結合され、前記ネットワークを通じて送信するため前記アプリケーションに関連するオーディオストリームをエンコーディングするように構成されたオーディオエンコーダエンジンと、
   を更に備える、請求項１に記載のシステム。
3. 各々が対応する複数のエンコーダエンジン及び対応する複数の第１のコマンド処理エンジンを有し、オペレーティングシステムの１つのインスタンスにおいて実行されるユーザーインターフェースを有する複数のアプリケーションと、
   前記ネットワークを通じて対応する複数の第２の装置へ送信するため前記複数のアプリケーションの各々の連続するビデオフレームを可変のレートでロードバランス形式にてエンコーディングするように構成されたユーザーマネージャエンジンと、を更に備える、請求項１に記載のシステム。
4. ネットワークを通じてビデオフレームを通信するための方法であって、
   連続するプログラムのユーザーインターフェースのキャプチャを受信するステップと、
   連続するキャプチャのうちの各キャプチャを直前のキャプチャと比較するステップと、
   直前のキャプチャと異なるキャプチャを特定するステップと、
   特定された、プログラムのユーザーインターフェースのキャプチャを対応するビデオフレームに変換し、可変のレートでリサイズするステップであって、前記変換は、１つ以上のフィードバックパラメータ及びビデオ変換技法に基づき、前記リサイズは、１つ以上のフィードバックパラメータ及びリサイズ技法に基づく、ステップと、
   前記ビデオフレームをエンコーディングするステップであって、前記エンコーディングは、１つ以上のフィードバックパラメータに基づくと共にビデオ圧縮技法を含む、ステップと、
   ユーザー入力に対応する信号を受信するステップと、
   前記ユーザー入力に対応する信号を前記プログラムへ通信するステップと、を含む方法。
5. 前記ネットワークを通じて送信するため、前記プログラムに関連したオーディオストリームをエンコーディングするステップと、
   を更に含む、請求項４に記載の方法。
6. 対応する複数のプログラムのユーザーインターフェースの複数の連続するビデオフレームをエンコーディングするステップであって、前記エンコーディングは、各プログラムに対応する１つ以上のフィードバックパラメータに基づいてなされ且つビデオ圧縮技法を含み、前記複数のプログラムは、オペレーティングシステムの１つのインスタンスにおいて実行されるステップと、
   各々が前記複数のプログラムのうちの１つに対応する複数のデバイスからのユーザー入力を受信するステップと、
   前記複数のデバイスの前記ユーザー入力を前記各対応するプログラムへ通信するためのステップと、を更に含む、請求項４に記載の方法。
7. ネットワークを通じてビデオフレームを通信するためのシステムであって、
   複数の画像管理エンジンの複数のプログラムにおける、連続する複数のユーザーインターフェースをキャプチャし、連続するキャプチャのうちの各キャプチャを直前のキャプチャと比較し、直前のキャプチャと異なるキャプチャを特定し、特定されたキャプチャを対応するビデオフレームに可変のレートで変換する、ように構成された複数の画像管理エンジンと、
   前記ネットワークを通じて送信するために前記ビデオフレームをエンコーディングするように構成されたビデオエンコーダエンジンであって、前記ビデオフレームのエンコーディングが、１つ以上のフィードバックパラメータに基づいており、ビデオ圧縮技法を含む、複数のビデオエンコーダエンジンと、
   複数の前記プログラムに機能的に結合され、且つユーザー入力を受け取り、前記ユーザー入力を前記対応するプログラムであって前記ユーザー入力を送信するデバイスに関連するプログラムへと通信するように構成されたコマンド処理エンジンであって、前記デバイスは前記プログラムのエンコードされた複数のビデオフレームを受信する、コマンド処理エンジンと、
   前記複数のプログラムに機能的に結合され、前記複数のプログラムに対応する複数のオーディオストリームをエンコーディングするように構成されたオーディオエンコーダエンジンと、
   前記複数のプログラム及び前記オーディオエンコーダエンジンに機能的に結合され、前記複数のオーディオストリームを前記オーディオエンコーダエンジンにリダイレクトするように構成されたオーディオインターセプターエンジンであって、前記複数のオーディオストリームは、前記複数のプログラムに対応する複数のプロセスの識別子の一つに関連付けられ、前記オーディオエンコーダエンジンは、対応付けられたプロセスの識別子に基づき前記複数のオーディオストリームをルーティングするように構成された、オーディオインターセプターエンジンと、
   前記エンジンを実行するプロセッサと、
   を備えるシステム。
8. 前記プログラムに機能的に結合され、前記コマンド処理エンジンを通してユーザー入力を受け取り且つ前記プログラムでのオペレーションのため前記ユーザー入力を転送するように構成されたプラグインを更に備える、請求項７に記載のシステム。
9. 前記画像管理エンジンは、更に、プログラムの前記ユーザーインターフェースにおける変化に基づいてビデオフレームを非同期的に通信するように構成された、請求項７に記載のシステム。
10. 前記ネットワークを通じて対応する複数のデバイスへと送信するため、前記複数のプログラムの各々の連続するビデオフレームをロードバランシング形式にてエンコーディングするように構成されたユーザーマネージャエンジンと、を更に備える、請求項７に記載のシステム。
11. 前記複数のプログラムは、オペレーティングシステムの１つのインスタンスにて実行される、請求項１０に記載のシステム。
12. 前記ユーザーマネージャエンジンは、複数のワーカースレッドを備えており、各ユーザーを前記複数のワーカースレッドのうちの１つへと割り当て、各ワーカースレッドが１つ以上のユーザーにサービスするように構成された、請求項１０に記載のシステム。
13. コンピュータに実装され、ネットワークを通じてビデオフレームを通信するための方法であって、
    連続するプログラムのユーザーインターフェースのキャプチャを受信するステップと、
    連続するキャプチャのうちの各キャプチャを直前のキャプチャと比較するステップと、
    直前のキャプチャと異なるキャプチャを特定するステップと、
    特定された、直前のキャプチャと異なる、複数のプログラムのユーザーインターフェースのキャプチャを対応するビデオフレームに可変のレートで変換するステップと、
    ネットワークを通じて送信するため、複数のデバイスに対応するビデオフレームをエンコーディングするステップであり、前記エンコーディングは、１つ以上のフィードバックパラメータに基づいており、ビデオ圧縮技法を含む、ステップと、
    前記複数のデバイスからのユーザー入力を受け取るステップと、
    前記ユーザー入力を前記ユーザー入力に関連し対応する前記プログラムへ通信するステップと、
    前記複数のプログラムに対応する複数のオーディオストリームをインターセプトするステップと、
    前記複数のオーディオストリームの各々を前記複数のプログラムに対応する複数の処理識別子のうちの１つに関連付けるステップと、
    前記複数のオーディオストリームをエンコーディングするステップと、
    前記関連付けられた処理識別子に基づいて前記複数のオーディオストリームをルーティングするステップと、
    を含む方法。
14. 前記プログラムにおけるオペレーションのため、前記ユーザー入力を受け取り前記対応するプログラムへ転送するように構成されたプラグインを前記プログラムに補充するステップを更に含む、請求項１３に記載の方法。
15. 前記複数のプログラムは、オペレーティングシステムの１つのインスタンスにおいて実行される、請求項１３に記載の方法。
16. ネットワークを通じて、対応する複数の第２のデバイスに送信するために、前記複数のプログラムの各々のビデオフレームのエンコーディングを管理しロードバランシングさせるステップと、を更に有し、
    前記管理しロードバランシングさせるステップは、複数のワーカースレッドを使用し各ユーザーを前記複数のワーカースレッドのうちの１つへと割り当て、各ワーカースレッドが１つ以上のユーザーにサービスするようにする段階を含む、請求項１３に記載の方法。
17. ネットワークを通じてビデオフレームを受け取るためのシステムであって、
    前記ネットワークを通じて送信される、エンコードされた、プログラムのユーザーインターフェースの連続するビデオフレームをデコーディングするように構成されたビデオデコーダーエンジンであって、
    前記ビデオフレームは、１つ以上のフィードバックパラメータ及びビデオ圧縮技法に基づき、プログラムのユーザーインターフェースのキャプチャから、エンコード及び可変のレートでリサイズされたものであり、前記ユーザーインターフェースの前記キャプチャは連続するキャプチャ間の相違の特定に基づくエンコードのために選択されたものである、ビデオデコーダーエンジンと、
    前記システムのユーザー入力を前記プログラムへ通信するように構成されたコマンド処理エンジンと、
    前記エンジンを実行するプロセッサと、
    を備えるシステム。
18. 前記ネットワークを通した送信の後、前記連続するビデオフレームに関連したオーディオストリームをデコーディングするように構成されたオーディオデコーダーエンジンを更に備える、請求項１７に記載のシステム。
19. 前記ビデオデコーダーエンジン及び前記オーディオデコーダーエンジンに機能的に結合され、デバイス出力のため前記オーディオストリームを前記連続するビデオフレームと相関させるように構成された同期エンジンを更に備える、請求項１８に記載のシステム。
20. 前記ビデオデコーダーエンジンに機能的に結合され、前記連続するビデオフレームを表示するように構成されており、且つ前記コマンド処理エンジンに更に機能的に結合され、ユーザー入力を前記プログラムへ通信するように構成されたビューイングアプリケーションを更に備える、請求項１７に記載のシステム。
21. 前記連続するユーザーインターフェースをキャプチャは、前記ユーザーインターフェースの連続するスクリーンショットを含む、請求項１に記載のシステム。
22. 前記連続するキャプチャは、そのネイティブフォーマットにおけるプログラムの、受信したユーザーインターフェースデータに対応する、請求項４に記載の方法。
23. 前記連続するキャプチャは、そのネイティブフォーマットにおけるプログラムの、受信したユーザーインターフェースデータに対応する、請求項７に記載のシステム。
24. 前記連続するキャプチャは、そのネイティブフォーマットにおけるプログラムの、受信したユーザーインターフェースデータに対応する、請求項１３に記載のシステム。

Images