JP5920006B2 - 画面更新制御プログラム、画面更新制御方法、および情報処理装置 - Google Patents

Description

本発明は画面の表示を制御する技術に関する。

ある種のシンクライアントシステムでは、コンピュータの画面の更新を遠隔制御する技術が使われる。例えば、画面の遠隔制御に使われるプロトコルとして、ＲＤＰ（Remote Desktop Protocol）やＲＦＢ（Remote Framebuffer）プロトコルなどのプロトコルが知られている。

例えば、ある種のシンクライアントシステムでは、サーバは、シンクライアントに画面を描画（render）させるためのデータを生成し、生成したデータをシンクライアントに送信する。サーバは、以上のようなデータの生成と送信を繰り返すことにより、シンクライアントの画面の更新を遠隔制御する。

近頃では、コンピュータからの情報の漏洩を防止するという観点や、コンピュータの保守にかかるコストを削減するという観点など、いくつかの観点から、シンクライアントシステムが注目されている。シンクライアントシステムの利用は広まりつつあり、シンクライアントシステムに関する研究も様々に行われている。

例えば、シンクライアントの汎用性を維持しつつ、操作レスポンスを向上させることを課題として、以下のような技術が提案されている。
当該技術による情報処理装置は、画像メモリと、変更頻度判別部と、第１の画像送信部と、高頻度変更領域識別部と、送信停止部と、第２の画像送信部とを有する。画像メモリは、コンピュータの実行結果を描画する画像を保持する。変更頻度判別部は、画像メモリに描画された画像を複数の領域に分割し、領域ごとにフレーム間の変更の頻度を判別する。

第１の画像送信部は、変更のある領域の画像を送信する。高頻度変更領域識別部は、変更の頻度が閾値を超えた領域を高頻度更新領域として識別する。送信停止部は、識別した領域について、第１の画像送信部での送信を停止する。第２の画像送信部は、識別した領域の画像を、第１の画像送信部よりも圧縮率の高い動画の圧縮処理を行って送信する。

ところで、画面の更新の遠隔制御はネットワーク通信をともなう。例えば、ある種のシンクライアントシステムでは、シンクライアントの画面の更新を遠隔制御するためのデータを、サーバがネットワークを介してシンクライアントに送る。サーバがデータを送信してからシンクライアントがデータを受信するまでの時間の長さは、ネットワーク状況に依存する。したがって、ネットワーク状況によっては、かなり長い表示遅延が生じ得る。

一方で、ネットワーク状況を把握するための技術も、様々に研究されている。例えば、ネットワーク状況は、具体的にはネットワークの可用帯域幅により表されてもよいし、ネットワーク上の経路のコストにより表されてもよい。可用帯域幅や経路のコストに関して、例えば以下のような技術が提案されている。

ある方法は、ネットワークの可用帯域幅を高速かつ高精度で測定するための方法である。当該方法によれば、複数の周期的なタイムスタンプパケットが、受信側の通信装置へ、現在設定されている試験伝送率で伝送される。そして、受信側の通信装置にタイムスタンプパケットのそれぞれが受信された時刻に基づいて、タイムスタンプパケット間の伝送遅延時間差の変化傾向が検査される。

伝送遅延時間差が、予め定められた安定範囲内に含まれず、かつ増加傾向を示すと、試験伝送率の値を減少させた後に、検査が繰り返される。一方、伝送遅延時間差が安定範囲内に含まれず、かつ減少傾向を示すと、試験伝送率の値を増加させた後に、検査が繰り返される。以上のような処理の結果、伝送遅延時間差が安定範囲内に含まれると、現在設定されている試験伝送率が可用帯域幅として決定される。

また、経路のコストに関連して、次のようなシステムも提案されている。当該システムは、同一ノードに至る複数の経路が存在する場合に、最適な経路を選択するためのシステムである。具体的には、当該システムは、始点ノードから第１ノードを経由して終点ノードへ至る第１経路と、始点ノードから第２ノードを経由して終点ノードへ至る第２経路とを含むマルチノードネットワークにおいて最適な経路を選択するシステムである。当該システムは、記憶手段と経路計測最適化手段を有する。

記憶手段は、リンクコストを記憶する。また、経路計測最適化手段は、第１の経路コストと第２の経路コストとを比較し、コストが低い方の経路を選択することによって経路を最適化する。なお、第１の経路コストは、具体的には、始点ノードコスト、第１リンクコスト、第１ノードコスト、第２リンクコスト、および終点ノードコストに基づいて算出される。また、第２の経路コストは、始点ノードコスト、第３リンクコスト、第２ノードコスト、第４リンクコスト、および終点ノードコストに基づいて算出される。

特開２０１１−２３８０１４号公報 特開２００６−７４７７３号公報 特開２００６−２３７８３７号公報

ある種のシステムでは、第１のコンピュータの画面に表示される画像が、第２のコンピュータにより生成される。この場合、第１のコンピュータに画像を画面上に表示させるための画面情報を、第２のコンピュータが第１のコンピュータに送信する。そして、第１のコンピュータは、画面情報を受信し、画面情報にしたがって画像を画面上に表示する。以上のような画像の生成、画面情報の送信、および画像の表示は、繰り返し行われ得る。

具体的には、第２のコンピュータによる画像の生成は、第１のコンピュータの入力装置を介して第１のコンピュータに与えられた入力に基づく。第１のコンピュータは、入力についての通知を第２のコンピュータに送信し、第２のコンピュータは、通知された入力に応じて、１つ以上のプログラムを実行する。第２のコンピュータは、１つ以上のプログラムの実行に応じて、上記のとおり画像を生成する。

以上のように第１と第２のコンピュータが動作すると、第１のコンピュータのユーザにとっては、次のように認識される。すなわち、ユーザにとっては、ユーザが入力装置を介して第１のコンピュータに与えた入力に応じて、第１のコンピュータの画面が更新されるように認識される。

この場合、ユーザが入力装置を介して第１のコンピュータに入力を与えてから、第１のコンピュータが画面情報に応じて画像を画面上に表示するまでにかかる時間の長さが、ユーザビリティに影響する。当該時間の長さは、第１と第２のコンピュータの間のネットワークの状況に依存する。そこで、ネットワーク状況が悪くてもユーザビリティの低下を抑えるために、ネットワーク状況に応じた何らかの制御が行われることが好ましい。

一方で、仮に、ネットワーク状況に応じた制御のために、ネットワーク状況を把握するための付加的な通信が過剰に行われるとすると、ネットワーク状況が悪化するおそれがある。なぜなら、付加的な通信により、ネットワークの負荷が一層増してしまうからである。そして、ネットワーク状況の悪化は、ユーザビリティの低下を招く。よって、上記のような第１と第２のコンピュータを含むシステムにおけるユーザビリティの観点からは、付加的な通信の量は少ないことが好ましい。

本発明は、１つの側面では、ユーザビリティがネットワーク状況に依存する環境においても、ユーザビリティの低下を抑えることを目的とする。

一態様による画面更新制御プログラムは、第１のコンピュータに、以下に述べる画面更新制御処理を実行させる。
前記画面更新制御処理は、ネットワークを介して前記第１のコンピュータと接続された第２のコンピュータから、画面情報と時刻情報を受信することを含む。

前記第２のコンピュータは、以下のようなコンピュータである。すなわち、前記第２のコンピュータは、前記第１のコンピュータの入力装置を介して前記第１のコンピュータに与えられた入力についての通知を前記第１のコンピュータから受信する。また、前記第２のコンピュータは、前記入力に応じて１つ以上のプログラムを実行する。そして、前記第２のコンピュータは、前記１つ以上のプログラムの実行に応じて、前記第１のコンピュータの画面に表示するための画像を生成する。

前記画面情報は、前記第１のコンピュータに前記画像を前記画面上に表示させるための情報であり、前記時刻情報は、前記画面情報を送信する第１の時刻を示す情報である。前記第２のコンピュータは、前記画面情報を送信するとともに、前記時刻情報を送信する。また、前記第２のコンピュータは、前記第１のコンピュータから通知される値に基づいて、前記画面情報を送信する頻度を調整しながら、前記画像の生成ならびに前記画面情報および前記時刻情報の送信を繰り返す。

そして、前記画面更新制御処理は、前記第１のコンピュータと前記第２のコンピュータとの間の前記ネットワークの可用帯域幅の推定値を、第２の時刻と第３の時刻との差に応じて、増加させるか、維持するか、または、減少させることを含む。ここで、前記第２の時刻は、前記第１のコンピュータが前記画面情報を受信した時刻である。また、前記第３の時刻は、前記推定値と、受信した前記画面情報のサイズと、受信した前記時刻情報により示される前記第１の時刻から、前記第１のコンピュータが前記画面情報を受信するものと推定される時刻である。なお、前記差に応じて前記推定値を減少させる処理は、ある期間内に１回以上受信した前記画面情報それぞれのサイズと前記期間の長さから算出される受信ビットレートに基づく。

前記画面更新制御処理は、少なくとも前記推定値を増加または減少させることで更新した場合には、前記推定値または前記推定値の更新を反映する指標値を前記第２のコンピュータに通知することも含む。

上記の画面更新制御プログラムによれば、ユーザビリティがネットワーク状況に依存する環境においても、ユーザビリティの低下を抑えることができる。

第１実施形態の動作例を示すシーケンス図である。 画面の更新について説明する図である。 第１実施形態の効果を説明する図（その１）である。 第１実施形態の効果を説明する図（その２）である。 ハードウェア構成例を示す図である。 システムのブロック構成図である。 各種データの例を示す図である。 第２実施形態のクライアントの動作フローチャート（その１）である。 第２実施形態のクライアントの動作フローチャート（その２）である。 サーバの動作フローチャート（その１）である。 サーバの動作フローチャート（その２）である。 過剰遅延時間と受信ビットレートの変化の例を示すグラフである。 第３実施形態のクライアントの動作フローチャートである。 第４実施形態のクライアントの動作フローチャートである。

以下、実施形態について、図面を参照しながら詳細に説明する。具体的には、図１〜４を参照して第１実施形態について説明する。次に、図５を参照して、第１〜第４実施形態のいずれにも適用可能なハードウェア構成について説明する。その後、図６〜１２を参照して第２実施形態について説明し、図１３を参照して第３実施形態について説明し、図１４を参照して第４実施形態について説明する。また、いくつかの変形例についても説明する。

図１は、第１実施形態の動作例を示すシーケンス図である。図１には、コンピュータ１０１と、コンピュータ１０２と、ユーザ１０３の動作が例示されている。図１にはステップＳ１０１〜Ｓ１２４が例示されているが、これらのステップについて順に説明する前に、まず、コンピュータ１０１と１０２の動作の概要を説明する。

コンピュータ１０１と１０２はネットワークを介して接続されている。例えば、コンピュータ１０１は、シンクライアントシステムにおけるクライアントであってもよく、コンピュータ１０２はサーバであってもよい。より具体的には、コンピュータ１０２は、シンクライアントシステムにおいて、コンピュータ１０１の画面の更新を遠隔制御するサーバ（換言すれば、リモートデスクトップサービスを提供するサーバ）であってもよい。

例えば、図１のステップＳ１０４、Ｓ１０９、およびＳ１２０に例示するように、コンピュータ１０１には、コンピュータ１０１の入力装置を介して、ユーザ１０３から入力が与えられる。すると、例えばステップＳ１０５、Ｓ１１０、およびＳ１２１に例示するように、コンピュータ１０１は、与えられた入力についての通知をコンピュータ１０２に送信し、コンピュータ１０２は当該通知を受信する。

コンピュータ１０２は、通知された入力に応じて１つ以上のプログラムを実行する。そして、コンピュータ１０２は、それらの１つ以上のプログラムの実行に応じて、コンピュータ１０１の画面に表示するための画像を生成する。

例えば、あるアプリケーションを起動するための入力操作をユーザ１０３が行うと、当該入力操作をコンピュータ１０１がコンピュータ１０２に通知する。よって、コンピュータ１０２は当該アプリケーションの実行を開始する。アプリケーションの実行の開始にともない、例えば、コンピュータ１０２は、あるウィンドウを画面に表示するための処理（つまり、当該ウィンドウを含む画面全体の画像を生成する処理）を行うこともある。

また、起動済みのアプリケーションのウィンドウ上でユーザ１０３が入力操作を行うと、当該入力操作をコンピュータ１０１がコンピュータ１０２に通知する。そして、コンピュータ１０２は、当該アプリケーションの実行の過程において、当該入力操作に応じた処理を実行する。

例えば、テキストエディタがフォアグラウンドで実行されている状況において、ユーザがキー入力操作を行う場合がある。この場合、コンピュータ１０２は、コンピュータ１０１からの通知に応じて、テキストエディタのウィンドウ内のカーソル位置に文字を表示させるための処理（つまり、カーソル位置に新たに文字が追加されているような画像を生成する処理）を実行する。

起動済みのアプリケーションの種類によっては、コンピュータ１０１からの入力の通知がない間は、コンピュータ１０２は、当該アプリケーションの実行をサスペンドしてもよい。もちろん、コンピュータ１０２は、コンピュータ１０１から入力の通知がなくても、プログラムの実行を続行する場合もある。

例えば、動画像を視聴するためのメディアプレイヤが起動されている場合、ユーザ１０３が再生ボタンをクリックすると、クリック操作がコンピュータ１０１からコンピュータ１０２に通知される。すると、コンピュータ１０２は、動画像を再生するために、メディアプレイヤのウィンドウ内を更新するための処理を開始する。ユーザ１０３が再生ボタンをクリックした後、仮に何も操作を行わないとしても、コンピュータ１０２は、メディアプレイヤのウィンドウ内を更新し続ける。また、例えば、画面上に時刻を表示する機能をＯＳ（Operating System）が提供する場合、コンピュータ１０２は、時間の経過に応じて画面上の時刻表示を更新する処理を、入力の通知とは関係なく行ってもよい。

コンピュータ１０２は、例えば上記に例示したようにして１つ以上のプログラムを実行し、それらの１つ以上のプログラムの実行に応じて、コンピュータ１０１の画面に表示するための画像を繰り返し生成する。例えば、コンピュータ１０１の画面の解像度が１２８０×１０２４画素の場合、コンピュータ１０２は、１２８０×１０２４画素の画像を繰り返し生成する。

そして、コンピュータ１０２は、生成した画像をコンピュータ１０１の画面上に表示させるための情報（以下、便宜上「画面情報」という）をコンピュータ１０１に送信する。コンピュータ１０２は、さらに、コンピュータ１０２が画面情報をコンピュータ１０１に送信する第１の時刻を示す時刻情報も、コンピュータ１０１に送信する。

コンピュータ１０２は、画面情報と時刻情報を１つのパケットに含めてもよい。図１の例では、ステップＳ１０１、Ｓ１０６、Ｓ１１１、Ｓ１１４、Ｓ１１７、およびＳ１２２において、コンピュータ１０２がコンピュータ１０１に画面情報と時刻情報を送信する。

また、コンピュータ１０１は、画面情報を受信すると、画面情報にしたがって画面を更新する。例えば、図１の例では、コンピュータ１０１が、ステップＳ１０２、Ｓ１０７、Ｓ１１２、Ｓ１１５、Ｓ１１８、およびＳ１２３において、受信した画面情報にしたがって画面を更新する。

なお、画面情報の具体的な形式は、実施形態に応じて様々であってよい。以下に、画面情報の形式の例を３つ挙げる。

第１の形式は、画面の少なくとも一部を更新するためのコマンドを１つ以上含む形式である。例えば、第１の形式の画面情報には、以下の（１ａ）〜（１ｃ）のようなコマンドが１つ以上含まれていてもよい。

（１ａ）ある点からある点へ線を引くよう命じるコマンドなど、ベクタオブジェクトの描画のためのコマンド。
（１ｂ）ある特定の座標に、ある特定の文字を、ある特定のフォントで、表示するよう命じるコマンド。
（１ｃ）画面内のある特定の領域を、ある静止画像に置き換えるよう命じるコマンド。

第１の形式の画面情報が使われる実施形態においては、コンピュータ１０１は、画面情報を受信すると、画面情報に含まれるコマンドにしたがって画面を更新する。

第２の形式は、コンピュータ１０１の画面全体を、動画像用の圧縮アルゴリズムにしたがって圧縮したデータを含む形式である。例えば、３０ｆｐｓ（frames per second）というフレームレートでコンピュータ１０１の画面を更新するために、３０ｆｐｓというフレームレートの動画像のデータが、画面情報として送信されてもよい。例えば、ＭＰＥＧ（Moving Picture Expert Group）形式などのデータ形式が利用可能である。

第２の形式の画面情報が使われる実施形態においては、コンピュータ１０１は、画面情報を受信すると、画面情報に含まれる圧縮された動画像データをデコードし、フレーム画像を画面に表示する。コンピュータ１０１は、次々にフレーム画像を画面に表示することにより、画面を更新する。

第３の形式は、以下に詳しく説明するとおり、第１の形式と第２の形式のハイブリッド形式である。第３の形式には、画面の更新が高頻度で生じても遅延の累積を防げるという効果と、コンピュータ１０２における圧縮処理の負荷を減らす効果がある。よって、画面情報は、第３の形式で送信されることが好ましい。

例えば、メディアプレイヤが利用されて動画像が再生される場合など、画面の更新が高頻度で生じる場合がある。画面の更新が高頻度で生じる場合、第１の形式では、ある程度大きなサイズの画面情報が、高頻度でコンピュータ１０２からコンピュータ１０１へ送信されることになる。

すると、コンピュータ１０１と１０２の間の可用帯域幅によっては、コンピュータ１０２からコンピュータ１０１への経路上（例えば、コンピュータ１０２内の送信バッファや、経路上のルータ内のバッファなど）に画面情報が滞留してしまうことがある。その結果、遅延時間が次第に長くなってゆき、ユーザビリティが低下してしまうおそれがある。

他方、第２の形式では、動画像用の圧縮アルゴリズムが使われる。動画像の圧縮では、フレーム間予測や動き補償などが行われる。そのため、画面の更新が高頻度で生じる場合、第２の形式の方が第１の形式よりもデータ量が少なくて済むことがほとんどである。よって、第２の形式が使われる場合、上記のような遅延の累積のおそれはあまりない。

ところが、動画像の圧縮は比較的高負荷の処理である。よって、例えば、多数のクライアントの画面を１台のサーバが遠隔制御するシステムにおいて第２の形式が使われると、サーバの負荷が非常に高くなる場合があり得る。換言すれば、コンピュータ１０１と同様の多数のコンピュータの画面を１台のコンピュータ１０２が遠隔制御するシステムにおいて第２の形式が使われると、コンピュータ１０２の負荷が非常に高くなる場合があり得る。

高負荷に対処するため、コンピュータ１０２には、動画像の圧縮用の専用ハードウェア回路（例えばＡＳＩＣ（Application-Specific Integrated Circuit）など）が設けられてもよい。しかし、専用ハードウェア回路をコンピュータ１０２に設けることは、コンピュータ１０２の製造コストの増加につながるので、あまり好ましくない。

そこで、遅延の累積を防ぎつつ、コンピュータ１０２の処理負荷の軽減を図るために、第１の形式と第２の形式を適宜に組み合わせたハイブリッド形式である第３の形式が使われてもよい。第３の形式が使われる場合、具体的には、第１の形式と第２の形式は次のように組み合わされてもよい。

画面内において高頻度で更新が生じる領域には、第２の形式が適用される。それにより、遅延の累積を防ぐことができる。

他方、更新の頻度が低い領域には、第１の形式が適用される。つまり、第２の形式を適用する範囲が限定される。多くの場合、画面上の小さな範囲を占める動画像を圧縮する処理は、画面上の大きな範囲を占める動画像を圧縮する処理よりも負荷が低い。よって、第２の形式を適用する範囲を限定することで、コンピュータ１０２の負荷を軽減することができる。

動画像の圧縮の負荷がそれほど高くない場合、コンピュータ１０２は、圧縮用の専用ハードウェア回路なしでも、汎用のプロセッサによって、十分、動画像の圧縮に対処することができる。したがって、第２の形式を適用する範囲を限定することは、コンピュータ１０２の製造コストの増加を回避することにもつながる。

以上のように、第３の形式は、更新が発生する頻度に応じて第１の形式と第２の形式を組み合わせた形式である。ここで、第３の形式の画面情報のより具体的な例について説明するため、図２を参照する。図２は、画面の更新について説明する図である。

図２に示すように、画面１１０は、横方向にＨ個に分割され、縦方向にＶ個に分割されてもよい。この場合、画面１１０は合計でＶ×Ｈ個のブロックを含む。図２の例ではＶ＝６かつＨ＝８であるが、２≦Ｖかつ２≦Ｈであれば、ＶとＨの値は任意である。

図２には、参照の便宜上、横方向のｈ軸と縦方向のｖ軸が示されている。また、図２には、各ブロックを参照するための、ｈ軸方向のインデックス番号とｖ軸方向のインデックス番号も示されている。以下では、２つのインデックス番号を使って、例えば「ブロック（１，２）」などと表記することがある。

図２の例は、具体的には、第１の時点の画面１１０と、第１の時点より後の第２の時点の画面１１０とを比較すると、以下の（２ａ）〜（２ｃ）に示す領域１１１〜１１３で変更が検出される場合の例である。

（２ａ）ブロック（４，１）とブロック（５，１）とブロック（６，１）とブロック（４，２）とブロック（５，２）とブロック（６，２）とブロック（４，３）とブロック（５，３）とブロック（６，３）からなる領域１１１。
（２ｂ）ブロック（１，２）からなる領域１１２。
（２ｃ）ブロック（７，５）からなる領域１１３。

説明の便宜上、第１の時点よりも前のある時点を「第３の時点」といい、以下の（３ａ）〜（３ｃ）のように仮定する。

（３ａ）第３の時点から第２の時点までの間の期間において、領域１１１では高頻度で変更が生じている。例えば、領域１１１に含まれるどのブロックにおいても、当該期間中には、ある閾値以上の回数の変更が生じている。
（３ｂ）第３の時点から第２の時点までの期間において、領域１１２で変更が生じた頻度は低い。例えば、ブロック（１，２）において当該期間中に生じた変更の回数は上記閾値未満である。
（３ｃ）第３の時点から第２の時点までの期間において、領域１１３で変更が生じた頻度は低い。例えば、ブロック（７，５）において当該期間中に生じた変更の回数は上記閾値未満である。

