JP5123186B2 - 任意のフォーマットにおけるラージオブジェクトの通信のためのリモートプロトコルサポート - Google Patents

Description

本発明は、任意のフォーマットにおけるラージオブジェクトの通信のためのリモートプロトコルサポートに関する。

アプリケーションプログラム、またはアプリケーションは、グラフィックイメージを作成し、提供することができる。グラフィックイメージは、他のアプリケーションに移すことができるビットマップによって表すことができる。グラフィックイメージは、複雑性またはサイズにおいて変化することができるので、グラフィックイメージを表すビットマップもまた、複雑性またはサイズにおいて変化することができる。

サーバーコンピュータが１または複数のクライアントコンピュータをサポートする、サーバーおよびリモートクライアントシステムにおいて、サーバーコンピュータからのビットマップは、より小さなピースに分解し、クライアントコンピュータと通信することができる。クライアントコンピュータは、それぞれのより小さなビットマップのピースを個々にディスプレイし、または処理することができる。言い換えると、より大きなグラフィックイメージをディスプレイするために、それぞれのより小さなビットマップのピースを処理する。高速で変換または更新する比較的大きなサイズのビットマップにとっての問題は、クライアントコンピュータで見られる切り離し効果である。切り離し効果は、クライアントコンピュータが各ビットマップのピースをディスプレイするように起こる。

ビットマップが、クライアントコンピュータに一度に（すなわち、より小さなピースに分解されずに）送信されると、クライアントコンピュータは、どのようにビットマップをディスプレイすることができるかを、クライアントコンピュータで見られる固有の制約（例えば、高速更新）を与えて決めることができるが、ビットマップがその全体で送られると、ビットマップは圧縮されなければならないかもしれない。圧縮は、典型的には、比較的大きいサイズのビットマップのサポートに用いられる。サーバーコンピュータで稼動しているアプリケーションは、特定の圧縮フォーマットに基づいてビットマップを圧縮することができる。圧縮フォーマットは、損失をともなうものであるかもしれない、つまりビットマップ（すなわち、グラフィックイメージ）が圧縮されると、何らかの情報またはデータが落ちるか、失われることを意味する。

ビットマップは、ＲＤＰ（Remote Desktop Protocol）などの特定の通信プロトコルを用いて、クライアントコンピュータに通信し、伝送することができる。典型的に、通信プロトコルが用いられると、圧縮されたビットマップは、さらに、規格化された非圧縮フォーマット内に解凍され、通信プロトコルエンコーダがクライアントコンピュータに対する伝送のためにビットマップを圧縮するのを可能にする。これは、サーバーコンピュータにとって重大で冗長的な働きを伴うことができ、あらかじめ圧縮されたビットマップにすでに存在するものよりも低圧縮率にすること（すなわち、元のビットマップのさらなる低下）ができる。

さらに、ＲＤＰなどの通信プロトコルが実装されると、セパレートチャネルまたは仮想チャネルは、１または複数のビットマップと関連のあるメタデータ情報を提供するように実装することができる。このセパレートまたは仮想チャネルは、典型的に、ビットマップ、またはビットマップを含むグラフィックスストリームと同期を取らない。ビットマップまたはグラフィックスストリームが、メタデータが伝送される仮想チャネルからチャネルセパレートを経由して伝送されることは、典型的なことである。このことは、グラフィックスストリームと、あるメタデータが同期を取ることが望まれ、または要求されるシナリオにおける制限となる可能性がある。ＲＤＰに関するこのような制限の具体的な例は、クライアント側のウィンドウの位置および次元についての情報の不足である。グラフィックスストリームのディスプレイは、ウィンドウの配置によって直接的に影響されるべきである場合、注意深くグラフィックスストリームと同期を取ることは、ウィンドウの配置の変化にとって重要なことであるだろう。

さらに、クライアント側での任意のラージオブジェクトの再構築は、クライアントコンピュータでのメモリ管理上の問題点を引き起こす。例えば、ビットマップおよび／またはビットマップのピースは、クライアントコンピュータによって受け取られるので、ビットマップおよび／またはビットマップのピースは、バッファ中に配置し、それから再構築し、処理することができる。しかしながら、クライアントコンピュータのバッファは、ビットマップおよび／またはビットマップのピースに適合するほど十分にラージではない可能性がある。

