JP5664289B2 - 情報処理装置、画像送信プログラムおよび画像表示方法 - Google Patents

Description

本発明は、情報処理装置、画像送信プログラムおよび画像表示方法に関する。

シンクライアント（thin client）というシステムが知られている。シンクライアントシステムでは、クライアントに最低限の機能しか持たせず、サーバでアプリケーションやファイルなどのリソースを管理するようにシステムが構築される。

かかるシンクライアントシステムは、実際にはサーバが処理を実行した処理結果やサーバが保持するデータをクライアントに表示させつつも、あたかもクライアントが主体となって処理を実行したり、データを保持したりしているかのように振る舞う。

一例として、シンクライアントシステムは、サーバで資料作成やメールなどの業務に関するアプリケーションを実行させ、そのアプリケーションの処理結果をクライアントに表示させる。このような業務アプリの他にも、ＣＡＤ（Computer-Aided Design）などのように繊細な画像を扱うアプリケーション、さらには、動画を扱うアプリケーションなどがシンクライアントシステムの適用範囲として拡充されることが求められる。

ところが、シンクライアントシステムで通信に用いられるプロトコル、例えばＶＮＣ（Virtual Network Computing）で画像や動画などの大容量のデータを扱う場合には、クライアントで実行される操作に対するレスポンスが悪化する問題がある。

このことから、操作レスポンスを改善するための技術の一例として、次のような技術が提案されている。これを説明すると、サーバは、特定のメディアアプリケーションの出力を途中でフックしてそのメディアアプリケーションが扱うデータをクライアントに送信する。一方、クライアントは、サーバで動作するメディアアプリケーションが扱うデータの再生処理を行う。

特表２００７−５０５５８０号公報 特開２００９−１９４６２６号公報 特開２０１０−１１８９７６号公報

ところで、クライアントにより動画データが再生された画像は、静止画データが再生された画像と比較して劣化する。このため、サーバは、動画データの送信が終了した際に、静止画データを送信する場合がある。

しかしながら、上記の従来技術であっても、メディアアプリケーションが扱う動画データが大容量である場合には、動画データの送信が終了した際に同じ領域の静止画データを送信すると、送信帯域が増加してしまうという問題があった。

開示の技術は、上記に鑑みてなされたものであって、動画データの送信が終了した際の送信帯域の増加を軽減できる情報処理装置などを提供することを目的とする。

本願の開示する情報処理装置は、ネットワーク経由で接続された端末装置へ画像を送信する情報処理装置であって、前記画像を保持する画像メモリと、前記画像メモリの画像を期間毎に圧縮する第１の圧縮部と、前記画像メモリで保持した画像から前記第１の圧縮部を用いて圧縮する動画領域を検出する動画領域検出部と、前記第１の圧縮部よりも画像劣化が低くなるように、前記画像メモリの画像を圧縮する第２の圧縮部と、前記第１の圧縮部で圧縮された領域の中から変化した変化領域を検出する変化領域検出部と、前記変化領域を積算して積算変化領域を算出する算出部と、前記動画領域検出部で検出した動画領域を前記第１の圧縮部で圧縮した動画画像と、前記変化領域検出部で検出した変化領域とを前記端末装置へ送信し、前記動画画像の送信終了時に、前記算出部で算出した積算変化領域を前記第２の圧縮部で圧縮した画像を送信する送信部とを有する。

本願の開示する情報処理装置の一つの態様によれば、動画データの送信が終了した際の送信帯域の増加を軽減することができる。

図１は、実施例に係るシンクライアントシステムに含まれる各装置の構成を示すブロック図である。 図２は、デスクトップ画面の分割要領を説明するための図である。 図３Ａは、デスクトップ画面の変更頻度の判別要領を説明するための図である。 図３Ｂは、デスクトップ画面の変更頻度の判別要領を説明するための図である。 図３Ｃは、デスクトップ画面の変更頻度の判別要領を説明するための図である。 図４は、メッシュ連結体の補正要領を説明するための図である。 図５は、高頻度変更領域の候補の合成要領を説明するための説明図である。 図６Ａは、高頻度変更領域の属性情報の通知要領を説明するための図である。 図６Ｂは、高頻度変更領域の属性情報の通知要領を説明するための図である。 図６Ｃは、高頻度変更領域の属性情報の通知要領を説明するための図である。 図７は、ウィンドウが移動する場合にサーバ装置がクライアント端末へ送信する画像の送信方式の一例を示す図である。 図８は、コピー領域の位置を算出する方法を説明するための図である。 図９は、ウィンドウが移動する一態様を示す図である。 図１０Ａは、更新頻度と移動面積を説明するための図である。 図１０Ｂは、更新頻度と移動面積を説明するための図である。 図１０Ｃは、更新頻度と移動面積を説明するための図である。 図１１Ａは、更新領域の属性情報の算出を説明するための図である。 図１１Ｂは、更新領域の属性情報の算出を説明するための図である。 図１２Ａは、積算更新領域の属性情報の算出を説明するための図である。 図１２Ｂは、積算更新領域の属性情報の算出を説明するための図である。 図１３は、実施例に係る画像送信処理の手順を示すフローチャートである。 図１４は、実施例に係る画像送信処理の手順を示すフローチャートである。 図１５は、実施例に係る画像表示処理の手順を示すフローチャートである。 図１６は、実施例に係る画像送信処理の変形例の手順を示すフローチャートである。 図１７は、実施例に係る画像送信プログラムを実行するコンピュータの一例について説明するための図である。

以下に、本願の開示する情報処理装置、画像送信プログラムおよび画像表示方法の実施例を図面に基づいて詳細に説明する。なお、本実施例によりこの発明が限定されるものではない。

［システム構成］
図１は、本実施例に係るシンクライアントシステムについて説明する。図１は、実施例に係るシンクライアントに含まれる各装置の構成を示すブロック図である。

図１に示すシンクライアントシステム１は、クライアント端末２０が表示する画面をリモートでサーバ装置１０に制御させるものである。つまり、シンクライアントシステム１は、実際にはサーバ装置１０が実行した処理結果や保持するデータをクライアント端末２０に表示させつつも、あたかもクライアント端末２０が主体となって処理を実行したり、データを保持したりしているかのように振る舞う。

図１に示すように、シンクライアントシステム１は、サーバ装置１０と、クライアント端末２０とを有する。なお、図１の例では、１つのサーバ装置１０に対し、１つのクライアント端末を接続する場合を図示したが、任意の数のクライアント端末を接続できる。

これらサーバ装置１０およびクライアント端末２０は、所定のネットワークを介して、相互に通信可能に接続される。かかるネットワークには、有線または無線を問わず、インターネット、ＬＡＮ（Local Area Network）やＶＰＮ（Virtual Private Network）などの任意の種類の通信網を採用できる。なお、サーバ装置１０およびクライアント端末２０間の通信プロトコルには、一例として、ＶＮＣにおけるＲＦＢ（Remote Frame Buffer）プロトコルを採用する場合を想定する。

サーバ装置１０は、クライアント端末２０に表示させる画面をリモートで制御するサービスを提供するコンピュータである。このサーバ装置１０には、サーバ向けリモート画面制御用のアプリケーションがインストールまたはプレインストールされる。なお、以下では、サーバ向けのリモート画面制御用のアプリケーションをサーバ側リモート画面制御用アプリと呼ぶ。

このサーバ側リモート画面制御用アプリは、基本機能として、リモート画面制御サービスを提供する機能を有する。一例としては、サーバ側リモート画面制御用アプリは、クライアント端末２０における操作情報を取得したうえでその操作により要求された処理を自装置で動作するアプリケーションに実行させる。そして、サーバ側リモート画面制御用アプリは、アプリケーションにより実行された処理結果を表示するための画面を生成したうえでその画面をクライアント端末２０へ送信する。このとき、サーバ側リモート画面制御用アプリは、今回の画面生成の前にクライアント端末２０で表示させていたビットマップ画像との間で変更のあった部分の画像が集まった領域、すなわち更新矩形の画像を送信する。なお、以下では、一例として、更新部分の画像が矩形の画像で形成される場合を説明するが、開示の装置は更新部分の画像が矩形以外の形状で形成される場合にも適用できる。

また、サーバ側リモート画面制御用アプリは、フレーム間で動きが大きい部分のデータを動画向けの圧縮方式のデータに圧縮してクライアント端末２０へ送信する機能も有する。一例としては、サーバ側リモート画面制御用アプリは、アプリケーションにより実行された処理結果から生成した画面を複数の領域に分割し、分割した領域ごとに変更の頻度を監視する。このとき、サーバ側リモート画面制御用アプリは、変更の頻度が閾値を超えた領域、すなわち高頻度変更領域の属性情報をクライアント端末２０へ送信する。これとともに、サーバ側リモート画面制御用アプリは、高頻度変更領域のビットマップ画像をＭＰＥＧ−２やＭＰＥＧ−４などのＭＰＥＧ方式のデータにエンコードしたうえでクライアント端末２０へ送信する。なお、ここでは、ＭＰＥＧ（Moving Picture Experts Group）方式のデータ圧縮する場合を例示したが、これに限定されない。例えば、動画向けの圧縮方式であれば任意の圧縮符号化方式、例えばＭｏｔｉｏｎ−ＪＰＥＧ（Joint Photographic Experts Group）などを採用できる。

クライアント端末２０は、サーバ装置１０によるリモート画面制御サービスの提供を受ける側のコンピュータである。かかるクライアント端末２０の一例としては、パーソナルコンピュータなど固定端末のほか、携帯電話機、ＰＨＳ（Personal Handyphone System）やＰＤＡ（Personal Digital Assistant）などの移動体端末を適用することもできる。このクライアント端末２０には、クライアント向けのリモート画面制御用アプリケーションがインストールまたはプリインストールされる。なお、以下では、クライアント向けのリモート画面制御用のアプリケーションをクライアント側リモート画面制御用アプリと呼ぶ。

このクライアント側リモート画面制御用アプリは、マウスやキーボードなどの各種の入力デバイスを介して受け付けた操作情報をサーバ装置１０へ通知する機能を有する。一例としては、クライアント側リモート画面制御用アプリは、マウスの左右のクリックを始め
、ダブルクリックやドラッグ、マウスの移動操作を介して得られたマウスカーソルの位置や移動量などを操作情報として通知する。他の一例としては、マウスホイールの回転量、キーボードのうち押下されたキーの種別なども操作情報として通知する。

さらに、クライアント側リモート画面制御用アプリは、サーバ装置１０から受信した画像を所定の表示部に表示させる機能を有する。一例としては、クライアント側リモート画面制御用アプリは、サーバ装置１０から更新矩形のビットマップ画像を受信した場合には、更新矩形の画像を前回のビットマップ画像から変更のあった位置に合わせて表示する。他の一例としては、クライアント側リモート画面制御用アプリは、サーバ装置１０から高頻度変更領域の属性情報を受信した場合には、その属性情報に含まれる位置に対応する表示画面上の領域をビットマップ画像の表示対象外のブランク領域とする。そのうえで、クライアント側リモート画面制御用アプリは、動画向けの圧縮方式のデータを受信した場合にそのデータをデコードしたうえでブランク領域に表示する。

［サーバ装置の構成］
次に、本実施例に係るサーバ装置の構成について説明する。図１に示すように、サーバ装置１０は、ＯＳ実行制御部１１ａと、アプリ実行制御部１１ｂと、グラフィックドライバ１２と、フレームバッファ１３と、サーバ側リモート画面制御部１４とを有する。なお、図１の例では、図１に示した機能部以外にも既知のコンピュータが有する各種の機能部、例えば各種の入力デバイスなどの機能を有するものとする。

