WO2017090457A1 - 受信装置、送信装置、及び、データ処理方法 - Google Patents

受信装置、送信装置、及び、データ処理方法 Download PDF

Info

Publication number
WO2017090457A1
WO2017090457A1 PCT/JP2016/083467 JP2016083467W WO2017090457A1 WO 2017090457 A1 WO2017090457 A1 WO 2017090457A1 JP 2016083467 W JP2016083467 W JP 2016083467W WO 2017090457 A1 WO2017090457 A1 WO 2017090457A1
Authority
WO
WIPO (PCT)
Prior art keywords
resource
content
signaling
service
cache
Prior art date
Application number
PCT/JP2016/083467
Other languages
English (en)
French (fr)
Inventor
山岸　靖明
五十嵐　卓也
Original Assignee
ソニー株式会社
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority to KR1020247004799A priority Critical patent/KR20240025698A/ko
Priority to CN201680067759.9A priority patent/CN108293148B/zh
Priority to US15/766,850 priority patent/US10986397B2/en
Priority to CA3003683A priority patent/CA3003683A1/en
Priority to JP2017552356A priority patent/JPWO2017090457A1/ja
Priority to MX2018006174A priority patent/MX2018006174A/es
Application filed by ソニー株式会社 filed Critical ソニー株式会社
Priority to EP16868405.8A priority patent/EP3383054B1/en
Priority to AU2016360190A priority patent/AU2016360190A1/en
Priority to KR1020187013711A priority patent/KR102637023B1/ko
Publication of WO2017090457A1 publication Critical patent/WO2017090457A1/ja
Priority to US17/189,827 priority patent/US11575961B2/en
Priority to AU2021202436A priority patent/AU2021202436B2/en

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/433—Content storage operation, e.g. storage operation in response to a pause request, caching operations
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/434—Disassembling of a multiplex stream, e.g. demultiplexing audio and video streams, extraction of additional data from a video stream; Remultiplexing of multiplex streams; Extraction or processing of SI; Disassembling of packetised elementary stream
    • H04N21/4348—Demultiplexing of additional data and video streams
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/236—Assembling of a multiplex stream, e.g. transport stream, by combining a video stream with other content or additional data, e.g. inserting a URL [Uniform Resource Locator] into a video stream, multiplexing software data into a video stream; Remultiplexing of multiplex streams; Insertion of stuffing bits into the multiplex stream, e.g. to obtain a constant bit-rate; Assembling of a packetised elementary stream
    • H04N21/2362—Generation or processing of Service Information [SI]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F13/00—Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04H—BROADCAST COMMUNICATION
    • H04H60/00—Arrangements for broadcast applications with a direct linking to broadcast information or broadcast space-time; Broadcast-related systems
    • H04H60/27—Arrangements for recording or accumulating broadcast information or broadcast-related information
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/236—Assembling of a multiplex stream, e.g. transport stream, by combining a video stream with other content or additional data, e.g. inserting a URL [Uniform Resource Locator] into a video stream, multiplexing software data into a video stream; Remultiplexing of multiplex streams; Insertion of stuffing bits into the multiplex stream, e.g. to obtain a constant bit-rate; Assembling of a packetised elementary stream
    • H04N21/23614—Multiplexing of additional data and video streams
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/433—Content storage operation, e.g. storage operation in response to a pause request, caching operations
    • H04N21/4331—Caching operations, e.g. of an advertisement for later insertion during playback
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/434—Disassembling of a multiplex stream, e.g. demultiplexing audio and video streams, extraction of additional data from a video stream; Remultiplexing of multiplex streams; Extraction or processing of SI; Disassembling of packetised elementary stream
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/434—Disassembling of a multiplex stream, e.g. demultiplexing audio and video streams, extraction of additional data from a video stream; Remultiplexing of multiplex streams; Extraction or processing of SI; Disassembling of packetised elementary stream
    • H04N21/4345—Extraction or processing of SI, e.g. extracting service information from an MPEG stream
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/61—Network physical structure; Signal processing
    • H04N21/6106—Network physical structure; Signal processing specially adapted to the downstream path of the transmission network
    • H04N21/6112—Network physical structure; Signal processing specially adapted to the downstream path of the transmission network involving terrestrial transmission, e.g. DVB-T
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/61—Network physical structure; Signal processing
    • H04N21/6106—Network physical structure; Signal processing specially adapted to the downstream path of the transmission network
    • H04N21/6125—Network physical structure; Signal processing specially adapted to the downstream path of the transmission network involving transmission via Internet
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/643—Communication protocols
    • H04N21/64322—IP
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/65—Transmission of management data between client and server
    • H04N21/654—Transmission by server directed to the client
    • H04N21/6543—Transmission by server directed to the client for forcing some client operations, e.g. recording
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/81—Monomedia components thereof
    • H04N21/812—Monomedia components thereof involving advertisement data
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/81—Monomedia components thereof
    • H04N21/8166—Monomedia components thereof involving executable data, e.g. software
    • H04N21/8173—End-user applications, e.g. Web browser, game
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/83—Generation or processing of protective or descriptive data associated with content; Content structuring
    • H04N21/845—Structuring of content, e.g. decomposing content into time segments
    • H04N21/8456—Structuring of content, e.g. decomposing content into time segments by decomposing the content in the time domain, e.g. in time segments

