JP2002512395A

JP2002512395A - 仮想デスクトップ・システム・アーキテクチャを提供するための方法および装置

Info

Publication number: JP2002512395A
Application number: JP2000545088A
Authority: JP
Inventors: ノースカット，ジェイ・デュアン; ハンコ，ジェームズ・ジイ; ルバーグ，アラン・ティ; ウォール，ジェラルド・エイ; ブッチャー，ローレンス・エル; ウィルヘルム，ニール・シイ
Original assignee: Sun Microsystems Inc
Current assignee: Sun Microsystems Inc
Priority date: 1998-04-20
Filing date: 1999-04-20
Publication date: 2002-04-23
Also published as: KR20010042901A; WO1999054804B1; WO1999054804A2; AU3863899A; WO1999054804A3; CN1346564A; CN1310487C; WO1999054804A9; EP1074137A2; CA2329199A1; AU763158B2; US7346689B1; KR100742436B1

Abstract

(57)【要約】本発明は計算用の中央局メタファを提供し、その特徴と機能は１つまたは複数のサーバによって提供され、ネットワークを介して機器端末に伝達される。データ・プロバイダは、「サービス」と定義され、１つまたは複数の処理資源によって提供される。サービスは、イーサネットなどのネットワークを介して表示端末と通信する。端末は、データを表示し、ネットワークを介して処理サーバにキーボード・データ、カーソル・データ、オーディオ・データ、およびビデオ・データを送信するように構成されている。機能は分割されており、サービスによってデータベース、サーバ、およびグラフィカル・ユーザ・インタフェース機能が提供されるようにされ、人間インタフェース機能は端末によって提供される。各種サービスからの端末との通信は、異なる出力を共通プロトコルに変換することで行われる。サービスごとにプロトコル変換を行う適切なドライバを用意する。複数の端末をネットワークに結合する。ユーザは、「スマート・カード」をカード・リーダーに挿入することによりいずれかの端末で一意的なセッションを有効にすることができる。カードを取り外すと、セッションは無効になる。カードを再度同じ端末または他の端末に挿入すると、セッションが再度有効になる。

Description

【発明の詳細な説明】

【０００１】〔発明の背景〕〔１．発明の分野〕本発明は、コンピュータ・システムの分野に関する。

【０００２】本特許文書の開示の一部には、著作権保護の対象となる資料が含まれている。
著作権所有者は、特許商標局のファイルおよび記録に記載されているとおり、特
許文書または特許開示の複製を拒絶していないが、他の方法ですべての著作権を
留保しているＳｕｎ、ＳｕｎＭｉｃｒｏｓｙｓｔｅｍｓ、Ｓｕｎのロゴ、Ｊａ
ｖａ、ＪａｖａＢｅａｎｓ、ＨｏｔＪａｖａ、およびすべてのＪａｖａベースの
商標およびロゴは、米国およびその他の国々においてＳｕｎＭｉｃｒｏｓｙｓ
ｔｅｍｓ，Ｉｎｃ．の商標または登録商標である。

【０００３】〔２．背景技術〕コンピュータ・ユーザは、ますます低コストで高性能な計算装置を望んでいる
。このような要求に応えようとする現在の試みの結果、少しばかり安価であって
も、性能は著しく劣る計算システムが構築された。コンピュータ・ユーザが選択
できるのは、かなり性能の劣るコンピュータにわずかに安い金額を支払うという
ことである。解決すべき問題は、かなり低いコストで相当以上の性能を持つコン
ピュータをいかにして得るかということである。この問題は、計算システムの発
展を再検討することで理解が深まる。

【０００４】コンピュータ・システムの構成におけるパラダイム（典型例）は年月の経過と
とももに変化してきた。初期の頃には、コンピュータは一部屋分のサイズの装置
であり、ユーザがコンピュータのすぐ近くにいてアクセスしていた。このような
コンピュータは、「メインフレーム」コンピュータと呼ばれていた。結局、多数
のユーザがメインフレームの計算能力にアクセスできるようにすることが望まし
くなった。その結果、複数のいわゆる「ダム・ターミナル(dumb terminals)」を
使用し、ネットワーク経由でメインフレームと通信することになった。メインフ
レームは、計算能力とデータ記憶装置を備えた中央ステーションであった。ダム
・ターミナルは、メインフレームによって提供されたデータ用の表示デバイスで
あり、またある種のデータをメインフレームに伝達するための手段ともなった。
こうした端末のことをダム・ターミナルと呼ぶのは、ローカルで処理する能力や
データ記憶機能を保有していなかったからである。端末は、メインフレーム・ネ
ットワークとの接続を絶たれると、計算機として使用できない。メインフレーム
／端末アーキテクチャの欠点としては、メインフレーム・コンピュータ自体と関
連する高コストであるという点であった。メインフレームと端末システムを購入
して利用する正当な理由としては、多数のユーザが使用するという大きな関心事
しかなかった。

【０００５】デスクトップ・コンピュータともに呼ばれる、パーソナル・コンピュータの導
入は、メインフレーム・システムの欠点を解決する一手段となった。デスクトッ
プ・コンピュータは、自給自足型の計算システムであり、すべてのアプリケーシ
ョン、データ、および計算能力がデスクトップ・コンピュータ・システム自体に
置かれている。このようなパーソナル・コンピュータにより、家庭とオフィスに
おけるコンピュータの利用に拍車がかかった。デスクトップ・システムのコスト
は、メインフレーム環境に比べて比較的安価である。一人のユーザが１台のデス
クトップ・システムを買える余裕がある。しかし、デスクトップ・コンピュータ
を使用するうえでいくつかの欠点がすぐに明らかになった。欠点の１つが、デス
クトップ・コンピュータの孤立化であった。中央集中型の一貫したネットワーク
の一部ではなくなったため、ユーザが他のユーザとデータを共有することが困難
である。デスクトップ・コンピュータそれぞれにソフトウェアが装備されている
ため、異なるコンピュータ上ではソフトウェア・アプリケーションのバージョン
非互換性の問題が生じた。さらに、オペレーティング・システムが複数あるため
、一部のデータの共有がまったくできない場合や、互換性のある形式に特別に変
換してからでないと共有できない場合がある。

【０００６】クライアント／サーバ・システムの出現により、こうした問題に対する解決策
が提示された。デスクトップ・コンピュータは、会社のネットワークで相互にリ
ンクされるようになった。共通データ、場合によってはアプリケーションは、サ
ーバと呼ばれる中央計算システムに格納される。サーバは、共通データを保持し
、要求があったときにそのコピーをクライアント（デスクトップ・コンピュータ
）に提供する。クライアント・サーバ・システムにも欠点があった。１つは、ハ
ードウェアの旧式化である。デスクトップ・コンピュータはマイクロプロセッサ
で動作するものであり、より高速でより強力なマイクロプロセッサが利用できる
ようになると、既存のデスクトップ・システムのアップグレードや、新しいデス
クトップ・システムの購入が必要になる。多くのオフィスには、パーソナル・デ
スクトップ・コンピュータが全体に分散されており、ときには、数千台、数万台
を数えることもある。システム用ＲＡＭなどの一部のハードウェア・コンポーネ
ントは、デスクトップ・システムをまるごと交換しなくてもアップグレードでき
る。しかし、デスクトップ・システムの使用年数とタイプによって、システム用
ＲＡＭに対し可能なアップグレードには限界がある。アップグレードできたとし
ても、数万台ものデスクトップ・コンピュータのアップグレードのコストは膨大
なものになりうる。同様の問題が、ローカルのハードウェア・ディスク・ストレ
ージのアップグレードにも存在する。システムをアップグレードすることができ
なくなったときに、交換しなければならない。より新しいバージョンのソフトウ
ェア・アプリケーションとオペレーティング・システムを導入するには、場合に
よっては、もはや既存のデスクトップ・システムには合わないハードウェア仕様
を使用する必要がある。これには、数万台ものデスクトップ・コンピュータを交
換する必要があり、３年ごとに実施しなければならない場合もある。

【０００７】このようなシステムの欠点としてもう１つ、個々のシステムにおけるアプリケ
ーションとデータの互換性の欠如があげられる。ユーザによっては、旧バージョ
ンのソフトウェアと下位互換性のない新しいバージョンのソフトウェア・アプリ
ケーションを所有している場合がある。このような問題の解決策は、すべてのシ
ステムで一貫するソフトウェアを保持することである。しかし、各システムをア
ップグレードし、ソフトウェアおよびソフトウェア・アップグレードのライセン
ス付きコピーを提供するコストは、かなりの額に上る可能性がある。さらに、ソ
フトウェアのインストールとソフトウェアのメンテナンスに、大きな管理面の労
力が要求される。リモート・システム管理能力があっても、ソフトウェア・リソ
ースの追跡とカタログ化は煩わしい作業である。会社必須ソフトウェアに加えて
、ユーザは、ネットワーク運用全体に芳しくない影響を及ぼす、娯楽ソフトウェ
ア、ソフトウェア・オプティマイザ、さらには生産性向上ツールなど、無許可の
ソフトウェアを自分のシステムに追加するのがふつうである。それ以上に危険な
のは、ユーザが無許可アプリケーションをインストールすることでコンピュータ
・ウイルスを会社のネットワークに導き入れるということである。

【０００８】最近、インターネットの利用が進み、いわゆる「ネットワーク・コンピュータ
」の利用が提案されるようになった。ネットワーク・コンピュータとは、ストレ
ージ領域、メモリを減らし、そして多くの場合、計算能力を低く抑えた、よけい
なものを取り払ったパーソナル・コンピュータのことである。ネットワーク・コ
ンピュータは、インターネットを介してデータにアクセスし、特定のタスクに必
要なアプリケーションのみをネットワーク・コンピュータに用意するというのが
その考え方である。アプリケーションは、使用し終わっても、ネットワーク・コ
ンピュータ上には格納されない。このようなシステムについては、フル装備のデ
スクトップ・システムの能力を欠いていながら、この能力の低下に見合う程には
安価でないという批判もあった。さらに、ネットワーク・コンピュータがデスク
トップ・システムのサブセットであったとしても、それでもネットワーク・コン
ピュータは適切な性能レベルを維持するためにハードウェアとソフトウェアのア
ップグレードが必要な場合がある。

【０００９】メインフレーム・システムの管理面の容易さをあわせ持ち、ハードウェアの旧
式化が少なく、性能を維持しながらもコスト面でデスクトップ・システムよりも
優れているシステムが要求される。

【００１０】〔発明の概要〕本発明は計算用の中央局メタファを提供し、その特徴と機能は１つまたは複数
のサーバによって提供され、ネットワークを介して機器端末に伝達される。デー
タ・プロバイダは、「サービス」と定義され、１つまたは複数の処理資源によっ
て提供される。サービスは、イーサネットなどのネットワークを介して表示端末
と通信する。端末は、データを表示し、ネットワークを介して処理サーバにキー
ボード・データ、カーソル・データ、オーディオ・データ、およびビデオ・デー
タを送信するように構成されている。機能は分割されており、サービスによって
データベース、サーバ、およびグラフィカル・ユーザ・インタフェース機能が提
供され、人間インタフェース機能は端末によって提供される。各種サービスから
の端末への通信は、異なる出力を共通プロトコルに変換することで行われる。サ
ービスごとにプロトコル変換を行う適切なドライバを用意する。複数の端末をネ
ットワークに結合する。ユーザは、「スマート・カード」をカード・リーダーに
挿入することによりいずれかの端末で一意的なセッションを有効にすることがで
きる。カードを取り外すと、セッションは無効になる。カードを再度同じ端末ま
たは他の端末に挿入すると、セッションが再度有効になる。

【００１１】〔発明の詳細な説明〕本発明は、仮想デスクトップ・システム・アーキテクチャを提供するための方
法および装置である。次の説明では、本発明の実施形態についてより詳しく説明
するため多数の具体的内容を記述している。ただし、当業者であれば、こうした
具体的内容がなくても本発明を実践できることは明白であろう。他の場合には、
本発明をわかりにくくしないため、よく知られている特徴については詳しく説明
していない。

【００１２】本発明は、仮想デスクトップ・アーキテクチャと呼ばれる新しいコンピュータ
・システムを提供する。このシステムは、従来技術のシステムに比べて低いコス
トでかなり高いレベルの機能を備える。本発明は、インストール済みの中央サー
バとユーザ・ハードウェアとの間で機能の再分割を行う。データおよび計算機能
は、中央集中処理配置を用いてデータ資源により提供される。ユーザ側では、ユ
ーザに対し出力を生成するもの（たとえば、表示装置やスピーカ）、ユーザから
の入力を受け取るもの（たとえば、マウスやキーボード）、あるいはユーザが対
話操作するためのその他の周辺装置（たとえば、スキャナ、カメラ、着脱可能記
憶装置など）以外のすべての機能が除かれている。

【００１３】計算はすべて、中央データ資源によって行われ、計算はデータの宛先とは無関
係に実行される。データ資源の出力先は端末であり、「人間インタフェース・デ
バイス」（ＨＩＤ，Human Interface Device）と呼ばれる。ＨＩＤは、データを
受信し、データを表示する機能を持つ。

