JP2007241736A - リモートデスクトップシステムのサーバ装置及びクライアント装置 - Google Patents

Abstract

【課題】リモートデスクトップシステムにおいて、フェードやスクロールなどの画像変化の発生時にクライアント側の負荷を増大させることなく、サーバからクライアントに送信される画像データのデータ量を大幅に削減してＧＵＩの反応速度を向上させる。
【解決手段】サーバＦ０１のフェード処理部１２０１は、あらかじめクライアント装置Ｆ０２で表示されるフェード表示の学習を行い、フェード表示の表示領域のフェード時間などの特徴をフェードテーブル格納部１２０２に格納しておく。比較決定部１２０３は、クライアント装置でフェード表示が行われることを検出した場合、クライアント装置に対して、そのフェード表示の表示領域やフェード時間、表示の態様などの指示を送出することで、大量の画像データが伝送されることなく、クライアント装置で擬似的なフェード表示が行われる。
【選択図】図６

Description

本発明は、キーボードなどの入力装置と、映像を表示することが可能なビットマップディスプレイなどの表示装置とを備えたクライアント装置から遠隔地にあるサーバ装置に対して、アプリケーションなどの操作指示を送信し、その結果として、サーバ装置からクライアント装置に送信される映像をクライアント装置で表示するリモートデスクトップシステムに関し、特に、リモートデスクトップシステムのサーバ装置及びクライアント装置に関する。

リモートデスクトップシステムとして１９７０年代から普及したＴＳＳ（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：離散コサイン変換）、量子化、エントロピー処理を行って更新データを符号化し（ステップＳ２９１０）、ステップＳ２９０９に進む。

また、ステップＳ２９０３でキャッシュメモリ内に存在する更新領域が同一のものが１つのみではない場合には、ＤＣＴ、量子化、エントロピー処理を行って更新データを符号化し（ステップＳ２９０５）、複数検出された同一の更新領域を持つデータのコードワード（キャッシュメモリ内のコードワード）と、ステップ２９０５で符号化した更新データとを比較し、同一のコードワードを持つデータが存在するか否かを検索する（ステップＳ２９０６）。そして、ステップＳ２９０７において、同一のコードワードを持つデータが存在する場合にはステップＳ２９０８に進み、同一のコードワードを持つデータが存在しない場合にはステップＳ２９０９に進む。一方、ステップＳ２９０３でキャッシュメモリ内に更新領域が１つのみ存在している場合には、ステップＳ２９０４に進む。

ステップＳ２９０４では、キャッシュメモリ内に更新領域が同一のデータが１つしか存在しない場合の処理が行われる。この場合、キャッシュ情報に『キャッシュ済』、ＳＩＤに『キャッシュメモリ内で一致したデータのＳＩＤ』が代入され、コードワードには何も設定されずに作成されたＲＫＥＹのデータがクライアントに送信される。

また、ステップＳ２９０８では、キャッシュメモリ内に同一のコードワードを持つデータが存在する場合の処理が行われる。この場合、キャッシュ情報に『キャッシュ済』、ＳＩＤに『キャッシュメモリ内で一致したデータのＳＩＤ』が代入され、コードワードには何も設定されずに作成されたＲＫＥＹのデータがクライアントに送信される。

また、ステップＳ２９０９では、キャッシュメモリ内に更新領域は同一であるが同一のコードワードが存在しない場合、又は、更新領域が異なる場合の処理が行われる。この場合、キャッシュ情報に『キャッシュ』、ＳＩＤに『割り振られていない値』、コードワードに『符号化した更新データ』が代入されたＲＫＥＹのデータがクライアントに送信される。

一方、図２６において、クライアントは、サーバから受信するＲＫＥＹのキャッシュ情報を監視及び解析を行い（ステップＳ３００１）、『キャッシュ不要』の場合にはステップＳ３００２に進み、『キャッシュ』の場合にはステップＳ３００３に進み、『キャッシュ済』の場合にはステップＳ３００５に進む。

ステップＳ３００２では、キャッシュ不要の場合の処理が行われる。この場合、コードワードに直接更新するデータが代入されており、それを更新データとする。

また、ステップＳ３００３では、キャッシュへの登録が必要な場合の処理が行われる。この場合、ＲＫＥＹのコードワードが符号化されているので、これを復号し、復号したデータを更新データとする。さらに、クライアントは、ＲＫＥＹのデータをローカルキャッシュメモリに登録する（ステップＳ３００４）。

また、ステップＳ３００５では、既にキャッシュされている場合の処理が行われる。この場合、受信したＲＫＥＹのＳＩＤと同一のＲＫＥＹのデータをローカルキャッシュメモリより取得する。さらに、クライアントは、ステップ３００５で取得したＲＫＥＹのコードワードを復号して、復号したデータを更新データとする（ステップＳ３００６）。

そして、上記のステップＳ３００２、Ｓ３００４、３００６のそれぞれで作成された更新データを使用して、更新領域にデータが表示される（ステップＳ３００７）。

また、ユーザに対して画像の移り変わりを知覚させ、例えば画像全体が突然変更されることによってユーザに不快感を与えることを避けるために、画像の輝度を連続的に変化させるフェード（フェードイン又はフェードアウト）という画像表示手法が一般的に知られている。下記の特許文献２には、時系列的に変化する画像の総輝度値の差分の絶対値を演算し、この差分の絶対値が大きく、かつ同一位置に存在する画素同士の画素データの差分値が小さい場合に、画像が上述のフェード状態にあることを検出するフェード検出方法及びフェード検出装置が開示されている。

また、ディスプレイの表示可能領域よりも大きな画像をユーザに提示したい場合に、まず画像の一部分を表示し、例えばユーザの操作に従って時系列的にピクセル単位で表示部分をずらすことで全体を表示させるスクロールという画像表示手法が一般的に知られている。なお、スクロールは、元々大きな画像（ＨＴＭＬ（Hyper Text Markup Language）テキストなどの文章データを画像レンダリングしたものも含む）を表示する手法であり、１画面におけるスクロール範囲の割合は必然的に大きくなる。
特表２００５−５０１３５５号公報（図４〜図７、段落００１５、００１６） 特開２０００−５９６８３号公報（段落００１７、図１） Tristan Richardson, RealVNC Ltd："The RFB Protocol" Version 3.8, 8 March 2005

従来のリモートデスクトップシステムのうち、Ｘウィンドウシステム型のリモートデスクトップシステムが、サーバとクライアントとの間における伝送効率が最も良いと考えられる。Ｘウィンドウシステム型のリモートデスクトップシステムでは、描画データは『線を描け』などのような抽象度の高いものであり、その結果、データ量は極小化されている。しかしながら、その代償としてＸウィンドウシステム用の描画データ列を生成する専用Ｘアプリケーションが必要になる。

インターネットが普及した今日では、様々なＰＣや汎用コンピュータが様々なアプリケーションを実行し、相互に分散ネットワークを形成している。このため、常にＸアプリケーションを要求するＸウィンドウシステムは時代の要請に合わず、異種間における接続に対してより汎用性の高いＶＮＣ型のリモートデスクトップシステムが好適であると言える。

しかしながら、ＶＮＣ型のリモートデスクトップシステムでは、上述のようにビットマップ画像を含む描画データ列のデータ量が膨大になる傾向がある。特に、最近の画面全体にビットマップ画像を用いた美麗なボタン類が並ぶＧＵＩ（Graphic User Interface：グラフィック・ユーザ・インタフェース）を用いたアプリケーションにおいては、更新領域が画面全体を占めることも珍しくない。例えば、図２７に図示されているようなウィザード形式のアプリケーションによる表示の場合には、例えば『次へ』ボタンを押すと新たな次画面に移るため、サーバからクライアントに対して画面全体を送らなければならない機会が非常に多い。これはＧＵＩの反応速度低下をもたらし、ユーザに対する利便性を低下させるとともに、ユーザのストレスを増大させる要因となる。

例えば、上述のように、スループットが１．５ＭＢ／ＳであるＡＤＳＬの通信ネットワークを介して、１０２４×７６８ピクセルで３２ビットフルカラーのビットマップ画像１枚を伝送する場合には、約２秒の表示遅延が生じることとなる。このため、Ｘウィンドウシステム型のリモートデスクトップシステムのような抽象度の高い描画データ列を生成することが可能なＶＮＣ型のリモートデスクトップシステムの開発が望まれている。しかしながら、アプリケーションをＸウィンドウシステム型の抽象描画命令に完全対応させることは、すなわち、新たなＸアプリケーションを新規に開発することになってしまい意味がない。これはＶＮＣが発達してきた背景を考えれば明らかである。

上述の特許文献１に係る技術では、更新表示データを『キャッシュ済』や『キャッシュ不要』などのように特定できるようにすることで、ＶＮＣ型のリモートデスクトップシステムにおいて、抽象度の高い描画データ列の生成を試みているが、この技術では、更新領域の大きさに応じて、非可逆符号化する部分と符号化しない部分とが存在し、クライアント側で実現される表示画像が視覚的に奇妙かつ見づらいものになってしまうという課題がある。

また、リモートデスクトップシステムでは、基本的にクライアント側の負荷が小さいことがメリットであるが、上述の特許文献１に係る技術では、クライアント側に符号化データを復号するための復号化器を設ける必要があり、復号機能に関してクライアント側の負荷を小さくすることができないという課題がある。

さらに、上述の特許文献１に係る技術では、作成されるＲＫＥＹデータが、更新領域、及び更新領域の大きさにより作成されているので、例えば同一のボタン形状の画像配列を有するＧＵＩのように異なる更新領域で同一の更新画像データが存在する場合であっても、更新領域が異なるために新たなＲＫＥＹを作成する必要があり、このＲＫＥＹをサーバ及びクライアントの両方においてキャッシュメモリに保存するので、キャッシュ量が増大してしまうという課題がある。

また、ＶＮＣ型のリモートデスクトップシステムや特許文献１に係る技術では、画像の輝度値が変化するフェードや、表示ウィンドウよりも大きな画像が一定方向に動くスクロールが発生した際には、フェードやスクロールによって時系列的に連続的に変化する画像領域の画像データ又は表示画像領域全体の画像データが、サーバ側からクライアント側に送信される必要があり、一時的に大量の画像データがサーバからクライアントに伝送されることになる。その結果、クライアント側では、フェード表示やスクロール表示に係る処理に遅延が生じたり、不自然なフェード表示又はスクロール表示となったりするという課題がある。

例えば、図２８に図示されているような１つの画像表示ウィンドウと３つのボタンで構成された画像において、画像表示ウィンドウ内にフェードが発生した場合には、画像表示ウィンドウ内のフェード変化を反映するために、フェード状態の間はサーバ側からクライアント側に対して、フェード変化に対応する画像データが送信され続けることになる。また、図２９に図示されているような１つのスクロールウィンドウと３つのボタンで構成された画像において、スクロールウィンドウ内に画像のスクロールが発生した場合には、スクロールウィンドウ内のスクロール変化を反映するために、スクロール移動が行われている間はサーバ側からクライアント側に対して、スクロール移動に対応する画像データが送信され続けることになる。

上記の課題を解決するため、本発明は、クライアント側の負荷を増大させることなく、フェードやスクロールなどの画像変化が発生した際に、サーバとクライアントとの間において送受信する描画データ列のデータ量を大幅に削減してＧＵＩの反応速度を向上させることが可能なリモートデスクトップシステムのサーバ装置及びクライアント装置を提供することを目的とする。

上記の目的を達成するため、本発明によれば、クライアント装置に対して、前記クライアント装置の表示手段に表示させる画像データを送信するリモートデスクトップシステムのサーバ装置であって、
前記クライアント装置の前記表示手段にフェード効果を有する表示を実現させる画像データを前記クライアント装置に送信しようとするフェード開始タイミングを検出するフェード検出手段と、
前記フェード検出手段によって検出された前記フェード開始タイミングにおいて、前記フェード効果を有する表示を実現させる前記画像データを、前記クライアント装置に送信しないように制御するとともに、前記フェード効果を有する表示が行われる前記表示手段上の表示領域と、前記フェード開始タイミングと、前記フェード効果を有する表示の開始から終了までのフェード期間と、前記フェード期間中の前記表示領域における表示の態様とを指示する情報を前記クライアント装置に送信するフェード制御手段とを、
有するサーバ装置が提供される。

