JP5264895B2

JP5264895B2 - ビットマップ形式の表示リモーティング

Info

Publication number: JP5264895B2
Application number: JP2010510421A
Authority: JP
Inventors: アブドナディム; アール．シュミーダーヴィルヘルム
Original assignee: Microsoft Corp
Current assignee: Microsoft Corp
Priority date: 2007-05-31
Filing date: 2008-05-21
Publication date: 2013-08-14
Anticipated expiration: 2028-05-21
Also published as: US8209372B2; EP2171606A1; WO2008150709A1; EP2171606A4; CN101681339A; EP2171606B1; JP2010529537A; US8140610B2; US20080301566A1; US20110227935A1; CN101681339B

Description

ＲＤＰ（ＲｅｍｏｔｅＤｅｓｋｔｏｐＰｒｏｔｏｃｏｌ：リモートデスクトッププロトコル）は、ＴＳ（ｔｅｒｍｉｎａｌｓｅｒｖｅｒ：端末サーバー）ベースのアプリケーションへのネットワーク接続を介して、リモート表示および入力機能を提供する。例えば、ＲＤＰは、サーバー上の自身のビデオドライバーを使用して、レンダリング情報をクライアントに対するネットワーク経由の通信のためのネットワークパケット内に構築することにより、アプリケーションの表示出力をクライアントデバイスにレンダリングする。このようなネットワークパケットを受信することに応答して、クライアントはレンダリング情報を、対応するＧＤＩ（ＧｒａｐｈｉｃａｌＤｅｖｉｃｅｉｎｔｅｒｆａｃｅ）ＡＰＩ（ＡｐｐｌｉｃａｔｉｏｎＰｒｏｇｒａｍｍｉｎｇＩｎｔｅｒｆａｃｅ）コールに復号化し、解釈する。（ＧＤＩは、典型的には、オペレーティングシステムの個々の部分と関連している。）このような復号化および解釈は、通常、クライアントが拡張インターフェイスであるＲＤＰを復号化するように構成されるだけでなく、受信したレンダリング情報を対応するＧＤＩコールにマッピングするように構成されることが必要である。このような動作には、典型的には、クライアントが複数の異なるデータのコンテキスト依存キャッシュを作成し、保持して、ＧＤＩベースのレンダリング動作においてフォント、ブラシ、グリフ、フラグメントなどのグラフィックオブジェクトを使用することが必要である。

これらのタスクは複雑であるため、ＲＤＰベースのクライアントの作成は、非常に時間がかかり、大きな労力を要する可能性がある。さらに、ＲＤＰベースのクライアントは、典型的には、そのような動作を実装するのにかなりの処理能力を持たなければならない。このような処理リソースは、通常、スモール・フォーム・ファクター・デバイスでは見られない。結果として、スモール・フォーム・ファクターは、典型的には、ＲＤＰベースのクライアントを実装するのに使用されない。

この概要は、以下の「発明を実施するための形態」でさらに説明する概念の選択を簡略化した形で紹介するものである。この概要は、請求される主題の重要な特徴または不可欠な特徴を特定するものではなく、請求される主題の範囲の決定を助けるものでもない。

前段落では、クライアント・コンピューティング・デバイス（「クライアント」）に結合されたサーバー・コンピューティング・デバイス（「サーバー」）によるビットマップ転送形式表示リモーティング（ｒｅｍｏｔｉｎｇ）を説明している。一態様では、サーバー側で実行するアプリケーションは、ＧＵＩの一部をレンダリングするための動作を実装する。サーバーは、対応するレンダリング形式のコマンド（単数または複数）（例えば、ＧＤＩコマンド）を簡単なビットマップ転送コマンドに変換する。サーバーは、ビットマップ転送コマンドをクライアントに送信する。例えば、１つの実装では、サーバーはＧＤＩコマンドを１つまたは複数のビットマップ操作動作（ｍａｎｉｐｕｌａｔｉｏｎｏｐｅｒａｔｉｏｎ）コマンド（ラスター動作）に変換する。また、１つの実装では、サーバーはＧＤＩコマンドに従ってレンダリング動作を実装して動作結果（単数または複数）を得る。

サーバーは、動作結果（単数または複数）をビットマップ転送コマンド（単数または複数）のビットマップ（単数または複数）としてクライアントに送信する。クライアントは、サーバーからの受信したビットマップ転送コマンドに応答して、サーバーに指示されるように、オフスクリーンの表示面からオンスクリーンの表示面に、それぞれビットマップ（単数または複数）を記憶し、描画して、ユーザーにＧＵＩ部を提示する。このようにして、サーバーは、任意の従来のＲＤＰクライアント側のリモーティングロジック（例えば、キャッシュ管理、ビットマップのセマンティクスを超えたグラフィックオブジェクトのセマンティクスの判断および処理など）を使用せずに、またはそのようなロジックに依存せずに、ビットマップ転送コマンドのみを使用して、クライアントに指示してアプリケーションのＧＵＩをリモーティングさせる。このような管理、セマンティクスの判断および処理は、それぞれサーバー側でサーバーにより実装され、保持される。

図面および関連した説明で、コンポーネントの符番の最も左の桁はそのコンポーネントが最初に表示された特定の図面を示す。
一実施形態のビットマップ転送形式表示リモーティングの例示的なシステムを示す図である。一実施形態のビットマップ転送形式表示リモーティング用のリモートクライアント側の例示的なサーバーが作成した、サーバーが目的とするオフスクリーン表示面を示す図である。一実施形態のビットマップ転送形式表示リモーティングの例示的なプロシージャを示す図である。一実施形態のビットマップ転送形式表示リモーティングの例示的なプロシージャを示す図である。一実施形態のビットマップ転送形式表示リモーティングの別の例示的なプロシージャを示す図である。一実施形態のビットマップ転送形式表示リモーティングの図５の例示的なプロシージャのさらに別の態様を示す図である。一実施形態のビットマップ転送形式表示リモーティングの図５、６の例示的なプロシージャのさらに別の態様を示す図である。

概略
ビットマップ転送形式表示リモーティングのシステムおよび方法を説明する。このシステムおよび方法は、ＳＢＴＤＲＰ（ｓｉｍｐｌｅｂｉｔｍａｐｔｒａｎｓｆｅｒ−ｂａｓｅｄｄｉｓｐｌａｙｒｅｍｏｔｉｎｇｐｒｏｔｏｃｏｌ：簡易ビットマップ転送形式表示リモーティングプロトコル）を使用して、従来型のＲＤＰの限界に対処するものである。ＳＢＴＤＲＰにより、アプリケーション（単数または複数）をホストするサーバーは、任意のビットマップ記憶およびクライアント側での記憶されたビットマップ表示を指示し、制御して、サーバー上で実行するアプリケーションのＧＵＩをクライアント上で提示できるようになる。この指示と制御により、サーバーはそれ以外にクライアント側で複雑なレンダリング動作やキャッシング動作になるものを、クライアント側で２つ以上の面で３方向または４方向のＲＯＰＳ（ｒａｓｔｅｒｏｐｅｒａｔｉｏｎｓ：ラスター動作）に抽象化する。ＣＯＰＹＲＯＰは、この動作の一例である。ところが、従来のＲＤＰは、この実装では、多数の異なるグラフィックオブジェクトのクライアント側のキャッシングをレンダリングロジックと緊密に結合し、サーバーのみが（例えば、サーバーによりリソースビットが記憶されている場所をクライアントへマッピングするために）キャッシュ管理ロジックを実装する。ＳＢＴＤＲＰのシステムおよび方法のこれらのおよび他の態様をより詳細に示す。

