JPWO2018180572A1

JPWO2018180572A1 - 情報処理装置、受信装置、及び情報処理方法

Info

Publication number: JPWO2018180572A1
Application number: JP2019509270A
Authority: JP
Inventors: 山岸　靖明; 靖明山岸
Original assignee: Sony Corp
Current assignee: Sony Corp
Priority date: 2017-03-31
Filing date: 2018-03-16
Publication date: 2020-02-06
Anticipated expiration: 2038-03-16
Also published as: JP7160030B2; WO2018180572A1

Abstract

本技術は、放送に同期した通信経由のマルチキャスト配信を行うことができるようにする情報処理装置、受信装置、及び情報処理方法に関する。情報処理装置が、放送コンテンツと同時にマルチキャスト配信される通信コンテンツのマルチキャストセッションを事前に予約し、通信コンテンツが要求されたとき、マルチキャストセッションを利用して配信される通信コンテンツを要求元に転送する。本技術は、例えば、マルチキャスト配信されるコンテンツを転送する機器に適用することができる。

Description

本技術は、情報処理装置、受信装置、及び情報処理方法に関し、特に、放送に同期した通信経由のマルチキャスト配信を行うことができるようにした情報処理装置、受信装置、及び情報処理方法に関する。

コンテンツを配信するためのシステムとして、ユニキャスト配信を行うもののほか、一斉同報配信可能なブロードバンドネットワーク経由でマルチキャスト配信を行うための技術が提案されている（例えば、特許文献１参照）。

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

ところで、地上波放送等の放送に同期したブロードバンドネットワーク経由のマルチキャスト配信の方式が検討され始めているが、その技術方式は確立されておらず、放送に同期した通信経由のマルチキャスト配信を行うための方式の提案が要請されている。

本技術はこのような状況に鑑みてなされたものであり、放送に同期した通信経由のマルチキャスト配信を行うことができるようにするものである。

本技術の第１の側面の情報処理装置は、放送コンテンツと同時にマルチキャスト配信される通信コンテンツのマルチキャストセッションを事前に予約し、前記通信コンテンツが要求されたとき、前記マルチキャストセッションを利用して配信される前記通信コンテンツを要求元に転送する処理部を備える情報処理装置である。

本技術の第１の側面の情報処理装置は、独立した装置であってもよいし、１つの装置を構成している内部ブロックであってもよい。また、本技術の第１の側面の情報処理方法は、上述した本技術の第１の側面の情報処理装置に対応する情報処理方法である。

本技術の第１の側面の情報処理装置、及び情報処理方法においては、放送コンテンツと同時にマルチキャスト配信される通信コンテンツのマルチキャストセッションを事前に予約し、前記通信コンテンツが要求されたとき、前記マルチキャストセッションを利用して配信される前記通信コンテンツが要求元に転送される。

本技術の第２の側面の受信装置は、放送波として送信されてくる放送コンテンツを受信する第１の受信部と、マルチキャスト配信される通信コンテンツを、通信ネットワークを介して受信する第２の受信部と、第１のタイミングで、前記放送コンテンツと同時にマルチキャスト配信される前記通信コンテンツのマルチキャストセッションの開始を要求し、前記第１のタイミングよりも時間的に後の第２のタイミングで、前記通信コンテンツを要求する処理部とを備える受信装置である。

本技術の第２の側面の受信装置は、独立した装置であってもよいし、１つの装置を構成している内部ブロックであってもよい。また、本技術の第２の側面の情報処理方法は、上述した本技術の第２の側面の受信装置に対応する情報処理方法である。

本技術の第２の側面の受信装置、及び情報処理方法においては、放送波として送信されてくる放送コンテンツが受信され、マルチキャスト配信される通信コンテンツが、通信ネットワークを介して受信され、第１のタイミングで、前記放送コンテンツと同時にマルチキャスト配信される前記通信コンテンツのマルチキャストセッションの開始が要求され、前記第１のタイミングよりも時間的に後の第２のタイミングで、前記通信コンテンツが要求される。

本技術の第１の側面、及び第２の側面によれば、放送に同期した通信経由のマルチキャスト配信を行うことができる。

なお、ここに記載された効果は必ずしも限定されるものではなく、本開示中に記載されたいずれかの効果であってもよい。

本技術を適用したコンテンツ配信システムの構成例を示す図である。放送受信デバイスでの画面の表示例を示す図である。放送受信デバイスの構成例を示すブロック図である。処理部の構成の詳細を示すブロック図である。マルチキャスト終端デバイスの構成例を示すブロック図である。 nmc.sdpファイルの内容の例を示す図である。 sdpの記述例を示す図である。 nmc.sdpファイルの内容をhttp-postで送る場合のメッセージの例を示す図である。 nmc.sdpファイルURLをhttp-postで送る場合のメッセージの例を示す図である。 SDPの内容を、http-getのURLクエリ文字列として送る場合の例を示す図である。第１の配信方式での処理の流れを説明するフローチャートである。第１の配信方式での処理の流れを説明するフローチャートである。マルチキャスト予約通知関数を説明する図である。マルチキャスト解除通知関数を説明する図である。 MITの構造の例を示す図である。 MITに割り当てられるPIDの例を示す図である。 MITに割り当てられるテーブルIDの例を示す図である。マルチキャストセッション記述子の構造の例を示す図である。マルチキャストセッション記述子のタグ値の例を示す図である。第２の配信方式での処理の流れを説明するフローチャートである。第２の配信方式での処理の流れを説明するフローチャートである。第３の配信方式での処理の流れを説明するフローチャートである。第４の配信方式での処理の流れを説明するフローチャートである。第４の配信方式での処理の流れを説明するフローチャートである。第５の配信方式での処理の流れを説明するフローチャートである。第５の配信方式での処理の流れを説明するフローチャートである。第６の配信方式での処理の流れを説明するフローチャートである。第７の配信方式での処理の流れを説明するフローチャートである。第７の配信方式での処理の流れを説明するフローチャートである。第７の配信方式での処理の流れを説明するフローチャートである。第１のスタック構成の例を示す図である。第２のスタック構成の例を示す図である。第３のスタック構成の例を示す図である。第４のスタック構成の例を示す図である。第５のスタック構成の例を示す図である。第６のスタック構成の例を示す図である。第７のスタック構成の例を示す図である。第８のスタック構成の例を示す図である。第９のスタック構成の例を示す図である。第１０のスタック構成の例を示す図である。第１１のスタック構成の例を示す図である。第１２のスタック構成の例を示す図である。コンピュータの構成例を示す図である。

以下、図面を参照しながら本技術の実施の形態について説明する。なお、説明は以下の順序で行うものとする。

１．システムの構成
２．本技術のマルチキャスト配信方式
（１）第１の配信方式：放送アプリケーションがマルチキャスト参加を促す方式
（２）第２の配信方式：放送シグナリングがマルチキャスト参加を促す方式
（３）第３の配信方式：全チャンネルを事前予約する方式
（４）第４の配信方式：ブロードバンド配信シグナリングがマルチキャスト配信される場合に、放送アプリケーションがマルチキャスト参加を促す方式
（５）第５の配信方式：ブロードバンド配信シグナリングがユニキャスト配信される場合に、放送アプリケーションがマルチキャスト参加を促す方式
（６）第６の配信方式：ブロードバンド配信シグナリングがユニキャスト配信される場合に、放送シグナリングがマルチキャスト参加を促す方式
（７）第７の配信方式：ブロードバンドコンテンツの配信形式を、ユニキャスト配信からマルチキャスト配信に切り替える方式
３．本技術のプロトコルスタック構成
４．変形例
５．コンピュータの構成

＜１．システムの構成＞

（コンテンツ配信システムの構成例）
図１は、本技術を適用したコンテンツ配信システムの構成例を示す図である。

図１のコンテンツ配信システム１は、地上波放送等の放送に同期したブロードバンドネットワーク経由で、コンテンツを配信するためのシステムである。

図１において、コンテンツ配信システム１は、放送コンテンツマネジメントシステム１０、地上波放送向けストリームサーバ２０、地上波放送サーバ３０、ブロードバンド向けストリームサーバ４０、ブロードバンドサーバ５０、放送受信デバイス６０、及びマルチキャスト終端デバイス７０から構成される。

また、図１において、地上波放送サーバ３０と放送受信デバイス６０とは、地上波放送ネットワーク２を介して、一方向でデータの伝送が行われる。また、ブロードバンドサーバ５０とマルチキャスト終端デバイス７０とは、ブロードバンドネットワーク３を介して、双方向でデータの伝送が行われる。

ブロードバンドネットワーク３内には、マルチキャスト中継ルータ８０−１乃至８０−５等の複数のルータが設けられる。これらの複数のルータは、ルーティングテーブルに基づき、ブロードバンドネットワーク３を構成する異なるネットワーク間で、データを中継する。

なお、ブロードバンドネットワーク３としては、例えば、固定電話や携帯電話の通信キャリアにより提供されるNGN(Next Generation Network)等の通信網（通信回線）を用いることができる。

放送コンテンツマネジメントシステム１０は、コンテンツを生成し、地上波放送向けストリームサーバ２０及びブロードバンド向けストリームサーバ４０に提供する。ここで、コンテンツとしては、例えば、マルチキャストでの併用番組配信可能な放送番組と、そのマルチキャスト併用配信番組の元となる番組が生成される。

また、放送コンテンツマネジメントシステム１０は、放送アプリケーションやシグナリング等のデータを生成し、地上波放送向けストリームサーバ２０に提供する。

ここで、放送アプリケーションは、放送経由で配信されるアプリケーションであって、例えば、HTML5(HyperText Markup Language 5)等のマークアップ言語やJavaScript（登録商標）等のスクリプト言語で開発することができる。例えば、放送アプリケーションは、ハイブリッドキャストアプリケーション等のウェブアプリケーションとすることができる。また、シグナリングは、放送受信デバイス６０側で処理される制御情報である。

地上波放送向けストリームサーバ２０は、放送コンテンツマネジメントシステム１０から提供されるコンテンツを処理（例えば、エンコード等の処理）して、放送配信ストリームを生成し、地上波放送サーバ３０に提供する。

地上波放送サーバ３０は、地上波放送向けストリームサーバ２０から提供される放送配信ストリームと、放送コンテンツマネジメントシステム１０から提供される放送アプリケーションやシグナリングのデータを処理（例えば、多重化等の処理）する。地上波放送サーバ３０は、処理の結果得られる多重化ストリーム（地上波放送トランスポート）を送信する。

地上波放送サーバ３０から送信された多重化ストリームは、送信所や中継所等の地上波放送ネットワーク２を介して、放送波として、放送受信デバイス６０により受信される。

なお、地上波放送サーバ３０は、専用線などの所定の回線を介して、送信所に設置される送出設備に接続されている。この送信所内の送出設備が、地上波放送サーバ３０からのデータに対し、必要な処理（例えば、変調等の処理）を施すことで、その結果得られる放送波（放送信号）が、地上波放送ネットワーク２を介して送信される。以下の説明では、説明の簡略化のため、送信所内の送出設備により行われる処理については省略する。

放送受信デバイス６０は、例えば、テレビ受像機やセットトップボックス（STB：Set Top Box）、パーソナルコンピュータ、ゲーム機などの固定受信機、あるいは、スマートフォンや携帯電話機、タブレット型コンピュータなどのモバイル受信機として構成される。

また、放送受信デバイス６０は、ヘッドマウントディスプレイ（HMD：Head Mounted Display）などのウェアラブルコンピュータであってもよい。さらに、放送受信デバイス６０は、例えば車載テレビなどの自動車に搭載される機器であってもよい。このように、放送受信デバイス６０は、コンテンツの再生や録画が可能な機器であれば、いずれの機器であってもよい。

放送受信デバイス６０は、地上波放送ネットワーク２を介して送信されてくる放送波を受信して、処理（例えば、復調や多重分離、デコード等の処理）することで、地上波コンテンツを再生し、その映像と音声を出力する。ここでは、地上波コンテンツ（放送コンテンツ）として、例えば、マルチキャストでの併用番組配信可能な放送番組を再生することができる。

また、放送受信デバイス６０は、放送波から得られる多重化ストリームに含まれる放送アプリケーションを取得し、実行することができる。

一方で、ブロードバンド向けストリームサーバ４０は、放送コンテンツマネジメントシステム１０から提供されるコンテンツを処理（例えば、エンコード等の処理）して、ブロードバンド配信ストリームを生成し、ブロードバンドサーバ５０に提供する。

ブロードバンドサーバ５０は、ブロードバンド向けストリームサーバ４０から提供されるブロードバンド配信ストリームを処理（例えば、パケット化等の処理）する。ブロードバンドサーバ５０は、処理の結果得られるIPストリームを、マルチキャスト配信する。

なお、ここでは、ブロードバンドサーバ５０がマルチキャスト配信を行う場合を説明するが、ブロードバンドサーバ５０は、ユニキャスト配信を行うことも可能である。

ブロードバンドサーバ５０からマルチキャスト配信されたIPマルチキャストストリームは、ブロードバンドネットワーク３内の複数のマルチキャスト中継ルータ８０を経由して、マルチキャスト終端デバイス７０により受信される。

マルチキャスト終端デバイス７０は、例えば、ブロードバンドルータやゲートウェイ、専用のサーバ、テレビ受像機、セットトップボックス（STB）、ネットワークストレージ、ゲーム機などとして構成される。

マルチキャスト終端デバイス７０は、ブロードバンドネットワーク３内の複数のマルチキャスト中継ルータ８０を経由して受信されるIPマルチキャストストリームを処理し、放送受信デバイス６０に転送する。

なお、放送受信デバイス６０とマルチキャスト終端デバイス７０は、例えば、エンドユーザ宅に構築された家庭内LAN(Local Area Network)等の双方向ネットワークを介して相互に接続されている。

放送受信デバイス６０は、マルチキャスト終端デバイス７０から転送されてくるIPマルチキャストストリームを受信して、処理（例えば、デパケット化やデコード等の処理）することで、ブロードバンドコンテンツを再生し、その映像と音声を出力する。ここでは、ブロードバンドコンテンツ（通信コンテンツ）として、例えば、マルチキャスト併用配信番組を再生することができる。

ここで、放送受信デバイス６０においては、放送経由で配信された地上波コンテンツと、通信経由で配信（マルチキャスト配信）されたブロードバンドコンテンツを再生可能であるが、これらのコンテンツは、例えば、図２に示すような方法で切り替えられる。

すなわち、図２に示した放送受信デバイス６０において、図２のＡには、地上波コンテンツ（マルチキャストでの併用番組配信可能な放送番組）の再生時の様子を模式的に表している一方で、図２のＢには、ブロードバンドコンテンツ（マルチキャスト併用配信番組）の再生時の様子を模式的に表している。

図２のＡにおいて、地上波コンテンツの映像には、放送アプリケーションによって表示される画像６１Ａが重畳されており、この画像６１Ａの内容を確認したエンドユーザが、リモートコントローラ等を操作することで、放送受信デバイス６０では、再生対象のコンテンツが、例えば、2K解像度の地上波コンテンツ（図２のＡ）から、4K解像度のブロードバンドコンテンツ（図２のＢ）に切り替えられる。

一方で、図２のＢにおいて、ブロードバンドコンテンツの映像には、放送アプリケーションによって表示される画像６１Ｂが重畳されており、この画像６１Ｂの内容を確認したエンドユーザが、リモートコントローラ等を操作することで、放送受信デバイス６０では、再生対象のコンテンツが、例えば、4K解像度のブロードバンドコンテンツ（図２のＢ）から、2K解像度の地上波コンテンツ（図２のＡ）に切り替えられる。

このように、放送受信デバイス６０においては、放送アプリケーションによって、エンドユーザの意向に基づき、放送経由で配信されるストリーミングか、通信経由で配信されるストリーミングかの遷移を制御することになる。

以上のように構成されるコンテンツ配信システム１で行われる配信処理をまとめると、次のようになる。

すなわち、まず、放送コンテンツマネジメントシステム１０からの放送番組が、所定の編成情報に基づき送出される。この放送番組は、地上波放送向けストリームサーバ２０によって、地上波放送向けにエンコードされ、ブロードバンド向けストリームサーバ４０によって、ブロードバンド向けにエンコードされる。

ここでは、地上波放送向けの放送配信ストリームと、ブロードバンド向けのブロードバンド配信ストリームにおいて、画面解像度等のエンコードパラメタに相違がある場合、すなわち、例えば、地上波放送向けの配信では、2K解像度（2K-MPEG2）となり、ブロードバンド向けの配信では、4K解像度（4K-HEVC）となる場合などに対応するために、異なる方式でエンコードされる。

このようにしてエンコードされた番組は、地上波放送サーバ３０によって、地上波放送トランスポートプロトコルに従い、地上波放送ネットワーク２に送出されるとともに、ブロードバンドサーバ５０によって、ブロードバンドユニキャスト／マルチキャストトランスポートプロトコルに従い、ブロードバンドネットワーク３に送出される。

例えば、地上波放送トランスポートプロトコルとしては、MPEG2-TS/PHYフレームの場合には、MP4/MMT/UDP/IP/TLV/PHYフレームや、MP4/DASH/ROUTE(FLUTE)/UDP/IP/MPEG2-TS/PHYフレームなどが適用可能である。

また、例えば、ブロードバンドユニキャストプロトコルとしては、MP4/DASH/HTTP/TCP/IPなどが適用可能であり、ブロードバンドマルチキャストプロトコルとしては、MP4/DASH/ROUTE(FLUTE)/UDP/IPなどが適用可能である。

なお、"/"は、プロトコルスタックの階層構造における階層の区切りを意味し、"/"を挟んで左側の階層が、右側の階層よりも上位の階層であることを表している。

