(57)【要約】  本開示は、コンテンツの配信をより効率よく行うことができるようにする情報処理装置および方法、プログラム、並びにコンテンツ供給システムに関する。コンテンツの供給にマルチキャスト配信若しくは放送配信を利用するか否かを判定し、前記マルチキャスト配信若しくは前記放送配信を利用すると判定された場合、前記コンテンツの供給に前記マルチキャスト配信若しくは前記放送配信を利用するように、前記コンテンツのユニキャスト配信に関する制御情報を更新する。本開示は、例えば、情報処理装置に適用することができる。
2014132821.tif 000002
【特許請求の範囲】
【請求項１】
コンテンツの供給にマルチキャスト配信若しくは放送配信を利用するか否かを判定する判定部と、
前記判定部により前記マルチキャスト配信若しくは前記放送配信を利用すると判定された場合、前記コンテンツの供給に前記マルチキャスト配信若しくは前記放送配信を利用するように、前記コンテンツのユニキャスト配信に関する制御情報を更新する更新部と
を備える情報処理装置。
【請求項２】
前記判定部は、前記コンテンツの供給にマルチキャスト配信若しくは放送配信を利用する場合のコストを評価し、その評価結果に応じて、前記コンテンツの供給にマルチキャスト配信若しくは放送配信を利用するか否かを判定する
請求項１に記載の情報処理装置。
【請求項３】
前記制御情報を受け取る受け取り部をさらに備え、
前記判定部は、前記受け取り部により受け取られた前記制御情報に応じて、前記コンテンツの供給にマルチキャスト配信若しくは放送配信を利用する場合のコストを評価し、その評価結果に応じて、前記コンテンツの供給にマルチキャスト配信若しくは放送配信を利用するか否かを判定し、
前記更新部は、前記判定部により前記マルチキャスト配信若しくは前記放送配信を利用すると判定された場合、前記コンテンツの供給に前記マルチキャスト配信若しくは前記放送配信を利用するように、前記受け取り部により受け取られた前記制御情報を更新する
請求項２に記載の情報処理装置。
【請求項４】
前記判定部は、前記受け取り部により受け取られた前記制御情報の量に応じて、前記コストを評価する
請求項３に記載の情報処理装置。
【請求項５】
前記受け取り部は、所定のネットワークに接続されるクライアントから供給される前記制御情報を受け取る
請求項３に記載の情報処理装置。
【請求項６】
前記受け取り部は、前記コンテンツを供給するサーバのプロキシサーバから供給される、前記プロキシサーバがクライアントから収集した前記制御情報を受け取る
請求項３に記載の情報処理装置。
【請求項７】
マルチキャスト配信若しくは放送配信のリソースの利用状況を確認する確認部をさらに備え、
前記判定部は、前記確認部により確認された利用可能な前記リソースを利用する場合についての前記コストを評価する
請求項２に記載の情報処理装置。
【請求項８】
前記判定部により前記マルチキャスト配信若しくは前記放送配信を利用すると判定された場合、前記コンテンツを供給するためのマルチキャスト配信若しくは放送配信のリソースを確保する確保部をさらに備え、
前記更新部は、前記コンテンツの供給に、前記確保部により確保された前記リソースを利用するように、前記制御情報を更新する
請求項１に記載の情報処理装置。
【請求項９】
前記コンテンツは、DASH（Dynamic Adaptive Streaming over HTTP）フォーマットのストリームであり、
前記制御情報は、MPD（Media Presentation Description）である
請求項１に記載の情報処理装置。
【請求項１０】
前記更新部は、前記MPDのBaseURLに配置されるserviceLocationAttribute URL属性により指定されるService Locationファイルの、DeliverySystemIdentifierに、前記コンテンツの供給に利用するマルチキャスト配信若しくは放送配信を識別する識別子を格納する
請求項９に記載の情報処理装置。
【請求項１１】
前記更新部は、前記MPDのBaseURLに配置されるserviceLocationAttribute URL属性により指定されるService Locationファイルの、DeliverySystemDescriptorに、前記DeliverySystemIdentifierに格納された識別子に対応するシステムにおいてストリームデータを取得するためのパラメタを格納する
請求項１０に記載の情報処理装置。
【請求項１２】
前記コンテンツのユニキャスト用のストリームをユニキャスト配信するユニキャスト配信部をさらに備える
請求項１に記載の情報処理装置。
【請求項１３】
前記コンテンツのユニキャスト用のストリームをマルチキャスト配信若しくは放送配信用のストリームに変換する変換部と、
前記変換部により生成された前記ストリームをマルチキャスト配信若しくは放送配信するBC/MC配信部をさらに備える
請求項１２に記載の情報処理装置。
【請求項１４】
前記ユニキャスト用のストリームは、DASH（Dynamic Adaptive Streaming over HTTP）フォーマットのストリームであり、
前記変換部により生成されたマルチキャスト配信若しくは放送配信用のストリームは、FLUTE（File Delivery over Unidirectional Transport）プロトコルのファイルである
請求項１３に記載の情報処理装置。
【請求項１５】
前記変換部は、前記FLUTEプロトコルのファイルのFDT（File Delivery Table）-Instanceにおいて、File要素の属性としてrange属性を導入する
請求項１４に記載の情報処理装置。
【請求項１６】
前記更新部により更新された前記制御情報を供給する供給部をさらに備える
請求項１に記載の情報処理装置。
【請求項１７】
クライアントの代わりに前記コンテンツを取得し、
前記供給部より供給される前記制御情報に応じて、取得した前記コンテンツをユニキャスト配信により前記クライアントに供給するか、若しくは、取得した前記コンテンツを、マルチキャスト配信若しくは放送配信のリソースを利用して前記クライアントに供給する供給制御部をさらに備える
請求項１６に記載の情報処理装置。
【請求項１８】
コンテンツの供給にマルチキャスト配信若しくは放送配信を利用するか否かを判定し、
前記マルチキャスト配信若しくは前記放送配信を利用すると判定された場合、前記コンテンツの供給に前記マルチキャスト配信若しくは前記放送配信を利用するように、前記コンテンツのユニキャスト配信に関する制御情報を更新する
情報処理方法。
【請求項１９】
コンピュータを、
コンテンツの供給にマルチキャスト配信若しくは放送配信を利用するか否かを判定する判定部と、
前記判定部により前記マルチキャスト配信若しくは前記放送配信を利用すると判定された場合、前記コンテンツの供給に前記マルチキャスト配信若しくは前記放送配信を利用するように、前記コンテンツのユニキャスト配信に関する制御情報を更新する更新部と
して機能させるプログラム。
【請求項２０】
サーバからクライアントにコンテンツを供給するコンテンツ供給システムであって、
前記クライアントからの前記コンテンツの取得要求量に応じて、前記コンテンツの供給にマルチキャスト配信若しくは放送配信を利用するか否かを判定し、
前記マルチキャスト配信若しくは前記放送配信を利用すると判定された場合、前記サーバから前記クライアントへの前記コンテンツの供給に前記マルチキャスト配信若しくは前記放送配信を利用するように、前記コンテンツのユニキャスト配信に関する制御情報を更新する
コンテンツ供給システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本開示は情報処理装置および方法、プログラム、並びにコンテンツ供給システムに関し、特に、コンテンツの配信をより効率よく行うことができるようにした情報処理装置および方法、プログラム、並びにコンテンツ供給システムに関する。
【背景技術】
【０００２】
近年、インターネット上のストリーミングサービスの主流がOTT-V（Over The Top Video）となっている。この基盤技術として普及し始めているのがDASH（Dynamic Adaptive Streaming over HTTP）である（例えば、非特許文献１参照）。【０００３】
DASHはポイントトゥーポイントのHTTP（HyperText Transfer Protocol）ストリーミングにより実現されるため、スポーツ中継等の大多数のクライアントが同時に視聴する可能性のあるコンテンツ（番組）のストリーミングに適用する場合、例えばAkamai（登録商標）等のCDN（Contents Delivery Network）のサポートが必要となることがある。【０００４】
ただし、一般的に、CDNは、コスト的な制約から、既存の放送配信に匹敵する程のスケーラビリティを求めることはできないので、マルチキャストやブロードキャストベアラを併用することにより、ネットワークリソースの負荷を低減する方法が考えられた。
【先行技術文献】
【非特許文献】
【０００５】
【非特許文献１】「既存のWebサーバで途切れない動画配信を実現」、平林光浩、NIKKEI ELECTRONICS 2012.3.19
【発明の概要】
【発明が解決しようとする課題】
【０００６】
しかしながら、この方法を適用するだけでは、併用するマルチキャスト・ブロードキャストネットワークリソースの容量等によって、常に十分なコストメリットが得られるとは限らなかった。【０００７】
本開示は、このような状況に鑑みてなされたものであり、コンテンツの配信をより効率よく行うことができるようにするものである。
【課題を解決するための手段】
【０００８】
本技術の一側面は、コンテンツの供給にマルチキャスト配信若しくは放送配信を利用するか否かを判定する判定部と、前記判定部により前記マルチキャスト配信若しくは前記放送配信を利用すると判定された場合、前記コンテンツの供給に前記マルチキャスト配信若しくは前記放送配信を利用するように、前記コンテンツのユニキャスト配信に関する制御情報を更新する更新部とを備える情報処理装置である。【０００９】
前記判定部は、前記コンテンツの供給にマルチキャスト配信若しくは放送配信を利用する場合のコストを評価し、その評価結果に応じて、前記コンテンツの供給にマルチキャスト配信若しくは放送配信を利用するか否かを判定することができる。【００１０】
前記制御情報を受け取る受け取り部をさらに備え、前記判定部は、前記受け取り部により受け取られた前記制御情報に応じて、前記コンテンツの供給にマルチキャスト配信若しくは放送配信を利用する場合のコストを評価し、その評価結果に応じて、前記コンテンツの供給にマルチキャスト配信若しくは放送配信を利用するか否かを判定し、前記更新部は、前記判定部により前記マルチキャスト配信若しくは前記放送配信を利用すると判定された場合、前記コンテンツの供給に前記マルチキャスト配信若しくは前記放送配信を利用するように、前記受け取り部により受け取られた前記制御情報を更新することができる。【００１１】
前記判定部は、前記受け取り部により受け取られた前記制御情報の量に応じて、前記コストを評価することができる。【００１２】
前記受け取り部は、所定のネットワークに接続されるクライアントから供給される前記制御情報を受け取ることができる。【００１３】
前記受け取り部は、前記コンテンツを供給するサーバのプロキシサーバから供給される、前記プロキシサーバがクライアントから収集した前記制御情報を受け取ることができる。【００１４】
マルチキャスト配信若しくは放送配信のリソースの利用状況を確認する確認部をさらに備え、前記判定部は、前記確認部により確認された利用可能な前記リソースを利用する場合についての前記コストを評価することができる。【００１５】
前記判定部により前記マルチキャスト配信若しくは前記放送配信を利用すると判定された場合、前記コンテンツを供給するためのマルチキャスト配信若しくは放送配信のリソースを確保する確保部をさらに備え、前記更新部は、前記コンテンツの供給に、前記確保部により確保された前記リソースを利用するように、前記制御情報を更新することができる。【００１６】
前記コンテンツは、DASH（Dynamic Adaptive Streaming over HTTP）フォーマットのストリームであり、前記制御情報は、MPD（Media Presentation Description）であるようにすることができる。【００１７】
前記更新部は、前記MPDのBaseURLに配置されるserviceLocationAttribute URL属性により指定されるService Locationファイルの、DeliverySystemIdentifierに、前記コンテンツの供給に利用するマルチキャスト配信若しくは放送配信を識別する識別子を格納することができる。【００１８】
前記更新部は、前記MPDのBaseURLに配置されるserviceLocationAttribute URL属性により指定されるService Locationファイルの、DeliverySystemDescriptorに、前記DeliverySystemIdentifierに格納された識別子に対応するシステムにおいてストリームデータを取得するためのパラメタを格納することができる。【００１９】
前記コンテンツのユニキャスト用のストリームをユニキャスト配信するユニキャスト配信部をさらに備えることができる。【００２０】
前記コンテンツのユニキャスト用のストリームをマルチキャスト配信若しくは放送配信用のストリームに変換する変換部と、前記変換部により生成された前記ストリームをマルチキャスト配信若しくは放送配信するBC/MC配信部をさらに備えることができる。【００２１】
前記ユニキャスト用のストリームは、DASH（Dynamic Adaptive Streaming over HTTP）フォーマットのストリームであり、前記変換部により生成されたマルチキャスト配信若しくは放送配信用のストリームは、FLUTE（File Delivery over Unidirectional Transport）プロトコルのファイルであることができる。【００２２】
前記変換部は、前記FLUTEプロトコルのファイルのFDT（File Delivery Table）-Instanceにおいて、File要素の属性としてrange属性を導入することができる。【００２３】
前記更新部により更新された前記制御情報を供給する供給部をさらに備えることができる。【００２４】
クライアントの代わりに前記コンテンツを取得し、前記供給部より供給される前記制御情報に応じて、取得した前記コンテンツをユニキャスト配信により前記クライアントに供給するか、若しくは、取得した前記コンテンツを、マルチキャスト配信若しくは放送配信のリソースを利用して前記クライアントに供給する供給制御部をさらに備えることができる。【００２５】
本技術の一側面は、また、コンテンツの供給にマルチキャスト配信若しくは放送配信を利用するか否かを判定し、前記マルチキャスト配信若しくは前記放送配信を利用すると判定された場合、前記コンテンツの供給に前記マルチキャスト配信若しくは前記放送配信を利用するように、前記コンテンツのユニキャスト配信に関する制御情報を更新する情報処理方法である。【００２６】
本技術の一側面は、さらに、コンピュータを、コンテンツの供給にマルチキャスト配信若しくは放送配信を利用するか否かを判定する判定部と、前記判定部により前記マルチキャスト配信若しくは前記放送配信を利用すると判定された場合、前記コンテンツの供給に前記マルチキャスト配信若しくは前記放送配信を利用するように、前記コンテンツのユニキャスト配信に関する制御情報を更新する更新部として機能させるプログラムである。【００２７】
本技術の一側面は、また、サーバからクライアントにコンテンツを供給するコンテンツ供給システムであって、前記クライアントからの前記コンテンツの取得要求量に応じて、前記コンテンツの供給にマルチキャスト配信若しくは放送配信を利用するか否かを判定し、前記マルチキャスト配信若しくは前記放送配信を利用すると判定された場合、前記サーバから前記クライアントへの前記コンテンツの供給に前記マルチキャスト配信若しくは前記放送配信を利用するように、前記コンテンツのユニキャスト配信に関する制御情報を更新するコンテンツ供給システムである。【００２８】
本技術においては、コンテンツの供給にマルチキャスト配信若しくは放送配信を利用するか否かが判定され、マルチキャスト配信若しくは放送配信を利用すると判定された場合、コンテンツの供給にマルチキャスト配信若しくは放送配信を利用するように、コンテンツのユニキャスト配信に関する制御情報が更新される。
【発明の効果】
【００２９】
本開示によれば、コンテンツの配信に関する情報を処理することができる。特に、コンテンツの配信をより効率よく行うようにすることができる。
【図面の簡単な説明】
【００３０】
【図１】従来のコンテンツ配信システムの例を説明する図である。
【図２】DASHの概要を説明する図である。
【図３】MPDの構成例を示す図である。
【図４】コンテンツの時間的区切りを説明する図である。
【図５】MPDにおけるPeriod以下の階層構造の例を示す図である。
【図６】MPDファイルの構成例を時間軸上で説明する図である。
【図７】MPDのRepresentation以下の構造の例を説明する図である。
【図８】MPDのXML記述例を示す図である。
【図９】セグメント取得要求の例を説明する図である。
【図１０】拡張したMPDのXML記述例を示す図である。
【図１１】serviceLocationAttributeUrl属性により指定されるServiceLocation要素のXML Schemaの一例を示す図である。
【図１２】serviceLocationAttributeUrl属性により指定されるServiceLocation要素のデータ構造を示す図である。
【図１３】User Service Description構造の例を示す図である。
【図１４】FLUTEプロトコルの階層構造を示す図である。
【図１５】FDTのデータ構造を示す図である。
【図１６】拡張したFDTのデータ構造を示す図である。
【図１７】コンテンツ配信システムの主な構成例を示すブロック図である。
【図１８】MPDコンフィギュレータの物理的構成の例を示すブロック図である。
【図１９】DASHセグメントストリーマが有する機能の例を示す機能ブロック図である。
【図２０】FLUTEサーバが有する機能の例を示す機能ブロック図である。
【図２１】放送配信サーバが有する機能の例を示す機能ブロック図である。
【図２２】DASH-MPDサーバが有する機能の例を示す機能ブロック図である。
【図２３】DASHクライアントが有する機能の例を示す機能ブロック図である。
【図２４】MPDコンフィギュレータが有する機能の例を示す機能ブロック図である。
【図２５】BC/MCリソースマネージャが有する機能の例を示す機能ブロック図である。
【図２６】DASHクライアントプロキシが有する機能の例を示す機能ブロック図である。
【図２７】配信制御処理の流れの例を説明するフローチャートである。
【図２８】DASHクライアントプロキシ処理の流れの例を説明するフローチャートである。
【図２９】コンテンツ配信処理の流れの例を説明するフローチャートである。
【図３０】コンテンツ配信処理の流れの例を説明する、図２９に続くフローチャートである。
【図３１】コンテンツ配信処理の流れの例を説明する、図２９に続くフローチャートである。
【図３２】コンテンツ配信システムの他の構成例を示すブロック図である。
【図３３】プロキシサーバが有する機能の例を示す機能ブロック図である。
【図３４】コンテンツ配信処理の流れの他の例を説明するフローチャートである。
【図３５】コンテンツ配信処理の流れの他の例を説明する、図３４に続くフローチャートである。
【図３６】コンテンツ配信処理の流れの他の例を説明する、図３４に続くフローチャートである。
【図３７】MPDおよびセグメントの配信処理の流れの例を説明するフローチャートである。
【図３８】ユニキャスト配信の場合の、MPDおよびセグメントの配信処理の流れの例を説明するフローチャートである。
【図３９】マルチキャスト配信若しくは放送配信の場合の、MPDおよびセグメントの配信処理の流れの例を説明するフローチャートである。
【図４０】マルチキャスト配信若しくは放送配信の場合の、MPDおよびセグメントの配信処理の流れの、他の例を説明するフローチャートである。
【図４１】MPDおよびセグメントをFLUTEにより配信する場合の配信処理の流れの例を説明するフローチャートである。
【図４２】プロキシサーバを介して行う場合の、MPDおよびセグメントの配信処理の流れの例を説明するフローチャートである。
【発明を実施するための形態】
【００３１】
以下、本開示を実施するための形態（以下実施の形態とする）について説明する。なお、説明は以下の順序で行う。
０．概要
１．第１の実施の形態（コンテンツ配信システム）
２．第２の実施の形態（コンテンツ配信システム）
３．第３の実施の形態（MPDおよびストリームの伝送）
【００３２】
＜０．概要＞
＜コンテンツ配信システム＞
近年、インターネット上のストリーミングサービスの主流がOTT-V（Over The Top Video）となっている。この基盤技術として普及し始めているのがDASH（Dynamic Adaptive Streaming over HTTP）である。
【００３３】
DASHは、ポイントトゥーポイントのHTTP（HyperText Transfer Protocol）ストリーミングにより実現されるため、スポーツ中継等の大多数のクライアントが同時に視聴する可能性のあるコンテンツ（番組）のストリーミングに適用する場合、例えばAkamai（登録商標）等のCDN（Contents Delivery Network）のサポートが必要となることがある。
【００３４】
図１は、DASHによるコンテンツを配信するシステムの例を説明する図である。図１に示されるコンテンツ配信システム１０は、DASHを利用して、画像や音声等よりなるコンテンツデータをサーバからクライアントに配信するシステムである。
【００３５】
図１に示される例のように、このコンテンツ配信システム１０においては、DASH-MPDファイルも、DASHセグメントもすべてCDNを介して配信される。つまり、まず、DASH MPDサーバ１１が、DASH-MPDファイル４１を、CDN２０を介して、最初にHTTPリクエストを発したDASHクライアント３１に供給する。このDASH-MPDファイル４１は、CDN２０のキャッシュサーバ（DASHキャッシュ２１）にも保持される。
【００３６】
DASHクライアント３１が、取得したDASH-MPDファイル４１に基づいて、コンテンツを要求すると、DASHセグメントストリーマ１２は、そのコンテンツであるDASHセグメント６１を、矢印５１のように、CDN２０を介して、DASHクライアント３１に供給する。図１において小さな楕円は、それぞれ、セグメント化されたコンテンツであるDASHセグメントを示している。このDASHセグメント６１も、CDN２０のキャッシュサーバ（DASHキャッシュ２２乃至DASHキャッシュ２４等）にも保持される。
【００３７】
その後、他のクライアントであるDASHクライアント３２が、同じコンテンツについてHTTPリクエストを発すると、CDN２０のDASHキャッシュ２１が、保持しているDASH-MPDファイル４１をDASH-MPDファイル４２としてDASHクライアント３２に供給する。これによりDASH MPDサーバ１１の負荷が低減される。もちろん、CDN２０のキャッシュサーバにDASH-MPDファイルがキャッシュされていない場合は、DASHクライアント３１の場合と同様に、DASH MPDサーバ１１からDASH-MPDファイル４２がDASHクライアント３２に供給される。
【００３８】
そして、DASHクライアント３２が、取得したDASH-MPDファイル４２に基づいて、コンテンツを要求すると、DASHセグメントストリーマ１２は、そのコンテンツであるDASHセグメント６１を、矢印５２のように、CDN２０を介して、DASHクライアント３２に供給する。このとき、CDN２０のキャッシュサーバ（DASHキャッシュ２２乃至DASHキャッシュ２４等）にそのコンテンツのDASHセグメント６１がキャッシュされている場合、そのDASHセグメント６１がDASHクライアント３２に供給される。これによりDASHセグメントストリーマ１２の負荷が低減される。
【００３９】
このようにCDNを利用することにより、より効率的にコンテンツを配信することができる。
【００４０】
＜DASH＞
DASHによるコンテンツの伝送の手順を、図２を参照して説明する。まず、コンテンツを取得する側のクライアントは、ブラウザ等のアプリケーション（HTTP Streaming Client）によって、所望のコンテンツのMPDを選択し、サーバ（Media Presentation on HTTP Server）から取得する。
【００４１】
MPDを取得すると、クライアントは、MPDを解析して、所望のコンテンツのDASHセグメントをサーバから取得し、それを再生する。
【００４２】
MPDは、図３に示されるような構成を有する。MPDの解析（パース）においては、クライアントは、MPD（図３のMedia Presentation）のPeriodに含まれるRepresentationの属性から最適なものを選択する。
【００４３】
クライアントは、選択したRepresentationの先頭のSegmentを呼んでInitialization Segmentを取得し、処理する。続いて、クライアントは、後続のSegmentを取得し、再生する。
【００４４】
なお、MPDにおける、Period、Representation、およびSegmentの関係は、図４のようになる。つまり、１つのメディアコンテンツは、時間方向のデータ単位であるPeriod毎に管理することができ、各Periodは、時間方向のデータ単位であるSegment毎に管理することができる。また、各Periodについて、ビットレート等の属性の異なる複数のRepresentationを構成することができる。
【００４５】
したがって、このMPDのファイル（MPDファイルとも称する）は、Period以下において、図５に示されるような階層構造を有する。また、このMPDの構造を時間軸上に並べると図６の例のようになる。図６から明らかなように、同一のSegmentに対して複数のRepresentationが存在している。クライアントは、これらのうちのいずれかを適応的に選択することにより、通信環境や自己のデコード能力などに応じて適切なストリームデータを取得し、再生することができる。
【００４６】
ただし、一般的に、CDNは、コスト的な制約から、既存の放送配信に匹敵する程のスケーラビリティを求めることはできない。
【００４７】
Representationで記述する対象は、インターネット（NIC（Network Interface Controller））経由で配信されるストリームのurlであるが、もしクライアントがMBMS（Multimedia Broadcast and Multicast Service）等のブロードキャスト・マルチキャスト用（放送系）物理層が実装されている場合、それらを経由して受信できるチャンネル上に同一のライブ放送等が配信されているときには、それら経由で受信再生した方が放送系のQoS（Quality of Service）（保証帯域/遅延等）の保証された伝送路上ではるかに品質の高いコンテンツ再生が期待できる場合がある。
【００４８】
また、コスト的にも放送を使った方がリーズナブルな配信ができる可能性がある。また、再生途中で、インターネット配信環境（トラフィック）の急激な変化により、例えば、準備されているビットレートの範囲（の下限）を超えたストリームでしか受信できないような状況になった場合には、ストリーム再生が停止してしまう。このような場合に、たとえそれがインターネット配信よりもビットレートの低いストリームであっても視聴そのものを継続したいというユーザには、放送系伝送路上のストリームにスイッチして視聴を継続させるというような代替配信が必要となる。しかしながら、現在のDASHのスコープではいずれのケースもサポートすることができなかった。
【００４９】
＜MPDの拡張＞
そこで、ネットワークリソースの負荷を低減し、より効率よくコンテンツの配信を行うことができるように、マルチキャストやブロードキャストベアラを利用することができるようにする。より具体的には、Representationの１つとして、上述の放送チャネルで配信されるストリームを指定できるようにする。そのために、放送チャネルチューニング用のパラメタを記述する要素を配置できるようにし、放送チャネルで配信されるストリーム上のファイル転送プロトコルFLUTE（File Delivery over Unidirectional Transport）に対しても拡張属性を配置できるようにする。
【００５０】
図７は、MPDのRepresentation以下の構造の例を示す図である。Representationには、セグメント化されたストリームデータが格納されたファイルのアドレスが記述される。具体的には、セグメント化された複数のストリームデータがそれぞれ個別にファイル化されている場合、各ファイルのアドレス（url情報）のシーケンスが記述される。また、セグメント化された複数のストリームデータがまとめてファイル化されている場合、該ファイルのアドレス（Base URL）と、該ファイルにおける各セグメントの範囲（mediaRange）のシーケンスが記述される。なお、図７には、後者の場合が示されている。
【００５１】
MPDに、Representationの１つとして、放送チャンネル上に配信される同一コンテンツストリームを表現する属性を記述できるようにするための拡張利用方式を以下に説明する。ストリームを構成するチャンク化されたコンテンツデータのシーケンスは、チャンク化されたコンテンツデータが格納されるファイルのurlのシーケンスか、もしくは、チャンク化されたコンテンツのデータがファイルの中に納まっている場合には、それらが格納される"ファイルのURL+バイト範囲 "のシーケンスにより表現されるようにDASHで規定されている。
【００５２】
図８は、図７に示されたRepresentation以下の構造をXML形式で記述した一例を示している。
【００５３】
図８においては、対象のMP4のメディアが格納されるファイルのURLが
MPD/Period/AdaptationSet/Representation/BaseURL
に記述されている
”http://example.com/counter-10mn_avc_dash.mp4”
で表されている。
【００５４】
また、図８の
MPD/Period/AdaptationSet/Representation/SegmentList/SegmentURL/@mediaRange=”795-83596”
は、そのファイルにおけるバイト範囲795バイト目から83596バイト目までが１つ目のSegment（セグメント化されたストリームデータ）であることを示している。
【００５５】
また、図８の
MPD/Period/AdaptationSet/Representation/SegmentList/SegmentURL/@mediaRange="83597-166046"
は、そのファイルにおけるバイト範囲83597バイト目から166046バイト目までが２つ目のSegmentであることを示している。
【００５６】
クライアントは、これらのSegmentを取得する際、ファイルのurlである
"http://example.com/counter-10mn_avc_dash.mp4"
を指定するとともに、HTTPリクエストのRangeヘッダに当該バイトレンジを指定するHTTPリクエストを発行する。すなわち、図９のＡに示されるように、クライアントは、最初のセグメントを取得するためのHTTPリクエストにおいて、ファイルurlとして
http://example.com/counter-10mn_avc_dash.mp4
を指定し、さらに、バイトレンジとして" 795-83596"を指定する。
【００５７】
また、図９のＢに示されるように、クライアントは、２つ目のセグメントを取得するためのHTTPリクエストにおいて、ファイルurlとして
http://example.com/server/counter-10mn_aacdash.mp4
を指定し、さらに、バイトレンジとして"83597-166046"を指定する。
【００５８】
これらセグメントのデータを放送チャネル上のIPマルチキャストストリーム上のFLUTEで転送されるファイルに格納させる場合、上述の表現形式を放送チャネル上のIPマルチキャストストリームをアドレッシングするように拡張しなければならない。
【００５９】
そのために、セグメントファイル群が転送されるIPマルチキャストストリームを取得するための新たな要素としてチューニングパラメタ（DeliverySystemAttributes）やIPマルチキャストアドレス（IPMulticastAddress）を格納するServiceLocation要素が導入される。つまり、この場合、図１０に示される例のように、このServiceLocation要素をルート要素として格納するserviceLocationファイルのurlを格納するserviceLocationAttribute Url属性がMPDのBaseURLに配置（記述）される。
【００６０】
なお、serviceLocationAttributeUrl属性により指定されるServiceLocationファイルのXML Schemaは、図１１に示される例のように記述される。
【００６１】
図１２は、このように拡張したMPDにおけるServiceLocation要素の構成例を示す図である。
【００６２】
図１２に示されるように、DeliverySystemAttributesTypeのDeliverySystemIdentifierには、MBMSのマルチキャスト配信若しくは放送配信用のストリーム（ブロードキャスト・マルチキャストストリーム）を識別するデータ構造のフォーマットを識別する識別子が格納される。例えば、動画や音楽などのマルチメディアコンテンツを既存ネットワーク、特にW-CDMAをベースとする3G携帯電話網、GSM（登録商標）/EDGEをベースとする2.5G携帯電話網で効率よく配信するための技術である”MBMS”を用いた配信の場合、DeliverySystemIdentifierには、MBMSを示す識別子”ID_MBMS”が格納（記述）される。
【００６３】
また、DeliverySystemAttributesTypeのDeliverySystemDescriptorには、上述したDeliverySystemIdentifierで識別される配信システム毎に規定されたブロードキャスト・マルチキャストストリームを取得するためのパラメタのデータ構造若しくはパラメタそのものが格納（記述）される。
【００６４】
DeliverySystemIdentifierに”ID_MBMS”が格納（記述）される場合、例えば、図１３に示されるような、MBMSにおいて規定される”User Service Description”構造が格納（記述）される。
【００６５】
［FDTの拡張］
次に、FDTの拡張について説明する。上述したServiceLocation/DeliverySystem要素に格納される情報によりMBMSマルチキャストストリーム上に転送されるIPパケットストリームのうち、ServiceLocation/IPMulticastAddress要素で指定されるマルチキャストアドレスを持つIPパケットストリーム上には、FLUTEプロトコルによりファイル群が運ばれるものとする。
【００６６】
図１４はFLUTEプロトコルの階層を示している。FLUTEは、IPパケットストリーム上にファイルを転送するプロトコルであり、図１４に示される例のようなプロトコル階層を有する。なお図１４においては、上述したDeliverySystemAttributesで指定されるMBMSベアラ上にFLUTEのパケットが運ばれる場合を示している。
【００６７】
FLUTEプロトコルでは、FLUTEパケットにより運ばれるファイルのそれぞれに対してファイル属性が記述できるようになっている。ファイル属性はFDT（File Delivery Table）（FDT-Instance要素）に記述される。
【００６８】
図１５は、FDTのデータ構造の例を示している。FDTに必須のファイル属性は以下の３種である。
【００６９】
FDT-Instance/Expires（FDTの有効期限）
FDT-Instance/File/Content-Location（転送するファイルのURL）
FDT-Instance/File/TOI（Transport Object Identifier、FLUTE転送する上で必須の構成チャンク群の識別子）
【００７０】
FLUTEプロトコルでは、同一のTOIを有する全てのファイルが受信された段階で初めて、Content-LocationのURLにより指定されるファイルとしてそれらに対してアクセスが可能となる。したがって、映画などのVoDコンテンツのように再生時間が長く１つのファイルのサイズが非常に大きい場合には、そのファイル全体が受信側で再構成されてアクセスできるようになるまでに、ある程度の時間が必要となる。
【００７１】
これに対して、DASHを利用したストリーミングにおいては、対象のVoDコンテンツのファイルのサイズが大きくても、個々のHTTPリクエストのmediaRange指定によりファイルの一部をセグメント単位で取得し、再生することができる。したがって、放送チャネル上のFLUTE転送されるファイルの単位もこのセグメントの単位で取得し、再生できるようにすることが望ましい。
【００７２】
ただし、現在規定されているFDTのContent-Location要素のみでは、MPDのBaseURL＋SegmentURL mediaRangeのシーケンスのように、ファイルの一部を表現することができない。DASHのMPDのSegmentが、FLUTEで転送されるファイルの一部（ファイルurl+バイトレンジで指定されるバイト列）である場合には、そのバイト列をファイルとして独立させ、そのファイルにURLを割り当て、そのurlと対応するSegmentを対応させる方法も考えられるが、これは、放送配信のために、ネット配信のMPDファイルの構成を変更することとなり、ネット配信目的で生成されたMPDを、放送配信を併用することになった時点で、セグメントファイルの構成変更や、対応するMPDの書き換えが生じるため現実的でない（運用上余計なオーバヘッドが生じる）。そこで、FDTについてもファイルの一部を表現できるように拡張する。
【００７３】
図１６は、拡張したFDTのデータ構造を示している。すなわち、FDTに対して、Content-Locationと、さらにそのContent-Locationのurlで指定されるファイルの中のバイトレンジが指定できるように新たにrange属性を導入する。range属性のシンタクスには、range-specifier(RFC2616.section.14.35.1)の定義を適用する。range属性には、以下のようにHTTPリクエストのrangeヘッダに格納されるrange-specifierにより表現されるものをそのまま格納できるようにする。つまりrange属性には、MPDのPeriod/AdaptationSet/Representation/SegmentList/SegmentURL/@mediaRangeをそのまま流用することができる。
【００７４】
＜適応的な制御＞
ただし、仮に、上述したようにMPDを拡張することにより、マルチキャストやブロードキャストベアラを利用するとしても、マルチキャスト配信やブロードキャスト配信が常に最善という訳ではない。例えば、コンテンツを要求するクライアントが少ない場合や、使用可能なマルチキャスト配信やブロードキャスト配信のリソースが少ない場合等においては、十分なコストメリットを得ることができず、ネットワークリソースの負荷を十分に低減することができないことも考えられた。
【００７５】
そこで、コンテンツの配信をより効率よく行うために、ユニキャスト配信とマルチキャスト配信やブロードキャスト配信とを併用し、各配信の利用をより適応的に制御するようにする。
【００７６】
例えば、DASHアダプティブストリーミングフォーマットのマニフェストファイル（MPD）を収集するMPDコンフィギュレータを用意し、DASHクライアントからの要求量（要求数）に応じて放送チャンネルを割り当て（解放して）、MPDを書き換える（更新する）ようにする。
【００７７】
このようにすることにより、放送配信リソース割り当てを最適に保ちながら、アダプティブストリーミングにおけるストリームスイッチ可能な代替配信パスとしてMBMS等のモバイル放送チャンネルを利用することができる。
【００７８】
＜１．第１の実施の形態＞
＜コンテンツ配信システム＞
図１７は、本技術を適用したコンテンツ供給システムの一実施の形態であるコンテンツ配信システムの主な構成例を示すブロック図である。
【００７９】
図１７に示されるコンテンツ配信システム１００は、サーバからクライアントにコンテンツを供給するシステムである。図１７に示されるように、コンテンツ配信システム１００は、コンテンツ提供システム１１１、配信制御システム１１２、ネットワーク１１３、並びに、DASHクライアント１１４−１およびDASHクライアント１１４−２を有する。コンテンツ配信システム１００は、コンテンツ提供システム１１１からDASHクライアント１１４−１やDASHクライアント１１４−２へコンテンツを伝送するシステムである。
【００８０】
コンテンツ提供システム１１１は、主にコンテンツの提供に関する処理を行うシステムである。コンテンツ提供システム１１１は、DASHクライアント１１４−１やDASHクライアント１１４−２からの要求に応じて、自身が管理するコンテンツを、ネットワーク１１３を介して、要求元であるDASHクライアント１１４−１若しくはDASHクライアント１１４−２に供給する。
【００８１】
配信制御システム１１２は、そのコンテンツの配信方法に関する制御処理を行うシステムである。
【００８２】
ネットワーク１１３は、例えばインターネットやLAN等の、有線若しくは無線、または両方の任意のネットワークよりなる。図１７においては、ネットワーク１１３が１つのネットワークとして示されているが、ネットワーク１１３の構成は任意であり、複数のネットワークにより構成されるようにしてもよい。また、ネットワーク１１３には、どのような機器やシステムが接続されるようにしてもよい。図１７の例の場合、ネットワーク１１３には、コンテンツ提供システム１１１、配信制御システム１１２、並びに、DASHクライアント１１４−１およびDASHクライアント１１４−２が接続される。
【００８３】
DASHクライアント１１４−１やDASHクライアント１１４−２は、それぞれ、ネットワーク１１３に接続され、コンテンツの取得に関する処理を行う。なお、DASHクライアント１１４−１とDASHクライアント１１４−２とを互いに区別して説明する必要がない場合、単にDASHクライアント１１４と称する。図１７においては、２つのDASHクライアント１１４が示されているが、DASHクライアント１１４の数は任意である。
【００８４】
DASHクライアント１１４は、ネットワーク１１３を介して通信を行う通信機能を備え、コンテンツ提供システム１１１から供給される動画像や音声などよりなるコンテンツのストリーミングデータを再生可能な装置であれば、どのようなデバイスであってもよい。例えば、携帯電話機、ノート型のパーソナルコンピュータ、スマートフォン、タブレット型情報処理装置等といった携帯型の端末装置（モバイル機器）であってもよい。DASHクライアント１１４−１とDASHクライアント１１４−２とが互いに異なる種類のデバイスであってももちろんよい。
【００８５】
また、DASHクライアント１１４は、ネットワーク１１３に、有線通信により接続されてもよいし、無線通信により接続されてもよい。
【００８６】
図１７に示されるように、コンテンツ提供システム１１１は、例えば、コンテンツマネジメントサーバ１２１、DASHセグメントストリーマ１２２、DASH-MPDサーバ１２３、BC/MCサービスプロバイダ１２４を有する。
【００８７】
コンテンツマネジメントサーバ１２１は、コンテンツ（例えば、ライブ放送ストリームを含む）の生成・管理を行うサーバである。
【００８８】
DASHセグメントストリーマ１２２は、コンテンツマネジメントサーバ１２１にて管理されるコンテンツからDASHセグメントを生成するサーバである。個々のセグメントは、ファイルとして独立して生成される場合もあれば、ファイルとしては分割されずにファイルURL+rangeで指定される領域として管理される場合もある。ネット配信の場合、DASHセグメントストリーマ１２２は、セグメントを配信するHTTPサーバとなる。
【００８９】
DASH-MPDサーバ１２３は、DASHセグメントストリーマ１２２にて管理されるDASHセグメントのurl(+range)とコンテンツマネジメントサーバ１２１にて管理されるコンテンツのメタデータをもとにMPDを生成するサーバである。ネット配信の場合、DASH-MPDサーバ１２３は、MPDを配信するHTTPサーバとなる。放送配信もしくはマルチキャスト配信の場合、DASH-MPDサーバ１２３は、MPDを後述するFLUTEサーバ１３１に送付する。
【００９０】
BC/MCサービスプロバイダ１２４は、後述するDASHクライアントプロキシ１４３から放送配信依頼されたMPDやセグメントを放送配信リソース１５２（例えばMBMSベアラ等）により放送配信するサーバである。図１７に示されるように、BC/MCサービスプロバイダ１２４は、例えば、FLUTEサーバ１３１および放送配信サーバ１３２を有する。
【００９１】
FLUTEサーバ１３１は、DASHセグメントストリーマ１２２にて管理されるDASHセグメントをFLUTEプロトコルにてDASHクライアント１１４にマルチキャストするサーバである。FLUTEサーバ１３１は、拡張されたFDTの生成や、セグメントからFLUTEパケット（ALCパケット等）の生成等を行う。ネット配信の場合、FLUTEサーバ１３１は、生成したFDTやFLUTEパケットをDASHクライアント１１４にマルチキャスト配信するマルチキャストサーバとなる。放送配信の場合、FLUTEサーバ１３１は、生成したFDTやFLUTEパケットを放送配信サーバ１３２に送付する。
【００９２】
放送配信サーバ１３２は、FLUTEサーバ１３１にて生成されるFDTやALCパケット等を放送配信するサーバである。
【００９３】
図１７に示されるように、配信制御システム１１２は、例えば、MPDコンフィギュレータ１４１、BC/MCリソースマネージャ１４２、およびDASHクライアントプロキシ１４３を有する。
【００９４】
MPDコンフィギュレータ１４１は、コンテンツの供給にマルチキャスト配信若しくは放送配信を利用するか否かを判定し、マルチキャスト配信若しくは放送配信を利用すると判定された場合、コンテンツの供給にそのマルチキャスト配信若しくは放送配信を利用するように、そのコンテンツのユニキャスト配信に関する制御情報を更新する。
【００９５】
より具体的には、MPDコンフィギュレータ１４１は、DASHクライアント１１４から送付された、その制御情報の一例であるMPDをもとに、BC/MCリソースマネージャ１４２に対してマルチキャストリソースを予約・解放し、コンテンツの一例である当該セグメントストリームをマルチキャストチャネルから取得できるように、＜０．概要＞において上述したようにMPDを書き換えてクライアントに送付する。リソースの予約・解放判断は、BC/MCリソース併用のコスト効果計算をもとに行う。
【００９６】
BC/MCリソースマネージャ１４２は、MPDコンフィギュレータ１４１からの依頼を基に、マルチキャストリソースを予約・解放するサーバである。MPDコンフィギュレータ１４１に対してブロードキャスト/マルチキャストリソースの空き状況を報告し、リソース予約・解放要求に応じる。
【００９７】
DASHクライアントプロキシ１４３は、DASHセグメントストリーマ１２２に対して、DASHクライアント１１４としてふるまうプロキシサーバである。MPDコンフィギュレータ１４１により書き換えられたMPDをモニタして、DASHクライアント１１４の代わりにセグメントを取得し、マルチキャスト配信若しくは放送配信（BC/MC）のためのプロトコル変換（HTTP取得からFLUTEマルチキャスト配信への変換）を行い、BC/MCサービスプロバイダ１２４に対してマルチキャスト配信若しくは放送配信を依頼するサーバである。
【００９８】
図１７に示されるように、ネットワーク１１３は、例えば、CDN１５１および放送配信リソース１５２を有する。放送配信リソース１５２は、例えば、MBMSベアラ等よりなる。図１７においては、ネットワーク１１３にCDN１５１と放送配信リソース１５２を１つずつ示しているが、ネットワーク１１３に含まれるCDN１５１や放送配信リソース１５２の数は任意であり、複数であってもよい。
【００９９】
コンテンツ提供システム１１１が上述した以外のサーバ等を有していてももちろんよい。また、図１７においては、コンテンツ提供システム１１１がネットワーク１１３に接続されているように示されているが、実際には、上述した、コンテンツ提供システム１１１を構成する各サーバ（コンテンツマネジメントサーバ１２１乃至BC/MCサービスプロバイダ１２４（FLUTEサーバ１３１および放送配信サーバ１３２）等）が、直接的または間接的にネットワーク１１３に接続される。
【０１００】
もちろん、コンテンツ提供システム１１１の構成は任意であり、ネットワーク１１３を介してDASHクライアント１１４に対してコンテンツを配信することができるのであれば、上述した各サーバやその他の機器がどのように互いに接続され、どのようにネットワーク１１３に接続されるようにしてもよい。また、図１７においては、１つずつ示されているが、コンテンツマネジメントサーバ１２１乃至BC/MCサービスプロバイダ１２４（FLUTEサーバ１３１および放送配信サーバ１３２）の数は任意であり、複数であってもよい。
【０１０１】
配信制御システム１１２が上述した以外のサーバ等を有していてももちろんよい。また、図１７においては、配信制御システム１１２がネットワーク１１３に接続されているように示されているが、実際には、上述した、配信制御システム１１２を構成する各サーバ（MPDコンフィギュレータ１４１乃至DASHクライアントプロキシ１４３等）が、直接的または間接的にネットワーク１１３に接続される。
【０１０２】
もちろん、配信制御システム１１２の構成は任意であり、ネットワーク１１３を介したコンテンツ配信を制御することができるのであれば、上述した各サーバやその他の機器がどのように互いに接続され、どのようにネットワーク１１３に接続されるようにしてもよい。また、図１７においては、１つずつ示されているが、MPDコンフィギュレータ１４１乃至DASHクライアントプロキシ１４３の数は任意であり、複数であってもよい。
【０１０３】
さらに、例えば、MPDコンフィギュレータ１４１乃至DASHクライアントプロキシ１４３（若しくはそれらの一部）が、コンテンツ配信側に形成される（すなわち、コンテンツ提供システム１１１を構成する）ようにしてもよい。
【０１０４】
また、例えば、ネットワーク１１３が複数のネットワークよりなり、MPDコンフィギュレータ１４１乃至DASHクライアントプロキシ１４３（若しくはそれらの一部）が、それらのネットワーク間の中継装置として形成されるようにしてもよい。
【０１０５】
さらに、例えば、MPDコンフィギュレータ１４１乃至DASHクライアントプロキシ１４３（若しくはそれらの一部）が、ネットワーク１１３を介して行われるコンテンツ配信の所定の一部のみを制御するようにしてもよい。例えば、MPDコンフィギュレータ１４１乃至DASHクライアントプロキシ１４３（若しくはそれらの一部）が、時間的または位置的（領域的）にネットワーク１１３の一部において行われるコンテンツ配信を担当するようにしてもよい。
【０１０６】
例えば、DASHクライアント１１４が携帯電話機やスマートフォンのような、公衆無線通信回線の基地局を介してインターネット等に接続するデバイスであり、MPDコンフィギュレータ１４１乃至DASHクライアントプロキシ１４３（若しくはそれらの一部）が、その基地局に形成されるようにし、その基地局を介して行われるコンテンツ配信のみを制御するようにしてもよい。
【０１０７】
この場合、MPDコンフィギュレータ１４１は、その基地局に接続されるDASHクライアント１１４からのコンテンツ配信要求の量に応じて、マルチキャスト配信若しくは放送配信のリソースの割り当てを適応的に制御して、MPDを更新する。
【０１０８】
また、例えば、DASHクライアント１１４が、家庭内や店舗等に設置された無線LANのアクセスポイント（またはフェムトセルの基地局等）を介してインターネット等に接続するデバイスであり、MPDコンフィギュレータ１４１乃至DASHクライアントプロキシ１４３（若しくはそれらの一部）が、そのアクセスポイントに形成されるようにし、そのアクセスポイントを介して行われるコンテンツ配信のみを制御するようにしてもよい。
【０１０９】
この場合、MPDコンフィギュレータ１４１は、そのアクセスポイントに接続されるDASHクライアント１１４（つまり、その無線LANに接続されるDASHクライアント１１４）からのコンテンツ配信要求の量に応じて、マルチキャスト配信若しくは放送配信のリソースの割り当てを適応的に制御して、MPDを更新する。
【０１１０】
さらに、例えば、MPDコンフィギュレータ１４１は、予め登録された所定のDASHクライアント１１４に対するコンテンツ配信のみを制御するようにしてもよい。つまり、この場合、MPDコンフィギュレータ１４１は、予め登録された所定のDASHクライアント１１４からのコンテンツ配信要求の量に応じて、マルチキャスト配信若しくは放送配信のリソースの割り当てを適応的に制御して、MPDを更新する。
【０１１１】
また、例えば、MPDコンフィギュレータ１４１乃至DASHクライアントプロキシ１４３（若しくはそれらの一部）が、DASHクライアント１１４内に形成されるようにし、そのDASHクライアント１１４において実行される各アプリケーションのコンテンツ配信要求の量に応じて、マルチキャスト配信若しくは放送配信のリソースの割り当てを適応的に制御して、MPDを更新するようにしてもよい。
【０１１２】
このようにすることにより、MPDコンフィギュレータ１４１は、ネットワーク１１３全体でなく、その時間的、位置的（領域的）、若しくはクライアント的に一部におけるコンテンツ配信要求量に応じて、マルチキャスト配信若しくは放送配信のリソースの割り当てを適応的に制御することができる。すなわち、局所的に要求量の変動にもより適切に対応することができる。つまり、コンテンツ配信をより効率よく行うようにすることができる。
【０１１３】
＜物理的構成＞
次に、コンテンツ配信システム１００を構成する各デバイスの構成例について説明する。図１８は、MPDコンフィギュレータ１４１の物理的な構成例を示すブロック図である。
【０１１４】
図１８に示されるように、MPDコンフィギュレータ１４１は、CPU（Central Processing Unit）２０１、ROM（Read Only Memory）２０２、およびRAM（Random Access Memory）２０３を有する。これらのCPU２０１、ROM２０２、およびRAM２０３は、バス２０４を介して相互に接続されている。
【０１１５】
バス２０４にはまた、入出力インタフェース２１０も接続されている。入出力インタフェース２１０には、入力部２１１、出力部２１２、記憶部２１３、通信部２１４、およびドライブ２１５が接続されている。
【０１１６】
入力部２１１は、例えば、キーボード、マウス、マイクロホン、タッチパネル、入力端子などよりなる。出力部２１２は、例えば、ディスプレイ、スピーカ、出力端子などよりなる。記憶部２１３は、例えば、ハードディスク、RAMディスク、不揮発性のメモリなどよりなる。通信部２１４は、例えば、ネットワークインタフェースよりなる。ドライブ２１５は、磁気ディスク、光ディスク、光磁気ディスク、または半導体メモリなどのリムーバブルメディア２２１を駆動する。
【０１１７】
もちろん、MPDコンフィギュレータ１４１の構成は任意であり、図１８の例に限らない。例えば、MPDコンフィギュレータ１４１が、図１８に示される構成以外の構成を有するようにしてもよい。
【０１１８】
なお、コンテンツマネジメントサーバ１２１、DASHセグメントストリーマ１２２、DASH-MPDサーバ１２３、BC/MCサービスプロバイダ１２４（FLUTEサーバ１３１および放送配信サーバ１３２）、BC/MCリソースマネージャ１４２、DASHクライアントプロキシ１４３、並びに、DASHクライアント１１４も、それぞれ、MPDコンフィギュレータ１４１と同様の構成を有するものとする。すなわち、以下において、これらのデバイスの物理的な構成について説明する場合、図１８を参照して説明する。もちろん、これらのデバイスの構成も、MPDコンフィギュレータ１４１の場合と同様に任意であり、図１８の例に限らない。MPDコンフィギュレータ１４１を含むこれらのデバイス（または一部のデバイス）が他のデバイスと異なる構成を有するようにしてもよい。
【０１１９】
＜機能的構成＞
次に、コンテンツ配信システム１００を構成する各デバイスの機能の例について、図１９乃至図２６を参照して説明する。図１９乃至図２６は、各デバイスが有する機能を説明するための機能ブロック図である。図１９乃至図２６に示される各機能ブロックは、各デバイスのCPU２０１がROM２０２や記憶部２１３から読み出したプログラム等を、適宜RAM２０３等を用いて実行することにより実現される機能を表すものである。
【０１２０】
図１９は、DASHセグメントストリーマ１２２が有する主な機能ブロックの構成例を示す図である。図１９に示されるように、DASHセグメントストリーマ１２２は、例えば、DASHセグメント生成部３０１、DASHセグメント管理部３０２、およびDASHセグメント供給部３０３を有する。
【０１２１】
DASHセグメント生成部３０１は、DASHセグメントストリーマ１２２の通信部２１４を介して、コンテンツマネジメントサーバ１２１にて管理されるコンテンツデータを取得し、その取得したコンテンツデータからDASHセグメントを生成する。
【０１２２】
DASHセグメント管理部３０２は、DASHセグメント生成部３０１により生成されたDASHセグメントを、DASHセグメントストリーマ１２２の記憶部２１３に記憶し、管理する。
【０１２３】
DASHセグメント供給部３０３は、DASHセグメントストリーマ１２２の通信部２１４を介して外部（例えば、DASHクライアント１１４、DASHクライアントプロキシ１４３等）から要求された、DASHセグメントストリーマ１２２の記憶部２１３に記憶され、DASHセグメント管理部３０２により管理されているDASHセグメントを読み出し、その読み出したDASHセグメントを、DASHセグメントストリーマ１２２の通信部２１４を介して要求元に供給する。
【０１２４】
もちろん、DASHセグメントストリーマ１２２は、任意の機能ブロックを有することができる。例えば、図１９に示される例以外の機能ブロックを有することもできる。
【０１２５】
図２０は、FLUTEサーバ１３１が有する主な機能ブロックの構成例を示す図である。図２０に示されるように、FLUTEサーバ１３１は、例えば、プロトコル変換部３１１、MPDマルチキャスト配信部３１２、セグメントマルチキャスト配信部３１３、および放送配信依頼部３１４を有する。
【０１２６】
プロトコル変換部３１１は、FLUTEサーバ１３１の通信部２１４を介して外部（例えば、DASHクライアントプロキシ１４３等）から供給されたデータのプロトコルをマルチキャスト配信若しくは放送配信用のプロトコルに変換する。より具体的には、プロトコル変換部３１１は、供給されるDASHプロトコルのデータをFLUTEプロトコルのデータに変換する。例えば、プロトコル変換部３１１は、MPDやDASHセグメントからFDTやFLUTEパケットを生成する。
【０１２７】
図２０に示されるように、プロトコル変換部３１１は、例えばFDT生成部３２１およびFLUTEストリーム生成部３２２を有する。
【０１２８】
FDT生成部３２１は、＜０．概要＞において上述したように、拡張されたFDTを生成する。
【０１２９】
FLUTEストリーム生成部３２２は、＜０．概要＞において上述したようにFLUTEパケットを生成する。
【０１３０】
MPDマルチキャスト配信部３１２は、FLUTEサーバ１３１の通信部２１４を介して、MPDをマルチキャスト配信する。つまり、MPDマルチキャスト配信部３１２は、MPDのマルチキャスト配信を行う。その際MPDマルチキャスト配信部３１２は、BC/MCリソースマネージャ１４２により確保された放送配信リソース１５２（マルチキャスト配信用のリソース）を用いて、外部（例えば、DASHクライアント１１４等）に対してMPDのマルチキャスト配信を行う。
【０１３１】
セグメントマルチキャスト配信部３１３は、FLUTEサーバ１３１の通信部２１４を介して、DASHセグメントをマルチキャスト配信する。つまり、セグメントマルチキャスト配信部３１３は、プロトコル変換部３１１により生成されたFDTやFLUTEパケットをマルチキャスト配信する。その際セグメントマルチキャスト配信部３１３は、BC/MCリソースマネージャ１４２により確保された放送配信リソース１５２（マルチキャスト配信用のリソース）を用いて外部（例えば、DASHクライアント１１４等）にマルチキャスト配信を行う。
【０１３２】
放送配信依頼部３１４は、FDTやFLUTEパケットを放送配信する場合、FLUTEサーバ１３１の通信部２１４を介して、放送配信サーバ１３２に対して放送配信依頼を行う。その際、放送配信依頼部３１４は、放送配信するFDTやFLUTEパケットを放送配信サーバ１３２に供給する。
【０１３３】
もちろん、FLUTEサーバ１３１は、任意の機能ブロックを有することができる。例えば、図２０に示される例以外の機能ブロックを有することもできる。
【０１３４】
図２１は、放送配信サーバ１３２が有する主な機能ブロックの構成例を示す図である。図２１に示されるように、放送配信サーバ１３２は、例えば、放送配信部３３１を有する。
【０１３５】
放送配信部３３１は、外部（例えば、FLUTEサーバ１３１等）より供給された放送配信依頼を放送配信サーバ１３２の通信部２１４を介して取得し、その放送配信依頼にしたがって、同様に供給されたFDTやFLUTEパケットを、放送配信サーバ１３２の通信部２１４を介して外部（例えば、DASHクライアント１１４等）に放送配信する。その際放送配信部３３１は、BC/MCリソースマネージャ１４２により確保された放送配信リソース１５２（放送配信用のリソース）を用いて放送配信を行う。
【０１３６】
もちろん、放送配信サーバ１３２は、任意の機能ブロックを有することができる。例えば、図２１に示される例以外の機能ブロックを有することもできる。
【０１３７】
図２２は、DASH-MPDサーバ１２３が有する主な機能ブロックの構成例を示す図である。図２２に示されるように、DASH-MPDサーバ１２３は、例えば、MPD生成部３４１、MPD管理部３４２、およびMPD供給部３４３を有する。
【０１３８】
MPD生成部３４１は、DASH-MPDサーバ１２３の通信部２１４を介して、DASHセグメントストリーマ１２２において管理されるDASHセグメントのurl（+range）とコンテンツマネジメントサーバ１２１において管理されるコンテンツのメタデータを取得し、それらの情報をもとにMPDを生成する。
【０１３９】
MPD管理部３４２は、MPD生成部３４１により生成されたMPDを、DASH-MPDサーバ１２３の記憶部２１３に記憶し、管理する。
【０１４０】
MPD供給部３４３は、DASH-MPDサーバ１２３の通信部２１４を介して外部（例えば、DASHクライアント１１４、DASHクライアントプロキシ１４３等）から要求された、DASH-MPDサーバ１２３の記憶部２１３に記憶され、MPD管理部３４２により管理されているMPDを読み出し、その読み出したMPDを、DASH-MPDサーバ１２３の通信部２１４を介して要求元に供給する。
【０１４１】
もちろん、DASH-MPDサーバ１２３は、任意の機能ブロックを有することができる。例えば、図２２に示される例以外の機能ブロックを有することもできる。
【０１４２】
図２３は、DASHクライアント１１４が有する主な機能ブロックの構成例を示す図である。図２３に示されるように、DASHクライアント１１４は、例えば、MPD要求部３５１、MPD取得部３５２、判定部３５３、MPD供給部３５４、セグメント要求部３５５、セグメント取得部３５６、およびセグメント再生部３５７を有する。
【０１４３】
MPD要求部３５１は、DASHクライアント１１４の通信部２１４を介して、外部（例えばDASH-MPDサーバ１２３等）に対してMPDの取得を要求する。
【０１４４】
MPD取得部３５２は、DASHクライアント１１４の通信部２１４を介して、MPD要求部３５１がした要求に対して外部（例えば、DASH-MPDサーバ１２３、BC/MCサービスプロバイダ１２４、DASHクライアントプロキシ１４３等）から供給されるMPDを取得する。
【０１４５】
判定部３５３は、MPD取得部３５２により取得された、DASHクライアント１１４の通信部２１４を介して外部（例えば、DASH-MPDサーバ１２３等）から供給されたMPDに基づいて、受信方法（ユニキャスト配信されるデータを受信する（ユニキャスト受信する）方がよいか、マルチキャスト配信若しくは放送配信されるデータを受信する（マルチキャスト受信する）方がよいか）を判定する。つまり、判定部３５３は、各配信用のリソースの利用可能帯域等を確認することにより、MPDを、DASHクライアント１１４の通信部２１４を介して外部（例えば、MPDコンフィギュレータ１４１等）に供給するか否かを判定する。コンテンツをユニキャスト受信する方がよい場合、MPDを更新する必要がないので、判定部３５３は、MPDを供給しないと判定する。逆に、コンテンツをマルチキャスト受信する方が望ましい場合、MPDを更新する必要があるので、判定部３５３は、MPDを供給すると判定する。
【０１４６】
MPD供給部３５４は、判定部３５３によりMPDを供給すると判定された場合、MPD取得部３５２により取得されたMPDを、DASHクライアント１１４の通信部２１４を介して外部（例えば、MPDコンフィギュレータ１４１等）に供給する。
【０１４７】
セグメント要求部３５５は、MPD取得部３５２により取得された、DASHクライアント１１４の通信部２１４を介して外部（例えば、BC/MCサービスプロバイダ１２４、DASHクライアントプロキシ１４３等）から供給されたMPDに基づいて、ユニキャスト受信する場合、DASHクライアント１１４の通信部２１４を介して、外部（例えば、DASHセグメントストリーマ１２２等）に対してDASHセグメントの取得を要求する。
【０１４８】
セグメント取得部３５６は、DASHクライアント１１４の通信部２１４を介して、セグメント要求部３５５がした要求に対して外部（例えば、DASHセグメントストリーマ１２２等）から供給されるDASHセグメントを取得する。また、セグメント取得部３５６は、DASHクライアント１１４の通信部２１４を介して、外部（例えば、BC/MCサービスプロバイダ１２４、DASHクライアントプロキシ１４３等）から供給されるFLUTEパケット等を取得する。
【０１４９】
セグメント再生部３５７は、セグメント取得部３５６により取得されたコンテンツデータ（例えば、DASHセグメント、FLUTEパケット等）を再生し、例えば、画像や音声をDASHクライアント１１４の出力部２１２から出力する。
【０１５０】
もちろん、DASHクライアント１１４は、任意の機能ブロックを有することができる。例えば、図２３に示される例以外の機能ブロックを有することもできる。
【０１５１】
図２４は、MPDコンフィギュレータ１４１が有する主な機能ブロックの構成例を示す図である。図２４に示されるように、MPDコンフィギュレータ１４１は、例えば、MPD取得部３６１、リソース情報要求部３６２、リソース情報取得部３６３、コスト評価部３６４、リソース確保要求部３６５、リソース確保結果通知取得部３６６、MPD更新部３６７、およびMPD供給部３６８を有する。
【０１５２】
MPD取得部３６１は、MPDコンフィギュレータ１４１の通信部２１４を介して、外部（例えば、DASHクライアント１１４等）から供給されるMPDを取得する。
【０１５３】
リソース情報要求部３６２は、リソースの利用状況を確認するために、MPDコンフィギュレータ１４１の通信部２１４を介して、外部（例えば、BC/MCリソースマネージャ１４２等）に対して、放送配信リソース１５２（マルチキャスト配信や放送配信用のリソース）の利用状況を示す情報であるリソース情報を要求する。
【０１５４】
リソース情報取得部３６３は、MPDコンフィギュレータ１４１の通信部２１４を介して、リソース情報要求部３６２がした要求に対して外部（例えば、BC/MCリソースマネージャ１４２等）から供給されるリソース情報を取得する。
【０１５５】
コスト評価部３６４は、MPD取得部３６１が取得したMPDやリソース情報取得部３６３が取得したリソース情報に基づいて、コンテンツの配信に、マルチキャスト配信や放送配信を利用する場合のコスト（BC/MC併用コストとも称する）を評価する。この場合のコストとは、任意の条件についての評価値を示し、コンテンツ配信の効率の度合いを示す任意のパラメタである。
【０１５６】
リソース確保要求部３６５は、コスト評価部３６４によりマルチキャスト配信や放送配信を利用すると判定された場合に、リソース情報に基づいて、利用可能な放送配信リソース１５２（マルチキャスト配信や放送配信用のリソース）の確保を、MPDコンフィギュレータ１４１の通信部２１４を介して外部（例えば、BC/MCリソースマネージャ１４２等）に要求する。
【０１５７】
リソース確保結果通知取得部３６６は、MPDコンフィギュレータ１４１の通信部２１４を介して、リソース確保要求部３６５がした要求に対して外部（例えば、BC/MCリソースマネージャ１４２等）から供給される、放送配信リソース１５２（マルチキャスト配信や放送配信用のリソース）の確保結果の通知を取得する。
【０１５８】
MPD更新部３６７は、コスト評価部３６４によりマルチキャスト配信や放送配信を利用すると判定された場合に、MPDを、コンテンツの供給にその放送配信リソース１５２（マルチキャスト配信や放送配信用のリソース）を利用するように、＜０．概要＞において上述したように更新する。
【０１５９】
MPD供給部３６８は、MPD更新部３６７により更新されたMPD、若しくは、MPD更新部３６７により更新されなかったMPDを、MPDコンフィギュレータ１４１の通信部２１４を介して、外部（例えば、DASHクライアントプロキシ１４３、BC/MCサービスプロバイダ１２４、DASHクライアント１１４等）に供給する。
【０１６０】
もちろん、MPDコンフィギュレータ１４１は、任意の機能ブロックを有することができる。例えば、図２４に示される例以外の機能ブロックを有することもできる。
【０１６１】
図２５は、BC/MCリソースマネージャ１４２が有する主な機能ブロックの構成例を示す図である。図２５に示されるように、BC/MCリソースマネージャ１４２は、例えば、リソース情報要求取得部３７１、リソース情報生成部３７２、リソース情報供給部３７３、リソース確保要求取得部３７４、リソース確保部３７５、およびリソース確保結果通知部３７６を有する。
【０１６２】
リソース情報要求取得部３７１は、BC/MCリソースマネージャ１４２の通信部２１４を介して、外部（例えば、MPDコンフィギュレータ１４１等）から供給されるリソース情報の要求を取得する。
【０１６３】
リソース情報生成部３７２は、リソース情報要求取得部３７１により取得されたリソース情報の要求に応じて、BC/MCリソースマネージャ１４２の通信部２１４を介して放送配信リソース１５２（マルチキャスト配信や放送配信用のリソース）の利用状況を調査し、リソース情報を生成する。
【０１６４】
リソース情報供給部３７３は、リソース情報生成部３７２により生成されたリソース情報を、BC/MCリソースマネージャ１４２の通信部２１４を介して、要求元である外部（例えば、MPDコンフィギュレータ１４１等）に供給する。
【０１６５】
リソース確保要求取得部３７４は、BC/MCリソースマネージャ１４２の通信部２１４を介して、外部（例えば、MPDコンフィギュレータ１４１等）から供給される放送配信リソースの確保の要求を取得する。
【０１６６】
リソース確保部３７５は、リソース確保要求取得部３７４により取得された放送配信リソースの確保の要求に応じて、要求された放送配信リソース１５２（マルチキャスト配信や放送配信用のリソース）を確保する。
【０１６７】
リソース確保結果通知部３７６は、リソース確保部３７５による放送配信リソース１５２（マルチキャスト配信や放送配信用のリソース）の確保結果を、BC/MCリソースマネージャ１４２の通信部２１４を介して、要求元である外部（例えば、MPDコンフィギュレータ１４１等）に供給する。
【０１６８】
もちろん、BC/MCリソースマネージャ１４２は、任意の機能ブロックを有することができる。例えば、図２５に示される例以外の機能ブロックを有することもできる。
【０１６９】
図２６は、DASHクライアントプロキシ１４３が有する主な機能ブロックの構成例を示す図である。図２６に示されるように、DASHクライアントプロキシ１４３は、例えば、MPD取得部３８１、MPD供給部３８２、セグメント要求部３８３、セグメント取得部３８４、およびFLUTE配信依頼部３８５を有する。
【０１７０】
MPD取得部３８１は、DASHクライアントプロキシ１４３の通信部２１４を介して、外部（例えば、MPDコンフィギュレータ１４１等）から供給されるMPDを取得する。
【０１７１】
MPD供給部３８２は、MPD取得部３８１が取得したMPDを、DASHクライアントプロキシ１４３の通信部２１４を介して、外部（例えば、DASHクライアント１１４、BC/MCサービスプロバイダ１２４等）に供給する。
【０１７２】
セグメント要求部３８３は、MPD取得部３８１が取得したMPDに基づいて、コンテンツの配信にマルチキャスト配信若しくは放送配信を利用する場合、DASHクライアントプロキシ１４３の通信部２１４を介して、DASHクライアント１１４の代わりに、外部（例えば、DASHセグメントストリーマ１２２等）に、DASHセグメントを要求する。
【０１７３】
セグメント取得部３８４は、DASHクライアントプロキシ１４３の通信部２１４を介して、セグメント要求部３８３の要求に応じて外部（例えば、DASHセグメントストリーマ１２２等）から供給されたDASHセグメントを取得する。
【０１７４】
FLUTE配信依頼部３８５は、セグメント取得部３８４により取得されたDASHセグメントを、DASHクライアントプロキシ１４３の通信部２１４を介して、外部（例えば、BC/MCサービスプロバイダ１２４等）に供給し、そのDASHセグメントをFLUTE配信（マルチキャスト配信若しくは放送配信）するように依頼する。
【０１７５】
もちろん、DASHクライアントプロキシ１４３は、任意の機能ブロックを有することができる。例えば、図２６に示される例以外の機能ブロックを有することもできる。
【０１７６】
＜配信制御処理の流れ＞
以上のような機能を有するMPDコンフィギュレータ１４１（図２４）は、配信制御処理を実行して、＜０．概要＞において上述したようにMPDを適宜更新することにより、より効率よく行われるように、コンテンツの配信を制御する。
【０１７７】
図２７のフローチャートを参照して、このMPDコンフィギュレータ１４１による配信制御処理の流れの例を説明する。
【０１７８】
配信制御処理が開始されると、MPDコンフィギュレータ１４１のMPD取得部３６１は、ステップＳ１０１において、MPDコンフィギュレータ１４１の管理対象となる（配下の）クライアントから供給されるMPDを取得（収集）する。
【０１７９】
ステップＳ１０２において、リソース情報要求部３６２がリソース情報を要求し、リソース情報取得部３６３がリソース情報を取得することにより、放送配信リソース１５２（マルチキャスト配信および放送配信用のリソース）が確認される。
【０１８０】
ステップＳ１０３において、コスト評価部３６４は、ステップＳ１０１におけるMPDの収集結果（MPDの取得量、すなわち、コンテンツの要求量）や、ステップＳ１０２における確認結果（リソース情報取得部３６３が取得したリソース情報）に応じて、マルチキャスト配信および放送配信利用のコストを評価する。
【０１８１】
ステップＳ１０４において、コスト評価部３６４は、ステップＳ１０３の評価結果に基づいて、マルチキャスト配信または放送配信を利用するか否かを判定する。利用すると判定された場合、処理はステップＳ１０５に進む。
【０１８２】
ステップＳ１０５において、リソース確保要求部３６５がリソースの確保を要求し、リソース確保結果通知取得部３６６がリソース確保結果の通知を取得することにより、利用可能な放送配信リソース１５２が確保される。
【０１８３】
ステップＳ１０６において、MPD更新部３６７は、ステップＳ１０５の処理により確保された放送配信リソース１５２を利用するように、＜０．概要＞において上述したようにMPDを更新する。ステップＳ１０６の処理が終了すると、処理は、ステップＳ１０７に進む。
【０１８４】
また、ステップＳ１０４において、マルチキャスト配信または放送配信を利用しないと判定された場合、処理は、ステップＳ１０７に進む。
【０１８５】
ステップＳ１０７において、MPD供給部３６８は、MPDをDASHクライアントプロキシ１４３に供給する。
【０１８６】
ステップＳ１０７の処理が終了すると、配信制御処理が終了する。MPDコンフィギュレータ１４１は、このような配信制御処理を実行することにより、コンテンツの配信をより効率よく行うようにすることができる。また、MPDコンフィギュレータ１４１は、このような配信制御処理を繰り返し実行する。これにより、MPDコンフィギュレータ１４１は、常に、コンテンツの配信をより効率よく行うようにすることができる。例えば、MPDコンフィギュレータ１４１は、配信中のコンテンツについてもこのような配信制御処理を実行する。これにより、MPDコンフィギュレータ１４１は、コンテンツ配信中であっても、適応的に配信方法を制御することができ、より効率よくコンテンツ配信を行うことができる。
【０１８７】
＜DASHクライアントプロキシ処理の流れ＞
以上のような機能を有するDASHクライアントプロキシ１４３（図２６）は、DASHクライアント１１４の代わりに、MPDコンフィギュレータ１４１による配信制御処理に対応して、DASHクライアントプロキシ処理を実行する。これにより、DASHクライアントプロキシ１４３は、MPDコンフィギュレータ１４１の配信制御に応じた、より効率のよいコンテンツの配信を実現する。
【０１８８】
図２８のフローチャートを参照して、このDASHクライアントプロキシ１４３によるDASHクライアントプロキシ処理の流れの例を説明する。
【０１８９】
DASHクライアントプロキシ処理が開始されると、MPD供給部３８２は、ステップＳ１２１において、MPD取得部３８１が取得したMPD（MPDコンフィギュレータ１４１により供給されたMPD）に基づいて、マルチキャスト配信若しくは放送配信を利用するか否かを判定する。利用すると判定された場合、処理はステップＳ１２２に進む。
【０１９０】
ステップＳ１２２において、MPD供給部３８２は、MPD取得部３８１が取得したMPDをBC/MCサービスプロバイダ１２４に供給し、そのMPDをDASHクライアント１１４に対して周期的に配信させる。
【０１９１】
ステップＳ１２３において、セグメント要求部３８３は、DASHセグメントストリーマ１２２に対してDASHセグメントの取得を要求する。
【０１９２】
ステップＳ１２４において、セグメント取得部３８４は、ステップＳ１２３における要求に応じて供給されるDASHセグメントを取得する。
【０１９３】
ステップＳ１２５において、FLUTE配信依頼部３８５は、ステップＳ１２４において取得したDASHセグメントをBC/MCサービスプロバイダ１２４に供給し、FLUTE配信依頼をする。つまり、この場合、コンテンツは、BC/MCサービスプロバイダ１２４からDASHクライアント１１４に対してマルチキャスト配信若しくは放送配信される。
【０１９４】
ステップＳ１２５の処理が終了すると、DASHクライアントプロキシ処理が終了する。
【０１９５】
また、ステップＳ１２１において、マルチキャスト配信若しくは放送配信を利用しないと判定された場合、処理はステップＳ１２６に進む。
【０１９６】
ステップＳ１２６において、MPD供給部３８２は、MPD取得部３８１が取得したMPDをDASHクライアント１１４に供給する。この場合、DASHクライアント１１４が、DASHセグメントストリーマ１２２にDASHセグメントを要求し、取得する。つまり、この場合、コンテンツは、ユニキャスト配信される。
【０１９７】
ステップＳ１２６の処理が終了すると、DASHクライアントプロキシ処理が終了する。
【０１９８】
以上のようにすることにより、DASHクライアントプロキシ１４３は、MPDコンフィギュレータ１４１の配信制御に応じた、より効率のよいコンテンツの配信を実現することができる。
【０１９９】
なお、配信制御処理が上述したように繰り返し実行される場合、このDASHクライアントプロキシ処理も、それに対応して繰り返し実行される。また、配信制御処理が上述したようにコンテンツ配信中に実行される場合、このDASHクライアントプロキシ処理も、それに対応してコンテンツ配信中に実行される。
【０２００】
＜コンテンツ配信処理の流れ＞
以上のようなコンテンツ配信システム１００により行われるコンテンツの配信の例を、図２９乃至図３１のフローチャートを参照して説明する。
【０２０１】
コンテンツ配信システム１００によりコンテンツ配信処理が開始されると、DASH-MPDサーバ１２３は、DASHセグメントストリーマ１２２が管理するコンテンツについて、MPD生成部３４１がMPDを生成し（ステップＳ２１１）、MPD管理部３４２がそのMPDを管理する。
【０２０２】
コンテンツの配信を要求するユーザに操作されたDASHクライアント１１４のMPD要求部３５１は、所望のコンテンツのMPDの取得を、DASH-MPDサーバ１２３に対して要求する（ステップＳ２６１）。
【０２０３】
DASH-MPDサーバ１２３のMPD供給部３４３は、その要求を受け取ると（ステップＳ２１２）、要求されたMPDを要求元であるDASHクライアント１１４に供給する（ステップＳ２１３）。
【０２０４】
DASHクライアント１１４のMPD取得部３５２がそのMPDを受け取ると（ステップＳ２６２）、判定部３５３は、帯域をモニタリングし、ユニキャスト受信が不安定になりそうか否か、並びに、マルチキャストが受信可能なデバイスであるか否か等により、コンテンツの受信方法、すなわち、MPDを送信するか否かを判定する（ステップＳ２６３）。
【０２０５】
ユニキャスト受信が不安定になりそうであり、かつ、マルチキャストが受信可能である場合、判定部３５３は、MPDを送信すると判定し、MPD供給部３５４は、MPDをMPDコンフィギュレータ１４１に供給する（ステップＳ２６４）。
【０２０６】
MPDコンフィギュレータ１４１のMPD取得部３６１がそのMPDを取得すると（ステップＳ２２１）、リソース情報要求部３６２は、BC/MCリソースマネージャ１４２に対してリソース情報を要求する（ステップＳ２２２）。
【０２０７】
BC/MCリソースマネージャ１４２のリソース情報要求取得部３７１がその要求を取得すると（ステップＳ２３１）、リソース情報生成部３７２がリソース情報を生成し（ステップＳ２３２）、リソース情報供給部３７３がそのリソース情報を、要求元であるMPDコンフィギュレータ１４１に供給する（ステップＳ２３３）。
【０２０８】
MPDコンフィギュレータ１４１のリソース情報取得部３６３がそのリソース情報を取得すると（ステップＳ２２３）、コスト評価部３６４は、BC/MC併用コストを評価し、マルチキャスト配信若しくは放送配信を利用するか否かを判定する（ステップＳ２２４）。
【０２０９】
ここで、マルチキャスト配信若しくは放送配信を利用すると判定されたとする。その場合、リソース確保要求部３６５は、リソース情報に基づいて利用可能なBC/MCリソース（放送配信リソース１５２）の確保を、BC/MCリソースマネージャ１４２に対して要求する（ステップＳ２２５）。
【０２１０】
BC/MCリソースマネージャ１４２のリソース確保要求取得部３７４がその要求を取得すると（ステップＳ２３４）、リソース確保部３７５が、要求された放送配信リソース１５２を確保し（ステップＳ２３５）、リソース確保結果通知部３７６が、リソース確保結果を、要求元であるMPDコンフィギュレータ１４１に通知する（ステップＳ２３６）。
【０２１１】
MPDコンフィギュレータ１４１のリソース確保結果通知取得部３６６がそのリソース確保結果を取得すると（ステップＳ２２６）、MPD更新部３６７が、＜０．概要＞において上述したようにMPDを書き換えて（ステップＳ２２７）、MPD供給部３６８が、更新されたMPDをDASHクライアントプロキシ１４３に供給する（ステップＳ２２８）。
【０２１２】
DASHクライアントプロキシ１４３のMPD取得部３８１がそのMPDを取得すると（ステップＳ２４１）、MPD供給部３８２は、そのMPDを、マルチキャスト配信若しくは放送配信を利用しない場合、DASHクライアント１１４に供給し、マルチキャスト配信若しくは放送配信を利用する場合、BC/MCサービスプロバイダ１２４に供給する（ステップＳ２４２）。
【０２１３】
BC/MCサービスプロバイダ１２４（FLUTEサーバ１３１）のMPDマルチキャスト配信部３１２は、そのMPDを取得すると（ステップＳ２５１）、取得したMPDを、DASHクライアント１１４に対して、周期的に（つまり複数回繰り返し）マルチキャスト配信する（ステップＳ２５２）。
【０２１４】
DASHクライアント１１４のMPD取得部３５２は、DASHクライアントプロキシ１４３から供給されるMPD、若しくは、BC/MCサービスプロバイダ１２４から周期的にマルチキャスト配信されるMPDを取得する（ステップＳ２６６）。
【０２１５】
ここで、MPD取得部３５２により取得されたMPDにおいて、マルチキャスト配信若しくは放送配信を利用しないようになされている場合、つまり、ユニキャスト配信によりDASHセグメントを取得する場合、処理は、図３０に進む。
【０２１６】
この場合、DASHクライアント１１４のセグメント要求部３５５は、MPDの情報に基づいて、DASHセグメントストリーマ１２２に対して、所望のDASHセグメントの取得を要求する（ステップＳ２６７）。
【０２１７】
DASHセグメントストリーマ１２２のDASHセグメント供給部３０３は、その要求を取得すると（ステップＳ２０１）、要求されたDASHセグメントを、要求元であるDASHクライアント１１４に供給（ユニキャスト配信）する（ステップＳ２０２）。
【０２１８】
DASHクライアント１１４のセグメント取得部３５６が、そのユニキャスト配信されたDASHセグメントを取得すると（ステップＳ２６８）、セグメント再生部３５７は、そのDASHセグメントを再生する（ステップＳ２６９）。
【０２１９】
また、図２９のステップＳ２６６においてMPD取得部３５２により取得されたMPDにおいて、マルチキャスト配信若しくは放送配信を利用するようになされている場合、つまり、マルチキャスト配信若しくは放送配信によりDASHセグメントを取得する場合、処理は、図３１に進む。
【０２２０】
この場合、DASHクライアント１１４の代わりに、DASHクライアントプロキシ１４３のセグメント要求部３８３は、MPDの情報に基づいて、DASHセグメントストリーマ１２２に対して、所望のDASHセグメントの取得を要求する（ステップＳ２４３）。
【０２２１】
DASHセグメントストリーマ１２２のDASHセグメント供給部３０３は、その要求を取得すると（ステップＳ２０３）、要求されたDASHセグメントを、要求元であるDASHクライアントプロキシ１４３に供給する（ステップＳ２０４）。
【０２２２】
DASHクライアントプロキシ１４３のセグメント取得部３８４が、そのDASHセグメントを取得すると（ステップＳ２４４）、FLUTE配信依頼部３８５は、BC/MCサービスプロバイダ１２４に対してそのDASHセグメントを供給し、配信依頼を行う（ステップＳ２４５）。
【０２２３】
BC/MCサービスプロバイダ１２４（FLUTEサーバ１３１）のプロトコル変換部３１１は、そのDASHセグメントを取得すると（ステップＳ２５３）、取得したDASHセグメントをマルチキャストプロトコル（例えば、FLUTEプロトコル等）に変換する（ステップＳ２５４）。
【０２２４】
マルチキャスト配信を行う場合、セグメントマルチキャスト配信部３１３は、そのプロトコル変換されたDASHセグメント（FDTやFLUTEパケット）を、DASHクライアント１１４に対してマルチキャスト配信する（ステップＳ２５５）。
【０２２５】
なお、ここで、放送配信を行う場合、放送配信依頼部３１４は、プロトコル変換されたDASHセグメント（FDTやFLUTEパケット）を、放送配信サーバ１３２に供給し、放送配信依頼する。これを受けて、放送配信サーバ１３２の放送配信部３３１は、プロトコル変換されたDASHセグメント（FDTやFLUTEパケット）を、DASHクライアント１１４に対して放送配信する。
【０２２６】
DASHクライアント１１４のセグメント取得部３５６が、このようにマルチキャスト配信（若しくは放送配信）されたセグメント（FDTやFLUTEパケット）を取得し（ステップＳ２７０）、セグメント再生部３５７が、そのセグメント（FDTやFLUTEパケット）を再生する（ステップＳ２７１）。
【０２２７】
以上のようなコンテンツ配信処理を行うことにより、コンテンツ配信システム１００は、より効率よくコンテンツ配信を行うことができる。
【０２２８】
＜２．第２の実施の形態＞
＜コンテンツ配信システム＞
なお、第１の実施の形態においては、MPDコンフィギュレータ１４１が、DASHクライアント１１４から供給されるMPDを収集するように説明したが、MPDの送付元はどこであってもよく、これに限らない。例えば、DASH-MPDサーバ１２３等のコンテンツ提供システム１１１側のデバイスから供給されるようにしてもよい。また、例えば、DASH-MPDサーバ１２３の代わりに処理を行うプロキシサーバを設けるようにし、そのプロキシサーバからMPDが供給されるようにしてもよい。
【０２２９】
図３２は、本技術を適用したコンテンツ供給システムの一実施の形態であるコンテンツ配信システムの主な構成例を示すブロック図である。
【０２３０】
図３２に示されるコンテンツ配信システム４００は、コンテンツ配信システム１００（図１７）と同様のシステムである。コンテンツ配信システム４００は、コンテンツ配信システム１００の構成に加え、配信制御システム１１２の構成として、プロキシサーバ４４１を有する。
【０２３１】
プロキシサーバ４４１は、ネット上のマルチキャスト、もしくは、放送により配信されるFLUTE上のファイルを展開（キャッシュ）して、DASHクライアント１１４に対してDASH-MPDサーバ１２３若しくはDASHセグメントストリーマ１２２としてふるまうサーバである。
【０２３２】
＜物理的構成＞
このプロキシサーバ４４１も、MPDコンフィギュレータ１４１と同様の構成を有するものとする。すなわち、以下において、プロキシサーバ４４１のデバイスの物理的な構成について説明する場合、図１８を参照して説明する。
【０２３３】
＜機能的構成＞
図３３は、プロキシサーバ４４１が有する主な機能ブロックの構成例を示す図である。図３３に示されるように、プロキシサーバ４４１は、例えば、MPD要求部４５１、MPD取得部４５２、MPD供給部４５３、セグメント取得部４５４、およびセグメント供給部４５５を有する。
【０２３４】
MPD要求部４５１は、プロキシサーバ４４１の通信部２１４を介して、外部（例えば、DASHクライアント１１４等）からMPD取得要求を取得し、その要求に基づいて、外部（例えば、DASH-MPDサーバ１２３等）に対してMPDの取得を要求する。
【０２３５】
MPD取得部４５２は、プロキシサーバ４４１の通信部２１４を介して、MPD要求部４５１がした要求に対して外部（例えば、DASH-MPDサーバ１２３、FLUTEサーバ１３１、放送配信（MBMS）サーバ１３２、MPDコンフィギュレータ１４１等）から供給されるMPDを取得する。
【０２３６】
MPD供給部４５３は、プロキシサーバ４４１の通信部２１４を介して、MPD取得部４５２により取得されたMPDを、外部（例えば、MPDコンフィギュレータ１４１、DASHクライアント１１４等）に供給する。
【０２３７】
セグメント取得部４５４は、プロキシサーバ４４１の通信部２１４を介して、外部（例えば、FLUTEサーバ１３１、放送配信（MBMS）サーバ１３２等）から供給されるセグメント（FDTやFLUTEパケット）を取得する。
【０２３８】
セグメント供給部４５５は、プロキシサーバ４４１の通信部２１４を介して、セグメント取得部４５４により取得されたセグメント（FDTやFLUTEパケット）を、外部（例えば、DASHクライアント１１４等）に供給する。
【０２３９】
もちろん、プロキシサーバ４４１は、任意の機能ブロックを有することができる。例えば、図３３に示される例以外の機能ブロックを有することもできる。
【０２４０】
＜コンテンツ配信処理の流れ＞
以上のようなコンテンツ配信システム４００（図３２）により行われるコンテンツの配信の例を、図３４乃至図３６のフローチャートを参照して説明する。
【０２４１】
コンテンツ配信システム４００によりコンテンツ配信処理の場合も、DASH-MPDサーバ１２３は、DASHセグメントストリーマ１２２が管理するコンテンツについて、MPD生成部３４１がMPDを生成し（ステップＳ４１１）、MPD管理部３４２がそのMPDを管理する。
【０２４２】
ただし、DASHクライアント１１４からのMPD要求（ステップＳ４７１）は、プロキシサーバ４４１を介してDASH-MPDサーバ１２３に供給される。つまり、プロキシサーバ４４１のMPD要求部４５１が、DASHクライアント１１４からのMPD要求を取得し（ステップＳ４２１）、それをDASH-MPDサーバ１２３に供給する（ステップＳ４２２）。
【０２４３】
したがって、この場合、DASH-MPDサーバ１２３のMPD供給部３４３は、プロキシサーバ４４１を介して供給された要求を受け取ると（ステップＳ４１２）、要求されたMPDをプロキシサーバ４４１に供給する（ステップＳ４１３）。
【０２４４】
プロキシサーバ４４１のMPD取得部４５２は、そのMPDを取得すると（ステップＳ４２３）、それをMPDコンフィギュレータ１４１に供給する（ステップＳ４２４）。
【０２４５】
つまり、この場合、MPDコンフィギュレータ１４１には、MPDが、プロキシサーバ４４１から供給される。すなわち、この場合、DASHクライアント１１４がMPDをMPDコンフィギュレータ１４１に供給しなくても、MPDコンフィギュレータ１４１によるコンテンツの配信方法の制御が行われる。
【０２４６】
MPDコンフィギュレータ１４１は、ステップＳ４３１乃至ステップＳ４３７の各処理を、ステップＳ２２１乃至ステップＳ２２７の各処理（図２９）と同様に行い、BC/MCリソースマネージャ１４２は、ステップＳ４４１乃至ステップＳ４４６の各処理を、ステップＳ２３１乃至ステップＳ２３６の各処理と同様に行い、配信方法を決定し、必要に応じてMPDを更新する。
【０２４７】
この場合、MPDコンフィギュレータ１４１のMPD供給部３６８は、MPDをプロキシサーバ４４１に供給する（ステップＳ４３８）。
【０２４８】
プロキシサーバ４４１のMPD取得部４５２がそのMPDを取得すると（ステップＳ４２５）、MPD供給部４５３が、そのMPDをDASHクライアントプロキシ１４３に供給する（ステップＳ４２６）。
【０２４９】
これ以降の処理は、第１の実施の形態の場合と同様である。
【０２５０】
すなわち、DASHクライアントプロキシ１４３は、ステップＳ４５１およびステップＳ４５２の各処理を、ステップＳ２４１およびステップＳ２４２の各処理（図２９）と同様に行い、BC/MCサービスプロバイダ１２４は、ステップＳ４６１およびステップＳ４６２の各処理を、ステップＳ２５１およびステップＳ２５２の各処理（図２９）と同様に行い、DASHクライアント１１４は、ステップＳ４７２乃至ステップＳ４７３の各処理を、ステップＳ２６３、ステップＳ２６５、およびステップＳ２６６の各処理（図２９）と同様に行う。ただし、この場合DASHクライアント１１４は、ステップＳ４７２若しくはステップＳ４７３においてMPDを取得するので、ステップＳ４７４において受信方法の判定を行う。
【０２５１】
図３４においてユニキャスト受信が選択された場合、処理は、図３５に進む。すなわち、DASHセグメントストリーマ１２２は、ステップＳ４０１およびステップＳ４０２の各処理を、ステップＳ２０１およびステップＳ２０２の各処理（図３０）と同様に行う。また、DASHクライアント１１４は、ステップＳ４７５乃至ステップＳ４７７の各処理を、ステップＳ２６７乃至ステップＳ２６９の各処理（図３０）と同様に行う。
【０２５２】
図３４においてマルチキャスト受信（若しくは放送受信）が選択された場合、処理は、図３６に進む。すなわち、DASHセグメントストリーマ１２２は、ステップＳ４０３およびステップＳ４０４の各処理を、ステップＳ２０３およびステップＳ２０４の各処理（図３１）と同様に行う。
【０２５３】
また、DASHクライアントプロキシ１４３は、ステップＳ４５３乃至ステップＳ４５５の各処理を、ステップＳ２４３乃至ステップＳ２４５の各処理（図３１）と同様に行う。
【０２５４】
さらに、BC/MCサービスプロバイダ１２４は、ステップＳ４６３乃至ステップＳ４６５の各処理を、ステップＳ２５３乃至ステップＳ２５５の各処理（図３１）と同様に行う。
【０２５５】
また、DASHクライアント１１４は、ステップＳ４７８およびステップＳ４７９の各処理を、ステップＳ２７０およびステップＳ２７１の各処理（図３１）と同様に行う。
【０２５６】
以上のようなコンテンツ配信処理を行うことにより、コンテンツ配信システム４００も、より効率よくコンテンツ配信を行うことができる。
【０２５７】
＜３．第３の実施の形態＞
＜MPDおよびストリームの伝送＞
本実施の形態においては、第１の実施の形態や第２の実施の形態において説明したMPDやストリームの伝送の流れの例についてさらに説明する。
【０２５８】
コンテンツマネジメントサーバ１２１にて管理されるコンテンツからDASHセグメントストリーマ１２２におけるDASHストリームセグメント生成、DASH-MPDサーバ１２３によるDASH-MPD生成までの処理の流れと、DASHセグメントストリーマ１２２において生成されたストリームセグメントならびにストリームセグメントurlからFLUTEサーバ１３１におけるFLUTEのFDTとFLUTEストリームの生成に至る処理の流れの例を、図３７のフローチャートを参照して説明する。
【０２５９】
DASH-MPDサーバ１２３は、ステップＳ５１１乃至ステップＳ５１３の各処理を、ステップＳ２１１乃至ステップＳ２１３の各処理（図２９）と同様に行う。また、この例の場合、DASHクライアントプロキシ１４３のMPD取得部３８１が、DASHクライアント１１４の代わりに、ステップＳ５４１およびステップＳ５４２の各処理を、ステップＳ２６１およびステップＳ２６２の各処理（図２９）と同様に行う。
【０２６０】
MPDを取得すると、DASHセグメントストリーマ１２２は、ステップＳ５０１およびステップＳ５０２の各処理を、ステップＳ２０３およびステップＳ２０４の各処理（図３１）と同様に行う。これに対して、DASHクライアントプロキシ１４３のセグメント要求部３８３は、ステップＳ５４３およびステップＳ５４４の各処理を、ステップＳ２４３およびステップＳ２４４（図３１）と同様に行う。
【０２６１】
ユニキャスト配信が利用される場合、DASHセグメントストリーマ１２２は、ステップＳ５０３において、DASHセグメントをHTTP配信する。
【０２６２】
また、マルチキャスト配信若しくは放送配信を利用する場合、DASHクライアントプロキシ１４３のFLUTE配信依頼部３８５は、ステップＳ５４５の処理を、ステップＳ２４５の処理（図３１）と同様に行う。つまり、DASHクライアントプロキシ１４３は、BC/MCサービスプロバイダ１２４のFLUTEサーバ１３１に対してFLUTE配信依頼要求を行う。
【０２６３】
FLUTEサーバ１３１のプロトコル変換部３１１がそのFLUTE配信依頼要求を取得すると（ステップＳ５２１）、FDT生成部３２１がFDTを生成し（ステップＳ５２２）、FLUTEストリーム生成部３２２がFLUTEストリーム（FLUTEパケット等）を生成する（ステップＳ５２３）。
【０２６４】
放送配信を行う場合は、放送配信依頼部３１４が、放送配信（MBMS）サーバ１３２に対して、そのFDTやFLUTEパケット等を供給し、放送配信依頼を行う（ステップＳ５２４）。放送配信（MBMS）サーバ１３２の放送配信部３３１は、その依頼を受け取ると（ステップＳ５３２）、その依頼に基づいて、FDTやFLUTEパケットを放送配信する（ステップＳ５３２）。
【０２６５】
マルチキャスト配信する場合は、FLUTEサーバ１３１のセグメントマルチキャスト配信部３１３が、FDTやFLUTEパケット等をマルチキャスト配信する（ステップＳ５２５）。
【０２６６】
次に、ユニキャスト配信の場合の、MPD配信、クライアント主導のストリームセグメント取得・再生の処理の流れを、図３８のフローチャートを参照して説明する。
【０２６７】
この場合、DASHクライアント１１４は、ステップＳ５７１乃至ステップＳ５７５の各処理を、ステップＳ２６１およびステップＳ２６２（図２９）、並びに、ステップＳ２６７乃至ステップＳ２６９（図３０）の各処理と同様に行う。
【０２６８】
また、DASH-MPDサーバ１２３は、ステップＳ５６１およびステップＳ５６２の各処理を、ステップＳ２１２およびステップＳ２１３の各処理（図２９）と同様に行う。
【０２６９】
そして、DASHセグメントストリーマ１２２は、ステップＳ５５１およびステップＳ５５２の各処理を、ステップＳ２０１およびステップＳ２０２の各処理（図３０）と同様に行う。
【０２７０】
次に、マルチキャスト配信若しくは放送配信の場合の、MPD配信、クライアント受動のストリームセグメント受信・再生の処理の流れを、図３９のフローチャートを参照して説明する。
【０２７１】
この場合、DASHクライアント１１４は、ステップＳ６１１およびステップＳ６１２の各処理を、ステップＳ５７１およびステップＳ５７２の各処理（図３８）と同様に行う。これに対応して、DASH-MPDサーバ１２３は、ステップＳ５８１およびステップＳ５８２の各処理を、ステップＳ５６１およびステップＳ５６２の各処理（図３８）と同様に行う。
【０２７２】
マルチキャスト配信の場合、FLUTEサーバ１３１が、セグメントをマルチキャスト配信する（ステップＳ５９１）。放送配信の場合、放送配信（MBMS）サーバ１３２に対する放送配信依頼となる。その場合、放送配信（MBMS）サーバ１３２は、その依頼（セグメント）を取得し（ステップＳ６０１）、放送配信する（ステップＳ６０２）。
【０２７３】
DASHクライアント１１４は、マルチキャスト配信の場合、FLUTEサーバ１３１から供給されるセグメントを取得し（ステップＳ６１３）、放送配信の場合、放送配信（MBMS）サーバ１３２から供給されるセグメントを取得する（ステップＳ６１４）。
【０２７４】
DASHクライアント１１４は、このように取得したセグメントを再生する（ステップＳ６１５）。
【０２７５】
なお、上述したストリームセグメントのマルチキャストは、ストリームセグメントが生成されると同時に行われるようにしてもよい。その場合の処理の流れの例を、図４０のフローチャートを参照して説明する。
【０２７６】
この場合、図３９と処理順が異なるのみで同様の処理が行われる。
【０２７７】
つまり、FLUTEサーバ１３１が、ステップＳ６３１の処理をステップＳ５９１の処理と同様に行い、放送配信（MBMS）サーバ１３２が、ステップＳ６４１およびステップＳ６４２の各処理を、ステップＳ６０１およびステップＳ６０２の各処理と同様に行い、DASHクライアント１１４が、ステップＳ６５１の処理をステップＳ６１３と同様に行うか、若しくは、ステップＳ６５２の処理をステップＳ６１４と同様に行う。
【０２７８】
そして、DASHクライアント１１４が、ステップＳ６５３およびステップＳ６５４の各処理を、ステップＳ６１１およびステップＳ６１２と同様に行い、DASH-MPDサーバ１２３が、ステップＳ６２１およびステップＳ６２２の各処理を、ステップＳ５８１およびステップＳ５８２の各処理と同様に行う。
【０２７９】
そして、DASHクライアント１１４が、ステップＳ６５５の処理を、ステップＳ６１５の処理と同様に行う。
【０２８０】
このような手順によりコンテンツの配信を行うこともできる。
【０２８１】
なお、MPD配信もFLUTEにより放送(マルチキャスト)配信で行うこともできる。その場合の処理の流れの例を、図４１のフローチャートを参照して説明する。
【０２８２】
この場合、DASH-MPDサーバ１２３は、MPDをFLUTEサーバ１３１に供給する（ステップＳ６６１）。
【０２８３】
FLUTEサーバ１３１は、そのMPDを取得すると（ステップＳ６７１）、そのMPDをマルチキャスト配信する（ステップＳ６７２）。なお、MPDを放送配信する場合は、この処理が、放送配信（MBMS）サーバ１３２に対する放送配信依頼となる。その場合、放送配信（MBMS）サーバ１３２は、その依頼（セグメント）を取得し（ステップＳ６８１）、放送配信する（ステップＳ６８２）。
【０２８４】
DASHクライアント１１４は、マルチキャスト配信の場合、FLUTEサーバ１３１から供給されるMPDを取得し（ステップＳ６９１）、放送配信の場合、放送配信（MBMS）サーバ１３２から供給されるMPDを取得する（ステップＳ６９２）。
【０２８５】
セグメントの配信については、図３９の場合と同様に行われる。
【０２８６】
すなわち、FLUTEサーバ１３１が、ステップＳ６７３の処理をステップＳ５９１の処理と同様に行い、放送配信（MBMS）サーバ１３２が、ステップＳ６８３およびステップＳ６８４の各処理を、ステップＳ６０１およびステップＳ６０２の各処理と同様に行い、DASHクライアント１１４が、ステップＳ６９３乃至ステップＳ６９５の各処理をステップＳ６１３乃至ステップＳ６１５の各処理と同様に行う。
【０２８７】
このような手順によりMPDの配信を行うこともできる。
【０２８８】
図４１のフローチャートの場合の処理を、第２の実施の形態にも適用することができる。その場合の処理の流れの例を、図４２のフローチャートを参照して説明する。
【０２８９】
この場合、DASH-MPDサーバ１２３、FLUTEサーバ１３１、および放送配信（MBMS）サーバ１３２は、図４１の場合と同様に各処理を実行する。つまり、DASH-MPDサーバ１２３は、ステップＳ７０１の処理を、ステップＳ６６１の処理と同様に行い、FLUTEサーバ１３１は、ステップＳ７１１乃至ステップＳ７１３の各処理を、ステップＳ６７１乃至ステップＳ６７３の各処理と同様に行い、放送配信（MBMS）サーバ１３２は、ステップＳ７２１乃至ステップＳ７２４の各処理を、ステップＳ６８１乃至ステップＳ６８４の各処理と同様に行う。
【０２９０】
ただし、図４２の場合、MPDやセグメントの配信先は、DASHクライアント１１４ではなく、プロキシサーバ４４１である。プロキシサーバ４４１は、ステップＳ７３１若しくはステップＳ７３２において、MPDを取得し、ステップＳ７３３若しくはステップＳ７３４において、セグメントを取得する。
【０２９１】
DASHクライアント１１４は、このようにプロキシサーバ４４１によりキャッシュされたMPDやセグメントを取得する。
【０２９２】
つまり、DASHクライアント１１４は、プロキシサーバ４４１に対して、MPDの取得を要求し（ステップＳ７４１）、その要求に応じて供給されたMPDを取得する（ステップＳ７４２）。プロキシサーバ４４１は、DASHクライアント１１４からのMPD取得要求を受け取ると（ステップＳ７３５）、要求されたMPDを要求元であるDASHクライアント１１４に供給する（ステップＳ７３６）。
【０２９３】
また、DASHクライアント１１４は、プロキシサーバ４４１に対して、セグメントの取得を要求し（ステップＳ７４３）、その要求に応じて供給されたセグメントを取得する（ステップＳ７４４）。プロキシサーバ４４１は、DASHクライアント１１４からのセグメントの要求を受け取ると（ステップＳ７３７）、要求されたセグメントを要求元であるDASHクライアント１１４に供給する（ステップＳ７３８）。
【０２９４】
セグメントを取得したDASHクライアント１１４は、そのセグメントを再生する（ステップＳ７４５）。
【０２９５】
以上のように、プロキシサーバ４４１を介してMPDやセグメントを配信することもできる。
【０２９６】
以上においては、DASHのストリームを配信する場合について説明したが、本技術は、DASH以外の任意のコンテンツ配信技術に適用することができる。
【０２９７】
また、上述した一連の処理は、ハードウエアにより実行させることもできるし、ソフトウエアにより実行させることもできる。一連の処理をソフトウエアにより実行する場合には、そのソフトウエアを構成するプログラムが、例えば、図１８に示されるような構成のコンピュータにインストールされる。ここでコンピュータには、専用のハードウエアに組み込まれているコンピュータや、各種のプログラムをインストールすることで、各種の機能を実行することが可能な、例えば汎用のパーソナルコンピュータ等が含まれる。
【０２９８】
図１８のように構成されるコンピュータでは、CPU２０１が、例えば、記憶部２１３に記憶されているプログラムを、入出力インタフェース２１０およびバス２０４を介して、RAM２０３にロードして実行することにより、上述した一連の処理が行われる。RAM２０３にはまた、CPU２０１が各種の処理を実行する上において必要なデータなども適宜記憶される。
【０２９９】
コンピュータ（CPU２０１）が実行するプログラムは、例えば、パッケージメディア等としてのリムーバブルメディア２２１に記録して適用することができる。また、プログラムは、ローカルエリアネットワーク、インターネット、デジタル衛星放送といった、有線または無線の伝送媒体を介して提供することができる。
【０３００】
コンピュータでは、プログラムは、リムーバブルメディア２２１をドライブ２１５に装着することにより、入出力インタフェース２１０を介して、記憶部２１３にインストールすることができる。また、プログラムは、有線または無線の伝送媒体を介して、通信部２１４で受信し、記憶部２１３にインストールすることができる。その他、プログラムは、ROM２０２や記憶部２１３に、あらかじめインストールしておくことができる。
【０３０１】
なお、コンピュータが実行するプログラムは、本明細書で説明する順序に沿って時系列に処理が行われるプログラムであっても良いし、並列に、あるいは呼び出しが行われたとき等の必要なタイミングで処理が行われるプログラムであっても良い。
【０３０２】
また、本明細書において、記録媒体に記録されるプログラムを記述するステップは、記載された順序に沿って時系列的に行われる処理はもちろん、必ずしも時系列的に処理されなくとも、並列的あるいは個別に実行される処理をも含むものである。
【０３０３】
また、本明細書において、システムとは、複数の構成要素（装置、モジュール（部品）等）の集合を意味し、全ての構成要素が同一筐体中にあるか否かは問わない。したがって、別個の筐体に収納され、ネットワークを介して接続されている複数の装置、及び、１つの筐体の中に複数のモジュールが収納されている１つの装置は、いずれも、システムである。
【０３０４】
また、以上において、１つの装置（または処理部）として説明した構成を分割し、複数の装置（または処理部）として構成するようにしてもよい。逆に、以上において複数の装置（または処理部）として説明した構成をまとめて１つの装置（または処理部）として構成されるようにしてもよい。また、各装置（または各処理部）の構成に上述した以外の構成を付加するようにしてももちろんよい。さらに、システム全体としての構成や動作が実質的に同じであれば、ある装置（または処理部）の構成の一部を他の装置（または他の処理部）の構成に含めるようにしてもよい。
【０３０５】
以上、添付図面を参照しながら本開示の好適な実施形態について詳細に説明したが、本開示の技術的範囲はかかる例に限定されない。本開示の技術分野における通常の知識を有する者であれば、請求の範囲に記載された技術的思想の範疇内において、各種の変更例または修正例に想到し得ることは明らかであり、これらについても、当然に本開示の技術的範囲に属するものと了解される。
【０３０６】
例えば、本技術は、１つの機能を、ネットワークを介して複数の装置で分担、共同して処理するクラウドコンピューティングの構成をとることができる。
【０３０７】
また、上述のフローチャートで説明した各ステップは、１つの装置で実行する他、複数の装置で分担して実行することができる。
【０３０８】
さらに、１つのステップに複数の処理が含まれる場合には、その１つのステップに含まれる複数の処理は、１つの装置で実行する他、複数の装置で分担して実行することができる。
【０３０９】
以上、添付図面を参照しながら本開示の好適な実施形態について詳細に説明したが、本開示はかかる例に限定されない。本開示の属する技術の分野における通常の知識を有する者であれば、請求の範囲に記載された技術的思想の範疇内において、各種の変更例または修正例に想到し得ることは明らかであり、これらについても、当然に本開示の技術的範囲に属するものと了解される。
【０３１０】
なお、本技術は以下のような構成も取ることができる。
（１）  コンテンツの供給にマルチキャスト配信若しくは放送配信を利用するか否かを判定する判定部と、
前記判定部により前記マルチキャスト配信若しくは前記放送配信を利用すると判定された場合、前記コンテンツの供給に前記マルチキャスト配信若しくは前記放送配信を利用するように、前記コンテンツのユニキャスト配信に関する制御情報を更新する更新部と
を備える情報処理装置。
（２）  前記判定部は、前記コンテンツの供給にマルチキャスト配信若しくは放送配信を利用する場合のコストを評価し、その評価結果に応じて、前記コンテンツの供給にマルチキャスト配信若しくは放送配信を利用するか否かを判定する
（１）、（３）乃至（１７）のいずれかに記載の情報処理装置。
（３）  前記制御情報を受け取る受け取り部をさらに備え、
前記判定部は、前記受け取り部により受け取られた前記制御情報に応じて、前記コンテンツの供給にマルチキャスト配信若しくは放送配信を利用する場合のコストを評価し、その評価結果に応じて、前記コンテンツの供給にマルチキャスト配信若しくは放送配信を利用するか否かを判定し、
前記更新部は、前記判定部により前記マルチキャスト配信若しくは前記放送配信を利用すると判定された場合、前記コンテンツの供給に前記マルチキャスト配信若しくは前記放送配信を利用するように、前記受け取り部により受け取られた前記制御情報を更新する
（１）、（２）、（４）乃至（１７）のいずれかに記載の情報処理装置。
（４）  前記判定部は、前記受け取り部により受け取られた前記制御情報の量に応じて、前記コストを評価する
（１）乃至（３）、（５）乃至（１７）のいずれかに記載の情報処理装置。
（５）  前記受け取り部は、所定のネットワークに接続されるクライアントから供給される前記制御情報を受け取る
（１）乃至（４）、（６）乃至（１７）のいずれかに記載の情報処理装置。
（６）  前記受け取り部は、前記コンテンツを供給するサーバのプロキシサーバから供給される、前記プロキシサーバがクライアントから収集した前記制御情報を受け取る
（１）乃至（５）、（７）乃至（１７）のいずれかに記載の情報処理装置。
（７）  マルチキャスト配信若しくは放送配信のリソースの利用状況を確認する確認部をさらに備え、
前記判定部は、前記確認部により確認された利用可能な前記リソースを利用する場合についての前記コストを評価する
（１）乃至（６）、（８）乃至（１７）のいずれかに記載の情報処理装置。
（８）  前記判定部により前記マルチキャスト配信若しくは前記放送配信を利用すると判定された場合、前記コンテンツを供給するためのマルチキャスト配信若しくは放送配信のリソースを確保する確保部をさらに備え、
前記更新部は、前記コンテンツの供給に、前記確保部により確保された前記リソースを利用するように、前記制御情報を更新する
（１）乃至（７）、（９）乃至（１７）のいずれかに記載の情報処理装置。
（９）  前記コンテンツは、DASH（Dynamic Adaptive Streaming over HTTP）フォーマットのストリームであり、
前記制御情報は、MPD（Media Presentation Description）である
（１）乃至（８）、（１０）乃至（１７）のいずれかに記載の情報処理装置。
（１０）  前記更新部は、前記MPDのBaseURLに配置されるserviceLocationAttribute URL属性により指定されるService Locationファイルの、DeliverySystemIdentifierに、前記コンテンツの供給に利用するマルチキャスト配信若しくは放送配信を識別する識別子を格納する
（１）乃至（９）、（１１）乃至（１７）のいずれかに記載の情報処理装置。
（１１）  前記更新部は、前記MPDのBaseURLに配置されるserviceLocationAttribute URL属性により指定されるService Locationファイルの、DeliverySystemDescriptorに、前記DeliverySystemIdentifierに格納された識別子に対応するシステムにおいてストリームデータを取得するためのパラメタを格納する
（１）乃至（１０）、（１２）乃至（１７）のいずれかに記載の情報処理装置。
（１２）  前記コンテンツのユニキャスト用のストリームをユニキャスト配信するユニキャスト配信部をさらに備える
（１）乃至（１１）、（１３）乃至（１７）のいずれかに記載の情報処理装置。
（１３）  前記コンテンツのユニキャスト用のストリームをマルチキャスト配信若しくは放送配信用のストリームに変換する変換部と、
前記変換部により生成された前記ストリームをマルチキャスト配信若しくは放送配信するBC/MC配信部をさらに備える
（１）乃至（１２）、（１４）乃至（１７）のいずれかに記載の情報処理装置。
（１４）  前記ユニキャスト用のストリームは、DASH（Dynamic Adaptive Streaming over HTTP）フォーマットのストリームであり、
前記変換部により生成されたマルチキャスト配信若しくは放送配信用のストリームは、FLUTE（File Delivery over Unidirectional Transport）プロトコルのファイルである
（１）乃至（１３）、（１５）乃至（１７）のいずれかに記載の情報処理装置。
（１５）  前記変換部は、前記FLUTEプロトコルのファイルのFDT（File Delivery Table）-Instanceにおいて、File要素の属性としてrange属性を導入する
（１）乃至（１４）、（１６）、（１７）のいずれかに記載の情報処理装置。
（１６）  前記更新部により更新された前記制御情報を供給する供給部をさらに備える
（１）乃至（１５）、（１７）のいずれかに記載の情報処理装置。
（１７）  クライアントの代わりに前記コンテンツを取得し、前記供給部より供給される前記制御情報に応じて、取得した前記コンテンツをユニキャスト配信により前記クライアントに供給するか、若しくは、取得した前記コンテンツを、マルチキャスト配信若しくは放送配信のリソースを利用して前記クライアントに供給する供給制御部をさらに備える
（１）乃至（１６）のいずれかに記載の情報処理装置。
（１８）  コンテンツの供給にマルチキャスト配信若しくは放送配信を利用するか否かを判定し、
前記マルチキャスト配信若しくは前記放送配信を利用すると判定された場合、前記コンテンツの供給に前記マルチキャスト配信若しくは前記放送配信を利用するように、前記コンテンツのユニキャスト配信に関する制御情報を更新する
情報処理方法。
（１９）  コンピュータを、
コンテンツの供給にマルチキャスト配信若しくは放送配信を利用するか否かを判定する判定部と、
前記判定部により前記マルチキャスト配信若しくは前記放送配信を利用すると判定された場合、前記コンテンツの供給に前記マルチキャスト配信若しくは前記放送配信を利用するように、前記コンテンツのユニキャスト配信に関する制御情報を更新する更新部と
して機能させるプログラム。
（２０）  サーバからクライアントにコンテンツを供給するコンテンツ供給システムであって、
前記クライアントからの前記コンテンツの取得要求量に応じて、前記コンテンツの供給にマルチキャスト配信若しくは放送配信を利用するか否かを判定し、
前記マルチキャスト配信若しくは前記放送配信を利用すると判定された場合、前記サーバから前記クライアントへの前記コンテンツの供給に前記マルチキャスト配信若しくは前記放送配信を利用するように、前記コンテンツのユニキャスト配信に関する制御情報を更新する
コンテンツ供給システム。
【符号の説明】
【０３１１】
１００  コンテンツ配信システム，  １１１  コンテンツ提供システム，  １１２  配信制御システム，  １１３  ネットワーク，  １１４  DASHクライアント，  １２１  コンテンツマネジメントサーバ，  １２２  DASHセグメントストリーマ，  １２３  DASH-MPDサーバ，  １２４  BC/MCサービスプロバイダ，  １３１  FLUTEサーバ，  １３２  放送配信サーバ，  １４１  MPDコンフィギュレータ，  １４２  BC/MCリソースマネージャ，  １４３  DASHクライアントプロキシ，  ３６１  MPD取得部，  ３６２  リソース情報要求部，  ３６３  リソース情報取得部，  ３６４  コスト評価部，  ３６５  リソース確保要求部，  ３６６  リソース確保結果通知取得部，  ３６７  MPD更新部，  ３６８  MPD供給部，  ３７１  リソース情報要求取得部，  ３７２  リソース情報生成部，  ３７３  リソース情報供給部，  ３７４  リソース確保要求取得部，  ３７５  リソース確保部，  ３７６  リソース確保結果通知部，  ３８１  MPD取得部，  ３８２  MPD供給部，  ３８３  セグメント要求部，  ３８４  セグメント取得部，  ３８５  FLUTE配信依頼部，  ４００  コンテンツ配信システム，  ４４１  プロキシサーバ
【図１】
2014132821.tif 000003
【図２】
2014132821.tif 000004
【図３】
2014132821.tif 000005
【図４】
2014132821.tif 000006
【図５】
2014132821.tif 000007
【図６】
2014132821.tif 000008
【図７】
2014132821.tif 000009
【図８】
2014132821.tif 000010
【図９】
2014132821.tif 000011
【図１０】
2014132821.tif 000012
【図１１】
2014132821.tif 000013
【図１２】
2014132821.tif 000014
【図１３】
2014132821.tif 000015
【図１４】
2014132821.tif 000016
【図１５】
2014132821.tif 000017
【図１６】
2014132821.tif 000018
【図１７】
2014132821.tif 000019
【図１８】
2014132821.tif 000020
【図１９】
2014132821.tif 000021
【図２０】
2014132821.tif 000022
【図２１】
2014132821.tif 000023
【図２２】
2014132821.tif 000024
【図２３】
2014132821.tif 000025
【図２４】
2014132821.tif 000026
【図２５】
2014132821.tif 000027
【図２６】
2014132821.tif 000028
【図２７】
2014132821.tif 000029
【図２８】
2014132821.tif 000030
【図２９】
2014132821.tif 000031
【図３０】
2014132821.tif 000032
【図３１】
2014132821.tif 000033
【図３２】
2014132821.tif 000034
【図３３】
2014132821.tif 000035
【図３４】
2014132821.tif 000036
【図３５】
2014132821.tif 000037
【図３６】
2014132821.tif 000038
【図３７】
2014132821.tif 000039
【図３８】
2014132821.tif 000040
【図３９】
2014132821.tif 000041
【図４０】
2014132821.tif 000042
【図４１】
2014132821.tif 000043
【図４２】
2014132821.tif 000044
【手続補正書】
【提出日】平成26年6月27日(2014.6.27)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
コンテンツのユニキャスト配信に関する制御情報を受け取る受け取り部と、
前記受け取り部により受け取られた前記制御情報に応じて、前記コンテンツの供給にマルチキャスト配信若しくは放送配信を利用する場合のコストを評価し、その評価結果に応じて、前記コンテンツの供給にマルチキャスト配信若しくは放送配信を利用するか否かを判定する判定部と、
前記判定部により前記マルチキャスト配信若しくは前記放送配信を利用すると判定された場合、前記コンテンツの供給に前記マルチキャスト配信若しくは前記放送配信を利用するように、前記受け取り部により受け取られた前記制御情報を更新する更新部と
を備える情報処理装置。
【請求項２】
（削除）
【請求項３】
（削除）
【請求項４】
前記判定部は、前記受け取り部により受け取られた前記制御情報の量に応じて、前記コストを評価する
請求項１に記載の情報処理装置。
【請求項５】
前記受け取り部は、所定のネットワークに接続されるクライアントから供給される前記制御情報を受け取る
請求項１に記載の情報処理装置。
【請求項６】
前記受け取り部は、前記コンテンツを供給するサーバのプロキシサーバから供給される、前記プロキシサーバがクライアントから収集した前記制御情報を受け取る
請求項１に記載の情報処理装置。
【請求項７】
マルチキャスト配信若しくは放送配信のリソースの利用状況を確認する確認部をさらに備え、
前記判定部は、前記確認部により確認された利用可能な前記リソースを利用する場合についての前記コストを評価する
請求項１に記載の情報処理装置。
【請求項８】
前記判定部により前記マルチキャスト配信若しくは前記放送配信を利用すると判定された場合、前記コンテンツを供給するためのマルチキャスト配信若しくは放送配信のリソースを確保する確保部をさらに備え、
前記更新部は、前記コンテンツの供給に、前記確保部により確保された前記リソースを利用するように、前記制御情報を更新する
請求項１に記載の情報処理装置。
【請求項９】
前記コンテンツは、ＤＡＳＨ（Ｄｙｎａｍｉｃ  Ａｄａｐｔｉｖｅ  Ｓｔｒｅａｍｉｎｇ  ｏｖｅｒ  ＨＴＴＰ）フォーマットのストリームであり、
前記制御情報は、ＭＰＤ（Ｍｅｄｉａ  Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｄｅｓｃｒｉｐｔｉｏｎ）である
請求項１に記載の情報処理装置。
【請求項１０】
前記更新部は、前記ＭＰＤのＢａｓｅＵＲＬに配置されるｓｅｒｖｉｃｅＬｏｃａｔｉｏｎＡｔｔｒｉｂｕｔｅ  ＵＲＬ属性により指定されるＳｅｒｖｉｃｅ  Ｌｏｃａｔｉｏｎファイルの、ＤｅｌｉｖｅｒｙＳｙｓｔｅｍＩｄｅｎｔｉｆｉｅｒに、前記コンテンツの供給に利用するマルチキャスト配信若しくは放送配信を識別する識別子を格納する
請求項９に記載の情報処理装置。
【請求項１１】
前記更新部は、前記ＭＰＤのＢａｓｅＵＲＬに配置されるｓｅｒｖｉｃｅＬｏｃａｔｉｏｎＡｔｔｒｉｂｕｔｅ  ＵＲＬ属性により指定されるＳｅｒｖｉｃｅ  Ｌｏｃａｔｉｏｎファイルの、ＤｅｌｉｖｅｒｙＳｙｓｔｅｍＤｅｓｃｒｉｐｔｏｒに、前記ＤｅｌｉｖｅｒｙＳｙｓｔｅｍＩｄｅｎｔｉｆｉｅｒに格納された識別子に対応するシステムにおいてストリームデータを取得するためのパラメタを格納する
請求項１０に記載の情報処理装置。
【請求項１２】
前記コンテンツのユニキャスト用のストリームをユニキャスト配信するユニキャスト配信部をさらに備える
請求項１に記載の情報処理装置。
【請求項１３】
前記コンテンツのユニキャスト用のストリームをマルチキャスト配信若しくは放送配信用のストリームに変換する変換部と、
前記変換部により生成された前記ストリームをマルチキャスト配信若しくは放送配信するＢＣ／ＭＣ配信部をさらに備える
請求項１２に記載の情報処理装置。
【請求項１４】
前記ユニキャスト用のストリームは、ＤＡＳＨ（Ｄｙｎａｍｉｃ  Ａｄａｐｔｉｖｅ  Ｓｔｒｅａｍｉｎｇ  ｏｖｅｒ  ＨＴＴＰ）フォーマットのストリームであり、
前記変換部により生成されたマルチキャスト配信若しくは放送配信用のストリームは、ＦＬＵＴＥ（Ｆｉｌｅ  Ｄｅｌｉｖｅｒｙ  ｏｖｅｒ  Ｕｎｉｄｉｒｅｃｔｉｏｎａｌ  Ｔｒａｎｓｐｏｒｔ）プロトコルのファイルである
請求項１３に記載の情報処理装置。
【請求項１５】
前記変換部は、前記ＦＬＵＴＥプロトコルのファイルのＦＤＴ（Ｆｉｌｅ  Ｄｅｌｉｖｅｒｙ  Ｔａｂｌｅ）−Ｉｎｓｔａｎｃｅにおいて、Ｆｉｌｅ要素の属性としてｒａｎｇｅ属性を導入する
請求項１４に記載の情報処理装置。
【請求項１６】
前記更新部により更新された前記制御情報を供給する供給部をさらに備える
請求項１に記載の情報処理装置。
【請求項１７】
クライアントの代わりに前記コンテンツを取得し、
前記供給部より供給される前記制御情報に応じて、取得した前記コンテンツをユニキャスト配信により前記クライアントに供給するか、若しくは、取得した前記コンテンツを、マルチキャスト配信若しくは放送配信のリソースを利用して前記クライアントに供給する供給制御部をさらに備える
請求項１６に記載の情報処理装置。
【請求項１８】
コンテンツのユニキャスト配信に関する制御情報を受け取り、
受け取られた前記制御情報に応じて、前記コンテンツの供給にマルチキャスト配信若しくは放送配信を利用する場合のコストを評価し、その評価結果に応じて、前記コンテンツの供給にマルチキャスト配信若しくは放送配信を利用するか否かを判定し、
前記マルチキャスト配信若しくは前記放送配信を利用すると判定された場合、前記コンテンツの供給に前記マルチキャスト配信若しくは前記放送配信を利用するように、受け取られた前記制御情報を更新する
情報処理方法。
【請求項１９】
コンピュータを、
コンテンツのユニキャスト配信に関する制御情報を受け取る受け取り部と、
前記受け取り部により受け取られた前記制御情報に応じて、前記コンテンツの供給にマルチキャスト配信若しくは放送配信を利用する場合のコストを評価し、その評価結果に応じて、前記コンテンツの供給にマルチキャスト配信若しくは放送配信を利用するか否かを判定する判定部と、
前記判定部により前記マルチキャスト配信若しくは前記放送配信を利用すると判定された場合、前記コンテンツの供給に前記マルチキャスト配信若しくは前記放送配信を利用するように、前記受け取り部により受け取られた前記制御情報を更新する更新部と
して機能させるプログラム。
【請求項２０】
サーバからクライアントにコンテンツを供給するコンテンツ供給システムであって、
前記コンテンツのユニキャスト配信に関する制御情報を受け取り、
受け取られた前記制御情報に応じて、前記コンテンツの供給にマルチキャスト配信若しくは放送配信を利用する場合のコストを評価し、その評価結果に応じて、前記コンテンツの供給にマルチキャスト配信若しくは放送配信を利用するか否かを判定し、
前記マルチキャスト配信若しくは前記放送配信を利用すると判定された場合、前記サーバから前記クライアントへの前記コンテンツの供給に前記マルチキャスト配信若しくは前記放送配信を利用するように、受け取られた前記制御情報を更新する
コンテンツ供給システム。
【国際調査報告】
2014132821.tif 000045
2014132821.tif 000046
2014132821.tif 000047
2014132821.tif 000048