例示的なシステム
図１は、一実施形態のビットマップ転送形式表示リモーティングの例示的なシステム１００を示す図である。この実装では、図１は、例えば、ネットワーク１０４を介して１つまたは複数のクライアント・コンピューティング・デバイス１０６（「クライアント１０６」）に結合されるサーバー・コンピューティング・デバイス１０２（「サーバー１０２」）を含む。この実装では、サーバー１０２は、サーバー、ＰＣ（パーソナルコンピュータ）、ラップトップなどの任意の１つまたは複数の汎用コンピューティングデバイスを表す。クライアントデバイス１０６は、ＰＣ、ラップトップコンピュータ、モバイル・コンピューティング・デバイス、または汎用またはサーバー・コンピューティング・デバイスに比べて限られた処理機能やデータ記憶機能を有する任意のスモール・フォーム・ファクター・デバイス（例えば、ＰＤＡ（携帯端末）、モバイルデバイス、携帯電話など）の任意の１つまたは複数の汎用コンピューティングデバイスを表す。ネットワーク１０４は、オフィスで一般的な通信環境、企業規模のコンピュータネットワーク、イントラネット、およびインターネットなどのＬＡＮ（ｌｏｃａｌａｒｅａｎｅｔｗｏｒｋ）と一般的なＷＡＮ（ｗｉｄｅａｒｅａｎｅｔｗｏｒｋ）の通信環境との任意の組み合わせを表す。

各コンピューティングデバイス１０２、１０６は、それぞれエンコードされたコンピュータプログラムモジュールを備えるシステムメモリーに結合された１つまたは複数のプロセッサーを含む。コンピュータプログラムモジュールは、プロセッサー（単数または複数）の各々により実行可能な命令を含む。このようなシステムメモリーは、さらにプログラムモジュール実行時に、コンピュータプログラム命令の各々により生成され、および／または使用されるプログラムデータを含む。例えば、サーバー１０２は、揮発性ＲＡＭ（ｒａｎｄｏｍａｃｃｅｓｓｍｅｍｏｒｙ）や不揮発性ＲＯＭ（ｒｅａｄｏｎｌｙｍｅｍｏｒｙ）を示すシステムメモリー１１０に結合された１つまたは複数のプロセッサー１０８を含む。システムメモリー１１０は、プロセッサー（単数または複数）１０８により実行可能なコンピュータプログラム命令を備えるプログラムモジュール１１２を含む。システムメモリー１１２は、さらにプログラムモジュール実行時に、プログラムモジュール１１２の各々により生成され、および／または使用されるプログラムデータ１１４も含む。

この実装では、例えば、プログラムモジュール１１４は、端末サービスベースのアクセス用の１つまたは複数の任意のアプリケーション１１６（例えば、ワードプロセッサー、電子メールプログラム、スプレッドシートアプリケーションなど）、サーバー側端末サービス１１８、およびランタイム環境を提供するオペレーティングシステム、デバイスドライバー、ネットワーク通信ロジックなどの他のプログラムモジュール１２０を含む。この実装では、例えば、クライアント１０６側のコンピュータプログラムロジックは、クライアントベースの端末サービス１２２およびオペレーティングシステム、ドライバー、ネットワーク通信ロジックなどの他のプログラムモジュール１２４を含む。サーバーの端末サービス１１８およびクライアントの端末サービス１２２により、クライアント１０６のユーザーはネットワーク１０４を介して端末サービスセッションを確立して、サーバー１０２上で１つまたは複数の任意のアプリケーション１１６を起動して、ファイル、データベース、ネットワークリソースなどの任意の組み合わせにアクセスすることができる。実行アプリケーション（単数または複数）１１６は完全にサーバー１０２上で起動されるが、システム１００はＳＢＴＤＲＰ（ｓｉｍｐｌｅｂｉｔｍａｐｔｒａｎｓｆｅｒ−ｂａｓｅｄｄｉｓｐｌａｙｒｅｍｏｔｉｎｇｐｒｏｔｏｃｏｌ：簡易ビットマップ転送形式表示リモーティングプロトコル）を実装して、ディスプレイ装置１３０を介して実行アプリケーション（単数または複数）１１６のＧＵＩの要素をエンドユーザーに提示する。

ＳＢＴＤＲＰ（簡易ビットマップ転送形式表示リモーティングプロトコル）
この実装では、例えば、ＳＢＴＤＲＰは、サーバー側端末サービス１１８の一部としてビットマップ転送形式表示リモーティングモジュール（またはロジック）１２６により、またクライアント側端末サービス１２２の一部としてクライアント側ビットマップ記憶・表示ロジック１２８により実装される。ＳＢＴＤＲＰにより、サーバー１０２のビットマップ転送形式表示リモーティングロジック１２６（「リモーティングロジック１２６」）は、クライアント１０６側で任意のビット記憶および記憶されたビット表示を指示し、制御して、サーバーがホストする実行アプリケーション（単数または複数）１１６の１つまたは複数のＧＵＩをユーザーに提示することができる。ＳＢＴＤＲＰは、クライアントが拡張ＲＤＰを実装するために複雑なキャッシングやレンダリングのロジックを実装する必要がある従来のＲＤＰベースの表示リモーティング動作を克服するものである。これを達成するために、ＳＢＴＤＲＰは、従来の複雑な表示リモーティングプロトコルを、クライアント１０６側のサーバーが目的とする（ｓｅｒｖｅｒ−ｐｕｒｐｏｓｅｄ）オフセットスクリーン表示面（単数または複数）に対する簡易サーバー制御ビットマップ転送（ラスター）動作に抽象化する。

この実装では、例えば、ＳＢＴＤＲＰは、以下の例示的なコマンド１３２（インターフェイスまたはコール）を含む。ＣｒｅａｔｅＳｕｒｆａｃｅ、ＳｅｔＳｕｒｆａｃｅＢｉｔｓ、ＴｒａｎｓｆｅｒＳｕｒｆａｃｅＢｉｔｓ、ＤｅｓｔｒｏｙＳｕｒｆａｃｅである。このコマンド１３２のセットは、それよりも多くても少なくてもよく、システム１００の特定の実装の機能とすることができる。さらに、例示的なコマンド１３２に付けられた特定の名前は一例であり、各コマンドのそれぞれの実装に関連付けられた動作それぞれを説明するように考えられている。したがって、これらのインターフェイスとそれらに関連する動作は、すぐ後で詳細に説明するが、異なる名前のインターフェイスで表すことができる。