また、MMTはMPEG Media Transport，UDPはUser Datagram Protocol，IPはInternet Protocol，TLVはType Length Valueの略語である。また、DASHはDynamic Adaptive Streaming over HTTP，ROUTEはReal-time Object Delivery over Unidirectional Transport，FLUTEはFile Delivery over Unidirectional Transportの略語である。

これらのプロトコルスタックの詳細な構成は、図３１乃至図４２を参照して後述する。

なお、図１のコンテンツ配信システム１においては、説明を簡単にするために、１台の地上波放送サーバ３０と、１台のブロードバンドサーバ５０が設けられた場合を図示しているが、地上波放送サーバ３０とブロードバンドサーバ５０としては、例えば、放送局等の事業者ごとに、複数台のサーバを設けることができる。

また、図１のコンテンツ配信システム１では、１台の放送受信デバイス６０と、１台のマルチキャスト終端デバイス７０が設けられた場合を図示しているが、放送受信デバイス６０とマルチキャスト終端デバイス７０としては、例えば、エンドユーザ宅ごとに、複数台のデバイスを設けることができる。

さらにまた、図１には、放送受信デバイス６０とマルチキャスト終端デバイス７０が別々の機器として構成される場合を図示したが、放送受信デバイス６０とマルチキャスト終端デバイス７０とが一体化された機器（以下、同梱型デバイスともいう）として構成されるようにしてもよい。

例えば、マルチキャスト終端デバイス７０をマルチキャスト終端モジュールとして提供して、放送受信デバイス６０の機能に含めることで、同梱型デバイスとして構成することができる。なお、この同梱型デバイスでは、例えば家庭内LAN等を介して相互に通信を行う必要はない。

また、上述した図１の説明では、放送受信デバイス６０とマルチキャスト終端デバイス７０が、エンドユーザ宅内に配置されるとして説明したが、マルチキャスト終端デバイス７０は、エンドユーザ宅に限らず、例えば、ケーブルオペレータのヘッドエンドや、モバイル網の基地局などに設置されるようにして、より広範囲な領域をカバーできるようにしてもよい。

すなわち、例えば、マルチキャスト終端デバイス７０が、ケーブルオペレータのヘッドエンドに設置される場合、放送受信デバイス６０は、同一のエンドユーザ宅ではなく、ケーブルテレビのサービスを契約している各エンドユーザ宅内に設置されることになる。

また、例えば、マルチキャスト終端デバイス７０が、モバイル網の基地局に設置される場合、放送受信デバイス６０は、モバイルサービスを契約しているエンドユーザが、屋内又は屋外で所持しているデバイス（モバイル受信機）となる。

さらに、上述した図１の説明では、放送コンテンツの放送方式として、地上波放送を説明したが、例えば、放送衛星（BS：Broadcasting Satellite）や通信衛星（CS：Communications Satellite）を利用した衛星放送、あるいは、ケーブルを用いた有線放送（CATV：Common Antenna TeleVision）等の放送方式によって、放送コンテンツや放送アプリケーション等が配信されるようにしてもよい。

（放送受信デバイスの構成例）
図３は、図１の放送受信デバイス６０の構成例を示すブロック図である。

図３において、放送受信デバイス６０は、処理部１０１、入力部１０２、記憶部１０３、チューナ１０４、放送ミドルウェア１０５、DASHクライアント１０６、レンダラ１０７、出力部１０８、ブラウザ１０９、及び通信I/F１１０から構成される。

処理部１０１は、例えば、CPU(Central Processing Unit)やマイクロプロセッサ等から構成される。処理部１０１は、各種の演算処理や、各部の動作制御など、放送受信デバイス６０における中心的な処理装置として動作する。処理部１０１は、放送受信デバイス６０内の各部との間で、各種のデータをやりとりすることができる。

入力部１０２は、例えば、物理的なボタン等であり、エンドユーザの操作に応じた操作信号を、処理部１０１に供給する。処理部１０１は、入力部１０２から供給される操作信号に基づいて、各部の動作を制御する。

記憶部１０３は、例えば、半導体メモリやハードディスクドライブ（HDD：Hard Disk Drive）等から構成される。記憶部１０３は、処理部１０１からの制御に従い、各種のデータを記憶する。

チューナ１０４は、アンテナ１２１を介して、地上波放送ネットワーク２からの放送波を受信して処理し、その結果得られるデータを、放送ミドルウェア１０５に供給する。

放送ミドルウェア１０５は、チューナ１０４から供給されるデータを処理し、その結果得られるデータの種別に応じて、処理部１０１、DASHクライアント１０６、又はブラウザ１０９に供給する。

ここで、処理対象のデータのうち、地上波コンテンツのストリームデータ（DASHセグメント）は、DASHクライアント１０６に供給され、放送アプリケーションのデータは、ブラウザ１０９に供給される。また、シグナリングは、処理部１０１に供給される。

DASHクライアント１０６は、放送ミドルウェア１０５から供給されるDASHセグメントを処理し、その結果得られるビデオとオーディオのデータを、レンダラ１０７に供給される。なお、ここでは説明を省略しているが、このDASHセグメントを処理して得られるビデオとオーディオのデータは、デコーダによりデコードされた後に、レンダラ１０７に供給されることになる。

レンダラ１０７は、DASHクライアント１０６から供給されるビデオとオーディオのデータに対し、レンダリング処理を行い、その結果得られるデータを、出力部１０８に供給する。

出力部１０８は、レンダラ１０７から供給されるビデオとオーディオのデータを出力する。これにより、放送受信デバイス６０では、マルチキャストでの併用番組配信可能な放送番組等の地上波コンテンツが再生され、その映像や音声が出力される。

ブラウザ１０９は、例えばHTML5やJavaScript（登録商標）に対応したブラウザである。ブラウザ１０９は、放送ミドルウェア１０５から供給される放送アプリケーションのデータ（例えばHTML形式ファイルや画像ファイル）を処理し、その結果得られるデータを、出力部１０８に供給する。これにより、放送受信デバイス６０では、放送アプリケーションの画像（映像）が表示される。

通信I/F１１０は、通信インターフェース回路等から構成される。通信I/F１１０は、家庭内LAN等の双方向ネットワークを介してマルチキャスト終端デバイス７０と各種のデータのやりとりを行う。

ここで、受信対象のデータのうち、ブロードバンドコンテンツのストリームデータ（DASHセグメント）は、DASHクライアント１０６に供給される。なお、シグナリングやアプリケーションが通信経由で配信される場合には、シグナリングは、処理部１０１に供給され、アプリケーションは、ブラウザ１０９に供給される。

なお、これらの通信経由で取得されたデータに対する処理は、上述した放送経由で取得されたデータに対する処理と同様であるため、ここでは、その説明は省略するが、通信経由で取得されたブロードバンドコンテンツのストリームデータを処理することで、放送受信デバイス６０では、マルチキャスト併用配信番組等のブロードバンドコンテンツが再生され、その映像や音声が出力される。

なお、地上波コンテンツやブロードバンドコンテンツは、録画されるようにしてもよい。また、映像を表示するディスプレイや、音声を出力するスピーカは、放送受信デバイス６０の内部に設けるほか、外部に設けて出力部１０８からのデータが供給されるようにしてもよい。

放送受信デバイス６０は、以上のように構成される。

（処理部の構成）
図４は、図３の処理部１０１の構成の詳細を示すブロック図である。

図４において、処理部１０１は、放送制御部１３１、通信制御部１３２、ネット配信予約準備処理部１３３、及びシグナリング処理部１３４から構成される。

放送制御部１３１は、放送受信デバイス６０内の各部で行われる、放送経由で取得されるデータに対する処理を制御する。例えば、放送制御部１３１は、チューナ１０４、放送ミドルウェア１０５、DASHクライアント１０６、レンダラ１０７、及び出力部１０８を制御して、地上波コンテンツが再生されるようにする。

通信制御部１３２は、放送受信デバイス６０内の各部で行われる、通信経由で取得されるデータに対する処理を制御する。例えば、通信制御部１３２は、通信I/F１１０、DASHクライアント１０６、レンダラ１０７、及び出力部１０８を制御して、ブロードバンドコンテンツが再生されるようにする。

ネット配信予約準備処理部１３３は、放送アプリケーション又はシグナリングの解析結果に応じて、マルチキャスト終端デバイス７０に対し、ブロードバンドコンテンツのマルチキャストセッションの開始を要求する。

シグナリング処理部１３４は、放送ミドルウェア１０５が取得したシグナリングを処理し、その処理結果を放送制御部１３１に供給する。放送制御部１３１は、シグナリング処理部１３４からのシグナリングの処理結果に基づき、各部の動作を制御する。

（マルチキャスト終端デバイスの構成例）
図５は、図１のマルチキャスト終端デバイス７０の構成例を示すブロック図である。

図５において、マルチキャスト終端デバイス７０は、処理部２０１、通信I/F２０２、及び通信I/F２０２から構成される。

処理部２０１は、例えば、CPUやマイクロプロセッサ等から構成される。処理部２０１は、各種の演算処理や、各部の動作制御など、マルチキャスト終端デバイス７０における中心的な処理装置として動作する。

処理部２０１は、マルチキャストミドルウェア２３１、ウェブサーバ２３２、及びシグナリング処理部２３３から構成される。

マルチキャストミドルウェア２３１は、ブロードバンドコンテンツのマルチキャスト配信に関する処理を行う。

例えば、マルチキャストミドルウェア２３１は、放送受信デバイス６０からの要求に応じて、ブロードキャストコンテンツのマルチキャストセッションを事前に予約し（マルチキャストに参加し）、当該ブロードバンドコンテンツが要求されたとき、参加しているマルチキャストセッションを利用して配信されるブロードキャストコンテンツを、要求元の放送受信デバイス６０に転送する。

ここで、ウェブサーバ２３２上では、マルチキャスト終端モジュールがサーバサイドスクリプトとして稼働している。マルチキャストミドルウェア２３１は、マルチキャスト終端モジュールとの間で、各種のデータをやりとりする。

シグナリング処理部２３３は、ブロードバンドネットワーク３を経由して配信されるシグナリング（ブロードバンド配信シグナリング）を取得して解析する。このシグナリングの解析結果は、マルチキャストミドルウェア２３１に供給される。マルチキャストミドルウェア２３１は、シグナリングの解析結果に基づき、マルチキャストセッションの予約を行う。

通信I/F２０２は、例えば、通信インターフェース回路等から構成される。通信I/F２０２は、双方向ネットワーク（例えば、家庭内LAN等）を介して、放送受信デバイス６０との間で、各種のデータをやりとりする。

通信I/F２０３は、例えば、通信インターフェース回路等から構成され、ブロードバンドネットワーク３（のマルチキャスト中継ルータ８０）を介して、ブロードバンドサーバ５０との間で、各種のデータをやりとりする。

なお、説明の都合上、図５のマルチキャスト終端デバイス７０においては、通信I/F２０２と、通信I/F２０３の２つの通信I/Fを設けた構成を示しているが、それらの通信I/Fは一体となって、１つの通信I/Fから構成されるようにしてもよい。

マルチキャスト終端デバイス７０は、以上のように構成される。

＜２．本技術のマルチキャスト配信方式＞

ところで、ネットマルチキャスト地上波放送の実現を検討するにあたり、その典型的なユースケースの検討が始まっている。主なユースケースとしては、地上波放送が行われている最中に、同一の番組（地上波コンテンツ）よりも高画質のブロードバンドコンテンツのストリームが、ブロードバンドネットワーク３経由で配信されるケースが想定される。

このユースケースでは、一般のインターネットではなく、固定電話や携帯電話の通信キャリアが提供するCDN(Content Delivery Network)上のサーバを経由して、ブロードバンドコンテンツが配信される場合に、放送受信デバイス６０では、地上波放送ネットワーク２経由で、地上波コンテンツと同時に配信される放送アプリケーションを起動して、エンドユーザに対し、ブロードバンドコンテンツを視聴するかしないかを選択させる。

そして、エンドユーザが、ブロードバンドコンテンツの視聴を選択した場合には、放送アプリケーションが、例えば、DASHプレイヤ（図３のDASHクライアント１０６）を起動して、当該DASHプレイヤが、マルチキャスト終端デバイス７０（例えば、ブロードバンドルータ等）を介して、HTTP等のユニキャストプロトコルによって、高画質のブロードバンドコンテンツをストリーミング再生する。

このとき、通信キャリアのCDN内で、マルチキャストプロトコルの利用が前提となる場合に、マルチキャスト終端デバイス７０（例えば、ブロードバンドルータ等）が、CDN内で使用されるマルチキャストプロトコルを終端しなければならないが、その実現方法が検討される予定である。

本技術では、その１つの実現方法として、放送受信デバイス６０で実行される放送アプリケーションが、マルチキャスト終端デバイス７０（例えば、ブロードバンドルータ等）に対して、マルチキャストセッションの開始を依頼する方式を提案する。

なお、放送アプリケーションが、マルチキャストセッションの開始を依頼するタイミングは、エンドユーザが、ブロードバンドネットワーク３経由でのブロードバンドコンテンツの視聴を選択するとき、あるいは、マルチキャストセッション確立手順（例えば、マルチキャスト予約など）のプロトコルオーバヘッドを軽減するため、エンドユーザが選択するか否かにかかわらずマルチキャストセッション開始を依頼するなどのバリエーションがある。

以下、本技術が提案する方式の具体的な実施の形態として、第１の配信方式乃至第７の配信方式の７つの配信方式について説明する。

（１）第１の配信方式

第１の配信方式は、放送受信デバイス６０で実行される放送アプリケーションが、マルチキャスト終端デバイス７０（で稼働するマルチキャスト終端モジュール）に対して、マルチキャストセッションの開始を依頼する方式である。

すなわち、第１の配信方式では、放送受信デバイス６０において、マルチキャスト併用番組配信可能な放送番組のオンエア中に、地上波放送ネットワーク２を介してMPEG2-TS若しくはMMT上で転送されるか、又はブロードバンドネットワーク３を介して取得されるAIT(Application Information Table)により起動される放送アプリケーションが、API(Application Programming Interface)を介して、マルチキャスト終端モジュールのURL(Uniform Resource Locator)に、当該放送番組のマルチキャストアドレスの制御情報を通知する。

なお、マルチキャスト終端モジュールは、サーバサイドスクリプトとして、マルチキャスト終端デバイス７０のウェブサーバ２３２上で稼働している。

AITは、マルチキャスト併用番組配信可能な放送番組が開始されると同時か、あるいは放送番組の開始の少し前に放送開始され、放送番組の終わりに放送終了される。AITを受信した放送受信デバイス６０は、AITから得られる情報に基づき、放送アプリケーションを起動する。

この放送アプリケーションは、自身が起動すると同時に、マルチキャスト終端デバイス７０で稼働するマルチキャスト終端モジュールに対して、例えば、URLの後のクエリ文字列を付加して、対象のマルチキャストアドレスの制御情報、又はその制御情報が格納されたファイルのURLを渡すようにする。

例えば、マルチキャスト終端デバイス７０で稼働するモジュールのサーバサイドスクリプトのURLが、"http://localgateway/nmcm"である場合に、図６に示すようなnmc.sdpファイルの中身をhttp-postすることができる。なお、このURLで、"localgateway"は、"192.168.0.1:8080"のような、IPアドレスとポート番号の組に解決される文字列である。

また、ここでは、nmc.sdpファイルの中身をhttp-postする方法に限らず、例えば、nmc.sdpファイルのURLをhttp-postしたり、あるいは、http-getのURLのクエリ文字列のパラメタとして、同様の内容を渡したりしてもよい。なお、http-postとhttp-getは、HTTPで定義されているメソッドのうち、POSTメソッドとGETメソッドで実行される動作に相当するものである。

ここで、nmc.sdpファイルの内容は、例えば、放送アプリケーションが、HTML5やJavaScript（登録商標）等の言語で開発されている場合に、スクリプトの中にハードコードで、その内容を記述したり、あるいは、放送アプリケーションのリソースファイルの中の１つのファイルとして、nmc.sdpファイルを含めて転送したりすることで、放送受信デバイス６０に通知される。

図６は、nmc.sdpファイルの内容の例を示す図である。

なお、SDP(Session Description Protocol)は、セッション記述プロトコルであるため、nmc.sdpファイルは、セッション記述情報であるとも言える。

図６に示すように、nmc.sdpファイルには、送出サーバのIPアドレス、マルチキャストセッション内のチャネル数、各マルチキャストセッション内の各チャネルの宛先マルチキャストIPアドレスとUDPポート番号、FLUTEのTSI(Transport Session Identifier)、マルチキャストセッションの開始・終了時刻、プロトコルID、メディアの種類、データレート、FEC(Forward Error Correction)属性情報、及びサービス言語属性が含まれる。

マルチキャスト終端デバイス７０は、このnmc.sdpファイルの内容に基づいて、例えば、NGN(Next Generation Network)等のインターフェースを介して、QoS(Quality of Service)が保証されたCDN(Content Delivery Network)網側のプロトコルによって、マルチキャストセッション予約を行う。

図７は、SDPの記述例を示す図である。

図７においては、必須のプロトコルバージョン（v=）として、"0"が記述され、必須のセッションのオーナ情報（o=）として、"user123 2890844526 2890842807 IN IP6 2201:056D::112E:144A:1E24"が記述されている。

また、必須のセッション名（s=）として、"File delivery session example"が記述され、必須のセッション有効期間開始/終了時刻（t=）として、"2873397496 2873404696"が記述され、セッションレベルFEC属性（a=）として、"FEC-declaration:0 encoding-id=1"が記述されている。

また、IPアドレス（a=）として、" source-filter: incl IN IP6 * 2001:210:1:2:240:96FF:FE25:8EC9"が記述されている。ここでは、ソースIPアドレスとして、"2001:210:1:2:240:96FF:FE25:8EC9"を持ち、任意の宛先マルチキャストIPアドレスが指定される。

