情報処理装置、画像送信プログラム、画像表示プログラム及び画像表示方法
【課題】シンクライアントの汎用性を維持しつつ、操作レスポンスを向上させることを課題とする。
【解決手段】情報処理装置１は、画像メモリ１ａと、変更頻度判別部１ｂと、第１の画像送信部１ｃと、高頻度変更領域識別部１ｄと、送信停止部１ｅと、第２の画像送信部１ｆとを有する。画像メモリ１ａは、コンピュータの実行結果を描画する画像を保持する。変更頻度判別部１ｂは、画像メモリ１ａに描画された画像を複数の領域に分割し、領域ごとにフレーム間の変更の頻度を判別する。第１の画像送信部１ｃは、変更のある領域の画像を送信する。高頻度変更領域識別部１ｄは、変更の頻度がしきい値を超えた領域を高頻度更新領域として識別する。送信停止部１ｅは、識別した領域について、第１の画像送信部１ｃでの送信を停止する。第２の画像送信部１ｆは、識別した領域の画像を、第１の画像送信部１ｃよりも圧縮率の高い動画の圧縮処理を行って送信する。
【解決手段】情報処理装置１は、画像メモリ１ａと、変更頻度判別部１ｂと、第１の画像送信部１ｃと、高頻度変更領域識別部１ｄと、送信停止部１ｅと、第２の画像送信部１ｆとを有する。画像メモリ１ａは、コンピュータの実行結果を描画する画像を保持する。変更頻度判別部１ｂは、画像メモリ１ａに描画された画像を複数の領域に分割し、領域ごとにフレーム間の変更の頻度を判別する。第１の画像送信部１ｃは、変更のある領域の画像を送信する。高頻度変更領域識別部１ｄは、変更の頻度がしきい値を超えた領域を高頻度更新領域として識別する。送信停止部１ｅは、識別した領域について、第１の画像送信部１ｃでの送信を停止する。第２の画像送信部１ｆは、識別した領域の画像を、第１の画像送信部１ｃよりも圧縮率の高い動画の圧縮処理を行って送信する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、情報処理装置、画像送信プログラム、画像表示プログラム及び画像表示方法に関する。
【背景技術】
【０００２】
シンクライアント（thin client）というシステム（system）が知られている。シンクライアントシステムでは、クライアント（client）に最低限の機能しか持たせず、サーバ（server）でアプリケーション（application）やファイル（file）などのリソース（resource）を管理するようにシステムが構築される。
【０００３】
かかるシンクライアントシステムは、実際にはサーバが処理を実行した処理結果やサーバが保持するデータをクライアントに表示させつつも、あたかもクライアントが主体となって処理を実行したり、データを保持しているかのように振る舞う。
【０００４】
一例として、シンクライアントシステムは、サーバで資料作成やメールなどの業務に関するアプリケーションを実行させ、そのアプリケーションの処理結果をクライアントに表示させる。このような業務アプリの他にも、ＣＡＤ（Computer-Aided Design）などのように精細な画像を扱うアプリケーション、さらには、動画を扱うアプリケーションなどがシンクライアントシステムの適用範囲として拡充されることが求められる。
【０００５】
ところが、シンクライアントシステムで通信に用いられるプロトコル、例えばＲＤＰ（Remote Desktop Protocol）や、ＶＮＣ（Virtual Network Computing）で用いられているＲＦＢ（Remote Frame Buffer）プロトコルなどで、画像や動画などの大容量のデータを扱う場合には、クライアントで実行される操作に対するレスポンス（response）が悪化する問題がある。なお、かかる問題は、シンクライアントシステムでクライアントとサーバ間で画面更新時に大容量のデータ送信が発生する場合に共通するものであり、画像や動画を扱う場合に限定して生じる問題ではない。
【０００６】
このことから、操作レスポンスを改善するための技術の一例として、次のような技術が提案されている。これを説明すると、サーバは、特定のメディアアプリケーション（media application）の出力を途中でフックしてそのメディアプリケーションが扱うデータをクライアントに送信する。一方、クライアントは、サーバで動作するメディアアプリケーションが扱うデータの再生処理を行う。
【先行技術文献】
【特許文献】
【０００７】
【特許文献１】特表２００７−５０５５８０号公報
【発明の概要】
【発明が解決しようとする課題】
【０００８】
しかしながら、上記の従来技術は、特定のメディアアプリケーションに依存した環境でしか効力を発揮できないので、シンクライアントの汎用性を損なうという問題がある。
【０００９】
すなわち、上記の従来技術は、サーバ及びクライアントにインストール（install）されるメディアアプリケーションを改造するか、または予め改造を行ったメディアアプリケーションをプリインストールすることが前提となる。ところが、メディアアプリケーションの入手経路が多種多様である現状では、改造を施すことができるメディアアプリケーションは一部に限られる。このため、その他の大部分のメディアアプリケーションを利用する場合には、依然として、操作レスポンスが悪化したままで利用する他に術はない。
【００１０】
開示の技術は、上記に鑑みてなされたものであって、シンクライアントの汎用性を維持しつつ、操作レスポンスを向上させることができる情報処理装置、画像送信プログラム、画像表示プログラム及び画像表示方法を提供することを目的とする。
【課題を解決するための手段】
【００１１】
本願の開示する情報処理装置は、ネットワーク経由で接続された端末装置の表示部にコンピュータの実行結果を表示するための画像を生成してネットワークへ送信する情報処理装置である。前記情報処理装置は、コンピュータの実行結果を描画する画像を保持する画像メモリを有する。さらに、前記情報処理装置は、前記画像メモリに描画された画像を複数の領域に分割し、前記領域ごとにフレーム間の変更の頻度を判別する変更頻度判別部を有する。さらに、前記情報処理装置は、前記変更のある領域の画像を送信する第１の画像送信部を有する。さらに、前記情報処理装置は、前記変更の頻度がしきい値を超えた領域を高頻度更新領域として識別する高頻度変更領域識別部を有する。さらに、前記情報処理装置は、前記識別した領域について、前記第１の画像送信部での送信を停止する送信停止部を有する。さらに、前記情報処理装置は、前記識別した領域の画像を、前記第１の画像送信部よりも圧縮率の高い動画の圧縮処理を行って送信する第２の画像送信部を有する。
【発明の効果】
【００１２】
本願の開示する情報処理装置の一つの態様によれば、シンクライアントの汎用性を維持しつつ、操作レスポンスを向上させることができるという効果を奏する。
【図面の簡単な説明】
【００１３】
【図１】図１は、実施例１に係る情報処理装置の構成を示すブロック図である。
【図２】図２は、実施例２に係るシンクライアントシステムに含まれる各装置の構成を示すブロック図である。
【図３】図３は、デスクトップ画面の分割要領を説明するための図である。
【図４Ａ】図４Ａは、デスクトップ画面の変更頻度の判別要領を説明するための図である。
【図４Ｂ】図４Ｂは、デスクトップ画面の変更頻度の判別要領を説明するための図である。
【図４Ｃ】図４Ｃは、デスクトップ画面の変更頻度の判別要領を説明するための図である。
【図５】図５は、メッシュ連結体の補正要領を説明するための図である。
【図６】図６は、高頻度変更領域の候補の合成要領を説明するための説明図である。
【図７Ａ】図７Ａは、高頻度変更領域の属性情報の通知要領を説明するための図である。
【図７Ｂ】図７Ｂは、高頻度変更領域の属性情報の通知要領を説明するための図である。
【図７Ｃ】図７Ｃは、高頻度変更領域の属性情報の通知要領を説明するための図である。
【図８】図８は、実施例２に係る画像送信処理の手順を示すフローチャートである。
【図９Ａ】図９Ａは、マップクリアの延長要領を説明するための図である。
【図９Ｂ】図９Ｂは、マップクリアの延長要領を説明するための図である。
【図１０Ａ】図１０Ａは、高頻度変更領域の縮小に関する抑制要領を説明するための図である。
【図１０Ｂ】図１０Ｂは、高頻度変更領域の縮小に関する抑制要領を説明するための図である。
【図１１】図１１は、実施例３に係る画像送信プログラムを実行するコンピュータの一例について説明するための図である。
【発明を実施するための形態】
【００１４】
以下に、本願の開示する情報処理装置、画像送信プログラム、画像表示プログラム及び画像表示方法の実施例を図面に基づいて詳細に説明する。なお、この実施例は開示の技術を限定するものではない。
【実施例１】
【００１５】
図１は、実施例１に係る情報処理装置の構成を示すブロック図である。図１に示す情報処理装置１は、ネットワーク経由で接続された端末装置の表示部にコンピュータの実行結果を表示するための画像を生成してネットワークへ送信するである。図１に示すように、情報処理装置１は、画像メモリ１ａと、変更頻度判別部１ｂと、第１の画像送信部１ｃと、高頻度変更領域識別部１ｄと、送信停止部１ｅと、第２の画像送信部１ｆとを有する。
【００１６】
画像メモリ１ａは、コンピュータの実行結果を描画する画像を保持する。また、変更頻度判別部１ｂは、画像メモリ１ａに描画された画像を複数の領域に分割し、領域ごとにフレーム間の変更の頻度を判別する。また、第１の画像送信部１ｃは、変更のある領域の画像を送信する。
【００１７】
高頻度変更領域識別部１ｄは、変更の頻度がしきい値を超えた領域を高頻度更新領域として識別する。また、送信停止部１ｅは、高頻度変更領域識別部１ｄが高頻度変更領域として識別した領域について、第１の画像送信部１ｃでの送信を停止する。また、第２の画像送信部１ｆは、高頻度変更領域識別部１ｄが高頻度変更領域として識別した領域の画像を、第１の画像送信部１ｃよりも圧縮率の高い動画の圧縮処理を行って送信する。
【００１８】
このため、本実施例に係る情報処理装置１では、動画向けの圧縮方式を用いる領域を高頻度変更領域として特定のアプリケーションに依存せずに識別することができる。さらに、本実施例に係る情報処理装置１では、高頻度変更領域以外の領域については変更があった部分の画像を送信しつつ、高頻度変更領域についてはその領域に対応する画像を動画向けの圧縮方式のデータに圧縮できる。それゆえ、本実施例に係る情報処理装置１では、端末装置へ送信する画像のうち操作レスポンスを悪化させる根本となる画像に重点を置いてデータ量を低減しつつ、圧縮処理を行うエンコーダ、端末装置側で復号化処理を行うデコーダの負荷を最小限にできる。よって、本実施例に係る情報処理装置１によれば、シンクライアントの汎用性を維持しつつ、操作レスポンスを向上させることが可能になる。さらに、本実施例に係る情報処理装置１では、端末装置へ送信するデータ量を低減できるので、情報処理装置及び端末装置間での伝送遅延を低減できる結果、端末装置側で表示される画像がコマ落ちする可能性も低減できる。
【実施例２】
【００１９】
［システム構成］
続いて、実施例２に係るシンクライアントシステムについて説明する。図２は、実施例２に係るシンクライアントシステムに含まれる各装置の構成を示すブロック図である。
【００２０】
図２に示すシンクライアントシステム（thin client system）３は、クライアント（client）端末２０が表示する画面をリモート（remote）でサーバ（server）装置１０に制御させるものである。つまり、シンクライアントシステム３は、実際にはサーバ装置１０が実行した処理結果や保持するデータをクライアント端末２０に表示させつつも、あたかもクライアント端末２０が主体となって処理を実行したり、データを保持しているかのように振る舞う。
【００２１】
図２に示すように、シンクライアントシステム３は、サーバ装置１０と、クライアント端末２０とを有する。なお、図２の例では、１つのサーバ装置１０に対し、１つのクライアント端末を接続する場合を図示したが、任意の数のクライアント端末を接続できる。
【００２２】
これらサーバ装置１０及びクライアント端末２０は、所定のネットワーク（Network）を介して、相互に通信可能に接続される。かかるネットワークには、有線または無線を問わず、インターネット（Internet）、ＬＡＮ（Local Area Network）やＶＰＮ（Virtual Private Network）などの任意の種類の通信網を採用できる。なお、サーバ装置１０及びクライアント端末２０間の通信プロトコル（Protocol）には、一例として、ＶＮＣにおけるＲＦＢ（Remote Frame Buffer）プロトコルを採用する場合を想定する。
【００２３】
サーバ装置１０は、クライアント端末２０に表示させる画面をリモートで制御するサービスを提供するコンピュータ（computer）である。このサーバ装置１０には、サーバ向けのリモート画面制御用のアプリケーション（application）がインストール（install）またはプリインストール（preinstall）される。なお、以下では、サーバ向けのリモート画面制御用のアプリケーションをサーバ側リモート画面制御用アプリと呼ぶ。
【００２４】
このサーバ側リモート画面制御用アプリは、基本機能として、リモート画面制御サービスを提供する機能を有する。一例としては、サーバ側リモート画面制御用アプリは、クライアント端末２０における操作情報を取得した上でその操作により要求された処理を自装置で動作するアプリケーションに実行させる。そして、サーバ側リモート画面制御用アプリは、アプリケーションにより実行された処理結果を表示するための画面を生成した上でその画面をクライアント端末２０へ送信する。このとき、サーバ側リモート画面制御用アプリは、今回の画面生成の前にクライアント端末２０で表示させていたビットマップ画像（bitmap）との間で変更があった部分の画素（pixel）が集まった領域、すなわち更新矩形の画像を送信する。なお、以下では、一例として、更新部分の画像が矩形の画像で形成される場合を説明するが、開示の装置は更新部分の画像が矩形以外の形状で形成される場合にも適用できる。
【００２５】
このほか、サーバ側リモート画面制御用アプリは、フレーム（frame）間で動きが大きい部分のデータを動画向けの圧縮方式のデータに圧縮してクライアント端末２０へ送信する機能も有する。一例としては、サーバ側リモート画面制御用アプリは、アプリケーションにより実行された処理結果から生成した画面を複数の領域に分割し、分割した領域ごとに変更の頻度を監視する。このとき、サーバ側リモート画面制御用アプリは、変更の頻度がしきい値を超えた領域、すなわち高頻度変更領域の属性情報をクライアント端末２０へ送信する。これとともに、サーバ側リモート画面制御用アプリは、高頻度変更領域のビットマップ画像をＭＰＥＧ−２やＭＰＥＧ−４などのＭＰＥＧ方式のデータにエンコード（encode）した上でクライアント端末２０へ送信する。なお、ここでは、ＭＰＥＧ（Moving Picture Experts Group）方式のデータへ圧縮する場合を例示したが、これに限定されない。例えば、動画向けの圧縮方式であれば任意の圧縮符号化方式、例えばＭｏｔｉｏｎ−ＪＰＥＧ（Joint Photographic Experts Group）などを採用できる。
【００２６】
クライアント端末２０は、サーバ装置１０によるリモート画面制御サービスの提供を受ける側のコンピュータである。かかるクライアント端末２０の一例としては、パーソナルコンピュータ（personal computer）など固定端末の他、携帯電話機、ＰＨＳ（Personal Handyphone System）やＰＤＡ（Personal Digital Assistant）などの移動体端末を適用することもできる。このクライアント端末２０には、クライアント向けのリモート画面制御用アプリケーションがインストールまたはプリインストールされる。なお、以下では、クライアント向けのリモート画面制御用のアプリケーションをクライアント側リモート画面制御用アプリと呼ぶ。
【００２７】
このクライアント側リモート画面制御用アプリは、マウス（mouse）やキーボード（keyboard）などの各種の入力デバイス（device）を介して受け付けた操作情報をサーバ装置１０へ通知する機能を有する。一例としては、クライアント側リモート画面制御用アプリは、マウスの左右のクリック（click）を始め、ダブルクリック（double click）やドラッグ（drag）、マウスの移動操作を介して得られたマウスカーソルの移動量などを操作情報として通知する。他の一例としては、マウスホイールの回転量、キーボードのうち押下されたキーの種別なども操作情報として通知する。
【００２８】
さらに、クライアント側リモート画面制御用アプリは、サーバ装置１０から受信した画像を所定の表示部に表示させる機能を有する。一例としては、クライアント側リモート画面制御用アプリは、サーバ装置１０から更新矩形のビットマップ画像を受信した場合には、更新矩形の画像を前回のビットマップ画像から変更のあった位置に合わせて表示する。他の一例としては、クライアント側リモート画面制御用アプリは、サーバ装置１０から高頻度変更領域の属性情報を受信した場合には、その属性情報に含まれる位置に対応する表示画面上の領域をビットマップ画像の表示対象外のブランク（blank）領域とする。その上で、クライアント側リモート画面制御用アプリは、動画向けの圧縮方式のデータを受信した場合にそのデータをデコード（decode）した上でブランク領域に表示する。
【００２９】
［サーバ装置の構成］
次に、本実施例に係るサーバ装置の構成について説明する。図２に示すように、サーバ装置１０は、ＯＳ実行制御部１１ａと、アプリ実行制御部１１ｂと、グラフィックドライバ１２と、フレームバッファ１３と、サーバ側リモート画面制御部１４とを有する。なお、図２の例では、図２に示した機能部以外にも既知のコンピュータが有する各種の機能部、例えば各種の入力デバイスや表示デバイスなどの機能を有するものとする。
【００３０】
ＯＳ実行制御部１１ａは、ＯＳ（Operating System）の実行を制御する処理部である。例えば、ＯＳ実行制御部１１ａは、後述の操作情報取得部１４ａにより取得された操作情報からアプリケーションの起動指示やアプリケーションに対するコマンドを検出する。一例としては、ＯＳ実行制御部１１ａは、アプリケーションのアイコン（icon）上でダブルクリックを検出した場合に、そのアイコンに対応するアプリケーションの起動を後述のアプリ実行制御部１１ｂへ指示する。他の一例としては、起動中のアプリケーションの操作画面、いわゆるウィンドウ（window）上でコマンド（command）の実行を要求する操作を検出した場合に、ＯＳ実行制御部１１ａは、そのコマンドの実行をアプリ実行制御部１１ｂへ指示する。なお、以下では、アプリケーションをアプリと略記する。
【００３１】
アプリ実行制御部１１ｂは、ＯＳ実行制御部１１ａによる指示に基づき、アプリケーションの実行を制御する処理部である。一例としては、アプリ実行制御部１１ｂは、ＯＳ実行制御部１１ａによりアプリの起動が指示された場合や起動中のアプリにコマンドの実行が指示された場合にアプリを動作させる。そして、アプリ実行制御部１１ｂは、アプリを実行することにより得られた処理結果の表示用イメージ（image）をフレームバッファ１３に描画する要求を後述のグラフィックドライバ１２へ行う。このようにグラフィックドライバ１２へ描画要求を行う場合には、アプリ実行制御部１１ｂは、表示用イメージとともに表示用イメージの描画位置をグラフィックドライバ１２へ通知する。
【００３２】
なお、アプリ実行制御部１１ｂが実行するアプリは、プリインストールされたものであってもよく、サーバ装置１０の出荷後にインストールされたものであってもかまわない。また、ＪＡＶＡ（登録商標）などのネットワーク環境で動作するアプリであってもよい。
【００３３】
グラフィックドライバ（graphic driver）１２は、フレームバッファ１３に対する描画処理を実行する処理部である。一例としては、グラフィックドライバ１２は、アプリ実行制御部１１ｂからの描画要求を受け付けた場合に、アプリの処理結果の表示用イメージをアプリにより指定されたフレームバッファ１３上の描画位置へビットマップ形式で描画する。なお、ここでは、アプリにより描画要求を受け付ける場合を説明したが、ＯＳ実行制御部１１ａからの描画要求を受け付けることもできる。一例としては、グラフィックドライバ１２は、ＯＳ実行制御部１１ａからマウスカーソルの描画要求を受け付けた場合に、マウスカーソルの表示用イメージをＯＳにより指定されたフレームバッファ１３上の描画位置へビットマップ形式で描画する。
【００３４】
フレームバッファ（frame buffer）１３は、グラフィックドライバ１２により描画されたビットマップデータを記憶する記憶デバイスである。かかるフレームバッファ１３の一態様としては、ＶＲＡＭ（Video Random Access Memory）を始めとするＲＡＭ（Random Access Memory)、ＲＯＭ（Read Only Memory）やフラッシュメモリ（flash memory）などの半導体メモリ素子が挙げられる。なお、フレームバッファ１３は、ハードディスク、光ディスクなどの記憶装置を採用することとしてもかまわない。
【００３５】
サーバ側リモート画面制御部１４は、サーバ側リモート画面制御用アプリを通じて、リモート画面制御サービスをクライアント端末２０へ提供する処理部である。このサーバ側リモート画面制御部１４は、図２に示すように、操作情報取得部１４ａと、画面生成部１４ｂと、変更頻度判別部１４ｃと、高頻度変更領域識別部１４ｄと、エンコーダ１４ｅと、第１の画像送信部１４ｆと、第２の画像送信部１４ｇとを有する。
【００３６】
操作情報取得部１４ａは、クライアント端末２０から操作情報を取得する処理部である。かかる操作情報の一例としては、マウスの左右のクリックを始め、ダブルクリックやドラッグ、マウスの移動操作を介して得られたマウスカーソルの移動量などが挙げられる。操作情報の他の一例としては、マウスホイールの回転量、キーボードのうち押下されたキーの種別なども挙げられる。
【００３７】
画面生成部１４ｂは、クライアント端末２０の表示部２２に表示させる画面の画像を生成する処理部である。一例としては、画面生成部１４ｂは、グラフィックドライバ１２によりフレームバッファ１３へビットマップデータが格納される度に、次のような処理を起動する。すなわち、画面生成部１４ｂは、前回のフレーム生成時にクライアント端末２０で表示させていたデスクトップ画面と、今回のフレーム生成時にフレームバッファ１３へ書き込まれたデスクトップ画面とを比較する。そして、画面生成部１４ｂは、前回のフレームから変更があった部分の画素をつなげ合わせた上で矩形に整形した更新矩形の画像を生成し、更新矩形送信用のパケットを生成する。
【００３８】
変更頻度判別部１４ｃは、フレームバッファ１３に描画された画像を分割した領域ごとにフレーム間の変更の頻度を判別する処理部である。一例としては、変更頻度判別部１４ｃは、画面生成部１４ｂにより生成された更新矩形を図示しない作業用の内部メモリへ所定の期間にわたって蓄積する。このとき、変更頻度判別部１４ｃは、更新矩形の位置および大きさを特定可能な属性情報、例えば更新矩形の左上の頂点の座標と更新矩形の幅および高さとを蓄積する。かかる更新矩形を蓄積させる期間は、高頻度変更領域を識別する精度と相関関係があり、期間を長くするほど高頻度変更領域の誤検出が低減される。なお、ここでは、一例として、１秒間にわたって更新矩形の画像を蓄積する場合を想定する。
【００３９】
このとき、変更頻度判別部１４ｃは、更新矩形の画像を蓄積してから所定の期間が経過した場合に、クライアント端末２０に表示させるデスクトップ画面をメッシュ（mesh）状に分割したマップ（map）を用いて、デスクトップ画面の変更頻度を判別する。
【００４０】
図３は、デスクトップ画面の分割要領を説明するための図である。図３に示す符号３０は、変更頻度判別用のマップを示す。図３に示す符号３１は、マップ３０に含まれるメッシュを指す。図３に示す符号３２は、メッシュ３１を形成する画素のブロックに含まれる１画素を指す。図３に示す例では、変更頻度判別部１４ｃがマップ３０を占める画素のうち８画素×８画素のブロックを１つのメッシュとして分割する場合を想定している。この場合には、１つのメッシュに６４個の画素が含まれることになる。
【００４１】
ここで、変更頻度判別部１４ｃは、作業用の内部メモリに蓄積した更新矩形の位置および大きさにしたがって更新矩形の画像を変更頻度判別用のマップに順次展開する。そして、変更頻度判別部１４ｃは、更新矩形をマップに展開する度に、マップ上で更新矩形と重なり合った部分のメッシュの変更回数を累積して加算する。このとき、変更頻度更新部１４ｃは、マップ上に展開された更新矩形がメッシュに含まれる画素との間で所定数にわたって重なり合った場合に、そのメッシュの変更回数を１つ加算する。なお、ここでは、更新矩形がメッシュに含まれる画素と１つでも重なり合った場合に、メッシュの変更回数を加算する場合を想定して説明を行う。
【００４２】
図４Ａ〜図４Ｃは、デスクトップ画面の変更頻度の判別要領を説明するための図である。図４Ａ〜図４Ｃに示す符号４０Ａ、符号４０Ｂ及び符号４０Ｎは変更頻度判別用のマップを示す。図４Ａ及び図４Ｂに示す符号４１Ａ及び符号４１Ｂは更新矩形を示す。ここで、マップ４０Ａのメッシュ内に図示した数字は、更新矩形４１Ａが展開された時点におけるメッシュの変更回数を示す。また、マップ４０Ｂのメッシュ内に図示した数字は、更新矩形４１Ｂが展開された時点におけるメッシュの変更回数を示す。さらに、マップ４０Ｎのメッシュ内に図示した数字は、作業用の内部メモリに蓄積した更新矩形が全て展開された時点におけるメッシュの変更回数を示す。なお、図４Ａ〜図４Ｃにおいて数字が図示されていないメッシュは変更回数がゼロであるものとする。
【００４３】
図４Ａに示すように、更新矩形４１Ａがマップ４０Ａに展開された場合には、網掛け部分のメッシュが更新矩形４１Ａと重なり合う。このため、変更頻度判別部１４ｃは、網掛け部分のメッシュの更新回数を１つずつ加算する。この場合には、各メッシュの変更回数はゼロであるため、網掛け部分の変更回数は０から１に加算される。さらに、図４Ｂに示すように、更新矩形４１Ｂがマップ４０Ｂに展開された場合には、網掛け部分のメッシュが更新矩形４１Ｂと重なり合う。このため、変更頻度判別部１４ｃは、網掛け部分のメッシュの更新回数を１つずつ加算する。この場合には、各メッシュの変更回数は１であるため、網掛け部分の変更回数は１から２に加算される。このようにして全ての更新矩形がマップに展開された段階では、図４Ｃに示すマップ４０Ｎの結果が得られる。
【００４４】
そして、変更頻度判別部１４ｃは、作業用の内部メモリに蓄積した更新矩形を全てマップに展開し終えた場合に、所定の期間における変更回数、すなわち変更頻度がしきい値を超えるメッシュを取得する。図４Ｃの例で言えば、しきい値を「４」としたとき、網掛け部分のメッシュが取得されることになる。かかるしきい値は、その値を高く設定するほどデスクトップ画面で動画が表示されている可能性が高い部分を後述のエンコーダ１４ｅによりエンコードできる。なお、上記の「しきい値」は、サーバ側リモート画面制御用アプリの開発者が段階的に設定した値をエンドユーザに選択させたり、また、エンドユーザが値を直接設定することができる。
【００４５】
図２の説明に戻り、高頻度変更領域識別部１４ｄは、クライアント端末２０に表示されるデスクトップ画面のうち高頻度で変更される領域を高頻度変更領域として識別する処理部である。
【００４６】
高頻度変更領域識別部１４ｄは、変更頻度判別部１４ｃにより変更回数がしきい値を超えるメッシュが取得された場合に、隣接するメッシュ同士を連結したメッシュ連結体を矩形に補正する。一例としては、高頻度変更領域識別部１４ｄは、メッシュ連結体に補間する補間領域を導出した上でメッシュ連結体に補間領域を足し合わせることによりメッシュ連結体を矩形に補正する。この補間領域の導出には、メッシュの連結体が最小の補間で矩形に整形される領域を導出するアルゴリズム（algorithm）が適用される。
【００４７】
図５は、メッシュ連結体の補正要領を説明するための図である。図５に示す符号５１は補正前のメッシュ連結体を示す。図５に示す符号５２は補間領域を示す。また、図５に示す符号５３は補正後の矩形を示す。図５に示すように、高頻度変更領域識別部１４ｄは、メッシュ連結体５１に補間領域５２を足し合わせることにより、メッシュ連結体５１を矩形５３に補正する。この段階では、後述の矩形の合成が完了しておらず、矩形５３が未だ高頻度変更領域と確定していないので、補正後の矩形を高頻度変更領域の候補と呼ぶこととする。
【００４８】
高頻度変更領域識別部１４ｄは、高頻度変更領域の候補が複数存在する場合には、複数の高頻度変更領域の候補の距離が所定の値以下である高頻度変更領域の候補同士を含む矩形に合成する。ここで言う高頻度変更領域の候補の距離とは、補正後の矩形の最短距離を指すものとする。一例としては、高頻度変更領域識別部１４ｄは、高頻度変更領域の候補を合成するにあたって各候補の間を埋める補間領域を導出した上で高頻度変更領域の候補に補間領域を足し合わせることにより、高頻度変更領域の候補同士を含む矩形に合成する。この補間領域の導出には、高頻度変更領域の候補の間が最小の補間で合成体に整形される領域を導出するアルゴリズム（algorithm）が適用される。
【００４９】
図６は、高頻度変更領域の候補の合成要領を説明するための説明図である。図６に示す符号６１Ａ及び符号６１Ｂは、高頻度変更領域の候補を指す。図６に示す符号６２は補間領域を指す。図６に示す符号６３は、高頻度変更領域の候補６１Ａ及び高頻度変更領域の候補６１Ｂの合成体を指す。図６に示すように、高頻度変更領域識別部１４ｄは、高頻度変更領域の候補６１Ａ及び高頻度変更領域の候補６１Ｂに補間領域６２を足し合わせることにより、高頻度変更領域の候補６１Ａ及び高頻度変更領域の候補６１Ｂを含む合成体６３へ合成する。そして、高頻度変更領域識別部１４ｄは、このようにして得た合成体を高頻度変更領域と識別する。
【００５０】
このようにして高頻度変更領域を識別すると、高頻度変更領域識別部１４ｄは、高頻度変更領域の位置および大きさを特定可能な属性情報をクライアント端末２０へ送信する。これにより、クライアント端末２０で表示されるデスクトップ画面のビットマップデータのうち高頻度変更領域に対応する部分をブランク表示させる。その後、高頻度変更領域識別部１４ｄは、作業用の内部メモリにマッピングされたメッシュの変更回数をクリア（clear）する。なお、高頻度変更領域識別部１４ｄは、高頻度変更領域の属性情報を作業用の内部メモリに登録する。
【００５１】
図７Ａ〜図７Ｃは、高頻度変更領域の属性情報の通知要領を説明するための図である。図７Ａに示す符号７０Ａは、フレームバッファ１３に描画されたデスクトップ画面の一例を示す。図７Ｂ〜図７Ｃに示す符号７０Ｂ及び符号７０Ｃは、変更頻度判別用のマップを示す。図７Ａに示す符号７１は、ブラウザ（browser）画面を指す。図７Ａに示す符号７２は、動画再生画面を指す。図７Ｂに示す符号７３は、マウスの移動軌跡を示す。図７Ｂに示す符号７４は、アプリによる動画再生領域を示す。
【００５２】
図７Ａに示すように、デスクトップ画面７０Ａには、ブラウザ画面７１及び動画再生画面７２が含まれる。このデスクトップ画面７０Ａから経時的な変化を追った場合には、図７Ｂに示すように、静止画であるブラウザ画面７１の更新矩形は検出されず、マウスの移動軌跡７３および動画再生領域７４に関する更新矩形が検出される。このうち、動画の再生領域７４で変更回数がしきい値を超えるメッシュ、すなわち図示の網掛け部分が高頻度変更領域識別部１４ｄにより識別されたものとする。この場合には、高頻度変更領域識別部１４ｄは、図７Ｃに示す網掛け部分の高頻度変更領域の左上の頂点の座標（ｘ，ｙ）と、高頻度変更領域の幅ｗおよび高さｈとを高頻度変更領域の属性情報としてクライアント端末２０へ送信する。なお、ここでは、高頻度変更領域の位置を特定する点として左上の頂点の座標を採用する場合を説明したが、他の頂点を採用することとしてもかまわない。また、高頻度変更領域の位置を特定することができる点であれば、頂点以外の任意の点、例えば重心などを採用できる。また、ここでは、画面上の左上を座標軸ＸＹの原点とする場合を説明したが、画面内および画面外の任意の点を原点とすることができる。
【００５３】
また、高頻度変更領域識別部１４ｄは、画面生成部１４ｂにより更新矩形が生成される度に、その更新矩形が作業用の内部メモリに記憶された高頻度変更領域、すなわち後述の第２の画像送信部１４ｇにより動画を送信中の領域に含まれるか否かを判定する。このとき、高頻度変更領域識別部１４ｄは、更新矩形が高頻度変更領域に含まれない場合には、更新矩形の画像および属性情報を後述の第１の画像送信部１４ｆに送信させる。一方、高頻度変更領域識別部１４ｄは、更新矩形が高頻度変更領域に含まれる場合には、原則として、後述の第１の画像送信部１４ｆに更新矩形の画像および属性情報を送信させない。なお、更新矩形がＯＳ実行制御部１１ａにより描画されたマウスのものである場合には、マウスに関する更新矩形の画像および属性情報を例外的に送信させることとしてもよい。
【００５４】
また、高頻度変更領域識別部１４ｄは、フレームバッファ１３にビットマップデータが描画される度に、作業用の内部メモリに高頻度変更領域の属性情報が登録されているか否かを判定する。そして、高頻度変更領域識別部１４ｄは、高頻度変更領域の属性情報が登録されている場合に、フレームバッファ１３に描画されたビットマップデータのうち高頻度変更領域に対応する部分のビットマップ画像を切り出した上で後述のエンコーダ１４ｅへ出力する。
【００５５】
エンコーダ１４ｅは、高頻度変更領域識別部１４ｄから入力される高頻度変更領域の画像をエンコードする処理部である。一例としては、エンコーダ１４ｅは、高頻度変更領域識別部１４ｄから入力された高頻度変更領域のビットマップ画像がストリーム（stream）を形成可能なフレーム数に到達した段階で高頻度変更領域のビットマップ画像をエンコードする。なお、エンコード方式の一態様としては、ＭＰＥＧ−２やＭＰＥＧ−４などのＭＰＥＧ方式やＭｏｔｉｏｎ−ＪＰＥＧ方式が挙げられる。
【００５６】
第１の画像送信部１４ｆは、画面生成部１４ｂにより生成された更新矩形の画像および属性情報をクライアント端末２０へ送信する処理部である。この更新矩形を送信する場合の通信プロトコルには、一例としてＶＮＣにおけるＲＦＢプロトコルが採用される。
【００５７】
第２の画像送信部１４ｇは、エンコーダ１４ｅによりエンコードされた高頻度変更領域のエンコード画像をクライアント端末２０へ送信する処理部である。この高頻度変更領域のエンコード画像を送信する場合の通信プロトコルには、一例として、ＲＴＰ（Real-time Transport Protocol）を採用できる。
【００５８】
なお、ＯＳ実行制御部１１ａ、アプリ実行制御部１１ｂ、グラフィックドライバ１２、サーバ側リモート画面制御部１４には、各種の集積回路や電子回路を採用できる。また、サーバ側リモート画面制御部１４に含まれる機能部の一部を別の集積回路や電子回路とすることもできる。例えば、集積回路としては、ＡＳＩＣ（Application Specific Integrated Circuit）やＦＰＧＡ（Field Programmable Gate Array）が挙げられる。また、電子回路としては、ＣＰＵ（Central Processing Unit）やＭＰＵ（Micro Processing Unit）などが挙げられる。
【００５９】
［クライアント端末の構成］
次に、本実施例に係るクライアント端末の構成について説明する。図２に示すように、クライアント端末２０は、入力部２１と、表示部２２と、クライアント側リモート画面制御部２３とを有する。なお、図２の例では、図２に示した機能部以外にも既知のコンピュータが有する各種の機能部、例えば音声出力部などの機能を有するものとする。
【００６０】
入力部２１は、各種の情報、例えば後述のクライアント側リモート画面制御部２３に対する指示入力を受け付ける入力デバイスであり、一例としては、キーボード（keyboard）やマウス（mouse）などを適用できる。なお、後述の表示部２２も、マウスと協働して、ポインティングデバイス（pointing device）機能を実現する。
【００６１】
表示部２２は、各種の情報、例えばサーバ装置１０から送信されたデスクトップ画面などを表示する表示デバイスであり、一例としては、モニタ（monitor）、ディスプレイ（display）やタッチパネル（touch panel）などを適用できる。
【００６２】
クライアント側リモート画面制御部２３は、クライアント側リモート画面制御用アプリを通じて、サーバ装置１０によるリモート画面制御サービスの提供を受ける処理部である。このクライアント側リモート画面制御部２３は、図２に示すように、操作情報通知部２３ａと、第１の画像受信部２３ｂと、第１の表示制御部２３ｃと、第２の画像受信部２３ｄと、デコーダ２３ｅと、第２の表示制御部２３ｆとを有する。
【００６３】
操作情報通知部２３ａは、入力部２１による操作情報をサーバ装置１０へ通知する処理部である。一例としては、操作情報通知部２３ａは、マウスの左右のクリックを始め、ダブルクリックやドラッグ、マウスの移動操作を介して得られたマウスカーソルの移動量などを操作情報として通知する。他の一例としては、操作情報通知部２３ａは、マウスホイールの回転量、キーボードのうち押下されたキーの種別なども操作情報として通知する。
【００６４】
第１の画像受信部２３ｂは、サーバ装置１０の第１の画像送信部１４ｆにより送信された更新矩形の画像および属性情報を受信する処理部である。また、第１の画像受信部２３ｂは、サーバ装置１０の高頻度変更領域識別部１４ｄにより送信された高頻度変更領域の属性情報も受信する。
【００６５】
第１の表示制御部２３ｃは、第１の画像受信部２３ｂにより受信された更新矩形の画像を表示部１１に表示させる処理部である。一例としては、第１の表示制御部２３ｃは、第１の画像受信部２３ｂにより受信された更新矩形の属性情報に含まれる位置および大きさに対応する表示部２２の画面領域に更新矩形のビットマップ画像を表示させる。また、第１の表示制御部２３ｃは、第１の画像受信部２３ｂにより高頻度変更領域の属性情報が受信された場合には、次のような処理を行う。すなわち、第１の表示制御部２３ｃは、高頻度変更領域の属性情報に含まれる高頻度変更領域の位置および大きさに対応する表示部２２の画面領域をビットマップ画像の表示対象外のブランク領域とする。
【００６６】
第２の画像受信部２３ｄは、サーバ装置１０の第２の画像送信部１４ｇにより送信された高頻度変更領域のエンコード画像を受信する処理部である。また、第２の画像受信部２３ｄは、サーバ装置１０の高頻度変更領域識別部１４ｄにより送信された高頻度変更領域の属性情報も受信する。
【００６７】
デコーダ２３ｅは、第２の画像受信部２３ｄにより受信された高頻度変更領域のエンコード画像をデコードする処理部である。なお、デコーダ２３ｅには、サーバ装置１０に搭載されるエンコード方式に適合するデコード方式のデコーダが搭載される。
【００６８】
第２の表示制御部２３ｆは、第１の画像受信部２３ｂにより高頻度変更領域の属性情報に基づき、デコーダ２３ｅによりデコードされた高頻度変更領域のデコード画像を表示部２２に表示させる処理部である。一例としては、第２の表示制御部２３ｆは、高頻度変更領域の属性情報に含まれる高頻度変更領域の位置および大きさに対応する表示部２２の画面領域に高頻度変更領域のデコード画像を表示させる。
【００６９】
なお、クライアント側リモート画面制御部２３には、各種の集積回路や電子回路を採用できる。また、クライアント側リモート画面制御部２３に含まれる機能部の一部を別の集積回路や電子回路とすることもできる。例えば、集積回路としては、ＡＳＩＣ（Application Specific Integrated Circuit）やＦＰＧＡ（Field Programmable Gate Array）が挙げられる。また、電子回路としては、ＣＰＵ（Central Processing Unit）やＭＰＵ（Micro Processing Unit）などが挙げられる。
【００７０】
［処理の流れ］
次に、本実施例に係るシンクライアントシステムの処理の流れについて説明する。図８は、実施例２に係る画像送信処理の手順を示すフローチャートである。この画像送信処理は、サーバ装置１０により実行される処理であり、フレームバッファ１３にビットマップデータが描画された場合に起動する。
【００７１】
図８に示すように、フレームバッファ１３にビットマップデータが描画されると、画面生成部１４ｂは、前回のフレームから変更があった部分の画素をつなげ合わせた上で矩形に整形した更新矩形の画像を生成する（ステップＳ１０１）。そして、画面生成部１４ｂは、先に生成した更新矩形の画像から更新矩形送信用のパケットを生成する（ステップＳ１０２）。
【００７２】
続いて、変更頻度判別部１４ｃは、画面生成部１４ｂにより生成された更新矩形を図示しない作業用の内部メモリへ蓄積する（ステップＳ１０３）。このとき、更新矩形の蓄積を開始してから所定の期間が経過していない場合（ステップＳ１０４否定）には、以降に続く高頻度変更領域の識別に関する処理をとばし、後述のステップＳ１１３へ移行する。
【００７３】
一方、更新矩形の蓄積を開始してから所定の期間が経過した場合（ステップＳ１０４肯定）には、変更頻度判別部１４ｃは、次のような処理を行う。すなわち、変更頻度判別部１４ｃは、作業用の内部メモリに蓄積した更新矩形の位置および大きさにしたがって更新矩形の画像を変更頻度判別用のマップに順次展開する（ステップＳ１０５）。そして、変更頻度判別部１４ｃは、変更頻度判別用のマップに含まれるメッシュのうち変更頻度がしきい値を超えるメッシュを取得する（ステップＳ１０６）。
【００７４】
その後、高頻度変更領域識別部１４ｄは、変更頻度判別部１４ｃにより変更頻度がしきい値を超えるメッシュが取得されたか否かを判定する（ステップＳ１０７）。このとき、変更頻度がしきい値を超えるメッシュが存在しない場合（ステップＳ１０７否定）には、高頻度変更領域がデスクトップ画面に存在しないので、以降に続く高頻度変更領域の識別に関する処理をとばし、ステップＳ１１２へ移行する。
【００７５】
一方、変更頻度がしきい値を超えるメッシュが存在する場合（ステップＳ１０７肯定）には、高頻度変更領域識別部１４ｄは、隣接するメッシュ同士を連結したメッシュ連結体を矩形に補正する（ステップＳ１０８）。
【００７６】
そして、補正後の矩形、すなわち高頻度変更領域の候補が複数存在する場合（ステップＳ１０９肯定）には、高頻度変更領域識別部１４ｄは、次のような処理を行う。すなわち、高頻度変更領域識別部１４ｄは、複数の高頻度変更領域の候補の距離が所定の値以下である高頻度変更領域の候補同士を含む矩形に合成する（ステップＳ１１０）。なお、高頻度変更領域の候補が複数存在しない場合（ステップＳ１０９否定）には、矩形の合成を行わずにステップＳ１１１へ移行する。
【００７７】
続いて、高頻度変更領域識別部１４ｄは、高頻度変更領域の位置および大きさを特定可能な属性情報をクライアント端末２０へ送信する（ステップＳ１１１）。そして、高頻度変更領域識別部１４ｄは、作業用の内部メモリにマッピングされたメッシュの変更回数をクリアする（ステップＳ１１２）。
【００７８】
その後、高頻度変更領域識別部１４ｄは、画面生成部１４ｂにより生成された更新矩形が作業用の内部メモリに記憶された高頻度変更領域、すなわち第２の画像送信部１４ｇにより動画を送信中の領域に含まれるか否かを判定する（ステップＳ１１３）。
【００７９】
このとき、更新矩形が高頻度変更領域に含まれない場合（ステップＳ１１３否定）には、第１の画像送信部１４ｆは、更新矩形の画像および属性情報をクライアント端末２０へ送信し（ステップＳ１１４）、処理を終了する。
【００８０】
一方、更新矩形が高頻度変更領域に含まれる場合（ステップＳ１１３肯定）には、次のような処理を行う。すなわち、高頻度変更領域識別部１４ｄは、フレームバッファ１３に描画されたビットマップデータのうち高頻度変更領域に対応する部分のビットマップ画像を切り出した上でエンコーダ１４ｅにエンコードさせる（ステップＳ１１５）。そして、エンコーダ１４ｅによりエンコードされた高頻度変更領域のエンコード画像をクライアント端末２０へ送信し（ステップＳ１１６）、処理を終了する。
【００８１】
なお、上記のステップＳ１０４〜ステップＳ１１２までの高頻度更新領域の識別に関する処理は、図８に示したフローとは別処理として動作させることもできる。この場合には、更新矩形の蓄積を開始してから所定の期間が経過する度に処理が起動することになる。
【００８２】
また、上記のステップ１１３〜ステップＳ１１４の処理は、図８に示したフローと別の処理として動作させることもできる。この場合には、画面生成部１４ｂにより更新矩形が生成される度に処理が起動することになる。
【００８３】
また、上記のステップＳ１１５〜ステップＳ１１６の処理は、図８に示したフローと別の処理として動作させることもできる。この場合には、フレームバッファ１３にビットマップデータが描画される度に作業用の内部メモリに高頻度変更領域の属性情報が登録されているか否かが判定される。このとき、高頻度変更領域の属性情報が登録されている場合に処理が起動することになる。
【００８４】
［実施例２の効果］
上述してきたように、本実施例に係るサーバ装置１０では、動画向けの圧縮方式を用いる領域を高頻度変更領域として特定のアプリケーションに依存せずに識別することができる。さらに、本実施例に係るサーバ装置１０では、高頻度変更領域以外の領域については変更があった部分の画像を送信しつつ、高頻度変更領域についてはその領域に対応する画像を動画向けの圧縮方式のデータに圧縮できる。それゆえ、本実施例に係るサーバ装置１０では、クライアント端末２０へ送信する画像のうち操作レスポンスを悪化させる根本となる画像に重点を置いてデータ量を低減できる。これとともに、圧縮処理を行うサーバ装置１０のエンコーダ、復号化処理を行うクライアント端末２０のデコーダの負荷を最小限にできる。
【００８５】
よって、本実施例に係るサーバ装置１０及びシンクライアントシステム３によれば、シンクライアントの汎用性を維持しつつ、操作レスポンスを向上させることが可能である。さらに、本実施例に係るサーバ装置１０及びシンクライアントシステム３では、クライアント端末２０へ送信するデータ量を低減できるので、サーバ装置１０及びクライアント端末２０間での伝送遅延を低減できる。この結果、クライアント端末２０側で表示される画像がコマ落ちする可能性も低減できる。
【００８６】
また、本実施例に係るサーバ装置１０は、複数のメッシュ連結体が存在する場合に、近接する領域の双方を含む領域に変換する。これによって、本実施例に係るサーバ装置１０では、実際に動画が再生される領域の全てで動きがなくとも、動画が再生される領域における一部の動きから動画の再生領域を覆うように高頻度変更領域を形成することが可能である。
【実施例３】
【００８７】
さて、これまで開示の装置に関する実施例について説明したが、本発明は上述した実施例以外にも、種々の異なる形態にて実施されてよいものである。そこで、以下では、本発明に含まれる他の実施例を説明する。
【００８８】
［マップクリアの延長］
例えば、上記の実施例２では、高頻度変更領域識別部１４ｄが更新矩形を蓄積させる周期に合わせて変更頻度判別用のマップをクリアする場合を説明したが、変更頻度判別用のマップをクリアする契機はこれに限定されない。
【００８９】
一例としては、高頻度変更領域識別部１４ｄは、高頻度変更領域として識別した領域において変更頻度がしきい値を超えなくなった後も所定の期間にわたって継続して高頻度変更領域と識別することもできる。
【００９０】
図９Ａ及び図９Ｂは、マップクリアの延長要領を説明するための図である。図９Ａの例では、高頻度変更領域が最初に識別された時点の変更頻度判別用のマップ８０Ａと、その時点の高頻度変更領域の識別結果８１Ａとを図示している。また、図９Ｂの例では、高頻度変更領域が最初に識別されてから所定の期間内である特定の時点の変更頻度判別用のマップ８０Ｂと、その時点の高頻度変更領域の識別結果８１Ａとを図示している。
【００９１】
図９Ａに示すように、マップ８０Ａで変更回数がしきい値を超えるメッシュ連結体が取得されて高頻度変更領域の識別結果８１Ａが得られた場合には、以降に変更回数がしきい値を超えるメッシュ連結体が取得されなくとも識別結果８１Ａを所定の期間引き継ぐ。すなわち、図９Ｂに示すように、マップ８０Ａで変更回数がしきい値を超えるメッシュ連結体が取得されずとも、最初に高頻度変更領域の識別結果８１Ａを識別してから所定の期間内であれば高頻度変更領域の識別結果８１Ａを引き継ぐ。なお、上記の「しきい値」は、サーバ側リモート画面制御用アプリの開発者が段階的に設定した値をエンドユーザに選択させたり、また、エンドユーザが値を直接設定することができる。
【００９２】
これによって、実際に動画が再生される領域において間欠的に動きがなくなった場合でも、高頻度変更領域を断続的に識別することがなくなる結果、高頻度変更領域で画像のコマ落ちが断続的に発生するのを防止できる。さらに、高頻度変更領域の識別結果を引き継ぐことにより高頻度変更領域のサイズ（size）が安定するので、エンコード時のパラメータを初期化する頻度を低減できる結果、エンコーダにかかる負荷を低減することも可能になる。
【００９３】
［高頻度変更領域の縮小の抑制］
他の一例としては、高頻度変更領域識別部１４ｄは、高頻度変更領域として識別した領域が以前に高頻度変更領域と識別した領域よりも縮小した場合に、次のような処理を行う。すなわち、高頻度変更領域識別部１４ｄは、当該縮小した度合いが所定のしきい値以下であるならば、前回の識別時に高頻度変更領域と識別した領域を今回の識別結果として引き継ぐ。
【００９４】
図１０Ａ及び図１０Ｂは、高頻度変更領域の縮小に関する抑制要領を説明するための図である。図１０Ａの例では、時点Ｔ１の変更頻度判別用のマップ９０Ａと高頻度変更領域の識別結果９１Ａとを図示している。また、図１０Ｂの例では、時点Ｔ２の変更頻度判別用のマップ９０Ｂと高頻度変更領域の識別結果９１Ａとを図示している。なお、上記の時点Ｔ１および時点Ｔ２はＴ１＜Ｔ２であるものとする。
【００９５】
図１０Ａに示すように、マップ９０Ａで変更回数がしきい値を超えるメッシュ連結体が取得されて高頻度変更領域の識別結果９１Ａが得られた場合には、時点Ｔ１以降に変更回数が閾値を超えるメッシュ連結体が縮小されても直ちに高頻度変更領域を縮小しない。すなわち、図９Ｂに示すように、変更回数が閾値を超えるメッシュ連結体が斜線の部分について縮小したとしてもその面積が所定のしきい値、例えば半分以下であるならば、高頻度変更領域の識別結果９１Ａを引き継ぐ。
【００９６】
これによって、実際に動画が再生される領域において一部の動きが間欠的になったとしても、高頻度変更領域を断続的に識別することがなくなる結果、高頻度変更領域で画像のコマ落ちが断続的に発生するのを防止できる。さらに、高頻度変更領域の識別結果を引き継ぐことにより高頻度変更領域のサイズが安定するので、エンコード時のパラメータを初期化する頻度を低減できる結果、エンコーダにかかる負荷を低減することも可能になる。
【００９７】
［その他］
また、図示した各装置の各構成要素は、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散・統合の具体的形態は図示のものに限られず、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。
【００９８】
例えば、サーバ装置１０の第１の画像送信部１４ｆ及び第２の画像送信部１４ｇが実行する画像の送信処理を１つの画像送信部に統合することとしてもよい。また、クライアント端末２０の第１の画像受信部２３ｂ及び第２の画像受信部２３ｄが実行する画像の受信処理を１つの画像受信部に統合することとしてもかまわない。さらに、クライアント端末の第１の表示制御部２３ｃ及び第２の表示制御部２３ｆが実行する表示制御処理を１つの表示制御部に統合することとしてもよい。
【００９９】
また、サーバ装置が有する操作情報取得部１４ａ、画面生成部１４ｂ、変更頻度判別部１４ｃ、高頻度変更領域識別部１４ｄ、エンコーダ１４ｅ、第１の画像送信部１４ｆまたは第２の画像送信部１４ｇを次のように構成できる。一例としては、これらの機能部をサーバ装置１０の外部装置としてネットワーク経由で接続するようにしてもよい。他の一例としては、これらの機能部を別の装置がそれぞれ有し、ネットワーク接続されて協働することで、上記のサーバ装置１０の機能を実現するようにしてもよい。同様に、クライアント端末２０が有する操作情報通知部２３ａ、第１の画像受信部２３ｂ、第１の表示制御部２３ｃ、第２の画像受信部２３ｄ、デコーダ２３ｅまたは第２の表示制御部２３ｆを先のように構成できる。
【０１００】
［画像送信プログラム］
また、上記の実施例で説明した各種の処理は、予め用意されたプログラムをパーソナルコンピュータやワークステーションなどのコンピュータで実行することによって実現することができる。そこで、以下では、図１１を用いて、上記の実施例と同様の機能を有する画像送信プログラムを実行するコンピュータの一例について説明する。なお、図１１は、実施例３に係る画像送信プログラムを実行するコンピュータの一例について説明するための図である。また、ここでは、サーバ装置１０と同様の機能を有する画像送信プログラムを実行するコンピュータの例を説明するが、クライアント端末２０と同様の機能を有する画像表示プログラムを実行する場合も同様である。
【０１０１】
図１１に示すように、実施例３におけるコンピュータ１００は、操作部１１０ａと、マイク１１０ｂと、スピーカ１１０ｃと、ディスプレイ１２０と、通信部１３０とを有する。さらに、このコンピュータ１００は、ＣＰＵ１５０と、ＲＯＭ１６０と、ＨＤＤ（Hard Disk Drive）１７０と、ＲＡＭ（Random Access Memory）１８０と有する。これら１１０〜１８０の各部はバス１４０を介して接続される。
【０１０２】
ＲＯＭ１６０には、上記の実施例２で示した操作情報取得部１４ａと、画面生成部１４ｂと、変更頻度判別部１４ｃと同様の機能を発揮する制御プログラムが予め記憶される。さらに、ＲＯＭ１６０には、高頻度変更領域識別部１４ｄと、第１の画像送信部１４ｆと、第２の画像送信部１４ｇと同様の機能を発揮する制御プログラムが予め記憶される。つまり、ＲＯＭ１６０には、図１１に示すように、操作情報取得プログラム１６０ａと、画面生成プログラム１６０ｂと、変更頻度判別プログラム１６０ｃと、高頻度変更領域識別プログラム１６０ｄとが記憶される。さらに、ＲＯＭ１６０には、第１の画像送信プログラム１６０ｅと、第２の画像送信プログラム１６０ｇとが記憶される。これらのプログラム１６０ａ〜１６０ｆについては、図２に示したサーバ装置１０の各構成要素と同様、適宜統合又は分離しても良い。なお、ＲＡＭ１６０に格納される各データは、常に全てのデータがＲＡＭ１６０に格納される必要はなく、処理に必要なデータのみがＲＡＭ１６０に格納されれば良い。
【０１０３】
そして、ＣＰＵ１５０が、これらのプログラム１６０ａ〜１６０ｆをＲＯＭ１６０から読み出して実行する。これにより、ＣＰＵ１５０は、図１１に示すように、各プログラム１６０ａ〜１６０ｄについては、操作情報取得プロセス１５０ａ、画面生成プロセス１５０ｂ及び変更頻度判別プロセス１５０ｃ及び高頻度変更領域識別プロセス１５０ｄとして機能するようになる。さらに、ＣＰＵ１５０は、各プログラム１６０ｅ〜１６０ｆについては、第１の画像送信プロセス１５０ｅ及び第２の画像送信プロセス１５０ｇとして機能するようになる。これらプロセス１５０ａ〜１５０ｆは、図２に示した操作情報取得部１４ａと、画面生成部１４ｂと、変更頻度判別部１４ｃと、高頻度変更領域識別部１４ｄと、第１の画像送信部１４ｆと、第２の画像送信部１４ｇとにそれぞれ対応する。そして、ＣＰＵ１５０は、ＲＡＭ１８０を用いて、画像送信プログラムを実行する。なお、ＣＰＵ１５０上で仮想的に実現される各処理部は、常に全ての処理部がＣＰＵ１５０上で動作する必要はなく、処理に必要な処理部のみが仮想的に実現されれば良い。
【０１０４】
なお、上記した画像送信プログラムについては、必ずしも最初からＨＤＤ１７０やＲＯＭ１６０に記憶させておく必要はない。例えば、コンピュータ１００に挿入されるフレキシブルディスク、いわゆるＦＤ、ＣＤ−ＲＯＭ、ＤＶＤディスク、光磁気ディスク、ＩＣカードなどの「可搬用の物理媒体」に各プログラムを記憶させる。そして、コンピュータ１００がこれらの可搬用の物理媒体から各プログラムを取得して実行するようにしてもよい。また、公衆回線、インターネット、ＬＡＮ、ＷＡＮなどを介してコンピュータ１００に接続される他のコンピュータまたはサーバ装置などに各プログラムを記憶させておき、コンピュータ１００がこれらから各プログラムを取得して実行するようにしてもよい。
【符号の説明】
【０１０５】
１ 情報処理装置
１ａ 画像メモリ
１ｂ 変更頻度判別部
１ｃ 第１の画像送信部
１ｄ 高頻度変更領域識別部
１ｅ 送信停止部
１ｆ 第２の画像送信部
３ シンクライアントシステム
１０ サーバ装置
１１ａ ＯＳ実行制御部
１１ｂ アプリ実行制御部
１２ グラフィックドライバ
１３ フレームバッファ
１４ サーバ側リモート画面制御部
１４ａ 操作情報取得部
１４ｂ 画面生成部
１４ｃ 変更頻度判別部
１４ｄ 高頻度変更領域識別部
１４ｅ エンコーダ
１４ｆ 第１の画像送信部
１４ｇ 第２の画像送信部
２０ クライアント端末
２１ 入力部
２２ 表示部
２３ クライアント側リモート画面制御部
２３ａ 操作情報通知部
２３ｂ 第１の画像受信部
２３ｃ 第１の表示制御部
２３ｄ 第２の画像受信部
２３ｅ デコーダ
２３ｆ 第２の表示制御部
【技術分野】
【０００１】
本発明は、情報処理装置、画像送信プログラム、画像表示プログラム及び画像表示方法に関する。
【背景技術】
【０００２】
シンクライアント（thin client）というシステム（system）が知られている。シンクライアントシステムでは、クライアント（client）に最低限の機能しか持たせず、サーバ（server）でアプリケーション（application）やファイル（file）などのリソース（resource）を管理するようにシステムが構築される。
【０００３】
かかるシンクライアントシステムは、実際にはサーバが処理を実行した処理結果やサーバが保持するデータをクライアントに表示させつつも、あたかもクライアントが主体となって処理を実行したり、データを保持しているかのように振る舞う。
【０００４】
一例として、シンクライアントシステムは、サーバで資料作成やメールなどの業務に関するアプリケーションを実行させ、そのアプリケーションの処理結果をクライアントに表示させる。このような業務アプリの他にも、ＣＡＤ（Computer-Aided Design）などのように精細な画像を扱うアプリケーション、さらには、動画を扱うアプリケーションなどがシンクライアントシステムの適用範囲として拡充されることが求められる。
【０００５】
ところが、シンクライアントシステムで通信に用いられるプロトコル、例えばＲＤＰ（Remote Desktop Protocol）や、ＶＮＣ（Virtual Network Computing）で用いられているＲＦＢ（Remote Frame Buffer）プロトコルなどで、画像や動画などの大容量のデータを扱う場合には、クライアントで実行される操作に対するレスポンス（response）が悪化する問題がある。なお、かかる問題は、シンクライアントシステムでクライアントとサーバ間で画面更新時に大容量のデータ送信が発生する場合に共通するものであり、画像や動画を扱う場合に限定して生じる問題ではない。
【０００６】
このことから、操作レスポンスを改善するための技術の一例として、次のような技術が提案されている。これを説明すると、サーバは、特定のメディアアプリケーション（media application）の出力を途中でフックしてそのメディアプリケーションが扱うデータをクライアントに送信する。一方、クライアントは、サーバで動作するメディアアプリケーションが扱うデータの再生処理を行う。
【先行技術文献】
【特許文献】
【０００７】
【特許文献１】特表２００７−５０５５８０号公報
【発明の概要】
【発明が解決しようとする課題】
【０００８】
しかしながら、上記の従来技術は、特定のメディアアプリケーションに依存した環境でしか効力を発揮できないので、シンクライアントの汎用性を損なうという問題がある。
【０００９】
すなわち、上記の従来技術は、サーバ及びクライアントにインストール（install）されるメディアアプリケーションを改造するか、または予め改造を行ったメディアアプリケーションをプリインストールすることが前提となる。ところが、メディアアプリケーションの入手経路が多種多様である現状では、改造を施すことができるメディアアプリケーションは一部に限られる。このため、その他の大部分のメディアアプリケーションを利用する場合には、依然として、操作レスポンスが悪化したままで利用する他に術はない。
【００１０】
開示の技術は、上記に鑑みてなされたものであって、シンクライアントの汎用性を維持しつつ、操作レスポンスを向上させることができる情報処理装置、画像送信プログラム、画像表示プログラム及び画像表示方法を提供することを目的とする。
【課題を解決するための手段】
【００１１】
本願の開示する情報処理装置は、ネットワーク経由で接続された端末装置の表示部にコンピュータの実行結果を表示するための画像を生成してネットワークへ送信する情報処理装置である。前記情報処理装置は、コンピュータの実行結果を描画する画像を保持する画像メモリを有する。さらに、前記情報処理装置は、前記画像メモリに描画された画像を複数の領域に分割し、前記領域ごとにフレーム間の変更の頻度を判別する変更頻度判別部を有する。さらに、前記情報処理装置は、前記変更のある領域の画像を送信する第１の画像送信部を有する。さらに、前記情報処理装置は、前記変更の頻度がしきい値を超えた領域を高頻度更新領域として識別する高頻度変更領域識別部を有する。さらに、前記情報処理装置は、前記識別した領域について、前記第１の画像送信部での送信を停止する送信停止部を有する。さらに、前記情報処理装置は、前記識別した領域の画像を、前記第１の画像送信部よりも圧縮率の高い動画の圧縮処理を行って送信する第２の画像送信部を有する。
【発明の効果】
【００１２】
本願の開示する情報処理装置の一つの態様によれば、シンクライアントの汎用性を維持しつつ、操作レスポンスを向上させることができるという効果を奏する。
【図面の簡単な説明】
【００１３】
【図１】図１は、実施例１に係る情報処理装置の構成を示すブロック図である。
【図２】図２は、実施例２に係るシンクライアントシステムに含まれる各装置の構成を示すブロック図である。
【図３】図３は、デスクトップ画面の分割要領を説明するための図である。
【図４Ａ】図４Ａは、デスクトップ画面の変更頻度の判別要領を説明するための図である。
【図４Ｂ】図４Ｂは、デスクトップ画面の変更頻度の判別要領を説明するための図である。
【図４Ｃ】図４Ｃは、デスクトップ画面の変更頻度の判別要領を説明するための図である。
【図５】図５は、メッシュ連結体の補正要領を説明するための図である。
【図６】図６は、高頻度変更領域の候補の合成要領を説明するための説明図である。
【図７Ａ】図７Ａは、高頻度変更領域の属性情報の通知要領を説明するための図である。
【図７Ｂ】図７Ｂは、高頻度変更領域の属性情報の通知要領を説明するための図である。
【図７Ｃ】図７Ｃは、高頻度変更領域の属性情報の通知要領を説明するための図である。
【図８】図８は、実施例２に係る画像送信処理の手順を示すフローチャートである。
【図９Ａ】図９Ａは、マップクリアの延長要領を説明するための図である。
【図９Ｂ】図９Ｂは、マップクリアの延長要領を説明するための図である。
【図１０Ａ】図１０Ａは、高頻度変更領域の縮小に関する抑制要領を説明するための図である。
【図１０Ｂ】図１０Ｂは、高頻度変更領域の縮小に関する抑制要領を説明するための図である。
【図１１】図１１は、実施例３に係る画像送信プログラムを実行するコンピュータの一例について説明するための図である。
【発明を実施するための形態】
【００１４】
以下に、本願の開示する情報処理装置、画像送信プログラム、画像表示プログラム及び画像表示方法の実施例を図面に基づいて詳細に説明する。なお、この実施例は開示の技術を限定するものではない。
【実施例１】
【００１５】
図１は、実施例１に係る情報処理装置の構成を示すブロック図である。図１に示す情報処理装置１は、ネットワーク経由で接続された端末装置の表示部にコンピュータの実行結果を表示するための画像を生成してネットワークへ送信するである。図１に示すように、情報処理装置１は、画像メモリ１ａと、変更頻度判別部１ｂと、第１の画像送信部１ｃと、高頻度変更領域識別部１ｄと、送信停止部１ｅと、第２の画像送信部１ｆとを有する。
【００１６】
画像メモリ１ａは、コンピュータの実行結果を描画する画像を保持する。また、変更頻度判別部１ｂは、画像メモリ１ａに描画された画像を複数の領域に分割し、領域ごとにフレーム間の変更の頻度を判別する。また、第１の画像送信部１ｃは、変更のある領域の画像を送信する。
【００１７】
高頻度変更領域識別部１ｄは、変更の頻度がしきい値を超えた領域を高頻度更新領域として識別する。また、送信停止部１ｅは、高頻度変更領域識別部１ｄが高頻度変更領域として識別した領域について、第１の画像送信部１ｃでの送信を停止する。また、第２の画像送信部１ｆは、高頻度変更領域識別部１ｄが高頻度変更領域として識別した領域の画像を、第１の画像送信部１ｃよりも圧縮率の高い動画の圧縮処理を行って送信する。
【００１８】
このため、本実施例に係る情報処理装置１では、動画向けの圧縮方式を用いる領域を高頻度変更領域として特定のアプリケーションに依存せずに識別することができる。さらに、本実施例に係る情報処理装置１では、高頻度変更領域以外の領域については変更があった部分の画像を送信しつつ、高頻度変更領域についてはその領域に対応する画像を動画向けの圧縮方式のデータに圧縮できる。それゆえ、本実施例に係る情報処理装置１では、端末装置へ送信する画像のうち操作レスポンスを悪化させる根本となる画像に重点を置いてデータ量を低減しつつ、圧縮処理を行うエンコーダ、端末装置側で復号化処理を行うデコーダの負荷を最小限にできる。よって、本実施例に係る情報処理装置１によれば、シンクライアントの汎用性を維持しつつ、操作レスポンスを向上させることが可能になる。さらに、本実施例に係る情報処理装置１では、端末装置へ送信するデータ量を低減できるので、情報処理装置及び端末装置間での伝送遅延を低減できる結果、端末装置側で表示される画像がコマ落ちする可能性も低減できる。
【実施例２】
【００１９】
［システム構成］
続いて、実施例２に係るシンクライアントシステムについて説明する。図２は、実施例２に係るシンクライアントシステムに含まれる各装置の構成を示すブロック図である。
【００２０】
図２に示すシンクライアントシステム（thin client system）３は、クライアント（client）端末２０が表示する画面をリモート（remote）でサーバ（server）装置１０に制御させるものである。つまり、シンクライアントシステム３は、実際にはサーバ装置１０が実行した処理結果や保持するデータをクライアント端末２０に表示させつつも、あたかもクライアント端末２０が主体となって処理を実行したり、データを保持しているかのように振る舞う。
【００２１】
図２に示すように、シンクライアントシステム３は、サーバ装置１０と、クライアント端末２０とを有する。なお、図２の例では、１つのサーバ装置１０に対し、１つのクライアント端末を接続する場合を図示したが、任意の数のクライアント端末を接続できる。
【００２２】
これらサーバ装置１０及びクライアント端末２０は、所定のネットワーク（Network）を介して、相互に通信可能に接続される。かかるネットワークには、有線または無線を問わず、インターネット（Internet）、ＬＡＮ（Local Area Network）やＶＰＮ（Virtual Private Network）などの任意の種類の通信網を採用できる。なお、サーバ装置１０及びクライアント端末２０間の通信プロトコル（Protocol）には、一例として、ＶＮＣにおけるＲＦＢ（Remote Frame Buffer）プロトコルを採用する場合を想定する。
【００２３】
サーバ装置１０は、クライアント端末２０に表示させる画面をリモートで制御するサービスを提供するコンピュータ（computer）である。このサーバ装置１０には、サーバ向けのリモート画面制御用のアプリケーション（application）がインストール（install）またはプリインストール（preinstall）される。なお、以下では、サーバ向けのリモート画面制御用のアプリケーションをサーバ側リモート画面制御用アプリと呼ぶ。
【００２４】
このサーバ側リモート画面制御用アプリは、基本機能として、リモート画面制御サービスを提供する機能を有する。一例としては、サーバ側リモート画面制御用アプリは、クライアント端末２０における操作情報を取得した上でその操作により要求された処理を自装置で動作するアプリケーションに実行させる。そして、サーバ側リモート画面制御用アプリは、アプリケーションにより実行された処理結果を表示するための画面を生成した上でその画面をクライアント端末２０へ送信する。このとき、サーバ側リモート画面制御用アプリは、今回の画面生成の前にクライアント端末２０で表示させていたビットマップ画像（bitmap）との間で変更があった部分の画素（pixel）が集まった領域、すなわち更新矩形の画像を送信する。なお、以下では、一例として、更新部分の画像が矩形の画像で形成される場合を説明するが、開示の装置は更新部分の画像が矩形以外の形状で形成される場合にも適用できる。
【００２５】
このほか、サーバ側リモート画面制御用アプリは、フレーム（frame）間で動きが大きい部分のデータを動画向けの圧縮方式のデータに圧縮してクライアント端末２０へ送信する機能も有する。一例としては、サーバ側リモート画面制御用アプリは、アプリケーションにより実行された処理結果から生成した画面を複数の領域に分割し、分割した領域ごとに変更の頻度を監視する。このとき、サーバ側リモート画面制御用アプリは、変更の頻度がしきい値を超えた領域、すなわち高頻度変更領域の属性情報をクライアント端末２０へ送信する。これとともに、サーバ側リモート画面制御用アプリは、高頻度変更領域のビットマップ画像をＭＰＥＧ−２やＭＰＥＧ−４などのＭＰＥＧ方式のデータにエンコード（encode）した上でクライアント端末２０へ送信する。なお、ここでは、ＭＰＥＧ（Moving Picture Experts Group）方式のデータへ圧縮する場合を例示したが、これに限定されない。例えば、動画向けの圧縮方式であれば任意の圧縮符号化方式、例えばＭｏｔｉｏｎ−ＪＰＥＧ（Joint Photographic Experts Group）などを採用できる。
【００２６】
クライアント端末２０は、サーバ装置１０によるリモート画面制御サービスの提供を受ける側のコンピュータである。かかるクライアント端末２０の一例としては、パーソナルコンピュータ（personal computer）など固定端末の他、携帯電話機、ＰＨＳ（Personal Handyphone System）やＰＤＡ（Personal Digital Assistant）などの移動体端末を適用することもできる。このクライアント端末２０には、クライアント向けのリモート画面制御用アプリケーションがインストールまたはプリインストールされる。なお、以下では、クライアント向けのリモート画面制御用のアプリケーションをクライアント側リモート画面制御用アプリと呼ぶ。
【００２７】
このクライアント側リモート画面制御用アプリは、マウス（mouse）やキーボード（keyboard）などの各種の入力デバイス（device）を介して受け付けた操作情報をサーバ装置１０へ通知する機能を有する。一例としては、クライアント側リモート画面制御用アプリは、マウスの左右のクリック（click）を始め、ダブルクリック（double click）やドラッグ（drag）、マウスの移動操作を介して得られたマウスカーソルの移動量などを操作情報として通知する。他の一例としては、マウスホイールの回転量、キーボードのうち押下されたキーの種別なども操作情報として通知する。
【００２８】
さらに、クライアント側リモート画面制御用アプリは、サーバ装置１０から受信した画像を所定の表示部に表示させる機能を有する。一例としては、クライアント側リモート画面制御用アプリは、サーバ装置１０から更新矩形のビットマップ画像を受信した場合には、更新矩形の画像を前回のビットマップ画像から変更のあった位置に合わせて表示する。他の一例としては、クライアント側リモート画面制御用アプリは、サーバ装置１０から高頻度変更領域の属性情報を受信した場合には、その属性情報に含まれる位置に対応する表示画面上の領域をビットマップ画像の表示対象外のブランク（blank）領域とする。その上で、クライアント側リモート画面制御用アプリは、動画向けの圧縮方式のデータを受信した場合にそのデータをデコード（decode）した上でブランク領域に表示する。
【００２９】
［サーバ装置の構成］
次に、本実施例に係るサーバ装置の構成について説明する。図２に示すように、サーバ装置１０は、ＯＳ実行制御部１１ａと、アプリ実行制御部１１ｂと、グラフィックドライバ１２と、フレームバッファ１３と、サーバ側リモート画面制御部１４とを有する。なお、図２の例では、図２に示した機能部以外にも既知のコンピュータが有する各種の機能部、例えば各種の入力デバイスや表示デバイスなどの機能を有するものとする。
【００３０】
ＯＳ実行制御部１１ａは、ＯＳ（Operating System）の実行を制御する処理部である。例えば、ＯＳ実行制御部１１ａは、後述の操作情報取得部１４ａにより取得された操作情報からアプリケーションの起動指示やアプリケーションに対するコマンドを検出する。一例としては、ＯＳ実行制御部１１ａは、アプリケーションのアイコン（icon）上でダブルクリックを検出した場合に、そのアイコンに対応するアプリケーションの起動を後述のアプリ実行制御部１１ｂへ指示する。他の一例としては、起動中のアプリケーションの操作画面、いわゆるウィンドウ（window）上でコマンド（command）の実行を要求する操作を検出した場合に、ＯＳ実行制御部１１ａは、そのコマンドの実行をアプリ実行制御部１１ｂへ指示する。なお、以下では、アプリケーションをアプリと略記する。
【００３１】
アプリ実行制御部１１ｂは、ＯＳ実行制御部１１ａによる指示に基づき、アプリケーションの実行を制御する処理部である。一例としては、アプリ実行制御部１１ｂは、ＯＳ実行制御部１１ａによりアプリの起動が指示された場合や起動中のアプリにコマンドの実行が指示された場合にアプリを動作させる。そして、アプリ実行制御部１１ｂは、アプリを実行することにより得られた処理結果の表示用イメージ（image）をフレームバッファ１３に描画する要求を後述のグラフィックドライバ１２へ行う。このようにグラフィックドライバ１２へ描画要求を行う場合には、アプリ実行制御部１１ｂは、表示用イメージとともに表示用イメージの描画位置をグラフィックドライバ１２へ通知する。
【００３２】
なお、アプリ実行制御部１１ｂが実行するアプリは、プリインストールされたものであってもよく、サーバ装置１０の出荷後にインストールされたものであってもかまわない。また、ＪＡＶＡ（登録商標）などのネットワーク環境で動作するアプリであってもよい。
【００３３】
グラフィックドライバ（graphic driver）１２は、フレームバッファ１３に対する描画処理を実行する処理部である。一例としては、グラフィックドライバ１２は、アプリ実行制御部１１ｂからの描画要求を受け付けた場合に、アプリの処理結果の表示用イメージをアプリにより指定されたフレームバッファ１３上の描画位置へビットマップ形式で描画する。なお、ここでは、アプリにより描画要求を受け付ける場合を説明したが、ＯＳ実行制御部１１ａからの描画要求を受け付けることもできる。一例としては、グラフィックドライバ１２は、ＯＳ実行制御部１１ａからマウスカーソルの描画要求を受け付けた場合に、マウスカーソルの表示用イメージをＯＳにより指定されたフレームバッファ１３上の描画位置へビットマップ形式で描画する。
【００３４】
フレームバッファ（frame buffer）１３は、グラフィックドライバ１２により描画されたビットマップデータを記憶する記憶デバイスである。かかるフレームバッファ１３の一態様としては、ＶＲＡＭ（Video Random Access Memory）を始めとするＲＡＭ（Random Access Memory)、ＲＯＭ（Read Only Memory）やフラッシュメモリ（flash memory）などの半導体メモリ素子が挙げられる。なお、フレームバッファ１３は、ハードディスク、光ディスクなどの記憶装置を採用することとしてもかまわない。
【００３５】
サーバ側リモート画面制御部１４は、サーバ側リモート画面制御用アプリを通じて、リモート画面制御サービスをクライアント端末２０へ提供する処理部である。このサーバ側リモート画面制御部１４は、図２に示すように、操作情報取得部１４ａと、画面生成部１４ｂと、変更頻度判別部１４ｃと、高頻度変更領域識別部１４ｄと、エンコーダ１４ｅと、第１の画像送信部１４ｆと、第２の画像送信部１４ｇとを有する。
【００３６】
操作情報取得部１４ａは、クライアント端末２０から操作情報を取得する処理部である。かかる操作情報の一例としては、マウスの左右のクリックを始め、ダブルクリックやドラッグ、マウスの移動操作を介して得られたマウスカーソルの移動量などが挙げられる。操作情報の他の一例としては、マウスホイールの回転量、キーボードのうち押下されたキーの種別なども挙げられる。
【００３７】
画面生成部１４ｂは、クライアント端末２０の表示部２２に表示させる画面の画像を生成する処理部である。一例としては、画面生成部１４ｂは、グラフィックドライバ１２によりフレームバッファ１３へビットマップデータが格納される度に、次のような処理を起動する。すなわち、画面生成部１４ｂは、前回のフレーム生成時にクライアント端末２０で表示させていたデスクトップ画面と、今回のフレーム生成時にフレームバッファ１３へ書き込まれたデスクトップ画面とを比較する。そして、画面生成部１４ｂは、前回のフレームから変更があった部分の画素をつなげ合わせた上で矩形に整形した更新矩形の画像を生成し、更新矩形送信用のパケットを生成する。
【００３８】
変更頻度判別部１４ｃは、フレームバッファ１３に描画された画像を分割した領域ごとにフレーム間の変更の頻度を判別する処理部である。一例としては、変更頻度判別部１４ｃは、画面生成部１４ｂにより生成された更新矩形を図示しない作業用の内部メモリへ所定の期間にわたって蓄積する。このとき、変更頻度判別部１４ｃは、更新矩形の位置および大きさを特定可能な属性情報、例えば更新矩形の左上の頂点の座標と更新矩形の幅および高さとを蓄積する。かかる更新矩形を蓄積させる期間は、高頻度変更領域を識別する精度と相関関係があり、期間を長くするほど高頻度変更領域の誤検出が低減される。なお、ここでは、一例として、１秒間にわたって更新矩形の画像を蓄積する場合を想定する。
【００３９】
このとき、変更頻度判別部１４ｃは、更新矩形の画像を蓄積してから所定の期間が経過した場合に、クライアント端末２０に表示させるデスクトップ画面をメッシュ（mesh）状に分割したマップ（map）を用いて、デスクトップ画面の変更頻度を判別する。
【００４０】
図３は、デスクトップ画面の分割要領を説明するための図である。図３に示す符号３０は、変更頻度判別用のマップを示す。図３に示す符号３１は、マップ３０に含まれるメッシュを指す。図３に示す符号３２は、メッシュ３１を形成する画素のブロックに含まれる１画素を指す。図３に示す例では、変更頻度判別部１４ｃがマップ３０を占める画素のうち８画素×８画素のブロックを１つのメッシュとして分割する場合を想定している。この場合には、１つのメッシュに６４個の画素が含まれることになる。
【００４１】
ここで、変更頻度判別部１４ｃは、作業用の内部メモリに蓄積した更新矩形の位置および大きさにしたがって更新矩形の画像を変更頻度判別用のマップに順次展開する。そして、変更頻度判別部１４ｃは、更新矩形をマップに展開する度に、マップ上で更新矩形と重なり合った部分のメッシュの変更回数を累積して加算する。このとき、変更頻度更新部１４ｃは、マップ上に展開された更新矩形がメッシュに含まれる画素との間で所定数にわたって重なり合った場合に、そのメッシュの変更回数を１つ加算する。なお、ここでは、更新矩形がメッシュに含まれる画素と１つでも重なり合った場合に、メッシュの変更回数を加算する場合を想定して説明を行う。
【００４２】
図４Ａ〜図４Ｃは、デスクトップ画面の変更頻度の判別要領を説明するための図である。図４Ａ〜図４Ｃに示す符号４０Ａ、符号４０Ｂ及び符号４０Ｎは変更頻度判別用のマップを示す。図４Ａ及び図４Ｂに示す符号４１Ａ及び符号４１Ｂは更新矩形を示す。ここで、マップ４０Ａのメッシュ内に図示した数字は、更新矩形４１Ａが展開された時点におけるメッシュの変更回数を示す。また、マップ４０Ｂのメッシュ内に図示した数字は、更新矩形４１Ｂが展開された時点におけるメッシュの変更回数を示す。さらに、マップ４０Ｎのメッシュ内に図示した数字は、作業用の内部メモリに蓄積した更新矩形が全て展開された時点におけるメッシュの変更回数を示す。なお、図４Ａ〜図４Ｃにおいて数字が図示されていないメッシュは変更回数がゼロであるものとする。
【００４３】
図４Ａに示すように、更新矩形４１Ａがマップ４０Ａに展開された場合には、網掛け部分のメッシュが更新矩形４１Ａと重なり合う。このため、変更頻度判別部１４ｃは、網掛け部分のメッシュの更新回数を１つずつ加算する。この場合には、各メッシュの変更回数はゼロであるため、網掛け部分の変更回数は０から１に加算される。さらに、図４Ｂに示すように、更新矩形４１Ｂがマップ４０Ｂに展開された場合には、網掛け部分のメッシュが更新矩形４１Ｂと重なり合う。このため、変更頻度判別部１４ｃは、網掛け部分のメッシュの更新回数を１つずつ加算する。この場合には、各メッシュの変更回数は１であるため、網掛け部分の変更回数は１から２に加算される。このようにして全ての更新矩形がマップに展開された段階では、図４Ｃに示すマップ４０Ｎの結果が得られる。
【００４４】
そして、変更頻度判別部１４ｃは、作業用の内部メモリに蓄積した更新矩形を全てマップに展開し終えた場合に、所定の期間における変更回数、すなわち変更頻度がしきい値を超えるメッシュを取得する。図４Ｃの例で言えば、しきい値を「４」としたとき、網掛け部分のメッシュが取得されることになる。かかるしきい値は、その値を高く設定するほどデスクトップ画面で動画が表示されている可能性が高い部分を後述のエンコーダ１４ｅによりエンコードできる。なお、上記の「しきい値」は、サーバ側リモート画面制御用アプリの開発者が段階的に設定した値をエンドユーザに選択させたり、また、エンドユーザが値を直接設定することができる。
【００４５】
図２の説明に戻り、高頻度変更領域識別部１４ｄは、クライアント端末２０に表示されるデスクトップ画面のうち高頻度で変更される領域を高頻度変更領域として識別する処理部である。
【００４６】
高頻度変更領域識別部１４ｄは、変更頻度判別部１４ｃにより変更回数がしきい値を超えるメッシュが取得された場合に、隣接するメッシュ同士を連結したメッシュ連結体を矩形に補正する。一例としては、高頻度変更領域識別部１４ｄは、メッシュ連結体に補間する補間領域を導出した上でメッシュ連結体に補間領域を足し合わせることによりメッシュ連結体を矩形に補正する。この補間領域の導出には、メッシュの連結体が最小の補間で矩形に整形される領域を導出するアルゴリズム（algorithm）が適用される。
【００４７】
図５は、メッシュ連結体の補正要領を説明するための図である。図５に示す符号５１は補正前のメッシュ連結体を示す。図５に示す符号５２は補間領域を示す。また、図５に示す符号５３は補正後の矩形を示す。図５に示すように、高頻度変更領域識別部１４ｄは、メッシュ連結体５１に補間領域５２を足し合わせることにより、メッシュ連結体５１を矩形５３に補正する。この段階では、後述の矩形の合成が完了しておらず、矩形５３が未だ高頻度変更領域と確定していないので、補正後の矩形を高頻度変更領域の候補と呼ぶこととする。
【００４８】
高頻度変更領域識別部１４ｄは、高頻度変更領域の候補が複数存在する場合には、複数の高頻度変更領域の候補の距離が所定の値以下である高頻度変更領域の候補同士を含む矩形に合成する。ここで言う高頻度変更領域の候補の距離とは、補正後の矩形の最短距離を指すものとする。一例としては、高頻度変更領域識別部１４ｄは、高頻度変更領域の候補を合成するにあたって各候補の間を埋める補間領域を導出した上で高頻度変更領域の候補に補間領域を足し合わせることにより、高頻度変更領域の候補同士を含む矩形に合成する。この補間領域の導出には、高頻度変更領域の候補の間が最小の補間で合成体に整形される領域を導出するアルゴリズム（algorithm）が適用される。
【００４９】
図６は、高頻度変更領域の候補の合成要領を説明するための説明図である。図６に示す符号６１Ａ及び符号６１Ｂは、高頻度変更領域の候補を指す。図６に示す符号６２は補間領域を指す。図６に示す符号６３は、高頻度変更領域の候補６１Ａ及び高頻度変更領域の候補６１Ｂの合成体を指す。図６に示すように、高頻度変更領域識別部１４ｄは、高頻度変更領域の候補６１Ａ及び高頻度変更領域の候補６１Ｂに補間領域６２を足し合わせることにより、高頻度変更領域の候補６１Ａ及び高頻度変更領域の候補６１Ｂを含む合成体６３へ合成する。そして、高頻度変更領域識別部１４ｄは、このようにして得た合成体を高頻度変更領域と識別する。
【００５０】
このようにして高頻度変更領域を識別すると、高頻度変更領域識別部１４ｄは、高頻度変更領域の位置および大きさを特定可能な属性情報をクライアント端末２０へ送信する。これにより、クライアント端末２０で表示されるデスクトップ画面のビットマップデータのうち高頻度変更領域に対応する部分をブランク表示させる。その後、高頻度変更領域識別部１４ｄは、作業用の内部メモリにマッピングされたメッシュの変更回数をクリア（clear）する。なお、高頻度変更領域識別部１４ｄは、高頻度変更領域の属性情報を作業用の内部メモリに登録する。
【００５１】
図７Ａ〜図７Ｃは、高頻度変更領域の属性情報の通知要領を説明するための図である。図７Ａに示す符号７０Ａは、フレームバッファ１３に描画されたデスクトップ画面の一例を示す。図７Ｂ〜図７Ｃに示す符号７０Ｂ及び符号７０Ｃは、変更頻度判別用のマップを示す。図７Ａに示す符号７１は、ブラウザ（browser）画面を指す。図７Ａに示す符号７２は、動画再生画面を指す。図７Ｂに示す符号７３は、マウスの移動軌跡を示す。図７Ｂに示す符号７４は、アプリによる動画再生領域を示す。
【００５２】
図７Ａに示すように、デスクトップ画面７０Ａには、ブラウザ画面７１及び動画再生画面７２が含まれる。このデスクトップ画面７０Ａから経時的な変化を追った場合には、図７Ｂに示すように、静止画であるブラウザ画面７１の更新矩形は検出されず、マウスの移動軌跡７３および動画再生領域７４に関する更新矩形が検出される。このうち、動画の再生領域７４で変更回数がしきい値を超えるメッシュ、すなわち図示の網掛け部分が高頻度変更領域識別部１４ｄにより識別されたものとする。この場合には、高頻度変更領域識別部１４ｄは、図７Ｃに示す網掛け部分の高頻度変更領域の左上の頂点の座標（ｘ，ｙ）と、高頻度変更領域の幅ｗおよび高さｈとを高頻度変更領域の属性情報としてクライアント端末２０へ送信する。なお、ここでは、高頻度変更領域の位置を特定する点として左上の頂点の座標を採用する場合を説明したが、他の頂点を採用することとしてもかまわない。また、高頻度変更領域の位置を特定することができる点であれば、頂点以外の任意の点、例えば重心などを採用できる。また、ここでは、画面上の左上を座標軸ＸＹの原点とする場合を説明したが、画面内および画面外の任意の点を原点とすることができる。
【００５３】
また、高頻度変更領域識別部１４ｄは、画面生成部１４ｂにより更新矩形が生成される度に、その更新矩形が作業用の内部メモリに記憶された高頻度変更領域、すなわち後述の第２の画像送信部１４ｇにより動画を送信中の領域に含まれるか否かを判定する。このとき、高頻度変更領域識別部１４ｄは、更新矩形が高頻度変更領域に含まれない場合には、更新矩形の画像および属性情報を後述の第１の画像送信部１４ｆに送信させる。一方、高頻度変更領域識別部１４ｄは、更新矩形が高頻度変更領域に含まれる場合には、原則として、後述の第１の画像送信部１４ｆに更新矩形の画像および属性情報を送信させない。なお、更新矩形がＯＳ実行制御部１１ａにより描画されたマウスのものである場合には、マウスに関する更新矩形の画像および属性情報を例外的に送信させることとしてもよい。
【００５４】
また、高頻度変更領域識別部１４ｄは、フレームバッファ１３にビットマップデータが描画される度に、作業用の内部メモリに高頻度変更領域の属性情報が登録されているか否かを判定する。そして、高頻度変更領域識別部１４ｄは、高頻度変更領域の属性情報が登録されている場合に、フレームバッファ１３に描画されたビットマップデータのうち高頻度変更領域に対応する部分のビットマップ画像を切り出した上で後述のエンコーダ１４ｅへ出力する。
【００５５】
エンコーダ１４ｅは、高頻度変更領域識別部１４ｄから入力される高頻度変更領域の画像をエンコードする処理部である。一例としては、エンコーダ１４ｅは、高頻度変更領域識別部１４ｄから入力された高頻度変更領域のビットマップ画像がストリーム（stream）を形成可能なフレーム数に到達した段階で高頻度変更領域のビットマップ画像をエンコードする。なお、エンコード方式の一態様としては、ＭＰＥＧ−２やＭＰＥＧ−４などのＭＰＥＧ方式やＭｏｔｉｏｎ−ＪＰＥＧ方式が挙げられる。
【００５６】
第１の画像送信部１４ｆは、画面生成部１４ｂにより生成された更新矩形の画像および属性情報をクライアント端末２０へ送信する処理部である。この更新矩形を送信する場合の通信プロトコルには、一例としてＶＮＣにおけるＲＦＢプロトコルが採用される。
【００５７】
第２の画像送信部１４ｇは、エンコーダ１４ｅによりエンコードされた高頻度変更領域のエンコード画像をクライアント端末２０へ送信する処理部である。この高頻度変更領域のエンコード画像を送信する場合の通信プロトコルには、一例として、ＲＴＰ（Real-time Transport Protocol）を採用できる。
【００５８】
なお、ＯＳ実行制御部１１ａ、アプリ実行制御部１１ｂ、グラフィックドライバ１２、サーバ側リモート画面制御部１４には、各種の集積回路や電子回路を採用できる。また、サーバ側リモート画面制御部１４に含まれる機能部の一部を別の集積回路や電子回路とすることもできる。例えば、集積回路としては、ＡＳＩＣ（Application Specific Integrated Circuit）やＦＰＧＡ（Field Programmable Gate Array）が挙げられる。また、電子回路としては、ＣＰＵ（Central Processing Unit）やＭＰＵ（Micro Processing Unit）などが挙げられる。
【００５９】
［クライアント端末の構成］
次に、本実施例に係るクライアント端末の構成について説明する。図２に示すように、クライアント端末２０は、入力部２１と、表示部２２と、クライアント側リモート画面制御部２３とを有する。なお、図２の例では、図２に示した機能部以外にも既知のコンピュータが有する各種の機能部、例えば音声出力部などの機能を有するものとする。
【００６０】
入力部２１は、各種の情報、例えば後述のクライアント側リモート画面制御部２３に対する指示入力を受け付ける入力デバイスであり、一例としては、キーボード（keyboard）やマウス（mouse）などを適用できる。なお、後述の表示部２２も、マウスと協働して、ポインティングデバイス（pointing device）機能を実現する。
【００６１】
表示部２２は、各種の情報、例えばサーバ装置１０から送信されたデスクトップ画面などを表示する表示デバイスであり、一例としては、モニタ（monitor）、ディスプレイ（display）やタッチパネル（touch panel）などを適用できる。
【００６２】
クライアント側リモート画面制御部２３は、クライアント側リモート画面制御用アプリを通じて、サーバ装置１０によるリモート画面制御サービスの提供を受ける処理部である。このクライアント側リモート画面制御部２３は、図２に示すように、操作情報通知部２３ａと、第１の画像受信部２３ｂと、第１の表示制御部２３ｃと、第２の画像受信部２３ｄと、デコーダ２３ｅと、第２の表示制御部２３ｆとを有する。
【００６３】
操作情報通知部２３ａは、入力部２１による操作情報をサーバ装置１０へ通知する処理部である。一例としては、操作情報通知部２３ａは、マウスの左右のクリックを始め、ダブルクリックやドラッグ、マウスの移動操作を介して得られたマウスカーソルの移動量などを操作情報として通知する。他の一例としては、操作情報通知部２３ａは、マウスホイールの回転量、キーボードのうち押下されたキーの種別なども操作情報として通知する。
【００６４】
第１の画像受信部２３ｂは、サーバ装置１０の第１の画像送信部１４ｆにより送信された更新矩形の画像および属性情報を受信する処理部である。また、第１の画像受信部２３ｂは、サーバ装置１０の高頻度変更領域識別部１４ｄにより送信された高頻度変更領域の属性情報も受信する。
【００６５】
第１の表示制御部２３ｃは、第１の画像受信部２３ｂにより受信された更新矩形の画像を表示部１１に表示させる処理部である。一例としては、第１の表示制御部２３ｃは、第１の画像受信部２３ｂにより受信された更新矩形の属性情報に含まれる位置および大きさに対応する表示部２２の画面領域に更新矩形のビットマップ画像を表示させる。また、第１の表示制御部２３ｃは、第１の画像受信部２３ｂにより高頻度変更領域の属性情報が受信された場合には、次のような処理を行う。すなわち、第１の表示制御部２３ｃは、高頻度変更領域の属性情報に含まれる高頻度変更領域の位置および大きさに対応する表示部２２の画面領域をビットマップ画像の表示対象外のブランク領域とする。
【００６６】
第２の画像受信部２３ｄは、サーバ装置１０の第２の画像送信部１４ｇにより送信された高頻度変更領域のエンコード画像を受信する処理部である。また、第２の画像受信部２３ｄは、サーバ装置１０の高頻度変更領域識別部１４ｄにより送信された高頻度変更領域の属性情報も受信する。
【００６７】
デコーダ２３ｅは、第２の画像受信部２３ｄにより受信された高頻度変更領域のエンコード画像をデコードする処理部である。なお、デコーダ２３ｅには、サーバ装置１０に搭載されるエンコード方式に適合するデコード方式のデコーダが搭載される。
【００６８】
第２の表示制御部２３ｆは、第１の画像受信部２３ｂにより高頻度変更領域の属性情報に基づき、デコーダ２３ｅによりデコードされた高頻度変更領域のデコード画像を表示部２２に表示させる処理部である。一例としては、第２の表示制御部２３ｆは、高頻度変更領域の属性情報に含まれる高頻度変更領域の位置および大きさに対応する表示部２２の画面領域に高頻度変更領域のデコード画像を表示させる。
【００６９】
なお、クライアント側リモート画面制御部２３には、各種の集積回路や電子回路を採用できる。また、クライアント側リモート画面制御部２３に含まれる機能部の一部を別の集積回路や電子回路とすることもできる。例えば、集積回路としては、ＡＳＩＣ（Application Specific Integrated Circuit）やＦＰＧＡ（Field Programmable Gate Array）が挙げられる。また、電子回路としては、ＣＰＵ（Central Processing Unit）やＭＰＵ（Micro Processing Unit）などが挙げられる。
【００７０】
［処理の流れ］
次に、本実施例に係るシンクライアントシステムの処理の流れについて説明する。図８は、実施例２に係る画像送信処理の手順を示すフローチャートである。この画像送信処理は、サーバ装置１０により実行される処理であり、フレームバッファ１３にビットマップデータが描画された場合に起動する。
【００７１】
図８に示すように、フレームバッファ１３にビットマップデータが描画されると、画面生成部１４ｂは、前回のフレームから変更があった部分の画素をつなげ合わせた上で矩形に整形した更新矩形の画像を生成する（ステップＳ１０１）。そして、画面生成部１４ｂは、先に生成した更新矩形の画像から更新矩形送信用のパケットを生成する（ステップＳ１０２）。
【００７２】
続いて、変更頻度判別部１４ｃは、画面生成部１４ｂにより生成された更新矩形を図示しない作業用の内部メモリへ蓄積する（ステップＳ１０３）。このとき、更新矩形の蓄積を開始してから所定の期間が経過していない場合（ステップＳ１０４否定）には、以降に続く高頻度変更領域の識別に関する処理をとばし、後述のステップＳ１１３へ移行する。
【００７３】
一方、更新矩形の蓄積を開始してから所定の期間が経過した場合（ステップＳ１０４肯定）には、変更頻度判別部１４ｃは、次のような処理を行う。すなわち、変更頻度判別部１４ｃは、作業用の内部メモリに蓄積した更新矩形の位置および大きさにしたがって更新矩形の画像を変更頻度判別用のマップに順次展開する（ステップＳ１０５）。そして、変更頻度判別部１４ｃは、変更頻度判別用のマップに含まれるメッシュのうち変更頻度がしきい値を超えるメッシュを取得する（ステップＳ１０６）。
【００７４】
その後、高頻度変更領域識別部１４ｄは、変更頻度判別部１４ｃにより変更頻度がしきい値を超えるメッシュが取得されたか否かを判定する（ステップＳ１０７）。このとき、変更頻度がしきい値を超えるメッシュが存在しない場合（ステップＳ１０７否定）には、高頻度変更領域がデスクトップ画面に存在しないので、以降に続く高頻度変更領域の識別に関する処理をとばし、ステップＳ１１２へ移行する。
【００７５】
一方、変更頻度がしきい値を超えるメッシュが存在する場合（ステップＳ１０７肯定）には、高頻度変更領域識別部１４ｄは、隣接するメッシュ同士を連結したメッシュ連結体を矩形に補正する（ステップＳ１０８）。
【００７６】
そして、補正後の矩形、すなわち高頻度変更領域の候補が複数存在する場合（ステップＳ１０９肯定）には、高頻度変更領域識別部１４ｄは、次のような処理を行う。すなわち、高頻度変更領域識別部１４ｄは、複数の高頻度変更領域の候補の距離が所定の値以下である高頻度変更領域の候補同士を含む矩形に合成する（ステップＳ１１０）。なお、高頻度変更領域の候補が複数存在しない場合（ステップＳ１０９否定）には、矩形の合成を行わずにステップＳ１１１へ移行する。
【００７７】
続いて、高頻度変更領域識別部１４ｄは、高頻度変更領域の位置および大きさを特定可能な属性情報をクライアント端末２０へ送信する（ステップＳ１１１）。そして、高頻度変更領域識別部１４ｄは、作業用の内部メモリにマッピングされたメッシュの変更回数をクリアする（ステップＳ１１２）。
【００７８】
その後、高頻度変更領域識別部１４ｄは、画面生成部１４ｂにより生成された更新矩形が作業用の内部メモリに記憶された高頻度変更領域、すなわち第２の画像送信部１４ｇにより動画を送信中の領域に含まれるか否かを判定する（ステップＳ１１３）。
【００７９】
このとき、更新矩形が高頻度変更領域に含まれない場合（ステップＳ１１３否定）には、第１の画像送信部１４ｆは、更新矩形の画像および属性情報をクライアント端末２０へ送信し（ステップＳ１１４）、処理を終了する。
【００８０】
一方、更新矩形が高頻度変更領域に含まれる場合（ステップＳ１１３肯定）には、次のような処理を行う。すなわち、高頻度変更領域識別部１４ｄは、フレームバッファ１３に描画されたビットマップデータのうち高頻度変更領域に対応する部分のビットマップ画像を切り出した上でエンコーダ１４ｅにエンコードさせる（ステップＳ１１５）。そして、エンコーダ１４ｅによりエンコードされた高頻度変更領域のエンコード画像をクライアント端末２０へ送信し（ステップＳ１１６）、処理を終了する。
【００８１】
なお、上記のステップＳ１０４〜ステップＳ１１２までの高頻度更新領域の識別に関する処理は、図８に示したフローとは別処理として動作させることもできる。この場合には、更新矩形の蓄積を開始してから所定の期間が経過する度に処理が起動することになる。
【００８２】
また、上記のステップ１１３〜ステップＳ１１４の処理は、図８に示したフローと別の処理として動作させることもできる。この場合には、画面生成部１４ｂにより更新矩形が生成される度に処理が起動することになる。
【００８３】
また、上記のステップＳ１１５〜ステップＳ１１６の処理は、図８に示したフローと別の処理として動作させることもできる。この場合には、フレームバッファ１３にビットマップデータが描画される度に作業用の内部メモリに高頻度変更領域の属性情報が登録されているか否かが判定される。このとき、高頻度変更領域の属性情報が登録されている場合に処理が起動することになる。
【００８４】
［実施例２の効果］
上述してきたように、本実施例に係るサーバ装置１０では、動画向けの圧縮方式を用いる領域を高頻度変更領域として特定のアプリケーションに依存せずに識別することができる。さらに、本実施例に係るサーバ装置１０では、高頻度変更領域以外の領域については変更があった部分の画像を送信しつつ、高頻度変更領域についてはその領域に対応する画像を動画向けの圧縮方式のデータに圧縮できる。それゆえ、本実施例に係るサーバ装置１０では、クライアント端末２０へ送信する画像のうち操作レスポンスを悪化させる根本となる画像に重点を置いてデータ量を低減できる。これとともに、圧縮処理を行うサーバ装置１０のエンコーダ、復号化処理を行うクライアント端末２０のデコーダの負荷を最小限にできる。
【００８５】
よって、本実施例に係るサーバ装置１０及びシンクライアントシステム３によれば、シンクライアントの汎用性を維持しつつ、操作レスポンスを向上させることが可能である。さらに、本実施例に係るサーバ装置１０及びシンクライアントシステム３では、クライアント端末２０へ送信するデータ量を低減できるので、サーバ装置１０及びクライアント端末２０間での伝送遅延を低減できる。この結果、クライアント端末２０側で表示される画像がコマ落ちする可能性も低減できる。
【００８６】
また、本実施例に係るサーバ装置１０は、複数のメッシュ連結体が存在する場合に、近接する領域の双方を含む領域に変換する。これによって、本実施例に係るサーバ装置１０では、実際に動画が再生される領域の全てで動きがなくとも、動画が再生される領域における一部の動きから動画の再生領域を覆うように高頻度変更領域を形成することが可能である。
【実施例３】
【００８７】
さて、これまで開示の装置に関する実施例について説明したが、本発明は上述した実施例以外にも、種々の異なる形態にて実施されてよいものである。そこで、以下では、本発明に含まれる他の実施例を説明する。
【００８８】
［マップクリアの延長］
例えば、上記の実施例２では、高頻度変更領域識別部１４ｄが更新矩形を蓄積させる周期に合わせて変更頻度判別用のマップをクリアする場合を説明したが、変更頻度判別用のマップをクリアする契機はこれに限定されない。
【００８９】
一例としては、高頻度変更領域識別部１４ｄは、高頻度変更領域として識別した領域において変更頻度がしきい値を超えなくなった後も所定の期間にわたって継続して高頻度変更領域と識別することもできる。
【００９０】
図９Ａ及び図９Ｂは、マップクリアの延長要領を説明するための図である。図９Ａの例では、高頻度変更領域が最初に識別された時点の変更頻度判別用のマップ８０Ａと、その時点の高頻度変更領域の識別結果８１Ａとを図示している。また、図９Ｂの例では、高頻度変更領域が最初に識別されてから所定の期間内である特定の時点の変更頻度判別用のマップ８０Ｂと、その時点の高頻度変更領域の識別結果８１Ａとを図示している。
【００９１】
図９Ａに示すように、マップ８０Ａで変更回数がしきい値を超えるメッシュ連結体が取得されて高頻度変更領域の識別結果８１Ａが得られた場合には、以降に変更回数がしきい値を超えるメッシュ連結体が取得されなくとも識別結果８１Ａを所定の期間引き継ぐ。すなわち、図９Ｂに示すように、マップ８０Ａで変更回数がしきい値を超えるメッシュ連結体が取得されずとも、最初に高頻度変更領域の識別結果８１Ａを識別してから所定の期間内であれば高頻度変更領域の識別結果８１Ａを引き継ぐ。なお、上記の「しきい値」は、サーバ側リモート画面制御用アプリの開発者が段階的に設定した値をエンドユーザに選択させたり、また、エンドユーザが値を直接設定することができる。
【００９２】
これによって、実際に動画が再生される領域において間欠的に動きがなくなった場合でも、高頻度変更領域を断続的に識別することがなくなる結果、高頻度変更領域で画像のコマ落ちが断続的に発生するのを防止できる。さらに、高頻度変更領域の識別結果を引き継ぐことにより高頻度変更領域のサイズ（size）が安定するので、エンコード時のパラメータを初期化する頻度を低減できる結果、エンコーダにかかる負荷を低減することも可能になる。
【００９３】
［高頻度変更領域の縮小の抑制］
他の一例としては、高頻度変更領域識別部１４ｄは、高頻度変更領域として識別した領域が以前に高頻度変更領域と識別した領域よりも縮小した場合に、次のような処理を行う。すなわち、高頻度変更領域識別部１４ｄは、当該縮小した度合いが所定のしきい値以下であるならば、前回の識別時に高頻度変更領域と識別した領域を今回の識別結果として引き継ぐ。
【００９４】
図１０Ａ及び図１０Ｂは、高頻度変更領域の縮小に関する抑制要領を説明するための図である。図１０Ａの例では、時点Ｔ１の変更頻度判別用のマップ９０Ａと高頻度変更領域の識別結果９１Ａとを図示している。また、図１０Ｂの例では、時点Ｔ２の変更頻度判別用のマップ９０Ｂと高頻度変更領域の識別結果９１Ａとを図示している。なお、上記の時点Ｔ１および時点Ｔ２はＴ１＜Ｔ２であるものとする。
【００９５】
図１０Ａに示すように、マップ９０Ａで変更回数がしきい値を超えるメッシュ連結体が取得されて高頻度変更領域の識別結果９１Ａが得られた場合には、時点Ｔ１以降に変更回数が閾値を超えるメッシュ連結体が縮小されても直ちに高頻度変更領域を縮小しない。すなわち、図９Ｂに示すように、変更回数が閾値を超えるメッシュ連結体が斜線の部分について縮小したとしてもその面積が所定のしきい値、例えば半分以下であるならば、高頻度変更領域の識別結果９１Ａを引き継ぐ。
【００９６】
これによって、実際に動画が再生される領域において一部の動きが間欠的になったとしても、高頻度変更領域を断続的に識別することがなくなる結果、高頻度変更領域で画像のコマ落ちが断続的に発生するのを防止できる。さらに、高頻度変更領域の識別結果を引き継ぐことにより高頻度変更領域のサイズが安定するので、エンコード時のパラメータを初期化する頻度を低減できる結果、エンコーダにかかる負荷を低減することも可能になる。
【００９７】
［その他］
また、図示した各装置の各構成要素は、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散・統合の具体的形態は図示のものに限られず、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。
【００９８】
例えば、サーバ装置１０の第１の画像送信部１４ｆ及び第２の画像送信部１４ｇが実行する画像の送信処理を１つの画像送信部に統合することとしてもよい。また、クライアント端末２０の第１の画像受信部２３ｂ及び第２の画像受信部２３ｄが実行する画像の受信処理を１つの画像受信部に統合することとしてもかまわない。さらに、クライアント端末の第１の表示制御部２３ｃ及び第２の表示制御部２３ｆが実行する表示制御処理を１つの表示制御部に統合することとしてもよい。
【００９９】
また、サーバ装置が有する操作情報取得部１４ａ、画面生成部１４ｂ、変更頻度判別部１４ｃ、高頻度変更領域識別部１４ｄ、エンコーダ１４ｅ、第１の画像送信部１４ｆまたは第２の画像送信部１４ｇを次のように構成できる。一例としては、これらの機能部をサーバ装置１０の外部装置としてネットワーク経由で接続するようにしてもよい。他の一例としては、これらの機能部を別の装置がそれぞれ有し、ネットワーク接続されて協働することで、上記のサーバ装置１０の機能を実現するようにしてもよい。同様に、クライアント端末２０が有する操作情報通知部２３ａ、第１の画像受信部２３ｂ、第１の表示制御部２３ｃ、第２の画像受信部２３ｄ、デコーダ２３ｅまたは第２の表示制御部２３ｆを先のように構成できる。
【０１００】
［画像送信プログラム］
また、上記の実施例で説明した各種の処理は、予め用意されたプログラムをパーソナルコンピュータやワークステーションなどのコンピュータで実行することによって実現することができる。そこで、以下では、図１１を用いて、上記の実施例と同様の機能を有する画像送信プログラムを実行するコンピュータの一例について説明する。なお、図１１は、実施例３に係る画像送信プログラムを実行するコンピュータの一例について説明するための図である。また、ここでは、サーバ装置１０と同様の機能を有する画像送信プログラムを実行するコンピュータの例を説明するが、クライアント端末２０と同様の機能を有する画像表示プログラムを実行する場合も同様である。
【０１０１】
図１１に示すように、実施例３におけるコンピュータ１００は、操作部１１０ａと、マイク１１０ｂと、スピーカ１１０ｃと、ディスプレイ１２０と、通信部１３０とを有する。さらに、このコンピュータ１００は、ＣＰＵ１５０と、ＲＯＭ１６０と、ＨＤＤ（Hard Disk Drive）１７０と、ＲＡＭ（Random Access Memory）１８０と有する。これら１１０〜１８０の各部はバス１４０を介して接続される。
【０１０２】
ＲＯＭ１６０には、上記の実施例２で示した操作情報取得部１４ａと、画面生成部１４ｂと、変更頻度判別部１４ｃと同様の機能を発揮する制御プログラムが予め記憶される。さらに、ＲＯＭ１６０には、高頻度変更領域識別部１４ｄと、第１の画像送信部１４ｆと、第２の画像送信部１４ｇと同様の機能を発揮する制御プログラムが予め記憶される。つまり、ＲＯＭ１６０には、図１１に示すように、操作情報取得プログラム１６０ａと、画面生成プログラム１６０ｂと、変更頻度判別プログラム１６０ｃと、高頻度変更領域識別プログラム１６０ｄとが記憶される。さらに、ＲＯＭ１６０には、第１の画像送信プログラム１６０ｅと、第２の画像送信プログラム１６０ｇとが記憶される。これらのプログラム１６０ａ〜１６０ｆについては、図２に示したサーバ装置１０の各構成要素と同様、適宜統合又は分離しても良い。なお、ＲＡＭ１６０に格納される各データは、常に全てのデータがＲＡＭ１６０に格納される必要はなく、処理に必要なデータのみがＲＡＭ１６０に格納されれば良い。
【０１０３】
そして、ＣＰＵ１５０が、これらのプログラム１６０ａ〜１６０ｆをＲＯＭ１６０から読み出して実行する。これにより、ＣＰＵ１５０は、図１１に示すように、各プログラム１６０ａ〜１６０ｄについては、操作情報取得プロセス１５０ａ、画面生成プロセス１５０ｂ及び変更頻度判別プロセス１５０ｃ及び高頻度変更領域識別プロセス１５０ｄとして機能するようになる。さらに、ＣＰＵ１５０は、各プログラム１６０ｅ〜１６０ｆについては、第１の画像送信プロセス１５０ｅ及び第２の画像送信プロセス１５０ｇとして機能するようになる。これらプロセス１５０ａ〜１５０ｆは、図２に示した操作情報取得部１４ａと、画面生成部１４ｂと、変更頻度判別部１４ｃと、高頻度変更領域識別部１４ｄと、第１の画像送信部１４ｆと、第２の画像送信部１４ｇとにそれぞれ対応する。そして、ＣＰＵ１５０は、ＲＡＭ１８０を用いて、画像送信プログラムを実行する。なお、ＣＰＵ１５０上で仮想的に実現される各処理部は、常に全ての処理部がＣＰＵ１５０上で動作する必要はなく、処理に必要な処理部のみが仮想的に実現されれば良い。
【０１０４】
なお、上記した画像送信プログラムについては、必ずしも最初からＨＤＤ１７０やＲＯＭ１６０に記憶させておく必要はない。例えば、コンピュータ１００に挿入されるフレキシブルディスク、いわゆるＦＤ、ＣＤ−ＲＯＭ、ＤＶＤディスク、光磁気ディスク、ＩＣカードなどの「可搬用の物理媒体」に各プログラムを記憶させる。そして、コンピュータ１００がこれらの可搬用の物理媒体から各プログラムを取得して実行するようにしてもよい。また、公衆回線、インターネット、ＬＡＮ、ＷＡＮなどを介してコンピュータ１００に接続される他のコンピュータまたはサーバ装置などに各プログラムを記憶させておき、コンピュータ１００がこれらから各プログラムを取得して実行するようにしてもよい。
【符号の説明】
【０１０５】
１ 情報処理装置
１ａ 画像メモリ
１ｂ 変更頻度判別部
１ｃ 第１の画像送信部
１ｄ 高頻度変更領域識別部
１ｅ 送信停止部
１ｆ 第２の画像送信部
３ シンクライアントシステム
１０ サーバ装置
１１ａ ＯＳ実行制御部
１１ｂ アプリ実行制御部
１２ グラフィックドライバ
１３ フレームバッファ
１４ サーバ側リモート画面制御部
１４ａ 操作情報取得部
１４ｂ 画面生成部
１４ｃ 変更頻度判別部
１４ｄ 高頻度変更領域識別部
１４ｅ エンコーダ
１４ｆ 第１の画像送信部
１４ｇ 第２の画像送信部
２０ クライアント端末
２１ 入力部
２２ 表示部
２３ クライアント側リモート画面制御部
２３ａ 操作情報通知部
２３ｂ 第１の画像受信部
２３ｃ 第１の表示制御部
２３ｄ 第２の画像受信部
２３ｅ デコーダ
２３ｆ 第２の表示制御部
【特許請求の範囲】
【請求項１】
ネットワーク経由で接続された端末装置の表示部にコンピュータの実行結果を表示するための画像を生成してネットワークへ送信する情報処理装置であって、
コンピュータの実行結果を描画する画像を保持する画像メモリと、
前記画像メモリに描画された画像を複数の領域に分割し、前記領域ごとにフレーム間の変更の頻度を判別する変更頻度判別部と、
前記変更のある領域の画像を送信する第１の画像送信部と、
前記変更の頻度がしきい値を超えた領域を高頻度更新領域として識別する高頻度変更領域識別部と、
前記識別した領域について、前記第１の画像送信部での送信を停止する送信停止部と、
前記識別した領域の画像を、前記第１の画像送信部よりも圧縮率の高い動画の圧縮処理を行って送信する第２の画像送信部と
を有することを特徴とする情報処理装置。
【請求項２】
前記高頻度変更領域識別部は、複数の領域を識別した際に、近接する領域の双方を含む領域に変換することを特徴とする請求項１に記載の情報処理装置。
【請求項３】
前記高頻度変更領域識別部は、前記高頻度変更領域として識別した領域において前記変更の頻度がしきい値を超えなくなった後も所定の期間にわたって継続して高頻度変更領域と識別することを特徴とする請求項１または２に記載の情報処理装置。
【請求項４】
前記高頻度変更領域識別部は、前記識別した領域が以前に高頻度変更領域と識別した領域よりも縮小した場合に、当該縮小した度合いが所定のしきい値以下であるならば、前回の識別時に高頻度変更領域と識別した領域を今回の識別結果とすることを特徴とする請求項１、２または３に記載の情報処理装置。
【請求項５】
ネットワーク経由で接続された端末装置の表示部にコンピュータの実行結果を表示するための画像を生成してネットワークへ送信する情報処理装置に用いる画像送信プログラムであって、
前記情報処理装置に、
コンピュータの実行結果を描画する画像を保持する画像メモリに描画された画像を複数の領域に分割し、前記領域ごとにフレーム間の変更の頻度を判別する変更頻度判別手順と、
前記変更のある領域の画像を送信する第１の画像送信手順と、
前記変更の頻度がしきい値を超えた領域を高頻度更新領域として識別する高頻度変更領域識別手順と、
前記識別した領域について、前記第１の画像送信部での送信を停止する画像入換手順と、
前記識別した領域の画像を、前記第１の画像送信部よりも圧縮率の高い動画の圧縮処理を行って送信する第２の画像送信手順と
を実行させることを特徴とする画像送信プログラム。
【請求項６】
ネットワーク経由で接続された情報処理装置により生成されたコンピュータの実行結果を表示するための画像を受信し、該受信した画像を自装置の表示部に表示する端末装置に用いる画像表示プログラムであって、
前記端末装置に、
コンピュータの実行結果を描画する画像が分割された複数の領域のうち、フレーム間に変更のある領域の画像を受信する第１の画像受信手順と、
コンピュータの実行結果を描画する画像が分割された複数の領域のうち、フレーム間に変更の頻度がしきい値を超えた領域を対象に前記第１の画像受信手順よりも圧縮率の高い動画の圧縮処理が行われた画像を受信する第２の画像受信手順と、
前記第１の画像受信工程により受信された画像を前記表示部に表示させる第１の表示制御工程と、
前記第２の画像受信工程により受信された画像を復号化した上で前記表示部に表示させる第２の表示制御工程と
を実行させることを特徴とする画像表示プログラム。
【請求項７】
ネットワーク経由で接続された端末装置の表示部にコンピュータの実行結果を表示するための画像を生成してネットワークへ送信する情報処理装置と、前記情報処理装置から前記ネットワークを経由して受信した画像を表示する端末装置とを有する画像表示システムに用いる画像表示方法であって、
前記情報処理装置が、
コンピュータの実行結果を描画する画像を保持する画像メモリに描画された画像を複数の領域に分割し、前記領域ごとにフレーム間の変更の頻度を判別する変更頻度判別工程と、
前記変更のある領域の画像を送信する第１の画像送信工程と、
前記変更の頻度がしきい値を超えた領域を高頻度変更領域として識別する高頻度変更領域識別工程と、
前記識別した領域について、前記第１の画像送信部での送信を停止する送信停止工程と、
前記識別した領域の画像を、前記第１の画像送信部よりも圧縮率の高い動画の圧縮処理を行って送信する第２の画像送信工程とを含み、
前記端末装置が、
前記第１の画像送信工程により送信された画像を前記表示部に表示させる第１の表示制御工程と、
前記第２の画像送信工程により送信された画像を復号化した上で前記表示部に表示させる第２の表示制御工程とを含んだ
ことを特徴とする画像表示方法。
【請求項１】
ネットワーク経由で接続された端末装置の表示部にコンピュータの実行結果を表示するための画像を生成してネットワークへ送信する情報処理装置であって、
コンピュータの実行結果を描画する画像を保持する画像メモリと、
前記画像メモリに描画された画像を複数の領域に分割し、前記領域ごとにフレーム間の変更の頻度を判別する変更頻度判別部と、
前記変更のある領域の画像を送信する第１の画像送信部と、
前記変更の頻度がしきい値を超えた領域を高頻度更新領域として識別する高頻度変更領域識別部と、
前記識別した領域について、前記第１の画像送信部での送信を停止する送信停止部と、
前記識別した領域の画像を、前記第１の画像送信部よりも圧縮率の高い動画の圧縮処理を行って送信する第２の画像送信部と
を有することを特徴とする情報処理装置。
【請求項２】
前記高頻度変更領域識別部は、複数の領域を識別した際に、近接する領域の双方を含む領域に変換することを特徴とする請求項１に記載の情報処理装置。
【請求項３】
前記高頻度変更領域識別部は、前記高頻度変更領域として識別した領域において前記変更の頻度がしきい値を超えなくなった後も所定の期間にわたって継続して高頻度変更領域と識別することを特徴とする請求項１または２に記載の情報処理装置。
【請求項４】
前記高頻度変更領域識別部は、前記識別した領域が以前に高頻度変更領域と識別した領域よりも縮小した場合に、当該縮小した度合いが所定のしきい値以下であるならば、前回の識別時に高頻度変更領域と識別した領域を今回の識別結果とすることを特徴とする請求項１、２または３に記載の情報処理装置。
【請求項５】
ネットワーク経由で接続された端末装置の表示部にコンピュータの実行結果を表示するための画像を生成してネットワークへ送信する情報処理装置に用いる画像送信プログラムであって、
前記情報処理装置に、
コンピュータの実行結果を描画する画像を保持する画像メモリに描画された画像を複数の領域に分割し、前記領域ごとにフレーム間の変更の頻度を判別する変更頻度判別手順と、
前記変更のある領域の画像を送信する第１の画像送信手順と、
前記変更の頻度がしきい値を超えた領域を高頻度更新領域として識別する高頻度変更領域識別手順と、
前記識別した領域について、前記第１の画像送信部での送信を停止する画像入換手順と、
前記識別した領域の画像を、前記第１の画像送信部よりも圧縮率の高い動画の圧縮処理を行って送信する第２の画像送信手順と
を実行させることを特徴とする画像送信プログラム。
【請求項６】
ネットワーク経由で接続された情報処理装置により生成されたコンピュータの実行結果を表示するための画像を受信し、該受信した画像を自装置の表示部に表示する端末装置に用いる画像表示プログラムであって、
前記端末装置に、
コンピュータの実行結果を描画する画像が分割された複数の領域のうち、フレーム間に変更のある領域の画像を受信する第１の画像受信手順と、
コンピュータの実行結果を描画する画像が分割された複数の領域のうち、フレーム間に変更の頻度がしきい値を超えた領域を対象に前記第１の画像受信手順よりも圧縮率の高い動画の圧縮処理が行われた画像を受信する第２の画像受信手順と、
前記第１の画像受信工程により受信された画像を前記表示部に表示させる第１の表示制御工程と、
前記第２の画像受信工程により受信された画像を復号化した上で前記表示部に表示させる第２の表示制御工程と
を実行させることを特徴とする画像表示プログラム。
【請求項７】
ネットワーク経由で接続された端末装置の表示部にコンピュータの実行結果を表示するための画像を生成してネットワークへ送信する情報処理装置と、前記情報処理装置から前記ネットワークを経由して受信した画像を表示する端末装置とを有する画像表示システムに用いる画像表示方法であって、
前記情報処理装置が、
コンピュータの実行結果を描画する画像を保持する画像メモリに描画された画像を複数の領域に分割し、前記領域ごとにフレーム間の変更の頻度を判別する変更頻度判別工程と、
前記変更のある領域の画像を送信する第１の画像送信工程と、
前記変更の頻度がしきい値を超えた領域を高頻度変更領域として識別する高頻度変更領域識別工程と、
前記識別した領域について、前記第１の画像送信部での送信を停止する送信停止工程と、
前記識別した領域の画像を、前記第１の画像送信部よりも圧縮率の高い動画の圧縮処理を行って送信する第２の画像送信工程とを含み、
前記端末装置が、
前記第１の画像送信工程により送信された画像を前記表示部に表示させる第１の表示制御工程と、
前記第２の画像送信工程により送信された画像を復号化した上で前記表示部に表示させる第２の表示制御工程とを含んだ
ことを特徴とする画像表示方法。
【図１】
【図２】
【図３】
【図４Ａ】
【図４Ｂ】
【図４Ｃ】
【図５】
【図６】
【図７Ａ】
【図７Ｂ】
【図７Ｃ】
【図８】
【図９Ａ】
【図９Ｂ】
【図１０Ａ】
【図１０Ｂ】
【図１１】
【図２】
【図３】
【図４Ａ】
【図４Ｂ】
【図４Ｃ】
【図５】
【図６】
【図７Ａ】
【図７Ｂ】
【図７Ｃ】
【図８】
【図９Ａ】
【図９Ｂ】
【図１０Ａ】
【図１０Ｂ】
【図１１】
【公開番号】特開２０１１−２３８０１４（Ｐ２０１１−２３８０１４Ａ）
【公開日】平成２３年１１月２４日（２０１１．１１．２４）
【国際特許分類】
【出願番号】特願２０１０−１０８７９９（Ｐ２０１０−１０８７９９）
【出願日】平成２２年５月１０日（２０１０．５．１０）
【出願人】（０００００５２２３）富士通株式会社 (25,993)
【Ｆターム（参考）】
【公開日】平成２３年１１月２４日（２０１１．１１．２４）
【国際特許分類】
【出願日】平成２２年５月１０日（２０１０．５．１０）
【出願人】（０００００５２２３）富士通株式会社 (25,993)
【Ｆターム（参考）】
[ Back to top ]