ＣｒｅａｔｅＳｕｒｆａｃｅ（．．．）
ＣｒｅａｔｅＳｕｒｆａｃｅコマンド１３２はサーバー側リモーティングロジック１２６により発行されて、サーバーが目的とするビットマップ記憶のために特定のサイズのオフスクリーン表示面１３６をクライアント１０６に割り当てるようにクライアント側ロジック１２８に指示する。この実装では、例えば、ＣｒｅａｔｅＳｕｒｆａｃｅのパラメータは、クライアント側ロジック１２８が新規に作成されたオフスクリーン表示面１３６にマッピングするためのサーバーが提供した（ｓｅｒｖｅｒ−ｓｕｐｐｌｉｅｄ）一意のＩＤ（識別子）と面サイズとを含む。この実装では、面サイズはビットマップの幅、高さ、色の深み（例えば、１ピクセル当たり８、１６、２４、３２ビット）として表される。バイト数は、クライアント１０６およびサーバー１０２によりこれらの寸法から判断される（すなわち、バイト数は、１ピクセル当たりのバイトの幅、高さ、色の深みである）。可能な色の深みは、最初のプロトコル機能交換（ｉｎｉｔｉａｌｐｒｏｔｏｃｏｌｃａｐａｂｉｌｉｔｙｅｘｃｈａｎｇｅ）で交渉（ｎｅｇｏｔｉａｔｅ）することができる。ＣｒｅａｔｅＳｕｒｆａｃｅコマンド１３２の受信に応答して、クライアント側ロジック１２８は、要求された表示面１３６を割り当てて、サーバーが提供した一意の面ＩＤを新規に割り当てられた表示面１３６にマッピングする。以下で説明するように、リモーティングロジック１２６はこのＩＤを利用して、次のコマンド１３２内のこの割り当てられた特定の面を参照する。

この実装では、例えば、従来のメッセージング技術を使用して、リモーティングロジック１２６は、クライアント１０６が任意のサーバーが目的とするビットをキャッシングするために利用することができる最大メモリー量を判断する。この判断に基づいて、リモーティングロジック１２６は、少なくとも１つのサブセットの最大メモリー量をオフスクリーン表示面１３６として割り当てるようにクライアント１０６に指示する。このシナリオでは、リモーティングロジック１２６は、サーバー１０２上で実行するアプリケーション１１６からのレンダリングコマンド／コールの検出および／またはマッピングとは無関係に、クライアント１０６にオフスクリーン表示面１３６を割り当てさせる。これが、従来のＲＤＰベースの実装と大きく異なる点である。

ＳｅｔＳｕｒｆａｃｅＢｉｔｓ（．．．）
サーバー側リモーティングロジック１２６は、ネットワーク１０４を介してＳｅｔＳｕｒｆａｃｅＢｉｔｓコマンド１３２をクライアント１０６に通信して、識別されたクライアント側オフスクリーン表示面１３６上の特定の目標位置（ｄｅｓｔｉｎａｔｉｏｎｌｏｃａｔｉｏｎｓ）でビットセットを記憶するようにクライアント側ロジック１２８に指示する。この実装では、例えば、ＳｅｔＳｕｒｆａｃｅＢｉｔｓのパラメータは、オフスクリーン表示面１３６とビットセットとビットの目標位置とを識別する一意のＩＤを含む。１つの実装では、例えば、目標位置は、左、上、右、下の座標で表される矩形の座標を識別する。あるいは、記憶する矩形は、Ｘ、Ｙ、幅、高さを使用して識別される。別の実装では、目標位置は、矩形でない（例えば、正方形、円、任意の形状など）幾何学的オブジェクト（単数または複数）の座標を識別する。

ＳｅｔＳｕｒｆａｃｅＢｉｔｓコマンド１３２に応答して、クライアント側ロジック１２８は、指定されたオフスクリーン表示面１３６上の指示された目標位置（単数または複数）に対する指定ビットを記憶する。以下の段落００５６〜００５８で説明するように（また、図６を参照）、リモーティングロジック１２６により記憶されているビットセットが、次にレンダリングロジック１２６により使用される可能性があるグラフィックオブジェクトを描画するビットと一致して、サーバー１０２上で実行するアプリケーション１１６のＧＵＩの１つまたは複数の態様をレンダリングする。しかし、クライアント１０６から見れば、ビットマップのビットであることとは無関係に、これらの記憶されたビットの意味またはセマンティクスは重要ではなく、つまりビットマップが任意の意味を有し、ビットがサーバー１０２に指示されるようにクライアント側ロジック１２８によりオフスクリーン表示面１３６に記憶されているだけである。

ＴｒａｎｓｆｅｒＳｕｒｆａｃｅＢｉｔｓ（．．．）
リモーティングロジック１２６は、ＴｒａｎｓｆｅｒＳｕｒｆａｃｅＢｉｔｓコマンド１３２を使用して、ディスプレイ装置１３０を介してクライアント１０６により提示するために特定のクライアント側オフスクリーン表示面１３６内にキャッシングされている特定のビット（単数または複数）を異なる表示面（例えば、オンスクリーンのレンダリング面１３８、別のオフスクリーン面など）に転送するようにクライアント側ロジック１２８に指示する。この実装では、例えば、ＴｒａｎｓｆｅｒＳｕｒｆａｃｅＢｉｔｓのパラメータは、以下のうちの１つまたは複数を含む。

特定のオフスクリーン表示面１３６を識別する一意のソース面ＩＤ。

ターゲットビットマップの目標面（例えば、オンスクリーン表示面）を識別する目標面ＩＤ。

識別された目標面に転送するためにターゲットビットマップを表すビットセットを識別するソース矩形（または他の任意の形状）。

転送されたビットマップを受信するための目標面における目標矩形（またはクリッピング領域などの他の任意の形状）。１つの実装では、ＴｒａｎｓｆｅｒＳｕｒｆａｃｅＢｉｔｓコマンド１３２は、更新のためのクリッピング領域（ｃｌｉｐｐｉｎｇｒｅｇｉｏｎ）（目標面の不規則なエリアを画定する矩形セット）を含む。

マスクビットマップ（または面）。例えば、ＭａｓｋＢｌｔはビットマップ転送動作であり、この動作により、マスク内の対応ピクセルの値に基づいて選択的にピクセルがソース面から目標面に転送される。例えば、マスクビットマップの１００，１００の座標のピクセルが０（黒）に設定された場合のみ、１００，１００の座標のピクセルがソース面から目標面まで転送される。