また、FLUTEのTSI（a=）として、"flute-tsi:3"が記述され、FLUTEセッションの属性（メディア種別、UDPのポート番号、プロトコル種）（m=）として、"application 12345 FLUTE/UDP 0"が記述され、宛先マルチキャストIPアドレス（c=）として、"IN IP6 FF1E:03AD::7F2E:172A:1E24/1"が記述される。

また、ビットレート（b=）として、"8000"が記述され、サービス言語属性（a=）として、"lang:EN(English)"が記述され、メディアレベルFEC属性（a=）として、"FEC:0"が指定される。

なお、図７の記述例では、セッション記述情報を、SDP形式で記述した場合の例を示したが、セッション記述情報は、例えば、XML(Extensible Markup Language)形式やJSON(JavaScript Object Notation)形式など、他の形式で記述するようにしてもよい。また、セッション記述情報は、テキスト形式の情報に限らず、バイナリ形式の情報であってもよい。

放送受信デバイス６０から、マルチキャスト終端デバイス７０に送られるメッセージとしては、例えば、図８又は図９に示すようなメッセージを送ることができる。

図８は、nmc.sdpファイルの内容をhttp-postで送る場合のメッセージの例を示す図である。

図８に示したメッセージは、HTTPリクエストであって、１行目のリクエスト行で、POSTメソッドが指定され、２行目のメッセージヘッダに、マルチキャスト終端デバイス７０のマルチキャスト終端モジュールのURLのホスト名（Host: localgateway）が記述される。

また、空白行を挟んで、メッセージボディとして、nmc.sdpファイルの内容が、直接記述される。

図９は、nmc.sdpファイルのURLをhttp-postで送る場合のメッセージの例を示す図である。

図９に示したメッセージは、HTTPリクエストであって、１行目のリクエスト行と２行目のメッセージヘッダの記述は、図８のメッセージと同様である。

また、空白行を挟んで、メッセージボディとして、nmc.sdpファイルのURLが記述される。例えば、このURLとしては、"http://a.com/nmc.sdp"が指定される。

マルチキャスト終端デバイス７０は、"http://a.com/nmc.sdp"であるURLに基づき、所定のサーバ等にアクセスすることで、nmc.sdpファイルを取得することができる。すなわち、nmc.sdpファイルのURLを送る場合には、いわば間接的にnmc.sdpファイルの内容が取得されることになる。

そして、マルチキャスト終端デバイス７０は、放送受信デバイス６０から送られてくるメッセージ、例えば、図８又は図９に示したメッセージに基づき、直接又は間接にnmc.sdpファイルの内容を取得して、マルチキャストセッション予約を行うことになる。

なお、nmc.sdpファイルの内容を、http-getのURLのクエリ文字列のパラメタとして通知する場合には、当該パラメタとして、例えば、図１０に示した内容を指定すればよい。

ここでは、URLの末尾に、"？"であるマークを付け、それに続けて「名前 = 値」の形式で記述するが、この名前として、図１０に示すような、"owner"，"sessionName"，"time"，"fecAttribute"，"address"，"tsi"，"sessionAttribute"，"destinationAddress","bitRate"，"language"，"mediaFecAttribute"が、その値とともに記述される。ただし、複数の値は、"&"であるマークで区切られる。

（第１の配信方式の処理）
次に、図１１及び図１２のフローチャートを参照して、第１の配信方式を採用した場合のコンテンツ配信システム１の各装置で実行される処理の流れを説明する。

なお、図１１及び図１２においては、説明の都合上、１台のマルチキャスト中継ルータ８０により行われる処理を示しているが、実際には、ブロードバンドネットワーク３内では、複数のマルチキャスト中継ルータ８０が多段に設置され、それらのマルチキャスト中継ルータ８０によって、データの中継が行われる。

ステップＳ１０１において、放送コンテンツマネジメントシステム１０は、番組等のコンテンツを生成する。ステップＳ１０１の処理で生成されたコンテンツは、放送向けストリームサーバ２０と、ブロードバンド向けストリームサーバ４０に送信される（Ｓ１０２）。

ステップＳ１１１において、放送向けストリームサーバ２０は、放送コンテンツマネジメントシステム１０から送信されてくるコンテンツを処理し、放送配信ストリームを生成する。ステップＳ１１１の処理で生成された放送配信ストリームは、地上波放送サーバ３０に送信される（Ｓ１１２）。

ステップＳ１２１において、ブロードバンド向けストリームサーバ４０は、放送コンテンツマネジメントシステム１０から送信されてくるコンテンツを処理し、ブロードバンド配信ストリームを生成する。ステップＳ１２１の処理で生成されたブロードバンド配信ストリームは、ブロードバンドサーバ５０に送信される（Ｓ１２２）。

ステップＳ１０３において、放送コンテンツマネジメントシステム１０は、放送アプリケーションを生成する。ステップＳ１０３の処理で生成された放送アプリケーションは、地上波放送サーバ３０に送信される（Ｓ１０４）。

地上波放送サーバ３０においては、放送向けストリームサーバ２０からの放送配信ストリームと、放送コンテンツマネジメントシステム１０からの放送アプリケーションが受信される。

ステップＳ１３１において、地上波放送サーバ３０は、受信された放送配信ストリームと、放送アプリケーションを処理（例えば、多重化等の処理）して、放送配信を行う。これにより、放送配信ストリームと放送アプリケーションの多重化ストリームを含む放送波が、地上波放送ネットワーク２を介して伝送される。

そして、地上波放送ネットワーク２を伝送された放送波は、放送受信デバイス６０において、アンテナ１２１を介してチューナ１０４によって受信され、その後段の放送ミドルウェア１０５やDASHクライアント１０６、ブラウザ１０９等によって処理される。

一方で、ブロードバンドサーバ５０においては、ブロードバンド向けストリームサーバ４０からのブロードバンド配信ストリームが受信される。

ステップＳ１４１において、ブロードバンドサーバ５０は、受信されたブロードバンド配信ストリームを処理（例えば、パケット化等の処理）して、マルチキャスト配信を行う。これにより、IPマルチキャストストリームが、ブロードバンドネットワーク３を介して伝送される。

ここで、ブロードバンドサーバ５０からマルチキャスト配信されたIPマルチキャストストリームを構成するマルチキャストパケット（IPパケット）は、ブロードバンドネットワーク３内で、ネットワーク間を相互に接続するマルチキャスト中継ルータ８０により受信され、複数のマルチキャスト中継ルータ８０の間で転送される。

図１２のステップＳ１８１において、放送受信デバイス６０の放送ミドルウェア１０５及びDASHクライアント１０６は、地上波放送ネットワーク２を介して受信された多重化ストリームを処理することで、地上波コンテンツを再生する。そして、放送受信デバイス６０では、レンダラ１０７によって、レンダリング処理が行われることで、マルチキャスト併用番組配信可能な放送番組としての地上波コンテンツの映像と音声が出力される。

ステップＳ１８２において、ブラウザ１０９は、AITに基づいて、放送ミドルウェア１０５により処理されたストリームから得られる放送アプリケーションを取得して起動する。なお、AITは、アプリケーション制御情報の一例であって、放送経由又は通信経由で取得される。

このようにして起動される放送アプリケーションが、ネット配信予約準備処理部１３３からの制御に従い、マルチキャスト終端デバイス７０で稼働するマルチキャスト終端モジュールに対し、ネット配信予約準備を通知する（Ｓ１８３）。

このネット配信予約準備通知では、放送受信デバイス６０において、ブラウザ１０９により実行される放送アプリケーションが、APIとして提供されるマルチキャスト予約通知関数（図１３の第１の引数）を利用して、マルチキャスト終端モジュールに対し、nmc.sdpファイルを通知することで、マルチキャストの予約指示がなされる。

ここで、図１３を参照して、マルチキャスト予約通知関数について説明する。

multicastJoin()は、マルチキャストセッション参加を依頼するためのマルチキャスト予約通知関数であって、その第１の引数として、マルチキャストセッション記述（例えば、nmc.sdpファイル）が渡される。また、その戻り値として、第１の引数で渡したマルチキャストセッション記述が返された場合には、処理が成功したことを意味し、nullが返された場合には、処理が失敗したことを意味する。

このように、マルチキャスト予約通知関数は、第１の引数で渡すマルチキャストセッション記述（例えば、nmc.sdpファイル）の内容を、マルチキャスト終端デバイス７０に渡して、マルチキャストセッション予約を依頼する関数である。

なお、この第１の配信方式では、multicastJoin()の引数として、第１の引数を渡すことになるが、第２の引数としてのサービス識別子を渡すようにしてもよい。第２の引数を渡した場合、その戻り値として、第２の引数で渡したサービス識別子が返されたときには、処理が成功したことを意味し、nullが返されたときには、処理が失敗したことを意味する。

このように、マルチキャスト予約通知関数は、第２の引数で渡すサービス識別子を、マルチキャスト終端デバイス７０に渡して、マルチキャストセッション予約を依頼する関数である。なお、マルチキャスト予約通知関数を利用する際に、引数として第２の引数（サービス識別子）を渡す配信方式としては、例えば、後述する第４の配信方式や第５の配信方式が想定される。

図１２の説明に戻り、マルチキャスト終端デバイス７０においては、放送受信デバイス６０から通知されるnmc.sdpファイルが受信される。なお、ここでは、図８乃至図１０に示したように、nmc.sdpファイルの内容や、URLをhttp-postで送る方法、http-getのURLのクエリ文字列のパラメタに指定する方法などを用いることができる。

ステップＳ１６１において、マルチキャスト終端デバイス７０のマルチキャストミドルウェア２３１は、nmc.sdpファイルの内容に基づいて、ブロードバンドネットワーク３内のマルチキャスト中継ルータ８０に対し、マルチキャストの予約を行うことで、マルチキャスト（マルチキャストグループ）に参加する。

マルチキャスト中継ルータ８０においては、マルチキャスト終端デバイス７０がマルチキャストに参加する場合、ステップＳ１５１の処理が実行される。すなわち、ステップＳ１５１において、マルチキャスト中継ルータ８０は、ブロードバンドサーバ５０からマルチキャスト配信されたIPマルチキャストストリームを、マルチキャスト終端デバイス７０に転送する。

このようにして、マルチキャスト中継ルータ８０ではマルチキャスト転送が開始され、IPマルチキャストストリームが、マルチキャスト終端デバイス７０により受信される。

すなわち、マルチキャスト中継ルータ８０では、IPマルチキャストストリームの中継を行う場合、複数のマルチキャスト中継ルータ８０の間のマルチキャストツリー（経路情報）が動的に生成されるが、第１の配信方式では、マルチキャスト終端デバイス７０が、マルチキャスト（マルチキャストグループ）に参加したとき、マルチキャストツリーが生成されるようにしている。

これにより、放送受信デバイス６０からブロードバンドコンテンツが要求されるよりも前に、マルチキャストツリーが生成され、IPマルチキャストストリームが、マルチキャスト中継ルータ８０からマルチキャスト終端デバイス７０にまで転送されているため、放送受信デバイス６０からブロードバンドコンテンツが要求されたときには、直ちに、IPマルチキャストストリームを転送することが可能となる。

言うなれば、マルチキャスト終端デバイス７０がマルチキャストに参加するまでは、ブロードバンドネットワーク３内で多段に構成されるマルチキャスト中継ルータ８０によって、IPマルチキャストストリームがせき止めてられているとも言える。

すなわち、このようにしてIPマルチキャストストリームをせき止めるのは、ブロードバンドネットワーク３内で、データの中継を行う複数のマルチキャスト中継ルータ８０のうち、いずれかのマルチキャスト中継ルータ８０であって、マルチキャスト終端デバイス７０がマルチキャストに参加して、マルチキャストツリーが生成されることで、対象のIPマルチキャストストリーム（を構成するマルチキャストパケット）の経路が確定される。

ただし、IPマルチキャストストリームをせき止めるのは、マルチキャスト中継ルータ８０に限らず、ブロードバンドサーバ５０であってもよく、この場合には、マルチキャスト終端デバイス７０がマルチキャストに参加したときに、ブロードバンドサーバ５０によって、マルチキャスト配信が開始されることになる。

また、このようにして確定されるIPマルチキャストストリーム（を構成するマルチキャストパケット）の経路は、放送受信デバイス６０（の放送アプリケーション）からのネット配信予約準備通知に応じたマルチキャストツリーによるものであって、いわば優先度が高いために取捨選択された経路であるため、ブロードバンドネットワーク３への負荷を抑えることができる。

ここで、放送受信デバイス６０において、ブロードバンドコンテンツの要求がなされた場合、そのリクエストが通知され（Ｓ１８４）、マルチキャスト終端デバイス７０により受信される。

ここでは、例えば、図２に示したように、放送アプリケーションが、エンドユーザに対し、ブロードバンドコンテンツを視聴するかどうかを選択させるための表示を行い、エンドユーザが、ブロードバンドコンテンツの視聴を選択した場合に、ブロードバンドコンテンツの要求がなされる。

ステップＳ１６２において、マルチキャスト終端デバイス７０のマルチキャストミドルウェア２３１は、マルチキャスト中継ルータ８０からマルチキャスト転送されたIPマルチキャストストリームに含まれるブロードバンドコンテンツを、放送受信デバイス６０に転送する。

放送受信デバイス６０においては、通信I/F１１０によって、マルチキャスト終端デバイス７０からのブロードバンドコンテンツ（を含むIPマルチキャストストリーム）が受信される。

ステップＳ１８５において、DASHクライアント１０６は、ブロードバンドネットワーク３を介して受信されたIPマルチキャストストリームを処理することで、ブロードバンドコンテンツを再生する。そして、放送受信デバイス６０では、レンダラ１０７によって、レンダリング処理が行われることで、マルチキャスト併用配信番組としてのブロードバンドコンテンツの映像と音声が出力される。

なお、このとき、DASHクライアント１０６は、マルチキャスト終端デバイス７０からMPD(Media Presentation Description)を必要に応じて取得し、IPマルチキャストストリームから得られるDASHセグメントを処理して、ブロードバンドコンテンツが再生されるようにしてもよい。ここで、MPDは、MPEG-DASH(Dynamic Adaptive Streaming over HTTP)に準拠したストリーミング配信を行うために用いられるビデオやオーディオのファイルの制御情報である。

その後、ブロードバンドコンテンツの再生を終了する場合には、放送アプリケーションが、マルチキャスト終端デバイス７０に対し、ネット配信予約解除を通知する（Ｓ１８６）。

このネット配信予約解除では、放送受信デバイス６０において、ブラウザ１０９により実行される放送アプリケーションが、APIとして提供されるマルチキャスト解除通知関数を利用して、マルチキャスト終端デバイス７０で稼働しているマルチキャスト終端モジュールに対し、nmc.sdpファイルを通知することで、マルチキャストの離脱指示がなされる。

ここで、図１４を参照して、マルチキャスト解除通知関数について説明する。

multicastLeave()は、マルチキャストセッション離脱を依頼するためのマルチキャスト解除通知関数であって、その第１の引数として、マルチキャストセッション記述（例えば、nmc.sdpファイル）が渡される。また、その戻り値として、第１の引数で渡したマルチキャストセッション記述が返された場合には、処理が成功したことを意味し、nullが返された場合には、処理が失敗したことを意味する。

このように、マルチキャスト解除通知関数は、第１の引数で渡すマルチキャストセッション記述（例えば、nmc.sdpファイル）の内容を、マルチキャスト終端デバイス７０に渡して、マルチキャストセッション離脱を依頼する関数である。

なお、この第１の配信方式では、multicastLeave()の引数として、第１の引数を渡すことになるが、第２の引数としてのサービス識別子を渡すようにしてもよい。第２の引数を渡した場合、その戻り値として、第２の引数で渡したサービス識別子が返されたときには、処理が成功したことを意味し、nullが返されたときには、処理が失敗したことを意味する。

このように、マルチキャスト解除通知関数は、第２の引数で渡すサービス識別子を、マルチキャスト終端デバイス７０に渡して、マルチキャストセッション離脱を依頼する関数である。なお、マルチキャスト解除通知関数を利用する際に、引数として第２の引数（サービス識別子）を渡す配信方式としては、例えば、後述する第４の配信方式や第５の配信方式が想定される。

図１２の説明に戻り、マルチキャスト終端デバイス７０においては、放送受信デバイス６０からのnmc.sdpファイルが受信される。なお、ここでは、図８乃至図１０に示したように、nmc.sdpファイルの内容や、URLをhttp-postで送る方法、http-getのURLのクエリ文字列のパラメタに指定する方法などを用いることができる。

ステップＳ１６３において、マルチキャスト終端デバイス７０のマルチキャストミドルウェア２３１は、nmc.sdpファイルの内容に基づいて、ブロードバンドネットワーク３内のマルチキャスト中継ルータ８０に対し、マルチキャストの参加を取り消すことで、マルチキャストから離脱する。

マルチキャスト中継ルータ８０においては、マルチキャスト終端デバイス７０がマルチキャストから離脱する場合、ステップＳ１５２の処理が実行される。すなわち、ステップＳ１５２において、マルチキャスト中継ルータ８０は、ブロードバンドサーバ５０からマルチキャスト配信されたIPマルチキャストストリームを、マルチキャスト終端デバイス７０に転送するのを停止する。

一方で、放送受信デバイス６０においては、地上波放送ネットワーク２を介して、地上波放送サーバ３０から放送配信された多重化ストリームが受信され、地上波コンテンツの再生が再開される（Ｓ１３２，Ｓ１８７）。

すなわち、マルチキャスト終端デバイス７０が、参加していたマルチキャストから離脱すると、放送受信デバイス６０では、ブロードバンド配信ストリームが受信できなくなるが、放送配信ストリームの受信が再開されるため、再生対象のコンテンツが、ブロードバンドコンテンツから地上波コンテンツに切り替えられる。