図２では、第１の時点から第２の時点までに変更が生じていないブロックを白で示している。また、図２では、第１の時点から第２の時点までに変更が生じているが上記期間中での変更頻度が低いブロックは網点パターンで示している。そして、図２では、第１の時点から第２の時点までに変更が生じており、かつ上記期間中での変更頻度が高いブロックは斜線パターンで示している。

上記の（３ａ）〜（３ｃ）の仮定のもとでは、領域１１１に第２の形式が適用され、領域１１２と１１３には第１の形式が適用される。より具体的には、第２の時点の画面１１０をコンピュータ１０１に表示させるための第３の形式の画面情報は、以下の（４ａ）〜（４ｃ）のデータを含んでもよい。

（４ａ）動画像用の圧縮アルゴリズムにしたがって領域１１１を圧縮したデータであって、第２の時点の領域１１１をフレーム画像（例えば１枚のピクチャ）として含むデータ。
（４ｂ）第２の時点の領域１１２の静止画像のデータ。
（４ｃ）第２の時点の領域１１３の静止画像のデータ。

もちろん、領域１１２と１１３に関しては、（４ｂ）と（４ｃ）の静止画像のデータの代わりに、ベクタオブジェクトまたは文字を表示するためのコマンドが使われてもよい。

なお、第２の形式の適用対象の領域を矩形に整えるために、第１の時点から第２の時点までの間に変更が生じていないブロック、または第３の時点から第２の時点までの期間における変更頻度が低いブロックが、第２の形式の適用対象に含められてもよい。例えば、図２の例では、領域１１１が９個のブロックを含むが、９個のブロックでの変更頻度が同じであるとは限らない。例えば、以下の（５ａ）と（５ｂ）がともに成り立つような場合もあり得る。

（５ａ）ブロック（６，１）では、第１の時点から第２の時点までの間に変更が生じていない。または、ブロック（６，１）では、第１の時点から第２の時点までの間に変更が生じているが、第３の時点から第２の時点までの期間における変更頻度が低い。
（５ｂ）残りの８つのブロックでは、第１の時点から第２の時点までの間に変更が生じており、しかも、第３の時点から第２の時点までの期間における変更頻度が高い。

上記の（５ａ）と（５ｂ）がともに成り立つ場合、コンピュータ１０２は、（５ｂ）に述べた８つのブロックにブロック（６，１）を加えることにより、第２の形式の適用対象の領域を矩形に整えてもよい。そして、コンピュータ１０２は、矩形の領域１１１に対して、動画像の圧縮アルゴリズムによる圧縮を適用してもよい。

以上のように、画面情報は、第１の形式と第２の形式を変更頻度に応じて適宜に組み合わせた第３の形式であることが好ましい。しかし、画面情報は、第１の形式または第２の形式であってもよい。

ところで、画面情報がいずれの形式であっても、第１実施形態においては、コンピュータ１０２が、コンピュータ１０１から通知される値に基づく頻度で画面情報を送信する。つまり、第１実施形態では、コンピュータ１０１は、コンピュータ１０２に通知する値を決めることにより、コンピュータ１０２が画面情報を送信する頻度を間接的に制御することができる。

ここで、コンピュータ１０２が画面情報を送信する頻度を制御することは、換言すれば、単位時間当たりにコンピュータ１０２からコンピュータ１０１に送信される画面情報の量を制御することである。したがって、コンピュータ１０１は、コンピュータ１０２に通知する値をネットワークの状況に応じて適切に決めることにより、通信トラフィックの量をネットワークの状況に応じて制御することができる。

具体的には、第１実施形態では、コンピュータ１０１は、コンピュータ１０１と１０２との間のネットワークの可用帯域幅の推定値、または、推定値の更新を反映する指標値を、コンピュータ１０２に通知する。そして、コンピュータ１０２は、通知された推定値または指標値に基づく頻度で、画面情報を送信する。

コンピュータ１０１は、状況に応じて、可用帯域幅の推定値を決定する。
例えば、コンピュータ１０１は、最初に画面情報を受信したときに、可用帯域幅の推定値を初期化してもよい。より具体的には、コンピュータ１０１は、最初に画面情報を受信したときに、以下の（６ａ）と（６ｂ）の値を用いて受信ビットレートを算出し、受信ビットレートを可用帯域幅の推定値の初期値として用いてもよい。

（６ａ）最初の画面情報をコンピュータ１０１が受信した時刻と、最初の画面情報に対応する時刻情報が示す時刻（つまり最初の画面情報をコンピュータ１０２が送信した時刻）との差。
（６ｂ）最初の画面情報のサイズ。

また、コンピュータ１０１は、２回目以降に画面情報を受信したときに、下記の（７ａ）の時刻と（７ｂ）の時刻の差に応じて、可用帯域幅の推定値を、増加させるか、維持するか、または減少させる。

（７ａ）コンピュータ１０１が画面情報を実際に受信した時刻。
（７ｂ）コンピュータ１０１が画面情報を受信するものと推定される（estimated）時刻。

換言すれば、画面情報の送信から受信までに実際にかかる時間と、画面情報の送信から受信までにかかると推定される時間との差に応じて、コンピュータ１０１は、可用帯域幅の推定値を、増加させるか、維持するか、または減少させる。

上記（７ａ）の時刻はネットワーク状況に依存する。また、可用帯域幅の推定値がどの程度良くネットワーク状況を反映しているかに応じて、（７ａ）の時刻と（７ｂ）の時刻の差も変動する。よって、（７ａ）の時刻と（７ｂ）の時刻の差に応じて可用帯域幅の推定値を決めることは、換言すれば、ネットワーク状況に応じて可用帯域幅の推定値を決めることである。

なお、上記（７ｂ）の時刻は、具体的には、以下の（８ａ）〜（８ｃ）の値から推定される時刻である。

（８ａ）可用帯域幅の現在の推定値。
（８ｂ）コンピュータ１０１が受信した画面情報のサイズ。
（８ｃ）当該画面情報に対応する時刻情報により示される時刻。すなわち、当該画面情報がコンピュータ１０２から送信された時刻。

例えば、上記の（７ａ）の時刻と（７ｂ）の時刻の差が正の第１の閾値より大きい場合、コンピュータ１０１は、可用帯域幅の推定値を減少させてもよい。なぜなら、推定される受信時刻よりも実際の受信時刻が大幅に遅い場合、可用帯域幅が過大に推定されている可能性が高いからである。よって、この場合、コンピュータ１０１は、可用帯域幅の推定値を減少させてもよい。

また、第１の閾値未満の適宜の値が、第２の閾値として定められているものとする。上記の（７ａ）の時刻と（７ｂ）の時刻の差が、第２の閾値以下の場合、可用帯域幅が過小に推定されている可能性がある。よって、この場合、コンピュータ１０１は、可用帯域幅の推定値を増加させてもよい。第２の閾値は、より具体的には、０または負であることが好ましい。

そして、上記の（７ａ）の時刻と（７ｂ）の時刻の差が、第２の閾値より大きく第１の閾値以下の場合は、コンピュータ１０１は、可用帯域幅の推定値を維持してもよい。
なお、コンピュータ１０１は、可用帯域幅の推定値を減少させる場合には、具体的には、以下の（９ａ）と（９ｂ）の値から算出される受信ビットレートに基づいて、可用帯域幅の推定値を減少させる。

（９ａ）ある期間内にコンピュータ１０１が１回以上受信した画面情報それぞれのサイズ。
（９ｂ）上記期間の長さ。

コンピュータ１０１と１０２の間のポイント・ツー・ポイントの実際の可用帯域幅を正確に観測することは困難である。しかし、ある期間における実際の可用帯域幅の平均値は、少なくとも、当該期間における平均受信ビットレート以上である。よって、コンピュータ１０１は、当該期間における可用帯域幅の下限値として、当該期間における実際の平均受信ビットレートを利用してもよい。具体的には、コンピュータ１０１は、上記のように受信ビットレートに基づいて推定値を減少させることが好ましい。

他方、コンピュータ１０１は、可用帯域幅の推定値を増加させる場合は、例えば、推定値を所定の割合で増加させてもよい。あるいは、コンピュータ１０１は、推定値に所定の値を足すことにより、推定値を増加させてもよい。

また、以下の（１０ａ）〜（１０ｃ）の値から算出される直近の受信ビットレートが、ある程度大きい場合、コンピュータ１０１は、直近の受信ビットレートに応じて可用帯域幅の推定値を増加させてもよい。

（１０ａ）コンピュータ１０１が直近に受信した画面情報に関しての時刻情報により示される送信時刻。
（１０ｂ）コンピュータ１０１が直近に画面情報を受信した時刻。
（１０ｃ）コンピュータ１０１が直近に受信した画面情報のサイズ。

例えば、可用帯域幅の推定値に基づいて、推定値よりも大きな判定基準値が定められていてもよい。例えば、１より大きい定数を使って、判定基準値が、現在の推定値の定数倍と定められていてもよい。直近の受信ビットレートが判定基準値よりも大きい場合、実際の可用帯域幅が最近急増した可能性がある。また、直近の受信ビットレートは、直近の可用帯域幅の下限値と見なせる。

よって、コンピュータ１０１は、（７ａ）の時刻と（７ｂ）の時刻の差とは関係なく、直近の受信ビットレートに応じて可用帯域幅の推定値を増加させてもよい。もちろん、コンピュータ１０１は、（７ａ）の時刻と（７ｂ）の時刻の差と、直近の受信ビットレートの双方を考慮に入れて、可用帯域幅の推定値を増加させてもよい。

コンピュータ１０１は、少なくとも可用帯域幅の推定値を増加または減少させることで更新した場合には、推定値または推定値の更新を反映する指標値をコンピュータ１０２に通知する。指標値は、例えば、更新後の推定値と更新前の推定値の差分を示す値でもよい。

例えば、図２の例では、ステップＳ１０３、Ｓ１０８、Ｓ１１３、Ｓ１１６、Ｓ１１９、およびＳ１２４に示すように、コンピュータ１０１は、画面情報と時刻情報を受信するたびに、推定値をコンピュータ１０２に通知する。実施形態によっては、コンピュータ１０１は、推定値を維持する場合には、推定値をコンピュータ１０２に通知しなくてもよい。

また、コンピュータ１０１は、推定値を増加させた場合に、推定値の増加を強調して示す指標値をコンピュータ１０２に通知してもよい。例えば、コンピュータ１０１は、増加させた推定値よりもさらに大きく指標値を定めて、指標値をコンピュータ１０２に通知してもよい。

実施形態によっては、コンピュータ１０１は、推定値を維持する場合に、推定値自体の代わりに、推定値よりも大きな値をコンピュータ１０２に通知してもよい。例えば、（７ａ）の時刻と（７ｂ）の時刻の差が所定の閾値以下の場合、コンピュータ１０１は、推定値自体は変えずに、推定値よりも大きな値をコンピュータ１０２に通知してもよい。

コンピュータ１０２は、推定値自体をコンピュータ１０１がコンピュータ１０２に通知したのか、それとも推定値とは別の値をコンピュータ１０１がコンピュータ１０２に通知したのかを区別しなくてもよい。コンピュータ１０２は、単に、コンピュータ１０１から通知された値に応じて、画面情報を送信する頻度を調整してもよい。具体的には、コンピュータ１０１から通知される値が大きいほど、コンピュータ１０２は、画面情報を送信する頻度を上げる。ただし、頻度には上限があってもよい。

以上のようにして、第１実施形態によれば、ネットワーク状況を反映する可用帯域幅の推定値に応じて、コンピュータ１０２がコンピュータ１０１に画面情報を送信する頻度が調整される。つまり、第１実施形態では、通信トラフィックの量がネットワークの状況に応じて調整される。よって、過剰な通信トラフィックのせいで遅延が累積する事態は回避される。つまり、遅延が累積することによるユーザビリティの低下は回避される。

また、以上説明したとおり、第１実施形態では、画像（静止画像、動画像、またはその双方）の品質を落とすことで通信トラフィックの量を減らすのではなく、画面情報を送信する頻度を落とすことで通信トラフィックの量を減らすアプローチが採用されている。そのため、個々の瞬間においてコンピュータ１０１の画面に表示される画像の品質は保たれる。画像の品質を保つことは、ユーザビリティの低下を防止する効果がある。

例えば、色深度を減少させたり、圧縮符号化において量子化を粗くしたりするなど、画質を落とすことで通信トラフィックの量の低減を図ることも可能ではある。しかしながら、画質が落ちると、例えば、「コンピュータ１０１の画面に文字がぼやけて表示されるため、ユーザ１０３が文字を読み取れない」などの問題が起きるおそれがある。文字が読み取れないことはユーザビリティの低下に直結する。また、高精細な（high-definition）画像（静止画像、動画像、またはその双方）を扱うアプリケーションをユーザ１０３が使いたい場合も、画質の低下はユーザビリティを大きく損ねる。

したがって、ユーザビリティの観点からは、画質を落とすことは好ましくない。換言すれば、第１実施形態のように頻度の調整により通信トラフィックの量の低減を図るアプローチには、ネットワーク状況が悪くてもユーザビリティの悪化を抑える効果がある。

続いて、コンピュータ１０１と１０２が以上説明したように動作することによって生じ得る具体的な動作シーケンスの例について、図１を参照しながら説明する。

ステップＳ１０１より前の時間は図１では省略されているが、上記のとおりコンピュータ１０２は、コンピュータ１０１からの通知に応じて１つ以上のプログラムを実行しており、コンピュータ１０１の画面に表示するための画像を生成する。そして、ステップＳ１０１でコンピュータ１０２は、生成した画像に基づいて画面情報を生成し、画面情報と時刻情報を送信する。

すると、ステップＳ１０２でコンピュータ１０１は、画面情報にしたがって画面を更新する。また、ステップＳ１０３でコンピュータ１０１は、上記の（８ａ）〜（８ｃ）の値から（７ｂ）の時刻を推定し、（７ａ）の時刻と（７ｂ）の時刻の差に応じて、可用帯域幅の推定値を、増加させるか、維持するか、または減少させる。そして、コンピュータ１０１は、可用帯域幅の推定値をコンピュータ１０２に通知する。

なお、コンピュータ１０１は、ステップＳ１０２とＳ１０３のどちらを先に実行してもよい。以下のステップにおいても、コンピュータ１０１は、画面情報と時刻情報を受信したとき、画面の更新と推定値の通知のどちらを先に実行してもよい。

一方、ユーザ１０３は、コンピュータ１０１の画面の更新とは独立したタイミングで、入力装置を介してコンピュータ１０１に入力を与える。例えば、ステップＳ１０４でユーザ１０３は入力操作を行う。すると、ステップＳ１０５でコンピュータ１０１は、入力操作の内容をコンピュータ１０２に通知する。コンピュータ１０２は、プログラムを実行する過程において、通知された入力に応じて適宜の処理を行う。

また、コンピュータ１０２は、ステップＳ１０３で通知された値に応じた頻度で画面情報をコンピュータ１０１に送信しようとする。具体的には、ステップＳ１０１での送信からある時間Ａ１が経過した後、コンピュータ１０２は、ステップＳ１０６において、コンピュータ１０１の画面に表示するための画像を生成し、画像に基づいて画面情報を生成し、画面情報と時刻情報を送信する。

すると、ステップＳ１０７でコンピュータ１０１は、画面情報にしたがって画面を更新する。また、ステップＳ１０８でコンピュータ１０１は、可用帯域幅の推定値を、増加させるか、維持するか、または減少させる。そして、コンピュータ１０１は、可用帯域幅の推定値をコンピュータ１０２に通知する。

また、ユーザ１０３はステップＳ１０９においても何らかの入力操作を行う。すると、ステップＳ１１０でコンピュータ１０１は、入力操作の内容をコンピュータ１０２に通知する。コンピュータ１０２は、プログラムを実行する過程において、通知された入力に応じて適宜の処理を行う。

コンピュータ１０２は、ステップＳ１０８で通知された値に応じた頻度で画面情報をコンピュータ１０１に送信しようとする。具体的には、ステップＳ１０６での送信からある時間Ａ２が経過した後、コンピュータ１０２は、ステップＳ１１１において、コンピュータ１０１の画面に表示するための画像を生成し、画像に基づいて画面情報を生成し、画面情報と時刻情報を送信する。

すると、ステップＳ１１２でコンピュータ１０１は、画面情報にしたがって画面を更新する。また、ステップＳ１１３でコンピュータ１０１は、可用帯域幅の推定値を、増加させるか、維持するか、または減少させる。

例えば、ステップＳ１１１で今までよりもネットワーク状況が悪化した場合、ステップＳ１１１での画面情報と時刻情報の送信から受信までにかかる時間は、コンピュータ１０１が可用帯域幅の推定値から推定する時間よりも長い。よって、この場合、コンピュータ１０１は、ステップＳ１１３で可用帯域幅の推定値を減少させてもよく、減少させた推定値をコンピュータ１０２に通知してもよい。

コンピュータ１０２は、ステップＳ１１３で通知された値に応じた頻度で画面情報をコンピュータ１０１に送信しようとする。具体的には、ステップＳ１１１での送信からある時間Ａ３が経過した後、コンピュータ１０２は、ステップＳ１１４において、コンピュータ１０１の画面に表示するための画像を生成し、画像に基づいて画面情報を生成し、画面情報と時刻情報を送信する。

例えば上記のように、ステップＳ１１３で今までよりも小さな値がコンピュータ１０１から通知された場合、コンピュータ１０２は、画面情報を送信する頻度を下げる。よって、時間Ａ３は、時間Ａ１やＡ２よりも長い。

さて、コンピュータ１０１は、ステップＳ１１４で送信された画面情報と時刻情報を受信すると、ステップＳ１１５で、画面情報にしたがって画面を更新する。また、ステップＳ１１６でコンピュータ１０１は、可用帯域幅の推定値を、増加させるか、維持するか、または減少させる。そして、コンピュータ１０１は、可用帯域幅の推定値をコンピュータ１０２に通知する。

ところで、ステップＳ１１６の送信からしばらく時間が経った後、ネットワーク状況が好転したとする。ステップＳ１１７でコンピュータ１０２は画面情報と時刻情報を送信するが、当該送信にかかる時間は、ネットワーク状況の好転の結果として、短くて済む。例えば、説明の便宜上、コンピュータ１０１が可用帯域幅の推定値から推定する時間よりも短い時間で、画面情報と時刻情報はコンピュータ１０１に到着したとし、その結果、コンピュータ１０１は推定値を増加させるものとする。

具体的には、コンピュータ１０１はステップＳ１１８で画面情報にしたがって画面を更新し、ステップＳ１１９で上記のように増加させた推定値をコンピュータ１０２に通知する。

また、ユーザ１０３は好きなタイミングで入力操作を行い得るので、例えばステップＳ１２０においてもユーザ１０３から入力装置を介してコンピュータ１０１に入力が与えられる。すると、ステップＳ１２１でコンピュータ１０１は、入力操作の内容をコンピュータ１０２に通知する。コンピュータ１０２は、プログラムを実行する過程において、通知された入力に応じて適宜の処理を行う。

そして、コンピュータ１０２は、ステップＳ１１９で通知された値に応じた頻度で画面情報をコンピュータ１０１に送信しようとする。具体的には、ステップＳ１１７での送信からある時間Ａ４が経過した後、コンピュータ１０２は、ステップＳ１２２において、コンピュータ１０１の画面に表示するための画像を生成し、画像に基づいて画面情報を生成し、画面情報と時刻情報を送信する。

例えば、上記のように、ネットワーク状況が悪かった間にコンピュータ１０１がコンピュータ１０２に通知していた値よりも大きな値をステップＳ１１９でコンピュータ１０１がコンピュータ１０２に通知した場合、コンピュータ１０２は、画面情報を送信する頻度を上げる。よって、時間Ａ４は、時間Ａ３よりも短い。

コンピュータ１０１は、ステップＳ１２２で送信された画面情報と時刻情報を受信すると、ステップＳ１２３で、画面情報にしたがって画面を更新する。また、ステップＳ１２４でコンピュータ１０１は、可用帯域幅の推定値を、増加させるか、維持するか、または減少させる。そして、コンピュータ１０１は、可用帯域幅の推定値をコンピュータ１０２に通知する。

例えば以上例示したステップＳ１０１〜Ｓ１２４のようにして、画面情報の送信頻度はネットワーク状況に応じて調整される。よって、ネットワーク状況がたとえ悪化しても、遅延の累積によるユーザビリティの低下は回避される。また、個々の瞬間における画質は保たれるので、画質の低下によるユーザビリティの低下は生じない。

ところで、図１には、コンピュータ１０１が可用帯域幅の推定値をコンピュータ１０２に通知するステップが破線矢印で描かれており、それ以外のステップが実線矢印で描かれている。上記の説明から明らかなとおり、破線矢印で描かれたステップは、画面情報の送信頻度の調整のために追加的に生じる通信であるが、可用帯域幅の推定値のデータサイズはごくわずかである。また、画面情報の送信頻度の調整のために、時刻情報がコンピュータ１０２からコンピュータ１０１へと送信されるが、時刻情報のデータサイズもごくわずかである。

よって、第１実施形態には、「ネットワーク状況の把握のために追加的に生じる通信トラフィックの量が、ネットワーク状況に影響を与えない程度のごくわずかな量に過ぎない」という利点もある。換言すれば、第１実施形態では、「ネットワークに大きな追加的負荷をかけなくても、ネットワーク状況を推定することができ、推定したネットワーク状況に応じて通信トラフィックの量を調整することができる」という利点がある。

以上説明したような種々の利点のある第１実施形態は、シンクライアントシステムに好適である。以下に、シンクライアントシステムへの第１実施形態の適用に関して補足説明を行う。

シンクライアントシステムでは、クライアントとサーバがネットワークを介して接続される。そのため、クライアントにおける操作レスポンス性能はネットワーク状況に依存する。換言すれば、ユーザビリティがネットワーク状況に依存する。しかし、常にネットワーク状況が良好であるとは限らない。

