JP6329484B2 - 多数のサーバーからクライアントへの単一エンド・ユーザー体験の配信 - Google Patents

Description

[0001] リモート計算システムでは、ユーザーが、このリモート計算システムによってホストされるリソースにアクセスすることができる場合がある。このリモート計算システム上のサーバーは、プログラムを実行し、ユーザー・インターフェースを示す信号をクライアントに送信することができる。クライアントは、ＴＣＰ／ＩＰ、ＵＤＰ、または他のプロトコルというような通信プロトコルに準拠したネットワークを通じて、信号を送ることによって接続することができる。接続する各クライアントには、仮想デスクトップまたはセッション、即ち、１組のリソースを含む実行環境を提供されるのでもよい。各クライアントは、ユーザー入力を示す信号をサーバーに送信することができ、サーバーはユーザー入力をしかるべきセッションに適用することができる。クライアントは、サーバー・リソースに接続するためには、リモート・デスクトップ・プロトコル（ＲＤＰ）のようなプロトコルを用いてもよい。

[0002] ネットワーク帯域幅の可用性拡大、ならびに豊富な２Ｄおよび３Ｄクライアント・グラフィクス・アプリケーションに対する要望増大のため、リモート計算システム・アーキテクチャーにおいてシフトが生じつつある。純粋にローカルな計算パワーだけに頼る代わりに、サーバーがグラフィクス仮想化プラットフォームを組み込み、これらのプラットフォームが、グラフィクス処理インテリジェンスを、データー・センタに配備され(deploy)ホストされた仮想デスクトップ・インフラストラクチャ（ＶＤＩ）にシフトする。クライアントは、共有グラフィクス処理ユニット（ＧＰＵ）およびＶＤＩ上にインストールされたプロセッサーのグラフィクス処理パワーを利用して、仮想デスクトップを最大の忠実度で体験する。グラフィクス仮想化プラットフォームの一例に、Microsoft（登録商標）RemoteFX（登録商標）がある。これは、Hyper-V（登録商標）ＶＤＩアーキテクチャー上に構築し、ホストされたＶＤＩデスクトップのために設計された新たなペイロードを配信するためにＲＤＰを統合する。

[0003] 典型的なＶＤＩアーキテクチャーは、ホスト・パーティションと、多数のゲスト・パーティションまたは仮想機械とを含むことができる。ホスト・パーティションは、ＧＰＵ、中央処理ユニット（ＣＰＵ）、およびメモリー空間というような、ＶＤＩの基礎的な物理リソースにアクセスし、仮想機械のこれらのリソースに対するアクセスを割り当てそして管理することができる。各仮想機械は、割り当てられた物理リソースの仮想化である、１組の仮想リソースを有する。

[0004] このため、リモート計算システムでは、クライアントは、仮想機械またはその中で実行する仮想デスクトップ・セッションに接続することができ、このセッションにおいてこのクライアントの認証が管理される。ユーザー入力データーまたはグラフィクス・データーのような、クライアントから仮想機械に送信すべきデーターは、最初にホスト・パーティション上のネットワーク・インターフェース・カード（ＮＩＣ）に送信され、次いで仮想機械に導き直される。仮想機械は、その仮想リソースを用いてデーターを処理することができる。仮想機械は、処理したデーターを、基礎的な物理リソース上での更なる処理のために、ホスト・パーティションに送る。ホスト・パーティションは、更に、このデーターを処理し、クライアントとの認証のために仮想機械に返送する。仮想機械は、このデーターをホスト・パーティションＮＩＣを通じてクライアントに送信するために、パッケージ化し再度ホスト・パーティションに導き直す。ホスト・パーティションと仮想機械との間におけるデーターの反復横断は、集中的な動作を必要とする可能性があり、大量のメモリーおよびＣＰＵリソースを消費する可能性があり、クライアントに対するデーター配信レイテンシが増大する可能性がある。

[0005] リモート計算システム環境においてクライアントから受信される、グラフィクス・データーのような、データーの処理を最適化するためのシステム、方法、およびコンピューター読み取り可能媒体について開示する。現在のアーキテクチャーと比較すると、このような最適化は、ホストされるメモリーおよびＣＰＵリソースの使用削減、およびクライアントに対するデーター配信レイテンシの短縮を含む。

[0006] 一実施形態では、クライアントは、計算サーバーのような他の計算デバイスとの第１接続を開始して、仮想デスクトップまたはその中におけるセッションにおいてクライアント作業負荷を実行することができる。計算サーバーは、第１接続を認証することができ、クライアント・アドレスを取得することができる。計算サーバーは、次に、グラフィクス・サーバーとの接続をネゴシエートすることができ、グラフィクス・サーバーを初期化して、クライアント・アドレスから始まる接続を予期する(expect)ようにグラフィクス・サーバーに命令する。また、計算サーバーはグラフィクス・サーバーからグラフィクス・サーバー・アドレスも取得することができる。計算サーバーは、このグラフィクス・サーバー・アドレスをクライアントに供給することができる。一方、クライアントは、このグラフィクス・サーバー・アドレスを用いて、グラフィクス・サーバーとの第３接続を確立することができる。一旦これらの接続が確立されたなら、クライアントは、キーボード入力、マウス入力等のようなユーザーの画面入力を計算サーバーに、第１接続を通じて、供給することができる。計算サーバーは、供給された入力を処理し、表示コマンドやコールのような、処理データーを出力することができる。計算サーバーは、処理したデーターを、処理のためにグラフィクス・サーバーに送ることができる。次いで、グラフィクス・サーバーは、受信したデーターを処理し、グラフィクス出力データーをクライアントに送ることができる。したがって、グラフィクス・サーバーがグラフィクス出力データーを計算サーバーに返送する必要はない。同様に、計算サーバーがグラフィクス出力データーをクライアントに送る必要もない。

[0007] 計算サーバーは、仮想化計算システム上にホストされるゲスト・パーティションまたは仮想機械であることができ、一方グラフィクス・サーバーは仮想化計算システム上のホスト・パーティションであることができる。第１接続は、例えば、ＴＣＰ／ＩＰ、ＵＤＰ、または他のネットワーク・ベース通信のいずれでも可能であり、リモート・デスクトップ・セッション接続を含むことができる。第２接続は、例えば、ＶＭＢｕｓ、ハイパーバイザー（仮想機械モニターとしても知られる）を介した通信、ＴＣＰ／ＩＰ、ＵＤＰ、または他のネットワーク・ベース接続のいずれかというような、イントラ・パーティション通信チャネルを含むことができる。第３接続は、例えば、ＴＣＰ／ＩＰ、ＵＤＰ、ＦＣＯＥ、１００ＧＢイーサネット(登録商標)、またはネットワーク・ベース接続のいずれかとすることができる。

[0008] 一実施形態では、複数のクライアントを同時に複数の計算サーバーにそして複数のグラフィクス・サーバーに接続することができる。複数のクライアントの内１つのクライアントとの接続を確立し、このクライアントを認証する最初のステップにおいて、クライアントを複数の計算サーバーの内第１計算サーバーに接続するために、リディレクターおよび／またはブローカーを用いることができる。リディレクターおよび／またはブローカーは、複数の計算サーバーの可用性を判断し、それに応じてクライアントと第１計算サーバーとの間の接続を割り当てることができる。したがって、計算リソースの負荷均衡の場合、仮想機械ライブ・マイグレーションのような技法は継ぎ目なく作業負荷を第１計算サーバーから第２計算サーバーに移転することができる。第２計算サーバーへのクライアント接続は、再確立することができ、一方クライアントと複数のグラフィクス・サーバーの内１つのグラフィクス・サーバーとの間の接続は、同じままであり続けることができる。同様に、グラフィクス・サーバー・マネージャーは、クライアントが接続された計算サーバーを、複数のグラフィクス・サーバーの内１つのグラフィクス・サーバーに接続するために用いることができる。グラフィクス・サーバー・マネージャーは、複数のグラフィクス・サーバーの可用性を判断し、これに応じてクライアントが接続された計算サーバーと第１グラフィクス・サーバーとの間の接続を割り当てることができる。したがって、グラフィクス・サーバーの負荷均衡の場合、クライアントが接続された計算サーバーは、第２グラフィクス・サーバーとの新たな接続を形成することができ、第２グラフィクス・サーバーとの新たな接続を確立するようにクライアントに要求することができる。次いで、クライアントは第２グラフィクス・サーバーに継ぎ目無しに移行することができる。

[0009] 複数のクライアントが同時に複数の計算サーバーおよび複数のグラフィクス・サーバーに接続される実施形態では、少なくとも１つのクライアントが、複数のグラフィクス・サーバーからの、レンダリングされ、キャプチャされ、圧縮されたデーターを受信するように構成することができる。したがって、少なくとも１つのクライアントを通じてインターフェースするユーザーは、１つ以上のクライアントから発する、レンダリングされ、キャプチャされ、圧縮されたデーターを見ることができる。同様に、少なくとも１つのグラフィクス・サーバーは、複数のクライアントから発する、レンダリングされ、キャプチャされ、圧縮された処理データーをクライアントに送信するように構成することができる。

[0010] この摘要は、本発明の態様の全体像を規定することを意図している。これは、本発明のあらゆる必要なステップまたはコンポーネントを特定することを意図しているのではない。以上のことに加えて、他の態様も特許請求の範囲、図面、および本開示の一部をなす本文において記載される。尚、本開示の１つ以上の種々の態様が、ここで引用した本開示の態様を実施するための回路および／またはプログラミングを含むのでもよいがこれらには限定されないこと、その回路および／またはプログラミングは、システム設計者の設計選択に応じて、ここで引用した態様を実施するように構成されるハードウェア、ソフトウェア、および／またはファームウェアの事実上あらゆる組み合わせであることができることは、当業者には認めることができよう。

[0011] 本明細書にしたがってリモート計算環境において受信された、グラフィクス・データーのようなデーターの処理を最適化するためのシステム、方法、およびコンピューター媒体について、添付図面を参照しながら更に説明する。
図１は、本開示の態様を実現することができる計算環境の一例を示す。 図２は、本開示の態様を実施するためのリモート計算環境を示す。 図３は、本開示の態様を実施するために、複数のクライアントが複数のリモート・サーバーに接続することができるリモート環境を示す。 図４は、複数の仮想機械を有する仮想機械環境の一例を示す。 図５は、複数の仮想機械を有する仮想機械環境の他の例を示す。 図６は、本開示の態様を実施するために複数の仮想デスクトップ・セッションをホストするリモート・サーバーを示す。 図７は、本開示の態様を実施するための計算サーバーおよびグラフィック・サーバーのアーキテクチャー例を示す。 図８は、本開示の態様を実施するための計算サーバーおよびグラフィクス・サーバーの他のアーキテクチャー例を示す。 図９は、本開示の態様を実施するための計算サーバーおよび複数のグラフィクス・サーバーの例を示す。 図１０は、本開示の態様を実施するための仮想環境において実装される(effectuate)計算サーバーおよびグラフィクス・サーバーの例を示す。 図１１は、本開示の態様を実施するための、クライアント、計算サーバー、およびグラフィクス・サーバーを有する計算環境を示す。 図１２は、本開示の態様を実施するための、複数のクライアント、計算サーバー、およびグラフィクス・サーバーを有する計算環境を示す。 図１３は、本開示の態様を実施するための方法の一例を表すフロー・チャートを示す。 図１４は、本開示の態様を実施するためのシステムおよびコンピューター読み取り可能記憶媒体の例を示す。

[0026] 本開示の種々の実施形態の完全な理解が得られるようにするために、以下の説明および図においてある程度具体的な詳細を明記する。計算およびソフトウェア技術に関連することが多いある種の周知の詳細については、本開示の種々の実施形態を不要に曖昧にするのを避けるために、以下の開示では明記しないこととする。更に、当業者は、以下に説明する詳細の内１つ以上がなくても、本開示の他の実施形態を実施できることが理解されよう。最後に、以下の開示ではステップおよびシーケンスを参照して種々の方法について説明するが、このような説明は、本開示の実施形態の明確な実施態様を提示するためであり、これらのステップおよびステップのシーケンスが本開示を実施するためには必須であると解釈してはならない。

[0027] 尚、本明細書において説明する種々の技法は、ハードウェアまたはソフトウェア、あるいはしかるべきときには、双方の組み合わせで実現できることは言うまでもない。つまり、本開示の方法および装置、またはその一部のある種の態様は、フロッピー(登録商標)・ディスケット、ＣＤ−ＲＯＭ、ハード・ドライブ、または他のあらゆる機械読み取り可能記憶媒体というような、有形媒体に具体化されたプログラム・コード（即ち、命令）の形態をなすことができ、プログラム・コードがコンピューターのような機械にロードされこの機械によって実行されると、この機械が本開示を実施する装置になる。プログラマブル・コンピューター上におけるプログラム・コード実行の場合、計算デバイスは、通常、プロセッサー、このプロセッサーによって読み取り可能な記憶媒体（揮発性および不揮発性メモリーおよび／または記憶エレメントを含む）、少なくとも１つの入力デバイス、および少なくとも１つの出力デバイスを含む。例えば、アプリケーション・プログラミング・インターフェース（ＡＰＩ）、再利用可能な制御手段等の使用によって、１つ以上のプログラムが、本開示に関して説明されるプロセスを実現するまたは利用することもできる。このようなプログラムは、コンピューター・システムと通信するために、高級手順プログラミング言語またはオブジェクト指向プログラミング言語で実現されることが好ましい。しかしながら、プログラム（１つまたは複数）は、所望であれば、アセンブリーまたは機械語で実現することもできる。いずれの場合でも、言語は、コンパイル型言語でもインタプリタ型言語でもよく、ハードウェアの実施形態と組み合わせてもよい。