また、上記の目的を達成するため、本発明によれば、クライアント装置に対して、前記クライアント装置の表示手段に表示させる画像データを送信するリモートデスクトップシステムのサーバ装置であって、
前記クライアント装置に対して送信した前記画像データを格納する画像データ格納手段と、
新たに前記クライアント装置に対して送信する第１画像データによって表示される表示対象と、前記画像データ格納手段に格納されている前記第１画像データの直前に前記クライアント装置に対して送信した第２画像データによって表示される表示対象との動きベクトルを検出する動きベクトル検出手段と、
前記動きベクトル検出手段によって検出された前記動きベクトルから、所定領域以上の大きさの画像が、一定方向かつ一定距離だけ移動を行っている動きが検出された場合に、前記第１画像データの表示画像と前記第２画像データの表示画像との間でスクロールが起こっていると判断するスクロール判断手段と、
前記スクロール判断手段で前記スクロールの発生が検出された前記第１画像データ及び前記第２画像データから、前記スクロールが起こっているスクロール領域を特定するスクロール領域特定手段と、
前記第１画像データの表示画像の前記スクロール領域と前記第２画像データの表示画像の前記スクロール領域とを比較し、前記スクロールによって移動するスクロール移動領域の画像データ、及び、前記スクロールによって新たに表示されるスクロール新規領域の画像データを特定するスクロール画像データ特定手段と、
前記クライアント装置に対して既に送信されている前記第２画像データの表示画像から前記スクロール移動領域の表示画像を抽出するように指示する情報と、前記スクロールに基づく前記スクロール移動領域の表示画像の新たな表示位置を指定する情報とを前記クライアント装置に送信し、前記クライアント装置に抽出させた前記表示画像を前記新たな表示位置に表示させる第１スクロール表示制御手段と、
前記第１画像データの表示画像の一部を構成する前記第１画像データ内における前記スクロール新規領域の画像データのみを含むとともに、前記スクロール新規領域の表示画像の表示位置を指定する情報を前記クライアント装置に送信し、前記スクロール新規領域の表示画像をその表示位置に表示させる第２スクロール表示制御手段とを、
有するサーバ装置が提供される。

また、上記の目的を達成するため、本発明によれば、サーバ装置から受信する画像データに基づいて画像表示を行うリモートデスクトップシステムのクライアント装置であって、
画像表示を行う表示手段と、
フェード効果を有する表示を実現させる画像データの代わりに、前記フェード効果を有する表示が行われる前記表示手段上の表示領域と、前記フェード開始タイミングと、前記フェード効果を有する表示の開始から終了までのフェード期間と、前記フェード期間中の前記表示領域における表示の態様とを指示する情報を前記サーバ装置から受信するフェード指示受信手段と、
前記フェード開始タイミングから前記フェード期間の間、前記表示手段上の前記表示領域に前記フェード期間中の前記表示領域における前記表示の態様に基づく表示を行うように制御するフェード表示制御手段とを、
有するクライアント装置が提供される。

本発明は、上記の構成を有しており、リモートデスクトップシステムでフェードやスクロールなどの画像変化が発生した場合において、サーバとクライアントとの間において送受信する描画データ列のデータ量を大幅に削減でき、ＧＵＩの反応速度を向上させてユーザの利便性を向上するとともに、ユーザのストレスを軽減するという効果を有している。また、本発明は、クライアント側に復号化器を搭載させる必要がなく、クライアントの負荷を削減することができるという効果を有している。また、本発明は、異なる領域で同一のフェードやスクロールなどの画像変化が発生する場合であっても、新たにテーブルに追加することなくフェードやスクロールを再現することができ、テーブル量を削減することができるという効果を有している。また、本発明は、サーバからクライアントに送信されるデータが全て可逆圧縮であるので、クライアント側で実現される画像データが一様になり、クライアント側で視覚的に安定した表示を実現できるという効果を有している。

以下、図面をしながら、本発明の第１及び第２の実施の形態について説明する。まず、本発明の第１及び第２の実施の形態が前提とするリモートデスクトップの構成及び動作について説明する。

図１は、本発明の第１及び第２の実施の形態が前提とするリモートデスクトップシステムの一構成例を示すブロック図である。図１に図示されているリモートデスクトップシステムは、サーバＥ０１とクライアントＥ０２とが任意のデータ伝送路を介して接続された構成を有している。

以下、図１に図示されているサーバＥ０１の構成について説明する。図１に図示されているサーバＥ０１は、フレームバッファ４０１、フレーム取得部４０２、比較部４０３、前フレームバッファ４０４、固有値算出部８０１、比較決定部８０２、通信部８０３、テーブル格納部８０４を有している。

図１に図示されているサーバＥ０１のフレームバッファ４０１、フレーム取得部４０２、比較部４０３、前フレームバッファ４０４には、従来の技術で説明した図２１に図示されているＶＮＣサーバＤ０１のフレームバッファ４０１、フレーム取得部４０２、比較部４０３、前フレームバッファ４０４を利用することが可能である。すなわち、図１に図示されているサーバＥ０１の比較部４０３からは、ＶＮＣシステムと同様に、フレーム取得部４０２で取得したフレームバッファ４０１内の画像データと、前フレームバッファ内の画像データ（フレームバッファ４０１内の画像データの更新直前にフレームバッファ４０１内に蓄積されていた画像データ）との比較の結果、これら画像データの差分の描画データが、上述のデータ構造１の形式で出力される。

図１に図示されているサーバＥ０１の比較部４０３から出力されるデータ構造１の形式のデータは、固有値算出部８０１に供給される。固有値算出部８０１は、比較部４０３から供給されるデータ構造１に沿った描画データのビットマップ画像データをハッシュ関数を用いて演算して、そのビットマップ画像データに固有のハッシュ値（以下、固有値と記載する）を算出する。そして、固有値算出部８０１は、描画データを含むデータ構造１のデータと、算出した固有値とを比較決定部８０２に出力する。

なお、固有値を算出するためにハッシュ関数を用いることが好適ではあるが、任意の入力データに対して固有値を算出するような方法であれば、他の方法を用いてもよい。ハッシュ関数を用いることが好適な理由は、以下の通りである。ハッシュ関数は、電子署名などに用いられるＭＤ−５やＳＨＡ−１などのハッシュ関数であり、これらのハッシュ関数は、任意のデータから１２８ビット又は１６０ビットの数値（任意のデータに固有な値）を算出する。このようなハッシュ関数を用いた場合、２つのデータＸ、Ｙが与えられた際には、データＸ、Ｙが同一データであればハッシュ値Ｈ（Ｘ）、Ｈ（Ｙ）も等しくなる。しかしながら、データＸ、Ｙが１ビットでも異なるデータである場合には、ハッシュ値Ｈ（Ｘ）、Ｈ（Ｙ）は異なる数値を取る。なお、原理的には、異なるデータに対してハッシュ値が同一になる場合も生じ得るが、その可能性は極めて低い確率でしか発生しないのがハッシュ関数の特徴である。したがって、異なるデータ同士が同一のハッシュ値を取る可能性は実用上無視できる。ハッシュ関数は、上述のような特性を持った関数であるので、任意のデータから固有値を求める際に有効である。

また、比較決定部８０２は、固有値算出部８０１から供給される描画データを含むデータ構造１のデータ及び固有値を受け取ると、テーブル格納部８０４に格納されているテーブルを使用して、下記のデータ構造２のデータを作成する。

（ビットマップ存在フラグ、画面上のＸ座標、画面上のＹ座標、ビットマップ画像の横幅、ビットマップ画像の高さ、ビットマップ画像、固有値）・・・＜データ構造２＞

上記のように、データ構造２は、ビットマップ存在フラグ、画面上のＸ座標、画面上のＹ座標、ビットマップ画像の横幅、ビットマップ画像の高さ、ビットマップ画像、固有値の各データを挿入するためのフィールドを有している。ビットマップ存在フラグのフィールドは、後続のビットマップ画像のフィールドにビットマップ画像が含まれているか否かを示す１ビットのフィールドである。クライアントＥ０２が有しているテーブルにこのビットマップ画像が保持されていると判断された場合には、ビットマップ存在フラグにビットマップ画像の非存在を示すビット（例えば『０』）がセットされ、ビットマップ画像のフィールドにビットマップ画像が含まれないようにする。一方、クライアントＥ０２が有しているテーブルにこのビットマップ画像が保持されていないと判断された場合には、ビットマップ存在フラグにビットマップ画像の存在を示すビット（例えば『１』）がセットされ、ビットマップ画像のフィールドにビットマップ画像が含まれるようにする。

また、画面上のＸ座標、画面上のＹ座標、ビットマップ画像の横幅、ビットマップ画像の高さの各フィールドは、ビットマップ画像（ビットマップ画像のフィールドに含まれているビットマップ画像又は固有値によって特定されるビットマップ画像）の配置位置を示す配置位置情報である。ここでは、ＶＮＣシステムと同様に上記４つのフィールドを用いているが、ビットマップ画像の配置位置を示すことができれば、任意の情報及び形式を採用することが可能である。

また、固有値のフィールドには、ビットマップ画像から算出された固有値が挿入される。クライアントＥ０２側では、この固有値は、ビットマップ画像を特定するための情報として利用される。

なお、比較決定部８０２は、固有値算出部８０１から受け取った固有値と、テーブル格納部８０４に格納されているテーブル内の固有値との比較結果に基づいて、ビットマップ画像データを含むデータの生成を行うか、ビットマップ画像データを含まないデータの生成を行うかを判断するが、このデータの生成処理に関しては後で詳細に説明する。

また、テーブル格納部８０４には、比較決定部８０２で作成されるデータ構造２に沿ったデータを追加記録するために用意されているテーブルが格納されている。比較決定部８０２は、固有値算出部８０１から固有値及び描画データを受けると、テーブル格納部８０４に格納されているテーブルを使用して、固有値算出部８０１から受けた固有値及び描画データに係るデータ構造２のデータを作成するとともに、作成したデータ構造２のデータ（あるいは、データ構造１のデータ及び固有値）をテーブルに格納する。なお、サーバＥ０１の比較決定部８０２は、固有値の比較によってビットマップ画像データをクライアントに送信するか否かを決定するので、テーブル格納部８０４内のテーブルに固有値のみが保持されても本発明は動作可能である。

テーブル格納部８０４に格納されているテーブルは、上述のように比較決定部８０２で作成されたデータ構造２のデータを保持することができるものであれば任意の形式で実現可能であるが、例えば、テーブルのエントリ（１つのデータ構造２のデータを保持する領域）の最大数を１０００個とし、ＦＩＦＯ（First In First Out）方式でテーブルの更新が行われるようにすることが可能である。

また、通信部８０３は、比較決定部８０２から供給されるデータ構造２に沿ったデータを、例えばＶＮＣプロトコルに変換してクライアントＥ０２に送信する。

次に、図１に図示されているクライアントＥ０２の構成について説明する。図１に図示されているクライアントＥ０２は、通信部８０５、描画作成部８０６、テーブル格納部８０７、フレームバッファ４０８、出力部４０９、ディスプレイ（ビットマップディスプレイ）４１０を有している。

通信部８０５は、サーバＥ０１から送信されるＶＮＣプロトコルに沿ったデータを受信し、データ構造２に沿ったデータに変換して、描画作成部８０６に出力する。

描画作成部８０６は、通信部８０５から供給されるデータ構造２に沿ったデータを受け取ると、通信部８０５から供給されるデータ構造２に沿ったデータ内に含まれているデータ、又はテーブル格納部８０７に格納されているテーブルに保持されているデータ構造２に沿ったデータを使用して画像データを作成し、作成した画像データをフレームバッファ４０８に書き込む。

なお、通信部８０５から供給されるデータにビットマップ画像データが既に含まれている場合には、描画作成部８０６は、この画像データをフレームバッファ４０８に書き込むことになる。描画作成部８０６における画像データの生成処理に関しては後で詳細に説明する。

