JP2013506348A - 低遅延性転送プロトコルのための方法及びシステム - Google Patents

Abstract

コンピュータ生成出力及び特定のグラフィック出力を提供するための方法及びシステム。
システムは、デジタル情報を運ぶように構成されるネットワークを含む。システムは、ネットワークと通信するサーバを含み、サーバは、アプリケーションプログラム及びクラウドエンジンモジュールを実行するように構成される。アプリケーションは、グラフィック出力を提供する。出力捕捉及び符号化エンジンモジュールはさらに、サーバ上のアプリケーションからグラフィック出力を傍受するように構成される。出力捕捉及び符号化エンジンモジュールはさらに、グラフィック出力を、グラフィックコマンド及びビデオコーデックデータの少なくとも１つに変換するように構成される。出力捕捉及び符号化エンジンモジュールはさらに、変換された出力をネットワークにわたって送信するように構成される。システムは、ネットワークにわたってサーバと通信するクライアントを含み、クライアントは、グラフィック及びビデオデコーディング及びレンダリングエンジンモジュールを実行するように構成される。グラフィック及びビデオデコーディング及びレンダリングエンジンモジュールは、送信された、変換された出力を受信することに応じて、グラフィック出力をレンダリングするように構成される。グラフィック及ビデオデコーディング及びレンダリングエンジンモジュールは、クライアントでグラフィック及びビデオデコーディング及びレンダリング入力を傍受するように構成される。グラフィック及びビデオデコーディング及びレンダリングエンジンモジュールは、傍受されたユーザ入力を出力捕捉及び符号化エンジンモジュールに送信するように構成される。
【選択図】図４

Description

本願は、２００９年９月２９日出願の米国特許出願第１２／５６９８７６号の優先権を求め、これによって、参照によりその全体に組み込まれる。

バーチャルデスクトップインフラストラクチャ（ＶＤＩ）は、ネットワークにわたって小型軽量クライアントを経由してエンドユーザにフルＰＣデスクトップの体験を提供する一方で、データセンタにてデスクトップバーチャルマシンをホスティングし及び管理するサーバ中央演算モデルである。

いくつかの既存の解決策は、いくつかのインカミングクライアントセッションを切り換える能力を、マイクロソフト社のターミナルサービス又はサイトリックス社のアプリケーションサーバ、ブレードサーバ、又は個々の不使用の物理デスクトップコンピュータのような伝統的な共有デスクトップシステムに加える。

ＶＤＩソリューションは、スクリーンアップデートをネットワークにわたってＲＤＰ若しくはＩＣＡといったプロトコルとともにクライアントの表示装置に送信するサーバでの、ウィンドウズインスタンスの遠隔実行を含む。しかしながら、従来のプロトコルは、約１００ミリ秒に一回、ビデオフレームバッファをクライアントにフラッシュするが、それは、現代のグラフィックの多いアプリケーション、及び、ＡＶ同期を必要とするアプリケーションには適していない。

ＶＤＩソリューションを提供する既存のアプローチがいくつかある。

「スクリーンスクレープ」法は、そのプロトコルによってホスト上で「スクリーン」にペイントされるグラフィック要素を「スクレープすること」を含む。第１の例において、クライアントは、サーバにコンタクトをとり、そして、スクリーンの新たな「スナップショット」をフレームバッファから取り出す。第２の例において、サーバは、そのスクリーンの動作をクライアントに連続的にプッシュ配信できる。これは、そのフレームバッファレベルであり、ＧＤＩ／ウィンドウマネージャレベルであり、またはその両方の組み合わせであり得る。両方の例は、しばしば使用されるグラフィック要素について、クライアントでのキャッシングを利用できる。

スクリーンスクレープ法は、「マルチメディアリディレクション」と組み合わせ可能であり、ここでは、サーバ側のマルチメディア要素が、そのネイティブフォーマットにおいて、クライアント装置に送信される。その後、クライアントは、マルチメディアストリームを局地的に再生することができ、それらをスクリーン上の適切な位置に動的に挿入できる。

このアプローチは、（１）クライアントが、技術的な能力とマルチメディアを提供するハードウェアとを有している場合、そして（２）クライアントが、マルチメディアコンテンツを適切に提供するようにインストールされる適切なコーデックを有する場合に適している。実際には、これは、クライアントが「小型軽量過ぎる」ことがあり得ないということを意味する。

サーバグラフィックシステム仮想化は、ホストのグラフィックシステムを仮想化する。ホスト上のソフトウェアは、全ての可能性のあるグラフィックレイヤ（ＧＤＩ、ＷＰＦ、ＤｉｒｅｃｔＸ等）を捕捉し、可能な限り速くクライアントに送信される（ＲＤＰのような）リモートプロトコルストリーム内にそれらをレンダリングする。これは、クライアント装置（非常にローエンドな又は小型軽量のクライアント上でさえも）に関わらず、クライアントに、局地的なパフォーマンスに非常に近い体験を与えるであろう。

サーバ及びクライアントにおけるハードウェアアクセラレーションは、ホスト上で特別なチップセットを利用し、ネットワークにわたる転送のためのスクリーンを捕捉する。クライアント装置は、レンダリングのためのマッチングスペシャルチップセットを有する。

リアルタイムでのネットワークにわたるグラフィック情報の遠隔表示における問題に取り組んでいる上記従来のアプローチは、極めて動的なグラフィックおよびフルモーションビデオについての低遅延性、許容可能なレベルの品質、及び双方向性を届けることができない。

問題は、以下の点を含む。

−フルモーションビデオの限定的なサポート。

−相互に短い距離（ＷＡＮ）においての作業の場合であっても内在する重大な遅延性。

−相対的に高いレベルのパケットロス、ジッタ及び遅延性を伴う信頼性の低いネットワーク環境（例えばインターネット）における貧弱なパフォーマンス及び品質。

−ネットワークにおける重大なデータストリームの存在の下でのユーザ体験の品質及び遅延性について転送量を優先することができない点。

―オーディオ及びビデオストリームの一貫性のない同期。

―フルボディセンシング、ビデオ、声、センサ、動きのような様々な入力及び出力を操作することができない点−全てを背景に追加されたい。

ビデオ及び高度にインタラクティブで豊富なグラフィックユーザインターフェースがユーザのコンピュータにおいてユビキタスであった以前に、Ｍｉｃｒｏｓｏｆｔ ＲＤＰ、Ｃｉｔｒｉｘ ＩＣＡ、ＡＴ＆ＴのＶＮＣその他のような既存のソリューションが設計されたということから、上の問題が部分的に生じる。

従って、リモートコンピューティングについて改良型転送プロトコルに関する必要性が存在する。

この開示の特徴及び目的は、同様の参照符号または同様の要素を示す添付図面とともに、以下の記載を参照してより明確になるであろう。
図１は、リモートコンピューティングのための改良型転送プロトコルを提供するためのシステムの例を示す。 図２は、リモートコンピューティングのための改良型転送プロトコルを提供するためのサーバの例を示す。 図３は、リモートコンピューティングのための改良型転送プロトコルを提供するためのクライアントの例を示す。 図４は、リモートコンピューティングのための改良型転送プロトコルを提供するための、サーバにおいて実行される出力キャプチャ及びエンコーディングエンジンの例を示す。 図５は、リモートコンピューティングのための改良型転送プロトコルを提供するための、クライアントにおいて実行されるデコーディング及びレンダリングエンジンの例を示す。 図６は、改良型転送プロトコルに関する、捕捉、符号化及び送信のためのサーバによって実行される手順の例を示す。 図７は、改良型転送プロトコルに関する、受信、復号化及びレンダリングのためのクライアントによって実行される手順の例を示す。 図８は、リモートコンピューティングのための改良型転送プロトコルを提供するためのネットワークスタックの例を示す。 図９は、領域検出器モジュールを提供するためのサーバによって実行される手順の例を示す。 図１０は、単純なモーション検出器モジュールを提供するためのサーバによって実行される手順の例を示す。 図１１Ａは、第１のモーション検出の例のスクリーンショットを示す。図１１Ｂは、第２のモーション検出の例のスクリーンショットを示す。図１１Ｃは、第３のモーション検出の例のスクリーンショットを示す。 図１２は、リモートコンピューティングのための改良型転送プロトコルを提供するためのビデオエンコーダの例を示す。 図１３は、グラフィック出力の前処理のための手順の例を示す。 図１４は、プログレッシブピクチャエンコーダを提供するための手順の例を示す。

信頼性のないパケット切替通信ネットワークにわたる多数のインタラクティブディスプレイ装置に対するコンピュータ生成情報の低遅延性のリアルタイム送信が提供される。グラフィック出力、オーディオ信号、データ、ＵＳＢインターフェース信号、プリントスプール等のようなコンピュータ出力情報は、サーバ上で実行されるアプリケーションによって生成され得る。システムは、ネットワークにわたって多数のエンドユーザの装置に対して、アプリケーションによって生成されるコンピュータ出力情報のインタラクティブ送信を可能にする。低コストのシン・クライアントから強力なワークステーションまで、幅広いエンドユーザの装置がシステムによって支援され、ここでは各エンドユーザの装置は、異なる量の利用可能なバンド幅を有する。多数のユーザが、同時に、同じグラフィック情報をエンドユーザの装置上で交信できる。

システムは、エンドユーザの装置で捕捉されたインタラクションデータをサーバに送り返し、アプリケーションによる処理のために入力を同期させる。システムはその後、サーバのグラフィック及び他の種類の出力を捕捉し、出力情報を符号化しエンドユーザの装置に送信するための様々なエンコーディングスキームを適用する。

システムは、既存のシステムのそれらとは大幅に異なる設計仮定及び目標（低遅延性、フルモーションビデオ、信頼性のないネットワーク、相対的に高いネットワークバンド幅等）を利用する。同様のアプローチが、極端に低い遅延性（５０ｍｓを下回る）でのインターネットにわたる高品質のオーディオストリームの送信とこれらのストリームの正確な同期を必要とする分散型マルチプレーヤリアルタイムジャミングシステムにおいて使用されている。このアプローチは、以下のような様々な参照文献において議論される。

米国特許出願第１１／７１７６０６号、発明の名称「Method and System for Low Latency High Quality Music Conferencing」、出願日２００７年３月１３日、米国仮出願第６０／７８５１４５号、発明の名称「Method and System for Low Latency High Quality Music Conferencing」、出願日２００６年３月２２日の優先権を主張。

「Virtual Jamming. Four Fixes for the Major Problem Facing Musicians Who Play Together on the Web: Lag」http://www.spectrum.ieee.org/computing/software/virtual-jamming（２００９年９月に最後に検索）

米国特許出願第１２／０２４０８９号、発明の名称「Method and System for Precise Synchronization of Audio and Video Streams During a Distributed Communication Session With Multiple Participants」、出願日２００８年１月３１日、米国仮出願第６０／８８７５５５号、発明の名称「Method and System for Low Latency High Quality Music Conferencing」、出願日２００７年１月３１日の優先権を主張。

その全てが参照によってここに組み入れられる。

図１は、リモートコンピューティングのための改良型転送プロトコルを提供するための例示的なシステムを示す。システムは、地理的に分配可能であり、インターネットのようなブロードバンドネットワークにわたって通信可能である。

システムは、オペレーティングシステム上におけるソフトウェアアプリケーション１１３のインスタンスを実行する物理的な又はバーチャルなサーバ１１２を含む。例えば、オペレーティングシステムは、Ｗｉｎｄｏｗｓ、Ｍａｃ ＯＳＸ、ＵＮＩＸ、Ｌｉｎｕｘ等であり得る。

アプリケーション１１３の出力は、後述される捕捉及びエンコーディングエンジン１１４によって捕捉される。例えば、その出力は、実行中のアプリケーション１１３によって提供されるユーザインターフェースのグラフィック出力であり得る。

他の種類の出力が、エンジン１１４によって捕捉され得る。例えば、オーディオ出力が、システムにわたる符号化及び送信のために捕捉され得る。

サーバ１１２上において実行されるエンジン１１４は、以下で議論される低遅延性のハイブリッドネットワークスタックを使用するブロードバンドネットワークにわたる送信のためのアプリケーションの出力を捕捉し符号化する。例えば、ネットワークは、ＩＰベースのネットワーク、セルラーネットワーク、３Ｇ又は４Ｇのワイヤレスネットワーク、ケーブル等であり得る。

送信は、ネットワーク上の負荷を低減させるために（可能な場合は）マルチキャスティングを使用するネットワーク１１１にわたって、多数のストリーム１０９及び１１０を経由して多数のレシーバに同時に中継され得る。どのレシーバでもシステム上に存在し、ネットワーク１１１の利用可能なバンド幅を受けることができるということが理解されるであろう。システムは、ユーザ体験を改良するために遅延性を最小化するように構成される。例えば、レシーバが不十分なバンド幅を有する場合（又はネットワークの混雑が生じた場合）、システムは、動的にグラフィックの品質を低下させ、そうでなければ、低遅延性を維持するためにストリームのバンド幅を低減させる。

例示的なシステムは、２つのレシーバ、ネットブック１０３及びフレキシブルディスプレイ（電子ペーパ）１０４を含む。例えば、ネットブック１０３は、Ｉｎｔｅｌ Ａｔｏｍ ＣＰＵ及びＩｎｔｅｌ ＧＭＡ ９４５Ａグラフィックアクセラレーションチップに基づくＡＳＵＳのＥｅｅ ＰＣのような低コストの演算装置である。同様なネットブックもまた使用され得る。