[0028] 本開示全体を通じて用いられる回路(circuitry)という用語は、ハードウェア割り込みコントローラ、ハード・ドライブ、ネットワーク・アダプター、グラフィクス・プロセッサー、ハードウェア・ベース・ビデオ／オーディオ・コデックというようなハードウェア・コンポーネント、およびこのようなハードウェアを動作させるために用いられるファームウェア／ソフトウェアを含むことができる。また、回路という用語は、ファームウェアによってまたはある種の方法で設定されるスイッチによって機能（１つまたは複数）を実行するように構成されたマイクロプロセッサー、または１つ以上の論理プロセッサー、例えば、マルチコア汎用処理ユニットの１つ以上のコアも含むことができる。この例における論理プロセッサー（１つまたは複数）は、機能（１つまたは複数）を実行するように動作可能なロジックを具体化するソフトウェア命令によって構成することができる。このソフトウェア命令は、メモリー、例えば、ＲＡＭ、ＲＯＭ、ファームウェア、および／または仮想メモリーからロードされる。回路がハードウェアおよびソフトウェアの組み合わせを含む実施形態例では、実施者(implementer)がロジックを具体化するソース・コードを書くのでもよく、続いて、このソース・コードが機械読み取り可能コードにコンパイルされ、論理プロセッサーによって機械読み取り可能コードを実行することができる。技術的現状はハードウェア、ソフトウェア、またはハードウェア／ソフトウェアの組み合わせの間の差が殆どなくなるところまで発展したことは当業者は認めることができるはずであるので、機能を実装するためのハードウェアかソフトウェアかの選択は、単なる設計の選択事項に過ぎない。つまり、ソフトウェア・プロセスを等価のハードウェア構造に変換でき、ハードウェア構造自体を等価なソフトウェア・プロセスに変換できることは当業者は認めることができるので、ハードウェアの実施態様かまたはソフトウェアの実施態様かの選択は、実施者に委ねられる。

[0029] 本発明の実施形態は、１つ以上のコンピューター上で実行することができる。図１および以下に続く論述は、本開示を実現することができる適した計算環境について端的で総合的な説明を行うことを意図している。当業者は、コンピューター・システムが本明細書において以下で説明するコンポーネントの一部または全部を有することができることを認めることができよう。

[0030] 図１は、本開示の態様と共に作用するように構成された計算システムの一例を示す。この計算システムは、コンピューター１００等を含むことができ、コンピューター１００は、論理処理ユニット１０２、システム・メモリー２２、およびシステム・バス２３を含む。システム・バス２３は、システム・メモリーから論理処理ユニット１０２までを含む種々のシステム・コンポーネントを結合する。システム・バス２３は、メモリー・バスまたはメモリー・コントローラ、周辺バス、および種々のバス・アーキテクチャーの内いずれかを用いるローカル・バスを含む、様々なタイプのバス構造の内いずれでもよい。システム・メモリーは、リード・オンリー・メモリー（ＲＯＭ）２４およびランダム・アクセス・メモリー（ＲＡＭ）１０４を含む。基本入力／出力システム２６（ＢＩＯＳ）は、起動中のように、コンピューター１００内部のエレメント間で情報を転送するのを助ける基本的なルーチンを収容し、ＲＯＭ２４に格納される。コンピューター１００は、更に、図示しないハード・ディスクに対する読み取りおよび書き込みを行うハード・ディスク・ドライブ２７、リムーバブル磁気ディスク１１８に対する読み取りおよび書き込みを行う磁気ディスク・ドライブ２８、およびＣＤ ＲＯＭまたは他の光媒体のようなリムーバブル光ディスク３１に対する読み取りおよび書き込みを行う光ディスク・ドライブ３０も含むとよい。実施形態例では、本開示の態様を具体化するコンピューター実行可能命令は、ＲＯＭ２４、ハード・ディスク（図示せず）、ＲＡＭ１０４、リムーバブル磁気ディスク１１８、光ディスク３１、および／または論理処理ユニット１０２のキャッシュに格納してもよい。ハード・ディスク・ドライブ２７、磁気ディスク・ドライブ２８、および光ディスク・ドライブ３０は、システム・バス２３に、それぞれハード・ディスク・ドライブ・インターフェース３２、磁気ディクス・ドライブ・インターフェース３３、および光ドライブ・インターフェース３４を介して接続される。ドライブおよびそれらに付随するコンピューター読み取り可能媒体は、コンピューター１００のためのコンピューター読み取り可能命令、データー構造、プログラム・モジュール、およびその他のデーターの不揮発性ストレージを設ける。本明細書において説明する環境はハード・ディスク、リムーバブル磁気ディスク１１８、およびリムーバブル光ディスク３１を採用するが、磁気カセット、フラッシュ・メモリー・カード、ディジタル・ビデオ・ディスク、ベルヌーイ・カートリッジ、ランダム・アクセス・メモリー（ＲＡＭ）、リード・オンリー・メモリー（ＲＯＭ）等のような、コンピューターによってアクセス可能なデーターを格納することができる他のタイプのコンピューター読み取り可能媒体もこの動作環境において使用してもよいことは、当業者には認められてしかるべきである。

[0031] オペレーティング・システム３５、１つ以上のアプリケーション・プログラム３６、他のプログラム・モジュール３７、およびプログラム・データー３８を含む多数のプログラム・モジュールを、ハード・ディスク、磁気ディスク１１８、光ディスク３１、ＲＯＭ２４、またはＲＡＭ１０４に格納することができる。ユーザーは、キーボード４０およびポインティング・デバイス４２のような入力デバイスを介して、コマンドおよび情報をコンピューター１００に入力することができる。他の入力デバイス（図示せず）は、マイクロフォン、ジョイスティック、ゲーム・パッド、衛星ディスク、スキャナー等を含むことができる。これらおよびその他の入力デバイスは、多くの場合、システム・バスに結合されたシリアル・ポート・インターフェース４６を介して、論理処理ユニット１０２に接続されるが、パラレル・ポート、ゲーム・ポート、またはユニバーサル・シリアル・バス（ＵＳＢ）のような他のインターフェースによって接続されてもよい。ディスプレイ４７または他のタイプのディスプレイ・デバイスも、ＧＰＵ／ビデオ・アダプター１１２のようなインターフェースを介して、システム・バス２３に接続することができる。ディスプレイ４７に加えて、コンピューターは、通例、スピーカーおよびプリンターのような、他の周辺出力デバイス（図示せず）も含む。また、図１のシステムは、ホスト・アダプター５５、小型コンピューター・システム・インターフェース（ＳＣＳＩ）バス５６、およびＳＣＳＩバス５６に接続された外部記憶デバイス６２も含む。

[0032] コンピューター１００は、リモート・コンピューター４９のような、１つ以上のリモート・コンピューターへの論理接続を用いて、ネットワーク接続環境において動作することもできる。リモート・コンピューター４９は、他のコンピューター、サーバー、ルーター、ネットワークＰＣ、ピア・デバイスまたは他の一般的なネットワーク・ノード、仮想機械であってもよく、通例、コンピューター１００に関して以上で説明したエレメントの多くまたは全部を含むことができるが、図１には、メモリー記憶デバイス５０だけが示されている。図１に示す論理接続は、ローカル・エリア・ネットワーク（ＬＡＮ）５１およびネットワーク５２を含むことができ、ネットワーク５２は、一例として、ワイド・エリア・ネットワーク（ＷＡＮ）である。このようなネットワーク接続環境は、事務所、企業規模のコンピューター・ネットワーク、イントラネット、およびインターネットでは極普通である。

[0033] ＬＡＮネットワーク接続環境において用いられる場合、コンピューター１００は、ネットワーク・インターフェース・コントローラ（ＮＩＣ）１１４またはアダプターを介してＬＡＮ５１に接続することができる。ＷＡＮネットワーク接続環境において用いられる場合、コンピューター１００は、通例、モデム５４、またはインターネットのようなネットワーク５２を通じて通信を確立する他の手段を含むことができる。モデム５４は、内蔵型でも外付け型でもよく、シリアル・ポート・インターフェース４６を介してシステム・バス２３に接続することができる。ネットワーク接続環境では、コンピューター１００に関して図示したプログラム・モジュールまたはその一部が、リモート・メモリー記憶デバイスに格納されてもよい。尚、図示するネットワーク接続は例であり、コンピューター間で通信リンクを確立する他の手段を用いてもよいことは認められよう。更に、本開示の多数の実施形態がコンピューター・システムには特に非常に適していると考えられるが、本文書において、本開示をこのような実施形態に限定することを意図するものは何もない。

[0034] 場合によっては、ユーザーが計算アプリケーション、即ち、別の計算デバイス上で実行しているアプリケーションに、リモートにアクセスすることを望むこともある。一実施態様では、仮想デスクトップのようなリモート・デスクトップを介してこのようなアクセスをユーザーに付与する。リモート・デスクトップ・システムの実施形態は、１つ以上のコンピューターを実行することができ、または図１のコンピューター１００に関して説明したコンポーネントの一部または全部を有することもできる。リモート・デスクトップ・システムは、クライアント・コンピューター・システムによってリモートに実行し表示することができるアプリケーションを維持するコンピューター・システムである。図２は、リモート・デスクトップ・システム２００のアーキテクチャー例を示す。リモート・デスクトップ・システム２００は、リモート・クライアント・コンピューター２１０とリモート・サーバー・コンピューター２２０とを含むことができる。リモート・クライアント・コンピューター２１０およびリモート・サーバー・コンピューター２２０は、仮想デスクトップ・セッションのようなリモート・セッションを互いに実行するように構成される。

[0035] 図示のように、リモート・サーバー・コンピューター２２０は、リモート・セッションをリモート・クライアント・コンピューター２１０に配給し(serve)、この場合、リモート・サーバー・コンピューター２２０が、リモート・クライアント・セッション２２２を実行するユーザーからのクライアント・グラフィック出力を送る。リモート・ユーザー入力は、リモート・クライアント・コンピューター２１０において入力される。入力マネージャー２１２が、リモート・ユーザー入力を処理し、ネットワークを通じて（例えばリモート・デスクトップ・プロトコル（ＲＤＰ）のような、国際電気通信連合（ＩＴＵ）Ｔ．１２０ファミリーのプロトコルに基づくプロトコルを用いる）リモート・サーバー・コンピューター２２０上のリモート・ユーザー・アプリケーション２２４に転送することができる。ネットワークは、ローカル・エリア・ネットワーク、ワイド・エリア・ネットワーク、ケーブル・ネットワーク、インターネット、ワールド・ワイド・ウェブ、または企業内ネットワーク(corporate enterprise network)のような、いずれのタイプの通信ネットワークでもよい。リモート・ユーザー・アプリケーション２２４は、リモート・サーバー・コンピューター２２０上にホストされたリモート・クライアント・セッション２２２において実行することができる。リモート・ユーザー・アプリケーション２２４は、入力がリモート・サーバー・コンピューター２２０において入力されたかのように、この入力を処理する。リモート・ユーザー・アプリケーション２２４は、受信した入力に応答して、リモート・サーバー出力を生成し、この出力はネットワークを通じてリモート・クライアント・コンピューター２１０に転送される。リモート・クライアント・コンピューター２１０は、この出力データーをリモート・ユーザーに提示する。このように、リモート・クライアント・コンピューター２１０において入力が受信され出力が提示されるが、処理は実際にはリモート・サーバー・コンピューター２２０において行われる。

[0036] リモート・ユーザー・アプリケーション２２４に加えて、リモート・クライアント・セッション２２２は、シェルおよびデスクトップのようなユーザー・インターフェース、このデスクトップ内部におけるマウスの動きを追跡するサブシステム、アイコン上のマウス・クリックを、プログラムのインスタンスを実装するコマンドに変換するサブシステム、他のアプリケーション等を含むことができる。尚、以上の論述は例示であり、本明細書において開示する主題は、種々のクライアント／サーバー環境において実現することができ、特定のリモート・プレゼンテーション生産物(remote presentation product)には限定されないことは言うまでもない。

[0037] 全てではないにしても、殆どのリモート・デスクトップ環境において、リモート・ユーザーの入力データー（リモート・クライアント・コンピューター２１０において入力される）は、通例、アプリケーションに対するコマンドを表すマウスおよびキーボード・データーを含む。出力データー（リモート・サーバー・コンピューター２２０においてリモート・ユーザー・アプリケーションによって生成される）は、通例、リモート・クライアント・コンピューター２１０における表示のためのグラフィクス・データーを含む。また、多くのリモート・デスクトップ環境は、他のタイプのデーターを転送するために拡張する機能も含む。一実施形態例では、ユーザー・アプリケーション２２４から出力されたグラフィック・データーを、リモート・サーバー・コンピューター２２０上にホストされたグラフィクス・マネージャー２２６に送ることができる。グラフィクス・マネージャー２２６は、グラフィクス・データーをレンダリングし、キャプチャし、圧縮し、ネットワークを通じてリモート・クライアント・コンピューター２１０上のリモート・ユーザー・ディスプレイ２１４に転送することができる。リモート・ユーザー・ディスプレイ２１４は、このグラフィクス出力データーをリモート・ユーザーに表示することができる。