ここで、上述したステップＳ１６１，Ｓ１５１，Ｓ１６２の処理、すなわち、ブロードバンドネットワーク３において、複数のマルチキャスト中継ルータ８０によって行われるデータの中継処理は、次のように行われる。

すなわち、本技術では、マルチキャスト終端デバイス７０がマルチキャストに参加することで（Ｓ１６１）、マルチキャストの優先予約を行っているが、この優先予約が必要となる理由は次の通りである。

一般的なIPTV(Internet Protocol TV)によるIP放送方式として、マルチキャストプロトコルが利用されているが、IPマルチキャストプロトコルをサポートするマルチキャストルータ（例えば、マルチキャスト中継ルータ８０）では、自身に接続されたネットワークセグメント上に、個々のマルチキャストグループに参加しているクライアント装置（例えば、放送受信デバイス６０）が存在するか否かを管理するために、IGMP(Internet Group Management Protocol)等のマルチキャストグループマネジメントプロトコルを利用する。

マルチキャスト配信を受信するクライアント装置は、所望のマルチキャストが行われるマルチキャストアドレスを指定して、マルチキャストルータに対し、マルチキャストグループマネジメントプロトコルによって、マルチキャストグループへの参加を宣言する。

マルチキャストルータは、マルチキャストツリーを構成する上位のルータから、マルチキャストパケットを受け取ると、自身に接続されたネットワークセグメント上に、そのマルチキャストグループに参加しているクライアント装置がある場合にのみ、そのマルチキャストパケットを、当該ネットワークセグメントへ送出する。また、クライアント装置は、マルチキャスト配信の受信を止める場合には、マルチキャストルータに対して、マルチキャストグループからの離脱を宣言する。

ここで、マルチキャストルータが、ホームネットワークとアクセスネットワークとの境界に位置し、ホームネットワークセグメント上に、クライアント装置が接続されているものとする。このクライアント装置において、IPマルチキャストストリームの選択や切り替え（チャンネルの選択や切り替え）が行われると、その都度、マルチキャストルータに対し、当該マルチキャストへの参加又は離脱が行われる。

一般に、マルチキャストの参加又は離脱の処理は、時間がかかるため、選択や切り替えの度に、画面が途絶える場合があって、例えば、アナログテレビで頻繁なチャンネル切り替え（いわゆるチャンネルザッピング）に慣れ親しんだエンドユーザにとっては、レスポンスの悪さが耐えられないことも想定される。

このような問題に対処するために、インテリジェントなマルチキャストルータにおいては、あらかじめ自身に接続されているホームネットワーク上のクライアント装置を使用するエンドユーザが選択しえる複数のチャンネルに対応するマルチキャストグループに参加（例えば、あらかじめ数十チャンネルに対応するマルチキャストグループに参加）しておき、当該マルチキャストルータよりも上位のマルチキャストツリーの切り替えのオーバーヘッドを低減させる方法が考えられる。

しかしながら、このような方法を採用した場合、アクセスネットワークに接続されるマルチキャストルータが増加するにつれ、あらかじめ参加しておかなければならないマルチキャストグループの数が増加して、アクセスネットワーク上に非常に多くのIPマルチキャストストリームが流れることになる。その結果、ネットワークに多大な負荷がかかって、キャパシティオーバーフローが起こり、逆にレスポンスが悪化してしまう。

なお、異なるマルチキャストルータから同一のマルチキャストアドレスに対する参加が行われ、複数のマルチキャストルータで共有されるIPマルチキャストストリームがあるにせよ、あらかじめ参加しておかなければならないマルチキャストグループの数が増加することに変わりはない。

そのため、このアクセスネットワーク上に常時流れるIPマルチキャストストリームの数を抑え、かつ、チャンネルザッピングのオーバーヘッドを極力抑えるためには、個々のマルチキャストルータが参加しておくマルチキャストグループに優先度をつけて、あらかじめエンドユーザが選択しそうなマルチキャストグループを取捨選択して、参加しておく必要がある。

そこで、第１の配信方式では、マルチキャスト終端デバイス７０が、マルチキャスト（マルチキャストグループ）に参加したときに、マルチキャストツリーが生成されるようにすることで、放送受信デバイス６０からブロードバンドコンテンツが要求されるよりも前に、放送受信デバイス６０（の放送アプリケーション）からのネット配信予約準備通知に応じたマルチキャストツリーが生成されるようにしている。

そのため、放送受信デバイス６０からブロードバンドコンテンツが要求されるよりも前に、IPマルチキャストストリームが、マルチキャスト中継ルータ８０からマルチキャスト終端デバイス７０にまで転送されているため、放送受信デバイス６０からブロードバンドコンテンツが要求されたときには、直ちに、IPマルチキャストストリームを転送することが可能となる。

また、このIPマルチキャストストリーム（を構成するマルチキャストパケット）の経路は、放送受信デバイス６０（の放送アプリケーション）からのネット配信予約準備通知に応じたマルチキャストツリーによるものであって、いわば優先度が高いために取捨選択されたものとなるため、ブロードバンドネットワーク３への負荷を抑えることができる。

以上、第１の配信方式を採用した場合の処理の流れを説明した。

（２）第２の配信方式

第２の配信方式は、nmc.sdpファイル又はそれと等価な内容を格納したマルチキャスト情報テーブル（以下、MIT(Multicast Information Table)ともいう）を利用して、マルチキャスト終端デバイス７０（で稼働するマルチキャスト終端モジュール）に対して、マルチキャストセッションの開始を依頼する方式である。

図１５は、MITの構造の例を示す図である。

MITは、例えば、PSI/SI(Program Specific Information / Service Information)に含まれ、セクション形式で伝送される。

また、図１６に示すように、MITのテーブルを伝送するTSパケットのパケット識別子（PID）は、PMT(Program Map Table)による間接指定とされる。PMTは、あるプログラムに含まれる画像や音声等の各PIDを格納したテーブルである。

図１５において、Multicast_information_section()は、8ビットのtable_id，1ビットのsection_syntax_indicator，1ビットのreserved_future_use，2ビットのreserved，12ビットのsection_length，12ビットのdescriptors_loop_length，ディスクリプタループ内のdescriptor()，32ビットのCRC_32のフィールドから構成される。

table_idは、テーブルを識別するためのテーブルIDの8ビットのフィールドである。例えば、図１７に示すように、MITのテーブルIDとして、"0x76"が設定される。

ディスクリプタループ内のdescriptor()には、マルチキャストセッション記述子が配置される。

図１８は、マルチキャストセッション記述子の構造の例を示す図である。

図１８において、Multicast_session_descriptor()は、8ビットのdescriptor_tag，8ビットのdescriptor_length，8ビットのtext_charのフィールドから構成される。

descriptor_tagは、記述子を識別するためのタグ値の8ビットのフィールドである。例えば、図１９に示すように、マルチキャストセッション記述子のタグ値として、"0xE5"が設定される。

text_charは、8ビットのフィールドであって、nmc.sdpファイル又はそれに等価な内容が含まれる。なお、このnmc.sdpファイルには、例えば、図６に示した内容が含まれる。

放送受信デバイス６０では、このようなMITを放送経由で取得したとき、このMITに含まれるnmc.sdpファイル又はそれと等価な内容に基づき、マルチキャスト終端デバイス７０（で稼働するマルチキャスト終端モジュール）に対して、マルチキャストセッションの開始を依頼することになる。

（第２の配信方式の処理）
次に、図２０及び図２１のフローチャートを参照して、第２の配信方式を採用した場合のコンテンツ配信システム１の各装置で実行される処理の流れを説明する。

ステップＳ２０１乃至Ｓ２０２においては、図１１のステップＳ１０１乃至Ｓ１０２と同様に、放送コンテンツマネジメントシステム１０によって、番組等のコンテンツが生成される。

ステップＳ２１１乃至Ｓ２１２においては、図１１のステップＳ１１１乃至Ｓ１１２と同様に、放送向けストリームサーバ２０によって、放送配信ストリームが生成される。

ステップＳ２２１乃至Ｓ２２２においては、図１１のステップＳ１２１乃至Ｓ１２２と同様に、ブロードバンド向けストリームサーバ４０によって、ブロードバンド配信ストリームが生成される。

ステップＳ２０３乃至Ｓ２０４においては、図１１のステップＳ１０３乃至Ｓ１０４と同様に、放送コンテンツマネジメントシステム１０によって、放送アプリケーションが生成される。

ステップＳ２０５において、放送コンテンツマネジメントシステム１０は、MITを生成する。ステップＳ２０６で生成されたMITは、地上波放送サーバ３０に送信される（Ｓ２０６）。

地上波放送サーバ３０においては、放送コンテンツマネジメントシステム１０からの放送アプリケーション及びMITと、放送向けストリームサーバ２０からの放送配信ストリームが受信される。

ステップＳ２３１において、地上波放送サーバ３０は、受信された放送配信ストリームと、放送アプリケーションと、MITを処理（例えば、多重化等の処理）して、放送配信を行う。これにより、放送配信ストリームと放送アプリケーションとMITの多重化ストリームを含む放送波が、地上波放送ネットワーク２を介して伝送される。

ステップＳ２４１において、ブロードバンドサーバ５０は、ブロードバンド向けストリームサーバ４０からのブロードバンド配信ストリームを処理（例えば、パケット化等の処理）して、マルチキャスト配信を行う。これにより、IPマルチキャストストリームが、ブロードバンドネットワーク３を介して伝送される。

図２１のステップＳ２８１において、放送受信デバイス６０の放送ミドルウェア１０５は、地上波放送ネットワーク２を介して受信された多重化ストリームを処理することで、MITを取得する。このMITは、図１５に示した構造を有し、ディスクリプタループ内に配置されるマルチキャストセッション記述子（図１８）には、nmc.sdpファイル又はそれに等価な内容が含まれる。

ステップＳ２８２において、放送ミドルウェア１０５（又はネット配信予約準備処理部１３３）は、ステップＳ２８１の処理で得られたMITに基づいて、マルチキャスト終端デバイス７０で稼働しているマルチキャスト終端モジュールに対し、ネット配信予約準備を通知する。

このネット配信予約準備通知では、放送受信デバイス６０において、放送ミドルウェア１０５（又はネット配信予約準備処理部１３３）が、マルチキャスト終端モジュールに対し、ステップＳ２８１の処理で取得したMITから得られるnmc.sdpファイル又はそれに等価な内容を通知することで、マルチキャストの予約指示がなされる。

マルチキャスト終端デバイス７０においては、放送受信デバイス６０からのnmc.sdpファイル又はそれに等価な内容が受信される。なお、ここでは、図８乃至図１０に示したように、http-postやhttp-getのメッセージを利用することができる。

ステップＳ２６１及びＳ２５１においては、図１２のステップＳ１６１及びＳ１５１と同様に、マルチキャスト終端デバイス７０のマルチキャストミドルウェア２３１によって、nmc.sdpファイル又はそれに等価な内容を用いて、マルチキャストに参加することになる。そして、マルチキャスト終端デバイス７０では、マルチキャスト中継ルータ８０からマルチキャスト転送されるIPマルチキャストストリームの受信が開始される。

すなわち、第２の配信方式では、上述した第１の配信方式と同様に、マルチキャスト終端デバイス７０が、マルチキャスト（マルチキャストグループ）に参加したとき、マルチキャストツリーが生成されるようにしている。

そのため、放送受信デバイス６０からブロードバンドコンテンツが要求されるよりも前に、マルチキャストツリーが生成され、IPマルチキャストストリームが、マルチキャスト中継ルータ８０からマルチキャスト終端デバイス７０にまで転送されているため、放送受信デバイス６０からブロードバンドコンテンツが要求されたときには、直ちに、IPマルチキャストストリームを転送することが可能となる。

また、マルチキャスト終端デバイス７０がマルチキャストに参加するまでは、マルチキャスト中継ルータ８０又はブロードバンドサーバ５０によって、IPマルチキャストストリームがせき止めてられるが、マルチキャスト終端デバイス７０がマルチキャストに参加して、マルチキャストツリーが生成されることで、対象のIPマルチキャストストリーム（を構成するマルチキャストパケット）の経路が確定される。

そして、このようにして確定されるIPマルチキャストストリーム（を構成するマルチキャストパケット）の経路は、MITを受信した放送受信デバイス６０からのネット配信予約準備通知に応じたマルチキャストツリーによるものであって、いわば優先度が高いために取捨選択された経路であるため、ブロードバンドネットワーク３への負荷を抑えることができる。

一方で、放送受信デバイス６０においては、放送ミドルウェア１０５やDASHクライアント１０６等が、地上波放送ネットワーク２を介して受信されたストリームを処理することで、地上波コンテンツを再生する（Ｓ２８３）。そして、放送受信デバイス６０では、レンダラ１０７によって、レンダリング処理が行われることで、マルチキャスト併用番組配信可能な放送番組としての地上波コンテンツの映像と音声が出力される。

また、放送受信デバイス６０においては、ブラウザ１０９が、AITに基づいて、放送ミドルウェア１０５により処理された多重化ストリームから得られる放送アプリケーションを取得して起動する（Ｓ２８４）。そして、この放送アプリケーションが、ブロードバンドコンテンツを視聴するかどうかを選択させるための表示を行い、エンドユーザが、所望のブロードバンドコンテンツの視聴を選択した場合に、当該ブロードバンドコンテンツの要求がなされる（Ｓ２８５）。

ステップＳ２８５，Ｓ２６２，Ｓ２８６においては、図１２のステップＳ１８４，Ｓ１６２，Ｓ１８５と同様に、マルチキャスト終端デバイス７０が、放送受信デバイス６０からの要求に応じて、IPマルチキャストストリームを転送することで、放送受信デバイス６０では、マルチキャスト併用配信番組としてのブロードバンドコンテンツが再生される。

なお、図２１のフローチャートでは、記載を省略しているが、図１２のステップＳ１８６，Ｓ１６３，Ｓ１５２，Ｓ１３２，Ｓ１８７と同様の処理が行われるようにすることで、マルチキャストの離脱が行われ、放送受信デバイス６０での再生対象のコンテンツが、ブロードバンドコンテンツから地上波コンテンツに切り替えられるようにしてもよい。

以上、第２の配信方式を採用した場合の処理の流れを説明した。

（３）第３の配信方式

第３の配信方式は、その時点で放送配信されている全チャンネルのMITを取得して、マルチキャスト終端デバイス７０（で稼働するマルチキャスト終端モジュール）に対し、事前にマルチキャスト予約をかける方式である。

ただし、この方式では、全チャンネルを選局する必要があるため、放送受信デバイス６０においては、例えば、チューナ１０４として、マルチチューナが実装されている必要がある。

（第３の配信方式の処理）
次に、図２２のフローチャートを参照して、第３の配信方式を採用した場合のコンテンツ配信システム１の各装置で実行される処理の流れを説明する。

なお、第３の配信方式の前段の処理は、上述した第２の配信方式の前段の処理と同様であるため、その説明は省略する。すなわち、第３の配信方式の前段の処理は、上述した図２０のフローチャートに示した処理と同様であり、図２２に示した第３の配信方式の後段の処理は、図２０のフローチャートに示した処理に続いて実行される処理とされる。

ステップＳ３８１において、放送受信デバイス６０のチューナ１０４（マルチチューナ）は、全チャンネルを選局（チューン）し、地上波放送ネットワーク２を介して受信された多重化ストリームで同時並行転送されている全てのMITが、放送ミドルウェア１０５により取得されるようにする。

ステップＳ３８２において、放送ミドルウェア１０５（又はネット配信予約準備処理部１３３）は、ステップＳ３８１の処理で得られた全てのMITに基づいて、マルチキャスト終端デバイス７０で稼働しているマルチキャスト終端モジュールに対し、全ネット配信予約準備を通知する。

この全ネット配信予約準備通知では、放送受信デバイス６０において、放送ミドルウェア１０５（又はネット配信予約準備処理部１３３）が、マルチキャスト終端モジュールに対し、ステップＳ３８１の処理で取得した全てのMITから得られる、全チャンネル分のnmc.sdpファイル又はそれに等価な内容を通知することで、マルチキャストの予約指示がなされる。

ステップＳ３６１及びＳ３５１においては、図２１のステップＳ２６１及びＳ２５１と同様に、マルチキャスト終端デバイス７０のマルチキャストミドルウェア２３１によって、全チャンネル分のnmc.sdpファイル又はそれに等価な内容を用いて、マルチキャストに参加することになる。そして、マルチキャスト終端デバイス７０では、マルチキャスト中継ルータ８０からマルチキャスト転送される、全チャンネル分のIPマルチキャストストリームの受信が開始される。

すなわち、第３の配信方式では、上述した第２の配信方式等と同様に、マルチキャスト終端デバイス７０が、マルチキャスト（マルチキャストグループ）に参加したとき、マルチキャストツリーが生成されるようにしている。

そのため、放送受信デバイス６０からブロードバンドコンテンツが要求されるよりも前に、マルチキャストツリーが生成され、全チャンネル分のIPマルチキャストストリームが、マルチキャスト中継ルータ８０からマルチキャスト終端デバイス７０にまで転送されているため、放送受信デバイス６０から所望のチャンネルのブロードバンドコンテンツが要求されたときには、直ちに、全チャンネルの中から、所望のチャンネルのIPマルチキャストストリームを転送することが可能となる。

また、マルチキャスト終端デバイス７０がマルチキャストに参加するまでは、マルチキャスト中継ルータ８０又はブロードバンドサーバ５０によって、全チャンネル分のIPマルチキャストストリームがせき止めてられるが、マルチキャスト終端デバイス７０がマルチキャストに参加して、マルチキャストツリーが生成されることで、対象の全チャンネル分のIPマルチキャストストリーム（を構成するマルチキャストパケット）の経路が確定される。