クライアントロジック１２８がソース面から目標面へビットマップ転送を実装するためのラスター動作（すなわち、コピー、ｘｏｒなど）の指示。１つの実装では、例えば、ＴｒａｎｓｆｅｒＳｕｒｆａｃｅＢｉｔｓコマンド１３２は、クライアントロジック１２８にマスク面動作を実装するように指示する。

１つの実装では、クライアント側ロジック１２８によるビットマップ転送の失敗により、クライアントロジック１２８は一般的な「ダーティ（ｄｉｒｔｙ）」面の通知１３４をリモーティングロジック１２６に通信して、リモーティングロジック１２６にその面のビットが有効でないことを通知する。１つの実装では、この通知に応答して、サーバー１０２は、無効の面のビット／領域のためにクライアントロジック１２８に更新版を送信する（更新版により、その領域が有効になる）。

ＤｅｓｔｒｏｙＳｕｒｆａｃｅ（．．．）
リモーティングロジック１２６は、ＤｅｓｔｒｏｙＳｕｒｆａｃｅコマンド１３２を送信して、サーバー１０２が開始し、目的とするオフスクリーン表示面１３６を破壊（再割り当て）するようにクライアントロジック１２８に指示する。この実装では、ＤｅｌｅｔｅＳｕｒｆａｃｅのパラメータは、例えば、特定のオフスクリーン表示面１３６に対する一意の面ＩＤを含む。

例示的なサーバーが目的とするビットマップ記憶及び転送
以下の実施例は、ＴＳベースのサーバー上で実行するアプリケーションのＧＵＩの要素をＴＳベースのクライアント上で表示する従来のＲＤＰの使用を、ＳＢＴＤＲＰの使用と比較対照したものである。これらの実施例は一例であり、これらの実施例の範囲から逸脱せずに、他の動作の順序、グラフィックオブジェクト、面などに置き換えることができる。

従来のＲＤＰベースのロジックを使用する場合、以下の動作は、典型的には、特定の位置にブラシオブジェクトをキャッシングし、ブラシオブジェクトを使用して、主要なオンスクリーン表示面の矩形を埋めなければならない。例示するために、そのブラシは１６×１６ピクセルブラシで、オンスクリーン表示面のレンダリング位置は（０，０，６４，１６）であり、面のエリアの表示はこのような複数のブラシをカプセル化している。

サーバー（「Ｓ」）とクライアント（「Ｃ」）との間で初期プロトコル交換の一部として、キャッシュタイプ（例えば、ブラシ、グリフ、フォント、フラグメント、ビットマップなど）およびサイズを交渉することで、クライアントはキャッシュ管理動作をグラフィックオブジェクトレンダリング動作と緊密に結びつけた複雑なキャッシュ管理サービスを設定することができる。この実施例では、キャッシュタイプはブラシキャッシュである。キャッシュサイズは、例えば、１００エントリを有する１６（幅）×１６（高さ）キャッシュ、２００エントリを有する４２×３２キャッシュなどを含む。

サーバーは、ブラシ用のビットマップビットおよび原点を取得し、ブラシキャッシュ内のある指定された位置（例えば、位置９９）でキャッシングするためにこれらをクライアントに送信する。

サーバーは、ブラシキャッシュ位置９９内のブラシを使用して、オンスクリーン表示面の（０，０，６４，１６）における面の矩形を埋めるようにクライアントに命令する。クライアントは、ＲＤＰコマンドをキャッシュされたブラシを使用する対応ＧＤＩコールに変換することでこれに応答する。クライアントはＧＤＩコールをクライアントのオペレーティングシステムに提出（ｓｕｂｍｉｔ）して、指示されたようにブラシを描画する。面の矩形サイズがブラシ（１６×１６）のサイズであれば、クライアント側のＧＤＩは複数のブラシレンダリングコマンドを繰り返し実行して、面の矩形を埋めることになる。

上述の実施例とは対照的に、図１のシステム１００は、ＳＢＴＤＲＰを利用して、クライアント側のオフスクリーン表示面のブラシのビットマップおよび複数のサーバー開始のビットマップコピーコマンド（１回に１コマンドを連続的に）を記憶して、クライアント１０６側のオンスクリーン表示面の矩形を埋める。したがって、サーバーはアプリケーション１１６からのより複雑なレンダリングコマンド（例えば、ＧＤＩコマンド）をより簡易なビットマップ転送コマンドに分解する、または分割する。このコンテキストにおいてキャッシングと記憶との違いの１つは、ＲＤＰを使用してクライアント側でオブジェクトをキャッシングするためには、ＲＤＰベースのクライアントがキャッシュ管理ロジックに、キャッシング動作の実行およびオブジェクト転送の実行を要求する点である。一方、クライアント１０２におけるビットマップ記憶およびビットマップ転送は、クライアント１０２のいずれのキャッシュ管理とは全く無関係である。

例示し比較するために、ブラシサイズは１６×１６ビットであり、クライアント１０６側のオンスクリーン表示面（例えば、「面０」）における面の矩形の座標は（０，０，６４，１６）である。直前の実施例にあるように、ターゲット面の矩形を埋めるのは複数のレンダリング動作が必要であるだろう。前の実施例では、クライアントはＧＤＩを使用してサーバーコマンドを複数のレンダリング動作に変換し、面の矩形を埋めている。一方、サーバー１０２は、複数の面ビット転送コマンドをクライアント１０２に繰り返し通信して、例示的なレンダリング動作を実行している。

リモーティングロジック１２６とクライアント側ロジック１２８とが交渉して、オフスクリーン表示面１３６を（例えば、初期プロトコル動作の一部として）割り当てる。例示するために、このようなオフスクリーン表示面を図２に示す。

リモーティングロジック１２６は、クライアント１０６に、サーバーが提供した（およびサーバーが保持した）一意の識別子（例えば、ＩＤ８８）にマッピングされたオフクスリーン面１３６を作成するように命令する。１つの実装では、オフスクリーン面は少なくとも１６×１６である。

リモーティングロジック１２６は、面ＩＤ８８の位置（０，０，１６，１６）のビットマップビットを（ＳｅｔＳｕｒｆａｃｅＢｉｔｓコマンド１３２を使用して）ブラシオブジェクトを表す特定のビットマップビットに設定するようにクライアント１０６に命令する。

リモーティングロジック１２６は、位置（０，０，１６，１６）の面ＩＤ８８から（ＴｒａｎｓｆｅｒＳｕｒｆａｃｅＢｉｔｓコマンド１３２を使用して）ビットを位置（０，０，１６，１６）の面０に転送するようにクライアント１０６に命令する。

リモーティングロジック１２６は、ビットを位置（０，０，１６，１６）のオフスクリーン表示面ＩＤ８８から位置（１６，０，４２，１６）の面０に転送するようにクライアント１０６に命令する。