【００１４】本発明の仮想デスクトップ・システム・アーキテクチャは他の分割度の高いシ
ステムと似ていると思われる。たとえば、パブリックな電話会社は強力で高い処
理能力を保持し、中央局に大規模なデータベースを置いている。しかし、人間イ
ンタフェース・デバイス、すなわち電話器は、比較的単純なものであり、新しい
機能やサービスを電話会社が付加したときでもアップグレードの必要はない。電
話器それ自体は、低コストで、きわめて陳腐化の度合いの低い器具となっている
。それと同様に、ほとんどのコンピュータ・システムの表示モニタも陳腐化の度
合いが低く、ほとんどのデスクトップ・システムのアップグレードにおいてもそ
のままに保持されているのがふつうである。

【００１５】《仮想デスクトップ・システム・アーキテクチャ》このシステムでは、システムの機能は、表示および入力デバイスと、データ・
ソースすなわちサービスとに分割される。表示および入力デバイスは人間インタ
フェース・デバイス（ＨＩＤ）である。このシステムは分割することで、状態お
よび計算機能が、ＨＩＤから除去されて、データ・ソースすなわちサービス上に
置かれる。本発明の一実施形態では、１つまたは複数のサービスがネットワーク
などの相互接続構造(interconnection fabric)により１つまたは複数のＨＩＤと
通信する。このようなシステムの例を図３に示す。図３を見ると、システムは相
互接続構造３０１からＨＩＤ３０２にデータを伝達する計算サービス・プロバイ
ダ３００から成り立っている。

【００１６】《計算サービス・プロバイダ》ＨＩＤシステムでは、計算能力および状態保守は、サービス・プロバイダすな
わちサービス側にある。サービスは、特定のコンピュータに結びつけられてはい
ないが、図１と関連して説明しているものなどの１つまたは複数の従来のデスク
トップ・システム上に分散するか、または従来のサーバで分散できる。１つのコ
ンピュータに１つ以上のサービスを持たせることも、また１つのサービスを１つ
または複数のコンピュータで提供することもできる。サービスでは、計算、状態
、およびデータをＨＩＤに提供し、サービスは共通の当局ないし管理者の制御の
下に置かれる。図３では、サービスはコンピュータ３１０、３１１、３１２、３
１３、および３１４に置かれている。中央データ・ソースも、たとえばインター
ネットやワールド・ワイド・ウェブなど、中央データ・ソースの外部から来るデ
ータを提供できることに注意することが重要である。データ・ソースはさらに、
テレビやラジオの信号などのデータを放送するものなどの放送局（放送エンティ
ティ）であってもよい。

【００１７】サービスの例としては、Ｘ１１／Ｕｎｉｘサービス、アーカイブされているか
若しくはライブのオーディオ又はビデオ・サービス、ＷｉｎｄｏｗｓＮＴサー
ビス、Ｊａｖａ^TMプログラム実行サービスなどがある。ここでサービスとは、出
力データを提供し、ユーザの要求および入力に応答するプロセスのことである。

【００１８】与えられたサービスにアクセスするために現在使用されているＨＩＤとの通信
を処理するのがサービスの役割である。そのために、計算サービスから出力を取
り出して、ＨＩＤ用の標準プロトコルに変換する必要がある。このデータ・プロ
トコル変換は、本発明の一実施形態において、サービス・プロデューサ・マシン
内のＸ１１サーバ、ＭｉｃｒｏｓｏｆｔＷｉｎｄｏｗｓインタフェース、ビデ
オ・フォーマット・トランスコーダ、ＯｐｅｎＧＬインタフェース、またはｊａ
ｖａ．ａｗｔ．ｇｒａｐｈｉｃｓクラスの一変種などのミドルウェア層により処
理される。サービス・マシンは、仮想デスクトップ・アーキテクチャのワイヤ・
プロトコルとの間の変換を処理する。

【００１９】本発明の一実施形態において、各サービスはその性能に合わせて最適化された
計算デバイスにより提供される。たとえば、エンタプライズ・クラスのマシンを
使用してＸ１１／Ｕｎｉｘサービスを提供する、ＳｕｎＭｅｄｉａＣｅｎｔｅ
ｒを使用してビデオ・サービスを提供する、ＨｙｄｒａベースのＮＴマシンでア
プレット・プログラム実行サービスを提供するといったことが可能である。

【００２０】相互接続構造を介して、サービス生成コンピュータ・システムを直接ＨＩＤに
接続する。また、サービス・プロデューサは、３層アーキテクチャのデータベー
ス用コンピュータなどの計算サービスを提供する他のデバイス用のプロキシとす
ることも可能であるが、ただしプロキシ・コンピュータはクエリを生成し、ユー
ザ・インタフェース・コードを実行するだけの場合もある。

【００２１】《相互接続構造》本発明では、相互接続構造はサービスとＨＩＤとの間でデータを伝送するため
の複数の適当な通信経路で構成される。一実施形態において、相互接続構造はイ
ーサネット・ネットワークとして実装されたローカル・エリア・ネットワークで
ある。他のローカル・ネットワークも使用できる。本発明ではさらに、ワイド・
エリア・ネットワーク、インターネット、ワールド・ワイド・ウェブなどの使用
も考慮している。相互接続構造は、ワイヤや光ファイバ・ケーブルなどの物理的
媒体で実装することもできるし、またワイヤレス環境で実装することもできる。

【００２２】本発明の一実施形態において、相互接続構造は、ＨＩＤとアクセスされている
サービスとの間の、能動的に管理され、待ち時間が短い、高帯域幅通信を提供す
る。一実施形態では、協調的（競合とは反対）ネットワーク・トラフィックを持
つ単一レベル交換ネットワークを考慮している。本発明では、専用または共有通
信相互接続を使用することができる。

【００２３】《人間インタフェース・デバイス》ＨＩＤは、ユーザがサービスによって提供される計算サービスにアクセスする
ための手段である。図３には、ＨＩＤ３２１、３２２、および３２３が示され
る。ＨＩＤは、表示装置３２６、キーボード３２４、マウス３２５、およびオー
ディオ・スピーカ３２７から成り立っている。ＨＩＤには、電子回路が備えられ
ており、その電子回路でこれらのデバイスを相互接続構造とインタフェースし、
サービスとの間でデータのやり取りを行う必要がある。

【００２４】ＨＩＤのブロック図を図４に示す。ＨＩＤのコンポーネントはＰＣＩバス４１
２に内部的に結合されている。ネットワーク制御ブロック４０２は、ライン４１
４を介してイーサネットなどの相互接続構造と交信する。オーディオ・コーデッ
ク４０３は、インタフェース４１６でオーディオ・データを受信し、ブロック４
０２に結合されている。ＵＳＢデータ通信機能は、ＵＳＢコントローラ４０１に
つながっているライン４１３で提供される。

【００２５】組込みプロセッサ４０４は、たとえば、Ｓｐａｒｃ２ｅｐであり、フラッシュ
・メモリ４０５およびＤＲＡＭ４０６が結合されている。ＵＳＢコントローラ
４０１、ネットワーク・コントローラ４０２、および組込みプロセッサ４０４は
すべて、ＰＣＩバス４１２に結合されている。さらにＰＣＩ４１２には、ビデ
オ・コントローラ４０９が結合されている。ビデオ・コントローラ４０９は、た
とえば、ＡＴＩＲａｇｅＰｒｏ＋フレーム・バッファ・コントローラであり、
これがライン４１５上にＳＶＧＡ信号を出力する。ビデオ・デコーダ４１０およ
びビデオ・エンコーダ４１１によりビデオ・コントローラとの間でＮＴＳＣデー
タの入出力が行われる。スマートカード・インタフェース４０８も、ビデオ・コ
ントローラ４０９に結合できる。

【００２６】それとは別に、ＨＩＤは、図５に示されているように、シングル・チップ・ソ
リューションを使用して提供することができる。このシングル・チップ・ソリュ
ーションには、ＣＰＵ５０１およびグラフィック・レンダラ５０５を介して実
装されている必要な処理能力を持つ。チップ・メモリ５０７が、ビデオ・コント
ローラ／インタフェース５０６とともに設けられている。ユニバーサル・シリア
ル・バス（ＵＳＢ）コントローラ５０２が設けられて、ＨＩＤに取り付けられる
マウス、キーボード、およびその他のローカル・デバイスと通信することができ
る。サウンド・コントローラ５０３および相互接続インタフェース５０４も備え
られている。ビデオ・インタフェースは、ＣＰＵ５０１およびグラフィック・
レンダラ５０５と、メモリ５０７を共有する。この実施形態で使用するソフトウ
ェアは、ローカルの不揮発性メモリに格納しておくこともできるが、デバイスの
電源投入時に相互接続インタフェースを通じてロードすることもできる。

【００２７】《仮想デスクトップ・システム・アーキテクチャの動作》セッションの処理仮想デスクトップ・システム・アーキテクチャにおけるサービスの提供は、セ
ッションと呼ばれる抽出的作用(abstraction) を中心として行われる。セッショ
ンと言うのは、ユーザのために実行中のサービスについての、任意の時点におけ
る、長い時間存続し、持続的で、信頼できる表現である。新規ユーザがシステム
上で有効にされると新規セッションが作成され、ユーザがシステムから削除され
るとユーザのすべてのセッションは破壊される。セッションなる抽出的作用は、
セッション・マネージャと呼ばれる機能によって保持され、セッション・マネー
ジャは、ユーザとセッションとの間のマッピングのデータベースを保持し、各セ
ッションを構成するサービスを管理することがその役目である。システムが認識
しているユーザごとに、１つまたは複数のセッションがある。セッション・マネ
ージャは、ユーザにサービスを提供し、これにより、セッションの構成および新
規セッションの作成が可能になる。

【００２８】本発明のシステムでは、ユーザは特定のＨＩＤに結びつけられていない。ユー
ザは、ユーザ・セッションと関連付けられており、セッションはユーザがアクセ
スするＨＩＤ上に表示できる。認証マネージャよる抽出的作用は、ユーザの合法
性を保証し、ユーザをそれの所望のセッションに関連付ける役割を持つ。ＨＩＤ
は通常、使用中でなければ、スリープ・モード、スタンバイ・モード、またはオ
フ・モードのいずれいかにある。ユーザが特定のＨＩＤを使用したい場合、認証
交換が行われるが、これは１つまたは複数のスマートカード、キー、パスワード
、および／または生物測定メカニズムで構成されることがある。

【００２９】認証マネージャは、ユーザの確認を行うと、ユーザの現在のセッション・マネ
ージャに通知し、その後、このセッション・マネージャが選択されたセッション
内のすべてのサービスに通知し、セッションの表示をユーザのデスクトップ上に
構成する。ユーザは、セッション内から既存のサービスと対話し、新規サービス
を開始し、あるいは実行中のサービスを停止するなどの操作を行い得る。ユーザ
がＨＩＤから出ると（たとえば、スマートカードを引き抜いて）、認証マネージ
ャはこのことを記憶し、セッション・マネージャに通知し、その後セッション・
マネージャは関連するすべてのサービスに通知し、表示機能を停止し、ＨＩＤは
休眠状態に戻る。ＨＩＤのアクティブ化と非アクティブ化の効果は、デスクトッ
プ・システム上の表示モニタをオフにする操作と似ている。ユーザ・デスクトッ
プはまだ使用可能であり、たぶん実行中であるが、表示は生成されない。本発明
の１つの利点は、接続されている任意のＨＩＤ上でユーザ・デスクトップにアク
セスできるということである。

【００３０】図２は、本発明のセッション管理および許可の例である。これは、本発明の譲
受人に譲渡され、参照により本明細書に記載されたものとする、１９９８年４月
２０日出願の「ＭｅｔｈｏｄａｎｄＡｐｐａｒａｔｕｓｆｏｒＳｅｓｓ
ｉｏｎＭａｎａｇｅｍｅｎｔａｎｄＵｓｅｒＡｕｔｈｅｎｔｉｃａｔｉ
ｏｎ」という名称の米国特許出願第０９／０６３，３３９号に記載されている。
図２において、ネットワーク端末２０２は、人間インタフェース・デバイス（Ｈ
ＩＤ）であり、ユーザにサービスの出力を表示し、ユーザからサービスへの入力
を受け取る作業を受け持つ。ネットワーク端末２０２は、たとえば、計算サービ
ス・プロバイダ上で実行中のソフトウェア・プログラム（たとえば、サービス２
３０〜２３８、認証２０４、およびセッション・マネージャ２０６）から受信し
たコマンド（たとえば、表示コマンド）に応答する機能を持つ。ユーザから受信
した入力は、たとえば、ユーザ要求を遂行しているサービスに転送される。

【００３１】サービスとは、ユーザ用の何らかの機能を実行するプログラムのことである。
複数のサーバがセッションを構成するサービスを実行できる。たとえば、セッシ
ョン２０８で、サービス２３０はサーバ２１０上で実行中で、サービス２３２お
よび２３４はサーバ２１２上で実行中、サービス２３６および２３８はサーバ２
１４上で実行中である。

