JP5129151B2 - マルチユーザ・ディスプレイ・プロキシ・サーバ - Google Patents

Description

本発明は、一般的には、マルチユーザ・ホスト・コンピュータ・システムに関し、更に特定すれば、リモート・ユーザのために端末サービスをサポートするプロキシ・サーバの利用に関する。

効率的なマルチユーザ・ホスト・コンピュータ・システムを開発することは、現在のシステム設計者及び製造業者にとって重要な目的である。
従来のコンピュータ・システムは、出力を直接一人のユーザに表示するために、ローカル・ディスプレイ・デバイスを利用することができる。ローカル・ディスプレイ・デバイスは、通例、コンピュータ・システムに近接して位置付けられる。これは、ディスプレイ・デバイスをコンピュータ・システムの出力に電気的に結合する種々の物理的接続によって強いられる制約のためである。コンピュータ・システムによっては、第２ディスプレイ・デバイスをサポートすることができる場合もあるが、物理的接続のために同様の近接制約がある。

リモート・ユーザ（遠隔地のユーザ）の場合、しかるべき目視場所及びホスト・システムに対するネットワーク接続を選択するという更に別の柔軟性も必要となる。例えば、会社環境では、業務上、ホスト・コンピュータの全てを、物理的な安全性並びに空調及び電力バックアップ・システムのような環境管理双方を有する安全な中央「コンピュータ・ルーム」に保有しておきたい場合がある。しかしながら、ユーザは、「コンピュータ・ルーム」の外部に位置する彼らの事務所及び机からホスト・コンピュータ・システムを利用する必要がある。

今日の典型的な事務所環境では、パーソナル・コンピュータと、物理的にユーザの所在地に位置する、増々少なくなる機能のクライアントとを含む。これらのパーソナル・コンピュータ及び少機能クライアントは、格納、ファイル提供、ファイル共有、ネットワーク管理、及び種々の管理運営サービスのために集中システムを有するネットワーク上で動作する。当初、システムは、コンピュータ・システムと関連のあるディスク・ストレージの全てを集中させ、一方、ユーザは彼らのローカル・デスクトップ上でアプリケーションをラン（実行）させていた。最近になって、セキュリティの便益、運用コスト削減、及び集中制御に対する一般的な要望を認識し、パーソナル・コンピュータ及び薄いクライアントは、サーバ上でアプリケーションをランさせるサーバ基本計算（ＳＢＣ：Server Based Computing）ソリューションにおけるリモート端末（ＲＴ）として動作することが可能となっている。

ＳＢＣ環境におけるＲＴのための従前からの手法は、ホスト・システムが、Microsoft社のRemote Display Protocol（ＲＤＰ）のような、ある形式のサーバ対クライアント通信交換を用いるためにあった。ＲＤＰはそれ自体のビデオ・ドライバをサーバ上で用い、ＲＤＰプロトコルを用いてレンダリング情報をネットワーク・パケットに組み立て、これらをネットワークを通じてクライアントに送る。クライアントは、レンダリング・データを受信し、パケットを解釈して、対応するMicrosoft Win32 Graphics Device Interface （ＧＤＩ）ＡＰＩコールを得る。クライアント・キーボード及びマウス・コマンドをサーバに再送出し、ローカル・オーディオ及びローカル・クライアント・ドライブを管理するための支援も含まれる。

ホスト・システムとクライアントとの間における通信を強化するために、他のシステムはＲＴの性能を向上させるためにホスト・コンピュータの主ＣＰＵを用いている。これは、少機能のクライアント及びリモート・クライアントとしての従前からのＰＣ双方に対して行われている。このような手法は、一度に一人のユーザのみをサポートするホスト・システムには有効であった。しかしながら、マルチユーザ・システムでは、ホストにおいて主ＣＰＵを用いて任意の一人のユーザに対して性能を向上させる手法には、大きな限界がある。主メモリ及びＣＰＵサイクルのような、一人のユーザの最適化のために用いられる計算資源は、追加のユーザの作業負荷を支援する能力を低下させる虞れがある。

１台のホスト・コンピュータから多数のユーザを効率的に支援することができれば、コストを低減することができる。典型的な事務所環境では、各々が彼らのコンピュータを同時にそして同様に用いることは殆どなく、いずれか一人のユーザが彼らのコンピュータの計算資源全てを用いることも殆どない。したがって、例えば、１００の事務所を有する会社であっても、一度に６０人のユーザをサポートするシステムがあればよい。しかしながら、このようなシステムは、１０人のユーザをサポートするように設計することもでき、十分な計算スループットを与えて、彼らが各々彼ら自身のホスト・コンピュータを有するような外観を与えることができる。分散型の事務所環境では、集中マルチユーザ・システムを、様々な帯域幅のリンクを通じて接続し、それぞれの時間帯の異なる作業時間中に世界の異なる地区における場所でＲＴをサポートすることができる。

サーバ・ベースの計算は、ＲＴサービスをユーザの端末においてサポートするだけのサーバ上でユーザのアプリケーションが実行され、多数のユーザに対して計算資源の割り当て効率を高める別の方法である。ＳＢＣによって、ホスト・システムは、メモリやＣＰＵサイクルのような共有資源を、マルチユーザ動作環境において動的に割り当てることが可能になる。ＳＢＣシステムは、マルチユーザ・オペレーティング・システムの技法、仮想マシーン（ＶＭ）、負荷均衡及びその他の手段を用いて、異なるユーザに異なるレベルの性能及び資源へのアクセスを、多数の判断基準に基づいて付与することができる。ＳＢＣ資源を割り当てるために、異なる優先方式を用いることができる。ＳＢＣは、データ・セキュリティを高め、編成、災難回復力強化及び業務継続に対するサポートを集中し、組織全体におけるデータ記憶要件を低減することができる。

ブレード(blade)・ベースのシステムは、スケーラブル・マルチユーザ・ホスト・システムに合った効果的なアーキテクチャを実現する。ブレード計算機能の区分、Ｉ／Ｏ機能、バックプレーン・アーキテクチャ、及び切換は、全て、ブレードに基づくサーバの設計では重要である。各ブレードは、完全なコンピュータの機能を構築することができ、あるいはブレード・サーバはブレード間で重要な機能を共有することができる。多数のプロセッサ・コアを含むことによってＣＰＵが増々その性能を向上させていくにしたがって、一人のユーザを１つのブレードに制限することは、経済的な意味を減少させる。ブレード・システムにおける各ブレードを離れて監視する必要がある場合もある。ブレード・システムの多機能性のために、ブレードのラックは、異なる作業負荷に最も良く合うように構成しなければならない。

図１は、１〜８まで（１０２、１０４、１０６、１０８、１１０、１１２、１１４及び１１６）番号を付したブレード、並びにスイッチ１２０及び１２２、スイッチの各々を通過するパスを含む、代表的な従来技術のマルチブレード・システム・レベル・アーキテクチャ１００を示す。また、スイッチは、それらの間及びリンク１２４へのパスも含むことができ、リンク１２４によって、更に、ブレードのラックを別のブレードのラック又は他の何らかのサブシステムに拡大することができる。図１のブレードの数を変更することもでき、各ブレードは、プロセッサ・ブレード、Ｉ／Ｏブレード、切換ブレード、又はこれら３つの何らかの組み合わせとすることもできる。Ｉ／Ｏブレードは、ブレード４ １０８及びパス１８０、並びにブレード８ １１６及びパス１９０によって例示するように、それら自体の外部インターフェースを含むことができる。外部インターフェースの例には、ファイバ・チャネル及びｉＳＣＳＩのような非ネットワーク・インターフェース、又はイーサネット及び１０Ｇイーサネットのようなネットワーク・インターフェースを含むことができる。

スイッチ１ １２０及びスイッチ２ １２２のスイッチ・マトリクスの例は、各スイッチから各ブレードへの接続１４０及び１４２を示す。スイッチ毎の物理的又は論理的トランスポートの形式は同一でも異なってもよい。パス１４４は、スイッチ１２０及び１２２を一緒に接続又はブリッジすることができる。スイッチ及び接続の組み合わせをスイッチ・ファブリック１５０と呼び、各ブレード上に分散すること、バックプレーンの一部とすること、切換ブレード上に実現することができ、あるいはこれら３つの組み合わせを伴うこともできる。切換ファブリックのパスは、単一方向、双方向、又は組み合わせでもよい。各ブレードは、いずれの数のスイッチにでも接続することができ、ブレード機能の一部として、異なるスイッチに対するブリッジ機能を含むことができる。更に進んだシステムでは、フル・メッシュ・トポロジ(full mesh topology)ファブリックを含むことができ、冗長性を有することができる。

スイッチ・ファブリック１５０に用いられる接続の例には、Peripheral Component Interconnect（ＰＣＩ）Express、10Ｇ Attachment Unit Interface （ＸＡＵＩ：１０Ｇ取り付けユニット・インターフェース）、Infiniband、RapidIO、StarFabric、Advanced Switching Interconnect （ＡＳＩ：高度交換相互接続）、Gigabit Ethernet（ギガビット・イーサネット）、Fiber Channel（ファイバ・チャネル）、並びにその他の電気又は光相互接続の１つ以上のチャネルが含まれる。場合によっては、各ブレードの機能チップが直接ファブリック・インターフェース１３０を含むこともある。別の場合には、ブレードがファブリック・インターフェース・チップ又はブリッジ・チップを含み、これらがインターフェース処理を実行することも可能である。各ブレードにおけるファブリック及びブリッジ・チップは、システム・スイッチの１つ以上に接続することができ、スイッチ間における追加のブリッジ機能を一体化することができる。

しかしながら、ブレード・ベースのマルチユーザ・ホスト・コンピュータが、組織が有する可能性がある種々のサーバ・ソフトウェア及びウェブに基づくアプリケーション並びに種々のＲＴデバイスに対して豊富なアプリケーション性能を効果的に管理、制御、及び配給するためには、複雑さを高めなければならないこともある。ブレード・ベースのマルチユーザ・ホスト・サーバが、並外れた計算及び表示性能を有し、多数のリモート・ユーザを一層効率的にサポートすることを可能にする解決策が求められている。

本発明は、対話式グラフィクス及びビデオが可能な１つ以上のリモート端末（ＲＴ）を含み、アプリケーションを全体的に管理し、サーバに基づく計算を実行するブレード・ベースのマルチユーザ・コンピュータ・システムの効率的なアーキテクチャを提供する。各ＲＴは、それ自体のキーボード、マウス、及びディスプレイを有し、更に他の周辺デバイスを有することもできる。ＲＴは、個々のユーザに、サーバ上で利用可能なアプリケーションへのアクセス、及び豊富なグラフィカル・ユーザ・インターフェースを設ける。マルチユーザ・コンピュータ・システムは、マルチユーザ・オペレーティング・システムをランさせることができ、単一ユーザ・オペレーティング・システムの仮想化インスタンシエーション(virtualized instantiation)をランさせることができ、多数のユーザのためにウェブ・サーバ・エンジンをランさせることができ、プロキシ・サーバをランさせることができ、あるいはその何らかの組み合わせをランさせることができる。

第１の好適な実施形態では、プロセッサ・ブレードが、ＲＴからのリモート管理及び制御を可能にするベースボード管理コントローラ（ＢＭＣ）を含む。センサ及びステータス情報を提供することに加えて、ＢＭＣは、キーボード、ビデオ及びマウス（ＫＶＭ）能力を含むので、システム・アドミニストレータは、あたかも彼がローカルにブレードに接続されているかのように、プロセッサ・ブレードに遠隔地からアクセスすることができる。ＢＭＣ及びＫＶＭ機能は、ＣＰＵ及びボードの基本動作に追加の実行時変更を行うことなく、「帯域外」動作をサポートするので、実行時の診断を最も効率的に行うことができる。リモートＫＶＭの表示に関する機構は、グラフィクス・プロセッサ及び表示データ・エンコーダがサポートする。これらは、選択的更新、及び必要であれば、種々の形態の表示データ圧縮を利用する。表示データ・エンコーダ機能をＴＳＡ４２４に統合してもよく、又は専用データ・エンコーダ７５２とし、ＧＰＵ−ＴＳＡに組み合わせてもよい。

第２の好適な実施形態では、端末サービス・ブレード（ＴＳＢ）がソフトウェア、グラフィクス・プロセッサ、及びデータ・エンコードの組み合わせを利用して、ＲＴ毎に仮想表示環境を創造することによって、多数のＲＴをサポートする。ＲＴとの通信のための最も馴染み深い方法では、カプセル化したグラフィクス・コマンドを送ること、又はエンコードしたサブフレーム・データを送ることを含む。ＲＴを管理するソフトウェアは、主ホスト・プロセッサ・ブレード上、ＴＳＢのＣＰＵ、端末サービス・アクセレレータ（ＴＳＡ）上、ＲＴ上、又はその組み合わせの上でランすることができる。ＲＴ毎に選択的更新を、ソフトウェアで、あるいはマルチユーザ・グラフィクス・プロセッサ・ユニット（ＭＵ−ＧＰＵ）又は組み合わせたＴＳＡ−ＧＰＵにおけるハードウェアの補助によって調整することができる。グラフィクス・プロセッサは、提案したVESA Digital Packet Video Link（ＤＰＶＬ）規格、又はサブフレームのヘッダ、ステータス・ビット及び署名の何らかの組み合わせを用いた改良方法に従うことができる。他の改善策では、ＰＣＩエクスプレス又はその他のバスを、ＤＶＩの代わりに、出力データのために用い、追加のデータ・エンコードをグラフィクス・プロセッサ内部又はグラフィクス・プロセッサに取り付けたエンコーダによって行い、ソフトウェアは１つ以上のグラフィクス・プロセッサをマルチユーザ・サポートのために利用する。

ＴＳＢは、クライアント終了を含む多様なレベルのプロキシ応対(proxy serving)を行うことができ、プロセッサ・ブレード上でランするＲＤＰホストがＴＳＢ上で走るプロセスを唯一の既知のクライアントであることを考慮するように、完全に多数のＲＤＰクライアントを列挙するためである限り動作することができる。この方法では、ＴＳＢはホスト・プロセッサが認識しない、完全に独立したインターフェースをＲＴに対して作成することができる。ＴＳＢとＲＴとの間におけるこの主のインターフェースは、分割プロキシの形態とするとよい。分割プロキシとして、ＴＳＢ及びＲＴは、私的チャネルを通じて通信し、このチャネル上では、ＲＤＰ又はウェブ・ブラウザ・プロトコルのような、より一般的なプロトコルを用いて可能なよりも、更に効率的に通信することができる。

更に効率を高めるためには、プロセッサ・ブレードは、追跡（トラッキング）ソフトウェアをランさせることができる。追跡ソフトウェアは、ＴＳＡと組み合わせて、ビデオ再生のような機能を傍受(intercept)することができる。ホストＣＰＵにビデオ・デコードをローカルに実行させ、ＲＴに伝送するためにビットマップを供給させる代わりに、ＴＳＡは、ＣＰＵによるデコードの前に、ビデオ・データ・ストリームを傍受することができ、ネイティブなビデオ・ストリーム、あるいはトランスコード又はレート変更したバージョンのような、修正バージョンを、目標のＲＴに伝達することができる。ＲＴへの通信には、標準的なＲＤＰチャネルに加えて、その他の私的チャネルを採用することができるが、その場合でもＲＤＰプロトコルの中で管理する。

各実施形態において、グラフィクス動作及び選択的更新プロセスの後、データをエンコードし、カプセル化して、ネットワーク・レディ(network ready)更新パケットとする。ネットワークＩ／Ｏブレード、ネットワーク・プロセッサ、又は更に単純なネットワーク・コントローラと共に動作するＣＰＵが、有線及び／又は無線（ワイヤレス）ネットワークを通じて、グラフィクス・パケットをＲＴに送信する。ＫＶＭの構成によっては、ＢＭＣがネットワーク処理を実行し、更新パケット動作によってプロセッサ・ブレードＣＰＵを中断させないようにする場合もある。別の構成では、ＣＰＵは保護的区分のために「仮想技術」を利用し、ユーザ・タスクを含むオペレーティング・システムの動作及びＭＢＣの帯域外管理タスクの双方を実行する。ＢＭＣは、システムにおける別のネットワーク・コントローラ又はネットワーク物理レイヤ（ＰＨＹ）と通信することができる。各ＲＴシステムは、その表示を意図するグラフィクス・パケットをデコードし、フレーム更新を管理し、表示画面に必要な処理を実行する。ネットワーク送信中に失われたパケットを隠蔽する等の他の機構は、リモート・ディスプレイ・システムによって管理する。新しいフレーム更新がない場合、リモート・ディスプレイ・コントローラは、直前のフレームからのデータによって、表示画面をリフレッシュする。