ＯＳ実行制御部１１ａは、ＯＳ（Operation System）の実行を制御する処理部である。例えば、ＯＳ実行制御部１１ａは、後述の操作情報取得部１４ａにより取得された操作情報からアプリケーションの起動指示やアプリケーションに対するコマンドを検出する。一例としては、ＯＳ実行制御部１１ａは、アプリケーションのアイコン上でダブルクリックを検出した場合に、そのアイコンに対応するアプリケーションの起動を後述のアプリ実行制御部１１ｂへ指示する。他の一例としては、起動中のアプリケーションの操作画面、いわゆるウィンドウ上でコマンドの実行を要求する操作を検出した場合に、ＯＳ実行制御部１１ａは、そのコマンドの実行をアプリ実行制御部１１ｂへ指示する。なお、以下では、アプリケーションをアプリと略記する。

アプリ実行制御部１１ｂは、ＯＳ実行制御部１１ａによる指示に基づき、アプリケーションの実行を制御する処理部である。一例としては、アプリ実行制御部１１ｂは、ＯＳ実行制御部１１ａによりアプリの起動が指示された場合や起動中のアプリにコマンドの実行が指示された場合にアプリを動作させる。そして、アプリ実行制御部１１ｂは、アプリを実行することにより得られた処理結果の表示用イメージをフレームバッファ１３に描画する要求を後述のグラフィックドライバ１２へ行う。このようにグラフィックドライバ１２へ描画要求を行う場合には、アプリ実行制御部１１ｂは、表示用イメージとともに表示用イメージの描画位置をグラフィックドライバ１２へ通知する。

なお、アプリ実行制御部１１ｂが実行するアプリは、プリインストールされたものであってもよく、サーバ装置１０の出荷後にインストールされたものであってもかまわない。また、ＪＡＶＡ（登録商標）などのネットワーク環境で動作するアプリであってもよい。

グラフィックドライバ１２は、フレームバッファ１３に対する描画処理を実行する処理部である。一例としては、グラフィックドライバ１２は、アプリ実行制御部１１ｂからの描画要求を受け付けた場合に、アプリの処理結果の表示用イメージをアプリにより指定されたフレームバッファ１３上の描画位置へビットマップ形式で描画する。なお、ここでは、アプリにより描画要求を受け付ける場合を説明したが、ＯＳ実行制御部１１ａからの描画要求を受け付けることもできる。一例としては、グラフィックドライバ１２は、ＯＳ実行制御部１１ａからマウスカーソルの描画要求を受け付けた場合に、マウスカーソルの表示用イメージをＯＳにより指定されたフレームバッファ１３上の描画位置ビットマップ形式で描画する。

フレームバッファ１３は、グラフィックドライバ１２により描画されたビットマップデータを記憶する記憶デバイスである。かかるフレームバッファ１３の一態様としては、ＶＲＡＭ（Video Random Access Memory）を始めとするＲＡＭ（Random Access Memory）、ＲＯＭ（Read Only Memory）やフラッシュメモリなどの半導体メモリ素子が挙げられる。なお、フレームバッファ１３は、ハードディスク、光ディスクなどの記憶装置を採用することとしてもかまわない。

サーバ側リモート画面制御部１４は、サーバ側リモート画面制御用アプリを通じて、リモート画面制御サービスをクライアント端末２０へ提供する処理部である。図１に示すように、サーバ側リモート画面制御部１４は、操作情報取得部１４ａと、画面生成部１４ｂと、変更頻度判別部１４ｃと、高頻度変更領域識別部１４ｄと、エンコーダ１４ｅと、第１の画像送信部１４ｆと、第２の画像送信部１４ｇとを有する。また、サーバ側リモート画面制御部１４は、属性情報送信部１４ｈと、コピーイベント制御部１４ｋと、全画面動画化判定部１４ｍとを有する。さらに、サーバ側リモート画面制御部１４は、高頻度画面更新領域識別部１４ｎと、画面更新通知部１４ｏとを有する。

操作情報取得部１４ａは、クライアント端末２０から操作情報を取得する処理部である。かかる操作情報の一例としては、マウスの左右のクリックを始め、ダブルクリックやドラッグ、マウスの移動操作を介して得られたマウスカーソルの位置や移動量などが上げられる。操作情報の他の一例としては、マウスホイールの回転量、キーボードのうち押下されたキーの種別なども挙げられる。

画面生成部１４ｂは、クライアント端末２０の表示部２２に表示させる画面の画像を生成する処理部である。一例としては、画面生成部１４ｂは、グラフィックドライバ１２によりフレームバッファ１３へビットマップデータが格納される度に、次のような処理を起動する。すなわち、画面生成部１４ｂは、前回のフレーム生成時にクライアント端末２０で表示させていたデスクトップ画面と、今回のフレーム生成時にフレームバッファ１３へ書き込まれたデスクトップ画面とを比較する。そして、画面生成部１４ｂは、前回のフレームから変更があった部分の画素をつなぎ合わせたうえで矩形に整形した更新矩形の画像を生成し、更新矩形送信用のパケットを生成する。なお、画面生成部１４ｂは、後述するエンコーダ１４ｅよりも画像劣化が低くなるように、フレームバッファ１３の画像を圧縮するものとしても良い。

変更頻度判別部１４ｃは、フレームバッファ１３に描画された画像を分割した領域ごとにフレーム間の変更の頻度を判別する処理部である。一例としては、変更頻度判別部１４ｃは、画面生成部１４ｂにより生成された更新矩形を図示しない作業用の内部メモリへ所定の期間にわたって蓄積する。このとき、変更頻度判別部１４ｃは、更新矩形の位置および大きさを特定可能な属性情報、例えば更新矩形の左上の頂点の座標と更新矩形の幅および高さとを蓄積する。かかる更新矩形を蓄積させる期間は、高頻度変更領域を識別する精度と相関関係があり、期間を長くするほど高頻度変更領域の誤検出が低減される。なお、ここでは、一例として、１秒間にわたって更新矩形の画像を蓄積する場合を想定する。

このとき、変更頻度判別部１４ｃは、更新矩形の画像を蓄積してから所定の期間が経過した場合に、クライアント端末２０に表示させるデスクトップ画面をメッシュ状に分割したマップを用いて、デスクトップ画面の変更頻度を判別する。

図２は、デスクトップ画面の分割要領を説明するための図である。図２に示す符号３０は、変更頻度判別用のマップを示す。図２に示す符号３１は、マップ３０に含まれるメッシュを指す。図２に示す符号３２は、メッシュ３１を形成する画素のブロックに含まれる１画素を指す。図２に示す例では、変更頻度判別部１４ｃがマップ３０を占める画素のうち８画素×８画素のブロックを１つのメッシュとして分割する場合を想定している。この場合には、１つのメッシュに６４個の画素が含まれることになる。

ここで、変更頻度判別部１４ｃは、作業用の内部メモリに蓄積した更新矩形の位置および大きさにしたがって更新矩形の画像を変更頻度判別用のマップに順次展開する。そして、変更頻度判別部１４ｃは、更新矩形をマップに展開する度に、マップ上で更新矩形と重なり合った部分のメッシュの変更回数を累積して加算する。このとき、変更頻度更新部１４ｃは、マップ上に展開された更新矩形がメッシュに含まれる画素との間で所定数にわたって重なり合った場合に、そのメッシュの変更回数を１つ加算する。なお、ここでは、更新矩形がメッシュに含まれる画素と１つでも重なり合った場合に、メッシュの変更回数を加算する場合を想定して説明を行う。

図３Ａ〜図３Ｃは、デスクトップ画面の変更頻度の判別要領を説明するための図である。図３Ａ〜図３Ｃに示す符号４０Ａ、符号４０Ｂおよび符号４０Ｎは変更頻度判別用のマップを示す。図３Ａおよび図３Ｂに示す符号４１Ａおよび符号４１Ｂは更新矩形を示す。ここで、マップ４０Ａのメッシュ内に図示した数字は、更新矩形４１Ａが展開された時点におけるメッシュの変更回数を示す。また、マップ４０Ｂのメッシュ内に図示した数字は、更新矩形４１Ｂが展開された時点におけるメッシュの変更回数を示す。さらに、マップ４０Ｎのメッシュ内に図示した数字は、作業用の内部メモリに蓄積した更新矩形が全て展開された時点におけるメッシュの変更回数を示す。なお、図３Ａ〜図３Ｃにおいて数字が図示されていないメッシュは変更回数がゼロであるものとする。

図３Ａに示すように、更新矩形４１Ａがマップ４０Ａに展開された場合には、網掛け部分のメッシュが更新矩形４１Ａと重なり合う。このため、変更頻度判別部１４ｃは、網掛け部分のメッシュの更新回数を１つずつ加算する。この場合には、各メッシュの変更回数はゼロであるため、網掛け部分の変更回数は０から１に加算される。さらに、図３Ｂに示すように、更新矩形４１Ｂがマップ４０Ｂに展開された場合には、網掛け部分のメッシュが更新矩形４０Ｂと重なり合う。このため、変更頻度判別部１４ｃは、網掛け部分のメッシュの更新回数を１つずつ加算する。この場合には、各メッシュの変更回数は１であるため、網掛け部分の変更回数は１から２に加算される。このようにして全ての更新矩形がマップに展開された段階では、図３Ｃに示すマップ４０Ｎの結果が得られる。

そして、変更頻度判別部１４ｃは、作業用の内部メモリに蓄積した更新矩形を全てマップに展開し終えた場合に、所定の期間における変更回数、すなわち変更頻度が閾値を超えるメッシュを取得する。図３Ｃの例で言えば、閾値を「４」としたとき、網掛け部分のメッシュが取得されることになる。かかる閾値は、その値を高く設定するほどデスクトップ画面で動画が表示されている可能性が高い部分を後述のエンコーダ１４ｅによりエンコードできる。なお、上記の「閾値」は、サーバ側リモート画面制御用アプリの開発者が段階的に設定した値をエンドユーザに選択させたり、また、エンドユーザが値を直接設定することができる。

図１の説明に戻り、高頻度変更領域識別部１４ｄは、クライアント端末２０に表示されるデスクトップ画面のうち高頻度で変更される領域を高頻度変更領域として識別する処理部である。

高頻度変更領域識別部１４ｄは、変更頻度判別部１４ｃにより変更回数が閾値を超えるメッシュが取得された場合に、隣接するメッシュ同士を連結したメッシュ連結体に補完する補間領域を導出する。そのうえで、高頻度変更領域識別部１４ｄは、導出した補完領域をメッシュ連結体に足し合わせることによりメッシュ連結体を矩形に補正する。この補間領域の導出には、メッシュの連結体が最小の補間で矩形に整形される領域を導出するアルゴリズムが適用される。

図４は、メッシュ連結体の補正要領を説明するための図である。図４に示す符号５１は補正前のメッシュ連結体を示す。図４に示す符号５２は補間領域を示す。また、図４に示す符号５３は補正後の矩形を示す。図４に示すように、高頻度変更領域識別部１４ｄは、メッシュ連結体５１に補間領域５２を足し合わせることにより、メッシュ連結体５１を矩形５３に補正する。この段階では、後述の矩形の合成が完了しておらず、矩形５３が未だ高頻度変更領域と確定していないので、補正後の矩形を高頻度変更領域の候補と呼ぶこととする。

