WO2011036733A1

WO2011036733A1 - サーバ装置、及び画面転送システム

Info

Publication number: WO2011036733A1
Application number: PCT/JP2009/004922
Authority: WO
Inventors: 谷澤佳道; 川添博史; 後藤真孝
Original assignee: 株式会社東芝
Priority date: 2009-09-28
Filing date: 2009-09-28
Publication date: 2011-03-31

Abstract

　サーバ装置１００は、ネットワーク３００を介してクライアント装置２００から入力データを受信し、入力データに対する応答画面の描画命令をクライアント装置２００に送信する。サーバ装置１００の欠損通知受信部１１１は、クライアント装置２００において描画命令の受信に欠損が生じたことを検知する。画面共有品質予測部１０８は、欠損に対して描画命令を再送信する場合に、クライアント装置で描画の破綻が生じるか否かを判定する。描画の破綻が生じると判定した場合に、再構築部１０７によって描画が破綻しないするように描画命令を再構築し、描画命令送信部１０４は再構築した描画命令をクライアント装置２００に送信する。

Description

サーバ装置、及び画面転送システム

　本発明は、サーバ装置、及び画面転送システムに関する。

　画面転送システムとは、サーバ装置がネットワークを介して接続されたクライアント装置に対して、画面を送信するシステムである。このシステムでは、利用者がクライアント装置を操作して、ネットワークを介してサーバ装置にアクセスし、サーバ装置の機能を利用することができる。

　まず利用者は、マウス、キーボード、タッチペン、タッチスクリーン等の入力インタフェースを用いてクライアント装置に情報を入力する。クライアント装置は、その入力情報をサーバ装置に対して送信する。サーバ装置は、クライアント装置から入力情報を受信すると、その入力情報に従ってサーバ装置上のアプリケーション処理を実行する。アプリケーション処理の結果、ディスプレイ描画情報が生成されると、サーバ装置はその描画情報をクライアント装置に送信する。クライアント装置は、描画情報を受信すると、ディスプレイ装置等に表示し、利用者に新しい画面情報を伝える。

　画面転送システムでは、クライアント装置とサーバ装置がネットワークを介して通信する。そのため、ネットワークの帯域幅が少ない場合や、パケットロスや通信障害、輻輳などが発生すると、クライアント装置への描画情報が遅延あるいは欠損することがある。

　上記の問題を解決するために、サーバ装置においてネットワーックの状況やＣＰＵ負荷などに応じて送信データを間引くことで、ネットワークの負荷を下げ、通信遅延を抑制する技術が発明されている。（例えば、特許文献１参照。）

特開２０００－５７０９４号公報

　しかしながら、特許文献１のように、サーバ装置において送信データを間引くと、クライアント装置への描画情報の品質が悪化するという課題があった。

　本発明の目的は、クライアント装置への画面情報を遅延や欠損なく送信することができるサーバ装置、及び画面転送システムを提供することを目的とする。

　上記目的を達成するために、本発明のサーバ装置は、クライアント装置からネットワークを介して入力データを受信し、前記入力データに対する応答画面の描画命令を前記ネットワークを介して前記クライアント装置に送信するサーバ装置であって、　前記クライアント装置へ送信した前記描画命令を記憶する履歴記憶部と、前記クライアント装置から送信された前記描画命令に欠損が生じたことを通知する通知データを受信する受信部と、前記通知データに応じて前記履歴記憶部から抽出した前記描画命令を再送信することによって前記クライアント装置で描画の破綻が生じるか否かを予測する第１の予測部と、前記第１の予測部によって描画の破綻が生じると予測した場合に、前記履歴記憶部に記憶された描画命令と前記通知データとから描画の破綻が生じないように描画命令を再構築する再構築部と、前記再構築した描画命令を前記クライアント装置に送信する送信部とを備えることを特徴とする。

　本発明によれば、利用者に品質の悪化を意識させずに、クライアント装置における出力応答を遅延や欠損なく画面表示することができる。

（ａ）本発明の第１の実施形態に係るサーバ装置を示す図。（ｂ）同実施形態に係るクライアント装置を示す図。（ａ）同実施形態に係る描画命令のフォーマットの例を示す図。（ｂ）同実施形態に係る描画命令のフォーマットの例を示す図。（ａ）同実施形態に係るサーバ装置における画面更新生成時の処理のフローチャート。（ｂ）同実施形態に係るクライアント装置における描画命令受信時の処理のフローチャート。（ａ）同実施形態に係るサーバ装置における欠損通知受信時の処理のフローチャート。（ｂ）同実施形態に係る描画命令の履歴の例を示す図。同実施形態に係る描画命令の実行後の画面表示の推移を示す図。同実施形態に係るパケット欠損が生じた場合の描画命令の再構築を説明する図。本発明の第２の実施形態に係る画面転送システムの構成と当該画面転送システムにおけるデータの流れ。同実施形態に係るクライアント装置における処理のシーケンス図。（ａ）同実施形態に係るドラッグによるウィンドウ移動のイメージ図。（ｂ）同実施形態に係るウィンドウ移動の画面更新手順における矩形コピーのイメージ図。（ａ）同実施形態に係るウィンドウ移動の画面更新手順における背景画像描画のイメージ図。（ｂ）本発明の第３の実施形態に係る画面共有品質予測部における処理のフローチャート。（ａ）同実施形態に係る遅延状態の判定方法を説明する図。（ｂ）同実施形態に係る遅延値の計算方法の一例を説明する図。

　以下、図面を参照しながら本発明の実施形態について詳細に説明する。

（第１の実施形態）
　本実施形態に係る画面転送システムは、図１（ａ）に示すサーバ装置１００と、図１（ｂ）に示すクライアント装置２００とによって構成される。サーバ装置１００とクライアント装置２００は、ネットワーク３００に接続されている。

[サーバ装置１００]
　図１（ａ）に示すサーバ装置１００は、描画命令生成部１０１と、シーケンス番号付加部１０２と、エンコード部１０３と、送信部（以下、描画命令送信部という）１０４と、フレームバッファ１０５と、表示部１０６と、再構築部１０７と、予測部（以下、画面共有品質予測部という）１０８と、履歴記憶部１０９と、履歴取得部１１０と、受信部（以下、欠損通知受信部という）１１１とを備える。

　描画命令生成部１０１は、サーバ装置１００において実行されるＯＳ（Operating System：オペレーティングシステム）および各種アプリケーションの動作状態に応じて描画命令を生成する。描画命令とは、表示画面（デスクトップ）上に最新の描画状態を得るための命令のことである。直前の描画状態が記憶されたフレームバッファ１０５に対し描画命令を適用することにより、最新の描画状態を得ることができる。

　描画命令は、描画命令の種類を表す描画命令種別と、描画する内容の詳細を表わす描画データから構成される。図２（ａ）および図２（ｂ）に、描画命令の例を示す。

　図２（ａ）は、描画命令種別Ｂ１が「ＢＩＴＭＡＰ」の例を示している。この場合、描画データＢ２は、更新する領域の位置を表す領域情報Ｂ２１と、更新する領域の更新後の画像情報Ｂ２２からなる。画像情報Ｂ２２は、デスクトップの一部分に相当する矩形状のビットマップデータ（矩形の各画素における赤緑青３色の値など）である。領域情報Ｂ２１は、デスクトップ上における更新画像の表示位置を示す座標値である。

　図２（ｂ）は、描画命令種別Ｃ１が「ＣＯＰＹＲＥＣＴ」の例を示している。「ＣＯＰＹＲＥＣＴ」とは、フレームバッファ１０５における特定の矩形領域のビットマップデータを、別の位置にコピーすることを示す。この場合、描画データＣ２は、コピー先の領域情報Ｃ２１と、また、コピー元の領域情報Ｃ２２を含んでいる。

　描画命令生成部１０１は、フレームバッファ１０５に対し前記描画命令を適用した後、さらにシーケンス番号付加部１０２に描画命令を出力する。

　シーケンス番号付加部１０２は、シーケンス番号カウント値を格納するための記憶領域（図示せず）を有している。シーケンス番号付加部１０２は、描画命令生成部１０１もしくは再構築部１０７から描画命令を受け取るごとに、前記記憶領域に格納しているシーケンス番号カウント値をその描画命令に付加する。シーケンス番号付加部１０２は、シーケンス番号カウント値を付加するごとに、前記シーケンス番号カウント値を１つインクリメントする。シーケンス番号付加部１０２は、シーケンス番号カウント値を付加した描画命令をエンコード部１０３および履歴記憶部１０９に出力する。

