JP2015220741A - 配信制御システム、配信制御方法、及びプログラム - Google Patents

Abstract

【課題】通信ネットワークに負荷をかけることなく、映像データのフレームデータを送信する。
【解決手段】実施形態の配信制御システムは、フレームデータを生成する生成部と、フレームデータが所定の範囲以上更新されている場合、フレームデータを、第１の変換フレームデータ、又は第２の変換フレームデータに変換し、フレームデータが所定の範囲以上更新されていない場合、フレームデータを、第３の変換フレームデータ、又は第４の変換フレームデータに変換する変換部と、フレームデータが所定の範囲以上更新されている場合、第１の変換フレームデータ又は第２の変換フレームデータを送信し、フレームデータが所定の範囲以上更新されていない場合、第３の変換フレームデータを分割数Ｎに応じてＮ個に分割して送信した後、フレームデータが所定の範囲以上更新されるまで第４の変換フレームデータを定期的に送信する送信部と、を備える。
【選択図】図９

Description

本発明は、配信制御システム、配信制御方法、及びプログラムに関する。

近年、インターネットの普及に伴い、様々な分野でクラウドコンピューティングが利用されてきている。クラウドコンピューティングは、ユーザが、インターネットに接続した通信端末を用いてインターネット上のサーバ（システム）が提供するサービス（クラウドサービス）を利用し、その対価を支払うサービス利用形態である。

また、サーバが映像データを配信するサービスを提供する場合、ビデオ圧縮技術により、不要なデータを減らしたり取り除いたりしている。このビデオ圧縮技術では、MPEG-4やH.264はフレームデータ間符号化（エンコード化）を使用し、フレームデータ間の変化を予測して映像データの量を減少させている。この方法には、あるフレームデータを参照先のフレームデータと比較して変化しているピクセルだけをエンコードする差分コーディングの技術が含まれている。この差分コーディングを利用することで、エンコードして送信するピクセル数が減少する。このようにしてエンコードされた映像データを表示すると、差分コーディングにより生成される各差分データがオリジナルの映像データに含まれているかのように見せることができる。フレームデータ間の変化の予測では、映像データ内の各フレームデータをＩフレームデータ及びＰフレームデータのようなフレームタイプに分類される。

しかしながら、複数のフレームタイプのフレームデータのうち、高画質なフレームデータを送信するときに、ネットワークに負荷がかかるという問題があった。

本発明は、上記に鑑みてなされたものであって、通信ネットワークに負荷をかけることなく、映像データのフレームデータを送信することができる配信制御システム、配信制御方法、及びプログラムを提供することを目的とする。

上述した課題を解決し、目的を達成するために、本発明は、コンテンツデータからフレームデータを生成する生成部と、前記フレームデータが所定の範囲以上更新されている場合、前記フレームデータを、単独で再生可能な第１の変換フレームデータ、又は前回変換された変換フレームデータとの差分を示す第２の変換フレームデータに変換し、前記フレームデータが所定の範囲以上更新されていない場合、前記フレームデータを、前記第１の変換フレームデータよりも高画質な第３の変換フレームデータ、又は前回変換された変換フレームデータから更新されていないことを示す第４の変換フレームデータに変換する変換部と、前記フレームデータが所定の範囲以上更新されている場合、前記第１の変換フレームデータ又は前記第２の変換フレームデータを送信し、前記フレームデータが所定の範囲以上更新されていない場合、前記第３の変換フレームデータを分割数Ｎ（Ｎは２以上の整数）に応じてＮ個に分割して送信した後、前記フレームデータが所定の範囲以上更新されるまで前記第４の変換フレームデータを定期的に送信する送信部と、を備える。

本発明によれば、通信ネットワークに負荷をかけることなく、映像データのフレームデータを送信することができるという効果を奏する。

図１は、本実施形態に係る配信システムの概略図である。 図２は、通信端末にドングルを取り付ける際のイメージ図である。 図３は、基本的な配信方法を示した概念図である。 図４は、マルチキャストの概念図である。 図５は、マルチディスプレイの概念図である。 図６は、配信制御システムを介して複数の通信端末を使った複合配信の概念図である。 図７は、配信制御システム、通信端末、端末管理システム、及びウェブサーバの論理的なハードウェア構成図である。 図８は、ドングルの論理的なハードウェア構成図である。 図９は、主に配信制御システムの各機能を示す機能ブロック図である。 図１０は、主に通信端末の各機能を示す機能ブロック図である。 図１１は、端末管理システムの各機能を示す機能ブロック図である。 図１２は、配信先選択メニュー画面の概念図である。 図１３は、端末管理テーブルの概念図である。 図１４は、利用可能端末管理テーブルの概念図である。 図１５は、エンコーダブリッジ部の詳細図である。 図１６は、変換部の各機能を示す機能ブロック図である。 図１７は、配信制御システムの基本的な配信処理を示したシーケンス図である。 図１８は、配信制御システムを介して複数の通信端末を使った通信の処理を示すシーケンス図である。 図１９は、時刻調整の処理を示したシーケンス図である。 図２０は、配信制御システムから通信端末に送信するデータの回線適応制御の処理を示したシーケンス図である。 図２１は、通信端末から配信制御システムに送信するデータの回線適応制御の処理を示したシーケンス図である。 図２２は、マルチディスプレイの処理を示すシーケンス図である。 図２３は、マルチディスプレイの処理を示すシーケンス図である。 図２４は、マルチディスプレイの処理を示すシーケンス図である。 図２５は、各種フレームデータの概念図である。 図２６は、分割数が２である場合の強制Ｉフレームデータの概念図である。 図２７は、各種フレームデータを生成するためのフローチャートである。

以下に図面を用いて、本実施形態に係る配信システム１を詳細に説明する。なお、以下では、クラウドコンピューティングを利用して、クラウド上でウェブブラウザ（以下、「ブラウザ」と示す）とエンコーダとの両方を連携させて実行させ、通信端末に映像データや音データ等を送信する発明について詳細に説明する。

なお、以下に示される「画像」には、静止画及び動画が含まれる。また、以下に示される「映像」は、基本的に動画を意味し、動画が停止されて静止画状態になった場合も含まれる。更に、静止画及び音のうち少なくとも一方を示す場合には、「静止画（音）」と示す。また、画像及び音のうち少なくとも一方を示す場合には、「画像（音）」と示す。映像及び音のうち少なくとも一方を示す場合には、「映像（音）」と示す。

〔実施形態の概略〕
図１を用いて、本発明の一実施形態の概略を説明する。なお、図１は、本実施形態に係る配信システムの概略図である。

＜システム構成の概略＞
まず、配信システム１の構成の概略について説明する。

図１に示されているように、本実施形態の配信システム１は、配信制御システム２、複数の通信端末（５ａ〜５ｆ）、端末管理システム７、及びウェブサーバ８によって構築されている。なお、以下では、複数の通信端末（５ａ〜５ｆ）のうち、任意の通信端末を「通信端末５」として表す。また、配信制御システム２、端末管理システム７、及びウェブサーバ８は、いずれもサーバコンピュータによって構築されている。

通信端末５は、配信システム１のサービスを受けるユーザが使用する端末である。このうち、通信端末５ａは、ノートＰＣ(Personal Computer)である。通信端末５ｂは、スマートフォンやタブレット端末等のモバイル端末である。通信端末５ｃは、コピー、スキャン、プリント、及びファックスの各機能が複合されたＭＦＰ(Multifunction Peripheral/Printer/Product)である。通信端末５ｄは、プロジェクタである。通信端末５ｅは、カメラ、マイク及びスピーカを備えたテレビ（ビデオ）会議端末である。通信端末５ｆは、ユーザ等によって描かれた内容を電子的に変換することが可能な電子黒板（ホワイトボード）である。

なお、通信端末５は、図１に示されているような端末だけでなく、腕時計、自動販売機、ガスメータ、カーナビゲーション装置、ゲーム機、エアコン、照明器具、カメラ単体、マイク単体、スピーカ単体等であって、インターネット等の通信ネットワークを介して通信可能な装置であってもよい。

また、配信制御システム２、通信端末５、端末管理システム７、及びウェブサーバ８は、インターネットやＬＡＮ(Local Area Network)等の通信ネットワーク９によって通信することができる。この通信ネットワーク９には、３Ｇ(3rd Generation)、ＷｉＭＡＸ（登録商標）(Worldwide Interoperability for Microwave Access)、ＬＴＥ(Long Term Evolution)等の無線通信によるネットワークも含まれる。

なお、通信端末５によっては、通信端末５ｄ等のように、通信ネットワーク９を介して他の端末やシステムと通信する機能を有していないものがある。しかし、図２に示されているように、ユーザが通信端末５ｄのＵＳＢ(Universal Serial Bus)やＨＤＭＩ（登録商標）(High-Definition Multimedia Interface)のインターフェース部にドングル９９を差し込むことで、通信端末５は通信ネットワーク９を介して他の端末やシステムと通信可能となる。なお、図２は、通信端末にドングルを取り付ける際のイメージ図である。

また、配信制御システム２は、クラウド上でブラウザ２０（生成部の一例）を有し、ブラウザ２０におけるレンダラ(Renderer)の機能が、所定の記述言語で示された単一又は複数のコンテンツデータを取得して、レンダリングすることにより、RGB(Red, Green, Blue)によるビットマップデータ等の静止画データやＰＣＭ(Pulse Code Modulation)データ等の音データ（即ち、静止画（音）データ）としてのフレームデータを生成することができる。なお、コンテンツデータは、ウェブサーバ８や任意の通信端末等から取得されたデータであって、HTML(Hypertext Markup Language)やCSS(Cascading Style Sheets)による画像（音）データ、MP4(MPEG-4)による画像（音）データ、ＡＡＣ(Advanced Audio Coding)による音データ等が含まれる。

更に、配信制御システム２は、クラウド上でエンコード部１９を有し、エンコード部１９がエンコーダとしての役割を果たすことにより、静止画（音）データとしての各フレームデータを、H.264（MPEG-4 AVC）、H.265、Motion JPEG等の圧縮符号化方式の映像（音）データに変換する。

一方、端末管理システム７は、通信端末５のログイン認証を行ったり、通信端末５の契約情報等の管理を行ったりする。また、端末管理システム７は、電子メールを送信するためのＳＭＴＰ(Simple Mail Transfer Protocol)サーバの機能を有している。端末管理システム７は、例えば、クラウドのサービス(IaaS:Infrastructure as a Service)上に展開される仮想マシンとして実現することができる。端末管理システム７は、不測の事態に対応して継続的なサービス提供を行うために、多重化して運用することが望ましい。

また、ブラウザ２０は、リアルタイムコミュニケーション（ＲＴＣ：Real-time communication/collaboration）を可能にしている。更に、配信制御システム２は後述の図１６におけるエンコード部１９を有しており、このエンコード部１９は、ブラウザ２０によって出力されたフレームデータに対して、リアルタイムのエンコードを行い、H.264の規格等に基づく変換により生成された映像（音）データを出力することができる。そのため、配信制御システム２の処理は、ＤＶＤプレーヤによって、ＤＶＤに記録されているリアルタイム性のない映像（音）データを読み出して配信する場合等とは異なる。

なお、配信制御システム２だけでなく、通信端末５もブラウザを有してもよい。この場合、配信制御システム２のブラウザ２０を最新化することで、各通信端末５のブラウザを起動させる必要はなくなる。

＜各種配信方法の概略＞
続いて、各種配信方法の概略について説明する。

（基本配信）
図３は、基本的な配信方法を示した概念図である。配信システム１では、図３に示されているように、配信制御システム２のブラウザ２０が、ウェブサーバ８から画像（音）データとしてのウェブコンテンツデータ〔Ａ〕を取得してレンダリングすることにより、静止画（音）データとしての各フレームデータ〔Ａ〕を生成する。そして、エンコード部１９を含むエンコーダブリッジ部３０が、各フレームデータ〔Ａ〕をエンコード等することによりH.264等の圧縮符号化方式の映像（音）データ〔Ａ〕（送信データの一例）に変換する。配信制御システム２は、変換された後の映像（音）データ〔Ａ〕を通信端末５に配信する。

以上により、たとえリッチなウェブコンテンツデータであっても、配信制御システム２が、クラウド上で、HTML等によるウェブコンテンツデータからH.264等による圧縮した映像（音）データにした状態で、通信端末５に配信することができる。よって、通信端末５側では、自端末のブラウザを最新化したり、ＣＰＵ(Central Processing Unit)、ＯＳ(Operating System)、及びＲＡＭ(Random Access Memory)等のスペックを上げる手間や費用を掛けなくても、スムーズにウェブコンテンツを再生することができる。

また、今後、ウェブコンテンツのリッチ化が進んでも、クラウド上の配信制御システム２におけるブラウザ２０やＣＰＵ等のスペックを上げればよいため、通信端末５のスペックは上げる必要がない。

更に、配信システム１は、上述の配信方法を応用し、図４乃至図６に示されているように、ウェブコンテンツデータを複数の拠点に映像（音）データとして配信することも可能である。ここで、図４乃至図６に示されている配信方法について説明する。

（マルチキャスト）
図４は、マルチキャストの概念図である。図４に示されているように、配信制御システム２の単一のブラウザ２０は、ウェブサーバ８から画像（音）データとしてのウェブコンテンツデータ〔Ａ〕を取得してレンダリングすることにより、静止画（音）データとしての各フレームデータ〔Ａ〕を生成する。そして、エンコーダブリッジ部３０が、各フレームデータ〔Ａ〕をエンコードして、映像（音）データに変換する。その後、配信制御システム２は、映像（音）データ〔Ａ〕（送信データの一例）を複数の通信端末（５ｆ１，５ｆ２，５ｆ３）に配信する。

以上により、複数の拠点では、同じ映像（音）が再生される。なお、この場合、通信端末（５ｆ１，５ｆ２，５ｆ３）は同じ表示再生能力（解像度が同じ等）を有する必要はない。このような配信方法は、例えば「マルチキャスト」と呼ぶ。