【００３２】ユーザは、ログインを開始して、システム（たとえば、サーバ、セッション、
サービス、およびネットワーク端末）にアクセスする。ログイン中に、ユーザの
確認が認証マネージャ２０４により実行される。ユーザのログイン用に、さまざ
まな手法を利用できる。たとえば、ユーザはネットワーク端末２０２上のキーを
押してログインを開始できる。

【００３３】本発明の一実施形態では、ユーザは、ネットワーク端末２０２に取り付けられ
ているカード・リーダ（たとえば、カード・リーダ２１６）にスマート・カード
を挿入してシステムにアクセスする。スマート・カードとは、スマート・カード
の磁気ストリップまたはメモリなどに情報を格納することができるカードのこと
である。スマート・カードは、ユーザの識別（すなわち、６４ビットの数値など
のユーザＩＤ）およびネットワーク端末２０２に送信される秘密コード（たとえ
ば、１２８ビット乱数）などのユーザ情報を格納することができる。秘密コード
は、認証時に使用される。

【００３４】ネットワーク端末２０２は、その相互接続ネットワーク・アドレスおよび認証
マネージャ２０４のアドレスを認識（または取得）することができる。ユーザが
ログインを開始すると、ネットワーク端末２０２は認証マネージャ２０４との通
信を開始し、認証を始める。認証マネージャ２０４は、たとえばローカル・エリ
ア・ネットワーク（ＬＡＮ）などの相互接続ネットワークを介してネットワーク
端末２０２に接続されている計算サービス・プロバイダ上でアクティブになって
いる（たとえば実行中の）プログラムである。しかし、ファイバ・チャネル・ル
ープやポイント−ツウ−ポイントのケーブルなどの他の相互接続ネットワーク技
術を使用しても、ネットワーク端末２０２を認証マネージャ２０４に接続できる
ことは明白であろう。ネットワーク端末２０２は、ユーザ識別（ユーザＩＤ）を
含むスタートアップ要求を認証マネージャ２０４に送信する。

【００３５】本発明の一実施形態では、認証マネージャ２０４は、ユーザの確認のため認証
を開始することによりスタートアップ要求に応答する。認証には、システムに対
するユーザの識別を検証するメカニズムを含めることもできる。そのユーザにし
か知られていないキーやパスワード、あるいは生物測定情報を使用して、ユーザ
の認証を実行できる。

【００３６】本発明の一実施形態では、認証は、ネットワーク端末２０２でユーザが入力し
た個人識別番号（ＰＩＮ）を検証することにより実行される。認証マネージャ２
０４はコマンド（すなわち、チャレンジ・コマンド）を送信して、ネットワーク
端末２０２でのユーザのＰＩＮの入力を開始させる。ユーザ入力は、ネットワー
ク端末２０２によってパッケージ化され、認証マネージャ２０４に送信される（
すなわち、チャレンジ応答）。

【００３７】認証マネージャ２０４は、認証データベース２１８に保持されているユーザ情
報、ユーザが提供した情報、および認証時に生成された情報でチャレンジ応答を
検証する。ユーザが認証されると、ユーザはセッション（たとえば、セッション
２０８）にアクセスできるようになる。セッションとは、ユーザのために実行さ
れている１つまたは複数のサービスの関連する集まりの持続的表現である。

【００３８】ユーザから予想される結果が届いた場合、認証マネージャ２０４はセッション
・マネージャ２０６に（接続メッセージを介して）、ユーザがネットワーク端末
２０２でシステムにログインしたことを通知する。認証データベース２１８に格
納されているセッション情報を使用して、セッション・マネージャ２０６のサー
バ、ポート、およびセッション識別子（ＩＤ）を識別する。セッション・マネー
ジャ２０６は、計算サービス・プロバイダ上でアクティブ状態にあるプログラム
であり、たとえば、相互接続ネットワークを介して認証マネージャ２０４とネッ
トワーク端末２０２に接続される。認証マネージャ２０４は、認証データベース
２１８に格納されているセッション・マネージャ２０６のサーバおよびポート情
報を使用してセッション・マネージャ２０６にメッセージを送信する。

【００３９】認証マネージャ２０４からの接続メッセージへの応答として、セッション・マ
ネージャ２０６はユーザの現在のセッションに入っているサービス（すなわち、
セッション２０８のサービス）に、そのユーザがネットワーク端末２０２に接続
していることを通知する。すなわち、セッション・マネージャ２０６は接続メッ
セージをサービス２３０〜２３８に送信し、出力先をネットワーク端末２０２に
させる。セッション・マネージャ２０６は、セッションの要求されたサービスで
あるとみなされるサービスの実行を確保する。もし実行されていなければ、セッ
ション・マネージャ２０６により、サービスが開始させられる。ユーザは、セッ
ション（たとえば、セッション２０８）内でサービス２３０〜２３８と対話する
ことができる。ネットワーク端末２０２は、ローカル・エリア・ネットワークや
その他の相互接続技術などの相互接続ネットワークを介してサーバ２１０、２１
２、および２１４（およびサービス２３０〜２３８）に接続されている。ユーザ
は、さらに、新規サービスを起動したり、既存サービスを終了したりすることも
できる。

【００４０】ユーザは、カードをカード・リーダ２１６から取り出すことで、システムから
離れることができる。さらに切断を表すその他のメカニズムを本発明で使用する
こともできる（たとえば、ネットワーク端末２０２のサインオフ・ボタン）。サ
ービス２３０〜２３８は、ユーザがカードリーダ２１６からカードを抜いた後も
、引き続き実行できる。すなわち、ユーザの関連セッションおよび、セッション
を構成するサービスはユーザがシステムから離れて不在になっている（ログオフ
）期間も存続を続けることができるということである。ユーザがカードをカード
・リーダ２１６から取り出すと、ネットワーク端末２０２は認証マネージャ２０
４に（たとえば、切断（ディスコネクト）メッセージで）通知し、認証マネージ
ャはセッション・マネージャ２０６に（たとえば、切断メッセージで）通知する
。セッション・マネージャ２０６はサービス２３０〜２３８に（たとえば、切断
メッセージで）通知し、これらのサービスはネットワーク端末２０２への表示コ
マンドの送信を終了する。ただし、サービス２３０〜２３８は、ユーザがネット
ワーク端末にログオンしていないときでも実行を続けている。ユーザは、ネット
ワーク端末２０２などのネットワーク端末を使用してまたログインし、セッショ
ン２０８に接続し、サービス２３０〜２３８と対話することができる。

【００４１】ワイヤ・プロトコル本発明では、サービス出力を標準プロトコルに、またはここで呼んでいるよう
に「ワイヤ・プロトコル」に変換することで、計算機能を一部いくつかのサービ
スに分割することができる。ワイヤ・プロトコルの一実施形態の例を、付録とし
て添付した。ワイヤ・プロトコルは、ビデオ・データおよびオーディオ・データ
を処理するためのコマンドを備えている。システムはさらに、帯域幅利用を管理
するメカニズムも備える。

【００４２】ビデオ・データワイヤ・プロトコルは、ユーザのために実行されるサービスのすべての表示操
作をサポートするように設計されたレンダリング・コマンドを備えている。これ
は、すべての表示操作を多数の２Ｄ／矩形操作（たとえば、塗りつぶし(fill)、
コピー、浮彫像(glyph)、点描(stipple) ）に正規化することにより実行される
。イメージまたはビデオ・データの転送のため、ピクセル・アレイ転送操作が用
意されており、圧縮フォーマットを含む異なるフォーマットの小さな集まりを使
用できる。さらに、ワイヤ・プロトコルでは、オーディオ入出力、およびユーザ
接続、切断、および認証を処理する入力デバイス（たとえば、キーボード、マウ
ス）もサポートする。

【００４３】本発明のシステム・アーキテクチャでは、システムのサービス用にレンダリン
グを提供するすべてのＡＰＩが本発明のワイヤ・プロトコルを出力する必要があ
る。これは、一実施形態において、レンダリングＡＰＩでソフトウェア「仮想フ
レーム・バッファ」を使用するようにし、すべてのレンダリング・コマンドを与
えられた高水準ＡＰＩからワイヤ・プロトコルのコマンドに変換することで実現
される。たとえば、Ｘサーバを修正してＳｐａｎｓインタフェースからコマンド
を取り去ったり，ＭｉｃｒｏｓｏｆｔＷｉｎｄｏｗｓのＧＤＩインタフェース
を使用して低水準レンダリング・コマンドへのアクセスを獲得したり、ＭＰＥＧ
ビデオ・デコーダを、そのカラースペースがビデオ・データを変換し拡大縮小す
る地点よりも前のところで分割することができる。同様に、ｊａｖａ．ａｗｔ．
ｇｒａｐｈｉｃｓクラスをサブクラス化して、アプリケーションおよびアプレッ
トがワイヤ・プロトコルを吐き出せるようにすることもできる（それにより、Ｘ
またはＷｉｎｄｏｗｓのレンダリング実行をまとめてバイパスすることで）。

【００４４】２Ｄレンダリングおよびデバイス入力をサポートするほかに、仮想デスクトッ
プ・プロトコルはさらに、マルチメディア・データ・タイプもサポートする。今
日存在している各種のオーディオ／ビデオ・フォーマットを取り扱うために、２
Ｄ表示コマンド・セットのアプローチと似たアプローチが講じられてきた、すな
わち、サービス・プロデューサ上ですべてのレンダリングを実行し、出力を低水
準フォーマットに正規化する。異なるメディア・フォーマットをすべてのＨＩＤ
で認識できる標準化形式に変換することにより、さまざまなフォーマットをサポ
ートするコスト（一連の専用ハードウェアのアップグレードがあろうとソフトウ
ェアのプラグインがあろうと）が低くなる。ビデオおよび画像処理データは、最
小公倍数で正規化される、すなわちアンスケールで、アン−カラー・スペース変
換で、クローマ・サブサンプルでのピクセル（たとえば、ＹＵＶ４２２）である
。このフォーマットは、全コーディング方式の大多数に共通のものであり、プロ
キシ・マシンによるトランスコーディングに役立っている（デコード・パイプラ
インを切り詰め、生ピクセル・データを吐き出す）。さらに、単純な形式の中程
度の圧縮（ソフトウェアによるエンコードもデコードも簡単）のオプション使用
では、圧縮がさらに１／６になり、画質低下に関しては非常に小さい。生のＮＴ
ＳＣビデオは、ＲＧＢフォーマットで送信したときに２４０Ｍｂｐｓの連続デー
タを表す。クローマ・サブサンプルＹＵＶデータは１６０Ｍｂｐｓであり、中程
度の圧縮手法では、フルサイズおよびレートのＮＴＳＣウィンドウ（または４つ
のＳＩＦサイズ・ウィンドウなど）を３０Ｍｂｐｓ程度で転送することができる
。この同じビデオ転送フォーマットを使用して、ビデオ・データをデスクトップ
・デバイスから同様に送信できる。このビデオ・プロトコルは、本発明の譲受人
に譲渡され、引用により本明細書に取り込まれるものとする、１９９８年４月２
０日出願の「ＭｅｔｈｏｄａｎｄＡｐｐａｒａｔｕｓｏｆＳｕｐｐｏｒ
ｔｉｎｇａＶｉｄｅｏＰｒｏｔｏｃｏｌｉｎａＮｅｔｗｏｒｋＥ
ｎｖｉｒｏｎｍｅｎｔ」という名称の米国同時係属出願第０９／０６３，４９２
号に記載されている。

【００４５】オーディオ・データオーディオ・データは、仮想デスクトップ・プロトコルの一部として定義され
ているオーディオ・コマンド・セットによりデスクトップとの間でやり取りされ
る。デスクトップ・デバイスでのオーディオ受信は、「ユニバーサル・レシーバ
」アプローチと考えられるものを通じてサポートされており、任意のサンプル・
レート・データの任意の数のストリームをＨＩＤに送信することができ、適宜ス
トリームを混合し、出力する。たとえば、ＤＡＴ品質のステレオ・オーディオ・
ストリームを４８ＫＨｚ、１６ビット／サンプル・フォーマットで送信すること
ができ、これはデータ・レートの約１．５になる。これらのストリームのいくつ
かと複数の他のオーディオ・ストリームを他のデータ・レートでＨＩＤに送信す
ることができ、これにより、時刻変更と、すべてのストリームの混合を効果的に
行い、システム・オーディオ出力ストリームを生成する。

【００４６】ワイヤ・プロトコルのオーディオ・プロトコル部分は、使用するサービス用の
標準プロトコルを提供するものである。本発明の一実施形態では、レシーバと関
連するオーディオ処理およびハードウェアの要件は、ネットワーク上のトランス
ミッタとレシーバとの間のオーディオ・データの送信用に単一のオーディオ・プ
ロトコルを指定することで最小限に抑えている。このプロトコルでは、サンプリ
ング・レート、ビット分解能、および量子化方式を指定するが、これにより、高
い音質を確保し、レシーバの複雑さをできるだけ抑えることができる。トランス
ミッタには、オーディオ・データを必要に応じて指定プロトコルに変換する機能
を持つドライバが備えられている。