　エンコード部１０３は、シーケンス番号付加部１０２から描画命令を受け取ると、その描画命令に画像圧縮などのエンコード処理を施す。その後、エンコード部１０３は、エンコードされた描画命令を描画命令送信部１０４に出力する。

　描画命令送信部１０４は、エンコードされた描画命令を、通信用のパケットに形成する。その後、描画命令送信部１０４は、生成したパケットをネットワーク３００に送出する。

　フレームバッファ１０５は、表示部１０６の表示画面全体の画面データを記憶する。フレームバッファ１０５は、描画命令生成部１０１から描画命令を受けると、その描画命令の描画命令種別と描画データに応じて、画面データを記憶する記憶領域に新たな画面データを上書する。フレームバッファ１０５の前記記憶領域に上書きされた画面データは、表示部１０６によって表示される。また、フレームバッファ１０５は、再構築部１０７から画面データの取得要求を受け取ると、指定された領域の最新の画面データを再構築部１０７に出力する。

　履歴記憶部１０９は、描画命令を記憶する。履歴記憶部１０９は、シーケンス番号付加部１０２から描画命令を受け取るごとに、シーケンス番号と描画命令とを対応させて記憶する。その結果、履歴記憶部１０９には所定期間の描画履歴が蓄積される。また、履歴記憶部１０９は、再構築部１０７、画面共有品質予測部１０８、履歴取得部１０９から蓄積している描画命令の取得要求を受け取ると、要求に対応する描画命令をそれぞれのユニットへ出力する。

　履歴取得部１１０は、欠損通知受信部１１１からパケットの欠損通知を受け取ると、欠損通知に含まれるシーケンス番号に対応する描画命令を履歴記憶部１０９から取得する。その後、履歴取得部１１０は、画面共有品質予測部１０８にシーケンス番号及び描画命令を出力する。

　画面共有品質予測部１０８は、履歴取得部１１０から描画命令を受け取ると、当該描画命令以降に記録された描画命令を履歴記憶部１０９から取得する。そしてこれらの描画命令をもとにして、クライアント装置２００に対し再送信の処置を行う場合に、クライアント装置２００において描画の破綻が生じるか否かを予測する。画面共有品質予測部１０８は、予測結果と、取得した描画命令、および履歴記憶部１０９から取得した履歴情報の組み合わせを再構築部１０７に出力する。

　再構築部１０７は、画面共有品質予測部１０８から予測結果、描画命令、および履歴情報の組み合わせを受け取ると、予測結果の内容を確認する。予測結果がクライアント装置２００における描画の破綻を示す内容であった場合に、再構築部１０７は、破綻が生じないように再送しようとする描画命令の再構築を行う。再構築部１０７は、再構築した描画命令をシーケンス番号付加部１０２に出力する。

　表示部１０６は、フレームバッファ１０５に格納されている画面データを表示する。欠損通知受信部１１１は、ネットワーク３００を介して欠損通知を受信すると、これを履歴取得部１１０に出力する。

［クライアント装置２００］
　図１（ｂ）に示すクライアント装置２００は、受信部（以下、描画命令受信部という）２０１と、検知部（以下、欠損検知部という）２０２と、デコード部２０３と、描画実行部２０４と、フレームバッファ２０５と、表示部２０６と、送信部（以下、欠損通知送信部という）２０７とを備える。

　描画命令受信部２０１は、ネットワーク３００を介して描画命令を受信する。欠損検知部２０２は、シーケンス番号カウント値を格納するための記憶領域（図示せず）を有している。欠損検知部２０２は、描画命令受信部２０１から描画命令を受け取ると、その描画命令に付加されたシーケンス番号を記憶し、受信した描画命令の描画データに欠損が生じているか否かを検知する。欠損検知部２０２は、欠損を検知した場合には、欠損したシーケンス番号を欠損通知送信部２０７に出力する。また、欠損したシーケンス番号とともに当該描画命令をデコード部２０３に出力する。一方、欠損を検知しなかった場合には、欠損通知送信部２０７には何も通知せず、欠損検知部２０２は当該描画命令をデコード部２０３に出力する。

　デコード部２０３は、描画命令を受け取ると、その描画命令にデコード処理を施す。その後、デコードされた描画命令を描画実行部２０４に出力する。

　描画実行部２０４は、デコード後の描画命令を受け取ると、その描画命令に含まれる描画命令種別と描画データに応じて、フレームバッファ２０５の画面データに新たな画面データを上書きする。

　フレームバッファ２０５は、表示部２０６の表示画面全体の画面データを記憶する。表示部２０６は、フレームバッファ２０５に格納されている画面データを表示する。欠損通知送信部２０７は、欠損検知部２０２からシーケンス番号を受け取ると、これをパケット化する。その後、欠損通知として当該パケットをネットワーク３００を介してサーバ装置１００に送出する。

［画面転送システムにおける処理の流れ］
　以下に、本実施形態に係る画面転送システムの動作を説明する。本実施形態における画面転送システムでは、サーバ装置１００とクライアント装置２００がネットワーク３００を介して接続されている。サーバ装置１００とクライアント装置２００の間は、ネットワーク接続が完了して画面転送を実施している状態にあるものとする。

（１）画面更新処理（サーバ装置１００）
　図３（ａ）は、サーバ装置１００の画面更新処理のフローチャートである。図１（ａ）及び図３（ａ）を参照しながら、サーバ装置１００における画面更新の処理を説明する。

　画面転送を実施している状態にあるとき、描画命令生成部１０１は、サーバ装置１００において実行されるＯＳおよび各種アプリケーションの動作状態の変化により、クライアント装置２００へ提示する視覚的情報に更新があるかどうかをチェックする（ステップＳ１０１）。

　画面更新がある場合は（ステップＳ１０１のＹＥＳ）、描画命令生成部１０１は、描画命令の生成を行う（ステップＳ１０２）。描画命令生成部１０１は、更新の前後の視覚的情報の差分を任意の方法で抽出することで、上述したような「ＢＩＴＭＡＰ」や「ＣＯＰＹＲＥＣＴ」などの種別の描画命令を生成する。あるいは別の方法として、描画命令生成部１０１は、ＯＳが発行する描画命令を直接フックすることにより、描画命令を得てもよい。

　描画命令生成部１０１は、生成した描画命令をフレームバッファ１０５に入力する。フレームバッファ１０５は、内部の記憶領域のうち、描画命令の領域情報に示す領域に描画命令の描画データ（新たな画面データ）を上書する。表示部１０６は、フレームバッファ１０５に記憶された画面データを表示する。また、描画命令生成部１０１は、生成した描画命令をシーケンス番号付加部１０２に出力する。その後、処理の流れはステップＳ１０３に進む。

　描画命令を受け取ると、シーケンス番号付加部１０２は、内部のシーケンス番号記憶領域に格納しているシーケンス番号カウント値を参照する。シーケンス番号付加部１０２は、このシーケンス番号カウント値をシーケンス番号として、受信した描画命令に付加する（ステップＳ１０３）。

　シーケンス番号付加部１０２では、画面転送の開始の際にシーケンス番号カウント値をゼロにリセットする。その後は、ステップＳ１０３の処理でシーケンス番号の付加を行うごとに、シーケンス番号カウント値を１ずつインクリメントする。シーケンス番号カウント値が規定値（例えば、２の３２乗－１）を超えたら、再びゼロにリセットする。その後、処理の流れはステップＳ１０４に進む。

　シーケンス番号付加部１０２は、描画命令とシーケンス番号の対を履歴記憶部１０９に出力する。履歴記憶部１０９は、内部の記憶領域に描画命令とシーケンス番号の対を描画履歴として記憶する（ステップＳ１０４）。

　シーケンス番号付加部１０２は、履歴記憶部１０９から記憶が完了した通知を受け取ると、シーケンス番号が付加された描画命令をエンコード部１０３に出力する。