各レシーバは、グラフィック及びビデオデコーディング及びレンダリングエンジン（ＧＶＤＲエンジン）を含む。ネットブック１０３は、ネットブック１０３のオペレーティングシステム上で実行されるソフトウェアベースのＧＶＤＲエンジン１０８を含む。フレキシブルディスプレイは、集積回路又はＤＳＰのチップセット、プロセッシングユニット、メモリユニット等として実装されるハードウェアＧＶＤＲエンジン１０７を含む。他のＧＶＤＲの実装が、ユーザ及び利用可能なリソースの必要性に応じて利用され得るということが理解されるであろう。代わりに、ビデオデコーディング及びレンダリングエンジンは、ＵＳＢ装置のような外部のハードウェア装置であり得る。一実施例は、ネットワーク入力及びＨＤＭＩ出力を伴う小さなＴＶボックスであり得る。ネットワーク入力は、有線のネットワーク（ケーブル、Ｅｔｈｅｒｎｅｔ）又は無線ネットワーク（Ｗｉ−Ｆｉ等）であってもよい。

ＧＶＤＲエンジンは、実装が簡単であり、多数のコンピューティングプラットフォーム又は家庭用電子機器について様々な方法で構築され得るということが理解されるであろう。これは、幅広い装置がシステム内でレシーバとして機能することを可能にする。

ＧＶＤＲエンジン１０７及び１０８は、各システム１０３及び１０４上でアプリケーション１１３の画像１０５及び１０６をレンダリングする。加えて、ＧＶＤＲエンジン１０７及び１０８は、ビデオデータ、オーディオデータ及び、アプリケーション１１３からの出力として捕捉される、あらゆる他のデータをレンダリングできる。

画像１０５及び１０６は、必要に応じてリフレッシュされるが、リフレッシュレートは、既存のディスプレイ装置を利用して、ピクチャの特定の領域について毎秒１５フレームから毎秒６０フレーム又はそれ以上で変化し得る。システムリソース及び性能要件によって、より高いフレームレートが可能となることが理解されるであろう。より高いフレームレートは、より多くの最適なユーザ体験を与え得る。一実施形態において、画像の異なる領域が、後述されるように、改良されたユーザ体験について異なるレートでリフレッシュされ得る。

一実施形態において、画像１０５及び１０６は、インタラクティブであり得る。装置１０４及び１０５で相互に交信するユーザ１０１及び１０２からの様々な入力データが、捕捉され、アプリケーション１１３に送り返され得る。入力データは、キーボードストローク、マウスの移動、タッチ及びマルチタッチイベント、モーションセンシングデータ、加速度計データ、温度又は大気の状態のようなセンサデータ、心拍数センサ又は血糖センサのような人間の生物学的センサ、音声命令、目の動き、又は、コンピュータによって解読される神経系のインパルス等を含む。

入力データは、エンジン１１４に送信され、エンジン１１４は、入力データを集計し、アプリケーション１１３へと送信する。アプリケーション１１３は、入力データを処理のために読み取ることができ、入力データに応じてその出力を変更する。出力は、エンジン１１４によって再び捕捉され、ネットワーク１１１を通じて、上記のように、レシーバ１０３及び１０４に送信される。

代わりに、エンジン１１４は、処理のために入力データを読み取ることができる。例えば、エンジン１１４は、独立してアプリケーション１１３に備えられるマッピングスキームに基づくアプリケーションの特定の命令に対するマルチタッチイベントをマッピングできる。入力データがアプリケーション１１３とエンジン１１４の組み合わせによって解釈され得るということが理解されるであろう。

動作中において、ユーザ１０１及び１０２は、同じアプリケーション１１３上で共に作業をすることができる。この共同作業は、アプリケーション１１３がマルチユーザサポートを含むか否かにかかわらず、システムの特徴である。

さらに、ファイアウォールのようなセキュリティ及びプライバシーの問題、及びネットワークアドレス変換（ＮＡＴ）の問題が取り除かれる。ユーザ１０１及び１０２は、サーバ１１２、信頼できるソースへの接続を開始する。それ故、ユーザ１０１及び１０２のシステムの例は、未知の及び信頼できないネットワーク接続を決して受け入れることはない。

図２は、リモートコンピューティングのための改良型転送プロトコルを提供するためのサーバの例を示す。サーバ２０１が、議論されたアプリケーション及びＧＶＤＲエンジンを実行できる。

サーバ２０１は、物理的又はバーチャルなものであり、ＣＰＵ２０２及びオプションとしてＧＰＵ２０３を含む。サーバ２０１は、サウンドカード（図示せず）のような他のプロセッシングハードウェアユニットを含み得る。例えば、ＣＰＵは、Ｉｎｔｅｌ Ｃｏｒｅ ｉ７であり得る。例えば、ＧＰＵは、Ｎｖｉｄｉａ ＧｅＦｏｒｃｅ９４００であってもよい。

アプリケーション２０４は、ハイパーバイザの内部又は外部で、従来のオペレーティングシステム内で動作している（ＯＳ及びハイパーバイザは図示されていない）。オペレーティングシステムの例は、Ｗｉｎｄｏｗｓ ＸＰ、Ｗｉｎｄｏｗｓ Ｖｉｓｔａ、Ｗｉｎｄｏｗｓ ７、Ｗｉｎｄｏｗｓ Ｓｅｒｖｅｒ、Ｗｉｎｄｏｗｓ Ｍｏｂｉｌｅ、Ｍａｃ ＯＳ Ｘ、Ｍａｃ ＯＳ Ｘ Ｓｅｒｖｅｒ、ＵＮＩＸ、Ｌｉｎｕｘ、Ｓｙｍｂｉａｎ、Ａｎｄｒｏｉｄ等を含む。

出力捕捉要素２０５は、命令の形式又は生のデータの形式でアプリケーションからの出力データを捕捉する。捕捉処理の詳細が後述される。例えば、要素２０５は、グラフィックＡＰＩ命令（ＧＤＩ又はオープンＧＬ命令等）、ビデオメモリからの高周波数（２０−６０Ｈｚ）の画像、及びマルチメディアＡＰＩ命令（ビデオ等を見せるためのような）を捕捉し得る。

出力エンコーダ２０６は、低遅延性のハイブリッドネットワークスタックを通じた送信のための捕捉された出力データを符号化する。出力マルチキャスティングユニット２０７は、ネットワークにわたる多数のレシーバの送信を管理し、その送信がこれらの多数のレシーバの間で同期されることを保証する。加えて、出力マルチキャスティングユニット２０７は、適切な出力データが各レシーバに送信されることを保証する。例えば、異なる質の出力データが異なるバンド幅を伴うレシーバに使用され得る。加えて、レシーバは、最大ｆｐｓ、オープンＧＬハードウェアサポート等といった装置のレンダリング性能によって変動し得る。

マルチキャスティングユニット２０７は、レシーバがブロードキャスティングセッションに接続すること及び離れることを維持し、最適な送信トポロジー及びルーティングを定め、かつ、マルチキャストオーバレイネットワークを維持及び再配置する。マルチキャスティングユニット２０７はまた、発信パケットに対するタイムスタンプのような関連する同期データを加え、レシーバのクロックが同期され、必要であれば、ビットレート、符号化データ、利用可能なネットワークのバンド幅、処理性能、及び共通のセッションに参加している各レシーバの遅延性を調節する。

マルチキャスティングユニット２０７は、上述のように機能性を効率的に実行するために、ハイブリッドネットワークスタック２０８及び出力エンコーダ２０７と通信する。マルチキャスティングユニット２０７は、レシーバ装置でのインタラクションの質及びユーザに関するユーザ体験に基づく最適化基準を利用できる。ネットワークスタック２０８は、データのパケットを物理通信ネットワークに送信する物理ネットワークインターフェースと接続する。ネットワークスタック２０８は、ユーザモード又はカーネルモードのソフトウェアコンポーネントとして一般に実装され得る。代わりに、それはハードウェア集積回路として実装され得る。

入力キュー２０９は、多数のユーザから入力命令を受信すること、命令をバッファリングすること、及び適切に命令すること（それによって多数のユーザからの入力データを同期すること）について担当する。入力デコーダ２１０が、異なる種類の入力データがアプリケーション２０４によって理解可能になるということを保証する。入力デコーダ２１０は、アプリケーション２０４によって読み取りができない全ての入力命令を捨て去る。

発信捕捉ユニット２０５、出力エンコーダ２０６、出力マルチキャスティングユニット２０７、ネットワークスタック２０８、入力キュー２０９、及び入力デコーダ２１０は、アプリケーション２０４のネイティブオペレーティングシステムのカーネル及びユーザモードで作動するソフトウェアプログラムとして実装される。これらの特徴はさらに後述される。

図３は、リモートコンピューティングのための改良型転送プロトコルを提供するためのクライアントの例を示す。クライアントディスプレイ（表示）装置３０５が、上述されたレシーバ装置であってもよい。

クライアント３０５は、低遅延性のハイブリッドネットワークスタック３０７、出力デコーダ３０６及び装置に存在する出力レンダラ３０７を含む。出力デコーダは、オーディオ／ビジュアルコーデック、ピクチャコーデック、及び受信された出力データを復号化するグラフィックコマンドライブラリを含み得る。

上記の要素は、ＣＰＵ３０２及びＧＰＵ３０３を含み得る低コストのコンピューティングハードウェアプラットフォーム上で実行される従来のオペレーティングシステムで動作するユーザモードのソフトウェアプログラムとして実装され得る。例えば、ＣＰＵ３０２は、Ｉｎｔｅｌ Ａｔｏｍプロセッサであり得る。例えば、ＧＰＵ３０３は、Ｉｎｔｅｌ ＧＭＡ ９４５であり得る。

これらの要素はまた、ハードウェアに実装され得る。一実施形態において、クライアント３０１は、汎用のＣＰＵ及びＧＰＵを必要とせず、また、Ｗｉｎｄｏｗｓ ＸＰ、Ｗｉｎｄｏｗｓ Ｖｉｓｔａ、Ｗｉｎｄｏｗｓ ７、Ｗｉｎｄｏｗｓ Ｓｅｒｖｅｒ、Ｗｉｎｄｏｗｓ Ｍｏｂｉｌｅ、Ｍａｃ ＯＳ Ｘ、Ｍａｃ ＯＳ Ｘ Ｓｅｒｖｅｒ、ＵＮＩＸ、Ｌｉｎｕｘ、Ｓｙｍｂｉａｎ、Ａｎｄｒｏｉｄ等の従来のオペレーティングシステムを必要としない。

クライアント３０５は、入力エンコーダ３０１とともに入力性能を支援できる。入力エンコーダ３０１及び出力デコーダ３０６は、画像、符号化されたビデオストリームの形式のグラフィック出力データ、又は遠隔のサーバからの中間フォーマット内のグラフィック命令を受信し、符号化された入力データに応答するために、ネットワークスタック３０７に接続する。出力デコーダ３０６は、（ファイル又はデータのストリームのような）出力ストリームのような他の種類の出力を受信し、読み取ることが可能である。入力データは、入力エンコーダ３０１によって、装置の又はオペレーティングシステムの独立したフォーマットに符号化され得る。

図４は、リモートコンピューティングのための改良型転送プロトコルを提供するためのサーバ上で実行される出力捕捉及びエンコーディングエンジンを示す。グラフィック出力及びエンコーディングエンジンは、上述のようにサーバ上で動作しているアプリケーションのグラフィック出力を捕捉できる。エンジンは、さらに、サポートされたフォーム（グラフィックＡＰＩ命令、ピクチャ又はビデオ）内で出力を符号化し、その後、符号化された出力を、データの種類や緊急性によって、ハイブリッドマルチチャンネルネットワークスタックとともに送信する。エンジンはまた、（もし存在する場合には）レシーバ上でそれ自体を他のキャッシュに同期させるキャッシュを更新する。

グラフィックＡＰＩ命令インターセプタ４０１、フレーム捕捉ユニット４０２、及びビデオパススルーインターセプタ４０３は、アプリケーション（又は選択的にアプリケーションが動作しているオペレーティングシステム）によって生成されるグラフィック情報を捕捉する。 例えば、フレーム捕捉ユニット４０２は、グラフィック出力を、毎秒２０〜３０フレームで捕捉できる。より高いフレームレートが、所定の十分な処理性能及びバンド幅で可能になる。

他のインターセプタ要素４０３ａが、他の種類の出力の傍受のために存在する。出力の種類の例は、データファイル及びデータストリームの形式の一般データ出力と同様に、３Ｄホログラム、３Ｄオブジェクト、プリンタ出力等を含む。

例えば、高品質のオーディオストリームの低遅延性インターセプションが上述の「Method and System for Low Latency High Quality Music Conferencing」に記載されており、ここに組み込まれる。

様々な種類の出力間の同期は、様々なメカニズムで達成され得る。あるメカニズムは、送り側におけるバイタイムスタンピング（後述のマルチキャスティングユニット４１３内で実行される）及び同期される送り側と受け側におけるクロックを維持することである。他のメカニズムは、後述のようにジッタバッファを受け側で実装することであり、これは、バッファサイズを変化させ、データ部分を必要に応じて捨て去ることによって、ネットワークの遅延性を管理する。他のメカニズムは、所望の同期のレベルを達成すべく、（オーディオサンプリングレートリレーのような）データインターセプションを変化させることである。

インターセプタ４０１、４０２、４０３、及び同様なインターセプタ４０３ａの実装は、変化し得る。それらは、オペレーティングシステム内で動作するカーネルモード又はユーザモードのソフトウェアコンポーネントとして実装され得る。それらはまた、ハイパーバイザ上で動作するソフトウェアコンポーネントとして実装され、それら自体を、ゲストオペレーティングシステムの仮想化されたインスタンスに対するハードウェアコンポーネントとして示し得る。それらはまた、グラフィック捕捉及びエンコーディングエンジンがハードウェアチップとして実装される場合に、ハードウェア内に実装され得る。

