JP2013130968A - 情報処理装置、情報処理方法及びプログラム - Google Patents

Abstract

【課題】シンクライアントの操作レスポンスを損なわずに、サーバ側の処理負荷を軽減し、データ転送量を削減すること。
【解決手段】ネットワークを介して接続された端末に、端末で表示される画像を生成して、画像に関するデータを送信する情報処理装置であって、端末から送信される操作コマンドに基づいて変更される画像に対して、画像内の領域で、所定時間内に第１閾値以上の変更があれば領域を動画化対象の領域に設定する動画化領域推定部と、情報処理装置及び端末間のネットワークの往復遅延に基づき、上限のデータ転送量を推定する推定部と、推定されたデータ転送量が第２閾値未満の場合、操作コマンドのうち、所定の操作コマンドを間引くフィルタ部と、所定の操作コマンドが間引かれた場合、フィルタ部の間引き量に応じて第１閾値を変更する閾値変更部と、を備える。
【選択図】図１

Description

本発明は、シンクライアントシステムで用いられる情報処理装置、情報処理方法及びプログラムに関する。

情報漏えい対策や、ＰＣ（Personal Computer）の運用管理コスト削減などで、シンクライアント（thin client）というシステム（system）が一般的に用いられている。シンクライアントシステムでは、クライアントに最低限の機能しか持たせず、サーバでアプリケーションやファイルなどのリソースを管理するようにシステムが構築される。

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

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

ところが、シンクライアントシステムで通信に用いられるプロトコル、例えばＲＤＰ（Remote Desktop Protocol）や、ＶＮＣ（Virtual Network Computing）で用いられているＲＦＢ（Remote Frame Buffer）プロトコルなどで、画像や動画などの大容量のデータを転送する場合には、クライアントで実行される操作に対するレスポンスが悪化する問題がある。なお、この問題は、シンクライアントシステムでクライアントとサーバ間で画面更新時に大容量のデータ送信が発生する場合に共通するものであり、画像や動画を扱う場合に限定して生じる問題ではない。

そこで、レスポンス悪化時に、サーバ側で遅延が生じた場合、サーバ側の現在のポインタ（又はキー入力情報）を生成し、画面データとしてクライアントへ転送することでクライアント側から遅延原因を判別する技術がある。

また、サーバのＣＰＵ（Central Processing Unit）の負荷に応じて、操作量、時間、種類の統合などのフィルタリングを行ってイベント量を減らすことで、サーバ側で大量のイベントを効率的に処理する技術がある。

また、マウスの移動コマンドが多すぎると描画処理が大量に発生し、描画負荷が増加するため、マウスの移動イベントを所定間隔で間引く技術がある。また、画像出力システムにおいて前回のレンダリング処理時間に応じて今回のプリレンダリング判定の閾値を変更する技術がある。

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

しかしながら、従来技術では、シンクライアントの操作レスポンスを損なわずに、サーバ側の処理負荷を軽減し、データ転送量を削減することができないという問題点がある。例えば、画面更新が多く発生するようなコマンドを連続して処理する場合、このコマンドを間引くことで処理負荷を軽減することがはできるが、画面の更新量が多い場合にはデータ転送量が多いため、シンクライアントの操作レスポンスが悪化してしまう。

そこで、開示の技術は、上記問題点に鑑みてなされたものであって、シンクライアントの操作レスポンスを損なわずに、サーバ側の処理負荷を軽減し、データ転送量を削減することができる情報処理装置、情報処理方法、プログラムを提供することを目的とする。

開示の一態様における情報処理装置は、ネットワークを介して接続された端末に、該端末で表示される画像を生成して、該画像に関するデータを送信する情報処理装置であって、前記端末から送信される操作コマンドに基づいて変更される前記画像に対して、該画像内の領域で、所定時間内に第１閾値以上の変更があれば前記領域を動画化対象の領域に設定する動画化領域推定部と、前記情報処理装置及び前記端末間のネットワークの往復遅延に基づき、上限のデータ転送量を推定する推定部と、前記推定されたデータ転送量が第２閾値未満の場合、前記操作コマンドのうち、所定の操作コマンドを間引くフィルタ部と、前記所定の操作コマンドが間引かれた場合、前記フィルタ部の間引き量に応じて前記第１閾値を変更する閾値変更部と、を備える。

開示の技術は、シンクライアントの操作レスポンスを損なわずに、サーバ側の処理負荷を軽減し、データ転送量を削減することができる。

実施例１に係るシンクライアントシステムに含まれる各装置の構成の一例を示すブロック図。 表示画面の分割例を説明するための図。 表示画面の変更頻度の判別例を説明するための図。 表示画面の変更頻度の判別例を説明するための図。 表示画面の変更頻度の判別例を説明するための図。 メッシュ連結体の補正例を説明するための図。 高頻度変更領域の候補の合成例を説明するための図。 高頻度変更領域の属性情報の通知例を説明するための図。 高頻度変更領域の属性情報の通知例を説明するための図。 高頻度変更領域の属性情報の通知例を説明するための図。 コマンドフィルタ処理と閾値変更処理の概要を説明するための図。 コマンドフィルタ処理と閾値変更処理の具体例を説明するための図。 実施例１におけるサーバ装置の情報処理の一例を示すフローチャート。 実施例１における帯域推定部の処理の一例を示すフローチャート。 実施例１におけるフィルタ部の処理の一例を示すフローチャート。 実施例１における閾値変更部の処理の一例を示すフローチャート。 クライアント端末の情報処理の一例を示すフローチャート。 実施例２に係るシンクライアントシステムに含まれる各装置の構成の一例を示すブロック図。 実施例２におけるフィルタリング閾値設定処理の一例を示すフローチャート。 実施例２における上限データ転送量の設定処理の一例を示すフローチャート。 情報処理装置の構成の一例を示すブロック図

以下、各実施例について、添付図面を参照しながら説明する。

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

図１に示すシンクライアントシステム（thin client system）１は、クライアント（client）端末２０が表示する画面をリモート（remote）でサーバ（server）装置１０に制御させるものである。サーバ装置１０及びクライアント端末２０は、例えば情報処理装置である。

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

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

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

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

サーバ側リモート画面制御用アプリは、基本機能として、リモート画面制御サービスを提供する機能を有する。一例としては、サーバ側リモート画面制御用アプリは、クライアント端末２０における操作情報を取得した上でその操作により要求された処理を自装置で動作するアプリケーションに実行させる。

サーバ側リモート画面制御用アプリは、アプリケーションにより実行された処理結果を表示するための画面の画像を生成した上でその画像をクライアント端末２０へ送信する。このとき、サーバ側リモート画面制御用アプリは、今回の画面生成の前にクライアント端末２０で表示させていたビットマップ（bitmap）画像との間で変更があった部分の画素（pixel）が集まった領域、すなわち更新矩形の画像を送信する。なお、以下では、一例として、更新部分の画像が矩形の画像で形成される場合を説明するが、開示の装置は更新部分の画像が矩形以外の形状で形成される場合にも適用できる。

このほか、サーバ側リモート画面制御用アプリは、フレーム（frame）間で動きが大きい部分のデータを動画向けの圧縮方式のデータに圧縮してクライアント端末２０へ送信する機能も有する。一例としては、サーバ側リモート画面制御用アプリは、アプリケーションにより実行された処理結果から生成した画面の画像を複数の領域に分割し、分割した領域ごとに変更の頻度を監視する。

このとき、サーバ側リモート画面制御用アプリは、変更の頻度が閾値を超えた領域、すなわち高頻度変更領域の属性情報をクライアント端末２０へ送信する。これとともに、サーバ側リモート画面制御用アプリは、高頻度変更領域のビットマップ画像をＭＰＥＧ−２やＭＰＥＧ−４などのＭＰＥＧ方式のデータにエンコード（encode）した上でクライアント端末２０へ送信する。

なお、ここでは、ＭＰＥＧ（Moving Picture Experts Group）方式のデータへ圧縮する場合を例示したが、これに限定されない。例えば、動画向けの圧縮方式であれば任意の圧縮符号化方式、例えばＭｏｔｉｏｎ−ＪＰＥＧ（Joint Photographic Experts Group）などを採用してもよい。