　図４（ｂ）は、履歴記憶部１０９に記憶される描画履歴の一例である。履歴記憶部１０９は、描画命令のすべての情報を記憶する必要はない。本実施形態では、シーケンス番号と、それに対応する描画命令種別（「ＣＯＰＹＲＥＣＴ」、「ＢＩＴＭＡＰ」など）とを記憶する。描画命令種別が「ＣＯＰＹＲＥＣＴ」の場合は、さらに、領域情報Ｃ２１とコピー元の領域情報Ｃ２２を記憶する。また、描画命令種別が「ＢＩＴＭＡＰ」の場合は、領域情報Ｂ２１のみが記憶される。すなわち、「ＢＩＴＭＡＰ」の場合は、画像情報Ｂ２２のビットマップデータは記憶されない。

　エンコード部１０３は、描画命令を受け取ると、描画命令種別が「ＢＩＴＭＡＰ」の場合には画像情報に対しエンコード処理を施す。エンコード部１０３はビットマップデータに対して、例えばＪＰＥＧ（Joint Photographic Experts Group）やｇｚｉｐ（GNU ZIP）などの任意のアルゴリズムによる圧縮を行う。次に、エンコード部１０３は、エンコード後の描画命令を描画命令送信部１０４に出力する。

　描画命令送信部１０４は、描画命令にＵＤＰ（User Datagram Protocol）ヘッダやＩＰ（Internet Protocol）ヘッダを付与するなど、通信用の描画命令パケットに変換する。その後、描画命令送信部１０４は、描画命令パケットをネットワーク３００に送出する。

（２）描画命令パケットの受信時（クライアント装置２００）
　次に、図１（ｂ）及び図３（ｂ）を参照しながら、クライアント装置２００における描画命令パケット受信時の動作を説明する。図３（ｂ）は、クライアント装置２００における描画命令パケット受信時のフローチャートである。

　まず、描画命令受信部２０１は、ネットワーク３００から描画命令パケットを受信すると、そのパケットからＵＤＰヘッダやＩＰヘッダを除外し、描画命令を取り出す（ステップＳ３０１）。その後、描画命令受信部２０１は、取り出した描画命令を欠損検知部２０２に出力する。

　欠損検知部２０２は、描画命令受信部２０１から描画命令を受け取ると、描画命令中のシーケンス番号を取り出す。その後、欠損検知部２０２は、取得したシーケンス番号と、内部のシーケンス番号カウント値記憶領域（図示せず）に記憶しているシーケンス番号カウント値とを比較し、両者が一致するか否かを調べる（ステップＳ３０２）。

　両者の比較結果は、以下の３つのケースに分けられる。第１のケースは、「描画命令中のシーケンス番号とシーケンス番号カウント値が一致する場合（＝）」である。第２のケースは、「描画命令中のシーケンス番号とシーケンス番号カウント値が一致せず、かつ、描画命令中のシーケンス番号がシーケンス番号カウント値よりも大きい場合（＞）」である。第３のケースは、「描画命令中のシーケンス番号とシーケンス番号カウント値が一致せず、かつ、描画命令中のシーケンス番号がシーケンス番号カウント値よりも小さい場合（＜）」である。

　まず、第１のケースの場合では、欠損検知部２０２は、欠損は生じていないと判定する。そして、欠損検知部２０２は、受信した描画命令をデコード部２０３に出力する。その後、処理の流れはステップＳ３０５に進む。

　デコード部２０３は描画命令を受信すると、その描画命令にエンコード処理が施されている場合には対応するデコード処理を施す。その後、デコードした描画命令を描画実行部２０４に出力する。

　描画実行部２０４は、描画命令に従って描画命令中の画面データをフレームバッファ２０５に記憶する。その後、表示部２０６がフレームバッファ２０５から記憶された画面データを取り出し、画面に表示する（ステップＳ３０５）。

　次に、第２のケースの場合では、欠損検知部２０２は、欠損が生じたと判定する。例えば、内部で保有するシーケンス番号カウント値が「１００」で、描画命令中のシーケンス番号が「１０３」であったとすると、欠損検知部２０２は、シーケンス番号「１００」，「１０１」，「１０２」に相当する描画命令パケットに欠損が生じたと判定する。

　そして、欠損検知部２０２は、欠損が生じた描画命令パケットのシーケンス番号（上述の例では「１００」，「１０１」，「１０２」）を欠損通知送信部２０８に出力する。

　欠損通知送信部２０８は、欠損検知部２０２から通知されたシーケンス番号にＵＤＰヘッダやＩＰヘッダ等など通信に必要な情報を付加し、サーバ装置１００に欠損を通知する欠損通知パケットを形成する。その後、欠損通知送信部２０８は、欠損通知パケットを送信する（ステップＳ３０３）。

　欠損検知部２０２は、欠損通知パケットの送信が完了すると、描画命令受信部２０１より入力された描画命令と、欠損が生じた描画命令のシーケンス番号の組み合わせをデコード部２０３に出力する。その後、処理の流れはステップＳ３０５に進む。

　また、第３のケースの場合では、欠損検知部２０２は、以前に受信した描画命令を重複して受信したと判断する。そして、欠損検知部２０２は、受信した描画命令を破棄し、処理を終了する（ステップＳ３０４）。

　上記第１乃至第３のいずれのケースであっても、欠損検知部２０２では描画命令中のシーケンス番号とシーケンス番号カウント値とを比較した後、内部のシーケンス番号カウント値に描画命令中のシーケンス番号が上書きされ、更新される。

（３）欠損通知パケットの受信時（サーバ装置１００）
　図１（ａ）及び図４（ａ）を参照しながら、サーバ装置１００における欠損通知パケットの受信時の動作を説明する。図４（ａ）は、サーバ装置１００における欠損通知パケット受信時のフローチャートである。

　まず、欠損通知受信部１１１は、クライアント端末２００からの欠損通知パケットを受信すると、その欠損通知パケットに含まれる１つ又は複数のシーケンス番号を取り出す（ステップＳ２０１）。そして、そのシーケンス番号を、履歴取得部１１０に出力する。

　履歴取得部１１０はシーケンス番号を受け取ると、履歴記憶部１０９から当該シーケンス番号に対応する描画命令を取得する（ステップＳ２０２）。履歴記憶部１０９には、例えば図４（ｂ）に示すような描画命令の履歴が記憶されている。履歴記憶部１０９は要求されたシーケンス番号に対する履歴情報を出力する。履歴情報には、シーケンス番号に対応する描画命令種別、及び領域情報を少なくとも有する。

　履歴取得部１１０は、取得した描画命令の履歴情報を、画面共有品質予測部１０８に出力する。

　画面共有品質予測部１０８は、履歴情報を受け取ると、履歴記憶部１０９からシーケンス番号以降の描画命令の履歴情報をすべて取得する。次に、画面共有品質予測部１０８は、後述する予測ルーチンに従って欠損した描画命令の再送信を行った場合に、クライアント装置２００における画面状態に描画の破綻が生じるか否かを予測する。

　ここでは、説明を簡潔にするために、描画命令種別を「ＢＩＴＭＡＰ」と「ＣＯＰＹＲＥＣＴ」の２種類のみとする。また、欠損した描画命令Ｌの描画先の領域情報をＤ［Ｌ］と表す。描画命令種別が「ＣＯＰＹＲＥＣＴ」の場合、コピー元の領域をＳ［Ｌ］と表す。以上の表記を用いて、欠損した描画命令を、「ＢＩＴＭＡＰ：Ｄ［Ｌ］」または「ＣＯＰＹＲＥＣＴ：Ｓ［Ｌ］→Ｄ［Ｌ］」と表記する。さらに、当該描画命令以降ｉ番目に発生した描画命令の履歴を「ＢＩＴＭＡＰ：Ｄ［ｉ］」または「ＣＯＰＹＲＥＣＴ：Ｓ［ｉ］→Ｄ［ｉ］」と表記する。

　画面共有品質予測部１０８は、欠損した描画命令の再送信した場合にクライアント装置２００における画面状態に描画の破綻が生じるか否かを予測するために、以下の予測ルーチンを実行する（ステップＳ２０３）。以下において、「ＴＲＵＥ」は「描画の破綻が生じる」ことを意味し、「ＦＡＬＳＥ」は「描画の破綻が生じない」ことを意味する。