[0038] リモート・デスクトップ環境の一実施形態では、リモート・サーバー・コンピューターが複数のリモート・クライアント・コンピューターのために複数のリモート・セッション（または仮想デスクトップ）を実行することもできる。したがって、複数のリモート・クライアント・コンピューターに対するセッションの割り当てを制御するために、ブローカーを用いることもできる。加えて、リモート・デスクトップ環境では、特定のリモート・クライアント・コンピューターを配給することができる、複数のリモート・サーバー・コンピューターがあることもある。したがって、特定のリモート・クライアント・コンピューターを配給するリモート・サーバー・コンピューターの割り当てを制御するために、リディレクターを用いることもできる。図３は、このようなリモート・デスクトップ・システム３００の実施形態例を示す。

[0039] 複数のリモート・クライアント・コンピューター３１０（Ａ〜Ｎ）は、図２のリモート・クライアント・コンピューター２１０のように、ネットワークを通じてリモート・サーバー・システム３５０と通信することができる計算デバイスであればいずれでもよい。リモート・サーバー・システム３５０は、リディレクター３３０、ブローカー３４０、および複数のリモート・サーバー・コンピューター３２０（Ａ〜Ｎ）を含むことができる。リディレクター３３０およびブローカー３４０は、本明細書において以下で説明するようなデバイスのそれぞれの機能を実現するように構成された、プロセッサーおよびメモリーを含む計算デバイスであってもよい。リモート・サーバー・コンピューター３２０（Ａ〜Ｎ）は、図２のコンピューター１００および図２のリモート・サーバー・コンピューター２２０に関して説明したコンポーネントの一部を有してもまたは全部を有してもよい。リモート・サーバー・コンピューター３２０（Ａ〜Ｎ）は、仮想機械として実現されてもよい。仮想機械は、１つのハードウェア・インフラストラクチャ上または別々のハードウェア・インフラストラクチャ上で実行することができる。ブローカー３４０は、ゲートウェイ（図示せず）を用いてリディレクター３３０に接続された単体デバイスであってもよく、リディレクター３３０内部に配置されてもよく、またはリモート・サーバー・コンピューター３２０（Ａ〜Ｎ）内に配置されてもよい。また、リディレクター３３０もリモート・サーバー３２０（Ａ〜Ｎ）に配置されてもよい。

[0040] ブローカー３４０は、当該ブローカー３４０に格納されているセッション状態情報に基づいて、セッションをリモート・クライアント・コンピューターに割り当てる。セッション状態情報は、例えば、セッションＩＤ、ユーザー名、セッションが存在しているリモート・サーバー・コンピューターの名前、各リモート・サーバー・コンピューター内にあるアクティブ・セッションの数等を含んでもよい。本明細書において用いる場合、セッションとは仮想デスクトップ・セッション（仮想機械セッションとしても知られる）であってよい。

[0041] リモート・クライアント・コンピューター３１０は、最初に、リモート・クライアント・コンピューター３１０（Ａ〜Ｎ）の負荷均衡に備えることができるリディレクター３３０に接続する。このような場合、リディレクター３３０は通例最初に接続要求を受ける。次いで、リディレクター３３０はこの接続要求を受け入れ、リモート・クライアント・コンピューター３１０をどこにリディレクトするか決定するように、ブローカー３４０に問い合わせる。ブローカー３４０は、その特定の環境のセッション状態情報を分析し、リモート・クライアント・コンピューター３１０をリディレクトすることができるリモート・サーバー・コンピューター３２０を特定する。特定されたリモート・サーバー・コンピューター３２０は、リモート・クライアント・コンピューター３１０によって以前にアクセスされたが後に切断され、リモート・クライアント・コンピューター３１０を再接続することができるセッションを保有するのでもよい。一実施形態では、リモート・クライアント・コンピューター３１０が他に既存のセッションを全く保有していないことを条件に、特定されたリモート・サーバー・コンピューター３２０が、リモート・クライアント・コンピューター３１０を接続することができる新たなセッションを提供することもできる。

[0042] ブローカー３４０は、要求されたリモート・サーバー・コンピューター３２０に情報を送り、このリモート・クライアント・コンピューター３２０が、特定されたリモート・サーバー・コンピューター３１０との接続を確立することを可能にする。例えば、この情報は、機械ＩＤ、セッションＩＤ、および特定されたリモート・サーバー・コンピューター３２０の位置を含んでもよい。一旦リモート・クライアント・コンピューター３１０が、特定されたリモート・サーバー・コンピューター３２０との接続を確立すると、リモート・クライアント・コンピューター３１０は、特定されたリモート・サーバー・コンピューター３２０内にあるアプリケーションにアクセスすることができる。これらのアプリケーションは、リモート・サーバー・システム３５０においてリモート・サーバー・コンピューター３２０を特定するときに用いられたブローカー３４０のロジックに対して適合する(compatible)とよい。

[0043] 一実施形態では、以上で説明したシステムは、例えば、リモート・クライアント・コンピューター３１０を、リモート・サーバー・コンピューター上で実行している複数の仮想デスクトップまたはセッションの内１つに接続するために用いることができる。リモート・クライアント・コンピューターは、リモート・デスクトップ・プロトコル（ＲＤＰ）パケットにおけるリディレクター・トークンを調べる。リモート・クライアント・コンピューターは、このリディレクター・トークンに含まれる情報に基づいて、多くの仮想デスクトップの内１つに接続する。

[0044] 他の実施形態では、ブローカー３４０およびプール・マネージャー（図示せず）を用いて、リモート・クライアント・コンピューター３１０を仮想デスクトップの１つに接続することができる。プール・マネージャーは、ブローカー３４０内部に配置するのでもよい。ブローカー３４０は、リモート・クライアント・コンピューター３１０が仮想機械（ＶＭ）上にホストされた仮想デスクトップに接続されているときに、仮想デスクトップをリモート・クライアント・コンピューター３１０に割り当て、プール・マネージャーは、仮想デスクトップの内どれが、割り当てるために利用可能か示す。

[0045] 更に他の実施形態では、リモート・クライアント・コンピューター３１０を仮想デスクトップに接続することができる。リモート・クライアント・コンピューター３１０は、インターネット・プロトコル（ＩＰ）アドレスを生成し、リモート・クライアント・コンピューター３１０と仮想デスクトップとの間に接続を確立するためにブローカー３４０によって用いられるネットワーク名を示す。個々の仮想デスクトップＩＰアドレスをリモート・クライアント・コンピューター３１０（Ａ〜Ｎ）から隠すことによって、最初はブローカー３４０の１つのネットワーク名のみが、外部に対してリモート・クライアント・コンピューター３１０（Ａ〜Ｎ）に露出されるだけで済む。

[0046] 図４は、複数の仮想機械を有する仮想機械環境の一例を示す。仮想化コンピューター・システム４００は、図２のリモート・サーバー・コンピューター２２０および図３のリモート・サーバー・コンピューター３２０（Ａ〜Ｎ）を実現するために用いることができる。

[0047] 図４に示すように、コンピューター・システム４００は、図１において説明したエレメントと、仮想機械を実装するように動作可能なコンポーネントとを含むことができる。このようなコンポーネントの１つに、ハイパーバイザー・マイクロカーネル(hypervisor microkernel)４０２がある。これは、当技術分野では、仮想機械モニターとも呼ばれることもある。ハイパーバイザー・マイクロカーネル４０２は、コンピューター・システム４００のハードウェアに対するアクセスを制御し調停するように構成することができる。ハイパーバイザー・マイクロカーネル４０２は、ゲスト・パーティション１からゲスト・パーティションＮまで（Ｎは１よりも大きい正の整数）のような、パーティションと呼ばれる実行環境を生成することができる。ここで、ゲスト・パーティションは、ハイパーバイザー・マイクロカーネル４０２によってサポートされる分離の基本単位である。ゲスト・パーティションは、チャイルド・パーティションと言っても分かるであろう。ハイパーバイザー・マイクロカーネル４０２は、１つのパーティションにおけるプロセスを、他のパーティションのリソースにアクセスすることから分離することができる。ハイパーバイザー・マイクロカーネル４０２の制御下にある１組のハードウェア・リソース、例えば、メモリー、デバイス、プロセッサー・サイクル等に、各ゲスト・パーティションをマッピングすることができる。実施形態では、ハイパーバイザー・マイクロカーネル４０２は、単体のソフトウェア生産物であることができ、オペレーティング・システムの一部であることができ、マザーボードのファームウェア内に埋め込むことができ、特殊集積回路であることができ、またはこれらの組み合わせとすることができる。

[0048] ハイパーバイザー・マイクロカーネル４０２は、物理コンピューター・システムにおいてメモリーのゲスト・オペレーティング・システムのビューを制限することによって、パーティション形成(partitioning)を施行することができる。ハイパーバイザー・マイクロカーネル４０２が仮想機械をインスタンス化するとき、ページ、例えば、システム物理メモリー（ＳＰＭ）の、開始アドレスおよび終了アドレスを有する固定長のメモリー・ブロックを、仮想機械にゲスト物理メモリー（ＧＰＭ）として割り当てることができる。ここで、ゲストの制限されたシステム・メモリーのビューは、ハイパーバイザー・マイクロカーネル４０２によって制御される。ゲスト物理メモリーという用語は、仮想機械の観点からメモリーのページを記述する省略表現(shorthand way)であり、システム物理メモリーという用語は、物理システムの観点からメモリーのページを記述する省略表現である。つまり、仮想機械に割り当てられるメモリーのページは、ゲスト物理アドレス（仮想機械によって用いられるアドレス）とシステム物理アドレス（そのページの実際のアドレス）とを有することになる。

[0049] ゲスト・オペレーティング・システムが、ゲスト物理メモリーを仮想化することもできる。仮想メモリーとは、オペレーティング・システムにメモリーをオーバー・コミットさせ、連続する作業メモリーに対する１回のアクセスをアプリケーションに与えさせる管理技法である。仮想化環境では、ゲスト・オペレーティング・システムが１つ以上のページ・テーブルを用いて、仮想ゲスト・アドレスとして知られる仮想アドレスをゲスト物理アドレスに変換することができる。この例では、メモリー・アドレスがゲスト仮想アドレス、ゲスト物理アドレス、およびシステム物理アドレスを有してもよい。

[0050] 図示する例では、コンピューター・システム４００は、ホスト・パーティションを含む。ホスト・パーティションは、Ｘｅｎのオープン・ソース・ハイパーバイザーのドメイン０と同様であると考えることができる。また、ホスト・パーティションは、ペアレント・パーティションまたはルート・パーティションと呼ぶこともできる。図示のように、ホスト・パーティションはホスト４０４を含むことができる。ホスト４０４は、アプリケーションのコンピューター・システム４００の基礎物理ハードウェアとの相互作用を可能にするデバイス・ドライバー４２４を含むことができる。したがって、ホスト４０４は、論理処理ユニット１０２、ＧＰＵ１１２、およびＮＩＣ１１４のような、コンピューター・システム４００の物理ハードウェアにアクセスすることができる。ホスト４０４は、オペレーティング・システム（または１組の構成ユーティリティ）であることができる。

[0051] ホスト４０４は、仮想化サービス・プロバイダー４２８（ＶＳＰ）を用いることによって、ゲスト・パーティション１〜Ｎにおいて実行するゲスト・オペレーティング・システムにリソースを供給するように構成することができる。ＶＳＰ４２８は、通例、オープン・ソース・コミュニティにおけるバックエンド・ドライバーと呼ばれ、仮想化サービス・クライアント（ＶＳＣ）（通例、オープン・ソース・コミュニティまたは準仮想化デバイスにおいてフロントエンド・ドライバーと呼ばれる）によって、インターフェースをハードウェア・リソースに多重化するために用いることができる。図４に示すように、仮想化サービス・クライアントは、ゲスト・オペレーティング・システムのコンテキストの範囲内で実行する。しかしながら、これらのドライバーはゲストにおける残りのドライバーとは異なり、これらのドライバーにはゲストではなくハイパーバイザーが供給されてもよい。一実施形態例では、仮想化サービス・プロバイダー４２８がＶＳＣ４１６および４１８と通信するために用いられるパスは、仮想化パスであると考えることができる。

[0052] ホスト・パーティションＶＳＰ４２８ならびにゲスト・パーティションＶＳＣ４１６および４１８は、仮想機械バス（ＶＭＢｕｓ）に接続することができる。ＶＭＢｕｓは、パーティション間通信を可能にする論理チャネルである。仮想プロセッサー４３０および４３２のような仮想リソースに対するゲスト・パーティションの要求は、ＶＭＢｕｓを通じて、要求を管理することができるホスト・パーティションにおけるデバイスにリディレクトすることができる。ホスト・パーティションからゲスト・パーティションへの応答も、ＶＭＢｕｓを通じてリディレクトすることができる。このプロセス全体は、ゲストＯＳ２２０および２２２に対して透過的であることができる。他の実施形態では、ホスト・パーティションＶＳＰ２２８ならびにゲスト・パーティションＶＳＣ２１６および２１８は、メッセージ・パケットを送信し受信することによって、ＴＣＰ／ＩＰネットワークのようなネットワークを通じて通信することができる。

[0053] 図４に示すように、エミュレーター４３４、例えば、仮想化ＩＤＥデバイス、仮想化ビデオ・アダプター、仮想化ＮＩＣ等は、ホスト４０４内部で実行するように構成することができ、ゲスト・オペレーティング・システム４２０および４２２に利用可能なリソースに添付される(attach)。例えば、ゲストＯＳが、デバイスのレジスタがあるところにマッピングされたメモリー位置、またはメモリー・マッピングされたデバイスにタッチする(touch)とき、ハイパーバイザー・マイクロカーネル４０２は要求を横取りし(intercept)、ゲストが書き込もうとする値を、関連するエミュレーターに渡すことができる。ここで、この例におけるリソースは、仮想デバイスが位置するところであると考えることができる。このようなエミュレーターの使用は、エミュレーション・パス(emulation path)と見なすことができる。エミュレーション・パスは、仮想化パスと比較すると非効率的である。何故なら、ＶＳＰとＶＳＣとの間でメッセージを渡すよりも、デバイスをエミュレートする方が多くのＣＰＵリソースを必要とするからである。例えば、エミュレーション・パスを経由して値をディスクに書き込むために必要とされるレジスタにマッピングされたメモリーにおける数百回の動作は、仮想化パスにおいてＶＳＣからＶＳＰに渡される１つのメッセージに減らすことができる。