リモーティングロジック１２６は、ビットを位置（０，０，１６，１６）のオフスクリーン表示面ＩＤ８８から位置（３２，０，５８，１６）の面０に転送するようにクライアント１０６に命令する。

リモーティングロジック１２６は、ビットを位置（０，０，１６，１６）の面８８から位置（４８，０，６４，１６）の面０に転送するようにクライアント１０６に命令する。

ＳＢＴＤＲＰを使用する前述の実施例では、リモーティングロジック１２６は面ビット転送コマンド１３２を繰り返し（この例では、４回）実装して、指定された目標矩形を指定されたブラシビットマップで埋めることに留意されたい。従来のシステムとは対照的に、システム１００により実装される簡易プロトコルは、ビットマップブラシ処理（およびサーバー１０２で実行するアプリケーション１１６からＧＵＩを、リモートクライアント１０６に結合されたディスプレイ装置１３２上に表示するために利用される他の動作）のために、簡易ＳＢＴＤＲＰコマンドを使用する。その結果、クライアント１０６は、簡易ビットマップ／面の読み出しおよび書き込み操作を実装して、サーバー１０２で実行するアプリケーション１１６に関連付けられたＧＵＩのそれぞれの部分をレンダリングする構成となる。すなわち、サーバー１０２は複雑なグラフィックレンダリングコマンド（例えば、ＦｉｌｌＲｅｃｔＧＤＩコマンド）を個々の対応するビットマップラスター動作コマンドに分割する。これは、従来のＲＤＰシステムとは対照的な点であり、クライアントは、複数の異なるグラフィックオブジェクト固有のキャッシュを保持し、種々のグラフィックオブジェクト（グリフ、ブラシ、ビットマップなど）間のセマンティクスの差を理解し、頻繁に（例えば、ブラシキャッシュからのブラシで矩形を埋めるために）ＲＤＰレンダリングコマンドを対応するＧＤＩコマンドに変換するように構成される。

例示的なプロシージャ
図３は、一実施形態のビットマップ転送形式表示リモーティングの例示的なプロシージャを示す図である。例示し説明するために、プロシージャ３００の動作は図１の態様およびコンポーネントに関して説明する。説明では、コンポーネントの符番の最も左の数字はそのコンポーネントが最初に紹介された特定の図面を示している。図３を参照すると、ブロック３０２の動作は、サーバーリモーティングモジュール１２６（図１）により、サーバー１０２で実行するアプリケーション１１６がアプリケーションのＧＵＩの一部をレンダリングする動作に関与すると判断する。この動作は、例えば、ＧＵＩをレンダリングするのに次に使用するためのブラシ、グリフ、フォント、フラグメントなどのグラフィックオブジェクトの作成を含む。別の実施例では、この動作は、ブラシで埋め込みコマンドなどの実際のレンダリングコマンドを含む。ブロック３０４の動作は、動作に関連付けられたコマンド（例えば、ブロック３０２参照）を対応するビットマップラスター動作コマンドに分解する、または分割する。

例えば、上述したように、アプリケーション１１６がＧＤＩコマンドを生成してブラシのグラフィックオブジェクトを作成する場合、サーバーリモーティングロジック１２６は、ビットマップをクライアント１０６の特定のオフスクリーン表示面１３６に書き込む。別の実施例では、アプリケーション１１６がブラシのグラフィックオブジェクトを利用してＧＵＩの一部に書き込む場合、サーバーリモーティングロジック１２６は、（１回または数回）ブラシに対応するビットマップをオンスクリーン表示面１３８の特定の部分に転送して、ユーザーにＧＵＩ部を提示するようにクライアント１０６に指示する。この転送動作は、ビットマップ読み出し及び書き込み動作を含む。

ブロック３０６の動作は、ビットマップラスター動作コマンド（ブロック３０４の動作を参照）をクライアント１０６に送信する。ブロック３０８の動作は、クライアント１０６により、受信されたビットマップラスター動作コマンドを復号化して、オンスクリーン表示面１３８に対応するビットマップを記憶／または描画して、ユーザーにＧＵＩ部を提示する。１つの実装では、コマンドは、ビットマップ（単数または複数）をオンスクリーン面に転送する前に１つのオフスクリーン面から別のオフスクリーン面にビットマップ（単数または複数）を転送するようにクライアント１０６に指示してもよい。ビットマップを記憶し、描画してＧＵＩ部を提示するためのクライアント１０６側のロジックは、クライアント実装のキャッシュ管理ロジックとは全く無関係である。さらに、クライアントロジックは、ビットマップのセマンティクスを超えたグラフィックオブジェクトのセマンティクスの任意の判断や処理とは全く無関係である。これが、従来のＲＤＰ動作とは対照的な点である。

図４は、一実施形態のビットマップ転送形式表示リモーティングの例示的なプロシージャを示す図である。例示し説明するために、プロシージャ４００の動作は、図１の態様およびコンポーネントに関して説明する。説明では、コンポーネントの符番の最も左の数字はそのコンポーネントが最初に紹介された特定の図面を示している。図４を参照すると、ブロック４０２動作は、サーバーにより、サーバーが指示し（ｄｉｒｅｃｔｅｄ）かつ目的とするデータ記憶のためにオフスクリーン表示面を割り当てるようにクライアントに指示する。１つの実装では、サーバー１０２側のリモーティングロジック１２６は、ＣｒｅａｔｅＳｕｒｆａｃｅコマンド１３２を使用して、このようなサーバーが指示し、サーバーが目的とするデータ記憶のためにオフスクリーン表示面１３６を割り当てるようにクライアント１０６のクライアント側ロジック１２８に指示する。このサーバーが指示し、サーバーが目的とするデータ記憶とは、サーバー１０２で実行するアプリケーション１１５のＧＵＩを（例えば、ディスプレイ装置１３０を使用して）クライアント１０６のユーザーに提示することである。

ブロック４０４の動作は、サーバーにより、特定の位置に対するビットマップをオフスクリーン表示面上に記憶するようにクライアントに要求する。１つの実装では、例えば、この動作は、ＧＤＩまたは他のグラフィックインターフェイスを要求するアプリケーションに応答して行われ、グラフィックオブジェクト（例えば、ブラシ、グリフ、ビットマップ、フォントなど）を作成または変更してサーバー上にＧＵＩをレンダリングする。１つの実装では、レンダリングロジック１２６はアプリケーション１１６からＧＤＩへのコールをインターセプトする。別の実装では、例えば、この動作は、ＧＤＩに対する要求とは無関係に実行される。例えば、この動作は、ＧＤＩ出力（例えば、黒い矩形など）以外のものなどを表示するように要求されるクライアントに応答して実行される。このコールがＧＵＩをレンダリングするためのグラフィックオブジェクトの作成または変更に関連付けられる場合、レンダリングロジック１２６は、割り当てられたオフスクリーン表示面１３６上の特定の位置にグラフィックオブジェクトを表す任意のビットマップを記憶するようにクライアント側ロジックに要求する。この要求は、例えば、ＳｅｔＳｕｒｆａｃｅＢｉｔｓコマンド１３２をクライアント側ロジック１２８に通信するレンダリングロジック１２６により行われる。