種々のネットワーク・システムはネットワーク情報を種々の有線及びワイヤレス・ネットワーク接続からＴＳＢにフィードバックすることができる。ＴＳＢは、ＲＴ更新を生成する種々の処理ステップに影響を及ぼすためにネットワーク情報を用い、ネットワーク・フィードバックに基づいて、異なるＲＴに合わせてフレーム・レート及びデータ・エンコードを様々に変更することができる。加えて、ノイズが多い送信チャネルを有するネットワークを含むシステムでは、エンコード・ステップをフォワード・エラー・コレクション（前進誤り補正）保護と組み合わせて、送信チャネルの特性に合わせて送信データを用意することができる。これらのステップの組み合わせは、ＲＴの各々について、低いレイテンシで最適なフレーム・レートを維持する。ＴＳＡ及びＴＳＡ−ＧＰＵは、別個のサブシステムとして実施することができ、あるいはネットワーク・プロセッサ、セキュリティ・プロセッサ、ＸＭＬアクセレレータ、ｉＳＣＳＩプロセッサ、又はこれらのあらゆる組み合わせというような、その他のオフロード及び加速処理と組み合わせることもできる。

したがって、少なくとも以上の理由により、本発明はシステムの相互動作性及び機能性を容易に得るために、種々の異質なコンポーネントを利用する柔軟性の高いブレードに基づくマルチユーザ・コンピュータ・システムを効果的に実現する。言い換えると、本発明は、強化したブレード・ベースのマルチユーザ・サーバを実現する。

本発明は、リモート端末に対するサポートを備えた、ブレードに基づく（ブレード・ベースの）マルチユーザ・コンピュータ・システムの改良に関する。開示する実施形態はブレード・ベースのマルチユーザ・コンピュータ・システムに関するが、同じ原理及び特徴は、他の形式の単一及びマルチユーザ・システム、並びに他の形式のリモート端末にも同様に応用することができる。

ブレード・ベースのマルチユーザ・コンピュータ・システム１００は、「ホスト１００」とも呼ばれ、リモート端末における多数のユーザをサポートするように設計されている。リモート端末については、以下で図３を参照して説明する。各ＲＴは、ホスト１００を時間共有することができ、ホスト１００はあたかもそれら自体のローカル・コンピュータとして機能し、ローカル・コンピュータ上で達成することができる同じ種類のユーザ操作で、あらゆる種類のグラフィクス、テキスト、及びビデオ・コンテンツを完全にサポートすることができる。パス１８０及び１９０は、ネットワーク接続を用いた場合に、図２のパス２９０及び図４のパス４９０に対応し、図３のネットワーク・パス３９０に接続することができる。ＲＴ接続に加えて、ホスト１００は、リンク１２４を通じて、ＷＡＮ、記憶サブシステム、他のホスト、あるいはGigE、10G Ethernet、iSCSI、Fiber Channel（ＦＣ）、Fiber Channel IP（ＦＣＩＰ）あるいはその他の電気又は光接続の形態をなることができる種々の他のデータ中心接続部に接続することができる。ホスト１００は、種々のマルチユーザ・オペレーティング・システム（ＯＳ）をサポートすることができ、また単一ユーザＯＳを仮想化するソフトウェアを、プロセッサ・ブレードの１つ以上において展開することができる。Citrix又はWindows Serverのようなオペレーティング・システムは、マルチユーザＯＳとして設計されている。Windows XPは、具体的には同時に多数のユーザ用には設計されていないが、VMWARE又はXenSource、あるいはマルチユーザＯＳのように素早く見えるようにユーザ切換を実行するその他の手段のような、任意の下位レベル仮想化ソフトウェアの補助によって、このような構成において用いることができる。異なる管理制御によって、ＲＴ及びプログラムを統計的に又は動的にプロセッサ間で移動させることが可能になる。負荷均衡は、ＯＳによって、プロセッサ毎に実行することができ、あるいはシステムが多数のプロセッサに跨って負荷均衡を実行することもできる。また、ホスト１００は、ある種のウェブ・サーバをランさせ、ウェブ・ベースのインターフェースを通じて多数のユーザをサポートすることができる。ホスト１００は、種々のＲＴに対してプロキシ・サーバのように機能し、アプリケーション・サーバ又はウェブ・サーバと通信することができる。

図２は、ブレード・ベースのマルチユーザ・サーバ・システム１００のブレード１０２〜１１６の１つとしての役割を果たすことができる、プロセッサ・ブレード２００の一実施形態のブロック図である。各ブレード２００は、それ自体ホスト・コンピュータであってもよく、あるいは、多数のブレードを一緒にラックに収容して、能力の高いホスト・コンピュータを作成することもできる。ホストが有するプロセッサ・ブレード、Ｉ／Ｏ処理及びＣＰＵが多い程、多くのユーザを同時にサポートすることができる。プロセッサ・ブレード２００の基本的コンポーネントは、好ましくは、マルチＣＰＵコンプレックス２０２、バス・ブリッジ・コントローラ２０４、ＰＣＩエクスプレスのような主システム・バス２０６、ローカルＩ／Ｏ２０８、主ＲＡＭ２３４、スイッチ、バックプレーン及びその他のブレードに接続するファブリック・インターフェース（ＦＩ）１３０、並びにオプションでベースボード管理制御（ＢＭＣ）サブシステム８００を含む。

スイッチ・ファブリック１５０のトランスポート及び物理層インターフェースの形式に応じて、ファブリック・インターフェース（ＦＩ）１３０は、重要な処理を含む場合がある。例えば、ファブリック・インターフェース１３０は、１０Ｇイーサネット・プロセッサ（図示せず）を含む場合があり、このプロセッサは、ローカルに発生したパケットのため及びＡＳＩファブリック・インターフェースのために必要なパケット・レベルのフィルタリング及び処理の双方を全て実行する。このようなファブリック・インターフェース・プロセッサは、外部ＲＡＭ２３０を必要とすることもあり、十分な内部ストレージを有する場合もある。ネットワーク物理層インターフェース（ＰＨＹ）をＦＩプロセッサと一体化してもよく、あるいは外部ＰＨＹコンポーネントを利用してもよい。ローカルＩ／Ｏ２０８及びローカルＩ／Ｏ接続２９０は、この同じＦＩプロセッサによって制御することができる。加えて、ブリッジ・コントローラ２０４を通じてシステム・バス２０６とインターフェースする代わりに、ファブリック・インターフェース１３０が直接システム・バス２０６に取り付けられてもよい。

システムの一例では、スイッチ１ １２０及び関連するパス１４０は、ＰＣＩエクスプレス・パケットのトンネリング(tunneling)を許容するＡＳＩバス・プロトコルを利用する。スイッチ２ １２２及び関連するパス１４２は、ＸＡＵＩ型バスとするとよく、記憶及びネットワーク構築に対して一層最適化することができ、１０Ｇイーサネット・プロトコルを利用することもできる。このシステムは、主に、異なるプロセッサ・ブレード間の通信にはＡＳＩバスを利用し、ネットワーキング及び記憶ブレードとの通信にはＸＡＵＩバスを利用することができる。各ブレードは、１つのインターフェース、双方のインターフェースを含むことができ、双方のインターフェースも、２系統のバス間においてトラフィック転送をブリッジ（橋架）する能力を含む。

図２のマルチＣＰＵコンプレックス２０２は、１つ以上のプロセッサ・チップを含むことができ、各々は、多数の同時スレッドを実行することができる１つ以上のコア（図示せず）を有する。各レベルにおいて、各ＣＰＵコアは、専用キャッシュ・メモリを含み、あるレベルにおいて、多数のＣＰＵがキャッシュ・メモリを共有することができる。マルチＣＰＵコンプレックス２０２は、ＲＡＭ２３４を独立して制御及びアクセスすることができ、あるいはＲＡＭ２３４へのアクセスを実行するためにブリッジ・コントローラ２０４を利用することもできる。他の構成では、マルチＣＰＵコンプレックス２０２が直接、主システム・バス２０６にインターフェースする（図示せず）ことができる。

ローカルＩ／Ｏ２０８は、種々のＩ／Ｏインターフェース及び制御を、外部インターフェース２９０のため及びパス２１０を通じてプロセッサ・ブレード２００の内部に位置するリソースのために、含むことができる。記憶及びネットワーク構築等の主要なＩ／Ｏ機能は、各プロセッサ・ブレード２００上に含めてもよいし、スイッチ・ファブリック１５０を通じてあるいは他の専用Ｉ／Ｏブレードをサポートしてもよい。スイッチ・ファブリックの物理及び論理接続に対する選択に応じて、インターフェース１４０及び１４２を直接ブリッジ・コントローラ２０４に一体化してもよいし、ファブリック・インターフェース１３０をチップとして用いてもよい。

各プロセッサ・ブレード２００は、事実上「コンピュータ・システム」であると考えられるので、システムを観察し管理するやり方を備えることは非常に望ましい。ホスト１００が特殊なコンピュータ室の中に位置する場合があるので、リモート端末（ＲＴ）３００からシステムを観察及び管理できるようにすることが望ましい。ＲＴは、特別に設計された少機能のクライアントとすることができ、あるいは、管理機能のためには、一般に、管理ソフトウェアをランさせるコンピュータである。あるいは、ＲＴはブラウザ型ソフトウェアを含み、管理機能を実行することもできる。プロセッサ・ブレード２００は、ブラウザ・ベースの管理のためにユーザ・インターフェースを設けるウェブ・サーバを含むこともできる。

プロセッサ・ブレード２００の管理運営を行っているがリモート・ユーザからの作業負荷の下ではない場合、マルチＣＰＵコンプレックス２０２の主ＣＰＵは、ＲＴと通信するために使用可能である。しかしながら、種々の環境状態を監視するため、そしてプロセッサ・ブレード２００がリモート・ユーザからの作業負荷を実行している間、これを観察及び管理するためには、図８において詳細を示すベースボード管理制御（ＢＭＣ）サブシステム８００を含むことが望ましい。

ＢＭＣ８００における別個のＣＰＵの代替又は付属として、２０２における主ＣＰＵは仮想化技術を用いて、管理機能をオペレーティング・システム及びユーザ機能から隔離することができる。マルチコアＣＰＵ２０２においては、特定のコアをこのような管理機能に専用とすることができるが、適正に設計されたＣＰＵは、Intel Vanderpool VT技術のようなハードウェアを含み、タスク又はスレッドが走っているコアがどれであるかには無関係に、これらを互いから隔離することを可能にする。したがって、１つのＣＰＵコアが同時に帯域外管理機能をサポートするための保護仮想管理マシーン・モードをランさせ、更に種々のオペレーティング・システム及びユーザ・タスクをサポートするためにオペレーティング・システムの仮想マシーン・モードをランさせることができる。

ＣＰＵコアの異なる仮想マシーンは、各々、ＢＭＣ８００の異なる態様と共に動作することができる。好適な実施形態では、ＫＶＭ２１２を有するＢＭＣは、ＴＳＡ−ＧＰＵ７００のＭＵ−ＧＰＵ４１２のようなローカル・グラフィクス・プロセッサを含み、仮想マシーン・モードでランしている標準的オペレーティング・システムのために表示処理を実行する。リモートＫＶＭ動作については、リモート・アドミニストレータがプロセッサ・ブレード２００の帯域外管理を観察又は実行したい場合がある。帯域外リモート管理運営を実行する際に補助するために、ホストＣＰＵ２０２の保護仮想管理マシーン・モードを用いることができる。リモートＫＶＭ管理運営は、同じローカル・グラフィクス・プロセッサ・ディスプレイに、帯域外ネットワーク・インターフェースからアクセスすることを含むこともある。このようなグラフィクス・プロセッサ・ディスプレイへのアクセスは、図７に詳細を示すＴＳＡ−ＧＰＵ７００の更に進んだ特徴を利用することができる。別の実施形態では、ホストＣＰＵ上の保護仮想管理マシーン・モードを用いる代わりに、ＫＶＭ２１２を有するＭＢＣ内部にある別個のＣＰＵ８０８を、帯域外リモート管理運営を管理するために用いる。

図３は、本発明の一実施形態によるリモート端末３００のブロック図であり、好ましくは、表示画面３１０、ローカルＲＡＭ３１２、及びリモート端末システム・コントローラ（ＲＴＳＣ）３１４を含むが、これらに限定されるものではない。ＲＴＳＣ３１４は、キーボード、マウス、及びＩ／Ｏ制御サブシステム３１６を含む。Ｉ／Ｏ制御サブシステム３１６は、マウス３１８、キーボード３２０、及びオーディオを再生するスピーカ又は種々のデバイスをサポートすることができるユニバーサル・シリアル・バス（ＵＳＢ）接続部のような、その他の雑多のデバイスに対応する接続部を有する。バイオメトリックス又はセキュリティ・カードを含む安全確保手段によるユーザ認証をサポートするためのその他の一体又は周辺接続部も、含むことができる。接続部は、ＰＳ／２様式のキーボード又はマウス接続部のような単一目的専用とすることも、あるいはＵＳＢのように汎用性を高めることもできる。別の実施形態では、Ｉ／Ｏはゲーム・コントローラ、ローカル・ワイヤレス接続部、ＩＲ接続部を含むことができ、あるいは接続部を全く含まないことも可能である。また、リモート端末システム３００は、ＤＶＤドライブのようなその他の周辺デバイスも含むことができる。

本発明の実施形態の中には、リモート端末システム３００において外部入力を全く必要としない場合もある。このようなシステムの一例は、小売店又は電子ビルボードであり、異なる表示が異なる場所で利用可能であり、種々の情報及び娯楽情報を示すことができる。各ディスプレイは独立して動作することができ、種々の要因に基づいて更新することができる。また、同様の安全確保システムが、銀行における情報キオスクや現金自動預け払い機（ＡＴＭ）のような、タッチ・スクリーン入力を受け入れる数個のディスプレイを含むこともできる。カジノ用ゲームマシーンのような、その他の安全確保システムも、この種のＲＴに基づくことができる。

図１のホスト１００は、各ブレードからのネットワーキング・インターフェース（例えば、１８０、１９０）を含むことができ、あるいは共有ネットワーク・コントローラを含むこともできる。いずれの場合でも、ネットワーク接続がホスト１００からＲＴ３００の入力３９０まで確立される。ネットワーク・コントローラ３３６は、ネットワーク・パス３９０上で安全確保プロトコルをサポートする。ネットワーク・パス３９０は、有線又は無線とすることができ、ネットワーク上を移動するデータは、鍵（キー）交換によって暗号化することができる。共通ネットワークの一例に、ある種のイーサネット、好ましくは、ギガビット・イーサネットをランさせるＣＡＴ５ワイヤリングのようなイーサネットがあり、Ｉ／Ｏ制御パスは、標準的なトランスポート制御プロトコル及びインターネット・プロトコル（ＴＣＰ／ＩＰ）又はＵＤＰ送信と組み合わせた軽量ハンドシェーキングの何らかの形態のような、イーサネットをサポートするプロトコルを用いることができる。リアル・タイム・ストリーミング・プロトコル（ＲＴＳＰ）及びリアル・タイム転送プロトコル（ＲＴＰ）のような業界の成果を、リアル・タイム制御プロトコル（ＲＴＣＰ）と共に用いてパケットの転送をブリッジすることができ、更に再送信プロトコルを追加することによって、一層強化することができる。layer 3 DiffServ Code Points （ＤＳＣＰ）、Digital Living Network Alliance（ＤＬＮＡ）の一部としてのＷＭＭプロトコル、Microsoft Qwave、uPnP、QoS、及び802.1Pのような、サービス品質（ＱｏＳ）成果を用いることに関するその他の最新成果も、既存のネットワーク規格を用いる強化方法である。

Ｉ／Ｏデバイスをサポートするためのパケットに加えて、ネットワークは表示に必要な、カプセル化及びエンコードした表示コマンド及びデータも搬送する。ＣＰＵ３２４は、ネットワーク・コントローラ３３６、２Ｄ描画エンジン３３２、３Ｄ描画エンジン３３４、データ・デコーダ３２６、ビデオ・デコーダ３２８、及びディスプレイ・コントローラ３３０と調整して、表示画面３１０上にローカルにレンダリング及び表示される可能性があるあらゆる形式の仮想データ表現をサポートする。ＲＴが表示処理ブロックの任意特定の組み合わせも含む必要はない。特別に少機能のＲＴであれば、表示処理を行うＣＰＵを有するディスプレイ・コントローラ３３０だけしか含まないこともあるが、少なくとも１種類のデコーダ又は描画エンジンを有する可能性の方が高い。

種々の処理エレメントが、フレーム全体を表すパケット、又は表示データの種々のサブフレームを表すパケットをデコードすることができる。好適な一実施形態では、パケットは、ディスプレイの固定位置に対応するエンコード表示データの種々のスライスを含む。ＣＰＵ３２４は、パケットを受信し、パケットのヘッダ情報を読み取ることによって、パケットが意図する表示のしかるべき場所を決定する。データ・デコーダ３２６のようなしかるべき資源を用いて、データのスライスをデコードし、デコードしたデータを、表示メモリの中のしかるべき位置に転送する。データ・デコーダ３２６は、デコードしたデータを直接表示メモリ位置に生成するように設定することができ、あるいはデータを別のエリアにデコードし、２Ｄ描画エンジン３３２、ＣＰＵ３２４、又はその他の手段によって、意図する位置に転送することもできる。