また、テーブル格納部８０７には、描画作成部８０６が受け取ったデータ構造２に沿ったデータを追加記録するために用意されているテーブルが格納されている。描画作成部８０６は、通信部８０５からデータ構造２のデータを受けると、テーブル格納部８０７に格納されているテーブルを使用して、フレームバッファ４０８に書き込むための画像データを作成するとともに、通信部８０５から受けたデータ構造２のデータをテーブルに格納する。なお、クライアントＥ０２の描画作成部８０６は、固有値の一致するビットマップ画像データをテーブル格納部８０７内のテーブルから読み出す処理を行うので、テーブル格納部８０７内のテーブルにビットマップ画像データ及び固有値のみが保持されても本発明は動作可能である。

テーブル格納部８０４に格納されているテーブルは、サーバＥ０１のテーブル格納部８０４内のテーブルと同様に任意の形式で実現可能である。ただし、サーバＥ０１は、クライアントＥ０２のテーブル格納部８０７に格納されているテーブルに保持されている内容を把握する必要がある。したがって、例えば、サーバＥ０１のテーブル格納部８０４内のテーブルと、クライアントＥ０２のテーブル格納部８０７内のテーブルとは、同一の形式によって作成、保持されるようにすることが望ましい。

次に、図２を参照しながら、図１に図示されているサーバＥ０１の動作の一例について説明する。図２は、本発明の第１及び第２の実施の形態が前提とするリモートデスクトップシステムにおけるサーバの動作の一例を示すフローチャートである。

サーバＥ０１では、ＶＮＣシステムの場合と同様に、フレーム取得部４０２がフレームバッファ４０１から画像データ（描画データ）を取得し（ステップＳ６０１）、画像データを構成する描画データ列の各描画データに関して、ハッシュ関数を用いてビットマップ画像の固有値を算出する（ステップＳ９０１）。なお、上述のように、任意の入力データに対して固有値を算出することが可能であれば、必ずしもハッシュ関数を用いる必要はない。

次に、前フレームバッファ４０４が空か否かを確認することによって、初回の画像データ取得動作か否かの判定が行われる（ステップＳ６０２）。このとき、前フレームバッファ４０４が空の場合（画像データが１度も書き込まれていない場合）には、ステップＳ９０２における比較処理及び変換処理をスキップしてステップＳ９０３に進み、一方、前フレームバッファ４０４が空ではない場合には、ステップＳ９０２に進む。

ステップＳ９０２では、ステップＳ９０１で算出された各ビットマップ画像の固有値とテーブル格納部８０４に格納されているテーブル内の固有値とを比較し、その比較結果に基づいて、データ構造１に沿ったデータ及び固有値をデータ構造２に沿ったデータに変換する処理が行われる。

以下、図３を参照しながら、上記のステップＳ９０２における比較処理及び変換処理の詳細について説明する。図３は、本発明の第１及び第２の実施の形態が前提とするリモートデスクトップシステムにおけるサーバの比較決定部で行われる比較処理及び変換処理の一例を示すフローチャートである。

図３において、まず、サーバＥ０１の比較決定部８０２は、固有値算出部８０１から供給される描画データの固有値と、テーブル格納部８０４内のテーブルに保持されている固有値とを比較して、固有値算出部８０１から供給される描画データの固有値と同一のものがテーブル格納部８０４内のテーブルに保持されているか否かを判断する（ステップＳ１１０１）。

ステップＳ１１０１で同一の固有値がテーブルに存在する場合には、データ構造１に沿ったデータに対して、
・ビットマップ存在フラグに、ビットマップ画像の非存在を示す『０』をセット
・データ構造１に沿ったデータに対応する固有値をセット（追加）
・ビットマップ画像データを削除して、ＮＵＬＬを設定
することによって、データ構造２に沿ったデータが作成される（ステップＳ１１０２）。

一方、ステップＳ１１０１で同一の固有値がテーブルに存在しない場合には、データ構造１に沿ったデータに対して、
・ビットマップ存在フラグに、ビットマップ画像の存在を示す『１』をセット
・データ構造１に沿ったデータに対応する固有値をセット（追加）
することによって、データ構造２に沿ったデータが作成される（ステップＳ１１０３）。

なお、図面には反映されていないが、ステップＳ６０２で初回と判定された場合には、すべての描画データ及び固有値がサーバＥ０１からクライアントＥ０２に送信される必要があり、この場合には、上記のステップＳ１１０３に従ってデータ構造２に沿ったデータが作成される。

そして、上述のようにステップＳ１１０２又はＳ１１０３でデータ構造２に沿ったデータが作成された場合や、ステップＳ６０２で初回と判定された場合には、図２に示すように、データ構造２に沿ったデータ（少なくとも固有値）がテーブル格納部８０４のテーブルに追加登録され（ステップＳ９０３）、例えばＶＮＣプロトコルに準拠したデータに変換された後にクライアントＥ０２に送信される（ステップＳ９０４）。また、ＶＮＣシステムと同様に、前フレームバッファ４０４には、今回取得した画像データ（フレームバッファ４０１内の画像データ）が上書きされ（ステップＳ６０５）、ステップＳ６０６において、何らかの終了条件が成立している場合には動作を終了する一方、終了条件が存在しない場合にはステップＳ６０１に戻って上記の処理が繰り返し行われる。

次に、図４を参照しながら、図１に図示されているクライアントＥ０２の動作の一例について説明する。図４は、本発明の第１及び第２の実施の形態が前提とするリモートデスクトップシステムにおけるクライアントの動作の一例を示すフローチャートである。

クライアントＥ０２では、まず、サーバＥ０１から送信されるＶＮＣプロトコルに沿ったデータを受信し、このデータをデータ構造２に沿ったデータに変換する（ステップＳ１００１）。そして、描画作成部８０６において、データ構造２に沿ったデータに含まれているビットマップ画像データ、あるいはテーブル格納部８０７に格納されているテーブル内のビットマップ画像データに基づいて、フレームバッファ４０８に書き込む描画データの作成処理が行われる（ステップＳ１００２）。

以下、図５を参照しながら、上記のステップＳ１００２における描画作成処理の詳細について説明する。図５は、本発明の第１及び第２の実施の形態が前提とするリモートデスクトップシステムにおけるクライアントの描画作成部で行われる描画作成処理の一例を示すフローチャートである。

図５において、まず、クライアントＥ０２の描画作成部８０６は、通信部８０５から供給されるデータ構造２に沿ったデータ内のビットマップ存在フラグの値をチェックする（ステップＳ１１５１）。

ステップＳ１１５１でビットマップ存在フラグの値がビットマップ画像の存在を示す『１』の場合、このデータ構造２に沿ったデータにはビットマップ画像データが含まれていることが分かる。この場合には、描画作成部８０６は、サーバＥ０１から受信したデータ構造２に沿ったデータからビットマップ画像データを抽出する（ステップＳ１１５２）。なお、描画作成部８０６は抽出したビットマップ画像データを用いてフレームバッファ４０８への書き込みを行うので、テーブル格納部８０７内のテーブルを参照して描画データの作成を行う必要はない。

一方、ステップＳ１１５１でビットマップ存在フラグの値がビットマップ画像の非存在を示す『０』の場合、このデータ構造２に沿ったデータにはビットマップ画像データは含まれていないことが分かる。この場合には、描画作成部８０６は、サーバＥ０１から受信したデータ構造２に沿ったデータから固有値を抽出し、抽出した固有値に対応するビットマップ画像データをテーブル格納部８０７内のテーブルから取得して、このデータからビットマップ画像データを抽出する（ステップＳ１１５２）。

具体的には、例えばステップＳ１１５２では、描画作成部８０６は、ビットマップ存在フラグが『０』であることを確認した後、データ構造２に沿った入力データの固有値とテーブル格納部８０７内のテーブルに保持されている固有値とを比較して、データ構造２に沿った入力データの固有値と同一の固有値を有するデータ構造２に沿ったデータをテーブルから取得する。そして、取得したデータ構造２に沿ったデータからビットマップ存在フラグ及び固有値を削除して、データ構造１に沿ったデータを作成し、作成したデータの出力を行う。

また、さらに描画作成部８０６は、サーバＥ０１から受信したデータ構造２に沿ったデータ（少なくともビットマップ画像データ及び固有値）をテーブル格納部８０７のテーブルに追加登録する（ステップＳ１００３）。なお、この場合、ビットマップ画像データを含んでいるデータ構造２に沿ったデータのみをテーブルに追加登録してもよい。

図４において、描画作成部８０６は、描画データ列に含まれる描画データを用いて、フレームバッファ４０８に画像データの描画を行う（ステップＳ７０２）。なお、上述のように、図５のステップＳ１１５１でビットマップ存在フラグが『１』であることが確認された場合には、描画作成部８０６は、データ構造２に沿った入力データからビットマップ存在フラグ及び固有値を削除して、データ構造１に沿ったデータを作成し、作成したデータの出力を行い、したがって、描画作成部８０６は、図５のステップＳ１１５１でビットマップ存在フラグが『０』であることが確認された場合には、描画作成部８０６は、図５のステップＳ１１５３で取得したデータに基づくデータ出力を行う。また、出力部４０９は、フレームバッファ４０８を順次読み出し、Ｄ／Ａ変換などの所望の信号処理を行ってディスプレイ４１０への出力を行う（ステップＳ７０３）。また、ステップＳ７０４において、何らかの終了条件が成立している場合には動作を終了する一方、終了条件が存在しない場合にはステップＳ６０１に戻って上記の処理が繰り返し行われる。

以上、説明したように、本発明の第１及び第２の実施の形態が前提とするリモートデスクトップシステムは、各描画データから固有値（例えばハッシュ値）を算出して各描画データを固有値と関連付けてテーブルに登録し、このテーブルをサーバ及びクライアントで共有する。これにより、クライアント側のテーブルに保持されているビットマップ画像が表示画像データとして入力された場合に、サーバは、このビットマップ画像の代わりに固有値（さらには、Ｘ座標やＹ座標などの描画位置を指定する情報）を送信することで、クライアントは、この固有値からビットマップ画像（さらには、描画位置）を特定し、表示の更新を行うことが可能となる。この結果、サーバからクライアントに転送される描画データ量が削減される。

＜第１の実施の形態＞
次に、本発明の第１の実施の形態について説明する。図６は、本発明の第１の実施の形態におけるリモートデスクトップシステムの一構成例を示すブロック図である。図６に図示されているリモートデスクトップシステムは、サーバＦ０１とクライアントＦ０２とが任意のデータ伝送路を介して接続された構成を有している。

以下、図６に図示されているサーバＦ０１の構成について説明する。図６に図示されているサーバＦ０１は、フレームバッファ４０１、フレーム取得部４０２、比較部４０３、前フレームバッファ４０４、固有値算出部８０１、テーブル格納部８０４、フェード処理部１２０１、フェードテーブル格納部１２０２、比較決定部１２０３、通信部１２０４を有している。

図６に図示されているサーバＦ０１のフレームバッファ４０１、フレーム取得部４０２、比較部４０３、前フレームバッファ４０４には、従来の技術で説明した図２１に図示されているＶＮＣサーバＤ０１のフレームバッファ４０１、フレーム取得部４０２、比較部４０３、前フレームバッファ４０４を利用することが可能である。すなわち、図６に図示されているサーバＦ０１の比較部４０３からは、ＶＮＣシステムと同様に、フレーム取得部４０２で取得したフレームバッファ４０１内の画像データと、前フレームバッファ４０４内の画像データ（フレームバッファ４０１内の画像データの更新直前にフレームバッファ４０１内に蓄積されていた画像データ）との比較の結果、これら画像データの差分の描画データが、上述のデータ構造１の形式で出力される。

また、図６に図示されている固有値算出部８０１、テーブル格納部８０４には、図１に図示されている固有値算出部８０１、テーブル格納部８０４を利用することが可能である。すなわち、図６に図示されているサーバＦ０１の比較部４０３から出力されるデータ構造１の形式のデータは固有値算出部８０１に供給され、固有値算出部８０１において、描画データのビットマップ画像データに対してハッシュ関数を用いた演算が行われて、固有値（ハッシュ値）が算出された後、上述のデータ構造２の形式で出力される。また、テーブル格納部８０４には、例えばデータ構造２の形式のデータを含むテーブルが格納されており、本発明の第２の実施の形態では、比較決定部１２０３は、通常の描画データ（フェード非発生状態の描画データ）に関しては、テーブル格納部８０４に格納されているテーブルを参照して、上述の図６に図示されている比較決定部８０２と同様の処理を行う。

