JP2004252884A - コンテンツ配信変換装置及びコンテンツ配信変換方法 - Google Patents

Abstract

【課題】ユニキャスト用のコンテンツ配信装置に保持されたコンテンツに対し同報配信を可能とするコンテンツ配信変換装置及び方法を提供する。
【解決手段】コンテンツ配信変換装置３００、３５０において、コンテンツをコンテンツ配信装置１００、１１０からユニキャスト用の制御プロトコルを用いてコンテンツを取得し、当該コンテンツを同報用の広告プロトコルを用いて１以上の受信端末２００等へ同報配信する。また、コンテンツ配信変換装置３００、３５０においてコネクション型プロトコルによりコンテンツを取得した場合には、コネクションレス型のプロトコルに変換し、変換後のコンテンツを同報配信する。これにより、ユニキャストを前提としたコンテンツ配信装置１００、１１０からでも、コンテンツ配信変換装置３００、３５０を介することにより、１以上の受信端末２００等へ同報配信することが可能となる。
【選択図】 図１

Description

【０００１】
【発明の属する技術分野】
本発明は、コンテンツ配信装置から１以上の受信装置にコンテンツを配信するシステムにてネットワーク上に位置するコンテンツ配信変換装置であって、遠隔のコンテンツ配信装置からコンテンツをユニキャストで取得し当該コンテンツを１以上の受信端末に同報配信するコンテンツ配信変換装置、及びコンテンツ配信変換方法に関する。
【０００２】
【従来の技術】
インターネット上で１対多の放送型通信を実現するための技術としてマルチキャスト技術があるが、実際のインターネット上にはマルチキャスト機能を持たないルータが多く、マルチキャストを使えるネットワークは限られている。また、携帯電話のネットワークはユニキャストベースのネットワークであり、そのままでは１対多の放送型通信は不可能である。
【０００３】
ユニキャストベースのネットワーク上で１対多の放送型通信を可能とする従来技術としてＭｂｏｎｅ（Ｉｎｔｅｒｎｅｔ Ｍｕｌｔｉｃａｓｔ Ｂａｃｋｂｏｎｅ）がある。このＭＢｏｎｅではマルチキャストをサポートするネットワーク内にＭＢｏｎｅルータを設置し、当該ネットワーク内の受信端末に対してはマルチキャストによりパケットを転送する。一方、Ｍｂｏｎｅルータ間がユニキャストしか通さないネットワークである場合には、パケットのカプセル化によりユニキャストでパケットを転送する。このように、通信経路中にユニキャストしか通さないネットワークがあってもカプセル化によるトンネリング手段によりマルチキャストを実現することが可能となる。
【０００４】
マルチキャストを実現する技術は、例えば、下記の特許文献１〜３に開示されている。このうち特許文献１に示される方法では、受信端末がマルチキャストをサポートしていない場合でも、ネットワーク内のゲートウェイ装置がマルチキャストパケットを受信し、当該受信端末ヘユニキャストでパケットを送信する。これにより、マルチキャストをサポートしていない端末でもマルチキャストのサービスを受けることが可能となる。
【０００５】
また、特許文献２に示される方法では、ユニキャストパケットとマルチキャストパケットのヘッダを変換するゲートウェイ装置をネットワーク内に設置することにより、ＭＢｏｎｅのようなトンネリングによるオーバヘッド無くマルチキャストを実現することが可能となる。
【０００６】
更に、特許文献３に示される方法では、マルチキャスト可能なネットワーク内に位置しないコンテンツの送信元が、マルチキャスト通信装置にユニキャストでコンテンツを送信すると、当該マルチキャスト通信装置はユニキャストとマルチキャストの変換を行う。そのため、コンテンツの送信元がマルチキャスト可能なネットワーク内に位置しない場合でも、マルチキャスト通信装置によりマルチキャストによる配信が可能となる。
【０００７】
上記のような技術により、ユニキャストしか通さないネットワークが存在する場合や、ユニキャストをサポートしない配信装置や受信端末が存在する場合でも、マルチキャストのサービスを提供することが可能となる。
【０００８】
但し、上述の技術では、コンテンツを配信する配信装置がマルチキャスト若しくはブロードキャストにより同報送信すること、又は、配信装置が特殊なマルチキャスト通信装置の存在を知っていることが前提となっている。
【０００９】
【特許文献１】
特開平１０−２４２９６２号公報
【特許文献２】
特開２００１−２３０７７４号公報
【特許文献３】
特開２００２−１８５５２８号公報
【００１０】
【発明が解決しようとする課題】
しかしながら、現状のインターネットでは、マルチキャストでコンテンツを配信する配信装置は数少なく、通常はＨＴＴＰ（Ｈｙｐｅｒ Ｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）やＲＴＳＰ（Ｒｅａｌ−Ｔｉｍｅ Ｓｔｒｅａｍｉｎｇ Ｐｒｏｔｏｃｏｌ）などの１対１のセッション制御プロトコルを用いてユニキャストでコンテンツを配信している。従って、上記の従来技術では、１対１のセッション制御プロトコルを有する配信装置に対しては、適用することができなかった。
【００１１】
本発明は、上記課題を解決するために成されたものであり、コンテンツの配信装置がユニキャストを前提とした配信装置であっても、１以上の受信端末ヘブロードキャストもしくはマルチキャストによる同報配信を可能とするコンテンツ配信変換装置及びコンテンツ配信変換方法を提供することを目的とする。
【００１２】
【課題を解決するための手段】
上記目的を達成するために、本発明に係るコンテンツ配信変換装置は、請求項１に記載したように、コンテンツを保持したコンテンツ配信装置に対してデータ転送用の制御プロトコルを用いてコンテンツを要求するコンテンツ要求手段と、前記コンテンツをコネクション型のプロトコルにより前記コンテンツ配信装置から取得するコンテンツ取得手段と、前記コンテンツのフォーマット情報を含む広告メッセージを１以上の受信端末に対して繰り返し同報配信する広告メッセージ配信手段と、前記コンテンツをコネクションレス型のプロトコルにより１以上の受信端末に対して同報配信するコンテンツ配信手段とを備えたことを特徴とする。
【００１３】
また、本発明に係るコンテンツ配信変換方法は、請求項８に記載したように、コンテンツを保持したコンテンツ配信装置に対してデータ転送用の制御プロトコルを用いてコンテンツを要求するコンテンツ要求工程と、前記コンテンツをコネクション型のプロトコルにより前記コンテンツ配信装置から取得するコンテンツ取得工程と、前記コンテンツのフォーマット情報を含む広告メッセージを１以上の受信端末に対して繰り返し同報配信する広告メッセージ配信工程と、前記コンテンツをコネクションレス型のプロトコルにより１以上の受信端末に対して同報配信するコンテンツ配信工程とを有することを特徴とする。
【００１４】
これら請求項１、８の発明によれば、まず、コンテンツ要求手段が、コンテンツを保持したコンテンツ配信装置に対してデータ転送用の制御プロトコルを用いてコンテンツを要求し、コンテンツ取得手段が、前記コンテンツをコネクション型のプロトコルにより前記コンテンツ配信装置から取得する。そして、広告メッセージ配信手段が、前記コンテンツのフォーマット情報を含む広告メッセージを１以上の受信端末に対して繰り返し同報配信し、コンテンツ配信手段が、前記コンテンツをコネクションレス型のプロトコルにより１以上の受信端末に対して同報配信する。
【００１５】
本発明によれば、ユニキャストを前提としたコンテンツ配信装置からでも、上述のコンテンツ配信変換装置を介することにより、１以上の受信端末へ同報配信することが可能となる。そのため、コンテンツ配信装置は同報配信のための特別なプロトコルを用意する必要がなく、ユニキャスト配信用のコンテンツを同報配信に使用することが可能となる。
【００１６】
また、コンテンツ配信変換装置においてデータ転送用の制御プロトコルと同報配信用の広告プロトコルを変換するため、受信端末は、通常の同報配信用途で使用される広告プロトコルを解釈するだけですむようになり、実装の負荷を軽減することができる。
【００１７】
また、コンテンツ配信変換装置において、コネクション型プロトコル、例えば、ＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）で取得したコンテンツをコネクションレス型プロトコル、例えば、ＵＤＰ（Ｕｓｅｒ Ｄａｔａｇｒａｍ Ｐｒｏｔｏｃｏｌ）に変換して送信する。これにより、コネクション型プロトコルで取得した当該コンテンツを１以上の受信端末ヘコネクションレス型プロトコルで同報配信することが可能となり、より大規模なコンテンツ配信が可能となる。
【００１８】
上記目的を達成するために、本発明に係るコンテンツ配信変換装置は、請求項２に記載したように、少なくとも音響データ及び映像データの何れかを含むコンテンツを保持したコンテンツ配信装置に対してデータ転送用の制御プロトコルを用いてコンテンツを要求するコンテンツ要求手段と、前記コンテンツをコネクション型のプロトコルにより前記コンテンツ配信装置から取得するコンテンツ取得手段と、前記コンテンツ内部から、前記コンテンツの符号化方法及び符号化パラメータに関する情報を抽出する情報抽出手段と、前記抽出した符号化方法及び符号化パラメータに関する情報を含む広告メッセージを１以上の受信端末に対して繰り返し同報配信する広告メッセージ配信手段と、前記コンテンツ内部の時間情報に基づいて、再生時刻を表すタイムスタンプ情報が各パケットのヘッダ部に記録されたストリーミングフォーマットに前記コンテンツを変換するコンテンツ変換手段と、変換後のコンテンツを１以上の受信端末へ同報配信するコンテンツ配信手段とを備えたことを特徴とする。
【００１９】
また、本発明に係るコンテンツ配信変換方法は、請求項９に記載したように、少なくとも音響データ及び映像データの何れかを含むコンテンツを保持したコンテンツ配信装置に対してデータ転送用の制御プロトコルを用いてコンテンツを要求するコンテンツ要求工程と、前記コンテンツをコネクション型のプロトコルにより前記コンテンツ配信装置から取得するコンテンツ取得工程と、前記コンテンツ内部から、前記コンテンツの符号化方法及び符号化パラメータに関する情報を抽出する情報抽出工程と、前記抽出した符号化方法及び符号化パラメータに関する情報を含む広告メッセージを１以上の受信端末に対して繰り返し同報配信する広告メッセージ配信工程と、前記コンテンツ内部の時間情報に基づいて、再生時刻を表すタイムスタンプ情報が各パケットのヘッダ部に記録されたストリーミングフォーマットに前記コンテンツを変換するコンテンツ変換工程と、変換後のコンテンツを１以上の受信端末へ同報配信するコンテンツ配信工程とを有することを特徴とする。
【００２０】
これら請求項２、９の発明によれば、まず、コンテンツ要求手段が、少なくとも音響データ及び映像データの何れかを含むコンテンツを保持したコンテンツ配信装置に対してデータ転送用の制御プロトコルを用いてコンテンツを要求し、コンテンツ取得手段が、コンテンツをコネクション型のプロトコルにより前記コンテンツ配信装置から取得する。そして、情報抽出手段が、コンテンツ内部から、前記コンテンツの符号化方法及び符号化パラメータに関する情報を抽出すると、広告メッセージ配信手段が、前記抽出した符号化方法及び符号化パラメータに関する情報を含む広告メッセージを１以上の受信端末に対して繰り返し同報配信する。さらに、コンテンツ変換手段が、前記コンテンツ内部の時間情報に基づいて、再生時刻を表すタイムスタンプ情報が各パケットのヘッダ部に記録されたストリーミングフォーマットに前記コンテンツを変換すると、コンテンツ配信手段が、変換後のコンテンツを１以上の受信端末へ同報配信する。なお、上記の「映像データ」は、動画データ、静止画データ、及びこれらと音響データとの混合データを含むものとする。
【００２１】
本発明によれば、コンテンツ配信変換装置において、コネクション型プロトコル、例えば、ＴＣＰで取得したオーディオもしくはビデオコンテンツをストリーミングフォーマット、例えば、ＲＴＰに変換し、コネクションレス型プロトコル、例えば、ＵＤＰ上で送信する。これにより、コンテンツ配信装置と配信変換装置の間はコネクション型プロトコルを利用して、高い信頼性のもとでコンテンツを取得し、配信変換装置と受信端末の間はストリーミングフォーマットで効率的にコンテンツを配信することが可能となる。
【００２２】
上記目的を達成するために、本発明に係るコンテンツ配信変換装置は、請求項３に記載したように、少なくとも音響データ及び映像データの何れかを含むコンテンツを保持したコンテンツ配信装置に対してストリーミング用の制御プロトコルを用いてコンテンツを要求するコンテンツ要求手段と、前記コンテンツ配信装置からストリーミング用の制御プロトコルで通知される符号化方法及び符号化パラメータに関する情報を抽出する情報抽出手段と、再生時刻を表すタイムスタンプ情報が各パケットのヘッダ部に記録されたストリーミングフォーマットによって、前記コンテンツ配信装置から前記コンテンツを取得するコンテンツ取得手段と、前記抽出した符号化方法及び符号化パラメータに関する情報を含む広告メッセージを１以上の受信端末に対して繰り返し同報配信する広告メッセージ配信手段と、前記取得したストリーミングフォーマットのコンテンツを１以上の受信端末へ同報配信するコンテンツ配信手段とを備えたことを特徴とする。
【００２３】
また、本発明に係るコンテンツ配信変換方法は、請求項１０に記載したように、少なくとも音響データ及び映像データの何れかを含むコンテンツを保持したコンテンツ配信装置に対してストリーミング用の制御プロトコルを用いてコンテンツを要求するコンテンツ要求工程と、前記コンテンツ配信装置からストリーミング用の制御プロトコルで通知される符号化方法及び符号化パラメータに関する情報を抽出する情報抽出工程と、再生時刻を表すタイムスタンプ情報が各パケットのヘッダ部に記録されたストリーミングフォーマットによって、前記コンテンツ配信装置から前記コンテンツを取得するコンテンツ取得工程と、前記抽出した符号化方法及び符号化パラメータに関する情報を含む広告メッセージを１以上の受信端末に対して繰り返し同報配信する広告メッセージ配信工程と、前記取得したストリーミングフォーマットのコンテンツを１以上の受信端末へ同報配信するコンテンツ配信工程とを有することを特徴とする。
【００２４】
これら請求項３、１０の発明によれば、まず、コンテンツ要求手段が、少なくとも音響データ及び映像データの何れかを含むコンテンツを保持したコンテンツ配信装置に対してストリーミング用の制御プロトコルを用いてコンテンツを要求し、情報抽出手段が、コンテンツ配信装置からストリーミング用の制御プロトコルで通知される符号化方法及び符号化パラメータに関する情報を抽出する。そして、コンテンツ取得手段が、再生時刻を表すタイムスタンプ情報が各パケットのヘッダ部に記録されたストリーミングフォーマットによって、前記コンテンツ配信装置から前記コンテンツを取得すると、広告メッセージ配信手段が、抽出された符号化方法及び符号化パラメータに関する情報を含む広告メッセージを１以上の受信端末に対して繰り返し同報配信し、コンテンツ配信手段が、取得されたストリーミングフォーマットのコンテンツを１以上の受信端末へ同報配信する。
【００２５】
本発明によれば、コンテンツ配信変換装置において、ストリーミング用制御プロトコルにより配信されるストリーミングフォーマットのコンテンツを受信し、１以上の受信端末へ同報配信する。これにより、ライブ配信などのリアルタイムに生成されるコンテンツも配信変換装置において同報することが可能となり、より大規模なコンテンツ配信が可能となる。
【００２６】
上記コンテンツ配信変換装置は、請求項４に記載したように、少なくともコンテンツの配信タイミング及びコンテンツの取得元が記述された配信制御記述情報を保持した制御情報保持手段をさらに備え、前記コンテンツ取得手段が、前記配信制御記述情報内に記述されたコンテンツ取得元の情報に基づいて、当該コンテンツ取得元からコンテンツを取得し、前記コンテンツ配信手段が、前記配信制御記述情報内に記述された配信タイミングの情報に基づいて、１以上の受信端末ヘのコンテンツ配信タイミングを決定するよう構成とすることが望ましい。この場合、コンテンツ配信変換装置は、取得するコンテンツの位置や配信タイミング等を指定した配信制御記述情報に基づいて、コンテンツの取得及び配信を行う。これにより、ユーザから要求されたコンテンツ配信時間に（配信タイミングで）同報配信することが可能である。
【００２７】
また、コンテンツ配信変換装置では、請求項５に記載したように、配信制御記述情報は番組情報をさらに含み、当該番組情報は前記広告メッセージによって前記受信端末に同報配信されることが望ましい。この場合、配信管理者が配信制御記述情報によって放送番組のスケジューリングを行うことも可能となる。
【００２８】
また、コンテンツ配信変換装置では、請求項６に記載したように、コンテンツを同報する同報配信範囲を制限する同報配信範囲制限手段をさらに備えた構成とすることが望ましい。この場合、コンテンツ配信変換装置から同報配信する範囲を制限することにより、特定のドメインに限定した配信が可能となる。これにより、例えば、地理的な位置に応じて放送コンテンツを設定することが可能となる。
【００２９】
また、コンテンツ配信変換装置は、請求項７に記載したように、コンテンツの配信タイミング、コンテンツの取得元及びコンテンツの画面レイアウトが記述されたメディア記述ファイルを取得するメディア記述ファイル取得手段と、画面レイアウトにて同一の領域に配置される複数のコンテンツに関する画面レイアウトの記述を１つの記述に変換し、コンテンツの取得元に関する記述を前記広告メッセージに記述される情報形式に変換する記述変換手段と、当該変換後の記述を含むメディア記述ファイルを１以上の受信端末へ同報配信するメディア記述ファイル配信手段とをさらに備えた構成とすることが望ましい。この場合、コンテンツ配信変換装置において、ユニキャスト配信用に画面レイアウトや配信タイミングが記述されているメディア記述ファイルを、ブロードキャストやマルチキャスト配信用のメディア記述ファイルに変換して受信端末へ配信することにより、受信端末は当該変換後のメディア記述ファイルに従って画面レイアウトや配信タイミングを決定することが可能となる。
【００３０】
【発明の実施の形態】
以下、本発明に係るコンテンツ配信変換装置及びコンテンツ配信変換方法に関する各種の実施形態について順に説明する。
【００３１】
［第１実施形態］
図１には、本実施形態における配信システムのブロック構成図を示す。同図に示すネットワーク１は少なくともユニキャストで通信することが可能なネットワークであり、当該ネットワーク１には、１以上のコンテンツ配信装置（たとえばＨＴＴＰサーバやＲＴＳＰサーバ）１００、１１０と、１以上の配信変換装置３００、３５０とが接続されている。コンテンツ配信装置から配信変換装置へはユニキャストでコンテンツ配信が行われている。
【００３２】
一方、ネットワーク２及びネットワーク３はブロードキャストもしくはマルチキャストをサポートする同報配信可能なネットワークであり、当該ネットワーク上に１以上の配信変換装置と１以上の受信端末とが接続されている。配信変換装置３００は、ネットワーク２に接続されている受信端末２００や受信端末２１０に対し同報配信によりコンテンツ配信を行っている。一方、配信変換装置３５０は、ネットワーク２に接続されている受信端末２５０や受信端末２６０に対し同報配信によりコンテンツ配信を行っている。なお、図１ではネットワーク１、２、３を別のネットワークとして描いているが、物理的には同一のネットワークであってもよい。
【００３３】
図２には、配信変換装置３００における機能ブロック図の一例を示す。同図に示すように、配信変換装置は、配信制御処理部３０１、ユニキャスト送受信部３０２、コンテンツ取得制御処理部３０３、コネクション型プロトコル処理部３０４、コネクションレス型プロトコル処理部３０５、フォーマット変換部３０６、同報配信広告部３０７、コネクションレス型プロトコル処理部３０８及び同報配信処理部３０９から構成されている。
【００３４】
以下、配信変換装置３００の各機能を、図３に示すコンテンツ配信変換手順及び図４に示す配信変換装置３００の動作手順にしたがって説明する。
【００３５】
最初に、ユーザもしくは配信管理者による配信変換装置３００への配信制御記述情報の入力が行われる（図３、図４のＳ１０１）。入力方法としては、当該配信変換装置３００のコンソールから入力したり、遠隔にある受信端末や配信管理端末からＳＯＡＰ（Ｓｉｍｐｌｅ Ｏｂｊｅｃｔ Ａｃｃｅｓｓ Ｐｒｏｔｏｃｏｌ）やＨＴＴＰ等のプロトコルを用いて配信制御記述情報を配信変換装置３００に送信すること等により行われる。
【００３６】
ここで、図５を用いて配信制御記述情報の一例を説明する。図５では配信制御記述情報をＸＭＬ形式で記述している。＜ｂｐｍｌ＞エレメントにより、本記述情報が配信制御記述情報を意味していることを宣言している。そして、＜ｈｅａｄ＞と＜／ｈｅａｄ＞で囲まれる部分には、本情報で配信する番組のメタ情報が記述されている。たとえば、＜ｔｉｔｌｅ＞は本番組のタイトルを、＜ｉｎｆｏｒｍａｔｉｏｎ＞は本番組に関する情報を表している。また、＜ｕｒｌ＞、＜ｅｍａｉｌ＞、＜ｐｈｏｎｅ＞にはそれぞれ本番組に関連するホームページのＵＲＬ、電子メールアドレス、電話番号が記載されている。
【００３７】
＜ｂｏｄｙ＞と＜／ｂｏｄｙ＞で囲まれた部分には、例えば、ＳＭＩＬ（Ｓｙｎｃｈｒｏｎｉｚｅｄ Ｍｕｌｔｉｍｅｄｉａ Ｉｎｔｅｇｒａｔｉｏｎ Ｌａｎｇｕａｇｅ）の記述に従ってコンテンツの取得元と配信タイミングが記述されている。本例では＜ｓｅｑ＞エレメントにより、＜ｉｍｇ ｓｒｃ＝”ｈｔｔｐ：／／ｓｅｒｖｅｒ−１００／ｃｏｎｔｅｎｔ−Ａ．ｊｐｅｇ” ｄｕｒ＝”５ｍｉｎ”＞と＜ｉｍｇ ｓｒｃ＝”ｈｔｔｐ：／／ｓｅｒｖｅｒ−１００／ｃｏｎｔｅｎｔ−Ｂ．ｊｐｅｇ” ｄｕｒ＝”５ｍｉｎ”＞で示されるコンテンツを連続的に配信することを表している。そして、＜ｉｍｇ ｓｒｃ＝”ｈｔｔｐ：／／ｓｅｒｖｅｒ−１００／ｃｏｎｔｅｎｔ−Ａ．ｊｐｅｇ” ｄｕｒ＝”５ｍｉｎ”＞では、コンテンツの取得元がｈｔｔｐ：／／ｓｅｒｖｅｒ−１００／ｃｏｎｔｅｎｔ−Ａ．ｊｐｅｇであり、その配信時間が５分であることを表している。したがって、図の記述例ではｈｔｔｐ：／／ｓｅｒｖｅｒ−１００／ｃｏｎｔｅｎｔ−Ａ．ｊｐｅｇのコンテンツを最初の５分間配信し、続いてｈｔｔｐ：／／ｓｅｒｖｅｒ−１００／ｃｏｎｔｅｎｔ−Ｂ．ｊｐｅｇのコンテンツを５分間配信することを意味している。ここでは、ＳＭＩＬを用いた例を示したが、コンテンツの取得元と配信タイミングが記述されれば、特に、ＳＭＩＬに限定されるものではない。
【００３８】
次に、配信変換装置３００の配信制御処理部３０１は上記の配信制御記述情報を解釈して（図４のＳ１０２）、コンテンツ取得制御処理部３０３にコンテンツ取得の指示をする。図３および図５の例では、最初にコンテンツ配信装置１００（ｓｅｒｖｅｒ−１００）に蓄積されているｃｏｎｔｅｎｔ−Ａ．ｊｐｅｇの取得を指示することになり、コンテンツ取得制御処理部３０３はＨＴＴＰによりコンテンツ配信装置１００にｃｏｎｔｅｎｔ−Ａ．ｊｐｅｇの配信要求をユニキャスト送受信部３０２経由で行う。
【００３９】
コンテンツ配信装置１００は配信変換装置３００からの配信要求を受信したのち、当該コンテンツをパケットに分割しＴＣＰなどの信頼性のあるコネクション型のプロトコルを用いて配信変換装置３００に配信する。
【００４０】
ユニキャスト送受信部３０２は当該コンテンツを含むパケットを受信したのち、コネクション型プロトコル処理部３０４にパケットを渡し、コネクション型プロトコル処理部３０４では要求コンテンツを再構築する。こうして配信変換装置３００におけるコンテンツの取得が実行される（図３、図４のＳ１０３）。
【００４１】
続いて、配信変換装置３００は、ネットワーク２に対し当該取得コンテンツを同報配信する。配信制御処理部３０１には、当該コンテンツの配信範囲がユーザもしくは配信管理者によって設定されている。配信範囲は、たとえばＩＰパケットのＴＴＬ（Ｔｉｍｅ Ｔｏ Ｌｉｖｅ）値の設定によって行われる。ＴＴＬ値はルータを経由するごとに１ずつ減らされ、０になった時点で当該パケットは廃棄されるため、ＴＴＬが小さいほど当該ＩＰパケットの配信範囲は狭まれることになる。このように配信範囲を設定することによって、配信変換装置３００の近郊のみの同報配信にするか、もしくは広い範囲で受信することのできる同報配信にするかを決定することができるようになる。
【００４２】
配信制御処理部３０１は、同報配信広告部３０７に対し上述のように設定された配信範囲に配信情報を広告するように指示する。配信情報の広告は、たとえば、セッション・アナウンスメント・プロトコル（Ｓｅｓｓｉｏｎ Ａｎｎｏｕｎｃｅｍｅｎｔ Ｐｒｏｔｏｃｏｌ）などのプロトコルを用いて行われる。当該プロトコルを用いて送信されるメッセージ（以下、「セッション広告メッセージ」という）内にはＳＤＰ（Ｓｅｓｓｉｏｎ Ｄｅｓｃｒｉｐｔｉｏｎ Ｐｒｏｔｏｃｏｌ）により、配信情報が記述される。
【００４３】
ここで、図６を用いてセッション広告メッセージ内のＳＤＰ記述例を説明する。”ｖ＝０”はＳＤＰのバージョンが０であることを表す。”ｏ＝ａｂｃｄｅｆ １２３４ １ ＩＮ ＩＰ４ １２６．１６．６４．４”は当該同報セッションの識別子を表す。また、ｓ、ｉ、ｕ、ｅ、ｐから始まる行についてはそれぞれ当該セッションに関するタイトル、情報、ＵＲＬ、ｅ−ｍａｉｌアドレス、電話番号が含まれる。これらの情報は配信制御記述情報のメタ情報から抜き出され、ＳＤＰで記載される。また、”ｃ＝ＩＮ ＩＰ４ ２２４．２．１７．１２／１”では、当該同報セッションがＩＰｖ４のマルチキャスト用のＩＰアドレス２２４．２．１７．１２で配信され、そのＴＴＬ値が１であることを表している。当該ＴＴＬ値は、上述で配信制御処理部３０１にて設定された配信範囲にしたがって設定される。また”ｔ＝２８７３３９７４９６ ２８７３４０４６９６”は当該同報セッションの開始時刻と終了時刻をＮＴＰ（Ｎｅｔｗｏｒｋ Ｔｉｍｅ Ｐｒｏｔｏｃｏｌ）記述にしたがって設定する。”ｍ＝ａｐｐｌｉｃａｔｉｏｎ ３２４１６ ｕｄｐ ｊｐｅｇ”は当該同報セッションの中でＵＤＰのポート番号３２４１６のＪＰＥＧコンテンツが送信されていることを示している。
【００４４】
上記のようなセッション広告メッセージが同報配信処理部３０９を介してネットワーク２に周期的に送信される（図３、図４のＳ１０４）。
【００４５】
続けて、配信変換装置３００は上記でコンテンツ配信装置１００から取得したコンテンツをネットワーク２に配信する。配信変換装置３００では、コネクション型プロトコル処理部３０４で再構築したコンテンツを、コネクションレス型プロトコル処理部３０８に渡す。コネクションレス型プロトコル処理部３０８では、当該コンテンツをコネクションレスのプロトコル、たとえばＵＤＰ上にマッピングし、パケット化を行って、同報配信処理部３０９を介して同報配信を行う（図３、図４のＳ１０５）。図６のセッション広告メッセージの例ではＵＤＰポート番号を３２４１６に設定し、ＩＰアドレスを２２４．２．１７．１２、ＴＴＬを１としたＵＤＰ／ＩＰパケットを同報配信処理部３０９経由で送信することになる。
【００４６】
一般にコネクションレス型の通信ではコネクション型通信に比べて信頼性が低い。信頼性を高めるために、たとえば複数回同一パケットを図３に示すように繰り返し送信したり、ＦＥＣ（Ｆｏｒｗａｒｄ Ｅｒｒｏｒ Ｃｏｒｒｅｃｔｉｏｎ）用のパケットを付加するなどして、信頼性を高めることも可能である。
【００４７】
一方、受信端末２００や受信端末２１０は同報配信コンテンツを受信したい場合に、まず同報配信広告情報を取得する。上記の例ではセッション広告メッセージを取得することになる。そして、セッション広告メッセージから同報配信コンテンツに関する情報を取得し、同報配信コンテンツを受信するためのＩＰアドレスやフォーマット情報を知る。そして、当該同報配信コンテンツを受信し、活用することが可能となる。
【００４８】
Ｃｏｎｔｅｎｔ−Ａの配信時間が５分を経過した時点で、Ｃｏｎｔｅｎｔ−Ａの配信が終了し（図３、図４のＳ１０６）、配信変換装置３００の配信制御処理部３０１はコンテンツ取得制御処理部３０３に次のコンテンツＣｏｎｔｅｎｔ−Ｂの取得を指示する。コンテンツ取得制御処理部３０３は上記と同様にコンテンツ配信装置１００に対してＣｏｎｔｅｎｔ−Ｂの配信をＨＴＴＰで要求し（図３、図４のＳ１０７）、コンテンツ配信装置１００はＣｏｎｔｅｎｔ−Ｂをコネクション型プロトコルであるＴＣＰで配信する。配信変換装置３００のユニキャスト送受信部３０２を介して、コネクション型プロトコル処理部３０４は当該ＴＣＰパケットを受信すると、コンテンツを再構築し、当該コンテンツをコネクションレス型プロトコル処理部３０８に渡す。コネクションレス型プロトコル処理部３０８では、当該コンテンツをＵＤＰパケットに分割し、ネットワーク２上に同報配信する（図３、図４のＳ１０８）。受信端末２００および受信端末２１０は、ＵＤＰパケットで同報配信される当該コンテンツＣｏｎｔｅｎｔ−Ｂを受信し、当該端末にて活用することが可能となる。
【００４９】
そして、Ｃｏｎｔｅｎｔ−Ｂ配信後５分が経過した時点で、Ｃｏｎｔｅｎｔ−Ｂの同報配信を終了し（図３、図４のＳ１０９）、またセッション広告メッセージの同報配信も終了する（図４のＳ１１０）。
【００５０】
以上の第１実施形態によれば、以下の効果が得られる。コンテンツ配信装置１００がユニキャスト用のセッション制御しか備えていないＨＴＴＰサーバであっても、配信変換装置３００を介することによりネットワーク２上を同報形態でコンテンツを配信することが可能となり、特にネットワーク２が無線ネットワークなどの狭帯域なネットワークである場合には、ネットワークリソースの有効活用が可能となる。
また、配信変換装置３００においてユニキャスト用の制御プロトコルであるＨＴＴＰを、同報用の広告プロトコルであるセッション・アナウンスメント・プロトコルに変換することになるため、受信端末２００や受信端末２１０は、セッション・アナウンスメント・プロトコルを解釈する同報コンテンツ受信用の端末であればよく、コンテンツ配信装置１００の具備するＨＴＴＰを意識する必要がなくなる。
【００５１】
また、配信変換装置３００において、コネクション型プロトコルであるＴＣＰを用いて取得したコンテンツを、コネクションレス型プロトコルであるＵＤＰに変換して送信するため、受信端末はＴＣＰコネクションを張るための手続きやＴＣＰのＡＣＫパケット返送の処理が不要となり、大規模な同報配信が可能となる。
【００５２】
また、ユーザもしくは配信管理者が設定する配信制御記述情報によって、コンテンツの取得元や配信タイミングを制御することができるようになるため、ユーザが自分の見たいコンテンツを要求したり、配信管理者が放送番組をスケジューリングすることが可能となる。
【００５３】
また、ユーザもしくは配信管理者がコンテンツの同報配信範囲をＴＴＬ等で指定することにより、当該コンテンツの配信を特定の配信変換装置の近郊地域に限定するなど、位置に応じた適切なサービスを展開することが可能となる。
【００５４】
なお、本実施形態では、配信変換装置３００がコンテンツ配信装置１００にコンテンツを取得するタイミングとして、配信制御記述情報に従ってコンテンツを取得したが、必ずしもこれに従う必要はなく、たとえば最初にすべてのコンテンツを取得してから、同報配信を開始しても構わない。
【００５５】
また、本実施形態では、コンテンツを同報配信するコネクションレス型プロトコルとしてＵＤＰを例に挙げたが、コネクションレス型であればＵＤＰに限らず、ＲＴＰ（Ｒｅａｌ−ｔｉｍｅ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ）やデジタル放送規格のデータカルーセル方式を利用しても構わない。
【００５６】
また、本実施形態では、図４のようにＣｏｎｔｅｎｔ−Ａの同報配信が終了した（Ｓ１０６）後で、次のコンテンツＣｏｎｔｅｎｔ−Ｂの要求・取得をする（Ｓ１０７）例を説明したが、これらの順番は逆でもよいし、これらを同時に実行してもよい。
【００５７】
［第２実施形態］
前述した第１実施形態では、コネクション型プロトコルで取得したコンテンツをそのままコネクションレス型プロトコルで同報配信する例であったが、本実施形態ではコネクション型プロトコルで取得したコンテンツから内容を変換してコネクションレス型プロトコルで同報配信する形態を説明する。
【００５８】
なお、本実施形態の配信システムの構成、配信変換装置の構成はそれぞれ、第１実施形態で説明した図１の配信システムの構成、図２の配信変換装置３００の構成と同様であるので、説明を省略する。
【００５９】
本実施形態におけるコンテンツ配信変換手順を、図７及び図８に示す配信変換装置３００の動作手順にしたがって説明する。
【００６０】
はじめに、第１実施形態と同様に、ユーザもしくは配信管理者によって配信制御記述情報が配信変換装置３００に入力される（図７、図８のＳ２０１）。ここで、図９に示す配信制御記述情報が入力されたとする。第１実施形態との違いは、コンテンツが音声やビデオコンテンツである点である。
【００６１】
配信制御処理部３０１は上記配信制御記述情報から、当該同報配信コンテンツのメタ情報を＜ｈｅａｄ＞と＜／ｈｅａｄ＞で囲まれる部分から抜き出す。さらに、コンテンツ取得元として最初の５分間のコンテンツはｈｔｔｐ：／／ｓｅｒｖｅｒ−１００／ｃｏｎｔｅｎｔ−Ｘ．ｍｐ４から、次の５分間はｈｔｔｐ：／／ｓｅｒｖｅｒ−１００／ｃｏｎｔｅｎｔ−Ｙ．ｍｐ４からであることを解釈し、また、それぞれのコンテンツには音声コンテンツとビデオコンテンツが含まれていることを＜ａｕｄｉｏ＞エレメントと＜ｖｉｄｅｏ＞エレメントから判断する（図８のＳ２０２）。
【００６２】
配信制御処理部３０１は、上記解釈にもとづいて、コンテンツ取得制御処理部３０３に各コンテンツの取得を指示する。コンテンツ取得制御処理部３０３は、ユニキャスト送受信部３０２を介してｃｏｎｔｅｎｔ−Ｘとｃｏｎｔｅｎｔ−ＹをＨＴＴＰで順に要求し、コンテンツ配信装置１００はｃｏｎｔｅｎｔ−Ｘとｃｏｎｔｅｎｔ−Ｙを、コネクション型プロトコルのＴＣＰによって順に配信する。
【００６３】
配信変換装置３００では、コネクション型プロトコル処理部３０４において、上記コンテンツを再構築する。そして、再構築したコンテンツをフォーマット変換部３０６に渡す。フォーマット変換部３０６では当該コンテンツの中身を解析し、当該コンテンツがストリーミング用のコンテンツでなければ、第１実施形態と同様にコネクションレス型のプロトコルでコンテンツをそのまま同報配信する。一方、当該コンテンツがストリーミング用のコンテンツであれば、以下のストリーミング変換処理を行う。
【００６４】
なお、ここでストリーミング用のコンテンツかどうかの判断方法としては、たとえばコンテンツの拡張子（たとえばＭＰ４ファイルであるとか）で判断するか、またはコンテンツの内部にストリーミング用の付属情報（たとえばＭＰ４ファイルのヒントトラック情報）があるかどうかで判断するなどの方法が考えられる。
【００６５】
ストリーミング用のコンテンツであると判断された場合には、フォーマット変換部３０６において当該コンテンツからストリーミングフォーマットに変換する。ストリーミングフォーマットヘの変換は、通常ファイルから音声、ビデオペイロードを抜き出し、必要に応じてペイロードヘッダを付加した後、ＲＴＰにマッピングすることで行われる。
【００６６】
また、同報配信広告部３０７においては、セッション・アナウンスメント・プロトコルなどの広告用プロトコルによってストリーミングフォーマットのコンテンツが同報配信されることを広告する。セッション広告メッセージの一例を図１０に示す。図１０の上半分については第１実施形態と同様に、同報コンテンツのメタ情報が記述される。一方、図１０の下半分には、ビデオコンテンツとしてＨ．２６３で符号化されたＲＴＰストリームが、オーディオコンテンツとしてＡＭＲで符号化されたＲＴＰストリームが配信されていることを表している。これらの符号化情報はコンテンツ配信装置１００から取得したコンテンツ内のストリーミング用付属情報から抜き出すか、もしくはオーディオ・ビデオペイロードを解析することで得ることが可能である。
【００６７】
受信端末２００及び受信端末２１０は、上記セッション広告メッセージを受信することにより、オーディオコンテンツとビデオコンテンツがＲＴＰストリームとして同報配信されていることがわかり、当該ストリームを受信するために必要な情報（ＵＤＰポート番号やＲＴＰペイロードタイプ）を得ることができる。そして、これらの情報にもとづき、当該オーディオストリーム及びビデオストリームを受信・再生することが可能となる。
【００６８】
具体的には、配信変換装置３００は、Ｃｏｎｔｅｎｔ−Ｘの配信要求をコンテンツ配信装置１００に対して行って、コンテンツ配信装置１００からＣｏｎｔｅｎｔ−Ｘを取得し（図７、図８のＳ２０３）、セッション広告メッセージの同報配信を開始する（図７、図８のＳ２０４）。そして、Ｃｏｎｔｅｎｔ−Ｘをフォーマット変換し、受信端末２００や受信端末２１０への変換後のＣｏｎｔｅｎｔ−Ｘの同報配信を開始する（図７、図８のＳ２０５）。
【００６９】
配信変換装置３００は、Ｃｏｎｔｅｎｔ−Ｘの配信開始から５分後に、Ｃｏｎｔｅｎｔ−Ｘの配信を終了し（図７、図８のＳ２０６）、Ｃｏｎｔｅｎｔ−Ｙの配信要求をコンテンツ配信装置１００に対して行い、Ｃｏｎｔｅｎｔ−Ｙを取得する（図７、図８のＳ２０７）。そして、Ｃｏｎｔｅｎｔ−Ｙをフォーマット変換し、受信端末２００や受信端末２１０への変換後のＣｏｎｔｅｎｔ−Ｙの同報配信を開始する（図７、図８のＳ２０８）。Ｃｏｎｔｅｎｔ−ＹもＣｏｎｔｅｎｔ−Ｘと同様にＲＴＰストリームとして配信される。このため、受信端末２００及び受信端末２１０は、コンテンツが切り替わったことを意識せずに、そのままオーディオ及びビデオのＲＴＰストリームを受信・再生し続けることが可能である。
【００７０】
そして、Ｃｏｎｔｅｎｔ−Ｙ配信後５分が経過した時点で、Ｃｏｎｔｅｎｔ−Ｙの同報配信を終了し（図７、図８のＳ２０９）、またセッション広告メッセージの同報配信も終了する（図８のＳ２１０）。
【００７１】
以上の第２実施形態では、コンテンツ配信装置１００と配信変換装置３００の間は信頼性の高いコネクション型プロトコルによりコンテンツを伝送するため、たとえパケットロス等があっても回復することができる。
【００７２】
一方、配信変換装置３００と受信端末の間を第１実施形態のように、そのままコンテンツを同報配信するとなると、パケットロス耐性を向上させるために繰り返し配信が必要であったり、途中から受信を開始する受信端末があった場合に、コンテンツを一通り受信し終わらないと再生を開始できないという問題があった。第２実施形態では、配信変換装置３００と受信端末の間をストリーミングフォーマットで同報配信することにより、パケットロスによる音声・ビデオの多少に乱れは生じるものの、繰り返し配信などの冗長な配信が不要になり、また途中から受信を開始する受信端末もすぐにコンテンツの途中から再生を開始することが可能となる。
【００７３】
なお、本実施形態では、図８のようにＣｏｎｔｅｎｔ−Ｘの同報配信が終了した（Ｓ２０６）後で、次のコンテンツＣｏｎｔｅｎｔ−Ｙの要求・取得をする（Ｓ２０７）例を説明したが、これらの順番は逆でもよいし、これらを同時に実行してもよい。
【００７４】
［第３実施形態］
上記の第１、第２実施形態では、配信変換装置３００はコンテンツ配信装置１００からコンテンツをコネクション型プロトコルで取得していたが、本実施形態ではコンテンツ配信装置１００からコネクションレスのストリーミングフォーマットによりコンテンツを受信し、そのままストリーミングフォーマットで受信端末へ同報配信する例を説明する。
【００７５】
なお、本実施形態の配信システムの構成、配信変換装置の構成はそれぞれ、第１実施形態で説明した図１の配信システムの構成、図２の配信変換装置３００の構成と同様であるので、説明を省略する。
【００７６】
本実施形態におけるコンテンツ配信変換手順及び配信変換装置３００の動作手順を、図１１及び図１２にしたがって説明する。
【００７７】
はじめに、第１、第２実施形態と同様に、ユーザもしくは配信管理者により配信制御記述情報が配信変換装置３００に入力される（図１１、図１２のＳ３０１）。ここで、図１３に示す配信制御記述情報が入力されたとする。前記実施形態との違いは、コンテンツを取得するプロトコルとしてＨＴＴＰではなくＲＴＳＰを指定している点である。
【００７８】
配信制御処理部３０１は上記配信制御記述情報から、当該同報配信コンテンツのメタ情報を＜ｈｅａｄ＞と＜／ｈｅａｄ＞で囲まれる部分から抜き出す。さらに、コンテンツ取得元として最初の５分間のコンテンツはｒｔｓｐ：／／ｓｅｒｖｅｒ−１００／ｃｏｎｔｅｎｔ−Ｘ．ｍｐ４から、次の５分間はｒｔｓｐ：／／ｓｅｒｖｅｒ−１００／ｃｏｎｔｅｎｔ−Ｙ．ｍｐ４からであることを解釈し、また、それぞれのコンテンツには音声コンテンツとビデオコンテンツが含まれていることが＜ａｕｄｉｏ＞エレメントと＜ｖｉｄｅｏ＞エレメントから判断する（図１２のＳ３０２）。
【００７９】
配信制御処理部３０１は上記解釈にもとづいて、コンテンツ取得制御処理部３０３に各コンテンツの取得を指示する。コンテンツ取得制御処理部３０３はユニキャスト送受信部３０２を介してｃｏｎｔｅｎｔ−Ｘとｃｏｎｔｅｎｔ−Ｙを順にＲＴＳＰで要求する。このとき、コンテンツ配信装置１００と配信変換装置３００の間ではＲＴＳＰによるセッション確立のためのネゴシエーションが行われ、コンテンツ配信装置１００はこれから送信するオーディオ及びビデオストリームの符号化パラメータ等を配信変換装置３００に通知する。そしてネゴシエーションの後、コネクションレス型プロトコルのＲＴＰ／ＵＤＰを用いたストリーミングフォーマットでオーディオ及びビデオストリームを配信変換装置３００に配信する。
【００８０】
配信変換装置３００では、コネクションレス型プロトコル処理部３０５において、コンテンツ配信装置１００から配信されるオーディオ・ビデオストリームを受信する。そして、受信したストリームをコネクションレス型プロトコル処理部３０８に渡し、コネクションレス型プロトコル処理部３０８では当該ストリームを受信端末２００や受信端末２１０へ同じくＲＴＰ／ＵＤＰを用いたストリーミングフォーマットにより同報配信する。
【００８１】
一方、配信変換装置３００の配信制御処理部３０１は、当該コンテンツを同報配信するために同報配信広告部３０７に当該コンテンツの配信情報を広告するように指示する。当該配信情報は第２実施形態のセッション広告メッセージ（図１０）と同様である。ただし、第２実施形態ではメディアの符号化パラメータに関する情報をコンテンツ内のストリーミング用付属情報から抜き出すことにより取得可能であったが、本実施形態ではＲＴＳＰによってコンテンツ配信装置１００から通知される符号化パラメータから取得することが可能である。したがって、ＲＴＳＰにより取得した符号化パラメータ等の情報をセッション広告メッセージ内に記述することにより同報配信用の通知情報を生成することができる。
【００８２】
受信端末２００及び受信端末２１０は、上記セッション広告メッセージを受信することにより、オーディオコンテンツとビデオコンテンツがＲＴＰストリームとして同報配信されていることがわかり、当該ストリームを受信するために必要な情報（ＵＤＰポート番号やＲＴＰペイロードタイプ）を得ることができる。そして、これらの情報にもとづき、当該オーディオストリーム及びビデオストリームを受信・再生することが可能となる。
【００８３】
具体的には、配信変換装置３００は、Ｃｏｎｔｅｎｔ−Ｘの配信要求をコンテンツ配信装置１００に対して行い、Ｃｏｎｔｅｎｔ−Ｘのオーディオ・ビデオストリームの受信を開始し（図１１、図１２のＳ３０３）、セッション広告メッセージの同報配信を開始する（図１１、図１２のＳ３０４）。一方、当該ストリームを受信端末２００や受信端末２１０に対して同報配信を開始する（図１１、図１２のＳ３０５）。
【００８４】
配信変換装置３００は、Ｃｏｎｔｅｎｔ−Ｘの配信開始から５分後に、Ｃｏｎｔｅｎｔ−Ｘの配信を終了し（図１１、図１２のＳ３０６）、Ｃｏｎｔｅｎｔ−Ｙの配信要求をコンテンツ配信装置１００に対して行い、Ｃｏｎｔｅｎｔ−Ｙのオーディオ・ビデオストリームの受信を開始する（図１１、図１２のＳ３０７）。一方、当該ストリームを受信端末２００や受信端末２１０に対して同報配信を開始する（図１１、図１２のＳ３０８）。このため、受信端末２００及び受信端末２１０は、コンテンツが切り替わったことを意識せずに、そのままオーディオ及びビデオのＲＴＰストリームを受信・再生し続けることが可能である。
【００８５】
そして、Ｃｏｎｔｅｎｔ−Ｙ配信開始から５分が経過した時点で、Ｃｏｎｔｅｎｔ−Ｙの同報配信を終了し（図１１、図１２のＳ３０９）、またセッション広告メッセージの同報配信も終了する（図１２のＳ３１０）。
【００８６】
以上の第３実施形態によれば、以下の効果が得られる。従来、コンテンツ配信装置１００からＴＣＰなどのコネクション型プロトコルを用いてコンテンツ配信する場合、配信開始前に配信するコンテンツをすでにコンテンツ配信装置１００が保持していなければならず、コンテンツ配信途中に動的に生成されるコンテンツ、たとえばライブコンテンツなどに対して適用することができなかったが、本実施形態では、コンテンツ配信装置１００と配信変換装置３００の間をストリーミングフォーマットで伝送することにより、コンテンツ配信途中でも動的にコンテンツを生成できるため、コンテンツ配信装置１００で動的に生成されるコンテンツを配信変換装置３００経由で同報配信することが可能となる。
【００８７】
なお、本実施形態では、図１２のようにＣｏｎｔｅｎｔ−Ｘの同報配信が終了した（Ｓ３０６）後で、次のコンテンツＣｏｎｔｅｎｔ−Ｙの要求・受信開始を行う（Ｓ３０７）例を説明したが、これらの順番は逆でもよいし、これらを同時に実行してもよい。
【００８８】
ところで、上記３つの実施形態では、コンテンツ配信装置１００と配信変換装置３００の間はコネクション型プロトコルを用いてファイルを配信するか、又は、コネクションレス型プロトコルを用いてストリーミングフォーマットで配信するかのどちらかであったが、両方を併用してもかまわない。また、配信変換装置３００と受信端末２００及び受信端末２１０の間では、コンテンツ配信装置１００から取得したコンテンツをコネクションレス型プロトコルでファイルをそのまま伝送するか、又は、ストリーミングフォーマットで伝送するかのどちらかであったが、これらを併用してもかまわない。
【００８９】
例えば、配信変換装置３００はコンテンツ配信装置１００から静止画コンテンツとオーディオ・ビデオコンテンツをそれぞれＪＰＥＧファイルとＭＰ４ファイルとして取得し、ＪＰＥＧファイルはそのままファイルとして同報配信し、ＭＰ４ファイルだけをストリーミングフォーマットに変換して同報配信することも可能である。また、コンテンツ配信装置１００から静止画コンテンツをＪＰＥＧファイルとして受信し、そのままファイルとして同報配信する一方、オーディオ・ビデオコンテンツはコンテンツ配信装置１００からストリーミングフォーマットで受信し、そのままストリーミングフォーマットで同報配信することも可能である。
【００９０】
また、コンテンツの取得元として複数のコンテンツ配信装置からコンテンツを取得してもかまわない。たとえば、静止画コンテンツはコンテンツ配信装置１００から取得し、オーディオ・ビデオコンテンツは、図１に示すコンテンツ配信装置１１０から取得するのでもよい。
【００９１】
［第４実施形態］
上記の３つの実施形態では、同報配信するコンテンツとして静止画やテキストなどのコンテンツや、オーディオやビデオなどのストリームコンテンツを例としていたが、本実施形態では、レイアウト指定や配信タイミング指定を行うＳＭＩＬ等のメディア記述ファイルを同報配信する例を説明する。
【００９２】
なお、本実施形態の配信システムの構成、配信変換装置の構成はそれぞれ、第１実施形態で説明した図１の配信システムの構成、図２の配信変換装置３００の構成と同様であるので、説明を省略する。
【００９３】
本実施形態における同報配信手順及び配信変換装置３００の動作手順を、図１４及び図１５にしたがって説明する。
【００９４】
はじめに、上記の各実施形態と同様に、ユーザもしくは配信管理者により配信制御記述情報が配信変換装置３００に入力される（図１４、図１５のＳ４０１）。ここで、図１６に示すような配信制御記述情報が入力されたとする。第１〜第３実施形態との違いは、取得すべきコンテンツとしてＳＭＩＬファイルのみを指定している点である。
【００９５】
配信制御処理部３０１は上記の配信制御記述情報から、当該同報配信コンテンツのメタ情報を＜ｈｅａｄ＞と＜／ｈｅａｄ＞で囲まれる部分から抜き出す。次に、＜ｂｏｄｙ＞と＜／ｂｏｄｙ＞で囲まれる部分に記述されている＜ｓｍｉｌ ｓｒｃ＝ｈｔｔｐ：／／ｓｅｒｖｅｒ−１００／ＳＭＩＬ．ｓｍｉｌ＞からＳＭＩＬファイルの取得元を知る。配信制御処理部３０１は当該ＳＭＩＬファイルを取得するようにコンテンツ取得制御処理部３０３に指示を出し、コンテンツ配信装置１００に対して当該ＳＭＩＬファイルを要求する。そして、コネクション型プロトコル処理部３０４を介して当該ＳＭＩＬファイルを取得する（図１４、図１５のＳ４０２）。
【００９６】
ここでは、上記で取得されるＳＭＩＬファイルが図１７に示すユニキャスト配信用のＳＭＩＬファイルであったとする。図１７のＳＭＩＬファイルでは＜ｌａｙｏｕｔ＞と＜／ｌａｙｏｕｔ＞で囲まれる部分にレイアウト情報が記述されており、識別子”ａ”で特定される領域と、識別子”ｂ”で特定される領域の２つを指定している。一方、＜ｂｏｄｙ＞と＜／ｂｏｄｙ＞で囲まれる部分において、コンテンツの配信元と配信タイミングが記述されており、最初の５分間はｒｔｓｐ：／／ｓｅｒｖｅｒ−１００／ｃｏｎｔｅｎｔ−Ｘ．ｍｐ４からオーディオとビデオストリームを、ｈｔｔｐ：／／ｓｅｒｖｅｒ−１００／ｃｏｎｔｅｎｔ−Ｃ．ｈｔｍｌからＨＴＭＬコンテンツを配信するように指定している。また、ビデオストリームについては識別子”ａ”で特定される領域に表示し、ＨＴＭＬコンテンツについては識別子”ｂ”で特定される領域に表示することを表している。そして、次の５分間では、ｒｔｓｐ：／／ｓｅｒｖｅｒ−１００／ｃｏｎｔｅｎｔ−Ｙ．ｍｐ４からオーディオとビデオストリームを、ｈｔｔｐ：／／ｓｅｒｖｅｒ−１００／ｃｏｎｔｅｎｔ−Ｄ．ｈｔｍｌからＨＴＭＬコンテンツを配信するように指定し、上記と同様にビデオストリームについては識別子”ａ”で特定される領域に表示し、ＨＴＭＬコンテンツについては識別子”ｂ”で特定される領域に表示することを表している。
【００９７】
コネクション型プロトコル処理部３０４は上記ＳＭＩＬファイルを取得すると、フォーマット変換部３０６に当該ＳＭＩＬファイルを渡す。フォーマット変換部３０６はユニキャスト用に記述されたＳＭＩＬファイルを図１８に示すような同報配信用のＳＭＩＬファイルに変換する（図１４、図１５のＳ４０２）。具体的な変換方法は次の通りである。
【００９８】
ＳＭＩＬファイルに記述された情報のうち、レイアウト情報はそのままとする。そして＜ｂｏｄｙ＞に含まれる情報のうち、メディア種類が同じもので時間的に重ならず、かつ領域の指定がある場合に同一の領域に配置されるメディア情報を一つのメディア情報に縮退させる。たとえば、上記変換前のＳＭＩＬファイルの複数の＜ａｕｄｉｏ＞タグは一つの＜ａｕｄｉｏ＞タグに縮退される。また、当該変換前のＳＭＩＬファイルに記述されている複数の＜ｖｉｄｅｏ＞タグは同一の識別子”ａ”の領域に配置されるため、これらの＜ｖｉｄｅｏ＞タグも一つの＜ｖｉｄｅｏ＞タグに縮退される。同様に、ＨＴＭＬコンテンツも同一の識別子”ｂ”の領域に配置されるため、＜ｔｅｘｔ＞タグも一つのタグに縮退される。また、コンテンツ取得元としてＵＲＬで表記されていた部分を、同報配信時に使用するポート番号情報に置き換えている。これにより、指定されたポート番号宛に配信されるコンテンツをＳＭＩＬの指定どおりにレイアウト配置することが可能となる。
【００９９】
上述のようにフォーマット変換部３０６は、ユニキャスト用のＳＭＩＬファイルを同報配信用のＳＭＩＬファイルに変換するとともに、ＳＭＩＬファイルに記述される配信タイミング情報を配信制御処理部３０１に通知する。
【０１００】
配信制御処理部３０１は、フォーマット変換部３０６から通知された配信タイミング情報にもとづいて、コンテンツ取得制御処理部３０３に各コンテンツの取得を指示する。コンテンツ取得制御処理部３０３はユニキャスト送受信部３０２を介して、ｃｏｎｔｅｎｔ−ＣをＨＴＴＰで、ｃｏｎｔｅｎｔ−ＸをＲＴＳＰで、それぞれ要求し、取得する（図１４、図１５のＳ４０３）。
【０１０１】
続けて配信制御処理部３０１は、上記変換後のＳＭＩＬファイル及びｃｏｎｔｅｎｔ−Ｃ、ｃｏｎｔｅｎｔ−Ｘを同報配信するために同報配信広告部３０７に上記コンテンツの配信情報をセッション広告メッセージにより広告するように指示する。セッション広告メッセージの例を図１９に示す。図１９の上半分には、配信制御記述情報から取得できるメタ情報が記述されている。図１９の下半分の１行目”ｍ＝ａｐｐｌｉｃａｔｉｏｎ ４９１６６ ｕｄｐ ｓｍｉｌ”でＳＭＩＬファイルがＵＤＰでポート番号４９１６６に送信されることを示している。同様にＨＴＭＬはＵＤＰでポート番号４９１６８に、ビデオストリームはＨ．２６３符号化されてＲＴＰを用いてポート番号４９１７０に、そしてオーディオストリームはＡＭＲに符号化されてＲＴＰを用いてポート番号４９１７２に送信されることを表している。ここでＨＴＭＬ及びオーディオ・ビデオストリームの送信されるポート番号は変換後のＳＭＩＬファイルに記述されるポート番号と同一になるように設定される。
【０１０２】
上述のセッション広告メッセージの同報配信を開始するとともに、ＳＭＩＬファイルの同報配信も開始する（図１４、図１５のＳ４０４）。続いてｃｏｎｔｅｎｔ−Ｃ及びｃｏｎｔｅｎｔ−Ｘについてもそれぞれ同報配信を開始する（図１４、図１５のＳ４０５）。受信端末は、最初にセッション広告メッセージを取得し、同報配信されているコンテンツ及び当該コンテンツを取得するために必要な情報を知る。そして、続けてＳＭＩＬファイルを取得し、ＳＭＩＬファイルに記述されているレイアウト情報を知る。そして、ｃｏｎｔｅｎｔ−Ｃおよびｃｏｎｔｅｎｔ−Ｘを取得・受信を開始し、ＳＭＩＬファイルの記述にしたがって配置し、表示する。
【０１０３】
ｃｏｎｔｅｎｔ−Ｃ及びｃｏｎｔｅｎｔ−Ｘの同報配信後５分が経過した時点で、当該ｃｏｎｔｅｎｔ−Ｃ及びｃｏｎｔｅｎｔ−Ｘの同報配信が終了し（図１４、図１５のＳ４０６）、次の同報配信コンテンツであるｃｏｎｔｅｎｔ−Ｄとｃｏｎｔｅｎｔ−Ｙの取得・受信を開始し（図１４、図１５のＳ４０７）、当該コンテンツの同報配信を開始する（図１４、図１５のＳ４０８）。さらに５分が経過した時点で、ｃｏｎｔｅｎｔ−Ｄとｃｏｎｔｅｎｔ−Ｙの同報配信も終了し（図１４、図１５のＳ４０９）、つづいてＳＭＩＬファイル及びセッション広告メッセージの同報配信も終了する（図１５のＳ４１０）。
【０１０４】
以上の第４実施形態によれば、ＳＭＩＬファイルを配信変換装置３００から同報配信することにより、受信端末はＳＭＩＬファイルの記述にしたがってレイアウト配置することが可能となり、より高度なコンテンツ配信が可能となる。また、ユニキャスト用のＳＭＩＬファイルを配信変換装置３００で同報配信用のＳＭＩＬファイルに変換するため、コンテンツ作成者はユニキャスト用のＳＭＩＬファイルのみを用意していればよく、同報配信用のＳＭＩＬファイルを用意する必要がなくなる、という利点がある。
【０１０５】
なお、本実施形態では、図１５のようにＣｏｎｔｅｎｔ−Ｃ、Ｃｏｎｔｅｎｔ−Ｘの同報配信が終了した（Ｓ４０６）後で、次のコンテンツＣｏｎｔｅｎｔ−Ｄの要求・取得及びＣｏｎｔｅｎｔ−Ｙの要求・受信開始を行う（Ｓ４０７）例を説明したが、これらの順番は逆でもよいし、これらを同時に実行してもよい。
【０１０６】
【発明の効果】
以上説明したように、本発明によれば、ユニキャストを前提としたコンテンツ配信装置からでも、上述のコンテンツ配信変換装置を介することにより、１以上の受信端末へ同報配信することが可能となる。そのため、コンテンツ配信装置は同報配信のための特別なプロトコルを用意する必要がなく、ユニキャスト配信用のコンテンツを同報配信に使用することが可能となる。
【０１０７】
また、コンテンツ配信変換装置においてデータ転送用の制御プロトコルと同報配信用の広告プロトコルを変換するため、受信端末は、通常の同報配信用途で使用される広告プロトコルを解釈するだけですむようになり、実装の負荷を軽減することができる。
【０１０８】
また、コンテンツ配信変換装置において、コネクション型プロトコル、例えば、ＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）で取得したコンテンツをコネクションレス型プロトコル、例えば、ＵＤＰ（Ｕｓｅｒ Ｄａｔａｇｒａｍ Ｐｒｏｔｏｃｏｌ）に変換して送信することで、コネクション型プロトコルで取得した当該コンテンツを１以上の受信端末ヘコネクションレス型プロトコルで同報配信することが可能となり、より大規模なコンテンツ配信が可能となる。
【０１０９】
また、コンテンツ配信変換装置において、コネクション型プロトコル、例えば、ＴＣＰで取得したオーディオもしくはビデオコンテンツをストリーミングフォーマット、例えば、ＲＴＰに変換し、コネクションレス型プロトコル、例えば、ＵＤＰ上で送信することで、コンテンツ配信装置と配信変換装置の間はコネクション型プロトコルを利用して、高い信頼性のもとでコンテンツを取得し、配信変換装置と受信端末の間はストリーミングフォーマットで効率的にコンテンツを配信することが可能となる。
【０１１０】
また、コンテンツ配信変換装置において、ストリーミング用制御プロトコルにより配信されるストリーミングフォーマットのコンテンツを受信し、１以上の受信端末へ同報配信することで、ライブ配信などのリアルタイムに生成されるコンテンツも配信変換装置において同報することが可能となり、より大規模なコンテンツ配信が可能となる。
【図面の簡単な説明】
【図１】第１〜第４実施形態における配信システムのブロック図である。
【図２】第１〜第４実施形態における配信変換装置３００の機能ブロック図である。
【図３】第１実施形態における配信変換手順の一例を示すチャートである。
【図４】第１実施形態における配信変換装置３００の動作手順の一例を示す流れ図である。
【図５】第１実施形態における配信制御記述情報の一例を示す図である。
【図６】第１実施形態におけるセッション広告メッセージのＳＤＰ記述例を示す図である。
【図７】第２実施形態における配信変換手順の一例を示すチャートである。
【図８】第２実施形態における配信変換装置３００の動作手順の一例を示す流れ図である。
【図９】第２実施形態における配信制御記述情報の一例を示す図である。
【図１０】第２実施形態におけるセッション広告メッセージのＳＤＰ記述例を示す図である。
【図１１】第３実施形態における配信変換手順の一例を示すチャートである。
【図１２】第３実施形態における配信変換装置３００の動作手順の一例を示す流れ図である。
【図１３】第３実施形態における配信制御記述情報の一例を示す図である。
【図１４】第４実施形態における配信手順の一例を示すチャートである。
【図１５】第４実施形態における配信変換装置３００の動作手順の一例を示す流れ図である。
【図１６】第４実施形態における配信制御記述情報の一例を示す図である。
【図１７】第４実施形態における変換前のＳＭＩＬファイル記述例を示す図である。
【図１８】第４実施形態における変換後のＳＭＩＬファイル記述例を示す図である。
【図１９】第４実施形態におけるセッション広告メッセージのＳＤＰ記述例を示す図である。
【符号の説明】
１、２、３…ネットワーク、１００、１１０…コンテンツ配信装置、２００、２１０、２５０、２６０…受信端末、３００、３５０…配信変換装置、３０１…配信制御処理部、３０２…ユニキャスト送受信部、３０３…コンテンツ取得制御処理部、３０４…コネクション型プロトコル処理部、３０５…コネクションレス型プロトコル処理部、３０６…フォーマット変換部、３０７…同報配信広告部、３０８…コネクションレス型プロトコル処理部、３０９…同報配信処理部。