クライアントコンピュータまたはサーバークライアントシステムのデバイスが、サーバーコンピュータに、ビットマップまたは他のオブジェクトを受け取るための能力に関する情報を提供することを可能にする、方法および装置を提供し、クライアントコンピュータが受け取ることができるオブジェクトを構築し、クライアントコンピュータのアプリケーションのメタデータを、ビットマップまたはオブジェクトを表すデータに加える。

この概要は、以下の詳細な説明でさらに説明する簡単な形式の概念の選択を紹介するために提供する。この概要は、特許請求の範囲に記載された事項の重要な特徴または本質的な特徴を特定することを意図したものではなく、クレームに記載された事項の範囲を定める補助として用いられることを意図したものでもない。

詳細な説明は、添付の図を参照して説明される。図において、参照番号の最左の桁は、参照番号が最初に出てきた図を識別する。異なる図中における同じ参照番号の使用は、類似または同一のアイテムを示す。

図１は、典型的なサーバーおよびリモートクライアント、またはサーバークライアントシステム１００を示す。システム１００は、サーバーコンピュータ１０２、および１または複数のクライアントデバイス、またはクライアントコンピュータ１０４として表されているクライアントコンピュータを含む。サーバーコンピュータ１０２およびクライアントコンピュータ１０４は、インターネットを含む１または複数のネットワークを含むことができるネットワーク１０６によって接続される。特に、グラフィックスイメージ、オブジェクト、および／またはグラフィックスイメージを表すビットマップは、クライアントコンピュータ１０４による処理またはディスプレイのために、サーバーコンピュータ１０２からクライアントコンピュータ１０４に送信される。グラフィックスイメージ、オブジェクト、および／またはビットマップは、どんな任意のサイズであってもよい。グラフィックスイメージ、オブジェクト、および／またはビットマップは、サーバーコンピュータ１０２によって、ＲＤＰ（Remote Desktop Protocol）などの通信プロトコルを用いて、通信することができる。ＴＣＰ／ＩＰ（transmission control protocol over Internet protocol）などの移送プロトコルは、ネットワーク１０６上において移送するときに、実装することができる。あるケースにおいては、ＲＤＰが実装されると、サーバーコンピュータ１０２は、「ＲＤＰサーバー」と呼ばれる可能性があり、クライアントコンピュータ１０４は、「ＲＤＰクライアント」と呼ばれる可能性がある。

グラフィックスイメージ、オブジェクト、および／またはビットマップは、サーバーコンピュータ１０２から通信されるので、グラフィックスイメージ、オブジェクト、および／またはビットマップを記述し、または関連付けられるどのメタデータも、グラフィックスイメージ、オブジェクト、および／またはビットマップに含まれるかもしれない。これは、メタデータがグラフィックスイメージ、オブジェクト、および／またはビットマップと同期を取ることを可能にする。サーバークライアントシステム１００は、この例において説明されるが、これは、イントラデバイスシステム（例えば、スタンドアローンのコンピューティングデバイス）などの他の実装が、本明細書で説明する技術および方法を使用することができることを意図する。

サーバーコンピュータ１０２は、中央演算処理装置、またはプロセッサ１０８として表される１または複数のプロセッサを含む。プロセッサ１０８は、記憶デバイスまたはメモリ１１０を制御し、またはアクセスすることができる。この例示的な実装においては、サーバーコンピュータ１０２は、さらに、メモリ１１０内に常駐することができるオペレーティングシステム１１２を含む。サーバーコンピュータ１０２は、プロセッサ１０８によって制御される１または複数のアプリケーションプログラムまたは（１または複数の）アプリケーション１１４を含む。特に、アプリケーション１１４は、クライアントコンピュータ１０４と通信するラフィックスイメージ、オブジェクト、および／またはビットマップを生成または提供するアプリケーションを含む。