高頻度変更領域識別部１４ｄは、高頻度変更領域の候補が複数存在する場合には、複数の高頻度変更領域の候補の距離が所定の値以下である高頻度変更領域の候補同士を含む矩形に合成する。ここで言う高頻度変更領域の候補の距離とは、補正後の矩形の最短距離を指すものとする。一例としては、高頻度変更領域識別部１４ｄは、高頻度変更領域の候補を合成するにあたって各候補の間を埋める補間領域を導出する。そのうえで、高頻度変更領域識別部１４ｄは、導出した補間領域を高頻度変更領域の候補に足し合わせることにより、高頻度変更領域の候補同士を含む矩形に合成する。この補間領域の導出には、高頻度変更領域の候補の間が最小の補間で合成体に整形される領域を導出するアルゴリズムが適用される。

図５は、高頻度変更領域の候補の合成要領を説明するための説明図である。図５に示す符号６１Ａおよび符号６１Ｂは、高頻度変更領域の候補を指す。図５に示す符号６２は補間領域を指す。図５に示す符号６３は、高頻度変更領域の候補６１Ａおよび高頻度変更領域の候補６１Ｂの合成体を指す。図５に示すように、高頻度変更領域識別部１４ｄは、高頻度変更領域の候補６１Ａおよび高頻度変更領域の候補６１Ｂの距離ｄが所定の距離以内である場合に補間領域６２を足し合わせる。これにより、高頻度変更領域の候補６１Ａおよび高頻度変更領域の候補６１Ｂを含む合成体６３へ合成する。そして、高頻度変更領域識別部１４ｄは、このようにして得た合成体を高頻度変更領域と識別する。

このようにして高頻度変更領域を識別すると、高頻度変更領域識別部１４ｄは、高頻度変更領域の位置および大きさを特定可能な属性情報を後述の属性情報送信部１４ｈへ出力する。このようにして属性情報送信部１４ｈに高頻度変更領域の属性情報をクライアント端末２０へ通知させることにより、クライアント端末２０で表示されるデスクトップ画面のビットマップデータのうち高頻度変更領域に対応する部分をブランク表示させる。その後、高頻度変更領域識別部１４ｄは、作業用の内部メモリにマッピングされたメッシュの変更回数を後述の全画面動画化判定用マップに加算したうえでクリアする。なお、高頻度変更領域識別部１４ｄは、高頻度変更領域の属性情報を作業用の内部メモリに登録する。

また、高頻度変更領域識別部１４ｄは、画面生成部１４ｂにより更新矩形が生成される度に、その更新矩形が作業用の内部メモリに記憶された高頻度変更領域、すなわち後述の第２の画像送信部１４ｇにより動画を送信中の領域に含まれるか否かを判定する。このとき、高頻度変更領域識別部１４ｄは、更新矩形が高頻度変更領域に含まれない場合には、更新矩形の画像および属性情報を後述の第１の画像送信部１４ｆに送信させる。一方、高頻度変更領域識別部１４ｄは、更新矩形が高頻度変更領域に含まれる場合には、原則として、後述の第１の画像送信部１４ｆに更新矩形の画像および属性情報を送信させない。なお、更新矩形がＯＳ実行制御部１１ａにより描画されたマウスのものである場合には、マウスに関する更新矩形の画像および属性情報を例外的に送信させることとしてもよい。

また、高頻度変更領域識別部１４ｄは、フレームバッファ１３にビットマップデータが描画される度に、作業用の内部メモリの高頻度変更領域の属性情報が登録されているか否かを判定する。そして、高頻度変更領域識別部１４ｄは、高頻度変更領域の属性情報が登録されている場合に、フレームバッファ１３に描画されたビットマップデータのうち高頻度変更領域に対応する部分のビットマップ画像を切り出す。そのうえで、高頻度変更領域識別部１４ｄは、後述のエンコーダ１４ｅへ出力する。

エンコーダ１４ｅは、画像をエンコードする処理部である。一例として、高頻度変更領域識別部１４ｄから高頻度変更領域の画像が入力される画像をエンコードする場合が挙げられる。この場合には、エンコーダ１４ｅは、高頻度変更領域識別部１４ｄから入力された高頻度変更領域のビットマップ画像がストリームを形成可能なフレーム数に到達した段階で高頻度変更領域のビットマップ画像をエンコードする。なお、エンコード方式の一態様としては、ＭＰＥＧ−２やＭＰＥＧ−４などのＭＰＥＧ方式やＭｏｔｉｏｎ−ＪＰＥＧ方式が挙げられる。

第１の画像送信部１４ｆは、画面生成部１４ｂにより生成された更新矩形の画像および属性情報をクライアント端末２０へ送信する処理部である。この更新矩形を送信する場合の通信プロトコルには、一例として、ＶＮＣにおけるＲＦＢプロトコルが採用される。

第２の画像送信部１４ｇは、エンコーダ１４ｅによりエンコードされたエンコード画像および属性情報をクライアント端末２０へ送信する処理部である。このエンコード画像を送信する場合の通信プロトコルには、一例として、ＲＴＰ（Real-time Transport Protocol）を採用できる。

属性情報送信部１４ｈは、画像の属性情報をクライアント端末２０へ送信する処理部である。一例としては、高頻度変更領域識別部１４ｄにより高頻度変化領域が識別されると、属性情報送信部１４ｈは、高頻度変更領域の位置および大きさを特定可能な属性情報をクライアント端末２０へ送信する。これにより、クライアント端末２０で表示されるデスクトップ画面のビットマップデータのうち高頻度変更領域に対応する部分をブランク表示させる。

図６Ａ〜図６Ｃは、高頻度変更領域の属性情報の通知要領を説明するための図である。図６Ａに示す符号７０Ａは、フレームバッファ１３に描画されたデスクトップ画面の一例を示す。図６Ｂ〜図６Ｃに示す符号７０Ｂおよび符号７０Ｃは、変更頻度判別用のマップを示す。図６Ａに示す符号７１は、ブラウザ画面を指す。図６Ａに示す符号７２は、動画再生画面を指す。図６Ｂに示す符号７３は、マウスの移動軌跡を示す。図６Ｂに示す符号７４は、アプリによる動画再生領域を示す。

図６Ａに示すように、デスクトップ画面７０Ａには、ブラウザ画面７１および動画再生画面７２が含まれる。このデスクトップ画面７０Ａから経時的な変化を追った場合には、図６Ｂに示すように、静止画であるブラウザ画面７１の更新矩形は検出されず、マウスの移動軌跡７３および動画再生領域７４に関する更新矩形が検出される。このうち、動画再生領域７４で変更回数が閾値を超えるメッシュ、すなわち図示の網掛け部分が高頻度変更領域識別部１４ｄにより識別されたものとする。この場合には、属性情報送信部１４ｈは、図６Ｃに示す網掛け部分の高頻度変更領域の左上の頂点の座標（ｘ、ｙ）と、高頻度変更領域の幅ｗおよび高さｈとを高頻度変更領域の属性情報としてクライアント端末２０へ送信する。なお、ここでは、高頻度変更領域の位置を特定する点として左上の頂点の座標を採用する場合を説明したが、他の頂点を採用することとしてもかまわない。また、高頻度変更領域の位置を特定することができる点であれば、頂点以外の任意の点、例えば重心などを採用できる。また、ここでは、画面上の左上を座標軸ＸＹの原点とする場合を説明したが、画面内および画面外の任意の点を原点とすることができる。

このように、サーバ装置１０では、動画向けの圧縮方式を用いる領域を高頻度変更領域として特定のアプリケーションに依存せずに識別する。さらに、サーバ装置１０では、高頻度変更領域以外の領域については変更があった部分の画像を送信しつつ、高頻度変更領域についてはその領域に対応する画像を動画向けの圧縮方式のデータに圧縮する。それゆえ、サーバ装置１０では、クライアント端末２０へ送信する画像のうち操作レスポンスを悪化させる根本となる画像に重点を置いてデータ量を低減しつつ、圧縮処理を行うエンコーダ、端末装置側で復号化処理を行うデコーダの負荷を最小限にできる。このため、サーバ装置１０では、シンクライアントの汎用性を維持しつつ、操作レスポンスを向上させることが可能になる。

ところが、サーバ装置１０では、高頻度変更領域を識別するには一定の時間が必要となる。このため、フレームバッファ１３へ描画される画像のフレーム間で動きが激しい変更が描画されたとしても変更が短期間である場合には、その変更が行われた領域を高頻度変更領域として識別することはできない。

例えば、ウィンドウが移動された場合には、ウィンドウの動きを追従することができず、クライアント端末２０で動画をスムーズに表示できない場合がある。図７は、ウィンドウが移動する場合にサーバ装置がクライアント端末へ送信する画像の送信方式の一例を示す図である。図７の例では、動画アプリが動画を再生している場合にそのウィンドウのタイトルバーがドラッグ＆ドロップされる場合を想定している。

図７に示すように、動画アプリにより動画が再生される時刻Ｔ１前までは、ウィンドウは停止しているので、フレーム間の変更部分が更新矩形の画像としてサーバ装置１０からクライアント端末２０へ送信される。そして、時刻Ｔ１となって動画アプリによる動画の再生が開始される。その後、時刻Ｔ２となった段階でサーバ装置１０によりウィンドウが高頻度変更領域と識別されてウィンドウの画像が動画でクライアント端末２０へ送信され始める。

ところが、時刻Ｔ３になった段階でウィンドウのタイトルバーをドラッグ＆ドロップすることにより移動され始める。そうすると、動きの激しい部分がウィンドウの移動に伴って一緒に移動するので、動画再生中であるにもかかわらず、ウィンドウは高頻度変更領域とは識別されなくなる。その後、時刻Ｔ４になってウィンドウの移動が停止されてからも時刻Ｔ５になるまで、ウィンドウは高頻度変更領域とは識別されない。そして、ようやく時刻Ｔ５になってサーバ装置１０によりウィンドウが高頻度変更領域と識別されてウィンドウの画像が動画でクライアント端末２０へ送信され始める。

このように、ウィンドウが移動された場合には、網掛け部分の期間にわたって動画アプリにより再生される動画が更新矩形としてクライアント端末２０へ送信されるので、操作レスポンスが低下する。

かかるウィンドウの移動に対応するために、本実施例に係るサーバ装置１０では、コピーイベントを発生させることにより、ウィンドウの移動を追従することとした。ここで、コピーイベントとは、実際のウィンドウが移動された場合にウィンドウと擬似的にみなしたコピー領域をマウスの移動軌跡にしたがって移動させることにより、ウィンドウの移動にコピー領域を追従させるイベントを指す。

すなわち、本実施例に係るサーバ装置１０では、ウィンドウの移動に追従するコピー領域の位置および大きさを特定可能な属性情報をクライアント端末２０へ送信するとともに、フレームバッファ１３上でコピー領域に描画される画像を動画化して送信する。

これによって、大量の更新矩形を発生させずに動きが激しいコピー領域の画像を圧縮してクライアント端末２０へ送信できるので、ウィンドウが移動した場合の操作レスポンスが改善される。

しかしながら、ウィンドウの移動がクライアント端末２０の画面の大部分に及ぶ場合などには、画面のうちコピー領域の一部だけ動画化してクライアント端末２０へ送信した方が全画面を動画化する場合よりもサーバ装置１０の負荷が重くなる場合がある。なぜなら、上述の高頻度変更領域を識別するには、所定の時間にわたって蓄積した更新矩形をメモリ上にマッピングする必要があるからである。特に、スマートフォンなどの小型の携帯端末の場合には、画面のサイズ自体が小さいので、全画面を動画化した方が有効である場合がある。