最初に、ローカル・フラッシュ・メモリ（図示せず）からブートし、追加の情報をホスト１００によってネットワーク１９０／３９０を通じて提供することにより、ＲＴ３００を初期化することができる。ＲＴの初期化シーケンスの間、ＲＴＳＣ３１４と表示画面３１０との間の接続は、Display Data Channel（ＤＤＣ：表示データ・チャネル）インターフェース、Extended Display Identification Data （ＥＤＩＤ：拡張表示識別データ）、及び表示モニタの能力を特定するその他の拡張子のような規格を利用して、逆方向又は双方向モードで用いることができる。キーボード、マウス、及びＩ／Ｏコントローラ３１６を通じたＵＳＢ接続も、表示画面３１０への接続において用いることができる。次いで、利用可能な解像度及び制御のような情報をＣＰＵ３２４によって処理する。システム３００は、ホスト１００と通信することができるuPnPのようなプロトコル又はその他の発見メカニズムを実装することができる。その初期化通信の間、ＣＰＵ３２４は、表示モニタ情報を含むＲＴ情報をホスト１００に提供することができるので、各ＲＴをホスト側でインスタンス化することができる。

初期表示画面は、フラッシュ・メモリ又はホスト１００のいずれからのものでもよい。第１フレーム全体の表示データに続いて、ホスト・コンピュータ２００は、表示更新ネットワーク・ストリームの一部として、ネットワーク３９０を通じて、部分的なフレーム情報だけを送ればよい。表示の画素が直前のフレームから全く変化しない場合、ディスプレイ・コントローラ３３０は、ローカルＲＡＭストレージ３１２からの直前のフレーム内容によって表示画面３１０をリフレッシュすることができる。表示画面３１０が、ＤＶＩのようなケーブルによって接続されている場合、ＨＤＣＰがＤＲＭを有するコンテンツを再生するための要件となることもある。加えて、ＲＴＳＣ３１４は、種々の暗号鍵が決してチップの外部には露出されない、高度に安全な処理環境を提供するように設計することもできる。更に安全を確保した実施形態においては、解読したコンテンツ・データがチップ外部に出ていくことは決してない。このような安全を確保したシステムを達成するために、ＲＴＳＣ３１４は、ホスト１００及び表示画面３１０によって行う鍵交換とは独立して、ローカル暗号方法を利用するとよい。

表示の更新は、ネットワーク・ストリームを通じて送られ、カプセル化２Ｄ描画コマンド、３Ｄ描画コマンド、エンコード表示データ、又はエンコード・ビデオ・データで構成することができる。ネットワーク・コントローラ３２６は、ネットワーク表示ストリームを受信し、ＣＰＵ３２４は、暗号化ヘッダから、機能ユニット３３２、３３４、３２６及び３２８の内どれが、そのパケットに必要とされるか判断する。機能ユニットは、画像データをデコードし、ＲＡＭ３１２のしかるべきエリアを新しい画像で更新するために必要な処理ステップを実行する。次のリフレッシュ・サイクルの間、ディスプレイ・コントローラ３３０はこの更新フレームを表示画面３１０に用いる。

ディスプレイ・コントローラ３３０は、現在の画像フレームの表現をＲＡＭ３１２からディスプレイ３１０に転送する。通常、画像は、表示の準備ができたフォーマットでＲＡＭ３１２に格納されているが、ＲＡＭのコストが問題となる場合、画像又は画像の一部をエンコードしたフォーマットで格納することもできる。外部ＲＡＭ３１２を、リモート端末のシステム・コントローラ３１４内部にある大型バッファによって置き換えてもよい。また、ディスプレイ・コントローラ３３０はＲＡＭ３１２に格納されている２つ以上の表示面を組み合わせて出力画像を合成し、画面３１０に表示することもできる。異なる配合動作を、合成と共に実行することもできる。

ＣＰＵ３２４は、ＴＳＢ４００（図４、以下で論ずる）と通信して、ＲＴに対する表示動作全体を最良に設定し管理する。初期設定には、ＲＴＳＣ３１４においてサポートされている機能の種類、表示画面３１０の仕様、データをバッファ及びキャッシュするために利用可能なＲＡＭ３１２の両、３Ｄ描画エンジン３３２がサポートするコマンド集合、３Ｄ描画エンジン３３４がサポートするコマンド集合、データ・デコーダ３２６がサポートするフォーマット、ビデオ・デコーダ３２８がサポートするフォーマット、及びディスプレイ・コントローラ３３０の能力を列挙することを含むことができる。実行時におけるその他の管理最適化には、ＲＡＭ３１２において表示ビットマップを管理及びキャッシュし、これらをリセットしなくてもよいようにすることが含まれる。

ＲＴ３００の構成は、以前からの(more conventional)ＣＰＵに基づくプラットフォーム上で走る基本データ・デコード・アーキテクチャ又はソフトウェアを含むことができ、インターネット・ブラウザ・アーキテクチャに基づくこともできる。インターネット・ブラウザ・アーキテクチャの一部として、機能ユニットを直接コールする特殊なブラウザによって、機能ユニットを利用する「プラグ・イン」又はドライバを含むブラウザによって機能ユニットを用いることもでき、あるいは標準的なブラウザが、どの要求をローカルに達成することができるかを判断し、ホスト・システム上でウェブ・アプリケーションとの通信を要求する仲介物として作用するローカル・エージェントを用いてもよい。「非同期Ｊａｖａスクリプト言語及びＸＭＬ「（ＡＪＡＸ）、及び「非同期フラッシュ及び拡張可能マークアップ言語」（ＡＦＬＡＸ）は、このようなエージェントに基づく技法であり、ＸＨＴＭＬ、Ｊａｖａスクリプト及び「XMLHttpRequest」を通じて操作する文書オブジェクト・モデルを利用して、ウェブ・サーバと非同期でデータを交換し、クライアントにおけるユーザ・インターフェースを改善することができる。ＡＪＡＸを用いると、クライアント側におけるデータ・デコードにＲＴ３００の機能ブロックを用いる場合、選択的要求を実行することができる。

インターネット・ブラウザ・ベースのＲＴ３００からのエージェントに基づく選択的要求は、ホスト・プロセッサ・ブレード２００及び端末サービス・ブレード４００によってサポートし、システム全体を更に最適化することができる。追加の通信プロトコル処理も、ＡＪＡＸエージェントによって実行することもできる。ＡＪＡＸ動作の別の例には、セキュリティ鍵の管理及びＤＮＳ参照を含むことができる。ＲＴ上におけるＡＪＡＸに基づくエージェントは、ホスト・プロセッサ・ブレード２００又はＴＳＢ４００を、アプリケーション・サーバ又はウェブ・サーバに対するプロキシとして利用することができる。ＡＪＡＸに基づくエージェントは、特殊な通信メカニズムを含み、分割プロキシとして動作することができ、ホスト・プロセッサ・ブレード２００又はＴＳＢ４００がプロキシの他の部分を設ける。

図４は、ブレード・ベースのマルチユーザ・コンピュータ・システム１００の端末サービス・ブレード（ＴＳＢ）４００の第２の好適な実施形態を示すが、ＴＳＢ４００は、代わりに、別個のコンピュータ又は器具として具体化し、ネットワーキングによってホスト・プロセッサに取り付けることもできる。器具としては、ＴＳＢ４００は、ＤＶＩ又はサーバの表示出力へのその他のケーブルのような、別のネットワーク接続を含むことができ、ローカル・ディスプレイ・デバイスに対するサポートを保存するために、ローカルＤＶＩ出力を含むことができる。このようなＴＳＢ４００からのＤＶＩ出力は、サーバからの通過モード(pass-through mode)とすることができ、あるいはＤＶＩケーブル上のデータが単純な通過動作には適していないときには、デコード・ステップを通り抜けることもできる。ＴＳＢ４００は、ホスト・プロセッサからは独立して動作し、多数のＲＴのプロキシ・サーバとして振る舞うことができる。

ＴＳＢ４００は、ＣＰＵサブシステム４０２、メモリ４３４、ブリッジ・コントローラ４０４、ＲＡＭ４３２を有するローカルＩ／Ｏ４２８、並びに端末サービス・アクセレレータ及びマルチユーザ・グラフィクス・プロセッサ・ユニット・サブシステム（ＴＳＡ−ＧＰＵ）７００を構成するコンポーネントを含む。ブリッジ・コントローラ４０４は、直接スイッチ・ファブリックとインターフェースすることができ、あるいはスイッチ・ファブリック１４０及び１４２への接続のためにファブリック・インターフェース１３０を含むこともできる。ＴＳＡ−ＧＰＵ７００の内部にある主要な機能ユニットには、マルチユーザＧＰＵ（ＭＵ−ＧＰＵ）４１２及び端末サービス・アクセレレータ（ＴＳＡ）４２４があり、これらは連動するＲＡＭ４１８及び４３０を有し、ディスプレイ・インターフェース２２０を経由する接続部２２２を含むことができる。構成の中には、ＴＳＡ−ＧＰＵが共有ＲＡＭを有し、更に、図７を参照して以下で説明するように一体化してもよい。

単一のＴＳＢは、多数のプロセッサ・ブレードに対してグラフィクス動作を実行する。プロセッサ・ブレード２００の各々は、１つ以上のＣＰＵを有し、各ＣＰＵは１つ以上のプロセッサ・コアを有し、任意数の仮想マシーンをＣＰＵ及びプロセッサ・コアの混合体上で走ることができる。マルチユーザ又はマルチプロセッサ・オペレーティング・システムの中には、ＴＳＢ４００に対する要求を調整しながら管理し実行することができる場合もある。例えば、Microsoft Remote Desktop Protocol（ＲＤＰ）又はCitrix ICA系システムの場合、表示コマンドは既に仮想化されており、プロセッサ・ブレード２００は直接グラフィクス・サブシステムにアクセスしようとはしない。他のマルチユーザ又はマルチプロセッサ・オペレーティング・システムは、グラフィクス・サブシステムへのアクセスを直列化するように調整された手段を含むことができ、オペレーティング・システムを組み合わせたＴＳＢ４００によって、調整されたアクセスを適正にマップして、１つのＴＳＡ７００が１つ以上のマルチユーザ・オペレーティング・システムに対して多数の表示をサポートすることができるようにしている。

しかしながら、仮想マシーン・モードでは、異なる仮想マシーン同士が互いを知らない場合もあり、各仮想マシーンが、専用のグラフィクス・サブシステムに完全にアクセスできると仮定すればよい。このような場合、ＴＳＢ４００は、多数の仮想マシーンからの非同期コマンド及び要求を順番に満たし、その結果得られるＲＴに対すある表示を適正にサポートするために、仮想抽象レイヤを作成する必要がある。ＴＳＢ４００は、プロセッサ・ブレード２００の異なる仮想マシーン上でランする個別のオペレーティング・システムに対してグラフィクス・ドライバを記述することができる。次いで、ＴＳＢ４００は、異なるオペレーティング・システムからのドライバ・コールを調整し、マルチディスプレイＴＳＡ７００の動作を調整する。あるいは、各オペレーティング・システムが標準的なグラフィクス・ドライバを利用すれば、ＴＳＢ４００は事実上ドライバ・コールを傍受することが必要となる。次いで、傍受したドライバ・コールを管理し、コヒーレント・マルチディスプレイ・モードでＴＳＡ７００を動作させ、仮想マシーン毎に表示をしかるべく管理する。

システムによっては、ＴＳＢ４００の機能の１つは、プロセッサ・ブレード２００をＲＴの各々に対する管理の一部から肩代わりし(offload)、各ＲＴの表示過程(display experience)が改善するように、肩代わりした処理の一部を加速することである。肩代わり及び加速サポートの形式には、グラフィクス動作をリモート・グラフィクス・コマンドにカプセル化すること、どのグラフィクス・コマンドが最も適しているか判断するためにどの能力及びビットマップを各ＲＴにキャッシュするか判断する際に補助すること、ＲＴに転送するために必要となるビットマップのエンコード及びカプセル化、並びにマルチメディア・ビットストリームを最良に管理することが含まれる。あるいは、ブラウザ及びエージェントに基づくＲＴがホスト１００に対して一層具体的な要求を開始して、グラフィクス・データの更新を規定し、送信の前にグラフィクス・データをＴＳＢ４００によってエンコードすることもできる。好適な一実施形態では、ホスト・システム１００はウェブ・サーバであり、この場合、プロセッサ・ブレード２００はサーバ機能のデータベース及び「バック・エンド」動作を実行し、ＴＳＢ４００は、メディア・コプロセッサとして動作して、ウェブ・サーバ機能に対する表示エレメントを管理する。

eXtensible Markup Language（ＸＭＬ：拡張可能マークアップ言語）トラフィック、Simple Object Access Protocol（ＳＯＡＰ：単純オブジェクト・アクセス・プロトコル）、ＨＴＴＰトラフィック、Java Virtual Machine（ＪＶＭ）、及びインターネット系通信と関連する他のトラフィックの検査及びカプセル化のような追加機能もサポートすることができる。プロセッサ・ブレード２００は、ＴＳＢ４００と共に、所望の任意のアンチスパム、アンチ・ビールス、コンテンツ・フィルタリング、アクセス規制施行、又はその他のパケット・フィルタリングに基づくアルゴリズムを実行している間でも、ＲＴに完全なインターネットへのリモート・アクセスを効果的に実行させることができる。このような追加機能は、特に、ウェブ・コンテンツ・アクセスのためのプロキシとしてホストを用いてＲＴインターネット閲覧をサポートする際には有用なことがある。システムには何らかの冗長性があるが、この方法は、ホスト・システムとＷＡＮとの間で利用される一般的なネットワーク・セキュリティ・アプリアンス（装置）よりも特定したユーザ制御を設けることができる。ＤＮＳ参照を設けることによって、設定及び管理する必要があるＴＣＰ／ＩＰ接続の数の減少が可能となる場合がある。また、ＴＳＢ４００は、ＳＳＬのようなセキュリティのための肩代わりも提供ことができる。加えて、ＴＳＢ４００は、安全を確保したクライアントに対して、証明書ベースの暗号アルゴリズムを設けることもできる。

ＴＳＢ４００上の特殊プロキシ・サーバが、インターネット・ベースのトラフィックに対して他の強化を用いることもでき、これには、ＲＴディスプレイ・デバイスに応じて、インターネット・ベースのコンテンツを再フォーマット又は記録すること、及びＲＴ内部における実行機能を含むことができる。例えば、ＲＴデバイスがセルラ・フォン又はパーソナル・ディジタル・アシスタント（ＰＤＡ）であり、画面解像度が限られている場合、ＴＳＢ４００は、高解像度のコンテンツにフィルタをかけてそれよりも低い解像度の画像に落として、高速化し一層適した画像にすることができる。ＴＳＢ４００は、その他の更にインテリジェントなコンテンツ・フィルタリング及びウェブ・ページ解釈アルゴリズムをランさせて、バナー広告及びその他の外部情報の除去というような機能を実行し、中核情報をセルラ・フォンに送るようにすることができる。ＴＳＢ４００は、ウェブ・ブラウザ全体を走らせることができ、ＲＴは能力が低いウェブ・ブラウザ又はマイクロ・ブラウザを走らせる。ＴＳＢ４００のプロキシ機能は、進んだウェブ・フォーマットを、ＲＴのブラウザが理解できるウェブ・フォーマットに変換することができる。

Active-X制御、Macromedia Flash、又はその他のラン・タイム・プログラムを利用するウェブ・コンテンツのような、他の種類のウェブ・コンテンツは、電話機又はＰＤＡのようなデバイスと互換性がない場合もある。ＴＳＢ４００は、仲介プロキシ・サーバとして作用し、表示データpost-Active-X制御を、待機中のＰＤＡに転送することができる。アプリケーション層の正規表現（ＲｅｇＥｘ）コンテンツ処理も実行することができる。再フォーマット及び再符号化も、クライアントのセキュリティを高めるために実行することができる。ＸＭＬ及びＳＯＡＰはハイジャッキング(hijacking)及びその他の形態のウィルスを受け渡しする恐れがあるが、ＴＳＢ４００はＸＭＬ及びＳＯＡＰを安全なディスプレイ・フォーマットに記録することができるので、ＲＴクライアントにはこのような危険性が及ぶことはない。

別の実施形態では、ホスト１００又は更に具体的にはＴＳＢ４００は、ＲＴが読むことができないはずのファイルを見るための、より一般的なマルチフォーマット・ネットワーク・ファイル・プロキシ・サーバとして用いられる。例えば、ＲＴは、種々の表示フォーマットに合ったビューアを含むことができるが、Adobe PDFファイル又はMicrosoft Word文書を開いて見る能力を含むことはできない。ＲＴ上のビューアは、種々のＨＴＭＬ及びその他のウェブ指向の文書をサポートするブラウザとするとよい。ホスト１００は、Adobe PDFファイル及びMicrosoft Word文書の双方を開いて見ることができるとよい。次いで、ホスト１００は、ＴＳＢ４００の機能性を用いて、PDFファイル又はWord文書からのグラフィカル出力を、ＲＴ上で見ることができる互換性のある表示フォーマットに変換することができる。ＲＴは、多くの種類のデータ・ファイルへのネットワーク・リンクを有することができ、マルチフォーマット・プロキシ・ビューアを利用することによって、ＲＴ自体では見るためにデコードすることができない多くの種類のファイルを見ることが可能になる。この種のマルチフォーマット・プロキシ・ビューイングは、ネットワーク・ファイル共有機能と、又はメール・サーバと組み合わせることができる。例えば、マルチフォーマット・プロキシ・ビューアがファイル添付書類を、セル・フォンＲＴが見ることができるフォーマットに変換すると、種々の添付ファイルを有する電子メールを受信することが可能になる。見ることができる添付ファイルは、電子メール・メッセージに含ませることができ、あるいは添付書類の目視可能なバージョンへのリンクを電子メールに含ませることもできる。