また、サーバ側リモート画面制御用アプリは、ＲＴＴ（Round Trip Time）を利用して上限データ転送量を推定し、この上限データ転送量に応じて、画面の更新が大量に発生する所定の操作コマンドを間引く。このとき、サーバ側リモート画面制御用アプリは、操作コマンドの間引き量に応じて高頻度変更領域の判定に用いる閾値を変更する。

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

クライアント端末２０には、クライアント向けのリモート画面制御用アプリケーションがインストールまたはプリインストールされる。なお、以下では、クライアント向けのリモート画面制御用のアプリケーションをクライアント側リモート画面制御用アプリと呼ぶ。

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

クライアント側リモート画面制御用アプリは、サーバ装置１０から受信した画像を所定の表示部に表示させる機能を有する。一例としては、クライアント側リモート画面制御用アプリは、サーバ装置１０から更新矩形のビットマップ画像を受信した場合には、更新矩形の画像を前回のビットマップ画像から変更のあった位置に合わせて表示する。

他の一例としては、クライアント側リモート画面制御用アプリは、サーバ装置１０から高頻度変更領域の属性情報を受信した場合には、その属性情報に含まれる位置に対応する表示画面上の領域をビットマップ画像の表示対象外のブランク（blank）領域とする。その上で、クライアント側リモート画面制御用アプリは、動画向けの圧縮方式のデータを受信した場合にそのデータをデコードした上でブランク領域に表示する。

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

ＯＳ実行制御部１１ａは、ＯＳ（Operating System）の実行を制御する処理部である。例えば、ＯＳ実行制御部１１ａは、後述の操作情報取得部１１１により取得された操作情報からアプリケーションの起動指示やアプリケーションに対するコマンドを検出する。例えば、ＯＳ実行制御部１１ａは、アプリケーションのアイコン（icon）上でダブルクリックを検出した場合に、そのアイコンに対応するアプリケーションの起動を後述のアプリ実行制御部１１ｂへ指示する。

他の例としては、起動中のアプリケーションの操作画面、例えばウィンドウ（window）上でコマンド（command）の実行を要求する操作を検出した場合に、ＯＳ実行制御部１１ａは、そのコマンドの実行をアプリ実行制御部１１ｂへ指示する。なお、以下では、アプリケーションをアプリと略記する場合がある。

アプリ実行制御部１１ｂは、ＯＳ実行制御部１１ａによる指示に基づき、アプリケーションの実行を制御する処理部である。例えば、アプリ実行制御部１１ｂは、ＯＳ実行制御部１１ａによりアプリの起動が指示された場合や起動中のアプリにコマンドの実行が指示された場合にアプリを動作させる。

アプリ実行制御部１１ｂは、アプリを実行することにより得られた処理結果の表示用イメージ（image）をフレームバッファ１３に描画する要求を、後述のグラフィックドライバ１２へ行う。このようにグラフィックドライバ１２へ描画要求を行う場合には、アプリ実行制御部１１ｂは、表示用イメージとともに表示用イメージの描画位置をグラフィックドライバ１２へ通知する。

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

グラフィックドライバ１２は、フレームバッファ１３に対する描画処理を実行する処理部である。例えば、グラフィックドライバ１２は、アプリ実行制御部１１ｂからの描画要求を受け付けた場合に、アプリの処理結果の表示用イメージをアプリにより指定されたフレームバッファ１３上の描画位置へビットマップ形式で描画する。

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

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

サーバ側リモート画面制御部１４は、サーバ側リモート画面制御用アプリを通じて、リモート画面制御サービスをクライアント端末２０へ提供する処理部である。このサーバ側リモート画面制御部１４は、図１に示すように、通信部１０１と、画像生成部１０２と、動画化領域推定部１０３と、第１のエンコーダ１０４と、第２のエンコーダ１０５と、帯域推定部１０６と、フィルタ部１０７とを有する。

通信部１０１は、クライアント端末２０とデータ通信を行う処理部である。通信部１０１は、操作情報取得部１１１と、第１の送信部１１２と、第２の送信部１１３とを有する。また、動画化領域推定部１０３は、画像生成部１０２により生成された画像内に、動画化する領域があれば動画化を行う領域として設定を行う推定部である。動画化領域推定部１０３は、変更頻度判別部１３１と、高頻度変更領域識別部１３２とを有する。

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

画像生成部１０２は、クライアント端末２０の表示部２２に表示させる画面の画像を生成する処理部である。例えば、画像生成部１０２は、グラフィックドライバ１２によりフレームバッファ１３へビットマップデータが格納される度に、次のような処理を起動する。

画像生成部１０２は、前回のフレーム生成時にクライアント端末２０で表示させていた表示画面の画像と、今回のフレーム生成時にフレームバッファ１３へ書き込まれた表示画面の画像とを比較する。そして、画像生成部１０２は、前回のフレームから変更があった部分の画素をつなぎ合わせた上で矩形に整形した更新矩形の画像を生成し、更新矩形送信用のパケットを生成する。

《基本処理》
ここで、画像内の領域に対し、動画向けの圧縮方式を用いる領域を高頻度変更領域として特定のアプリケーションに依存せずに識別する処理について説明する。この処理は、サーバ装置１０の基本処理である。

変更頻度判別部１３１は、フレームバッファ１３に描画された画像を分割した領域ごとにフレーム間の変更の頻度を判別する処理部である。例えば、変更頻度判別部１３１は、画像生成部１０２により生成された更新矩形を図示しない作業用の内部メモリへ所定の期間にわたって蓄積する。

このとき、変更頻度判別部１３１は、更新矩形の位置および大きさを特定可能な属性情報、例えば更新矩形の左上の頂点の座標と更新矩形の幅および高さとを蓄積する。更新矩形を蓄積させる所定期間は、高頻度変更領域を識別する精度と相関関係があり、期間を長くするほど高頻度変更領域の誤検出が低減される。なお、ここでは、一例として、１秒間にわたって更新矩形の画像を蓄積する場合を想定する。

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

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

ここで、変更頻度判別部１３１は、作業用の内部メモリに蓄積した更新矩形の位置および大きさにしたがって更新矩形の画像を変更頻度判別用のマップに順次展開する。そして、変更頻度判別部１３１は、更新矩形をマップに展開する度に、マップ上で更新矩形と重なり合った部分のメッシュの変更回数を累積して加算する。

このとき、変更頻度判別部１３１は、マップ上に展開された更新矩形がメッシュに含まれる画素との間で所定数にわたって重なり合った場合に、そのメッシュの変更回数を１つ加算する。なお、ここでは、更新矩形がメッシュに含まれる画素と１つでも重なり合った場合に、メッシュの変更回数を加算する場合を想定して説明を行う。

図３Ａ〜図３Ｃは、表示画面の変更頻度の判別例を説明するための図である。図３Ａ〜図３Ｃに示す符号４０Ａ、符号４０Ｂ及び符号４０Ｎは変更頻度判別用のマップを示す。図３Ａ及び図３Ｂに示す符号４１Ａ及び符号４１Ｂは更新矩形を示す。ここで、マップ４０Ａのメッシュ内に図示した数字は、更新矩形４１Ａが展開された時点におけるメッシュの変更回数を示す。

また、マップ４０Ｂのメッシュ内に図示した数字は、更新矩形４１Ｂが展開された時点におけるメッシュの変更回数を示す。さらに、マップ４０Ｎのメッシュ内に図示した数字は、作業用の内部メモリに蓄積した更新矩形が全て展開された時点におけるメッシュの変更回数を示す。なお、図３Ａ〜図３Ｃにおいて数字が図示されていないメッシュは変更回数がゼロであるものとする。

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

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

そして、変更頻度判別部１３１は、作業用の内部メモリに蓄積した更新矩形を全てマップに展開し終えた場合に、所定の期間における変更回数、すなわち変更頻度が閾値を超えるメッシュを取得する。図３Ｃの例で言えば、閾値を「４」としたとき、網掛け部分のメッシュが取得されることになる。

