(57)【要約】  本技術は、放送ネットワークを利用して、ストリーミングトラフィックを負荷分散させることができるようにする情報処理装置、及び、情報処理方法に関する。情報処理装置が、複数の受信装置から送信されてくる、コンテンツのリクエストを処理して、リクエストに含まれる受信装置で受信可能な放送エリアを識別するための第１の識別情報、及び、コンテンツを識別するための第２の識別情報に基づいて、リクエストに対するレスポンスの返信経路として、通信経由での返信と、放送経由での返信とを動的に切り替えることで、ストリーミングトラフィックを負荷分散させることができるようになる。本技術は、例えば、サーババックエンド側に設置される専用のサーバ（スイッチングサーバ）に適用することができる。
2018079295.tif 000002
【特許請求の範囲】
【請求項１】
複数の受信装置から送信されてくる、コンテンツのリクエストを処理して、前記リクエストに対するレスポンスを返信する処理部を備え、
前記リクエストは、前記受信装置で受信可能な放送エリアを識別するための第１の識別情報と、前記コンテンツを識別するための第２の識別情報を含み、
前記処理部は、前記第１の識別情報及び前記第２の識別情報に基づいて、前記レスポンスの返信経路として、通信経由での返信と、放送経由での返信とを動的に切り替える
情報処理装置。
【請求項２】
前記処理部は、
通常時の場合、前記レスポンスの返信経路として、通信経由の経路を選択し、
通信経由の経路に負荷がかかっている場合、前記レスポンスの返信経路として、放送経由の経路を選択する
請求項１に記載の情報処理装置。
【請求項３】
前記処理部は、
前記第２の識別情報により識別される前記コンテンツごとに、一定の期間で、前記リクエストの数をカウントし、
そのカウント値が、あらかじめ定められた閾値以上となった場合に、該当する第２の識別情報を含むリクエストに対するレスポンスが、前記第１の識別情報に基づいた放送経由で返信されるようにする
請求項２に記載の情報処理装置。
【請求項４】
前記処理部は、前記レスポンスの返信経路が、通信経由の経路から放送経由の経路に切り替えられる場合に、前記レスポンスを放送経由で返信する第１のサーバに対し、放送経由での返信が行われることを前記受信装置に通知させるために、制御情報の更新を要求する
請求項２に記載の情報処理装置。
【請求項５】
前記処理部は、前記第１の識別情報により識別される放送エリア内の前記第１のサーバに対し、前記レスポンスとして、第２のサーバから配信されるコンテンツのストリームのセグメントを転送する
請求項４に記載の情報処理装置。
【請求項６】
前記処理部は、前記受信装置が放送経由で返信される前記レスポンスの受信に失敗した場合に、放送経由で返信される前記レスポンスと同一のレスポンスが、通信経由で返信されるようにする
請求項５に記載の情報処理装置。
【請求項７】
前記第１の識別情報は、RF(Radio Frequency)チャネルに対応した情報であり、
前記第２の識別情報は、コンテンツIDである
請求項１に記載の情報処理装置。
【請求項８】
前記コンテンツのストリームは、前記第２のサーバから、ライブストリーム又はVOD(Video On Demand)ストリームとして配信される
請求項５に記載の情報処理装置。
【請求項９】
前記通信経由の経路は、インターネットを含む経路であり、
前記放送経由の経路は、IP(Internet Protocol)伝送方式に対応した地上波放送による伝送経路である
請求項１に記載の情報処理装置。
【請求項１０】
情報処理装置の情報処理方法において、
前記情報処理装置が、
複数の受信装置から送信されてくる、コンテンツのリクエストを処理して、前記リクエストに含まれる前記受信装置で受信可能な放送エリアを識別するための第１の識別情報、及び、前記コンテンツを識別するための第２の識別情報に基づいて、前記リクエストに対するレスポンスの返信経路として、通信経由での返信と、放送経由での返信とを動的に切り替える
ステップを含む情報処理方法。
【請求項１１】
コンテンツのリクエストを処理して、自身が受信可能な放送エリアを識別するための第１の識別情報と、前記コンテンツを識別するための第２の識別情報を挿入する処理部を備え、
前記処理部は、送信装置から送信されてくる、前記リクエストに対するレスポンスとして、通信経由で返信されるレスポンス、又は放送経由で返信されるレスポンスを処理する
情報処理装置。
【請求項１２】
前記レスポンスは、通常時の場合、通信経由で返信され、通信経由の経路に負荷がかかっている場合、放送経由で返信される
請求項１１に記載の情報処理装置。
【請求項１３】
前記処理部は、前記レスポンスを放送経由で返信する第１のサーバから送信されてくる周知情報に基づいて、通信経由の経路に負荷がかかっている場合に、放送経由の経路で前記レスポンスを返信するサービスが利用可能であるかどうかを認識する
請求項１２に記載の情報処理装置。
【請求項１４】
前記処理部は、
前記サービスが利用可能である場合、前記リクエストに対し、前記第１の識別情報及び前記第２の識別情報を挿入し、
前記サービスが利用できない場合、前記リクエストに対し、前記第２の識別情報のみを挿入する
請求項１３に記載の情報処理装置。
【請求項１５】
前記周知情報は、前記コンテンツとともに配信される制御情報に含まれる
請求項１４に記載の情報処理装置。
【請求項１６】
前記周知情報は、前記コンテンツに対して事前に配信される番組情報に含まれる
請求項１４に記載の情報処理装置。
【請求項１７】
前記第１の識別情報は、RFチャネルに対応した情報であり、
前記第２の識別情報は、コンテンツIDであり、
前記処理部は、前記第１の識別情報と、前記第２の識別情報を、前記リクエストのHTTP(Hypertext Transfer Protocol)ヘッダの拡張部分に挿入する
請求項１１に記載の情報処理装置。
【請求項１８】
前記コンテンツのストリームは、第２のサーバから、ライブストリーム又はVODストリームとして配信される
請求項１１に記載の情報処理装置。
【請求項１９】
前記通信経由の経路は、インターネットを含む経路であり、
前記放送経由の経路は、IP伝送方式に対応した地上波放送による伝送経路である
請求項１１に記載の情報処理装置。
【請求項２０】
情報処理装置の情報処理方法において、
前記情報処理装置が、
コンテンツのリクエストを処理して、自身が受信可能な放送エリアを識別するための第１の識別情報と、前記コンテンツを識別するための第２の識別情報を挿入し、
送信装置から送信されてくる、前記リクエストに対するレスポンスとして、通信経由で返信されるレスポンス、又は放送経由で返信されるレスポンスを処理する
ステップを含む情報処理方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本技術は、情報処理装置、及び、情報処理方法に関し、特に、放送ネットワークを利用して、ストリーミングトラフィックを負荷分散させることができるようにした情報処理装置、及び、情報処理方法に関する。
【背景技術】
【０００２】
IPTV(Internet Protocol Television)等のインターネットストリーミングにおける標準化の流れとして、HTTP(Hypertext Transfer Protocol)ストリーミングによるVOD（Video On Demand）ストリーミングや、ライブストリーミングに適用される方式の標準化が行われている。【０００３】
特に、ISO/IEC/MPEGで標準化が行われているMPEG-DASH(Dynamic Adaptive Streaming over HTTP)が注目されている（例えば、非特許文献１参照）。【０００４】
MPEG-DASHは、MPD（Media Presentation Description）と呼ばれるメタファイルと、そこに記述されるチャンク化されたオーディオ、ビデオ、又は字幕等のメディアデータのアドレス（URL：Uniform Resource Locator）に従い、ストリームデータを取得して再生するものである。
【先行技術文献】
【非特許文献】
【０００５】
【非特許文献１】ISO/IEC 23009-1:2012 Information technology Dynamic adaptive streaming over HTTP (DASH)
【発明の概要】
【発明が解決しようとする課題】
【０００６】
ところで、MPEG-DASH等のストリーミングのトラフィックで、インターネットに多大な負荷がかかり、トラフィックが輻輳しそうな場合に、放送ネットワークを利用して、トラフィックを負荷分散させるという要件がある。【０００７】
しかしながら、そのような、インターネットトラフィックのオフロード先に、放送ネットワークを利用するための技術方式は確立されておらず、放送ネットワークを利用して、ストリーミングトラフィックを負荷分散させるための技術が求められていた。【０００８】
本技術はこのような状況に鑑みてなされたものであり、放送ネットワークを利用して、ストリーミングトラフィックを負荷分散させることができるようにするものである。
【課題を解決するための手段】
【０００９】
本技術の第１の側面の情報処理装置は、複数の受信装置から送信されてくる、コンテンツのリクエストを処理して、前記リクエストに対するレスポンスを返信する処理部を備え、前記リクエストは、前記受信装置で受信可能な放送エリアを識別するための第１の識別情報と、前記コンテンツを識別するための第２の識別情報を含み、前記処理部は、前記第１の識別情報及び前記第２の識別情報に基づいて、前記レスポンスの返信経路として、通信経由での返信と、放送経由での返信とを動的に切り替える情報処理装置である。【００１０】
本技術の第１の側面の情報処理装置は、独立した装置であってもよいし、１つの装置を構成している内部ブロックであってもよい。また、本技術の第１の側面の情報処理方法は、上述した本技術の第１の側面の情報処理装置に対応する情報処理方法である。【００１１】
本技術の第１の側面の情報処理装置、及び、情報処理方法においては、複数の受信装置から送信されてくる、コンテンツのリクエストを処理して、前記リクエストに対するレスポンスが返信される。また、前記リクエストには、前記受信装置で受信可能な放送エリアを識別するための第１の識別情報と、前記コンテンツを識別するための第２の識別情報が含まれ、前記第１の識別情報及び前記第２の識別情報に基づいて、前記レスポンスの返信経路として、通信経由での返信と、放送経由での返信とが、動的に切り替えられる。【００１２】
本技術の第２の側面の情報処理装置は、コンテンツのリクエストを処理して、自身が受信可能な放送エリアを識別するための第１の識別情報と、前記コンテンツを識別するための第２の識別情報を挿入する処理部を備え、前記処理部は、送信装置から送信されてくる、前記リクエストに対するレスポンスとして、通信経由で返信されるレスポンス、又は放送経由で返信されるレスポンスを処理する情報処理装置である。【００１３】
本技術の第２の側面の情報処理装置は、独立した装置であってもよいし、１つの装置を構成している内部ブロックであってもよい。また、本技術の第２の側面の情報処理方法は、上述した本技術の第２の側面の情報処理装置に対応する情報処理方法である。【００１４】
本技術の第２の側面の情報処理装置、及び、情報処理方法においては、コンテンツのリクエストを処理して、自身が受信可能な放送エリアを識別するための第１の識別情報と、前記コンテンツを識別するための第２の識別情報が挿入され、送信装置から送信されてくる、前記リクエストに対するレスポンスとして、通信経由で返信されるレスポンス、又は放送経由で返信されるレスポンスが処理される。
【発明の効果】
【００１５】
本技術の第１の側面、及び、第２の側面によれば、放送ネットワークを利用して、ストリーミングトラフィックを負荷分散させることができる。【００１６】
なお、ここに記載された効果は必ずしも限定されるものではなく、本開示中に記載されたいずれかの効果であってもよい。
【図面の簡単な説明】
【００１７】
【図１】本技術の概要を説明する図である。
【図２】本技術を適用した送受信システムの一実施の形態の構成を示すブロック図である。
【図３】送信側の各サーバの構成例を示すブロック図である。
【図４】受信側の各装置の構成例を示すブロック図である。
【図５】本技術のIP伝送方式のプロトコルスタックの例を示す図である。
【図６】MPDメタデータの内容を示す図である。
【図７】MPDメタデータの記述例を示す図である。
【図８】図２の送受信システムの具体的な構成例を示す図である。
【図９】スイッチングサーバを通過するセグメントリクエストの時間遷移の例を示す図である。
【図１０】処理フロー（第１段階）を説明する図である。
【図１１】処理フロー（第２段階）を説明する図である。
【図１２】処理フロー（第３段階）を説明する図である。
【図１３】処理フロー（第４段階）を説明する図である。
【図１４】セグメントのリクエスト/レスポンスのトラフィック（第１の期間）について説明する図である。
【図１５】セグメントのリクエスト/レスポンスのトラフィック（第２の期間）について説明する図である。
【図１６】セグメントのリクエスト/レスポンスのトラフィック（第３の期間）について説明する図である。
【図１７】セグメントのリクエスト/レスポンスのトラフィック（第４の期間）について説明する図である。
【図１８】本技術の拡張ヘッダの例を示す図である。
【図１９】拡張ヘッダとして挿入される識別情報の例を示す図である。
【図２０】HTTPリクエストの例を示す図である。
【図２１】拡張ヘッダが挿入されたHTTPリクエストの例を示す図である。
【図２２】SLTメタデータのserviceCategory属性の値の例を示す図である。
【図２３】SLTメタデータの記述例を示す図である。
【図２４】ESGのServiceType要素の値の例を示す図である。
【図２５】ESG情報の記述例を示す図である。
【図２６】放送オフローディングサービスが利用可能である場合のXMLフラグメントの関係を示す図である。
【図２７】ESGサービスの画面の表示例を示す図である。
【図２８】コンテンツ送受信処理の流れを説明するフローチャートである。
【図２９】コンテンツ送受信処理の流れを説明するフローチャートである。
【図３０】コンテンツ送受信処理の流れを説明するフローチャートである。
【図３１】コンテンツ送受信処理の流れを説明するフローチャートである。
【図３２】コンピュータの構成例を示す図である。
【発明を実施するための形態】
【００１８】
以下、図面を参照しながら本技術の実施の形態について説明する。なお、説明は以下の順序で行うものとする。
【００１９】
１．システムの構成
２．具体的な運用例
３．リクエスト/レスポンスのトラフィックの例
４．識別情報の挿入方法
５．放送オフローディングサービスの周知方法
６．コンテンツ送受信処理
７．変形例
８．コンピュータの構成
【００２０】
＜１．システムの構成＞
【００２１】
（本技術の概要）
図１は、本技術の概要を説明する図である。
【００２２】
放送ネットワークを、ライブストリーミング等のインターネットトラフィックのオフロード先に利用するというトラフィックオフローディングの要件がある。ここで、トラフィックオフローディングとは、インターネットのトラフィックが輻輳しそうな場合に、ショートカットパスとしての放送ネットワークを利用して、トラフィックを負荷分散させることをいう。
【００２３】
例えば、図１においては、MPEG-DASHによるDASHライブストリーミングのトラフィックの一部を、放送ネットワークにオフロードしている様子を模式的に表している。
【００２４】
すなわち、図１において、インターネット等の双方向ネットワークでは、DASHライブストリーミングトラフィックで、多大な負荷がかかっている状態となっている。そのため、図中の矢印Ａで示すように、中央の領域のDASHライブストリーミングトラフィックを、放送ネットワーク（一方向ネットワーク）にオフロードしている。
【００２５】
ただし、放送ネットワークへのオフロードを行う際には、オフロード先の放送ネットワークが、編成された放送番組の放送を行っていない、放送編成番組の間の空き時間である必要がある。あるいは、ここでは、放送編成番組の放送ストリーミングに必要な周波数の帯域幅が小さい場合に、オフロード用の周波数帯域（空帯域）を用意しておくようにしてもよい。
【００２６】
このように、DASHライブストリーミングトラフィックの一部を、放送ネットワークにオフロード（負荷分散、委譲）することで、トラフィックがオフロードされた図中の中央の領域では、インターネット等の双方向ネットワークの負荷が軽減されている。
【００２７】
一方で、図中の左右の枠Ｂの領域では、DASHライブストリーミングトラフィックのオフロードが行われていないため、インターネット等の双方向ネットワークでは、DASHライブストリーミングトラフィックによる多大な負荷がかかったままとなる。
【００２８】
以上のように、DASHライブストリーミングトラフィックのオフロード先を、放送ネットワークとすることで、トラフィックの負荷分散を行うことができるが、現状では、そのような技術方式は確立されていない。
【００２９】
例えば、ストリーミングサービスのトラフィックが、特に集中しているエリアを特定して、そのエリアを放送対象とする放送ネットワークに対し、優先的にトラフィックの一部をオフロードする機能が必要とされる。
【００３０】
また、例えば、ストリーミングサービスのトラフィックを、放送ネットワークにオフロードしているという状況を受信側の装置（デバイス）に周知して、受信側の装置（デバイス）に対し、放送ネットワークと双方向ネットワークのどちらから配信されるストリーミングを待つべきかについて、ストリーミングの取得先の判断基準を提供する機能が必要とされる。
【００３１】
ストリーミング配信におけるリソースの有効利用の側面から、このような機能が必須となる可能性があるが、現状では、このような機能を提供するための技術方式は確立されていない。
【００３２】
一方で、このような機能が、特定の放送ネットワークに対応したチューナを実装する受信側の端末（ローカルプロキシサーバ）に統合（インテグレート）されることにより、チューナを実装していない受信側の端末（一般のクライアント）に、共通に適用可能な放送ネットワークオフローディングのオペレーションフレームワークを提供することが可能となる。
【００３３】
本技術では、以上のような要件を満たすための技術方式を提案する。以下、その内容について説明する。
【００３４】
（送受信システムの構成例）
図２は、本技術を適用した送受信システムの一実施の形態の構成を示すブロック図である。
【００３５】
図２において、送受信システムは、送信側のDASHサーバ１１、スイッチングサーバ１２、及び放送サーバ１３と、受信側のプロキシサーバ２１、及びDASHクライアント２２とから構成される。
【００３６】
すなわち、クライアントとサーバの関係にあるDASHクライアント２２とDASHサーバ１１との間に、プロキシサーバ２１とスイッチングサーバ１２が設けられている。
【００３７】
プロキシサーバ２１は、例えば、専用のサーバやテレビ受像機、セットトップボックス（STB：Set Top Box）、ネットワークストレージ、ゲーム機などとして構成される。
【００３８】
プロキシサーバ２１は、放送波（放送信号）を受信可能なチューナと、インターネット４１と接続可能な通信I/Fを有する。すなわち、プロキシサーバ２１においては、チューナにより、放送ネットワーク（MAC/PHY）のインターフェースを持ち、かつ、通信I/Fにより、インターネット４１等の双方向ネットワーク（MAC/PHY）のインターフェースを持つことになる。
【００３９】
また、プロキシサーバ２１は、エンドユーザ宅に構築された家庭内LAN(Local Area Network)等の双方向ネットワークを介して、DASHクライアント２２と相互に接続され、通信を行うことが可能である。すなわち、プロキシサーバ２１においては、通信I/Fにより、家庭内LAN等の双方向ネットワーク（MAC/PHY）のインターフェースを持つことになる。
【００４０】
DASHクライアント２２は、テレビ受像機やセットトップボックス、パーソナルコンピュータ、ゲーム機などの固定受信機、あるいは、スマートフォンや携帯電話機、タブレット型コンピュータなどのモバイル受信機として構成される。さらに、DASHクライアント２２は、ヘッドマウントディスプレイ（HMD：Head Mounted Display）などのウェアラブルコンピュータであってもよい。
【００４１】
DASHクライアント２２は、通信I/Fにより、家庭内LAN等の双方向ネットワーク（MAC/PHY）のインターフェースを持っている。DASHクライアント２２は、コンテンツのストリーム（DASHセグメント）を再生（又は記録）することができる。
【００４２】
スイッチングサーバ１２は、DASHサーバ１１側に設置され、双方向ネットワーク（インターネット４１）と一方向ネットワーク（放送ネットワーク）との切り替え機能（スイッチング機能：Bi/Uni-directional Switching）を有している。スイッチングサーバ１２は、例えば、専用のサーバとして構成される。
【００４３】
スイッチングサーバ１２は、インターネット４１等の双方向ネットワークを介した通信経由でのデータ配信を、自身で行う。一方で、スイッチングサーバ１２は、放送ネットワーク等の一方向ネットワークを介した放送経由でのデータ配信を、放送サーバ１３に依頼する。
【００４４】
DASHサーバ１１は、コンテンツのストリーム（DASHセグメント）の配信機能を有している。DASHサーバ１１は、例えば、専用のサーバとして構成される。DASHサーバ１１から配信されるストリームとしては、例えば、ライブ番組のライブストリームや、録画番組や映画などのVOD(Video On Demand)ストリームなどがある。
【００４５】
DASHサーバ１１は、LAN等の双方向ネットワークを介して、スイッチングサーバ１２と相互に接続され、通信を行うことが可能である。
【００４６】
放送サーバ１３は、コンテンツのストリーム（DASHセグメント）やその制御情報、番組情報などを、放送波（放送信号）として、放送ネットワーク（一方向ネットワーク）を介して送信する機能を有している。
【００４７】
なお、放送サーバ１３は、専用線などの所定の回線を介して、送信所３１に設置される送出設備に接続されている。この送信所３１内の送出設備が、放送サーバ１３からのデータに対し、必要な処理（例えば、変調処理等）を施すことで、その結果得られる放送波（放送信号）が、放送ネットワークを介して送信される。以下の説明では、説明の簡略化のため、送信所３１内の送出設備により行われる処理については省略する。
【００４８】
ここで、DASHクライアント２２において、所望のコンテンツを再生する場合、セグメントリクエストが、家庭内LANを介して、プロキシサーバ２１に送信される。プロキシサーバ２１は、DASHクライアント２２からのセグメントリクエストを処理して、インターネット４１を介して、スイッチングサーバ１２に送信する。
【００４９】
スイッチングサーバ１２は、プロキシサーバ２１からのセグメントリクエストに基づいて、双方向ネットワークと放送ネットワークのいずれにより、セグメントリクエストに対するセグメントレスポンスを返信するかを判断する。
【００５０】
スイッチングサーバ１２は、セグメントレスポンスを、双方向ネットワークを介した通信経由で返信すると判断した場合、DASHサーバ１１からのセグメントレスポンス（DASHセグメント）を、インターネット４１を介して、プロキシサーバ２１に送信する。
【００５１】
プロキシサーバ２１は、スイッチングサーバ１２から受信したセグメントレスポンス（DASHセグメント）を、家庭内LANを介して、DASHクライアント２２に送信する。そして、DASHクライアント２２では、通信経由で返信されたDASHセグメントが処理され、所望のコンテンツが再生されることになる。
【００５２】
その後、例えば、DASHクライアント２２で再生中のコンテンツを視聴するエンドユーザが増加して、当該コンテンツのストリーミングサービスのトラフィックが集中し、インターネット４１に多大な負荷がかかっている状況を想定する。
【００５３】
この場合、スイッチングサーバ１２は、プロキシサーバ２１からのセグメントリクエストに基づいて、双方向ネットワークと放送ネットワークのうち、放送ネットワークで、セグメントリクエストに対するセグメントレスポンスを返信すると判断する。そして、スイッチングサーバ１２は、DASHサーバ１１からのセグメントレスポンス（DASHセグメント）を、放送サーバ１３に転送する。
【００５４】
放送サーバ１３は、スイッチングサーバ１２からのセグメントレスポンス（DASHセグメント）を、放送ネットワークを介した放送経由で返信する。プロキシサーバ２１は、チューナにより、放送サーバ１３から送信されてくるセグメントレスポンス（DASHセグメント）を受信する。
【００５５】
プロキシサーバ２１は、放送サーバ１３から受信したセグメントレスポンス（DASHセグメント）を、家庭内LANを介して、DASHクライアント２２に送信する。そして、DASHクライアント２２では、放送経由で返信されたDASHセグメントが処理され、所望のコンテンツが再生されることになる。
【００５６】
なお、図２の送受信システムの説明では、プロキシサーバ２１とDASHクライアント２２が、エンドユーザ宅内に配置されるとして説明したが、プロキシサーバ２１は、エンドユーザ宅内に限らず、例えば、ケーブルオペレータのヘッドエンドや、モバイル網の基地局などに設置されるようにして、より広範囲は領域をカバーできるようにしてもよい。
【００５７】
すなわち、例えば、プロキシサーバ２１が、ケーブルオペレータのヘッドエンドに設置される場合、DASHクライアント２２は、同一のエンドユーザ宅内ではなく、ケーブルテレビのサービスを契約している各エンドユーザ宅内に設置されることになる。
【００５８】
また、例えば、プロキシサーバ２１が、モバイル網の基地局に設置される場合、DASHクライアント２２は、モバイルサービスを契約しているエンドユーザが、屋内又は屋外で所持しているデバイス（モバイル受信機）となる。
【００５９】
（送信側の構成例）
図３は、図２の送信側の各サーバの構成例を示すブロック図である。
【００６０】
（DASHサーバの構成例）
まず、DASHサーバ１１の構成例から説明する。DASHサーバ１１は、処理部１００、及び通信I/F１０１から構成される。
【００６１】
処理部１００は、例えば、CPU(Central Processing Unit)やマイクロプロセッサ等から構成される。処理部１００は、各種の演算処理や、各部の動作制御など、DASHサーバ１１における中心的な処理装置として動作する。
【００６２】
処理部１００は、MPD処理部１１１及びDASHセグメント処理部１１２を有する。
【００６３】
MPD処理部１１１は、MPDメタデータに関する処理を行う。DASHセグメント処理部１１２は、DASHセグメントに関する処理を行う。
【００６４】
通信I/F１０１は、例えば、通信インターフェース回路等から構成される。通信I/F１０１は、所定の通信回線を介して、スイッチングサーバ１２との間で、各種のデータをやりとりする。
【００６５】
（スイッチングサーバの構成例）
次に、スイッチングサーバ１２の構成例を説明する。スイッチングサーバ１２は、処理部１２０、通信I/F１２１、記憶部１２２、通信I/F１２３、及び通信I/F１２４から構成される。
【００６６】
処理部１２０は、例えば、CPUやマイクロプロセッサ等から構成される。処理部１２０は、各種の演算処理や、各部の動作制御など、スイッチングサーバ１２における中心的な処理装置として動作する。
【００６７】
処理部１２０は、リクエスト処理部１３１、放送処理部１３２、及び通信処理部１３３を有する。
【００６８】
リクエスト処理部１３１は、セグメントリクエスト等のリクエストに関する処理を行う。
【００６９】
放送処理部１３２は、放送返信モードで、リクエストに対するレスポンスを返信する場合の処理を行う。通信処理部１３３は、通信返信モードで、リクエストに対するレスポンスを返信する場合の処理を行う。
【００７０】
なお、詳細は後述するが、放送返信モードは、放送サーバ１３による放送ネットワークを利用して、レスポンスを返信するモードである。また、通信返信モードは、インターネット４１を利用して、レスポンスを返信するモードである。
【００７１】
通信I/F１２１は、例えば、通信インターフェース回路等から構成される。通信I/F１２１は、所定の通信回線を介して、DASHサーバ１１との間で、各種のデータをやりとりする。
【００７２】
記憶部１２２は、例えば、半導体メモリやハードディスクドライブ（HDD：Hard Disk Drive）等から構成される。記憶部１２２は、処理部１２０からの制御に従い、各種のデータを記録する。
【００７３】
通信I/F１２３は、例えば、通信インターフェース回路等から構成され、所定の通信回線を介して、放送サーバ１３との間で、各種のデータをやりとりする。
【００７４】
通信I/F１２４は、例えば、通信インターフェース回路等から構成され、インターネット４１を介して、プロキシサーバ２１との間で、各種のデータをやりとりする。
【００７５】
なお、図３においては、説明の都合上、通信I/F１２１と、通信I/F１２３と、通信I/F１２４の３つの通信I/Fを設けた構成を示しているが、それらの通信I/Fは一体となって、１つの通信I/Fから構成されるようにしてもよい。
【００７６】
（放送サーバの構成例）
次に、放送サーバ１３の構成例を説明する。放送サーバ１３は、処理部１４０、通信I/F１４１、及び送信部１４２から構成される。
【００７７】
処理部１４０は、例えば、CPUやマイクロプロセッサ等から構成される。処理部１４０は、各種の演算処理や、各部の動作制御など、放送サーバ１３における中心的な処理装置として動作する。
【００７８】
処理部１４０は、ESG・メタデータ処理部１５１及びDASHセグメント処理部１５２を有する。
【００７９】
ESG・メタデータ処理部１５１は、ESG・メタデータサーバ１４から取得されるESG情報やSLS等のメタデータに関する処理を行う。DASHセグメント処理部１５２は、DASHセグメントに関する処理を行う。
【００８０】
通信I/F１４１は、例えば、通信インターフェース回路等から構成される。通信I/F１４１は、所定の通信回線を介して、スイッチングサーバ１２との間で、各種のデータをやりとりする。
【００８１】
送信部１４２は、コンテンツのストリーム（DASHセグメント）とともに、ESG情報や制御情報などを送信する。
【００８２】
なお、図２や図３においては、送信側（サーババックエンド側）のDASHサーバ１１と、スイッチングサーバ１２と、放送サーバ１３とは、別々の装置（デバイス）として構成され、双方向ネットワークにより接続される場合の構成を示しているが、DASHサーバ１１と、スイッチングサーバ１２と、放送サーバ１３とは、同一のデバイス上に実装されるようにしてもよい。
【００８３】
例えば、DASHサーバ１１が有する機能と、スイッチングサーバ１２が有する機能と、放送サーバ１３が有する機能とを有する専用のサーバなどとして構成することができる。また、例えば、DASHサーバ１１と、スイッチングサーバ１２を同一のデバイス上に実装するなど、同一のデバイス上に実装するサーバの組み合わせは、任意である。
【００８４】
（受信側の構成例）
図４は、図２の受信側の各装置の構成例を示すブロック図である。
【００８５】
（プロキシサーバの構成例）
まず、プロキシサーバ２１の構成例から説明する。プロキシサーバ２１は、処理部２００、チューナ２０１、通信I/F２０２、及び通信I/F２０３から構成される。
【００８６】
処理部２００は、例えば、CPUやマイクロプロセッサ等から構成される。処理部２００は、各種の演算処理や、各部の動作制御など、プロキシサーバ２１における中心的な処理装置として動作する。
【００８７】
処理部２００は、ESG・メタデータ処理部２１１及びリクエスト処理部２１２を有する。
【００８８】
ESG・メタデータ処理部２１１は、ESG情報やSLS等のメタデータに関する処理を行う。リクエスト処理部２１２は、セグメントリクエスト等のリクエストに関する処理を行う。
【００８９】
チューナ２０１は、アンテナを介して、放送サーバ１３から送信されてくる放送波（放送信号）を受信して処理し、その結果得られるデータを処理部２００に供給する。
【００９０】
通信I/F２０２は、例えば、通信インターフェース回路等から構成される。通信I/F２０２は、インターネット４１を介して、スイッチングサーバ１２との間で、各種のデータをやりとりする。
【００９１】
通信I/F２０３は、例えば、通信インターフェース回路等から構成され、所定の通信回線（例えば、家庭内LAN等）を介して、DASHクライアント２２との間で、各種のデータをやりとりする。
【００９２】
なお、図４においては、説明の都合上、通信I/F２０２と、通信I/F２０３の２つの通信I/Fを設けた構成を示しているが、それらの通信I/Fは一体となって、１つの通信I/Fから構成されるようにしてもよい。
【００９３】
（DASHクライアントの構成例）
次に、DASHクライアント２２の構成例を説明する。DASHクライアント２２は、処理部２２０、通信I/F２２１、表示部２２２、及びスピーカ２２３から構成される。
【００９４】
処理部２２０は、例えば、CPUやマイクロプロセッサ等から構成される。処理部２２０は、各種の演算処理や、各部の動作制御など、DASHクライアント２２における中心的な処理装置として動作する。
【００９５】
処理部２２０は、リクエスト処理部２３１及び再生部２３２を有する。
【００９６】
リクエスト処理部２３１は、セグメントリクエスト等のリクエストに関する処理を行う。再生部２３２は、DASHセグメントに関する処理等を行うことで、コンテンツを再生する。
【００９７】
表示部２２２は、例えば、LCD(Liquid Crystal Display)やOELD(Organic Electroluminescence Display)等のディスプレイから構成される。表示部２２２は、処理部２２０（の再生部２３２）からのビデオデータに対応する映像を表示する。
【００９８】
スピーカ２２３は、処理部２２０からのオーディオデータに対応する音声を出力する。
【００９９】
なお、DASHクライアント２２において、表示部２２２が、タッチパネルの機能を有している場合には、当該タッチパネルに対するエンドユーザの操作に応じた操作信号が処理部２２０に供給され、処理部２２０は、当該操作信号に応じた処理を行う。また、図４には図示していないが、物理的なボタン等の入力部を設けて、当該入力部に対するエンドユーザの操作に応じた操作信号が、処理部２２０に供給されるようにしてもよい。
【０１００】
また、図２や図４においては、受信側のプロキシサーバ２１とDASHクライアント２２は、別々の装置（デバイス）として構成され、双方向ネットワークにより接続される場合の構成を示しているが、プロキシサーバ２１とDASHクライアント２２とは、同一のデバイス上に実装されるようにしてもよい。例えば、プロキシサーバ２１が有する機能と、DASHクライアント２２が有する機能とを有するテレビ受像機などとして構成することができる。
【０１０１】
（本技術のプロトコルスタック）
図５は、本技術のIP伝送方式のプロトコルスタックの例を示す図である。
【０１０２】
デジタル放送の伝送方式として、現状では、MPEG2-TS(Transport Stream)方式が広く普及しているが、今後は、通信の分野で用いられているIP(Internet Protocol)パケットをデジタル放送に用いたIP伝送方式が普及することが想定されている。
【０１０３】
例えば、次世代地上波放送規格の１つであるATSC(Advanced Television Systems Committee)3.0においても、IP伝送方式を採用して、より高度なサービスを提供できるようにすることが期待されている。本技術においても、ATSC3.0等の放送方式と同様に、IP伝送方式を採用することができる。
【０１０４】
図５において、最も下位の階層は、物理層（Physical Layer）とされる。ATSC3.0等のIP伝送方式のデジタル放送では、一方向の放送を利用した伝送に限らず、一部のデータを、双方向の通信を利用して伝送する場合があるが、放送（Broadcast）を利用する場合、その物理層は、サービス（チャネル）のために割り当てられた放送波の周波数帯域等が対応することになる。
【０１０５】
物理層（Physical Layer）の上位の階層は、データリンク層（Data Link Layer）とされる。また、データリンク層の上位の階層は、IP(Internet Protocol)層とUDP(User Datagram Protocol)層とされる。IP層とUDP層は、通信の階層モデルにおけるネットワーク層とトランスポート層に相当する層であり、IPアドレスとポート番号により、IPパケットとUDPパケットが特定される。
【０１０６】
ここで、ATSC3.0では、制御情報（シグナリング）として、LLS(Low Level Signaling)とSLS(Service Layer Signaling)を用いることが想定されている。LLSは、SLSよりも下位の層で伝送される制御情報である。SLSは、サービス単位の制御情報である。すなわち、ATSC3.0では、トランスポート層の制御情報が、LLSとSLSの２階層で伝送される。
【０１０７】
LLSには、SLT(Service List Table)等のメタデータが含まれる。SLTメタデータは、放送サービス（チャネル）の選局に必要な情報など、放送ネットワークにおけるストリームや放送サービスの構成を示す基本情報を含む。このSLTメタデータは、UDPパケットを含むIPパケットであるUDP/IPパケットに含めて伝送される。ただし、SLTメタデータを格納したUDP/IPパケットは、特別なIPアドレスとポート番号で伝送されることになる。
【０１０８】
IP層とUDP層に隣接する上位の階層は、ROUTE(Real-time Object Delivery over Unidirectional Transport)とされる。ROUTEは、ストリーミングファイル転送用のプロトコルであって、FLUTE(File Delivery over Unidirectional Transport)を拡張したものである。
【０１０９】
このROUTEセッションにより、放送サービスごとに、SLSのファイル（Signaling）や、NRT(Non Real Time)コンテンツのファイル（NRT）、DASHセグメントファイル（DASH）などが伝送される。
【０１１０】
ここで、SLSは、サービスレベルの制御情報であり、対象の放送サービスに属するコンポーネントの探索と選択に必要な情報や属性などを提供するものである。SLSは、USBD(User Service Bundle Description)，S-TSID(Service-based Transport Session Instance Description)，MPD(Media Presentation Description))等のメタデータを含む。
【０１１１】
USBDメタデータは、他のメタデータの取得先などの情報を含む。
【０１１２】
S-TSIDメタデータは、LSID(LCT Session Instance Description)をATSC3.0向けに拡張したものであって、ROUTEプロトコルの制御情報である。また、S-TSIDメタデータは、ROUTEセッションで伝送されるEFDT(Extended FDT)を特定することができる。EFDTは、FLUTEで導入されていたFDT(File Delivery Table)を拡張したものであって、転送用の制御情報である。
【０１１３】
MPDメタデータは、MPEG-DASHに準拠したストリーミング配信を行うために用いられる、ビデオやオーディオのファイルの制御情報である。
【０１１４】
ここで、MPEG-DASHは、OTT-V(Over The Top Video)に従ったストリーミング配信規格であって、HTTP(Hypertext Transfer Protocol)をベースとしたストリーミングプロトコルを用いたアダプティブストリーミング配信に関する規格である。
【０１１５】
このMPEG-DASHの規格では、ビデオやオーディオのファイルの制御情報であるメタデータを記述するためのマニフェストファイルと、動画のコンテンツを伝送するためのファイルフォーマットが規定されている。ここでは、前者のマニフェストファイルが、MPD(Media Presentation Description)と称され、後者のファイルフォーマットは、セグメントフォーマットとも称される。
【０１１６】
また、トランスポート・プロトコルとして、ROUTEを用いる場合には、ストリーミングのファイルフォーマットとして、MP4ファイルフォーマットを用いることができる。MP4ファイルフォーマットは、ISO/IEC 14496-12で規定されているISO BMFF(ISO Base Media File Format)の派生フォーマットである。
【０１１７】
ROUTEセッションで伝送されるセグメントは、イニシャライゼイションセグメント（IS：Initialization Segment）と、メディアセグメント（MS：Media Segment）から構成される。イニシャライゼイションセグメントは、データ圧縮方式等の初期化情報を含んでいる。また、メディアセグメントは、ビデオやオーディオ、字幕のストリームのデータを格納している。すなわち、このメディアセグメントが、DASHセグメント（DASHセグメントファイル）に相当するものである。
【０１１８】
このように、番組等のコンテンツを構成するサービスコンポーネント（ビデオやオーディオ、字幕等）のストリームデータは、ISO BMFFの規格に準じたDASHセグメント単位で、ROUTEセッションにより伝送されることになる。
【０１１９】
なお、NRTコンテンツは、受信機のストレージに一旦蓄積された後で再生が行われるコンテンツである。また、例えば、アプリケーションや電子サービスガイド（ESG：Electronic Service Guide）のファイルなど、NRTコンテンツ以外のファイルを、ROUTEセッションで伝送することもできる。
【０１２０】
また、LLSとしてのSLTメタデータや、SLSとしてのUSBD，S-TSID，MPD等のメタデータは、例えば、XML(Extensible Markup Language)等のマークアップ言語により記述されたテキスト形式のデータとすることができる。
【０１２１】
一方で、双方向の通信（Broadband）を利用する場合、その物理層（Physical Layer）の上位の階層は、データリンク層（Data Link Layer）とされる。また、データリンク層の上位の階層は、ネットワーク層に相当するIP層とされる。IP層に隣接する上位階層は、トランスポート層に相当するTCP(Transmission Control Protocol)層とされ、さらに、TCP層に隣接する上位階層は、アプリケーション層に相当するHTTP層とされる。
【０１２２】
すなわち、これらの階層によって、インターネット等の通信回線で稼働するTCP/IPなどのプロトコルが実装される。
【０１２３】
HTTP層に隣接する上位階層のうち、一部の階層は、制御情報（Signaling）と、NRTコンテンツ（NRT）とされる。この制御情報としては、上述したROUTEセッションで伝送される制御情報など、すべての制御情報が含まれる。また、NRTコンテンツは、通信経由で取得されるコンテンツであって、例えば、アプリケーションが含まれる。
【０１２４】
HTTP層に隣接する上位階層のうち、上述した階層以外の他の階層は、DASHセグメント（DASH）とされる。すなわち、双方向の通信系のストリーミング配信では、VOD(Video On Demand)番組等のコンテンツを構成するサービスコンポーネント（ビデオやオーディオ、字幕等）のストリームデータが、ISO BMFFの規格に準じたDASHセグメント単位で伝送されることになる。
【０１２５】
以上のように、本技術のIP伝送方式のプロトコルスタックにおいては、一方向の放送系の階層と、双方向の通信系の階層の一部が共通のプロトコルとなって、一方向の放送と双方向の通信で、コンテンツを構成するサービスコンポーネントのストリームデータを、ISO BMFFの規格に準じたDASHセグメント単位で伝送することができる。
【０１２６】
そのため、一方向の放送系のストリーミング配信と、双方向の通信系のストリーミング配信の双方を行う場合において、上位の階層のプロトコルが共通化されているため、各装置での実装の負担や処理の負担を軽減することができる。
【０１２７】
（MPDの内容）
図６は、SLSとしてのMPDメタデータの内容を示す図である。
【０１２８】
ここで、MPDメタデータは、Period要素と、AdaptationSet要素と、Representation要素と階層構造をなして構成される。
【０１２９】
Period要素は、番組等のコンテンツの構成を記述する単位となる。また、AssetIdentifier要素により、コンテンツの識別情報を記述することができる。
【０１３０】
また、AdaptationSet要素と、Representation要素は、コンテンツを構成するビデオやオーディオ、字幕等のコンポーネントのストリームごとに利用され、ぞれぞれのストリームの属性を記述することができる。
【０１３１】
AdaptationSet要素は、ビデオやオーディオのストリーム等の単一のストリームのほか、複数のストリームが多重化されたストリームに対応している。
【０１３２】
Representation要素は、その上位要素（親要素）となるAdaptationSet要素の範囲内で、例えばビットレート等のパラメータが異なる複数の選択肢となるコンポーネントのストリームを列挙することができる。なお、コンテンツは、１又は複数のコンポーネントから構成されるので、ここでは、コンテンツのストリームが列挙されているとも言える。
【０１３３】
図６においては、２つのコンテンツのストリームがある場合に、各コンテンツのストリームが、MPD-1とMPD-2で示すような構成のMPDメタデータをそれぞれ持っている。つまり、１つ目のコンテンツが、MPD-1を持ち、２つ目のコンテンツが、MPD-2を持っている。
【０１３４】
すなわち、１つ目のコンテンツは、コンテンツの識別情報として、AssetIdentifier要素により指定されるAssetId-1が割り当てられる一方で、２つ目のコンテンツには、AssetId-2が割り当てられている。
【０１３５】
また、１つ目のコンテンツのストリームのDASHセグメント（DASHセグメントファイル）は、SegURL-1-1，SegURL-1-2，・・・，SegURL-1-20，・・・，SegURL-1-40，・・・のように遷移するセグメントURLにより識別される。
【０１３６】
一方で、２つ目のコンテンツのストリームのDASHセグメント（DASHセグメントファイル）は、SegURL-2-1，SegURL-2-2，・・・，SegURL-2-30，・・・のように遷移するセグメントURLにより識別される。
【０１３７】
（MPDの記述例）
図７は、図６に示した１つ目のコンテンツが持っているMPDメタデータ（MPD-1）の記述例を示す図である。すなわち、図７には、MPD-1のXMLインスタンスの記述例を示している。
【０１３８】
このMPD-1においては、AssetIdentifier要素により、図６に示したAssetId-1の値として、"md:cid:EIDR:10.5240%2f0EFB-02CD-126E-8092-1E49-W"が指定されている。
【０１３９】
また、Representation要素のSegmentList要素に列挙されたSegmentURL要素の値が、図６に示したSegURL-1-1等のセグメントURLに相当する。具体的には、SegmentURL要素のコンテンツパートの"a-1-1.mp4"，"a-1-2.mp4"，"a-1-3.mp4"等が、SegURL-1-1，SegURL-1-2，SegURL-1-3等に相当している。
【０１４０】
＜２．具体的な運用例＞
【０１４１】
（具体的な構成の例）
図８は、図２の送受信システムの具体的な構成例を示す図である。
【０１４２】
図８においては、MPD-1とMPD-2に基づいたセグメントリクエストを発行する複数のDASHクライアント２２が、プロキシサーバ２１−１，２１−２を介して、双方向のインターネット４１に接続されている。
【０１４３】
具体的には、プロキシサーバ２１−１には、MPD-1に基づいたセグメントリクエストを発行するDASHクライアント２２−１−１乃至２２−１−ｎ（ｎ：１以上の整数）と、MPD-2に基づいたセグメントリクエストを発行するDASHクライアント２２−２と、MPD-1に基づいたセグメントリクエストを発行するDASHクライアント２２−３−１乃至２２−３−ｍ（ｍ：１以上の整数）が接続されている。
【０１４４】
また、プロキシサーバ２１−２には、MPD-2に基づいたセグメントリクエストを発行するDASHクライアント２２−４−１乃至２２−４−ｉ（ｉ：１以上の整数）と、MPD-1に基づいたセグメントリクエストを発行するDASHクライアント２２−５と、MPD-2に基づいたセグメントリクエストを発行するDASHクライアント２２−６−１乃至２２−６−ｊ（ｊ：１以上の整数）が接続されている。
【０１４５】
プロキシサーバ２１−１，２１−２が接続されたインターネット４１の先には、スイッチングサーバ１２が設けられる。このスイッチングサーバ１２は、DASHサーバ１１と接続されている。また、スイッチングサーバ１２は、放送サーバ１３−１，１３−２とも接続される。
【０１４６】
放送サーバ１３−１は、一方向の放送ネットワークBN-1（BrdcstNetwork-1）を介して、プロキシサーバ２１−１と接続される。また、放送サーバ１３−２は、一方向の放送ネットワークBN-2（BrdcstNetwork-2）を介して、プロキシサーバ２１−２と接続される。
【０１４７】
（セグメントリクエストの時間遷移の例）
図９は、図８の構成を採用した場合に、スイッチングサーバ１２を通過するセグメントリクエストの時間遷移の例を示す図である。
【０１４８】
図９において、図中の４つの点線の枠内には、セグメントリクエストの種別ごとに、プロキシサーバ２１からのセグメントリクエストが、図中の左側から右側に向かう方向で表された時間Tの時系列に並べられている。
【０１４９】
具体的には、図中の４つの点線の枠のうち、上側の２つの点線の枠内のセグメントリクエストは、AssetId-1のコンテンツC-1に対するセグメントリクエスト数の時間遷移を表している。
【０１５０】
上段のセグメントリクエストReq1/1は、放送ネットワークBN-1（BrdcstNetwork-1）に接続されるプロキシサーバ２１−１からのAssetId-1のコンテンツC-1のリクエストを表している。また、下段のセグメントリクエストReq2/1は、放送ネットワークBN-2（BrdcstNetwork-2）に接続されるプロキシサーバ２１−２からのAssetId-1のコンテンツC-1のリクエストを表している。
【０１５１】
ここで、セグメントリクエストReq1/1に注目すれば、放送ネットワークBN-1で返信される放送ストリーミングを受信可能なプロキシサーバ２１−１では、コンテンツC-1におけるRequestForSegURL-1-20以降で、RequestForSegURL-1-40未満のセグメントURLに対するリクエストが多くなっている。
【０１５２】
また、セグメントリクエストReq2/1に注目すれば、放送ネットワークBN-2で返信される放送ストリーミングを受信可能なプロキシサーバ２１−２では、コンテンツC-1における特定のセグメントURLに対するリクエストの増加は発生していない。
【０１５３】
そのため、AssetId-1のコンテンツC-1について、RequestForSegURL-1-20のリクエストから、RequestForSegURL-1-39のリクエストまでは、放送ネットワークBN-1（BrdcstNetwork-1）を利用した放送返信モードによって、処理されるのが効率がよい。
【０１５４】
一方で、図中の４つの点線の枠のうち、下側の２つの点線の枠内のセグメントリクエストは、AssetId-2のコンテンツC-2に対するセグメントリクエスト数の時間遷移を表している。
【０１５５】
上段のセグメントリクエストReq2/2は、放送ネットワークBN-2（BrdcstNetwork-2）に接続されるプロキシサーバ２１−２からのAssetId-2のコンテンツC-2のリクエストを表している。また、下段のセグメントリクエストReq1/2は、放送ネットワークBN-1（BrdcstNetwork-1）に接続されるプロキシサーバ２１−１からのAssetId-2のコンテンツC-2のリクエストを表している。
【０１５６】
ここで、セグメントリクエストReq2/2に注目すれば、放送ネットワークBN-2で返信される放送ストリーミングを受信可能なプロキシサーバ２１−２では、コンテンツC-2におけるRequestForSegURL-2-30以降のセグメントURLに対するリクエストが多くなっている。
【０１５７】
また、セグメントリクエストReq1/2に注目すれば、放送ネットワークBN-1で返信される放送ストリーミングを受信可能なプロキシサーバ２１−１では、コンテンツC-2における特定のセグメントURLに対するリクエストの増加は発生していない。
【０１５８】
そのため、AssetId-2のコンテンツC-2について、RequestForSegURL-2-30以降のリクエストは、放送ネットワークBN-2（BrdcstNetwork-2）を利用した放送返信モードによって、処理されるのが効率がよい。
【０１５９】
（処理フロー）
次に、図１０乃至図１３を参照して、送受信システムにおける処理フローを説明する。ここでは、当該処理フローを４段階に分けて説明する。
【０１６０】
（第１段階）
４段階の処理フローのうちの第１段階は、例えば、図１０のように表される。
【０１６１】
すなわち、まず、放送サーバ１３が、チューナ２０１を実装するプロキシサーバ２１に対し、ESG情報やSLTメタデータを用いて、ある地域の放送波において、放送オフローディングサービスが利用可能であることを通知（周知）する（Ｓ１）。
【０１６２】
ここで、周知情報をESG情報に含める場合には、放送オフローディングサービスが利用可能であることを、事前に通知することができる。一方で、周知情報をSLTメタデータに含める場合には、放送オフローディングサービスが利用可能であることを、即時（直前）に通知することができる。
【０１６３】
また、ある地域の放送波としては、例えば、放送ネットワークBN-1（BrdcstNetwork-1）や放送ネットワークBN-2（BrdcstNetwork-2）が該当する。これは、例えば、ATSC3.0におけるRF(Radio Frequency)チャネルに相当するものである。
【０１６４】
なお、ESG情報やSLTメタデータは、放送サーバ１３から放送波により放送経由で配信される場合もあれば、インターネット４１を介して、プロキシサーバ２１からの要求に応じて、通信経由で配信される場合もある。
【０１６５】
（第２段階）
次に、４段階の処理フローのうちの第２段階は、例えば、図１１のように表される。
【０１６６】
すなわち、DASHクライアント２２は、所望のコンテンツのMPDメタデータのURLを取得し、DASHサーバ１１に対し、リクエストを投げる。
【０１６７】
ここでは、例えば、プロキシサーバ２１又はDASHクライアント２２が、インターネット４１上に公開されたストリーミングサイトのWebページにアクセスするなど、何らかの方法で、MPDメタデータのURLが取得される。
【０１６８】
DASHクライアント２２からのMPDリクエスト（RequestForMPD-1）は、プロキシサーバ２１によって、インターネット４１を介して、スイッチングサーバ１２を経由してDASHサーバ１１に届けられる（Ｓ２）。
【０１６９】
DASHサーバ１１は、DASHクライアント２２からのMPDリクエストに対するMPDレスポンス（MPD-1）を、その逆の経路で、DASHクライアント２２に返信する。
【０１７０】
すなわち、MPDレスポンス（MPD-1）は、スイッチングサーバ１２によって、インターネット４１を介して、プロキシサーバ２１を経由してDASHクライアント２２に届けられる（Ｓ３）。ただし、スイッチングサーバ１２は、DASHサーバ１１からのMPDレスポンス（MPD-1）を記録しておくようにする。
【０１７１】
（第３段階）
次に、４段階の処理フローのうちの第３段階は、例えば、図１２のように表される。
【０１７２】
すなわち、DASHクライアント２２は、DASHサーバ１１からのMPDメタデータ（MPD-1）をパースして、プロキシサーバ２１に対し、DASHセグメントをリクエストする（Ｓ４）。
【０１７３】
プロキシサーバ２１は、DASHクライアント２２からのセグメントリクエスト（RequestForSegURL-1-*）に対し、ソース識別情報（AssetId-1）を挿入する。
【０１７４】
また、プロキシサーバ２１は、図１０に示したESG情報やSLTメタデータに含まれる周知情報に基づいて、自身が受信可能な放送エリアにおいて、放送オフローディングサービスが利用可能であるかどうかを確認する。プロキシサーバ２１は、放送オフローディングサービスが利用可能である場合には、セグメントリクエストに対し、さらに放送ネットワーク識別情報（BrdcstNetwork-1）を挿入する。
【０１７５】
なお、プロキシサーバ２１において、自身が受信可能な放送エリアは、放送ネットワークBN-1（BrdcstNetwork-1）のブロードキャストストリームID（bsid：BroadcastStreamID）により識別され、それを、放送ネットワーク識別情報として用いることができる。
【０１７６】
このようにして、放送オフローディングサービスが利用可能である場合には、ソース識別情報（AssetId-1）のほかに、放送ネットワーク識別情報（BrdcstNetwork-1）が挿入されたセグメントリクエスト（RequestForSegURL-1-*）が生成される。一方で、放送オフローディングサービスが利用できない場合には、ソース識別情報（AssetId-1）のみが挿入されたセグメントリクエスト（RequestForSegURL-1-*）が生成される。
【０１７７】
そして、当該セグメントリクエストは、プロキシサーバ２１によって、インターネット４１を介して、スイッチングサーバ１２を経由してDASHサーバ１１に届けられる（Ｓ５）。
【０１７８】
DASHサーバ１１は、プロキシサーバ２１からのセグメントリクエストに対するDASHセグメントを、スイッチングサーバ１２とプロキシサーバ２１を経由して、DASHクライアント２２に返信する（Ｓ６）。
【０１７９】
なお、図１２においては、MPD-1に基づいたセグメントリクエストを発行するDASHクライアント２２の数が、少ないため、プロキシサーバ２１は、インターネット４１を介した通信経由で返信されるDASHセグメントを受信し、DASHクライアント２２に転送している。
【０１８０】
（第４段階）
次に、４段階の処理フローのうちの第４段階は、例えば、図１３のように表される。
【０１８１】
すなわち、スイッチングサーバ１２は、プロキシサーバ２１を経由して送信されてくる複数のDASHクライアント２２（２２-１-１乃至２２-１-ｎ，２２-３-１乃至２２-３-ｍ）からのセグメントリクエストの監視（モニタ）を行う。
【０１８２】
なお、図１３の第４段階においては、プロキシサーバ２１に接続され、MPD-1に基づいたセグメントリクエストを発行するDASHクライアント２２の数が、図１２に示した第３段階と比べて増加している。
【０１８３】
そして、スイッチングサーバ１２は、あるDASHセグメントに対するセグメントリクエストが集中しているエリアについては、インターネット４１を介してDASHクライアントを返信するのではなく、そのエリアをカバーする放送ネットワークに、当該DASHセグメントの放送を依頼する。
【０１８４】
例えば、上述の図９に示したセグメントリクエストの時間遷移において、同一の放送ネットワークBN-1（BrdcstNetwork-1）を受信可能なエリアに存在する複数のDASHクライアント２２が、MPDメタデータ（MPD-1）から導出されるRequestForSegURL-1-20〜29であるセグメントURLをリクエストした場合を想定する（Ｓ７）。
【０１８５】
なお、当該セグメントリクエスト（セグメントリクエストReq1/1）には、プロキシサーバ２１により、ソース識別情報（AssetId-1）とともに、放送ネットワーク識別情報（BrdcstNetwork-1）が挿入されている。
【０１８６】
この場合、スイッチングサーバ１２は、プロキシサーバ２１からのセグメントリクエストReq1/1に含まれるソース識別情報（AssetId-1）及び放送ネットワーク識別情報（BrdcstNetwork-1）に基づいて、所定の条件に従い、レスポンス（DASHセグメント）の返信モードを決定する。
【０１８７】
すなわち、例えば、スイッチングサーバ１２では、ソース識別情報で識別されるコンテンツ（ソース）ごとに、一定の測定期間を設けて、セグメントリクエストのリクエスト数がカウントされるようにする。そして、そのカウント値が、あらかじめ定められた閾値以上になった場合、それ以降の該当するソース識別情報を含むセグメントリクエストに対するレスポンス（DASHセグメント）が、放送ネットワークBN-1（BrdcstNetwork-1）を利用して返信されるようにする（Ｓ８）。
【０１８８】
換言すれば、スイッチングサーバ１２は、セグメントリクエストに対するレスポンス（DASHセグメント）を、放送ネットワークを介して返信したほうが、ネットワークリソースの効率利用（コストセーブ）をはかれると判断した場合には、当該レスポンスを、放送ネットワークを利用して返信させる。つまり、放送返信モードで、レスポンス（DASHセグメント）が返信される。
【０１８９】
このとき、スイッチングサーバ１２は、放送返信モードで返信されるコンテンツ（ソース）からのDASHセグメントの存在を、SLS（USBDメタデータ）により、プロキシサーバ２１側に通知（周知）するように、放送サーバ１３に依頼する。
【０１９０】
ここで、スイッチングサーバ１２は、リクエストの多いDASHセグメントのセグメントURLから、記録してあるMPDメタデータを参照して、該当するbaseURLを、SLS（USBDメタデータ）に格納するように、放送サーバ１３に指示する。
【０１９１】
なお、このようなUSBDメタデータによるフラグに依らず、あらかじめMPDメタデータを更新して通知し、当該MPDメタデータ内に、放送経由での返信か、通信経由での返信かを明示的に記述しておくという方法を採用してもよい。ここでは、例えば、放送経由での返信の場合には、baseURL（"/"等ではじまる相対URL等）を用い、通信経由での返信の場合には、絶対URLを用いるというような規則を、あらかじめ定義しておくというような方法を用いることができる。
【０１９２】
また、スイッチングサーバ１２は、放送サーバ１３に対し、SLSとして、USBDメタデータとともに、MPDメタデータを通知する。
【０１９３】
ここで、放送返信モードに設定されたソースに該当するDASHセグメントは、プロキシサーバ２１が、放送経由での受信に失敗する場合に備えて、通信経由でも返信できるようにしておくことが望ましい。
【０１９４】
具体的には、該当するDASHセグメントについて、スイッチングサーバ１２（の処理部１２０）が、インターネット４１上のCDN(Contents Delivery Network)に、キャッシュコピーを展開しておくことで、通信経由での返信に備えることができる。
【０１９５】
また、一旦、対象のコンテンツが、放送返信モードのソースに設定された場合には、そのソースに属する後続のDASHセグメントについては、DASHクライアント２２からのセグメントリクエストを待つことなく、放送サーバ１３が、スイッチングサーバ１２から通知されたMPDメタデータに基づいて、セグメントリクエストを、スイッチングサーバ１２を介してDASHサーバ１１に対して発行する。
【０１９６】
それに対し、DASHサーバ１１は、セグメントリクエストに対するレスポンス（DASHセグメント）を、スイッチングサーバ１２を介して放送サーバ１３に返信する。そして、放送サーバ１３は、DASHサーバ１１からのレスポンス（DASHセグメント）を受け取って、当該DASHセグメントを、放送ネットワーク（BrdcstNetwork-1）を利用して返信されるようにする。
【０１９７】
放送サーバ１３は、MPDメタデータに基づいて、MPDメタデータの最後まで、又はPeriod要素が終了するまで、DASHサーバ１１に対し、セグメントリクエストを発行し続ける。そして、放送サーバ１３は、放送返信モードでの返信を終える場合には、該当するbaseURLを、SLS（USBDメタデータ）から取り除いて、更新されたSLS（USBDメタデータ）を配信する。
【０１９８】
なお、このようなUSBDメタデータによるフラグに依らず、あらかじめMPDメタデータを更新して通知し、当該MPDメタデータ内に、放送経由での返信か、通信経由での返信かを明示的に記述していた場合には、例えば、放送経由での返信の場合を意味するbaseURL（"/"等ではじまる相対URL等）を取り除くようにする。
【０１９９】
一方で、受信側において、プロキシサーバ２１は、DASHクライアント２２からDASHセグメントがリクエストされた場合、最新のSLS（USBDメタデータ）を参照して、放送返信モードに設定されたソースであるかを確認して、DASHセグメントを、放送経由で取得するか、あるいは通信経由で取得するかを判断する。
【０２００】
例えば、当該セグメントリクエストに対応するセグメントURLの最初のパートが、"bundleDescriptionROUTE/userServiceDescription/deliveryMethod/broadcastAppService/basePattern"（放送配信向けのURLの一致パターン）に列挙されているURLの一部（又は全部）に一致するかどうかを確認することで、放送経由又は通信経由での取得を判断することができる。
【０２０１】
なお、このようなUSBDメタデータによるフラグに依らず、MPDメタデータ内に、放送経由での返信か、通信経由での返信かが明示的に記述されている場合、プロキシサーバ２１は、当該MPDメタデータに基づいて、放送経由又は通信経由での取得を判断することができる。ここでは、例えば、放送経由での返信の場合には、baseURL（"/"等ではじまる相対URL等）を用い、通信経由での返信の場合には、絶対URLを用いるというような規則があらかじめ定義される。
【０２０２】
そして、プロキシサーバ２１は、放送経由での取得を行う場合には、放送サーバ１３から、放送ネットワーク（BrdcstNetwork-1）を利用して返信されるデータを、ROUTEモジュール等により処理し、その結果得られるセグメントファイル（DASHセグメント）を、DASHクライアント２２に送信する。
【０２０３】
一方で、プロキシサーバ２１は、通信経由での取得を行う場合には、インターネット４１を介して、スイッチングサーバ１２を経由して、DASHサーバ１１との間で、リクエストとレスポンスのやりとりを行うことで、セグメントファイル（DASHセグメント）を取得し、DASHクライアント２２に送信する（Ｓ９）。
【０２０４】
以上、送受信システムにおける処理フローについて説明した。
【０２０５】
＜３．リクエスト/レスポンスのトラフィックの例＞
【０２０６】
次に、図１４乃至図１７を参照して、上述の図９に示したセグメントリクエストの時間遷移に応じたレスポンストラフィックについて説明する。
【０２０７】
（第１の期間のトラフィック）
まず、図１４を参照して、第１の期間（時刻t0乃至時刻t1の間）におけるセグメントのリクエスト/レスポンスのトラフィックについて説明する。
【０２０８】
なお、図１４において、プロキシサーバ２１−１は、放送サーバ１３−１の放送エリア内に存在し、一方向の放送ネットワークBN-1（BrdcstNetwork-1）を介して、放送サーバ１３−１からのセグメントファイル（DASHセグメント）を受信可能である。
【０２０９】
このプロキシサーバ２１−１には、MPD-1に基づいたセグメントリクエストを発行するDASHクライアント２２−１と、MPD-2に基づいたセグメントリクエストを発行するDASHクライアント２２−２が接続される。さらに、プロキシサーバ２１−１は、インターネット４１を介して、スイッチングサーバ１２と接続される。
【０２１０】
また、図１４において、プロキシサーバ２１−２は、放送サーバ１３−２の放送エリア内に存在し、一方向の放送ネットワークBN-2（BrdcstNetwork-2）を介して、放送サーバ１３−２からのセグメントファイル（DASHセグメント）を受信可能である。
【０２１１】
このプロキシサーバ２１−２には、MPD-1に基づいたセグメントリクエストを発行するDASHクライアント２２−３と、MPD-2に基づいたセグメントリクエストを発行するDASHクライアント２２−４が接続される。さらに、プロキシサーバ２１−２は、インターネット４１を介して、スイッチングサーバ１２と接続される。
【０２１２】
ここで、第１の期間は、図９に示した時刻t0乃至時刻t1の間に相当しており、この第１の期間に、スイッチングサーバ１２で処理されるセグメントリクエストは、RequestForSegURL-1-1乃至RequestForSegURL-1-19と、RequestForSegURL-2-1乃至RequestForSegURL-2-19である。
【０２１３】
図１４において、図９のRequestForSegURL-1-1乃至RequestForSegURL-1-19に相当するのは、セグメントリクエストReq1/1と、セグメントリクエストReq2/1である。
【０２１４】
すなわち、セグメントリクエストReq1/1は、DASHクライアント２２−１からのセグメントリクエストであって、プロキシサーバ２１−１により、放送ネットワークBN-1の放送ネットワーク識別情報（BrdcstNetwork-1）と、コンテンツC-1のソース識別情報（AssetId-1）が挿入されている。
【０２１５】
また、セグメントリクエストReq2/1は、DASHクライアント２２−３からのセグメントリクエストであって、プロキシサーバ２１−２により、放送ネットワークBN-2の放送ネットワーク識別情報（BrdcstNetwork-2）と、コンテンツC-1のソース識別情報（AssetId-1）が挿入されている。
【０２１６】
一方で、図１４において、図９のRequestForSegURL-2-1乃至RequestForSegURL-2-19に相当するのは、セグメントリクエストReq1/2と、セグメントリクエストReq2/2である。
【０２１７】
すなわち、セグメントリクエストReq1/2は、DASHクライアント２２−２からのセグメントリクエストであって、プロキシサーバ２１−１により、放送ネットワークBN-1の放送ネットワーク識別情報（BrdcstNetwork-1）と、コンテンツC-2のソース識別情報（AssetId-2）が挿入されている。
【０２１８】
また、セグメントリクエストReq2/2は、DASHクライアント２２−４からのセグメントリクエストであって、プロキシサーバ２１−２により、放送ネットワークBN-2の放送ネットワーク識別情報（BrdcstNetwork-2）と、コンテンツC-2のソース識別情報（AssetId-2）が挿入されている。
【０２１９】
このようなセグメントリクエストReq1/1，Req2/1，Req1/2，Req2/2が、インターネット４１を介して、スイッチングサーバ１２により受信される。スイッチングサーバ１２は、これらのセグメントリクエストReq1/1，Req2/1，Req1/2，Req2/2から得られるネットワーク識別情報と、ソース識別情報に基づいて、所定の条件に従い、レスポンス（DASHセグメント）の返信モードを決定する。
【０２２０】
ここでは、各セグメントリクエストにおいて、特定のセグメントURLに対するリクエストの増加は発生していないため、スイッチングサーバ１２は、放送オフローディングサービスを利用する必要はないと判断して、通信返信モードで、すべてのセグメントレスポンス（DASHセグメント）が返信されるようにする。
【０２２１】
スイッチングサーバ１２は、通信返信モードに設定されたソースに該当するDASHセグメントであって、セグメントリクエストReq1/1，Req1/2に応じたDASHセグメントをDASHサーバ１１から取得し、インターネット４１を介して、プロキシサーバ２１−１に送信する。
【０２２２】
そして、プロキシサーバ２１−１は、スイッチングサーバ１２から通信経由で受信されたDASHセグメント（セグメントリクエストReq1/1に応じたDASHセグメント）を、DASHクライアント２２−１に送信する。また、プロキシサーバ２１−１は、スイッチングサーバ１２から通信経由で受信されたDASHセグメント（セグメントリクエストReq1/2に応じたDASHセグメント）を、DASHクライアント２２−２に送信する。
【０２２３】
一方で、スイッチングサーバ１２は、通信返信モードに設定されたソースに該当するDASHセグメントであって、セグメントリクエストReq2/1，Req2/2に応じたDASHセグメントをDASHサーバ１１から取得し、インターネット４１を介して、プロキシサーバ２１−２に送信する。
【０２２４】
そして、プロキシサーバ２１−２は、スイッチングサーバ１２から通信経由で受信されたDASHセグメント（セグメントリクエストReq2/1に応じたDASHセグメント）を、DASHクライアント２２−３に送信する。また、プロキシサーバ２１−２は、スイッチングサーバ１２から通信経由で受信されたDASHセグメント（セグメントリクエストReq2/2に応じたDASHセグメント）を、DASHクライアント２２−４に送信する。
【０２２５】
以上のように、第１の期間（時刻t0乃至時刻t1の間）においては、ストリーミングサービスのトラフィックの集中が発生していないため、セグメントリクエスト（Req1/1，Req2/1，Req1/2，Req2/2）に対するレスポンスがすべて、インターネット４１を介して通信経由で返信される。
【０２２６】
（第２の期間のトラフィック）
次に、図１５を参照して、第２の期間（時刻t1乃至時刻t2の間）におけるセグメントのリクエスト/レスポンスのトラフィックについて説明する。
【０２２７】
この第２の期間に、スイッチングサーバ１２で処理されるセグメントリクエストは、RequestForSegURL-1-20乃至RequestForSegURL-1-29と、RequestForSegURL-2-20乃至RequestForSegURL-2-29である。
【０２２８】
図１５の第２の期間においては、図１４の第１の期間と比べて、プロキシサーバ２１−１に接続されるDASHクライアント２２のうち、MPD-1に基づいたセグメントリクエストを発行するものが、DASHクライアント２２−１から、DASHクライアント２２−１−１乃至２２−１−ｎ（ｎ：１以上の整数），２２−５−１乃至２２−５−ｍ（ｍ：１以上の整数）に増加している。
【０２２９】
ただし、プロキシサーバ２１−１に接続されるDASHクライアント２２のうち、MPD-2に基づいたセグメントリクエストを発行するものと、プロキシサーバ２１−２に接続されるDASHクライアント２２のうち、MPD-1とMPD-2に基づいたセグメントリクエストを発行するものの増減はない。
【０２３０】
このような構成の場合にも、セグメントリクエストReq1/1，Req2/1，Req1/2，Req2/2が、インターネット４１を介して、スイッチングサーバ１２により受信される。スイッチングサーバ１２は、これらのセグメントリクエストReq1/1，Req2/1，Req1/2，Req2/2から得られるネットワーク識別情報と、ソース識別情報に基づいて、所定の条件に従い、レスポンス（DASHセグメント）の返信モードを決定する。
【０２３１】
ここでは、セグメントリクエストReq1/1において、特定のセグメントURLに対するリクエストの増加が発生しているため、スイッチングサーバ１２は、セグメントリクエストReq1/1に対するレスポンス（DASHセグメント）を、放送オフローディングサービスを利用して返信したほうが、ネットワークリソースの効率利用をはかれると判断する。つまり、セグメントリクエストReq1/1に対するレスポンス（DASHセグメント）が、放送返信モードで返信されるようにする。
【０２３２】
一方で、セグメントリクエストReq2/1，Req1/2，Req2/2において、特定のセグメントURLに対するリクエストの増加は発生していないため、スイッチングサーバ１２は、セグメントリクエストReq2/1，Req1/2，Req2/2に対するレスポンス（DASHセグメント）について、放送オフローディングサービスを利用する必要はないと判断する。つまり、セグメントリクエストReq2/1，Req1/2，Req2/2に対するレスポンス（DASHセグメント）が、通信返信モードで返信されるようにする。
【０２３３】
スイッチングサーバ１２は、放送返信モードに設定されたソースに該当するDASHセグメントであって、セグメントリクエストReq1/1に応じたDASHセグメントを、DASHサーバ１１から取得し、放送サーバ１３−１に送信する。そして、放送サーバ１３−１は、当該DASHセグメントを、放送ネットワークBN-1（BrdcstNetwork-1）を介して、プロキシサーバ２１−１に送信する。
【０２３４】
また、スイッチングサーバ１２は、通信返信モードに設定されたソースに該当するDASHセグメントであって、セグメントリクエストReq1/2に応じたDASHセグメントをDASHサーバ１１から取得し、インターネット４１を介して、プロキシサーバ２１−１に送信する。
【０２３５】
そして、プロキシサーバ２１−１は、放送サーバ１３−１から放送経由で受信されたDASHセグメント（セグメントリクエストReq1/1に応じたDASHセグメント）を、DASHクライアント２２−１−１乃至２２−１−ｎ，２２−５−１乃至２２−５−ｍにそれぞれ送信する。また、プロキシサーバ２１−１は、スイッチングサーバ１２から通信経由で受信されたDASHセグメント（セグメントリクエストReq1/2に応じたDASHセグメント）を、DASHクライアント２２−２に送信する。
【０２３６】
一方で、スイッチングサーバ１２は、通信返信モードに設定されたソースに該当するDASHセグメントであって、セグメントリクエストReq2/1，Req2/2に応じたDASHセグメントをDASHサーバ１１から取得し、インターネット４１を介して、プロキシサーバ２１−２に送信する。
【０２３７】
そして、プロキシサーバ２１−２は、スイッチングサーバ１２から通信経由で受信されたDASHセグメント（セグメントリクエストReq2/1に応じたDASHセグメント）を、DASHクライアント２２−３に送信する。また、プロキシサーバ２１−２は、スイッチングサーバ１２から通信経由で受信されたDASHセグメント（セグメントリクエストReq2/2に応じたDASHセグメント）を、DASHクライアント２２−４に送信する。
【０２３８】
以上のように、第２の期間（時刻t1乃至時刻t2の間）においては、セグメントリクエストReq1/1において、特定のセグメントURLに対するリクエストの増加が発生して、ストリーミングサービスのトラフィックの集中が発生しているため、セグメントリクエストReq1/1に対するレスポンスを、放送オフローディングサービスを利用して、放送経由で返信している。
【０２３９】
また、セグメントリクエストReq2/1，Req1/2，Req2/2については、ストリーミングサービスのトラフィックの集中が発生していないため、それらのセグメントリクエスト（Req2/1，Req1/2，Req2/2）に対するレスポンスは、図１４の第１の期間と同様に、インターネット４１を介して通信経由で返信される。
【０２４０】
（第３の期間のトラフィック）
次に、図１６を参照して、第３の期間（時刻t2乃至時刻t3の間）におけるリクエスト/レスポンスのトラフィックについて説明する。
【０２４１】
この第３の期間に、スイッチングサーバ１２で処理されるセグメントリクエストは、RequestForSegURL-1-30乃至RequestForSegURL-1-39と、RequestForSegURL-2-30乃至RequestForSegURL-2-39である。
【０２４２】
図１６の第３の期間においては、図１５の第２の期間と比べて、プロキシサーバ２１−２に接続されるDASHクライアント２２のうち、MPD-2に基づいたセグメントリクエストを発行するものが、DASHクライアント２２−４から、DASHクライアント２２−４−１乃至２２−４−ｉ（ｉ：１以上の整数），２２−６−１乃至２２−６−ｊ（ｊ：１以上の整数）に増加している。
【０２４３】
ただし、プロキシサーバ２１−２に接続されるDASHクライアント２２のうち、MPD-1に基づいたセグメントリクエストを発行するものと、プロキシサーバ２１−１に接続されるDASHクライアント２２のうち、MPD-1とMPD-2に基づいたセグメントリクエストを発行するものの増減はない。
【０２４４】
このような構成の場合にも、セグメントリクエストReq2/1，Req1/2，Req2/2が、インターネット４１を介して、スイッチングサーバ１２により受信される。スイッチングサーバ１２は、これらのセグメントリクエストReq2/1，Req1/2，Req2/2から得られるネットワーク識別情報と、ソース識別情報に基づいて、所定の条件に従い、レスポンス（DASHセグメント）の返信モードを決定する。
【０２４５】
ここでは、セグメントリクエストReq2/2において、特定のセグメントURLに対するリクエストの増加が発生しているため、スイッチングサーバ１２は、セグメントリクエストReq2/2に対するレスポンス（DASHセグメント）を、放送オフローディングサービスを利用して返信したほうが、ネットワークリソースの効率利用をはかれると判断する。つまり、セグメントリクエストReq2/2に対するレスポンス（DASHセグメント）が、放送返信モードで返信されるようにする。
【０２４６】
一方で、セグメントリクエストReq2/1，Req1/2において、特定のセグメントURLに対するリクエストの増加は発生していないため、スイッチングサーバ１２は、セグメントリクエストReq2/1，Req1/2に対するレスポンス（DASHセグメント）について、放送オフローディングサービスを利用する必要はないと判断する。つまり、セグメントリクエストReq2/1，Req1/2，に対するレスポンス（DASHセグメント）が、通信返信モードで返信されるようにする。
【０２４７】
なお、図１６の第３の期間において、セグメントリクエストReq1/1については、図１５の第２の期間と同様に、放送返信モードが継続される。
【０２４８】
スイッチングサーバ１２は、放送返信モードに設定されたソースに該当するDASHセグメントであって、セグメントリクエストReq1/1に応じたDASHセグメントを、DASHサーバ１１から取得し、放送サーバ１３−１に送信する。そして、放送サーバ１３−１は、当該DASHセグメントを、放送ネットワークBN-1（BrdcstNetwork-1）を介して、プロキシサーバ２１−１に送信する。
【０２４９】
また、スイッチングサーバ１２は、通信返信モードに設定されたソースに該当するDASHセグメントであって、セグメントリクエストReq1/2に応じたDASHセグメントをDASHサーバ１１から取得し、インターネット４１を介して、プロキシサーバ２１−１に送信する。
【０２５０】
そして、プロキシサーバ２１−１は、放送サーバ１３−１から放送経由で受信されたDASHセグメント（セグメントリクエストReq1/1に応じたDASHセグメント）を、DASHクライアント２２−１−１乃至２２−１−ｎ，２２−５−１乃至２２−５−ｍにそれぞれ送信する。また、プロキシサーバ２１−１は、スイッチングサーバ１２から通信経由で受信されたDASHセグメント（セグメントリクエストReq1/2に応じたDASHセグメント）を、DASHクライアント２２−２に送信する。
【０２５１】
一方で、スイッチングサーバ１２は、放送返信モードに設定されたソースに該当するDASHセグメントであって、セグメントリクエストReq2/2に応じたDASHセグメントを、DASHサーバ１１から取得し、放送サーバ１３−２に送信する。そして、放送サーバ１３−２は、当該DASHセグメントを、放送ネットワークBN-2（BrdcstNetwork-2）を介して、プロキシサーバ２１−２に送信する。
【０２５２】
また、スイッチングサーバ１２は、通信返信モードに設定されたソースに該当するDASHセグメントであって、セグメントリクエストReq2/1に応じたDASHセグメントをDASHサーバ１１から取得し、インターネット４１を介して、プロキシサーバ２１−２に送信する。
【０２５３】
そして、プロキシサーバ２１−２は、スイッチングサーバ１２から通信経由で受信されたDASHセグメント（セグメントリクエストReq2/1に応じたDASHセグメント）を、DASHクライアント２２−３に送信する。また、プロキシサーバ２１−２は、スイッチングサーバ１２から放送経由で受信されたDASHセグメント（セグメントリクエストReq2/2に応じたDASHセグメント）を、DASHクライアント２２−４−１乃至２２−４−ｉ，２２−６−１乃至２２−６−ｊにそれぞれ送信する。
【０２５４】
以上のように、第３の期間（時刻t2乃至時刻t3の間）においては、セグメントリクエストReq1/1，Req2/2において、特定のセグメントURLに対するリクエストの増加が発生して、ストリーミングサービスのトラフィックの集中が発生しているため、セグメントリクエストReq1/1，Req2/2に対するレスポンスを、放送オフローディングサービスを利用して、放送経由で返信している。
【０２５５】
また、セグメントリクエストReq2/1，Req1/2については、ストリーミングサービスのトラフィックの集中が発生していないため、それらのセグメントリクエスト（Req2/1，Req1/2）に対するレスポンスは、図１４の第１の期間と同様に、インターネット４１を介して通信経由で返信される。
【０２５６】
（第４の期間のトラフィック）
最後に、図１７を参照して、第４の期間（時刻t3以降）におけるリクエスト/レスポンスのトラフィックについて説明する。
【０２５７】
この第４の期間に、スイッチングサーバ１２で処理されるセグメントリクエストは、RequestForSegURL-1-40以降と、RequestForSegURL-2-40以降である。
【０２５８】
図１７の第４の期間においては、図１６の第３の期間と比べて、プロキシサーバ２１−１に接続されるDASHクライアント２２のうち、MPD-1に基づいたセグメントリクエストを発行するものが、DASHクライアント２２−１−１乃至２２−１−ｎ，２２−５−１乃至２２−５−ｍから、DASHクライアント２２−１に減少している。
【０２５９】
ただし、プロキシサーバ２１−１に接続されるDASHクライアント２２のうち、MPD-2に基づいたセグメントリクエストを発行するものと、プロキシサーバ２１−２に接続されるDASHクライアント２２のうち、MPD-1とMPD-2に基づいたセグメントリクエストを発行するものの増減はない。
【０２６０】
また、第４の期間では、例えば、MPD-1において、あるPeriod要素が終了し、セグメントリクエストReq1/1に対する、DASHセグメントの放送返信モードでの返信は終了しているものとする。
【０２６１】
このような構成の場合に、セグメントリクエストReq1/1，Req2/1，Req1/2が、インターネット４１を介して、スイッチングサーバ１２により受信される。スイッチングサーバ１２は、これらのセグメントリクエストReq1/1，Req2/1，Req1/2から得られるネットワーク識別情報と、ソース識別情報に基づいて、所定の条件に従い、レスポンス（DASHセグメント）の返信モードを決定する。
【０２６２】
ここでは、セグメントリクエストReq1/1，Req2/1，Req1/2において、特定のセグメントURLに対するリクエストの増加は発生していないため、スイッチングサーバ１２は、セグメントリクエストReq1/1，Req2/1，Req1/2に対するレスポンス（DASHセグメント）について、放送オフローディングサービスを利用する必要はないと判断する。つまり、セグメントリクエストReq2/1，Req1/2，に対するレスポンス（DASHセグメント）が、通信返信モードで返信されるようにする。
【０２６３】
なお、図１７の第４の期間において、セグメントリクエストReq2/2については、図１６の第３の期間と同様に、放送返信モードが継続される。
【０２６４】
スイッチングサーバ１２は、通信返信モードに設定されたソースに該当するDASHセグメントであって、セグメントリクエストReq1/1，Req1/2に応じたDASHセグメントをDASHサーバ１１から取得し、インターネット４１を介して、プロキシサーバ２１−１に送信する。
【０２６５】
そして、プロキシサーバ２１−１は、スイッチングサーバ１２から通信経由で受信されたDASHセグメント（セグメントリクエストReq1/1に応じたDASHセグメント）を、DASHクライアント２２−１に送信する。また、プロキシサーバ２１−１は、スイッチングサーバ１２から通信経由で受信されたDASHセグメント（セグメントリクエストReq1/2に応じたDASHセグメント）を、DASHクライアント２２−２に送信する。
【０２６６】
一方で、放送返信モードに設定されたソースに該当するDASHセグメントであって、セグメントリクエストReq2/2に応じたDASHセグメントを、DASHサーバ１１から取得し、放送サーバ１３−２に送信する。そして、放送サーバ１３−２は、当該DASHセグメントを、放送ネットワークBN-2（BrdcstNetwork-2）を介して、プロキシサーバ２１−２に送信する。
【０２６７】
また、スイッチングサーバ１２は、通信返信モードに設定されたソースに該当するDASHセグメントであって、セグメントリクエストReq2/1に応じたDASHセグメントをDASHサーバ１１から取得し、インターネット４１を介して、プロキシサーバ２１−２に送信する。
【０２６８】
そして、プロキシサーバ２１−２は、スイッチングサーバ１２から通信経由で受信されたDASHセグメント（セグメントリクエストReq2/1に応じたDASHセグメント）を、DASHクライアント２２−３に送信する。また、プロキシサーバ２１−２は、スイッチングサーバ１２から放送経由で受信されたDASHセグメント（セグメントリクエストReq2/2に応じたDASHセグメント）を、DASHクライアント２２−４−１乃至２２−４−ｉ，２２−６−１乃至２２−６−ｊにそれぞれ送信する。
【０２６９】
以上のように、第４の期間（時刻t3以降）においては、セグメントリクエストReq2/2において、特定のセグメントURLに対するリクエストの増加が発生して、ストリーミングサービスのトラフィックの集中が発生しているため、セグメントリクエストReq2/2に対するレスポンスを、放送オフローディングサービスを利用して、放送経由で返信している。
【０２７０】
また、セグメントリクエストReq1/1，Req2/1，Req1/2については、ストリーミングサービスのトラフィックの集中が発生していないため、それらのセグメントリクエスト（Req1/1，Req2/1，Req1/2）に対するレスポンスは、図１４の第１の期間と同様に、インターネット４１を介して通信経由で返信される。
【０２７１】
＜４．識別情報の挿入方法＞
【０２７２】
プロキシサーバ２１により、セグメントリクエストに対し、放送ネットワーク識別情報とソース識別情報を挿入する方法であるが、例えば、セグメントリクエストのHTTPリクエストのヘッダを拡張することで、それらの識別情報を拡張することができる。
【０２７３】
（拡張ヘッダの例）
図１８は、本技術の拡張ヘッダの例を示す図である。
【０２７４】
図１８には、HTTPリクエストヘッダの拡張の一例として、ATSC3.0サービスの場合の拡張ヘッダの記述例を示している。
【０２７５】
図１８において、HTTPリクエストヘッダの汎用ヘッダに拡張する拡張ヘッダ名は、例えば、"ATSC3.0-request"とされる。ここで、汎用ヘッダは、リクエストやレスポンスのエンティティボディではなく、接続に対して適用されるヘッダを意味する。なお、拡張ヘッダ名を、プライベートヘッダとして定義する場合には、"X-ATSC3.0-request"とすることができる。
【０２７６】
拡張ヘッダの値としては、サービスID（service-id）、コンテンツID（contentId）、MPDメタデータのURL（mpd-uri）、時刻情報（broadcastTime）、及びブロードキャストストリームIDリスト（broadcastStreamIdList）等のATSC3.0サービスの配信関連の主な属性を含めることができる。
【０２７７】
サービスIDは、ATSC3.0で規定されるサービスを識別するためのID（グローバルサービスID）である。このサービスIDは、必須の値とされる。
【０２７８】
なお、ATSC3.0規定のサービスID（globalServiceId）の詳細は、下記の非特許文献２の「Table 7.1 Semantics of the User Service Bundle Description Fragment for ROUTE/DASH」に開示されている。すなわち、サービスIDとしては、USBDメタデータのuserServiceDescription要素のglobalServiceID属性の値を用いることができる。
【０２７９】
非特許文献２：ATSC Candidate Standard: Signaling, Delivery, Synchronization,and Error Protection(A/331)
【０２８０】
MPDメタデータのURLは、USBDメタデータにより参照されるMPDメタデータの絶対パスを表したURI(Uniform Resource Identifier)である。このURLは、オプショナルな値とされる。
【０２８１】
なお、上記の非特許文献２の「Table 7.1 Semantics of the User Service Bundle Description Fragment for ROUTE/DASH」に開示されているように、MPDメタデータのURLとしては、USBDメタデータのuserServiceDescription要素のfullMPDUri属性の値を用いることができる。
【０２８２】
時刻情報は、コンテンツが実際に放送された時刻を表している。ただし、放送時刻の内容の選択は、実装依存とされる。つまり、例えば、放送時刻が、コンテンツの配信スケジュールの開始時刻であるのか、あるいは配信スケジュールの開始から終了までの任意の時刻（HTTPリクエストのパケットが到着した時刻）であるのかは、運用に応じて設定される。この時刻情報は、オプショナルな値とされる。
【０２８３】
コンテンツIDは、コンテンツを識別するIDである。このコンテンツIDとしては、例えば、"EIDR"又は"Ad-ID"を指定することができる。
【０２８４】
ここで、"EIDR"は、Entertainment Identifier Registryの略であり、テレビ番組や映画のコンテンツを、グローバルな単一のIDで管理することができる。"Ad-ID"は、Advertising IDの略であり、広告用のIDである。このコンテンツIDは、オプショナルな値とされる。
【０２８５】
ブロードキャストストリームIDリストは、ATSC3.0で規定されるブロードキャストストリームを識別するためのブロードキャストストリームID（bsid：BroadcastStreamID）のリストである。
【０２８６】
なお、ATSC3.0規定のブロードキャストストリームID（bsid）の詳細は、上記の非特許文献２の「Table 6.2 SLT XML Format」に開示されている。すなわち、ブロードキャストストリームIDとしては、LLSのSLTメタデータのSLT要素のbsid属性を用いることができる。
【０２８７】
ここで、図１９には、HTTPリクエストに対し、拡張ヘッダとして挿入される情報の例を示している。
【０２８８】
すなわち、図１９においては、XML形式のUSBDメタデータとMPDメタデータの記述例を示しているが、これらのメタデータから得られる情報を、ATSC3.0サービスの配信関連の属性として、HTTPリクエストの拡張ヘッダに含めることができる。
【０２８９】
例えば、USBDメタデータにおいては、userServiceDescription要素のglobalServiceID属性の値から、サービスID（グローバルサービスID）が得られ、userServiceDescription要素のfullMPDUri属性の値から、MPDメタデータのURLが得られる。また、例えば、MPDメタデータにおいては、Period要素のAssetIdentifier要素の値から、EIDRに対応したコンテンツIDが得られる。
【０２９０】
なお、USBDメタデータのDeliveryMethod要素に記述されるURLと、MPDメタデータのRepresentation要素に記述されるURL（セグメントURL）とのマッチングを行うことで、コンテンツのデータ（ストリーム）の配信経路が、放送経由であるのか、あるいは通信経由であるのかを特定することができる。
【０２９１】
次に、図２０及び図２１を参照して、HTTPリクエストヘッダの具体的な例を示す。ここでは、まず、図２０を参照して、拡張ヘッダ挿入前のHTTPリクエストヘッダを説明してから、図２１を参照して、拡張ヘッダ挿入後のHTTPリクエストヘッダを説明する。
【０２９２】
（HTTPリクエスト）
図２０は、HTTPリクエストの例を示す図である。
【０２９３】
図２０においては、セグメントURLが、"http://a.com/a.mp4"の場合に、このDASHセグメントファイルを取得するためのHTTPリクエストの例を示している。
【０２９４】
このHTTPリクエストは、HTTPで定義されているメソッドのうち、GETメソッドを利用している。HTTPリクエストでは、HOSTにより、ホスト名（サーバ名）が指定され、GETメソッドにより、リソースが指定される。なお、"HTTP/1.1"は、HTTPのバージョンを表している。
【０２９５】
なお、HTTPリクエストでは、１行目がHTTPリクエスト行となり、２行目以降がHTTPヘッダ行、すなわち、HTTPリクエストヘッダとされる。また、GETメソッドを利用する場合、HTTPボディ部には、何も記述されることはない。
【０２９６】
（拡張ヘッダ挿入後のHTTPリクエスト）
図２１は、拡張ヘッダが挿入されたHTTPリクエストの例を示す図である。
【０２９７】
図２１においては、図２０のHTTPリクエスト（HTTPリクエストヘッダ）に対し、拡張ヘッダとして、"atsc3.0-request"である拡張ヘッダ名の行が追加されている。
【０２９８】
すなわち、この拡張ヘッダとして、サービスID、コンテンツID、MPDメタデータのURL、時刻情報、及びブロードキャストストリームID（bsid）が追加されている。
【０２９９】
例えば、図２１のHTTPリクエストの拡張ヘッダでは、USBDメタデータのglobalServiceID属性の値である"urn:atsc:serviceId:NBCU-NFL-1"が、サービスID（service-id）として指定され、USBDメタデータのfullMPDUri属性の値である"http://a.com/a.mpd"が、MPDメタデータのURL（mpd-uri）として指定されている。
【０３００】
また、図２１のHTTPリクエストの拡張ヘッダでは、MPDメタデータのAssetIdentifier要素に記述されるEIDRである"md:cid:EIDR:10.5240%2f0EFB-02CD-126E-8092-1E49-W"が、コンテンツID（contentId）として指定されている。つまり、このコンテンツIDが、プロキシサーバ２１により挿入されるソース識別情報に相当している。
【０３０１】
また、図２１のHTTPリクエストの拡張ヘッダでは、当該コンテンツの放送時刻である2016年7月4日(金)23:54:58(グリニッジ標準時)を表した"Fri, 04 Jul 2016 23:54:58 GMT"が、時刻情報（broadcastTime）として指定されている。
【０３０２】
さらに、図２１のHTTPリクエストの拡張ヘッダでは、SLTメタデータのSLT要素のbsid属性の値である"bsid-1"が、ブロードキャストストリームID（bsid）として指定されている。つまり、このブロードキャストストリームIDが、プロキシサーバ２１により挿入される放送ネットワーク識別情報に相当している。
【０３０３】
以上のように、本技術では、プロキシサーバ２１が、HTTPリクエストに対し、拡張ヘッダとして、ソース識別情報（コンテンツID）と、放送ネットワーク識別情報（ブロードキャストストリームID）を挿入することで、スイッチングサーバ１２において、これらの識別情報に基づき、当該HTTPリクエストに対するレスポンスの返信経路として、放送経由（放送ネットワーク経由）での返信と、通信経由（双方向ネットワーク）での返信とを動的に切り替えることができるようにしている。
【０３０４】
なお、プロキシサーバ２１において、放送ネットワーク識別情報として挿入されるブロードキャストストリームID（bsid）は、自身が備えるチューナ２０１が選局可能なブロードキャストストリーム（BroadcastStream）に流れるLLSのSLTメタデータから得られる。
【０３０５】
また、プロキシサーバ２１において、ブロードキャストストリームID（bsid）を挿入する際には、事前に取得済みであるSLTメタデータやESG情報の内容（周知情報）を確認して、対象の時間帯に、放送オフローディングサービスが利用可能であるブロードキャストストリームID（bsid）であるかを確認した上で、HTTPリクエストに対して挿入することになる。このSLTメタデータやESG情報に含まれる周知情報の詳細は、後述する。
【０３０６】
さらに、プロキシサーバ２１においては、拡張ヘッダ挿入処理に先立って、放送ネットワーク識別情報やソース識別情報などの情報を格納したマッピングデータベースをあらかじめ生成しておくことで、拡張ヘッダ挿入処理では、当該マッピングデータベースを参照することにより、HTTPリクエストに挿入すべき情報を取得することが可能となる。
【０３０７】
なお、ここでは、デジタル放送の規格として、米国等で採用される方式であるATSC（特にATSC3.0）を一例に説明したが、本技術は、日本等が採用する方式であるISDB(Integrated Services Digital Broadcasting)や、欧州の各国等が採用する方式であるDVB(Digital Video Broadcasting)などに適用するようにしてもよい。
【０３０８】
ただし、上述した説明では、HTTPリクエストに挿入すべき情報として、ATSC3.0サービスを前提に、サービスIDやコンテンツID、ブロードキャストストリームID（bsid）などを例示列挙したが、それらに限らず、ISDBやDVB等の規格ごとに、より適した情報を用いることができる。
【０３０９】
また、デジタル放送の規格以外で規定された情報を、必要に応じて、HTTPリクエストに挿入すべき情報として加えることもできる。例えば、移動体通信システムの標準化プロジェクトである3GPP(Third Generation Partnership Project)で規定された情報を追加することもできる。具体的には、HTTPリクエストに挿入すべき情報として、3GPP-MBMS(Multimedia Broadcast Multicast Services)で規定される要素や属性を加えることができる。
【０３１０】
＜５．放送オフローディングサービスの周知方法＞
【０３１１】
次に、放送オフローディングサービスが利用可能であることを周知するための周知情報の配信方法について説明する。ここでは、例えば、LLS（SLTメタデータ）を拡張するか、あるいはESG情報を拡張することで、周知情報が配信されるようにする。
【０３１２】
（LLSの拡張による周知情報の配信）
LLSの１つであるSLTメタデータにおいては、サービスの種別を示すserviceCategory属性が規定されている（上記の非特許文献２参照）。
【０３１３】
図２２には、SLTメタデータのサービスループ内に配置されるserviceCategory属性の値の例が示されている。
【０３１４】
図２２に示すように、このserviceCategory属性により、例えば、通常の放送サービス（1：Linear A/V service）であるとか、音声のみのサービス（2：Linear audio only service）であるとかのサービスの種別を指定することができる。なお、音声のみのサービスは、現行のラジオ放送に相当する。
【０３１５】
上記の非特許文献２の「Table 6.4 Code Values for SLT.Service@serviceCategory」に規定されているように、serviceCategory属性には、0〜5とOther valuesの値が定義されている。
【０３１６】
このserviceCategory属性の値として、新たに"6"を定義して、放送オフローディングサービス（Broadcast off-loading service）を意味するようにする。すなわち、ここでは、要素や属性の追加ではなく、属性値の追加拡張によって、SLTメタデータに、放送オフローディングサービスが配信されることを示す周知情報を含めることができる。
【０３１７】
図２３には、SLTメタデータの記述例を示している。例えば、2016年9月12日の13時から15時までの間に、この放送オフローディングサービスが利用可能である場合、この時間帯のSLTメタデータのService要素のうちの１つに、serviceCategory属性の値として、serviceCategory = "6"が指定される。つまり、2016年9月12日の13時から15時までの間は、当該SLTメタデータが配信されることになる。
【０３１８】
（ESGの拡張による周知情報の配信）
ESGサービスは、携帯電話の規格策定を行う組織であるOMA（Open Mobile Alliance）によって規定されている電子サービスガイド（電子番組表）であるが、ATSC3.0においてもOMA-ESGに準拠した番組情報（ESG）を利用することが想定されている（下記の非特許文献３参照）。
【０３１９】
非特許文献３：ATSC Candidate Standard: Service Announcement (A/332)
【０３２０】
図２４に示すように、ATSC3.0の番組情報（ESG）においては、通常の放送サービス（Liner service）、ラジオ放送（Linear audio only service）、又はApp-basedサービス（app-based enhancement service）であるかのサービスの種別を示すServiceTypeという要素がある。
【０３２１】
なお、ESGのServiceType要素と、SLTメタデータのserviceCategory属性とを比べれば、ESGの通常の放送サービスは、SLTメタデータで定義される通常の放送サービス（1：Linear A/V service）に相当し、ESGのラジオ放送は、SLTメタデータで定義される音声のみのサービス（2：Linear audio only service）に相当する。さらに、ESGのApp-basedサービスは、SLTメタデータで定義されるApp-basedサービス（3：App-based service）に相当する。
【０３２２】
すなわち、ESGのServiceType要素としては、上記の非特許文献３の「5.2.2.1.1 Service Type」に規定される値が規定されている。
【０３２３】
このServiceType要素の値として、図２４に示すように、新たに"230"を定義して、放送オフローディングサービス（Broadcast off-loading service）を意味するようにする。すなわち、ここでは、要素や属性の追加ではなく、要素のコンテントとして格納する値の追加拡張によって、ESG情報に、放送オフローディングサービスが配信されることを示す周知情報を含めることができる。
【０３２４】
図２５には、ESG情報の記述例を示している。図２５に示すように、ESG情報のサービスフラグメント（Service fragment）に、ServiceType要素の値として、ServiceType = "230"が指定され、対象のサービスが、放送オフローディングサービスであることを表している。
【０３２５】
また、例えば、2016年9月12日の13時から15時までの間などの時間帯で、放送オフローディングサービスが利用可能である場合、ESG情報では、図２５に示したサービスフラグメント（Service fragment）のほか、コンテンツフラグメント（Content fragment）や、スケジュールフラグメント（Schedule fragment）等のXMLフラグメントを用いて、当該放送オフローディングサービスの有効期間を事前に通知することができる。その具体例を、図２６及び図２７に示す。
【０３２６】
（XMLフラグメントの関係）
図２６は、ある時間帯で、放送オフローディングサービスが利用可能である場合のサービス、コンテンツ、及びスケジュールのXMLフラグメントの関係を示す図である。
【０３２７】
サービスフラグメントは、"//a.com/Service-1"であるIDで識別され、ServiceType要素の値として、ServiceType = "230"が指定されている。つまり、当該サービス（Service-1）が、放送オフローディングサービスであることを表している。
【０３２８】
コンテンツフラグメントは、"//a.com/Content-1-1"であるIDで識別され、Name要素として、"Broadcast off-loading Service"が指定されている。つまり、当該コンテンツの名称は、放送オフローディングサービスである。
【０３２９】
なお、図２６において、コンテンツフラグメントは、ServiceReference要素のidRef属性の値により、サービスフラグメントと関連付けられている。
【０３３０】
スケジュールフラグメントは、"//a.com/Schedule-1-1"であるIDで識別され、ContentReference要素の子要素となるPresentationWindow要素のstartTime属性として、"2016-09-12T13:00:00+00:00"が指定され、endTime属性として、"2016-09-12T15:00:00+00:00"が指定される。
【０３３１】
つまり、startTime属性とendTime属性によって、放送オフローディングサービスの開始時刻t1と終了時刻t2が指定される。この例の場合には、2016年9月12日の13時から15時までの間で、放送オフローディングサービスが配信されることになる。
【０３３２】
なお、図２６において、スケジュールフラグメントは、ServiceReference要素のidRef属性の値により、サービスフラグメントと関連付けられている。また、スケジュールフラグメントは、ContentReference要素のidRef属性の値により、コンテンツフラグメントと関連付けられている。
【０３３３】
（ESGサービスの画面例）
図２７は、放送オフローディングサービスが利用可能である場合のESGサービスの画面の表示例を示す図である。
【０３３４】
図２７のESGサービスの画面は、図２６に示したXMLフラグメントを含むESG情報を受信したクライアント装置２０で表示される画面の表示例である。
【０３３５】
すなわち、このESGサービスの画面においては、開始時刻t1（2016年9月12日の13時）から終了時刻t2（2016年9月12日の15時）までの時間帯の枠内に、Service-1として、放送オフローディングサービス（Broadcast off-loading Service）が表示されている。これにより、エンドユーザに対し、その時間帯に、放送オフローディングサービスが配信されることを、事前に通知（周知）することができる。
【０３３６】
ただし、放送オフローディングサービスの配信を、ESGサービスの画面上に表示するかどうかは、クライアント装置２０のUI(User Interface)の実装次第である。
【０３３７】
なお、上述したLLSの拡張、及び、ESGの拡張による周知情報の配信方法のうち、少なくとも一方の配信方法によって、周知情報を配信するようにすればよい。また、LLSの拡張、及び、ESGの拡張による周知情報の配信方法以外の配信方法によって、周知情報が配信されるようにしてもよい。
【０３３８】
＜６．コンテンツ送受信処理＞
【０３３９】
（コンテンツ送受信処理の流れ）
次に、図２８乃至図３１のフローチャートを参照して、送信側と受信側の各装置で行われるコンテンツ送受信処理の詳細を説明する。
【０３４０】
なお、図２８乃至図３０において、ステップＳ１０１乃至Ｓ１０３、Ｓ１２１乃至１２８、及びＳ１４１乃至Ｓ１４６の処理は、送信側のDASHサーバ１１、スイッチングサーバ１２、及び放送サーバ１３によりそれぞれ実行される。一方で、ステップＳ２０１乃至Ｓ２０７、及び２２１乃至Ｓ２２５の処理は、受信側のプロキシサーバ２１、及びDASHクライアント２２によりそれぞれ実行される。
【０３４１】
図２８のステップＳ１４１において、ESG・メタデータ処理部１５１は、放送オフローディングサービスが利用可能であることを示す周知情報を生成し、ESG情報又はSLTメタデータに含める。
【０３４２】
ステップＳ１４２において、送信部１４２は、ステップＳ１４１の処理で得られる、周知情報を含むESG情報又はSLTメタデータを送信する。このESG情報又はSLTメタデータは、放送ネットワークを介して、対象の放送エリア内に設置されるプロキシサーバ２１により受信され、そこに含まれる周知情報によって、放送オフローディングサービスが利用可能であることが周知されることになる。
【０３４３】
ステップＳ２２１において、リクエスト処理部２３１は、所望のコンテンツのMPDリクエストを生成する。ここで、所望のコンテンツは、例えば、エンドユーザの操作に応じて選択される。
【０３４４】
ステップＳ２２２において、通信I/F２２１は、ステップＳ２２１の処理で得られるMPDリクエストを、プロキシサーバ２１に送信する。プロキシサーバ２１では、DASHクライアント２２からのMPDリクエストが受信され、通信I/F２０２によって、インターネット４１を介して、スイッチングサーバ１２に送信される。
【０３４５】
なお、ここでは、プロキシサーバ２１又はDASHクライアント２２が、例えば、インターネット４１上に公開されたストリーミングサイトのWebページにアクセスするなど、何らかの方法で、MPDメタデータのURLが取得されたことで、MPDリクエストが、DASHサーバ１１宛てに送信される。
【０３４６】
このように、DASHクライアント２２からのMPDリクエストは、インターネット４１等を経由して、最終的に、DASHサーバ１１により受信される。
【０３４７】
ステップＳ１０１において、MPD処理部１１１は、MPDリクエストに基づいて、MPDレスポンス（MPDメタデータ）を生成する。
【０３４８】
ステップＳ１０２において、通信I/F１０１は、ステップＳ１０１の処理で得られるMPDレスポンス（MPDメタデータ）をスイッチングサーバ１２に送信する。スイッチングサーバ１２では、DASHサーバ１１からのMPDレスポンスが受信され、通信I/F１２４によって、インターネット４１を介して、プロキシサーバ２１を経由して、DASHクライアント２２に送信される。
【０３４９】
なお、スイッチングサーバ１２では、DASHサーバ１１からのMPDレスポンスが転送されるが、そのとき、MPDレスポンスに含まれるMPDメタデータが、記憶部１２２に記録されるようにする（Ｓ１２１）。また、DASHサーバ１１からのMPDレスポンスは、インターネット４１等を経由して、最終的に、DASHクライアント２２により受信される。
【０３５０】
ステップＳ２２３において、リクエスト処理部２３１は、MPDレスポンスに含まれるMPDメタデータのパース結果に基づいて、所望のコンテンツのセグメントリクエストを生成する。
【０３５１】
ステップＳ２２４において、通信I/F２２１は、ステップＳ２２３の処理で得られるセグメントリクエストを、プロキシサーバ２１に送信する。プロキシサーバ２１では、DASHクライアント２２からのセグメントリクエストが受信される。
【０３５２】
図２９のステップＳ２０１において、ESG・メタデータ処理部２１１は、放送サーバ１３から受信したESG情報又はSLTメタデータを処理して、そこに含まれる周知情報を参照し、放送オフローディングサービスを利用できるかどうかを確認する。
【０３５３】
ステップＳ２０２において、ESG・メタデータ処理部２１１は、ステップＳ２０１の確認結果に基づいて、放送オフローディングサービスを利用できるかどうかを判定する。
【０３５４】
ステップＳ２０２において、放送オフローディングサービスを利用できると判定された場合、処理は、ステップＳ２０３に進められる。ステップＳ２０３において、リクエスト処理部２１２は、DASHクライアント２２からのセグメントリクエスト（HTTPリクエストのヘッダ）に対し、放送ネットワーク識別情報（ブロードキャストストリームID）を挿入する。
【０３５５】
そして、ステップＳ２０３の処理が終了すると、処理は、ステップＳ２０４に進められる。ステップＳ２０４において、リクエスト処理部２１２は、放送ネットワーク識別情報を含むセグメントリクエスト（HTTPリクエストのヘッダ）に対し、ソース識別情報（コンテンツID）をさらに挿入する。
【０３５６】
一方、ステップＳ２０２において、放送オフローディングサービスを利用できると判定された場合、ステップＳ２０３の処理はスキップされ、処理は、ステップＳ２０４に進められる。ステップＳ２０４において、リクエスト処理部２１２は、DASHクライアント２２からのセグメントリクエスト（HTTPリクエストのヘッダ）に対し、ソース識別情報（コンテンツID）を挿入する。
【０３５７】
このように、放送オフローディングサービスを利用できる場合には、セグメントリクエストに対し、放送ネットワーク識別情報とソース識別情報が挿入される一方で、放送オフローディングサービスを利用できない場合には、セグメントリクエストに対し、ソース識別情報のみが挿入される。
【０３５８】
ステップＳ２０５において、通信I/F２０２は、ステップＳ２０１乃至Ｓ２０４の処理で得られるセグメントリクエストを、インターネット４１を介してスイッチングサーバ１２に送信する。このセグメントリクエストは、スイッチングサーバ１２によって、DASHサーバ１１に転送される。
【０３５９】
ステップＳ１２２において、リクエスト処理部１３１は、プロキシサーバ２１からのセグメントリクエストを、記憶部１２２に記録する。
【０３６０】
ステップＳ１２３において、リクエスト処理部１３１は、プロキシサーバ２１からのセグメントリクエスト（HTTPリクエストのヘッダ）から、放送ネットワーク識別情報（ブロードキャストストリームID）と、ソース識別情報（コンテンツID）を抽出して処理する。
【０３６１】
ここでは、処理対象のセグメントリクエストの送信元のプロキシサーバ２１が、放送オフローディングサービスを利用できる場合には、当該セグメントリクエストには、放送ネットワーク識別情報及びソース識別情報が含まれる。一方で、処理対象のセグメントリクエストの送信元のプロキシサーバ２１が、放送オフローディングサービスを利用できない場合には、当該セグメントリクエストには、ソース識別情報のみが含まれる。
【０３６２】
そして、例えば、リクエスト処理部１３１は、ソース識別情報で識別されるコンテンツ（ソース）ごとに、一定の測定期間を設けて、セグメントリクエストのリクエスト数をカウントして、そのカウント値が、あらかじめ定められた閾値以上になった場合には、それ以降の該当するソース識別情報を含むセグメントリクエストに対するレスポンスが、放送返信モードで返信されるようにする。
【０３６３】
ステップＳ１２４において、リクエスト処理部１３１は、セグメントリクエストの処理結果に基づいて、当該セグメントリクエストに対するレスポンスについて、放送返信モードで対応するかどうかについて判定する。
【０３６４】
ステップＳ１２４において、放送返信モードで対応すると判定された場合、処理は、図３０のステップＳ１２５に進められる。図３０には、図２９のステップＳ１２４の判定処理以降の処理として、放送返信モード時の処理内容が示されている。
【０３６５】
なお、詳細は後述するが、ステップＳ１２４において、通信返信モードで対応すると判定された場合、処理は、図３１のステップＳ１３１に進められる。図３１には、ステップＳ１２４の判定処理以降の処理として、通信返信モード時の処理内容が示されている。
【０３６６】
図３０の説明に戻り、ステップＳ１２５において、放送処理部１３２は、処理対象のセグメントリクエストに対するレスポンスを、放送返信モードで返信する際の、対象の放送エリアを特定する。
【０３６７】
ステップＳ１２６において、放送処理部１３２は、ステップＳ１２５の処理で特定される対象の放送エリアでの放送を行う放送サーバ１３に対し、ソース識別情報とともに、SLS更新指示を送信する。
【０３６８】
ステップＳ１２７において、放送処理部１３２は、ステップＳ１２５の処理で特定される対象の放送エリアでの放送を行う放送サーバ１３に対し、放送返信モードでの開始セグメントURLと合わせて、ステップＳ１２１の処理で記憶されていたMPDメタデータを送信する。
【０３６９】
放送サーバ１３では、スイッチングサーバ１２からの、ソース識別情報及びSLS更新指示、並びに放送返信モードでの開始セグメントURL及びMPDメタデータが受信される。
【０３７０】
ステップＳ１４３において、ESG・メタデータ処理部１５１は、SLS（USBDメタデータ）を更新して、ソース識別情報で識別されるコンテンツ（ソース）のDASHセグメントが、放送返信モードで返信されることを示す情報を含める。
【０３７１】
なお、ここでは、USBDメタデータによるフラグに依らず、例えば、スイッチングサーバ１２からのMPDメタデータを更新して、当該MPDメタデータ内に、放送経由での返信か、通信経由での返信かを明示的に記述するなどの方法を用いてもよいことは、先に述べた通りである。
【０３７２】
ステップＳ１４４において、送信部１４２は、ステップＳ１４３の処理で得られる、更新後のSLS（USBDメタデータ）及びMPDメタデータを送信する。ただし、ステップＳ１４３の処理で、MPDメタデータの更新を行っていない場合には、未更新のMPDメタデータは送信せずに、SLSのみが送信されるようにしてもよい。
【０３７３】
この更新後のSLS及びMPDメタデータは、放送ネットワークを介して、対象の放送エリア内に設置されるプロキシサーバ２１により受信される。ステップＳ２０６において、ESG・メタデータ処理部２１１は、更新後のSLS（USBDメタデータ）及びMPDメタデータを処理する。
【０３７４】
この更新後のSLS（USBDメタデータ）及びMPDメタデータには、ソース識別情報で識別されるコンテンツ（ソース）のDASHセグメントが、放送返信モードで返信されることを示す情報が含まれているため、プロキシサーバ２１では、そのことを認識することができる。
【０３７５】
また、ESG・メタデータ処理部２１１は、ステップＳ２０６の処理結果に基づいて、MPDメタデータが更新されている場合には、更新後のMPDメタデータを、通信I/F２０３を介して、DASHクライアント２２に送信（通知）する。
【０３７６】
一方で、放送サーバ１３においては、DASHセグメント処理部１５２が、放送返信モードでの開始セグメントURLに基づいて、セグメントリクエストを、DASHサーバ１１に送信する。このセグメントリクエストは、DASHサーバ１１により受信される。なお、ここでは、スイッチングサーバ１２を介してセグメントリクエストがやりとりされるようにしてもよい。
【０３７７】
ステップＳ１０３において、DASHセグメント処理部１１２は、放送サーバ１３からのセグメントリクエストに基づいて、対象のコンテンツ（ソース）のDASHセグメントを取得し、スイッチングサーバ１２に送信する。このDASHセグメントは、スイッチングサーバ１２により受信される。
【０３７８】
ステップＳ１２８において、放送処理部１３２は、ステップＳ１２５の処理で特定される対象の放送エリアでの放送を行う放送サーバ１３に対し、DASHサーバ１１からのDASHセグメントを転送する。このDASHセグメントは、放送サーバ１３により受信され、処理される。
【０３７９】
ステップＳ１４６において、送信部１４２は、DASHセグメントを送信する。このDASHセグメントは、放送ネットワークを介して、対象の放送エリア内に設置されるプロキシサーバ２１により受信され、通信I/F２０３によって、DASHクライアント２２に転送される。
【０３８０】
ステップＳ２２５において、再生部２３２は、プロキシサーバ２１から転送されてくるDASHセグメントを再生する。これにより、DASHクライアント２２においては、セグメントリクエストに応じたDASHセグメントが処理され、所望のコンテンツが再生される。
【０３８１】
以上、図３０を参照して、図２９のステップＳ１２４の判定処理で、放送返信モードで対応すると判定された場合（Ｓ１２４の「YES」）のそれ以降の処理の流れを説明した。次に、図３１を参照して、図２９のステップＳ１２４の判定処理で、通信返信モードで対応すると判定された場合（Ｓ１２４の「NO」）のそれ以降の処理の流れを説明する。
【０３８２】
なお、図３１において、ステップＳ１１１、及びＳ１３１の処理は、送信側のDASHサーバ１１、及びスイッチングサーバ１２によりそれぞれ実行される。一方で、ステップＳ２３１の処理は、受信側のDASHクライアント２２により実行される。
【０３８３】
ステップＳ１１１において、DASHセグメント処理部１１２は、DASHクライアント２２又はスイッチングサーバ１２からのセグメントリクエストに基づいて、対象のコンテンツ（ソース）のDASHセグメントを取得し、スイッチングサーバ１２に送信する。このDASHセグメントは、スイッチングサーバ１２により受信される。
【０３８４】
ステップＳ１３１において、通信処理部１３３は、DASHサーバ１１からのDASHセグメントを、インターネット４１を介して、プロキシサーバ２１に送信（転送）する。このDASHセグメントは、インターネット４１を介して、プロキシサーバ２１により受信され、通信I/F２０３によって、DASHクライアント２２に転送される。
【０３８５】
ステップＳ２３１において、再生部２３２は、プロキシサーバ２１から転送されてくるDASHセグメントを再生する。これにより、DASHクライアント２２においては、セグメントリクエストに応じたDASHセグメントが処理され、所望のコンテンツが再生される。
【０３８６】
以上、図３１を参照して、図２９のステップＳ１２４の判定処理で、通信返信モードで対応すると判定された場合（Ｓ１２４の「NO」）のそれ以降の処理の流れを説明した。
【０３８７】
＜７．変形例＞
【０３８８】
（他の放送規格への適用）
上述した説明としては、デジタル放送の規格として、米国等で採用されている方式であるATSC（特に、ATSC3.0）を説明したが、本技術は、日本等が採用する方式であるISDB(Integrated Services Digital Broadcasting)や、欧州の各国等が採用する方式であるDVB(Digital Video Broadcasting)などに適用するようにしてもよい。
【０３８９】
また、上述した説明では、IP伝送方式が採用されるATSC3.0を例にして説明したが、IP伝送方式に限らず、例えば、MPEG2-TS(Transport Stream)方式等の他の方式に適用するようにしてもよい。
【０３９０】
さらに、デジタル放送の規格としては、地上波放送のほか、放送衛星（BS：Broadcasting Satellite)や通信衛星（CS：Communications Satellite）等を利用した衛星放送や、ケーブルテレビ（CATV：Common Antenna TeleVision）等の有線放送などの規格に適用することができる。
【０３９１】
（その他の変形例）
上述した制御情報（シグナリング）などの名称は、一例であって、他の名称が用いられる場合がある。ただし、これらの名称の違いは、形式的な違いであって、対象の制御情報などの実質的な内容が異なるものではない。
【０３９２】
例えば、USBD(User Service Bundle Description)は、USD(User Service Description)と称される場合がある。また、例えば、NRT(Non Real Time)は、LCC(Locally Cached Content)と称され、ESG(Electronic Service Guide)は、EPG(Electronic Program Guide)と称される場合がある。
【０３９３】
また、上述したDASHクライアント２２において、DASHセグメントを再生するためのDASHプレーヤは、例えば、HTML5(HyperText Markup Language 5)などのマークアップ言語やJavaScript（登録商標）等のスクリプト言語で開発されたアプリケーションのほか、例えば、Java（登録商標）などのプログラミング言語で開発されたアプリケーションとすることができる。
【０３９４】
さらに、このアプリケーションは、ブラウザにより実行されるアプリケーションに限らず、いわゆるネイティブアプリケーションとして、オペレーティングシステム（OS：Operating System）環境などで実行されるようにしてもよい。
【０３９５】
なお、アプリケーションは、何らかの情報を明示的に表示するだけでなく、非表示で（バックグラウンドで）動作されるようにしてもよい（エンドユーザに認識されずに起動するようにしてもよい）。また、コンテンツは、動画や音楽のほか、例えば、電子書籍やゲーム、広告など、あらゆるコンテンツを含めることができる。
【０３９６】
＜８．コンピュータの構成＞
【０３９７】
上述した一連の処理は、ハードウェアにより実行することもできるし、ソフトウェアにより実行することもできる。一連の処理をソフトウェアにより実行する場合には、そのソフトウェアを構成するプログラムが、コンピュータにインストールされる。図３２は、上述した一連の処理をプログラムにより実行するコンピュータのハードウェアの構成例を示す図である。
【０３９８】
コンピュータ１０００において、CPU(Central Processing Unit)１００１、ROM(Read Only Memory)１００２、RAM(Random Access Memory)１００３は、バス１００４により相互に接続されている。バス１００４には、さらに、入出力インターフェース１００５が接続されている。入出力インターフェース１００５には、入力部１００６、出力部１００７、記録部１００８、通信部１００９、及び、ドライブ１０１０が接続されている。
【０３９９】
入力部１００６は、キーボード、マウス、マイクロフォンなどよりなる。出力部１００７は、ディスプレイ、スピーカなどよりなる。記録部１００８は、ハードディスクや不揮発性のメモリなどよりなる。通信部１００９は、ネットワークインターフェースなどよりなる。ドライブ１０１０は、磁気ディスク、光ディスク、光磁気ディスク、又は半導体メモリなどのリムーバブル記録媒体１０１１を駆動する。
【０４００】
以上のように構成されるコンピュータ１０００では、CPU１００１が、ROM１００２や記録部１００８に記録されているプログラムを、入出力インターフェース１００５及びバス１００４を介して、RAM１００３にロードして実行することにより、上述した一連の処理が行われる。
【０４０１】
コンピュータ１０００（CPU１００１）が実行するプログラムは、例えば、パッケージメディア等としてのリムーバブル記録媒体１０１１に記録して提供することができる。また、プログラムは、ローカルエリアネットワーク、インターネット、デジタル衛星放送といった、有線又は無線の伝送媒体を介して提供することができる。
【０４０２】
コンピュータ１０００では、プログラムは、リムーバブル記録媒体１０１１をドライブ１０１０に装着することにより、入出力インターフェース１００５を介して、記録部１００８にインストールすることができる。また、プログラムは、有線又は無線の伝送媒体を介して、通信部１００９で受信し、記録部１００８にインストールすることができる。その他、プログラムは、ROM１００２や記録部１００８に、あらかじめインストールしておくことができる。
【０４０３】
ここで、本明細書において、コンピュータがプログラムに従って行う処理は、必ずしもフローチャートとして記載された順序に沿って時系列に行われる必要はない。すなわち、コンピュータがプログラムに従って行う処理は、並列的あるいは個別に実行される処理（例えば、並列処理あるいはオブジェクトによる処理）も含む。また、プログラムは、１のコンピュータ（プロセッサ）により処理されるものであってもよいし、複数のコンピュータによって分散処理されるものであってもよい。
【０４０４】
なお、本技術の実施の形態は、上述した実施の形態に限定されるものではなく、本技術の要旨を逸脱しない範囲において種々の変更が可能である。
【０４０５】
また、本技術は、以下のような構成をとることができる。
【０４０６】
（１）
複数の受信装置から送信されてくる、コンテンツのリクエストを処理して、前記リクエストに対するレスポンスを返信する処理部を備え、
前記リクエストは、前記受信装置で受信可能な放送エリアを識別するための第１の識別情報と、前記コンテンツを識別するための第２の識別情報を含み、
前記処理部は、前記第１の識別情報及び前記第２の識別情報に基づいて、前記レスポンスの返信経路として、通信経由での返信と、放送経由での返信とを動的に切り替える
情報処理装置。
（２）
前記処理部は、
通常時の場合、前記レスポンスの返信経路として、通信経由の経路を選択し、
通信経由の経路に負荷がかかっている場合、前記レスポンスの返信経路として、放送経由の経路を選択する
前記（１）に記載の情報処理装置。
（３）
前記処理部は、
前記第２の識別情報により識別される前記コンテンツごとに、一定の期間で、前記リクエストの数をカウントし、
そのカウント値が、あらかじめ定められた閾値以上となった場合に、該当する第２の識別情報を含むリクエストに対するレスポンスが、前記第１の識別情報に基づいた放送経由で返信されるようにする
前記（２）に記載の情報処理装置。
（４）
前記処理部は、前記レスポンスの返信経路が、通信経由の経路から放送経由の経路に切り替えられる場合に、前記レスポンスを放送経由で返信する第１のサーバに対し、放送経由での返信が行われることを前記受信装置に通知させるために、制御情報の更新を要求する
前記（２）又は（３）に記載の情報処理装置。
（５）
前記処理部は、前記第１の識別情報により識別される放送エリア内の前記第１のサーバに対し、前記レスポンスとして、第２のサーバから配信されるコンテンツのストリームのセグメントを転送する
前記（４）に記載の情報処理装置。
（６）
前記処理部は、前記受信装置が放送経由で返信される前記レスポンスの受信に失敗した場合に、放送経由で返信される前記レスポンスと同一のレスポンスが、通信経由で返信されるようにする
前記（１）乃至（５）のいずれかに記載の情報処理装置。
（７）
前記第１の識別情報は、RF(Radio Frequency)チャネルに対応した情報であり、
前記第２の識別情報は、コンテンツIDである
前記（１）乃至（６）のいずれかに記載の情報処理装置。
（８）
前記コンテンツのストリームは、前記第２のサーバから、ライブストリーム又はVOD(Video On Demand)ストリームとして配信される
前記（５）に記載の情報処理装置。
（９）
前記通信経由の経路は、インターネットを含む経路であり、
前記放送経由の経路は、IP(Internet Protocol)伝送方式に対応した地上波放送による伝送経路である
前記（１）乃至（８）のいずれかに記載の情報処理装置。
（１０）
情報処理装置の情報処理方法において、
前記情報処理装置が、
複数の受信装置から送信されてくる、コンテンツのリクエストを処理して、前記リクエストに含まれる前記受信装置で受信可能な放送エリアを識別するための第１の識別情報、及び、前記コンテンツを識別するための第２の識別情報に基づいて、前記リクエストに対するレスポンスの返信経路として、通信経由での返信と、放送経由での返信とを動的に切り替える
ステップを含む情報処理方法。
（１１）
コンテンツのリクエストを処理して、自身が受信可能な放送エリアを識別するための第１の識別情報と、前記コンテンツを識別するための第２の識別情報を挿入する処理部を備え、
前記処理部は、送信装置から送信されてくる、前記リクエストに対するレスポンスとして、通信経由で返信されるレスポンス、又は放送経由で返信されるレスポンスを処理する
情報処理装置。
（１２）
前記レスポンスは、通常時の場合、通信経由で返信され、通信経由の経路に負荷がかかっている場合、放送経由で返信される
前記（１１）に記載の情報処理装置。
（１３）
前記処理部は、前記レスポンスを放送経由で返信する第１のサーバから送信されてくる周知情報に基づいて、通信経由の経路に負荷がかかっている場合に、放送経由の経路で前記レスポンスを返信するサービスが利用可能であるかどうかを認識する
前記（１２）に記載の情報処理装置。
（１４）
前記処理部は、
前記サービスが利用可能である場合、前記リクエストに対し、前記第１の識別情報及び前記第２の識別情報を挿入し、
前記サービスが利用できない場合、前記リクエストに対し、前記第２の識別情報のみを挿入する
前記（１３）に記載の情報処理装置。
（１５）
前記周知情報は、前記コンテンツとともに配信される制御情報に含まれる
前記（１４）に記載の情報処理装置。
（１６）
前記周知情報は、前記コンテンツに対して事前に配信される番組情報に含まれる
前記（１４）に記載の情報処理装置。
（１７）
前記第１の識別情報は、RFチャネルに対応した情報であり、
前記第２の識別情報は、コンテンツIDであり、
前記処理部は、前記第１の識別情報と、前記第２の識別情報を、前記リクエストのHTTP(Hypertext Transfer Protocol)ヘッダの拡張部分に挿入する
前記（１１）乃至（１６）のいずれかに記載の情報処理装置。
（１８）
前記コンテンツのストリームは、第２のサーバから、ライブストリーム又はVODストリームとして配信される
前記（１１）乃至（１７）のいずれかに記載の情報処理装置。
（１９）
前記通信経由の経路は、インターネットを含む経路であり、
前記放送経由の経路は、IP伝送方式に対応した地上波放送による伝送経路である
前記（１１）乃至（１８）のいずれかに記載の情報処理装置。
（２０）
情報処理装置の情報処理方法において、
前記情報処理装置が、
コンテンツのリクエストを処理して、自身が受信可能な放送エリアを識別するための第１の識別情報と、前記コンテンツを識別するための第２の識別情報を挿入し、
送信装置から送信されてくる、前記リクエストに対するレスポンスとして、通信経由で返信されるレスポンス、又は放送経由で返信されるレスポンスを処理する
ステップを含む情報処理方法。
【符号の説明】
【０４０７】
１１  DASHサーバ，  １２  スイッチングサーバ，  １３  放送サーバ，  １４  ESG・メタデータサーバ，  ２１  プロキシサーバ，  ２２  DASHクライアント，  ３１  送信所，  ４１  インターネット，  １００  処理部，  １０１  通信I/F，  １１１  MPD処理部，  １１２  DASHセグメント処理部，  １２０  処理部，  １２１  通信I/F，  １２２  記憶部，  １２３  通信I/F，  １２４  通信I/F，  １３１  リクエスト処理部，  １３２  放送処理部，  １３３  通信処理部，  １４０  処理部，  １４１  通信I/F，  １４２  送信部，  １５１  ESG・メタデータ処理部，  １５２  DASHセグメント処理部，  ２００  処理部，  ２０１  チューナ，  ２０２  通信I/F，  ２０３  通信I/F，  ２１１  ESG・メタデータ処理部，  ２１２  リクエスト処理部，  ２２０  処理部，  ２２１  通信I/F，  ２２２  表示部，  ２２３  スピーカ，  ２３１  リクエスト処理部，  ２３２  再生部，  １０００  コンピュータ，  １００１  CPU
【図１】
2018079295.tif 000003
【図２】
2018079295.tif 000004
【図３】
2018079295.tif 000005
【図４】
2018079295.tif 000006
【図５】
2018079295.tif 000007
【図６】
2018079295.tif 000008
【図７】
2018079295.tif 000009
【図８】
2018079295.tif 000010
【図９】
2018079295.tif 000011
【図１０】
2018079295.tif 000012
【図１１】
2018079295.tif 000013
【図１２】
2018079295.tif 000014
【図１３】
2018079295.tif 000015
【図１４】
2018079295.tif 000016
【図１５】
2018079295.tif 000017
【図１６】
2018079295.tif 000018
【図１７】
2018079295.tif 000019
【図１８】
2018079295.tif 000020
【図１９】
2018079295.tif 000021
【図２０】
2018079295.tif 000022
【図２１】
2018079295.tif 000023
【図２２】
2018079295.tif 000024
【図２３】
2018079295.tif 000025
【図２４】
2018079295.tif 000026
【図２５】
2018079295.tif 000027
【図２６】
2018079295.tif 000028
【図２７】
2018079295.tif 000029
【図２８】
2018079295.tif 000030
【図２９】
2018079295.tif 000031
【図３０】
2018079295.tif 000032
【図３１】
2018079295.tif 000033
【図３２】
2018079295.tif 000034
【国際調査報告】
2018079295.tif 000035
2018079295.tif 000036