グラフィックＡＰＩ命令インターセプタ４０１は、グラフィック命令及びアプリケーションによって生成されるＡＰＩコールを捕捉する。これらの命令は、例えば、ＭｉｃｒｏｓｏｆｔのＧＤＩ、Ｄｉｒｅｃｔ ３Ｄ、Ｏｐｅｎ ＧＬ、Ｄｅｓｋｔｏｐ Ｗｉｎｄｏｗ Ｍａｎａｇｅｒ、及びＡｐｐｌｅのＱｕｉｃｋＤｒａｗ、Ｑｕａｒｔｚ ２Ｄ、ＰｏｓｔＳｃｒｉｐｔ、Ｃｏｒｅ Ｉｍａｇｅ、Ｃｏｒｅ Ａｎｉｍａｔｉｏｎ、Ｑｕａｒｔｚ Ｃｏｍｐｏｓｉｔｏｒ等を含み得る。インターセプタ４０１は、ユーザモード要素との組み合わせでバーチャルディスプレイドライバとして実装され得る。そのようなバーチャルディスプレイドライバは、それ自体、アプリケーションに対する物理ディスプレイドライバとして示されるが、受信されたいかなる命令をも複製し、あるコピーがネットワーク４１６を通じてレシーバに送られ、一方、第２のコピーは、フレーム捕捉ユニット４０２によって捕捉され得るピクチャをつくり出すために、物理グラフィックプロセッシングユニット又はバーチャルグラフィックプロセッシングユニットに渡される。

グラフィックコマンドフィルタ４０４は、ネットワーク４１６にわたるレシーバへの送信の前に、どのグラフィックコマンドが更なる処理に適しているかを決定するために、送り側のユニバーサルキャッシュ４０６及び領域検出器４０５と通信する。

一例において、既にレシーバの全部又は一部に存在する場合には、グラフィックＡＰＩコマンド及び関係する引数（ビットマップ、テクスチャ、ブラシ等）は、送信について不適格である。そのようなコマンドは、グラフィックコマンドフィルタ４０４によってフィルタ処理され、キャッシュ４０６内でのキャッシュロケーションを認証するハッシュ数によって代用される。ユニバーサルキャッシュ４０６は、キャッシュ同期手順４１２を経由して送り側と受け側との間で、システムにわたって同期される。

グラフィックＡＰＩコマンドはまた、領域検出器４０５が、グラフィックＡＰＩコマンドが影響を与える領域について、ビデオ又はピクチャエンコーダ（後述される）を利用することを決定した場合に、送信に関して不適格となり得る。領域検出器４０５は、後述の処理を実行する。

グラフィックコマンドフィルタ４０４はまた、グラフィックコマンドの量、コマンドの種類、キャッシュされていないサイズ、及び領域検出器４０５に対する領域境界のような統計を送信する。領域検出器４０５は、統計をその独自のモーション検出データ、及びグラフィックＡＰＩコマンドインターセプタ４０１又はビデオ／ピクチャエンコーダを使用するかどうかを決定する領域分類と比較する。

一例において、領域検出器４０５は、グラフィックコマンドを使用する方にバイアスがかけられる。しかしながら、高動画像を可能にする多くのＧＤＩコマンドをアプリケーションが利用する場合に、ビデオコーデックがより効率的になり得るということが理解されるであろう。

コマンドがさらなる処理について適格であるということがわかると、それは、グラフィックコマンドトランスレータ４０８によって、ユニバーサルフォーマットに変換される。ユニバーサルフォーマットは、様々なグラフィックＡＰＩにわたって共通のものであり得る。共通フォーマットは、追加及び修正を伴うＰｏｓｔＳｃｒｉｐｔのような既存のフォーマットに基づき得る。フォーマットは、簡単さに関して最適化され、受信装置によって、解釈及びレンダリングが容易になり得る。フォーマットは、低電力のハードウェア実装又はソフトウェア実装によって、解釈及びレンダリングに関して最適化され得る。

解釈（翻訳）されたコマンドは、グラフィックコマンドコンプレッサで圧縮される。コンプレッサは、アイテムの繰り返しがアイテムによって置き換えられ、アイテムがその順序で何度も生じるランレングス符号化アルゴリズムであり得る。より進歩したコンプレッサアルゴリズムは、コマンドを等価なコマンドの組に変換して、それはＺＩＰ又はＲＬＥアルゴリズムによって圧縮される。これは、レシーバへの送信に関するバンド幅及び遅延性を減少させる。

その結果としてのビットストリームは、後述のマルチキャスティングユニット４１２に送られ、ハイブリッドマルチチャンネルネットワーク伝送プロトコルスタック４１４を経由して、ネットワーク４１６に送信される。

スタック４１４は、ルーティングのための送信及びＩＰプロトコルのためにＵＤＰプロトコルを利用する。他の種類のネットワークプロトコルが同様に使用され得るということが理解されるであろう。例えば、ＴＣＰ／ＩＰが使用可能であるが、次善のユーザ体験のための高い遅延性の影響を受けるであろう。

フレーム捕捉ユニット４０２は、例えば毎秒３０−５０フレームの周波数で、サーバのビデオメモリからのアプリケーションのフレームデータを捕捉する。より高い捕捉レートが必要に応じて使用され得るということが理解されるであろう。ホストオペレーティングシステムのためのカーネルモードソフトウェアコンポーネントが、グラフィックからのデータ獲得速度を改良するために使用され得る。代わりに、フレーム捕捉ユニット４０２は、ユーザモードで実装され得る。

フレーム捕捉ユニット４０２は、アプリケーションが表示されるスクリーンの一部又はスクリーンの全体を捕捉できる。一実施形態において、捕捉ユニット４０２は、スクリーン全体を捕捉し、捕捉された画像を、後述のように関心のある領域のみを処理するように操作する。他の実施形態において、捕捉ユニット４０２は、アプリケーションが表示される１以上の特定の領域を捕捉するだけである。

フレーム捕捉ユニット４０２は、２０−３０ｍｓごとの、又は、しばしば５−１０ｍｓごとの画像フレームを伴う領域検出器４０５を提供する。フレーム捕捉レートは、出力のフレームレートに基づいて部分的に決定されるということが理解されるであろう。そのレート（ｍｓにおける）は、出力の毎秒のフレームによって１０００に分割される。それ故、領域検出器４０５は、フレームインターセプタ４０２から、インターセプタ４０１から傍受されたグラフィックＡＰＩコマンドのストリームから、そして、インターセプタ４０３から傍受されたビデオＡＰＩコマンドのストリームから、これらの画像を受信する。

領域検出器４０５は、その後、画像の各領域について、コマンドベースのアプローチ、ビデオコーデック又はピクチャコーデックを使用するかどうかを決定する。領域は、上述のように非矩形となり得る。

領域検出器４０５は、その後、後述のように、ビデオで符号化される領域のマスクとともに画像フレームをビデオエンコーダ４０７に送る。領域検出器４０５は、異なる状況について、様々なピクチャエンコーダ４１０とともに動作し得る。

例えば、大画像要素のためのプログレッシブイメージエンコーダ、及び、小画像のための、簡単な、損失のない又は損失のあるイメージコンプレッサの２種類のピクチャエンコーダ４１０が在り得る。その一方で、小画像は、既に小さなバンド幅を必要とし、それ故、速いエンコーダからより多くの利益を得る。プログレッシブイメージエンコーダは、効率的に大画像の大きさで圧縮され、一方、小画像は、高速エンコーダで処理され得る。プログレッシブイメージエンコーダは、小画像が高速エンコーダで処理され得る一方で、大画像のサイズにおいて効率的に圧縮することとなる。

領域検出器４０５は、上述のように、符号化のために、画像要素を伴うピクチャエンコーダ４１０を提供する。ビデオエンコーダ４０７及びピクチャエンコーダ４１０は、データを符号化し、それによって、データを圧縮し、圧縮されたデータをマルチキャスティングユニット４１３に渡す。

マルチキャスティングユニット４１３は、１以上のレシーバに対して通信セッションを維持し、最適なルーティングを決定し、同期に必要な時間のスタンピングを管理し、ネットワークスタック４１４から受信するフィードバックデータに応じて、ビデオエンコーダ４０７及びピクチャエンコーダ４１０のパラメータを変化させることによって、ビットレートを適合させる。

マルチキャスティングユニット４１３は、ペイロード及び遅延性の要求に応じて、異なる種類の通信チャンネルをつくり出すネットワークスタック４１４を使用する。マルチキャスティングユニット４１３は、マルチチャンネルの相対的優先順位を管理し、レシーバとの接続を確立させる。マルチキャスティングユニット４１３はまた、データをレシーバに送信する。

後述のように、ネットワークスタック４１４は、３種類のチャンネル、保証型配信、非保証型配信、及び、順方向誤り訂正を伴う非保証型配信を有し得る。

一実施形態において、マルチキャスティングユニット４１３は、ＡＰＩコマンドに関する保証型配信チャンネル、ネットワークの状況がロバスト（ｒｏｂｕｓｔ）である場合に、ビデオコーデック符号化データのための非保証型配信チャンネル、ネットワークの状況が信頼性のない場合に、ＦＥＣを伴うビデオ用の非保証型配信、また、オーディオストリーム及びピクチャコーデック符号化データ用の非保証型配信、を確立する。マルチキャスティングユニット４１３は、低い優先度で保証型配信チャンネルにわたって、アプリケーションデータを送信できる。パケットロス又はジッタによるオーディオの品質の劣化が、ビデオと比較して品質の知覚される劣化をさらに悪化させることになるため、オーディオデータは、高い優先度で送信され得る。

ビデオ再生コマンド（ＤｉｒｅｃｔＳｈｏｗ、Ｃｏｒｅ Ｖｉｄｅｏ、ＱｕｉｃｋＴｉｍｅ等）及びこれらのコマンドに関連するメディアデータストリームが、パススルー用ビデオインターセプタ４０３によって傍受され得る。インターセプタ４０３は、異なる種類のメディアについて、多数のコマンド固有のソフトウェアコンポーネントとして実装される。

一例において、Ｗｉｎｄｏｗｓ用のＤｉｒｅｃｔＳｈｏｗビデオインターセプタが、ＤｉｒｅｃｔＳｈｏｗの処理パイプラインにおいて最初であることを保証すべく、高い優先度でＤｉｒｅｃｔＳｈｏｗフィルタとして実装され得る。そのようなフィルタが、コマンド及びＡＰＩコール（ビデオファイルを再生する要求等）を除去し、それらをマルチキャスティングユニット４１３及びネットワークスタック４１４に伝える。

インターセプタ４０３は、送り側のシステムで再生せずに、そして、ビデオエンコーダ４０７で再符号化することなく、捕捉されたメディアデータを、レシーバに直接渡す。例えば、データは、パケットロス及び利用可能なバンド幅のようなネットワークの状況に応じて、ＦＥＣを伴うか又は伴わずに非保証型配信チャンネルにわたって送信され得る。

ビデオパススルーインターセプタ４０３は、（ビデオレンダリングのような）メディアレンダリングコマンドの組によって引かれる領域について領域検出器４０５と通信する。領域検出器４０５は、それがビデオエンコーダ４０７をこの領域に適用するかどうかを決定するために、この情報を用いる。決定は、レシーバ上の生のメディアデータを復号する必要のあるコーデックの利用可能性といった要因によって、又は、（レシーバ上の限られたＣＰＵの性能のような）他の理由によってビデオエンコーダが望ましい場合に、影響を受け得る。

対応する（ウェブカメラからのビデオファイル又はビデオストリームのような）データが、Ａ／Ｖラッパ４１１に送られる。ラッパ４１１は、メディアタイプ、フレームディスクリプションデータ等について情報を加えることになる。ラッパ４１１はまた、必要であれば、メディアを他のフォーマットにトランスコードする。ラッパ４１１は、レシーバでのメディアデータの互換性を保証し、レシーバにメディアデータを再生し直すための十分なメタデータを与える。

図５は、リモートコンピューティングのための改良型転送プロトコルを提供するための、クライアント上で実行されるデコーディング及びレンダリングエンジンを示す。クライアントは、レシーバ装置上で実行され、符号化されたデータを受信するように構成される。クライアントは、さらに、符号化されたデータをユーザのためのグラフィック出力にレンダリングできる。クライアントはまた、限定されないが、オーディオ、データファイル、データストリーム、プリンタデータストリーム等を含む他の種類の出力を復号化しレンダリングできる。

一実施形態において、レシーバは、ネットワーク伝送プロトコルスタック５０４、ビデオジッタバッファ５０６、ビデオデコーダ５１２及びビデオレンダラ５１８からなる。レシーバは、ビデオデコーダ５１２によってビデオデコーディングを利用するのみである。十分に低いフレームレートで、ジッタバッファ５０６が必要となる。受信された符号化データは、ピクチャエンコーディング、パススルーエンコーディング又はＧＤＩコマンドなしで送信されることによって、適切に符号化されることになる。

このレシーバは、ハードウェア内のデコーディングチップとして実装される、単純かつエネルギ効率の良い設計である。

他の実施形態において、単純なオペレーティングシステムは、システムサービスとして上述された要素５０４，５０６，５１２，５１８をロード及び実行できる。この実施形態は、５０４，５１２及び５１８を支援することが求められる追加の要素を含むであろう。

他の実施形態において、要素は、Ｍａｃ ＯＳ Ｘ又はＷｉｎｄｏｗｓ ７のようなオペレーティングシステム内で動作するソフトウェアコンポーネントとして実装され得る。

他の実施形態において、追加の種類の出力が上述したオーディオのようなレシーバによって支援される。レシーバは、追加のジッタバッファ５１９、出力デコーダ５２０、及び出力レンダラ５２１を含んで拡張され得る。

他の実施形態において、上述のように、アプリケーションのグラフィック出力を符号化するために、ハイブリッドアプローチが使用される。グラフィック出力は、４種類のデータ、グラフィックコマンド、ビデオフレーム、画像要素、及びパススルービデオに符号化される。４種類のデータは、図示される４つのパイプラインによって操作され、表示のためにリアルタイムにおける単一のピクチャに統合される。