（マルチディスプレイ）
図５は、マルチディスプレイの概念図である。図５に示されているように、配信制御システム２の単一のブラウザ２０は、ウェブサーバ８から画像（音）データとしてのウェブコンテンツデータ〔ＸＹＺ〕を取得してレンダリングすることにより、静止画（音）データとしての各フレームデータ〔ＸＹＺ〕を生成する。そして、エンコーダブリッジ部３０が、フレームデータ〔ＸＹＺ〕毎に、複数のフレームデータ（〔Ｘ〕，〔Ｙ〕，〔Ｚ〕）に分割した後にエンコードすることで、複数の映像（音）データ（〔Ｘ〕，〔Ｙ〕，〔Ｚ〕）に変換する。その後、配信制御システム２は、映像（音）データ〔Ｘ〕（送信データの一例）を通信端末５ｆ１に配信する。また、同じように、配信制御システム２は、映像（音）データ〔Ｙ〕（送信データの一例）を通信端末５ｆ２に配信し、映像（音）データ〔Ｚ〕（送信データの一例）を通信端末５ｆ３に配信する。

以上により、例えば、横長のウェブコンテンツ〔ＸＹＺ〕であっても、複数の通信端末５で分割して映像（音）が再生されるため、通信端末（５ｆ１，５ｆ２，５ｆ３）を一列に並べて設置すれば、１つの大きな映像を再生させることと同様の効果を得ることができる。なお、この場合、通信端末（５ｆ１，５ｆ２，５ｆ３）は同じ表示再生能力（解像度が同じ等）を有する必要がある。このような配信方法は、例えば「マルチディスプレイ」と呼ぶ。

（複合配信）
図６は、配信制御システムを介して複数の通信端末を使った複合配信の概念図である。図６に示されているように、第１の拠点（図６の右側）では、電子黒板としての通信端末５ｆ１及びテレビ会議端末としての通信端末５ｅ１が利用され、第２の拠点（図６の左側）では、同じく電子黒板としての通信端末５ｆ２、及びテレビ会議端末としての通信端末５ｅ２が利用されている。また、第１の拠点では、通信端末５ｆ１にストロークによる文字等を描画させるための電子ペンＰ１が利用され、第２の拠点では、通信端末５ｆ２にストロークによる文字等を描画させるための電子ペンＰ２が利用されている。

そして、第１の拠点において、通信端末５ｅ１によって取得された映像（音）データは、エンコード部６０でエンコードされた後に、配信制御システム２に送信される。その後、配信制御システム２のデコード部４０でデコードされて、ブラウザ２０に入力される。また、電子ペンＰ１によって通信端末５ｆ１に描かれたストロークを示す操作データ（この場合、通信端末５ｆ１のディスプレイ上における座標データ等）は、配信制御システム２に送信され、ブラウザ２０に入力される。一方、第２の拠点においても、通信端末５ｅ２によって取得された映像（音）データは、エンコード部６０でエンコードされた後に、配信制御システム２に送信される。その後、配信制御システム２のデコード部４０でデコードされて、ブラウザ２０に入力される。また、電子ペンＰ２によって通信端末５ｆ２に描かれたストロークを示す操作データ（この場合、通信端末５ｆ２のディスプレイ上における座標データ等）は、配信制御システム２に送信され、ブラウザ２０に入力される。

一方、ブラウザ２０は、例えば、ウェブサーバ８から通信端末（５ｆ１，５ｆ２）のぞれぞれのディスプレイに表示される背景画像であるウェブコンテンツデータ〔Ａ〕を取得する。そして、ブラウザ２０は、ウェブコンテンツデータ〔Ａ〕、操作データ（〔ｐ１〕，〔ｐ２〕）及び映像（音）コンテンツデータ（〔Ｅ１〕，〔Ｅ２〕）を結合してレンダリングするとで、各コンテンツ（〔Ａ〕，〔ｐ１〕，〔ｐ２〕，〔Ｅ１〕，〔Ｅ２〕）が所望のレイアウトに設置された静止画（音）データとしてのフレームデータを生成する。そして、エンコーダブリッジ部３０は、各フレームデータをエンコードし、配信制御システム２が各拠点に同じコンテンツ（〔Ａ〕，〔ｐ１〕，〔ｐ２〕，〔Ｅ１〕，〔Ｅ２〕）を示す映像（音）データ（送信データの一例）を配信する。これにより、第１の拠点では、通信端末５ｆ１のディスプレイ上に、映像（〔Ａ〕、〔ｐ１〕、〔ｐ２〕、〔Ｅ１（映像部分）〕及び〔Ｅ２（映像部分）〕）が表示されると共に、通信端末５ｅ１のスピーカから音〔Ｅ２（音部分）〕が出力される。一方、第２の拠点でも、通信端末５ｆ２のディスプレイ上に、映像（〔Ａ〕、〔ｐ１〕、〔ｐ２〕、〔Ｅ１（映像部分）〕及び〔Ｅ２（映像部分）〕）が表示されると共に、通信端末５ｅ２のスピーカから音〔Ｅ１（音部分）〕が出力される。なお、第１の拠点では、通信端末５ｆ１のエコーキャンセル機能により、自拠点の音〔Ｅ１（音部分）〕は出力されない。一方、第２の拠点では、通信端末５ｆ２のエコーキャンセル機能により、自拠点の音〔Ｅ２（音部分）〕は出力されない。

以上により、第１の拠点と第２の拠点とでは、遠隔地間においてリアルタイムで同じ情報を共有する遠隔共有処理を行うことができるため、本実施形態の配信システム１は遠隔会議等に有効である。

〔実施形態の詳細な説明〕
続いて、図７乃至図２４を用いて、実施形態の詳細な説明を行う。

＜実施形態のハードウェア構成＞
まずは、図７及び図８を用いて、本実施形態のハードウェア構成を説明する。なお、図７は、配信制御システム、通信端末、端末管理システム、及びウェブサーバの論理的なハードウェア構成図である。また、図８は、ドングルの論理的なハードウェア構成図である。なお、通信端末の通信に関与するハードウェア構成は、通信端末のハードウェア構成の一部と同じであるため、説明を省略する。

図７に示されているように配信制御システム２は、配信制御システム２全体の動作を制御する（ホスト）ＣＰＵ２０１、ＩＰＬ等のＣＰＵ２０１の駆動に用いられるプログラムを記憶したＲＯＭ２０２、ＣＰＵ２０１のワークエリアとして使用されるＲＡＭ２０３、プログラム等の各種データを記憶するＨＤＤ２０４、ＣＰＵ２０１の制御にしたがってＨＤＤ２０４に対する各種データの読み出し又は書き込みを制御するＨＤＣ(Hard Disk Controller)２０５、フラッシュメモリ等の記録メディア２０６に対するデータの読み出し又は書き込み（記憶）を制御するメディアドライブ２０７、各種情報を表示するディスプレイ２０８、通信ネットワーク９を利用してデータ送信したりドングル９９を接続したりするためのＩ／Ｆ２０９、キーボード２１１、マウス２１２、マイク２１３、スピーカ２１４、ＧＰＵ(Graphics Processing Unit)２１５、ＧＰＵ２１５の駆動に用いられるプログラムを記憶したＲＯＭ２１６、ＧＰＵ２１５のワークエリアとして使用されるＲＡＭ２１７、上記各構成要素を図７に示されているように電気的に接続するためのアドレスバスやデータバス等の拡張バスライン２２０を備えている。なお、プロジェクタとしての通信端末５ｄのように、ＧＰＵが備えられていない場合もある。また、端末管理システム７、及びウェブサーバ８のハードウェア構成は、配信制御システム２のハードウェア構成と同様であるため、それらの説明を省略する。

次に、図８を用いて、図２に示されているドングルのハードウェア構成について説明する。図８に示されているように、ドングル９９は、ドングル９９全体の動作を制御するＣＰＵ９１、基本入出力プログラムを記憶したＲＯＭ９２、ＣＰＵ９１のワークエリアとして使用されるＲＡＭ９３、ＣＰＵ９１の制御にしたがってデータの読み出し又は書き込みを行うＥＥＰＲＯＭ（Electrically Erasable and Programmable ROM）９４、ＧＰＵ９５、ＧＰＵ９５の駆動に用いられるプログラムを記憶したＲＯＭ９６、ＧＰＵ９５のワークエリアとして使用されるＲＡＭ９７、通信端末５のインターフェースＩ／Ｆ２０９に接続するためのインターフェースＩ／Ｆ９６、アンテナ９７ａ、このアンテナ９７ａを利用して短距離無線技術により通信を行う通信部９７、及び、上記各部を電気的に接続するためのアドレスバスやデータバス等のバスライン９０を備えている。