閾値は、その値を高く設定するほど表示画面で動画が表示されている可能性が高い部分を後述の第２のエンコーダ１０５によりエンコードできる。なお、この閾値は、サーバ側リモート画面制御用アプリの開発者が段階的に設定した値をエンドユーザに選択させたり、また、エンドユーザが値を直接設定したりすることができる。

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

高頻度変更領域識別部１３２は、所定の期間内で、変更頻度判別部１３１により変更回数が閾値（第１閾値）を超えるメッシュが取得された場合に、隣接するメッシュ同士を連結したメッシュ連結体を矩形に補正する。ここでの所定期間は、例えば５秒とする。高頻度変更領域識別部１３２は、例えばメッシュ連結体に補間する補間領域を導出した上でメッシュ連結体に補間領域を足し合わせることによりメッシュ連結体を矩形に補正する。この補間領域の導出には、メッシュの連結体が最小の補間で矩形に整形される領域を導出するアルゴリズム（algorithm）が適用される。

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

高頻度変更領域識別部１３２は、高頻度変更領域の候補が複数存在する場合には、複数の高頻度変更領域の候補の距離が所定の値以下である高頻度変更領域の候補同士を含む矩形に合成する。ここで言う高頻度変更領域の候補の距離とは、補正後の矩形の最短距離を指すものとする。

例えば、高頻度変更領域識別部１３２は、高頻度変更領域の候補を合成するにあたって各候補の間を埋める補間領域を導出した上で高頻度変更領域の候補に補間領域を足し合わせることにより、高頻度変更領域の候補同士を含む矩形に合成する。この補間領域の導出には、高頻度変更領域の候補の間が最小の補間で合成体に整形される領域を導出するアルゴリズム（algorithm）が適用される。

図５は、高頻度変更領域の候補の合成例を説明するための図である。図５に示す符号６１Ａ及び符号６１Ｂは、高頻度変更領域の候補を指す。図５に示す符号６２は補間領域を指す。図５に示す符号６３は、高頻度変更領域の候補６１Ａ及び高頻度変更領域の候補６１Ｂの合成体を指す。

図５に示すように、高頻度変更領域識別部１３２は、高頻度変更領域の候補６１Ａ及び高頻度変更領域の候補６１Ｂに補間領域６２を足し合わせることにより、高頻度変更領域の候補６１Ａ及び高頻度変更領域の候補６１Ｂを含む合成体６３へ合成する。そして、高頻度変更領域識別部１３２は、このようにして得た合成体を高頻度変更領域と識別する。

上述したようにして高頻度変更領域を識別すると、高頻度変更領域識別部１３２は、高頻度変更領域の位置および大きさを特定可能な属性情報を第１の送信部１１２及び第２の送信部１１３に出力する。

これにより、クライアント端末２０で表示される表示画面のビットマップデータのうち、高頻度変更領域に対応する部分をブランク表示させる。その後、高頻度変更領域識別部１３２は、作業用の内部メモリにマッピングされたメッシュの変更回数をクリア（clear）する。なお、高頻度変更領域識別部１３２は、高頻度変更領域の属性情報を作業用の内部メモリに登録する。

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

図６Ａに示すように、表示画面７０Ａには、ブラウザ画面７１及び動画再生画面７２が含まれる。この表示画面７０Ａから経時的な変化を追った場合には、図６Ｂに示すように、静止画であるブラウザ画面７１の更新矩形は検出されず、マウスの移動軌跡７３および動画再生領域７４に関する更新矩形が検出される。

このうち、動画の再生領域７４で変更回数が閾値を超えるメッシュ、すなわち図示の網掛け部分が高頻度変更領域識別部１３２により識別されたものとする。この場合には、高頻度変更領域識別部１３２は、図６Ｃに示す網掛け部分の高頻度変更領域の左上の頂点の座標（ｘ，ｙ）と、高頻度変更領域の幅ｗおよび高さｈとを高頻度変更領域の属性情報として第１の送信部１１２及び第２の送信部１１３に通知する。

なお、ここでは、高頻度変更領域の位置を特定する点として左上の頂点の座標を採用する場合を説明したが、他の頂点を採用することとしてもかまわない。また、高頻度変更領域の位置を特定することができる点であれば、頂点以外の任意の点、例えば重心などを採用できる。また、ここでは、画面上の左上を座標軸ＸＹの原点とする場合を説明したが、画面内および画面外の任意の点を原点とすることができる。

また、高頻度変更領域識別部１３２は、画像生成部１０２により更新矩形が生成される度に、その更新矩形が作業用の内部メモリに記憶された高頻度変更領域、すなわち後述の第２の送信部１１３により送信中の動画領域に含まれるか否かを判定する。

このとき、高頻度変更領域識別部１３２は、更新矩形が高頻度変更領域に含まれない場合には、更新矩形の画像および更新矩形の位置やサイズを含む属性情報を第１のエンコーダ１０４に出力する。一方、高頻度変更領域識別部１３２は、更新矩形が高頻度変更領域に含まれる場合には、原則として、後述の第１の送信部１１２に更新矩形の画像を送信させない。なお、更新矩形がＯＳ実行制御部１１ａにより描画されたマウスのものである場合には、マウスに関する更新矩形の画像および属性情報を例外的に送信させることとしてもよい。

また、高頻度変更領域識別部１３２は、フレームバッファ１３にビットマップデータが描画される度に、作業用の内部メモリに高頻度変更領域の属性情報が登録されているか否かを判定する。

そして、高頻度変更領域識別部１３２は、高頻度変更領域の属性情報が登録されている場合に、フレームバッファ１３に描画されたビットマップデータのうち高頻度変更領域に対応する部分のビットマップ画像を切り出した上で後述の第２のエンコーダ１０５に出力する。

第１のエンコーダ１０４は、高頻度変更領域識別部１３２から入力される更新矩形の画像を静止画の圧縮方式でエンコードする処理部である。例えば、第１のエンコーダ１０４は、各更新矩形の画像をＪＰＥＧで圧縮することによって静止画の符号化データへエンコードする。なお、ここでは、静止画の圧縮方式としてＪＰＥＧを例示したが、ＧＩＦ（Graphic Interchange Format）やＰＮＧ（Portable Network Graphics）などの他の方式を適用することもできる。

第１の送信部１１２は、第１のエンコーダ１０４によってエンコードされた更新矩形の符号化データをクライアント端末２０へ送信する処理部である。例えば、第１の送信部１１２は、更新矩形の符号化データをクライアント端末２０へ送信するにあたってフレームＩＤ及び送信時刻のタイムスタンプ等のヘッダ情報を符号化データに付加した上でクライアント端末２０に送信する。

このとき、第１の送信部１１２は、第１のエンコーダ１０４によってエンコードされた全ての更新矩形の符号化データにヘッダ情報を付加することもできるが、更新矩形の符号化データのうち少なくとも１つの符号化データにヘッダ情報を付加すればよい。ヘッダ情報には、更新矩形や高頻度変更領域の属性情報を含めてもよい。この更新矩形を送信する場合の通信プロトコルには、一例としてＶＮＣにおけるＲＦＢプロトコルが採用される。

第２のエンコーダ１０５は、高頻度変更領域識別部１３２から入力される高頻度変更領域の画像を動画の圧縮方式でエンコードする処理部である。例えば、第２のエンコーダ１０５は、高頻度変更領域の画像をＭＰＥＧで圧縮することによって動画の符号化データへエンコードする。なお、ここでは、動画の圧縮方式としてＭＰＥＧを例示したが、Ｍｏｔｉｏｎ−ＪＰＥＧなどの他の方式を適用することもできる。

第２の送信部１１３は、第２のエンコーダ１０５によってエンコードされた動画の符号化データをクライアント端末２０に送信する処理部である。例えば、第２の送信部１１３は、動画の符号化データのうち少なくともいずれか１つの符号化データにヘッダ情報を付加する。ヘッダ情報には、高頻度変更領域の属性情報を含めてもよい。この高頻度変更領域のエンコード画像を送信する場合の通信プロトコルには、一例として、ＲＴＰ（Real-time Transport Protocol）を採用できる。