【００４７】ネットワーク上でオーディオ・ストリームを送信する動作と関連する問題を補
正するために指定プロトコルのいろいろな面が用意されている。指定プロトコル
により、データ・パケット内のオーディオ・サンプルをインターリーブするフォ
ーマットを指定し、パケット損失による連続欠損オーディオ・データ・サンプル
の結果である誤差を最小限に抑える。レシーバはさらに、補間により欠損オーデ
ィオ・データ・サンプルを補正することができる。指定プロトコルに応じて、シ
ーケンス・サイズを指定し、オーディオ・データの処理法法を決定する。トラン
スミッタは、各オーディオ・アプリケーション用に指定されている限界内にオー
ディオ待ち時間を維持するため適応によりシーケンス・サイズを制御する。指定
プロトコルはさらに、混合モードの決定を行い、また複数のチャネルを持つオー
ディオ・データを複数のオーディオ出力デバイス間で混合し経路を定める方法を
指定する多数のチャネルを備える。このオーディオ・プロトコルは、本発明の譲
受人に譲渡され、引用により本明細書に取り込まれたものとする、１９９８年４
月２０日出願の「ＭｅｔｈｏｄａｎｄＡｐｐａｒａｔｕｓｏｆＳｕｐｐ
ｏｒｔｉｎｇａｎＡｕｄｉｏＰｒｏｔｏｃｏｌｉｎａＮｅｔｗｏｒ
ｋＥｎｖｉｒｏｎｍｅｎｔ」という名称の米国同時係属出願第０９／０６３，
３４１号に記載されている。

【００４８】帯域幅管理仮想デスクトップ・プロトコル・トラフィックは本質的にバーストが多い。サ
ービス・プロデューサの部分で非活動状態が長い期間続くと、その後きわめて高
い帯域幅バーストが生じ、たとえば、ユーザがデータを読み込むときにトラフィ
ックが生成されず、その後、追加データが要求されたときに全画面更新が実行さ
れる。４０Ｍｂｐｓを超えるピーク時データ・レート・バーストが観察されてい
るが、長期間の平均データ・レートは無視できるくらい小さい。バーストが明確
に規定された限界（すなわち、毎フレーム時間に、すべてのピクセルを変化させ
るための〜２Ｇｂｐｓ）を持つという事実は通常、限界以下に保たれ（すなわち
、通常であれば、画面のピクセルのサブセット、その後次の変更前の期間、一定
のまま）、バーストは無作為に分布し（すなわち、ユーザは独立に操作する傾向
がある）、すべて、統計多重化から生じる利得を利用することに寄与している。
ただし、これは、システム・リソースの需要が供給を超えたときを処理するため
一時的過負荷を処理する手段を用意する必要もある。この目的のために、レート
制御メカニズムを相互接続構造の管理で使用している。これは、プロデューサが
リンク以上のデータを生成せず、人間インタフェース・デバイスが取り扱えるよ
うにするため実行する。このタスクは、与えられた相互接続リンクとともに与え
られたＨＩＤに送信する複数のソースがあるため複雑である。これは、何らかの
形態の分散調整（または協力）を用意し、システムが動作するようにしなければ
ならないことを意味する。この問題を解決する効果的アプローチとして、輻輳回
避およびレート制御手法を使用して、相互接続リソースおよびデスクトップ上の
リソースを管理するという方法がある。現在のＦＴＰ実装の手法と互換性のある
手法を使用することで、仮想デスク・トップ・プロトコル・トラフィックを標準
インターネット・トラフィックと十分共存させることができる。

【００４９】媒体上でデータを送信する複数のデータ・ソースの累積データ・レートが媒体
の帯域幅を超えると、媒体は望むデータ・レートですべてのデータを送信するこ
とができなくなる。媒体の帯域幅限界内でデータ送信を維持するには、データの
一部を遅らせたり、まったく送信しないなどの操作を行う必要がある。しかし、
複数のソースがいろいろな時間にさまざまな量のデータを送信するときには、遅
らせる、あるいは落とすデータの選択はきわめて複雑になる。遅らせる、あるい
は落とすデータの選択が不適切だと、システム・パフォーマンスの著しい低下を
きたすことがある。したがって、有限な帯域幅の媒体上で複数のソースからデー
タの通信を管理する手法が必要であり、その場合、複数のソースの必要な累積帯
域幅は媒体の帯域幅を超えることがある。

【００５０】本発明の一実施形態では、通信媒体を通じて複数のデータ・ソースをデータ・
レシーバに結合する。データ・ソースは、任意の情報ソースでよく、また情報は
任意の種類、あるいは複数の種類であってもかまわない。たとえば、情報として
、コンピュータ・プログラム・コード、テキスト、オーディオ・データ、ビデオ
・データ、図形データ、条件または事象のデータ表現、デジタル情報、アナログ
情報、またはその他の形式のその他の情報がある。データ・ソースの例としては
、コンピュータ機器、オーディオ・デバイス、ビデオ・デバイス、ユーザ入力デ
バイス、情報記憶デバイス、ネットワーク機器、センサ、識別デバイス、または
その他の情報ソースがある。

【００５１】情報をデータ・ソースからデータ・レシーバに送信するときに、データ・ソー
ス側では、許容可能なデータ・レートで情報を転送するのに必要な帯域幅を予測
する。データ・ソース側では、必要な帯域幅の推定値をデータ・レシーバに送信
する。複数のデータ・ソースがある環境では、データ・レシーバは複数のデータ
・ソースから必要な帯域幅の推定値を受信する。データ・レシーバは、複数のデ
ータ・ソースの必要な帯域幅の推定値を加算して、複数のデータ・ソースによっ
て要求される累積データ・レートを取得する。データ・レシーバは、要求された
累積データ・レートと、情報の受け渡しに使用する通信媒体の帯域幅とを比較す
る。要求された累積データ・レートが媒体の帯域幅よりも小さい場合、データ・
レシーバは複数のデータ・ソースのいずれかのデータ・レートを制限しない。デ
ータ・レシーバは、そのデータ・ソースが要求する全帯域幅を各データ・ソース
に割り当てる。

【００５２】ただし、要求された累積データ・レートが通信媒体の帯域幅を超えた場合、デ
ータ・レシーバは、各データ・ソースが要求する帯域幅を比較する。比較的狭い
帯域幅を要求するデータ・ソースについては、データ・レシーバは要求された帯
域幅のすべてを割り当てる。比較的広い帯域幅を要求するデータ・ソースについ
ては、データ・レシーバは要求された帯域幅の一部のみを割り当てる。データ・
レシーバは、要求された帯域幅をほんのわずかしか狭めない場合の便益と、要求
された帯域幅をまったく狭めない場合の便益とを比較して、低減の影響を受ける
データ・ソースの数および影響を受けるそれぞれのデータ・ソースの帯域幅の低
減範囲を決定する。

【００５３】本発明の一実施形態では、データ・ソースは、データ・レシーバに送信されて
いるコマンドを監視することにより必要と思われる帯域幅の推定値を出力する。
たとえば、Ｘウィンドウ・サーバで構成されるデータ・ソースはＸウィンドウ・
クライアント・プログラムに送信されるコマンドを監視する。このようなコマン
ドを監視することで、Ｘウィンドウ・サーバは送信するビット数およびピクセル
数およびそのような送信が行われる理想的期間を決定できる。ビット数を理想的
期間で割ることで、Ｘウィンドウ・サーバはコマンドによって生成されるデータ
について毎秒ビット数で表される理想的データ・レートを取得できる。同様に、
ピクセル数を理想的期間で割ることで、Ｘウィンドウ・サーバはコマンドによっ
て生成されるデータについて毎秒ピクセル数で表される理想的データ・レートを
取得できる。これらの理想的データ・レートは、必要な帯域幅の初期推定値とし
て使用できる。

【００５４】この監視および推定プロセスが続くときに、データ・レートに関する履歴情報
を使用して、データ・レートを記述する統計パラメータを出力できる。たとえば
、平均データ・レートまたは、平均データ・レート＋１標準偏差に等しいデータ
・レートを正確に近似して、使用することで、将来の帯域幅割り当てを決定でき
る。

【００５５】データ・ソースは、データを送信していない期間に、あるいは充分な計算リソ
ースがデータ・ソースに存在している場合には、データを送信している期間に、
データ・レート・パラメータのこのような監視、分析、および推定を実行できる
。たとえば、割り当てた帯域幅の低減によりデータ・ソースがデータを送信でき
る速度が遅くなる場合、データ・ソースは、データを送信してデータ・レート・
パラメータの監視、分析、推定を実行するのを待っている間の時間を利用できる
ことがある。本発明の帯域幅管理および衝突回避は、本発明の譲受人に譲渡され
、引用により本明細書に取り込まれたものとする、１９９８年４月２０日出願の
「ＭｅｔｈｏｄａｎｄＡｐｐａｒａｔｕｓｆｏｒＭａｎａｇｅｍｅｎｔ
ｏｆＣｏｍｍｕｎｉｃａｔｉｏｎｓｏｖｅｒＭｅｄｉａｏｆＦｉｎ
ｉｔｅＢａｎｄｗｉｄｔｈ」という名称の米国同時係属出願第０９／０６３，
４９１号に記載されている。

【００５６】《コンピュータ実行環境の実施形態（ハードウェア）》本発明の実施形態は、図１に示されているコンピュータ１００などの汎用コン
ピュータ上で実行されるコンピュータ読み取り可能コードの形、またはそのよう
なコンピュータ上で実行するＪａｖａ^TMランタイム環境内で実行可能なバイト・
コード・クラス・ファイルの形でコンピュータ・ソフトウェアとして実装できる
。キーボード１１０およびマウス１１１は、双方向システム・バス１１８に結合
されている。キーボードとマウスは、ユーザ入力をコンピュータ・システムに取
り入れ、そのユーザ入力をプロセッサ１１３に伝達するためのものである。他の
適当な入力デバイスを、マウス１１１およびキーボード１１０の他に、あるいは
それらの代わりに使用することができる。双方向システム・バス１１８に結合さ
れているＩ／Ｏ（入出力）ユニット１１９は、プリンタ、Ａ／Ｖ（オーディオ／
ビデオ）Ｉ／ＯなどのＩ／Ｏ要素を表す。

【００５７】コンピュータ１００はビデオ・メモリ１１４、メイン・メモリ１１５、および
大容量記憶装置１１２を装備し、すべてキーボード１１０、マウス１１１、およ
びプロセッサ１１３とともに双方向システム・バス１１８に結合されている。大
容量記憶装置１１２としては、磁気記憶システム、光記憶システム、または光磁
気記憶システムまたはその他の利用可能な大容量記憶装置技術などの固定媒体と
着脱可能媒体の両方がある。たとえば、バス１１８は、ビデオ・メモリ１１４ま
たはメイン・メモリ１１５をアドレッシングするための３２本のアドレス線を含
むことができる。システム・バス１１８はさらに、たとえば、プロセッサ１１３
、メイン・メモリ１１５、ビデオ・メモリ１１４、および大容量記憶装置１１２
などのコンポーネント間でデータを転送するために３２ビット・データ・バスも
含む。それとは別に、多重データ／アドレス線は、別々のアドレスおよびアドレ
ス線の代わりに使用できる。

【００５８】本発明の一実施形態では、プロセッサ１１３は、６８０Ｘ０プロセッサなどの
Ｍｏｔｏｒｏｌａが製造しているマイクロプロセッサまたは８０Ｘ８６やＰｅｎ
ｔｉｕｍプロセッサなどのＩｎｔｅｌが製造するマイクロプロセッサまたはＳｕ
ｎＭｉｃｒｏｓｙｓｔｅｍｓ^TM，Ｉｎｃ．のＳＰＡＲＣ^TMマイクロプロセッサ
である。しかし、他の適当なマイクロプロセッサまたはマイクロコンピュータも
使用できる。メイン・メモリ１１５は、ダイナミック・ランダム・アクセス・メ
モリ（ＤＲＡＭ）で構成されている。ビデオ・メモリ１１４は、デュアル・ポー
ト・ビデオ・ランダム・アクセス・メモリである。ビデオ・メモリ１１４の１つ
のポートは、ビデオ増幅器１１６に結合されている。ビデオ増幅器１１６を使用
して、陰極線管（ＣＲＴ）ラスタ・モニタ１１７を駆動する。それとは別に、ビ
デオ・メモリを使用して、フラット・パネルまたは液晶表示装置（ＬＣＤ）、あ
るいはその他の適当なデータ表示装置を駆動することもできる。ビデオ増幅装置
１１６は、よく知られている技術であり、適当な装置で実装できる。この回路は
、ビデオ・メモリ１１４に格納されているピクセル・データをモニタ１１７で使
用するのに適したラスタ信号に変換する。モニタ１１７は、グラフィック画像を
表示するのに適したタイプのモニタである。