第１実施形態によれば、たとえネットワーク状況が悪くてもユーザビリティの低下を緩和することができるような方法で、クライアントの画面更新が制御される。なぜなら、ネットワーク状況に応じて画面情報の送信頻度が調整され、ネットワーク状況の把握のためにネットワークに追加的に生じる負荷は無視して構わない程度のレベルであり、個々の瞬間での画質の低下は生じないからである。

また、シンクライアントシステムの利用が広まるのにつれて、ユーザがシンクライアントを行って行う作業の種類も、多様化が進むと予測される。よって、シンクライアントの画面の更新は、作業の種類によらずにユーザが快適にシンクライアントを使って作業を進めることができるように制御されることが好ましい。

例えば、ユーザは、テキスト文書の作成や電子メールの送受信などの作業だけでなく、高精細な画像（静止画像、動画像、または双方）を扱うアプリケーションを使った作業も、シンクライアント上で行いたい場合があり得る。高精細な画像を扱うアプリケーションの例として、例えば、ＣＡＤ（Computer Aided Design）アプリケーションや、フォトレタッチアプリケーションなどがある。

高精細な画像のデータサイズは大きいため、ある種の遠隔制御方法では、実用上満足の得られる操作レスポンス性能が達成されないことがしばしば起こり得る。つまり、クライアントとサーバ間の可用帯域幅が、実用上満足の得られる短い時間内に高精細な画像のデータをサーバからクライアントに送信するには、不十分な場合が多々ある。

しかし、第１実施形態では、高精細な画像を扱うアプリケーションが使われる場合でも、ユーザビリティの低下は比較的軽度である。なぜなら、第１実施形態によれば、画面情報のデータサイズが大きくても、画面情報をネットワーク状況に応じた頻度で送信することにより、遅延の累積による操作レスポンス性能の悪化を防ぐことができ、しかも、個々の時点での画質は保たれるからである。

なお、画面情報が送信される頻度は、換言すれば、ユーザが見ているクライアントの画面が更新される頻度である。そして、当該頻度が低くなることで、多少ユーザビリティが低下する可能性はある。なぜなら、画面の更新頻度が低い場合、動画像の動きがぎくしゃくして見えることがあるからである。

しかしながら、遅延の累積による操作レスポンス性能の悪化や、個々の瞬間における画質の低下がユーザビリティに与える悪影響と比べると、画面の更新頻度の低下がユーザビリティに与える悪影響は小さい。よって、第１実施形態は、ユーザビリティの低下を抑制または緩和するという点において、優れている。

また、仮に高精細な画像を扱うアプリケーションをユーザが使わないとしても、クライアントとサーバ間の可用帯域幅が狭ければ、ある種の遠隔制御方法では、実用上満足の得られる操作レスポンス性能が達成されないおそれが高い。そして、スマートフォンやタブレット端末やノート型ＰＣ（Personal Computer）などの携帯端末をモバイル環境下で利用するユーザにとっては、可用帯域幅は必ずしも十分に広いわけではない。例えば、社内の有線ＬＡＮ（Local Area Network）でクライアントとサーバが接続されている環境と比較すると、クライアントが公衆無線ＬＡＮを介してサーバと接続されている環境では、可用帯域幅がかなり狭い。

しかし、第１実施形態によれば、可用帯域幅が狭ければ、画面情報の送信頻度が、狭い可用帯域幅に応じた小さな値に調整される。その結果、遅延の累積は回避される。よって、第１実施形態によれば、モバイル環境下でも、実用上問題ない操作レスポンス性能が得られる。

以上説明したように、第１実施形態は、今後利用の拡大が見込まれるシンクライアントシステムにも好適である。

続いて、図３と４を参照して、第１実施形態の効果についてさらに説明する。
図３には、５つの模式的なタイミングチャート１２１〜１２５が示されている。タイミングチャート１２１は、コンピュータ１０２が画面情報Ｆ１〜Ｆ７を送信するタイミングを示す。説明の便宜上、図３には、コンピュータ１０２がある一定の頻度で画面情報Ｆ１〜Ｆ７を送信する場合のタイミングチャート１２１が示されている。

コンピュータ１０１と１０２の間の実際の可用帯域幅が十分な場合は、画面情報Ｆ１〜Ｆ７は、タイミングチャート１２２に示すようにコンピュータ１０１に受信される。つまり、送信から受信まで（より具体的には、送信の開始から受信の完了まで）、ある程度の遅延は生じるものの、「遅延が累積して次第に遅延時間が長くなる」という事態は生じない。よって、ある程度満足な操作レスポンス性能が得られる。タイミングチャート１２２に示す受信頻度は、換言すれば、コンピュータ１０１における表示フレームレートである。

他方、タイミングチャート１２３は、第１実施形態と比較するための比較例において、コンピュータ１０１と１０２の間の実際の可用帯域幅が不十分な場合に、コンピュータ１０１が画面情報Ｆ１〜Ｆ５を受信するタイミングを示す。比較例では、コンピュータ１０２が画面情報Ｆ１〜Ｆ７を送信する頻度を調整しないものとする。つまり、比較例では、コンピュータ１０２は、コンピュータ１０１と１０２の間の実際の可用帯域幅が不十分な場合にも、タイミングチャート１２１と同じ頻度で画面情報Ｆ１〜Ｆ５を送信するものとする。

可用帯域幅が不十分な場合、例えば画面情報Ｆ１がコンピュータ１０２からコンピュータ１０１への経路上のノードにおいて、当該経路上のリンクが空くのを待つために滞留してしまうことがある。具体的には、画面情報Ｆ１は、コンピュータ１０２内の送信バッファや、経路上のルータ内のバッファなどで、しばらく滞留することがある。同様に、画面情報Ｆ２〜Ｆ５も、コンピュータ１０２からコンピュータ１０１への経路上のどこかで滞留することがある。

このように、比較例においては、可用帯域幅が不十分な場合にコンピュータ１０２がタイミングチャート１２１の頻度で画面情報Ｆ１〜Ｆ５を送信すると、コンピュータ１０１は、タイミングチャート１２３に示すように画面情報Ｆ１〜Ｆ５を受信する。タイミングチャート１２１と１２３を比較すると分かるように、滞留の結果として、画面情報Ｆ１〜Ｆ５の送信間隔よりも画面情報Ｆ１〜Ｆ５の受信間隔の方が長い。

そして、受信間隔が長くなると、遅延の累積によって次第にレスポンス性能が悪化し、時間の進み方が遅くなったようにユーザに感じられる。つまり、下記の（１１ａ）〜（１１ｅ）の遅延時間Ｄ１〜Ｄ５は、Ｄ１＜Ｄ２＜Ｄ３＜Ｄ４＜Ｄ５という関係にある。

（１１ａ）画面情報Ｆ１の送信から受信までにかかる遅延時間Ｄ１。
（１１ｂ）画面情報Ｆ２の送信から受信までにかかる遅延時間Ｄ２。
（１１ｃ）画面情報Ｆ３の送信から受信までにかかる遅延時間Ｄ３。
（１１ｄ）画面情報Ｆ４の送信から受信までにかかる遅延時間Ｄ４。
（１１ｅ）画面情報Ｆ５の送信から受信までにかかる遅延時間Ｄ５。

なお、遅延時間Ｄ１は、より具体的には、画面情報Ｆ１の送信が開始されてから画面情報Ｆ１の受信が完了するまでにかかる時間である。他の遅延時間Ｄ２〜Ｄ５も同様である。

タイミングチャート１２３に示すようにコンピュータ１０１が画面情報Ｆ１〜Ｆ５を受信する場合、ユーザ１０３にとっては、時間の進み方が遅くなったように感じられる。例えば、「１秒間かけてユーザ１０３がマウス操作を行うと、当該マウス操作に応じて画面上のマウスポインタが１．５秒間かけて移動する」といったような事態が生じ得る。つまり、比較例では、「入力と表示の間で時間の進み方が異なる」という違和感をユーザ１０３に感じさせてしまうおそれが多いにある。

さらに、上記のとおり次第に遅延時間が長くなるので、やがては、例えば、「入力操作を行ってから１０秒以上もたってから、やっと、当該入力操作に応じて画面が変化する」といった事態も生じ得る。つまり、遅延の累積によって、やがては操作レスポンス性能が非常に悪化してしまいかねない。

以上のとおりなので、タイミングチャート１２３に示すような比較例は、ユーザビリティを大きく悪化させるおそれがある。しかし、第１実施形態では、比較例とは異なり、画面情報の送信頻度が調整される。

例えば、コンピュータ１０１がコンピュータ１０２に通知する可用帯域幅の推定値に応じて、コンピュータ１０２は、タイミングチャート１２１に示す頻度の半分の頻度で画面情報を送信してもよい。タイミングチャート１２４は、そのように頻度を半減させる調整を第１実施形態においてコンピュータ１０２が行う場合を示す。

タイミングチャート１２１と１２４を比較すると分かるように、タイミングチャート１２４の例では、画面情報Ｆ２、Ｆ４、およびＦ６は送信されない。タイミングチャート１２４の例では、コンピュータ１０２が画面情報の送信頻度を落とすことで、単位時間当たりの通信トラフィックの量が減る。

その結果、遅延の累積は回避される。具体的には、コンピュータ１０１は、タイミングチャート１２５に示すように画面情報Ｆ１、Ｆ３、Ｆ５およびＦ７を受信することができる。つまり、各画面情報の送信から受信まで、ある程度の遅延は生じるものの、遅延の累積による遅延の長期化は回避される。よって、ある程度満足な操作レスポンス性能が得られる。

また、画面情報Ｆ１、Ｆ３、Ｆ５およびＦ７がそれぞれ示す個々の時点の画面の品質は、第１実施形態では落とされない。よって、高精細な画像や細かい文字でも、くっきりとコンピュータ１０１の画面上に表示される。

続いて、図４を参照して第１実施形態の効果についてさらに説明する。図４には、あるＣＡＤアプリケーションが利用される場合についての、遅延時間に関するグラフ１３１とフレームレートに関するグラフ１３２が示されている。グラフ１３１と１３２において、白い棒グラフは、コンピュータ１０２が画面情報の送信頻度を調整しない比較例を示し、斜線パターンの棒グラフは、第１実施形態を示す。

具体的には、図４に関して、比較例と第１実施形態は、次の（１２ａ）〜（１２ｃ）の点で共通である。

（１２ａ）ユーザ１０３は、ＣＡＤアプリケーションを起動する入力操作と、ＣＡＤアプリケーション上での拡大、縮小、回転などのための入力操作を行う。
（１２ｂ）コンピュータ１０２は、コンピュータ１０１から通知される入力操作の内容に応じて、ＣＡＤアプリケーションを実行し、コンピュータ１０１の画面に表示するための画像を生成する。そして、コンピュータ１０２は、生成した画像をコンピュータ１０１に表示させるための画面情報を生成し、画面情報をコンピュータ１０１に送信する。
（１２ｃ）コンピュータ１０１は、受信した画面情報にしたがって画面を更新する。

しかし、比較例では下記の（１３ａ）〜（１３ｃ）の処理は行われないのに対して、第１実施形態では、下記の（１３ａ）〜（１３ｃ）の処理が行われる。

（１３ａ）コンピュータ１０２は、画面情報とともに時刻情報もコンピュータ１０１に送信する。
（１３ｂ）コンピュータ１０１は、時刻情報を用いて、可用帯域幅の推定値を増加させるか、維持するか、それとも減少させるかを決定する。そして、コンピュータ１０１は、可用帯域幅の推定値（または推定値の更新を反映する指標値）をコンピュータ１０２に通知する。
（１３ｃ）コンピュータ１０２は、通知された値に応じて、画面情報の送信頻度を調整する。

具体的には、グラフ１３１には、拡大、縮小、および回転という入力操作の種類ごとに、ユーザ１０３が入力操作をそれぞれ複数回行ったときの平均遅延時間が示されている。なお、グラフ１３１における遅延時間は、ユーザ１０３が入力操作を行った時点から、当該入力操作に応じた画像がコンピュータ１０１の画面に表示されるまでの時間である。白い棒グラフと斜線パターンの棒グラフを比較すると分かるように、比較例よりも第１実施形態の方が、遅延時間が短い。よって、第１実施形態はユーザビリティの改善に有益である。

また、グラフ１３２には、拡大、縮小、および回転という入力操作の種類ごとに、ユーザ１０３が入力操作をそれぞれ複数回行ったときの平均表示フレームレートが示されている。白い棒グラフが示す比較例での表示フレームレートは、例えば図３のタイミングチャート１２３に例示するように、遅延の累積の結果として送信フレームレートよりも下がってしまった表示フレームレートを示す。他方、斜線パターンの棒グラフが示す第１実施形態の表示フレームレートは、コンピュータ１０１から通知される値に応じてコンピュータ１０２が画面情報の送信頻度を調整した結果として下がったフレームレートを示す。

グラフ１３２では、比較例と第１実施形態のフレームレートの差があまりない。このことは、画面情報の送信頻度（換言すれば送信フレームレート）の調整（すなわち可用帯域幅の推定に基づく調整）が適切であり、実際の可用帯域幅が十分に活用されていることを示す。つまり、第１実施形態によれば、フレームレートが過度に下げられてしまうこと（そして、その結果として画面の表示が必要以上にぎくしゃくしてしまうこと）も防げる。

さて、図５は、ハードウェア構成例を示す図である。図５に示すハードウェア構成は、第１〜第４実施形態のいずれにも適用可能である。図５には、ネットワーク２２０を介して互いに接続されたコンピュータ２００と２４０が例示されている。

例えば、第１実施形態に関して図１に示したコンピュータ１０１は、図５のコンピュータ２００であってもよい。この場合、図１のコンピュータ１０２は、図５のコンピュータ２４０であってもよい。

また、第２〜第４実施形態に関して後述する図６のサーバ３１０は、図５のコンピュータ２４０であってもよい。この場合、図６のクライアント３２０は、図５のコンピュータ２００であってもよい。

コンピュータ２００と２４０の種類は任意である。例えば、コンピュータ２００は、エンドユーザが使うユーザ端末でもよい。また、コンピュータ２４０は、クラウドサービスの一種としてリモートデスクトップサービスを提供するサーバでもよい。ユーザ端末の例としては、デスクトップ型のＰＣ、ノート型のＰＣ、タブレット端末、ＰＤＡ（Personal Digital Assistant）、スマートフォン、ネットワーク機能を持つメディアプレイヤなどが挙げられる。

ネットワーク２２０の種類は任意である。ネットワーク２２０は、例えば、ＬＡＮ、ＷＡＮ（Wide Area Network）、インターネット、および、それらの組み合わせのいずれであってもよい。また、ネットワーク２２０は、有線ネットワークでもよく、無線ネットワークでもよく、両者の組み合わせであってもよい。

図５のコンピュータ２００は、ＣＰＵ（Central Processing Unit）２０１と、ＲＯＭ（Read Only Memory）２０２と、ＲＡＭ（Random Access Memory）２０３と、通信インタフェイス２０４を有する。コンピュータ２００はさらに、入力装置２０５と、出力装置２０６と、記憶装置２０７と、コンピュータ読み取り可能な記憶媒体２１０の駆動装置２０８を有する。コンピュータ２００の各構成要素は、バス２０９によって互いに接続されている。

ＣＰＵ２０１は、シングルコアまたはマルチコアのプロセッサである。コンピュータ２００は、複数のプロセッサを有していてもよい。例えば、コンピュータ２００は、２台以上のＣＰＵ２０１を有していてもよいし、ＣＰＵ２０１に加えてＧＰＵ（Graphics Processing Unit）などのプロセッサを有していてもよい。ＣＰＵ２０１は、プログラムをＲＡＭ２０３にロードし、ＲＡＭ２０３をワーキングエリアとしても利用しながら、プログラムを実行する。

通信インタフェイス２０４は、例えば、有線ＬＡＮインタフェイス、無線ＬＡＮインタフェイス、またはその組み合わせである。コンピュータ２００は、通信インタフェイス２０４を介してネットワーク２２０に接続される。

通信インタフェイス２０４は、具体的には、外付けのＮＩＣ（Network Interface Card）でもよいし、オンボード型のネットワークインタフェイスコントローラでもよい。例えば、通信インタフェイス２０４は、物理層の処理を行う「ＰＨＹチップ」と呼ばれる回路と、ＭＡＣ（Media Access Control）副層の処理を行う「ＭＡＣチップ」と呼ばれる回路を含んでいてもよい。

入力装置２０５は、例えば、キーボード、ポインティングデバイス、またはその組み合わせである。ポインティングデバイスは、例えば、マウスでもよいしタッチパッドでもよいしタッチスクリーンでもよい。出力装置２０６は、ディスプレイ、スピーカ、またはその組み合わせである。ディスプレイはタッチスクリーンであってもよい。

記憶装置２０７は、例えばＨＤＤ（Hard Disk Drive）やＳＳＤ（Solid-State Drive）などの不揮発性の記憶装置である。

記憶媒体２１０の例は、ＣＤ（Compact Disc）やＤＶＤ（Digital Versatile Disk）などの光ディスク、光磁気ディスク、磁気ディスク、フラッシュメモリなどの半導体メモリカードなどである。

ＣＰＵ２０１が実行するプログラムは、予めＲＯＭ２０２または記憶装置２０７にインストールされていてもよい。あるいは、プログラムは、記憶媒体２１０に格納されて提供され、記憶媒体２１０から駆動装置２０８により読み取られて記憶装置２０７にコピーされ、その後、ＲＡＭ２０３にロードされてもよい。または、ネットワーク２２０上のプログラム提供者２３０から、ネットワーク２２０と通信インタフェイス２０４を介して、プログラムがコンピュータ２００にダウンロードされ、インストールされてもよい。プログラム提供者２３０は、具体的には、コンピュータ２００ともコンピュータ２４０とも異なる、他のコンピュータである。

さて、コンピュータ２４０は、ＣＰＵ２４１と、ＲＯＭ２４２と、ＲＡＭ２４３と、通信インタフェイス２４４と、入力装置２４５と、出力装置２４６と、記憶装置２４７と、コンピュータ読み取り可能な記憶媒体２５０の駆動装置２４８を有する。コンピュータ２４０の各構成要素は、バス２４９によって互いに接続されている。コンピュータ２４０の構成はコンピュータ２００の構成と類似なので、詳しい説明は省略するが、何点か補足すると下記のとおりである。

図５には１台のＣＰＵ２４１のみが描かれているが、コンピュータ２４０は、コンピュータ２００と同様に、複数のプロセッサを有していてもよい。コンピュータ２４０は、ＣＰＵ２４１に加えて、さらに、動画像の圧縮用の専用ハードウェア回路を有していてもよい。

ＣＰＵ２４１が実行するプログラムは、予めＲＯＭ２４２または記憶装置２４７にインストールされていてもよい。あるいは、プログラムは、記憶媒体２５０に格納されて提供され、記憶媒体２５０から駆動装置２４８により読み取られて記憶装置２４７にコピーされてもよい。または、プログラム提供者２３０から、ネットワーク２２０と通信インタフェイス２４４を介して、プログラムがコンピュータ２４０にダウンロードされ、インストールされてもよい。

なお、ＲＯＭ２０２、ＲＡＭ２０３、記憶装置２０７、記憶媒体２１０、ＲＯＭ２４２、ＲＡＭ２４３、記憶装置２４７、および記憶媒体２５０は、いずれも、有形の（tangible）記憶媒体であり、信号搬送波のような一時的な（transitory）媒体ではない。

続いて、図６〜１２を参照して第２実施形態について説明する。詳しくは後述するとおり、図６〜８および１０〜１２は、第３〜第４実施形態とも関わる。第２〜第４実施形態のいずれにおいても、第１実施形態と同様の効果が得られる。

図６は、システムのブロック構成図である。図６のシステム３００は、サーバ３１０とクライアント３２０を含む。上記のとおり、サーバ３１０は例えば図５のコンピュータ２４０であってもよく、クライアント３２０は図５のコンピュータ２００でもよい。図６ではネットワークが省略されているが、図５に例示したように、サーバ３１０とクライアント３２０はネットワークを介して接続されている。

サーバ３１０は、受信部３１１と、生成部３１２と、送信部３１３と、調整部３１４と、付加部３１５を有する。また、サーバ３１０は、送信制御データ３１６を保持する。

受信部３１１は、クライアント３２０からデータを受信する。クライアント３２０からサーバ３１０に送信されるデータには、少なくとも２種類ある。

第１の種類のデータは、ユーザからクライアント３２０への入力をサーバ３１０に通知するためのデータである。受信部３１１は、第１の種類のデータを受信すると、受信したデータを生成部３１２に出力する。

第２の種類のデータは、後述するように可用帯域幅と過剰遅延時間をサーバ３１０に通知するためのデータである。過剰遅延時間は、実際の受信時刻が、可用帯域幅から推定される受信時刻よりもどの程度遅延しているかを示す。受信部３１１は、第２の種類のデータを受信すると、受信したデータを調整部３１４に出力する。

生成部３１２は、クライアント３２０の画面に表示するための画像を生成する。具体的には、生成部３１２は、クライアント３２０への入力の通知（つまり上記の第１の種類のデータ）に基づいて、１つまたは複数のプログラムを実行し、プログラムの実行に応じて画像を生成する。そして、生成した画像に基づいて、生成部３１２は、クライアント３２０に画像を画面上に表示させるための画面情報（具体的には後述の描画コマンド）を生成する。送信部３１３は、画面情報をクライアント３２０に送信する。

より具体的には、画面情報がクライアント３２０に送信される頻度は、調整部３１４により調整される。換言すれば、調整部３１４は、生成部３１２が画面情報を出力する頻度を制御する。調整部３１４は、送信制御データ３１６を用いて頻度の調整を行う。送信制御データ３１６の具体例は図７とともに後述する。

また、画面情報がクライアント３２０に送信されるときには、現在時刻を示す時刻情報が付加部３１５により画面情報に付加され、画面情報は時刻情報とともに送信部３１３から送信される。すなわち、画面情報は、画面情報が送信される時刻を示す時刻情報とともに、送信される。