ＤＬＬ（dynamic link library）１１６は、サーバーコンピュータ１０２に含まれる。特に、ＤＬＬ１１６は、（１または複数の）アプリケーション１１４がグラフィックスイメージ、オブジェクト、および／またはビットマップを受け渡すことを可能にする（１または複数の）アプリケーションプログラムインターフェース１１８を通じてアクセスされるルーチンを含む。「ＤｒｖＥｓｃａｐｅ」を含むそのようなルーチンの例は、ユーザーモード（例えば、アプリケーションレベル）から呼び出して、ディスプレイドライバ「ｒｄｐｄｄ．ｄｌｌ」（ディスプレイドライバは、典型的にカーネル／オペレーティングシステムモードまたはレベルである）とし、任意のエンコードしたビットマップを、この例で「ＳｕｐｅｒＢｌｔ」またはスーパービットブロック１２０と呼ばれる特定のＰＤＵとして再エンコードするように受け渡し、任意のエンコードしたビットマップは、最終的には、クライアントコンピュータ１０４に受け渡されるか、または通信される。（１または複数の）アプリケーションプログラムインターフェース１１８を通じて受け渡されるグラフィックスイメージ、オブジェクト、および／またはビットマップは、ピクセルのアルファ透過性の情報ごとにサポートするフォーマットを含む、どんな任意のフォーマット内にもある可能性がある。これは、メタデータがグラフィックスストリームと同期をとるように、メタデータをクライアントコンピュータ１０４に送ることができる例示的な実装であり、ここでは、ビットマップは、知られ、存在している「ＢｉｔＢｌｔ」ルーチンを用いて、「Ｗｉｎ３２」グラフィックスストリームなどの標準のコールとなることができる。

スーパービットブロック１２０は、ＲＤＰ（remote desktop protocol）などの通信プロトコルにおいて、下層レイヤによってマルチデータブロックに分割される、単一のＰＤＵである。ある実装においては、スーパービットブロック１２０は、プロトコルデータユニット１２２の一部である。エンコーダ１２４は、スーパービットブロック１２０をパケット、またはグラフィックスストリームに圧縮またはパッケージするように、実装することができ、そこでは、パケット、および／またはグラフィックスストリームは、単一のチャネルを経て送られる。特に、エンコーダ１２４は、ＲＤＰなどの固有の通信プロトコル、および／またはＴＣＰ／ＩＰなどの伝送プロトコルを実装するように構成される。他の実装においては、セパレートコンポーネントは、エンコーダ１２４の機能を提供するように用いることができる。あるケースにおいては、エンコーダ１２４またはサーバーコンピュータ１０２の他のコンポーネントは、どんなグラフィックスイメージ、オブジェクト、および／またはビットマップも大きすぎるので、より小さく扱いやすいグラフィックスイメージ、オブジェクト、および／またはビットマップに分解することができる。より小さなグラフィックスイメージ、オブジェクト、および／またはビットマップは、それから、クライアントコンピュータ１０４で再構築される。

クライアントコンピュータ１０４は、中央演算処理装置、またはプロセッサ１２６として表される１または複数のプロセッサを含む。プロセッサ１２６は、記憶デバイスまたはメモリ１２８を制御し、またはアクセスすることができる。この例示的な実装においては、クライアントコンピュータ１０４は、さらに、メモリ１２８に常駐することができるオペレーティングシステム１３０を含む。クライアントコンピュータ１０４は、１または複数のアプリケーションプログラム、またはプロセッサ１２６によって制御される（１または複数の）アプリケーション１３２を含む。特に、（１または複数の）アプリケーション１３２は、サーバーコンピュータ１０２から受け取ったグラフィックスイメージ、オブジェクト、および／またはビットマップを処理するアプリケーションを含む。特に、グラフィックスイメージ、オブジェクト、および／またはビットマップは、アプリケーション１３２によって、ＤＬＬ（dynamic link library）１３６内のルーチンまたはドライバにアクセスする（１または複数の）アプリケーションプログラムインターフェース１３４を通じて、受け取られる。固有のアプリケーションプログラムインターフェースは、以前から存在する「ｂｉｔ ｂｌｏｃｋ」規則およびプロトコルに基づいて、「ｂｉｔ ｂｌｏｃｋ」型のインターフェースである可能性があり、ここでは、そのようなインターフェースは、再構築されたビットマップデータ（すなわち、グラフィックスイメージ、オブジェクト、ビットマップ）を、対応するメタデータとともに（１または複数の）アプリケーション１３２に受け渡すために用いられる。ＤＬＬ１３６のルーチンまたはドライバは、特に、グラフィックスデータまたは情報を、アプリケーション１３２からオペレーティングシステム１３０に受け渡すために用いられる。