グラフィックコマンドパイプラインは、グラフィックコマンド用のジッタバッファ５０５、グラフィックコマンドデコンプレッサ５０９、グラフィックコマンドトランスレータ５１１、グラフィックコマンドレンダラ５１５、及び分散型同期キャッシュ５１０を含む。

ビデオでコーディングパイプラインは、ビデオデコーダ用のジッタバッファ５０６及びビデオデコーダ５１２を含む。

画像ベースのデコーディングパイプラインは、画像要素用のジッタバッファ５０７、（多数種類であり得る）ピクチャデコーダ５１３、及び分散型同期キャッシュ５１０を含む。

パススルービデオパイプラインは、画像要素用のジッタバッファ５０８及びパススルービデオアンラッピング及びレンダリングのためのジッタバッファ５０７を含む。

パイプライン出力は、フレームコンポジタ５１６によって、単一の画像に結合される。画像は、画像内の領域境界を平滑化するスムージングトランスフォーメーションモジュール５１７によって処理される。画像は、その後、５１８でのグラフィック出力として表示される。

平滑化変換（スムージングトランスフォーメーション）は、異なる領域を符号化するために使用される異なる方法によって生じるアーティファクトを除去できる。平滑化変換の例は、デブロッキングトランスフォームである。異なる変換が、状況に応じて使用され得るということが理解されるであろう。

一実施形態において、ジッタバッファ５０５，５０６，５０７，５０８，５１９は、異なる実装及びアルゴリズムを有し得る。ジッタバッファは、異なる種類のデータを操作し、それ故、異なるニーズを有する。例えば、ジッタバッファは、ネットワークの高い遅延性が存在する場合に、低いフレームレートであっても、パフォーマンスを改良できる。したがって、多数のジッタバッファは、円滑なユーザ体験についての様々な出力の種類の同期を管理するように求められる。ジッタバッファは、それらのサイズを動的に変化させ、受信されたデータ上でタイムスタンプを確認し、受信されたデータを必要に応じて捨て、遅らせ、又は再配置する。これは、遅延性を管理し、そして、高品質の出力を、特に信頼性のないネットワークにわたって維持する。

例えば、グラフィックコマンド用のジッタバッファは、グラフィックＧＤＩコマンドが正しい順序で処理されるということを保証する。

キャッシュ５１０は、画像要素と、ビットマップ又はテクスチャのような受信したグラフィックコマンド用の引数とを引き出す。上述のように、キャッシュ５１０は、その送り側から受信したハッシュ数に基づくそのようなエンティティを保存できる。キャッシュ５１０は、独立したデータ通信チャンネルにわたって、サーバキャッシュからのそのデータを受信し、それ自体、送り側のキャッシュで同期された状態を維持する。

図６は、改良型転送プロトコルに関する、サーバによる捕捉、符号化、及び送信を実行する手順を示す。手順は、上述のように、１以上のクライアントと通信して、サーバ上で実行され得る。

６０１において、サーバは、実行中のアプリケーションからグラフィック出力を傍受する。例えば、アプリケーションは、単独のユーザのためのインタラクティブユーザインターフェースを提供するように構成される既存のアプリケーションであり得る。グラフィック出力及びユーザ入力（後述）を傍受することによって、アプリケーションは、多数のユーザに提供され得る。

代わりに、グラフィック出力は、傍受され、複数のクライアントに送信され得る。これは、例えば、広大な地理的範囲にわたって配置される複数のクライアントにマルチメディアを用いたプレゼンテーションを送信するために使用され得る。

６０２において、サーバは、領域検出手順を実行する。領域検出手順は、グラフィック出力を、１以上の領域に分けるように構成され、各領域は、後述のように、最適なデータ変換に影響を与える優位な特性を有する。

例えば、領域検出は、既述のモジュールによって提供され得る。一実施形態において、モジュールは、サーバ上で実行されるソフトウェアモジュールであり得る。他の実施形態において、モジュールは、専用ハードウェア、汎用ハードウェア、及びサーバにアクセス可能な実行中のソフトウェアの組み合わせであり得る。

６０３において、サーバを、上記で検出された領域をフィルタリングする。例えば、グラフィックＡＰＩコマンドは、ビデオ、ピクチャ、又はパススルー領域内には送られない。例えば、ビデオ及びピクチャデータは、パススルー領域内には送られない。

６０４において、サーバは、各領域のグラフィック出力を、変換された適切な出力に変換する。領域の４つの例が、それらに関する特性ととともに後述される。

グラフィックＡＰＩコマンドは、オペレーティングシステム又はグラフィック出力をレンダリングするように使用される他のコマンドである。例えば、Ｍｉｃｒｏｓｏｆｔ Ｗｉｎｄｏｗｓは、グラフィックコマンド、ウィンドウ、サークル及び他の形状を描くためのグラフィックコマンドの範囲を示す。そのような領域は、標準のＭｉｃｒｏｓｏｆｔ ＡＰＩを経由して検出され得る。他のオペレーティングシステムが、オペレーションの同様の原理を有し、また、同様の方式における領域検出に関して利用され得る標準ＡＰＩを有する。そのような領域は、オリジナルグラフィックコマンド内に最適に符号化され、スクリーンショットを送信することと比較して、バンド幅の要求を大幅に減少させる。

そのようなコマンドが、保証された方式において送信されなければならない、すなわち、１以上のＡＰＩコマンドがクライアントに対して失われた場合に、グラフィック出力を再構成することが難しい、ということが理解されるであろう。

ビデオデータは、ビデオコーデックで符号化され得る。ビデオデータは、連続的に移動しているユーザ体験における最小の影響で圧縮され得る。例えば、ビデオ内でより小さな移動があったときに、高品質コーデックに切り換えること、及び、ビデオ内でより大きな移動があったときに、低品質のコーデックに切り換えることというように、様々な最適化コーデックが使用され得る。人間の目が、ビデオの詳細よりもビデオ内においてより多くの移動を知覚するものであるということから、ハイムーブメントビデオが、より高い率で圧縮され得るということが理解されるであろう。

個別のロストパケットがビデオレンダリング全体において最小の影響を有するということから、そのようなビデオデータが非保証方式で送信され得るということが理解されるであろう。ネットワークの状況が、非常に信頼性のない場合（後述のネットワークスタックによって検出される）には、そのようなビデオデータが、順方向誤り訂正が適用されて、非保証方式で送信され得るということが理解されるであろう。

ピクチャは、ピクチャコーデックで符号化され得る。例えば、ピクチャコーデックは、上で使用されるビデオコーデックよりも高品質であり、グラフィックについても最適化され得る。移動の不足が、改良されたユーザ体験についてレンダリングを必要とするグラフィックの詳細に人の目を注目させるということから、ピクチャは、高品質を必要とする。

そのようなピクチャデータが、非保証方式において、但し、順方向誤り検査とともに送信され得るということが理解されるであろう。後述の順方向誤り検査を利用することによって最小化される得る表示されたグラフィック出力内において、符号化されたピクチャ内のエラーは、アーティファクトの結果を生じさせ得る。それは、保証型配信を利用することが可能な一方で、符号化されたピクチャデータは、非効率となり得る保証方式において送信するために、大きなバンド幅を必要とし得る。

ピクチャデータ及びビデオデータは、後述のモーション検出器モジュールを経由してグラフィック出力内において識別され得る。

パススルーデータは、例えば、クライアントによって圧縮解除され得る符号化されたビデオデータであり得る。符号化されたビデオデータをそのまま復号するための十分なリソース（ハードウェア、コーデック等）をクライアントが有し、符号化されたビデオデータがバンド幅及び品質要求を満たす場合には、サーバは、符号化されたビデオデータを、レンダリングのために、単純にクライアントに直接送信する。

符号化されたビデオデータのサイズ及びロストパケットに対するその抵抗に応じて、保証型、非保証型、又は、順方向誤り訂正配信を伴う非保証型のいずれかが後述のように使用され得るということが理解されるであろう。

６０５において、サーバは、変換された出力を送信する。上述のように、変換された出力は、デジタル情報を運ぶように構成されるネットワークにわたって送信され得る。変換された出力は、レンダリングのために１以上のクライアントに送信され得る。

６０６において、サーバは、変換された出力を適切なキューを経由して送信する。様々なキューが利用可能であり、各キューは、異なる送信及び信頼性の特性を伴って構成される。キューの例は以下を含む。

配信及び基本パケットのシーケンスを保証する、信頼性のあるキュー。信頼性のあるキューは、レシーバによって制御チャンネルにわたって送り返される肯定応答を信頼する。信頼性のあるチャンネルからのチャンクを伴う各パケットは、シーケンス番号を有する。定期的に、レシーバは、受信したパケットのシーケンス番号（＜＜ＡＣＫベクター＞＞チャンク）を送り側に送り返す。送り側がパケットについてのＡＣＫをしばらくの間受信しないとき、それは、パケットロストを考慮し、信頼性のあるチャンネルから出たパケットのチャンクを再送信する。それは、パケットの次の部分を送る前に、ＡＣＫを待つことはない。

配信及び基本パケットのシーケンスを保証しない信頼性のないキュー。信頼性のないキューは、命令を保存し、レシーバ側で複製を捨てるために、各パケットにインチャンネルシーケンス番号を付ける。いかなる検査も行われず、それ故、最小の可能な遅延及びＣＰＵ利用がつくり出される。観測可能なパケットロスが、（インターリービングによって）ネットワークパケットロスレートと等しいか又はこれをやや越え得る。

失われたパケットを回復させるのに役立つ送信されたパケット間に配分された重複情報を送信する、順方向誤り訂正（ＦＥＣ）を伴う信頼性のないキュー。一実施形態において、ＦＥＣ実装は、Ｌｕｂｙ変換コード（ＬＴコード）に基づき、これは、伝統的なＲｅｅｄ−Ｓｏｌｏｍｏｎよりも速くかつ単純である。これは、シングルパケットロス及びバーストパケットロスからの回復を許容する。一実施形態において、ＦＥＣは、XORに対するパケットサブセットを選択するＮ×Ｍマトリックス（オリジナルＬＴコードが疑似ランダムサブセットを使用する）を使用する。ビットレートオーバヘッドは等しい（Ｎ＋Ｍ）／（Ｎ＊Ｍ）。エミュレータを伴う検査が、ネットワークパケットロスレート１５％で、追加のＦＥＣが、観測可能なパケットロスを０．５％減少させ得るということを示した。５％のネットワークパケットロスについて、観測量は、〜０．０１％である。

他の実施形態において、ＦＥＣは、希に（非常に低いバンド幅、非常に高いパケットロス）、一般の場合（ネットワークバンド幅＞＞データビットレート、パケットロス＜２０％）におけるロバスト性を犠牲にする。これは、単一チャンネルが追加の遅延を他のチャンネルに導入することがあり得ないということを保証するＵＤＰパケット内で、チャンネルチャンクをインターリーブすることによって達成され得る。これは、パケットロスに関する遅延をほとんど取り除く。

６０７において、サーバは手順を終了する。

図７は、クライアントによって実行される、改良型転送プロトコルに関する、受信、復号化、及びレンダリングの手順の例を示す。手順は、上述のようにクライアント上で実行され得る。手順は、図６で上記したようにサーバからのデータを受信し得る。

７０１において、クライアントは、信頼性のあるキューからデータを受信し得る。信頼性のあるキューは、６０６において既述されたものであり得る。

７０２において、クライアントは、信頼性のないキューからデータを受信し得る。信頼性のないキューは、６０６において既述されたものであり得る。

７０３において、クライアントは、ＦＥＣを伴う信頼性のないキューからデータを受信し得る。ＦＥＣを伴う信頼性のないキューは、６０６において既述されたものであり得る。

各キューが既述のように動的に適合される１以上のジッタバッファに関連し得るということが理解されるであろう。

７０４において、クライアントは、任意の組み合わせで、１以上の上記のキューから変換された出力を受信し得る。それぞれのキューは、受信されたデータ及びキュープロトコルに関連する出力をつくり出し得る。ジッタバッファアルゴリズムは、７０４における多様な種類のデータを運ぶ多様なチャンネルに適用される。ジッタバッファは、レンダリングの後に受信されたデータの認知における歪みを最小化するのに有用である。オーディオデータの場合には、それは不具合及び欠陥を最小化するために使用される。ビデオの場合には、それは「メルティング」及び「ダスト」又は同様の歪みを最小化するために使用され得る。

信頼性のあるキューは、欠けているパケットの再送信を要求し、サーバによって送信されたパケットストリームを出力することが保証される。信頼性のないキューは、クライアントによって受信されると、パケットストリームを出力する。ＦＥＣを伴う信頼性のないキューは、既述のように、欠けているパケットを、順方向誤り訂正アルゴリズムで再構築することを試みる。

信頼性のないキュー及びＦＥＣを伴う信頼性のないキューについて、欠けているパケットは、近隣のパケットから合成され得る。例えば、欠けているパケットは、近接するパケットから推定される値が割り当てられて与えられ得る。

クライアントはまた、ネットワークの混雑の状況に応じて、ジッタバッファの能力を動的に調整できる。

７０５において、クライアントは、上記のキューから受信される、変換された出力を復号化し得る。クライアントは、変換された出力の各部を復号化する適切な方法を後述のように決定する。

７０６において、各種の変換された出力は、適切に復号化され得る。適切な復号化が、使用される符号化の種類において部分的に決定される。

例えば、グラフィックＡＰＩコマンドは、コマンドを適切なＡＰＩに送信することによって、クライアント上で複製される。大量のスクリーンデータが、最小のバンド幅の要求に伴って、この方式でレンダリングされ得る。

例えば、ビデオデータが、適切なコーデックによって復号化され得る。適切なコーデックは、サーバによって上記のように選択され得る。

例えば、ピクチャデータが、適切なコーデックによって復号化され得る。適切なコーデックは、サーバによって上記にように選択され得る。