そして、このようにして確定される全チャンネル分のIPマルチキャストストリーム（を構成するマルチキャストパケット）の経路は、MITを受信した放送受信デバイス６０からの全ネット配信予約準備通知に応じたマルチキャストツリーによるものであって、いわば優先度が高いために取捨選択された経路であるため、ブロードバンドネットワーク３への負荷を抑えることができる。

一方で、放送受信デバイス６０においては、地上波コンテンツの再生が行われ（Ｓ３８３）、さらに、放送アプリケーションが起動される（Ｓ３８４）。そして、この放送アプリケーションが、ブロードバンドコンテンツを視聴するかどうかを選択させるための表示を行い、エンドユーザが、所望のチャンネルのブロードバンドコンテンツの視聴を選択した場合に、当該ブロードバンドコンテンツの要求がなされる（Ｓ３８５）。

ステップＳ３８５，Ｓ３６２，Ｓ３８６においては、図２１のステップＳ２８５，Ｓ２６２，Ｓ２８６と同様に、マルチキャスト終端デバイス７０が、放送受信デバイス６０からの要求に応じて、IPマルチキャストストリームを転送することになるが、マルチキャスト中継ルータ８０から、全チャンネル分のブロードバンドコンテンツが転送されているため、次の点が異なっている。

すなわち、マルチキャスト終端デバイス７０では、マルチキャスト中継ルータ８０からマルチキャスト転送される全チャンネル分のブロードバンドコンテンツの中から、エンドユーザにより選択された所望のチャンネルのブロードバンドコンテンツを選択して、放送受信デバイス６０に転送する。これにより、放送受信デバイス６０では、所望のチャンネルのブロードバンドコンテンツが再生される。

なお、図２２のフローチャートでは、記載を省略しているが、図１２のステップＳ１８６，Ｓ１６３，Ｓ１５２，Ｓ１３２，Ｓ１８７と同様の処理が行われるようにすることで、マルチキャストの離脱が行われ、放送受信デバイス６０での再生対象のコンテンツが、ブロードバンドコンテンツから地上波コンテンツに切り替えられるようにしてもよい。

以上、第３の配信方式を採用した場合の処理の流れを説明した。

（４）第４の配信方式

第４の配信方式は、ブロードバンド配信シグナリングがマルチキャスト配信される場合に、放送アプリケーションが、サービス識別子を通知してマルチキャスト参加を促す方式である。

（第４の配信方式の処理）
次に、図２３及び図２４のフローチャートを参照して、第４の配信方式を採用した場合のコンテンツ配信システム１の各装置で実行される処理の流れを説明する。

ステップＳ４０１乃至Ｓ４０２においては、図２０のステップＳ２０１乃至Ｓ２０２と同様に、放送コンテンツマネジメントシステム１０によって、番組等のコンテンツが生成される。

ステップＳ４０３乃至Ｓ４０４においては、図２０のステップＳ２０３乃至Ｓ２０４と同様に、放送コンテンツマネジメントシステム１０によって、放送アプリケーションが生成される。

ステップＳ４０５乃至Ｓ４０６においては、図２０のステップＳ２０５乃至Ｓ２０６と同様に、放送コンテンツマネジメントシステム１０によって、MITが生成される。このMITは、ブロードバンド向けストリームサーバ４０に送信される。

ステップＳ４１１乃至Ｓ４１２においては、図２０のステップＳ２１１乃至Ｓ２１２と同様に、放送向けストリームサーバ２０によって、放送配信ストリームが生成される。

ステップＳ４２１において、ブロードバンド向けストリームサーバ４０は、ブロードバンド配信シグナリングを生成する。ここでは、例えば、ブロードバンド配信シグナリングとして、放送コンテンツマネジメントシステム１０から受信したMITに基づき、SLT(Service List Table)やSLS(Service Layer Signaling)等のシグナリングが生成される。

なお、MITは、図１５に示した構造を有し、ディスクリプタループ内に配置されるマルチキャストセッション記述子（図１８）には、nmc.sdpファイル又はそれに等価な内容が含まれる。つまり、SLTやSLS等のシグナリングに対し、nmc.sdpファイル又はそれに等価な内容が含められる。

また、SLTやSLSは、次世代地上放送規格の１つであるATSC(Advanced Television Systems Committee)3.0で規定されているシグナリングである。なお、SLTやSLSの詳細な内容は、下記の非特許文献１に記載されている。SLTやSLSは、XML形式のファイルとして提供される。

非特許文献１：ATSC Candidate Standard：Signaling, Delivery, Synchronization, and Error Protection(A/331)

ステップＳ４２３乃至Ｓ４２４においては、図２０のステップＳ２２１乃至Ｓ２２２と同様に、ブロードバンド向けストリームサーバ４０によって、ブロードバンド配信ストリームが生成される。

ステップＳ４３１においては、図２０のステップＳ２３１と同様に、地上波放送サーバ３０によって、放送配信が行われる。地上波放送サーバ３０からの放送波は、地上波放送ネットワーク２を介して、放送受信デバイス６０により受信される。

ステップＳ４４１においては、図２０のステップＳ２４１と同様に、ブロードバンドサーバ５０によって、マルチキャスト配信が行われる。ブロードバンドサーバ５０からのIPマルチキャストストリームは、ブロードバンドネットワーク３内のマルチキャスト中継ルータ８０により受信される。

ただし、このIPマルチキャストストリームには、ブロードバンド配信ストリームとともに、ブロードバンド配信シグナリングが含まれる。

図２４のステップＳ４６１において、マルチキャスト終端デバイス７０のマルチキャストミドルウェア２３１は、マルチキャスト中継ルータ８０に対し、所定の手続を行うことで、ブロードバンド配信シグナリングマルチキャストに参加する。

ここで、ブロードバンド配信シグナリングマルチキャストとは、ブロードバンド配信シグナリング（例えばSLTやSLSのファイル）を転送するマルチキャストであって、このマルチキャストに参加することで、マルチキャスト配信されるシグナリング（例えばSLTやSLSのファイル）を取得することができる。

マルチキャスト中継ルータ８０においては、マルチキャスト終端デバイス７０がブロードバンド配信シグナリングマルチキャストに参加する場合、ステップＳ４５１の処理が実行される。すなわち、ステップＳ４５１において、マルチキャスト中継ルータ８０は、ブロードバンドサーバ５０からマルチキャスト配信されたシグナリングを、マルチキャスト終端デバイス７０に転送する。

このようにして、マルチキャスト中継ルータ８０ではシグナリングマルチキャスト転送が開始され、ブロードバンド配信シグナリングが、マルチキャスト終端デバイス７０により受信される。

ステップＳ４６２において、マルチキャスト終端デバイス７０のシグナリング処理部２３３は、受信されたシグナリングを解析する。この解析結果によって、SLTやSLS等のシグナリングから、nmc.sdpファイル又はそれに等価な内容が得られる。

一方で、放送受信デバイス６０においては、地上波コンテンツの再生が行われ（Ｓ４８１）、さらに、放送アプリケーションが起動される（Ｓ４８２）。そして、起動された放送アプリケーションが、マルチキャスト終端デバイス７０で稼働するマルチキャスト終端モジュールに対し、ネット配信予約準備を通知する（Ｓ４８３）。

このネット配信予約準備通知では、放送アプリケーションが、マルチキャスト予約通知関数（図１３の第２の引数）を利用して、再生中の地上波コンテンツを提供するサービス（チャンネル）を識別するサービス識別子を指定してマルチキャストへの参加指示がなされる。このサービス識別子は、マルチキャスト終端デバイス７０により受信される。

ステップＳ４６３及びＳ４５２においては、マルチキャスト終端デバイス７０のマルチキャストミドルウェア２３１によって、サービス識別子及びnmc.sdpファイル又はそれに等価な内容が処理され、マルチキャストに参加することになる。

より具体的には、SLTやSLS等のシグナリングの解析結果から、サービス識別子に関連付けられたnmc.sdpファイル又はそれに等価な内容が取得されることで、サービス識別子により識別されるブロードバンドコンテンツのマルチキャストに参加するために必要なパラメタが取得される。例えば、サービス識別子は、SLTのグローバスサービスID（globalServiceID）等に紐付けられる。

これにより、マルチキャスト終端デバイス７０では、マルチキャスト中継ルータ８０からマルチキャスト転送されるIPマルチキャストストリームの受信が開始される。

すなわち、第４の配信方式では、上述した第１の配信方式等と同様に、マルチキャスト終端デバイス７０が、マルチキャスト（マルチキャストグループ）に参加したとき、マルチキャストツリーが生成されるようにしている。

また、マルチキャスト終端デバイス７０がマルチキャストに参加するまでは、マルチキャスト中継ルータ８０又はブロードバンドサーバ５０によって、IPマルチキャストストリームがせき止めてられるが、マルチキャスト終端デバイス７０がマルチキャストに参加して、マルチキャストツリーが生成されることで、対象のサービス（チャンネル）のIPマルチキャストストリーム（を構成するマルチキャストパケット）の経路が確定される。

そして、このようにして確定されるIPマルチキャストストリーム（を構成するマルチキャストパケット）の経路は、サービス識別子を用いたシグナリングの解析結果に応じたマルチキャストツリーによるものであって、いわば優先度が高いために取捨選択された経路であるため、ブロードバンドネットワーク３への負荷を抑えることができる。

一方で、放送受信デバイス６０においては、放送アプリケーションが、ブロードバンドコンテンツを視聴するかどうかを選択させるための表示を行い、エンドユーザが、再生中の地上波コンテンツのサービス識別子により識別されるブロードバンドコンテンツの視聴を選択した場合に、当該ブロードバンドコンテンツの要求がなされる（Ｓ４８４）。

ステップＳ４８４，Ｓ４６４，Ｓ４８５においては、図１２のステップＳ１８４，Ｓ１６２，Ｓ１８５と同様に、マルチキャスト終端デバイス７０が、放送受信デバイス６０からの要求に応じて、IPマルチキャストストリームを転送することで、放送受信デバイス６０では、ブロードバンドコンテンツが再生される。

なお、図２４のフローチャートでは、記載を省略しているが、図１２のステップＳ１８６，Ｓ１６３，Ｓ１５２，Ｓ１３２，Ｓ１８７と同様の処理が行われるようにすることで、マルチキャストの離脱が行われ、放送受信デバイス６０での再生対象のコンテンツが、ブロードバンドコンテンツから地上波コンテンツに切り替えられるようにしてもよい。ただし、ここでは、マルチキャスト解除通知関数を利用する際に、第２の引数（図１４の第２の引数）によって、サービス識別子が渡される。

以上、第４の配信方式を採用した場合の処理の流れを説明した。

（５）第５の配信方式

第５の配信方式は、ブロードバンド配信シグナリングがユニキャスト配信される場合に、放送アプリケーションが、サービス識別子を通知してマルチキャスト参加を促す方式である。

この第５の配信方式は、上述した第４の配信方式のバリエーションで、ブロードバンドマルチキャストサービスにおいて、その時点で放送されているサービスについてのシグナリングを一度に取得できる環境で利用可能なシナリオとなる。

（第５の配信方式の処理）
次に、図２５及び図２６のフローチャートを参照して、第５の配信方式を採用した場合のコンテンツ配信システム１の各装置で実行される処理の流れを説明する。

なお、図２５及び図２６においては、ブロードバンドサーバ５０として、マルチキャスト配信を行うブロードバンドサーバ５０Ａの処理と、ユニキャスト配信を行うブロードバンドサーバ５０Ｂの処理をそれぞれ示している。

また、図２５及び図２６においては、説明の都合上、放送向けストリームサーバ２０の処理と、地上波放送サーバ３０の処理を省略しているが、地上波放送ネットワーク２を介して、地上波コンテンツや放送アプリケーションの配信も可能である。

ステップＳ５０１乃至Ｓ５０２においては、図２３のステップＳ４０１乃至Ｓ４０２と同様に、放送コンテンツマネジメントシステム１０によって、番組等のコンテンツが生成される。

ステップＳ５０３乃至Ｓ５０４においては、図２３のステップＳ４０５乃至Ｓ４０６と同様に、放送コンテンツマネジメントシステム１０によって、MITが生成される。

ステップＳ５２１乃至Ｓ５２２においては、図２３のステップＳ４２１乃至Ｓ４２２と同様に、ブロードバンド配信シグナリングが生成される。このブロードバンド配信シグナリングは、SLTやSLS等の、nmc.sdpファイル又はそれに等価な内容が含められたシグナリングであって、ブロードバンドサーバ５０Ｂに送信される。

ステップＳ５２３乃至Ｓ５２４においては、図２３のステップＳ４２３乃至Ｓ４２４と同様に、ブロードバンド配信ストリームが生成される。このブロードバンド配信ストリームは、ブロードバンドサーバ５０Ａに送信される。

ステップＳ５４６においては、図２３のステップＳ４４１と同様に、ブロードバンドサーバ５０Ａによって、ブロードバンド配信ストリームのマルチキャスト配信が行われる。ブロードバンドサーバ５０ＡからのIPマルチキャストストリームは、ブロードバンドネットワーク３内のマルチキャスト中継ルータ８０により受信される。

ステップＳ５６１において、マルチキャスト終端デバイス７０のシグナリング処理部２３３は、ブロードバンドネットワーク３を介して、ブロードバンドサーバ５０Ｂに対し、ブロードバンド配信シグナリングを要求する。

ステップＳ５４１において、ブロードバンドサーバ５０Ｂは、マルチキャスト終端デバイス７０からの要求に応じて、ブロードバンドネットワーク３を介して、ブロードバンド配信シグナリングを返信する。

マルチキャスト終端デバイス７０においては、通信I/F２０３によって、ブロードバンドサーバ５０Ｂからのブロードバンド配信シグナリングが受信される。

図２６のステップＳ５６２において、マルチキャスト終端デバイス７０のシグナリング処理部２３３は、受信されたブロードバンド配信シグナリングを解析する。この解析結果によって、SLTやSLS等のシグナリングから、nmc.sdpファイル又はそれに等価な内容が得られる。

一方で、放送受信デバイス６０においては、地上波コンテンツの再生が行われ（Ｓ５８１）、さらに、放送アプリケーションが起動される（Ｓ５８２）。そして、起動された放送アプリケーションが、マルチキャスト終端デバイス７０で稼働するマルチキャスト終端モジュールに対し、ネット配信予約準備を通知する（Ｓ５８３）。

このネット配信予約準備通知では、放送アプリケーションが、マルチキャスト予約通知関数（図１３の第２の引数）を利用して、再生中の地上波コンテンツを提供するサービス（チャンネル）を識別するサービス識別子を指定してマルチキャストへの参加指示がなされる。

ステップＳ５６３及びＳ５５１においては、図２４のステップＳ４６３及びＳ４５２と同様に、マルチキャスト終端デバイス７０のマルチキャストミドルウェア２３１によって、サービス識別子及びnmc.sdpファイル又はそれに等価な内容が処理され、マルチキャストに参加することになる。

より具体的には、SLTやSLS等のシグナリングの解析結果から、サービス識別子に関連付けられたnmc.sdpファイル又はそれに等価な内容が取得されることで、サービス識別子により識別されるブロードバンドコンテンツのマルチキャストに参加するために必要なパラメタが取得される。

すなわち、第５の配信方式では、上述した第４の配信方式等と同様に、マルチキャスト終端デバイス７０が、マルチキャスト（マルチキャストグループ）に参加したとき、マルチキャストツリーが生成されるようにしている。

一方で、放送受信デバイス６０においては、放送アプリケーションが、ブロードバンドコンテンツを視聴するかどうかを選択させるための表示を行い、エンドユーザが、再生中の地上波コンテンツのサービス識別子により識別されるブロードバンドコンテンツの視聴を選択した場合に、当該ブロードバンドコンテンツの要求がなされる（Ｓ５８４）。

ステップＳ５８４，Ｓ５６４，Ｓ５８５においては、図２４のステップＳ４８４，Ｓ４６４，Ｓ４８５と同様に、マルチキャスト終端デバイス７０が、放送受信デバイス６０からの要求に応じて、IPマルチキャストストリームを転送することで、放送受信デバイス６０では、ブロードバンドコンテンツが再生される。

なお、図２６のフローチャートでは、記載を省略しているが、図１２のステップＳ１８６，Ｓ１６３，Ｓ１５２，Ｓ１３２，Ｓ１８７と同様の処理が行われるようにすることで、マルチキャストの離脱が行われ、放送受信デバイス６０での再生対象のコンテンツが、ブロードバンドコンテンツから地上波コンテンツに切り替えられるようにしてもよい。ただし、ここでは、マルチキャスト解除通知関数を利用する際に、第２の引数（図１４の第２の引数）によって、サービス識別子が渡される。

以上、第５の配信方式を採用した場合の処理の流れを説明した。

（６）第６の配信方式

第６の配信方式は、ブロードバンド配信シグナリングがユニキャスト配信される場合に、放送シグナリングが、マルチキャスト参加を促す方式である。

この第６の配信方式は、上述した第５の配信方式のバリエーションで、放送アプリケーションの代わりに、MITを取得して、事前にマルチキャスト予約をかけるシナリオとなる。

（第６の配信方式の処理）
次に、図２７のフローチャートを参照して、第６の配信方式を採用した場合のコンテンツ配信システム１の各装置で実行される処理の流れを説明する。

なお、第６の配信方式の前段の処理は、上述した第５の配信方式の前段の処理と同様であるため、その説明は省略する。すなわち、第６の配信方式の前段の処理は、上述した図２５のフローチャートに示した処理と同様であり、図２７に示した第６の配信方式の後段の処理は、図２５のフローチャートに示した処理に続いて実行される処理とされる。