図６の構成では、固有値算出部８０１から出力される描画データを含むデータ構造２に沿ったデータ（あるいは、データ構造１に沿ったデータ及び固有値）は、フェード処理部１２０１及び比較決定部１２０３に供給される。フェード処理部１２０１は、固有値算出部８０１から供給されるデータ構造１に沿ったデータ及び固有値に加えて、前フレームバッファ４０４内の画像データを使用してフェードを検出し、フェードテーブル格納部１２０２にフェードテーブルとして格納するデータを作成して出力する。なお、フェード処理部１２０１における処理（フェード検出処理）に関しては、例えば図８を参照しながら、後で詳細に説明する。

また、フェードテーブル格納部１２０２には、フェードテーブルが格納されており、フェード処理部１２０１から供給されるデータがフェードテーブルに追加登録されることによって、フェードテーブルの更新が行われる。また、フェードテーブル格納部１２０２に格納されているフェードテーブルは、必要に応じて、比較決定部１２０３によって参照される。なお、フェードテーブルは、例えば図１６に図示されているようなテーブルによって実現される。

図１６には、本発明の第１の実施の形態において、サーバＦ０１のフェードテーブル格納部１２０２に格納されるフェードテーブルの一例が図示されている。図１６に図示されているフェードテーブルは、各フェードに対応して行（エントリ）が設けられている。そして、各エントリには、そのフェードの特徴を表すとともにフェードを擬似的に再現できるようにするための情報が含まれている。

例えば、図１６に図示されているフェードテーブルは、フェード発生領域を示す位置（Ｘ、Ｙ）及び大きさ（Ｗ、Ｈ）、フェードが終了しているか否かを示すフェード終了フラグ、フェード開始時の描画データを特定するための固有値を含むフェード開始固有値、フェード終了時の描画データを特定するための固有値を含むフェード最後固有値、フェード開始時の色調（ＲＧＢ値）を示すフェード開始ＲＧＢ値、フェードの開始時刻を示すフェード開始時刻、フェード終了時の色調（ＲＧＢ値）を示すフェード最後ＲＧＢ値、フェードの終了時刻を示すフェード最後時刻、フェード開始時からフェード終了時までに遷移するＲＧＢ値の変分を示すフェード係数、フェード開始時からフェード終了時までに使用されるフレーム枚数を示すフェード枚数、フェード開始時からフェード終了時までの経過時間を示すフェードスパン、現在フェード状態か否かを示すフェード処理中フラグの各項目を有している。

なお、図１６に示すフェードテーブルは、フェードを再現するために多数の情報を有しているが、例えば、どの領域（位置及び大きさ）にどのような擬似的フェード効果（フェード係数）をどのくらいの時間（フェードスパン）行うかを有するだけで、最低限の擬似的フェード効果を実現することが可能である。

本発明の第１の実施の形態では、サーバＦ０１側でフェード効果を有する表示が生じた場合に、例えば後述のデータ構造３のようなデータによって、図１６に示すフェードテーブルに含まれているフェード効果を再現するための情報をクライアントＦ０２側に送信することで、フェードに係る画像伝送量を大幅に低減させて、クライアントＦ０２側でサーバＦ０１側に同調した擬似的フェード効果を実現されるようになる。

また、図６に図示されている比較決定部１２０３は、固有値算出部８０１から供給されるデータ構造１に沿ったデータ及び固有値を受け取ると、テーブル格納部８０４に格納されているテーブル、又はフェードテーブル格納部１２０２に格納されているフェードテーブルを使用して、クライアントＦ０２に送信するデータを作成し、通信部１２０４に供給する。なお、比較決定部１２０３は、フェードとは無関係の通常の描画データ（フェード非発生状態の描画データ）に関しては、上述のようにテーブル格納部８０４内のテーブルを参照して、上述した本発明の第１及び第２の実施の形態の前提における処理と同一の処理を行う一方、フェードに関連する描画データに関しては、フェードテーブル格納部１２０２に格納されているフェードテーブルを参照して、クライアントＦ０２に送信するデータの作成を行う。

また、通信部１２０４は、比較決定部１２０３から供給されるデータを、例えばＶＮＣプロトコルに変換してクライアントＦ０２に送信する。

次に、図６に図示されているクライアントＦ０２の構成について説明する。図６に図示されているクライアントＦ０２は、通信部１２０５、フェード処理部１２０６、描画作成部８０６、フェードテーブル格納部１２０２、テーブル格納部８０７、フレームバッファ４０８、前フレームバッファ１２０８、出力部４０９、ディスプレイ（ビットマップディスプレイ）４１０を有している。

なお、図６に図示されているクライアントＦ０２のフレームバッファ４０８、出力部４０９、ディスプレイ４１０には、従来の技術で説明した図２１に図示されているＶＮＣサーバＤ０１のフレームバッファ４０８、出力部４０９、ディスプレイ４１０を利用することが可能である。また、図６に図示されているクライアントＦ０２の描画作成部８０６、テーブル格納部８０７には、図１に図示されている描画作成部８０６、テーブル格納部８０７を利用することが可能である。

通信部１２０５は、サーバＦ０１から送信されるＶＮＣプロトコルに沿ったデータを受信して変換し、フェード処理部１２０６に出力する。

また、フェード処理部１２０６は、通信部１２０５から供給されるデータを解析するとともに、フェード効果を反映させる必要がある場合には、例えば、前フレームバッファ１２０８内の画像データやフェードテーブル格納部１２０７内のフェードテーブルを使用して、フェード効果の反映された描画データの作成を行う。さらにフェード処理部１２０６は、フェードテーブル格納部１２０７に格納されているフェードテーブルに追加登録するためのデータ（後述のデータ構造５に沿ったフェードテーブルデータ）の作成も行う。

また、フェードテーブル格納部１２０７に格納されるフェードテーブルは、フェード処理部１２０６から入出力されるデータを記録管理するデータ構造を有している。フェードテーブル格納部１２０７は、例えばハードディスクやその他の読み書き可能な記録媒体によって実現可能である。なお、フェードテーブル格納部１２０７に格納されるフェードテーブルは、サーバＦ０１のフェードテーブル格納部１２０２内のフェードテーブルと同様に任意の形式で実現可能である。

また、前フレームバッファ１２０８は、フレームバッファ４０８から供給される画像データ（フレームバッファ４０８に新たな画像データが格納される際に、その直前にフレームバッファ４０８に格納されていた画像データ）を保持することが可能である。また、フェード処理部１２０６は、前フレームバッファ１２０８内の画像データを参照することが可能である。

次に、図７を参照しながら、図６に図示されているサーバＦ０１の動作の一例について説明する。図７は、本発明の第１の実施の形態におけるサーバの動作の一例を示すフローチャートである。

サーバＦ０１では、本発明の第１及び第２の実施の形態の前提（図２参照）と同様に、フレーム取得部４０２がフレームバッファ４０１から画像データ（描画データ）を取得し（ステップＳ６０１）、画像データを構成する描画データ列の各描画データに関して、ハッシュ関数を用いてビットマップ画像の固有値を算出する（ステップＳ９０１）。続いて、サーバＦ０１は、サーバＦ０１とクライアントＦ０２とが接続されているか否かの判断を行う（ステップＳ１３０１）。

このステップＳ１３０１におけるクライアントの接続／非接続の判断は、フェード検出処理（フェードテーブル作成処理）を行うか否かを決定するものである。フェードを検出するためには数フレーム（少なくとも２フレーム）分の画像データを解析する必要があり、クライアントＦ０２との接続時にフェード検出処理を行うと、フェードが発生した場合にクライアントに送信するデータが滞ってしまい、サーバＦ０１とクライアントＦ０２との間の遅延が非常に大きくなる可能性がある。したがって、サーバＦ０１は、クライアントＦ０２と非接続時にフェード検出を行って、その検出結果をフェードテーブルに保持しておくことで、クライアントＦ０２との接続時にフェードが発生した場合に、クライアントＦ０２に対するデータ送信を遅滞無く実現し、サーバＦ０１とクライアントＦ０２との間の遅延を低減させることが可能となる。すなわち、サーバＦ０１では、クライアントＦ０２との非接続時に、高い頻度で利用されるアプリケーションを実行し、フェード発生時の画面遷移の特徴をあらかじめフェードテーブルに学習しておく。

なお、必ずしも上述のようにクライアントＦ０２との非接続時にフェード検出処理が行われる必要はなく、クライアント接続時であってもフェード検出処理が行われてもよい。さらに、あらかじめサーバＦ０１で発生するフェードの特徴を有するフェードテーブルを用意し、このフェードテーブルをフェードテーブル格納部１２０２に格納させることによって、サーバＦ０１上でフェード検出処理（フェードテーブル生成処理）を行う必要をなくしてもよい。

ステップＳ１３０１におけるクライアントＦ０２の接続／非接続の判断において、サーバＦ０１とクライアントＦ０２との接続が検出された場合にはステップＳ１３０２に進む。ステップＳ１３０２では、フェードテーブルを作成するためのフェード検出処理が行われる。

以下、図８を参照しながら、上記のステップＳ１３０２におけるフェード検出処理の詳細について説明する。図８は、本発明の第１の実施の形態において、サーバのフェード処理部で行われるフェードテーブル作成のためのフェード検出処理の一例を示すフローチャートである。

フェード検出処理では、フェード処理部１２０１は、まず固有値算出部８０１から供給された画像データの大きさ（ビットマップ画像の横幅（以下、Ｗと記載）、ビットマップ画像の高さ（以下、Ｈと記載））を、あらかじめ定められた閾値Ｔｗ、Ｔｈと比較し、条件１『Ｗ＞Ｔｗ、かつ、Ｈ＞Ｔｈ』を満たしているか否かを判断する（ステップＳ１４０１）。条件１が満たされている場合にはステップＳ１４０２に進み、条件１が満たされていない場合には、フェード検出処理は終了となる。

なお、上述のステップＳ１４０１でＴｗ×Ｔｈの大きさよりも小さな画像に関してフェード検出処理を行わない理由は、小さな画像であればフェード発生時においてもクライアントＦ０２への送信データ量が過大とはならないため、通信路にかかる負担（さらには処理遅延などの影響）が少ないためである。なお、ここでは、画像の横幅Ｗ及び高さＨの両方が閾値Ｔｗ及びＴｈよりも大きい場合にフェード検出処理が行われるようにしているが、例えば画像の横幅Ｗ及び高さＨのいずれか一方が閾値を超えた場合や、画像の面積が閾値を超えた場合に、フェード検出処理が行われるようにしてもよい。また、ここでは、閾値ＴｗやＴｈとして固定値を用いているが、画像サイズや転送レートなどに合わせて、閾値ＴｗやＴｈを適時変化させてもよい。さらには、閾値ＴｗやＴｈを設定せずに、すべてのフェードに関して、ステップＳ１４０２以降の処理を行ってもよい。

次に、ステップＳ１４０１で条件１を満たす画像データに関して、サーバＦ０１は、描画データの位置（画面上のＸ座標（以下、Ｘと記載）、画面上のＹ座標（以下、Ｙと記載））や大きさ（Ｗ、Ｈ）を参照して、前フレームバッファ４０４内の画像データから同一の位置及び大きさのビットマップ画像（以下、前ＢＭＰ画像と記載）を取得する（ステップＳ１４０２）。

そして、サーバＦ０１は、上述のステップＳ１４０２で取得した前ＢＭＰ画像、及び現在処理を行っている描画データのビットマップ画像（以下、現ＢＭＰ画像と記載）をビットマップ画像からＹＵＶ画像に変換する（ステップＳ１４０３）。このステップＳ１４０３における処理によって、現ＢＭＰ画像は現ＹＵＶ画像に変換され、前ＢＭＰ画像は前ＹＵＶ画像に変換される。なお、ＹＵＶ画像は、輝度信号（Ｙ）、輝度信号と青色成分との差（Ｕ）、輝度信号と赤色成分の差（Ｖ）の３つの情報によって画像上の色を表現する色表現形式を有する画像である。