例えば、パススルーデータが、更なる処理なしで、クライアントを簡単にパススルーできる。パススルーデータは、上述のキューから適合され、そして、利用可能なリソース（ハードウェア、コーデック）とともにクライアントによってレンダリングされる。

７０７において、グラフィック出力がレンダリングされる。既述のように、グラフィック出力のレンダリングは、グラフィックＡＰＩコマンドのレンダリング、ビデオデータのレンダリング、ピクチャデータのレンダリング、パススルーデータのレンダリングを含む。レンダリングは、フレームを構成すること、及び領域境界をデブロッキングすることをさらに含む。

７０８において、クライアントは、手順を終了する。

図８は、リモートコンピューティングのための改良型転送プロトコルを提供するためのネットワークスタックの例を示す。ネットワークスタックは、上述のように、サーバによって提供され得る。

アプリケーション８０１は、サーバ上で実行され得る。上述のように、アプリケーション８０１は、グラフィック出力を提供するサーバ上で実行されるいかなるソフトウェアでもあり得る。例えば、ソフトウェアは、ユーザが望む機能性に関するユーザインターフェースを提供するアプリケーションであり得る。

信頼性のあるチャンネル８０２は、パケットの保証型送信を提供し得る。信頼性のあるチャンネル８０２は、上述のような信頼性のあるキューに対応し得る。

信頼性のないチャンネル８０３は、パケットの非保証型送信を提供し得る。信頼性のないチャンネル８０３は、上述のような信頼性のないキューに対応し得る。

ＦＥＣを伴う信頼性のないチャンネル８０４は、順方向誤り訂正を伴う、パケットの非保証型送信を提供し得る。ＦＥＣを伴う信頼性のないチャンネルは、上述のようなＦＥＣを伴う信頼性のないキューに対応する。ＦＥＣは、必要であれば、欠けているパケットの再構築を許容する、パケット間のリダンダンシーを提供する。これは、最小の追加オーバヘッドを伴うチャンネルの信頼性を増加させる。

上述のような各キューは、１以上のチャンネルと関係し得る。各チャンネルは、優先度レベルと関係し得る。ネットワークスタックは、その優先度レベルに関係する各チャンネルを操作し得る。加えて、チャンネルは、必要であれば、多数の実行中のアプリケーションの間で分割され得る。

ネットワークフィードバックモジュール８０５は、ネットワークの混雑を監視し、必要に応じて送信パラメータを修正する。例えば、衝突の増加がネットワーク上で検出された場合には、送信レートが減少させられ得る。増加したパケットロスが検出された場合には、システムは、非保証型チャンネルからＦＥＣを伴う非保証型チャンネルまで、特定の種類のデータの送信を切り換えることができる。また、ネットワークの状況に応じて、ＦＥＣパラメータは、バンド幅及びパケットロスレベルに影響を与えて調整され得る。同様に、少ない数の衝突が検出された場合には、ネットワークフィードバックモジュール８０５は、送信レートにおける増分が保証されたことを示す。

デマルチプレクサ８０６が、ネットワーク送信から受信されたパケットを多重化解除する。パケットは、適切なチャンネルに多重化される。例えば、各パケットは、それが属するチャンネルを確認するチャンネル識別子を含み得る。

マルチプレクサ及びパケットキュー８０７は、ネットワーク伝送にわたる送信のために、チャンネルからパケットキュー内へとパケットを多重化する。上述のように、各パケットは、チャンネル識別子を含み得る。マルチプレクサは、異なるチャンネルの優先度を考慮する。

ＡＣＫセンダモジュール８０８は、信頼性のあるチャンネルについてクライアントから必要な肯定応答を受信し得る。レシーバは、受信されたパケットのパケット識別子を定期的に送信する。例えば、パケット識別子は、ＡＣＫベクターチャンクとして送信され得る。一旦、ＡＣＫセンダモジュール８０８が、ＡＣＫベクターチャンクを受信すると、識別されたパケットは、レシーバによって受信されたということがわかる。

輻輳制御８０９は、輻輳制御モジュールを実行し得る。ネットワーク伝送プロトコル内における効果的な輻輳制御は、混雑の衝突を防止する。混雑の衝突が起こると、混雑、高いパケットロス、及び高いパケットによってほとんど有用でないスループットが生じる。従来の輻輳制御アルゴリズムがＴＣＰ及び他のネットワークプロトコルにおいて実装されるが、高いバンド幅リンクを使用する低遅延性の高品質データストリーム配信を配信するのに十分効果的かつ積極的ではない。一実施形態において、ネットワーク伝送プロトコルは、利用可能なバンド幅を効果的に調べ、利用可能なネットワークの容量を利用する、異なる輻輳制御メカニズムを利用できる。

用語及び定義

ネットワークの混雑−ネットワークの混雑は、リンク又はノードが、そのサービスの品質が悪化する多くのデータを運ぶときに生じる。典型的な効果は、待ち行列遅延、パケットロス又は新しい接続のブロッキングを含む。

混雑信号−混雑がネットワークパス上で生じたという通知。２つの連続するロスト又はタイムアウトパケットによってトリガされる。

ラウンドトリップタイム（ＲＴＴ）−パケットが特定のソースから特定の目的地へと移動し、かつ戻るために必要な時間。

インターパケットギャップ（ＩＰＧ）−送り側によって送られる連続するパケット間の時間遅延。

ラウンド−アルゴリズムの一ステップ。ラウンドタイムは、i番目のラウンドで生じるアクションが（i−１）番目のラウンドで生じたアクションに対するネットワークリアクションへの応答であるような平均ＲＴＴに等しい。

輻輳制御アルゴリズムの説明

アルゴリズムは、レートベースであり、ＩＰＧ値を通じた制御データレートである。反対に、ＴＣＰは、混雑ウィンドウ値を利用する。アルゴリズムは、ＲＴＴサンプル及び入力される混雑信号を取得する。

ＲＴＴサンプルは、それぞれ送信されたパケットに関して計算される。ＲＴＴサンプルは、パケットが送られたときと認識されたときとの間の時間遅延である。それ故、ＲＴＴサンプルは、認識された各パケットとともに到着する。ＲＴＴサンプルが与えられることにより、以下の４つの生成された特性を計算できるようになる。

ＲＴＴ−ゲインαを伴う受信されたＲＴＴサンプルの指数平滑平均。

詳細ＲＴＴ（DetailedRTT）−ゲインβ，β＞αを伴う受信されたＲＴＴの指数平滑平均。

ＲＴＴ分散（RTTVariance）−平均ＲＴＴからのＲＴＴサンプルの分散。

ベースＲＴＴ（BaseRTT）−今までのＲＴＴの下限の近似。

ＲＴＴは、長期間にわたる平均であり、詳細ＲＴＴは、より短期間にわたる平均であり、そして、ベースＲＴＴは、混雑していないネットワークにわたる達成可能な最小の往復時間の近似である。

この値から、３つの無次元の変数が導かれる。

フィードバックは、その平均の状態に関する現在におけるルータのキューの状態を特徴づける。フィードバックは、通常、（０．５，１．５）の範囲内にあるが、理論上は、ある正の数であり得る。

制御は、ＩＰＧの値を変化させることで実行される。送り側は、連続するパケット間の時間遅延が、輻輳制御アルゴリズムから得られるＩＰＧよりも大きいということを保証する。ＩＰＧは、送られた各パケットの後に変化し、以下の方式によって計算される。

ここで、ベースＩＰＧｉ（BaseＩＰＧi）−現在のラウンドについての所望のＩＰＧの値。それは、各ラウンド又は混雑の信号に応答して更新される。

ベースＩＰＧｉは、以下のアルゴリズムに従って更新される。

混雑が生じた場合には、

ここで、Ａ＞１（通常は２に近い）

ｉ番目のラウンドで混雑が生じない場合には、

上の式は、パケットレートに関して説明される。パケットレートは、毎秒に送られるパケット数である。詳細なＩＰＧ制御の考慮なしで、パケットレートは以下のように表現される。

そして、上の式から以下が導かれる。

接続確立シーケンス

サーバは、接続について聞き取りを行い、クライアントは接続（ＴＣＰにおいて）を行う。

４ウェイハンドシェイク。より多くのＤｏＳ攻撃への抵抗。

３ウェイシャットダウン。ＴＣＰにおいて、半分閉じた状態でバグ無し。

接続確立及びシャットダウンのための正確なシーケンスが後述される。

ネットワークサポート８１０は、ＵＤＰ／ＩＰのような既存のプロトコルによって提供され得る。他のプロトコルも使用できるが、ネットワークークスタックの多くの利益を取り除くことになるということが理解されるであろう。例えば、ＴＣＰ／ＩＰの使用は、使用されるチャンネルにかかわらず、全てのパケットの保証型配信を与えることになるが、重要なプロセッサ及びバンド幅オーバヘッドを追加する。

図９は、領域検出器モジュールを提供する、サーバによって実行される手順の例を示す。領域検出器は、動きを検出すること及びグラフィック及びビデオコマンドのストリームを監視することによって、グラフィック出力における各領域に関する適切な符号化スキームを決定する。

グラフィック出力は、最初に領域に分割される。一実施形態において、グラフィックコマンドエンコーディング（符号化）は、領域が相対的に静的であり、かつ、テキストドローイングのような２ＤグラフィックＡＰＩコマンドによって生成されるテキスト又は簡単なグラフィックを含む場合に適用される。ビデオエンコーディング（符号化）は、強い動きを伴う領域に適用される。デコーディングコーデックＣＰＵリソースがレシーバ上で利用可能である場合に、パススルービデオエンコーディング（符号化）は、メディアＡＰＩコマンドを使用するビデオストリームを再生することによって生成されるビデオを伴う領域に使用され得る。

プログレッシブウェーブレットベースドコーデックが、しばしばゆっくりと変化する動的な大きな部分を伴う領域に適用される。そのような領域の例は、３〜５秒毎に画像を変化させるフォトスライドショウであり得る。ロスのない簡単なピクチャの圧縮が、非常に急速に変化することのない小さな領域に使用される。システムはまた、上述のような分散型キャッシュシステムを使用する。

領域検出器は、相対的に高い周波数（毎秒２５フレーム以上）を伴うビットマップ（又はフレーム）Ｆ_k（９０１）を与えるフレーム捕捉法に頼る。領域検出器は、その後、Ｆ_k（９０１）に関する「モーションクラスマップ」Ｃ_k（９０５）を演算するために、後述の簡単なモーション検出ルーティン９０２を適用する。

その結果としてのＣ_k（９０５）は、後述のように、グリッドの各ブロックに割り当てられた動きの強度を伴う数のマップである。ステップ９０３は、その後、領域の組｛Ｒ₁ ^k，Ｒ₂ ^k，…，Ｒ_N ^k｝９０７を構築し、これは、後述のように、所定の領域内でのＣ_kのレベルを伴う微小領域の凸包である。一実施形態において、微小領域の凸包の構築のステップは、効率性の目的のために省略され得る（これは、より簡単で、より少ない知的アルゴリズムの結果となる）。

領域には、領域の動きの強度に基づく色が割り当てられ得る。強い動きを伴う領域は赤色であり、他方、動きのない領域は白色である。現れ始める散発的な移動は緑色であり、他方、動きが遅くなっている領域は黄色である。これらの統合された領域９０７は、マクロ領域と呼ばれ、これとともに、モーションクラスマップＣ_k（９０５）が入力としてマクロ領域アナライザ９０８に引き渡される。統合された領域が構築されていない場合には、その後、マクロ領域アナライザアルゴリズムが、知的でなくなるが、単純化されより速くなる。これは実施中にトレードオフとして考慮され得る。

マクロ領域アナライザ９０８はまた、上述のように、（ＧＤＩのような）ＡＰＩコマンド及び（ＤｉｒｅｃｔＳｈｏｗのような）ビデオＡＰＩコマンドのストリームを監視する。アナライザ９０８は、ビデオエンコーダ、ピクチャエンコーダタイプ１（大きなピクチャ）、及びピクチャエンコーダタイプ２（小さな画像要素）によって使用される領域の組９１２，９１０，９１１を出力する。アナライザ９０８はまた、９１３において、ネットワークにわたって送信されないグラフィック及びビデオコマンドを捨てる。

領域の組９０９（「送信しない」）について、グラフィック／ビデオＡＰＩコマンドエンコーディング（符号化）が使用され、又は、情報の必要性が全く送信されない（ピクチャが静的である）。

一実施形態において、「赤色」の領域が、ビデオとともに符号化され、又は、９１６におけるビデオパススルーを使用して送信される。動きがＧＤＩコマンドによって生成される（ＧＤＩ領域が緑色の領域にオーバラップする）「緑色」の領域は、ＧＤＩコマンドエンコーディングとともに送信され得る。代わりに、領域のサイズによって、ピクチャコーデック「大」又は「小」が、領域を符号化するために使用され得る。領域が小さな領域に関して大きくかつ簡単である場合に、「黄色」の領域がピクチャコーデックで符号化され得る。簡単なヒューリスティックスの例が存在するということに留意されるべきである。しかしながら、微小及びマクロ領域を操作する他の技術とその状況が発展され得るということが理解されるべきである。

９１４において、タイプ１のピクチャエンコーダは、プログレッシブ（例えばウェーブレットベースの）画像エンコーダであり得る。エンコーダは、相対的に大きな画像（幅及び高さが閾値Ｗ_max及びＨ_maxを越える）に対してのみ適用される。

９１５において、タイプ２のピクチャエンコーダは、単純化した高速無損失画像コンプレッサである。エンコーダは、小さな画像、典型的に、ブロックのサイズ（幅及び高さが閾値Ｗ_max及びＨ_maxを越えない）に対してのみ適用される。

マクロ領域アナライザのヒューリスティックスがさらに以下に説明される。

図１０は、簡単なモーション検出器モジュールを提供するための、サーバによって実行される手順の例を示す。