マルチメディア・ビットストリームは、ビデオ・ストリームを含むことができる。ビデオ・ストリームは既に圧縮フォーマット化されており、図２のプロセッサ・ブレード２００又は図４のＴＳＢ４００によって受信されている。中には、マルチメディア・ビットストリームが既に対象のＴＲ４００と互換性のあるフォーマットになっている場合もある。このような場合、プロセッサ・ブレード２００上で走るソフトウェア追跡層がビットストリームをＴＳＢ４００に送出し、ＴＳＢ４００はこのビットストリームを、ＲＴへの送信に適したパケット・フォーマットにカプセル化する。カプセル化は、ビデオ表示ウィンドウの原点のような、ヘッダ情報を追加すること、又はトランスポート・ストリームを異なるパケット・サイズのプログラム・ストリームに変換することのような、パケット編成を修正することを含む場合がある。

別の場合では、マルチメディア・ビットストリームは、目標ＲＴによって容易に処理されるフォーマットになっておらず、あるいはネットワーク接続に適したフォーマットになっていない。このような場合、ＴＳＢ４００は、トランスコーディング・プロキシ・サーバとして動作し、マルチメディア・ビットストリームをデコードし、再度エンコードし、トランスコードし、又はレートを変更するという一層複雑なステップを実行する。例えば、着信マルチメディア・ビットストリームが、エンコードしたＨＤＴＶ ＭＰＥＧ−２ストリームである場合がある。ＲＴにおけるウィンドウ・サイズは、小さな３２０×２３０ウィンドウに合わせて設定されている場合、ネットワーク帯域幅を保存し、ＴＳＢ４００にマルチメディア・ビットストリームをトランスコード及びレート変更させて、所望の表示ウィンドウ・サイズを表す、低いビットレートにすることには意味があると考えられる。同様に、着信ビデオのフォーマットが、ＲＴによってデコードすることができない場合、ＴＳＢ４００はビデオを互換性のあるフォーマットにトランスコードすることができる。フォーマットに互換性があっても、ディジタル権利管理（ＤＲＭ）又は暗号化方式のような、その他の非互換性が存在する場合もある。ＴＳＢ４００は、１つのＤＲＭ又は暗号化方式を、目標ＲＴに適合する方式に変換することもできる。

例えば、コンテンツ所有者が、Apple社のiTunesが用いるような企業固有の鍵交換に基づくＤＲＭ方式を用いる場合がある。ＴＳＢ４００は、プロセッサ・ブレード２００又はローカルＣＰＵ４０２のいずれかでランするiTunesビデオ・プレーヤの出力を検査して、解読したコンテンツを取り込むことができる。出力がＤＶＩビデオ・バスからである場合、デコードした出力を更にＨＤＣＰにおいて暗号化する。ＨＤＣＰの場合、ＴＳＢ４００はＤＨＣＰ保護コンテンツをデコードするためには適正な鍵を有する必要があり、解読を実行するために、ディスプレイ・デバイスとして作用する場合もある。コンテンツ所有者の制御権利を保存するために、ＴＳＢ４００は、次に、コンテンツを再度暗号化して、リモート・クライアントの再生デバイスが理解できるプロトコルにする。これは、ディジタル送信コンテンツ保護（ＤＰＣＴ）又はMicrosoft社の現行のフォーマットのような、市販のプロトコルに基づけばよく、あるいは企業固有のプロトコルを用いてもよい。一旦再暗号化したならば、新たに保護されたデータ・ストリームをネットワークを通じて、適正な解読及び表示能力を有する受信側のデバイスに送信することができる。

Microsoft社のRemote Desktop Protocol（ＲＤＰ）の現行バージョンの一部では、圧縮ビデオ・ストリームに対する処理効率が低下している。ＲＤＰでは、ホスト・システムの内部にあるドライバがビットストリームを検出し、デバイス独立ビットマップ（ＤＩＢ）にデコードする。次いで、ＤＩＢをＲＤＰ転送コマンドに変換し、ＤＩＢフォーマット・データをネットワークを介してＲＴに転送するが、信頼性は低い。殆どの場合、１組のＤＩＢデータのフレームのみが表示のためにＲＴに達する。つまり、デコードを行うホストＣＰＵ、及びデコードしたデータを効率の低いフォーマットでネットワークを通じて送ることは、非効率である。他のＲＤＰベースのグラフィックス動作も同様にＤＩＢを利用している。

ウェブサイトからのグラフィックス・ビットマップのような、従来からのグラフィクス・ビットマップも、ホスト１００からＲＴ３００に転送する必要がある。ＴＳＢ４００は、ＤＩＢのような従来のグラフィクス・ビットマップに対して種々のレベルのエンコードを実行することができる。グラフィクス・ビットマップのエンコードは、損失がない場合も損失がある場合もあるが、元のグラフィクス品質の目視区別可能な表現を提供することを目標とする。ＴＳＢ４００のための簡素化したソフトウェア・インターフェースでは、単にＲＤＰ ＡＰＩを通じてホストＣＰＵとインターフェースすることだけを含む場合があり、一方、それよりも意欲的な実施態様では、ＴＳＢ４００が基礎のDirectX ドライバ・フレームワークにアクセスすることを可能にする。エンコードしたＤＩＢの転送、及び特殊な圧縮ビデオ・ドメインの転送は、標準的なＲＤＰ実施態様の一部ではない。したがって、これらの転送は、既存のＲＤＰ転送フォーマットと抱き合わせ、ある種の私的ＲＤＰ拡張として動作するか、又はＲＤＰフレームワークの外側で動作すればよい。

ホスト・オペレーティング・システム及びＲＤＰのバージョンの中には、ＲＤＰプロトコルに対する追加のセキュリティ要件を満たす必要がある場合もある。ＲＤＰクライアントは、ホストと鍵を交換し、暗号化パケットを利用しなければならない場合もある。ＴＳＢ４００はＲＤＰクライアント・パケットを傍受しているので、ＴＳＢ４００は、ホスト・プロセッサと通信するために、しかるべき加速及びオフロードを、鍵交換及び解読のために含むとよい。加えて、システムのセキュリティを維持するために、ＴＳＢ４００及びネットワーク・インターフェースは、ＲＴとの全ての通信がしかるべく暗号化されていることを確認する。

別の実施形態では、ＴＳＢ４００は、ウェブ・サーバ移行エンジンとして、ウェブ・サーバの一部として又は多数のウェブ・サーバに対する集合点として動作し、ブラウザ及びエージェントに基づくＲＴをサポートすることができる。ウェブ・サーバの加速は、ＪＡＶＡ、データ・エンコード、データ・トランスコード、及びその他の機能のために実行することができる。更に別の好適な実施形態では、ＲＴは一層インテリジェントなエージェントに基づくブラウザをランさせることができ、このブラウザは、ＡＪＡＸのような多数のプロトコルに対するサポートを含む。ＡＪＡＸまたは同様の手法を用いるブラウザは、ユーザ動作の間ブラウザ内部の情報を維持し、管理することができ、新しい情報が必要となったときだけ、ウェブ・サーバと接触すればよい。サーバが完全なフレームを受け渡す代わりに、ＡＪＡＸが情報の要求を更に特定して行わせ、ウェブ・サーバがその新しい情報だけを提供し、次いでこれを既に格納されている情報と共に用いて、新しいフレームをローカルに発生する。この永続性(persistence)は、情報をプリフェッチすることによって、要求を小さくそして効率を高くすることを求めることによって、そして、セキュリティを管理することによって、ユーザ・インターフェースを改善するために用いることができる。ＡＪＡＸが発生する要求は、ＴＳＢ４００によって管理することができ、この場合、ＴＳＢ４００によってセキュリティを維持し、データを効率的にエンコードすることができ、クライアント側ではＡＪＡＸ及びＲＴ３００の機能ブロックを用いてデータをデコードすることができる。

設計が優れたＡＪＡＸウェブ・アプリケーションは、クライアント又はプロキシのオブジェクトをキャッシュし完全なフレームを送る必要性を軽減する能力を利用する。ここでも、任意のフレーム・データの最初の要求をエンコードするためにＴＳＢ４００を用いることができる。選択的更新に合わせて設計されていないウェブ・アプリケーションに対して、ＴＳＢ４００を、このようなウェブ・アプリケーションとＡＪＡＸに基づくブラウザとの間でプロキシとして用いることができる。ホスト１００は、ウェブ・サーバでなくてもよく、インターネット・サービス・プロバイダ（ＩＳＰ）又は存在点（ＰＯＰ：Point of Presence）に配置されたサーバであってもよい。プロキシのように、ホスト１００又はＴＳＢ４００は、ＲＴ３００と調整を行い、クライアントが先導する要求に基づいて、選択的更新を実行することができる。ウェブ・アプリケーションが完全なフレームの更新を要求しても、ＴＳＢ４００のプロキシは、新しいフレーム及び古いフレームを処理し比較して、クライアントにエンコードした更新情報を提供することができる。これによって、選択的更新に合わせて具体的に設計されていないウェブ・アプリケーションにとっても、帯域幅の縮小、及びＲＴ３００のユーザ・インターフェースの改良が可能となる。

ＴＳＢ４００は、数個の無関係の動作に対して一般的な移行タスクも解決するプログラム可能な解決策によって実施することができる。サーバは、ネットワーク、格納、セキュリティ、及びその他のタスクをオフロードすることから便益を得ることができる。オフロード・プロセッサは、統計的又は動的に種々の肩代わりタスクの均衡を取り、任意の作業負荷についても全体的なシステム・スループットを加速するように設計することができる。例えば、サーバは、日中少機能のクライアントのためにサーバ・ベースの計算を実行しており、夜間は大きなデータベース動作をランさせている場合もある。日中、肩代わりエンジンは、ＴＳＡのために記述された動作をランさせる。夜間では、肩代わりエンジンは、ディスク記憶システムから大きなデータベースにアクセスするために、ｉＳＣＳＩ加速をランさせる。種々の作業負荷を追跡する内部又はシステム全体の管理手順によって、柔軟性を管理することができる。肩代わりタスク間の切換の粒度は、非常に小さくすることができる。肩代わりエンジンは、非常に速いコンテクスト切換を実行するように設計することができるので、１回のセッションの間に、ネットワーク、端末サービス、格納、セキュリティ、及び同じセッションについてのその他の肩代わりタスクを実行することもできる。

異なる肩代わりタスクのために動的処理をサポートするために、ＴＳＢ４００はプログラム可能かつコンフィギュレーション（環境設定）可能な処理ブロックを用いる。これらの処理ブロックは、作業負荷が変化するに連れて素早くタスクが切り換えられ、再コンフィギュレーションすることができる。処理ブロックの各々には、種々のメモリ・ブロックを含めることができ、それよりも大きなメモリ４３４を含めることもできる。ＣＰＵ４０２は、総合的にプログラム可能なプロセッサであり、それ自体のキャッシュ・メモリを含み、肩代わりについてのハウスキーピング及び管理を実行することができ、更に高いレベルのプロトコル及びインターフェースの処理も実行することができる。ブリッジ・コントローラ４０４は、ネットワーク・プロセッサを統合し、ＴＳＢ４００のスイッチ・ファブリック・インターフェース１３０の機能を管理することができ、更に同時通信の多数のパイプを管理することができる。コンテンツ・アドレス・メモリ（ＣＡＭ）のような特殊な内部メモリ、及び従前のメモリもブリッジ・コントローラ４０４の中に含めてもよい。

ブリッジ・コントローラ４０４及びＴＳＡ−ＧＰＵ７００の処理ユニットは、専用ハードウェア・ブロックと関連のあるスループットで異なる処理を実行するように容易に再コンフィギュレーションされるように設計されたコンフィギュレーション変更可能なデータ・プロセッサ（ＣＤＰ）として実施することができる。専用ハードウェアの代わりにＣＰＵを利用することによって、同じハードウェアによって異なる肩代わりタスクを実行することが可能になる。コンフィギュレーション変更可能なデータ・パス、動的命令集合、非常に長い命令語（ＶＬＩＷ）、単一命令多重データ（ＳＩＭＤ）、多重命令多重データ（ＭＩＭＤ）、ディジタル信号処理（ＤＳＰ）及びその他の形態のコンフィギュレーション変更可能な計算のような、ＣＤＰを設計する先行技術の方法を組み合わせると、非常に高い性能の計算を実行することができる。また、ＣＤＰは、暗号及び鍵に関する機能のために追加の専用ハードウェアを用いて、又は用いずに、セキュリティ・プロセッサとして機能することもできる。

端末サービス加速及びプロキシ・サーバ動作のために、ＣＤＰは、タイル及び矩形のデータ・エンコード、ビデオ又はデータに対する種々の形態のトランスコード及びレート変更、タイル署名の発生及び比較、並びにＴＳＡ−ＧＰＵ７００に関して以下で説明するその他のタスクを実行するように、構成することができる。記憶の加速のためには、ＣＤＰはｉＳＣＣＩ、ファイバ・チャネル（ＦＣ）、ファイバ・チャネル・インターネット・プロトコル（ＦＣＩＰ）、及びインターネット・プロトコルに関するタスクの異なる態様に合わせて構成することができる。接続部４９０は、ＦＣ及びその他の記憶プロトコルに接続するように構成することができる。インターネット・コンテンツの加速のためには、ＣＤＰは、ＸＭＬトラフィック、ＳＯＡＰ、ＨＴＴＰトラフィック、ＪＶＭ、及びインターネット系通信と関連のあるその他のトラフィックを処理するように構成することができる。他のウェブ・サーバ加速には、ＤＮＳ参照を肩代わりすること、ＴＣＰ／ＩＰ接続を処理すること、並びに従前のウェブ・クライアント及びＡＪＡＸ様式のエージェント・ベースのブラウザ双方のために、データ・エンコード及びトランスコードを実行することを含む。

ＴＳＡ−ＧＰＵ７００は、ＴＳＢ４００のグラフィクスに関する肩代わり及び加速機能を実行する。マルチユーザ・グラフィクス・プロセッサ・ユニット（ＭＵ−ＧＰＵ）４１２は、パケットを通じた選択的表示更新のサポートを含み、好適な実施形態を通じて提案したVESA Digital Packet Video Link（ＤＰＶＬ）規格の一部又は全てに準拠することができ、強化機能を含む。ＴＳＡ４２４は、システム・バス４０６を通じてＭＵ−ＧＰＵ４１２からのパケット表示更新をサポートするか、好ましくは入力パス４１４及び４１６をサポートする。これらの入力は、シリアル・ディジタル・ビデオ出力ＳＶＤ０１及びＳＤＶ０２、又は異なるバス幅、シグナリング・プロトコル、及び周波数を有する汎用ポートとすればよい。その例には、ディジタル・ビデオ出力（ＤＶＯ）、ディジタル・ビジュアル・インターフェース（ＤＶＩ）高品位マルチメディア・インターフェース（ＨＤＭＩ）ディスプレイ・ポート、あるいは、その他の低電圧差動シグナリング（ＬＶＤ）、遷移最小化差動シグナリング（ＴＭＤＳ）、ＰＣＩエクスプレス、又はその他の方式が含まれる。表示出力パスは、高いリフレッシュ・レートで多数のフレームを出力するのに十分な速度で走ることができればよく、フレームは、１つよりも多いＲＴに対応する選択的更新矩形とすることができる。ＴＳＡ４２４は、ローカルＩ／Ｏ 又はネットワーク・コントローラに、専用リンク４２６を通じて、種システム・バス４４０６を経由して接続することができ、あるいはシステム・オン・チップ（ＳＯＣ）実施態様によって一層密接に一体化することができる。第２システム・バス４０８も、追加帯域幅のために、そしてブリッジ・コントローラ４０４及びその多数のスイッチ・ファブリックに対するインターフェースを直接サポートし易くするために、含んでもよい。

従前のグラフィクス処理を実行することに加えて、ＭＵ−ＧＰＵ４１２は、表示に基づく選択的更新を生成し、表示の内変化した部分を示す。選択的更新は、矩形又はタイルの形態をなすことができ、ビデオ出力パス４１４又は４１６を通じて、又は主システム・バス４０６を通じてのいずれかで出力される。矩形更新は、ウィンドウの原点、サイズ、及びフォーマットを示すパケット・ヘッダを含む。原点は、どのＲＴが宛先であるかを示すために用いることができる。タイルも用いることができ、ヘッダがタイルを記述する情報が少なくて済むように、１つ以上の固定サイズに標準化することができる。矩形又はタイルをＲＴにおいて倍率調整すべきか、そしてどのようにして倍率調整するかというような、他の情報もヘッダに含むこともできる。選択的更新の他の形態には、BitBlt、エリア・フィル(Area Fill)及びパターン・フィル(Pattern Fill)に対するサポートを含み、大きなブロックのデータを送る代わりに、ＲＴにおいて実行する動作のコマンド・パラメータと共に、最少量のデータを送る。他のヘッダは、ビデオ・ストリーム、ゲンロック、倍率調整ビデオ・ストリーム、ガンマ・テーブル、フレーム・バッファ制御の形態で更新をサポートする。他の強化した複雑なコマンドも、ＲＴに対する選択的更新の様式に入れることができる。提案したＤＰＶＬ仕様は、選択的更新について可能な一実施態様を、それらのヘッダと共に詳細に示す。

