"ネットワークを介して接続された端末装置に表示させる表示用の画像を記憶する画像メモリと、ソフトウェアの処理結果を前記画像メモリに描画する描画部と、前記画像のフレーム間で更新があった更新領域を検出する更新領域検出部と、前記更新領域の画像で用いられる色に基づいてカラーマップを前記更新領域ごとに生成する第1の生成処理と、前記更新領域のそれぞれの画像で用いられる色に基づいて前記更新領域の間で共通して使用されるカラーマップを生成する第2の生成処理とを選択的に行う生成部と、前記更新領域を検出した数に応じて、前記第1の生成処理と第2の生成処理を切り換えて前記生成部に実行させ、生成されたカラーマップを用いて前記更新領域を減色する画像圧縮部と、前記画像圧縮部で圧縮された更新領域の画像を前記端末装置へ送信する送信部とを有することを特徴とする情報処理装置。前記画像のフレーム間で更新の頻度が所定の頻度以上である高頻度の変更領域を識別する識別部と、前記表示用の画像のうち前記識別部によって識別された高頻度の変更領域の画像を動画化する動画化部と、前記動画化部によって動画化された高頻度の変更領域の画像を前記端末装置へ送信する動画送信部とをさらに有し、前記生成部は、前記第1の生成処理と、前記第2の生成処理と、前記表示用の画像で用いられる色に基づいて前記動画化部による動画化中に前記端末装置へ送信された画像を上書きするための上書き用のカラーマップを生成する第3の生成処理とを選択的に行い、前記画像圧縮部は、前記動画化部による動画化が終了した後に、前記第3の生成処理を前記生成部に実行させ、生成された上書き用のカラーマップを用いて前記表示用の画像の全体もしくは一部を減色し、前記送信部は、前記画像圧縮部で圧縮された表示用の画像の全体もしくは一部を前記端末装置へ送信することを特徴とする請求項1に記載の情報処理装置。前記画像圧縮部は、前記画像メモリに描画された表示用の画像を構成する色の数が所定の色数以下である場合に、前記第2の生成処理を前記生成部に実行させることを特徴とする請求項1または2に記載の情報処理装置。コンピュータが、ネットワークを介して接続された端末装置に表示させる表示用の画像を記憶する画像メモリに対し、ソフトウェアの処理結果を描画し、前記画像のフレーム間で更新があった更新領域を検出し、前記更新領域を検出した数に応じて、前記更新領域の画像で用いられる色に基づいてカラーマップを前記更新領域ごとに生成する第1の生成処理と、前記更新領域のそれぞれの画像で用いられる色に基づいて前記更新領域の間で共通して使用されるカラーマップを生成する第2の生成処理とを選択的に切り換えて実行し、生成されたカラーマップを用いて前記更新領域を減色し、圧縮された更新領域の画像を前記端末装置へ送信する処理を実行することを特徴とする画像送信方法。コンピュータに、ネットワークを介して接続された端末装置に表示させる表示用の画像を記憶する画像メモリに対し、ソフトウェアの処理結果を描画し、前記画像のフレーム間で更新があった更新領域を検出し、前記更新領域を検出した数に応じて、前記更新領域の画像で用いられる色に基づいてカラーマップを前記更新領域ごとに生成する第1の生成処理と、前記更新領域のそれぞれの画像で用いられる色に基づいて前記更新領域の間で共通して使用されるカラーマップを生成する第2の生成処理とを選択的に切り換えて実行し、生成されたカラーマップを用いて前記更新領域を減色し、圧縮された更新領域の画像を前記端末装置へ送信する処理を実行させることを特徴とする画像送信プログラム。しかしながら、上記の従来技術では、減色処理および圧縮符号化を画面のブロックデータごとに実行する必要があるので、データ伝送量の削減に伴って圧縮処理の所要時間が増大するという問題がある。開示の技術は、上記に鑑みてなされたものであって、圧縮処理の所要時間を短縮できる情報処理装置、画像送信方法及び画像送信プログラムを提供することを目的とする。本願の開示する情報処理装置は、ネットワークを介して接続された端末装置に表示させる表示用の画像を記憶する画像メモリを有する。前記情報処理装置は、ソフトウェアの処理結果を前記画像メモリに描画する描画部を有する。前記情報処理装置は、前記画像のフレーム間で更新があった更新領域を検出する更新領域検出部を有する。前記情報処理装置は、第1の生成処理と第2の生成処理を選択的に行う生成部を有する。前記第1の生成処理は、前記更新領域の画像で用いられる色に基づいてカラーマップを前記更新領域ごとに生成する処理である。前記第2の生成処理は、前記更新領域のそれぞれの画像で用いられる色に基づいて前記更新領域の間で共通して使用されるカラーマップを生成する処理である。前記情報処理装置は、前記更新領域を検出した数に応じて、前記第1の生成処理と第2の生成処理を切り換えて前記生成部に実行させ、生成されたカラーマップを用いて前記更新領域を減色する画像圧縮部を有する。前記情報処理装置は、前記画像圧縮部で圧縮された更新領域の画像を前記端末装置へ送信する送信部とを有する。本願の開示する情報処理装置の一つの態様によれば、圧縮処理の所要時間を短縮できるという効果を奏する。以下に、本願の開示する情報処理装置、画像送信方法及び画像送信プログラムの実施例を図面に基づいて詳細に説明する。なお、この実施例は開示の技術を限定するものではない。そして、各実施例は、処理内容を矛盾させない範囲で適宜組み合わせることが可能である。[システム構成]まず、本実施例に係るシンクライアントシステムの構成について説明する。図1は、実施例1に係るシンクライアントシステムに含まれる各装置の機能的構成を示すブロック図である。図1に示すシンクライアントシステム1は、クライアント端末20が表示するデスクトップ画面をリモートでサーバ装置10に制御させるものである。つまり、シンクライアントシステム1は、実際にはサーバ装置10が実行した処理結果や保持するデータをクライアント端末20に表示させつつも、あたかもクライアント端末20が主体となって処理を実行したり、データを保持しているかのように振る舞う。図1に示すように、シンクライアントシステム1は、サーバ装置10と、クライアント端末20とを有する。なお、図1の例では、1つのサーバ装置10に対し、1つのクライアント端末20を接続する場合を図示したが、任意の数のクライアント端末が接続される場合にも同様に適用できる。これらサーバ装置10及びクライアント端末20は、所定のネットワークを介して、相互に通信可能に接続される。かかるネットワークには、有線または無線を問わず、インターネット、LANLocalAreaNetworkやVPNVirtualPrivateNetworkなどの任意の種類の通信網を採用できる。なお、サーバ装置10及びクライアント端末20間の通信プロトコルには、一例として、VNCVirtualNetworkComputingにおけるRFBRemoteFrameBufferプロトコルを採用する場合を想定する。サーバ装置10は、クライアント端末20に表示させる画面をリモートで制御するサービスを提供するコンピュータである。このサーバ装置10には、サーバ向けのリモート画面制御用のアプリケーションがインストールまたはプリインストールされる。なお、以下では、サーバ向けのリモート画面制御用のアプリケーションのことをサーバ側リモート画面制御用アプリと記載する場合がある。このサーバ側リモート画面制御用アプリは、基本機能として、リモート画面制御サービスを提供する機能を有する。一態様としては、サーバ側リモート画面制御用アプリは、クライアント端末20における操作情報を取得した上でその操作により要求された処理を自装置で動作するアプリケーションに実行させる。そして、サーバ側リモート画面制御用アプリは、アプリケーションにより実行された処理結果を表示するための画面を生成した上でその画面をクライアント端末20へ送信する。このとき、サーバ側リモート画面制御用アプリは、今回の画面生成の前にクライアント端末20で表示させていたビットマップ画像との間で変更があった部分の画素が集まった領域、すなわち更新矩形の画像を送信する。なお、以下では、一例として、更新部分の画像が矩形の画像で形成される場合を説明するが、開示の装置は更新部分の画像が矩形以外の形状で形成される場合にも適用できる。このほか、サーバ側リモート画面制御用アプリは、フレーム間で動きが大きい部分のデータを動画向けの圧縮方式のデータに圧縮してクライアント端末20へ送信する機能も有する。一態様としては、サーバ側リモート画面制御用アプリは、クライアント端末20に表示させるデスクトップ画面を複数の領域に分割し、分割した領域ごとに変更の頻度を監視する。このとき、サーバ側リモート画面制御用アプリは、変更の頻度がしきい値を超えた領域、すなわち高頻度変更領域の属性情報をクライアント端末20へ送信する。これとともに、サーバ側リモート画面制御用アプリは、高頻度変更領域のビットマップ画像をMPEG-2やMPEG-4などのMPEG方式のデータにエンコードした上でクライアント端末20へ送信する。なお、ここでは、MPEGMovingPictureExpertsGroup方式のデータへ圧縮する場合を例示したが、これに限定されない。例えば、動画向けの圧縮方式であれば任意の圧縮符号化方式、例えばMotion-JPEGJointPhotographicExpertsGroupなどを採用できる。クライアント端末20は、サーバ装置10によるリモート画面制御サービスの提供を受ける側のコンピュータである。かかるクライアント端末20の一例としては、パーソナルコンピュータPersonalComputerなど固定端末の他、携帯電話機、PHSPersonalHandyphoneSystemやPDAPersonalDigitalAssistantなどの移動体端末を採用することができる。このクライアント端末20には、クライアント向けのリモート画面制御用アプリケーションがインストールまたはプリインストールされる。なお、以下では、クライアント向けのリモート画面制御用のアプリケーションのことをクライアント側リモート画面制御用アプリと記載する場合がある。このクライアント側リモート画面制御用アプリは、マウスやキーボードなどの各種の入力デバイスを介して受け付けた操作情報をサーバ装置10へ通知する機能を有する。一態様としては、クライアント側リモート画面制御用アプリは、マウスの左右のクリックを始め、ダブルクリックやドラッグ、マウスの移動操作を介して得られたマウスカーソルの移動量などを操作情報として通知する。他の一例としては、マウスホイールの回転量、キーボードのうち押下されたキーの種別なども操作情報として通知する。さらに、クライアント側リモート画面制御用アプリは、サーバ装置10から受信した画像を所定の表示部に表示させる機能を有する。一態様としては、クライアント側リモート画面制御用アプリは、サーバ装置10から更新矩形のビットマップ画像を受信した場合には、更新矩形の画像を前回のビットマップ画像から変更のあった位置に合わせて表示する。他の一態様としては、クライアント側リモート画面制御用アプリは、サーバ装置10から高頻度変更領域の属性情報を受信した場合には、その属性情報に含まれる位置に対応する表示画面上の領域をビットマップ画像の表示対象外のブランク領域とする。その上で、クライアント側リモート画面制御用アプリは、動画向けの圧縮方式のデータを受信した場合にそのデータをデコードした上でブランク領域に表示する。[サーバ装置の構成]次に、本実施例に係るサーバ装置の機能的構成について説明する。図1に示すように、サーバ装置10は、OS実行制御部11aと、アプリ実行制御部11bと、グラフィックドライバ12と、フレームバッファ13と、リモート画面制御部14とを有する。なお、図1の例では、図1に示した機能部以外にも既知のコンピュータが有する各種の機能部、例えば各種の入力デバイスや表示デバイスなどの機能を有するものとする。OS実行制御部11aは、OSOperatingSystemの実行を制御する処理部である。一態様としては、OS実行制御部11aは、後述の操作情報取得部14aにより取得された操作情報からアプリケーションの起動指示やアプリケーションに対するコマンドを検出する。例えば、OS実行制御部11aは、アプリケーションのアイコン上でダブルクリックを検出した場合に、そのアイコンに対応するアプリケーションの起動を後述のアプリ実行制御部11bへ指示する。また、OS実行制御部11aは、起動中のアプリケーションの操作画面、いわゆるウィンドウ上でコマンドの実行を要求する操作を検出した場合に、そのコマンドの実行をアプリ実行制御部11bへ指示する。なお、以下では、アプリケーションのことをアプリと記載する場合がある。アプリ実行制御部11bは、OS実行制御部11aによる指示に基づき、アプリケーションの実行を制御する処理部である。一態様としては、アプリ実行制御部11bは、OS実行制御部11aによってアプリの起動が指示された場合や起動中のアプリにコマンドの実行が指示された場合にアプリを動作させる。そして、アプリ実行制御部11bは、アプリを実行することにより得られた処理結果の表示用イメージをフレームバッファ13に描画する要求を後述のグラフィックドライバ12へ行う。このようにグラフィックドライバ12へ描画要求を行う場合には、アプリ実行制御部11bは、表示用イメージとともに表示用イメージの描画位置をグラフィックドライバ12へ通知する。なお、アプリ実行制御部11bが実行するアプリは、プリインストールされたものであってもよく、サーバ装置10の出荷後にインストールされたものであってもかまわない。また、JAVA登録商標などのネットワーク環境で動作するアプリであってもよい。グラフィックドライバ12は、フレームバッファ13に対する描画処理を実行する処理部である。一態様としては、グラフィックドライバ12は、アプリ実行制御部11bからの描画要求を受け付けた場合に、アプリの処理結果の表示用イメージをアプリにより指定されたフレームバッファ13上の描画位置へビットマップ形式で描画する。なお、ここでは、アプリを介して描画要求を受け付ける場合を例示したが、OS実行制御部11aからの描画要求を受け付けることもできる。例えば、グラフィックドライバ12は、OS実行制御部11aからマウスカーソルの描画要求を受け付けた場合に、マウスカーソルの表示用イメージをOSにより指定されたフレームバッファ13上の描画位置へビットマップ形式で描画する。フレームバッファ13は、グラフィックドライバ12によって描画されたビットマップ画像を記憶する記憶デバイスである。かかるフレームバッファ13の一態様としては、VRAMVideoRandomAccessMemoryを始めとするRAMRandomAccessMemory、ROMReadOnlyMemoryやフラッシュメモリflashmemoryなどの半導体メモリ素子が挙げられる。なお、フレームバッファ13は、ハードディスク、光ディスクなどの記憶装置を採用することとしてもかまわない。リモート画面制御部14は、サーバ側のリモート画面制御用アプリを通じて、リモート画面制御サービスをクライアント端末20へ提供する処理部である。このリモート画面制御部14は、図1に示すように、操作情報取得部14aと、画面生成部14bと、変更頻度判別部14cと、高頻度変更領域識別部14dとを有する。さらに、リモート画面制御部14は、第1のエンコーダ14eと、第1の送信部14fと、第2のエンコーダ14gと、第2の送信部14hと、カラーマップ生成部14jとを有する。操作情報取得部14aは、クライアント端末20から操作情報を取得する処理部である。かかる操作情報の一例としては、マウスの左右のクリックを始め、ダブルクリックやドラッグ、マウスの移動操作を介して得られたマウスカーソルの移動量などが挙げられる。また、操作情報の他の一例としては、マウスホイールの回転量、キーボードのうち押下されたキーの種別なども挙げられる。画面生成部14bは、クライアント端末20の表示部22に表示させる画面の画像を生成する処理部である。一態様としては、画面生成部14bは、デスクトップ画面の更新間隔、例えば33msecが経過する度に、次のような処理を起動する。すなわち、画面生成部14bは、前回のフレーム生成時にクライアント端末20で表示させていたデスクトップ画面と、今回のフレーム生成時にフレームバッファ13へ書き込まれたデスクトップ画面とを比較する。そして、画面生成部14bは、前回のフレームから変更があった部分の画素をつなげ合わせた上で矩形に整形した更新矩形の画像を生成し、更新矩形送信用のパケットを生成する。変更頻度判別部14cは、デスクトップ画面が分割された領域ごとにフレーム間の変更の頻度を判別する処理部である。一例としては、変更頻度判別部14cは、画面生成部14bにより生成された更新矩形を図示しない作業用の内部メモリへ所定の期間にわたって蓄積する。このとき、変更頻度判別部14cは、更新矩形の位置および大きさを特定可能な属性情報、例えば更新矩形の左上の頂点の座標と更新矩形の幅および高さとを蓄積する。かかる更新矩形を蓄積させる期間は、高頻度変更領域を識別する精度と相関関係があり、期間を長くするほど高頻度変更領域の誤検出が低減される。なお、ここでは、一例として、330msecミリ秒にわたって更新矩形の画像を蓄積する場合を想定する。このとき、変更頻度判別部14cは、更新矩形の画像を蓄積してから所定の期間が経過した場合に、クライアント端末20に表示させるデスクトップ画面をメッシュ状に分割したマップを用いて、デスクトップ画面の変更頻度を判別する。図2は、デスクトップ画面の分割要領を説明するための図である。図2に示す符号30は、変更頻度判別用のマップを示す。図2に示す符号31は、マップ30に含まれるメッシュを指す。図2に示す符号32は、メッシュ31を形成する画素のブロックに含まれる1画素を指す。図2に示す例では、変更頻度判別部14cがマップ30を占める画素のうち8画素×8画素のブロックを1つのメッシュとして分割する場合を想定している。この場合には、1つのメッシュに64個の画素が含まれることになる。ここで、変更頻度判別部14cは、作業用の内部メモリに蓄積した更新矩形の位置および大きさにしたがって更新矩形の画像を変更頻度判別用のマップに順次展開する。そして、変更頻度判別部14cは、更新矩形をマップに展開する度に、マップ上で更新矩形と重なり合った部分のメッシュの変更回数を累積して加算する。このとき、変更頻度更新部14cは、マップ上に展開された更新矩形がメッシュに含まれる画素との間で所定数にわたって重なり合った場合に、そのメッシュの変更回数を1つ加算する。なお、ここでは、更新矩形がメッシュに含まれる画素と1つでも重なり合った場合に、メッシュの変更回数を加算する場合を想定して説明を行う。図3A~図3Cは、デスクトップ画面の変更頻度の判別要領を説明するための図である。図3A~図3Cに示す符号40A、符号40B及び符号40Nは変更頻度判別用のマップを示す。図3A及び図3Bに示す符号41A及び符号41Bは更新矩形を示す。ここで、マップ40Aのメッシュ内に図示した数字は、更新矩形41Aが展開された時点におけるメッシュの変更回数を示す。また、マップ40Bのメッシュ内に図示した数字は、更新矩形41Bが展開された時点におけるメッシュの変更回数を示す。さらに、マップ40Nのメッシュ内に図示した数字は、作業用の内部メモリに蓄積した更新矩形が全て展開された時点におけるメッシュの変更回数を示す。なお、図3A~図3Cにおいて数字が図示されていないメッシュは変更回数がゼロであるものとする。図3Aに示すように、更新矩形41Aがマップ40Aに展開された場合には、網掛け部分のメッシュが更新矩形41Aと重なり合う。このため、変更頻度判別部14cは、網掛け部分のメッシュの更新回数を1つずつ加算する。この場合には、各メッシュの変更回数はゼロであるため、網掛け部分の変更回数は0から1に加算される。さらに、図3Bに示すように、更新矩形41Bがマップ40Bに展開された場合には、網掛け部分のメッシュが更新矩形41Bと重なり合う。このため、変更頻度判別部14cは、網掛け部分のメッシュの更新回数を1つずつ加算する。この場合には、各メッシュの変更回数は1であるため、網掛け部分の変更回数は1から2に加算される。このようにして全ての更新矩形がマップに展開された段階では、図3Cに示すマップ40Nの結果が得られる。そして、変更頻度判別部14cは、作業用の内部メモリに蓄積した更新矩形を全てマップに展開し終えた場合に、所定の期間における変更回数、すなわち変更頻度がしきい値を超えるメッシュを取得する。図3Cの例で言えば、閾値を4としたとき、網掛け部分のメッシュが取得されることになる。かかる閾値は、その値を高く設定するほどデスクトップ画面で動画が表示されている可能性が高い部分を後述の第2のエンコーダ14gによりエンコードできる。なお、上記の閾値は、リモート画面制御用アプリの開発者が段階的に設定した値をエンドユーザに選択させたり、また、エンドユーザが値を直接設定することができる。高頻度変更領域識別部14dは、クライアント端末20に表示されるデスクトップ画面のうち高頻度で変更される領域を高頻度変更領域として識別する処理部である。これを説明すると、高頻度変更領域識別部14dは、変更頻度判別部14cによって変更回数がしきい値を超えるメッシュが取得された場合に、隣接するメッシュ同士を連結したメッシュ連結体を矩形に補正する。一態様としては、高頻度変更領域識別部14dは、メッシュ連結体に補間する補間領域を導出した上でメッシュ連結体に補間領域を足し合わせることによりメッシュ連結体を矩形に補正する。この補間領域の導出には、メッシュの連結体が最小の補間で矩形に整形される領域を導出するアルゴリズムが適用される。図4は、メッシュ連結体の補正要領を説明するための図である。図4に示す符号51は補正前のメッシュ連結体を示す。図4に示す符号52は補間領域を示す。また、図4に示す符号53は補正後の矩形を示す。図4に示すように、高頻度変更領域識別部14dは、メッシュ連結体51に補間領域52を足し合わせることにより、メッシュ連結体51を矩形53に補正する。この段階では、後述の矩形の合成が完了しておらず、矩形53が未だ高頻度変更領域と確定していないので、補正後の矩形を高頻度変更領域の候補と記載する場合がある。その後、高頻度変更領域識別部14dは、高頻度変更領域の候補が複数存在する場合には、複数の高頻度変更領域の候補の距離が所定の値以下である高頻度変更領域の候補同士を含む矩形に合成する。ここで言う高頻度変更領域の候補の距離とは、補正後の矩形の最短距離を指すものとする。一例としては、高頻度変更領域識別部14dは、高頻度変更領域の候補を合成するにあたって各候補の間を埋める補間領域を導出した上で高頻度変更領域の候補に補間領域を足し合わせることにより、高頻度変更領域の候補同士を含む矩形に合成する。この補間領域の導出には、高頻度変更領域の候補の間が最小の補間で合成体に整形される領域を導出するアルゴリズムが適用される。図5は、高頻度変更領域の候補の合成要領を説明するための説明図である。図5に示す符号61A及び符号61Bは、高頻度変更領域の候補を指す。図5に示す符号62は補間領域を指す。図5に示す符号63は、高頻度変更領域の候補61A及び高頻度変更領域の候補61Bの合成体を指す。図5に示すように、高頻度変更領域識別部14dは、互いの距離が距離d以内である高頻度変更領域の候補61A及び高頻度変更領域の候補61Bに補間領域62を足し合わせることにより、高頻度変更領域の候補61A及び高頻度変更領域の候補61Bを含む合成体63へ合成する。そして、高頻度変更領域識別部14dは、このようにして得た合成体を高頻度変更領域と識別する。このように高頻度変更領域を識別すると、高頻度変更領域識別部14dは、高頻度変更領域の位置および大きさを特定可能な属性情報をクライアント端末20へ送信する。これによって、クライアント端末20で表示されるデスクトップ画面のビットマップ画像のうち高頻度変更領域に対応する部分をブランク表示させる。その後、高頻度変更領域識別部14dは、作業用の内部メモリにマッピングされたメッシュの変更回数をクリアする。なお、高頻度変更領域識別部14dは、高頻度変更領域の属性情報を作業用の内部メモリに登録する。図6A~図6Cは、高頻度変更領域の属性情報の通知要領を説明するための図である。図6Aに示す符号70Aは、フレームバッファ13に描画されたデスクトップ画面の一例を示す。図6B~図6Cに示す符号70B及び符号70Cは、変更頻度判別用のマップを示す。図6Aに示す符号71は、ブラウザ画面を指す。図6Aに示す符号72は、動画再生画面を指す。図6Bに示す符号73は、マウスの移動軌跡を示す。図6Bに示す符号74は、アプリによる動画再生領域を示す。図6Aに示すように、デスクトップ画面70Aには、ブラウザ画面71及び動画再生画面72が含まれる。このデスクトップ画面70Aから経時的な変化を追った場合には、図6Bに示すように、静止画であるブラウザ画面71の更新矩形は検出されず、マウスの移動軌跡73および動画再生領域74に関する更新矩形が検出される。このうち、動画再生領域74で変更回数がしきい値を超えるメッシュ、すなわち図示の網掛け部分が高頻度変更領域識別部14dにより識別されたものとする。この場合には、高頻度変更領域識別部14dは、図6Cに示す網掛け部分の高頻度変更領域の左上の頂点の座標x,yと、高頻度変更領域の幅wおよび高さhとを高頻度変更領域の属性情報としてクライアント端末20へ送信する。なお、ここでは、高頻度変更領域の位置を特定する点として左上の頂点の座標を採用する場合を説明したが、他の頂点を採用することとしてもかまわない。また、高頻度変更領域の位置を特定することができる点であれば、頂点以外の任意の点、例えば重心などを採用できる。また、ここでは、画面上の左上を座標軸XYの原点とする場合を説明したが、画面内および画面外の任意の点を原点とすることができる。このように、デスクトップ画面の一部に高頻度変更領域が検出された場合には、デスクトップ画面のうち当該高頻度変更領域の動画化が開始される。この場合には、高頻度変更領域識別部14dは、フレームバッファ13に描画されたビットマップ画像のうち高頻度変更領域に対応する部分のビットマップ画像を後述の第1のエンコーダ14eへ入力する。また、高頻度変更領域が検出された後には、動画化のONまたはOFFが頻繁に切り替わるのを抑制する観点から、所定の期間、例えば1秒間にわたって継続して高頻度変更領域が検出されなくなるまで、高頻度変更領域の動画化が継続される。この場合には、高頻度変更領域と識別されなかった場合でも、前回に識別された高頻度変更領域が動画化される。一方、高頻度変更領域に含まれない更新矩形については、動画化が開始される前と同様に、静止画圧縮方式で圧縮される。すなわち、フレームバッファ13に描画されたビットマップ画像のうち高頻度変更領域に含まれない更新矩形の画像が後述のカラーマップ生成部14jによって後述の第2のエンコーダ14gへ入力される。第1のエンコーダ14eは、後述のカラーマップ生成部14jによって入力される更新矩形の画像を静止画の圧縮方式でエンコードする処理部である。一態様としては、第1のエンコーダ14eは、各更新矩形の画像をGIFGraphicInterchangeFormatやPNGPortableNetworkGraphicsなどで圧縮することによって静止画の符号化データへエンコードする。なお、ここでは、カラーマップを用いる静止画の圧縮方式としてGIFとPNGを例示したが、他の方式を適用することもできる。これらの圧縮方式は、CADで、物体をワイヤーフレームで描画した画像や物体の平面を同じ色で塗りつぶした画像を扱う場合や、文書作成ソフトや表計算ソフトを利用する場合に、JPEGで圧縮するよりも圧縮効率が高い傾向がある。第1の送信部14fは、第1のエンコーダ14eによってエンコードされた更新矩形の符号化データをクライアント端末20へ送信する処理部である。この更新矩形を送信する場合の通信プロトコルには、一例としてVNCにおけるRFBプロトコルが採用される。第2のエンコーダ14gは、高頻度変更領域識別部14dから入力される画像を動画の圧縮方式でエンコードする処理部である。一態様としては、第2のエンコーダ14gは、高頻度変更領域または変更領域の画像をMPEGで圧縮することによって動画の符号化データへエンコードする。なお、ここでは、動画の圧縮方式としてMPEGを例示したが、Motion-JPEGなどの他の方式を適用することもできる。第2の送信部14hは、第2のエンコーダ14gによってエンコードされた動画の符号化データをクライアント端末20へ送信する処理部である。この高頻度変更領域のエンコード画像を送信する場合の通信プロトコルには、一例として、RTPRealtimeTransportProtocolを採用できる。カラーマップ生成部14jは、グラフィックドライバ12によってデスクトップ画面の描画に使用される色の数よりも色の数が減色されたカラーマップを生成する処理部である。ここで、上記のカラーマップは、画素を表現する色が定義された色情報を指し、例えば、RGB表色系の場合には、R赤、G緑及びB青の三原色の各々が8ビットで表現される。なお、以下では、メディアンカット法を用いて、グラフィックドライバ12がデスクトップ画面の描画に使用する24bitカラー、いわゆるフルカラーを3分の1の8bitカラーに減色したカラーマップを生成する場合を想定する。一態様としては、カラーマップ生成部14jは、今回のフレームバッファ13への描画によって生成された更新矩形の数が所定の閾値、例えば5つ以上であるか否かによってカラーマップを生成するのに使用する画像を変更する。この閾値は、利用者が利用する端末装置が有する表示部の解像度によって決定してもよい。例えば、表示部の解像度が高くなり、画面全体の画素数が多い場合には、大きい閾値を用い、画面全体の画素数が少ない場合には、少ない閾値を用いてもよい。これにより、全画面からカラーマップを生成する時間を基準とした閾値を設定でき、カラーマップの生成に必要な時間の上限を最適化できる。なお、上記の閾値には、サーバ装置10に実装されるプロセッサやメモリの性能および使用率などの処理負荷を示すパラメータが所定の許容値、例えば開発者によって設定されるデフォルト値やシステム管理者によって指定される指定値以内になるように設定される。これを説明すると、更新矩形の数が閾値未満である場合には、各更新矩形につき1つのカラーマップを個別に生成したとしても、減色処理による処理量が比較的少なく、更新矩形の減色処理の所要時間が過度に長くならないと推定できる。このため、カラーマップ生成部14jは、更新矩形の画像を用いてカラーマップを更新矩形ごとに生成する。これによって、後述する更新矩形の画像の減色処理によってデータ伝送量を削減しつつ、クライアント端末20によって表示されるデスクトップ画面の画質劣化を抑制する。一方、更新矩形の数が閾値以上である場合には、各更新矩形につき1つのカラーマップを個別に生成すると、カラーマップを生成するオーバーヘッドが大きくなり、減色処理の所要時間が長くなってしまうと判別できる。それゆえ、カラーマップ生成部14jは、フレームバッファ13に描画されたデスクトップ画面全体から各更新領域の間で共通して使用されるカラーマップを生成する。これによって、データ伝送量の削減に伴って減色処理の所要時間が増大するのを抑制する。かかるカラーマップの生成方法について説明する。まず、カラーマップ生成部14jは、カラーマップの生成対象とする画像の色数をカウントする。このとき、更新矩形別のカラーマップを生成する場合には、更新矩形の画像が使用され、また、共通のカラーマップを生成する場合には、デスクトップ画面が使用される。なお、ここでは、更新矩形別のカラーマップを生成する場合を例示するが、共通のカラーマップを生成する場合も同様の処理が実行される。そして、カラーマップ生成部14jは、更新矩形の画像が持つ各色成分の発生頻度を表すヒストグラムを生成する。続いて、カラーマップ生成部14jは、R軸、G軸およびB軸の3軸によって表現される色空間に分布する更新矩形の全画素を含むボックスを定義し、当該ボックスに含まれる更新矩形の全画素が等分されるようにボックスを分割する。このとき、カラーマップ生成部14jは、ボックスを構成する長辺と直交するようにボックスを分割することにより、R軸、G軸またはB軸のどの軸でボックスを分割するか決定する。そして、カラーマップ生成部14jは、最初に定義したボックスを分割した領域に含まれる更新矩形の画素、ここでは全画素の半数を含むボックスをさらに定義する。その上で、カラーマップ生成部14jは、ボックスに含まれる更新矩形の画素が等分されるようにボックスをさらに分割する。なお、分割する軸の決定方法や分割する箇所を特定する方法は、理解を容易にする例を用いて説明したが、既知の他の方法を用いてもよい。その後、カラーマップ生成部14jは、分割されたボックスの数が目標の数になるまで、ボックスの定義および分割を再帰的に実行する。このとき、カラーマップ生成部14jは、複数のボックスのうち分割するボックスを選択する場合に、最も内包する画素数が多いボックスを優先するようにしてもよいし、また、最も体積が大きいボックスを優先するようにしてもかまわない。そして、カラーマップ生成部14jは、分割されたボックスの数が目標の数になると、各ボックスの端点の平均値を計算することによって各ボックスの代表色のRGB値にインデックス値を割り当てる。これによって、インデックス値とRGB値が対応付けられたカラーマップが生成される。このように、色成分の分布が密になっている領域をより細かい部分空間に細分し、逆に色成分の分布が疎になっている領域はより大きな部分空間にまとめることによって、画質低下を可及的に抑制しつつも、フルカラーよりも少ない色数で画像を再現できる。このため、高頻度変更領域の識別が実行される周期よりも短い期間に更新矩形の発生が集中した場合でも、サーバ装置10及びクライアント端末20間のデータ伝送量を抑制できる。よって、動画化が自動化されている場合でも、動画化が開始されるまでに操作レスポンスが低下するのを抑制できる。なお、ここでは、メディアンカット法によって減色する場合を例示したが、これ以外のアルゴリズムを用いることもできる。また、更新矩形の画像がRGB表色系によって表現される場合を例示したが、画像が他の表色系、例えばHSVなどによって表現される場合にも同様に適用できる。かかるカラーマップの生成後、カラーマップ生成部14jは、カラーマップを用いて、更新矩形の画像に対する減色処理を実行する。一態様としては、カラーマップ生成部14jは、更新矩形の画像を構成する画素ごとに当該画素のRGB値に最もユークリッド距離が近いRGB値を持つインデックス値をカラーマップから選択する。このように、RGB値の代わりにインデックス値を画素値として付与することによって、フルカラーの色数16777216色が256色まで減色される。他の一態様としては、カラーマップ生成部14jは、高頻度変更領域の動画化が終了した場合に、動画化終了後のデスクトップ画面から動画化中にクライアント端末20へ送信されたデスクトップ画面を上書きするための上書き用のカラーマップを生成する。その上で、カラーマップ生成部14jは、上書き用のカラーマップを用いて、動画化終了後のデスクトップ画面のうち動画化中に高頻度変更領域と識別されていた上書き領域の画像に対する減色処理を実行する。このようにして減色処理が実行された上書き領域の画像が第1のエンコーダ14eによって符号化された後にクライアント端末20へ送信される。かかる上書き領域の画像の送信は、画面生成部14bによって更新矩形が生成されるか否かとは無関係に独立して実行される。これによって、動画化によって静止画よりも画質が劣化していたクライアント端末20のデスクトップ画面を静止画によって上書きさせることができる。このため、画質の劣化が認識されにくい動画化中には、粗いデスクトップ画面を表示させつつ、動画化が終了して画質の劣化が認識されやすくなった段階で画質の劣化を抑えたデスクトップ画面を表示させることができる。なお、ここでは、カラーマップ生成部14jがカラーマップの生成および減色処理を行う場合を例示したが、各々の処理を別々の機能部、すなわち生成部と減色部として構成することもできる。また、ここでは、カラーマップ生成部14jが各更新矩形別、共通または上書き用のカラーマップのうちいずれのカラーマップを生成するのかを自律的に選択する場合を例示したが、開示の装置はこれに限定されない。例えば、減色部や第1のエンコーダなどの他の機能部が、各更新矩形別、共通または上書き用のカラーマップのうちいずれか1つのカラーマップを選択的に生成する生成部に生成させるカラーマップを切り換えるようにしてもかまわない。なお、OS実行制御部11a、アプリ実行制御部11b、グラフィックドライバ12、リモート画面制御部14には、各種の集積回路や電子回路を採用できる。また、リモート画面制御部14に含まれる機能部の一部を別の集積回路や電子回路とすることもできる。例えば、集積回路としては、ASICApplicationSpecificIntegratedCircuitやFPGAFieldProgrammableGateArrayが挙げられる。また、電子回路としては、CPUCentralProcessingUnitやMPUMicroProcessingUnitなどが挙げられる。[具体例]次に、図7を用いて、カラーマップの生成に使用される原画像の遷移について説明する。図7は、カラーマップの生成に使用される原画像の遷移を説明するための具体例を示す図である。この図7の例では、クライアント端末20からの操作情報に応答してCADComputerAidedDesignがサーバ装置10上で実行される場合を想定する。なお、図7に示す符号200、符号210、符号220、符号230、符号240及び符号250は、クライアント端末20に表示させるデスクトップ画面に含まれるCADウィンドウを示す。図7に示すように、CADウィンドウ200上で製品または製品を構成する部品等のオブジェクトを読み出す操作が実行されると、オブジェクトを含むCADウィンドウ210がクライアント端末20に表示される。このとき、オブジェクト全体を含む領域210aが画面生成部14bによって更新矩形として生成される。この場合には、オブジェクト全体を含む領域210aの1つだけしか更新矩形が生成されず、更新矩形の数が閾値である5つ未満となるので、カラーマップの生成には更新矩形210aの画像が使用される。そして、CADウィンドウ210上でオブジェクトの回転操作を受け付けた場合には、オブジェクトが回転されたCADウィンドウ220がクライアント端末20に表示される。このとき、オブジェクトの回転に伴って変更があった領域220a~領域220gが画面生成部14bによって更新矩形として生成される。この場合には、領域220a~領域220gに対応する7つの更新矩形が生成されるので、閾値である5つを超える。このため、カラーマップの生成にはデスクトップ画面が使用される。これによって、更新矩形ごとにカラーマップを生成した場合にはカラーマップを7回生成せねばならないところをカラーマップの生成を1回に削減できる。その後、CADウィンドウ220上でオブジェクトの回転操作をさらに受け付けた場合には、さらにオブジェクトが回転されたCADウィンドウ230がクライアント端末20に表示される。このとき、オブジェクトの回転に伴って変更があった領域230a~領域230gが画面生成部14bによって更新矩形として生成される。この場合にも、領域230a~領域230gに対応する7つの更新矩形が生成されるので、閾値である5つを超える。このため、カラーマップの生成にはデスクトップ画面が使用される。これによって、上記のCADウィンドウ210の場合と同様に、カラーマップを7回生成せねばならないところをカラーマップの生成を1回に削減できる。続いて、CADウィンドウ230上でオブジェクトの回転操作をさらに受け付けた場合には、さらにオブジェクトが回転されたCADウィンドウ240がクライアント端末20に表示される。このとき、オブジェクトの大部分もしくは全体を含む領域240aが高頻度変更領域と識別された場合を想定する。この場合には、高頻度変更領域の画像が動画の圧縮符号化が実行された後にクライアント端末20へ送信されるので、サーバ装置10及びクライアント端末20間のデータ伝送量を削減できる。その一方で、静止画よりも画質が劣化した領域240aの画像がクライアント端末20に表示されることになる。ところが、オブジェクトが回転しているので、クライアント端末20の利用者には画質の劣化は認識されにくい。その後、CADウィンドウ240が表示された状態で無操作状態が継続された場合には、動画化終了後の画像が上書きされたCADウィンドウ250がクライアント端末20に表示される。このように、動画化が終了した場合には、動画化されていた高頻度変更領域の画像が上書き領域250aの画像によって上書きされる。この場合には、カラーマップの生成には上書き領域250aの画像が使用される。かかる静止画による上書きによって、画質の劣化が認識されやすくなった段階で画質の劣化を抑えたデスクトップ画面を表示させることができる。[クライアント端末の構成]次に、本実施例に係るクライアント端末の機能的構成について説明する。図1に示すように、クライアント端末20は、入力部21と、表示部22と、クライアント側のリモート画面制御部23とを有する。なお、図1の例では、図1に示した機能部以外にも既知のコンピュータが有する各種の機能部、例えば音声出力部などの機能を有するものとする。入力部21は、各種の情報、例えば後述のクライアント側リモート画面制御部23に対する指示入力を受け付ける入力デバイスであり、一例としては、キーボードやマウスなどを適用できる。なお、後述の表示部22も、マウスと協働して、ポインティングデバイス機能を実現する。表示部22は、各種の情報、例えばサーバ装置10から送信されたデスクトップ画面などを表示する表示デバイスであり、一例としては、モニタ、ディスプレイやタッチパネルなどを適用できる。リモート画面制御部23は、クライアント側のリモート画面制御用アプリを通じて、サーバ装置10によるリモート画面制御サービスの提供を受ける処理部である。このリモート画面制御部23は、図1に示すように、操作情報通知部23aと、第1の受信部23bと、第1のデコーダ23cと、第1の表示制御部23dとを有する。さらに、リモート画面制御部23は、第2の受信部23eと、第2のデコーダ23fと、第2の表示制御部23gとを有する。操作情報通知部23aは、入力部21による操作情報をサーバ装置10へ通知する処理部である。一態様としては、操作情報通知部23aは、マウスの左右のクリックを始め、ダブルクリックやドラッグ、マウスの移動操作を介して得られたマウスカーソルの移動量などを操作情報として通知する。他の一例としては、操作情報通知部23aは、マウスホイールの回転量、キーボードのうち押下されたキーの種別なども操作情報として通知する。第1の受信部23bは、サーバ装置10の第1の送信部14fにより送信された更新矩形の符号化データを受信する処理部である。また、第1の受信部23bは、サーバ装置10の高頻度変更領域識別部14dによって送信された高頻度変更領域の属性情報も受信する。第1のデコーダ23cは、第1の受信部23bによって受信された更新矩形の符号化データをデコードする処理部である。この第1のデコーダ23cには、サーバ装置10に搭載されるエンコード方式に適合するデコード方式のデコーダが搭載される。第1の表示制御部23dは、第1のデコーダ23cによってデコードされた更新矩形の画像を表示部22に表示させる処理部である。一態様としては、第1の表示制御部23dは、第1の受信部23bによって受信された更新矩形の属性情報に含まれる位置および大きさに対応する表示部22の画面領域に更新矩形のビットマップ画像を表示させる。また、第1の表示制御部23dは、第1の受信部23bによって高頻度変更領域の属性情報が受信された場合には、次のような処理を行う。すなわち、第1の表示制御部23dは、高頻度変更領域の属性情報に含まれる高頻度変更領域の位置および大きさに対応する表示部22の画面領域をビットマップ画像の表示対象外のブランク領域とする。第2の受信部23eは、サーバ装置10の第2の送信部14hにより送信された動画の符号化データを受信する処理部である。この第2の受信部23eは、サーバ装置10の高頻度変更領域識別部14dによって送信された高頻度変更領域の属性情報も受信する。第2のデコーダ23fは、第2の受信部23eによって受信された動画の符号化データをデコードする処理部である。この第2のデコーダ23fには、サーバ装置10に搭載されたエンコード方式に適合するデコード方式のデコーダが搭載される。第2の表示制御部23gは、第2の受信部23eによって受信された高頻度変更領域の属性情報に基づき、第2のデコーダ23fによってデコードされた高頻度変更領域を表示部22に表示させる処理部である。一態様としては、第2の表示制御部23gは、高頻度変更領域の属性情報に含まれる高頻度変更領域の位置および大きさに対応する表示部22の画面領域に高頻度変更領域の動画を再生させる。なお、クライアント側のリモート画面制御部23には、各種の集積回路や電子回路を採用できる。また、リモート画面制御部23に含まれる機能部の一部を別の集積回路や電子回路とすることもできる。例えば、集積回路としては、ASICやFPGAが挙げられる。また、電子回路としては、CPUやMPUなどが挙げられる。[処理の流れ]次に、本実施例に係るサーバ装置10の処理の流れについて説明する。図8及び図9は、実施例1に係る画像送信処理の手順を示すフローチャートである。この画像送信処理は、サーバ装置10によって実行される処理であり、フレームバッファ13にビットマップデータが描画された場合に起動する。図8に示すように、画面生成部14bは、前回のフレームから変更があった部分の画素をつなげ合わせた上で矩形に整形した更新矩形の画像を生成するステップS101。そして、画面生成部14bは、先に生成した更新矩形の画像から更新矩形送信用のパケットを生成するステップS102。続いて、変更頻度判別部14cは、画面生成部14bにより生成された更新矩形を図示しない作業用の内部メモリへ蓄積するステップS103。このとき、更新矩形の蓄積を開始してから所定の期間が経過していない場合ステップS104否定には、以降に続く高頻度変更領域の識別に関する処理をとばし、後述のステップS113へ移行する。一方、更新矩形の蓄積を開始してから所定の期間が経過した場合ステップS104肯定には、変更頻度判別部14cは、次のような処理を行う。すなわち、変更頻度判別部14cは、作業用の内部メモリに蓄積した更新矩形の位置および大きさにしたがって更新矩形の画像を変更頻度判別用のマップに順次展開するステップS105。そして、変更頻度判別部14cは、変更頻度判別用のマップに含まれるメッシュのうち変更頻度がしきい値を超えるメッシュを取得するステップS106。その後、高頻度変更領域識別部14dは、変更頻度判別部14cにより変更頻度がしきい値を超えるメッシュが取得されたか否かを判定するステップS107。このとき、変更頻度がしきい値を超えるメッシュが存在しない場合ステップS107否定には、高頻度変更領域がデスクトップ画面に存在しないので、以降に続く高頻度変更領域の識別に関する処理をとばし、ステップS112へ移行する。一方、変更頻度がしきい値を超えるメッシュが存在する場合ステップS107肯定には、高頻度変更領域識別部14dは、隣接するメッシュ同士を連結したメッシュ連結体を矩形に補正するステップS108。そして、補正後の矩形、すなわち高頻度変更領域の候補が複数存在する場合ステップS109肯定には、高頻度変更領域識別部14dは、次のような処理を行う。すなわち、高頻度変更領域識別部14dは、複数の高頻度変更領域の候補の距離が所定の値以下である高頻度変更領域の候補同士を含む矩形に合成するステップS110。なお、高頻度変更領域の候補が複数存在しない場合ステップS109否定には、矩形の合成を行わずにステップS111へ移行する。続いて、高頻度変更領域識別部14dは、高頻度変更領域の位置および大きさを特定可能な属性情報をクライアント端末20へ送信するステップS111。そして、高頻度変更領域識別部14dは、作業用の内部メモリにマッピングされたメッシュの変更回数をクリアするステップS112。その後、高頻度変更領域が検出された場合ステップS113否定には、第2のエンコーダ14gは、高頻度変更領域の画像を動画の符号化データにエンコードするステップS114。また、高頻度変更領域が検出されなかったものの、高頻度変更領域の検出が所定の期間にわたって途絶えていない場合ステップS113肯定かつステップS115否定にも、第2のエンコーダ14gは、高頻度変更領域の画像を動画の符号化データにエンコードするステップS114。一方、高頻度変更領域が所定の期間にわたって継続して検出されなかった場合ステップS113肯定かつステップS115肯定には、カラーマップ生成部14jは、次のような処理を実行する。すなわち、カラーマップ生成部14jは、動画化終了後のデスクトップ画面を用いて、上書き用のカラーマップを生成するステップS116。そして、カラーマップ生成部14jは、上書き用のカラーマップを用いて、動画化終了後のデスクトップ画面のうち動画化中に高頻度変更領域と識別されていた上書き領域の画像に対する減色処理を実行するステップS117。その後、第1のエンコーダ14eは、減色処理が実行された上書き領域の画像を静止画の符号化データへエンコードするステップS118。その後、更新矩形が存在する場合ステップS119肯定には、カラーマップ生成部14jは、更新矩形の数が所定の閾値、例えば5つ以上であるか否かを判定するステップS120。このとき、更新矩形の数が閾値以上である場合ステップS120肯定には、各更新矩形につき1つのカラーマップを個別に生成すると、カラーマップを生成するオーバーヘッドが大きくなり、減色処理の所要時間が長くなってしまうと判別できる。それゆえ、カラーマップ生成部14jは、フレームバッファ13に描画されたデスクトップ画面全体から各更新領域の間で共通して使用されるカラーマップを生成するステップS121。そして、カラーマップ生成部14jは、共通のカラーマップを用いて、各更新領域の画像に対する減色処理を実行するステップS122。続いて、第1のエンコーダ14eは、減色処理が実行された各更新矩形の画像を静止画の符号化データへエンコードするステップS123。一方、更新矩形の数が閾値未満である場合ステップS120否定には、各更新矩形につき1つのカラーマップを個別に生成したとしても、減色処理による処理量が比較的少なく、更新矩形の減色処理の所要時間が過度に長くならないと推定できる。このため、カラーマップ生成部14jは、更新矩形の画像を用いてカラーマップを更新矩形ごとに生成するステップS124。そして、カラーマップ生成部14jは、各更新矩形ごとに生成されたカラーマップを用いて、各々の更新領域の画像に対する減色処理を実行するステップS122。続いて、第1のエンコーダ14eは、減色処理が実行された各更新矩形の画像を静止画の符号化データへエンコードするステップS123。その後、第1の送信部14f及び第2の送信部14hは、静止画及び/又は動画の符号化データをクライアント端末20へ送信しステップS125、処理を終了する。[実施例1の効果]上述してきたように、本実施例に係るサーバ装置10は、デスクトップ画面の伝送時に画面の更新矩形の数が少ない場合に更新矩形ごとにカラーマップを作成する一方で画面の更新矩形の数が多い場合にデスクトップ画面全体から各更新矩形の間で共通して使用させるカラーマップを作成する。このため、本実施例に係るサーバ装置10では、カラーマップ生成のオーバーヘッドが大きくなる場合にカラーマップの生成回数を低減できる。したがって、本実施例に係るサーバ装置10によれば、圧縮処理の所要時間を短縮できる。さて、これまで開示の装置に関する実施例について説明したが、本発明は上述した実施例以外にも、種々の異なる形態にて実施されてよいものである。そこで、以下では、本発明に含まれる他の実施例を説明する。[マップクリアの延長]例えば、上記の実施例1では、高頻度変更領域識別部14dが更新矩形を蓄積させる周期に合わせて変更頻度判別用のマップをクリアする場合を説明したが、変更頻度判別用のマップをクリアする契機はこれに限定されない。一例としては、高頻度変更領域識別部14dは、高頻度変更領域として識別した領域において変更頻度がしきい値を超えなくなった後も所定の期間にわたって継続して高頻度変更領域と識別することもできる。図10A及び図10Bは、マップクリアの延長要領を説明するための図である。図10Aの例では、高頻度変更領域が最初に識別された時点の変更頻度判別用のマップ80Aと、その時点の高頻度変更領域の識別結果81Aとを図示している。また、図10Bの例では、高頻度変更領域が最初に識別されてから所定の期間内である特定の時点の変更頻度判別用のマップ80Bと、その時点の高頻度変更領域の識別結果81Aとを図示している。図10Aに示すように、マップ80Aで変更回数がしきい値を超えるメッシュ連結体が取得されて高頻度変更領域の識別結果81Aが得られた場合には、以降に変更回数が閾値を超えるメッシュ連結体が取得されなくとも識別結果81Aを所定の期間引き継ぐ。すなわち、図10Bに示すように、マップ80Aで変更回数が閾値を超えるメッシュ連結体が取得されずとも、最初に高頻度変更領域の識別結果81Aを識別してから所定の期間内であれば高頻度変更領域の識別結果81Aを引き継ぐ。なお、上記の閾値は、サーバ側リモート画面制御用アプリの開発者が段階的に設定した値をエンドユーザに選択させたり、また、エンドユーザが値を直接設定することができる。これによって、実際に動画が再生される領域において間欠的に動きがなくなった場合でも、高頻度変更領域を断続的に識別することがなくなる結果、高頻度変更領域で画像のコマ落ちが断続的に発生するのを防止できる。さらに、高頻度変更領域の識別結果を引き継ぐことにより高頻度変更領域のサイズが安定するので、エンコード時のパラメータを初期化する頻度を低減できる結果、エンコーダにかかる負荷を低減することも可能になる。[高頻度変更領域の縮小の抑制]他の一例としては、高頻度変更領域識別部14dは、高頻度変更領域として識別した領域が以前に高頻度変更領域と識別した領域よりも縮小した場合に、次のような処理を行う。すなわち、高頻度変更領域識別部14dは、当該縮小した度合いが所定の閾値以下であるならば、前回の識別時に高頻度変更領域と識別した領域を今回の識別結果として引き継ぐ。図11A及び図11Bは、高頻度変更領域の縮小に関する抑制要領を説明するための図である。図11Aの例では、時点T1の変更頻度判別用のマップ90Aと高頻度変更領域の識別結果91Aとを図示している。また、図11Bの例では、時点T2の変更頻度判別用のマップ90Bと高頻度変更領域の識別結果91Aとを図示している。なお、上記の時点T1および時点T2はT1<T2であるものとする。図11Aに示すように、マップ90Aで変更回数がしきい値を超えるメッシュ連結体が取得されて高頻度変更領域の識別結果91Aが得られた場合には、時点T1以降に変更回数が閾値を超えるメッシュ連結体が縮小されても直ちに高頻度変更領域を縮小しない。すなわち、図11Bに示すように、変更回数が閾値を超えるメッシュ連結体が斜線の部分について縮小したとしてもその面積が所定の閾値、例えば半分以下であるならば、高頻度変更領域の識別結果91Aを引き継ぐ。これによって、実際に動画が再生される領域において一部の動きが間欠的になったとしても、高頻度変更領域を断続的に識別することがなくなる結果、高頻度変更領域で画像のコマ落ちが断続的に発生するのを防止できる。さらに、高頻度変更領域の識別結果を引き継ぐことにより高頻度変更領域のサイズが安定するので、エンコード時のパラメータを初期化する頻度を低減できる結果、エンコーダにかかる負荷を低減することも可能になる。[カラーマップの生成方法]上記の実施例1では、各更新領域で共通のカラーマップを生成する場合にフレームバッファ13に描画されたデスクトップ画面全体で用いられる色からカラーマップを生成する例を説明したが、開示の装置は、必ずしもデスクトップ画面全体の色を用いる必要はない。すなわち、開示の装置は、各更新領域で共通のカラーマップを生成する場合には、デスクトップ画面全体のうち少なくとも各更新領域の画像で用いられる色を含んでいればよい。[応用例]上記の実施例1では、更新矩形の数が閾値以上である場合に、デスクトップ画面から各更新矩形の間で共通のカラーマップを生成する場合を例示したが、デスクトップ画面の色数が少ない場合に限って共通のカラーマップを生成することとしてもよい。すなわち、CAD、文書作成ソフトや表計算ソフトなどのアプリケーションが実行される場合に、壁紙やブラウザなどのウィンドウに比べて使用される色の数が少ないことがある。このような場合に、カラーマップの生成中にデスクトップ画面の色の数をカウントした段階でデスクトップ画面に使用される色の数が所定の閾値未満である場合に限って共通のカラーマップの生成を継続するようにしてもよい。これによって、デスクトップ画面として壁紙やブラウザなどのウィンドウのように使用される色の数が多いケースで共通のカラーマップを生成するのを防ぎ、クライアント端末20で表示させるデスクトップ画面の画質劣化が顕著になるのを予防できる。[上書き領域]上記の実施例1では、動画化中に高頻度変更領域であった領域を上書き領域とする場合を例示したが、開示の装置はこれに限定されない。例えば、開示の装置は、デスクトップ画面全体を上書き領域とすることもできるし、また、動画化開始から動画化終了までの期間で更新矩形が実際に生成された領域だけを上書き領域とすることもできる。また、図示した各装置の各構成要素は、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散統合の具体的形態は図示のものに限られず、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散統合して構成することができる。例えば、サーバ装置10の第1の送信部14f及び第2の送信部14hが実行する画像の送信処理を1つの送信部に統合することとしてもよい。また、クライアント端末20の第1の受信部23b及び第2の受信部23eが実行する画像の受信処理を1つの画像受信部に統合することとしてもかまわない。さらに、クライアント端末の第1の表示制御部23d及び第2の表示制御部23gが実行する表示制御処理を1つの表示制御部に統合することとしてもよい。[画像送信プログラム]また、上記の実施例で説明した各種の処理は、予め用意されたプログラムをパーソナルコンピュータやワークステーションなどのコンピュータで実行することによって実現することができる。そこで、以下では、図12を用いて、上記の実施例と同様の機能を有する画像送信プログラムを実行するコンピュータの一例について説明する。図12は、実施例1及び実施例2に係る画像送信プログラムを実行するコンピュータの一例について説明するための図である。図12に示すように、コンピュータ100は、操作部110aと、スピーカ110bと、カメラ110cと、ディスプレイ120と、通信部130とを有する。さらに、このコンピュータ100は、CPU150と、ROM160と、HDD170と、RAM180と有する。これら110~180の各部はバス140を介して接続される。HDD170には、図12に示すように、上記の実施例1で示した上記の実施例1で示したサーバ側のリモート画面制御部14と同様の機能を発揮する画像送信プログラム170aが予め記憶される。この画像送信プログラム170aについては、図1に示した各々のリモート画面制御部14の各構成要素と同様、適宜統合又は分離しても良い。すなわち、HDD170に格納される各データは、常に全てのデータがHDD170に格納される必要はなく、処理に必要なデータのみがHDD170に格納されれば良い。そして、CPU150が、画像送信プログラム170aをHDD170から読み出してRAM180に展開する。これによって、図12に示すように、画像送信プログラム170aは、画像送信プロセス180aとして機能する。この画像送信プロセス180aは、HDD170から読み出した各種データを適宜RAM180上の自身に割り当てられた領域に展開し、この展開した各種データに基づいて各種処理を実行する。なお、画像送信プロセス180aは、図1に示した各々のリモート画面制御部14にて実行される処理、例えば図8~図9に示す処理を含む。また、CPU150上で仮想的に実現される各処理部は、常に全ての処理部がCPU150上で動作する必要はなく、処理に必要な処理部のみが仮想的に実現されれば良い。なお、上記の画像送信プログラム170aについては、必ずしも最初からHDD170やROM160に記憶させておく必要はない。例えば、コンピュータ100に挿入されるフレキシブルディスク、いわゆるFD、CD-ROM、DVDディスク、光磁気ディスク、ICカードなどの可搬用の物理媒体に各プログラムを記憶させる。そして、コンピュータ100がこれらの可搬用の物理媒体から各プログラムを取得して実行するようにしてもよい。また、公衆回線、インターネット、LAN、WANなどを介してコンピュータ100に接続される他のコンピュータまたはサーバ装置などに各プログラムを記憶させておき、コンピュータ100がこれらから各プログラムを取得して実行するようにしてもよい。"