なお、サーバ３１０が図５のコンピュータ２４０により実現される場合、受信部３１１は、ＣＰＵ２４１と通信インタフェイス２４４により実現されてもよい。同様に、送信部３１３も、ＣＰＵ２４１と通信インタフェイス２４４により実現されてもよい。生成部３１２と調整部３１４と付加部３１５は、いずれも、ＣＰＵ２４１により実現されてもよい。送信制御データ３１６は、ＲＡＭ２４３に記憶されることが好ましいが、記憶装置２４７に記憶されてもよい。

一方、クライアント３２０は、入力部３２１と、表示部３２２と、送信部３２３と、受信部３２４と、描画部３２５と、推定部３２６を有する。また、クライアント３２０は、受信履歴データ３２７と、時刻差データ３２８と、可用帯域幅データ３２９を保持する。

入力部３２１は、ユーザからの入力を受け付ける。例えば、入力部３２１は図５の入力装置２０５であってもよい。

表示部３２２は、画面を表示する。例えば、表示部３２２は図５の出力装置２０６であってもよい。

送信部３２３は、入力部３２１を介してユーザからクライアント３２０に与えられた入力をサーバ３１０に通知するためのデータや、可用帯域幅と過剰遅延時間をサーバ３１０に通知するためのデータを、サーバ３１０に送信する。送信部３２３は、例えば、図５のＣＰＵ２０１と通信インタフェイス２０４によって実現されてもよい。

受信部３２４は、サーバ３１０から、時刻情報とともに画面情報を受信する。また、詳しくは後述するように、サーバ３１０は、クライアント３２０の時計が示す時刻と、サーバ３１０の時計が示す時刻との時刻差を算出するためのデータ（以下では説明の便宜上、「時刻合わせコマンド」ともいう）も送信する。よって、受信部３２４は、画面情報だけでなく時刻合わせコマンドも受信する。

受信部３２４は、サーバ３１０からデータを受信するたびに、受信履歴データ３２７を更新する。また、受信部３２４は、時刻合わせコマンドを受信すると、クライアント３２０の時計が示す時刻と、サーバ３１０の時計が示す時刻との時刻差を算出し、算出結果を時刻差データ３２８として記憶する。

受信履歴データ３２７と時刻差データ３２８の具体例は図７とともに後述する。なお、クライアント３２０が図５のコンピュータ２００により実現される場合、受信履歴データ３２７と時刻差データ３２８は、ＲＡＭ２０３に記憶されることが好ましいが、記憶装置２０７に記憶されてもよい。なお、送信部３２３と同様に、受信部３２４も、ＣＰＵ２０１と通信インタフェイス２０４によって実現されてもよい。

描画部３２５は、受信部３２４が受信した画面情報に基づいて、画面の一部または全部を描画する。描画部３２５は、ＣＰＵ２０１（または、不図示のＧＰＵなどの他のプロセッサ）によって実現されてもよい。

推定部３２６は、受信履歴データ３２７と時刻差データ３２８を用いて、サーバ３１０とクライアント３２０の間のネットワークの可用帯域幅を推定する。可用帯域幅の推定値は、可用帯域幅データ３２９として記憶される。可用帯域幅データ３２９の具体例は図７とともに後述する。

より詳しくは、可用帯域幅の推定に際して、推定部３２６は、過剰遅延時間を算出する。過剰遅延時間は、実際に受信部３２４が画面情報を受信した時刻と、現在の可用帯域幅データ３２９から推定される受信時刻との差である。推定部３２６は、過剰遅延時間に応じて、可用帯域幅の推定値を増加させるか、維持するか、または減少させる。

また、推定部３２６は、可用帯域幅と過剰遅延時間を送信部３２３に出力する。すると、送信部３２３は、可用帯域幅と過剰遅延時間をサーバ３１０に通知するためのデータ（上記の第２の種類のデータ）をサーバ３１０に送信する。

なお、推定部３２６は、図５のＣＰＵ２０１によって実現されてもよい。また、可用帯域幅データ３２９は、ＲＡＭ２０３に記憶されることが好ましいが、記憶装置２０７に記憶されてもよい。

続いて、図７を参照して、図６中の各種データの詳細について説明する。図７には、参照の便宜のため、後述の数式で用いる記号も併記してある。
なお、以下では説明の便宜上、サーバ３１０における時刻は、サーバ３１０が起動してから経過した時間の長さにより示されるものとする。同様に、クライアント３２０における時刻は、クライアント３２０が起動してから経過した時間の長さにより示されるものとする。そのため、図７では、時刻がｍｓ（millisecond）単位で示されている。

サーバ３１０における時刻は、例えば、サーバ３１０を実現するコンピュータ２４０のＣＰＵ２４１に内蔵されたタイマにより、カウントされてもよい。同様に、クライアント３２０における時刻は、例えば、クライアント３２０を実現するコンピュータ２００のＣＰＵ２０１に内蔵されたタイマにより、カウントされてもよい。

さて、サーバ３１０が保持する送信制御データ３１６は、具体的には、可用帯域幅と、過剰遅延解消時刻と、送信フレームレートと、最終送信時刻を含む。図７の例では、可用帯域幅が３５００ｋｂｐｓ（kilobit per second）、過剰遅延解消時刻が１０１０００ｍｓ、送信フレームレートが３０ｆｐｓ、最終送信時刻が１０００１０ｍｓである。

送信制御データ３１６中の可用帯域幅は、クライアント３２０から通知された推定値を示す。可用帯域幅の初期値は、例えば０ｋｂｐｓなどの無効な値である。

また、過剰遅延解消時刻は、「過剰遅延を解消するためには、サーバ３１０がいつまで画面情報の送信を控えるのが好ましいか」という目安を示す時刻である。後述するとおり、過剰遅延解消時刻は、クライアント３２０から通知される過剰遅延時間に基づいて算出される。過剰遅延解消時刻の初期値は、例えば０ｍｓなどの無効な値である。

送信フレームレートは、画面情報を送信する頻度の、現在の値を示す。送信フレームレートの初期値は、例えば３０ｆｐｓなどの所定の値である。送信フレームレートの初期値は、実施形態に応じた適宜の値でよい。

最終送信時刻は、サーバ３１０が最後にクライアント３２０に画面情報を送信した時刻である。最終送信時刻の初期値は、例えば０ｍｓなどの無効な値である。

さて、クライアント３２０が保持する受信履歴データ３２７は、１つ以上のエントリを含み得る。各エントリは、受信時刻と、当該受信時刻に受信部３２４が受信したデータのサイズとのペアである。図７の例は、受信部３２４が、１２００ｍｓという時刻に１０００バイトのデータを受信し、１２４０ｍｓという時刻に１５００バイトのデータを受信し、１２７０ｍｓという時刻に１２００バイトのデータを受信したことを示す。

受信履歴データ３２７は、初期状態ではエントリを１つも持たない。また、現在時刻から所定の範囲よりも受信時刻が古くなったエントリは、受信部３２４により削除される。以下では説明の便宜上、上記「所定の範囲」を、「現在から６秒間以内」という範囲だとするが、所定の範囲は実施形態に応じて適宜決められてよい。

また、クライアント３２０が保持する時刻差データ３２８は、クライアント３２０の時計が示す時刻と、サーバ３１０の時計が示す時刻との時刻差を示す。第２〜第４実施形態では、具体的には、時刻差の近似値が使われる。図７の例では、時刻差は−９８７４０ｍｓである。

ところで、クライアント３２０が保持する図６の可用帯域幅データ３２９は、第２〜第３実施形態では、具体的には図７の可用帯域幅データ３２９ａのように、推定部３２６が推定した可用帯域幅の推定値を含むデータである。図７の例では、可用帯域幅データ３２９ａは、３５００ｋｂｐｓという推定値を含む。

他方、後述の第４実施形態では、図６の可用帯域幅データ３２９は、具体的には図７の可用帯域幅データ３２９ｂのように、推定部３２６が推定した可用帯域幅の推定値だけでなく、さらに、前回通知帯域幅を含む。図7の例では、可用帯域幅は３５００ｂｐｓであり、前回通知帯域幅は３８５０ｂｐｓである。前回通知帯域幅の詳細については、第４実施形態とともに後述する。

さて、図８〜９は、第２実施形態のクライアント３２０の動作フローチャートである。クライアント３２０は、電源が入れられて起動すると、図８〜９の処理を開始する。

ステップＳ２０１で、クライアント３２０は、サーバ３１０に接続要求を送信してサーバ３１０との間の接続を確立し、リモートデスクトップ初期化処理を行う。リモートデスクトップ初期化処理は、サーバ３１０からクライアント３２０がリモートデスクトップサービスを受けるための初期化処理である。例えば、ステップＳ２０１でクライアント３２０は、表示部３２２の解像度や、使用するインプットメソッドなどの情報をサーバ３１０に通知してもよい。

次に、ステップＳ２０２でクライアント３２０は、イベントの発生を待つ。
そして、入力部３２１を介してユーザから入力が与えられるという入力イベントが発生すると、処理はステップＳ２０３に移行する。入力イベントの具体例は、例えば、キーボードのキーの押鍵、マウスポインタの移動、ドラッグ、クリック（またはタップ）、ダブルクリック（またはダブルタップ）、フリック、ピンチイン、ピンチアウト、などの操作である。

他方、受信部３２４がサーバ３１０から何らかのデータを受信するというデータ受信イベントが発生すると、処理はステップＳ２０４に移行する。

ステップＳ２０３で送信部３２３は、入力部３２１を介して与えられた入力の内容を、サーバ３１０に通知する。そして、処理はステップＳ２０２に戻る。

ステップＳ２０４で受信部３２４は、受信時刻とデータサイズの組を受信履歴データ３２７に追加する。つまり、受信部３２４は、現在時刻を取得し、サーバ３１０から受信したデータのサイズを調べ、現在時刻と調べたサイズを組にした新たなエントリを受信履歴データ３２７に追加する。

なお、サーバ３１０がクライアント３２０に送信するデータの形式は実施形態に応じて適宜決められていてよい。例えば、ＴＣＰ／ＩＰ（Transmission Control Protocol/Internet Protocol）上でリモートデスクトップサービスが提供される場合、サーバ３１０がクライアント３２０に送信するデータは、以下の（１４ａ）〜（１４ｄ）のフィールドを含むパケットであってもよい。

（１４ａ）ＩＰヘッダ。
（１４ｂ）ＴＣＰヘッダ。
（１４ｃ）リモートデスクトップサービス用のアプリケーション層のヘッダ。
（１４ｄ）リモートデスクトップサービス用のアプリケーション層のペイロード。

例えば（１４ａ）〜（１４ｄ）のフィールドを含むパケットを受信部３２４が受信した場合、受信履歴データ３２７に記録されるデータサイズは、（１４ａ）〜（１４ｄ）のフィールドを含むパケット全体の長さである。

次に、ステップＳ２０５で受信部３２４は、受信したデータの種類を判定する。例えば、（１４ｃ）のアプリケーション層のヘッダが、データの種類を示すフィールドを含んでいてもよい。その場合、受信部３２４は、アプリケーション層のヘッダを参照することにより、データの種類を判定することができる。以下では説明の便宜上、サーバ３１０がクライアント３２０に送信するデータには、少なくとも、「時刻合わせコマンド」と「描画コマンド」の２種類があるものとする。

時刻合わせコマンドは、クライアント３２０の時計が示す時刻と、サーバ３１０の時計が示す時刻との時刻差を算出するためのデータである。具体的には、時刻合わせコマンドは、サーバ３１０が時刻合わせコマンドを送信した時刻を示すタイムスタンプを含む。

なお、（１４ｃ）のアプリケーション層のヘッダの形式は、実施形態に応じて様々であってよい。（１４ｃ）のヘッダの形式に応じて、タイムスタンプは、（１４ｃ）のヘッダに含まれていてもよいし、（１４ｄ）のペイロードに含まれていてもよい。

描画コマンドは、サーバ３１０がクライアント３２０に画像を画面上に表示させるための画面情報を含むデータである。詳しくは後述するように、描画コマンドのペイロードは、画面の一部または全部を静止画像形式で圧縮したデータ、画面の一部または全部を動画像形式で圧縮したデータ、または両者の組み合わせを含む。換言すれば、描画コマンドは、第１実施形態に関して説明した第３の形式の画面情報を含む。

例えば、静止画像用の形式としては、ＪＰＥＧ（Joint Photographic Experts Group）形式が利用可能であり、動画像用の形式としては、ＭＰＥＧ形式が利用可能である。もちろん、実施形態に応じて、他の画像圧縮形式が使われてもよい。

また、描画コマンドも、サーバ３１０が描画コマンドを送信した時刻を示すタイムスタンプを含む。アプリケーション層のヘッダの形式に応じて、タイムスタンプは、ヘッダに含まれていてもよいし、ペイロードに含まれていてもよい。

受信したデータが時刻合わせコマンドの場合、処理はステップＳ２０７に移行する。受信したデータが描画コマンドの場合、処理はステップＳ２１０に移行する。受信したデータが他の種類のデータである場合、処理はステップＳ２０６に移行する。

ステップＳ２０６でクライアント３２０は、受信したデータの種類に応じた適宜の処理を行う。そして、図８〜９の処理はステップＳ２０２に戻る。

ステップＳ２０７で受信部３２４は、受信した時刻合わせコマンドから、時刻合わせコマンドの送信時刻を取得する。取得される送信時刻は、サーバ３１０での時計で表された時刻である。以下では説明の便宜上、ステップＳ２０７で取得される送信時刻を「Ｔ＿ｓｅｎｔ」と表記することがある。

次に、ステップＳ２０８で受信部３２４は、現在時刻を取得し、現在時刻とステップＳ２０７で取得した送信時刻の差を算出する。そして、受信部３２４は、算出した時刻差を時刻差データ３２８として記憶する。

ステップＳ２０８で取得される現在時刻は、クライアント３２０の時計で表された時刻である。以下では説明の便宜上、ステップＳ２０８で取得される現在時刻を「Ｔ＿ｎｏｗ＿ｃ」と表記し、ステップＳ２０８で算出される時刻差を「Ｔ＿ｄｉｆｆ」と表記する。すなわち、式（１）の時刻差Ｔ＿ｄｉｆｆが時刻差データ３２８として記憶される。
T_diff = T_now_c-T_sent (1)

式（１）から明らかなように、第２実施形態における時刻差Ｔ＿ｄｉｆｆは、クライアント３２０の時計で表される時刻とサーバ３１０の時計で表される時刻との差そのものを厳密に示す値ではなく、当該時刻差の近似値である。時刻合わせコマンドのような短いデータに関しては、サーバ３１０が当該データを送信し始めてから、クライアント３２０が当該データを受信し終わるまでの転送時間も短い。よって、短い転送時間を無視することによって、クライアント３２０の時計で表される時刻とサーバ３１０の時計で表される時刻との差は、式（１）のように近似される。

なお、参照の便宜上、図７には時刻がミリ秒単位で示されているが、式（１）および後述の各数式における時刻と時間の単位は秒であるものとする。

以上のようにして受信部３２４が時刻差データ３２８を更新した後、処理はステップＳ２０２に戻る。

さて、ステップＳ２０９では、描画部３２５が、受信部３２４により受信された描画コマンドにしたがって、画面上の更新された領域を描画する。

具体的には、描画コマンドのペイロードには、画面の中で更新された領域を描画部３２５に描画させるためのデータが含まれる。例えば、表示部３２２の画面は、図２に例示するように、横方向にＨ個に分割され、縦方向にＶ個に分割されてもよい（２≦Ｈかつ２≦Ｖ）。この場合、画面は合計でＨ×Ｖ個のブロックを含む。これらのＨ×Ｖ個のブロックのすべてに変化が生じる場合もあるし、どのブロックにも変化が生じない場合もあるし、１個以上のあるブロックには変化があり残りのブロックには変化がない場合もある。

少なくとも１個のブロックに変化がある場合、描画コマンドのペイロードには、変化したブロックを静止画像形式で圧縮したデータ、変化したブロックを含む矩形の領域を動画像形式で圧縮したデータ、またはその両者が含まれる。よって、描画部３２５は、描画コマンドのペイロードに含まれるデータをデコードし、更新された各領域を画面上に描画する。

例えば、図２の例では、描画コマンドのペイロードには、領域１１１を動画像形式で圧縮したデータと、領域１１２を静止画像形式で圧縮したデータと、領域１１３を静止画像形式で圧縮したデータが含まれる。よって、描画部３２５は、描画コマンドのペイロードに含まれるデータをデコードし、領域１１１〜１１３を更新する。例えば、描画部３２５は、ＶＲＡＭ（Video Random Access Memory）上に記憶されている、領域１１１〜１１３中の各画素のデータを、デコード結果に応じて更新する。それにより、描画部３２５は、画面上の領域１１１〜１１３を更新する。

次のステップＳ２１０では、推定部３２６が、受信履歴データ３２７を用いて、最近の６秒間以内の期間における平均受信ビットレートを算出する。図７に関して説明したとおり、第２実施形態では、受信時刻から６秒が経過した後は、受信履歴データ３２７からエントリが削除される。よって、受信履歴データ３２７のどのエントリの受信時刻も、現在から６秒以内である。

説明の便宜上、受信履歴データ３２７のエントリの個数をＲとする（１≦Ｒ）。また、１≦ｊ≦Ｒなる各ｊについて、受信履歴データ３２７のｊ番目のエントリにおける受信時刻とデータサイズをそれぞれ「Ｔ＿ｒｃｖ_ｊ」と「Ｓｉｚｅ＿ｒｃｖ_ｊ」と表記する。なお、１番目のエントリの受信時刻が最も古く、Ｒ番目のエントリの受信時刻が最も新しいものとする。

ステップＳ２１０で推定部３２６は、より具体的には、例えば式（２）にしたがって最近の６秒間以内の期間における平均受信ビットレート（以下では「ＢＰＳ＿ａｖｒ」と表記する）を算出してもよい。

なお、式（２）における８の乗算は、バイトからビットへの換算を示す。また、式（２）における「Ｔ＿ｎｏｗ＿ｃ」は、推定部３２６がステップＳ２１０で取得する現在時刻を示す。なお、参照の便宜上、図７には帯域幅がｋｂｐｓ単位で示されているが、式（２）および後述の各数式における、帯域幅および受信ビットレートの単位は、ｂｐｓ（bit per second）であるものとする。

実施形態によっては、上記の「最近６秒間」という所定の期間の長さに合わせて、式（２）の分母は、「６」という定数に置き換えられてもよい。もちろん、所定の期間の長さ自体も、実施形態に応じて適宜変更されてよい。

続いて、ステップＳ２１１で推定部３２６は、可用帯域幅データ３２９を参照し、可用帯域幅が初期値（例えば０ｋｂｐｓ）であるか否かを判断する。可用帯域幅が初期値の場合、処理はステップＳ２１２に移行し、可用帯域幅が初期値ではない場合、処理はステップＳ２１３に移行する。

ステップＳ２１２で推定部３２６は、ステップＳ２１０で算出した平均受信ビットレートＢＰＳ＿ａｖｒを可用帯域幅として記憶する。すなわち、推定部３２６は、可用帯域幅データ３２９を平均受信ビットレートＢＰＳ＿ａｖｒで上書きする。

なお、可用帯域幅データ３２９は、サーバ３１０とクライアント３２０の間のエンド・ツー・エンドの可用帯域幅の推定値を示す。そして、実際の可用帯域幅は時間とともに変化し得るが、ある期間における可用帯域幅の実際の値の平均値は、当該期間における平均受信ビットレート以上であると推定される。よって、ステップＳ２１２では、平均受信ビットレートＢＰＳ＿ａｖｒが可用帯域幅の推定値として使われる（すなわち、平均受信ビットレートＢＰＳ＿ａｖｒが可用帯域幅データ３２９として記憶される）。

以下では説明の便宜上、可用帯域幅（より正確には可用帯域幅の推定値）を「ＥｓｔＢＷ」と表記することがある。具体的には、表記の簡単化のために単に「可用帯域幅ＥｓｔＢＷ」と表記する場合もあるし、可用帯域幅の実際の値と推定値との区別を明示するために「可用帯域幅の推定値ＥｓｔＢＷ」のように表記する場合もある。

ステップＳ２１２の処理は、式（３）のように表される。ある観点から見れば、ステップＳ２１２の処理は、無効な値に設定されている可用帯域幅ＥｓｔＢＷを、式（３）により有効な値に初期化する処理である。
EstBW = BPS_avr (3)

以上のようにして可用帯域幅が更新された後、処理はステップＳ２１３に移行する。
ステップＳ２１３で推定部３２６は、受信部３２４が今回受信したデータ（つまり描画コマンド）のサイズと可用帯域幅から、今回受信したデータの転送にかかった時間の推定値を算出する。以下では説明の便宜上、ステップＳ２１３で算出される時間を「推定転送時間」といい、「ＥｓｔＴ＿ｔｒａｎｓ」と表記する。

具体的には、推定部３２６は、受信履歴データ３２７の最新のエントリに記憶されているデータサイズＳｉｚｅ＿ｒｃｖ_Ｒと、可用帯域幅データ３２９として記憶されている可用帯域幅Ｅｓｔ＿ＢＷを用いて、式（４）の計算を行う。
EstT_trans = 8×Size_rcv_R/EstBW (4)

そして、次に図９のステップＳ２１４で推定部３２６は、受信部３２４により受信された描画コマンドから、描画コマンドがサーバ３１０から送信された時刻を示す時刻情報（すなわち上記のタイムスタンプ）を取得する。

以下ではステップＳ２１４で取得される時刻情報が示す送信時刻を、説明の便宜上、「Ｔ＿ｓｅｎｔ」とも表記する。送信時刻Ｔ＿ｓｅｎｔは、サーバ３１０の時計で表される時刻である。推定部３２６は以上のようにして送信時刻Ｔ＿ｓｅｎｔを取得する。

次のステップＳ２１５で推定部３２６は、式（５）に示すとおり、送信時刻Ｔ＿ｓｅｎｔに時刻差Ｔ＿ｄｉｆｆを足し、推定送信時刻（以下では「ＥｓｔＴ＿ｓｅｎｔ」と表記する）を算出する。
EstT_sent = T_sent+T_diff (5)

