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

Description

本発明は、パソコンや電子黒板等の通信端末に、データを送信する発明に関する。

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

ところが、インターネット上で扱われるウェブ（Ｗｅｂ）コンテンツは、様々な要求に応えるためにリッチ化される傾向にある。そのため、インターネット経由でサービスを利用するための通信端末を用いて、リッチ化されたコンテンツを利用する場合、通信端末の負荷が高いという問題がある。

また、通信端末の負荷を低減させる技術としては、シンクライアントと呼ばれる技術がある（例えば、特許文献１等を参照）。そして、このシンクライアントの技術により、インターネット環境を利用してウェブベースで様々なアプリケーションを通信端末で実行することができる。

しかしながら、シンクライアントの技術を利用しても、リッチ化されたコンテンツを利用する場合、通信端末の負荷が高いという問題は解消しないという課題が生じる。

上述した課題を解決すべく、請求項１に係る発明は、クラウド上に置かれるウェブサーバと通信ネットワークを介して通信し、該ウェブサーバからウェブコンテンツを取得し、かつ、通信端末に映像データを送信する配信制御システムであって、公開用のブラウザと個人用のブラウザとの、少なくとも２つのブラウザを記憶する記憶部と、他の通信端末に公開可能な前記映像データを出力する場合には、前記公開用のブラウザを起動し、他の通信端末に公開可能でない前記映像データをする出力する場合は、前記個人用のブラウザを起動するブラウザ起動部と、前記映像データを前記通信端末に送信する送信部とを備え、前記ブラウザ起動部により起動されたブラウザは、前記ウェブサーバからウェブコンテンツを取得してレンダリングすることによって、前記映像データを生成する。

本発明によれば、コンテンツのリッチ化に対応させるための通信端末の負荷が高いという問題を解消することができる。

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

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

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

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

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

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