＜予測ルーチン＞
（１）ｉ：＝１
（２）ｉ番目の描画命令が存在しなければ「ＦＡＬＳＥ」を出力して終了
（３）ｉ番目の描画命令がＢＩＴＭＡＰなら（５）へ遷移
（４）Ｄ［Ｌ］とＳ［ｉ］が共通部分を持つ場合、「ＴＲＵＥ」を出力して終了
（５）Ｄ［Ｌ］とＤ［ｉ］が共通部分を持つ場合、「ＴＲＵＥ」を出力して終了
（６）欠損した描画命令ＬがＢＩＴＭＡＰなら（８）へ遷移
（７）Ｓ［Ｌ］とＤ［ｉ］が共通部分を持つ場合、「ＴＲＵＥ」を出力して終了
（８）ｉ：＝ｉ＋１　の後で（２）へ遷移
　画面共有品質予測部１０８は、＜予測ルーチン＞を実行することにより、クライアント装置２００における描画の破綻の有無を予測することができる。画面共有品質予測部１０８は、予測結果（「ＴＲＵＥ」または「ＦＡＬＳＥ」）と、欠損した描画命令とを再構築部１０７に出力する。

　再構築部１０７は、予測結果および欠損した描画命令が入力されると、予測結果を確認する。予測結果が「ＦＡＬＳＥ」の場合（ステップＳ２０４の“ＮＯ”）、欠損した描画命令の再送信を行ってもクライアント装置２００における画面状態に描画の破綻が生じない。このとき再構築部１０７は、描画命令が「ＢＩＴＭＡＰ」ならば、領域情報Ｂ２１に対応する最新のフレームバッファ１０５の描画データを取得する。取得した最新のフレームバッファ１０５の描画データをビットマップデータとした上で、欠損した描画命令をシーケンス番号付加部１０２に出力する（ステップＳ２０６）。

　一方、描画命令種別が「ＣＯＰＹＲＥＣＴ」ならば、再構築部１０７は、この描画命令をそのままシーケンス番号付加部１０２に出力する（ステップＳ２０６）。これ以降のシーケンス番号付加部１０２の動作は、前述の内容と同一である（ステップＳ２０７）。

　なお、このとき描画命令に付加されるシーケンス番号は、欠損したシーケンス番号ではなく、新規の番号が割り当てられる。

　一方、予測結果が「ＴＲＵＥ」の場合（ステップＳ２０４の“ＹＥＳ”）、欠損した描画命令の再送信を単純に行うと、クライアント装置２００における描画に破綻が生じてしまう。そこで再構築部１０７は、以下の再構築ルーチンに従って描画命令の再構築を行う（ステップＳ２０５）。

　まず、再構築部１０７は、欠損した描画命令以降に発生したすべての描画命令の履歴情報を履歴記憶部１０９から取得する。その後、以下の再構築ルーチンを実行する。当該描画命令以降ｉ番目に発生した描画命令の履歴情報を「ＢＩＴＭＡＰ：Ｄ［ｉ］」または「ＣＯＰＹＲＥＣＴ：Ｓ［ｉ］→Ｄ［ｉ］」と表記する。なお、以下において、ＢＩＴＭＡＰ描画命令に対してはＳ［ｉ］は空集合として扱う。ここで出力用リストとは、再構築部が破綻を予測する際に、描画命令を一時的に格納するリストであって、本ステップ（Ｓ２０５）
にて描画命令を格納し、後のステップ（Ｓ２０６およびＳ２０７）で参照される。

＜再構築ルーチン＞
（１）出力用リストにＬを追加する
（２）ｉ：＝１
（３）ｉ番目の描画命令が存在しなければ（９）へ遷移
（４）出力用リストのすべての要素Ａについて（５）～（７）を実行する
（５）Ｄ［Ａ］とＳ［ｉ］が共通部分を持つ場合、出力用リストの最後尾に　ＢＩＴＭＡＰ：Ｄ［ｉ］を追加する
（６）Ｄ［Ａ］とＤ［ｉ］が共通部分を持つ場合、Ａの描画領域、すなわちＤ［Ａ］をＤ［Ａ］－Ｄ［ｉ］で置き換える。ここでＤ［Ａ］－Ｄ［ｉ］とはＤ［Ａ］の領域からＤ［Ａ］とＤ［ｉ］の共通部分を除外した部分領域を指す
（７）Ｓ［Ａ］とＤ［ｉ］が共通部分を持つ場合、出力用リストの最後尾にＢＩＴＭＡＰ：Ｄ［ｉ］（Ｓ［Ａ］×Ｄ［ｉ］）を追加する。ここでＳ［Ａ］×Ｄ［ｉ］とはＳ［Ａ］とＤ［ｉ］領域の共通部分を指す。またＤ［ｉ］（Ｓ［Ａ］×Ｄ［ｉ］）とは、Ｓ［Ａ］とＤ［ｉ］領域の共通部分に対応するコピー先領域の部分を指す
（８）ｉ：＝ｉ＋１　の後で（３）へ遷移
（９）出力用リストが開始時と変化がなければ「ＴＲＵＥ」（破綻が生じる）、変化があれば「ＦＡＬＳＥ」（破綻が生じない）を出力する
　上記の再構築ルーチンの終了後、出力用リストに記された描画命令が、再構築後の描画命令となる。

　再構築部１０７は、当該出力用リスト内の描画命令を先頭から順にチェックしていく。再構築した描画命令が「ＢＩＴＭＡＰ」ならば、再構築部１０７は領域情報Ｂ２１に対応する最新のフレームバッファ１０５の描画データを取得する。取得した最新のフレームバッファ１０５の描画データをビットマップデータ（画像情報Ｂ２２）とした上で、再構築した描画命令をシーケンス番号付加部１０２に出力する（ステップＳ２０６）。

［再構築の具体例１］
　上記で説明した画面共有品質予測部１０８と再構築部１０７の動作について、具体例を用いて以下に説明する。図４（ｂ）は、ある時間内に発生した一連の描画命令の履歴情報の例を示す。

　デスクトップにおいてウィンドウをいったん描画した後、ウィンドウ位置が右下方向に移動した状況を想定する。図４（ｂ）の例では、４個の描画命令が、「ＢＩＴＭＡＰ」→「ＣＯＰＹＲＥＣＴ」→「ＢＩＴＭＡＰ」→「ＢＩＴＭＡＰ」の順に発生したとしている。

　この一連の描画命令の実行結果を描画命令毎に表すと、図５（ａ）乃至（ｅ）のようになる。すなわち、サーバ装置１００が送信したこれらの描画命令が、１つも欠損なくクライアント装置２００で受信されると、図５（ａ）乃至（ｅ）と同じ工程で作成された画面データがクライアント装置２００の表示部２００６に表示される。

　以上の一連の描画命令において、シーケンス番号１の描画命令が伝送途中に欠損した場合の画面共有品質予測部１０８と再構築部１０７の動作を、図６を用いて説明する。

　例えば、シーケンス番号１が欠損した場合、クライアント装置２００は、はじめにシーケンス番号２の描画命令を受信することになる。このとき、クライアント装置２００の欠損検知部２０２は、シーケンス番号１の欠損を検知する。その後、欠損通知送信部２０７とサーバ装置１００の欠損通知受信部１１１を通じて、サーバ装置１００の履歴取得部１１０にシーケンス番号１の欠損を通知する。

　サーバ装置１００の履歴取得部１１０は、シーケンス番号１に対応する履歴情報としてＢＩＴＭＡＰ：（７０，７０，３５０，２８０）を取得すると、これを画面共有品質予測部１０８に渡す。

　画面共有品質予測部１０８は、履歴記憶部１０９から、シーケンス番号１以降のシーケンス番号２，シーケンス番号３，シーケンス番号４の描画命令の履歴情報を取得すると、上述の＜予測ルーチン＞を用いてクライアント装置２００における描画に破綻が生じるか否かを予測する。図６の例では、シーケンス番号１の描画領域（７０，７０，３５０，２８０）と、シーケンス番号２のコピー元領域（７０，７０，３５０，２８０）とは共通部分を持つため、予測ルーチンの結果は「ＴＲＵＥ」（破綻が生じる）となる。