式（１）から分かるように、サーバ３１０の時計で表された時刻に時刻差Ｔ＿ｄｉｆｆを足すことで、サーバ３１０の時計で表された時刻は、クライアント３２０の時計で表された時刻に換算される。また、時刻差Ｔ＿ｄｉｆｆは上記のとおり近似値である。よって、式（５）により算出される推定送信時刻ＥｓｔＴ＿ｓｅｎｔは、描画コマンドがサーバ３１０から送信された時刻Ｔ＿ｓｅｎｔをクライアント３２０の時計で示した時刻の推定値を示す。

そして、次にステップＳ２１６で推定部３２６は、式（６）に示すとおり、受信履歴データ３２７の最新のエントリに記憶されている受信時刻Ｔ＿ｒｃｖ_Ｒから、推定送信時刻ＥｓｔＴ＿ｓｅｎｔと推定転送時間ＥｓｔＴ＿ｔｒａｎｓを引く。式（６）の減算により、推定部３２６は、過剰遅延時間を算出する。なお、式（６）に示すように、以下では便宜上、過剰遅延時間を「ＥｘｔｒａＤｅｌａｙ」とも表記する。
ExtraDelay = T_rcv_R-EstT_sent-EstT_trans (6)

過剰遅延時間ＥｘｔｒａＤｅｌａｙは、可用帯域幅Ｅｓｔ＿ＢＷから推定される受信時刻（ＥｓｔＴ＿ｓｅｎｔ＋ＥｓｔＴ＿ｔｒａｎｓ）よりも実際の受信時刻Ｔ＿ｒｃｖ_Ｒがどれくらい遅延しているかを示す。

可用帯域幅データ３２９に基づいて推定される受信時刻よりも早くに描画コマンドが受信された場合は、過剰遅延時間ＥｘｔｒａＤｅｌａｙは負である。逆に、可用帯域幅データ３２９に基づいて推定される受信時刻よりも遅くに描画コマンドが受信された場合は、過剰遅延時間ＥｘｔｒａＤｅｌａｙは正である。

続いて、ステップＳ２１７で推定部３２６は、過剰遅延時間ＥｘｔｒａＤｅｌａｙが３００ｍｓより長いのか、０ｍｓより長く３００ｍｓ以下なのか、それとも０ｍｓ以下なのかを判断する。

なお、ステップＳ２１７における「３００ｍｓ」という第１の閾値は、実施形態に応じて、適宜、他の正の値に置き換えられてよい。また、ステップＳ２１７における「０ｍｓ」という第２の閾値も、実施形態に応じて、適宜、他の値に置き換えられてよい。

第２の閾値は、ゼロか負の値であることが望ましいが、ゼロに近い小さな正の値が第２の閾値として使われてもよい。ただし、いずれにせよ、第２の閾値は、第１の閾値より小さい。

なお、２つの閾値は、ユーザ定義可能な変数であってもよいし、推定部３２６が可用帯域幅ＥｓｔＢＷに応じて変更する可変の閾値であってもよい。しかし、以下では説明の簡単化のため、固定的な２つの閾値が使われるものとする。

これらの２つの閾値の意味を説明すれば、以下のとおりである。第１と第２の閾値は、以下に説明する意味をよく反映するように、例えば予備実験などに基づいて、適切に定められることが好ましい。

実際の可用帯域幅は、時間とともに変動し得る。例えば、サーバ３１０とクライアント３２０以外の他のコンピュータによるネットワーク通信の量に応じて、実際の可用帯域幅は変動し得る。また、サーバ３１０とクライアント３２０の間のネットワークの少なくとも一部が無線ネットワークである場合、遮蔽物や干渉源など、環境中のいくつかの要因によっても、実際の可用帯域幅は変動し得る。

実際の可用帯域幅の変動に応じて、描画コマンドの受信時刻が影響を受けるので、過剰遅延時間ＥｘｔｒａＤｅｌａｙも実際の可用帯域幅の変動に応じて変動し得る。しかし、偶発的に起こり得る小さな変動は無視しても差し支えない。

式（６）から分かるように、可用帯域幅データ３２９として記憶されている推定値が実際の可用帯域幅に近ければ、過剰遅延時間ＥｘｔｒａＤｅｌａｙの絶対値も比較的小さい。よって、過剰遅延時間ＥｘｔｒａＤｅｌａｙの絶対値が比較的小さい場合、過剰遅延時間ＥｘｔｒａＤｅｌａｙは、偶発的に起こり得る小さな変動に起因すると見なして差し支えない。つまり、この場合、可用帯域幅データ３２９として記憶されている推定値は、更新されなくてもよい。

しかし、もし過剰遅延時間ＥｘｔｒａＤｅｌａｙが第２の閾値以下ならば、可用帯域幅データ３２９として記憶されている推定値は、更新されることが好ましい（具体的には、大きくされることが好ましい）。なぜなら、過剰遅延時間ＥｘｔｒａＤｅｌａｙが第２の閾値以下ならば、「可用帯域幅データ３２９として記憶されている推定値が過小である」という可能性が残っているからである。つまり、実際の可用帯域幅の一部が活用されずに遊んでいる可能性がある。

すなわち、過剰遅延時間ＥｘｔｒａＤｅｌａｙが第２の閾値以下ならば、実際の可用帯域幅によっては、サーバ３１０からクライアント３２０に描画コマンドが送信される頻度を上昇させる余地があり得る。換言すれば、クライアント３２０における表示フレームレートを上げて、画面表示をより滑らかにし、ひいてはユーザビリティをさらに向上させることが可能な場合もあり得る。

よって、過剰遅延時間ＥｘｔｒａＤｅｌａｙが第２の閾値以下ならば、以上のような可能性が実際に成り立つか否かを試すために、推定部３２６は可用帯域幅の推定値を増加させてもよい。クライアント３２０は、より大きな可用帯域幅の推定値をサーバ３１０に通知することで、間接的に、サーバ３１０からクライアント３２０に描画コマンドが送信される頻度を上昇させることができる。

つまり、第２の閾値は、可用帯域幅データ３２９を更新しないで推定値を維持する場合と、上記のような可能性が成り立つか否かを積極的に試す場合とを分かつための閾値である。

逆に、もし過剰遅延時間ＥｘｔｒａＤｅｌａｙが非常に長ければ（具体的には、第１の閾値より長ければ）、可用帯域幅データ３２９として記憶されている推定値が過大だと考えられる。また、この場合、「偶発的に起こり得る小さな変動に起因して、過剰遅延時間ＥｘｔｒａＤｅｌａｙが、偶然、正になった」という蓋然性は低い。むしろ、この場合、「描画コマンドの送信が繰り返されるうちに遅延が次第に累積してゆく過程（例えば図３のタイミングチャート１２３のような過程）に起因して、過剰遅延時間ＥｘｔｒａＤｅｌａｙが第１の閾値を超えた」という蓋然性が高い。

よって、過剰遅延時間ＥｘｔｒａＤｅｌａｙが第１の閾値より長ければ、可用帯域幅データ３２９として記憶されている推定値を減少させる（すなわち推定値を実際の可用帯域幅に近づける）ことが適切である。つまり、第１の閾値は、偶然起こり得る小さな変動と、可用帯域幅の過大な推定に起因する遅延の累積とを見分けるための閾値である。

さて、ここでステップＳ２１７の説明に戻る。過剰遅延時間ＥｘｔｒａＤｅｌａｙが３００ｍｓより長ければ、可用帯域幅ＥｓｔＢＷを減少させるために、処理はステップＳ２１８に移行する。過剰遅延時間ＥｘｔｒａＤｅｌａｙが０ｍｓより長く３００ｍｓ以下であれば、推定部３２６は、可用帯域幅ＥｓｔＢＷを変えずにそのまま維持し、処理はステップＳ２２０に移行する。過剰遅延時間ＥｘｔｒａＤｅｌａｙが０ｍｓ以下ならば、可用帯域幅ＥｓｔＢＷを増加させるために、処理はステップＳ２２１に移行する。

ステップＳ２１８で推定部３２６は、過大な推定値を小さくするために、可用帯域幅ＥｓｔＢＷの現在の値と、ステップＳ２１０で算出した平均受信ビットレートＢＰＳ＿ａｖｒとの平均値を、新たに可用帯域幅ＥｓｔＢＷとして記憶する。すなわち、推定部３２６は、式（７）にしたがって可用帯域幅データ３２９を更新する。式（７）の右辺の「ＥｓｔＢＷ」は可用帯域幅の現在の値を示し、左辺の「ＥｓｔＢＷ」は更新後の可用帯域幅の値を示す。
EstBW = (EstBW+BPS_avr)/2 (7)

なお、実施形態によっては、推定部３２６は、式（７）以外の式にしたがって可用帯域幅データ３２９を更新してもよい。例えば、推定部３２６は、０＜Ｃ_１≦１なる適宜の定数Ｃ_１を用いて、式（８）にしたがって可用帯域幅データ３２９を更新してもよい。
EstBW = (1-C₁)×EstBW+C₁×BPS_avr (8)

式（７）は、式（８）における定数Ｃ_１が１／２の場合の例である。定数Ｃ_１が小さいほど、可用帯域幅ＥｓｔＢＷの変化は緩やかになる。

続いて、ステップＳ２１９で推定部３２６は、ステップＳ２１８で更新した可用帯域幅ＥｓｔＢＷを用いて、過剰遅延時間ＥｘｔｒａＤｅｌａｙを再計算する。

具体的には、推定部３２６は、更新後の可用帯域幅ＥｓｔＢＷを用いて、式（４）により推定転送時間ＥｓｔＴ＿ｔｒａｎｓを再計算する。そして、推定部３２６は、再計算した推定転送時間ＥｓｔＴ＿ｔｒａｎｓを用いて、式（６）により過剰遅延時間ＥｘｔｒａＤｅｌａｙを再計算する。

過剰遅延時間ＥｘｔｒａＤｅｌａｙの再計算の後、処理はステップＳ２２０に移行する。なお、ステップＳ２１６で算出される過剰遅延時間ＥｘｔｒａＤｅｌａｙと、ステップＳ２１９で再計算される過剰遅延時間ＥｘｔｒａＤｅｌａｙの差は、それほど顕著でない場合も多い。よって、処理の簡素化のため、実施形態によっては、ステップＳ２１９が省略されてもよい。

ステップＳ２２０では、推定部３２６が可用帯域幅ＥｓｔＢＷと過剰遅延時間ＥｘｔｒａＤｅｌａｙを送信部３２３に出力する。すると、送信部３２３は、可用帯域幅ＥｓｔＢＷと過剰遅延時間ＥｘｔｒａＤｅｌａｙを含む通知をサーバ３１０に送信する。そして、処理は図８のステップＳ２０２に戻る。

ステップＳ２２１で推定部３２６は、可用帯域幅ＥｓｔＢＷの値を増加させる。具体的には、推定部３２６は、比較的小さな正の適宜の定数Ｃ_２を用いて、式（９）により、新たな可用帯域幅ＥｓｔＢＷの値を算出し、可用帯域幅データ３２９を更新する。式（９）の右辺の記号「ＥｓｔＢＷ」は、可用帯域幅の現在の推定値を示し、左辺の記号「ＥｓｔＢＷ」は、可用帯域幅の新たな推定値を示す。
EstBW = EstBW×(1+C₂) (9)

図９には、Ｃ_２＝０．１の場合が例示されている。上記のとおり、ステップＳ２２１が実行されるのは過剰遅延時間ＥｘｔｒａＤｅｌａｙが０ｍｓ以下の場合であり、この場合、フレームレートを上げる余地があり得る。よって、ステップＳ２２１では、フレームレートを上げる余地が実際にあるか否かを試すため、推定部３２６が可用帯域幅ＥｓｔＢＷの値を増加させる。

なお、推定部３２６は、式（９）のように１より大きい所定の値を可用帯域幅の現在の推定値に掛ける代わりに、所定の正の値を可用帯域幅の現在の推定値に足すことで、可用帯域幅の新たな推定値を算出してもよい。

次に、ステップＳ２２２で推定部３２６は、ステップＳ２２１で更新した可用帯域幅ＥｓｔＢＷを用いて、過剰遅延時間ＥｘｔｒａＤｅｌａｙを再計算する。

具体的には、推定部３２６は、更新後の可用帯域幅ＥｓｔＢＷを用いて、式（４）により推定転送時間ＥｓｔＴ＿ｔｒａｎｓを再計算する。そして、推定部３２６は、再計算した推定転送時間ＥｓｔＴ＿ｔｒａｎｓを用いて、式（６）により過剰遅延時間ＥｘｔｒａＤｅｌａｙを再計算する。

過剰遅延時間ＥｘｔｒａＤｅｌａｙの再計算の後、処理はステップＳ２２０に移行する。なお、ステップＳ２１６で算出される過剰遅延時間ＥｘｔｒａＤｅｌａｙと、ステップＳ２２２で再計算される過剰遅延時間ＥｘｔｒａＤｅｌａｙの差は、それほど顕著でない場合も多い。よって、処理の簡素化のため、実施形態によっては、ステップＳ２１９が省略されてもよい。

さて、図１０〜１１は、第２〜第４実施形態に共通のサーバ３１０の動作フローチャートである。サーバ３１０は、クライアント３２０からの接続要求を受信すると、図１０〜１１の処理を開始する。

ステップＳ３０１でサーバ３１０は、クライアント３２０との間の接続を確立し、リモートデスクトップ初期化処理を行う。例えば、サーバ３１０は、クライアント３２０から、表示部３２２の解像度や、使用するインプットメソッドなどの情報を受信してもよい。そして、サーバ３１０は、クライアント３２０用に１つ以上のプログラムを実行するための実行環境（runtime environment）をサーバ３１０内に作成し、クライアント３２０から受信した情報に応じて、実行環境の環境設定を行ってもよい。

サーバ３１０内に生成される上記実行環境は、実施形態に応じて、例えば、サーバ３１０上のプロセスであってもよいし、サーバ３１０（すなわち物理マシン）上の仮想マシンであってもよい。また、クライアント３２０用にサーバ３１０が実行する上記１つ以上のプログラムは、具体的には、ＯＳを含み、さらにアプリケーションプログラムを含んでもよい。

次に、ステップＳ３０２で付加部３１５は、現在時刻を取得し、現在時刻を示す時刻情報（すなわちタイムスタンプ）を含む時刻合わせコマンドを生成する。そして、送信部３１３が時刻合わせコマンドをクライアント３２０に送信する。

次に、ステップＳ３０３でサーバ３１０は、イベントの発生を待つ。
そして、受信部３１１がクライアント３２０から入力通知を受信したというイベントが発生すると、処理はステップＳ３０４に移行する。入力通知は、図８のステップＳ２０３でクライアント３２０から送信される通知である。

あるいは、受信部３１１がクライアント３２０から可用帯域幅と過剰遅延時間の通知を受信したというイベントが発生すると、処理はステップＳ３０５に移行する。可用帯域幅と過剰遅延時間の通知は、図９のステップＳ２２０でクライアント３２０から送信される通知である。

ところで、サーバ３１０の生成部３１２は、所定の間隔で発火する（expire）画面取得タイマを有する。画面取得タイマは、具体的には、図５のＣＰＵ２４１の内蔵タイマにより実現されてもよい。

第２〜第４実施形態では、送信フレームレートの最大値が予め決められており、画面取得タイマが発火する間隔は、送信フレームレートの最大値に応じて予め設定される。以下では説明の便宜上、送信フレームレートの最大値が３０ｆｐｓであるものとする。したがって、画面取得タイマの発火間隔は、１／３０秒である。

画面取得タイマの発火というイベントが発生すると、処理はステップＳ３０３からステップＳ３０８へと移行する。

さて、入力通知が受信された場合、ステップＳ３０４で生成部３１２は、受信部３１１により受信された入力通知の内容に応じた入力割り込みを発生させる。そして、処理はステップＳ３０３に戻る。

なお、説明の簡略化のため図１０〜１１では省略しているが、ステップＳ３０１でのリモートデスクトップ初期化処理の完了後、生成部３１２は、上記実行環境上でＯＳの実行を開始する。生成部３１２がステップＳ３０４で発生させる入力割り込みは、アプリケーションプログラムを起動するトリガになる場合もあり得る（例えば、所定のアイコン上でのダブルクリック操作が通知された場合など）。この場合、生成部３１２は、発生させた入力割り込みに応じて、新たにアプリケーションプログラムの実行を開始する。

あるいは、生成部３１２がステップＳ３０４で発生させる入力割り込みは、起動済みのプログラム（例えば、ＯＳでもよいし、アプリケーションプログラムでもよい）に対する入力を表す場合もあり得る。この場合、生成部３１２は、起動済みのプログラムを実行する過程において、入力割り込みに応じた処理を行う。

例えば、テキストエディタが起動済みで、かつ、入力割り込みがキー入力に対応する場合があり得る。この場合、生成部３１２は、テキストエディタのプログラムを実行する過程において、入力割り込みに応じて、カーソル位置に文字を表示させるための処理を行ってもよい。

また、ＣＡＤアプリケーションが起動済みで、かつ、入力割り込みが、ＣＡＤアプリケーション内の「回転」などのコマンドの呼び出しのための入力（例えばメニューバーからのメニュー選択操作）に対応する場合があり得る。この場合、生成部３１２は、ＣＡＤアプリケーションのプログラムを実行する過程において、入力割り込みに応じて、ＣＡＤアプリケーション内のコマンドを呼び出してもよい。

また、入力割り込みが、起動済みのアプリケーションプログラムを終了させるための入力（例えば「終了」メニューを選択する操作）に対応する場合もあり得る。この場合、生成部３１２は、入力割り込みに応じて、当該アプリケーションプログラムの実行を終了する。

例えば上記に例示したようにして、生成部３１２は、クライアント３２０からの入力通知の内容に応じて、入力割り込みを発生させ、入力割り込みの内容に応じて、プログラムを実行する。

ここで、図１０〜１１の説明に戻る。ステップＳ３０５で調整部３１４は、受信部３１１により受信された可用帯域幅と過剰遅延時間の通知から、可用帯域幅を読み取る。そして、調整部３１４は、通知された可用帯域幅を記憶する。つまり、調整部３１４は、送信制御データ３１６中の可用帯域幅を、通知された値に書き換える。

次に、ステップＳ３０６で調整部３１４は、可用帯域幅と過剰遅延時間の通知から過剰遅延時間を読み取り、通知された過剰遅延時間が正か否かを判断する。過剰遅延時間が正ならば、処理はステップＳ３０７に移行する。逆に、過剰遅延時間が０以下ならば、処理はステップＳ３０３に戻る。

ステップＳ３０７で調整部３１４は、現在時刻を取得し、現在時刻に過剰遅延時間を足して、過剰遅延解消時刻を算出する。そして、調整部３１４は、送信制御データ３１６中の過剰遅延解消時刻を、算出した値に書き換える。

ステップＳ３０７で取得される現在時刻は、サーバ３１０の時計で表された時刻である。以下では説明の便宜上、ステップＳ３０７で取得される現在時刻を「Ｔ＿ｎｏｗ＿ｓ」と表記し、ステップＳ３０７で算出される過剰遅延解消時刻を「Ｔ＿ｓｏｌｖｅｄ」と表記する。ステップＳ３０７での過剰遅延解消時刻Ｔ＿ｓｏｌｖｅｄの算出は、式（１０）のとおりである。
T_solved = T_now_s+ExtraDelay (10)
過剰遅延解消時刻Ｔ＿ｓｏｌｖｅｄの算出後、処理はステップＳ３０３に戻る。

さて、画面取得タイマが発火した場合は、ステップＳ３０８で生成部３１２が画面全体の画像（すなわちフレーム画像）を取得する。

上記のとおり生成部３１２は１つ以上のプログラムの実行を続けており、プログラムの実行に応じて、クライアント３２０の表示部３２２の画面に表示するための画像を生成する。例えば、画像のデータは、サーバ３１０を実現するコンピュータ２４０のＲＡＭ２４３内の第１のメモリ領域に、無圧縮のビットマップ形式で記憶されていてもよい。第１のメモリ領域は、具体的には、クライアント３２０用に割り当てられたフレームバッファ中の領域であり、ある観点から見れば、クライアント３２０のＶＲＡＭをエミュレートするためのメモリ領域である。

生成部３１２は、プログラムを実行する過程において、プログラムの実行の進捗に応じて第１のメモリ領域内の一部または全部のデータを書き換えることで、画像を更新してもよい。生成部３１２は、ステップＳ３０８では、第１のメモリ領域から画像のデータを読み出すことで、画面全体の画像を取得してもよい。

そして、次のステップＳ３０９で生成部３１２は、今回ステップＳ３０８で取得した画像と、前回画面取得タイマが発火したときに取得した画像との差分を検出する。

例えば、ＲＡＭ２４３内において第１のメモリ領域とは別の第２のメモリ領域に、前回画面取得タイマが発火したときに生成部３１２が取得した画像のデータが格納されていてもよい。生成部３１２は、第１のメモリ領域と第２のメモリ領域の画像同士を比較することで、今回取得した画像と前回の画面の画像との差分を検出してもよい。なお、生成部３１２は、後述の動画圧縮におけるフレーム間予測や動き補償のために、第１と第２のメモリ領域とは別のメモリ領域に、さらに過去のフレーム画像を保持していてもよい。

次に、ステップＳ３１０で生成部３１２は、動画像用の圧縮アルゴリズムで圧縮する対象の領域（以下、「動画領域」という）を検出する。図２の例では領域１１１が動画領域である。動画領域を検出する方法は公知なので、詳しい説明は省略するが、例えば、生成部３１２は以下のようにして動画領域を検出してもよい。

図２に例示するように、画面がＨ×Ｖ個のブロックに分割されていてもよい。この場合、生成部３１２は、Ｈ×Ｖ個のブロックのそれぞれについて、ステップＳ３０９において当該ブロックで差分が検出された回数をカウントし、カウント結果を所定の閾値と比較してもよい。生成部３１２は、カウント結果が閾値以上のブロックを、高頻度で変更が生じているブロックだと判断し、カウント結果が閾値未満のブロックを、変更が生じる頻度が低いブロックだと判断してもよい。