１つのＭＵ−ＧＰＵ４１２は、多数のＲＴに対する表示データを各々が収容する種々の表示面にＲＡＭ４１８を編成することにより、ＲＴ３００の全てに対してシステムによって事実上仮想化することができる。ＭＵ−ＧＰＵ４１２の２Ｄ、３Ｄ及びビデオ・グラフィクス・プロセッサ（図示せず）を利用して高いグラフィクス及びビデオ性能を達成することが好ましい。グラフィクス処理ユニットは、２Ｄグラフィクス、３Ｄグラフィクス、ビデオ・エンコード、ビデオ・デコード、スケーリング、ビデオ処理、及びその他の高度画素処理を含むことができる。また、ＭＵ−ＧＰＵ４１２のディスプレイ・コントローラは、ビデオ及びグラフィクス・データの配合及びキーイング(keying)、並びに画面リフレッシュ動作全体というような機能も実行することができる。主及び副表示面に用いられるＲＡＭ４１８に加えて、種々の３Ｄ及びビデオ動作をサポートするのみ十分な、画面外メモリ(off-screen memory)がある。選択的更新を管理するＤＰＶＬ方法の代わりに、ＲＡＭ４１８の内部に選択的更新バッファ・メモリ（Ｓ−バッファ）４０４があってもよい。一実施形態では、Ｓ−バッファ４０４は、ステータス・ビット、署名、又はステータス・ビット及び署名双方を格納する。これらは仮想表示毎に各タイルに対応する。他の実施形態では、Ｓ−バッファ４０４はヘッダと共に又はヘッダのないタイル自体、ステータス・ビット及び署名情報を格納し、この場合、タイルは選択的更新に合わせて出力されるように配列されている。

グラフィクス・エンジン及びディスプレイ・コントローラは、通例、ＲＴディスプレイ毎に主面に対応する完全な表示画像を合成する。ＲＡＭ４１８は、ＲＴの全てについての表示フレームのアレイを効果的に収容する。例えば、１６Ｋ×１６Ｋ画素の仮想ディスプレイとして、表示メモリを構成することができる。このような応用例では、１Ｋ×１Ｋの２５６台のＲＴディスプレイを１６Ｋ×１６Ｋアレイにマッピングすることができる。同様に、各ＲＴが２５６×１２８ディスプレイを有するセルラ・フォンである場合、８１９２個の仮想ディスプレイを１６Ｋ×１６Ｋの表示エリアにマッピングすることができる。追加の画面外メモリ及びスクラッチ・メモリ（scratch memory）も含まれる可能性も高い。この用途には多数の独立したＲＴを伴うので、ＭＵ−ＧＰＵ４１２は異なるセキュリティ機構を追加して、異なる表示エリアの安全性を確保し、一人のユーザが他のユーザのフレーム・バッファへのアクセスをえることを防止するとよい。本システムは、好ましくは、ハードウェア・ロックを含み、セキュリティ及び信頼性双方の懸念に対して、表示メモリの保護部分に対する不正アクセスを防止する。

図５は、図４のメモリ４１８の構成例を示し、仮想表示空間が横３２００画素及び縦４８００画素に設定されている。メモリ４１８は、８つの１６００×１２００表示エリアに分割されており、５２０、５２２、５２４、５２６、５２８、５３０、５３２、及び５３４で示されている。典型的な高品質表示モードは、画素毎に２４ビットのビット深さに合わせて構成されるが、多くの場合、ＲＡＭ４１８において編成されている、ビット当たり３２ビットの構成を利用し、グラフィクス及びビデオ・プロセッサがディスプレイにアクセスするときに、位置合わせがし易くし、更に余分な８ビットを潜在的に他の目的で用いることができるようにする。タイル状メモリの図は、性質上概念的であり、ＭＵ−ＧＰＵ４１２から見た場合である。実際のＲＡＭアドレシングは、メモリ・ページ・サイズ及びその他の考慮点にも関係する。

図５において、表示エリア５２８は更に、表示更新矩形５５０を含んでいる。１６００×１２００表示の破線５４０は、地区(precinct)と呼ばれる、２５６×２５６画素の更に粗いブロックの境界に対応する。表示ウィンドウ５５０から明白なように、表示ウィンドウの境界の位置合わせは、必ずしも地区の境界と合っていない。ユーザは表示画面上にウィンドウのサイズ及び位置を任意に決めるので、これは典型的な状況である。フレーム全体を更新する必要がない遠隔画面更新をサポートするためには、表示ウィンドウ５５０の影響を受ける地区の各々を更新する必要がある。更に、表示ウィンドウ５５０内におけるデータ形式及び周囲の表示画素は完全に異なる形式であり、相関がない場合もある。したがって、地区に基づくエンコード・アルゴリズムは、損失を伴う場合、地区の縁及び表示ウィンドウ５５０の境界いずれにも、視覚的アーチファクトが伴わないことを確保する必要がある。実施のエンコード・プロセスは、８×８又は１６×１６のような、地区よりも小さいブロック単位で行うことができる。したがって、好適な実施形態は決定論的エンコード・アルゴリズムを用い、周囲の画素には関係なく画素の１集合に対して同じ結果が得られ、ウィンドウの任意の位置合わせによってアーチファクトが生ずることはない。

エンコード方式に対するブロック境界も、タイルに関する考慮点の１つである。例えば、ブロック境界が８画素の倍数でなければならないエンコード方式がある。ソース・ファイルが８画素の倍数でない場合、周囲のデータで埋め合わせする必要がある。別の場合には、ブロックの境界を、特定のユーザが配置した矩形すなわちタイルではなく、画面に向けてブロック境界を方位付けることが好ましいことが多い。ユーザが８０×８０画素のウィンドウを操作する場合、水平及び垂直方向の各々において最低１０個の８×８ブロックを用いるように配置することが理論上可能であっても（合計１００ブロック）、各方向に１１ブロック（１２１ブロック）に及ぶ可能性の方が高い。したがって、矩形更新及び矩形の任意の続行中の円弧度は、８８×８８画素（１２１ブロック）をエンコードすることになり、周囲の画素の一部が埋め合わせ(padding)のために必要となる。

また、異なるサイズのディスプレイを有するＲＴもサポートすることができる。一例では、ＭＵ−ＧＰＵ４１２は任意サイズのディスプレイをサポートすることができる。別の例では、それよりも小さいディスプレイをサブ・ウィンドウとしてサポートする、又はそれよりも大きなディスプレイを１つの表示エリアよりも広いオーバーレイ・ウィンドウとしてサポートする方が簡単な場合もある。矩形５３６によって線引きされているように、１９２０×１０８０ウィンドウの場合、５３２及び５３４エリア双方を用いる必要がある。これはエリアを無駄にするが、ディスプレイ毎にカスタム・サイズを作成するよりも、実施が簡単である。ＭＵ−ＧＰＵ４１２の選択的矩形更新メカニズムのために、画面の関連するエリアだけが常に送信される。ＤＶＰＬは動的にＣＲＴＣ制御レジスタを制御して選択的更新を管理するが、Ｓ−バッファのような、これよりも柔軟性のあるその他のメカニズムを実施することもでき、プロセッサの介入が少なくて済み、システムの効率も向上する。

また、更に柔軟性の高いシステムでは、矩形を、タイルのように一層規則的サイズとしたエンティティに分解することもできる。任意の矩形サイズを有するヘッダ情報の効率と、柔軟性の低いタイル・サイズを用いるが画面データが多く単純化する潜在性のあるヘッダとの間には、ヘッダ情報の効率にトレードオフがある。好適な一実施形態では、タイルをブロック・サイズの任意倍数に動的に設定することができ、ブロック・サイズは、データ・エンコード・アルゴリズムに対して最小のエンティティとなっている。ブロックは、ソース画像又は画面の固定ブロック位置のいずれに対して方位付けることもできる。タイルのサイズは、ヘッダ情報に含まれる。

５３０で示すようなメモリのエリアを、選択的更新を管理するためのＳ−バッファに指定することができる。一実施形態では、Ｓ−バッファは、表示フレーム５２０、５２２、５２４及び５２６のタイルに対応するステータス・ビットを含み、ステータス・ビットは、タイルが選択的更新を必要とするか否かを示す。Ｓ−バッファ４０４は、タイル毎に署名も格納することができ、この場合、選択的更新の必要性を判断する際に用いられる。別の実施形態では、選択的更新が必要なフレーム５２０、５２２、５２４及び５２６からのタイルを、メモリ・エリア５３０にコピーし、選択的更新出力に合わせて整列させる。整列したタイルは、種々のヘッダ、ステータス、及び署名情報を含むことができる。

図６Ａは、図５の表示マップ５３６を更に詳細にした図を示す。これは、１９２０×１０８０の高品位テレビジョン（ＨＤＴＶ）の解像度を有し、１０８０Ｐと呼ぶ。図６Ａにおいて、固定サイズの矩形６１４が、画面位置の境界によって方位付けられている。各矩形は、横１６０画素、縦１２０画素である。行毎に１２個の矩形（１２×１６０＝１９２０）、そして列毎に９個の矩形（９×１２０＝１０８０）がある。システムは、これらの矩形を選択的更新の基準を形成するタイルとして用いることができる。図６Ｂにおける別のシステムでは、更に、矩形を８０×４０画素を含むタイルに分割し、システムはこれらの小さくしたタイルを選択的更新の基準として選択することもできる。更に柔軟性が高いシステムでは、６つのタイル６２０から成る大きな矩形６１４、及びタイル自体の双方を利用することができ、ヘッダ情報を用いて、任意の時点でどちらの種類が出力されているのかを正確に叙述することができる。

双方の場合において、エンコード・アルゴリズムの基準を形成するブロックは、タイル又は矩形の中に納まる。８×８ブロックを仮定すると、各タイルは、１０×５のブロック構成を有し、各矩形は２０×１５のブロック構成を有する。大きい方の矩形及び小さい方の双方の矩形を利用するシステムでは、選択的更新の必要性を判断する際に、各々に異なるメカニズムを用いることができる。好適な一実施形態では、大きい矩形にはステータス・ビットを関連付け、これらが変化したか否かを示すことができ、小さい方のタイルは、このような判断を行うために署名を利用することができる。ステータス・ビット及び署名は、以下で説明するが、Ｓ−バッファによって管理することができる。

ＭＵ−ＧＰＵ４１２は、タイルの選択的エンコードを直接的に実行する処理を統合することができ、あるいは選択的更新プロセス及びＴＳＡ４２４への出力を用いて各タイルをチェックすることもでき、その場合、タイルはしかるべきヘッダを含むことになる。ヘッダは、ＴＳＡ４２４によって処理され、ヘッダ内部にあるフィールドに基づいて、ＴＳＡ４２４は、どのＲＴそして表示画面のどこにタイルが意図されているのか把握する。該当する場合、ＴＳＡ４２４は、タイルを圧縮フォーマットにエンコードし、いずれの必要なヘッダ情報も調節し、更にネットワーク処理を行うためにタイル及びヘッダを供給する。

ＭＵ−ＧＰＵ４１２及びＴＳＡ４２４は、選択的更新プロセスを別々に区分することもできる。場合によっては、ＭＵ−ＧＰＵ４１２は、完全な管理を行うことができ、更新を必要とするタイルだけをＴＳＡ４２４に送る。別の場合、ＴＳＡ４２４は、更にスライスのフィルタリングも実行し、どのスライスが本当に更新を必要としているのか判断しなければならない。ＭＵ−ＧＰＵ４１２内部において、選択的更新メカニズムは、ハードワイヤにすることも可能であり、ＣＰＵの介入を必要とすることも可能であり、ハードウェアは、描画エンジン及び選択的更新リフレッシュ・エンジンの双方に跨って実施することもできる。また、タイルのエンコードは、ＭＵ−ＧＰＵ４１２又はＴＳＡ４２４のいずれで実行してもよい。また、ＭＵ−ＧＰＵ４１２は、ディジタル・ビデオ・バスを通じて、ＲＴに対するグラフィクス描画コマンドをＴＳＡ４２４に出力することもでき、あるいはソフトウェア・ドライバがコマンドを直接ＴＳＡ４２４に供給することもできる。

選択的タイル更新のために、第１の実施形態では、Ｓ−バッファを用いる場合、ＭＵ−ＧＰＵ４１２がタイル毎にステータス・ビットを管理する描画エンジンと、タイル毎に選択的表示更新を管理する際にステータス・ビットを監視する選択的更新リフレッシュ・エンジンとを有する。３Ｄグラフィクスで用いられるＺ−バッファと同様に、Ｓ−バッファは、別個のデータ・メモリ・プレーンとして実現することができる。Ｚ−バッファの場合と同様、強化ＭＵ−ＧＰＵ４１２のハードウェア描画動作がＳ−バッファのステータス・ビットを更新し、追加コマンドは不要である。次いで、選択的更新ハードウェアがステータス・ビットを用いて、どのタイルがＲＴにおいて更新する必要があるか判断する。ディスプレイ・コントローラのリフレッシュ・サイクルと同様に、選択的更新ハードウェアは周期的にＳ−バッファを詳しく調べて、ステータス・ビットを読み出す。ステータス・ビットの状態に基づいて、選択的更新ハードウェアは、更新する必要のないタイルをやり過ごすか、又は選択的更新のためにタイルを読み取り、このタイルをヘッダ情報と共に出力し、それに応じてステータス・ビットを更新する。効率が低くてもよい実施態様では、ＭＵ−ＧＰＵ４１２は従前の古いグラフィクス描画動作を用いてＳ−バッファを発生することができる。

特定のＳ−バッファ・ハードウェアを必要としない別の好適な実施形態では、ＭＵ−ＧＰＵ４１２は、更新が必要なタイルを連結し、選択的更新バッファを管理することができる。選択的更新バッファは、別個のメモリ・エリアに組み入れてもよい。ＭＵ−ＧＰＵ４１２が動作を実行しタイルが変化する毎に、そのタイルを選択的更新バッファにコピーする。各タイルの先頭に、ヘッダ情報を格納することができ、タイル同士を一緒に詰め込むことができる。ディスプレイ・コントローラは、選択的更新バッファを用い、標準的なディスプレイ・コントローラの出力動作を用いて、それをリフレッシュ・ポートに出力するように設定されている。ＭＵ−ＧＰＵ４１２は、１つ以上のバッファをリング・バッファ、又は連結したタイルのリンク・バッファ・リストとして管理し、連続出力をＳＤＶＯ出力に供給し、ＴＳＡ４２４はそれをタイル・リストとして扱う。ＭＵ−ＧＰＵ４１２がリストにおける配置の優先順位を調停するためには、種々の方式を用いることができる。この方法は、多数のＲＴをサポートするには特定のハードウェアが少なく、特殊な選択的更新ハードウェアを殆ど又は全く有していないＭＵ−ＧＰＵ４１２を利用するためには、最も効率的であると言える。

別の好適な実施形態では、ＴＳＡ４２４がＭＵ−ＧＰＵ４１２と共に動作して、ＲＴ３００においてどのタイルが更新を必要としているか判断する。ＭＵ−ＧＰＵ４１２がタイル毎にステータス・ビットを管理する能力は、難しすぎる場合があり、タイルを大きなタイル又は仮想ＲＴディスプレイ全体に集合化し、ステータス・ビットに対する粒度を制限することもできる。大きなタイルをそれよりも小さなタイルの更新に縮小することは、タイル毎の署名追跡に基づいて行うことができる。署名は、タイルが最初に処理されるときに発生され、後続の署名と突き合わせてチェックする。署名は、ＴＳＡ４２４によって発生し処理することができ、ＴＳＡ４２４は、着信データから、又はＭＵ−ＧＰＵ４１２の選択的更新ハードウェアと共に動作する。ＴＳＡ４２４がタイル毎に署名チェックを行う場合、各ＲＴ４００に対するネットワーク帯域幅を保存することができる。ＭＵ−ＧＰＵ４１２が署名チェックを行う場合、ビデオ・パスを通じてＴＳＡ４２４までの帯域幅も保存する。ＭＵ−ＧＰＵ４１２はタイルに対応する署名のメモリ・プレーンを発生し管理することができ、ステータス・ビットは、署名プレーン又は別個のプレーンの一部とすることができる。あるいは、ステータス・ビット及び署名ビットをＲＡＭキャッシュにおいて管理し、ＭＵＧＰＵ４１２によってリンク・リストと共に管理してもよい。

ホスト４００上におけるグラフィクス動作によって発生するグラフィクス・コマンドの種類、及びＲＴ３００の能力に応じて、コマンドをカプセル化してＲＴにおける実行のために送ることができ、あるいはＭＵ−ＧＰＵ４１２によってローカルにコマンドを実行することもできる。多くの場合、コマンドはＲＴにおける実行のために送られるが、仮想表示のローカル・コピーを保持するために、コマンドはＭＵ−ＧＰＵ４１２によってもローカルに実行される。理想的には、冗長なローカル・グラフィクス・コマンドの結果変化した任意のタイルをステータス・ビットによって取り除き、不要なタイル更新パケットがＲＴに送られるのを防止する。エンコードしたタイルの代わりにコマンドを送るには、帯域幅は少なくてよいが、常にこれが可能とは限らない。選択的更新バッファを手動で管理するシステムでは、ＲＴに送られているコマンドも考慮する。ＲＴにおいて実行するコマンドによって更新されるタイルは、ＭＵ−ＧＰＵ４１２によって選択的更新バッファに入れないことが理想的である。