そこで、本実施例に係るサーバ装置１０では、フレームバッファ１３に描画した画面の更新部分をクライアント端末２０へ送信する際に、ウィンドウの移動によって画面内の更新面積や更新頻度が閾値以上になった場合には全画面を動画化して送信する。これによって、本実施例に係るサーバ装置１０では、全画面を動画化した方がサーバ装置１０の処理負荷が軽くなる場合に全画面を動画化することができる。よって、本実施例に係るサーバ装置１０によれば、ウィンドウ移動のレスポンスを向上できる。

ところで、クライアント端末２０により動画が再生された画像は、更新矩形が再生された画像と比較して劣化する。このため、サーバ装置１０は、動画の送信が終了した際に、動画の領域に対応した更新矩形を送信する場合がある。この場合、サーバ装置１０は、仮に全画面を動画化して送信すると、動画の送信が終了した際に、全画面の領域に対応した更新矩形を送信することとなる。すると、動画の送信が終了した際に、送信帯域が増加してしまう。

そこで、さらに、本実施例に係るサーバ装置１０では、ウィンドウの移動によって画面内の更新面積や更新頻度が閾値以上になった場合には全画面を動画化して送信しつつ、全画面の中で実際に変化のあった更新領域を送信する。さらに、本実施例に係るサーバ装置１０では、画面の更新開始から更新終了までの更新領域を積算しておき、動画の送信が終了した際に、積算した更新領域における更新矩形を送信する。これによって、本実施例に係るサーバ装置１０では、動画の送信が終了した際に、動画中に更新した領域に制限して更新矩形を送信することができる。よって、本実施例に係るサーバ装置１０によれば、動画の送信が終了した際の送信帯域の増加を軽減できる。

図１の説明に戻り、上記のコピーイベントを実現するコピーイベント制御部１４ｋと、全画面の動画化を実現する全画面動画化判定部１４ｍとについて説明する。このうち、コピーイベント制御部１４ｋは、コピーイベントの発生、実行および終了を制御する処理部である。

かかるコピーイベントを発生させる契機について説明する。コピーイベント制御部１４ｋは、高頻度変更領域識別部１４ｄにより識別された高頻度変更領域が所定のサイズ、例えば５０×５０ピクセル以上であるか否かを判定する。このとき、高頻度変更領域が所定のサイズ以上である場合には、コピーイベント制御部１４ｋは、特定のマウスイベントが検出されたか否か、例えばドラッグ＆ドロップが操作情報取得部１４ａにより取得されているか否かをさらに判定する。そして、特定のマウスイベントが検出された場合には、コピーイベント制御部１４ｋは、コピーイベントを発生させる。なお、ここでは、マウスイベントによりコピーイベントの発生可否を判定する場合を説明したが、タブレットやキーボードの操作からコピーイベントの発生可否を判定するようにしてもよい。

このように、一定のサイズ以上の高頻度変更領域が存在する場合には、フレームバッファ１３に動画を含むウィンドウが描画されている可能性が高まる。かかる状況でウィンドウを移動させる操作が取得された場合には、動画を含むウィンドウを移動させる操作がなされていると推定できる。よって、ＯＳから特段の情報を収集せずとも、コピーイベントを適切なタイミングで発生させることができる。

次に、コピーイベントを終了させる契機について説明する。コピーイベント制御部１４ｋは、特定のマウスイベントが検出されたか否かを判定する。そして、特定のマウスイベントが検出されなくなった場合、すなわちウィンドウの移動操作が終了された場合には、コピーイベント制御部１４ｋは、コピーイベントを終了させる。なお、ウィンドウの移動操作が終了された場合には、ドラッグ操作に含まれる左クリックが解除された旨の操作情報が後述の操作情報取得部１４ａにより取得される。また、マウスカーソルの更新矩形が所定の期間にわたって通知されなくなった場合もウィンドウの移動操作が終了されたと言える。

次に、コピーイベントで実行される処理内容について説明する。コピーイベント制御部１４ｋは、操作情報取得部１４ａによりマウスの移動量が取得された場合に、前回にコピーイベントを実行したコピー領域の位置と、今回に取得されたマウスの移動量とから今回のコピー領域の位置を算出する。なお、コピー領域の位置および大きさは、高頻度変更領域と同様に、左上の頂点の座標で位置が規定されるとともに高頻度変更領域の幅ｗおよび高さｈで大きさが規定されるものとする。

図８は、コピー領域の位置を算出する方法を説明するための図である。図８に示す「ｉ＝０」の領域は、時刻ｔ０にコピーイベントを実行したコピー領域であり、コピーイベント発生時の高頻度変更領域の属性情報、すなわち左上の座標（ｘ０、ｙ０）と高頻度変更領域の幅ｗおよび高さｈと同じである。図８に示す「ｉ＝１」の領域は、時刻ｔ１にコピーイベントを実行したコピー領域である。図８に示す「ｉ＝２」の領域は、時刻ｔ２にコピーイベントを実行したコピー領域である。

例えば、図８に示す時刻ｔ１のコピー領域の位置は、時刻ｔ０のコピー領域の座標（ｘ０、ｙ０）に時刻ｔ１に取得したマウスの移動量を加算することにより、左上の頂点の座標が（ｘ１、ｙ１）と算出される。例えば、図８に示す時刻ｔ２のコピー領域の位置は、時刻ｔ１のコピー領域の座標（ｘ１、ｙ１）に時刻ｔ２に取得したマウスの移動量を加算することにより、左上の頂点の座標が（ｘ２、ｙ２）と算出される。なお、コピー領域の幅および高さは、高頻度変更領域の幅ｗおよび高さｈが各更新カウントのコピー領域で引き継がれる。

このようにして、コピー領域の属性情報が算出された後に、コピーイベント制御部１４ｋは、コピー領域の属性情報を属性情報送信部１４ｈへ出力する。この属性情報送信部１４ｈによりコピー領域の属性情報がクライアント端末２０へ送信される。

また、コピーイベント制御部１４ｋは、コピー領域の属性情報をエンコーダ１４ｅへ出力する。そして、フレームバッファ１３に描画されたビットマップ画像のうち、コピー領域に対応する位置および大きさの画像がエンコーダ１４ｅにより順次エンコードされる。その後、第２の画像送信部１４ｇによりエンコード画像がクライアント端末２０へ送信される。

全画面動画化判定部１４ｍは、フレームバッファ１３に描画された画面全体を動画化するか否かを判定する処理部である。この全画面動画化判定部１４ｍは、コピーイベントが発生している場合に、作業用の内部メモリにマッピングされた全画面動画化判定用マップを用いて、移動面積Ａｔおよび更新頻度Ｃｔを算出する。ここで、移動面積Ａｔとは、画像のフレーム間における変更が累積して更新された面積を指す。また、更新頻度Ｃｔとは、画像のフレーム間における変更の頻度を指す。なお、コピーイベントが発生していない場合には、ウィンドウが移動しておらず、サーバ装置１０の処理負荷が重くなりにくいので、全画面の動画化の要否は判定しない。この場合には、全画面動画化判定用マップをクリアする。

図９は、ウィンドウが移動する一態様を示す図である。図９に示す符号２００は、全画面動画化判定用マップを指す。図９に示す符号２００Ａは、ウィンドウが時刻ｔ０に所在した位置を示す。図９に示す符号２００Ｂは、ウィンドウが時刻ｔ１に所在した位置を示す。図９に示す符号２００Ｃは、ウィンドウが時刻ｔ２に所在した位置を示す。図９に示す符号２００Ｄは、ウィンドウが時刻ｔ３に所在した位置を示す。

図１０Ａ〜図１０Ｃは、更新頻度と移動頻度を説明するための図である。図１０Ａ、図１０Ｂおよび図１０Ｃに示す符号２１０Ｂ、符号２１０Ｃおよび符号２１０Ｄは、全画面動画化判定用マップを示す。網掛け部分は、コピーイベントが発生してから更新矩形が１度でも検出されたメッシュを指し、全てのメッシュを足し合わせた数が移動面積Ａｔとなる。全画面動画化判定用マップ２１０Ｂ、２１０Ｃおよび２１０Ｄのメッシュ内に図示した数字は、メッシュ内の更新頻度を指し、全てのメッシュを足し合わせた数が更新頻度Ｃｔとなる。

図１０Ａの例では、図９に示したウィンドウが時刻ｔ１にあるときの全画面動画化判定用マップ２１０Ｂを表す。図１０Ａの例で言えば、全画面動画化判定部１４ｍは、網掛け部分のメッシュを足し合わせることにより移動面積Ａｔを「２２」と算出するとともに、メッシュ内の数字を足し合わせることにより更新頻度Ｃｔを「４９」と算出する。

図１０Ｂの例では、図９に示したウィンドウが時刻ｔ２にあるときの全画面動画化判定用マップ２１０Ｃを表す。図１０Ｂの例で言えば、全画面動画化判定部１４ｍは、網掛け部分のメッシュを足し合わせることにより移動面積Ａｔを「３６」と算出するとともに、メッシュ内の数字を足し合わせることにより更新頻度Ｃｔを「８２」と算出する。

図１０Ｃの例では、図９に示したウィンドウが時刻ｔ３にあるときの全画面動画化判定用マップ２１０Ｄを表す。図１０Ｃの例で言えば、全画面動画化判定部１４ｍは、網掛け部分のメッシュを足し合わせることにより移動面積Ａｔを「４２」と算出するとともに、メッシュ内の数字を足し合わせることにより更新頻度Ｃｔを「９８」と算出する。

このようにして、移動面積Ａｔおよび更新頻度Ｃｔを算出した後に、全画面動画化判定部１４ｍは、更新頻度Ｃｔが閾値Ｃ未満であるか否かを判定する。このとき、更新頻度Ｃｔが閾値Ｃ未満である場合には、全画面動画化判定部１４ｍは、移動面積Ａｔが閾値Ａ２未満であるか否かをさらに判定する。一方、更新頻度Ｃｔが閾値Ｃ以上である場合には、全画面動画化判定部１４ｍは、移動面積Ａｔが閾値Ａ１未満であるか否かをさらに判定する。

このように、更新頻度Ｃｔが閾値Ｃ未満である場合には、移動面積Ａｔと比較する閾値Ａ２とし、また、更新頻度Ｃｔが閾値Ｃ以上である場合には、閾値Ａ２よりも小さい閾値Ａ１の値に変更するのは、次のような理由である。その理由とは、動画を含むウィンドウはある程度の移動があれば全画面を動画化し、静止画であるウィンドウは多少の移動では動画化しないように判定ロジックとし、サーバ装置１０の負荷を最小化するためである。

ここで、更新頻度Ｃｔと比較する閾値Ｃは、図９に示したウィンドウに動画が含まれるか否かを判定できる値であることが好ましい。また、移動面積Ａｔと比較する閾値Ａ１は、動画が含まれるウィンドウの移動が全画面を動画化した場合におけるサーバ装置１０の処理負荷を超える値であることが好ましい。また、移動面積Ａｔと比較する閾値Ａ２は、静止画であるウィンドウの移動が全画面を動画化した場合におけるサーバ装置１０の処理負荷を超える値であることが好ましい。なお、閾値Ａ１と閾値Ａ２の関係は、Ａ１＜Ａ２であるものとする。