[0054] 各ゲスト・パーティションは、１つ以上の仮想プロセッサー（４３０および４３２）を含むことができ、これらの仮想プロセッサーをゲスト・オペレーティング・システム（４２０および４２２）が管理して、そこで実行するスレッドのスケジューリングを行うことができる。一般に、仮想プロセッサーは、実行可能命令および関連する状態情報である。状態情報は、物理プロセッサーの表現に特定のアーキテクチャーを付与する。例えば、１つの仮想機械が、Intel社のx86プロセッサーの特性を有する仮想プロセッサーを有するのであってもよく、一方他の仮想プロセッサーがPowerPCプロセッサーの特性を有するのでもよい。この例における仮想プロセッサーは、これらの仮想プロセッサーを実装する命令がプロセッサーによって支援されるように、コンピューター・システムのプロセッサーにマッピングすることができる。つまり、多数のプロセッサーを含む実施形態では、例えば、他のプロセッサーがハイパーバイザー命令を実行する間に、仮想プロセッサーを同時にプロセッサーによって実行することができる。パーティションにおける仮想プロセッサーとメモリーとの組み合わせは、仮想機械と見なすことができる。

[0055] ゲスト・オペレーティング・システム（４２０および４２２）は、例えば、Microsoft（登録商標）、Apple（登録商標）、オープン・ソース・コミュニティ等からのオペレーティング・システムのような、いずれのオペレーティング・システムでも可能である。ゲスト・オペレーティング・システムは、ユーザー／カーネル動作モードを含むことができ、スケジューラ、メモリー・マネージャー等を含むことができるカーネルを有することができる。一般的に言うと、カーネル・モードは、少なくとも特権プロセッサー命令にアクセスを付与するプロセッサーにおける実行モードを含むことができる。各ゲスト・オペレーティング・システムは、関連するファイル・システムを有することができ、このファイル・システムには、リモート・サービスまたは仮想デスクトップ・セッション、端末サーバー、電子商取引サーバー、電子メール・サーバー等のようなアプリケーション、およびゲスト・オペレーティング・システム自体を格納することができる。ゲスト・オペレーティング・システムは、仮想プロセッサー上で実行するスレッドのスケジューリングを行うことができ、このようなアプリケーションのインスタンスを実装することができる。

[0056] 図５は、図４のコンポーネントに類似するコンポーネントを示す。しかしながら、この実施形態例では、ハイパーバイザー５４２が、マイクロカーネル・コンポーネントと、仮想化サービス・プロバイダー４２８およびデバイス・ドライバー４２４のような図４のホスト４０４におけるコンポーネントと同様のコンポーネントを含むことができ、一方管理オペレーティング・システム５４０は、例えば、ハイパーバイザー５４２を構成するために用いられる構成ユーティリティ(configuration utilities)を収容してもよい。このアーキテクチャーでは、ハイパーバイザー５４２は、図４のハイパーバイザー・マイクロカーネル４０２およびホスト４０４と同じ機能または同様の機能を実行することができる。ハイパーバイザー５４２は、単体ソフトウェア生産物であることができ、オペレーティング・システムの一部であることができ、マザーボードのファームウェア内部に埋め込むことができ、および／またはハイパーバイザー５４２の一部は特殊集積回路によって実装することもできる。

[0057] 種々の実施形態では、図２のリモート・サーバー・コンピューター２２０のような、リモート・サーバー・コンピューターは、多数のリモート・クライアント・セッションまたは仮想デスクトップを実行することができる。リモート・クライアント・セッション２２２のような各リモート・クライアント・セッションは、接続クライアントに対するアプリケーション環境を表すことができる。リモート・サーバー・コンピューターは、図６に示すように、接続するリモート・クライアント・コンピューター毎に、少なくとも１つのリモート・クライアント・セッションを生成することができる。更に、先に注記したように、リモート・サーバー・コンピューター２２０は、図４および図５のコンピューター・システム４００のコンポーネントの一部または全部を実行する仮想機械であってもよく、一方、コンピューター・システム４００は多数のリモート・クライアント・セッションを実行する。

[0058] 図６に示すのは、コンピューター・システム６００であり、リモート・サーバー・コンピューターを実装するように構成された回路を含んでもよく、また他の実施形態では、コンピューター・システム６００は、リモート・デスクトップ接続をサポートするように構成された回路を含むことができる。図示する例では、コンピューター・システム６００は、セッション１からＮまで（Ｎは２よりも大きい正の整数）というような、接続クライアントに対して１つ以上のリモート・クライアント・セッションを生成するように構成することができる。端的に言うと、本発明の実施形態例におけるセッションは、一般に、複数のサブシステム、例えば、ソフトウェア・コードによって実装される動作環境を含むことができ、これらのサブシステムは、コンピューター・システム６００のカーネル６１４と相互作用するように構成される。例えば、セッションは、デスクトップ・ウィンドウのようなユーザー・インターフェース、ウィンドウ内におけるマウスの動きを追跡するサブシステム、アイコン上でのマウス・クリックをプログラムのインスタンスを実装するコマンドに変換するサブシステム等をインスタンス化するプロセスを含むことができる。セッションは、例えば、コンピューター・システム６００が図２のリモート・クライアント・コンピューター２１０のようなクライアントからの接続要求をネットワーク接続を通じて受信したときに、コンピューター・システム６００によってユーザー毎に生成することができる。一般に、接続要求は、最初にトランスポート・ロジック６１０によって扱うことができ、例えば、トランスポート・ロジック６１０は、コンピューター・システム６００の回路によって実装することができる。トランスポート・ロジック６１０は、実施形態では、ネットワーク・アダプター、ファームウェア、および接続メッセージを受信しこれらをエンジン６１２に転送するように構成することができるソフトウェアを含むことができる。図６に示すように、トランスポート・ロジック６１０は、実施形態では、セッション毎にプロトコル・スタック・インスタンスを含むことができる。一般に、各プロトコル・スタック・インスタンスは、ユーザー・インターフェースの出力をクライアントに導き、クライアントから受信したユーザー入力を、そのセッションに関連するセッション・コア６４４に導くように構成することができる。

[0059] 図６の全体的な説明を続けると、本発明の実施形態例におけるエンジン６１２は、セッション要求を処理し、セッション毎に機能を決定し、１組の物理リソースをセッションに割り当てることによってセッションを生成し、そのセッションに対するプロトコル・スタック・インスタンスをインスタンス化するように構成することができる。実施形態では、以上で述べた動作手順の一部を実現する(implement)ことができる特殊回路コンポーネントによってエンジン６１２を実装することもできる。例えば、実施形態例における回路は、メモリーと、エンジン６１２を実装するコードを実行するように構成されたプロセッサーとを含むことができる。図６に示すように、場合によっては、エンジン６１２が接続要求を受けて、例えば、ライセンスが入手可能であり、その要求に対してセッションを生成できると判断することができる。コンピューター・システム６００がリモート・デスクトップ能力を含むリモート・コンピューターであるという状況では、エンジン６１２が接続要求に応答して、ライセンスをチェックすることなく、セッションを生成するように構成することができる。図６に示すように、セッション・マネージャー６１６は、エンジン６１２からのメッセージを受信するように構成することができ、このメッセージに応答して、セッション・マネージャー６１６はセッション識別子を表に追加し、メモリーをセッション識別子に割り当て、サブシステム・プロセスのシステム環境変数およびインスタンスを、セッション識別子に割り当てられたメモリー内において生成することができる。

[0060] 図６に示すように、セッション・マネージャー６１６は、セッション・コア６４４のようなカーネル・モード部を含むことができるランタイム・サブシステム６４０のような、環境サブシステムをインスタンス化することができる。例えば、一実施形態における環境サブシステムは、サービスのある一部(subset)をアプリケーション・プログラムに露出させ、アクセス・ポイントをコンピューター・オペレーティング・システム６０２のカーネルに提供するように構成される。実施形態例では、ランタイム・サブシステム６４０がプロセスおよびスレッドの実行を制御することができ、セッション・コア６４４は、スレッドにメモリーを割り当てこれらを実行する時間をスケジューリングする要求を、カーネル６１４のエクゼキュティブ(executive)に送ることができる。一実施形態では、セッション・コア６４４は、グラフィクス・ディスプレイ・インターフェース６４６（ＧＤＩ）、セキュリティ・サブシステム６５０、および入力サブシステム６５２を含むことができる。入力サブシステム６５２は、これらの実施形態では、セッションに関連するプロトコル・スタック・インスタンスを通じてクライアントからユーザー入力を受信し、この入力をしかるべきセッションのためにセッション・コア６４４に送信するように構成することができる。ユーザー入力は、実施形態では、絶対および／または相対マウス移動コマンド、マウス座標、マウス・クリックを示す信号、キーボード信号、ジョイスティック移動信号等を含むことができる。ユーザー入力、例えば、アイコン上におけるマウスのダブル・クリックは、セッション・コア６４４によって受けることができ、入力サブシステム６５２は、アイコンがダブル・クリックに関連する座標に位置すると判断するように構成することができる。次いで、入力サブシステム６５２は、そのアイコンに関連するアプリケーションに対してプロセスを実行することができるという通知を、ランタイム・サブシステム６４０に送るように構成することができる。

[0061] クライアントから入力を受信することに加えて、アプリケーションおよび／またはデスクトップからドロー・コマンドを受けることもでき、このドロー・コマンドをＧＤＩ６４６によって処理することができる。ＧＤＩ６４６は、一般に、グラフィカル・オブジェクト・ドロー・コマンドを生成することができるプロセスを含むことができる。この実施形態例におけるＧＤＩ６４６は、ＧＤＩ６４６出力をリモート・ディスプレイ・サブシステム６５４に渡すように構成することができ、リモート・ディスプレイ・サブシステム６５４において、コマンドは、そのセッションに添付されたディスプレイ・ドライバーに合わせてフォーマットされる。ある種の実施形態例では、１つ以上の物理ディスプレイをコンピューター・システム６００に、例えば、リモート・デスクトップの状況において添付することができる。これらの実施形態例では、リモート・ディスプレイ・サブシステム６５４は、リモート・コンピューター・システムのディスプレイ・ドライバー（１つまたは複数）によってレンダリングされるドロー・コマンドをミラーリングし(mirror)、このミラーリングした情報をクライアントに、セッションに関連するスタック・インスタンスを通じて送信するように構成することができる。他の実施形態例では、リモート・ディスプレイ・サブシステム６５４は、仮想ディスプレイ・ドライバー（１つまたは複数）を含むように構成することができる。仮想ディスプレイ・ドライバーは、コンピューター・システム６００に物理的に添付されたディスプレイと関連付けられていなくてもよく、例えば、コンピューター・システム６００がヘッドレスで(headless)で実行していることも可能である。この実施形態におけるリモート・ディスプレイ・サブシステム６５４は、１つ以上の仮想ディスプレイに対するドロー・コマンドを受け、これらをクライアントに、セッションに関連するスタック・インスタンスを通じて送信するように構成することができる。本発明の一実施形態では、リモート・ディスプレイ・サブシステム６５４は、ディスプレイ・ドライバー毎に表示解像度を決定し、例えば、仮想ディスプレイに関連する仮想ディスプレイ・ドライバー（１つまたは複数）の表示解像度、または物理ディスプレイに関連するディスプレイ・ドライバーの表示解像度を決定し、関連するプロトコル・スタック・インスタンスを通じてパケットをクライアントに導くように構成することができる。

[0062] 実施形態例では、セッション・マネージャー６１６が加えてセッションのセッション識別子に関連するログオン・プロセスのインスタンスをインスタンス化することもできる。ログオン・プロセスは、セッションのログオンおよびログオフを扱うように構成することができる。これらの実施形態例では、ログオン・プロセスに関連するグラフィカル・ユーザー・インターフェースを示すドロー・コマンドをクライアントに送信することができ、このクライアントのユーザーがアカウント識別子、例えば、ユーザー名／パスワードの組み合わせ、スマート・カード識別子、および／または生物計量情報をログイン画面に入力することができる。この情報は、コンピューター・システム６００に送信され、エンジン６１２およびセッション・コア６４４のセキュリティ・サブシステム６５０に導くことができる。例えば、ある種の実施形態例では、エンジン６１２は、ユーザー・アカウントがライセンスと関連付けられているか否か判断するように構成することができ、セキュリティ・サブシステム６５９は、セッションに対してセキュリティ・トークンを生成するように構成することができる。