プロキシ・サーバ又は端末サービス・アクセレレータの仮想表示メモリは、ＲＴのディスプレイに変化が反映される前に更新することができる。これらは同じディスプレイと相関があるが、ＭＵ−ＧＰＵ４１２及びＴＳＡ４２４によって管理されるタイルの位置及びサブフレームは、ユーザ・インターフェースの動作とは独立して位置付けられる。ユーザ・インターフェースの動作の結果、１つのタイルの中又は多数のタイルに跨って表示の変化が生ずる場合がある。ユーザ・インターフェースの変更は、ユーザの動作、ＡＪＡＸエージェント、ブラウザ、又はプロキシ・サーバから開始する場合があり、その結果、仮想表示メモリに変更が生ずる可能性がある。タイルにおける更新、又は仮想表示メモリのサブフレーム更新は、ＲＴにおいて反映され、ＭＵ−ＧＰＵ４１２及びＴＳＡ４２４によって管理される。

別の例では、ＲＴを目的とするグラフィクス・コマンドをＴＳＡ４２４によって処理し、エンコード・データ転送及び修正グラフィクス・コマンドに分解する。例えば、ホスト・システムが画面外メモリから又はパターンから画面上メモリにBitBlt動作を実行したい場合がある。これは、ＭＵ−ＧＰＵ４１２サブシステムにおいて容易に実行することができる。しかしながら、ＲＴにおいて、BitBltに必要なソース・データがキャッシュされていない。したがって、グラフィクス・コマンドを送ることができるようにするには、最初に、ソース・データ又はパターンをエンコードし、カプセル化し、ＲＴに送り、次いで修正グラフィクス・コマンドをカプセル化しＲＴに送る必要がある。この手順は、ＴＳＡ４２４によって肩代わりすることができる。DirectXドライバがＭＵ−ＧＰＵ４１２を通じてコマンドをつぎ込み、ついでＭＵ−ＧＰＵ４１２がこれらをＴＳＡ４２４に出力することは可能であるが、DirectXドライバがこれらを直接ＴＳＡ４２４に伝達することの方が効率的なことも多い。

図７は、マルチユーザＧＰＵ（ＭＵ−ＧＰＵ）４１２を端末サービス・アクセレレータ（ＴＳＡ）４２４と共に集積回路（ＴＳＡ−ＧＰＵ−ＩＣ）システム・オン・チップ（ＳＯＣ）７１０に組み合わせた好適な実施形態を示す。組み合わせたＴＳＡ−ＧＰＵ−ＩＣ７１０は、ＲＡＭ７３６をオンチップ又は外部に、サブシステム７００の一部として含むことができる。ＴＳＡ−ＧＰＵ７００は、１つ以上のシステム・バス・インターフェース４０６及び４０８を含むことができ、これらは同様でも異なっていてもよい。ＴＡＳ−ＧＰＵ７００は、２Ｄエンジン７２０、３Ｄグラフィクス処理ユニット（ＧＰＵ）７２２、ＰＣＩエクスプレス等の種々のシステム・バスに合わせたシステム・バス・インターフェース７３２、及びビデオ又はその他のローカルＩ／Ｏのためのインターフェースを含むことができるローカルＩ／Ｏ４１０の制御を含む。加えて、ＳＯＣ７１０は、ビデオ圧縮部７２４及びビデオ伸張部７２６のハードウェアの組み合わせ、あるいは、これら及びその他のビデオ関係機能を組み合わせた形態のプログラマブル・ビデオ・プロセッサ７６４も含むことができる。また、追加のプロセッサ７５６も含むことができる。

また、選択的更新を実行するディスプレイ・コントローラ（ＳＵＣ）を有するマルチユーザ選択的更新、及び、要求されたサブフレーム又はタイルを圧縮するデータ・エンコーダ７５２も含まれる。ＳＵＣ７５０は、ローカル・ディスプレイに対する出力２２２及び７５８を含むが、リモート・マルチユーザは、システム・インターフェース７３２、あるいは潜在的にネットワーク・コントローラへの直接接続部４２６によってサポートされる。システム・バス７６０は、種々の処理ユニット並びにシステム・インターフェース７３２及びメモリ・インターフェース７３４間における接続を例示する。システム・バス７６０は、種々の形態のクロスバー切換、調停転送を含むことができ、性能強化のためにユニット間に直接パスを有することもできる。

図４のマルチチップＴＳＡ−ＧＰＵ７００では、ＭＵ−ＧＰＵ４１２は、ＳＤＶＯパス４１４及び４１６を通じてＴＳＡ４２４に接続されており、ＭＵ−ＧＰＵ及びＴＳＡは各々、それら自体のＲＡＭを有している。逆に、図７では、ＴＳＡ−ＧＰＵ−ＩＣ７１０は、ＳＤＶＯパスの代わりに、共有ＲＡＭ７３６を用いる。ＲＳＭ７３６を用いることによって、転送のためにＳＤＶＯパスを用いる必要性、そしてＳＤＶＯ帯域幅の問題を解消する。加えて、メモリを共有することにより、ＳＵＣ７５０はフレーム情報を直接メモリから読み取ることが可能となり、これによってＭＵ−ＧＰＵ４１２によるメモリ読み取りが不要となる。

機能ユニットの各々に直接Ｓ−バッファ・サポートを含むというように、ＴＳＡ−ＧＰＵ７００のＳＯＣ７１０に、いくつかの追加の最適化を含んでもよい。また、図５に示したような固定サイズのディスプレイによってマルチユーザ・フレーム・サポートを実施する代わりに、ＴＳＡ−ＧＰＵ７００を、対応するリモート端末における解像度及び色の深み(color depth)が一致する多数のディスプレイに対するサポートをマッピングするように設計することもできる。メモリにおける表示を対応するリモート・ディスプレイ・システムとより直接的に照合することにより、メモリ使用の効率向上を達成することができる。

Ｓ−バッファのサポートは、ハードウェアで又は追跡ソフトウェア・レイヤと合わせて用いると、変化が生じ選択的更新ストリームの発生を必要とする表示フレームに対するエンコードの選択において補助することができる。Ｓ−バッファのサポートは、ヘッダ、ステータス・ビット、署名、又はこれら３つの組み合わせを利用することができ、そして固定サイズのタイル又は可変サイズのタイルに基づくこともできる。ＳＵＣ７５０はＳ−バッファのサポートを利用して、選択的更新を必要とする表示のサブフレームを決定することができる。ヘッダ情報は、選択的更新の下流処理に有用であると考えられる。

異なるシステムが、ヘッダのサイズ縮小、又は選択的更新転送の回数減少に最適化することができる。例えば、好適な実施形態では、６４ビットのヘッダを含む、タイルに基づく選択的更新システムを利用することができる。ヘッダの１６ビットは、６４Ｋの可能なＲＴの内のどれが選択的更新の意図した受信先か指定するために、用いることができる。他の１対のビットは、限られた数の固定サイズのタイルの内どれが選択的更新に含まれるかを示すために、用いることができる。更に、ビットの別のセグメントは、選択的更新が対応するディスプレイ上の場所を示すタイル番号を指定する。選択的更新エンコード・データは、ヘッダに追従する。優先順位、誤りチェック、及びその他の追跡情報についての追加ビットも含むことができる。

別の好適な実施形態では、ＳＵＣ７５０はタイルを用いなくてもよいが、選択的更新パケットに必要な記述は多くなる。例えば、タイル位置を指定するために数値を与える代わりに、システムは選択的更新矩形の開始位置を指定するためにＸ及びＹオフセットを要求してもよい。この場合、選択的更新矩形は、水平及び垂直方向双方に対して画素又はブロックの数で記述されることになる。このようなシステムのヘッダ情報は大きくなる場合があるが、リモート端末に対して更新を行うための固有の転送(unique transfer)の回数は少なくて済む。

ＲＴの能力及びホスト１００とＲＴとの間におけるネットワーク特性に応じて、ＴＳＢ４００は、選択的更新を送る代わりに、一部のグラフィクス・コマンドを直接ＲＴに送ることを選択してもよい。これらのグラフィクス・コマンドは、ＴＳＢのＣＰＵサブシステム４０２又はプロセッサ７５６によって管理することができる。また、これらのプロセッサは、DirectX及びＲＤＰコマンド双方に対してコマンド解釈を行うことを含む、プロキシ・サーバ又はその他の端末サービス機能も管理することができる。インタープリタとしては、プロセッサ７５６又はＣＰＵサブシステム４０２は、ホスト・システム上でランするソフトウェア・ドライバを肩代わりさせて、２Ｄグラフィクス・コマンド、３Ｄグラフィクス・コマンド、ビデオ・ストリーム、及びその他のウィンドウ作成機能を管理する。インタープリタの機能をデータ・エンコーダ７５２と組み合わせて、ＲＴ管理の計算集約的な態様の多くを実行することができ、更に、ホスト・システムから種々のＲＴに送られるコマンド、データ、及びビデオ・ストリームを最適化することもできる。プロキシ・サーバは、ＴＳＢ４００とＲＴとの間で分割することもできる。

例えば、種々のパターンBitBlt、ソースから画面宛先BitBlt、及び他のビットマップ転送を強化することができる。ソース・データ、ソース・パターン、又はソース・ビットマップを必要とするグラフィック・コマンドは、ソースをより効率的なフォーマットに、データ・エンコーダ７５２によってエンコードすることができる。エンコードされたソース・データ、ソース・パターン、又はソース・ビットマップは、修正されたグラフィック・コマンドと共にＲＴ３００に転送される。宛先のＲＴは、エンコードされたソースを受信し、それをデコードし、次いで、修正されたグラフィック・コマンドを受信したときに、意図した動作を実行する。エンコード・データ及び修正コマンドの転送は、ＲＤＰ転送、又はＲＤＰ状の転送のいずれかでよく、これらはＴＳＡ−ＧＰＵ７００及びＲＴ３００がサポートする。

ＴＳＢ４００におけるビデオ・ストリームに対して、DirectXインタープリタ・ソフトウェアは、ビデオ・ストリーム処理を傍受し肩代わりし、最適なストリームを目標ＲＴに供給することができる。肩代わりにおける最初のステップは、プロセッサ・ブレード２００がマルチＣＰＵコンプレックス２０２上でビデオ・デコードを実行していないことを確かめることである。ホスト・ベースのデコードには幾つかのマイナス面があり、その内最も重要な２つは、最初に、実際のデコードを行うのに多数のＣＰＵサイクルを要することである。第２に、ホストにおいてビデオ・フレームをデコードしておくことは、目標ＲＴにおいて表示するフレームを得る最良のやり方では必ずしもないということである。代わりに、DirectXインタープリタ・ソフトウェアはDirectXコールを傍受し、Microsoft Windows（登録商標）の中には、圧縮形態のままである間にビデオ・ストリームに対するアクセスを得るためには、DirectShowの使用を伴うバージョンもある。DirectXインタープリタは、ＲＤＰが通常の動作を続けるためには、模造フレームによってＲＤＰソフトウェア・インターフェースを騙さなければならない場合もある。

一方、ＴＳＢ４００は、ＲＴがデコードすることができるビデオ・ストリーム・フォーマットはどれか、ホスト・システムからＲＴまでのネットワーク・スループットが通常はどれくらいか、そしてビデオ・ストリームで意図する解像度及び表示特性は何か把握している。この情報を用いて、ＴＳＢ４００は、着信ビデオ・ストリームを処理しネットワーク、ＲＴ及び表示出力要件に対して理想的なストリームを生成するように、ＴＳＡ−ＧＰＵを設定する。これには、一方のエンコード・フォーマットから他方にトランスコードすること、一方のビットレートから他方にレート変更すること、フレーム・レートを変更すること、表示フォーマットを変更すること、解像度又はこれらのいずれかの組み合わせを変更することを伴う場合もある。次いで、ＴＳＢ４００は、処理したビットストリームをカプセル化し、ネットワーク処理のためにそれを然るべき接続部に送る。

プロキシ・サーバ又はシステム１００上でランするＲＤＰサーバ・ソフトウェアをプロセッサ・ブレード２００とＴＳＢ４００との間で区分するには、いくつかのやり方がある。ここでは、２つの実施形態について詳細に検討する。第１の実施形態は「終了及び再生」(terminate and regenerate)であり、第２の実施形態は「肩代わり及び強化」である。これらの実施形態の変形も可能であり、各実施形態の態様を利用することができる。

「終了及び再生」の場合、ＴＳＢ４００上でＲＤＰクライアントをランさせる。プロセッサ・ブレード２００上で走っているＲＤＰサーバに関する限り、ＲＤＰ動作はＴＳＢ４００によって終了させられる。この場合、ＴＳＢ４００は、ＴＳＡ−ＧＰＵ７００を利用して仮想表示空間を作成し、１つの大きな表示マップを作成することによって多数の仮想ＲＴをサポートし、この大きな表示空間の内部において、各ユーザをオフセットするか、又は各仮想表示を、それ自体のマッピングによって、別個の表示として見る。ＲＤＰクライアント・ソフトウェアは、安全を確保したクライアント通信を要求するＲＤＰホストのために、プロセッサ・ブレード２００とＴＳＢ４００との間で鍵交換及びセキュリティ処理を利用しなければならない場合もある。ＲＤＰクライアントがＲＤＰホストからコマンドを受信すると、クライアントは、ＴＳＡ−ＧＰＵ７００を利用して、表示フレームをディスプレイ・サブシステムに引き渡す。次いで、「終了及び再生」により、ＴＳＢ４００はＴＳＢ４００とＲＴとの間の通信のために望む手段及びプロトコルであればいずれでも用いることができる。

「終了及び再生」動作の好適な実施形態では、ＴＳＢ４００は、多数のＲＤＰクライアントとして構成され、その各々がＲＴに対応する。プロセッサ・ブレード２００は、スイッチ・ファブリックを用いて、「仮想」ＲＤＰクライアントと通信する。次いで、ＴＳＢ４００は、仮想ネットワーク計算（ＶＮＣ）を用いて、ＲＴに対してサーバとして作用する。ＲＴとホスト１００との間の通信は全て、ＴＳＢ４００が管理する。ＲＴからのＶＮＣキーボード及びマウス・コマンドは、ＴＳＢ４００によって、プロセッサ・ブレード２００に対するＲＤＰコマンドに変換される。すると、ＶＮＣを用いるいずれの種類のクライアントでも、主プロセッサ・ブレード２００が非ＶＮＣサーバを走らせているホスト１００と効果的に通信することができるようになる。「終了及び再生」動作の第２の好適な実施形態では、ＴＳＢ４００は、インターネット・サーバとして作用し、ブラウザを走らせているＲＴと通信する。異なるプラットフォーム上の異なるブラウザは通常異なる能力を有するので、ＴＳＢ４００は、異なるＴＨＨＰ、ＸＭＬ、Ｊａｖａ、及びブラウザに基づくクライアントと通信するためのその他のメタデータ・プロトコルをサポートするとよい。

ウェブ・サービスのために、「終了及び再生」機能は、ＴＳＢ４００上で動作するプロキシ・サーバが実行する。プロセッサ・ブレード２００は、ウェブ・サーバをランさせることができ、あるいは別の場所に位置するウェブ・サーバに対する接続を管理することができる。あるいは、ＴＳＢ４００はウェブ・サーバと直接通信することもできる。プロキシ・サーバとしては、ＴＳＢ４００はウェブ動作の全てを終了させる。ＴＳＢ４００は、上流側のウェブ・サーバに継続的に要求を行うＡＪＡＸエージェントのような、エージェントを含むことができる。次いで、ＴＳＢ４００は直接ＲＴクライアントと通信する。ＴＳＢ４００は、ＲＴがサポートするプロトコルであれば任意のものを用いることができ、ＲＴ通信を完全に別個なプロトコルにすることもでき、あるいは同様のウェブに基づくプロトコルを再利用することもできる。

サーバ・ベースの計算の第２の実施形態では、「オフロード及び強化」がクライアント通信におけるプロセッサ・ブレード２００の関与を一層維持する。プロセッサ・ブレード２００上の追跡ソフトウェア・レイヤは、なおもDirectXビデオ、グラフィクス、及びデータ・ストリームをＴＳＢ４００に再送出し、ＴＳＢ４００がDirectXコールの機能を完成させる。機能をオフロードさせることによって、マルチＣＰＵコンプレックス２０２をマルチユーザ・システムの他のユーザも利用できるようにする。表示環境及び最適な処理を可能にするネットワーキング帯域幅を把握することによって、ＴＳＢ４００によって更に多くの処理を完成させることができる。