Landscapes

  • Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • Multimedia (AREA)
  • General Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Marketing (AREA)
  • Business, Economics & Management (AREA)
  • Information Transfer Between Computers (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

本技術は、複数のサービスにおいて再利用されるリソースを共有することができるようにする受信装置、送信装置、及び、データ処理方法に関する。 受信装置は、コンテンツを受信し、コンテンツとともに伝送される制御情報であって、コンテンツのリソースが、複数のサービスで共有されるリソースであるかどうかを示すリソース共有情報を含む制御情報に基づいて、コンテンツのリソースが、複数のサービスで共有されるように、リソースの記憶装置への記憶を制御する。本技術は、例えば、ATSC3.0に対応したテレビ受像機に適用することができる。

Description

受信装置、送信装置、及び、データ処理方法
　本技術は、受信装置、送信装置、及び、データ処理方法に関し、特に、複数のサービスにおいて再利用されるリソースを共有することができるようにした受信装置、送信装置、及び、データ処理方法に関する。
　クライアント装置において、特定のサービスに付随するアプリケーションのファイルに対するアクセスのパフォーマンスを向上させるためには、ローカルキャッシュにあらかじめ必要なファイルをキャッシュしておく必要がある。
　例えば、現在策定が進められている米国の次世代放送規格である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

Claims (20)

  1. 　コンテンツを受信する受信部と、
    　前記コンテンツとともに伝送される制御情報であって、前記コンテンツのリソースが、複数のサービスで共有されるリソースであるかどうかを示すリソース共有情報を含む前記制御情報に基づいて、前記コンテンツのリソースが、複数のサービスで共有されるように、前記リソースの記憶装置への記憶を制御する制御部と
    　を備える受信装置。
  2. 　前記制御部は、前記制御情報に含まれる前記リソース共有情報が、複数のサービスで共有されるリソースであることを示している場合、共有されるリソースである共有リソースを、他のリソースと区別して記憶させる
    　請求項１に記載の受信装置。
  3. 　前記コンテンツ及び前記制御情報は、放送波により伝送され、
    　前記サービスは、デジタル放送のサービスであり、
    　前記制御情報は、前記サービスを提供するためのシグナリングである
    　請求項２に記載の受信装置。
  4. 　前記シグナリングは、複数のサービスの属性を指定可能な第１のシグナリングであり、
    　前記第１のシグナリングは、サービス単位で指定された前記リソース共有情報を含む
    　請求項３に記載の受信装置。
  5. 　前記シグナリングは、サービスごとの属性を指定可能な第２のシグナリングであり、
    　前記第２のシグナリングは、対象のサービス内の所定の単位で指定された前記リソース共有情報を含む
    　請求項３に記載の受信装置。
  6. 　前記リソース共有情報は、サービス単位、セッション単位、又はアプリケーション単位で指定される
    　請求項５に記載の受信装置。
  7. 　前記コンテンツのリソースは、所定の形式のファイルであり、
    　前記制御部は、前記コンテンツとともに伝送されるアプリケーションの動作に応じて、共有リソースのファイルを、他のリソースのファイルが記憶される第１の記憶領域とは異なる第２の記憶領域に記憶させる
    　請求項３に記載の受信装置。
  8. 　前記制御部は、前記アプリケーションの動作に応じて、前記第２の記憶領域に記憶された共有リソースのファイルを消去する
    　請求項７に記載の受信装置。
  9. 　前記放送波は、IP(Internet Protocol)伝送方式に対応した放送波であり、
    　前記コンテンツのリソースのファイルのデータは、UDP(User Datagram Protocol)パケットを含むIPパケットに格納されて伝送される
    　請求項３に記載の受信装置。
  10. 　前記コンテンツは、広告のコンテンツを含み、
    　前記リソース共有情報は、前記広告のコンテンツのリソースを共有する複数のサービスが属するグループを識別するための識別情報である
    　請求項１に記載の受信装置。
  11. 　受信装置のデータ処理方法において、
    　前記受信装置が、
    　コンテンツを受信し、
    　前記コンテンツとともに伝送される制御情報であって、前記コンテンツのリソースが、複数のサービスで共有されるリソースであるかどうかを示すリソース共有情報を含む前記制御情報に基づいて、前記コンテンツのリソースが、複数のサービスで共有されるように、前記リソースの記憶装置への記憶を制御する
    　ステップを含むデータ処理方法。
  12. 　コンテンツのリソースが、複数のサービスで共有されるリソースであるかどうかを示すリソース共有情報を含む制御情報を生成する生成部と、
    　前記コンテンツとともに、前記制御情報を送信する送信部と
    　を備える送信装置。
  13. 　前記コンテンツ及び前記制御情報は、放送波により伝送され、
    　前記サービスは、デジタル放送のサービスであり、
    　前記制御情報は、前記サービスを提供するためのシグナリングである
    　請求項１２に記載の送信装置。
  14. 　前記シグナリングは、複数のサービスの属性を指定可能な第１のシグナリングであり、
    　前記第１のシグナリングは、サービス単位で指定された前記リソース共有情報を含む
    　請求項１３に記載の送信装置。
  15. 　前記シグナリングは、サービスごとの属性を指定可能な第２のシグナリングであり、
    　前記第２のシグナリングは、対象のサービス内の所定の単位で指定された前記リソース共有情報を含む
    　請求項１３に記載の送信装置。
  16. 　前記リソース共有情報は、サービス単位、セッション単位、又はアプリケーション単位で指定される
    　請求項１５に記載の送信装置。
  17. 　前記コンテンツのリソースは、所定の形式のファイルである
    　請求項１２に記載の送信装置。
  18. 　前記放送波は、IP伝送方式に対応した放送波であり、
    　前記コンテンツのリソースのファイルのデータは、UDPパケットを含むIPパケットに格納されて伝送される
    　請求項１３に記載の送信装置。
  19. 　前記コンテンツは、広告のコンテンツを含み、
    　前記リソース共有情報は、前記広告のコンテンツのリソースを共有する複数のサービスが属するグループを識別するための識別情報である
    　請求項１２に記載の送信装置。
  20. 　送信装置のデータ処理方法において、
    　前記送信装置が、
    　コンテンツのリソースが、複数のサービスで共有されるリソースであるかどうかを示すリソース共有情報を含む制御情報を生成し、
    　前記コンテンツとともに、前記制御情報を送信する
    　ステップを含むデータ処理方法。
PCT/JP2016/083467 2015-11-25 2016-11-11 受信装置、送信装置、及び、データ処理方法 WO2017090457A1 (ja)

Priority Applications (11)

Application Number Priority Date Filing Date Title
CN201680067759.9A CN108293148B (zh) 2015-11-25 2016-11-11 接收装置、发送装置以及数据处理方法
US15/766,850 US10986397B2 (en) 2015-11-25 2016-11-11 Reception apparatus, transmission apparatus, and data processing method
CA3003683A CA3003683A1 (en) 2015-11-25 2016-11-11 Reception apparatus, transmission apparatus, and data processing method
JP2017552356A JPWO2017090457A1 (ja) 2015-11-25 2016-11-11 受信装置、送信装置、及び、データ処理方法
MX2018006174A MX2018006174A (es) 2015-11-25 2016-11-11 Aparato de recepcion, aparato de transmision y metodo de procesamiento de datos.
KR1020247004799A KR20240025698A (ko) 2015-11-25 2016-11-11 수신 장치, 송신 장치, 및 데이터 처리 방법
EP16868405.8A EP3383054B1 (en) 2015-11-25 2016-11-11 Reception device, transmission device and data processing method
AU2016360190A AU2016360190A1 (en) 2015-11-25 2016-11-11 Reception device, transmission device and data processing method
KR1020187013711A KR102637023B1 (ko) 2015-11-25 2016-11-11 수신 장치, 송신 장치, 및 데이터 처리 방법
US17/189,827 US11575961B2 (en) 2015-11-25 2021-03-02 Reception apparatus, transmission apparatus, and data processing method
AU2021202436A AU2021202436B2 (en) 2015-11-25 2021-04-21 Reception appartus, transmission apparatus, and data processing method

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2015-229769 2015-11-25
JP2015229769 2015-11-25

Related Child Applications (2)

Application Number Title Priority Date Filing Date
US15/766,850 A-371-Of-International US10986397B2 (en) 2015-11-25 2016-11-11 Reception apparatus, transmission apparatus, and data processing method
US17/189,827 Continuation US11575961B2 (en) 2015-11-25 2021-03-02 Reception apparatus, transmission apparatus, and data processing method

Publications (1)

Publication Number Publication Date
WO2017090457A1 true WO2017090457A1 (ja) 2017-06-01

Family

ID=58763199

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2016/083467 WO2017090457A1 (ja) 2015-11-25 2016-11-11 受信装置、送信装置、及び、データ処理方法

Country Status (9)

Country Link
US (2) US10986397B2 (ja)
EP (1) EP3383054B1 (ja)
JP (1) JPWO2017090457A1 (ja)
KR (2) KR20240025698A (ja)
CN (1) CN108293148B (ja)
AU (2) AU2016360190A1 (ja)
CA (1) CA3003683A1 (ja)
MX (1) MX2018006174A (ja)
WO (1) WO2017090457A1 (ja)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2021108440A (ja) * 2019-12-27 2021-07-29 株式会社インフォシティ 放送サービス通信ネットワーク配信装置および方法
US11368730B2 (en) 2019-08-27 2022-06-21 Electronics And Telecommunications Research Institute Apparatus and method for transmitting broadcast content based on ATSC 3.0, and apparatus and method for receiving broadcast content based ATSC 3.0
JP2023008952A (ja) * 2021-06-30 2023-01-19 レモン インコーポレイテッド 事前選択の目的のシグナリング
US11985333B2 (en) 2022-06-27 2024-05-14 Lemon Inc. Indicating which video data units represent a target picture-in-picture region

Families Citing this family (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
MX2018006174A (es) * 2015-11-25 2018-08-01 Sony Corp Aparato de recepcion, aparato de transmision y metodo de procesamiento de datos.
US11044294B2 (en) 2018-01-03 2021-06-22 Sony Group Corporation ATSC 3.0 playback using MPEG media transport protocol (MMTP)
US11606528B2 (en) 2018-01-03 2023-03-14 Saturn Licensing Llc Advanced television systems committee (ATSC) 3.0 latency-free display of content attribute
US11109115B2 (en) * 2018-11-06 2021-08-31 At&T Intellectual Property I, L.P. Inserting advertisements in ATSC content
WO2020104035A1 (en) * 2018-11-22 2020-05-28 Telefonaktiebolaget Lm Ericsson (Publ) Media descriptor file comprising a reference to other streaming media content
US10743069B2 (en) 2018-12-10 2020-08-11 Sony Corporation Delivery of information related to digital rights management (DRM) in a terrestrial broadcast system
US11706465B2 (en) 2019-01-15 2023-07-18 Sony Group Corporation ATSC 3.0 advertising notification using event streams
EP4029279A1 (en) 2019-10-04 2022-07-20 Eexpway Method for broadcasting dash/hls hybrid multimedia streams
US11960507B2 (en) 2020-01-17 2024-04-16 International Business Machines Corporation Hierarchical data
DE202020104113U1 (de) * 2020-07-16 2021-10-20 WAGO Verwaltungsgesellschaft mit beschränkter Haftung Elektronikeinrichtung für eine industrielle elektrische Anlage sowie Kommunikationsmodul
US11451872B1 (en) * 2021-05-27 2022-09-20 Sling TV L.L.C. System, device, and processes for intelligent start playback of program content

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2001197381A (ja) * 1999-11-05 2001-07-19 Dentsu Inc 蓄積情報の放送方法及びそのためのテレビジョン装置
JP2002101056A (ja) * 2000-07-17 2002-04-05 Matsushita Electric Ind Co Ltd 放送装置、放送方法、プログラム記録媒体、プログラム
JP2003032653A (ja) * 2001-07-16 2003-01-31 Funai Electric Co Ltd 双方向テレビシステムおよび双方向テレビ受信装置
JP2006099698A (ja) * 2004-09-30 2006-04-13 Toshiba Corp 配信情報再生装置、プログラム及び方法
JP2008017207A (ja) * 2006-07-06 2008-01-24 Kddi Corp 映像信号受信装置
JP2014057227A (ja) 2012-09-13 2014-03-27 Sony Corp コンテンツ供給装置、コンテンツ供給方法、プログラム、およびコンテンツ供給システム

Family Cites Families (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8300534B2 (en) * 2000-05-24 2012-10-30 Alcatel Lucent Programmable packet processor with flow resolution logic
US7096482B2 (en) 2000-07-17 2006-08-22 Matsushita Electric Industrial Co., Ltd. Broadcasting apparatus, broadcasting method, program recording medium, and program
US7073178B2 (en) * 2002-01-18 2006-07-04 Mobitv, Inc. Method and system of performing transactions using shared resources and different applications
US7721306B2 (en) * 2006-02-15 2010-05-18 Sony Corporation Bandwidth sharing
US20080098420A1 (en) * 2006-10-19 2008-04-24 Roundbox, Inc. Distribution and display of advertising for devices in a network
JP4973246B2 (ja) * 2007-03-09 2012-07-11 日本電気株式会社 アクセス権管理システム、サーバ及びアクセス権管理プログラム
US9027100B2 (en) 2010-01-05 2015-05-05 Yahoo! Inc. Client-side ad caching for lower ad serving latency
US9052919B2 (en) * 2010-01-15 2015-06-09 Apple Inc. Specialized network fileserver
US8832750B2 (en) * 2012-05-10 2014-09-09 Time Warner Cable Enterprises Llc Media synchronization within home network using set-top box as gateway
KR20140029733A (ko) * 2012-08-29 2014-03-11 주식회사 팬택 어플리케이션 관리 기능을 갖는 디바이스 및 이를 위한 어플리케이션 관리 방법
US20140229580A1 (en) * 2013-02-12 2014-08-14 Sony Corporation Information processing device, information processing method, and information processing system
JP5865551B2 (ja) * 2013-04-16 2016-02-17 パナソニック インテレクチュアル プロパティ コーポレーション オブアメリカＰａｎａｓｏｎｉｃ Ｉｎｔｅｌｌｅｃｔｕａｌ Ｐｒｏｐｅｒｔｙ Ｃｏｒｐｏｒａｔｉｏｎ ｏｆ Ａｍｅｒｉｃａ コンテンツ表示方法、プログラム及びコンテンツ表示システム
EP3062521B1 (en) * 2013-10-25 2018-07-04 Sony Corporation Reception apparatus, reception method, transmission apparatus, and transmission method for services transmitted on a broadcast wave using ip packets
EP2922303A1 (en) * 2014-03-04 2015-09-23 LG Electronics Inc. Display device for managing a plurality of time source data and method for controlling the same
US9386027B2 (en) * 2014-08-11 2016-07-05 Indiana University Research & Technology Corporation Detection of pileup vulnerabilities in mobile operating systems
MX2018006174A (es) * 2015-11-25 2018-08-01 Sony Corp Aparato de recepcion, aparato de transmision y metodo de procesamiento de datos.

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2001197381A (ja) * 1999-11-05 2001-07-19 Dentsu Inc 蓄積情報の放送方法及びそのためのテレビジョン装置
JP2002101056A (ja) * 2000-07-17 2002-04-05 Matsushita Electric Ind Co Ltd 放送装置、放送方法、プログラム記録媒体、プログラム
JP2003032653A (ja) * 2001-07-16 2003-01-31 Funai Electric Co Ltd 双方向テレビシステムおよび双方向テレビ受信装置
JP2006099698A (ja) * 2004-09-30 2006-04-13 Toshiba Corp 配信情報再生装置、プログラム及び方法
JP2008017207A (ja) * 2006-07-06 2008-01-24 Kddi Corp 映像信号受信装置
JP2014057227A (ja) 2012-09-13 2014-03-27 Sony Corp コンテンツ供給装置、コンテンツ供給方法、プログラム、およびコンテンツ供給システム

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See also references of EP3383054A4

Cited By (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11368730B2 (en) 2019-08-27 2022-06-21 Electronics And Telecommunications Research Institute Apparatus and method for transmitting broadcast content based on ATSC 3.0, and apparatus and method for receiving broadcast content based ATSC 3.0
JP2021108440A (ja) * 2019-12-27 2021-07-29 株式会社インフォシティ 放送サービス通信ネットワーク配信装置および方法
JP2021108441A (ja) * 2019-12-27 2021-07-29 株式会社インフォシティ 放送サービス通信ネットワーク配信装置および方法
JP7058039B2 (ja) 2019-12-27 2022-04-21 株式会社インフォシティ 放送サービス通信ネットワーク配信装置および方法
JP2022095777A (ja) * 2019-12-27 2022-06-28 株式会社インフォシティ 放送サービス通信ネットワーク配信装置および方法
JP7125692B2 (ja) 2019-12-27 2022-08-25 株式会社インフォシティ 放送サービス通信ネットワーク配信装置および方法
JP7477116B2 (ja) 2019-12-27 2024-05-01 株式会社インフォシティ 放送サービス通信ネットワーク配信装置および方法
JP2023008952A (ja) * 2021-06-30 2023-01-19 レモン インコーポレイテッド 事前選択の目的のシグナリング
JP7460693B2 (ja) 2021-06-30 2024-04-02 レモン インコーポレイテッド 事前選択の目的のシグナリング
US11985333B2 (en) 2022-06-27 2024-05-14 Lemon Inc. Indicating which video data units represent a target picture-in-picture region

Also Published As

Publication number Publication date
KR20240025698A (ko) 2024-02-27
AU2021202436B2 (en) 2023-03-16
EP3383054B1 (en) 2021-07-28
JPWO2017090457A1 (ja) 2018-09-13
CA3003683A1 (en) 2017-06-01
EP3383054A4 (en) 2019-01-09
AU2016360190A1 (en) 2018-04-19
US20180288468A1 (en) 2018-10-04
EP3383054A1 (en) 2018-10-03
KR102637023B1 (ko) 2024-02-16
MX2018006174A (es) 2018-08-01
US20210266629A1 (en) 2021-08-26
US11575961B2 (en) 2023-02-07
CN108293148A (zh) 2018-07-17
AU2021202436A1 (en) 2021-05-13
CN108293148B (zh) 2022-07-26
US10986397B2 (en) 2021-04-20
KR20180088383A (ko) 2018-08-03

Similar Documents

Publication Publication Date Title
AU2021202436B2 (en) Reception appartus, transmission apparatus, and data processing method
CN103081507B (zh) 集成并处理到视频流中相关视频内容的嵌入式链接以提供广告信息
KR102443060B1 (ko) 정보 처리 장치 및 정보 처리 방법
US10469919B2 (en) Broadcast signal transmission apparatus, broadcast signal reception apparatus, broadcast signal transmission method, and broadcast signal reception method
WO2018034172A1 (ja) 情報処理装置、クライアント装置、及び、データ処理方法
JPWO2016174960A1 (ja) 受信装置、送信装置、およびデータ処理方法
US11336957B2 (en) Reception apparatus, transmission apparatus, and data processing method
WO2016067987A1 (ja) 受信装置、送信装置、およびデータ処理方法
KR102491466B1 (ko) 수신 장치, 송신 장치, 및 데이터 처리 방법
KR102600762B1 (ko) Atsc 3.0 기반의 방송 콘텐츠 전송 장치 및 방법과, 방송 콘텐츠 수신 장치 및 방법
WO2018012315A1 (ja) 情報処理装置、及び、情報処理方法
WO2017212932A1 (ja) 受信装置、送信装置、及び、データ処理方法
JP2012257231A (ja) 放送通信連携システム、サーバおよびプログラム

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 16868405

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 15766850

Country of ref document: US

ENP Entry into the national phase

Ref document number: 2017552356

Country of ref document: JP

Kind code of ref document: A

ENP Entry into the national phase

Ref document number: 2016360190

Country of ref document: AU

Date of ref document: 20161111

Kind code of ref document: A

ENP Entry into the national phase

Ref document number: 3003683

Country of ref document: CA

ENP Entry into the national phase

Ref document number: 20187013711

Country of ref document: KR

Kind code of ref document: A

WWE Wipo information: entry into national phase

Ref document number: MX/A/2018/006174

Country of ref document: MX

NENP Non-entry into the national phase

Ref country code: DE

WWE Wipo information: entry into national phase

Ref document number: 2016868405

Country of ref document: EP