(57)【要約】一実施形態では、或る方法が、リモートデスクトップからのデスクトップＧＵＩの画像をクライアント装置上で表示する。この方法では、クライアント装置上で表示されているデスクトップＧＵＩの画像のフレームを更新するために複数の画像ブロックを受信する。リモートデスクトップはホスト上で実行されている。クライアント装置が、フレーム更新用の１つ以上の欠落画像ブロックが受信されていないと判定し、１つ以上の欠落画像ブロックなしでフレーム更新を行うべきかどうかを判定する。デスクトップＧＵＩのフレーム更新を１つ以上の欠落画像ブロックなしで行うべき場合、クライアント装置は、１つ以上の欠落画像ブロックを使用することなしに、複数の画像ブロックを使用してデスクトップＧＵＩのフレーム更新を行う。
2015529882.tif 000002
【特許請求の範囲】
【請求項１】
リモートデスクトップからのデスクトップ・グラフィカル・ユーザインターフェイス（以下、デスクトップＧＵＩと称する）の画像をクライアント装置上で表示する方法であって、
前記クライアント装置上で表示されている前記デスクトップＧＵＩの画像のフレームを更新するために複数の画像ブロックを受信することであって、前記リモートデスクトップはホスト上で実行されている、前記受信すること、
前記クライアント装置により、前記フレーム更新のために１つ以上の欠落画像ブロックが受信されていないと判定すること、
前記クライアント装置により、前記１つ以上の欠落画像ブロックなしでフレーム更新を行うべきかどうかを判定すること、
前記クライアント装置において表示されている前記デスクトップＧＵＩの前記フレーム更新を前記１つ以上の欠落画像ブロックなしで行うべき場合、前記クライアント装置により、前記１つ以上の欠落画像ブロックを使用することなしに、前記複数の画像ブロックを使用して前記デスクトップＧＵＩの前記フレーム更新を行うこと
を備える、方法。
【請求項２】
前記複数の画像ブロックが複数のパケット内で受信され、方法は更に
パケットシーケンスを受信すること、
シーケンス内の失われた１つ以上のパケットを突き止めることであって、前記１つ以上のパケットは前記１つ以上の欠落画像ブロックを含む、前記突き止めること
を備える、請求項１に記載の方法。
【請求項３】
前記１つ以上の欠落画像ブロックなしで前記フレーム更新を行うべきかどうかを判定することが、
前記１つ以上の欠落画像ブロックが閾値を超えるかどうかを判定すること、
前記閾値を超えていない場合、前記１つ以上の欠落ブロックを使用することなしに、前記複数の画像ブロックを使用して前記デスクトップＧＵＩの前記フレーム更新を行うこと
を含む、請求項１に記載の方法。
【請求項４】
前記１つ以上の欠落画像ブロックが前記閾値を超えるかどうかを判定することが、前記フレーム更新における前記１つ以上の欠落画像ブロックの数が前記閾値を超えるかどうかを判定することを含む、請求項３に記載の方法。
【請求項５】
前記１つ以上の欠落画像ブロックなしで前記フレーム更新を行うべきではない場合、方法は更に、
前記１つ以上の欠落画像ブロックを求める要求を送信すること、
前記１つ以上の欠落画像ブロックの少なくとも一部を受信するまで、前記デスクトップＧＵＩの前記フレーム更新を行うのを待つこと、
前記複数の画像ブロック及び前記１つ以上の欠落ブロックの前記少なくとも一部を使用し、前記クライアント装置において前記デスクトップＧＵＩの前記フレーム更新を行うことを備える、請求項１に記載の方法。
【請求項６】
前記１つ以上の欠落画像ブロックが幾つかのフレーム更新にわたり同様の位置において持続する場合、前記１つ以上の欠落画像ブロックなしで前記フレーム更新を行わない、
請求項１に記載の方法。
【請求項７】
前記１つ以上の欠落画像ブロックなしで前記デスクトップＧＵＩの前記フレーム更新を行うべき場合、方法は更に、
前記１つ以上の欠落画像ブロックが受信されなかったことを知らせる通知を前記リモートデスクトップに送信することであって、前記リモートデスクトップは前記１つ以上の欠落画像ブロックを解析して是正措置を決定する、前記送信することを備える、請求項１に記載の方法。
【請求項８】
前記是正措置として、前記リモートデスクトップから前記１つ以上の欠落画像ブロックを受信することを更に備える、請求項７に記載の方法。
【請求項９】
画像ブロックの不可逆圧縮が行われる場合にのみ、前記１つ以上の欠落画像ブロックなしで前記デスクトップＧＵＩの前記画像が描画される、請求項１に記載の方法。
【請求項１０】
前記画像ブロックを含めるためにウィンドウ又はディクショナリ圧縮方式が使用されている場合、フレームの全ての画像ブロックが受信されている場合にのみ、前記クライアント装置がフレーム更新を行うときに使用されるウィンドウ又はディクショナリからそれぞれのウィンドウ又はディクショナリが減じられる、請求項１に記載の方法。
【請求項１１】
前記複数の画像ブロックの位置情報を示す複数のマーカを受信することであって、前記位置情報は、前記複数の画像ブロックの少なくとも一部に関する前記フレーム更新における位置を示す、前記マーカを受信することを更に備える、請求項１に記載の方法。
【請求項１２】
前記複数の画像ブロックが圧縮ストリーム内にあり、
前記１つ以上の欠落画像ブロックが前記圧縮ストリーム内に散在し、
前記位置情報により、前記クライアント装置が前記圧縮ストリーム内の画像ブロックを前記フレーム更新における位置に再同期することが可能となる、請求項１１に記載の方法。
【請求項１３】
前記複数のマーカが、前記複数の画像ブロックを含む複数のパケット内に、又は前記複数の画像ブロックの何れも含まない別のパケット内に含まれる、請求項１１に記載の方法。
【請求項１４】
クライアント装置上のデスクトップＧＵＩのフレーム更新用のパケットをリモートデスクトップから送信する方法であって、
前記クライアント装置上で表示されている前記デスクトップＧＵＩの画像のフレームを更新するための複数の画像ブロックを決定することであって、前記リモートデスクトップはホスト上で実行されている、前記決定すること、
前記ホストにより、前記複数の画像ブロックを圧縮ストリームへと圧縮することであって、前記圧縮ストリーム内の圧縮された複数の画像ブロックは可変長のものである、前記圧縮すること、
前記ホストにより、前記圧縮ストリームの一部を複数のパケット内に含めること、
前記ホストにより、前記圧縮ストリーム内の圧縮画像ブロックの位置情報を示す複数のマーカを決定すること、
前記ホストにより、前記複数のパケット及び前記複数のマーカを前記クライアント装置に送信することであって、パケット損失が発生した場合、前記クライアント装置は前記複数のマーカを使用し、前記圧縮ストリーム内の圧縮画像ブロックを前記フレーム更新における位置と再同期させる、前記送信すること
を備える、方法。
【請求項１５】
前記複数のマーカにおける１つのマーカを１つのパケットに含めることであって、前記パケット内の前記マーカは、前記パケット内に含まれる圧縮画像ブロックに対するフレーム更新における位置を示す、マーカを含めることを更に備える、請求項１４に記載の方法。
【請求項１６】
各パケットが、各パケット内の圧縮画像ブロックの位置を示すマーカを含む、請求項１５に記載の方法。
【請求項１７】
前記複数のパケットとは別のインデックスパケット内で前記複数のマーカを送信することであって、前記複数のマーカは、圧縮画像ブロックの前記フレーム更新における位置を示し、かつ前記複数のパケットの少なくとも一部に含まれる、前記送信することを更に備える、請求項１５に記載の方法。
【請求項１８】
前記インデックスパケットが複数回送信され、又は高信頼プロトコルによって送信される、請求項１７に記載の方法。
【請求項１９】
クライアント装置上に、デスクトップＧＵＩのリモートデスクトップの画像を表示するための命令を含む非一時的なコンピュータ可読記憶媒体であって、前記命令は、実行されるとき、
前記クライアント装置上で表示されている前記デスクトップＧＵＩの画像のフレームを更新するために複数の画像ブロックを受信することであって、前記リモートデスクトップはホスト上で実行されている、前記受信すること、
フレーム更新用の１つ以上の欠落画像ブロックが受信されていないと判定すること、
前記１つ以上の欠落画像ブロックなしで前記フレーム更新を行うべきかどうかを判定すること、
前記クライアント装置において表示される前記デスクトップＧＵＩの前記フレーム更新を前記１つ以上の欠落画像ブロックなしで行うべき場合、前記１つ以上の欠落画像ブロックを使用することなしに、前記複数の画像ブロックを使用して前記デスクトップＧＵＩの前記フレーム更新を行うこと
を行うためのコンピュータシステムが構成されるように該コンピュータシステムを制御する、非一時的なコンピュータ可読記憶媒体。
【請求項２０】
リモートデスクトップによって生成されるデスクトップＧＵＩのフレーム更新用のパケットをクライアント装置に送信するための命令を含む非一時的なコンピュータ可読記憶媒体であって、前記命令は、実行されるとき、
前記クライアント装置上で表示されている前記デスクトップＧＵＩの画像のフレームを更新するための複数の画像ブロックを決定することであって、前記リモートデスクトップはホスト上で実行されている、前記決定すること、
前記複数の画像ブロックを圧縮ストリームへと圧縮することであって、前記圧縮ストリーム内の圧縮された複数の画像ブロックは可変長のものである、前記圧縮すること、
前記圧縮ストリームの一部を複数のパケット内に含めること、
前記圧縮ストリーム内の圧縮画像ブロックの位置情報を示す複数のマーカを決定すること、
前記複数のパケット及び前記複数のマーカを前記クライアント装置に送信することであって、パケット損失が発生した場合、前記クライアント装置は前記複数のマーカを使用し、前記圧縮ストリーム内の圧縮画像ブロックを前記フレーム更新における位置と再同期させる、前記送信すること
を行うためのコンピュータシステムが構成されるように該コンピュータシステムを制御する、非一時的なコンピュータ可読記憶媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
仮想デスクトップインフラ（ＶＤＩ：ｖｉｒｔｕａｌ  ｄｅｓｋｔｏｐ  ｉｎｆｒａｓｔｒｕｃｔｕｒｅ）とは、利用者のクライアント装置がリモートデスクトップに接続することを可能にするリモートデスクトップ・プロトコル（以下「リモーティング・プロトコル」と呼ぶ）を使用するシステムを指す。「リモートデスクトップ」という用語は、例えば遠隔データセンタ内で、利用者にとって遠隔的に実行されるユーザコンピュータシステム又は仮想マシンのインスタンスを指す。「リモートデスクトップ」という用語は、利用者に提示されるユーザインターフェイスを指すために使用することもできる。リモートデスクトップはホスト上で実行され、ホストはクライアント装置からコマンドを受信し、そのコマンドに基づき、リモートデスクトップのディスプレイの画像をクライアント装置に対して更新する（「ディスプレイ・リモーティング」と呼ぶ）。利用者のクライアント装置上でリモートデスクトップの画像を更新することは、クライアント装置から受信される入力、オペレーティングシステムの動作、及びリモートデスクトップ上で実行されるアプリケーションに基づきリアルタイムであるべきである。
【背景技術】
【０００２】
ディスプレイ・リモーティングのリアルタイムな性質により、リモーティング・プロトコルは、厳しいネットワーク環境がある状態でも優れたユーザエクスペリエンスを提供しなければならない。リモートデスクトップとクライアント装置とが豊富な帯域幅を利用できる高速ローカルエリアネットワーク（ＬＡＮ）によって接続される場合、パケット損失がゼロに近い状態で短い往復遅延がある。この環境では、リモーティング・プロトコルは質の高いユーザエクスペリエンスを提供する。しかし、利用者は必ずしも理想的な環境の中で接続できるわけではない。例えば、利用者は、モバイル環境及び分散環境のうちの少なくとも一方を介し、高遅延、高損失の広域網（ＷＡＮ）上でリモートデスクトップにより頻繁に接続している。一例では、利用者は、中央データセンタ又はクラウド内に収納されたリモートデスクトップに離れた支店から接続することができ、又は利用者は、多くの場合公衆網であり、輻輳していることがある無線ネットワーク（例えばＷｉＦｉ）によって接続しても良い。これらの環境は、質の高いユーザエクスペリエンスを提供する助けにならない可能性がある、高いパケット損失率及び高遅延を含むネットワーク条件の原因となる。
【０００３】
前の世代のリモーティング・プロトコルは、クライアント装置上でデスクトップ・グラフィカル・ユーザインターフェイス（ＧＵＩ：ｇｒａｐｈｉｃａｌ  ｕｓｅｒ  ｉｎｔｅｒｆａｃｅ）の画像を更新するための画像ブロックの搬送を処理するために、伝送制御プロトコル（ＴＣＰ：ｔｒａｎｓｍｉｓｓｉｏｎ  ｃｏｎｔｒｏｌ  ｐｒｏｔｏｃｏｌ）を使用した。ＴＣＰは、クライアント装置への画像ブロックの信頼できる搬送を処理した高信頼プロトコルである。しかし、最近のリモーティング・プロトコルは、ユーザデータグラム・プロトコル（ＵＤＰ：ｕｓｅｒ  ｄａｔａｇｒａｍ  ｐｒｏｔｏｃｏｌ）等の信頼できない他のネットワーク・プロトコルを使用する。この場合、リモーティング・プロトコルは、画像ブロックの高信頼の搬送を確実にすることを担う。
【０００４】
一例では、リモートデスクトップによって生成されたデスクトップＧＵＩの画像を更新するための画像ブロックを一連のパケットが運び得る。ホストからクライアント装置にパケットを送信する過程で、幾つかのパケットが失われ、クライアント装置が更新用の１組の完全な画像ブロックを有さない結果になる場合がある。リモーティング・プロトコルがＵＤＰを活用しても、リモーティング・プロトコルは典型的には失われた全てのデータパケットを再伝送する。その結果、パケット損失が発生した場合、リモーティング・プロトコルは損失パケットの問題を解決するまで、クライアント装置がデスクトップＧＵＩの画像に対する更新を描画するのを阻止する。例えばクライアント装置は、典型的にはパケットが遅延しているのかどうかを判定するために一定期間待ち、パケットが失われたと判定し、パケットが失われたことをリモートデスクトップに知らせ、リモートデスクトップがその損失パケットを再送するのを待つ。
【０００５】
低遅延ネットワークでは、リモートデスクトップは損失パケットを迅速に送ることができ、ユーザエクスペリエンスに悪影響を及ぼさない可能性が最も高い。しかし、高遅延ネットワークでは、問題が解決されるまでクライアント装置が更新を遅らせるので、損失パケットの問題を解決するのにかかる時間がユーザエクスペリエンスに影響を及ぼす場合がある。このことは、クライアント装置がデスクトップＧＵＩの画像を更新するために配信可能な最高速度に影響を与え、それにより、ビデオレンダリング、スクロール操作、ウィンドウドラッグ操作を遅く、こま落ちして表示させること等、ユーザエクスペリエンスに影響を与える。
【発明の概要】
【課題を解決するための手段】
【０００６】
一実施形態では、或る方法が、リモートデスクトップからのデスクトップＧＵＩの画像をクライアント装置上で表示する。この方法では、クライアント装置上で表示されているデスクトップＧＵＩの画像のフレームを更新するために複数の画像ブロックを受信する。リモートデスクトップはホスト上で実行されている。クライアント装置が、フレーム更新用の１つ以上の欠落画像ブロックが受信されていないと判定し、その１つ以上の欠落画像ブロックなしでフレーム更新を行うべきかどうかを判定する。クライアントにおけるデスクトップＧＵＩのフレーム更新を１つ以上の欠落画像ブロックなしで行うべき場合、クライアント装置は、１つ以上の欠落画像ブロックを使用することなしに、複数の画像ブロックを使用してデスクトップＧＵＩのフレーム更新を行う。
【０００７】
一実施形態では、クライアント装置上で表示されているデスクトップＧＵＩの画像のフレームを更新するための複数の画像ブロックをホストが決定する。ホストは、複数の画像ブロックを圧縮ストリームへと圧縮し、圧縮ストリーム内の圧縮された複数の画像ブロックは可変長のものである。圧縮ストリームの一部が複数のパケットに含められる。ホストは、圧縮ストリーム内の圧縮画像ブロックの位置情報を示す複数のマーカも決定し、複数のパケット及び複数のマーカをクライアント装置に送信する。パケット損失が発生した場合、クライアント装置はその複数のマーカを使用し、圧縮ストリーム内の圧縮画像ブロックをフレーム更新における位置と再同期させる。
【０００８】
以下の詳細な説明及び添付図面は、特定の実施形態の性質及び利点をより良く理解できるようにするものである。
【図面の簡単な説明】
【０００９】
【図１】一実施形態による、損失パケットを処理するためのリモートデスクトップ環境の単純化したシステムを示す。
【図２】一実施形態による、フレーム更新を行うための単純化した流れ図を示す。
【図３】一実施形態による、別の圧縮方式を使用してフレーム更新を行う方法の単純化した流れ図を示す。
【図４】一実施形態による、非圧縮ストリームと圧縮ストリームとの間の関係を示す。
【図５Ａ】画像ブロックのフレーム更新シーケンスを示す。
【図５Ｂ】フレーム内の位置に対する、フレーム更新用の復元画像ブロックの関係を示す。
【図６Ａ】一実施形態による、パケットに含まれるマーカを示す。
【図６Ｂ】一実施形態による、インデックスを使用して圧縮ストリームを再同期する一例を示す。
【図７】一実施形態による、ホスト・リモートデスクトップ・マネージャ及びクライアント・リモートデスクトップ・マネージャのより詳細な例を示す。
【発明を実施するための形態】
【００１０】
以下の説明では、特定の実施形態の完全な理解を可能にするために、数多くの例及び具体的詳細を説明目的で記載する。特許請求の範囲によって定める特定の実施形態は、単独で又は以下に記載する他の特徴と組み合わせてこれらの例の中の特徴の一部又は全てを含むことができ、本明細書に記載の特徴及び概念の修正形態及び均等物を更に含むことができる。
【００１１】
図１は、一実施形態による、損失パケットを処理するためのリモートデスクトップ環境の単純化したシステム１００を示す。システム１００は、ネットワーク１０６を介して通信するホスト１０２及びクライアント装置１０４を含む。ホスト１０２及びクライアント装置１０４は、リモーティング・プロトコルを使用し、ホスト１０２上で動作するリモートデスクトップに提供されるデスクトップＧＵＩ（不図示）の画像をクライアント装置１０４において表示する。特定の実施形態を仮想デスクトップインフラ（ＶＤＩ）に関して説明するが、リモートコンピュータ上の情報を更新するシステム等、特定の実施形態は他の環境内で使用されても良い。例えば、クライアント装置１０４は、ディスプレイ１１０上の画像のフレームを更新する。連続したそれぞれの画像は「フレーム」と呼ぶことができ、フレーム更新とは新たな画像を表示することである。並列符号化／復号を可能にし、符号化の効率を改善するために、各フレームは複数の独立した下位要素から成ると見なされ得ることに留意すべきである。或る特定の下位要素が失われることは、デスクトップＧＵＩの画像の大部分に影響することになる。従って、フレームという用語は、フレーム及び下位要素／下位フレーム構造の両方を意味することができる。
【００１２】
一実施形態では、リモートデスクトップ１０８が、ホスト１０２上で実行される仮想マシン（ＶＭ）（不図示）等の仮想環境内でアプリケーションを実行している場合がある。リモートデスクトップ１０８を仮想環境内で実施する方法は当業者なら理解されよう。但し、仮想環境について説明するが、リモートデスクトップ１０８は非仮想環境内で実行されても良い。例えば、コンピュータシステム上で実行されるリモートアプリケーションが、クライアント装置１０４にフレーム更新用の画像データを伝送する他の環境が使用され得る。
【００１３】
ホスト１０２上でリモートデスクトップ１０８を実行すること、及びクライアント装置１０４上でデスクトップＧＵＩの画像を表示することは、表示リモーティングと呼ぶことができる。表示リモーティングでは、クライアント・リモートデスクトップ・マネージャ１１２が、クライアント装置１０４に関連する周辺装置からの入出力（Ｉ／Ｏ）コマンドをリモートデスクトップ１０８に送る。ホスト・リモートデスクトップ・マネージャ１１４は、その入出力コマンドを処理し、フレーム更新用の画像ブロックをクライアント・リモートデスクトップ・マネージャ１１２に送る。次いで、クライアント・リモートデスクトップ・マネージャ１１２が、その画像ブロックを使用してディスプレイ１１０上のデスクトップＧＵＩの画像を更新する。例えば、利用者はマウスを使用してデスクトップＧＵＩ上のウィンドウをドラッグしても良い。クライアント・リモートデスクトップ・マネージャ１１２は動きを検出し、その動きに関する入出力コマンドを送信する。ホスト・リモートデスクトップ・マネージャ１１４がその入出力コマンドを処理し、デスクトップＧＵＩの画像を横切ってウィンドウを移動させる。次いで、ホスト・リモートデスクトップ・マネージャ１１４が、クライアント・リモートデスクトップ・マネージャ１１２にフレーム更新を送り、クライアント・リモートデスクトップ・マネージャ１１２は、ディスプレイ１１０上に表示されているデスクトップＧＵＩの画像を更新して動きを表示する。一部の例では、ウィンドウのドラッグに応答して全デスクトップ画像が更新されるのではなく、この操作の結果デスクトップ画像のどの小領域が変化したのかをリモーティング・プロトコルが突き止め、それらの変化した領域だけを更新する。
【００１４】
一実施形態では、ホスト・リモートデスクトップ・マネージャ１１４がフレーム更新を複数のパケットで送る。各パケットは１組の画像ブロックを含むことができ、各画像ブロックは、ディスプレイ１１０上に表示されるフレーム更新の一部に相当し得る。パケットの全てが受信された場合、クライアント・リモートデスクトップ・マネージャ１１２は画像ブロックを使用し、ディスプレイ１１０上のデスクトップＧＵＩの画像のフレーム更新を行う。
【００１５】
場合によっては、クライアント・リモートデスクトップ・マネージャ１１２がフレーム更新用のパケットの全てを受信できず、このことはフレームを構築するのに必要な画像ブロックの欠落の原因となる。例えパケット損失が生じていても、特定の実施形態では、そのようなフレームの画像ブロックが欠落している可能性があっても、フレーム更新を行うかどうかをクライアント・リモートデスクトップ・マネージャ１１２が知的な方法で決定することが可能となる。例えばリモーティング・プロトコルにより、損失パケットを再伝送する必要なしにクライアント装置１０４がパケット損失を許容することが可能となり、このことによりクライアント装置１０４が欠落した画像ブロックがある状態でフレーム更新を行うことが可能となる。以下でより詳細に説明するように、フレーム更新用の幾つかのパケットが失われているとクライアント・リモートデスクトップ・マネージャ１１２のパフォーマンス・マネージャ１１６が判定する場合、損失パケットの再伝送を要求することなしに、受信済みの画像ブロックを使用して画像を更新すべきことをパフォーマンス・マネージャ１１６がクライアント・リモートデスクトップ・マネージャ１１２に知らせる。これにより、クライアント装置１０４はフレーム更新を遅延なしに表示することができる。パフォーマンス・マネージャ１１６は、パケット損失を考慮してフレーム更新を行うかどうかを判定するとき、優れたユーザエクスペリエンスを提供するために様々な基準を天秤にかけることができる。例えば、フレーム更新が欠落情報を含んでいる可能性があっても、フレーム更新が高頻度の画面更新等の一連の瞬間的な持続時間に対応する場合、欠落画像ブロックはほんの一瞬でその後のフレーム更新によって置換される。従って、利用者はフレーム更新における欠落した画像ブロックに気付かない場合がある。加えて、利用者は、クライアント・リモートデスクトップ・マネージャ１１２が損失パケットの再伝送を待つことによる遅延を一切見ることがない。更に、欠落画像ブロックを無視するのではなく、クライアント・リモートデスクトップ・マネージャ１１２は、フレーム更新における欠落画像ブロックを受信済みの画像ブロックから推定することができ、欠落情報が目立つのを抑えるために欠落画像ブロック内に情報（例えば黒色）を挿入することができ、又は単にそのブロックを前のフレームから変えないままにしておくことができる。
【００１６】
図２は、一実施形態による、フレーム更新を行うための単純化した流れ図２００を示す。２０２で、クライアント・リモートデスクトップ・マネージャ１１２が、デスクトップＧＵＩのフレーム更新用のパケットをホスト・リモートデスクトップ・マネージャ１１４から受信する。各パケットは１組の画像ブロックを含むことができる。２０４で、パケットが欠落しているとパフォーマンス・マネージャ１１６が判定する。例えば、パフォーマンス・マネージャ１１６は、パケットが遅れているのか損失しているのかを判定するために、一定期間待つことができる。その期間が経過した後、パフォーマンス・マネージャ１１６はパケットが失われたと判定する。一実施形態では、ホスト・リモートデスクトップ・マネージャ１１４から送信されるパケットがシーケンス番号を含む。例えば、ＵＤＰ等のネットワーク・プロトコルが各パケット内にシーケンス番号を挿入し、シーケンス内の各パケットを識別する。その後、パフォーマンス・マネージャ１１６は、何からのパケットが失われているかどうかをシーケンス番号に基づいて判定することができる。例えば、パケット１、２、４、５、６、７、８、及び９が受信されている場合、一定期間後、パフォーマンス・マネージャ１１６はパケット＃３が失われていると判断することができる。
【００１７】
２０６で、パフォーマンス・マネージャ１１６は、クライアント・リモートデスクトップ・マネージャ１１２が欠落画像ブロックなしでフレーム更新を行うべきかどうかを判定する。例えば、パフォーマンス・マネージャ１１６は、欠落パケットの欠落画像ブロックが閾値を上回る画像破損を引き起こすかどうかを判定する。画像破損を判定するために、パフォーマンス・マネージャ１１６は、フレーム更新に対する欠落画像ブロックの影響を定量化することができる。例えば、パフォーマンス・マネージャ１１６は、フレーム更新における欠落画像ブロックの最大数／パーセンテージを制限することができる。画像破損（例えば欠落画像ブロックの数）が閾値を下回る場合、パフォーマンス・マネージャ１１６は、欠落画像ブロックなしに画像を表示することを許容し得ると判定する。パフォーマンス・マネージャ１１６は、フレーム更新が高頻度のフレーム更新の一環であるかどうか等、他の基準を考慮することもできる。フレーム更新を行うべき場合、２０８で、クライアント・リモートデスクトップ・マネージャ１１２が、欠落画像ブロックなしに受信パケット内の画像ブロックを使用してフレーム更新を表示する。欠落画像ブロックが実際には単に遅れていることが分かった場合、クライアント・リモートデスクトップ・マネージャ１１２は、任意選択的にそれらの画像ブロックを更新されたフレーム内に挿入することができる。後で到着する任意のブロックを使ってフレームを更新するかどうかの決定は、フレームの更新頻度を含む様々な要因に基づき得る。
【００１８】
破損（例えば欠落画像ブロックの数）が閾値を上回るとパフォーマンス・マネージャ１１６が判定する場合、パフォーマンス・マネージャ１１６は、クライアント・リモートデスクトップ・マネージャ１１２を停止させ、欠落画像ブロックを要求している間はフレーム更新を表示させない。２１０で、クライアント・リモートデスクトップ・マネージャ１１２が、欠落パケットを求める要求をホスト・リモートデスクトップ・マネージャ１１４に送信する。この場合、ホスト・リモートデスクトップ・マネージャ１１４は欠落パケットを再送することができる。２１２で、クライアント・リモートデスクトップ・マネージャ１１２が欠落パケットを受信し、受信したばかりの欠落パケット及び前に受信したパケット内の画像ブロックを使用してフレーム更新を表示する。上記のように、欠落パケットを再伝送することにより遅延が発生する。しかし、クライアント・リモートデスクトップ・マネージャ１１２は、欠落画像ブロックを含まないフレーム更新を行い、そのためより優れた画像を表示する。
【００１９】
クライアント・リモートデスクトップ・マネージャ１１２が欠落画像ブロックなしで画像を表示した場合、パフォーマンス・マネージャ１１６は、パケット損失事象をホスト・リモートデスクトップ・マネージャ１１４に知らせるメッセージを送信することができる。２１０に記載したようにパフォーマンス・マネージャ１１６が欠落パケットを要求する場合、ホスト・リモートデスクトップ・マネージャ１１４は既にパケット損失事象を知らされている。しかし、例え再伝送が要求されている場合でも、クライアント・リモートデスクトップ・マネージャ１１２は、パケット損失をホスト・リモートデスクトップ・マネージャ１１４に知らせるメッセージを追加で送信しても良い。パケット損失事象をリモートデスクトップ１０８に知らせることにより、ホスト・リモートデスクトップ・マネージャ１１４は該当する場合に是正措置を取ることができる。例えば、連続した更新フレーム内の欠落画像ブロックが多くの更新にわたり静的なままである（例えば欠落画像ブロックが同じ位置又は小領域内にある）場合、ホスト・リモートデスクトップ・マネージャ１１４は、フレーム更新と共に表示するための欠落画像ブロックをクライアント・リモートデスクトップ・マネージャ１１２に提供することができる。この場合、ホスト・リモートデスクトップ・マネージャ１１４は、利用者が分かるようになる可能性がある同じ欠落画像ブロックがある状態でクライアント・リモートデスクトップ・マネージャ１１２が複数のフレーム更新を表示することを望まない場合がある。しかし、欠落画像ブロックが一連の高頻度の画面更新に対応する場合、ホスト・リモートデスクトップ・マネージャ１１４が欠落画像ブロックをその後のフレーム更新において置換するので、ホスト・リモートデスクトップ・マネージャ１１４は欠落画像ブロックを無視することができる。ホスト・リモートデスクトップ・マネージャ１１４がパケット損失事象の警告を生成できること等、他の是正措置が取られても良い。更に、損失が高頻度更新の最後のフレームシーケンス（例えば映像の最後のフレーム）に関係する場合、例え要求されていない場合でも、ホスト・リモートデスクトップ・マネージャ１１４は欠落画像ブロックの再伝送を引き起こすことができる。この場合、パフォーマンス・マネージャ１１４は、破損フレームがその後のフレーム更新によって素早く置換されると想定し、破損画像を表示している可能性があるが、映像の終わりということは更新されたフレームが送信されないことを意味する。従って、ホスト・リモートデスクトップ・マネージャ１１４は、欠落画像ブロックを送信することによって破損を解決することができる。或いは、破損の持続時間が当初予想していたよりも長い（即ち、その領域のフレーム更新が一定の閾値を過ぎても受信されない）場合、パフォーマンス・マネージャ１１４自体が再伝送を要求しても良い。
【００２０】
フレーム更新に必要な画像データは、典型的にはリモートデスクトップ１０８において圧縮され、圧縮ストリーム内でクライアント装置１０４に送信される。その後、クライアント・リモートデスクトップ・マネージャ１１２が圧縮ストリームを復元する。場合によっては、或るフレーム（更にはかなりの量のフレーム）の復元が、存在している全てのパケットに依存すべきでない。つまり、クライアント・リモートデスクトップ・マネージャ１１２は、各画像ブロック（又は画像ブロックの小集団）を分離して復元できるべきである。例えば、１組の画像ブロックを含む１つのパケットがフレーム更新で失われた場合、クライアント・リモートデスクトップ・マネージャ１１２は、フレーム更新用の受信パケット内に含まれる他の画像ブロックを引き続き復元できるべきである。クライアント・リモートデスクトップ・マネージャ１１２が他の画像ブロックを復元できない場合、欠落画像ブロックなしでフレーム更新を表示することはできない。一例では、ホスト・リモートデスクトップ・マネージャ１１４が不可逆圧縮を使用する場合、クライアント・リモートデスクトップ・マネージャ１１２が分離して画像ブロックを復元することができる。しかし、フレームの画像ブロックを復元するためにストリームからの全ての画像ブロック（従って全てのパケット）がある必要がある可逆圧縮では、ホスト・リモートデスクトップ・マネージャ１１４はディクショナリ／ウィンドウ方式を使用することができる。人気のあるポータブル・ネットワーク・グラフィックス（ＰＮＧ）のグラフィックス画像形式で使用されるＤＥＦＬＡＴＥ等のかかる可逆圧縮アルゴリズムは良く知られており、そのためその詳細をここで示す必要はない。本明細書に記載の特定の実施形態は、異なる（不可逆及び可逆）圧縮方式に異なるように対処する。
【００２１】
図３は、一実施形態による、別の圧縮方式を使用してフレーム更新を行う方法の単純化した流れ図３００を示す。特定の実施形態では、上記の損失パケット許容方式が使用される場合、リモーティング・プロトコルに以下の調節を行うことができる。３０２で、ホスト・リモートデスクトップ・マネージャ１１４が、使用する圧縮方式を決定する。例えば、圧縮方式が伝送されているデータの種類（例えば映像データ）に依存しても良いこと等、ホスト・リモートデスクトップ・マネージャ１１４はその時々において異なる圧縮方式を使用することができる。
【００２２】
３０４で、不可逆圧縮方式が使用されているのか、ディクショナリ／ウィンドウが使用されているのかをホスト・リモートデスクトップ・マネージャ１１４が判定する。これらの２つの圧縮方式を示すが、他の圧縮方式も認めることができる。一実施形態では、クライアント・リモートデスクトップ・マネージャ１１２は、不可逆圧縮方式が使用されている場合にのみ欠落画像ブロックがある状態でフレーム更新を行うことができる。従って、不可逆圧縮が使用されていない場合、パケット損失が生じたとき、リモーティング・プロトコルは、欠落画像ブロックを求める要求をクライアント・リモートデスクトップ・マネージャ１１２に送信させる。不可逆圧縮が実行される場合にのみ欠落画像ブロックを受信する必要なしにクライアント・リモートデスクトップ・マネージャ１１２がフレーム更新を行えても、これは過度に制限的ではない場合があり、その理由はホスト・リモートデスクトップ・マネージャ１１４が、欠落画像ブロックなしでフレーム更新を表示することを促進する動作で不可逆圧縮を使用できるからである。例えば、映像再生等の高頻度のフレーム更新動作は、大半の場合に不可逆圧縮を使用することができ、欠落画像ブロックが少し経ってその後のフレーム更新において置換され得るので、欠落画像ブロックがある状態でフレーム更新を表示することを促進する。従って、３０６で、ホスト・リモートデスクトップ・マネージャ１１４が不可逆圧縮方式を使用している場合、クライアント・リモートデスクトップ・マネージャ１１２は、上記の制限を受ける欠落画像ブロックなしでフレーム更新を描画する。
【００２３】
ディクショナリ／ウィンドウ圧縮方式が使用されている場合、ディクショナリ又はウィンドウ内で欠落画像ブロックが生じる場合、ディクショナリ又はウィンドウ内の全ての画像ブロックを復元することができない。これは、復元がウィンドウ内の全ての画像ブロックからの情報に依存するからである。従って、３０８で、ホスト・リモートデスクトップ・マネージャ１１４は、損失パケットがフレーム更新のより小さな領域に関する圧縮しか無効化しないように、ディクショナリ又はウィンドウにわたり、より小さな画像の塊を使用することができる。より小さいウィンドウは概してより少ない圧縮しか得られないことを意味するので、より低い圧縮率が結果としてもたらされるため、この場合、実現可能な圧縮が悪影響を受ける可能性がある。しかし利点は、帯域幅の利用が増加することと引き換えに、クライアント・リモートデスクトップ・マネージャ１１２が遅延なしにフレーム更新を表示できるようにすることにより、特定の実施形態がユーザエクスペリエンスを改善することである。更に、ホスト・リモートデスクトップ・マネージャ１１４がディクショナリ／ウィンドウ圧縮方式を使用する場合は大抵、リモーティング・プロトコルが既にフレーム更新を複数の領域に細分している。従って、パケット損失事象によって途絶する領域の大きさを最小限にするために、これらの既存領域が単により小さな小領域に分割される。
【００２４】
特定の実施形態では、ホスト・リモートデスクトップ・マネージャ１１４が送信する画像データの種類に基づき、圧縮方式を切り替えることができる。例えば映像が送信されている場合、３０６に記載されているように、ホスト・リモートデスクトップ・マネージャ１１４は不可逆圧縮を使用し、クライアント・リモートデスクトップ・マネージャ１１２によって損失パケット許容方式が実行されることを可能にし得る。加えて、ホスト・リモートデスクトップ・マネージャ１１４は、損失パケット許容方式とより互換性がある別の圧縮方式に圧縮方式を切り替えることができる。
【００２５】
クライアント・リモートデスクトップ・マネージャ１１２がフレームを更新するために圧縮ストリームを復元し、フレームを正しく再構築するために、クライアント・リモートデスクトップ・マネージャ１１２は、パケットが失われたことにより部分的にしか入手できない圧縮ストリーム内で、画像ブロックの境界を求めなければならない。図４は、一実施形態による、非圧縮ストリーム４０２と圧縮ストリーム４０４との間の関係を示す。非圧縮ストリーム４０２では、画像ブロックの大きさが均一である。例えば、画像ブロック４０６−１〜４０６−ｎは同じ大きさである。しかし、圧縮された場合、圧縮ストリーム４０４は、特定の画像ブロック４０６−１〜４０６−ｎごとに果される圧縮に応じて長さが異なる、圧縮画像ブロック４０８−１〜４０８−ｎを含む。例えば、果される圧縮がより優れている場合、一部の画像ブロック４０６は、より小さい大きさの画像ブロック４０８へと圧縮され得る。見て分かるように、対応する圧縮画像ブロック４０８−１、４０８−２、．．．４０８−ｎの大きさは異なり、画像境界は非圧縮画像ブロック４０６−１、４０６−２、．．．４０６−ｎの画像境界に一致しない。
【００２６】
クライアント・リモートデスクトップ・マネージャ１１２は、圧縮ストリーム４０４を復元し、フレーム内の非圧縮画像ブロックどこに表示するのかを決定する必要がある。パケット損失がない場合、クライアント・リモートデスクトップ・マネージャ１１２がフレームの全圧縮表現を受信すると、クライアント・リモートデスクトップ・マネージャ１１２は、圧縮ストリームを初めから終わりまで構文解析することができる。各記号／単位／塊に出くわすとき、それらが順々に処理される。クライアント・リモートデスクトップ・マネージャ１１２がストリームを初めから終わりまで構文解析するので、クライアント・リモートデスクトップ・マネージャ１１２は、画像ブロックをフレーム内のどこに表示するのかを求めることができる。例えば、圧縮ストリームはフレームの左上の位置から開始し、図５Ａに示すパターンでデータを含み得る。クライアント・リモートデスクトップ・マネージャ１１２が圧縮ストリームを復元すると、クライアント・リモートデスクトップ・マネージャ１１２は、それぞれの復元画像ブロックが、フレーム更新における最後の復元画像ブロックから逐次的に表示されることを知る。しかし、パケット損失が発生する場合、クライアント・リモートデスクトップ・マネージャ１１２は、圧縮ストリームを初めから終わりまで逐次的に処理することができない。むしろ、欠落画像ブロックは復元ストリーム内に存在する。画像ブロックが欠落しているので、クライアント・リモートデスクトップ・マネージャ１１２は、復元ストリーム内の画像ブロックをフレーム内のどこに表示すべきかを求めることができず、その理由は、欠落パケットに直面した後、圧縮画像ブロック４０８の不規則の大きさが原因で、クライアント・リモートデスクトップ・マネージャ１１２が非圧縮ストリーム４０４をフレーム内の位置に再同期できないからである。
【００２７】
図５Ｂに示すように、５０２において、クライアント・リモートデスクトップ・マネージャ１１２が、圧縮ストリーム４０４からフレーム更新用の画像ブロックを復元している。これらの復元画像ブロックは、図示のようにフレーム内の位置に対応し得る。欠落画像ブロックが圧縮ストリーム４０４をもたらすため、クライアント・リモートデスクトップ・マネージャ１１２の画像が損失パケットに直面する。欠落画像ブロックを５０４で概念的に示す。５０６において、クライアント・リモートデスクトップ・マネージャ１１２が、パケット損失後に受信されるパケットから画像ブロックを復元する。しかし、クライアント・リモートデスクトップ・マネージャ１１２は、復元画像ブロックをフレーム内のどこに配置するのかが分からない。圧縮ストリーム４０４内の画像ブロックの可変サイズにより、クライアント・リモートデスクトップ・マネージャ１１２は画像ブロックが何個失われているのかを突き止めることができない。
【００２８】
クライアント・リモートデスクトップ・マネージャ１１２が圧縮ストリーム４０４をフレーム内の或る位置と再同期できるようにするために、特定の実施形態では、クライアント・リモートデスクトップ・マネージャ１１２が復元する画像ブロックの位置情報を、クライアント・リモートデスクトップ・マネージャ１１２が求めることを可能にするマーカを提供することができる。一実施形態では、ホスト・リモートデスクトップ・マネージャ１１４が、圧縮ストリーム４０４を定期的な間隔において一意の記号等のマーカを用いて印付けすることができ、このマーカは、圧縮ストリーム４０４内の不連続性を引き起こすパケット損失の後で、クライアント・リモートデスクトップ・マネージャ１１２が圧縮ストリーム４０４を再同期することを可能にする。マーカの頻度は、パケット損失後にクライアント・リモートデスクトップ・マネージャ１１２がどの程度素早く再同期を行うことができるのかに影響し得る。例えば、パケットが失われると、圧縮ストリーム４０４内の画像ブロックの位置を示すマーカに出くわすまで、クライアント・リモートデスクトップ・マネージャ１１２は如何なる画像ブロックも表示することができない。従って、クライアント・リモートデスクトップ・マネージャ１１２は、例え損失パケット後に幾つかの画像ブロックを受信しても、別のマーカを受信するまでそれらの画像ブロックがフレーム内のどこに表示されるのかが分からない。リモーティング・プロトコルは、素早く再同期したいという願望のバランスを取り、マーカを伝送することによって導入されるオーバヘッドによりフレーム内で無効化される領域を制限することができる。
【００２９】
一例では、図６Ａが、一実施形態による、パケット６０２−１〜６０２−ｎ内に含まれるマーカ６０４−１〜６０４−ｎを示す。一実施形態では、画像ブロックが複数のパケット６０２に及ぶことがないように、ホスト・リモートデスクトップ・マネージャ１１４が、画像ブロックの境界をパケット６０２と整合させることができる。次いで、各パケット６０２のヘッダ又は最初の数バイトの中にマーカ６０４が挿入される。マーカ６０４は、パケット６０２内に含まれる圧縮ブロックの位置情報を含むことができる。例えば、パケット６０２は、フレーム内の圧縮画像ブロックの配置先であるｘ、ｙ座標を含む。一例では、各パケット６０２が、各パケット内の最初の画像ブロックのｘ、ｙ座標を含む。クライアント・リモートデスクトップ・マネージャ１１２は、最初の画像ブロックのｘ、ｙ座標に基づき、パケット６０２内の残りの画像ブロックの位置情報を求めることができる。つまり、最初の画像ブロックがフレームの行又は一片の第１の位置から始まる場合、パケット内の残りの画像ブロックがその行を埋める。他の実施形態では、パケット６０２内の全ての画像ブロックについて等、ｘ、ｙ座標を最初の画像ブロック以外についても含めることができる。
【００３０】
図示のように、送信される各パケット６０２内にマーカ６０４を含めることができる。従って、例えばパケット６０２−２が失われた場合、クライアント・リモートデスクトップ・マネージャ１１２がパケット６０２−３を受信するとき、クライアント・リモートデスクトップ・マネージャ１１２はマーカ６０４−３を用いて圧縮ストリーム４０４をフレーム内の位置に再同期する。例えば、クライアント・リモートデスクトップ・マネージャ１１２は、マーカ６０４−３に基づき、パケット６０４−３内の非圧縮画像ブロックをフレーム内のどこに配置すべきかが分かる。この場合、クライアント・リモートデスクトップ・マネージャ１１２はフレーム内のｘ、ｙ位置を求め、その位置から画像ブロックを逐次的に表示することができる。
【００３１】
画像ブロックの境界をパケットの境界と整列させ、マーカ６０４を含めることによって効率の悪さが生じる場合がある。しかし、こうした効率の悪さは、全帯域幅に対して無視できるほど小さい影響しかない場合がある。但し、クライアント・リモートデスクトップ・マネージャ１１２がパケット損失により素早く再同期することを可能にする利益は、効率の悪さに勝る可能性がある。
【００３２】
図６Ｂは、一実施形態による、インデックスを使用して圧縮ストリーム４０４を再同期する別の例を示す。一実施形態では、ホスト・リモートデスクトップ・マネージャ１１４が各フレームの最初にマーカを含め、そのマーカは、クライアント・リモートデスクトップ・マネージャ１１２が部分的な非圧縮ストリーム４０４を正しく整列させ、再構築することを可能にする。例えばインデックスパケット６０６は、パケット６０８のストリーム内に含められ、フレーム更新用の各パケット６０８−１〜６０８−ｎ内の画像ブロックをどこに配置すべきかを示し得るインデックス情報を含む。一例では、インデックスパケット６０６が、フレームを更新するために送信される各パケット６０８内の最初の画像ブロックの位置情報を示し得る。従って、パケット６０８−２が失われた場合、クライアント・リモートデスクトップ・マネージャ１１２は、インデックスパケット６０６からパケット６０８−３の位置情報を求めることができる。例えば、パケット６０８はシーケンス番号を含むので、クライアント・リモートデスクトップ・マネージャ１１２がパケット６０２−３を受信するとき、クライアント・リモートデスクトップ・マネージャ１１２はパケット６０２−３がシーケンス内の３番目のパケットだと分かる。次いで、クライアント・リモートデスクトップ・マネージャ１１２は、インデックスパケット６０６内の３番目のパケットの位置情報を求める。位置情報を求めると、クライアント・リモートデスクトップ・マネージャ１１２は、位置情報によって示されるフレーム内のｘ、ｙ位置において始まるパケット６０８−３から画像ブロックを表示することができる。
【００３３】
インデックスパケット６０６の重要性を所与として、ホスト・リモートデスクトップ・マネージャ１１４はインデックスパケット６０６を複数回送信することができる。例えば６１０で、ホスト・リモートデスクトップ・マネージャ１１４はインデックスパケット６０６を再送している。更に、クライアント・リモートデスクトップ・マネージャ１１２がインデックスパケット６０６を受信することを確実にする他の方法を使用しても良い。例えば、ＴＣＰ等の高信頼プロトコルを使用してインデックスパケット６０６を送信することができる。但し、ＵＤＰ等の信頼できないプロトコルをそれでもなお使用してパケット６０８を送信しても良い。
【００３４】
図７は、一実施形態による、ホスト・リモートデスクトップ・マネージャ１１４及びクライアント・リモートデスクトップ・マネージャ１１２のより詳細な例を示す。ホスト１０２において、圧縮マネージャ７０２がフレーム更新用の画像ブロックを受信し、その画像ブロックを圧縮ストリームへと圧縮する。パケット送信機７０４が圧縮ストリームを受け取り、クライアント装置１０４に送信されるパケットシーケンス内に圧縮ストリームの一部を含める。
【００３５】
クライアント装置１０４のパケット受信機７０６がパケットを受信する。上記のように、パケットが失われる場合がある。パフォーマンス・マネージャ１１６は欠落パケットを解析し、欠落パケットの欠落画像ブロックなしでフレーム更新を行うべきかどうかを判定する。一方で、パケット受信機７０６はパケット内の圧縮ストリームを抽出し、圧縮ストリームを復元マネージャ７０８に送ることができる。復元マネージャ７０８は、圧縮ストリームを画像ブロックの復元ストリームへと圧縮解除する。
【００３６】
レンダラ７１０は、フレームの更新を行う。上記のように、レンダラ７１０は欠落画像ブロックなしでフレーム更新を行うことができる。この場合、パフォーマンス・マネージャ１１６がレンダラ７１０に信号を送り、レンダラ７１０が欠落画像ブロックなしで更新されたフレームを描画すべきかどうかを知らせても良い。更に、レンダラ７１０は、復元ストリームに加えてマーカも復元マネージャ７０８から受け取ることができる。上記のように復元ストリーム内で画像ブロックが欠落している場合、レンダラ７１０はマーカを使用して画像ブロックを表示する場所を突き止める。次いでレンダラ７１０は、該当する場合は更新されたフレームを表示する。
【００３７】
上記のように欠落パケットが発生する場合、パフォーマンス・マネージャ１１６は、パケット損失を知らせるメッセージをホスト・リモートデスクトップ・マネージャ１１４に送信する。ホスト是正マネージャ７１２が損失パケットを解析し、何らかの是正措置を取るべきかどうかを判定する。例えば、一連のフレーム更新にわたり同じ領域内で欠落画像ブロックが生じた場合、欠落画像ブロックを再送しても良い。
【００３８】
一実施形態では、ホスト・リモートデスクトップ・マネージャ１１４が、パケット損失事象の局所的影響を減らすために高パケット損失期間中のパケットサイズを落とすことができる。例えば、パケット損失が、フレーム更新に関して欠落しているより少数の画像ブロックに影響する。これにより、送信しなければならないパケット数は増え、パケット損失の総数を増やす可能性があるが、その損失はより小さい大きさの、及びことによるとより視覚的に影響を受けないフレーム更新の欠落部分をもたらし得る。
【００３９】
圧縮ストリームをよりモジュール式にすることにより、復元プロセスに更なる並列処理を取り入れることができ、全フレーム又はフレームの一片を受信する前に復元プロセスを開始できるようにもなる。
【００４０】
従って特定の実施形態では、パケットが失われた場合にフレーム更新をどのように処理するのかをクライアント装置１０４が知的な方法で決定することが可能となる。画像ブロックが欠落した状態でクライアント装置１０４がフレームを更新できるようにすることにより、ユーザエクスペリエンスの向上をもたらすことができる。
【００４１】
本明細書に記載した様々な実施形態では、コンピュータシステム内に記憶されるデータを用いる様々なコンピュータによって実施される操作を利用することができる。例えば、これらの操作は物理量の物理的操作を必要とする場合があり、必須ではないが通常、これらの量は電気信号又は磁気信号の形を取ることができ、それらの信号又はそれらの信号の表現は記憶し、転送し、結合し、比較し、又は他の方法で操作することができる。更に、かかる操作はしばしば作成、識別、決定、比較等の用語で呼ばれる。１つ以上の実施形態の一部を形成する本明細書に記載した如何なる操作も、有用な機械操作とすることができる。更に、１つ以上の実施形態は、それらの操作を行うための装置又は機器にも関する。この機器は、特定の所要の目的のために特別に構築することができ、又はコンピュータ内に記憶されるコンピュータプログラムによって選択的に活性化され若しくは構成される汎用コンピュータでも良い。具体的には、本明細書の教示に従って書かれたコンピュータプログラムと共に様々な汎用機械を使用することができ、又は所要の操作を行うためにより特化された機器を構築する方が便利な場合もある。本明細書に記載した様々な実施形態は、携帯端末、マイクロプロセッサシステム、マイクロプロセッサベースの又はプログラム可能な消費者家電、ミニコンピュータ、メインフレームコンピュータ等を含む他のコンピュータシステム構成を使って実施しても良い。
【００４２】
１つ以上の実施形態は、１つ以上の非一時的なコンピュータ可読記憶媒体内に具体化される１つ以上のコンピュータプログラム又は１つ以上のコンピュータプログラムモジュールとして具体化することができる。非一時的なコンピュータ可読記憶媒体という用語は、後でコンピュータシステムに入力可能なデータを記憶することができる任意のデータ記憶装置を指す。非一時的なコンピュータ可読媒体は、コンピュータプログラムがコンピュータによって読み取られることを可能にする方法でコンピュータプログラムを具体化する既存の任意の技術、又は後に開発される技術に基づくことができる。非一時的なコンピュータ可読媒体の例には、ハードドライブ、ネットワーク接続ストレージ（ＮＡＳ）、読取専用メモリ、ランダムアクセスメモリ（例えばフラッシュメモリデバイス）、ＣＤ（コンパクトディスク）、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、ＣＤ−ＲＷ、ＤＶＤ（デジタル多用途ディスク）、磁気テープ、並びに他の光学的及び非光学的データ記憶装置が含まれる。コンピュータ可読コードが分散された方法で記憶され実行されるように、非一時的なコンピュータ可読媒体をネットワークに結合されたコンピュータシステムにわたって分散させることもできる。
【００４３】
加えて、説明した仮想化方法では、慨して、仮想マシンが特定のハードウェアシステムに合ったインターフェイスを示すと仮定したが、記載した方法は或る特定のハードウェアシステムに直接対応しない仮想化と組み合わせて使用しても良いことを当業者なら理解されよう。ホスト型の実施形態、非ホスト型の実施形態、又はその２つの区別を曖昧にする傾向がある実施形態として実装される、様々な実施形態による仮想化システムの全てが想定されている。更に、様々な仮想化操作がハードウェアにより完全に又は部分的に実施されても良い。
【００４４】
仮想化の程度に関係なく、多くの改変、修正、追加、及び改善が可能である。従って仮想化ソフトウェアは、仮想化機能を実行するホスト、コンソール、又はゲストオペレーティングシステムのコンポーネントを含むことができる。単一の例として本明細書に記載したコンポーネント、操作、又は構造について複数の例が提供されても良い。最後に、様々なコンポーネント、操作、及びデータストア間の境界は幾らか恣意的であり、特定の操作を特定の例示的構成との関連で解説した。他の機能の割当ても想定されており、本発明の範囲に含まれ得る。慨して、例示的構成の中で別個のコンポーネントとして提示した構造及び機能は、複合構造又は複合コンポーネントとして実装しても良い。同様に、単一のコンポーネントとして提示した構造及び機能を別個のコンポーネントとして実装しても良い。
【００４５】
上記の説明は、特定の実施形態の態様を実施し得る方法の例と共に様々な実施形態を示す。上記の例及び実施形態は唯一の実施形態と見なされるべきではなく、添付の特許請求の範囲によって定める特定の実施形態の柔軟性及び利点を例示するために示した。上記の開示及び添付の特許請求の範囲に基づき、添付の特許請求の範囲によって定める本発明の範囲から逸脱することなく他の構成、実施形態、実装形態、及び等価物を使用することができる。
【図４】
2015529882.tif 000003
【図５Ａ】
2015529882.tif 000004
【図５Ｂ】
2015529882.tif 000005
【図６Ａ】
2015529882.tif 000006
【図１】
2015529882.tif 000007
【図２】
2015529882.tif 000008
【図３】
2015529882.tif 000009
【図６Ｂ】
2015529882.tif 000010
【図７】
2015529882.tif 000011
【国際調査報告】
2015529882.tif 000012
2015529882.tif 000013