(57)【要約】  サーバが画像のフレームデータを複数のクライアントにネットワークを介して配信する方法であって、サーバが備えるプロセッサが、フレームデータとして第１のフレームデータと第２のフレームデータとを生成し、複数のクライアントの全てに対して第１のフレームデータを送信し、第１のフレームデータの送信間において、クライアントとサーバとの間の通信環境が所定条件を満たすクライアントについて第２のフレームデータを送信することを含む。
2016088244.tif 000002
【特許請求の範囲】
【請求項１】
サーバが画像のフレームデータを複数のクライアントにネットワークを介して配信する方法であって、
前記サーバが備えるプロセッサが、
前記フレームデータとして、第１のフレームデータと、第２のフレームデータとを生成し、
前記複数のクライアントの全てに対し、前記第１のフレームデータを送信し、
前記第１のフレームデータの送信間において、クライアントと前記サーバとの間の通信環境が所定条件を満たすクライアントについて前記第２のフレームデータを送信する
ことを含むサーバの画像配信方法。
【請求項２】
前記プロセッサは、各クライアントについて、送信対象のフレームデータが前記第１のフレームデータであれば当該第１のフレームデータの送信を行い、送信対象のフレームデータが前記第２のフレームデータであれば前記所定条件が満たされるか否かによって当該第２のフレームデータの送信又は送信の取り止めを行う送信判定処理を、往復遅延時間の長い順で実行する
請求項１に記載のサーバの画像配信方法。
【請求項３】
前記プロセッサは、各クライアントについて、クライアントと前記サーバとの間に前記第２のフレームデータを送信するための空き帯域が前記ネットワークにあるか否かによって前記所定条件が満たされるか否かを判定する請求項１又は２に記載のサーバの画像配信方法。
【請求項４】
前記プロセッサは、これまでに送信した前記第１のフレームデータの累積データ量をこれまでに送信した前記第１のフレームデータに係る往復遅延時間で除した値を空き帯域の推定値として求め、現在から単位時間遡った期間におけるフレームデータのデータ量に送信対象の第２のフレームデータのデータ量を加算した値が前記推定値を下回るときに当該第２のフレームデータを送信し、そうでなければ当該第２のフレームデータの送信を取り止める
請求項３に記載のサーバの画像配信方法。
【請求項５】
前記プロセッサは、前記第２のフレームデータとして、最後に送信された前記第１のフレームデータとの差分を示すデータを送信する
請求項１から４のいずれか１項に記載のサーバの画像配信方法。
【請求項６】
前記プロセッサは、２回目以降に送信される前記第１のフレームデータとして、初回で送信された前記第１のフレームデータとの差分を示すデータを送信する
請求項１から５のいずれか１項に記載のサーバの画像配信方法。
【請求項７】
前記プロセッサは、各クライアントからの応答に基づいて最後に送信した第１のフレームデータが前記複数のクライアントの全てで受信されたことを検出したときに、次のフレームデータの送信タイミングにおいて第１のフレームデータを送信することを決定する
請求項１から６のいずれか１項に記載のサーバの画像配信方法。
【請求項８】
前記プロセッサは、前記複数のクライアントに係る往復遅延時間に応じて前記複数のクライアントを複数のクラスタにクラスタリングし、
前記複数のクライアントの全てから前記第１のフレームデータの受信を示す応答が受信される前に、或るクラスタに属するクライアントの全てから前記応答が受信されている場合には、前記或るクラスタに属するクライアントの全てを送信対象とする第３のフレームデータの送信を決定する
請求項１から７のいずれか１項に記載のサーバの画像配信方法。
【請求項９】
前記プロセッサは、前記画像に対する操作情報が受信されたときに当該操作情報の送信元のクライアントに対する前記送信判定処理の優先順位を上げる
請求項２から８のいずれか１項に記載のサーバの画像配信方法。
【請求項１０】
画像のフレームデータを複数のクライアントにネットワークを介して配信するサーバとして動作するコンピュータに、
前記フレームデータとして、第１のフレームデータと、第２のフレームデータとを生成するステップと、
前記複数のクライアントの全てに対し、前記第１のフレームデータを送信するステップと、
前記第１のフレームデータの送信間において、クライアントと前記サーバとの間の通信環境が所定条件を満たすクライアントについて前記第２のフレームデータを送信るステップと
を実行させるプログラム。
【請求項１１】
画像のフレームデータを複数のクライアントにネットワークを介して配信するサーバであって、
前記フレームデータとして、第１のフレームデータと、第２のフレームデータとを生成する処理と、前記複数のクライアントの全てに対し、前記第１のフレームデータを送信する処理と、前記第１のフレームデータの送信間において、クライアントと前記サーバとの間の通信環境が所定条件を満たすクライアントについて前記第２のフレームデータを送信る処理と、を実行する制御装置
を含むサーバ。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、サーバの画像配信方法に関する。
【背景技術】
【０００２】
コラボレーションシステムの一つとして、サーバの画面を複数のクライアント（ユーザとも呼ばれる）に転送（配信）することによって、複数のクライアントが画面を共有するシステムがある。サーバは、例えば、画面をキャプチャして得られた静止画データを所定のフレームレート（単位時間当たりのフレーム数）で各クライアントに送信する。各クライアントでは、入力装置を用いて画面の操作情報が入力されると、操作情報はサーバに送信される。サーバは、操作情報に基づき画面を更新し、更新された画面のフレームデータが各クライアントに配信される。これによって、１つの画面に対して、複数のクライアントのオペレータが操作を行うことができる。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２００９-１１００４１号公報
【特許文献２】特開平９−２０４３８０号公報
【特許文献３】特開２００５−２６７３４７号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
しかしながら、各クライアントとサーバとを結ぶネットワーク環境（通信環境）は、クライアント間で一様でないことがある。例えば、クライアント間で通信に利用可能な帯域にバラツキがある場合には、クライアント間でフレームデータを受信するタイミング、および画面の表示（更新）タイミングにズレが生じる。【０００５】
上記問題に鑑み、クライアント毎（幾つかのクライアント間で共通な通信環境毎）に、フレームレートを変更することが考えられる。この場合、クライアント（通信環境）毎に、異なるタイミングで、画面のキャプチャ、フレームデータの生成、およびフレームデータの送信が行われていた。このため、クライアント（通信環境）の増加につれてサーバの処理負荷が増加する問題があった。【０００６】
本発明の一態様は、サーバの処理負荷を軽減可能な技術を提供することを目的とする。
【課題を解決するための手段】
【０００７】
本発明の一態様は、サーバが画像のフレームデータを複数のクライアントにネットワークを介して配信する方法である。本方法では、サーバが備えるプロセッサが、上記フレームデータとして、第１のフレームデータと、第２のフレームデータとを生成し、上記複数のクライアントの全てに対し、第１のフレームデータを送信し、第１のフレームデータの送信間において、クライアントとサーバとの間の通信環境が所定条件を満たすクライアントについて第２のフレームデータを送信することを含む。
【発明の効果】
【０００８】
本発明の一態様によれば、サーバの処理負荷を軽減可能とすることができる。
【図面の簡単な説明】
【０００９】
【図１】図１は、ユーザ間で画像を共有するコラボレーションシステムを形成するネットワークシステムの構成例を示す。
【図２】図２は、実施形態１における画面データの送信方法の一例を示す。
【図３】図３は、キーフレームの決定方法の一例を示す図である。
【図４】図４は、各クライアントに対するキーフレームの送信制御の一例を模式的に示す図である。
【図５】図５は、図４に示した送信判定処理の一例を示すフローチャートである。
【図６】図６は、図１に示したサーバおよびクライアントのそれぞれとして使用可能な情報処理装置（コンピュータ）のハードウェア構成例を示す。
【図７】図７は、サーバの構成例を模式的に示す図である。
【図８】図８は、クライアントの構成例を模式的に示す図である。
【図９】図９は、サーバの処理例を示すフローチャートである。
【図１０】図１０は、応答時間リストのデータ構造例を示す。
【図１１】図１１は、クライアントの処理例を示すフローチャートである。
【図１２Ａ】図１２Ａは、実施形態２の説明図である。
【図１２Ｂ】図１２Ｂは、実施形態２の説明図である。
【図１３】図１３は、実施形態２におけるサーバの処理例を示すフローチャートである。
【図１４】図１４は、実施形態２における応答時間リストのデータ構造例を示す。
【図１５】図１５は、実施形態２におけるクライアントの処理例を示すフローチャートである。
【図１６】図１６は、実施形態３におけるサーバの構成例を模式的に示す図である。
【図１７】図１７は、実施形態３におけるサーバの処理例を示すフローチャートである。
【図１８Ａ】図１８Ａは、修正された応答時間リストの登録内容例を示す。
【図１８Ｂ】図１８Ｂは、修正された応答時間リストの登録内容例を示す。
【発明を実施するための形態】
【００１０】
以下、図面を参照して実施形態について説明する。実施形態の構成は例示であり、実施形態の構成に限定されない。  
【００１１】
〔実施形態１〕  
＜ネットワークシステム＞
図１は、実施形態に係るコラボレーションシステムを形成するネットワークシステムの構成例を示す。実施形態では、クライアント（「ユーザ」とも呼ばれる）間で画像を共有するコラボレーションシステムに適用されるサーバ、およびサーバの画像データ配信方法について説明する。
【００１２】
図１において、ネットワークシステムは、サーバ１と、複数のクライアント２（２Ａ〜２Ｅ）とを含む。以下の説明において、クライアント２Ａ〜２Ｅを区別しない場合には、「クライアント２」と表記する。クライアント２Ａ〜２Ｃは、ネットワーク３を介してサーバ１と接続されており、クライアント２Ｄ，２Ｅは、ネットワーク４を介してサーバ１と接続されている。ネットワーク３およびネットワーク４の夫々は、無線区間を含んでいても良い。
【００１３】
サーバ１は、クライアント２（ユーザ）間で共有される画像データと、画像編集用のプログラムを記憶している。サーバ１は、画像編集用の画面（編集用の画像を含んだ画面）のビットマップ（静止画データ）を所定のコーデック形式に基づき圧縮した圧縮データを生成し、この圧縮データをフレームデータとして各クライアント２に配信する。コーデック形式は、例えば、Joint Photographic Experts Group（ＪＰＥＧ），ＪＰＥＧ  ＸＲ，Graphics Interchange Format（ＧＩＦ），Portable Network Graphics（ＰＮＧ）などを例示できるが、これらに限定されない。各クライアント２は、圧縮された画面データの復元処理を行い、画面データに基づく画面をディスプレイに表示する。これによって、各クライアント２のディスプレイには、共通の画面が表示される。画面は、「画像」の一例である。
【００１４】
各クライアント２は、画面に表示された画像に対する編集（加工）を行うためのクライアント２間で共通のインタフェースを有している。インタフェースは、例えば、キーボードや、マウスなどのポインティングデバイスを含む入力装置である。クライアント２のオペレータは、入力装置を用いて、画像を編集するための操作入力を行う。操作入力によって入力された情報（「操作情報」という）は、ネットワーク（ネットワーク３又はネットワーク４）を介してサーバ１に送信される。操作情報は、画像の編集のみならず、画面内での画像の移動や回転のような表示態様の変更に係る操作も含む。
【００１５】
サーバ１は、操作情報を受信すると、画像データ編集用のプログラムの実行によって、当該操作情報を用いた画面データの更新（画像編集、表示態様変更など）が行われる。サーバ１は、更新された画面データを圧縮し各クライアント２へ送信する。これによって、各クライアント２のディスプレイには、更新された画面が表示される。
【００１６】
このようにして、複数のクライアント２が画面データを共有し、いずれかのクライアント２が行った画面データに対する操作（画像編集、表示態様の変更）の結果（操作に対するレスポンス）が他のクライアント２にも反映される。画面内の画像は、例えば、機械や電子機器などの設計図であり、共通の設計図を、複数のユーザによって編集することができる。但し、画像の内容は設計図に限定されず、あらゆる画像を含む。なお、「画像」は、静止画だけでなく動画も含む概念である。動画用のコーデック形式は、例えば、Ｈ．２６３,Ｈ．２６４,Moving Picture Experts Group（ＭＰＥＧ）などを例示できるが、これらに限定されない。
【００１７】
＜画面データの送信方法＞
次に、実施形態１におけるサーバ１の画面データの送信方法（「サーバの画像配信方法」の一例）について説明する。図２は、実施形態１における画面データの送信方法の一例を示す。図２において、太線矢印は、時間軸を示す。また、太線の矩形はキーフレームを示し、細線の矩形は非キーフレーム（差分画像）を示す。また、細線の矢印は、フレームがフレーム＃１の差分画像であることを示す。また、細線の破線矢印は、フレームの送信タイミングおよび遅延を示す。
【００１８】
サーバ１は、複数のクライアント２に対し画像のフレームデータを配信する。フレームデータは、所定のフレームレートに従った送信タイミングで各クライアント２に送信される。サーバ１は、フレームレートに従った数のフレームデータを生成する。クライアント２は、サーバ１から受信されたフレームデータを用いた復元処理によって画像を復元し、ディスプレイに表示することができる。
【００１９】
フレームデータは、キーフレームと、非キーフレームとを含む。キーフレームは、全てのクライアント２に送信されるフレームデータである。非キーフレームは、キーフレームの送信間において、クライアント２とサーバ１との間の通信環境に応じて送信されたり送信が取り止めとなったり（間引きされたり）するフレームデータである。キーフレームは、「第１のフレームデータ」の一例であり、非キーフレームは、「第２のフレームデータ」の一例である。
【００２０】
図２の例では、サーバ１で生成されたフレームデータとしてフレーム＃１〜＃５が図示されている。フレーム＃１〜フレーム＃５のうち、フレーム＃１およびフレーム＃４がキーフレームである。これに対し、フレーム＃２,フレーム＃３およびフレーム＃５が、非キーフレームである。
【００２１】
また、図２の例では、複数のクライアント２の一例として、クライアント＃１とクライアント＃２とが例示されている。クライアント＃１は、例えば、ネットワーク３に接続されたクライアント２Ａ,２Ｂ,２Ｃのいずれかであり、クライアント＃２は、ネットワーク４に接続されたクライアント２Ｄ,２Ｅのいずれかである。
【００２２】
クライアント＃１のネットワーク環境（通信環境）と、クライアント＃２のネットワーク環境とは異なっている。即ち、ネットワーク３とネットワーク４とはフレームデータの転送に利用可能な帯域が異なっている。例えば、クライアント＃１が利用可能な帯域（通信速度）は１０Ｍｂｐｓであるのに対し、クライアント＃２が利用可能な帯域（通信速度）は２Ｍｂｐｓである。換言すれば、クライアント＃１は、クライアント＃２よりも広帯域の通信環境を有する。
【００２３】
サーバ１は、クライアント＃１およびクライアント＃２の通信環境に応じて、クライアントに対する送信内容を変える。上述したように、キーフレームであるフレーム＃１およびフレーム＃４は、全てのクライアント２（クライアント＃１およびクライアント２）へ送信される。これに対し、非キーフレームであるフレーム＃２,フレーム＃３,フレーム＃５は、クライアント２とサーバ１との通信環境が所定条件を満たすか否かによって送信されたり、送信を取り止めたり（間引きされたり）する。
【００２４】
図２に示す例では、クライアント＃１についてフレーム＃２,フレーム＃３,フレーム＃５の送信に利用可能な空き帯域がある（即ち、通信環境が所定条件を満たす）と判定され、クライアント＃１に対し、フレーム＃２,フレーム＃３,フレーム＃５が送信されている。これに対し、クライアント＃２については、フレーム＃２,フレーム＃３,フレーム＃５の送信に利用可能な空き帯域がない（即ち、通信環境が所定条件を満たさない）と判定され、クライアント＃２に対するフレーム＃２,フレーム＃３,フレーム＃５の送信が取り止められている。すなわち、フレーム＃２,フレーム＃３,フレーム＃５が間引きされる。
【００２５】
このようなサーバ１によるフレームデータの送信制御によって、全てのクライアント２に対し、統一的なフレームデータの送信制御を行うことができる。すなわち、各クライアント２に対しては、少なくともキーフレームが送信される。このため、各クライアント２は、キーフレームに基づく画像をディスプレイに表示することができる。これによって、全てのクライアント２間で同一の画像が表示されることを保証することができる。
【００２６】
一方、クライアント２の通信環境に応じて非キーフレームが間引きされることで、クライアント２の通信環境に応じたフレームレートで各クライアント２へフレームデータを送信することができる。従って、従来のように、クライアント又は通信環境毎に異なるフレームデータを生成し送信する場合に比べてサーバ１の処理負荷を軽減することができる。
【００２７】
フレームデータは、画面のキャプチャによって得られた画面データ（ビットマップ：「キャプチャ画像」ともいう）の圧縮によって生成される。キャプチャ画像全体の圧縮によって得られたフレームデータを「圧縮画像」と称する。これに対し、過去の圧縮画像からの差分を「差分画像」という。差分画像は、キャプチャ画像間の差分データを抽出し、差分データを圧縮することによって得られる。
【００２８】
圧縮画像は、キャプチャ画像全体を圧縮したデータであるので、クライアント２は、圧縮画像単独でキャプチャ画像（画面データ）を復元することができる。これに対し、クライアント２は、差分画像を受信した場合、過去の圧縮画像の参照（合成）によってキャプチャ画像（画面データ）を復元する。圧縮画像は、動画圧縮におけるいわゆるＩピクチャ（Intra-Picture：「Ｉフレーム」とも呼ばれる）に相当し、差分画像は、いわゆるＰピクチャ（Predictive Picture：Ｐフレーム）に相当する。
【００２９】
全てのフレームデータに対し圧縮画像を適用することができる。もっとも、実施形態１では、初回に送信されるフレームデータ（キーフレーム：フレーム＃１）に圧縮画像を適用し、次回以降のフレームデータ（フレーム＃２,＃３,・・・）に対し、差分画像を適用する。  
【００３０】
この場合、クライアント２では、フレーム＃２以降のフレームデータを用いた画面データの復元処理において、フレーム＃１を用いる。差分画像のデータ量（サイズ）は、圧縮画像のデータ量（サイズ）よりも小さい。このため、次回以降のフレームデータに差分画像を適用することによって、クライアント２に対する転送データ量を削減することができる。
【００３１】
もっとも、２回目以降に送信されるキーフレームに対し、圧縮画像が適用されるように変形しても良い。例えば、フレーム＃４に対して圧縮画像を適用しても良い。この場合、サーバ１では、フレーム＃５として、フレーム＃４の差分画像を生成および送信する。これによって、クライアント２は、フレーム＃５を用いた画面データの復元を、フレーム＃５とフレーム＃４とを用いて実施することができる。換言すれば、非キーフレームを用いた画面データの復元に最後に受信されたキーフレームを用いるようにすることができる。なお、２回目以降に送信されるキーフレームの少なくとも１つに圧縮画像が適用されるようにしても良い。
【００３２】
データの復元に参照される画像の生成時点からの時間経過が大きくなるほど、当該画像との差分が大きくなると考えられる。差分が大きくなることは差分画像のサイズが大きくなることを意味する。上記のような変形がなされることで、２回目以降のキーフレーム（例えばフレーム＃４）の送信後に送信される非キーフレーム（フレーム＃５）のデータ量（サイズ）が小さくなることを期待することができる。
【００３３】
初回より後のキーフレーム（例えばフレーム＃４）の送信タイミングは、以下のようにして決定することができる。図３は、キーフレームの決定方法の一例を示す図である。サーバ１は、初回のキーフレーム（フレーム＃１）のフレームデータを送信した後は、所定のフレームレートに従ったタイミングで次以降のフレームデータを送信する。フレームレート（所定間隔（所定時間）の長さ）は、適宜設定可能であり、固定でも良く、状況に応じて可変としても良い。
【００３４】
サーバ１は、キーフレームが全てのクライアント２で受信されたことを検出したときに、次のフレームデータの送信タイミングでキーフレームを送信することを決定する。２回目以降のフレームデータに差分画像が適用される場合、サーバ１は、上記した次のフレームデータの送信タイミングで送信されるフレームデータ（差分画像）をキーフレームに設定する。これに対し、全てのキーフレームに圧縮画像を適用する場合には、サーバ１は、画面データの圧縮画像を生成し、上記した次のフレームデータの送信タイミングで送信する。
【００３５】
図３に示す例では、フレーム＃３の送信タイミングの後であってフレーム＃４の送信タイミングの前の或る時点（図３の破線参照）において、全てのクライアント２（クライアント＃１および＃２）で直前のキーフレーム（フレーム＃１）が受信されたことが検出されている。この場合、次のフレームデータ（フレーム＃４）の送信タイミングで、キーフレームが送信される。
【００３６】
キーフレームの受信判断は、例えば、サーバ１が、サーバ１と各クライアント２とを結ぶネットワークの遅延を測定し、当該遅延に基づいて判定することができる。図４は、各クライアント２に対するフレームの送信制御の一例を模式的に示す図である。図４において、サーバ１は、キーフレームを受信したクライアント２（ユーザ）から、キーフレームの受信を示す応答メッセージ（以下「受信応答」という）を受信する。図４は、クライアント数が３の例を示している。サーバ１は、キーフレームの受信応答の回収処理１０１と、圧縮画像および差分画像（キーフレームおよび非キーフレーム）を生成する圧縮処理１０２とを行う。
【００３７】
回収処理１０１は、各クライアント２から受信応答を回収する。回収処理１０１は、全クライアント２からの受信応答を回収すると、全クライアント２のキーフレーム受信を示す情報（以下、「受信通知」という）を圧縮処理１０２に伝達する。圧縮処理１０２は、フレームレートに合わせたフレームデータ（図４の符号“Ｆ”参照）の生成および出力を行う。
【００３８】
例えば、圧縮処理１０２は、上記信号を受けたときは、次に出力するフレームデータにキーフレームであることを示す識別子を付与する。上記信号がないときには、次に出力するフレームデータに識別子を付与しないか、非キーフレームであることを示す識別子を付与する。もっとも、キーフレームに識別子が付与されず、非キーフレームに識別子が付与されるようにしても良い。
【００３９】
なお、受信通知は、後述する送信判定処理１０３に供給され、送信判定処理１０３にて、送信対象がキーフレームか非キーフレームかが判定されるようにしても良い。この場合、識別子の付与は必ずしも必要ではない。
【００４０】
サーバ１は、クライアント２毎の送信処理を実行する。各クライアント２に対する送信処理は、クライアント２とサーバ１との応答時間の長い順で行われる。例えば、サーバ１は、各クライアント２について、キーフレームを送信してから受信応答を受信するまでの往復遅延時間（ラウンドトリップタイム：ＲＴＴ）を応答時間として測定する。応答時間（遅延）が大きい程、通信環境が良くない（例えば、サーバ１から遠い、利用可能な帯域が小さい）ことを意味する。応答時間が長い順に送信処理を実行することで、クライアント２間でキーフレームに基づく画面の表示タイミングを近づける（揃えるようにする）ことができる。
【００４１】
各クライアント２に対する送信処理では、送信対象のフレームデータに対する送信判定処理１０３が行われる。送信判定処理１０３では、送信対象のフレームデータ（送信データ）がキーフレームであれば、クライアント２への送信が行われる。これに対し、送信対象のフレームデータが非キーフレームであるときには、例えば、当該クライアント２への通信路に空き帯域があることを条件に、クライアント２への送信が行われる。空き帯域がなければ、差分画像の送信は取り止めとなる（すなわち、非キーフレームが間引きされる）。
【００４２】
図５は、図４に示した送信判定処理１０３の一例を示すフローチャートである。図５の０１において、送信データ（送信対象のフレームデータ）がキーフレームか否かが判定される。当該判定は、例えば、送信データがキーフレームであることを示す識別子が当該送信データに含まれているか否かによって行われる。もっとも、上述したように、０１の判定は、受信通知が回収処理１０１から届いているか否かによってなされても良い。
【００４３】
送信データがキーフレームである場合（０１,Ｙｅｓ）には、クライアント２に係る空き帯域ＢＷmaxの推定値が以下の計算式により算出される（０２）。その後、キーフレームが送信される（０３）。
ＢＷmax＝Σ（これまでに送信したキーフレームのデータ量）／Σ（これまでに送信したキーフレームに対する応答時間）
【００４４】
空き帯域ＢＷmaxは、フレームデータの送信に利用可能な単位時間当たりのデータ量を示す。単位時間は、例えば１秒であるが、他の時間長が用いられても良い。なお、サーバ１では、各キーフレームのデータ量（サイズ）と、往復遅延時間とが随時主記憶装置１２又は補助記憶装置１３に記録され、０３の処理において、空き帯域ＢＷmaxの算出に用いられる。
【００４５】
０２において、送信データがキーフレームでない場合（非キーフレームである場合：０２,Ｎｏ）には、過去１秒間に送信したデータ量と今回の送信データのデータ量との加算値が空き帯域ＢＷmax未満であるか否かが判定される（０４）。このとき、加算値が空き帯域ＢＷmax未満であれば（０４,Ｙｅｓ）、非キーフレームが送信される（０３）。これに対し、加算値が空き帯域ＢＷmax以上であれば（０４,Ｎｏ）、非キーフレームの送信が取りやめとなる。即ち、非キーフレームの間引きが行われる。
【００４６】
以上のように、送信判定処理１０３では、送信データがキーフレームであればキーフレームの送信が行われる。よって、キーフレームは、周期的に全てのクライアント２へ送信される。これに対し、非キーフレームについては、非キーフレームの送信に利用可能な空き帯域があれば（送信データ量が空き帯域ＢＷmaxに達していなければ）、非キーフレームの送信処理が行われる。
【００４７】
図４に示したように、各クライアント２（ユーザ）がキーフレームを受信する度に受信応答をサーバ１に返すことによって、リアルタイムに近い（準リアルタイムな）送信制御を行うことができる。
【００４８】
全てのクライアント２でのキーフレームの受信が検出されたときに、次に送信するフレームデータをキーフレームに設定することで、キーフレーム間の時間長を不必要に長くすることが回避され、隣接するキーフレーム間の差分を小さくすることが期待できる。換言すれば、帯域が狭いクライアント２で表示される画面の変化を小さくすることが期待できる。
【００４９】
また、上記した空き帯域ＢＷmaxの推定値を求めることで、時間の経過に伴い通信環境が変化する場合に、非キーフレームの送信可否判定の閾値（空き帯域ＢＷmax）を通信環境の変化に追従させることができる。もっとも、空き帯域の閾値は固定であっても良い。
【００５０】
なお、複数のクライアント２が同一の拠点に存在する。例えば、複数のクライアント２（例えば、図１に示すクライアント２Ａ,２Ｂ,２Ｃ）が同一のネットワーク（Local Area Network：ＬＡＮ）に収容されている場合には、送信データをブロードキャストで送信しても良い。このようにすれば、転送データ量のさらなる削減を図ることができる。以下、上記したサーバ１および各クライアント２の詳細について説明する。
【００５１】
＜情報処理装置のハードウェア構成＞
図６は、図１に示したサーバ１およびクライアント２のそれぞれとして使用可能な情報処理装置（コンピュータ）のハードウェア構成例を示す。情報処理装置１０は、バスＢを介して相互に接続されたプロセッサ１１，主記憶装置１２，補助記憶装置１３，入力装置１４，出力装置１５，ネットワークインタフェース（ＮＩＦ）１６を含んでいる。
【００５２】
プロセッサ１１は、例えば、Central Processing Unit（ＣＰＵ），Digital Signal Processor（ＤＳＰ）, Graphics Processing Unit（ＧＰＵ）などから少なくとも１つ選択される汎用プロセッサである。もっとも、プロセッサ１１として専用のプロセッサを適用することもできる。以下の説明では、プロセッサ１１がＣＰＵである例について説明する。
【００５３】
主記憶装置１２は、主記憶装置（メインメモリ）の一例であり、例えば、Read Only Memory（ＲＯＭ）及びRandom Access Memory（ＲＡＭ）を含む。主記憶装置１２は、プロセッサ１１の作業領域として使用される。
【００５４】
補助記憶装置１３は、プロセッサ１１によって実行される様々なプログラム（オペレーティングシステム（ＯＳ），アプリケーションプログラム）や、プロクラムの実行に際して使用されるデータを記憶する。補助記憶装置１３としては、例えば、ハードディスクドライブ（ＨＤＤ），Electrically Erasable Programmable Read-Only Memory（ＥＥＰＲＯＭ），フラッシュメモリ，Solid State Drive（ＳＳＤ）などから選択される少なくとも１つを用いることができる。また、補助記憶装置１３は、ディスク記憶媒体およびそのドライブ装置も含む。
【００５５】
入力装置１４は、ボタン、キー、キーボード、マウスのようなポインティングデバイス、タッチパネルの少なくとも１つを含み、情報およびデータの入力に使用される。入力装置１４は、音声入力装置（マイクロフォン）を含む。
【００５６】
出力装置１５は、ディスプレイ装置（ディスプレイ）を含む。また、出力装置１５は、音声出力装置（スピーカ）や印刷装置（プリンタ）を含むことができる。さらに、出力装置１５として、ランプやバイブレータを含むこともできる。
【００５７】
ＮＩＦ１６は、ネットワークを介して接続された通信機器との通信処理を司るインタフェース回路である。ＮＩＦ１６として、例えば、Local Area Network（ＬＡＮ）カード、或いはネットワークインタフェースカード（ＮＩＣ）を適用することができる。
【００５８】
プロセッサ１１は、補助記憶装置１３に記憶されたプログラムを主記憶装置１２にロードして実行することによって、様々な機能を発揮する。機能の発揮によって、情報処理装置１０は、サーバ１として動作したり、クライアント２として動作したりすることができる。
【００５９】
なお、プロセッサ１１によって実行される機能の一部又は全部は、ハードウェアのハードウェアロジック（ワイヤードロジック）によって実装されても良い。ハードウェアは、例えば、電気・電子回路，集積回路（例えば、Integrated Circuit（ＩＣ），Large Scale Integrated circuit（ＬＳＩ），Application Specific Integrated Circuit（ＡＳＩＣ）の少なくとも一つ）を含む。また、ハードウェアは、Field Programmable Gate Array（ＦＰＧＡ）のようなプログラマブルロジックデバイス（ＰＬＤ）を含む。この場合、一つのハードウェアが複数の機能を実行するようにしても良く、複数のハードウェアの組み合わせで一つの機能が実行されるようにしても良い。
【００６０】
プロセッサ１１は、「プロセッサ」，「制御装置」，「コントローラ」の一例である。また、主記憶装置１２、補助記憶装置１３のそれぞれは、「記憶装置」，「メモリ」，「コンピュータ読み取り可能な記録媒体」の一例である。
【００６１】
＜サーバの構成＞
図７は、サーバ１の構成例を模式的に示す図である。図７において、サーバ１として動作する情報処理装置１０（図６）は、プロセッサ１１がプログラムを実行することによって、図７に示すブロックを含んだ装置として動作する。図７において、サーバ１は、入力装置１４と接続された入力処理部１１１と、入力処理部１１１と接続されたアプリケーション実行部１１２と、アプリケーション実行部１１２および出力装置１５（ディスプレイ）と接続された画面表示制御部１１３とを含んでいる。
【００６２】
また、サーバ１は、画面表示制御部１１３と接続された画像取得部１１４と、画像取得部１１４と接続された画像処理部１１５と、画像処理部１１５と接続された送信判定部１１６とを含んでいる。さらに、サーバ１は、送信判定部１１６およびネットワークと接続された送信部１１７と、ネットワークと接続された受信部１１８と、受信部１１８と接続されたネットワーク状態の計測部１１９と、応答時間リスト１２０とを含んでいる。
【００６３】
入力処理部１１１,アプリケーション実行部１１２,画面表示制御部１１３,画像取得部１１４,画像処理部１１５,送信判定部および１１９は、図６に示した情報処理装置１０のプロセッサ１１（例えばＣＰＵ）がプログラムを実行することによって得られるプロセッサ１１の機能である。送信部１１７および受信部１１８は、ＮＩＦ１６の機能である。応答時間リスト１２０は、主記憶装置１２又は補助記憶装置１３上に作成される。
【００６４】
入力処理部１１１は、入力装置１４や受信部１１８から入力される情報やデータの処理を行う。アプリケーション実行部１１２は、アプリケーションプログラム（画像編集用のプログラムなど）を実行し、入力された情報に基づく処理を行う。例えば、入力処理部１１１は、受信部１１８で受信されるクライアント２からの画面の操作情報を得て、操作情報をアプリケーション実行部１１２に渡す。
【００６５】
アプリケーション実行部１１２は、操作情報を用いて、例えば、出力装置１５に表示される画面の描画用パラメータを変更する。画面表示制御部１１３は、ＶＲＡＭ（ビデオＲＡＭ）に、出力装置１５（ディスプレイ）に表示する画面データを描画し、画面データの映像信号を出力装置１５に送る。ＶＲＡＭは、主記憶装置１２に含まれている。出力装置１５（ディスプレイ）は、画面データに基づく画面を表示する。
【００６６】
画像取得部１１４は、例えば、フレームレートに合わせたタイミングで、画面表示制御部１１３によって描画された画面データを取得（キャプチャ）する。画像処理部１１５は、圧縮処理１０２（図４）を行い、画面データからフレームデータ（圧縮画像および差分画像）を生成して出力する。また、画像処理部１１５は、受信通知の受領時には、次に出力するフレームデータにキーフレームであることを示す識別子を付与する。
【００６７】
送信判定部１１６は、送信判定処理１０３（図４，図５）を実行する。送信判定処理１０３に用いる各クライアント２の空き帯域ＢＷmaxの算出用データは、主記憶装置１２又は補助記憶装置１３に記憶されている。送信部１１７は、送信対象のキーフレーム,差分画像を受け取り、宛先へ向けて送信する。受信部１１８は、クライアント２からの操作情報を受信して入力処理部１１１へ送ったり、受信応答を受信して計測部１１９に送ったりする。
【００６８】
計測部１１９は、各クライアント２の応答時間（ＲＴＴ）を計測する。例えば、計測部１１９は、各クライアント２について、キーフレームの送信時刻を送信部１１７から受け取る。一方、計測部１１９は、受信部１１８で受信されるキーフレームの受信応答の回収処理１０１を行い、受信応答の受信時刻を得る。計測部１１９は、送信時刻と受信時刻との差分から応答時間（ＲＴＴ）を得る。各クライアント２の応答時間は、応答時間リスト１２０に記憶される。送信判定部１１６は、応答時間リスト１２０を参照し、送信判定処理を行う順序を決定する。
【００６９】
また、計測部１１９は、全てのクライアント２からの受信応答が得られたときに、受信通知を画像処理部１１５に与える。このとき、画像処理部１１５は、フレームデータに識別子を設定する。これによって、送信判定部１１６は、送信判定処理１０３において、送信対象がキーフレームか非キーフレームか否かを判定することができる。
【００７０】
＜クライアント２の構成＞
図８は、クライアント２の構成例を模式的に示す図である。クライアント２として動作する情報処理装置１０は、プロセッサ１１がプログラムを実行することによって、図８に示すブロックを含んだ装置として動作する。
【００７１】
図８において、クライアント２は、受信部２０１と、画像（画面データ）の復元部２０２と、画面表示制御部２０３と、出力装置１５（ディスプレイ）と、受信応答部２０４と、入力処理部２０５と、送信部２０６とを含む装置として動作する。
【００７２】
復元部２０２,画面表示制御部２０３,受信応答部２０４および入力処理部２０５は、例えば、プロセッサ１１がプログラムを実行することによって得られるプロセッサ１１の機能である。受信部２０１および送信部２０６は、ＮＩＦ１６が有する機能である。
【００７３】
受信部２０１は、サーバ１から送信されたフレームデータ（キーフレーム，非キーフレーム）を受信する。復元部２０２は、受信部２０１で受信されたフレームデータ（圧縮画像，或いは圧縮画像および差分画像）を用いた復元処理によって画面データを得る。画面表示制御部２０３は、復元された画面データに基づく描画をＶＲＡＭに対して行い、描画された画面の映像信号が出力装置（ディスプレイ）１５に出力される。これによって、出力装置１５（ディスプレイ）には、サーバ１で生成された画面が表示される。
【００７４】
受信応答部２０４は、受信部２０１でキーフレームが受信されたときに、キーフレームの受信応答のメッセージを生成し、送信部２０６に与える。送信部は、受信応答をサーバ１へ送信する。なお、キーフレームには、サーバ１のアドレスが送信元アドレスとして付与されており、受信応答の宛先アドレスには、サーバ１のアドレスが設定される。
【００７５】
入力処理部２０５は、出力装置（ディスプレイ）１５に表示された画面に対し、入力装置１４から入力された操作の内容を示す操作情報を生成し、送信部２０６へ送る。送信部２０６は、サーバ１へ操作情報を送信する。
【００７６】
＜サーバ１の処理例＞
図９は、サーバ１の処理例を示すフローチャートである。図９に示す処理は、サーバ１として動作する情報処理装置１０のプロセッサ１１（ＣＰＵ）によって実行される。図９の例では、初回のフレームデータに圧縮画像を適用し、次以降のフレームデータに差分画像を用いる。また、図９の例では、受信通知の有無によって、送信対象がキーフレームか否かが判定される。さらに、図９の例では、受信応答の回収処理１０１は、別途プロセッサ１１によって実行され、受信通知が送信判定処理１０３に供給される。
【００７７】
最初の１０１では、サーバ１が各クライアント２と接続される。すると、プロセッサ１１は、計測部１１９として動作し、各クライアント２の応答時間リスト１２０を作成する（１０２）。サーバ１において、各クライアント２のアドレスは既知であり（例えば、補助記憶装置１３にて記憶）、プロセッサ１１は、例えば、ｐｉｎｇコマンドを用いて、各クライアントの応答時間（ＲＴＴ）を測定する。
【００７８】
図１０は、応答時間リスト１２０のデータ構造例を示す。応答時間リスト１２０は、例えば、クライアント２（ユーザ）の識別子と、応答時間（ＲＴＴ）とを含むエントリの集合で形成される。クライアント２の識別子は、クライアントを一意に識別可能な情報であれば良く、クライアントＩＤでもユーザ名でも、クライアント２のアドレスであっても良い。なお、図１０に示した各クライアント２Ａ〜２Ｅの応答時間は一例である。図１０に示すように、エントリは、応答時間の長い順でソートされており、エントリ順が送信判定処理の実行順序を示す。
【００７９】
図９に戻って、次の１０３では、プロセッサ１１は、画像取得部１１４として動作し、一定時間毎にサーバ画面（画面データ）をキャプチャする。続いて、プロセッサ１１は、画像処理部１１５として動作し、圧縮処理１０２（図４）の実行によって、圧縮画像および差分画像を生成する（１０４）。初回の１０４の処理では、圧縮画像が生成され、２回目以降の１０４の処理では、差分画像が生成される。なお、初回か否かは、例えば、フレームデータの送信回数をカウントするカウンタの管理によって行うことができる。但し、このような手法に限定されない。
【００８０】
次の１０５では、プロセッサ１１は、今回が初回のフレームデータ送信か否かを判定する。初回の送信であれば（１０５，Ｙｅｓ）、処理が１０７に進み、初回の送信でなければ（１０５，Ｎｏ）、処理が１０６に進む。
【００８１】
１０６では、プロセッサ１１は、送信判定部１１６として動作し、受信通知を受領しているか否かを判定する。受信通知が受領されていれば（１０６，Ｙｅｓ）、処理が１０７に進み、受信通知が受領されていなければ（１０６，Ｎｏ）、処理が１０８に進む。
【００８２】
１０７では、プロセッサ１１は、フレームデータをキーフレームに設定する。例えば、フレームデータに対し、キーフレームであることを示す識別子を付与する。次の１０８では、プロセッサ１１は、応答時間リスト１２０（図１０）から、応答時間の長い順で、一つのクライアントを選択する。
【００８３】
次の１０９では、プロセッサ１１は、送信判定部１１６として動作し、送信判定処理を実行する。送信判定処理の詳細は、図５を用いて説明した送信判定処理１０３と同じであるため、説明を省略する。送信判定処理の結果、送信を行う場合には、フレームデータの送信が行われ（１１０）、送信部１１７（ＮＩＦ１６）からフレームデータが送信される。その後、処理が１１１に進む。これに対し、送信判定処理の結果、送信が取り止め（間引き）となる場合には、処理が１１１に進む。
【００８４】
１１１では、プロセッサ１１は、残りのクライアント２があるか否かを判定する。残りのクライアント２がある場合には（１１１，Ｙｅｓ）、処理が１０８に戻り、次のクライアント２が選択される。これに対し、残りのクライアント２がない、すなわち全てのクライアント２に対する送信判定処理（１０９）が実行済みであるときには（１１１，Ｎｏ）、処理が１０３に戻る。
【００８５】
＜クライアントの処理例＞
図１１は、クライアント２の処理例を示すフローチャートである。図１１に示す処理は、クライアント２として動作する情報処理装置１０のプロセッサ１１（ＣＰＵ）によって実行される。
【００８６】
最初の１２１において、クライアント２がサーバ１と接続されると、プロセッサ１１は、サーバ１からのフレームデータの受信を待機する（１２２）。受信部２０１（ＮＩＦ１６）でフレームデータが受信されると、プロセッサ１１は、復元部２０２として動作し、既に説明した手法を用いてフレームデータの復号を行う（１２３）。続いて、プロセッサ１１は、画面表示制御部２０３として動作し、復号により得られた画面データに基づく画面を出力装置１５（ディスプレイ）に表示させる（１２４）。
【００８７】
１２５では、プロセッサ１１は、受信応答部２０４として動作し、受信データ、すなわち受信されたフレームデータがキーフレームか否かを判定する。当該判定は、例えば、フレームデータにキーフレームであることを示す識別子が付与されているか否かによって行うことができる。
【００８８】
フレームデータがキーフレームでなければ（１２５，Ｎｏ）、処理が１２２に戻り、次のフレームデータの受信待ち状態となる。これに対し、フレームデータがキーフレームであれば（１２５，Ｙｅｓ）、プロセッサ１１は、キーフレームの受信応答のメッセージを生成し、サーバ１へ送信する（１２６）。受信応答は、送信部２０６（ＮＩＦ１６）からサーバ１へ送信される。その後、処理が１２２へ戻る。
【００８９】
＜実施形態１の効果＞
実施形態１によれば、サーバ１のプロセッサ１１が、複数のクライアント２の全てに対してキーフレームを送信し、キーフレームの送信間において、クライアント２とサーバ１との間の通信環境が所定条件を満たす（空き帯域がある）クライアント２については非キーフレームを送信し、所定条件を満たさない（空き帯域がない）クライアント２については非キーフレームの送信を取り止める。
【００９０】
このように、１つのフレームデータの送信制御を行うことで、全てのクライアント２について、その通信環境に応じたフレームレートでフレームデータを送信することができる。これによって、サーバ１の処理負荷を軽減することができる。
【００９１】
また、サーバ１のプロセッサ１１は、各クライアント２について、送信対象のフレームデータがキーフレームであればキーフレームの送信を行い、送信対象のフレームデータが非キーフレームであれば、所定条件が満たされるか否かによって非キーフレームの送信又は送信の取り止めを行う送信判定処理を、往復遅延時間（応答時間）の長い順で実行する。これによって、クライアント２間でキーフレームに基づく画面（画像）が表示されるタイミングを近づけることができる。
【００９２】
また、サーバ１のプロセッサ１１は、クライアント２とサーバ１との間に非キーフレームを送信するための空き帯域があるか否かによって非キーフレームの送信を行うか否かを判定する。これによって、空き帯域がないときには非キーフレームの送信が取り止められることで、非キーフレームがネットワークで遅延し、クライアント２間でのキーフレームに基づく画面（画像）の表示タイミングのズレが大きくなるのを回避することができる。
【００９３】
また、サーバ１のプロセッサ１１は、これまでに送信したキーフレームの累積データ量をこれまでに送信したキーフレームに係るＲＴＴで除した値を空き帯域の推定値（ＢＷmax）として求める。そして、プロセッサ１１は、現在から単位時間（１秒）遡った期間におけるフレームデータのデータ量に送信対象の非キーフレームのデータ量を加算した値が推定値を下回るときに非キーフレームを送信し、そうでなければ送信を取り止める。これによって、実際の通信環境の変化に則して、非キーフレームを送信するか否かを決定することができる。  
【００９４】
また、サーバ１のプロセッサ１１は、非キーフレームとして、最後に送信されたキーフレームデータとの差分を示すデータ（差分画像）を送信することができる。これによって、フレームデータのサイズを小さくすることができる。すなわち、転送データ量を削減することができ、ネットワーク３やネットワーク４への負荷を軽減できる。
【００９５】
また、サーバ１のプロセッサ１１は、２回目以降に送信されるキーフレームとして、初回で送信されたキーフレームとの差分を示すデータを送信することができる。このように、キーフレームとして差分を示すデータを送信することで、さらに転送データ量を削減することができる。
【００９６】
また、サーバ１のプロセッサ１１は、各クライアント２からの応答に基づいて最後に送信したキーフレームが複数のクライアント２の全てで受信されたことを検出したときに、次のフレームデータの送信タイミングにおいてキーフレームを送信することを決定する。これによって、キーフレームの送信間隔が不必要に長くなるのを回避することができる。
【００９７】
＜変形例＞
なお、実施形態１で示したように、２回目以降のフレームデータに差分画像を適用する場合には、サーバ１およびクライアント２で以下のような処理を行うことが好ましい。例えば、図３に示す例を元に説明すると、サーバ１は、フレーム＃４の生成にあたり、フレーム＃１生成時点の画面データ（「画面データ＃１」とする）と、フレーム＃４生成時点の画面データ（「画面データ＃２」とする）の差分データを抽出する。サーバ１は、画面データ＃２を、次のキーフレームを送信するまでに送信される非キーフレームの差分画像を作成するための参照用画像として主記憶装置１２又は補助記憶装置１３に記憶する。
【００９８】
フレーム＃５の生成に当たり、サーバ１は、フレーム＃５生成用の画面データ（「画面データ＃３」とする）をキャプチャし、保存しておいた画面データ＃２との差分データを圧縮して差分画像（フレーム＃５）を生成し、送信する。
【００９９】
一方、フレーム＃４を受信したクライアント２では、以下のような処理を行う。すなわち、クライアント２は、フレーム＃１とフレーム＃４とを用いて、画面データを復元する。復元された画面データは、フレーム＃５の復元用データとして、主記憶装置１２又は補助記憶装置１３に記憶される。その後、フレーム＃５が受信された場合には、フレーム＃５の伸張処理により差分データを得て、保存しておいた復元データとの合成により、画面データ＃３相当の画面データを取得する。この画面データに基づく画面が出力装置１５で表示される。
【０１００】
このように、サーバ１では、２回目以降のキーフレームの送信時には、差分画像作成のために使用される画面データが更新される。一方、クライアント２では、復元用データが保存され、復元用データと非キーフレームから得られた差分データとの合成により表示対象の画像データが生成される。このようにすれば、最初のキーフレーム（フレーム＃１）からの差分が時間経過に伴って大きくなり、差分画像のデータ量（サイズ）が大きくなるのを抑えることができる。
【０１０１】
〔実施形態２〕
次に、実施形態２について説明する。実施形態２は、実施形態１と共通点を有するので、共通点については説明を省略し、主として相違点について説明する。
【０１０２】
実施形態１では、全てのクライアント２からの受信応答がサーバ１で得られたことを契機として、次のフレームデータがキーフレームに設定される。しかしながら、遠隔に存在する（応答時間が長い）クライアント２が１つでも存在する場合では、そのようなクライアントの存在によって、キーフレームの送信間隔（インターバルの長さ）が長時間化する。この場合、キーフレームの送信時刻から時間が経過する程、キーフレームからの差分が大きくなり、非キーフレームとして送信される差分画像の圧縮率が低下することが考えられる。圧縮率の低下は転送データ量の増加を意味する。実施形態２は、この様な問題を回避するための構成について説明する。
【０１０３】
図１２Ａおよび図１２Ｂは、実施形態２の説明図である。図１２Ａおよび図１２Ｂでは、時間軸上に配置された複数の矩形のブロックが図示されている。各ブロックは、フレーム送信のためにサーバ１でキャプチャされる画面データを示す。ブロック上の矢印は、差分データ抽出のために参照される画面データを示す。参照される画面データは、キーフレームの送信を契機に更新される。
【０１０４】
図１２Ａに示す例では、フレーム＃５が次のキーフレームとなっており、フレーム＃６，フレーム＃７は、フレーム＃５の画面データからの差分データの圧縮により得られる。これは、実施形態１の変形例で示した手法と同じである。ここで、時間経過につれて、フレーム＃１（キーフレーム）との差分が大きくなるものと仮定する。
【０１０５】
この場合、フレーム＃６，フレーム＃７として、フレーム＃５の画面データの参照によって生成された差分画像が送信されることで、フレーム＃６，フレーム７のデータ量が削減される。しかし、フレーム＃１とフレーム＃４との差分が大きく、フレーム＃４のデータサイズが大きくなっている。一方、複数のクライアント２の一部からのキーフレームの受信応答は、フレーム＃３の送信前にサーバ１で受信されているものとする。
【０１０６】
そこで、実施形態２では、複数のクライアント２を、受信応答の受信タイミングに従ってクラスタリングする。例えば、複数のクライアント２が「遠隔者」と「近隣者」との二つのクラスタにクラスタリングされる。「近隣者」は、フレーム＃３の送信タイミングの前にサーバ１が受信応答を受信したクライアント２であり、「遠隔者」は、「近隣者」以外のクライアント２である。
【０１０７】
図１２Ｂに示すように、サーバ１は、近隣者向けに、フレーム＃３をサブキーフレームとして設定する。サブキーフレームは、クライアント全体でなく、所定クラスタに属するクライアント２に対して有効なキーフレームである。サブキーフレームの送信を契機として、参照用の画面データは更新される。
【０１０８】
図１２の例では、フレーム＃３の画面データが参照用の画面データに設定され、「近隣者」に対するフレーム＃４は、フレーム＃３の画面データからの差分データを圧縮した差分画像となる。これによって、「近隣者」に対するフレーム＃４のデータ量を削減することができる。また、「近隣者」に対するフレーム＃５（キーフレーム）も、フレーム＃３の画面データからの差分で生成されるため、データ量が削減される。一方、「遠隔者」に対しては、図１２Ａに示したような状態が維持される。
【０１０９】
上記したクラスタリングおよびサブキーフレームの設定は、プロセッサ１１によって実行される。図１３は、実施形態２におけるサーバ１の処理例を示すフローチャートである。図１３に示すサーバ１の処理は、図９に示したサーバ１の処理と、以下の点で異なっている。第１に、１０２の処理の代わりに１０２Ａの処理が設けられている。第２に、１０６の処理と１０８の処理の間に１１２の処理が挿入されている。
【０１１０】
１０２Ａでは、プロセッサ１１は、応答時間リスト１２０を作成するとともに、応答時間に基づいてクライアントをクラスタリングする。図１４は、実施形態２における応答時間リスト１２０の例を示す。
【０１１１】
図１４に示す応答時間リストは、図１０に示した応答時間リストの内容に加えて、クライアント２が所属するクラスタを示す情報が含まれている。図１４に示す例では、クラスタリングは、一例として、全クライアント２中で最も長い応答時間を基準にして、３つのクラスタ（クラスタ＃１，クラスタ＃２，クラスタ＃３）に分割されている。
【０１１２】
クラスタ＃１は、最長応答時間の１／８〜１／４の範囲に応答時間が入るクライアント２が属するクラスタである。クラスタ＃２は、最長応答時間の１／４〜１／２の範囲に応答時間が入るクライアント２が属するクラスタである。クラスタ＃３は、最長応答時間の１／２〜１の範囲に応答時間が入るクライアント２が属するクラスタである。
【０１１３】
図１３の１１２の処理では、プロセッサ１１は、全てのクライアント２からキーフレームの受信応答又はサブキーフレームの受信応答が受信されているクラスタがあれば、当該クラスタに属するクライアント２向けのフレームデータをサブキーフレームに設定する。
【０１１４】
例えば、プロセッサ１１は、各クライアント２からのキーフレームの受信応答およびサブキーフレームの受信応答の受信状況を主記憶装置１２又は補助記憶装置１３に記録する。プロセッサ１１は、当該状況と応答時間リスト（図１４）とを参照して、該当のクラスタがあるか否かを判定する。このとき、該当の複数のクラスタが存在する場合には、夫々のクラスタに属するクライアント２向けのフレームデータがサブキーフレームに設定される。送信処理は、応答時間の長いクラスタ順で実行される。
【０１１５】
図１３における１０２Ａおよび１１２以外の処理については実施形態１（図９）と同じであるので、説明を省略する。
【０１１６】
図１５は、実施形態２におけるクライアント２の処理例を示すフローチャートである。図１５に示す処理は、１２７および１２８の処理が追加されている点で、実施形態１における処理（図１１）と異なっている。
【０１１７】
すなわち、図１５の１２５の処理で、受信データがキーフレームでないと判定された場合には（１２５，Ｎｏ）、受信データがサブキーフレームか否かが判定される（１２７）。このとき、受信データがサブキーフレームでなければ（１２７，Ｎｏ）、処理が１２２に戻る。これに対し、受信データがサブキーフレームであれば（１２７，Ｙｅｓ）、処理が１２８に進み、サブキーフレームの受信応答のメッセージが生成され、サブキーフレームの受信応答がサーバ１へ送信される。
【０１１８】
以上を除き、図１５に示す処理は、図１１と同じであるので、説明を省略する。また、上記を除き、実施形態２の構成および動作は実施形態１とほぼ同様であるので、説明を省略する。
【０１１９】
実施形態２では、サーバ１のプロセッサ１１は、複数のクライアント２に係る往復遅延時間（ＲＴＴ）に応じて複数のクライアント２を複数のクラスタにクラスタリングする。そして、プロセッサ１１は、複数のクライアント２の全てからキーフレームの受信を示す応答が受信される前に、或るクラスタに属するクライアント２の全てから応答が受信されている場合には、或るクラスタに属するクライアントの全てを送信対象とするサブキーフレームの送信を決定する。
【０１２０】
これによって、ＲＴＴが比較的短いクライアント２に対するフレームデータの圧縮率が低下するのを回避することが可能となる。換言すれば、クライアント２のクラスタリングおよびサブキーフレームの設定によって、一部のクライアント２へ向けて送信されるフレームデータの圧縮率を上げることができる。
【０１２１】
〔実施形態３〕
次に、実施形態３について説明する。実施形態３は、実施形態１と共通点を有するので、共通点については説明を省略し、主として相違点について説明する。実施形態１，実施形態２では、応答時間の長い順で、クライアント２に対する送信処理が実施されていた。
【０１２２】
実施形態１において説明したように、各クライアント２からの操作情報は、サーバ１へ送られ、サーバ１で操作情報を反映した画面データの更新が行われ、各クライアント２に送信される。このとき、操作情報を送信したクライアント２において、操作に伴う画面の更新に時間がかかると、オペレータに対して良好な操作感を与えることができない。そこで、実施形態３では、サーバ１が操作情報を受信した場合には、操作情報の送信元のクライアント２に対する送信処理の優先順位を上げる。
【０１２３】
図１６は、実施形態３におけるサーバ１の構成例を模式的に示す図である。図１６に示すサーバ１は、実施形態１の構成（図７）に加えて、操作ユーザ判定部１２１をさらに備えている。
【０１２４】
操作ユーザ判定部１２１は、受信部１１８で操作情報が受信されたときに、操作情報の送信元のクライアント２の識別子を受信部１１８から得る。操作ユーザ判定部１２１は、て、送信元のクライアント２のエントリが先頭になるように、応答時間リスト１２０のエントリ登録順を変更する。
【０１２５】
図１７は、実施形態３におけるサーバ１の処理例を示すフローチャートである。図１７に示す処理は、実施形態１における処理（図９）と以下の点で異なっている。第１に、１０３の処理と１０４の処理との間に、１３１の処理が挿入されている。第２に、１０８の処理の代わりに、１０８Ａの処理が設けられている。
【０１２６】
１３１では、プロセッサ１１は、操作ユーザ（操作情報の送信元のクライアント２）の送信判定処理の優先度が上がるように、応答時間リスト１２０のエントリ登録順を修正する。実施形態３の例では、操作ユーザの優先度が最大となるように修正される。但し、優先度が最大に設定されることは必須ではない。
【０１２７】
１０８Ａでは、プロセッサ１１は、応答時間リストから優先度が最大（優先順位が最上位）のクライアント２を送信判定処理１０３（１０９の処理）の対象として選択する。もっとも、プロセッサ１１の処理としては、応答時間リスト１２０の先頭エントリに登録されたクライアント２を最初の送信判定処理の対象として選択するので、１０８の処理と１０８Ａの処理は実質的に変わらない。
【０１２８】
図１８Ａおよび図１８Ｂは、１３１の処理によって修正された応答時間リスト１２０の登録内容例を示す。応答時間リスト１２０の登録内容は、操作情報がない場合（初期状態）では、図１４に示したように、応答時間の長い順で、クライアント２Ａ〜２Ｅのエントリが登録されている。これに対し、例えば、クライアント２Ｅからの操作情報が受信された場合には、図１８Ａに示すように、クライアント２Ｅのエントリの登録位置が先頭に変更される。上述したように、送信判定処理は、応答時間リスト１２０のエントリ登録順でなされるため、クライアント２Ｅについての送信判定処理が最初になされるようになる。
【０１２９】
図１８Ｂは、クライアント２Ｅについての送信判定処理が開始された後に、クライアント２Ｃからの操作情報が受信された場合を示す。この場合、クライアント２Ｃのエントリが先頭に移動する。クライアント２Ｅのエントリは、応答時間の長さに従って最下位に戻される。これによって、クライアント２Ｃについての送信判定処理が優先的に実行される。なお、クライアント２Ｃについての送信判定処理が開始されると、クライアント２Ｃのエントリは、元の位置に戻る。即ち、登録内容が図１４の状態に戻る。
【０１３０】
図１７の１３１および１０８Ａ以外の処理は、図９の処理と同じであるので、説明を省略する。また、実施形態３の他の構成は、実施形態１と同じであるので、説明を省略する。
【０１３１】
実施形態３では、サーバ１のプロセッサ１１は、画面に対する操作情報が受信されたときに当該操作情報の送信元のクライアント２に対する送信判定処理の優先順位を上げる。これによって、当該クライアント２へ操作情報が反映されたフレームデータが送信されるタイミングを早めることができる。これによって、操作情報の送信元のクライアント２のオペレータが受ける操作感を向上させることができる。
【０１３２】
なお、実施形態３の構成を実施形態２に組み合わせることができる。その他、実施形態１，実施形態２，および実施形態３で示した構成は、適宜組み合わせることが可能である。
【符号の説明】
【０１３３】
１・・・サーバ
２・・・クライアント
１０・・・情報処理装置
１１・・・プロセッサ
１２・・・主記憶装置
１３・・・補助記憶装置
１６・・・ネットワークインタフェース
【図１】
2016088244.tif 000003
【図２】
2016088244.tif 000004
【図３】
2016088244.tif 000005
【図４】
2016088244.tif 000006
【図５】
2016088244.tif 000007
【図６】
2016088244.tif 000008
【図７】
2016088244.tif 000009
【図８】
2016088244.tif 000010
【図９】
2016088244.tif 000011
【図１０】
2016088244.tif 000012
【図１１】
2016088244.tif 000013
【図１２Ａ】
2016088244.tif 000014
【図１２Ｂ】
2016088244.tif 000015
【図１３】
2016088244.tif 000016
【図１４】
2016088244.tif 000017
【図１５】
2016088244.tif 000018
【図１６】
2016088244.tif 000019
【図１７】
2016088244.tif 000020
【図１８Ａ】
2016088244.tif 000021
【図１８Ｂ】
2016088244.tif 000022
【手続補正書】
【提出日】平成29年6月1日(2017.6.1)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
サーバが画像のフレームデータを複数のクライアントにネットワークを介して配信する方法であって、
前記サーバが備えるプロセッサが、
前記フレームデータとして、第１のフレームデータと、第２のフレームデータとを生成し、
前記複数のクライアントの全てに対し、前記第１のフレームデータを送信し、
前記第１のフレームデータの送信間において、クライアントと前記サーバとの間の通信環境が所定条件を満たすクライアントについて前記第２のフレームデータを送信する
ことを含むサーバの画像配信方法。
【請求項２】
前記プロセッサは、各クライアントについて、送信対象のフレームデータが前記第１のフレームデータであれば当該第１のフレームデータの送信を行い、送信対象のフレームデータが前記第２のフレームデータであれば前記所定条件が満たされるか否かによって当該第２のフレームデータの送信又は送信の取り止めを行う送信判定処理を、往復遅延時間の長い順で実行する
請求項１に記載のサーバの画像配信方法。
【請求項３】
前記プロセッサは、各クライアントについて、クライアントと前記サーバとの間に前記第２のフレームデータを送信するための空き帯域が前記ネットワークにあるか否かによって前記所定条件が満たされるか否かを判定する
請求項１又は２に記載のサーバの画像配信方法。
【請求項４】
前記プロセッサは、これまでに送信した前記第１のフレームデータの累積データ量をこれまでに送信した前記第１のフレームデータに係る往復遅延時間で除した値を空き帯域の推定値として求め、現在から単位時間遡った期間におけるフレームデータのデータ量に送信対象の第２のフレームデータのデータ量を加算した値が前記推定値を下回るときに当該第２のフレームデータを送信し、そうでなければ当該第２のフレームデータの送信を取り止める
請求項３に記載のサーバの画像配信方法。
【請求項５】
前記プロセッサは、前記第２のフレームデータとして、最後に送信された前記第１のフレームデータとの差分を示すデータを送信する
請求項１から４のいずれか１項に記載のサーバの画像配信方法。
【請求項６】
前記プロセッサは、２回目以降に送信される前記第１のフレームデータとして、初回で送信された前記第１のフレームデータとの差分を示すデータを送信する
請求項１から５のいずれか１項に記載のサーバの画像配信方法。
【請求項７】
前記プロセッサは、各クライアントからの応答に基づいて最後に送信した第１のフレームデータが前記複数のクライアントの全てで受信されたことを検出したときに、次のフレームデータの送信タイミングにおいて第１のフレームデータを送信することを決定する
請求項１から６のいずれか１項に記載のサーバの画像配信方法。
【請求項８】
前記プロセッサは、前記複数のクライアントに係る往復遅延時間に応じて前記複数のクライアントを複数のクラスタにクラスタリングし、
前記複数のクライアントの全てから前記第１のフレームデータの受信を示す応答が受信される前に、或るクラスタに属するクライアントの全てから前記応答が受信されている場合には、前記或るクラスタに属するクライアントの全てを送信対象とする第３のフレームデータの送信を決定する
請求項１から７のいずれか１項に記載のサーバの画像配信方法。
【請求項９】
前記プロセッサは、前記画像に対する操作情報が受信されたときに当該操作情報の送信元のクライアントに対する前記送信判定処理の優先順位を上げる
請求項２から８のいずれか１項に記載のサーバの画像配信方法。
【請求項１０】
画像のフレームデータを複数のクライアントにネットワークを介して配信するサーバとして動作するコンピュータに、
前記フレームデータとして、第１のフレームデータと、第２のフレームデータとを生成するステップと、
前記複数のクライアントの全てに対し、前記第１のフレームデータを送信するステップと、
前記第１のフレームデータの送信間において、クライアントと前記サーバとの間の通信環境が所定条件を満たすクライアントについて前記第２のフレームデータを送信するステップと
を実行させるプログラム。
【請求項１１】
画像のフレームデータを複数のクライアントにネットワークを介して配信するサーバであって、
前記フレームデータとして、第１のフレームデータと、第２のフレームデータとを生成する処理と、前記複数のクライアントの全てに対し、前記第１のフレームデータを送信する処理と、前記第１のフレームデータの送信間において、クライアントと前記サーバとの間の通信環境が所定条件を満たすクライアントについて前記第２のフレームデータを送信する処理と、を実行する制御装置
を含むサーバ。
【手続補正２】
【補正対象書類名】明細書
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、サーバの画像配信方法に関する。
【背景技術】
【０００２】
コラボレーションシステムの一つとして、サーバの画面を複数のクライアント（ユーザとも呼ばれる）に転送（配信）することによって、複数のクライアントが画面を共有するシステムがある。サーバは、例えば、画面をキャプチャして得られた静止画データを所定のフレームレート（単位時間当たりのフレーム数）で各クライアントに送信する。各クライアントでは、入力装置を用いて画面の操作情報が入力されると、操作情報はサーバに送信される。サーバは、操作情報に基づき画面を更新し、更新された画面のフレームデータが各クライアントに配信される。これによって、１つの画面に対して、複数のクライアントのオペレータが操作を行うことができる。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２００９-１１００４１号公報
【特許文献２】特開平９−２０４３８０号公報
【特許文献３】特開２００５−２６７３４７号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
しかしながら、各クライアントとサーバとを結ぶネットワーク環境（通信環境）は、クライアント間で一様でないことがある。例えば、クライアント間で通信に利用可能な帯域にバラツキがある場合には、クライアント間でフレームデータを受信するタイミング、および画面の表示（更新）タイミングにズレが生じる。
【０００５】
上記問題に鑑み、クライアント毎（幾つかのクライアント間で共通な通信環境毎）に、フレームレートを変更することが考えられる。この場合、クライアント（通信環境）毎に、異なるタイミングで、画面のキャプチャ、フレームデータの生成、およびフレームデータの送信が行われていた。このため、クライアント（通信環境）の増加につれてサーバの処理負荷が増加する問題があった。
【０００６】
本発明の一態様は、サーバの処理負荷を軽減可能な技術を提供することを目的とする。
【課題を解決するための手段】
【０００７】
本発明の一態様は、サーバが画像のフレームデータを複数のクライアントにネットワークを介して配信する方法である。本方法では、サーバが備えるプロセッサが、上記フレームデータとして、第１のフレームデータと、第２のフレームデータとを生成し、上記複数のクライアントの全てに対し、第１のフレームデータを送信し、第１のフレームデータの送信間において、クライアントとサーバとの間の通信環境が所定条件を満たすクライアントについて第２のフレームデータを送信することを含む。
【発明の効果】
【０００８】
本発明の一態様によれば、サーバの処理負荷を軽減可能とすることができる。
【図面の簡単な説明】
【０００９】
【図１】図１は、ユーザ間で画像を共有するコラボレーションシステムを形成するネットワークシステムの構成例を示す。
【図２】図２は、実施形態１における画面データの送信方法の一例を示す。
【図３】図３は、キーフレームの決定方法の一例を示す図である。
【図４】図４は、各クライアントに対するキーフレームの送信制御の一例を模式的に示す図である。
【図５】図５は、図４に示した送信判定処理の一例を示すフローチャートである。
【図６】図６は、図１に示したサーバおよびクライアントのそれぞれとして使用可能な情報処理装置（コンピュータ）のハードウェア構成例を示す。
【図７】図７は、サーバの構成例を模式的に示す図である。
【図８】図８は、クライアントの構成例を模式的に示す図である。
【図９】図９は、サーバの処理例を示すフローチャートである。
【図１０】図１０は、応答時間リストのデータ構造例を示す。
【図１１】図１１は、クライアントの処理例を示すフローチャートである。
【図１２Ａ】図１２Ａは、実施形態２の説明図である。
【図１２Ｂ】図１２Ｂは、実施形態２の説明図である。
【図１３】図１３は、実施形態２におけるサーバの処理例を示すフローチャートである。
【図１４】図１４は、実施形態２における応答時間リストのデータ構造例を示す。
【図１５】図１５は、実施形態２におけるクライアントの処理例を示すフローチャートである。
【図１６】図１６は、実施形態３におけるサーバの構成例を模式的に示す図である。
【図１７】図１７は、実施形態３におけるサーバの処理例を示すフローチャートである。
【図１８Ａ】図１８Ａは、修正された応答時間リストの登録内容例を示す。
【図１８Ｂ】図１８Ｂは、修正された応答時間リストの登録内容例を示す。
【発明を実施するための形態】
【００１０】
以下、図面を参照して実施形態について説明する。実施形態の構成は例示であり、実施形態の構成に限定されない。
【００１１】
〔実施形態１〕
＜ネットワークシステム＞
図１は、実施形態に係るコラボレーションシステムを形成するネットワークシステムの構成例を示す。実施形態では、クライアント（「ユーザ」とも呼ばれる）間で画像を共有するコラボレーションシステムに適用されるサーバ、およびサーバの画像データ配信方法について説明する。
【００１２】
図１において、ネットワークシステムは、サーバ１と、複数のクライアント２（２Ａ〜２Ｅ）とを含む。以下の説明において、クライアント２Ａ〜２Ｅを区別しない場合には、「クライアント２」と表記する。クライアント２Ａ〜２Ｃは、ネットワーク３を介してサーバ１と接続されており、クライアント２Ｄ，２Ｅは、ネットワーク４を介してサーバ１と接続されている。ネットワーク３およびネットワーク４の夫々は、無線区間を含んでいても良い。
【００１３】
サーバ１は、クライアント２（ユーザ）間で共有される画像データと、画像編集用のプログラムを記憶している。サーバ１は、画像編集用の画面（編集用の画像を含んだ画面）のビットマップ（静止画データ）を所定のコーデック形式に基づき圧縮した圧縮データを生成し、この圧縮データをフレームデータとして各クライアント２に配信する。コーデック形式は、例えば、Joint Photographic Experts Group（ＪＰＥＧ），ＪＰＥＧ  ＸＲ，Graphics Interchange Format（ＧＩＦ），Portable Network Graphics（ＰＮＧ）などを
例示できるが、これらに限定されない。各クライアント２は、圧縮された画面データの復元処理を行い、画面データに基づく画面をディスプレイに表示する。これによって、各クライアント２のディスプレイには、共通の画面が表示される。画面は、「画像」の一例である。
【００１４】
各クライアント２は、画面に表示された画像に対する編集（加工）を行うためのクライアント２間で共通のインタフェースを有している。インタフェースは、例えば、キーボードや、マウスなどのポインティングデバイスを含む入力装置である。クライアント２のオペレータは、入力装置を用いて、画像を編集するための操作入力を行う。操作入力によって入力された情報（「操作情報」という）は、ネットワーク（ネットワーク３又はネットワーク４）を介してサーバ１に送信される。操作情報は、画像の編集のみならず、画面内での画像の移動や回転のような表示態様の変更に係る操作も含む。
【００１５】
サーバ１は、操作情報を受信すると、画像データ編集用のプログラムの実行によって、当該操作情報を用いた画面データの更新（画像編集、表示態様変更など）が行われる。サーバ１は、更新された画面データを圧縮し各クライアント２へ送信する。これによって、各クライアント２のディスプレイには、更新された画面が表示される。
【００１６】
このようにして、複数のクライアント２が画面データを共有し、いずれかのクライアント２が行った画面データに対する操作（画像編集、表示態様の変更）の結果（操作に対するレスポンス）が他のクライアント２にも反映される。画面内の画像は、例えば、機械や電子機器などの設計図であり、共通の設計図を、複数のユーザによって編集することができる。但し、画像の内容は設計図に限定されず、あらゆる画像を含む。なお、「画像」は、静止画だけでなく動画も含む概念である。動画用のコーデック形式は、例えば、Ｈ．２６３,Ｈ．２６４,Moving Picture Experts Group（ＭＰＥＧ）などを例示できるが、これらに限定されない。
【００１７】
＜画面データの送信方法＞
次に、実施形態１におけるサーバ１の画面データの送信方法（「サーバの画像配信方法」の一例）について説明する。図２は、実施形態１における画面データの送信方法の一例を示す。図２において、太線矢印は、時間軸を示す。また、太線の矩形はキーフレームを示し、細線の矩形は非キーフレーム（差分画像）を示す。また、細線の矢印は、フレームがフレーム＃１の差分画像であることを示す。また、細線の破線矢印は、フレームの送信タイミングおよび遅延を示す。
【００１８】
サーバ１は、複数のクライアント２に対し画像のフレームデータを配信する。フレームデータは、所定のフレームレートに従った送信タイミングで各クライアント２に送信される。サーバ１は、フレームレートに従った数のフレームデータを生成する。クライアント２は、サーバ１から受信されたフレームデータを用いた復元処理によって画像を復元し、ディスプレイに表示することができる。
【００１９】
フレームデータは、キーフレームと、非キーフレームとを含む。キーフレームは、全てのクライアント２に送信されるフレームデータである。非キーフレームは、キーフレームの送信間において、クライアント２とサーバ１との間の通信環境に応じて送信されたり送信が取り止めとなったり（間引きされたり）するフレームデータである。キーフレームは、「第１のフレームデータ」の一例であり、非キーフレームは、「第２のフレームデータ」の一例である。
【００２０】
図２の例では、サーバ１で生成されたフレームデータとしてフレーム＃１〜＃５が図示されている。フレーム＃１〜フレーム＃５のうち、フレーム＃１およびフレーム＃４がキ
ーフレームである。これに対し、フレーム＃２,フレーム＃３およびフレーム＃５が、非
キーフレームである。
【００２１】
また、図２の例では、複数のクライアント２の一例として、クライアント＃１とクライアント＃２とが例示されている。クライアント＃１は、例えば、ネットワーク３に接続されたクライアント２Ａ,２Ｂ,２Ｃのいずれかであり、クライアント＃２は、ネットワーク４に接続されたクライアント２Ｄ,２Ｅのいずれかである。
【００２２】
クライアント＃１のネットワーク環境（通信環境）と、クライアント＃２のネットワーク環境とは異なっている。即ち、ネットワーク３とネットワーク４とはフレームデータの転送に利用可能な帯域が異なっている。例えば、クライアント＃１が利用可能な帯域（通信速度）は１０Ｍｂｐｓであるのに対し、クライアント＃２が利用可能な帯域（通信速度）は２Ｍｂｐｓである。換言すれば、クライアント＃１は、クライアント＃２よりも広帯域の通信環境を有する。
【００２３】
サーバ１は、クライアント＃１およびクライアント＃２の通信環境に応じて、クライアントに対する送信内容を変える。上述したように、キーフレームであるフレーム＃１およびフレーム＃４は、全てのクライアント２（クライアント＃１およびクライアント２）へ送信される。これに対し、非キーフレームであるフレーム＃２,フレーム＃３,フレーム＃５は、クライアント２とサーバ１との通信環境が所定条件を満たすか否かによって送信されたり、送信を取り止めたり（間引きされたり）する。
【００２４】
図２に示す例では、クライアント＃１についてフレーム＃２,フレーム＃３,フレーム＃５の送信に利用可能な空き帯域がある（即ち、通信環境が所定条件を満たす）と判定され、クライアント＃１に対し、フレーム＃２,フレーム＃３,フレーム＃５が送信されている。これに対し、クライアント＃２については、フレーム＃２,フレーム＃３,フレーム＃５の送信に利用可能な空き帯域がない（即ち、通信環境が所定条件を満たさない）と判定され、クライアント＃２に対するフレーム＃２,フレーム＃３,フレーム＃５の送信が取り止められている。すなわち、フレーム＃２,フレーム＃３,フレーム＃５が間引きされる。
【００２５】
このようなサーバ１によるフレームデータの送信制御によって、全てのクライアント２に対し、統一的なフレームデータの送信制御を行うことができる。すなわち、各クライアント２に対しては、少なくともキーフレームが送信される。このため、各クライアント２は、キーフレームに基づく画像をディスプレイに表示することができる。これによって、全てのクライアント２間で同一の画像が表示されることを保証することができる。
【００２６】
一方、クライアント２の通信環境に応じて非キーフレームが間引きされることで、クライアント２の通信環境に応じたフレームレートで各クライアント２へフレームデータを送信することができる。従って、従来のように、クライアント又は通信環境毎に異なるフレームデータを生成し送信する場合に比べてサーバ１の処理負荷を軽減することができる。
【００２７】
フレームデータは、画面のキャプチャによって得られた画面データ（ビットマップ：「キャプチャ画像」ともいう）の圧縮によって生成される。キャプチャ画像全体の圧縮によって得られたフレームデータを「圧縮画像」と称する。これに対し、過去の圧縮画像からの差分を「差分画像」という。差分画像は、キャプチャ画像間の差分データを抽出し、差分データを圧縮することによって得られる。
【００２８】
圧縮画像は、キャプチャ画像全体を圧縮したデータであるので、クライアント２は、圧縮画像単独でキャプチャ画像（画面データ）を復元することができる。これに対し、クライアント２は、差分画像を受信した場合、過去の圧縮画像の参照（合成）によってキャプ
チャ画像（画面データ）を復元する。圧縮画像は、動画圧縮におけるいわゆるＩピクチャ（Intra-Picture：「Ｉフレーム」とも呼ばれる）に相当し、差分画像は、いわゆるＰピ
クチャ（Predictive Picture：Ｐフレーム）に相当する。
【００２９】
全てのフレームデータに対し圧縮画像を適用することができる。もっとも、実施形態１では、初回に送信されるフレームデータ（キーフレーム：フレーム＃１）に圧縮画像を適用し、次回以降のフレームデータ（フレーム＃２,＃３,・・・）に対し、差分画像を適用する。
【００３０】
この場合、クライアント２では、フレーム＃２以降のフレームデータを用いた画面データの復元処理において、フレーム＃１を用いる。差分画像のデータ量（サイズ）は、圧縮画像のデータ量（サイズ）よりも小さい。このため、次回以降のフレームデータに差分画像を適用することによって、クライアント２に対する転送データ量を削減することができる。
【００３１】
もっとも、２回目以降に送信されるキーフレームに対し、圧縮画像が適用されるように変形しても良い。例えば、フレーム＃４に対して圧縮画像を適用しても良い。この場合、サーバ１では、フレーム＃５として、フレーム＃４の差分画像を生成および送信する。これによって、クライアント２は、フレーム＃５を用いた画面データの復元を、フレーム＃５とフレーム＃４とを用いて実施することができる。換言すれば、非キーフレームを用いた画面データの復元に最後に受信されたキーフレームを用いるようにすることができる。なお、２回目以降に送信されるキーフレームの少なくとも１つに圧縮画像が適用されるようにしても良い。
【００３２】
データの復元に参照される画像の生成時点からの時間経過が大きくなるほど、当該画像との差分が大きくなると考えられる。差分が大きくなることは差分画像のサイズが大きくなることを意味する。上記のような変形がなされることで、２回目以降のキーフレーム（例えばフレーム＃４）の送信後に送信される非キーフレーム（フレーム＃５）のデータ量（サイズ）が小さくなることを期待することができる。
【００３３】
初回より後のキーフレーム（例えばフレーム＃４）の送信タイミングは、以下のようにして決定することができる。図３は、キーフレームの決定方法の一例を示す図である。サーバ１は、初回のキーフレーム（フレーム＃１）のフレームデータを送信した後は、所定のフレームレートに従ったタイミングで次以降のフレームデータを送信する。フレームレート（所定間隔（所定時間）の長さ）は、適宜設定可能であり、固定でも良く、状況に応じて可変としても良い。
【００３４】
サーバ１は、キーフレームが全てのクライアント２で受信されたことを検出したときに、次のフレームデータの送信タイミングでキーフレームを送信することを決定する。２回目以降のフレームデータに差分画像が適用される場合、サーバ１は、上記した次のフレームデータの送信タイミングで送信されるフレームデータ（差分画像）をキーフレームに設定する。これに対し、全てのキーフレームに圧縮画像を適用する場合には、サーバ１は、画面データの圧縮画像を生成し、上記した次のフレームデータの送信タイミングで送信する。
【００３５】
図３に示す例では、フレーム＃３の送信タイミングの後であってフレーム＃４の送信タイミングの前の或る時点（図３の破線参照）において、全てのクライアント２（クライアント＃１および＃２）で直前のキーフレーム（フレーム＃１）が受信されたことが検出されている。この場合、次のフレームデータ（フレーム＃４）の送信タイミングで、キーフレームが送信される。
【００３６】
キーフレームの受信判断は、例えば、サーバ１が、サーバ１と各クライアント２とを結ぶネットワークの遅延を測定し、当該遅延に基づいて判定することができる。図４は、各クライアント２に対するフレームの送信制御の一例を模式的に示す図である。図４において、サーバ１は、キーフレームを受信したクライアント２（ユーザ）から、キーフレームの受信を示す応答メッセージ（以下「受信応答」という）を受信する。図４は、クライアント数が３の例を示している。サーバ１は、キーフレームの受信応答の回収処理１０１と、圧縮画像および差分画像（キーフレームおよび非キーフレーム）を生成する圧縮処理１０２とを行う。
【００３７】
回収処理１０１は、各クライアント２から受信応答を回収する。回収処理１０１は、全クライアント２からの受信応答を回収すると、全クライアント２のキーフレーム受信を示す情報（以下、「受信通知」という）を圧縮処理１０２に伝達する。圧縮処理１０２は、フレームレートに合わせたフレームデータ（図４の符号"Ｆ"参照）の生成および出力を行う。
【００３８】
例えば、圧縮処理１０２は、上記信号を受けたときは、次に出力するフレームデータにキーフレームであることを示す識別子を付与する。上記信号がないときには、次に出力するフレームデータに識別子を付与しないか、非キーフレームであることを示す識別子を付与する。もっとも、キーフレームに識別子が付与されず、非キーフレームに識別子が付与されるようにしても良い。
【００３９】
なお、受信通知は、後述する送信判定処理１０３に供給され、送信判定処理１０３にて、送信対象がキーフレームか非キーフレームかが判定されるようにしても良い。この場合、識別子の付与は必ずしも必要ではない。
【００４０】
サーバ１は、クライアント２毎の送信処理を実行する。各クライアント２に対する送信処理は、クライアント２とサーバ１との応答時間の長い順で行われる。例えば、サーバ１は、各クライアント２について、キーフレームを送信してから受信応答を受信するまでの往復遅延時間（ラウンドトリップタイム：ＲＴＴ）を応答時間として測定する。応答時間（遅延）が大きい程、通信環境が良くない（例えば、サーバ１から遠い、利用可能な帯域が小さい）ことを意味する。応答時間が長い順に送信処理を実行することで、クライアント２間でキーフレームに基づく画面の表示タイミングを近づける（揃えるようにする）ことができる。
【００４１】
各クライアント２に対する送信処理では、送信対象のフレームデータに対する送信判定処理１０３が行われる。送信判定処理１０３では、送信対象のフレームデータ（送信データ）がキーフレームであれば、クライアント２への送信が行われる。これに対し、送信対象のフレームデータが非キーフレームであるときには、例えば、当該クライアント２への通信路に空き帯域があることを条件に、クライアント２への送信が行われる。空き帯域がなければ、差分画像の送信は取り止めとなる（すなわち、非キーフレームが間引きされる）。
【００４２】
図５は、図４に示した送信判定処理１０３の一例を示すフローチャートである。図５の０１において、送信データ（送信対象のフレームデータ）がキーフレームか否かが判定される。当該判定は、例えば、送信データがキーフレームであることを示す識別子が当該送信データに含まれているか否かによって行われる。もっとも、上述したように、０１の判定は、受信通知が回収処理１０１から届いているか否かによってなされても良い。
【００４３】
送信データがキーフレームである場合（０１,Ｙｅｓ）には、クライアント２に係る空
き帯域ＢＷmaxの推定値が以下の計算式により算出される（０２）。その後、キーフレー
ムが送信される（０３）。
ＢＷmax＝Σ（これまでに送信したキーフレームのデータ量）／Σ（これまでに送信し
たキーフレームに対する応答時間）
【００４４】
空き帯域ＢＷmaxは、フレームデータの送信に利用可能な単位時間当たりのデータ量を
示す。単位時間は、例えば１秒であるが、他の時間長が用いられても良い。なお、サーバ１では、各キーフレームのデータ量（サイズ）と、往復遅延時間とが随時主記憶装置１２又は補助記憶装置１３に記録され、０３の処理において、空き帯域ＢＷmaxの算出に用い
られる。
【００４５】
０１において、送信データがキーフレームでない場合（非キーフレームである場合：０１,Ｎｏ）には、過去１秒間に送信したデータ量と今回の送信データのデータ量との加算
値が空き帯域ＢＷmax未満であるか否かが判定される（０４）。このとき、加算値が空き
帯域ＢＷmax未満であれば（０４,Ｙｅｓ）、非キーフレームが送信される（０３）。これに対し、加算値が空き帯域ＢＷmax以上であれば（０４,Ｎｏ）、非キーフレームの送信が取りやめとなる。即ち、非キーフレームの間引きが行われる。
【００４６】
以上のように、送信判定処理１０３では、送信データがキーフレームであればキーフレームの送信が行われる。よって、キーフレームは、周期的に全てのクライアント２へ送信される。これに対し、非キーフレームについては、非キーフレームの送信に利用可能な空き帯域があれば（送信データ量が空き帯域ＢＷmaxに達していなければ）、非キーフレー
ムの送信処理が行われる。
【００４７】
図４に示したように、各クライアント２（ユーザ）がキーフレームを受信する度に受信応答をサーバ１に返すことによって、リアルタイムに近い（準リアルタイムな）送信制御を行うことができる。
【００４８】
全てのクライアント２でのキーフレームの受信が検出されたときに、次に送信するフレームデータをキーフレームに設定することで、キーフレーム間の時間長を不必要に長くすることが回避され、隣接するキーフレーム間の差分を小さくすることが期待できる。換言すれば、帯域が狭いクライアント２で表示される画面の変化を小さくすることが期待できる。
【００４９】
また、上記した空き帯域ＢＷmaxの推定値を求めることで、時間の経過に伴い通信環境
が変化する場合に、非キーフレームの送信可否判定の閾値（空き帯域ＢＷmax）を通信環
境の変化に追従させることができる。もっとも、空き帯域の閾値は固定であっても良い。
【００５０】
なお、複数のクライアント２が同一の拠点に存在する。例えば、複数のクライアント２（例えば、図１に示すクライアント２Ａ,２Ｂ,２Ｃ）が同一のネットワーク（Local Area
Network：ＬＡＮ）に収容されている場合には、送信データをブロードキャストで送信しても良い。このようにすれば、転送データ量のさらなる削減を図ることができる。以下、上記したサーバ１および各クライアント２の詳細について説明する。
【００５１】
＜情報処理装置のハードウェア構成＞
図６は、図１に示したサーバ１およびクライアント２のそれぞれとして使用可能な情報処理装置（コンピュータ）のハードウェア構成例を示す。情報処理装置１０は、バスＢを介して相互に接続されたプロセッサ１１，主記憶装置１２，補助記憶装置１３，入力装置１４，出力装置１５，ネットワークインタフェース（ＮＩＦ）１６を含んでいる。
【００５２】
プロセッサ１１は、例えば、Central Processing Unit（ＣＰＵ），Digital Signal Processor（ＤＳＰ）, Graphics Processing Unit（ＧＰＵ）などから少なくとも１つ選択
される汎用プロセッサである。もっとも、プロセッサ１１として専用のプロセッサを適用することもできる。以下の説明では、プロセッサ１１がＣＰＵである例について説明する。
【００５３】
主記憶装置１２は、主記憶装置（メインメモリ）の一例であり、例えば、Read Only Memory（ＲＯＭ）及びRandom Access Memory（ＲＡＭ）を含む。主記憶装置１２は、プロセッサ１１の作業領域として使用される。
【００５４】
補助記憶装置１３は、プロセッサ１１によって実行される様々なプログラム（オペレーティングシステム（ＯＳ），アプリケーションプログラム）や、プロクラムの実行に際して使用されるデータを記憶する。補助記憶装置１３としては、例えば、ハードディスクドライブ（ＨＤＤ），Electrically Erasable Programmable Read-Only Memory（ＥＥＰＲ
ＯＭ），フラッシュメモリ，Solid State Drive（ＳＳＤ）などから選択される少なくと
も１つを用いることができる。また、補助記憶装置１３は、ディスク記憶媒体およびそのドライブ装置も含む。
【００５５】
入力装置１４は、ボタン、キー、キーボード、マウスのようなポインティングデバイス、タッチパネルの少なくとも１つを含み、情報およびデータの入力に使用される。入力装置１４は、音声入力装置（マイクロフォン）を含む。
【００５６】
出力装置１５は、ディスプレイ装置（ディスプレイ）を含む。また、出力装置１５は、音声出力装置（スピーカ）や印刷装置（プリンタ）を含むことができる。さらに、出力装置１５として、ランプやバイブレータを含むこともできる。
【００５７】
ＮＩＦ１６は、ネットワークを介して接続された通信機器との通信処理を司るインタフェース回路である。ＮＩＦ１６として、例えば、Local Area Network（ＬＡＮ）カード、或いはネットワークインタフェースカード（ＮＩＣ）を適用することができる。
【００５８】
プロセッサ１１は、補助記憶装置１３に記憶されたプログラムを主記憶装置１２にロードして実行することによって、様々な機能を発揮する。機能の発揮によって、情報処理装置１０は、サーバ１として動作したり、クライアント２として動作したりすることができる。
【００５９】
なお、プロセッサ１１によって実行される機能の一部又は全部は、ハードウェアのハードウェアロジック（ワイヤードロジック）によって実装されても良い。ハードウェアは、例えば、電気・電子回路，集積回路（例えば、Integrated Circuit（ＩＣ），Large Scale Integrated circuit（ＬＳＩ），Application Specific Integrated Circuit（ＡＳＩ
Ｃ）の少なくとも一つ）を含む。また、ハードウェアは、Field Programmable Gate Array（ＦＰＧＡ）のようなプログラマブルロジックデバイス（ＰＬＤ）を含む。この場合、
一つのハードウェアが複数の機能を実行するようにしても良く、複数のハードウェアの組み合わせで一つの機能が実行されるようにしても良い。
【００６０】
プロセッサ１１は、「プロセッサ」，「制御装置」，「コントローラ」の一例である。また、主記憶装置１２、補助記憶装置１３のそれぞれは、「記憶装置」，「メモリ」，「コンピュータ読み取り可能な記録媒体」の一例である。
【００６１】
＜サーバの構成＞
図７は、サーバ１の構成例を模式的に示す図である。図７において、サーバ１として動
作する情報処理装置１０（図６）は、プロセッサ１１がプログラムを実行することによって、図７に示すブロックを含んだ装置として動作する。図７において、サーバ１は、入力装置１４と接続された入力処理部１１１と、入力処理部１１１と接続されたアプリケーション実行部１１２と、アプリケーション実行部１１２および出力装置１５（ディスプレイ）と接続された画面表示制御部１１３とを含んでいる。
【００６２】
また、サーバ１は、画面表示制御部１１３と接続された画像取得部１１４と、画像取得部１１４と接続された画像処理部１１５と、画像処理部１１５と接続された送信判定部１１６とを含んでいる。さらに、サーバ１は、送信判定部１１６およびネットワークと接続された送信部１１７と、ネットワークと接続された受信部１１８と、受信部１１８と接続されたネットワーク状態の計測部１１９と、応答時間リスト１２０とを含んでいる。
【００６３】
入力処理部１１１,アプリケーション実行部１１２,画面表示制御部１１３,画像取得部
１１４,画像処理部１１５,送信判定部および計測部１１９は、図６に示した情報処理装置１０のプロセッサ１１（例えばＣＰＵ）がプログラムを実行することによって得られるプロセッサ１１の機能である。送信部１１７および受信部１１８は、ＮＩＦ１６の機能である。応答時間リスト１２０は、主記憶装置１２又は補助記憶装置１３上に作成される。
【００６４】
入力処理部１１１は、入力装置１４や受信部１１８から入力される情報やデータの処理を行う。アプリケーション実行部１１２は、アプリケーションプログラム（画像編集用のプログラムなど）を実行し、入力された情報に基づく処理を行う。例えば、入力処理部１１１は、受信部１１８で受信されるクライアント２からの画面の操作情報を得て、操作情報をアプリケーション実行部１１２に渡す。
【００６５】
アプリケーション実行部１１２は、操作情報を用いて、例えば、出力装置１５に表示される画面の描画用パラメータを変更する。画面表示制御部１１３は、ＶＲＡＭ（ビデオＲＡＭ）に、出力装置１５（ディスプレイ）に表示する画面データを描画し、画面データの映像信号を出力装置１５に送る。ＶＲＡＭは、主記憶装置１２に含まれている。出力装置１５（ディスプレイ）は、画面データに基づく画面を表示する。
【００６６】
画像取得部１１４は、例えば、フレームレートに合わせたタイミングで、画面表示制御部１１３によって描画された画面データを取得（キャプチャ）する。画像処理部１１５は、圧縮処理１０２（図４）を行い、画面データからフレームデータ（圧縮画像および差分画像）を生成して出力する。また、画像処理部１１５は、受信通知の受領時には、次に出力するフレームデータにキーフレームであることを示す識別子を付与する。
【００６７】
送信判定部１１６は、送信判定処理１０３（図４，図５）を実行する。送信判定処理１０３に用いる各クライアント２の空き帯域ＢＷmaxの算出用データは、主記憶装置１２又
は補助記憶装置１３に記憶されている。送信部１１７は、送信対象のキーフレーム,差分
画像を受け取り、宛先へ向けて送信する。受信部１１８は、クライアント２からの操作情報を受信して入力処理部１１１へ送ったり、受信応答を受信して計測部１１９に送ったりする。
【００６８】
計測部１１９は、各クライアント２の応答時間（ＲＴＴ）を計測する。例えば、計測部１１９は、各クライアント２について、キーフレームの送信時刻を送信部１１７から受け取る。一方、計測部１１９は、受信部１１８で受信されるキーフレームの受信応答の回収処理１０１を行い、受信応答の受信時刻を得る。計測部１１９は、送信時刻と受信時刻との差分から応答時間（ＲＴＴ）を得る。各クライアント２の応答時間は、応答時間リスト１２０に記憶される。送信判定部１１６は、応答時間リスト１２０を参照し、送信判定処理を行う順序を決定する。
【００６９】
また、計測部１１９は、全てのクライアント２からの受信応答が得られたときに、受信通知を画像処理部１１５に与える。このとき、画像処理部１１５は、フレームデータに識別子を設定する。これによって、送信判定部１１６は、送信判定処理１０３において、送信対象がキーフレームか非キーフレームか否かを判定することができる。
【００７０】
＜クライアント２の構成＞
図８は、クライアント２の構成例を模式的に示す図である。クライアント２として動作する情報処理装置１０は、プロセッサ１１がプログラムを実行することによって、図８に示すブロックを含んだ装置として動作する。
【００７１】
図８において、クライアント２は、受信部２０１と、画像（画面データ）の復元部２０２と、画面表示制御部２０３と、出力装置１５（ディスプレイ）と、受信応答部２０４と、入力処理部２０５と、送信部２０６とを含む装置として動作する。
【００７２】
復元部２０２,画面表示制御部２０３,受信応答部２０４および入力処理部２０５は、例えば、プロセッサ１１がプログラムを実行することによって得られるプロセッサ１１の機能である。受信部２０１および送信部２０６は、ＮＩＦ１６が有する機能である。
【００７３】
受信部２０１は、サーバ１から送信されたフレームデータ（キーフレーム，非キーフレーム）を受信する。復元部２０２は、受信部２０１で受信されたフレームデータ（圧縮画像，或いは圧縮画像および差分画像）を用いた復元処理によって画面データを得る。画面表示制御部２０３は、復元された画面データに基づく描画をＶＲＡＭに対して行い、描画された画面の映像信号が出力装置（ディスプレイ）１５に出力される。これによって、出力装置１５（ディスプレイ）には、サーバ１で生成された画面が表示される。
【００７４】
受信応答部２０４は、受信部２０１でキーフレームが受信されたときに、キーフレームの受信応答のメッセージを生成し、送信部２０６に与える。送信部は、受信応答をサーバ１へ送信する。なお、キーフレームには、サーバ１のアドレスが送信元アドレスとして付与されており、受信応答の宛先アドレスには、サーバ１のアドレスが設定される。
【００７５】
入力処理部２０５は、出力装置（ディスプレイ）１５に表示された画面に対し、入力装置１４から入力された操作の内容を示す操作情報を生成し、送信部２０６へ送る。送信部２０６は、サーバ１へ操作情報を送信する。
【００７６】
＜サーバ１の処理例＞
図９は、サーバ１の処理例を示すフローチャートである。図９に示す処理は、サーバ１として動作する情報処理装置１０のプロセッサ１１（ＣＰＵ）によって実行される。図９の例では、初回のフレームデータに圧縮画像を適用し、次以降のフレームデータに差分画像を用いる。また、図９の例では、受信通知の有無によって、送信対象がキーフレームか否かが判定される。さらに、図９の例では、受信応答の回収処理１０１は、別途プロセッサ１１によって実行され、受信通知が送信判定処理１０３に供給される。
【００７７】
最初の１０１では、サーバ１が各クライアント２と接続される。すると、プロセッサ１１は、計測部１１９として動作し、各クライアント２の応答時間リスト１２０を作成する（１０２）。サーバ１において、各クライアント２のアドレスは既知であり（例えば、補助記憶装置１３にて記憶）、プロセッサ１１は、例えば、ｐｉｎｇコマンドを用いて、各クライアントの応答時間（ＲＴＴ）を測定する。
【００７８】
図１０は、応答時間リスト１２０のデータ構造例を示す。応答時間リスト１２０は、例
えば、クライアント２（ユーザ）の識別子と、応答時間（ＲＴＴ）とを含むエントリの集合で形成される。クライアント２の識別子は、クライアントを一意に識別可能な情報であれば良く、クライアントＩＤでもユーザ名でも、クライアント２のアドレスであっても良い。なお、図１０に示した各クライアント２Ａ〜２Ｅの応答時間は一例である。図１０に示すように、エントリは、応答時間の長い順でソートされており、エントリ順が送信判定処理の実行順序を示す。
【００７９】
図９に戻って、次の１０３では、プロセッサ１１は、画像取得部１１４として動作し、一定時間毎にサーバ画面（画面データ）をキャプチャする。続いて、プロセッサ１１は、画像処理部１１５として動作し、圧縮処理１０２（図４）の実行によって、圧縮画像および差分画像を生成する（１０４）。初回の１０４の処理では、圧縮画像が生成され、２回目以降の１０４の処理では、差分画像が生成される。なお、初回か否かは、例えば、フレームデータの送信回数をカウントするカウンタの管理によって行うことができる。但し、このような手法に限定されない。
【００８０】
次の１０５では、プロセッサ１１は、今回が初回のフレームデータ送信か否かを判定する。初回の送信であれば（１０５，Ｙｅｓ）、処理が１０７に進み、初回の送信でなければ（１０５，Ｎｏ）、処理が１０６に進む。
【００８１】
１０６では、プロセッサ１１は、送信判定部１１６として動作し、受信通知を受領しているか否かを判定する。受信通知が受領されていれば（１０６，Ｙｅｓ）、処理が１０７に進み、受信通知が受領されていなければ（１０６，Ｎｏ）、処理が１０８に進む。
【００８２】
１０７では、プロセッサ１１は、フレームデータをキーフレームに設定する。例えば、フレームデータに対し、キーフレームであることを示す識別子を付与する。次の１０８では、プロセッサ１１は、応答時間リスト１２０（図１０）から、応答時間の長い順で、一つのクライアントを選択する。
【００８３】
次の１０９では、プロセッサ１１は、送信判定部１１６として動作し、送信判定処理を実行する。送信判定処理の詳細は、図５を用いて説明した送信判定処理１０３と同じであるため、説明を省略する。送信判定処理の結果、送信を行う場合には、フレームデータの送信が行われ（１１０）、送信部１１７（ＮＩＦ１６）からフレームデータが送信される。その後、処理が１１１に進む。これに対し、送信判定処理の結果、送信が取り止め（間引き）となる場合には、処理が１１１に進む。
【００８４】
１１１では、プロセッサ１１は、残りのクライアント２があるか否かを判定する。残りのクライアント２がある場合には（１１１，Ｙｅｓ）、処理が１０８に戻り、次のクライアント２が選択される。これに対し、残りのクライアント２がない、すなわち全てのクライアント２に対する送信判定処理（１０９）が実行済みであるときには（１１１，Ｎｏ）、処理が１０３に戻る。
【００８５】
＜クライアントの処理例＞
図１１は、クライアント２の処理例を示すフローチャートである。図１１に示す処理は、クライアント２として動作する情報処理装置１０のプロセッサ１１（ＣＰＵ）によって実行される。
【００８６】
最初の１２１において、クライアント２がサーバ１と接続されると、プロセッサ１１は、サーバ１からのフレームデータの受信を待機する（１２２）。受信部２０１（ＮＩＦ１６）でフレームデータが受信されると、プロセッサ１１は、復元部２０２として動作し、既に説明した手法を用いてフレームデータの復号を行う（１２３）。続いて、プロセッサ
１１は、画面表示制御部２０３として動作し、復号により得られた画面データに基づく画面を出力装置１５（ディスプレイ）に表示させる（１２４）。
【００８７】
１２５では、プロセッサ１１は、受信応答部２０４として動作し、受信データ、すなわち受信されたフレームデータがキーフレームか否かを判定する。当該判定は、例えば、フレームデータにキーフレームであることを示す識別子が付与されているか否かによって行うことができる。
【００８８】
フレームデータがキーフレームでなければ（１２５，Ｎｏ）、処理が１２２に戻り、次のフレームデータの受信待ち状態となる。これに対し、フレームデータがキーフレームであれば（１２５，Ｙｅｓ）、プロセッサ１１は、キーフレームの受信応答のメッセージを生成し、サーバ１へ送信する（１２６）。受信応答は、送信部２０６（ＮＩＦ１６）からサーバ１へ送信される。その後、処理が１２２へ戻る。
【００８９】
＜実施形態１の効果＞
実施形態１によれば、サーバ１のプロセッサ１１が、複数のクライアント２の全てに対してキーフレームを送信し、キーフレームの送信間において、クライアント２とサーバ１との間の通信環境が所定条件を満たす（空き帯域がある）クライアント２については非キーフレームを送信し、所定条件を満たさない（空き帯域がない）クライアント２については非キーフレームの送信を取り止める。
【００９０】
このように、１つのフレームデータの送信制御を行うことで、全てのクライアント２について、その通信環境に応じたフレームレートでフレームデータを送信することができる。これによって、サーバ１の処理負荷を軽減することができる。
【００９１】
また、サーバ１のプロセッサ１１は、各クライアント２について、送信対象のフレームデータがキーフレームであればキーフレームの送信を行い、送信対象のフレームデータが非キーフレームであれば、所定条件が満たされるか否かによって非キーフレームの送信又は送信の取り止めを行う送信判定処理を、往復遅延時間（応答時間）の長い順で実行する。これによって、クライアント２間でキーフレームに基づく画面（画像）が表示されるタイミングを近づけることができる。
【００９２】
また、サーバ１のプロセッサ１１は、クライアント２とサーバ１との間に非キーフレームを送信するための空き帯域があるか否かによって非キーフレームの送信を行うか否かを判定する。これによって、空き帯域がないときには非キーフレームの送信が取り止められることで、非キーフレームがネットワークで遅延し、クライアント２間でのキーフレームに基づく画面（画像）の表示タイミングのズレが大きくなるのを回避することができる。
【００９３】
また、サーバ１のプロセッサ１１は、これまでに送信したキーフレームの累積データ量をこれまでに送信したキーフレームに係るＲＴＴで除した値を空き帯域の推定値（ＢＷmax）として求める。そして、プロセッサ１１は、現在から単位時間（１秒）遡った期間に
おけるフレームデータのデータ量に送信対象の非キーフレームのデータ量を加算した値が推定値を下回るときに非キーフレームを送信し、そうでなければ送信を取り止める。これによって、実際の通信環境の変化に則して、非キーフレームを送信するか否かを決定することができる。
【００９４】
また、サーバ１のプロセッサ１１は、非キーフレームとして、最後に送信されたキーフレームデータとの差分を示すデータ（差分画像）を送信することができる。これによって、フレームデータのサイズを小さくすることができる。すなわち、転送データ量を削減することができ、ネットワーク３やネットワーク４への負荷を軽減できる。
【００９５】
また、サーバ１のプロセッサ１１は、２回目以降に送信されるキーフレームとして、初回で送信されたキーフレームとの差分を示すデータを送信することができる。このように、キーフレームとして差分を示すデータを送信することで、さらに転送データ量を削減することができる。
【００９６】
また、サーバ１のプロセッサ１１は、各クライアント２からの応答に基づいて最後に送信したキーフレームが複数のクライアント２の全てで受信されたことを検出したときに、次のフレームデータの送信タイミングにおいてキーフレームを送信することを決定する。これによって、キーフレームの送信間隔が不必要に長くなるのを回避することができる。
【００９７】
＜変形例＞
なお、実施形態１で示したように、２回目以降のフレームデータに差分画像を適用する場合には、サーバ１およびクライアント２で以下のような処理を行うことが好ましい。例えば、図３に示す例を元に説明すると、サーバ１は、フレーム＃４の生成にあたり、フレーム＃１生成時点の画面データ（「画面データ＃１」とする）と、フレーム＃４生成時点の画面データ（「画面データ＃２」とする）の差分データを抽出する。サーバ１は、画面データ＃２を、次のキーフレームを送信するまでに送信される非キーフレームの差分画像を作成するための参照用画像として主記憶装置１２又は補助記憶装置１３に記憶する。
【００９８】
フレーム＃５の生成に当たり、サーバ１は、フレーム＃５生成用の画面データ（「画面データ＃３」とする）をキャプチャし、保存しておいた画面データ＃２との差分データを圧縮して差分画像（フレーム＃５）を生成し、送信する。
【００９９】
一方、フレーム＃４を受信したクライアント２では、以下のような処理を行う。すなわち、クライアント２は、フレーム＃１とフレーム＃４とを用いて、画面データを復元する。復元された画面データは、フレーム＃５の復元用データとして、主記憶装置１２又は補助記憶装置１３に記憶される。その後、フレーム＃５が受信された場合には、フレーム＃５の伸張処理により差分データを得て、保存しておいた復元データとの合成により、画面データ＃３相当の画面データを取得する。この画面データに基づく画面が出力装置１５で表示される。
【０１００】
このように、サーバ１では、２回目以降のキーフレームの送信時には、差分画像作成のために使用される画面データが更新される。一方、クライアント２では、復元用データが保存され、復元用データと非キーフレームから得られた差分データとの合成により表示対象の画像データが生成される。このようにすれば、最初のキーフレーム（フレーム＃１）からの差分が時間経過に伴って大きくなり、差分画像のデータ量（サイズ）が大きくなるのを抑えることができる。
【０１０１】
〔実施形態２〕
次に、実施形態２について説明する。実施形態２は、実施形態１と共通点を有するので、共通点については説明を省略し、主として相違点について説明する。
【０１０２】
実施形態１では、全てのクライアント２からの受信応答がサーバ１で得られたことを契機として、次のフレームデータがキーフレームに設定される。しかしながら、遠隔に存在する（応答時間が長い）クライアント２が１つでも存在する場合では、そのようなクライアントの存在によって、キーフレームの送信間隔（インターバルの長さ）が長時間化する。この場合、キーフレームの送信時刻から時間が経過する程、キーフレームからの差分が大きくなり、非キーフレームとして送信される差分画像の圧縮率が低下することが考えられる。圧縮率の低下は転送データ量の増加を意味する。実施形態２は、この様な問題を回
避するための構成について説明する。
【０１０３】
図１２Ａおよび図１２Ｂは、実施形態２の説明図である。図１２Ａおよび図１２Ｂでは、時間軸上に配置された複数の矩形のブロックが図示されている。各ブロックは、フレーム送信のためにサーバ１でキャプチャされる画面データを示す。ブロック上の矢印は、差分データ抽出のために参照される画面データを示す。参照される画面データは、キーフレームの送信を契機に更新される。
【０１０４】
図１２Ａに示す例では、フレーム＃５が次のキーフレームとなっており、フレーム＃６，フレーム＃７は、フレーム＃５の画面データからの差分データの圧縮により得られる。これは、実施形態１の変形例で示した手法と同じである。ここで、時間経過につれて、フレーム＃１（キーフレーム）との差分が大きくなるものと仮定する。
【０１０５】
この場合、フレーム＃６，フレーム＃７として、フレーム＃５の画面データの参照によって生成された差分画像が送信されることで、フレーム＃６，フレーム７のデータ量が削減される。しかし、フレーム＃１とフレーム＃４との差分が大きく、フレーム＃４のデータサイズが大きくなっている。一方、複数のクライアント２の一部からのキーフレームの受信応答は、フレーム＃３の送信前にサーバ１で受信されているものとする。
【０１０６】
そこで、実施形態２では、複数のクライアント２を、受信応答の受信タイミングに従ってクラスタリングする。例えば、複数のクライアント２が「遠隔者」と「近隣者」との二つのクラスタにクラスタリングされる。「近隣者」は、フレーム＃３の送信タイミングの前にサーバ１が受信応答を受信したクライアント２であり、「遠隔者」は、「近隣者」以外のクライアント２である。
【０１０７】
図１２Ｂに示すように、サーバ１は、近隣者向けに、フレーム＃３をサブキーフレームとして設定する。サブキーフレームは、クライアント全体でなく、所定クラスタに属するクライアント２に対して有効なキーフレームである。サブキーフレームの送信を契機として、参照用の画面データは更新される。
【０１０８】
図１２の例では、フレーム＃３の画面データが参照用の画面データに設定され、「近隣者」に対するフレーム＃４は、フレーム＃３の画面データからの差分データを圧縮した差分画像となる。これによって、「近隣者」に対するフレーム＃４のデータ量を削減することができる。また、「近隣者」に対するフレーム＃５（キーフレーム）も、フレーム＃３の画面データからの差分で生成されるため、データ量が削減される。一方、「遠隔者」に対しては、図１２Ａに示したような状態が維持される。
【０１０９】
上記したクラスタリングおよびサブキーフレームの設定は、プロセッサ１１によって実行される。図１３は、実施形態２におけるサーバ１の処理例を示すフローチャートである。図１３に示すサーバ１の処理は、図９に示したサーバ１の処理と、以下の点で異なっている。第１に、１０２の処理の代わりに１０２Ａの処理が設けられている。第２に、１０６の処理と１０８の処理の間に１１２の処理が挿入されている。
【０１１０】
１０２Ａでは、プロセッサ１１は、応答時間リスト１２０を作成するとともに、応答時間に基づいてクライアントをクラスタリングする。図１４は、実施形態２における応答時間リスト１２０の例を示す。
【０１１１】
図１４に示す応答時間リストは、図１０に示した応答時間リストの内容に加えて、クライアント２が所属するクラスタを示す情報が含まれている。図１４に示す例では、クラスタリングは、一例として、全クライアント２中で最も長い応答時間を基準にして、３つの
クラスタ（クラスタ＃１，クラスタ＃２，クラスタ＃３）に分割されている。
【０１１２】
クラスタ＃１は、最長応答時間の１／２〜１の範囲に応答時間が入るクライアント２が属するクラスタである。クラスタ＃２は、最長応答時間の１／４〜１／２の範囲に応答時間が入るクライアント２が属するクラスタである。クラスタ＃３は、最長応答時間の１／８〜１／４の範囲に応答時間が入るクライアント２が属するクラスタである。
【０１１３】
図１３の１１２の処理では、プロセッサ１１は、全てのクライアント２からキーフレームの受信応答又はサブキーフレームの受信応答が受信されているクラスタがあれば、当該クラスタに属するクライアント２向けのフレームデータをサブキーフレームに設定する。
【０１１４】
例えば、プロセッサ１１は、各クライアント２からのキーフレームの受信応答およびサブキーフレームの受信応答の受信状況を主記憶装置１２又は補助記憶装置１３に記録する。プロセッサ１１は、当該状況と応答時間リスト（図１４）とを参照して、該当のクラスタがあるか否かを判定する。このとき、該当の複数のクラスタが存在する場合には、夫々のクラスタに属するクライアント２向けのフレームデータがサブキーフレームに設定される。送信処理は、応答時間の長いクラスタ順で実行される。
【０１１５】
図１３における１０２Ａおよび１１２以外の処理については実施形態１（図９）と同じであるので、説明を省略する。
【０１１６】
図１５は、実施形態２におけるクライアント２の処理例を示すフローチャートである。図１５に示す処理は、１２７および１２８の処理が追加されている点で、実施形態１における処理（図１１）と異なっている。
【０１１７】
すなわち、図１５の１２５の処理で、受信データがキーフレームでないと判定された場合には（１２５，Ｎｏ）、受信データがサブキーフレームか否かが判定される（１２７）。このとき、受信データがサブキーフレームでなければ（１２７，Ｎｏ）、処理が１２２に戻る。これに対し、受信データがサブキーフレームであれば（１２７，Ｙｅｓ）、処理が１２８に進み、サブキーフレームの受信応答のメッセージが生成され、サブキーフレームの受信応答がサーバ１へ送信される。
【０１１８】
以上を除き、図１５に示す処理は、図１１と同じであるので、説明を省略する。また、上記を除き、実施形態２の構成および動作は実施形態１とほぼ同様であるので、説明を省略する。
【０１１９】
実施形態２では、サーバ１のプロセッサ１１は、複数のクライアント２に係る往復遅延時間（ＲＴＴ）に応じて複数のクライアント２を複数のクラスタにクラスタリングする。そして、プロセッサ１１は、複数のクライアント２の全てからキーフレームの受信を示す応答が受信される前に、或るクラスタに属するクライアント２の全てから応答が受信されている場合には、或るクラスタに属するクライアントの全てを送信対象とするサブキーフレームの送信を決定する。
【０１２０】
これによって、ＲＴＴが比較的短いクライアント２に対するフレームデータの圧縮率が低下するのを回避することが可能となる。換言すれば、クライアント２のクラスタリングおよびサブキーフレームの設定によって、一部のクライアント２へ向けて送信されるフレームデータの圧縮率を上げることができる。
【０１２１】
〔実施形態３〕
次に、実施形態３について説明する。実施形態３は、実施形態１と共通点を有するので
、共通点については説明を省略し、主として相違点について説明する。実施形態１，実施形態２では、応答時間の長い順で、クライアント２に対する送信処理が実施されていた。
【０１２２】
実施形態１において説明したように、各クライアント２からの操作情報は、サーバ１へ送られ、サーバ１で操作情報を反映した画面データの更新が行われ、各クライアント２に送信される。このとき、操作情報を送信したクライアント２において、操作に伴う画面の更新に時間がかかると、オペレータに対して良好な操作感を与えることができない。そこで、実施形態３では、サーバ１が操作情報を受信した場合には、操作情報の送信元のクライアント２に対する送信処理の優先順位を上げる。
【０１２３】
図１６は、実施形態３におけるサーバ１の構成例を模式的に示す図である。図１６に示すサーバ１は、実施形態１の構成（図７）に加えて、操作ユーザ判定部１２１をさらに備えている。
【０１２４】
操作ユーザ判定部１２１は、受信部１１８で操作情報が受信されたときに、操作情報の送信元のクライアント２の識別子を受信部１１８から得る。操作ユーザ判定部１２１は、て、送信元のクライアント２のエントリが先頭になるように、応答時間リスト１２０のエントリ登録順を変更する。
【０１２５】
図１７は、実施形態３におけるサーバ１の処理例を示すフローチャートである。図１７に示す処理は、実施形態１における処理（図９）と以下の点で異なっている。第１に、１０３の処理と１０４の処理との間に、１３１の処理が挿入されている。第２に、１０８の処理の代わりに、１０８Ａの処理が設けられている。
【０１２６】
１３１では、プロセッサ１１は、操作ユーザ（操作情報の送信元のクライアント２）の送信判定処理の優先度が上がるように、応答時間リスト１２０のエントリ登録順を修正する。実施形態３の例では、操作ユーザの優先度が最大となるように修正される。但し、優先度が最大に設定されることは必須ではない。
【０１２７】
１０８Ａでは、プロセッサ１１は、応答時間リストから優先度が最大（優先順位が最上位）のクライアント２を送信判定処理１０３（１０９の処理）の対象として選択する。もっとも、プロセッサ１１の処理としては、応答時間リスト１２０の先頭エントリに登録されたクライアント２を最初の送信判定処理の対象として選択するので、１０８の処理と１０８Ａの処理は実質的に変わらない。
【０１２８】
図１８Ａおよび図１８Ｂは、１３１の処理によって修正された応答時間リスト１２０の登録内容例を示す。応答時間リスト１２０の登録内容は、操作情報がない場合（初期状態）では、図１４に示したように、応答時間の長い順で、クライアント２Ａ〜２Ｅのエントリが登録されている。これに対し、例えば、クライアント２Ｅからの操作情報が受信された場合には、図１８Ａに示すように、クライアント２Ｅのエントリの登録位置が先頭に変更される。上述したように、送信判定処理は、応答時間リスト１２０のエントリ登録順でなされるため、クライアント２Ｅについての送信判定処理が最初になされるようになる。
【０１２９】
図１８Ｂは、クライアント２Ｅについての送信判定処理が開始された後に、クライアント２Ｃからの操作情報が受信された場合を示す。この場合、クライアント２Ｃのエントリが先頭に移動する。クライアント２Ｅのエントリは、応答時間の長さに従って最下位に戻される。これによって、クライアント２Ｃについての送信判定処理が優先的に実行される。なお、クライアント２Ｃについての送信判定処理が開始されると、クライアント２Ｃのエントリは、元の位置に戻る。即ち、登録内容が図１４の状態に戻る。
【０１３０】
図１７の１３１および１０８Ａ以外の処理は、図９の処理と同じであるので、説明を省略する。また、実施形態３の他の構成は、実施形態１と同じであるので、説明を省略する。
【０１３１】
実施形態３では、サーバ１のプロセッサ１１は、画面に対する操作情報が受信されたときに当該操作情報の送信元のクライアント２に対する送信判定処理の優先順位を上げる。これによって、当該クライアント２へ操作情報が反映されたフレームデータが送信されるタイミングを早めることができる。これによって、操作情報の送信元のクライアント２のオペレータが受ける操作感を向上させることができる。
【０１３２】
なお、実施形態３の構成を実施形態２に組み合わせることができる。その他、実施形態１，実施形態２，および実施形態３で示した構成は、適宜組み合わせることが可能である。
【０１３３】
上記した実施形態は、以下の付記を開示する。
（付記１）  サーバが画像のフレームデータを複数のクライアントにネットワークを介して配信する方法であって、前記サーバが備えるプロセッサが、前記フレームデータとして、第１のフレームデータと、第２のフレームデータとを生成し、前記複数のクライアントの全てに対し、前記第１のフレームデータを送信し、前記第１のフレームデータの送信間において、クライアントと前記サーバとの間の通信環境が所定条件を満たすクライアントについて前記第２のフレームデータを送信することを含むサーバの画像配信方法。
【０１３４】
（付記２）  前記プロセッサは、各クライアントについて、送信対象のフレームデータが前記第１のフレームデータであれば当該第１のフレームデータの送信を行い、送信対象のフレームデータが前記第２のフレームデータであれば前記所定条件が満たされるか否かによって当該第２のフレームデータの送信又は送信の取り止めを行う送信判定処理を、往復遅延時間の長い順で実行する付記１に記載のサーバの画像配信方法。
【０１３５】
（付記３）  前記プロセッサは、各クライアントについて、クライアントと前記サーバとの間に前記第２のフレームデータを送信するための空き帯域が前記ネットワークにあるか否かによって前記所定条件が満たされるか否かを判定する付記１又は２に記載のサーバの画像配信方法。
【０１３６】
（付記４）  前記プロセッサは、これまでに送信した前記第１のフレームデータの累積データ量をこれまでに送信した前記第１のフレームデータに係る往復遅延時間で除した値を空き帯域の推定値として求め、現在から単位時間遡った期間におけるフレームデータのデータ量に送信対象の第２のフレームデータのデータ量を加算した値が前記推定値を下回るときに当該第２のフレームデータを送信し、そうでなければ当該第２のフレームデータの送信を取り止める付記３に記載のサーバの画像配信方法。
【０１３７】
（付記５）  前記プロセッサは、前記第２のフレームデータとして、最後に送信された前記第１のフレームデータとの差分を示すデータを送信する付記１から４のいずれか１項に記載のサーバの画像配信方法。
【０１３８】
（付記６）  前記プロセッサは、２回目以降に送信される前記第１のフレームデータとして、初回で送信された前記第１のフレームデータとの差分を示すデータを送信する付記１から５のいずれか１項に記載のサーバの画像配信方法。
【０１３９】
（付記７）  前記プロセッサは、各クライアントからの応答に基づいて最後に送信した第１のフレームデータが前記複数のクライアントの全てで受信されたことを検出したときに
、次のフレームデータの送信タイミングにおいて第１のフレームデータを送信することを決定する付記１から６のいずれか１項に記載のサーバの画像配信方法。
【０１４０】
（付記８）  前記プロセッサは、前記複数のクライアントに係る往復遅延時間に応じて前記複数のクライアントを複数のクラスタにクラスタリングし、前記複数のクライアントの全てから前記第１のフレームデータの受信を示す応答が受信される前に、或るクラスタに属するクライアントの全てから前記応答が受信されている場合には、前記或るクラスタに属するクライアントの全てを送信対象とする第３のフレームデータの送信を決定する付記１から７のいずれか１項に記載のサーバの画像配信方法。
【０１４１】
（付記９）  前記プロセッサは、前記画像に対する操作情報が受信されたときに当該操作情報の送信元のクライアントに対する前記送信判定処理の優先順位を上げる付記２から８のいずれか１項に記載のサーバの画像配信方法。
【０１４２】
（付記１０）  画像のフレームデータを複数のクライアントにネットワークを介して配信するサーバとして動作するコンピュータに、前記フレームデータとして、第１のフレームデータと、第２のフレームデータとを生成するステップと、前記複数のクライアントの全てに対し、前記第１のフレームデータを送信するステップと、前記第１のフレームデータの送信間において、クライアントと前記サーバとの間の通信環境が所定条件を満たすクライアントについて前記第２のフレームデータを送信するステップとを実行させるプログラム。
【０１４３】
（付記１１）  画像のフレームデータを複数のクライアントにネットワークを介して配信するサーバであって、前記フレームデータとして、第１のフレームデータと、第２のフレームデータとを生成する処理と、前記複数のクライアントの全てに対し、前記第１のフレームデータを送信する処理と、前記第１のフレームデータの送信間において、クライアントと前記サーバとの間の通信環境が所定条件を満たすクライアントについて前記第２のフレームデータを送信する処理と、を実行する制御装置を含むサーバ。
【符号の説明】
【０１４４】
１・・・サーバ
２・・・クライアント
１０・・・情報処理装置
１１・・・プロセッサ
１２・・・主記憶装置
１３・・・補助記憶装置
１６・・・ネットワークインタフェース
【国際調査報告】
2016088244.tif 000023
2016088244.tif 000024
2016088244.tif 000025
2016088244.tif 000026