なお、図２７においては、ブロードバンドサーバ５０として、マルチキャスト配信を行うブロードバンドサーバ５０Ａの処理と、ユニキャスト配信を行うブロードバンドサーバ５０Ｂの処理をそれぞれ示している。また、図２７においては、説明の都合上、放送向けストリームサーバ２０の処理と、地上波放送サーバ３０の処理を省略しているが、地上波放送ネットワーク２を介して、地上波コンテンツや放送アプリケーションの配信も可能である。

ステップＳ６８１において、放送受信デバイス６０の放送ミドルウェア１０５は、地上波放送ネットワーク２を介して受信されたストリームを処理することで、MITを取得する。

ステップＳ６８２において、放送ミドルウェア１０５（又はネット配信予約準備処理部１３３）は、ステップＳ６８１の処理でMITが取得されたとき、マルチキャスト終端デバイス７０で稼働しているマルチキャスト終端モジュールに対し、ネット配信予約準備を通知する。

ステップＳ６６１において、マルチキャスト終端デバイス７０のシグナリング処理部２３３は、ブロードバンドネットワーク３を介して、ブロードバンドサーバ５０Ｂに対し、ブロードバンド配信シグナリングを要求する。

ステップＳ６６２において、マルチキャスト終端デバイス７０のシグナリング処理部２３３は、ブロードバンドサーバ５０Ｂから受信したブロードバンド配信シグナリングを解析する。この解析結果によって、SLTやSLS等のシグナリングから、nmc.sdpファイル又はそれに等価な内容が得られる。

ステップＳ６６３，Ｓ６５１においては、マルチキャスト終端デバイス７０によって、nmc.sdpファイル又はそれに等価な内容が処理され、マルチキャストに参加することになる。

すなわち、第６の配信方式では、上述した第５の配信方式等と同様に、マルチキャスト終端デバイス７０が、マルチキャスト（マルチキャストグループ）に参加したとき、マルチキャストツリーが生成されるようにしている。

そして、このようにして確定されるIPマルチキャストストリーム（を構成するマルチキャストパケット）の経路は、シグナリングの解析結果に応じたマルチキャストツリーによるものであって、いわば優先度が高いために取捨選択された経路であるため、ブロードバンドネットワーク３への負荷を抑えることができる。

一方で、放送受信デバイス６０においては、地上波コンテンツの再生が行われ（Ｓ６８３）、さらに、放送アプリケーションが起動される（Ｓ６８４）。そして、この放送アプリケーションが、ブロードバンドコンテンツを視聴するかどうかを選択させるための表示を行い、エンドユーザが、所望のブロードバンドコンテンツの視聴を選択した場合に、当該ブロードバンドコンテンツの要求がなされる（Ｓ６８５）。

ステップＳ６８５，Ｓ６６４，Ｓ６８６においては、図２６のステップＳ５８４，Ｓ５６４，Ｓ５８５と同様に、マルチキャスト終端デバイス７０が、放送受信デバイス６０からの要求に応じて、IPマルチキャストストリームを転送することで、放送受信デバイス６０では、ブロードバンドコンテンツが再生される。

なお、図２７のフローチャートでは、記載を省略しているが、図１２のステップＳ１８６，Ｓ１６３，Ｓ１５２，Ｓ１３２，Ｓ１８７と同様の処理が行われるようにすることで、マルチキャストの離脱が行われ、放送受信デバイス６０での再生対象のコンテンツが、ブロードバンドコンテンツから地上波コンテンツに切り替えられるようにしてもよい。

また、上述した第６の配信方式の説明では、SLTやSLS等のシグナリングから得られる、nmc.sdpファイル又はそれに等価な内容を利用する場合を説明したが、放送受信デバイス６０が、MITから得られるnmc.sdpファイル又はそれに等価な内容を、マルチキャスト終端デバイス７０に通知して、マルチキャストの参加がなされるようにしてもよい。

以上、第６の配信方式を採用した場合の処理の流れを説明した。

（７）第７の配信方式

第７の配信方式は、ブロードバンドコンテンツの配信形式を、ユニキャスト配信からマルチキャスト配信に切り替える方式である。第７の配信方式では、例えば、次のようなシナリオが想定される。

ここでは、放送受信デバイス６０において、放送アプリケーションによって、通常の通信経由のHTTP(Hypertext Transfer Protocol)のユニキャストで配信されるブロードバンドコンテンツが再生されている場面を想定する。

ただし、このブロードバンドコンテンツは、地上波コンテンツよりも高解像度かつ高音質であって、DASHストリーミングとして配信されているものとする。また、放送受信デバイス６０は、マルチキャスト終端デバイス７０により転送されてくるブロードバンドコンテンツを再生するが、この場合のマルチキャスト終端デバイス７０は、単にプロキシとして機能しているだけで、上述したマルチキャストセッション等に関する機能は実行していない。

ここで、例えば、同一の番組（ブロードバンドコンテンツ）を同時に、ブロードバンドネットワーク３を経由して視聴するクライアント装置（例えば、テレビ受像機等の放送受信デバイス６０）が増加して、ブロードバンドネットワーク３が、輻輳し始める場面を想定する。

この輻輳は、ユニキャスト配信を行っているブロードバンドサーバ５０により検知され、ブロードバンドコンテンツのマルチキャスト配信での併用配信が指示される。ただし、この輻輳の検知は、ブロードバンドサーバ５０に限らず、例えば、ユニキャストトラフィックをモニタリングしている、専用のネットワークトラフィックモニタリングモジュールが行ってもよい。

ブロードバンドサーバ５０からの併用配信の指示を受けた放送コンテンツマネジメントシステム１０は、新たに放送アプリケーションを生成するか、又は放送アプリケーションに通知するイベントメッセージを生成して、更新された放送アプリケーション又はイベントメッセージが、放送受信デバイス６０により受信されるようにする。

更新された放送アプリケーション又はイベントメッセージを受け取った放送受信デバイス６０では、放送アプリケーションを起動しなおすか、又はイベントメッセージが、起動中の放送アプリケーションに通知されるようにする。

そして、放送受信デバイス６０においては、放送アプリケーションが、マルチキャスト終端デバイス７０で稼働するマルチキャスト終端モジュールに対し、マルチキャストセッションの開始を依頼することになる。

これ以降の処理は、上述した第１の配信方式などと同様であって、マルチキャスト終端デバイス７０は、ブロードバンドコンテンツの取得先を、ユニキャスト配信を行うブロードバンドサーバ５０Ｂから、マルチキャスト配信を行うブロードバンドサーバ５０Ａに切り替える。つまり、マルチキャスト終端デバイス７０は、プロキシとして機能するのではなく、上述したマルチキャストセッション等に関する機能を実行することになる。

なお、ここでのマルチキャスト系の制御フローは、上述した第１の配信方式のような、直接SDPを利用する場合と、上述した第４の配信方式のような、ATSC3.0のシグナリング系を利用する場合の両方のパターンに適用可能とされる。

（第７の配信方式の処理）
次に、図２８乃至図３０のフローチャートを参照して、第７の配信方式を採用した場合のコンテンツ配信システム１の各装置で実行される処理の流れを説明する。

なお、図２８乃至図３０においては、ブロードバンドサーバ５０として、マルチキャスト配信を行うブロードバンドサーバ５０Ａの処理と、ユニキャスト配信を行うブロードバンドサーバ５０Ｂの処理をそれぞれ示している。

ステップＳ７０１乃至Ｓ７０２においては、図１１のステップＳ１０１乃至Ｓ１０２と同様に、放送コンテンツマネジメントシステム１０によって、番組等のコンテンツが生成される。

ステップＳ７１１乃至Ｓ７１２においては、図１１のステップＳ１１１乃至Ｓ１１２と同様に、放送向けストリームサーバ２０によって、放送配信ストリームが生成される。

ステップＳ７２１乃至Ｓ７２２においては、図１１のステップＳ１２１乃至Ｓ１２２と同様に、ブロードバンド向けストリームサーバ４０によって、ユニキャスト配信用のブロードバンド配信ストリームが生成される。

ステップＳ７０３乃至Ｓ７０４においては、図１１のステップＳ１０３乃至Ｓ１０４と同様に、放送コンテンツマネジメントシステム１０によって、放送アプリケーションが生成される。

ステップＳ７３１においては、図１１のステップＳ１３１と同様に、地上波放送サーバ３０によって、放送配信が行われる。地上波放送サーバ３０からの放送波は、地上波放送ネットワーク２を介して、放送受信デバイス６０により受信される。

そして、図２９に示すように、放送受信デバイス６０においては、地上波コンテンツの再生が行われ（Ｓ７８１）、さらに、放送アプリケーションが起動される（Ｓ７８２）。

ステップＳ７８３において、処理部１０１の通信制御部１３２は、通信I/F１１０を制御して、マルチキャスト終端デバイス７０に対し、ユニキャスト配信のブロードバンドコンテンツを要求する。

この要求を受けたマルチキャスト終端デバイス７０では、処理部２０１が、ブロードバンドネットワーク３を介してブロードバンドサーバ５０Ｂに対し、ユニキャスト配信のブロードバンドコンテンツを要求する（Ｓ７６１）。

そして、ブロードバンドサーバ５０Ｂは、マルチキャスト終端デバイス７０からの要求に応じて、ブロードバンドネットワーク３を介してブロードバンドコンテンツを、ユニキャスト配信する（Ｓ７４１）。このIPユニキャストストリームは、ブロードバンドネットワーク３を介して、マルチキャスト終端デバイス７０により受信され、放送受信デバイス６０に転送される（Ｓ７６２）。

これにより、放送受信デバイス６０においては、ユニキャスト配信されたブロードバンドコンテンツの再生が行われる（Ｓ７８４）。

すなわち、このブロードバンドコンテンツは、地上波コンテンツよりも高解像度かつ高音質であって、放送受信デバイス６０での再生対象のコンテンツが、例えば、2K解像度の地上波コンテンツから、4K解像度のブロードバンドコンテンツに切り替えられる。

ここで、ブロードバンドサーバ５０Ｂでは、ブロードバンドネットワーク３でのユニキャストトラフィックがモニタされ、ユニキャストトラフィックにおける過負荷検知が行われる（Ｓ７４２）。ステップＳ７４２の過負荷検知処理で、ブロードバンドネットワーク３の輻輳が検知された場合、ステップＳ７４３の処理が行われる。

すなわち、ブロードバンドサーバ５０Ｂは、放送コンテンツマネジメントシステム１０と、ブロードバンド向けストリームサーバ４０に対し、ブロードバンドコンテンツのマルチキャスト配信での併用配信を通知（指示）する（Ｓ７４３）。

ステップＳ７０５において、放送コンテンツマネジメントシステム１０は、ブロードバンドサーバ５０Ｂからの併用配信の指示に応じて、新たに放送アプリケーションを生成して放送アプリケーションを更新するか、又は放送アプリケーションに通知するイベントメッセージ（以下、アプリイベントともいう）を生成する。

ステップＳ７０５の処理で得られる更新後の放送アプリケーション又はアプリイベントは、地上波放送サーバ３０に送信される。

ステップＳ７３２においては、図１１のステップＳ１３１と同様に、地上波放送サーバ３０によって、放送配信が行われる。ここで、地上波放送サーバ３０からの放送波には、更新後の放送アプリケーション又はアプリイベントが含まれ、地上波放送ネットワーク２を介して、放送受信デバイス６０により受信される。

ステップＳ７２３乃至Ｓ７２４においては、図１１のステップＳ１２１乃至Ｓ１２２と同様に、ブロードバンド向けストリームサーバ４０によって、マルチキャスト配信用のブロードバンド配信ストリームが生成される。

ステップＳ７４６においては、図１１のステップＳ１４１と同様に、ブロードバンドサーバ５０Ａによって、ブロードバンド向けストリームサーバ４０からのマルチキャスト配信用のブロードバンド配信ストリームが処理され、マルチキャスト配信が行われる。これにより、IPマルチキャストストリームが、ブロードバンドネットワーク３を介して伝送される。

一方で、放送受信デバイス６０においては、放送ミドルウェア１０５により処理された多重化ストリームから得られるのが、更新後の放送アプリケーションである場合には、図３０のステップＳ７８５の処理が実行され、アプリイベントである場合には、図３０のステップＳ７８６の処理が実行される。

すなわち、ステップＳ７８５においては、多重化ストリームから得られる更新後の放送アプリケーションが取得され、起動される。一方で、ステップＳ７８６においては、多重化ストリームから得られるアプリイベントが、起動中の放送アプリケーションによって検知される。

ステップＳ７８５又はＳ７８６の処理が終了すると、処理は、ステップＳ７８７に進められる。そして、ステップＳ７８７においては、更新後の放送アプリケーション、又はアプリイベントを検知した放送アプリケーションによって、マルチキャスト終端デバイス７０で稼働しているマルチキャスト終端モジュールに対し、ネット配信予約準備が通知される。

このネット配信予約準備では、放送受信デバイス６０において、更新後の放送アプリケーション、又はアプリイベントを検知した放送アプリケーションがが、APIとして提供されるマルチキャスト予約通知関数（図１３の第１の引数）を利用して、マルチキャスト終端モジュールに対し、nmc.sdpファイル又はそれに等価な内容を通知することで、マルチキャストの予約指示がなされる。

マルチキャスト終端デバイス７０においては、放送受信デバイス６０からのnmc.sdpファイル又はそれに等価な内容が受信される。

ステップＳ７６３及びＳ７５１においては、図１２のステップＳ１６１及びＳ１５１と同様に、マルチキャスト終端デバイス７０のマルチキャストミドルウェア２３１によって、nmc.sdpファイル又はそれに等価な内容を用いて、マルチキャストに参加することになる。そして、マルチキャスト終端デバイス７０では、マルチキャスト中継ルータ８０からマルチキャスト転送されるIPマルチキャストストリームの受信が開始される。

すなわち、第７の配信方式では、上述した第１の配信方式等と同様に、マルチキャスト終端デバイス７０が、マルチキャスト（マルチキャストグループ）に参加したとき、マルチキャストツリーが生成されるようにしている。

そして、このようにして確定されるIPマルチキャストストリーム（を構成するマルチキャストパケット）の経路は、放送受信デバイス６０からのネット配信予約準備通知に応じたマルチキャストツリーによるものであって、いわば優先度が高いために取捨選択された経路であるため、ブロードバンドネットワーク３への負荷を抑えることができる。

ステップＳ７８８，Ｓ７６４，Ｓ７８９においては、図１２のステップＳ１８４，Ｓ１６２，Ｓ１８５と同様に、マルチキャスト終端デバイス７０が、放送受信デバイス６０からの要求に応じて、IPマルチキャストストリームを転送することで、放送受信デバイス６０では、マルチキャスト配信されたブロードバンドコンテンツが再生される。

すなわち、ブロードバンドネットワーク３の輻輳が検知されたとき、放送受信デバイス６０では、再生されるブロードバンドコンテンツが、ユニキャスト配信されたブロードバンドコンテンツから、マルチキャスト配信されたブロードバンドコンテンツに切り替えられることになる。

以上、第７の配信方式を採用した場合の処理の流れを説明した。

＜３．本技術のプロトコルスタック構成＞

ところで、本技術が提案する方式では、地上波放送トランスポートプロトコル、ブロードバンドユニキャストプロトコルやブロードバンドマルチキャストプロトコルとして、様々なプロトコルを利用することができる。

そこで、以下、本技術が提案する方式に適用可能なプロトコルスタック構成として、第１のスタック構成乃至第１２のスタック構成について説明する。

（１）第１のスタック構成

図３１は、第１のスタック構成の例を示す図である。

図３１の第１のスタック構成においては、図中の右側に、放送受信デバイス６０のスタック構成を示し、図中の左側に、マルチキャスト終端デバイス７０のスタック構成を示している。

これらのスタック構成においては、その階層構造のうち、最も下位の階層が、物理層やリンク層に対応した第１の階層とされ、さらに第１の階層の１つ上の階層は、ネットワーク層に対応した第２の階層とされる。また、第２の階層の１つ上の階層は、トランスポート層に対応した第３の階層とされ、さらに第３の階層の１つ上の階層は、アプリケーション層に対応した第４の階層とされる。

そして、このような４階層のプロトコルスタックを実装することで、放送受信デバイス６０やマルチキャスト終端デバイス７０では、各種のミドルウェアやアプリケーションを実装することが可能となる。

放送受信デバイス６０は、チューナ１０４（図３）と通信I/F１１０（図３）を有して構成され、放送と通信の両方の方式に対応可能であるため、放送系のスタックと通信系のスタックが併記されている。

放送系のスタックとしては、第１の階層が、放送PHYとされ、第２の階層が、MPEG2-TS(Transport Stream)とされ、第３の階層が、PES(Packetized Elementary Stream)又はSectionとされ、第４の階層が、Audio/Video ES(Elementary Stream)又はPSI/SI(Program Specific Information / Service Information)とされる。

なお、AIT(Application Information Table)やMIT(Multicast Information Table)は、PSI/SIに含まれ、セクション形式で伝送される。

通信系のスタックとしては、第１の階層が、Ethernet/Wifiとされ、第２の階層が、IP(Internet Protocol)とされ、第３の階層が、TCP(Transmission Control Protocol)とされ、第４の階層が、HTTP(Hypertext Transfer Protocol)とされる。

このようなプロトコルスタックが実装されることで、放送受信デバイス６０では、放送ミドルウェア１０５、ネットプレイヤや放送プレイヤとしてのDASHクライアント１０６（DASHプレイヤ）、又は放送アプリケーションを実行するブラウザ１０９などが実装される。

一方で、マルチキャスト終端デバイス７０は、通信I/F２０２（図５）と通信I/F２０３（図５）を有して構成され、２つの通信方式に対応可能であるため、第１の通信系のスタックと、第２の通信系のスタックが併記されている。