Claims (10)

1. コンテンツを保持したコンテンツ配信装置に対してデータ転送用の制御プロトコルを用いてコンテンツを要求するコンテンツ要求手段と、
   前記コンテンツをコネクション型のプロトコルにより前記コンテンツ配信装置から取得するコンテンツ取得手段と、
   前記コンテンツのフォーマット情報を含む広告メッセージを１以上の受信端末に対して繰り返し同報配信する広告メッセージ配信手段と、
   前記コンテンツをコネクションレス型のプロトコルにより１以上の受信端末に対して同報配信するコンテンツ配信手段と、
   を備えたコンテンツ配信変換装置。
2. 少なくとも音響データ及び映像データの何れかを含むコンテンツを保持したコンテンツ配信装置に対してデータ転送用の制御プロトコルを用いてコンテンツを要求するコンテンツ要求手段と、
   前記コンテンツをコネクション型のプロトコルにより前記コンテンツ配信装置から取得するコンテンツ取得手段と、
   前記コンテンツ内部から、前記コンテンツの符号化方法及び符号化パラメータに関する情報を抽出する情報抽出手段と、
   前記抽出した符号化方法及び符号化パラメータに関する情報を含む広告メッセージを１以上の受信端末に対して繰り返し同報配信する広告メッセージ配信手段と、
   前記コンテンツ内部の時間情報に基づいて、再生時刻を表すタイムスタンプ情報が各パケットのヘッダ部に記録されたストリーミングフォーマットに前記コンテンツを変換するコンテンツ変換手段と、
   変換後のコンテンツを１以上の受信端末へ同報配信するコンテンツ配信手段と、
   を備えたコンテンツ配信変換装置。