サーバＦ０１は、上述のステップＳ１４０３で得られた現ＹＵＶ画像のＹ値（輝度）と前ＹＵＶ画像のＹ値（輝度）とを入力値とし、これらのＹ値同士を比較することによってフェードが発生しているか否かの検出を行う（ステップＳ１４０４）。なお、フェード検出方法に関しては、例えば特許文献２に開示されている技術を利用することが可能であり、ここでは詳細な説明を省略する。また、本発明において、フェードが発生しているか否かを判断する方法は、特許文献２に開示されている技術に限定されるものではなく、任意の方法を用いることが可能である。

サーバＦ０１は、ステップＳ１４０４の処理結果から、条件２『フェードの発生が検出されたか否か』を判断する（ステップＳ１４０５）。フェードの発生が検出された場合にはステップＳ１４０６に進み、フェードの発生が検出されなかった場合にはステップＳ１４１０に進む。

ステップＳ１４０５でフェードの発生が検出された場合には、さらに、サーバＦ０１は、フェードテーブル格納部１２０２内のフェードテーブルを参照して、条件３『入力描画データと同一の位置（Ｘ、Ｙ）及び大きさ（Ｗ、Ｈ）を有する描画データが、フェードテーブルに登録されているか否か』を検索する（ステップＳ１４０６）。この検索の結果、同一の位置及び大きさの描画データがフェードテーブルに登録されている場合にはステップＳ１４０７に進み、同一の位置及び大きさの描画データがフェードテーブルに登録されていない場合にはステップＳ１４０９に進む。

ステップＳ１４０６で同一の位置及び大きさの描画データがフェードテーブルに登録されている場合には、条件４『フェードテーブル内の該当フェードに対応する行（エントリ）のフェード終了フラグが『０』であるか否か』を確認する（ステップＳ１４０７）。フェード終了フラグが『１』の場合にはステップＳ１４０８に進み、フェード終了フラグが『０』の場合にはステップＳ１４０９に進む。

ステップＳ１４０７でフェード終了フラグ『１』が確認された場合には、サーバＦ０１はフェード継続処理を行う（ステップＳ１４０８）。フェード継続処理では、前ＢＭＰ画像から現画像ＢＭＰ画像に移る映像が継続してフェード状態にあるとみなされ、サーバＦ０１は、フェードテーブルにおいて、位置（Ｘ、Ｙ）及び大きさ（Ｗ、Ｈ）に対応するインデックスのフェード枚数のカウントを１枚増やす処理を行う。

また、ステップＳ１４０７でフェード終了フラグ『１』が確認された場合や、ステップＳ１４０６で同一の位置及び大きさのフェードがフェードテーブルに既に登録されていない場合には、サーバＦ０１はフェード初期処理を行う（ステップＳ１４０９）。フェード初期処理では、前ＢＭＰ画像から現画像ＢＭＰ画像に移る映像において新たなフェードが発生したとみなされ、サーバＦ０１は、フェードテーブルのデータに新たな行（エントリ）を設定して、下記の数値をセットする。
・位置（Ｘ、Ｙ）及び大きさ（Ｗ、Ｈ）に、フェードが発生している画像の位置及び大きさをセット
・フェード開始固有値に、描画データの固有値をセット
・フェード開始ＲＧＢ値に、対象領域（Ｗ、Ｈ）の全画素の各色値（Ｒ、Ｇ、Ｂ）の平均値を求めて代入
・フェード開始時刻に、現時刻（少なくともフレーム取得部４０２の取得間隔未満の精度を持つ絶対時刻、例えば１０ミリ秒の精度を持つ協定世界時とする）をセット

一方、ステップＳ１４０５でフェードの発生が検出されなかった場合には、サーバＦ０１は、ステップＳ１４０６と同様に、フェードテーブル格納部１２０２内のフェードテーブルを参照して、条件３『描画データの位置（Ｘ、Ｙ）及び大きさ（Ｗ、Ｈ）が、フェードテーブルに登録されているか否か』を検索する（ステップＳ１４１０）。

ステップＳ１４１０における検索の結果、同一の位置（Ｘ、Ｙ）及び大きさ（Ｗ、Ｈ）の描画データがフェードテーブルに登録されていない場合には、処理は終了となる。一方、同一の位置（Ｘ、Ｙ）及び大きさ（Ｗ、Ｈ）の描画データがフェードテーブルに登録されている場合には、前ＢＭＰ画像から現ＢＭＰ画像に移る映像においてフェードが終了したとみなされ、フェード終了処理が行われる（ステップＳ１４１１）。フェード終了処理では、フェードテーブルの当該フェードに対応する行（エントリ）に対して、下記の数値がセットされる。
・フェード終了フラグに『１』をセット
・フェード最後固有値に、描画データの固有値をセット
・フェード最後ＲＧＢ値に、対象領域（Ｗ、Ｈ）の全画素の各色値（Ｒ、Ｇ、Ｂ）の平均値を求めて代入
・フェード最後時刻に、現時刻をセット
・フェード枚数のカウントを１枚増やす
・フェード係数（Ｒ、Ｇ、Ｂ）に、以下の式で求められる数値をセット
Ｒ ＝ （フェード開始Ｒ値−フェード最後Ｒ値）÷フェード枚数 ・・・（式１）
Ｇ ＝ （フェード開始Ｇ値−フェード最後Ｇ値）÷フェード枚数 ・・・（式２）
Ｂ ＝ （フェード開始Ｂ値−フェード最後Ｂ値）÷フェード枚数 ・・・（式３）
・フェードスパンに、差分時刻（フェード最後時刻−フェード開始時刻）をセット

上述の図８に図示されているフェードテーブル作成のためのフェード検出処理によれば、任意のアプリケーションで使用されているフェード効果を検出し、そのフェードを再現するための特徴（図１６に図示されているフェードテーブルの各項目によって特定されるような特徴）を検出して、フェードテーブルに格納することが可能となる。すなわち、図７において、ステップＳ１３０２で得られたフェード検出処理の結果は、例えば図１６に図示されているフェードテーブルに追加登録されることで、フェードテーブルの更新が行われる（ステップＳ１３０３）。そして、前フレームバッファ４０４には、今回取得した画像データ（フレームバッファ４０１内の画像データ）が上書きされ（ステップＳ１３０４）、ステップＳ１３０５において、何らかの終了条件が成立している場合には動作を終了する一方、終了条件が存在しない場合にはステップＳ６０１に戻って上記の処理が繰り返し行われる。

一方、図７のステップＳ１３０１におけるクライアントの接続／非接続の判断において、サーバＦ０１とクライアントＦ０２との接続が検出されなかった場合にはステップＳ１３０６に進む。このとき、サーバＦ０１では、前フレームバッファ４０４が空か否かを確認することによって、初回の画像データ取得動作か否かの判定が行われる（ステップＳ１３０６）。前フレームバッファ４０４が空の場合（画像データが１度も書き込まれていない場合）にはステップＳ１３０８に進み、前フレームバッファ４０４が空ではない場合にはステップＳ１３０７における比較処理及び変換処理が行われる。

以下、図９を参照しながら、上記のステップＳ１３０８における比較処理及び変換処理の詳細について説明する。図９には、本発明の第１の実施の形態において、サーバＦ０１の比較決定部１２０３で行われる比較処理及び変換処理の一例を示すフローチャートが図示されている。

図９において、まず、サーバＦ０１の比較決定部１２０３は、固有値算出部８０１から供給される描画データの固有値と、テーブル格納部８０４内のテーブルに保持されている固有値とを比較して、条件１『固有値算出部８０１から供給される描画データの固有値と同一のものがテーブル格納部８０４内のテーブルに保持されているか否か』を判断する（ステップＳ１５０１）。

このとき、ステップＳ１５０１で同一の固有値がテーブルに存在する場合には、条件２『固有値算出部８０１から供給された入力描画データの位置（Ｘ、Ｙ）及び大きさ（Ｗ、Ｈ）がフェードテーブルに登録されているか否か』を判断する（ステップＳ１５０２）。そして、入力描画データの位置（Ｘ、Ｙ）及び大きさ（Ｗ、Ｈ）がフェードテーブルに登録されている場合には、さらに、条件４『フェードテーブル内の該当する行（エントリ）のフェード処理中フラグが『１』であるか否か』の判断が行われる（ステップＳ１５０３）。

ステップＳ１５０３においてフェード処理中フラグが『１』の場合には、入力描画データに関して、フェード状態中処理が行われる（ステップＳ１５０４）。なお、フェード状態中処理が行われる場合は、入力描画データに係る表示がフェード状態にある。以下、図１７を参照しながら、上記のステップＳ１５０４におけるフェード状態中処理の詳細について説明する。図１７には、本発明の第１の実施の形態において、サーバＦ０１の比較決定部１２０３で行われるフェード状態中処理の一例を示すフローチャートが図示されている。

図１７において、まずサーバＦ０１の比較決定部１２０３は、条件１『入力描画データの固有値と、フェードテーブル内のフェード最後固有値とを比較し、これらの値が同一であるか否か同等であるか否か』を判断する（ステップＳ１７０１）。

ステップＳ１７０１において、入力描画データの固有値とフェードテーブル内のフェード最後固有値とが同一の場合には、フェード状態が終了したと判断され、フェード終了データ作成処理が行われる（ステップＳ１７０２）。ステップＳ１７０２のフェード終了データ作成処理では、下記のデータ構造３のデータが作成され、さらにデータ構造３に沿ったデータの各数値が下記のようにセットされる。

（フェード情報フラグ、フェードＳＥフラグ、フェード開始Ｘ座標、フェード開始Ｙ座標、フェード画像の横幅、フェード画像の高さ、フェード開始固有値、フェード係数（Ｒ、Ｇ、Ｂ）、フェードスパン）・・・＜データ構造３＞
・フェードに関する情報であることを示すフェード情報フラグに『１』をセット
・フェードＳＥフラグにフェード終了を示す『１』をセット
・その他のデータには『０』をセット

なお、データ構造３に沿ったデータのフェード情報フラグは、例えば『１』にセットされるとフェードに関連する情報の存在を示し、『０』にセットされるとフェードとは無関係の情報の存在を示す情報である。また、フェードＳＥフラグは、フェードの開始又は終了を示す情報であり、例えば『１』にセットされるとフェードの終了を示し、『０』にセットされるとフェードの開始を示す情報である。また、フェード開始Ｘ座標及びＹ座標は、フェードが発生する位置を示す情報であり、フェード画像の横幅及び高さは、フェードの領域（大きさ）を示す情報である。また、フェード開始固有値は、フェードの開始時の描画データを特定するための情報である。なお、フェード開始固有値に代わってフェード最後固有値が含まれてもよい。また、フェード係数は、フェード開始ＲＧＢ値からフェード最後ＲＧＢ値までの遷移をフェードスパン（又はフェード枚数）で除算した値であり、画像に対してこのフェード係数の値を連続的に付加していくことで、擬似的なフェード効果を作り出すことが可能となる。また、フェードスパンは、フェードの開始時刻から終了時刻までの総時間であり、例えば秒によって表される。

一方、ステップＳ１７０１において、入力描画データの固有値とフェードテーブル内のフェード最後固有値とが同一ではない場合には、条件２『フェードタイマ≧フェードスパン』を満たしているか否かの判断が行われる（ステップＳ１７０３）。この条件２が満たされている場合（すなわち、フェードスパン以上の時間だけフェード状態の時間が経過）には、上述のステップ１７０２に進んで、ステップＳ１７０２に係る処理が行われる。また、この条件２が満たされていない場合にはフェード状態中（フェードが終了していない状態）であり、データの作成は行われず、フェード状態中処理はそのまま終了となる。なお、フェードタイマは、後述のステップＳ１５０９において、フェード状態の開始時に起動され、フェード状態の経過時間を計測するためのものである。

また、図９において、ステップＳ１５０２で入力描画データの位置（Ｘ、Ｙ）及び大きさ（Ｗ、Ｈ）がフェードテーブルに登録されている場合や、ステップＳ１５０３においてフェード処理中フラグが『０』の場合には、ステップＳ１５０５に進む。ステップＳ１５０５では、フェード非発生状態の処理が行われて、クライアントＦ０２に送信するデータが作成される。この場合、データ構造２に沿ったデータが作成されるが、さらに、フェードが発生していないことを示す『０』の値がセットされたフェード情報フラグがデータ構造２のデータに付加される。すなわち、ステップＳ１５０５では、例えばデータ構造２のデータにフェード情報フラグが設定された、下記のようなデータ構造４のデータが作成される。
（フェード情報フラグ、データ構造２のデータ）・・・＜データ構造４＞

