(57)【要約】【課題】リモートデスクトップシステムにおいて、クライアント側の負荷を増大させることなく、サーバからクライアントに送信される画像データのデータ量を大幅に削減してＧＵＩの反応速度を向上させる。【解決手段】サーバＥ０１の固有値算出部８０１は、クライアントＥ０２のディスプレイ４１０に表示させる画像データの固有値（例えばハッシュ値）を算出する。算出された固有値及び画像データは、テーブルに格納されるとともにクライアントに送信される。また、比較決定部８０２は、送信すべき画像データの固有値とテーブルに格納されている固有値とを参照し、一致する固有値が発見された場合にはクライアントに画像データを送らずに固有値のみを送信する。クライアントでは、サーバから受信したデータをテーブルに蓄積し、サーバから固有値のみを受信した場合には、その固有値に対応する画像データをテーブルから取得して、ディスプレイに出力する。【選択図】図１
2007226635.tif 000002
【特許請求の範囲】
【請求項１】
クライアント装置に対して、前記クライアント装置の表示手段に表示させる画像データを送信するリモートデスクトップシステムのサーバ装置であって、
前記画像データを特定するための固有値を少なくとも含むデータを保持するためのテーブルを格納するテーブル格納手段と、
前記画像データに対してハッシュ関数による演算を行うことによって得られるハッシュ値を、前記画像データを特定するための前記固有値として設定する固有値算出手段と、
前記テーブル内に保持されている前記データと、前記固有値算出手段で算出された前記固有値とを比較して、前記固有値算出手段で算出された前記固有値に一致する固有値が前記テーブル内に発見された場合には、前記画像データを特定する前記固有値を含むとともに前記画像データを含まない表示更新用データを作成する一方、前記固有値算出手段で算出された前記固有値に一致する固有値が前記テーブル内に発見されなかった場合には、前記画像データを特定する前記固有値及び前記画像データの両方を含む表示更新用データを作成する比較決定手段と、
前記表示更新用データを前記クライアント装置に送信するデータ送信手段と、
前記表示更新用データを前記テーブル内の前記データとして登録する追加登録手段とを、
有するサーバ装置。
【請求項２】
クライアント装置に対して、前記クライアント装置の表示手段に表示させる画像データを送信するリモートデスクトップシステムのサーバ装置であって、
前記画像データを特定するための固有値を少なくとも含むデータを保持するためのテーブルを格納するテーブル格納手段と、
前記画像データに対してハッシュ関数による演算を行うことによって得られるハッシュ値を、前記画像データを特定するための前記固有値として設定する固有値算出手段と、
前記テーブル内に保持されている前記データと、前記固有値算出手段で算出された前記固有値とを比較して、前記固有値算出手段で算出された前記固有値に一致する固有値が前記テーブル内に発見された場合には、前記画像データを特定する前記固有値を含むとともに前記画像データを含まない表示更新用データを生成する一方、前記固有値算出手段で算出された前記固有値に一致する固有値が前記テーブル内に発見されなかった場合には、前記画像データを特定する前記固有値及び前記画像データの両方を含む中間データを生成する比較決定手段と、
前記テーブル内に保持されている前記データと前記中間データに含まれる前記画像データとを比較して、前記中間データに含まれる前記画像データと横幅及び高さの一致する画像データが前記テーブルに発見された場合には、前記中間データに含まれる前記画像データと前記テーブル内で発見された前記画像データとを比較してこれらの差分画像データ及び前記差分画像データの配置位置を取得し、前記中間データに関して、前記画像データを削除するとともに前記差分画像データ及び前記差分画像データの配置位置と前記テーブル内で発見された前記画像データの前記固有値とを挿入して表示更新用データを作成する一方、前記中間データに含まれる前記画像データと横幅及び高さの一致する画像データが前記テーブルに発見されなかった場合には、前記中間データから前記表示更新用データを作成する差分決定手段と、
前記表示更新用データを前記クライアント装置に送信するデータ送信手段と、
前記表示更新用データを前記テーブル内の前記データとして登録する追加登録手段とを、
有するサーバ装置。
【請求項３】
クライアント装置に対して、前記クライアント装置の表示手段に表示させる画像データを送信するリモートデスクトップシステムのサーバ装置であって、
前記クライアント装置から、前記クライアント装置のテーブルの上限データ量の値を受信する閾値受信手段と、
前記画像データを特定するための固有値を少なくとも含むデータを保持するための第１テーブルを格納する第１テーブル格納手段と、
前記第１テーブル内に保持されているデータの中から選択されたデータを保持するための第２テーブルを格納する第２テーブル格納手段と、
前記画像データに対してハッシュ関数による演算を行うことによって得られるハッシュ値を、前記画像データを特定するための前記固有値として設定する固有値算出手段と、
前記第２テーブル内に保持されている前記データと、前記固有値算出手段で算出された前記固有値とを比較して、前記固有値算出手段で算出された前記固有値に一致する固有値が前記第２テーブル内に発見された場合には、前記画像データを特定する前記固有値を含むとともに前記画像データを含まない表示更新用データを作成する一方、前記固有値算出手段で算出された前記固有値に一致する固有値が前記第２テーブル内に発見されなかった場合には、前記画像データを特定する前記固有値及び前記画像データの両方を含む表示更新用データを作成する比較決定手段と、
前記表示更新用データを前記クライアント装置に送信する表示更新用データ送信手段と、
前記表示更新用データをその格納順を示す情報と共に前記第１テーブル内の前記データとして登録する追加登録手段とを、
前記第１テーブルのデータのうちの前記格納順が新しいデータを、前記第２テーブルのデータ量が前記上限データ量を基準としたデータ量を超えないように前記第２のテーブルに格納するとともに、前記第２のテーブルに前記データを格納すると同時に前記第２のテーブルに格納した前記データを前記クライアント装置のテーブルの更新用のテーブル更新用データとして前記クライアント装置に送信するテーブル更新制御手段とを、
有するサーバ装置。
【請求項４】
前記データ送信手段によって送信する前記クライアント装置のテーブルに格納させるデータを、その送信前に、前記クライアント装置側でテーブルを格納するために使用するメモリのタイプに合わせて変換するデータ変換手段を有する請求項１から３のいずれか１つに記載のサーバ装置。
【請求項５】
サーバ装置から受信する画像データに基づいて画像表示を行うリモートデスクトップシステムのクライアント装置であって、
画像表示を行う表示手段と、
前記画像データに対してハッシュ関数による演算を行うことによって得られるハッシュ値を前記画像データの固有値とし、前記画像データを特定するための前記固有値を少なくとも含むデータを保持するためのテーブルを格納するテーブル格納手段と、
前記サーバ装置から、前記表示手段における表示を更新するための表示更新用データを受信するデータ受信手段と、
前記データ受信手段で受信した前記表示更新用データに前記画像データを特定するための固有値及び前記画像データの両方が含まれている場合には、前記画像データに基づいて前記表示手段に表示する画像を作成する一方、前記データ受信手段で受信した前記表示更新用データに前記画像データを特定する前記固有値のみが含まれており前記画像データが含まれていない場合には、前記テーブル内に保持されているデータと、前記表示更新用データに含まれている前記固有値とを比較して、前記テーブル内に前記固有値と共に保持されている画像データに基づいて前記表示手段に表示する画像を作成する描画作成手段と、
前記描画作成手段で作成された前記画像を前記表示手段に出力する出力手段と、
前記データ受信手段で受信した前記表示更新用データを前記テーブル内の前記データとして登録する追加登録手段とを、
有するクライアント装置。
【請求項６】
サーバ装置から受信する画像データに基づいて画像表示を行うリモートデスクトップシステムのクライアント装置であって、
画像表示を行う表示手段と、
前記画像データに対してハッシュ関数による演算を行うことによって得られるハッシュ値を前記画像データの固有値とし、前記画像データを特定するための前記固有値を少なくとも含むデータを保持するためのテーブルを格納するテーブル格納手段と、
前記サーバ装置から、前記表示手段における表示を更新するための表示更新用データを受信するデータ受信手段と、
前記データ受信手段で受信した前記表示更新用データに差分画像データ及び前記差分画像データの配置位置と差分の比較対象となる画像データの固有値と差分合成によって作成される元画像データの固有値とが含まれている場合には、前記テーブル内に保持されているデータと、前記差分の比較対象となる前記画像データの前記固有値とを比較して、前記テーブル内から前記固有値と共に保持されている前記差分の比較対象となる前記画像データを読み出し、読み出された前記画像データの前記配置位置に前記差分画像データを合成して合成画像データを作成し、前記表示更新用データに関して、前記差分画像データ及び前記差分画像データの配置位置と前記テーブル内で発見された前記画像データの前記固有値とを削除するとともに前記合成画像データを挿入して中間データを作成する差分合成手段と、
前記データ受信手段で受信した前記表示更新用データに前記画像データを特定する前記固有値及び前記画像データの両方が含まれている場合には、前記画像データに基づいて前記表示手段に表示する画像を作成し、前記データ受信手段で受信した前記表示更新用データに前記画像データを特定する前記固有値のみが含まれており前記画像データが含まれていない場合には、前記テーブル内に保持されているデータと、前記表示更新用データに含まれている前記固有値とを比較して、前記テーブル内に固有値と共に保持されている画像データに基づいて前記表示手段に表示する画像を作成し、前記差分合成手段で作成された前記表示更新用データに関しては、前記合成画像データに基づいて前記表示手段に表示する画像を作成する描画作成手段と、
前記描画作成手段で作成された前記画像を前記表示手段に出力する出力手段と、
前記描画作成手段で前記画像の作成の際に参照される前記表示更新用データを前記テーブル内の前記データとして登録する追加登録手段とを、
有するクライアント装置。
【請求項７】
サーバ装置から受信する画像データに基づいて画像表示を行うリモートデスクトップシステムのクライアント装置であって、
画像表示を行う表示手段と、
前記画像データに対してハッシュ関数による演算を行うことによって得られるハッシュ値を前記画像データの固有値とし、前記画像データを特定するための前記固有値を少なくとも含むデータを保持するためのテーブルを格納するテーブル格納手段と、
前記サーバ装置に対して、前記テーブル格納手段に格納される前記テーブルの上限データ量の値を送信する閾値送信手段と、
前記サーバ装置から、前記表示手段における表示を更新するための描画用の表示更新用データと、前記テーブル格納手段に格納されている前記テーブルの更新用のテーブル更新用データとを受信するデータ受信手段と、
前記データ受信手段で受信した前記表示更新用データに前記画像データを特定するための固有値及び前記画像データの両方が含まれている場合には、前記画像データに基づいて前記表示手段に表示する画像を作成する一方、前記データ受信手段で受信した前記表示更新用データに前記画像データを特定する前記固有値のみが含まれており前記画像データが含まれていない場合には、前記テーブル内に保持されているデータと、前記表示更新用データに含まれている前記固有値とを比較して、前記テーブル内に前記固有値と共に保持されている画像データに基づいて前記表示手段に表示する画像を作成する描画作成手段と、
前記描画作成手段で作成された前記画像を前記表示手段に出力する出力手段と、
前記データ受信手段で受信した前記画像データを特定するための固有値及び前記画像データの両方が含まれている前記テーブル更新用データを前記テーブル内の前記データとして登録する追加登録手段とを、
有するクライアント装置。
【請求項８】
前記テーブル格納手段に前記データを格納する際には、前記テーブル格納手段として使用するメモリのタイプに合わせて変換し、前記テーブル格納手段から前記データを読み出す際には、前記描画作成手段で前記画像の作成の際に参照可能なデータ構造に変換するデータ変換手段を有する請求項５から７のいずれか１つに記載のクライアント装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、キーボードなどの入力装置と、映像を表示することが可能なビットマップディスプレイなどの表示装置とを備えたクライアント装置から遠隔地にあるサーバ装置に対して、アプリケーションなどの操作指示を送信し、その結果として、サーバ装置からクライアント装置に送信される映像をクライアント装置で表示するリモートデスクトップシステムに関し、特に、リモートデスクトップシステムのサーバ装置及びクライアント装置に関する。
【背景技術】
【０００２】
リモートデスクトップシステムとして１９７０年代から普及したＴＳＳ（Time Sharing System：タイム・シェアリング・システム）は、マルチユーザ型の汎用コンピュータであり、貴重な計算機資源を複数のユーザ（利用者）が複数の端末装置を介して同時に使用できるようにしたものである。以下、図２３を参照しながら、従来のＴＳＳの一例を説明する。
【０００３】
図２３に図示されているＴＳＳでは、例えば、ＴＳＳを提供する汎用コンピュータＡ０１上で動作する端末サーバ１０２と端末装置１０３とがシリアル伝送Ａ０２で接続されており、ユーザＡ０３は端末装置１０３からＴＳＳにログインし、アプリケーション１０１を実行する。端末サーバ１０２は、端末装置１０３のキーボードから入力された文字列をアプリケーション１０１の入力に渡すとともに、アプリケーション１０１の文字列出力を端末装置１０３に送り返す。これにより、端末装置１０３は、端末サーバ１０２から受信した文字列をディスプレイ１０４に表示して、遠隔操作を行うことが可能となる。なお、文字列は、ＩＥＥＥ（Institute of Electrical and Electronic Engineers）−４８８（又はＲＳ−２３２Ｃ）のような無手順シリアル伝送規格のビット列に変換されて、ＴＳＳと端末装置１０３との間で送受信される。
【０００４】
一方、リモートデスクトップシステムとして１９８０年代から普及したＸウィンドウシステムは、マサチューセッツ工科大学で開発されたクライアント・サーバ型リモートデスクトップシステムである。上述のＴＳＳでは文字列の送受信のみが可能であったが、Ｘウィンドウシステムでは、端末装置がビットマップディスプレイ２０４を備えていることを前提としており、ユーザは、マウスやキーボードなどのポインティングデバイス２０５による入力の結果として、文字列だけではなく静止画や動画などの映像情報を受け取り、この映像情報をビットマップディスプレイ２０４に表示することで、映像情報を視認することが可能である。以下、図２４を参照しながら、従来のＸウィンドウシステムの一例を説明する。
【０００５】
図２４に図示されているＸウィンドウシステムは、例えば、サーバＢ０１として機能する汎用コンピュータ上で動作するＸサーバ２０２と、Ｘサーバ専用のＸアプリケーション２０１と、クライアントＢ０３として機能する端末装置上で動作するＸクライアント２０３と、サーバＢ０１とクライアントＢ０３との間を接続する通信ネットワークＢ０２によって構成されている。サーバＢ０１である汎用コンピュータ上において、Ｘアプリケーション２０１が表示したい描画データ列をＸサーバ２０２に出力すると、Ｘサーバ２０２は、通信ネットワークＢ０２を介して接続しているクライアントＢ０３である端末装置上のＸクライアント２０３に対して描画データ列を送信する。Ｘクライアント２０３は、描画データ列を解釈して、端末装置が備えるビットマップディスプレイ２０４に表示する。
【０００６】
上述のＸウィンドウシステムで扱われる描画データ列とは、描画データの時系列集合であり、描画データとは『画面の座標（Ｘ１，Ｙ１）から（Ｘ２，Ｙ２）まで黒色で太さ１の線を引く』などのような抽象描画命令である。抽象描画命令には、線を引くほかに、点を打つ、四角を描く、四角の内側を塗りつぶす、楕円を描く、楕円の内側を塗りつぶすなどの原始的な描画処理が含まれている。
【０００７】
また、描画データ列は、Ｘプロトコルと呼ばれる通信プロトコルに変換され、Ｘサーバ２０２とＸクライアント２０３との間で送受信される。一方、ポインティングデバイス２０５のボタンの押下状態などもＸプロトコルに変換され、Ｘサーバ２０２とＸクライアント２０３との間で送受信される。
【０００８】
さらに、１９９０年代からは、ＡＴ＆Ｔ（American Telephone and Telegraph）ケンブリッジ研究所で開発されたＶＮＣ（Virtual Network Computing：バーチャル・ネットワーク・コンピューティング）が普及している。以下、図２５を参照しながら、従来のＶＮＣの一例を説明する。
【０００９】
図２５に図示されているＶＮＣは、Ｘウィンドウシステムと同様にクライアント・サーバ型リモートデスクトップシステムであり、ＶＮＣサーバ３０３とＶＮＣクライアント３０４との間におけるビットマップ画像伝送を基調とした描画処理を行う。
【００１０】
ＶＮＣでは、汎用コンピュータＣ０１側に、クライアントＣ０３の操作環境であるデスクトップに相当するフレームバッファ３０２が設けられている。フレームバッファ３０２は、画面全体のビットマップ画像を少なくとも１枚保存することができるメモリ領域である。なお、フレームバッファ３０２から汎用コンピュータＣ０１側のビットマップディスプレイ（不図示）に逐次出力を行うことも可能である。
【００１１】
一方、ＶＮＣサーバ３０３は、フレームバッファ３０２を継続的に監視しており、アプリケーション３０１が描画した結果であるビットマップ画像をフレームバッファ３０２から抽出し、これを描画データ列として通信ネットワークＣ０２を介してＶＮＣクライアント３０４に送信する。なお、ＶＮＣで扱われる描画データは、Ｘウィンドウシステムのような抽象描画命令ではなく、『縦横（８００，６００）ピクセルのビットマップ画像を画面の座標（Ｘ３，Ｙ３）に描画しろ』などのようなビットマップ画像を含む非効率なものである。そして、ＶＮＣクライアント３０４は、この描画データ列を解釈して、クライアントＣ０３が備えるビットマップディスプレイ３０５に表示する。
【００１２】
また、描画データ列は、ＶＮＣプロトコルと呼ばれる通信プロトコルに変換され、ＶＮＣサーバ３０３とＶＮＣクライアント３０４との間で送受信される。一方、ポインティングデバイス３０６のボタンの押下状態などもＶＮＣプロトコルに変換され、ＶＮＣサーバ３０３とＶＮＣクライアント３０４との間で送受信される。
【００１３】
ＸウィンドウシステムではＸアプリケーション２０１が描画データ列を生成していたが、ＶＮＣでは、フレームバッファ３０２に描画する能力があるすべてのアプリケーションに適用できる点に特徴がある。いったんフレームバッファ３０２を介して描画データ列の受け渡しが行われるため、アプリケーション３０１側は特別な仕掛けが不要である。このため、ＶＮＣでは、汎用コンピュータＣ０１上でＸウィンドウシステムとは全く異なる描画体系を持つマイクロソフト・ウィンドウズ（登録商標）やアップル・ＭａｃＯＳ（登録商標）などのＯＳ（Operating System：オペレーティング・システム）が動作していても、同一のクライアントＣ０３から統一的にアプリケーション３０１をリモートコントロールすることが可能である。
【００１４】
一方、現在のアプリケーションの実行環境としては、ＰＣ（Persopnal Computer：パーソナル・コンピュータ）が支配的な市場位置を占めている。ＰＣは、潤沢なＣＰＵ（Central Processing Unit：中央演算処理装置）パワーと、出力装置としてビットマップディスプレイやフレームバッファ、入力装置としてマウスやキーボードなどを兼ね備えている。このため、ＰＣは、リモートデスクトップシステムのサーバ側及びクライアント側のどちらの役割も担うことができる。現在では、ユーザの間では、あるＰＣから別のＰＣのアプリケーションを呼び出して遠隔操作する利用形態が一般化しつつある。  
【００１５】
特に最近では、個人情報保護法の施行など、情報保護の機運が高まっているため、顧客名簿や重要文書などが入った社用ＰＣは常に会社に置いておき、必要な時だけリモートデスクトップシステムを用いてモバイルＰＣから閲覧する形態の集中データ管理手法が注目されつつある。集中データ管理手法では、外出先に持ち運ぶモバイルＰＣなどには重要データそのものがコピーされないため、重要データをモバイルＰＣごと盗難されることはなく、重要データの安全性が高まる。また、悪意ある第３者が、リモートデスクトップシステムの描画データ列を取得し、ビットマップ画像の一部を復元したとしても、それはアプリケーション上に表示された重要データのほんの一部分であるため、例えば数百万件の顧客名簿を一瞬にしてコピーするようなことはできず、安全性が高まる。
【００１６】
次に、ＶＮＣや同種の技術におけるリモートデスクトップシステムの描画データ列について詳しく説明する。フレームバッファの監視から得られた非圧縮ビットマップ画像を含む描画データ列は、膨大なデータ量を有している。例えば、一般的なＰＣの解像度である１０２４×７６８ピクセルで３２ビットフルカラーのビットマップ画像を、ユーザが滑らかに映像の変化として感じられる１０フレーム／秒で送信する場合、その総データ量は約３０ＭＢ／Ｓ（＝２４０Ｍｂｐｓ）に達する。しかしながら、現在、個人ユーザがインターネット接続に用いているＡＤＳＬ（Asymmetric Digital Subscriber Line：非対称デジタル加入者線）のスループット（平均伝送帯域）の実用的な上限は１．５ＭＢ／Ｓ（＝１２Ｍｂｐｓ）程度である。したがって、ＰＣのディスプレイ上に表示される画像を滑らかに表示するために非圧縮ビットマップ画像を含む描画データ列の伝送を行うことは甚だ非現実的であると言える。
【００１７】
そこで、下記の非特許文献１には、『ＰＣのデスクトップの画面全体のうちの一部分しか更新されないことが多い』という特性を活かして、時系列に変化するフレームバッファを監視し、更新領域のみを差分ビットマップ画像として抽出して、その差分ビットマップ画像を描画データ列としてクライアントに送信するための通信プロトコルが説明されている。以下、図２６〜図２８を参照しながら、従来のＶＮＣに関して詳細に説明する。
【００１８】
なお、図２６に示すＶＮＣサーバＤ０１及びＶＮＣクライアントＤ０２は、図２５に示すＶＮＣシステムから、動作説明に最低限必要なブロックを抽出したものであり、図２６に示すＶＮＣサーバＤ０１は、図２５に示すＶＮＣシステムのＶＮＣサーバ３０３に相当し、図２６に示すＶＮＣクライアントＤ０２は、図２５に示すＶＮＣシステムのＶＮＣクライアント３０４に相当する。
【００１９】
まず、図２６に示すＶＮＣサーバＤ０１の各ブロックについて説明する。フレームバッファ４０１は、アプリケーションから出力されクライアント側のデスクトップ画像に相当する画像データの読み出し及び書き込みを行うことが可能なメモリ領域であり、フレームバッファ４０１には、ある瞬間の画像データが蓄積される。また、フレーム取得部４０２は、フレームバッファ４０１から画像データを取得するフレームグラバ（Frame Grabber）である。また、前フレームバッファ４０４は、更新直前のフレームバッファ４０１内の画像データのコピーを保存する作業メモリ領域であり、比較部４０３は、フレームバッファ４０１内の画像データと前フレームバッファ４０４内の画像データとの時系列変化を観察することで、その差分の描画データ列を生成する機能を有している。また、通信部４０５は、比較部４０３で生成される差分の画像データである描画データ列をＶＮＣプロトコルに変換し、ＶＮＣクライアントＤ０２に送信する。
【００２０】
次に、図２６に示すＶＮＣクライアントＤ０２の各ブロックについて説明する。通信部４０６は、ＶＮＣサーバＤ０１からＶＮＣプロトコルを受信し、元の描画データ列への変換を行う。描画部４０７は、その描画データ列に含まれる描画データを用いて、画像データを保持するメモリ領域であるフレームバッファ４０８に、画像データとして描画を行う。出力部４０９は、フレームバッファ４０８を順次読み出し、Ｄ／Ａ（デジタル／アナログ）変換などの所望の信号処理を行ってディスプレイ４１０に出力することにより、ディスプレイ４１０上に画像データが表示される。
【００２１】
次に、図２７に示すＶＮＣサーバのフローチャートを参照しながら、上述の図２６に示すＶＮＣサーバＤ０１の動作について説明する。ＶＮＣサーバＤ０１において、フレーム取得部４０２がフレームバッファ４０１から画像データ（描画データ）を取得し（ステップＳ６０１）、まず前フレームバッファ４０４が空か否かを確認することによって、初回の画像データ取得動作か否かの判定が行われる（ステップＳ６０２）。このとき、前フレームバッファ４０４が空の場合（画像データが１度も書き込まれていない場合）にはステップＳ６０５に進み、前フレームバッファ４０４が空ではない場合にはステップＳ６０３に進む。
【００２２】
前フレームバッファ４０４が空ではない場合、比較部４０３は、前フレームバッファ４０４内の画像データと、フレーム取得部４０２から得られた画像データとの差分を比較し、差分がある場合にはその差分から描画データを生成し、さらに描画データの集合である描画データ列を生成する（ステップＳ６０３）。そして、通信部４０５は、比較部４０３で生成された描画データ列をＶＮＣプロトコルに変換し、ＶＮＣクライアントＤ０２に送信する（ステップＳ６０４）。また、前フレームバッファ４０４には、今回取得した画像データ（フレームバッファ４０１内の画像データ）が上書きされる（ステップＳ６０５）。また、ＶＮＣサーバＤ０１は、より上位の動作状態を取得し、例えば電源断ボタンが押されたなどの終了条件が成立している場合には動作を終了する一方、終了条件が存在しない場合にはステップＳ６０１に戻って上記の処理が繰り返し行われる。その結果、ＶＮＣサーバＤ０１は、動作中は常にフレームバッファ４０１を監視し、前フレームバッファ４０４との差分を描画データ列として抽出し、さらに描画データ列をＶＮＣプロトコルに変換して、ＶＮＣクライアントＤ０２へ送信し続ける。
【００２３】
なお、ここでの描画データとは、画面のすべて又は一部分の画像データを指すビットマップ画像と、そのビットマップ画像のレイアウト情報（すなわち、画面上のどの部分に位置するかを指定するＸ座標とＹ座標、さらにビットマップ画像の横幅、高さなどの情報）をセットにしたものである。描画データは、例えば下記のデータ構造１を有している。なお、下記のデータ構造はあくまで一例であり、座標系や各要素の順序が異なっていてもよい。
【００２４】
（画面上のＸ座標、画面上のＹ座標、ビットマップ画像の横幅、ビットマップ画像の高さ、ビットマップ画像）・・・  ＜データ構造１＞
【００２５】
次に、図２８に示すＶＮＣクライアントのフローチャートを参照しながら、上述の図２６に示すＶＮＣサーバＤ０１の動作について説明する。ＶＮＣクライアントＤ０２は、通信部４０６を介してＶＮＣサーバＤ０１からＶＮＣプロトコルを受信し、元の描画データ列に変換する（ステップＳ７０１）。描画部４０７は、描画データ列に含まれる描画データを用いて、フレームバッファ４０８に画像データの描画を行う（ステップＳ７０２）。また、出力部４０９は、フレームバッファ４０８を順次読み出し、Ｄ／Ａ変換などの所望の信号処理を行ってディスプレイ４１０への出力を行う（ステップＳ７０３）。また、ＶＮＣクライアントＤ０２は、より上位の動作状態を取得し、例えば電源断ボタンが押されたなどの終了条件が成立している場合には動作を終了する一方、終了条件が存在しない場合にはステップＳ７０１に戻って上記の処理を繰り返し行う。その結果、ＶＮＣクライアントＤ０２は、動作中は常にＶＮＣプロトコルを受信して描画データ列を取得し、フレームバッファ４０８への描画データの描画を行って、ディスプレイ４１０を介してユーザに画像を提示し続ける。
【００２６】
一方、例えば、下記の特許文献１には、リモートデスクトップシステムの改良技術が開示されている。以下、図２９〜図３１を参照しながら、特許文献１に開示されている技術について説明する。
【００２７】
特許文献１に開示されている技術では、サーバからクライアントに送信されるデータ構造は、以下のように設定されている。
【００２８】
（キャッシュ情報、ＳＩＤ、コードワード）・・・＜ＲＫＥＹ＞
【００２９】
図２９において、サーバは、例えば上述のＶＮＣシステムでクライアントに送信する差分の画像に関し、更新する画像の更新領域の横幅（Ｗ）、高さ（Ｈ）が、閾値（ＴｈＷ、ＴｈＨ）を超えていないか否かを判断する（ステップＳ２８０１）。このとき、更新する画像の更新領域の横幅及び高さの両方が閾値を超えていない場合にはステップＳ２８０２に進み、それ以外の場合にはステップＳ２８０３に進む。
【００３０】
更新する画像の更新領域の横幅及び高さの両方が閾値を超えていない場合には、更新する画像の更新領域が小さく、キャッシュするに値しない画像データであると判断されて、領域キー（ＲＫＥＹ）のキャッシュ情報に『キャッシュ不要』、シーケンス識別子（ＳＩＤ）に『ＮＵＬＬ』、コードワードに『更新する画像データ（更新データ）』が代入されて、クライアントに送信される（ステップＳ２８０２）。すなわち、更新データの更新領域が小さい場合には、更新データがサーバからクライアントに送信される。
【００３１】
一方、ステップＳ２８０１で、更新する画像の更新領域の横幅及び高さの少なくとも一方が閾値を超えていると判断された場合には、ＲＫＥＹ作成処理が行われる（ステップＳ２８０３）。ＲＫＥＹ作成処理の詳細に関しては、図３０に図示されている。
【００３２】
図３０において、サーバは、メッセージヘッダのＲＫＥＹのキャッシュ情報に『キャッシュ』を設定し（ステップＳ２９０１）、キャッシュメモリ内に更新領域が同一のものが存在するか否かを判断する（ステップＳ２９０２）。ステップＳ２９０２で更新領域が同一のものが存在する場合には、ステップＳ２９０３に進み、キャッシュメモリ内に更新領域が同一のものが１つのみ存在しているか否かが判断される（ステップＳ２９０３）。また、ステップＳ２９０２で更新領域が同一のものが存在しない場合には、ステップＳ２９１０に進み、ＤＣＴ（Discrete Cosine Transform：離散コサイン変換）、量子化、エントロピー処理を行って更新データを符号化し（ステップＳ２９１０）、ステップＳ２９０９に進む。
【００３３】
また、ステップＳ２９０３でキャッシュメモリ内に存在する更新領域が同一のものが１つのみではない場合には、ＤＣＴ、量子化、エントロピー処理を行って更新データを符号化し（ステップＳ２９０５）、複数検出された同一の更新領域を持つデータのコードワード（キャッシュメモリ内のコードワード）と、ステップ２９０５で符号化した更新データとを比較し、同一のコードワードを持つデータが存在するか否かを検索する（ステップＳ２９０６）。そして、ステップＳ２９０７において、同一のコードワードを持つデータが存在する場合にはステップＳ２９０８に進み、同一のコードワードを持つデータが存在しない場合にはステップＳ２９０９に進む。一方、ステップＳ２９０３でキャッシュメモリ内に更新領域が１つのみ存在している場合には、ステップＳ２９０４に進む。
【００３４】
ステップＳ２９０４では、キャッシュメモリ内に更新領域が同一のデータが１つしか存在しない場合の処理が行われる。この場合、キャッシュ情報に『キャッシュ済』、ＳＩＤに『キャッシュメモリ内で一致したデータのＳＩＤ』が代入され、コードワードには何も設定されずに作成されたＲＫＥＹのデータがクライアントに送信される。
【００３５】
また、ステップＳ２９０８では、キャッシュメモリ内に同一のコードワードを持つデータが存在する場合の処理が行われる。この場合、キャッシュ情報に『キャッシュ済』、ＳＩＤに『キャッシュメモリ内で一致したデータのＳＩＤ』が代入され、コードワードには何も設定されずに作成されたＲＫＥＹのデータがクライアントに送信される。
【００３６】
また、ステップＳ２９０９では、キャッシュメモリ内に更新領域は同一であるが同一のコードワードが存在しない場合、又は、更新領域が異なる場合の処理が行われる。この場合、キャッシュ情報に『キャッシュ』、ＳＩＤに『割り振られていない値』、コードワードに『符号化した更新データ』が代入されたＲＫＥＹのデータがクライアントに送信される。
【００３７】
一方、図３１において、クライアントは、サーバから受信するＲＫＥＹのキャッシュ情報を監視及び解析を行い（ステップＳ３００１）、『キャッシュ不要』の場合にはステップＳ３００２に進み、『キャッシュ』の場合にはステップＳ３００３に進み、『キャッシュ済』の場合にはステップＳ３００５に進む。
【００３８】
ステップＳ３００２では、キャッシュ不要の場合の処理が行われる。この場合、コードワードに直接更新するデータが代入されており、それを更新データとする。
【００３９】
また、ステップＳ３００３では、キャッシュへの登録が必要な場合の処理が行われる。この場合、ＲＫＥＹのコードワードが符号化されているので、これを復号し、復号したデータを更新データとする。さらに、クライアントは、ＲＫＥＹのデータをローカルキャッシュメモリに登録する（ステップＳ３００４）。
【００４０】
また、ステップＳ３００５では、既にキャッシュされている場合の処理が行われる。この場合、受信したＲＫＥＹのＳＩＤと同一のＲＫＥＹのデータをローカルキャッシュメモリより取得する。さらに、クライアントは、ステップ３００５で取得したＲＫＥＹのコードワードを復号して、復号したデータを更新データとする（ステップＳ３００６）。
【００４１】
そして、上記のステップＳ３００２、Ｓ３００４、３００６のそれぞれで作成された更新データを使用して、更新領域にデータが表示される（ステップＳ３００７）。
【特許文献１】特表２００５−５０１３５５号公報（図４〜７、段落００１５、００１６）
【非特許文献１】Tristan Richardson, RealVNC Ltd：“The RFB Protocol” Version 3.8, 8 March 2005
【発明の開示】
【発明が解決しようとする課題】
【００４２】
従来のリモートデスクトップシステムのうち、Ｘウィンドウシステム型のリモートデスクトップシステムが、サーバとクライアントとの間における伝送効率が最も良いと考えられる。Ｘウィンドウシステム型のリモートデスクトップシステムでは、描画データは『線を描け』などのような抽象度の高いものであり、その結果、データ量は極小化されている。しかしながら、その代償としてＸウィンドウシステム用の描画データ列を生成する専用Ｘアプリケーションが必要になる。
【００４３】
インターネットが普及した今日では、様々なＰＣや汎用コンピュータが様々なアプリケーションを実行し、相互に分散ネットワークを形成している。このため、常にＸアプリケーションを要求するＸウィンドウシステムは時代の要請に合わず、異種間における接続に対してより汎用性の高いＶＮＣ型のリモートデスクトップシステムが好適であると言える。
【００４４】
しかしながら、ＶＮＣ型のリモートデスクトップシステムでは、上述のようにビットマップ画像を含む描画データ列のデータ量が膨大になる傾向がある。特に、最近の画面全体にビットマップ画像を用いた美麗なボタン類が並ぶＧＵＩ（Graphic User Interface：グラフィック・ユーザ・インタフェース）を用いたアプリケーションにおいては、更新領域が画面全体を占めることも珍しくない。例えば、図３２に図示されているようなウィザード形式のアプリケーションによる表示の場合には、例えば『次へ』ボタンを押すと新たな次画面に移るため、サーバからクライアントに対して画面全体を送らなければならない機会が非常に多い。これはＧＵＩの反応速度低下をもたらし、ユーザに対する利便性を低下させるとともに、ユーザのストレスを増大させる要因となる。
【００４５】
例えば、上述のように、スループットが１．５ＭＢ／ＳであるＡＤＳＬの通信ネットワークを介して、１０２４×７６８ピクセルで３２ビットフルカラーのビットマップ画像１枚を伝送する場合には、約２秒の表示遅延が生じることとなる。このため、Ｘウィンドウシステム型のリモートデスクトップシステムのような抽象度の高い描画データ列を生成することが可能なＶＮＣ型のリモートデスクトップシステムの開発が望まれている。しかしながら、アプリケーションをＸウィンドウシステム型の抽象描画命令に完全対応させることは、すなわち、新たなＸアプリケーションを新規に開発することになってしまい意味がない。これはＶＮＣが発達してきた背景を考えれば明らかである。
【００４６】
上述の特許文献１に係る技術では、更新表示データを『キャッシュ済』や『キャッシュ不要』などのように特定できるようにすることで、ＶＮＣ型のリモートデスクトップシステムにおいて、抽象度の高い描画データ列の生成を試みているが、この技術では、更新領域の大きさに応じて、非可逆符号化する部分と符号化しない部分とが存在し、クライアント側で実現される表示画像が視覚的に奇妙かつ見づらいものになってしまうという課題がある。
【００４７】
また、リモートデスクトップシステムでは、基本的にクライアント側の負荷が小さいことがメリットであるが、上述の特許文献１に係る技術では、クライアント側に符号化データを復号するための復号化器を設ける必要があり、復号機能に関してクライアント側の負荷を小さくすることができないという課題がある。
【００４８】
さらに、上述の特許文献１に係る技術では、作成されるＲＫＥＹデータが、更新領域、及び更新領域の大きさにより作成されているので、例えば同一のボタン形状の画像配列を有するＧＵＩのように異なる更新領域で同一の更新画像データが存在する場合であっても、更新領域が異なるために新たなＲＫＥＹを作成する必要があり、このＲＫＥＹをサーバ及びクライアントの両方においてキャッシュメモリに保存するので、キャッシュ量が増大してしまうという課題がある。
【００４９】
上記の課題を解決するため、本発明は、クライアント側の負荷を増大させることなく、サーバとクライアントとの間において送受信する描画データ列のデータ量を大幅に削減してＧＵＩの反応速度を向上させることが可能なリモートデスクトップシステムのサーバ装置及びクライアント装置を提供することを目的とする。
【課題を解決するための手段】
【００５０】
上記の目的を達成するため、本発明によれば、クライアント装置に対して、前記クライアント装置の表示手段に表示させる画像データを送信するリモートデスクトップシステムのサーバ装置であって、
前記画像データを特定するための固有値を少なくとも含むデータを保持するためのテーブルを格納するテーブル格納手段と、
前記画像データに対してハッシュ関数による演算を行うことによって得られるハッシュ値を、前記画像データを特定するための前記固有値として設定する固有値算出手段と、
前記テーブル内に保持されている前記データと、前記固有値算出手段で算出された前記固有値とを比較して、前記固有値算出手段で算出された前記固有値に一致する固有値が前記テーブル内に発見された場合には、前記画像データを特定する前記固有値を含むとともに前記画像データを含まない表示更新用データを作成する一方、前記固有値算出手段で算出された前記固有値に一致する固有値が前記テーブル内に発見されなかった場合には、前記画像データを特定する前記固有値及び前記画像データの両方を含む表示更新用データを作成する比較決定手段と、
前記表示更新用データを前記クライアント装置に送信するデータ送信手段と、
前記表示更新用データを前記テーブル内の前記データとして登録する追加登録手段とを、
有するサーバ装置が提供される。
【００５１】
また、上記の目的を達成するため、本発明によれば、クライアント装置に対して、前記クライアント装置の表示手段に表示させる画像データを送信するリモートデスクトップシステムのサーバ装置であって、
前記画像データを特定するための固有値を少なくとも含むデータを保持するためのテーブルを格納するテーブル格納手段と、
前記画像データに対してハッシュ関数による演算を行うことによって得られるハッシュ値を、前記画像データを特定するための前記固有値として設定する固有値算出手段と、
前記テーブル内に保持されている前記データと、前記固有値算出手段で算出された前記固有値とを比較して、前記固有値算出手段で算出された前記固有値に一致する固有値が前記テーブル内に発見された場合には、前記画像データを特定する前記固有値を含むとともに前記画像データを含まない表示更新用データを生成する一方、前記固有値算出手段で算出された前記固有値に一致する固有値が前記テーブル内に発見されなかった場合には、前記画像データを特定する前記固有値及び前記画像データの両方を含む中間データを生成する比較決定手段と、
前記テーブル内に保持されている前記データと前記中間データに含まれる前記画像データとを比較して、前記中間データに含まれる前記画像データと横幅及び高さの一致する画像データが前記テーブルに発見された場合には、前記中間データに含まれる前記画像データと前記テーブル内で発見された前記画像データとを比較してこれらの差分画像データ及び前記差分画像データの配置位置を取得し、前記中間データに関して、前記画像データを削除するとともに前記差分画像データ及び前記差分画像データの配置位置と前記テーブル内で発見された前記画像データの前記固有値とを挿入して表示更新用データを作成する一方、前記中間データに含まれる前記画像データと横幅及び高さの一致する画像データが前記テーブルに発見されなかった場合には、前記中間データから前記表示更新用データを作成する差分決定手段と、
前記表示更新用データを前記クライアント装置に送信するデータ送信手段と、
前記表示更新用データを前記テーブル内の前記データとして登録する追加登録手段とを、
有するサーバ装置が提供される。
【００５２】
また、上記の目的を達成するため、本発明によれば、クライアント装置に対して、前記クライアント装置の表示手段に表示させる画像データを送信するリモートデスクトップシステムのサーバ装置であって、
前記クライアント装置から、前記クライアント装置のテーブルの上限データ量の値を受信する閾値受信手段と、
前記画像データを特定するための固有値を少なくとも含むデータを保持するための第１テーブルを格納する第１テーブル格納手段と、
前記第１テーブル内に保持されているデータの中から選択されたデータを保持するための第２テーブルを格納する第２テーブル格納手段と、
前記画像データに対してハッシュ関数による演算を行うことによって得られるハッシュ値を、前記画像データを特定するための前記固有値として設定する固有値算出手段と、
前記第２テーブル内に保持されている前記データと、前記固有値算出手段で算出された前記固有値とを比較して、前記固有値算出手段で算出された前記固有値に一致する固有値が前記第２テーブル内に発見された場合には、前記画像データを特定する前記固有値を含むとともに前記画像データを含まない表示更新用データを作成する一方、前記固有値算出手段で算出された前記固有値に一致する固有値が前記第２テーブル内に発見されなかった場合には、前記画像データを特定する前記固有値及び前記画像データの両方を含む表示更新用データを作成する比較決定手段と、
前記表示更新用データを前記クライアント装置に送信する表示更新用データ送信手段と、
前記表示更新用データをその格納順を示す情報と共に前記第１テーブル内の前記データとして登録する追加登録手段とを、
前記第１テーブルのデータのうちの前記格納順が新しいデータを、前記第２テーブルのデータ量が前記上限データ量を基準としたデータ量を超えないように前記第２のテーブルに格納するとともに、前記第２のテーブルに前記データを格納すると同時に前記第２のテーブルに格納した前記データを前記クライアント装置のテーブルの更新用のテーブル更新用データとして前記クライアント装置に送信するテーブル更新制御手段とを、
有するサーバ装置が提供される。
【００５３】
さらに、本発明によれば、上記の構成に加えて、前記データ送信手段によって送信する前記クライアント装置のテーブルに格納させるデータを、その送信前に、前記クライアント装置側でテーブルを格納するために使用するメモリのタイプに合わせて変換するデータ変換手段を有するサーバ装置が提供される。
【００５４】
また、上記の目的を達成するため、本発明によれば、サーバ装置から受信する画像データに基づいて画像表示を行うリモートデスクトップシステムのクライアント装置であって、
画像表示を行う表示手段と、
前記画像データに対してハッシュ関数による演算を行うことによって得られるハッシュ値を前記画像データの固有値とし、前記画像データを特定するための前記固有値を少なくとも含むデータを保持するためのテーブルを格納するテーブル格納手段と、
前記サーバ装置から、前記表示手段における表示を更新するための表示更新用データを受信するデータ受信手段と、
前記データ受信手段で受信した前記表示更新用データに前記画像データを特定するための固有値及び前記画像データの両方が含まれている場合には、前記画像データに基づいて前記表示手段に表示する画像を作成する一方、前記データ受信手段で受信した前記表示更新用データに前記画像データを特定する前記固有値のみが含まれており前記画像データが含まれていない場合には、前記テーブル内に保持されているデータと、前記表示更新用データに含まれている前記固有値とを比較して、前記テーブル内に前記固有値と共に保持されている画像データに基づいて前記表示手段に表示する画像を作成する描画作成手段と、
前記描画作成手段で作成された前記画像を前記表示手段に出力する出力手段と、
前記データ受信手段で受信した前記表示更新用データを前記テーブル内の前記データとして登録する追加登録手段とを、
有するクライアント装置が提供される。
【００５５】
また、上記の目的を達成するため、本発明によれば、サーバ装置から受信する画像データに基づいて画像表示を行うリモートデスクトップシステムのクライアント装置であって、
画像表示を行う表示手段と、
前記画像データに対してハッシュ関数による演算を行うことによって得られるハッシュ値を前記画像データの固有値とし、前記画像データを特定するための前記固有値を少なくとも含むデータを保持するためのテーブルを格納するテーブル格納手段と、
前記サーバ装置から、前記表示手段における表示を更新するための表示更新用データを受信するデータ受信手段と、
前記データ受信手段で受信した前記表示更新用データに差分画像データ及び前記差分画像データの配置位置と差分の比較対象となる画像データの固有値と差分合成によって作成される元画像データの固有値とが含まれている場合には、前記テーブル内に保持されているデータと、前記差分の比較対象となる前記画像データの前記固有値とを比較して、前記テーブル内から前記固有値と共に保持されている前記差分の比較対象となる前記画像データを読み出し、読み出された前記画像データの前記配置位置に前記差分画像データを合成して合成画像データを作成し、前記表示更新用データに関して、前記差分画像データ及び前記差分画像データの配置位置と前記テーブル内で発見された前記画像データの前記固有値とを削除するとともに前記合成画像データを挿入して中間データを作成する差分合成手段と、
前記データ受信手段で受信した前記表示更新用データに前記画像データを特定する前記固有値及び前記画像データの両方が含まれている場合には、前記画像データに基づいて前記表示手段に表示する画像を作成し、前記データ受信手段で受信した前記表示更新用データに前記画像データを特定する前記固有値のみが含まれており前記画像データが含まれていない場合には、前記テーブル内に保持されているデータと、前記表示更新用データに含まれている前記固有値とを比較して、前記テーブル内に固有値と共に保持されている画像データに基づいて前記表示手段に表示する画像を作成し、前記差分合成手段で作成された前記表示更新用データに関しては、前記合成画像データに基づいて前記表示手段に表示する画像を作成する描画作成手段と、
前記描画作成手段で作成された前記画像を前記表示手段に出力する出力手段と、
前記描画作成手段で前記画像の作成の際に参照される前記表示更新用データを前記テーブル内の前記データとして登録する追加登録手段とを、
有するクライアント装置が提供される。
【００５６】
また、上記の目的を達成するため、本発明によれば、サーバ装置から受信する画像データに基づいて画像表示を行うリモートデスクトップシステムのクライアント装置であって、
画像表示を行う表示手段と、
前記画像データに対してハッシュ関数による演算を行うことによって得られるハッシュ値を前記画像データの固有値とし、前記画像データを特定するための前記固有値を少なくとも含むデータを保持するためのテーブルを格納するテーブル格納手段と、
前記サーバ装置に対して、前記テーブル格納手段に格納される前記テーブルの上限データ量の値を送信する閾値送信手段と、
前記サーバ装置から、前記表示手段における表示を更新するための描画用の表示更新用データと、前記テーブル格納手段に格納されている前記テーブルの更新用のテーブル更新用データとを受信するデータ受信手段と、
前記データ受信手段で受信した前記表示更新用データに前記画像データを特定するための固有値及び前記画像データの両方が含まれている場合には、前記画像データに基づいて前記表示手段に表示する画像を作成する一方、前記データ受信手段で受信した前記表示更新用データに前記画像データを特定する前記固有値のみが含まれており前記画像データが含まれていない場合には、前記テーブル内に保持されているデータと、前記表示更新用データに含まれている前記固有値とを比較して、前記テーブル内に前記固有値と共に保持されている画像データに基づいて前記表示手段に表示する画像を作成する描画作成手段と、
前記描画作成手段で作成された前記画像を前記表示手段に出力する出力手段と、
前記データ受信手段で受信した前記画像データを特定するための固有値及び前記画像データの両方が含まれている前記テーブル更新用データを前記テーブル内の前記データとして登録する追加登録手段とを、
有するクライアント装置が提供される。
【００５７】
さらに、本発明によれば、上記の構成に加えて、前記テーブル格納手段に前記データを格納する際には、前記テーブル格納手段として使用するメモリのタイプに合わせて変換し、前記テーブル格納手段から前記データを読み出す際には、前記描画作成手段で前記画像の作成の際に参照可能なデータ構造に変換するデータ変換手段を有するクライアント装置が提供される。
【発明の効果】
【００５８】
本発明は、上記の構成を有しており、サーバとクライアントとの間において送受信する描画データ列のデータ量を大幅に削減でき、ＧＵＩの反応速度を向上させてユーザの利便性を向上するとともに、ユーザのストレスを軽減するという効果を有している。また、本発明は、クライアント側に復号化器を搭載させる必要がなく、クライアントの負荷を削減することができるという効果を有している。また、本発明は、異なる領域で同一の更新画像データが存在する場合であっても、新たにテーブルに追加することなく更新表示データを再現することができ、テーブル量を削減することができるという効果を有している。また、本発明は、サーバからクライアントに送信されるデータが全て可逆圧縮であるので、クライアント側で実現される画像データが一様になり、クライアント側で視覚的に安定した表示を実現できるという効果を有している。
【発明を実施するための最良の形態】
【００５９】
以下、図面をしながら、本発明の第１〜第４の実施の形態について説明する。
【００６０】
＜第１の実施の形態＞
まず、本発明の第１の実施の形態について説明する。図１は、本発明の第１の実施の形態におけるリモートデスクトップシステムの一構成例を示すブロック図である。図１に図示されているリモートデスクトップシステムは、サーバＥ０１とクライアントＥ０２とが任意のデータ伝送路を介して接続された構成を有している。
【００６１】
以下、図１に図示されているサーバＥ０１の構成について説明する。図１に図示されているサーバＥ０１は、フレームバッファ４０１、フレーム取得部４０２、比較部４０３、前フレームバッファ４０４、固有値算出部８０１、比較決定部８０２、通信部８０３、テーブル格納部８０４を有している。
【００６２】
図１に図示されているサーバＥ０１のフレームバッファ４０１、フレーム取得部４０２、比較部４０３、前フレームバッファ４０４には、従来の技術で説明した図２６に図示されているＶＮＣサーバＤ０１のフレームバッファ４０１、フレーム取得部４０２、比較部４０３、前フレームバッファ４０４を利用することが可能である。すなわち、図１に図示されているサーバＥ０１の比較部４０３からは、ＶＮＣシステムと同様に、フレーム取得部４０２で取得したフレームバッファ４０１内の画像データと、前フレームバッファ内の画像データ（フレームバッファ４０１内の画像データの更新直前にフレームバッファ４０１内に蓄積されていた画像データ）との比較の結果、これら画像データの差分の描画データが、上述のデータ構造１の形式で出力される。
【００６３】
図１に図示されているサーバＥ０１の比較部４０３から出力されるデータ構造１の形式のデータは、固有値算出部８０１に供給される。固有値算出部８０１は、比較部４０３から供給されるデータ構造１に沿った描画データのビットマップ画像データをハッシュ関数を用いて演算して、そのビットマップ画像データに固有のハッシュ値（以下、固有値と記載する）を算出する。そして、固有値算出部８０１は、描画データを含むデータ構造１のデータと、算出した固有値とを比較決定部８０２に出力する。
【００６４】
なお、固有値を算出するためにハッシュ関数を用いることが好適ではあるが、任意の入力データに対して固有値を算出するような方法であれば、他の方法を用いてもよい。ハッシュ関数を用いることが好適な理由は、以下の通りである。ハッシュ関数は、電子署名などに用いられるＭＤ−５やＳＨＡ−１などのハッシュ関数であり、これらのハッシュ関数は、任意のデータから１２８ビット又は１６０ビットの数値（任意のデータに固有な値）を算出する。このようなハッシュ関数を用いた場合、２つのデータＸ、Ｙが与えられた際には、データＸ、Ｙが同一データであればハッシュ値Ｈ（Ｘ）、Ｈ（Ｙ）も等しくなる。しかしながら、データＸ、Ｙが１ビットでも異なるデータである場合には、ハッシュ値Ｈ（Ｘ）、Ｈ（Ｙ）は異なる数値を取る。なお、原理的には、異なるデータに対してハッシュ値が同一になる場合も生じ得るが、その可能性は極めて低い確率でしか発生しないのがハッシュ関数の特徴である。したがって、異なるデータ同士が同一のハッシュ値を取る可能性は実用上無視できる。ハッシュ関数は、上述のような特性を持った関数であるので、任意のデータから固有値を求める際に有効である。
【００６５】
また、比較決定部８０２は、固有値算出部８０１から供給される描画データを含むデータ構造１のデータ及び固有値を受け取ると、テーブル格納部８０４に格納されているテーブルを使用して、下記のデータ構造２のデータを作成する。
【００６６】
（ビットマップ存在フラグ、画面上のＸ座標、画面上のＹ座標、ビットマップ画像の横幅、ビットマップ画像の高さ、ビットマップ画像、固有値）・・・＜データ構造２＞
【００６７】
上記のように、データ構造２は、ビットマップ存在フラグ、画面上のＸ座標、画面上のＹ座標、ビットマップ画像の横幅、ビットマップ画像の高さ、ビットマップ画像、固有値の各データを挿入するためのフィールドを有している。ビットマップ存在フラグのフィールドは、後続のビットマップ画像のフィールドにビットマップ画像が含まれているか否かを示す１ビットのフィールドである。クライアントＥ０２が有しているテーブルにこのビットマップ画像が保持されていると判断された場合には、ビットマップ存在フラグにビットマップ画像の非存在を示すビット（例えば『０』）がセットされ、ビットマップ画像のフィールドにビットマップ画像が含まれないようにする。一方、クライアントＥ０２が有しているテーブルにこのビットマップ画像が保持されていないと判断された場合には、ビットマップ存在フラグにビットマップ画像の存在を示すビット（例えば『１』）がセットされ、ビットマップ画像のフィールドにビットマップ画像が含まれるようにする。
【００６８】
また、画面上のＸ座標、画面上のＹ座標、ビットマップ画像の横幅、ビットマップ画像の高さの各フィールドは、ビットマップ画像（ビットマップ画像のフィールドに含まれているビットマップ画像又は固有値によって特定されるビットマップ画像）の配置位置を示す配置位置情報である。ここでは、ＶＮＣシステムと同様に上記４つのフィールドを用いているが、ビットマップ画像の配置位置を示すことができれば、任意の情報及び形式を採用することが可能である。
【００６９】
また、固有値のフィールドには、ビットマップ画像から算出された固有値が挿入される。クライアントＥ０２側では、この固有値は、ビットマップ画像を特定するための情報として利用される。
【００７０】
なお、比較決定部８０２は、固有値算出部８０１から受け取った固有値と、テーブル格納部８０４に格納されているテーブル内の固有値との比較結果に基づいて、ビットマップ画像データを含むデータの生成を行うか、ビットマップ画像データを含まないデータの生成を行うかを判断するが、このデータの生成処理に関しては後で詳細に説明する。
【００７１】
また、テーブル格納部８０４には、比較決定部８０２で作成されるデータ構造２に沿ったデータを追加記録するために用意されているテーブルが格納されている。比較決定部８０２は、固有値算出部８０１から固有値及び描画データを受けると、テーブル格納部８０４に格納されているテーブルを使用して、固有値算出部８０１から受けた固有値及び描画データに係るデータ構造２のデータを作成するとともに、作成したデータ構造２のデータ（あるいは、データ構造１のデータ及び固有値）をテーブルに格納する。なお、サーバＥ０１の比較決定部８０２は、固有値の比較によってビットマップ画像データをクライアントに送信するか否かを決定するので、テーブル格納部８０４内のテーブルに固有値のみが保持されても本発明は動作可能である。
【００７２】
テーブル格納部８０４に格納されているテーブルは、上述のように比較決定部８０２で作成されたデータ構造２のデータを保持することができるものであれば任意の形式で実現可能であるが、例えば、テーブルのエントリ（１つのデータ構造２のデータを保持する領域）の最大数を１０００個とし、ＦＩＦＯ（First In First Out）方式でテーブルの更新が行われるようにすることが可能である。
【００７３】
また、通信部８０３は、比較決定部８０２から供給されるデータ構造２に沿ったデータを、例えばＶＮＣプロトコルに変換してクライアントＥ０２に送信する。
【００７４】
次に、図１に図示されているクライアントＥ０２の構成について説明する。図１に図示されているクライアントＥ０２は、通信部８０５、描画作成部８０６、テーブル格納部８０７、フレームバッファ４０８、出力部４０９、ディスプレイ（ビットマップディスプレイ）４１０を有している。
【００７５】
通信部８０５は、サーバＥ０１から送信されるＶＮＣプロトコルに沿ったデータを受信し、データ構造２に沿ったデータに変換して、描画作成部８０６に出力する。
【００７６】
描画作成部８０６は、通信部８０５から供給されるデータ構造２に沿ったデータを受け取ると、通信部８０５から供給されるデータ構造２に沿ったデータ内に含まれているデータ、又はテーブル格納部８０７に格納されているテーブルに保持されているデータ構造２に沿ったデータを使用して画像データを作成し、作成した画像データをフレームバッファ４０８に書き込む。
【００７７】
なお、通信部８０５から供給されるデータにビットマップ画像データが既に含まれている場合には、描画作成部８０６は、この画像データをフレームバッファ４０８に書き込むことになる。描画作成部８０６における画像データの生成処理に関しては後で詳細に説明する。
【００７８】
また、テーブル格納部８０７には、描画作成部８０６が受け取ったデータ構造２に沿ったデータを追加記録するために用意されているテーブルが格納されている。描画作成部８０６は、通信部８０５からデータ構造２のデータを受けると、テーブル格納部８０７に格納されているテーブルを使用して、フレームバッファ４０８に書き込むための画像データを作成するとともに、通信部８０５から受けたデータ構造２のデータをテーブルに格納する。なお、クライアントＥ０２の描画作成部８０６は、固有値の一致するビットマップ画像データをテーブル格納部８０７内のテーブルから読み出す処理を行うので、テーブル格納部８０７内のテーブルにビットマップ画像データ及び固有値のみが保持されても本発明は動作可能である。
【００７９】
テーブル格納部８０４に格納されているテーブルは、サーバＥ０１のテーブル格納部８０４内のテーブルと同様に任意の形式で実現可能である。ただし、サーバＥ０１は、クライアントＥ０２のテーブル格納部８０７に格納されているテーブルに保持されている内容を把握する必要がある。したがって、例えば、サーバＥ０１のテーブル格納部８０４内のテーブルと、クライアントＥ０２のテーブル格納部８０７内のテーブルとは、同一の形式によって作成、保持されるようにすることが望ましい。
【００８０】
次に、図２を参照しながら、図１に図示されているサーバＥ０１の動作の一例について説明する。図２は、本発明の第１の実施の形態におけるサーバの動作の一例を示すフローチャートである。
【００８１】
サーバＥ０１では、ＶＮＣシステムの場合と同様に、フレーム取得部４０２がフレームバッファ４０１から画像データ（描画データ）を取得し（ステップＳ６０１）、画像データを構成する描画データ列の各描画データに関して、ハッシュ関数を用いてビットマップ画像の固有値を算出する（ステップＳ９０１）。なお、上述のように、任意の入力データに対して固有値を算出することが可能であれば、必ずしもハッシュ関数を用いる必要はない。
【００８２】
次に、前フレームバッファ４０４が空か否かを確認することによって、初回の画像データ取得動作か否かの判定が行われる（ステップＳ６０２）。このとき、前フレームバッファ４０４が空の場合（画像データが１度も書き込まれていない場合）には、ステップＳ９０２における比較処理及び変換処理をスキップしてステップＳ９０３に進み、一方、前フレームバッファ４０４が空ではない場合には、ステップＳ９０２に進む。
【００８３】
ステップＳ９０２では、ステップＳ９０１で算出された各ビットマップ画像の固有値とテーブル格納部８０４に格納されているテーブル内の固有値とを比較し、その比較結果に基づいて、データ構造１に沿ったデータ及び固有値をデータ構造２に沿ったデータに変換する処理が行われる。
【００８４】
以下、図３を参照しながら、上記のステップＳ９０２における比較処理及び変換処理の詳細について説明する。図３は、本発明の第１の実施の形態において、サーバの比較決定部で行われる比較処理及び変換処理の一例を示すフローチャートである。
【００８５】
図３において、まず、サーバＥ０１の比較決定部８０２は、固有値算出部８０１から供給される描画データの固有値と、テーブル格納部８０４内のテーブルに保持されている固有値とを比較して、固有値算出部８０１から供給される描画データの固有値と同一のものがテーブル格納部８０４内のテーブルに保持されているか否かを判断する（ステップＳ１１０１）。
【００８６】
ステップＳ１１０１で同一の固有値がテーブルに存在する場合には、データ構造１に沿ったデータに対して、
・ビットマップ存在フラグに、ビットマップ画像の非存在を示す『０』をセット
・データ構造１に沿ったデータに対応する固有値をセット（追加）
・ビットマップ画像データを削除して、ＮＵＬＬを設定
することによって、データ構造２に沿ったデータが作成される（ステップＳ１１０２）。
【００８７】
一方、ステップＳ１１０１で同一の固有値がテーブルに存在しない場合には、データ構造１に沿ったデータに対して、
・ビットマップ存在フラグに、ビットマップ画像の存在を示す『１』をセット
・データ構造１に沿ったデータに対応する固有値をセット（追加）
することによって、データ構造２に沿ったデータが作成される（ステップＳ１１０３）。
【００８８】
なお、図面には反映されていないが、ステップＳ６０２で初回と判定された場合には、すべての描画データ及び固有値がサーバＥ０１からクライアントＥ０２に送信される必要があり、この場合には、上記のステップＳ１１０３に従ってデータ構造２に沿ったデータが作成される。
【００８９】
そして、上述のようにステップＳ１１０２又はＳ１１０３でデータ構造２に沿ったデータが作成された場合や、ステップＳ６０２で初回と判定された場合には、図２に示すように、データ構造２に沿ったデータ（少なくとも固有値）がテーブル格納部８０４のテーブルに追加登録され（ステップＳ９０３）、例えばＶＮＣプロトコルに準拠したデータに変換された後にクライアントＥ０２に送信される（ステップＳ９０４）。また、ＶＮＣシステムと同様に、前フレームバッファ４０４には、今回取得した画像データ（フレームバッファ４０１内の画像データ）が上書きされ（ステップＳ６０５）、ステップＳ６０６において、何らかの終了条件が成立している場合には動作を終了する一方、終了条件が存在しない場合にはステップＳ６０１に戻って上記の処理が繰り返し行われる。
【００９０】
次に、図４を参照しながら、図１に図示されているクライアントＥ０２の動作の一例について説明する。図４は、本発明の第１の実施の形態におけるクライアントの動作の一例を示すフローチャートである。
【００９１】
クライアントＥ０２では、まず、サーバＥ０１から送信されるＶＮＣプロトコルに沿ったデータを受信し、このデータをデータ構造２に沿ったデータに変換する（ステップＳ１００１）。そして、描画作成部８０６において、データ構造２に沿ったデータに含まれているビットマップ画像データ、あるいはテーブル格納部８０７に格納されているテーブル内のビットマップ画像データに基づいて、フレームバッファ４０８に書き込む描画データの作成処理が行われる（ステップＳ１００２）。
【００９２】
以下、図５を参照しながら、上記のステップＳ１００２における描画作成処理の詳細について説明する。図５は、本発明の第１の実施の形態において、クライアントの描画作成部で行われる描画作成処理の一例を示すフローチャートである。
【００９３】
図５において、まず、クライアントＥ０２の描画作成部８０６は、通信部８０５から供給されるデータ構造２に沿ったデータ内のビットマップ存在フラグの値をチェックする（ステップＳ１１５１）。
【００９４】
ステップＳ１１５１でビットマップ存在フラグの値がビットマップ画像の存在を示す『１』の場合、このデータ構造２に沿ったデータにはビットマップ画像データが含まれていることが分かる。この場合には、描画作成部８０６は、サーバＥ０１から受信したデータ構造２に沿ったデータからビットマップ画像データを抽出する（ステップＳ１１５２）。なお、描画作成部８０６は抽出したビットマップ画像データを用いてフレームバッファ４０８への書き込みを行うので、テーブル格納部８０７内のテーブルを参照して描画データの作成を行う必要はない。
【００９５】
一方、ステップＳ１１５１でビットマップ存在フラグの値がビットマップ画像の非存在を示す『０』の場合、このデータ構造２に沿ったデータにはビットマップ画像データは含まれていないことが分かる。この場合には、描画作成部８０６は、サーバＥ０１から受信したデータ構造２に沿ったデータから固有値を抽出し、抽出した固有値に対応するビットマップ画像データをテーブル格納部８０７内のテーブルから取得して、このデータからビットマップ画像データを抽出する（ステップＳ１１５２）。
【００９６】
具体的には、例えばステップＳ１１５２では、描画作成部８０６は、ビットマップ存在フラグが『０』であることを確認した後、データ構造２に沿った入力データの固有値とテーブル格納部８０７内のテーブルに保持されている固有値とを比較して、データ構造２に沿った入力データの固有値と同一の固有値を有するデータ構造２に沿ったデータをテーブルから取得する。そして、取得したデータ構造２に沿ったデータからビットマップ存在フラグ及び固有値を削除して、データ構造１に沿ったデータを作成し、作成したデータの出力を行う。
【００９７】
また、さらに描画作成部８０６は、サーバＥ０１から受信したデータ構造２に沿ったデータ（少なくともビットマップ画像データ及び固有値）をテーブル格納部８０７のテーブルに追加登録する（ステップＳ１００３）。なお、この場合、ビットマップ画像データを含んでいるデータ構造２に沿ったデータのみをテーブルに追加登録してもよい。
【００９８】
図４において、描画作成部８０６は、描画データ列に含まれる描画データを用いて、フレームバッファ４０８に画像データの描画を行う（ステップＳ７０２）。なお、上述のように、図５のステップＳ１１５１でビットマップ存在フラグが『１』であることが確認された場合には、描画作成部８０６は、データ構造２に沿った入力データからビットマップ存在フラグ及び固有値を削除して、データ構造１に沿ったデータを作成し、作成したデータの出力を行い、したがって、描画作成部８０６は、図５のステップＳ１１５１でビットマップ存在フラグが『０』であることが確認された場合には、描画作成部８０６は、図５のステップＳ１１５３で取得したデータに基づくデータ出力を行う。また、出力部４０９は、フレームバッファ４０８を順次読み出し、Ｄ／Ａ変換などの所望の信号処理を行ってディスプレイ４１０への出力を行う（ステップＳ７０３）。また、ステップＳ７０４において、何らかの終了条件が成立している場合には動作を終了する一方、終了条件が存在しない場合にはステップＳ６０１に戻って上記の処理が繰り返し行われる。
【００９９】
以上、説明したように、本発明の第１の実施の形態では、リモートデスクトップシステムにおいて、各描画データから固有値（例えばハッシュ値）を算出して各描画データを固有値と関連付けてテーブルに登録し、このテーブルをサーバ及びクライアントで共有する。これにより、クライアント側のテーブルに保持されているビットマップ画像が表示画像データとして入力された場合に、サーバは、このビットマップ画像の代わりに固有値（さらには、Ｘ座標やＹ座標などの描画位置を指定する情報）を送信することで、クライアントは、この固有値からビットマップ画像（さらには、描画位置）を特定し、表示の更新を行うことが可能となる。この結果、サーバからクライアントに転送される描画データ量が削減される。
【０１００】
＜第２の実施の形態＞
次に、本発明の第２の実施の形態について説明する。図６は、本発明の第２の実施の形態におけるリモートデスクトップシステムの一構成例を示すブロック図である。図６に図示されているリモートデスクトップシステムは、サーバＦ０１とクライアントＦ０２とが任意のデータ伝送路を介して接続された構成を有している。
【０１０１】
以下、図６に図示されているサーバＦ０１の構成について説明する。図６に図示されているサーバＦ０１は、フレームバッファ４０１、フレーム取得部４０２、比較部４０３、前フレームバッファ４０４、固有値算出部８０１、比較決定部１２０１、差分決定部１２０２、通信部１２０３、テーブル格納部１２０４を有している。
【０１０２】
図６に図示されているサーバＦ０１のフレームバッファ４０１、フレーム取得部４０２、比較部４０３、前フレームバッファ４０４には、従来の技術で説明した図２６に図示されているＶＮＣサーバＤ０１のフレームバッファ４０１、フレーム取得部４０２、比較部４０３、前フレームバッファ４０４を利用することが可能である。すなわち、図６に図示されているサーバＦ０１の比較部４０３からは、ＶＮＣシステムと同様に、フレーム取得部４０２で取得したフレームバッファ４０１内の画像データと、前フレームバッファ内の画像データ（フレームバッファ４０１内の画像データの更新直前にフレームバッファ４０１内に蓄積されていた画像データ）との比較の結果、これら画像データの差分の描画データが、上述のデータ構造１の形式で出力される。
【０１０３】
また、図６に図示されている固有値算出部８０１には、図１に図示されている固有値算出部８０１を利用することが可能である。すなわち、図６に図示されているサーバＦ０１の比較部４０３から出力されるデータ構造１の形式のデータは固有値算出部８０１に供給され、固有値算出部８０１において、描画データのビットマップ画像データに対してハッシュ関数を用いた演算が行われて、固有値（ハッシュ値）が算出される。
【０１０４】
図６の構成では、固有値算出部８０１から出力される描画データを含むデータ構造１のデータ及び固有値は、比較決定部１２０１に供給される。比較決定部１２０１は、固有値算出部８０１から供給されるデータ構造１に沿ったデータ及び固有値を受け取ると、テーブル格納部１２０４に格納されているテーブルを使用して、下記のデータ構造３のデータを作成する。
【０１０５】
（ビットマップ存在フラグ、画面上のＸ座標、画面上のＹ座標、ビットマップ画像の横幅、ビットマップ画像の高さ、画像データ（ビットマップ画像、又は、差分ビットマップ画像＋固有値＋差分領域（Ｘ座標、Ｙ座標、横幅、高さ））、固有値、差分データ存在フラグ）・・・＜データ構造３＞
【０１０６】
上記のデータ構造３の各フィールドのうち、ビットマップ存在フラグ、画面上のＸ座標、画面上のＹ座標、ビットマップ画像の横幅、ビットマップ画像の高さ、固有値の各フィールドは、上述のデータ構造２と同一である。
【０１０７】
一方、データ構造３の画像データのフィールドには、上述のデータ構造２の場合のようにビットマップ画像が含まれる場合と、差分ビットマップ画像が含まれる場合とがある。差分ビットマップ画像が含まれる場合には、画像データのフィールドには、この差分ビットマップ画像を特定するための固有値と、この差分ビットマップ画像の配置位置情報とが更に含まれる。また、差分データ存在フラグのフィールドは、画像データのフィールドに差分ビットマップ画像が含まれているか否かを示す１ビットのフィールドである。
【０１０８】
なお、比較決定部１２０１は、固有値算出部８０１から受け取った固有値と、テーブル格納部１２０４に格納されているテーブル内の固有値との比較結果に基づいて、ビットマップ画像データを含むデータの生成を行うか、ビットマップ画像データを含まないデータの生成を行うかを判断する。この比較決定部１２０１の基本的な処理は、図１に図示されている比較処理部８０２に類似しているが、比較決定部１２０１に係る処理に関しては後で詳細に説明する。
【０１０９】
また、差分決定部１２０２は、比較決定部１２０１から供給されるデータ構造３に沿ったデータＡ群と、テーブル格納部１２０４内のテーブルに保持されているデータ構造３に沿ったデータＢ群とを使用して、上記のデータＡ群のデータ量を削減するため、受け取ったデータＡ群と似通ったデータをデータＢ群の中から検索し、これらの差分を求めて、データＡ群のデータ更新を行う機能を有している。なお、差分決定部１２０２におけるデータ更新処理関しては、後で詳細に説明する。
【０１１０】
また、テーブル格納部１２０４には、差分決定部１２０２における更新処理の後に通信部１２０３に出力されるデータ構造３に沿ったデータを追加記録するために用意されているテーブルが格納されている。比較決定部１２０１では、固有値算出部８０１から受けた固有値に一致する固有値を、テーブル格納部１２０４に格納されているテーブル内から検索する処理が行われ、差分決定部１２０２では、データ構造３のデータにビットマップ画像が含まれている場合に、このビットマップ画像に似通った画像をテーブル格納部１２０４に格納されているテーブル内から検索して、これらの画像の差分データを取得してクライアントＦ０２に送信するデータの更新を行うことによって、データ量の削減が行われる。
【０１１１】
テーブル格納部１２０４に格納されているテーブルは、上述のように差分決定部１２０２から出力されるデータ構造３のデータを保持することができるものであれば任意の形式で実現可能であるが、例えば、テーブルのエントリ（１つのデータ構造２のデータを保持する領域）の最大数を１０００個とし、ＦＩＦＯ方式でテーブルの更新が行われるようにすることが可能である。
【０１１２】
また、通信部１２０３は、差分決定部１２０２から供給されるデータ構造３に沿ったデータを、例えばＶＮＣプロトコルに変換してクライアントＦ０２に送信する。
【０１１３】
次に、図６に図示されているクライアントＦ０２の構成について説明する。図６に図示されているクライアントＦ０２は、通信部１２０５、差分合成部１２０６、テーブル格納部１２０７、描画作成部１２０８、フレームバッファ４０８、出力部４０９、ディスプレイ（ビットマップディスプレイ）４１０を有している。
【０１１４】
なお、図６に図示されているクライアントＦ０２のフレームバッファ４０８、出力部４０９、ディスプレイ４１０には、従来の技術で説明した図２６に図示されているＶＮＣサーバＤ０１のフレームバッファ４０８、出力部４０９、ディスプレイ４１０を利用することが可能である。
【０１１５】
通信部１２０５は、サーバＦ０１から送信されるＶＮＣプロトコルに沿ったデータを受信し、データ構造３に沿ったデータに変換して、差分合成部１２０６に出力する。
【０１１６】
また、差分合成部１２０６は、通信部１２０５から供給されるデータの差分データ存在フラグを監視し、差分データ存在フラグが差分データの存在を示すもの（例えば『１』）である場合には、テーブル格納部１２０７に格納されているデータ構造３に沿ったデータを使用してビットマップ画像データを合成する。なお、差分データ存在フラグが差分データの非存在を示すもの（例えば『０』）である場合には、差分合成部１２０６は、通信部１２０５から供給されるデータをそのまま描画作成部１２０８に出力する。また、差分合成部１２０６では、基本的にサーバＦ０１の差分決定部１２０２で行われる変換の逆変換が行われる。差分合成部１２０６における画像データの生成処理に関しては後で詳細に説明する。
【０１１７】
また、描画作成部１２０８は、差分合成部１２０６から供給されるデータ構造３に沿ったデータを受け取ると、テーブル格納部１２０７に格納されているテーブルに保持されているデータ構造３に沿ったデータを使用して画像データを作成し、作成した画像データをフレームバッファ４０８に書き込む。なお、データ構造に違いはあるが、描画作成部１２０８では、基本的に図１に図示されている描画作成部８０６と同様に、差分合成部１２０６から供給されるデータ構造３に沿ったデータ内の固有値に対応するビットマップ画像データを、テーブル格納部１２０７に格納されているテーブルから取得する処理が行われる。
【０１１８】
また、テーブル格納部１２０７には、サーバＦ０１から受信したデータ構造３に沿ったデータを追加記録するために用意されているテーブルが格納されている。なお、データ構造３に沿ったデータは、差分合成部１２０６及び描画作成部１２０８のどちらからテーブルに書き込まれてもよい。また、テーブルには差分ビットマップ画像が保持されるが、差分ビットマップ画像は、サーバＦ０１から受信した状態で保持されてもよく、また、差分の比較対象となったビットマップ画像データ（比較対象データ）に差分ビットマップ画像が合成された状態で保持されてもよい。
【０１１９】
また、テーブル格納部１２０７に格納されているテーブルは、サーバＦ０１のテーブル格納部１２０７内のテーブルと同様に任意の形式で実現可能である。また、例えば、サーバＦ０１のテーブル格納部１２０４内のテーブルと、クライアントＦ０２のテーブル格納部１２０７内のテーブルとは、同一の形式によって作成、保持されるようにすることが望ましい。
【０１２０】
次に、図７を参照しながら、図６に図示されているサーバＦ０１の動作の一例について説明する。図７は、本発明の第２の実施の形態におけるサーバの動作の一例を示すフローチャートである。
【０１２１】
サーバＦ０１では、本発明の第１の実施の形態（図２参照）と同様に、フレーム取得部４０２がフレームバッファ４０１から画像データ（描画データ）を取得し（ステップＳ６０１）、画像データを構成する描画データ列の各描画データに関して、ハッシュ関数を用いてビットマップ画像の固有値を算出し（ステップＳ９０１）、前フレームバッファ４０４が空か否かを確認することによって、初回の画像データ取得動作か否かの判定が行われる（ステップＳ６０２）。このとき、前フレームバッファ４０４が空の場合（画像データが１度も書き込まれていない場合）には、ステップＳ１３０１における比較処理及び変換処理とステップＳ１３０２における差分決定処理をスキップしてステップＳ１３０３に進み、一方、前フレームバッファ４０４が空ではない場合には、ステップＳ１３０１に進む。
【０１２２】
ステップＳ１３０１では、ステップＳ９０１で算出された各ビットマップ画像の固有値とテーブル格納部１２０４に格納されているテーブル内の固有値とを比較し、その比較結果に基づいて、データ構造１に沿ったデータ及び固有値をデータ構造３に沿ったデータに変換する処理が行われる。
【０１２３】
以下、図８を参照しながら、上記のステップＳ１３０１における比較処理及び変換処理の詳細について説明する。図８は、本発明の第２の実施の形態において、サーバの比較決定部で行われる比較処理及び変換処理の一例を示すフローチャートである。
【０１２４】
図８において、まず、サーバＦ０１の比較決定部１２０１は、固有値算出部８０１から供給される描画データの固有値と、テーブル格納部１２０４内のテーブルに保持されている固有値とを比較して、固有値算出部８０１から供給される描画データの固有値と同一のものがテーブル格納部１２０４内のテーブルに保持されているか否かを判断する（ステップＳ１５０１）。
【０１２５】
ステップＳ１５０１で同一の固有値がテーブルに存在する場合には、データ構造１に沿ったデータに対して、
・ビットマップ存在フラグに、ビットマップ画像の非存在を示す『０』をセット
・データ構造１に沿ったデータに対応する固有値をセット（追加）
・ビットマップ画像を削除して、ＮＵＬＬを設定
・差分データ存在フラグに、差分データの非存在を示す『０』をセット
することによって、データ構造３に沿ったデータが作成される（ステップＳ１５０２）。
【０１２６】
一方、ステップＳ１５０１で同一の固有値がテーブルに存在しない場合には、データ構造１に沿ったデータに対して、
・ビットマップ存在フラグに、ビットマップ画像の存在を示す『１』をセット
・データ構造１に沿ったデータに対応する固有値をセット（追加）
・差分データ存在フラグに、差分データの非存在を示す『０』をセット
することによって、データ構造３に沿ったデータが作成される（ステップＳ１５０３）。
【０１２７】
なお、図面には反映されていないが、ステップＳ６０２で初回と判定された場合には、すべての描画データ及び固有値がサーバＦ０１からクライアントＦ０２に送信される必要があり、この場合には、上記のステップＳ１５０３に従ってデータ構造３に沿ったデータが作成されることが望ましい。
【０１２８】
さらに、ステップＳ１３０１の比較処理及び変換処理に続いて、ステップＳ１３０２の差分決定処理が行われる。以下、図９を参照しながら、上記のステップＳ１３０２における差分決定処理の詳細について説明する。図９は、本発明の第２の実施の形態において、サーバの差分決定部で行われる差分決定処理の一例を示すフローチャートである。
【０１２９】
図９において、サーバＦ０１の差分決定部１２０２は、比較決定部１２０１から供給されるデータ構造３に沿ったデータ（図８のステップＳ１５０２又はＳ１５０３で作成されたデータ）内のビットマップ存在フラグの値をチェックする（ステップＳ１６０１）。
【０１３０】
ステップＳ１６０１でビットマップ存在フラグの値がビットマップ画像の存在を示す『１』の場合、このデータ構造２に沿ったデータにはビットマップ画像データが含まれていることが分かる。この場合には、ステップＳ１６０２に進む。一方、ステップＳ１６０１でビットマップ存在フラグの値がビットマップ画像の非存在を示す『０』の場合には、差分決定処理を行う必要はなく差分決定処理は終了となる。
【０１３１】
ビットマップ存在フラグの値がビットマップ画像の存在を示す『１』の場合には、データ構造３に沿った入力データのビットマップ画像の横幅と高さを取得し、テーブル格納部１２０４のテーブル内に同一の横幅及び高さのビットマップ画像データが保持されているか否かの検索が行われる（ステップＳ１６０２）。
【０１３２】
ステップＳ１６０２でテーブル格納部１２０４のテーブル内に同一の横幅及び高さのビットマップ画像データが発見されなかった場合には、差分決定処理は終了となる。一方、ステップＳ１６０２でテーブル格納部１２０４のテーブル内に同一の横幅及び高さのビットマップ画像データが発見された場合には、テーブルから、このビットマップ画像データ及び固有値が取得される（ステップＳ１６０３）。
【０１３３】
そして、ステップＳ１６０３で取得されたビットマップ画像データと、データ構造３に沿った入力データのビットマップ画像データとを比較して、両者の画像データの差分が取得され、差分領域（差分ビットマップ画像の配置位置情報）と、差分ビットマップ画像とが取得される（ステップＳ１６０４）。なお、差分ビットマップ画像の配置位置を定める差分領域としては、例えば画面上のＸ座標、画面上のＹ座標、差分ビットマップ画像の横幅、差分ビットマップ画像の高さが決定される。
【０１３４】
ステップＳ１６０４で差分ビットマップ画像及び差分領域が取得された後、これらの情報に基づいてデータ構造３に沿った入力データが更新される。具体的には、データ構造３に沿った入力データに対して、
・差分データ存在フラグに画像データの存在を示す『１』をセット
・ビットマップ画像の横幅及び高さに『０』をセット
・画像データに、テーブル格納部１２０４のテーブルから検出された比較対象データ（差分の比較対象となったビットマップ画像データ）の固有値、差分ビットマップ画像、差分領域をセット
することによって、データ構造３に沿ったデータが作成される（ステップＳ１６０５）。
【０１３５】
そして、上述のようにステップＳ１５０２、Ｓ１５０３、Ｓ１６０５でデータ構造３に沿ったデータが作成された場合や、ステップＳ６０２で初回と判定された場合には、データ構造３に沿ったデータがテーブル格納部１２０４のテーブルに追加登録され（ステップＳ１３０３）、例えばＶＮＣプロトコルに準拠したデータに変換された後にクライアントＦ０２に送信される（ステップＳ１３０４）。また、ＶＮＣシステムと同様に、前フレームバッファ４０４には、今回取得した画像データ（フレームバッファ４０１内の画像データ）が上書きされ（ステップＳ６０５）、ステップＳ６０６において、何らかの終了条件が成立している場合には動作を終了する一方、終了条件が存在しない場合にはステップＳ６０１に戻って上記の処理が繰り返し行われる。
【０１３６】
次に、図１０を参照しながら、図６に図示されているクライアントＦ０２の動作の一例について説明する。図１０は、本発明の第２の実施の形態におけるクライアントの動作の一例を示すフローチャートである。
【０１３７】
クライアントＦ０２では、まず、サーバＦ０１から送信されるＶＮＣプロトコルに沿ったデータを受信し、このデータをデータ構造３に沿ったデータに変換する（ステップＳ１４０１）。そして、差分合成部１２０６において、データ構造３に沿ったデータに含まれているビットマップ画像データ、テーブル格納部１２０７に格納されているテーブル内のビットマップ画像データ、あるいはデータ構造３に沿ったデータに含まれている差分ビットマップデータ及びテーブル格納部１２０７に格納されているテーブル内のビットマップ画像データに基づいて、差分合成処理及び描画作成処理が行われる（ステップＳ１４０２）。
【０１３８】
以下、図１１を参照しながら、上記のステップＳ１４０２における差分合成処理の詳細について説明する。図１１は、本発明の第２の実施の形態において、クライアントの差分合成部で行われる差分合成処理の一例を示すフローチャートである。
【０１３９】
図１１において、まず、クライアントＦ０２の差分合成部１２０６は、通信部１２０５から供給されるデータ構造３に沿ったデータ内の差分データ存在フラグの値をチェックする（ステップＳ１７０１）。
【０１４０】
ステップＳ１７０１で差分データ存在フラグの値が差分データの非存在を示す『０』の場合、このデータ構造３に沿ったデータには差分データが含まれておらず、差分合成部１２０６での差分合成処理は終了となり、データ構造３に沿ったデータはそのまま描画作成部１２０８に出力される。
【０１４１】
一方、ステップＳ１７０１で差分データ存在フラグの値が差分データの存在を示す『１』の場合には、サーバＦ０１から受信したデータ構造３に沿った入力データに含まれる画像データ内の固有値を取得し、この固有値と同一の固有値を有するデータ構造３に沿ったデータをテーブル内から抽出する（ステップＳ１７０２）。
【０１４２】
次に、ステップ１７０２で抽出されたデータ内のビットマップ画像データをベースにして、サーバＦ０１から受信したデータ構造３に沿った入力データに含まれる差分データの差分領域（Ｘ座標、Ｙ座標、横幅、高さ）に差分ビットマップ画像を上書きし、合成ビットマップ画像を作成する（ステップＳ１７０３）。
【０１４３】
そして、ステップＳ１７０３で作成された合成ビットマップ画像を使用して、サーバＦ０１から受信したデータ構造３に沿った入力データを更新する。具体的には、データ構造３に沿った入力データに対して、
・差分データ存在フラグに画像データの非存在を示す『０』をセット
・画像データの内容を合成ビットマップ画像で書き換え
・ビットマップ画像の横幅及び高さを合成ビットマップ画像の横幅及び高さ（すなわち、ステップＳ１７０２で抽出されたデータのビットマップ画像データ）で書き換え
することによって、データ構造３に沿ったデータが作成されて、描画作成部１２０８に出力される（ステップＳ１７０４）。
【０１４４】
次に、ステップ１７０４で更新されたデータ構造３に沿ったデータ（差分合成処理が行われなかった場合には、データ構造３に沿った入力データ）は、テーブル格納部１２０７内のテーブルに追加登録される（ステップＳ１４０３）。また、上述の差分合成処理を経て差分合成部１２０６からデータ構造３に沿ったデータを受信した描画作成部１２０８では、基本的に図５と同様の処理が行われる。すなわち、描画作成部１２０８では、ビットマップ存在フラグがビットマップ画像の存在を示す『１』の場合には、差分合成部１２０６から受け取ったデータに含まれるビットマップ画像データから描画データが作成され、ビットマップ存在フラグがビットマップ画像の非存在を示す『０』の場合には、差分合成部１２０６から受け取ったデータに含まれる固有値を基にテーブル内でビットマップ画像データの検索が行われ、この検索によって取得されたビットマップ画像データから描画データが作成される。
【０１４５】
上述のように、描画作成部８０６は、描画データ列に含まれる描画データを用いて、フレームバッファ４０８に画像データの描画を行い（ステップＳ７０２）、出力部４０９は、フレームバッファ４０８を順次読み出し、Ｄ／Ａ変換などの所望の信号処理を行ってディスプレイ４１０への出力を行う（ステップＳ７０３）。また、ステップＳ７０４において、何らかの終了条件が成立している場合には動作を終了する一方、終了条件が存在しない場合にはステップＳ６０１に戻って上記の処理が繰り返し行われる。
【０１４６】
また、図１２には、本発明の第２の実施の形態における差分合成の概要が図示されている。例えば、ディスプレイに表示されている開始ボタン３１０１の表示が、終了ボタン３１０２の表示に変更された場合、サーバＦ０１では、終了の文字の部分のみの差分ビットマップ画像３１０３が取得され、データ構造３のデータの画像データには、この差分ビットマップ画像３１０３、差分ビットマップ画像３１０３の配置位置、開始ボタン３１０１の固有値が挿入されて、サーバＦ０１からクライアントＦ０２に送信される。一方、クライアントＦ０２は、このデータ構造３に沿ったデータを受信すると、テーブル格納部１２０７に格納されている開始ボタン３１０１のビットマップ画像を取得して、差分ビットマップ画像３１０３を合成することで、終了ボタン３１０２の画像データを作成する。本発明の第１の実施の形態では、このような表示変更の際に、終了ボタン３１０２の画像データが送信されていたことに比べて、本発明の第２の実施の形態では、よりデータ量の小さな差分ビットマップ画像３１０３が送信されることとなり、サーバＦ０１からクライアントＦ０２に転送される描画データ量が大きく削減されるようになる。
【０１４７】
以上、説明したように、本発明の第２の実施の形態では、リモートデスクトップシステムにおいて、各描画データから固有値（例えばハッシュ値）を算出して各描画データを固有値と関連付けてテーブルに登録し、このテーブルをサーバ及びクライアントで共有するとともに、共有されている画像の一部のみが更新されるような表示変更に関しては、サーバは、その差分ビットマップ画像をクライアントに送信する。これにより、クライアント側のテーブルに保持されているビットマップ画像の一部のみを更新する表示変更に関しては、サーバは、この差分ビットマップ画像（さらには、差分対象となるビットマップ画像の固有値や描画位置）を送信することで、クライアントは、合成ビットマップ画像を作成して表示の更新を行うことが可能となる。この結果、サーバからクライアントに転送される描画データ量が削減される。
【０１４８】
＜第３の実施の形態＞
次に、本発明の第３の実施の形態について説明する。図１３は、本発明の第３の実施の形態におけるリモートデスクトップシステムの一構成例を示すブロック図である。図１３に図示されているリモートデスクトップシステムは、サーバＧ０１とクライアントＧ０２とが任意のデータ伝送路を介して接続された構成を有している。
【０１４９】
以下、図１３に図示されているサーバＧ０１の構成について説明する。図１３に図示されているサーバＧ０１は、フレームバッファ４０１、フレーム取得部４０２、比較部４０３、前フレームバッファ４０４、固有値算出部８０１、比較決定部８０２、テーブル格納部８０４、データ変換部１８０１、通信部１８０２を有している。
【０１５０】
図１３に図示されているサーバＧ０１のフレームバッファ４０１、フレーム取得部４０２、比較部４０３、前フレームバッファ４０４、固有値算出部８０１、比較決定部８０２、テーブル格納部８０４には、図１に図示されているフレームバッファ４０１、フレーム取得部４０２、比較部４０３、前フレームバッファ４０４、固有値算出部８０１、比較決定部８０２、テーブル格納部８０４を利用することが可能である。すなわち、図１３に図示されているサーバＧ０１の比較決定部８０２からは、描画データが上述のデータ構造２の形式で出力される。
【０１５１】
図１３に図示されているサーバＧ０１の比較決定部８０２から出力されるデータ構造２の形式のデータは、データ変換部１８０１に供給される。データ変換部１８０１は、比較決定部８０２から供給されるデータ構造２のデータをビットマップ画像に変換して、下記のデータ構造４のデータを作成して、通信部１８０２に出力する。
【０１５２】
（データ構造２のデータがビットマップ画像に変換されたビットマップ画像データ）・・・＜データ構造４＞
【０１５３】
なお、ここでは、データ構造２のデータをビットマップ画像であるデータ構造４のデータに変換しているが、ビットマップ以外のデータに変換してもよい。また、クライアントＧ０２の要求するデータ型に変換してもよい。
【０１５４】
また、通信部１８０２は、データ変換部１８０１から供給されるデータ構造４に沿ったデータを、例えばＶＮＣプロトコルに変換してクライアントＧ０２に送信する。
【０１５５】
次に、図１３に図示されているクライアントＧ０２の構成について説明する。図１３に図示されているクライアントＧ０２は、通信部１８０３、データ変換部１８０４、クライアントバッファ１８０５、描画作成部１８０６、フレームバッファ４０８、出力部４０９、ディスプレイ（ビットマップディスプレイ）４１０を有している。
【０１５６】
なお、図１３に図示されているクライアントＧ０２のフレームバッファ４０８、出力部４０９、ディスプレイ４１０には、従来の技術で説明した図２６に図示されているＶＮＣクライアントＤ０２のフレームバッファ４０８、出力部４０９、ディスプレイ４１０を利用することが可能である。
【０１５７】
通信部１８０３は、サーバＧ０１から送信されるＶＮＣプロトコルに沿ったデータを受信し、データ構造４に沿ったデータに変換して、データ変換部１８０４に出力する。
【０１５８】
データ変換部１８０４は、通信部１８０３から供給されたデータ構造４に沿ったデータを、データ構造２に沿ったデータに変換し、さらに、変換によって作成されたデータ構造２のデータにテーブルフラグを付加して、下記のデータ構造５に沿ったデータを作成するとともに、テーブルフラグにこのデータがサーバＧ０１から受信したものであることを示す『０』をセットして、描画作成部１８０６に出力する。なお、以下では、データ変換部１８０４が、サーバＧ０１から通信部１８０３を介して受信したデータ構造４のデータを、テーブルフラグが『０』にセットされたデータ構造５のデータに変換するデータ変換処理を第１のデータ変換処理と呼ぶことにする。
【０１５９】
（テーブルフラグ、ビットマップ存在フラグ、画面上のＸ座標、画面上のＹ座標、ビットマップ画像の横幅、ビットマップ画像の高さ、ビットマップ画像、固有値）・・・＜データ構造５＞
【０１６０】
データ構造５は、データ構造２のデータにテーブルフラグのフィールドが付加された構造を有している。テーブルフラグは、対応するデータ構造２のデータが通信部１８０３を介してサーバＧ０１から受信したデータであるのか、あるいはクライアントバッファ１８０５から読み出されたデータであるのかを識別するために付加される情報であり、例えば、サーバＧ０１から受信したデータにはテーブルフラグ『０』がセットされ、クライアントバッファ１８０５から読み出されたデータにはテーブルフラグ『１』がセットされる。
【０１６１】
なお、このテーブルフラグは、描画作成部１８０６が上記のいずれに該当するデータであるのかを識別するために付加される情報の一例であるが、例えば、通信部１８０３及びクライアントバッファ１８０５のそれぞれから描画作成部１８０６に到来するデータのデータ入力口を分けるなど、描画作成部１８０６がデータの由来を確実に把握することが可能であれば、テーブルフラグは必ずしも付加される必要はない。
【０１６２】
また、データ変換部１８０４は、描画作成部１８０６の命令によってクライアントバッファ１８０５から読み出されたデータ構造４のデータを受けて、このデータをデータ構造５のデータに変換するとともに、テーブルフラグにこのデータがクライアントバッファ１８０５から読み出されたものであることを示す『１』をセットして、描画作成部１８０６に出力する。なお、以下では、データ変換部１８０４が、クライアントバッファ１８０５から読み出されたデータ構造４のデータを、テーブルフラグが『１』にセットされたデータ構造５のデータに変換するデータ変換処理を第２のデータ変換処理と呼ぶことにする。
【０１６３】
また、データ変換部１８０４は、描画作成部１８０６から書き込み命令と共に渡されたデータ構造２のデータをデータ構造４のデータに変換してクライアントバッファ１８０５に書き込む。なお、以下では、データ変換部１８０４が、描画作成部１８０６から渡されたデータ構造２のデータを、クライアントバッファ１８０５に書き込むためにデータ構造４のデータに変換するデータ変換処理を第３のデータ変換処理と呼ぶことにする。
【０１６４】
なお、ここでは、１つのデータ変換部１８０４が上述の第１〜第３のデータ変換処理を行う機能を有しているが、複数のデータ変換部１８０４を設けて上述の第１〜第３のデータ変換処理をそれぞれ分担して行うようにしてもよい。
【０１６５】
また、クライアントバッファ１８０５は、クライアントＧ０２の所持するメモリであり、例えばデジタルテレビなどのようなデコーダの搭載されている表示機器の場合には、このデコーダのフレームバッファが利用可能である。このクライアントバッファ１８０５は、ビットマップ画像メモリであり、データ構造４のデータを保持することが可能である。
【０１６６】
また、描画作成部１８０６は、サーバＧ０１から受信したことを示すテーブルフラグ『０』が付加されたデータ構造５のデータをデータ変換部１８０４から受け取ると、このデータに基づいて画像データを作成し、作成した画像データをフレームバッファ４０８に書き込む。
【０１６７】
また、描画作成部１８０６は、クライアントバッファ１８０５からデータ変換部１８０４経由で所望のデータの読み出しを行い、データ変換部１８０４で上記の第２のデータ変換処理を経て作成されたテーブルフラグ『１』が付加されたデータ構造５のデータを受け取る。さらに、描画作成部１８０６は、このテーブルフラグ『１』が付加されたデータを一時的に保持するためのキャッシュを有している。
【０１６８】
次に、図１４を参照しながら、図１３に図示されているサーバＧ０１の動作の一例について説明する。図１４は、本発明の第３の実施の形態におけるサーバの動作の一例を示すフローチャートである。
【０１６９】
サーバＧ０１では、本発明の第１の実施の形態（図２参照）と同様に、フレーム取得部４０２がフレームバッファ４０１から画像データ（描画データ）を取得し（ステップＳ６０１）、画像データを構成する描画データ列の各描画データに関して、ハッシュ関数を用いてビットマップ画像の固有値を算出し（ステップＳ９０１）、前フレームバッファ４０４が空か否かを確認することによって、初回の画像データ取得動作か否かの判定が行われる（ステップＳ６０２）。このとき、前フレームバッファ４０４が空の場合（画像データが１度も書き込まれていない場合）には、ステップＳ９０２における比較処理及び変換処理をスキップしてステップＳ９０３のテーブルへの追加登録処理が行われる。一方、前フレームバッファ４０４が空ではない場合には、ステップＳ９０２の比較処理及び変換処理を経てステップＳ９０３のテーブルへの追加登録処理が行われる。なお、ここまでは、本発明の第１の実施の形態に係る処理と同一である。
【０１７０】
上述の処理の後、データ変換部１８０４は、データ構造２に沿ったデータをビットマップ画像に変換して、データ構造４に沿ったデータを作成する（ステップＳ１９０１）。そして、ステップＳ１９０１で作成されたデータ構造４に沿ったデータは、例えばＶＮＣプロトコルに準拠したデータに変換された後にクライアントＧ０２に送信される（ステップＳ１９０２）。また、ＶＮＣシステムと同様に、前フレームバッファ４０４には、今回取得した画像データ（フレームバッファ４０１内の画像データ）が上書きされ（ステップＳ６０５）、ステップＳ６０６において、何らかの終了条件が成立している場合には動作を終了する一方、終了条件が存在しない場合にはステップＳ６０１に戻って上記の処理が繰り返し行われる。
【０１７１】
次に、図１５を参照しながら、図１３に図示されているクライアントＧ０２の動作の一例について説明する。図１５は、本発明の第３の実施の形態におけるクライアントの動作の一例を示すフローチャートである。
【０１７２】
クライアントＧ０２では、サーバＧ０１から送信されるＶＮＣプロトコルに沿ったデータを受信した場合、データ変換部１８０４が、このデータをデータ構造４に沿ったデータに変換する（ステップＳ２００１）。さらに、データ変換部１８０４において、ビットマップ画像であるデータ構造４のデータは、データ構造５に沿ったデータに変換されて、描画作成部１８０６に渡される（ステップＳ２００２）。なお、ここで描画作成部１８０６に渡されるデータ構造５のデータにはテーブルフラグ『０』がセットされる。
【０１７３】
一方、描画作成部１８０６は、クライアントバッファ１８０５から読み出してデータ変換部１８０６から受け取ったデータ構造５のデータを一時的にキャッシュする（ステップＳ２００３）。なお、ここで描画作成部１８０６に渡されるデータ構造５のデータにはテーブルフラグ『１』がセットされており、描画作成部１８０６はこのテーブルフラグ『１』を参照してキャッシュを行う。
【０１７４】
そして、描画作成部１８０６において、データ構造５に沿ったデータに含まれているビットマップ画像データ、あるいはキャッシュに格納されているテーブル内のビットマップ画像データに基づいて、フレームバッファ４０８に書き込む描画データの作成処理が行われる（ステップＳ２００４）。
【０１７５】
以下、図１６を参照しながら、上記のステップＳ２００４における描画作成処理の詳細について説明する。図１６は、本発明の第３の実施の形態において、クライアントの描画作成部で行われる描画作成処理の一例を示すフローチャートである。
【０１７６】
図１６において、まず、クライアントＧ０２の描画作成部１８０６は、通信部１８０５から供給されるテーブルフラグ『０』がセットされたデータ構造５に沿ったデータ内のビットマップ存在フラグの値をチェックする（ステップＳ２１０１）。
【０１７７】
ステップＳ２１０１でテーブルフラグ『０』がセットされたデータ構造５に沿ったデータ内のビットマップ存在フラグの値が『０』の場合には、描画作成部１８０６は、このデータ構造５に沿ったデータに含まれている固有値を取得して（ステップＳ２１０２）、キャッシュされているデータ構造５のデータ（ステップＳ２００３でキャッシュされたデータ構造５のデータ）の中から、ステップ２１０２で取得した固有値と同一の固有値を有するデータを検索し、同一の固有値を有するデータに含まれるビットマップ画像データを取得する（ステップＳ２１０３）。なお、ステップＳ２１０３における検索の際に、クライアントバッファ１８０５からのデータ読み出し及びキャッシュ処理（ステップＳ２００３に対応する処理）が行われてもよい。
【０１７８】
そして、描画作成部１８０６は、通信部１８０３から供給されたテーブルフラグ『０』がセットされたデータ構造５に沿ったデータのテーブルフラグ及びビットマップ存在フラグを削除するとともに、ステップＳ２１０３で取得したビットマップ画像データをセットして、データ構造１に沿ったデータを作成する（ステップＳ２１０４）。このデータ構造１に沿ったデータがフレームバッファ４０８に書き込まれる。
【０１７９】
一方、ステップＳ２１０１でテーブルフラグ『０』がセットされたデータ構造５に沿ったデータ内のビットマップ存在フラグの値が『１』の場合には、このテーブルフラグ『１』がセットされたデータ構造５に沿ったデータのテーブルフラグ及びビットマップ存在フラグを削除して、データ構造１に沿ったデータを作成する（ステップＳ２１０５）。また、さらに描画作成部１８０６は、通信部１８０３から供給されたデータ構造５に沿ったデータのテーブルフラグを削除して、データ構造２に沿ったデータを作成し、このデータをデータ構造４のデータとしてクライアントバッファ１８０５に書き込む（ステップＳ２１０６）。なお、上述のように、描画作成部１８０６から出力されたデータ構造２に沿ったデータは、データ変換部１８０４における第３のデータ変換処理を経てデータ構造４のデータに変換され、クライアントバッファ１８０５に書き込まれる。
【０１８０】
また、さらに描画作成部１８０６は、ステップＳ２００３でデータ変換部１８０４から受けたデータ構造５に沿ったデータのテーブルフラグのフィールドを削除してデータ構造２のデータを作成し、このデータ構造２のデータをデータ変換部１８０４を介してクライアントバッファ１８０５に書き込む（ステップＳ２００５）。なお、このとき、データ変換部１８０４では上述の第３のデータ変換処理が行われ、クライアントバッファ１８０５には、ビットマップ画像であるデータ構造４のデータとして書き込みが行われる。
【０１８１】
その後の処理は、本発明の第１の実施の形態（図４参照）と同様である。すなわち、描画作成部１８０６は、描画データ列に含まれる描画データを用いて、フレームバッファ４０８に画像データの描画を行い（ステップＳ７０２）、出力部４０９は、フレームバッファ４０８を順次読み出し、Ｄ／Ａ変換などの所望の信号処理を行ってディスプレイ４１０への出力を行う（ステップＳ７０３）。また、ステップＳ７０４において、何らかの終了条件が成立している場合には動作を終了する一方、終了条件が存在しない場合にはステップＳ２００１に戻って上記の処理が繰り返し行われる。
【０１８２】
以上、説明したように、本発明の第３の実施の形態では、リモートデスクトップシステムにおいて、各描画データから固有値（例えばハッシュ値）を算出して各描画データを固有値と関連付けてテーブルに登録し、このテーブルをサーバ及びクライアントで共有する。この際、クライアントがあらかじめ持っているメモリ（例えば、デジタルテレビにおけるデコーダのフレームバッファ）に格納できるような形式にサーバ側でデータ変換を行うことによって、クライアントがどのようなタイプのメモリを所有している場合でも、余分なメモリを付加することなくテーブルの保持を行うことができ、省資源化及び低コスト化を実現することが可能となる。
【０１８３】
＜第４の実施の形態＞
次に、本発明の第４の実施の形態について説明する。図１７は、本発明の第４の実施の形態におけるリモートデスクトップシステムの一構成例を示すブロック図である。図１７に図示されているリモートデスクトップシステムは、サーバＨ０１とクライアントＨ０２とが任意のデータ伝送路を介して接続された構成を有している。
【０１８４】
以下、図１７に図示されているサーバＨ０１の構成について説明する。図１７に図示されているサーバＨ０１は、フレームバッファ４０１、フレーム取得部４０２、比較部４０３、前フレームバッファ４０４、固有値算出部８０１、比較決定部２２０１、データ作成部２２０２、更新待ちテーブル格納部２２０３、テーブル更新制御部２２０４、テーブル格納部２２０５、通信部２２０６を有している。
【０１８５】
図１７に図示されているサーバＨ０１のフレームバッファ４０１、フレーム取得部４０２、比較部４０３、前フレームバッファ４０４、固有値算出部８０１には、図１に図示されているフレームバッファ４０１、フレーム取得部４０２、比較部４０３、前フレームバッファ４０４、固有値算出部８０１を利用することが可能である。すなわち、図１７に図示されているサーバＨ０１の固有値算出部８０１からは、データ構造１のデータ及び固有値が出力される。
【０１８６】
図１７に図示されているサーバＨ０１の固有値算出部８０１から出力されるデータ構造１のデータ及び固有値は、比較決定部２２０１に供給される。比較決定部２２０１は、図１に図示されている比較決定部８０２とほぼ同一の機能を有しているが、出力するデータ構造の形式が異なっている。すなわち、比較決定部２２０１は、固有値算出部８０１から供給される描画データを含むデータ構造１のデータ及び固有値を受け取ると、テーブル格納部２２０５に格納されているテーブル（データ構造２のデータを格納）を使用して、下記のデータ構造６のデータを作成する。この比較決定部２２０１で作成されたデータ構造６に沿ったデータは、データ作成部２２０２及び通信部２２０６に出力される。
【０１８７】
（テーブル送信フラグ、更新時刻、ビットマップ存在フラグ、画面上のＸ座標、画面上のＹ座標、ビットマップ画像の横幅、ビットマップ画像の高さ、ビットマップ画像、固有値）・・・＜データ構造６＞
【０１８８】
データ構造６は、データ構造２のデータにテーブル送信フラグ及び更新時間のフィールドが付加された構造を有している。テーブル送信フラグのフィールドには、クライアントＨ０２に対して、このデータが描画用のものであるかテーブル更新用のものであるかを示すためのフラグがセットされる。なお、比較決定部２２０１は、このテーブル送信フラグ内に、このデータが描画用のものであることを示すフラグ『０』をセットして、データ作成部２２０２及び通信部２２０６に出力する。また、更新時刻のフィールドには、このデータの処理時刻（例えば、比較決定部２２０１で処理された際の現在時刻）がセットされる。なお、更新時刻のフィールドには、処理されるデータの順序が把握できる情報（例えば、シーケンスナンバー）などがセットされてもよい。
【０１８９】
また、データ作成部２２０２は、比較決定部２２０１から供給されるデータ構造６に沿ったデータを受け取ると、このデータ構造６に沿ったデータに対応して更新待ちテーブル格納部２２０３に格納されている更新待ちテーブル（下記のデータ構造７のデータを格納）の更新処理又は追加登録処理を行う。
【０１９０】
（更新時刻、テーブル存在フラグ、ビットマップ存在フラグ、画面上のＸ座標、画面上のＹ座標、ビットマップ画像の横幅、ビットマップ画像の高さ、ビットマップ画像、固有値）・・・＜データ構造７＞
【０１９１】
データ構造７は、データ構造２のデータに更新時刻及びテーブル存在フラグのフィールドが付加された構造を有している。更新時刻のフィールドには、比較決定部２２０１から供給されたデータ構造６のデータに含まれている更新時刻がそのままセットされるか、あるいは、データ作成部２２０２における処理時刻（現在時刻）がセットされる。また、テーブル存在フラグのフィールドは、このデータに係るエントリが既にテーブル格納部２２０５内のテーブルに格納されているか否かを示すフラグである。例えば、データ作成部２２０２は、比較決定部２２０１から供給されたデータ構造６のデータに含まれているビットマップ存在フラグを参照して、ビットマップ存在フラグがビットマップ画像データの存在を示す『１』の場合には、テーブル格納部２２０５内のテーブルにおける非存在を示すテーブル存在フラグ『０』をセットし、ビットマップ存在フラグがビットマップ画像データの非存在を示す『０』の場合には、テーブル格納部２２０５内のテーブルにおける存在を示すテーブル存在フラグ『１』をセットする。
【０１９２】
また、更新待ちテーブル格納部２２０３には、データ構造７のデータを追加記録するために用意されているテーブル（更新待ちテーブル）が格納されている。なお、上述のように、更新待ちテーブル格納部２２０３内の更新待ちテーブルは、データ作成部２２０２によって更新又は追加登録され、また、テーブル更新制御部２２０４によって読み出される。なお、更新待ちテーブル格納部２２０３が格納可能な更新待ちテーブルの最大容量は、テーブル格納部２２０５が格納可能なテーブルの最大容量よりも大きいことが望ましい。また、更新待ちテーブル格納部２２０３に格納されているテーブルは、上述のようにデータ構造７のデータを保持することができるものであれば任意の形式で実現可能である。
【０１９３】
また、テーブル更新制御部２２０４は、例えば、所定の更新時間ごとや更新待ちテーブル格納部２２０３における所定容量以上のデータ格納などのタイミングで、更新待ちテーブル格納部２２０３内の更新待ちテーブルに基づいて、テーブル格納部２２０５内のテーブルを更新するためのデータ（データ構造２のデータ）の作成を行うとともに、通信部２２０６を介してクライアントＨ０２に送信するデータ（テーブル更新用のものであることを示すテーブル送信フラグ『１』がセットされたデータ構造６のデータ）の作成を行う。なお、テーブル更新制御部２２０４におけるテーブル更新処理に関しては後で詳細に説明する。
【０１９４】
また、テーブル格納部２２０５には、データ構造２のデータを追加記録するために用意されているテーブルが格納されている。このテーブル格納部２２０５内のテーブルは、テーブル更新制御部２２０４によって更新され、比較決定部２２０１によって参照される。なお、テーブル格納部２２０５に格納されているテーブルは、上述のようにデータ構造２のデータを保持することができるものであれば任意の形式で実現可能である。
【０１９５】
また、通信部２２０６は、比較決定部２２０１又はテーブル更新制御部２２０４から供給されるデータ構造６に沿ったデータを、例えばＶＮＣプロトコルに変換してクライアントＨ０２に送信する。
【０１９６】
次に、図１７に図示されているクライアントＨ０２の構成について説明する。図１７に図示されているクライアントＨ０２は、通信部２２０７、描画作成部２２０８、テーブル作成部２２０９、テーブル格納部２２１０、フレームバッファ４０８、出力部４０９、ディスプレイ（ビットマップディスプレイ）４１０を有している。
【０１９７】
なお、図１７に図示されているクライアントＨ０２のフレームバッファ４０８、出力部４０９、ディスプレイ４１０には、従来の技術で説明した図２６に図示されているＶＮＣサーバＤ０１のフレームバッファ４０８、出力部４０９、ディスプレイ４１０を利用することが可能である。
【０１９８】
通信部２２０７は、サーバＨ０１から送信されるＶＮＣプロトコルに沿ったデータを受信し、データ構造６に沿ったデータに変換するとともに、このデータ構造６のデータ内のテーブル送信フラグを参照して、テーブル送信フラグが『０』の場合にはデータを描画作成部２２０８に出力し、テーブル送信フラグが『１』の場合にはデータをテーブル作成部２２０９に出力する。
【０１９９】
また、描画作成部２２０８は、図１に図示されている描画作成部８０６と同様に、通信部２２０７から供給されるデータ構造６に沿ったデータを受け取ると、このデータ内に含まれている画像データ、又はテーブル格納部２２１０に格納されているテーブルに保持されているデータ構造６に沿ったデータを使用して画像データを作成し、作成した画像データをフレームバッファ４０８に書き込む。さらに、描画作成部２２０８は、ビットマップ画像データの非存在を示すビットマップ存在フラグが『０』にセットされているデータ構造６のデータを受けた場合には、このデータに対応したテーブル格納部２２１０内のテーブルのデータ（互いの固有値が同一のデータ）の更新時刻を、通信部２２０７から受信したデータ構造６のデータに含まれている更新時刻に置き換えることが望ましい。
【０２００】
また、テーブル作成部２２０９は、通信部２２０７から供給されるデータ構造６に沿ったデータを受け取ると、テーブル格納部２２１０に格納されているテーブルへの追加登録処理を行う。また、さらにテーブル作成部２２０９は、例えば一致時間ごとにテーブル格納部２２１０内のテーブルの容量（総データ量）を監視し、テーブルが所定容量以下となるように更新処理を行う。また、テーブル作成部２２０９は、通信部２２０７を通じてサーバＨ０１に対して、テーブル格納部２２１０内で格納可能なテーブルの最大容量（あるいは上記の所定容量）を通知する。
【０２０１】
また、テーブル格納部２２１０には、データ構造６のデータを追加記録するために用意されているテーブルが格納されている。このテーブル格納部２２１０内のテーブルは、描画作成部２２０８又はテーブル作成部２２０９によって更新され、描画作成部２２０８によって参照される。なお、本発明の第４の実施の形態における動作によって、クライアントＨ０２のテーブル格納部２２１０内のテーブルは、サーバＨ０１のテーブル格納部２２０５内のテーブルと同期している。また、テーブル格納部２２０５に格納されているテーブルは、上述のようにデータ構造６のデータを保持することができるものであれば任意の形式で実現可能である。
【０２０２】
次に、図１８を参照しながら、図１７に図示されているサーバＨ０１の動作の一例について説明する。図１８は、本発明の第４の実施の形態におけるサーバの動作の一例を示すフローチャートである。
【０２０３】
サーバＨ０１では、本発明の第１の実施の形態（図２参照）と同様に、フレーム取得部４０２がフレームバッファ４０１から画像データ（描画データ）を取得し（ステップＳ６０１）、画像データを構成する描画データ列の各描画データに関して、ハッシュ関数を用いてビットマップ画像の固有値を算出し（ステップＳ９０１）、前フレームバッファ４０４が空か否かを確認することによって、初回の画像データ取得動作か否かの判定が行われる（ステップＳ６０２）。  ステップＳ６０２で前フレームバッファ４０４が空ではない場合にはステップＳ２３０１に進み、ステップＳ６０２で前フレームバッファ４０４が空の場合にはステップＳ２３０２に進む。
【０２０４】
ステップＳ２３０１では、ステップＳ９０１で算出された各ビットマップ画像の固有値とテーブル格納部２２０５に格納されているテーブル内の固有値とを比較し、その比較結果に基づいて、データ構造１に沿ったデータ及び固有値をデータ構造６に沿ったデータに変換する処理が行われる。なお、上述のように、データ構造６のデータのテーブル送信フラグには、描画用のデータであることを示す値『０』がセットされる。
【０２０５】
なお、図面には反映されていないが、ステップＳ６０２で初回と判定された場合には、すべての描画データ及び固有値がサーバＨ０１からクライアントＨ０２に送信される必要があり、この場合には、テーブル送信フラグ『０』がセットされビットマップ画像データが含まれているデータ構造７のデータが作成される。
【０２０６】
また、ステップＳ２３０２では、作成されたデータ構造７のデータが更新待ちテーブル格納部２２０３内の更新待ちテーブルに追加登録される。
【０２０７】
また、テーブル更新制御部２２０４は、常に更新待ちテーブル又は所定のタイマ（不図示）を監視しており、テーブル格納部２２０５内のテーブルの更新タイミングであるか否かの判断を行っている（ステップＳ２３０３）。ステップＳ２３０３でテーブルの更新タイミングであると判断された場合にはステップＳ２３０４に進み、ステップＳ２３０３でテーブルの更新タイミングではないと判断された場合にはステップＳ２３０６に進む。
【０２０８】
ステップＳ２３０３でテーブルの更新タイミングであると判断された場合には、テーブル更新制御部２２０４は、更新待ちテーブル格納部２２０３内の更新待ちテーブル及びテーブル格納部２２０５内のテーブルの作成処理を行う（ステップＳ２３０４）とともに、テーブル更新処理を行う（ステップＳ２３０５）。
【０２０９】
以下、図１９を参照しながら、上記のステップＳ２３０３〜Ｓ２３０５における処理の詳細について説明する。図１９は、本発明の第４の実施の形態において、サーバのテーブル更新制御部で行われるテーブル作成処理及びテーブル更新処理の一例を示すフローチャートである。
【０２１０】
図１９において、まず、サーバＨ０１のテーブル更新制御部２２０４は、タイマなどを用いて、前回テーブルを更新した時間からあらかじめ予め設定された所定時間ＴＨ１が経過しているかどうかを判断する（ステップＳ２５０１）。ステップＳ２５０１で所定時間ＴＨ１が経過していないと判断された場合には、テーブルの更新処理は終了となる。
【０２１１】
一方、ステップＳ２５０１で所定時間ＴＨ１が経過したと判断された場合には、ステップＳ２５０２に進み、更新待ちテーブルのデータ量（テーブル量）が所定の限界容量ＴＨ２を超えているか否かを判断する。なお、限界容量ＴＨ２は、クライアントＨ０２から通知された値に基づいて設定されてもよく、初めから固定した値に設定されていてもよい。ステップＳ２５０２で更新待ちテーブルのデータ量がクライアントＨ０２の限界容量ＴＨ２を超えていると判断された場合にはステップＳ２５０３に進み、更新待ちテーブルのデータ量がクライアントＨ０２の限界容量ＴＨ２を超えていないと判断された場合には、ステップＳ２５０３、Ｓ２５０４の更新待ちテーブルの最適化処理をスキップしてステップＳ２５０５に進む。
【０２１２】
ステップＳ２５０２で更新待ちテーブルのデータ量がクライアントＨ０２の限界容量ＴＨ２を超えていると判断された場合、テーブル更新制御部２２０４は、更新待ちテーブル内のデータを更新時刻の新しい順に並べ替え（ステップＳ２５０３）、並べ替えた更新待ちテーブルのデータ量が限界容量ＴＨ２以下になるまで、更新時刻の古い順にデータの削除を行う（ステップＳ２５０４）。
【０２１３】
続いて、テーブル更新制御部２２０４は、更新待ちテーブル内のデータをコピーして、２つのコピーデータ（コピーデータ１及びコピーデータ２）を作成する（ステップ２５０５）。これら２つのコピーデータは、それぞれクライアントＨ０２への送信用及びテーブル格納部２２０５に格納されているテーブルの更新用に用いられる。
【０２１４】
一方のコピーデータ１に関しては、テーブル更新制御部２２０４は、コピーデータ１（データ構造７に沿ったデータ）のテーブル存在フラグを削除するとともに、テーブル更新用のものであることを示す値『１』がセットされたテーブル送信フラグを付加して、データ構造６に沿ったデータを作成する（ステップＳ２５０６）。
【０２１５】
また、他方のコピーデータ２に関しては、テーブル更新制御部２２０４は、コピーデータ２（データ構造７に沿ったデータ）のテーブル存在フラグ及び更新時刻を削除して、データ構造２に沿ったデータを作成する（ステップＳ２５０７）。
【０２１６】
更新待ちテーブル内のすべてのデータに関して上記の処理が完了した後、更新待ちテーブル内のすべてのデータのテーブル存在フラグが、テーブル格納部２２０５のテーブルにおける存在を示す値『１』にセットされるとともに、ステップＳ２５０７でデータ構造２に沿ったデータに変換されたコピーデータ２によって、テーブル格納部２２０５内のテーブルが更新される（ステップＳ２５０８）。
【０２１７】
そして、上述のようにステップＳ２３０１で作成されたデータ（テーブル送信フラグ『０』のデータ構造６に沿ったデータ）や、図１９のステップＳ２５０６で作成されたデータ（テーブル送信フラグ『１』のデータ構造６に沿ったデータ）は、例えばＶＮＣプロトコルに準拠したデータに変換された後にクライアントＨ０２に送信される（ステップＳ２３０６）。また、ＶＮＣシステムと同様に、前フレームバッファ４０４には、今回取得した画像データ（フレームバッファ４０１内の画像データ）が上書きされ（ステップＳ６０５）、ステップＳ６０６において、何らかの終了条件が成立している場合には動作を終了する一方、終了条件が存在しない場合にはステップＳ６０１に戻って上記の処理が繰り返し行われる。
【０２１８】
次に、図２０を参照しながら、図１７に図示されているクライアントＨ０２の動作の一例について説明する。図２０は、本発明の第４の実施の形態におけるクライアントの動作の一例を示すフローチャートである。
【０２１９】
クライアントＨ０２では、まず、サーバＨ０１から送信されるＶＮＣプロトコルに沿ったデータを受信し、このデータをデータ構造６に沿ったデータに変換する（ステップＳ２４０１）。このデータ構造６のデータに含まれているテーブル送信フラグの値が描画用を示す値『０』の場合には、データは通信部２２０７から描画作成部２２０８に渡される。描画作成部２２０８では、データ構造６に沿ったデータに含まれているビットマップ画像データ、あるいはテーブル格納部２２１０に格納されているテーブル内のビットマップ画像データに基づいて、フレームバッファ４０８に書き込む描画データの作成処理が行われる（ステップＳ２４０２）。
【０２２０】
なお、描画作成部２２０８における処理は、データ形式がデータ構造６に沿ったデータである点を除いて、基本的に上述の図５に示されている動作とほぼ同一である。ただし、描画作成部２２０８は、ビットマップ存在フラグが『０』にセットされているデータの処理を行った場合には、処理を行ったデータに含まれる更新時刻で、テーブル格納部２２１０に格納されているテーブル内の対応データの更新時刻を書き換えることが望ましい。
【０２２１】
一方、サーバＨ０１から受信したデータに含まれているテーブル送信フラグの値がテーブル更新用を示す値『１』の場合には、データは通信部２２０７からテーブル作成部２２０９に渡される。テーブル作成部２２０９では、通信部２２０７から供給されたデータ構造６のデータをテーブルに追加登録することによって、テーブル更新処理が行われる（ステップＳ２４０３）。
【０２２２】
以下、図２１を参照しながら、上記のステップＳ２４０３におけるテーブル更新処理の詳細について説明する。図２１は、本発明の第４の実施の形態において、クライアントのテーブル作成部で行われるテーブル更新処理の一例を示すフローチャートである。
【０２２３】
クライアント側では、テーブル格納部２２１０のテーブルのデータ量が所定の限界容量ＴＨ２を基準にした容量に抑えられるように監視されている。テーブル作成部２２０９は、テーブル格納部２２１０内のテーブルの総データ量が所定の限界容量ＴＨ２より大きいか否かを判断する（ステップＳ２６０１）。なお、ステップＳ２６０１でテーブル格納部２２１０内のテーブルの総データ量が所定の限界容量ＴＨ２以下であると判断された場合には、ステップＳ２６０４に進む。
【０２２４】
一方、ステップＳ２６０１でテーブル格納部２２１０内のテーブルの総データ量が所定の限界容量ＴＨ２より大きいと判断された場合には、データ構造６に沿ったデータに含まれている更新時刻を使用して、テーブル内のデータを更新時刻の新しい順に並び替えられる（ステップＳ２６０２）。そして、テーブルの総データ量が限界容量ＴＨ２以下となるまで、更新時刻の古い順にデータの削除が行われる（ステップＳ２６０３）。
【０２２５】
そして、ステップＳ２６０３で総データ量が削減されたテーブル、あるいはステップＳ２６０１で総データ量が限界容量以下であると判断されたテーブルに、通信部２２０７から供給されたデータ構造６のデータが追加登録される（ステップＳ２６０４）。
【０２２６】
その後の処理は、本発明の第１の実施の形態（図４参照）と同様である。すなわち、描画作成部２２０８は、描画データ列に含まれる描画データを用いて、フレームバッファ４０８に画像データの描画を行い（ステップＳ７０２）、出力部４０９は、フレームバッファ４０８を順次読み出し、Ｄ／Ａ変換などの所望の信号処理を行ってディスプレイ４１０への出力を行う（ステップＳ７０３）。また、ステップＳ７０４において、何らかの終了条件が成立している場合には動作を終了する一方、終了条件が存在しない場合にはステップＳ２４０１に戻って上記の処理が繰り返し行われる。
【０２２７】
なお、ここでは、１つのサーバＨ０１に対して１つのクライアントＨ０２のみが図示されているが、図２２に図示されているように、１つのサーバＨ０１に対して複数のクライアントＨ０２（図２２では５つのクライアントＡ〜Ｅを図示）が存在するように構成してもよい。このような構成の場合、従来のサーバは、すべてのクライアントに同一のテーブルに係るデータを送信していたので、クライアントによっては、テーブルのデータ量がメモリのデータ量を超えてしまい、テーブルを保持しきれない場合があった。しかしながら、本発明の第４の実施の形態によれば、サーバＨ０１は、各クライアントＨ０２に対して、各クライアントの限界容量ＴＨ２に応じたテーブルのデータを送信することが可能となる。
【０２２８】
以上、説明したように、本発明の第４の実施の形態では、リモートデスクトップシステムにおいて、各描画データから固有値（例えばハッシュ値）を算出して各描画データを固有値と関連付けてテーブルに登録し、このテーブルをサーバ及びクライアントで共有する。この際、クライアントが持っているテーブルを格納するためのメモリの容量が小さい場合や、テーブルの格納に使用されるメモリリソースを制限する場合などにおいて、サーバ側でクライアントのテーブルの総データ量に基づくテーブル管理を行うことができるようになり、サーバからクライアントに転送される描画データ量が削減される。
【０２２９】
なお、本明細書では、本発明の第１〜第４の実施の形態に関して独立して説明を行ったが、これらの第１〜第４の実施の形態を任意に組み合わせて用いることも可能である。また、本発明を実現するサーバ及びクライアントとして、例えば汎用コンピュータを利用することも可能である。また、上述の説明では、サーバ及びクライアントが有する構成要素は機能ブロックによって模式的に図示されているが、これらの各構成要素は、ハードウェア又はソフトウェア（例えば、コンピュータによって実行可能なプログラム）によって実現することが可能である。例えば、上記した各装置の機能をプログラムによりコンピュータに実現させるようにしてもよい。また、このプログラムは、記録媒体から読み取られてコンピュータに取り込まれてもよいし、通信ネットワークを介して伝送されてコンピュータに取り込まれてもよい。
【産業上の利用可能性】
【０２３０】
本発明は、サーバとクライアントとの間において送受信する描画データ列のデータ量を大幅に削減でき、ＧＵＩの反応速度を向上させてユーザの利便性を向上するとともに、ユーザのストレスを軽減するという効果、クライアント側に復号化器を搭載させる必要がなく、クライアントの負荷を削減することができるという効果、異なる領域で同一の更新画像データが存在する場合であっても、新たにテーブルに追加することなく更新表示データを再現することができ、テーブル量を削減することができるという効果を有している。また、本発明は、サーバからクライアントに送信されるデータが全て可逆圧縮であるので、クライアント側で実現される画像データが一様になり、クライアント側で視覚的に安定した表示を実現できるという効果を有しており、キーボードなどの入力装置と、映像を表示することが可能なビットマップディスプレイなどの表示装置とを備えたクライアント装置から遠隔地にあるサーバ装置に対して、アプリケーションなどの操作指示を送信し、その結果として、サーバ装置からクライアント装置に送信される映像をクライアント装置で表示するリモートデスクトップシステムの技術に適用可能である。
【図面の簡単な説明】
【０２３１】
【図１】本発明の第１の実施の形態におけるリモートデスクトップシステムの一構成例を示すブロック図である。
【図２】本発明の第１の実施の形態におけるサーバの動作の一例を示すフローチャートである。
【図３】本発明の第１の実施の形態において、サーバの比較決定部で行われる比較処理及び変換処理の一例を示すフローチャートである。
【図４】本発明の第１の実施の形態におけるクライアントの動作の一例を示すフローチャートである。
【図５】本発明の第１の実施の形態において、クライアントの描画作成部で行われる描画作成処理の一例を示すフローチャートである。
【図６】本発明の第２の実施の形態におけるリモートデスクトップシステムの一構成例を示すブロック図である。
【図７】本発明の第２の実施の形態におけるサーバの動作の一例を示すフローチャートである。
【図８】本発明の第２の実施の形態において、サーバの比較決定部で行われる比較処理及び変換処理の一例を示すフローチャートである。
【図９】本発明の第２の実施の形態において、サーバの差分決定部で行われる差分決定処理の一例を示すフローチャートである。
【図１０】本発明の第２の実施の形態におけるクライアントの動作の一例を示すフローチャートである。
【図１１】本発明の第２の実施の形態において、クライアントの差分合成部で行われる差分合成処理の一例を示すフローチャートである。
【図１２】本発明の第２の実施の形態における差分合成の概要が図示されている。
【図１３】本発明の第３の実施の形態におけるリモートデスクトップシステムの一構成例を示すブロック図である。
【図１４】本発明の第３の実施の形態におけるサーバの動作の一例を示すフローチャートである。
【図１５】本発明の第３の実施の形態におけるクライアントの動作の一例を示すフローチャートである。
【図１６】本発明の第３の実施の形態において、クライアントの描画作成部で行われる描画作成処理の一例を示すフローチャートである。
【図１７】本発明の第４の実施の形態におけるリモートデスクトップシステムの一構成例を示すブロック図である。
【図１８】本発明の第４の実施の形態におけるサーバの動作の一例を示すフローチャートである。
【図１９】本発明の第４の実施の形態において、サーバのテーブル更新制御部で行われるテーブル作成処理及びテーブル更新処理の一例を示すフローチャートである。
【図２０】本発明の第４の実施の形態におけるクライアントの動作の一例を示すフローチャートである。
【図２１】本発明の第４の実施の形態において、クライアントのテーブル作成部で行われるテーブル更新処理の一例を示すフローチャートである。
【図２２】本発明の第４の実施の形態において、１つのサーバに複数のクライアントが接続する構成の一例を示す図である。
【図２３】従来の技術におけるＴＳＳの一例を示すシステム構成図である。
【図２４】従来の技術におけるＸウィンドウシステムの一例を示すシステム構成図である。
【図２５】従来の技術におけるＶＮＣの一例を示すシステム構成図である。
【図２６】従来の技術におけるＶＮＣシステムの一構成例を示すブロック図である。
【図２７】図２６に示すＶＮＣサーバの処理の一例を示すフローチャートである。
【図２８】図２６に示すＶＮＣクライアントの処理の一例を示すフローチャートである。
【図２９】特許文献１に開示されているリモートデスクトップシステムの改良技術におけるサーバの処理の一例を示すフローチャートである。
【図３０】図２９のＲＫＥＹ作成処理の詳細な処理を示すフローチャートである。
【図３１】特許文献１に開示されているリモートデスクトップシステムの改良技術におけるクライアントの処理の一例を示すフローチャートである。
【図３２】従来の技術におけるウィザード形式のアプリケーションにおける表示例を示す図である。
【符号の説明】
【０２３２】
１０１、３０１  アプリケーション
１０２  端末サーバ
１０３  端末装置
１０４  ディスプレイ
２０１  Ｘアプリケーション
２０２  Ｘサーバ
２０３  Ｘクライアント
２０４、３０５、４１０  ディスプレイ（ビットマップディスプレイ）
２０５  ポインティングデバイス
３０２、４０１、４０８  フレームバッファ
３０３  ＶＮＣサーバ
３０４  ＶＮＣクライアント
３０６  ポインティングデバイス
４０２  フレーム取得部
４０３  比較部
４０４  前フレームバッファ
４０５、４０６、８０３、８０５、１２０３、１２０５、１８０２、１８０３、２２０６、２２０７  通信部
４０７  描画部
４０９  出力部
８０１  固有値算出部
８０２、１２０１、２２０１  比較決定部
８０４、８０７、１２０４、１２０７、２２０５、２２１０  テーブル格納部
８０６、１２０８、１８０６、２２０８  描画作成部
１２０２  差分決定部
１２０６  差分合成部
１８０１、１８０４  データ変換部
１８０５  クライアントバッファ
２２０２  データ作成部
２２０３  更新待ちテーブル格納部
２２０４  テーブル更新制御部
２２０９  テーブル作成部
３１０１  開始ボタン
３１０２  終了ボタン
３１０３  差分ビットマップ画像
Ａ０１  ＴＳＳを提供する汎用コンピュータ
Ａ０２  シリアル伝送
Ａ０３  ユーザ
Ｂ０１、Ｅ０１、Ｆ０１、Ｇ０１、Ｈ０１  サーバ
Ｂ０２、Ｃ０２  通信ネットワーク
Ｂ０３、Ｃ０３、Ｅ０２、Ｆ０２、Ｇ０２、Ｈ０２  クライアント
Ｃ０１  汎用コンピュータ
Ｄ０１  ＶＮＣサーバ
Ｄ０２  ＶＮＣクライアント
【図１】
2007226635.tif 000003
【図２】
2007226635.tif 000004
【図３】
2007226635.tif 000005
【図４】
2007226635.tif 000006
【図５】
2007226635.tif 000007
【図６】
2007226635.tif 000008
【図７】
2007226635.tif 000009
【図８】
2007226635.tif 000010
【図９】
2007226635.tif 000011
【図１０】
2007226635.tif 000012
【図１１】
2007226635.tif 000013
【図１２】
2007226635.tif 000014
【図１３】
2007226635.tif 000015
【図１４】
2007226635.tif 000016
【図１５】
2007226635.tif 000017
【図１６】
2007226635.tif 000018
【図１７】
2007226635.tif 000019
【図１８】
2007226635.tif 000020
【図１９】
2007226635.tif 000021
【図２０】
2007226635.tif 000022
【図２１】
2007226635.tif 000023
【図２２】
2007226635.tif 000024
【図２３】
2007226635.tif 000025
【図２４】
2007226635.tif 000026
【図２５】
2007226635.tif 000027
【図２６】
2007226635.tif 000028
【図２７】
2007226635.tif 000029
【図２８】
2007226635.tif 000030
【図２９】
2007226635.tif 000031
【図３０】
2007226635.tif 000032
【図３１】
2007226635.tif 000033
【図３２】
2007226635.tif 000034