【００５９】コンピュータ１００は、さらに、バス１１８に結合された通信インタフェース
１２０を備えることもできる。通信インタフェース１２０は、ネットワーク・リ
ンク１２１を介してローカル・ネットワーク１２２に結合する双方向データ通信
を実現する。たとえば、通信インタフェース１２０が統合サービスデジタル網（
ＩＳＤＮ）カードまたはモデムであれば、通信インタフェース１２０により、ネ
ットワーク・リンク１２１の一部をなしている対応するタイプの電話回線に接続
してデータ通信を行うことができる。通信インタフェース１２０がローカル・エ
リア・ネットワーク（ＬＡＮ）カードであれば、通信インタフェース１２０によ
り、ネットワーク・リンク１２１を介して互換性のあるＬＡＮに接続してデータ
通信を行うことができる。無線リンク、モデム、ケーブル・モデム・リンクも使
用可能である。このような実装で、通信インタフェース１２０はさまざまな種類
の情報を表すデジタル・データ・ストリームを伝送する電気信号、電磁気信号、
または光信号を送受信する。

【００６０】ネットワーク・リンク１２１は通常、１つまたは複数のネットワークを介して
他のデータ・デバイスとの間のデータ通信を行う。たとえば、ネットワーク・リ
ンク１２１では、ローカル・ネットワーク１２２を通じてローカル・サーバ・コ
ンピュータ１２３と、あるいはインターネット・サービス・プロバイダ（ＩＳＰ
）１２４によって操作されているデータ機器に接続できる。次にＩＳＰ１２４
は、現在では「インターネット」１２５と一般に呼ばれている全世界的なパケッ
ト・データ通信ネットワークを介してデータ通信サービスを提供する。ローカル
・ネットワーク１２２およびインターネット１２５は両方とも、デジタル・デー
タ・ストリームを伝送する電気信号、電磁気信号、または光信号を使用する。デ
ジタル・データをコンピュータ１００との間で伝送する、さまざまなネットワー
クを経由する信号およびネットワーク・リンク１２１上および通信インタフェー
ス１２０を経由する信号は、情報を伝送するキャリア波の一例である。

【００６１】コンピュータ１００は、ネットワーク、ネットワーク・リンク１２１、および
通信インタフェース１２０を介してメッセージを送信し、プログラム・コードな
どのデータを受信する。インターネットの例では、リモート・サーバ・コンピュ
ータ１２６はインターネット１２５、ＩＳＰ１２４、ローカル・ネットワーク
１２２、および通信インタフェース１２０を介してアプリケーション・プログラ
ムの要求されたコードを送信することができる。

【００６２】受信したコードは、受信とともにプロセッサ１１３で実行したり、大容量記憶
装置１１２あるいは他の不揮発性記憶装置に格納しておき後で実行することがで
きる。このようにして、コンピュータ１００は、キャリア波の形でアプリケーシ
ョン・コードを取得することができる。

【００６３】アプリケーション・コードは、コンピュータ・プログラム製品の形で具現化で
きる。コンピュータ・プログラム製品は、コンピュータ読み取り可能なコードを
格納する、あるいは運ぶように構成されている、あるいはコンピュータ読み取り
可能なコードを具現化できる媒体で構成されている。コンピュータ・プログラム
製品の例としては、ＣＤ−ＲＯＭディスク、ＲＯＭカード、フロッピディスク、
磁気テープ、コンピュータ・ハードディスク・ドライブ、ネットワーク上のサー
バ、およびキャリア波がある。

【００６４】上で述べたコンピュータ・システムは、例にすぎない。本発明の実施形態は、
どのような種類のコンピュータ・システムあるいはプログラミングあるいは処理
環境であっても実装できる。

【００６５】デスクトップ・ユニットの機能を適切に定義され、固定された一組の動作に減
らすことにより、さまざまな実装が可能になる。たとえば、ＨＩＤは純粋にハー
ドウェアだけで提供することや（たとえば、ボードやチップとして）、あるいは
小規模なデスクトップ・システムを制御するソフトウェアとして提供することや
（たとえば、ネットワーク・コンピュータ、パーソナル・コンピュータ、従来の
デスクトップ・システム）、あるいは従来技術のワークステーション・コンピュ
ータ・システムで動作するアプリケーションとして提供することなどができる。

【００６６】以上、仮想デスクトップ・システム・アーキテクチャを実現する方法と装置を
説明した。

【００６７】付録レンダリング・コマンド書込プロトコル・コマンド・フォーマットすべてのデータが、ネットワークを介してネットワーク・バイト順（ビッグ・
エンディアン）で送信され、ビット・フィールドは、ＭＳＢからＬＳＢの順でパ
ックされる。基本的なレンダリング・コマンド・フォーマットは次の通りである。＜ＣＯＭＭＡＮＤ：８＞＜ＳＥＱＵＥＮＣＥ：２４＞＜Ｘ：１６＞＜Ｙ
：１６＞＜ＷＩＤＴＨ：１６＞＜ＨＥＩＧＨＴ：１６＞＜Ｉｎｆｏ＞コマンド・・・・・コード・・・・・・・・・・＜Ｉｎｆｏ＞の説明Ｓｅｔ・・・・・０ｘＡ１・・・・・・・・・・ＷＩＤＴＨ×ＨＥＩＧＨＴ個の３２ビット値＜Ｘ、Ｂ、Ｇ
、Ｒ＞［ＷＩＤＴＨ×ＨＥＩＧＨＴ≦５１２画素］Ｆｉｌｌ・・・・・０ｘＡ２・・・・・・・・・・１つの３２ビット値＜Ｘ、Ｂ、Ｇ、Ｒ＞Ｇｌｙｐｈ・・・・・０ｘＡ３・・・・・・・・・・１つの３２ビット値＜Ｘ、Ｂ、Ｇ、Ｒ＞、（ＨＥＩＧＨＴ
×ｃｅｉｌｉｎｇ（ＷＩＤＴＨ／８））バイトのビットマップ［すなわち、各ラ
インは８ビットまでパディングされる］［ＷＩＤＴＨ×ＨＥＩＧＨＴ≦２０４８
画素］；コマンド全体が、次の３２ビット境界までパディングされるＣｏｐｙ・・・・・０ｘＡ４・・・・・・・・・・＜ＦＲＯＭ＿Ｘ：１６＞＜ＦＲＯＭ＿Ｙ：１６＞Ｂｉｌｅｖｅｌ・・・・・０ｘＡ５・・・・・・・・・・２つの３２ビット値ｃ０およびｃ１、＜Ｘ、Ｂ、Ｇ、Ｒ＞
、（ＨＥＩＧＨＴ×ｃｅｉｌｉｎｇ（ＷＩＤＴＨ／９））バイトのビットマップ
［すなわち、各ラインは８ビットまでパディングされる］［ＷＩＤＴＨ×ＨＥＩ
ＧＨＴ≦２０４８画素］；コマンド全体が、次の３２ビット境界までパディング
されるＳｅｔ２４・・・・・０ｘＡ６・・・・・・・・・・ＷＩＤＴＨ×ＨＥＩＧＨＴ個のパックド２４ビット値＜Ｂ
、Ｇ、Ｒ＞［ＷＩＤＴＨ×ＨＥＩＧＨＴ≦５１２画素］；次の３２ビット境界ま
でパディングされるＳｅｔ・・・・・ＹＵＶＩｍａｇｅ・・・・・・・・・・０ｘＡ７＜ＳＯＵＲＣＥ＿Ｗ：１６＞＜ＳＯＵＲＣＥ
＿Ｈ：１６＞＜ＲＦＵ：８＞＜ＬＵＭＡ＿ＥＮＣＯＤＩＮＧ：２＞＜ＣＨ
ＲＯＭＡ＿ＳＵＢ＿Ｘ：３＞＜ＣＨＲＯＭＡ＿ＳＵＢ＿Ｙ：３＞の後に、各ラ
インがバイト境界までパディングされた（ＳＯＵＲＣＥ＿Ｗ×ＳＯＵＲＣＥ＿Ｈ
）画素のＹ［ｌｕｍａ］、（ｃｅｉｌｉｎｇ（ＳＯＵＲＣＥ＿Ｗ／ｘ＿ｓｕｂｓ
ａｍｐｌｅ）ｃｅｉｌｉｎｇ（ＳＯＵＲＣＥ＿Ｈ／ｙ＿ｓｕｂｓａｍｐｌｅ）
）バイトのそれぞれ８ビット符号付きＣＣＩＲ−６０１値エンコーディングのＵ
およびＶ［ｃｈｒｏｍａ］；コマンド全体が、次の３２ビット境界までパディン
グされる；［ＳＯＵＲＣＥ＿Ｗ×ＳＯＵＲＣＥ＿Ｈ≦１０２４画素］；［ＳＯＵ
ＲＣＥ＿Ｗ≦ＷＩＤＴＨ］；［ＳＯＵＲＣＥ＿Ｈ≦ＨＥＩＧＨＴ］ＳｅｔＣｕｒｓｏｒ・・・・・０ｘＡ９・・・・・・・・・・２つの３２ビット値ｃ０およびｃ１、＜Ｘ、Ｂ、Ｇ、Ｒ＞
とその後の２組の（ＨＥＩＧＨＴ×ｃｅｉｌｉｎｇ（ＷＩＤＴＨ／９））バイト
のビットマップ［すなわち、各ラインは８ビットまでパディングされる］［ＷＩ
ＤＴＨ≦６４画素、ＨＥＩＧＨＴ≦６４画素］。最初のビットマップは画素値、
第２のビットマップは画素ごとのマスク。コマンド全体が次の３２ビット境界ま
でパディングされる。ＳｅｔＰｏｉｎｔｅｒ・・・・・０ｘＡＡ・・・・・・・・・・＜ＩＮＤＥＸ：８＞＜ＤＩＭ：２＞＜ＰＡＤ：５＞
｛＜Ｚ：１６＞｛＜Ｐ：１６＞＜Ｒ：１６＞＜Ｈ：１６＞＜ＰＡＤ
：１６＞｝｝｜＜ＰＡＤ：１６＞すべての値が符号付きの２の補数であることに留意されたい。角度値は、−
１８０から＋１８０−（１ｌｓｂ）＝＋１７９．９９４５（フル・レンジの°
）であるＷＩＤＴＨ、ＨＥＩＧＨＴは無視される。ＳｅｔＫｅｙＬｏｃｋｓ・・・・・０ｘＡＢ・・・・・・・・・・Ｘ、Ｙ、ＷＩＤＴＨ、ＨＥＩＧＨＴは無視される。＜ＩＮ
ＤＥＸ：８＞＜ＬＯＣＫＳ：８＞＜ＰＡＤ：１６＞ＤａｍａｇｅＲｅｐａｉｒ・・・・・０ｘＡＣ・・・・・・・・・・＜ＥＰＯＣＨ：３２＞＜ＰＡＤ：８＞＜ＳＥＱ：２４
＞ＰｌａｙＡｕｄｉｏ・・・・・０ｘＢ１・・・・・・・・・・Ｘ、Ｙ、ＷＩＤＴＨ、ＨＥＩＧＨＴは次の形でエンコード
される。Ｘ：４オーディオ・シーケンス番号Ｘ：１２インターリーブ・オフセットＹシーケンス全長−１ＷＩＤＴＨ：４ミキサー・モード標準ミックスに含めるチャネル数を指定する。この番号を超えるチャネル
番号は、未加工で送られ、端末が要求をカバーするのに不十分なチャネルを有す
る場合には、他のチャネルと組み合わされる。ＷＩＤＴＨ：１２サンプル内のパケット長最大２０００バイトＨＥＩＧＨＴ：４チャネル数−１ＨＥＩＧＨＴ：１２インターリーブ・サイズ−１ヘッダの後に、指定されたサンプル数×チャネル数×１６ビットが続く。コマンド全体が３２ビットまでパディングされる。シーケンス番号は、コマンドごとに増分される。シーケンス番号は、下で説明
するエポック変更ｆｌｕｓｈコマンドの場合を除いて全ビット０になってはなら
ない。長方形がラップしてはならない。すなわち、ｗ＋ｗｉｄｔｈ＜０ｘ１００
００かつｙ＋ｈｅｉｇｈｔ＜０ｘ１００００である。１つの追加情報コマンドが、次の異なるフォーマットを用いて定義される。＜ＣＯＭＭＡＮＤ：８＞＜ＳＥＱＵＥＮＣＥ：２４＞＜ＥＰＯＣＨ：３２
＞＜ＦＩＬＬ：１６×８＞コマンドコードｆｌｕｓｈ０ｘＡｆｆｌｕｓｈコマンドのシーケンス番号は、エポック変更（下の説明を参照）を
除いて、前のコマンドのシーケンス番号と同一である。すなわち、シーケンス番
号は、画素が変化するかエポックが変化する時に限って増分される。