　次に、再構築部１０７は、歴記憶部１０９からの予測結果を受けて、描画命令の再構築を行う。上述の＜再構築ルーチン＞を用いて、描画に破綻が生じないような描画命令を構成することが可能である。ルーチンの細かな実行の様子は説明を省略する。図６の例では、＜再構築ルーチン＞を実行した結果、再構築後の描画命令はＢＩＴＭＡＰ：（２８０，２１０，５６０，４２０）となる。

　再構築部１０７は、この領域に対応する最新のフレームバッファ１０５の描画データを取得し、これをビットマップデータとした上で、この描画命令をシーケンス番号付加部１０２に出力する。シーケンス番号付加部１０２は、この描画命令に新たなシーケンス番号５を付加して（図６（ａ）参照）、ネットワーク３００を介してクライアント端末２００に送信する。

［再構築の具体例２］
　次に、前記シーケンス番号２の描画命令が欠損した場合の再構築の例を、図６を用いて以下に説明する。

　シーケンス番号２の描画命令が伝送途中に欠損した場合、クライアント装置２００は、シーケンス番号１、３の順に描画命令を受信することになる。従って、欠損検知部２０２は、シーケンス番号カウンタ値に基づいて、シーケンス番号２の欠損を検知する。欠損検知部２０２は、欠損通知送信部２０７、ネットワーク３００、サーバ装置１００の欠損通知受信部１１１を通じて、サーバ装置１００の履歴取得部１１０にシーケンス番号２の欠損を通知する。

　履歴取得部１１０は、シーケンス番号２に対応する履歴として、履歴記憶部１０９から描画命令「ＣＯＰＹＲＥＣＴ：（７０，７０，３５０，２８０）→（２８０，２１０，５６０，４２０）」を取得する。履歴取得部１１０は、取得した描画命令を画面共有品質予測部１０８に渡す。

　画面共有品質予測部１０８は、履歴記憶部１０９からシーケンス番号２以降のシーケンス番号３，及びシーケンス番号４の描画命令の履歴情報を取得する。その後、上述の＜予測ルーチン＞を用いて、クライアント装置２００において描画に破綻が生じるか否かを予測する。図６の例では、シーケンス番号２のコピー元領域（７０，７０，３５０，２８０）と、シーケンス番号３の描画領域（７０，７０，３５０，２１０）とは共通部分を持つため、予測ルーチンの結果は「ＴＲＵＥ」となる。

　次に、再構築部１０７は、上述の＜再構築ルーチン＞を用いて、描画命令の再構築を行う。再構築ルーチンを実行した結果、再構築後の描画命令として出力用リストには、「ＣＯＰＹＲＥＣＴ：（７０，７０，３５０，２８０）→（２８０，２１０，５６０，４２０）」、「ＢＩＴＭＡＰ：（２８０，２１０，５６０，３５０）」、「ＢＩＴＭＡＰ：（２８０，３５０，４９０，４２０）」の３個が得られる。

　再構築部１０７は、この出力用リスト内の描画命令について、先頭から順番に、「ＢＩＴＭＡＰ」の描画命令であれば領域に対応する最新のフレームバッファの描画データを取得した後で、シーケンス番号付加部１０２に出力する。シーケンス番号付加部１０２は、この描画命令に新たなシーケンス番号５，６，７を付加して送信する（図６（ｂ），（ｃ），（ｄ）参照）。

　以上の手順によって得られる再構築後の描画命令により、クライアント装置２００において描画の破綻が回避され、欠損が生じない場合と同一のデスクトップ状態が得られる。

　なお、本実施形態に記載した＜予測ルーチン＞および＜再構築ルーチン＞は、あくまでも動作のための一例にすぎない。クライアント装置２００における描画の破綻が回避できるならば、これ以外の任意のルーチンを用いても良い。

　また、今回は描画命令種別を「ＢＩＴＭＡＰ」と「ＣＯＰＹＲＥＣＴ」の２種類のみに限って説明したが、これ以外の種類の描画命令が混在した環境であっても、同じようにルーチンを構成することが可能である。例えば、デスクトップ上の矩形領域を対象に描画処理を行う任意の描画命令は、「ＢＩＴＭＡＰ」の場合と同様にルーチンを構成することができる。

　以上のように、本実施形態におけるサーバ装置１００は、過去に送出した描画命令の履歴を参照することで、クライアント装置２００における描画の破綻を予測することができる。また、クライアント装置２００において描画が破綻すると予測された場合には、サーバ装置１００が描画命令に再構築を施すことで、クライアント装置２００における描画の破綻を回避することができる。これにより、利用者に品質の悪化を意識させずに、クライアント装置２００における出力応答を遅延や欠損なく画面表示することができる。

　また、本実施形態のサーバ装置１００は、破綻の回避に必要な最小限の描画命令のみを構成して送信する。従って、例えばデスクトップ全体の最新の描画状態を取得して送出するといった場合と比べて、サーバ装置１００におけるエンコードや送信の処理負荷が低減される。また、ネットワーク帯域の消費量も少なくて済むという利点がある。

　さらに、本実施形態のクライアント装置２００は、描画命令の受信に欠損を検知したとき、その欠損通知に対する応答を待つことなく、以降に受信した描画命令を用いて、引き続き描画実行する。従って、例えば伝送プロトコルにＴＣＰ（Transmission Control Protocol）を用いた画面転送システムのように、欠損が生ずると以降の描画を中断してサーバ装置からの再送信を待機するという場合と比べて、サーバ装置１００で実行された描画がすみやかにクライアント装置２００において反映されるというリアルタイム性を確保できる利点がある。

(第２の実施形態)
　前述した第１の実施形態では、画面共有品質予測部１０８と再構築部１０７を画面転送システムのサーバ装置１００に備える構成としたが、第２の実施形態では、クライアント装置２００に備える構成とする。図７は、第２の実施形態に係る画面転送システムの構成を示す図である。

　本実施形態に係る画面転送システムは、図７に示すサーバ装置１０００とクライアント装置２０００とによって構成される。図７はまた、画面転送システムにおけるデータの流れを矢印によって示している。破線の矢印は通常（比較例）のデータの流れを示し、実線の矢印は本実施例特有のデータの流れを示す。以下に例として、クライアント装置２０００の画面に表示されたウィンドウをドラッグにより移動させる場合を説明する。

　まず、通常（比較例）のデータの流れを説明する。比較例となる通常の画面転送システムでは、クライアント装置２０００の利用者が、ペン、マウスなどで入力するポインタ入力や、キーボードなどで入力したキー入力を、入力部２００１が受け付ける。クライアント装置２０００は、そのポインタ入力やキー入力といった入力データを、通信部２００２、ネットワーク３００を介して、サーバ装置１０００に送信する。

　サーバ装置１０００の通信部１００１は、入力データを受信する。その後、入力データを入力処理部１００２へ渡す。入力処理部１００２は、入力データをアプリケーション／ＯＳ１００３に渡す。ＯＳやアプリケーションでは、入力データに応じたプログラム実行が行なわれ、画面に処理結果を示す出力表示データが表示される。（処理内容によっては、画面に出力表示されないこともある。)画面への出力表示データは、アプリケーション／ＯＳ１００３から画面の描画命令として、描画転送部１００４に出力される。描画転送部１００４は、当該描画命令を、通信部１００１、ネットワーク３００を通じてクライアント装置２０００に送信する。

　クライアント装置２０００の通信部２００２は、サーバ装置１０００からの描画命令を受信する。その後、表示部２００３において描画命令が実行され、画面に出力表示データが表示される。

　一方、本実施形態では、クライアント装置２０００において、入力部２００１からのポインタ入力と、通信部２００２からの矩形コピー描画命令（詳細は後述する）をトリガとして、画面共有品質予測部２００４が起動される。そして、予測部（以下、画面共有品質予測部という）２００４は、クライアント装置２０００における出力表示に欠損が発生するであろうと予測する。何故ならば、ドラッグによる矩形コピーは、多量の画面更新データを発生させる操作であるので、多量の通信を誘発する可能性がある。これにより、パケットの欠損による描画の破綻、操作性悪化などを引き起こす可能性が高いためである。

　上記の予測に基づき、画面共有品質予測部２００４は、以後、入力されたポインタ入力をサーバ装置１０００へ転送しないように、遮断部（以下、転送遮断部という）２００６に指令する。転送遮断部２００６は、画面共有品質予測部２００４からの指令を受け取ると、入力部２００１から受け取ったポインタ入力のデータをそのまま破棄する。