また、グラフィクス・コマンドをローカルに実行し、かつＲＴに転送して送るときに、ＴＳＡ−ＧＰＵ７００によってＳ−バッファを管理するために、ＴＳＢ４００上のインタープリタ・ソフトウェアを用いることができる。ＴＳＡ−ＧＰＵ７００がグラフィクス・コマンドをローカルに実行する理由は、フレーム・バッファの現行のコピーを今後の使用のために管理することができるようにするためである。グラフィクス・コマンドがＲＴにおいて実行されているので、ホスト上でローカル・グラフィクス・コマンドの結果として変化するタイルは、選択的更新ハードウェアにエンコードしたタイルを遅らせる必要はない。これを防止するために、ＲＤＰ追跡ソフトウェアは、どのタイルがグラフィクス・コマンドによって影響を受けるか計算する必要がある。これらのタイルに対応するＳ−バッファにおけるステータス・ビットを管理すれば、タイルに基づく選択的更新を実行しないようにすることができる。

また、追跡及びインタープリタ・ソフトウェアは、変化し表示更新ストリームの発生を必要とする表示フレームの選択をエンコードする際に、補助するために用いることができる。尚、エンコードは、リモート・ディスプレイ・システム３００が表示を再生するために必要なデータを減少させるために行われることは上記した通りである。追跡ソフトウェア・レイヤは、フレーム又はタイル内にあるデータの形式を識別し、最適な種類のエンコードを実行できるようにするのに役立つ。一部のＲＴは、グラフィクス・コマンドを実行するための十分なグラフィクス処理能力を有しておらず、ＴＳＡ−ＧＰＵ７００が処理したエンコード・データが送られることもある。

例えば、追跡ソフトウェア層が、タイルの表面がリアル・タイム・ビデオであることを識別した場合、ビデオには一層効果的であり、スムーズな空間遷移及び時間的局在性 (temporal locality)を有するエンコード方式を、これらのタイルに用いることができる。追跡ソフトウェア層が、タイルの表面が殆どテキストであることを識別した場合、鋭い縁及びテキストの広い白色空間に一層効果的なエンコード方式を用いることができる。どの形式のデータがどの領域にあるか識別することは、複雑な問題である。しかしながら、追跡ソフトウェア層のこの実施形態では、ホスト・ディスプレイ・システム及びこの識別において補助するホスト・オペレーティング・システムのグラフィクス・ドライバ・アーキテクチャにインターフェースを組み込むことを可能にする。例えば、Microsoft Windows（登録商標）では、ある種のDirectShowコマンドを利用する表面はビデオ・データである可能性が高く、一方、通常テキストと関連のある、色拡張ビット・ブロック転送（ビット・ブリッツ(Bit Blits)）を用いる表面はテキストである可能性が高い。各オペレーティング・システム及びグラフィクス・ドライバ・アーキテクチャは、それ自体の特性指標を有する。他の実施態様が並行して多数の形式のデータ・エンコードを実行し、次いでエンコーダのフィードバックに基づいて最良の結果を出したエンコード方式を用いることを選択することができる。

また、この「オフロード及び強化」の第２の実施形態は、ウェブ・ベースのサービスに合わせたプロキシ・サーバ・アーキテクチャと共に利用することもできる。このような実施形態では、ＴＳＢ４００は、ウェブ・サーバと直接通信することができ、あるいはＲＴとウェブ・サーバとの間の通信を調整する分割プロキシとして機能することもできる。ＴＳＢ４００及びＲＴ上でランするエージェントは、種々のウェブ・サーバに継続して要求を行うこともある。ＴＳＢ４００は、ウェブ・サーバ情報を、実際にＲＴが表示のために必要とするまで、キャッシュすることができる。前述のように、ＴＳＢ４００は、種々のグラフィクス及びビデオ・コマンド並びにデータを記録し、又はフォーマットし直して、ＲＴへの通信チャネルにより良く適応させるだけでなく、ＲＴ内部で利用可能な機能及び性能とより良く合わせることができる。種々のコンテンツ管理及びコンテンツ・フォーマット動作は、プロキシ又は分割プロキシ・サーバとして動作するＴＳＢ４００によって実行することができる。

種々のデータ形式に対して、ある種のエンコード方式は特定の形式のデータにはより有用であり、一部のエンコード方式はデータ依存性が低い。例えば、ＲＬＥはテキストには非常に良いが、ビデオには劣っており、ＤＣＴ・ベースの方式はビデオには非常に良いが、テキストには劣っており、ウェーブレット変換ベースの方式は、ビデオ及びテキスト双方にとって満足することができる。このシステムでは、無損失のエンコード又は損失があるエンコードのいずれの種類でも用いることができるが、ウェーブレット変換エンコードは、無損失又は損失型のいずれでも可能であり、特に、周囲のタイルに対する懸念なく各タイルをエンコードすることができる決定論的算術的コーダを用いたプログレッシブ（前進）・ウェーブレット変換は、この用途には特に適している。ＪＰＥＧ２０００ウェーブレット・エンコーダの派生物は、リアル・タイムでの実行を改善するために特別な処理を行っており、可能な実施態様の１つである。

図８は、図２のＢＭＣ８００を更に詳細にした図である。ＢＭＣ８００は、ＣＰＵ８０８を含む。ＣＰＵ８０８は、単純なマイクロコントローラでよく、あるいはキャッシュを備えて一層強力なＣＰＵでもよい。また、ＢＭＣ８００はセキュリティ・プロセッサ８０４、ネットワーク・プロセッサ及びＭＡＣコントローラ即ち「ネットワーク・インターフェース制御」（ＮＩＣ）８０６、ＲＡＭ２１８、インターフェース制御部８１０、並びにある形態のＴＳＡ−ＧＰＵ７００も含む。

ＣＰＵ８０８は、「帯域外」（ＯＯＢ）を処理することができるオンボード・プロセッサである。これは、動的なソフトウェアや介入が主ＣＰＵから要求されないことを意味する。理想的なＢＭＣ８００は、追加の配線(cabling)を全く必要とせず、プロセッサ・ブレード２００の完全なリモート管理運営を可能にする。場合によっては、ＢＭＣ８００は、多数のブレードの管理を行うために、中心に据えてもよい。ここに示すＢＭＣ８００は、キーボード、ビデオ、及びマウス（ＫＶＭ）機能のサポートを含む。システムによっては、ＣＰＵ８０８を、主システムＣＰＵ上でランする仮想マシーンによって、更に強化するとよい。完全にＯＯＢではないが、仮想マシーンは、他のシステム機能と干渉しないように設計する。

ＢＭＣ８００との通信は、セキュリティのために、セキュリティ・プロセッサ８０４を用いて暗号化し、ローカル・ネットワーク・インターフェース２１４を利用することができ、又はバス２０６を通じて、あるいはしかるべき図２のファブリック接続部１４０又は１４２を経由してパケットを転送することもできる。ネットワーク・インターフェースは、図示のように、ＮＩＣ８０６と共に部分的に含めることもでき、ＮＩＣ８０６は、ＭＡＣ部と、任意の場所にある残りの物理インターフェース（ＰＨＹ）とを含む。インターフェース８１４は、外部ＰＨＹ（図示せず）にインターフェースするときには、メディア独立インターフェース（ＭＩＩ）又は縮小版ＭＩＩ（ＲＭＩＩ）のような規格に準拠することができる。外部Ｐｈｙは、専用デバイスとすることも、別のネットワーキング・サブシステムの一部とすることもできる。

ＢＭＣ８００についての表示の態様は、単純から複雑なものまで変化に富む場合があり、１つ以上のローカル又はリモート・ユーザをサポートすることができる。単純なシステムは基本的なグラフィクス・コントローラ及びソフトウェアを利用して表示をエンコードすることができるが、好適な実施形態はグラフィクス加速、選択的更新及び更新のエンコードの精巧な組み合わせを利用し、リモート・ユーザが最大の性能仮想提示(performance virtual presence)を有するようにしている。したがって、ＢＭＣ８００は、表示をサポートするためのＴＳＡ−ＧＰＵ７００の使用を示す。同時ユーザの数に応じて、この種のＢＭＣ８００の用途に合わせたＴＳＡ−ＧＰＵ７００の性能は、ＴＳＢ４００における程高くなくてもよいが、潜在能力は同様であるとよい。

リモート・アクセスのためにサポートする仮想提示機構のレベルを高めることに加えて、オンボード・プロセッサは、温度、電圧、音響、センサ、ＬＥＤを管理するというような、種々のプラットフォーム自動化のための異なるセンサにインターフェースすることもできる。警報の中間レベル・リモート監視も監視し管理する。外部管理システムと通信するために、ＢＭＣ８００はウェブ・サーバを含むことができ、Intelligent Platform Management Interface（ＩＰＭＩ：インテリジェント・プラットフォーム管理インターフェース）及びActive Server Management Interface（ＡＳＭＩ：アクティブ・サーバ管理インターフェース）のようなリモート管理を標準化するための種々の業界の成果に従うことができる。同時多数ユーザ、及びＤＶＤドライブのような仮想Ｉ／Ｏデバイスに対するサポートも含ませることができる。また、ＢＭＣ８００には、インターフェース制御部８１０も示されており、インターフェース制御部８１０は、直接オンボード・センサに、パス８０２を通じてオンボード・センサと通信する外部インターフェース・チップ８５０に、又はパス２１４を通じて別のローカルＩ／Ｏコントローラにインターフェースすることができる。図８に示すようなシステム・バス２０６を利用する代わりに、インターフェース制御部８１０はＢＭＣ８００を、システム管理バスのような、別のバスにインターフェースすることもできる。

図９は、本発明の一実施形態にしたがって端末サービス加速及びプロキシ・サーバ手順を実行する方法ステップのフローチャートである。明確化のために、ビデオを含むデータの表示を参照して、この手順を論ずることにする。しかしながら、オーディオ、キーボード、マウス、及びその他のデータに関する手順も同様に、本発明と共に用いることができる。最初に、ステップ９１０において、マルチユーザ・コンピュータ１００及びリモート端末システム３００は、種々の手順にしたがって、種々のサブシステムが各ＲＴをイネーブルするために、ホスト側及び端末側を初期化し設定する。ステップ９１２において、アプリケーションが、更新表示データを、表示コマンド、表示データ更新、又はビデオ・データ・ストリームの形態で供給する。アプリケーション更新は、アプリケーション自体、クライアントにおけるユーザの行為、又はアプリケーションにおける他の何らかのエージェント、プロキシ・サーバ、あるいはクライアントから開始することができる。アプリケーションの要求は、ホストＣＰＵ上で走る追跡ソフトウェア・レイヤによって傍受することができ、あるいはコマンドは、ＴＳＢ４００上で走っているプロキシ・サーバ又は端末サービス・アクセレレータによって傍受することもできる。ステップ９１２において、ＢＭＣ８００のために、追跡ソフトウェア・レイヤを含ませず、ＢＭＣ８００はホストＣＰＵとは独立して動作する。

グラフィクス動作が２Ｄ描画を含む場合、ステップ９２４において、２Ｄ描画エンジンＭＵ−ＧＰＵ４１２が動作を処理し、しかるべき仮想表示をＲＡＭ４３０内に生成することが好ましい。同様に、ステップ９２６において、３Ｄ描画をＭＵ−ＧＰＵ４１２によって実行して、しかるべき仮想表示をＲＡＭ内に生成する。ステップ９２８において、ＴＳＢ４００は、ビデオ又はグラフィクス・コマンドをしかるべきＲＴに転送することを決定することができる。ステップ９５０までのフローは、バイパス・ステップ９２８による影響を受けずに済む。ステップ９４０において、ＭＵ−ＧＰＵ４１２は各仮想表示を合成して、表示に適したフレームを形成する。この合成は、ＣＰＵサブシステム２０２、２Ｄエンジン、３Ｄエンジン、及びＧＰＵ４１２内部にある任意のビデオ処理エレメントによる動作の任意の組み合わせで実行することができる。合成ステップの一部として、Ｓ−バッファの管理をグラフィクス処理ハードウェアに含むＭＵ−ＧＰＵ４１２のために、描画エンジンは、それぞれのタイル毎にＳ−バッファを更新する。

リターン・パス９４４によって示されるように、ＴＳＢ４００は、必要に応じて、同じＲＴ又は異なるＲＴのために次のフレームを処理することができる。好適な一実施形態では、ＴＳＢ４００は、アプリケーション・サーバに関する限り、クライアントは最後まで完了した描画動作を有するように、完全なクライアント・スタックをランさせることができる。同様に、ＴＳＢ４００は、ウェブ・サーバに関するウェブ・クライアント動作を完成するために、プロキシ・サーバ又は分割プロキシ・サーバとして作用することもできる。ＴＳＢ４００は、多数のユーザを列挙するためにクライアント・プロトコルをランさせることができる。一旦ＴＳＢ４００が、クライアント側動作が完了したサーバに通信したなら、ＴＳＢ４００はその時点で意図するコマンド又は表示データを目標のＲＴに中継するためにいずれのメカニズムでも用いることができる。先に述べたように、ＴＳＢ４００は既存のコマンドを再度送ること、修正したコマンドの様式を変更すること、又は表示更新をＲＴに反映する別のメカニズムを用いることができる。

コマンド傍受の一部として、ＴＳＢ４００はローカル仮想表示メモリにおいて意図したＲＴ表示画面を完全に合成することができる。一旦合成動作を行ったならば、ステップ９４６において、タイル及び関連するＳ−バッファ・ステータス・ビット、並びに該当する場合には署名ビットを管理する。ステップ９４６では、Ｓ−バッファ・ステータス・ビットに影響を及ぼす可能性があるビデオ及びグラフィクス迂回ステップ９２８によって処理されたいずれのグラフィクス及びビデオ動作をも考慮する。例えば、描画動作がステップ９２４において実行され、ステップ９２８を通じてリモート端末に迂回された場合、描画動作による影響を受けるタイルに対して選択的更新を行う必要なない。何故なら、この動作はＲＴにおいて行われるからである。

ＭＵ−ＧＰＵ４１２内部で又はＴＳＡ４２４との組み合わせで行われる、タイルに対するステータス・ビット及び署名の処理がステップ９４６において行われた場合、ステップ９５０では、ファイルの選択的更新を行うことができる。タイルは、固定又は可変サイズにすることができる。タイルと共に含まれるヘッダ情報は、フォーマット、及び意図するＲＴ宛先を示す。ステップ９５４において、ＴＳＡ４２４は、ステップ９５０から受けたタイルの必要なエンコードを実行する。このエンコードは、決定論的方式として、タイル内部にあるデータの方位及び周囲のタイルを、エンコード・ステップにおいて考慮する必要をなくすことが好ましい。また、ステップ９５４において、ステップ９２８に続くビデオ・データ及びグラフィックス・コマンドを処理する。ビデオ・データのレートを変更することができるが、この場合、ビットレート又はフレームレートを変更し、周波数又は空間のいずれかのドメインにおいてスケーリングし、必要な場合、異なるエンコード規格にトランスコードする。リターン・パス９６８を通じたネットワーク・フィードバックは、ＲＴ情報と共に、エンコードのステップ９５４を判断するのに役立つことができる。

また、ステップ９５４では、グラフィクス・データのエンコードを伴う可能性がある、追加の処理を必要とするいずれのグラフィクス動作をも実行する。ステップ９５８において、ＴＳＡ４２４又はＣＰＵ４０２は、以前のステップにおいて処理したグラフィクス・コマンド、データ転送、又はビデオ転送の更なるカプセル化を実行する。また、このステップにおいて、帯域幅及びレイテンシのようなネットワーク特性、並びに特定のパケット・サイズ及び送信の問題に関して、ネットワーク・フィードバックを考慮する。ステップ９６２において、カプセル化したパケットを、しかるべきネットワーク・コントローラによって処理し、パケットをネットワークに沿ってしかるべきＲＴ３００に転送する。

ステップ９６２におけるネットワーク・プロセスでは、システム制御からの情報を用いる。この情報は、どのリモート・ディスプレイがどのフレーム更新ストリームを要求しているか、フレーム更新ストリーム毎にどの種類のネットワーク送信プロトコルを用いるのか、そして各フレーム更新ストリームの各部分について、優先度及び再指向特性はどのようになっているかに関する情報を含むことができる。ネットワーク・プロセス・ステップ９６２は、ローカルＩ／Ｏ４２８及びローカル・ネットワーク接続部４９０を利用して、ＴＳＡに対してローカルに管理することもできる。あるいは、ブレードに基づくシステムでは、ネットワーク・レディ・パケット(network ready packet)を、システム・ファブリック・バス１４０又は１４２の一方を通じて転送し、ネットワーク接続部を含むプロセッサ・ブレード２００によって、又は別のプロセッサ・ブレード上に位置するネットワーク・プロセッサによって処理することもできる。種々のネットワークには、ギガビット・イーサネット、１０／１００イーサネット、電力線イーサネット、同軸ケーブルを用いたイーサネット、電話線を用いたイーサネット、あるいは８０２．１１ａ、ｂ、ｇ、ｎ、ｓのようなワイヤレス・イーサネット規格、及び今後の派生物を含むことができる。その他のイーサネット以外の接続も可能であり、ＵＳＢ、１３９４ａ、１３９４ｂ、１３９４ｃ、あるいは超広帯域（ＵＷＢ）又はＷｉＭＡＸのようなその他のワイヤレス・プロトコルを含むことができる。