【００６８】コマンドの説明コマンド・・・・・・・説明Ｓｅｔ・・・・・・・＜ｘ、ｙ＞＜ｗｉｄｔｈ、ｈｅｉｇｈｔ＞によって定義される
長方形に、その後に続く画素値をセットする。領域内の画素ごとに１つの画素値
がある。レイアウトは行単位である。すなわち、＜ｘ、ｙ＞ないし＜ｘ＋ｗｉｄ
ｔｈ−１、ｙ＞の画素の「ｗｉｄｔｈ」個の画素値があり、その後に＜ｘ、ｙ＋
１＞ないし＜ｘ＋ｗｉｄｔｈ−１、ｙ＋１＞などの画素が続く。＜０、０＞は、
左上隅を示す。Ｆｉｌｌ・・・・・・・＜ｘ、ｙ＞＜ｗｉｄｈｔ、ｈｅｉｇｈｔ＞によって定義される
長方形のすべての画素に単一の３２ビット値をセットする。Ｇｌｙｐｈ・・・・・・・３２ビット値が、ビットマップ内の１のビットのそれぞれに対応
する画素位置に配置され、０のビットに関連する位置は変更されない。ビットマ
ップは、各バイト内でＭＳＢからＬＳＢを使用して、行（ｙ、ｙ＋１、…）によ
ってレイアウトされる。Ｃｏｐｙ・・・・・・・＜ｆｒｏｍ＿ｘ、ｆｒｏｍ＿ｙ＞＜ｗｉｄｔｈ、ｈｅｉｇｈｔ
＞によって定義される長方形を＜ｘ、ｙ＞＜ｗｉｄｔｈ、ｈｅｉｇｈｔ＞によ
って定義される長方形にコピーする。クライアントは、オーバーラップする領域
が正しくコピーされることを保証しなければならない（たとえば、Ｓｏｌａｒｉ
ｓのｂｓｔｒｉｎｇ（３）を参照されたい）。Ｂｉｌｅｖｅｌ・・・・・・・３２ビット値ｃ０が、ビットマップ内の０のビットに対応する画
素位置、ｃ１が１のビットに対応する画素位置に配置される。ビットマップは、
各バイト内でＭＳＢからＬＳＢを使用して、行（ｙ、ｙ＋１、…）によってレイ
アウトされる。Ｓｅｔ２４・・・・・・・＜ｘ、ｙ＞＜ｗｉｄｔｈ、ｈｅｉｇｈｔ＞によって定義される
長方形に、その後に続く画素値をセットする。画素値は、３つの３２ビット値に
よって４画素が定義されるようにパックされ、したがって、＜ｂｇｒｂ、ｇｒｂ
ｇ、ｒｂｇｒ＞になる。ｗｉｄｔｈが４の倍数でない場合には、末尾が残りの値
を用いて上と同様にパックされ、最も近い３２ビット値までパディングされる。
領域内の画素ごとに１つの画素値がある。レイアウトは行単位、すなわち、（（
３×ｗｉｄｔｈ＋３）／４）個の３２ビット・ワードで＜ｘ、ｙ＞ないし＜ｘ＋
ｗｉｄｔｈ−１、ｙ＞の画素の「ｗｉｄｔｈ」個の画素値があり、その後に＜ｘ
、ｙ＋１＞ないし＜ｘ＋ｗｉｄｔｈ−１、ｙ＋１＞などの画素が続く。＜０、０
＞は、左上隅を示す。ＳｅｔＹＵＶＩｍａｇｅ・・・・・・・＜ｘ、ｙ＞＜ｗｉｄｔｈ、ｈｅｉｇｈｔ＞によって定義される
長方形に、次の形で供給される画素値をセットする。ｓｏｕｒｃｅ＿ｗ×ｓｏｕ
ｒｃｅ＿ｈ画素のＣＣＩＲ／ＩＴＵ．ＢＴ６０１Ｙ’ＣｂＣｒ（またはＹＵＶ
）フォーマットの画像を、ＲＧＢにデコードする。クロマ要素は、指定通りに水
平次元または垂直次元もしくはその両方でサブサンプリングすることができ、変
換の前にアップサンプリングされなければならない。ＣＨＲＯＭＡ＿ＳＵＢ＿ＸおよびＣＨＲＯＭＡ＿ＳＵＢ＿Ｙの値（それぞれ
ｘ＿ｓｕｂｓａｍｐｌｅおよびｙ＿ｓｕｂｓａｍｐｌｅ）は、次の形でエンコー
ドされる。０ − クロマ値なし：モノクローム画像１ − １によるサブサンプル（すなわち、サブサンプルなし）２ − ２によるサブサンプル３ − ４によるサブサンプル４〜７ − 未定義／予約済みＬＵＭＡ＿ＥＮＣＯＤＩＮＧ値は次の通りである。０ − Ｙ（ｌｕｍａ）は、８ビット符号なしデータによって指定される１ − Ｙ（ｌｕｍａ）は、４ビット量子化ＤＣＰＭ値（下を参照）から
なる２、３ − 未定義／予約済みＲＦＵは、将来の使用のために予約済みであり、０でなければならない。デコードの後に、ＲＧＢイメージを、必要に応じてｗｉｄｔｈ×ｈｅｉｇｈ
ｔ画素までスケール・アップする。結果の画像を、ディスプレイ上の位置＜ｘ、
ｙ＞に置く。注：ＣＨＲＯＭＡ＿ＳＵＢ＿ＸとＣＨＲＯＭＡ＿ＳＵＢ＿Ｙの両方が０の場
合には、画像はモノクローム（ｌｕｍａのみ）であり、ＵまたはＶのデータは存
在しない。一方に０、他方に非０をセットすることは無効である。成分の順序は、Ｙ（またはＣＣＩＲ−６０１Ｙ’）、Ｕ（ＣＣＩＲ−６０
１Ｃｂ）、およびＶ（ＣＣＩＲ−６０１Ｃｒ）である。ＳｅｔＣｕｒｓｏｒ・・・・・・・このコマンドは、ローカル・ディスプレイ・カーソル（Ｐｏｉｎ
ｔｅｒ［０］によって移動され、報告される）の外見を設定する。カーソルは、
最大６４×６４ブロックであるが、それ未満であればどのサイズでもよい。特定
の画素のマスク値が「１」の場合には、対応するカーソル画素が表示され、マス
クが「０」の場合には、カーソルはその位置で透明になる。マスクが「１」の時
に、値が「０」の時には画素値が「ｃ０」になり、値が「１」の時には画素値が
「ｃ１」になる。マスクが０の場合には、画素値も０でなければならない。０の
マスクと１の画素値は、将来の拡張のために予約済みである。ＷＩＤＴＨおよびＨＥＩＧＨＴを０にすることができ、これはカーソルを描
画しないことを示す（全ビットが０のマスクと同等である）。ポインタ・トラッ
キングは、通常通りに機能し続ける。ＸおよびＹは、カーソルの「ホット・スポット」を示し、たとえば、カーソ
ル画像のどの画素についてイベントが報告されるかを示す。これは、主にディス
プレイの縁でカーソルを停止させるのに使用される。Ｘ［０、ＷＩＤＴＨ）、
Ｙ［０、ＨＥＩＧＨＴ）である。ＳｅｔＰｏｉｎｔｅｒ・・・・・・・ポインタの位置を設定する。Ｐｏｉｎｔｅｒ［０］は、通常は設
定可能（マウスまたはタッチスクリーン）であり、２Ｄ画面カーソルである。こ
のコマンドは、ポインタの設定を共用するアプリケーション、または、相対ポイ
ンタが必要なアプリケーション（たとえばカーソルを前の位置にリセットする）
のために設けられている。したがって、下記の制限がある。ポインタの設定が全く動作しない場合がある（例えばジョイスティック）ポインタ値が、ポインタ・デバイスまたは画面に合わせて勝手にクリッピ
ングされる場合があるポインタが設定された後にユーザがポインタを動かし続けることができる
が、これは、「ＰｏｉｎｔｅｒＳｔａｔｅ」ステート（状況）メッセージを使
用して報告される。擬似相対モードのためにポインタをリセットする挙動が、異なるデバイス
に関して異なる挙動を引き起こす可能性がある。たとえば、タッチ・スクリーン
は、ユーザが「ドラッグ」していない時に限って設定可能である。ポインタは、６つまでの次元を有することができる。次元の数とコマンドの
サイズは、ＤＩＭビットを使用して設定する。すべてのポインタ値が、符号付き
の２の補数である。ＳｅｔＫｅｙＬｏｃｋｓ・・・・・・・・このコマンドは、＜ＩＮＤＥＸ＞で指定されるキーボードのロ
ック値を設定する。ロックは、一般に、ソフトウェア制御可能なキーボード上の
ライトに対応する。ロック状態を示さなければならない場合には、マスクのビッ
トをセットしなければならず、そうでない場合にはビットをクリアしなければな
らない。一部のキーボードは、ロックをローカルに（たとえば機械的に）実施す
る場合があるので、ロックの設定が、影響を及ぼさない場合がある。キーボード
のキーは、必ず、キーボードによって報告される状態から解釈しなければならな
い。その一方で、ホストは、インターフェースからそう指示された場合に、ロッ
ク・キーコードを受け取った際にＳｅｔＫｅｙＬｏｃｋｓコマンドを発行し
なければならない。というのは、通常のキーボードと端末の両方が、ロックをロ
ーカルに処理しようとしないからである。これは、端末が、キーボードも所望の
ユーザ・インターフェース・セマンティクスも理解しないからである。キー・ロック・ビットマップは、ブート・キーボードに関する次のＵＳＢク
ラス定義から与えられる。０ｘ０１ＮｕｍＬｏｃｋ０ｘ０２ＣａｐｓＬｏｃｋ０ｘ０４ＳｃｒｏｌｌＬｏｃｋ０ｘ０８Ｃｏｍｐｏｓｅ０ｘ１０Ｋａｎａ他のすべてのビットは予約済みであり、読み取りの際には無視し、設定の際
には０にする。ＤａｍａｇｅＲｅｐａｉｒ・・・・・・・これは、エポックＥＰＯＣＫ内のシーケンス番号ＳＥＱおよびそ
れ以前のすべてのダメージ・メッセージが、処理され、リペア・データが送信さ
れたことをクライアントに知らせる（Ｄａｍａｇｅバックチャネル・コマンドを
参照されたい）。ＰＡＤは、０でなければならない。Ｘ、Ｙ、ＷＩＤＴＨ、およ
びＨＥＩＧＨＴは、０でなければならない。ＰｌａｙＡｕｄｉｏ・・・・・・・これは、４８ｋＨｚオーディオ・サンプルを再生し、グラフィッ
クス・コマンド・ストリーム内に埋め込むことができる。未定義の数のストリームが、先着順ベースで端末に受信される。ストリーム
は、必要に応じて割り振られ、バッファ・スターベイション（ｂｕｆｆｅｒｓ
ｔａｒｖａｔｉｏｎ）が発生した時（再生の時間になった時に再生するデータが
ない−部分的に受信されたバッファは、エラーを隠され、再生される）に分割さ
れる。端末は、タイムベース・ドリフトを補正する。データは、ネットワーク・エラー隠蔽を助けるためにインターリーブされた
形で送信される。サンプル・シーケンスは、インターリーブ・サイズに分割され
、多くとも１＋（シーケンス・サイズ）／（インターリーブ・サイズ）個のサン
プルが、パッカーによって放出される。サンプルは、次の形で選択される。 sample sequence[sample_size]; int seq_number = 0; while (1) { get_samples(sequence, sample_size); for (i = 0; i < interleave_size; i++) { interleave_offset = randome_select(0..interleave_size); packet=new_packet(seq_number, sample_size, num_chan, num_chan, interleave_size, interleave_offset); for (j = interleave_offset; j < sample_size; j += interleave_size) emit(packet, sequence[j]); send_packet(packet); } seq_number = (seq_number+1)%16; } パケットが送信される順序をランダムにすることができる（おそらくはそう
しなければならない）ことに留意されたい。たとえば、３のインターリーブと８のシーケンス・サイズの場合、次の３つ
のパケットを送信することができる。（サンプル）（０１２３４５６７）パケット１、オフセット１：１４７パケット２、オフセット０：０３６パケット３、オフセット２：２５シーケンスは、エラー隠蔽を行い、サンプル・シーケンスを放出する時を端
末が知るように番号を付けられる。サンプルは、４８ｋＨｚ、１６ビット・リニアであり、１６個までのチャネ
ルを含めることができる。たとえば、５チャンネル・サンプルは、連続する１０
バイトを占める。端末によってサポートされるオーディオ・チャネルの数に関する定義はなく
、それを見つける方法もないが、１６個までのチャネルを同時に送信することが
できる。端末がサポートする数と異なる数のチャネルが送信される可能性がある
ので、標準ミックスの概念を、最初の８チャネルに導入する。これは、あるイン
デックスのチャネルが互いにミックスされないことを保証する「ＭＩＸ」フィー
ルドの設定によってディスエーブルすることができる。最後の８チャネルは、最
初の８チャネルと同一の方式でミックスされ、その結果、サウンドを聞くことが
できるようなる。十分なチャネルがある場合には、結果は端末のセットアップに
依存する。標準で割り当てられるチャネルは次の通りである。チャネル→ チャネル番号０１２３４５６７１モノラル２ｌｒ３ｌｒｓｗ４ｌｒｒｌｒｒ５ｌｒｒｌｒｒｓｗ６ｌｒｒｌｒｒｓｗｃｆ７ｌｒｒｌｒｒｓｗｃｆｔｏｐ８ｌｒｒｌｒｒｓｗｃｆｃｌｃｒ（ｌ＝左、ｒ＝右、ｒ［ｌｒ］＝後（左、右）、ｓｗ＝サブウーハー、ｃ
ｆ＝センター・フィル、ｃ［ｌｒ］＝中央（左、右）、ｔｏｐ＝中央−中央たとえば、２つのスピーカがあり、１チャネルが標準ミックスをイネーブル
した状態で送信される場合には、その１チャネルが、左右両方のスピーカに送ら
れる。逆に、同一の端末に６チャネルが送信された場合には、チャネル０、２、
４、および５がミックスされ、左スピーカに送られ、チャネル１、３、４、およ
び６がミックスされ、右スピーカに送られる。端末のスピーカは、同一の形でセット・アップされる。完全なミキシング・マトリックスは、完全な仕様書で入手可能である。Ｆｌｕｓｈ・・・・・・・このコマンドに続く時間期間のディスプレイ・ストリームにコマ
ンドがない可能性がある。したがって、これは、クライアントが未完了のすべて
のレンダリングを画面にフラッシュするのによい点である。エポック・フィール
ドは、シーケンス番号用に３２ビットの追加の上位ビットを提供する。ＦＩＬＬ
は、すべて０ｘＦＦの１６バイト・セットからなる。このコマンドは、ドロップ
アウトの後でデータ・ストリームを再同期化する機会を提供する。ｆｌｕｓｈコマンドのシーケンス番号は、通常は、最後の非ｆｌｕｓｈコマ
ンドと同一である。しかし、エポックを使い果たした（すなわち、最後のコマン
ドのシーケンス番号が０ｘＦＦＦＦＦＦである）時には、０のシーケンス番号と
新しいエポック番号（１つ増分される）を有するｆｌｕｓｈコマンドが送信され
る。＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