ブロック４０６の動作は、サーバーがアプリケーションからのレンダリングコマンドをインターセプトすることに応答して行われる。ここで、レンダリングコマンドは、前に作成されたグラフィックオブジェクト（例えば、ブラシ、グリフなど）に関連付けられる。（特定のアプリケーションからレンダリングコマンドをインターセプトするのに、ミラードライバーなどの技術が既知である。）具体的には、ブロック４０６の動作は、サーバーにコマンドをクライアントに対して送信させて、オフスクリーン表示面からクライアント側表示面上の少なくとも１つの位置に、前に作成されたグラフィックオブジェクトに対応するビットマップを転送するようにクライアントに指示する。これらの動作は、クライアントのユーザーに提示するためのＧＵＩの一部をレンダリングすることになる。１つの実装では、例えば、ブロック４０６の動作は、ＴｒａｎｓｆｅｒＳｕｒｆａｃｅＢｉｔｓコマンド１３２をクライアント側ロジック１２８に通信するレンダリングロジック１２６により実装される。クライアント側ロジック１２８によりこのコマンドが受信されることで、クライアント側ロジック１２８はサーバーが指定したビットマップを異なる表示面（例えば、オンスクリーンレンダリング面１３８）の目標位置に転送する。クライアント側ロジック１２８によるこれら任意のビットマップの転送動作は、サーバー１０２上で実行するアプリケーション１１６のＧＵＩの一部となり、クライアント１０６のユーザーに提示される。ビットマップ転送形式表示リモーティングのこれらのさらに詳細な例示的なプロシージャを、図４〜図７に関してより詳細に説明する。

図５は、一実施形態のビットマップ転送形式表示リモーティングでリモートクライアントデバイスにおいてオフスクリーン表示面を作成するための別の例示的なプロシージャ５００を示す図である。例示し説明するために、プロシージャ５００の動作を図１の態様およびコンポーネントに関して説明する。説明では、コンポーネントの符番の最も左の数字は、そのコンポーネントが最初に紹介された特定の図面を示している。

図５では、ブロック５０２の動作は、サーバーによりクライアントに、サーバーが指示し、サーバーが目的とするビットマップ記憶動作に特定のサイズのオフスクリーン表示面を割り当てるように指示する。この指示は、要求された面がビットマップまたは任意の他のデータ記憶に使用されることになることをクライアント１０２に示す情報を全く含まない。１つの実装では、例えばサーバー１０２のリモーティングロジック１２６は、クライアント１０６がオフスクリーン表示面１３６に割り当てることができるサイズ（例えば、最大サイズ、デフォルトサイズ、またはそれ以外のサイズ）を示すようにクライアント側ロジック１２８に要求する。サイズの判断に応答して、リモーティングロジック１２６はＣｒｅａｔｅＳｕｒｆａｃｅコマンド１３２をクライアント１０６に送信する。ＣｒｅａｔｅＳｕｒｆａｃｅコマンド１３２は、指示されたサイズのオフスクリーン表示面１３６を割り当てるようにクライアント側ロジック１２８に指示する。この通信は、さらに新規に割り当てられたオフスクリーン表示面１３６に関連付けるために、クライアント側ロジック１２８のためのサーバーが提供した一意のＩＤを含む。以下で示すように、リモーティングロジック１２６は、この特定のオフスクリーン表示面１３６に関連付けられたビットマップ形式の動作を実行するようにクライアント側ロジック１２８に指示するときに、この一意のＩＤを使用することになる。１つの実装では、ブロック５０２の動作は、リモーティングロジック１２６およびクライアント側ロジック１２８により初期プロトコル構成動作の一部として実装される。ブロック５０４の動作は、オフスクリーン表示面１３６を作成するコマンド１３２を（クライアント１０６により）受信することに応答して、クライアント１０６は特定の指定されたサイズまたはデフォルトサイズのオフスクリーン表示面１３６を割り当てる。

ブロック５０６の動作は、レンダリングコマンド（例えば、ＧＤＩに対するコール）をインターセプトして、実行端末サービスベースのアプリケーションのＧＵＩを提示する。１つの実装では、例えば、リモーティングロジック１２６は従来のドライバーを利用して、実行アプリケーション１１６から（例えば、ＧＤＩロジックなどに）レンダリングコールをインターセプトして、実行アプリケーション１１６に関連付けられたＧＵＩを提示する。ブロック５０８の動作は、インターセプトされたレンダリングコマンド（またはレンダリング関連コマンド）がグラフィックオブジェクト（例えば、ブラシ、グリフ、フラグメント、ビットマップ、フォントなど）を作成または変更するコマンド（削除／破壊（ｄｅｓｔｒｏｙ）コマンドを含む）であるか否か、またはインターセプトされたレンダリングコマンドが、特定のグラフィックオブジェクトを使用してレンダリング動作（例えば、埋め込みコマンド、描画コマンドなど）を実行するコマンドであるか否かを判断する。１つの実装では、リモーティングロジック１２８は、既知のレンダリングコマンド解析技術（例えば、ＧＤＩコマンド解析技術など）を使用してコマンドを解析することにより、この判断を行う。ブロック５１０で、インターセプトされたレンダリングコマンド／コールが既存のグラフィックオブジェクトを作成または変更するためのものである場合、プロシージャ５００の動作は、ページ上の「Ａ」で示されるように、図６のブロック６０２で継続する。それ以外に、インターセプトされたレンダリングコールが特定のグラフィックオブジェクトを利用してレンダリング動作を実装するためのものである場合、プロシージャ５００の動作は、ページ上の「Ｂ」で示されるように、図７のブロック７０２で継続する。１つの実装では、ブロック５１０の動作は、サーバー１０２のリモーティングロジック１２６により実装される。

図６は、一実施形態のビットマップ転送形式表示リモーティングの例示的なプロシージャのさらなる態様を示す図である。具体的に、図６は図５のプロシージャ５００の続きである。図６を参照すると、動作はページの「Ａ」で示されるように、ブロック６０２で始まる。ブロック６０２の動作は、インターセプトされたレンダリングコマンドが既存のグラフィックオブジェクトを作成または変更するためのものであるとの前の判断（図５のブロック５１０参照）に応答して実装される。ブロック６０２では、サーバーは、特定のオフスクリーン表示面の特定の位置でキャッシングするために、作成されたまたは変更されたグラフィックオブジェクトを表すビットをクライアントに通信する。１つの実装では、リモーティングロジック１２６は、ＳｅｔＳｕｒｆａｃｅＢｉｔｓコマンド１３２を使用して、サーバーが識別したオフスクリーン表示面１３６上のサーバー指定の位置で、クライアント側ロジック１２８によりキャッシングするために、作成されたまたは変更されたグラフィックオブジェクトを表すビットをクライアント側ロジック１２８に通信する。例示のために、このビットは、図１の「他のプログラムデータ」１４２の各部分として示す。