一方、ステップＳ１５０１で同一の固有値がテーブル格納部８０４内のテーブルに存在しない場合には、条件３『入力描画データの固有値がフェードテーブルに登録されているか否か』の判断が行われる（ステップＳ１５０６）。ステップＳ１５０６で入力描画データの固有値がフェードテーブルに登録されていない場合には、ステップＳ１５０５と同様にフェード非発生状態の処理が行われる（ステップＳ１５１０）。この場合もステップＳ１５０６と同様に、フェード情報フラグが『０』にセットされたデータ構造３のデータが作成される。

一方、ステップＳ１５０６で入力描画データの固有値がフェードテーブルに登録されている場合には、ステップＳ１５０３と同様に、条件４『フェードテーブル内の該当する行（エントリ）のフェード処理中フラグが『１』であるか否か』の判断が行われる（ステップＳ１５０７）。そして、ステップＳ１５０７においてフェード処理中フラグが『１』の場合には、ステップＳ１５０４と同様に、入力描画データに関してフェード状態中処理が行われる一方（ステップＳ１５０８）、ステップＳ１５０７においてフェード処理中フラグが『０』の場合には、フェード状態が開始されたとみなされて、フェード初期処理が実行される（ステップＳ１５０９）。

ステップＳ１５０９におけるフェード初期処理では、入力描画データの位置（Ｘ、Ｙ）及び大きさ（Ｗ、Ｈ）で特定される領域においてフェードが始まると判断され、クライアントＦ０２に対して送信する上述のデータ構造３に沿ったデータが作成されるとともに、フェードタイマを０にセットして起動し、さらに、データ構造３に沿ったデータに対して下記のパラメータの設定が行われる。

・フェード情報フラグに『１』を代入
・フェードの開始終了を示すフラグであるフェードＳＥフラグにフェードが開始することを示す『０』をセット
・フェードの開始Ｘ座標及びＹ座標に、入力画像データの位置（Ｘ、Ｙ）をセット
・フェード画像の横幅及び高さに、入力画像データの大きさ（Ｗ、Ｈ）をセット
・フェード開始固有値に、入力描画データの固有値をセット
・フェード最後固有値に、このフェードに対応したフェードテーブル内のフェード最後固有値をセット
・フェード係数（Ｒ、Ｇ、Ｂ）に、このフェードに対応したフェードテーブル内のフェード係数（Ｒ、Ｇ、Ｂ）をセット
・フェードスパンに、このフェードに対応したフェードテーブル内のフェードスパンをセット

次に、図１０を参照しながら、図６に図示されているクライアントＦ０２の動作の一例について説明する。図１０には、本発明の第１の実施の形態におけるクライアントＦ０２の動作の一例を示すフローチャートが図示されている。

クライアントＦ０２では、まず、サーバＦ０１から送信されるＶＮＣプロトコルに沿ったデータを受信し、このデータを元のデータ構造（データ構造３又はデータ構造４）に沿ったデータ（以下、入力データと記載）に変換する（ステップＳ２００１）。なお、上述のサーバＦ０１は、クライアントＦ０２に送信するデータに対して、フェード情報フラグを付加している。そして、入力データを受け取ったフェード処理部１２０６は、フェード処理を行う（ステップＳ２００２）。

以下、図１１を参照しながら、上記のステップＳ２００２におけるフェード処理の詳細について説明する。図１１には、本発明の第１の実施の形態において、クライアントＦ０２のフェード処理部１２０６で行われるフェード処理の一例を示すフローチャートが図示されている。

図１１において、フェード処理部１２０６は、まず、条件１『入力データのフェード情報フラグが『１』であるか否か』を判断する（ステップＳ２１０１）。このとき、フェード情報フラグが『１』（フェードに関する情報であることを示す）の場合にはステップＳ２１０２に進み、『０』の場合にはステップＳ２１０５へ移動する。

ステップＳ２１０１でフェード情報フラグが『１』であることが検出された場合には、続いて条件２『フェードＳＥフラグが『０』であるか否か』の判断が行われる（ステップＳ２１０２）。このとき、フェードＳＥフラグが『０』（フェードの開始を示す）の場合にはステップＳ２１０３に進み、『１』の場合にはステップＳ２１０４に進む。

ステップＳ２１０２でフェードＳＥフラグが『０』であることが検出された場合には、フェード開始処理が行われる（ステップＳ２１０３）。ステップＳ２１０３のフェード開始処理ではフェード処理が開始されて、下記のように描画データ及びフェードテーブルデータが作成される。

１．入力データより、位置（フェード開始Ｘ座標、フェード開始Ｙ座標）、大きさ（フェード画像の横幅、フェード画像の高さ）を取得し、前フレームバッファ１２０８から上記の位置及び大きさのビットマップ画像を取得する。
２．取得したビットマップ画像の全画素に、入力データのフェード係数（Ｒ、Ｇ、Ｂ）を加算してフェード効果の反映されたビットマップ画像を作成し、位置及び大きさの情報を付加して、描画作成部８０６に供給する描画データを作成する。
３．（フェードテーブル更新フラグ、フェード処理中フラグ、フェードタイマ、入力データ）で構成されたデータ構造５に沿ったフェードテーブルデータを作成する。
４．フェードタイマを『０』にセットして起動する。
５．フェード処理中フラグに『１』をセットする。
６．フェードテーブル更新フラグに『１』をセットする。

なお、データ構造５に沿ったフェードテーブルデータのフェードテーブル更新フラグは、例えば『１』にセットされるとフェードテーブルの更新を示し、『０』にセットされるとフェードテーブルの維持（更新を行わないこと）を示す情報である。また、フェード処理中フラグは、例えば『１』にセットされるとこのフェードが現在処理中であることを示し、『０』にセットされるとこのフェードが現在処理中ではないことを示す情報である。また、フェードタイマはフェード状態の経過時間を計測するタイマの起動（又は停止）を指示するための情報である。

また、ステップＳ２１０２でフェードＳＥフラグが『１』であることが検出された場合には、フェード終了処理が行われる（ステップＳ２１０４）。ステップＳ２１０４のフェード終了処理ではフェード処理が終了され、下記のように描画データ及びフェードテーブルデータが作成される。

１．入力データからフェード最後固有値を取得し、フェードテーブル内で該当するデータを検索して、そのデータに対応するフェードテーブルデータを取得する。
２．取得したフェードテーブルデータのフェード処理中フラグに『０』をセットする。
３．取得したフェードテーブルデータのフェードタイマに『０』をセットする。
４．取得したフェードテーブルデータのフェードテーブル更新フラグに『１』をセットする。
５．前フレームバッファ１２０８から、該当する位置及び大きさのビットマップ画像データを取得し、取得したビットマップ画像の全画素に対して該当フェードテーブルのフェード係数（Ｒ、Ｇ、Ｂ）を加算して、フェード効果の反映されたビットマップ画像データを作成し、位置及び大きさの情報を付加して、描画作成部８０６に供給する描画データを作成する。

また、ステップＳ２１０１でフェード情報フラグが『０』であることが検出された場合には、条件３『フェード処理中フラグを検索し、フェード処理中フラグが『１』であるものが存在するか否か』の判断が行われる（ステップＳ２１０５）。このとき、フェード処理中フラグが『１』であるものが存在しない場合には、フェード状態にある描画データは存在せず、フェード処理は終了となる。

一方、フェード処理中フラグが『１』であるものが存在する場合には、続いて、条件４『フェードタイマ≧フェードスパン』を満たしているか否かの判断が行われる（ステップＳ２１０６）。このとき、ステップＳ２１０６でフェードタイマ≧フェードスパンの場合には、このフェード効果は既にタイムアウト状態にあり、ステップＳ２１０４と同様に、フェード終了処理が行われる（ステップＳ２１０７）。

一方、ステップＳ２１０６でフェードタイマ＜フェードスパンの場合には、現在進行中のフェードに対するフェード中間処理が行われる（ステップＳ２１０８）。ステップＳ２１０８のフェード中間処理では、下記のように描画データ及びフェードテーブルデータの作成が行われる。

１．フェードテーブルから、フェード処理中フラグが『１』であるデータを検索して取得するとともに、前フレームバッファ１２０８から、該当する位置及び大きさのビットマップ画像データを取得し、取得したビットマップ画像データと、登録されているフェード係数（Ｒ、Ｇ、Ｂ）を加算し、フェード効果の反映されたビットマップ画像を作成する。そして、作成されたビットマップ画像に位置及び大きさの情報を付加し、描画作成部８０６に出力するデータを作成する。
２．データ構造５に沿ったフェードテーブルデータに全て『０』をセットする（あるいは、フェードテーブルの更新が行われないように、少なくともフェードテーブル更新フラグのみが『０』にセットされてもよい）。

なお、上述のフェード処理の際に作成されるビットマップ画像データはいずれも、直前の描画データ（あるいは、フェード開始固有値で指定された描画データ）に対して所定のフェード係数（Ｒ、Ｇ、Ｂ）を加算することによって得られる画像データである。これによって、フェード終了時に表示される画像（例えば、真っ白又は真っ黒な画像）に向けて徐々に色調が変化するフェード効果が得られるようになる。なお、フェード係数としてＹ値（輝度）を使用することによって、徐々に輝度が変化するフェード効果を実現することも可能である。

図１０において、ステップＳ２００２のフェード処理が完了した後、フェード処理によって作成されたフェードテーブルデータによるフェードテーブルの更新処理が行われる（ステップＳ２００３）。一方、フェードとは無関係のデータに関しては、上述の本発明の第１及び第２の実施の形態が前提とする動作と同様の描画作成処理（図４のステップＳ１００２の描画処理）が行われ（ステップＳ２００４）、必要に応じてテーブル格納部８０７内のテーブルの更新が行われる（ステップＳ２００５）。さらに、ステップＳ２００３のフェード処理によって作成されたデータやステップＳ２００４の描画作成処理によって作成されたデータに基づいて、描画作成部８０６における描画処理が行われる（ステップＳ２００６）。

そして、出力部４０９は、フレームバッファ４０８を順次読み出し、Ｄ／Ａ変換などの所望の信号処理を行ってディスプレイ４１０への出力を行い（ステップＳ２００７）、さらに、前フレームバッファ１２０８に入力描画データが上書きされる（ステップＳ２００８）。その後、ステップＳ２００９において、何らかの終了条件が成立している場合には動作を終了する一方、終了条件が存在しない場合にはステップＳ２００１に戻って上記の処理が繰り返し行われる。

以上、説明したように、本発明の第１の実施の形態におけるリモートデスクトップシステムは、サーバ側で起こり得るフェード表示に関する特徴をあらかじめ把握しておき、サーバ側でフェード表示が発生した場合に、クライアント側で擬似的にフェードを再現するために、クライアントに対してフェード表示に関する特徴のみを送信することで、フェード発生時に伝送されるデータ量を削減することが可能となり、クライアント側における遅延や表示の不具合（ぎこちない表示）などを抑えることが可能となる。特に従来の技術と比較した場合、従来の技術ではフェード発生時にはサーバからクライアントに対して画像データを送信していたのに対し、本発明の第１の実施の形態では、サーバからクライアントにフェード命令を一度送信することでフェードを実現することができ、サーバからクライアントにフェード発生時に伝送されるデータ量を大幅に削減することが可能となる。

＜第２の実施の形態＞
次に、本発明の第２の実施の形態について説明する。図１２は、本発明の第２の実施の形態におけるリモートデスクトップシステムの一構成例を示すブロック図である。図１２に図示されているリモートデスクトップシステムは、サーバＧ０１とクライアントＧ０２とが任意のデータ伝送路を介して接続された構成を有している。

以下、図１２に図示されているサーバＧ０１の構成について説明する。図１２に図示されているサーバＧ０１は、フレームバッファ４０１、フレーム取得部４０２、比較部４０３、前フレームバッファ４０４、スクロール処理部２２０１、固有値算出部２２０２、テーブル格納部８０４、比較決定部２２０３、通信部２２０４を有している。

