(57)【要約】  サーバーコンピュータ（１０２）は、クライアントコンピュータまたはデバイスによって処理するため、グラフィックイメージを表すビットマップのようなオブジェクト（１２２）を提供する。オブジェクトは、どんな任意のサイズであってもよく、クライアントコンピュータが受け取ることができるデータ構造（１２２）に変換される。同期を取ったメタデータは、データ構造に含むことができ、そこでは、メタデータは、クライアントコンピュータまたはデバイス（１０４）においてアプリケーションによって用いられる。
2009506456.tif 000002
【特許請求の範囲】
【請求項１】
サーバーコンピュータからオブジェクトを受け取るためのクライアントデバイスの機能に関する情報を受け取るステップ（３０２）と、
前記オブジェクトを分けるかどうか、または前記オブジェクトを全体としてクライアントデバイスに送信するかどうかを、少なくとも前記クライアントデバイスの前記機能に基づいて決定するステップ（３０４）と、
前記クライアントデバイスに常駐するアプリケーションによってオブジェクトを処理するために用いられる前記メタデータを、前記オブジェクトに追加するステップ（３０６）と、
前記オブジェクトおよびメタデータを特定のデータフォーマットに構築するステップ（３０８）と、
前記特定のデータフォーマットに構築された前記オブジェクトおよびメタデータを、前記クライアントデバイスに送信するステップ（３０８）と
を備える方法（３００）。
【請求項２】
前記オブジェクトは、グラフィックスイメージのビットマップの表現を記述することを特徴とする請求項１に記載の方法。
【請求項３】
前記受け取る情報は、前記クライアントデバイスのバッファ容量を含むリソース機能を備えることを特徴とする請求項１に記載の方法。
【請求項４】
前記受け取る情報は、前記送信するステップが行われるチャネルから離れているチャネルを介すること特徴とする請求項１に記載の方法。
【請求項５】
前記受け取る情報は、前記送信するステップが行われるチャネルから離れているチャネルを介すること特徴とする請求項１に記載の方法。
【請求項６】
前記追加するステップは、オブジェクトを記述するヘッダーをさらに備えることを特徴とする請求項１に記載の方法。
【請求項７】
前記送信するステップは、オブジェクトをパッケージし、圧縮することをさらに備えることを特徴とする請求項１に記載の方法。
【請求項８】
前記送るステップは、オブジェクトを含むデータストリームを介することを特徴とする請求項１に記載の方法。
【請求項９】
オブジェクトを、通信プロトコルによって行われるように、シーケンス順によって順序づけされ識別される離散ユニットに分けるステップをさらに備える請求項１に記載の方法。
【請求項１０】
特定のスレッドのデータストリーム内でオブジェクトを受け取るステップ（４０２）と、
同一の前記スレッドが処理に用いられる場合に、前記データストリーム内で前記オブジェクトを処理するステップ（４０４）と、
前記データストリームの前記デコード状態をトラックするステップ（４０６）と、
データストリーム内の受け取られたオブジェクトのコンテキストを格納するステップ（０８）と、
前記データストリームを受け取る割り込みのあとに、受け取られたオブジェクトのコンテキストに基づいてデコードするステップ（４１０）と
を備える方法（４００）。
【請求項１１】
前記オブジェクトは、グラフィックスイメージを表すビットマップであること、および前記データストリームは、グラフィックスストリームであることを特徴とする請求項１０に記載の方法。
【請求項１２】
前記オブジェクトは、グラフィックスイメージを表すビットマップであること、および前記データストリームは、グラフィックスストリームであることを特徴とする請求項１０に記載の方法。
【請求項１３】
セパレートスレッドが、前記処理するステップに提供される場合は、
前記セパレートスレッドの前記データストリームを読み込むステップと、
追加データが必要とされる場合は、デコーダによって行われる前記処理するステップを中断するステップと、
前記中断するステップが起こると、前記デコーダの前記状態を保存するステップと
を特徴とする請求項１０に記載の方法。
【請求項１４】
前記デコーダの前記状態を前記保存するステップは、前記セパレートスレッドのスレッドスタックの前記状態を保存することによって行われることを特徴とする請求項１３に記載の方法。
【請求項１５】
割り込みのあとに前記デコーダの前記状態に基づいてデコードするステップをさらに備える請求項１３に記載の方法。
【請求項１６】
プロセッサ（１０８）と、
前記プロセッサによって制御されるアプリケーション（１１４）であって、グラフィックスイメージを提供する前記アプリケーションと、
前記アプリケーションに対するアプリケーションプログラムインターフェース（１１８）と、
前記グラフィックスイメージをスーパービットブロックにエンコードする次のドライバに、前記グラフィックスイメージを受け渡すことを可能にする、前記アプリケーションプログラムインタフェースによってアクセスされる最初のドライバ（１１６）と
を備えるコンピュータ（１０２）。
【請求項１７】
前記グラフィックスイメージは、どんな任意のサイズのビットマップによっても表されることを特徴とする請求項１６に記載のコンピュータ。
【請求項１８】
前記スーパービットブロックは、一組のプロトコルデータユニットであって、前記一組においてシーケンス順に識別される一組のプロトコルデータユニットを備えることを特徴とする請求項１６に記載のコンピュータ。
【請求項１９】
クライアントデバイスに通信するために、前記スーパービットブロックをエンコードすること、およびパッケージすることをさらに備える請求項１６に記載のコンピュータ。
【請求項２０】
前記グラフィックスストリーム内の前記スーパービットブロックをクライアントデバイスに送信することをさらに備える請求項１６に記載のコンピュータ。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、任意のフォーマットにおけるラージオブジェクトの通信のためのリモートプロトコルサポートに関する。
【背景技術】
【０００２】
アプリケーションプログラム、またはアプリケーションは、グラフィックイメージを作成し、提供することができる。グラフィックイメージは、他のアプリケーションに移すことができるビットマップによって表すことができる。グラフィックイメージは、複雑性またはサイズにおいて変化することができるので、グラフィックイメージを表すビットマップもまた、複雑性またはサイズにおいて変化することができる。
【０００３】
サーバーコンピュータが１または複数のクライアントコンピュータをサポートする、サーバーおよびリモートクライアントシステムにおいて、サーバーコンピュータからのビットマップは、より小さなピースに分解し、クライアントコンピュータと通信することができる。クライアントコンピュータは、それぞれのより小さなビットマップのピースを個々にディスプレイし、または処理することができる。言い換えると、より大きなグラフィックイメージをディスプレイするために、それぞれのより小さなビットマップのピースを処理する。高速で変換または更新する比較的大きなサイズのビットマップにとっての問題は、クライアントコンピュータで見られる切り離し効果である。切り離し効果は、クライアントコンピュータが各ビットマップのピースをディスプレイするように起こる。
【０００４】
ビットマップが、クライアントコンピュータに一度に（すなわち、より小さなピースに分解されずに）送信されると、クライアントコンピュータは、どのようにビットマップをディスプレイすることができるかを、クライアントコンピュータで見られる固有の制約（例えば、高速更新）を与えて決めることができるが、ビットマップがその全体で送られると、ビットマップは圧縮されなければならないかもしれない。圧縮は、典型的には、比較的大きいサイズのビットマップのサポートに用いられる。サーバーコンピュータで稼動しているアプリケーションは、特定の圧縮フォーマットに基づいてビットマップを圧縮することができる。圧縮フォーマットは、損失をともなうものであるかもしれない、つまりビットマップ（すなわち、グラフィックイメージ）が圧縮されると、何らかの情報またはデータが落ちるか、失われることを意味する。
【０００５】
ビットマップは、ＲＤＰ（Remote Desktop Protocol）などの特定の通信プロトコルを用いて、クライアントコンピュータに通信し、伝送することができる。典型的に、通信プロトコルが用いられると、圧縮されたビットマップは、さらに、規格化された非圧縮フォーマット内に解凍され、通信プロトコルエンコーダがクライアントコンピュータに対する伝送のためにビットマップを圧縮するのを可能にする。これは、サーバーコンピュータにとって重大で冗長的な働きを伴うことができ、あらかじめ圧縮されたビットマップにすでに存在するものよりも低圧縮率にすること（すなわち、元のビットマップのさらなる低下）ができる。
【０００６】
さらに、ＲＤＰなどの通信プロトコルが実装されると、セパレートチャネルまたは仮想チャネルは、１または複数のビットマップと関連のあるメタデータ情報を提供するように実装することができる。このセパレートまたは仮想チャネルは、典型的に、ビットマップ、またはビットマップを含むグラフィックスストリームと同期を取らない。ビットマップまたはグラフィックスストリームが、メタデータが伝送される仮想チャネルからチャネルセパレートを経由して伝送されることは、典型的なことである。このことは、グラフィックスストリームと、あるメタデータが同期を取ることが望まれ、または要求されるシナリオにおける制限となる可能性がある。ＲＤＰに関するこのような制限の具体的な例は、クライアント側のウィンドウの位置および次元についての情報の不足である。グラフィックスストリームのディスプレイは、ウィンドウの配置によって直接的に影響されるべきである場合、注意深くグラフィックスストリームと同期を取ることは、ウィンドウの配置の変化にとって重要なことであるだろう。
【発明の開示】
【発明が解決しようとする課題】
【０００７】
さらに、クライアント側での任意のラージオブジェクトの再構築は、クライアントコンピュータでのメモリ管理上の問題点を引き起こす。例えば、ビットマップおよび／またはビットマップのピースは、クライアントコンピュータによって受け取られるので、ビットマップおよび／またはビットマップのピースは、バッファ中に配置し、それから再構築し、処理することができる。しかしながら、クライアントコンピュータのバッファは、ビットマップおよび／またはビットマップのピースに適合するほど十分にラージではない可能性がある。
【課題を解決するための手段】
【０００８】
クライアントコンピュータまたはサーバークライアントシステムのデバイスが、サーバーコンピュータに、ビットマップまたは他のオブジェクトを受け取るための能力に関する情報を提供することを可能にする、方法および装置を提供し、クライアントコンピュータが受け取ることができるオブジェクトを構築し、クライアントコンピュータのアプリケーションのメタデータを、ビットマップまたはオブジェクトを表すデータに加える。
【０００９】
この概要は、以下の詳細な説明でさらに説明する簡単な形式の概念の選択を紹介するために提供する。この概要は、特許請求の範囲に記載された事項の重要な特徴または本質的な特徴を特定することを意図したものではなく、クレームに記載された事項の範囲を定める補助として用いられることを意図したものでもない。
【発明を実施するための最良の形態】
【００１０】
詳細な説明は、添付の図を参照して説明される。図において、参照番号の最左の桁は、参照番号が最初に出てきた図を識別する。異なる図中における同じ参照番号の使用は、類似または同一のアイテムを示す。
【００１１】
図１は、典型的なサーバーおよびリモートクライアント、またはサーバークライアントシステム１００を示す。システム１００は、サーバーコンピュータ１０２、および１または複数のクライアントデバイス、またはクライアントコンピュータ１０４として表されているクライアントコンピュータを含む。サーバーコンピュータ１０２およびクライアントコンピュータ１０４は、インターネットを含む１または複数のネットワークを含むことができるネットワーク１０６によって接続される。特に、グラフィックスイメージ、オブジェクト、および／またはグラフィックスイメージを表すビットマップは、クライアントコンピュータ１０４による処理またはディスプレイのために、サーバーコンピュータ１０２からクライアントコンピュータ１０４に送信される。グラフィックスイメージ、オブジェクト、および／またはビットマップは、どんな任意のサイズであってもよい。グラフィックスイメージ、オブジェクト、および／またはビットマップは、サーバーコンピュータ１０２によって、ＲＤＰ（Remote Desktop Protocol）などの通信プロトコルを用いて、通信することができる。ＴＣＰ／ＩＰ（transmission control protocol over Internet protocol）などの移送プロトコルは、ネットワーク１０６上において移送するときに、実装することができる。あるケースにおいては、ＲＤＰが実装されると、サーバーコンピュータ１０２は、「ＲＤＰサーバー」と呼ばれる可能性があり、クライアントコンピュータ１０４は、「ＲＤＰクライアント」と呼ばれる可能性がある。
【００１２】
グラフィックスイメージ、オブジェクト、および／またはビットマップは、サーバーコンピュータ１０２から通信されるので、グラフィックスイメージ、オブジェクト、および／またはビットマップを記述し、または関連付けられるどのメタデータも、グラフィックスイメージ、オブジェクト、および／またはビットマップに含まれるかもしれない。これは、メタデータがグラフィックスイメージ、オブジェクト、および／またはビットマップと同期を取ることを可能にする。サーバークライアントシステム１００は、この例において説明されるが、これは、イントラデバイスシステム（例えば、スタンドアローンのコンピューティングデバイス）などの他の実装が、本明細書で説明する技術および方法を使用することができることを意図する。
【００１３】
サーバーコンピュータ１０２は、中央演算処理装置、またはプロセッサ１０８として表される１または複数のプロセッサを含む。プロセッサ１０８は、記憶デバイスまたはメモリ１１０を制御し、またはアクセスすることができる。この例示的な実装においては、サーバーコンピュータ１０２は、さらに、メモリ１１０内に常駐することができるオペレーティングシステム１１２を含む。サーバーコンピュータ１０２は、プロセッサ１０８によって制御される１または複数のアプリケーションプログラムまたは（１または複数の）アプリケーション１１４を含む。特に、アプリケーション１１４は、クライアントコンピュータ１０４と通信するラフィックスイメージ、オブジェクト、および／またはビットマップを生成または提供するアプリケーションを含む。
【００１４】
ＤＬＬ（dynamic link library）１１６は、サーバーコンピュータ１０２に含まれる。特に、ＤＬＬ１１６は、（１または複数の）アプリケーション１１４がグラフィックスイメージ、オブジェクト、および／またはビットマップを受け渡すことを可能にする（１または複数の）アプリケーションプログラムインターフェース１１８を通じてアクセスされるルーチンを含む。「ＤｒｖＥｓｃａｐｅ」を含むそのようなルーチンの例は、ユーザーモード（例えば、アプリケーションレベル）から呼び出して、ディスプレイドライバ「ｒｄｐｄｄ．ｄｌｌ」（ディスプレイドライバは、典型的にカーネル／オペレーティングシステムモードまたはレベルである）とし、任意のエンコードしたビットマップを、この例で「ＳｕｐｅｒＢｌｔ」またはスーパービットブロック１２０と呼ばれる特定のＰＤＵとして再エンコードするように受け渡し、任意のエンコードしたビットマップは、最終的には、クライアントコンピュータ１０４に受け渡されるか、または通信される。（１または複数の）アプリケーションプログラムインターフェース１１８を通じて受け渡されるグラフィックスイメージ、オブジェクト、および／またはビットマップは、ピクセルのアルファ透過性の情報ごとにサポートするフォーマットを含む、どんな任意のフォーマット内にもある可能性がある。これは、メタデータがグラフィックスストリームと同期をとるように、メタデータをクライアントコンピュータ１０４に送ることができる例示的な実装であり、ここでは、ビットマップは、知られ、存在している「ＢｉｔＢｌｔ」ルーチンを用いて、「Ｗｉｎ３２」グラフィックスストリームなどの標準のコールとなることができる。
【００１５】
スーパービットブロック１２０は、ＲＤＰ（remote desktop protocol）などの通信プロトコルにおいて、下層レイヤによってマルチデータブロックに分割される、単一のＰＤＵである。ある実装においては、スーパービットブロック１２０は、プロトコルデータユニット１２２の一部である。エンコーダ１２４は、スーパービットブロック１２０をパケット、またはグラフィックスストリームに圧縮またはパッケージするように、実装することができ、そこでは、パケット、および／またはグラフィックスストリームは、単一のチャネルを経て送られる。特に、エンコーダ１２４は、ＲＤＰなどの固有の通信プロトコル、および／またはＴＣＰ／ＩＰなどの伝送プロトコルを実装するように構成される。他の実装においては、セパレートコンポーネントは、エンコーダ１２４の機能を提供するように用いることができる。あるケースにおいては、エンコーダ１２４またはサーバーコンピュータ１０２の他のコンポーネントは、どんなグラフィックスイメージ、オブジェクト、および／またはビットマップも大きすぎるので、より小さく扱いやすいグラフィックスイメージ、オブジェクト、および／またはビットマップに分解することができる。より小さなグラフィックスイメージ、オブジェクト、および／またはビットマップは、それから、クライアントコンピュータ１０４で再構築される。
【００１６】
クライアントコンピュータ１０４は、中央演算処理装置、またはプロセッサ１２６として表される１または複数のプロセッサを含む。プロセッサ１２６は、記憶デバイスまたはメモリ１２８を制御し、またはアクセスすることができる。この例示的な実装においては、クライアントコンピュータ１０４は、さらに、メモリ１２８に常駐することができるオペレーティングシステム１３０を含む。クライアントコンピュータ１０４は、１または複数のアプリケーションプログラム、またはプロセッサ１２６によって制御される（１または複数の）アプリケーション１３２を含む。特に、（１または複数の）アプリケーション１３２は、サーバーコンピュータ１０２から受け取ったグラフィックスイメージ、オブジェクト、および／またはビットマップを処理するアプリケーションを含む。特に、グラフィックスイメージ、オブジェクト、および／またはビットマップは、アプリケーション１３２によって、ＤＬＬ（dynamic link library）１３６内のルーチンまたはドライバにアクセスする（１または複数の）アプリケーションプログラムインターフェース１３４を通じて、受け取られる。固有のアプリケーションプログラムインターフェースは、以前から存在する「ｂｉｔ  ｂｌｏｃｋ」規則およびプロトコルに基づいて、「ｂｉｔ  ｂｌｏｃｋ」型のインターフェースである可能性があり、ここでは、そのようなインターフェースは、再構築されたビットマップデータ（すなわち、グラフィックスイメージ、オブジェクト、ビットマップ）を、対応するメタデータとともに（１または複数の）アプリケーション１３２に受け渡すために用いられる。ＤＬＬ１３６のルーチンまたはドライバは、特に、グラフィックスデータまたは情報を、アプリケーション１３２からオペレーティングシステム１３０に受け渡すために用いられる。
【００１７】
クライアントコンピュータ１０４は、デコーダ１３８を含む。デコーダ１３８は、データまたはグラフィックスストリーム内にあるかもしれないが、ないかもしれないスーパービットブロック（すなわち、グラフィックスイメージ、オブジェクト、および／またはビットマップ）などの受け取ったＰＤＵを解凍することができる。デコーダ１３８の他の機能は、受け取ったグラフィックスイメージ、オブジェクト、および／またはビットマップを、特定の通信プロトコル（例えば、ＲＤＰ）および／または伝送プロトコル（例えば、ＴＣＰ／ＩＰ）に基づいてデコードすることを、含むことができる。
【００１８】
固有のケースでは、スーパービットブロックなどの受け取ったオブジェクトは、クライアントコンピュータ１０４で再構築される離散オブジェクトの代わりにストリームとして取り扱うことができる。例示的な実装においては、デコーダ１３８は、グラフィックスイメージ、オブジェクト、および／またはビットマップを記述するスーパービット１２０を含むデータストリームまたはグラフィックスストリームのデコード状態のトラックを保つために用いることができる。グラフィックスストリームのデコード状態をトラッキングすることにより、グラフィックスストリームは、割り込みをされる可能性があり、クライアントコンピュータ１０４は、割り込みが生じる場合に継続すべき場所を知る。固有の実装は、デコーダ１３８を、受け取ったデータ（例えば、グラフィックスストリーム内のスーパービットブロック）のコンテキストを明示的に格納する状態マシンとして提供することである。別の実装においては、デコーダ１３８は、デコーダ１３８がグラフィックスストリームから読み込むように、セパレートスレッドでサーバー１０２に対して稼動する。デコーダ１３８が、さらなるデータ（例えば、スーパービットブロック）のために待つ必要がある場合、デコーダ１３８は、「中断」される。中断されると、デコーダ１３８の状態は、暗黙的に、デコーダ１３８が稼動するセパレートスレッドのスレッドスタックに保存される。言い換えると、デコーダ１３８は中断されるが、デコーダ１３８がアンブロックになる（すなわち、中断されなくなる）場合に継続すべき場所を知っているように、デコーダ１３８の状態は、暗黙的にデコーダスレッドのスタックに固定される。
【００１９】
再構築バッファ１４０は、クライアントコンピュータ１０４内に含むことができる。再構築バッファ１４０は、特に、（１または複数の）アプリケーションインターフェース内のアプリケーションプログラムインターフェース１３４の受け渡しに先立ち、スーパービットブロック（すなわち、グラフィックスイメージ、オブジェクト、および／またはビットマップ）のより小さなピースを格納する。スーパービットブロックが小さなピースに分けられることを特徴とする特定の実装においては、再構築バッファ１４０は、クライアントコンピュータ１０４に含まれない。ある実装においては、セパレートバッファ（図示せず）は、クライアントコンピュータ１０４によるさらなる処理の前に、スーパービットブロック（すなわち、グラフィックスイメージ、オブジェクト、および／またはビットマップ）を一時的に格納するために用いることができる。
【００２０】
上述したように、クライアントコンピュータ１０４は、ＲＤＰなどの通信プロトコルを実装することができ、ＲＤＰクライアントと呼ぶことができる。ＲＤＰクライアントのように、クライアントコンピュータ１０４は、アプリケーションプログラムインターフェースを通じて、一組のプロトコルデータユニット１４４を含むスーパービットブロック１４２を受け取る。さらに、スーパービットブロック１４２は、すなわち、マルチデータブロックにするスプリットである。スーパービットブロック１４２は、他のプロトコルデータユニット１４４に含まれる可能性がある。特定のグラフィックスイメージ、オブジェクト、またはビットマップを記述するデータ含むスーパービットブロック１４２内のデータは、（１または複数の）アプリケーション１３２によって、ディスプレイ１４６にグラフィックスイメージを生成またはレンダーするために用いることができる。
【００２１】
図２は、マルチフラグメントＰＤＵ２００の例示的なデータブロックの構造を示す。上述したスーパービットブロック１２０は、特に、マルチフラグメントＰＤＵ２００によって実装される。
【００２２】
マルチフラグメントＰＤＵ２００は、どんな固有のサイズであってもよい。しかしながら、リソース（例えば、バッファの受け取り）がクライアントコンピュータ１０４で制限されると、圧縮は、マルチフラグメントＰＤＵ２００をサポートするために必要であるかもしれない。そのようなケースにおいては、クライアントコンピュータ１０４は、サーバーコンピュータ１０２に固有のサイズ制限に関して知らせるかもしれない。例として、マルチフラグメントＰＤＵ２００は、最初は、１または２ＭＢのサイズであってよく、クライアントコンピュータ１０４は、６４ＫＢのみをサポートできる。実装は、スーパービットブロック１２０またはマルチフラグメントＰＤＵ２００をより小さいピースに分解することを伴うことができる。別の実装においては、スーパービットブロック１２０またはマルチフラグメントＰＤＵ２００の全体が送信され、ここでは、スーパービットブロック１２０またはマルチフラグメントＰＤＵ２００の選択的なデータが圧縮され、スーパービットブロック１２０またはマルチフラグメントＰＤＵ２００の全体のサイズを効果的に減少させる。
【００２３】
マルチフラグメントＰＤＵ２００は、ヘッダー２０２、メタデータ２０４、およびペイロードまたはビット２０６を含むことができる。ヘッダー２０２は、色の濃さおよび圧縮型などのビットマップ（または、グラフィックスイメージまたはオブジェクト）に関する情報を含むことができる。さらに、ヘッダー２０２は、後続のメタデータ２０４およびビット２０６のサイズを記述することができる。あるケースにおいては、スーパービットブロック１２０またはマルチフラグメントＰＤＵ２００は、サーバーコンピュータ１０２から、メタデータ２０４の情報のみ（すなわち、ペイロード２０６は送られないか、または空である）とともに伝達または通信することができる。メタデータ２０４は、ペイロード２０６内の情報を対象とする、どの追加情報をも含むことができる。メタデータ２０４内の情報は、特に、クライアントコンピュータ１０４の（１または複数の）アプリケーション１３２によって用いられるアプリケーションレベルのデータを対象とする。メタデータ２０４をペイロード２０６とともに提供することによって、メタデータは、ペイロード２０６と同期を取る。例として、メタデータの同期は、特に、音とディスプレイのアクションの同期を取ること、および安定したフレームレートのビデオの品質を向上させるためのタイミング情報と関連付けることにおいて、有益である。
【００２４】
マルチフラグメントＰＤＵ２００は、最初のフラグメント２０８、次のフラグメント２１０、最後のフラグメント２１２によって表されているように、複数フラグメントに分割することができる。ＲＤＰプロトコルは、更新ＰＤＵメカニズムを提供する。この例においては、更新ＰＤＵメカニズムは、最初のフラグメント２０８、次のフラグメント２１０、最後のフラグメント２１２を含むマルチフラグメントＰＤＵ２００などのマルチフラグメントＰＤＵをサポートするまで拡張される。特に、ＲＤＰなどの通信プロトコルは、プロトコルの下層を通じて、マルチフラグメントＰＤＵを、複数データブロック、または最初のフラグメント２０８、次のフラグメント２１０、最後のフラグメント２１２などの複数フラグメントに分割することが可能である。
【００２５】
マルチフラグメントＰＤＵ２００は、ビットマップなどのどんなリソースを送るためにも用いることができる。言い換えると、マルチフラグメントＰＤＵ２００は、どんな固有のオブジェクトタイプにも制限されない。「最初、次、最後」と識別されるマルチフラグメント２０８、２１０、および２１２を提供することによって、デコーダ層（例えば、デコーダ１３８）は、データをデコーダの上層に受け渡す前に追加フラグメントを受け取るべきかどうかを知っており、デコーダの上層は、ＰＤＵまたはマルチフラグメントＰＤＵ２００内の実在のリソースまたはオブジェクトタイプに関して知っている。
【００２６】
図３は、データストリームと同期を取るアプリケーションレベルのメタデータを送信するプロセス３００を示す。プロセス３００は、サーバーコンピュータ（例えば、サーバーコンピュータ１０２）とクライアントコンピュータ（例えば、クライアントコンピュータ１０４）の間のプロトコルとして実装することができる。プロセス３００は、ハードウェア、ソフトウェア、ファームウェア、またはこれらの組み合わせで実装することができる操作の順序を表す論理フローグラフのブロックの集合として図示される。ソフトウェアのコンテキストにおいては、ブロックは、１または複数のプロセッサによって実行されるときのコンピュータの構造を表し、列挙した操作を行う。フローチャートとして記述されているが、あるブロックは、一斉に、または異なる順序で起こりうることを意図している。
【００２７】
ブロック３０２では、サーバーコンピュータは、グラフィックスイメージに記述され、または関連づけられているオブジェクトまたはビットマップデータを受け取るための、１または複数のクライアントコンピュータ（デバイス）の可用性に関する情報を受け取る。例えば、オブジェクトは、マルチフラグメントＰＤＵ（例えば、マルチフラグメントＰＤＵ２００）として表される。グラフィックスイメージは、アプリケーション、またはサーバーコンピュータで稼動しているアプリケーションプログラムによって、提供することができる。クライアントコンピュータの可用性に加え、サーバーコンピュータは、固有のクライアントコンピュータのリソース機能に関する情報を受け取ることができる。リソース機能は、受け取りバッファおよび再構築バッファを含むクライアントコンピュータのバッファ容量を含むことができる。情報は、データをサーバーコンピュータからクライアントコンピュータに送信するチャネル、またはセパレートチャネルを通じて伝達することができる。
【００２８】
ブロック３０４では、オブジェクトまたはビットマップ、またはオブジェクトまたはビットマップを表すデータ（例えば、マルチフラグメントＰＤＵ）を全体として送信するかどうかの決定が、サーバーコンピュータでなされる。決定の要因は、クライアントコンピュータのリソース機能である。対照的に、オブジェクトまたはビットマップ（データ）は、より小さなピースに分けることができる。より小さなピースは、最終的には、クライアントコンピュータによって受け取られ、再構築される。決定すること、および決定は、クライアントコンピュータのリソース機能に基づくことができる。
【００２９】
ブロック３０６では、ヘッダーおよびメタデータの情報は、オブジェクトまたはビットマップデータに追加される。メタデータは、特に、クライアントコンピュータに常駐するアプリケーションによって用いられることを対象とし、クライアントコンピュータでは、そのようなアプリケーションは、オブジェクトまたはビットマップデータを消費または処理する。メタデータは、さらに、オブジェクトまたはビットマップデータに関して、記述または提供することができる。オブジェクトは、上述の図２で説明したように、複数フラグメントを含むことができるマルチフラグメントＰＤＵによって、表すことができる。特に、複数フラグメントは、順序付けすることができ、特定のフラグメントが配置される順序（例えば、最初、次、および最後）に関する各フラグメントの識別子を含むことができる。
【００３０】
ブロック３０８では、ヘッダー、メタデータ、およびオブジェクトまたはビットマップデータは、図２で説明したマルチフラグメントＰＤＵなどの特定のデータフォーマットに構築することができ、クライアントコンピュータに送信することができる。ヘッダー、メタデータ、およびオブジェクトまたはビットマップデータ（すなわち、マルチフラグメントＰＤＵ、またはスーパービットブロック）は、さらに圧縮し、ＲＤＰなどの特定の通信プロトコル、および／またはＴＣＰ／ＩＰなどの特定の伝送プロトコルに基づいてエンコードすることができる。離散マルチフラグメントＰＤＵまたはスーパービットブロックは、データストリームの作成者（すなわち、アプリケーション）、およびデータストリームの消費者（すなわち、アプリケーション）が存在するように、イントラデバイス（すなわち、同一マシン内のデバイス）と通信するデータストリーム内に含まれるか、またはイントラデバイス（すなわち、同一マシン内のデバイス）と通信するデータストリームデータストリームの一部である可能性がある。
【００３１】
図４は、着信ラージオブジェクトをデータストリームとして取り扱うプロセス４００を示す。プロセス４００は、特に、ビットマップなどのラージオブジェクトを、クライアントコンピュータ（例えば、クライアントコンピュータ１０４）で維持することを対象としている。プロセス４００は、スーパービットブロックのようなオブジェクトを受け取るように、クライアントコンピュータで実装することができる。プロセス４００は、ハードウェア、ソフトウェア、ファームウェア、またはこれらの組み合わせで実装することができる操作の順序を表す論理フローグラフのブロックの集合として図示される。ソフトウェアのコンテキストにおいては、ブロックは、１または複数のプロセッサによって実行されるときのコンピュータ命令を表し、列挙した操作を行う。フローチャートとして記述されているが、あるブロックは、一斉に、または異なる順序で起こりうることを意図している。
【００３２】
ブロック４０２では、クライアントコンピュータは、グラフィックスまたはデータストリーム内で、スーパービットブロックのようなオブジェクトを受け取る。データストリームは、サーバーコンピュータから生じることができ、図１に示した例示的システム１００によって説明されるように、１または複数のネットワーク上で伝送することができる。データストリームは、特定のスレッドまたはチャネルを通じて送信することができる。
【００３３】
クライアントコンピュータのデコーダまたは同様のコンポーネントは、データストリーム内でオブジェクトを受け取り、処理することができる。デコーダが、セパレートスレッド内のデータストリームを、データストリームを通信または送信するスレッドから受け取らない（すなわち、ブロック４０４の「ＮＯ」の枝に従う）場合、特定の実装に対して、ブロック４０６では、デコーダはデータストリームのデコード状態、特にデータストリーム内のオブジェクトのデコード状態をトラッキングすることができる。
【００３４】
ブロック４０８では、状態マシンとして動くデコーダは、コンテキストまたはデータストリーム内で受け取ったオブジェクトのデコード状態を格納することができる。ブロック４１０では、データストリームが割り込まれると（すなわち、デコーダがデータストリームの受け取りを停止すると）、それからデコードは、受け取ったオブジェクトのデコード状態に基づいて、継続することができる。
【００３５】
デコーダが、データストリームが受け取られるセパレートスレッドで稼動する場合（すなわち、ブロック４０４の「ＹＥＳ」の枝に従う場合）、別の実装においては、ブロック４１２では、デコーダは、セパレートスレッドのデータストリームから読み込まれる。
【００３６】
ブロック４１４では、データストリーム内の、さらなる、または追加のデータ／オブジェクトがデコードによって必要とされる場合、デコーダは中断される。ブロック４１６では、デコーダの状態は、保存される。特に、デコーダがセパレートスレッドで稼動する場合、デコーダが中断されると、セパレートスレッドのスレッドスタックは、暗黙的にデコーダの状態を保存する。ブロック４１８では、割り込みが生じると、デコードは、デコーダの状態（スレッドスタックの状態）に基づいて継続することができる。
【００３７】
（結論）
上述した方法およびデバイスは、処理するために、グラフィックイメージのビットマップなどの任意のサイズのオブジェクトを、クライアントデバイスと通信することについて説明する。本発明は、構造上の特徴、および／または方法的な動作に固有の言語で説明されているが、添付の特許請求の範囲に定義される本発明は、説明した固有の特徴、または動作に限定する必要がないことを理解されたい。むしろ、固有の特徴および動作は、特許請求の範囲に記載された発明の例示的な実装形式として開示する。
【図面の簡単な説明】
【００３８】
【図１】クライアントコンピュータがラージオブジェクトのフラグメントを再構築することを可能にする、プロトコルおよびＡＰＩ（application programming interfaces）を組み込むサーバークライアントシステムの図である。
【図２】マルチフラグメントプロトコルのデータユニットの例示的なブロック図である。
【図３】データストリームと同期を取るアプリケーションレベルのメタデータを送信するためのプロセスを図示するフローチャートである。
【図４】着信ラージオブジェクトをデータストリームの一部として取り扱うためのプロセスを図示するフローチャートである。
【図１】
2009506456.tif 000003
【図２】
2009506456.tif 000004
【図３】
2009506456.tif 000005
【図４】
2009506456.tif 000006
【国際調査報告】
2009506456.tif 000007
2009506456.tif 000008