例えば、生成部３１２は、各ブロックについて、ステップＳ３０８の直近のＱ回（Ｑ＞１）の実行においてそれぞれ差分が検出されたか否かを記憶してもよい。そして、生成部３１２は、各ブロックについて、Ｑ回のうち何回差分が検出されたかをカウントして、上記の閾値と比較してもよい。

以上のようにして、高頻度で変更が生じていることが検出されるブロックの個数は、０個の場合もあり得るし、１個の場合もあり得るし、複数個の場合もあり得る。

生成部３１２は、複数のブロックにおいて高頻度で変更が生じていることを検出した場合は、それら複数のブロックの各々を個別に動画領域と決定してもよい。

あるいは、高頻度で変更が生じていることが検出されたいくつかのブロック同士が、隣接または近接している場合もあり得る。この場合、生成部３１２は、隣接または近接するそれらのブロックを包含する矩形領域（例えば、隣接または近接するそれらのブロックを包含する最小の矩形領域）を、動画領域と決定してもよい。

例えば以上のようにして、生成部３１２は、ステップＳ３１０で動画領域を検出する。したがって、場合によっては、１つも動画領域が検出されないこともあり得るし、１つの動画領域が検出されることもあり得るし、離れ離れの複数の動画領域が検出されることもあり得る。

次に、ステップＳ３１１で調整部３１４は、送信制御データ３１６を参照して、現在の送信フレームレート（以下では「ＦＰＳ＿ｃｕｒ」と表記する）を取得する。そして、調整部３１４は、現在の送信フレームレートＦＰＳ＿ｃｕｒから、式（１１）により、送信時間間隔（以下では「Ｉｎｔ」と表記する）を算出する。
Int = 1/FPS_cur (11)

次に、ステップＳ３１２で調整部３１４は、現在時刻（以下では「Ｔ＿ｎｏｗ＿ｓ」と表記する）を取得する。また、調整部３１４は、送信制御データ３１６を参照して、最終送信時刻（以下では「Ｔ＿ｌａｓｔ」と表記する）を取得する。そして、調整部３１４は、現在時刻Ｔ＿ｎｏｗ＿ｓと最終送信時刻Ｔ＿ｌａｓｔの差が、ステップＳ３１１で算出した送信時間間隔Ｉｎｔより大きいか否かを判断する。すなわち、調整部３１４は、不等式（１２）が成り立つか否かを判断する。
T_now_s-T_last > Int (12)

不等式（１２）が成り立たない場合は、まだクライアント３２０に描画コマンドを送信しなくてよい。よって、処理はステップＳ３０３に戻る。逆に、不等式（１２）が成り立つ場合、クライアント３２０に描画コマンドを送信するか否かを決定するために、処理は図１１のステップＳ３１３に移行する。

ステップＳ３１３で調整部３１４は、過剰遅延解消時刻Ｔ＿ｓｏｌｖｅｄを算出済みか否かを判断する。具体的には、調整部３１４は、送信制御データ３１６を参照して、過剰遅延解消時刻Ｔ＿ｓｏｌｖｅｄとして有効な値（すなわち初期値とは別の値）が記憶されているか否かを判断する。

過剰遅延解消時刻Ｔ＿ｓｏｌｖｅｄとして有効な値が記憶されていれば、過剰遅延解消時刻Ｔ＿ｓｏｌｖｅｄは算出済みである。この場合、クライアント３２０に描画コマンドを送信するか否かは、過剰遅延解消時刻Ｔ＿ｓｏｌｖｅｄによる。よって、描画コマンドを送信するか否かを過剰遅延解消時刻Ｔ＿ｓｏｌｖｅｄに応じて決定するために、処理はステップＳ３１４に移行する。

逆に、過剰遅延時刻として無効な値が記憶されていれば、過剰遅延時刻はまだ算出されていない。この場合、クライアント３２０に描画コマンドを送信するか否かは、単に現在時刻Ｔ＿ｎｏｗ＿ｓと最終送信時刻Ｔ＿ｌａｓｔの差による。また、不等式（１２）が成り立つことは、ステップＳ３１２において確認済みである。よって、描画コマンドの生成と送信のために、処理はステップＳ３１５に移行する。

ステップＳ３１４で調整部３１４は、現在時刻Ｔ＿ｎｏｗ＿ｓが過剰遅延解消時刻Ｔ＿ｓｏｌｖｅｄ以降であるか否かを判断する。現在時刻Ｔ＿ｎｏｗ＿ｓが過剰遅延解消時刻Ｔ＿ｓｏｌｖｅｄよりも前であれば、まだクライアント３２０に描画コマンドを送信しない方がよいので、処理はステップＳ３０３に戻る。逆に、現在時刻Ｔ＿ｎｏｗ＿ｓが過剰遅延解消時刻Ｔ＿ｓｏｌｖｅｄ以降であれば、描画コマンドの生成と送信のために、処理はステップＳ３１５に移行する。

ところで、以下では説明の便宜上、ステップＳ３０９で生成部３１２が差分を検出した領域を「差分領域」という。例えば、ステップＳ３１０に関して例示したように、画面がＨ×Ｖ個のブロックに分割されている場合、ステップＳ３０９では、Ｈ×Ｖ個のブロックのうち、０個、１個、または複数個のブロックにおいて、差分が検出される。差分が検出された各ブロックが、１つの差分領域である。

ステップＳ３１５で生成部３１２は、各差分領域について、当該差分領域を動画像用の圧縮アルゴリズムで圧縮するか、それとも静止画像用の圧縮アルゴリズムで圧縮するかを、ステップＳ３１０での動画領域の検出結果に基づいて決定する。具体的には、差分領域が動画領域に含まれる場合、生成部３１２は、当該差分領域を動画像用の圧縮アルゴリズムで圧縮することに決める。逆に、差分領域が動画領域に含まれない場合、生成部３１２は、当該差分領域を静止画像用の圧縮アルゴリズムで圧縮することに決める。

例えば、図２の例では、領域１１２と１１３は、差分領域である。しかし、領域１１２と領域１１３は、動画領域である領域１１１に含まれない。よって、生成部３１２は、領域１１２と１１３の各々を静止画像用の圧縮アルゴリズムで圧縮することに決める。

そして、次のステップＳ３１６で生成部３１２は、各動画領域を動画像用の圧縮アルゴリズムで圧縮し、静止画像用の圧縮アルゴリズムで圧縮することに決めた各差分領域を、静止画像用の圧縮アルゴリズムで圧縮する。

なお、ステップＳ３１０に関して例示したように、いくつか差分領域を包含する矩形領域が動画領域として決定される場合もある。この場合、差分の検出されていないブロックが動画領域に含まれることもあり得るが、生成部３１２は矩形の動画領域全体を動画像用の圧縮アルゴリズムで圧縮する。例えば、図２の例では、生成部３１２は、領域１１１を動画像用の圧縮アルゴリズムで圧縮する。

続いて、ステップＳ３１７で調整部３１４は、送信制御データ３１６を参照して、可用帯域幅の通知をクライアント３２０から受信済みか否かを判断する。可用帯域幅として有効な値（すなわち初期値以外の値）が記憶されていれば、可用帯域幅の通知は受信済みなので、処理はステップＳ３１８に移行する。逆に、可用帯域幅として無効な値が記憶されていれば、可用帯域幅の通知はまだ受信されていないので、処理はステップＳ３２０に移行する。

ステップＳ３１８で調整部３１４は、送信制御データ３１６を参照して、可用帯域幅ＥｓｔＢＷの値を取得する。また、調整部３１４は、生成部３１２がステップＳ３１６で圧縮したデータの合計サイズを認識する。例えば、生成部３１２が調整部３１４に圧縮後のデータの合計サイズを通知してもよい。

そして、調整部３１４は、圧縮後のデータの合計サイズから、当該データをペイロードに含む描画コマンドのサイズを算出する。具体的には、描画コマンドの形式に応じて、調整部３１４は、各種ヘッダの長さなどを圧縮後のデータの合計サイズに足すことで、描画コマンドのサイズを算出する。以下では説明の便宜上、算出されるサイズを「Ｓｉｚｅ＿ｃｍｄ」と表記し、当該サイズはバイト単位で表されるものとする。

ここで、以下の（１５ａ）と（１５ｂ）の２点を仮定した場合に、可用帯域幅ＥｓｔＢＷの範囲内で各フレームに対応する描画コマンドの送信を繰り返すことが可能な最大のフレームレートのことを、「送信可能フレームレート」ということにする。

（１５ａ）各フレームに対応する描画コマンドのサイズが一定である。
（１５ｂ）具体的には、当該一定のサイズが、上記のようにして算出されたサイズＳｉｚｅ＿ｃｍｄである。

調整部３１４は、可用帯域幅ＥｓｔＢＷと描画コマンドのサイズＳｉｚｅ＿ｃｍｄから、送信可能フレームレート（以下、「ＦＰＳ＿ｆｅａｓｉｂｌｅ」と表記する）を算出する。上記の定義より、送信可能フレームレートＦＰＳ＿ｆｅａｓｉｂｌｅは、不等式（１３）を満たす最大の値である。よって、調整部３１４は、式（１４）にしたがって送信可能フレームレートＦＰＳ＿ｆｅａｓｉｂｌｅを算出する。
8×Size_cmd×FPS_feasible≦EstBW (13)
FPS_feasible = EstBW/(8×Size_cmd) (14)

以上のようにしてステップＳ３１８で送信可能フレームレートＦＰＳ＿ｆｅａｓｉｂｌｅが算出された後、処理はステップＳ３１９に移行する。すると、ステップＳ３１９で調整部３１４は、送信制御データ３１６を参照して、現在の送信フレームレートＦＰＳ＿ｃｕｒを読み取る。そして、調整部３１４は、送信フレームレートＦＰＳ＿ｃｕｒと送信可能フレームレートＦＰＳ＿ｆｅａｓｉｂｌｅに基づいて、新たな送信フレームレートを設定する。例えば、調整部３１４は以下のようにして新たな送信フレームレートを設定してもよい。

ステップＳ３０８に関して説明したように、第２〜第４実施形態では、送信フレームレートの最大値が予め決められている。以下では説明の便宜上、送信フレームレートの最大値を「ＦＰＳ＿ｍａｘ」と表記する。調整部３１４は、送信フレームレートの現在の値ＦＰＳ＿ｃｕｒと送信可能フレームレートＦＰＳ＿ｆｅａｓｉｂｌｅの平均値と、送信フレームレートの最大値ＦＰＳ＿ｍａｘのうち、小さい方の値を、新たに送信フレームレートとして設定してもよい。

すなわち、調整部３１４は、式（１５）の右辺にしたがって新たな送信フレームレートを算出し、算出した値を、送信制御データ３１６中の送信フレームレートとして記憶してもよい。式（１５）の左辺の「ＦＰＳ＿ｃｕｒ」という記号は、算出された新たな送信フレームレートを示す。
FPS_cur = min(FPS_max, (FPS_cur+FPS_feasible)/2) (15)

あるいは、調整部３１４は、０＜Ｃ_３≦１なる適宜の定数Ｃ_３を用いて、式（１５）の代わりに式（１６）にしたがって、送信フレームレートＦＰＳ＿ｃｕｒを更新してもよい。式（１５）は、定数Ｃ_３が１／２の場合の例である。
FPS_cur = min(FPS_max, (1-C₃)×FPS_cur+C₃×FPS_feasible) (16)

また、ステップＳ３２０では、付加部３１５が現在時刻を取得する。付加部３１５はさらに、生成部３１２により圧縮されたデータに現在時刻を付加し、描画コマンドを生成する。

なお、上記のとおり、実施形態に応じて描画コマンドの形式は適宜定められていてよい。例えば、アプリケーション層のヘッダに時刻情報を含むよう定義された形式の描画コマンドが使われる実施形態では、付加部３１５は、ステップＳ３２０でアプリケーション層のヘッダ中の時刻情報用の所定のフィールドに、現在時刻を書き込む。あるいは、ペイロードに時刻情報を含むよう定義された形式の描画コマンドが使われる実施形態では、付加部３１５は、ステップＳ３２０でペイロード中の時刻情報用の所定のフィールドに、現在時刻を書き込む。

そして、ステップＳ３２１で付加部３１５は、送信制御データ３１６中の最終送信時刻を、ステップＳ３２０で現在時刻として取得した時刻で上書きする。

さらに、ステップＳ３２２で送信部３１３は、付加部３１５により生成された描画コマンドをクライアント３２０に送信する。そして、処理は図１０のステップＳ３０３に戻る。なお、ステップＳ３２１とＳ３２２の実行順序は入れ替えられてもよい。

以上説明した第２実施形態によれば、クライアント３２０とサーバ３１０の間のネットワークの可用帯域幅が狭くても、可用帯域幅に応じたフレームレートで画面情報が送信される。よって、遅延の累積を回避することができ、ある程度満足な操作レスポンス性能が得られる。つまり、ネットワーク状況が悪くても、ユーザビリティの低下は抑えられる。このような第２実施形態の利点について、図１２を参照してさらに説明する。

図１２は、過剰遅延時間と受信ビットレートの変化の例を示すグラフである。図１２のグラフ４００には、過剰遅延時間を示す曲線４０１と、クライアント３２０における受信ビットレートを示す曲線４０２が描かれている。

図１２の例では、受信ビットレートはあまり大きく変動はしていない。しかし、例えばデフォルトの送信フレームレートが実際の可用帯域幅に対して過大である場合などに、曲線４０１に示すように、過剰遅延時間が次第に増加していく事態に陥ることがあり得る。図１２の例では、時刻Ｔ１において、過剰遅延時間は閾値（図９の例では３００ｍｓ）を超える。

しかし、第２実施形態によれば、過剰遅延時間が閾値を超えると、クライアント３２０がサーバ３１０に通知する可用帯域幅の推定値が下がるので、それに応じて送信フレームレートも下がる。また、サーバ３１０は、クライアント３２０から通知された過剰遅延時間に応じて、画面情報の送信を省略することがある（つまり、処理が図１１のステップＳ３１４から図１０のステップＳ３０３へと戻ることがある）。

よって、時刻Ｔ１の後、少し時間が経つと、サーバ３１０からクライアント３２０への通信トラフィックも減り、次第に過剰遅延時間は短くなってゆく。そして、曲線４０１に示すように、過剰遅延時間は、やがて小さな値で安定する。つまり、第２実施形態によれば、ネットワーク状況によって仮に一時的に過剰遅延時間が長くなってユーザビリティが多少悪化するとしても、フレームレートの調整により、ユーザビリティは、ある程度満足なレベルにまで回復する。

続いて、第３実施形態について説明する。図１３は、第３実施形態のクライアントの動作フローチャートである。なお、図８のステップＳ２０１〜Ｓ２１３は第３実施形態にも共通である。図１３と図９を比較すれば分かるように、第３実施形態では、ステップＳ２１５とＳ２１６の間にステップＳ４０１〜Ｓ４０４が追加されている。

推定部３２６は、ステップＳ２１４で送信時刻Ｔ＿ｓｅｎｔを取得し、ステップＳ２１５で式（５）により推定送信時刻ＥｓｔＴ＿ｓｅｎｔを算出する。ステップＳ２１４とＳ２１５は図９と同様である。

その後、ステップＳ４０１で推定部３２６は、以下の（１６ａ）〜（１６ｃ）の値を用いて、直近の受信ビットレートを算出する。

（１６ａ）受信部３２４が、今回データ（つまり描画コマンド）を受信した時刻。換言すれば、受信履歴データ３２７の最新のエントリに記憶されている受信時刻Ｔ＿ｒｃｖ_Ｒ。
（１６ｂ）ステップＳ２１５で算出した推定送信時刻ＥｓｔＴ＿ｓｅｎｔ。
（１６ｃ）受信部３２４が今回受信したデータのサイズ。換言すれば、受信履歴データ３２７の最新のエントリに記憶されているデータサイズＳｉｚｅ＿ｒｃｖ_Ｒ。

以下では説明の便宜上、ステップＳ４０１で算出される直近の受信ビットレートを「ＢＰＳ＿ｌａｔｅｓｔ」とも表記する。推定部３２６は、具体的には、式（１７）にしたがって直近の受信ビットレートＢＰＳ＿ｌａｔｅｓｔを算出する。
BPS_latest = 8×Size_rcv_R/(T_rcv_R-EstT_sent) (17)

次に、ステップＳ４０２で推定部３２６は、直近の受信ビットレートＢＰＳ＿ｌａｔｅｓｔが現在の可用帯域幅ＥｓｔＢＷと比べて十分に大きいか否かを判断する。具体的には、推定部３２６は、不等式（１８）が成立するか否かを判断する。
BPS_latest > (1+C₄)×EstBW (18)

なお、不等式（１８）における「Ｃ_４」は、適宜の正の定数である。図１３には、定数Ｃ_４が０．１の場合が例示されている。図１３に示すように、定数Ｃ_４が例えば０．１の場合、推定部３２６は、具体的には、直近の受信ビットレートＢＰＳ＿ｌａｔｅｓｔが現在の可用帯域幅ＥｓｔＢＷの１．１倍を超えるか否かを判断する。

不等式（１８）が成り立つ場合、処理はステップＳ４０３に移行する。不等式（１８）が成り立たない場合、処理はステップＳ２１６に移行する。

なお、不等式（１８）では、可用帯域幅ＥｓｔＢＷに１より大きい所定の値を掛けた値が、直近の受信ビットレートＢＰＳ＿ｌａｔｅｓｔと比較するための判定基準値として使われている。しかし、実施形態によっては、可用帯域幅ＥｓｔＢＷに所定の正の値を足した値が、判定基準値として使われてもよい。

ステップＳ４０３で推定部３２６は、直近の受信ビットレートＢＰＳ＿ｌａｔｅｓｔに応じて、可用帯域幅ＥｓｔＢＷの値を大きくする。例えば、式（１９）に示すように、推定部３２６は、直近の受信ビットレートＢＰＳ＿ｌａｔｅｓｔを新たな可用帯域幅ＥｓｔＢＷとして記憶してもよい。
EstBW = BPS_latest (19)

あるいは、式（２０）に示すように、推定部３２６は、現在の可用帯域幅ＥｓｔＢＷと直近の受信ビットレートＢＰＳ＿ｌａｔｅｓｔとの平均値を、新たな可用帯域幅ＥｓｔＢＷとして記憶してもよい。
EstBW = (EstBW+BPS_latest)/2 (20)

なお、推定部３２６は、０＜Ｃ_５≦１なる適宜の定数Ｃ_５を用いて、式（２１）にしたがって新たな可用帯域幅ＥｓｔＢＷを算出してもよい。
EstBW = (1-C₅)×EstBW+C₅×BPS_latest (21)

式（１９）は、式（２１）における定数Ｃ_５が１の場合の具体例である。また、式（２０）は、式（２１）における定数Ｃ_５が１／２の場合の具体例である。

定数Ｃ_５の値が１に近いほど、実際の可用帯域幅が急激に増加した場合に、可用帯域幅の推定値ＥｓｔＢＷを実際の可用帯域幅の増加に素早く追従させることができる。例えば式（１９）が使われる場合、ネットワーク状況の好転に素早く対応して、フレームレートを上昇させ、フレームレートの上昇によってクライアント３２０の表示部３２２の表示をより滑らかにすることが可能である。

また、定数Ｃ_５が小さいほど、可用帯域幅ＥｓｔＢＷの変化は緩やかになる。例えば式（２０）を使うことには、可用帯域幅の変動が激しい場合にも安定した制御を可能とする効果がある。

なお、不等式（１８）が成り立つので、式（１９）〜（２１）のいずれが使われる場合も、可用帯域幅ＥｓｔＢＷの値は増加する。具体的には、可用帯域幅ＥｓｔＢＷの値は、今までの値の（１＋Ｃ_４×Ｃ_５）倍の値を超えることになる。

続いて、ステップＳ４０４で推定部３２６は、ステップＳ４０３で更新した可用帯域幅ＥｓｔＢＷを用いて、式（４）により推定転送時間ＥｓｔＴ＿ｔｒａｎｓを再計算する。そして、処理はステップＳ２１６に移行する。

ステップＳ２１６で推定部３２６は、式（６）により、過剰遅延時間ＥｘｔｒａＤｅｌａｙを算出する。式（４）と（６）から分かるように、上記のステップＳ４０３で可用帯域幅ＥｓｔＢＷが更新された場合は、ステップＳ２１６で算出される過剰遅延時間ＥｘｔｒａＤｅｌａｙにも可用帯域幅ＥｓｔＢＷの更新が反映される。

そして、ステップＳ２１７で推定部３２６は、過剰遅延時間ＥｘｔｒａＤｅｌａｙが３００ｍｓより長いのか、０ｍｓより長く３００ｍｓ以下なのか、それとも０ｍｓ以下なのかを判断する。

過剰遅延時間ＥｘｔｒａＤｅｌａｙが３００ｍｓより長ければ、推定部３２６は、ステップＳ２１８で式（７）にしたがって可用帯域幅データ３２９を更新する（すなわち可用帯域幅ＥｓｔＢＷの値を減少させる）。実施形態によっては、式（７）の代わりに式（８）が使われてもよい。そして、推定部３２６は、ステップＳ２１９で過剰遅延時間ＥｘｔｒａＤｅｌａｙを再計算する。その後、ステップＳ２２０で可用帯域幅ＥｓｔＢＷと過剰遅延時間ＥｘｔｒａＤｅｌａｙが送信部３２３からサーバ３１０に通知される。

過剰遅延時間ＥｘｔｒａＤｅｌａｙが０ｍｓより長く３００ｍｓ以下であれば、ステップＳ２２０で可用帯域幅ＥｓｔＢＷと過剰遅延時間ＥｘｔｒａＤｅｌａｙが送信部３２３からサーバ３１０に通知される。