　また、画面共有品質予測部２００４は、構築部（以下、再構築部という）２００５に対し描画命令の再構築を指令する。その指令を受け取ると、再構築部２００５はポインタ入力を画面の矩形コピー描画命令に再構築し、表示部２００３へ渡す。その後、表示部２００３において矩形コピー描画命令が実行され、画面に出力が表示される。

　以降、クライアント装置２０００において、入力部２００１から連続してポインタ入力される場合、再構築部２００５はドラッグの移動に応じて矩形コピー描画命令を再構築し、表示部２００３へ渡す。

　入力部２００１からポインタ入力がなくなった際には、画面共有品質予測部２００４は転送遮断部２００６と再構築部２００５にその旨を通知する。この通知により、転送遮断部２００６では入力データを破棄する動作を終了する。また、再構築部２００５は、矩形コピー描画命令の再構築を終了する。

　その後、転送遮断部２００６は、最後のドラッグ入力を通信部２００２を介してサーバ装置１０００に送信し、通常動作に戻る。

　上述した本実施形態の処理の流れを、図８を用いて具体的に説明する。図８は、クライアント装置２０００の動作を示す図である。

　まず、入力部２００１から、ポインタ入力TIP[x11,y11]が入力される。ここで、TIPとは、ペン入力におけるペンのタッチを意味し、座標 [x11, y11] にペンがタッチされたことを意味する。あるいは、マウスの場合には座標[x11, y11]にて左ボタンが押されたことを意味する。

　画面共有品質予測部２００４はポインタ入力を受け、ペンのタッチが開始されたことを検知する。そして、そのポインタ入力を転送遮断部２００６を介して通信部２００２へ渡す。

　次に、入力部２００１からポインタ入力TIP[x12,y12]が入力される。画面共有品質予測部２００４は、ペンがタッチされたまま座標が移動していることから、ドラッグが行なわれたことを検知する。そして、そのポインタ入力を転送遮断部２００６を介して通信部２００２へ渡す。

　その後、上述した処理によってサーバ装置１０００から、ウィンドウのドラッグによる画面更新データ３００１，３００２が送信されてくる。画面更新データ３００１は、矩形コピー描画命令である。画面更新データ３００２は、背景画像描画命令である。

　例えば、クライアント装置２０００にて、図９（ａ）に示すようなウィンドウの移動（ドラッグ）を行ったとする。例えば、ウィンドウのサイズは３２０×２００である。図９（ａ）に示すようなウィンドウの移動に対処するためには、図９（ｂ）に示す矩形コピーの処理と、その後に図１０（ａ）に示す背景画像描画の処理を実施する必要がある。そのため、サーバ装置１０００から矩形コピー描画命令３００１及び背景画像描画命令３００２の２つの画面更新データがクライアント装置２０００に送信されてくる。

　画面共有品質予測部２００４は、画面更新データを受信すると、入力されたポインタ入力[x12,y12]が、起点 [x22,y22]から３２０×２００ピクセルの矩形内に入っているかどうかを判定する。ここでは、矩形内に入っていると判定したものとして説明する。

　画面共有品質予測部２００４は、上記の矩形内に入っているとの判定に基づき、クライアント装置２０００における出力画面表示に欠損が発生するであろうと予測する。画面共有品質予測部２００４は、その予測に基づき転送遮断部２００６へ遮断開始の指令３００３を送る。

　転送遮断部２００６は、画面共有品質予測部２００４からの指令を受け取り、以後、受け取るデータの転送を停止する。

　一方、通信部２００６は、サーバ装置１０００から送られてきた画面更新データ３００１(矩形コピー [x21,y21](320x200)-[x22,y22])と、画面更新データ３００２(背景画像描画)を表示部２００３に送る。表示部２００３は、受け取った画面更新データの処理を実行し、表示を出力する。

　次に、入力部２００１から次のポインタ入力(TIP[x13,y13])が入力されると、画面共有品質予測部２００４は再構築部２００５に命令再構築の指令３００４を出す。

　再構築部２００５は、命令再構築の指令３００４を受信すると、直前のポインタ入力(TIP[x12,y12])と、画面更新データ３００１(矩形コピー [x21,y21](320x200)-[x22,y22])に基づき、x23 = x22 + x13 - x12, y23 = y22 + y13 - y12 として、画面更新データ３００５(矩形コピー [x22,y22](320x200)-[x23,y23])を生成する。そして、生成した画面更新データ３００５を表示部２００３に送る。表示部２００３は、画面更新データ３００５に従って表示処理を行う。

　一方、転送遮断部２００６は、ポインタ入力(TIP[x13,y13])を受け取るが、サーバ装置１０００には転送せずに、最新のポインタ入力として保持する。以降、入力部２００１から、次のポインタ入力(TIP[x14,y14])、次の次のポインタ入力(TIP[x18,y18])が入力された場合も同様の動作を行う。

　その後、入力部２００１から、次のポインタ入力３００６(unTIP[x19,y19])が入力される。unTIPは、ペンのタッチが離されたことを意味する。つまり、これまで行なわれていたドラッグ操作が、座標[x19,y19]で終了したことを意味する。

　従って、画面共有品質予測部２００４は、転送遮断部２００６へ遮断終了の指令３００７を送信する。転送遮断部２００６は、遮断終了の指令３００７を受信すると、最後のポインタ入力(unTIP[x19,y19])を通信部２００２を介してサーバ装置１０００へ転送する。

　サーバ装置１０００は、前回にクライアント装置２０００から受信したポインタ入力TIP[x12,y12]の実行状態から、今回クライアント装置２０００から受信したポインタ入力(unTIP[x19,y19])の実行状態に遷移するまでの処理を行う。その結果、出力される画面更新データ３００８、３００９をクライアント装置２０００へ送信する。

　クライアント装置２０００は、画面更新データ３００８、３００９を受信し、当該処理を実行する。以降、クライアント装置２０００は、本シーケンス開始時と同様の状態に戻る。

　以上のように、本実施形態におけるクライアント装置２０００は、ドラッグ操作により大量の画面更新データが発生すると予測した場合、ドラッグ操作に関するポインタ入力をサーバ装置１０００に送信せず、内部に保有する画像データを利用して出力画面を表示する。これにより、クライアント装置２０００とサーバ装置１０００間の通信量を少なく抑えることができ、ネットワークの混雑を抑制できる。その結果、クライアント装置２０００において、パケットの遅延や欠損による描画の破綻を回避することができる。

（第３の実施形態）
　第３の実施形態は、第２の実施形態と同様に、画面共有品質予測部１０８と再構築部１０７を画面転送システムのクライアント装置に備えるものである。

　本実施例では、ネットワーク品質が悪化して、クライアント装置における描画実行が遅延した場合、クライアント装置に表示されるマウスポインタカーソル（以下、カーソルという)の形状を、処理待ち中であることを示す「砂時計マーク」に変更する。これにより、画面転送システムの利用者に対し、ネットワークに起因する処理の遅延が発生していることを正しく通知する。その結果、利用者のストレスや、思わぬ誤操作の原因を取り除くことができる。

　本実施形態に係る画面転送システムは、第２の実施形態と同様に、図７に示すサーバ装置１０００とクライアント装置２０００とによって構成される。また、データの流れも、第２の実施形態と同様に図７に示す通りである。従って、本実施形態に特有の画面共有品質予測部２００４における予測方法と、再構築部２００５の処理内容を以下に説明する。

　まず、本実施形態における画面共有品質予測部２００４について説明する。

　画面共有品質予測部２００４は、通信部２００２からネットワーク３００の品質を示すネットワーク情報を取得する。画面共有品質予測部２００４は、取得したネットワーク情報に基づき、ネットワーク３００において遅延が発生しているか否かを判定する。当該判定結果に応じて、再構築部２００５に対して、表示部２００３に描画するカーソルの画像（以下、カーソルイメージ情報という）を指定する。取得するネットワーク情報、および、それに基づいて遅延発生を判断する方法については後述する。

　次に、本実施形態における再構築部２００５について説明する。再構築部は、実施例１及び２で述べた機能に加え、以下の機能も有する。