[0063] 図６によって説明したように、リモート・サーバー・コンピューターは、多数のリモート・デスクトップ・セッションを接続リモート・クライアント・コンピューターに提供することができる。リモート・デスクトップ・セッションは、リモート・クライアント・コンピューターによって要求される１つ以上のアプリケーションと関連付けられてもよい。加えて、そして図６によって説明したように、リモート・サーバー・コンピューターは、ユーザー・インターフェース画面、ユーザー入力コマンド等のような、クライアント・デスクトップを表すグラフィックス・データーを処理することができる。更に、リモート・サーバー・コンピューターは、グラフィクス・データーをレンダリングし、キャプチャし、圧縮し、クライアント・リモート・コンピューターに送信することもできる。レンダリングとは、リモート・デスクトップ・セッション内において実行するアプリケーションによって行われる、回転する、ひっくり返す、および描画するというような、生の表示コール(raw display call)を変換するプロセスを言う。キャプチャとは、画面上ビットマップまたはフレーム変更というような、レンダリングされたアプリケーション・コンテンツを受け入れ(take)、このアプリケーション・コンテンツの以前のレンダリングに対する変更をインテリジェントにキャプチャすることを言う。圧縮は、エンコーディングとも呼ばれ、グラフィクス・リソースを、接続されているリモート・クライアント・コンピューターの各々に最適にそして公正に配信するプロセスを言う。ネットワーク状態の品質、およびターゲット・リモート・クライアント・コンピューターが、キャプチャされたコンテンツを最適に配信するために用いられる圧縮／エンコーディングのタイプを決定する。

[0064] 本明細書において以下で更に説明するように、種々の実施形態では、リモート・サーバー・コンピューターが、計算サーバーおよびグラフィクス・サーバーを備えるのでもよい。計算サーバーは、グラフィクス・データーをリモート・クライアント・コンピューターから受信し、このグラフィクス・データーを処理し、処理したグラフィクス・データーをグラフィクス・サーバーに送るように構成することができる。グラフィクス・サーバーは、計算サーバーから受信したデーターをレンダリングし、キャプチャし、そして圧縮してグラフィクス出力データーを得るように構成することができる。また、グラフィクス出力データーを計算サーバーに送り、計算サーバーを用いてグラフィクス出力データーをリモート・クライアント・コンピューターに送信する代わりに、グラフィクス・サーバーが、グラフィクス出力データーをリモート・クライアント・コンピューターに直接送信するように構成されてもよい。

[0065] 図７は、計算サーバー７１０およびグラフィクス・サーバー７２０を備えるリモート・サーバー・コンピューター７００の一実施形態例を示す。リモート・サーバー・コンピューター７００の実施形態は、図１のコンピューター１００、図２のリモート・サーバー・コンピューター２２０、図３のリモート・サーバー・コンピューター３２０、図４および図５のコンピューター・システム４００、ならびに図６のコンピューター・システム６００に関して説明したコンポーネントの一部または全部を実行することができる。

[0066] 計算サーバー７１０の実施形態は、図１のコンピューター１００、図２のリモート・サーバー・コンピューター２２０、図４および図５のコンピューター・システム４００または仮想機械４４０、ならびに図６のコンピューター・システム６００に関して説明したコンポーネントの一部または全部を実行することができる。また、計算サーバー７１０は、ＧＰＵリソースが十分でなくても、またはＧＰＵリソースを有していなくてもよい。更に他の実施形態では、計算サーバー７１０が、以下で説明する計算リソースを設けるためにしかるべく構成された標準的なサーバー・コンピューターであってもよい。他の実施形態では、計算サーバー７１０が特定機能に合わせて構成された計算デバイスであってもよい。例えば、計算サーバーが１つのタイプの処理ユニットと、少量のキャッシュ・メモリーのみを有するのでもよい。

[0067] グラフィクス・サーバー７２０は、レンダリング、キャプチャし、および圧縮動作というような、グラフィクス動作のためにリソースを提供するように構成されるのでもよい。また、グラフィクス・サーバーに複数のＧＰＵリソースが構成されてもよい。一実施形態では、グラフィクス・サーバー７２０が、図１のコンピューターに関して説明したコンポーネントの一部または全部を実行することができる。更に他の実施形態では、グラフィクス・サーバーが、図４のホスト４０４のような、ホスト・パーティション上にホストされるのでもよい。計算サーバー７１０およびグラフィクス・サーバー７２０が、ネットワーク（例えば、ファイバー・チャネル、ＬＡＮ、ワイヤレス、イーサネット(登録商標)等）を通じて接続されてもよい。図４の環境のような仮想化環境では、グラフィクス・サーバー７２０および計算サーバー７１０が、ＶＭＢｕｓを用いて接続されてもよい。

[0068] 計算サーバー７１０は、１つ以上のアプリケーション７１２を実行することもできる。一態様では、アプリケーションがグラフィクス・デバイス・ドライバー７１４と関連付けられてもよい。グラフィクス・デバイス・ドライバー７１４、アプリケーション７１２、および／または計算サーバー７１０は、グラフィクス・サーバー７２０上のグラフィクス・サーバー・マネージャー７４０と関連付けられてもよい。グラフィクス・デバイス・ドライバー７１４、アプリケーション７１２、および／または計算サーバー７１０は、命令およびデーターをグラフィクス・サーバー・マネージャー７４０に送ること、ならびに命令およびデーターをグラフィクス・サーバー・マネージャー７４０から受信することができるとよい。一例として、グラフィクス・デバイス・ドライバー７１４、アプリケーション７１２、および／または計算サーバー７１０が、第１データーをグラフィクス・サーバー・マネージャー７４０に送ることができるとよく、この第１データーはＧＰＵリソースの要求を示す。グラフィクス・サーバー・マネージャー７４０が、第２データーをグラフィクス・デバイス・ドライバー７１４、アプリケーション７１２、および／または計算サーバー７１０に送るのでもよく、第２データーは、グラフィクス・サーバー７２０からのＧＰＵ命令に対するルーティング(routing)を示す。

[0069] グラフィクス・サーバー・マネージャー７４０が、グラフィクス・サーバー７２０を管理することもできる。グラフィクス・サーバー・マネージャー７４０は、命令およびデーターをグラフィクス・サーバー７２０のコンポーネントに送ることができるとよく、グラフィクス・サーバー７２０のコンポーネントからの応答として、情報およびデーターを受信すればよい。グラフィクス・サーバー７２０は、ＧＰＵホスティングおよび処理に特殊化されてもよい。グラフィクス・サーバー７２０は、グラフィクス・サーバー・マネージャー７４０、プロキシー・グラフィクス・アプリケーション７２２、カーネル７２６、およびＧＰＵハードウェア７３０を備えることができる。プロキシー・グラフィクス・アプリケーション７２２が、第１グラフィクス・デバイス・ドライバー７２４と関連付けられてもよく、カーネル７２６が、第２グラフィクス・デバイス・ドライバー７２８と関連付けられてもよい。グラフィクス・デバイス・ドライバー７２４および７２８は、グラフィクス処理タスクに関連するデーターおよび情報を変換、受信、そして送信することができる。一実施形態では、グラフィクス・デバイス・ドライバー７２４および７２８は、特定のＧＰＵハードウェア７３０と、グラフィクス・サーバー・マネージャー７４０、計算サーバー７１０、および／またはリモート・クライアント・コンピューター上のアプリケーション、ハードウェア、およびオペレーティング・システムとの間において変換を行うために選択される。

[0070] 図７の実施形態では、グラフィクス処理タスクに関連する命令は、アプリケーション７１２からグラフィクス・サーバー・マネージャー７４０までの一連のレイヤーを通って、プロキシー・グラフィクス・アプリケーション７２２に、カーネル７２６に、そしてハードウェア７３０まで流れることができる。処理された情報は、同じパスを逆に辿ればよい。図８は、情報パスについての代替実施形態を示す。グラフィクス・サーバー・マネージャー８５０は、計算サーバー７１０、アプリケーション７１２、および／またはグラフィクス・デバイス・ドライバー７１４からＧＰＵリソース要求を受け、ルーティング命令、状態命令等を計算サーバー７１０およびグラフィクス・サーバー７２０に送る。その後、ＧＰＵタスク、処理された情報、および命令は、直接グラフィクス・サーバー７２０と計算サーバー７１０との間で送ることができる。グラフィクス・サーバー・マネージャー８５０は、これらの相互作用を監視することができ、ＧＰＵハードウェア７３０のようなＧＰＵ上におけるリソースの割り当てに関係する他のタスクも実行することができる。

[0071] 図９は、複数のグラフィクス・サーバー７２０（Ａ〜Ｎ）を示す。これらは、１組のＧＰＵハードウェア７３０に関連するリソースがＧＰＵ処理タスクを実行するには不十分であるときに用いることができる。また、この実施形態は、グラフィクス・サーバー・マネージャー８５０がＧＰＵ処理タスクの一部を第１グラフィクス・サーバー７２０Ａから第２グラフィクス・サーバー７２０Ｂに移すときにも用いることができる。このような実施形態では、グラフィクス・サーバー・マネージャー８５０が、第１グラフィクス・サーバー７２０Ａの状態を第２グラフィクス・サーバー７２０Ｂにコピーするように動作することもできる。

[0072] 図１０は、計算サーバー１０１０およびグラフィクス・サーバー１０２０が仮想化環境または仮想デスクトップ・インフラストラクチャ（ＶＤＩ）において実現される(implement)、リモート・サーバー・コンピューター１０００の一実施形態例を示す。計算サーバー１０１０およびグラフィクス・サーバー１０２０は、図７〜図９の計算サーバー７１０およびグラフィクス・サーバー７２０を実装するように構成することができる。リモート・サーバー・コンピューター１０００の実施形態は、図１のコンピューター１００、図２のリモート・サーバー・コンピューター２２０、図３のリモート・サーバー・システム３５０、図４および図５のコンピューター・システム４００、ならびに図６のコンピューター・システム６００に関して説明したコンポーネントの一部または全部を実行することができる。

[0073] 図１０は、ＶＤＩに対するホスト・ベースのグラフィクス仮想化を示す。このようなアーキテクチャーは、例えば、Microsoft（登録商標）RemoteFX（登録商標）プラットフォームを用いて実現する(implement)ことができる。仮想機械１０１１（Ａ〜Ｎ）は、仮想デスクトップと呼ぶことができる。このアーキテクチャーは、仮想グラフィクス処理ユニット（ｖＧＰＵ）１０１６（Ａ〜Ｎ）を用い、ゲスト・オペレーティング・システム（ＯＳ）１０１４（Ａ〜Ｎ）と物理ＧＰＵ１１２との間の関係を抽象化し、ホストされたマルチ・ユーザー環境においてＧＰＵリソースを最適に共有する。

[0074] ハイパーバイザー・マイクロカーネル１００２は、複数のホストおよびゲスト・パーティションを実現するように構成することができる。他の実施形態では、ハイパーバイザー・マイクロカーネル１００２は、リモート・デスクトップ・セッション・コンポーネント（図示せず）を統合することができる。

[0075] 各ホスト・パーティションは、リモート・コンピューター・サーバー１０００の物理ＧＰＵリソースにアクセスするグラフィクス・サーバー１０２０として構成することができる。また、各ホスト・パーティションは、グラフィクスのレンダリング、キャプチャし、およびエンコーディングのために管理コンポーネントも含むことができる。また、各ホスト・パーティションは、物理ＧＰＵ１１２および、ＡＳＩＣＳ（図示せず）のようなホスト・ベース・エンコーダーにインターフェースを設けるデバイス・ドライバー１０２６も含むことができる。デバイス・ドライバー１０２６は、ＧＰＵ、ＣＰＵ、およびエンコーダー特定ドライバーを含むことができる。

[0076] 各ゲスト・パーティションは、ｖＧＰＵリソースにアクセスする計算サーバー１０１０として構成することができる。各ゲスト・パーティションは、複数の接続されたリモート・クライアント・コンピューター（図示せず）に対して１つ以上の仮想デスクトップまたはセッションを実装することができる。各ゲスト・パーティションとリモート・クライアント・コンピューターとの間の接続は、図２および図３に示したものと同様である、ＲＤＰ７．１のようなリモート・デスクトップ・セッションを含むことができる。

[0077] ｖＧＰＵ１０１６は、各仮想機械１０１１にインストールされる仮想グラフィクス・アダプターを設けることができる。ｖＧＰＵ１０１６は、１つ以上のＧＰＵ１１２を利用する多数の仮想機械に対するグラフィック処理を抽象化することができる。仮想機械１０１１において実行するアプリケーションが、DirectX（登録商標）またはＧＤＩ動作のようなグラフィクス動作を呼び出すとき、ｖＧＰＵ１０１６は、ゲスト・パーティション１０１０とホスト・パーティション１０２０との間の通信チャネルを用いて、ＧＰＵ１１２からリソースを得ることができる。この通信チャネルは、ＶＭＢｕｓまたはＴＣＰ／ＩＰチャネルを含むことができる。ＶＭＢｕｓは、メモリー共有およびｖＧＰＵに特定的な他の機能のために、ハイパーバイザー・マイクロカーネル１００２内部に構成することができる。このようなＶＭＢｕｓ構成は、統合メカニズムを直接ハイパーバイザー・マイクロカーネル１００２内に設けることができ、グラフィクス関連デバイスを求める全てのリソース要求を転送することができる。

[0078] また、ｖＧＰＵ１０１６は、ある品質のサービス・メカニズムを仮想機械１０１１に提供することもできる。サービス・メカニズムの品質は、ＧＰＵ１１２を最も効率的利用する負荷均衡方針に基づいて、公平にＧＰＵ１１２のリソースを仮想機械１０１１に配分する(deliver)ことができる。

