サーバ、サーバ制御方法、及びサーバ制御プログラム
【課題】画面転送システムにおいて、描画コマ数と応答性を両立する。
【解決手段】サーバは、第１データ及び第２データを記憶し、第１の指示に応じて第１データを出力し、第２の指示に応じて第２データを出力するバッファと、バッファが出力した第１及び第２データに対して、それぞれ第１の処理〜第Ｎの処理を行う第１処理部〜第Ｎ処理部と、第１の指示に応じてバッファが第１データを出力した後、第１の処理〜第Ｎの処理各々を完了する第１-１時刻〜第１-Ｎ時刻と、第２のデータを、第１の処理〜第Ｎの処理各々を開始する第２-１時刻〜第２-Ｎ時刻を推定する推定部と、第１-１時刻と第２-１時刻との関係〜第１-N時刻と第２-Ｎ時刻との関係各々が所定の関係を満たす場合、第２の指示を行い、満たさない場合には第２の指示を行わないようにバッファを制御する制御部とを備える。
【解決手段】サーバは、第１データ及び第２データを記憶し、第１の指示に応じて第１データを出力し、第２の指示に応じて第２データを出力するバッファと、バッファが出力した第１及び第２データに対して、それぞれ第１の処理〜第Ｎの処理を行う第１処理部〜第Ｎ処理部と、第１の指示に応じてバッファが第１データを出力した後、第１の処理〜第Ｎの処理各々を完了する第１-１時刻〜第１-Ｎ時刻と、第２のデータを、第１の処理〜第Ｎの処理各々を開始する第２-１時刻〜第２-Ｎ時刻を推定する推定部と、第１-１時刻と第２-１時刻との関係〜第１-N時刻と第２-Ｎ時刻との関係各々が所定の関係を満たす場合、第２の指示を行い、満たさない場合には第２の指示を行わないようにバッファを制御する制御部とを備える。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明の実施形態は、サーバ、サーバ制御方法、及びサーバ制御プログラムに関する。
【背景技術】
【０００２】
ネットワークを介して接続されたサーバ端末からクライアント端末に対してサーバ端末の画面の情報をパケット化してリアルタイムで配信する「画面転送システム」がある。クライアント端末は、サーバ端末が保持する画面領域の一部または全部の領域における画面情報を受け取り表示する。
【０００３】
画面転送システムを構築する際には、サーバ端末が保持する画面領域全体の内容を一定時間おきにパケット化して各クライアント端末に向けて配信するという方法と、画面領域において描画状態に変化が生じるごとに、その差分となる情報のみを変化が生じた領域の情報とともに配信するという方法がある。差分を配信する後者の方法では、描画状態の変化に応じて必要な部分のみのデータ生成が行われるため、前者の方法と比較して、ネットワーク帯域を効率的に利用することができる。
【０００４】
画面領域において最新の描画状態を得るための上述の差分を画面更新と呼ぶ。直前の描画状態が記憶されたフレームバッファに対し画面更新を反映させることにより、最新の描画状態を得ることができる。
【０００５】
ここで、画像転送システムにおいて、画面情報を転送する動作を簡単に説明する。サーバは、サーバのフレームバッファから画像更新を出力し、その画面更新を圧縮し、送信する。また、クライアントは、サーバが送信した画面更新を受け取ると、その画面更新を伸長して画面に表示する。
【０００６】
画面転送システムでは、十分な描画コマ数と応答性を両立することが重要な課題である。
【０００７】
描画コマ数（フレームレート）とは、クライアント端末にて単位時間あたりに描画される画面更新の回数である。描画コマ数が高いと画面表示が滑らかに表示される。
【０００８】
応答性とは、クライアント端末でクリック等の操作がなされてから、その操作に対応するサーバ端末上の画面変化に対し圧縮・送信・伸張などの一連の処理が施され、最終的にクライアント端末に反映されるまでの時間（応答時間）に相当する。応答性が不十分であると、ユーザが、操作結果を確認するまでの待機時間が長くなり、作業効率が低下する。
【先行技術文献】
【特許文献】
【０００９】
【特許文献１】特開２００６−２４６１５３号公報
【発明の概要】
【発明が解決しようとする課題】
【００１０】
ここで、描画コマ数を向上させるためには、フレームバッファから画面更新を出力する頻度を上げることが必要である。しかしながら、フレームバッファから画面更新を出力する頻度を不用意に上げると、応答性が劣化する場合がある。例えば、フレームバッファから出力した画面更新について、圧縮処理に移ろうとしても、直近にフレームバッファから出力した画面更新について圧縮処理を実行中の場合、その圧縮処理が完了するまでの待ち時間が発生する。このように、処理と処理の間の待ち時間が発生すると、フレームバッファから更新画像を出力してから、画面に表示するまでの時間が長くなり、応答性が劣化することになる。したがって、描画コマ数と応答性とを両立するためには、フレームバッファから画面更新を出力するタイミングを適切に選択する必要がある。
【００１１】
本発明の一実施形態では、描画コマ数と応答性とを両立するサーバを提供することを目的とする。
【課題を解決するための手段】
【００１２】
本発明の一観点にかかるサーバは、少なくとも第１データ及び第２データを記憶し、第１の指示に応じて前記第１データを出力し、第２の指示に応じて前記第２データを出力するバッファと、前記バッファが出力した第１及び第２データに対して、それぞれ第１の処理〜第Ｎ（Ｎは、２以上の整数）の処理を第１の処理〜第Ｎの処理の順番で処理を行う第１処理部〜第Ｎ処理部と、前記第１の指示に応じて前記バッファが前記第１データを出力した後、前記第１処理部〜前記第Ｎ処理部各々において、前記第１の処理〜前記第Ｎの処理各々を完了する第１-１時刻〜第１-Ｎ時刻と、前記第２のデータを、前記第１処理部〜前記第Ｎ処理部各々において、前記第１の処理〜前記第Ｎの処理各々を開始する第２-１時刻〜第２-Ｎ時刻とを推定する推定部と、前記第１-１時刻と前記第２-１時刻との関係〜前記第１-N時刻と前記第２-Ｎ時刻との関係各々が所定の関係を満たす場合、前記第２の指示を行い、満たさない場合には前記第２の指示を行わないように前記バッファを制御する制御部と、を備える。
【図面の簡単な説明】
【００１３】
【図１】本発明の第1の実施形態にかかる画面転送システムを示すブロック図。
【図２】描画命令の例を示す図。
【図３】領域情報を説明するための図。
【図４】画面更新の領域情報の一例を示す。
【図５】圧縮処理前後の記憶部１０６の記憶状態を示す表。
【図６】送信処理前後の記憶部１０６の記憶状態を示す表。
【図７】伸長処理前後の記憶部１０６の記憶状態を示す表。
【図８】判断部１０４の１度目の判断時点における記憶部１０６の記憶状態を示す表。
【図９】判断部１０４の１度目の判断時点におけるバッファ１０１が保持する画面更新を示す図。
【図１０】判断部１０４の１度目の判断時点における推定される処理時間を示す図。
【図１１】判断部１０４の２度目の判断時点における記憶部１０６の記憶状態を示す表。
【図１２】判断部１０４の２度目の判断時点におけるバッファ１０１が保持する画面更新を示す図。
【図１３】判断部１０４の２度目の判断時点における推定される処理時間を示す図。
【図１４】判断部１０４の３度目の判断時点における記憶部１０６の記憶状態を示す表。
【図１５】判断部１０４の３度目の判断時点におけるバッファ１０１が保持する画面更新を示す図。
【図１６】判断部１０４の３度目の判断時点における推定される処理時間を示す図。
【図１７】画面更新の出力を早すぎるタイミングで実行した場合の、応答性劣化を説明する図。
【図１８】画面更新の出力を早すぎるタイミングで実行した場合の、描画コマ数劣化を説明する図。
【図１９】画面更新を出力するか否かの判断の際に、閾値Ｔｈを用いた条件で判断することによる効果を説明する図。
【図２０】第１の実施形態の変形例のサーバを示すブロック図。
【図２１】第１の実施形態のサーバの構成を示すブロック図。
【発明を実施するための形態】
【００１４】
以下、本発明の実施の形態について、図面を参照しながら説明する。尚、各図において同一箇所については同一の符号を付すとともに、重複した説明は省略する。
【００１５】
本発明の実施形態にかかるサーバは、少なくとも第１データ及び第２データを記憶し、第１の指示に応じて前記第１データを出力し、第２の指示に応じて前記第２データを出力するバッファと、前記バッファが出力した第１及び第２データに対して、それぞれ第１の処理〜第Ｎ（Ｎは、２以上の整数）の処理を第１の処理〜第Ｎの処理の順番で処理を行う第１処理部〜第Ｎ処理部と、前記第１の指示に応じて前記バッファが前記第１データを出力した後、前記第１処理部〜前記第Ｎ処理部各々において、前記第１の処理〜前記第Ｎの処理各々を完了する第１-１時刻〜第１-Ｎ時刻と、前記第２のデータを、前記第１処理部〜前記第Ｎ処理部各々において、前記第１の処理〜前記第Ｎの処理各々を開始する第２-１時刻〜第２-Ｎ時刻とを推定する推定部と、前記第１-１時刻と前記第２-１時刻との関係〜前記第１-N時刻と前記第２-Ｎ時刻との関係各々が所定の関係を満たす場合、前記第２の指示を行い、満たさない場合には前記第２の指示を行わないように前記バッファを制御する制御部と、を備える。
【００１６】
以下の第1の実施形態では、本発明の実施形態に係るサーバのより具体的構成を説明する。
【００１７】
図１に示すように、本実施形態にかかるサーバの第1処理部〜第Ｎ処理部の具体例として、まず、処理部が2つの場合（つまり、Ｎ＝２の場合）として、圧縮部102、送信部103を例に示して説明する。次に、処理部が3つの場合（つまり、Ｎ＝３の場合）、変換部108、圧縮部102、送信部103を例に示して説明する。以下の例では、Ｎ＝２と３を例に説明するが、Ｎは４以上の場合もありうる。
【００１８】
また、上述した第1データ及び第2データの例として画面更新を例に説明する。
【００１９】
また、上述した第１の指示及び第2の指示の例として、画面更新の出力指示を例に説明する。
【００２０】
また、上述したサーバの制御部は、以下の実施形態のサーバ１の判断部１０３と対応する。
【００２１】
＜第１の実施形態＞
図１は、第1の実施形態にかかる画面転送システムの構成を示すブロック図である。
【００２２】
画面転送システムは、サーバ１と、クライアント２とが、ネットワーク３を介して接続されている。本実施形態では、ネットワーク３はＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）ネットワークであるとする。
【００２３】
図１を用いて、サーバ１の構成を説明する。
【００２４】
生成部１００は、サーバ１におけるオペレーティングシステム又はアプリケーションの実行状態に応じて、描画命令の生成処理を行う。
【００２５】
描画命令とは、クライアント端末２の画面の描画状態を変化させるための命令である。図２は、描画命令の例を示す図である。描画命令は、描画命令の種別を表す描画命令種別と、クライアント端末２の画面の画面領域のうち更新する領域の位置を表す領域情報と、領域情報の更新後の画像情報とを含む命令である。
【００２６】
図２で示した描画命令は、ビットマップ描画命令（ＢＩＴＭＡＰ）である。ビットマップ描画命令は、「領域情報で示される領域を画像情報によって上書き更新する」という命令である。
【００２７】
領域情報は、画面領域における画像情報の表示位置を示す数値である。図３は、領域情報を説明するための図である。図３に示すように、クライアント端末の画面全体の画面領域の、左上角を（０，０）、右下角を（Ｗｉｄｔｈ，Ｈｅｉｇｈｔ）と表したとする。図３に示す矩形（斜線で示した領域）の領域情報は、表示位置の左上座標（Ｌｅｆｔ，Ｔｏｐ）と右下座標（Ｒｉｇｈｔ，Ｂｏｔｔｏｍ）とで表すこととなる。図３の例では、（Ｗｉｄｔｈ，Ｈｅｉｇｈｔ）＝（６４０、４８０）である。また、領域情報は、左上座標（Ｌｅｆｔ，Ｔｏｐ）＝（１００，１００）、右下座標（Ｒｉｇｈｔ，Ｂｏｔｔｏｍ）＝（３００，３００）である。
【００２８】
画像情報は、領域情報に対応する領域の更新後のビットマップデータ（矩形の各画素におけるＲＧＢ３色の値など）である。
【００２９】
以上の説明では、描画命令として、ビットマップ描画命令を例にとって説明した。しかしながら、描画命令は、その他、「矩形領域間の画面情報のコピーを意味する」矩形コピー描画命令（ＣＯＰＹＲＥＣＴ）などが存在する。
【００３０】
バッファ１０１は、クライアント端末の画面の画面領域の画面情報を保持するための記憶領域を有する。初期状態においては、記憶領域に情報は記憶していない。バッファ１０１は、生成部１００から描画命令を受け取るごとに、記憶領域に描画命令を反映させ、画面情報を更新する。つまり、描画命令の領域情報に対応する記憶領域の内容を、描画命令の画像情報によって更新する。描画命令の領域情報に対応する記憶領域に、すでに画面情報が記憶されている場合は、重なる領域の古い画面情報が新しい画面情報によって上書きされる。これにより常に最新の画面情報が保持された状態が保たれる。
【００３１】
また、バッファ１０１は、画面更新の出力指示を受け取ると、前回の画面更新の出力時と現時点との画面情報の差分（この差分を、画面更新と称する。）を出力する。バッファ１０１は、前回出力時から現時点までに行われた画面情報の更新が行われた領域の情報（画面更新の領域情報と称する。）を保持している。画面更新の領域情報は、描画命令を反映させるごとに更新される。この画面更新の領域情報は、バッファ１０１が画面更新を出力するごとに、クリアされる。
【００３２】
圧縮部１０２は、画面更新の圧縮処理を行う。つまり、画面更新に含まれる画像情報に対し、ＺＬＩＢやＪＰＥＧ等の圧縮処理を施す。
【００３３】
送信部１０３は、画面更新の伝送処理を行う。入力された画面更新をネットワーク上において伝送可能な形式に変換して、クライアント端末２の受信部２０１との間で伝送処理を行う。ここで、送信部１０３が行う画面更新の伝送処理時間を定義しておく。本実施形態では、画面更新の伝送処理時間とは、送信部１０３が、画面更新の入力を受けてから、クライアント端末２０１の受信部２０１に画面更新が届くまでの時間であるとする。
【００３４】
判断部１０４は、定期的なタイミングで、バッファ１０１に対し画面更新の出力指示を出すか否かを判断する。判断部１０４は、推定部１０５が推定する処理開始時刻や処理終了時刻に基づき、判断を行う。例えば、現時点で、バッファ１０１が保持する画面更新を出力した場合に、当該画面更新の圧縮処理が完了する時刻と、現時点で、送信部１０２が伝送処理中である画面更新の伝送処理が完了する時刻とに基づき、バッファ１０１が保持する画面更新を圧縮後、待ち時間なく伝送処理に移れると判断した場合、画面更新の出力指示を出すと判断する。尚、判断部１０４は、定期的なタイミングでなく、任意のタイミングで判断を実行して良い。判断部１０４の動作の詳細は後述する。
【００３５】
推定部１０５は、圧縮部１０２、送信部１０３、伸張部２０２において行われる各処理部の処理開始時刻と処理終了時刻の推定を行う。推定に当たっては、記憶部１０７から得る各処理部の処理状態（詳細は後述する）と、バッファ１０１から得るその時々の画面更新の領域情報とを利用する。推定部１０５の動作の詳細は後述する。
【００３６】
記憶部１０６は、圧縮部１０２、送信部１０３、伸張部２０２各々の処理状態を記憶する。各処理状態は、各処理部が処理実行中であるか否かを示すフラグと、各処理部が処理中のデータ（画面更新）のデータサイズと、当該処理の処理開始時刻とから構成される。処理状態の情報の詳細は後述する。
【００３７】
受信部１０７は、クライアント端末２から伸張部２０２の処理状態に関する情報を受信する。
【００３８】
次に、クライアント端末２の構成を説明する。
【００３９】
受信部２０１は、ネットワーク３を介してサーバ１から画面更新を受信する。
【００４０】
伸張部２０２は、画面更新に含まれる圧縮された画像情報に対して伸張処理を行う。
【００４１】
表示部２０３は、ユーザに対して、画面情報を提示する。具体的には、表示部２０３は、画面領域全体の画面情報を格納するための記憶領域（フレームバッファ）を有し、そして、画面更新を受け取ると、画面更新の領域情報が示す記憶領域上の画面情報を画像情報で上書き更新する。
【００４２】
送信部２０４は、伸張部２０２の処理状態を、ネットワーク３を介してサーバ１へ送信する。
【００４３】
以上、図１を用いて、サーバ１とクライアント端末２の構成を説明した。
【００４４】
次に、サーバ１とクライアント端末２から構成される画面転送システムにおける動作を説明する。
【００４５】
画面転送システムにおける動作として、第１に、生成部１００が、描画命令を生成してから、バッファ１０１の情報を更新するまでの動作を説明する。第２に、バッファ１０１が、画面更新の出力指示を受けた場合に、画面更新を出力し、クライアント端末２が当該画面更新を反映した画面を表示するまでの動作の流れを説明する。第３に、バッファ１０１が、画面更新を出力するか否かを判断する動作の詳細について、説明する。
【００４６】
まず、第１に、生成部１００が、生成部１００が、描画命令を生成してから、バッファ１０１の画面情報を更新するまでの動作を説明する。
【００４７】
画面転送の実行が開始されると、生成部１００は、サーバ１のオペレーティングやアプリケーション（図示は省略。）の実行状態に応じて描画命令（描画命令の例は図２で示した。）を生成する。生成部１００は、描画命令をバッファ１０１へ出力する。
【００４８】
バッファ１０１は、画面転送の実行開始直後は、記憶領域に画面情報を有さない状態である。バッファ１０１は、描画命令を受け取ると、記憶領域のうち、描画命令の領域情報が示す位置の情報を、描画命令によって更新する。また、バッファ１０１は、画面情報の更新が、一度以上行われた領域の情報（画面更新の領域情報）を保持する。
【００４９】
図４は、画面更新の領域情報の一例を示す。
【００５０】
図４（ａ）は、画面転送の実行開始後、最初に、描画命令を受け取った後に、バッファ１００が記憶する画面更新の領域情報と画面情報の例である。図４（ａ）の例では、描画命令の領域情報が、（Ｌｅｆｔ，Ｔｏｐ，Ｒｉｇｈｔ，Ｂｏｔｔｏｍ）＝（１００，１００，４００，３００）である場合を示す。このように、初回の入力では、受け取った全ての情報が記憶される。
【００５１】
図４（ｂ）は、２回目の描画命令を受け取った後に、バッファ１００が記憶する画面更新の領域情報と画面情報の例である。図４（ｂ）の例では、２回目の描画命令の領域情報が（Ｌｅｆｔ，Ｔｏｐ，Ｒｉｇｈｔ，Ｂｏｔｔｏｍ）＝（２００，２００，６００，４００）である場合を示している。
【００５２】
２回目以降の入力では、既に記憶された情報の領域と新たに記憶する情報の領域とが重複する場合がある。図４（ｂ）に示すように、重複する領域がある場合、重複する部分を新しい情報によって上書き更新する。図４（ｂ）の例では、重複する領域は、（Ｌｅｆｔ，Ｔｏｐ，Ｒｉｇｈｔ，Ｂｏｔｔｏｍ）＝（２００，２００，４００，３００）の領域である。その重複する領域が、２回目の描画命令の情報によって更新される。尚、既に記憶された情報の領域と重複しない領域についての情報についても、記憶される。図４（ｂ）の例では、（Ｌｅｆｔ，Ｔｏｐ，Ｒｉｇｈｔ，Ｂｏｔｔｏｍ）＝（１００，１００，４００，２００），（１００，２００，２００，３００），（２００，２００，６００，４００）の領域である。
【００５３】
このように、生成部１００で描画命令が生成されるごとに、バッファ１０１の内容は逐一更新される。バッファ１０１の内容の更新は、判断部１０４から、画面更新の出力指示を受け取るまで繰り返し実行される。
【００５４】
次に、バッファ１０１が、画面更新の出力指示を受けてから、画面更新を出力し、クライアント端末２が当該画面更新を反映した画面を表示するまでの動作の流れを説明する。尚、バッファ１０１が、画面更新を出力するか否かの決定は、判断部１０４が行うが、その動作の詳細は後述する。
【００５５】
バッファ１０１は、画面更新の出力指示を受け取ると、前回出力時から今までに記憶した最新の画面情報と、その領域の情報を圧縮部１０２に画面更新として出力する。画面更新の出力が完了すると、これまでに記憶した画面情報とその領域の情報をクリアする。バッファ１０１は、以降は、また１から、生成部１００から受け取った描画命令を記憶していく。
【００５６】
圧縮部１０２は画面更新を受け取ると、その画面更新に含まれる画像情報に圧縮処理を施す。また、圧縮部１０２は、圧縮処理を行う際に、圧縮処理を行う対象の画面更新のデータサイズを記憶部１０６に通知する。
【００５７】
記憶部１０６は、圧縮部１０２から、画面更新のデータサイズを受け取ると、圧縮処理が実行中であることを示すフラグ（実行状態）をオン（処理中）にする。また、受け取ったデータサイズと、現在の時刻を処理開始時刻として記憶する。ここで、現在の時刻とは、例えばサーバ１が起動してから現在の経過秒数（単位：ミリ秒）などである。
【００５８】
ここで、画面更新のデータサイズの算出方法の一例を説明する。
【００５９】
バッファ１０１が出力した画面更新が、図４（ｂ）の示すものであったとする。画面更新の総画素数は、この画面更新が占める領域の面積に等しい。図４（ｂ）の例では、画面更新が占める面積（総画素数）は、（４００−１００）×（２００−１００）＋（２００−１００）×（３００−２００）＋（６００−２００）×（４００−２００）＝３００００＋１００００＋８００００＝１２００００である。本実施形態では、１画素あたりのデータサイズを３バイトとする。両者の積により、画面更新のデータサイズは、３６０キロバイトと計算できる。（なお、簡便のため１キロバイト＝１０００バイトとしている。）
記憶部１０６が、圧縮部１０２から、画面更新のデータサイズを受け取った場合に、記憶した情報を図５（ａ）に示す。図５（ａ）では、圧縮処理が処理中であり、画面更新のデータサイズは３６０キロバイトであり、圧縮処理の処理開始時刻が１０００００ である例を示している。
【００６０】
圧縮部１０２は、圧縮処理を完了すると、記憶部１０６に圧縮完了通知をする。記憶部１０６は、圧縮完了通知を受けとると、圧縮処理が実行中であることを示すフラグをオフにする。また、データサイズと処理開始時刻を削除する。図５（ｂ）に、記憶部１０６が圧縮完了通知を受け取った後の記憶状態を示す。
【００６１】
また、圧縮部１０２は、圧縮処理を完了すると、圧縮後の画面更新を送信部１０３に渡し、伝送処理を依頼する。
【００６２】
送信部１０３は、圧縮後の画面更新を受け取ると伝送処理を施す。伝送処理を施す前に、送信部１０３は、圧縮後の画面更新のデータサイズを記憶部１０６に通知する。記憶部１０６は、圧縮後の画面更新のデータサイズを受け取ると、伝送処理が実行中であることを示すフラグ（実行状態）をオン（処理中）にする。また、データサイズと、現在の時刻を処理開始時刻として記憶する。記憶部１０６が記憶された情報の例を図６（ａ）に示す。図６（ａ）の例では、圧縮後の画面更新のデータサイズが、１２０キロバイトであり、処理開始時刻が１００１００である場合を示している。
【００６３】
送信部１０３は、圧縮後の画面更新のデータサイズを記憶部１０６に通知後、圧縮後の画面更新にＴＣＰ／ＩＰの各ヘッダを付与し、クライアント端末２に向けてネットワーク３へ送出する。
【００６４】
送信部１０３は伝送処理を完了すると、記憶部１０６に伝送処理完了通知を行う。記憶部１０６は、伝送処理完了通知を受けると、伝送処理が実行中であることを示すフラグをオフにし、データサイズと処理開始時刻を削除する。伝送処理完了通知後の記憶部１０６の記憶状態を図６（ｂ）に示す。
【００６５】
クライアント端末２の受信部２０１は、伝送処理において画面更新を受け取ると、伸張部２０２に渡し、伸張を依頼する。
【００６６】
伸張部２０２は、画面更新を受け取ると、その画面更新に含まれる画像情報に伸張処理を施す。
【００６７】
伸張部２０２は、伸長処理を実行する前に、伸長処理を施す対象となる画面更新のデータサイズを送信部２０４に渡し、サーバ１への通知を依頼する。送信部２０４は、データサイズにＴＣＰ／ＩＰの各ヘッダを付与し、データサイズをサーバ１へと送出する。
サーバ１の受信部１０７は、データサイズを受信すると、ヘッダを除去する。そして、記憶部１０６へデータサイズを通知する。記憶部１０６は、データサイズを受け取ると、伸張処理が実行中であることを示すフラグをオンにする。また、伸長処理を施す対象となる画面更新のデータサイズを記憶し、現在の時刻を処理開始時刻として記憶する。図７（ａ）は、伸長処理が実行中の際に、記憶部１０６に記憶された情報の例である。図７（ａ）では、伸張前の画面更新のデータサイズとして１２０キロバイト、処理開始時刻として１００３００が記憶されている。
【００６８】
伸張部２０２は伸張処理を完了すると、伸長処理完了通知を、送信部２０４を介して、サーバ１の記憶部１０６に通知する。記憶部１０６は、伸長処理完了通知を受け取ると、伸張処理が実行中であることを示すフラグをオフにし、データサイズと処理開始時刻を削除する。伸長処理完了通知を受け取った後の記憶部１０６の状態を図７（ｂ）に示す。
【００６９】
伸張部２０２は、伸張が完了した画面更新を表示部２０３に渡し、表示を依頼する。
【００７０】
表示部２０３は、画面領域全体の画面情報を保持する記憶領域を有しており、画面更新の領域情報が示す領域の情報を、伸張後の画像情報で上書き更新する。表示部２０３の状態はユーザに視覚的に提示される。
【００７１】
以上、バッファ１０１が、画面更新の出力指示を受けてから、画面更新を出力し、クライアント端末２が当該画面更新を反映した画面を表示するまでの動作の流れを説明した。
【００７２】
なお、圧縮部１０２、送信部１０３、伸張部２０２はいずれも並列的に動作が可能である。つまり、例えば圧縮部１０２が圧縮後の画面更新を送信部１０３に渡したすぐ後に、バッファ１０１から新たな画面更新が渡されれば、たとえ送信部１０３が先の画面更新の伝送処理中であったとしても、新たな画面更新の圧縮処理を実行することが可能である。
【００７３】
次に、判断部１０４が、バッファ１０１に、画面更新を出力させるか否かを判断する動作の詳細について、説明する。
【００７４】
判断部１０４は、任意のタイミングで、バッファ１０１に画面更新の出力指示を出すか否かの判断を行う。例えば一定時間間隔ごとに判断を開始してよい。
【００７５】
以下では、３つの時刻で判断する例を説明する。第１の時刻は、１００４００であり、第２の時刻は、１００５００であり、第３の時刻は、１００５４０であるとする。
【００７６】
まず、第１の時刻である、１００４００の時点で、判断する例を説明する。
【００７７】
まず、判断部１０４は、推定部１０５に対し、次の二種類の時刻を推定するよう要求する。一つ目は、現在処理の実行中である最新の画面更新に施される圧縮処理、伝送処理、伸張処理のそれぞれの処理終了時刻である。ここで、最新の画面更新とは、現時点から直近の時点で、バッファが出力した画面更新である。それぞれα１、α２、α３と示す。二つ目は、もし今、バッファ１０１から画面更新が出力されたと仮定したときに、当該の画面更新に施される圧縮処理、伝送処理、伸張処理のそれぞれの処理開始時刻である。それぞれβ１、β２、β３と示す。
【００７８】
推定部１０５は、推定の要求を受け取ると、上述の二種類の時刻を次の手順により推定する。
【００７９】
まず、一つ目の時刻（α１、α２、α３）について説明する。始めに、推定部１０５は、記憶部１０６に対し情報の読み出しを依頼する。図８に、記憶部１０６が記憶している情報の例を示す。
【００８０】
図８は、圧縮部１０２が、画面更新１００１を処理中で、伸張部２０２が画面更新１００２を処理中である様子が示されている。
【００８１】
推定部１０５は、図８の情報から、現在処理中の最新の画面更新の、圧縮処理、伝送処理、伸張処理のそれぞれの処理終了時刻を推定する。
【００８２】
本実施形態では、推定部１０５は、以下の値を有しているものとする。
【００８３】
・圧縮部１０２の平均処理所要時間：ＴＣ（ミリ秒／キロバイト）
・送信部１０３の平均処理所要時間：ＴＴ（ミリ秒／キロバイト）
・伸張部２０２の平均処理所要時間：ＴＤ（ミリ秒／キロバイト）
・圧縮部１０２の平均圧縮率：Ｃ（％）
また、本実施形態においては、ＴＣ＝０．８ミリ秒／キロバイト、ＴＴ＝３．２ミリ秒／キロバイト、ＴＤ＝４．８ミリ秒／キロバイト、Ｃ＝５０％であるとする。
【００８４】
推定部１０５は、推定部１０５が有する上述した値を用いて、最新の画面更新、すなわち画面更新１００１に対する処理終了時刻を、以下の方法で推定する。
【００８５】
推定部１０５は、圧縮処理終了時刻を、圧縮処理開始時刻＋圧縮前データサイズ×ＴＣと推定する。上記の例では、α１＝１００３６０＋１００×０．８＝１００４４０と推定する。推定部１０５は、伝送処理終了時刻を、伝送処理開始時刻＋圧縮後データサイズ×ＴＴと推定する。伝送処理開始時刻は圧縮処理終了時刻に等しく、また圧縮後データサイズは圧縮前データサイズ×Ｃとみなす。上記の例では、α２＝１００４４０＋１００×５０÷１００×３．２＝１００６００と推定する。推定部１０５は、伸張処理開始時刻を、伸張処理開始時刻＋圧縮後データサイズ×ＴＤと推定する。伸張処理開始時刻は伝送処理終了時刻に等しいとみなす。上記の例では、α３＝１００６００＋１００×５０÷１００×４．８＝１００８４０と推定する。
【００８６】
次に、二つ目の時刻（β１、β２、β３）について説明する。
【００８７】
始めに、推定部１０５はバッファ１０１に対し、現在記憶している画面更新の領域情報の読み出しを依頼する。例を図９に示す。図９の例では、バッファ１０１は現在記憶している画面更新の領域情報として、（Ｌｅｆｔ，Ｔｏｐ，Ｒｉｇｈｔ，Ｂｏｔｔｏｍ）＝（１００，１００，３５０，２００）を推定部１０５に返す。
【００８８】
推定部１０５は、もし今、バッファ１０１から画面更新が出力されたと仮定したときに、この画面更新に施されるであろう圧縮処理、伝送処理、伸張処理のそれぞれの処理開始時刻を推定する。
【００８９】
まず、この画面更新のデータサイズを算出する。画素数は（３５０−１００）×（２００−１００）＝２５００００である。この値に、１画素あたりのバイト数として３バイトを乗じ、データサイズを７５キロバイトと算出する。さらに上述のＴＣ、ＴＴ、Ｃを用いて各処理の開始時刻を推定する。圧縮処理開始時刻は現在の時刻を取得し、それをそのまま利用する。現在時刻は、１００４００であるとしたので、β１＝１００４００とする。伝送処理開始時刻は圧縮処理終了時刻に等しいとみなし、β２＝１００４００＋７５×０．８＝１００４６０と推定する。伸張処理開始時刻は伝送処理終了時刻に等しいとみなし、β３＝１００４６０＋７５×５０÷１００×３．２＝１００５８０と推定する。
【００９０】
推定部１０５が、（α１、α２、α３）と（β１、β２、β３）を算出すると、判断部１０４は、これらを用いて、バッファ１０１に画面更新の出力指示を出すか否かを判断する。
【００９１】
判断部１０５は、α１≦β１、α２≦β２、α３≦β３の三つの条件がすべて真となる場合に、出力指示を出すと判断し、それ以外の場合には、出力指示を出さないと判断する。
【００９２】
以上の例では、α１＝１００４４０、β１＝１００４００であるため、条件を満たしていない。したがって、判断部１０４はバッファ１０１に画面更新の出力指示を出さないと判断する。
【００９３】
図１０に、以上説明した例における、推定時刻である（α１、α２、α３）と（β１、β２、β３）との関係を示す。
【００９４】
図１０では、時間軸に沿った各処理の処理状態を示している。図中の四角は、各処理部が処理中である様子を意味する。四角内の数字は各処理の所要時間である。もし現在時刻１００４００（図中右側の矢印）において、バッファ１０１からの画面更新の出力指示を行ったと仮定すると、その時点で圧縮部１０２は前の画面更新を処理実行中であるため、新たな画面更新の圧縮処理に即座に取りかかることができない。その結果、応答性が低下する。つまり、α１≦β１の条件を満たしていないと、応答性が低下する。したがって、判断部１０４は、第１の時点（１００４００）では画面更新の出力指示を行うべきでないと判断する。
【００９５】
判断部１０４の処理は以上で終了する。既に述べたように、判断部１０４の判断処理は、任意のタイミングで繰り返し行われる。
【００９６】
以下では、上記の判断終了時から１００ミリ秒が経過した第２の時刻（時刻１００５００）で、再び判断部１０４の判断処理が開始したときの処理の流れを述べる。
【００９７】
先程と同様、判断部１０４は、二種類の時刻を推定するよう推定部１０５に要求する。
【００９８】
推定部１０５が行う、一つ目の時刻（α１、α２、α３）の推定について説明する。
【００９９】
始めに、推定部１０５は、記憶部１０６に対し情報の読み出しを依頼する。図１１に、記憶部１０６が記憶している情報の例を示す。図１１に示すように、前述した判断時点（時刻１００４００）では、圧縮処理中だった画面更新（画面更新１１０１）が、伝送処理に移っている。また、図１１には、伸張部２０２は、画面更新１１０２を引き続き伸張処理を継続している様子が示されている。
【０１００】
推定部１０５は、記憶部１０６の情報から、現在処理の実行中である最新の画面更新、すなわち画面更新１１０１についてα１、α２、α３を推定する。圧縮処理終了時刻については既に圧縮処理が終了しているため計算を行わない。伝送処理終了時刻は、伝送処理開始時刻＋圧縮後データサイズ×ＴＴで算出し、推定する。α２＝１００４４０＋５０×３．２＝１００６００と推定できる。伸張処理終了時刻は、伸張処理開始時刻＋圧縮後データサイズ×ＴＤと推定する。ここで、伸張処理開始時刻は、伝送処理終了時刻と推定し、算出する。α３＝１００６００＋５０×４．８＝１００８４０と推定できる。
【０１０１】
次に、推定部１０５が行う、二つ目の時刻（β１、β２、β３）の推定について説明する。
【０１０２】
始めに、推定部１０５はバッファ１０１に対し、現在記憶している画面更新の領域情報の読み出しを依頼する。例を図１２に示す。図９と図１２を比較するとわかるとおり、前述した判断時点（時刻１００４００）と比較して、現時点（時刻１００５００）では、描画命令が追加で発生しており、バッファ１０１のデータ量が増加している。
【０１０３】
図１２に示すように、バッファ１０１は、現在記憶している画面更新の領域情報として、（Ｌｅｆｔ，Ｔｏｐ，Ｒｉｇｈｔ，Ｂｏｔｔｏｍ）＝（１００，１００，３５０，２００），（２００，２００，４００，３００）を推定部１０５に渡す。推定部１０５は、前述した算出方法と同様の方法で、β１、β２、β３を推定する。
【０１０４】
画素数は、画面行使の領域情報から、（３５０−１００）×（２００−１００）＋（４００−２００）×（３００−２００）＝４５００００と算出できる。データサイズは、算出した画素数に、１画素あたりのバイト数として３バイトを乗じ、１３５キロバイトと算出できる。圧縮処理開始時刻は現在の時刻をそのまま利用し、β１＝１００５００とする。伝送処理開始時刻は圧縮処理終了時刻に等しいとみなす。β２＝１００５００＋１３５×０．８＝１００６０８と推定できる。伸張処理開始時刻は伝送処理終了時刻に等しいとみなす。β３＝１００６０８＋１３５×５０÷１００×３．２＝１００８２４と推定できる。
【０１０５】
判断部１０４は、以上の二種類の時刻の推定値（α１、α２、α３）と（β１、β２、β３）を用いて、バッファ１０１に画面更新の出力指示を出すか否かを判断する。今回はα１の計算を行わなかったが、α１はすでに経過している。したがって、α１≦β１は真とみなすことができる。また、α２＝１００６００、β２＝１００６０８であるため、α２≦β２の条件は真である。しかし、α３＝１００８４０、β３＝１００８２４であるため、α３≦β３の条件は真でない。したがって、判断部１０４はバッファ１０１に画面更新の出力指示を出さないと判断する。
【０１０６】
図１３に、以上説明した、（α１、α２、α３）と（β１、β２、β３）との間の関係を示す。もし、現在時刻１００５００において、バッファ１０１からの画面更新の出力指示を行ったと仮定する。この場合、現時点で、圧縮部１０２は処理実行中でないため、新たな画面更新の圧縮処理に即座に取りかかることができる。また、送信部１０３は、現時点では伝送処理中だが、圧縮処理の完了時点（β２）では、処理が完了（α２の時点で完了）していると推定できる。したがって、圧縮処理完了後、すぐに、新たな画面更新の送信処理に取りかかることができる。しかし、伸張部２０２は、新たな画像更新の伝送処理が完了すると推定される時刻（β３）において、処理実行中であると推定される（β３＜α３）。したがって、新たな画像更新の伝送処理完了後、すぐに、新伸張処理に取りかかることができない。したがって、判断部１０４は、この時点では、バッファ１０１から画面更新の出力指示を行うべきでないと判断する。
【０１０７】
判断部１０４の処理は以上で終了する。
【０１０８】
以下では、上記の判断終了時からさらに４０ミリ秒が経過した第３の時刻（時刻１００５４０）で、再び判断部１０４の判断処理が開始したときの処理の流れを説明する。
【０１０９】
以前の判断と同様、判断部１０４は、二種類の時刻を推定するよう推定部１０５に要求する。
【０１１０】
まず、一つ目の時刻（α１、α２、α３）の推定について説明する。
【０１１１】
図１４に、時刻１００５４０における、記憶部１０６が保持する情報を示す。
【０１１２】
図１４に示す通り、圧縮処理、伝送処理、伸長処理それぞれの処理状態は、前回の判断時点（時刻１００５００）から変化していないものとする。つまり、伝送処理、伸長処理が処理を継続して行っている。
【０１１３】
推定部１０５は、α１、α２、α３を推定する。推定部１０５は、今回のように、記憶部１０６の状態に変化がないことを検出した場合は、α１、α２、α３の推定を省略し、前回の推定結果をそのまま再利用することができる。その結果、α１は推定値なし、α２＝１００６００、α３＝１００８４０との推定結果を得る。
【０１１４】
次に、二つ目の時刻（β１、β２、β３）の推定について説明する。
【０１１５】
図１５に、時刻１００５４０における、バッファ１０１の状態を示す。
【０１１６】
図１２と図１５を比較するとわかるとおり、現時点（１００５４０）と、以前判断した時点（１００５００）との間に、描画命令の追加発生はなく、バッファ１０１の状態に変化がない。
【０１１７】
したがって、推定部１０５は、データ量として、前回算出した値と同様１３５キロバイトを得る。また、圧縮処理開始時刻は、現在の時刻をそのまま利用し、β１＝１００５４０とする。伝送処理開始時刻は圧縮処理終了時刻に等しいとみなし、β２＝１００５４０＋１３５×０．８＝１００６４８と推定する。伸張処理開始時刻は伝送処理終了時刻に等しいとみなし、β３＝１００６４８＋１３５×５０÷１００×３．２＝１００８６４と推定する。
【０１１８】
判断部１０４は、以上の二種類の時刻の推定値を用いて、バッファ１０１に画面更新の出力指示を出すか否かを判断する。前回の判断時と同様の理由で、α１≦β１は真と判断できる。α２＝１００６００、β２＝１００６４８であるため、α２≦β２の条件は真である。α３＝１００８４０、β３＝１００８６４であるため、α３≦β３の条件は真である。全ての条件が真となったため、判断部１０４はバッファ１０１に画面更新の出力指示を出すと判断する。
【０１１９】
図１６に、以上説明した、（α１、α２、α３）と（β１、β２、β３）との間の関係を示す。
【０１２０】
図１６に示す通り、現在時刻１００５４０において、バッファ１０１からの画面更新の出力指示を行ったと仮定すると、当該の画面更新に対する各処理が完了した時点で次の処理に即座に移れるようになっていることが分かる。
【０１２１】
判断部１０４は、バッファ１０１に対し、画面更新の出力指示を行う。以上で判断部１０４の処理は終了する。
【０１２２】
以上が、本実施形態の動作説明である。
【０１２３】
以上、本実施の形態によれば、判断部１０４は、繰り返し、判断を実行し、β１、β２、β３それぞれが、α１、α２、α３それぞれを初めて上回った時点で、バッファ１０１に対して、画面更新の出力指示を行っている。β１、β２、β３それぞれが、α１、α２、α３それぞれを上回った時点で、バッファ１０１に対する出力指示を行っているため、並列的に動作可能な、画面更新に施される一連の処理（圧縮→伝送→伸張）において、各処理を終えた画面更新が即座に次の処理へ移行することができる。また、「初めて」上回った時点で、出力指示を行うこととしているため、画面更新の出力頻度も高い状態を維持できる。また、ボトルネックの処理部（本実施形態では伸張部２０２）が処理を行っていない時間を最小限に抑えることができる。したがって、応答性と描画コマ数の両立を実現できる。
【０１２４】
より具体的に説明する。
【０１２５】
図１７に示すように、もし本実施形態で決定した出力指示のタイミングよりも早いタイミングで出力指示を行った場合、処理後の画面更新が即座に次の処理に移行できず、余計な待ち時間が発生することになる（応答性が悪化する）。
【０１２６】
図１８に示すように、本実施形態で決定した出力指示のタイミングよりも遅いタイミングで出力指示を行った場合、ボトルネックの処理部が処理を行っていない時間が生じることになる（描画コマ数が悪化することになる）。
【０１２７】
本実施形態によれば、一連の処理が全て完了するまでの所要時間を小さくしたいという要求と、単位時間あたりに行われる一連の処理の回数を大きくしたいという要求を、同時に満たすことが可能になる。つまり、描画コマ数と応答性を両立することが可能になる。
【０１２８】
また、本実施形態では、判断部１０４が判断処理を繰り返し実行するものとした。前述の通り、画面転送では画面変化が生じた場合にのみ送出すべきデータが発生するため、ある時点において、以降将来にどのような画面変化が生じるかは予測できない。判断処理を繰り返し行うという本実施形態の動作は、このような特殊なデータの発生パターンを有する画面転送において効果的にバッファ１０１からの出力タイミングを決定することができる。
【０１２９】
なお、本実施形態では、一つ目の時刻（α１、α２、α３）と二つ目の時刻（β１、β２、β３）を全て推定した後に判断処理を行っているが、必ずしも全てを推定してから判断を行わなくともよい。例えば、始めにα１とβ１のみの推定を行ってからα１≦β１の真偽を確かめ、真の場合にのみα２とβ２の推定を行い、さらにα２≦β２が真の場合にのみα３とβ３の推定を行いα３≦β３の真偽を確かめる、といった手順であってもよい。こうした手順を採用すれば、一度に全てを推定するよりも少ない計算量で同等の判断をすることができる。
【０１３０】
また、本実施形態では、推定部１０５が、各処理部の平均処理所要時間（ＴＣ、ＴＴ、ＴＤ）や圧縮率（Ｃ）を事前に有しているものとして説明したが、これに限られない。例えば、画面転送の開始時に試験的に圧縮処理や伝送処理、伸張処理を行い、その所要時間や圧縮率からＴＣ、ＴＴ、ＴＤ、Ｃを決定してよい。また、画面転送の実施の任意のタイミングで、各処理部の処理の所要時間や圧縮率の実績を求め、ＴＣ、ＴＴ、ＴＤ、Ｃを適宜更新してもよい。また、ＴＣ、ＴＴ、ＴＤ、Ｃを決定する際に、サーバ１やクライアント端末２のＣＰＵ性能などの値を反映してもよい。また、ＴＣ、ＴＴ、ＴＤ、Ｃを決定する際に、ネットワーク３の通信帯域やＲＴＴ（Ｒｏｕｎｄ Ｔｒｉｐ Ｔｉｍｅ）を測定し決定に反映してよい。こうした手順を採用すれば、画面転送を実行する環境ごとに異なる端末性能やネットワーク性能に適応することができる。
【０１３１】
また、本実施形態では、判断処理を定期的に行うこととして説明したが、判断処理のタイミングは任意でよい。
【０１３２】
例えば、バッファ１０１おいて少なくとも一度以上更新が行われた領域が増えたことを検出したときに、判断部１０４に対し判断処理の開始を依頼してもよい。判断部１０４は、周期的なタイミングで判断処理を行うのに加えて、バッファ１０１から依頼があった際に追加的に判断処理を行う。バッファ１０１において少なくとも一度以上更新が行われた領域が拡大した場合、バッファ１０１が出力する画面更新のデータサイズが増加する。その結果、圧縮処理、伝送処理、伸張処理の処理時間は大きくなることが予期される。つまり、β１、β２、β３の値が増加する。したがって、α１≦β１、α２≦β２、α３≦β３の条件が成立する可能性が高くなる。したがって、このようなタイミングで判断処理を行うことで、バッファ１０１からの出力指示を、より適切なタイミングで行える。
【０１３３】
また、本実施形態では、α１≦β１、α２≦β２、α３≦β３の三つの条件が真の場合、つまり、バッファが記憶している画面更新の圧縮処理、伝送処理、伸長処理各々の処理の推定開始時刻であるβ１、β２、β３が、直近に出力した画面更新の圧縮処理、伝送処理、伸長処理各々の処理完了時刻であるα１、α２、α３と同一か、後になるように条件を設定した。しかしながら、必ずしも、各処理の推定開始時刻が、各処理の推定完了時刻と同一か、後になる必要はない。
【０１３４】
例えば適当な閾値Ｔｈを設けて、α１≦β１、α２≦β２、α３≦β３の三つの条件の代わりに、条件をα１≦β１＋Ｔｈ、α２≦β２＋Ｔｈ、α３≦β３＋Ｔｈの三つの条件としてもよい。この条件では、各処理の推定開始時刻が、推定完了時刻以前となる場合がある。この場合、推定開始時刻から推定完了時刻まで、処理の待ち時間が、多少生じることにはなるが、待ち時間は、Ｔｈ以内である。したがって、応答性と描画コマ数の両立を実現できる。尚、閾値Ｔｈの値は、圧縮処理、伝送処理、伸長処理それぞれの条件毎に異なる値としてもよい。
【０１３５】
こうしたやり方は、判断処理を周期Ｔで定期的に行う場合において、描画コマ数と応答性の両立をより向上できる。図１９を用いて説明する。
【０１３６】
ある時刻ｔでの判断処理においてβ３がα３をわずかに上回らなかった場合、次の判断の時刻ｔ´＝ｔ＋Ｔでは、β３がα３を大きく上回ることとなる。条件を、α１≦β１＋Ｔｈ、α２≦β２＋Ｔｈ、α３≦β３＋Ｔｈとしておけば、このようにβ３がα３をわずかに上回る場合であっても、画面更新の出力を実行すると判断できる。この場合、応答性はわずかに劣化するが、描画コマ数の劣化を防ぐことができ、応答性と描画コマ数の両立を実現できる。
【０１３７】
特に、Ｔｈ＝Ｔ／２と定めた場合は、応答性と描画コマ数の両立のために、より適切な判断ができる。つまり、この条件を定めた場合、バッファが記憶する画面更新の、ボトルネックとなる処理部の処理開始時刻と、直近にバッファが出力した画面更新のボトルネックとなる処理部の処理完了時刻とが最も近づくタイミングで、バッファの更新画像を出力することができるようになる。ここで、ボトルネックとなる処理部とは、α１≦β１＋Ｔｈ、α２≦β２＋Ｔｈ、α３≦β３＋Ｔｈの条件を、最後の時刻に満たす処理部である。
【０１３８】
例えば、ボトルネックとなる処理部が、伸長部である場合を考える。この場合、α３≦β３＋Ｔｈの条件を最後に満たす。時刻ｔでの判断処理で、α１≦β１＋Ｔ／２、α２≦β２＋Ｔ／２、α３≦β３＋Ｔ／２すべてが成立した場合、その後どのような画面変化が生じようとも、時刻ｔ´（ｔ´＝ｔ＋Ｔ）においては、｜β３´−α３´｜≧｜β３−α３｜が成立することとなる。（ここで、時刻ｔ´での、α１、β１をそれぞれα１´とβ１´と表現した。この｜β３´−α３´｜≧｜β３−α３｜であることが、
時刻ｔで、バッファが記憶する画面更新の、ボトルネックとなる処理部の処理開始時刻と、直近にバッファが出力した画面更新のボトルネックとなる処理部の処理完了時刻とが最も近づくタイミングであることを示す。このような判断をできることで、応答性と描画コマ数の両立をより向上できる。
【０１３９】
なお、本実施形態では、圧縮→伝送→伸張という三ステップの処理が行われる構成としたが、必ずしもこれに限らなくともよい。２のステップの処理以下であっても、４ステップの処理以上であっても適用できる。
【０１４０】
例えば、新規の四ステップ目の処理部を追加してもよい。例を図２０に示す。図では、サーバ１は変換部１０８をさらに有し、バッファ１０１から出力された画面更新に対し、色数の変換処理（例えば３２ビット色から２４ビット色への減色処理）を行う。この場合は、記憶部１０６は変換部１０８の実行状態やデータサイズ、処理開始時刻を記憶するための領域をさらに有し、変換部１０８は変換処理の開始時と終了時に記憶部１０６の状態を更新する。さらに推定部１０５は変換部１０８の変換処理の処理開始時刻と処理終了時刻の推定を併せておこなう。さらに判断部１０４は、現在処理の実行中である最新の画面更新に施される変換処理、圧縮処理、伝送処理、伸張処理のそれぞれの処理終了時刻をそれぞれα１、α２、α３、α４とし、また、バッファ１０１から画面更新が出力されたと仮定したときに当該の画面更新に施される変換処理、圧縮処理、伝送処理、伸張処理のそれぞれの処理開始時刻をそれぞれβ１、β２、β３、β４とした上で、各値の推定値に基づき、α１≦β１、α２≦β２、α３≦β３、α４≦β４の全ての条件が真となる場合にバッファ１０１へ出力指示を行うと判断する。このような構成であっても、描画コマ数と応答性との両立を実現できる。
【０１４１】
また、処理の数は、３ステップより少なくてもよい。この場合、いずれかの処理部の処理所要時間をゼロと近似し、その処理部に関する通知や推定、判断の手続きを省略してもよい。例えば伸張部２０２に関する手続きを省略した場合は、本発明の実施をサーバ１の内部に閉じた構成とすることが可能である。このときの構成を図２１に示す。このように画面更新に対する一連の処理を行う処理部がサーバ１にのみ存在する場合は、クライアント端末２の状態を受信する受信１０７は不要である。この場合は、記憶部１０６は圧縮処理と送信処理のみの実行状態やデータサイズ、処理開始時刻を記憶する。判断部１０４は、現在処理の実行中である最新の画面更新に施される圧縮処理、送信処理のそれぞれの処理終了時刻をそれぞれα１、α２とし、また、バッファ１０１から画面更新が出力されたと仮定したときに当該の画面更新に施される圧縮処理、送信処理のそれぞれの処理開始時刻をβ１、β２とした上で、各値の推定値に基づき、α１≦β１、α２≦β２の両方の条件が真となる場合にバッファ１０１へ出力指示を行うと判断する。このような構成であっても、描画コマ数と応答性との両立を実現できる。
【０１４２】
また、本実施形態では、圧縮処理、伝送処理、伸張処理を例に説明したが、これらの処理に限らず、本実施形態は適用できる。また、本実施形態では、画面転送システムを例に説明したが、これに限られない。転送されるデータは、画面更新に限られない。適宜更新される更新データに対して、並列的に施される一連の処理を実行するシステムや装置に適用できる。
【０１４３】
サーバ１は、例えば、汎用のコンピュータ装置を基本ハードウェアとして用いることでも実現することが可能である。すなわち、生成部１００、バッファ１０１、圧縮部１０２、送信部１０３、判断部１０４、推定部１０５、記憶部１０６、受信部１０７は、上記のコンピュータ装置に搭載されたプロセッサにプログラムを実行させることにより実現することができる。このとき、サーバ１は、上記のプログラムをコンピュータ装置にあらかじめインストールすることで実現してもよいし、ＣＤ−ＲＯＭなどの記憶媒体に記憶して、あるいはネットワークを介して上記のプログラムを配布して、このプログラムをコンピュータ装置に適宜インストールすることで実現してもよい。また、記憶部１０６は、上記のコンピュータ装置に内蔵あるいは外付けされたメモリ、ハードディスクもしくはＣＤ−Ｒ、ＣＤ−ＲＷ、ＤＶＤ−ＲＡＭ、ＤＶＤ−Ｒなどの記憶媒体などを適宜利用して実現することができる。
【０１４４】
以上説明した少なくとも１つの実施形態の効果は、描画コマ数と応答性を両立する画面転送システムを提供することができることである。
【０１４５】
本発明のいくつかの実施形態を説明したが、これらの実施形態は、例として提示したものであり、発明の範囲を限定することは意図していない。これら新規な実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。これら実施形態やその変形は、発明の範囲や要旨に含まれるとともに、特許請求の範囲に記載された発明とその均等の範囲に含まれる。
【符号の説明】
【０１４６】
１・・・サーバ、２・・・クライアント端末、３・・・ネットワーク、１００・・・生成部、１０１・・・バッファ、１０２・・・圧縮部、１０３・・・送信部、１０４・・・判断部、１０５・・・推定部、１０６・・・記憶部、１０７・・・受信部、１０８・・・変換部、２０１・・・受信部、２０２・・・伸長部、２０３・・・表示部、２０４・・・送信部。
【技術分野】
【０００１】
本発明の実施形態は、サーバ、サーバ制御方法、及びサーバ制御プログラムに関する。
【背景技術】
【０００２】
ネットワークを介して接続されたサーバ端末からクライアント端末に対してサーバ端末の画面の情報をパケット化してリアルタイムで配信する「画面転送システム」がある。クライアント端末は、サーバ端末が保持する画面領域の一部または全部の領域における画面情報を受け取り表示する。
【０００３】
画面転送システムを構築する際には、サーバ端末が保持する画面領域全体の内容を一定時間おきにパケット化して各クライアント端末に向けて配信するという方法と、画面領域において描画状態に変化が生じるごとに、その差分となる情報のみを変化が生じた領域の情報とともに配信するという方法がある。差分を配信する後者の方法では、描画状態の変化に応じて必要な部分のみのデータ生成が行われるため、前者の方法と比較して、ネットワーク帯域を効率的に利用することができる。
【０００４】
画面領域において最新の描画状態を得るための上述の差分を画面更新と呼ぶ。直前の描画状態が記憶されたフレームバッファに対し画面更新を反映させることにより、最新の描画状態を得ることができる。
【０００５】
ここで、画像転送システムにおいて、画面情報を転送する動作を簡単に説明する。サーバは、サーバのフレームバッファから画像更新を出力し、その画面更新を圧縮し、送信する。また、クライアントは、サーバが送信した画面更新を受け取ると、その画面更新を伸長して画面に表示する。
【０００６】
画面転送システムでは、十分な描画コマ数と応答性を両立することが重要な課題である。
【０００７】
描画コマ数（フレームレート）とは、クライアント端末にて単位時間あたりに描画される画面更新の回数である。描画コマ数が高いと画面表示が滑らかに表示される。
【０００８】
応答性とは、クライアント端末でクリック等の操作がなされてから、その操作に対応するサーバ端末上の画面変化に対し圧縮・送信・伸張などの一連の処理が施され、最終的にクライアント端末に反映されるまでの時間（応答時間）に相当する。応答性が不十分であると、ユーザが、操作結果を確認するまでの待機時間が長くなり、作業効率が低下する。
【先行技術文献】
【特許文献】
【０００９】
【特許文献１】特開２００６−２４６１５３号公報
【発明の概要】
【発明が解決しようとする課題】
【００１０】
ここで、描画コマ数を向上させるためには、フレームバッファから画面更新を出力する頻度を上げることが必要である。しかしながら、フレームバッファから画面更新を出力する頻度を不用意に上げると、応答性が劣化する場合がある。例えば、フレームバッファから出力した画面更新について、圧縮処理に移ろうとしても、直近にフレームバッファから出力した画面更新について圧縮処理を実行中の場合、その圧縮処理が完了するまでの待ち時間が発生する。このように、処理と処理の間の待ち時間が発生すると、フレームバッファから更新画像を出力してから、画面に表示するまでの時間が長くなり、応答性が劣化することになる。したがって、描画コマ数と応答性とを両立するためには、フレームバッファから画面更新を出力するタイミングを適切に選択する必要がある。
【００１１】
本発明の一実施形態では、描画コマ数と応答性とを両立するサーバを提供することを目的とする。
【課題を解決するための手段】
【００１２】
本発明の一観点にかかるサーバは、少なくとも第１データ及び第２データを記憶し、第１の指示に応じて前記第１データを出力し、第２の指示に応じて前記第２データを出力するバッファと、前記バッファが出力した第１及び第２データに対して、それぞれ第１の処理〜第Ｎ（Ｎは、２以上の整数）の処理を第１の処理〜第Ｎの処理の順番で処理を行う第１処理部〜第Ｎ処理部と、前記第１の指示に応じて前記バッファが前記第１データを出力した後、前記第１処理部〜前記第Ｎ処理部各々において、前記第１の処理〜前記第Ｎの処理各々を完了する第１-１時刻〜第１-Ｎ時刻と、前記第２のデータを、前記第１処理部〜前記第Ｎ処理部各々において、前記第１の処理〜前記第Ｎの処理各々を開始する第２-１時刻〜第２-Ｎ時刻とを推定する推定部と、前記第１-１時刻と前記第２-１時刻との関係〜前記第１-N時刻と前記第２-Ｎ時刻との関係各々が所定の関係を満たす場合、前記第２の指示を行い、満たさない場合には前記第２の指示を行わないように前記バッファを制御する制御部と、を備える。
【図面の簡単な説明】
【００１３】
【図１】本発明の第1の実施形態にかかる画面転送システムを示すブロック図。
【図２】描画命令の例を示す図。
【図３】領域情報を説明するための図。
【図４】画面更新の領域情報の一例を示す。
【図５】圧縮処理前後の記憶部１０６の記憶状態を示す表。
【図６】送信処理前後の記憶部１０６の記憶状態を示す表。
【図７】伸長処理前後の記憶部１０６の記憶状態を示す表。
【図８】判断部１０４の１度目の判断時点における記憶部１０６の記憶状態を示す表。
【図９】判断部１０４の１度目の判断時点におけるバッファ１０１が保持する画面更新を示す図。
【図１０】判断部１０４の１度目の判断時点における推定される処理時間を示す図。
【図１１】判断部１０４の２度目の判断時点における記憶部１０６の記憶状態を示す表。
【図１２】判断部１０４の２度目の判断時点におけるバッファ１０１が保持する画面更新を示す図。
【図１３】判断部１０４の２度目の判断時点における推定される処理時間を示す図。
【図１４】判断部１０４の３度目の判断時点における記憶部１０６の記憶状態を示す表。
【図１５】判断部１０４の３度目の判断時点におけるバッファ１０１が保持する画面更新を示す図。
【図１６】判断部１０４の３度目の判断時点における推定される処理時間を示す図。
【図１７】画面更新の出力を早すぎるタイミングで実行した場合の、応答性劣化を説明する図。
【図１８】画面更新の出力を早すぎるタイミングで実行した場合の、描画コマ数劣化を説明する図。
【図１９】画面更新を出力するか否かの判断の際に、閾値Ｔｈを用いた条件で判断することによる効果を説明する図。
【図２０】第１の実施形態の変形例のサーバを示すブロック図。
【図２１】第１の実施形態のサーバの構成を示すブロック図。
【発明を実施するための形態】
【００１４】
以下、本発明の実施の形態について、図面を参照しながら説明する。尚、各図において同一箇所については同一の符号を付すとともに、重複した説明は省略する。
【００１５】
本発明の実施形態にかかるサーバは、少なくとも第１データ及び第２データを記憶し、第１の指示に応じて前記第１データを出力し、第２の指示に応じて前記第２データを出力するバッファと、前記バッファが出力した第１及び第２データに対して、それぞれ第１の処理〜第Ｎ（Ｎは、２以上の整数）の処理を第１の処理〜第Ｎの処理の順番で処理を行う第１処理部〜第Ｎ処理部と、前記第１の指示に応じて前記バッファが前記第１データを出力した後、前記第１処理部〜前記第Ｎ処理部各々において、前記第１の処理〜前記第Ｎの処理各々を完了する第１-１時刻〜第１-Ｎ時刻と、前記第２のデータを、前記第１処理部〜前記第Ｎ処理部各々において、前記第１の処理〜前記第Ｎの処理各々を開始する第２-１時刻〜第２-Ｎ時刻とを推定する推定部と、前記第１-１時刻と前記第２-１時刻との関係〜前記第１-N時刻と前記第２-Ｎ時刻との関係各々が所定の関係を満たす場合、前記第２の指示を行い、満たさない場合には前記第２の指示を行わないように前記バッファを制御する制御部と、を備える。
【００１６】
以下の第1の実施形態では、本発明の実施形態に係るサーバのより具体的構成を説明する。
【００１７】
図１に示すように、本実施形態にかかるサーバの第1処理部〜第Ｎ処理部の具体例として、まず、処理部が2つの場合（つまり、Ｎ＝２の場合）として、圧縮部102、送信部103を例に示して説明する。次に、処理部が3つの場合（つまり、Ｎ＝３の場合）、変換部108、圧縮部102、送信部103を例に示して説明する。以下の例では、Ｎ＝２と３を例に説明するが、Ｎは４以上の場合もありうる。
【００１８】
また、上述した第1データ及び第2データの例として画面更新を例に説明する。
【００１９】
また、上述した第１の指示及び第2の指示の例として、画面更新の出力指示を例に説明する。
【００２０】
また、上述したサーバの制御部は、以下の実施形態のサーバ１の判断部１０３と対応する。
【００２１】
＜第１の実施形態＞
図１は、第1の実施形態にかかる画面転送システムの構成を示すブロック図である。
【００２２】
画面転送システムは、サーバ１と、クライアント２とが、ネットワーク３を介して接続されている。本実施形態では、ネットワーク３はＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）ネットワークであるとする。
【００２３】
図１を用いて、サーバ１の構成を説明する。
【００２４】
生成部１００は、サーバ１におけるオペレーティングシステム又はアプリケーションの実行状態に応じて、描画命令の生成処理を行う。
【００２５】
描画命令とは、クライアント端末２の画面の描画状態を変化させるための命令である。図２は、描画命令の例を示す図である。描画命令は、描画命令の種別を表す描画命令種別と、クライアント端末２の画面の画面領域のうち更新する領域の位置を表す領域情報と、領域情報の更新後の画像情報とを含む命令である。
【００２６】
図２で示した描画命令は、ビットマップ描画命令（ＢＩＴＭＡＰ）である。ビットマップ描画命令は、「領域情報で示される領域を画像情報によって上書き更新する」という命令である。
【００２７】
領域情報は、画面領域における画像情報の表示位置を示す数値である。図３は、領域情報を説明するための図である。図３に示すように、クライアント端末の画面全体の画面領域の、左上角を（０，０）、右下角を（Ｗｉｄｔｈ，Ｈｅｉｇｈｔ）と表したとする。図３に示す矩形（斜線で示した領域）の領域情報は、表示位置の左上座標（Ｌｅｆｔ，Ｔｏｐ）と右下座標（Ｒｉｇｈｔ，Ｂｏｔｔｏｍ）とで表すこととなる。図３の例では、（Ｗｉｄｔｈ，Ｈｅｉｇｈｔ）＝（６４０、４８０）である。また、領域情報は、左上座標（Ｌｅｆｔ，Ｔｏｐ）＝（１００，１００）、右下座標（Ｒｉｇｈｔ，Ｂｏｔｔｏｍ）＝（３００，３００）である。
【００２８】
画像情報は、領域情報に対応する領域の更新後のビットマップデータ（矩形の各画素におけるＲＧＢ３色の値など）である。
【００２９】
以上の説明では、描画命令として、ビットマップ描画命令を例にとって説明した。しかしながら、描画命令は、その他、「矩形領域間の画面情報のコピーを意味する」矩形コピー描画命令（ＣＯＰＹＲＥＣＴ）などが存在する。
【００３０】
バッファ１０１は、クライアント端末の画面の画面領域の画面情報を保持するための記憶領域を有する。初期状態においては、記憶領域に情報は記憶していない。バッファ１０１は、生成部１００から描画命令を受け取るごとに、記憶領域に描画命令を反映させ、画面情報を更新する。つまり、描画命令の領域情報に対応する記憶領域の内容を、描画命令の画像情報によって更新する。描画命令の領域情報に対応する記憶領域に、すでに画面情報が記憶されている場合は、重なる領域の古い画面情報が新しい画面情報によって上書きされる。これにより常に最新の画面情報が保持された状態が保たれる。
【００３１】
また、バッファ１０１は、画面更新の出力指示を受け取ると、前回の画面更新の出力時と現時点との画面情報の差分（この差分を、画面更新と称する。）を出力する。バッファ１０１は、前回出力時から現時点までに行われた画面情報の更新が行われた領域の情報（画面更新の領域情報と称する。）を保持している。画面更新の領域情報は、描画命令を反映させるごとに更新される。この画面更新の領域情報は、バッファ１０１が画面更新を出力するごとに、クリアされる。
【００３２】
圧縮部１０２は、画面更新の圧縮処理を行う。つまり、画面更新に含まれる画像情報に対し、ＺＬＩＢやＪＰＥＧ等の圧縮処理を施す。
【００３３】
送信部１０３は、画面更新の伝送処理を行う。入力された画面更新をネットワーク上において伝送可能な形式に変換して、クライアント端末２の受信部２０１との間で伝送処理を行う。ここで、送信部１０３が行う画面更新の伝送処理時間を定義しておく。本実施形態では、画面更新の伝送処理時間とは、送信部１０３が、画面更新の入力を受けてから、クライアント端末２０１の受信部２０１に画面更新が届くまでの時間であるとする。
【００３４】
判断部１０４は、定期的なタイミングで、バッファ１０１に対し画面更新の出力指示を出すか否かを判断する。判断部１０４は、推定部１０５が推定する処理開始時刻や処理終了時刻に基づき、判断を行う。例えば、現時点で、バッファ１０１が保持する画面更新を出力した場合に、当該画面更新の圧縮処理が完了する時刻と、現時点で、送信部１０２が伝送処理中である画面更新の伝送処理が完了する時刻とに基づき、バッファ１０１が保持する画面更新を圧縮後、待ち時間なく伝送処理に移れると判断した場合、画面更新の出力指示を出すと判断する。尚、判断部１０４は、定期的なタイミングでなく、任意のタイミングで判断を実行して良い。判断部１０４の動作の詳細は後述する。
【００３５】
推定部１０５は、圧縮部１０２、送信部１０３、伸張部２０２において行われる各処理部の処理開始時刻と処理終了時刻の推定を行う。推定に当たっては、記憶部１０７から得る各処理部の処理状態（詳細は後述する）と、バッファ１０１から得るその時々の画面更新の領域情報とを利用する。推定部１０５の動作の詳細は後述する。
【００３６】
記憶部１０６は、圧縮部１０２、送信部１０３、伸張部２０２各々の処理状態を記憶する。各処理状態は、各処理部が処理実行中であるか否かを示すフラグと、各処理部が処理中のデータ（画面更新）のデータサイズと、当該処理の処理開始時刻とから構成される。処理状態の情報の詳細は後述する。
【００３７】
受信部１０７は、クライアント端末２から伸張部２０２の処理状態に関する情報を受信する。
【００３８】
次に、クライアント端末２の構成を説明する。
【００３９】
受信部２０１は、ネットワーク３を介してサーバ１から画面更新を受信する。
【００４０】
伸張部２０２は、画面更新に含まれる圧縮された画像情報に対して伸張処理を行う。
【００４１】
表示部２０３は、ユーザに対して、画面情報を提示する。具体的には、表示部２０３は、画面領域全体の画面情報を格納するための記憶領域（フレームバッファ）を有し、そして、画面更新を受け取ると、画面更新の領域情報が示す記憶領域上の画面情報を画像情報で上書き更新する。
【００４２】
送信部２０４は、伸張部２０２の処理状態を、ネットワーク３を介してサーバ１へ送信する。
【００４３】
以上、図１を用いて、サーバ１とクライアント端末２の構成を説明した。
【００４４】
次に、サーバ１とクライアント端末２から構成される画面転送システムにおける動作を説明する。
【００４５】
画面転送システムにおける動作として、第１に、生成部１００が、描画命令を生成してから、バッファ１０１の情報を更新するまでの動作を説明する。第２に、バッファ１０１が、画面更新の出力指示を受けた場合に、画面更新を出力し、クライアント端末２が当該画面更新を反映した画面を表示するまでの動作の流れを説明する。第３に、バッファ１０１が、画面更新を出力するか否かを判断する動作の詳細について、説明する。
【００４６】
まず、第１に、生成部１００が、生成部１００が、描画命令を生成してから、バッファ１０１の画面情報を更新するまでの動作を説明する。
【００４７】
画面転送の実行が開始されると、生成部１００は、サーバ１のオペレーティングやアプリケーション（図示は省略。）の実行状態に応じて描画命令（描画命令の例は図２で示した。）を生成する。生成部１００は、描画命令をバッファ１０１へ出力する。
【００４８】
バッファ１０１は、画面転送の実行開始直後は、記憶領域に画面情報を有さない状態である。バッファ１０１は、描画命令を受け取ると、記憶領域のうち、描画命令の領域情報が示す位置の情報を、描画命令によって更新する。また、バッファ１０１は、画面情報の更新が、一度以上行われた領域の情報（画面更新の領域情報）を保持する。
【００４９】
図４は、画面更新の領域情報の一例を示す。
【００５０】
図４（ａ）は、画面転送の実行開始後、最初に、描画命令を受け取った後に、バッファ１００が記憶する画面更新の領域情報と画面情報の例である。図４（ａ）の例では、描画命令の領域情報が、（Ｌｅｆｔ，Ｔｏｐ，Ｒｉｇｈｔ，Ｂｏｔｔｏｍ）＝（１００，１００，４００，３００）である場合を示す。このように、初回の入力では、受け取った全ての情報が記憶される。
【００５１】
図４（ｂ）は、２回目の描画命令を受け取った後に、バッファ１００が記憶する画面更新の領域情報と画面情報の例である。図４（ｂ）の例では、２回目の描画命令の領域情報が（Ｌｅｆｔ，Ｔｏｐ，Ｒｉｇｈｔ，Ｂｏｔｔｏｍ）＝（２００，２００，６００，４００）である場合を示している。
【００５２】
２回目以降の入力では、既に記憶された情報の領域と新たに記憶する情報の領域とが重複する場合がある。図４（ｂ）に示すように、重複する領域がある場合、重複する部分を新しい情報によって上書き更新する。図４（ｂ）の例では、重複する領域は、（Ｌｅｆｔ，Ｔｏｐ，Ｒｉｇｈｔ，Ｂｏｔｔｏｍ）＝（２００，２００，４００，３００）の領域である。その重複する領域が、２回目の描画命令の情報によって更新される。尚、既に記憶された情報の領域と重複しない領域についての情報についても、記憶される。図４（ｂ）の例では、（Ｌｅｆｔ，Ｔｏｐ，Ｒｉｇｈｔ，Ｂｏｔｔｏｍ）＝（１００，１００，４００，２００），（１００，２００，２００，３００），（２００，２００，６００，４００）の領域である。
【００５３】
このように、生成部１００で描画命令が生成されるごとに、バッファ１０１の内容は逐一更新される。バッファ１０１の内容の更新は、判断部１０４から、画面更新の出力指示を受け取るまで繰り返し実行される。
【００５４】
次に、バッファ１０１が、画面更新の出力指示を受けてから、画面更新を出力し、クライアント端末２が当該画面更新を反映した画面を表示するまでの動作の流れを説明する。尚、バッファ１０１が、画面更新を出力するか否かの決定は、判断部１０４が行うが、その動作の詳細は後述する。
【００５５】
バッファ１０１は、画面更新の出力指示を受け取ると、前回出力時から今までに記憶した最新の画面情報と、その領域の情報を圧縮部１０２に画面更新として出力する。画面更新の出力が完了すると、これまでに記憶した画面情報とその領域の情報をクリアする。バッファ１０１は、以降は、また１から、生成部１００から受け取った描画命令を記憶していく。
【００５６】
圧縮部１０２は画面更新を受け取ると、その画面更新に含まれる画像情報に圧縮処理を施す。また、圧縮部１０２は、圧縮処理を行う際に、圧縮処理を行う対象の画面更新のデータサイズを記憶部１０６に通知する。
【００５７】
記憶部１０６は、圧縮部１０２から、画面更新のデータサイズを受け取ると、圧縮処理が実行中であることを示すフラグ（実行状態）をオン（処理中）にする。また、受け取ったデータサイズと、現在の時刻を処理開始時刻として記憶する。ここで、現在の時刻とは、例えばサーバ１が起動してから現在の経過秒数（単位：ミリ秒）などである。
【００５８】
ここで、画面更新のデータサイズの算出方法の一例を説明する。
【００５９】
バッファ１０１が出力した画面更新が、図４（ｂ）の示すものであったとする。画面更新の総画素数は、この画面更新が占める領域の面積に等しい。図４（ｂ）の例では、画面更新が占める面積（総画素数）は、（４００−１００）×（２００−１００）＋（２００−１００）×（３００−２００）＋（６００−２００）×（４００−２００）＝３００００＋１００００＋８００００＝１２００００である。本実施形態では、１画素あたりのデータサイズを３バイトとする。両者の積により、画面更新のデータサイズは、３６０キロバイトと計算できる。（なお、簡便のため１キロバイト＝１０００バイトとしている。）
記憶部１０６が、圧縮部１０２から、画面更新のデータサイズを受け取った場合に、記憶した情報を図５（ａ）に示す。図５（ａ）では、圧縮処理が処理中であり、画面更新のデータサイズは３６０キロバイトであり、圧縮処理の処理開始時刻が１０００００ である例を示している。
【００６０】
圧縮部１０２は、圧縮処理を完了すると、記憶部１０６に圧縮完了通知をする。記憶部１０６は、圧縮完了通知を受けとると、圧縮処理が実行中であることを示すフラグをオフにする。また、データサイズと処理開始時刻を削除する。図５（ｂ）に、記憶部１０６が圧縮完了通知を受け取った後の記憶状態を示す。
【００６１】
また、圧縮部１０２は、圧縮処理を完了すると、圧縮後の画面更新を送信部１０３に渡し、伝送処理を依頼する。
【００６２】
送信部１０３は、圧縮後の画面更新を受け取ると伝送処理を施す。伝送処理を施す前に、送信部１０３は、圧縮後の画面更新のデータサイズを記憶部１０６に通知する。記憶部１０６は、圧縮後の画面更新のデータサイズを受け取ると、伝送処理が実行中であることを示すフラグ（実行状態）をオン（処理中）にする。また、データサイズと、現在の時刻を処理開始時刻として記憶する。記憶部１０６が記憶された情報の例を図６（ａ）に示す。図６（ａ）の例では、圧縮後の画面更新のデータサイズが、１２０キロバイトであり、処理開始時刻が１００１００である場合を示している。
【００６３】
送信部１０３は、圧縮後の画面更新のデータサイズを記憶部１０６に通知後、圧縮後の画面更新にＴＣＰ／ＩＰの各ヘッダを付与し、クライアント端末２に向けてネットワーク３へ送出する。
【００６４】
送信部１０３は伝送処理を完了すると、記憶部１０６に伝送処理完了通知を行う。記憶部１０６は、伝送処理完了通知を受けると、伝送処理が実行中であることを示すフラグをオフにし、データサイズと処理開始時刻を削除する。伝送処理完了通知後の記憶部１０６の記憶状態を図６（ｂ）に示す。
【００６５】
クライアント端末２の受信部２０１は、伝送処理において画面更新を受け取ると、伸張部２０２に渡し、伸張を依頼する。
【００６６】
伸張部２０２は、画面更新を受け取ると、その画面更新に含まれる画像情報に伸張処理を施す。
【００６７】
伸張部２０２は、伸長処理を実行する前に、伸長処理を施す対象となる画面更新のデータサイズを送信部２０４に渡し、サーバ１への通知を依頼する。送信部２０４は、データサイズにＴＣＰ／ＩＰの各ヘッダを付与し、データサイズをサーバ１へと送出する。
サーバ１の受信部１０７は、データサイズを受信すると、ヘッダを除去する。そして、記憶部１０６へデータサイズを通知する。記憶部１０６は、データサイズを受け取ると、伸張処理が実行中であることを示すフラグをオンにする。また、伸長処理を施す対象となる画面更新のデータサイズを記憶し、現在の時刻を処理開始時刻として記憶する。図７（ａ）は、伸長処理が実行中の際に、記憶部１０６に記憶された情報の例である。図７（ａ）では、伸張前の画面更新のデータサイズとして１２０キロバイト、処理開始時刻として１００３００が記憶されている。
【００６８】
伸張部２０２は伸張処理を完了すると、伸長処理完了通知を、送信部２０４を介して、サーバ１の記憶部１０６に通知する。記憶部１０６は、伸長処理完了通知を受け取ると、伸張処理が実行中であることを示すフラグをオフにし、データサイズと処理開始時刻を削除する。伸長処理完了通知を受け取った後の記憶部１０６の状態を図７（ｂ）に示す。
【００６９】
伸張部２０２は、伸張が完了した画面更新を表示部２０３に渡し、表示を依頼する。
【００７０】
表示部２０３は、画面領域全体の画面情報を保持する記憶領域を有しており、画面更新の領域情報が示す領域の情報を、伸張後の画像情報で上書き更新する。表示部２０３の状態はユーザに視覚的に提示される。
【００７１】
以上、バッファ１０１が、画面更新の出力指示を受けてから、画面更新を出力し、クライアント端末２が当該画面更新を反映した画面を表示するまでの動作の流れを説明した。
【００７２】
なお、圧縮部１０２、送信部１０３、伸張部２０２はいずれも並列的に動作が可能である。つまり、例えば圧縮部１０２が圧縮後の画面更新を送信部１０３に渡したすぐ後に、バッファ１０１から新たな画面更新が渡されれば、たとえ送信部１０３が先の画面更新の伝送処理中であったとしても、新たな画面更新の圧縮処理を実行することが可能である。
【００７３】
次に、判断部１０４が、バッファ１０１に、画面更新を出力させるか否かを判断する動作の詳細について、説明する。
【００７４】
判断部１０４は、任意のタイミングで、バッファ１０１に画面更新の出力指示を出すか否かの判断を行う。例えば一定時間間隔ごとに判断を開始してよい。
【００７５】
以下では、３つの時刻で判断する例を説明する。第１の時刻は、１００４００であり、第２の時刻は、１００５００であり、第３の時刻は、１００５４０であるとする。
【００７６】
まず、第１の時刻である、１００４００の時点で、判断する例を説明する。
【００７７】
まず、判断部１０４は、推定部１０５に対し、次の二種類の時刻を推定するよう要求する。一つ目は、現在処理の実行中である最新の画面更新に施される圧縮処理、伝送処理、伸張処理のそれぞれの処理終了時刻である。ここで、最新の画面更新とは、現時点から直近の時点で、バッファが出力した画面更新である。それぞれα１、α２、α３と示す。二つ目は、もし今、バッファ１０１から画面更新が出力されたと仮定したときに、当該の画面更新に施される圧縮処理、伝送処理、伸張処理のそれぞれの処理開始時刻である。それぞれβ１、β２、β３と示す。
【００７８】
推定部１０５は、推定の要求を受け取ると、上述の二種類の時刻を次の手順により推定する。
【００７９】
まず、一つ目の時刻（α１、α２、α３）について説明する。始めに、推定部１０５は、記憶部１０６に対し情報の読み出しを依頼する。図８に、記憶部１０６が記憶している情報の例を示す。
【００８０】
図８は、圧縮部１０２が、画面更新１００１を処理中で、伸張部２０２が画面更新１００２を処理中である様子が示されている。
【００８１】
推定部１０５は、図８の情報から、現在処理中の最新の画面更新の、圧縮処理、伝送処理、伸張処理のそれぞれの処理終了時刻を推定する。
【００８２】
本実施形態では、推定部１０５は、以下の値を有しているものとする。
【００８３】
・圧縮部１０２の平均処理所要時間：ＴＣ（ミリ秒／キロバイト）
・送信部１０３の平均処理所要時間：ＴＴ（ミリ秒／キロバイト）
・伸張部２０２の平均処理所要時間：ＴＤ（ミリ秒／キロバイト）
・圧縮部１０２の平均圧縮率：Ｃ（％）
また、本実施形態においては、ＴＣ＝０．８ミリ秒／キロバイト、ＴＴ＝３．２ミリ秒／キロバイト、ＴＤ＝４．８ミリ秒／キロバイト、Ｃ＝５０％であるとする。
【００８４】
推定部１０５は、推定部１０５が有する上述した値を用いて、最新の画面更新、すなわち画面更新１００１に対する処理終了時刻を、以下の方法で推定する。
【００８５】
推定部１０５は、圧縮処理終了時刻を、圧縮処理開始時刻＋圧縮前データサイズ×ＴＣと推定する。上記の例では、α１＝１００３６０＋１００×０．８＝１００４４０と推定する。推定部１０５は、伝送処理終了時刻を、伝送処理開始時刻＋圧縮後データサイズ×ＴＴと推定する。伝送処理開始時刻は圧縮処理終了時刻に等しく、また圧縮後データサイズは圧縮前データサイズ×Ｃとみなす。上記の例では、α２＝１００４４０＋１００×５０÷１００×３．２＝１００６００と推定する。推定部１０５は、伸張処理開始時刻を、伸張処理開始時刻＋圧縮後データサイズ×ＴＤと推定する。伸張処理開始時刻は伝送処理終了時刻に等しいとみなす。上記の例では、α３＝１００６００＋１００×５０÷１００×４．８＝１００８４０と推定する。
【００８６】
次に、二つ目の時刻（β１、β２、β３）について説明する。
【００８７】
始めに、推定部１０５はバッファ１０１に対し、現在記憶している画面更新の領域情報の読み出しを依頼する。例を図９に示す。図９の例では、バッファ１０１は現在記憶している画面更新の領域情報として、（Ｌｅｆｔ，Ｔｏｐ，Ｒｉｇｈｔ，Ｂｏｔｔｏｍ）＝（１００，１００，３５０，２００）を推定部１０５に返す。
【００８８】
推定部１０５は、もし今、バッファ１０１から画面更新が出力されたと仮定したときに、この画面更新に施されるであろう圧縮処理、伝送処理、伸張処理のそれぞれの処理開始時刻を推定する。
【００８９】
まず、この画面更新のデータサイズを算出する。画素数は（３５０−１００）×（２００−１００）＝２５００００である。この値に、１画素あたりのバイト数として３バイトを乗じ、データサイズを７５キロバイトと算出する。さらに上述のＴＣ、ＴＴ、Ｃを用いて各処理の開始時刻を推定する。圧縮処理開始時刻は現在の時刻を取得し、それをそのまま利用する。現在時刻は、１００４００であるとしたので、β１＝１００４００とする。伝送処理開始時刻は圧縮処理終了時刻に等しいとみなし、β２＝１００４００＋７５×０．８＝１００４６０と推定する。伸張処理開始時刻は伝送処理終了時刻に等しいとみなし、β３＝１００４６０＋７５×５０÷１００×３．２＝１００５８０と推定する。
【００９０】
推定部１０５が、（α１、α２、α３）と（β１、β２、β３）を算出すると、判断部１０４は、これらを用いて、バッファ１０１に画面更新の出力指示を出すか否かを判断する。
【００９１】
判断部１０５は、α１≦β１、α２≦β２、α３≦β３の三つの条件がすべて真となる場合に、出力指示を出すと判断し、それ以外の場合には、出力指示を出さないと判断する。
【００９２】
以上の例では、α１＝１００４４０、β１＝１００４００であるため、条件を満たしていない。したがって、判断部１０４はバッファ１０１に画面更新の出力指示を出さないと判断する。
【００９３】
図１０に、以上説明した例における、推定時刻である（α１、α２、α３）と（β１、β２、β３）との関係を示す。
【００９４】
図１０では、時間軸に沿った各処理の処理状態を示している。図中の四角は、各処理部が処理中である様子を意味する。四角内の数字は各処理の所要時間である。もし現在時刻１００４００（図中右側の矢印）において、バッファ１０１からの画面更新の出力指示を行ったと仮定すると、その時点で圧縮部１０２は前の画面更新を処理実行中であるため、新たな画面更新の圧縮処理に即座に取りかかることができない。その結果、応答性が低下する。つまり、α１≦β１の条件を満たしていないと、応答性が低下する。したがって、判断部１０４は、第１の時点（１００４００）では画面更新の出力指示を行うべきでないと判断する。
【００９５】
判断部１０４の処理は以上で終了する。既に述べたように、判断部１０４の判断処理は、任意のタイミングで繰り返し行われる。
【００９６】
以下では、上記の判断終了時から１００ミリ秒が経過した第２の時刻（時刻１００５００）で、再び判断部１０４の判断処理が開始したときの処理の流れを述べる。
【００９７】
先程と同様、判断部１０４は、二種類の時刻を推定するよう推定部１０５に要求する。
【００９８】
推定部１０５が行う、一つ目の時刻（α１、α２、α３）の推定について説明する。
【００９９】
始めに、推定部１０５は、記憶部１０６に対し情報の読み出しを依頼する。図１１に、記憶部１０６が記憶している情報の例を示す。図１１に示すように、前述した判断時点（時刻１００４００）では、圧縮処理中だった画面更新（画面更新１１０１）が、伝送処理に移っている。また、図１１には、伸張部２０２は、画面更新１１０２を引き続き伸張処理を継続している様子が示されている。
【０１００】
推定部１０５は、記憶部１０６の情報から、現在処理の実行中である最新の画面更新、すなわち画面更新１１０１についてα１、α２、α３を推定する。圧縮処理終了時刻については既に圧縮処理が終了しているため計算を行わない。伝送処理終了時刻は、伝送処理開始時刻＋圧縮後データサイズ×ＴＴで算出し、推定する。α２＝１００４４０＋５０×３．２＝１００６００と推定できる。伸張処理終了時刻は、伸張処理開始時刻＋圧縮後データサイズ×ＴＤと推定する。ここで、伸張処理開始時刻は、伝送処理終了時刻と推定し、算出する。α３＝１００６００＋５０×４．８＝１００８４０と推定できる。
【０１０１】
次に、推定部１０５が行う、二つ目の時刻（β１、β２、β３）の推定について説明する。
【０１０２】
始めに、推定部１０５はバッファ１０１に対し、現在記憶している画面更新の領域情報の読み出しを依頼する。例を図１２に示す。図９と図１２を比較するとわかるとおり、前述した判断時点（時刻１００４００）と比較して、現時点（時刻１００５００）では、描画命令が追加で発生しており、バッファ１０１のデータ量が増加している。
【０１０３】
図１２に示すように、バッファ１０１は、現在記憶している画面更新の領域情報として、（Ｌｅｆｔ，Ｔｏｐ，Ｒｉｇｈｔ，Ｂｏｔｔｏｍ）＝（１００，１００，３５０，２００），（２００，２００，４００，３００）を推定部１０５に渡す。推定部１０５は、前述した算出方法と同様の方法で、β１、β２、β３を推定する。
【０１０４】
画素数は、画面行使の領域情報から、（３５０−１００）×（２００−１００）＋（４００−２００）×（３００−２００）＝４５００００と算出できる。データサイズは、算出した画素数に、１画素あたりのバイト数として３バイトを乗じ、１３５キロバイトと算出できる。圧縮処理開始時刻は現在の時刻をそのまま利用し、β１＝１００５００とする。伝送処理開始時刻は圧縮処理終了時刻に等しいとみなす。β２＝１００５００＋１３５×０．８＝１００６０８と推定できる。伸張処理開始時刻は伝送処理終了時刻に等しいとみなす。β３＝１００６０８＋１３５×５０÷１００×３．２＝１００８２４と推定できる。
【０１０５】
判断部１０４は、以上の二種類の時刻の推定値（α１、α２、α３）と（β１、β２、β３）を用いて、バッファ１０１に画面更新の出力指示を出すか否かを判断する。今回はα１の計算を行わなかったが、α１はすでに経過している。したがって、α１≦β１は真とみなすことができる。また、α２＝１００６００、β２＝１００６０８であるため、α２≦β２の条件は真である。しかし、α３＝１００８４０、β３＝１００８２４であるため、α３≦β３の条件は真でない。したがって、判断部１０４はバッファ１０１に画面更新の出力指示を出さないと判断する。
【０１０６】
図１３に、以上説明した、（α１、α２、α３）と（β１、β２、β３）との間の関係を示す。もし、現在時刻１００５００において、バッファ１０１からの画面更新の出力指示を行ったと仮定する。この場合、現時点で、圧縮部１０２は処理実行中でないため、新たな画面更新の圧縮処理に即座に取りかかることができる。また、送信部１０３は、現時点では伝送処理中だが、圧縮処理の完了時点（β２）では、処理が完了（α２の時点で完了）していると推定できる。したがって、圧縮処理完了後、すぐに、新たな画面更新の送信処理に取りかかることができる。しかし、伸張部２０２は、新たな画像更新の伝送処理が完了すると推定される時刻（β３）において、処理実行中であると推定される（β３＜α３）。したがって、新たな画像更新の伝送処理完了後、すぐに、新伸張処理に取りかかることができない。したがって、判断部１０４は、この時点では、バッファ１０１から画面更新の出力指示を行うべきでないと判断する。
【０１０７】
判断部１０４の処理は以上で終了する。
【０１０８】
以下では、上記の判断終了時からさらに４０ミリ秒が経過した第３の時刻（時刻１００５４０）で、再び判断部１０４の判断処理が開始したときの処理の流れを説明する。
【０１０９】
以前の判断と同様、判断部１０４は、二種類の時刻を推定するよう推定部１０５に要求する。
【０１１０】
まず、一つ目の時刻（α１、α２、α３）の推定について説明する。
【０１１１】
図１４に、時刻１００５４０における、記憶部１０６が保持する情報を示す。
【０１１２】
図１４に示す通り、圧縮処理、伝送処理、伸長処理それぞれの処理状態は、前回の判断時点（時刻１００５００）から変化していないものとする。つまり、伝送処理、伸長処理が処理を継続して行っている。
【０１１３】
推定部１０５は、α１、α２、α３を推定する。推定部１０５は、今回のように、記憶部１０６の状態に変化がないことを検出した場合は、α１、α２、α３の推定を省略し、前回の推定結果をそのまま再利用することができる。その結果、α１は推定値なし、α２＝１００６００、α３＝１００８４０との推定結果を得る。
【０１１４】
次に、二つ目の時刻（β１、β２、β３）の推定について説明する。
【０１１５】
図１５に、時刻１００５４０における、バッファ１０１の状態を示す。
【０１１６】
図１２と図１５を比較するとわかるとおり、現時点（１００５４０）と、以前判断した時点（１００５００）との間に、描画命令の追加発生はなく、バッファ１０１の状態に変化がない。
【０１１７】
したがって、推定部１０５は、データ量として、前回算出した値と同様１３５キロバイトを得る。また、圧縮処理開始時刻は、現在の時刻をそのまま利用し、β１＝１００５４０とする。伝送処理開始時刻は圧縮処理終了時刻に等しいとみなし、β２＝１００５４０＋１３５×０．８＝１００６４８と推定する。伸張処理開始時刻は伝送処理終了時刻に等しいとみなし、β３＝１００６４８＋１３５×５０÷１００×３．２＝１００８６４と推定する。
【０１１８】
判断部１０４は、以上の二種類の時刻の推定値を用いて、バッファ１０１に画面更新の出力指示を出すか否かを判断する。前回の判断時と同様の理由で、α１≦β１は真と判断できる。α２＝１００６００、β２＝１００６４８であるため、α２≦β２の条件は真である。α３＝１００８４０、β３＝１００８６４であるため、α３≦β３の条件は真である。全ての条件が真となったため、判断部１０４はバッファ１０１に画面更新の出力指示を出すと判断する。
【０１１９】
図１６に、以上説明した、（α１、α２、α３）と（β１、β２、β３）との間の関係を示す。
【０１２０】
図１６に示す通り、現在時刻１００５４０において、バッファ１０１からの画面更新の出力指示を行ったと仮定すると、当該の画面更新に対する各処理が完了した時点で次の処理に即座に移れるようになっていることが分かる。
【０１２１】
判断部１０４は、バッファ１０１に対し、画面更新の出力指示を行う。以上で判断部１０４の処理は終了する。
【０１２２】
以上が、本実施形態の動作説明である。
【０１２３】
以上、本実施の形態によれば、判断部１０４は、繰り返し、判断を実行し、β１、β２、β３それぞれが、α１、α２、α３それぞれを初めて上回った時点で、バッファ１０１に対して、画面更新の出力指示を行っている。β１、β２、β３それぞれが、α１、α２、α３それぞれを上回った時点で、バッファ１０１に対する出力指示を行っているため、並列的に動作可能な、画面更新に施される一連の処理（圧縮→伝送→伸張）において、各処理を終えた画面更新が即座に次の処理へ移行することができる。また、「初めて」上回った時点で、出力指示を行うこととしているため、画面更新の出力頻度も高い状態を維持できる。また、ボトルネックの処理部（本実施形態では伸張部２０２）が処理を行っていない時間を最小限に抑えることができる。したがって、応答性と描画コマ数の両立を実現できる。
【０１２４】
より具体的に説明する。
【０１２５】
図１７に示すように、もし本実施形態で決定した出力指示のタイミングよりも早いタイミングで出力指示を行った場合、処理後の画面更新が即座に次の処理に移行できず、余計な待ち時間が発生することになる（応答性が悪化する）。
【０１２６】
図１８に示すように、本実施形態で決定した出力指示のタイミングよりも遅いタイミングで出力指示を行った場合、ボトルネックの処理部が処理を行っていない時間が生じることになる（描画コマ数が悪化することになる）。
【０１２７】
本実施形態によれば、一連の処理が全て完了するまでの所要時間を小さくしたいという要求と、単位時間あたりに行われる一連の処理の回数を大きくしたいという要求を、同時に満たすことが可能になる。つまり、描画コマ数と応答性を両立することが可能になる。
【０１２８】
また、本実施形態では、判断部１０４が判断処理を繰り返し実行するものとした。前述の通り、画面転送では画面変化が生じた場合にのみ送出すべきデータが発生するため、ある時点において、以降将来にどのような画面変化が生じるかは予測できない。判断処理を繰り返し行うという本実施形態の動作は、このような特殊なデータの発生パターンを有する画面転送において効果的にバッファ１０１からの出力タイミングを決定することができる。
【０１２９】
なお、本実施形態では、一つ目の時刻（α１、α２、α３）と二つ目の時刻（β１、β２、β３）を全て推定した後に判断処理を行っているが、必ずしも全てを推定してから判断を行わなくともよい。例えば、始めにα１とβ１のみの推定を行ってからα１≦β１の真偽を確かめ、真の場合にのみα２とβ２の推定を行い、さらにα２≦β２が真の場合にのみα３とβ３の推定を行いα３≦β３の真偽を確かめる、といった手順であってもよい。こうした手順を採用すれば、一度に全てを推定するよりも少ない計算量で同等の判断をすることができる。
【０１３０】
また、本実施形態では、推定部１０５が、各処理部の平均処理所要時間（ＴＣ、ＴＴ、ＴＤ）や圧縮率（Ｃ）を事前に有しているものとして説明したが、これに限られない。例えば、画面転送の開始時に試験的に圧縮処理や伝送処理、伸張処理を行い、その所要時間や圧縮率からＴＣ、ＴＴ、ＴＤ、Ｃを決定してよい。また、画面転送の実施の任意のタイミングで、各処理部の処理の所要時間や圧縮率の実績を求め、ＴＣ、ＴＴ、ＴＤ、Ｃを適宜更新してもよい。また、ＴＣ、ＴＴ、ＴＤ、Ｃを決定する際に、サーバ１やクライアント端末２のＣＰＵ性能などの値を反映してもよい。また、ＴＣ、ＴＴ、ＴＤ、Ｃを決定する際に、ネットワーク３の通信帯域やＲＴＴ（Ｒｏｕｎｄ Ｔｒｉｐ Ｔｉｍｅ）を測定し決定に反映してよい。こうした手順を採用すれば、画面転送を実行する環境ごとに異なる端末性能やネットワーク性能に適応することができる。
【０１３１】
また、本実施形態では、判断処理を定期的に行うこととして説明したが、判断処理のタイミングは任意でよい。
【０１３２】
例えば、バッファ１０１おいて少なくとも一度以上更新が行われた領域が増えたことを検出したときに、判断部１０４に対し判断処理の開始を依頼してもよい。判断部１０４は、周期的なタイミングで判断処理を行うのに加えて、バッファ１０１から依頼があった際に追加的に判断処理を行う。バッファ１０１において少なくとも一度以上更新が行われた領域が拡大した場合、バッファ１０１が出力する画面更新のデータサイズが増加する。その結果、圧縮処理、伝送処理、伸張処理の処理時間は大きくなることが予期される。つまり、β１、β２、β３の値が増加する。したがって、α１≦β１、α２≦β２、α３≦β３の条件が成立する可能性が高くなる。したがって、このようなタイミングで判断処理を行うことで、バッファ１０１からの出力指示を、より適切なタイミングで行える。
【０１３３】
また、本実施形態では、α１≦β１、α２≦β２、α３≦β３の三つの条件が真の場合、つまり、バッファが記憶している画面更新の圧縮処理、伝送処理、伸長処理各々の処理の推定開始時刻であるβ１、β２、β３が、直近に出力した画面更新の圧縮処理、伝送処理、伸長処理各々の処理完了時刻であるα１、α２、α３と同一か、後になるように条件を設定した。しかしながら、必ずしも、各処理の推定開始時刻が、各処理の推定完了時刻と同一か、後になる必要はない。
【０１３４】
例えば適当な閾値Ｔｈを設けて、α１≦β１、α２≦β２、α３≦β３の三つの条件の代わりに、条件をα１≦β１＋Ｔｈ、α２≦β２＋Ｔｈ、α３≦β３＋Ｔｈの三つの条件としてもよい。この条件では、各処理の推定開始時刻が、推定完了時刻以前となる場合がある。この場合、推定開始時刻から推定完了時刻まで、処理の待ち時間が、多少生じることにはなるが、待ち時間は、Ｔｈ以内である。したがって、応答性と描画コマ数の両立を実現できる。尚、閾値Ｔｈの値は、圧縮処理、伝送処理、伸長処理それぞれの条件毎に異なる値としてもよい。
【０１３５】
こうしたやり方は、判断処理を周期Ｔで定期的に行う場合において、描画コマ数と応答性の両立をより向上できる。図１９を用いて説明する。
【０１３６】
ある時刻ｔでの判断処理においてβ３がα３をわずかに上回らなかった場合、次の判断の時刻ｔ´＝ｔ＋Ｔでは、β３がα３を大きく上回ることとなる。条件を、α１≦β１＋Ｔｈ、α２≦β２＋Ｔｈ、α３≦β３＋Ｔｈとしておけば、このようにβ３がα３をわずかに上回る場合であっても、画面更新の出力を実行すると判断できる。この場合、応答性はわずかに劣化するが、描画コマ数の劣化を防ぐことができ、応答性と描画コマ数の両立を実現できる。
【０１３７】
特に、Ｔｈ＝Ｔ／２と定めた場合は、応答性と描画コマ数の両立のために、より適切な判断ができる。つまり、この条件を定めた場合、バッファが記憶する画面更新の、ボトルネックとなる処理部の処理開始時刻と、直近にバッファが出力した画面更新のボトルネックとなる処理部の処理完了時刻とが最も近づくタイミングで、バッファの更新画像を出力することができるようになる。ここで、ボトルネックとなる処理部とは、α１≦β１＋Ｔｈ、α２≦β２＋Ｔｈ、α３≦β３＋Ｔｈの条件を、最後の時刻に満たす処理部である。
【０１３８】
例えば、ボトルネックとなる処理部が、伸長部である場合を考える。この場合、α３≦β３＋Ｔｈの条件を最後に満たす。時刻ｔでの判断処理で、α１≦β１＋Ｔ／２、α２≦β２＋Ｔ／２、α３≦β３＋Ｔ／２すべてが成立した場合、その後どのような画面変化が生じようとも、時刻ｔ´（ｔ´＝ｔ＋Ｔ）においては、｜β３´−α３´｜≧｜β３−α３｜が成立することとなる。（ここで、時刻ｔ´での、α１、β１をそれぞれα１´とβ１´と表現した。この｜β３´−α３´｜≧｜β３−α３｜であることが、
時刻ｔで、バッファが記憶する画面更新の、ボトルネックとなる処理部の処理開始時刻と、直近にバッファが出力した画面更新のボトルネックとなる処理部の処理完了時刻とが最も近づくタイミングであることを示す。このような判断をできることで、応答性と描画コマ数の両立をより向上できる。
【０１３９】
なお、本実施形態では、圧縮→伝送→伸張という三ステップの処理が行われる構成としたが、必ずしもこれに限らなくともよい。２のステップの処理以下であっても、４ステップの処理以上であっても適用できる。
【０１４０】
例えば、新規の四ステップ目の処理部を追加してもよい。例を図２０に示す。図では、サーバ１は変換部１０８をさらに有し、バッファ１０１から出力された画面更新に対し、色数の変換処理（例えば３２ビット色から２４ビット色への減色処理）を行う。この場合は、記憶部１０６は変換部１０８の実行状態やデータサイズ、処理開始時刻を記憶するための領域をさらに有し、変換部１０８は変換処理の開始時と終了時に記憶部１０６の状態を更新する。さらに推定部１０５は変換部１０８の変換処理の処理開始時刻と処理終了時刻の推定を併せておこなう。さらに判断部１０４は、現在処理の実行中である最新の画面更新に施される変換処理、圧縮処理、伝送処理、伸張処理のそれぞれの処理終了時刻をそれぞれα１、α２、α３、α４とし、また、バッファ１０１から画面更新が出力されたと仮定したときに当該の画面更新に施される変換処理、圧縮処理、伝送処理、伸張処理のそれぞれの処理開始時刻をそれぞれβ１、β２、β３、β４とした上で、各値の推定値に基づき、α１≦β１、α２≦β２、α３≦β３、α４≦β４の全ての条件が真となる場合にバッファ１０１へ出力指示を行うと判断する。このような構成であっても、描画コマ数と応答性との両立を実現できる。
【０１４１】
また、処理の数は、３ステップより少なくてもよい。この場合、いずれかの処理部の処理所要時間をゼロと近似し、その処理部に関する通知や推定、判断の手続きを省略してもよい。例えば伸張部２０２に関する手続きを省略した場合は、本発明の実施をサーバ１の内部に閉じた構成とすることが可能である。このときの構成を図２１に示す。このように画面更新に対する一連の処理を行う処理部がサーバ１にのみ存在する場合は、クライアント端末２の状態を受信する受信１０７は不要である。この場合は、記憶部１０６は圧縮処理と送信処理のみの実行状態やデータサイズ、処理開始時刻を記憶する。判断部１０４は、現在処理の実行中である最新の画面更新に施される圧縮処理、送信処理のそれぞれの処理終了時刻をそれぞれα１、α２とし、また、バッファ１０１から画面更新が出力されたと仮定したときに当該の画面更新に施される圧縮処理、送信処理のそれぞれの処理開始時刻をβ１、β２とした上で、各値の推定値に基づき、α１≦β１、α２≦β２の両方の条件が真となる場合にバッファ１０１へ出力指示を行うと判断する。このような構成であっても、描画コマ数と応答性との両立を実現できる。
【０１４２】
また、本実施形態では、圧縮処理、伝送処理、伸張処理を例に説明したが、これらの処理に限らず、本実施形態は適用できる。また、本実施形態では、画面転送システムを例に説明したが、これに限られない。転送されるデータは、画面更新に限られない。適宜更新される更新データに対して、並列的に施される一連の処理を実行するシステムや装置に適用できる。
【０１４３】
サーバ１は、例えば、汎用のコンピュータ装置を基本ハードウェアとして用いることでも実現することが可能である。すなわち、生成部１００、バッファ１０１、圧縮部１０２、送信部１０３、判断部１０４、推定部１０５、記憶部１０６、受信部１０７は、上記のコンピュータ装置に搭載されたプロセッサにプログラムを実行させることにより実現することができる。このとき、サーバ１は、上記のプログラムをコンピュータ装置にあらかじめインストールすることで実現してもよいし、ＣＤ−ＲＯＭなどの記憶媒体に記憶して、あるいはネットワークを介して上記のプログラムを配布して、このプログラムをコンピュータ装置に適宜インストールすることで実現してもよい。また、記憶部１０６は、上記のコンピュータ装置に内蔵あるいは外付けされたメモリ、ハードディスクもしくはＣＤ−Ｒ、ＣＤ−ＲＷ、ＤＶＤ−ＲＡＭ、ＤＶＤ−Ｒなどの記憶媒体などを適宜利用して実現することができる。
【０１４４】
以上説明した少なくとも１つの実施形態の効果は、描画コマ数と応答性を両立する画面転送システムを提供することができることである。
【０１４５】
本発明のいくつかの実施形態を説明したが、これらの実施形態は、例として提示したものであり、発明の範囲を限定することは意図していない。これら新規な実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。これら実施形態やその変形は、発明の範囲や要旨に含まれるとともに、特許請求の範囲に記載された発明とその均等の範囲に含まれる。
【符号の説明】
【０１４６】
１・・・サーバ、２・・・クライアント端末、３・・・ネットワーク、１００・・・生成部、１０１・・・バッファ、１０２・・・圧縮部、１０３・・・送信部、１０４・・・判断部、１０５・・・推定部、１０６・・・記憶部、１０７・・・受信部、１０８・・・変換部、２０１・・・受信部、２０２・・・伸長部、２０３・・・表示部、２０４・・・送信部。
【特許請求の範囲】
【請求項１】
少なくとも第１データ及び第２データを記憶し、第１の指示に応じて前記第１データを出力し、第２の指示に応じて前記第２データを出力するバッファと、
前記バッファが出力した第１及び第２データに対して、それぞれ第１の処理〜第Ｎ（Ｎは、２以上の整数）の処理を第１の処理〜第Ｎの処理の順番で処理を行う第１処理部〜第Ｎ処理部と、
前記第１の指示に応じて前記バッファが前記第１データを出力した後、前記第１処理部〜前記第Ｎ処理部各々において、前記第１の処理〜前記第Ｎの処理各々を完了する第１-１時刻〜第１-Ｎ時刻と、前記第２のデータを、前記第１処理部〜前記第Ｎ処理部各々において、前記第１の処理〜前記第Ｎの処理各々を開始する第２-１時刻〜第２-Ｎ時刻とを推定する推定部と、
前記第１-１時刻と前記第２-１時刻との関係〜前記第１-N時刻と前記第２-Ｎ時刻との関係各々が所定の関係を満たす場合、前記第２の指示を行い、満たさない場合には前記第２の指示を行わないように前記バッファを制御する制御部と、
を備えるサーバ。
【請求項２】
前記第1処理部〜前記第N処理部は、前記第1データに対して、第ｍ処理部が第ｍの処理（ｍ＝１〜Nいずれかの整数）を実行するタイミングと重複するタイミングで、前記第2データに対して、第ｎ処理部（n＝m−１以下の整数）が、第ｎの処理を実行できる請求項１記載のサーバ。
【請求項３】
前記所定の関係は、前記第１-１時刻と前記第２-１時刻との差〜前記第１-N時刻と前記第２-N時刻との差各々が、所定の閾値以下である請求項２記載のサーバ。
【請求項４】
前記所定の閾値は、前記第1-1時刻と前記第2-1時刻との差〜前記第1-N時刻と前記第2-N時刻との差各々のうち最も大きな値が、正であって、かつもっとも０に近い値となる値である請求項３記載のサーバ。
【請求項５】
前記推定部は、第１時点で推定した、前記第１-１時刻〜前記第１-Ｎ時刻及び前記第２-１時刻〜前記第２-Ｎ時刻に関して、前記第１-１時刻と前記第２-１時刻との関係〜前記第１-Ｎ時刻と前記第２-Ｎ時刻との関係各々が所定の関係を満たさない場合には、前記第１時点以後の第２時点に、再度、前記第１-１時刻〜前記第Ｎ-１時刻と前記第２-１時刻〜前記第２-Ｎ時刻とを推定し、
前記制御部は、前記第２時点に推定した前記第１-１時刻〜前記第１-Ｎ時刻及び前記第２-１時刻〜前記第２-Ｎ時刻に関して、前記第１-１時刻と前記第２-１時刻との関係〜前記第１-Ｎ時刻と前記第２-Ｎ時刻との関係各々が所定の関係を満たす場合、前記第２の指示を行い、満たさない場合には前記第２の指示を行わない請求項３記載のサーバ。
【請求項６】
前記第2時点と前記第1時点との差がTである場合、
前記所定の閾値はT/2である
請求項５記載のサーバ。
【請求項７】
前記推定部は、前記第１-１時刻〜前記第１-Ｎ時刻と、前記第２-１時刻〜前記第２-Ｎ時刻とを、所定の周期Ｔ毎に推定し、
前記所定の閾値は、Ｔ／２以下である請求項３記載のサーバ。
【請求項８】
前記所定の閾値は、０以下である請求項３記載のサーバ。
【請求項９】
前記第２データは、前記バッファが前記第１データを出力以後に記憶したデータである請求項２記載のサーバ。
【請求項１０】
前記第２-１時刻〜前記第２-Ｎ時刻は、前記第２データに基づき、推定する請求項９記載のサーバ。
【請求項１１】
前記第１データ及び前記第２データは、ネットワークを介して接続されたクライアント端末が表示する画面情報を更新する情報である請求項２記載のサーバ。
【請求項１２】
前記第１〜前記第Ｎ処理部は、圧縮処理部と送信処理部を含む請求項１記載のサーバ。
【請求項１３】
前記クライアント端末は、前記第Ｎの処理を行った前記第１データ及び前記第２データに対して、第Ｎ＋１の処理を行う第Ｎ＋１処理部を有し、
前記推定部は、前記第１データを、前記第Ｎ＋１処理部が、前記第Ｎ＋１の処理を完了する第１-(Ｎ＋１)時刻と、前記第２データを、前記第Ｎ＋１の処理部が、前記第Ｎ＋１の処理を開始する第２-(Ｎ＋１)時刻とを推定し、
前記制御部は、更に、前記第１-(Ｎ＋１)時刻と前記第２-(Ｎ＋１)との差が、前記所定の閾値以下である場合に、前記バッファに対して前記第2データを出力する指示を行い、前記所定の閾値より大きい場合に、前記バッファに対して前記第2データを出力する指示を行わないように前記バッファを制御する請求項３記載のサーバ。
【請求項１４】
前記第Ｎ＋１の処理部は、伸長処理部であり、前記第Ｎ＋１の処理は、前記圧縮処理で圧縮された前記第１データ及び前記第２データに対して伸長する伸長処理である請求項１３記載のサーバ。
【請求項１５】
前記推定部は、前記バッファが前記第２データとして新たにデータを記憶したタイミングで、前記第１-１時刻〜前記第１-Ｎ時刻及び前記第2-１時刻〜前記第2-Ｎ時刻を推定する請求項９記載のサーバ。
【請求項１６】
前記推定部は、前記第2-１時刻〜前記第2-Ｎ時刻を推定する以前に、前記第１データに関して、前記第１-１時刻〜前記第１-Ｎ時刻いずれかを推定していた場合、前記第１-１時刻〜前記第１-Ｎ時刻を推定する際、以前推定した、前記第１-１時刻〜前記第１-Ｎ時刻を利用して推定する請求項１記載のサーバ。
【請求項１７】
前記推定部は、前記第１-１時刻〜前記第１-Ｎ時刻及び前記第2-１時刻〜前記第2-Ｎ時刻を推定する際、前記ネットワークの状態を考慮して推定する請求項１記載のサーバ。
【請求項１８】
少なくとも第１データ及び第２データを記憶し、第１の指示に応じて前記第１データを出力し、第２の指示に応じて前記第２データを出力するバッファステップと、
前記バッファステップで出力した第１及び第２データに対して、それぞれ第１の処理〜第Ｎ（Ｎは、２以上の整数）の処理を第１の処理〜第Ｎの処理の順番で処理を行う第１処理ステップ〜第Ｎ処理ステップと、
前記第１の指示に応じて前記バッファステップで前記第１データを出力した後、前記第１処理ステップ〜前記第Ｎ処理ステップ各々において、前記第１の処理〜前記第Ｎの処理各々を完了する第１-１時刻〜第１-Ｎ時刻と、前記第２のデータを、前記第１処理ステップ〜前記第Ｎ処理ステップ各々において、前記第１の処理〜前記第Ｎの処理各々を開始する第２-１時刻〜第２-Ｎ時刻とを推定する推定ステップと、
前記第１-１時刻と前記第２-１時刻との関係〜前記第１-Ｎ時刻と前記第２-Ｎ時刻との関係各々が所定の関係を満たす場合、前記第２の指示を行い、満たさない場合には前記第２の指示を行わないように前記バッファステップを制御する制御ステップと、
を備えるサーバ制御方法。
【請求項１９】
少なくとも第１データ及び第２データを記憶し、第１の指示に応じて前記第１データを出力し、第２の指示に応じて前記第２データを出力するバッファ機能と、
前記バッファ機能で出力した第１及び第２データに対して、それぞれ第１の処理〜第Ｎ（Ｎは、２以上の整数）の処理を第１の処理〜第Ｎの処理の順番で処理を行う第１処理機能〜第Ｎ処理機能と、
前記第１の指示に応じて前記バッファ機能で前記第１データを出力した後、前記第１処理機能〜前記第Ｎ処理機能各々において、前記第１の処理〜前記第Ｎの処理各々を完了する第１-１時刻〜第１-Ｎ時刻と、前記第２のデータを、前記第１処理機能〜前記第Ｎ処理機能各々において、前記第１の処理〜前記第Ｎの処理各々を開始する第２-１時刻〜第２-Ｎ時刻とを推定する推定機能と、
前記第１-１時刻と前記第２-１時刻との関係〜前記第１-Ｎ時刻と前記第２-Ｎ時刻との関係各々が所定の関係を満たす場合、前記第２の指示を行い、満たさない場合には前記第２の指示を行わないように前記バッファ機能を制御する制御機能と、
を備えるサーバ制御プログラム。
【請求項１】
少なくとも第１データ及び第２データを記憶し、第１の指示に応じて前記第１データを出力し、第２の指示に応じて前記第２データを出力するバッファと、
前記バッファが出力した第１及び第２データに対して、それぞれ第１の処理〜第Ｎ（Ｎは、２以上の整数）の処理を第１の処理〜第Ｎの処理の順番で処理を行う第１処理部〜第Ｎ処理部と、
前記第１の指示に応じて前記バッファが前記第１データを出力した後、前記第１処理部〜前記第Ｎ処理部各々において、前記第１の処理〜前記第Ｎの処理各々を完了する第１-１時刻〜第１-Ｎ時刻と、前記第２のデータを、前記第１処理部〜前記第Ｎ処理部各々において、前記第１の処理〜前記第Ｎの処理各々を開始する第２-１時刻〜第２-Ｎ時刻とを推定する推定部と、
前記第１-１時刻と前記第２-１時刻との関係〜前記第１-N時刻と前記第２-Ｎ時刻との関係各々が所定の関係を満たす場合、前記第２の指示を行い、満たさない場合には前記第２の指示を行わないように前記バッファを制御する制御部と、
を備えるサーバ。
【請求項２】
前記第1処理部〜前記第N処理部は、前記第1データに対して、第ｍ処理部が第ｍの処理（ｍ＝１〜Nいずれかの整数）を実行するタイミングと重複するタイミングで、前記第2データに対して、第ｎ処理部（n＝m−１以下の整数）が、第ｎの処理を実行できる請求項１記載のサーバ。
【請求項３】
前記所定の関係は、前記第１-１時刻と前記第２-１時刻との差〜前記第１-N時刻と前記第２-N時刻との差各々が、所定の閾値以下である請求項２記載のサーバ。
【請求項４】
前記所定の閾値は、前記第1-1時刻と前記第2-1時刻との差〜前記第1-N時刻と前記第2-N時刻との差各々のうち最も大きな値が、正であって、かつもっとも０に近い値となる値である請求項３記載のサーバ。
【請求項５】
前記推定部は、第１時点で推定した、前記第１-１時刻〜前記第１-Ｎ時刻及び前記第２-１時刻〜前記第２-Ｎ時刻に関して、前記第１-１時刻と前記第２-１時刻との関係〜前記第１-Ｎ時刻と前記第２-Ｎ時刻との関係各々が所定の関係を満たさない場合には、前記第１時点以後の第２時点に、再度、前記第１-１時刻〜前記第Ｎ-１時刻と前記第２-１時刻〜前記第２-Ｎ時刻とを推定し、
前記制御部は、前記第２時点に推定した前記第１-１時刻〜前記第１-Ｎ時刻及び前記第２-１時刻〜前記第２-Ｎ時刻に関して、前記第１-１時刻と前記第２-１時刻との関係〜前記第１-Ｎ時刻と前記第２-Ｎ時刻との関係各々が所定の関係を満たす場合、前記第２の指示を行い、満たさない場合には前記第２の指示を行わない請求項３記載のサーバ。
【請求項６】
前記第2時点と前記第1時点との差がTである場合、
前記所定の閾値はT/2である
請求項５記載のサーバ。
【請求項７】
前記推定部は、前記第１-１時刻〜前記第１-Ｎ時刻と、前記第２-１時刻〜前記第２-Ｎ時刻とを、所定の周期Ｔ毎に推定し、
前記所定の閾値は、Ｔ／２以下である請求項３記載のサーバ。
【請求項８】
前記所定の閾値は、０以下である請求項３記載のサーバ。
【請求項９】
前記第２データは、前記バッファが前記第１データを出力以後に記憶したデータである請求項２記載のサーバ。
【請求項１０】
前記第２-１時刻〜前記第２-Ｎ時刻は、前記第２データに基づき、推定する請求項９記載のサーバ。
【請求項１１】
前記第１データ及び前記第２データは、ネットワークを介して接続されたクライアント端末が表示する画面情報を更新する情報である請求項２記載のサーバ。
【請求項１２】
前記第１〜前記第Ｎ処理部は、圧縮処理部と送信処理部を含む請求項１記載のサーバ。
【請求項１３】
前記クライアント端末は、前記第Ｎの処理を行った前記第１データ及び前記第２データに対して、第Ｎ＋１の処理を行う第Ｎ＋１処理部を有し、
前記推定部は、前記第１データを、前記第Ｎ＋１処理部が、前記第Ｎ＋１の処理を完了する第１-(Ｎ＋１)時刻と、前記第２データを、前記第Ｎ＋１の処理部が、前記第Ｎ＋１の処理を開始する第２-(Ｎ＋１)時刻とを推定し、
前記制御部は、更に、前記第１-(Ｎ＋１)時刻と前記第２-(Ｎ＋１)との差が、前記所定の閾値以下である場合に、前記バッファに対して前記第2データを出力する指示を行い、前記所定の閾値より大きい場合に、前記バッファに対して前記第2データを出力する指示を行わないように前記バッファを制御する請求項３記載のサーバ。
【請求項１４】
前記第Ｎ＋１の処理部は、伸長処理部であり、前記第Ｎ＋１の処理は、前記圧縮処理で圧縮された前記第１データ及び前記第２データに対して伸長する伸長処理である請求項１３記載のサーバ。
【請求項１５】
前記推定部は、前記バッファが前記第２データとして新たにデータを記憶したタイミングで、前記第１-１時刻〜前記第１-Ｎ時刻及び前記第2-１時刻〜前記第2-Ｎ時刻を推定する請求項９記載のサーバ。
【請求項１６】
前記推定部は、前記第2-１時刻〜前記第2-Ｎ時刻を推定する以前に、前記第１データに関して、前記第１-１時刻〜前記第１-Ｎ時刻いずれかを推定していた場合、前記第１-１時刻〜前記第１-Ｎ時刻を推定する際、以前推定した、前記第１-１時刻〜前記第１-Ｎ時刻を利用して推定する請求項１記載のサーバ。
【請求項１７】
前記推定部は、前記第１-１時刻〜前記第１-Ｎ時刻及び前記第2-１時刻〜前記第2-Ｎ時刻を推定する際、前記ネットワークの状態を考慮して推定する請求項１記載のサーバ。
【請求項１８】
少なくとも第１データ及び第２データを記憶し、第１の指示に応じて前記第１データを出力し、第２の指示に応じて前記第２データを出力するバッファステップと、
前記バッファステップで出力した第１及び第２データに対して、それぞれ第１の処理〜第Ｎ（Ｎは、２以上の整数）の処理を第１の処理〜第Ｎの処理の順番で処理を行う第１処理ステップ〜第Ｎ処理ステップと、
前記第１の指示に応じて前記バッファステップで前記第１データを出力した後、前記第１処理ステップ〜前記第Ｎ処理ステップ各々において、前記第１の処理〜前記第Ｎの処理各々を完了する第１-１時刻〜第１-Ｎ時刻と、前記第２のデータを、前記第１処理ステップ〜前記第Ｎ処理ステップ各々において、前記第１の処理〜前記第Ｎの処理各々を開始する第２-１時刻〜第２-Ｎ時刻とを推定する推定ステップと、
前記第１-１時刻と前記第２-１時刻との関係〜前記第１-Ｎ時刻と前記第２-Ｎ時刻との関係各々が所定の関係を満たす場合、前記第２の指示を行い、満たさない場合には前記第２の指示を行わないように前記バッファステップを制御する制御ステップと、
を備えるサーバ制御方法。
【請求項１９】
少なくとも第１データ及び第２データを記憶し、第１の指示に応じて前記第１データを出力し、第２の指示に応じて前記第２データを出力するバッファ機能と、
前記バッファ機能で出力した第１及び第２データに対して、それぞれ第１の処理〜第Ｎ（Ｎは、２以上の整数）の処理を第１の処理〜第Ｎの処理の順番で処理を行う第１処理機能〜第Ｎ処理機能と、
前記第１の指示に応じて前記バッファ機能で前記第１データを出力した後、前記第１処理機能〜前記第Ｎ処理機能各々において、前記第１の処理〜前記第Ｎの処理各々を完了する第１-１時刻〜第１-Ｎ時刻と、前記第２のデータを、前記第１処理機能〜前記第Ｎ処理機能各々において、前記第１の処理〜前記第Ｎの処理各々を開始する第２-１時刻〜第２-Ｎ時刻とを推定する推定機能と、
前記第１-１時刻と前記第２-１時刻との関係〜前記第１-Ｎ時刻と前記第２-Ｎ時刻との関係各々が所定の関係を満たす場合、前記第２の指示を行い、満たさない場合には前記第２の指示を行わないように前記バッファ機能を制御する制御機能と、
を備えるサーバ制御プログラム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【公開番号】特開２０１３−２６９３１（Ｐ２０１３−２６９３１Ａ）
【公開日】平成２５年２月４日（２０１３．２．４）
【国際特許分類】
【出願番号】特願２０１１−１６１４０６（Ｐ２０１１−１６１４０６）
【出願日】平成２３年７月２２日（２０１１．７．２２）
【出願人】（０００００３０７８）株式会社東芝 (54,554)
【Ｆターム（参考）】
【公開日】平成２５年２月４日（２０１３．２．４）
【国際特許分類】
【出願日】平成２３年７月２２日（２０１１．７．２２）
【出願人】（０００００３０７８）株式会社東芝 (54,554)
【Ｆターム（参考）】
[ Back to top ]