通信端末５は、配信システム１のサービスを受けるユーザが使用する端末である。このうち、通信端末５ａは、ノートＰＣ(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等による圧縮した映像（音）データにした状態で、通信端末５に配信することができる。よって、通信端末５側では、自端末のブラウザを最新化したり、CPU(Central Processing Unit)、OS(Operating System)、及びRAM(Random Access Memory)等のスペックを上げる手間や費用を掛けなくても、スムーズにウェブコンテンツを再生することができる。

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

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

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

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

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

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

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

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

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

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

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

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

図７に示されているように配信制御システム２は、配信制御システム２全体の動作を制御するＣＰＵ２０１、ＩＰＬ等のＣＰＵ２０１の駆動に用いられるプログラムを記憶したＲＯＭ２０２、ＣＰＵ２０１のワークエリアとして使用されるＲＡＭ２０３、プログラム等の各種データを記憶するＨＤＤ２０４、ＣＰＵ２０１の制御にしたがってＨＤＤ２０４に対する各種データの読み出し又は書き込みを制御するＨＤＣ(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情報」、及び「キャッシュファイル」が含まれており、各通信端末５のログイン後に、設定情報と共に配信制御システム２に送信され、各通信端末５に対して個別のサービスを行うために利用される。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

＜ブラウザ種別に応じた配信処理＞
本実施形態の配信制御システム２は、ブラウザ２０がコンテンツデータからフレームデータを生成する。そして、エンコーダブリッジ部３０が当該フレームデータを、通信ネットワーク２で配信可能な画像（音）データに変換する。通信端末５のユーザが、コンテンツデータを利用するための各種設定などを行う設定画面も、ブラウザ２０及びエンコーダブリッジ部３０により生成された画像（音）データを利用して行う。

設定画面に含まれる情報などには、個人情報などの他のユーザに公開するべきでない情報が含まれる場合がある。そのため、本実施形態のブラウザ管理部２２は、他の通信端末に公開可能な情報であるか否かに応じて、起動するブラウザ２０の種類を変える。ブラウザ管理部２２は、ブラウザ２０の種類をブラウザ種別により管理する。ブラウザ種別は、公開用のブラウザ２０、又は個人用のブラウザ２０を示す。ブラウザ管理部２２は、他の通信端末に公開可能な情報である場合、公開用のブラウザ２０（上述のブラウザ２０aに相当）を起動し、他の通信端末に公開可能でない情報を出力する場合、個人用のブラウザ２０（上述のブラウザ２０ｂに相当）を起動する。

公開用のブラウザ２０は、例えば、プレゼンテーション用のコンテンツデータからフレームデータを生成する。個人用のブラウザ２０は、例えば、ユーザ毎の設定画面用のコンテンツデータからフレームデータを生成する。なお、公開用のブラウザ２０、及び個人用のブラウザ２０が読み込むコンテンツデータは、上述の例に限らず任意でよい。例えば、他の通信端末５に公開可能な情報を、他の通信端末５に公開する必要のない情報として意図的に個人用のブラウザ２０で扱ってもよい。

以下、ブラウザ種別に応じた配信処理について、基本配信（図３及び図１７参照）の場合、及びマルチディスプレイ（図５及び図２２参照）の場合を例にして説明する。

本実施形態の配信制御システム２では、ブラウザ管理部２２が、上述のブラウザＩＤによりブラウザ２０のプロセスを識別する。また、ブラウザ管理部２２は、ブラウザＩＤとブラウザ種別とにより、ブラウザ２０を管理する。また、エンコーダブリッジ部３０が、上述のエンコーダＩＤによりエンコーダブリッジ部３０のプロセス（上述の変換部１０）を識別（管理）する。

まず、画像（音）データを１つの通信端末５に基本配信する場合のブラウザＩＤ、ブラウザ種別、及びエンコーダＩＤについて説明する。画像（音）データを１つの通信端末５に基本配信する場合、画像（音）データの基本配信に使用するブラウザ２０のプロセスは、1つである。すなわち、画像（音）データ毎に、１つのブラウザ２０が使用される。

ブラウザ管理部２２は、基本配信する画像（音）データが公開可能な情報を含む場合、公開用のブラウザ２０を示すブラウザ種別を、当該ブラウザ２０のプロセスを識別するブラウザＩＤに紐付ける。具体的には、ブラウザ管理部２２は、端末管理システム７から受信したブラウザ起動要求が公開用のブラウザ２０の起動を示す場合（図１７のステップＳ２４など）、公開用のブラウザ２０を示すブラウザ種別を、起動させたブラウザ２０のプロセスを識別するブラウザＩＤに紐付ける。

一方、ブラウザ管理部２２は、基本配信する画像（音）データが公開可能でない情報を含む場合、個人用のブラウザ２０を示すブラウザ種別を、当該ブラウザ２０のプロセスを識別するブラウザＩＤに紐付ける。具体的には、ブラウザ管理部２２は、端末管理システム７から受信したブラウザ起動要求が個人用のブラウザ２０の起動を示す場合（図２２のステップＳ２０８など）、個人用のブラウザ２０を示すブラウザ種別を、起動させたブラウザ２０のプロセスを識別するブラウザＩＤに紐付ける。

また、画像（音）データを１つの通信端末５に基本配信する場合、当該基本配信に使用するエンコーダブリッジ部３０のプロセス（上述の変換部１０）は、1つである。すなわち、画像（音）データ毎に、１つの変換部１０が使用される。エンコーダブリッジ部３０は、当該エンコーダブリッジ部３０のプロセス（変換部１０）を識別するエンコーダＩＤにより、当該基本配信に使用するエンコーダブリッジ部３０のプロセスを管理する。

なお、エンコーダブリッジ部３０のプロセス（上述の変換部１０）は、上述の作成・選択部３１０により、画像（音）データの種類に応じて切り替えられる。例えば、マルチディスプレイの処理では、配信先を追加するために、画像（音）データを、視聴用のコンテンツ（他の通信端末５に公開できる情報）から、設定画面用のコンテンツ（他の通信端末５に公開できない情報）に変える必要がある。このとき、作成・選択部３１０は、エンコーダブリッジ部３０のプロセス（上述の変換部１０）を切り替える（図２２のステップＳ２１０参照）。

本実施形態の配信制御システム２では、ブラウザ種別により、他の通信端末５に公開可能な情報を扱うブラウザ２０と、他の通信端末５に公開できない情報を扱うブラウザ２０と、を明確に区別する。これにより配信制御システム２が取り扱う情報のセキュリティを向上させることができる。

例えば、送受信３１が、ユーザの通信端末５から、画像（音）データをマルチキャストする指示を含むジェスチャイベントを受信しても、ブラウザ管理部２２が、ブラウザ２０のブラウザ種別に応じて、マルチキャストしてよいか否かを判定する。すなわち、ブラウザ管理部２２は、当該画像（音）データに対応するフレームデータを生成するブラウザ２０のブラウザ種別が、個人用のブラウザ２０を示す場合、当該画像（音）データのマルチキャストを不可と判定する。

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

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

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

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

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

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

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

Claims (6)

1. クラウド上に置かれるウェブサーバと通信ネットワークを介して通信し、該ウェブサーバからウェブコンテンツを取得し、かつ、通信端末に映像データを送信する配信制御システムであって、
   公開用のブラウザと個人用のブラウザとの、少なくとも２つのブラウザを記憶する記憶部と、
   他の通信端末に公開可能な前記映像データを出力する場合には、前記公開用のブラウザを起動し、他の通信端末に公開可能でない前記映像データをする出力する場合は、前記個人用のブラウザを起動するブラウザ起動部と、
   前記映像データを前記通信端末に送信する送信部とを備え、
   前記ブラウザ起動部により起動されたブラウザは、前記ウェブサーバからウェブコンテンツを取得してレンダリングすることによって、前記映像データを生成する、
   配信制御システム。
2. 前記映像データを複数の前記通信端末にマルチキャストする指示を示す情報を含むジェスチャイベントを、前記通信端末から受信する受信部を更に備え、
   前記送信部は、
   前記映像データを出力するブラウザが前記公開用のブラウザである場合は、前記映像データをマルチキャストし、前記映像データを出力するブラウザが前記個人用のブラウザである場合は、前記映像データをマルチキャストしない
   請求項１に記載の配信制御システム。
3. 前記配信制御システムは、
   前記映像データを符号化するエンコーダを更に備え、
   前記送信部は、
   符号化された前記映像データを前記通信端末に配信する
   請求項１又は２に記載の配信制御システム。
4. 請求項１乃至３のいずれか１項に記載の配信制御システムと、
   前記映像データを出力する１以上の通信端末と、
   を備える配信システム。
5. クラウド上に置かれるウェブサーバと通信ネットワークを介して通信し、該ウェブサーバからウェブコンテンツを取得し、かつ、通信端末に映像データを送信する配信制御システムの配信制御方法であって、
   記憶部が、公開用のブラウザと個人用のブラウザとの、少なくとも２つのブラウザを記憶するステップと、
   ブラウザ起動部が、他の通信端末に公開可能な前記映像データを出力する場合には、前記公開用のブラウザを起動し、他の通信端末に公開可能でない前記映像データをする出力する場合は、前記個人用のブラウザを起動するステップと、
   前記起動するステップにより起動されたブラウザが、前記ウェブサーバからウェブコンテンツを取得してレンダリングすることによって、前記映像データを生成するステップと、
   送信部が、前記映像データを前記通信端末に送信するステップと、
   を含む配信制御方法。
6. クラウド上に置かれるウェブサーバと通信ネットワークを介して通信し、該ウェブサーバからウェブコンテンツを取得し、かつ、通信端末に映像データを送信し、公開用のブラウザと個人用のブラウザとの、少なくとも２つのブラウザを記憶する記憶部を備えるコンピュータを、
   他の通信端末に公開可能な前記映像データを出力する場合には、前記公開用のブラウザを起動し、他の通信端末に公開可能でない前記映像データをする出力する場合は、前記個人用のブラウザを起動するブラウザ起動部と、
   前記映像データを前記通信端末に送信する送信部として機能させ、
   前記ブラウザ起動部により起動されたブラウザは、前記ウェブサーバからウェブコンテンツを取得してレンダリングすることによって、前記映像データを生成する、
   プログラム。

Images