情報処理装置、画像送信プログラム、画像送信方法および画像表示方法
【課題】データ転送量を削減することを課題とする。
【解決手段】情報処理装置は、画像を保持する第１の画像メモリと、送信済みの画像を保持する第２の画像メモリとを有する。また、情報処理装置は、第１の画像メモリの保持される画像を端末装置へ送信する第１の画像送信部と、前記画像を基準画像と差分画像とを組み合わせて送信する第２の画像送信部を有する。この第２の画像送信部は、第１の画像送信部から第２の画像送信部に送信を切り換える際に、第２の画像メモリに保持された画像を基準画像に設定し、基準画像を基に、第１の画像メモリに保持された画像から差分画像を生成する。そして、第２の画像送信部は、基準画像を端末装置に送信済みの画像から取得する信号と共に差分画像を送信する。
【解決手段】情報処理装置は、画像を保持する第１の画像メモリと、送信済みの画像を保持する第２の画像メモリとを有する。また、情報処理装置は、第１の画像メモリの保持される画像を端末装置へ送信する第１の画像送信部と、前記画像を基準画像と差分画像とを組み合わせて送信する第２の画像送信部を有する。この第２の画像送信部は、第１の画像送信部から第２の画像送信部に送信を切り換える際に、第２の画像メモリに保持された画像を基準画像に設定し、基準画像を基に、第１の画像メモリに保持された画像から差分画像を生成する。そして、第２の画像送信部は、基準画像を端末装置に送信済みの画像から取得する信号と共に差分画像を送信する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、情報処理装置、画像送信プログラム、画像送信方法および画像表示方法に関する。
【背景技術】
【０００２】
シンクライアントというシステムが知られている。シンクライアントシステムでは、クライアントに最低限の機能しか持たせず、サーバでアプリケーションやファイルなどのリソースを管理するようにシステムが構築される。
【０００３】
かかるシンクライアントシステムは、実際にはサーバが処理を実行した処理結果やサーバが保持するデータをクライアントに表示させつつも、あたかもクライアントが主体となって処理を実行したり、データを保持しているかのように振る舞う。このシンクライアントシステムで通信に用いられるプロトコルには、例えばＲＤＰ（Remote Desktop Protocol）や、ＶＮＣ（Virtual Network Computing）で用いられているＲＦＢ（Remote Frame Buffer）プロトコルなどがある。
【０００４】
シンクライアントシステムでは、文章作成アプリケーションやＷｅｂブラウザだけでなく、ＣＡＤ（Computer-Aided Design）アプリケーションも利用できる。ＣＡＤアプリケーションでは、基盤の配線や３Ｄモデルの作成をワイヤフレームとよばれるデータで処理が実行される。そして、データによってはより詳細な描画データを作成するレンダリングと呼ばれる作業や、ワイヤフレームを様々な角度から眺めて不具合やおかしな部分や全体を検査するといった作業が行われる。そのため、ＣＡＤアプリケーションなどをシンクライアントシステム上で利用する場合には大量のデータを転送することが要求される。
【０００５】
このようなアプリケーションを利用する場合、全ての画面データをそのままの形で転送すると数１００Ｍｂｉｔｓ／秒のネットワークの帯域幅を消費してしまう。そのため、画面データを転送する場合には圧縮処理を行った上でデータを転送する。圧縮処理を行う場合には、画質とデータ量のトレードオフによって特定時間あたりのデータ量を変化させる。
【０００６】
しかし、利用可能なネットワーク帯域は常に一定ではなく時間帯や接続しているネットワーク自体においても増減が発生する。さらに、利用するアプリケーションによって必要とするネットワーク帯域幅が異なるため、単純に一つの圧縮方式と特定の画質設定に応じて圧縮や転送を行った場合、必要なネットワーク帯域幅が足りずに圧縮画面データを転送できないといった問題が発生する。また、利用可能なネットワーク帯域幅を十分に利用できずに画像品質を向上できないといった問題が発生する。なお、かかる問題は、シンクライアントシステムでクライアントとサーバ間で画面更新時に大容量のデータ送信が発生する場合に共通するものであり、画像や動画を扱う場合に限定して生じる問題ではない。
【０００７】
このことから、サーバとクライアント間におけるデータ転送量を削減し、操作レスポンスを改善する技術が開示されている。一例として、ディスプレイ画面のデータを転送する場合に現在利用可能なネットワークの帯域幅に応じて圧縮率の異なる画像圧縮方式を適用することで、転送量を最適化する技術が存在する。この技術では、利用可能な帯域幅が少ない場合には、画面データを不可逆圧縮方式で圧縮することで画像品質を削減することと引き替えに、必要なデータ転送量を大きく削減する。逆に、利用可能な帯域幅が大きい場合には、可逆圧縮方式での圧縮や非圧縮で画像データを転送することで、膨大な帯域幅を消費しつつも高品質の画像データを転送する。このように、この技術は、ネットワーク帯域幅の状況に応じて切り替えることで、適切な転送量と画質を維持している。
【先行技術文献】
【特許文献】
【０００８】
【特許文献１】特表２００７−５０５５８０号公報
【発明の概要】
【発明が解決しようとする課題】
【０００９】
しかしながら、従来の技術では、データ転送量が大きいという問題があった。
【００１０】
例えば、ある時点において画面データを画像として圧縮および転送しており、ネットワーク帯域や利用アプリの変化によって、次の時点で動画データとして画面データを圧縮おおび転送する処理に切り替わった場合を想定する。この場合、動画データとして画面データを圧縮する際には、画像によって圧縮された画面データに対する次の更新が発生した画面から圧縮が行われる。
【００１１】
しかし、画像で圧縮された画面（以下、前フレームという）と、動画で圧縮された画面（以下、後フレームという）の間では全ての領域で無関係に更新が行われているということはまれで、前フレームと後フレームのデータは似通っているという関係がある。動画だけでの圧縮の場合、一般的にこの関係を利用し、差分データのみを含むフレーム（以下、Ｐフレームという）の送信を行い、少ないデータ量での表示を実現している。ところが、従来技術の場合、このような差分データによるデータ更新は行われず、差分データの元になる対象領域の全データを含むフレーム（以下、Ｉフレームという）から動画データが生成され、画面データとして圧縮および転送が行われる。
【００１２】
例えば、画像データで転送を行った前フレームと動画データで転送を行った後フレームのデータは似通っているにもかかわらず、動画データ中でＩフレームとして圧縮および送信されてしまうため、重複したデータの転送が発生している。すなわち、データ転送量の大きい静止画を重複して送信することになり、データ転送量が削減できているとは言い難い。
【００１３】
開示の技術は、上記に鑑みてなされたものであって、データ転送量を削減できる情報処理装置、画像送信プログラム、画像送信方法および画像表示方法を提供することを目的とする。
【課題を解決するための手段】
【００１４】
本願の開示する情報処理装置は、一つの態様において、前記画像を保持する第１の画像メモリと、前記画像を前記端末装置へ送信する第１の画像送信部とを有する。また、開示する情報処理装置は、前記第１の画像送信部で送信した画像を保持する第２の画像メモリと、前記画像を基準画像と差分画像とを組み合わせて送信する第２の画像送信部とを有する。また、開示する情報処理装置の第２の画像送信部は、前記第１の画像送信部から前記第２の画像送信部に送信を切り換える際に、前記第２の画像メモリに保持された画像を前記基準画像に設定し、前記基準画像を基に、前記第１の画像メモリに保持された画像から前記差分画像を生成する。そして、開示する情報処理装置の第２の画像送信部は、前記基準画像を端末装置に送信済みの画像から取得する信号と共に前記差分画像を送信する。
【発明の効果】
【００１５】
本願の開示する情報処理装置、画像送信プログラム、画像送信方法および画像表示方法の一つの態様によれば、画像品質の劣化を防止しつつ、データ転送量を削減できるという効果を奏する。
【図面の簡単な説明】
【００１６】
【図１】図１は、実施例１に係るシンクライアントシステムの構成を示す図である。
【図２】図２は、実施例１に係るシステムの流れを説明する図である。
【図３】図３は、サーバ装置がクライアント装置に送信した画像の例を示す図である。
【図４】図４は、クライアント操作の例を示す図である。
【図５】図５は、クライアント装置が差分画像を用いて動画を生成する処理の例を示す図である。
【図６】図６は、実施例２に係るシステムが有する各装置の構成を示すブロック図である。
【図７】図７は、更新差分動画変換部の内部処理の例を示す図である。
【図８】図８は、動画データ処理部の内部処理の例を示す図である。
【図９】図９は、実施例２に係るサーバ装置が実行する処理の全体的な流れを示すフローチャートである。
【図１０】図１０は、実施例２に係るサーバ装置が実行するフレームバッファ蓄積処理の流れを示すフローチャートである。
【図１１】図１１は、実施例２に係るサーバ装置が実行する擬似Ｉフレーム作成処理の流れを示すフローチャートである。
【図１２】図１２は、実施例２に係るサーバ装置が実行する更新差分動画作成処理の流れを示すフローチャートである。
【図１３】図１３は、実施例２に係るクライアント装置が実行する処理の全体的な流れを示すフローチャートである。
【図１４】図１４は、実施例２に係るクライアント装置が実行する擬似Ｉフレーム処理の流れを示すフローチャートである。
【図１５】図１５は、実施例２に係るクライアント装置が実行する動画データ処理の流れを示すフローチャートである。
【図１６】図１６は、実施例３に係るサーバ装置の構成を示すブロック図である。
【図１７】図１７は、実施例３に係るサーバ装置が実行する更新差分画像変換処理の流れを示すフローチャートである。
【図１８】図１８は、実施例３に係るサーバ装置が実行する擬似Ｉフレーム作成処理の流れを示すフローチャートである。
【図１９】図１９は、実施例４に係るサーバ装置の構成を示すブロック図である。
【図２０】図２０は、実施例４に係るサーバ装置が実行する擬似Ｉフレーム作成処理の流れを示すフローチャートである。
【図２１】図２１は、画像送信プログラムを実行するコンピュータのハードウェア構成例を示す図である。
【発明を実施するための形態】
【００１７】
以下に、本願の開示する情報処理装置、画像送信プログラム、画像送信方法および画像表示方法の実施例を図面に基づいて詳細に説明する。なお、この実施例によりこの発明が限定されるものではない。
【実施例１】
【００１８】
実施例１では、シンクライアントシステムの全体構成、シンクライアントシステムを形成する各装置の構成、処理の流れ等を説明する。
【００１９】
［全体構成］
図１は、実施例１に係るシンクライアントシステムの構成を示す図である。図１に示すように、このシステムは、サーバ装置１とクライアント装置５とを有する。なお、各装置の台数はあくまで例示であり、これに限定されるものではない。
【００２０】
このシンクライアントシステムは、クライアント装置５が表示する画面をリモートでサーバ装置１に制御させるものである。つまり、シンクライアントシステムは、実際にはサーバ装置１が実行した処理結果や保持するデータをクライアント装置５に表示させつつも、あたかもクライアント装置５が主体となって処理を実行したり、データを保持しているかのように振る舞う。
【００２１】
これらサーバ装置１及びクライアント装置５は、所定のネットワークを介して、相互に通信可能に接続される。かかるネットワークには、有線または無線を問わず、インターネット、ＬＡＮ（Local Area Network）やＶＰＮ（Virtual Private Network）などの任意の種類の通信網を採用できる。なお、サーバ装置１及びクライアント装置５間の通信プロトコルには、一例として、ＶＮＣ（Virtual Network Computing）におけるＲＦＢ（Remote Frame Buffer）プロトコルを採用する場合を想定する。
【００２２】
サーバ装置１は、クライアント装置５に表示させる画面をリモートで制御するサービスを提供するコンピュータである。一例としては、サーバ装置１は、クライアント装置５における操作情報を取得した上でその操作により要求された処理を自装置で動作するアプリケーションに実行させる。そして、サーバ装置１は、アプリケーションにより実行された処理結果を表示するための画面を生成した上で、その画面をクライアント装置５へ送信する。
【００２３】
クライアント装置５は、サーバ装置１によるリモート画面制御サービスの提供を受ける側のコンピュータである。かかるクライアント装置５の一例としては、パーソナルコンピュータなど固定端末の他、携帯電話機、ＰＨＳ（Personal Handyphone System）やＰＤＡ（Personal Digital Assistant）などの移動体端末を適用することもできる。
【００２４】
［サーバの構成］
図１に示すように、サーバ装置１は、通信部１ａ、第１の画像メモリ１ｂ、第２の画像メモリ１ｃ、第１の画像送信部１ｄ、第２の画像送信部１ｅ、ＯＳ（Operating System）実行部１ｆを有する。通信部１ａは、クライアント装置５との間の通信を制御するインタフェースであり、クライアント装置５に画像等を送信したり、クライアント装置５で実行された操作等を受信する。
【００２５】
第１の画像メモリ１ｂは、コンピュータの上で実行されているＯＳ自身ならびにＯＳ上で動作するアプリケーションが行ったデスクトップ画面への描画処理の実行結果を保持する。つまり、第１の画像メモリ１ｂは、サーバ装置１がリモート画面制御サービスとしてクライアント装置５に提供するための元データとなるデスクトップ画面の最新の画像データを保持する。
【００２６】
第２の画像メモリ１ｃは、後述する第１の画像送信部１ｄで送信した画像を保持する。つまり、第２の画像メモリ１ｃは、サーバ装置１がリモート画面制御サービスとしてクライアント装置５に提供した、送信済みの画像を保持する。例えば、第２の画像メモリ１ｃは、送信された順序や時系列で送信済みのリモート画面を保持する。第１の画像メモリでは、非同期に異なる間隔でＯＳやアプリケーションから更新画像が書き込まれる。一方、第１の画像送信部は、必ずしもＯＳ実行部１ｆから画像メモリへの書き込み毎にデータを取得するとは限らない。また、第１の画像メモリ１ｂから第２の画像メモリ１ｃへ直接コピーを行うと、クライアントへ送信したデータと同期がとれない可能性がある。ゆえに、サーバ装置１は、第１の画像送信部１ｄ経由で画像メモリデータを第２の画像メモリ１ｃへコピーする。
【００２７】
第１の画像送信部１ｄは、第１の画像メモリ１ｂに保持される画像を一定間隔で取得しクライアント装置５へ送信するとともに第２の画像メモリへも送信（コピー）する。例えば、ＯＳ実行部１ｆは、クライアント装置５における操作情報を取得した上で、その操作により要求された処理を自装置で動作するアプリケーションに実行させる。そして、ＯＳ実行部１ｆは、アプリケーションにより実行された処理結果を表示するための画像を生成して第１の画像メモリ１ｂに格納する。そして、第１の画像送信部１ｄは、第１の画像メモリ１ｂに格納された画像をあるタイミングでコピーした上で変換を行いクライアント装置へ送信する。この送信処理と同時に変換に利用した画像メモリのデータを第２の画像メモリ１ｃに格納する。
【００２８】
第２の画像送信部１ｅは、第１の画像送信部１ｄから第２の画像送信部１ｅに送信を切り換える際に、第２の画像メモリ１ｃに保持された画像で最新のものを基準画像に設定する。そして、第２の画像送信部１ｅは、基準画像を基に、第１の画像メモリ１ｂから一定間隔で画像データを取得して差分画像を生成し、基準画像をクライアント装置５に送信済みの画像から取得する信号と共に差分画像を送信する。
【００２９】
例えば、第２の画像送信部１ｅは、所定の契機で、第１の画像送信部１ｄが実行していた画像送信から、動画送信に送信手法を変更する。そして、第２の画像送信部１ｅは、送信手法を切り替えるタイミングでクライアント装置５が表示していたリモート画面、すなわち、第２の画像メモリ１ｃが保持する最新画像を基準画像に決定する。続いて、第２の画像送信部１ｅは、切り替え以降の画像送信データを基準画像をもとにした差分画像として生成する。ここでの差分画像は第２の画像送信部が一定間隔で第１の画像メモリから画面データを取得し、基準画像と比較することで生成される。その後、第２の画像送信部１ｅは、基準画像をクライアント装置５に送信済みの画像から取得する信号と共に、差分画像をクライアント装置５に送信する。
【００３０】
つまり、第２の画像送信部１ｅは、画像送信から動画送信に切り替えた際に、いわゆるＩフレームについてはＰフレームを生成する際にだけ使用し、Ｐフレームのみをクライアント装置５に送信する。
【００３１】
［クライアント装置の構成］
図１に示すように、クライアント装置５は、通信部５ａ、画像メモリ５ｂ、表示部５ｃ、画像生成部５ｄを有する。通信部５ａは、サーバ装置１との間の通信を制御するインタフェースであり、例えば、サーバ装置１から画像等を受信したり、サーバ装置１に操作情報を送信したりする。
【００３２】
画像メモリ５ｂは、サーバ装置１から受信した画像や保持する。例えば、画像メモリ５ｂは、リモート画面として受信した画像を画像生成部で展開・復号処理した結果を保持する。表示部５ｃは、画像メモリ上に書き込まれた画像データを表示するディスプレイやタッチパネルなどの表示装置であり、マウス等と連携してポインティングデバイスを提供する。
【００３３】
画像生成部５ｄは、サーバ装置１から画像を受信した場合には、受信した画像を画像メモリ５ｂに格納する。また、画像生成部５ｄは、基準画像を送信済みの画像から取得する信号と共に差分画像を受信した場合に、画像メモリ５ｂに記憶される画像を取得して擬似基準画像とする。そして、画像生成部５ｄは、擬似基準画像と受信した差分画像とを用いて動画を生成し、生成した動画を画像メモリ５ｂに格納する。その後、クライアント装置５内のＯＳ等は、画像メモリ５ｂから読み出してリモート画面として表示部５ｃに再生する。
【００３４】
つまり、画像生成部５ｄは、サーバ装置１からＰフレームと所定信号とを受信した場合に、直前まで表示部５ｃに表示されていた画像を擬似Ｉフレームと決定する。そして、画像生成部５ｄは、決定した擬似Ｉフレームと受信したＰフレームとを用いて、動画を再生する。
【００３５】
［処理の流れ］
図２は、実施例１に係るシステムの流れを説明する図である。図２に示すように、サーバ装置１の第１の画像送信部１ｄは、第１の画像メモリ１ｂから取得し更新のあった領域の画像を差分画像としてクライアント装置５へ送信する（Ｓ１０１とＳ１０２）。つまり、サーバ装置１は、クライアント装置５における操作情報を取得した上で、その操作により要求された処理を自装置で動作するアプリケーションに実行させ、実行された処理結果を表示するための画像を生成してクライアント装置５へ送信する。
【００３６】
この画像を受信したクライアント装置５の画像生成部５ｄは、サーバ装置１から受信した画像を画像メモリ５ｂに格納し、これが表示部へと出力される（Ｓ１０３）。
【００３７】
その後、所定契機を検出したサーバ装置１の第２の画像送信部１ｅは、送信手法を切り替えると判定し、送信手法を切り替えるタイミングでクライアント装置５が表示していたリモート画面を基準画像に決定する（Ｓ１０４とＳ１０５）。すなわち、第２の画像送信部１ｅは、第２の画像メモリ１ｃが保持する最新画像を基準画像に決定する。
【００３８】
そして、第２の画像送信部１ｅは、基準画像を基に、基準画像からクライアント装置５に表示させる画像までの差分画像を第１の画像メモリ１ｂに保持された画像を一定間隔で取得し基準画像との比較から生成する（Ｓ１０６）。
【００３９】
その後、第２の画像送信部１ｅは、基準画像をクライアント装置５に送信済みの画像から取得させる信号と共に、差分画像をクライアント装置５に送信する（Ｓ１０７とＳ１０８）。
【００４０】
この差分画像および信号を受信したクライアント装置５の画像生成部５ｄは、差分画像を受信する直前の画像、言い換えると、表示部５ｃに表示していた最新画像を擬似基準画像とし、擬似基準画像と差分画像を用いて動画を生成する（Ｓ１０９とＳ１１０）。そして、画像生成部５ｄは、生成した動画を画像メモリ５ｂに格納するとともに、リモート画面として表示部５ｃに表示させる（Ｓ１１１）。
【００４１】
［送信手法切替の具体例］
次に、図３〜図５を用いて、図１に示したシステムで実行される画面送信手法の切替例を説明する。図３は、サーバ装置がクライアント装置に送信した画像の例を示す図である。図４は、クライアント操作の例を示す図である。図５は、クライアント装置が差分画像を用いて動画を生成する処理の例を示す図である。
【００４２】
まず、サーバ装置１は、図３に示した画像Ａを生成してクライアント装置５に送信する。その後、クライアント装置５では、図４に示したように、表示画像Ａを所定値以上移動させる画像操作が実行される。サーバ装置１は、図４に示した画像操作をトリガとして、画像送信の手法を切り替える。
【００４３】
そして、サーバ装置１は、図４の画像操作が実行されるまでクライアント装置に表示されていた図３に示す画像Ａを基準画像とし、この基準画像を基に、図４に示す画像Ａから画像Ｂまでの差分画像を生成する。その後、サーバ装置１は、基準画像を送信済みの画像から取得する信号と共に、生成した差分画像をクライアント装置５に送信する。なお、画像Ａから画像Ｂまで移動する場合、基準画像は今までの各フレームの差分画像との和に変更される。
【００４４】
すると、クライアント装置５では、基準画像を受信する直前に受信した画像、すなわち図３の画像Ａを擬似基準画像として、図５に示すように、この擬似基準画像と受信した差分画像とを用いて動画を生成して表示部５ｃに再生する。
【００４５】
［実施例１による効果］
実施例１に係るシステムでは、圧縮方式を切り替えながら画面の更新データを送信するシーンにおいて、サーバ装置とクライアント装置双方に存在するフレームを擬似基準画像として利用することで、重複をなくしデータ転送量を削減可能である。すなわち、サーバ装置１がデータ転送量の大きい静止画を送信しないにも関らず、クライアント装置５では動画を表示させることができる。したがって、データ転送量を削減できる。
【実施例２】
【００４６】
次に、サーバ装置が通常時には静止画像をクライアント装置に送信し、トリガを検出した場合に、静止画像からＭＰＥＧ（Moving Picture Expert Group）送信に切り替える例について説明する。ここでは、システムが有する各装置の構成、処理の流れ、効果について説明する。なお、ここで例示する圧縮形式は、ＭＰＥＧ−２でもＭＰＥＧ−４でもよく、圧縮形式を限定するものではない。
【００４７】
［各装置の構成］
図６は、実施例２に係るシステムが有する各装置の構成を示すブロック図である。図６に示すように、このシステムは、サーバ装置１０とクライアント装置５０とを有するので、ここでは各装置の構成を説明する。
【００４８】
（サーバの構成）
図６に示すように、サーバ１０は、通信部１１、操作情報取得部１２、ＯＳ（Operating System）実行部１３、表示画面生成部１４、サーバ側リモート画面制御部１５を有する。なお、図６の例では、図６に示した機能部以外にも既知のコンピュータが有する各種の機能部、例えば各種の入力デバイスや表示デバイスなどの機能を有するものとする。
【００４９】
通信部１１は、クライアント装置５０との間でデータの送受信を行う通信インタフェースである。例えば、通信部１１は、後述する画面更新通知部２３から出力された画像や差分画像をクライアント装置５０に送信する。また、通信部１１は、クライアント装置５０から操作情報を受信して操作情報取得部１２に出力する。
【００５０】
操作情報取得部１２は、通信部１１が受信したクライアント装置５０の操作情報を取得する処理部である。例えば、操情報取得部１２は、マウスの左右のクリックを始め、ダブルクリックやドラッグ、マウスの移動操作を介して得られたマウスカーソルの移動量などを操作情報として取得する。他の一例としては、操作情報取得部１２は、マウスホイールの回転量、キーボードのうち押下されたキーの種別なども操作情報として取得する。具体的な例を挙げると、操作情報取得部１２は、クライアント装置５０から取得したマウスのダウンクリックからアップクリックまでに要した時間や、マウスのダウンクリックからアップクリックまでの距離等を取得してもよい。
【００５１】
ＯＳ実行部１３は、サーバ内のＯＳを実行する処理部である。例えば、ＯＳ実行部１３は、操作情報取得部１２により取得された操作情報からアプリケーションの起動指示やアプリケーションに対するコマンドを検出する。一例としては、ＯＳ実行部１３は、アプリケーションのアイコン上でダブルクリックを検出した場合に、そのアイコンに対応するアプリケーションの起動を表示画面生成部１４へ指示する。他の一例としては、ＯＳ実行部１３は、起動中のアプリケーションの操作画面、いわゆるウィンドウ上でコマンドの実行を要求する操作を検出した場合に、そのコマンドの実行を表示画面生成部１４へ指示する。
【００５２】
表示画面生成部１４は、ＯＳ実行部１３による指示に基づき、アプリケーションの実行を制御したり、画面生成を実行したりする処理部である。一例としては、表示画面生成部１４は、ＯＳ実行部１３によりアプリの起動が指示された場合や起動中のアプリにコマンドの実行が指示された場合にアプリを動作させる。そして、表示画面生成部１４は、アプリを実行することにより得られた処理結果の表示用画像（リモート画面）を生成して、フレームバッファ１６に書き込む。
【００５３】
なお、表示画面生成部１４が実行するアプリケーションは、プリインストールされたものであってもよく、サーバ装置１０の出荷後にインストールされたものであってもかまわない。また、ＪＡＶＡ（登録商標）などのネットワーク環境から動的にデータを読み込んだ上で動作するアプリケーションであってもよい。また、表示画面生成部１４は、フレームバッファ１６に表示用画像を書き込む、言い換えると、フレームバッファ１６に表示用画像を描画するためのドライバ等を有していてもよい。
【００５４】
サーバ側リモート画面制御部１５は、サーバ側リモート画面制御用アプリケーションを通じて、リモート画面制御サービスをクライアント装置５０へ提供する処理部である。このサーバ側リモート画面制御部１５は、図６に示すように、フレームバッファ１６、フレームバッファ蓄積部１７、更新差分作成部１８、高頻度画面更新領域検出部１９、更新差分画像変換部２０を有する。さらに、サーバ側リモート画面制御部１５は、擬似Ｉフレーム処理部２１、更新差分動画変換部２２、画面更新通知部２３を有する。
【００５５】
フレームバッファ１６は、表示画面生成部１４により描画された表示用画像を画像データフレームとして記憶する記憶デバイスである。かかるフレームバッファ１６の一態様としては、ＶＲＡＭ（Video Random Access Memory）を始めとするＲＡＭ（Random Access Memory)、ＲＯＭ（Read Only Memory）やフラッシュメモリ（flash memory）などの半導体メモリ素子が挙げられる。なお、フレームバッファ１６は、ハードディスク、光ディスクなどの記憶装置を採用することとしてもかまわない。
【００５６】
フレームバッファ蓄積部１７は、過去のフレームバッファ状態を履歴として蓄積する記憶デバイスであり、フレームバッファ１６と同種別のデバイスを用いることができる。例えば、フレームバッファ蓄積部１７は、サーバ側のフレームバッファ１６に書き込みされた過去の画面データフレームを蓄積する機能を有する。具体的には、フレームバッファ蓄積部１７は、サーバ装置１０中で画面情報の差分検出処理を行う際に、１回全画面を走査して差分検出を行うのを１フレームとカウントし、これを１フレームずつ蓄積していく。
【００５７】
例を挙げると、フレームバッファ蓄積部１７は、ある時点におけるフレームの全情報を定期的に取得して保持し、他の処理部からの要求に応じて保持したデータを出力する。フレームバッファ蓄積部１７は、例えば３３ｍｓに１回など、フレームバッファをチェックするタイミングにおいて、更新差分作成部１８から要求を受けフレームバッファの画面データフレームを取得する。フレームバッファ蓄積部１７は、取得時にはそのタイミングにおけるフレームの全情報をその時のフレーム番号とともに保持する。なお、フレーム番号はフレームバッファをチェックする際に１ずつ増加する値である。
【００５８】
更新差分作成部１８は、フレームバッファ１６を検査し更新された差分部分を検出する処理部である。例えば、更新差分作成部１８は、フレームバッファ蓄積部１７から画面データフレームを受信した場合に、今回受信した画面データフレームと前回のタイミングで受信した画面データフレームとを比較して、差分部分を検出する。そして、更新差分作成部１８は、検出した差分部分を高頻度画面更新領域検出部１９に出力する。
【００５９】
高頻度画面更新領域検出部１９は、更新差分作成部１８から取得した更新差分を利用してフレームバッファ中で更新が激しい領域を検出する処理部である。高頻度画面更新領域検出部１９が更新の激しい領域を検出する手法には様々な手法を用いることができる。一例を挙げると、高頻度画面更新領域検出部１９は、取得した差分部分から更新された矩形を示す更新矩形を生成し、生成した更新矩形が動画化領域である場合には、更新が激しい領域として検出する。
【００６０】
例えば、高頻度画面更新領域検出部１９は、更新矩形の大きさが所定値以上であったり、更新矩形を表す差分画像のフレーム数が所定値以上であったりする場合に、動画化領域と検出する。つまり、高頻度画面更新領域検出部１９は、サーバ装置１０がクライアント装置５０に前回送信した画面データフレームに対して、クライアント装置５０によって激しい操作が実行されたか否かを検出する。そして、高頻度画面更新領域検出部１９は、激しい操作が実行されたと判定した場合に、動画生成依頼を擬似Ｉフレーム処理部２１に通知し、激しい操作が実行されていないと判定した場合に、更新画像送信を更新差分画像変換部２０に通知する。
【００６１】
更新差分画像変換部２０は、高頻度画面更新領域検出部１９から更新画像送信依頼を受信すると、領域の更新頻度から更新差分に一致する領域をフレームバッファ１６から取得して画像へ変換し、変換した画像を画面更新通知部２３に出力する処理部である。つまり、更新差分画像変換部２０は、サーバ装置１０がクライアント装置５０に前回送信した画面データフレームに対して、許容範囲内の画像操作が実行されたとする。この場合、更新差分画像変換部２０は、前回送信された画面データフレームとの差分画像を、フレームバッファ蓄積部１７やフレームバッファ１６に記憶されるデータを用いて生成する。
【００６２】
擬似Ｉフレーム処理部２１は、更新差分を動画へ変換する場合に、Ｉフレームとして利用可能なフレーム情報を検出する処理部である。そして、擬似Ｉフレーム処理部２１は、フレーム情報を利用してフレームバッファ蓄積部１７から擬似Ｉフレームデータとなる画面データを取得して、更新差分動画変換部２２へ出力する。
【００６３】
具体的には、擬似Ｉフレーム処理部２１は、フレームバッファ蓄積部１７から現在送信済みで最新のフレームバッファを取得する。そして、擬似Ｉフレーム処理部２１は、そのフレームデータから動画データへ変換する対象の領域の画面データを取得し、擬似Ｉフレームとして更新差分動画変換部２２に出力する。例えば、擬似Ｉフレーム処理部２１は、高頻度画面更新領域検出部１９から動画データへ変換する必要がある高頻度画面更新領域の情報を受け取るとともに、画面更新通知部２３から現在までに送信済みのフレームの番号を取得する。なお、画面更新通知部２３で送信が行われたデータはクライアント側に届いていると想定する。そして、擬似Ｉフレーム処理部２１は、フレームバッファ蓄積部１７から送信済みのフレーム番号に該当するフレームの情報を取得し、ここから動画データへ変換する領域の画面データを抽出する。擬似Ｉフレーム処理部２１は、この画面データを擬似Ｉフレームとして更新差分動画変換部２２へ出力する。
【００６４】
更新差分動画変換部２２は、擬似Ｉフレームがあらかじめ渡された状態で生成され、このＩフレームをベースとしてフレームバッファ１６から取得したデータを利用して、先頭Ｉフレームを排除した形で動画データを生成する処理部である。例えば、更新差分動画変換部２２は、擬似Ｉフレーム処理部２１から擬似Ｉフレームと高頻度画面更新領域の情報を受信し、擬似ＩフレームのデータをＩフレームとして現在のフレームバッファと比較する。その後、更新差分動画変換部２２は、データの先頭がＰフレームから始まる動画データを作成し、画面更新通知部２３に渡す。
【００６５】
なお、更新差分動画変換部２２では画面の更新差分データの変換のためにＭＰＥＧ技術を利用することができる。ＭＰＥＧ技術の中で以下の２種類の性質の異なるフレームのみを利用して動画データを生成する。はじめに、Ｉフレームと呼ばれるデータを動画データの先頭に作成する。これは、他のフレーム（Ｐフレーム）の土台となるフレームで、このフレーム単独で１枚の画像として表示可能な独立したデータになっている。次に、Ｐフレームと呼ばれるデータを作成する。これは、Ｉフレームに対する差分データのみを含むフレームで、Ｉフレームに対してこのフレームを適用することで画面全体を生成することが可能である。ゆえに、Ｐフレーム単独では画像を生成することはできない。また、ＰフレームはＩフレームの後に連続して作成することが可能である。
【００６６】
ここで、更新差分動画変換部２２が実行するＭＰＥＧ符号化について説明する。図７は、更新差分動画変換部の内部処理の例を示す図である。図７に示すように、ＭＰＥＧ符号化器である更新差分動画変換部２２では、一般的な符号化器と同様、動き予測、動き補償、テクスチャ符号化、多重化などの処理を実行して、動画データを生成する。ここで、更新差分動画変換部２２が実行する処理で、一般的な復号化器と異なる点は、符号化器初期化時に処理領域のフレームバッファをＩフレームとして入力する点である。なお、一般的な符号化器と同様の処理については、詳細な説明は省略する。
【００６７】
具体的には、まず、更新差分動画変換部２２は、ＭＰＥＧデータを作成する際のＩフレームの替わりとして、擬似Ｉフレーム処理部２１から過去のフレームバッファ中の高頻度画面更新領域の位置の画面データを取得する。ここでは、過去の画面データを取得するのは、クライアント側に既に通知されているフレームバッファを使うためである。次に、更新差分動画変換部２２は、取得した画面データを擬似Ｉフレームとして、「前画面までの再構成フレーム」が保持されているバッファに書き込む。この処理により、符号化の際に生成するデータの先頭のＩフレームの生成を無くし、Ｐフレームからの動画データ生成を可能とする。
【００６８】
そして、更新差分動画変換部２２は、フレームバッファから最新の画面データを取得し、擬似Ｉフレームを保持した状態で、はじめから差分のデータが生成され、先頭がＰフレームからはじまるＭＰＥＧ形式で画面の更新データを生成する。更新差分動画変換部２２は、生成した更新データを画面更新通知部２３に出力し、通信部１１を経由してクライアント装置５０に通知される。
【００６９】
一例を挙げると、更新差分動画変換部２２は、入力された画像と擬似Ｉフレームとを用いて動き予測や動き補償を実行した後に、テクスチャ符号化によってテクスチャ情報を生成する。一方で、更新差分動画変換部２２は、動き補償の結果とテクスチャ情報とを用いて、新たなフレームを生成してバッファに書込む。また、更新差分動画変換部２２は、動き予測から得られた動きベクトル情報と、テクスチャ符号化によって得られたテクスチャ情報とを多重化してバッファに書込み、このバッファからデータを読み出して、ビットストリームとしてクライアント装置５０に送信する。
【００７０】
図６に戻り、画面更新通知部２３は、更新差分画像変換部２０によって生成された画像をクライアント装置５０に送信する。また、画面更新通知部２３は、更新差分動画変換部２２によって生成された動画、すなわち、Ｐフレームのみから形成される動画をクライアント装置５０に送信する。また、画面更新通知部２３は、現在までに送信済みの画像（フレーム）と、当該フレームに割り与えられた番号とを対応付けて保持する。
【００７１】
なお、上述した各処理部は、各種の集積回路や電子回路を採用でき、一部を別の集積回路や電子回路とすることもできる。例えば、集積回路としては、ＡＳＩＣ（Application Specific Integrated Circuit）やＦＰＧＡ（Field Programmable Gate Array）が挙げられる。また、電子回路としては、ＣＰＵ（Central Processing Unit）やＭＰＵ（Micro Processing Unit）などが挙げられる。
【００７２】
（クライアント装置の構成）
図６に示すように、クライアント装置５０は、通信部５１、表示部５２、画面表示部５３、操作情報取得部５４、クライアント側リモート画面制御部５５を有する。なお、図６の例では、図６に示した機能部以外にも既知のコンピュータが有する各種の機能部、例えば各種の入力デバイスや音声出力部などの機能を有するものとする。
【００７３】
通信部５１は、サーバ装置１０との間でデータの送受信を行う通信インタフェースである。例えば、通信部５１は、後述する操作情報取得部５４により取得された操作情報をサーバ装置１０に送信する。また、通信部５１は、サーバ装置１０から画像や動画を受信して画面更新情報取得部５６等に出力する。
【００７４】
表示部５２は、各種の情報、例えばサーバ装置１０から送信されたデスクトップ画面などを表示する表示デバイスであり、一例としては、モニタ、ディスプレイやタッチパネルなどを適用できる。また、表示部５２は、マウスなどの入力デバイスと協働して、ポインティングデバイスを提供する。
【００７５】
画面表示部５３は、フレームバッファ６０に書き込まれた画像、言い換えると、フレームバッファ６０に描画された画像や動画を読み出し、リモート画面として表示部５２に表示させる。この結果、サーバ装置１０から送信された画像や動画がクライアント装置５０に表示され、リモート画面制御サービスの提供が行われることになる。
【００７６】
操作情報取得部５４は、マウスなどの操作情報を取得してサーバ装置１０へ通知する処理部である。一例としては、操作情報取得部５４は、マウスの左右のクリックを始め、ダブルクリックやドラッグ、マウスの移動操作を介して得られたマウスカーソルの移動量などを操作情報として通知する。他の一例としては、操作情報取得部５４は、マウスホイールの回転量、キーボードのうち押下されたキーの種別なども操作情報として通知する。
【００７７】
クライアント側リモート画面制御部５５は、クライアント側リモート画面制御用アプリを通じて、サーバ装置１０によるリモート画面制御サービスの提供を受ける処理部である。このクライアント側リモート画面制御部５５は、図６に示すように、画面更新情報取得部５６、画像データ処理部５７、擬似Ｉフレーム処理部５８、動画データ処理部５９、フレームバッファ６０を有する。
【００７８】
画面更新情報取得部５６は、サーバ装置１０から送信された画像データを通信部５１から取得する処理部である。そして、画面更新情報取得部５６は、取得した画像データが静止画などの画像である場合には、当該画像データを画像データ処理部５７に出力する。また、画面更新情報取得部５６は、取得した画像データがＰフレームなどの動画である場合には、当該画像データを擬似Ｉフレーム処理部５８に出力する。なお、画面更新情報取得部５６は、画像データのフォーマットや符号化状態などから、画像データの種類を判別することができる。
【００７９】
画像データ処理部５７は、画面更新情報取得部５６から取得した画像データをフレームバッファ６０に書き込む処理部である。例えば、画像データ処理部５７は、サーバ装置１０から送信された画像データ、すなわち、クライアントの操作によって更新された画像をフレームバッファ６０に描画する。
【００８０】
擬似Ｉフレーム処理部５８は、画面更新情報取得部５６から取得した、先頭のＩフレームが取り除かれた動画データから、処理すべきフレーム内の領域位置情報を取得する処理部である。そして、擬似Ｉフレーム処理部５８は、取得した領域位置情報に基づいてフレームバッファ６０から画面データを取得し、擬似Ｉフレームとして動画データ処理部５９に出力する。
【００８１】
例えば、擬似Ｉフレーム処理部５８は、Ｐフレームから始まる画面の動画更新データを受信し、フレームバッファ６０から更新データと同領域の画面データを擬似Ｉフレームとして切り出して動画データ処理部５９に出力する。具体的には、擬似Ｉフレーム処理部５８は、動画形式の更新データを受信し、更新データから描画位置の情報として座標位置等を取得する。続いて、擬似Ｉフレーム処理部５８は、この位置情報を利用して、フレームバッファ６０から該当する領域の画面データを取得し、擬似Ｉフレームとして動画データ処理部５９へ通知する。
【００８２】
つまり、擬似Ｉフレーム処理部５８は、取得した動画データの先頭がＰフレームである場合、サーバ装置１０から動画データを受信する直前に受信していた画像データを特定する。そして、擬似Ｉフレーム処理部５８は、取得した動画データと、特定した画像データと、擬似Ｉフレームとを動画データ処理部５９に出力する。
【００８３】
動画データ処理部５９は、擬似Ｉフレーム処理部５８から取得した擬似Ｉフレームと、サーバ装置１０から受信したＩフレームが取り除かれたデータとを利用して、動画データを再生する。なお、動画データ処理部５９は、動画生成にＭＰＥＧ技術を利用することができる。例えば、ＭＰＥＧ復号器である動画データ処理部５９は、擬似Ｉフレーム処理部５８から擬似Ｉフレームを受信するとともに、Ｐフレームから始まる動画データも受信し、これらのデータから動画データをフレームバッファ６０へ描画する。
【００８４】
図８は、動画データ処理部の内部処理の例を示す図である。図８に示すように、動画データ処理部５９は、一般的なＭＰＥＧ復号器と同様、バッファを有し、可変長復号処理、逆量子化、逆直交変換、動き補償等を実行して復号映像を生成する。ここで、動画データ処理部５９が実行する処理で、一般的な復号器と異なる点は、復号器初期化時に処理領域のフレームをＩフレームとしてバッファに入力する点である。なお、一般的な復号器と同様の処理については、詳細な説明は省略する。
【００８５】
具体的には、まず、動画データ処理部５９は、受信した擬似Ｉフレームを「バッファ」に書き込む。この処理により、復号の際に生成する画面描画データを現在のフレームバッファ６０に表示中の画面データに変更が加えられた後のデータから生成可能とする。そして、動画データ処理部５９は、Ｐフレームから始まる動画データとこの擬似Ｉフレームとを用いて、Ｐフレームの差分が反映されたフレームから画面の更新データを生成する。その後、動画データ処理部５９は、生成されたデータをフレームバッファ６０に書き込む。
【００８６】
図６に戻り、フレームバッファ６０は、画像データ処理部５７により描画された画像や、動画データ処理部５９により生成された動画を保持する。例えば、フレームバッファ６０は、動画データ処理部５９などが実行する描画処理の結果のデータが書き込まれるとともに、擬似Ｉフレーム処理部５８が取得する擬似Ｉフレームのデータの元となる画像を保持する。
【００８７】
［処理の流れ］
次に、実施例２に係るシステムで実行される処理の流れを説明する。ここでは、サーバ装置が実行する処理の流れ、クライアント装置が実行する処理の流れを説明する。
【００８８】
（サーバが実行する全体的な処理の流れ）
図９は、実施例２に係るサーバ装置が実行する処理の全体的な流れを示すフローチャートである。図９に示すように、サーバ装置１０の操作情報取得部１２は、クライアント装置５０で実行されたユーザの操作情報を取得し（Ｓ２０１）、表示画面生成部１４は、ユーザの操作情報に対応した画面を生成してフレームバッファ１６に反映する（Ｓ２０２）。
【００８９】
そして、フレームバッファ蓄積部１７は、表示画面生成部１４によってフレームが反映された結果、フレームバッファ１６に更新が生じたと検出すると（Ｓ２０３肯定）、フレームバッファ蓄積処理を実行する（Ｓ２０４）。なお、フレームバッファ蓄積部１７によってフレームバッファ１６に更新が生じていないと検出された場合には（Ｓ２０３否定）、サーバ装置１０は、Ｓ２０１に戻って以降の処理を繰り返す。
【００９０】
その後、更新差分作成部１８は、フレームバッファ蓄積処理によって蓄積された全フレームバッファの情報から、フレームバッファ１６の更新矩形を作成する（Ｓ２０５）。続いて、高頻度画面更新領域検出部１９は、更新差分作成部１８が生成した更新矩形から、高頻度画面更新領域を検出する（Ｓ２０６）。そして、高頻度画面更新領域検出部１９は、検出した高頻度画面更新領域が動画化領域、すなわち、更新の激しいか否かを判定する（Ｓ２０７）。
【００９１】
高頻度画面更新領域が動画化領域でない場合（Ｓ２０７否定）、更新差分画像変換部２０は、更新差分に一致する領域をフレームバッファ１６から取得して画像へ変換し、変換した画像を画面更新通知部２３に出力する（Ｓ２０８）。そして、画像更新通知部２３は、通信部１１を介して、更新差分画像変換部２０から取得した差分画像をクライアント装置５０に送信する（Ｓ２０９）。その後、クライアント装置で画像描画処理が実行される（Ｓ２１０）。
【００９２】
一方、高頻度画面更新領域が動画化領域である場合（Ｓ２０７肯定）、擬似Ｉフレーム処理部２１が擬似Ｉフレーム作成処理を実行し（Ｓ２１１）、続いて、更新差分動画変換部２２が更新差分動画作成処理を実行する（Ｓ２１２）。
【００９３】
その後、画面更新通知部２３は、通信部１１を介して、ＩフレームがなくＰフレームだけの動画データをクライアント装置５０に送信する（Ｓ２１３）。その後、クライアント装置で動画再生処理が実行される（Ｓ２１４）。
【００９４】
（フレームバッファ蓄積処理）
図１０は、実施例２に係るサーバ装置が実行するフレームバッファ蓄積処理の流れを示すフローチャートである。なお、この処理は、図９のＳ２０４で実行される。
【００９５】
図１０に示すように、フレームバッファ蓄積部１７は、更新差分作成部１８から取得要求を受信すると（Ｓ３０１肯定）、フレームバッファ１６中の全データを取得し（Ｓ３０２）、一意なフレーム番号を付与して保持する（Ｓ３０３）。
【００９６】
一方、フレームバッファ蓄積部１７は、更新差分作成部１８から取得要求を受信せずに（Ｓ３０１否定）、擬似Ｉフレーム処理部２１から取得要求を受信した場合（Ｓ３０４肯定）、Ｓ３０５を実行する。すなわち、フレームバッファ蓄積部１７は、取得要求に含まれるフレーム番号に一致するデータを検索し、検索されたデータを擬似Ｉフレーム処理部２１に出力する（Ｓ３０５）。なお、フレームバッファ蓄積部１７は、更新差分作成部１８から取得要求を受信せずに（Ｓ３０１否定）、擬似Ｉフレーム処理部２１からも取得要求を受信しない場合（Ｓ３０４否定）、Ｓ３０１に戻って以降の処理を実行する。
【００９７】
（擬似Ｉフレーム作成処理）
図１１は、実施例２に係るサーバ装置が実行する擬似Ｉフレーム作成処理の流れを示すフローチャートである。なお、この処理は、図９のＳ２１１で実行される。この処理は、高頻度画面が検出されるたびに実行される。
【００９８】
図１１に示すように、擬似Ｉフレーム処理部２１は、更新差分画像変換部２０から高頻度画面が存在することを受信した場合（Ｓ４０１肯定）、送信済みの最新のフレーム番号を画面更新通知部２３から取得する（Ｓ４０２）。
【００９９】
続いて、擬似Ｉフレーム処理部２１は、取得した最新のフレーム番号に対応するフレームデータをフレームバッファ蓄積部１７から取得する（Ｓ４０３）。そして、擬似Ｉフレーム処理部２１は、高頻度画面更新領域を更新差分画像変換部２０から取得するとともに、この領域に一致する領域の画面データをフレームバッファ蓄積部１７から取得する（Ｓ４０４）。その後、擬似Ｉフレーム処理部２１は、取得した画像データを擬似Ｉフレームとして、更新差分動画変換部２２へ出力する（Ｓ４０５）。
【０１００】
（更新差分動画作成処理）
図１２は、実施例２に係るサーバ装置が実行する更新差分動画作成処理の流れを示すフローチャートである。なお、この処理は、図９のＳ２１２で実行される。この処理は、擬似フレームが受信されるたびに実行される。
【０１０１】
図１２に示すように、更新差分動画変換部２２は、擬似Ｉフレーム処理部２１から擬似Ｉフレームを受信すると（Ｓ５０１肯定）、擬似Ｉフレームを「前画面までの再構成フレーム」を保持するバッファに格納する（Ｓ５０２）。
【０１０２】
続いて、更新差分動画変換部２２は、高頻度画面更新領域すなわち激しい操作が実行された領域の最新のフレームをフレームバッファ１６から取得し（Ｓ５０３）、Ｐフレームから始まる動画データを生成する（Ｓ５０４）。その後、更新差分動画変換部２２は、生成した動画データを画面更新通知部２３に出力する（Ｓ５０５）。
【０１０３】
（クライアント装置が実行する全体的な処理の流れ）
図１３は、実施例２に係るクライアント装置が実行する処理の全体的な流れを示すフローチャートである。図１３に示すように、クライアント装置５０の操作情報取得部５４は、表示部５２に表示される画面に対してユーザが操作した場合に（Ｓ６０１肯定）、当該操作の内容を示す操作情報を逐次サーバ装置１０に送信する（Ｓ６０２）。
【０１０４】
そして、画面更新情報取得部５６がサーバ装置１０から画像データを受信した場合（Ｓ６０３肯定）、画像データ処理部５７は、受信された画像データをフレームバッファ６０に描画する（Ｓ６０４）。
【０１０５】
一方、画面更新情報取得部５６がサーバ装置１０から画像データではなく（Ｓ６０３否定）、動画データを受信した場合（Ｓ６０５肯定）、擬似Ｉフレーム処理部５８は、受信された動画データの先頭がＰフレームであるか否かを判定する（Ｓ６０６）。
【０１０６】
そして、擬似Ｉフレーム処理部５８は、受信された動画データの先頭がＰフレームである場合（Ｓ６０６肯定）、擬似Ｉフレーム処理を実行する（Ｓ６０７）。また、このＳ６０６において、動画データ処理部５９は、動画データを生成する。その後、動画データ処理部５９は、生成した動画データをフレームバッファ６０に重畳して再生する（Ｓ６０８）。なお、擬似Ｉフレーム処理部５８は、受信された動画データの先頭がＰフレームでなくＩフレームである場合（Ｓ６０６否定）、Ｓ６０７を実行することなく、動画データ処理部５９は、受信した動画データをフレームバッファ６０に重畳して再生する（Ｓ６０８）。
【０１０７】
（擬似Ｉフレーム処理）
図１４は、実施例２に係るクライアント装置が実行する擬似Ｉフレーム処理の流れを示すフローチャートである。なお、この処理は、図１３のＳ６０５からＳ６０８で実行される。この処理は、動画データが受信されるたびに実行される。
【０１０８】
図１４に示すように、擬似Ｉフレーム処理部５８は、画面更新情報取得部５６によって動画データが受信され（Ｓ７０１肯定）、データの先頭がＰフレームである場合（Ｓ７０２肯定）、動画データから描画位置の情報を取得する（Ｓ７０３）。
【０１０９】
そして、擬似Ｉフレーム処理部５８は、取得した描画位置にある高頻度画面更新領域と一致する領域の画面データを取得する（Ｓ７０４）。その後、擬似Ｉフレーム処理部５８は、取得した画面データを擬似Ｉフレームとして動画データ処理部５９に出力する（Ｓ７０５）。
【０１１０】
一方、画面更新情報取得部５６によって受信された動画データの先頭がＰフレームでない場合（Ｓ７０２否定）、受信された動画データを動画データ処理部５９に出力する（Ｓ７０６）。
【０１１１】
（動画データ処理）
図１５は、実施例２に係るクライアント装置が実行する動画データ処理の流れを示すフローチャートである。なお、この処理は、図１３のＳ６０７で実行される。この処理は、擬似Ｉフレームが受信されるたびに実行される。
【０１１２】
図１５に示すように、動画データ処理部５９は、擬似Ｉフレーム処理部５８から擬似Ｉフレームを受信すると（Ｓ８０１肯定）、受信した擬似フレームを動画データ処理部５９内部のバッファ等に書き込む（Ｓ８０２）。
【０１１３】
続いて、動画データ処理部５９は、擬似Ｉフレームと、サーバ装置１０から受信したＩフレームが取り除かれた動画データを利用して動画データを生成する（Ｓ８０３）。そして、動画データ処理部５９は、受信した動画データをフレームバッファ６０に重畳して再生する（Ｓ８０４）。
【０１１４】
［実施例２による効果］
実施例２によれば、大量のキャッシュデータなしに、画面データの処理方法切替時のデータ重複を排除し、更新開始時の送信データ量を削減することができる。また、マウスの操作情報などを操作トリガとして利用することで、大量の更新が発生する可能性が高い場合のみ開示する処理を適用することができる。また、実施例２の処理によって更新された画面領域の場所を記憶することで、通信量が少ないときに更新を行うことができ、この場合であっても高画質を維持できる。
【実施例３】
【０１１５】
ところで、開示するシステムは、クライアント装置に画像で画面更新データを送信した際に利用した画像圧縮形式を保持し、擬似Ｉフレームを取得する際に画像圧縮形式情報を取得する。そして、このシステムは、取得した画像圧縮形式情報をフレームバッファ蓄積部から取得した画面データに適用することでより正確な擬似Ｉフレームを生成することができる。
【０１１６】
そこで、実施例３では、画像圧縮形式情報を保持しておき、正確な擬似Ｉフレームを生成する例について説明する。ここでは、装置の構成、処理の流れ、効果を説明する。なお、クライアント装置の構成は、実施例２と同様であるので、詳細な説明は省略する。
【０１１７】
［装置の構成］
図１６は、実施例３に係るサーバ装置の構成を示すブロック図である。図１６に示すように、このサーバ装置１０は、通信部１１、操作情報取得部１２、ＯＳ実行部１３、表示画面生成部１４、サーバ側リモート画面制御部１５を有する。なお、通信部１１、操作情報取得部１２、ＯＳ実行部１３、画面生成部１４は、図６と同様なので、詳細な説明は省略する。
【０１１８】
サーバ側リモート画面制御部１５は、フレームバッファ１６、フレームバッファ蓄積部１７、更新差分作成部１８、高頻度画面更新領域検出部１９、更新差分画像変換部２０を有する。さらに、サーバ側リモート画面制御部１５は、擬似Ｉフレーム処理部２１、更新差分動画変換部２２、画面更新通知部２３を有する。さらに、サーバ側リモート画面制御部１５は、フレームバッファ変換情報蓄積部３０を有する。なお、フレームバッファ変換情報蓄積部３０以外の処理部は、図６と同様の処理を実行するので、ここでは詳細な説明は省略する。
【０１１９】
フレームバッファ変換情報蓄積部３０は、クライアント装置に送信されたデータに利用される画像圧縮形式を保持する。例えば、フレームバッファ変換情報蓄積部３０は、更新差分動画変換部２２において利用された変換方式と更新した領域情報とを取得して保持する。そして、擬似Ｉフレーム処理部２１が高頻度画面更新領域の情報を受け取った際に、領域情報を検索キーとして、フレームバッファ変換情報蓄積部３０を検索する。その後、擬似Ｉフレーム処理部２１は、一致するものがあればフレームバッファ１６から取得した該当領域に対してその圧縮方式を適用した上で、再度展開して擬似Ｉフレームとして利用する。
【０１２０】
［処理の流れ］
次に、図１７と図１８を用いて、実施例３に係るサーバ装置が実行する処理について説明する。ここでは、実施例２とは異なる処理として、更新差分画像変換処理と擬似Ｉフレーム作成処理について説明する。
【０１２１】
（更新差分画像変換処理）
図１７は、実施例３に係るサーバ装置が実行する更新差分画像変換処理の流れを示すフローチャートである。図１７に示すように、更新差分画像変換部２０は、更新された矩形の情報を高頻度画面更新領域検出部１９から受信すると（Ｓ９０１肯定）、Ｓ９０２を実行する。すなわち、更新差分画像変換部２０は、更新矩形情報から領域情報を読み込んで、フレームバッファ１６から該当領域の画面データを取得する（Ｓ９０２）。
【０１２２】
そして、更新差分画像変換部２０は、クライアント装置５０との間で予め取り決められた非可逆圧縮方式または前回画面データを生成した際に利用した非可逆圧縮方式で画面データを圧縮する（Ｓ９０３）。その後、更新差分画像変換部２０は、画面データを生成した領域の情報と、圧縮方式とを対応付けてフレームバッファ変換情報蓄積部３０に通知し（Ｓ９０４）、生成した画面データを画面更新通知部２３に出力する（Ｓ９０５）。
【０１２３】
（擬似Ｉフレーム作成処理）
図１８は、実施例３に係るサーバ装置が実行する擬似Ｉフレーム作成処理の流れを示すフローチャートである。図１８に示すように、擬似Ｉフレーム処理部２１は、更新差分画像変換部２０から高頻度画面が存在することを受信した場合（Ｓ１００１肯定）、送信済みの最新のフレーム番号を画面更新通知部２３から取得する（Ｓ１００２）。
【０１２４】
続いて、擬似Ｉフレーム処理部２１は、取得した最新のフレーム番号に対応するフレームデータをフレームバッファ蓄積部１７から取得する（Ｓ１００３）。そして、擬似Ｉフレーム処理部２１は、高頻度画面更新領域を更新差分画像変換部２０から取得するとともに、この領域に一致する領域の画面データをフレームバッファ蓄積部１７から取得する（Ｓ１００４）。その後、擬似Ｉフレーム処理部２１は、フレームバッファ変換情報蓄積部３０から該当領域の圧縮方式を取得する（Ｓ１００５）。
【０１２５】
そして、擬似Ｉフレーム処理部２１は、取得した圧縮方式が可逆圧縮である場合（Ｓ１００６肯定）、Ｓ１００４で取得した画像データを擬似Ｉフレームとして、更新差分動画変換部２２へ出力する（Ｓ１００７）。
【０１２６】
一方、擬似Ｉフレーム処理部２１は、取得した圧縮方式が可逆圧縮でない場合（Ｓ１００６否定）、取得した圧縮方式で、Ｓ１００４で取得した画像データを圧縮後、再展開したデータを擬似Ｉフレームとして、更新差分動画変換部２２へ出力する（Ｓ１００８）。
【０１２７】
［実施例３による効果］
クライアント装置とサーバ装置双方のフレームバッファは、同一のものが存在することを想定している。このように画面データ転送時に同一のデータを転送しようとするとする場合、可逆圧縮方式と呼ばれる比較的データ量が大きい方法で画像を圧縮する必要がある。そのため、データの欠落を許容することでデータ量を小さくすることが可能な非可逆圧縮方式で画面データを圧縮して転送することも可能である。しかし、クライアントに対して非可逆圧縮方式で画面データを送信すると、サーバに存在するフレームバッファとクライアントのそれの整合性がとれない事象が発生する恐れもある。
【０１２８】
そこで、実施例３のように、サーバ装置１０に「フレームバッファ変換情報蓄積部３０」を加えて、領域毎の圧縮方式や圧縮品質を保持しておくことで、クライアント装置とサーバ装置間で同一の擬似Ｉフレームを生成可能となる。
【実施例４】
【０１２９】
ところで、開示するシステムは、既存のＭＰＥＧ符号化器や復号器に手を加えずにＩフレームを排除し、データ転送量を削減することもできる。そこで、実施例４では、既存のＭＰＥＧ符号化器や復号器に手を加えずにＩフレームを排除例について説明する。ここでは、装置の構成、処理の流れ、効果を説明する。なお、クライアント装置の構成は、実施例２と同様であるので、詳細な説明は省略する。
【０１３０】
［装置の構成］
図１９は、実施例４に係るサーバ装置の構成を示すブロック図である。図１９に示すように、このサーバ装置１０は、通信部１１、操作情報取得部１２、ＯＳ実行部１３、表示画面生成部１４、サーバ側リモート画面制御部１５を有する。なお、通信部１１、操作情報取得部１２、ＯＳ実行部１３、画面生成部１４は、図６と同様なので、詳細な説明は省略する。
【０１３１】
サーバ側リモート画面制御部１５は、フレームバッファ１６、フレームバッファ蓄積部１７、更新差分作成部１８、高頻度画面更新領域検出部１９、更新差分画像変換部２０を有する。さらに、サーバ側リモート画面制御部１５は、擬似Ｉフレーム処理部２１、更新差分動画変換部２２、画面更新通知部２３を有する。さらに、サーバ側リモート画面制御部１５は、Ｉフレームデータ排除部３１を有する。なお、Ｉフレームデータ排除部３１以外の処理部は、図６と同様の処理を実行するので、ここでは詳細な説明は省略する。
【０１３２】
Ｉフレームデータ排除部３１は、擬似Ｉフレーム処理部２１によって生成されたＭＰＥＧデータ中から先頭のＩフレームのデータを排除する処理部である。例えば、Ｉフレームデータ排除部３１は、擬似Ｉフレーム処理部２１からＩフレームを排除するよう通知を受信した場合、擬似Ｉフレーム処理部２１から受信したＭＰＥＧデータの先頭からＩフレームを排除して、画面更新通知部２３に出力する。
【０１３３】
［処理の流れ］
図２０は、実施例４に係るサーバ装置が実行する擬似Ｉフレーム作成処理の流れを示すフローチャートである。図２０に示すように、擬似Ｉフレーム処理部２１は、高頻度画面更新領域検出部１９から高頻度画面更新領域を受信する（Ｓ１１０１肯定）。すると、擬似Ｉフレーム処理部２１は、画面更新通知部２３から送信済みフレームのうち最新値を取得し（Ｓ１１０２）、フレームバッファ蓄積部１７に蓄積されている最新のフレームバッファの番号を取得する（Ｓ１１０３）。
【０１３４】
続いて、擬似Ｉフレーム処理部２１は、画面更新通知部２３から取得したフレーム番号と、フレームバッファ蓄積部１７から取得したフレーム番号とが一致するか否かを判定する（Ｓ１１０４）。なお、フレームバッファ蓄積部１７へ先に新しい画面データが書き込まれるため、処理のタイミングによっては動画作成時のＩフレームに相当するデータがクライアントへ届いていない場合、つまり画面更新通知部２３のフレーム番号が古い場合が存在する。そのような場合には、Ｐフレームから始まるデータをクライアントへ送信しても疑似Ｉフレームが生成できない可能性がある。このような場合のために一致判定を行う。
【０１３５】
そして、擬似Ｉフレーム処理部２１は、両方のフレーム番号が一致する場合（Ｓ１１０４肯定）、Ｉフレームデータ排除部３１に次のＭＰＥＧデータ、すなわちこれから通知されるＭＰＥＧデータの先頭Ｉフレームを排除する通知を出力する（Ｓ１１０５）。なお、擬似Ｉフレーム処理部２１は、両方のフレーム番号が一致しない場合（Ｓ１１０４否定）、Ｓ１１０５を実行することなくＳ１１０６を実行する。
【０１３６】
その後、擬似Ｉフレーム処理部２１は、高頻度画面更新領域検出部１９から取得した高頻度更新領域を更新差分動画変換部２２に出力する（Ｓ１１０６）。この結果、Ｉフレームデータ排除部３１は、更新差分動画変換部２２から取得したＭＰＥＧデータの先頭のＩフレームを削除して画面更新通知部２３に出力する。
【０１３７】
［実施例４による効果］
このように、サーバ装置に「Iフレームデータ排除部３１」をさらに加え、生成されたＭＰＥＧデータ中から先頭のＩフレームのデータを排除した上でクライアント装置に転送する。クライアント装置では、自身のフレームバッファから取得した擬似Ｉフレームを、受信したＭＰＥＧデータの先頭に付与することでデータ転送量を削減可能である。
【実施例５】
【０１３８】
さて、これまで本発明の実施例について説明したが、本発明は上述した実施例以外にも、種々の異なる形態にて実施されてよいものである。そこで、以下に異なる実施例を説明する。
【０１３９】
（送信手法の切替）
例えば、実施例１から実施例４では、画像送信から動画送信に切り替える例を説明しているがこれに限定されるものではない。例えば、開示するシステムは、動画データによる更新から別の動画データ形式への切り替え時や、動画データによる更新から画像データ形式への切り替え時にも適用可能である。
【０１４０】
また、切り替えるトリガ、言い換えると激しい操作の例としては、サーバ装置は、クライアント装置からマウスのダウンクリックを検出してから、アップクリックを検出するまでの時間が所定時間となった場合に、激しい操作が行われたと検出する。また、サーバ装置は、ダウンクリックからアップクリックまでの距離が所定値以上となった場合に、激しい操作が行われたと検出する。
【０１４１】
（送信手法の戻し）
例えば、実施例１から実施例４で説明した手法で、画像送信から動画送信に切り替えた後に、元の画像送信に切り戻すタイミングは、任意に設定できる。例えば、動画化される領域が一定になったタイミング、もしくは更新が少ない状態で一定時間経った場合に、元の送信手法に戻してもよい。
【０１４２】
（動画圧縮）
例えば、実施例１から実施例４では、ＭＰＥＧ技術で利用されるＩフレーム、Ｐフレームを用いた例で説明しているが、開示するシステムの適用範囲はＭＰＥＧ技術だけではなく、他の動画圧縮形式にも適用可能ある。つまり、実施例で例示したＩフレーム、Ｐフレームは、動画圧縮方式一般で利用される基準画像、差分画像に相当するものである。
【０１４３】
（システム）
また、本実施例において説明した各処理のうち、自動的におこなわれるものとして説明した処理の全部または一部を手動的におこなうこともできる。あるいは、手動的におこなわれるものとして説明した処理の全部または一部を公知の方法で自動的におこなうこともできる。この他、上記文書中や図面中で示した処理手順、制御手順、具体的名称、例えば図３等に示した各種のデータやパラメータを含む情報については、特記する場合を除いて任意に変更することができる。
【０１４４】
また、図示した各装置の各構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、任意の処理部を統合するなど各装置の分散・統合の具体的形態は図示のものに限られない。つまり、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。さらに、各装置にて行なわれる各処理機能は、その全部または任意の一部が、ＣＰＵおよび当該ＣＰＵにて解析実行されるプログラムにて実現され、あるいは、ワイヤードロジックによるハードウェアとして実現され得る。
【０１４５】
また、各実施例で説明した操作情報取得部は、加速度センサや光センサ、地磁気センサ、温度センサなどのユーザの周辺状況および端末へのユーザの動作をセンシング可能なセンサでも良い。また、操作情報取得部は、タッチパネルやキーボードやマイクロフォンなどのユーザが直接入力を行う機器でも構わない。また、本実施例ではクライアント装置としてサーバ装置上のデスクトップ環境と同サイズの出力が可能なクライアント装置を利用しているが、これに限定されるものではない。例えば、画面の表示サイズを縮小することでこれ以外のＰＤＡやノートＰＣ、携帯ゲーム機、携帯音楽プレイヤーなどの画面サイズの小さな端末上にも適用可能である。また、サーバ装置側のＯＳ実行部は特定のアーキテクチャに依存せず、どのようなＯＳでも構わない。
【０１４６】
（プログラム）
ところで、上記の実施例で説明した各種の処理は、あらかじめ用意されたプログラムをパーソナルコンピュータやワークステーションなどのコンピュータシステムで実行することによって実現することができる。そこで、以下では、上記の実施例と同様の機能を有するプログラムを実行するコンピュータシステムの一例を説明する。
【０１４７】
図２１は、画像送信プログラムを実行するコンピュータのハードウェア構成例を示す図である。図２１に示すように、コンピュータシステム１００は、バス１０１に、ＣＰＵ１０２、入力装置１０３、出力装置１０４、通信インタフェース１０５、ＨＤＤ（Hard Disk Drive）１０６、ＲＡＭ（Random Access Memory）１０７が接続される。
【０１４８】
入力装置１０３は、マウスやキーボードであり、出力装置１０４は、ディスプレイなどであり、通信インタフェース１０５は、ＮＩＣ（Network Interface Card）などのインタフェースである。ＨＤＤ１０６には、画像送信プログラム１０６ａととともに、図６等に示した各バッファ等に記憶される情報が記憶される。記録媒体の例としてＨＤＤ１０６を例に挙げたが、ＲＯＭ（Read Only Memory）、ＲＡＭ（Random Access Memory）、ＣＤ−ＲＯＭ等の他のコンピュータ読み取り可能な記録媒体に各種プログラムを格納しておき、コンピュータに読み取らせることとしてもよい。なお、記憶媒体を遠隔地に配置し、コンピュータが、その記憶媒体にアクセスすることでプログラムを取得して利用してもよい。また、その際、取得したプログラムをそのコンピュータ自身の記録媒体に格納して用いてもよい。
【０１４９】
ＣＰＵ１０２は、画像送信プログラム１０６ａを読み出してＲＡＭ１０７に展開することで、図６等で説明した各機能を実行する画像送信プロセス１０７ａを動作させる。すなわち、画像送信プロセス１０７ａは、図６、図１６、図１９に記載したサーバ側リモート画面制御部１５が有する各処理部と同様の機能を実行する。このようにコンピュータシステム１００は、プログラムを読み出して実行することでリモート画面送信制御方法を実行する情報処理装置として動作する。
【符号の説明】
【０１５０】
１、１０ サーバ装置
１ａ 通信部
１ｂ 第１の画像メモリ
１ｃ 第２の画像メモリ
１ｄ 第１の画像送信部
１ｅ 第２の画像送信部
５、５０ クライアント装置
５ａ 通信部
５ｂ 画像メモリ
５ｃ 表示部
５ｄ 画像生成部
１１ 通信部
１２ 操作情報取得部
１３ ＯＳ実行部
１４ 表示画面生成部
１５ サーバ側リモート画面制御部
１６ フレームバッファ
１７ フレームバッファ蓄積部
１８ 更新差分作成部
１９ 高頻度画面更新領域検出部
２０ 更新差分画像変換部
２１ 擬似Ｉフレーム処理部
２２ 更新差分動画変換部
２３ 画面更新通知部
５１ 通信部
５２ 表示部
５３ 画面表示部
５４ 操作情報取得部
５５ クライアント側リモート画面制御部
５６ 画面更新情報取得部
５７ 画像データ処理部
５８ 擬似Ｉフレーム処理部
５９ 動画データ処理部
【技術分野】
【０００１】
本発明は、情報処理装置、画像送信プログラム、画像送信方法および画像表示方法に関する。
【背景技術】
【０００２】
シンクライアントというシステムが知られている。シンクライアントシステムでは、クライアントに最低限の機能しか持たせず、サーバでアプリケーションやファイルなどのリソースを管理するようにシステムが構築される。
【０００３】
かかるシンクライアントシステムは、実際にはサーバが処理を実行した処理結果やサーバが保持するデータをクライアントに表示させつつも、あたかもクライアントが主体となって処理を実行したり、データを保持しているかのように振る舞う。このシンクライアントシステムで通信に用いられるプロトコルには、例えばＲＤＰ（Remote Desktop Protocol）や、ＶＮＣ（Virtual Network Computing）で用いられているＲＦＢ（Remote Frame Buffer）プロトコルなどがある。
【０００４】
シンクライアントシステムでは、文章作成アプリケーションやＷｅｂブラウザだけでなく、ＣＡＤ（Computer-Aided Design）アプリケーションも利用できる。ＣＡＤアプリケーションでは、基盤の配線や３Ｄモデルの作成をワイヤフレームとよばれるデータで処理が実行される。そして、データによってはより詳細な描画データを作成するレンダリングと呼ばれる作業や、ワイヤフレームを様々な角度から眺めて不具合やおかしな部分や全体を検査するといった作業が行われる。そのため、ＣＡＤアプリケーションなどをシンクライアントシステム上で利用する場合には大量のデータを転送することが要求される。
【０００５】
このようなアプリケーションを利用する場合、全ての画面データをそのままの形で転送すると数１００Ｍｂｉｔｓ／秒のネットワークの帯域幅を消費してしまう。そのため、画面データを転送する場合には圧縮処理を行った上でデータを転送する。圧縮処理を行う場合には、画質とデータ量のトレードオフによって特定時間あたりのデータ量を変化させる。
【０００６】
しかし、利用可能なネットワーク帯域は常に一定ではなく時間帯や接続しているネットワーク自体においても増減が発生する。さらに、利用するアプリケーションによって必要とするネットワーク帯域幅が異なるため、単純に一つの圧縮方式と特定の画質設定に応じて圧縮や転送を行った場合、必要なネットワーク帯域幅が足りずに圧縮画面データを転送できないといった問題が発生する。また、利用可能なネットワーク帯域幅を十分に利用できずに画像品質を向上できないといった問題が発生する。なお、かかる問題は、シンクライアントシステムでクライアントとサーバ間で画面更新時に大容量のデータ送信が発生する場合に共通するものであり、画像や動画を扱う場合に限定して生じる問題ではない。
【０００７】
このことから、サーバとクライアント間におけるデータ転送量を削減し、操作レスポンスを改善する技術が開示されている。一例として、ディスプレイ画面のデータを転送する場合に現在利用可能なネットワークの帯域幅に応じて圧縮率の異なる画像圧縮方式を適用することで、転送量を最適化する技術が存在する。この技術では、利用可能な帯域幅が少ない場合には、画面データを不可逆圧縮方式で圧縮することで画像品質を削減することと引き替えに、必要なデータ転送量を大きく削減する。逆に、利用可能な帯域幅が大きい場合には、可逆圧縮方式での圧縮や非圧縮で画像データを転送することで、膨大な帯域幅を消費しつつも高品質の画像データを転送する。このように、この技術は、ネットワーク帯域幅の状況に応じて切り替えることで、適切な転送量と画質を維持している。
【先行技術文献】
【特許文献】
【０００８】
【特許文献１】特表２００７−５０５５８０号公報
【発明の概要】
【発明が解決しようとする課題】
【０００９】
しかしながら、従来の技術では、データ転送量が大きいという問題があった。
【００１０】
例えば、ある時点において画面データを画像として圧縮および転送しており、ネットワーク帯域や利用アプリの変化によって、次の時点で動画データとして画面データを圧縮おおび転送する処理に切り替わった場合を想定する。この場合、動画データとして画面データを圧縮する際には、画像によって圧縮された画面データに対する次の更新が発生した画面から圧縮が行われる。
【００１１】
しかし、画像で圧縮された画面（以下、前フレームという）と、動画で圧縮された画面（以下、後フレームという）の間では全ての領域で無関係に更新が行われているということはまれで、前フレームと後フレームのデータは似通っているという関係がある。動画だけでの圧縮の場合、一般的にこの関係を利用し、差分データのみを含むフレーム（以下、Ｐフレームという）の送信を行い、少ないデータ量での表示を実現している。ところが、従来技術の場合、このような差分データによるデータ更新は行われず、差分データの元になる対象領域の全データを含むフレーム（以下、Ｉフレームという）から動画データが生成され、画面データとして圧縮および転送が行われる。
【００１２】
例えば、画像データで転送を行った前フレームと動画データで転送を行った後フレームのデータは似通っているにもかかわらず、動画データ中でＩフレームとして圧縮および送信されてしまうため、重複したデータの転送が発生している。すなわち、データ転送量の大きい静止画を重複して送信することになり、データ転送量が削減できているとは言い難い。
【００１３】
開示の技術は、上記に鑑みてなされたものであって、データ転送量を削減できる情報処理装置、画像送信プログラム、画像送信方法および画像表示方法を提供することを目的とする。
【課題を解決するための手段】
【００１４】
本願の開示する情報処理装置は、一つの態様において、前記画像を保持する第１の画像メモリと、前記画像を前記端末装置へ送信する第１の画像送信部とを有する。また、開示する情報処理装置は、前記第１の画像送信部で送信した画像を保持する第２の画像メモリと、前記画像を基準画像と差分画像とを組み合わせて送信する第２の画像送信部とを有する。また、開示する情報処理装置の第２の画像送信部は、前記第１の画像送信部から前記第２の画像送信部に送信を切り換える際に、前記第２の画像メモリに保持された画像を前記基準画像に設定し、前記基準画像を基に、前記第１の画像メモリに保持された画像から前記差分画像を生成する。そして、開示する情報処理装置の第２の画像送信部は、前記基準画像を端末装置に送信済みの画像から取得する信号と共に前記差分画像を送信する。
【発明の効果】
【００１５】
本願の開示する情報処理装置、画像送信プログラム、画像送信方法および画像表示方法の一つの態様によれば、画像品質の劣化を防止しつつ、データ転送量を削減できるという効果を奏する。
【図面の簡単な説明】
【００１６】
【図１】図１は、実施例１に係るシンクライアントシステムの構成を示す図である。
【図２】図２は、実施例１に係るシステムの流れを説明する図である。
【図３】図３は、サーバ装置がクライアント装置に送信した画像の例を示す図である。
【図４】図４は、クライアント操作の例を示す図である。
【図５】図５は、クライアント装置が差分画像を用いて動画を生成する処理の例を示す図である。
【図６】図６は、実施例２に係るシステムが有する各装置の構成を示すブロック図である。
【図７】図７は、更新差分動画変換部の内部処理の例を示す図である。
【図８】図８は、動画データ処理部の内部処理の例を示す図である。
【図９】図９は、実施例２に係るサーバ装置が実行する処理の全体的な流れを示すフローチャートである。
【図１０】図１０は、実施例２に係るサーバ装置が実行するフレームバッファ蓄積処理の流れを示すフローチャートである。
【図１１】図１１は、実施例２に係るサーバ装置が実行する擬似Ｉフレーム作成処理の流れを示すフローチャートである。
【図１２】図１２は、実施例２に係るサーバ装置が実行する更新差分動画作成処理の流れを示すフローチャートである。
【図１３】図１３は、実施例２に係るクライアント装置が実行する処理の全体的な流れを示すフローチャートである。
【図１４】図１４は、実施例２に係るクライアント装置が実行する擬似Ｉフレーム処理の流れを示すフローチャートである。
【図１５】図１５は、実施例２に係るクライアント装置が実行する動画データ処理の流れを示すフローチャートである。
【図１６】図１６は、実施例３に係るサーバ装置の構成を示すブロック図である。
【図１７】図１７は、実施例３に係るサーバ装置が実行する更新差分画像変換処理の流れを示すフローチャートである。
【図１８】図１８は、実施例３に係るサーバ装置が実行する擬似Ｉフレーム作成処理の流れを示すフローチャートである。
【図１９】図１９は、実施例４に係るサーバ装置の構成を示すブロック図である。
【図２０】図２０は、実施例４に係るサーバ装置が実行する擬似Ｉフレーム作成処理の流れを示すフローチャートである。
【図２１】図２１は、画像送信プログラムを実行するコンピュータのハードウェア構成例を示す図である。
【発明を実施するための形態】
【００１７】
以下に、本願の開示する情報処理装置、画像送信プログラム、画像送信方法および画像表示方法の実施例を図面に基づいて詳細に説明する。なお、この実施例によりこの発明が限定されるものではない。
【実施例１】
【００１８】
実施例１では、シンクライアントシステムの全体構成、シンクライアントシステムを形成する各装置の構成、処理の流れ等を説明する。
【００１９】
［全体構成］
図１は、実施例１に係るシンクライアントシステムの構成を示す図である。図１に示すように、このシステムは、サーバ装置１とクライアント装置５とを有する。なお、各装置の台数はあくまで例示であり、これに限定されるものではない。
【００２０】
このシンクライアントシステムは、クライアント装置５が表示する画面をリモートでサーバ装置１に制御させるものである。つまり、シンクライアントシステムは、実際にはサーバ装置１が実行した処理結果や保持するデータをクライアント装置５に表示させつつも、あたかもクライアント装置５が主体となって処理を実行したり、データを保持しているかのように振る舞う。
【００２１】
これらサーバ装置１及びクライアント装置５は、所定のネットワークを介して、相互に通信可能に接続される。かかるネットワークには、有線または無線を問わず、インターネット、ＬＡＮ（Local Area Network）やＶＰＮ（Virtual Private Network）などの任意の種類の通信網を採用できる。なお、サーバ装置１及びクライアント装置５間の通信プロトコルには、一例として、ＶＮＣ（Virtual Network Computing）におけるＲＦＢ（Remote Frame Buffer）プロトコルを採用する場合を想定する。
【００２２】
サーバ装置１は、クライアント装置５に表示させる画面をリモートで制御するサービスを提供するコンピュータである。一例としては、サーバ装置１は、クライアント装置５における操作情報を取得した上でその操作により要求された処理を自装置で動作するアプリケーションに実行させる。そして、サーバ装置１は、アプリケーションにより実行された処理結果を表示するための画面を生成した上で、その画面をクライアント装置５へ送信する。
【００２３】
クライアント装置５は、サーバ装置１によるリモート画面制御サービスの提供を受ける側のコンピュータである。かかるクライアント装置５の一例としては、パーソナルコンピュータなど固定端末の他、携帯電話機、ＰＨＳ（Personal Handyphone System）やＰＤＡ（Personal Digital Assistant）などの移動体端末を適用することもできる。
【００２４】
［サーバの構成］
図１に示すように、サーバ装置１は、通信部１ａ、第１の画像メモリ１ｂ、第２の画像メモリ１ｃ、第１の画像送信部１ｄ、第２の画像送信部１ｅ、ＯＳ（Operating System）実行部１ｆを有する。通信部１ａは、クライアント装置５との間の通信を制御するインタフェースであり、クライアント装置５に画像等を送信したり、クライアント装置５で実行された操作等を受信する。
【００２５】
第１の画像メモリ１ｂは、コンピュータの上で実行されているＯＳ自身ならびにＯＳ上で動作するアプリケーションが行ったデスクトップ画面への描画処理の実行結果を保持する。つまり、第１の画像メモリ１ｂは、サーバ装置１がリモート画面制御サービスとしてクライアント装置５に提供するための元データとなるデスクトップ画面の最新の画像データを保持する。
【００２６】
第２の画像メモリ１ｃは、後述する第１の画像送信部１ｄで送信した画像を保持する。つまり、第２の画像メモリ１ｃは、サーバ装置１がリモート画面制御サービスとしてクライアント装置５に提供した、送信済みの画像を保持する。例えば、第２の画像メモリ１ｃは、送信された順序や時系列で送信済みのリモート画面を保持する。第１の画像メモリでは、非同期に異なる間隔でＯＳやアプリケーションから更新画像が書き込まれる。一方、第１の画像送信部は、必ずしもＯＳ実行部１ｆから画像メモリへの書き込み毎にデータを取得するとは限らない。また、第１の画像メモリ１ｂから第２の画像メモリ１ｃへ直接コピーを行うと、クライアントへ送信したデータと同期がとれない可能性がある。ゆえに、サーバ装置１は、第１の画像送信部１ｄ経由で画像メモリデータを第２の画像メモリ１ｃへコピーする。
【００２７】
第１の画像送信部１ｄは、第１の画像メモリ１ｂに保持される画像を一定間隔で取得しクライアント装置５へ送信するとともに第２の画像メモリへも送信（コピー）する。例えば、ＯＳ実行部１ｆは、クライアント装置５における操作情報を取得した上で、その操作により要求された処理を自装置で動作するアプリケーションに実行させる。そして、ＯＳ実行部１ｆは、アプリケーションにより実行された処理結果を表示するための画像を生成して第１の画像メモリ１ｂに格納する。そして、第１の画像送信部１ｄは、第１の画像メモリ１ｂに格納された画像をあるタイミングでコピーした上で変換を行いクライアント装置へ送信する。この送信処理と同時に変換に利用した画像メモリのデータを第２の画像メモリ１ｃに格納する。
【００２８】
第２の画像送信部１ｅは、第１の画像送信部１ｄから第２の画像送信部１ｅに送信を切り換える際に、第２の画像メモリ１ｃに保持された画像で最新のものを基準画像に設定する。そして、第２の画像送信部１ｅは、基準画像を基に、第１の画像メモリ１ｂから一定間隔で画像データを取得して差分画像を生成し、基準画像をクライアント装置５に送信済みの画像から取得する信号と共に差分画像を送信する。
【００２９】
例えば、第２の画像送信部１ｅは、所定の契機で、第１の画像送信部１ｄが実行していた画像送信から、動画送信に送信手法を変更する。そして、第２の画像送信部１ｅは、送信手法を切り替えるタイミングでクライアント装置５が表示していたリモート画面、すなわち、第２の画像メモリ１ｃが保持する最新画像を基準画像に決定する。続いて、第２の画像送信部１ｅは、切り替え以降の画像送信データを基準画像をもとにした差分画像として生成する。ここでの差分画像は第２の画像送信部が一定間隔で第１の画像メモリから画面データを取得し、基準画像と比較することで生成される。その後、第２の画像送信部１ｅは、基準画像をクライアント装置５に送信済みの画像から取得する信号と共に、差分画像をクライアント装置５に送信する。
【００３０】
つまり、第２の画像送信部１ｅは、画像送信から動画送信に切り替えた際に、いわゆるＩフレームについてはＰフレームを生成する際にだけ使用し、Ｐフレームのみをクライアント装置５に送信する。
【００３１】
［クライアント装置の構成］
図１に示すように、クライアント装置５は、通信部５ａ、画像メモリ５ｂ、表示部５ｃ、画像生成部５ｄを有する。通信部５ａは、サーバ装置１との間の通信を制御するインタフェースであり、例えば、サーバ装置１から画像等を受信したり、サーバ装置１に操作情報を送信したりする。
【００３２】
画像メモリ５ｂは、サーバ装置１から受信した画像や保持する。例えば、画像メモリ５ｂは、リモート画面として受信した画像を画像生成部で展開・復号処理した結果を保持する。表示部５ｃは、画像メモリ上に書き込まれた画像データを表示するディスプレイやタッチパネルなどの表示装置であり、マウス等と連携してポインティングデバイスを提供する。
【００３３】
画像生成部５ｄは、サーバ装置１から画像を受信した場合には、受信した画像を画像メモリ５ｂに格納する。また、画像生成部５ｄは、基準画像を送信済みの画像から取得する信号と共に差分画像を受信した場合に、画像メモリ５ｂに記憶される画像を取得して擬似基準画像とする。そして、画像生成部５ｄは、擬似基準画像と受信した差分画像とを用いて動画を生成し、生成した動画を画像メモリ５ｂに格納する。その後、クライアント装置５内のＯＳ等は、画像メモリ５ｂから読み出してリモート画面として表示部５ｃに再生する。
【００３４】
つまり、画像生成部５ｄは、サーバ装置１からＰフレームと所定信号とを受信した場合に、直前まで表示部５ｃに表示されていた画像を擬似Ｉフレームと決定する。そして、画像生成部５ｄは、決定した擬似Ｉフレームと受信したＰフレームとを用いて、動画を再生する。
【００３５】
［処理の流れ］
図２は、実施例１に係るシステムの流れを説明する図である。図２に示すように、サーバ装置１の第１の画像送信部１ｄは、第１の画像メモリ１ｂから取得し更新のあった領域の画像を差分画像としてクライアント装置５へ送信する（Ｓ１０１とＳ１０２）。つまり、サーバ装置１は、クライアント装置５における操作情報を取得した上で、その操作により要求された処理を自装置で動作するアプリケーションに実行させ、実行された処理結果を表示するための画像を生成してクライアント装置５へ送信する。
【００３６】
この画像を受信したクライアント装置５の画像生成部５ｄは、サーバ装置１から受信した画像を画像メモリ５ｂに格納し、これが表示部へと出力される（Ｓ１０３）。
【００３７】
その後、所定契機を検出したサーバ装置１の第２の画像送信部１ｅは、送信手法を切り替えると判定し、送信手法を切り替えるタイミングでクライアント装置５が表示していたリモート画面を基準画像に決定する（Ｓ１０４とＳ１０５）。すなわち、第２の画像送信部１ｅは、第２の画像メモリ１ｃが保持する最新画像を基準画像に決定する。
【００３８】
そして、第２の画像送信部１ｅは、基準画像を基に、基準画像からクライアント装置５に表示させる画像までの差分画像を第１の画像メモリ１ｂに保持された画像を一定間隔で取得し基準画像との比較から生成する（Ｓ１０６）。
【００３９】
その後、第２の画像送信部１ｅは、基準画像をクライアント装置５に送信済みの画像から取得させる信号と共に、差分画像をクライアント装置５に送信する（Ｓ１０７とＳ１０８）。
【００４０】
この差分画像および信号を受信したクライアント装置５の画像生成部５ｄは、差分画像を受信する直前の画像、言い換えると、表示部５ｃに表示していた最新画像を擬似基準画像とし、擬似基準画像と差分画像を用いて動画を生成する（Ｓ１０９とＳ１１０）。そして、画像生成部５ｄは、生成した動画を画像メモリ５ｂに格納するとともに、リモート画面として表示部５ｃに表示させる（Ｓ１１１）。
【００４１】
［送信手法切替の具体例］
次に、図３〜図５を用いて、図１に示したシステムで実行される画面送信手法の切替例を説明する。図３は、サーバ装置がクライアント装置に送信した画像の例を示す図である。図４は、クライアント操作の例を示す図である。図５は、クライアント装置が差分画像を用いて動画を生成する処理の例を示す図である。
【００４２】
まず、サーバ装置１は、図３に示した画像Ａを生成してクライアント装置５に送信する。その後、クライアント装置５では、図４に示したように、表示画像Ａを所定値以上移動させる画像操作が実行される。サーバ装置１は、図４に示した画像操作をトリガとして、画像送信の手法を切り替える。
【００４３】
そして、サーバ装置１は、図４の画像操作が実行されるまでクライアント装置に表示されていた図３に示す画像Ａを基準画像とし、この基準画像を基に、図４に示す画像Ａから画像Ｂまでの差分画像を生成する。その後、サーバ装置１は、基準画像を送信済みの画像から取得する信号と共に、生成した差分画像をクライアント装置５に送信する。なお、画像Ａから画像Ｂまで移動する場合、基準画像は今までの各フレームの差分画像との和に変更される。
【００４４】
すると、クライアント装置５では、基準画像を受信する直前に受信した画像、すなわち図３の画像Ａを擬似基準画像として、図５に示すように、この擬似基準画像と受信した差分画像とを用いて動画を生成して表示部５ｃに再生する。
【００４５】
［実施例１による効果］
実施例１に係るシステムでは、圧縮方式を切り替えながら画面の更新データを送信するシーンにおいて、サーバ装置とクライアント装置双方に存在するフレームを擬似基準画像として利用することで、重複をなくしデータ転送量を削減可能である。すなわち、サーバ装置１がデータ転送量の大きい静止画を送信しないにも関らず、クライアント装置５では動画を表示させることができる。したがって、データ転送量を削減できる。
【実施例２】
【００４６】
次に、サーバ装置が通常時には静止画像をクライアント装置に送信し、トリガを検出した場合に、静止画像からＭＰＥＧ（Moving Picture Expert Group）送信に切り替える例について説明する。ここでは、システムが有する各装置の構成、処理の流れ、効果について説明する。なお、ここで例示する圧縮形式は、ＭＰＥＧ−２でもＭＰＥＧ−４でもよく、圧縮形式を限定するものではない。
【００４７】
［各装置の構成］
図６は、実施例２に係るシステムが有する各装置の構成を示すブロック図である。図６に示すように、このシステムは、サーバ装置１０とクライアント装置５０とを有するので、ここでは各装置の構成を説明する。
【００４８】
（サーバの構成）
図６に示すように、サーバ１０は、通信部１１、操作情報取得部１２、ＯＳ（Operating System）実行部１３、表示画面生成部１４、サーバ側リモート画面制御部１５を有する。なお、図６の例では、図６に示した機能部以外にも既知のコンピュータが有する各種の機能部、例えば各種の入力デバイスや表示デバイスなどの機能を有するものとする。
【００４９】
通信部１１は、クライアント装置５０との間でデータの送受信を行う通信インタフェースである。例えば、通信部１１は、後述する画面更新通知部２３から出力された画像や差分画像をクライアント装置５０に送信する。また、通信部１１は、クライアント装置５０から操作情報を受信して操作情報取得部１２に出力する。
【００５０】
操作情報取得部１２は、通信部１１が受信したクライアント装置５０の操作情報を取得する処理部である。例えば、操情報取得部１２は、マウスの左右のクリックを始め、ダブルクリックやドラッグ、マウスの移動操作を介して得られたマウスカーソルの移動量などを操作情報として取得する。他の一例としては、操作情報取得部１２は、マウスホイールの回転量、キーボードのうち押下されたキーの種別なども操作情報として取得する。具体的な例を挙げると、操作情報取得部１２は、クライアント装置５０から取得したマウスのダウンクリックからアップクリックまでに要した時間や、マウスのダウンクリックからアップクリックまでの距離等を取得してもよい。
【００５１】
ＯＳ実行部１３は、サーバ内のＯＳを実行する処理部である。例えば、ＯＳ実行部１３は、操作情報取得部１２により取得された操作情報からアプリケーションの起動指示やアプリケーションに対するコマンドを検出する。一例としては、ＯＳ実行部１３は、アプリケーションのアイコン上でダブルクリックを検出した場合に、そのアイコンに対応するアプリケーションの起動を表示画面生成部１４へ指示する。他の一例としては、ＯＳ実行部１３は、起動中のアプリケーションの操作画面、いわゆるウィンドウ上でコマンドの実行を要求する操作を検出した場合に、そのコマンドの実行を表示画面生成部１４へ指示する。
【００５２】
表示画面生成部１４は、ＯＳ実行部１３による指示に基づき、アプリケーションの実行を制御したり、画面生成を実行したりする処理部である。一例としては、表示画面生成部１４は、ＯＳ実行部１３によりアプリの起動が指示された場合や起動中のアプリにコマンドの実行が指示された場合にアプリを動作させる。そして、表示画面生成部１４は、アプリを実行することにより得られた処理結果の表示用画像（リモート画面）を生成して、フレームバッファ１６に書き込む。
【００５３】
なお、表示画面生成部１４が実行するアプリケーションは、プリインストールされたものであってもよく、サーバ装置１０の出荷後にインストールされたものであってもかまわない。また、ＪＡＶＡ（登録商標）などのネットワーク環境から動的にデータを読み込んだ上で動作するアプリケーションであってもよい。また、表示画面生成部１４は、フレームバッファ１６に表示用画像を書き込む、言い換えると、フレームバッファ１６に表示用画像を描画するためのドライバ等を有していてもよい。
【００５４】
サーバ側リモート画面制御部１５は、サーバ側リモート画面制御用アプリケーションを通じて、リモート画面制御サービスをクライアント装置５０へ提供する処理部である。このサーバ側リモート画面制御部１５は、図６に示すように、フレームバッファ１６、フレームバッファ蓄積部１７、更新差分作成部１８、高頻度画面更新領域検出部１９、更新差分画像変換部２０を有する。さらに、サーバ側リモート画面制御部１５は、擬似Ｉフレーム処理部２１、更新差分動画変換部２２、画面更新通知部２３を有する。
【００５５】
フレームバッファ１６は、表示画面生成部１４により描画された表示用画像を画像データフレームとして記憶する記憶デバイスである。かかるフレームバッファ１６の一態様としては、ＶＲＡＭ（Video Random Access Memory）を始めとするＲＡＭ（Random Access Memory)、ＲＯＭ（Read Only Memory）やフラッシュメモリ（flash memory）などの半導体メモリ素子が挙げられる。なお、フレームバッファ１６は、ハードディスク、光ディスクなどの記憶装置を採用することとしてもかまわない。
【００５６】
フレームバッファ蓄積部１７は、過去のフレームバッファ状態を履歴として蓄積する記憶デバイスであり、フレームバッファ１６と同種別のデバイスを用いることができる。例えば、フレームバッファ蓄積部１７は、サーバ側のフレームバッファ１６に書き込みされた過去の画面データフレームを蓄積する機能を有する。具体的には、フレームバッファ蓄積部１７は、サーバ装置１０中で画面情報の差分検出処理を行う際に、１回全画面を走査して差分検出を行うのを１フレームとカウントし、これを１フレームずつ蓄積していく。
【００５７】
例を挙げると、フレームバッファ蓄積部１７は、ある時点におけるフレームの全情報を定期的に取得して保持し、他の処理部からの要求に応じて保持したデータを出力する。フレームバッファ蓄積部１７は、例えば３３ｍｓに１回など、フレームバッファをチェックするタイミングにおいて、更新差分作成部１８から要求を受けフレームバッファの画面データフレームを取得する。フレームバッファ蓄積部１７は、取得時にはそのタイミングにおけるフレームの全情報をその時のフレーム番号とともに保持する。なお、フレーム番号はフレームバッファをチェックする際に１ずつ増加する値である。
【００５８】
更新差分作成部１８は、フレームバッファ１６を検査し更新された差分部分を検出する処理部である。例えば、更新差分作成部１８は、フレームバッファ蓄積部１７から画面データフレームを受信した場合に、今回受信した画面データフレームと前回のタイミングで受信した画面データフレームとを比較して、差分部分を検出する。そして、更新差分作成部１８は、検出した差分部分を高頻度画面更新領域検出部１９に出力する。
【００５９】
高頻度画面更新領域検出部１９は、更新差分作成部１８から取得した更新差分を利用してフレームバッファ中で更新が激しい領域を検出する処理部である。高頻度画面更新領域検出部１９が更新の激しい領域を検出する手法には様々な手法を用いることができる。一例を挙げると、高頻度画面更新領域検出部１９は、取得した差分部分から更新された矩形を示す更新矩形を生成し、生成した更新矩形が動画化領域である場合には、更新が激しい領域として検出する。
【００６０】
例えば、高頻度画面更新領域検出部１９は、更新矩形の大きさが所定値以上であったり、更新矩形を表す差分画像のフレーム数が所定値以上であったりする場合に、動画化領域と検出する。つまり、高頻度画面更新領域検出部１９は、サーバ装置１０がクライアント装置５０に前回送信した画面データフレームに対して、クライアント装置５０によって激しい操作が実行されたか否かを検出する。そして、高頻度画面更新領域検出部１９は、激しい操作が実行されたと判定した場合に、動画生成依頼を擬似Ｉフレーム処理部２１に通知し、激しい操作が実行されていないと判定した場合に、更新画像送信を更新差分画像変換部２０に通知する。
【００６１】
更新差分画像変換部２０は、高頻度画面更新領域検出部１９から更新画像送信依頼を受信すると、領域の更新頻度から更新差分に一致する領域をフレームバッファ１６から取得して画像へ変換し、変換した画像を画面更新通知部２３に出力する処理部である。つまり、更新差分画像変換部２０は、サーバ装置１０がクライアント装置５０に前回送信した画面データフレームに対して、許容範囲内の画像操作が実行されたとする。この場合、更新差分画像変換部２０は、前回送信された画面データフレームとの差分画像を、フレームバッファ蓄積部１７やフレームバッファ１６に記憶されるデータを用いて生成する。
【００６２】
擬似Ｉフレーム処理部２１は、更新差分を動画へ変換する場合に、Ｉフレームとして利用可能なフレーム情報を検出する処理部である。そして、擬似Ｉフレーム処理部２１は、フレーム情報を利用してフレームバッファ蓄積部１７から擬似Ｉフレームデータとなる画面データを取得して、更新差分動画変換部２２へ出力する。
【００６３】
具体的には、擬似Ｉフレーム処理部２１は、フレームバッファ蓄積部１７から現在送信済みで最新のフレームバッファを取得する。そして、擬似Ｉフレーム処理部２１は、そのフレームデータから動画データへ変換する対象の領域の画面データを取得し、擬似Ｉフレームとして更新差分動画変換部２２に出力する。例えば、擬似Ｉフレーム処理部２１は、高頻度画面更新領域検出部１９から動画データへ変換する必要がある高頻度画面更新領域の情報を受け取るとともに、画面更新通知部２３から現在までに送信済みのフレームの番号を取得する。なお、画面更新通知部２３で送信が行われたデータはクライアント側に届いていると想定する。そして、擬似Ｉフレーム処理部２１は、フレームバッファ蓄積部１７から送信済みのフレーム番号に該当するフレームの情報を取得し、ここから動画データへ変換する領域の画面データを抽出する。擬似Ｉフレーム処理部２１は、この画面データを擬似Ｉフレームとして更新差分動画変換部２２へ出力する。
【００６４】
更新差分動画変換部２２は、擬似Ｉフレームがあらかじめ渡された状態で生成され、このＩフレームをベースとしてフレームバッファ１６から取得したデータを利用して、先頭Ｉフレームを排除した形で動画データを生成する処理部である。例えば、更新差分動画変換部２２は、擬似Ｉフレーム処理部２１から擬似Ｉフレームと高頻度画面更新領域の情報を受信し、擬似ＩフレームのデータをＩフレームとして現在のフレームバッファと比較する。その後、更新差分動画変換部２２は、データの先頭がＰフレームから始まる動画データを作成し、画面更新通知部２３に渡す。
【００６５】
なお、更新差分動画変換部２２では画面の更新差分データの変換のためにＭＰＥＧ技術を利用することができる。ＭＰＥＧ技術の中で以下の２種類の性質の異なるフレームのみを利用して動画データを生成する。はじめに、Ｉフレームと呼ばれるデータを動画データの先頭に作成する。これは、他のフレーム（Ｐフレーム）の土台となるフレームで、このフレーム単独で１枚の画像として表示可能な独立したデータになっている。次に、Ｐフレームと呼ばれるデータを作成する。これは、Ｉフレームに対する差分データのみを含むフレームで、Ｉフレームに対してこのフレームを適用することで画面全体を生成することが可能である。ゆえに、Ｐフレーム単独では画像を生成することはできない。また、ＰフレームはＩフレームの後に連続して作成することが可能である。
【００６６】
ここで、更新差分動画変換部２２が実行するＭＰＥＧ符号化について説明する。図７は、更新差分動画変換部の内部処理の例を示す図である。図７に示すように、ＭＰＥＧ符号化器である更新差分動画変換部２２では、一般的な符号化器と同様、動き予測、動き補償、テクスチャ符号化、多重化などの処理を実行して、動画データを生成する。ここで、更新差分動画変換部２２が実行する処理で、一般的な復号化器と異なる点は、符号化器初期化時に処理領域のフレームバッファをＩフレームとして入力する点である。なお、一般的な符号化器と同様の処理については、詳細な説明は省略する。
【００６７】
具体的には、まず、更新差分動画変換部２２は、ＭＰＥＧデータを作成する際のＩフレームの替わりとして、擬似Ｉフレーム処理部２１から過去のフレームバッファ中の高頻度画面更新領域の位置の画面データを取得する。ここでは、過去の画面データを取得するのは、クライアント側に既に通知されているフレームバッファを使うためである。次に、更新差分動画変換部２２は、取得した画面データを擬似Ｉフレームとして、「前画面までの再構成フレーム」が保持されているバッファに書き込む。この処理により、符号化の際に生成するデータの先頭のＩフレームの生成を無くし、Ｐフレームからの動画データ生成を可能とする。
【００６８】
そして、更新差分動画変換部２２は、フレームバッファから最新の画面データを取得し、擬似Ｉフレームを保持した状態で、はじめから差分のデータが生成され、先頭がＰフレームからはじまるＭＰＥＧ形式で画面の更新データを生成する。更新差分動画変換部２２は、生成した更新データを画面更新通知部２３に出力し、通信部１１を経由してクライアント装置５０に通知される。
【００６９】
一例を挙げると、更新差分動画変換部２２は、入力された画像と擬似Ｉフレームとを用いて動き予測や動き補償を実行した後に、テクスチャ符号化によってテクスチャ情報を生成する。一方で、更新差分動画変換部２２は、動き補償の結果とテクスチャ情報とを用いて、新たなフレームを生成してバッファに書込む。また、更新差分動画変換部２２は、動き予測から得られた動きベクトル情報と、テクスチャ符号化によって得られたテクスチャ情報とを多重化してバッファに書込み、このバッファからデータを読み出して、ビットストリームとしてクライアント装置５０に送信する。
【００７０】
図６に戻り、画面更新通知部２３は、更新差分画像変換部２０によって生成された画像をクライアント装置５０に送信する。また、画面更新通知部２３は、更新差分動画変換部２２によって生成された動画、すなわち、Ｐフレームのみから形成される動画をクライアント装置５０に送信する。また、画面更新通知部２３は、現在までに送信済みの画像（フレーム）と、当該フレームに割り与えられた番号とを対応付けて保持する。
【００７１】
なお、上述した各処理部は、各種の集積回路や電子回路を採用でき、一部を別の集積回路や電子回路とすることもできる。例えば、集積回路としては、ＡＳＩＣ（Application Specific Integrated Circuit）やＦＰＧＡ（Field Programmable Gate Array）が挙げられる。また、電子回路としては、ＣＰＵ（Central Processing Unit）やＭＰＵ（Micro Processing Unit）などが挙げられる。
【００７２】
（クライアント装置の構成）
図６に示すように、クライアント装置５０は、通信部５１、表示部５２、画面表示部５３、操作情報取得部５４、クライアント側リモート画面制御部５５を有する。なお、図６の例では、図６に示した機能部以外にも既知のコンピュータが有する各種の機能部、例えば各種の入力デバイスや音声出力部などの機能を有するものとする。
【００７３】
通信部５１は、サーバ装置１０との間でデータの送受信を行う通信インタフェースである。例えば、通信部５１は、後述する操作情報取得部５４により取得された操作情報をサーバ装置１０に送信する。また、通信部５１は、サーバ装置１０から画像や動画を受信して画面更新情報取得部５６等に出力する。
【００７４】
表示部５２は、各種の情報、例えばサーバ装置１０から送信されたデスクトップ画面などを表示する表示デバイスであり、一例としては、モニタ、ディスプレイやタッチパネルなどを適用できる。また、表示部５２は、マウスなどの入力デバイスと協働して、ポインティングデバイスを提供する。
【００７５】
画面表示部５３は、フレームバッファ６０に書き込まれた画像、言い換えると、フレームバッファ６０に描画された画像や動画を読み出し、リモート画面として表示部５２に表示させる。この結果、サーバ装置１０から送信された画像や動画がクライアント装置５０に表示され、リモート画面制御サービスの提供が行われることになる。
【００７６】
操作情報取得部５４は、マウスなどの操作情報を取得してサーバ装置１０へ通知する処理部である。一例としては、操作情報取得部５４は、マウスの左右のクリックを始め、ダブルクリックやドラッグ、マウスの移動操作を介して得られたマウスカーソルの移動量などを操作情報として通知する。他の一例としては、操作情報取得部５４は、マウスホイールの回転量、キーボードのうち押下されたキーの種別なども操作情報として通知する。
【００７７】
クライアント側リモート画面制御部５５は、クライアント側リモート画面制御用アプリを通じて、サーバ装置１０によるリモート画面制御サービスの提供を受ける処理部である。このクライアント側リモート画面制御部５５は、図６に示すように、画面更新情報取得部５６、画像データ処理部５７、擬似Ｉフレーム処理部５８、動画データ処理部５９、フレームバッファ６０を有する。
【００７８】
画面更新情報取得部５６は、サーバ装置１０から送信された画像データを通信部５１から取得する処理部である。そして、画面更新情報取得部５６は、取得した画像データが静止画などの画像である場合には、当該画像データを画像データ処理部５７に出力する。また、画面更新情報取得部５６は、取得した画像データがＰフレームなどの動画である場合には、当該画像データを擬似Ｉフレーム処理部５８に出力する。なお、画面更新情報取得部５６は、画像データのフォーマットや符号化状態などから、画像データの種類を判別することができる。
【００７９】
画像データ処理部５７は、画面更新情報取得部５６から取得した画像データをフレームバッファ６０に書き込む処理部である。例えば、画像データ処理部５７は、サーバ装置１０から送信された画像データ、すなわち、クライアントの操作によって更新された画像をフレームバッファ６０に描画する。
【００８０】
擬似Ｉフレーム処理部５８は、画面更新情報取得部５６から取得した、先頭のＩフレームが取り除かれた動画データから、処理すべきフレーム内の領域位置情報を取得する処理部である。そして、擬似Ｉフレーム処理部５８は、取得した領域位置情報に基づいてフレームバッファ６０から画面データを取得し、擬似Ｉフレームとして動画データ処理部５９に出力する。
【００８１】
例えば、擬似Ｉフレーム処理部５８は、Ｐフレームから始まる画面の動画更新データを受信し、フレームバッファ６０から更新データと同領域の画面データを擬似Ｉフレームとして切り出して動画データ処理部５９に出力する。具体的には、擬似Ｉフレーム処理部５８は、動画形式の更新データを受信し、更新データから描画位置の情報として座標位置等を取得する。続いて、擬似Ｉフレーム処理部５８は、この位置情報を利用して、フレームバッファ６０から該当する領域の画面データを取得し、擬似Ｉフレームとして動画データ処理部５９へ通知する。
【００８２】
つまり、擬似Ｉフレーム処理部５８は、取得した動画データの先頭がＰフレームである場合、サーバ装置１０から動画データを受信する直前に受信していた画像データを特定する。そして、擬似Ｉフレーム処理部５８は、取得した動画データと、特定した画像データと、擬似Ｉフレームとを動画データ処理部５９に出力する。
【００８３】
動画データ処理部５９は、擬似Ｉフレーム処理部５８から取得した擬似Ｉフレームと、サーバ装置１０から受信したＩフレームが取り除かれたデータとを利用して、動画データを再生する。なお、動画データ処理部５９は、動画生成にＭＰＥＧ技術を利用することができる。例えば、ＭＰＥＧ復号器である動画データ処理部５９は、擬似Ｉフレーム処理部５８から擬似Ｉフレームを受信するとともに、Ｐフレームから始まる動画データも受信し、これらのデータから動画データをフレームバッファ６０へ描画する。
【００８４】
図８は、動画データ処理部の内部処理の例を示す図である。図８に示すように、動画データ処理部５９は、一般的なＭＰＥＧ復号器と同様、バッファを有し、可変長復号処理、逆量子化、逆直交変換、動き補償等を実行して復号映像を生成する。ここで、動画データ処理部５９が実行する処理で、一般的な復号器と異なる点は、復号器初期化時に処理領域のフレームをＩフレームとしてバッファに入力する点である。なお、一般的な復号器と同様の処理については、詳細な説明は省略する。
【００８５】
具体的には、まず、動画データ処理部５９は、受信した擬似Ｉフレームを「バッファ」に書き込む。この処理により、復号の際に生成する画面描画データを現在のフレームバッファ６０に表示中の画面データに変更が加えられた後のデータから生成可能とする。そして、動画データ処理部５９は、Ｐフレームから始まる動画データとこの擬似Ｉフレームとを用いて、Ｐフレームの差分が反映されたフレームから画面の更新データを生成する。その後、動画データ処理部５９は、生成されたデータをフレームバッファ６０に書き込む。
【００８６】
図６に戻り、フレームバッファ６０は、画像データ処理部５７により描画された画像や、動画データ処理部５９により生成された動画を保持する。例えば、フレームバッファ６０は、動画データ処理部５９などが実行する描画処理の結果のデータが書き込まれるとともに、擬似Ｉフレーム処理部５８が取得する擬似Ｉフレームのデータの元となる画像を保持する。
【００８７】
［処理の流れ］
次に、実施例２に係るシステムで実行される処理の流れを説明する。ここでは、サーバ装置が実行する処理の流れ、クライアント装置が実行する処理の流れを説明する。
【００８８】
（サーバが実行する全体的な処理の流れ）
図９は、実施例２に係るサーバ装置が実行する処理の全体的な流れを示すフローチャートである。図９に示すように、サーバ装置１０の操作情報取得部１２は、クライアント装置５０で実行されたユーザの操作情報を取得し（Ｓ２０１）、表示画面生成部１４は、ユーザの操作情報に対応した画面を生成してフレームバッファ１６に反映する（Ｓ２０２）。
【００８９】
そして、フレームバッファ蓄積部１７は、表示画面生成部１４によってフレームが反映された結果、フレームバッファ１６に更新が生じたと検出すると（Ｓ２０３肯定）、フレームバッファ蓄積処理を実行する（Ｓ２０４）。なお、フレームバッファ蓄積部１７によってフレームバッファ１６に更新が生じていないと検出された場合には（Ｓ２０３否定）、サーバ装置１０は、Ｓ２０１に戻って以降の処理を繰り返す。
【００９０】
その後、更新差分作成部１８は、フレームバッファ蓄積処理によって蓄積された全フレームバッファの情報から、フレームバッファ１６の更新矩形を作成する（Ｓ２０５）。続いて、高頻度画面更新領域検出部１９は、更新差分作成部１８が生成した更新矩形から、高頻度画面更新領域を検出する（Ｓ２０６）。そして、高頻度画面更新領域検出部１９は、検出した高頻度画面更新領域が動画化領域、すなわち、更新の激しいか否かを判定する（Ｓ２０７）。
【００９１】
高頻度画面更新領域が動画化領域でない場合（Ｓ２０７否定）、更新差分画像変換部２０は、更新差分に一致する領域をフレームバッファ１６から取得して画像へ変換し、変換した画像を画面更新通知部２３に出力する（Ｓ２０８）。そして、画像更新通知部２３は、通信部１１を介して、更新差分画像変換部２０から取得した差分画像をクライアント装置５０に送信する（Ｓ２０９）。その後、クライアント装置で画像描画処理が実行される（Ｓ２１０）。
【００９２】
一方、高頻度画面更新領域が動画化領域である場合（Ｓ２０７肯定）、擬似Ｉフレーム処理部２１が擬似Ｉフレーム作成処理を実行し（Ｓ２１１）、続いて、更新差分動画変換部２２が更新差分動画作成処理を実行する（Ｓ２１２）。
【００９３】
その後、画面更新通知部２３は、通信部１１を介して、ＩフレームがなくＰフレームだけの動画データをクライアント装置５０に送信する（Ｓ２１３）。その後、クライアント装置で動画再生処理が実行される（Ｓ２１４）。
【００９４】
（フレームバッファ蓄積処理）
図１０は、実施例２に係るサーバ装置が実行するフレームバッファ蓄積処理の流れを示すフローチャートである。なお、この処理は、図９のＳ２０４で実行される。
【００９５】
図１０に示すように、フレームバッファ蓄積部１７は、更新差分作成部１８から取得要求を受信すると（Ｓ３０１肯定）、フレームバッファ１６中の全データを取得し（Ｓ３０２）、一意なフレーム番号を付与して保持する（Ｓ３０３）。
【００９６】
一方、フレームバッファ蓄積部１７は、更新差分作成部１８から取得要求を受信せずに（Ｓ３０１否定）、擬似Ｉフレーム処理部２１から取得要求を受信した場合（Ｓ３０４肯定）、Ｓ３０５を実行する。すなわち、フレームバッファ蓄積部１７は、取得要求に含まれるフレーム番号に一致するデータを検索し、検索されたデータを擬似Ｉフレーム処理部２１に出力する（Ｓ３０５）。なお、フレームバッファ蓄積部１７は、更新差分作成部１８から取得要求を受信せずに（Ｓ３０１否定）、擬似Ｉフレーム処理部２１からも取得要求を受信しない場合（Ｓ３０４否定）、Ｓ３０１に戻って以降の処理を実行する。
【００９７】
（擬似Ｉフレーム作成処理）
図１１は、実施例２に係るサーバ装置が実行する擬似Ｉフレーム作成処理の流れを示すフローチャートである。なお、この処理は、図９のＳ２１１で実行される。この処理は、高頻度画面が検出されるたびに実行される。
【００９８】
図１１に示すように、擬似Ｉフレーム処理部２１は、更新差分画像変換部２０から高頻度画面が存在することを受信した場合（Ｓ４０１肯定）、送信済みの最新のフレーム番号を画面更新通知部２３から取得する（Ｓ４０２）。
【００９９】
続いて、擬似Ｉフレーム処理部２１は、取得した最新のフレーム番号に対応するフレームデータをフレームバッファ蓄積部１７から取得する（Ｓ４０３）。そして、擬似Ｉフレーム処理部２１は、高頻度画面更新領域を更新差分画像変換部２０から取得するとともに、この領域に一致する領域の画面データをフレームバッファ蓄積部１７から取得する（Ｓ４０４）。その後、擬似Ｉフレーム処理部２１は、取得した画像データを擬似Ｉフレームとして、更新差分動画変換部２２へ出力する（Ｓ４０５）。
【０１００】
（更新差分動画作成処理）
図１２は、実施例２に係るサーバ装置が実行する更新差分動画作成処理の流れを示すフローチャートである。なお、この処理は、図９のＳ２１２で実行される。この処理は、擬似フレームが受信されるたびに実行される。
【０１０１】
図１２に示すように、更新差分動画変換部２２は、擬似Ｉフレーム処理部２１から擬似Ｉフレームを受信すると（Ｓ５０１肯定）、擬似Ｉフレームを「前画面までの再構成フレーム」を保持するバッファに格納する（Ｓ５０２）。
【０１０２】
続いて、更新差分動画変換部２２は、高頻度画面更新領域すなわち激しい操作が実行された領域の最新のフレームをフレームバッファ１６から取得し（Ｓ５０３）、Ｐフレームから始まる動画データを生成する（Ｓ５０４）。その後、更新差分動画変換部２２は、生成した動画データを画面更新通知部２３に出力する（Ｓ５０５）。
【０１０３】
（クライアント装置が実行する全体的な処理の流れ）
図１３は、実施例２に係るクライアント装置が実行する処理の全体的な流れを示すフローチャートである。図１３に示すように、クライアント装置５０の操作情報取得部５４は、表示部５２に表示される画面に対してユーザが操作した場合に（Ｓ６０１肯定）、当該操作の内容を示す操作情報を逐次サーバ装置１０に送信する（Ｓ６０２）。
【０１０４】
そして、画面更新情報取得部５６がサーバ装置１０から画像データを受信した場合（Ｓ６０３肯定）、画像データ処理部５７は、受信された画像データをフレームバッファ６０に描画する（Ｓ６０４）。
【０１０５】
一方、画面更新情報取得部５６がサーバ装置１０から画像データではなく（Ｓ６０３否定）、動画データを受信した場合（Ｓ６０５肯定）、擬似Ｉフレーム処理部５８は、受信された動画データの先頭がＰフレームであるか否かを判定する（Ｓ６０６）。
【０１０６】
そして、擬似Ｉフレーム処理部５８は、受信された動画データの先頭がＰフレームである場合（Ｓ６０６肯定）、擬似Ｉフレーム処理を実行する（Ｓ６０７）。また、このＳ６０６において、動画データ処理部５９は、動画データを生成する。その後、動画データ処理部５９は、生成した動画データをフレームバッファ６０に重畳して再生する（Ｓ６０８）。なお、擬似Ｉフレーム処理部５８は、受信された動画データの先頭がＰフレームでなくＩフレームである場合（Ｓ６０６否定）、Ｓ６０７を実行することなく、動画データ処理部５９は、受信した動画データをフレームバッファ６０に重畳して再生する（Ｓ６０８）。
【０１０７】
（擬似Ｉフレーム処理）
図１４は、実施例２に係るクライアント装置が実行する擬似Ｉフレーム処理の流れを示すフローチャートである。なお、この処理は、図１３のＳ６０５からＳ６０８で実行される。この処理は、動画データが受信されるたびに実行される。
【０１０８】
図１４に示すように、擬似Ｉフレーム処理部５８は、画面更新情報取得部５６によって動画データが受信され（Ｓ７０１肯定）、データの先頭がＰフレームである場合（Ｓ７０２肯定）、動画データから描画位置の情報を取得する（Ｓ７０３）。
【０１０９】
そして、擬似Ｉフレーム処理部５８は、取得した描画位置にある高頻度画面更新領域と一致する領域の画面データを取得する（Ｓ７０４）。その後、擬似Ｉフレーム処理部５８は、取得した画面データを擬似Ｉフレームとして動画データ処理部５９に出力する（Ｓ７０５）。
【０１１０】
一方、画面更新情報取得部５６によって受信された動画データの先頭がＰフレームでない場合（Ｓ７０２否定）、受信された動画データを動画データ処理部５９に出力する（Ｓ７０６）。
【０１１１】
（動画データ処理）
図１５は、実施例２に係るクライアント装置が実行する動画データ処理の流れを示すフローチャートである。なお、この処理は、図１３のＳ６０７で実行される。この処理は、擬似Ｉフレームが受信されるたびに実行される。
【０１１２】
図１５に示すように、動画データ処理部５９は、擬似Ｉフレーム処理部５８から擬似Ｉフレームを受信すると（Ｓ８０１肯定）、受信した擬似フレームを動画データ処理部５９内部のバッファ等に書き込む（Ｓ８０２）。
【０１１３】
続いて、動画データ処理部５９は、擬似Ｉフレームと、サーバ装置１０から受信したＩフレームが取り除かれた動画データを利用して動画データを生成する（Ｓ８０３）。そして、動画データ処理部５９は、受信した動画データをフレームバッファ６０に重畳して再生する（Ｓ８０４）。
【０１１４】
［実施例２による効果］
実施例２によれば、大量のキャッシュデータなしに、画面データの処理方法切替時のデータ重複を排除し、更新開始時の送信データ量を削減することができる。また、マウスの操作情報などを操作トリガとして利用することで、大量の更新が発生する可能性が高い場合のみ開示する処理を適用することができる。また、実施例２の処理によって更新された画面領域の場所を記憶することで、通信量が少ないときに更新を行うことができ、この場合であっても高画質を維持できる。
【実施例３】
【０１１５】
ところで、開示するシステムは、クライアント装置に画像で画面更新データを送信した際に利用した画像圧縮形式を保持し、擬似Ｉフレームを取得する際に画像圧縮形式情報を取得する。そして、このシステムは、取得した画像圧縮形式情報をフレームバッファ蓄積部から取得した画面データに適用することでより正確な擬似Ｉフレームを生成することができる。
【０１１６】
そこで、実施例３では、画像圧縮形式情報を保持しておき、正確な擬似Ｉフレームを生成する例について説明する。ここでは、装置の構成、処理の流れ、効果を説明する。なお、クライアント装置の構成は、実施例２と同様であるので、詳細な説明は省略する。
【０１１７】
［装置の構成］
図１６は、実施例３に係るサーバ装置の構成を示すブロック図である。図１６に示すように、このサーバ装置１０は、通信部１１、操作情報取得部１２、ＯＳ実行部１３、表示画面生成部１４、サーバ側リモート画面制御部１５を有する。なお、通信部１１、操作情報取得部１２、ＯＳ実行部１３、画面生成部１４は、図６と同様なので、詳細な説明は省略する。
【０１１８】
サーバ側リモート画面制御部１５は、フレームバッファ１６、フレームバッファ蓄積部１７、更新差分作成部１８、高頻度画面更新領域検出部１９、更新差分画像変換部２０を有する。さらに、サーバ側リモート画面制御部１５は、擬似Ｉフレーム処理部２１、更新差分動画変換部２２、画面更新通知部２３を有する。さらに、サーバ側リモート画面制御部１５は、フレームバッファ変換情報蓄積部３０を有する。なお、フレームバッファ変換情報蓄積部３０以外の処理部は、図６と同様の処理を実行するので、ここでは詳細な説明は省略する。
【０１１９】
フレームバッファ変換情報蓄積部３０は、クライアント装置に送信されたデータに利用される画像圧縮形式を保持する。例えば、フレームバッファ変換情報蓄積部３０は、更新差分動画変換部２２において利用された変換方式と更新した領域情報とを取得して保持する。そして、擬似Ｉフレーム処理部２１が高頻度画面更新領域の情報を受け取った際に、領域情報を検索キーとして、フレームバッファ変換情報蓄積部３０を検索する。その後、擬似Ｉフレーム処理部２１は、一致するものがあればフレームバッファ１６から取得した該当領域に対してその圧縮方式を適用した上で、再度展開して擬似Ｉフレームとして利用する。
【０１２０】
［処理の流れ］
次に、図１７と図１８を用いて、実施例３に係るサーバ装置が実行する処理について説明する。ここでは、実施例２とは異なる処理として、更新差分画像変換処理と擬似Ｉフレーム作成処理について説明する。
【０１２１】
（更新差分画像変換処理）
図１７は、実施例３に係るサーバ装置が実行する更新差分画像変換処理の流れを示すフローチャートである。図１７に示すように、更新差分画像変換部２０は、更新された矩形の情報を高頻度画面更新領域検出部１９から受信すると（Ｓ９０１肯定）、Ｓ９０２を実行する。すなわち、更新差分画像変換部２０は、更新矩形情報から領域情報を読み込んで、フレームバッファ１６から該当領域の画面データを取得する（Ｓ９０２）。
【０１２２】
そして、更新差分画像変換部２０は、クライアント装置５０との間で予め取り決められた非可逆圧縮方式または前回画面データを生成した際に利用した非可逆圧縮方式で画面データを圧縮する（Ｓ９０３）。その後、更新差分画像変換部２０は、画面データを生成した領域の情報と、圧縮方式とを対応付けてフレームバッファ変換情報蓄積部３０に通知し（Ｓ９０４）、生成した画面データを画面更新通知部２３に出力する（Ｓ９０５）。
【０１２３】
（擬似Ｉフレーム作成処理）
図１８は、実施例３に係るサーバ装置が実行する擬似Ｉフレーム作成処理の流れを示すフローチャートである。図１８に示すように、擬似Ｉフレーム処理部２１は、更新差分画像変換部２０から高頻度画面が存在することを受信した場合（Ｓ１００１肯定）、送信済みの最新のフレーム番号を画面更新通知部２３から取得する（Ｓ１００２）。
【０１２４】
続いて、擬似Ｉフレーム処理部２１は、取得した最新のフレーム番号に対応するフレームデータをフレームバッファ蓄積部１７から取得する（Ｓ１００３）。そして、擬似Ｉフレーム処理部２１は、高頻度画面更新領域を更新差分画像変換部２０から取得するとともに、この領域に一致する領域の画面データをフレームバッファ蓄積部１７から取得する（Ｓ１００４）。その後、擬似Ｉフレーム処理部２１は、フレームバッファ変換情報蓄積部３０から該当領域の圧縮方式を取得する（Ｓ１００５）。
【０１２５】
そして、擬似Ｉフレーム処理部２１は、取得した圧縮方式が可逆圧縮である場合（Ｓ１００６肯定）、Ｓ１００４で取得した画像データを擬似Ｉフレームとして、更新差分動画変換部２２へ出力する（Ｓ１００７）。
【０１２６】
一方、擬似Ｉフレーム処理部２１は、取得した圧縮方式が可逆圧縮でない場合（Ｓ１００６否定）、取得した圧縮方式で、Ｓ１００４で取得した画像データを圧縮後、再展開したデータを擬似Ｉフレームとして、更新差分動画変換部２２へ出力する（Ｓ１００８）。
【０１２７】
［実施例３による効果］
クライアント装置とサーバ装置双方のフレームバッファは、同一のものが存在することを想定している。このように画面データ転送時に同一のデータを転送しようとするとする場合、可逆圧縮方式と呼ばれる比較的データ量が大きい方法で画像を圧縮する必要がある。そのため、データの欠落を許容することでデータ量を小さくすることが可能な非可逆圧縮方式で画面データを圧縮して転送することも可能である。しかし、クライアントに対して非可逆圧縮方式で画面データを送信すると、サーバに存在するフレームバッファとクライアントのそれの整合性がとれない事象が発生する恐れもある。
【０１２８】
そこで、実施例３のように、サーバ装置１０に「フレームバッファ変換情報蓄積部３０」を加えて、領域毎の圧縮方式や圧縮品質を保持しておくことで、クライアント装置とサーバ装置間で同一の擬似Ｉフレームを生成可能となる。
【実施例４】
【０１２９】
ところで、開示するシステムは、既存のＭＰＥＧ符号化器や復号器に手を加えずにＩフレームを排除し、データ転送量を削減することもできる。そこで、実施例４では、既存のＭＰＥＧ符号化器や復号器に手を加えずにＩフレームを排除例について説明する。ここでは、装置の構成、処理の流れ、効果を説明する。なお、クライアント装置の構成は、実施例２と同様であるので、詳細な説明は省略する。
【０１３０】
［装置の構成］
図１９は、実施例４に係るサーバ装置の構成を示すブロック図である。図１９に示すように、このサーバ装置１０は、通信部１１、操作情報取得部１２、ＯＳ実行部１３、表示画面生成部１４、サーバ側リモート画面制御部１５を有する。なお、通信部１１、操作情報取得部１２、ＯＳ実行部１３、画面生成部１４は、図６と同様なので、詳細な説明は省略する。
【０１３１】
サーバ側リモート画面制御部１５は、フレームバッファ１６、フレームバッファ蓄積部１７、更新差分作成部１８、高頻度画面更新領域検出部１９、更新差分画像変換部２０を有する。さらに、サーバ側リモート画面制御部１５は、擬似Ｉフレーム処理部２１、更新差分動画変換部２２、画面更新通知部２３を有する。さらに、サーバ側リモート画面制御部１５は、Ｉフレームデータ排除部３１を有する。なお、Ｉフレームデータ排除部３１以外の処理部は、図６と同様の処理を実行するので、ここでは詳細な説明は省略する。
【０１３２】
Ｉフレームデータ排除部３１は、擬似Ｉフレーム処理部２１によって生成されたＭＰＥＧデータ中から先頭のＩフレームのデータを排除する処理部である。例えば、Ｉフレームデータ排除部３１は、擬似Ｉフレーム処理部２１からＩフレームを排除するよう通知を受信した場合、擬似Ｉフレーム処理部２１から受信したＭＰＥＧデータの先頭からＩフレームを排除して、画面更新通知部２３に出力する。
【０１３３】
［処理の流れ］
図２０は、実施例４に係るサーバ装置が実行する擬似Ｉフレーム作成処理の流れを示すフローチャートである。図２０に示すように、擬似Ｉフレーム処理部２１は、高頻度画面更新領域検出部１９から高頻度画面更新領域を受信する（Ｓ１１０１肯定）。すると、擬似Ｉフレーム処理部２１は、画面更新通知部２３から送信済みフレームのうち最新値を取得し（Ｓ１１０２）、フレームバッファ蓄積部１７に蓄積されている最新のフレームバッファの番号を取得する（Ｓ１１０３）。
【０１３４】
続いて、擬似Ｉフレーム処理部２１は、画面更新通知部２３から取得したフレーム番号と、フレームバッファ蓄積部１７から取得したフレーム番号とが一致するか否かを判定する（Ｓ１１０４）。なお、フレームバッファ蓄積部１７へ先に新しい画面データが書き込まれるため、処理のタイミングによっては動画作成時のＩフレームに相当するデータがクライアントへ届いていない場合、つまり画面更新通知部２３のフレーム番号が古い場合が存在する。そのような場合には、Ｐフレームから始まるデータをクライアントへ送信しても疑似Ｉフレームが生成できない可能性がある。このような場合のために一致判定を行う。
【０１３５】
そして、擬似Ｉフレーム処理部２１は、両方のフレーム番号が一致する場合（Ｓ１１０４肯定）、Ｉフレームデータ排除部３１に次のＭＰＥＧデータ、すなわちこれから通知されるＭＰＥＧデータの先頭Ｉフレームを排除する通知を出力する（Ｓ１１０５）。なお、擬似Ｉフレーム処理部２１は、両方のフレーム番号が一致しない場合（Ｓ１１０４否定）、Ｓ１１０５を実行することなくＳ１１０６を実行する。
【０１３６】
その後、擬似Ｉフレーム処理部２１は、高頻度画面更新領域検出部１９から取得した高頻度更新領域を更新差分動画変換部２２に出力する（Ｓ１１０６）。この結果、Ｉフレームデータ排除部３１は、更新差分動画変換部２２から取得したＭＰＥＧデータの先頭のＩフレームを削除して画面更新通知部２３に出力する。
【０１３７】
［実施例４による効果］
このように、サーバ装置に「Iフレームデータ排除部３１」をさらに加え、生成されたＭＰＥＧデータ中から先頭のＩフレームのデータを排除した上でクライアント装置に転送する。クライアント装置では、自身のフレームバッファから取得した擬似Ｉフレームを、受信したＭＰＥＧデータの先頭に付与することでデータ転送量を削減可能である。
【実施例５】
【０１３８】
さて、これまで本発明の実施例について説明したが、本発明は上述した実施例以外にも、種々の異なる形態にて実施されてよいものである。そこで、以下に異なる実施例を説明する。
【０１３９】
（送信手法の切替）
例えば、実施例１から実施例４では、画像送信から動画送信に切り替える例を説明しているがこれに限定されるものではない。例えば、開示するシステムは、動画データによる更新から別の動画データ形式への切り替え時や、動画データによる更新から画像データ形式への切り替え時にも適用可能である。
【０１４０】
また、切り替えるトリガ、言い換えると激しい操作の例としては、サーバ装置は、クライアント装置からマウスのダウンクリックを検出してから、アップクリックを検出するまでの時間が所定時間となった場合に、激しい操作が行われたと検出する。また、サーバ装置は、ダウンクリックからアップクリックまでの距離が所定値以上となった場合に、激しい操作が行われたと検出する。
【０１４１】
（送信手法の戻し）
例えば、実施例１から実施例４で説明した手法で、画像送信から動画送信に切り替えた後に、元の画像送信に切り戻すタイミングは、任意に設定できる。例えば、動画化される領域が一定になったタイミング、もしくは更新が少ない状態で一定時間経った場合に、元の送信手法に戻してもよい。
【０１４２】
（動画圧縮）
例えば、実施例１から実施例４では、ＭＰＥＧ技術で利用されるＩフレーム、Ｐフレームを用いた例で説明しているが、開示するシステムの適用範囲はＭＰＥＧ技術だけではなく、他の動画圧縮形式にも適用可能ある。つまり、実施例で例示したＩフレーム、Ｐフレームは、動画圧縮方式一般で利用される基準画像、差分画像に相当するものである。
【０１４３】
（システム）
また、本実施例において説明した各処理のうち、自動的におこなわれるものとして説明した処理の全部または一部を手動的におこなうこともできる。あるいは、手動的におこなわれるものとして説明した処理の全部または一部を公知の方法で自動的におこなうこともできる。この他、上記文書中や図面中で示した処理手順、制御手順、具体的名称、例えば図３等に示した各種のデータやパラメータを含む情報については、特記する場合を除いて任意に変更することができる。
【０１４４】
また、図示した各装置の各構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、任意の処理部を統合するなど各装置の分散・統合の具体的形態は図示のものに限られない。つまり、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。さらに、各装置にて行なわれる各処理機能は、その全部または任意の一部が、ＣＰＵおよび当該ＣＰＵにて解析実行されるプログラムにて実現され、あるいは、ワイヤードロジックによるハードウェアとして実現され得る。
【０１４５】
また、各実施例で説明した操作情報取得部は、加速度センサや光センサ、地磁気センサ、温度センサなどのユーザの周辺状況および端末へのユーザの動作をセンシング可能なセンサでも良い。また、操作情報取得部は、タッチパネルやキーボードやマイクロフォンなどのユーザが直接入力を行う機器でも構わない。また、本実施例ではクライアント装置としてサーバ装置上のデスクトップ環境と同サイズの出力が可能なクライアント装置を利用しているが、これに限定されるものではない。例えば、画面の表示サイズを縮小することでこれ以外のＰＤＡやノートＰＣ、携帯ゲーム機、携帯音楽プレイヤーなどの画面サイズの小さな端末上にも適用可能である。また、サーバ装置側のＯＳ実行部は特定のアーキテクチャに依存せず、どのようなＯＳでも構わない。
【０１４６】
（プログラム）
ところで、上記の実施例で説明した各種の処理は、あらかじめ用意されたプログラムをパーソナルコンピュータやワークステーションなどのコンピュータシステムで実行することによって実現することができる。そこで、以下では、上記の実施例と同様の機能を有するプログラムを実行するコンピュータシステムの一例を説明する。
【０１４７】
図２１は、画像送信プログラムを実行するコンピュータのハードウェア構成例を示す図である。図２１に示すように、コンピュータシステム１００は、バス１０１に、ＣＰＵ１０２、入力装置１０３、出力装置１０４、通信インタフェース１０５、ＨＤＤ（Hard Disk Drive）１０６、ＲＡＭ（Random Access Memory）１０７が接続される。
【０１４８】
入力装置１０３は、マウスやキーボードであり、出力装置１０４は、ディスプレイなどであり、通信インタフェース１０５は、ＮＩＣ（Network Interface Card）などのインタフェースである。ＨＤＤ１０６には、画像送信プログラム１０６ａととともに、図６等に示した各バッファ等に記憶される情報が記憶される。記録媒体の例としてＨＤＤ１０６を例に挙げたが、ＲＯＭ（Read Only Memory）、ＲＡＭ（Random Access Memory）、ＣＤ−ＲＯＭ等の他のコンピュータ読み取り可能な記録媒体に各種プログラムを格納しておき、コンピュータに読み取らせることとしてもよい。なお、記憶媒体を遠隔地に配置し、コンピュータが、その記憶媒体にアクセスすることでプログラムを取得して利用してもよい。また、その際、取得したプログラムをそのコンピュータ自身の記録媒体に格納して用いてもよい。
【０１４９】
ＣＰＵ１０２は、画像送信プログラム１０６ａを読み出してＲＡＭ１０７に展開することで、図６等で説明した各機能を実行する画像送信プロセス１０７ａを動作させる。すなわち、画像送信プロセス１０７ａは、図６、図１６、図１９に記載したサーバ側リモート画面制御部１５が有する各処理部と同様の機能を実行する。このようにコンピュータシステム１００は、プログラムを読み出して実行することでリモート画面送信制御方法を実行する情報処理装置として動作する。
【符号の説明】
【０１５０】
１、１０ サーバ装置
１ａ 通信部
１ｂ 第１の画像メモリ
１ｃ 第２の画像メモリ
１ｄ 第１の画像送信部
１ｅ 第２の画像送信部
５、５０ クライアント装置
５ａ 通信部
５ｂ 画像メモリ
５ｃ 表示部
５ｄ 画像生成部
１１ 通信部
１２ 操作情報取得部
１３ ＯＳ実行部
１４ 表示画面生成部
１５ サーバ側リモート画面制御部
１６ フレームバッファ
１７ フレームバッファ蓄積部
１８ 更新差分作成部
１９ 高頻度画面更新領域検出部
２０ 更新差分画像変換部
２１ 擬似Ｉフレーム処理部
２２ 更新差分動画変換部
２３ 画面更新通知部
５１ 通信部
５２ 表示部
５３ 画面表示部
５４ 操作情報取得部
５５ クライアント側リモート画面制御部
５６ 画面更新情報取得部
５７ 画像データ処理部
５８ 擬似Ｉフレーム処理部
５９ 動画データ処理部
【特許請求の範囲】
【請求項１】
ネットワーク経由で接続された端末装置の表示部にコンピュータの実行結果を表示するための画像を生成して前記端末装置へ送信する情報処理装置であって、
前記画像を保持する第１の画像メモリと、
前記画像を前記端末装置へ送信する第１の画像送信部と、
前記第１の画像送信部で送信した画像を保持する第２の画像メモリと、
前記画像を基準画像と差分画像とを組み合わせて送信する第２の画像送信部と、を有し、
前記第２の画像送信部は、
前記第１の画像送信部から前記第２の画像送信部に送信を切り換える際に、前記第２の画像メモリに保持された画像を前記基準画像に設定し、
前記基準画像を基に、前記第１の画像メモリに保持された画像から前記差分画像を生成し、
前記基準画像を端末装置に送信済みの画像から取得する信号と共に前記差分画像を送信する情報処理装置。
【請求項２】
前記第２の画像送信部は、
前記端末装置の表示部に表示される画像の更新領域が所定値以上となった場合に、前記第１の画像送信部から前記第２の画像送信部に送信を切り換え、前記移動距離が所定値以上となった画像を前記基準画像とすることを特徴とする請求項１に記載の情報処理装置。
【請求項３】
前記第２の画像メモリは、前記第１の画像送信部で送信した画像に加えて、前記画像に利用された圧縮方式をさらに対応付けて保持し、
前記第２の画像送信部は、前記第１の画像送信部から前記第２の画像送信部に送信を切り換える際に、前記第２の画像メモリに保持された画像を、当該画像に対応付けられている圧縮方式を用いて前記基準画像を生成することを特徴とする請求項１または２に記載の情報処理装置。
【請求項４】
ネットワーク経由で接続された端末装置の表示部にコンピュータの実行結果を表示するための画像を生成して前記端末装置へ送信する情報処理装置に
前記画像を第１の画像メモリに保持する第１保持手順と、
前記画像を前記端末装置へ送信する第１の画像送信手順と、
前記端末装置に送信された画像を第２の画像メモリを保持する第２保持手順と、
前記画像を基準画像と差分画像とを組み合わせて送信する第２の画像送信手順と、
前記第２の画像送信手順は、
前記第１の画像送信手順から前記第２の画像送信手順に送信を切り換える際に、前記第２の画像メモリに保持された画像を前記基準画像に設定し、
前記基準画像を基に、前記第１の画像メモリに保持された画像から前記差分画像を生成し、
前記基準画像を端末装置に送信済みの画像から取得する信号と共に前記差分画像を送信する処理を実行することを特徴とする画像送信プログラム。
【請求項５】
ネットワーク経由で接続された端末装置の表示部にコンピュータの実行結果を表示するための画像を生成して前記端末装置へ送信する情報処理装置が実行する制御方法であって、
前記画像を第１の画像メモリに保持する第１保持工程と、
前記画像を前記端末装置へ送信する第１の画像送信工程と、
前記端末装置に送信された画像を第２の画像メモリを保持する第２保持工程と、
前記画像を基準画像と差分画像とを組み合わせて送信する第２の画像送信工程と、
前記第２の画像送信工程は、
前記第１の画像送信工程から前記第２の画像送信工程に送信を切り換える際に、前記第２の画像メモリに保持された画像を前記基準画像に設定し、
前記基準画像を基に、前記第１の画像メモリに保持された画像から前記差分画像を生成し、
前記基準画像を端末装置に送信済みの画像から取得する信号と共に前記差分画像を送信することを含んだことを特徴とする画像送信方法。
【請求項６】
ネットワーク経由で接続された端末装置の表示部にコンピュータの実行結果を表示するための画像を生成して前記端末装置へ送信する情報処理装置と、前記情報処理装置から前記ネットワークを経由して受信した画像を表示する端末装置とを有する画像表示システムに用いる画像表示方法であって、
前記情報処理装置は、
前記画像を第１の画像メモリに保持する第１保持工程と、
前記画像を前記端末装置へ送信する第１の画像送信工程と、
前記端末装置に送信された画像を第２の画像メモリを保持する第２保持工程と、
前記画像を基準画像と差分画像とを組み合わせて送信する第２の画像送信工程であって、前記第１の画像送信工程から前記第２の画像送信工程に送信を切り換える際に、前記第２の画像メモリに保持された画像を前記基準画像に設定し、
前記基準画像を基に、前記第１の画像メモリに保持された画像から前記差分画像を生成し、
前記基準画像を端末装置に送信済みの画像から取得する信号と共に前記差分画像を送信する第２の画像送信工程とを含み、
前記端末装置は、
前記情報処理装置から画像を受信した画像を保持部に保持する保持工程と、
前記保持部に保持される画像を所定の表示部に表示させる第１表示制御部と、
前記情報処理装置から前記差分画像と前記信号とを受信した場合に、前記保持部に保持される画像を基準画像として、当該基準画像と前記差分画像から生成した画像を前記所定の表示部に表示させる第２表示制御部と、
を含んだことを特徴とする画像表示方法。
【請求項１】
ネットワーク経由で接続された端末装置の表示部にコンピュータの実行結果を表示するための画像を生成して前記端末装置へ送信する情報処理装置であって、
前記画像を保持する第１の画像メモリと、
前記画像を前記端末装置へ送信する第１の画像送信部と、
前記第１の画像送信部で送信した画像を保持する第２の画像メモリと、
前記画像を基準画像と差分画像とを組み合わせて送信する第２の画像送信部と、を有し、
前記第２の画像送信部は、
前記第１の画像送信部から前記第２の画像送信部に送信を切り換える際に、前記第２の画像メモリに保持された画像を前記基準画像に設定し、
前記基準画像を基に、前記第１の画像メモリに保持された画像から前記差分画像を生成し、
前記基準画像を端末装置に送信済みの画像から取得する信号と共に前記差分画像を送信する情報処理装置。
【請求項２】
前記第２の画像送信部は、
前記端末装置の表示部に表示される画像の更新領域が所定値以上となった場合に、前記第１の画像送信部から前記第２の画像送信部に送信を切り換え、前記移動距離が所定値以上となった画像を前記基準画像とすることを特徴とする請求項１に記載の情報処理装置。
【請求項３】
前記第２の画像メモリは、前記第１の画像送信部で送信した画像に加えて、前記画像に利用された圧縮方式をさらに対応付けて保持し、
前記第２の画像送信部は、前記第１の画像送信部から前記第２の画像送信部に送信を切り換える際に、前記第２の画像メモリに保持された画像を、当該画像に対応付けられている圧縮方式を用いて前記基準画像を生成することを特徴とする請求項１または２に記載の情報処理装置。
【請求項４】
ネットワーク経由で接続された端末装置の表示部にコンピュータの実行結果を表示するための画像を生成して前記端末装置へ送信する情報処理装置に
前記画像を第１の画像メモリに保持する第１保持手順と、
前記画像を前記端末装置へ送信する第１の画像送信手順と、
前記端末装置に送信された画像を第２の画像メモリを保持する第２保持手順と、
前記画像を基準画像と差分画像とを組み合わせて送信する第２の画像送信手順と、
前記第２の画像送信手順は、
前記第１の画像送信手順から前記第２の画像送信手順に送信を切り換える際に、前記第２の画像メモリに保持された画像を前記基準画像に設定し、
前記基準画像を基に、前記第１の画像メモリに保持された画像から前記差分画像を生成し、
前記基準画像を端末装置に送信済みの画像から取得する信号と共に前記差分画像を送信する処理を実行することを特徴とする画像送信プログラム。
【請求項５】
ネットワーク経由で接続された端末装置の表示部にコンピュータの実行結果を表示するための画像を生成して前記端末装置へ送信する情報処理装置が実行する制御方法であって、
前記画像を第１の画像メモリに保持する第１保持工程と、
前記画像を前記端末装置へ送信する第１の画像送信工程と、
前記端末装置に送信された画像を第２の画像メモリを保持する第２保持工程と、
前記画像を基準画像と差分画像とを組み合わせて送信する第２の画像送信工程と、
前記第２の画像送信工程は、
前記第１の画像送信工程から前記第２の画像送信工程に送信を切り換える際に、前記第２の画像メモリに保持された画像を前記基準画像に設定し、
前記基準画像を基に、前記第１の画像メモリに保持された画像から前記差分画像を生成し、
前記基準画像を端末装置に送信済みの画像から取得する信号と共に前記差分画像を送信することを含んだことを特徴とする画像送信方法。
【請求項６】
ネットワーク経由で接続された端末装置の表示部にコンピュータの実行結果を表示するための画像を生成して前記端末装置へ送信する情報処理装置と、前記情報処理装置から前記ネットワークを経由して受信した画像を表示する端末装置とを有する画像表示システムに用いる画像表示方法であって、
前記情報処理装置は、
前記画像を第１の画像メモリに保持する第１保持工程と、
前記画像を前記端末装置へ送信する第１の画像送信工程と、
前記端末装置に送信された画像を第２の画像メモリを保持する第２保持工程と、
前記画像を基準画像と差分画像とを組み合わせて送信する第２の画像送信工程であって、前記第１の画像送信工程から前記第２の画像送信工程に送信を切り換える際に、前記第２の画像メモリに保持された画像を前記基準画像に設定し、
前記基準画像を基に、前記第１の画像メモリに保持された画像から前記差分画像を生成し、
前記基準画像を端末装置に送信済みの画像から取得する信号と共に前記差分画像を送信する第２の画像送信工程とを含み、
前記端末装置は、
前記情報処理装置から画像を受信した画像を保持部に保持する保持工程と、
前記保持部に保持される画像を所定の表示部に表示させる第１表示制御部と、
前記情報処理装置から前記差分画像と前記信号とを受信した場合に、前記保持部に保持される画像を基準画像として、当該基準画像と前記差分画像から生成した画像を前記所定の表示部に表示させる第２表示制御部と、
を含んだことを特徴とする画像表示方法。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【公開番号】特開２０１２−１９５６２９（Ｐ２０１２−１９５６２９Ａ）
【公開日】平成２４年１０月１１日（２０１２．１０．１１）
【国際特許分類】
【出願番号】特願２０１１−５５９９５（Ｐ２０１１−５５９９５）
【出願日】平成２３年３月１４日（２０１１．３．１４）
【出願人】（０００００５２２３）富士通株式会社 (25,993)
【Ｆターム（参考）】
【公開日】平成２４年１０月１１日（２０１２．１０．１１）
【国際特許分類】
【出願日】平成２３年３月１４日（２０１１．３．１４）
【出願人】（０００００５２２３）富士通株式会社 (25,993)
【Ｆターム（参考）】
[ Back to top ]