１００１において、サーバは、コンピュータが生成したフレームＦ_k、ここでｋはフレーム数、を受信する。

１００２において、サーバは、以下で利用されるビデオエンコーディングコアのマクロブロック構造に関して、Ｆ_kを（ｐ×ｑ）における矩形又は四角形のブロックｂ^k _p,qに分割する。

１００３において、フレームＦ_kの各ブロックｂ^k _i,jについて、サーバは、ブロックを前のフレームＦ_k-1の同じブロックｂ^k-1 _i,jと比較する。

１００４において、サーバは、ブロックｂ^k _i,jがブロックｂ^k-1 _i,jと等しいかどうかを検査する。もし、等しければ、サーバは、１００５ａに進む。等しくなければ、サーバは、１００５ｂに進む。

１００５ａにおいて、サーバは、微小領域ｂ_i,jについてモーションスコアｍ^k _i,jを減少させ、ｍ^k _i,j＝ｍ^k _i,j−Δ₁を設定する、ここで、Δ₁は負でない整数である。一実施例において、Δ₁＝１。

１００５ｂにおいて、サーバは、微小領域ｂ_i,jについてモーションスコアｍ^k _i,jを増加させ、ｍ^k _i,j＝ｍ^k _i,j＋Δ₂を設定する、ここで、Δ₂は負でない整数である。一実施例において、Δ₂＝４。

１００６において、サーバは、各モーション領域ｂ_i,jに、モーションスコアｍ^k _i,jの値に基づいてモーションクラス（「色」）ｃ^k _i,jを以下のように割り当てる。

ｍ^k _i,j＝０の場合、ｃ_i,j＝０（モーションクラス「透明」）、

０＜ｍ^k _i,j＜Ｔ₁の場合、ｃ^k _i,j＝１（モーションクラス「緑」）、

Ｔ₁＝ｍ^k _i,j＜Ｔ₂の場合、ｃ^k _i,j＝２（モーションクラス「黄」）、

Ｔ₂＝ｍ^k _i,j＜Ｔ₃の場合、ｃ^k _i,j＝３（モーションクラス「赤」）、

ここで、Ｔ₁，Ｔ₂，Ｔ₃は、モーションスコアｍ_i,jに関する閾値である。一例において、Ｔ₁＝１０、Ｔ₂＝２０、Ｔ₃＝３０。

１００７において、サーバは、ｃ^k _i,jの値の（ｐ×ｑ）の長方形配列Ｃ_kを出力する。

サーバは、現在のフレームレート（典型的に毎秒２０〜４０回）の周波数で、例示された処理ルーティンを実行するということが理解されるであろう。

図１１Ａは、第１のモーション検出例のスクリーンショットを示す。表示されるウェブサイトスクリーンショットは、２つのモーションインテンシブ領域を有する。急速に変化するフラッシュアニメーションであるということから、領域１１０１は、「赤」として認識されている。領域１１０２は、Ａｄｏｂｅ Ｆｌａｓｈビデオになっているということから、「赤」として認識されている。動きがより強くなくなる領域１１０１の右側に四角形が存在する。この微小領域は、簡単な無損失ピクチャコーデックを使用して符号化される。ピクチャ要素はまた、キャッシュされる。

図１１Ｂは、第２のモーション検出例のスクリーンショットを示す。表示されるウェブサイトスクリーンショットは、上述のものと同様であり得るが、緑（１１０５）と黄（１１０４）を含む。これらの領域は、上記のスクリーンショットとはわずかに異なり、ＯＳグラフィックＡＰＩコマンドによって生成されていない。代わりに、これらの領域は、Ａｄｏｂｅ Ｆｌａｓｈアニメーションとして生成されており、領域は、簡単な無損失コーデックで符号化される。代わりに、領域は、キャッシュされ、送信を要求しない。

領域１１０５は、しばしば変化する大きな画像を含む。マクロ領域ピクチャベースのウェーブレットコーデックが使用されることになる。

領域１１０３及び１１０６は、モーションインテンシブであり続け、ビデオエンコーダを使用して符号化されることになる。

図１１Ｃは、第３のモーション検出例のスクリーンショットを示す。表示されるウェブサイトスクリーンショットは、上述したものと同様であるが、そのピクチャがより速く変化し始めたということから、領域１１０８がその色を緑から黄に変えている。領域検出器は、符号化のために、ピクチャベースのウェーブレットコーデックを使用し続けることができ、又は、領域検出器は、全体の領域をビデオ領域として取り扱うことができる。

領域１１０７及び１１０９は、上述のように、符号化を続ける。

図１２は、リモートコンピューティングのための改良型転送プロトコルを提供するためのビデオの例を示す。ビデオエンコーダは、Ｈ．２６４／ＭＰＥＧ−４のような標準のビデオエンコーディングアルゴリズム又は専用の低遅延性ビデオエンコーダを実装し得るビデオエンコーディングコア１２０５を含む。他の状況が改良されたパフォーマンスのための専用のソリューションを必要とする一方で、特定の状況が標準対応のビデオエンコーディングコアを必要とするということが理解されるであろう。

ここで望ましいビデオエンコーダは、画像にわたってブラックマスクを重ねるフレームプレプロセッサ１２０４を有する。これは、ビデオエンコーダが、必要な領域を処理することのみを許容する。フレームの前処理が後述される。

ビデオエンコーディングコアコントローラ１２０１は、様々なシステムコンポーネントと通信し、特定のパラメータでエンコーディングコアを初期化し、又は、これらのパラメータ（画像サイズ又はビットレート等）を変える。

いくつかのソリューションについての同時符号化を提供することで、エンコーディングコアの多数のインスタンスが同時に動作することが可能になる。

領域ヒストリ／キャッシュ１２０２は、領域検出器の使用又はビデオ領域に対する高速予測スイッチングに関するこれまでの分析から、数十のフレーム及び領域の組を維持する。

図１３は、グラフィック出力を前処理することについての手順の例を示す。手順は、サーバ上で上述のように実行され得る。記載される手順の目的は、異なる領域の座標及びサイズを伴うエンコーディングコアの頻繁な再初期化を回避することである。そのような手順は、時間及びパフォーマンスに関してコストがかかることを示している。解決策は、大きな領域でそれを初期化し、ブラックレイヤを動いていない領域に重ねることであり、それ故、ビデオエンコーディングコアのビルトインモーションエスティメーション処理の処理リソースを保存することであり、非送信の結果となる大多数の場合に、動いていない領域の効率的な送信を許容する。

１３０１において、サーバは、フレームＦ_k１３０８（幅×高さ）のフルサイズの大きさを伴うビデオエンコーディングコアを初期化する

１３０２において、サーバは、上述のマクロ領域アナライザから、ビデオエンコーディングのための領域の組｛ＶＲ₁ ^k，ＶＲ₂ ^k，…，ＶＲ_N ^k｝を受信する。

１３０３において、サーバは、領域｛ＶＲ₁ ^k，ＶＲ₂ ^k，…，ＶＲ_N ^k｝の画像を、黒色（＃００００００）及びフレームＦ’_kを得るためにフレームＦ_kのサイズに等しいサイズＷ×Ｈの矩形のＢＬＡＮＫ_W×_Hにわたって重ねる。Ｆ’_k＝ＢＬＡＮＫ_W×_H＋ＶＲ₁ ^k＋ＶＲ₂ ^k＋…＋ＶＲ_N ^k、ここで、「＋」の演算は、ビットマップ上で実行される論理和（ＯＲ）を表す。ＶＲ₁ ^k（１３０６）、ＶＲ₂ ^k（１３０７）、及びＶＲ₃ ^k（１３０９）が例示される。

１３０４において、サーバは、一連のフレーム｛Ｆ’_k｝を上述のビデオエンコーディングコアへの入力として提供する。例えば、ビデオエンコーディングコアは、Ｈ．２６４規格を利用し得る。

１３０５において、サーバは、例えば、ビデオ圧縮のためのＨ．２６４／ＭＰＥＧ−４ＡＶＣ規格又は他の規格を使用して、フレーム｛Ｆ’_k｝を符号化する。

図１４は、プログレッシブピクチャエンコーダを提供するための手順の例を示す。上述のように、サーバ上で実行され得る。ピクチャエンコーダは、２つのシリーズにおける符号化された画像データ、第１のシリーズ１４１５及び第２のシリーズ１４１６を準備するということから、プログレッシブピクチャエンコーダは、進歩的である。１４１５において、サーバは、大まかな画像をクライアント上で描くためのＬＬサブバンドを即座に送信する。

第１のシリーズ１４１５は、より小さなサイズであり、レシーバに速く送信され、画像のぼやけたバージョンを提供する。その一方、第２のシリーズ１４１６は、より多くのデータを伴う圧縮されたピクチャのフルクォリティバージョンである。第２のシリーズ１４１６は、より大きな遅延性とともにレシーバに送信され得る。

エンコーダは、追加の粒度を提供し得るということが理解されるであろう。このエンコーダが大画像に適しているということが理解されるであろう。

第１ステップにおいて、エンコーダは、入力ＲＧＢ画像（１４０１）をＹＣｂＣｒカラースペース（１４０２）に変換し、Ｙ成分（１４０３）、Ｃｂ成分（１４０４）、及びＣｒ成分（１４０５）をつくり出す。Ｙ成分は、ルマ成分（「明るさ」）である。Ｃｒ成分は、青が異なる彩度成分である。Ｃｒ成分は、赤が庫尾なる彩度成分である。

第２のステップにおいて、エンコーダは、上の各成分（１４０６−１４０８）に対して、ハール（Ｈａａｒ）のような目立たないウェーブレット変換を適用する。Ｃｂ及びＣｒ成分のためのプロセッシングパイプラインは、Ｙ成分（図中に示される）と同じであり得る。

第３のステップにおいて、エンコーダは、結果（１４１５）を出力する前に、ＲＬＥコンプレッサ（１４１３）を伴う結果を圧縮し、ネットワークへの送信に先だって、ＲＬＥとともにそれを圧縮する第１のデータシリーズのためのＬＬウェーブレットサブバンドを利用する。ステップ１４１３は、ＬＬサブバンドからの結果を、全体の出力サイズから半分をやや上回るほどに圧縮することができる。

ランレングス符号化（ＲＬＥ）が、データの「ラン（runs）」（「ラン」は、連続したデータ要素内で同じデータが生じるシーケンスのことである）が、オリジナルランとしてよりもむしろ、単一データ値又はカウントとして保存されるデータ圧縮の形式であるということが理解されるであろう。ＲＬＥは、非常に簡単でかつ高速の圧縮アルゴリズムである。しかしながら、他のデータ圧縮アルゴリズムが使用されてもよい。

３つの残りの３ウェーブレットサブバンドが同様に処理される。ＨＬ、ＬＨ及びＨＨサブバンド（１４１０−１４１２）が、出力される（１４１６）前に、ＲＬＥコンプレッサ（１４１４）に供給される。

ウェーブレットサブバンドは、４つの「サブ画像」を表し、ＬＬは、オリジナル画像のより小さなバージョンを表し、ＨＨは、ノイズレベルを表すということが理解されるであろう。サブバンドは、高度の相関を有し、良く圧縮され得る（すなわち、ＲＬＥアルゴリズムで）。

図１５Ａは、パケット構造の例を示す。パケットフォーマット１５００は、上記のシステム内での使用のためのパケットフォーマットの一例を示す。

図１５Ｂは、チャンクフォーマットの例を示す。汎用チャンクフォーマット１５０２は、上記のシステム内での使用のためのチャンクフォーマットの一例を示す。

図１５Ｃは、信頼性のあるチャンネル及び信頼性のないチャンネルのためのチャンクフォーマットの例を示す。チャンクフォーマット１５０４は、上記のシステム内での使用のためのチャンクフォーマットの一例を示す。

図１５Ｄは、ＦＥＣチャンネルのためのチャンクフォーマットの例を示す。チャンクフォーマット１５０６は、上記のシステム内での使用のためのチャンクフォーマットの一例を示す。

図１５Ｅは、ピングチャンクフォーマットの例を示す。ピングチャンクフォーマット１５０８は、上記のシステム内での使用のためのチャンクフォーマットの一例を示す。

図１５Ｆは、ピングレスポンスチャンクの例を示す。ピングレスポンスチャンクフォーマット１５１０は、上記のシステム内での使用のためのチャンクフォーマットの一例を示す。

図１５Ｇは、ハンドシェイクシーケンスを例示する。１５１２において、クライアントは、そのイニシャルシーケンス番号を伴うＩＮＩＴを送信することによって開始する。

図１５Ｈは、ｉｎｉｔチャンクの例を示す。ｉｎｉｔチャンクフォーマット１５１４は、上記のシステム内での使用のためのチャンクフォーマットの一例を示す。

図１５Ｉは、ｉｎｉｔ＿ａｃｋチャンクの例を示す。ｉｎｉｔ＿ａｃｋチャンクフォーマット１５１６は、上記のシステム内での使用のためのチャンクフォーマットの一例を示す。サーバは、サーバイニシャルシーケンス番号及びクッキー（バイナリデータ）を含むＩＮＩＴ＿ＡＣＫに応答する。

図１５Ｊは、ｃｏｏｋｉｅ＿ｅｃｈｏチャンクの例を示す。ｃｏｏｋｉｅ＿ｅｃｈｏチャンクフォーマット１５１８は、上記のシステム内での使用のためのチャンクフォーマットの一例を示す。上記のｉｎｉｔ＿ａｃｋチャンクに応答して、クライアントは、Ｆ（クッキー）を含むＣＯＯＫＩＥ＿ＥＣＨＯに応答する。