なお、短距離無線技術として、例えば、ＮＦＣ（Near Field Communication）規格、ＢｌｕｅＴｏｏｔｈ（登録商標）、ＷｉＦｉ(Wireless Fidelity）、ＺｉｇＢｅｅ（登録商標）等が挙げられる。また、ドングル９９にはＧＰＵ９５が備えられているため、通信端末５ｄのようにＧＰＵが備えられていない場合であっても、図２に示されているようにドングル９９が取り付けられることで、通信端末５ｄはグラフィクス表示に必要な計算処理を実行することができる。

＜実施形態の機能構成＞
次に、図９乃至図１６を用い、本実施形態の機能構成について説明する。

（配信制御システムの機能構成）
先ずは、図９を用いて、配信制御システム２の機能構成について説明する。図９は、主に配信制御システムの各機能を示す機能ブロック図である。図９では、配信制御システム２が通信端末５ｆ１に対して映像（音）データを配信する場合の機能構成が示されているが、配信先が通信端末５ｆ１以外の場合も、同じ機能構成を有する。なお、配信制御システム２は、複数の配信エンジンサーバを備えているが、説明を簡単にするために、以下では、単一の配信エンジンサーバを備えている場合について説明する。

図９に示されているように、配信制御システム２は、図７に示されているＣＰＵ２０１又はＧＰＵ２１５であるプロセッサ等のハードウェア構成及びプログラムによって、図９に示されている各機能構成を有する。

具体的に、配信制御システム２は、ブラウザ２０、送受信部２１、ブラウザ管理部２２、送信用ＦＩＦＯバッファ２４、時刻管理部２５、時刻取得部２６、回線適応制御部２７、エンコーダブリッジ部３０、送受信部３１、受信用ＦＩＦＯ３４、認識部３５、遅延情報取得部３７ａ、回線適応制御部３７ｂ、及びデコード部４０を有している。更に、配信制御システム２は、図７に示されているＨＤＤ２０４によって構築される記憶部２０００を有している。この記憶部２０００には、認識部３５から出力されブラウザ管理部２２を介して送られた後述の認識情報が記憶される。なお、ブラウザ２０が取得したコンテンツデータは、キャッシュとして、記憶部２０００に一時的に記憶しておくこともできる。

上述の各機能構成のうち、ブラウザ２０は、配信制御システム２内で動作するウェブブラウザである。ブラウザ２０は、ウェブコンテンツのリッチ化に対応させて常に最新化されている。ブラウザ２０は、例えば、Media Player、Flash Player、JavaScript（登録商標）、CSS及びHTMLレンダラを有する。なお、JavaScript（登録商標）には、標準規格のものと配信システム１独自のものが含まれる。

ここで、Media Playerは、映像（音）ファイルなどのマルチメディアファイルをブラウザ２０内で再生するためのブラウザプラグインである。Flash Playerは、Flashコンテンツをブラウザ２０内で再生するためのブラウザプラグインである。独自のJavaScript（登録商標）は、配信システム１に固有のサービスのAPI(Application Programming Interface)を提供するJavaScript（登録商標）群である。CSSは、HTMLで記述されたウェブページの見栄えやスタイルを効率的に定義するための技術である。HTMLレンダラは、HTMLレンダリングエンジンである。

レンダラは、画像（音）データとしてのウェブコンテンツデータ等のコンテンツデータをレンダリングすることにより、静止画（音）データとしての各フレームデータを生成する。また、レンダラは、図６に示されているように、複数種類のコンテンツ（〔Ａ〕，〔ｐ１〕，〔ｐ２〕，〔Ｅ１〕，〔Ｅ２〕）のレイアウトを行うレイアウトエンジン(Layout Engine)でもある。

また、本実施形態の配信システム１では、配信制御システム２内に複数のブラウザ２０を用意しており、これら複数のブラウザ２０の中からユーザセッションに使用するクラウドブラウザが選択される。なお、ここでは、説明を簡略化するため、単一のブラウザ２０が用意されている場合について、以下続けて説明する。

送受信部２１は、端末管理システム７やウェブサーバ８との間で、各種データ、各種要求、各種指示等の送受信を行う。例えば、送受信部２１は、ウェブサーバ８のコンテンツサイトからウェブコンテンツデータを取得する。また、送受信部２１は、端末管理システム７から取得した各種データを配信制御システム２内の各機能構成に出力したり、端末管理システム７から取得した各種データ、各種要求、又は各種指示等に基づいて配信制御システム２内の各機能構成を制御したりする。例えば、ブラウザ２０が複数ある場合、送受信部２１は、端末管理システム７からの配信のパターンの切替え要求をブラウザ管理部２２に出力し、ブラウザ管理部２２が、複数のブラウザ２０における一のブラウザから他のブラウザへの切替えを制御する。また、送受信部２１は、端末管理システム７からの配の切替え要求に基づいて、図１５及び図１６に示されているエンコーダブリッジ部３０内の各構成の組み合わせの切替えを行う。

ブラウザ管理部２２は、ブラウザ２０の管理を行う。例えば、ブラウザ管理部２２は、
ブラウザ２０に、起動又は終了を指示したり、起動又は終了時にエンコーダＩＤを採番し
たりする。ここで、エンコーダＩＤは、ブラウザ管理部２２がエンコーダブリッジ３０の
プロセスを管理するために採番する識別情報である。また、ブラウザ管理部２２は、ブラ
ウザ２０が起動されるたびに、ブラウザＩＤを採番して管理する。ここで、ブラウザＩＤ
は、ブラウザ管理部２２がブラウザ２０のプロセスを管理するために採番し、ブラウザ２
０を識別するための識別情報である。

また、ブラウザ管理部２２は、送受信部３１を介して通信端末５から、各種操作データを取得し、ブラウザ２０に出力する。なお、操作データは、通信端末５での操作イベント（キーボード２１１やマウス２１２等による操作や電子ペンＰによるストローク等）によって生じたデータである。通信端末５に、温度センサ、湿度センサ、及び加速度センサ等の各種センサが設けられている場合には、ブラウザ管理部２２は、通信端末５から各センサの出力信号であるセンサ情報を取得し、ブラウザ２０に出力する。更に、ブラウザ管理部２２は、認識部３５から画像（音）データを取得してブラウザ２０に出力したり、認識部３５から後述の認識情報を取得して記憶部２０００に記憶したりする。また、ブラウザ管理部２２は、受信用ＦＩＦＯ３４から映像（音）データを取得してブラウザ２０に出力する。

送信用ＦＩＦＯ２４は、ブラウザ２０で生成された静止画（音）データとしての各フレームデータを格納するバッファである。

時刻管理部２５は、配信制御システム２独自の時刻Ｔを管理している。

時刻取得部２６は、後述の通信端末５における時刻制御部５６と連携して、時刻調整の処理を行う。具体的には、時刻取得部２６は、時刻管理部２５から配信制御システム２における時刻Ｔを示す時刻情報（Ｔ）を取得したり、送受信部３１及び送受信部５１を介して、後述の時刻制御部５６から通信端末５における時刻ｔを示す時刻情報（ｔ）を受信したり、時刻制御部５６に時刻情報（ｔ）及び時刻情報（Ｔ）を送信する。

回線適応制御部２７は、送信遅延時間情報（Ｄ）に基づいて、再生遅延時間Ｕを計算したり、エンコーダブリッジ部３０における変換部１０のフレームレートやデータの解像度等の動作条件を計算したりする。この再生遅延時間Ｕは、再生までにデータがバッファリングされることで、再生を遅延させるための時間である。つまり、回線適応制御部２７は、送信遅延時間情報（Ｄ）とデータのサイズ（ビット数やバイト数等）に基づき、エンコーダブリッジ部３０の動作を変更する。この送信遅延時間情報（Ｄ）は、後述のように、通信端末５における遅延情報取得部５７が再生制御部５３から取得した複数の送信遅延時間Ｄ１によって構成された度数分布情報を示す。各送信遅延時間Ｄ１は、映像（音）データが配信制御システム２によって送信されてから通信端末５によって受信されるまでの時間を示す。

エンコーダブリッジ部３０は、ブラウザ２０が生成した静止画（音）データとしての各フレームデータを、エンコーダブリッジ部３０における後述の変換部１０に出力する。この際、変換部１０は、回線適応制御部２７で計算された動作条件を考慮して各処理を行なう。エンコーダブリッジ部３０については、図１５及び図１６を用いて、更に詳細に説明する。図１５は、エンコーダブリッジ部の詳細図である。また、図１６は、変換部の各機能を示す機能ブロック図である。

図１５に示されているように、エンコーダブリッジ部３０は、作成・選択・転送部３１０、及び選択部３２０と、これらの間に複数の変換部（１０ａ，１０ｂ，１０ｃ）が構築されている。ここでは、３つの変換部を示したが、いくつであってもよい。なお、以下、任意の変換部を「変換部１０」として表す。

更に、変換部１０は、ブラウザ２０によって生成された静止画（音）データとしての各フレームデータのデータ形式を、通信ネットワーク９を介して通信端末５に配信できるH.264等のデータ形式に変換する。そのため、変換部１０は、図１６に示されているように、トリミング部１１、リサイズ部１２、分割部１３、及びエンコード部１９を有することで、フレームデータに各種処理を施す。トリミング部１１、リサイズ部１２、及び分割部１３は、音データの場合は、処理を行わない。

このうち、トリミング部１１は、静止画の一部だけを切り出す処理を行う。リサイズ部１２は、静止画の縮尺を変更する。分割部１３は、図５に示されているように、静止画を分割する。

また、エンコード部１９は、ブラウザ２０で生成された、静止画（音）データとしての各フレームデータをエンコードすることにより、通信ネットワーク９介して通信端末５に映像（音）データを配信できるように変換する。また、エンコード部１９は、映像が動かなければ（フレーム間で更新（変化）がなければ）、以降、映像が動くまでスキップフレーム（「フレームスキップ」ともいう）データを挿入することで帯域をセーブする。

なお、レンダリングにより静止画データと共に音データが生成される場合には、これら両方のデータがエンコードされるが、音データだけが生成される場合には、トリミングやリサイズ、分割は行われることはなく、エンコードだけが行われてデータ圧縮される。

また、作成・選択・転送部３１０は、新たに変換部１０を作成したり、既に作成されている変換部１０に対して入力させる静止画（音）データとしてのフレームデータを選択したり、変換部１０にフレームデータを転送したりする。作成する場合としては、作成・選択・転送部３１０は、通信端末５おける映像（音）データの再生能力に応じた変換が可能な変換部１０を作成する。また、選択する場合としては、作成・選択・転送部３１０は、既に作成されている変換部１０を選択する。例えば、通信端末５ａへの配信に加えて通信端末５ｂへの配信を開始するにあたって、通信端末５ａへ配信している映像（音）データと同じ映像（音）データを通信端末５ｂへ配信する場合がある。このような場合で、更に、通信端末５ｂが通信端末５ａにおける映像（音）データの再生能力と同じ再生能力を有する場合には、作成・選択・転送部３１０は通信端末５ｂ用に新たな変換部１０ｂを作成せずに、通信端末５ａ用に既に作成している変換部１０ａを利用する。また、転送する場合としては、作成・選択・転送部３１０は、送信用ＦＩＦＯに記憶されているフレームデータを、変換部１０に転送する。

一方、選択部３２０は、既に作成されている変換部１０から所望のものを選択する。これら作成・選択・転送部３１０と選択部３２０による選択によって、図６に示したような様々なパターンの配信を行うことができる。

送受信部３１は、通信端末５との間で、各種データや要求等の送受信を行う。この送受信部３１が、クラウド上から通信ネットワーク９を介して通信端末５に各種データや要求等の送信を行うことで、配信制御システム２は通信端末５に対して、各種データや要求等を配信することができる。例えば、送受信部３１は、通信端末５のログイン処理において、通信端末５の送受信部５１に対し、ユーザにログイン要求を促すための認証画面データを送信する。その他に、送受信部３１は、ＨＴＴＰＳ(Hypertext Transfer Protocol over Secure Socket Layer)サーバを介して配信システム１独自のプロトコルにより、通信端末５のユーザアプリや通信端末６のデバイスアプリへのデータ送信およびデータ受信を行う。この独自のプロトコルは、配信制御システム２と通信端末との間でリアルタイムに途切れることなくデータを送受信するためのＨＴＴＰＳベースのアプリケーション層プロトコルである。また、送受信部３１は、送信レスポンス制御、リアルタイムのデータ作成、コマンド送信、受信レスポンス制御、受信データ分析、及びジェスチャ変換を行う。

このうち、送信レスポンス制御は、配信制御システム２から通信端末５にデータを送信するために、通信端末５からリクエスト（要求）されたダウンロード用のＨＴＴＰＳセッションを管理する処理である。このダウンロード用のＨＴＴＰＳセッションのレスポンスはすぐに終了せず、一定時間（１〜数分）保持する。送受信部３１は、通信端末５に送るデータを動的にレスポンスのＢｏｄｙ部に書き込む。また、再接続のコストをなくすため、通信端末からは前のセッションが終了しないうちに別のリクエストが届くようにする。送受信部３１を、前のリクエストが完了するまで待機させておくようにすることで、再接続を行っても、オーバヘッドを削除することができる。

リアルタイムのデータ作成は、図１６におけるエンコード部１９で生成された圧縮映像（および圧縮音）のデータに独自のヘッダを付与して、ＨＴＴＰＳのＢｏｄｙ部に書き込む処理である。

コマンド送信は、通信端末５に送信するコマンドデータを生成し、通信端末５へのＨＴＴＰＳのＢｏｄｙ部に書き込む処理である。

受信レスポンス制御は、配信制御システム２が通信端末５からデータを受信するために、通信端末５からリクエストされたＨＴＴＰＳセッションを管理する処理である。このＨＴＴＰＳセッションのレスポンスはすぐに終了せず、一定時間（１〜数分）保持される。通信端末５は、配信制御システム２の送受信部３１に送るデータを動的にリクエストのＢｏｄｙ部に書き込む。

受信データ分析は、通信端末５から送られてきたデータを種別ごとに分析し、必要なプロセスにデータを渡す処理である。

ジェスチャ変換は、ユーザが電子黒板としての通信端末５ｆに電子ペンや手書きにより入力したジェスチャイベントを、ブラウザ２０が受け取れる形式のデータに変換する処理である。

また、受信用ＦＩＦＯ３４は、デコード部４０でデコードされた後の映像（音）データを格納するバッファである。

認識部３５は、通信端末５から受信する画像（音）データに対しての処理を行う。具体的には、認識部３５は、例えば、サイネージ向けにカメラ６２で撮影された画像から人や動物の顔、年齢、及び性別などを認識する。また、認識部３５は、オフィス向けに、カメラ６２で撮影された画像から顔認識による名前タグ付けや背景画像の差し替え処理などを行う。認識部３５は、認識した内容を示す認識情報を記憶部２０００に記憶させる。この認識部３５は、認識拡張ボードで処理を行うことで高速化が実現される。

遅延情報取得部３７ａは、下り用の回線適応制御の処理に用いられる通信端末５側の遅延情報取得部５７に対応して、上り用の回線適応制御の処理に用いられる。具体的には、遅延情報取得部３７ａは、デコード部４０から送信遅延時間ｄ１を示す送信遅延時間情報（ｄ１）を取得して一定時間保持しておき、複数の送信遅延時間情報（ｄ１）を取得したところで、回線適応制御部３７ｂに、複数の送信遅延時間ｄ１による度数分布情報を示す送信遅延時間情報（ｄ）を出力する。送信遅延時間情報（ｄ１）は、映像（音）データが通信端末５によって送信されてから配信制御システム２によって受信されるまでの時間を示す。

回線適応制御部３７ｂは、下り用の回線適応制御の処理に用いられる回線適応制御部２７に対応して、上り用の回線適応制御の処理に用いられる。具体的には、回線適応制御部３７ｂは、送信遅延時間情報（ｄ）に基づいて、通信端末５側のエンコード部６０の動作条件を計算する。また、回線適応制御部３７ｂは、送受信部３１及び送受信部５１を介して通信端末５のエンコード部６０に、フレームレートやデータの解像度等の動作条件を示す回線適応制御信号を送信する。

デコード部４０は、通信端末５から送信されて来た映像（音）データをデコードする。また、デコード部４０は、送信遅延時間ｄ１を示す送信遅延時間情報（ｄ１）を遅延情報取得部３７ａに出力する。

（通信端末の機能構成）
続いて、図１０を用いて、通信端末５の機能構成について説明する。図１０は、主に通信端末の各機能を示す機能ブロック図である。通信端末５は、ユーザが配信システム１へのログインや映像（音）データの配信の開始又は停止などを行うためのインターフェースとなる端末である。

図１０に示されているように、通信端末５は、図７に示されているＣＰＵ２０１等のハードウェア構成及びプログラムによって、図１０に示されている各機能構成を有する。なお、通信端末５が、図２に示されているようにドングル９９が差し込まれることで、通信ネットワーク９を介して他の端末やシステムと通信可能となる場合には、図７及び図８に示されているハードウェア構成及びプログラムによって、図１０に示されている各機能構成を有する。

具体的に、通信端末５は、デコード部５０、送受信部５１、操作部５２、再生制御部５３、レンダリング部５５、時刻制御部５６、遅延情報取得部５７、表示部５８、及びエンコード部６０を有している。更に、通信端末５は、図７に示されているＲＡＭ２０３によって構築される記憶部５０００を有している。この記憶部５０００には、後述の時刻差Δを示す時刻差情報（Δ）、及び通信端末５における時刻ｔを示す時刻情報（ｔ）が記憶される。

このうち、デコード部５０は、配信制御システム２から配信され、再生制御部５３から出力された映像（音）データをデコードする。

送受信部５１は、配信制御システム２の送受信部３１、及び後述の端末管理システム７の送受信部７１ａとの間で、各種データや要求等の送受信を行う。例えば、送受信部５１は、通信端末５のログイン処理において、操作部５２による通信端末５の起動に基づき、端末管理システム７の送受信部７１にログイン要求を行う。

操作部５２は、ユーザの操作入力を受け付ける処理を行い、例えば、電源スイッチ、キーボード、マウス、電子ペンＰ等による入力や選択等を受け付け、操作データとして配信制御システム２のブラウザ管理部２２に送信する。

再生制御部５３は、送受信部５１から受けた映像（音）データ（リアルタイムデータのパケット）をバッファリングし、再生遅延時間Ｕを考慮してデコード部５０に出力する。また、再生制御部５３は、送信遅延時間Ｄ１を示す送信遅延時間情報（Ｄ１）を算出し、遅延情報取得部５７に出力する。

レンダリング部５５は、デコード部５０によってデコードされたデータをレンダリングする。

時刻制御部５６は、配信制御システム２の時刻取得部２６と連携して、時刻調整の処理を行う。具体的には、時刻制御部５６は、記憶部５０００から通信端末５における時刻ｔを示す時刻情報（ｔ）を取得する。また、時刻制御部５６は、送受信部５１及び送受信部３１を介して、配信制御システム２の時刻取得部２６に、配信制御システム２における時刻Ｔを示す時刻情報（Ｔ）を要求する。この場合、時刻情報（Ｔ）の要求と共に、時刻情報（ｔ）が送信される。

遅延情報取得部５７は、再生制御部５３から送信遅延時間Ｄ１を示す送信遅延時間情報（Ｄ１）を取得して一定時間保持しておき、複数の送信遅延時間情報（Ｄ１）を取得したところで、送受信部５１及び送受信部３１を介して回線適応制御部２７に、複数の送信遅延時間Ｄ１による度数分布情報を示す送信遅延時間情報（Ｄ）を送信する。なお、送信遅延時間情報（Ｄ）は、例えば、１００フレームに１回送信される。

表示部５８は、レンダリング部５５によってレンダリングされたデータを再生する。

エンコード部６０は、内蔵されたマイク２１３や、外付けのカメラ６２及びマイク６３から取得してエンコードした映像（音）データ〔Ｅ〕と、記憶部５０００から取得した現時点の通信端末５における時刻ｔ_０を示す時刻情報（ｔ_０）と、同じく記憶部５０００から取得した時刻差Δを示す時刻差情報（Δ）を、送受信部５１及び送受信部３１を介して、配信制御システム２のデコード部４０に送信する。なお、時刻差Δは、配信制御システム２独自で管理されている時刻と通信端末５独自で管理されている時刻との差である。

また、エンコード部６０は、回線適応制御部３７ｂから受信した回線適応制御信号で示される動作条件に基づいて、エンコード部６０の動作条件を変更する。更に、エンコード部６０は、新たな動作条件に従って、カメラ６２及びマイク６３から取得してエンコードした映像（音）データ〔Ｅ〕と、記憶部５０００から取得した現時点の通信端末５における時刻ｔ_０を示す時刻情報（ｔ_０）と、記憶部５０００から取得した時刻差Δを示す時刻差情報（Δ）とを、送受信部５１及び送受信部３１を介して、配信制御システム２のデコード部４０に送信する。

なお、内蔵されたマイク２１３、外付けのカメラ６２及びマイク６３等は、入力手段の一例であり、エンコードやデコードが必要な各種デバイスである。入力手段は、映像（音）データの他に、触覚(touch)データや嗅覚（smell）データを出力することができてもよい。入力手段には、温度センサ、方位センサ、加速度センサ等の各種センサも含まれる。

（端末管理システムの機能構成）
続いて、図１１を用いて、端末管理システム７の機能構成について説明する。図１１は、端末管理システムの各機能を示す機能ブロック図である。

図１１に示されているように、端末管理システム７は、図７に示されているＣＰＵ２０１等のハードウェア構成及びプログラムによって、図１１に示されている各機能構成を有する。

具体的に、端末管理システム７は、送受信部７１ａ、送受信部７１ｂ、及び認証部７５を有している。更に、端末管理システム７は、図７に示されているＨＤＤ２０４によって構築される記憶部７０００を有している。この記憶部７０００には、配信先選択メニューデータ、端末管理テーブル７０１０、及び利用可能端末管理テーブル７０２０が記憶される。

このうち、配信先選択メニューは、図１２に示されているような配信先選択メニュー画面を示すデータである。

端末管理テーブル７０１０では、図１３に示されているように、通信端末５の端末ＩＤ、ユーザ証明書、ユーザが配信システム１のサービスを利用する際の契約情報、通信端末５の端末種別、各通信端末５のホームＵＲＬ(Uniform Resource Locator)を示す設定情報、各通信端末５の実行環境情報、共有ＩＤ、設置位置情報、及び表示名情報が関連付けて管理されている。このうち、実行環境情報には、各通信端末５の「お気に入り」、「前回のCookie情報」、及び「キャッシュファイル」が含まれており、各通信端末５のログイン後に、設定情報と共に配信制御システム２に送信され、各通信端末５に対して個別のサービスを行うために利用される。

また、共有ＩＤは、各ユーザが、自己の通信端末５に配信されている映像（音）データと同じ内容の映像（音）データを他の通信端末５にも配信させることで、遠隔共有処理を行う場合に利用されるＩＤであり、他の通信端末又は他の通信端末群を識別する識別情報である。例えば、端末ＩＤ「ｔ００６」の共有ＩＤは「ｖ００６」であり、端末ＩＤ「ｔ００７」の共有ＩＤは「ｖ００６」であり、また、端末ＩＤ「ｔ００８」の共有ＩＤは「ｖ００６」である。更に、端末ＩＤ「ｔ００１」の通信端末５ａから、共有ＩＤ「ｖ００６」の通信端末（５ｆ１，５ｆ２，５ｆ３）との遠隔共有処理の要求があった場合には、配信制御システム２は、通信端末（５ｆ１，５ｆ２，５ｆ３）に対して、通信端末５ａに配信中の映像(音)データと同じ映像（音）データを配信する。但し、通信端末５ａと通信端末（５ｆ１，５ｆ２，５ｆ３）の表示部５８の解像度が異なる場合には、これに応じて、配信制御システム２が映像(音)データを配信する。

更に、設置位置情報は、例えば、図５に示されているように、通信端末（５ｆ１，５ｆ２，５ｆ３）が並んで設置される場合の設置位置を示している。表示名情報は、図１２に示されている配信先選択メニュー画面の表示名の内容を表す情報である。

一方、利用可能端末管理テーブル７０２０では、端末ＩＤ毎に、この端末ＩＤによって示される通信端末５が遠隔共有処理することが可能な通信端末又は通信端末群を示す共有ＩＤが関連付けて管理されている。

次に、図１１に戻り、各機能構成について説明する。

送受信部７１ａは、通信端末５との間で、各種データや要求等の送受信を行う。例えば、送受信部７１ａは、通信端末５の送受信部５１からログイン要求を受信したり、送受信部５１に対してログイン要求の認証結果を送信したりする。

送受信部７１ｂは、配信制御システム２との間で、各種データや要求等の送受信を行う。例えば、送受信部７１ｂは、配信制御システム２の送受信部２１から配信先選択メニューのデータの要求を受信したり、送受信部２１に対して、配信先選択メニューのデータを送信したりする。

認証部７５は、通信端末５から受信した端末ＩＤ及びユーザ証明書に基づいて、端末管理テーブル７０１０を検索することにより、同じ組み合わせの端末ＩＤ及びユーザ証明書があるか否かを判断することで、通信端末５の認証を行う。

〔実施形態の動作または処理〕
続いて、図１７乃至図２４を用いて、本実施形態の動作または処理について説明する。なお、これらの処理は、配信制御システム２、通信端末５、端末管理システム７、ウェブサーバ８における各ＣＰＵが、それぞれに格納されているプログラムに従って実行される処理である。

＜基本的な配信処理＞
まず、図１７を用いて、図３に示されている基本的な配信方法における具体的な配信処理を説明する。図１７は、配信制御システムの基本的な配信処理を示したシーケンス図である。なお、ここでは、通信端末５ａを用いてログイン要求する場合について説明するが、通信端末５ａ以外の通信端末５を用いてログインしてもよい。

図１７に示されているように、通信端末５ａにおいてユーザが電源オンにすると、通信端末５ａの送受信部５１は、端末管理システム７の送受信部７１ａに、ログイン要求する。（ステップＳ２１）。これにより、送受信部７１ａは、ログイン要求を受信する。このログイン要求には、通信端末５ａの端末ＩＤ及びユーザ証明書が含まれている。よって、認証部７５は、通信端末５ａの端末ＩＤ及びユーザ証明書を取得する。

次に、認証部７５は、端末ＩＤ及びユーザ証明書に基づいて、図１３に示されている端末管理テーブル７０１０を検索することにより、同じ組み合わせの端末ＩＤ及びユーザ証明書があるか否かを判断することで、通信端末５ａの認証を行う(ステップＳ２２)。ここでは、端末管理テーブル７０１０に同じ組み合わせの端末ＩＤ及びユーザ証明書がある場合、即ち、通信端末５ａが配信システム１における正当な端末であると認証された場合について、以下に続けて説明する。

端末管理システム７の送受信部７１ａは、通信端末５ａの送受信部５１に、配信制御システム２のＩＰアドレスを送信する（ステップＳ２３）。なお、配信制御システム２のＩＰアドレスは、予め、端末管理システム７によって配信制御システム２から取得されて、記憶部７０００に記憶されている。

次に、端末管理システム７の送受信部７１ｂは、配信制御システム２の送受信部２１に、ブラウザ２０の起動要求を行う（ステップＳ２４）。これにより、送受信部２１は、ブラウザ２０の起動要求を受信する。そして、ブラウザ管理部２２は、送受信部２１によって受信された起動要求に基づいて、ブラウザ２０を起動させる（ステップＳ２５）。

次に、エンコーダブリッジ部３０の作成・選択・転送部３１０は、通信端末５ａの再生能力（ディスプレイの解像度等）及びコンテンツの種類に従って変換部１０を作成する（ステップＳ２６）。次に、送受信部２１は、ブラウザ２０の命令に従い、ウェブサーバ８に対して、コンテンツデータ〔Ａ〕を要求する（ステップＳ２７）。これに対して、ウェブサーバ８は、要求されたコンテンツデータ〔Ａ〕を自己の記憶部（不図示）から読み出す（ステップＳ２８）。そして、ウェブサーバ８は、配信制御システム２の送受信部２１にコンテンツデータ〔Ａ〕を送信する（ステップＳ２９）。

次に、ブラウザ２０が、送受信部２１によって受信されたコンテンツデータ〔Ａ〕をレンダリングすることにより、静止画（音）データとしての各フレームデータを生成して、送信用ＦＩＦＯ２４に出力する（ステップＳ３０）。そして、変換部１０が、送信用ＦＩＦＯ２４に格納された各フレームデータをエンコードすることで、通信端末５ａに配信すべき映像（音）データ〔Ａ〕に変換する（ステップＳ３１）。

次に、送受信部３１は、通信端末５ａの送受信部５１に映像（音）データ〔Ａ〕を送信する（ステップＳ３２）。これにより、通信端末５ａの送受信部５１は、映像（音）データ〔Ａ〕を受信して、再生制御部５３に出力する。

次に、通信端末５ａでは、デコード部５０が再生制御部５３から映像（音）データ〔Ａ〕を取得してデコードする（ステップＳ３３）。その後、スピーカ６１は、デコードされた音データ〔Ａ〕に基づいて音を再生すると共に、表示部５８は、レンダリング部５５によってデコード部５０から取得されてレンダリングされた映像データ〔Ａ〕に基づいて映像を再生する（ステップＳ３４）。

＜複数の通信端末を使った複合配信の処理＞
続いて、図１８を用いて、配信制御システムを介して複数の通信端末を使った通信の処理を説明する。なお、図１８は、配信制御システムを介して複数の通信端末を使った配信の処理を示すシーケンス図である。ここでは、複数の通信端末５として、図６に示されているパターンについて具体的な処理を説明する。なお、ここでも、上述のステップＳ２１〜Ｓ２９と同様のログイン処理及びブラウザ起動等の処理を行うため、上述のステップＳ２９に対応する処理から説明する。

図１８に示されているように、配信制御システム２の送受信部２１は、ウェブサーバ８からコンテンツデータ〔Ａ〕を受信する（ステップＳ４１）。そして、ブラウザ２０は、コンテンツデータ〔Ａ〕をレンダリングすることにより、静止画（音）データとしての各フレームデータを生成して、送信用ＦＩＦＯ２４に出力する（ステップＳ４２）。

一方、通信端末５ｆ１のエンコード部６０が、カメラ６２及びマイク６３から映像（音）データ〔Ｅ〕としてのコンテンツデータの入力を受け付けると（ステップＳ４３）、エンコード部６０はコンテンツデータ〔Ｅ〕をエンコードする（ステップＳ４４）。送受信部５１は、エンコード部６０によってエンコードされたコンテンツデータ〔Ｅ〕を、配信制御システム２の送受信部３１に送信する（ステップＳ４５）。これにより、配信制御システム２の送受信部３１は、コンテンツデータ〔Ｅ〕を受信する。

次に、配信制御システム２のデコード部４０は、送受信部３１によって受信されたコンテンツデータ〔Ｅ〕をデコードして、受信用ＦＩＦＯ３４に出力する（ステップＳ４６）。そして、ブラウザ２０が、受信用ＦＩＦＯ３４に格納されたコンテンツデータ〔Ｅ〕をレンダリングすることにより、静止画（音）データとしてのフレームデータ〔Ｅ〕を生成して、送信用ＦＩＦＯ２４に出力する（ステップＳ４７）。この場合、ブラウザ２０は、既に取得しているコンテンツデータ〔Ａ〕に対して、コンテンツデータ〔Ｅ〕を結合したレイアウトにして出力する。

更に、通信端末５ｆ１の操作部５２が、電子ペンＰ１によるストローク操作の入力を受け付けると（ステップＳ４８）、送受信部５１は、操作部５２によって受け付けられたストローク操作の内容を示す操作データ〔ｐ〕を、配信制御システム２の送受信部３１に送信する（ステップＳ４９）。これにより、配信制御システム２の送受信部３１は、操作データ〔ｐ〕を受信する。そして、ブラウザ管理部２２は、送受信部３１によって受信された操作データ〔ｐ〕をブラウザ２０に出力する。

次に、ブラウザ２０は、操作データ〔ｐ〕をレンダリングすることにより、静止画（音）データとしてのフレームデータ〔ｐ〕を生成して、送信用ＦＩＦＯ２４に出力する（ステップＳ５０）。この場合、ブラウザ２０は、既に取得しているコンテンツデータ（〔Ａ〕，〔Ｅ〕）に対して、操作データ〔ｐ〕を結合したレイアウトにして出力する。

次に、変換部１０が、送信用ＦＩＦＯ２４に格納された静止画（音）データとしての各フレームデータ（〔Ａ〕，〔Ｅ〕，〔ｐ〕）をエンコードすることで、通信端末５ａに配信すべき映像（音）データ（〔Ａ〕，〔Ｅ〕，〔ｐ〕）に変換する（ステップＳ５１）。

次に、送受信部３１は、変換部１０を含むエンコーダブリッジ部３０からエンコード後の映像（音）データ（〔Ａ〕，〔Ｅ〕，〔ｐ〕）を取得し、通信端末５ｆ１の送受信部５１に送信する（ステップＳ５２−１）。これにより、通信端末５ｆ１の送受信部５１は、映像（音）データ（〔Ａ〕，〔Ｅ〕，〔ｐ〕）を受信し、通信端末５ｆ１の再生制御部５３が送受信部５１から映像（音）データ（〔Ａ〕，〔Ｅ〕，〔ｐ〕）を取得する。そして、通信端末５ｆ１では、デコード部５０が再生制御部５３から映像（音）データ（〔Ａ〕，〔Ｅ〕，〔ｐ〕）を取得してデコードする（ステップＳ５３−１）。その後、スピーカ６１は、デコードされた音データ（〔Ａ〕，〔Ｅ〕）に基づいて音を再生すると共に、表示部５８は、レンダリング部５５によってデコード部５０から取得されてレンダリングされた映像データ（〔Ａ〕，〔Ｅ〕，〔ｐ〕に基づいて映像を再生する（ステップＳ５４−１）。

また、通信端末５ｆ２に対しても、ステップＳ５２−１と同様に、送受信部３１は、エンコーダブリッジ部３０からエンコード後の映像（音）データ（〔Ａ〕，〔Ｅ〕，〔ｐ〕）を取得し、通信端末５ｆ２の送受信部５１に送信する（ステップＳ５２−２）。これにより、通信端末５ｆ２の再生制御部５３が映像（音）データ（〔Ａ〕，〔Ｅ〕，〔ｐ〕）を取得する。そして、通信端末５ｆ１では、デコード部５０が再生制御部５３から映像（音）データ（〔Ａ〕，〔Ｅ〕，〔ｐ〕）を取得してデコードする（ステップＳ５３−２）。その後、スピーカ６１は、デコードされた音データ（〔Ａ〕，〔Ｅ〕）に基づいて音を再生すると共に、表示部５８は、レンダリング部５５によってデコード部５０から取得されてレンダリングされた映像データ（〔Ａ〕，〔Ｅ〕，〔ｐ〕に基づいて映像を再生する（ステップＳ５４−２）。

以上より、通信端末５ｆ１で出力される映像（音）と同じ映像（音）が、通信端末５ｆ２でも出力されることになる。

＜時刻調整の処理＞
続いて、図１９を用いて、時刻調整の処理について説明する。なお、図１９は、時刻調整の処理を示したシーケンス図である。

まず、通信端末５の時刻制御部５６は、送受信部５１が配信制御システム２に時刻情報（Ｔ）を要求する時点を示す時刻を取得するために、記憶部５０００から通信端末５における時刻情報（ｔ_ｓ）を取得する（ステップＳ８１）。そして、送受信部５１は送受信部３１に、配信制御システム２における時刻情報（Ｔ）を要求する（ステップＳ８２）。この場合、時刻情報（Ｔ）の要求と共に、上記時刻情報（ｔ_ｓ）が送信される。

次に、配信制御システム２の時刻取得部２６は、送受信部３１が上記ステップＳ８２の要求を受信した時点を示す時刻を取得するために、時刻管理部２５から配信制御システム２における時刻情報（Ｔ_ｒ）を取得する（ステップＳ８３）。更に、時刻取得部２６は、送受信部３１が上記ステップＳ８２の要求に応答する時点を示す時刻を取得するために、時刻管理部２５から配信制御システム２における時刻情報（Ｔ_ｓ）を取得する（ステップＳ８４）。そして、送受信部３１は送受信部５１に、時刻情報（ｔ_ｓ, Ｔ_ｒ，Ｔ_ｓ）を送信する（ステップＳ８５）。

次に、通信端末５の時刻制御部５６は、送受信部５１が上記ステップＳ８５の応答を受信した時点を示す時刻を取得するために、記憶部５０００から通信端末５における時刻情報（ｔ_ｒ）を取得する（ステップＳ８６）。

そして、通信端末５の時刻制御部５６は、配信制御システム２と通信端末５との間の時刻差Δを計算する（ステップＳ８７）。この時刻差Δは、以下の式１によって表される。

Δ＝（（Ｔ_ｒ＋Ｔ_ｓ）／２）−（（ｔ_ｒ＋ｔ_ｓ）／２）・・・（式１）
そして、時刻制御部５６は、記憶部５０００に時刻差Δを示す時刻差情報（Δ）を記憶する（ステップＳ８８）。この時刻調整の一連の処理は、例えば、毎分定期的に行われる。

＜下り用の回線適応制御の処理＞
続いて、図２０を用いて、配信制御システム２から通信端末５に送信する（下り）データの回線適応制御の処理を説明する。なお、図２０は、配信制御システムから通信端末に送信するデータの回線適応制御の処理を示したシーケンス図である。

まず、配信制御システム２の回線適応制御部２７は、通信端末５の再生制御部５３が映像（音）データを再生させるまでにバッファリングすることで、再生を遅延させるための再生遅延時間Ｕを示す再生遅延時間情報（Ｕ）を計算して、エンコーダブリッジ部３０に出力する（ステップＳ１０１）。

次に、送受信部３１は、エンコーダブリッジ部３０から再生遅延時間情報（Ｕ）を取得し、通信端末５の送受信部５１に再生遅延時間情報（Ｕ）を送信する（ステップＳ１０２）。これにより、通信端末５の送受信部５１は、再生遅延時間情報（Ｕ）を受信する。また、エンコーダブリッジ部３０は、送信用ＦＩＦＯ２４から取得してエンコード等を行った映像（音）データ〔Ａ〕に対して、時刻管理部２５から取得した時点を示す時刻Ｔ_０を示す時刻情報（Ｔ_０）をタイムスタンプとして付加する（ステップＳ１０３）。そして、送受信部３１は、通信端末５の送受信部５１に、映像（音）データ及び配信制御システム２の時刻情報（Ｔ_０）を送信する（ステップＳ１０４）。これにより、通信端末５の送受信部５１は、映像（音）データ及び配信制御システム２の時刻情報（Ｔ_０）を受信し、再生制御部５３に映像（音）データ及び時刻情報（Ｔ_０）を出力する。

次に、通信端末５では、再生制御部５３が、上記ステップＳ１０２によって取得した再生遅延時間情報（Ｕ）、上記ステップＳ１０４によって取得した時刻情報（Ｔ_０）、及び上記ステップＳ８８によって記憶部５０００に記憶した時刻差情報（Δ）に基づき、通信端末５における時刻（Ｔ_０＋Ｕ−Δ）になるまで待ってから、上記ステップＳ１０４によって取得した映像（音）データをデコード部５０に出力することで、スピーカ６１から音を再生させ、レンダリング部５５を介して表示部５８から映像を再生させる（ステップＳ１０５）。これにより、以下の式２に示される再生遅延時間Ｕの範囲内に通信端末５が受信した映像（音）データだけが再生されることになり、範囲外の映像（音）データは遅延しすぎるため、再生されずに消去される。

Ｕ≧（ｔ_０＋Δ）−Ｔ_０・・・（式２）
また、再生制御部５３は、記憶部５０００から、通信端末５における現時点の時刻ｔ_０を読み出す（ステップＳ１０６）。この時刻ｔ_０は、通信端末５が配信制御システム２から映像（音）データを受信した時点の通信端末５における時刻を示す。更に、再生制御部５３は、記憶部５０００から、上記ステップＳ８８によって記憶されている時刻差Δを示す時刻差情報（Δ）を読み出す（ステップＳ１０７）。そして、再生制御部５３は、映像（音）データが配信制御システム２から送信されて通信端末５で受信されるまでの時間を示す送信遅延時間Ｄ１を計算する（ステップＳ１０８）。この計算は、以下の式３によって行われ、通信ネットワーク９が混雑している場合には、送信遅延時間Ｄ１が長くなる。

Ｄ１＝（ｔ_０＋Δ）−Ｔ_０・・・（式３）
次に、遅延情報取得部５７は、再生制御部５３から送信遅延時間Ｄ１を示す送信遅延時間情報（Ｄ１）を取得して一定時間保持しておき、複数の送信遅延時間情報（Ｄ１）を取得したところで、複数の送信遅延時間Ｄ１による度数分布情報を示す送信遅延時間情報（Ｄ）を、送受信部５１に出力する(ステップＳ１０９)。そして、送受信部５１は、配信制御システム２の送受信部３１に、送信遅延時間情報（Ｄ）を送信する（ステップＳ１１０）。これにより、配信制御システム２の送受信部３１は、送信遅延時間情報（Ｄ）を受信して、回線適応制御部２７に送信遅延時間情報（Ｄ）を出力する。

次に、配信制御システム２の回線適応制御部２７は、送信遅延時間情報（Ｄ）に基づいて、新たに再生遅延情報Ｕ’を計算したり、変換部１０のフレームレートやデータの解像度等の動作条件を計算したりして、エンコーダブリッジ部３０に出力する（ステップＳ１１１）。即ち、回線適応制御部２７は、送信遅延時間情報（Ｄ）及びデータのサイズ（ビット数、バイト数等）に基づき、エンコーダブリジ部３０の動作を変更させる。

次に、送受信部３１は、エンコーダブリッジ部３０から、上記ステップＳ１１１によって計算された新たな再生遅延時間Ｕ’を示す再生遅延時間情報（Ｕ’）を取得し、通信端末５の送受信部５１に再生遅延時間情報（Ｕ’）を送信する（ステップＳ１１２）。これにより、通信端末５の送受信部５１は、再生遅延時間情報（Ｕ’）を受信する。

更に、エンコードブリッジ部３０における変換部１０は、動作条件を示す回線適応制御信号に基づいて、変換部１０の動作条件を変更する（ステップＳ１１３）。例えば、送信遅延時間Ｄ１が長すぎる場合、送信遅延時間Ｄ１に応じて再生遅延時間Ｕを長くすると、スピーカ６１や表示部５８での再生時間が遅くなり過ぎるため、再生遅延時間Ｕを長くすることには限界がある。そこで、回線適応制御部２７は、エンコーダブリッジ部３０に対して、再生遅延時間Ｕを変更させて再生遅延時間Ｕ’とするだけでなく、変換部１０に対して、映像（音）データのフレームレートを下げさせたり、映像（音）データの解像度を下げさせたりすることで、通信ネットワーク９の混雑に対応する。これにより、エンコーダブリッジ部３０は、変更後の動作条件に従って、上記ステップＳ１０３のように、映像（音）データ〔Ａ〕に対して、現時点の時刻情報（Ｔ_０）をタイムスタンプとして付加する（ステップＳ１０４）。そして、映像（音）データ付加する（ステップＳ１１４）。そして、送受信部３１は、通信端末５の送受信部５１に、映像（音）データ及び配信制御システム２の時刻情報（Ｔ_０）を送信する（ステップＳ１１５）。これにより、通信端末５の送受信部５１は、映像（音）データ及び配信制御システム２の時刻情報（Ｔ_０）を受信し、再生制御部５３に映像（音）データ及び時刻情報（Ｔ_０）を出力する。

次に、通信端末５では、再生制御部５３が、上記ステップＳ１１２によって取得した再生遅延時間情報（Ｕ’）、上記ステップＳ１１５によって取得した時刻情報（Ｔ_０）、及び上記ステップＳ８８によって記憶部５０００に記憶した時刻差情報（Δ）に基づき、通信端末５における時刻（Ｔ_０＋Ｕ’−Δ）になるまで待ってから、映像（音）データをデコード部５０に出力することで、上記ステップＳ１０５のように、スピーカ６１から音を再生させ、レンダリング部５５を介して表示部５８から映像を再生させる（ステップＳ１１６）。その後、上記ステップＳ１０６以降の処理が続けて行われる。このようにして、下り用の回線適応制御の処理が継続して行われる。

＜上り用の回線適応制御の処理＞
続いて、図２１を用いて、通信端末５から配信制御システム２に送信する（上り）データの回線適応制御の処理を説明する。なお、図２０は、通信端末から配信制御システムに送信するデータの回線適応制御の処理を示したシーケンス図である。

まず、通信端末５のエンコード部６０は、カメラ６２及びマイク６３から入力された映像（音）データ〔Ｅ〕としてのコンテンツデータをエンコードする（ステップＳ１２１）。この際、エンコード部６０は、記憶部５０００から、現時点の通信端末５における時刻ｔ_０を示す時刻情報（ｔ_０）及び時刻差Δを示す時刻差情報（Δ）を取得するが、これらに対しては、エンコードを行わない。そして、送受信部５１は、配信制御システム２の送受信部３１に、映像（音）データ〔Ｅ〕、時刻情報（ｔ_０）、及び時刻差情報（Δ）を送信する（ステップＳ１２２）。これにより、配信制御システム２の送受信部３１は、映像（音）データ〔Ｅ〕、時刻情報（ｔ_０）、及び時刻差情報（Δ）を受信する。

次に、配信制御システム２では、デコード部４０が上記ステップＳ１２２によって映像（音）データ〔Ｅ〕等を受信した時点を示す時刻Ｔ_０を時刻管理部２５から読み出す(ステップＳ１２３)。そして、デコード部４０は、映像（音）データが通信端末５から送信されて配信制御システム２で受信されるまでの時間を示す送信遅延時間ｄ１を計算する（ステップＳ１２４）。この計算は、以下の式４によって行われ、通信ネットワーク９が混雑している場合には、送信遅延時間ｄ１が長くなる。

ｄ１＝Ｔ_０−（ｔ_０＋Δ）・・・（式４）
次に、配信制御システム２の遅延情報取得部３７ａは、遅延情報取得部５７と同様に、デコード部４０から送信遅延時間ｄ１を示す送信遅延時間情報（ｄ１）を取得して一定時間保持しておき、複数の送信遅延時間情報（ｄ１）を取得したところで、回線適応制御部３７ｂに、複数の送信遅延時間ｄ１による度数分布情報を示す送信遅延時間情報（ｄ）を出力する（ステップＳ１２５）。

次に、回線適応制御部３７ｂは、送信遅延時間情報（ｄ）に基づいて、エンコード部６０の動作条件を計算する（ステップＳ１２６）。そして、送受信部３１は、通信端末５の送受信部５１に、フレームレートやデータの解像度等の動作条件を示す回線適応制御信号を送信する（ステップＳ１２７）。これにより、通信端末５の送受信部５１は、回線適応制御信号を受信する。即ち、図２０に示されている回線適応制御の場合（下り）は、同じ配信制御システム２内でエンコーダブリッジ部３０に回線適応制御信号が出力されるのに対して、図２１に示されている回線適応制御の場合（上り）は、配信制御システム２から通信ネットワーク９を介して、通信端末５に回線適応制御信号が送信される。

次に、エンコード部６０は、送受信部５１によって受信された回線適応制御信号で示される動作条件に基づいて、エンコード部６０の動作条件を変更する（ステップＳ１２８）。そして、エンコード部６０は、新たな動作条件によって、上記ステップＳ１２１と同様の処理を行う（ステップＳ１２９）。そして、送受信部５１は、配信制御システム２の送受信部３１に対して、上記ステップＳ１２２のように、カメラ６２及びマイク６３から取得してエンコードした映像（音）データ〔Ｅ〕と、記憶部５０００から取得した現時点の通信端末５における時刻ｔ_０を示す時刻情報（ｔ_０）と、同じく記憶部５０００から取得した時刻差Δを示す時刻差情報（Δ）とを送信する（ステップＳ１３０）。これにより、配信制御システム２の送受信部３１は、映像（音）データ〔Ｅ〕、時刻情報（ｔ_０）、及び時刻差情報（Δ）を受信する。その後、上記ステップＳ１２３以降の処理が続けて行われる。このようにして、上り用の回線適応制御の処理が継続して行われる。

＜マルチディスプレイの処理＞
続いて、図２２乃至図２４を用いて、マルチディスプレイの処理について説明する。なお、図２２乃至図２４は、図５に示されているマルチディスプレイの処理を示したシーケンス図である。

ここでは、通信端末５ａで再生されている映像（音）〔ＸＹＺ〕を、各通信端末（５ｆ１，５ｆ２，５ｆ３）にも分割して再生させる例である。

また、ここでは、ウェブコンテンツを表示させるためのブラウザ２０を「ブラウザ２０ａ」と示し、ユーザへの設定画面を表示させるためのブラウザ２０を「ブラウザ２０ｂ」と示す。更に、ここでは、図１７のステップＳ３０に相当する処理から説明する。

まず、配信制御システム２のブラウザ２０ａは、ウェブサーバ８から取得したウェブコンテンツデータ〔ＸＹＺ〕をレンダリングすることにより、静止画（音）データとしての各フレームデータを生成し、送信用ＦＩＦＯ２４に出力する（ステップＳ２０１）。そして、変換部１０が、送信用ＦＩＦＯ２４に格納された各フレームデータをエンコードすることで、通信端末５ａに配信可能なデータ形式の映像（音）データ〔ＸＹＺ〕に変換する
（ステップＳ２０２）。

次に、送受信部３１は、通信端末５ａの送受信部５１に、上記変換部１０によって変換された後の映像（音）データ〔ＸＹＺ〕を送信する（ステップＳ２０３）。これにより、通信端末５ａの送受信部５１は、映像（音）データ〔ＸＹＺ〕を受信して、再生制御部５３に出力する。

次に、通信端末５ａでは、デコード部５０が再生制御部５３から映像（音）データ〔ＸＹＺ〕を取得してデコードする（ステップＳ２０４）。その後、スピーカ６１は、デコードされた音データ〔ＸＹＺ〕に基づいて音を再生すると共に、表示部５８は、レンダリング部５５によってデコード部５０から取得されてレンダリングされた映像データ〔ＸＹＺ〕に基づいて映像を再生する（ステップＳ２０５）。

次に、通信端末５ａのユーザによって、表示部５８上に表示されている画面が不図示のメニュー要求画面に切り替えられ、操作部５２が、メニュー要求画面中の不図示の「配信先選択メニュー」ボタンの押下を受け付ける（ステップＳ２０６）。これにより、送受信部５１が、端末管理システム７の送受信部７１ａに、配信先選択メニューへの切り替え要求を送信する（ステップＳ２０７）。これにより、端末管理システム７の送受信部７１ａは、配信先選択メニューへの切り替え要求を受信する。この要求には、通信端末５ａの端末ＩＤが含まれている。

次に、送受信部７１ｂは、配信制御システム２の送受信部２１に、ブラウザ２０ｂの起動要求を送信する（ステップＳ２０８）。これにより、配信制御システム２の送受信部２１は、ブラウザ２０ｂの起動要求を受信し、ブラウザ管理部２２に対して、ブラウザ２０ｂの起動要求を行う。

次に、ブラウザ管理部２２は、ブラウザ２０ｂを起動させる（ステップＳ２０９）。そして、エンコーダブリッジ部３０の作成・選択・転送部３１０は、ブラウザ２０ａから変換部１０（例えば、変換部１０ａ）への出力を、ブラウザ２０ｂから変換部１０（例えば、変換部１０ｂ）への出力に切り替える（ステップＳ２１０）。但し、通信端末５ａが他の通信端末５（例えば、通信端末５ｂ）と変換部１０（例えば、変換部１０ａ）を共有して上記ステップＳ２０３による映像（音）データを受信していた場合には、他の通信端末５（例えば、通信端末５ｂ）はブラウザ２０ａ用に変換部１０（例えば、変換部１０ａ）を利用中であるため、エンコーダブリッジ部３０の作成・選択・転送部３１０は、新たに変換部１０（例えば、変換部１０ｂ）を作成する。

そして、送受信部２１は、ブラウザ２０ｂの命令に従って、端末管理システム７の送受信部７１ｂに、配信先選択メニュー要求を送信する（ステップＳ２１１）。この際に、通信端末５ａの端末ＩＤも送信される。これにより、端末管理システム７の送受信部７１ｂは、配信先選択メニュー要求を受信し、記憶部７０００に通信端末５ａの端末ＩＤを出力する。

これに対して、端末管理システム７の記憶部７０００は、この端末ＩＤに基づいて利用可能端末管理テーブル７０２０を検索することにより、対応する共有ＩＤを抽出する（ステップＳ２１２）。この共有ＩＤは、通信端末５ａが遠隔共通処理をするために利用可能な通信端末５を示している。ここでは、図１４に示されているように、通信端末５ａの端末ＩＤが「ｔ００１」であるため、抽出される共有ＩＤは「ｖ００３」、「ｖ００６」である。

更に、記憶部７０００は、抽出した共有ＩＤに基づいて端末管理テーブル７０１０を検索することにより、対応する表示名を示す表示名情報を抽出する（ステップＳ２１３）。ここでは、図１３に示されているように、抽出された共有ＩＤ「ｖ００３」、「ｖ００６」に対応する表示名は、それぞれ「東京本社１０Ｆ ＭＦＰ」、「大阪展示場１Ｆ マルチディスプレイ」である。

そして、送受信部７１ｂは、配信制御システム２の送受信部２１に、コンテンツデータとしての配信先選択メニューデータ〔Ｍ〕を送信する（ステップＳ２１４）。これにより、配信制御システム２の送受信部２１は、配信先選択メニューデータ〔Ｍ〕を受信し、ブラウザ２０ｂに出力する。この配信先選択メニュー〔Ｍ〕は、図１２に示されているように、チェックボックス、共有ＩＤ、及び表示名が含まれている。

次に、図２３に示されているように、ブラウザ２０ｂが、端末管理システム７から取得した配信先選択メニュー〔Ｍ〕を示すコンテンツデータをレンダリングすることによって、静止画（音）データとしての各フレームデータを生成し、送信用ＦＩＦＯ２４に出力する（ステップＳ２２１）。そして、変換部１０が、送信用ＦＩＦＯ２４に格納された画像（音）データ〔Ｍ〕をエンコードすることで、通信端末５ａに配信可能なデータ形式の映像（音）データ〔Ｍ〕に変換する（ステップＳ２２２）。

次に、送受信部３１は、通信端末５ａの送受信部５１に、上記変換部１０によって変換された後の映像（音）データ〔Ｍ〕を送信する（ステップＳ２２３）。これにより、通信端末５ａの送受信部５１は、映像（音）データ〔Ｍ〕を受信して、再生制御部５３に出力する。

次に、通信端末５ａでは、デコード部５０が再生制御部５３から映像（音）データ〔Ｍ〕を取得してデコードする（ステップＳ２２４）。その後、表示部５８は、レンダリング部５５によってデコード部５０から取得されてレンダリングされた映像データ〔ＸＹＺ〕に基づいて、図１２に示されているような映像を再生する（ステップＳ２２５）。

次に、図１２に示されている配信先選択メニューにおいて、ユーザにより共有ＩＤ「ｖ００６」のチェックボックスにチェックが入れられ、「ＯＫ」ボタンが押下されると、操作部５２が、ユーザの操作入力を受け付ける（ステップＳ２２６）。

次に、送受信部５１は、配信制御システム２の送受信部３１に、操作データとしてチェック結果を送信する（ステップＳ２２７）。これにより、配信制御システム２の送受信部３１は、操作データとしてチェック結果を受信し、ブラウザ２０ｂに出力する。

次に、ブラウザ２０ｂは、チェック結果から共有ＩＤを選択する（ステップＳ２２８）。そして、送受信部２１は、ブラウザ２０ｂの命令に従って、端末管理システム７の送受信部７１ｂに、配信先追加要求を送信する（ステップＳ２２９）。この配信先追加要求には、上記ステップＳ２２７によって選択された共有ＩＤが含まれている。これにより、端末管理システム７の送受信部７１ｂは、配信先追加要求を受信し、記憶部７０００に共有ＩＤを出力する。そして、ブラウザ２０ｂは、役目を終えて終了する（ステップＳ２３０）。これにより、エンコーダブリッジ部３０の作成・選択・転送部３１０は、ブラウザ２０ｂから変換部１０への出力を、ブラウザ２０ａから変換部１０への出力に戻すよう切り替える（ステップＳ２３１）。

次に、図２４に示されているように、端末管理システム７の記憶部７０００では、上記ステップＳ２２９によって送られて来た共有ＩＤに基づいて、端末管理テーブル７０１０を検索することにより、対応する端末ＩＤ及び設置位置情報を抽出する（ステップＳ２４１）。そして、送受信部７１ｂは、配信制御システム２の送受信部２１に、配信先の追加指示を送信する(ステップＳ２４２)。この配信先の追加指示には、上記ステップＳ２４１によって抽出された端末ＩＤ及び設置位置情報が含まれている。これにより、配信制御システム２の送受信部２１は、配信先の追加指示を受信し、ブラウザ管理部２２に配信先の追加指示を出力する。ここでは、端末ＩＤ及び設置位置情報が「ｔ００６」、「左」と、端末ＩＤ及び設置位置情報が「ｔ００７」、「中」と、端末ＩＤ及び設置位置情報が「ｔ００８」、「右」との３組の端末ＩＤ及び設置位置情報が含まれている。

次に、エンコーダブリッジ部３０の作成・選択・転送部３１０は、マルチディスプレイ用の変換部１０を作成する（ステップＳ２４３）。なお、この場合、エンコーダブリッジ部３０の作成・選択・転送部３１０は、ブラウザ管理部２２から、端末ＩＤ及び設置位置情報を取得する。

そして、上記ステップＳ２４３によって作成された変換部１０の分割部１３が、送信用ＦＩＦＯ２４に格納されている静止画（音）データとしての各フレームデータ〔ＸＹＺ〕を分割し、エンコード部１９が、分割された各フレームデータをエンコードする（ステップＳ２４４）。

そして、送受信部３１は、エンコーダブリッジ部３０によってエンコードされた映像（音）データ〔Ｘ〕を、端末ＩＤ（「ｔ００６」）及び設置位置情報（「左」）に基づいて、通信端末５ｆ１の送受信部５１に送信する（ステップＳ２４５−１）。これにより、通信端末５ｆ１の送受信部５１は、映像（音）データ〔Ｘ〕を受信して、再生制御部５３に出力する。

次に、通信端末５ｆ１では、デコード部５０が再生制御部５３から映像（音）データ〔Ｘ〕を取得してデコードする（ステップＳ２４６−１）。その後、スピーカ６１は、デコードされた音データ〔Ｘ〕に基づいて音を再生すると共に、表示部５８は、レンダリング部５５によってデコード部５０から取得されてレンダリングされた映像データ〔Ｘ〕に基づいて映像を再生する（ステップＳ２４７−１）。

また、同様にして、送受信部３１は、エンコーダブリッジ部３０によってエンコードされた映像（音）データ〔Ｙ〕を、端末ＩＤ（「ｔ００７」）及び設置位置情報（「中」）に基づいて、通信端末５ｆ２の送受信部５１に送信する（ステップＳ２４５−２）。これにより、通信端末５ｆ２の送受信部５１は、映像（音）データ〔Ｙ〕を受信して、再生制御部５３に出力する。

次に、通信端末５ｆ２では、デコード部５０が再生制御部５３から映像（音）データ〔Ｙ〕を取得してデコードする（ステップＳ２４６−２）。その後、スピーカ６１は、デコードされた音データ〔Ｙ〕に基づいて音を再生すると共に、表示部５８は、レンダリング部５５によってデコード部５０から取得されてレンダリングされた映像データ〔Ｙ〕に基づいて映像を再生する（ステップＳ２４７−２）。

更に、同様にして、送受信部３１は、エンコーダブリッジ部３０によってエンコードされた映像（音）データ「Ｚ」を、端末ＩＤ（「ｔ００８」）及び設置位置情報（「右」）に基づいて、通信端末５ｆ３の送受信部５１に送信する（ステップＳ２３５−３）。これにより、通信端末５ｆ３の送受信部５１は、映像（音）データ〔Ｚ〕を受信して、再生制御部５３に出力する。

次に、通信端末５ｆ３では、デコード部５０が再生制御部５３から映像（音）データ〔Ｚ〕を取得してデコードする（ステップＳ２４６−３）。その後、スピーカ６１は、デコードされた音データ〔Ｚ〕に基づいて音を再生すると共に、表示部５８は、レンダリング部５５によってデコード部５０から取得されてレンダリングされた映像データ〔Ｚ〕に基づいて映像を再生する（ステップＳ２４７−３）。

＜各種フレームデータを生成する処理＞
続いて、図２５乃至図２７を用いて、各種フレームデータを生成する処理を説明する。なお、図２５は、各種フレームデータの概念図である。本実施形態では、４種類のフレームデータが生成される。４種類のフレームデータは、「定期的に生成されるＩフレームデータ」及び「Ｐフレームデータ」、並びに、「スキップフレームデータ」及び「強制的に生成されるＩフレームデータ」である。なお、「定期的に生成されるＩフレームデータ」を以下「定期Ｉフレームデータ」と示し、「強制的に生成されるＩフレームデータ」を以下「強制Ｉフレームデータ」と示す。また、定期Ｉフレームデータは第１の変換フレームデータの一例、Ｐフレームデータは第２の変換フレームデータの一例、強制Ｉフレームデータは第３の変換フレームデータの一例、スキップフレームデータは第４の変換フレームデータの一例である。

まず、公知技術である定期Ｉフレームデータ及びＰフレームデータの生成について説明する。一般に、映像データを通信ネットワーク上で効率よく送信するため、ビデオ圧縮技術により、不要なデータを減らしたり取り除いたりしている。このビデオ圧縮技術では、エンコーダが映像データ内の各フレームデータをエンコードして、定期Ｉフレームデータ又はＰフレームデータを生成する。

このうち、定期Ｉフレーム（Intra Frame）データは、通信端末が、他の画像を参照せずに独立して（単独で）デコードすることで再生可能なフレームデータである。図２５に示されているように、映像データの最初の画像は常に定期Ｉフレームデータになる。ここでは、説明を簡単にするために、１つの定期Ｉフレーム及び４つのＰフレームの配信が繰り返されている場合を示している。具体的には、エンコード部１９は、映像データを構成する定期ＩフレームデータＭ１を生成した後に、映像データを構成する４つのＰフレームデータ（Ｍ１１，Ｍ１２，Ｍ１３，Ｍ１４）を順次生成し、続いて、映像データを構成する定期ＩフレームデータＭ２を生成した後に、映像データを構成するＰフレームデータ（Ｍ２１，Ｍ２２，Ｍ２３，Ｍ２４）を順次生成するというように、定期Ｉフレームデータ及びＰフレームデータの生成を繰り返す。

また、定期Ｉフレームデータは、映像データを閲覧する新規ユーザの開始地点、また伝送中のビットストリームに問題が発生したときの再同期位置、さらに早送りや巻き戻し、ランダムアクセス機能の実装に利用される。エンコード部１９は、一定の間隔で自動的に定期Ｉフレームを生成したり、また、映像データを閲覧するユーザが新しく加わったりした時などに、必要に応じて定期Ｉフレームデータを生成する。定期Ｉフレームデータは、差分データではないため、より多くのビット数を必要とする（データ容量が大きい）という欠点があるが、データの欠落によるノイズなどが発生しないという利点がある。

一方、Ｐフレーム(Predictive Inter Frame）データは、前回のフレームデータとの差分である差分データによって構成されており、エンコード部１９が、前回の定期Ｉフレームデータ又はＰフレームデータの一部を参照してエンコードするフレームデータである。Ｐフレームデータは定期Ｉフレームデータよりも必要とするビット数が少なくなるという利点があるが、前回のＰフレームデータ又は定期Ｉフレームデータと複雑な依存関係にあるため、配信エラーによる影響を受けやすくなるという欠点がある。映像データの配信には、データが高速転送かつ低品質となるＵＤＰ(User Datagram Protocol)が使われているため、通信ネットワーク上でフレームデータが消失する可能性がある。この場合、今回のＰフレームデータは、消失した前回のＰフレームデータの影響により、ユーザ側（通信端末５側）に配信される映像データが崩壊してしまい、配信エラーによる影響を受けることになる。しかし、定期的に挿入される定期Ｉフレームデータにより、再び映像データの崩壊が解消する。

続いて、本実施形態に特有のスキップフレームデータ及び強制Ｉフレームデータの生成について説明する。

上述の如く、Ｐフレームデータは、前回のフレームデータ（Ｐフレームデータ又は強制Ｉフレームデータ）との差分データであるため、前回に対して更新された部分がなければ、エンコード部１９が実行する差分計算は無駄になってしまう。

一方、定期Ｉフレームデータは、エンコード部１９によって差分計算されないが、エンコードのための圧縮計算が行なわれる。また、このエンコードによって生成された定期Ｉフレームデータのデータ容量は、Ｐフレームデータに比べて大きい。そのため、定期Ｉフレームデータは、前回に対して更新された部分がなければ、圧縮計算は無駄になり、しかも定期Ｉフレームデータはデータ容量が大きいために配信制御システム内のバスライン２２０上の転送時間も遅くなってしまう。

例えば、図２５では、Ｐフレームデータ（Ｍ２２，Ｍ２３，Ｍ２４）、定期ＩフレームデータＭ３およびＰフレームデータＭ３１は連続して更新（変化）されていない状態である。この状態では、エンコード部１９が差分計算または圧縮計算する処理が無駄となっている。

そこで、本実施形態では、ブラウザ２０から送信用ＦＩＦＯ２４に送られるフレームデータが更新されない回数が第１閾値以上の場合には、エンコード部１９は、定期Ｉフレームデータ又はＰフレームデータに代えて、スキップフレームデータを生成する。なお、第１閾値は、通信ネットワーク９のトラフィック及び品質等の状態、並びに配信制御システム２のリソースの負荷等に応じて任意の値に決定してよい。

スキップフレームデータは、直前のフレームデータに比べて更新（変化）がないことを示すフレームデータである。例えば、図２５に示されているように、第１閾値が５の場合、５回フレームデータの内容に変更がなければ、６回目のフレームデータは、ＰフレームデータＭ３２からスキップデータｍ３２に代えて生成される。その後も更新されない状態が続くと、７回目のフレームデータは、ＰフレームデータＭ３３からスキップデータｍ３３に代えて生成される等、更新が再開されるまでスキップフレームデータが生成される。

Ｐフレームの生成及び送信処理は、スキップフレームの生成及び送信処理と比較して負荷が大きいため、Ｐフレームを連続して処理していると、処理が滞る可能性がある。スキップフレームの生成及び送信処理は負荷が小さいので、フレームデータが更新されない回数が第１閾値以上の場合、スキップフレームの生成及び送信処理を行うことにより、配信制御システム２でフレームデータの処理が滞るという事態を回避することができる。そのため、配信制御システム２はウェブサーバ８等から取得したコンテンツデータを、より迅速に映像データとして通信端末５に配信することができる。

更に、本実施形態では、エンコード部１９は、スキップフレームデータが生成される直前のフレームデータに代えて、強制Ｉフレームデータを生成する。

強制Ｉフレームデータは、静止画データであり、映像データを構成する定期Ｉフレームデータよりも低圧縮（高画質）のフレームデータである。強制Ｉフレームデータは、定期Ｉフレームデータよりも低圧縮（高画質）のフレームデータなので、分割することにより１フレームデータのデータサイズを抑える。

図２６は、分割数が２である場合の強制Ｉフレームデータの概念図である。図２６の例は、強制ＩフレームデータＳ３を、強制ＩフレームデータＳ３−１及びＳ３−２に分割する場合の例である。強制ＩフレームデータＳ３には、強制ＩフレームデータＳ３のデータサイズ情報（DataSize）等がヘッダ情報として付与されている。分割された強制ＩフレームデータＳ３−１及びＳ３−２のヘッダ情報は、更にフラグ情報(Next)を含む。フラグ情報は、分割された強制Ｉフレームデータの終端を示す。即ち、フラグ情報がNext=trueの場合、分割された強制Ｉフレームデータがまだ終端でないことを示し、フラグ情報がNext=falseの場合、分割された強制Ｉフレームデータの終端を示す。送受信部３１は、分割された強制Ｉフレームデータをフレームレート間隔で１つずつ通信端末５に送信する。フレームレート間隔は、例えば３０ｆｐｓの場合、３３ｍｓである。

図２６は、強制ＩフレームデータＳ３を、強制ＩフレームデータＳ３−１及びＳ３−２に分割する場合の例なので、強制ＩフレームデータＳ３−１のフラグ情報は、Next=trueに設定されている。また、強制ＩフレームデータＳ３−２のフラグ情報は、Next=falseに設定されている。通信端末５の送受信部５１は、分割された強制フレームデータを全部受信すると、分割された強制フレームデータを一の強制フレームデータに統合する。そして、送受信部５１は、一の強制フレームデータを再生制御部５３に入力する。

なお、強制ＩフレームデータＳ３の分割数は２に限らず２以上の任意の整数でよい。また、強制ＩフレームデータＳ３の分割数を、通信ネットワーク９のトラフィック及び品質等の状態、並びに配信制御システム２のリソースの負荷等に応じて変動させてもよい。また、通信ネットワーク９のトラフィック及び品質等の状態、並びに配信制御システム２のリソースの負荷等に余裕がある場合、強制ＩフレームデータＳ３を分割しないようにしてもよい。通信端末５は、強制Ｉフレームデータの分割数を、強制Ｉフレームデータのヘッダ情報のフラグ情報(Next)を参照することにより判定することができる。なお、強制フレームデータの分割数を通信端末５に通知する方法は任意でよい。配信制御システム２は、例えば強制フレームデータとは独立に、分割数を示す情報を送信することにより通信端末５に分割数を通知してもよい。

図２５の説明に戻る。例えば、図２５に示されているようにＰフレームデータＭ２２、ＰフレームデータＭ２３、ＰフレームデータＭ２４、定期ＩフレームデータＭ３、ＰフレームデータＭ３１として送信される映像データのフレームデータに変更がなく、第１閾値が５の場合、ＰフレームデータＭ３１が、強制ＩフレームデータＳ３−１に代えられて、エンコード部１９により生成される。更に、ＰフレームデータＭ３２が、強制ＩフレームデータＳ３−２に代えられて、エンコード部１９により生成される。更に、ＰフレームデータＭ３３が、スキップフレームデータｍ３３に代えられて、エンコード部１９により生成される。

なお、例えば、第１閾値が４である場合、定期ＩフレームデータＭ３が、強制ＩフレームデータＳ３−１に代えられて、エンコード部１９により生成される。更に、ＰフレームデータＭ３１が、強制ＩフレームデータＳ３−２に代えられて、エンコード部１９により生成される。更に、ＰフレームデータＭ３２が、スキップフレームデータｍ３３に代えられて、エンコード部１９により生成される。

これにより、高画質のフレームデータである強制ＩフレームデータＳ３が強制ＩフレームデータＳ３−１及びＳ３−２として分割されて通信端末５に配信されるので、通信ネットワーク９の負荷を下げることができる。具体的には、図２５の例の場合、2フレームを送信していた時間で1フレーム分のデータ（強制ＩフレームデータＳ３−１及びＳ３−２）を送信することで、通信ネットワーク９の負荷を下げることができる。そして、実施形態の配信制御システム２は、スキップフレームデータが送信される前に強制ＩフレームデータＳ３−１及びＳ３−２を送信するので、画像が更新されない状態が続いて、スキップフレームデータが定期的に配信され続けられている場合であっても、通信端末５で高画質の画像を再生することができる。

続いて、図２７を用いて、配信制御システム２が、各種フレームデータを生成する処理について説明する。図２７は、各種フレームデータを生成するためのフローチャートである。まず、ブラウザ２０のレンダラ機能が、送信用ＦＩＦＯ２４にフレームデータを記憶すると共に、フレームデータの内容が更新されたか否かを示す更新フラグを記憶する。更新フラグは、更新情報の一例であり、例えば、更新があった場合は「１」、更新がなかった場合は「０」として表される。なお、ブラウザ２０は、フレームデータの内容が前回生成されたフレームデータの内容に比べて全く更新されなかった場合だけでなく、前回生成されたフレームデータの内容に比べて所定範囲以上更新されていない場合であっても、更新フラグを「０」としてもよい。例えば、通信端末５側で再生される映像の角辺りが更新される程度で、中央部が更新されないような場合には、更新フラグは「０」とされる。

次に、図１５に示されている作成・選択・転送部３１０が、タイマーを開始する（ステップＳ３０１）。このタイマーは、作成・選択・転送部３１０が定期的に図９に示されている送信用ＦＩＦＯ２４からフレームデータを取得するタイミングに利用される。よって、作成・選択・転送部３１０は、次のフレームデータを取得する時間であるかを判断する（ステップＳ３０２）。そして、作成・選択・転送部３１０は、次のフレームデータを取得する時間まで待機する（ステップＳ３０２，Ｎｏ）。次のフレームデータを取得する時間になった場合には（ステップＳ３０２，Ｙｅｓ）、作成・選択・転送部３１０は、ＥＳＣ（Encode Skip Counter）が０以上であるか否かを判定する（ステップＳ３０３）。

ここで、ＥＳＣについて説明する。ＥＳＣはエンコード部１９のエンコード処理をスキップする回数を制御するためのカウンタである。なお、このカウンタの値は、ＧＰＵ２１５側のＲＡＭ２１７に記憶される。ＥＳＣの初期値は０である。ＥＳＣは、エンコード部１９が強制Ｉフレームを生成するときに、エンコード部１９により更新される。強制Ｉフレームの分割数がＮの場合、ＥＳＣはＮ−１に更新される。これは、実施形態の配信制御システム２では、強制Ｉフレームを、Ｎフレーム分の時間を使って送信することになるので、後続のＮ−１フレーム分はエンコード不要だからである。

ＥＳＣが０より大きい場合（ステップＳ３０３，Ｎｏ）、作成・選択・転送部３１０は、ＥＳＣをデクリメント（ESC=ESC-1）する（ステップＳ３０４）。そして、処理はステップＳ３０２に戻る。

ＥＳＣが０以下の場合（ステップＳ３０３，Ｙｅｓ）、作成・選択・転送部３１０は、送信用ＦＩＦＯ２４からフレームデータを取得して、変換部１０に転送する（ステップＳ３０５）。

次に、変換部１０では、トリミング部１１、リサイズ部１２、又は分割部１３が、それぞれフレームデータのトリミング、リサイズ、又は分割等の画像処理を行なう（ステップＳ３０６）。

次に、エンコード部１９は、更新フラグに基づいて、フレームデータに更新があるかを判断する（ステップＳ３０７）。そして、更新フラグ「１」の場合、エンコード部１９は、作成・選択・転送部３１０によって転送されたフレームデータに更新があると判断し（ステップＳ３０７，Ｙｅｓ）、スキップフレームデータを生成するために利用するカウンタ（以下、「ＳＦＣ」という）を０にする(ステップＳ３０８)。なお、このカウンタは、エンコード部１９によって、ＧＰＵ２１５側のＲＡＭ２１７に記憶される。

次に、エンコード部１９は、生成すべきフレームデータの種類を判断する（ステップＳ３０９）。例えば、図２５に示されている場合では、１つの定期Ｉフレームデータが生成される後に、４つのＰフレームデータを生成されることが予め定められている。そして、ステップＳ３０９において、エンコード部１９が定期Ｉフレームデータを生成すると判断した場合には、定期Ｉフレームデータを生成する（ステップＳ３１０）。一方、ステップＳ３０９において、エンコード部１９がＰフレームデータを生成すると判断した場合には、Ｐフレームデータを生成する（ステップＳ３１１）。

また、上記ステップＳ３０７に戻り、更新フラグ「０」の場合、エンコード部１９は、作成・選択・転送部３１０によって転送されたフレームデータに変更がないと判断し（ステップＳ３０７，Ｎｏ）、ＳＦＣを１つ増やすことにより、インクリメントを行なう（ステップＳ３１２）。

次に、エンコード部１９は、ＳＦＣが第１閾値より小さいか否かを判断する（ステップＳ３１３）。即ち、エンコード部１９は、ブラウザ２０から出力されたコンテンツデータの内容の更新が第１閾値以上の回数、続けて行なわれていないか否かを判断する。図２５に示されている場合では、ＳＦＣが５より小さいか否かが判断される。そして、上記ステップＳ３１３において、エンコード部１９は、ＳＦＣが第１閾値より小さいと判断した場合には（ステップＳ３１３，Ｙｅｓ）、上記ステップＳ３０９の処理に進む。一方、上記ステップＳ３１３において、エンコード部１９は、ＳＦＣが第１閾値以上であると判断した場合には（ステップＳ３１３，Ｎｏ）、更に、ＳＦＣが第１閾値と同じ値であるか否かを判断する（ステップＳ３１４）。

そして、上記ステップＳ３１４において、エンコード部１９は、ＳＦＣが第１閾値と同じ値であると判断した場合には（ステップＳ３１４，Ｙｅｓ）、エンコード部１９は、ＥＳＣをＮ−１（Ｎ：分割数）に更新する（ステップＳ３１５）。次に、エンコード部１９は、強制Ｉフレームを生成する（ステップＳ３１６）。次に、送受信部３１は、強制ＩフレームをＮ個に分割し、分割された強制Ｉフレームデータを順番に通信端末５に送信する（ステップＳ３１７）。

一方、上記ステップＳ３１４において、エンコード部１９は、ＳＦＣが第１閾値と同じ値でないと判断した場合には（ステップＳ３１４，Ｎｏ）、スキップフレームデータを生成する（ステップＳ３１８）。

なお、再びコンテンツデータの内容が変更されることで、作成・選択・転送部３１０が送信用ＦＩＦＯから更新フラグ「１」を取得するに至った場合には、再び、エンコード部１９は、定期Ｉフレームデータ又はＰフレームデータを生成する。図２５に示されている場合、エンコード部１９がスキップフレームデータｍ３３を生成した後に、フレームデータの内容が更新された場合には、エンコード部１９はＰフレームデータＭ３４を生成する。この場合、エンコード部１９は、最後に生成した強制Ｉフレームデータとの差分データとしてのＰフレームデータを生成する。また、エンコード部１９がスキップフレームデータｍ３４を生成後、フレームデータの内容が更新された場合には、エンコード部１９は定期ＩフレームデータＭ４を生成する。

〔実施形態の主な効果〕
以上説明したように本実施形態によれば、ブラウザ２０から送信用ＦＩＦＯ２４に送られるフレームデータが第１閾値以上の回数、更新されない場合には、エンコード部１９は、定期Ｉフレームデータ又はＰフレームデータに代えて、スキップフレームデータを生成する。これにより、配信制御システム２でフレームデータの処理が滞るという事態を回避することができるため、配信制御システム２はウェブサーバ８等から取得したコンテンツデータを、より迅速に映像データとして通信端末５に配信することができるという効果を奏する。

また、本実施形態では、エンコード部１９は、スキップフレームデータが生成される直前の定期Ｉフレームデータ又はＰフレームデータに代えて、定期Ｉフレームデータ（第１の変換フレームデータの一例）よりも高画質の強制Ｉフレームデータ（第３の変換フレームデータの一例）を生成する。そして、送受信部３１は、強制Ｉフレームデータを分割数Ｎに応じてＮ個に分割して送信する。これにより、画像が更新されない状態が続いて、スキップフレームデータが定期的に配信され続けられている場合であっても、通信ネットワーク９に負荷をかけることなく、通信端末５側では高画質の画像を再生し続けることができるので、通信端末５のユーザにとっては画像が見え易い状態が続くという効果を奏する。

また、本実施形態の配信システム１では、クラウド上で配信制御システム２がレンダリングを行うブラウザ２０及びエンコード等を行うエンコーダブリッジ部３０を有する。これにより、ブラウザ２０が所定の記述言語で示されたコンテンツデータに基づいて静止画（音）データとしての各フレームデータを生成し、エンコーダブリッジ部３０が各フレームデータを通信ネットワーク９で配信可能な映像（音）データに変換する。その後に、配信制御システム２は、通信端末５に映像（音）データを配信する。よって、通信端末５側では、自端末のブラウザを最新化したり、CPU、OS、及びRAM等のスペックを上げる手間や費用を掛けなくても、スムーズにウェブコンテンツを再生することができる。そのため、コンテンツのリッチ化によって通信端末５の負荷が高くなるという問題を解消することができる。

特に、ブラウザ２０は、リアルタイムコミュニケーションを可能にし、変換部１０は、ブラウザ２０によって生成されたフレームデータに対してリアルタイムのエンコードを行う。よって、例えば、映像（音）データのオンデマンド配信のように、ＤＶＤプレーヤがリアルタイム性のない（つまり、予めエンコードされている）映像（音）データを選択して配信する場合とは異なり、配信制御システム２は、配信する直前に取得したコンテンツをレンダリングすることによってフレームデータを生成してからエンコードするため、リアルタイム性に優れた映像（音）データの配信を行うことができる。

〔補足説明〕
上記実施形態では、ステップＳ３１３の処理において、エンコード部１９は、ＳＦＣが第１閾値より小さいか否かを判断することにより、更新されていないフレームデータを生成した回数を判断したが、これに限るものではない。例えば、エンコード部１９は、更新されていないフレームデータを生成した回数ではなく、更新したフレームデータを最後に生成してから、フレームデータを更新していない時間が所定の時間を超えているか否かを判断してもよい。

また、上記実施形態では、強制Ｉフレームデータは、定期Ｉフレームデータよりも低圧縮（高画質）のフレームデータであるが、これに限るものではない。例えば、エンコード部１９は、定期Ｉフレームデータよりも高圧縮（低画質）の複数のフレームデータを生成し、送受信部３１が通信端末５に複数のフレームデータを順次送信するようにしてもよい。この場合、通信端末５では、順次受信した複数のフレームデータから、単一の強制Ｉフレームデータと同等の高画質の映像を再生する。

更に、上記実施形態では、配信制御システム２は、上記ステップＳ３１８によって生成したスキップフレームデータを配信するが、これに限るものではない。例えば、配信制御システム２は、スキップフレームデータを配信せずに、今回のフレームデータの内容が前回のフレームデータの内容に対して更新されない旨を示す非更新情報を配信してもよい。この場合、通信端末５は、非更新情報に基づいて、上記スキップフレームデータを受信した場合と同様の処理を行なう。なお、非更新情報のデータ形式は、H.264の規格等によらない独自のデータ形式でもよい。

また、上記実施形態では、強制Iフレームデータを分割する場合について説明したが、強制Ｉフレームデータ以外のフレームデータを分割してもよい。例えば、静止画から急に動画に変化した場合、急にフレームサイズが大きくなる。このような場合、フレームサイズが急に大きくなった最初のフレームを分割することで通信ネットワーク９の負荷を低減させることができる。

また、上記実施形態の配信システム１では、端末管理システム７と配信制御システム２とを互いに別個のシステムとして構成しているが、例えば、配信制御システム２に端末管理システム７の機能を持たせるなどにより、端末管理システム７と配信制御システム２とを一体の装置として構成するようにしてもよい。

また、上記実施形態における配信制御システム２及び端末管理システム７等のコンピュータシステムは、単一のコンピュータによって構築されてもよいし、各部（機能、手段、又は記憶部）を分割して任意に割り当てられた複数のコンピュータによって構築されていてもよい。

更に、上記実施形態の各プログラムが記録されたＣＤ−ＲＯＭやＨＤＤ等の記録媒体は、いずれもプログラム製品(Program Product)として、国内又は国外へ提供されることができる。

１ 配信システム
２ 配信制御システム
５ 通信端末
７ 端末管理システム
８ ウェブサーバ
９ 通信ネットワーク
１０ 変換部
１１ トリミング部
１２ リサイズ部
１３ 分割部
１９ エンコード部
２０ ブラウザ
２１ 送受信部
２２ ブラウザ管理部
２３ クラウドブラウザ
２４ 送信用ＦＩＦＯ
３０ エンコーダブリッジ部
３１ 送受信部
５２ 操作部
３１０ 作成・選択・転送部

特開２００７−２２１２２９号公報

Claims (9)

1. コンテンツデータからフレームデータを生成する生成部と、
   前記フレームデータが所定の範囲以上更新されている場合、前記フレームデータを、単独で再生可能な第１の変換フレームデータ、又は前回変換された変換フレームデータとの差分を示す第２の変換フレームデータに変換し、前記フレームデータが所定の範囲以上更新されていない場合、前記フレームデータを、前記第１の変換フレームデータよりも高画質な第３の変換フレームデータ、又は前回変換された変換フレームデータから更新されていないことを示す第４の変換フレームデータに変換する変換部と、
   前記フレームデータが所定の範囲以上更新されている場合、前記第１の変換フレームデータ又は前記第２の変換フレームデータを送信し、前記フレームデータが所定の範囲以上更新されていない場合、前記第３の変換フレームデータを分割数Ｎ（Ｎは２以上の整数）に応じてＮ個に分割して送信した後、前記フレームデータが所定の範囲以上更新されるまで、前記第４の変換フレームデータを定期的に送信する送信部と、
   を備える配信制御システム。
2. 前記送信部は、前記第３の変換フレームデータを前記分割数Ｎに応じてＮ個に分割して送信した後、前記第４の変換フレームデータに代えて、前回変換された変換フレームデータから更新がないことを示す非更新情報を、前記フレームデータが所定の範囲以上更新されるまで定期的に送信する
   請求項１に記載の配信制御システム。
3. 前記変換部は、所定の範囲以上更新されていない前記フレームデータを、前記生成部が継続して生成した回数が第１閾値以上である場合、前記フレームデータを、前記第３の変換フレームデータ、又は前記第４の変換フレームデータに変換し、
   前記送信部は、前記生成部が所定の範囲以上更新されていない前記フレームデータを、継続して生成した回数が第１閾値以上である場合、前記第３の変換フレームデータを前記分割数Ｎに応じてＮ個に分割して送信する
   請求項１又は２に記載の配信制御システム。
4. 前記送信部は、通信ネットワークの状態に応じて前記第３の変換フレームデータを分割するか否かを判定し、分割する場合、更に通信ネットワークの状況に応じて前記分割数Ｎを変更する
   請求項１乃至３のいずれか１項に記載の配信制御システム。
5. 前記変換部は、前記送信部が前記第３の変換フレームデータを分割数Ｎに応じてＮ個に分割して送信している間は、前記フレームデータの変換を行わない
   請求項１乃至４のいずれか１項に記載の配信制御システム。
6. 前記送信部は、前記分割数Ｎを示す情報を配信先の端末に通知する
   請求項１乃至５のいずれか１項に記載の配信制御システム。
7. 前記生成部は、ブラウザである
   請求項１乃至６のいずれか１項に記載の配信制御システム。
8. 生成部が、コンテンツデータからフレームデータを生成するステップと、
   変換部が、前記フレームデータが所定の範囲以上更新されている場合、前記フレームデータを、単独で再生可能な第１の変換フレームデータ、又は前回変換された変換フレームデータとの差分を示す第２の変換フレームデータに変換し、前記フレームデータが所定の範囲以上更新されていない場合、前記フレームデータを、前記第１の変換フレームデータよりも高画質な第３の変換フレームデータ、又は前回変換された変換フレームデータから更新されていないことを示す第４の変換フレームデータに変換するステップと、
   送信部が、前記フレームデータが所定の範囲以上更新されている場合、前記第１の変換フレームデータ又は前記第２の変換フレームデータを送信し、前記フレームデータが所定の範囲以上更新されていない場合、前記第３の変換フレームデータを分割数Ｎ（Ｎは２以上の整数）に応じてＮ個に分割して送信した後、前記フレームデータが所定の範囲以上更新されるまで前記第４の変換フレームデータを定期的に送信するステップと、
   を含む配信制御方法。
9. コンピュータを、
   コンテンツデータからフレームデータを生成する生成部と、
   前記フレームデータが所定の範囲以上更新されている場合、前記フレームデータを、単独で再生可能な第１の変換フレームデータ、又は前回変換された変換フレームデータとの差分を示す第２の変換フレームデータに変換し、前記フレームデータが所定の範囲以上更新されていない場合、前記フレームデータを、前記第１の変換フレームデータよりも高画質な第３の変換フレームデータ、又は前回変換された変換フレームデータから更新されていないことを示す第４の変換フレームデータに変換する変換部と、
   前記フレームデータが所定の範囲以上更新されている場合、前記第１の変換フレームデータ又は前記第２の変換フレームデータを送信し、前記フレームデータが所定の範囲以上更新されていない場合、前記第３の変換フレームデータを分割数Ｎ（Ｎは２以上の整数）に応じてＮ個に分割して送信した後、前記フレームデータが所定の範囲以上更新されるまで前記第４の変換フレームデータを定期的に送信する送信部、
   として機能させるためのプログラム。

Images