　再構築部２００５は、入力部２００１から、画面共有品質予測部２００４を介して、カーソルの位置情報（ボタン押下情報等も含む。以下同様。)を通知され、記憶する。また、再構築部２００５は、画面共有品質予測部２００４から、カーソルイメージ情報を通知され、記憶する。あるいは、再構築部２００５は、画面共有品質予測部２００４からの要求に応じて、カーソル位置に描画するカーソルイメージ情報を決定する。この場合、描画命令にて指定されているカーソルイメージ情報を上書き更新してもよい。

　以下に、図１０（ｂ）を用いて本実施形態の画面共有品質予測部２００４の動作を説明する。図１０（ｂ）は、画面共有品質予測部２００４の動作を示すフローチャートである。

　まず、画面共有品質予測部２００４は、通信部２００２から描画命令、あるいはネットワーク情報を受信すると（ステップＳ１４０１）、遅延判定の処理を開始する（ステップＳ１４０２）。

　ネットワーク３００が遅延状態であると判定した場合、画面共有品質予測部２００４は、例えばカーソルイメージ情報Ｘを再構築部２００５に対して通知する（ステップＳ１４０３）。一方、遅延状態でないと判定した場合、画面共有品質予測部２００４は、カーソルイメージ情報Ｗを再構築部２００５に対して通知する（ステップＳ１４０５）。

　再構築部２００５においてカーソルイメージ情報Ｘからカーソルイメージ情報Ｗへの変更、あるいはカーソルイメージ情報Ｗからカーソルイメージ情報Ｘへの変更が発生した場合、一定時間カーソルイメージ情報の変更を禁止する（ステップＳ１４０４）。一定時間のカーソルイメージ情報の変更禁止は、カーソルイメージ情報が頻繁に変更されないために必要なフローである。

　ここで、カーソルイメージ情報Ｘは、ネットワーク３００に遅延が発生していることを利用者に通知するために用いられる。一般には、カーソルイメージ情報Ｘには砂時計マークの画像が用いられる。又はコンピュータが処理中であることを示す砂時計マークの画像と同一の画像を利用してもよい。更にはまた、遅延状態であることを明示的に提示するため、異なる砂時計マークの画像を利用しても良い。

　なお、ネットワーク３００が遅延状態であると予測しているとき、クライアント装置２０００は以下に述べる動作を行っても良い。

・ネットワーク３００が遅延状態であるとき、表示部２００３の画面描画を停止してもよい。即ち、ネットワーク３００が遅延状態であるときは、サーバ装置１０００から送信される出力画面情報の受信が円滑に行われない。よって、描画が乱れたり、遅延したりして、クライアント装置のリソースを不要に消費したりすることを避けるために、画面描画を停止させる。

・ネットワーク３００が遅延状態であるとき、カーソルイメージ情報Ｘ（砂時計マーク）の位置の更新を行わず、停止させてもよい。これは、利用者にクライアント端末２０００の操作ができないことを通知するためである。

・ネットワーク３００が遅延状態であるとき、入力情報の送信を停止してもよい。即ち、ネットワーク３００が遅延状態であるときは、ネットワーク３００に異常が発生している場合がある。従って、通信部２００２から入力情報を送信しても、応答として返信される出力情報を正しく受信できる可能性は低い。また、新たな送信データが発生することで、ネットワーク３００の更なる混雑や輻輳を招くおそれがある。これを避けるためである。

　次に、ステップＳ１４０２のネットワーク３００が遅延状態であるか否かの判定について説明する。画面共有品質予測部２００４は、以下に記す３つのステップを繰り返すことにより、ネットワーク３００が遅延状態であるか否かを判定する。（１）遅延値の計算、（２）遅延値と遅延判断定数との比較による遅延状態であるか否かの決定、（３）遅延判断定数の修正である。

（１）遅延値Ｙの計算
　ネットワーク情報に基づき、遅延値Ｙを計算して求める。遅延値Ｙは、例えば、ＲＴＴ (Round Trip Time)などの時間幅である。利用するネットワーク情報と、その計算方法にはいくつかのバリエーションがあるため、後述する。

（２）遅延値と遅延判断定数との比較による遅延状態であるか否かの決定
　図１１（ａ）に、時間経過に対する遅延指数Ｙの変化を示す。図１１（ａ）の横軸は、遅延値Ｙである。また、縦軸は、時間経過ｔである。

　「（１）遅延値の計算」で得られた遅延値Ｙと、事前に定められた２つの遅延判断定数Ａ，Ｂ（Ａ＜Ｂ）の大小を比較する。ＹがＢより大きい（つまり、前回のＹはＹ＜Ｂであったにも関わらず、今回のＹは、Ｂ＜Ｙであった）ならば、ネットワーク３００が遅延状態であると判定する。ＹがＡより小さい（つまり、前回のＹはＡ＜Ｙであったにも関わらず、今回のＹは、Ｙ＜Ａであった）ならば、ネットワーク３００が遅延状態でないと判定する。上記以外の場合は、前回の判定結果を維持し、変更しない。

　図１１（ａ）は、上述の判定の結果をグラフ化したものである。即ち、図１１（ａ）に示すように、遅延値Ｙが遅延判断定数Ｂを超えた時刻から、遅延判断定数Ａを下回った時刻までを、ネットワーク３００が遅延状態であると、画面共有品質予測部２００４は判定する。

（３）遅延判断定数の修正
　「（１）遅延値の計算」で得られた遅延値Ｙに基づき、遅延値Ｙの平均値を計算する。このとき、上述の遅延判断定数ＡおよびＢの値を、遅延値Ｙの平均値を考慮して修正してもよい。

　ここで、遅延判断定数Ａ，Ｂの初期値は、クライアント装置２０００がネットワーク３００に接続しているリンク情報を用いて決定してもよい。例えば、クライアント装置２０００が有線ＬＡＮに接続している場合を考える。クライアント装置２０００が１００Ｍｂｐｓの有線ＬＡＮに接続している場合と、１Ｇｂｐｓの有線ＬＡＮに接続している場合とでは、後者の方がＡおよびＢの値が大きいことが望ましい。次に、クライアント装置２０００が無線ＬＡＮに接続している場合を考える。IEEE802.11b準拠の無線ＬＡＮを用いる場合と、IEEE802.11g準拠の無線ＬＡＮを用いる場合とでは、後者の方がＡおよびＢの値が大きいことが望ましい。

　次に、上述の「（１）遅延値の計算」におけるネットワーク情報の種類と遅延値の計算方法を説明する。遅延値は、以下（Ａ）～（Ｄ）に示すいずれかの方法、またはこれらの組合せによって計算して求める。

（Ａ）ＲＴＴ値をネットワーク情報として用いる。

　クライアント装置２０００の画面共有品質予測部２００４は、サーバ装置１０００との間で、ＲＴＴ (Round Trip Time)を測定するためのデータを交換する。ＲＴＴの測定方法は、一般的に知られた方法を利用するものとする。本発明で限定するものではないため、詳細説明は省く。画面共有品質予測部２００４は、測定により得られたＲＴＴ値を、遅延値として利用する。

（Ｂ）パケット欠損率をネットワーク情報として用いる。

　クライアント装置２０００の画面共有品質予測部２００４は、「（１）サーバ装置１０００に対して送信したデータのうち、未だTCP Ackメッセージを受信していない数」、もしくは「（２）TCPスタックにおける現在のセグメントサイズ」などの送信データに関するネットワーク情報を、通信部２００２から取得し記憶する。上記（１）を用いる場合、画面共有品質予測部２００４は、未だTCP Ackメッセージを受信していないデータの割合を計算し、遅延値として使用する。上記（２）を用いる場合には、画面共有品質予測部２００４は、最大セグメントサイズと現在のセグメントサイズとの差を計算し、遅延値として使用する。

（Ｃ）画面更新データ受信開始から受信完了に要する時間を、ネットワーク情報として用いる。

　通信部２００２が受信する画面更新データは、複数のTCPパケットとして届けられることもあるし、一部データが欠損して届けられたために再送処理が行われることもある。そのため、通信部２００２にて、画面更新データを受信開始する時刻と、画面更新データを受信完了する時刻は異なる。そこで画面共有品質予測部２００４は、通信部２００２において画面更新データを受信開始した時刻に、タイマー（図示せず）をスタートする。そして、画面更新データを受信完了した時刻に、当該タイマーをストップする。これにより、画面更新データの受信開始から受信完了に要する時間を測定する。画面共有品質予測部２００４は、測定した、画面更新データの受信開始から受信完了に要する時間を、遅延値として使用する。