3. 少なくとも音響データ及び映像データの何れかを含むコンテンツを保持したコンテンツ配信装置に対してストリーミング用の制御プロトコルを用いてコンテンツを要求するコンテンツ要求手段と、
   前記コンテンツ配信装置からストリーミング用の制御プロトコルで通知される符号化方法及び符号化パラメータに関する情報を抽出する情報抽出手段と、
   再生時刻を表すタイムスタンプ情報が各パケットのヘッダ部に記録されたストリーミングフォーマットによって、前記コンテンツ配信装置から前記コンテンツを取得するコンテンツ取得手段と、
   前記抽出した符号化方法及び符号化パラメータに関する情報を含む広告メッセージを１以上の受信端末に対して繰り返し同報配信する広告メッセージ配信手段と、
   前記取得したストリーミングフォーマットのコンテンツを１以上の受信端末へ同報配信するコンテンツ配信手段と、
   を備えたコンテンツ配信変換装置。
4. 少なくともコンテンツの配信タイミング及びコンテンツの取得元が記述された配信制御記述情報を保持した制御情報保持手段をさらに備え、
   前記コンテンツ取得手段は、前記配信制御記述情報内に記述されたコンテンツ取得元の情報に基づいて、当該コンテンツ取得元からコンテンツを取得し、
   前記コンテンツ配信手段は、前記配信制御記述情報内に記述された配信タイミングの情報に基づいて、１以上の受信端末ヘのコンテンツ配信タイミングを決定する、
   ことを特徴とする請求項１〜３の何れか１項に記載のコンテンツ配信変換装置。