例えば、閾値Ｃを「５０」、閾値Ａ１を「３０」、閾値Ａ２を「５０」であると仮定する。図１０Ａの例では、更新頻度Ｃｔが「４９」であるので、更新頻度Ｃｔ＜閾値Ｃとなり、移動面積Ａｔが「２２」であるので、移動面積Ａｔ＜閾値Ａ２となる。このため、図９に示したウィンドウは時刻ｔ１の段階では動画化されない。図１０Ｂの例では、更新頻度Ｃｔが「８２」であるので、更新頻度Ｃｔ≧閾値Ｃとなり、移動面積Ａｔが「３６」であるので、移動面積Ａｔ≧閾値Ａ１となる。このため、図９に示したウィンドウは時刻ｔ２の段階で全画面を動画化すると判定する。なお、図９に示したウィンドウは時刻ｔ２の段階で全画面が動画化されるので、実際には時刻ｔ３における更新頻度Ｃｔ「９８」および移動面積Ａｔ「４２」の算出や全画面動画化の要否が判定されることはない。

そして、全画面動画化判定部１４ｍは、移動面積Ａｔが閾値Ａ１以上である場合または移動面積Ａｔが閾値Ａ２以上である場合に、全画面を動画化すると判定する。この場合に、全画面動画化判定部１４ｍは、フレームバッファ１３に描画された画面全体をエンコードの対象とするようにエンコーダ１４ｅへ指示する。そして、フレームバッファ１３に描画されたビットマップ画像全体がエンコーダ１４ｅにより順次エンコードされる。その後、第２の画像送信部１４ｇによりエンコード画像がクライアント端末２０へ送信される。なお、全画面の動画化は、特定のマウスイベントが検出されなくなった場合、すなわちウィンドウの移動が終了した場合に、元の更新矩形を送信する形態に戻す。

高頻度画面更新領域識別部１４ｎは、全画面動画化の間、全画面動画領域の中から実際に変化した更新領域を識別する処理部である。例えば、高頻度画面変化領域検出部１４ｎは、前回にコピーイベントを実行したコピー領域の位置および大きさと、今回にコピーイベントを実行したコピー領域の位置とから前回から今回までに変化した更新領域の属性情報を算出する。なお、前回から今回までに変化した更新領域は、矩形で表されるものとする。

図１１Ａ〜図１１Ｂは、更新領域の属性情報の算出を説明するための図である。図１１Ａおよび図１１Ｂに示す符号２２０Ｂおよび符号２２０Ｃは、全画面動画化判定用マップを示す。図１１Ａの網掛け部分は、時刻ｔ２にコピーイベントを実行したコピー領域と時刻ｔ３にコピーイベントを実行したコピー領域を指す。図１１Ｂの網掛け部分は、時刻ｔ２にコピーイベントを実行したコピー領域、時刻ｔ３にコピーイベントを実行したコピー領域および時刻ｔ４にコピーイベントを実行したコピー領域を指す。

図１１Ａの例では、ウィンドウが時刻ｔ３にあるときの全画面動画化判定用マップ２２０Ｂを表す。図１１Ａの例で言えば、高頻度画面更新領域識別部１４ｎは、時刻ｔ２にコピーイベントを実行したコピー領域の位置および大きさと時刻ｔ３にコピーイベントを実行したコピー領域の位置とから時刻ｔ２から時刻ｔ３までに変化した更新領域の属性情報を算出する。ここでは、時刻ｔ２のコピー領域は、左上の頂点の座標を（ｘ０、ｙ０）とし、幅をｗとし、高さをｈとする。また、時刻ｔ３のコピー領域は、左上の頂点の座標を（ｘ１、ｙ１）とする。すると、高頻度画面更新領域識別部１４ｎは、前回の時刻ｔ２から今回の時刻ｔ３までに変化した更新領域を、左上の頂点の座標を（ｘ０、ｙ１）、幅を「ｗ＋（ｘ１−ｘ０）」、高さを「ｈ＋（ｙ１−ｙ０）」として算出する。

図１１Ｂの例では、ウィンドウが時刻ｔ４にあるときの全画面動画化判定用マップ２２０Ｃを表す。図１１Ｂの例で言えば、高頻度画面更新領域識別部１４ｎは、時刻ｔ３にコピーイベントを実行したコピー領域の位置および大きさと時刻ｔ４にコピーイベントを実行したコピー領域の位置とから時刻ｔ３から時刻ｔ４までに変化した更新領域の属性情報を算出する。ここでは、時刻ｔ３のコピー領域は、左上の頂点の座標を（ｘ１、ｙ１）とする。また、時刻ｔ３のコピー領域の大きさは、時刻ｔ２のコピー領域の大きさと同じである。さらに、時刻ｔ４のコピー領域は、左上の頂点の座標を（ｘ２、ｙ２）とする。すると、高頻度画面更新領域識別部１４ｎは、前回の時刻ｔ３から今回の時刻ｔ４までに変化した更新領域を、左上の頂点の座標を（ｘ１、ｙ２）、幅を「ｗ＋（ｘ２−ｘ１）」、高さを「ｈ＋（ｙ２−ｙ１）」として算出する。

そして、高頻度画面更新領域識別部１４ｎは、全画面動画化の間、更新領域が算出される度に、その更新領域を積算して積算更新領域を算出する。ここで、全画面動画化の間とは、全画面動画化が開始される場合のコピーイベントが発生してから全画面動画化が終了される場合のコピーイベントが発生しなくなるまでをいう。例えば、高頻度画面更新領域識別部１４ｎは、全画面動画化の間、コピーイベントが発生中に、コピーイベントが発生する度に算出される更新領域を積算して積算更新領域の属性情報を算出する。なお、積算更新領域は、矩形で表されるものとする。

図１２Ａ〜図１２Ｂは、積算更新領域の属性情報の算出を説明するための図である。図１２Ａおよび図１２Ｂに示す符号２３０Ｂおよび符号２３０Ｃは、全画面動画化判定用マップを示す。図１２Ａの網掛け部分は、時刻ｔ２にコピーイベントを実行したコピー領域と時刻ｔ３にコピーイベントを実行したコピー領域を指す。図１２Ａに示す符号２３０Ｂ１は、時刻ｔ２から時刻ｔ３までの更新領域を指す。図１２Ｂの網掛け部分は、時刻ｔ２にコピーイベントを実行したコピー領域、時刻ｔ３にコピーイベントを実行したコピー領域および時刻ｔ４にコピーイベントを実行したコピー領域を指す。図１２Ｂに示す符号２３０Ｃ１は、時刻ｔ２から時刻ｔ３までの更新領域を指す。図１２Ｂに示す符号２３０Ｃ２は、時刻ｔ３から時刻ｔ４までの更新領域を指す。なお、ここでは、時刻ｔ２に全画面動画化が開始される場合のコピーイベントが発生したものとする。

図１２Ａの例では、ウィンドウが時刻ｔ３にあるときの全画面動画化判定用マップ２３０Ｂを表す。図１２Ａの例で言えば、高頻度画面更新領域識別部１４ｎは、全画面動画化が開始される場合のコピーイベントが時刻ｔ２で最初に発生したので、時刻ｔ２の次のコピーイベントが発生した時刻ｔ３で算出される更新領域２３０Ｂ１を積算更新領域とする。ここでは、積算更新領域は、時刻ｔ２から時刻ｔ３までの更新領域と一致し、左上の頂点の座標を（ｘ０、ｙ１）、幅を「ｗ＋（ｘ１−ｘ０）」、高さを「ｈ＋（ｙ１−ｙ０）」と算出される。

図１２Ｂの例では、ウィンドウが時刻ｔ２にあるときの全画面動画化判定用マップ２３０Ｂを表す。図１２Ｂの例で言えば、高頻度画面更新領域識別部１４ｎは、時刻ｔ３で算出される更新領域２３０Ｃ１と時刻ｔ４で算出される更新領域２３０Ｃ２とを積算して積算更新領域とする。ここでは、積算更新領域は、左上の頂点の座標を（ｘ０、ｙ２）、幅を「ｗ＋（ｘ２−ｘ０）」、高さを「ｈ＋（ｙ２−ｙ０）」と算出される。

画面更新通知部１４ｏは、全画面動画化の間、更新領域の属性情報を第２の画像送信部１４ｇに通知する。その後、第２の画像送信部１４ｇは、エンコーダ１４ｅにより画面全体がエンコードされた動画画像と、画面更新通知部１４ｏにより通知された更新領域の属性情報とをクライアント端末２０に送信する。

また、画面更新通知部１４ｏは、全画面動画化の終了時に、積算更新領域の更新矩形の画像および属性情報を第１の画像送信部１４ｆに通知する。例えば、画面更新通知部１４ｏは、コピーイベント制御部１４ｋからコピーイベントの終了が通知されると、全画面動画化の終了を判定し、画面生成部１４ｂにより生成された積算更新領域の更新矩形の画像および属性情報を第１の画像送信部１４ｆに通知する。その後、第１の画像送信部１４ｆは、積算更新領域の更新矩形の画像をクライアント端末２０に送信する。

なお、ＯＳ実行制御部１１ａ、アプリ実行制御部１１ｂ、グラフィックドライバ１２、サーバ側リモート画面制御部１４には、各種の集積回路や電子回路を採用できる。また、サーバ側リモート画面制御部１４に含まれる機能部の一部を別の集積回路や電子回路とすることもできる。例えば、集積回路としては、ＡＳＩＣ（Application Specific Integrated Circuit）やＦＰＧＡ（Field Programmable Gate Array）が挙げられる。また、電子回路としては、ＣＰＵ（Central Processing Unit）やＭＰＵ（Micro Processing Unit）などが挙げられる。

［クライアント端末の構成］
次に、本実施例に係るクライアント端末の構成について説明する。図１に示すように、クライアント端末２０は、入力部２１と、表示部２２と、クライアント側リモート画面制御部２３とを有する。なお、図１の例では、図１に示した機能部以外にも既知のコンピュータが有する各種の機能部、例えば音声出力部などの機能を有するものとする。

入力部２１は、各種の情報、例えば後述のクライアント側リモート画面制御部２３に対する指示入力を受け付ける入力デバイスであり、一例としては、キーボードやマウスなどを適用できる。なお、後述の表示部２２も、マウスと協働して、ポインティングデバイス機能を実現する。

表示部２２は、各種の情報、例えばサーバ装置１０から送信されたデスクトップ画面などを表示する表示デバイスであり、一例としては、モニタ、ディスプレイやタッチパネルなどを適用できる。

クライアント側リモート画面制御部２３は、クライアント側リモート画面制御用アプリを通じて、サーバ装置１０によるリモート画面制御サービスの提供を受ける処理部である。このクライアント側リモート画面制御部２３は、図１に示すように、操作情報通知部２３ａと、第１の画像受信部２３ｂと、第１の表示制御部２３ｃと、第２の画像受信部２３ｄと、デコーダ２３ｅと、第２の表示制御部２３ｆとを有する。

操作情報通知部２３ａは、入力部２１による操作情報をサーバ装置１０へ通知する処理部である。一例として、操作情報通知部２３ａは、マウスの左右のクリックを始め、ダブルクリックやドラッグ、マウスの移動操作を介して得られたマウスカーソルの位置や移動量などを操作情報として通知する。他の一例としては、操作情報通知部２３ａは、マウスホールの回転量、キーボードのうち押下されたキーの種別なども操作情報として通知する。

第１の画像受信部２３ｂは、サーバ装置１０の第１の画像送信部１４ｆにより送信された更新矩形の画像および属性情報を受信する処理部である。また、第１の画像受信部２３ｂは、サーバ装置１０の属性情報送信部１４ｈにより送信された高頻度変更領域の属性情報またはコピー領域の属性情報を受信する。