【００６９】バックチャネル・コマンドワイヤ・プロトコル・ステータス・メッセージ・フォーマット基本的なステート（状況）コマンド・フォーマットは次の通りである。＜ＣＯＭＭＡＮＤ：８＞＜ＴＩＭＥ：２４＞＜Ｉｎｆｏ＞コマンド・・・・・コード・・・・・・・・・・＜Ｉｎｆｏ＞の説明ＫｅｙｂｏａｒｄＳｔａｔｅ・・・・・０ｘｃ１・・・・・・・・・・＜ＩＮＤＥＸ：８＞＜ＣＯＵＮＴＲＹ＿ＣＯＤＥ：８＞
＜ＬＯＣＫＳ：８＞＜ＭＯＤＩＦＩＥＲＳ：８＞＜ＫＥＹＣＯＤＥ：８＞
［８］ＰｏｉｎｔｅｒＳｔａｔｅ・・・・・０ｘｃ２・・・・・・・・・・＜ＩＮＤＥＸ：８＞＜ＤＩＭ：２＞＜ＢＵＴＴＯＮＳ
：６＞＜Ｘ：１６＞｛＜Ｙ：１６＞｛＜Ｚ：１６＞｛＜Ｐ：１６＞＜
Ｒ：１６＞＜Ｈ：１６＞｝｝｝すべての値が、符号付きの２の補数であることに留意されたい。角度値は、
−１８０から＋１８０−（１ｌｓｂ）＝＋１７９．９９４５（フル・レンジの
°）である。ＤＩＭ次元０Ｘ１Ｘ、Ｙ２Ｘ、Ｙ、Ｚ３Ｘ、Ｙ、Ｚ、Ｐ、Ｒ、Ｈ（ヨー）ＡｃｔｉｖｅＲｅｇｉｏｎ・・・・・０ｘｃ３・・・・・・・・・・＜Ｘ：１６＞＜Ｙ：１６＞＜ＷＩＤＴＨ：１６＞＜
ＨＥＩＧＨＴ：１６＞Ｄａｍａｇｅ・・・・・０ｘｃ４・・・・・・・・・・＜ＥＰＯＣＨ：３２＞＜ＰＡＤ０：８＞＜ＳＥＱ＿Ｌ
：２４＞＜ＰＡＤ１：８＞＜ＳＥＱ＿Ｈ：２４＞注：ＴＩＭＥはミリ秒単位である；２の２４乗（約１６秒）後にラップする
。

【００７０】ステータス・メッセージの説明コマンド・・・・・・・・説明ＫｅｙｂｏａｒｄＳｔａｔｅ・・・・・・・・＜ＩＮＤＥＸ＞で指定されるキーボードの状態を報告する。カ
ントリ・コードは、ＵＳＢＤｅｖｉｃｅＣｌａｓｓＤｅｆｉｎｉｔｉｏｎ
ｆｏｒＨＩＤｓ，ｓｅｃｔｉｏｎ６．２からのものである。ロックは、次
のブート・キーボードのＵＳＢクラス定義からのものである。０ｘ０１ＮｕｍＬｏｃｋ０ｘ０２ＣａｐｓＬｏｃｋ０ｘ０４ＳｃｒｏｌｌＬｏｃｋ０ｘ０８Ｃｏｍｐｏｓｅ０ｘ１０Ｋａｎａ「ＳｅｔＫｅｙＬｏｃｋｓ」コマンドを使用して、これらのロックをリ
セットすることができ、ホストでロック・キーが検出された場合には「Ｓｅｔ
ＫｅｙＬｏｃｋｓ」コマンドを使用しなければならない。というのは、キーボ
ードが、一般にロックステート（状況）をローカルに処理せず、端末もこれを処
理しないからである。上で指定されたもの以外のビットは、予約済みであり、無
視しなければならない。セットの際には、これらのビットには０をセットしなけ
ればならない。モディファイア・ビットもブート・キーボード用のＵＳＢクラス定義からの
ものである。０ｘ０１左Ｃｏｎｔｒｏｌ０ｘ０２左Ｓｈｉｆｔ０ｘ０４左Ａｌｔ０ｘ０８左ＧＵＩ０ｘ１０右Ｃｏｎｔｒｏｌ０ｘ２０右Ｓｈｉｆｔ０ｘ４０右Ａｌｔ０ｘ８０右ＧＵＩ必ず６つのスキャンコードのスペースがある。押し下げられたすべてのキー
（モディファイヤでないもの）が、６キーまで報告される。これは、単純なロー
ルオーバー機能とコーディング機能を提供する。スキャン・コードは、ブート・
キーボード用のＵＳＢクラス定義からのものである。特に注目すべきものが、スロット内にイベントがないことを示すコード０ｘ
００と、８つを超えるキーが押されていることを示す全スロットの０ｘ０１であ
る。モディファイヤは、この状態でも報告される。９つ未満のキーが押されたな
らば、通常のレポートが再開される。報告の順序は任意であり、イベントの順序
を反映しない。ＰｏｉｎｔｅｒＳｔａｔｅ・・・・・・・・＜ＩＮＤＥＸ＞で指定されるポインタの状態を報告する。ＤＩ
Ｍは、報告される次元の数すなわち、１、２、３、または６を示す。ボタンは、
ブート・キーボード用のＵＳＢクラス定義からのものであり、ビット０が「プラ
イマリ」ボタン（左ボタン）であり、左から右へ数が増える。報告される値は、
すべて絶対値であり、符号付きの２の補数である。ＡｃｔｉｖｅＲｅｇｉｏｎ・・・・・・・・ｎｅｗｔ上で保存される論理フレームバッファの区域を示す。
具体的には、これは、Ｃｏｐｙレンダリング・コマンドの「ｆｒｏｍ」領域を成
功裡に指定することができる区域である。この領域は、たとえばハンドヘルド・デバイスのパン−アンド−スキャン・
スタイルのインターフェースに起因して、所与のクライアント上で時間的に変化
する可能性がある。また、異なるクライアント・デバイスが、異なるアクティブ
領域を報告する可能性がある。Ｄａｍａｇｅ・・・・・・・・エポックＥＰＯＣＨのシーケンス番号ＳＥＱ＿Ｌからシーケン
ス番号ＳＥＱ＿Ｅまで（ＳＥＱ＿Ｅを含む）のダウンストリーム（レンダリング
）コマンドが、サーバから、クライアントによって受信されなかったことを示す
。ＰＡＤ０とＰＡＤ１は０でなければならない。クライアントは、影響を受けたシーケンス番号に関するＤａｍａｇｅＲｅ
ｐａｉｒメッセージを受信するまで、報告を続ける。ＳＥＱ＿Ｌが０の場合には、現在の画面イメージ全体を送信しなければなら
ない。所与のシーケンス番号についてダメージ・メッセージが送信された後には、
それより若いシーケンス番号に関する新しい後続のダメージは送信されない。し
かし、後のステート（状況）パケットのスペースを節約するために、複数の範囲
を１つにまとめることが許容される。＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

【００７１】ＤＰＣＭＹＵＶの説明１のＬＵＭＡ＿ＥＮＣＯＤＩＮＧを用いて、さらにＹＵＶデータを圧縮すること
ができる。Ｌｕｍａデータは、次の形でエンコードされる。 for each line last_value = 0x80 for each luma-value l in line diff = l - last_value q_value = quant(diff) last_value = clamp(last_value + dquant(q_value)) emit q_value end end Ｌｕｍａデータは、次の形でデコードされる。 for each line last_value = 0x80 for each quantization-value q_value in line last_value = clamp(last_value + dquant(q_value)) emit last_value end end Ｃｌａｍｐは、クランピング・テーブルであり、ｃｌａｍｐ［ｉ］は次の通りで
ある。０ｉ＜０の場合２５５ｉ＞２５５の場合ｉそれ以外の場合。使用される量子化は次の通りである。差コードｒｑｕａｎｔ −２５５〜−９１０ −１００ −９０〜−７１１ −８０ −７０〜−５１２ −６０ −５０〜−３１３ −４０ −３０〜−１６４ −２０ −１５〜−８５ −１０ −７〜−３６ −４ −２〜０７ −１１〜２８１３〜７９４８〜１５１０１０１６〜３０１１２０３１〜５０１２４０５１〜７０１３６０７１〜９０１４８０９１〜２５５１５１００

【図面の簡単な説明】

【図１】本発明で使用できるコンピュータ・システム例のブロック図であ
る。

【図２】本発明のセッション管理および許可の例である。

【図３】本発明の仮想デスクトップ環境の図である。

【図４】本発明のＨＩＤの一実施形態のブロック図である。

【図５】本発明のシングル・チップＨＩＤの実施形態の図である。

【手続補正書】

【提出日】平成１３年５月３１日（２００１．５．３１）

【手続補正２】

【補正対象書類名】明細書

【補正対象項目名】特許請求の範囲

【補正方法】変更

【補正内容】

【特許請求の範囲】