これにより、サーバ装置１０は、高頻度変更領域以外の領域については変更があった部分の画像を送信し、高頻度変更領域については動画向けの圧縮を行ったデータを送信することができる。よって、クライアント端末２０へ送信するデータ量を削減し、操作レスポンスを向上させることができる。さらに、クライアント端末２０へ送信するデータ量を削減することができるので、サーバ装置１０及びクライアント端末２０間の伝送遅延を低減し、クライアント端末２０で表示される画像がコマ落ちする可能性も低減できる。

《コマンドフィルタ処理と閾値変更処理》
次に、サーバ装置１０におけるコマンドフィルタ処理（間引き処理）と閾値変更処理とについて説明する。

図７は、コマンドフィルタ処理と閾値変更処理の概要を説明するための図である。図７に示すように、コマンドフィルタ処理と閾値変更処理には大きく５つの処理が含まれる。
（Ａ）サーバ装置１０及びクライアント端末２０間のＲＴＴを検出し、ネットワークの理論的な上限のデータ転送量を推定する。以下では、このデータ転送量を上限データ転送量とも呼ぶ。
（Ｂ）クライアント端末２０側でユーザにより操作されたマウス操作のコマンドをサーバ装置１０に送信する。
（Ｃ）サーバ装置１０は、上限データ転送量を利用して所定のコマンドを間引く。
（Ｄ）サーバ装置１０は、コマンドを間引いた量に応じて動画化判定のための閾値を変更する。
（Ｅ）サーバ装置１０は、変更された閾値を用いて動画化領域を検出し、クライアント端末２０に送信する。
以下、（Ａ）〜（Ｅ）の処理について詳しく説明する。

図１の説明に戻り、帯域推定部１０６は、所定間隔でサーバ装置１０及びクライアント端末２０間のネットワークの往復遅延（ＲＴＴ）を計測し、上限データ転送量を推定する処理部である。例えば、帯域推定部１０６は、数秒間隔（例えば５秒に１回）で、サーバ装置１０からクライアント端末２０に対してＩＣＭＰ Ｅｃｈｏ Ｒｅｑｕｅｓｔとよばれるパケットを送信し、クライアント端末２０からのＩＣＭＰ Ｅｃｈｏ Ｒｅｐｌｙが受信されるのを待つ。受信後、帯域推定部１０６は、Ｒｅｑｕｅｓｔ − Ｒｅｐｌｙ間の時刻の差を算出し、これをＲＴＴとする。

転送量の上限推定には、ネットワーク通信のプロトコルとして広く普及しているＴＣＰの仕組みを応用する。ＴＣＰにはウィンドウとよばれるバッファがあり、データを受信する側はこのウィンドウのサイズ（以下ウィンドウサイズ）をクライアント側に通知することで確認応答なしに送信可能なデータ量を操作することができる。確認応答がない場合、データ送信側は確認応答を受信してウィンドウサイズが拡張されるまで、データを送信することはできない。

ウィンドウサイズは、通常６４ＫＢｙｔｅが利用されている。ＬＡＮ環境のようなＲＴＴの小さなネットワークではこのウィンドウサイズは問題にならない。しかし、ＷＡＮ環境のようなＲＴＴが大きい（例えば５０ｍｓ以上）ネットワークでは、ウィンドウサイズの制約のため１ＴＣＰコネクションあたりに送信可能なデータ転送量が制限されてしまう。例えば、ＲＴＴ５０ｍｓのネットワークの場合、５０ｍｓの間には６４ＫＢｙｔｅのデータ転送しか行えない。よって、１秒間に１コネクションあたり１２８０ＫＢｙｔｅ≒１０Ｍｂｐｓ程度しか伝送できないことがわかる。

帯域推定部１０６は、このようにＲＴＴを利用して現在のネットワークの上限データ転送量を推定する。帯域推定部１０６は、推定した上限データ転送量をフィルタ部１０７に通知する。

フィルタ部１０７は、操作情報取得部１１１から通知された操作コマンドを取得し、操作コマンドを条件に応じてフィルタリングし、ＯＳ実行制御部１１ａに通知する処理部である。例えば、フィルタ部１０７は、帯域推定部１０６で推定された現在のネットワークの上限データ転送量と、予め設定されたフィルタリング閾値（第２閾値）とを比較する。フィルタ部１０７は、もし上限データ転送量がフィルタリング閾値未満の場合には通知された操作コマンドの中から所定の操作コマンドを一定間隔で間引く処理を行う。所定の操作コマンドは、画面更新を大量に発生するようなコマンドであり、例えば、ドラッグコマンドである。

フィルタリング閾値が例えば５Ｍｂｐｓだった場合、上限データ転送量が５Ｍｂｐｓ以上であれば、全ての操作コマンドがＯＳ実行制御部１１ａへ通知される。上限データ転送量が４Ｍｂｐｓと推定された時には、フィルタ部１０７は、次の式（１）により間引き量を算出する。
間引き量＝１−（上限データ転送量／閾値） ・・・式（１）
上記例によれば、間引き量は、１−（４／５）＝１／５となる。

上記例の場合、フィルタ部１０７は、ドラッグコマンド５つに対して１つの割合で間引き処理を行い、残りのドラッグコマンドをＯＳ実行制御部１１ａに通知する。

閾値変更部１０８は、フィルタ部１０７で行われた間引きの間引き量に応じて、高頻度変更領域検出で利用される閾値（第１閾値）の変更を行う処理部である。例えば、閾値変更部１０８は、フィルタ部１０７から通知された間引き量に合わせて閾値も同じ割合で減少させる処理を行う。

フィルタ部１０７から取得した間引き量が例えば０である場合には、閾値は既定値５であるとする。閾値変更部１０８は、次の式（２）により閾値を変更する。
変更後閾値＝変更前閾値×（１−間引き量） ・・・式（２）
例えば、間引き量が０から１／５に変更された時、閾値変更部１０８は、式（２）にあてはめて、５×（４／５）＝４と計算する。閾値変更部１０８は、式（２）により求められた「４」を新たな閾値として、高頻度変更領域識別部１３２に設定する。

以上の処理により、サーバ装置１０は、上限データ転送量に応じて所定の操作コマンドを間引き、間引いた操作によって発生するはずであった描画処理を削減でき、描画処理の負担を軽減することができる。所定の操作コマンドは、例えばＣＡＤアプリケーションの回転操作である。

また、サーバ装置１０は、間引き量に応じて高頻度変更領域判定の閾値を変更することで、操作コマンドの間引きにより描画回数が少なくなった領域を、描画回数を間引かない場合と同様に高頻度更新領域として検出可能とすることができる。これにより、サーバ装置１０は、データ転送量の抑制の維持が可能となる。

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

＜具体例＞
次に、コマンドフィルタ処理と閾値変更処理の具体例について説明する。図８は、コマンドフィルタ処理と閾値変更処理の具体例を説明するための図である。図８に示す例では、帯域推定部１０６は、例えば、表示画面ｄ１１の画像のときに、式（３）により上限データ転送量を推定する。このときのＲＴＴを５０ｍｓとする。画面データ・操作コマンド転送時には、遅延対策のため１サーバ・クライアント間で複数のコネクションを作成し、ここにデータを分割して送信することで、データ転送量の上限を増加させることがある。そのため、上限データ転送量の計算時には、ＲＴＴだけでなくコネクション数も考慮するとよい。
上限データ転送量＝６４×（１０００／ＲＴＴ）×ｎ ・・・式（３）
ｎ：コネクション数
次に、クライアント端末２０で、マウスの移動操作を行った場合と、移動操作以外の操作を行った場合とで場合分けする。

マウスの移動操作が行われた場合、マウスのドラッグコマンドＣ１１がサーバ装置１０に送信される。このとき、フィルタ部１０７は、上限データ転送量がフィルタリング閾値より小さければ、このドラッグコマンドＣ１１を間引く。表示画面ｄ１２では、ウィンドウが起動し、このウィンドウの移動の処理が間引かれることになる。

閾値変更部１０８は、操作コマンドが間引かれると、動画化領域推定部１０３で動画化判定に用いる閾値を式（２）により変更する。動画化領域推定部１０３は、変更された閾値を用いて、画像内の領域で動画化する領域があるかを判定し、動画化する領域があれば動画化対象領域に設定する。表示画面ｄ１３では、例えば領域ａｒ１１が動画化領域と判定される。

