(57)【要約】  クライアントに結合されたサーバーによるビットマップ転送形式表示リモーティングを説明する。具体的には、サーバー上で実行するアプリケーションはＧＵＩ（グラフィカル・ユーザー・インターフェイス）の一部をレンダリングする動作を実装する。サーバーは対応するレンダリング形式のコマンド（単数または複数）を簡易ビットマップラスター動作コマンドに分解する。サーバーはビットマップ形式のコマンドをクライアントに送信する。クライアントは、そのコマンドの受信に応答して、サーバーが指示するように、オフスクリーン表示面からオンスクリーン表示面にビットマップをそれぞれ記憶しかつ描画して、ユーザーにＧＵＩ部を提示する。ＧＵＩ部を記憶しかつ提示するためのクライアント側のロジックは、クライアント実装表示リモーティングキャッシュ管理ロジックとは無関係である。また、クライアントの動作は、ビットマップセマンティクスを超えたグラフィックオブジェクトのセマンティクスの判断および処理とも無関係である。このような管理およびセマンティクスの判断や処理は、それぞれサーバー側でサーバーにより実装されかつ保持される。
2010529537.tif 000002
【特許請求の範囲】
【請求項１】
サーバー・コンピューティング・デバイス１０２（「サーバー」）とクライアント・コンピューティング・デバイス１０６（「クライアント」）との間で、前記サーバーがネットワーク１０４を介して前記クライアントに結合された通信方法３００であって、
前記サーバーにより前記サーバー上で実行するアプリケーション１１６がＧＵＩ１４２（グラフィカル・ユーザー・インターフェイス）の一部をレンダリングする動作に関与するか否かを判断するステップ３０２と、
前記判断のステップに応答して、
少なくとも前記動作に関連付けられたコマンドのサブセットを、対応するビットマップ転送コマンド１３２に変換するステップ３０４と、
前記ビットマップ転送コマンド（単数または複数）のみを前記クライアントに通信するステップ３０６と
を含み、前記ビットマップ転送コマンド（単数または複数）の受信は、前記クライアントが（ａ）クライアント実装キャッシュ管理ロジックもしくは（ｂ）ビットマップセマンティクスを超えたグラフィックオブジェクトのセマンティクスの判断および処理とは無関係に、前記クライアントのユーザーに前記一部を提示するためにオンスクリーン表示面に対応するビットマップ（単数または複数）を記憶しかつ描画する３０８ことをもたらすことを特徴とする方法。
【請求項２】
前記サーバーは、ＲＤＰサーバーであることを特徴とする、請求項１に記載の方法。
【請求項３】
前記ビットマップ転送コマンド（単数または複数）の特定のセットの受信は、前記クライアントが、前記サーバーからの任意のコマンドを対応するＧＤＩ（グラフィック・デバイス・インターフェイス）ベースのコマンドに変換することとは無関係に、前記ＧＵＩ部を提示することをもたらすことを特徴とする請求項１に記載の方法。
【請求項４】
前記ビットマップ転送コマンド（単数または複数）は、ＳＢＴＤＲＰ（簡易ビットマップ転送形式表示リモーティングプロトコル）に基づいており、前記ＳＢＴＤＲＰは、オブジェクトがビットマップとして前記サーバー側でキャッシングされているか否かに関係なく、ビットマップを使用して複数の異なるタイプのオブジェクトを提示することを特徴とする請求項１に記載の方法。
【請求項５】
前記ビットマップ転送コマンド（単数または複数）は、それぞれ、ブラシ、フォント、グリフおよびフラグメントの１つまたは複数のグラフィックオブジェクトを表すビットマップ（単数または複数）の読み出しおよび書き込みの１つまたは複数に向けられており、前記方法は、
前記サーバーにより少なくとも１つのキャッシュを管理して、ブラシ、フォント、グリフ、フラグメントの１つまたは複数のグラフィックオブジェクトを、前記クライアント側の１つまたは複数のオフスクリーン表示面の１つまたは複数の各々の位置に記憶されている１つまたは複数の対応するビットマップにマッピングするステップ
をさらに含むことを特徴とする請求項１に記載の方法。
【請求項６】
前記対応するビットマップ（単数または複数）の１つのビットマップは、前記ＧＵＩ部より小さく、少なくとも１つのサブセットのコマンドは、複数の簡易ビットマップ形式コマンドに変換され、前記方法は、
前記サーバーにより前記一部の異なる部分をレンダリングするための前記簡易ビットマップ形式コマンドの各々を前記クライアントに通信して、前記一部をレンダリングするステップ
をさらに含むことを特徴とする請求項１に記載の方法。
【請求項７】
前記サーバーにより、複数の異なるタイプのグラフィックオブジェクトを表すビットマップを、前記クライアント側のオフスクリーン表示面の各々の位置に書き込み／記憶するステップをさらに含むことを特徴とする請求項１に記載の方法。
【請求項８】
前記サーバーにより、前記クライアントが前記ユーザーに前記ＧＵＩを、前記クライアントにより提示することに関連付けられたオフスクリーン表示面を破壊する要求を通信するステップをさらに含むことを特徴とする請求項１に記載の方法。
【請求項９】
前記サーバーによりオフスクリーン表示面を割り当てるように前記クライアントに要求するステップと、
前記サーバーにより前記オフスクリーン表示面の特定の位置に、グラフィックオブジェクトを表すビットマップを記憶するように前記クライアントに要求するステップと、
前記サーバーにより前記オンスクリーン表示面の特定の位置（単数または複数）に１回または複数回前記ビットマップを書き込んで、前記ユーザーに前記ＧＵＩ部を提示するように前記クライアントに指示するステップと
をさらに含むことを特徴とする請求項１に記載の方法。
【請求項１０】
前記サーバーにより前記特定の位置に前記ビットマップを記憶するように前記クライアントに要求するステップにおいて、前記オフスクリーン表示面上で前記サーバーにより前に記憶されている異なるビットマップの少なくとも一部を上書きすることを特徴とする、請求項９に記載の方法。
【請求項１１】
ネットワーク１０４を介して、クライアント・コンピューティング・デバイス１０６（「クライアント」）に結合されるサーバー・コンピューティング・デバイス１０２（「サーバー」）を備えるシステム１００において、前記サーバーにより実装される方法であって、
前記サーバー上で実行するアプリケーション１１６からレンダリングに関連付けられたコマンド１４２をインターセプトするステップと、
前記コマンドの各コマンドを解析するステップと、
前記コマンドがレンダリング動作に関連付けられたグラフィックオブジェクトを作成または変更するためのものである場合、
（ａ）任意のクライアント側表示リモーティングキャッシュ管理および処理とは無関係に、前記クライアント１０６にグラフィックオブジェクトを表すビットマップ１４２を前記クライアント側のオフスクリーン表示面１３６上の指定位置に書き込ませるステップと、
（ｂ）前記オフスクリーン表示面と前記指定位置の指示と共にグラフィックオブジェクトをキャッシングするステップと、
前記レンダリングコマンドがグラフィックオブジェクトの使用を指定して、前記サーバー側のアプリケーションのＧＵＩ（グラフィカル・ユーザー・インターフェイス）の一部をレンダリングする場合、
（ｃ）連続的に、１回または複数回、クライアント側表示リモーティングキャッシュ管理および処理とは無関係に、前記ビットマップ１４２を、前記指定位置から前記クライアント側のオンスクリーン表示面１３６上の１つまたは複数の目標位置に転送して、ユーザーに前記一部を提示するように前記前記クライアントに指示するステップと
を含むことを特徴とする方法。
【請求項１２】
前記サーバーはＲＤＰサーバーであり、前記クライアントはＲＤＰクライアントであることを特徴とする請求項１１に記載の方法。
【請求項１３】
前記コマンドの内の１つのコマンドは、グラフィック・デバイス・インターフェイスに対するコールであることを特徴とする請求項１１に記載の方法。
【請求項１４】
前記クライアントは、スモール・フォーム・ファクター・デバイスであることを特徴とする請求項１１に記載の方法。
【請求項１５】
前記ビットマップは前記一部より小さく、前記１つまたは複数の目標位置の各々は前記ビットマップの転送されたビットの異なる位置を表し、かつ前記ビットマップの転送は、前記一部が完全にレンダリングされるまで前記ビットマップを前記一部の各部分にコピーするように前記クライアントに繰り返し指示するステップをさらに含むことを特徴とする請求項１１に記載の方法。
【請求項１６】
前記コマンドがグラフィックオブジェクトを削除するためのものである場合、前記アプリケーションからのレンダリングコールに関連付けられた異なるグラフィックオブジェクトに関連付けられた異なるビットマップをキャッシングするために、前記オフスクリーン表示面上の前記特定の位置を再使用するステップをさらに含むことを特徴とする請求項１１に記載の方法。
【請求項１７】
前記コマンドがグラフィックオブジェクトを削除するためのものである場合、前記オフスクリーン表示面の割り当てを解除するステップをさらに含むことを特徴とする請求項１１に記載の方法。
【請求項１８】
前記オフスクリーン表示面のサイズを判断するステップと、
前記オフスクリーン表示面を割り当てるステップと
をさらに含むことを特徴とする請求項１１に記載の方法。
【請求項１９】
前記オフスクリーン表示面の割り当ては、ＳＢＴＤＲＰの初期構成動作のセットの一部であることを特徴とする請求項１８に記載の方法。
【請求項２０】
分散処理システム１００におけるサーバー・コンピューティング・デバイス１０２（「サーバー」）とクライアント・コンピューティング・デバイス１０６（「クライアント」）との間の通信方法であって、
前記サーバーにより、オフスクリーン表示面にマッピングするための面サイズパラメータおよびサーバーが提供した一意の面ＩＤを含むＣｒｅａｔｅＳｕｒｆａｃｅコール１３２を発行して、オフスクリーン表示面１３６を割り当てるように前記クライアントに指示するステップと、
ＣｒｅａｔｅＳｕｒｆａｃｅコールの受信に応答して、任意のクライアント側キャッシュ管理動作とは無関係に、前記クライアントが前記面サイズに従って、前記オフスクリーン表示面を割り当てて、前記オフスクリーン表示面を前記サーバーが提供した一意の面ＩＤ１４２にマッピングするステップであって、前記オフスクリーン表示面は、
（ａ）グラフィックオブジェクトが前記サーバー側で前記サーバーによりビットマップ（単数または複数）、ブラシ（単数または複数）、フォント（単数または複数）、グリフ（単数または複数）およびフラグメント（単数または複数）のうちの１つまたは複数としてキャッシングされているか否かに関係なく、グラフィックオブジェクトを表すビットマップ１４２をサーバー指定の位置で記憶し、かつ
（ｂ）ビットマップセマンティクスを超えたセマンティクスの任意のクライアント側の判断および処理とは無関係に、１つまたは複数のビットマップを前記クライアント側の異なる表示面１３８上の各目標位置に転送して、前記サーバー上で実行するアプリケーション１１６のＧＵＩ（グラフィカル・ユーザー・インターフェイス）を提示するように前記クライアントに要求するために前記サーバーにより使用されるステップと、
前記サーバーにより、前記オフスクリーン表示面を識別するための特定の位置およびサーバーが提供した一意の面ＩＤを含むＳｅｔＳｕｒｆａｃｅＢｉｔｓコール１３２を前記クライアントに通信して、前記サーバー側および前記クライアント側で前記ＧＵＩをレンダリングするためのグラフィックオブジェクトを表すビットマップを、前記オフスクリーン表示面上の特定の位置に書き込むように前記クライアントに指示し、前記ＳｅｔＳｕｒｆａｃｅＢｉｔｓコールの受信に応答して、前記クライアントが前記ビットマップを前記オフスクリーン表示面上の前記特定の位置にコピーするステップであって、前記ビットマップのセマンティクスおよび意味は前記クライアントに対して任意であるステップと、
前記アプリケーションが前記サーバー側で前記ＧＵＩをレンダリングするためのレンダリングコマンドを発行するのに応答して、前記サーバーによりＴｒａｎｓｆｅｒＳｕｒｆａｃｅＢｉｔｓコマンド１３２を前記クライアントに送信して、前記オフスクリーン表示面から異なる表示面上の少なくとも１つの位置にビットマップを転送して、前記ユーザーに提示するための前記ＧＵＩの少なくとも一部をレンダリングするように前記クライアントに指示するステップであって、前記ＴｒａｎｓｆｅｒＳｕｒｆａｃｅＢｉｔｓコマンドのパラメータは、前記ビットマップのソース位置および異なる表示面上の目標位置を含むステップと
を含み、前記ＣｒｅａｔｅＳｕｒａｆｃｅコール、前記ＳｅｔＳｕｒｆａｃｅＢｉｔｓコール、前記ＴｒａｎｓｆｅｒＳｕｒｆａｃｅＢｉｔｓコマンド、および対応するクライアントの動作は、簡易ビットマップ転送形式表示リモーティングプロトコルの少なくとも一部を実装することを特徴とする方法。
【発明の詳細な説明】
【背景技術】
【０００１】
ＲＤＰ（Ｒｅｍｏｔｅ  Ｄｅｓｋｔｏｐ  Ｐｒｏｔｏｃｏｌ：リモートデスクトッププロトコル）は、ＴＳ（ｔｅｒｍｉｎａｌ  ｓｅｒｖｅｒ：端末サーバー）ベースのアプリケーションへのネットワーク接続を介して、リモート表示および入力機能を提供する。例えば、ＲＤＰは、サーバー上の自身のビデオドライバーを使用して、レンダリング情報をクライアントに対するネットワーク経由の通信のためのネットワークパケット内に構築することにより、アプリケーションの表示出力をクライアントデバイスにレンダリングする。このようなネットワークパケットを受信することに応答して、クライアントはレンダリング情報を、対応するＧＤＩ（Ｇｒａｐｈｉｃａｌ  Ｄｅｖｉｃｅ  ｉｎｔｅｒｆａｃｅ）ＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ  Ｐｒｏｇｒａｍｍｉｎｇ  Ｉｎｔｅｒｆａｃｅ）コールに復号化し、解釈する。（ＧＤＩは、典型的には、オペレーティングシステムの個々の部分と関連している。）このような復号化および解釈は、通常、クライアントが拡張インターフェイスであるＲＤＰを復号化するように構成されるだけでなく、受信したレンダリング情報を対応するＧＤＩコールにマッピングするように構成されることが必要である。このような動作には、典型的には、クライアントが複数の異なるデータのコンテキスト依存キャッシュを作成し、保持して、ＧＤＩベースのレンダリング動作においてフォント、ブラシ、グリフ、フラグメントなどのグラフィックオブジェクトを使用することが必要である。
【発明の概要】
【発明が解決しようとする課題】
【０００２】
これらのタスクは複雑であるため、ＲＤＰベースのクライアントの作成は、非常に時間がかかり、大きな労力を要する可能性がある。さらに、ＲＤＰベースのクライアントは、典型的には、そのような動作を実装するのにかなりの処理能力を持たなければならない。このような処理リソースは、通常、スモール・フォーム・ファクター・デバイスでは見られない。結果として、スモール・フォーム・ファクターは、典型的には、ＲＤＰベースのクライアントを実装するのに使用されない。
【課題を解決するための手段】
【０００３】
この概要は、以下の「発明を実施するための形態」でさらに説明する概念の選択を簡略化した形で紹介するものである。この概要は、請求される主題の重要な特徴または不可欠な特徴を特定するものではなく、請求される主題の範囲の決定を助けるものでもない。
【０００４】
前段落では、クライアント・コンピューティング・デバイス（「クライアント」）に結合されたサーバー・コンピューティング・デバイス（「サーバー」）によるビットマップ転送形式表示リモーティング（ｒｅｍｏｔｉｎｇ）を説明している。一態様では、サーバー側で実行するアプリケーションは、ＧＵＩの一部をレンダリングするための動作を実装する。サーバーは、対応するレンダリング形式のコマンド（単数または複数）（例えば、ＧＤＩコマンド）を簡単なビットマップ転送コマンドに変換する。サーバーは、ビットマップ転送コマンドをクライアントに送信する。例えば、１つの実装では、サーバーはＧＤＩコマンドを１つまたは複数のビットマップ操作動作（ｍａｎｉｐｕｌａｔｉｏｎ  ｏｐｅｒａｔｉｏｎ）コマンド（ラスター動作）に変換する。また、１つの実装では、サーバーはＧＤＩコマンドに従ってレンダリング動作を実装して動作結果（単数または複数）を得る。
【０００５】
サーバーは、動作結果（単数または複数）をビットマップ転送コマンド（単数または複数）のビットマップ（単数または複数）としてクライアントに送信する。クライアントは、サーバーからの受信したビットマップ転送コマンドに応答して、サーバーに指示されるように、オフスクリーンの表示面からオンスクリーンの表示面に、それぞれビットマップ（単数または複数）を記憶し、描画して、ユーザーにＧＵＩ部を提示する。このようにして、サーバーは、任意の従来のＲＤＰクライアント側のリモーティングロジック（例えば、キャッシュ管理、ビットマップのセマンティクスを超えたグラフィックオブジェクトのセマンティクスの判断および処理など）を使用せずに、またはそのようなロジックに依存せずに、ビットマップ転送コマンドのみを使用して、クライアントに指示してアプリケーションのＧＵＩをリモーティングさせる。このような管理、セマンティクスの判断および処理は、それぞれサーバー側でサーバーにより実装され、保持される。
【図面の簡単な説明】
【０００６】
図面および関連した説明で、コンポーネントの符番の最も左の桁はそのコンポーネントが最初に表示された特定の図面を示す。
【図１】一実施形態のビットマップ転送形式表示リモーティングの例示的なシステムを示す図である。
【図２】一実施形態のビットマップ転送形式表示リモーティング用のリモートクライアント側の例示的なサーバーが作成した、サーバーが目的とするオフスクリーン表示面を示す図である。
【図３】一実施形態のビットマップ転送形式表示リモーティングの例示的なプロシージャを示す図である。
【図４】一実施形態のビットマップ転送形式表示リモーティングの例示的なプロシージャを示す図である。
【図５】一実施形態のビットマップ転送形式表示リモーティングの別の例示的なプロシージャを示す図である。
【図６】一実施形態のビットマップ転送形式表示リモーティングの図５の例示的なプロシージャのさらに別の態様を示す図である。
【図７】一実施形態のビットマップ転送形式表示リモーティングの図５、６の例示的なプロシージャのさらに別の態様を示す図である。
【発明を実施するための形態】
【０００７】
概略
ビットマップ転送形式表示リモーティングのシステムおよび方法を説明する。このシステムおよび方法は、ＳＢＴＤＲＰ（ｓｉｍｐｌｅ  ｂｉｔｍａｐ  ｔｒａｎｓｆｅｒ−ｂａｓｅｄ  ｄｉｓｐｌａｙ  ｒｅｍｏｔｉｎｇ  ｐｒｏｔｏｃｏｌ：簡易ビットマップ転送形式表示リモーティングプロトコル）を使用して、従来型のＲＤＰの限界に対処するものである。ＳＢＴＤＲＰにより、アプリケーション（単数または複数）をホストするサーバーは、任意のビットマップ記憶およびクライアント側での記憶されたビットマップ表示を指示し、制御して、サーバー上で実行するアプリケーションのＧＵＩをクライアント上で提示できるようになる。この指示と制御により、サーバーはそれ以外にクライアント側で複雑なレンダリング動作やキャッシング動作になるものを、クライアント側で２つ以上の面で３方向または４方向のＲＯＰＳ（ｒａｓｔｅｒ  ｏｐｅｒａｔｉｏｎｓ：ラスター動作）に抽象化する。ＣＯＰＹ  ＲＯＰは、この動作の一例である。ところが、従来のＲＤＰは、この実装では、多数の異なるグラフィックオブジェクトのクライアント側のキャッシングをレンダリングロジックと緊密に結合し、サーバーのみが（例えば、サーバーによりリソースビットが記憶されている場所をクライアントへマッピングするために）キャッシュ管理ロジックを実装する。ＳＢＴＤＲＰのシステムおよび方法のこれらのおよび他の態様をより詳細に示す。
【０００８】
例示的なシステム
図１は、一実施形態のビットマップ転送形式表示リモーティングの例示的なシステム１００を示す図である。この実装では、図１は、例えば、ネットワーク１０４を介して１つまたは複数のクライアント・コンピューティング・デバイス１０６（「クライアント１０６」）に結合されるサーバー・コンピューティング・デバイス１０２（「サーバー１０２」）を含む。この実装では、サーバー１０２は、サーバー、ＰＣ（パーソナルコンピュータ）、ラップトップなどの任意の１つまたは複数の汎用コンピューティングデバイスを表す。クライアントデバイス１０６は、ＰＣ、ラップトップコンピュータ、モバイル・コンピューティング・デバイス、または汎用またはサーバー・コンピューティング・デバイスに比べて限られた処理機能やデータ記憶機能を有する任意のスモール・フォーム・ファクター・デバイス（例えば、ＰＤＡ（携帯端末）、モバイルデバイス、携帯電話など）の任意の１つまたは複数の汎用コンピューティングデバイスを表す。ネットワーク１０４は、オフィスで一般的な通信環境、企業規模のコンピュータネットワーク、イントラネット、およびインターネットなどのＬＡＮ（ｌｏｃａｌ  ａｒｅａ  ｎｅｔｗｏｒｋ）と一般的なＷＡＮ（ｗｉｄｅ  ａｒｅａ  ｎｅｔｗｏｒｋ）の通信環境との任意の組み合わせを表す。
【０００９】
各コンピューティングデバイス１０２、１０６は、それぞれエンコードされたコンピュータプログラムモジュールを備えるシステムメモリーに結合された１つまたは複数のプロセッサーを含む。コンピュータプログラムモジュールは、プロセッサー（単数または複数）の各々により実行可能な命令を含む。このようなシステムメモリーは、さらにプログラムモジュール実行時に、コンピュータプログラム命令の各々により生成され、および／または使用されるプログラムデータを含む。例えば、サーバー１０２は、揮発性ＲＡＭ（ｒａｎｄｏｍ  ａｃｃｅｓｓ  ｍｅｍｏｒｙ）や不揮発性ＲＯＭ（ｒｅａｄ  ｏｎｌｙ  ｍｅｍｏｒｙ）を示すシステムメモリー１１０に結合された１つまたは複数のプロセッサー１０８を含む。システムメモリー１１０は、プロセッサー（単数または複数）１０８により実行可能なコンピュータプログラム命令を備えるプログラムモジュール１１２を含む。システムメモリー１１２は、さらにプログラムモジュール実行時に、プログラムモジュール１１２の各々により生成され、および／または使用されるプログラムデータ１１４も含む。
【００１０】
この実装では、例えば、プログラムモジュール１１４は、端末サービスベースのアクセス用の１つまたは複数の任意のアプリケーション１１６（例えば、ワードプロセッサー、電子メールプログラム、スプレッドシートアプリケーションなど）、サーバー側端末サービス１１８、およびランタイム環境を提供するオペレーティングシステム、デバイスドライバー、ネットワーク通信ロジックなどの他のプログラムモジュール１２０を含む。この実装では、例えば、クライアント１０６側のコンピュータプログラムロジックは、クライアントベースの端末サービス１２２およびオペレーティングシステム、ドライバー、ネットワーク通信ロジックなどの他のプログラムモジュール１２４を含む。サーバーの端末サービス１１８およびクライアントの端末サービス１２２により、クライアント１０６のユーザーはネットワーク１０４を介して端末サービスセッションを確立して、サーバー１０２上で１つまたは複数の任意のアプリケーション１１６を起動して、ファイル、データベース、ネットワークリソースなどの任意の組み合わせにアクセスすることができる。実行アプリケーション（単数または複数）１１６は完全にサーバー１０２上で起動されるが、システム１００はＳＢＴＤＲＰ（ｓｉｍｐｌｅ  ｂｉｔｍａｐ  ｔｒａｎｓｆｅｒ−ｂａｓｅｄ  ｄｉｓｐｌａｙ  ｒｅｍｏｔｉｎｇ  ｐｒｏｔｏｃｏｌ：簡易ビットマップ転送形式表示リモーティングプロトコル）を実装して、ディスプレイ装置１３０を介して実行アプリケーション（単数または複数）１１６のＧＵＩの要素をエンドユーザーに提示する。
【００１１】
ＳＢＴＤＲＰ（簡易ビットマップ転送形式表示リモーティングプロトコル）
この実装では、例えば、ＳＢＴＤＲＰは、サーバー側端末サービス１１８の一部としてビットマップ転送形式表示リモーティングモジュール（またはロジック）１２６により、またクライアント側端末サービス１２２の一部としてクライアント側ビットマップ記憶・表示ロジック１２８により実装される。ＳＢＴＤＲＰにより、サーバー１０２のビットマップ転送形式表示リモーティングロジック１２６（「リモーティングロジック１２６」）は、クライアント１０６側で任意のビット記憶および記憶されたビット表示を指示し、制御して、サーバーがホストする実行アプリケーション（単数または複数）１１６の１つまたは複数のＧＵＩをユーザーに提示することができる。ＳＢＴＤＲＰは、クライアントが拡張ＲＤＰを実装するために複雑なキャッシングやレンダリングのロジックを実装する必要がある従来のＲＤＰベースの表示リモーティング動作を克服するものである。これを達成するために、ＳＢＴＤＲＰは、従来の複雑な表示リモーティングプロトコルを、クライアント１０６側のサーバーが目的とする（ｓｅｒｖｅｒ−ｐｕｒｐｏｓｅｄ）オフセットスクリーン表示面（単数または複数）に対する簡易サーバー制御ビットマップ転送（ラスター）動作に抽象化する。
【００１２】
この実装では、例えば、ＳＢＴＤＲＰは、以下の例示的なコマンド１３２（インターフェイスまたはコール）を含む。ＣｒｅａｔｅＳｕｒｆａｃｅ、ＳｅｔＳｕｒｆａｃｅＢｉｔｓ、ＴｒａｎｓｆｅｒＳｕｒｆａｃｅＢｉｔｓ、ＤｅｓｔｒｏｙＳｕｒｆａｃｅである。このコマンド１３２のセットは、それよりも多くても少なくてもよく、システム１００の特定の実装の機能とすることができる。さらに、例示的なコマンド１３２に付けられた特定の名前は一例であり、各コマンドのそれぞれの実装に関連付けられた動作それぞれを説明するように考えられている。したがって、これらのインターフェイスとそれらに関連する動作は、すぐ後で詳細に説明するが、異なる名前のインターフェイスで表すことができる。
【００１３】
ＣｒｅａｔｅＳｕｒｆａｃｅ（．．．）
ＣｒｅａｔｅＳｕｒｆａｃｅコマンド１３２はサーバー側リモーティングロジック１２６により発行されて、サーバーが目的とするビットマップ記憶のために特定のサイズのオフスクリーン表示面１３６をクライアント１０６に割り当てるようにクライアント側ロジック１２８に指示する。この実装では、例えば、ＣｒｅａｔｅＳｕｒｆａｃｅのパラメータは、クライアント側ロジック１２８が新規に作成されたオフスクリーン表示面１３６にマッピングするためのサーバーが提供した（ｓｅｒｖｅｒ−ｓｕｐｐｌｉｅｄ）一意のＩＤ（識別子）と面サイズとを含む。この実装では、面サイズはビットマップの幅、高さ、色の深み（例えば、１ピクセル当たり８、１６、２４、３２ビット）として表される。バイト数は、クライアント１０６およびサーバー１０２によりこれらの寸法から判断される（すなわち、バイト数は、１ピクセル当たりのバイトの幅、高さ、色の深みである）。可能な色の深みは、最初のプロトコル機能交換（ｉｎｉｔｉａｌ  ｐｒｏｔｏｃｏｌ  ｃａｐａｂｉｌｉｔｙ  ｅｘｃｈａｎｇｅ）で交渉（ｎｅｇｏｔｉａｔｅ）することができる。ＣｒｅａｔｅＳｕｒｆａｃｅコマンド１３２の受信に応答して、クライアント側ロジック１２８は、要求された表示面１３６を割り当てて、サーバーが提供した一意の面ＩＤを新規に割り当てられた表示面１３６にマッピングする。以下で説明するように、リモーティングロジック１２６はこのＩＤを利用して、次のコマンド１３２内のこの割り当てられた特定の面を参照する。
【００１４】
この実装では、例えば、従来のメッセージング技術を使用して、リモーティングロジック１２６は、クライアント１０６が任意のサーバーが目的とするビットをキャッシングするために利用することができる最大メモリー量を判断する。この判断に基づいて、リモーティングロジック１２６は、少なくとも１つのサブセットの最大メモリー量をオフスクリーン表示面１３６として割り当てるようにクライアント１０６に指示する。このシナリオでは、リモーティングロジック１２６は、サーバー１０２上で実行するアプリケーション１１６からのレンダリングコマンド／コールの検出および／またはマッピングとは無関係に、クライアント１０６にオフスクリーン表示面１３６を割り当てさせる。これが、従来のＲＤＰベースの実装と大きく異なる点である。
【００１５】
ＳｅｔＳｕｒｆａｃｅＢｉｔｓ（．．．）
サーバー側リモーティングロジック１２６は、ネットワーク１０４を介してＳｅｔＳｕｒｆａｃｅＢｉｔｓコマンド１３２をクライアント１０６に通信して、識別されたクライアント側オフスクリーン表示面１３６上の特定の目標位置（ｄｅｓｔｉｎａｔｉｏｎ  ｌｏｃａｔｉｏｎｓ）でビットセットを記憶するようにクライアント側ロジック１２８に指示する。この実装では、例えば、ＳｅｔＳｕｒｆａｃｅＢｉｔｓのパラメータは、オフスクリーン表示面１３６とビットセットとビットの目標位置とを識別する一意のＩＤを含む。１つの実装では、例えば、目標位置は、左、上、右、下の座標で表される矩形の座標を識別する。あるいは、記憶する矩形は、Ｘ、Ｙ、幅、高さを使用して識別される。別の実装では、目標位置は、矩形でない（例えば、正方形、円、任意の形状など）幾何学的オブジェクト（単数または複数）の座標を識別する。
【００１６】
ＳｅｔＳｕｒｆａｃｅＢｉｔｓコマンド１３２に応答して、クライアント側ロジック１２８は、指定されたオフスクリーン表示面１３６上の指示された目標位置（単数または複数）に対する指定ビットを記憶する。以下の段落００５６〜００５８で説明するように（また、図６を参照）、リモーティングロジック１２６により記憶されているビットセットが、次にレンダリングロジック１２６により使用される可能性があるグラフィックオブジェクトを描画するビットと一致して、サーバー１０２上で実行するアプリケーション１１６のＧＵＩの１つまたは複数の態様をレンダリングする。しかし、クライアント１０６から見れば、ビットマップのビットであることとは無関係に、これらの記憶されたビットの意味またはセマンティクスは重要ではなく、つまりビットマップが任意の意味を有し、ビットがサーバー１０２に指示されるようにクライアント側ロジック１２８によりオフスクリーン表示面１３６に記憶されているだけである。
【００１７】
ＴｒａｎｓｆｅｒＳｕｒｆａｃｅＢｉｔｓ（．．．）
リモーティングロジック１２６は、ＴｒａｎｓｆｅｒＳｕｒｆａｃｅＢｉｔｓコマンド１３２を使用して、ディスプレイ装置１３０を介してクライアント１０６により提示するために特定のクライアント側オフスクリーン表示面１３６内にキャッシングされている特定のビット（単数または複数）を異なる表示面（例えば、オンスクリーンのレンダリング面１３８、別のオフスクリーン面など）に転送するようにクライアント側ロジック１２８に指示する。この実装では、例えば、ＴｒａｎｓｆｅｒＳｕｒｆａｃｅＢｉｔｓのパラメータは、以下のうちの１つまたは複数を含む。
【００１８】
特定のオフスクリーン表示面１３６を識別する一意のソース面ＩＤ。
【００１９】
ターゲットビットマップの目標面（例えば、オンスクリーン表示面）を識別する目標面ＩＤ。
【００２０】
識別された目標面に転送するためにターゲットビットマップを表すビットセットを識別するソース矩形（または他の任意の形状）。
【００２１】
転送されたビットマップを受信するための目標面における目標矩形（またはクリッピング領域などの他の任意の形状）。１つの実装では、ＴｒａｎｓｆｅｒＳｕｒｆａｃｅＢｉｔｓコマンド１３２は、更新のためのクリッピング領域（ｃｌｉｐｐｉｎｇ  ｒｅｇｉｏｎ）（目標面の不規則なエリアを画定する矩形セット）を含む。
【００２２】
マスクビットマップ（または面）。例えば、ＭａｓｋＢｌｔはビットマップ転送動作であり、この動作により、マスク内の対応ピクセルの値に基づいて選択的にピクセルがソース面から目標面に転送される。例えば、マスクビットマップの１００，１００の座標のピクセルが０（黒）に設定された場合のみ、１００，１００の座標のピクセルがソース面から目標面まで転送される。
【００２３】
クライアントロジック１２８がソース面から目標面へビットマップ転送を実装するためのラスター動作（すなわち、コピー、ｘｏｒなど）の指示。１つの実装では、例えば、ＴｒａｎｓｆｅｒＳｕｒｆａｃｅＢｉｔｓコマンド１３２は、クライアントロジック１２８にマスク面動作を実装するように指示する。
【００２４】
１つの実装では、クライアント側ロジック１２８によるビットマップ転送の失敗により、クライアントロジック１２８は一般的な「ダーティ（ｄｉｒｔｙ）」面の通知１３４をリモーティングロジック１２６に通信して、リモーティングロジック１２６にその面のビットが有効でないことを通知する。１つの実装では、この通知に応答して、サーバー１０２は、無効の面のビット／領域のためにクライアントロジック１２８に更新版を送信する（更新版により、その領域が有効になる）。
【００２５】
ＤｅｓｔｒｏｙＳｕｒｆａｃｅ（．．．）
リモーティングロジック１２６は、ＤｅｓｔｒｏｙＳｕｒｆａｃｅコマンド１３２を送信して、サーバー１０２が開始し、目的とするオフスクリーン表示面１３６を破壊（再割り当て）するようにクライアントロジック１２８に指示する。この実装では、ＤｅｌｅｔｅＳｕｒｆａｃｅのパラメータは、例えば、特定のオフスクリーン表示面１３６に対する一意の面ＩＤを含む。
【００２６】
例示的なサーバーが目的とするビットマップ記憶及び転送  
以下の実施例は、ＴＳベースのサーバー上で実行するアプリケーションのＧＵＩの要素をＴＳベースのクライアント上で表示する従来のＲＤＰの使用を、ＳＢＴＤＲＰの使用と比較対照したものである。これらの実施例は一例であり、これらの実施例の範囲から逸脱せずに、他の動作の順序、グラフィックオブジェクト、面などに置き換えることができる。
【００２７】
従来のＲＤＰベースのロジックを使用する場合、以下の動作は、典型的には、特定の位置にブラシオブジェクトをキャッシングし、ブラシオブジェクトを使用して、主要なオンスクリーン表示面の矩形を埋めなければならない。例示するために、そのブラシは１６×１６ピクセルブラシで、オンスクリーン表示面のレンダリング位置は（０，０，６４，１６）であり、面のエリアの表示はこのような複数のブラシをカプセル化している。
【００２８】
サーバー（「Ｓ」）とクライアント（「Ｃ」）との間で初期プロトコル交換の一部として、キャッシュタイプ（例えば、ブラシ、グリフ、フォント、フラグメント、ビットマップなど）およびサイズを交渉することで、クライアントはキャッシュ管理動作をグラフィックオブジェクトレンダリング動作と緊密に結びつけた複雑なキャッシュ管理サービスを設定することができる。この実施例では、キャッシュタイプはブラシキャッシュである。キャッシュサイズは、例えば、１００エントリを有する１６（幅）×１６（高さ）キャッシュ、２００エントリを有する４２×３２キャッシュなどを含む。
【００２９】
サーバーは、ブラシ用のビットマップビットおよび原点を取得し、ブラシキャッシュ内のある指定された位置（例えば、位置９９）でキャッシングするためにこれらをクライアントに送信する。
【００３０】
サーバーは、ブラシキャッシュ位置９９内のブラシを使用して、オンスクリーン表示面の（０，０，６４，１６）における面の矩形を埋めるようにクライアントに命令する。クライアントは、ＲＤＰコマンドをキャッシュされたブラシを使用する対応ＧＤＩコールに変換することでこれに応答する。クライアントはＧＤＩコールをクライアントのオペレーティングシステムに提出（ｓｕｂｍｉｔ）して、指示されたようにブラシを描画する。面の矩形サイズがブラシ（１６×１６）のサイズであれば、クライアント側のＧＤＩは複数のブラシレンダリングコマンドを繰り返し実行して、面の矩形を埋めることになる。
【００３１】
上述の実施例とは対照的に、図１のシステム１００は、ＳＢＴＤＲＰを利用して、クライアント側のオフスクリーン表示面のブラシのビットマップおよび複数のサーバー開始のビットマップコピーコマンド（１回に１コマンドを連続的に）を記憶して、クライアント１０６側のオンスクリーン表示面の矩形を埋める。したがって、サーバーはアプリケーション１１６からのより複雑なレンダリングコマンド（例えば、ＧＤＩコマンド）をより簡易なビットマップ転送コマンドに分解する、または分割する。このコンテキストにおいてキャッシングと記憶との違いの１つは、ＲＤＰを使用してクライアント側でオブジェクトをキャッシングするためには、ＲＤＰベースのクライアントがキャッシュ管理ロジックに、キャッシング動作の実行およびオブジェクト転送の実行を要求する点である。一方、クライアント１０２におけるビットマップ記憶およびビットマップ転送は、クライアント１０２のいずれのキャッシュ管理とは全く無関係である。
【００３２】
例示し比較するために、ブラシサイズは１６×１６ビットであり、クライアント１０６側のオンスクリーン表示面（例えば、「面０」）における面の矩形の座標は（０，０，６４，１６）である。直前の実施例にあるように、ターゲット面の矩形を埋めるのは複数のレンダリング動作が必要であるだろう。前の実施例では、クライアントはＧＤＩを使用してサーバーコマンドを複数のレンダリング動作に変換し、面の矩形を埋めている。一方、サーバー１０２は、複数の面ビット転送コマンドをクライアント１０２に繰り返し通信して、例示的なレンダリング動作を実行している。
【００３３】
リモーティングロジック１２６とクライアント側ロジック１２８とが交渉して、オフスクリーン表示面１３６を（例えば、初期プロトコル動作の一部として）割り当てる。例示するために、このようなオフスクリーン表示面を図２に示す。
【００３４】
リモーティングロジック１２６は、クライアント１０６に、サーバーが提供した（およびサーバーが保持した）一意の識別子（例えば、ＩＤ８８）にマッピングされたオフクスリーン面１３６を作成するように命令する。１つの実装では、オフスクリーン面は少なくとも１６×１６である。
【００３５】
リモーティングロジック１２６は、面ＩＤ８８の位置（０，０，１６，１６）のビットマップビットを（ＳｅｔＳｕｒｆａｃｅＢｉｔｓコマンド１３２を使用して）ブラシオブジェクトを表す特定のビットマップビットに設定するようにクライアント１０６に命令する。
【００３６】
リモーティングロジック１２６は、位置（０，０，１６，１６）の面ＩＤ８８から（ＴｒａｎｓｆｅｒＳｕｒｆａｃｅＢｉｔｓコマンド１３２を使用して）ビットを位置（０，０，１６，１６）の面０に転送するようにクライアント１０６に命令する。
【００３７】
リモーティングロジック１２６は、ビットを位置（０，０，１６，１６）のオフスクリーン表示面ＩＤ８８から位置（１６，０，４２，１６）の面０に転送するようにクライアント１０６に命令する。
【００３８】
リモーティングロジック１２６は、ビットを位置（０，０，１６，１６）のオフスクリーン表示面ＩＤ８８から位置（３２，０，５８，１６）の面０に転送するようにクライアント１０６に命令する。
【００３９】
リモーティングロジック１２６は、ビットを位置（０，０，１６，１６）の面８８から位置（４８，０，６４，１６）の面０に転送するようにクライアント１０６に命令する。
【００４０】
ＳＢＴＤＲＰを使用する前述の実施例では、リモーティングロジック１２６は面ビット転送コマンド１３２を繰り返し（この例では、４回）実装して、指定された目標矩形を指定されたブラシビットマップで埋めることに留意されたい。従来のシステムとは対照的に、システム１００により実装される簡易プロトコルは、ビットマップブラシ処理（およびサーバー１０２で実行するアプリケーション１１６からＧＵＩを、リモートクライアント１０６に結合されたディスプレイ装置１３２上に表示するために利用される他の動作）のために、簡易ＳＢＴＤＲＰコマンドを使用する。その結果、クライアント１０６は、簡易ビットマップ／面の読み出しおよび書き込み操作を実装して、サーバー１０２で実行するアプリケーション１１６に関連付けられたＧＵＩのそれぞれの部分をレンダリングする構成となる。すなわち、サーバー１０２は複雑なグラフィックレンダリングコマンド（例えば、ＦｉｌｌＲｅｃｔ  ＧＤＩコマンド）を個々の対応するビットマップラスター動作コマンドに分割する。これは、従来のＲＤＰシステムとは対照的な点であり、クライアントは、複数の異なるグラフィックオブジェクト固有のキャッシュを保持し、種々のグラフィックオブジェクト（グリフ、ブラシ、ビットマップなど）間のセマンティクスの差を理解し、頻繁に（例えば、ブラシキャッシュからのブラシで矩形を埋めるために）ＲＤＰレンダリングコマンドを対応するＧＤＩコマンドに変換するように構成される。
【００４１】
例示的なプロシージャ
図３は、一実施形態のビットマップ転送形式表示リモーティングの例示的なプロシージャを示す図である。例示し説明するために、プロシージャ３００の動作は図１の態様およびコンポーネントに関して説明する。説明では、コンポーネントの符番の最も左の数字はそのコンポーネントが最初に紹介された特定の図面を示している。図３を参照すると、ブロック３０２の動作は、サーバーリモーティングモジュール１２６（図１）により、サーバー１０２で実行するアプリケーション１１６がアプリケーションのＧＵＩの一部をレンダリングする動作に関与すると判断する。この動作は、例えば、ＧＵＩをレンダリングするのに次に使用するためのブラシ、グリフ、フォント、フラグメントなどのグラフィックオブジェクトの作成を含む。別の実施例では、この動作は、ブラシで埋め込みコマンドなどの実際のレンダリングコマンドを含む。ブロック３０４の動作は、動作に関連付けられたコマンド（例えば、ブロック３０２参照）を対応するビットマップラスター動作コマンドに分解する、または分割する。
【００４２】
例えば、上述したように、アプリケーション１１６がＧＤＩコマンドを生成してブラシのグラフィックオブジェクトを作成する場合、サーバーリモーティングロジック１２６は、ビットマップをクライアント１０６の特定のオフスクリーン表示面１３６に書き込む。別の実施例では、アプリケーション１１６がブラシのグラフィックオブジェクトを利用してＧＵＩの一部に書き込む場合、サーバーリモーティングロジック１２６は、（１回または数回）ブラシに対応するビットマップをオンスクリーン表示面１３８の特定の部分に転送して、ユーザーにＧＵＩ部を提示するようにクライアント１０６に指示する。この転送動作は、ビットマップ読み出し及び書き込み動作を含む。
【００４３】
ブロック３０６の動作は、ビットマップラスター動作コマンド（ブロック３０４の動作を参照）をクライアント１０６に送信する。ブロック３０８の動作は、クライアント１０６により、受信されたビットマップラスター動作コマンドを復号化して、オンスクリーン表示面１３８に対応するビットマップを記憶／または描画して、ユーザーにＧＵＩ部を提示する。１つの実装では、コマンドは、ビットマップ（単数または複数）をオンスクリーン面に転送する前に１つのオフスクリーン面から別のオフスクリーン面にビットマップ（単数または複数）を転送するようにクライアント１０６に指示してもよい。ビットマップを記憶し、描画してＧＵＩ部を提示するためのクライアント１０６側のロジックは、クライアント実装のキャッシュ管理ロジックとは全く無関係である。さらに、クライアントロジックは、ビットマップのセマンティクスを超えたグラフィックオブジェクトのセマンティクスの任意の判断や処理とは全く無関係である。これが、従来のＲＤＰ動作とは対照的な点である。
【００４４】
図４は、一実施形態のビットマップ転送形式表示リモーティングの例示的なプロシージャを示す図である。例示し説明するために、プロシージャ４００の動作は、図１の態様およびコンポーネントに関して説明する。説明では、コンポーネントの符番の最も左の数字はそのコンポーネントが最初に紹介された特定の図面を示している。図４を参照すると、ブロック４０２動作は、サーバーにより、サーバーが指示し（ｄｉｒｅｃｔｅｄ）かつ目的とするデータ記憶のためにオフスクリーン表示面を割り当てるようにクライアントに指示する。１つの実装では、サーバー１０２側のリモーティングロジック１２６は、ＣｒｅａｔｅＳｕｒｆａｃｅコマンド１３２を使用して、このようなサーバーが指示し、サーバーが目的とするデータ記憶のためにオフスクリーン表示面１３６を割り当てるようにクライアント１０６のクライアント側ロジック１２８に指示する。このサーバーが指示し、サーバーが目的とするデータ記憶とは、サーバー１０２で実行するアプリケーション１１５のＧＵＩを（例えば、ディスプレイ装置１３０を使用して）クライアント１０６のユーザーに提示することである。
【００４５】
ブロック４０４の動作は、サーバーにより、特定の位置に対するビットマップをオフスクリーン表示面上に記憶するようにクライアントに要求する。１つの実装では、例えば、この動作は、ＧＤＩまたは他のグラフィックインターフェイスを要求するアプリケーションに応答して行われ、グラフィックオブジェクト（例えば、ブラシ、グリフ、ビットマップ、フォントなど）を作成または変更してサーバー上にＧＵＩをレンダリングする。１つの実装では、レンダリングロジック１２６はアプリケーション１１６からＧＤＩへのコールをインターセプトする。別の実装では、例えば、この動作は、ＧＤＩに対する要求とは無関係に実行される。例えば、この動作は、ＧＤＩ出力（例えば、黒い矩形など）以外のものなどを表示するように要求されるクライアントに応答して実行される。このコールがＧＵＩをレンダリングするためのグラフィックオブジェクトの作成または変更に関連付けられる場合、レンダリングロジック１２６は、割り当てられたオフスクリーン表示面１３６上の特定の位置にグラフィックオブジェクトを表す任意のビットマップを記憶するようにクライアント側ロジックに要求する。この要求は、例えば、ＳｅｔＳｕｒｆａｃｅＢｉｔｓコマンド１３２をクライアント側ロジック１２８に通信するレンダリングロジック１２６により行われる。
【００４６】
ブロック４０６の動作は、サーバーがアプリケーションからのレンダリングコマンドをインターセプトすることに応答して行われる。ここで、レンダリングコマンドは、前に作成されたグラフィックオブジェクト（例えば、ブラシ、グリフなど）に関連付けられる。（特定のアプリケーションからレンダリングコマンドをインターセプトするのに、ミラードライバーなどの技術が既知である。）具体的には、ブロック４０６の動作は、サーバーにコマンドをクライアントに対して送信させて、オフスクリーン表示面からクライアント側表示面上の少なくとも１つの位置に、前に作成されたグラフィックオブジェクトに対応するビットマップを転送するようにクライアントに指示する。これらの動作は、クライアントのユーザーに提示するためのＧＵＩの一部をレンダリングすることになる。１つの実装では、例えば、ブロック４０６の動作は、ＴｒａｎｓｆｅｒＳｕｒｆａｃｅＢｉｔｓコマンド１３２をクライアント側ロジック１２８に通信するレンダリングロジック１２６により実装される。クライアント側ロジック１２８によりこのコマンドが受信されることで、クライアント側ロジック１２８はサーバーが指定したビットマップを異なる表示面（例えば、オンスクリーンレンダリング面１３８）の目標位置に転送する。クライアント側ロジック１２８によるこれら任意のビットマップの転送動作は、サーバー１０２上で実行するアプリケーション１１６のＧＵＩの一部となり、クライアント１０６のユーザーに提示される。ビットマップ転送形式表示リモーティングのこれらのさらに詳細な例示的なプロシージャを、図４〜図７に関してより詳細に説明する。
【００４７】
図５は、一実施形態のビットマップ転送形式表示リモーティングでリモートクライアントデバイスにおいてオフスクリーン表示面を作成するための別の例示的なプロシージャ５００を示す図である。例示し説明するために、プロシージャ５００の動作を図１の態様およびコンポーネントに関して説明する。説明では、コンポーネントの符番の最も左の数字は、そのコンポーネントが最初に紹介された特定の図面を示している。
【００４８】
図５では、ブロック５０２の動作は、サーバーによりクライアントに、サーバーが指示し、サーバーが目的とするビットマップ記憶動作に特定のサイズのオフスクリーン表示面を割り当てるように指示する。この指示は、要求された面がビットマップまたは任意の他のデータ記憶に使用されることになることをクライアント１０２に示す情報を全く含まない。１つの実装では、例えばサーバー１０２のリモーティングロジック１２６は、クライアント１０６がオフスクリーン表示面１３６に割り当てることができるサイズ（例えば、最大サイズ、デフォルトサイズ、またはそれ以外のサイズ）を示すようにクライアント側ロジック１２８に要求する。サイズの判断に応答して、リモーティングロジック１２６はＣｒｅａｔｅＳｕｒｆａｃｅコマンド１３２をクライアント１０６に送信する。ＣｒｅａｔｅＳｕｒｆａｃｅコマンド１３２は、指示されたサイズのオフスクリーン表示面１３６を割り当てるようにクライアント側ロジック１２８に指示する。この通信は、さらに新規に割り当てられたオフスクリーン表示面１３６に関連付けるために、クライアント側ロジック１２８のためのサーバーが提供した一意のＩＤを含む。以下で示すように、リモーティングロジック１２６は、この特定のオフスクリーン表示面１３６に関連付けられたビットマップ形式の動作を実行するようにクライアント側ロジック１２８に指示するときに、この一意のＩＤを使用することになる。１つの実装では、ブロック５０２の動作は、リモーティングロジック１２６およびクライアント側ロジック１２８により初期プロトコル構成動作の一部として実装される。ブロック５０４の動作は、オフスクリーン表示面１３６を作成するコマンド１３２を（クライアント１０６により）受信することに応答して、クライアント１０６は特定の指定されたサイズまたはデフォルトサイズのオフスクリーン表示面１３６を割り当てる。
【００４９】
ブロック５０６の動作は、レンダリングコマンド（例えば、ＧＤＩに対するコール）をインターセプトして、実行端末サービスベースのアプリケーションのＧＵＩを提示する。１つの実装では、例えば、リモーティングロジック１２６は従来のドライバーを利用して、実行アプリケーション１１６から（例えば、ＧＤＩロジックなどに）レンダリングコールをインターセプトして、実行アプリケーション１１６に関連付けられたＧＵＩを提示する。ブロック５０８の動作は、インターセプトされたレンダリングコマンド（またはレンダリング関連コマンド）がグラフィックオブジェクト（例えば、ブラシ、グリフ、フラグメント、ビットマップ、フォントなど）を作成または変更するコマンド（削除／破壊（ｄｅｓｔｒｏｙ）コマンドを含む）であるか否か、またはインターセプトされたレンダリングコマンドが、特定のグラフィックオブジェクトを使用してレンダリング動作（例えば、埋め込みコマンド、描画コマンドなど）を実行するコマンドであるか否かを判断する。１つの実装では、リモーティングロジック１２８は、既知のレンダリングコマンド解析技術（例えば、ＧＤＩコマンド解析技術など）を使用してコマンドを解析することにより、この判断を行う。ブロック５１０で、インターセプトされたレンダリングコマンド／コールが既存のグラフィックオブジェクトを作成または変更するためのものである場合、プロシージャ５００の動作は、ページ上の「Ａ」で示されるように、図６のブロック６０２で継続する。それ以外に、インターセプトされたレンダリングコールが特定のグラフィックオブジェクトを利用してレンダリング動作を実装するためのものである場合、プロシージャ５００の動作は、ページ上の「Ｂ」で示されるように、図７のブロック７０２で継続する。１つの実装では、ブロック５１０の動作は、サーバー１０２のリモーティングロジック１２６により実装される。
【００５０】
図６は、一実施形態のビットマップ転送形式表示リモーティングの例示的なプロシージャのさらなる態様を示す図である。具体的に、図６は図５のプロシージャ５００の続きである。図６を参照すると、動作はページの「Ａ」で示されるように、ブロック６０２で始まる。ブロック６０２の動作は、インターセプトされたレンダリングコマンドが既存のグラフィックオブジェクトを作成または変更するためのものであるとの前の判断（図５のブロック５１０参照）に応答して実装される。ブロック６０２では、サーバーは、特定のオフスクリーン表示面の特定の位置でキャッシングするために、作成されたまたは変更されたグラフィックオブジェクトを表すビットをクライアントに通信する。１つの実装では、リモーティングロジック１２６は、ＳｅｔＳｕｒｆａｃｅＢｉｔｓコマンド１３２を使用して、サーバーが識別したオフスクリーン表示面１３６上のサーバー指定の位置で、クライアント側ロジック１２８によりキャッシングするために、作成されたまたは変更されたグラフィックオブジェクトを表すビットをクライアント側ロジック１２８に通信する。例示のために、このビットは、図１の「他のプログラムデータ」１４２の各部分として示す。
【００５１】
１つの実装では、例えば、ＳｅｔＳｕｒｆａｃｅＢｉｔｓコマンド１３２内の作成された、または変更されたグラフィックオブジェクトビットは、例えば、ビットマップサイズ、色、圧縮などを示している。これらのビットをクライアント１０６に送信する動作は、対応するビット定義またはビットのコンテキストの任意の指示をクライアント１０６に送信することとは全く無関係である。さらに、ＳｅｔＳｕｒｆａｃｅＢｉｔｓコマンド１３２内で指定された特定のオフスクリーン表示面１３６は、リモーティングロジック１２６が一意のＩＤで識別する面１３６である。この実装では、面１３６がＣｒｅａｔｅＳｕｒｆａｃｅコマンド１３２を使用して作成されたときに、リモーティングロジック１２６がこの一意のＩＤをクライアント側ロジック１２８に提供したのを思い出されたい。
【００５２】
ブロック６０４の動作は、面ビット設定コマンドの受信に応答して、面ビット設定コマンドに関連付けられた任意の（クライアント１０６およびクライアント側ロジック１２８から見て任意の）ビットを指定されたオフスクリーン表示面に記憶する。１つの実装では、例えば、クライアント側ロジック１２８は、ＳｅｔＳｕｒｆａｃｅＢｉｔｓコマンド１３２の受信に応答して、関連付けられた任意のビットを指定されたオフスクリーン表示面１３６に、面１３６上のサーバー指定の位置で記憶する。このシナリオでは、クライアント１０６は、通信されたビットはビットマップを表し、ＳｅｔＳｕｒｆａｃｅＢｉｔｓコマンド１３２は対応するビットマップのコピーまたは転送の動作を要求することを理解するように構成される。これ以外に、クライアント１０６の構成は、ＳｅｔＳｕｒｆａｃｅＢｉｔｓコマンド１３２で通信されたビットの定義、コンテキスト、セマンティクスなどを判断する必要が全くない。クライアント１０６から見れば、受信されたビットは、単にリモーティングロジック１２６によりクライアント１０６側で記憶されているセマンティクスが未知の任意のビットマップを表す。したがって、クライアント１０６は、任意のグラフィックオブジェクトベースのセマンティックの判断とは無関係に、受信したビットをキャッシングする。グラフィックオブジェクトベースのセマンティックの判断の例として、例えば、受信したビットはあるタイプのグラフィックオブジェクトを表しているか、そうであった場合、グラフィックオブジェクトのタイプは何かなどの質問に対する回答を判断するロジックを含む。例えば、ビットはブラシ、ビットマップ、グリフ、フラグメントなどを表すかである。従来のＲＤＰクライアントの実装は、グラフィックオブジェクトの判断されたタイプに基づいて特別な処理を実行する。
【００５３】
図７は、一実施形態のビットマップ転送形式表示リモーティングの例示的なプロシージャ５００のさらなる態様を示す図である。具体的には、図７は、図５および図６のプロシージャ５００の続きである（図５のページの「Ｂ」を参照）。図７を参照すると、動作は、インターセプトされたコールが既存のグラフィックオブジェクトを作成または変更するためのレンダリングコールでないとの前の判断（図５のブロック５１０を参照）に応答して、ブロック７０２で始まる。したがって、インターセプトされたコールは、既存のグラフィックオブジェクトまたはレンダリングコマンドを削除するためのものであったことになる。
【００５４】
ブロック７０２の動作は、インターセプトされたコールがグラフィックオブジェクトを削除するためのコールであったか否かを判断する。そうであった場合、動作はブロック７０４で継続し、サーバーがクライアント側スクリーン表示面でビットを保持する必要があるか否かが判断される。この判断は任意であり、サーバー側のリモーティングロジック１２６の特定の実装に基づくものである。例えば、１つの実装では、サーバー側のリモーティングロジックはローカルキャッシュ１４２を評価して、コールで識別されたグラフィックオブジェクトに関連付けられたクライアント側オフスクリーン表示面１３６が、まだ有効であるか否かを判断する。この判断は、サーバー側のリモーティングロジック１２６の特定の実装に基づいた多くの異なる任意のパラメータに基づいて行われる。
【００５５】
例えば、コールによりサーバー側での削除のためにスケジュールされたグラフィックオブジェクトが、クライアント側オンスクリーン表示面１３６内にキャッシングされた対応ビットを有する唯一のオブジェクトである場合、リモーティングロジック１２６は対応ビットを次にキャッシングされる任意のビットで上書きすることを決めてもよいし、または面１３６を削除するようにクライアント側ロジック１２８に要求してもよい。別の実施例では、リモーティングロジック１２６は１つまたは複数のオフスクリーン面１３６を利用して、ブラシをキャッシングすることを考慮する。ブラシがＧＤＩを使用してサーバー１０２側で削除される場合、リモーティングロジック１２６は、クライアント１０６の面でキャッシングされた対応ビットマップが占めるエリアを再び使用するように意図することを判断してもよい（すなわち、面ビットは他の何かに使用することができる）。クライアント側のブラシビットのエリアは、前述の実施例で示したように、１ブラシにつき１つの面として、または同一面１３６のブラシを表す複数のビットマップとして管理することができることに留意されたい。したがって、１つの実装では、リモーティングロジック１２６は、面１３６を削除することはできないが、関連する面ビットの少なくとも一部を再び使用するように意図することのみ可能である。
【００５６】
上述の例を見ると、面１３６の削除が指示された場合、ブロック７０４の動作は、リモーティングロジック１２６に、特定のオフスクリーン表示面１３６を削除するようにクライアント側ロジック１２８に指示するＤｅｌｅｔｅＳｕｒｆａｃｅコマンド１３２を通信させる。このコマンド１３２の受信に応答して、クライアント側ロジックは識別されたオフスクリーン表示面１３６の割り当てを解除する（破壊する）。
【００５７】
ブロック７０２の動作が、インターセプトされたコールがグラフィックオブジェクトを削除するためのコールでなかった場合、コールはレンダリング動作（例えば、描画コマンド、埋め込みコマンド）を実装するために、特定のグラフィックオブジェクトの使用に関連付けられる。したがって、プロシージャ５００の動作は、ブロック７０６で動作を継続する。ブロック７０６では、サーバーは１つまたは複数の面ビット転送コマンドをクライアントに送信して、ビットを特定のオフスクリーン表示面からフレームディスプレイバッファ内の位置にコピーし、インターセプトされたＧＤＩレンダリングコマンドのクライアント側での有効な結果をもたらす。１つの実装では、例えば、レンダリングロジック１２６は、１つまたは複数のＴｒａｎｓｆｅｒＳｕｒｆａｃｅＢｉｔｓコマンド１３２をクライアント側ロジック１２８に送信して、特定の表示面１３６からフレームディスプレイバッファ内の位置にビットをコピーし、インターセプトされたレンダリングコマンドのクライアント１０６側での有効な結果をもたらす。コピーされる特定のビットは、レンダリングロジック１２６により特定のオフスクリーン表示面１３６に、前にキャッシングされたビットを表す。１つの実装では、リモーティングロジック１２６は、サーバー側キャッシュ１４０を使用して、サーバー１０２側のグラフィックオブジェクトを特定のクライアント側オンスクリーン表示面１３６（一意の面ＩＤを使用して）、および面１３６の対応するソース位置にマッピングする。
【００５８】
結論
これまでの段落で、ビットマップ転送形式表示リモーティングを構造的特徴および／または方法動作もしくはアクションに固有の言葉で説明したが、添付の請求項で定義された実装は必ずしも説明した固有の特徴またはアクションに限定されない。例えば、プロシージャ５００の動作（図５、図６参照）は、特定のフローおよび順序で示したが、これらの動作は一例であって、システム１００の一例および例示的な実装を例示したに過ぎない。例えば、クライアント側オフスクリーン表示面１３６を作成する動作は、プロシージャ５００のブロック５０２に関して説明したが、リモーティングロジック１２６はその特定の実装当たりの数と同じ数のオフスクリーン表示面１３６を作成することができる。例えば、ブロック５０６の動作の後、レンダリングに関するコールがインターセプトされ、（ブロック５０２およぶ５０４で説明したように）レンダリングロジック１２６の別の実装が、別のオフスクリーン表示面１３６を作成して、対応するグラフィックオブジェクトのビットをキャッシングすることができる。このことから見て、プロシージャ４００および５００は、システム１００の特定の実装で行われる多くの異なる任意の動作フローの例である。したがって、上述したビットマップ転送形式表示リモーティングの固有の特徴および動作は、請求される主題を実装するための例示的な形態である。
【図１】
2010529537.tif 000003
【図２】
2010529537.tif 000004
【図３】
2010529537.tif 000005
【図４】
2010529537.tif 000006
【図５】
2010529537.tif 000007
【図６】
2010529537.tif 000008
【図７】
2010529537.tif 000009
【国際調査報告】
2010529537.tif 000010
2010529537.tif 000011