　ただし、画面更新データの受信は開始されたが、画面更新データの受信完了に時間を要し、時間測定中のタイマーの値が非常に大きくなる場合がある。すなわち、画面更新データの受信開始から受信完了に要する時間が、遅延判断定数Ｂ以上となる場合である。この場合には、画面共有品質予測部２００４は、画面更新データの受信が完了していなくても、タイマーをストップし、その時点での測定値をネットワーク情報としてもよい。

（Ｄ）入力データ送信完了から画面更新データ受信完了に要する時間を、ネットワーク情報として用いる。図１１（ｂ）を用いて、本ケースを説明する。

　画面共有品質予測部２００４は、入力データをサーバ装置１０００に送信する際、送信する入力データにシーケンス番号を付加する。図１１（ｂ）では、クライアント装置２０００は、まずシーケンス番号「５」の入力データを、サーバ装置１０００に送信している。

　そして、画面共有品質予測部２００４は、入力データを送信完了した時刻に、シーケンス番号に対応したタイマー（図示せず）をスタートする。それとともに、シーケンス番号を増加させる。図１１（ｂ）では、シーケンス番号「５」「６」の入力データを送信する毎に、対応するタイマーをスタートしている。

　また画面共有品質予測部２００４は、入力データの送信に対してサーバ装置１０００から返信される画面更新データを受信する際、画面更新データに付加されているシーケンス番号を確認する。画面共有品質予測部２００４は、画面更新データを受信完了した時刻に、前述のシーケンス番号に対応したタイマーをストップする。図１１（ｂ）では、シーケンス番号「５」の画面更新データをサーバ装置１０００から受信すると、クライアント装置２０００は対応するタイマーをストップしている。

　ここで上記では、サーバ装置１０００は、クライアント装置２０００から受信した入力データに付加されるシーケンス番号のうち、最新のものを常に記憶している。そして、サーバ装置１０００は、記憶したシーケンス番号を画面更新データに付加して送信することを仮定している。

　以上により、画面共有品質予測部２００４は、シーケンス番号に対応したタイマーの値から、入力データ送信完了から画面更新データ受信完了に要する時間（図１１（ｂ）における「測定時間」）を測定する。画面共有品質予測部２００４は、測定した、入力データ送信完了から画面更新データ受信完了に要する時間を、遅延値として使用する。

　ただし、入力データの送信は開始したが、対応する画面更新データの受信に時間を要し、タイマーの値が非常に大きくなる場合がある。このとき、画面更新データの受信が完了していなくても、タイマーをストップする。そして、その時点のタイマー値をネットワーク情報としてもよい。

　また、入力データや画面更新データに付加されるシーケンス番号は、入力データや画面更新データとは別のデータとして送信されてもよい。シーケンス番号を入力データに付加して送信する場合は、利用者操作に直接関係しないマウスイベントの一部としてシーケンス番号を入力データに含めてもよい。さらに、シーケンス番号を画面更新データに付加して送信する場合は、クライアント装置２０００の描画範囲の外のディスプレイ描画情報の一部として、シーケンス番号を画面更新データに含めてもよい。

　入力データ送信完了から画面更新データ受信完了に要する時間を測定するタイミングは任意であり、入力データ送信完了のたび、常に測定を実行する必要は無い。例えば、入力データとして重要な、マウスのクリックの際にのみ、測定を実行することも可能である。

　画面転送システムにおいて、ある入力データがクライアント装置２０００からサーバ装置１０００に送信されると、多くの場合において、カーソルの再描画等の処理がサーバ装置１０００で発生する。その結果、描画イベントが発生し、画面更新データがサーバ装置１０００からクライアント装置２０００へ送信される。従って、上述の(D)の方法を用いて測定した時間は、クライアント装置２０００とサーバ装置１０００との間のＲＴＴに近い値になると考えられる。

　また、上述の（Ｄ）の方法は、クライアント装置２０００とサーバ装置１０００との間でＲＴＴ測定用の特別なパケットが発生しないため、ネットワーク上のトラフィック量の増加を引き起こさない。

　本実施形態によれば、ネットワーク品質が悪化して、クライアント装置における描画実行が遅延した場合、クライアント装置に表示されるカーソルの形状を、処理待ち中であることを示す「砂時計マーク」に変更する。これにより、画面転送システムの利用者に対し、ネットワークに起因する処理の遅延が発生していることを正しく通知することができる。その結果、利用者の誤操作を防ぎ、さらなるネットワークの混雑を回避することができる。ネットワークの混雑に起因するパケットの遅延や欠損を低減できるので、クライアント装置における出力応答を遅延や欠損なく画面表示することが可能になる。

　また、画面転送システムの利用者は、ネットワークに起因する処理の遅延が発生していることを正しく把握することができるので、利用者のストレスを軽減することができる。

　尚、本発明は上記実施形態をそのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記実施形態に開示されている複数の構成要素の適宜な組み合わせにより、種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。さらに、異なる実施形態にわたる構成要素を適宜組み合わせてもよい。

１００・・・サーバ装置
１０１・・・描画命令生成部
１０２・・・シーケンス番号付加部
１０３・・・エンコード部
１０４・・・描画命令送信部
１０５・・・フレームバッファ
１０６・・・表示部
１０７・・・再構築部
１０８・・・画面共有品質予測部
１０９・・・履歴記憶部
１１０・・・履歴取得部
１１１・・・欠損通知受信部
２００・・・クライアント装置
２０１・・・描画命令受信部
２０２・・・欠損検知部
２０３・・・デコード部
２０４・・・描画実行部
２０５・・・フレームバッファ
２０６・・・表示部
２０７・・・欠損通知送信部
３００・・・ネットワーク

Claims

　クライアント装置からネットワークを介して入力データを受信し、前記入力データに対する応答画面の描画命令を前記ネットワークを介して前記クライアント装置に送信するサーバ装置であって、
　前記クライアント装置へ送信した前記描画命令を記憶する履歴記憶部と、
　前記クライアント装置から送信された前記描画命令に欠損が生じたことを通知する通知データを受信する受信部と、
　前記通知データに応じて前記履歴記憶部から抽出した前記描画命令を再送信することによって前記クライアント装置で描画の破綻が生じるか否かを予測する第１の予測部と、
　前記第１の予測部によって描画の破綻が生じると予測した場合に、前記履歴記憶部に記憶された描画命令と前記通知データとから描画の破綻が生じないように描画命令を再構築する再構築部と、
　前記再構築した描画命令を前記クライアント装置に送信する送信部と
を備えることを特徴とするサーバ装置。
　前記第１の予測部は、前記履歴記憶部に記憶された描画命令の送信履歴に基づき前記再送信しようとする前記描画命令により前記クライアント装置の描画が破綻するか否かを予測することを特徴とする請求項１に記載のサーバ装置。
請求項１に記載のサーバ装置と、クライアント装置とから構成される画面転送システムであって、
前記クライアント装置は
　前記入力データを前記サーバ装置に送信する場合に、前記入力データによって前記ネットワークが混雑状態か否かを予測する第２の予測部と、
　前記第２の予測部によって混雑状態が生じると予測した場合に、前記入力データの前記サーバ装置への送信を遮断する遮断部と、
　前記第２の予測部によって混雑状態が生じると予測した場合に、前記サーバ装置から前記描画命令を受信することなく前記入力データに基づいて描画命令を構築する構築部と、
　構築された前記描画命令による応答画面を表示する表示部と、
を備えることを特徴とする画面転送システム。
　前記クライアント装置において、
　前記第２の予測部は、前記ネットワークの混雑状態を示す数値を測定する機能をさらに有し、
　前記第２の予測部が前記数値に基づき前記ネットワークが混雑状態であると予測した場合は、前記構築部は前記混雑状態を示す画面を表示させる描画命令を構築する
ことを特徴とする請求項３に記載の画面転送システム。
　前記数値は、前記サーバ装置と前記クライアント装置間のラウンドトリップタイム、パケット欠損率、受信遅延時間のいずれかであることを特徴とする請求項４に記載の画面転送システム。