(57)【要約】  本開示は、複数のトランスポートメディアの割り当てを最適化および効率化することができるようにするコンテンツ提供システムおよびコンテンツ提供方法、並びにプログラムに関する。コンテンツ配信装置は、コンテンツを再生するクライアントへ、トランスポート特性の異なる複数のネットワークを使用してコンテンツを配信する。コンテンツ提供装置は、特徴の異なる複数のストリームにより構成されるコンテンツを配信するにあたり、それぞれのストリームの配信を、複数のネットワークで分配する際の判断基準となるポリシーを、コンテンツ配信装置に提供する。本技術は、例えば、MPEG DASHを利用してコンテンツを提供するコンテンツ提供システムに適用できる。
2018173874.tif 000002
【特許請求の範囲】
【請求項１】
コンテンツを再生するクライアントへ、トランスポート特性の異なる複数のネットワークを使用して前記コンテンツを配信するコンテンツ配信装置と、
特徴の異なる複数のストリームにより構成される前記コンテンツを配信するにあたり、それぞれの前記ストリームの配信を、複数の前記ネットワークで分配する際の判断基準となるポリシーを、前記コンテンツ配信装置に提供するコンテンツ提供装置と
を備えるコンテンツ提供システム。
【請求項２】
前記ポリシーでは、所定のネットワークに対する負荷の大きさを表すレベルごとに、特徴の異なる複数のストリームのうちの、そのネットワークで配信するストリームと、他のネットワークで配信するストリームとが分類される
請求項１に記載のコンテンツ提供システム。
【請求項３】
前記コンテンツ提供装置は、前記ポリシーおよび前記レベルを、MPEG DASHにおいてメタ情報を記述するのに用いられるMPD（Media Presentation Description）に記述し、前記MPDを前記コンテンツ配信装置に転送する
請求項２に記載のコンテンツ提供システム。
【請求項４】
前記コンテンツ配信装置は、前記コンテンツ提供装置から転送された前記MPDを、前記MPDに記述されている前記ポリシーおよび前記レベルを参照し、前記レベルに応じて書き換える
請求項３に記載のコンテンツ提供システム。
【請求項５】
前記コンテンツ配信装置は、複数のセグメントマネジャを有しており、それらのセグメントマネジャごとに前記MPDが書き換えられる
請求項４に記載のコンテンツ提供システム。
【請求項６】
前記コンテンツ提供装置は、前記ポリシーおよび前記レベルを、MPEG DASHにおいてイベントを通知する機能を利用して前記コンテンツを再生するクライアントに提供する
請求項２に記載のコンテンツ提供システム。
【請求項７】
前記コンテンツ提供装置は、前記ポリシーおよび前記レベルを、前記コンテンツ提供装置と前記コンテンツ配信装置、または、前記コンテンツを再生するクライアントとの間でやりとりするメッセージングインターフェイス利用して前記コンテンツ配信装置、または、前記コンテンツを再生するクライアントに提供する
請求項２に記載のコンテンツ提供システム。
【請求項８】
コンテンツ提供システムが、
コンテンツを再生するクライアントへ、トランスポート特性の異なる複数のネットワークを使用して前記コンテンツを配信することと、
特徴の異なる複数のストリームにより構成される前記コンテンツを配信するにあたり、それぞれの前記ストリームの配信を、複数の前記ネットワークで分配する際の判断基準となるポリシーを提供することと
を含むコンテンツ提供方法。
【請求項９】
コンテンツ提供システムのコンピュータに、
コンテンツを再生するクライアントへ、トランスポート特性の異なる複数のネットワークを使用して前記コンテンツを配信することと、
特徴の異なる複数のストリームにより構成される前記コンテンツを配信するにあたり、それぞれの前記ストリームの配信を、複数の前記ネットワークで分配する際の判断基準となるポリシーを提供することと
を含む処理を実行させるプログラム。
【請求項１０】
コンテンツ配信ネットワークを構成するサーバと、
前記コンテンツ配信ネットワークを介して配信されるコンテンツの提供を受けるクライアント装置と
を備え、
前記サーバまたは前記クライアント装置が、複数の提供元から提供される優先度が、時間的に変化するように記述されるメタデータを参照して、前記優先度の高い順に、前記コンテンツを構成するセグメントを先行取得する
コンテンツ提供システム。
【請求項１１】
前記優先度は、前記コンテンツを提供するコンテンツ提供者が提供し、前記コンテンツを作成した作成者の意図に従った値で記述される
請求項１０に記載のコンテンツ提供システム。
【請求項１２】
前記優先度は、前記コンテンツ配信ネットワークにより提供され、前記コンテンツ配信ネットワークを介して前記コンテンツが過去に配信されたときに実測された統計に基づく値で記述される
請求項１０に記載のコンテンツ提供システム。
【請求項１３】
前記メタデータには、前記優先度が適用されるセグメントを指定する要素が記述される
請求項１０に記載のコンテンツ提供システム。
【請求項１４】
前記優先度が適用される一連のセグメントの最初のセグメントを識別する番号、および、それらの一連のセグメントのセグメント数を用いて、前記優先度が適用されるセグメントが指定される
請求項１３に記載のコンテンツ提供システム。
【請求項１５】
前記優先度の適用が開始される開始時間、および、前記優先度の適用が終了される終了時間を用いて、前記優先度が適用される期間が指定される
請求項１０に記載のコンテンツ提供システム。
【請求項１６】
前記セグメントを先行取得する際に参照される前記メタデータは、MPEG DASHのMPDに記述されるアダプテーションセットに対する子エレメントとして定義される
請求項１０に記載のコンテンツ提供システム。
【請求項１７】
前記セグメントを先行取得する際に参照される前記メタデータは、MPEG DASHのMPDに記述されるリプレゼンテーションに対する子エレメントとして定義される
請求項１０に記載のコンテンツ提供システム。
【請求項１８】
前記セグメントを先行取得する際に参照される前記メタデータは、MPEG DASHのMPDにおいて複数のネットワークで分配する際の判断基準となるポリシー／レベルの記述で用いられるディストリビューションポリシーのエレメントにおけるレベルを利用して指定される
請求項１０に記載のコンテンツ提供システム。
【請求項１９】
コンテンツ提供システムは、
コンテンツ配信ネットワークを構成するサーバと、
前記コンテンツ配信ネットワークを介して配信されるコンテンツの提供を受けるクライアント装置と
を備え、
前記サーバまたは前記クライアント装置が、複数の提供元から提供される優先度が、時間的に変化するように記述されるメタデータを参照して、前記優先度の高い順に、前記コンテンツを構成するセグメントを先行取得すること
を含むコンテンツ提供方法。
【請求項２０】
コンテンツ配信ネットワークを構成するサーバと、
前記コンテンツ配信ネットワークを介して配信されるコンテンツの提供を受けるクライアント装置と
を備えるコンテンツ提供システムのコンピュータに、
前記サーバまたは前記クライアント装置が、複数の提供元から提供される優先度が、時間的に変化するように記述されるメタデータを参照して、前記優先度の高い順に、前記コンテンツを構成するセグメントを先行取得すること
を含む処理を実行させるプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本開示は、コンテンツ提供システムおよびコンテンツ提供方法、並びにプログラムに関し、特に、複数のトランスポートメディアの割り当てを最適化および効率化することができるようにしたコンテンツ提供システムおよびコンテンツ提供方法、並びにプログラムに関する。
【背景技術】
【０００２】
IPTV(Internet Protocol Television)等のインターネットストリーミングにおける標準化の流れとして、HTTP(Hypertext Transfer Protocol)ストリーミングによるVOD（Video On Demand）ストリーミングや、ライブストリーミングに適用される方式の標準化が行われている。【０００３】
特に、ISO/IEC/MPEGで標準化が行われているMPEG-DASH(Moving Picture Experts Group Dynamic Adaptive Streaming over HTTP)が注目されている（例えば、非特許文献１参照）。【０００４】
また、MPEG DASHでは、SAND（Server and Network Assisted DASH）において、プロキシやCDNエッジサーバがクライアントに対してDASHセグメント（segment）のキャッシュ状況（アベイラビリティ（availability））を知らせるステータス（status）メッセージが定義されている（例えば、非特許文献２参照）。
【先行技術文献】
【非特許文献】
【０００５】
【非特許文献１】ISO/IEC 23009-1:2012 Information technology Dynamic adaptive streaming over HTTP (DASH)
【非特許文献２】ISO/IEC JTC 1/SC 29/WG 11, Information Technology - Dynamic adaptive streaming over HTTP (DASH) - Part 5: Server and network assisted DASH (SAND), FDIS ISO/IEC 23009-5, N15991, 2015-02-19
【発明の概要】
【発明が解決しようとする課題】
【０００６】
ところで、MPEG DASHでは、DASHストリーミング（例えば、複数のビットレート等、トランスポート特性の異なるストリーム）を複数のトランスポートメディアに割り当てることができる。例えば、MPEG DASHにおいて、ATSCや3GPP-MBMSなどの放送と双方向配信メディアとにDASHストリーミングを割り当てることが想定される。このように、DASHストリーミングを複数のトランスポートメディアの割り当てる際に、より確実に割り当ての最適化および効率化を図ることが求められている。【０００７】
本開示は、このような状況に鑑みてなされたものであり、複数のトランスポートメディアの割り当てを最適化および効率化することができるようにするものである。
【課題を解決するための手段】
【０００８】
本開示の第１の側面のコンテンツ提供システムは、コンテンツを再生するクライアントへ、トランスポート特性の異なる複数のネットワークを使用して前記コンテンツを配信するコンテンツ配信装置と、特徴の異なる複数のストリームにより構成される前記コンテンツを配信するにあたり、それぞれの前記ストリームの配信を、複数の前記ネットワークで分配する際の判断基準となるポリシーを、前記コンテンツ配信装置に提供するコンテンツ提供装置とを備える。【０００９】
本開示の第１の側面のコンテンツ提供方法は、コンテンツ提供システムが、コンテンツを再生するクライアントへ、トランスポート特性の異なる複数のネットワークを使用して前記コンテンツを配信することと特徴の異なる複数のストリームにより構成される前記コンテンツを配信するにあたり、それぞれの前記ストリームの配信を、複数の前記ネットワークで分配する際の判断基準となるポリシーを提供することとを含む。【００１０】
本開示の第１の側面のプログラムは、コンテンツ提供システムのコンピュータに、コンテンツを再生するクライアントへ、トランスポート特性の異なる複数のネットワークを使用して前記コンテンツを配信することと、特徴の異なる複数のストリームにより構成される前記コンテンツを配信するにあたり、それぞれの前記ストリームの配信を、複数の前記ネットワークで分配する際の判断基準となるポリシーを提供することとを含む処理を実行させる。【００１１】
本開示の第１の側面においては、コンテンツを再生するクライアントへ、トランスポート特性の異なる複数のネットワークを使用してコンテンツが配信される。そして、特徴の異なる複数のストリームにより構成されるコンテンツを配信するにあたり、それぞれのストリームの配信を、複数のネットワークで分配する際の判断基準となるポリシーが提供される。【００１２】
本開示の第２の側面のコンテンツ提供システムは、コンテンツ配信ネットワークを構成するサーバと、前記コンテンツ配信ネットワークを介して配信されるコンテンツの提供を受けるクライアント装置とを備え、前記サーバまたは前記クライアント装置が、複数の提供元から提供される優先度が、時間的に変化するように記述されるメタデータを参照して、前記優先度の高い順に、前記コンテンツを構成するセグメントを先行取得する。【００１３】
本開示の第２の側面のコンテンツ提供方法は、コンテンツ提供システムは、コンテンツ配信ネットワークを構成するサーバと、前記コンテンツ配信ネットワークを介して配信されるコンテンツの提供を受けるクライアント装置とを備え、前記サーバまたは前記クライアント装置が、複数の提供元から提供される優先度が、時間的に変化するように記述されるメタデータを参照して、前記優先度の高い順に、前記コンテンツを構成するセグメントを先行取得することを含む。【００１４】
本開示の第２の側面のプログラムは、コンテンツ配信ネットワークを構成するサーバと、前記コンテンツ配信ネットワークを介して配信されるコンテンツの提供を受けるクライアント装置とを備えるコンテンツ提供システムのコンピュータに、前記サーバまたは前記クライアント装置が、複数の提供元から提供される優先度が、時間的に変化するように記述されるメタデータを参照して、前記優先度の高い順に、前記コンテンツを構成するセグメントを先行取得することを含む処理を実行させる。【００１５】
本開示の第２の側面においては、サーバまたはクライアント装置により、複数の提供元から提供される優先度が、時間的に変化するように記述されるメタデータが参照されて、優先度の高い順に、コンテンツを構成するセグメントが先行取得される。
【発明の効果】
【００１６】
本開示の第１の側面によれば、複数のトランスポートメディアの割り当てを最適化および効率化することができる。本開示の第２の側面によれば、セグメントのデータ配信における遅延を削減することができる。
【図面の簡単な説明】
【００１７】
【図１】インフィニットシーティングの概念を説明する図である。
【図２】インフィニットシーティングを提供するサービスのイメージを説明する図である。
【図３】MPDを利用して、ユニキャストおよび放送でリソース割り当てを行う概略について説明する図である。
【図４】MPDを利用して、放送およびMBMSでリソース割り当てを行う概略について説明する図である。
【図５】シートロケーションと、ビューおよびエンコーディングとの関係について説明する図である。
【図６】それぞれのシートごとに撮影される全天球ビューと、アングルごとのビューとの関係を示す図である。
【図７】優先シートをなるべく放送でプッシュするように放送とネットとを割り当てるポリシーの一例を示す図である。
【図８】ROIアングルビューをなるべく放送でプッシュする場合の割り当ての一例を示す図である。
【図９】レベルと放送負荷との関係を示す図である。
【図１０】優先シートをなるべく放送でプッシュする場合の割り当て例を表現したDistributionPolicy要素の内容を示す図である。
【図１１】ROIアングルビューをなるべく放送でプッシュする場合の割り当て例を表現したDistributionPolicy要素の内容を示す図である。
【図１２】MPD内に記述する場合のDistributionPolicyのXML表記の一例を示す図である。
【図１３】オプショナルなDistributionMediaDependantExtension要素について説明する図である。
【図１４】MPDの記述例を示す図である。
【図１５】図１４に示すMPDから生成されるべき有効なMPDを示す図である。
【図１６】MPDの再構成について構造的に示す図である。
【図１７】MPDの記述例を示す図である。
【図１８】図１７に示すMPDから生成されるべき有効なMPDを示す図である。
【図１９】MPDの記述例を示す図である。
【図２０】図１９に示すMPDから生成されるべき有効なMPDを示す図である。
【図２１】MPDの再構成について構造的に示す図である。
【図２２】MPDの再構成について構造的に示す図である。
【図２３】コンテンツ提供システムの第１の構成例を示す図である。
【図２４】MPD/DistricutionGroupをヒントとして生成されるMPDについて説明する図である。
【図２５】コンテンツ提供システムの第２の構成例を示す図である。
【図２６】コンテンツ配信処理を説明するフローチャートである。
【図２７】一般的なMPD Eventの一例を示す図である。
【図２８】In-band Event Signalingの一例を示す図である。
【図２９】MPDの当該AdaptationSet/Representation要素にInbandEventStream要素を配置する例を示す図である。
【図３０】DASH Eventによるポリシー／レベル通知の一例を示す図である。
【図３１】MPDの記述例を示す図である。
【図３２】emsgボックスの記述例を示す図である。
【図３３】MPDの記述例を示す図である。
【図３４】コンテンツ提供システムの第３の構成例を示す図である。
【図３５】クライアント側で再構成できるようにしたMPDを示す図である。
【図３６】クライアントで生成されたMPDを示す図である。
【図３７】クライアントで生成されたMPDを示す図である。
【図３８】コンテンツ配信処理を説明するフローチャートである。
【図３９】コンテンツ配信処理を説明するフローチャートである。
【図４０】クライアントでパースされたMPDの一例を示す図である。
【図４１】クライアントで検出されたIn-band Event、および、再構成されたMPDの一例を示す図である。
【図４２】クライアントでパースされたMPDの一例を示す図である。
【図４３】クライアントで検出されたIn-band Event、および、再構成されたMPDの一例を示す図である。
【図４４】コンテンツ配信処理を説明するフローチャートである。
【図４５】コンテンツ配信処理を説明するフローチャートである。
【図４６】クライアントでパースされたMPDの一例を示す図である。
【図４７】クライアントで検出されたIn-band Event、および、再構成されたMPDの一例を示す図である。
【図４８】クライアントでパースされたMPDの一例を示す図である。
【図４９】クライアントで検出されたIn-band Event、および、再構成されたMPDの一例を示す図である。
【図５０】MPD拡張のバリエーションを示す図である。
【図５１】MPD拡張のバリエーションを示す図である。
【図５２】メッセージングインターフェイスが定義を示す図である。
【図５３】DANE間でやりとりされるメッセージについて説明する図である。
【図５４】SANDのメッセージのやり取りについて説明する図である。
【図５５】DASHクライアントにおける処理の流れを示す図である。
【図５６】MPDUpdateDirectiveメッセージついて説明する図である。
【図５７】MPDUpdateDirectiveメッセージの一例を示す図である。
【図５８】MPDUpdateDirectiveフラグメントのインスタンスの第１の記述例を示す図である。
【図５９】MPDUpdateDirectiveフラグメントのインスタンスの第２の記述例を示す図である。
【図６０】MPDUpdateDirectiveフラグメントのインスタンスの第３の記述例を示す図である。
【図６１】MPDUpdateDirectiveフラグメントのインスタンスの第４の記述例を示す図である。
【図６２】コンテンツ配信処理を説明するフローチャートである。
【図６３】コンテンツ配信処理を説明するフローチャートである。
【図６４】クライアントでパースされたMPDの一例を示す図である。
【図６５】MPDUpdateDirectiveの一例を示す図である。
【図６６】クライアントで再構成されたMPDの一例を示す図である。
【図６７】クライアントでパースされたMPDの一例を示す図である。
【図６８】MPDUpdateDirectiveの一例を示す図である。
【図６９】クライアントで再構成されたMPDの一例を示す図である。
【図７０】放送系のシグナリング拡張について説明する図である。
【図７１】MPDUpdateDirectiveフラグメントのインスタンスの第１の記述例を示す図である。
【図７２】MPDUpdateDirectiveフラグメントのインスタンスの第２の記述例を示す図である。
【図７３】MPDUpdateDirectiveフラグメントのインスタンスの第３の記述例を示す図である。
【図７４】MPDUpdateDirectiveフラグメントのインスタンスの第４の記述例を示す図である。
【図７５】コンテンツ配信処理を説明するフローチャートである。
【図７６】コンテンツ配信処理を説明するフローチャートである。
【図７７】クライアントでパースされたMPDの一例を示す図である。
【図７８】クライアントで再構成されたMPDの一例を示す図である。
【図７９】クライアントで再構成されたMPDの一例を示す図である。
【図８０】クライアントで再構成されたMPDの一例を示す図である。
【図８１】遅延制約の低いものをネットで配信する場合の割り当て例を表現したDistributionPolicy要素の内容を示す図である。
【図８２】MPDの記述例を示す図である。
【図８３】図８２に示すMPDから生成されるべき有効なMPDを示す図である。
【図８４】ATSC3.0クライアント実装モデルを示す図である。
【図８５】Annex.ATSC3.0プロトコルスタックを示す図である。
【図８６】ROUTE/DASHベースのスタックを示す図である。
【図８７】優先度を示すメタデータを参照して、セグメントを先行取得するようなコンテンツ提供システムの概要を示す図である。
【図８８】セグメントポピュラリティータイムラインのエレメントの定義例を示す図である。
【図８９】セグメントポピュラリティータイムラインのエレメントを使用したMPEG DASHのMPDの例を示す図である。
【図９０】セグメントポピュラリティータイムラインのエレメントの第１のバリエーションを示す図である。
【図９１】第１のバリエーションのセグメントポピュラリティータイムラインのエレメントを使用したMPEG DASHのMPDの例を示す図である。
【図９２】第２のバリエーションのセグメントポピュラリティータイムラインのエレメントを使用したMPEG DASHのMPDの例を示す図である。
【図９３】セグメントポピュラリティータイムラインのエレメントの第３のバリエーションについて説明する図である。
【図９４】ディストリビューションポリシーのエレメントにおけるレベルのエレメントを、DPレベルタイムラインのエレメントに置き換えた例を示す図である。
【図９５】第３のバリエーションディストリビューションポリシーの記述例を示す図である。
【図９６】セグメントを先行取得する先行取得処理の第１の処理例を説明するフローチャートである。
【図９７】先行取得処理（アダプテーションセット）について説明するフローチャートである。
【図９８】先行取得処理について説明する（リプレゼンテーション）について説明するフローチャートである。
【図９９】セグメントを先行取得する先行取得処理の第２の処理例を説明するフローチャートである。
【図１００】SANDメッセージの記述例を示す図である。
【図１０１】優先度順に複数列挙したSANDメッセージの記述例を示す図である。
【図１０２】CDNサーバへのセグメントポピュラリティータイムラインの利用時に優先すべきソースの値を通知する処理の概念を説明する図である。
【図１０３】本技術を適用したコンピュータの一実施の形態の構成例を示すブロック図である。
【発明を実施するための形態】
【００１８】
以下、本技術を適用した具体的な実施の形態について、図面を参照しながら詳細に説明する。
【００１９】
＜Infinite seatingについて＞
まず、図１を参照して、本技術を適用したコンテンツ配信方法で実現されるインフィニットシーティング（Infinite seating）の概念について説明する。
【００２０】
昨今のVR（virtual reality）に対する盛り上がりから、VRベースでインフィニットシーティングのサービスを提供可能とするユースケースをサポートする技術が求められている。
【００２１】
例えば、スポーツイベントや、コンサート、ゲームショー、テレビショーなどのブロードキャストまたはマルチキャストにおいて、複数の特定の席（場所）からの360°ビューを提供する値段を、優先シートと、その他のシートとで差を設けることができる。そして、ユーザは、複数の優先シートおよびその他のシートの中から、任意のシートを選んでコンテンツを視聴したり、それらのシートを自由に切り替えたりすることができる。
【００２２】
例えば、図１に示す例において、ハッチングが施された丸印が、優先シート（Reserved）を表しており、ハッチングが施されていない丸印が、その他のシート（Other）を表している。そして、複数のユーザは、それぞれ任意のシートからの360°ビューのコンテンツを視聴することができ、例えば、図１の例では、ユーザＵ１およびユーザＵ２は、同一の優先シートからの360°ビューのコンテンツを視聴している。また、ユーザＵ３およびＵ４は、それ以外の優先シートからの360°ビューのコンテンツを視聴しており、ユーザＵ５およびＵ６は、その他のシートからの360°ビューのコンテンツを視聴している。
【００２３】
図２を参照して、このようなインフィニットシーティングのユースケースを適用したサービスを提供するシステムのイメージについて説明する。
【００２４】
図２に示すコンテンツ提供システム１１は、全天球カメラ１２−１乃至１２−３からクライアント１３−１乃至１３−３へ、それぞれ放送ネットワーク１４および双方向ネットワーク１５を介してコンテンツが配信されるように構成されている。そして、コンテンツ提供システム１１により、例えば、マルチフィールド競技中継等のスタジアム収録ストリームを配信するサービスを提供することができる。
【００２５】
このようなコンテンツ提供システム１１では、快適なVR視聴体験を提供するために、ユーザの視聴アングルの変化が起こる際に、とりあえずユーザが選択しているシートの全天球ビューから必要な領域が切り出される。そして、その切り出した領域を、低遅延かつ表示連続性を担保するためにアングル変化に追随して表示し、ユーザの視聴アングルが定まると、その視聴アングルの高解像度ビューに切り替えて表示する手法が用いられる。
【００２６】
そして、このようなサービスの提供を実現するために、複数のシートに全天球カメラ１２が設置され、それぞれのシートから観ることができる全天球ビューと、各アングルの高解像度ビューがストリーミングされる。また、ユーザは、クライアント１３を利用してコンテンツを視聴することができる。例えば、ユーザによるコンテンツの視聴は、HMD（Head Mount Display）などに実装されるVRクライアントを利用する形態が想定される。
【００２７】
ところで、配信コストの制約がない場合には、すべての全天球ビューストリームとすべてのアングルビューストリームとを、ビットレートや遅延等のQoS（Quality of Service）が保証された放送ネットワーク１４で配信することが考えられる。しかしながら、そのような配信を行うのは、配信コストがかかり過ぎてしまうため、現実的ではない。
【００２８】
そのため、例えば、比較的に多くの視聴者が選択することが想定されるシートの全天球ビューストリームを放送ネットワーク１４でプッシュ型配信し、その他のストリームは双方向ネットワーク１５によりプル型配信することが好ましい。または、配信コストに余裕がある場合には、全天球ビューストリームに加えて、視聴者が見る可能性の高いROI（Region Of Interest）高解像度アングルビューストリームのみを放送ネットワーク１４でプッシュ型配信することが考えられる。また、ユーザが選択するシートの人気度がわからない場合には、すべてのシートの全天球ストリームを放送ネットワーク１４でプッシュ配信することも考えられる。このような様々な組み合わせや、レベル分けなどを行うことが現実的である。
【００２９】
このように、配信コストの異なる複数のネットワーク（トランスポートメディア）を介して配信する場合、配信メディアのコストに応じて、複数のトランスポートメディアの割り当てが行われる。例えば、3GPP-MBMSプラットフォームでは、セル毎に放送および双方向それぞれのネットワークの帯域構成を柔軟に割り当てることができる。ところで、このように複数のトランスポートメディアにストリームを割り当てるとき、それらの組み合わせを最適にかつ効率的に行うためには、優先的に割り当てを行う優先度がヒント情報として用いられる。しかしながら、そのようなヒント情報は、通常、コンテンツプロバイダのみが把握している。
【００３０】
また、今後、コンテンツ提供者から提供されるサービスストリーム群が、複数のトランスポートメディアを保有するサービスプロバイダ（CDN（Content Delivery Network）プロバイダ）を介して配信する形態が一般化する可能性が高いと想定される。そのため、このようなリソース割り当てを最適化かつ効率化するためのヒント情報の必要性が高まることが想定される。
【００３１】
例えば、図３および図4に示すように、リソース割り当てを最適化かつ効率化するためのヒント情報は、MPEG DASHにおいてメタ情報を記述するのに用いられるMPD（Media Presentation Description）を利用して、CDNプロバイダに提供することができる。
【００３２】
図３に示すコンテンツ提供システム１１において、コンテンツプロバイダ２１のMPDには、ユニキャストと放送とでリソースを分配する方針を示す分配ポリシが記述されている。そして、CDNサービスプロバイダ２２は、その分配ポリシを参考にして、ユニキャスト優先およびブロードキャスト優先のどちらかを選択することができる。例えば、双方向ネットワーク１５を利用したコンテンツの配信を優先する場合にはユニキャスト優先が選択され、放送ネットワーク１４を利用したコンテンツの配信を優先する場合にはブロードキャスト優先が選択される。
【００３３】
図３の例では、CDNサービスプロバイダ２２−１は、ユニキャスト優先を選択し、双方向ネットワーク１５を利用したコンテンツの配信が、放送ネットワーク１４を利用したコンテンツの配信よりも優先的に行われる。また、CDNサービスプロバイダ２２−２は、ブロードキャスト優先を選択し、放送ネットワーク１４を利用したコンテンツの配信が、双方向ネットワーク１５を利用したコンテンツの配信よりも優先的に行われる。
【００３４】
また、図４に示すコンテンツ提供システム１１では、放送およびMBMS（Multimedia Broadcast and Multicast Service）によるリソースの分配が行われる。そして、図４に示す例では、CDNサービスプロバイダ２２は、MBMS優先を選択し、MBMSを利用したコンテンツの配信が、双方向ネットワーク１５を利用したコンテンツの配信よりも優先的に行われている。また、放送サービスプロバイダ２３は、ブロードキャスト優先を選択し、放送ネットワーク１４を利用したコンテンツの配信のみが行われる。
【００３５】
また、図５では、フィールド競技やパレード等を視聴するために構成されたシートロケーションと、それぞれのシートごとに撮影されるビューおよびエンコーディングとの関係について説明する。
【００３６】
例えば、シートロケーションとしては、フィールド競技やパレードなどの近くに配置された優先シート（Reserved）と、優先シートよりも遠くに配置されたその他シート（Other）とがある。そして、それぞれのシートごとに、全天球ビュー（ViewScope-ALL）、アングルごとのビューを配信することができる。さらに、アングルごとのビューとして、視聴者が見たいと思う確率の高いアングルビュー（ViewScope-ROI）と、それ以外のアングルビュー（ViewScope-NonROI）とがある。
【００３７】
また、全天球ビュー（ViewScope-ALL）はEncodigタイプ（Base-通常解像度）でエンコードされ、各アングルビュー（ViewScope-ROI/NonROI）はEncodingタイプ(Enhanced-通常解像度に比して高精細な高解像度)でエンコードされるものとする。
【００３８】
図６は、上述のサービスを実現するためのMPDの構成例を示す図である。
【００３９】
図６に示すように、１つのMPD内に、各優先シートから生成される全天球ビューのAdaptationSet（AS-R-B-All）、各優先シートの各アングルビューのAdaptationSet（AS-R-E-ROI/NonROI）、各その他シートから生成される全天球ビューのAdaptationSet（AS-O-B-All）、各その他シートの各アングルビューのAdaptationSet（AS-O-E-ROI/NonROI）を記述することができる。なお、以下の説明では、AdaptationSetは、RepresentationやSubRepresentationに置き換えることもできるものとする。
【００４０】
そして、上述のサービスをコストやトランスポート特性の異なるメディアを利用して配信する場合、ストリーム(AdaptationSet)のメディアへの割り当てが行われる。ここでは、コストやトランスポート特性の異なるメディアとして、例えば、放送およびネットの２種類について説明する。
【００４１】
図７には、優先シートをなるべく放送でプッシュするように放送とネットとを割り当てるポリシーの一例が示されている。
【００４２】
図７に示す例では、レベル１、レベル２、およびレベル３の順に、放送負荷が増大するように放送とネットとが割り当てられている。ここで、優先シートのScope-ALLが通常解像度でエンコードされたコンテンツを第１のストリームとし、その他のシートのViewScope-ALLが通常解像度でエンコードされたコンテンツを第２のストリームとする。また、優先シートのViewScope-ROIが高解像度でエンコードされたコンテンツを第３のストリームとし、その他のシートのViewScope-ROIが高解像度でエンコードされたコンテンツを第４のストリームとする。また、優先シートのViewScope-NonROIが高解像度でエンコードされたコンテンツを第５のストリームとし、その他のシートのViewScope-NonROIが高解像度でエンコードされたコンテンツを第６のストリームとする。
【００４３】
例えば、レベル１では、第１のストリームが放送で配信され、第２乃至第６のストリームがネットで配信される。また、第２のレベルでは、第１および第３のストリームが放送で配信され、第２のストリーム、および第４乃至第６のストリームがネットで配信される。また、第３のレベルでは、第１のストリーム、第３のストリーム、および第５のストリームが放送で配信され、第２のストリーム、第４のストリーム、および第６のストリームがネットで配信される。
【００４４】
また、図８には、ROIアングルビューをなるべく放送でプッシュするように放送とネットとを割り当てるポリシーの一例が示されている。
【００４５】
図８に示す例では、レベル１、レベル２、レベル３、およびレベル４の順に、放送負荷が増大するように放送とネットとが割り当てられている。そして、図７と同様に、第１乃至第６のストリームが、放送またはネットに割り当てられて配信される。
【００４６】
例えば、レベル１では、第１のストリームが放送で配信され、第２乃至第６のストリームがネットで配信される。また、第２のレベルでは、第１および第３のストリームが放送で配信され、第２のストリーム、および第４乃至第６のストリームがネットで配信される。また、第３のレベルでは、第１乃至第３のストリームが放送で配信され、第４乃至第６のストリームが、ネットで配信される。そして、第４のレベルでは、第１乃至第４のストリームが放送で配信され、第５および第６のストリームが、ネットで配信される。
【００４７】
このようなポリシーを参照することで、リソースの割り当てを最適化および効率化することができる。
【００４８】
＜第１のMPD拡張方法＞
上述の配信メディアの割り当てを最適化するためのヒント情報（ポリシー）をMPDに記述できるようにするための、第１のMPD拡張方法について説明する。
【００４９】
例えば、Periodの下に、新たにDistributionPolicy要素（Period下に複数配置可能）を定義する。
【００５０】
DistributionPolicyが持つ要素／属性には、tag、PolicyDistribution、NumLevels、Level[1]AdaptationSetIDs,Level[2]AdaptationSetIDs,…,Level[NumLevels]AdaptationSetIDs、DistributionMediaDependantExtensionがある。
【００５１】
Tagは、DistributionPolicyそのものを識別する文字列（MPD内でユニーク）である。PolicyDistributionは、ポリシーを表現する文字列（ヒント）である。なお、tagおよびPolicyDistributionはオプションである。NumLevelsは、段階を表すレベル数（数値）である。
【００５２】
Level[1]AdaptationSetIDsは、レベル１に属するas-idの列であり、Level[2]AdaptationSetIDsは、レベル２に属するas-idの列であり、以下、同様に、Level[NumLevels]AdaptationSetIDsは、そのレベルに属するas-idの列である。また、オプションとして、レベルごとのビットレート総和（最大MPDをもとに計算して求める）など負荷リソース割り当ての決定に関与しそうなヒントとなりそうな情報を格納できる領域を用意してもよい。
【００５３】
DistributionMediaDependantExtensionは、例えば、どのレベルインデックスのAdaptationSet群まで以下の拡張を適用するかを示すmaxLevelToBeApplied、当該AdaptationSetに追加する要素であるAttributeToBeApplied:"baseURL='/bc'（放送用URLなど）、その他当該DistributionMediaを説明する属性（文字列）などがある。
【００５４】
第１のMPD拡張方法では、このような汎用的なストリームグループ定義スキームが導入される。
【００５５】
そして、DistributionPolicyのレベル（Level[1]、Level[2]…Level[NumLevels]）を選択することで、図９に示すように、放送負荷を軽減または増加させることができる。
【００５６】
例えば、図９では、左側に向かうに従い放送負荷が軽減し、右側に向かうに従い放送負荷が増加するように並べられており、レベル１に属するas-idの列が最も放送負荷が軽く、レベル１およびレベル２に属するas-idの列が次に放送負荷が軽い。このように、レベルが増加するのに伴って、放送負荷が増加する方向となる。
【００５７】
図１０および図１１には、上述の図７および図８を参照して説明した２種類のリソース割り当て例を表現したDistributionPolicy要素の内容が示されている。即ち、図１０には、”Reservedシートをなるべく放送で”の場合におけるDistributionPolicy要素が示されており、図１１には、”ROIアングルをなるべく放送で”の場合におけるDistributionPolicy要素が示されている。
【００５８】
図１０に示すように、Tag：”１”により識別されるDistributionPolicyは、優先シートをなるべく放送（Reserved over Broadcast）で配信するポリシーであり、放送負荷は、レベル１からレベル３の３段階とされる。そして、上述の図７を参照して説明したように、レベル１では、第１のストリームのみが放送で配信され、レベル２では、第１および第３のストリームが放送で配信され、レベル３では、第１のストリーム、第３のストリーム、および第５のストリームが放送で配信される。このように、レベル１では放送負荷が軽く、レベル３では放送負荷が増えるようにリソースが割り当てられる。
【００５９】
図１１に示すように、Tag：”２”により識別されるDistributionPolicyは、ROIアングルをなるべく放送（ROI over Broadcast）で配信するポリシーであり、放送負荷は、レベル１からレベル４の４段階とされる。そして、上述の図８を参照して説明したように、レベル１では、第１のストリームのみが放送で配信され、レベル２では、第１および第３のストリームが放送で配信され、レベル３では、第１乃至第３のストリームが放送で配信され、レベル４では、第１乃至第４のストリームが放送で配信される。このように、このように、レベル１では放送負荷が軽く、レベル４では放送負荷が増えるようにリソースが割り当てられる。
【００６０】
＜DistributionPolicyの具体例とMPD生成例＞
図１２には、MPD内に記述する場合のDistributionPolicyのXML表記の一例が示されている。
【００６１】
また、図１２に示すようなXML表記が基本構造であるが、例えば、各Levelに属性としてオプショナルなResourceSpecificInformation属性を置くことができ、例えば、<Level resourceSpecificInformation='…' … />のように記述することができる。なお、要素として定義することもできる。ここには、Levelごとのビットレート総和等を、負荷リソース割り当ての決定に関与しそうなヒントとなりそうな情報を格納できる領域を用意してもよい。
【００６２】
例えば、ResourceSpecificInformationとして、このLevelに属するAdaptationSet列の最大ビットレートの総和（maxBitRate）を用いる場合には、<Level maxBitRate='そのLevelに属するAdaptationSet列の最大ビットレートの総和値' … />のように記述できるようにする。
【００６３】
また、とあるLevelまでのAdaptationSet要素群に追加すべき要素（Element）、あるいは、属性（Attribute）を定義できるようにする。例えば、放送配信されることになったAdaptationSet要素に対しては、BaseURL='(放送配信であることを示すurlのプリフィクス)'を追加して示すことができる。
【００６４】
従って、このAdaptationSet要素に対する追加分の"BaseURL='(放送配信であることを示すurlのプリフィクス)'"を指示できるようなオプショナルなDistributionMediaDependantExtension要素として、図１３に示すような記述をDistributionPolicyに配置できるようにする。図１３に示す記述は、とあるレベル値までのLevelに含まれるAdaptationSet列に対して、<ElementToBeAppended>要素に格納されている要素が追加されることを意味する。なお、このように簡易な拡張を施すために特別な要素を用意する場合もあれば、XML Query Update等を利用して要素の追加拡張を表現する場合も考えられる。
【００６５】
例えば、図１４に示すように記述されるMPDがある場合、生成されるべき有効なMPDは、図１５に示すように記述される。即ち、図１６に示すように、Level-2までDistributionMediaDependantExtensionであるBaseURL='/bc'を追加することが適用される。
【００６６】
一方、maxLevelToBeApplied属性がないか、あるいは、maxLevelToBeAppliedが0と指定されるとすると、MPDは、図１７に示すように記述される。そして、それが有効となった際に生成されるべきMPDは、図１８に示すように記述される。ここで、このDistributionMediaDependantExtension要素のmaxLevelToBeApplied属性の値は、後述するMPDとは別のデータ構造（イベント、メッセージ、シグナリング等）で有効なMPDを生成する主体に通知することができるようにする。
【００６７】
さらに、別の例として、クライアントが２種類以上の放送ネットワーク（例えば、ATSC放送および3GPP-MBMSネットワーク）と接続されていて、ATSC放送が<BaseURL>/atscBc</BaseURL>で指定され、3GPP-MBMSネットワーが<BaseURL>/3gppBc</BaseURL>で指定されるものとし、それぞれについてリソース割り当てポリシーが異なるような場合、以下のような２種類のDistributionPolicyを持つMPDを定義する。
【００６８】
例えば、MPDが、図１９に示すように記述される場合、ATSC放送のDistributionPolicy@tag='1'についてはmaxLevelToBeAppliedが２までと指定され、かつ、3GPP MBMS放送のDisitributionPolicy@tag='2'についてはmaxLevelToBeAppliedが１までと指定される場合に、生成されるべきMPDは、図２０に示すようになる。
【００６９】
即ち、図２１に示すように、tag=1（ATSC放送の場合に適用）については、Level-2までDistributionMediaDependantExtensionであるBaseURL='/atscBc'を追加することが適用される。同様に、図２２に示すように、tag=2（3GPP放送の場合に適用）についてはLevel-1までDistributionMediaDependantExtensionであるBaseURL='/3gppBc'を追加することが適用される。
【００７０】
＜コンテンツ提供システムの第１の構成例＞
図２３には、コンテンツプロバイダ２１、CDNサービスプロバイダ２２−１および２２−２、並びに、クライアント１３−１および１３−２により構成されるコンテンツ提供システム１１の構成例が示されている。
【００７１】
図２３に示すように、異なるCDNプラットフォームを有するサービスプロバイダ群において配信リソース管理する場合、各CDNの放送または双方向リソースの帯域配分を考慮し、MPD/DistributionPolicyをヒントとして、それぞれのCDNに最適化されたMPDが生成される。
【００７２】
例えば、コンテンツプロバイダ２１のMPDが、図２４の上側に示すように記載されている場合、CDNサービスプロバイダ２２−１は、MPD/DistricutionGroupをヒントとして、図２４の左下側に示すようなMPD’を生成する。同様に、この場合、CDNサービスプロバイダ２２−２は、MPD/DistricutionGroupをヒントとして、図２４の右下側に示すようなMPD’’を生成する。
【００７３】
このとき、CDNサービスプロバイダ２２−１は、MPD’に記述されているように、AS-1を放送トランスポートにより配信するが、放送トランスポートでとりこぼすクライアントを救済するため、双方向配信可能なサーバ上にも、AS-1の若干のコピーを準備する。同様に、CDNサービスプロバイダ２２−２は、MPD’’に記述されているように、AS-1およびAS-2を放送トランスポートにより配信するが、放送トランスポートでとりこぼすクライアントを救済するため、双方向配信可能なサーバ上にも、AS-1およびAS-2の若干のコピーを準備する。
【００７４】
＜コンテンツ提供システムの第２の構成例＞
【００７５】
図２５には、コンテンツプロバイダ２１、CDNセグメントマネジャ３１−１および３１−２を備えるサービスプロバイダ２２Ａ、並びに、クライアント１３−１および１３−２により構成されるコンテンツ提供システム１１Ａの構成例が示されている。
【００７６】
図２５に示すように、3GPP-eMBMSをサポートする配信プラットフォームを有する1つのキャリア（サービスプロバイダ）内で、各eNodeB上のCDNセグメントマネジャ（マルチキャスト/ユニキャストのストリーム割り当て配分を管理するモジュール）が各CDNセグメントの放送/双方向リソースの帯域配分を考慮し、MPD/DistributionPolicyをヒントとして、それぞれのCDNセグメントに最適化されたMPDが生成される。
【００７７】
例えば、コンテンツプロバイダ２１のMPDが、上述した図２４の上側に示すように記載されている場合、CDNセグメントマネジャ３１−１は、MPD/DistricutionGroupをヒントとして、上述した図２４の左下側に示すようなMPD’を生成する。同様に、この場合、CDNセグメントマネジャ３１−２は、MPD/DistricutionGroupをヒントとして、上述した図２４の右下側に示すようなMPD’’を生成する。
【００７８】
このとき、CDNセグメントマネジャ３１−１は、MPD’に記述されているように、AS-1を放送トランスポートにより配信するが、放送トランスポートでとりこぼすクライアントを救済するため、双方向配信可能なサーバ上にも、AS-1の若干のコピーを準備する。同様に、CDNセグメントマネジャ３１−２は、MPD’’に記述されているように、AS-1およびAS-2を放送トランスポートにより配信するが、放送トランスポートでとりこぼすクライアントを救済するため、双方向配信可能なサーバ上にも、AS-1およびAS-2の若干のコピーを準備する。
【００７９】
＜コンテンツ配信処理＞
図２６を参照して、図２３のコンテンツ提供システム１１においてコンテンツを配信するコンテンツ配信処理の一例について説明する。
【００８０】
ステップＳ１０１において、コンテンツプロバイダ２１は、MPDおよびAS（AdaptationSetおよびDASHセグメントの列）を生成し、CDNサービスプロバイダ２２に転送する。
【００８１】
CDNサービスプロバイダ２２のリソースマネジャは、コンテンツプロバイダ２１によりステップＳ１０１で転送されてくるMPDおよびASを受信する。そして、CDNサービスプロバイダ２２のリソースマネジャは、ステップＳ１１１において、放送または双方向配信のリソースを割り当て、MPDを書き換え、MPDおよびASを双方向サーバおよび放送サーバそれぞれに配置して、それらを転送させる。
【００８２】
CDNサービスプロバイダ２２の双方向サーバは、リソースマネジャによりステップＳ１１１でMPDおよびASが配置された後、クライアント１３からMPDの要求があると、ステップＳ１２１において、MPDをクライアント１３に転送する。その後、CDNサービスプロバイダ２２の双方向サーバは、クライアント１３からASの要求があると、ステップＳ１２２において、ASをクライアント１３に転送する。
【００８３】
CDNサービスプロバイダ２２の放送サーバは、リソースマネジャによりMPDおよびASが配置された後、ステップＳ１３１において、MPDをクライアント１３に転送する。その後、CDNサービスプロバイダ２２の放送サーバは、ステップＳ１３２において、ASをクライアント１３に転送する。
【００８４】
クライアント１３の（放送チューナ・ミドルウエアが実装された）ローカルプロキシサーバは、CDNサービスプロバイダ２２の放送サーバによりステップＳ１３１で転送されてくるMPDを取得する。また、クライアント１３のローカルプロキシサーバは、DASHクライアントによるMPDの要求をCDNサービスプロバイダ２２に送信し、その要求に応じて、CDNサービスプロバイダ２２の双方向サーバによりステップＳ１２１で転送されてくるMPDを取得する。そして、クライアント１３のローカルプロキシサーバは、ステップＳ１４１において、放送サーバから取得したMPD、および、双方向サーバから取得したMPDのどちらか一方のMPDをDASHクライアントに転送する。
【００８５】
その後、クライアント１３のローカルプロキシサーバは、CDNサービスプロバイダ２２の放送サーバによりステップＳ１３２で転送されてくるASを取得する。また、クライアント１３のローカルプロキシサーバは、DASHクライアントによるASの要求をCDNサービスプロバイダ２２に送信し、その要求に応じて、CDNサービスプロバイダ２２の双方向サーバによりステップＳ１２２で転送されてくるASを取得する。そして、クライアント１３のローカルプロキシサーバは、ステップＳ１４２において、放送サーバから取得したAS、および、双方向サーバから取得したASのどちらか一方のASをDASHクライアントに転送する。
【００８６】
クライアント１３のDASHクライアントは、ステップＳ１５１において、サービスまたはコンテンツの選択が行われると、その選択されたサービスまたはコンテンツのMPDを要求する。その後、クライアント１３のDASHクライアントは、クライアント１３のローカルプロキシサーバによりステップＳ１４１で転送されたMPDを取得する。
【００８７】
続いて、クライアント１３のDASHクライアントは、ステップＳ１５２において、取得したMPDをパースし、ASを特定して、その特定したASを要求する。その後、クライアント１３のDASHクライアントは、クライアント１３のローカルプロキシサーバによりステップＳ１４２で転送されたASを取得する。そして、クライアント１３のDASHクライアントは、ステップＳ１５３において、取得したASを再生する。
【００８８】
以上のように、コンテンツ提供システム１１では、CDNサービスプロバイダ２２が放送または双方向のトランスポートリソースの割り当てを担うことができる。そして、CDNサービスプロバイダ２２のリソースマネジャにおけるMPDの書き換えにより、トランスポートリソースの割り当てをクライアント１３に通知することができる。
【００８９】
なお、図２５のコンテンツ提供システム１１Ａにおいても、コンテンツ提供システム１１と同様のコンテンツ配信処理が行われ、サービスプロバイダ２２ＡのCDNセグメントマネジャ３１により、放送または双方向のトランスポートリソースの割り当てが行われる。
【００９０】
＜DASH EventによるDistributionPolicyとそのレベルの通知＞
MPEG DASHではDASH Eventと呼ばれるイベント通知機構が定義されており、２種類のEventの転送方法が規定されている。第１のEventの転送方法はMPD Eventであり、第２のEventの転送方法はIn-band Event Signalingである。
【００９１】
例えば、MPD Eventは、DASH-MPDのPeriod単位で、EventStream要素を追加することにより、MPD内にPeriod単位でEvent発火のスケジュールと、それぞれのEvent発火のタイミングでクライアントが処理すべき（クライアント上で稼働するアプリケーション等に渡すべき）イベントデータを記述することができる。
【００９２】
図２７には、一般的なMPD Eventの一例が示されている。
【００９３】
例えば、MPD Eventは、EventStream/@schemeIdUri（とオプショナルなEventStream/@value）属性によりイベントの種類を定義し、EventStream/Event要素のコンテンツパートにイベントデータを付加することができる。即ち、MPD/Period/EventStream/Event要素のコンテンツ部に格納されるEvent関連データのフォーマット（何を格納すべきか）については、EventStream/@schemeIdUri属性の値（以下の例では'urn:xxx'）によって特定（定義）される。例えば、MPD Eventは、MPDの送出前に、MPD内に記述されるPeriodの内容が確定できる場合にのみ適用可能である。
【００９４】
図２８には、In-band Event Signalingの一例が示されている。
【００９５】
In-band Event Signalingは、MP4のブランド名"emsg"box typeを有する"DASHEventMessageBox"と呼ばれるmp4 boxをDASH Segmentに挿入して、セグメントストリームの中（in-stream）で転送する。例えば、In-band Event Signalingの場合は、DASHEventMessageBoxのscheme_id_uriフィールド（とオプショナルなvalueフィールド）にイベントの種類を定義し、message_dataフィールドにイベントデータを付加する。ここで、図２８に示されている"presentation_time_delta = 0"は、このemgsボックスが包含されるセグメントのEarliestPresentationStimeからのオフセットを示し、"event_duration = 0xFFFF "の場合、無限を示している。
【００９６】
そして、これらのDASHEventMessageBoxを、DASHセグメントのbox構造の中に配置する。
【００９７】
例えば、図２８に示すemgs boxを格納するDASH segmentがどのストリーム(AdaptationSet/Representation)に含まれて転送されるかを指定するには、図２９のように、MPDの当該AdaptationSet/Representation要素にInbandEventStream要素が配置される。
【００９８】
以上のように説明したDASH Event（MPD Event、ならびに、In-band Event）により、DistributionPolicyのタグ値"tag"とレベル値"level"を指定して、クライアント側でどのDistributionPolicy定義のどのレベル（DistributionPolicy/DistributionMedia DependantExtension/maxLevelToBeApplied）まで、当該DistributionPolicy /DistributionMediaDependantExtension/ElementToBeAppendedが適用されるかを判断できるようにする。これにより、サーバ側でMPDを書き換えることなく、Event送出のタイミングで動的に配信リソースのストリーム割り当てを構成変更することができるため、粒度の細かなリソース割り当て制御が可能となる。
【００９９】
なお、図３０には、DASH Eventによるポリシー／レベル通知の一例が示されている。
【０１００】
また、MPD EventによりDistributionPolicyのtag+levelを通知する場合、MPD/Period/EventStream@schemeIdUriを"urn:mpeg:dash:event:distributionPolicy"とし、図３１に示すように、MPD/Period/EventStream/Event要素のコンテンツパートに"tag値,level値"のように格納する。
【０１０１】
一方、In-band EventによりDistributionPolicyのtagとlevelを通知する場合、図３２に示すように、emsgボックスのscheme_id_uriフィールドに" urn:mpeg:dash:event: distributionPolicy"を格納し、message_data[]フィールドに"tag値,level値"の文字列を格納し、このemsgボックスが含まれたDASH segmentが配信される可能性のあるRepresentationを、MPD/Period/AdaptationSet/Representation/InbanedEventStream @schemeIdUri=' urn:mpeg:dash:event:distributionPolicy'と指定することによってクライアント側に周知する。
【０１０２】
ここで、emsgボックスは、図３２に示すように記述される。そして、上述したIn-band Eventが抽出される可能性のあるAdaptationSet/Representationを指定するためのMPDは、図３３に示すように記述される。
【０１０３】
＜コンテンツ提供システムの第３の構成例＞
【０１０４】
図３４には、コンテンツプロバイダ２１、CDNセグメントマネジャ３１−１および３１−２を備えるCDNサービスプロバイダ２２Ｂ、並びに、クライアント１３−１および１３−２により構成されるコンテンツ提供システム１１Ｂの第３の構成例が示されている。
【０１０５】
図３４に示すコンテンツ提供システム１１Ｂでは、各CDNセグメントマネジャ３１がDistributionPolicyを含むMDPをクライアント１３に送付して、クライアント１３において、いずれかのAdaptationSet内のDASH Event（in-band event）を検知して、それぞれのCDNセグメントに最適化されたMPDが動的に生成される。このように、DASH Eventによる動的なMDPの生成を実現するためのDASH Eventの拡張について説明する。
【０１０６】
例えば、コンテンツプロバイダ２１のMPDは、図３５の上側に示すように記述される。そして、CDNセグメントマネジャ３１のMPDは、図３５の下側に示すように、DistributionPolicyと、別途シグナルされるDistributionPolicy@tag値+Level値により、クライアント１３側において、MPDを再構成できるようにする。そして、CDNセグメントマネジャ３１は、MPDは書き換えずにMPD Eventにて、クライアント１３に動的に周知する。
【０１０７】
このとき、CDNセグメントマネジャ３１−１は、MPDに記述されているように、AS-1を放送トランスポートにより配信するが、放送トランスポートでとりこぼすクライアントを救済するため、双方向配信可能なサーバ上にも、AS-1の若干のコピーを準備する。同様に、CDNセグメントマネジャ３１−２は、MPDに記述されているように、AS-1およびAS-2を放送トランスポートにより配信するが、放送トランスポートでとりこぼすクライアントを救済するため、双方向配信可能なサーバ上にも、AS-1およびAS-2の若干のコピーを準備する。
【０１０８】
そして、図３６に示すように、CDNセグメントマネジャ３１−１の、いずれかのASのDASHセグメント内のIn-band Eventが、MPD Eventにてクライアント１３−１に、動的に周知される。そして、クライアント１３−１が、Level値をもとにMPD’を生成する。
【０１０９】
同様に、図３７に示すように、CDNセグメントマネジャ３１−２の、いずれかのASのDASHセグメント内のIn-band Eventが、MPD Eventにてクライアント１３−２に、動的に周知される。そして、クライアント１３−２が、Level値をもとにMPD’’を生成する
【０１１０】
＜コンテンツ配信処理＞
図３８乃至図４３を参照して、図３４のコンテンツ提供システム１１Ｂにおいてコンテンツを配信するコンテンツ配信処理の一例について説明する。
【０１１１】
図３８のステップＳ２０１において、コンテンツプロバイダ２１は、MPDおよびASを生成し、CDNサービスプロバイダ２２Ｂに転送する。
【０１１２】
図３８のステップＳ２１１において、CDNサービスプロバイダ２２Ｂのリソースマネジャは、双方向配信のリソースを割り当て、DistributionPolicy付きのMPDおよびASを双方向サーバに配置して、それらを転送させる。ステップＳ２１２において、CDNサービスプロバイダ２２Ｂのリソースマネジャは、放送または双方向配信のリソースを割り当て、In-band EventをAS（N-1）へ挿入し、AS（N以降）を双方向サーバおよび放送サーバそれぞれに配置転換して、それらを転送させる。
【０１１３】
同様に、図３９のステップＳ２１３において、CDNサービスプロバイダ２２Ｂのリソースマネジャは、放送または双方向配信のリソースを割り当て、In-band EventをAS（M-1）へ挿入し、AS（M以降）を双方向サーバおよび放送サーバそれぞれに配置転換して、それらを転送させる。
【０１１４】
CDNサービスプロバイダ２２Ｂの双方向サーバは、リソースマネジャによりステップＳ２１１でDistributionPolicy付きのMPDおよびASが配置された後、クライアント１３からMPDの要求があると、図３８のステップＳ２２１において、MPDをクライアント１３に転送する。その後、CDNサービスプロバイダ２２Ｂの双方向サーバは、クライアント１３からASの要求があると、ステップＳ２２２において、ASをクライアント１３に転送する。また、CDNサービスプロバイダ２２Ｂの双方向サーバは、リソースマネジャによりステップＳ２１２でAS（N以降）が配置転換された後、クライアント１３からASの要求があると、ステップＳ２２３において、AS（N-1）をクライアント１３に転送する。
【０１１５】
同様に、CDNサービスプロバイダ２２Ｂの双方向サーバは、クライアント１３からASの要求があると、図３９のステップＳ２２４において、AS（N）をクライアント１３に転送する。その後、CDNサービスプロバイダ２２Ｂの双方向サーバは、リソースマネジャによりAS（M以降）が配置転換された後、クライアント１３からAS（M-1）の要求があると、ステップＳ２２５において、AS（M-1）をクライアント１３に転送する。さらに、CDNサービスプロバイダ２２Ｂの双方向サーバは、クライアント１３からAS（M）の要求があると、ステップＳ２２６において、AS（M）をクライアント１３に転送する。
【０１１６】
CDNサービスプロバイダ２２Ｂの放送サーバは、リソースマネジャによりステップＳ２１２でAS（N以降）が配置転換された後、図３９のステップＳ２３１において、AS（N）をクライアント１３に転送する。その後、CDNサービスプロバイダ２２Ｂの放送サーバは、リソースマネジャによりステップＳ２１３でAS（M以降）が配置転換された後、ステップＳ２３２において、AS（M-1）をクライアント１３に転送する。
【０１１７】
クライアント１３のローカルプロキシサーバは、DASHクライアントによるMPDの要求をCDNサービスプロバイダ２２Ｂに送信し、その要求に応じて、CDNサービスプロバイダ２２Ｂの双方向サーバによりステップＳ２２１で転送されてくるMPDを取得する。そして、クライアント１３のローカルプロキシサーバは、ステップＳ２４１において、MPDをDASHクライアントに転送する。また、クライアント１３のローカルプロキシサーバは、DASHクライアントによるASの要求をCDNサービスプロバイダ２２Ｂに送信し、その要求に応じて、CDNサービスプロバイダ２２Ｂの双方向サーバによりステップＳ２２２で転送されてくるASを取得する。そして、クライアント１３のローカルプロキシサーバは、ステップＳ２４２において、ASをDASHクライアントに転送する。
【０１１８】
また、クライアント１３のローカルプロキシサーバは、DASHクライアントによるAS後続セグメント（N-1）の要求をCDNサービスプロバイダ２２Ｂに送信し、その要求に応じて、CDNサービスプロバイダ２２Ｂの双方向サーバによりステップＳ２２３で転送されてくるAS（N-1）を取得する。そして、クライアント１３のローカルプロキシサーバは、ステップＳ２４３において、AS（N-1）をDASHクライアントに転送する。
【０１１９】
以下、同様に、クライアント１３のローカルプロキシサーバは、図３９のステップＳ２４４においてAS（N）をDASHクライアントに転送し、ステップＳ２４５においてAS（M-1）をDASHクライアントに転送し、ステップＳ２４６において、AS（M）をDASHクライアントに転送する。
【０１２０】
クライアント１３のDASHクライアントは、ステップＳ２５１において、サービスまたはコンテンツの選択が行われると、その選択されたサービスまたはコンテンツのMPDを要求する。その後、クライアント１３のDASHクライアントは、CDNサービスプロバイダ２２Ｂの双方向サーバによりステップＳ２２１で転送されたMPD、即ち、クライアント１３のローカルプロキシサーバによりステップＳ２４１で転送されたMPDを取得する。
【０１２１】
続いて、クライアント１３のDASHクライアントは、ステップＳ２５２において、取得したMPDをパースし、ASを特定して、その特定したASを要求する。なお、パースされたMPDの一例が、図４０に示されている。
【０１２２】
その後、クライアント１３のDASHクライアントは、CDNサービスプロバイダ２２の双方向サーバによりステップＳ２２２で転送されたAS、即ち、クライアント１３のローカルプロキシサーバによりステップＳ２４２で転送されたASを取得する。そして、クライアント１３のDASHクライアントは、ステップＳ２５３において、取得したASを再生する。
【０１２３】
さらに、クライアント１３のDASHクライアントは、ステップＳ２５４において、AS後続セグメント（N-1）を要求する。その後、クライアント１３のDASHクライアントは、CDNサービスプロバイダ２２の双方向サーバによりステップＳ２２３で転送されたAS（N-1）、即ち、クライアント１３のローカルプロキシサーバによりステップＳ２４３で転送されたAS（N-1）を取得する。そして、クライアント１３のDASHクライアントは、ステップＳ２５５において、取得したAS（N-1）を再生する。
【０１２４】
そして、クライアント１３のDASHクライアントは、ステップＳ２５６において、In-band Eventを検出し、MPDを再構成する。なお、検出されたIn-band Event、および、再構成されたMPDの一例が、図４１に示されている。
【０１２５】
以下、同様に、クライアント１３のDASHクライアントは、図３９のステップＳ２５７において、MPDをパースし、セグメント（N）を特定して、その特定したAS（N）を要求し、ステップＳ２５８においてAS（N）を再生する。なお、ステップＳ２５７でパースされたMPDの一例が、図４２に示されている。
【０１２６】
また、同様に、クライアント１３のDASHクライアントは、ステップＳ２５９において、AS後続セグメント（M-1）を要求し、ステップＳ２６０においてAS（M-1）を再生する。さらに、同様に、クライアント１３のDASHクライアントは、ステップＳ２６１において、In-band Eventを検出し、MPDを再構成し、ステップＳ２６２において、MPDをパースし、セグメント（M）を特定して、その特定したAS（M）を要求し、ステップＳ２６３において、AS（M）を再生する。なお、検出されたIn-band Event、および、再構成されたMPDの一例が、図４３に示されている。
【０１２７】
以上のように、コンテンツ提供システム１１Ｂでは、CDNサービスプロバイダ２２ＢのCDNセグメントマネジャ３１がDistributionPolicyを含むMDPをクライアント１３に送付する。そして、クライアント１３は、いずれかのAdaptationSet内のDASH Event（in-band event）を検知して、それぞれのCDNセグメントに最適化されたMPDを動的に生成することができる。
【０１２８】
＜コンテンツ配信処理＞
図４４乃至図４９を参照して、図３４のコンテンツ提供システム１１Ｂにおいてコンテンツを配信するコンテンツ配信処理の他の例について説明する。
【０１２９】
上述の図３７および図３８のフローチャートを参照して説明したコンテンツ配信処理においては、DASHクライアントが、放送チューナ・ミドルウエアが実装されたローカルプロキシサーバから、ネットワークの違い（放送か、ネットか）を意識せずに、セグメントを取得することができる。その他、例えば、このようなローカルプロキシサーバを介さずに処理を行ってもよい。
【０１３０】
また、CDNサービスプロバイダ２２は、上述したような放送サーバを備えるのではなく、２つの双方向サーバを備える構成とすることができる。例えば、第１の双方向サーバおよび第２の双方向サーバには、それぞれ異なるＩＰアドレスがアサインされており、例えば、第１の双方向サーバ提供されるセグメントのurlはNo.1から始まり、第２の双方向サーバ提供されるセグメントのurlはNo.2から始まるものとする。
【０１３１】
図４４のステップＳ３０１において、コンテンツプロバイダ２１は、MPDおよびASを生成し、CDNサービスプロバイダ２２Ｂに転送する。
【０１３２】
図４４および図４５のステップＳ３１１乃至Ｓ３１３において、CDNサービスプロバイダ２２Ｂのリソースマネジャは、図３８および図３９のステップＳ２１１乃至Ｓ２１３と同様の処理を行う。
【０１３３】
CDNサービスプロバイダ２２Ｂの第１の双方向サーバは、リソースマネジャによりステップＳ３１１でDistributionPolicy付きのMPDおよびASが配置された後、クライアント１３からMPDの要求があると、図４４のステップＳ３２１において、MPDをクライアント１３に転送する。続いて、CDNサービスプロバイダ２２Ｂの第１の双方向サーバは、クライアント１３からASの要求があると、ステップＳ３２２において、ASをクライアント１３に転送する。また、CDNサービスプロバイダ２２Ｂの第１の双方向サーバは、リソースマネジャによりステップＳ３１２でAS（N以降）が配置転換された後、クライアント１３からASの要求があると、ステップＳ３２３において、AS（N-1）をクライアント１３に転送する。
【０１３４】
その後、CDNサービスプロバイダ２２Ｂの第１の双方向サーバは、リソースマネジャによりAS（M以降）が配置転換された後、クライアント１３からAS（M）の要求があると、ステップＳ３２４において、AS（M）をクライアント１３に転送する。
【０１３５】
CDNサービスプロバイダ２２Ｂの第２の双方向サーバは、リソースマネジャによりステップＳ３１２でAS（N以降）が配置転換された後、クライアント１３からAS（N）の要求があると、ステップＳ３３１において、AS（N）をクライアント１３に転送する。その後、CDNサービスプロバイダ２２Ｂの第２の双方向サーバは、リソースマネジャによりステップＳ３１３でAS（M以降）が配置転換された後、クライアント１３からAS（M-1）の要求があると、ステップＳ３３２において、AS（M-1）をクライアント１３に転送する。
【０１３６】
クライアント１３のDASHクライアントは、ステップＳ３５１において、サービスまたはコンテンツの選択が行われると、その選択されたサービスまたはコンテンツのMPDをCDNサービスプロバイダ２２Ｂの第１の双方向サーバに要求する。その後、クライアント１３のDASHクライアントは、CDNサービスプロバイダ２２Ｂの第１の双方向サーバによりステップＳ３２１で転送されたMPDを取得する。
【０１３７】
続いて、クライアント１３のDASHクライアントは、ステップＳ３５２において、取得したMPDをパースし、ASを特定して、その特定したASを要求する。なお、パースされたMPDの一例が、図４６に示されている。
【０１３８】
その後、クライアント１３のDASHクライアントは、CDNサービスプロバイダ２２の第１の双方向サーバによりステップＳ３２２で転送されたASを取得する。そして、クライアント１３のDASHクライアントは、ステップＳ３５３において、取得したASを再生する。
【０１３９】
さらに、クライアント１３のDASHクライアントは、ステップＳ３５４において、AS後続セグメント（N-1）をCDNサービスプロバイダ２２Ｂの第１の双方向サーバに要求する。その後、クライアント１３のDASHクライアントは、CDNサービスプロバイダ２２の第１の双方向サーバによりステップＳ３２３で転送されたAS（N-1）を取得する。そして、クライアント１３のDASHクライアントは、ステップＳ３５５において、取得したAS（N-1）を再生する。
【０１４０】
そして、クライアント１３のDASHクライアントは、ステップＳ３５６において、In-band Eventを検出し、MPDを再構成する。なお、検出されたIn-band Event、および、再構成されたMPDの一例が、図４７に示されている。ここで、図４７に示すように、再構成されたMPDに、/BaseURL='No.2'と記述されていることより、CDNサービスプロバイダ２２Ｂの第２の双方向サーバからの取得も可能となる。
【０１４１】
従って、クライアント１３のDASHクライアントは、図４５のステップＳ３５７において、MPDをパースし、セグメント（N）を特定して、その特定したAS（N）をCDNサービスプロバイダ２２Ｂの第２の双方向サーバに要求する。そして、クライアント１３のDASHクライアントは、CDNサービスプロバイダ２２Ｂの第２の双方向サーバによりステップＳ３３１で転送されたAS（N）を取得し、ステップＳ３５８においてAS（N）を再生する。なお、ステップＳ３５７でパースされたMPDの一例が、図４８に示されている。
【０１４２】
また、クライアント１３のDASHクライアントは、ステップＳ３５９において、AS後続セグメント（M-1）をCDNサービスプロバイダ２２Ｂの第２の双方向サーバに要求する。その後、クライアント１３のDASHクライアントは、CDNサービスプロバイダ２２の第２の双方向サーバによりステップＳ３３２で転送されたAS（M-1）を取得する。そして、クライアント１３のDASHクライアントは、ステップＳ３６０において、取得したAS（N-1）を再生する。
【０１４３】
さらに、クライアント１３のDASHクライアントは、ステップＳ３６１において、In-band Eventを検出し、MPDを再構成し、ステップＳ３６２において、MPDをパースし、セグメント（M）を特定して、その特定したAS（M）をCDNサービスプロバイダ２２の第１の双方向サーバに要求する。その後、クライアント１３のDASHクライアントは、CDNサービスプロバイダ２２の第１の双方向サーバによりステップＳ３２４で転送されたAS（M）を取得する。そして、クライアント１３のDASHクライアントは、ステップＳ３６３において、取得したAS（M）を再生する。
【０１４４】
なお、検出されたIn-band Event、および、再構成されたMPDの一例が、図４９に示されている。ここで、図４９に示すように、再構成されたMPDに、/BaseURL='No.1のみが記述されていることより、CDNサービスプロバイダ２２Ｂの第１の双方向サーバからしか取得することができないようになっている。
【０１４５】
以上のように、コンテンツ提供システム１１Ｂでは、例えば、図３７および図３８のコンテンツ配信処理よりもシンプルに、コンテンツ配信処理を行うことができる。
【０１４６】
＜MPD拡張のバリエーション＞
図５０および図５１を参照して、MPD拡張のバリエーションについて説明する。
【０１４７】
例えば、図５１に示すように、各AdaptationSet要素の配下に、SupplementalProperty要素を配置できるようにし、SupplementalProperty @schemeIdUri属性値を" urn:mpeg:dash:event:distributionPolicy"とし、value属性値として、"(tag=値),(policyDescription=値),(level=値),(attributeToBeAppended=値), (attributeToBeAppended=値), ..."のように記述できるようにする。
【０１４８】
この意味するところは、当該AdaptationSetは、tag値で示されるDistributionPolicyのlevel（level値で示される）に属しており、そのDistributionPolicyのPolicyDescriptionがpolicyDescription値であり、このDistributionPolicy.level （maxLevelToBeApplied）が適用された暁には、複数のattributeToBeAppended値に示される追加が当該AdaptationSet要素に反映されることを示す。各々のattributeToBeAppendedには、例えば、<!CDATA[<BaseURL>/bc</BaseURL>]]>のように適当な記載方法で追加されるべき要素を記載する。
【０１４９】
また、図５１には、図５０に示したMPDの記述と等価な表現が示されている。
【０１５０】
＜DASH-SANDの拡張＞
図５２乃至図６０を参照して、DASH-SANDの拡張について説明する。
【０１５１】
上述の図２７を参照して説明したようにMPD内に定義されたDistributionPolicyに対して、どのレベルを適用してMPDを再構成するかを示すために、DASH Eventを利用することができる。この他、例えば、クライアント側またはサーバ側でMPDを再構成することができるように、DASH-SANDを利用してDistributionPollicyとそのlevelを通知することができる。
【０１５２】
例えば、SANDにおいては、図５２および図５３に示すように、DANE（DASH Aware Network Element）と呼ばれるDASHプロトコルを理解してDASHストリーミングを最適化する機能を持つネットワークコンポーネント/サーバと、それらとDASHクライアントがやりとりするメッセージングインターフェイスが定義されている。
【０１５３】
また、図５３に示すように、DANE間でやりとりされるメッセージであるPEDについては、現行のDASH-SANDにはインタフェースの界面（PED: Parameter Enhancing Distribution）が存在することのみが定義されていて、具体的なメッセージはまだ定義されていない。
【０１５４】
さらに、DASHクライアントが利用するMPDとメディアセグメントはWebサーバによりHTTPを介して提供されるが、図５４に示すように、SANDのメッセージについては、そのHTTPトランザクションとは別のパスでやり取りされる。
【０１５５】
例えば、図５５は、DASHクライアントにおける処理の流れを示しているが、MPDとメディアセグメントは、ストリーミングの再生そのものに利用される一方、SANDは、DASHストリーミングの最適化という用途に利用される。
【０１５６】
ここで、図５６に示すように、コンテンツプロバイダが提供する（上流側）DANEと、サービスプロバイダが提供する（下流側）DANEを想定する。なお、それぞれのコンテンツプロバイダ内もしくはサービスプロバイダ内におけるDANEは複数で構成される場合もある。
【０１５７】
例えば、DANE間のPEDメッセージ、もしくは、DANEからDASHクライアントへのPERメッセージとして、MPDUpdateDirectiveメッセージを導入する。
【０１５８】
MPDUpdateDirectiveメッセージは、修正対象のMPDに対してその中身の更新方法を記述する要素を持つメッセージである。MPDUpdateDirectiveメッセージのルート要素であるMPDUpdateDirective要素は、オプショナルな属性としてmpdUriReferenceを持ち、対象のMPDインスタンスのURIを指定できるようにする。その子要素に、複数のDistributionPolicyChange要素を持ち、DistributionPolicyChange要素は、その属性としてオプショナルなPolicyReference属性を持ち、対象のDistributionPolicyのtag値を指定できるようにする。さらに、オプショナルなDistiributionPolicy要素（先に説明したMPD/Period/DistributionPolicy要素そのもの）と、LevelChange要素を持つ。LevelChange要素は、更新するlevel値を属性として格納できるようにする。
【０１５９】
そして、SANDのMPDUpdateDirectiveメッセージは、例えば、図５７に示す例のようなHTTP-POSTにて転送される。
【０１６０】
図５８には、MPDUpdateDirectiveフラグメントのインスタンスの第１の記述例が示されている。例えば、MPDがDistributionPolicy要素を含まないとき、このMPDを再構成する場合に適用するDistributionPolicyとレベルを、図５８に示すようなMPDUpdateDirectiveフラグメントにより指示できるようにする。
【０１６１】
図５９には、MPDUpdateDirectiveフラグメントのインスタンスの第２の記述例が示されている。例えば、MPDがDistributionPolicy要素を含まないとき、このMPDを再構成する場合に適用する２つのDistributionPolicyとそれぞれのレベルを、図５９に示すようなMPDUpdateDirectiveフラグメントにより指示できるようにする。
【０１６２】
図６０には、MPDUpdateDirectiveフラグメントのインスタンスの第３の記述例が示されている。例えば、MPDが１つのDistributionPolicy要素を含むとき、このMPDを再構成する場合に適用するDistributionPolicyとレベルを、図６０に示すようなMPDUpdateDirectiveフラグメントにより指示できるようにする。
【０１６３】
図６１には、MPDUpdateDirectiveフラグメントのインスタンスの第４の記述例が示されている。例えば、MPDが2つのDistributionPolicy要素を含むとき、このMPDを再構成する場合に適用するそれぞれのDistributionPolicyとレベルを、図６１に示すようなMPDUpdateDirectiveフラグメントにより指示できるようにする。
【０１６４】
なお、すべてのSANDメッセージには、SANDメッセージインスタンスを識別するmessageIdが属性として付与されるため、MPDUpdateDirective要素の属性としてmessageIdが追加される。
【０１６５】
＜コンテンツ配信処理＞
図６２乃至図６９を参照して、SAND-PEDとして転送されるMPDUpdateDirectiveを用いたコンテンツ配信処理の一例について説明する。
【０１６６】
図６２のステップＳ４０１において、コンテンツプロバイダ２１は、MPDおよびASを生成し、CDNサービスプロバイダ２２Ｂに転送する。
【０１６７】
図３８のステップＳ４１１において、CDNサービスプロバイダ２２のリソースマネジャ上流側DANEは、放送または双方向配信のリソースを割り当て、DistributionPolicy付きのMPDおよびASを双方向サーバおよび放送サーバに配置して、それらを転送させる。ステップＳ４１２において、CDNサービスプロバイダ２２のリソースマネジャ上流側DANEは、放送または双方向配信のリソースを割り当て、MPDUpdateDirectiveのSAND-PEDを通知し、AS（N以降）を双方向サーバに配置転換して、それらを転送させる。
【０１６８】
同様に、図６３のステップＳ４１３において、CDNサービスプロバイダ２２のリソースマネジャ上流側DANEは、放送または双方向配信のリソースを割り当て、MPDUpdateDirectiveのSAND-PEDを通知し、AS（M以降）を双方向サーバに配置転換して、それらを転送させる。
【０１６９】
CDNサービスプロバイダ２２の双方向サーバは、リソースマネジャによりステップＳ４１１でDistributionPolicy付きのMPDおよびASが配置された後、クライアント１３からMPDの要求があると、図６２のステップＳ４２１において、MPDをクライアント１３に転送する。その後、CDNサービスプロバイダ２２の双方向サーバは、クライアント１３からASの要求があると、ステップＳ４２２において、ASをクライアント１３に転送する。また、CDNサービスプロバイダ２２の双方向サーバは、リソースマネジャによりステップＳ４１２でAS（N以降）が配置転換された後、クライアント１３からMPDUpdateDirective SAND-PEDの要求があると、ステップＳ４２３において、MPDUpdateDirective SAND-PEDをクライアント１３に転送する。なお、MPDUpdateDirectiveの一例が、図６５に示されている。そして、CDNサービスプロバイダ２２の双方向サーバは、クライアント１３からASの要求があると、ステップＳ４２４において、AS（N-1）をクライアント１３に転送する。
【０１７０】
同様に、CDNサービスプロバイダ２２の双方向サーバは、クライアント１３からAS（N）の要求があると、ステップＳ４２５において、AS（N）をクライアント１３に転送する。その後、CDNサービスプロバイダ２２の双方向サーバは、リソースマネジャによりAS（M以降）が配置転換された後、クライアント１３からMPDUpdateDirectiveの要求があると、ステップＳ４２６において、MPDUpdateDirectiveをクライアント１３に転送する。なお、転送されるMPDUpdateDirectiveの一例が、図６８に示されている。
【０１７１】
さらに、CDNサービスプロバイダ２２の双方向サーバは、クライアント１３からAS後続セグメント（M-1）の要求があると、ステップＳ４２７において、AS（M-1）をクライアント１３に転送する。そして、CDNサービスプロバイダ２２の双方向サーバは、クライアント１３からAS後続セグメント（M）の要求があると、ステップＳ４２８において、AS（M）をクライアント１３に転送する。
【０１７２】
CDNサービスプロバイダ２２の放送サーバは、リソースマネジャによりステップＳ４１１でDistributionPolicy付きのMPDおよびASが配置された後、図６２のステップＳ４３１において、MPDをクライアント１３に転送する。その後、CDNサービスプロバイダ２２の双方向サーバは、ステップＳ４３２において、AS（N）をクライアント１３に転送し、ステップＳ４４３において、AS（M-1）クライアント１３に転送する。
【０１７３】
クライアント１３のローカルプロキシサーバ下流側DANEは、CDNサービスプロバイダ２２の放送サーバからステップＳ４３１で転送されてくるMPDを取得する。そして、クライアント１３のローカルプロキシサーバ下流側DANEは、DASHクライアントによるMPDの要求をCDNサービスプロバイダ２２に送信し、その要求に応じて、CDNサービスプロバイダ２２の双方向サーバによりステップＳ４２１で転送されてくるMPDを取得する。そして、クライアント１３のローカルプロキシサーバ下流側DANEは、ステップＳ４４１において、放送サーバから取得したMPD、および、双方向サーバから取得したMPDのどちらか一方のMPDをDASHクライアントに転送する。
【０１７４】
また、クライアント１３のローカルプロキシサーバ下流側DANEは、DASHクライアントによるASの要求をCDNサービスプロバイダ２２に送信し、その要求に応じて、CDNサービスプロバイダ２２の双方向サーバによりステップＳ４２２で転送されてくるASを取得する。そして、クライアント１３のローカルプロキシサーバ下流側DANEは、ステップＳ４４２において、ASをDASHクライアントに転送する。
【０１７５】
クライアント１３のローカルプロキシサーバ下流側DANEは、ステップＳ４４３において、MPDUpdateDirective SAND-PEDをCDNサービスプロバイダ２２に要求し、その要求に応じて、CDNサービスプロバイダ２２の双方向サーバによりステップＳ４２３で転送されてくるMPDUpdateDirective SAND-PEDを取得する。また、クライアント１３のローカルプロキシサーバ下流側DANEは、DASHクライアントによるAS後続セグメント（N-1）の要求をCDNサービスプロバイダ２２に送信し、その要求に応じて、CDNサービスプロバイダ２２の双方向サーバによりステップＳ４２４で転送されてくるAS（N-1）を取得する。
【０１７６】
そして、クライアント１３のローカルプロキシサーバ下流側DANEは、ステップＳ４４４において、MPDを再構成し、MPDUpdateEventをセグメントへ挿入する。なお、再構成されたMPDの一例が、図６６に示されている。クライアント１３のローカルプロキシサーバ下流側DANEは、ステップＳ４４５において、AS（N-1）をDASHクライアントに転送する。その後、クライアント１３のローカルプロキシサーバ下流側DANEは、DASHクライアントからMPDが要求されると、ステップＳ４６６において、ステップＳ４４４で再構成した後のMPDをDASHクライアントに転送する。
【０１７７】
以下、同様に、クライアント１３のローカルプロキシサーバ下流側DANEは、ステップＳ４４７において、AS（N）をDASHクライアントに転送し、ステップＳ４４８において、MPDUpdateDirectiveをCDNサービスプロバイダ２２に要求する。さらに、クライアント１３のローカルプロキシサーバ下流側DANEは、ステップＳ４４９において、MPDを再構成し、MPDUpdateEventをセグメントへ挿入し、ステップＳ４５０において、AS（M-1）をDASHクライアントに転送する。なお、再構成されたMPDの一例が、図６９に示されている。
【０１７８】
そして、クライアント１３のローカルプロキシサーバ下流側DANEは、ステップＳ４５１において、ステップＳ４４９で再構成した後のMPDをDASHクライアントに転送し、ステップＳ４５２において、AS（M）をDASHクライアントに転送する。
【０１７９】
クライアント１３のDASHクライアントは、ステップＳ４６１において、サービスまたはコンテンツの選択が行われると、その選択されたサービスまたはコンテンツのMPDを要求する。その後、クライアント１３のDASHクライアントは、クライアント１３のローカルプロキシサーバ下流側DANEによりステップＳ４４１で転送されたMPDを取得する。
【０１８０】
続いて、クライアント１３のDASHクライアントは、ステップＳ４６２において、取得したMPDをパースし、ASを特定して、その特定したASを要求する。なお、パースされたMPDの一例が、図６４に示されている。
【０１８１】
その後、クライアント１３のDASHクライアントは、CDNサービスプロバイダ２２の双方向サーバによりステップＳ４２２で転送されたAS、および、クライアント１３のローカルプロキシサーバ下流側DANEによりステップＳ４４２で転送されたASを取得する。そして、クライアント１３のDASHクライアントは、ステップＳ４６３において、取得したASを再生する。
【０１８２】
さらに、クライアント１３のDASHクライアントは、ステップＳ４６４において、AS後続セグメント（N-1）を要求する。その後、クライアント１３のDASHクライアントは、CDNサービスプロバイダ２２の双方向サーバによりステップＳ４２４で転送されたAS（N-1）、即ち、クライアント１３のローカルプロキシサーバ下流側DANEによりステップＳ４４５で転送されたAS（N-1）を取得する。そして、クライアント１３のDASHクライアントは、ステップＳ４６５において、取得したAS（N-1）を再生する。
【０１８３】
そして、クライアント１３のDASHクライアントは、ステップＳ４６６において、In-band Eventを検出し、MPDを要求する。そして、クライアント１３のローカルプロキシサーバ下流側DANEによりステップＳ４４６で転送されてくるMPDを取得する。
【０１８４】
以下、同様に、クライアント１３のDASHクライアントは、図６３のステップＳ４６７において、MPDをパースし、セグメント（N）を特定して、その特定したAS（N）を要求し、ステップＳ４６８においてAS（N）を再生する。なお、ステップＳ４６７でパースされたMPDの一例が、図６７に示されている。
【０１８５】
また、同様に、クライアント１３のDASHクライアントは、ステップＳ４６９において、AS後続セグメント（M-1）を要求し、ステップＳ４７０においてAS（M-1）を再生する。さらに、同様に、クライアント１３のDASHクライアントは、ステップＳ４７１において、In-band Eventを検出し、MPDを要求する。そして、クライアント１３のローカルプロキシサーバ下流側DANEによりステップＳ４５１で転送されてくるMPDを取得する。クライアント１３のDASHクライアントは、ステップＳ４７１において、In-band Eventを検出して、MPDを要求し、ステップＳ４７２において、MPDをパースし、セグメント（M）を特定して、その特定したセグメント（M）を要求し、ステップＳ４７３において、AS（M）を再生する。なお、再構成されたMPDの一例が、図６９に示されている。
【０１８６】
以上のように、サービスプロバイダ（もしくは、サービスプロバイダ内のCDNセグメントマネジャ）が放送/双方向トランスポートリソースの割り当てを担う場合で、リソースマネジャにおいてMPDは書き換えずに、SAND-PEDとして転送されるMPDUpdateDirectiveにより、トランスポートリソースの割り当てをクライアント側に通知し、クライアント側でMPDを再構成することができる。
【０１８７】
＜放送系のシグナリング拡張＞
図７０乃至図７４を参照して、放送系のシグナリング拡張について説明する。
【０１８８】
上述の図２７を参照して説明したように、MPD内に定義されたDistributionPolicyに対して、どのレベルを適用してMPDを再構成するかを示すために、DASH Eventを利用することができる。これに対し、例えば、DASH Eventを利用しないで、クライアント側でのMPDの再構成を促す方法を別途定義することができる。
【０１８９】
例えば、ATSCや3GPP-MBMS放送環境において、DASH Eventを利用せずに、上述のような機能を実現するために、それぞれのサービスレイヤーシグナリングプロトコルを拡張して、DistributionPollicyとそのlevelを通知できるようにする。
【０１９０】
即ち、図７０に示すように、ATSC3.0では、サービルレイヤーシグナリング(SLS:Service Layer Signaling)のシグナリングフラグメント(XML)により、クライアントに対して、そのシグナリングが配送された時点で有効なMPDを伝えることができる。そして、ここでは、新たなシグナリングフラグメントとしてMPDUpdateDirectiveフラグメントを導入する。
【０１９１】
例えば、MPDUpdateDirectiveフラグメントは、その時点で有効なMPDに対してその中身の更新方法を記述する要素である。MPDUpdateDirectiveフラグメントのルート要素であるMPDUpdateDirective要素は、オプショナルな属性としてmpdUriReferenceを持ち、対象のMPDインスタンスのURIを指定できるようにする。その子要素に、複数のDistributionPolicyChange要素を持ち、DistributionPolicyChange要素は、その属性としてオプショナルなPolicyReference属性を持ち、対象のDistributionPolicyのtag値を指定できるようにする。さらに、オプショナルなDistiributionPolicy要素（先に説明したMPD/Period/DistributionPolicy要素そのもの）と、LevelChange要素を持つ。LevelChange要素は、更新するlevel値を属性として格納できるようにする。
【０１９２】
図７１には、MPDUpdateDirectiveフラグメントのインスタンスの第１の記述例が示されている。例えば、MPDがDistributionPolicy要素を含まないとき、このMPDを再構成する場合に適用するDistributionPolicyとレベルを、図７１に示すようなMPDUpdateDirectiveフラグメントにより指示できるようにする。
【０１９３】
図７２には、MPDUpdateDirectiveフラグメントのインスタンスの第２の記述例が示されている。例えば、MPDがDistributionPolicy要素を含まないとき、このMPDを再構成する場合に適用する２つのDistributionPolicyとそれぞれのレベルを、図７２に示すようなMPDUpdateDirectiveフラグメントにより指示できるようにする。
【０１９４】
図７３には、MPDUpdateDirectiveフラグメントのインスタンスの第３の記述例が示されている。例えば、MPDが１つのDistributionPolicy要素を含むとき、このMPDを再構成する場合に適用するDistributionPolicyとレベルを、図７３に示すようなMPDUpdateDirectiveフラグメントにより指示できるようにする。
【０１９５】
図７４には、MPDUpdateDirectiveフラグメントのインスタンスの第４の記述例が示されている。例えば、MPDが2つのDistributionPolicy要素を含むとき、このMPDを再構成する場合に適用するそれぞれのDistributionPolicyとレベルを、図７４に示すようなMPDUpdateDirectiveフラグメントにより指示できるようにする。
【０１９６】
＜コンテンツ配信処理＞
図７５乃至図８０を参照して、ATSC3.0や3GPP-MBMSのシグナリングフラグメントとして転送されるMPDUpdateDirectiveを用いたコンテンツ配信処理の一例について説明する。
【０１９７】
ステップＳ５０１において、コンテンツプロバイダ２１は、MPDおよびASを生成し、CDNサービスプロバイダ２２に転送する。
【０１９８】
CDNサービスプロバイダ２２のリソースマネジャは、コンテンツプロバイダ２１によりステップＳ５０１で転送されてくるMPDおよびASを受信する。そして、CDNサービスプロバイダ２２のリソースマネジャは、ステップＳ５１１において、放送または双方向配信のリソースを割り当て、MPDを書き換え、MPDおよびASを双方向サーバおよび放送サーバそれぞれに配置して、それらを転送させる。ステップＳ５１２において、CDNサービスプロバイダ２２のリソースマネジャは、放送または双方向配信のリソースを割り当て、MPDUpdateDirectiveをシグナリング放送し、AS（N以降）を双方向サーバおよび放送サーバそれぞれに配置転換して、それらを転送させる。なお、MPDUpdateDirectiveの一例が、図６５に示されている。
【０１９９】
同様に、図７６のステップＳ５１３において、CDNサービスプロバイダ２２のリソースマネジャは、放送または双方向配信のリソースを割り当て、MPDUpdateDirectiveをシグナリング放送し、AS（M以降）を双方向サーバおよび放送サーバそれぞれに配置転換して、それらを転送させる。なお、MPDUpdateDirectiveの一例が、図６８に示されている。
【０２００】
CDNサービスプロバイダ２２の双方向サーバは、リソースマネジャによりステップＳ５１１でDistributionPolicy付きのMPDおよびASが配置された後、クライアント１３からMPDの要求があると、図７５のステップＳ５２１において、MPDをクライアント１３に転送する。その後、CDNサービスプロバイダ２２の双方向サーバは、クライアント１３からASの要求があると、ステップＳ５２２において、ASをクライアント１３に転送する。また、CDNサービスプロバイダ２２の双方向サーバは、リソースマネジャによりステップＳ５１２でAS（N以降）が配置転換された後、クライアント１３からASの要求があると、ステップＳ５２３において、AS（N-1）をクライアント１３に転送する。
【０２０１】
同様に、CDNサービスプロバイダ２２の双方向サーバは、クライアント１３からASの要求があると、図７６のステップＳ５２４において、AS（N）をクライアント１３に転送する。その後、CDNサービスプロバイダ２２の双方向サーバは、リソースマネジャによりAS（M以降）が配置転換された後、クライアント１３からAS（M-1）の要求があると、ステップＳ５２５において、AS（M-1）をクライアント１３に転送する。さらに、CDNサービスプロバイダ２２の双方向サーバは、クライアント１３からAS（M）の要求があると、ステップＳ５２６において、AS（M）をクライアント１３に転送する。
【０２０２】
CDNサービスプロバイダ２２の放送サーバは、リソースマネジャによりステップＳ５１１でDistributionPolicy付きのMPDおよびASが配置された後、図７５のステップＳ５３１において、MPDをクライアント１３に転送する。その後、CDNサービスプロバイダ２２の放送サーバは、リソースマネジャによりステップＳ５１２で生成されたMPDUpdateDirectiveを取得して、ステップＳ５３２においてMPDUpdateDirectiveをクライアント１３に転送する。
【０２０３】
その後、CDNサービスプロバイダ２２の放送サーバは、図７６のステップＳ５３３においてAS（N）をDASHクライアントに転送する。また、CDNサービスプロバイダ２２のリソースマネジャによりステップＳ５１３で生成されたMPDUpdateDirectiveを取得し、配置転換されたAS（M以降）を取得して、ステップＳ５３４においてMPDUpdateDirectiveおよびAS（M-1）をクライアント１３に転送する。そして、CDNサービスプロバイダ２２の放送サーバは、ステップＳ５３５においてAS（N）をDASHクライアントに転送する。
【０２０４】
クライアント１３のローカルプロキシサーバは、CDNサービスプロバイダ２２の放送サーバによりステップＳ５３１で転送されてくるMPDを取得する。そして、クライアント１３のローカルプロキシサーバは、DASHクライアントによるMPDの要求をCDNサービスプロバイダ２２に送信し、その要求に応じて、CDNサービスプロバイダ２２の双方向サーバによりステップＳ５２１で転送されてくるMPDを取得する。そして、クライアント１３のローカルプロキシサーバは、ステップＳ５４１において、放送サーバから取得したMPD、および、双方向サーバから取得したMPDのどちらか一方のMPDをDASHクライアントに転送する。
【０２０５】
また、クライアント１３のローカルプロキシサーバは、DASHクライアントによるASの要求をCDNサービスプロバイダ２２に送信し、その要求に応じて、CDNサービスプロバイダ２２の双方向サーバによりステップＳ５２２で転送されてくるASを取得する。そして、クライアント１３のローカルプロキシサーバは、ステップＳ５４２において、ASをDASHクライアントに転送する。
【０２０６】
その後、クライアント１３のローカルプロキシサーバは、CDNサービスプロバイダ２２の放送サーバによりステップＳ５３２で転送されてくるMPDUpdateDirectiveを取得する。また、クライアント１３のローカルプロキシサーバは、DASHクライアントによるAS（N-1）の要求をCDNサービスプロバイダ２２に送信し、その要求に応じて、CDNサービスプロバイダ２２の双方向サーバによりステップＳ５２３で転送されてくるASを取得する。そして、クライアント１３のローカルプロキシサーバは、ステップＳ５４３において、MPDを再構成し、MPDUpdateEventをセグメントへ挿入する。なお、再構成されたMPDの一例が、図７８に示されている。
【０２０７】
また、クライアント１３のローカルプロキシサーバは、ステップＳ５４４において、AS（N-1）をDASHクライアントに転送する。その後、クライアント１３のローカルプロキシサーバは、DASHクライアントからMPDが要求されると、ステップＳ５４５において、ステップＳ５４３で再構成した後のMPDをDASHクライアントに転送する。
【０２０８】
さらに、クライアント１３のローカルプロキシサーバは、CDNサービスプロバイダ２２の放送サーバによりステップＳ５３３で転送されてくるAS（N）を取得する。そして、クライアント１３のローカルプロキシサーバは、DASHクライアントによるセグメント（N）の要求を受け、もし対象のセグメントが放送サーバから届いていなければ、CDNサービスプロバイダ２２に送信し、その要求に応じて、CDNサービスプロバイダ２２の双方向サーバによりステップＳ５２４で転送されてくるAS（N）を取得する。そして、クライアント１３のローカルプロキシサーバは、ステップＳ５４６において、AS（N）をDASHクライアントに転送する。
【０２０９】
その後、クライアント１３のローカルプロキシサーバは、CDNサービスプロバイダ２２の放送サーバによりステップＳ５３４で転送されてくるMPDUpdateDirectiveおよびAS（M-1）を取得する。そして、クライアント１３のローカルプロキシサーバは、DASHクライアントによるAS後続セグメント（M-1）の要求を受け、もし対象のセグメントが放送サーバから届いていなければ、CDNサービスプロバイダ２２に送信し、その要求に応じて、CDNサービスプロバイダ２２の双方向サーバによりステップＳ５２５で転送されてくるAS（M-1）を取得する。
【０２１０】
そして、クライアント１３のローカルプロキシサーバは、ステップＳ５４７において、MPDを再構成し、MPDUpdateEventをセグメントへ挿入する。なお、再構成されたMPDの一例が、図８０に示されている。クライアント１３のローカルプロキシサーバは、ステップＳ５４８において、AS（N-1）をDASHクライアントに転送する。その後、クライアント１３のローカルプロキシサーバは、DASHクライアントからMPDが要求されると、ステップＳ５４９において、ステップＳ５４７で再構成した後のMPDをDASHクライアントに転送する。
【０２１１】
その後、クライアント１３のローカルプロキシサーバは、DASHクライアントによるAS（M）の要求をCDNサービスプロバイダ２２に送信し、その要求に応じて、CDNサービスプロバイダ２２の双方向サーバによりステップＳ５２６で転送されてくるAS（M）を取得する。そして、クライアント１３のローカルプロキシサーバは、ステップＳ５５０において、AS（M）をDASHクライアントに転送する。
【０２１２】
クライアント１３のDASHクライアントは、ステップＳ５６１において、サービスまたはコンテンツの選択が行われると、その選択されたサービスまたはコンテンツのMPDを要求する。その後、クライアント１３のDASHクライアントは、CDNサービスプロバイダ２２の双方向サーバによりステップＳ５２１で転送されたMPD、CDNサービスプロバイダ２２の放送サーバによりステップＳ５３１で転送されたMPDのうち、クライアント１３のローカルプロキシサーバによりステップＳ５４１で転送されたいずれか一方のMPDを取得する。
【０２１３】
続いて、クライアント１３のDASHクライアントは、ステップＳ５６２において、取得したMPDをパースし、ASを特定して、その特定したASを要求する。なお、パースされたMPDの一例が、図７７に示されている。
【０２１４】
その後、クライアント１３のDASHクライアントは、CDNサービスプロバイダ２２の双方向サーバによりステップＳ５２２で転送されたAS、即ち、クライアント１３のローカルプロキシサーバによりステップＳ５４２で転送されたASを取得する。そして、クライアント１３のDASHクライアントは、ステップＳ５６３において、取得したASを再生する。
【０２１５】
さらに、クライアント１３のDASHクライアントは、ステップＳ５６４において、AS後続セグメント（N-1）を要求する。その後、クライアント１３のDASHクライアントは、CDNサービスプロバイダ２２の双方向サーバによりステップＳ５２３で転送されたAS（N-1）、即ち、クライアント１３のローカルプロキシサーバによりステップＳ５４４で転送されたAS（N-1）を取得する。そして、クライアント１３のDASHクライアントは、ステップＳ５６５において、取得したAS（N-1）を再生する。
【０２１６】
そして、クライアント１３のDASHクライアントは、ステップＳ５６６において、In-band Event（MPDUpdate）を検出し、MPDを要求する。そして、クライアント１３のローカルプロキシサーバによりステップＳ５４５で転送されてくるMPDを取得する。
【０２１７】
以下、同様に、クライアント１３のDASHクライアントは、ステップＳ５６７において、MPDをパースし、セグメント（N）を特定して、その特定したAS（N）を要求し、ステップＳ５６８においてAS（N）を再生する。なお、ステップＳ５６７でパースされたMPDの一例が、図７９に示されている。
【０２１８】
また、同様に、クライアント１３のDASHクライアントは、ステップＳ５６９において、AS後続セグメント（M-1）を要求し、ステップＳ５７０においてAS（M-1）を再生する。さらに、同様に、クライアント１３のDASHクライアントは、ステップＳ５７１において、In-band Event（MPDUpdate）を検出して、MPDを要求する。そして、クライアント１３のローカルプロキシサーバ下流側DANEによりステップＳ５４９で転送されてくるMPDを取得する。クライアント１３のDASHクライアントは、ステップＳ５７１において、In-band Eventを検出し、MPDを要求し、ステップＳ５７２において、MPDをパースし、AS（M）を特定して、その特定したAS（M）を要求し、ステップＳ５７３において、AS（M）を再生する。なお、再構成されたMPDの一例が、図８０に示されている。
【０２１９】
以上のように、サービスプロバイダ（もしくは、サービスプロバイダ内のCDNセグメントマネジャ）が放送/双方向トランスポートリソースの割り当てを担う場合で、リソースマネジャにおいてMPDは書き換えずに、ATSC3.0や3GPP-MBMSのシグナリングフラグメントとして転送されるMPDUpdateDirectiveにより、トランスポートリソースの割り当てをクライアント側に通知し、クライアント側でMPDを再構成することができる。
【０２２０】
＜ResourceSpecificInformationのその他の例＞
図８１乃至図８３を参照して、ResourceSpecificInformationのその他の例について説明する。
【０２２１】
例えば、DistributionPolicyのPolicyDescriptionは、とあるLevelに属するAdaptationSet群に対するさまざまな内容が記述できる。上述の例の他、当該ストリームを転送するのに必要となるトランスポート特性の制約をもとに定義することもできる。トランスポート特性の制約とは、当該ストリーム(放送)を取得する際に要求されるネットワーク要求品質条件を示す。例としては、遅延、遅延揺らぎ、損失(エラー)、スループット等がある。
【０２２２】
このうち、遅延を制約記述に用いる場合には、例えば、図８１に示すように、DistributionPolicy.PolicyDescription='遅延制約の高いものを放送へ'のように記載する。さらに、各Levelに対する具体的な制約値を格納できるように、各Level要素のResourceSpecificInformationの部分に、<Level LatencyLimit='100msec' … />のように記述できるようにする。
【０２２３】
ここで、Latencyの定義は、例えば、DASHプレイヤがセグメントリクエストを発行してから対象セグメントの先頭バイトを取得するまでの遅延等のように定義しておく。例えば、遅延以外にも、遅延ゆらぎ（ジッタ）、エラーレート等が考えられるが、それぞれのパラメタに対応する記述規則（属性名）とその詳細な意味/定義は別途定義するものとする。
【０２２４】
このように、ResourceSpecificInformationを用いるMPDは、図８２に示すように記述される。図８２に示すように、上述したようなDistributionMediaDependant Extension/ElementToBeAppendedに加え、さらにDistributionMediaDependant Extension/ElementToBeRemovedが記述されている。これは、maxLevelToBeAppliedで指定される当該Levelまでに含まれるAdaptationSet要素から削除すべき要素を示す。
【０２２５】
そして、生成されるべき有効なMPDは、図８３に示すように記述される。即ち、図８３に示すように、AS@id=１、２のASからBaseURL=/bcが削除されて、BaseURL=/netが追加される。
【０２２６】
図８３に示すMPDが配信されるクライアントデバイスが受信することのできる双方向トランスポートが最大遅延50msec以下を提供することできて、そこにはLevel[2]まで(Lavel[1]とLevel[2])のAdaptationSet群が転送されることを示している。一方、そのデバイスが受信することのできる放送トランスポートが最大遅延10msec以下を提供することができて、そこにはLevel[3]のAdaptationSet群が転送される。
【０２２７】
＜ATSC3.0クライアント実装モデル＞
図８４には、ATSC3.0のクライアントの実装モデルとして想定される構成例を示すブロック図が示されている。
【０２２８】
図８４に示すように、ATSC3.0クライアントアプリケーション("3.0 DASH Client")は、ATSC3.0チューナー(PHY/MAC)を有するATSC3.0放送受信クライアントデバイス("3.0 Client (with ATSC3.0 PHY/MAC)")上に実装されたブラウザ上で実行される(ブラウザアプリケーションとしてだけではなくネイティブアプリケーションとして実行される場合もある)。
【０２２９】
また、ATSC3.0クライアントアプリケーションは、クライアント上に実装されたクライアントローカルHTTPプロキシーサーバ("Client Local HTTP Proxy Server")を介して、放送系受信スタックが実装されたクライアントローカルATSCミドルウエア("Client Local ATSC Middleware")が受信した、もしくは、ネット系送受信処理を行う通常のネットワークスタックを介して取得した、DASH-MPDファイルやDASH segmentファイル、ならびに、SLS(Service level Signaling)ファイルにより、ストリームのレンダリングや、アプリケーションの制御を行う。
【０２３０】
そして、ATSC3.0 DASHクライアントアプリケーションは、また、LAN等を介してATSC3.0放送受信クライアントデバイスにアクセス可能な他のデバイス上に実装されたブラウザ上(もしくはネイティブアプリケーションとして)でも実行可能であり、そのアプリケーションも、ATSC3.0放送受信クライアントデバイス上のクライアントローカルHTTPプロキシーサーバを介して、クライアントローカルATSCミドルウエアが受信した、もしくは、通常のネットワークスタックを介して取得した、DASH-MPDファイルやDASH segmentファイル、ならびに、SLS(Service level Signaling)ファイルを取得して、ストリームのレンダリングや、アプリケーションの制御を行う。
【０２３１】
例えば、このモデルは、アプリケーションからすると、必ずクライアントローカルHTTPプロキシーサーバを介して外の世界にアクセスするため、それらファイル群を放送経由で取得しているのか、ネット経由で取得しているのかの区別を意識することがない(ネットワーク透過性が提供される)ため、アプリケーションの可搬性を高めることが可能となる(放送向けのみに特化して実装する必要がなく、放送もインターネットのどちらを使うかによらない実装にすることができる)。
【０２３２】
そして、ATSC3.0 DASHクライアントアプリケーションが上記ファイル群の取得を要求すると(HTTPリクエスト)、それを受けたクライアントローカルHTTPプロキシーサーバが、"Broadcast/Broadband Address Resolover"において放送受信スタックを介して取得するか、ネット経由で取得するかの判断を行う。
【０２３３】
ここで、判断の材料となる情報は、"SLS Signaling Parser"から提供される。"SLS Signaling Parser"は、"SLS Signaling Retriever"に、ATSC3.0のシグナリングメタであるUSBD/USDやS-TSID等の取得要求を行う。"SLS Signaling Retriever"は、ATSCチューナー"ATSC3.0 PHY/MAC"を介して放送受信するSLS LCTパケットにより運ばれるシグナリングメタを抽出する。"SLS Signaling Parser"は、また、セグメントの取得要求に含まれるurlから、シグナリングメタを引いて、対象となるファイルを取得するための放送配信アドレス情報を解決する。
【０２３４】
そして、放送配信される、または、放送されたことがわかれば、その放送配信アドレス情報をもとにして、所望のファイルが格納されたsegment LCTパケットを放送ストリームから取得し、"Proxy Cache"内に展開する。クライアントローカルHTTPプロキシーサーバは、当該ファイルをアプリケーションに(HTTPのレスポンスとして)返す。
【０２３５】
これにより、要求されたセグメントファイルのurlがシグナリングメタになければ、クライアントローカルHTTPプロキシーサーバは、通常のネットスタックを介してセグメントファイルを取得する。
【０２３６】
また、図８５には、ATSC3.0プロトコルスタックが示されており、図８６には、ROUTE/DASHベースのスタックが示されている。
【０２３７】
＜コンテンツ配信方法における第２の配信方法＞
以下では、本技術を適用したコンテンツ配信方法の第２の配信方法について説明する。
【０２３８】
上述したコンテンツ配信方法（第１の配信方法）では、複数のトランスポートメディアを保有するサービスプロバイダを介してコンテンツを配信する際に、分配ポリシーを参考して、ユニキャスト優先およびブロードキャスト優先のどちらかが選択される。これに対し、コンテンツ配信方法の第２の配信方法では、この分配ポリシーと同様に用いられるメタデータに、セグメントを先行取得する際に参照する情報（優先度）を定義することで、より遅延を削減してコンテンツの配信を行うことを想定している。
【０２３９】
例えば、コンテンツ配信方法の第２の配信方法は、スポーツなどのイベントの中継、または、全天球（360°VR）コンテンツなどの配信において、複数の視点の映像を提供するときに採用することができる。このような複数の視点の映像を提供する提供方法としては、例えば、完全に異なる複数の位置に配置されたカメラからの映像ストリームを、１つのコンテンツとして提供する方法がある。さらに、全天球コンテンツにおいて、ユーザの視線方向（Viewportと呼ばれる）ごとの個別の映像ストリームを提供する方法や、これらの方法を組み合わせて用いる方法などがある。
【０２４０】
また、複数の視点の映像を提供する際に、それらの映像に対して、クライアントが、視聴コンテンツを選択するための各種の（客観的な）メタデータを提供することがある。一方、全天球映像におけるROI（Region of Interest）などのように、制作者の意図（Director's Cut）に基づいて推奨される視点を提供することも想定されている。
【０２４１】
これに対し、コンテンツ配信方法の第２の配信方法では、セグメントのデータ配信における遅延を削減することによるユーザ体験の向上を図るために、セグメントを先行取得する際に参照する情報（優先度）が、メタデータにより提供される。例えば、比較的に多くの視聴者が選択することが想定される視点や、視聴者が観る可能性の高いROIのアングルビューなどが、高い優先度となるような割り当てなどが行われる。なお、このメタデータは、従来のクライアントによるユーザ意図や、HMDを装着した視聴者の動きなどを含むインタラクションなどに基づいて視聴ストリームを選択するために用いられるのとは異なるものである。
【０２４２】
また、メタデータのソース（メタデータを生成した生成元や、メタデータを提供する提供元、メタデータを付加した主体の種別）としては、コンテンツ提供者、ネットワーク、または、その他が想定される。コンテンツ提供者が提供するメタデータとして、コンテンツを制作した製作者の意図として予測される人気度を用いることが想定される。また、ネットワークにより提供されるメタデータとして、実際に過去にコンテンツを配信したときに測定される、ユーザによる選択の割合を表す実測値（実測された統計に基づく値）を用いることが想定される。また、コンテンツ提供者およびネットワークの他によりメタデータが提供されることも想定される。このように、複数のソースから、メタデータが同時に提供されることが想定されるだけでなく、各々のメタデータが時間的に変化することも考えられる。
【０２４３】
そこで、このように、複数のソースから提供され、時間的に変化するようなメタデータを、MPEG DASHのMPDに効率良く記述することが必要とされる。
【０２４４】
図８７を参照して、優先度を示すメタデータを参照して、セグメントを先行取得するようなコンテンツ提供システムの概要について説明する。
【０２４５】
図８７に示すコンテンツ提供システム１１は、コンテンツプロバイダ２１（オリジン・サーバ）から配信されるコンテンツが、配信サーバ５１によって、放送ネットワーク１４および双方向ネットワーク１５の間で配信リソースの分配が制御される。また、双方向ネットワーク１５は、CDN中間サーバ５２およびCDNエッジサーバ５３により構築され、配信サーバ５１から送信されるコンテンツは、例えば、CDN中間サーバ５２を経由して、CDNエッジサーバ５３により、コンテンツの提供を受けるクライアント１３へ配信される。
【０２４６】
また、コンテンツプロバイダ２１から配信されるコンテンツには、セグメントごとに優先度を示すメタデータを付加することができ、例えば、人気度が高い視点のセグメントには高い優先度が設定されている。そして、このメタデータを参照して、CDN中間サーバ５２およびCDNエッジサーバ５３が、優先度が高いセグメントを優先的に先行取得（pre-fetch）したり、クライアント１３が、優先度が高いセグメントを優先的に先行取得したりすることができる。
【０２４７】
なお、放送ネットワーク１４を介したブロードキャストまたはマルチキャストと、双方向ネットワーク１５を介したユニキャストとが併用可能である場合、優先度が高いセグメントを、優先的にブロードキャストまたはマルチキャストに割り当てて配信してもよい。
【０２４８】
ここで、上述したようにクライアント１３におけるユーザ意図やインタラクションによってストリームを選択する場合には、例えば、ファイルフォーマットレベルの情報を用いることができる。これに対し、配信サーバ５１により配信リソースの配分を最適化するためには、MPEG DASHのMPDレベルでのシグナリングが望ましい。同様に、双方向ネットワーク１５上の配信経路の途中にあるCDN中間サーバ５２およびCDNエッジサーバ５３、並びに、クライアント１３によりセグメントを先行取得するためには、MPDレベルでのシグナリングが望ましい。
【０２４９】
ところが、MPEG DASHのMPD記述について既に提案されている方式では、複数のソースからメタデータが提供され、かつ、それらのメタデータが時間的に変化すると、その記述が複雑となってしまう。そこで、このようなメタデータを、MPEG DASHのMPDに効率良く記述することが必要となる。
【０２５０】
＜セグメントポピュラリティータイムラインのエレメントの定義例＞
まず、セグメントを先行取得する際に参照する情報として用いられる「人気度」を、MPEG DASHのMPDに記述する方法について説明する。例えば、「人気度」は、そのストリームがクライアントで消費される確率の高さに基づいて求めることができる。
【０２５１】
図８８に示すように、MPDのアダプテーションセット（AdaptationSet）またはリプレゼンテーション（Representation）に対する子エレメントとして、セグメントポピュラリティータイムライン（SegmentPopularityTimeline）が定義される。
【０２５２】
例えば、セグメントポピュラリティータイムラインは、元のセグメント列に対する人気度（Pupularity rate）を規定する。
【０２５３】
ソース（@source）は、条件付きの必須で使用され、「人気度」の提供元または種別を表す値として、content、network、およびotherのいずれかが指定される。contentは、「人気度」が、コンテンツ提供者が提供する予測人気度であることを示す。networkは、「人気度」が、過去のユーザの視聴履歴統計に基づく値などのように、配信を行うネットワークにより提供される人気度であることを示す。otherは、「人気度」が、コンテンツ提供者およびネットワークの他により人気度であることを示す。なお、ソースは、あるエレメント（アダプテーションセットまたはリプレゼンテーショ）が２つ以上のセグメントポピュラリティータイムラインのエレメントを持つ場合に必ず指定される。
【０２５４】
SPエレメントは、１〜N個記述することができ、人気度（rate）の値を持つ要素である。SPエレメントで指定されるレート（@rate）は、必須で使用され、「人気度」を１〜１００の整数で指定される。例えば、レートは、レベル１が最も人気度が高く、数字が大きいほど人気度が低くなるように設定されている。SPエレメントで指定されるスタート（@start）は、オプションで使用され、そのSPエレメントのレートの値が適用される一連のセグメントのうちの、最初のセグメントのセグメント番号が指定される。SPエレメントで指定されるセグメント数（@r）は、オプションで使用され、そのSPエレメントで指定されるレートが適用される一連の後続セグメントの数が指定される。なお、セグメント数には、そのレートが指定される最初のセグメントは含まない。
【０２５５】
このように、セグメントポピュラリティータイムラインを規定することで、セグメントを先行取得する際に参照する情報を効率良く記述することができる。
【０２５６】
なお、図８８において、SPエレメントで指定されるレートの値は、別途、MPEG DASHのMPDに（Periodレベルで）記述されているDistributionPolicy（例えば、上述の図１２参照）のLevel@index（Levelエレメントのindexアトリビュート）の値に対応させることができる。
【０２５７】
図８９には、図８８を参照して説明したセグメントポピュラリティータイムラインのエレメントを使用して、２種類の提供元から提供された「人気度」を記述したMPEG DASHのMPDの例が示されている。
【０２５８】
図８９に示す例では、セグメントテンプレート（SegmentTemplate）のポピュラリティータイムラインのSPエレメントで記述されているdurationが180180でt=0から始まる６個のセグメントについて、「人気度」が指定されている。例えば、ソースがコンテンツ提供者（source="content"）であるセグメントポピュラリティータイムラインでは、初めの２個（１番目および２番目）のセグメントのレートの値に５０が指定されている。そして、続く２個（３番目および４番目）のセグメントのレートの値に３０が指定され、さらに続く２個（５番目および６番目）のセグメントのレートの値に１０が指定されている。
【０２５９】
また、図８９では、１つのアダプテーションセットに対するセグメントポピュラリティータイムラインの記述例のみが示されている。実際には、ピリオドに複数のアダプテーションセットが記述され、それぞれのアダプテーションセットにセグメントポピュラリティータイムラインのエレメントが記述される。そして、各SPエレメントのレートの値で指定される「人気度」は、ピリオド内の特定の区間における、異なるアダプテーションセット間の相対的な「人気度」を示すものである。従って、CDN中間サーバ５２、CDNエッジサーバ５３、またはクライアント１３は、この情報に基づいて、ピリオド内の特定の区間について、特定のアダプテーションセット内のセグメントを選択して、先行取得することができる。
【０２６０】
＜セグメントポピュラリティータイムラインのエレメントの第１のバリエーション＞
図９０および図９１を参照して、セグメントポピュラリティータイムラインのエレメントの第１のバリエーションについて説明する。
【０２６１】
上述した図８８に示したセグメントポピュラリティータイムラインのエレメントの定義例では、もともとアダプテーションセットのエレメントのセグメントタイムラインで規定されているセグメント単位で「人気度」を指定している。これに対し、例えば、個々のセグメントの時間（duration）とは独立に「人気度」を指定することができる。
【０２６２】
図９０に示すセグメントポピュラリティータイムラインが定義では、ソース（@source）、および、SPエレメントで指定されるレート（@rate）は、図８８の定義と同様であり、その説明は省略する。
【０２６３】
SPエレメントで指定されるスタートタイム（@start_time）は、オプションで使用され、そのSPエレメントのレートの値が適用される開始時間（media time）を、そのアダプテーションセットに適用されるタイムスケール（timescale）に基づいて記述する。なお、スタートタイムが省略された場合、適用開始時間は、前のSPエレメントに指定されたエンドタイム、または、ピリオドの開始時間となる。
【０２６４】
SPエレメントで指定されるエンドタイム（@end_time）は、オプションで使用され、そのSPエレメントのレートの値が適用される終了時間（media time）を、そのアダプテーションセットに適用されるタイムスケール（timescale）に基づいて記述する。なお、エンドタイムが省略された場合、適用終了時間は、ピリオドの終了時間となる。
【０２６５】
図９１には、図９０を参照して説明した第１のバリエーションのセグメントポピュラリティータイムラインのエレメントを使用して、２種類の提供元から提供された「人気度」を記述したMPEG DASHのMPDの例が示されている。
【０２６６】
図９１に示す例では、セグメントテンプレートのセグメントタイムライン（SegmentTemplate.SegmentTimeline）のSエレメントで記述されているタイムスケールが90000（タイムスケールは、１秒には90000カウントするという意味）となっている。そして、各セグメントの時間（duration）が、180180（=180180/90000秒）でt=0から始まる６個のセグメントについて、「人気度」が指定されている。
【０２６７】
例えば、ソースがコンテンツ提供者（source="content"）であるセグメントポピュラリティータイムラインでは、セグメントの境界に関わらずにｔ＝０〜3.003秒までにおいて、レートの値に５０が指定されている。この例では、スタートタイムが省略されているため、ピリオドの開始時間から適用されている。そして、続くｔ＝6.006秒までの区間において、レートの値に３０が指定され、さらに続くｔ＝12.012秒までの区間において、レートの値に１０が指定されている。
【０２６８】
また、ソースがネットワーク（source="network"）であるセグメントポピュラリティータイムラインでは、ｔ＝０〜3.5秒までの区間において、レートの値に１０が指定されている。そして、続くｔ＝3.5〜7.0秒までの区間において、レートの値に５０が指定され、さらに続くｔ＝7.0〜12.012秒までの区間において、レートの値に７０が指定されている。この例では、エンドタイムが省略されているため、ピリオドの終了時間まで適用されている。
【０２６９】
＜セグメントポピュラリティータイムラインのエレメントの第２のバリエーション＞
図９２を参照して、セグメントポピュラリティータイムラインのエレメントの第２のバリエーションについて説明する。
【０２７０】
例えば、セグメントポピュラリティータイムラインのエレメントは、アダプテーションセットのエレメントの子要素としてではなく、リプレゼンテーションのエレメントの子要素とすることができる。特に、ソースがネットワーク（source="network"）である場合、即ち、過去のユーザが取得したストリームの統計情報に基づく「人気度」を記述する場合、リプレゼンテーション単位で記述することによって、CDNエッジサーバ５３がセグメントを先行取得する際に、より有効に参照することができる。つまり、そのCDNエッジサーバ５３からストリームを取得しているクライアント１３との間の利用可能帯域の傾向を表す統計値が提供される可能性がある。
【０２７１】
図９２には、このような第２のバリエーションのセグメントポピュラリティータイムラインのエレメントを使用して、セグメント単位で「人気度」を記述したMPEG DASHのMPDの例が示されている。
【０２７２】
なお、図９２に示す例では、ソースがネットワーク（source="network"）であるセグメントポピュラリティータイムラインのみ、リプレゼンテーション単位で、レートの値を指定している。なお、これは、ソースがコンテンツ提供者（source="content"）であるセグメントポピュラリティータイムラインにおいて、リプレゼンテーション単位で、レートの値を指定することを排除するものではない。例えば、制作者の意図によって区間ごとの視聴を推奨したい最低限の品質（図９２に示す@bandwidthの値、すなわちストリームのencoding bitrate）を指定する目的で、リプレゼンテーション単位の優先度を指定することなどが想定される。
【０２７３】
また、図９２に示す例では、セグメントテンプレートのセグメントタイムライン（SegmentTemplate.SegmentTimeline）のSエレメントで記述されている時間（duration）が180180でｔ＝０から始まる６個のセグメントについて、「人気度」が指定されている。
【０２７４】
例えば、ソースがネットワーク（source="network"）であるセグメントポピュラリティータイムラインでは、初めの２個（１番目および２番目）のセグメントでは、bandwidth="500000"のリプレゼンテーションのレートの値が最も高く指定されている。そして、続く２個（３番目および４番目）のセグメントでは、bandwidth="1000000"のリプレゼンテーションのレートの値が最も高く指定されており、さらに続く２個（５番目および６番目）のセグメントでは、bandwidth="500000"のリプレゼンテーションのレートの値が最も高く指定されている。なお、これらのレートの値で示される「人気度」は、アダプテーションセット内のリプレゼンテーション間の相対的な関係を表すだけでなく、上述したように、他のアダプテーションセットで記述されているセグメントとの間の相対的な関係を表している。
【０２７５】
＜セグメントポピュラリティータイムラインのエレメントの第３のバリエーション＞
図９３を参照して、セグメントポピュラリティータイムラインのエレメントの第３のバリエーションについて説明する。
【０２７６】
例えば、上述したコンテンツ配信方法の第１の配信方法で定義したディストリビューションポリシー（distributionPolicy）のエレメントにおけるレベル（Level）のエレメントを時間に応じて指定可能とすることができる。図９３には、ディストリビューションポリシーのエレメントの記述例が示されている。
【０２７７】
そして、このようなディストリビューションポリシーのエレメントにおけるレベルのエレメントを、図９４に示すように定義するDPレベルタイムラインのエレメントに置き換えることができる。
【０２７８】
例えば、DPレベルタイムラインは、時間に応じて変化するディストリビューションポリシーのレベルを記述する。レベルは、１〜N個記述することができ、区間ごとのディストリビューションポリシーのレベルを指定する。レベルで指定されるインデックスASIDs（@index_ASIDs）は、必須で使用され、当該レベルのエレメント区間に適用される優先度（または「人気度」）を表すインデックス値、および、それが適用されるアダプテーションセットＩＤをコンマで区切って列挙する。
【０２７９】
レベルで指定されるスタートタイム（@start_time）は、オプションで使用され、そのレベルのエレメントのレートの値が適用される開始時間（media time）を秒単位で記述する。なお、スタートタイムが省略された場合、適用開始時間は、前のレベルのエレメントに指定されたエンドタイム、または、ピリオドの開始時間となる。
【０２８０】
レベルで指定されるエンドタイム（@end_time）は、オプションで使用され、そのレベルのエレメントの値が適用される終了時間（media time）を秒単位で記述する。なお、エンドタイムが省略された場合、適用終了時間は、ピリオドの終了時間となる。
【０２８１】
図９５には、図９４を参照して説明した第３のバリエーションディストリビューションポリシーの記述例が示されている。
【０２８２】
図９５に示す例では、ｔ＝０〜3.003秒まで、AS-1にLevel値（index値）１が指定され、AS-2およびAS-3にLevel値（index値）２が指定され、AS-4にLevel値（index値）３が指定されている。この例では、スタートタイムが省略されているため、ピリオドの開始時間から適用されている。そして、続くｔ＝6.006秒までの区間において、AS-1およびAS-2にLevel値（index値）１が指定され、AS-3にLevel値（index値）２が指定され、AS-4にLevel値（index値）３が指定されている。さらに続くｔ＝12.012秒までの区間ではAS-1にLevel値（index値）１が指定され、AS-2およびAS-4にLevel値（index値）２が指定され、AS-3にLevel値（index値）３が指定されている。
【０２８３】
＜セグメントを先行取得する先行取得処理の第１の処理例＞
図９６を参照して、セグメントを先行取得する先行取得処理の第１の処理例について説明する。また、CDN中間サーバ５２、CDNエッジサーバ５３、およびクライアント１３それぞれにおいて先行取得処理が行われ、以下では、これらの何れかを処理主体として説明を行う。
【０２８４】
例えば、CDN中間サーバ５２、CDNエッジサーバ５３、およびクライアント１３が、それぞれMPDを取得したときに処理が開始される。ステップＳ６０１において、その処理を行う処理主体は、まず、判断基準となるソースを設定するソースパラメータに、コンテンツ提供者を示す値をセット（$SourceParam$="content"）する。これにより、コンテンツ提供者により提供される情報に基づいた判断が優先的に行われる。
【０２８５】
ステップＳ６０２において、処理主体は、少なくとも１つ以上のアダプテーションセットに、ソースの属性を示す値が、ソースパラメータにセットされている値と一致（@source=$SourceParam$）するセグメントポピュラリティータイムラインのエレメントがあるか否かを判定する。
【０２８６】
ステップＳ６０２において、処理主体が、少なくとも１つ以上のアダプテーションセットに、ソースの属性を示す値が、ソースパラメータにセットされている値と一致するセグメントポピュラリティータイムラインのエレメントがあると判定した場合、処理はステップＳ６０３に進む。ステップＳ６０３では、図９７を参照して後述するように、アダプテーションセット（およびリプレゼンテーション）のセグメントポピュラリティータイムライン情報に基づいてセグメントを先行取得する先行取得処理（アダプテーションセット）が行われ、その後、処理は終了される。
【０２８７】
一方、ステップＳ６０２において、処理主体が、少なくとも１つ以上のアダプテーションセットに、ソースの属性を示す値が、ソースパラメータにセットされている値と一致するセグメントポピュラリティータイムラインのエレメントがないと判定した場合、処理はステップＳ６０４に進む。
【０２８８】
ステップＳ６０４において、処理主体は、少なくとも１つ以上のリプレゼンテーションに、ソースの属性を示す値が、ソースパラメータにセットされている値と一致（@source=$SourceParam$）するセグメントポピュラリティータイムラインのエレメントがあるか否かを判定する。
【０２８９】
ステップＳ６０４において、処理主体が、少なくとも１つ以上のリプレゼンテーションに、ソースの属性を示す値が、ソースパラメータにセットされている値と一致するセグメントポピュラリティータイムラインのエレメントがあると判定した場合、処理はステップＳ６０５に進む。ステップＳ６０５では、図９８を参照して後述するように、リプレゼンテーションのセグメントポピュラリティータイムライン情報に基づいたセグメントを先行取得する先行取得処理（リプレゼンテーション）が行われ、その後、処理は終了される。
【０２９０】
一方、ステップＳ６０４において、処理主体が、少なくとも１つ以上のリプレゼンテーションに、ソースの属性を示す値が、ソースパラメータにセットされている値と一致するセグメントポピュラリティータイムラインのエレメントがないと判定した場合、処理はステップＳ６０６に進む。
【０２９１】
ステップＳ６０６において、処理主体は、ソースパラメータに、コンテンツ提供者を示す値がセットされているか否かを判定する。
【０２９２】
ステップＳ６０６において、処理主体が、ソースパラメータに、コンテンツ提供者を示す値がセットされていると判定した場合、処理はステップＳ６０７に進む。ステップＳ６０７において、処理主体は、ソースパラメータに、ネットワークを示す値をセット（$SourceParam$="network"）する。これにより、ネットワークにより提供される情報に基づいた判断が行われるようになって、その後、処理はステップＳ６０２に戻り、以下、同様の処理が繰り返される。
【０２９３】
一方、ステップＳ６０６において、処理主体が、ソースパラメータに、コンテンツ提供者を示す値がセットされていないと判定した場合、処理はステップＳ６０８に進む。
【０２９４】
ステップＳ６０８において、処理主体は、ソースパラメータに、ネットワークを示す値がセットされているか否かを判定する。
【０２９５】
ステップＳ６０８において、処理主体が、ソースパラメータに、ネットワークを示す値がセットされていると判定した場合、処理はステップＳ６０９に進む。ステップＳ６０９において、処理主体は、ソースパラメータに、その他を示す値をセット（$SourceParam$="other"）する。これにより、その他により提供される情報に基づいた判断が行われるようになって、その後、処理はステップＳ６０２に戻り、以下、同様の処理が繰り返される。
【０２９６】
一方、ステップＳ６０８において、処理主体が、ソースパラメータに、ネットワークを示す値がセットされていないと判定した場合、ソースパラメータに、コンテンツ提供者、ネットワーク、および、その他の全てをセットした処理が行われたことになる。従って、処理は終了される。
【０２９７】
以上の例では、CDN中間サーバ５２、CDNエッジサーバ５３、およびクライアント１３は、まず、ソースがコンテンツ提供者（source="content"）であるセグメントポピュラリティータイムラインのレートを最優先し、そのような情報が提供がされていない場合、ソースがネットワーク（source="network"）であるセグメントポピュラリティータイムラインのレートを利用する。さらに、それも記述されていない場合に、ソースがその他（source="other"）であるセグメントポピュラリティータイムラインのレート利用した判断を行う。
【０２９８】
図９７に示すフローチャートを参照して、図９６のステップＳ６０３で行われる先行取得処理について説明する。なお、この先行取得処理では、次に取得しようとするセグメント、即ち、セグメントのタイムライン上で、取得済みのセグメントに続く時間のセグメントについて、ソースの属性を示す値が、ソースパラメータにセットされている値と一致（@source=$SourceParam$）するセグメントポピュラリティータイムラインのレート（SP@rate）の値が最小であるアダプテーションセット内のセグメントを選択するための判定が行われる。
【０２９９】
ステップＳ６１１において、処理主体は、ソースの属性を示す値が、ソースパラメータにセットされている値と一致するセグメントポピュラリティータイムラインのレート（SP@rate）の値が最小であるアダプテーションセットを選択する。
【０３００】
ステップＳ６１２において、処理主体は、ステップＳ６１１で選択されたアダプテーションセット内のリプレゼンテーションに、ソースの属性を示す値が、ソースパラメータにセットされている値と一致するセグメントポピュラリティータイムラインが指定されているか否かを判定する。
【０３０１】
ステップＳ６１２において、処理主体が、ステップＳ６１１で選択されたアダプテーションセット内のリプレゼンテーションに、ソースの属性を示す値が、ソースパラメータにセットされている値と一致するセグメントポピュラリティータイムラインが指定されていると判定した場合、処理はステップＳ６１３に進む。
【０３０２】
ステップＳ６１３において、処理主体は、ステップＳ６１１で選択されたアダプテーションセット内のリプレゼンテーションのうちで、ソースの属性を示す値が、ソースパラメータにセットされている値と一致するセグメントポピュラリティータイムラインのレートの値が小さいものを選択して、セグメントを先行取得する。このとき、処理主体は、タイムライン上で同一時間区間の１または複数のセグメントを先行取得することができる。
【０３０３】
一方、ステップＳ６１２において、処理主体が、ステップＳ６１１で選択されたアダプテーションセット内のリプレゼンテーションに、ソースの属性を示す値が、ソースパラメータにセットされている値と一致するセグメントポピュラリティータイムラインが指定されていないと判定した場合、処理はステップＳ６１４に進む。
【０３０４】
ステップＳ６１４では、以下で説明するような所定の条件に従って、セグメントが先行取得される。
【０３０５】
例えば、この先行取得処理を行う処理主体が、CDN中間サーバ５２またはCDNエッジサーバ５３である場合、ステップＳ６１１で選択されたアダプテーションセット内のリプレゼンテーションに付加されている、ソースの属性を示す値が、ソースパラメータにセットされている値と一致（@source=$SourceParam$）するもの以外のリプレゼンテーションのセグメントポピュラリティータイムラインのレートの該当するセグメントを優先する。または、何らかの判断（例えば、過去にリクエストされているbitrate（@bandwidth）の該当するリプレゼンテーションのみ、など）に基づいて選択されたセグメントを先行取得する。
【０３０６】
また、この先行取得処理を行う処理主体が、クライアント１３である場合、現在のネットワーク状況に応じて適切なリプレゼンテーションのセグメントを先行取得する。
【０３０７】
ステップＳ６１３またはＳ６１４の処理後、処理はステップＳ６１５に進み、処理主体は、ピリオド（Period）で表される区間の終了までセグメントを取得し終えたか否かを判定する。
【０３０８】
ステップＳ６１５において、処理主体が、セグメントを取得し終えていないと判定した場合、処理はステップＳ６１１に戻り、取得すべき後続のセグメントを同様に先行取得する処理が繰り返して行われる。
【０３０９】
一方、ステップＳ６１５において、処理主体が、セグメントを取得し終えたと判定した場合、この先行取得処理は終了される。
【０３１０】
図９８に示すフローチャートを参照して、図９６のステップＳ６０５で行われる先行取得処理について説明する。なお、この先行取得処理は、アダプテーションセットには、該当するセグメントポピュラリティータイムラインのエレメントがなく、かつ、リプレゼンテーションに、該当するセグメントポピュラリティータイムラインのエレメントがある場合に行われる。
【０３１１】
ステップＳ６２１において、処理主体は、複数のアダプテーションセットを横断して、次に取得しようとするセグメント、即ち、セグメントのタイムライン上で、取得済みのセグメントに続く時間のセグメントについて、ソースの属性を示す値が、ソースパラメータにセットされている値と一致（@source=$SourceParam$）するリプレゼンテーションのセグメントポピュラリティータイムラインのレート（SP@rate）の値の比較を行って、その値が小さいリプレゼンテーションを選択し、セグメントを取得する。このとき、処理主体は、タイムライン上で同一時間区間の１または複数のセグメントを取得する。
【０３１２】
ステップＳ６２２において、処理主体は、ピリオド（Period）で表される区間の終了までセグメントを取得し終えたか否かを判定する。
【０３１３】
ステップＳ６２２において、処理主体が、セグメントを取得し終えていないと判定した場合、処理はステップＳ６２１に戻り、取得すべき後続のセグメントを同様に先行取得する処理が繰り返して行われる。
【０３１４】
一方、ステップＳ６２２において、処理主体が、セグメントを取得し終えたと判定した場合、この先行取得処理は終了される。
【０３１５】
＜セグメントを先行取得する先行取得処理の第２の処理例＞
ところで、図９６乃至図９８のフローチャートを参照して説明した処理では、リプレゼンテーションのセグメントポピュラリティータイムラインよりも、アダプテーションセットのセグメントポピュラリティータイムラインを優先して扱うことが想定されている。これに対し、例えば、MPEG DASHのMPD内の他のエレメントと同様に、下位のエレメントに指定されたプロパティが上位のエレメントに指定された値よりも優先されるという解釈にすることもできる。
【０３１６】
そこで、図９９に示すフローチャートを参照して、セグメントを先行取得する先行取得処理の第２の処理例について説明する。なお、図９９に示すフローチャートでは、アダプテーションセットおよびリプレゼンテーションのうちの少なくとも一方に、ソースの属性を示す値が、ソースパラメータにセットされている値と一致（@source="content"）することが必ず指定されている前提で、それのみに基づいた選択を行う場合について説明する。例えば、ソースの属性を示す値が、ソースパラメータにセットされている値と一致すること以外が指定されている情報を用いる場合には、図９６のフローチャートのＳ６０６およびＳ６０８に対応する処理を経て、同様の処理が繰り返される。
【０３１７】
例えば、MPDを取得すると処理が開始され、ステップＳ６３１において、処理主体は、判断基準となるソースを設定するソースパラメータに、コンテンツ提供者を示す値をセット（$SourceParam$="content"）する。これにより、以下では、コンテンツ提供者により提供される情報に基づいた判断が行われることになる。
【０３１８】
ステップＳ６３２において、処理主体は、少なくとも１つ以上のリプレゼンテーションに、ソースの属性を示す値が、ソースパラメータにセットされている値と一致（@source=$SourceParam$）するセグメントポピュラリティータイムラインのエレメントがあるか否かを判定する。
【０３１９】
ステップＳ６３２において、処理主体が、少なくとも１つ以上のリプレゼンテーションに、ソースの属性を示す値が、ソースパラメータにセットされている値と一致するセグメントポピュラリティータイムラインのエレメントがあると判定した場合、処理はステップＳ６３３に進む。
【０３２０】
ステップＳ６３３において、処理主体は、各アダプテーションセットについて選択対象のセグメント（ピリオド内の時間区間）に対する、ソースの属性を示す値が、ソースパラメータにセットされている値と一致するリプレゼンテーションのセグメントポピュラリティータイムラインのレートの最小値を、そのリプレゼンテーションを含むアダプテーションセットのセグメントポピュラリティータイムラインのレートの値と比較して、小さい方を、選択対象の（当該）アダプテーションセットのレートの値とする。
【０３２１】
ステップＳ６３３の処理後、処理はステップＳ６３４に進む。また、ステップＳ６３２において、処理主体が、少なくとも１つ以上のリプレゼンテーションに、ソースの属性を示す値が、ソースパラメータにセットされている値と一致するセグメントポピュラリティータイムラインのエレメントがないと判定した場合、処理はステップＳ６３４に進む。
【０３２２】
ステップＳ６３４において、処理主体は、ソースの属性を示す値が、ソースパラメータにセットされている値と一致（@source=$SourceParam$）するセグメントポピュラリティータイムラインのエレメントを持つアダプテーションセットの中で、セグメントポピュラリティータイムラインに最小のレートを持つアダプテーションセットを選択する。ここで、アダプテーションセットには、セグメントポピュラリティータイムラインを持たないが、上述のステップＳ６３３の処理により、レートの値を得たものも、選択の対象となるアダプテーションセットに含まれる。
【０３２３】
ステップＳ６３５において、ステップＳ６３４で選択されたアダプテーションセットより、以下で説明するような所定の条件に従って、次に取得しようとするセグメント、即ち、セグメントのタイムライン上で、取得済みのセグメントに続く時間のセグメントについて、ソースの属性を示す値が、ソースパラメータにセットされている値と一致（@source=$SourceParam$）するセグメントポピュラリティータイムラインのレート（SP@rate）の値が最小であるアダプテーションセット内のセグメントが先行取得される。
【０３２４】
例えば、この先行取得処理を行う処理主体が、CDN中間サーバ５２またはCDNエッジサーバ５３である場合、何らかの判断（例えば、過去にリクエストされているbitrate（@bandwidth）のリプレゼンテーションのみ、など）に基づいて選択されたセグメントを先行取得する。
【０３２５】
また、この先行取得処理を行う処理主体が、クライアント１３である場合、現在のネットワーク状況に応じて適切なリプレゼンテーションのセグメントを先行取得する。
【０３２６】
ステップＳ６３５の処理後、処理はステップＳ６３６に進み、処理主体は、ピリオド（Period）で表される区間の終了までセグメントを取得し終えたか否かを判定する。
【０３２７】
ステップＳ６３６において、処理主体が、セグメントを取得し終えていないと判定した場合、処理はステップＳ６３２に戻り、取得すべき後続のセグメントを同様に先行取得する処理が繰り返して行われる。
【０３２８】
一方、ステップＳ６３６において、処理主体が、セグメントを取得し終えたと判定した場合、この先行取得処理は終了される。
【０３２９】
ここで、クライアント１３が、CDN中間サーバ５２またはCDNエッジサーバ５３に適用ポリシーを指定する方法について説明する。ここでの適用ポリシーは、上述したように、MPDに記述されているセグメントポピュラリティータイムラインに従ってセグメントを先行取得する際の優先すべき情報元（種別）であるソースのことである。
【０３３０】
例えば、クライアント１３が、CDN中間サーバ５２またはCDNエッジサーバ５３に適用ポリシーを指定するのに、MPEG DASHのSANDのメッセージ（図５４参照）を利用することができる。なお、MPEG DASHのSANDのメッセージについては、非特許文献『ISO/IEC 23009-5: 2017 Server and Network Assisted DASH (SAND)』で詳細に説明されている。
【０３３１】
例えば、SANDにおいて、クライアント１３からCDNサーバなど（DASH Aware Network Element:DANE）へのメッセージは、SAND Status messageと称され、media segmentの取得リクエスト（HTTP GET request）のヘッダに、以下のような拡張ヘッダを付加することで伝達することができる。
【０３３２】
ここで、本実施の形態のコンテンツ提供システム１１では、セグメントポピュラリティータイムラインのレートを用いた先行取得をCDN中間サーバ５２またはCDNエッジサーバ５３に伝達するのに、ヘッダ「SAND-PopularityRateSource:network」をメディアセグメント（Media Segment）のリクエスト時に付加することで、どのソースの値の情報を優先して適用すべきかを伝達することができる。または、複数のソースを優先順次列挙するようなヘッダ「SAND-PopularityRateSource:content,network」を付加してもよい。
【０３３３】
また、このメッセージは、CDNエッジサーバ５３が、セグメントを取得または先行取得するときに、CDNエッジサーバ５３から上流のCDN中間サーバ５２へも、そのままフォワードされる。
【０３３４】
同様に、コンテンツプロバイダ２１が、CDN中間サーバ５２またはCDNエッジサーバ５３に適用ポリシーを指定するのにも、MPEG DASHのSANDメッセージを利用することができる。ここでの適用ポリシーは、上述したように、先行取得するセグメントの選択に際して適用すべきセグメントポピュラリティータイムラインのソースの値である。
【０３３５】
例えば、コンテンツプロバイダ２１とCDN中間サーバ５２またはCDNエッジサーバ５３との間でやり取りされるメッセージは、PED（Parameter Enhancing Delivery）メッセージと称され、先行取得するセグメントの選択に際して適用すべきセグメントポピュラリティータイムラインのソースの値の伝達に、PEDメッセージが用いられる。
【０３３６】
なお、現状、MPEG規格ではPEDメッセージはアーキテクチャ上で言及されているのみで、具体的なメッセージは定義されていない。また、PEDメッセージを送受信する配信サーバ５１や、CDN中間サーバ５２およびCDNエッジサーバ５３は、SAND規格において、DASH Aware Network Element（DANE）と称される。
【０３３７】
また、DANE間のSANDメッセージのやり取りは、次に説明する２通りの方法がSAND規格に規定されている。
【０３３８】
即ち、第１の方法は、上流のDANEに対する下流のDANEからの、例えばMedia Segment取得のためのHTTP GET requestに対するresponseに、SAND Messageを取得するためのURLを記載した拡張HTTP headerを付加する。そして、それを受信した下流のDANEが、当該URLにHTTP GET requestを送信して、SANDメッセージを取得する方法である。
【０３３９】
また、第２の方法は、DANE間で予めSANDメッセージ交換のためのWebSocketチャネルを確立しておき、そのチャネルを使ってメッセージを送る方法である。
【０３４０】
ここでは、第１の方法および第２の方法のどちらを使用しても目的は達成されるが、第１の方法では、メッセージの伝達先がMedia Segmentの取得リクエストを送付してきた場合に限られるため、第２の方法を使用することが望ましい。もちろん、第１の方法を使用しても、一定の範囲では効果を得ることができる。なお、どちらの方法を使用する場合でも、SANDメッセージ自体は、XML文書で記述されることが想定されており、具体的には、図１００に示すように表現される。
【０３４１】
または、PopularityRateSourceのエレメントを、優先度順に複数列挙して、図１０１のように表現することができる。図１０１に示す例では、ソースがコンテンツ提供者（source="content"）であるセグメントポピュラリティータイムラインが、ソースがネットワーク（source="network"）であるセグメントポピュラリティータイムラインのものよりも優先されることが表されている。
【０３４２】
なお、図１００および図１０１では、ここで、<CommonEnvelope>にはattributeとして enderID，generationTimeを付加することができる。また、messageIdの値は、SANDメッセージの種別を表すが、図示する例は、規格に未定義の新たなメッセージのため"reserved for future ISO use"とされている値とした。
【０３４３】
以上のように、複数のソースから提供されるセグメントの「人気度」、または、クライアント１３で消費される「確からしさ」といった情報を、メタデータとしてMPEG DASHのMPD内に簡潔に表現することができる。従って、これに応じた配信リソース配分の最適化や、CDN中間サーバ５２、CDNエッジサーバ５３、またはクライアント１３により、セグメントの先行（予測）取得を行うことが容易に可能となる。
【０３４４】
図１０２には、CDNサーバ（DANE）へのセグメントポピュラリティータイムラインの利用時に優先すべきソース（@source）の値を通知する処理の概念が示されている。
【０３４５】
図１０２に示すように、DASH配信サーバ６１は、セグメントを先行取得する際の判断時に優先すべきソースの値の伝達を、SAND PEDメッセージを使用して、複数のCDNサーバ６２それぞれに伝達する。そして、DASH配信サーバ６１からCDNサーバ６２へ、セグメントポピュラリティータイムライン（SPT）を含むMPD、および、メディアセグメントが送信される。
【０３４６】
また、MPDクライアント６３は、セグメントを先行取得する際の判断時に優先すべきソースの値の伝達を、SAND Statusメッセージを使用して、複数のCDNサーバ６２それぞれに伝達する。そして、CDNサーバ６２からMPDクライアント６３へ、セグメントポピュラリティータイムライン（SPT）を含むMPD、および、メディアセグメントが送信される。
【０３４７】
＜コンピュータの構成例＞
なお、上述のフローチャートを参照して説明した各処理は、必ずしもフローチャートとして記載された順序に沿って時系列に処理する必要はなく、並列的あるいは個別に実行される処理（例えば、並列処理あるいはオブジェクトによる処理）も含むものである。また、プログラムは、１のCPUにより処理されるものであっても良いし、複数のCPUによって分散処理されるものであっても良い。
【０３４８】
また、上述した一連の処理（コンテンツ配信方法）は、ハードウエアにより実行することもできるし、ソフトウエアにより実行することもできる。一連の処理をソフトウエアにより実行する場合には、そのソフトウエアを構成するプログラムが、専用のハードウエアに組み込まれているコンピュータ、または、各種のプログラムをインストールすることで、各種の機能を実行することが可能な、例えば汎用のパーソナルコンピュータなどに、プログラムが記録されたプログラム記録媒体からインストールされる。
【０３４９】
図１０３は、上述した一連の処理をプログラムにより実行するコンピュータのハードウエアの構成例を示すブロック図である。
【０３５０】
コンピュータにおいて、CPU（Central Processing Unit）１０１，ROM（Read Only Memory）１０２，RAM（Random Access Memory）１０３は、バス１０４により相互に接続されている。
【０３５１】
バス１０４には、さらに、入出力インタフェース１０５が接続されている。入出力インタフェース１０５には、キーボード、マウス、マイクロホンなどよりなる入力部１０６、ディスプレイ、スピーカなどよりなる出力部１０７、ハードディスクや不揮発性のメモリなどよりなる記憶部１０８、ネットワークインタフェースなどよりなる通信部１０９、磁気ディスク、光ディスク、光磁気ディスク、或いは半導体メモリなどのリムーバブルメディア１１１を駆動するドライブ１１０が接続されている。
【０３５２】
以上のように構成されるコンピュータでは、CPU１０１が、例えば、記憶部１０８に記憶されているプログラムを、入出力インタフェース１０５及びバス１０４を介して、RAM１０３にロードして実行することにより、上述した一連の処理が行われる。
【０３５３】
コンピュータ（CPU１０１）が実行するプログラムは、例えば、磁気ディスク（フレキシブルディスクを含む）、光ディスク（CD-ROM(Compact Disc-Read Only Memory),DVD(Digital Versatile Disc)等）、光磁気ディスク、もしくは半導体メモリなどよりなるパッケージメディアであるリムーバブルメディア１１１に記録して、あるいは、ローカルエリアネットワーク、インターネット、デジタル衛星放送といった、有線または無線の伝送媒体を介して提供される。
【０３５４】
そして、プログラムは、リムーバブルメディア１１１をドライブ１１０に装着することにより、入出力インタフェース１０５を介して、記憶部１０８にインストールすることができる。また、プログラムは、有線または無線の伝送媒体を介して、通信部１０９で受信し、記憶部１０８にインストールすることができる。その他、プログラムは、ROM１０２や記憶部１０８に、あらかじめインストールしておくことができる。
【０３５５】
＜構成の組み合わせ例＞
【０３５６】
なお、本技術は以下のような構成も取ることができる。
（１）
コンテンツを再生するクライアントへ、トランスポート特性の異なる複数のネットワークを使用して前記コンテンツを配信するコンテンツ配信装置と、
特徴の異なる複数のストリームにより構成される前記コンテンツを配信するにあたり、それぞれの前記ストリームの配信を、複数の前記ネットワークで分配する際の判断基準となるポリシーを、前記コンテンツ配信装置に提供するコンテンツ提供装置と
を備えるコンテンツ提供システム。
（２）
前記ポリシーでは、所定のネットワークに対する負荷の大きさを表すレベルごとに、特徴の異なる複数のストリームのうちの、そのネットワークで配信するストリームと、他のネットワークで配信するストリームとが分類される
上記（１）に記載のコンテンツ提供システム。
（３）
前記コンテンツ提供装置は、前記ポリシーおよび前記レベルを、MPEG DASHにおいてメタ情報を記述するのに用いられるMPD（Media Presentation Description）に記述し、前記MPDを前記コンテンツ配信装置に転送する
上記（２）に記載のコンテンツ提供システム。
（４）
前記コンテンツ配信装置は、前記コンテンツ提供装置から転送された前記MPDを、前記MPDに記述されている前記ポリシーおよび前記レベルを参照し、前記レベルに応じて書き換える
上記（３）に記載のコンテンツ提供システム。
（５）
前記コンテンツ配信装置は、複数のセグメントマネジャを有しており、それらのセグメントマネジャごとに前記MPDが書き換えられる
上記（３）または（４）に記載のコンテンツ提供システム。
（６）
前記コンテンツ提供装置は、前記ポリシーおよび前記レベルを、MPEG DASHにおいてイベントを通知する機能を利用して前記コンテンツを再生するクライアントに提供する
上記（２）に記載のコンテンツ提供システム。
（７）
前記コンテンツ提供装置は、前記ポリシーおよび前記レベルを、前記コンテンツ提供装置と前記コンテンツ配信装置、または、前記コンテンツを再生するクライアントとの間でやりとりするメッセージングインターフェイス利用して前記コンテンツ配信装置、または、前記コンテンツを再生するクライアントに提供する
上記（２）に記載のコンテンツ提供システム。
（８）
コンテンツを再生するクライアントへ、トランスポート特性の異なる複数のネットワークを使用して前記コンテンツを配信し、
特徴の異なる複数のストリームにより構成される前記コンテンツを配信するにあたり、それぞれの前記ストリームの配信を、複数の前記ネットワークで分配する際の判断基準となるポリシーを提供する
ステップを含むコンテンツ提供方法。
（９）
コンテンツを再生するクライアントへ、トランスポート特性の異なる複数のネットワークを使用して前記コンテンツを配信し、
特徴の異なる複数のストリームにより構成される前記コンテンツを配信するにあたり、それぞれの前記ストリームの配信を、複数の前記ネットワークで分配する際の判断基準となるポリシーを提供する
ステップを含む処理をコンピュータに実行させるプログラム。
（１０）
コンテンツ配信ネットワークを構成するサーバと、
前記コンテンツ配信ネットワークを介して配信されるコンテンツの提供を受けるクライアント装置と
を備え、
前記サーバまたは前記クライアント装置が、複数の提供元から提供される優先度が、時間的に変化するように記述されるメタデータを参照して、前記優先度の高い順に、前記コンテンツを構成するセグメントを先行取得する
コンテンツ提供システム。
（１１）
前記優先度は、前記コンテンツを提供するコンテンツ提供者が提供し、前記コンテンツを作成した作成者の意図に従った値で記述される
上記（１０）に記載のコンテンツ提供システム。
（１２）
前記優先度は、前記コンテンツ配信ネットワークにより提供され、前記コンテンツ配信ネットワークを介して前記コンテンツが過去に配信されたときに実測された統計に基づく値で記述される
上記（１０）または（１１）に記載のコンテンツ提供システム。
（１３）
前記メタデータには、前記優先度が適用されるセグメントを指定する要素が記述される
上記（１０）から（１２）までのいずれかに記載のコンテンツ提供システム。
（１４）
前記優先度が適用される一連のセグメントの最初のセグメントを識別する番号、および、それらの一連のセグメントのセグメント数を用いて、前記優先度が適用されるセグメントが指定される
上記（１３）に記載のコンテンツ提供システム。
（１５）
前記優先度の適用が開始される開始時間、および、前記優先度の適用が終了される終了時間を用いて、前記優先度が適用される期間が指定される
上記（１０）から（１２）までのいずれかに記載のコンテンツ提供システム。
（１６）
前記セグメントを先行取得する際に参照される前記メタデータは、MPEG DASHのMPDに記述されるアダプテーションセットに対する子エレメントとして定義される
上記（１０）から（１５）までのいずれかに記載のコンテンツ提供システム。
（１７）
前記セグメントを先行取得する際に参照される前記メタデータは、MPEG DASHのMPDに記述されるリプレゼンテーションに対する子エレメントとして定義される
上記（１０）から（１５）までのいずれかに記載のコンテンツ提供システム。
（１８）
前記セグメントを先行取得する際に参照される前記メタデータは、MPEG DASHのMPDにおいて複数のネットワークで分配する際の判断基準となるポリシー／レベルの記述で用いられるディストリビューションポリシーのエレメントにおけるレベルを利用して指定される
上記（１０）から（１５）までのいずれかに記載のコンテンツ提供システム。
（１９）
コンテンツ提供システムは、
コンテンツ配信ネットワークを構成するサーバと、
前記コンテンツ配信ネットワークを介して配信されるコンテンツの提供を受けるクライアント装置と
を備え、
前記サーバまたは前記クライアント装置が、複数の提供元から提供される優先度が、時間的に変化するように記述されるメタデータを参照して、前記優先度の高い順に、前記コンテンツを構成するセグメントを先行取得すること
を含むコンテンツ提供方法。
（２０）
コンテンツ配信ネットワークを構成するサーバと、
前記コンテンツ配信ネットワークを介して配信されるコンテンツの提供を受けるクライアント装置と
を備えるコンテンツ提供システムのコンピュータに、
前記サーバまたは前記クライアント装置が、複数の提供元から提供される優先度が、時間的に変化するように記述されるメタデータを参照して、前記優先度の高い順に、前記コンテンツを構成するセグメントを先行取得すること
を含む処理を実行させるプログラム。
【０３５７】
なお、本実施の形態は、上述した実施の形態に限定されるものではなく、本開示の要旨を逸脱しない範囲において種々の変更が可能である。
【符号の説明】
【０３５８】
１１  コンテンツ提供システム，  １２  全天球カメラ，  １３  クライアント，  １４  放送ネットワーク，  １５  双方向ネットワーク，  ２１  コンテンツプロバイダ，  ２２  CDNサービスプロバイダ，  ２３  放送サービスプロバイダ，  ３１  CDNセグメントマネジャ
【図１】
2018173874.tif 000003
【図２】
2018173874.tif 000004
【図３】
2018173874.tif 000005
【図４】
2018173874.tif 000006
【図５】
2018173874.tif 000007
【図６】
2018173874.tif 000008
【図７】
2018173874.tif 000009
【図８】
2018173874.tif 000010
【図９】
2018173874.tif 000011
【図１０】
2018173874.tif 000012
【図１１】
2018173874.tif 000013
【図１２】
2018173874.tif 000014
【図１３】
2018173874.tif 000015
【図１４】
2018173874.tif 000016
【図１５】
2018173874.tif 000017
【図１６】
2018173874.tif 000018
【図１７】
2018173874.tif 000019
【図１８】
2018173874.tif 000020
【図１９】
2018173874.tif 000021
【図２０】
2018173874.tif 000022
【図２１】
2018173874.tif 000023
【図２２】
2018173874.tif 000024
【図２３】
2018173874.tif 000025
【図２４】
2018173874.tif 000026
【図２５】
2018173874.tif 000027
【図２６】
2018173874.tif 000028
【図２７】
2018173874.tif 000029
【図２８】
2018173874.tif 000030
【図２９】
2018173874.tif 000031
【図３０】
2018173874.tif 000032
【図３１】
2018173874.tif 000033
【図３２】
2018173874.tif 000034
【図３３】
2018173874.tif 000035
【図３４】
2018173874.tif 000036
【図３５】
2018173874.tif 000037
【図３６】
2018173874.tif 000038
【図３７】
2018173874.tif 000039
【図３８】
2018173874.tif 000040
【図３９】
2018173874.tif 000041
【図４０】
2018173874.tif 000042
【図４１】
2018173874.tif 000043
【図４２】
2018173874.tif 000044
【図４３】
2018173874.tif 000045
【図４４】
2018173874.tif 000046
【図４５】
2018173874.tif 000047
【図４６】
2018173874.tif 000048
【図４７】
2018173874.tif 000049
【図４８】
2018173874.tif 000050
【図４９】
2018173874.tif 000051
【図５０】
2018173874.tif 000052
【図５１】
2018173874.tif 000053
【図５２】
2018173874.tif 000054
【図５３】
2018173874.tif 000055
【図５４】
2018173874.tif 000056
【図５５】
2018173874.tif 000057
【図５６】
2018173874.tif 000058
【図５７】
2018173874.tif 000059
【図５８】
2018173874.tif 000060
【図５９】
2018173874.tif 000061
【図６０】
2018173874.tif 000062
【図６１】
2018173874.tif 000063
【図６２】
2018173874.tif 000064
【図６３】
2018173874.tif 000065
【図６４】
2018173874.tif 000066
【図６５】
2018173874.tif 000067
【図６６】
2018173874.tif 000068
【図６７】
2018173874.tif 000069
【図６８】
2018173874.tif 000070
【図６９】
2018173874.tif 000071
【図７０】
2018173874.tif 000072
【図７１】
2018173874.tif 000073
【図７２】
2018173874.tif 000074
【図７３】
2018173874.tif 000075
【図７４】
2018173874.tif 000076
【図７５】
2018173874.tif 000077
【図７６】
2018173874.tif 000078
【図７７】
2018173874.tif 000079
【図７８】
2018173874.tif 000080
【図７９】
2018173874.tif 000081
【図８０】
2018173874.tif 000082
【図８１】
2018173874.tif 000083
【図８２】
2018173874.tif 000084
【図８３】
2018173874.tif 000085
【図８４】
2018173874.tif 000086
【図８５】
2018173874.tif 000087
【図８６】
2018173874.tif 000088
【図８７】
2018173874.tif 000089
【図８８】
2018173874.tif 000090
【図８９】
2018173874.tif 000091
【図９０】
2018173874.tif 000092
【図９１】
2018173874.tif 000093
【図９２】
2018173874.tif 000094
【図９３】
2018173874.tif 000095
【図９４】
2018173874.tif 000096
【図９５】
2018173874.tif 000097
【図９６】
2018173874.tif 000098
【図９７】
2018173874.tif 000099
【図９８】
2018173874.tif 000100
【図９９】
2018173874.tif 000101
【図１００】
2018173874.tif 000102
【図１０１】
2018173874.tif 000103
【図１０２】
2018173874.tif 000104
【図１０３】
2018173874.tif 000105
【手続補正書】
【提出日】平成30年7月30日(2018.7.30)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
コンテンツ配信ネットワークを構成するサーバと、
前記コンテンツ配信ネットワークを介して配信されるコンテンツの提供を受けるクライアント装置と
を備え、
前記サーバまたは前記クライアント装置が、複数の提供元から提供される優先度が、時間的に変化するように記述されるメタデータを参照して、前記優先度の高い順に、前記コンテンツを構成するセグメントを先行取得する
コンテンツ提供システム。
【請求項２】
前記優先度は、前記コンテンツを提供するコンテンツ提供者が提供し、前記コンテンツを作成した作成者の意図に従った値で記述される
請求項１に記載のコンテンツ提供システム。
【請求項３】
前記優先度は、前記コンテンツ配信ネットワークにより提供され、前記コンテンツ配信ネットワークを介して前記コンテンツが過去に配信されたときに実測された統計に基づく値で記述される
請求項１に記載のコンテンツ提供システム。
【請求項４】
前記メタデータには、前記優先度が適用されるセグメントを指定する要素が記述される
請求項１に記載のコンテンツ提供システム。
【請求項５】
前記優先度が適用される一連のセグメントの最初のセグメントを識別する番号、および、それらの一連のセグメントのセグメント数を用いて、前記優先度が適用されるセグメントが指定される
請求項４に記載のコンテンツ提供システム。
【請求項６】
前記優先度の適用が開始される開始時間、および、前記優先度の適用が終了される終了時間を用いて、前記優先度が適用される期間が指定される
請求項１に記載のコンテンツ提供システム。
【請求項７】
前記セグメントを先行取得する際に参照される前記メタデータは、ＭＰＥＧ  ＤＡＳＨのＭＰＤに記述されるアダプテーションセットに対する子エレメントとして定義される
請求項１に記載のコンテンツ提供システム。
【請求項８】
前記セグメントを先行取得する際に参照される前記メタデータは、ＭＰＥＧ  ＤＡＳＨのＭＰＤに記述されるリプレゼンテーションに対する子エレメントとして定義される
請求項１に記載のコンテンツ提供システム。
【請求項９】
前記セグメントを先行取得する際に参照される前記メタデータは、ＭＰＥＧ  ＤＡＳＨのＭＰＤにおいて複数のネットワークで分配する際の判断基準となるポリシー／レベルの記述で用いられるディストリビューションポリシーのエレメントにおけるレベルを利用して指定される  請求項１に記載のコンテンツ提供システム。
【請求項１０】
コンテンツ提供システムは、
コンテンツ配信ネットワークを構成するサーバと、
前記コンテンツ配信ネットワークを介して配信されるコンテンツの提供を受けるクライアント装置と
を備え、
前記サーバまたは前記クライアント装置が、複数の提供元から提供される優先度が、時間的に変化するように記述されるメタデータを参照して、前記優先度の高い順に、前記コンテンツを構成するセグメントを先行取得すること
を含むコンテンツ提供方法。
【請求項１１】
コンテンツ配信ネットワークを構成するサーバと、
前記コンテンツ配信ネットワークを介して配信されるコンテンツの提供を受けるクライアント装置と
を備えるコンテンツ提供システムのコンピュータに、
前記サーバまたは前記クライアント装置が、複数の提供元から提供される優先度が、時間的に変化するように記述されるメタデータを参照して、前記優先度の高い順に、前記コンテンツを構成するセグメントを先行取得すること
を含む処理を実行させるプログラム。
【請求項１２】
（削除）
【請求項１３】
（削除）
【請求項１４】
（削除）
【請求項１５】
（削除）
【請求項１６】
（削除）
【請求項１７】
（削除）
【請求項１８】
（削除）
【請求項１９】
（削除）
【請求項２０】
（削除）
【国際調査報告】
2018173874.tif 000106
2018173874.tif 000107
2018173874.tif 000108
2018173874.tif 000109
2018173874.tif 000110
2018173874.tif 000111
2018173874.tif 000112
2018173874.tif 000113
2018173874.tif 000114
2018173874.tif 000115