(57)【要約】  本技術は、複数のサービスにおいて再利用されるリソースを共有することができるようにする受信装置、送信装置、及び、データ処理方法に関する。受信装置は、コンテンツを受信し、コンテンツとともに伝送される制御情報であって、コンテンツのリソースが、複数のサービスで共有されるリソースであるかどうかを示すリソース共有情報を含む制御情報に基づいて、コンテンツのリソースが、複数のサービスで共有されるように、リソースの記憶装置への記憶を制御する。本技術は、例えば、ATSC3.0に対応したテレビ受像機に適用することができる。
2017090457.tif 000002
【特許請求の範囲】
【請求項１】
コンテンツを受信する受信部と、
前記コンテンツとともに伝送される制御情報であって、前記コンテンツのリソースが、複数のサービスで共有されるリソースであるかどうかを示すリソース共有情報を含む前記制御情報に基づいて、前記コンテンツのリソースが、複数のサービスで共有されるように、前記リソースの記憶装置への記憶を制御する制御部と
を備える受信装置。
【請求項２】
前記制御部は、前記制御情報に含まれる前記リソース共有情報が、複数のサービスで共有されるリソースであることを示している場合、共有されるリソースである共有リソースを、他のリソースと区別して記憶させる
請求項１に記載の受信装置。
【請求項３】
前記コンテンツ及び前記制御情報は、放送波により伝送され、
前記サービスは、デジタル放送のサービスであり、
前記制御情報は、前記サービスを提供するためのシグナリングである
請求項２に記載の受信装置。
【請求項４】
前記シグナリングは、複数のサービスの属性を指定可能な第１のシグナリングであり、
前記第１のシグナリングは、サービス単位で指定された前記リソース共有情報を含む
請求項３に記載の受信装置。
【請求項５】
前記シグナリングは、サービスごとの属性を指定可能な第２のシグナリングであり、
前記第２のシグナリングは、対象のサービス内の所定の単位で指定された前記リソース共有情報を含む
請求項３に記載の受信装置。
【請求項６】
前記リソース共有情報は、サービス単位、セッション単位、又はアプリケーション単位で指定される
請求項５に記載の受信装置。
【請求項７】
前記コンテンツのリソースは、所定の形式のファイルであり、
前記制御部は、前記コンテンツとともに伝送されるアプリケーションの動作に応じて、共有リソースのファイルを、他のリソースのファイルが記憶される第１の記憶領域とは異なる第２の記憶領域に記憶させる
請求項３に記載の受信装置。
【請求項８】
前記制御部は、前記アプリケーションの動作に応じて、前記第２の記憶領域に記憶された共有リソースのファイルを消去する
請求項７に記載の受信装置。
【請求項９】
前記放送波は、IP(Internet Protocol)伝送方式に対応した放送波であり、
前記コンテンツのリソースのファイルのデータは、UDP(User Datagram Protocol)パケットを含むIPパケットに格納されて伝送される
請求項３に記載の受信装置。
【請求項１０】
前記コンテンツは、広告のコンテンツを含み、
前記リソース共有情報は、前記広告のコンテンツのリソースを共有する複数のサービスが属するグループを識別するための識別情報である
請求項１に記載の受信装置。
【請求項１１】
受信装置のデータ処理方法において、
前記受信装置が、
コンテンツを受信し、
前記コンテンツとともに伝送される制御情報であって、前記コンテンツのリソースが、複数のサービスで共有されるリソースであるかどうかを示すリソース共有情報を含む前記制御情報に基づいて、前記コンテンツのリソースが、複数のサービスで共有されるように、前記リソースの記憶装置への記憶を制御する
ステップを含むデータ処理方法。
【請求項１２】
コンテンツのリソースが、複数のサービスで共有されるリソースであるかどうかを示すリソース共有情報を含む制御情報を生成する生成部と、
前記コンテンツとともに、前記制御情報を送信する送信部と
を備える送信装置。
【請求項１３】
前記コンテンツ及び前記制御情報は、放送波により伝送され、
前記サービスは、デジタル放送のサービスであり、
前記制御情報は、前記サービスを提供するためのシグナリングである
請求項１２に記載の送信装置。
【請求項１４】
前記シグナリングは、複数のサービスの属性を指定可能な第１のシグナリングであり、
前記第１のシグナリングは、サービス単位で指定された前記リソース共有情報を含む
請求項１３に記載の送信装置。
【請求項１５】
前記シグナリングは、サービスごとの属性を指定可能な第２のシグナリングであり、
前記第２のシグナリングは、対象のサービス内の所定の単位で指定された前記リソース共有情報を含む
請求項１３に記載の送信装置。
【請求項１６】
前記リソース共有情報は、サービス単位、セッション単位、又はアプリケーション単位で指定される
請求項１５に記載の送信装置。
【請求項１７】
前記コンテンツのリソースは、所定の形式のファイルである
請求項１２に記載の送信装置。
【請求項１８】
前記放送波は、IP伝送方式に対応した放送波であり、
前記コンテンツのリソースのファイルのデータは、UDPパケットを含むIPパケットに格納されて伝送される
請求項１３に記載の送信装置。
【請求項１９】
前記コンテンツは、広告のコンテンツを含み、
前記リソース共有情報は、前記広告のコンテンツのリソースを共有する複数のサービスが属するグループを識別するための識別情報である
請求項１２に記載の送信装置。
【請求項２０】
送信装置のデータ処理方法において、
前記送信装置が、
コンテンツのリソースが、複数のサービスで共有されるリソースであるかどうかを示すリソース共有情報を含む制御情報を生成し、
前記コンテンツとともに、前記制御情報を送信する
ステップを含むデータ処理方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本技術は、受信装置、送信装置、及び、データ処理方法に関し、特に、複数のサービスにおいて再利用されるリソースを共有することができるようにした受信装置、送信装置、及び、データ処理方法に関する。
【背景技術】
【０００２】
クライアント装置において、特定のサービスに付随するアプリケーションのファイルに対するアクセスのパフォーマンスを向上させるためには、ローカルキャッシュにあらかじめ必要なファイルをキャッシュしておく必要がある。【０００３】
例えば、現在策定が進められている米国の次世代放送規格であるATSC(Advanced Television Systems Committee)3.0では、放送経由又は通信経由で取得されるあらゆるファイルが、クライアント装置におけるローカルなファイルシステム上のローカルキャッシュに一旦蓄積されて、ストリームのレンダラやアプリケーションに提供されるモデルが想定されている。ただし、ローカルなファイルシステムとしては、例えば、オンメモリ（On Memory）やSSD(Solid State Drive)などのファイルシステム、又は特別なデータベースなどが用いられる。【０００４】
これらのローカルキャッシュ上のファイルは、ある限定された期間キャッシュに維持された後で、ファイルに付随されたHTTP(Hypertext Transfer Protocol)ヘッダのキャッシュコントロールヘッダ（Cache Control Header）のパラメタに基づいて消去される。ただし、このような処理が行われるのは、ROUTE(Real-time Object Delivery over Unidirectional Transport)プロトコルの配信モードの一種であるエンティティモードとなる場合である。【０００５】
一般的に、クライアント装置のチューナや記憶リソースの制限から、すべての受信可能な放送波上のファイルをキャッシュすることができないため、その時点で、選局しているサービスに必要なファイル群のみを取得してキャッシュし、サービス（チャネル）が切り替えられた場合には、直ちに記憶リソースが解放されるというような動作が想定される。【０００６】
なお、放送番組や広告などのコンテンツを、放送局の放送サーバから一方向の放送経由で、あるいは通信サーバから双方向の通信経由で、クライアント装置に配信するための技術の開発や規格化が、現在、盛んに進められている。このような放送経由又は通信経由でデータ配信を実現する技術としては、例えば、特許文献１に開示されている技術が知られている。
【先行技術文献】
【特許文献】
【０００７】
【特許文献１】特開２０１４−５７２２７号公報
【発明の概要】
【発明が解決しようとする課題】
【０００８】
ここで、あるサービスで転送されるファイルのうち、例えば、どのサービスでも共通に利用される、広告のコンテンツなどのファイルを、複数のサービスで共有できれば、キャッシュの記憶領域や配信帯域などを有効に利用することができる。そのため、複数のサービスにおいて再利用されるリソースを共有するための提案が要請されていた。【０００９】
本技術はこのような状況に鑑みてなされたものであり、複数のサービスにおいて再利用されるリソースを共有することができるようにするものである。
【課題を解決するための手段】
【００１０】
本技術の第１の側面の受信装置は、コンテンツを受信する受信部と、前記コンテンツとともに伝送される制御情報であって、前記コンテンツのリソースが、複数のサービスで共有されるリソースであるかどうかを示すリソース共有情報を含む前記制御情報に基づいて、前記コンテンツのリソースが、複数のサービスで共有されるように、前記リソースの記憶装置への記憶を制御する制御部とを備える受信装置である。【００１１】
本技術の第１の側面の受信装置は、独立した装置であってもよいし、１つの装置を構成している内部ブロックであってもよい。また、本技術の第１の側面のデータ処理方法は、上述した本技術の第１の側面の受信装置に対応するデータ処理方法である。【００１２】
本技術の第１の側面の受信装置、及び、データ処理方法においては、コンテンツが受信され、前記コンテンツとともに伝送される制御情報であって、前記コンテンツのリソースが、複数のサービスで共有されるリソースであるかどうかを示すリソース共有情報を含む前記制御情報に基づいて、前記コンテンツのリソースが、複数のサービスで共有されるように、前記リソースの記憶装置への記憶が制御される。【００１３】
本技術の第２の側面の送信装置は、コンテンツのリソースが、複数のサービスで共有されるリソースであるかどうかを示すリソース共有情報を含む制御情報を生成する生成部と、前記コンテンツとともに、前記制御情報を送信する送信部とを備える送信装置である。【００１４】
本技術の第２の側面の送信装置は、独立した装置であってもよいし、１つの装置を構成している内部ブロックであってもよい。また、本技術の第２の側面のデータ処理方法は、上述した本技術の第２の側面の送信装置に対応するデータ処理方法である。【００１５】
本技術の第２の側面の送信装置、及び、データ処理方法においては、コンテンツのリソースが、複数のサービスで共有されるリソースであるかどうかを示すリソース共有情報を含む制御情報が生成され、前記コンテンツとともに、前記制御情報が送信される。
【発明の効果】
【００１６】
本技術の第１の側面、及び、第２の側面によれば、複数のサービスにおいて再利用されるリソースを共有することができる。【００１７】
なお、ここに記載された効果は必ずしも限定されるものではなく、本開示中に記載されたいずれかの効果であってもよい。
【図面の簡単な説明】
【００１８】
【図１】本技術を適用した伝送システムの一実施の形態の構成を示す図である。
【図２】本技術のIP伝送方式のプロトコルスタックの例を示す図である。
【図３】ROUTE/FLUTEの構造を示す図である。
【図４】ROUTEの詳細な構造を示す図である。
【図５】キャッシュクォータドメインの概要を示す図である。
【図６】クォータドメイン識別子の配置例を示す図である。
【図７】クォータドメイン識別子の指定方法を示す図である。
【図８】クォータドメイン識別子の指定とファイルキャッシュの関係を示す図である。
【図９】広告挿入の流れを説明する図である。
【図１０】受信側の上位層における処理の流れを示す図である。
【図１１】MPDメタデータのPeriod要素のxlink:href属性の記述例を示す図である。
【図１２】MPDメタデータによる時系列の広告挿入制御を説明する図である。
【図１３】MPDメタデータの記述例を示す図である。
【図１４】MPDメタデータの記述例を示す図である。
【図１５】SLTのフォーマットの例を示す図である。
【図１６】USBDのフォーマットの例を示す図である。
【図１７】S-TSIDのフォーマットの例を示す図である。
【図１８】SrcFlowのフォーマットの例を示す図である。
【図１９】ASTのフォーマットの例を示す図である。
【図２０】ASTのフォーマットの例を示す図である。
【図２１】ASTのフォーマットの例を示す図である。
【図２２】Ad/DASHサーバの構成例を示す図である。
【図２３】放送サーバの構成例を示す図である。
【図２４】通信サーバの構成例を示す図である。
【図２５】クライアント装置の構成例を示す図である。
【図２６】送信側の処理の流れを説明するフローチャートである。
【図２７】受信側の処理の流れを説明するフローチャートである。
【図２８】受信側の処理の流れを説明するフローチャートである。
【図２９】コンピュータの構成例を示す図である。
【発明を実施するための形態】
【００１９】
以下、図面を参照しながら本技術の実施の形態について説明する。なお、説明は以下の順序で行うものとする。
【００２０】
１．システムの構成
２．キャッシュクォータドメインの概要
３．アプリケーションの応用例
４．シグナリングの例
５．各装置の構成
６．各装置で実行される処理の流れ
７．変形例
８．コンピュータの構成
【００２１】
＜１．システムの構成＞
【００２２】
（伝送システムの構成）
図１は、本技術を適用した伝送システムの一実施の形態の構成を示す図である。なお、システムとは、複数の装置が論理的に集合したものをいう。
【００２３】
図１において、伝送システム１は、Ad/DASHサーバ１０、放送サーバ２０、通信サーバ３０、及び、クライアント装置４０から構成される。
【００２４】
Ad/DASHサーバ１０は、MPEG-DASH(Dynamic Adaptive Streaming over HTTP)に対応した配信サービスを行うためのサーバである。ここで、MPEG-DASHは、OTT-V(Over The Top Video)に従ったストリーミング配信規格であって、HTTP(Hypertext Transfer Protocol)をベースとしたストリーミングプロトコルを用いたアダプティブストリーミング配信に関する規格である。
【００２５】
このMPEG-DASHの規格では、動画や音声のファイルの管理情報であるメタデータを記述するためのマニフェストファイルと、動画のコンテンツを伝送するためのファイルフォーマットが規定されている。なお、前者のマニフェストファイルは、MPD(Media Presentation Description)と称される。また、後者のファイルフォーマットは、セグメントフォーマットとも称される。
【００２６】
Ad/DASHサーバ１０は、番組のコンテンツのセグメント（以下、DASHセグメントともいう）や、広告のコンテンツのセグメント（以下、Adセグメントともいう）のファイルを生成し、放送サーバ２０又は通信サーバ３０に送信する。また、Ad/DASHサーバ１０は、MPDメタデータを生成し、放送サーバ２０又は通信サーバ３０に送信する。
【００２７】
また、Ad/DASHサーバ１０は、アプリケーションを生成し、放送サーバ２０又は通信サーバ３０に送信する。このアプリケーションとしては、例えば、スクリプト（Script）を実行可能なスクリプトアプリケーションが含まれる。なお、スクリプトアプリケーションは、例えば、HTML5(HyperText Markup Language 5)等のマークアップ言語や、JavaScript（登録商標）等のスクリプト言語で開発されたアプリケーションとすることができる。
【００２８】
放送サーバ２０は、ATSC3.0等のデジタル放送の規格に準拠したデータ伝送を行うことが可能な送信機である。放送サーバ２０は、Ad/DASHサーバ１０から送信されてくるDASHセグメントやAdセグメント、MPDメタデータ、アプリケーションのファイルを処理し、シグナリングとともに、伝送路８０を介して送信（一斉同報配信）する。
【００２９】
また、放送サーバ２０には、NRTコンテンツが入力される。NRTコンテンツは、NRT(Non Real Time)放送で伝送されるコンテンツであって、クライアント装置４０のストレージに一旦蓄積された後で再生が行われる。放送サーバ２０は、そこに入力されるNRTコンテンツのファイルを処理し、伝送路８０を介して送信（一斉同報配信）する。
【００３０】
通信サーバ３０は、インターネット９０に接続されたクライアント装置４０からの要求に応じて、インターネット９０を介して各種のデータを提供するサーバである。通信サーバ３０は、Ad/DASHサーバ１０から送信されてくるDASHセグメントやAdセグメント、MPDメタデータ、アプリケーションのファイルを処理する。そして、通信サーバ３０は、クライアント装置４０からの要求に応じて、インターネット９０を介して、各種のファイルを送信する。
【００３１】
クライアント装置４０は、ATSC3.0等のデジタル放送の規格に準拠した伝送データを受信可能な受信機である。例えば、クライアント装置４０は、テレビ受像機やセットトップボックスなどの固定受信機、あるいは、スマートフォンや携帯電話機、タブレット型コンピュータなどのモバイル受信機である。クライアント装置４０は、例えば車載テレビなどの自動車に搭載される機器であってもよい。
【００３２】
クライアント装置４０は、放送サーバ２０から伝送路８０を介して送信（一斉同報配信）されてくる、DASHセグメントやAdセグメント、シグナリング、MPDメタデータ、アプリケーション、NRTコンテンツなどのファイルを受信して処理することで、放送番組や広告などのコンテンツの映像や音声を出力する。
【００３３】
また、クライアント装置４０は、通信機能を有する場合、インターネット９０を介して、通信サーバ３０にアクセスし、各種のファイルを取得することができる。例えば、クライアント装置４０は、通信サーバ３０からインターネット９０を介して送信（適応的にストリーミング配信）される、DASHセグメントやAdセグメント、MPDメタデータなどのファイルを受信して処理することで、VOD(Video On Demand)番組や広告などのコンテンツの映像や音声を出力する。
【００３４】
なお、伝送システム１において、伝送路８０は、地上波（地上波放送）のほか、例えば、放送衛星（BS：Broadcasting Satellite）や通信衛星（CS：Communications Satellite）を利用した衛星放送、あるいは、ケーブルを用いた有線放送（CATV）などであってもよい。
【００３５】
また、ATSC3.0は、現在策定が進められている米国の次世代放送規格である。ATSC3.0では、伝送方式として、現在広く普及しているMPEG2-TS(Transport Stream)方式ではなく、通信の分野で用いられているIP(Internet Protocol)パケットをデジタル放送に用いたIP伝送方式を導入することで、より高度なサービスを提供することが想定されている。
【００３６】
（本技術のプロトコルスタック）
図２は、本技術のIP伝送方式のプロトコルスタックの例を示す図である。
【００３７】
図２において、最も下位の階層は、物理層（Physical Layer）とされる。ATSC3.0等のIP伝送方式のデジタル放送では、一方向の放送を利用した伝送に限らず、一部のデータを、双方向の通信を利用して伝送する場合があるが、放送を利用する場合、その物理層（Broadcast）は、サービス（チャネル）のために割り当てられた放送波の周波数帯域が対応することになる。
【００３８】
物理層（Broadcast）の上位の階層は、IP層とされる。IP層は、通信の階層モデルにおけるネットワーク層に相当するものであり、IPアドレスによりIPパケットが特定される。IP層に隣接する上位階層は、通信の階層モデルにおけるトランスポート層に相当するUDP(User Datagram Protocol)層とされ、さらにその上位の階層は、ROUTE(Real-time Object Delivery over Unidirectional Transport)又はMMTP(MPEG Media Transport Protocol)とされる。
【００３９】
また、UDP層の上位の階層、すなわち、UDPパケットを含むIPパケットには、SLTメタデータが格納され、伝送される。SLSメタデータは、サービスの選局に必要な情報（選局情報）など、放送ネットワークにおけるストリームやサービスの構成を示す基本情報を含むLLS(Link Layer Signaling)シグナリングである。なお、LLSシグナリングは、SLS(Service Layer Signaling)シグナリングに先行して取得されるシグナリングであって、LLSシグナリングに含まれる情報に従い、SLSシグナリングが取得される。
【００４０】
ROUTEは、ストリーミングファイル転送用のプロトコルであって、FLUTE(File Delivery over Unidirectional Transport)を拡張したものである。なお、ROUTEの詳細な内容は、図３及び図４を参照して後述する。
【００４１】
ROUTEに隣接する上位階層のうち、一部の階層は、シグナリング（ROUTE specific Signaling）とNRTコンテンツ（NRT Files）とされる。このシグナリングは、SLSシグナリングであって、例えば、USBD(User Service Bundle Description)，S-TSID(Service-based Transport Session Instance Description)，MPD(Media Presentation Description)，AST(Application Signaling Table)等のメタデータが含まれる。
【００４２】
USDメタデータは、他のメタデータの取得先などの情報を含む。S-TSIDメタデータは、LSID(LCT Session Instance Description)をATSC3.0向けに拡張したものであって、ROUTEプロトコルの制御情報である。MPDメタデータは、上述したように、ストリーミング配信される動画や音声のファイルの管理情報である。ASTは、アプリケーションの制御情報である。
【００４３】
なお、NRTコンテンツは、ROUTEセッションで伝送されるコンテンツの一例であり、例えば、アプリケーションや電子サービスガイド（ESG：Electronic Service Guide）などのコンテンツが、ROUTEセッションにより伝送されるようにしてもよい。
【００４４】
ROUTEに隣接する上位階層のうち、上述した階層以外の他の階層は、DASHセグメント（ISO BMFF）とされる。また、DASHセグメント（ISO BMFF）に隣接する上位階層は、DASHプレーヤ／デコーダとされる。すなわち、トランスポートプロトコルとしてROUTEを用いる場合には、放送番組等のコンテンツを構成するサービスコンポーネント（ビデオやオーディオ、字幕等）のストリームデータが、ISO BMFF(ISO Base Media File Format)の規格に準じたDASHセグメント単位で、ROUTEセッションにより伝送される。
【００４５】
一方で、MMTPは、ストリーミングファイルを転送するためのプロトコルである。MMTPに隣接する上位階層のうち、一部の階層は、シグナリング（MMTP specific Signaling）とされる。このシグナリングとしては、例えば、USBD(User Service Bundle Description)やMPT(MMT Package Table)等のメタデータが含まれる。
【００４６】
また、MMTPに隣接する上位階層のうち、シグナリング以外の階層は、MPU(Media Processing Unit)（ISO BMFF）とされる。また、MPU（ISO BMFF）に隣接する上位階層は、DASHプレーヤ／デコーダとされる。すなわち、トランスポートプロトコルとしてMMTを用いる場合には、放送番組等のコンテンツを構成するサービスコンポーネント（ビデオやオーディオ、字幕等）のストリームデータが、ISO BMFF(ISO Base Media File Format)の規格に準じたMPU単位で、MMTPセッションにより伝送される。
【００４７】
このように、図２のプロトコルスタックにおいては、トランスポートプロトコルとして、ROUTEとMMTPとが併記されているため、一方向の放送系ストリーミング配信では、DASHセグメント（ISO BMFF）のファイルを転送するROUTEプロトコルか、あるいは、MPU（ISO BMFF）のファイルを転送するMMTPのいずれか一方のプロトコルを用いることになる。
【００４８】
また、双方向の通信を利用する場合、その物理層（Broadband）の上位の階層は、ネットワーク層に相当するIP層とされる。また、IP層に隣接する上位階層は、トランスポート層に相当するTCP(Transmission Control Protocol)層とされ、さらに、TCP層に隣接する上位階層は、アプリケーション層に相当するHTTP層とされる。すなわち、これらの階層によって、インターネット９０等のネットワークで稼働するTCP/IPなどのプロトコルが実装される。
【００４９】
HTTP層に隣接する上位階層のうち、一部の階層は、シグナリング（All Signaling Objects）とNRTコンテンツ（NRT Files）とされる。このシグナリングとしては、上述したROUTEやMMTPで伝送されるシグナリングなど、すべてのシグナリングが含まれる。また、NRTコンテンツは、通信経由で取得されるコンテンツの一例であり、例えば、アプリケーションなどのコンテンツが伝送されるようにしてもよい。
【００５０】
HTTP層に隣接する上位階層のうち、上述した階層以外の他の階層は、DASHセグメント（ISO BMFF）とされ、さらに、このDASHセグメント（ISO BMFF）に隣接する上位階層は、DASHプレーヤ／デコーダとされる。すなわち、双方向の通信系のストリーミング配信では、VOD番組等のコンテンツを構成するサービスコンポーネント（ビデオやオーディオ、字幕等）のストリームデータが、ISO BMFFの規格に準じたDASHセグメント単位で伝送されることになる。
【００５１】
また、一方向の放送のROUTEやMMTP等のプロトコル、双方向の通信のTCP/IPプロトコルなどを用いることで、アプリケーション（Applications）を伝送することができる。例えば、このアプリケーションは、HTML5やJS（JavaScript（登録商標））などにより開発されたアプリケーションとすることができる。
【００５２】
なお、図２において、ROUTEの一部に、HTTPプロキシ（HTTP Proxy）が記述されているのは、アプリケーションによって、DASHセグメント（ISO BMFF）のファイルを取得する場合に、クライアント装置４０に実装された放送ミドルウェアが、HTTPサーバとして振る舞う実装を想定しているためである。また、図２においては、コンテンツ保護のセキュリティフレームワークとして、W3C(World Wide Web Consortium)とMPEG(Moving Picture Experts Group)に準拠したEME/CENC(Encrypted Media Extension / Common Encryption Scheme)を採用しているため、DASHセグメント（ISO BMFF）と、MPU（ISO BMFF）の一部に、EME/CENCと記述されている。
【００５３】
また、LLSシグナリングとしてのSLTメタデータや、SLSシグナリングとしてのUSBD，S-TSID，MPD，AST等のメタデータは、XML(Extensible Markup Language)等のマークアップ言語により記述される。
【００５４】
以上のように、本技術のIP伝送方式のプロトコルスタックにおいては、一方向の放送系の階層と、双方向の通信系の階層の一部が共通のプロトコルとなって、一方向の放送と双方向の通信で、コンテンツを構成するサービスコンポーネントのストリームデータを、ISO BMFFの規格に準じたDASHセグメント単位で伝送することができる。そのため、一方向の放送系のストリーミング配信と、双方向の通信系のストリーミング配信の双方を行う場合において、上位の階層のプロトコルが共通化されているため、例えば、放送サーバ２０やクライアント装置４０では、実装の負担や処理の負担を軽減することができる。
【００５５】
（ROUTEの構造）
図３は、ROUTEの構造を示す図である。ただし、図３には、ROUTEとの比較のため、FLUTEについても記述している。
【００５６】
FLUTEは、ALC(Asynchronous Layered Coding)と呼ばれるスケーラブルなファイルオブジェクトのマルチキャストプロトコル、具体的には、そのビルディングブロックであるLCT(Layered Coding Transport)やFEC(Forward Error Correction)コンポーネントの組み合わせにより構成される。
【００５７】
ここで、ALCは、任意のバイナリファイルを一方向でマルチキャスト転送するのに適したプロトコルである。すなわち、ALCは、高信頼の非同期型の１対多の放送型のプロトコルとして開発されたものであるが、LCTとFECを利用しており、対象のファイルにFECをかけてLCTパケットに格納し、IPマルチキャスト上で転送する場合には、UDPパケットとIPパケットに格納する。
【００５８】
FLUTEにおけるトランスポートセッションは、送信元IPアドレスのスコープでユニークなTSI(Transport Session Identifier)により識別される。FLUTEでは、トランスポートセッションごと、又はファイルごとにFECの方式を変更することができる。また、FLUTEは、トランスポートセッションごとに転送されるFDT(File Delivery Table)と称されるXML形式の転送制御情報が導入されている。
【００５９】
LCTパケットに格納されたFECエンコーディングシンボルと同一のトランスポートセッション内で転送されるFDTファイルに、対象のファイルの基本属性と転送制御パラメタを記述する。FDTは、対象のファイルの識別子と対応するFECエンコーディングシンボル列が格納されたLCTパケット列とのマッピングを定義し、さらに個々のファイルの内容のMIMEタイプやサイズ、転送符号化方式、メッセージダイジェスト、FECデコードに必要なパラメタなどを格納することができる。なお、FDT自身にもFECを適用することが可能であり、自身のFECパラメタなどは別途LCTのレイヤで伝送することになる。
【００６０】
ところで、ROUTEは、FLUTEの拡張となるが、その差分としては、主に、オブジェクトバンドルとメディアアウェアなフラグメンテーションを挙げることができる。図４には、ROUTEの詳細な構造を示している。
【００６１】
ROUTEにおけるオブジェクトバンドルの特徴は、異なるサイズのソースブロックからなるビデオやオーディオのストリームをバンドルして、１つのスーパーオブジェクトとして構成し、それをもとにFECリペアストリームを生成する方法と、ソースストリームとリペアストリームの関係通知をプロトコルレベルでサポートしているところにある。
【００６２】
一般に、オーディオストリーム等は、単位時間あたりのデータ量（データオブジェクト）が小さいため、ビデオストリームと比べて、小さなソースオブジェクトサイズとなる。これらのソースオブジェクトサイズの異なるストリームに対して、同一のFEC方式でストリームごとにリペアシンボルを生成すると、ソースオブジェクトサイズの大小により、エラーに対する感受性が異なってくる。
【００６３】
ROUTEでは、複数のレートの異なるソースストリームからソースブロックを切り出してスーパーオブジェクトを構成し、それをもとに生成されるFECリペアシンボルによりリペアストリームを構成することができる。すなわち、異なる種類のソースストリームに跨ってリペアストリームが生成される。ここで、ソースシンボルからなるソースストリームと、リペアシンボルからなるリペアストリームと、ROUTEセッション内の別のLCTセッションとして転送することができる。
【００６４】
複数のソースストリームから切り出されたソースブロックから、どのようにスーパーオブジェクトを構成してFECストリームを生成するかについての情報（制御情報）が、LSID（FDT）を拡張したS-TSIDメタデータに記述される。受信機側では、このS-TSIDメタデータに記述された情報に基づいて、ROUTEセッションで伝送されるLCTパケット列から、スーパーオブジェクトを復元して、対象のファイルを抽出することができる。
【００６５】
一般に、放送ストリームは、送信機側で、サービスを構成するすべてのストリームを多重化して送信し、受信機側で、自身に必要なストリームを取捨選択するモデルである。したがって、送信機側で、サービスを構成するすべてのストリームからなるスーパーオブジェクトを構成して、受信機側でスーパーオブジェクトを復元してから、必要なストリームを取捨選択するという処理モデルの適用が可能なユースケースにおいては、ROUTEにより実現されるFEC構成方法が有効である。
【００６６】
以上、FLUTEの拡張であるROUTEについて説明した。
【００６７】
＜２．キャッシュクォータドメインの概要＞
【００６８】
ところで、クライアント装置４０において、放送番組等の特定のサービスに付随するアプリケーションに対するアクセスのパフォーマンスを向上させるためには、ローカルキャッシュにあらかじめ必要なファイルをキャッシュしておく必要がある。例えば、ATSC3.0では、放送経由又は通信経由で取得されるあらゆるファイルが、クライアント装置４０におけるローカルなファイルシステム上のローカルキャッシュに一時蓄積されて、ストリームのレンダラやアプリケーションに提供されるモデルが想定されている。
【００６９】
また、クライアント装置４０においては、チューナや記憶リソースの制限から、すべての受信可能な放送波上のファイルをキャッシュすることはできないため、その時点で選局しているサービスに必要なファイル群のみを取得してキャッシュし、サービス（チャネル）が切り替えられた場合には、直ちに記憶リソースを解放するというような動作が想定されている。
【００７０】
一方で、あるサービスで転送されるファイルのうち、例えば、どのサービスでも共通に利用される、広告のコンテンツなどのファイルを、複数のサービスで共有できれば、キャッシュの記憶領域や配信帯域などを有効に利用することができるなどのメリットがある。そのため、複数のサービスにおいて再利用されるリソースを共有するための提案が要請されているが、本技術では、キャッシュクォータドメイン（Cache Quota Domain）の概念を導入して、キャッシュクォータドメインを識別するクォータドメイン識別子をシグナリングとして伝送することで、クライアント装置４０で、複数のサービスにおいて再利用されるリソースを共有することができるようにする。
【００７１】
（キャッシュクォータドメインの概要）
図５は、キャッシュクォータドメインの概要を示す図である。
【００７２】
キャッシュクォータドメインは、再利用されるリソースを共有するためのドメイン（グループ）である。図５においては、サービスＡ、サービスＢ、及び、サービスＣが、クォータドメイン１に属し、サービスＸ、及び、サービスＹが、クォータドメイン２に属する場合を例示している。なお、図５のローカルキャッシュの記憶領域は、後述する図２５のローカルキャッシュ４０４の永続キャッシュ４０４Ｂに相当するものである。
【００７３】
この場合に、クライアント装置４０では、クォータドメイン１に属するサービスＡ乃至Ｃで共有されるアプリケーションやDASHセグメント等のファイルが、ローカルキャッシュのクォータドメイン１に割り当てられた記憶領域にキャッシュされる。すなわち、クォータドメイン１（のクォータドメイン識別子）により識別されるローカルキャッシュの記憶領域に、クォータドメイン１に属するサービスで共有されるファイルがキャッシュされるので、クォータドメイン１に属するサービスでは、当該記憶領域のファイルを取得して、処理（再生）することができる。
【００７４】
一方で、クォータドメイン２に属するサービスＸ及びＹで共有されるアプリケーションやDASHセグメント、ピリオドファイル等のファイルが、ローカルキャッシュのクォータドメイン２に割り当てられた記憶領域にキャッシュされる。すなわち、クォータドメイン２（のクォータドメイン識別子）により識別されるローカルキャッシュの記憶領域に、クォータドメイン２に属するサービスで共有されるファイルがキャッシュされるので、クォータドメイン２に属するサービスでは、当該記憶領域のファイルを取得して、処理（再生）することができる。
【００７５】
ただし、各サービスは、自身が属するクォータドメインを跨いで、他のクォータドメインのリソースにアクセスすることはできない。例えば、クォータドメイン１に属するサービスＡ乃至Ｃは、クォータドメイン２のリソースにアクセスすることはできないし、クォータドメイン２に属するサービスＸ及びＹは、クォータドメイン１のリソースにアクセスすることはできない。
【００７６】
このように、キャッシュクォータドメインの概念を導入することで、各クォータドメインに属するサービスでは、自身の属するクォータドメイン内のリソースを共有して利用（再利用）することが可能となる。
【００７７】
例えば、単一の放送局により提供される複数のサービス、あるいは、複数の放送局から組織される放送局連合により提供される複数のサービスなどが、同一のキャッシュクォータドメインに属することで、キャッシュクォータドメインごとに、複数のサービスが、リソース（ファイル）を共有することになる。
【００７８】
（クォータドメイン識別子の配置例）
図６は、クォータドメイン識別子の配置例を示す図である。
【００７９】
キャッシュクォータドメインを識別するクォータドメイン識別子は、放送波の各レイヤで伝送されるシグナリングにより伝送することができる。すなわち、シグナリングにおいて、対象のサービスが属するキャッシュクォータドメインのクォータドメイン識別子を指定可能な属性（又は要素）を追加することで、クライアント装置４０では、シグナリングに含まれるクォータドメイン識別子に基づいて、同一のキャッシュクォータドメインに属するサービスで、リソース（ファイル）を共有させることができる。
【００８０】
図６に示すように、クォータドメイン識別子は、IP/UDPパケットのペイロードに格納される、LLSシグナリングであるSLTメタデータ、又はIP/UDPパケットのペイロードに格納される、LCTセッションで伝送されるSLSシグナリングであるUSBDメタデータ、S-TSIDメタデータ、若しくはASTメタデータを拡張することで、そこに配置することができる。
【００８１】
（Ａ）SLTメタデータに配置する場合
キャッシュクォータドメインのクォータドメイン識別子が、SLTメタデータの拡張により指定される場合、SLTメタデータは、複数のサービスの属性を指定可能であるので、対象のサービスの属性として、クォータドメイン識別子を指定可能な属性（又は要素）を追加することになる。ここでは、例えば、SLTメタデータのservice要素に、quotaDomain属性を定義することで、対象のサービスが属するキャッシュクォータドメインのクォータドメイン識別子を指定することが可能となる。
【００８２】
例えば、サービスＡ乃至Ｚが提供される場合に、SLTメタデータでは、サービスＡ乃至ＣのサービスIDが指定されたservice要素のquotaDomain属性として、クォータドメイン１（図５）のクォータドメイン識別子が指定されるようにする。また、このSLTメタデータでは、サービスＸ及びＹのサービスIDが指定されたservice要素のquotaDomain属性として、クォータドメイン２（図５）のクォータドメイン識別子が指定されるようにする。
【００８３】
このように、SLTメタデータにおいて、service要素に、quotaDomain属性を定義することで、サービス単位で、クォータドメイン識別子を指定することが可能となる。
【００８４】
（Ｂ）USBDメタデータに配置する場合
キャッシュクォータドメインのクォータドメイン識別子が、USBDメタデータの拡張により指定される場合、USBDメタデータのUSD要素に、quotaDomain属性を定義することで、対象のサービスが属するキャッシュクォータドメインのクォータドメイン識別子を指定することが可能となる。
【００８５】
例えば、サービスＡ乃至Ｚが提供される場合に、サービスＡ乃至ＣのUSBDメタデータでは、USD要素のquotaDomain属性として、クォータドメイン１（図５）のクォータドメイン識別子が指定されるようにする。また、例えば、サービスＸ及びＹのUSBDメタデータでは、USD要素のquotaDomain属性として、クォータドメイン２（図５）のクォータドメイン識別子が指定されるようにする。
【００８６】
このように、USBDメタデータにおいて、USD要素に、quotaDomain属性を定義することで、サービス単位で、クォータドメイン識別子を指定することが可能となる。
【００８７】
（Ｃ）S-TSIDメタデータに配置する場合
キャッシュクォータドメインのクォータドメイン識別子が、S-TSIDメタデータの拡張により指定される場合、S-TSIDメタデータのRS要素のLS要素のsrcFlow要素のContentInfo要素に、quotaDomain属性を定義することで、対象のLCTセッションが属するキャッシュクォータドメインのクォータドメイン識別子を指定することが可能となる。
【００８８】
このように、S-TSIDメタデータにおいて、RS要素のLS要素のsrcFlow要素のContentInfo要素に、quotaDomain属性を定義することで、LCTセッション単位で、クォータドメイン識別子を指定することが可能となる。
【００８９】
（Ｄ）ASTメタデータに配置する場合
キャッシュクォータドメインのクォータドメイン識別子が、ASTメタデータの拡張により指定される場合、ASTメタデータのApplication要素のapplicationSpecificDescriptor要素のatsc:atscDescriptor要素に、quotaDomain属性を定義することで、対象のアプリケーションが属するキャッシュクォータドメインのクォータドメイン識別子を指定することが可能となる。
【００９０】
このように、ASTメタデータにおいて、Application要素のapplicationSpecificDescriptor要素のatsc:atscDescriptor要素に、quotaDomain属性を定義することで、アプリケーション単位で、クォータドメイン識別子を指定することが可能となる。
【００９１】
以上のように、SLTメタデータ、USBDメタデータ、S-TSIDメタデータ、又は、ASTメタデータを拡張して、クォータドメイン識別子を指定することで、同一のキャッシュクォータドメイン内で、サービス単位、LCTセッション単位、又は、アプリケーション単位で、リソース（ファイル）を共有させることができる。
【００９２】
すなわち、図７に示すように、各サービスは、１又は複数のLCTセッションから構成され、各LCTセッションでは、例えば、DASHセグメントやアプリケーションのファイル、任意のファイルなどが伝送されている。
【００９３】
ここで、図７に示すように、サービス単位でリソースを共有させたい場合には、SLTメタデータのサービスエントリ（サービスごとの基本属性）を拡張するか、又は、USBDメタデータのサービスごとの属性を拡張して、quotaDomain属性を定義するようにする。すなわち、対象のサービスで伝送されるファイルに対して、それらのファイルが格納されるローカルキャッシュの記憶領域を識別するためのクォータドメイン識別子が、SLTメタデータ又はUSBDメタデータのquotaDomain属性で指定される文字列に相当することになる。なお、この場合のファイルは、例えば、DASHセグメント、ピリオドファイル、又はアプリケーションなどのファイルであって、放送経由で取得されるファイルだけでなく、通信経由で取得されるファイルも含まれるものである。
【００９４】
ただし、SLTメタデータ又はUSBDメタデータのquotaDomain属性により、サービスレベルで、キャッシュクォータドメイン（例えば、クォータドメイン１）が指定された場合に、対象のサービスに属するLCTセッションで伝送されるすべてのファイルについて、ローカルキャッシュ（の永続キャッシュ）にキャッシュすることが指示された場合には、すべてのファイルが、ローカルキャッシュのキャッシュクォータドメイン（例えば、クォータドメイン１）に割り当てられた記憶領域にキャッシュされる（図８のＡ（Ｂ））。
【００９５】
なお、詳細は、図１５のSLTメタデータのフォーマットを参照して後述するが、SLTメタデータのservice要素には、SLSシグナリングのロケーション情報が指定される。そして、このロケーション情報は、SLSシグナリングが放送経由で取得される場合には、BroadcastSvcSignaling要素により指定され、SLSシグナリングが通信経由で取得される場合には、SvcInetUrl要素により指定される。例えば、USBDメタデータは、SLTメタデータのservice要素のロケーション情報に従い、放送経由又は通信経由で取得される。
【００９６】
また、図７に示すように、LCTセッション単位でリソースを共有させたい場合には、S-TSIDメタデータのLCTセッションごとの属性を拡張して、quotaDomain属性を定義するようにする。すなわち、対象のLCTセッションで伝送されるファイルに対して、それらのファイルが格納されるローカルキャッシュの記憶領域を識別するためのクォータドメイン識別子が、S-TSIDメタデータのquotaDomain属性で指定される文字列に相当することになる。なお、この場合のファイルは、例えば、DASHセグメント、ピリオドファイル、又はアプリケーションなどのファイルである。
【００９７】
ただし、S-TSIDメタデータのquotaDomain属性により、LCTセッションレベルで、キャッシュクォータドメイン（例えば、クォータドメイン１）が指定された場合には、対象のLCTセッションが属するサービスが、キャッシュクォータドメイン（例えば、クォータドメイン１）に属していると認識される。
【００９８】
そして、キャッシュクォータドメイン(例えば、クォータドメイン１)が指定されたLCTセッションで伝送されるファイルについて、ローカルキャッシュ（の永続キャッシュ）にキャッシュすることが指示された場合には、それらのファイルが、ローカルキャッシュのキャッシュクォータドメイン(例えば、クォータドメイン１)の記憶領域にキャッシュされる（図８のＣ１）。一方で、キャッシュクォータドメイン（例えば、クォータドメイン１）が指定されたLCTセッションと同一のサービスに属するLCTセッションであっても、キャッシュクォータドメイン（例えば、クォータドメイン１）が指定されていないLCTセッションについては、永続キャッシュの対象外とされる（図８のＣ２）。
【００９９】
なお、詳細は、図１６のUSBDメタデータのフォーマットを参照して後述するが、USBDメタデータのUSD要素のSTSIDUri属性には、S-TSIDメタデータの取得先を示すURI(Uniform Resource Identifier)が指定される。そして、このURIに従い、S-TSIDメタデータが取得される。
【０１００】
また、図７に示すように、アプリケーション単位でリソースを共有させたい場合には、ASTメタデータのアプリケーションごとの属性を拡張して、quotaDomain属性を定義するようにする。すなわち、対象のASTメタデータの記述対象とするアプリケーションのファイルが格納されるローカルキャッシュの記憶領域を識別するためのクォータドメイン識別子が、ASTメタデータのquotaDomain属性で指定される文字列に相当することになる。
【０１０１】
ただし、ASTメタデータのquotaDomain属性により、アプリケーションレベルで、キャッシュクォータドメイン（例えば、クォータドメイン１）が指定された場合には、対象のアプリケーションが属するサービスが、キャッシュクォータドメイン（例えば、クォータドメイン１）に属していると認識される。
【０１０２】
そして、キャッシュクォータドメイン（例えば、クォータドメイン１）が指定されたアプリケーションのファイルについて、ローカルキャッシュ（の永続キャッシュ）にキャッシュすることが指示された場合には、それらのファイルが、ローカルキャッシュのキャッシュクォータドメイン(例えば、クォータドメイン１)の記憶領域にキャッシュされる（図８のＤ）。一方で、キャッシュクォータドメイン（例えば、クォータドメイン１）が指定されたアプリケーションと同一のサービスに属するアプリケーションであっても、キャッシュクォータドメイン（例えば、クォータドメイン１）が指定されていないアプリケーションについては、永続キャッシュの対象外とされる。
【０１０３】
以上のように、キャッシュクォータドメインの概念を導入して、キャッシュクォータドメインを識別するクォータドメイン識別子（リソース共有情報）を、SLT，USBD，S-TSID，AST等のメタデータ（制御情報）に含めて伝送することで、クライアント装置４０では、同一のキャッシュクォータドメインに属するサービスに含まれるファイル（リソース）を、ローカルキャッシュ（の永続キャッシュ）に保持して、サービス単位、LCTセッション単位、又は、アプリケーション単位で共有させることが可能となる。
【０１０４】
＜３．アプリケーションの応用例＞
【０１０５】
次に、図９乃至図１４を参照して、第１のコンテンツ（放送番組）とともに伝送されるアプリケーションにより、第２のコンテンツ（広告）の挿入を行うシステムにおいて、キャッシュクォータドメインを実装する場合について説明する。なお、当該アプリケーションは、スクリプト（Script）を実行することで、広告挿入制御（Ad-Insertion）を行うものであるため、以下、スクリプトアプリケーション（Script App）と称して説明する。
【０１０６】
（広告挿入の流れ）
図９は、広告挿入の流れを説明する図である。
【０１０７】
図９においては、クライアント装置４０で、放送番組（BP1，BP2）の間に再生されるデフォルトの広告（TV1_Ad）の代わりに、ユーザに適合した広告（TV2_Ad）が挿入される場合の例を示している。
【０１０８】
図中の左側から右側の方向を時間の方向とした場合において、放送番組BP1が再生される時刻t1乃至時刻t2と、放送番組BP2が再生される時刻t3乃至時刻t4との間の時刻t2乃至時刻t3では、通常は、リアルタイムで取得される広告Ad1が再生される。
【０１０９】
また、この例では、デフォルトの広告Ad1と、挿入用の広告Ad2の２種類の広告が用意されているが、広告Ad2は、時刻t1乃至時刻t2で放送番組BP1-1が再生されているとき、すなわち、広告の挿入区間よりも時間的に前に、放送経由又は通信経由で取得され、ローカルキャッシュ（の永続キャッシュ）にキャッシュされている。
【０１１０】
クライアント装置４０では、放送番組BP1-2のシーンとなったとき、映像に、ユーザに対する質問が重畳表示される。そして、クライアント装置４０は、質問に対するユーザの回答に応じて、当該ユーザに適合した広告を表示させる。例えば、クライアント装置４０では、ユーザが質問に対して回答をした場合には、当該回答に応じた挿入用の広告Ad2が、ローカルキャッシュ（の永続キャッシュ）から読み出され、デフォルトの広告Ad1を、ユーザに適合した広告Ad2に差し替えて再生することになる。
【０１１１】
このように、ユーザにより視聴される可能性のある広告を、クライアント装置４０のローカルキャッシュ（の永続キャッシュ）にキャッシュしておくことで、そのキャッシュしていた広告を用いて、ユーザに適合した広告を表示させることができる。
【０１１２】
なお、図９の広告挿入の例では、ユーザの入力操作に応じて、当該ユーザに適合した広告のコンテンツが選択される例を示したが、このようなユーザとの間での情報のやりとり（インタラクション）のほか、例えば、ユーザのプリファレンスやプロファイル等のあらかじめ設定されたユーザの特性に関する情報（例えば、性別や年齢、居住地域等）などを用いて、広告のコンテンツが選択されるようにしてもよい。
【０１１３】
ところで、移動体通信システムの標準化プロジェクトである3GPP(Third Generation Partnership Project)や、DASH-IF(Industry Forum)においては、MPEG-DASHで規定されている、Period要素のXLinkによるパーソナライズされた広告挿入制御（Ad-Insertion）の実現方法が踏襲されているが、ATSC3.0においても、この広告挿入制御の実現方法が踏襲されることが想定されている。なお、XLinkは、XML文書同士のリンクを定義するための仕様であって、W3C(World Wide Web Consortium)により勧告されている。
【０１１４】
この広告挿入制御では、MPDメタデータの広告挿入区間に対応するPeriod要素を含むファイルをあらかじめ用意しておいて、広告のコンテンツのストリームに対応するセグメントを指定するPeriod要素を、ユーザの特性（例えば、ユーザプリファレンス等）に応じて動的に変更する方式を採用している。このような広告挿入制御に対応したクライアント装置４０が、図１０に示されている。
【０１１５】
図１０において、クライアント装置４０は、アプリケーション／コーデック機能と、DASHクライアント機能と、トランスポートスタック／HTTPサーバ機能を有している。また、トランスポートスタック／HTTPサーバ機能には、XLinkリゾルバ（XLink Resolver）と、HTTPプロキシキャッシュ（HTTP Proxy Cache）の機能が含まれる。ただし、XLinkリゾルバの機能は、通信サーバ３０のHTTPサーバが有するようにしてもよい。
【０１１６】
ここで、クライアント装置４０において、SLSシグナリングとして伝送されるMPDメタデータが受信された場合、MPDメタデータは、HTTPプロキシキャッシュにより取得され、DASHクライアントに通知される（Ｓ５１）。このMPDメタデータには、Period要素のxlink:href属性として、クライアント装置４０又は通信サーバ３０のHTTPサーバ上で稼働するXLinkリゾルバで解決されるURL(Uniform Resource Locator)が指定されている。
【０１１７】
具体的には、図１１に示すように、MPDメタデータに記述されたPeriod要素であるA1（Ad Break #1），M1（Main Program），A2（Ad Break #2），M2（Main Program），A3（Ad Break #3），M3（Main Program）のうち、A1（Ad Break #1）であるPeriod要素に注目すれば、xlink:href属性のURLとして、"http://adservice.com/adp-1?user=$groupID$"が記述されている。
【０１１８】
なお、A2（Ad Break #2）又はA3（Ad Break #3）においても、xlink:href属性のURLとして、"http://adservice.com/adp-1?user=$groupID$"が記述されており、A1（Ad Break #1）と同様に処理されるものとする。
【０１１９】
図１０の説明に戻り、クライアント装置４０においては、このURLのgroupIDのパラメタ部分に、ユーザを特定する値を挿入して、クライアント装置４０又は通信サーバ３０のHTTPサーバ上のXLinkリゾルバに、HTTPリクエストを発行することになる（Ｓ５２）。例えば、"http://adservice.com/adp-1?user=classA"のように、groupIDの値が挿入されたURLが、XLinkリゾルバに通知される。
【０１２０】
クライアント装置４０又は通信サーバ３０のXLinkリゾルバは、DASHクライアントから、groupIDの値が挿入されたURLが通知されると、groupIDにより指定される特定のユーザ（例えば、classAのユーザ）向けに生成されたURLを含むPeriod要素のファイル（以下、ピリオドファイルという）を、DASHクライアントに返信する（Ｓ５３）。このPeriod要素に含まれるURLは、一方向の放送経由の場合のROUTEプロトコルや、双方向の通信経由の場合のHTTPプロトコルにより配信されるセグメントのURL（セグメントURL）となる。
【０１２１】
そして、クライアント装置４０においては、DASHクライアントとHTTPプロキシキャッシュとが、ステップＳ５３の処理で取得されたピリオドファイルのPeriod要素に応じて、セグメントのリクエストやデリバリなどのやりとりを行うことで、当該Period要素のセグメントURLに応じたセグメントが取得される（Ｓ５４）。
【０１２２】
このようにして取得されるセグメントに応じた広告のコンテンツが、広告の挿入区間（例えば、図９の時刻t2乃至時刻t3の区間）で再生されることになる。
【０１２３】
より具体的には、図１２には、00:00:00〜00:15:00の間に、M1（Main Program）が再生され、00:15:00〜00:30:00の間に、M2（Main Program）が再生され、00:30:00〜00:42:00の間に、M3（Main Program）が再生される場合において、M1の再生よりも時間的に前にA1（Ad Break #1）が挿入され、M1とM2の間にA2（Ad Break #2）が挿入され、M2とM3の間に、A3（Ad Break #3）が挿入されるときの広告挿入制御を例示している。
【０１２４】
この例では、A1（Ad Break #1）として、３種類の広告が用意されており、例えば30代の男性や60代の女性などのユーザの特性（例えば、ユーザプリファレンス等）に応じて、再生される広告の内容が、動的に変化することになる。同様に、A2（Ad Break #2）とA3（Ad Break #3）としても複数の広告が用意されており、ユーザの特性に応じた広告が再生されることになる。
【０１２５】
なお、図１０においては、クライアント装置４０又は通信サーバ３０のHTTPサーバ上で、XLinkリゾルバが稼働される例を説明したが、クライアント装置４０においては、スクリプトアプリケーションが、XLinkリゾルバの役割を担うようにすることができる。
【０１２６】
すなわち、DASHクライアントが、MPDメタデータをパース（構文解析）することで、広告挿入用のPeriod要素のxlink:href属性のURLを検出した場合に、直ちにHTTPリクエストを、HTTPサーバ上で稼働するXLinkリゾルバに送信するのではなく、そのURLを、スクリプトアプリケーションに通知するようにする。
【０１２７】
スクリプトアプリケーションは、DASHクライアントからURLが通知されると（XLinkの解決が要求されると）、当該URLのパス部分やクエリ文字列に反映されている広告挿入区間を識別するための情報に基づいて、その区間に対応する広告のコンテンツ（Adセグメント）の挿入候補のうち、対象のユーザに適合する広告のコンテンツ（Adセグメント）を選択する。
【０１２８】
そして、スクリプトアプリケーションは、選択した広告のコンテンツ（Adセグメント）に対応するPeriod要素を含むピリオドファイルを生成し、DASHクライアントに応答する。例えば、このピリオドファイルのPeriod要素は、groupIDにより指定される特定のユーザ（例えば、classAのユーザ）向けに生成されたURLを含み、このセグメントURLのリストに基づいて、Adセグメント群を再生すると、広告のコンテンツが再生されることになる。
【０１２９】
ここで、ユーザに適合した広告のコンテンツの選択であるが、例えば、クライアント装置４０で管理されるユーザプリファレンス等に応じて行われる場合もあれば、ユーザとの間で情報のやりとり（インタラクション）を行って、随時取得される情報に応じて行われるようにしてもよい。例えば、上述した図９の広告挿入の例では、ユーザの入力操作に応じて、当該ユーザに適合した広告のコンテンツが選択されている。
【０１３０】
このように、クライアント装置４０側で、MPDメタデータのPeriod要素のXLinkの解決が行われるようにすることで、通信サーバ３０のHTTPサーバ上で稼働するXLinkリゾルバに、XLinkの解決を依頼する必要がなくなることになる。
【０１３１】
そのため、通信サーバ３０のXLinkリゾルバでXLinkの解決を行うとした場合には、広告挿入区間の直前に、インターネット９０に接続された多数のクライアント装置４０からのアクセスが、通信サーバ３０に集中することが想定されるが、クライアント装置４０のXLinkリゾルバでXLinkの解決を行うことで、XLinkの解決のトランザクション処理の負荷増加の解消を図ることができる。
【０１３２】
また、クライアント装置４０では、スクリプトアプリケーションによって、広告挿入区間よりも時間的に前に、放送経由又は通信経由で取得される広告のコンテンツ（Adセグメント）の候補を、ローカルキャッシュ（の永続キャッシュ）にキャッシュしておくことで、広告挿入制御による広告挿入の確実性を担保することができる。例えば、広告のコンテンツ（Adセグメント）を通信経由で取得する場合には、インターネット９０の通信状況などにより、広告のコンテンツ（Adセグメント）を取得できないことも想定されるが、あらかじめキャッシュしておけば、広告挿入制御による広告挿入の確実性を高めることができる。
【０１３３】
さらに、本技術では、キャッシュクォータドメインの概念を導入し、クライアント装置４０において、複数のサービスで再利用される広告のコンテンツ（Adセグメント）のファイルを共有できるようにしているため、ローカルキャッシュ（の永続キャッシュ）にキャッシュされる広告のコンテンツ（Adセグメント）の候補の再利用性を高めて、より確実に、広告挿入制御による広告挿入を行うことができる。
【０１３４】
（MPDの記述例）
次に、図１３及び図１４を参照して、XML形式のMPDメタデータの記述例について説明する。
【０１３５】
なお、MPDメタデータでは、Period要素、AdaptationSet要素、及び、Representation要素が階層構造で記述されている。Period要素は、コンテンツ等のサービスの構成を記述する単位となる。また、AdaptationSet要素と、Representation要素は、ビデオやオーディオ、字幕等のサービスコンポーネントのストリームごとに利用され、それぞれのストリームの属性を記述できるようになっている。
【０１３６】
図１３のMPDメタデータの記述例では、本編のPeriod要素と、広告（Ad）のPeriod要素が記述されている。
【０１３７】
本編のPeriod要素には、本編のコンテンツ（MP4形式の動画ファイル）の再生を管理するための情報が記述されている。ただし、AssetIdentifier要素のschemeIdUri属性とvalue属性には、EIDR(Entertainment Identifier Registry)に対応したIDが付与されている。
【０１３８】
一方で、広告（Ad）のPeriod要素には、デフォルトの広告のコンテンツ（MP4形式の動画ファイル）の再生を管理するための情報とともに、Period要素のxlink:href属性にURLが記述されている（図中のＡ）。このURLが、通信サーバ３０のHTTPサーバ上で稼働するXLinkリゾルバに通知されることで、挿入用の広告が取得され、デフォルトの広告が、挿入用の広告に差し替えられる。
【０１３９】
図１４のMPDメタデータの記述例においても、本編のPeriod要素と、広告（Ad）のPeriod要素が記述されている。
【０１４０】
本編のPeriod要素には、本編のコンテンツ（MP4形式の動画ファイル）の再生を管理するための情報が記述されている。
【０１４１】
一方で、広告（Ad）のPeriod要素には、デフォルトの広告のコンテンツ（MP4形式の動画ファイル）の再生を管理するための情報とともに、Period要素のxlink:href属性にURLが記述されている（図中のＡ）。ここでは、groupIDの値が挿入されたURLが、クライアント装置４０のHTTPサーバ上で稼働するXLinkリゾルバに通知されることで、groupIDにより指定される特定のユーザに適合した広告が取得され、デフォルトの広告が、ユーザに適合した広告に差し替えられる。なお、図中のＡにおいて、"urn:atsc:ad-insertion"は、広告挿入制御の解決を、ローカル（クライアント装置４０）で実行されるスクリプト（スクリプトアプリケーション）に依頼しなければならないことを示すものであるが、その詳細な内容は後述するものとする。
【０１４２】
なお、上述した説明では、広告のコンテンツを一例に説明し、キャッシュクォータドメインを用いて、複数のサービスで、広告のコンテンツ（Adセグメント）のファイルを共有できるとしたが、本技術は、広告以外の他のコンテンツに適用することもできる。また、ファイルは、コンテンツのリソースの一例であり、クライアント装置４０が処理可能なデータであれば、あらゆるデータを対象とすることができる。
【０１４３】
＜４．シグナリングの例＞
【０１４４】
次に、図１５乃至図２１を参照して、キャッシュクォータドメインを識別するクォータドメイン識別子を伝送するシグナリングのフォーマットの例を説明する。
【０１４５】
（SLTのフォーマット）
図１５は、XML形式のSLTメタデータのフォーマットの例を示す図である。なお、図１５において、要素と属性のうち、属性には「@」が付されている。また、インデントされた要素と属性は、その上位の要素に対して指定されたものとなる。これらの関係は、後述する他のシグナリングのフォーマットでも同様とされる。
【０１４６】
SLT要素は、ルート要素であって、bsid属性、sltCapabilities属性、sltInetUrl要素、及び、Service要素の上位要素となる。
【０１４７】
bsid属性には、ブロードキャストストリームIDが指定される。sltCapabilities属性には、必要とされる機能に関する情報が指定される。
【０１４８】
sltInetUrl要素には、ESGやSLSシグナリングを取得するためのベースURLが指定される。sltInetUrl要素は、urlType属性の上位要素となる。urlType属性には、ベースURLで利用可能なファイルの種類が指定される。
【０１４９】
Service要素には、１又は複数のサービスに関する情報が指定される。Service要素は、serviceId属性、sltSvcSeqNum属性、protected属性、majorChannelNo属性、minorChannelNo属性、serviceCategory属性、shortServiceName属性、hidden属性、broadbandAccessRequired属性、svcCapabilities属性、quotaDomain属性、BroadcastSvcSignaling要素、及び、svcInetUrl要素の上位要素となる。
【０１５０】
serviceId属性には、サービスIDが指定される。sltSvcSeqNum属性には、SLTメタデータのバージョンに関する情報が指定される。protected属性には、サービスの保護を示す暗号化情報が指定される。
【０１５１】
majorChannelNo属性には、メジャーチャネル番号が指定される。minorChannelNo属性には、マイナーチャネル番号が指定される。serviceCategory属性には、サービスのカテゴリが指定される。shortServiceName属性には、ショートサービス名が指定される。
【０１５２】
hidden属性には、サービスが、隠されたサービスであるかどうかが指定される。broadbandAccessRequired属性には、インターネット９０等の通信回線にアクセスする必要があるかどうかが指定される。svcCapabilities属性には、デコードに必要な機能などの情報が指定される。
【０１５３】
quotaDomain属性には、対象のサービスが属しているキャッシュクォータドメインのクォータドメイン識別子が指定される。同一のキャッシュクォータドメインに属するサービスでは、ローカルメモリにキャッシュされるリソース（ファイル）が共有されることになる。
【０１５４】
BroadcastSvcSignaling要素には、SLSシグナリングが放送経由で取得される場合に、当該SLSシグナリングの取得先に関する情報が指定される。BroadcastSvcSignaling要素は、slsProtocol属性、slsMajorProtocolVersion属性、slsMinorProtocolVersion属性、slsPlpId属性、slsDestinationIpAddress属性、slsDestinationUdpPort属性、及び、slsSourceIpAddress属性の上位要素となる。
【０１５５】
slsProtocol属性には、SLSシグナリングのプロトコルに関する情報が指定される。slsMajorProtocolVersion属性には、SLSシグナリングのプロトコルのメジャーバージョン番号が指定される。slsMinorProtocolVersion属性には、SLSシグナリングのプロトコルのマイナーバージョン番号が指定される。
【０１５６】
slsPlpId属性には、SLSシグナリングが伝送されるPLP(Physical Layer Pipe)のIDが指定される。slsDestinationIpAddress属性には、SLSシグナリングの宛先（destination）のIPアドレスが指定される。slsDestinationUdpPort属性には、SLSシグナリングの宛先（destination）のポート番号が指定される。slsSourceIpAddress属性には、SLSシグナリングの送信元（source）のIPアドレスが指定される。
【０１５７】
svcInetUrl要素には、SLSシグナリングが通信経由で取得される場合に、当該SLSシグナリングの取得先のURLが指定される。svcInetUrl要素は、urlType属性の上位要素となる。urlType属性には、このURLで利用可能なファイルの種類が指定される。
【０１５８】
なお、図１５において、出現数（Use）であるが、"1"が指定された場合にはその要素又は属性は必ず１つだけ指定され、"0..1"が指定された場合には、その要素又は属性を指定するかどうかは任意である。また、"1..N"が指定された場合には、その要素又は属性は１以上指定され、"0..N"が指定された場合には、その要素又は属性を１以上指定するかどうかは任意である。
【０１５９】
また、Data Typeとして、"unsignedShort"又は"unsignedByte"が指定された場合、その要素又は属性の値が、整数型であることを示している。Data Typeとして、"string"が指定された場合には、その要素又は属性の値が、文字列型であることを示し、"anyURI"が指定された場合、その要素又は属性の値が、URIの形式をした文字列であることを示している。Data Typeとして、"boolean"が指定された場合には、その要素又は属性がブール型であることを示している。なお、Data Typeとして、"language"が指定された場合、その要素又は属性の値が、xml:lang属性の値として有効なものであることを示し、"dateTime"が指定された場合、その要素又は属性の値が、特定の日時であることを示すものとする。
【０１６０】
（USBDのフォーマット）
図１６は、XML形式のUSBDメタデータのフォーマットの例を示す図である。
【０１６１】
bundleDescription要素は、ルート要素であって、userServiceDescription要素（USD要素）の上位要素となる。このuserServiceDescription要素は、globalServiceID属性、serviceId属性、serviceStatus属性、fullMPDUri属性、sTSIDUri属性、quotaDomain属性、name要素、serviceLanguage要素、capabilityCode要素、deliveryMethod要素の上位要素となる。
【０１６２】
globalServiceID属性には、グローバルサービスIDが指定される。serviceId属性には、サービスIDが指定される。serviceStatus属性には、サービスのステータスに関する情報が指定される。fullMPDUri属性には、MPDメタデータを参照するためのURIが指定される。sTSIDUri属性には、S-TSIDメタデータを参照するためのURIが指定される。
【０１６３】
quotaDomain属性には、対象のサービスが属しているキャッシュクォータドメインのクォータドメイン識別子が指定される。同一のキャッシュクォータドメインに属するサービスでは、ローカルメモリにキャッシュされるリソース（ファイル）が共有されることになる。
【０１６４】
name要素には、ATSC3.0のサービスの名称が指定される。name要素は、lang属性の上位要素となる。lang属性には、ATSC3.0のサービスの名称の言語が指定される。serviceLanguage要素には、ATSC3.0のサービスで利用できる言語が指定される。capabilityCode要素には、機能に関するコードが指定される。
【０１６５】
deliveryMethod要素には、データの配信方法に関する情報が指定される。deliveryMethod要素は、broadcastAppService要素及びunicastAppService要素の上位要素となる。broadcastAppService要素は、basePattern要素の上位要素であって、放送経由での配信に関する情報が指定される。unicastAppService要素は、basePattern要素の上位要素であって、通信経由での配信に関する情報が指定される。
【０１６６】
（S-TSIDのフォーマット）
図１７は、S-TSIDメタデータのフォーマットの例を示す図である。
【０１６７】
S-TSID要素は、ルート要素であって、serviceId属性及びRS要素の上位要素となる。serviceId属性には、サービスIDが指定される。
【０１６８】
RS要素には、ROUTEセッションに関する情報が指定される。RS要素は、bsid属性、sIpAddr属性、dIpAddr属性、dport属性、PLPID属性、及び、LS要素の上位要素となる。
【０１６９】
bsid属性には、ブロードキャストストリームIDが指定される。sIpAddr属性には、送信元（source）のIPアドレスが指定される。dIpAddr属性には、宛先（destination）のIPアドレスが指定される。dport属性には、宛先（destination）のポート番号が指定される。PLPID属性には、ROUTEセッションのPLPのIDが指定される。
【０１７０】
LS要素には、LCTセッションに関する情報が指定される。LS要素は、tsi属性、PLPID属性、bw属性、startTime属性、endTime属性、SrcFlow要素、及び、RprFlow要素の上位要素となる。
【０１７１】
tsi属性には、TSIが指定される。PLPID属性には、PLPのIDが指定される。bw属性には、帯域幅が指定される。startTime属性とendTime属性には、開始日時と終了日時が指定される。SrcFlow要素には、ソースフロー情報が指定される。なお、このSrcFlow要素の詳細な内容は、図１８を参照して後述する。RprFlow要素には、リペアフロー情報が指定される。
【０１７２】
（SrcFlow要素のフォーマット）
図１８は、図１７のS-TSIDメタデータに含まれるSrcFlow要素のフォーマットの例を示す図である。
【０１７３】
SrcFlow要素は、rt属性、minBuffSize属性、EFDT要素、ContentInfo要素、及び、Payload要素の上位要素となる。minBuffSize属性には、クライアント装置４０が必要とする最小バッファサイズが指定される。
【０１７４】
EFDT要素には、拡張されたFDT（Extended FDT）に関する情報が指定される。ContentInfo要素には、コンテンツに関する情報が指定される。ContentInfo要素は、quotaDomain属性の上位要素となる。
【０１７５】
quotaDomain属性には、対象のLCTセッションを含むサービスが属しているキャッシュクォータドメインのクォータドメイン識別子が指定される。同一のキャッシュクォータドメインに属するサービスでは、ローカルメモリにキャッシュされるリソース（ファイル）が共有されることになる。
【０１７６】
Payload要素は、codePoint属性、formatID属性、frag属性、order属性、srcFecPayloadID属性、及び、FECParams属性の上位要素であって、ソースフローのオブジェクトを格納するROUTEパケットのペイロードに関する情報が指定される。
【０１７７】
（ASTのフォーマット）
図１９乃至図２１は、ASTメタデータのフォーマットの例を示す図である。
【０１７８】
ApplicationList要素は、ルート要素であって、Application要素及びApplicationReference要素の上位要素となる。
【０１７９】
Application要素には、アプリケーションに関する情報が指定される。Application要素は、appName要素、applicationIdentifier要素、applicationDescriptor要素、applicationUsageDescriptor要素、applicationBoundary要素、applicationTransport要素、applicationLocation要素、及び、applicationSpecificDescriptor要素の上位要素となる。
【０１８０】
appName要素は、Language属性の上位要素であって、アプリケーションの名称が指定される。applicationIdentifier要素は、orgID要素及びappIDの上位要素であって、アプリケーションのアプリケーションIDが指定される。
【０１８１】
applicationDescriptor要素は、type要素、controlCode要素、visibility要素、serviceBound要素、priority要素、version要素、icon要素、及び、storageCapabilities要素の上位要素であって、対象のアプリケーションのプロパティに関する情報が指定される。
【０１８２】
applicationUsageDescriptor要素は、ApplicationUsage要素の上位要素であって、アプリケーションのUsageタイプに関する情報が指定される。applicationBoundary要素には、アプリケーションのバウンダリに関する情報が指定される。applicationTransport要素には、アプリケーションのトランスポートプロトコルに関する情報が指定される。
【０１８３】
トランスポートタイプが、HTTPの場合には、URLBase要素及びURLExtension要素が配置され、URLが指定される。URLExtension要素には、拡張URLが指定される。また、トランスポートタイプが、ROUTEの場合には、atsc:ROUTESessionInfo要素（LCTSession要素、tsi属性、plpID属性を含む）、broadcastStreamId属性、plpID属性、sourceIpAddress属性、destinationIpAddress属性、及び、destinationPort属性が配置され、ROUTEセッションに関する情報が指定される。
【０１８４】
applicationLocation要素には、アプリケーションのロケーション情報が指定される。applicationSpecificDescriptor要素には、アプリケーションの記述子が配置される。この記述子としては、DVB(Digital Video Broadcasting)に対応したdvbDescriptor、HTML(HyperText Markup Language)に対応したhtmlDescriptor、ATSCに対応したatscDescriptor、又は、その他の規格に対応したotherDescriptorが選択的に配置される。
【０１８５】
atsc:atscDescriptor要素は、quotaDomain属性、size要素、requiredCapabilities要素、icon要素、ApplicationRecordingDescriptor要素、timeSlotInfo要素、contentLinkage要素、contentItem要素、及び、graphicConstraintsDescriptorの上位要素であって、ATSC（ATSC3.0）に関する情報が指定される。
【０１８６】
quotaDomain属性は、対象のアプリケーションを含むサービスが属しているキャッシュクォータドメインのクォータドメイン識別子が指定される。同一のキャッシュクォータドメインに属するサービスでは、ローカルメモリにキャッシュされるリソース（ファイル）が共有されることになる。
【０１８７】
ただし、icon要素は、filename属性、size属性、及び、aspectRatio属性を含む。また、ApplicationRecordingDescriptor要素は、scheduled_recording_flag要素、trick_mode_aware_flag要素、time_shift_flag要素、dynamic_flag要素、av_synced_flag要素、initiating_replay_flag要素、及び、storage_properties要素を含む。さらに、timeSlotInfo要素は、timeslot_type要素、timeslot_start要素、timeslot_length要素、acquisition_time要素、及び、repeat_period要素を含む。
【０１８８】
また、contentItem要素は、location属性、contentLinkage属性、updatesAvailable属性、size属性、及び、timeSlotInfo要素を含む。このtimeSlotInfo要素は、timeslot_type要素、timeslot_start要素、timeslot_length要素、acquisition_time要素、及び、repeat_period要素を含む。graphicConstraintsDescriptor要素は、can_run_without_visible_ui要素、handles_configuration_changed要素、handles_externally_controlled_video要素、graphics_configuration_byte要素、及び、screenPosition要素を含む。
【０１８９】
なお、図１５乃至図２１を参照して説明したSLTメタデータ、USBDメタデータ、S-TSID、及び、ASTメタデータのフォーマットは一例であって、例えば、他の要素や属性を追加するなど、その一部を変更したフォーマットが採用されるようにしてもよい。また、SLTメタデータ、USBDメタデータ、S-TSID、及び、ASTメタデータは、XML形式に限らず、他のマークアップ言語により記述してもよいし、あるいはセクション形式であってもよい。
【０１９０】
また、SLTメタデータ、USBDメタデータ、S-TSID、及び、ASTメタデータ等のシグナリングを拡張することで追加されるquotaDomain属性により指定されるクォータドメイン識別子は、１種類のメタデータに含めるようにしてもよいし、複数種類のメタデータに含めるようにしてもよい。また、複数のサービスが提供される場合に、サービスごとに異なる種類のメタデータに、quotaDomain属性により指定されるクォータドメイン識別子が記述されるようにしてもよい。さらに、上述した各メタデータのフォーマットの例では、クォータドメイン識別子が、quotaDomain属性により指定される場合を一例に説明したが、クォータドメイン識別子は、属性に限らず、例えば、要素や、テキストとして記述された情報などにより指定されるようにしてもよい。
【０１９１】
＜５．各装置の構成＞
【０１９２】
次に、図２２乃至図２５を参照して、図１の伝送システム１における、送信側のAd/DASHサーバ１０、放送サーバ２０、及び、通信サーバ３０と、受信側のクライアント装置４０の構成について説明する。
【０１９３】
（Ad/DASHサーバの構成）
図２２は、図１のAd/DASHサーバ１０の構成例を示す図である。
【０１９４】
図２２において、Ad/DASHサーバ１０は、受信部１０１、Ad/DASHセグメント生成部１０２、スクリプトアプリケーション生成部１０３、MPD生成部１０４、処理部１０５、及び、送信部１０６から構成される。
【０１９５】
受信部１０１は、外部のサーバ（不図示）などからストリーミング配信用のデータを受信し、Ad/DASHセグメント生成部１０２、スクリプトアプリケーション生成部１０３、及び、MPD生成部１０４に供給する。
【０１９６】
Ad/DASHセグメント生成部１０２は、受信部１０１から供給されるデータに基づいて、Adセグメント及びDASHセグメントを生成し、処理部１０５に供給する。
【０１９７】
ここで、Adセグメントは、広告のコンテンツを処理して得られるセグメントファイルである。また、DASHセグメントは、中継場所から伝送路や通信回線を介して送られてくるライブコンテンツ（例えば、スポーツ中継等の生放送番組）や、ストレージに蓄積された収録済みのコンテンツ（例えば、ドラマ等の事前収録番組）などのコンテンツを処理して得られるセグメントファイルである。なお、Adセグメントは、DASHセグメントの一種であるとも言えるが、ここでは、説明の都合上、AdセグメントとDASHセグメントとを区別して説明する。
【０１９８】
スクリプトアプリケーション生成部１０３は、受信部１０１から供給されるデータに基づいて、スクリプトアプリケーションを生成し、処理部１０５に供給する。ここで、スクリプトアプリケーションは、スクリプト（Script）を実行可能なアプリケーションである。このスクリプトアプリケーションは、例えば、HTML5等のマークアップ言語や、JavaScript（登録商標）等のスクリプト言語で開発されたアプリケーションとすることができる。
【０１９９】
MPD生成部１０４は、受信部１０１から供給されるデータに基づいて、MPDメタデータを生成し、処理部１０５に供給する。ここで、MPDメタデータには、番組や広告等のコンテンツに対応したPeriod要素が記述されるが、その詳細な内容は後述する。
【０２００】
処理部１０５は、Ad/DASHセグメント生成部１０２から供給されるAdセグメント及びDASHセグメントと、スクリプトアプリケーション生成部１０３から供給されるスクリプトアプリケーションと、MPD生成部１０４から供給されるMPDメタデータに対して、必要な処理を施し、送信部１０６に供給する。
【０２０１】
送信部１０６は、処理部１０５から供給されるデータを、放送サーバ２０又は通信サーバ３０に送信する。なお、ここでは、Adセグメント及びDASHセグメント、スクリプトアプリケーション、並びに、MPDメタデータのデータ（ファイル）のうち、放送経由で配信されるデータが放送サーバ２０に送信され、通信経由で配信されるデータが通信サーバ３０に送信される。
【０２０２】
Ad/DASHサーバ１０は、以上のように構成される。
【０２０３】
（放送サーバの構成）
図２３は、図１の放送サーバ２０の構成例を示す図である。
【０２０４】
図２３において、放送サーバ２０は、受信部２０１、シグナリング生成部２０２、処理部２０３、及び、送信部２０４から構成される。
【０２０５】
受信部２０１は、Ad/DASHサーバ１０から送信されてくる、Adセグメント及びDASHセグメント、スクリプトアプリケーション、並びに、MPDメタデータを受信し、処理部２０３に供給する。ただし、ここでは、Adセグメント及びDASHセグメント、スクリプトアプリケーション、及び、MPDメタデータのすべてが、Ad/DASHサーバ１０から提供されるとは限らず、放送経由で配信されるデータ（ファイル）のみが提供され、受信部２０１により受信される。
【０２０６】
また、受信部２０１は、外部のサーバ（不図示）などからNRTコンテンツのデータ（ファイル）を受信し、処理部２０３に供給する。
【０２０７】
シグナリング生成部２０２は、シグナリングを生成し、処理部２０３に供給する。ここで、シグナリングには、SLTメタデータ等のLLSシグナリングと、USBDメタデータ、S-TSIDメタデータ、及び、ASTメタデータ等のSLSシグナリングが含まれる。また、複数のサービスで、リソース（ファイル）を共有させる場合には、SLTメタデータ、USBDメタデータ、S-TSIDメタデータ、又はASTメタデータに定義されたquotaDomain属性に、対象のキャッシュクォータドメインのクォータドメイン識別子が指定されることになる。
【０２０８】
処理部２０３は、受信部２０１から供給されるAdセグメント及びDASHセグメント、スクリプトアプリケーション、MPDメタデータ、並びにNRTコンテンツと、シグナリング生成部２０２から供給されるシグナリングに対して、必要な処理を施し、送信部２０４に供給する。ここでは、例えば、Adセグメント及びDASHセグメント、スクリプトアプリケーション、NRTコンテンツ、並びに、SLSシグナリング（USBDメタデータやMPDメタデータ等）を含むLCTセッションのデータをペイロードに格納したIP/UDPパケットと、LLSシグナリング（SLTメタデータ等）のデータをペイロードに格納したIP/UDPパケットを生成するための処理などが行われる。
【０２０９】
送信部２０４は、処理部２０３から供給されるデータに対応する放送波（デジタル放送信号）を、アンテナ２１１によって、伝送路８０を介して送信（一斉同報配信）する。
【０２１０】
放送サーバ２０は、以上のように構成される。
【０２１１】
（通信サーバの構成）
図２４は、図１の通信サーバ３０の構成例を示す図である。
【０２１２】
図２４において、通信サーバ３０は、受信部３０１、ピリオドファイル生成部３０２、処理部３０３、及び、通信部３０４から構成される。
【０２１３】
受信部３０１は、Ad/DASHサーバ１０から送信されてくる、Adセグメント及びDASHセグメント、スクリプトアプリケーション、並びに、MPDメタデータを受信し、処理部３０３に供給する。ただし、ここでは、Adセグメント及びDASHセグメント、スクリプトアプリケーション、及び、MPDメタデータのすべてが、Ad/DASHサーバ１０から提供されるとは限らず、通信経由で配信されるデータ（ファイル）のみが提供され、受信部３０１により受信される。
【０２１４】
処理部３０３は、通信部３０４により受信されたクライアント装置４０からの要求（XLinkの解決要求）に応じて、受信部３０１から供給されるデータを処理し、通信部３０４に供給する。通信部３０４は、クライアント装置４０からの要求に応じて、処理部３０３から供給されるデータ（Adセグメント及びDASHセグメント、スクリプトアプリケーション、並びに、MPDメタデータのうちの少なくとも１つのデータ）を、インターネット９０を介して、当該データの要求元のクライアント装置４０宛てに送信する。
【０２１５】
処理部３０３は、通信部３０４により受信されたクライアント装置４０からの要求に応じて、ピリオドファイルの生成を、ピリオドファイル生成部３０２に要求する。ピリオドファイル生成部３０２は、処理部３０３からの要求に応じて、クライアント装置４０を使用しているユーザ（の特性）に応じたPeriod要素を含むピリオドファイルを生成し、処理部３０３に供給する。
【０２１６】
処理部３０３は、ピリオドファイル生成部３０２から供給されるピリオドファイルを処理し、通信部３０４に供給する。通信部３０４は、処理部３０３から供給されるピリオドファイルを、インターネット９０を介して、XLinkの解決要求の要求元のクライアント装置４０宛てに送信する。
【０２１７】
通信サーバ３０は、以上のように構成される。
【０２１８】
（クライアント装置の構成）
図２５は、図１のクライアント装置４０の構成例を示す図である。
【０２１９】
図２５において、クライアント装置４０は、制御部４０１、受信部４０２、放送ミドルウェア４０３、ローカルキャッシュ４０４、ブラウザ４０５、出力部４０６、及び、通信部４０７から構成される。
【０２２０】
制御部４０１は、クライアント装置４０の各部の動作を制御する。
【０２２１】
受信部４０２は、アンテナ４１１によって、放送サーバ２０から伝送路８０を介して送信（一斉同報配信）されてくる放送波（デジタル放送信号）を受信して処理し、それにより得られるデータを、放送ミドルウェア４０３に供給する。なお、受信部４０２は、チューナなどから構成される。
【０２２２】
放送ミドルウェア４０３は、受信部４０２から供給されるデータを処理し、制御部４０１又はローカルキャッシュ４０４に供給する。ここで、処理対象のデータのうち、Adセグメント及びDASHセグメント、スクリプトアプリケーション、並びにMPDメタデータは、ローカルキャッシュ４０４に供給される。また、シグナリングは、制御部４０１に供給される。
【０２２３】
制御部４０１は、キャッシュ制御部４０１Ａ及び再生制御部４０１Ｂを含む。キャッシュ制御部４０１Ａは、放送ミドルウェア４０３から供給されるシグナリングや、ブラウザ４０５からの要求などに基づいて、ローカルキャッシュ４０４を制御する。また、再生制御部４０１Ｂは、放送ミドルウェア４０３から供給されるシグナリングなどに基づいて、ブラウザ４０５を制御する。
【０２２４】
ローカルキャッシュ４０４は、例えば、オンメモリ（On Memory）やSSD(Solid State Drive)などのローカルなファイルシステム上で実現される。
【０２２５】
ローカルキャッシュ４０４は、キャッシュ制御部４０１Ａからの制御に従い、放送ミドルウェア４０３から供給されるデータ（ファイル）をキャッシュする。このローカルキャッシュ４０４には、Adセグメント及びDASHセグメント、スクリプトアプリケーション、並びにMPDメタデータなどのデータがキャッシュされる。また、ローカルキャッシュ４０４は、通常キャッシュ４０４Ａ及び永続キャッシュ４０４Ｂを含む。
【０２２６】
ここで、通常キャッシュ４０４Ａは、通常のキャッシュであって、そこにキャッシュされたデータは、しかるべき時間（それほど長くない時間）を経過した後に消去される。一方で、永続キャッシュ４０４Ｂは、特別なキャッシュであって、そこにキャッシュされるデータは、優先的な永続性を持ち、通常キャッシュ４０４Ａにキャッシュされるデータよりも長い時間キャッシュされることになる。
【０２２７】
キャッシュ制御部４０１Ａは、放送ミドルウェア４０３からのシグナリング（に含まれるSLTメタデータ、USBDメタデータ、S-TSIDメタデータ、又はASTメタデータに定義されたquotaDomain属性）に、（キャッシュクォータドメインの）クォータドメイン識別子が指定されている場合であって、ブラウザ４０５（のスクリプト実行部４０５Ａ）から、対象のAdセグメントやDASHセグメント等の永続キャッシュ４０４Ｂへの引き込み要求があったとき、対象のAdセグメントやDASHセグメント等（のファイル）を、通常キャッシュ４０４Ａから永続キャッシュ４０４Ｂに引き込む。
【０２２８】
これにより、永続キャッシュ４０４ＢにキャッシュされるAdセグメントやDASHセグメント等のファイル群は、クォータドメイン識別子により紐付けられているので、同一のキャッシュクォータドメインに属する複数のサービスにおいて、AdセグメントやDASHセグメント等のファイルを共有することが可能となる。
【０２２９】
ブラウザ４０５は、HTML5やJavaScript（登録商標）等に対応したブラウザである。ブラウザ４０５は、再生制御部４０１Ｂからの制御に従い、ローカルキャッシュ４０４から読み出したデータ（ファイル）を処理する。ブラウザ４０５は、スクリプト実行部４０５Ａ及びDASHクライアント４０５Ｂを含む。
【０２３０】
スクリプト実行部４０５Ａは、JavaScript（登録商標）等のスクリプト言語で記述されたスクリプトを実行することができる。例えば、スクリプト実行部４０５Ａは、ローカルキャッシュ４０４（の通常キャッシュ４０４Ａ又は永続キャッシュ４０４Ｂ）からスクリプトアプリケーションを読み出して、実行することができる。
【０２３１】
また、スクリプト実行部４０５Ａは、スクリプトアプリケーションに記述されたCacheStorage API(Application Programming Interface)を実行することで、キャッシュ制御部４０１Ａによるローカルキャッシュ４０４の制御を実行させる。なお、CacheStorage APIの詳細な内容については後述する。さらに、スクリプト実行部４０５Ａは、DASHクライアント４０５ＢからのXLinkの解決要求に応じて、ユーザプリファレンス等に応じたピリオドファイルを生成し、DASHクライアント４０５Ｂに応答する。
【０２３２】
DASHクライアント４０５Ｂは、ローカルキャッシュ４０４（の通常キャッシュ４０４Ａ）からMPDメタデータ（のファイル）を読み出してパース（構文解析）する。DASHクライアント４０５Ｂは、MPDメタデータの解析結果に従い、ローカルキャッシュ４０４（の通常キャッシュ４０４Ａ又は永続キャッシュ４０４Ｂ）から、Adセグメント又はDASHセグメント（のファイル）を読み出して再生する。
【０２３３】
DASHクライアント４０５Ｂにより再生されたAdセグメント又はDASHセグメントのデータは、出力部４０６に供給される。出力部４０６は、再生制御部４０１Ｂからの制御に従い、DASHクライアント４０５Ｂから供給されるデータを出力する。これにより、放送番組や広告等のコンテンツが再生され、その映像や音声が出力されることになる。
【０２３４】
通信部４０７は、制御部４０１からの制御に従い、インターネット９０を介して、通信サーバ３０とデータのやりとりを行う。通信部４０７により受信されるデータのうち、Adセグメント及びDASHセグメント、スクリプトアプリケーション、並びにMPDメタデータは、ローカルキャッシュ４０４に供給される。また、シグナリングは、制御部４０１に供給される。これらの通信経由で取得されたデータに対する処理は、上述した放送経由で取得されたデータと同様であるため、その説明は省略する。
【０２３５】
クライアント装置４０は、以上のように構成される。
【０２３６】
＜６．各装置で実行される処理の流れ＞
【０２３７】
次に、図２６乃至図２８のフローチャートを参照して、図１の伝送システム１の各装置で実行される処理の流れについて説明する。
【０２３８】
（送信側の処理の流れ）
まず、図２６のフローチャートを参照して、送信側のAd/DASHサーバ１０、放送サーバ２０、及び、通信サーバ３０により実行される処理の流れを説明する。
【０２３９】
なお、図２６において、ステップＳ１０１乃至Ｓ１０６の処理は、Ad/DASHサーバ１０により実行され、ステップＳ２０１乃至Ｓ２０５の処理は、放送サーバ２０により実行され、ステップＳ３０１乃至Ｓ３０２の処理は、通信サーバ３０により実行される。
【０２４０】
ステップＳ１０１において、Ad/DASHサーバ１０のAd/DASHセグメント生成部１０２は、Adセグメント及びDASHセグメントを生成する。また、ステップＳ１０２において、Ad/DASHサーバ１０の送信部１０６は、ステップＳ１０１の処理で生成されたAdセグメント及びDASHセグメントを、放送サーバ２０に送信する。
【０２４１】
ここで、Adセグメントは、広告のコンテンツを処理して得られるセグメントファイルである。また、DASHセグメントは、放送番組のコンテンツを処理して得られるセグメントファイルである。ここでは、説明の都合上、AdセグメントとDASHセグメントが同時に生成される場合を説明するが、これらのセグメントは、異なるタイミングで生成されるようにしてもよい。
【０２４２】
ステップＳ２０１において、放送サーバ２０のシグナリング生成部２０２は、シグナリングを生成する。ステップＳ２０２において、放送サーバ２０の送信部２０４は、ステップＳ２０１の処理で生成されたシグナリングを、伝送路８０を介して送信（一斉同報配信）する。
【０２４３】
ここで、シグナリングとしては、SLTメタデータ等のLLSシグナリングと、USBDメタデータ等のSLSシグナリングが生成される。また、複数のサービスで、リソース（ファイル）を共有させる場合には、SLTメタデータ、USBDメタデータ、S-TSIDメタデータ、又はASTメタデータに定義されたquotaDomain属性に、対象のキャッシュクォータドメインのクォータドメイン識別子が指定されることになる。
【０２４４】
また、放送サーバ２０においては、ステップＳ２０２の処理で送信されたAdセグメント及びDASHセグメントが、受信部２０１により受信される。そして、ステップＳ２０３において、放送サーバ２０の送信部２０４は、Ad/DASHサーバ１０により生成されたAdセグメント及びDASHセグメントを、伝送路８０を介して送信（一斉同報配信）する。
【０２４５】
ステップＳ１０３において、Ad/DASHサーバ１０のスクリプトアプリケーション生成部１０３は、スクリプトアプリケーションを生成する。ステップＳ１０４において、Ad/DASHサーバ１０の送信部１０６は、ステップＳ１０３の処理で生成されたスクリプトアプリケーションを、放送サーバ２０に送信する。
【０２４６】
放送サーバ２０においては、ステップＳ１０４の処理で送信されたスクリプトアプリケーションが、受信部２０１により受信される。そして、ステップＳ２０４において、放送サーバ２０の送信部２０４は、Ad/DASHサーバ１０により生成されたスクリプトアプリケーションを、伝送路８０を介して送信（一斉同報配信）する。
【０２４７】
ステップＳ１０５において、Ad/DASHサーバ１０のMPD生成部１０４は、MPDメタデータを生成する。ステップＳ１０６において、Ad/DASHサーバ１０の送信部１０６は、ステップＳ１０５の処理で生成されたMPDメタデータを、放送サーバ２０に送信する。
【０２４８】
ここで、MPDメタデータにおいては、放送番組と広告のPeriod要素が記述されるが、例えば、広告のPeriod要素には、xlink:href属性として、"urn:atsc:ad-insertion:abc:1234"であるURLが記述されるようにする。ただし、このURLにおいて、"urn:atsc:ad-insertion"は、広告挿入制御の解決を、ローカル（クライアント装置４０）で実行されるスクリプト（スクリプトアプリケーション）に依頼しなければならないことを示すものとする。
【０２４９】
すなわち、MPEG-DASHの規定では、通常の"http:"から開始される文字列からなるURLを、MPDメタデータのPeriod要素のxlink:href属性に記述することで、クライアント装置４０は、この"http:・・・"で指定される、インターネット９０上の通信サーバ３０に問い合わせることになる。そして、クライアント装置４０は、通信サーバ３０からの応答として、ピリオドファイルを受信し、当該ピリオドファイルに含まれるPeriod要素の内容に基づいて、広告のコンテンツ（Adセグメント）を再生することになる。
【０２５０】
その一方で、この例では、"http:"から開始される文字列からなるURLではなく、"urn:atsc:ad-insertion"から開始される文字列からなるURN(Uniform Resource Name)を、MPDメタデータのPeriod要素のxlink:href属性に記述するようにする。これにより、クライアント装置４０では、MPDメタデータをパース（構文解析）した際に、"urn:atsc:ad-insertion"で開始される文字列が指定されたxlink:href属性を有するPeriod要素が検出された場合には、HTTPリクエストを発行するのではなく、同時に実行されているスクリプトアプリケーションに対して、XLinkの解決（Period要素の解決）を促すイベントを発行することになる。
【０２５１】
なお、この例では、MPDメタデータにおいて、Period要素のxlink:href属性に、"urn:atsc:ad-insertion"から開始される文字列からなるURNが指定される場合を主に説明するが、上述したように、"http://adservice.com/adp-1?user=$groupID$"などのURLを指定し、groupIDにより特定のユーザが指定されるようにしてもよい。
【０２５２】
放送サーバ２０においては、ステップＳ１０６の処理で送信されたMPDメタデータが、受信部２０１により受信される。そして、ステップＳ２０５において、放送サーバ２０の送信部２０４は、Ad/DASHサーバ１０により生成されたMPDメタデータを、伝送路８０を介して送信（一斉同報配信）する。
【０２５３】
なお、説明の都合上、ステップＳ２０２乃至Ｓ２０５においては、シグナリング、Adセグメント及びDASHセグメント、スクリプトアプリケーション、及び、MPDメタデータが、異なるタイミングで送信されるものとして説明したが、これらのデータは、放送ストリームに含められ、送信されることになる。
【０２５４】
通信サーバ３０においては、インターネット９０を介して、クライアント装置４０から送信されてくる、XLinkの解決要求が通信部３０４により受信される。そして、ステップＳ３０１において、通信サーバ３０のピリオドファイル生成部３０２は、ピリオドファイルを生成する。ステップＳ３０２において、通信サーバ３０の通信部３０４は、ステップＳ３０１の処理で生成されたピリオドファイルを、インターネット９０を介して、XLinkの解決要求の送信元のクライアント装置４０宛てに送信する。
【０２５５】
なお、このように、クライアント装置４０から通信サーバ３０に対して、XLinkの解決要求が送信されるのは、"http:"から開始される文字列からなるURLが、MPDメタデータのPeriod要素のxlink:href属性に記述された場合である。
【０２５６】
以上、送信側の処理の流れについて説明した。
【０２５７】
（受信側の処理の流れ）
次に、図２７及び図２８のフローチャートを参照して、受信側のクライアント装置４０により実行される処理の流れを説明する。
【０２５８】
なお、図２７及び図２８において、ステップＳ４０１乃至Ｓ４０８の処理は、放送ミドルウェア４０３により実行され、ステップＳ４２１乃至Ｓ４２３の処理、及び、ステップＳ４４１乃至Ｓ４４３の処理は、ローカルキャッシュ４０４（通常キャッシュ４０４Ａ，永続キャッシュ４０４Ｂ）を制御するキャッシュ制御部４０１Ａにより実行される。また、ステップＳ４６１乃至Ｓ４６６の処理は、ブラウザ４０５のスクリプト実行部４０５Ａにより実行され、ステップＳ４８１乃至Ｓ４９０の処理は、ブラウザ４０５のDASHクライアント４０５Ｂにより実行される。
【０２５９】
ステップＳ４０１において、放送ミドルウェア４０３は、受信部４０２を介して、放送サーバ２０から伝送路８０を介して送信されてくるシグナリングを受信する。ステップＳ４０２において、放送ミドルウェア４０３は、ステップＳ４０１の処理で受信されたシグナリングを処理する。
【０２６０】
ここで、シグナリングとしては、SLTメタデータ等のLLSシグナリングと、USBDメタデータ等のSLSシグナリングが処理される。また、複数のサービスで、リソース（ファイル）を共有させる場合には、SLTメタデータ、USBDメタデータ、S-TSIDメタデータ、又はASTメタデータに定義されたquotaDomain属性に、対象のキャッシュクォータドメインのクォータドメイン識別子が指定されているので、このキャッシュクォータドメインに属するサービスが認識されることになる。
【０２６１】
ステップＳ４０３において、放送ミドルウェア４０３は、受信部４０２を介して、放送サーバ２０から伝送路８０を介して送信されてくるAdセグメント及びDASHセグメントを受信する。ステップＳ４０４において、放送ミドルウェア４０３は、ステップＳ４０３の処理で受信されたAdセグメント及びDASHセグメントを、ローカルキャッシュ４０４に転送する。
【０２６２】
ステップＳ４２１において、キャッシュ制御部４０１Ａは、ステップＳ４０４の処理で転送されてくるAdセグメント及びDASHセグメント（のファイル）を、ローカルキャッシュ４０４の通常キャッシュ４０４Ａにキャッシュする。
【０２６３】
この場合、Adセグメント及びDASHセグメント（のファイル）は、通常キャッシュ４０４Ａにキャッシュされているので、このままの状態が継続されると、しかるべき時間（それほど長くない時間）の経過後、消去されることになる。また、ここでは、説明の都合上、AdセグメントとDASHセグメント（のファイル）が同時にキャッシュされる場合を説明しているが、これらのセグメント（のファイル）は、異なるタイミングでキャッシュされるようにしてもよい。
【０２６４】
ステップＳ４０５において、放送ミドルウェア４０３は、受信部４０２を介して、放送サーバ２０から伝送路８０を介して送信されてくるスクリプトアプリケーションを受信する。ステップＳ４０６において、放送ミドルウェア４０３は、ステップＳ４０５の処理で受信されたスクリプトアプリケーションを、ローカルキャッシュ４０４に転送する。
【０２６５】
ステップＳ４２２において、キャッシュ制御部４０１Ａは、ステップＳ４０６の処理で転送されてくるスクリプトアプリケーションを、ローカルキャッシュ４０４の通常キャッシュ４０４Ａにキャッシュする。この場合、スクリプトアプリケーションは、通常キャッシュ４０４Ａにキャッシュされているので、このままの状態が継続されると、しかるべき時間（それほど長くない時間）の経過後、消去されることになる。
【０２６６】
ステップＳ４６１において、スクリプト実行部４０５Ａは、ステップＳ４２２の処理で通常キャッシュ４０４Ａにキャッシュされたスクリプトアプリケーションを、ローカルキャッシュ４０４から取得し、当該スクリプトアプリケーションを実行する。
【０２６７】
ステップＳ４６２において、スクリプト実行部４０５Ａは、スクリプトアプリケーションの実行（ステップＳ４６１の処理）に応じて、キャッシュ制御部４０１Ａに対して、Adセグメントの永続キャッシュ４０４Ｂへの引き込みを要求する。
【０２６８】
ここで、Adセグメントの永続キャッシュ４０４Ｂへの引き込み指示は、例えば、スクリプトアプリケーションに記述される、下記のCacheStorage APIを実行することで行われる。
【０２６９】
Interface Cache {
Promise<void> fetchPeriod(xmlElement);
}
【０２７０】
ただし、上記のAPIにおいて、fetchPeriodメソッドは、永続キャッシュ４０４Ｂへの引き込み指示に用いられる。また、fetchPeriodメソッドの引数であるxmlElementで指定されるPeriod要素の中に記述されるセグメントURLで指定されるセグメントファイル（Adセグメントのファイル）が、永続キャッシュ４０４Ｂに格納される対象のファイルとなる。
【０２７１】
また、スクリプトアプリケーションには、下記のCacheStorage APIが記述されるようにしてもよい。
【０２７２】
Interface Cache {
Promise<void> fetchFile(url);
}
【０２７３】
ただし、上記のAPIにおいて、fetchFileメソッドは、永続キャッシュ４０４Ｂへの引き込み指示に用いられる。また、fetchFileメソッドの引数であるurlで指定されるセグメントファイル（Adセグメントのファイル）が、永続キャッシュ４０４Ｂに格納される対象のファイルとなる。
【０２７４】
ステップＳ４４１において、キャッシュ制御部４０１Ａは、ステップＳ４６２の処理の引き込み要求に応じて、挿入候補のAdセグメント（のファイル）を、ローカルキャッシュ４０４の通常キャッシュ４０４Ａから、永続キャッシュ４０４Ｂに引き込む。これにより、ローカルキャッシュ４０４の永続キャッシュ４０４Ｂには、通常キャッシュ４０４Ａから引き込まれたAdセグメント（のファイル）がキャッシュされる（Ｓ４４２）。
【０２７５】
すなわち、伝送路８０を介して放送経由で配信されるファイル群は、通常、放送ミドルウェア４０３によって、ROUTEプロトコルが終端された後に、ローカルキャッシュ４０４の通常キャッシュ４０４Ａ（HTTPプロキシキャッシュ（ファイルシステム））に展開されて、しかるべき時間（それほど長くない時間）が経過後、消去される。ここでは、例えば、ROUTEのエンティティモードのファイル転送の際に付加されるHTTPヘッダに記述されるキャッシュ有効期限などにより定められる時間が経過後、ファイルが消去される。
【０２７６】
一方で、ローカルキャッシュ４０４の永続キャッシュ４０４Ｂは、HTTPプロキシキャッシュのうち、特別な領域として扱われるものである。すなわち、この永続キャッシュ４０４Ｂに展開されるファイル群は、通常キャッシュ４０４Ａにキャッシュされる他のファイル群よりも、優先的な永続性を持ち、さらに、上記の「しかるべき時間」が経過しても消去されず、ローカルキャッシュ４０４にあらかじめ割り当てられたクォータ（quota：割り当て量）に達するまで、ファイルがキャッシュされることになる。
【０２７７】
そして、永続キャッシュ４０４Ｂにキャッシュされるファイル群が属するサービスは、SLTメタデータ、USBDメタデータ、S-TSIDメタデータ、又はASTメタデータに定義されたquotaDomain属性に指定されたクォータドメイン識別子により紐付けられているので、同一のキャッシュクォータドメインに属する複数のサービスにおいて、特定のファイル（この例では、Adセグメントのファイル）を共有することが可能となる。
【０２７８】
ステップＳ４０７において、放送ミドルウェア４０３は、受信部４０２を介して、放送サーバ２０から伝送路８０を介して送信されてくるMPDメタデータを受信する。ステップＳ４０８において、放送ミドルウェア４０３は、ステップＳ４０７の処理で受信されたMPDメタデータを、ローカルキャッシュ４０４に転送する。
【０２７９】
ステップＳ４２３において、キャッシュ制御部４０１Ａは、ステップＳ４０８の処理で転送されてくるMPDメタデータを、ローカルキャッシュ４０４の通常キャッシュ４０４Ａにキャッシュする。この場合、MPDメタデータは、通常キャッシュ４０４Ａにキャッシュされているので、しかるべき時間（それほど長くない時間）の経過後、消去されることになる。
【０２８０】
ステップＳ４８１において、DASHクライアント４０５Ｂは、ステップＳ４２３の処理で通常キャッシュ４０４ＡにキャッシュされたMPDメタデータを、ローカルキャッシュ４０４から取得し、当該MPDメタデータをパース（構文解析）する。
【０２８１】
ステップＳ４８２において、DASHクライアント４０５Ｂは、ステップＳ４０２やＳ４８１の処理結果（SLT，USBD，S-TSID，MPD等のメタデータの処理結果）に応じて取得され、通常キャッシュ４０４ＡにキャッシュされたDASHセグメントを、ローカルキャッシュ４０４から取得する。ステップＳ４８３において、DASHクライアント４０５Ｂは、再生制御部４０１Ｂからの制御に従い、ステップＳ４８２の処理で取得されたDASHセグメントを再生する。これにより、クライアント装置４０では、放送番組のコンテンツが再生されることになる。
【０２８２】
ステップＳ４８４において、DASHクライアント４０５Ｂは、広告を挿入するかどうかを判定する。ステップＳ４８４において、広告を挿入しないと判定された場合、処理は、ステップＳ４８２に戻り、ステップＳ４８２乃至Ｓ４８４の処理が繰り返される。この場合、放送番組のコンテンツの再生が継続されることになる。一方で、ステップＳ４８４において、広告を挿入すると判定された場合、処理は、ステップＳ４８５に進められる。
【０２８３】
ステップＳ４８５において、DASHクライアント４０５Ｂは、ステップＳ４８１の処理結果に応じて、MPDメタデータに含まれるXLinkの解決を、スクリプト実行部４０５Ａに要求する。
【０２８４】
ただし、ここでは、ステップＳ４８１の処理によって、MPDメタデータのPeriod要素のxlink:href属性に指定されるURLから、"urn:atsc:ad-insertion"から開始される文字列からなるURNが検出された場合に、スクリプト実行部４０５Ａにより同時に実行されているスクリプトアプリケーションに対して、XLinkの解決（Period要素の解決）を促すイベントを発行することになる。
【０２８５】
ステップＳ４６３において、スクリプト実行部４０５Ａは、ステップＳ４８５の処理のXLink解決要求に応じて、実行中のスクリプトアプリケーションのスクリプト内のロジックにより、ユーザプリファレンスを取得する。そして、ステップＳ４６４において、スクリプト実行部４０５Ａは、ステップＳ４６３の処理で取得されたユーザプリファレンスに基づいて、ピリオドファイルを生成する。
【０２８６】
ここで、スクリプト実行部４０５Ａは、DASHクライアント４０５Ｂからのイベントにより通知されるURL（例えば、"urn:atsc:ad-insertion:abc:1234"であるURL）に基づいて、MPDメタデータに挿入されるべきPeriod要素を含むピリオドファイルを生成する。なお、ユーザプリファレンスとしては、例えば、PDI(Preference Demographic and Interest)を利用するようにしてもよい。このPDIは、特定のサーバから提供される質問に対するユーザの回答を示す情報を生成することで、ユーザの嗜好にマッチしたコンテンツのみが再生(蓄積)されるようにする仕組みである。
【０２８７】
ステップＳ４６５において、スクリプト実行部４０５Ａは、ステップＳ４６４の処理で生成されたピリオドファイルを、DASHクライアント４０５Ｂに応答する。
【０２８８】
なお、MPDメタデータのPeriod要素のxlink:href属性に、"http:"から開始される文字列からなるURL（例えば、"http://adservice.com/adp-1?user=$groupID$"などのURL）が記述されている場合には、図中の点線（「５」の点線）で示すように、XLinkの解決要求が、インターネット９０を介して通信サーバ３０に送信される。そして、図中の点線（「６」の点線）で示すように、通信サーバ３０から送信されてくる、XLinkの解決要求に応じたピリオドファイルが取得されることになる。
【０２８９】
ステップＳ４８６において、DASHクライアント４０５Ｂは、ステップＳ４６５の処理で応答されるピリオドファイルを取得し、当該ピリオドファイルをパース（構文解析）する。
【０２９０】
ステップＳ４８７において、DASHクライアント４０５Ｂは、ステップＳ４８６の処理結果に応じて、ローカルキャッシュ４０４の永続キャッシュ４０４ＢにキャッシュされたAdセグメントを取得する。ここでは、ステップＳ４８６の処理で、Period要素をパースすることで、対象のAdセグメントのURLが得られるので、当該URLに従い、永続キャッシュ４０４ＢのAdセグメントが取得される。そして、このAdセグメントのファイルは、同一のキャッシュクォータドメインに属する複数のサービスで共有されているファイルであるため、Adセグメントのファイルを再利用することができる。
【０２９１】
ステップＳ４８８において、DASHクライアント４０５Ｂは、再生制御部４０１Ｂからの制御に従い、ステップＳ４８７の処理で取得されたAdセグメントを再生する。これにより、クライアント装置４０では、再生されるコンテンツが、放送番組から広告に切り替わることになる（広告が挿入される）。
【０２９２】
ステップＳ４８９において、DASHクライアント４０５Ｂは、Adセグメントの再生（ステップＳ４８８の処理）が完了したかどうかを判定する。ステップＳ４８９において、Adセグメントの再生が完了していないと判定された場合、処理は、ステップＳ４８８に戻り、Adセグメントの再生が継続される。
【０２９３】
一方で、ステップＳ４８９において、Adセグメントの再生が完了したと判定された場合、処理は、ステップＳ４９０に進められる。ステップＳ４９０において、DASHクライアント４０５Ｂは、Adセグメントの再生完了を、スクリプト実行部４０５Ａに通知する。
【０２９４】
ステップＳ４６６において、スクリプト実行部４０５Ａは、ステップＳ４９０のAdセグメント再生完了通知に応じて、実行中のスクリプトアプリケーションによって、キャッシュ制御部４０１Ａに対して、再生完了のAdセグメントの永続キャッシュ４０４Ｂからの消去を要求する。
【０２９５】
ここで、Adセグメントの永続キャッシュ４０４Ｂからの消去指示は、例えば、スクリプトアプリケーションに記述される、下記のCacheStorage APIを実行することで行われる。
【０２９６】
Interface Cache {
Promise<void> deleteFile(url);
}
【０２９７】
ただし、上記のAPIにおいて、deleteFileメソッドは、永続キャッシュ４０４Ｂからの消去指示に用いられる。また、deleteFileメソッドの引数であるurlで指定されるセグメントファイル（Adセグメントのファイル）が、永続キャッシュ４０４Ｂから削除される対象のファイルとなる。
【０２９８】
ステップＳ４４３において、キャッシュ制御部４０１Ａは、ステップＳ４６６の処理の消去要求に応じて、再生完了のAdセグメント（のファイル）を、ローカルキャッシュ４０４の永続キャッシュ４０４Ｂから消去する。なお、クライアント装置４０では、Adセグメントの再生が終了すると、再生されるコンテンツが、広告から放送番組に切り替わることになる。
【０２９９】
以上、受信側の処理の流れについて説明した。
【０３００】
＜７．変形例＞
【０３０１】
上述した説明としては、デジタル放送の規格として、米国等で採用されている方式である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）等の有線放送などに適用することができる。
【０３０３】
また、上述したドメインやシグナリングなどの名称は、一例であって、他の名称が用いられる場合がある。ただし、これらの名称の違いは、形式的な違いであって、対象のドメインやシグナリングなどの実質的な内容が異なるものではない。例えば、キャッシュクォータドメイン（Cache Quota Domain）は、キャッシュクォータグループ（Cache Quota Group）などの同様のニュアンスを有する他の名称で呼ばれる場合がある。また、例えば、AST(Application Signaling Table)は、AIT(Application Information Table)などと称され、NRT(Non Real Time)は、LCC(Locally Cached Content)などと称される場合がある。さらに、シグナリングがXML等のマークアップ言語により記述される場合において、それらの要素や属性の名称は一例であって、他の名称が採用されるようにしてもよい。ただし、これらの名称の違いは、形式的な違いであって、それらの要素や属性の実質的な内容が異なるものではない。
【０３０４】
また、上述した説明では、LLSシグナリングとして、SLTメタデータを説明したが、LLSシグナリングには、EAT(Emergency Alerting Table)やRRT(Region Rating Table)などのメタデータが含まれるようにしてもよい。EATメタデータは、緊急に告知する必要がある緊急情報に関する情報を含む。RRTメタデータは、レーティングに関する情報を含む。
【０３０５】
なお、アプリケーションは、HTML5等のマークアップ言語やJavaScript（登録商標）等のスクリプト言語で開発されたアプリケーションに限らず、例えば、Java（登録商標）などのプログラミング言語で開発されたアプリケーションであってもよい。また、上述したコンテンツには、動画や広告のほか、例えば、電子書籍やゲーム、音楽など、あらゆるコンテンツを含めることができる。
【０３０６】
また、本技術は、伝送路として、放送網以外の伝送路、すなわち、例えば、インターネットや電話網等の通信回線（通信網）などを利用することを想定して規定されている所定の規格（デジタル放送の規格以外の規格）などにも適用することができる。
【０３０７】
＜８．コンピュータの構成＞
【０３０８】
上述した一連の処理は、ハードウェアにより実行することもできるし、ソフトウェアにより実行することもできる。一連の処理をソフトウェアにより実行する場合には、そのソフトウェアを構成するプログラムが、コンピュータにインストールされる。図２９は、上述した一連の処理をプログラムにより実行するコンピュータのハードウェアの構成例を示す図である。
【０３０９】
コンピュータ１０００において、CPU(Central Processing Unit)１００１、ROM(Read Only Memory)１００２、RAM(Random Access Memory)１００３は、バス１００４により相互に接続されている。バス１００４には、さらに、入出力インターフェース１００５が接続されている。入出力インターフェース１００５には、入力部１００６、出力部１００７、記録部１００８、通信部１００９、及び、ドライブ１０１０が接続されている。
【０３１０】
入力部１００６は、キーボード、マウス、マイクロフォンなどよりなる。出力部１００７は、ディスプレイ、スピーカなどよりなる。記録部１００８は、ハードディスクや不揮発性のメモリなどよりなる。通信部１００９は、ネットワークインターフェースなどよりなる。ドライブ１０１０は、磁気ディスク、光ディスク、光磁気ディスク、又は半導体メモリなどのリムーバブルメディア１０１１を駆動する。
【０３１１】
以上のように構成されるコンピュータ１０００では、CPU１００１が、ROM１００２や記録部１００８に記録されているプログラムを、入出力インターフェース１００５及びバス１００４を介して、RAM１００３にロードして実行することにより、上述した一連の処理が行われる。
【０３１２】
コンピュータ１０００（CPU１００１）が実行するプログラムは、例えば、パッケージメディア等としてのリムーバブルメディア１０１１に記録して提供することができる。また、プログラムは、ローカルエリアネットワーク、インターネット、デジタル衛星放送といった、有線又は無線の伝送媒体を介して提供することができる。
【０３１３】
コンピュータ１０００では、プログラムは、リムーバブルメディア１０１１をドライブ１０１０に装着することにより、入出力インターフェース１００５を介して、記録部１００８にインストールすることができる。また、プログラムは、有線又は無線の伝送媒体を介して、通信部１００９で受信し、記録部１００８にインストールすることができる。その他、プログラムは、ROM１００２や記録部１００８に、あらかじめインストールしておくことができる。
【０３１４】
ここで、本明細書において、コンピュータがプログラムに従って行う処理は、必ずしもフローチャートとして記載された順序に沿って時系列に行われる必要はない。すなわち、コンピュータがプログラムに従って行う処理は、並列的あるいは個別に実行される処理（例えば、並列処理あるいはオブジェクトによる処理）も含む。また、プログラムは、１のコンピュータ（プロセッサ）により処理されるものであってもよいし、複数のコンピュータによって分散処理されるものであってもよい。
【０３１５】
なお、本技術の実施の形態は、上述した実施の形態に限定されるものではなく、本技術の要旨を逸脱しない範囲において種々の変更が可能である。
【０３１６】
また、本技術は、以下のような構成をとることができる。
【０３１７】
（１）
コンテンツを受信する受信部と、
前記コンテンツとともに伝送される制御情報であって、前記コンテンツのリソースが、複数のサービスで共有されるリソースであるかどうかを示すリソース共有情報を含む前記制御情報に基づいて、前記コンテンツのリソースが、複数のサービスで共有されるように、前記リソースの記憶装置への記憶を制御する制御部と
を備える受信装置。
（２）
前記制御部は、前記制御情報に含まれる前記リソース共有情報が、複数のサービスで共有されるリソースであることを示している場合、共有されるリソースである共有リソースを、他のリソースと区別して記憶させる
（１）に記載の受信装置。
（３）
前記コンテンツ及び前記制御情報は、放送波により伝送され、
前記サービスは、デジタル放送のサービスであり、
前記制御情報は、前記サービスを提供するためのシグナリングである
（１）又は（２）に記載の受信装置。
（４）
前記シグナリングは、複数のサービスの属性を指定可能な第１のシグナリングであり、
前記第１のシグナリングは、サービス単位で指定された前記リソース共有情報を含む
（３）に記載の受信装置。
（５）
前記シグナリングは、サービスごとの属性を指定可能な第２のシグナリングであり、
前記第２のシグナリングは、対象のサービス内の所定の単位で指定された前記リソース共有情報を含む
（３）に記載の受信装置。
（６）
前記リソース共有情報は、サービス単位、セッション単位、又はアプリケーション単位で指定される
（５）に記載の受信装置。
（７）
前記コンテンツのリソースは、所定の形式のファイルであり、
前記制御部は、前記コンテンツとともに伝送されるアプリケーションの動作に応じて、共有リソースのファイルを、他のリソースのファイルが記憶される第１の記憶領域とは異なる第２の記憶領域に記憶させる
（２）乃至（６）のいずれかに記載の受信装置。
（８）
前記制御部は、前記アプリケーションの動作に応じて、前記第２の記憶領域に記憶された共有リソースのファイルを消去する
（７）に記載の受信装置。
（９）
前記放送波は、IP(Internet Protocol)伝送方式に対応した放送波であり、
前記コンテンツのリソースのファイルのデータは、UDP(User Datagram Protocol)パケットを含むIPパケットに格納されて伝送される
（３）乃至（８）のいずれかに記載の受信装置。
（１０）
前記コンテンツは、広告のコンテンツを含み、
前記リソース共有情報は、前記広告のコンテンツのリソースを共有する複数のサービスが属するグループを識別するための識別情報である
（１）乃至（９）のいずれかに記載の受信装置。
（１１）
受信装置のデータ処理方法において、
前記受信装置が、
コンテンツを受信し、
前記コンテンツとともに伝送される制御情報であって、前記コンテンツのリソースが、複数のサービスで共有されるリソースであるかどうかを示すリソース共有情報を含む前記制御情報に基づいて、前記コンテンツのリソースが、複数のサービスで共有されるように、前記リソースの記憶装置への記憶を制御する
ステップを含むデータ処理方法。
（１２）
コンテンツのリソースが、複数のサービスで共有されるリソースであるかどうかを示すリソース共有情報を含む制御情報を生成する生成部と、
前記コンテンツとともに、前記制御情報を送信する送信部と
を備える送信装置。
（１３）
前記コンテンツ及び前記制御情報は、放送波により伝送され、
前記サービスは、デジタル放送のサービスであり、
前記制御情報は、前記サービスを提供するためのシグナリングである
（１２）に記載の送信装置。
（１４）
前記シグナリングは、複数のサービスの属性を指定可能な第１のシグナリングであり、
前記第１のシグナリングは、サービス単位で指定された前記リソース共有情報を含む
（１３）に記載の送信装置。
（１５）
前記シグナリングは、サービスごとの属性を指定可能な第２のシグナリングであり、
前記第２のシグナリングは、対象のサービス内の所定の単位で指定された前記リソース共有情報を含む
（１３）に記載の送信装置。
（１６）
前記リソース共有情報は、サービス単位、セッション単位、又はアプリケーション単位で指定される
（１５）に記載の送信装置。
（１７）
前記コンテンツのリソースは、所定の形式のファイルである
（１２）乃至（１６）のいずれかに記載の送信装置。
（１８）
前記放送波は、IP伝送方式に対応した放送波であり、
前記コンテンツのリソースのファイルのデータは、UDPパケットを含むIPパケットに格納されて伝送される
（１３）乃至（１７）のいずれかに記載の送信装置。
（１９）
前記コンテンツは、広告のコンテンツを含み、
前記リソース共有情報は、前記広告のコンテンツのリソースを共有する複数のサービスが属するグループを識別するための識別情報である
（１２）乃至（１８）のいずれかに記載の送信装置。
（２０）
送信装置のデータ処理方法において、
前記送信装置が、
コンテンツのリソースが、複数のサービスで共有されるリソースであるかどうかを示すリソース共有情報を含む制御情報を生成し、
前記コンテンツとともに、前記制御情報を送信する
ステップを含むデータ処理方法。
【符号の説明】
【０３１８】
１  伝送システム，  １０  Ad/DASHサーバ，  ２０  放送サーバ，  ３０  通信サーバ，  ４０  クライアント装置，  ８０  伝送路，  ９０  インターネット，  １０１  受信部，  １０２  Ad/DASHセグメント生成部，  １０３  スクリプトアプリケーション生成部，  １０４  MPD生成部，  １０５  処理部，  １０６  送信部，  ２０１  受信部，  ２０２  シグナリング生成部，  ２０３  処理部，  ２０４  送信部，  ３０１  受信部，  ３０２  ピリオドファイル生成部，  ３０３  処理部，  ３０４  通信部，  ４０１  制御部，  ４０１Ａ  キャッシュ制御部，  ４０１Ｂ  再生制御部，  ４０２  受信部，  ４０３  放送ミドルウェア，  ４０４  ローカルキャッシュ，  ４０４Ａ  通常キャッシュ，  ４０４Ｂ  永続キャッシュ，  ４０５  ブラウザ，  ４０５Ａ  スクリプト実行部，  ４０５Ｂ  DASHクライアント，  ４０６  出力部，  ４０７  通信部，  １０００  コンピュータ，  １００１  CPU
【図１】
2017090457.tif 000003
【図２】
2017090457.tif 000004
【図３】
2017090457.tif 000005
【図４】
2017090457.tif 000006
【図５】
2017090457.tif 000007
【図６】
2017090457.tif 000008
【図７】
2017090457.tif 000009
【図８】
2017090457.tif 000010
【図９】
2017090457.tif 000011
【図１０】
2017090457.tif 000012
【図１１】
2017090457.tif 000013
【図１２】
2017090457.tif 000014
【図１３】
2017090457.tif 000015
【図１４】
2017090457.tif 000016
【図１５】
2017090457.tif 000017
【図１６】
2017090457.tif 000018
【図１７】
2017090457.tif 000019
【図１８】
2017090457.tif 000020
【図１９】
2017090457.tif 000021
【図２０】
2017090457.tif 000022
【図２１】
2017090457.tif 000023
【図２２】
2017090457.tif 000024
【図２３】
2017090457.tif 000025
【図２４】
2017090457.tif 000026
【図２５】
2017090457.tif 000027
【図２６】
2017090457.tif 000028
【図２７】
2017090457.tif 000029
【図２８】
2017090457.tif 000030
【図２９】
2017090457.tif 000031
【国際調査報告】
2017090457.tif 000032
2017090457.tif 000033
2017090457.tif 000034
2017090457.tif 000035