一方、フィルタ部１０７は、マウスの移動操作以外の操作コマンド（例えばＣ２１）を取得した場合、そのままＯＳ実行制御部１１ａに通知する。これにより前述した基本処理が行われる。表示画面ｄ２１では、ウィンドウが起動し、ドラッグコマンド以外のコマンド操作が行われる。また、表示画面ｄ２２では、例えば領域ａｒ２１が動画化領域と判定される。

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

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

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

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

通信部２０１は、サーバ装置１０とデータ通信を行う処理部である。例えば、通信部２０１は、操作情報通知部２１１と、第１の受信部２１２と、第２の受信部２１３とを有する。

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

第１の受信部２１２は、サーバ装置１０の第１の送信部１１２により送信された更新矩形の符号化データ及び属性情報を受信する処理部である。例えば、第１の受信部２１２は、受信した符号化データを第１のデコーダ２０２に出力する。

第１のデコーダ２０２は、第１の受信部２１２により受信された更新矩形の符号化データをデコードする処理部である。第１のデコーダ２０２は、サーバ装置１０に搭載されるエンコード方式に適合するデコード方式のデコーダが搭載される。

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

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

第２の受信部２１３は、サーバ装置１０の第２の送信部１１３により送信された高頻度変更領域のエンコード画像及び属性情報を受信する処理部である。

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

第２の表示制御部２０５は、第２の受信部２１３によって受信された高頻度変更領域の属性情報に基づき、第２のデコーダ２０４によりデコードされた高頻度変更領域のデコード画像を表示部２２に表示させる処理部である。例えば、第２の表示制御部２０５は、高頻度変更領域の属性情報に含まれる高頻度変更領域の位置および大きさに対応する表示部２２の画面領域に高頻度変更領域のデコード画像を表示させる。

なお、クライアント側リモート画面制御部２３には、各種の集積回路や電子回路を採用できる。また、クライアント側リモート画面制御部２３に含まれる機能部の一部を別の集積回路や電子回路とすることもできる。例えば、集積回路としては、ＡＳＩＣやＦＰＧＡが挙げられる。また、電子回路としては、ＣＰＵやＭＰＵなどが挙げられる。

＜動作＞
次に、シンクライアントシステム１に用いられる各装置の動作について説明する。まず、サーバ装置１０の動作について説明する。

《サーバ装置の処理》
図９は、実施例１におけるサーバ装置１０の情報処理の一例を示すフローチャートである。図９に示すステップＳ１０１で、操作情報取得部１１１は、クライアント端末２０から操作情報を受信したかをチェックする。

ステップＳ１０２で、帯域推定部１０６は、所定時間経過したかを判定する。所定時間経過していれば（ステップＳ１０２−Ｙｅｓ）ステップＳ１０３に進み、所定時間経過していなければ（ステップＳ１０２−Ｎｏ）ステップＳ１０２に戻る。

ステップＳ１０３で、帯域推定部１０６は、ＲＴＴを用いて、式（３）により上限データ転送量を推定する。

ステップＳ１０４で、フィルタ部１０７は、クライアント端末２０から受信された操作情報に含まれるコマンドは、所定の操作コマンドであるか否かを判定する。例えば、所定の操作コマンドは、マウスのドラッグコマンドである。所定の操作コマンドであれば（ステップＳ１０４−Ｙｅｓ）ステップＳ１０５に進み、所定の操作コマンドでなければ（ステップＳ１０４−Ｎｏ）ステップＳ１０７に進む。

ステップＳ１０５で、フィルタ部１０７は、所定の操作コマンドを、式（１）により求められる間引き量を用いて間引く。

ステップＳ１０６で、閾値変更部１０８は、動画化判定に用いる閾値を変更し、高頻度変更領域識別部１３２に設定する。

ステップＳ１０７で、ＯＳ実行制御部１１ａ、アプリ実行制御部１１ｂ、グラフィックドライバ１２、フレームバッファ１３によりユーザの操作をフレームバッファに反映する。

ステップＳ１０８で、画像生成部１０２は、フレームバッファ１３に描画されたビットマップデータが、前回のビットマップデータから変更があるか否かを判定する。変更があれば（ステップＳ１０８−Ｙｅｓ）ステップＳ１０９に進み、変更がなければ（ステップＳ１０８−Ｎｏ）ステップＳ１０１に戻る。

ステップＳ１０９で、画像生成部１０２は、表示画面の画像に更新される領域があれば、更新矩形を生成する。

ステップＳ１１０で、変更頻度判別部１３１は、更新矩形の位置及び大きさ、変更回数などを含む更新矩形情報を蓄積する。

ステップＳ１１１で、高頻度変更領域識別部１３２は、所定の期間内で、変更回数が閾値を超える変更領域（高頻度変更領域）を検出する。

ステップＳ１１２で、高頻度変更領域識別部１３２は、高頻度変更領域があるか否かを判定する。高頻度変更領域があれば（ステップＳ１１２−Ｙｅｓ）ステップＳ１１３に進み、高頻度変更領域がなければ（ステップＳ１１２−Ｎｏ）ステップＳ１１５に進む。

ステップＳ１１３で、第２のエンコーダ１０５は、変更領域の画像を動画として処理し、動画圧縮を行う。

ステップＳ１１４で、第２の送信部１１３は、変更領域（高頻度変更領域）の動画データをクライアント端末２０に送信する。

ステップＳ１１５で、第１のエンコーダ１０４は、変更領域を画像で取得し、静止画圧縮を行う。

ステップＳ１１６で、第１の送信部１１２は、変更領域（更新矩形）の画像データをクライアント端末２０に送信する。次に、各部の処理について具体的に説明する。

（帯域推定部の処理）
図１０は、実施例１における帯域推定部１０６の処理の一例を示すフローチャートである。図１０に示す処理は、図９に示すステップＳ１０３の処理である。ステップＳ２０１で、帯域推定部１０６は、ＲＴＴを算出する。ステップＳ１０２で、帯域推定部１０６は、コネクション数を取得する。

ステップＳ１０３で、帯域推定部１０６は、式（３）により、上限データ転送量を算出する。

（フィルタ部の処理）
図１１は、実施例１におけるフィルタ部１０７の処理の一例を示すフローチャートである。図１１に示す処理は、図９に示すステップＳ１０５、Ｓ１０６の処理である。ステップＳ３０１で、フィルタ部１０７は、帯域推定部１０６から上限データ転送量を取得する度に、取得した上限データ転送量が、フィルタリング閾値（第２閾値）未満であるか否かを判定する。上限データ転送量がフィルタリング閾値未満であれば（ステップＳ３０１−Ｙｅｓ）ステップＳ３０２に進み、上限データ転送量がフィルタリング閾値以上であれば（ステップＳ３０１−Ｎｏ）ステップＳ３０１に戻る。

ステップＳ３０２で、フィルタ部１０７は、式（１）により、間引き量を算出する。ステップＳ３０３で、フィルタ部１０７は、操作情報取得部１１１から操作コマンドを取得したか否かを判定する。操作コマンドがあれば（ステップＳ３０３−Ｙｅｓ）ステップＳ３０４に進み、操作コマンドがなければ（ステップＳ３０３−Ｎｏ）ステップＳ３０１に戻る。

ステップＳ３０４で、フィルタ部１０７は、所定の操作コマンドであるか否かを判定する。所定の操作コマンドであれば（ステップＳ３０４−Ｙｅｓ）ステップＳ３０５に進み、所定の操作コマンドでなければ（ステップＳ３０４−Ｎｏ）ステップＳ３０６に進む。

ステップＳ３０５で、フィルタ部１０７は、所定の操作コマンドを、算出した間引き量に基づいて間引き処理を実行する。

ステップＳ３０６で、フィルタ部１０７は、操作コマンドをＯＳ実行制御部１１ａに通知する。

これにより、画面更新が大量に発生する可能性があるコマンドを間引くことで、サーバ装置１０の処理負荷を軽減することができる。