5. 前記配信制御記述情報は番組情報をさらに含み、
   当該番組情報は前記広告メッセージによって前記受信端末に同報配信される、
   ことを特徴とする請求項４記載のコンテンツ配信変換装置。
6. コンテンツを同報する同報配信範囲を制限する同報配信範囲制限手段をさらに備えたことを特徴とする請求項１〜５の何れか１項に記載のコンテンツ配信変換装置。
7. コンテンツの配信タイミング、コンテンツの取得元及びコンテンツの画面レイアウトが記述されたメディア記述ファイルを取得するメディア記述ファイル取得手段と、
   画面レイアウトにて同一の領域に配置される複数のコンテンツに関する画面レイアウトの記述を１つの記述に変換し、コンテンツの取得元に関する記述を前記広告メッセージに記述される情報形式に変換する記述変換手段と、
   当該変換後の記述を含むメディア記述ファイルを１以上の受信端末へ同報配信するメディア記述ファイル配信手段と、
   をさらに備えた請求項１〜６の何れか１項に記載のコンテンツ配信変換装置。
8. コンテンツを保持したコンテンツ配信装置に対してデータ転送用の制御プロトコルを用いてコンテンツを要求するコンテンツ要求工程と、
   前記コンテンツをコネクション型のプロトコルにより前記コンテンツ配信装置から取得するコンテンツ取得工程と、
   前記コンテンツのフォーマット情報を含む広告メッセージを１以上の受信端末に対して繰り返し同報配信する広告メッセージ配信工程と、
   前記コンテンツをコネクションレス型のプロトコルにより１以上の受信端末に対して同報配信するコンテンツ配信工程と、
   を有するコンテンツ配信変換方法。
