"ネットワークを介して接続された端末装置に表示させる表示用の画像を記憶する画像メモリと、ソフトウェアの処理結果を前記画像メモリに描画する描画部と、前記画像メモリに描画される画像のフレーム間で更新があった更新領域を検出する更新領域検出部と、複数の圧縮方式のうちいずれかの圧縮方式を適用して、前記更新領域検出部によって検出された更新領域の画像を静止画圧縮する第1の圧縮部と、前記画像メモリに描画される画像のフレーム間で変更の頻度が所定の頻度を超える高頻度の変更領域を識別する識別部と、前記画像メモリに描画された画像のうち前記識別部によって識別された高頻度の変更領域の画像を動画圧縮する第2の圧縮部と、前記第1の圧縮部によって静止画圧縮された更新領域の静止画圧縮データと、前記第2の圧縮部によって動画圧縮された高頻度の変更領域の動画圧縮データとを前記端末装置へ送信する送信部と、前記第2の圧縮部による動画圧縮が終了する場合に、前記第1の圧縮部によって用いられる圧縮方式の変更を試行する変更試行部と、前記変更試行部によって圧縮方式の変更が試行された前後で得られる更新領域の静止画圧縮データの圧縮率の比較結果に基づいて、前記第1の圧縮部に使用させる圧縮方式を選択する圧縮方式選択部とを有することを特徴とする情報処理装置。前記変更試行部は、前記第1の圧縮部によって圧縮された更新領域の静止画圧縮データの圧縮率と、当該更新領域が検出されるよりも前のフレームにおける圧縮率との変化が所定の閾値以上である場合に、前記圧縮方式の変更を試行することを特徴とする請求項1に記載の情報処理装置。前記変更試行部は、前記更新領域検出部によって検出された更新領域の面積と、当該更新領域が検出されるよりも前のフレームにおける面積との変化が所定の範囲以内である場合に、前記圧縮方式の変更を試行することを特徴とする請求項1または2に記載の情報処理装置。前記変更試行部は、前記更新領域検出部によって検出された更新領域の画像に含まれる色の数と所定の閾値との比較結果に基づいて、前記圧縮方式の変更を試行することを特徴とする請求項1、2または3に記載の情報処理装置。前記変更試行部は、前記第2の圧縮部による動画圧縮中に前記送信部によって動画圧縮データが送信された高頻度の変更領域を上書きする上書き領域の画像が前記第1の圧縮部によって静止画圧縮される場合に、前記圧縮方式の変更を試行することを特徴とする請求項1~4のいずれか1つに記載の情報処理装置。コンピュータが、ネットワークを介して接続された端末装置に表示させる表示用の画像を記憶する画像メモリに対し、ソフトウェアの処理結果を描画し、前記画像メモリに描画される画像のフレーム間で更新があった更新領域を検出し、複数の圧縮方式のうちいずれかの圧縮方式を適用して、前記更新領域の画像を静止画圧縮し、前記画像メモリに描画される画像のフレーム間で変更の頻度が所定の頻度を超える高頻度の変更領域を識別し、前記画像メモリに描画された画像のうち前記高頻度の変更領域の画像を動画圧縮し、前記更新領域の静止画圧縮データと、前記高頻度の変更領域の動画圧縮データとを前記端末装置へ送信し、動画圧縮が終了する場合に、静止画圧縮に用いられる圧縮方式の変更を試行し、前記圧縮方式の変更が試行された前後で得られる更新領域の静止画圧縮データの圧縮率の比較結果に基づいて、静止画圧縮に適用させる圧縮方式を選択する処理を実行することを特徴とする画像送信方法。コンピュータに、ネットワークを介して接続された端末装置に表示させる表示用の画像を記憶する画像メモリに対し、ソフトウェアの処理結果を描画し、前記画像メモリに描画される画像のフレーム間で更新があった更新領域を検出し、複数の圧縮方式のうちいずれかの圧縮方式を適用して、前記更新領域の画像を静止画圧縮し、前記画像メモリに描画される画像のフレーム間で変更の頻度が所定の頻度を超える高頻度の変更領域を識別し、前記画像メモリに描画された画像のうち前記高頻度の変更領域の画像を動画圧縮し、前記更新領域の静止画圧縮データと、前記高頻度の変更領域の動画圧縮データとを前記端末装置へ送信し、動画圧縮が終了する場合に、静止画圧縮に用いられる圧縮方式の変更を試行し、前記圧縮方式の変更が試行された前後で得られる更新領域の静止画圧縮データの圧縮率の比較結果に基づいて、静止画圧縮に適用させる圧縮方式を選択する処理を実行させることを特徴とする画像送信プログラム。しかしながら、上記の従来技術は、以下に説明するように、データ伝送量の削減効率が低下するという問題がある。すなわち、上記のデータ圧縮方法や遠隔操作システムでは、同じ圧縮方式であっても画面の内容によって画像の圧縮率にばらつきが生じるにもかかわらず、どのような画面データにも同じ圧縮方式が固定して使用される。このため、上記のデータ圧縮方法や遠隔操作システムでは、使用が定められた圧縮方式にとって不向きな画面にもその圧縮方式が適用されるので、画面データを圧縮したとしてもその効果は限定的となり、データ伝送量の削減効率が低下してしまう。また、複数の圧縮方式の中から画面の内容に適合する圧縮方式を選択することも考えられるが、圧縮方式の選択には、サーバからクライアントへ画面データを伝送する事前に画面の内容を解析する処理が必要となる。それゆえ、複数の圧縮方式から画面データに適用する圧縮方式を選択する場合には、上記の画像解析処理によってサーバの処理負荷が増大し、処理時間に遅延が発生するので、操作レスポンスの低下をまねいてしまうケースが生じる。開示の技術は、上記に鑑みてなされたものであって、処理負荷を抑制しつつ、データ伝送量の削減効率を向上させることができる情報処理装置、画像送信方法及び画像送信プログラムを提供することを目的とする。本願の開示する情報処理装置は、ネットワークを介して接続された端末装置に表示させる表示用の画像を記憶する画像メモリを有する。前記情報処理装置は、ソフトウェアの処理結果を前記画像メモリに描画する描画部を有する。前記情報処理装置は、前記画像メモリに描画される画像のフレーム間で更新があった更新領域を検出する更新領域検出部を有する。前記情報処理装置は、複数の圧縮方式のうちいずれかの圧縮方式を適用して、前記更新領域検出部によって検出された更新領域の画像を静止画圧縮する第1の圧縮部を有する。前記情報処理装置は、前記画像メモリに描画される画像のフレーム間で変更の頻度が所定の頻度を超える高頻度の変更領域を識別する識別部を有する。前記情報処理装置は、前記画像メモリに描画された画像のうち前記識別部によって識別された高頻度の変更領域の画像を動画圧縮する第2の圧縮部を有する。前記情報処理装置は、前記第1の圧縮部によって静止画圧縮された更新領域の静止画圧縮データと、前記第2の圧縮部によって動画圧縮された高頻度の変更領域の動画圧縮データとを前記端末装置へ送信する送信部を有する。前記情報処理装置は、前記第2の圧縮部による動画圧縮が終了する場合に、前記第1の圧縮部によって用いられる圧縮方式の変更を試行する変更試行部を有する。前記情報処理装置は、前記変更試行部によって圧縮方式の変更が試行された前後で得られる更新領域の静止画圧縮データの圧縮率の比較結果に基づいて、前記第1の圧縮部に使用させる圧縮方式を選択する圧縮方式選択部を有する。本願の開示する情報処理装置の一つの態様によれば、処理負荷を抑制しつつ、データ伝送量の削減効率を向上させることができるという効果を奏する。以下に、本願の開示する情報処理装置、画像送信方法及び画像送信プログラムの実施例を図面に基づいて詳細に説明する。なお、この実施例は開示の技術を限定するものではない。そして、各実施例は、処理内容を矛盾させない範囲で適宜組み合わせることが可能である。[システム構成]まず、本実施例に係るシンクライアントシステムの構成について説明する。図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へ送信する。これとともに、サーバ側のリモート画面制御用アプリは、高頻度変更領域のビットマップ画像をMPEGMovingPictureExpertsGroup-2やMPEG-4などの動画圧縮方式の符号化データにエンコードした上でクライアント端末20へ送信する。なお、ここでは、MPEG方式の符号化データへエンコードする場合を例示したが、これに限定されない。例えば、動画向けの圧縮方式であれば任意の圧縮符号化方式、例えば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とを有する。さらに、リモート画面制御部14は、算出部14jと、変更試行部14kと、圧縮方式選択部14mとを有する。操作情報取得部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に描画されたビットマップ画像のうち高頻度変更領域に対応する部分のビットマップ画像を後述の第2のエンコーダ14gへ入力する。また、高頻度変更領域が検出された後には、動画化のONまたはOFFが頻繁に切り替わるのを抑制する観点から、所定の期間、例えば1秒間にわたって継続して高頻度変更領域が検出されなくなるまで、高頻度変更領域の動画化が継続される。この場合には、高頻度変更領域と識別されなかった場合でも、前回に識別された高頻度変更領域が動画化される。一方、高頻度変更領域に含まれない更新矩形については、動画化が開始される前と同様に、静止画圧縮方式で圧縮される。すなわち、フレームバッファ13に描画されたビットマップ画像のうち高頻度変更領域に含まれない更新矩形の画像が後述の算出部14jを経由して後述の第1のエンコーダ14eへ入力される。第1のエンコーダ14eは、複数の静止画の圧縮方式のうち後述の変更試行部14kまたは後述の圧縮方式選択部14mによって指定された静止画の圧縮方式を適用して、画面生成部14bによって入力される更新矩形の画像をエンコードする処理部である。ここで、本実施例では、上記の静止画の圧縮方式として、JPEG及びPNGPortableNetworkGraphicsのいずれかが第1のエンコーダ14eによって選択的に適用される場合を想定する。このように、JPEGとPNGを併用するのは、JPEGに不向きな内容の画像をPNGで圧縮する一方でPNGに不向きな内容の画像をJPEGで圧縮することによって互いの弱点を補うためである。例えば、アプリ実行制御部11bによってCADComputerAidedDesignなどの設計製図ソフトが実行される場合には、製品または製品を構成する部品などのオブジェクトがワイヤーフレームやシェーディングによってレンダリングされる。このうち、ワイヤーフレームによってレンダリングされる場合には、オブジェクトが線形状によって描画される。一方、シェーディングによってレンダリングされる場合には、オブジェクトがポリゴン等の陰影によって描画される。なお、以下では、ワイヤーフレームによって描画されたオブジェクトのことをワイヤーフレームモデルと記載し、シェーディングによって描画されたオブジェクトのことをシェーディングモデルと記載する場合がある。このため、ワイヤーフレームモデルは、シェーディングモデルよりも色の数が少なくなる場合が多い。それゆえ、ワイヤーフレームモデルは、画像を構成する色の周波数成分のうち高周波成分を除去することによって高い圧縮率を得るJPEGにとって不向きな内容であるとも言える。一方、シェーディングモデルは、ポリゴン等によって陰影が表現されることによって画像を構成する色の数が多くなる。このため、シェーディングモデルは、PNGで圧縮する場合の圧縮効果がJPEGで圧縮する場合に比べて限定的であるので、PNGにとって不向きな内容であるとも言える。このことから、JPEGにとって不向きな内容の画像がPNGで圧縮される一方で、PNGにとって不向きな内容の画像がJPEGで圧縮されるように、静止画の圧縮方式が後述の圧縮方式選択部14mによって選択される。なお、ここでは、ワイヤーフレームモデルとシェーディングモデルを例示して説明したが、これ以外にも、自然画が表示される背景画像やウィンドウと文書作成ソフトや表計算ソフトが生成するウィンドウとが表示される場合も同様のことが言える。第1の送信部14fは、第1のエンコーダ14eによってエンコードされた更新矩形の符号化データをクライアント端末20へ送信する処理部である。この更新矩形を送信する場合の通信プロトコルには、一例としてVNCにおけるRFBプロトコルが採用される。第2のエンコーダ14gは、高頻度変更領域識別部14dから入力される画像を動画の圧縮方式でエンコードする処理部である。一態様としては、第2のエンコーダ14gは、高頻度変更領域または変更領域の画像をMPEGで圧縮することによって動画の符号化データへエンコードする。なお、ここでは、動画の圧縮方式としてMPEGを例示したが、Motion-JPEGなどの他の方式を適用することもできる。第2の送信部14hは、第2のエンコーダ14gによってエンコードされた動画の符号化データをクライアント端末20へ送信する処理部である。この高頻度変更領域のエンコード画像を送信する場合の通信プロトコルには、一例として、RTPRealtimeTransportProtocolを採用できる。算出部14jは、静止画の圧縮方式の変更を試行するか否かの判定に用いられる各種のパラメータ、例えば更新矩形の面積や静止画の圧縮率を算出する処理部である。一態様としては、算出部14jは、画面生成部14bによって生成された更新矩形の画像に含まれるピクセル数を計数することによって更新矩形の面積を算出する。その後、算出部14jは、先のようにして算出した更新矩形の面積を当該更新矩形の識別情報、更新矩形が生成されたフレームの識別情報および更新矩形の位置に対応付けて図示しない作業用の内部メモリに格納する。なお、更新矩形の面積は、画面生成部14bによって入力される更新矩形ごとに算出される。他の一態様としては、算出部14jは、静止画の符号化データの圧縮率を算出する。例えば、算出部14jは、第1のエンコーダ14eによってエンコードされた静止画の符号化データのデータ量を画面生成部14bによって生成された更新矩形の画像のデータ量で除算することによって現フレームの圧縮率を算出する。また、算出部14jは、現フレームの圧縮率と、現フレームよりも前に算出されていた所定数のフレーム、例えば過去の5フレームの圧縮率とを平均することによって前フレームまでの圧縮率の平均値を算出する。さらに、算出部14jは、動画化中にクライアント端末20へ動画が送信されていた高頻度変更領域の画像を動画化終了後の静止画で上書きする場合に、動画化中に高頻度変更領域であった上書き領域の画像の圧縮率を算出する。なお、ここでは、圧縮後の画像のデータ量を圧縮前の画像のデータ量で除算することによって圧縮率を算出する場合を例示したが、圧縮率の算出方法はこれに限定されない。例えば、算出部14jは、圧縮前および圧縮後の画像のデータ量の差分を圧縮前の画像のデータ量で除算することによって圧縮率を算出することとしてもかまわない。変更試行部14kは、第2のエンコーダ14gによる動画圧縮が終了する場合に、第1のエンコーダ14eによって用いられる圧縮方式の変更を試行する処理部である。これを説明すると、まず、変更試行部14kは、算出部14jによって算出された更新矩形の面積を、作業用の内部メモリに記憶された前フレームの更新矩形のうち当該更新矩形の位置と重複する更新矩形の面積で除算した除算値が所定の閾値以上であるか否かを判定する。つまり、変更試行部14kは、前フレームの更新矩形の面積に対する現フレームの更新矩形の面積の割合が所定の閾値、例えば1/10以上であるか否かを判定する。なお、現フレームの更新矩形の位置と重複する更新矩形が複数存在する場合には、面積が最大の更新矩形が比較の対象とされる。上記の閾値には、デスクトップ画面に含まれるウィンドウの一部やウィンドウ内のオブジェクトの一部の変化ではなく、ウィンドウ自体の表示や削除、オブジェクトの新規表示やレンダリング手法の変更などのシーンチェンジの発生を検知できる値が設定される。例えば、シーンチェンジの一例としては、CADによって表示されるCADウィンドウ上でオブジェクトがワイヤーフレームモデルからシェーディングモデルへ変更されるケースやシェーディングモデルからワイヤーフレームモデルへ変更されるケースが挙げられる。なお、シーンチェンジが発生した場合であっても、フレーム間で更新領域が一致することは稀であるので、現フレームの更新矩形が前フレームの更新矩形の1割程度まで縮小されるのを許容するのが好ましい。そして、変更試行部14kは、前フレームの更新矩形の面積に対する現フレームの更新矩形の面積の割合が閾値以上であると判定した場合に、現フレームの圧縮率が前フレームまでの圧縮率の平均値に比べて所定の閾値以上増加したか否かをさらに判定する。これによって、変更試行部14kは、現フレームの圧縮率が前フレームまでの圧縮率の平均値に比べて悪化したか否かを判定できる。なお、上記の閾値には、静止画の圧縮方式の変更を試行する価値があると推定できる値が設定される。すなわち、現フレームの圧縮率及び前フレームまでの圧縮率の平均値に大差がない場合、偶然に悪化したサンプルを圧縮方式の変更に使用してしまう可能性が高まる。よって、上記の閾値には、現フレームの圧縮率が前フレームまでの圧縮率の平均値の2倍程度まで悪化するのを許容するのが好ましい。ここで、変更試行部14kは、現フレームの圧縮率が閾値以上増加した場合に、図示しない作業用の内部メモリに記憶された変更試行フラグをONに設定する。ここで言う変更試行フラグとは、動画化終了後に高頻度変更領域であった領域に上書きする上書き画像の圧縮方式の変更を試行するか否かを示すフラグである。例えば、変更試行フラグがONである場合には、上書き画像の圧縮方式の変更が試行され、また、変更試行フラグがOFFである場合には、上書き画像の圧縮方式の変更は試行されない。なお、変更試行部14kは、圧縮方式選択部14mによって選択されている圧縮方式とは異なる圧縮方式で動画化終了後に高頻度変更領域であった領域に上書きする上書き画像のエンコードが試行された場合に、変更試行フラグをOFFに設定する。圧縮方式選択部14mは、変更試行部14kによって圧縮方式の変更が試行された前後で得られる更新領域の静止画圧縮データの圧縮率の比較結果に基づいて、第1のエンコーダ14eに使用させる静止画の圧縮方式を選択する処理部である。一態様としては、圧縮方式選択部14mは、圧縮方式の変更を試行した上書き画像の圧縮率が作業用の内部メモリに記憶された圧縮率の平均値、すなわち当該動画化前に算出されていた圧縮率の平均値に比べて所定の閾値以上減少したか否かを判定する。これによって、圧縮方式選択部14mは、圧縮方式の変更を試行した上書き画像の圧縮率が動画化前に算出されていた圧縮率の平均値に比べて向上したか否かを判定できる。このとき、上書き画像の圧縮率が閾値以上減少した場合には、静止画の圧縮方式を変更するのが好ましいと判定できる。この場合には、圧縮方式選択部14mは、第1のエンコーダ14eに使用させる静止画の圧縮方式を変更試行部14kによって変更が試行された静止画の圧縮方式へ切り替える。また、上書き画像の圧縮率が閾値以上減少していない場合には、静止画の圧縮方式を変更せずともよいと判定できる。この場合には、第1のエンコーダ14eに使用させる静止画の圧縮方式は変更されない。[具体例]次に、図7を用いて、静止画の圧縮方式の選択方法について説明する。図7は、静止画の圧縮方式の選択方法を説明するための具体例を示す図である。この図7の例では、クライアント端末20からの操作情報に応答してCADがサーバ装置10上で実行される場合を想定する。図7に示す符号200及び符号210は更新矩形の画像を示し、符号220は高頻度変更領域の画像を示し、また、符号230は上書き画像を示す。例えば、CADウィンドウ上でオブジェクトを読み出す操作が実行されると、ワイヤーフレームによってレンダリングされたオブジェクトが表示される。この場合には、CADウィンドウ上にオブジェクトがない状態からワイヤーフレームモデルのオブジェクトが表示されるので、ワイヤーフレームモデルのオブジェクトを含む更新矩形200が生成される。そして、CADウィンドウ上でオブジェクトの表示をワイヤーフレームモデルからシェーディングモデルへ変更する操作がなされると、シェーディングモデルのオブジェクトを含む更新矩形210が生成される。このとき、静止画の圧縮方式としてPNGが選択されている場合には、ワイヤーフレームモデルからシェーディングモデルへのシーンチェンジに伴ってCADウィンドウを構成する色数が増加するので、圧縮率が悪化する。例えば、更新矩形210の圧縮率が更新矩形200の圧縮率に比べて2倍以上悪化した場合には、変更試行フラグがONに設定される。続いて、CADウィンドウ上でオブジェクトの回転操作を受け付けた場合には、オブジェクトの回転に伴って変更の頻度が上昇し、オブジェクト全体を含む領域が高頻度変更領域と識別される。このようにして、シェーディングモデルのオブジェクトを含む高頻度変更領域の画像220が動画表示される。その後、CADウィンドウが表示された状態で無操作状態が継続された場合には、動画化が終了し、動画化中に高頻度変更領域であった領域に上書きする上書き画像がクライアント端末20に送信される。このとき、変更試行フラグがONに設定されているので、上書き画像はPNGではなく、JPEGで圧縮された上書き画像230がクライアント端末20に送信の後に表示される。この場合には、JPEGで圧縮された上書き画像230の圧縮率がPNGで圧縮されていた更新矩形210の圧縮率の平均値に比べて2倍以上向上する。よって、以後の静止画の圧縮方式がJPEGに切り替えられる。このように、本実施例に係るサーバ装置10では、PNGによる圧縮に不向きなシェーディングモデルのオブジェクトに変更された場合に、色数が多い画像の圧縮に性能を発揮するJPEGへ圧縮方式を変更できる。かかる動画化が終了してから圧縮方式の変更を試行するので、デスクトップ画面の変更の頻度が減少した時点で圧縮方式の変更を試行される結果、圧縮方式の変更を試行するにあたってサーバ装置10の処理負荷も軽減できる。なお、OS実行制御部11a、アプリ実行制御部11b、グラフィックドライバ12、リモート画面制御部14には、各種の集積回路や電子回路を採用できる。また、リモート画面制御部14に含まれる機能部の一部を別の集積回路や電子回路とすることもできる。例えば、集積回路としては、ASICApplicationSpecificIntegratedCircuitやFPGAFieldProgrammableGateArrayが挙げられる。また、電子回路としては、CPUCentralProcessingUnitやMPUMicroProcessingUnitなどが挙げられる。[クライアント端末の構成]次に、本実施例に係るクライアント端末の機能的構成について説明する。図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~図10は、実施例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。その後、図9に示すように、高頻度変更領域が検出された場合ステップS113否定には、第2のエンコーダ14gは、高頻度変更領域の画像を動画の符号化データにエンコードするステップS114。また、高頻度変更領域が検出されなかったものの、高頻度変更領域の検出が所定の期間にわたって途絶えていない場合ステップS113肯定かつステップS115否定にも、第2のエンコーダ14gは、高頻度変更領域の画像を動画の符号化データにエンコードするステップS114。一方、高頻度変更領域が所定の期間にわたって継続して検出されなかった場合ステップS113肯定かつステップS115肯定には、圧縮方式選択部14mは、作業用の内部メモリに記憶された変更試行フラグを参照するステップS116。このとき、変更試行フラグがONである場合ステップS116肯定には、圧縮方式選択部14mは、選択中の静止画の圧縮方式とは異なる他の圧縮方式への変更を試行し、他の圧縮方式で上書き画像を静止画の符号化データへエンコードさせるステップS117。続いて、算出部14jは、上書き画像の圧縮率を算出するステップS118。そして、圧縮方式選択部14mは、圧縮方式の変更を試行した上書き画像の圧縮率が動画化前に算出されていた圧縮率の平均値に比べて所定の閾値以上減少したか否かを判定するステップS119。ここで、上書き画像の圧縮率が閾値以上減少した場合ステップS119肯定には、静止画の圧縮方式を変更するのが好ましいと判定できる。よって、圧縮方式選択部14mは、第1のエンコーダ14eに使用させる静止画の圧縮方式を変更試行部14kによって変更が試行された静止画の圧縮方式へ切り替えるステップS120。一方、上書き画像の圧縮率が閾値以上低下していない場合ステップS119否定には、静止画の圧縮方式を変更せずともよいと判定できる。この場合には、第1のエンコーダ14eに使用させる静止画の圧縮方式を変更せず、ステップS122へ移行する。また、変更試行フラグがOFFである場合ステップS116否定には、圧縮方式選択部14mは、選択中の圧縮方式で上書き画像を静止画の符号化データへエンコードさせるステップS121。その後、図10に示すように、更新矩形が存在する場合ステップS122肯定には、算出部14jは、更新矩形の画像のピクセル数を計数することによって更新矩形の面積を算出するステップS123。なお、更新矩形が存在しない場合ステップS122否定には、ステップS123~ステップS129までの処理をとばし、ステップS130へ移行する。続いて、第1のエンコーダ14eは、更新矩形の画像を静止画の符号化データへエンコードするステップS124。その後、算出部14jは、第1のエンコーダ14eによってエンコードされた静止画の符号化データのデータ量を画面生成部14bによって生成された更新矩形の画像のデータ量で除算することによって現フレームの圧縮率を算出するステップS125。そして、変更試行部14kは、前フレームの更新矩形の面積に対する現フレームの更新矩形の面積の割合が閾値以上であるか否かを判定するステップS126。このとき、現フレームの更新矩形の面積の割合が閾値以上である場合ステップS126肯定には変更試行部14kは、現フレームの圧縮率が前フレームまでの圧縮率の平均値に比べて所定の閾値以上増加したか否かをさらに判定するステップS127。ここで、現フレームの更新矩形の面積の割合が閾値以上である場合、かつ現フレームの圧縮率が閾値以上増加した場合ステップS126肯定かつステップS127肯定には、変更試行部14kは、次のような処理を実行するステップS128。すなわち、変更試行部14kは、図示しない作業用の内部メモリに記憶された変更試行フラグをONに設定する。また、現フレームの更新矩形の面積の割合が閾値未満である場合、あるいは現フレームの圧縮率が閾値以上増加しなかった場合ステップS126否定またはステップS127否定には、変更試行フラグをONに設定せずに、ステップS129へ移行する。そして、算出部14jは、現フレームの圧縮率と、現フレームよりも前に算出されていた所定数のフレーム、例えば過去の5フレームの圧縮率とを平均することによって前フレームまでの圧縮率の平均値を更新するステップS129。その後、第1の送信部14f及び第2の送信部14hは、静止画及び/又は動画の符号化データをクライアント端末20へ送信しステップS130、処理を終了する。[実施例1の効果]上述してきたように、本実施例に係るサーバ装置10は、デスクトップ画面の伝送を動画から静止画に切り換える時に他の静止画の圧縮方式による画面の圧縮を試行した上でその圧縮率の良否によって圧縮方式を選択する。このため、本実施例に係るサーバ装置10では、複数の圧縮方式を適応的に切り替えるので、複数の静止画の圧縮方式同士で互いの弱点を補いながら静止画の圧縮処理を実行できる。また、本実施例に係るサーバ装置10では、動画化が終了してから圧縮方式の変更を試行するので、デスクトップ画面の変更の頻度が減少した時点で圧縮方式の変更を試行される。したがって、本実施例に係るサーバ装置10によれば、処理負荷を抑制しつつ、データ伝送量の削減効率を向上させることが可能になる。さて、これまで開示の装置に関する実施例について説明したが、本発明は上述した実施例以外にも、種々の異なる形態にて実施されてよいものである。そこで、以下では、本発明に含まれる他の実施例を説明する。[3つ以上の圧縮方式]上記の実施例1では、PNGまたはJPEGのうちいずれか一方を選択的に使用する場合を例示したが、他の静止画の圧縮方式を含めて3つ以上の圧縮方式を切り替えて静止画を圧縮する場合にも同様に適用できる。例えば、開示の装置は、PNGやJPEGの他にも、Hextileなどの静止画の圧縮方式を用いることができる。このように、3つ以上の圧縮方式の中から変更を試行する圧縮方式を選択する場合には、予め定められた順番に試行することとしてもよいし、また、上書き画像を全ての圧縮方式で圧縮した上で最も圧縮率が高い圧縮方式を選択することもできる。[色数]上記の実施例1では、更新矩形の面積や静止画の圧縮率が規定の条件を満たす場合に圧縮方式の変更を試行することとしたが、静止画を構成する色の数に関する条件をさらに追加することもできる。例えば、開示の装置は、更新領域の画像に含まれる色の数を計数する。その上で、開示の装置は、選択中の圧縮方式がPNGである場合には、当該更新矩形の色の数が所定の閾値以上であるならばJPEGへの変更を試行する。また、開示の装置は、選択中の圧縮方式がJPEGである場合には、当該更新矩形の色の数が所定の閾値未満であるならばPNGへの変更を試行する。これによって、画像の色の数が多い場合に性能を発揮する圧縮方式と画像の色の数が少ない場合に性能を発揮する圧縮方式との弱点を互いに補うように圧縮方式の変更を試行することが可能になる。[圧縮方式の変更範囲]上記の実施例1では、デスクトップ画面の全体で同一の静止画の圧縮方式が使用される場合を例示したが、デスクトップ画面に含まれる複数の領域の各々で異なる静止画の圧縮方式を用いることもできる。例えば、ワイヤーフレームによってレンダリングされたオブジェクトを含むCADウィンドウとシェーディングによってレンダリングされたオブジェクトを含むCADウィンドウとの複数のウィンドウがデスクトップ画面に表示されている場合を想定する。この場合には、開示の装置は、デスクトップ画面に含まれる領域であってウィンドウ表示がなされていると推定できる領域ごとに上記の変更試行部14kによるステップS126~S127の判定を実行し、その判定結果に応じて変更試行フラグを領域ごとに設定することもできる。このため、開示の装置では、デスクトップ画面のうちワイヤーフレームのオブジェクトを含むCADウィンドウに対応する領域の更新矩形にはPNGによる静止画圧縮を実行させることができる。これとともに、開示の装置は、デスクトップ画面のうちシェーディングのオブジェクトを含むCADウィンドウに対応する領域にはJPEGによる静止画圧縮を実行させることもできる。[マップクリアの延長]例えば、上記の実施例1では、高頻度変更領域識別部14dが更新矩形を蓄積させる周期に合わせて変更頻度判別用のマップをクリアする場合を説明したが、変更頻度判別用のマップをクリアする契機はこれに限定されない。一例としては、高頻度変更領域識別部14dは、高頻度変更領域として識別した領域において変更頻度が閾値を超えなくなった後も所定の期間にわたって継続して高頻度変更領域と識別することもできる。図11A及び図11Bは、マップクリアの延長要領を説明するための図である。図11Aの例では、高頻度変更領域が最初に識別された時点の変更頻度判別用のマップ80Aと、その時点の高頻度変更領域の識別結果81Aとを図示している。また、図11Bの例では、高頻度変更領域が最初に識別されてから所定の期間内である特定の時点の変更頻度判別用のマップ80Bと、その時点の高頻度変更領域の識別結果81Aとを図示している。図11Aに示すように、マップ80Aで変更回数が閾値を超えるメッシュ連結体が取得されて高頻度変更領域の識別結果81Aが得られた場合には、以降に変更回数が閾値を超えるメッシュ連結体が取得されなくとも識別結果81Aを所定の期間引き継ぐ。すなわち、図11Bに示すように、マップ80Aで変更回数が閾値を超えるメッシュ連結体が取得されずとも、最初に高頻度変更領域の識別結果81Aを識別してから所定の期間内であれば高頻度変更領域の識別結果81Aを引き継ぐ。なお、上記の閾値は、サーバ側リモート画面制御用アプリの開発者が段階的に設定した値をエンドユーザに選択させたり、また、エンドユーザが値を直接設定することができる。これによって、実際に動画が再生される領域において間欠的に動きがなくなった場合でも、高頻度変更領域を断続的に識別することがなくなる結果、高頻度変更領域で画像のコマ落ちが断続的に発生するのを防止できる。さらに、高頻度変更領域の識別結果を引き継ぐことにより高頻度変更領域のサイズが安定するので、エンコード時のパラメータを初期化する頻度を低減できる結果、エンコーダにかかる負荷を低減することも可能になる。[高頻度変更領域の縮小の抑制]他の一例としては、高頻度変更領域識別部14dは、高頻度変更領域として識別した領域が以前に高頻度変更領域と識別した領域よりも縮小した場合に、次のような処理を行う。すなわち、高頻度変更領域識別部14dは、当該縮小した度合いが所定の閾値以下であるならば、前回の識別時に高頻度変更領域と識別した領域を今回の識別結果として引き継ぐ。図12A及び図12Bは、高頻度変更領域の縮小に関する抑制要領を説明するための図である。図12Aの例では、時点T1の変更頻度判別用のマップ90Aと高頻度変更領域の識別結果91Aとを図示している。また、図12Bの例では、時点T2の変更頻度判別用のマップ90Bと高頻度変更領域の識別結果91Aとを図示している。なお、上記の時点T1および時点T2はT1<T2であるものとする。図12Aに示すように、マップ90Aで変更回数が閾値を超えるメッシュ連結体が取得されて高頻度変更領域の識別結果91Aが得られた場合には、時点T1以降に変更回数が閾値を超えるメッシュ連結体が縮小されても直ちに高頻度変更領域を縮小しない。すなわち、図12Bに示すように、変更回数が閾値を超えるメッシュ連結体が斜線の部分について縮小したとしてもその面積が所定の閾値、例えば半分以下であるならば、高頻度変更領域の識別結果91Aを引き継ぐ。これによって、実際に動画が再生される領域において一部の動きが間欠的になったとしても、高頻度変更領域を断続的に識別することがなくなる結果、高頻度変更領域で画像のコマ落ちが断続的に発生するのを防止できる。さらに、高頻度変更領域の識別結果を引き継ぐことにより高頻度変更領域のサイズが安定するので、エンコード時のパラメータを初期化する頻度を低減できる結果、エンコーダにかかる負荷を低減することも可能になる。[上書き領域]上記の実施例1では、動画化中に高頻度変更領域であった領域を上書き領域とする場合を例示したが、開示の装置はこれに限定されない。例えば、開示の装置は、デスクトップ画面全体を上書き領域とすることもできるし、また、動画化開始から動画化終了までの期間で更新矩形が実際に生成された領域だけを上書き領域とすることもできる。[分散および統合]また、図示した各装置の各構成要素は、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散統合の具体的形態は図示のものに限られず、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散統合して構成することができる。例えば、サーバ装置10の第1の送信部14f及び第2の送信部14hが実行する画像の送信処理を1つの送信部に統合することとしてもよい。また、クライアント端末20の第1の受信部23b及び第2の受信部23eが実行する画像の受信処理を1つの画像受信部に統合することとしてもかまわない。さらに、クライアント端末の第1の表示制御部23d及び第2の表示制御部23gが実行する表示制御処理を1つの表示制御部に統合することとしてもよい。[画像送信プログラム]また、上記の実施例で説明した各種の処理は、予め用意されたプログラムをパーソナルコンピュータやワークステーションなどのコンピュータで実行することによって実現することができる。そこで、以下では、図13を用いて、上記の実施例と同様の機能を有する画像送信プログラムを実行するコンピュータの一例について説明する。図13は、実施例1及び実施例2に係る画像送信プログラムを実行するコンピュータの一例について説明するための図である。図13に示すように、コンピュータ100は、操作部110aと、スピーカ110bと、カメラ110cと、ディスプレイ120と、通信部130とを有する。さらに、このコンピュータ100は、CPU150と、ROM160と、HDD170と、RAM180と有する。これら110~180の各部はバス140を介して接続される。HDD170には、図13に示すように、上記の実施例1で示したサーバ側のリモート画面制御部14と同様の機能を発揮する画像送信プログラム170aが予め記憶される。この画像送信プログラム170aについては、図1に示した各々のリモート画面制御部14の各構成要素と同様、適宜統合又は分離しても良い。すなわち、HDD170に格納される各データは、常に全てのデータがHDD170に格納される必要はなく、処理に必要なデータのみがHDD170に格納されれば良い。そして、CPU150が、画像送信プログラム170aをHDD170から読み出してRAM180に展開する。これによって、図13に示すように、画像送信プログラム170aは、画像送信プロセス180aとして機能する。この画像送信プロセス180aは、HDD170から読み出した各種データを適宜RAM180上の自身に割り当てられた領域に展開し、この展開した各種データに基づいて各種処理を実行する。なお、画像送信プロセス180aは、図1に示した各々のリモート画面制御部14にて実行される処理、例えば図8~図10に示す処理を含む。また、CPU150上で仮想的に実現される各処理部は、常に全ての処理部がCPU150上で動作する必要はなく、処理に必要な処理部のみが仮想的に実現されれば良い。なお、上記の画像送信プログラム170aについては、必ずしも最初からHDD170やROM160に記憶させておく必要はない。例えば、コンピュータ100に挿入されるフレキシブルディスク、いわゆるFD、CD-ROM、DVDディスク、光磁気ディスク、ICカードなどの可搬用の物理媒体に各プログラムを記憶させる。そして、コンピュータ100がこれらの可搬用の物理媒体から各プログラムを取得して実行するようにしてもよい。また、公衆回線、インターネット、LAN、WANなどを介してコンピュータ100に接続される他のコンピュータまたはサーバ装置などに各プログラムを記憶させておき、コンピュータ100がこれらから各プログラムを取得して実行するようにしてもよい。"