（閾値変更部の処理）
図１２は、実施例１における閾値変更部１０８の処理の一例を示すフローチャートである。図１２に示すステップＳ４０１で、閾値変更部１０８は、フィルタ部１０７により間引き状態が以前の状態から変更されたか否かを判定する。間引き処理が新たに行われたり、間引き量が変更されたり、間引き処理が終了したりすれば（ステップＳ４０１−Ｙｅｓ）ステップＳ４０２に進み、間引き処理状態の変更がなければ（ステップＳ４０１−Ｎｏ）ステップＳ４０１に戻る。

ステップＳ４０２で、閾値変更部１０８は、高頻度変更領域を判定するのに用いる閾値を変更し、変更後の閾値を高頻度変更領域識別部１３２に通知する。

これにより、操作コマンドが間引かれても、基本処理と同様にして適切な閾値を用いて動画化判定処理を行うことができる。

《クライアント端末の処理》
図１３は、実施例１におけるクライアント端末２０の情報処理の一例を示すフローチャートである。図１３に示すステップＳ５０１で、入力部２１は、マウスや、キー入力などによるユーザ操作があるか否かを判定する。ユーザ操作があれば（ステップＳ５０１−Ｙｅｓ）ステップＳ５０２に進み、ユーザ操作がなければ（ステップＳ５０１−Ｎｏ）ステップＳ５０３に進む。

ステップＳ５０２で、操作情報通知部２１１は、操作情報を逐次、サーバ装置１０へ送信する。

ステップＳ５０３で、第１の受信部２１２は、画像データを受信したか否かを判定する。画像データを受信していれば（ステップＳ５０３−Ｙｅｓ）ステップＳ５０４に進み、画像データを受信していなければ（ステップＳ５０３−Ｎｏ）ステップＳ５０５に進む。

ステップＳ５０４で、第１のデコーダ２０２は、画像データを復号し、第１の表示制御部２０３は、復号された画像を表示部２２の所定位置に表示させる。

ステップＳ５０５で、第２の受信部２１３は、動画データを受信したか否かを判定する。動画データを受信していれば（ステップＳ５０５−Ｙｅｓ）ステップＳ５０６に進み、動画データを受信していなければ（ステップＳ５０５−Ｎｏ）ステップＳ５０１に戻る。

ステップＳ５０６で、第２のデコーダ２０４は、動画データを復号し、第２の表示制御部２０５は、復号された動画を表示部２２の所定位置に表示させる。

以上、実施例１によれば、シンクライアントの操作レスポンスを損なわずに、サーバ側の処理負荷を軽減し、データ転送量を削減することができる。

［実施例２］
次に、実施例２におけるシンクライアントシステムについて説明する。実施例２では、サーバ装置に更新データ量算出部を有し、これからクライアント端末に送信されるデータ量を算出してフィルタリング閾値として設定する。これからクライアント端末に送信されるデータ量を更新データ量とも呼ぶ。

これは、フィルタリング閾値を実際に送信するデータ量よりも大きく設定してしまうと、実際には描画処理を間引かなくてもよいのに間引いてしまい、ＦＰＳ（frame Per Second）が減少してしまう。また、フィルタリング閾値を実際に送信するデータ量より小さく設定してしまうと、間引いた方が良い場合にも関わらず、描画処理を間引かずに無駄に描画処理を行ってしまう場合がある。

よって、更新データ量の平均値を所定間隔で算出し、この更新データ量をフィルタ部で用いられる閾値（第１閾値）に設定することで、操作コマンドの間引き処理を適切に行うことができる。

また、帯域推定部は、ＲＴＴを用いて上限データ転送量を推定しているが、上限データ転送量は、ＲＴＴのみによって決定されるものではなく、サーバ装置側の処理能力やネットワーク性能の変動によって決定される。そのため、ＲＴＴのみを利用して算出された上限データ転送量が多いと推定されたネットワークでも、他の影響で実際には上限データ転送量よりも少ないデータ量しか送信できない場合が発生する。

そのため、帯域推定部は、ＲＴＴに加えて過去に実際に送信した実績のデータ転送量を計測する。過去に実際に送信したデータ転送量を実績データ量とも呼ぶ。帯域推定部は、更新データ量と、実績データ量とを比較し、差が所定値以上であれば実績データ量を上限データ転送量に設定する。

よって、算出した更新データ量と、実績データ量とに大きな差がある場合は、実績データ量を上限データ転送量に設定し、実績値を用いて操作コマンドをフィルタすることができ、より適切な間引き処理を行うことができる。

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

図１４に示すシンクライアントシステム２は、クライアント端末２０が表示する画面をリモートでサーバ装置１０に制御させるものである。基本的なシステム構成は、図１に示す構成と同様であり、実施例１と異なるところは、サーバ装置３０の構成である。以下では、サーバ装置３０について説明する。

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

サーバ側リモート画面制御部３１について、帯域推定部３０１と更新データ量算出部３０２以外の構成は、図１に示すサーバ側リモート画面制御部３１の構成と同様であるため、同じ符号を付す。

更新データ量算出部３０２は、第１の送信部１１２及び第２の送信部１１３から、これからクライアント端末に送信するデータ量（更新データ量）を取得し、所定時間の更新データ量の平均値を算出する。更新データ量算出部３０２は、算出した更新データ量の平均値を、フィルタ部１０７で用いられるフィルタリング閾値に設定する。

更新データ量算出部３０２は、例えば、直近の１０秒間で、更新データ量の平均値が３Ｍｂｐｓであると算出した場合、この平均値をフィルタ部１０７のフィルタリング閾値に設定する。これにより、フィルタ部１０７では、適切な間引き処理が行われる。

また、帯域推定部３０１は、更新データ量算出部３０２で算出された更新データ量を用いて、上限データ転送量を変更してもよい。例えば、帯域推定部３０１は、第１の送信部１１２及び第２の送信部１１３から実際に送信されたデータ量（実績データ量）を計測し、実績データ量と更新データ量とを比較する。

帯域推定部３０１は、比較の結果、更新データ量と実績データ量との差が所定値以上であれば、実績データ量を上限データ転送量に設定し、フィルタ部１０７に通知する。例えば、所定値が５００ｋｂｐｓとし、更新データ量の平均値が３Ｍｂｐｓであり、更新データ量を算出した区間と同区間の実績データ量の平均が２Ｍｂｐｓだとする。

このとき、更新データ量と実績データ量との差（１Ｍｂｐｓ）が、所定値（５００ｋｂｐｓ）以上であるため、帯域推定部３０１は、実績データ量（２Ｍｂｐｓ）を上限データ転送量として設定し、フィルタ部１０７に通知する。これにより、フィルタ部１０７では、適切な間引き処理が行われる。

＜動作＞
次に、シンクライアントシステム２に用いられるサーバ装置３０の動作について説明する。クライアント端末２０の動作は、実施例１と同様であるため、その説明を省略する。

《サーバ装置の処理》
サーバ装置３０の処理は、図９に示す処理と基本的には同様である。図９に示す処理と異なるとことは、更新データ量をフィルタリング閾値に設定することと、上限データ転送量に実績値を考慮することである。以下では、これらの処理を順に説明する。

（フィルタリング閾値設定処理）
図１５は、実施例２におけるフィルタリング閾値設定処理の一例を示すフローチャートである。図１５に示す処理は、図９に示すステップＳ１０３の処理と並行して行われる。

ステップＳ６０１で、更新データ量算出部３０２は、所定時間（例えば５秒）毎に、更新データ量の平均値を算出する。

ステップＳ６０２で、更新データ量算出部３０２は、算出した平均の更新データ量を、フィルタ部１０７に通知し、フィルタリング閾値として設定する。

これにより、フィルリング閾値を適切な値に設定することで、適切な間引き処理を行うことができる。

（上限データ転送量の設定）
図１６は、実施例２における上限データ転送量の設定処理の一例を示すフローチャートである。図１６に示す処理は、ステップＳ１０３に対応する処理である。

ステップＳ７０１〜Ｓ７０３の処理は、図１０に示すステップＳ２０１〜Ｓ２０３の処理と同様であるため、その説明を省略する。

ステップＳ７０４で、帯域推定部３０１は、実績データ量の算出処理を行う。帯域推定部３０１は、クライアント端末２０に送信された実績のデータ量について所定時間の平均を算出する。