クライアントコンピュータ１０４は、デコーダ１３８を含む。デコーダ１３８は、データまたはグラフィックスストリーム内にあるかもしれないが、ないかもしれないスーパービットブロック（すなわち、グラフィックスイメージ、オブジェクト、および／またはビットマップ）などの受け取ったＰＤＵを解凍することができる。デコーダ１３８の他の機能は、受け取ったグラフィックスイメージ、オブジェクト、および／またはビットマップを、特定の通信プロトコル（例えば、ＲＤＰ）および／または伝送プロトコル（例えば、ＴＣＰ／ＩＰ）に基づいてデコードすることを、含むことができる。

固有のケースでは、スーパービットブロックなどの受け取ったオブジェクトは、クライアントコンピュータ１０４で再構築される離散オブジェクトの代わりにストリームとして取り扱うことができる。例示的な実装においては、デコーダ１３８は、グラフィックスイメージ、オブジェクト、および／またはビットマップを記述するスーパービット１２０を含むデータストリームまたはグラフィックスストリームのデコード状態のトラックを保つために用いることができる。グラフィックスストリームのデコード状態をトラッキングすることにより、グラフィックスストリームは、割り込みをされる可能性があり、クライアントコンピュータ１０４は、割り込みが生じる場合に継続すべき場所を知る。固有の実装は、デコーダ１３８を、受け取ったデータ（例えば、グラフィックスストリーム内のスーパービットブロック）のコンテキストを明示的に格納する状態マシンとして提供することである。別の実装においては、デコーダ１３８は、デコーダ１３８がグラフィックスストリームから読み込むように、セパレートスレッドでサーバー１０２に対して稼動する。デコーダ１３８が、さらなるデータ（例えば、スーパービットブロック）のために待つ必要がある場合、デコーダ１３８は、「中断」される。中断されると、デコーダ１３８の状態は、暗黙的に、デコーダ１３８が稼動するセパレートスレッドのスレッドスタックに保存される。言い換えると、デコーダ１３８は中断されるが、デコーダ１３８がアンブロックになる（すなわち、中断されなくなる）場合に継続すべき場所を知っているように、デコーダ１３８の状態は、暗黙的にデコーダスレッドのスタックに固定される。

再構築バッファ１４０は、クライアントコンピュータ１０４内に含むことができる。再構築バッファ１４０は、特に、（１または複数の）アプリケーションインターフェース内のアプリケーションプログラムインターフェース１３４の受け渡しに先立ち、スーパービットブロック（すなわち、グラフィックスイメージ、オブジェクト、および／またはビットマップ）のより小さなピースを格納する。スーパービットブロックが小さなピースに分けられることを特徴とする特定の実装においては、再構築バッファ１４０は、クライアントコンピュータ１０４に含まれない。ある実装においては、セパレートバッファ（図示せず）は、クライアントコンピュータ１０４によるさらなる処理の前に、スーパービットブロック（すなわち、グラフィックスイメージ、オブジェクト、および／またはビットマップ）を一時的に格納するために用いることができる。

上述したように、クライアントコンピュータ１０４は、ＲＤＰなどの通信プロトコルを実装することができ、ＲＤＰクライアントと呼ぶことができる。ＲＤＰクライアントのように、クライアントコンピュータ１０４は、アプリケーションプログラムインターフェースを通じて、一組のプロトコルデータユニット１４４を含むスーパービットブロック１４２を受け取る。さらに、スーパービットブロック１４２は、すなわち、マルチデータブロックにするスプリットである。スーパービットブロック１４２は、他のプロトコルデータユニット１４４に含まれる可能性がある。特定のグラフィックスイメージ、オブジェクト、またはビットマップを記述するデータ含むスーパービットブロック１４２内のデータは、（１または複数の）アプリケーション１３２によって、ディスプレイ１４６にグラフィックスイメージを生成またはレンダーするために用いることができる。

図２は、マルチフラグメントＰＤＵ２００の例示的なデータブロックの構造を示す。上述したスーパービットブロック１２０は、特に、マルチフラグメントＰＤＵ２００によって実装される。