[0079] ホスト・パーティション１０２０は、リモート・デスクトップ仮想グラフィクス管理（ＲＤＶＧＭ）機能を仮想機械１０１１に設けるように構成することができる。ＲＤＶＧＭは、リモート・コンピューター・サーバー１０００の物理リソース間におけるリソース割り当ておよびプロセス制御と、各仮想機械のゲスト・オペレーティング・システム（ＯＳ）１０１４へのｖＧＰＵ１０１６のリソース割り当とを管理することができる。ＲＤＶＧＭ機能は、レンダリング、キャプチャし、および圧縮（ＲＣＣ）プロセスを管理すること、ＧＰＵ１１２リソースを仮想機械１０１１にｖＧＰＵ１０１６を介して割り当てること、仮想機械１０１１に対するリソース方針を指定すること、および多数の仮想機械１０１１（A〜N）に跨がってＧＰＵ１１２リソースの負荷均衡を行うことを含むことができる。また、ＲＤＶＧＭは、ブートの時点においてしかるべきＧＰＵ１１２リソースを仮想機械１０１１（A〜N）に割り当てることもできる。

[0080] ＲＤＶＧＭは、ＲＣＣエンジン１０２２を統合することができる。ＲＣＣエンジン１０２２は、グラフィクス・データーのレンダリング、キャプチャし、および圧縮を扱う。ＲＣＣは、グラフィクス要求を各仮想機械１０１１からの出力として受け、これらの要求を、例えば、ホスト・パーティション１０２０上のDirectX（登録商標）に準拠したコマンドに変換することができる。ＶＭＢｕｓは、仮想機械１０１１（A〜N）において実行する、ホストされたアプリケーション１０１２（A〜N）からの物理ＧＰＵ１１２のリソースに対するグラフィクス要求のために、高速通信バックプレーンを提供することができる。DirectX（登録商標）準拠コマンドに対して、アプリケーション１０１２（A〜N）は、DirectX（登録商標）９以降をサポートする必要があり、一方ＧＰＵ１１２はDirectX（登録商標）１０以降をサポートする必要がある。

[0081] 既に説明したように、レンダリングとは、ｖＧＰＵ1016（Ａ〜Ｎ）を介してアプリケーション１０１２（A〜N）によって行われる、回転する、ひっくり返す、および描画するというような生の表示コールを変換し、これらの要求をＧＰＵ１１２に与え(honoring)、このようにしてアプリケーション・コンテンツをレンダリングするプロセスを指す。レンダリングは、標準的なDirectX（登録商標）のシンタックスに基づくことができる。キャプチャは、画面上ビットマップまたはフレーム変更というような、レンダリングされたアプリケーション・コンテンツを受け入れ(take)、このアプリケーション・コンテンツの以前のレンダリングに対する変更をインテリジェントにキャプチャすることを言う。キャプチャの二次的機能は、キャプチャ品質およびエンコーディング・レベルに対してサービス方針の品質を指定することである。圧縮またはエンコーディングは、ＧＰＵ１１２のリソースをリモート・クライアント・コンピューターに、例えば、リモート・デスクトップ・セッション・プロトコルを含む通信チャネルを通じて、ｖＧＰＵ１０１６によって最適にそして公正に配信するプロセスを言う。通信チャネルの品質および状態、ならびに目標とされるリモート・クライアント・コンピューターのタイプが、キャプチャされたコンテンツを最適に配信するために用いられる圧縮／エンコーディングのタイプを決定する。

[0082] ＶＭ１０１１内において実行するアプリケーション１０１２が、描画、サイズ変更、および回転というような表示コールを発行するとき、ｖＧＰＵ１０１６は全てのレンダリング要求を仲介することができる。仮想化パスは、ゲストＯＳ１０１４に対して透過的であることができる。既に説明したように、グラフィクス処理コマンドは、ホスト・パーティション１０２０が横取りすることができる。この横取りは、ソフトウェア・スタックにおける低いレベルで行うことができる。次いで、ＧＰＵ１１２上においてグラフィクスを１つのフレーム・バッファにレンダリングすることができる。この１つのフレーム・バッファは、グラフィック更新のための一時的保存場所(holding station)として役割を果たす。フレーム・バッファは、エンド・ユーザーの仮想化表示を表すことができ、エンド・ユーザーとは、リモート・クライアント・コンピューターを用いて仮想機械１０１１に接続されたユーザーである。豊富なグラフィクス・アプリケーション、３Ｄプラグイン、ならびにその他のグラフィクス・コールおよびコマンドは、ＧＰＵを内蔵した専用ワークステーション上でアプリケーションが実行しているかのように、正確に実行することができる。

[0083] ホスト・パーティション１０２０は、素早くそして効率的に、レンダリングされたコンテンツをキャプチャすることができる。コンテンツ内にある各フレームは、管理可能な
単位に分割することができる。フレーム内における変化領域は、ＲＣＣエンジン１０２２によって設けられる最適化能力によって処理することができる。このキャプチャ・メカニズムによって、個々のフレームが表示変化のために横取りされる。フレーム内において変化した領域のみが、エンコーディングのためにキャプチャされる。

[0084] また、ホスト・パーティション１０２０は、キャプチャされたコンテンツを圧縮することもできる。圧縮プロセスは、ある種の仮想機械に与える優先順位を高くまたは低くして、あるいはキャプチャされたフレーム内における変化領域のサイズによって動的に、管理ツールによって制御することができる。加えて、ＲＤＰ７．１のようなリモート・デスクトップ・セッションを用いる実施形態では、このリモート・デスクトップ・セッションが、ネットワークの使用および公正さに基づいて、フレーム・レートの最適化に備えることができる。ＲＣＣエンジン１０２２は、リモート・デスクトップ・セッション・リスナー・プロセス(listener process)に接触し(reach out to)、リモート・クライアント・コンピューターのデコーディング能力を含む、リモート・クライアント・コンピューターの状態を評価することができる。フレーム・バッファに対する変更は、フレーム・レートでリモート・クライアント・コンピューターに送ることができ、フレーム・レートはネットワーク状態およびリモート・クライアント・コンピューターの変更を消費する能力に動的に適合する。エンコードされた出力は、リモート・デスクトップ・セッション内をくぐり抜けることができ、リモート・クライアント・コンピューターに送出することができる。

[0085] １つ以上の計算サーバーおよび１つ以上のグラフィクス・サーバーを備えたリモート・サーバー・コンピューターを実現するための、図７〜図１０に示した全てのアーキテクチャーの変形は、実施態様の例である。ここでは、いかなることであっても、本開示をいずれの特定の実施態様(implementation aspect)に限定するように解釈してはならない。

[0086] リモート計算環境では、リモート・クライアント・コンピューターは通例コンピューター・サーバーのみと通信し、グラフィクス・サーバーとの直接的な接続を有さない。コンピューター・サーバーとの通信は、図３に示したものと同様のリディレクターおよび／またはブローカーの使用を含むことができる。計算サーバーは、通例、リモート・クライアント・コンピューターとの接続を管理する。例えば、計算サーバーのゲスト・オペレーティング・システムは、クライアントを認証するように構成することができる。一旦認証が完了したなら、リモート・クライアント・コンピューターと計算サーバーとの間における転送を開始することができる。したがって、リモート・クライアント・コンピューターからのグラフィクスの要求は、計算サーバーによって受けることができる。計算サーバーはこのグラフィクス要求を処理してグラフィクス・コールおよびコマンドを得て、レンダリング、キャプチャ、および圧縮のために、これらのコールおよびコマンドをグラフィクス・サーバーに送信することができる。グラフィクス・サーバーはリモート・クライアント・コンピューターとの直接的な通信パスを有さないので、グラフィクス・サーバーからのグラフィクス出力は、計算サーバーに送ることができる。計算サーバーは、このグラフィクス出力をパッケージ化し、エンド・ユーザーに対する表示のために、リモート・クライアント・コンピューターに送信することができる。

[0087] 以上の説明を図１０の仮想環境において適用すると、リモート・クライアント・コンピューターからのグラフィクス要求は、リモート・サーバー・コンピューター１０００の物理ＮＩＣ１１４上を、ゲスト・パーティション１０１０の仮想ＮＩＣ（図示せず）を通ってアプリケーション１０１２に送信される。次いで、グラフィクス要求は処理されて、レンダリング、キャプチャ、および圧縮のためにホスト・パーティション１０１２に導くことができる。一旦レンダリングされ、キャプチャされ、圧縮されたなら、出力データーをホスト・パーティション１０２０から計算サーバー１０１０に、ｖＧＰＵ１０１６を用いて逆に導くことができる。出力データーをゲスト・パーティション１０１０からリモート・クライアント・コンピューターに送信するために、ゲスト・パーティション１０１０は、データーをパッケージ化し仮想ＮＩＣを用いて送信することができる。仮想ＮＩＣは、出力データーを物理ＮＩＣ１１４にリディレクトし、物理ＮＩＣ１１４はこのデーターをネットワークを通じてリモート・クライアント・コンピューターに送信することができる。既に説明したように、ゲスト・パーティション１０１０、ホスト・パーティション１０２０、およびリモート・サーバー・コンピューター１０００の基礎リソース間において繰り返されるデーターの横断は、集中的動作を必要とする可能性があり、大量のメモリーおよびＣＰＵリソースを消費する可能性があり、リモート・クライアント・コンピューターに対するデーター配信レイテンシが増大する可能性がある。

[0088] 図１１は、リモート・サーバー・コンピューター１１００のリソース間における繰り返しデーター横断を解消する代替アーキテクチャーを示す。図１１は、リモート・クライアント・コンピューター１１３０との接続の管理を計算サーバー１１１０内に保持し、グラフィクス・サーバー１１２０が、グラフィクス出力データーを直接リモート・クライアント・コンピューター１１３０にストリーミングすることを可能にするアーキテクチャーについて説明する。リモート・サーバー・コンピューター１１００の実施形態は、図７〜図９のリモート・サーバー・コンピューター７００および図１０のリモート・サーバー・コンピューター１０００に関して説明したコンポーネントの一部または全部を実行することができる。リモート・クライアント・コンピューター１１３０の実施形態は、図１のコンピューター１００、図２のリモート・クライアント・コンピューター２１０、および図３のリモート・クライアント・コンピューター３１０に関して説明したコンポーネントの一部または全部を実行することができる。

[0089] リモート・クライアント・コンピューター１１３０は、ネットワーク（図示せず）を通じた計算サーバー１１１０との接続１１０５を開始することができる。接続１１０５は、ＴＣＰＩ／ＩＰに基づくことができ、ＲＤＰ７．１のようなリモート・デスクトップ・セッションを含むことができる。計算サーバー１１１０は、リモート・クライアント・コンピューター１１３０との接続１１０５を認証することができる。認証方法は、リモート・クライアント・コンピューター１１３０の仮想デスクトップまたはセッションが計算サーバー１１１０において設定される前に、リモート・クライアント・コンピューター１１３０が認証されることを要求することができる。例えば、認証方法は、ＲＤＰ７．１において利用可能なネットワーク・レベルの認証とすることができる。加えて、計算サーバー１１１０は、リモート・クライアント・コンピューター１１３０のＩＰアドレスのようなアドレスを取得することができる。

[0090] 一旦認証が完了し、リモート・クライアント・コンピューター１１３０と計算サーバー１１１０との間に接続１１０５が確立されたなら、計算サーバー１１１０は、仮想機械内においてリモート・デスクトップ・セッション、仮想機械、デスクトップ・セッション、またはその組み合わせを開始することができ、これらはリモート・クライアント・コンピューター１１３０のために計算サーバー１１１０内部で実行する。このような仮想機械またはデスクトップ・セッションは、図２〜図１０の技法を具体化することができる。加えて、計算サーバー１１１０は、グラフィクス・サーバー１１２０を初期化することができる。この初期化は、例えば、グラフィクス・サーバーがインアクティブ状態にある場合にはグラフィクス・サーバー１１２０を復元または起動し、計算サーバー１１１０とグラフィクス・サーバー１１２０との間に接続１１１５を確立することを含むことができる。接続１１１５は、ＴＣＰ／ＩＰに基づくことができ、または仮想環境におけるＶＭＢｕｓを用いることができる。また、計算サーバー１１１０は、リモート・クライアント・コンピューター１１３０のアドレスをグラフィクス・サーバー１１２０に供給し、グラフィクス・サーバー１１２０に、リモート・クライアント・コンピューター１１３０のアドレスから発する接続要求に対する準備をするように命令することができる。また、計算サーバーは、グラフィクス・サーバー１１２０の、ＩＰアドレスのような、アドレスを取得することができ、グラフィクス・サーバー１１２０のアドレスをリモート・クライアント・コンピューター１１３０に供給することができる。

[0091] 一旦グラフィクス・サーバー１１２０が初期化され、リモート・クライアント・コンピューター１１３０がグラフィクス・サーバー１１２０のアドレスを取得したなら、クライアント・コンピューター１１３０はネットワーク（図示せず）を通じてグラフィクス・サーバー１１２０との接続１１２５を開始することができる。接続１１２５は、ＴＣＰ／ＩＰに基づくことができる。また、接続１１２５は、ＲＤＰ７．１のような、リモート・デスクトップ・セッションを含むこともできる。他の実施形態では、接続１１０５および接続１１２５がリモート・デスクトップ・セッションを含む場合、リモート・デスクトップ・セッションは別個であることができ、または接続１１０５および接続１１２５に跨がって同一であることもできる。