第１の表示制御部２３ｃは、第１の画像受信部２３ｂにより受信された更新矩形の画像を表示部２２に表示させる処理部である。一例としては、第１の表示制御部２３ｃは、第１の画像受信部２３ｂにより受信された更新矩形の属性情報に含まれる位置および大きさに対応する表示部２２の画面領域に更新矩形のビットマップ画像を表示させる。

他の一例としては、第１の表示制御部２３ｃは、第１の画像受信部２３ｂにより高頻度変更領域の属性情報またはコピー領域の属性情報が受信された場合には、次のような処理を行う。すなわち、第１の表示制御部２３ｃは、高頻度変更領域の属性情報またはコピー領域の属性情報に含まれる位置および大きさに対応する表示部２２の画面領域をビットマップ画像の表示対象外のブランク領域とする。

更なる一例としては、第１の表示制御部２３ｃは、第１の画像受信部２３ｂにより積算更新領域の属性情報が受信された場合には、次のような処理を行う。すなわち、第１の表示制御部２３ｃは、全画面動画化の終了時に、積算更新領域の属性情報に含まれる位置および大きさに対応する表示部２２の画面領域に、更新矩形のビットマップ画像を表示させる。

第２の画像受信部２３ｄは、サーバ装置１０の第２の画像送信部１４ｇにより送信された高頻度変更領域またはコピー領域のエンコード画像を受信する処理部である。また、第２の画像受信部２３ｄは、サーバ装置１０の第２の画像受信部１４ｇにより送信された全画面のエンコード画像および全画面の中で実際に変化のあった更新領域の属性情報を受信する。

デコーダ２３ｅは、第２の画像受信部２３ｄにより受信された高頻度変更領域、コピー領域または全画面のエンコード画像をデコードする処理部である。なお、デコード２３ｅ
には、サーバ装置１０に搭載されるエンコード方式に適合するデコード方式のデコーダが搭載される。

第２の表示制御部２３ｆは、デコーダ２３ｅによりデコードされたデコード画像をそのまま表示部２２に表示させる処理部である。

一例としては、デコーダ２３ｅから入力されるデコード画像が高頻度変更領域のデコード画像である場合には、第２の表示制御部２３ｆは、第１の表示制御部２３ｃによりブランク領域とされた表示部２２の画面領域にデコード画像を表示させる。

他の一例としては、デコード２３ｅにより入力されるデコード画像がコピー領域のデコード画像である場合には、第２の表示制御部２３ｆは、第１の表示制御部２３ｃによりブランク領域とされた表示部２２の画面領域にデコード画像を表示させる。

更なる一例としては、デコーダ２３ｅにより入力されるデコード画像が全画面のデコード画像である場合には、第２の表示制御部２３ｆは、全画面のデコード画像を表示部２２に表示させる。

第３の表示制御部２３ｇは、デコーダ２３ｅによりデコードされたデコード画像を属性情報に合わせて表示部２２に表示させる処理部である。一例としては、デコーダ２３ｅから入力されるデコード画像が属性情報の大きさと一致しない場合には、第３の表示制御部２３ｇは、全画面動画化中であると判定する。そして、第３の表示制御部２３ｇは、全画面のデコード画像から、実際に変化のあった更新領域に係る属性情報の位置および大きさに対応する部分のデコード画像を切り出したうえで、当該デコード画像を表示部２２に表示させる。

[処理の流れ]
次に、本実施例に係るシンクライアントシステムの処理の流れについて説明する。図１３および図１４は、実施例に係る画像送信処理の手順を示すフローチャートである。この画像送信処理は、サーバ装置１０により実行される処理であり、フレームバッファ１３にビットマップデータが描画された場合に起動する。

図１３に示すように、フレームバッファ１３にビットマップデータが描画されると、画面生成部１４ｂは、前回のフレームから変更があった部分の画素をつなげ合わせたうえで矩形に整形した更新矩形の画像を生成する（ステップＳ１０１）。そして、画面生成部１４ｂは、先に生成した更新矩形の画像から更新矩形送信用のパケットを生成する（ステップＳ１０２）。

続いて、変更頻度判別部１４ｃは、画面生成部１４ｂにより生成された更新矩形を図示しない作業用の内部メモリへ蓄積する（ステップＳ１０３）。なお、コピー領域の更新矩形は、高頻度変更領域の識別に関する処理量を削減するために、作業用の内部メモリには蓄積されない。

そして、コピーイベント中の領域に含まれる更新矩形ではない場合（ステップＳ１０４否定）には、変更頻度判別部１４ｃは、更新矩形の蓄積を開始してから所定の期間が経過したか否かを判定する（ステップＳ１０５）。

このとき、更新矩形の蓄積を開始してから所定の期間が経過していない場合（ステップＳ１０５否定）には、以降に続く高頻度変更領域の識別に関する処理をとばし、後述のステップＳ１１６へ移行する。

一方、更新矩形の蓄積を開始してから所定の期間が経過した場合（ステップＳ１０５肯定）には、変更頻度判別部１４ｃは、次のような処理を行う。すなわち、変更頻度判別部１４ｃは、作業用の内部メモリに蓄積した更新矩形の位置および大きさにしたがって更新矩形の画像を変更頻度判別用のマップに順次展開する（ステップＳ１０６）。そして、変更頻度判別部１４ｃは、変更頻度判別用のマップに含まれるメッシュのうち変更頻度が閾値を超えるメッシュを取得する（ステップＳ１０７）。

その後、高頻度変更領域識別部１４ｄは、変更頻度判別部１４ｃにより変更頻度が閾値を超えるメッシュが取得されたか否かを判定する（ステップＳ１０８）。このとき、変更頻度が閾値を超えるメッシュが存在しない場合（ステップＳ１０８否定）には、高頻度変更領域がデスクトップ画面に存在しないので、以降に続く高頻度変更領域の識別に関する処理をとばし、ステップＳ１１３へ移行する。

一方、変更頻度が閾値を越えるメッシュが存在する場合（ステップＳ１０８肯定）には、高頻度変更領域識別部１４ｄは、隣接するメッシュ同士を連結したメッシュ連結体を矩形に補正する（ステップＳ１０９）。

そして、高頻度変更領域識別部１４ｄは、補正後の矩形、すなわち高頻度変更領域の候補が複数存在するか否かを判定する（ステップＳ１１０）。このとき、補正後の矩形、すなわち高頻度変更領域の候補が複数存在する場合（ステップＳ１１０肯定）には、高頻度変更領域識別部１４ｄは、次のような処理を行う。すなわち、高頻度変更領域識別部１４ｄは、複数の高頻度変更領域の候補の距離が所定の値以下である高頻度変更領域の候補同士を含む矩形に合成する（ステップＳ１１１）。なお、高頻度変更領域の候補が複数存在しない場合（ステップＳ１１０否定）には、矩形の合成を行わずにステップＳ１１２へ移行する。

続いて、高頻度変更領域識別部１４ｄは、高頻度変更領域の位置および大きさを特定可能な属性情報をクライアント端末２０へ送信する（ステップＳ１１２）。そして、高頻度変更領域識別部１４ｄは、作業用の内部メモリにマッピングされたメッシュの変更回数を全画面動画化判定用マップに加算したうえでクリアする（ステップＳ１１３）。

そして、コピーイベント制御部１４ｋによるコピーイベントが発生していない場合（ステップＳ１１４否定）には、全画面動画化判定部１４ｍは、全画面動画化判定用マップをクリアする（ステップＳ１１５）。

その後、高頻度変更領域識別部１４ｄは、画面生成部１４ｂにより生成された更新矩形が作業用の内部メモリに記憶された高頻度変更領域、すなわち第２の画像送信部１４ｇにより動画を送信中の領域に含まれるか否かを判定する（ステップＳ１１６）。

このとき、更新矩形が高頻度変更領域に含まれない場合（ステップＳ１１６否定）には、第１の画像送信部１４ｆは、更新矩形の画像および属性情報をクライアント端末２０へ送信し（ステップＳ１１７）、処理を終了する。

一方、更新矩形が高頻度変更領域に含まれる場合（ステップＳ１１６肯定）には、コピーイベント制御部１４ｋは、高頻度変更領域が所定のサイズ以上であるか否かを判定する（ステップＳ１１８）。なお、高頻度変更領域が所定のサイズ未満である場合（ステップＳ１１８否定）には、コピーイベントを発生させずにステップＳ１２１へ移行する。

このとき、高頻度変更領域が所定のサイズ以上である場合（ステップＳ１１８肯定）には、コピーイベント制御部１４ｋは、特定のマウスイベントが検出されたか否かをさらに判定する（ステップＳ１１９）。なお、特定のマウスイベントが検出されなかった場合（ステップＳ１１９否定）には、コピーイベントを発生させずにステップＳ１２１へ移行する。

そして、特定のマウスイベントが検出された場合（ステップＳ１１９肯定）には、コピーイベント制御部１４ｋは、コピーイベントを発生する（ステップＳ１２０）。そして、高頻度変更領域識別部１４ｄは、フレームバッファ１３に描画されたビットマップデータのうち高頻度変更領域に対応する部分のビットマップ画像を切り出したうえでエンコーダ１４ｅにエンコードさせる（ステップＳ１２１）。そして、エンコーダ１４ｅによりエンコードされた高頻度変更領域のエンコード画像をクライアント端末２０へ送信し（ステップＳ１２２）、処理を終了する。

先のステップＳ１０４の判定に戻り、コピーイベント中の領域に含まれる更新矩形である場合（ステップＳ１０４肯定）には、コピーイベント制御部１４ｋは、特定のマウスイベントが検出されたか否かを判定する（ステップＳ１２３）。

このとき、特定のマウスイベントが検出されなかった場合（ステップＳ１２３否定）には、コピーイベント制御部１４ｋは、コピーイベントを終了し（ステップＳ１２４）、ステップＳ１０５へ移行する。

一方、特定のマウスイベントが検出された場合（ステップＳ１２３肯定）には、コピーイベント制御部１４ｋは、次の処理を行う。すなわち、コピーイベント制御部１４ｋは、今回にコピーイベントが実行されるよりも１つ前のコピー領域の位置と、今回に取得したマウスの移動量とから今回にコピーイベントを実行するコピー領域の位置を算出する（ステップＳ１２５）。

続いて、属性情報送信部１４ｈは、コピー領域の属性情報をクライアント端末２０へ送信する（ステップＳ１２６）。そして、第２の画像送信部１４ｇは、エンコーダ１４ｅによりコピー領域がエンコーダされたエンコーダ画像をクライアント端末２０へ送信し（ステップＳ１２７）、処理を終了する。

先のステップＳ１１４の判定に戻り、コピーイベントが発生している場合（ステップＳ１１４肯定）に、全画面動画化判定部１４ｍは、全画面動画化判定用マップを用いて、移動面積Ａｔおよび更新頻度Ｃｔを算出する（ステップＳ１２８）。そして、全画面動画化判定部１４ｍは、更新頻度Ｃｔが閾値Ｃ未満であるか否かを判定する（ステップＳ１２９）。

一方、更新頻度Ｃｔが閾値Ｃ以上である場合（ステップＳ１２９否定）には、全画面動画化判定部１４ｍは、移動面積Ａｔが閾値Ａ１未満であるか否かをさらに判定する（ステップＳ１３０）。なお、移動面積Ａｔが閾値Ａ１未満である場合（ステップＳ１３０肯定）には、ステップＳ１１６へ移行する。