マルチフラグメントＰＤＵ２００は、どんな固有のサイズであってもよい。しかしながら、リソース（例えば、バッファの受け取り）がクライアントコンピュータ１０４で制限されると、圧縮は、マルチフラグメントＰＤＵ２００をサポートするために必要であるかもしれない。そのようなケースにおいては、クライアントコンピュータ１０４は、サーバーコンピュータ１０２に固有のサイズ制限に関して知らせるかもしれない。例として、マルチフラグメントＰＤＵ２００は、最初は、１または２ＭＢのサイズであってよく、クライアントコンピュータ１０４は、６４ＫＢのみをサポートできる。実装は、スーパービットブロック１２０またはマルチフラグメントＰＤＵ２００をより小さいピースに分解することを伴うことができる。別の実装においては、スーパービットブロック１２０またはマルチフラグメントＰＤＵ２００の全体が送信され、ここでは、スーパービットブロック１２０またはマルチフラグメントＰＤＵ２００の選択的なデータが圧縮され、スーパービットブロック１２０またはマルチフラグメントＰＤＵ２００の全体のサイズを効果的に減少させる。

マルチフラグメントＰＤＵ２００は、ヘッダー２０２、メタデータ２０４、およびペイロードまたはビット２０６を含むことができる。ヘッダー２０２は、色の濃さおよび圧縮型などのビットマップ（または、グラフィックスイメージまたはオブジェクト）に関する情報を含むことができる。さらに、ヘッダー２０２は、後続のメタデータ２０４およびビット２０６のサイズを記述することができる。あるケースにおいては、スーパービットブロック１２０またはマルチフラグメントＰＤＵ２００は、サーバーコンピュータ１０２から、メタデータ２０４の情報のみ（すなわち、ペイロード２０６は送られないか、または空である）とともに伝達または通信することができる。メタデータ２０４は、ペイロード２０６内の情報を対象とする、どの追加情報をも含むことができる。メタデータ２０４内の情報は、特に、クライアントコンピュータ１０４の（１または複数の）アプリケーション１３２によって用いられるアプリケーションレベルのデータを対象とする。メタデータ２０４をペイロード２０６とともに提供することによって、メタデータは、ペイロード２０６と同期を取る。例として、メタデータの同期は、特に、音とディスプレイのアクションの同期を取ること、および安定したフレームレートのビデオの品質を向上させるためのタイミング情報と関連付けることにおいて、有益である。

マルチフラグメントＰＤＵ２００は、最初のフラグメント２０８、次のフラグメント２１０、最後のフラグメント２１２によって表されているように、複数フラグメントに分割することができる。ＲＤＰプロトコルは、更新ＰＤＵメカニズムを提供する。この例においては、更新ＰＤＵメカニズムは、最初のフラグメント２０８、次のフラグメント２１０、最後のフラグメント２１２を含むマルチフラグメントＰＤＵ２００などのマルチフラグメントＰＤＵをサポートするまで拡張される。特に、ＲＤＰなどの通信プロトコルは、プロトコルの下層を通じて、マルチフラグメントＰＤＵを、複数データブロック、または最初のフラグメント２０８、次のフラグメント２１０、最後のフラグメント２１２などの複数フラグメントに分割することが可能である。

マルチフラグメントＰＤＵ２００は、ビットマップなどのどんなリソースを送るためにも用いることができる。言い換えると、マルチフラグメントＰＤＵ２００は、どんな固有のオブジェクトタイプにも制限されない。「最初、次、最後」と識別されるマルチフラグメント２０８、２１０、および２１２を提供することによって、デコーダ層（例えば、デコーダ１３８）は、データをデコーダの上層に受け渡す前に追加フラグメントを受け取るべきかどうかを知っており、デコーダの上層は、ＰＤＵまたはマルチフラグメントＰＤＵ２００内の実在のリソースまたはオブジェクトタイプに関して知っている。