図１５Ｋは、ｃｏｏｋｉｅ＿ａｃｋチャンクの例を示す。ｃｏｏｋｉｅ＿ａｃｋチャンクフォーマット１５１８は、上記のシステム内での使用のためのチャンクフォーマットの一例を示す。上記のｃｏｏｋｉｅ＿ａｃｋチャンクに応答して、サーバは、ＣＯＯＫＩＥ＿ＡＣＫを送信し、それ故、クライアントに連続接続を通知する。サーバは、連続するＣＯＯＫＩＥ＿ＥＣＨＯの後にのみ、あらゆるヘビーウェイト内部構造を割り当て、それ故、ＴＣＰにおけるＳＹＮ＿ｆｌｏｏｄに類似する攻撃を防ぐ。

図１５Ｌは、接続シャットダウンシーケンスの例を示す。フロー１５２２は、ピア１が全てのペンディングデータを送信し、その後、ＳＨＵＴＤＯＷＮを送信する。

ピア２は、ＳＨＵＴＤＯＷＮを受信すると、全てのペンディングデータを送信し、その後、ＳＨＵＴＤＯＷＮ＿ＡＣＫを送信する。

ＳＨＵＴＤＯＷＮ＿ＡＣＫを受信すると、ピア１は、ＣＯＭＰＬＥＴＥを送信し、それ故、ピア２に、接続がシャットダウンされたことを通知する。

図１５Ｍは、シャットダウンチャンクの例を示す。シャットダウンチャンクフォーマット１５２４は、上記のシステム内での使用のためのチャンクフォーマットの一例を示す。

図１５Ｎは、ｓｈｕｔｄｏｗｎ＿ａｃｋチャンクの例を示す。ｓｈｕｔｄｏｗｎ＿ａｃｋチャンクフォーマット１５２６は、上記のシステム内での使用のためのチャンクフォーマットの一例を示す。

図１５Ｏは、ｓｈｕｔｄｏｗｎ＿ｃｏｍｐｌｅｔｅチャンクの例を示す。ｓｈｕｔｄｏｗｎ＿ｃｏｍｐｌｅｔｅチャンクフォーマット１５２８は、上記のシステム内での使用のためのチャンクフォーマットの一例を示す。

上述のレシーバの一実施形態がコンタクトレンズディスプレイであり得るということが理解されるであろう。コンタクトレンズディスプレイは、「Augmented Reality in a Contact Lens」ＩＥＥＥスペクトラム、２００９年９月、http://www.spectrum.ieee.org/ biomedical/bionics/augmented-reality-in-a-contact-lens/0（２００９年９月２８日に最後に検索）において議論されており、参照によってここに組み入れられる。そのようなコンタクトレンズは、着用者に情報を表示でき、ワイヤレス装置にわたって通信できる。これらの装置は、上述のようにレシーバとして機能でき、着用者の視界にグラフィックを重ねることで、ユーザの現実感を増大させ得る。コンパクトな装置になると、これらの装置は、例えば、グラフィックコマンド及びテキストをレンダリングするだけというように、機能的に制限され得る。そのような装置の一実施形態は、着用者が自身の環境における対象物に集中できるように、関連するテキストを表示することができる。

上記のグラフィック出力が３Ｄグラフィックを含み得るということが理解されるであろう。３Ｄグラフィックは、多数のカメラで撮られ、その後に、ホログラム又は他の３Ｄ画像をつくり出すために一緒に統合される特別なグラフィックであり得る。そのような３Ｄグラフィックは、上記のシステムによって容易に支援され、３Ｄグラフィックは、サーバによって適切に圧縮され、レンダリングのためにレシーバに送信される。レシーバが適切なコンピューティングリソースとレンダリング性能を有すると仮定すると、３Ｄグラフィックは、ユーザによってレンダリングされ得る。３Ｄグラフィックは、「3D: It's Nearly There」エコノミスト技術季刊誌、２００９年９月５日、第２２頁で議論され、参照によってここに組み入れられる。

上述のように、本発明の一実施形態は、コンピュータ生成出力、特に、グラフィック出力、または他の種類の出力を提供するためのシステムであり得る。システムは、デジタル情報を運ぶように構成されるネットワークを含む。システムは、ネットワークと通信するサーバを含み、サーバは、アプリケーション、及び出力捕捉及びエンコーディングエンジンモジュール（ＯＣＥエンジン）を実行するように構成される。アプリケーションは、グラフィック出力を提供する。ＯＣＥエンジンモジュールは、さらに、アプリケーションからグラフィック及び他の種類の出力を傍受するように構成される。ＯＣＥエンジンモジュールは、さらに、グラフィック出力を、グラフィックコマンド及びビデオコーデックデータの少なくとも１つに変換するように構成される。ＯＣＥエンジンは、データ圧縮及び符号化（オーディオストリーム、データファイル等）のための適切な方法を利用して、他の種類の出力を符号化する。ＯＣＥエンジンモジュールは、さらに、変換された出力をネットワークにわたって送信するように構成される。システムは、ネットワークにわたってサーバと通信するクライアントを含み、クライアントは、グラフィック及びビデオの復号化及びレンダリング（ＧＶＤＲエンジン）を実行するように構成される。ＧＶＤＲエンジンモジュールは、送信された、変換された出力を受信することに応じて、グラフィック出力をレンダリングするように構成される。ＧＶＤＲエンジンモジュールは、クライアントでユーザ入力を傍受するように構成される。ＧＶＤＲエンジンモジュールは、傍受されたユーザ入力を、サーバ上の入力処理モジュールに送信するように構成される。ＯＣＥエンジンモジュールは、さらに、グラフィック出力を、ピクチャコーデックデータ及びパススルーデータの少なくとも１つに変換するように構成され得る。ＯＣＥエンジンモジュールは、さらに、領域検出器モジュールを実行するように構成され得る。領域検出器モジュールは、グラフィック出力を複数の領域に分割するように構成される。領域検出器モジュールは、各領域に関連するグラフィック出力を変換するように構成される。グラフィック出力は、フルモーションビデオを含むことが可能であり、フルモーションビデオは、複数の領域の１つの内に含まれる。グラフィックコマンドは、ユニバーサルインターミディアリーグラフィックコマンド言語によって表され得る。クラウドエンジンモジュールは、さらに、傍受されたユーザ入力をクライアントから受信するように構成される。サーバ上の入力処理モジュールは、さらに、傍受されたユーザ入力を処理のためにアプリケーションに提供するように構成される。ネットワークは、信頼性のない状態であり、ネットワークにわたる送信は、非保証型であり得る。

本発明の他の実施形態は、グラフィック出力を提供するためのシステムであり得る。システムは、デジタル情報を運ぶように構成されるネットワークを含む。システムは、ネットワークと通信するサーバを含み、サーバは、アプリケーションとＯＣＥエンジンモジュールとを実行するように構成される。アプリケーションは、グラフィック出力を提供し得る。ＯＣＥエンジンモジュールは、さらに、グラフィック及び他の種類のコンピュータ生成出力をアプリケーションから傍受するように構成される。ＯＣＥエンジンモジュールは、さらに、傍受された出力をグラフィックコマンド及びビデオコーデックデータに変換するように構成される。ＯＣＥエンジンモジュールは、さらに、変換された出力をネットワークにわたって送信するように構成される。システムは、ネットワークにわたってサーバと通信する複数のクライアントを含み、複数のクライアントのそれぞれは、ＧＶＤＲエンジンモジュールを実行するように構成される。ＧＶＤＲエンジンモジュールは、送信された、変換された出力を受信することに応じて、グラフィック出力をレンダリングするように構成される。ＧＶＤＲエンジンモジュールは、ユーザ入力を傍受するように構成される。ＧＶＤＲエンジンモジュールは、傍受されたユーザ入力を、アプリケーションによって処理するために、サーバ上の入力処理モジュールに送信するように構成される。

本発明の他の実施形態は、グラフィック及び他の種類のコンピュータ生成出力を送信するための方法であり得る。本方法は、グラフィック出力又は他の種類のコンピュータ生成出力を、実行中のアプリケーションから傍受することを含む。本方法は、傍受されたグラフィック出力を、グラフィックコマンド及びビデオコーデックデータの少なくとも１つに変換することを含む。本方法は、変換された出力を、ＧＶＤＲエンジンモジュールを実行するクライアントに、ネットワークにわたって送信する。その送信は、変換された出力を信頼性のあるキュー、信頼性のないキュー、及び順方向誤り訂正を伴う信頼性のないキューに解析し、各キューは、複数のチャンネルを有する。その送信は、信頼性のあるキューを送信することを含み、信頼性のあるキューの各パケットは、クライアントによって認識され、かつ、信頼性のあるパケットシーケンス番号を含む。その送信は、信頼性のないキューを送信することを含み、信頼性のないキューの各パケットが、信頼性のないパケットシーケンス番号を含む。その送信は、順方向誤り訂正を伴う信頼性のないキューを送信することを含み、順方向誤り訂正を伴う信頼性のないキューのパケットが、失われたパケットを回復するための重複情報を含む変換コードを含む。傍受されたグラフィック出力は、さらに、ピクチャコーデックデータ及びパススルーデータの少なくとも１つに変換され得る。本方法は、グラフィック出力を複数の領域に分割することを含む。本方法は、各領域に関連するグラフィック出力を変換することを含む。グラフィック出力は、フルモーションビデオを含んでもよく、フルモーションビデオは、複数の領域のうちの１つに含まれる。グラフィックコマンドは、ユニバーサルインターミディアリーグラフィックコマンド言語によって表され得る。信頼性のあるキューは、グラフィックコマンドを送信するために使用され、信頼性のないキューは、ビデオコーデックデータを送信するために使用される。変換された出力を送信することは、さらに、輻輳制御に基づく送信バンド幅を制限することを含む。本方法は、傍受されたユーザ入力を受信することを含む。本方法は、処理のために実行中のアプリケーションに傍受されたユーザ入力を提供することを含む。

本発明の他の実施形態は、グラフィック出力を受信するための方法であり得る。本方法は、変換された出力を、ネットワークにわたってサーバから受信することを含み、サーバは、グラフィック出力を提供するアプリケーションを実行し、ＯＣＥエンジンモジュールが、グラフィック出力を変換された出力へと変換する。その受信は、さらに、信頼性のあるキューを受信することを含み、信頼性のあるキューのパケットが、信頼性のあるパケットのシーケンス番号を含み、信頼性のあるキューを受信することは、さらに、信頼性のあるキューパケットを受信することに応じて、サーバに確認を送信することを含む。その受信は、さらに、信頼性のないキューを受信することを含み、信頼性のないキューの各パケットが、信頼性のないパケットのシーケンス番号を含む。その受信は、さらに、順方向誤り訂正を伴う信頼性のないキューを受信することを含み、順方向誤り訂正を伴う信頼性のないキューの各パケットが、失われたパケットを回復するための重複情報を含む変換コードを含む。その受信は、さらに、信頼性のあるキュー、信頼性のないキュー、及び順方向誤り訂正を伴う信頼性のないキューを、受信された、変換された出力へとコンパイルすることを含む。本方法は、受信された、変換された出力からグラフィック出力をレンダリングすることを含む。本方法は、ユーザ入力を傍受することに応じて、傍受されたユーザ入力をクラウドエンジンモジュールに送信することを含む。ユーザ入力は、信頼性のあるキューを経由してサーバに送信され得る。その受信は、さらに、ジッタバッファによって処理することを含む。変換された出力は、グラフィックコマンド、ビデオコーデックデータ、ピクチャコーデックデータ、及びパススルーデータの少なくとも１つを含む。グラフィック出力は、複数の領域に分割され、各領域に関連するグラフィック出力は、グラフィックコマンド、ビデオコーデックデータ、ピクチャコーデック、及びパススルーデータの少なくとも１つに変換される。グラフィック出力は、フルモーションビデオを含み、フルモーションビデオは、複数の領域のうちの１つに含まれる。

この明細書において記載される特定の実施形態は、本発明の例又は実施形態を表し、限定ではなく、本来例示的なものである。上記の記載において、説明の目的のため、多くの特有の詳細が、本発明の包括的な理解を提供するために設けられる。しかしながら、本発明がこれらの特有の詳細なしで実施され得るということが当業者にとって明らかとなるであろう。

明細書中の「一実施形態」又は「実施形態」又は「いくつかの実施形態」についての参照は、実施形態に関連する特定の特徴、構造、又は特性が、本発明の少なくとも１つの実施形態に含まれるということを意味する。様々な実施形態の特徴及び態様が、他の実施形態に統合されてもよく、この明細書中に例示される実施形態は、例示され又は記載される全ての特徴又は態様なしで実施され得る。前記の例及び実施形態は、例であり、限定的なものではないということが当業者に理解されるであろう。

システム、機器及び方法が、最も実用的で効果的な実施形態であるということが現在理解されているということについて記載された一方で、その開示が、開示された実施形態に限定される必要がないということが理解されるべきである。明細書の解釈及び図面の理解において、当業者にとって明白な、それに対する全ての置換、拡張、等価物、結合、及び改良が本発明の正確な精神及び範囲内に含まれるということが意図されている。それ故、開示の範囲は、全てのそのような修正及び同様な構造を包含するように、幅広い解釈に一致させるべきである。それ故、本出願は、本発明の正確な精神及び範囲内に収まる全ての修正、置換及び等価物を含むということが意図されている。