第１の通信系のスタックとしては、第１の階層が、Ethernet/Wifiとされ、第２の階層が、IPとされ、第３の階層が、TCPとされ、第４の階層が、HTTPとされる。すなわち、この第１の通信系のスタックは、放送受信デバイス６０の通信系のスタックと同様とされる。

第２の通信系のスタックとしては、第１の階層が、Ethernetとされ、第２の階層が、IPとされ、第３の階層が、UDP(User Datagram Protocol)又はTCPとされ、第４の階層が、FLUTE(File Delivery over Unidirectional Transport)又はHTTPとされる。

このようなプロトコルスタックが実装されることで、マルチキャスト終端デバイス７０では、マルチキャストミドルウェア２３１やウェブサーバ２３２などが実装される。

なお、図３１の第１のスタック構成において、放送受信デバイス６０では、放送系のスタックが実装されることで、例えば地上波網や衛星網等の放送網を介して放送波を受信することができる。

また、放送受信デバイス６０では、通信系のスタックが実装され、マルチキャスト終端デバイス７０では、第１の通信系のスタックが実装されることで、例えば家庭内LAN(Local Area Network)等を介して相互に通信を行うことができる。

さらに、マルチキャスト終端デバイス７０では、第２の通信系のスタックが実装されることで、例えば通信キャリアが提供するNGN(Next Generation Network)等を介して相互に通信を行うことができる。

（２）第２のスタック構成

図３２は、第２のスタック構成の例を示す図である。

図３２の第２のスタック構成においては、上述した第１のスタック構成（図３１）と同様に、放送受信デバイス６０とマルチキャスト終端デバイス７０のスタック構成を示しているが、放送受信デバイス６０の放送系のスタックが異なっている。

第２のスタック構成において、放送受信デバイス６０の放送系のスタックとしては、第１の階層が、TLV(Type Length Value)/放送PHYとされ、第２の階層が、IPとされ、第３の階層が、MMTP/UDP(MPEG Media Transport Protocol / User Datagram Protocol)とされ、第４の階層が、Audio/Video ES又はPSI/SIとされる。

すなわち、第２のスタック構成の放送系のスタックでは、MPEG2-TS方式ではなく、IP伝送方式を用いて、IPパケットをTLVパケットにカプセル化して、物理層フレーム（放送PHY）に含めるようにしているため、すべてのスタックでIPのプロトコルが使われて共通化されている。

なお、第２のスタック構成において、放送受信デバイス６０の通信系のスタックと、マルチキャスト終端デバイス７０の第１の通信系のスタック及び第２の通信系のスタックは、上述した第１のスタック構成（図３１）と同様であるため、その説明は省略する。

（３）第３のスタック構成

図３３は、第３のスタック構成の例を示す図である。

図３３の第３のスタック構成においては、上述した第１のスタック構成（図３１）と同様に、放送受信デバイス６０とマルチキャスト終端デバイス７０のスタック構成を示しているが、放送受信デバイス６０の放送系のスタックが異なっている。

第３のスタック構成において、放送受信デバイス６０の放送系のスタックとしては、第１の階層が、放送PHYとされ、第２の階層が、MPEG2-TSとされ、第３の階層が、Sectionとされ、第４の階層が、IPとされ、第５の階層が、UDPとされ、第６の階層がROUTE(Real-time Object Delivery over Unidirectional Transport)又はFLUTEとされる。また、第４の階層乃至第６の階層が、PSI/SIとされる。

すなわち、第３のスタック構成の放送系のスタックでは、PSI/SIだけでなく、UDPパケットを含むIPパケットについてもセクション形式で伝送される。

なお、第３のスタック構成において、放送受信デバイス６０の通信系のスタックと、マルチキャスト終端デバイス７０の第１の通信系のスタック及び第２の通信系のスタックは、上述した第１のスタック構成（図３１）と同様であるため、その説明は省略する。

（４）第４のスタック構成

図３４は、第４のスタック構成の例を示す図である。

図３４の第４のスタック構成においては、上述した第１のスタック構成（図３１）と同様に、放送受信デバイス６０とマルチキャスト終端デバイス７０のスタック構成を示しているが、マルチキャスト終端デバイス７０の第２の通信系のスタックが異なっている。

第４のスタック構成において、マルチキャスト終端デバイス７０の第２の通信系のスタックとしては、第１の階層が、Ethernetとされ、第２の階層が、IPとされ、第３の階層が、UDP又はTCPとされ、第４の階層が、SLT(Service List Table)、ROUTE、又はHTTPとされる。

すなわち、第４のスタック構成の第２の通信系スタックは、上記の非特許文献１に記載されているATSC3.0のプロトコルスタックに対応しているため、マルチキャストミドルウェア２３１やウェブサーバ２３２等は、ATSC3.0のミドルウェアと等価な機能を有している。なお、ATSC3.0のプロトコルスタックは、非特許文献１の「Figure 5.1 ATSC 3.0 receiver protocol stack.」に、その詳細が記載されている。

なお、第４のスタック構成において、放送受信デバイス６０の放送系のスタック及び通信系のスタックと、マルチキャスト終端デバイス７０の第１の通信系のスタックは、上述した第１のスタック構成（図３１）と同様であるため、その説明は省略する。

（５）第５のスタック構成

図３５は、第５のスタック構成の例を示す図である。

図３５の第５のスタック構成においては、上述した第４のスタック構成（図３４）と同様に、放送受信デバイス６０とマルチキャスト終端デバイス７０のスタック構成を示しているが、放送受信デバイス６０の放送系のスタックが異なっている。

第５のスタック構成において、放送受信デバイス６０の放送系のスタックとしては、第１の階層が、TLV/放送PHYとされ、第２の階層が、IPとされ、第３の階層が、MMTP/UDPとされ、第４の階層が、Audio/Video ES又はPSI/SIとされる。

すなわち、第５のスタック構成の放送系のスタックでは、MPEG2-TS方式ではなく、IP伝送方式を用いて、IPパケットをTLVパケットにカプセル化して、物理層フレーム（放送PHY）に含めるようにしているため、すべてのスタックでIPのプロトコルが使われて共通化されている。

また、第５のスタック構成の第２の通信系のスタックは、第４のスタック構成と同様に、ATSC3.0のプロトコルスタックに対応しているため、マルチキャストミドルウェア２３１等は、ATSC3.0のミドルウェアと等価な機能を有している。

なお、第５のスタック構成において、放送受信デバイス６０の通信系のスタックと、マルチキャスト終端デバイス７０の第１の通信系のスタックは、上述した第４のスタック構成（図３４）と同様であるため、その説明は省略する。

（６）第６のスタック構成

図３６は、第６のスタック構成の例を示す図である。

図３６の第６のスタック構成においては、上述した第４のスタック構成（図３４）と同様に、放送受信デバイス６０とマルチキャスト終端デバイス７０のスタック構成を示しているが、放送受信デバイス６０の放送系のスタックが異なっている。

第６のスタック構成において、放送受信デバイス６０の放送系のスタックとしては、第１の階層が、放送PHYとされ、第２の階層が、MPEG2-TSとされ、第３の階層が、Sectionとされ、第４の階層が、IPとされ、第５の階層が、UDPとされ、第６の階層がROUTE又はFLUTEとされる。また、第４の階層乃至第６の階層が、PSI/SIとされる。

すなわち、第６のスタック構成の放送系のスタックでは、PSI/SIだけでなく、UDPパケットを含むIPパケットについてもセクション形式で伝送される。

また、第６のスタック構成の第２の通信系スタックは、第４のスタック構成と同様に、ATSC3.0のプロトコルスタックに対応しているため、マルチキャストミドルウェア２３１等は、ATSC3.0のミドルウェアと等価な機能を有している。

なお、第６のスタック構成において、放送受信デバイス６０の通信系のスタックと、マルチキャスト終端デバイス７０の第１の通信系のスタックは、上述した第４のスタック構成（図３４）と同様であるため、その説明は省略する。

（７）第７のスタック構成

図３７は、第７のスタック構成の例を示す図である。

図３７の第７のスタック構成においては、放送受信デバイス６０とマルチキャスト終端デバイス７０とが一体化された機器（同梱型デバイス）として構成される場合のスタック構成を示している。したがって、この同梱型デバイスでは、例えば家庭内LAN等を介して相互に通信を行う必要がなく、例えばローカルループバック（Local Loopback）によって自身でデータをやり取りすることができる。

一方で、同梱型デバイスでは、チューナ１０４（図３）と通信I/F２０３（図５）を有して構成され、放送と通信の両方の方式に対応可能であるため、ローカルループバックのスタックを挟んで、放送系のスタックと通信系のスタックが併記されている。

放送系のスタックとしては、放送PHYとされ、第２の階層が、MPEG2-TSとされ、第３の階層が、PES又はSectionとされ、第４の階層が、Audio/Video ES又はPSI/SIとされる。

通信系のスタックとしては、第１の階層が、Ethernetとされ、第２の階層が、IPとされ、第３の階層が、UDP又はTCPとされ、第４の階層が、FLUTE又はHTTPとされる。

これらのプロトコルスタックが実装されることで、同梱型デバイスでは、放送ミドルウェア１０５、ネットプレイヤや放送プレイヤとしてのDASHクライアント１０６（DASHプレイヤ）、若しくは放送アプリケーションを実行するブラウザ１０９、又はマルチキャストミドルウェア２３１若しくはウェブサーバ２３２などが実装される。

なお、図３７の第７のスタック構成において、同梱型デバイスでは、放送系のスタックが実装されることで、例えば地上波網や衛星網等の放送網を介して放送波を受信することができる。また、マルチキャスト終端デバイス７０では、通信系のスタックが実装されることで、例えば通信キャリアが提供するNGN等を介して相互に通信を行うことができる。

（８）第８のスタック構成

図３８は、第８のスタック構成の例を示す図である。

図３８の第８のスタック構成においては、上述した第７のスタック構成（図３７）と同様に、放送受信デバイス６０とマルチキャスト終端デバイス７０とが一体化された同梱型デバイスのスタック構成を示しているが、放送系のスタックが異なっている。

第８のスタック構成において、同梱型デバイスの放送系のスタックとしては、第１の階層が、TLV/放送PHYとされ、第２の階層が、IPとされ、第３の階層が、MMTP/UDPとされ、第４の階層が、Audio/Video ES又はPSI/SIとされる。

すなわち、第８のスタック構成の放送系のスタックでは、MPEG2-TS方式ではなく、IP伝送方式を用いて、IPパケットをTLVパケットにカプセル化して、物理層フレーム（放送PHY）に含めるようにしているため、すべてのスタックでIPのプロトコルが使われて共通化されている。

なお、第８のスタック構成において、通信系のスタックは、上述した第７のスタック構成（図３７）と同様であるため、その説明は省略する。

（９）第９のスタック構成

図３９は、第９のスタック構成の例を示す図である。

図３９の第９のスタック構成においては、上述した第７のスタック構成（図３７）と同様に、放送受信デバイス６０とマルチキャスト終端デバイス７０とが一体化された同梱型デバイスのスタック構成を示しているが、放送系のスタックが異なっている。

第９のスタック構成において、同梱型デバイスの放送系のスタックとしては、第１の階層が、放送PHYとされ、第２の階層が、MPEG2-TSとされ、第３の階層が、Sectionとされ、第４の階層が、IPとされ、第５の階層が、UDPとされ、第６の階層がROUTE又はFLUTEとされる。また、第４の階層乃至第６の階層が、PSI/SIとされる。

すなわち、第９のスタック構成の放送系のスタックでは、PSI/SIだけでなく、UDPパケットを含むIPパケットについてもセクション形式で伝送される。

なお、第９のスタック構成において、通信系のスタックは、上述した第７のスタック構成（図３７）と同様であるため、その説明は省略する。

（１０）第１０のスタック構成

図４０は、第１０のスタック構成の例を示す図である。

図４０の第１０のスタック構成においては、上述した第７のスタック構成（図３７）と同様に、放送受信デバイス６０とマルチキャスト終端デバイス７０とが一体化された同梱型デバイスのスタック構成を示しているが、通信系のスタックが異なっている。

第１０のスタック構成において、同梱型デバイスの通信系のスタックとしては、第１の階層が、Ethernetとされ、第２の階層が、IPとされ、第３の階層が、UDP又はTCPとされ、第４の階層が、SLT、ROUTE、又はHTTPとされる。

すなわち、第１０のスタック構成の通信系スタックは、第４のスタック構成（図３４）の第２の通信系のスタックと同様に、ATSC3.0のプロトコルスタックに対応しているため、マルチキャストミドルウェア２３１等は、ATSC3.0のミドルウェアと等価な機能を有している。

なお、第１０のスタック構成において、放送系のスタックは、上述した第７のスタック構成（図３７）と同様であるため、その説明は省略する。

（１１）第１１のスタック構成

図４１は、第１１のスタック構成の例を示す図である。

図４１の第１１のスタック構成においては、上述した第１０のスタック構成（図４０）と同様に、放送受信デバイス６０とマルチキャスト終端デバイス７０とが一体化された同梱型デバイスのスタック構成を示しているが、放送系のスタックが異なっている。

第１１のスタック構成において、同梱型デバイスの放送系のスタックとしては、第１の階層が、TLV/放送PHYとされ、第２の階層が、IPとされ、第３の階層が、MMTP/UDPとされ、第４の階層が、Audio/Video ES又はPSI/SIとされる。

すなわち、第１１のスタック構成の放送系のスタックでは、MPEG2-TS方式ではなく、IP伝送方式を用いて、IPパケットをTLVパケットにカプセル化して、物理層フレーム（放送PHY）に含めるようにしているため、すべてのスタックでIPのプロトコルが使われて共通化されている。

また、第１１のスタック構成の通信系のスタックは、第１０のスタック構成（図４０）と同様に、ATSC3.0のプロトコルスタックに対応しているため、マルチキャストミドルウェア２３１等は、ATSC3.0のミドルウェアと等価な機能を有している。

（１２）第１２のスタック構成

図４２は、第１２のスタック構成の例を示す図である。

図４２の第１２のスタック構成においては、上述した第１０のスタック構成（図４０）と同様に、放送受信デバイス６０とマルチキャスト終端デバイス７０とが一体化された同梱型デバイスのスタック構成を示しているが、放送系のスタックが異なっている。

第１２のスタック構成において、同梱型デバイスの放送系のスタックとしては、第１の階層が、放送PHYとされ、第２の階層が、MPEG2-TSとされ、第３の階層が、Sectionとされ、第４の階層が、IPとされ、第５の階層が、UDPとされ、第６の階層がROUTE又はFLUTEとされる。また、第４の階層乃至第６の階層が、PSI/SIとされる。

すなわち、第１２のスタック構成の放送系のスタックでは、PSI/SIだけでなく、UDPパケットを含むIPパケットについてもセクション形式で伝送される。

また、第１２のスタック構成の通信系のスタックは、第１０のスタック構成（図４０）と同様に、ATSC3.0のプロトコルスタックに対応しているため、マルチキャストミドルウェア２３１等は、ATSC3.0のミドルウェアと等価な機能を有している。

以上、本技術が提案する方式に適用可能なプロトコルスタック構成について説明した。

＜４．変形例＞

（本技術が提案する方式の対象）
上述した説明としては、デジタル放送の放送方式として、米国等で採用されている方式であるATSC（特に、ATSC3.0）について説明したが、本技術が提案する方式は、ATSCに限らず、日本等が採用する方式であるISDB(Integrated Services Digital Broadcasting)や、欧州の各国等が採用する方式であるDVB(Digital Video Broadcasting)等の放送方式に適用するようにしてもよい。

また、本技術が提案する方式は、地上波放送のほか、放送衛星（BS)や通信衛星（CS）等を利用した衛星放送や、ケーブルテレビ（CATV）等の有線放送などの放送方式にも適用することが可能である。さらにまた、本技術が提案する方式は、MPEG2-TS方式やIP伝送方式など、様々な方式のデータ伝送の方式にも適用することが可能である。

また、本技術が提案する方式は、伝送路として、地上波放送等の放送網以外の伝送路、すなわち、例えば、インターネットや電話網等の通信回線（通信網）などを利用することを想定して規定されている所定の規格（デジタル放送の規格以外の規格）などにも適用することができる。

（アプリケーションやコンテンツの他の例）
放送アプリケーションは、HTML5などのマークアップ言語やJavaScript（登録商標）等のスクリプト言語で開発されたアプリケーションに限らず、例えば、Java（登録商標）などのプログラミング言語で開発されたアプリケーションであってもよい。

また、放送アプリケーションは、ブラウザ１０９（図３）により実行されるアプリケーションに限らず、いわゆるネイティブアプリケーションとして、OS（Operating System）環境（提示制御環境）などで実行されるようにしてもよい。

さらに、上述した説明では、アプリケーションとして、放送経由で配信される放送アプリケーションを説明したが、放送アプリケーションに限らず、ブロードバンドネットワーク３等の通信経由で配信される通信アプリケーションであってもよい。

また、上述した地上波コンテンツやブロードバンドコンテンツ等のコンテンツには、番組やCMなどのほか、例えば、動画や静止画、音楽、電子書籍、ゲーム、広告など、あらゆるコンテンツを含めることができる。

（システムの他の構成）
上述した説明では、図１のコンテンツ配信システム１において、地上波放送向けストリームサーバ２０や地上波放送サーバ３０、ブロードバンド向けストリームサーバ４０やブロードバンドサーバ５０など、提供する機能ごとにサーバを設けた構成を示したが、それらの機能の全部又は一部をまとめて、１又は複数のサーバにより提供されるようにしてもよい。

（その他）
また、上述したシグナリングやパケットなどの名称は、一例であって、他の名称が用いられる場合がある。ただし、これらの名称の違いは、形式的な違いであって、対象のシグナリングやパケットなどの実質的な内容が異なるものではない。また、パケットとフレームは同一の意味で用いられる場合がある。