図１０は、本発明の一実施形態にしたがってネットワーク受信及び表示手順を実行する方法におけるステップのフローチャートである。明確化のために、ビデオを含む表示データを参照して、この手順を論ずることにする。しかしながら、オーディオ及びその他のデータに関する手順も、等しく本発明と共に用いることを想定している。ＲＴ３００は、機能的動作を実行するために単純な制御プログラムをランさせるように構成することができ、ドライバ又はアプリケーションをランさせるオペレーティング・システムに基づくプロセッサとすることができ、あるいはＪＡＶＡ処理又は高度ＡＪＡＸ処理を含むより多くのエージェントを含んでも含まなくてもよい何らかの種類のクライアント上でランするブラウザとすることもできる。加えて、ＲＴ３００は、表示の更新が生ずる結果となるユーザの行為又はエージェントの動作に基づいて要求を開始することもできる。

図１０の実施形態では、最初に、ステップ１０１２において、リモート端末３００がパス３９０を通じて、ホスト・コンピュータ２００からネットワーク送信を受信することが好ましい。次いで、ステップ１０１４において、ネットワーク・コントローラ３３６はネットワーク処理手順を行ってネットワーク・プロトコルを実行し、有線又は無線で送信された送信データを受信することが好ましい。

ステップ１０２０において、ＣＰＵ３２４は到来する送信データを解釈して、送信が意図するのはどの機能ユニットか判断する。着信した送信が２Ｄグラフィクス・コマンドである場合、ＣＰＵ３２４は２Ｄ描画エンジン３３２を通じて動作を初期化し、３Ｄコマンドの場合、３Ｄ描画エンジン３３４を初期化し、ビデオ・データ・ストリームの場合、ビデオ・デコーダ３２８を初期化し、データのエンコードしたタイルである場合、データ・デコーダ３２６を初期化する。描画コマンドの中には、描画エンジン及びデータ・デコーダ３２６双方を利用する場合もある。場合によっては、着信した送信データを格納しておき、必要なときに用いることができるようにする。種々の形態のＡＪＡＸ及びエージェント処理が最終的に必要となることもならないこともあるデータについて、思惑的な要求を行うことがある。

色々な数のコマンド及びデータ転送が行われ、種々の機能ユニットが動作し、好ましくはデータ情報を操作して、しかるべき表示可能なフォーマットにする。ステップ１０３０において、機能的ユニットの各々からの操作後のデータを、フレーム・マネージャ３３０によって組み立てて、ＲＡＭ３１２の中に更新表示フレームを生成することができる。更新表示フレームは、以前のフレームからの表示フレーム・データ、操作及びデコードした新しいフレーム・データ、並びに新しいフレーム・データの送信中に発生した表示データの誤りを隠蔽するために必要なあらゆる処理を含むことができる。

最後に、ステップ１０４０において、ディスプレイ・コントローラ３３０は、最後に完成した表示フレーム・データを、リモート端末システム３００のユーザが見るために、リモート端末表示画面３１０に供給する。表示のリフレッシュは、フリッカを回避するために、リモート端末コントローラ３１４とディスプレイ３１０との間において毎秒６０〜７２回行われる非同期動作である。ステップ１０３０において新しい表示フレームを生成することは殆ど行われないのが通例であるが、必要なときには、毎秒３０フレーム以上で行うとよい。スクリーン・セーバ即ちパワー・ダウン・モードがない場合、ディスプレイ・プロセッサは、表示リフレッシュのプロセスにおいて、フィードバック・パス１０５０で示すように、最後に完成した表示フレームを用いて、リモート表示画面３１０を更新し続ける。

したがって、本発明は、ユーザが多種多様なアプリケーションにおいて効果的に利用することができるリモート端末をサポートする、マルチユーザ・サーバに基づくコンピュータ・システムを実施する。例えば、ある会社(business)が１つの場所において多数の棚にコンピュータ・システムを展開し、遠隔地にいるユーザに非常に単純で低コストのリモート端末システム３００を彼らのデスクトップ上に提供する。異なる遠隔地は、ＬＡＮ、ＷＡＮ、又はその他の接続を通じてサポートすることができる。ＲＴは、デスクトップ・パーソナル・コンピュータ又はノートブック・パーソナル・コンピュータとすればよく、別のシステムでは、セル・フォン、パーソナル・ディジタル・アシスタントのような特殊デバイス(specialty device)であっても、携帯用ビデオ・プレーヤ、ゲーム機、又はリモート制御システムのようなその他の消費者向け製品と組み合わせてもよい。ユーザは、マルチユーザ・システム１００のホスト・コンピュータを柔軟に利用して、ホスト・システムがローカル・ユーザに提供することができるのと同じレベルのソフトウェア互換性及び同様のレベルの性能を達成することができる。したがって、本発明は、種々の異質なコンポーネントを利用してシステム相互動作性及び機能性の最適化を促進する、柔軟性のあるマルチユーザ・システムを効果的に実施する。

以上、好適な実施形態を参照しながら、本発明について説明した。この開示を参考にすれば、他の実施形態も当業者には明白であろう。例えば、本発明は、前述の好適な実施形態において説明した構成以外の構成を用いても容易に実施することができる。加えて、本発明は、好適な実施形態として先に説明したシステム以外のシステムと共にでも効果的に用いることができる。したがって、好適な実施形態に対するこれら及びその他の変形は、本発明の範囲に該当することを意図しており、本発明は、添付した特許請求の範囲によってのみ限定されるものである。

多数のブレード及び切換ファブリックを含む、従来技術のブレード・ベースのマルチユーザ・コンピュータ・システムのブロック図である。 本発明の第１実施形態による、リモート・キーボード、ビデオ及びマウス（ＫＶＭ）サポートを備えた、マルチＣＰＵコンプレックス及びベースボード管理制御部（ＢＭＣ）を有するマルチＣＰＵプロセッサ・ブレードのブロック図である。 図１のブレード・ベースのマルチユーザ・コンピュータ・システムとネットワークを通じて接続されているＲＴを示す図である。 本発明の第２の実施形態による端末サービス・ブレード（ＴＳＢ）のブロック図である。 ８つのディスプレイ・エリアに編成されたメモリを表す図であり、その１つはディスプレイ・ウィンドウを含み、その２つは１つの大きなＲＴディスプレイをサポートするために用いられる。 図５のディスプレイ・マップ５３６の更に詳細な図を示す。 タイルに再分割した図６Ａの矩形を示す図である。 図４の一体化グラフィクス・プロセッサ・ユニット（TSA-GPU 700)を有するシステム・オン・チップ（ＳＯＣ）端末サービス・アクセレレータの一例の詳細を示すブロック図である。 グラフィクス・サブシステム及びその他の大域外処理を含む、ＫＶＭを備えたベースボード管理コントローラのブロック図である。 本発明の一実施形態にしたがって、端末サービス及びディスプレイ・プロキシ・サーバ動作を実行する方法のフローチャートである。 本発明の一実施形態にしたがって、リモート端末のためのネットワーク受信及び表示手順を実行する方法のフローチャートである。

Claims (12)

1. 多数のリモート端末のウェブ・コンテンツ・アクセスをサポートすることができるプロキシ機能を実行するディスプレイ・プロキシ・サーバ・システムであって、
   前記多数のリモート端末のための表示フレームを格納することができる表示メモリを有するグラフィクス・プロセッサ・サブシステムを備え、
   前記グラフィクス・プロセッサ・サブシステムは、
   １つ以上のリモート端末における表示フレームに対応する表示フレームを生成する動作であって、前記表示フレームがサブフレームを有し、それぞれの該サブフレームのサイズは、該サブフレームをエンコードするために選択されたアルゴリズムの最小画素ブロックサイズの倍数として、前記ディスプレイ・プロキシ・サーバ・システムによりラン・タイム期間に動的に構成可能であり、該アルゴリズムは前記サブフレーム内のコンテンツの特性に基づいてラン・タイム期間に選択される動作と、
   前記表示フレームの修正されたサブフレームを追跡し、この追跡に基づいて前記表示メモリからの選択的更新を実行する動作であって、前記追跡が、前記修正されたサブフレームに対応する署名を生成し、前記修正されたサブフレームに対して署名チェックを実行し、サブフレームが選択的更新を要求することを示すステータス・ビットを更新し、前記修正されたサブフレームに含まれるデータの形式を決定し、該形式に基づいてエンコード・アルゴリズムを選択することを含む動作と、
   １つ以上のホストＣＰＵが走らせる１つ以上の仮想マシーン上で動作するオペレーティング・システムに対応するグラフィックス・ドライバを含む仮想抽象レイヤを介して前記仮想マシーンからのコマンドと要求とに応答する動作と
   を行うように構成され、
   前記ディスプレイ・プロキシ・サーバ・システムは、グラフィックス動作を要求するよう構成された前記１つ以上の仮想マシーンを走らせている前記１つ以上のホストＣＰＵと通信し、仮想マシーン・グラフィックス要求を管理し、前記仮想マシーン・グラフィックス要求を用いて、グラフィックス動作を要求した仮想マシーンに対する仮想表示を生成し、前記リモート端末に対応するネットワークを介して前記仮想表示のエンコードされた更新を送信し、前記選択的更新のみが前記リモート端末に対応するネットワーク・サブシステムを通じて転送されるように、前記表示メモリからの選択的更新を管理する
   ことを特徴とするディスプレイ・プロキシ・サーバ・システム。
2. 請求項１記載のシステムにおいて、前記ディスプレイ・プロキシ・サーバ・システムはブレード・システムに実装され、１つ以上のホストＣＰＵとシステム・バックプレーン上で接続されることを特徴とするシステム。
3. 請求項１記載のシステムにおいて、前記ディスプレイ・プロキシ・サーバ・システムは、アプリケーションを走らせるホストＣＰＵと通信し、前記アプリケーションがあたかもクライアントであるかのように前記アプリケーションに応答し、前記リモート端末に対して選択的表示更新を実行するよう構成されていることを特徴とするシステム。
4. 請求項記載１のシステムにおいて、前記ディスプレイ・プロキシ・サーバ・システムは、ウェブ・アクセスを実行するときに、前記多数のリモート端末にＤＮＳ参照機構を提供するよう構成されていることを特徴とするシステム。
5. １つ以上のリモート端末のウェブ・コンテンツ・アクセスをサポートすることができるプロキシ機構を実行するよう構成された表示管理システムであって、
   前記システムは、グラフィクス・プロセッサ・サブシステムを備えており、
   前記グラフィクス・プロセッサ・サブシステムは、
   表示フレーム・データを発生するために、ホストＣＰＵの要求時に表示メモリにおいてグラフィクス・プロセッサ動作を実行する動作と、
   表示フレームの修正されたサブフレームを追跡し、この追跡に基づいて選択的更新を行い、前記修正されたサブフレームに対応する署名を生成し、前記修正されたサブフレームに対して署名チェックを実行し、サブフレームが選択的更新を要求することを示すステータス・ビットを更新し、前記修正されたサブフレームに含まれるデータの形式を決定し、該形式に基づいてエンコード・アルゴリズムを選択する動作であって、前記サブフレームに対するサイズは、該サブフレームをエンコードするために選択されたアルゴリズムの最小画素ブロックサイズの倍数として、前記ディスプレイ管理システムによりラン・タイム期間に動的に構成可能であり、該アルゴリズムは前記サブフレーム内のコンテンツの特性に基づいてラン・タイム期間に選択される動作と、
   前記選択的更新を、表示ウィンドウと周囲の画素との位置合わせによるアーチファクトが最小になるようにエンコードする動作と、
   前記選択的更新のみがネットワーク・サブシステムを通じて前記リモート端末の対応するものに転送されるように、前記表示メモリからの選択的更新を管理する動作と
   を行うように構成され、
   前記表示管理システムは、更に、グラフィックス動作を要求する１つ以上の仮想マシーンを走らせている１つ以上のホストＣＰＵと通信し、仮想マシーン・グラフィックス要求を管理し、前記仮想マシーン・グラフィックス要求を用いて、グラフィックス動作を要求した仮想マシーンに対する仮想表示を生成し、対応する前記リモート端末にネットワークを介して前記仮想表示のエンコードされた更新を送信するように構成されている
   ことを特徴とする表示管理システム。
6. 請求項５記載のシステムにおいて、前記選択的更新は、前記表示メモリのサイズにしたがって規定されたタイル・サイズのサブフレームに基づくことを特徴とするシステム。
7. 請求項５記載のシステムにおいて、前記表示管理システムは、選択的更新を管理するためにバッファを用いることを特徴とするシステム。
8. 多数のリモート端末のウェブ・コンテンツ・アクセスをサポートすることができるプロキシ機能を実行するよう構成された、ブレードに基づくマルチユーザ・システムであって、
   前記システムは、バックプレーンに接続されている１つ以上のプロセッサ・ブレードと、リモート端末に対する表示フレームを格納することのできる表示メモリを有するグラフィクス・プロセッサ・サブシステムを含む１つ以上の端末サービス・アクセレレータ・ブレードと、肩代わりサブシステムとを備えており、
   前記グラフィクス・プロセッサ・サブシステムは、
   リモート端末における表示フレームに対応する表示フレームを生成する動作であって、前記表示フレームがサブフレームを有し、それぞれの該サブフレームのサイズは、該サブフレームをエンコードするために選択されたアルゴリズムの最小画素ブロックサイズの倍数として、前記グラフィックス及びディスプレイ・サブシステムによりラン・タイム期間に動的に構成可能である動作と、
   修正されたサブフレームを追跡し、この追跡に基づいて前記表示メモリからの選択的更新を実行する動作であって、前記追跡が、前記修正されたサブフレームに対応する署名を生成し、前記修正されたサブフレームに対して署名チェックを実行し、サブフレームが選択的更新を要求することを示すステータス・ビットを更新することを含む動作と、
   前記修正サブフレームに含まれるデータの形式を識別して、該形式に対する特徴に基づいてエンコード技術を決定する動作と、
   １つ以上の仮想マシーン上で動作するオペレーティング・システムに対応するグラフィックス・ドライバを含む仮想抽象レイヤを介して前記１つ以上の仮想マシーンからのコマンドと要求とに応答する動作と
   を行うように構成され、
   前記肩代わりサブシステムは、
   前記１つ以上のプロセッサ・ブレードがグラフィックス・コマンド又はビデオ・データを処理する前に、且つ、前記グラフィックス・コマンド又は前記ビデオ・データが前記プロセッサ・ブレードにより処理されないように前記リモート端末へ前記グラフィックス・コマンド又は前記ビデオ・データを送る前に、前記グラフィックス・コマンド又は前記ビデオ・データを傍受する動作と、
   ネットワーク状態と表示特性と前記リモート端末のビデオ・デコード能力とに基づいて、傍受された前記グラフィックス・コマンド又は前記ビデオ・データを処理する動作であって、１つのエンコードされたフォーマットから他のエンコードされたフォーマットへのコード変換と、１つのビット・レートから他のビット・レートへの変更と、フレーム・レートの変更と、表示フォーマットの変換と、解像度の変更とのうちの少なくとも１つを含む動作と、
   前記プロセッサ・ブレードを前記１つ以上の端末サービス・アクセレレータ・ブレードに接続する動作と、
   を行うように構成され、
   更に、前記マルチユーザ・システムは、
   前記選択的更新のみがネットワーク・サブシステムを通じて前記リモート端末の対応するものに転送されるように、前記表示メモリからの選択的更新を管理する動作と、
   グラフィックス動作を要求する１つ以上の仮想マシーンを走らせている１つ以上のホストＣＰＵと通信し、仮想マシーン・グラフィックス要求を管理し、前記仮想マシーン・グラフィックス要求を用いて、グラフィックス動作を要求した仮想マシーンに対して仮想表示を生成する動作と、
   対応する前記リモート端末にネットワークを介して前記仮想表示のエンコードされた更新を送信する動作と
   を行うように構成されている
   ことを特徴とするマルチユーザ・システム。
9. 請求項８記載のシステムにおいて、前記１つ以上の端末サービス・アクセレレータ・ブレードが、アプリケーション・ソフトウェアを実行するホストＣＰＵと通信するよう構成され、
   前記ホストＣＰＵは、前記グラフィクス及びディスプレイ・サブシステムを仮想化するマルチユーザ・リモート・クライアント・プロトコルを利用し、仮想グラフィクス機能を前記リモート・ユーザ・クライアントとして実行し、前記選択的表示更新を、前記仮想ディスプレイ・サブシステムから前記リモート端末に対して実行するよう構成されている
   ことを特徴とするシステム。
10. 請求項８記載のシステムにおいて、前記端末サービス・アクセレレータ・ブレードは、１つ以上の仮想マシーンを実行する１つ以上のＣＰＵと通信するよう構成され、
    前記仮想マシーンの各々は、前記端末サービス・ブレードがあたかも各仮想マシーン専用のそれぞれのグラフィクス・コントローラを含むかのように、グラフィクス動作を要求する
    ことを特徴とするシステム。
11. 請求項８記載のシステムにおいて、前記プロセッサ・ブレードはウェブ・サーバとして動作することを特徴とするシステム。
12. 請求項８記載のシステムにおいて、前記ブレードに基づくマルチユーザ・システムは、多数のウェブ・サーバにアクセスする多数のリモート端末にインターネット・サービス管理機能を提供することを特徴とするシステム。

Images