図１２に図示されているサーバＧ０１のフレームバッファ４０１、フレーム取得部４０２、比較部４０３、前フレームバッファ４０４には、従来の技術で説明した図２１に図示されているＶＮＣサーバＤ０１のフレームバッファ４０１、フレーム取得部４０２、比較部４０３、前フレームバッファ４０４を利用することが可能である。また、図１２に図示されているテーブル格納部８０４には、図１に図示されているテーブル格納部８０４を利用することが可能である。

図１２の構成では、比較部４０３から出力される描画データを含むデータ構造１に沿ったデータは、スクロール処理部２２０１に供給される。スクロール処理部２２０１は、比較部４０３から供給されるデータ構造１に沿ったデータに加えて、前フレームバッファ４０４内の画像データを参照して、スクロール検出を行う。そして、スクロールが検出された場合には、スクロール処理部２２０１は、下記のデータ構造６のデータを作成して固有値算出部２２０２に出力する。

（スクロールフラグ、画面上のＸ座標、画面上のＹ座標、ビットマップ画像の横幅、ビットマップ画像の高さ、ビットマップ画像、スクロールＸ座標、スクロールＹ座標）・・・＜データ構造６＞

なお、データ構造６に沿ったデータのスクロールフラグには、スクロール検出の有無を示す情報が挿入される。また、スクロールＸ座標及びＹ座標には、スクロールによって移動した画像がスクロール前に存在していた位置を示す情報が挿入される。

また、固有値算出部２２０２は、スクロール処理部２２０１から供給されるデータ構造６に沿ったデータを受け取ると、このデータ構造６に沿ったデータに基づいて、比較決定部２２０３に出力するためのデータ（下記のデータ構造７に沿ったデータ）を作成して、比較決定部２２０３に出力する。

（スクロールフラグ、ビットマップ存在フラグ、画面上のＸ座標、画面上のＹ座標、ビットマップ画像の横幅、ビットマップ画像の高さ、ビットマップ画像、スクロールＸ座標、スクロールＹ座標、固有値）・・・＜データ構造７＞

なお、データ構造６からデータ構造７への変換は、基本的には、上述のデータ構造１からデータ構造２への変換と同一である。スクロール処理部２２０１におけるデータ構造６のデータ作成や、固有値算出部２２０２におけるデータ構造７のデータ作成に関しては、後で詳細に説明する。

また、通信部２２０４は、比較決定部２２０３から供給されるデータ構造７に沿ったデータを、例えばＶＮＣプロトコルに変換してクライアントＧ０２に送信する。

一方、図１２に図示されているクライアントＧ０２は、通信部２２０５、描画作成部２２０６、テーブル格納部８０７、フレームバッファ４０８、出力部４０９、ディスプレイ（ビットマップディスプレイ）４１０を有している。

なお、図１２に図示されている本発明の第２の実施の形態におけるクライアントＧ０２は、後述のようにサーバＧ０１がデータ構造７のデータ（スクロールフラグが付加されたデータ）をクライアントＧ０２に送信する場合が考えられるので、クライアントＧ０２は、データ構造７のデータに係る処理を行って、適切にスクロール表示を行うことができることが望ましい。しかしながら、サーバＧ０１は、スクロール検出時であっても、基本的に本発明の第１及び第２の実施の形態の前提において説明した動作によって、効率良いデータ伝送を行うことが可能であり、すなわち、クライアントＧ０２の構成は、本発明の第１及び第２の実施の形態の前提において説明したものと同一の構成であってもよい。さらに、サーバＧ０１は、スクロール検出時に、後述のようにＶＮＣシステムで使用されているcopyrecコマンド（特定の領域を他の領域にコピーさせるコマンド）によって、スクロール検出時において効率良いデータ伝送を実現することが可能である。すなわち、クライアントＧ０２は、従来のＶＮＣシステムにおけるクライアントと同一の構成であってもよい。

次に、図１３を参照しながら、図１２に図示されているサーバＧ０１の動作の一例について説明する。図１３は、本発明の第２の実施の形態におけるサーバの動作の一例を示すフローチャートである。

サーバＧ０１では、本発明の第１及び第２の実施の形態の前提（図２参照）と同様に、フレーム取得部４０２がフレームバッファ４０１から画像データ（描画データ）を取得する（ステップＳ６０１）。そして、スクロール処理部２２０１では、比較部４０３から供給されるデータ構造１のデータに基づいて、スクロール処理が行われる（ステップＳ２３０１）。

以下、図１４を参照しながら、上記のステップＳ２３０１におけるスクロール処理の詳細について説明する。図１４は、本発明の第２の実施の形態において、サーバのスクロール処理部で行われるスクロール処理の一例を示すフローチャートである。

スクロール処理では、スクロール処理部２２０１は、まず比較部４０３から供給されるデータ構造１に沿ったデータのビットマップ画像の横幅（以下、Ｗと記載）、及びビットマップ画像の高さ（以下、Ｈと記載）を、あらかじめ定められた閾値Ｔｗ２、Ｔｈ２と比較し、『Ｗ＞Ｔｗ２、かつ、Ｈ＞Ｔｈ２』を満たしているか否かを判断する（ステップＳ２４０１）。『Ｗ＞Ｔｗ２、かつ、Ｈ＞Ｔｈ２』の条件が満たされている場合にはステップＳ２４０２に進み、『Ｗ＞Ｔｗ２、かつ、Ｈ＞Ｔｈ２』の条件が満たされていない場合にはステップＳ２４０５に進む。

ステップＳ２４０１で『Ｗ＞Ｔｗ２、かつ、Ｈ＞Ｔｈ２』の条件が満たされている場合には、スクロール処理部２２０１は、データ構造１に沿った入力描画データのビットマップ画像を任意サイズ（Ｎ×Ｍ）のブロックに分割する（ステップＳ２４０２）。この画像分割によって、例えば１６×１６画素の矩形領域が１ブロックとして分割される。

そして、ステップＳ２４０２で分割された画像の各ブロックに対して、前フレームバッファ４０４のビットマップ画像を使用して、動きベクトル検出が行われる（ステップＳ２４０３）。例えば、時系列的に隣接するフレーム内の表示対象物の動きベクトルを検出し、所定領域以上がまとまって同一方向及び同一距離だけ移動している場合に、スクロールが発生していると判断することが可能である。ただし、ここでは、スクロールの検出を行うことを目的としており、検索する方向は上下左右（スクロールにおける通常の移動方向）とする。なお、処理負荷が大きくなるとともに処理が複雑になるものの、任意の方向における動きベクトルの検出を行うことも可能である。

また、動きベクトル検出を行う範囲に関しては、画面全体をその範囲としてもよいが、より狭い範囲（例えばＷ／２又はＨ／２）として、処理負荷を軽減することが望ましい。なお、この動きベクトル検出では、１６×１６の１ブロック内のすべての画素が一致することを条件とすることが望ましい。また、分割したブロックすべてに関して動きベクトル検出及び比較を行う必要はなく、複数の分割ブロックのうちの１つに着目して動きベクトル検出及び比較を行ってもよい。

次に、スクロール処理部２２０１は、ステップＳ２４０３で動きベクトルが検出されたか否かをチェックする（ステップＳ２４０４）。このとき、動きベクトルの検出結果から、検索方向（上下方向）に関して複数の画素のまとまりが同一方向かつ同一距離だけ動くような動きが検出されなかった場合には、ステップＳ２４０５に進む。この場合には、スクロールと判断できる動きが存在しないので、入力されたデータ構造１のデータに対して下記の設定を加えて、データ構造６のデータを作成する（ステップＳ２４０５）。
・スクロールフラグ＝０にセット
・スクロールＸ座標＝０にセット
・スクロールＹ座標＝０にセット

一方、動きベクトルの検出結果から、検索方向（上下方向）に関して複数の画素のまとまりが同一方向かつ同一距離だけ動くような動きが検出された場合には、スクロール処理部２２０１は、ステップＳ２４０３で算出された動きベクトルと同一の動きベクトルを有するブロックをまとめてスクロール領域を特定し（ステップＳ２４０６）、このスクロールに関するデータを作成するとともに、このスクロールによって移動した画像データ（移動前から存在していた画像データ）に関するデータ構造６のデータの作成を行う（ステップＳ２４０７）。さらに、スクロールによって新たに出現した画像データも存在しており、この新たに出現した画像データに関してデータ構造６のデータの作成も行われる（ステップＳ２４０８）。

ここで、図１５に図示されている具体的な画像を一例に挙げて、本発明の第２の実施の形態におけるスクロールの概念について説明する。なお、図１５の左側にはスクロール前の画像（前画像）が図示されており、右側にはスクロール後の画像（現画像）が図示されている。

図１５において、画像領域（１）は前画像では存在していたが、下方向（画像は上方向に移動）にスクロールしたことにより、現画像では存在しなくなった画像である。一方、図１５の画像領域（２）は、前画像で（Ｘ１、Ｙ１）の位置に（Ｗ、Ｈ１）の大きさで存在した画像であり、下方向にスクロールすることにより、現画像では（Ｘ０、Ｙ０）の位置に移動して存在している。なお、画像領域（２）の性質を有する画像をスクロール移動画像と呼ぶことにする。また、図１５の画像領域（３）は、下方向にスクロールすることにより、新たに出現した画像である。画像領域（３）の大きさは（Ｗ、Ｈ２）であり、位置は（Ｘ２、Ｙ２）である。なお、画像領域（３）の性質を有する画像をスクロール新規画像と呼ぶことにする。このように、スクロールによって画像が移動した場合には、以前から存在しておりスクロールによって移動したスクロール移動領域の画像データ（画像領域（２））と、スクロールによって新たに出現したスクロール新規領域の画像データ（画像領域（３））とに分けることが可能である。

上述のステップＳ２４０７では、図１５の画像領域（２）に関するデータの作成が行われる。具体的には、図１５の画像領域（２）に関して、下記のデータ構造６に沿ったデータが作成される。
・スクロールフラグ＝１をセット
・スクロールＸ座標＝Ｘ１をセット
・スクロールＹ座標＝Ｙ１をセット
・画面上のＸ座標＝Ｘ０をセット
・画面上のＹ座標＝Ｙ０をセット
・ビットマップ画像の横幅＝Ｗをセット
・ビットマップ画像の高さ＝Ｈ１をセット
・ビットマップ画像＝ＮＵＬＬをセット

また、上述のステップＳ２４０８では、図１５の画像領域（３）に関するデータの作成が行われる。具体的には、図１５の画像領域（３）に関して、下記のデータ構造６に沿ったデータが作成される。
・スクロールフラグ＝０をセット
・スクロールＸ座標＝０をセット
・スクロールＹ座標＝０をセット
・画面上のＸ座標＝Ｘ２をセット
・画面上のＹ座標＝Ｙ２をセット
・ビットマップ画像の横幅＝Ｗをセット
・ビットマップ画像の高さ＝Ｈ２をセット
・ビットマップ画像・・・画像領域（３）のビットマップ画像をセット

上述のように、図１３のステップＳ２３０１で行われたスクロール処理により作成されたデータ構造６のデータは、スクロール処理部２２０１から固有値算出部２２０２に供給される。そして、固有値算出部２２０２は、データ構造６のデータに含まれるスクロールフラグを解析し、スクロールフラグが『０』のビットマップ画像に対して固有値を算出する（ステップＳ２３０２）。ここで、サーバＧ０１では、前フレームバッファ４０４が空か否かを確認することによって、初回の画像データ取得動作か否かの判定を行い（ステップＳ２３０３）。このとき、前フレームバッファ４０４が空の場合（画像データが１度も書き込まれていない場合）には、ステップＳ２３０４の比較処理及び変換処理をスキップしてステップＳ２３０５に進み、前フレームバッファ４０４が空ではない場合にはステップＳ２３０４に進む。

ステップＳ２３０４では、比較決定部２２０３が、ステップＳ２３０２で算出した固有値を付加してデータ構造７のデータを作成し、出力する。なお、スクロールフラグが『１』のデータは、固有値にＮＵＬＬが代入されたデータ構造７のデータに変換される。さらに、比較決定部２２０３は、このデータに含まれる固有値や画像データのセットをテーブルに追加登録することによって、テーブル格納部８０４内のテーブルの更新を行う（ステップＳ２３０５）。