例えば、AIT(Application Information Table)は、AST(Application Signaling Table)などと称される場合がある。また、例えば、TLV(Type Length Value)パケットは、ALP(ATSC Link-Layer Protocol)パケットなどと称される場合がある。さらに、MIT(Multicast Information Table)などについても他の名称が用いられる場合がある。

なお、本明細書において、2K解像度とは、概ね1920×1080ピクセル前後の画面解像度に対応した映像であり、4K解像度とは、概ね4000×2000ピクセル前後の画面解像度に対応した映像である。

また、上述した説明では、高画質のコンテンツとして、4K解像度のコンテンツを説明したが、8K解像度等のさらに高画質のコンテンツであってもよい。ただし、8K解像度とは、概ね7680×4320ピクセル前後の画面解像度に対応した映像である。

＜５．コンピュータの構成＞

上述した一連の処理は、ハードウェアにより実行することもできるし、ソフトウェアにより実行することもできる。一連の処理をソフトウェアにより実行する場合には、そのソフトウェアを構成するプログラムが、コンピュータにインストールされる。

図４３は、上述した一連の処理をプログラムにより実行するコンピュータのハードウェアの構成例を示す図である。

コンピュータ１０００において、CPU(Central Processing Unit)１００１、ROM(Read Only Memory)１００２、RAM(Random Access Memory)１００３は、バス１００４により相互に接続されている。バス１００４には、さらに、入出力インターフェース１００５が接続されている。入出力インターフェース１００５には、入力部１００６、出力部１００７、記録部１００８、通信部１００９、及び、ドライブ１０１０が接続されている。

入力部１００６は、キーボード、マウス、マイクロフォンなどよりなる。出力部１００７は、ディスプレイ、スピーカなどよりなる。記録部１００８は、ハードディスクや不揮発性のメモリなどよりなる。通信部１００９は、ネットワークインターフェースなどよりなる。ドライブ１０１０は、磁気ディスク、光ディスク、光磁気ディスク、又は半導体メモリなどのリムーバブル記録媒体１０１１を駆動する。

以上のように構成されるコンピュータ１０００では、CPU１００１が、ROM１００２や記録部１００８に記録されているプログラムを、入出力インターフェース１００５及びバス１００４を介して、RAM１００３にロードして実行することにより、上述した一連の処理が行われる。

コンピュータ１０００（CPU１００１）が実行するプログラムは、例えば、パッケージメディア等としてのリムーバブル記録媒体１０１１に記録して提供することができる。また、プログラムは、ローカルエリアネットワーク、インターネット、デジタル衛星放送といった、有線又は無線の伝送媒体を介して提供することができる。

コンピュータ１０００では、プログラムは、リムーバブル記録媒体１０１１をドライブ１０１０に装着することにより、入出力インターフェース１００５を介して、記録部１００８にインストールすることができる。また、プログラムは、有線又は無線の伝送媒体を介して、通信部１００９で受信し、記録部１００８にインストールすることができる。その他、プログラムは、ROM１００２や記録部１００８に、あらかじめインストールしておくことができる。

ここで、本明細書において、コンピュータがプログラムに従って行う処理は、必ずしもフローチャートとして記載された順序に沿って時系列に行われる必要はない。すなわち、コンピュータがプログラムに従って行う処理は、並列的あるいは個別に実行される処理（例えば、並列処理あるいはオブジェクトによる処理）も含む。また、プログラムは、１のコンピュータ（プロセッサ）により処理されるものであってもよいし、複数のコンピュータによって分散処理されるものであってもよい。

なお、本技術の実施の形態は、上述した実施の形態に限定されるものではなく、本技術の要旨を逸脱しない範囲において種々の変更が可能である。

また、本技術は、以下のような構成をとることができる。

（１）
放送コンテンツと同時にマルチキャスト配信される通信コンテンツのマルチキャストセッションを事前に予約し、前記通信コンテンツが要求されたとき、前記マルチキャストセッションを利用して配信される前記通信コンテンツを要求元に転送する処理部を備える
情報処理装置。
（２）
前記処理部は、前記放送コンテンツ又は前記通信コンテンツの再生を行う第１の装置から、マルチキャストの予約指示がなされた場合に、前記マルチキャストセッションを確立する
前記（１）に記載の情報処理装置。
（３）
前記処理部は、前記第１の装置から通知される、前記マルチキャストセッションを確立するためのセッション記述情報に基づいて、通信ネットワーク内でマルチキャストの中継を行う第２の装置との間で、前記マルチキャストセッションを確立する
前記（２）に記載の情報処理装置。
（４）
前記通信ネットワークは、IP(Internet Protocol)ネットワークを含み、
前記セッション記述情報は、前記マルチキャストセッション内の宛先マルチキャスト用のIPアドレスとポート番号を少なくとも含んでいる
前記（３）に記載の情報処理装置。
（５）
前記第２の装置は、ルータ装置を含み、
前記IPネットワーク内で、前記通信コンテンツのマルチキャスト配信を行う通信サーバからのIPマルチキャストストリームを中継する複数のルータ装置の間の経路情報が、前記マルチキャストセッションが確立されたときに生成される
前記（４）に記載の情報処理装置。
（６）
前記処理部は、マルチキャスト配信されるシグナリングに含まれる、前記マルチキャストセッションを確立するためのセッション記述情報に基づいて、通信ネットワーク内でマルチキャストの中継を行う第２の装置との間で、前記マルチキャストセッションを確立する
前記（２）に記載の情報処理装置。
（７）
前記処理部は、ユニキャスト配信されるシグナリングに含まれる、前記マルチキャストセッションを確立するためのセッション記述情報に基づいて、通信ネットワーク内でマルチキャストの中継を行う第２の装置との間で、前記マルチキャストセッションを確立する
前記（２）に記載の情報処理装置。
（８）
通信サーバからマルチキャスト配信される前記通信コンテンツを、通信ネットワークを介して受信する受信部と、
受信された前記通信コンテンツを、前記放送コンテンツ又は前記通信コンテンツの再生を行う第１の装置に送信する送信部と
をさらに備える前記（１）乃至（７）のいずれかに記載の情報処理装置。
（９）
放送波として送信されてくる前記放送コンテンツを受信する第１の受信部と、
マルチキャスト配信される前記通信コンテンツを、通信ネットワークを介して受信する第２の受信部と、
前記放送コンテンツ又は前記通信コンテンツを再生する再生部と
をさらに備える前記（１）乃至（７）のいずれかに記載の情報処理装置。
（１０）
情報処理装置の情報処理方法において、
前記情報処理装置が、
放送コンテンツと同時にマルチキャスト配信される通信コンテンツのマルチキャストセッションを事前に予約し、前記通信コンテンツが要求されたとき、前記マルチキャストセッションを利用して配信される前記通信コンテンツを要求元に転送する
ステップを含む情報処理方法。
（１１）
放送波として送信されてくる放送コンテンツを受信する第１の受信部と、
マルチキャスト配信される通信コンテンツを、通信ネットワークを介して受信する第２の受信部と、
第１のタイミングで、前記放送コンテンツと同時にマルチキャスト配信される前記通信コンテンツのマルチキャストセッションの開始を要求し、前記第１のタイミングよりも時間的に後の第２のタイミングで、前記通信コンテンツを要求する処理部と
を備える受信装置。
（１２）
前記第１の受信部は、放送波として送信されてくる放送アプリケーションを受信し、
前記処理部は、前記放送アプリケーションの動作に応じて、前記第１のタイミングで、前記マルチキャストセッションの開始を要求する
前記（１１）に記載の受信装置。
（１３）
前記第１の受信部は、放送波として送信されてくるシグナリングを受信し、
前記処理部は、前記シグナリングの解析結果に応じて、前記第１のタイミングで、前記マルチキャストセッションの開始を要求する
前記（１１）に記載の受信装置。
（１４）
前記第１の受信部は、受信可能な全チャンネル分の前記シグナリングを受信し、
前記処理部は、全チャンネル分の前記シグナリングの解析結果に応じて、前記第１のタイミングで、前記マルチキャストセッションの開始を要求する
前記（１３）に記載の受信装置。
（１５）
前記処理部は、前記第１のタイミングで、前記マルチキャストセッションを確立するためのセッション記述情報を、前記マルチキャストセッションの予約を行う第１の装置に通知することで、前記マルチキャストセッションの開始を要求する
前記（１１）に記載の受信装置。
（１６）
前記通信ネットワークは、IPネットワークを含み、
前記IPネットワークには、前記通信コンテンツのマルチキャスト配信を行う通信サーバが接続され、
前記IPネットワーク内には、マルチキャストの中継を行う複数のルータ装置が配置され、
前記セッション記述情報は、前記マルチキャストセッション内の宛先マルチキャスト用のIPアドレスとポート番号を少なくとも含んでいる
前記（１５）に記載の受信装置。
（１７）
前記第２の受信部は、ユニキャスト配信される通信コンテンツを、前記通信ネットワークを介して受信し、
前記第１の受信部は、前記通信ネットワークで輻輳が検知された場合に、放送波として送信されてくる更新後の放送アプリケーション、又は前記放送アプリケーションに対するイベントを受信し、
前記処理部は、
前記更新後の放送アプリケーション、又は前記イベントを検知した前記放送アプリケーションの動作に応じて、前記第１のタイミングで、通信コンテンツのマルチキャストセッションの開始を要求し、
前記第２のタイミングで、マルチキャスト配信される通信コンテンツを要求し、
前記第２の受信部は、マルチキャスト配信される通信コンテンツを、前記通信ネットワークを介して受信する
前記（１２）に記載の受信装置。
（１８）
前記処理部は、前記放送アプリケーションの動作に応じて、前記第２のタイミングで、前記通信コンテンツを要求する
前記（１２）に記載の受信装置。
（１９）
前記放送コンテンツ又は前記通信コンテンツを再生する再生部をさらに備える
前記（１１）乃至（１８）のいずれかに記載の受信装置。
（２０）
放送波として送信されてくる放送コンテンツを受信する第１の受信部と、
マルチキャスト配信される通信コンテンツを、通信ネットワークを介して受信する第２の受信部と
を備える受信装置の情報処理方法において、
前記受信装置が、
第１のタイミングで、前記放送コンテンツと同時にマルチキャスト配信される前記通信コンテンツのマルチキャストセッションの開始を要求し、前記第１のタイミングよりも時間的に後の第２のタイミングで、前記通信コンテンツを要求する
ステップを含む情報処理方法。

１コンテンツ配信システム，２地上波放送ネットワーク，３ブロードバンドネットワーク，１０放送コンテンツマネジメントシステム，２０地上波放送向けストリームサーバ，３０地上波放送サーバ，４０ブロードバンド向けストリームサーバ，５０ブロードバンドサーバ，６０放送受信デバイス，７０マルチキャスト終端デバイス，８０，８０−１乃至８０−５マルチキャスト中継ルータ，１０１処理部，１０２入力部，１０３記憶部，１０４チューナ，１０５放送ミドルウェア，１０６ DASHクライアント，１０７レンダラ，１０８出力部，１０９ブラウザ，１１０通信I/F，１３１放送制御部，１３２通信制御部，１３３ネット配信予約準備処理部，１３４シグナリング処理部，２０１処理部，２０２通信I/F，２０３通信I/F，２３１マルチキャストミドルウェア，２３２ウェブサーバ，２３３シグナリング処理部，１０００コンピュータ，１００１ CPU

Claims

放送コンテンツと同時にマルチキャスト配信される通信コンテンツのマルチキャストセッションを事前に予約し、前記通信コンテンツが要求されたとき、前記マルチキャストセッションを利用して配信される前記通信コンテンツを要求元に転送する処理部を備える
情報処理装置。
前記処理部は、前記放送コンテンツ又は前記通信コンテンツの再生を行う第１の装置から、マルチキャストの予約指示がなされた場合に、前記マルチキャストセッションを確立する
請求項１に記載の情報処理装置。
前記処理部は、前記第１の装置から通知される、前記マルチキャストセッションを確立するためのセッション記述情報に基づいて、通信ネットワーク内でマルチキャストの中継を行う第２の装置との間で、前記マルチキャストセッションを確立する
請求項２に記載の情報処理装置。
前記通信ネットワークは、IP(Internet Protocol)ネットワークを含み、
前記セッション記述情報は、前記マルチキャストセッション内の宛先マルチキャスト用のIPアドレスとポート番号を少なくとも含んでいる
請求項３に記載の情報処理装置。
前記第２の装置は、ルータ装置を含み、
前記IPネットワーク内で、前記通信コンテンツのマルチキャスト配信を行う通信サーバからのIPマルチキャストストリームを中継する複数のルータ装置の間の経路情報が、前記マルチキャストセッションが確立されたときに生成される
請求項４に記載の情報処理装置。
前記処理部は、マルチキャスト配信されるシグナリングに含まれる、前記マルチキャストセッションを確立するためのセッション記述情報に基づいて、通信ネットワーク内でマルチキャストの中継を行う第２の装置との間で、前記マルチキャストセッションを確立する
請求項２に記載の情報処理装置。
前記処理部は、ユニキャスト配信されるシグナリングに含まれる、前記マルチキャストセッションを確立するためのセッション記述情報に基づいて、通信ネットワーク内でマルチキャストの中継を行う第２の装置との間で、前記マルチキャストセッションを確立する
請求項２に記載の情報処理装置。
通信サーバからマルチキャスト配信される前記通信コンテンツを、通信ネットワークを介して受信する受信部と、
受信された前記通信コンテンツを、前記放送コンテンツ又は前記通信コンテンツの再生を行う第１の装置に送信する送信部と
をさらに備える請求項１に記載の情報処理装置。
放送波として送信されてくる前記放送コンテンツを受信する第１の受信部と、
マルチキャスト配信される前記通信コンテンツを、通信ネットワークを介して受信する第２の受信部と、
前記放送コンテンツ又は前記通信コンテンツを再生する再生部と
をさらに備える請求項１に記載の情報処理装置。
情報処理装置の情報処理方法において、
前記情報処理装置が、
放送コンテンツと同時にマルチキャスト配信される通信コンテンツのマルチキャストセッションを事前に予約し、前記通信コンテンツが要求されたとき、前記マルチキャストセッションを利用して配信される前記通信コンテンツを要求元に転送する
ステップを含む情報処理方法。
放送波として送信されてくる放送コンテンツを受信する第１の受信部と、
マルチキャスト配信される通信コンテンツを、通信ネットワークを介して受信する第２の受信部と、
第１のタイミングで、前記放送コンテンツと同時にマルチキャスト配信される前記通信コンテンツのマルチキャストセッションの開始を要求し、前記第１のタイミングよりも時間的に後の第２のタイミングで、前記通信コンテンツを要求する処理部と
を備える受信装置。
前記第１の受信部は、放送波として送信されてくる放送アプリケーションを受信し、
前記処理部は、前記放送アプリケーションの動作に応じて、前記第１のタイミングで、前記マルチキャストセッションの開始を要求する
請求項１１に記載の受信装置。
前記第１の受信部は、放送波として送信されてくるシグナリングを受信し、
前記処理部は、前記シグナリングの解析結果に応じて、前記第１のタイミングで、前記マルチキャストセッションの開始を要求する
請求項１１に記載の受信装置。
前記第１の受信部は、受信可能な全チャンネル分の前記シグナリングを受信し、
前記処理部は、全チャンネル分の前記シグナリングの解析結果に応じて、前記第１のタイミングで、前記マルチキャストセッションの開始を要求する
請求項１３に記載の受信装置。
前記処理部は、前記第１のタイミングで、前記マルチキャストセッションを確立するためのセッション記述情報を、前記マルチキャストセッションの予約を行う第１の装置に通知することで、前記マルチキャストセッションの開始を要求する
請求項１１に記載の受信装置。
前記通信ネットワークは、IPネットワークを含み、
前記IPネットワークには、前記通信コンテンツのマルチキャスト配信を行う通信サーバが接続され、
前記IPネットワーク内には、マルチキャストの中継を行う複数のルータ装置が配置され、
前記セッション記述情報は、前記マルチキャストセッション内の宛先マルチキャスト用のIPアドレスとポート番号を少なくとも含んでいる
請求項１５に記載の受信装置。
前記第２の受信部は、ユニキャスト配信される通信コンテンツを、前記通信ネットワークを介して受信し、
前記第１の受信部は、前記通信ネットワークで輻輳が検知された場合に、放送波として送信されてくる更新後の放送アプリケーション、又は前記放送アプリケーションに対するイベントを受信し、
前記処理部は、
前記更新後の放送アプリケーション、又は前記イベントを検知した前記放送アプリケーションの動作に応じて、前記第１のタイミングで、通信コンテンツのマルチキャストセッションの開始を要求し、
前記第２のタイミングで、マルチキャスト配信される通信コンテンツを要求し、
前記第２の受信部は、マルチキャスト配信される通信コンテンツを、前記通信ネットワークを介して受信する
請求項１２に記載の受信装置。
前記処理部は、前記放送アプリケーションの動作に応じて、前記第２のタイミングで、前記通信コンテンツを要求する
請求項１２に記載の受信装置。
前記放送コンテンツ又は前記通信コンテンツを再生する再生部をさらに備える
請求項１１に記載の受信装置。
放送波として送信されてくる放送コンテンツを受信する第１の受信部と、
マルチキャスト配信される通信コンテンツを、通信ネットワークを介して受信する第２の受信部と
を備える受信装置の情報処理方法において、
前記受信装置が、
第１のタイミングで、前記放送コンテンツと同時にマルチキャスト配信される前記通信コンテンツのマルチキャストセッションの開始を要求し、前記第１のタイミングよりも時間的に後の第２のタイミングで、前記通信コンテンツを要求する
ステップを含む情報処理方法。