[0092] 一旦接続１１０５、１１１５、および１１２５が確立されたなら、リモート・クライアント・コンピューター１１３０は、キーボードまたはマウス入力のような、エンドユーザー・グラフィクス入力をコンピューター・サーバー１１１０に送ることができる。コンピューター・サーバーは、図２、図６〜図１０の技法を用いて、グラフィクス入力を処理することができる。一実施形態では、計算サーバー１１１０はエンド・ユーザーのキーボード押鍵またはアイコン上のマウス・クリックを、アプリケーションのインスタンスを実装する表示コマンドに、そして回転する、ひっくり返す、サイズ変更する、および描画するというような表示コールに変換することができる。計算サーバー１１１０は、表示コマンドおよびコール・データーを、レンダリング、キャプチャ、および圧縮のために、グラフィクス・サーバー１１２０に送ることができる。グラフィクス・サーバー１１２０は、表示コマンドおよびコール・データーをレンダリングし、キャプチャし、圧縮することができ、そして出力を出力グラフィクス・データーとしてエンコードすることができる。出力グラフィクス・データーを計算サーバー１１１０に送る代わりに、グラフィクス・サーバー１１２０は出力グラフィクス・データーを直接リモート・クライアント・コンピューター１１３０に、接続１１２５を通して送信することができる。リモート・クライアント・コンピューター１１３０は、エンド・ユーザーへの表示のために、出力グラフィクス・データーをデコードすることができる。

[0093] 一実施形態では、図１０のリモート・サーバー・コンピューター１０００のように、リモート・サーバー・コンピューター１１００が仮想化される場合、計算サーバー１１１０をゲスト・パーティション上に実装することができ、グラフィクス・サーバー１１２０をホスト・パーティション上に実装することができる。各パーティションは、ＩＰアドレスのようなアドレスを有するように構成することができる。ゲスト・パーティションまたは計算サーバー１１１０のアドレスは、仮想ＮＩＣと関連付けることができる。ホスト・パーティションまたはグラフィクス・サーバー１１２０のアドレスは、仮想ＮＩＣまたはリモート・サーバー・コンピューター１１００の基礎となるハードウェアの物理ＮＩＣ１１４と関連付けることができる。計算サーバー１１１０は、その中で実行する仮想機械またはセッションをリモート・クライアント・コンピューター１１３０に提示することができる。計算サーバー１１１０とグラフィクス・サーバー１１２０との間の接続１１１５は、ＶＭＢｕｓのようなパーティション内通信チャネルを構成することができる。

[0094] リモート・クライアント・コンピューター１１３０におけるエンド・ユーザー入力のようなグラフィクス・データーは、リモート・クライアント・コンピューター１１３０から接続１１０５を通って、コンピューター・サーバー１１１０の仮想ＮＩＣと関連する計算サーバー１１１０のアドレスに送ることができる。

[0095] 計算サーバー１１１０は、受信したグラフィクス・データーを処理して、先に説明したように、表示コマンドおよびコール・データーを得ることができる。計算サーバー１１１０は、処理したグラフィクス・データーを、レンダリング、キャプチャ、および圧縮のためにグラフィクス・サーバー１１２０に送ることができる。一実施形態では、処理したデーターを送るとき、処理したデーターを、計算サーバー１１１０に割り当てられたメモリー空間から、グラフィクス・サーバー１１２０に割り当てられたメモリー空間に送信することを含むことができる。他の実施形態では、リモート・サーバー・コンピューター１１００内部のパーティションがメモリー空間を共有することができる。このような実施形態では、計算サーバー１１１０からグラフィクス・サーバー１１２０にデーターを送るとき、２つのメモリー空間の間で処理したデーターをコピーするのではなく、処理したデーターを収容するメモリー空間のアドレスを送出することを含むことができる。例えば、計算サーバー１１１０およびグラフィクス・サーバー１１２０は、処理したデーターを導くために、ＶＭＢｕｓ内部の共有メモリー空間を利用することができる。

[0096] グラフィクス・サーバー１１２０は、先に説明したように、処理したデーターをレンダリングし、キャプチャし、圧縮することができる。グラフィクス・サーバー１１２０は、レンダリングし、キャプチャし、圧縮したデーターをエンコードして出力データーを得ることができ、グラフィクス・サーバーＮＩＣを用いて、この出力データーを、リモート・クライアント・コンピューター１１３０に関連するアドレスに送信することができる。リモート・クライアント・コンピューター１１３０は、受信した出力データーを、エンド・ユーザーへの表示のためにデコードすることができる。

[0097] 図１２は、複数のリモート・クライアント・コンピューター１１３０（Ａ〜Ｎ）、複数の計算サーバー１１１０（Ａ〜Ｎ）、および複数のグラフィクス・サーバー１１２０（Ａ〜Ｎ）を備える環境における、図１１のアーキテクチャーの一実施形態を示す。尚、リモート・クライアント・コンピューター、計算サーバー、およびグラフィクス・サーバーの数は、等しい必要はないことを注記するのは重要である。言い換えると、リモート・クライアント・コンピューター１１３０（Ａ〜Ｎ）と計算サーバー１１１０（Ａ〜Ｎ）との間の関係、計算サーバー１１１０（Ａ〜Ｎ）とグラフィクス・サーバー１１２０（Ａ〜Ｎ）との間の関係、およびグラフィクス・サーバー１１２０（Ａ〜Ｎ）とリモート・クライアント・コンピューター１１３０（Ａ〜Ｎ）との間の関係は、１対１、１対多数、またはその組み合わせとすることができる。

[0098] リモート・サーバー・コンピューター１２００の実施形態は、図２のリモート・サーバー・コンピューター２２０、図３のリモート・サーバー・コンピューター３２０、図７〜図１０のリモート・サーバー・コンピューター７００、図１０のリモート・サーバー・コンピューター１０００、および図１１のリモート・サーバー・コンピューター１１００に関して説明したコンポーネントの一部または全部を実行することができる。一実施形態では、リモート・サーバー・コンピューター１２００は複数の物理計算システムを備えることができる。リディレクターおよびブローカー１２４０は、図３のリディレクター３３０およびブローカー３４０に関して説明したコンポーネントの一部または全部を実行することができる。グラフィクス・サーバー・マネージャー１２５０は、図７のグラフィクス・サーバー・マネージャー７４０、および図８〜図９のグラフィクス・サーバー・マネージャー８５０に関して説明したコンポーネントの一部または全部を実行することができる。加えて、リディレクターおよびブローカー１２４０は、計算サーバー１１１（Ａ〜Ｎ）と統合することができる。同様に、グラフィクス・サーバー・マネージャー１２５０もグラフィクス・サーバー１１２０（Ａ〜Ｎ）と統合することができる。他の実施形態では、リモート・サーバー・コンピューターが仮想化されてもよく、図４〜図５の計算システム４００、図１０のリモート・サーバー・コンピューター１０００、および図１１のリモート・サーバー・コンピューター１１００に関して説明したコンポーネントの一部または全部を実行することができる。このような実施形態では、計算サーバー１１１０（Ａ〜Ｎ）は、１つ以上のゲスト・パーティション上に実装することができ、グラフィクス・サーバー１１２０（Ａ〜Ｂ）は、１つ以上のホスト・パーティション上に実装することができる。リディレクターおよびブローカー１２４０ならびにグラフィクス・サーバー・マネージャー１２５０も、１つ以上のゲスト・パーティションおよび／または１つ以上のホスト・パーティションにおいて、既に説明した技法を用いて仮想化することもできる。更に他の実施形態では、リモート・サーバー・コンピューター１２００は、仮想機械および物理機械の組み合わせとすることもできる。例えば、計算サーバー１１１０（Ａ〜Ｎ）およびグラフィクス・サーバー１１２０（Ａ〜Ｎ）が仮想化されてもよく、一方リディレクターおよびブローカー１２４０ならびにグラフィクス・サーバー・マネージャー１２５０が物理計算デバイスであってもよい。

[0099] リディレクターおよびブローカー１２４０は、リモート・クライアント・コンピューター１１３０と計算サーバー１１１０との間に第１接続を確立するために用いられてもよい。例えば、リディレクターおよびブローカー１２４０は、複数の計算サーバー１１１０（Ａ）の中から計算サーバー１１１０、および／またはそこにおけるセッションをリモート・クライアント・コンピューター１１３０に割り当てることもできる。したがって、リディレクターおよびブローカー１２４０は、計算サーバー１１１０（Ａ）の可用性に関して負荷均衡技法を設けることができる。一旦その割り当てが完了したなら、割り当てられた計算サーバー１１１０は、リモート・クライアント・コンピューター１１３０を認証することができる。リモート・クライアント・コンピューター１１３０および割り当てられた計算サーバー１１１０は、既に説明したように第１接続を確立することができる。例えば、第１接続は、図１１の接続１１０５を構成することができる。また、割り当てられた計算サーバー１１１０は、リモート・クライアント・コンピューター１１３０のアドレスを取得することもできる。

[0100] グラフィクス・サーバー・マネージャー１２５０は、割り当てられた計算サーバー１１１０と、複数のグラフィクス・サーバー１１２０（Ａ〜Ｎ）からのグラフィクス・サーバー１１２０との間に第２接続を確立するために用いられてもよい。グラフィクス・サーバー・マネージャー１２５０は、負荷均衡技法を実行して、グラフィクス・サーバー１１２０（Ａ〜Ｎ）の可用性を判断することができる。これに応じて、グラフィクス・サーバー・マネージャー１２５０は、次に、グラフィクス・サーバー１１２０を、割り当てられたコンピューター・サーバー１１１０との接続に割り当てるのでもよい。一旦この割り当てが完了すると、第２接続を確立することができる。例えば、第２接続は図１１の接続１１１５を構成することができる。

[0101] 割り当てられた計算サーバー１１１０は、リモート・クライアント・コンピューター１１３０のアドレスをグラフィクス・サーバー１１２０に供給することができ、割り当てられたグラフィクス・サーバー１１２０のアドレスを取得して、リモート・クライアント・コンピューター１１３０に供給することができる。リモート・クライアント・コンピューター１１３０および割り当てられたグラフィクス・サーバー１１１２０は、リモート・クライアント・コンピューター１１３０および割り当てられたグラフィクス・サーバー１１２０の取得したアドレスを用いて、第３接続を確立することができる。第３接続は、図１１の接続１１２５を含むことができる。

[0102] 更に、図１２のアーキテクチャー上で負荷均衡技法を実行することができる。例えば、グラフィクス・サーバー１１２０（Ａ〜Ｎ）の負荷均衡の場合、割り当てられたグラフィクス・サーバー１１２０がもはやリモート・クライアント・コンピューター１１３０に適正に配給する(serve)ことができないとき、計算サーバー１１１０は利用可能なグラフィクス・サーバー１１２０との新たな接続を確立し、リモート・クライアント・コンピューター１１３０に、利用可能なグラフィクス・サーバー１１２０との対応する新たな接続を確立するように命令することができる。リモート・クライアント・コンピューター１１３０は、次いで、利用可能なグラフィクス・サーバー１１２０に継ぎ目なく移行することができる。加えて、計算サーバー１１１０（Ａ〜Ｎ）の負荷均衡の場合、割り当てられた計算サーバー１１１０がもはやリモート・クライアント・コンピューター１１３０に適正に配給することができないとき、リモート・クライアント・コンピューター１１３０と利用可能な計算サーバー１１１０との間、および利用可能な計算サーバー１１１０と既に割り当てられているグラフィクス・サーバー１１２０との間に新たな接続を確立することができ、一方リモート・クライアント・コンピューター１１３０と既に割り当てられているグラフィクス・サーバー１１２０との間の接続は同じままで有り続けることができる。仮想機械ライブ・マイグレーションのような技法は、作業負荷を１つの計算サーバー１１１０から他の計算サーバーに継ぎ目なく転移させることができ、一方グラフィクス・サーバー１１２０の作業負荷は同じままで有り続けることができる。

[0103] 一実施形態では、１つ以上のリモート・クライアント・コンピューター１１３０が種々のグラフィクス・サーバー１１２０から表示ストリームまたはグラフィクス出力データーを受け入れることを可能にする技法を用いることができる。例えば、リモート・クライアント・コンピューター１１３０Ａは他のリモート・クライアント・コンピューター１１３０（Ｂ〜Ｎ）から、他のリモート・クライアント・コンピューター１１３０（Ｂ〜Ｎ）に関連するエンド・ユーザー表示を見る許可を得ることができる。この許可は、例えば、他のリモート・クライアント・コンピューター１１３０（Ｂ〜Ｎ）の各々に割り当てられた種々のグラフィクス・サーバー１１２０のアドレスを含むことができる。加えて、この許可は、他のリモート・クライアント・コンピューター１１３０（Ｂ〜Ｎ）のアドレス、他のリモート・クライアント・コンピューター１１３０（Ｂ〜Ｎ）の各々に割り当てられた計算サーバー１１１０のアドレス、対応するセッションＩＤ、ユーザー名、計算サーバー１１１０およびグラフィクス・サーバー１１２０の名称、各計算サーバー１１１０におけるアクティブなセッションの数等も含むことができる。リモート・クライアント・コンピューター１１３０Ａは、この許可を用いて、他のリモート・クライアント・コンピューター１１３０（Ｂ〜Ｎ）の各々に割り当てられたグラフィクス・サーバー１１２０との接続を確立することができる。これらの接続は、図１１の接続１１２５を含むことができる。一旦接続が確立されると、種々のグラフィクス・サーバー１１２０は、他のリモート・クライアント・コンピューター１１３０（Ｂ〜Ｎ）のグラフィクス・データー出力をリモート・クライアント・コンピューター１１３０Ａに送信することができる。リモート・クライアント・コンピューター１１３０Ａは、種々のグラフィクス・サーバー１１２０から受信したグラフィクス出力データーをデコードすることができ、デコードしたデーターをエンド・ユーザーに表示することができる。例えば、リモート・クライアント・コンピューター１１３０Ａは、デコードしたデーターをタイル状に並べて表示することができ、または他のリモート・クライアント・コンピューター１１３０（Ｂ〜Ｎ）と関連する画面の各々をユーザーにぱらぱらとめくらせることができる。更に、リモート・クライアント・コンピューター１１３０Ａは、ユーザー名、対応する計算サーバー１１１０およびグラフィクス・サーバー１１２０の名称等というような、許可において入手可能な他の情報を表示することもできる。他の実施形態では、リモート・クライアント・コンピューター１１３０（Ｂ〜Ｎ）に対応する種々のグラフィクス出力データーを送信するグラフィクス・サーバー１１２０が、種々のグラフィクス出力データーおよび対応するリモート・クライアント・コンピューター１１３０（Ｂ〜Ｎ）についての他の情報を他のリモート・クライアント・コンピューター１１３０Ａに送信するように構成することもできる。したがって、リモート・クライアント・コンピューター１１３０Ａは、リモート・クライアント・コンピューター１１３０（Ｂ〜Ｎ）の画面およびこれらについての情報を表示することができる。