図３は、データストリームと同期を取るアプリケーションレベルのメタデータを送信するプロセス３００を示す。プロセス３００は、サーバーコンピュータ（例えば、サーバーコンピュータ１０２）とクライアントコンピュータ（例えば、クライアントコンピュータ１０４）の間のプロトコルとして実装することができる。プロセス３００は、ハードウェア、ソフトウェア、ファームウェア、またはこれらの組み合わせで実装することができる操作の順序を表す論理フローグラフのブロックの集合として図示される。ソフトウェアのコンテキストにおいては、ブロックは、１または複数のプロセッサによって実行されるときのコンピュータの構造を表し、列挙した操作を行う。フローチャートとして記述されているが、あるブロックは、一斉に、または異なる順序で起こりうることを意図している。

ブロック３０２では、サーバーコンピュータは、グラフィックスイメージに記述され、または関連づけられているオブジェクトまたはビットマップデータを受け取るための、１または複数のクライアントコンピュータ（デバイス）の可用性に関する情報を受け取る。例えば、オブジェクトは、マルチフラグメントＰＤＵ（例えば、マルチフラグメントＰＤＵ２００）として表される。グラフィックスイメージは、アプリケーション、またはサーバーコンピュータで稼動しているアプリケーションプログラムによって、提供することができる。クライアントコンピュータの可用性に加え、サーバーコンピュータは、固有のクライアントコンピュータのリソース機能に関する情報を受け取ることができる。リソース機能は、受け取りバッファおよび再構築バッファを含むクライアントコンピュータのバッファ容量を含むことができる。情報は、データをサーバーコンピュータからクライアントコンピュータに送信するチャネル、またはセパレートチャネルを通じて伝達することができる。

ブロック３０４では、オブジェクトまたはビットマップ、またはオブジェクトまたはビットマップを表すデータ（例えば、マルチフラグメントＰＤＵ）を全体として送信するかどうかの決定が、サーバーコンピュータでなされる。決定の要因は、クライアントコンピュータのリソース機能である。対照的に、オブジェクトまたはビットマップ（データ）は、より小さなピースに分けることができる。より小さなピースは、最終的には、クライアントコンピュータによって受け取られ、再構築される。決定すること、および決定は、クライアントコンピュータのリソース機能に基づくことができる。

ブロック３０６では、ヘッダーおよびメタデータの情報は、オブジェクトまたはビットマップデータに追加される。メタデータは、特に、クライアントコンピュータに常駐するアプリケーションによって用いられることを対象とし、クライアントコンピュータでは、そのようなアプリケーションは、オブジェクトまたはビットマップデータを消費または処理する。メタデータは、さらに、オブジェクトまたはビットマップデータに関して、記述または提供することができる。オブジェクトは、上述の図２で説明したように、複数フラグメントを含むことができるマルチフラグメントＰＤＵによって、表すことができる。特に、複数フラグメントは、順序付けすることができ、特定のフラグメントが配置される順序（例えば、最初、次、および最後）に関する各フラグメントの識別子を含むことができる。

ブロック３０８では、ヘッダー、メタデータ、およびオブジェクトまたはビットマップデータは、図２で説明したマルチフラグメントＰＤＵなどの特定のデータフォーマットに構築することができ、クライアントコンピュータに送信することができる。ヘッダー、メタデータ、およびオブジェクトまたはビットマップデータ（すなわち、マルチフラグメントＰＤＵ、またはスーパービットブロック）は、さらに圧縮し、ＲＤＰなどの特定の通信プロトコル、および／またはＴＣＰ／ＩＰなどの特定の伝送プロトコルに基づいてエンコードすることができる。離散マルチフラグメントＰＤＵまたはスーパービットブロックは、データストリームの作成者（すなわち、アプリケーション）、およびデータストリームの消費者（すなわち、アプリケーション）が存在するように、イントラデバイス（すなわち、同一マシン内のデバイス）と通信するデータストリーム内に含まれるか、またはイントラデバイス（すなわち、同一マシン内のデバイス）と通信するデータストリームデータストリームの一部である可能性がある。

図４は、着信ラージオブジェクトをデータストリームとして取り扱うプロセス４００を示す。プロセス４００は、特に、ビットマップなどのラージオブジェクトを、クライアントコンピュータ（例えば、クライアントコンピュータ１０４）で維持することを対象としている。プロセス４００は、スーパービットブロックのようなオブジェクトを受け取るように、クライアントコンピュータで実装することができる。プロセス４００は、ハードウェア、ソフトウェア、ファームウェア、またはこれらの組み合わせで実装することができる操作の順序を表す論理フローグラフのブロックの集合として図示される。ソフトウェアのコンテキストにおいては、ブロックは、１または複数のプロセッサによって実行されるときのコンピュータ命令を表し、列挙した操作を行う。フローチャートとして記述されているが、あるブロックは、一斉に、または異なる順序で起こりうることを意図している。