過剰遅延時間ＥｘｔｒａＤｅｌａｙが０ｍｓ以下ならば、推定部３２６は、ステップＳ２２１で式（９）にしたがって可用帯域幅データ３２９を更新する（すなわち可用帯域幅ＥｓｔＢＷの値を増加させる）。そして、推定部３２６は、ステップＳ２２２で過剰遅延時間ＥｘｔｒａＤｅｌａｙを再計算する。その後、ステップＳ２２０で可用帯域幅ＥｓｔＢＷと過剰遅延時間ＥｘｔｒａＤｅｌａｙが送信部３２３からサーバ３１０に通知される。
ステップＳ２２０での通知の後、処理は図８のステップＳ２０２に戻る。

なお、図１３から分かるように、第３実施形態では、以下の（１７ａ）〜（１７ｃ）のいずれの場合もあり得る。以下の（１７ａ）〜（１７ｃ）のいずれの場合も、推定部３２６が可用帯域幅ＥｓｔＢＷを増加させるという点と、増加した可用帯域幅ＥｓｔＢＷがサーバ３１０に通知されるという点では共通である。

（１７ａ）ステップＳ４０３とＳ２２１の両方が実行される場合。
（１７ｂ）ステップＳ４０３は実行され、ステップＳ２２１は実行されない場合。
（１７ｃ）ステップＳ４０３は実行されず、ステップＳ２２１が実行される場合。

また、ステップＳ４０２の式（１８）における定数Ｃ_４と、ステップＳ４０３の式（２１）における定数Ｃ_５と、ステップＳ２２１の式（９）における定数Ｃ_２は、実施形態に応じて適宜に決められてよい。例えば、３つの定数は、不等式（２２）を満たすように決められていてもよい。
C₂ ≦ C₄×C₅ (22)

不等式（２２）は、可用帯域幅の推定値ＥｓｔＢＷの算出において、ステップＳ２２１に相当する下記（１８ａ）の判断よりも、ステップ４０３に相当する下記（１８ｂ）の追従の方を重視することを意味する。

（１８ａ）過剰遅延時間が所定の閾値（具体的には、ステップＳ２１７で使われる０ｍｓという値）以下の場合における、「可用帯域幅の実際の値は、現在の推測値よりも大きい可能性がある」という判断。
（１８ｂ）実際の直近のビットレートの増加への追従。

なお、第３実施形態は以下のように変形されてもよい。具体的には、ステップＳ４０３が実行された場合、ステップＳ４０４とＳ２１６の実行後、推定部３２６は、ステップＳ２１７の判断を省略して、可用帯域幅ＥｓｔＢＷと過剰遅延時間ＥｘｔｒａＤｅｌａｙを送信部３２３に出力してもよい。そして、ステップＳ２２０で送信部３２３が可用帯域幅ＥｓｔＢＷと過剰遅延時間ＥｘｔｒａＤｅｌａｙをサーバ３１０に通知してもよい。

続いて、第４実施形態について説明する。以下に述べるように、第４実施形態には、可用帯域幅の推定精度を向上させる効果がある。

具体的には、第４実施形態では、過剰遅延時間ＥｘｔｒａＤｅｌａｙが所定の閾値（例えば０ｍｓ）以下の場合に、クライアント３２０は、すぐに可用帯域幅の推定値ＥｓｔＢＷを増加させる代わりに、今までの推定値よりも大きな値をサーバ３１０に通知する。クライアント３２０は、大きな値をサーバ３１０に通知することにより、間接的に送信フレームレートを制御する（具体的には、上昇させる）。

サーバ３１０が送信する描画コマンドのデータサイズは、実行中のアプリケーションやユーザからの入力に応じて変動する。しかし、大まかな傾向としては、送信フレームレートが高いほど、単位時間あたりにサーバ３１０がクライアント３２０に送信するデータの量も多い。

よって、実際の可用帯域幅が可用帯域幅の現在の推定値よりも大きければ、送信フレームレートが上昇しても経路上でデータが滞留することはないと考えられる。つまり、実際の可用帯域幅が可用帯域幅の現在の推定値よりも大きければ、送信フレームレートの上昇に応じて受信ビットレートも上昇すると考えられる。

よって、クライアント３２０は、上記のように大きな値をサーバ３１０に通知した後に、実際にクライアント３２０における受信ビットレートの上昇を確認したら、そのときに可用帯域幅の推定値ＥｓｔＢＷを増加させる。つまり、クライアント３２０は、送信フレームレートの上昇に対処するだけの余裕が実際の可用帯域幅にあったことを確認してから、可用帯域幅の推定値ＥｓｔＢＷを増加させる。

以上のように、第４実施形態では、実際の受信ビットレートの上昇に基づいて可用帯域幅の推定値ＥｓｔＢＷをクライアント３２０が増加させるため、可用帯域幅の推定精度が向上する。可用帯域幅の推定精度の向上により、過剰遅延時間ＥｘｔｒａＤｅｌａｙの精度も向上する。よって、第４実施形態では、より実際の可用帯域幅に即した頻度で、画面情報（具体的には描画コマンド）が送信される。

なお、第４実施形態では、上記のように可用帯域幅の推定値ＥｓｔＢＷよりも大きな値をクライアント３２０がサーバ３１０に通知する場合もあるし、可用帯域幅の推定値ＥｓｔＢＷ自体をクライアント３２０がサーバ３１０に通知する場合もある。いずれの場合も、クライアント３２０は、通知した値を記憶する。

具体的には、第４実施形態においては、図６の可用帯域幅データ３２９は、図７の可用帯域幅データ３２９ｂのように、可用帯域幅だけでなく前回通知帯域幅を含む。クライアント３２０は、サーバ３１０に通知した値を、前回通知帯域幅として記憶する。以下では便宜上、前回通知帯域幅を「ＰｒｅｖＲｅｐＢＷ」と表記することがある。

続いて、図１４を参照して第４実施形態についてさらに詳しく説明する。図１４は、第４実施形態のクライアントの動作フローチャートである。なお、図８のステップＳ２０１〜Ｓ２１３は第４実施形態にも共通である。

図１４と図１３を比較すれば分かるように、第４実施形態では、図１３のステップＳ２１７とステップＳ２２０で挟まれた処理が、図１４の処理に置き換わる。つまり、第４実施形態では、図８のステップＳ２１３の後、図１３のステップＳ２１４、Ｓ２１５、Ｓ４０１、およびＳ４０２が実行される。さらに、ステップＳ４０２の判定結果によっては、ステップＳ４０３とＳ４０４も実行される。その後、ステップＳ２１６が実行されて過剰遅延時間ＥｘｔｒａＤｅｌａｙが算出されてから、図１４のステップＳ２１７が実行される。

よって、図１４のステップＳ２１７が実行される時点における可用帯域幅ＥｓｔＢＷの値は、以下の（１９ａ）〜（１９ｃ）のいずれかである。

（１９ａ）ステップＳ２１２で式（３）により算出された値。
（１９ｂ）ステップＳ４０３で式（２１）により更新された値。
（１９ｃ）今回の描画コマンドが受信された時点で既に可用帯域幅データ３２９ｂに可用帯域幅として記憶されていたままの値。

また、ステップＳ２１７において参照される過剰遅延時間ＥｘｔｒａＤｅｌａｙは、式（４）と（６）に示すように、可用帯域幅ＥｓｔＢＷに依存する。ステップＳ２１７では、第２〜第３実施形態と同様に、推定部３２６が、過剰遅延時間ＥｘｔｒａＤｅｌａｙが０ｍｓ以下なのか、０ｍｓより長く３００ｍｓ以下なのか、それとも３００ｍｓより長いのかを判断する。

過剰遅延時間ＥｘｔｒａＤｅｌａｙが０ｍｓ以下の場合、処理はステップＳ５０１に移行する。過剰遅延時間ＥｘｔｒａＤｅｌａｙが０ｍｓより長く３００ｍｓ以下の場合、処理はステップＳ５０２に移行する。過剰遅延時間ＥｘｔｒａＤｅｌａｙが３００ｍｓより長い場合、処理はステップＳ５０３に移行する。

ステップＳ５０１で推定部３２６は、図９や図１３のステップＳ２２１のように可用帯域幅ＥｓｔＢＷの値を増加させる代わりに、可用帯域幅ＥｓｔＢＷよりも大きな値を通知帯域幅として設定する。以下では便宜上、通知帯域幅を「ＲｅｐＢＷ」とも表記する。

通知帯域幅ＲｅｐＢＷは、クライアント３２０がサーバ３１０に通知する値である。後述のように、可用帯域幅ＥｓｔＢＷ自体が通知帯域幅ＲｅｐＢＷとして使われる場合もある。

具体的には、ステップＳ５０１で推定部３２６は、比較的小さな正の適宜の定数Ｃ_６を用いて、式（２３）により通知帯域幅ＲｅｐＢＷの値を決定する。図１４には、Ｃ_６＝０．１の場合が例示されている。
RepBW = (1+C₆)×EstBW (23)

なお、上記（１９ｂ）に示すとおり、式（２３）の可用帯域幅ＥｓｔＢＷは、ステップＳ４０３で増加した値の場合もあり得る。この場合、ある観点から見れば、式（２３）により算出される通知帯域幅ＲｅｐＢＷは、可用帯域幅ＥｓｔＢＷの増加を強調して示す１種の指標値でもある。

実施形態によっては、推定部３２６は、式（２３）のように１より大きい所定の値を可用帯域幅ＥｓｔＢＷに掛ける代わりに、所定の正の値を可用帯域幅ＥｓｔＢＷに足すことで、通知帯域幅ＲｅｐＢＷを算出してもよい。

なお、ステップＳ５０１が実行されるのは過剰遅延時間ＥｘｔｒａＤｅｌａｙが０ｍｓ以下の場合である。この場合、「可用帯域幅の現在の推定値ＥｓｔＢＷが実際の値と比べて過小である」という可能性がある。よって、この可能性が実際に成り立つのか否かを検証するため、推定部３２６は、ステップＳ５０１で通知帯域幅ＲｅｐＢＷを可用帯域幅ＥｓｔＢＷよりも大きく設定する。ステップＳ５０１の実行後、処理はステップＳ５０５へと移行する。

ステップＳ５０２で推定部３２６は、可用帯域幅ＥｓｔＢＷの現在の値を通知帯域幅ＲｅｐＢＷとして設定する。つまり、ステップＳ５０２は式（２４）のように表される。ステップＳ５０２の実行後、処理はステップＳ５０５へと移行する。
RepBW = EstBW (24)

ステップＳ５０３で推定部３２６は、可用帯域幅データ３２９ｂを参照し、可用帯域幅ＥｓｔＢＷが前回通知帯域幅ＰｒｅｖＲｅｐＢＷ未満か否かを判断する。すなわち、推定部３２６は、不等式（２５）が成り立つか否かを判断する。
EstBW < PrevRepBW (25)

不等式（２５）が成り立つ場合、処理はステップＳ５０２に移行する。逆に、不等式（２５）が成り立たない場合、処理はステップＳ２１８に移行する。なお、ステップＳ５０３での判断の意味については、ステップＳ５０６まで説明してから述べる。

ステップＳ２１８で推定部３２６は、以下に再掲する式（７）にしたがって（あるいは、式（７）を一般化した式（８）にしたがって）、可用帯域幅ＥｓｔＢＷを更新する。図１４には、ステップＳ２１８で式（７）が使われる場合が例示されている。
EstBW = (EstBW+BPS_avr)/2 (7)
EstBW = (1-C₁)×EstBW+C₁×BPS_avr (8)

そして、次のステップＳ２１９で推定部３２６は、ステップＳ２１８で更新した可用帯域幅ＥｓｔＢＷを用いて、過剰遅延時間ＥｘｔｒａＤｅｌａｙを再計算する。第２実施形態に関して説明したように、再計算による値の変化は比較的小さいので、ステップＳ２１９での再計算は省略されてもよい。

さらに、次のステップＳ５０４で推定部３２６は、ステップＳ２１８で更新した可用帯域幅ＥｓｔＢＷの値を、通知帯域幅ＲｅｐＢＷとして設定する。ステップＳ５０４は式（２６）のように表される。
RepBW = EstBW (26)

通知帯域幅ＲｅｐＢＷの設定後、処理はステップＳ５０５に移行する。なお、実施形態によっては、ステップＳ２１９とＳ５０４の実行順序が入れ替えられてもよい。

ステップＳ５０５では、推定部３２６が通知帯域幅ＲｅｐＢＷと過剰遅延時間ＥｘｔｒａＤｅｌａｙを送信部３２３に出力する。すると、送信部３２３は、通知帯域幅ＲｅｐＢＷと過剰遅延時間ＥｘｔｒａＤｅｌａｙを含む通知をサーバ３１０に送信する。

なお、サーバ３１０は、クライアント３２０から通知された通知帯域幅ＲｅｐＢＷを可用帯域幅ＥｓｔＢＷとして扱う。よって、クライアント３２０が通知した通知帯域幅ＲｅｐＢＷは、図１０のステップＳ３０５において、サーバ３１０の送信制御データ３１６における可用帯域幅ＥｓｔＢＷとして記憶される。

さて、ステップＳ５０５の実行後、ステップＳ５０６で推定部３２６は、通知帯域幅ＲｅｐＢＷを、可用帯域幅データ３２９ｂ中の前回通知帯域幅ＰｒｅｖＲｅｐＢＷとして記憶する。そして、処理は図８のステップＳ２０２に戻る。なお、実施形態によっては、ステップＳ５０５とＳ５０６の実行順序が入れ替えられてもよい。

ここで、ステップＳ５０３の判断の意味を説明する。ステップＳ５０３で不等式（２５）が成り立つ場合とは、具体的には、前回ステップＳ５０１で可用帯域幅ＥｓｔＢＷよりも大きく設定された値が、前回通知帯域幅ＰｒｅｖＲｅｐＢＷとして記憶されている場合である。また、ステップＳ５０３が実行されるのは、過剰遅延時間ＥｘｔｒａＤｅｌａｙが３００ｍｓより長い場合である。

したがって、ステップＳ５０３において不等式（２５）が成り立つことは、「可用帯域幅の推定値ＥｓｔＢＷが実際の値と比べて過小なのか否かを検証したら、可用帯域幅の推定値ＥｓｔＢＷが過小でないことが判明した」ということを意味する。より詳しくは以下のとおりである。

上記のように、ステップＳ５０１で、推定部３２６は、可用帯域幅の推定値ＥｓｔＢＷが実際の値と比べて過小なのか否かを検証するために、可用帯域幅の推定値ＥｓｔＢＷよりも大きく通知帯域幅ＲｅｐＢＷを設定することがある。クライアント３２０は、こうして大きく設定した通知帯域幅ＲｅｐＢＷをサーバ３１０に通知する。

その結果、サーバ３１０が送信フレームレートを上昇させ、単位時間当たりの通信トラフィックが増える。一方、もし可用帯域幅の推定値ＥｓｔＢＷが実際の値と比べて過小でないならば、以上のような単位時間当たりの通信トラフィックの増加の結果として、サーバ３１０からクライアント３２０への経路上でデータの滞留が生じ、過剰遅延時間も長くなる。

このようにして過剰遅延時間が３００ｍｓという閾値を超えてしまう場合、可用帯域幅ＥｓｔＢＷは、クライアント３２０が以前サーバ３１０に通知した通知帯域幅ＲｅｐＢＷより小さい。なぜなら、推定部３２６はまだ可用帯域幅ＥｓｔＢＷを増加させてはいないからである。

また、このようにして過剰遅延時間が３００ｍｓを超えてしまう場合は、クライアント３２０が前回サーバ３１０に通知した通知帯域幅ＲｅｐＢＷは、実際の可用帯域幅と比べて過大である。つまり、現在可用帯域幅データ３２９ｂに記録されている前回通知帯域幅ＰｒｅｖＲｅｐＢＷは過大なのであって、むしろ可用帯域幅ＥｓｔＢＷが適正である。換言すれば、可用帯域幅ＥｓｔＢＷは過小ではない。

ステップＳ５０３からステップＳ５０２への処理の流れは、以上のようにして可用帯域幅ＥｓｔＢＷが過小ではなく適正であることが確認された場合に、その適正な可用帯域幅ＥｓｔＢＷをクライアント３２０がサーバ３１０に通知しなおすことを意味する。

他方、たとえステップＳ５０１が実行されることがないとしても、ネットワークの状況の変化によっては、過剰遅延時間が３００ｍｓを超えてしまう場合もあり得る。その場合は、現在の可用帯域幅ＥｓｔＢＷですら過大であるから、クライアント３２０は、現在の可用帯域幅ＥｓｔＢＷよりも小さな値をサーバ３１０に通知することが望ましい。

ステップＳ５０３からステップＳ２１８への処理の流れは、以上のようにクライアント３２０によるステップＳ５０１の処理とは無関係に起こり得るネットワーク状況の悪化に起因する過剰遅延時間の増大への対処を意味する。

クライアント３２０の動作とは関係なくネットワーク状況が悪化した場合は、以前ステップＳ５０２またはＳ５０４で設定された通知帯域幅ＲｅｐＢＷが前回通知帯域幅ＰｒｅｖＲｅｐＢＷとして現在記憶されている。よって、推定部３２６は、ステップＳ５０３で可用帯域幅ＥｓｔＢＷが前回通知帯域幅ＰｒｅｖＲｅｐＢＷ以上であると判断し、ステップＳ２１８で可用帯域幅ＥｓｔＢＷを減少させる。そして、推定部３２６は、ステップＳ５０４で、減少させた可用帯域幅ＥｓｔＢＷを、新たに通知帯域幅ＲｅｐＢＷとして設定する。その結果、ステップＳ５０５では、減少させた可用帯域幅ＥｓｔＢＷがサーバ３１０に通知される。

なお、可用帯域幅の推定値ＥｓｔＢＷが実際の値と比べて過小なのか否かを検証するために推定部３２６がステップＳ５０１で通知帯域幅ＲｅｐＢＷを大きく設定した後、可用帯域幅の推定値ＥｓｔＢＷが過小だと判明する場合もあり得る。具体的には、次のような場合である。

もし可用帯域幅の推定値ＥｓｔＢＷが過小ならば、ステップＳ５０１で可用帯域幅の推定値ＥｓｔＢＷよりも大きく設定された通知帯域幅ＲｅｐＢＷがサーバ３１０に通知されると、クライアント３２０における実際の受信ビットレートが上昇する。つまり、ステップＳ５０１の実行後の受信ビットレートの上昇により、可用帯域幅の推定値ＥｓｔＢＷが過小であることが判明する。

具体的には、ステップＳ４０２で受信ビットレートの上昇が検出される場合、可用帯域幅の推定値ＥｓｔＢＷが過小であることが判明する。よって、この場合、ステップＳ４０３で推定部３２６は、上昇した実際の受信ビットレートに基づいて、可用帯域幅の推定値ＥｓｔＢＷを増加させる。

以上のように、第４実施形態では、ステップＳ４０２の判断は、ステップＳ５０１での通知帯域幅ＲｅｐＢＷの設定と関連する場合がある。よって、ステップＳ４０２の式（１８）の定数Ｃ_４と、ステップＳ５０１の式（２３）の定数Ｃ_６は、定数Ｃ_４が定数Ｃ_６よりもわずかに小さくなるように定められていることが好ましい。

ところで、以上説明した第４実施形態では、図７の可用帯域幅データ３２９ｂに含まれる通知帯域幅の履歴は、過去の１つの通知帯域幅（すなわち前回通知帯域幅ＰｒｅｖＲｅｐＢＷ）のみである。しかし、実施形態によっては、過去の２つ以上の通知帯域幅を可用帯域幅データ３２９ｂが含んでいてもよい。この場合、ステップＳ５０３で推定部３２６は、例えば、過去の２つ以上の通知帯域幅のうち、１つでも可用帯域幅より大きいものがあるか否かを判断してもよい。

そして、過去の２つ以上の通知帯域幅のうち、１つでも可用帯域幅より大きいものがあれば、処理がステップＳ５０３からステップＳ５０２へと移行する。逆に、過去の２つ以上の通知帯域幅のすべてが可用帯域幅以下ならば、処理はステップＳ５０３からＳ２１８へと移行する。

あるいは、ステップＳ５０３で推定部３２６は、１より大きい所定の定数Ｃ_７を用いて、過去の２つ以上の通知帯域幅のうち、１つでも、定数Ｃ_７を可用帯域幅に乗じた基準値より大きいものがあるか否を判断してもよい。そして、過去の２つ以上の通知帯域幅のうち、１つでも基準値より大きいものがあれば、処理がステップＳ５０３からステップＳ５０２へと移行する。逆に、過去の２つ以上の通知帯域幅のすべてが基準値以下ならば、処理はステップＳ５０３からＳ２１８へと移行する。

なお、所定の定数Ｃ_７は、例えば、ステップＳ５０１で使われる定数Ｃ_６との間に不等式（２７）の関係が成り立つように定められていてもよい。
1 < C₇ < (1+C₆) (27)

また、過去の２つ以上の通知帯域幅を可用帯域幅データ３２９ｂに記憶するために、リングバッファが使われてもよい。ステップＳ５０６では、推定部３２６は、今回設定した通知帯域幅を、１番近い過去の通知帯域幅として記憶すればよい。

以上のように、過去の２つ以上の通知帯域幅を含む可用帯域幅データ３２９ｂを利用する実施形態は、通知帯域幅の上昇から送信フレームレートの上昇を経て遅延の累積に至るまでにある程度のタイムラグが生じる場合にも好適である。

なお、本発明は上記の第１〜第４実施形態に限られるものではなく、上記の第１〜第４実施形態は様々に変形可能である。以下に、変形に関するいくつかの観点を例示する。例えば、上記の第１〜第４実施形態は、下記の観点から様々に変形することができ、これらの変形は、相互に矛盾しない限り、任意に組み合わせることが可能である。

上記の第１〜第４実施形態におけるいくつかの処理は、閾値との比較を含む。例えば、図９のステップＳ２１７、図１０のステップＳ３０６とＳ３１２、図１１のステップＳ３１４、図１３のステップＳ４０２とＳ２１７、図１４のステップＳ２１７とＳ５０３では、閾値との比較が行われる。

閾値との比較は、実施形態により「比較対象の数値が、閾値を超えるか否か」を判断する処理でもよいし、「比較対象の数値が、閾値以上か否か」を判断する処理でもよい。また、上記の説明では様々な用途の閾値を例示したが、各閾値の具体的な値は、実施形態に応じて適宜任意に決められてよい。