ステップＳ７０５で、帯域推定部３０１は、更新データ量算出部３０２から、平均の更新データ量を取得する。

ステップＳ７０６で、帯域推定部３０１は、実績データ量と、更新データ量との差が所定値以上であるか否かを判定する。差が所定値以上であれば（ステップＳ７０６−Ｙｅｓ）ステップＳ７０７に進み、差が所定値未満であれば（ステップＳ７０６−Ｎｏ）算出された上限データ転送量が、上限データ転送量に設定される。

ステップＳ７０７で、帯域推定部３０１は、実績データ量を上限データ転送量に設定し、フィルタ部１０７に通知する。

これにより、上限データ転送量を、実績データ量に変更することができるので、より適切なネットワークでのデータ送信量を用いて間引き処理を行うことができる。

以上、実施例２によれば、より適切なフィルタリング閾値を設定することで、適切な間引き処理を行うことができる。また、実施例２によれば、実績データ量を算出する場合には、実績データ量を上限データ転送量に設定可能とすることで、送信したデータ量の実績値に基づいて適切な間引き処理を行うことができる。

［変形例］
図１７は、情報処理装置４００の構成の一例を示すブロック図である。情報処理装置４００は、各実施例で説明したサーバ装置１０、３０及びクライアント端末２０の一例である。図１７に示すように、情報処理装置４００は、制御部４０１、主記憶部４０２、補助記憶部４０３、ドライブ装置４０４、ネットワークＩ／Ｆ部４０６、入力部４０７、表示部４０８を含む。これら各構成は、バスを介して相互にデータ送受信可能に接続されている。

制御部４０１は、コンピュータの中で、各装置の制御やデータの演算、加工を行うＣＰＵである。また、制御部４０１は、主記憶部４０２や補助記憶部４０３に記憶されたプログラムを実行する演算装置である。このプログラムは、上記各実施例で説明した情報処理を実行するプログラムである。

制御部４０１は、このプログラムを実行することで、実施例で説明した情報処理を実現できる。

主記憶部４０２は、ＲＯＭ（Read Only Memory）やＲＡＭ（Random Access Memory）などであり、制御部４０１が実行する基本ソフトウェアであるＯＳやアプリケーションソフトウェアなどのプログラムやデータを記憶又は一時保存する記憶装置である。

補助記憶部４０３は、ＨＤＤ（Hard Disk Drive）などであり、アプリケーションソフトウェアなどに関連するデータを記憶する記憶装置である。

ドライブ装置４０４は、記録媒体４０５、例えばフレキシブルディスクからプログラムを読み出し、記憶装置にインストールする。

また、記録媒体４０５に、所定のプログラムを格納し、この記録媒体４０５に格納されたプログラムはドライブ装置４０４を介して情報処理装置４００にインストールされる。インストールされた所定のプログラムは、情報処理装置４００により実行可能となる。

ネットワークＩ／Ｆ部４０６は、有線及び／又は無線回線などのデータ伝送路により構築されたＬＡＮ（Local Area Network）、ＷＡＮ（Wide Area Network）などのネットワークを介して接続された通信機能を有する周辺機器と情報処理装置４００とのインターフェースである。

入力部４０７は、カーソルキー、数字入力及び各種機能キー等を備えたキーボード、表示部４０８の表示画面上でキーの選択等を行うためのマウスやスライスパット等を有する。また、入力部４０７は、ユーザが制御部４０１に操作指示を与えたり、データを入力したりするためのユーザインターフェースである。

表示部４０８は、ＣＲＴ（Cathode Ray Tube）やＬＣＤ（Liquid Crystal Display）等により構成され、制御部４０１から入力される表示データに応じた表示が行われる。

このように、上述した実施例で説明した情報処理は、コンピュータに実行させるためのプログラムとして実現されてもよい。このプログラムをサーバ等からインストールしてコンピュータに実行させることで、上述した情報処理を実現することができる。

また、このプログラムを記録媒体４０５に記録し、このプログラムが記録された記録媒体４０５をコンピュータや携帯端末に読み取らせて、上述した情報処理を実現させることも可能である。なお、記録媒体４０５は、ＣＤ−ＲＯＭ、フレキシブルディスク、光磁気ディスク等の様に情報を光学的、電気的或いは磁気的に記録する記録媒体、ＲＯＭ、フラッシュメモリ等の様に情報を電気的に記録する半導体メモリ等、様々なタイプの記録媒体を用いることができる。記録媒体には、搬送波は含まれない。また、上述した実施例で説明した情報処理は、１つ又は複数の集積回路に実装してもよい。

また、開示の入力部は、加速度センサや光センサ、地磁気センサ、温度センサなどのユーザの周辺状況および端末へのユーザの動作をセンシング可能なセンサでも良いし、タッチパネルやキーボードやマイクロフォンなどのユーザが直接入力を行う機器でもよい。

また、各実施例ではクライアント端末としてサーバ上のデスクトップ環境と同サイズの出力が可能なクライアント端末を想定している。しかし、クライアント端末は、画面の表示サイズを縮小することで、ＰＤＡ（Personal Digital Assistant）やノートＰＣ、携帯ゲーム機、携帯音楽プレイヤーなどの画面サイズの小さな端末上にも適用可能である。また、サーバ装置側のＯＳ実行制御部は特定のアーキテクチャに依存せず、どのようなＯＳでも構わない。

なお、シンクライアントシステムでは文章作成アプリケーションやＷｅｂブラウザだけではなく、ＣＡＤアプリケーションも利用可能である。ＣＡＤアプリケーションでは、基盤の配線や３Ｄモデルの作成をワイヤフレームとよばれるデータで行う。このデータによっては、その後より詳細な描画データを作成するレンダリングと呼ばれる作業や、ワイヤフレームを様々な角度から眺めて不具合や不良部分や全体を検査するといった作業が行われる。

よって、ＣＡＤアプリケーションなどをシンクライアントシステム上で利用する場合には大量のデータを転送することが要求される。このような大量のデータ転送が発生するアプリケーションを利用する場合、全ての画面データをそのままの形で転送すると数１００Ｍｂｉｔｓ／秒のネットワークの帯域幅を消費してしまう。

上記各実施例では、画面データを転送する場合には圧縮処理を行った上でデータを転送することができる。圧縮処理を行う場合には、画質とデータ量のトレードオフによって特定時間あたりのデータ量を変化させることが可能となる。

また、近年では、デスクトップＰＣだけでなくノートＰＣやタブレット端末といったモバイル端末をシンクライアントのクライアントとして利用してシンクライアントシステムへ接続する、という需要が高まっている。しかし、モバイル端末はデスクトップＰＣに比べて十分な処理能力が利用できない。そのため、サーバが画面の更新データを圧縮して送信する場合、モバイル端末側でリアルタイムに展開処理ができず、描画処理が遅延してしまうという問題が発生する。

上記実施例は、クライアント端末側の描画処理の負荷を軽減し、さらにサーバ側の描画処理の負荷も軽減してデータ転送量を削減できるため、モバイル環境においてもシンクライアントシステムを適用可能にするものである。

なお、上記各実施例は、ユーザがクライアント端末を利用してサーバ装置からデスクトップ環境の表示画面を、ネットワークを介して受信して利用する場面で適用できる。

また、デスクトップ環境ではＣＡＤアプリケーションの利用時に、３Ｄオブジェクトデータを開き、これをマウスのドラッグ操作で回転させ大量の画面更新が発生する、という操作シーンにも上記実施例は適用できる。

ただし、開示の技術は、ＣＡＤアプリケーションに特化したものではなく、他のアプリケーション利用時でマウスのドラッグ操作により大量の画面更新が発生する場面へも適用可能である。

また、上記実施例ではフィルタ部において間引かれるコマンドとしてマウスのドラッグコマンドを用いてきたが、これ以外のコマンドもフィルタ対象となる。例えば、上下左右に対するスクロール操作やこれと同等のカーソルキーによる入力操作がフィルタ対象となる。

これらのコマンドでも、マウスのドラッグ操作と同様に１コマンドに対して１回画面の更新が行われる。例えば、Ｗｅｂブラウザではスクロール操作を１回行うと、表示ページが特定方向に全てスクロールするため、スクロールした部分全体が画面更新として認識される。