ブロック４０２では、クライアントコンピュータは、グラフィックスまたはデータストリーム内で、スーパービットブロックのようなオブジェクトを受け取る。データストリームは、サーバーコンピュータから生じることができ、図１に示した例示的システム１００によって説明されるように、１または複数のネットワーク上で伝送することができる。データストリームは、特定のスレッドまたはチャネルを通じて送信することができる。

クライアントコンピュータのデコーダまたは同様のコンポーネントは、データストリーム内でオブジェクトを受け取り、処理することができる。デコーダが、セパレートスレッド内のデータストリームを、データストリームを通信または送信するスレッドから受け取らない（すなわち、ブロック４０４の「ＮＯ」の枝に従う）場合、特定の実装に対して、ブロック４０６では、デコーダはデータストリームのデコード状態、特にデータストリーム内のオブジェクトのデコード状態をトラッキングすることができる。

ブロック４０８では、状態マシンとして動くデコーダは、コンテキストまたはデータストリーム内で受け取ったオブジェクトのデコード状態を格納することができる。ブロック４１０では、データストリームが割り込まれると（すなわち、デコーダがデータストリームの受け取りを停止すると）、それからデコードは、受け取ったオブジェクトのデコード状態に基づいて、継続することができる。

デコーダが、データストリームが受け取られるセパレートスレッドで稼動する場合（すなわち、ブロック４０４の「ＹＥＳ」の枝に従う場合）、別の実装においては、ブロック４１２では、デコーダは、セパレートスレッドのデータストリームから読み込まれる。

ブロック４１４では、データストリーム内の、さらなる、または追加のデータ／オブジェクトがデコードによって必要とされる場合、デコーダは中断される。ブロック４１６では、デコーダの状態は、保存される。特に、デコーダがセパレートスレッドで稼動する場合、デコーダが中断されると、セパレートスレッドのスレッドスタックは、暗黙的にデコーダの状態を保存する。ブロック４１８では、割り込みが生じると、デコードは、デコーダの状態（スレッドスタックの状態）に基づいて継続することができる。

（結論）
上述した方法およびデバイスは、処理するために、グラフィックイメージのビットマップなどの任意のサイズのオブジェクトを、クライアントデバイスと通信することについて説明する。本発明は、構造上の特徴、および／または方法的な動作に固有の言語で説明されているが、添付の特許請求の範囲に定義される本発明は、説明した固有の特徴、または動作に限定する必要がないことを理解されたい。むしろ、固有の特徴および動作は、特許請求の範囲に記載された発明の例示的な実装形式として開示する。

クライアントコンピュータがラージオブジェクトのフラグメントを再構築することを可能にする、プロトコルおよびＡＰＩ（application programming interfaces）を組み込むサーバークライアントシステムの図である。 マルチフラグメントプロトコルのデータユニットの例示的なブロック図である。 データストリームと同期を取るアプリケーションレベルのメタデータを送信するためのプロセスを図示するフローチャートである。 着信ラージオブジェクトをデータストリームの一部として取り扱うためのプロセスを図示するフローチャートである。

Claims (12)

1. サーバーコンピュータが、該サーバーコンピュータからオブジェクトを受信するクライアントデバイスの機能に関する情報を受信するステップであって、前記オブジェクトは、グラフィックスイメージを表すビットマップを記述するステップと、
   前記サーバーコンピュータが、少なくとも前記クライアントデバイスの機能に基づいて、前記オブジェクトを分割して前記クライアントデバイスに送信すべきか、または前記オブジェクトを全体として前記クライアントデバイスに送信するかどうかを決定するステップと、
   前記クライアントデバイスのアプリケーションによって前記オブジェクトを処理するのに使用されるメタデータを、前記オブジェクトに追加するステップと、
   前記オブジェクトおよび前記メタデータをマルチフラグメントＰＤＵに構築するステップと、
   前記マルチフラグメントＰＤＵを分割して、各フラグメントが対応する識別子によって識別される、複数のフラグメントを作成するステップと、
   前記識別子に基づく順序で各フラグメントが配置された前記マルチフラグメントＰＤＵを、前記クライアントデバイスに送信するステップと
   を含むことを特徴とする方法。