１つの実装では、例えば、ＳｅｔＳｕｒｆａｃｅＢｉｔｓコマンド１３２内の作成された、または変更されたグラフィックオブジェクトビットは、例えば、ビットマップサイズ、色、圧縮などを示している。これらのビットをクライアント１０６に送信する動作は、対応するビット定義またはビットのコンテキストの任意の指示をクライアント１０６に送信することとは全く無関係である。さらに、ＳｅｔＳｕｒｆａｃｅＢｉｔｓコマンド１３２内で指定された特定のオフスクリーン表示面１３６は、リモーティングロジック１２６が一意のＩＤで識別する面１３６である。この実装では、面１３６がＣｒｅａｔｅＳｕｒｆａｃｅコマンド１３２を使用して作成されたときに、リモーティングロジック１２６がこの一意のＩＤをクライアント側ロジック１２８に提供したのを思い出されたい。

ブロック６０４の動作は、面ビット設定コマンドの受信に応答して、面ビット設定コマンドに関連付けられた任意の（クライアント１０６およびクライアント側ロジック１２８から見て任意の）ビットを指定されたオフスクリーン表示面に記憶する。１つの実装では、例えば、クライアント側ロジック１２８は、ＳｅｔＳｕｒｆａｃｅＢｉｔｓコマンド１３２の受信に応答して、関連付けられた任意のビットを指定されたオフスクリーン表示面１３６に、面１３６上のサーバー指定の位置で記憶する。このシナリオでは、クライアント１０６は、通信されたビットはビットマップを表し、ＳｅｔＳｕｒｆａｃｅＢｉｔｓコマンド１３２は対応するビットマップのコピーまたは転送の動作を要求することを理解するように構成される。これ以外に、クライアント１０６の構成は、ＳｅｔＳｕｒｆａｃｅＢｉｔｓコマンド１３２で通信されたビットの定義、コンテキスト、セマンティクスなどを判断する必要が全くない。クライアント１０６から見れば、受信されたビットは、単にリモーティングロジック１２６によりクライアント１０６側で記憶されているセマンティクスが未知の任意のビットマップを表す。したがって、クライアント１０６は、任意のグラフィックオブジェクトベースのセマンティックの判断とは無関係に、受信したビットをキャッシングする。グラフィックオブジェクトベースのセマンティックの判断の例として、例えば、受信したビットはあるタイプのグラフィックオブジェクトを表しているか、そうであった場合、グラフィックオブジェクトのタイプは何かなどの質問に対する回答を判断するロジックを含む。例えば、ビットはブラシ、ビットマップ、グリフ、フラグメントなどを表すかである。従来のＲＤＰクライアントの実装は、グラフィックオブジェクトの判断されたタイプに基づいて特別な処理を実行する。

図７は、一実施形態のビットマップ転送形式表示リモーティングの例示的なプロシージャ５００のさらなる態様を示す図である。具体的には、図７は、図５および図６のプロシージャ５００の続きである（図５のページの「Ｂ」を参照）。図７を参照すると、動作は、インターセプトされたコールが既存のグラフィックオブジェクトを作成または変更するためのレンダリングコールでないとの前の判断（図５のブロック５１０を参照）に応答して、ブロック７０２で始まる。したがって、インターセプトされたコールは、既存のグラフィックオブジェクトまたはレンダリングコマンドを削除するためのものであったことになる。

ブロック７０２の動作は、インターセプトされたコールがグラフィックオブジェクトを削除するためのコールであったか否かを判断する。そうであった場合、動作はブロック７０４で継続し、サーバーがクライアント側スクリーン表示面でビットを保持する必要があるか否かが判断される。この判断は任意であり、サーバー側のリモーティングロジック１２６の特定の実装に基づくものである。例えば、１つの実装では、サーバー側のリモーティングロジックはローカルキャッシュ１４２を評価して、コールで識別されたグラフィックオブジェクトに関連付けられたクライアント側オフスクリーン表示面１３６が、まだ有効であるか否かを判断する。この判断は、サーバー側のリモーティングロジック１２６の特定の実装に基づいた多くの異なる任意のパラメータに基づいて行われる。

例えば、コールによりサーバー側での削除のためにスケジュールされたグラフィックオブジェクトが、クライアント側オンスクリーン表示面１３６内にキャッシングされた対応ビットを有する唯一のオブジェクトである場合、リモーティングロジック１２６は対応ビットを次にキャッシングされる任意のビットで上書きすることを決めてもよいし、または面１３６を削除するようにクライアント側ロジック１２８に要求してもよい。別の実施例では、リモーティングロジック１２６は１つまたは複数のオフスクリーン面１３６を利用して、ブラシをキャッシングすることを考慮する。ブラシがＧＤＩを使用してサーバー１０２側で削除される場合、リモーティングロジック１２６は、クライアント１０６の面でキャッシングされた対応ビットマップが占めるエリアを再び使用するように意図することを判断してもよい（すなわち、面ビットは他の何かに使用することができる）。クライアント側のブラシビットのエリアは、前述の実施例で示したように、１ブラシにつき１つの面として、または同一面１３６のブラシを表す複数のビットマップとして管理することができることに留意されたい。したがって、１つの実装では、リモーティングロジック１２６は、面１３６を削除することはできないが、関連する面ビットの少なくとも一部を再び使用するように意図することのみ可能である。

上述の例を見ると、面１３６の削除が指示された場合、ブロック７０４の動作は、リモーティングロジック１２６に、特定のオフスクリーン表示面１３６を削除するようにクライアント側ロジック１２８に指示するＤｅｌｅｔｅＳｕｒｆａｃｅコマンド１３２を通信させる。このコマンド１３２の受信に応答して、クライアント側ロジックは識別されたオフスクリーン表示面１３６の割り当てを解除する（破壊する）。

ブロック７０２の動作が、インターセプトされたコールがグラフィックオブジェクトを削除するためのコールでなかった場合、コールはレンダリング動作（例えば、描画コマンド、埋め込みコマンド）を実装するために、特定のグラフィックオブジェクトの使用に関連付けられる。したがって、プロシージャ５００の動作は、ブロック７０６で動作を継続する。ブロック７０６では、サーバーは１つまたは複数の面ビット転送コマンドをクライアントに送信して、ビットを特定のオフスクリーン表示面からフレームディスプレイバッファ内の位置にコピーし、インターセプトされたＧＤＩレンダリングコマンドのクライアント側での有効な結果をもたらす。１つの実装では、例えば、レンダリングロジック１２６は、１つまたは複数のＴｒａｎｓｆｅｒＳｕｒｆａｃｅＢｉｔｓコマンド１３２をクライアント側ロジック１２８に送信して、特定の表示面１３６からフレームディスプレイバッファ内の位置にビットをコピーし、インターセプトされたレンダリングコマンドのクライアント１０６側での有効な結果をもたらす。コピーされる特定のビットは、レンダリングロジック１２６により特定のオフスクリーン表示面１３６に、前にキャッシングされたビットを表す。１つの実装では、リモーティングロジック１２６は、サーバー側キャッシュ１４０を使用して、サーバー１０２側のグラフィックオブジェクトを特定のクライアント側オンスクリーン表示面１３６（一意の面ＩＤを使用して）、および面１３６の対応するソース位置にマッピングする。