図７にはテーブル形式で各種データを示したが、実施形態に応じて他のデータ形式が使われてもよい。

また、第２〜第４実施形態では時刻合わせコマンドが使われるが、実施形態によっては、時刻合わせコマンドが使われなくてもよい。代わりに、ＮＴＰ（Network Time Protocol）またはＳＮＴＰ（Simple Network Time Protocol）などのプロトコルにしたがって、クライアント３２０の時計をサーバ３１０の時計に同期させる処理が事前に行われてもよい。例えば、図８のステップＳ２０１と図１０のステップＳ３０１に示すリモートデスクトップ初期化処理が、ＮＴＰまたはＳＮＴＰによる同期処理を含んでいてもよい。

また、時刻合わせコマンドが使われる実施形態において、サーバ３１０は、時刻合わせコマンドを１回だけ送信するのではなく、定期的に、または不定期に、複数回、時刻合わせコマンドを送信してもよい。その場合、クライアント３２０の受信部３２４は、時刻合わせコマンドを受信するたびに時刻差データ３２８を更新する。

なお、図６には１台のクライアント３２０が描かれているが、サーバ３１０は、複数のクライアント３２０のそれぞれに対して画像を生成し、画面情報と時刻情報を含む描画コマンドを送信してもよい。その場合、サーバ３１０は、クライアント３２０ごとに送信制御データ３１６を管理する。クライアント３２０ごとの管理のために、送信制御データ３１６は、クライアント３２０を識別する識別情報をさらに含んでいてもよい。

また、クライアント３２０が複数台の場合、サーバ３１０は、複数のクライアント３２０のそれぞれに対応して独立に図１０〜１１の処理を実行する。例えば、サーバ３１０は、複数のスレッドで並行してそれぞれ図１０〜１１の処理を実行してもよい。つまり１つのスレッドが１台のクライアント３２０に対応していてもよい。

また、図８〜１１、１３、および１４のように、いくつか具体的なフローチャートを例示したが、矛盾が生じない限り、実施形態に応じて、ステップの実行順序が入れ替えられてもよい。また、入れ替え可能なステップ同士（すなわち互いに独立したステップ同士）は、並列に実行されてもよい。

ステップの実行順序の入れ替えやステップの省略については、いくつかの例を上記の説明においても述べたが、さらに、例えば以下のような変更も可能である。
例えば、クライアント３２０は、第２〜第４実施形態のように過剰遅延時間をサーバ３１０に通知することが好ましいが、過剰遅延時間をサーバ３１０に通知しなくてもよい。過剰遅延時間が通知されない実施形態では、ステップＳ３０７、Ｓ３１３、およびＳ３１４は省略される。

また、クライアント３２０は、第２〜第４実施形態のように、描画コマンドの受信のたびに、可用帯域幅と過剰遅延時間の算出と通知を行ってもよい。しかし、可用帯域幅と過剰遅延時間の通知に起因するネットワーク負荷を減少させるため、クライアント３２０は、描画コマンドをＮ_１回受信するごとに１回だけ、可用帯域幅と過剰遅延時間の算出と通知を行ってもよい（Ｎ_１＞１）。クライアント３２０が可用帯域幅と過剰遅延時間の算出と通知を行わない場合には、図８のステップＳ２０９の実行後、処理はステップＳ２０２に戻る。

あるいは、クライアント３２０は、描画コマンドの受信のたびに可用帯域幅と過剰遅延時間を算出し、直近のＮ_２回の描画コマンドの受信のときに算出した可用帯域幅と過剰遅延時間の値の履歴を保持してもよい（Ｎ_２≧１）。そして、クライアント３２０は、履歴を参照して、可用帯域幅の変化の大きさまたは変化の傾向を判断してもよく、過剰遅延時間の変化の大きさまたは変化の傾向を判断してもよい。

クライアント３２０は、可用帯域幅の変化の大きさもしくは変化の傾向が所定の基準を満たす場合か、または、過剰遅延時間の変化の大きさもしくは変化の傾向が所定の基準を満たす場合にだけ、可用帯域幅と過剰遅延時間をサーバ３１０に送信してもよい。例えば、上記の所定の基準は、以下の（２０ａ）〜（２０ｃ）に例示するような基準であってもよいし、その他の基準であってもよい。

（２０ａ）履歴中のＮ_２個の値のうちのいずれか（例えば最大値または最小値）と比べて、今回算出された値は、所定のパーセンテージ以上に大きく変化している。
（２０ｂ）履歴中のＮ_２個の値の平均値と比べて、今回算出された値は、所定のパーセンテージ以上に大きく変化している。
（２０ｃ）値がＮ_２回連続して増加しているか、または、Ｎ_２回連続して減少している。

例えば以上のようにして、可用帯域幅と過剰遅延時間を通知する場合を制限することにより、クライアント３２０は、可用帯域幅と過剰遅延時間の通知に起因するネットワーク負荷を抑えてもよい。

また、ステップＳ２０９での描画処理と、ステップＳ２１０以降の処理は、並列に実行されてもよい。ステップＳ２１０以降の処理（つまり、ステップＳ２２０またはＳ５０６までの処理）の後に、ステップＳ２０９が実行されてもよい。

あるいは、ステップＳ２１０がステップＳ２０４の直後に移動されてもよい。ステップＳ２１３がステップＳ２１５とＳ２１６の間に移動されてもよい。

送信制御データ３１６中の送信フレームレートの更新に関わるステップＳ３１７〜Ｓ３１９の処理は、描画コマンドの生成と送信に関わるステップＳ３１５〜Ｓ３１６およびＳ３２０〜Ｓ３２２の処理とは独立している。よって、これら２つの処理は、並列に実行されてもよい。

また、図１０〜１１に示すように、第２〜第４実施形態のサーバ３１０は、所定の間隔でステップＳ３０８を実行し、画面全体の画像を取得する。しかし、ステップＳ３１２またはＳ３１４の判断結果によっては、サーバ３１０は、取得した画像に対応する描画コマンドを送信しない場合がある。

このように、「描画コマンドを送信しない条件が成り立つにもかかわらず、画像が取得される」という場合がある理由は、ステップＳ３１０での動画領域の検出が、固定された間隔での画面の変化に基づいて行われるようにするためである。しかし、実施形態によっては、ステップＳ３０８〜Ｓ３１０は、例えばステップＳ３１５の直前に移動されてもよい。つまり、可変の送信フレームレートに応じた間隔で、動画領域の検出が行われてもよい。

最後に、上記の種々の実施形態に関して、さらに下記の付記を開示する。
（付記１）
第１のコンピュータに、
ネットワークを介して前記第１のコンピュータと接続された第２のコンピュータであって、
前記第１のコンピュータの入力装置を介して前記第１のコンピュータに与えられた入力についての通知を前記第１のコンピュータから受信し、
前記入力に応じて１つ以上のプログラムを実行し、
前記１つ以上のプログラムの実行に応じて、前記第１のコンピュータの画面に表示するための画像を生成し、
前記第１のコンピュータに前記画像を前記画面上に表示させるための画面情報を送信するとともに、前記画面情報を送信する第１の時刻を示す時刻情報を送信し、
前記第１のコンピュータから通知される値に基づいて、前記画面情報を送信する頻度を調整しながら、前記画像の生成ならびに前記画面情報および前記時刻情報の送信を繰り返す
ことを特徴とする第２のコンピュータから、前記画面情報と前記時刻情報を受信し、
前記第１のコンピュータと前記第２のコンピュータとの間の前記ネットワークの可用帯域幅の推定値を、
前記第１のコンピュータが前記画面情報を受信した第２の時刻と、
前記推定値と、受信した前記画面情報のサイズと、受信した前記時刻情報により示される前記第１の時刻から、前記第１のコンピュータが前記画面情報を受信するものと推定される第３の時刻と
の差に応じて、増加させるか、維持するか、または、ある期間内に１回以上受信した前記画面情報それぞれのサイズと前記期間の長さから算出される第１の受信ビットレートに基づいて減少させ、
少なくとも前記推定値を増加または減少させることで更新した場合には、前記推定値または前記推定値の更新を反映する指標値を前記第２のコンピュータに通知する
ことを含む画面更新制御処理を実行させる画面更新制御プログラム。
（付記２）
前記推定値を前記差に応じて増加させるか、維持するか、または、減少させる処理は、
前記差が正の第１の閾値より大きいとき、前記第１の受信ビットレートに基づいて前記推定値を減少させ、
前記差が前記第１の閾値未満の第２の閾値以下のとき、前記推定値を増加させ、
前記差が前記第２の閾値より大きく前記第１の閾値以下のとき、前記推定値を維持する
ことを含むことを特徴とする付記１に記載の画面更新制御プログラム。
（付記３）
前記推定値を増加させる処理が、前記推定値を所定の割合で増加させるかまたは所定の値だけ増加させる処理である
ことを特徴とする付記１または２に記載の画面更新制御プログラム。
（付記４）
直近に受信された前記画面情報に関しての、
前記第１の時刻と
前記第２の時刻と
前記サイズ
から算出される第２の受信ビットレートが、前記推定値に基づいて前記推定値よりも大きく定められる判定基準値よりも大きい場合、前記第２の受信ビットレートに応じて前記推定値を増加させる
ことを前記画面更新制御処理が含むことを特徴とする付記１から３のいずれか１項に記載の画面更新制御プログラム。
（付記５）
前記差が所定の閾値以下の場合に、
前記推定値を維持するとともに、
前記推定値よりも大きな値を前記第２のコンピュータに通知する
ことを前記画面更新制御処理が含むことを特徴とする付記１、３、または４に記載の画面更新制御プログラム。
（付記６）
前記画面更新制御処理は、前記差を前記第２のコンピュータに通知することを含む
ことを特徴とする付記１から５のいずれか１項に記載の画面更新制御プログラム。
（付記７）
最初に受信された前記画面情報に関しての、
前記第１の時刻と
前記第２の時刻と
前記サイズ
から算出される第３の受信ビットレートを用いて、前記推定値を初期化することを前記画面更新処理が含む
ことを特徴とする付記１から６のいずれか１項に記載の画面更新制御プログラム。
（付記８）
前記ある期間は、現在から所定範囲内に含まれる期間である
ことを特徴とする付記１から７のいずれか１項に記載の画面更新制御プログラム。
（付記９）
第１のコンピュータが、前記第１のコンピュータの入力装置を介して前記第１のコンピュータに与えられた入力を、ネットワークを介して前記第１のコンピュータと接続された第２のコンピュータに通知し、
前記第２のコンピュータが、前記通知された入力に応じて１つ以上のプログラムを実行し、
前記第２のコンピュータが、前記１つ以上のプログラムの実行に応じて、前記第１のコンピュータの画面に表示するための画像を生成し、
前記第２のコンピュータが、前記第１のコンピュータに前記画像を前記画面上に表示させるための画面情報を送信するとともに、前記画面情報を送信する第１の時刻を示す時刻情報を送信し、
前記第１のコンピュータが、前記画面情報と前記時刻情報を受信し、
前記第１のコンピュータが、前記第１のコンピュータと前記第２のコンピュータとの間の前記ネットワークの可用帯域幅の推定値を、
前記第１のコンピュータが前記画面情報を受信した第２の時刻と、
前記推定値と、受信した前記画面情報のサイズと、受信した前記時刻情報により示される前記第１の時刻から、前記第１のコンピュータが前記画面情報を受信するものと推定される第３の時刻
の差に応じて、増加させるか、維持するか、または、ある期間内に１回以上受信した前記画面情報それぞれのサイズと前記期間の長さから算出される受信ビットレートに基づいて減少させ、
前記第１のコンピュータが、少なくとも前記推定値を増加または減少させることで更新した場合には、前記推定値または前記推定値の更新を反映する指標値を前記第２のコンピュータに通知し、
前記第２のコンピュータが、通知された前記推定値または通知された前記指標値に基づいて、前記画面情報を送信する頻度を調整しながら、前記画像の生成ならびに前記画面情報および前記時刻情報の送信を繰り返す
ことを含む画面更新制御方法。
（付記１０）
前記画面更新制御方法は、前記第１のコンピュータが前記差を前記第２のコンピュータに通知することを含み、
前記第２のコンピュータは、通知された前記差にも基づいて前記頻度を調整する
ことを特徴とする付記９に記載の画面更新制御方法。
（付記１１）
前記差が所定の閾値以下の場合に、前記第１のコンピュータが、
前記推定値を維持するとともに、
前記推定値よりも大きな値を前記第２のコンピュータに通知する
ことを特徴とする付記９または１０に記載の画面更新制御方法。
（付記１２）
ネットワークを介して接続された第１の情報処理装置と第２の情報処理装置を含むシステムで使われる前記第１の情報処理装置であって、
前記第１の情報処理装置と前記第２の情報処理装置との間の前記ネットワークの可用帯域幅の推定値または前記推定値の更新を反映する指標値を示す通知を、前記第２の情報処理装置に送信し、前記第１の情報処理装置に入力が与えられると、前記入力についての通知を前記第２の情報処理装置に送信する送信部と、
前記第２の情報処理装置が、前記入力についての前記通知に基づいて１つ以上のプログラムを実行し、前記１つ以上のプログラムの実行に応じて、前記第１の情報処理装置の画面に表示するための画像を生成し、前記第１の情報処理装置に前記画像を前記画面上に表示させるための画面情報を送信するとともに、前記画面情報を送信する第１の時刻を示す時刻情報を送信し、前記推定値または前記指標値に基づいて前記画面情報を送信する頻度を調整しながら前記画像の生成ならびに前記画面情報および前記時刻情報の送信を繰り返すと、前記第２の情報処理装置から、順次送信される前記画面情報と前記時刻情報をそれぞれ受信する受信部と、
前記推定値を、
前記画面情報が前記受信部により受信された第２の時刻と、
前記推定値と、前記受信部が受信した前記画面情報のサイズと、前記受信部が受信した前記時刻情報により示される前記第１の時刻から、前記受信部が前記画面情報を受信するものと推定される第３の時刻と
の差に応じて、増加させるか、維持するか、または、ある期間内に１回以上前記受信部により受信された前記画面情報それぞれのサイズと前記期間の長さから算出される受信ビットレートに基づいて減少させる推定部と、
を備えることを特徴とする第１の情報処理装置。

１０１、１０２、２００、２４０ コンピュータ
１０３ ユーザ
１１０ 画面
１１１〜１１３ 領域
１２１〜１２５ タイミングチャート
Ｆ１〜Ｆ７ 画面情報
１３１、１３２、４００ グラフ
２０１、２４１ ＣＰＵ
２０２、２４２ ＲＯＭ
２０３、２４３ ＲＡＭ
２０４、２４４ 通信インタフェイス
２０５、２４５ 入力装置
２０６、２４６ 出力装置
２０７、２４７ 記憶装置
２０８、２４８ 駆動装置
２０９、２４９ バス
２１０、２５０ 記憶媒体
２２０ ネットワーク
２３０ プログラム提供者
３００ システム
３１０ サーバ
３１１ 受信部
３１２ 生成部
３１３ 送信部
３１４ 調整部
３１５ 付加部
３１６ 送信制御データ
３２０ クライアント
３２１ 入力部
３２２ 表示部
３２３ 送信部
３２４ 受信部
３２５ 描画部
３２６ 推定部
３２７ 受信履歴データ
３２８ 時刻差データ
３２９、３２９ａ、３２９ｂ 可用帯域幅データ
４０１、４０２ 曲線

Claims (7)

1. 第１のコンピュータに、
   ネットワークを介して前記第１のコンピュータと接続された第２のコンピュータであって、
   前記第１のコンピュータの入力装置を介して前記第１のコンピュータに与えられた入力についての通知を前記第１のコンピュータから受信し、
   前記入力に応じて１つ以上のプログラムを実行し、
   前記１つ以上のプログラムの実行に応じて、前記第１のコンピュータの画面に表示するための画像を生成し、
   前記第１のコンピュータに前記画像を前記画面上に表示させるための画面情報を送信するとともに、前記画面情報を送信する第１の時刻を示す時刻情報を送信し、
   前記第１のコンピュータから通知される値に基づいて、前記画面情報を送信する頻度を調整しながら、前記画像の生成ならびに前記画面情報および前記時刻情報の送信を繰り返す
   ことを特徴とする第２のコンピュータから、前記画面情報と前記時刻情報を受信し、
   前記第１のコンピュータと前記第２のコンピュータとの間の前記ネットワークの可用帯域幅の推定値を、
   前記第１のコンピュータが前記画面情報を受信した第２の時刻と、
   前記推定値と、受信した前記画面情報のサイズと、受信した前記時刻情報により示される前記第１の時刻から、前記第１のコンピュータが前記画面情報を受信するものと推定される第３の時刻と
   の差に応じて、増加させるか、維持するか、または、ある期間内に１回以上受信した前記画面情報それぞれのサイズと前記期間の長さから算出される第１の受信ビットレートに基づいて減少させ、
   少なくとも前記推定値を増加または減少させることで更新した場合には、前記推定値または前記推定値の更新を反映する指標値を前記第２のコンピュータに通知する
   ことを含む画面更新制御処理を実行させる画面更新制御プログラム。
2. 前記推定値を前記差に応じて増加させるか、維持するか、または、減少させる処理は、
   前記差が正の第１の閾値より大きいとき、前記第１の受信ビットレートに基づいて前記推定値を減少させ、
   前記差が前記第１の閾値未満の第２の閾値以下のとき、前記推定値を増加させ、
   前記差が前記第２の閾値より大きく前記第１の閾値以下のとき、前記推定値を維持する
   ことを含むことを特徴とする請求項１に記載の画面更新制御プログラム。
3. 直近に受信された前記画面情報に関しての、
   前記第１の時刻と
   前記第２の時刻と
   前記サイズ
   から算出される第２の受信ビットレートが、前記推定値に基づいて前記推定値よりも大きく定められる判定基準値よりも大きい場合、前記第２の受信ビットレートに応じて前記推定値を増加させる
   ことを前記画面更新制御処理が含むことを特徴とする請求項１または２に記載の画面更新制御プログラム。
4. 前記差が所定の閾値以下の場合に、
   前記推定値を維持するとともに、
   前記推定値よりも大きな値を前記第２のコンピュータに通知する
   ことを前記画面更新制御処理が含むことを特徴とする請求項１または３に記載の画面更新制御プログラム。
5. 第１のコンピュータが、前記第１のコンピュータの入力装置を介して前記第１のコンピュータに与えられた入力を、ネットワークを介して前記第１のコンピュータと接続された第２のコンピュータに通知し、
   前記第２のコンピュータが、前記通知された入力に応じて１つ以上のプログラムを実行し、
   前記第２のコンピュータが、前記１つ以上のプログラムの実行に応じて、前記第１のコンピュータの画面に表示するための画像を生成し、
   前記第２のコンピュータが、前記第１のコンピュータに前記画像を前記画面上に表示させるための画面情報を送信するとともに、前記画面情報を送信する第１の時刻を示す時刻情報を送信し、
   前記第１のコンピュータが、前記画面情報と前記時刻情報を受信し、
   前記第１のコンピュータが、前記第１のコンピュータと前記第２のコンピュータとの間の前記ネットワークの可用帯域幅の推定値を、
   前記第１のコンピュータが前記画面情報を受信した第２の時刻と、
   前記推定値と、受信した前記画面情報のサイズと、受信した前記時刻情報により示される前記第１の時刻から、前記第１のコンピュータが前記画面情報を受信するものと推定される第３の時刻
   の差に応じて、増加させるか、維持するか、または、ある期間内に１回以上受信した前記画面情報それぞれのサイズと前記期間の長さから算出される受信ビットレートに基づいて減少させ、
   前記第１のコンピュータが、少なくとも前記推定値を増加または減少させることで更新した場合には、前記推定値または前記推定値の更新を反映する指標値を前記第２のコンピュータに通知し、
   前記第２のコンピュータが、通知された前記推定値または通知された前記指標値に基づいて、前記画面情報を送信する頻度を調整しながら、前記画像の生成ならびに前記画面情報および前記時刻情報の送信を繰り返す
   ことを含む画面更新制御方法。
6. 前記画面更新制御方法は、前記第１のコンピュータが前記差を前記第２のコンピュータに通知することを含み、
   前記第２のコンピュータは、通知された前記差にも基づいて前記頻度を調整する
   ことを特徴とする請求項５に記載の画面更新制御方法。
7. ネットワークを介して接続された第１の情報処理装置と第２の情報処理装置を含むシステムで使われる前記第１の情報処理装置であって、
   前記第１の情報処理装置と前記第２の情報処理装置との間の前記ネットワークの可用帯域幅の推定値または前記推定値の更新を反映する指標値を示す通知を、前記第２の情報処理装置に送信し、前記第１の情報処理装置に入力が与えられると、前記入力についての通知を前記第２の情報処理装置に送信する送信部と、
   前記第２の情報処理装置が、前記入力についての前記通知に基づいて１つ以上のプログラムを実行し、前記１つ以上のプログラムの実行に応じて、前記第１の情報処理装置の画面に表示するための画像を生成し、前記第１の情報処理装置に前記画像を前記画面上に表示させるための画面情報を送信するとともに、前記画面情報を送信する第１の時刻を示す時刻情報を送信し、前記推定値または前記指標値に基づいて前記画面情報を送信する頻度を調整しながら前記画像の生成ならびに前記画面情報および前記時刻情報の送信を繰り返すと、前記第２の情報処理装置から、順次送信される前記画面情報と前記時刻情報をそれぞれ受信する受信部と、
   前記推定値を、
   前記画面情報が前記受信部により受信された第２の時刻と、
   前記推定値と、前記受信部が受信した前記画面情報のサイズと、前記受信部が受信した前記時刻情報により示される前記第１の時刻から、前記受信部が前記画面情報を受信するものと推定される第３の時刻と
   の差に応じて、増加させるか、維持するか、または、ある期間内に１回以上前記受信部により受信された前記画面情報それぞれのサイズと前記期間の長さから算出される受信ビットレートに基づいて減少させる推定部と、
   を備えることを特徴とする第１の情報処理装置。