そして、比較決定部２２０３から出力されたデータは、例えばＶＮＣプロトコルに準拠したデータに変換された後にクライアントＧ０２に送信される（ステップＳ２３０６）。また、ＶＮＣシステムと同様に、前フレームバッファ４０４には、今回取得した画像データ（フレームバッファ４０１内の画像データ）が上書きされ（ステップＳ２３０７）、ステップＳ２３０８において、何らかの終了条件が成立している場合には動作を終了する一方、終了条件が存在しない場合にはステップＳ６０１に戻って上記の処理が繰り返し行われる。

なお、本発明の第２の実施の形態では、例えば図１５に示すスクロールが検出された場合に、サーバＧ０１は、新たな画像領域（３）の送信と、既存の画像領域（２）の利用指示をクライアントＧ０２に対して行う。上記の新たな画像領域（３）の送信はＶＮＣシステムにおける通常の画像データの送信によって実現可能であり、上記の既存の画像領域（２）の利用指示は、ＶＮＣシステムのcopyrecコマンドの使用によって実現可能である。したがって、本発明の第２の実施の形態では、クライアントＧ０２が、既存のＶＮＣシステムに係る機能しか有していない場合であっても、サーバＧ０１からクライアントＧ０２に効率良いデータ伝送を実現することが可能であり、高い汎用性が実現される。

以上、説明したように、本発明の第２の実施の形態では、リモートデスクトップシステムにおいて、動きベクトル検出によってスクロールが検出された場合に、スクロールによって単に表示画面上の位置が移動しただけの画像に関しては、クライアントでその位置を変えて（コピーを行って）表示するように指示することで、スクロール変化時に伝送されるデータ量を削減することが可能となり、クライアント側における遅延や表示の不具合（ぎこちない表示）などを抑えることが可能となる。特に従来の技術と比較した場合、従来の技術ではスクロール発生時にはサーバからクライアントに対して画像データを送信していたのに対して、本発明の第２の実施の形態では、サーバからクライアントにコピー命令を送信することでスクロールを実現することができ、サーバからクライアントにスクロール発生時に伝送されるデータ量を大幅に削減することが可能となる。

なお、本明細書では、本発明の第１及び第２の実施の形態に関して独立して説明を行ったが、これらの第１及び第２の実施の形態を任意に組み合わせて用いることも可能である。また、本発明を実現するサーバ及びクライアントとして、例えば汎用コンピュータを利用することも可能である。また、上述の説明では、サーバ及びクライアントが有する構成要素は機能ブロックによって模式的に図示されているが、これらの各構成要素は、ハードウェア又はソフトウェア（例えば、コンピュータによって実行可能なプログラム）によって実現することが可能である。例えば、上記した各装置の機能をプログラムによりコンピュータに実現させるようにしてもよい。また、このプログラムは、記録媒体から読み取られてコンピュータに取り込まれてもよいし、通信ネットワークを介して伝送されてコンピュータに取り込まれてもよい。

本発明は、リモートデスクトップシステムでフェードやスクロールなどの画像変化が発生した場合において、サーバとクライアントとの間において送受信する描画データ列のデータ量を大幅に削減でき、ＧＵＩの反応速度を向上させてユーザの利便性を向上するとともに、ユーザのストレスを軽減するという効果、クライアント側に復号化器を搭載させる必要がなく、クライアントの負荷を削減することができるという効果、異なる領域で同一の更新画像データが存在する場合であっても、新たにテーブルに追加することなく更新表示データを再現することができ、テーブル量を削減することができるという効果を有している。また、本発明は、サーバからクライアントに送信されるデータが全て可逆圧縮であるので、クライアント側で実現される画像データが一様になり、クライアント側で視覚的に安定した表示を実現できるという効果を有しており、キーボードなどの入力装置と、映像を表示することが可能なビットマップディスプレイなどの表示装置とを備えたクライアント装置から遠隔地にあるサーバ装置に対して、アプリケーションなどの操作指示を送信し、その結果として、サーバ装置からクライアント装置に送信される映像をクライアント装置で表示するリモートデスクトップシステムの技術に適用可能である。

本発明の第１及び第２の実施の形態が前提とするリモートデスクトップシステムの一構成例を示すブロック図である。 本発明の第１及び第２の実施の形態が前提とするリモートデスクトップシステムにおけるサーバの動作の一例を示すフローチャートである。 本発明の第１及び第２の実施の形態が前提とするリモートデスクトップシステムにおけるサーバの比較決定部で行われる比較処理及び変換処理の一例を示すフローチャートである。 本発明の第１及び第２の実施の形態が前提とするリモートデスクトップシステムにおけるクライアントの動作の一例を示すフローチャートである。 本発明の第１及び第２の実施の形態が前提とするリモートデスクトップシステムにおけるクライアントの描画作成部で行われる描画作成処理の一例を示すフローチャートである。 本発明の第１の実施の形態におけるリモートデスクトップシステムの一構成例を示すブロック図である。 本発明の第１の実施の形態におけるサーバの動作の一例を示すフローチャートである。 本発明の第１の実施の形態において、サーバのフェード処理部で行われるフェードテーブル作成のためのフェード検出処理の一例を示すフローチャートである。 本発明の第１の実施の形態において、サーバの比較決定部で行われる比較処理及び変換処理の一例を示すフローチャートを示す図である。 本発明の第１の実施の形態におけるクライアントの動作の一例を示すフローチャートである。 本発明の第１の実施の形態において、クライアントのフェード処理部で行われるフェード処理の一例を示すフローチャートである。 本発明の第２の実施の形態におけるリモートデスクトップシステムの一構成例を示すブロック図である。 本発明の第２の実施の形態におけるサーバの動作の一例を示すフローチャートである。 本発明の第２の実施の形態において、サーバのスクロール処理部で行われるスクロール処理の一例を示すフローチャートである。 本発明の第２の実施の形態におけるスクロールの概念を説明するための図である。 本発明の第１の実施の形態において、サーバのフェードテーブル格納部に格納されるフェードテーブルの一例を示す図である。 本発明の第１の実施の形態において、サーバの比較決定部で行われるフェード状態中処理の一例を示すフローチャートである。 従来の技術におけるＴＳＳの一例を示すシステム構成図である。 従来の技術におけるＸウィンドウシステムの一例を示すシステム構成図である。 従来の技術におけるＶＮＣの一例を示すシステム構成図である。 従来の技術におけるＶＮＣシステムの一構成例を示すブロック図である。 図２１に示すＶＮＣサーバの処理の一例を示すフローチャートである。 図２１に示すＶＮＣクライアントの処理の一例を示すフローチャートである。 特許文献１に開示されているリモートデスクトップシステムの改良技術におけるサーバの処理の一例を示すフローチャートである。 図２４のＲＫＥＹ作成処理の詳細な処理を示すフローチャートである。 特許文献１に開示されているリモートデスクトップシステムの改良技術におけるクライアントの処理の一例を示すフローチャートである。 従来の技術におけるウィザード形式のアプリケーションにおける表示例を示す図である。 従来の技術におけるフェード表示を説明するための図である。 従来の技術におけるスクロールを説明するための図である。

符号の説明

１０１、３０１ アプリケーション
１０２ 端末サーバ
１０３ 端末装置
１０４ ディスプレイ
２０１ Ｘアプリケーション
２０２ Ｘサーバ
２０３ Ｘクライアント
２０４、３０５、４１０ ディスプレイ（ビットマップディスプレイ）
２０５ ポインティングデバイス
３０１ アプリケーション
３０２、４０１、４０８ フレームバッファ
３０３ ＶＮＣサーバ
３０４ ＶＮＣクライアント
３０６ ポインティングデバイス
４０２ フレーム取得部
４０３ 比較部
４０４、１２０８ 前フレームバッファ
４０５、４０６、８０３、８０５、１２０４、１２０５、２２０４、２２０５ 通信部
４０７ 描画部
４０９ 出力部
８０１、２２０２ 固有値算出部
８０２、１２０３、２２０３ 比較決定部
８０４、８０７ テーブル格納部
８０６、２２０６ 描画作成部
１２０１、１２０６ フェード処理部
１２０２、１２０７ フェードテーブル格納部
２２０１ スクロール処理部
Ａ０１ ＴＳＳを提供する汎用コンピュータ
Ａ０２ シリアル伝送
Ａ０３ ユーザ
Ｂ０１、Ｅ０１、Ｆ０１、Ｇ０１ サーバ
Ｂ０２、Ｃ０２ 通信ネットワーク
Ｂ０３、Ｃ０３、Ｅ０２、Ｆ０２、Ｇ０２ クライアント
Ｃ０１ 汎用コンピュータ
Ｄ０１ ＶＮＣサーバ
Ｄ０２ ＶＮＣクライアント

Claims (3)

1. クライアント装置に対して、前記クライアント装置の表示手段に表示させる画像データを送信するリモートデスクトップシステムのサーバ装置であって、
   前記クライアント装置の前記表示手段にフェード効果を有する表示を実現させる画像データを前記クライアント装置に送信しようとするフェード開始タイミングを検出するフェード検出手段と、
   前記フェード検出手段によって検出された前記フェード開始タイミングにおいて、前記フェード効果を有する表示を実現させる前記画像データを、前記クライアント装置に送信しないように制御するとともに、前記フェード効果を有する表示が行われる前記表示手段上の表示領域と、前記フェード開始タイミングと、前記フェード効果を有する表示の開始から終了までのフェード期間と、前記フェード期間中の前記表示領域における表示の態様とを指示する情報を前記クライアント装置に送信するフェード制御手段とを、
   有するサーバ装置。
2. クライアント装置に対して、前記クライアント装置の表示手段に表示させる画像データを送信するリモートデスクトップシステムのサーバ装置であって、
   前記クライアント装置に対して送信した前記画像データを格納する画像データ格納手段と、
   新たに前記クライアント装置に対して送信する第１画像データによって表示される表示対象と、前記画像データ格納手段に格納されている前記第１画像データの直前に前記クライアント装置に対して送信した第２画像データによって表示される表示対象との動きベクトルを検出する動きベクトル検出手段と、
   前記動きベクトル検出手段によって検出された前記動きベクトルから、所定領域以上の大きさの画像が、一定方向かつ一定距離だけ移動を行っている動きが検出された場合に、前記第１画像データの表示画像と前記第２画像データの表示画像との間でスクロールが起こっていると判断するスクロール判断手段と、
   前記スクロール判断手段で前記スクロールの発生が検出された前記第１画像データ及び前記第２画像データから、前記スクロールが起こっているスクロール領域を特定するスクロール領域特定手段と、
   前記第１画像データの表示画像の前記スクロール領域と前記第２画像データの表示画像の前記スクロール領域とを比較し、前記スクロールによって移動するスクロール移動領域の画像データ、及び、前記スクロールによって新たに表示されるスクロール新規領域の画像データを特定するスクロール画像データ特定手段と、
   前記クライアント装置に対して既に送信されている前記第２画像データの表示画像から前記スクロール移動領域の表示画像を抽出するように指示する情報と、前記スクロールに基づく前記スクロール移動領域の表示画像の新たな表示位置を指定する情報とを前記クライアント装置に送信し、前記クライアント装置に抽出させた前記表示画像を前記新たな表示位置に表示させる第１スクロール表示制御手段と、
   前記第１画像データの表示画像の一部を構成する前記第１画像データ内における前記スクロール新規領域の画像データのみを含むとともに、前記スクロール新規領域の表示画像の表示位置を指定する情報を前記クライアント装置に送信し、前記スクロール新規領域の表示画像をその表示位置に表示させる第２スクロール表示制御手段とを、
   有するサーバ装置。
3. サーバ装置から受信する画像データに基づいて画像表示を行うリモートデスクトップシステムのクライアント装置であって、
   画像表示を行う表示手段と、
   フェード効果を有する表示を実現させる画像データの代わりに、前記フェード効果を有する表示が行われる前記表示手段上の表示領域と、前記フェード開始タイミングと、前記フェード効果を有する表示の開始から終了までのフェード期間と、前記フェード期間中の前記表示領域における表示の態様とを指示する情報を前記サーバ装置から受信するフェード指示受信手段と、
   前記フェード開始タイミングから前記フェード期間の間、前記表示手段上の前記表示領域に前記フェード期間中の前記表示領域における前記表示の態様に基づく表示を行うように制御するフェード表示制御手段とを、
   有するクライアント装置。
   

Images