[0104] 図１３は、クライアントに送信するためにグラフィクス・データーを処理する動作手順の一例を示す。この動作手順は、動作１３００、１３１０、１３２０、１３３０、１３４０、１３５０、および１３６０を含む。動作１３００は、この動作手順を開始し、動作１３１０は、リモート・クライアントと計算サーバーとの間に第１接続を確立することを示す。第１接続は、図１１の接続１１０５を含むことができる。動作１３２０は、計算サーバーとグラフィクス・サーバーとの間に第２接続を確立することを示す。代２接続は、図１１の接続１１１５を含むことができる。動作１３３０は、リモート・クライアントとグラフィクス・サーバーとの間に第３接続を確立することを示す。第３接続は、図１１の接続１１２５を含むことができる。動作１３４０は、第１接続を通じてリモート・クライアントからグラフィクス・データーを計算サーバーが受信することを示す。受信されたグラフィクス・データーは、例えば、リモート・クライアントに関連するキーボード打鍵またはマウス・クリックというような、ユーザー・グラフィクス入力を含むことができる。動作１３５０は、受信したグラフィクス・データーを処理し、処理したグラフィクス・データーをグラフィクス・サーバーに第２接続を通じて送ることを示す。受信したグラフィクス・データーの処理は、計算サーバーが受信したグラフィクス・データーを表示コマンドおよびコールに変換することを含むことができる。動作１３６０は、処理したグラフィクス・データーをレンダリングし、キャプチャし、リモート・クライアントに第３接続を通じて送信することを示す。

[0105] 図１４は、前述のように、クライアント・コンピューターに送信するためにグラフィクス・データーを処理するシステム例を示す。システム１４００は、プロセッサー１４１０およびメモリー１４２０を備えている。一実施形態では、プロセッサー１４１０は、図１における論理処理ユニット１０２として実現することができ、一方メモリー１４２０は図１におけるシステム・メモリー２２のコンポーネントの一部または全部を有するものとして実現することができる。更に、メモリー１４２０は、リモート・クライアントへの送信のためにグラフィクス・データーをシステムに処理させるように構成されたコンピューター命令も備えている。ブロック１４２２は、リモート・クライアントと計算サーバーとの間に第１接続を確立することを示す。ブロック１４２４は、計算サーバーとグラフィクス・サーバーとの間に第２接続を確立することを示す。ブロック１４２６は、リモート・クライアントとグラフィクス・サーバーとの間に第３接続を確立することを示す。ブロック１４２８は、リモート・クライアントからグラフィクス・データーを第１接続を通じて計算サーバーが受信することを示す。ブロック１４３０は、受信したグラフィクス・データーを処理し、処理したグラフィクス・データーをグラフィクス・サーバーに第２接続を通じて送ることを示す。ブロック１４３２は、処理したグラフィクス・データーをレンダリングし、キャプチャし、圧縮し、リモート・クライアントに第３接続を通じて送信することを示す。

[0106] 以上で述べた態様は、いずれも、方法、システム、コンピューター読み取り可能媒体、またはあらゆるタイプの製造物(manufacture)で実現することができる。
[0107] 以上の詳細な説明では、例および／または動作図によって、本システムおよび／またはプロセスの種々の実施形態を明記した。このようなブロック図、および／または例が１つ以上の機能および／または動作を含む限りにおいて、このようなブロック図または例の中にある各機能および／または動作は、広い範囲のハードウェア、ソフトウェア、ファームウェア、または事実上そのあらゆる組み合わせによって、個々におよび／または集合的に実現できることは、当業者には理解されよう。

[0108] 尚、本命書において説明した種々の技法は、ハードウェアまたはソフトウェア、あるいはしかるべきときには双方の組み合わせに関して実現できることは言うまでもない。つまり、本開示の方法および装置、あるいはその一部のある種の態様は、フロッピー(登録商標)・ディスケット、ＣＤ−ＲＯＭ、ハード・ドライブ、または他のいずれかの機械読み取り可能記憶媒体というような、有形媒体に具体化されたプログラム・コード（即ち、命令）の形態をなすことができ、このプログラム・コードが、コンピューターのような機械にロードされこの機械によって実行されると、この機械が本開示を実施する装置となる。プログラマブル・コンピューター上におけるプログラム・コードの実行の場合、計算デバイスは通常プロセッサー、このプロセッサーによって読み取り可能な記憶媒体（揮発性および不揮発性メモリーおよび／または記憶エレメントを含む）、少なくとも１つの入力デバイス、および少なくとも１つの出力デバイスを含む。１つ以上のプログラムは、アプリケーション・プログラミング・インターフェース（ＡＰＩ）、再利用可能な制御手段等の使用によって、本開示に関連して説明したプロセスを実現するまたは利用することができる。このようなプログラムは、好ましくは、コンピューター・システムと通信するために、高級手続きプログラミング言語またはオブジェクト指向プログラミング言語で実現される。しかしながら、プログラム（１つまたは複数）は、望ましければ、アセンブリーまたは機械語で実現することもできる。いずれの場合でも、言語は、コンパイル型であってもインタプリタ型であってもよく、ハードウェアの実施態様と組み合わされてもよい。

[0109] 以上、本発明について、その好ましい実施形態を参照して特定的に示し説明したが、以下の特許請求の範囲に明記される本発明の範囲から逸脱することなく、形式および詳細には種々の変更がなされてもよいことは当業者には理解されよう。更に、本発明のエレメントは単数形で記載されること、または特許請求されることもあるが、単数形に限定することが明示的に述べられていない限り、複数形も想定されることとする。

Claims (10)

1. データーを処理するためのシステムであって、
   少なくとも１つの計算デバイスを備え、
   前記計算デバイスは、
   クライアント・デバイスとの第１の接続および少なくとも１つのグラフィクス・デバイスとの第２の接続を確立するステップであって、前記第１の接続は、前記クライアント・デバイスに割り当てられたリモート・セッションに前記クライアント・デバイスを接続する、ステップと、
   前記クライアント・デバイスが前記少なくとも１つのグラフィクス・デバイスへの第３の接続を確立するのを可能にするために、前記少なくとも１つのグラフィクス・デバイスを示す情報を前記クライアント・デバイスに提供するステップであって、前記第３の接続は、前記第１の接続を介して前記クライアント・デバイスから受信されたデーターに応答して、前記クライアント・デバイスへエンコードされたグラフィクス・データーを伝送するように適合される、ステップと、
   前記第１の接続を介して前記クライアント・デバイスからデーターを受信するステップと、
   前記クライアント・デバイスから受信された前記データーを、前記リモート・セッションのランタイム環境内で実行されるアプリケーションによって処理することによって、表示コマンドを発行するステップと、
   前記受信されたデーターに応答して前記アプリケーションによって発行された前記表示コマンドを、前記第２の接続を介して前記少なくとも１つのグラフィクス・デバイスへ送信するステップであって、前記表示コマンドは、前記少なくとも１つのグラフィクス・デバイスによって前記第３の接続を介して前記クライアント・デバイスへ送信されるグラフィクス・データーを生成するのに用いられる、ステップと、
   を少なくとも行うように構成される、
   システム。
2. 前記少なくとも１つの計算デバイスは、少なくとも１つの仮想機械内にインスタンス化される、請求項１に記載のシステム。
3. 前記少なくとも１つのグラフィクス・デバイスは、少なくとも１つの仮想化機械上の少なくとも１つのパーティション内にインスタンス化される、請求項１に記載のシステム。
4. 前記クライアント・デバイスと前記少なくとも１つのグラフィクス・デバイスとの前記第３の接続を確立するステップは、前記少なくとも１つの計算デバイスと前記少なくとも１つのグラフィクス・デバイスの負荷均衡を行うステップを含む、請求項１に記載のシステム。
5. 前記少なくとも１つのグラフィクス・デバイスのうちの１または複数のグラフィクス・デバイスは、多数のクライアント・デバイスに対応するグラフィクス・データーを１つのクライアント・デバイスへ送信するように構成される、請求項１に記載のシステム。
6. グラフィクス・データーを処理するための方法であって、
   複数の計算デバイスと複数のクライアント・デバイスとの間に第１の接続を確立し、前記複数の計算デバイスと複数のグラフィクス・デバイスとの間に第２の接続を確立するステップと、
   前記複数の計算デバイスに、前記複数のグラフィクス・デバイスのうちの対応する１つとの第３の接続を確立するよう命令するステップであって、前記第３の接続は、前記第１の接続を介して前記複数のクライアント・デバイスから受信されたデーターに応答して、前記複数のクライアント・デバイスへエンコードされたグラフィクス・データーを伝送するように適合される、ステップと、
   前記複数の計算デバイスによって、前記第１の接続を介して前記複数のクライアント・デバイスからデーターを受信するステップと、
   前記受信されたデーターを処理することによって、表示コマンドを発行するステップと、
   前記第２の接続を介して前記複数のグラフィクス・デバイスへ前記表示コマンドを送信するステップであって、前記表示コマンドは、前記受信されたデーターに応答してアプリケーションによって発行され、前記アプリケーションは、前記複数のクライアント・デバイスのうちのそれぞれのクライアント・デバイスに対して割り当てられたリモート・セッションのランタイム環境内で実行される、ステップと、
   前記表示コマンドを用いてグラフィクス・データーを生成し、前記生成されたグラフィクス・データーを前記第３の接続を介して前記複数のクライアント・デバイスへ送信するように、前記複数のグラフィクス・デバイスに命令するステップと、
   を含む方法。
7. 前記複数の計算デバイスは、複数の仮想機械内にインスタンス化され、前記複数のグラフィクス・デバイスは、前記複数の計算デバイスと同じ複数の物理計算デバイス上の複数のパーティション内にインスタンス化される、請求項６に記載の方法。
8. 前記複数の計算デバイスは、前記複数のクライアント・デバイスとの複数のリモート・デスクトップ・セッションを実行しており、前記グラフィクス・データーは、ユーザーのリモート・デスクトップ・セッションの少なくとも一部のグラフィクス表現を含む、請求項７に記載の方法。
9. 前記複数の計算デバイスと前記複数のクライアント・デバイスとの間に前記第１の接続を確立し、前記複数の計算デバイスと前記複数のグラフィクス・デバイスとの間に前記第２の接続を確立するステップは、複数のクライアント・デバイス・アドレスを取得して前記取得された複数のクライアント・デバイス・アドレスを前記複数のグラフィクス・デバイスに供給するステップと、複数のグラフィクス・デバイス・アドレスを取得して前記取得された複数のグラフィクス・デバイス・アドレスを前記複数のクライアント・デバイスに供給するステップと、前記複数のクライアント・デバイスおよび前記複数のグラフィクス・デバイスに、前記供給されたアドレスを用いて第３の接続を確立するよう命令するステップと、を含む、請求項６に記載の方法。
10. 命令が格納されたコンピューター読み取り可能記憶デバイスであって、前記命令は、１または複数のプロセッサーによって実行されると、前記１または複数のプロセッサーに、
    複数の計算デバイスと複数のリモート・クライアント・コンピューターとの間に第１の接続を確立し、前記複数の計算デバイスと複数のグラフィクス・デバイスとの間に第２の接続を確立するステップと、
    前記複数のリモート・クライアント・コンピューターのそれぞれが前記複数のグラフィクス・デバイスのうちの対応する１つとの同時の第３の接続を確立することを可能にする情報を前記複数のリモート・クライアント・コンピューターへ送信するステップであって、前記同時の第３の接続のそれぞれは、前記第１の接続を介して前記複数のリモート・クライアント・コンピューターから受信されたデーターに応答して、前記複数のリモート・クライアント・コンピューターへエンコードされたグラフィクス・データーを伝送するように適合される、ステップと、
    前記第１の接続を介して前記複数のリモート・クライアント・コンピューターによるデーターを受信するステップと、
    前記受信されたデーターを処理することによって、表示コマンドを発行するステップと、
    前記第２の接続を介して前記複数のグラフィクス・デバイスへ前記表示コマンドを送信するステップであって、前記表示コマンドは、前記受信されたデーターに応答してアプリケーションによって発行され、前記アプリケーションは、前記複数のリモート・クライアント・コンピューターのうちのそれぞれのリモート・クライアント・コンピューターに対して割り当てられたリモート・セッションのランタイム環境内で実行される、ステップと、
    前記表示コマンドを用いてグラフィクス・データーを生成し、前記生成されたグラフィクス・データーを、前記複数のリモート・クライアント・コンピューターのそれぞれによって確立された前記同時の第３の接続を介して前記複数のリモート・クライアント・コンピューターへ送信するように、前記複数のグラフィクス・デバイスに命令するステップと、
    を実施させる、コンピューター読み取り可能記憶デバイス。

Images