この開示の特徴及び目的は、同様の参照符号または同様の要素を示す添付図面とともに、以下の記載を参照してより明確になるであろう。
図１は、リモートコンピューティングのための改良型転送プロトコルを提供するためのシステムの例を示す。 図２は、リモートコンピューティングのための改良型転送プロトコルを提供するためのサーバの例を示す。 図３は、リモートコンピューティングのための改良型転送プロトコルを提供するためのクライアントの例を示す。 図４は、リモートコンピューティングのための改良型転送プロトコルを提供するための、サーバにおいて実行される出力キャプチャ及びエンコーディングエンジンの例を示す。 図５は、リモートコンピューティングのための改良型転送プロトコルを提供するための、クライアントにおいて実行されるデコーディング及びレンダリングエンジンの例を示す。 図６は、改良型転送プロトコルに関する、捕捉、符号化及び送信のためのサーバによって実行される手順の例を示す。 図７は、改良型転送プロトコルに関する、受信、復号化及びレンダリングのためのクライアントによって実行される手順の例を示す。 図８は、リモートコンピューティングのための改良型転送プロトコルを提供するためのネットワークスタックの例を示す。 図９は、領域検出器モジュールを提供するためのサーバによって実行される手順の例を示す。 図１０は、単純なモーション検出器モジュールを提供するためのサーバによって実行される手順の例を示す。 図１１Ａは、第１のモーション検出の例のスクリーンショットを示す。図１１Ｂは、第２のモーション検出の例のスクリーンショットを示す。図１１Ｃは、第３のモーション検出の例のスクリーンショットを示す。 図１２は、リモートコンピューティングのための改良型転送プロトコルを提供するためのビデオエンコーダの例を示す。 図１３は、グラフィック出力の前処理のための手順の例を示す。 図１４は、プログレッシブピクチャエンコーダを提供するための手順の例を示す。 図１５Ａは、パケット構造の例を示す。パケットフォーマット１５００は、 上記のシステム内での使用のためのパケットフォーマットの一例を示す。 図１５Ｂは、チャンクフォーマットの例を示す。 図１５Ｃは、信頼性のあるチャンネル及び信頼性のないチャンネルのための チャンクフォーマットの例を示す。 図１５Ｄは、ＦＥＣチャンネルのためのチャンクフォーマットの例を示す。 図１５Ｅは、ピングチャンクフォーマットの例を示す。 図１５Ｆは、ピングレスポンスチャンクの例を示す。 図１５Ｇは、ハンドシェイクシーケンスを例示する。 図１５Ｈは、ｉｎｉｔチャンクの例を示す。 図１５Ｉは、ｉｎｉｔ＿ａｃｋチャンクの例を示す。 図１５Ｊは、ｃｏｏｋｉｅ＿ｅｃｈｏチャンクの例を示す。 図１５Ｋは、ｃｏｏｋｉｅ＿ａｃｋチャンクの例を示す。 図１５Ｌは、接続シャットダウンシーケンスの例を示す。 図１５Ｍは、シャットダウンチャンクの例を示す。 図１５Ｎは、ｓｈｕｔｄｏｗｎ＿ａｃｋチャンクの例を示す。 図１５Ｏは、ｓｈｕｔｄｏｗｎ＿ｃｏｍｐｌｅｔｅチャンクの例を示す。

Ｔ₁ ≦ｍ^k _i,j＜Ｔ₂の場合、ｃ^k _i,j＝２（モーションクラス「黄」）、

Ｔ₂ ≦ｍ^k _i,j＜Ｔ₃の場合、ｃ^k _i,j＝３（モーションクラス「赤」）、

Claims (34)

1. デジタルコンピュータネットワークにわたってクライアントと通信するサーバと、
   前記サーバによって実行可能なアプリケーションプログラムと、を備え、
   前記アプリケーションは、コンピュータ生成出力を提供し、
   前記サーバは、
   前記コンピュータ生成出力をアプリケーションプログラムから傍受し、
   前記コンピュータ生成出力を、グラフィックコマンド及びビデオコーデックデータの少なくとも１つに変換し、かつ、
   変換された前記出力を前記ネットワークにわたって送信するように構成され、
   前記クライアントは、
   グラフィック及びビデオを実行、復号化及びレンダリングし、
   送信された、変換された出力を受信することに応じて、前記グラフィック出力をレンダリングし、
   ユーザ入力を傍受し、かつ、
   傍受された前記ユーザ入力を前記ネットワークにわたって前記サーバに送信するように構成される
   システム。
2. 前記サーバはさらに、前記グラフィック出力を、ピクチャコーデックデータ及びパススルーデータの少なくとも１つに変換するように構成される請求項１に記載のシステム。
3. 前記サーバはさらに、
   前記グラフィック出力を複数の領域に分割し、
   グラフィック出力をそれぞれの領域に関して変換し、
   複数の領域の境界領域を平滑化する
   ように構成される請求項２に記載のシステム。
4. 前記グラフィック出力は、フルモーションビデオを含み、前記フルモーションビデオは、複数の領域のうちの１つに含まれる請求項３に記載のシステム。
5. 前記グラフィックコマンドは、ユニバーサルインターミディアリーグラフィックコマンド言語によって表現される請求項１に記載のシステム。
6. 前記サーバはさらに、
   前記クライアントから傍受された前記ユーザ入力を受信し、
   傍受された前記ユーザ入力を処理のために前記アプリケーションに提供する
   ように構成される請求項１に記載のシステム。
7. 前記ネットワークは信頼性がなく、前記ネットワークにわたる送信が非保証型である請求項１に記載のシステム。
8. 前記サーバはさらに、ローカライズドモーション検出ルーティン及びモーションエスティメーションルーティンの少なくとも１つを利用して、前記グラフィック出力を前記ビデオコーデックに変換するように構成されるとともに、前記グラフィック出力を、複数の領域の組に分割し、各領域の組は、同様なモーション特性を共有する請求項１に記載のシステム。
9. 前記サーバは、各領域の組についてのモーションスコアを演算するように構成され、前記モーションスコアは、モーション特性を表示する請求項８に記載のシステム。
10. 前記サーバはさらに、処理のためのグラフィック動作を伴う領域を選択することによって、変換の前に、前記グラフィック出力を前処理するように構成される請求項１に記載のシステム。
11. 前記前処理は、静的な領域を覆うように、マスクを前記グラフィック出力に重ねることをさらに含む請求項１０に記載のシステム。
12. 前記サーバはさらに、標準ベースのエンコーディングコア及び各領域に関する領域ヒストリを含む専用のエンコーディングコアの少なくとも１つとともに、前記グラフィック出力を前記ビデオコーデックに符号化するように構成される請求項１に記載のシステム。
13. 前記サーバさらには、
    ＲＧＢ画像データを受信し、
    前記ＲＧＢ画像データにおいてウェーブレット変換を実行し、
    前記変換されたデータを、ＬＬサブバンドデータを含む第１のシリーズと、ＨＬサブバンドデータ、ＬＨサブバンドデータ、及びＨＨサブバンドデータを含む第２のシリーズとに分割し、
    前記第１のシリーズを圧縮後に前記レシーバに送信し、
    前記第１のシリーズの送信の後に、前記第２のシリーズを圧縮後に前記レシーバに送信するように構成される請求項１に記載のシステム。
14. デジタルコンピュータネットワークにわたって複数のクライアントと通信するサーバと、サーバによって実行可能なアプリケーションプログラムとを備え、
    前記アプリケーションは、コンピュータ生成グラフィック出力を生成し、
    前記サーバは、
    前記コンピュータ生成グラフィック出力を前記アプリケーションプログラムから傍受し、
    傍受された前記出力を、グラフィックコマンド及びビデオコーデックデータの少なくとも１つに変換し、かつ
    変換された前記出力を前記ネットワークにわたって送信するように構成され、
    各クライアントは、
    グラフィック及びビデオを実行、復号化、及びレンダリングし、
    送信された、変換された出力を受信することに応じて、前記グラフィック出力をレンダリングし、
    ユーザ入力を傍受し、かつ
    傍受された前記ユーザ入力を前記ネットワークにわたって前記サーバに送信するように構成される
    システム。
15. 実行中のアプリケーションからグラフィック出力を傍受すること、
    傍受された前記出力を、グラフィックコマンド及びビデオコーデックデータの少なくとも１つに変換すること、及び、
    変換された前記出力をネットワークにわたってクライアントに送信すること、を備え、
    送信は、
    変換された前記出力を信頼性のあるキュー、信頼性のないキュー及び順方向誤り訂正を伴う信頼性のないキューへと構文解析すること、ここで、各キューが複数のチャンネルを有し、各チャンネルは、優先度に関連する、
    前記信頼性のあるキューを送信すること、ここで、前記信頼性のあるキューにおける各パケットが、クライアントによって認識され、かつ、信頼性のあるパケットシーケンス番号を含む、
    前記信頼性のないキューを送信すること、ここで、前記信頼性のないキューにおける各パケットが信頼性のないパケットシーケンス番号を含む、及び、
    順方向誤り訂正を伴う前記信頼性のないキューを送信すること、ここで、順方向誤り訂正を含む前記信頼性のないキューにおける各パケットが、失われたパケットを回復させるための重複情報を含む変換コードを含む、を備える
    コンピュータに実装された方法。
16. 傍受された前記出力はさらに、ピクチャコーデックデータ及びパススルーデータの少なくとも１つに変換される請求項１５に記載のコンピュータに実装された方法。
17. 前記グラフィック出力を複数の領域に分割すること、
    各領域に関連するグラフィック出力を変換すること、及び、
    複数の領域の間の境界領域を平滑化すること
    をさらに備える請求項１６に記載のコンピュータに実装された方法。
18. 前記グラフィック出力は、フルモーションビデオを含み、前記フルモーションビデオは、複数の領域のうちの１つに含まれる請求項１７に記載のコンピュータに実装された方法。
19. 前記グラフィックコマンドは、ユニバーサルインターミディアリーグラフィックコマンド言語によって表現される請求項１５に記載のコンピュータに実装された方法。
20. 前記信頼性のあるキューがグラフィックコマンドを送信するために使用され、前記信頼性のないキューがビデオコーデックデータを送信するために使用される請求項１５に記載のコンピュータに実装された方法。
21. 変換された前記出力を送信することは、輻輳制御に基づくバンド幅の送信を制限することをさらに含む請求項１５に記載のコンピュータに実装された方法。
22. 傍受されたユーザ入力を受信すること、及び、
    傍受された前記ユーザ入力を処理用の実行中のアプリケーションに提供すること、
    をさらに備える請求項１５に記載のコンピュータに実装された方法。
23. 変換された出力をネットワークにわたってサーバから受信すること、ここで、前記サーバは、グラフィック出力を提供し、かつ、前記グラフィック出力を変換された前記出力へと変換するアプリケーションを実行する、を備え、
    前記受信は、
    信頼性のあるキューを受信すること、ここで、前記信頼性のあるキューにおける各パケットが、信頼性のあるパケットシーケンス番号を含み、前記信頼性のあるキューを受信することは、信頼性のあるパケットキューを受信することに応じて、サーバに確認を送信することをさらに含む、
    信頼性のないキューを受信すること、ここで、前記信頼性のないキューにおける各パケットは、信頼性のないパケットシーケンス番号を含む、
    順方向誤り訂正を伴う信頼性のないキューを受信すること、ここで、順方向誤り訂正を伴う前記信頼性のないキューは、失われたパケットを回復させるための重複情報を含む変換コードを含む、及び、
    前記信頼性のあるキュー、信頼性のないキュー、及び順方向誤り訂正を伴う信頼性のないキューを、受信され、変換された前記出力にコンパイルすること、を備え、
    受信され、変換された前記出力からグラフィック出力をレンダリングすること、及び、
    ユーザ入力の傍受に応じて、傍受された前記ユーザ入力を前記サーバに送信すること、
    を備えるコンピュータに実装された方法。
24. 前記ユーザ入力が、前記信頼性のあるキューを経由して前記サーバに送信される請求項２３に記載のコンピュータに実装された方法。
25. 前記受信は、ジッタバッファによって処理することをさらに含む請求項２３に記載のコンピュータに実装された方法。
26. 各キューが複数のチャンネルに関係し、各チャンネルが、ジッタバッファとともに入力データを処理する請求項２３に記載のコンピュータに実装された方法。
27. 変換された前記出力は、グラフィックコマンド、ビデオコーデックデータ、ピクチャコーデックデータ及びパススルーデータの少なくとも１つを含む請求項２３に記載のコンピュータに実装された方法。
28. 前記グラフィック出力が複数の領域に分割され、各領域に関連する前記グラフィック出力が、グラフィックコマンド、ビデオコーデックデータ、ピクチャコーデックデータ、及びパススルーデータの少なくとも１つに変換される請求項２７に記載の方法。
29. 前記グラフィック出力は、フルモーションビデオを含み、前記フルモーションビデオは、複数の領域のうちの１つに含まれる請求項２８に記載の方法。
30. デジタルネットワークにわたってクライアントと通信するサーバと、
    前記サーバによって実行可能なアプリケーションプログラムとを備え、
    前記アプリケーションプログラムは、コンピュータ生成グラフィック出力を生成し、
    前記サーバは、
    前記コンピュータ生成グラフィック出力を前記アプリケーションから傍受し、
    前記コンピュータ生成出力を複数のデータストリームに変換し、かつ、
    変換された前記出力をネットワークにわたって送信するように構成され、
    前記クライアントは、
    グラフィック及びビデオを復号化及びレンダリングし、
    送信された、変換された前記出力を受信することに応じて、前記コンピュータ生成出力をレンダリングし、
    ユーザ入力を傍受し、かつ、
    傍受された前記ユーザ入力を前記サーバに送信するように構成される
    システム。
31. 前記ネットワークは、ＵＤＰプロトコル上で動作する請求項３０に記載のシステム。
32. 前記サーバはさらに、遅延性を最小化し、利用可能なバンド幅の最適な使用のための輻輳制御モジュールを実行するように構成される請求項３０に記載のシステム。
33. 前記サーバはさらに、現在のネットワークの混雑レベルに応じてＦＥＣパラメータを調整するためのネットワークフィードバックユニットを実行するように構成される請求項３０に記載のシステム。
34. 前記サーバは、インタセプタモジュールとともにコンピュータ生成出力を傍受し、前記コンピュータ生成出力は、オーディオ信号、コンピュータデータ、ＵＳＢインターフェース信号及びプリントスプールの少なくとも１つである請求項３０に記載のシステム。

Images