2. 前記受信した情報は、前記クライアントデバイスの受信用のバッファ容量および再構築用のバッファ容量を含むリソース機能に関する情報を含むことを特徴とする請求項１に記載の方法。
3. 前記サーバーコンピュータが前記情報を受信するステップは、前記送信するステップが行われるチャネルとは別個のチャネルを介して前記情報を受信することを含むこと特徴とする請求項１に記載の方法。
4. 前記追加するステップは、前記オブジェクトを記述するヘッダーを前記オブジェクトに追加するステップをさらに含むことを特徴とする請求項１に記載の方法。
5. 前記送信するステップは、送信する前に、前記マルチフラグメントＰＤＵを圧縮することをさらに含むことを特徴とする請求項１に記載の方法。
6. 前記送信するステップは、前記マルチフラグメントＰＤＵをデータストリームとして送信することを含むことを特徴とする請求項１に記載の方法。
7. メモリと、
   オペレーティングシステムと、
   プロセッサと
   を備え、
   前記プロセッサが、
   グラフィックスイメージを表すビットマップを記述するオブジェクトを送信すべきクライアントデバイスの機能に関する情報を受信し、
   少なくとも前記クライアントデバイスの機能に基づいて、前記オブジェクトを分割して送信すべきか、または前記オブジェクトを全体として送信すべきかを決定し、
   前記クライアントデバイスに存在するアプリケーションが前記オブジェクトを処理するのに使用されるメタデータを、前記オブジェクトに追加し、
   前記オブジェクトおよび前記メタデータをマルチフラグメントＰＤＵに構築し、
   前記マルチフラグメントＰＤＵを分割して、各フラグメントが対応する識別子によって識別される、複数のフラグメントを作成し、
   前記識別子に基づく順序で各フラグメントが配置された前記マルチフラグメントＰＤＵを、前記クライアントデバイスに送信する
   ように構成されることを特徴とするサーバーコンピュータ。
8. 前記クライアントデバイスの前記機能は、前記クライアントデバイスの受信用のバッファ容量および再構築用のバッファ容量を含むリソース機能を含むことを特徴とする請求項７に記載のサーバーコンピュータ。
9. 前記マルチフラグメントＰＤＵを分割して複数のフラグメントを作成することは、前記クライアントデバイスのリソース機能に基づいて行われることを特徴とする請求項８に記載のサーバーコンピュータ。
10. オブジェクトを送信すべきクライアントデバイスの機能に関する情報を受信するステップであって、前記オブジェクトは、グラフィクスイメージを表す任意のサイズのビットマップであるステップと、
    前記オブジェクトを分割して前記クライアントデバイスに送信すべきか、または前記オブジェクトを全体として前記クライアントデバイスに送信すべきかどうかを、少なくとも前記クライアントデバイスの機能に基づいて決定するステップと、
    前記クライアントデバイスのアプリケーションによって前記オブジェクトを処理するのに使用されるメタデータを、前記オブジェクトに追加するステップと、
    前記オブジェクトおよび前記メタデータをマルチフラグメントＰＤＵに構築するステップと、
    前記マルチフラグメントＰＤＵを分割して、各フラグメントが対応する識別子によって識別される、複数のフラグメントを作成するステップと、
    前記識別子に基づく順序で各フラグメントが配置された前記マルチフラグメントＰＤＵを、前記クライアントデバイスに送信するステップと
    を含む処理をサーバーコンピュータに実行させるためのコンピュータ実行可能な命令を記録したことを特徴とするコンピュータ読取可能な記録媒体。
11. 前記受信した情報は、前記クライアントデバイスのリソース機能に関する情報を含むことを特徴とする請求項１０に記載のコンピュータ読取可能な記録媒体。
12. 前記メタデータは、前記オブジェクトと同期されることを特徴とする請求項１０に記載のコンピュータ読取可能な記録媒体。

Images