9. 少なくとも音響データ及び映像データの何れかを含むコンテンツを保持したコンテンツ配信装置に対してデータ転送用の制御プロトコルを用いてコンテンツを要求するコンテンツ要求工程と、
   前記コンテンツをコネクション型のプロトコルにより前記コンテンツ配信装置から取得するコンテンツ取得工程と、
   前記コンテンツ内部から、前記コンテンツの符号化方法及び符号化パラメータに関する情報を抽出する情報抽出工程と、
   前記抽出した符号化方法及び符号化パラメータに関する情報を含む広告メッセージを１以上の受信端末に対して繰り返し同報配信する広告メッセージ配信工程と、
   前記コンテンツ内部の時間情報に基づいて、再生時刻を表すタイムスタンプ情報が各パケットのヘッダ部に記録されたストリーミングフォーマットに前記コンテンツを変換するコンテンツ変換工程と、
   変換後のコンテンツを１以上の受信端末へ同報配信するコンテンツ配信工程と、
   を有するコンテンツ配信変換方法。
10. 少なくとも音響データ及び映像データの何れかを含むコンテンツを保持したコンテンツ配信装置に対してストリーミング用の制御プロトコルを用いてコンテンツを要求するコンテンツ要求工程と、
    前記コンテンツ配信装置からストリーミング用の制御プロトコルで通知される符号化方法及び符号化パラメータに関する情報を抽出する情報抽出工程と、
    再生時刻を表すタイムスタンプ情報が各パケットのヘッダ部に記録されたストリーミングフォーマットによって、前記コンテンツ配信装置から前記コンテンツを取得するコンテンツ取得工程と、
    前記抽出した符号化方法及び符号化パラメータに関する情報を含む広告メッセージを１以上の受信端末に対して繰り返し同報配信する広告メッセージ配信工程と、
    前記取得したストリーミングフォーマットのコンテンツを１以上の受信端末へ同報配信するコンテンツ配信工程と、
    を有するコンテンツ配信変換方法。

Images