このとき、更新頻度Ｃｔが閾値Ｃ未満である場合（ステップＳ１２９肯定）には、全画面動画化判定部１４ｍは、移動面積Ａｔが閾値Ａ２未満であるか否かをさらに判定する（ステップＳ１３１）。なお、移動面積Ａｔが閾値Ａ２未満である場合（ステップＳ１３１肯定）には、ステップＳ１１６へ移行する。

ここで、移動面積Ａｔが閾値Ａ１以上である場合または移動面積Ａｔが閾値Ａ２以上である場合（ステップＳ１３０否定またはステップＳ１３１否定）には、次のような処理を行う。すなわち、全画面動画化判定部１４ｍは、全画面動画化をすべく、フレームバッファ１３に描画された画面全体をエンコードの対象とするようにエンコーダ１４ｅへ指示する（ステップＳ１３２）。

このとき、高頻度画面更新領域識別部１４ｎは、前回にコピーイベントを実行したコピー領域の属性情報と、今回にコピーイベントを実行したコピー領域の位置とから前回から今回までに変化した更新領域の属性情報を算出する（ステップＳ１３３）。

さらに、高頻度画面更新領域識別部１４ｎは、算出した今回の更新領域と前回までの更新領域とを積算して積算更新領域の属性情報を算出する（ステップＳ１３４）。そして、第２の画像送信部１４ｇは、エンコーダ１４ｅにより画面全体がエンコードされた動画画像と、画面更新通知部１４ｏにより通知された更新領域の属性情報とをクライアント端末２０に送信する（ステップＳ１３５）。

その後、コピーイベント制御部１４ｋは、特定のマウスイベントが検出されなかったか否かを判定することによって、マウスイベントの終了の可否を判定する（ステップＳ１３６）。そして、マウスイベントが終了しないと判定された場合（ステップＳ１３６否定）には、全画面動画化の処理を繰り返すべく、ステップＳ１３２に移行する。

一方、マウスイベントが終了すると判定された場合（ステップＳ１３６肯定）には、
第１の画像送信部１４ｆは、フレームバッファ１３に描画された積算更新領域の更新矩形の画像をクライアント端末２０に送信する（ステップ１３７）。これにより、ステップＳ１３２〜ステップＳ１３７の全画面の動画化処理は、元の更新矩形を送信する形態に戻すために処理を終了する。

なお、上記のステップＳ１０５〜ステップＳ１１３までの高頻度更新領域の識別に関する処理は、図１３および図１４に示したフローとは別処理として動作させることもできる。この場合には、更新矩形の蓄積を開始してから所定の期間が経過する度に処理が起動することになる。

また、上記のステップＳ１１６〜ステップＳ１１７の処理は、図１３および図１４に示したフローとは別処理として動作させることもできる。この場合には、画面生成部１４ｂにより更新矩形が生成される度に処理が起動することになる。

また、上記のステップＳ１２３〜ステップＳ１２４の処理は、図１３および図１４に示したフローとは別処理として動作させることもできる。この場合には、フレームバッファ１３にビットマップデータが描画される度に作業用の内部メモリに高頻度変更領域の属性情報が登録されているか否かが判定される。このとき、高頻度変更領域の属性情報が登録されている場合に処理が起動することになる。

図１５は、実施例に係る画像表示処理の手順を示すフローチャートである。この画像表示処理は、クライアント端末２０により実行される処理である。

図１５に示すように、操作情報通知部２３ａは、マウス操作があったか否かを判定する（ステップＳ１４１）。このとき、マウス操作がなかった場合（ステップＳ１４１否定）には、マウス操作があるまで、ステップＳ１４１へ移行する。一方、マウス操作があった場合（ステップＳ１４１肯定）には、操作情報通知部２３ａは、マウスの操作情報をサーバ装置１０に送信する（ステップＳ１４２）。

そして、第１の画像受信部２３ｂおよび第２の画像受信部２３ｄは、サーバ装置１０からのデータがあるか否かを判定する（ステップＳ１４３）。このとき、サーバ装置１０からのデータがない場合（ステップＳ１４３否定）には、第１の画像受信部２３ｂおよび第２の画像受信部２３ｄは、サーバ装置１０からデータがあると判定するまで、ステップＳ１４１へ移行する。

一方、サーバ装置１０からのデータがある場合（ステップＳ１４３肯定）であって全画面動画化でない場合（ステップＳ１４４否定）には、第１の画像受信部２３ｂおよび／または第２の画像受信部２３ｄは、それぞれ画像データと属性情報を受信する（ステップＳ１４５）。すなわち、第２の画像受信部２３ｄは、高頻度変更領域またはコピー領域の動画（エンコード）データと属性情報とを受信する。また、第１の画像受信部２３ｂは、静止画（更新矩形）データを受信する。

第２の画像受信部２３ｄにより動画データが受信された場合には、第２の表示制御部２３ｆは、デコーダ２３ｅによりデコードされた動画を表示部２２に表示する。また、第１の画像受信部２３ｄにより静止画データが受信された場合には、第１の表示制御部２３ｃは、第１の画像受信部２３ｂにより受信された静止画データを表示部２２に表示する（ステップＳ１４６）。

先のステップＳ１４４の判定に戻り、全画面動画化である場合（ステップＳ１４４肯定）には、全画面動画化が終了するまで（ステップＳ１４７否定）、第２の画像受信部２３ｄが、全画面の動画データと更新領域の属性情報を受信する（ステップＳ１４８）。

そして、第３の表示制御部２３ｇは、デコーダ２３ｅによりデコードされた全画面の動画から、更新領域の属性情報に対応する部分の動画を切り出したうえで、表示部２２に表示する（ステップＳ１４９）。

その後、全画面動画化が終了した場合（ステップＳ１４７肯定）には、第１の画像受信部２３ｂは、積算更新領域の静止画（更新矩形）データを受信する（ステップＳ１５０）。そして、第１の表示制御部２３ｃは、第１の画像受信部２３ｂにより受信された積算更新領域の静止画データを表示部２２に表示する（ステップＳ１５１）。

［実施例の効果］
上述してきたように、本実施例に係るサーバ装置１０では、ウィンドウの移動によって画面内の更新面積や更新頻度が閾値以上になった場合には、全画面を動画化した動画画像と、実際に変化のあった更新領域とをクライアント端末２０へ送信する。さらに、本実施例に係るサーバ装置１０では、全画面動画化中の更新領域を積算して積算更新領域を算出しておき、全画面動画化の終了時に、積算更新領域における更新矩形をクライアント端末２０へ送信する。これによって、本実施例に係るサーバ装置１０では、全画面動画化の終了時に、全画面動画化中に変化のあった領域に制限して更新矩形を送信できるので、全画面領域の更新矩形を送信する場合と比較して、送信帯域の増加を軽減できる。

［適用範囲］
なお、上記の実施例では、更新頻度および移動面積に関する条件を満たした場合に全画面を動画化することとしたが、これ以外の条件であってもよい。例えば、画面内の変更の頻度が閾値を超えた領域、すなわち高頻度変更領域の面積が閾値以上になった場合に、全画面を動画化するようにしてもよい。この場合には、例えば、全画面動画化判定部１４ｍは、コピーイベントが発生していない場合であっても、作業用の内部メモリにマッピングされた全画面動画化判定用マップを用いて、高頻度変更領域の面積Ｂｔを算出する。そして、全画面動画化判定部１４ｍは、算出した高頻度変更領域の面積Ｂｔが閾値Ａ３以上であるか否かを判定する。ここで、閾値Ａ３は、動画が含まれる領域を動画化した場合におけるサーバ装置１０の処理負荷が全画面を動画化した場合におけるサーバ装置１０の処理負荷を超える値であることが好ましい。

また、全画面動画化判定部１４ｍは、算出した高頻度変更領域の面積Ｂｔが閾値Ａ３以上である場合に、全画面を動画化すると判定する。そして、高頻度画面更新領域識別部１４ｎは、全画面動画化の間、画面生成部１４ｂにより更新矩形が生成される度に更新矩形を更新領域として、更新領域の属性情報を算出する。さらに、高頻度画面更新領域識別部１４ｎは、更新領域が算出される度に、その更新領域を積算して積算更新領域を算出する。なお、積算更新領域は、矩形で表されるものとする。

画面更新通知部１４ｏは、全画面動画化の間、更新領域の属性情報を第２の画像送信部１４ｇに通知する。その後、第２の画像送信部１４ｇは、エンコーダ１４ｅにより画面全体がエンコードされた動画画像と、画面更新通知部１４ｏにより通知された更新領域の属性情報とをクライアント端末２０に送信する。

また、画面更新通知部１４ｏは、全画面動画化の終了時に、積算更新領域の更新矩形の画像および属性情報を第１の画像送信部１４ｆに通知する。例えば、画面更新通知部１４ｏは、高頻度変更領域内の更新頻度が所定量以下であるか否かを判定する。ここで、所定量は、高頻度変更領域内に動画が含まれるか否かを判定できる値であることが好ましい。そして、画面更新通知部１４ｏは、高頻度変更領域内の更新頻度が所定量以下である場合に、全画面動画化の終了を判定し、画面生成部１４ｂにより生成された積算更新領域の更新矩形の画像および属性情報を第１の画像送信部１４ｆに通知する。その後、第１の画像送信部１４ｆは、積算更新領域の更新矩形の画像をクライアント端末２０に送信する。

ここで、コピーイベントが発生していない場合であっても、全画面を動画化する画像送信処理について、図１６を参照して説明する。図１６は、実施例に係る画像送信処理の変形例の手順を示すフローチャートである。なお、図１６は、図１４に示す画像送信処理内におけるＳ１１４のコピーイベント中でない場合の処理のみを抜粋している。それ以外の処理は、図１３および図１４で説明した処理と同様であるので、その説明を省略する。また、図１４に示す画像送信処理と同一処理については同一符号を示すものとする。

コピーイベント制御部１４ｋによるコピーイベントが発生していない場合（ステップＳ１１４否定）には、全画面動画化判定部１４ｍは、高頻度変更領域の面積Ｂｔが閾値Ａ３以上であるか否かを判定する（ステップＳ１６１）。ここで、高頻度変更領域の面積Ｂｔが閾値Ａ３以上である場合（ステップＳ１６１肯定）には、次のような処理を行う。すなわち、全画面動画化判定部１４ｍは、全画面動画化をすべく、フレームバッファ１３に描画された画面全体をエンコードの対象とするようにエンコーダ１４ｅへ指示する（ステップＳ１３２）。

このとき、高頻度画面更新領域識別部１４ｎは、画面生成部１４ｂにより生成された更新矩形の領域を更新領域として、更新領域の属性情報を算出する（ステップＳ１６２）。さらに、高頻度画面更新領域識別部１４ｎは、算出した今回の更新領域と前回までの更新領域とを積算して積算更新領域の属性情報を算出する（ステップＳ１６３）。

そして、第２の画像送信部１４ｇは、エンコーダ１４ｅにより画面全体がエンコードされた動画画像と、画面更新通知部１４ｏにより通知された更新領域の属性情報とをクライアント端末２０に送信する（ステップＳ１３５）。

その後、画面更新通知部１４ｏは、高頻度変更領域内の更新頻度が所定量以下であるか否かを判定する（ステップＳ１６４）。そして、高頻度変更領域内の更新頻度が所定量より大きいと判定された場合（ステップＳ１６４否定）には、全画面動画化の処理を繰り返すべく、ステップＳ１３２に移行する。

一方、高頻度変更領域内の更新頻度が所定量以下であると判定された場合（ステップＳ６１肯定）には、第１の画像送信部１４ｆは、フレームバッファ１３に描画された積算更新領域の更新矩形の画像をクライアント端末２０に送信する（ステップ１３７）。これにより、ステップＳ１３２〜ステップＳ１３７の全画面の動画化処理は、元の更新矩形を送信する形態に戻すために処理を終了する。

