(57)【特許請求の範囲】
【請求項１】
ネットワークを介して接続された端末装置に表示させる表示用の画像を記憶する画像メモリと、
ソフトウェアの処理結果を前記画像メモリに描画する描画部と、
前記画像メモリに対する描画が実行された場合に前記画像に更新があった更新領域を検出する更新領域検出部と、
前記更新領域の画像を圧縮する第１の圧縮部と、
前記端末装置との間で確立されるコネクションのウィンドウサイズに収まるデータサイズに前記更新領域の画像の圧縮データを分割する分割部と、
前記コネクションのウィンドウサイズに収まるデータサイズに前記更新領域の画像を圧縮する第２の圧縮部と、
複数のコネクションのうちいずれかのコネクションに前記更新領域の画像の圧縮データが分割された各々の分割データを割り当てるとともに、前記複数のコネクションとは異なる専用コネクションに前記ウィンドウサイズに収まるデータサイズに圧縮された更新領域の画像の圧縮データを割り当てる送信制御部と
を有することを特徴とする情報処理装置。
【請求項２】
所定の期間ごとにコネクションのウィンドウサイズを取得する取得部をさらに有し、
前記第２の圧縮部は、前記取得部によって所定の期間ごとに取得されたコネクションのウィンドウサイズをもとに前記更新領域の画像を圧縮することを特徴とする請求項１に記載の情報処理装置。
【請求項３】
前記送信制御部は、各コネクションにおけるデータ伝送の進捗状態に応じて、分割データを割り当てるコネクションを選択することを特徴とする請求項１または２に記載の情報処理装置。
【請求項４】
前記専用コネクションは、前記端末装置との間で複数確立されるものであって、
前記送信制御部は、各々の専用コネクションに前記ウィンドウサイズに収まるデータサイズに圧縮された更新領域の画像の圧縮データをそれぞれ割り当てることを特徴とする請求項１、２または３に記載の情報処理装置。
【請求項５】
コンピュータが、
ネットワークを介して接続された端末装置に表示させる表示用の画像を記憶する画像メモリに対し、ソフトウェアの処理結果を描画し、
前記画像メモリに対する描画が実行された場合に前記画像に更新があった更新領域を検出し、
前記更新領域の画像を圧縮し、
前記端末装置との間で確立されるコネクションのウィンドウサイズに収まるデータサイズに前記更新領域の画像の圧縮データを分割し、
前記コネクションのウィンドウサイズに収まるデータサイズに前記更新領域の画像を圧縮し、
複数のコネクションのうちいずれかのコネクションに前記更新領域の画像の圧縮データが分割された各々の分割データを割り当てるとともに、前記複数のコネクションとは異なる専用コネクションに前記ウィンドウサイズに収まるデータサイズに圧縮された更新領域の画像の圧縮データを割り当てる
処理を実行することを特徴とする画像送信方法。
【請求項６】
コンピュータに、
ネットワークを介して接続された端末装置に表示させる表示用の画像を記憶する画像メモリに対し、ソフトウェアの処理結果を描画し、
前記画像メモリに対する描画が実行された場合に前記画像に更新があった更新領域を検出し、
前記更新領域の画像を圧縮し、
前記端末装置との間で確立されるコネクションのウィンドウサイズに収まるデータサイズに前記更新領域の画像の圧縮データを分割し、
前記コネクションのウィンドウサイズに収まるデータサイズに前記更新領域の画像を圧縮し、
複数のコネクションのうちいずれかのコネクションに前記更新領域の画像の圧縮データが分割された各々の分割データを割り当てるとともに、前記複数のコネクションとは異なる専用コネクションに前記ウィンドウサイズに収まるデータサイズに圧縮された更新領域の画像の圧縮データを割り当てる
処理を実行させることを特徴とする画像送信プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、情報処理装置、画像送信方法及び画像送信プログラムに関する。
【背景技術】
【０００２】
シンクライアントシステムというシステムが知られている。シンクライアントシステムでは、クライアントに最低限の機能しか持たせず、サーバでアプリケーションやファイルなどのリソースを管理するようにシステムが構成されている。
【０００３】
このようなシンクライアントシステムは、実際にはサーバが処理を実行した処理結果やサーバが保持するデータをクライアントに表示させつつも、あたかもクライアントが主体となって処理を実行しデータを保持しているかのように振る舞う。
【０００４】
一例として、シンクライアントシステムは、サーバで資料作成やメールなどの業務に関するアプリケーションを実行させ、そのアプリケーションの処理結果をクライアントに表示させる。このような業務アプリケーションの他にも、ＣＡＤ（Computer  Aided  Design）などのように精細な画像を扱うアプリケーション、さらには、動画を扱うアプリケーションなどがシンクライアントシステムの適用範囲として拡充されつつある。
【０００５】
また、モバイル端末の高性能化に伴って、デスクトップＰＣ（personal  computer）だけでなく、ノートＰＣやタブレット端末といったモバイル端末をクライアントとしてシンクライアントシステムへ接続したいという需要が高まっている。
【０００６】
ところが、モバイル端末が利用可能な通信ネットワークは、ＬＡＮ（Local  Area  Network）と比較し、通信環境の変化が激しく遅延やパケットロスが発生しやすいので、クライアントサーバ間でデータの伝送遅延による描画遅延が発生する場合がある。
【０００７】
かかる伝送遅延の低減を試みる技術の一例として、次のような情報処理装置が挙げられる。この情報処理装置では、ウェーブレット変換利用時の圧縮単位であるプレシンクト単位で画像を圧縮した後に、各プレシンクトを分解して同一の周波数成分帯ごとに蓄積する。その上で、情報処理装置は、蓄積しておいた画像データを低域成分から順番にパケット化してネットワークへ出力する。これによって、プレシンクト単位でデータを送信する場合と比較し、パケットロスが発生した場合に画質の劣化を抑え、低遅延で伝送することを目指す。
【先行技術文献】
【特許文献】
【０００８】
【特許文献１】特開２００８−２８５４１号公報
【発明の概要】
【発明が解決しようとする課題】
【０００９】
しかしながら、上記の従来技術は、特定のコーデックに依存した環境でしか効力を発揮できないという問題がある。
【００１０】
すなわち、上記の情報処理装置は、１つの画像データを低域成分から高域成分へ向けて段階的に描画可能な構造に変換するものであるが、かかる変換はウェーブレット変換なしには為し得ない。それゆえ、上記の情報処理装置は、あくまでウェーブレット変換を用いる特定のコーデックにしか適用することができず、それ以外のコーデックには適用できない。
【００１１】
なお、上記の問題は、シンクライアントシステムで画面更新時に大容量のデータ伝送がなされる場合に共通する問題であり、サーバ上で動作するアプリケーションが画像や動画を扱う場合に限定して生じる問題ではない。
【００１２】
開示の技術は、上記に鑑みてなされたものであって、特定のコーデックに依存することなく、画質劣化および伝送遅延を抑制できる情報処理装置、画像送信方法及び画像送信プログラムを提供することを目的とする。
【課題を解決するための手段】
【００１３】
本願の開示する情報処理装置は、ネットワークを介して接続された端末装置に表示させる表示用の画像を記憶する画像メモリを有する。さらに、前記情報処理装置は、ソフトウェアの処理結果を前記画像メモリに描画する描画部を有する。さらに、前記情報処理装置は、前記画像メモリに対する描画が実行された場合に前記画像に更新があった更新領域を検出する更新領域検出部を有する。さらに、前記情報処理装置は、前記更新領域の画像を圧縮する第１の圧縮部を有する。さらに、前記情報処理装置は、前記端末装置との間で確立されるコネクションのウィンドウサイズに収まるデータサイズに前記更新領域の画像の圧縮データを分割する分割部を有する。さらに、前記情報処理装置は、前記コネクションのウィンドウサイズに収まるデータサイズに前記更新領域の画像を圧縮する第２の圧縮部を有する。さらに、前記情報処理装置は、複数のコネクションのうちいずれかのコネクションに前記更新領域の画像の圧縮データが分割された各々の分割データを割り当てるとともに、前記複数のコネクションとは異なる専用コネクションに前記ウィンドウサイズに収まるデータサイズに圧縮された更新領域の画像の圧縮データを割り当てる送信制御部を有する。
【発明の効果】
【００１４】
本願の開示する情報処理装置の一つの態様によれば、特定のコーデックに依存することなく、伝送遅延を抑制できるという効果を奏する。
【図面の簡単な説明】
【００１５】
【図１】図１は、実施例１に係るシンクライアントシステムに含まれる各装置の機能的構成を示すブロック図である。
【図２】図２は、実施例１に係るサーバ装置及びクライアント端末間で確立されるマルチコネクションの使用方法について説明するための図である。
【図３】図３は、実施例１に係るサーバ装置が実行する全体処理の手順を示すフローチャートである。
【図４】図４は、実施例１に係る分割処理の手順を示すフローチャートである。
【図５】図５は、実施例１に係る第２の圧縮処理の手順を示すフローチャートである。
【図６】図６は、実施例１に係る送信制御処理の手順を示すフローチャートである。
【図７】図７は、実施例１に係る優先表示決定処理の手順を示すフローチャートである。
【図８】図８は、実施例１及び実施例２に係る画像送信プログラムを実行するコンピュータの一例について説明するための図である。
【発明を実施するための形態】
【００１６】
以下に、本願の開示する情報処理装置、画像送信方法及び画像送信プログラムの実施例を図面に基づいて詳細に説明する。なお、この実施例は開示の技術を限定するものではない。そして、各実施例は、処理内容を矛盾させない範囲で適宜組み合わせることが可能である。
【実施例１】
【００１７】
［システム構成］
まず、本実施例に係るシンクライアントシステムの構成について説明する。図１は、実施例１に係るシンクライアントシステムに含まれる各装置の機能的構成を示すブロック図である。
【００１８】
図１に示すシンクライアントシステム１は、クライアント端末２０が表示するデスクトップ画面をリモートでサーバ装置１０に制御させるものである。つまり、シンクライアントシステム１は、実際にはサーバ装置１０が実行した処理結果や保持するデータをクライアント端末２０に表示させつつも、あたかもクライアント端末２０が主体となって処理を実行したり、データを保持しているかのように振る舞う。
【００１９】
図１に示すように、シンクライアントシステム１は、サーバ装置１０と、クライアント端末２０とを有する。なお、図１の例では、１つのサーバ装置１０に対し、１つのクライアント端末２０を接続する場合を図示したが、任意の数のクライアント端末が接続される場合にも同様に適用できる。
【００２０】
これらサーバ装置１０及びクライアント端末２０は、所定のネットワークを介して、相互に通信可能に接続される。かかるネットワークには、有線または無線を問わず、インターネットやＬＡＮ（Local  Area  Network）やＶＰＮ（Virtual  Private  Network）などの固定端末向けのものに限定されない。例えば、ネットワークには、ＷＡＮ（Wide  Area  Network）やＷｉＭＡＸ（Worldwide  Interoperability  for  Microwave  Access）などのモバイル端末向けの通信網も採用できる。なお、サーバ装置１０及びクライアント端末２０間の通信プロトコルには、一例として、ＶＮＣ（Virtual  Network  Computing）におけるＲＦＢ（Remote  Frame  Buffer）プロトコルを採用する場合を想定する。
【００２１】
サーバ装置１０は、クライアント端末２０に表示させる画面をリモートで制御するサービスを提供するコンピュータである。かかるサーバ装置１０には、サーバ向けのリモート画面制御用のアプリケーションがインストールまたはプリインストールされる。なお、以下では、サーバ向けのリモート画面制御用のアプリケーションのことを「サーバ側のリモート画面制御用アプリ」と記載する場合がある。例えば、サーバ装置１０は、サーバ側のリモート画面制御用アプリがインストールされたＷｅｂサーバとして実装することとしてもよいし、また、リモート画面制御サービスをアウトソーシングによって提供するクラウドとして実装することもできる。
【００２２】
上記のサーバ側のリモート画面制御用アプリは、一例として、リモート画面制御サービスを提供する機能を有する。一態様としては、サーバ側のリモート画面制御用アプリは、クライアント端末２０における操作情報を取得した上でその操作により要求された処理を自装置で動作するアプリケーションに実行させる。そして、サーバ側のリモート画面制御用アプリは、アプリケーションにより実行された処理結果を表示するための画面を生成した上でその画面をクライアント端末２０へ送信する。このとき、サーバ側のリモート画面制御用アプリは、今回の画面生成の前にクライアント端末２０で表示させていたビットマップ画像との間で変更があった部分の画素が集まった領域、すなわち更新矩形の画像を送信する。なお、以下では、一例として、更新部分の画像が矩形の画像で形成される場合を説明するが、開示の装置は更新部分の画像が矩形以外の形状で形成される場合にも適用できる。
【００２３】
クライアント端末２０は、サーバ装置１０によるリモート画面制御サービスの提供を受ける側のコンピュータである。かかるクライアント端末２０の一例としては、パーソナルコンピュータ（personal  computer）など固定端末が挙げられる。他の一例としては、ノートＰＣ（personal  computer）の他、スマートフォン、携帯電話機やＰＨＳ（Personal  Handyphone  System）などの移動体端末、ＰＤＡ（Personal  Digital  Assistant）などのタブレット端末を含むモバイル端末を採用することができる。
【００２４】
クライアント端末２０には、クライアント向けのリモート画面制御用アプリケーションがインストールまたはプリインストールされる。なお、以下では、クライアント向けのリモート画面制御用のアプリケーションのことを「クライアント側のリモート画面制御用アプリ」と記載する場合がある。
【００２５】
上記のクライアント側のリモート画面制御用アプリは、マウスやキーボードなどの各種の入力デバイスを介して受け付けた操作情報をサーバ装置１０へ通知する機能を有する。一例としては、クライアント側のリモート画面制御用アプリは、マウスの左右のクリックを始め、ダブルクリックやドラッグ、マウスの移動操作を介して得られたマウスカーソルの移動量などを操作情報として通知する。他の一例としては、マウスホイールの回転量、キーボードのうち押下されたキーの種別なども操作情報として通知する。なお、ここでは、マウスの操作情報を採取する場合を例示したが、入力デバイスはマウスに限定されない。例えば、タッチパネルが実装されている場合には、タッチパネル上でなされるタップやフリックなどの操作情報を採取することとしてもよい。また、加速度センサ、光センサ、地磁気センサや温度センサなどのユーザの周辺状況および端末へのユーザの動作をセンシング可能なセンサによって採取された情報を操作情報として通知することとしてもよい。
【００２６】
さらに、クライアント側のリモート画面制御用アプリは、サーバ装置１０から受信した画像を所定の表示部に表示させる機能を有する。一態様としては、クライアント側のリモート画面制御用アプリは、サーバ装置１０から更新矩形の画像を受信した場合には、更新矩形の画像を前回のデスクトップ画面から変更のあった位置に合わせて表示する。
【００２７】
ここで、本実施例に係るサーバ装置１０は、クライアント端末２０に表示させる表示用の画像を記憶する画像メモリに対し、ソフトウェアの処理結果を描画する。さらに、本実施例に係るサーバ装置１０は、画像メモリに対する描画が実行された場合に画像に更新があった更新矩形を検出する。そして、本実施例に係るサーバ装置１０は、更新矩形の画像を圧縮した上で、クライアント端末２０との間で確立されるコネクションのウィンドウサイズに収まるデータサイズに更新矩形の画像の圧縮データを分割する。また、本実施例に係るサーバ装置１０は、コネクションのウィンドウサイズに収まるデータサイズに更新矩形の画像を圧縮する。その上で、本実施例に係るサーバ装置１０は、マルチコネクションのうちいずれかのコネクションに更新矩形の画像の圧縮データが分割された各々の分割データを割り当てる。その一方で、本実施例に係るサーバ装置１０は、複数のコネクションとは異なる専用コネクションにウィンドウサイズに収まるデータサイズに圧縮された更新矩形の画像の圧縮データを割り当てる。
【００２８】
このように、本実施例に係るサーバ装置１０では、マルチコネクションを介する経路と、マルチコネクションと異なる専用コネクションを介する経路とを用いて、同一の更新矩形の画像をクライアント端末２０へ重複して送信する。このとき、各々の経路でクライアント端末２０へ送信される更新矩形の画像は、いずれも同一のものであるが、画像の圧縮率はそれぞれ異なる。
【００２９】
このうち、マルチコネクションを介しては、更新矩形の画像の分割データがクライアント端末２０へ並列に送信される。この場合には、更新矩形の画像のデータサイズが大きくとも、コネクションの数を十分に多くすれば、ＡＣＫ（ACKnowledgement）等の確認応答なしに、大量のデータを一度に伝送できる。このため、マルチコネクションを介して送信される更新矩形の画像には、過度な圧縮は必要ない。このようなメリットが得られる反面、マルチコネクションを介してクライアント端末２０へ送信された分割データは、全てが揃うまではクライアント端末２０側で描画できない。つまり、いずれかの分割データにパケットロスが発生すると、パケットロスが発生した分割データが再送されるまで、クライアント端末２０側で更新矩形の画像が描画できない。
【００３０】
このような事態に備えて、本実施例に係るサーバ装置１０では、コネクションのウィンドウサイズに収まるデータサイズに圧縮された更新矩形の画像の圧縮データを専用コネクションを介してクライアント端末２０へ送信させる。かかる専用コネクションを介する場合には、他のデータとの間で待ち合せが発生しない。このため、専用コネクションを介して更新矩形の画像の圧縮データが届きさえすれば、分割データのいずれかにパケットロスが発生しても、再送を待たずに更新矩形の画像の圧縮データをクライアント端末２０に描画させることができる。また、全ての分割データが揃っていれば、マルチコネクションを介して分割して送信される更新矩形の画像の圧縮データの方が、コネクションのウィンドウサイズに収まるまで圧縮された専用コネクション経由の圧縮データよりも画質が良いので、そちらを描画させればよい。
【００３１】
ここで、以下では、マルチコネクションを介して送信される更新矩形の画像の圧縮データよりも画質が低いという意味合いで、コネクションのウィンドウサイズに収まるデータサイズに圧縮された更新矩形の画像の圧縮データのことを「低画質画面データ」と記載する場合がある。また、以下では、低画質画面データよりも画質が高いという意味合いで、マルチコネクションを介して送信される更新矩形の画像の圧縮データのことを「高画質画面データ」と記載する場合がある。
【００３２】
図２は、実施例１に係るサーバ装置及びクライアント端末間で確立されるマルチコネクションの使用方法について説明するための図である。図２の例では、サーバ装置１０及びクライアント端末２０の間には、マルチコネクションＣ１〜Ｃ４と、専用コネクションＣとを含む５つのコネクションが確立されている。なお、図２の例では、５つのコネクションを例示しているが、コネクションの数は図示の数に限定されず、任意の数のコネクションを確立することができる。
【００３３】
図２に示すように、サーバ装置１０は、デスクトップ画面Ｓのうち更新矩形Ｒの画像が更新のあった領域として検出した場合に、更新矩形Ｒの画像を圧縮することによって高画質画面データＨを生成する。そして、サーバ装置１０は、先に生成した高画質画面データＨを４つの分割データＨａ〜Ｈｄへ分割する。これら４つの分割データＨａ〜Ｈｄを生成する一方で、サーバ装置１０は、コネクションのウィンドウサイズに収まるデータサイズに更新矩形Ｒの画像を圧縮することによって低画質画面データＬを生成する。これら高画質画面データＨおよび低画質画面データＬの生成は、所望の圧縮率を得ることができれば任意のコーデックを適用できるので、特定のコーデックに依存しない。
【００３４】
その上で、サーバ装置１０は、マルチコネクションのうちコネクションＣ１に分割データＨａを割り当て、コネクションＣ２に分割データＨｂを割り当て、コネクションＣ３に分割データＨｃを割り当てるとともに、コネクションＣ４に分割データＨｄを割り当てる。一方、サーバ装置１０は、専用コネクションＣに低画質画面データＬを割り当てる。この結果、分割データＨａがコネクションＣ１を介してクライアント端末２０へ送信される。さらに、分割データＨｂがコネクションＣ２を介してクライアント端末２０へ送信される。さらに、分割データＨｃがコネクションＣ３を介してクライアント端末２０へ送信される。さらに、分割データＨｄがコネクションＣ４を介してクライアント端末２０へ送信される。
【００３５】
このように、分割データＨａ〜Ｈｄは、４つのコネクションＣ１〜Ｃ４を介してクライアント端末２０へ並列して送信される。よって、１つのコネクションを用いて更新矩形の画像を伝送する場合よりも、クライアントサーバ間におけるデータの伝送遅延を抑制できる。
【００３６】
さらに、４つの分割データＨａ〜Ｈｄともパケットロスが発生しなかった場合には、高画質画面データＨをクライアント端末２０に描画させることができる。この場合には、サーバ装置１０からクライアント端末２０へデータサイズが大きいデータが伝送された場合でも、クライアント端末２０で高画質のデスクトップ画面を閲覧させることができる。
【００３７】
さらに、たとえ分割データＨａ〜Ｈｄのうちいずれかにパケットロスが発生したとしても、低画質画面データＬが届いてさえいれば、パケットロスが発生した分割データが揃うのを待たずに、低画質画面データＬをクライアント端末２０に描画させることができる。この場合には、高画質画面データＨよりは画質は落ちるものの、更新矩形の画像が不達となる事態は防止でき、伝送遅延が発生するのを抑制できる。このため、クライアント端末２０でなされた操作には応答することができる結果、操作レスポンスが低下するのを抑制できる。
【００３８】
したがって、本実施例に係るサーバ装置１０によれば、特定のコーデックに依存することなく、画質劣化および伝送遅延を抑制できる。
【００３９】
［サーバ装置１０の構成］
次に、本実施例に係るサーバ装置１０の機能的構成について説明する。図１に示すように、サーバ装置１０は、通信Ｉ／Ｆ（interface）部１１と、ＯＳ実行制御部１２と、アプリ実行制御部１３と、グラフィックドライバ１４と、フレームバッファ１５と、リモート画面制御部１６とを有する。なお、サーバ装置１０は、図１に示した機能部以外にも既知のコンピュータが有する各種の機能部、例えば各種の入力デバイスや表示デバイスなどの機能を有するものとする。
【００４０】
通信Ｉ／Ｆ部１１は、他の装置、例えばクライアント端末２０との間で通信制御を行うインタフェースである。かかる通信Ｉ／Ｆ部１１の一態様としては、ＬＡＮカードなどのネットワークインタフェースカードを採用できる。
【００４１】
一態様としては、通信Ｉ／Ｆ部１１は、クライアント端末２０へ送信する画面データやクライアント端末２０から送信される操作情報を送受信する機能を持つ。例えば、通信Ｉ／Ｆ部１１は、クライアント端末２０の通信Ｉ／Ｆ部２３との間に複数のＴＣＰ（Transmission  Control  Protocol）コネクション、いわゆるマルチコネクションを確立した上で維持する。このようにマルチコネクションが維持された環境の下、通信Ｉ／Ｆ部１１は、後述の送信制御部１６ｇから指定を受けたコネクションで画面データの送信を実行する。このように、複数のＴＣＰコネクションを利用することによってデータの伝送量を向上させることができる。
【００４２】
上記のＴＣＰでは、コネクションの確立時にサーバ装置１０及びクライアント端末２０の間でウィンドウと呼ばれるバッファのサイズ、いわゆるウィンドウサイズが互いに授受される。かかるウィンドウサイズの授受によって、データを送信する側の装置は、ＡＣＫ等の確認応答なしに、ウィンドウサイズの範囲内で送信可能なデータ量を操作することができる。データを受信する側の装置からの確認応答がない場合には、データ送信側の装置は、確認応答を受信し、ウィンドウサイズが拡張されるまで、データを送信することはできない。一例として、ここでは、ウィンドウサイズが「64Kbyte」である場合を想定して複数のＴＣＰコネクションを利用することでデータの伝送量を向上可能な理由について以下の説明を行う。
【００４３】
ここで、ＬＡＮ環境のような固定端末向けのネットワークでは、上記のウィンドウサイズが１ＴＣＰコネクションあたりのデータの伝送量を減少させる原因とはならない。なぜならば、ＬＡＮ環境ではサーバ・クライアント間の往復遅延（Round  Trip  Time、以下ＲＴＴと呼称）が少ないため送信側でウィンドウサイズ分のデータ送信を行うより短い時間で、クライアントからの確認応答が受信され、ウィンドウサイズが拡張され続けるためである。ところが、ＬＡＮ環境よりもＲＴＴが大きいＷＡＮ環境のようなモバイル端末向けのネットワークでは、ウィンドウサイズの制約のため１ＴＣＰコネクションあたりに送信可能なデータ転送量が制限されてしまう。例えば、ＲＴＴが「50msec」であるネットワークの場合には、「50msec」の間に「64Kbyte」のデータ伝送しか行えないので、１秒間に１コネクションあたり「1280KByte≒10Mbps」程度しか伝送できないことがわかる。また、このウィンドウサイズはＴＣＰコネクション毎に付与されるパラメータであるため、本条件の場合複数のＴＣＰコネクションを利用するとコネクション毎に「10Mbps」のデータ転送が可能となる。ゆえに、ＲＴＴが大きい環境でも複数のＴＣＰコネクションを利用することで、コネクションの数だけ擬似的にウィンドウサイズを拡張し大量にデータを転送することができる。
【００４４】
ＯＳ実行制御部１２は、ＯＳ（Operating  System）の実行を制御する処理部である。一態様としては、ＯＳ実行制御部１２は、後述の操作情報取得部１６ａにより取得された操作情報からアプリケーションの起動指示やアプリケーションに対するコマンドを検出する。例えば、ＯＳ実行制御部１２は、アプリケーションのアイコン上でダブルクリックやタップを検出した場合に、そのアイコンに対応するアプリケーションの起動を後述のアプリ実行制御部１３へ指示する。また、ＯＳ実行制御部１２は、起動中のアプリケーションの操作画面、いわゆるウィンドウ上でコマンドの実行を要求する操作を検出した場合に、そのコマンドの実行をアプリ実行制御部１３へ指示する。なお、ＯＳ実行制御部１２は、特定のアーキテクチャに依存することなく、任意の種類のＯＳを実行できる。以下では、アプリケーションのことを「アプリ」と記載する場合がある。
【００４５】
アプリ実行制御部１３は、ＯＳ実行制御部１２による指示に基づき、アプリケーションの実行を制御する処理部である。一態様としては、アプリ実行制御部１３は、ＯＳ実行制御部１２によってアプリの起動が指示された場合や起動中のアプリにコマンドの実行が指示された場合にアプリを動作させる。そして、アプリ実行制御部１３は、アプリを実行することにより得られた処理結果の表示用イメージをフレームバッファ１５に描画する要求を後述のグラフィックドライバ１４へ行う。このようにグラフィックドライバ１４へ描画要求を行う場合には、アプリ実行制御部１３は、表示用イメージとともに表示用イメージの描画位置をグラフィックドライバ１４へ通知する。
【００４６】
なお、アプリ実行制御部１３が実行するアプリは、プリインストールされたものであってもよく、サーバ装置１０の出荷後にインストールされたものであってもかまわない。また、ＪＡＶＡ（登録商標）などのネットワーク環境で動作するアプリであってもよい。
【００４７】
グラフィックドライバ１４は、フレームバッファ１５に対する描画処理を実行する処理部である。一態様としては、グラフィックドライバ１４は、アプリ実行制御部１３からの描画要求を受け付けた場合に、アプリの処理結果の表示用イメージをアプリにより指定されたフレームバッファ１５上の描画位置へビットマップ形式で描画する。なお、ここでは、アプリを介して描画要求を受け付ける場合を例示したが、ＯＳ実行制御部１２からの描画要求を受け付けることもできる。例えば、グラフィックドライバ１４は、ＯＳ実行制御部１２からマウスカーソルの描画要求を受け付けた場合に、マウスカーソルの表示用イメージをＯＳにより指定されたフレームバッファ１５上の描画位置へビットマップ形式で描画する。
【００４８】
フレームバッファ１５は、グラフィックドライバ１４によって描画されたビットマップ画像を記憶する記憶デバイスである。かかるフレームバッファ１５の一態様としては、ＶＲＡＭ（Video  Random  Access  Memory）を始めとするＲＡＭ（Random  Access  Memory)、ＲＯＭ（Read  Only  Memory）やフラッシュメモリ（flash  memory）などの半導体メモリ素子が挙げられる。なお、フレームバッファ１５は、ハードディスク、光ディスクなどの記憶装置を採用することとしてもかまわない。
【００４９】
リモート画面制御部１６は、サーバ側のリモート画面制御用アプリを通じて、リモート画面制御サービスをクライアント端末２０へ提供する処理部である。かかるリモート画面制御部１６は、図１に示すように、操作情報取得部１６ａと、更新矩形生成部１６ｂと、第１の圧縮部１６ｃと、分割部１６ｄと、第２の圧縮部１６ｅと、ヘッダ付加部１６ｆと、送信制御部１６ｇとを有する。
【００５０】
操作情報取得部１６ａは、クライアント端末２０から操作情報を取得する処理部である。かかる操作情報の一例としては、マウスの左右のクリックを始め、ダブルクリックやドラッグ、マウスの移動操作を介して得られたマウスカーソルの移動量、マウスホイールの回転量、キーボードのうち押下されたキーの種別などが挙げられる。他の一例としては、クライアント端末２０のタッチパネル上でタップされた座標位置やフリックされた方向や範囲などが挙げられる。
【００５１】
更新矩形生成部１６ｂは、フレームバッファ１５を参照して、更新矩形の画像を生成する処理部である。一態様としては、更新矩形生成部１６ｂは、デスクトップ画面の更新間隔であるフレームレート、例えば３３ｍｓｅｃ（ミリ秒）が経過する度に、次のような処理を起動する。すなわち、更新矩形生成部１６ｂは、前回のフレームでクライアント端末２０に表示させていたデスクトップ画面と、今回のフレームでフレームバッファ１５へ書き込まれたデスクトップ画面とを比較する。そして、更新矩形生成部１６ｂは、前回のフレームから変更があった部分の中で隣接した画素をつなげ合わせた上で矩形に整形した更新矩形の画像を生成する。その上で、更新矩形生成部１６ｂは、同一の更新矩形の画像を後述の第１の圧縮部１６ｃ及び第２の圧縮部１６ｅの両方へ出力する。
【００５２】
第１の圧縮部１６ｃは、所定の圧縮コーデックを適用して、更新矩形生成部１６ｂによって生成された更新矩形の画像を圧縮する処理部である。かかる圧縮処理によって、上述の高画質画面データが生成される。第１の圧縮部１６ｃは、先の圧縮処理によって得られた高画質画面データを分割部１６ｄへ出力する。なお、上記の圧縮コーデックの一例としては、ＪＰＥＧ（Joint  Photographic  Experts  Group）やＰＮＧ（Portable  Network  Graphics）などを採用できる。
【００５３】
分割部１６ｄは、第１の圧縮部１６ｃによる圧縮符号化によって生成された高画質画面データを、クライアント端末２０との間で確立されるコネクションのウィンドウサイズに収まるデータサイズへ分割する処理部である。一態様としては、分割部１６ｄは、第１の圧縮部１６ｃから高画質画面データを受け付けると、高画質画面データがウィンドウサイズ、例えば「64KByte」を超過するか否かを判定する。そして、分割部１６ｄは、高画質画面データがウィンドウサイズを超過する場合に、分割後に各々のデータがウィンドウサイズ以下になるように、高画質画面データを分割する。例えば、分割部１６ｄは、高画質画面データを分割する際に各分割データがウィンドウサイズ未満となる分割数を算出する。その上で、分割部１６ｄは、先に算出した分割数にしたがって高画質画面データをウィンドウサイズ以下のデータサイズへ分割する。その後、分割部１６ｄは、高画質画面データが分割された各々の分割データを後述のヘッダ付加部１６ｆへ出力する。
【００５４】
第２の圧縮部１６ｅは、所定の圧縮コーデックを適用して、コネクションのウィンドウサイズに収まるデータサイズに更新矩形生成部１６ｂによって生成された更新矩形の画像を圧縮する処理部である。かかる圧縮処理によって、上述の低画質画面データが生成される。なお、上記の圧縮コーデックの一例としては、ＪＰＥＧ等の非可逆圧縮コーデックを適用することができる。
【００５５】
ここで、本実施例では、１つのフレームで複数の更新矩形が発生した場合に、全ての更新矩形の画像が圧縮された後のデータサイズの合計がウィンドウサイズ以下になるように圧縮を実行する場合を例示する。例えば、１フレーム内で「100px*100px」の更新矩形Ａと「600px*400px」の更新矩形Ｂが発生した場合を想定し、各更新矩形の面積の比に応じて各更新矩形の圧縮後のデータサイズがウィンドウサイズに占める割合を決定する例を説明する。
【００５６】
一態様としては、第２の圧縮部１６ｅは、１フレーム内で発生した更新矩形をすべて取得するまで待機する。そして、第２の圧縮部１６ｅは、全ての更新矩形の画像を取得すると、更新矩形の画像を形成する領域のサイズ、すなわち面積の合計値を算出する。その上で、第２の圧縮部１６ｅは、各更新矩形の面積の比に応じて各更新矩形への割り当てデータ量を算出する。ここで言う「割り当てデータ量」とは、ウィンドウサイズのうち各更新矩形の圧縮後のデータに割り当てられるデータ量のことを指す。
【００５７】
例えば、上記の例で言えば、領域のサイズの合計値は、「100px*100px+600px*400px=250000px」となる。よって、各更新矩形への割り当てデータ量の比率は、更新矩形Ａが「1/25」、更新矩形Ｂが「24/25」となる。実際の割り当てデータ量は、コネクションのウィンドウサイズに依存する。例えば、ＴＣＰの１コネクションを利用してデータ送信を行うとしたとき、ウィンドウサイズは最大「64Kbyte」である。このため、ウィンドウサイズ「64Kbyte」が更新矩形Ａ及び更新矩形Ｂの面積の比に応じて割り当てられる。すなわち、更新矩形Ａの割り当てデータ量が「64*1/25=2.56KByte」と算出されるとともに、更新矩形Ｂの割り当てデータ量が「64*24/25=61.44KByte」と算出されることとなる。
【００５８】
その後、第２の圧縮部１６ｅは、各更新矩形への割り当てデータ量が所定の閾値以下であるか否かを判定する。かかる閾値は、一定の面積あたりの圧縮データのデータ量、例えば「10000pxあたり2Kbyte」が設定される。このとき、第２の圧縮部１６ｅは、割り当てデータ量が閾値以下である更新矩形が存在する場合には、２４ｂｉｔカラー、いわゆるフルカラーから１６ｂｉｔカラーや８ｂｉｔカラーに減色する減色処理やダウンサンプリング処理、もしくは２つの処理を含む圧縮率の増加処理を実行する。これによって、ＪＰＥＧ等の圧縮符号化方式を適用するだけでなく、より一層のデータ量削減を図る。なお、上記の例で言えば、「10000pxあたり2.56Kbyte」の割り当てが行われているので、減色処理やダウンサンプリング処理は実行されない。そして、第２の圧縮部１６ｅは、各更新矩形の画像に割り当てられたデータ量に収まるように更新矩形の画像を圧縮する。その後、第２の圧縮部１６ｅは、圧縮処理によって得られた低画質画面データをヘッダ付加部１６ｆへ出力する。
【００５９】
なお、ここでは、各更新矩形の面積の比に応じて各更新矩形の圧縮後のデータサイズがウィンドウサイズに占める割合を決定する場合を例示したが、第２の圧縮部１６ｅはこれに限定されない。
【００６０】
ヘッダ付加部１６ｆは、高画質画面データの分割データ及び低画質画面データにヘッダ情報を付加する処理部である。ここで言う「ヘッダ情報」とは、データの画質種類、フレーム番号、領域サイズ、位置、パケット番号、分割パケット番号や終了フラグなどが含まれる。このうち、「データの画質種類」とは、画面データが高画質画面データまたは低画質画面データのいずれの種類であるかを示すコードを示す。また、「フレーム番号」は、デスクトップ画面のフレームを識別する番号を指す。また、「領域サイズ」とは、高画質画面データまたは低画質画面データの面積、あるいは高さ及び幅を指す。また、「位置」とは、高画質画面データまたは低画質画面データの所定の箇所の座標を指し、例えば、更新矩形の画像を形成する頂点や重心の座標を指す。また、「パケット番号」とは、パケットを識別する番号を指し、例えば、パケットのシーケンス番号が挙げられる。また、「分割パケット番号」とは、分割データを識別する番号を指す。また、「終了フラグ」とは、分割データの終了を示すフラグを指し、例えば、クライアント端末２０側で分割データの受信が終了した旨を検出させるために、分割データのうち最大の分割パケット番号を持つ分割データに付与される。
【００６１】
一態様としては、ヘッダ付加部１６ｆは、第２の圧縮部１６ｅから低画質画面データが入力された場合には、データの画質種類、フレーム番号、領域サイズ、位置及びパケット番号を含むヘッダ情報を低画質画面データへ付加する。このとき、データの画質種類には、「低画質画面データ」を示すコードが付加される。また、低画質画面データには、分割パケット番号や終了フラグは付加されない。一方、ヘッダ付加部１６ｆは、分割部１６ｄから高画質画面データの分割データが入力された場合には、データの画質種類、フレーム番号、領域サイズ、位置、パケット番号、分割パケット番号や終了フラグを含むヘッダ情報を高画質画面データの分割データへ付加する。このとき、データの画質種類には、「高画質画面データ」を示すコードが付加される。また、終了フラグは、最大の分割パケット番号を持つ分割データにしか付加されない。その後、ヘッダ付加部１６ｆは、ヘッダ情報を付加した高画質画面データの分割データ及び低画質画面データを送信制御部１６ｇへ出力する。
【００６２】
送信制御部１６ｇは、クライアント端末２０に対するデータの送信制御を実行する処理部である。一態様としては、送信制御部１６ｇは、マルチコネクションのうちいずれかのコネクションに高画質画面データの分割データを割り当てるとともに、専用コネクションに低画質画面データを割り当てる。
【００６３】
具体的には、送信制御部１６ｇは、ヘッダ付加部１６ｆから画面データを受け付けると、当該画面データが高画質画面データであるか否かを判定する。このとき、送信制御部１６ｇは、画面データが高画質画面データである場合には、マルチコネクションのうちいずれか１つのコネクションを選択する。例えば、送信制御部１６ｇは、各コネクション間で送信データ量の偏りが発生しないように、分割データを受け付ける度に異なるコネクションを選択する。また、送信制御部１６ｇは、マルチコネクションの中から１つのコネクションをアトランダムに選択することもできる。一方、送信制御部１６ｇは、画面データが低画質画面データである場合には、専用コネクションを選択する。その後、送信制御部１６ｇは、先に選択したコネクションへ画面データを出力する。これによって、高画質画面データの分割データや低品質画面データがクライアント端末２０へ送信されることになる。
【００６４】
なお、ＯＳ実行制御部１２、アプリ実行制御部１３、グラフィックドライバ１４、リモート画面制御部１６には、各種の集積回路や電子回路を採用できる。また、リモート画面制御部１６に含まれる機能部の一部を別の集積回路や電子回路とすることもできる。例えば、集積回路としては、ＡＳＩＣ（Application  Specific  Integrated  Circuit）やＦＰＧＡ（Field  Programmable  Gate  Array）が挙げられる。また、電子回路としては、ＣＰＵ（Central  Processing  Unit）やＭＰＵ（Micro  Processing  Unit）などが挙げられる。
【００６５】
［クライアント端末２０の構成］
次に、本実施例に係るクライアント端末の機能的構成について説明する。図１に示すように、クライアント端末２０は、入力部２１と、表示部２２と、通信Ｉ／Ｆ部２３と、クライアント側のリモート画面制御部２５とを有する。なお、クライアント端末２０は、図１に示した機能部以外にも既知のコンピュータが有する各種の機能部、例えば音声入力部や音声出力部などの音声デバイス、カメラや各種のセンサ等の機能部を有してもよい。
【００６６】
入力部２１は、各種の情報、例えば後述のクライアント側リモート画面制御部２５に対する指示入力を受け付ける入力デバイスである。一例としては、キーボードやマウスなどを採用できる。このように、マウスが採用される場合には、後述の表示部２２と協働することによって、ポインティングデバイス機能を実現することができる。他の一例としては、後述の表示部２２と協働することによって、入力部２１をタッチパネルとして機能させることもできる。
【００６７】
表示部２２は、各種の情報、例えばサーバ装置１０から送信されたデスクトップ画面などを表示する表示デバイスであり、一例としては、モニタ、ディスプレイやタッチパネルなどを適用できる。なお、表示部２２には、後述のフレームバッファ２７に描画されたビットマップ画像が表示される。
【００６８】
通信Ｉ／Ｆ部２３は、他の装置、例えばサーバ装置１０との間で通信制御を行うインタフェースである。かかる通信Ｉ／Ｆ部２３の一態様としては、ＬＡＮカードなどのネットワークインタフェースカードを採用できる。例えば、通信Ｉ／Ｆ部２３は、サーバ装置１０の通信Ｉ／Ｆ部１１との間にマルチコネクションを確立した上で維持する。このようにマルチコネクションが維持された環境の下、通信Ｉ／Ｆ部２３は、サーバ装置１０から低画質画面データや高画質画面データの分割データを受信する。
【００６９】
リモート画面制御部２５は、クライアント側のリモート画面制御用アプリを通じて、サーバ装置１０によるリモート画面制御サービスの提供を受ける処理部である。このリモート画面制御部２５は、図１に示すように、操作情報通知部２５ａと、受信制御部２５ｂと、優先表示決定部２５ｃとを有する。
【００７０】
操作情報通知部２５ａは、入力部２１による操作情報をサーバ装置１０へ通知する処理部である。一態様としては、操作情報通知部２５ａは、マウスの左右のクリックを始め、ダブルクリック、ドラッグ、マウスの移動操作を介して得られたマウスカーソルの移動量、マウスホイールの回転量やキーボードのうち押下されたキーの種別などを操作情報として通知する。他の一例としては、タッチパネル上でタップされた座標位置やフリックされた方向や範囲などを操作情報として通知する。
【００７１】
受信制御部２５ｂは、サーバ装置１０からのデータの受信制御を実行する処理部である。一態様としては、受信制御部２５ｂは、通信Ｉ／Ｆ部２３から受け付けた画面データを後述の優先表示決定部２５ｃへ出力する。このとき、高画質画面データは、マルチコネクションを介して分割データが受信される。よって、受信制御部２５ｂは、分割データを結合した後に優先表示決定部２５ｃへ出力する。
【００７２】
具体的には、受信制御部２５ｂは、通信Ｉ／Ｆ部２３から受け付けた画面データに付加されたヘッダ情報を参照する。このとき、受信制御部２５ｂは、ヘッダ情報に含まれるデータの画質種類を示すコードが「高画質画面データ」である場合には、ヘッダ情報に終了フラグが書き込まれているか否かをさらに判定する。そして、受信制御部２５ｂは、ヘッダ情報に終了フラグが書き込まれている場合には、分割パケット番号の順番にしたがって各分割データを統合することによって高画質画面データを生成する。その上で、受信制御部２５ｂは、高画質画面データを後述の優先表示決定部２５ｃへ出力する。なお、ヘッダ情報に含まれるデータの画質種類を示すコードが「低画質画面データ」である場合には、低画質画面データが後述の優先表示決定部２５ｃへそのまま出力される。
【００７３】
優先表示決定部２５ｃは、低画質画面データまたは高画質画面データのうち優先して表示させる画面データを決定する処理部である。一態様としては、優先表示決定部２５ｃは、受信制御部２５ｂから受け付けた画面データのフレーム番号とその画質種類を確認する。そして、優先表示決定部２５ｃは、所定の時間、例えば１フレームに相当する３３ｍｓｅｃ以内に最新の高画質画面データを受け付けた場合には、高画質画面データを後述のグラフィックドライバ２６へ出力する。一方、優先表示決定部２５ｃは、所定の時間以内に高画質画面データが到着せず、低画質画面データのみを受け付けた場合には、低画質画面データをグラフィックドライバ２６へ出力する。
【００７４】
具体的には、優先表示決定部２５ｃは、受信制御部２５ｂから画面データを受け付けた場合に、当該画面データに付加されたヘッダ情報のうちデータの画質種類が「高画質画面データ」であるか否かを判定する。このとき、優先表示決定部２５ｃは、データの画質種類が高画質画面データである場合には、ヘッダ情報に含まれるフレーム番号と、図示しない内部メモリに保持する描画予定フレーム番号とをさらに比較する。ここで言う「描画予定フレーム番号」とは、後述のフレームバッファ２７へ描画するべきフレーム番号を表す。かかる描画予定フレーム番号は、同一のフレーム番号を持つ全ての画面データ、すなわち低画質画面データもしくは高画質画面データが後述のフレームバッファ２７へ反映された場合に番号をインクリメントすることによって更新される。例えば、描画予定フレーム番号は、現在「2」のフレーム番号を持つフレームが描画された後には「3」へ更新される。
【００７５】
ここで、優先表示決定部２５ｃは、描画予定フレーム番号が高画質画面データのフレーム番号と同一であるか、もしくは、高画質画面データのフレーム番号＋１である場合には、グラフィックドライバ２６に当該高画質画面データをフレームバッファ２７へ反映させる。これは、高画質画面データが低画質画面データより先に到着した場合、もしくは低画質画面データが描画されていた場合に低画質画面データを高画質画面データで上書きする場合を想定している。一方、優先表示決定部２５ｃは、描画予定フレーム番号が高画質画面データのフレーム番号と同一でなく、かつ高画質画面データのフレーム番号＋１でもない場合には、当該高画質画面データを描画させずに破棄する。
【００７６】
また、優先表示決定部２５ｃは、データの画質種類が「低画質画面データ」である場合には、所定の期間にわたって高画質画面データが受け付けられるのを待機する。これによって、描画遅延が生じない範囲で高画質画面データを待ち合せる。その上で、優先表示決定部２５ｃは、低画質画面データのヘッダ情報に含まれるフレーム番号と、図示しない内部メモリに保持する描画予定フレーム番号とをさらに比較する。このとき、優先表示決定部２５ｃは、描画予定フレーム番号が低画質画面データのフレーム番号と同一である場合には、グラフィックドライバ２６に当該低画質画面データをフレームバッファ２７へ反映させる。これは、所定の期間、例えば３３ｍｓｅｃ後に高画質画面データが描画されていない場合のみ、低画質画面データを描画することを想定している。一方、優先表示決定部２５ｃは、描画予定フレーム番号が低画質画面データのフレーム番号と同一でない場合には、低画質画面データを描画させずに破棄する。
【００７７】
グラフィックドライバ２６は、フレームバッファ２７に対する描画処理を実行する処理部である。一態様としては、グラフィックドライバ２６は、優先表示決定部２５ｃからの描画指示を受け付けた場合に、画面データのヘッダ情報に含まれる位置により指定されたフレームバッファ２７上の描画位置へ当該画面データをビットマップ形式で描画する。
【００７８】
フレームバッファ２７は、グラフィックドライバ２６によって描画されたビットマップ画像を記憶する記憶デバイスである。かかるフレームバッファ２７の一態様としては、ＶＲＡＭを始めとするＲＡＭ、ＲＯＭやフラッシュメモリなどの半導体メモリ素子が挙げられる。なお、フレームバッファ２７は、ハードディスク、光ディスクなどの記憶装置を採用することとしてもかまわない。
【００７９】
なお、クライアント側のリモート画面制御部２５には、各種の集積回路や電子回路を採用できる。また、リモート画面制御部２５に含まれる機能部の一部を別の集積回路や電子回路とすることもできる。例えば、集積回路としては、ＡＳＩＣやＦＰＧＡが挙げられる。また、電子回路としては、ＣＰＵやＭＰＵなどが挙げられる。
【００８０】
［処理の流れ］
次に、本実施例に係るシンクライアントシステムの処理の流れについて説明する。なお、ここでは、サーバ装置１０が実行する（１）全体処理を説明した後に、サブルーチンとして実行される（２）分割処理、（３）第２の圧縮処理、（４）送信制御処理の順に説明し、最後に、クライアント端末２０が実行する（５）優先表示決定処理を説明することとする。
【００８１】
（１）全体処理
図３は、実施例１に係るサーバ装置１０が実行する全体処理の手順を示すフローチャートである。この全体処理は、サーバ装置１０及びクライアント端末２０の間でマルチコネクションが確立されている限り、繰り返し実行される処理である。
【００８２】
図３に示すように、フレームバッファ１５に記憶されたデスクトップ画面に更新があった場合（ステップＳ１０１肯定）には、更新矩形生成部１６ｂは、前回のフレームから変更があった部分の画素の中で隣接する差分をつなげ合わせた上で矩形に整形した更新矩形の画像を生成する（ステップＳ１０２）。
【００８３】
そして、第１の圧縮部１６ｃは、所定の圧縮コーデックを適用して、更新矩形生成部１６ｂによって生成された更新矩形の画像を圧縮する第１の圧縮処理を実行する（ステップＳ１０３Ａ）。
【００８４】
続いて、分割部１６ｄは、第１の圧縮部１６ｃによる圧縮符号化によって生成された高画質画面データを、クライアント端末２０との間で確立されるコネクションのウィンドウサイズに収まるデータサイズへ分割する（ステップＳ１０４Ａ）。
【００８５】
一方、第２の圧縮部１６ｅは、所定の圧縮コーデックを適用して、コネクションのウィンドウサイズに収まるデータサイズに更新矩形生成部１６ｂによって生成された更新矩形の画像を圧縮する第２の圧縮処理を実行する（ステップＳ１０３Ｂ）。
【００８６】
その後、ヘッダ付加部１６ｆは、分割部１６ｄによって高画質画面データが分割された分割データ及び第２の圧縮部１６ｅによる圧縮符号化によって生成された低画質画面データにヘッダ情報を付加する（ステップＳ１０５）。
【００８７】
そして、送信制御部１６ｇは、マルチコネクションのうちいずれかのコネクションに高画質画面データの分割データを割り当てるとともに、専用コネクションに低画質画面データを割り当てる送信制御処理を実行する（ステップＳ１０６）。
【００８８】
これらステップＳ１０１〜ステップＳ１０６の処理は、サーバ装置１０及びクライアント端末２０の間でマルチコネクションが確立されている限り、繰り返し実行される。
【００８９】
なお、図３に示したフローチャートのうちステップＳ１０３Ａ及びステップＳ１０４Ａの処理とステップＳ１０３Ｂの処理とは、並列して実行することもできるし、いずれかを先または後に実行することもできる。
【００９０】
（２）分割処理
図４は、実施例１に係る分割処理の手順を示すフローチャートである。この分割処理は、図３に示したステップＳ１０４Ａに対応する処理である。図４に示すように、第１の圧縮部１６ｃから高画質画面データを受け付けると（ステップＳ２０１肯定）、分割部１６ｄは、高画質画面データがウィンドウサイズ、例えば「64KByte」を超過するか否かを判定する（ステップＳ２０２）。
【００９１】
そして、高画質画面データがウィンドウサイズを超過する場合（ステップＳ２０２肯定）には、分割部１６ｄは、分割後に各々のデータがウィンドウサイズ以下になるように、高画質画面データを分割する（ステップＳ２０３）。その後、分割部１６ｄは、高画質画面データが分割された各々の分割データをヘッダ付加部１６ｆへ出力する（ステップＳ２０４）。
【００９２】
一方、高画質画面データがウィンドウサイズ以下である場合（ステップＳ２０２否定）には、分割部１６ｄは、高画質画面データの分割を行わずに、そのまま高画質画面データをヘッダ付加部１６ｆへ出力する（ステップＳ２０４）。
【００９３】
（３）第２の圧縮処理
図５は、実施例１に係る圧縮処理の手順を示すフローチャートである。この第２の圧縮処理は、図３に示したステップＳ１０３Ｂに対応する処理である。図５に示すように、第２の圧縮部１６ｅは、１フレーム内で発生した更新矩形をすべて取得するまで（ステップＳ３０１否定）、以降の処理を待機する。
【００９４】
そして、全ての更新矩形の画像を取得すると（ステップＳ３０１肯定）、第２の圧縮部１６ｅは、更新矩形の画像を形成する領域のサイズ、すなわち面積の合計値を算出する（ステップＳ３０２）。その上で、第２の圧縮部１６ｅは、各更新矩形の面積の比に応じて各更新矩形への割り当てデータ量を算出する（ステップＳ３０３）。
【００９５】
その後、第２の圧縮部１６ｅは、各更新矩形の割り当てデータ量が所定の閾値以下であるか否かを判定する（ステップＳ３０４）。このとき、割り当てデータ量が閾値以下である更新矩形が存在する場合（ステップＳ３０４肯定）には、第２の圧縮部１６ｅは、次のような処理を実行する。すなわち、第２の圧縮部１６ｅは、２４ｂｉｔカラー、いわゆるフルカラーから１６ｂｉｔカラーや８ｂｉｔカラーに減色する減色処理、ダウンサンプリング処理、もしくは２つの処理を含む圧縮率の増加処理を実行する（ステップＳ３０５）。
【００９６】
一方、各更新矩形の割り当てデータ量が所定の閾値を超えている場合（ステップＳ３０４否定）には、減色処理やダウンサンプリング処理を実行せずに、ステップＳ３０６へ移行する。
【００９７】
その後、第２の圧縮部１６ｅは、各更新矩形の画像に割り当てられたデータ量に収まるように更新矩形の画像を圧縮する（ステップＳ３０６）。そして、第２の圧縮部１６ｅは、圧縮処理によって得られた低画質画面データをヘッダ付加部１６ｆへ出力する（ステップＳ３０７）。
【００９８】
（４）送信制御処理
図６は、実施例１に係る送信制御処理の手順を示すフローチャートである。この送信制御処理は、図３に示したステップＳ１０６に対応する処理である。図６に示すように、ヘッダ付加部１６ｆから画面データを受け付けると（ステップＳ４０１肯定）、送信制御部１６ｇは、当該画面データが高画質画面データであるか否かを判定する（ステップＳ４０２）。
【００９９】
このとき、画面データが高画質画面データである場合（ステップＳ４０２肯定）には、送信制御部１６ｇは、マルチコネクションのうちいずれか１つのコネクションを選択する（ステップＳ４０３）。一方、画面データが低画質画面データである場合（ステップＳ４０２否定）には、送信制御部１６ｇは、専用コネクションを選択する（ステップＳ４０４）。
【０１００】
その後、送信制御部１６ｇは、ステップＳ４０３またはステップＳ４０４で選択したコネクションへ画面データを出力する（ステップＳ４０５）。これによって、高画質画面データの分割データや低品質画面データがクライアント端末２０へ送信されることになる。
【０１０１】
（５）優先表示決定処理
図７は、実施例１に係る優先表示決定処理の手順を示すフローチャートである。この優先表示決定処理は、サーバ装置１０及びクライアント端末２０の間でマルチコネクションが確立されている限り、繰り返し実行される処理である。
【０１０２】
図７に示すように、受信制御部２５ｂから画面データを受け付けた場合（ステップＳ５０１肯定）に、優先表示決定部２５ｃは、当該画面データに付加されたヘッダ情報のうちデータの画質種類が「高画質画面データ」であるか否かを判定する（ステップＳ５０２）。
【０１０３】
このとき、データの画質種類が高画質画面データである場合（ステップＳ５０２肯定）には、優先表示決定部２５ｃは、ヘッダ情報に含まれるフレーム番号と、図示しない内部メモリに保持する描画予定フレーム番号とをさらに比較する（ステップＳ５０３）。
【０１０４】
ここで、描画予定フレーム番号が高画質画面データのフレーム番号と同一であるか、もしくは、高画質画面データのフレーム番号＋１である場合（ステップＳ５０４肯定）には、優先表示決定部２５ｃは、グラフィックドライバ２６に当該高画質画面データをフレームバッファ２７へ反映させる（ステップＳ５０５）。
【０１０５】
一方、描画予定フレーム番号が高画質画面データのフレーム番号と同一でなく、かつ高画質画面データのフレーム番号＋１でもない場合（ステップＳ５０４否定）には、優先表示決定部２５ｃは、当該高画質画面データを描画させずに破棄する（ステップＳ５０６）。
【０１０６】
また、データの画質種類が「低画質画面データ」である場合（ステップＳ５０２否定）には、優先表示決定部２５ｃは、所定の期間にわたって高画質画面データが受け付けられるのを待機する（ステップＳ５０７）。
【０１０７】
その上で、優先表示決定部２５ｃは、低画質画面データのヘッダ情報に含まれるフレーム番号と、図示しない内部メモリに保持する描画予定フレーム番号とをさらに比較する（ステップＳ５０８）。
【０１０８】
このとき、描画予定フレーム番号が低画質画面データのフレーム番号と同一である場合（ステップＳ５０９肯定）には、優先表示決定部２５ｃは、グラフィックドライバ２６に当該低画質画面データをフレームバッファ２７へ反映させる（ステップＳ５０５）。
【０１０９】
一方、描画予定フレーム番号が低画質画面データのフレーム番号と同一でない場合（ステップＳ５０９否定）には、優先表示決定部２５ｃは、低画質画面データを描画させずに破棄する（ステップＳ５１０）。
【０１１０】
［実施例１の効果］
上述してきたように、本実施例に係るサーバ装置１０は、マルチコネクションの利用によって遅延やパケットロス率の大きいネットワーク上でのデータ伝送量を向上させる。さらに、本実施例に係るサーバ装置１０は、複数のコネクションに対して高画質画面データを分割して送信するとともに低画質画面データを専用コネクションで送信する。したがって、本実施例に係るサーバ装置１０によれば、特定のコーデックに依存することなく、画質劣化および伝送遅延を抑制することが可能である。
【実施例２】
【０１１１】
さて、これまで開示の装置に関する実施例について説明したが、本発明は上述した実施例以外にも、種々の異なる形態にて実施されてよいものである。そこで、以下では、本発明に含まれる他の実施例を説明する。
【０１１２】
［応用例１］
例えば、開示の装置は、所定の期間ごとに取得されたコネクションのウィンドウサイズをもとに更新領域の画像を圧縮するようにしてもよい。例えば、サーバ装置１０の通信Ｉ／Ｆ部１１で利用されているウィンドウサイズを取得し、これを第２の圧縮部１６ｅで使用されている割り当てデータ量として利用する。これによって、より正確に１コネクションで一度に送信可能な低画質画面データを生成してもよい。
【０１１３】
すなわち、上記の実施例１では、第２の圧縮部１６ｅが使用する割り当てデータ量として、ＴＣＰの最大ウィンドウサイズである「64Kbyte」が用いられる場合を説明した。しかし、実際の通信環境においては、ウィンドウサイズが一定であることはまれであり、ウィンドウサイズは常に変動している。このため、割り当てサイズを固定して用いると、実際のウィンドウサイズと低画質画面データのデータサイズに差が発生し、一度に画面データをすべて送信することができないケースが生じる可能性もある。
【０１１４】
このことから、開示の装置では、現在に通信Ｉ／Ｆ部１１で使用されているウィンドウサイズを取得し、第２の圧縮部１６ｅの割り当てデータ量として利用する。これによって、実際のウィンドウサイズとの差を可能な限り抑制したより正確な低画質画面データを生成可能となる。例えば、開示の装置では、１秒に１回程度すべてのコネクションのウィンドウサイズを取得した上で、これらの最小値を割り当てデータ量として利用する。これによって、通信環境が悪化しウィンドウサイズが変化した場合でも、低画質画面データが素早くクライアント端末２０へ到達できる可能性が高くなる。
【０１１５】
［応用例２］
また、開示の装置は、各コネクションにおけるデータ伝送の進捗状態に応じて、高画質画面データの分割データを割り当てるコネクションを選択することもできる。例えば、サーバ装置１０の送信制御部１６ｇにおいて利用している各コネクションの通信状態を検出し、高画質画面データの送信時にコネクションを選択する際に、データ送信がすでに終了している、もしくは終了に最も近いコネクションを選択しても良い。
【０１１６】
すなわち、上記の実施例１では、分割された高画質画面データを送信する際に利用するコネクションを順次切り替えて使用する。しかし、各コネクションは必ずしも同じ時間間隔で送信が終了するとは限らず、ケースによっては、後から送信を始めたコネクションによる送信が先に終了してしまい、効率良く送信できない場合もある。
【０１１７】
このことから、開示の装置は、送信制御部１６ｇにおいて各コネクションの通信状態を検出し、高画質画面データの送信時にデータ送信が終了している、もしくは終了に最も近いコネクションを選択する。これによって、データ送信の際に最も素早く送信可能なコネクションでデータ送信が可能となる。例えば、開示の装置は、高画質画面データ送信用の複数のコネクションに対して送信コネクション候補キューの作成および管理を行う。各コネクションは一定間隔ごとに通信状態がチェックされ、その際にキュー順序が更新される。キュー順序は、送信終了コネクション、ＡＣＫ待ちコネクション、送信中コネクションの順序でソートされる。その上で、開示の装置は、送信終了コネクション、ＡＣＫ待ちコネクション、送信中コネクションの順に優先して高画質画面データを割り当てればよい。
【０１１８】
［応用例３］
例えば、開示の装置は、クライアント端末２０との間で複数の専用コネクションを確立し、各々の専用コネクションにウィンドウサイズに収まるデータサイズに圧縮された低画質画面データをそれぞれ割り当てることとしてもよい。このように、低画質画面データを送信する経路を増やすことによって、低画質画面データがパケットロスなしにクライアント端末２０へ到着する可能性を向上させることができる。
【０１１９】
［応用例４］
また、開示の装置は、低画質データを優先して送信するようにデータの送信順序を並べ替えることもできる。たとえば、サーバ装置１０の送信制御部１６ｇにおいて通知されたデータの画質種類とフレーム番号をチェックし、あるフレーム内において低画質データを分割された高画質データに優先して送信しても良い。
【０１２０】
すなわち、上記の実施例１では、分割された高画質データと低画質データの送信順序を定めていないため、低画質データの送信が分割された高画質データの後になってしまう場合が想定される。しかし、ＲＴＴの大きな通信路では利用可能な帯域が少ない場合も多く、その場合次フレームが生成されるまでの間に全てのデータが送信できず、低画質・高画質データ両方の送信が遅延し、クライアントでの描画遅延が発生してしまう。
【０１２１】
このことから、開示の装置は、送信制御部１６ｇにおいてある１フレーム内での低画質データを分割された高画質データより先に送信する。当処理部が分割された高画質データを先に受け取った場合、これの送信を保留し低画質データの受け取り・送信を行った後にこれを送信する。
【０１２２】
［応用例５］
上記の実施例１では、各更新矩形の面積の比に応じて各更新矩形の圧縮後のデータサイズがウィンドウサイズに占める割合を決定する場合を例示したが、開示の装置はこれに限定されない。一例として、開示の装置は、全ての更新矩形を包含する領域の画像を１つの更新矩形とみなし、当該更新矩形の画像のデータサイズがウィンドウサイズ以下になるように圧縮を実行するようにしてもかまわない。例えば、更新矩形生成部１６ｂは、全ての更新矩形を包含する更新矩形を１つ生成して第２の圧縮部１６ｅへ出力する。そして、第２の圧縮部１６ｅは、更新矩形生成部１６ｂから出力された１つの更新矩形をウィンドウサイズ以下に圧縮する。これによって１つの更新矩形から低画質画面データを生成できる。
【０１２３】
［分散および統合］
また、図示した各装置の各構成要素は、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散・統合の具体的形態は図示のものに限られず、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。
【０１２４】
［画像送信プログラム］
また、上記の実施例で説明した各種の処理は、予め用意されたプログラムをパーソナルコンピュータやワークステーションなどのコンピュータで実行することによって実現することができる。そこで、以下では、図８を用いて、上記の実施例と同様の機能を有する画像送信プログラムを実行するコンピュータの一例について説明する。
【０１２５】
図８は、実施例１及び実施例２に係る画像送信プログラムを実行するコンピュータの一例について説明するための図である。図８に示すように、コンピュータ１００は、操作部１１０ａと、スピーカ１１０ｂと、カメラ１１０ｃと、ディスプレイ１２０と、通信部１３０とを有する。さらに、このコンピュータ１００は、ＣＰＵ１５０と、ＲＯＭ１６０と、ＨＤＤ１７０と、ＲＡＭ１８０とを有する。これら１１０〜１８０の各部はバス１４０を介して接続される。
【０１２６】
ＨＤＤ１７０には、図８に示すように、上記の実施例１で示したリモート画面制御部１６と同様の機能を発揮する画像送信プログラム１７０ａが予め記憶される。この画像送信プログラム１７０ａについては、図１に示した各々のリモート画面制御部１６の各構成要素と同様、適宜統合又は分離しても良い。すなわち、ＨＤＤ１７０に格納される各データは、常に全てのデータがＨＤＤ１７０に格納される必要はなく、処理に必要なデータのみがＨＤＤ１７０に格納されれば良い。
【０１２７】
そして、ＣＰＵ１５０が、画像送信プログラム１７０ａをＨＤＤ１７０から読み出してＲＡＭ１８０に展開する。これによって、図８に示すように、画像送信プログラム１７０ａは、画像送信プロセス１８０ａとして機能する。この画像送信プロセス１８０ａは、ＨＤＤ１７０から読み出した各種データを適宜ＲＡＭ１８０上の自身に割り当てられた領域に展開し、この展開した各種データに基づいて各種処理を実行する。なお、画像送信プロセス１８０ａは、図１に示したリモート画面制御部１６にて実行される処理、例えば図３〜図７に示す処理を含む。また、ＣＰＵ１５０上で仮想的に実現される各処理部は、常に全ての処理部がＣＰＵ１５０上で動作する必要はなく、処理に必要な処理部のみが仮想的に実現されれば良い。
【０１２８】
なお、上記の画像送信プログラム１７０ａについては、必ずしも最初からＨＤＤ１７０やＲＯＭ１６０に記憶させておく必要はない。例えば、コンピュータ１００に挿入されるフレキシブルディスク、いわゆるＦＤ、ＣＤ−ＲＯＭ、ＤＶＤディスク、光磁気ディスク、ＩＣカードなどの「可搬用の物理媒体」に各プログラムを記憶させる。そして、コンピュータ１００がこれらの可搬用の物理媒体から各プログラムを取得して実行するようにしてもよい。また、公衆回線、インターネット、ＬＡＮ、ＷＡＮなどを介してコンピュータ１００に接続される他のコンピュータまたはサーバ装置などに各プログラムを記憶させておき、コンピュータ１００がこれらから各プログラムを取得して実行するようにしてもよい。
【符号の説明】
【０１２９】
１    シンクライアントシステム
１０    サーバ装置
１１    通信Ｉ／Ｆ部
１２    ＯＳ実行制御部
１３    アプリ実行制御部
１４    グラフィックドライバ
１５    フレームバッファ
１６    リモート画面制御部
１６ａ  操作情報取得部
１６ｂ  更新矩形生成部
１６ｃ  第１の圧縮部
１６ｄ  分割部
１６ｅ  第２の圧縮部
１６ｆ  ヘッダ付加部
１６ｇ  送信制御部
２０    クライアント端末
２１    入力部
２２    表示部
２３    通信Ｉ／Ｆ部
２５    リモート画面制御部
２５ａ  操作情報通知部
２５ｂ  受信制御部
２５ｃ  優先表示決定部
２６    グラフィックドライバ
２７    フレームバッファ
【図１】
0005895671.tif 000002
【図２】
0005895671.tif 000003
【図３】
0005895671.tif 000004
【図４】
0005895671.tif 000005
【図５】
0005895671.tif 000006
【図６】
0005895671.tif 000007
【図７】
0005895671.tif 000008
【図８】
0005895671.tif 000009