結論
これまでの段落で、ビットマップ転送形式表示リモーティングを構造的特徴および／または方法動作もしくはアクションに固有の言葉で説明したが、添付の請求項で定義された実装は必ずしも説明した固有の特徴またはアクションに限定されない。例えば、プロシージャ５００の動作（図５、図６参照）は、特定のフローおよび順序で示したが、これらの動作は一例であって、システム１００の一例および例示的な実装を例示したに過ぎない。例えば、クライアント側オフスクリーン表示面１３６を作成する動作は、プロシージャ５００のブロック５０２に関して説明したが、リモーティングロジック１２６はその特定の実装当たりの数と同じ数のオフスクリーン表示面１３６を作成することができる。例えば、ブロック５０６の動作の後、レンダリングに関するコールがインターセプトされ、（ブロック５０２およぶ５０４で説明したように）レンダリングロジック１２６の別の実装が、別のオフスクリーン表示面１３６を作成して、対応するグラフィックオブジェクトのビットをキャッシングすることができる。このことから見て、プロシージャ４００および５００は、システム１００の特定の実装で行われる多くの異なる任意の動作フローの例である。したがって、上述したビットマップ転送形式表示リモーティングの固有の特徴および動作は、請求される主題を実装するための例示的な形態である。

Claims

サーバー・コンピューティング・デバイス（「サーバー」）とクライアント・コンピューティング・デバイス（「クライアント」）との間で、前記サーバーがネットワークを介して前記クライアントに結合された通信方法であって、
前記サーバーにより前記サーバー上で実行するアプリケーションがＧＵＩ（グラフィカル・ユーザー・インターフェイス）の一部をレンダリングする動作に関与するか否かを判断するステップと、
前記判断のステップに応答して、
少なくとも前記動作に関連付けられたコマンドのサブセットを、対応するビットマップ転送コマンドに変換するステップであって、前記ビットマップ転送コマンド（単数または複数）は、ＳＢＴＤＲＰ（簡易ビットマップ転送形式表示リモーティングプロトコル）に基づいており、前記ＳＢＴＤＲＰは、オブジェクトがビットマップとして前記サーバー側でキャッシングされているか否かに関係なく、ビットマップを使用して複数の異なるタイプのオブジェクトを提示することを特徴とする変換するステップと、
前記ビットマップ転送コマンド（単数または複数）のみを前記クライアントに通信するステップと
を含み、前記ビットマップ転送コマンド（単数または複数）の受信は、前記クライアントが（ａ）クライアント実装キャッシュ管理ロジックもしくは（ｂ）ビットマップセマンティクスを超えたグラフィックオブジェクトのセマンティクスの判断および処理とは無関係に、前記クライアントのユーザーに前記一部を提示するためにオンスクリーン表示面に対応するビットマップ（単数または複数）を記憶しかつ描画することをもたらし、
前記サーバーにより、オフスクリーン表示面を割り当てるために、前記クライアントに要求するステップと、
前記サーバーにより、前記オフスクリーン表示面上の特定の位置にビットマップを記憶するために、前記クライアントに要求するステップであって、前記ビットマップは、グラフィカルオブジェクトを表現することを特徴とする要求するステップと、
前記サーバーにより、前記ユーザーに前記一部を表現するために、前記オンスクリーン表示面上の特定の位置に一回または複数回、前記ビットマップを書き込むために、前記クライアントに指示するステップとをさらに含み、
前記方法は、さらに、前記グラフィカルオブジェクトを削除するためのコールがインターセプトされたとき、及び、削除されるべきグラフィカルオブジェクトが、前記オフスクリーン表示面上にキャッシングされた対応ビットを有する唯一のグラフィカルオブジェクトである場合、前記クライアントにより、前記ユーザーに前記ＧＵＩの前記一部を表示することに関連付けられた前記オフスクリーン表示面を前記クライアントが破壊するための要求を前記サーバーにより、通信するステップを含む
ことを特徴とする方法。
前記ビットマップ転送コマンド（単数または複数）の特定のセットの受信は、前記クライアントが、前記サーバーからの任意のコマンドを対応するＧＤＩ（グラフィック・デバイス・インターフェイス）ベースのコマンドに変換することとは無関係に、前記ＧＵＩ部を提示することをもたらすことを特徴とする請求項１に記載の方法。
前記ビットマップ転送コマンド（単数または複数）は、それぞれ、ブラシ、フォント、グリフおよびフラグメントの１つまたは複数のグラフィックオブジェクトを表すビットマップ（単数または複数）の読み出しおよび書き込みの１つまたは複数に向けられており、
前記方法は、
前記サーバーにより少なくとも１つのキャッシュを管理して、ブラシ、フォント、グリフ、フラグメントの１つまたは複数のグラフィックオブジェクトを、前記クライアント側の１つまたは複数のオフスクリーン表示面の１つまたは複数の各々の位置に記憶されている１つまたは複数の対応するビットマップにマッピングするステップ
をさらに含むことを特徴とする請求項１に記載の方法。
前記対応するビットマップ（単数または複数）の１つのビットマップは、前記ＧＵＩ部より小さく、少なくとも１つのサブセットのコマンドは、複数の簡易ビットマップ形式コマンドに変換され、前記方法は、
前記サーバーにより前記一部の異なる部分をレンダリングするための前記簡易ビットマップ形式コマンドの各々を前記クライアントに通信して、前記一部をレンダリングするステップ
をさらに含むことを特徴とする請求項１に記載の方法。
前記サーバーにより前記特定の位置に前記ビットマップを記憶するように前記クライアントに要求するステップにおいて、前記オフスクリーン表示面上で前記サーバーにより前に記憶されている異なるビットマップの少なくとも一部を上書きすることを特徴とする、請求項１に記載の方法。
サーバー・コンピューティング・デバイス（「サーバー」）とクライアント・コンピューティング・デバイス（「クライアント」）との間で、前記サーバーがネットワークを介して前記クライアントに結合された前記請求項１乃至５のいずれか１項に記載の通信方法を実行するように適用されたサーバー・コンピューティング・デバイス。
コンピュータに実行されたときに前記請求項１乃至５のいずれか１項に記載の通信方法をコンピュータに実施させるコンピュータ実行可能命令を含むコンピュータ可読記録媒体。