そのため、大量にこれらのコマンドがＯＳ実行制御部へ入力されると画面更新も大量に発生する。このような現象は、ＷｏｒｄやＥｘｃｅｌなどのドキュメント文章の表示時など、コンテンツの表示を特定のウィンドウ領域のみに限って表示しているアプリケーションで広く発生する。

よって、開示のフィルタ部において、マウスのドラッグ操作コマンドと同様にスクロール操作コマンドなどについてもフィルタ処理を行ってよい。なお、処理方法は、マウスのドラッグ操作と同様の処理であり、またスクロール操作やカーソルキーによる入力操作はどの入力部から行われてもかまわない。

なお、クライアント端末の処理負荷の軽減のためにサーバ装置側の画面送信フレームレートを低下させるシーンにおいて、単純にサーバ装置側の描画フレーム数を間引くと、動画化処理が適切に動作せずデータ転送量が増加する問題があった。これに対し、開示の技術では、サーバ装置側でネットワークの上限データ転送量を推定し、上限にあわせて所定の操作コマンドを間引くことで描画処理負荷を削減するとともに、動画化処理で利用される閾値を間引いた量に応じて変更することで、動画化処理を適切に動作させ、データ転送量を削減することが可能である。

以上、各実施例について詳述したが、上記各実施例に限定されるものではなく、特許請求の範囲に記載された範囲内において、上記変形例以外にも種々の変形及び変更が可能である。

なお、以上の各実施例に関し、さらに以下の付記を開示する。
（付記１）
ネットワークを介して接続された端末に、該端末で表示される画像を生成して、該画像に関するデータを送信する情報処理装置であって、
前記端末から送信される操作コマンドに基づいて変更される前記画像に対して、該画像内の領域で、所定期間内に第１閾値以上の変更があれば前記領域を動画化対象の領域に設定する動画化領域推定部と、
前記情報処理装置及び前記端末間のネットワークの往復遅延に基づき、上限のデータ転送量を推定する推定部と、
前記推定されたデータ転送量が第２閾値未満の場合、前記操作コマンドのうち、所定の操作コマンドを間引くフィルタ部と、
前記所定の操作コマンドが間引かれた場合、前記フィルタ部の間引き量に応じて前記第１閾値を変更する閾値変更部と、
を備える情報処理装置。
（付記２）
前記情報処理装置から前記端末に送信される第１データ量の平均値を所定間隔で算出し、該平均値を前記第２閾値に設定する算出部をさらに備える付記１記載の情報処理装置。
（付記３）
前記推定部は、
前記情報処理装置から前記端末に実際に送信された第２データ量を計測し、該第２データ量と前記第１データ量との差が所定値以上であれば、該第２データ量を前記データ転送量に設定する付記２記載の情報処理装置。
（付記４）
ネットワークを介して接続された端末に、該端末で表示される画像を生成して、該画像に関するデータを送信する情報処理装置が実行する情報処理方法であって、
前記端末から送信される操作コマンドに基づいて変更される前記画像に対して、該画像内の領域で、所定期間内に第１閾値以上の変更があれば前記領域を動画化対象の領域に設定し、
前記情報処理装置及び前記端末間のネットワークの往復遅延に基づき、上限のデータ転送量を推定し、
前記推定されたデータ転送量が第２閾値未満の場合、前記操作コマンドのうち、所定の操作コマンドを間引き、
前記所定の操作コマンドが間引かれた場合、前記所定の操作コマンドの間引き量に応じて前記第１閾値を変更する処理を有する情報処理方法。
（付記５）
前記情報処理装置から前記端末に送信される第１データ量の平均値を所定間隔で算出し、該平均値を前記第２閾値に設定する処理をさらに有する付記４記載の情報処理方法。
（付記６）
ネットワークを介して接続された端末に、該端末で表示される画像を生成して、該画像に関するデータを送信する情報処理装置に実行させるためのプログラムであって、
前記端末から送信される操作コマンドに基づいて変更される前記画像に対して、該画像内の領域で、所定期間内に第１閾値以上の変更があれば前記領域を動画化対象の領域に設定し、
前記情報処理装置及び前記端末間のネットワークの往復遅延に基づき、上限のデータ転送量を推定し、
前記推定されたデータ転送量が第２閾値未満の場合、前記操作コマンドのうち、所定の操作コマンドを間引き、
前記所定の操作コマンドが間引かれた場合、前記所定の操作コマンドの間引き量に応じて前記第１閾値を変更する処理を情報処理装置に実行させるためのプログラム。

１０ サーバ装置
２０ クライアント端末
１１ａ ＯＳ実行制御部
１１ｂ アプリ実行制御部
１２ グラフィックドライバ
１３ フレームバッファ
１４、３１ サーバ側リモート画面制御部
２１ 入力部
２２ 表示部
２３ クライアント側リモート画面制御部
１０１ 通信部
１０２ 画像生成部
１０３ 動画化領域推定部
１０４ 第１のエンコーダ
１０５ 第２のエンコーダ
１０６、３０１ 帯域推定部
１０７ フィルタ部
１０８ 閾値変更部
１１１ 操作情報取得部
１１２ 第１の送信部
１１３ 第２の送信部
１３１変更頻度識別部
１３２ 高頻度変更領域識別部
２１１ 操作情報通知部
２１２ 第１の受信部
２１３ 第２の受信部
３０２ 更新データ量算出部

Claims (5)

1. ネットワークを介して接続された端末に、該端末で表示される画像を生成して、該画像に関するデータを送信する情報処理装置であって、
   前記端末から送信される操作コマンドに基づいて変更される前記画像に対して、該画像内の領域で、所定時間内に第１閾値以上の変更があれば前記領域を動画化対象の領域に設定する動画化領域推定部と、
   前記情報処理装置及び前記端末間のネットワークの往復遅延に基づき、上限のデータ転送量を推定する推定部と、
   前記推定されたデータ転送量が第２閾値未満の場合、前記操作コマンドのうち、所定の操作コマンドを間引くフィルタ部と、
   前記所定の操作コマンドが間引かれた場合、前記フィルタ部の間引き量に応じて前記第１閾値を変更する閾値変更部と、
   を備える情報処理装置。
2. 前記情報処理装置から前記端末に送信される第１データ量の平均値を所定間隔で算出し、該平均値を前記第２閾値に設定する算出部をさらに備える請求項１記載の情報処理装置。
3. 前記推定部は、
   前記情報処理装置から前記端末に実際に送信された第２データ量を計測し、該第２データ量と前記第１データ量との差が所定値以上であれば、該第２データ量を前記データ転送量に設定する請求項２記載の情報処理装置。
4. ネットワークを介して接続された端末に、該端末で表示される画像を生成して、該画像に関するデータを送信する情報処理装置が実行する情報処理方法であって、
   前記端末から送信される操作コマンドに基づいて変更される前記画像に対して、該画像内の領域で、所定時間内に第１閾値以上の変更があれば前記領域を動画化対象の領域に設定し、
   前記情報処理装置及び前記端末間のネットワークの往復遅延に基づき、上限のデータ転送量を推定し、
   前記推定されたデータ転送量が第２閾値未満の場合、前記操作コマンドのうち、所定の操作コマンドを間引き、
   前記所定の操作コマンドが間引かれた場合、前記所定の操作コマンドの間引き量に応じて前記第１閾値を変更する処理を有する情報処理方法。
5. ネットワークを介して接続された端末に、該端末で表示される画像を生成して、該画像に関するデータを送信する情報処理装置に実行させるためのプログラムであって、
   前記端末から送信される操作コマンドに基づいて変更される前記画像に対して、該画像内の領域で、所定時間内に第１閾値以上の変更があれば前記領域を動画化対象の領域に設定し、
   前記情報処理装置及び前記端末間のネットワークの往復遅延に基づき、上限のデータ転送量を推定し、
   前記推定されたデータ転送量が第２閾値未満の場合、前記操作コマンドのうち、所定の操作コマンドを間引き、
   前記所定の操作コマンドが間引かれた場合、前記所定の操作コマンドの間引き量に応じて前記第１閾値を変更する処理を情報処理装置に実行させるためのプログラム。