───────────────────────────────────────────────────── フロントページの続き (51)Int.Cl.⁷ 識別記号ＦＩテーマコート゛(参考）Ｈ０４Ｌ 29/08 Ｈ０４Ｌ 13/00 ３０７Ｚ (81)指定国ＥＰ(ＡＴ，ＢＥ，ＣＨ，ＣＹ，ＤＥ，ＤＫ，ＥＳ，ＦＩ，ＦＲ，ＧＢ，ＧＲ，ＩＥ，ＩＴ，ＬＵ，ＭＣ，ＮＬ，ＰＴ，ＳＥ)，ＯＡ(ＢＦ，ＢＪ，ＣＦ，ＣＧ，ＣＩ，ＣＭ，ＧＡ，ＧＮ，ＧＷ，ＭＬ，ＭＲ，ＮＥ，ＳＮ，ＴＤ，ＴＧ)，ＡＰ(ＧＨ，ＧＭ，ＫＥ，ＬＳ，ＭＷ，ＳＤ，ＳＬ，ＳＺ，ＵＧ，ＺＷ)，ＥＡ(ＡＭ，ＡＺ，ＢＹ，ＫＧ，ＫＺ，ＭＤ，ＲＵ，ＴＪ，ＴＭ)，ＡＬ，ＡＭ，ＡＴ，ＡＵ，ＡＺ，ＢＡ，ＢＢ，ＢＧ，ＢＲ，ＢＹ，ＣＡ，ＣＨ，ＣＮ，ＣＵ，ＣＺ，ＤＥ，ＤＫ，ＥＥ，ＥＳ，ＦＩ，ＧＢ，ＧＤ，ＧＥ，ＧＨ，ＧＭ，ＨＲ，ＨＵ，ＩＤ，ＩＬ，ＩＮ，ＩＳ，ＪＰ，ＫＥ，ＫＧ，ＫＰ，ＫＲ，ＫＺ，ＬＣ，ＬＫ，ＬＲ，ＬＳ，ＬＴ，ＬＵ，ＬＶ，ＭＤ，ＭＧ，ＭＫ，ＭＮ，ＭＷ，ＭＸ，ＮＯ，ＮＺ，ＰＬ，ＰＴ，ＲＯ，ＲＵ，ＳＤ，ＳＥ，ＳＧ，ＳＩ，ＳＫ，ＳＬ，ＴＪ，ＴＭ，ＴＲ，ＴＴ，ＵＡ，ＵＧ，ＵＺ，ＶＮ，ＹＵ，ＺＷ (71)出願人 901 ＳＡＮＡＮＴＯＮＩＯＲＯＡＤＰＡＬＯＡＬＴＯ，ＣＡ 94303，Ｕ．Ｓ．Ａ． (72)発明者ハンコ，ジェームズ・ジイアメリカ合衆国・94061・カリフォルニア州・レッドウッドシティ・オハイオアベニュ・2746 (72)発明者ルバーグ，アラン・ティアメリカ合衆国・94404・カリフォルニア州・フォスターシティ・エメラルドベイレーン・605 (72)発明者ウォール，ジェラルド・エイアメリカ合衆国・95150・カリフォルニア州・サンホゼ・クロッカスドライブ・ 4515 (72)発明者ブッチャー，ローレンス・エルアメリカ合衆国・94043・カリフォルニア州・マウンテンビュー・コレンズコート８番・4315 (72)発明者ウィルヘルム，ニール・シイアメリカ合衆国・94025・カリフォルニア州・メンロパーク・プロスペクトストリート・2110 Ｆターム(参考） 5B045 AA07 BB03 BB42 GG02 5B085 AE02 AE12 BA06 BC02 BG07 5K034 AA14 AA18 CC02 CC05 FF01 【要約の続き】る。カードを取り外すと、セッションは無効になる。カードを再度同じ端末または他の端末に挿入すると、セッションが再度有効になる。

Claims

【特許請求の範囲】

【請求項１】計算システム・アーキテクチャであって、相互接続構造を通じてデータを提供するためのデータ・ソースと、前記データを受信して処理するための、前記相互接続構造に結合されているス
テートレス人間インタフェース・デバイスを備えるアーキテクチャ。
【請求項２】前記ステートレス人間インタフェース・デバイスにユーザが
識別子を使用してアクセスすることを特徴とする請求項１に記載のアーキテクチ
ャ。
【請求項３】前記識別子がスマート・カードを含むことを特徴とする請求
項２に記載のアーキテクチャ。
【請求項４】前記識別子が生物測定識別子を含むことを特徴とする請求項
２に記載のアーキテクチャ。
【請求項５】前記ユーザが前記ステートレス人間インタフェース・デバイ
スにアクセスしたときに前記ユーザの計算セッションにアクセスすることを特徴
とする請求項２に記載のアーキテクチャ。
【請求項６】前記相互接続構造を介して前記データ・ソースに結合されて
いる複数のステートレス人間インタフェース・デバイスをさらに含む請求項５に
記載のアーキテクチャ。
【請求項７】ユーザが前記識別子を使用して前記複数のステートレス人間
インタフェース・デバイスで前記セッションにアクセスできることを特徴とする
請求項６に記載のアーキテクチャ。
【請求項８】前記データ・ソースが複数のデータ・サービスを構成するこ
とを特徴とする請求項１に記載のアーキテクチャ。
【請求項９】前記相互接続構造を介して前記ステートレス人間インタフェ
ース・デバイスに送信するため前記複数のデータ・ソースの出力を共通プロトコ
ルに変換することを特徴とする請求項８に記載のアーキテクチャ。
【請求項１０】計算システムであって、複数のユーザ・セッションに対して計算およびデータ生成を提供する中央処理
ソースと、相互接続構造を介して前記中央処理ソースに結合されている複数のステートレ
ス人間インタフェース・デバイスであって、前記ステートレス人間インタフェー
ス・デバイスのそれぞれが前記中央処理ソースからデータを受信し、出力をユー
ザに表示して前記複数のユーザ・セッションの１つを開始し、さらに前記ステー
トレス人間インタフェース・デバイスのそれぞれが前記相互接続構造を介して前
記中央処理ソースにユーザ入力を送るステートレス人間インタフェース・デバイ
スと、前記ユーザと関連するセッションが前記相互接続構造を介して前記ステートレ
ス人間インタフェース・デバイスの前記１つを経由するように前記ユーザを識別
する前記ステートレス人間インタフェース・デバイスの１つでユーザが使用する
識別子を備える計算システム。
【請求項１１】ユーザ・セッションの状態が前記中央計算リソースで保持
されることを特徴とする請求項１０に記載のシステム。
【請求項１２】前記ユーザ入力がキーボード・ストロークを含むことを特
徴とする請求項１１に記載のシステム。
【請求項１３】前記ユーザ入力がカーソル移動を含むことを特徴とする請
求項１１に記載のシステム。
【請求項１４】前記ユーザ入力がオーディオを含むことを特徴とする請求
項１１に記載のシステム。
【請求項１５】前記ユーザ入力がビデオを含むことを特徴とする請求項１
１に記載のシステム。
【請求項１６】前記ユーザが前記物理的識別子を使用して前記複数のステ
ートレス人間インタフェース・デバイスで前記セッションにアクセスできること
を特徴とする請求項１１に記載のシステム。
【請求項１７】計算システムであって、複数の計算サービス・プロバイダと、前記計算サービス・プロバイダに結合されている相互接続構造と、前記相互接続構造に結合されている複数のステートレス・インタフェース・デ
バイスを備えるシステム。
【請求項１８】前記複数の計算サービス・プロバイダが前記相互接続構造
を介してデータを前記ステートレス・インタフェース・デバイスに提供し、前記
ステートレス・インタフェース・デバイスが前記データを表示することを特徴と
する請求項１７に記載の計算システム。
【請求項１９】前記計算サービス・プロバイダがユーザと関連するユーザ
・セッションと関連するデータを提供することを特徴とする請求項１８に記載の
計算システム。
【請求項２０】前記ユーザが前記複数のステートレス・インタフェース・
デバイスで前記ユーザ・セッションにアクセスすることを特徴とする請求項１９
に記載の計算システム。
【請求項２１】前記ユーザが識別子を前記ステートレス・インタフェース
・デバイスの１つに提示することで前記ステートレス・インタフェース・デバイ
スの１つで前記ユーザ・セッションにアクセスすることを特徴とする請求項２０
に記載の計算システム。
【請求項２２】前記複数の計算サービス・プロバイダが第１のメンバと第
２のメンバを含み、前記第１のメンバが第１のタイプのデータの計算を専門とし
、前記第２のメンバが第２のタイプのデータの計算を専門とすることを特徴とす
る請求項２１に記載の計算システム。
【請求項２３】前記第１のメンバが前記第１のタイプのデータを前記ステ
ートレス・インタフェース・デバイスに提供し、前記第２のメンバが前記第２の
タイプのデータを前記ステートレス・インタフェース・デバイスに提供すること
を特徴とする請求項２２に記載の計算システム。
【請求項２４】前記識別子がパスワードを含むことを特徴とする請求項２
３に記載の計算システム。
【請求項２５】前記識別子がスマート・カードを含むことを特徴とする請
求項２３に記載の計算システム。
【請求項２６】前記識別子が生物測定識別子を含むことを特徴とする請求
項２３に記載の計算システム。
【請求項２７】前記ユーザが前記インタフェース・デバイスの１つで前記
ユーザ・セッションを中断し、前記インタフェース・デバイスの他の１つで前記
ユーザ・セッションを再開することを特徴とする請求項２３に記載の計算システ
ム。
【請求項２８】計算の方法であって、複数の計算サービス・プロバイダを提供するステップと、前記計算サービス・プロバイダを相互接続構造に結合するステップと、ステートレス・インタフェース・デバイスを前記相互接続構造に結合するステ
ップと、前記相互接続構造を介して前記計算サービス・プロバイダからデータを前記ス
テートレス・インタフェース・デバイスに提供するステップを含む方法。
【請求項２９】前記計算サービス・プロバイダとのユーザ・セッションを
生成するステップをさらに含む請求項２８に記載の方法。
【請求項３０】前記ステートレス・インタフェース・デバイスで識別子を
提示することにより前記ユーザ・セッションにアクセスするステップをさらに含
む請求項２９に記載の方法。
【請求項３１】前記識別子が提示されたときに前記セッションを前記ステ
ートレス・インタフェース・デバイスに送信することを特徴とする請求項３０に
記載の方法。
【請求項３２】前記識別子がスマート・カードを含むことを特徴とする請
求項３１に記載の方法。
【請求項３３】前記識別子がパスワードを含むことを特徴とする請求項３
１に記載の方法。
【請求項３４】前記識別子が生物測定識別子を含むことを特徴とする請求
項３１に記載の方法。
【請求項３５】前記相互接続構造に結合されている複数のステートレス・
インタフェース・デバイスをさらに含む請求項３１に記載の方法。
【請求項３６】前記インタフェース・デバイスの１つで前記ユーザ・セッ
ションを中断し、前記インタフェース・デバイスの他の１つで前記ユーザ・セッ
ションを再開するステップをさらに含む請求項３１に記載の方法。
【請求項３７】前記計算サービス・プロバイダが外部ソースから前記デー
タを受信することを特徴とする請求項２８に記載の方法。
【請求項３８】前記外部ソースがインターネットであることを特徴とする
請求項３７に記載の方法。
【請求項３９】前記外部ソースが放送エンティティであることを特徴とす
る請求項３７に記載の方法。
【請求項４０】前記放送エンティティがテレビ信号を送信することを特徴
とする請求項３９に記載の方法。
【請求項４１】前記放送エンティティがラジオ信号を送信することを特徴
とする請求項３９に記載の方法。
【請求項４２】データを前記ステートレス・インタフェース・デバイスに
提供する前記ステップがさらに、前記複数の計算サービス・プロバイダが、前記相互接続構造を介して前記ステ
ートレス・インタフェース・デバイスに送信するため異なる出力を共通プロトコ
ルに変換するステップを含むことを特徴とする請求項２８に記載の方法。
【請求項４３】計算の方法であって、複数の計算サービス・プロバイダを提供するステップと、前記計算サービス・プロバイダを相互接続構造に結合するステップと、ステートレス・インタフェース・デバイスを前記相互接続構造に結合するステ
ップと、前記ステートレス・インタフェース・デバイスでユーザがセッションを開始す
るステップと、入力を前記ステートレス・インタフェース・デバイスに提供するステップと、前記相互接続構造を介して前記複数の計算サービス・プロバイダの１つまたは
複数に前記入力を送信するステップと、修正されたデータを出力するために前記複数の計算サービス・プロバイダの前
記１つまたは複数で前記データを操作するステップであって、操作の前記ステッ
プに状態を変更するステップと計算を実行するステップが含まれるステップと、前記相互接続構造を介して前記計算サービス・プロバイダから前記修正済みデ
ータを前記ステートレス・インタフェース・デバイスに提供するステップと、前記データを前記ステートレス・インタフェース・デバイス上に表示するステ
ップを含む方法。
【請求項４４】計算の方法であって、相互接続構造を実現するステップと、前記相互接続構造に結合されている複数の計算サービス・プロバイダを提供す
るステップと、前記相互接続構造に結合されているプロキシ・サービスを提供するステップで
あって、前記相互接続構造を介して前記複数の計算サービス・プロバイダからデ
ータを前記プロキシ・サービスに送信するステップと、前記相互接続構造に結合されているステートレス・インタフェース・デバイス
を提供するステップであって、前記相互接続構造を介して前記プロキシ・サービ
スからデータを前記ステートレス・インタフェース・デバイスに送信するステッ
プを含む方法。
【請求項４５】前記複数の計算サービス・プロバイダが１つまたは複数の
データベースにアクセスすることを特徴とする請求項４４に記載の方法。
【請求項４６】前記プロキシ・サービスが前記１つまたは複数のデータベ
ースに対するクエリを生成するように構成されていることを特徴とする請求項４
５に記載の方法。
【請求項４７】計算の方法であって、複数のステートマシンと、１つのステートレス・マシンと、前記複数のステート・マシンを前記ステートレス・マシンに結合する相互接続
構造と、入力を前記ステートレス・マシンに提供するステップと、前記入力を前記複数のステート・マシンの１つまたは複数に送信するステップ
と、出力を生成するため前記複数のステート・マシンの前記１つまたは複数により
前記入力に対し操作するステップと、前記出力を前記ステートレス・マシンに送信するステップと、前記データを前記ステートレス・マシン上に表示するステップを含む方法。
【請求項４８】前記入力と前記出力を送信する前に、前記入力と前記出力
を前記ステートレス・マシンで読み取り可能なプロトコルに変換することを特徴
とする請求項４７に記載の方法。