［その他］
また、上記実施例では、所定の条件を満たした場合に全画面を動画化することとしたが動画化をする範囲を全画面に限定せず、積算更新領域の範囲より大きい範囲であればよい。これによって、積算更新領域より大きい範囲における動画化終了時に、積算更新領域に制限して更新矩形を送信するので、動画化をした範囲の更新矩形を送信する場合と比較して、送信帯域の増加を軽減できる。

また、図示した各装置の各構成要素は、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散・統合の具体的形態は図示のものに限られず、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。

例えば、サーバ装置１０の第１の画像送信部１４ｆおよび第２の画像送信部１４ｇが実行する画像の送信処理を１つの画像送信部に統合することとしてもよい。また、クライアント端末２０の第１の画像受信部２３ｂおよび第２の画像受信部２３ｄが実行する画像の受信処理を１つの画像受信部に統合することとしてもかまわない。さらに、クライアント端末２０の第１の表示制御部２３ｃおよび第２の表示制御部２３ｆが実行する表示制御処理を１つの表示制御部に統合することとしてもよい。

また、サーバ装置１０が有する操作情報取得部１４ａ、画面生成部１４ｂ、変更頻度判別部１４ｃ、高頻度変更領域識別部１４ｄ、エンコーダ１４ｅまたは第１の画像送信部１４ｆは次のように構成できる。さらに、サーバ装置１０が有する第２の画像送信部１４ｇ、属性情報送信部１４ｈ、コピーイベント制御部１４ｋまたは全画面動画化判定部１４ｍ、高頻度画面更新領域識別部１４ｎまたは画面更新通知部１４ｏは次のように構成できる。一例としては、これらの機能部をサーバ装置１０の外部装置としてネットワーク経由で接続するようにしてもよい。他の一例としては、これらの機能部を別の装置がそれぞれ有し、ネットワーク接続されて協働することで、上記のサーバ装置１０の機能を実現するようにしてもよい。

［画像送信プログラム］
また、上記の実施例で説明した各種の処理は、予め用意されたプログラムをパーソナルコンピュータやワークステーションなどのコンピュータで実行することによって実現することができる。そこで、以下では、図１７を用いて、上記の実施例と同様の機能を有する画像送信プログラムを実行するコンピュータの一例について説明する。図１７は、実施例に係る画像送信プログラムを実行するコンピュータの一例について説明するための図である。また、ここでは、サーバ装置１０と同様の機能を有する画像送信プログラムを実行するコンピュータの例を説明するが、クライアント端末２０と同様の機能を有する画像表示プログラムを実行する場合も同様である。

図１７に示すように、実施例におけるコンピュータ１００は、操作部１１０ａと、マイク１１０ｂと、スピーカ１１０ｃと、ディスプレイ１２０と、通信部１３０とを有する。さらに、このコンピュータ１００は、ＣＰＵ１５０と、ＲＯＭ１６０と、ＨＤＤ（Hard Disk Drive）１７０と、ＲＡＭ（Random Access Memory）１８０とを有する。これら１１０〜１８０の各部はバス１４０を介して接続される。

ＲＯＭ１６０には、上記の実施例で示した操作情報取得部１４ａと、画面生成部１４ｂと、変更頻度判別部１４ｃと、高頻度変更領域識別部１４ｄと、第１の画像送信部１４ｆと同様の機能を発揮する制御プログラムが予め記憶される。さらに、ＲＯＭ１６０には、第２の画像送信部１４ｇと、属性情報送信部１４ｈと、コピーイベント制御部１４ｋと、全画面動画化判定部１４ｍと、高頻度画面更新領域識別部１４ｎと、画面更新通知部１４ｏと同様の機能を発揮する制御プログラムが予め記憶される。つまり、ＲＯＭ１６０には、図１６に示すように、操作情報取得プログラム１６０ａと、画面生成プログラム１６０ｂと、変更頻度判別プログラム１６０ｃと、高頻度変更領域識別プログラム１６０ｄとが記憶される。さらに、ＲＯＭ１６０には、第１の画像送信プログラム１６０ｅと、第２の画像送信プログラム１６０ｆと、属性情報送信プログラム１６０ｇと、コピーイベント制御プログラム１６０ｈとが記憶される。さらに、ＲＯＭ１６０には、全画面動画化判定プログラム１６０ｋと、高頻度画面更新領域識別プログラム１６０ｌと、画面更新通知プログラム１６０ｍとが記憶される。これらプログラム１６０ａ〜１６０ｍについては、図１に示したサーバ装置１０の各構成要素と同様、適宜統合または分離してもよい。なお、ＲＯＭ１６０に格納される各データは、常に全てのデータがＲＯＭ１６０に格納される必要はなく、処理に必要なデータのみがＲＯＭ１６０に格納されればよい。

そして、ＣＰＵ１５０が、これらプログラム１６０ａ〜１６０ｍをＲＯＭ１６０から読み出して実行する。これにより、ＣＰＵ１５０は、図１７に示すように、各プログラム１６０ａ〜１６０ｍについては、操作情報取得プロセス１５０ａと、画面生成プロセス１５０ｂと、変更頻度判別プロセス１５０ｃとして機能するようになる。さらに、ＣＰＵ１５０は、各プログラム１６０ａ〜１６０ｍについては、高頻度変更領域識別プロセス１５０ｄと、第１の画像送信プロセス１５０ｅと、第２の画像送信プロセス１５０ｆと、属性情報送信プロセス１５０ｇとして機能するようになる。さらに、ＣＰＵ１５０は、各プログラム１６０ａ〜１６０ｍについては、コピーイベント制御プロセス１５０ｈと、全画面動画化判定プロセス１５０ｋと、高頻度画面更新領域識別プロセス１５０ｌと、画面更新通知プロセス１５０ｍとして機能するようになる。これらプロセス１５０ａ〜１５０ｍは、図１に示したサーバ装置の各部に対応する。そして、ＣＰＵ１５０は、ＲＡＭ１８０を用いて、画像送信プログラムを実行する。なお、ＣＰＵ１５０上で仮想的に実現される各処理部は、常に全ての処理部がＣＰＵ１５０上で動作する必要はなく、処理に必要な処理部のみが仮想的に実現されればよい。

なお、上記した画像送信プログラムについては、必ずしも最初からＨＤＤ１７０やＲＯＭ１６０に記憶させておく必要はない。例えば、コンピュータ１００に挿入されるフレキシブルディスク、いわゆるＦＤ、ＣＤ−ＲＯＭ、ＤＶＤディスク、光磁気ディスク、ＩＣカードなどの「可搬用の物理媒体」に各プログラムを記憶させる。そして、コンピュータ１００がこれらの可搬用の物理媒体から各プログラムを取得して実行するようにしてもよい。また、公衆回線、インターネット、ＬＡＮ、ＷＡＮなどを介してコンピュータ１００に接続される他のコンピュータまたはサーバ装置などに各プログラムを記憶させておき、コンピュータ１００がこれらから各プログラムを取得して実行するようにしてもよい。

１ シンクライアントシステム
１０ サーバ装置
１１ａ ＯＳ実行制御部
１１ｂ アプリ実行制御部
１２ グラフィックドライバ
１３ フレームバッファ
１４ サーバ側リモート画面制御部
１４ａ 操作情報取得部
１４ｂ 画面生成部
１４ｃ 変更頻度判別部
１４ｄ 高頻度変更領域識別部
１４ｅ エンコーダ
１４ｆ 第１の画像送信部
１４ｇ 第２の画像送信部
１４ｈ 属性情報送信部
１４ｋ コピーイベント制御部
１４ｍ 全画面動画化判定部
１４ｎ 高頻度画面更新領域識別部
１４ｏ 画面更新通知部
２０ クライアント端末
２１ 入力部
２２ 表示部
２３ クライアント側リモート画面制御部
２３ａ 操作情報通知部
２３ｂ 第１の画像受信部
２３ｃ 第１の表示制御部
２３ｄ 第２の画像受信部
２３ｅ デコーダ
２３ｆ 第２の表示制御部
２３ｇ 第３の表示制御部

Claims (3)

1. ネットワーク経由で接続された端末装置へ画像を送信する情報処理装置であって、
   前記画像を保持する画像メモリと、
   前記画像メモリの画像を期間毎に圧縮する第１の圧縮部と、
   前記画像メモリで保持した画像から前記第１の圧縮部を用いて圧縮する動画領域を検出する動画領域検出部と、
   前記第１の圧縮部よりも画像劣化が低くなるように、前記画像メモリの画像を圧縮する第２の圧縮部と、
   前記第１の圧縮部で圧縮された領域の中から変化した変化領域を検出する変化領域検出部と、
   前記変化領域を積算して積算変化領域を算出する算出部と、
   前記動画領域検出部で検出した動画領域を前記第１の圧縮部で圧縮した動画画像と、前記変化領域検出部で検出した変化領域とを前記端末装置へ送信し、前記動画画像の送信終了時に、前記算出部で算出した積算変化領域における前記第２の圧縮部で圧縮した画像を送信する送信部と
   を有することを特徴とする情報処理装置。
2. ネットワーク経由で接続された端末装置の表示部にコンピュータの実行結果を表示するための画像を生成して前記端末装置へ送信する情報処理装置に用いる画像送信プログラムであって、
   前記情報処理装置に、
   前記画像を保持する画像メモリで保持した画像から、前記画像メモリの画像を期間毎に圧縮する第１の圧縮部を用いて圧縮する動画領域を検出し、
   前記第１の圧縮部で圧縮された領域の中から変化した変化領域を検出し、
   前記変化領域を積算して積算変化領域を算出し、
   該検出した動画領域を前記第１の圧縮部で圧縮した動画画像と、該検出した変化領域とを前記端末装置へ送信し、前記動画画像の送信終了時に、前記第１の圧縮部よりも画像劣化が低くなるように前記画像メモリの画像を圧縮する第２の圧縮部で圧縮した、該算出した積算変化領域における画像を送信する
   処理を実行させることを特徴とする画像送信プログラム。
3. ネットワーク経由で接続された端末装置の表示部にコンピュータの実行結果を表示するための画像を生成してネットワークへ送信する情報処理装置と、前記情報処理装置から前記ネットワークを経由して受信した画像を表示する端末装置とを有する画像表示システムに用いる画像表示方法であって、
   前記情報処理装置が、
   前記画像を保持する画像メモリで保持した画像から、前記画像メモリの画像を期間毎に圧縮する第１の圧縮部を用いて圧縮する動画領域を検出し、
   前記第１の圧縮部で圧縮された領域の中から変化した変化領域を検出し、
   前記変化領域を積算して積算変化領域を算出し、
   該検出した動画領域を前記第１の圧縮部で圧縮した動画画像と、該検出した変化領域とを前記端末装置へ送信し、前記動画画像の送信終了時に、前記第１の圧縮部よりも画像劣化が低くなるように前記画像メモリの画像を圧縮する第２の圧縮部で圧縮した、該算出した積算変化領域における画像を送信し、
   前記端末装置が、
   該送信された前記第１の圧縮部で圧縮した動画画像と前記変化領域とを受信すると、受信した動画画像の中の、前記変化領域に対応する部分の画像を表示し、
   前記動画画像の送信終了時に、該送信された前記積算変化領域における前記第２の圧縮部で圧縮した画像を受信すると、受信した画像を表示する
   ことを特徴とする画像表示方法。

Images