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

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

Info

Publication number
JPWO2018021015A1
JPWO2018021015A1 JP2018529493A JP2018529493A JPWO2018021015A1 JP WO2018021015 A1 JPWO2018021015 A1 JP WO2018021015A1 JP 2018529493 A JP2018529493 A JP 2018529493A JP 2018529493 A JP2018529493 A JP 2018529493A JP WO2018021015 A1 JPWO2018021015 A1 JP WO2018021015A1
Authority
JP
Japan
Prior art keywords
application
period
information
file
valid
Prior art date
Legal status (The legal status 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 status listed.)
Pending
Application number
JP2018529493A
Other languages
English (en)
Inventor
山岸　靖明
靖明 山岸
五十嵐　卓也
卓也 五十嵐
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Sony Corp
Original Assignee
Sony Corp
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
Application filed by Sony Corp filed Critical Sony Corp
Publication of JPWO2018021015A1 publication Critical patent/JPWO2018021015A1/ja
Pending legal-status Critical Current

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04H—BROADCAST COMMUNICATION
    • H04H20/00—Arrangements for broadcast or for distribution combined with broadcast
    • H04H20/86—Arrangements characterised by the broadcast information itself
    • H04H20/91—Arrangements characterised by the broadcast information itself broadcasting computer programmes
    • 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/09—Arrangements for device control with a direct linkage to broadcast information or to broadcast space-time; Arrangements for control of broadcast-related services
    • H04H60/13—Arrangements for device control affected by the broadcast 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
    • H04N21/23617—Multiplexing of additional data and video streams by inserting additional data into a data carousel, e.g. inserting software modules into a DVB carousel
    • 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/45—Management operations performed by the client for facilitating the reception of or the interaction with the content or administrating data related to the end-user or to the client device itself, e.g. learning user preferences for recommending movies, resolving scheduling conflicts
    • H04N21/462—Content or additional data management, e.g. creating a master electronic program guide from data received from the Internet and a Head-end, controlling the complexity of a video stream by scaling the resolution or bit-rate based on the client capabilities
    • 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/45—Management operations performed by the client for facilitating the reception of or the interaction with the content or administrating data related to the end-user or to the client device itself, e.g. learning user preferences for recommending movies, resolving scheduling conflicts
    • H04N21/462—Content or additional data management, e.g. creating a master electronic program guide from data received from the Internet and a Head-end, controlling the complexity of a video stream by scaling the resolution or bit-rate based on the client capabilities
    • H04N21/4622—Retrieving content or additional data from different sources, e.g. from a broadcast channel and the 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/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/47—End-user applications
    • H04N21/472—End-user interface for requesting content, additional data or services; End-user interface for interacting with content, e.g. for content reservation or setting reminders, for requesting event notification, for manipulating displayed content
    • 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/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

Landscapes

  • Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • Multimedia (AREA)
  • Databases & Information Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Human Computer Interaction (AREA)
  • Software Systems (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
  • Information Transfer Between Computers (AREA)
  • Circuits Of Receivers In General (AREA)

Abstract

本技術は、コンテンツに付随するアプリケーションの動作を、より柔軟に制御することができるようにする受信装置、送信装置、及び、データ処理方法に関する。コンテンツに付随するアプリケーションが有効になる期間を示す有効期間情報は、期間に応じてアプリケーションの動作を制御する第１のモードと、エンドユーザの意志に応じてアプリケーションの動作を制御する第２のモードとのいずれかを指定可能であり、当該有効期間情報として、第２のモードが指定されている場合、エンドユーザの操作に応じて、アプリケーションの動作を制御する。本技術は、例えば、地上波放送を受信可能なテレビ受像機などに適用することができる。

Description

本技術は、受信装置、送信装置、及び、データ処理方法に関し、特に、コンテンツに付随するアプリケーションの動作を、より柔軟に制御することができるようにした受信装置、送信装置、及び、データ処理方法に関する。
番組やCM等のコンテンツに付随するアプリケーション（以下、単にアプリケーションともいう）の配信ライフサイクルコントロールに、AIT(Application Information Table)等のアプリケーション制御情報を用いることが知られている（例えば、特許文献１参照）。このアプリケーション制御情報によって、受信機では、アプリケーションの起動や終了の動作を制御することができる。
特開２０１５−１８００６５号公報
ところで、AITは、送信側の送出タイミングにより、アプリケーションのライフサイクルを制御するため、エンドユーザの意志でアプリケーションの動作を制御するような柔軟性がなかった。そのため、アプリケーションの動作を、より柔軟に制御するための提案が要請されていた。
本技術はこのような状況に鑑みてなされたものであり、コンテンツに付随するアプリケーションの動作を、より柔軟に制御することができるようにするものである。
本技術の第１の側面の受信装置は、コンテンツを受信する受信部と、前記コンテンツに付随するアプリケーションが有効になる期間を示す有効期間情報に基づいて、前記アプリケーションの動作を制御する制御部とを備え、前記有効期間情報は、前記期間に応じて前記アプリケーションの動作を制御する第１のモードと、エンドユーザの意志に応じて前記アプリケーションの動作を制御する第２のモードとのいずれかを指定可能であり、前記制御部は、前記有効期間情報として、前記第２のモードが指定されている場合、前記エンドユーザの操作に応じて、前記アプリケーションの動作を制御する受信装置である。
本技術の第１の側面の受信装置は、独立した装置であってもよいし、１つの装置を構成している内部ブロックであってもよい。また、本技術の第１の側面のデータ処理方法は、上述した本技術の第１の側面の受信装置に対応するデータ処理方法である。
本技術の第１の側面の受信装置、及び、データ処理方法においては、コンテンツが受信され、前記コンテンツに付随するアプリケーションが有効になる期間を示す有効期間情報に基づいて、前記アプリケーションの動作が制御される。また、前記有効期間情報は、前記期間に応じて前記アプリケーションの動作を制御する第１のモードと、エンドユーザの意志に応じて前記アプリケーションの動作を制御する第２のモードとのいずれかを指定可能であり、前記有効期間情報として、前記第２のモードが指定されている場合、前記エンドユーザの操作に応じて、前記アプリケーションの動作が制御される。
本技術の第２の側面の送信装置は、コンテンツに付随するアプリケーションが有効になる期間を示す有効期間情報であって、前記期間に応じて前記アプリケーションの動作を制御する第１のモードと、エンドユーザの意志に応じて前記アプリケーションの動作を制御する第２のモードとのいずれかを指定可能な前記有効期間情報を生成する生成部と、前記コンテンツとともに、前記有効期間情報を送信する送信部とを備える送信装置である。
本技術の第２の側面の送信装置は、独立した装置であってもよいし、１つの装置を構成している内部ブロックであってもよい。また、本技術の第２の側面のデータ処理方法は、上述した本技術の第２の側面の送信装置に対応するデータ処理方法である。
本技術の第２の側面の送信装置、及び、データ処理方法においては、コンテンツに付随するアプリケーションが有効になる期間を示す有効期間情報であって、前記期間に応じて前記アプリケーションの動作を制御する第１のモードと、エンドユーザの意志に応じて前記アプリケーションの動作を制御する第２のモードとのいずれかを指定可能な前記有効期間情報が生成され、前記コンテンツとともに、前記有効期間情報が送信される。
本技術の第１の側面、及び、第２の側面によれば、コンテンツに付随するアプリケーションの動作を、より柔軟に制御することができる。
なお、ここに記載された効果は必ずしも限定されるものではなく、本開示中に記載されたいずれかの効果であってもよい。
本技術を適用した伝送システムの一実施の形態の構成例を示す図である。 クライアント装置の構成例を示す図である。 本技術のプロトコルスタックの構成例を示す図である。 シグナリングと、伝送ファイルとの関係を示す図である。 USBDメタデータのフォーマットの例を示す図である。 HLSTメタデータのフォーマットの例を示す図である。 アプリケーション対応処理の流れを説明するフローチャートである。 アプリケーション対応処理の流れを説明するフローチャートである。 HLSTメタデータ対応処理の流れを説明するフローチャートである。 アプリケーションを起動させるためのアイコンの表示例を示す図である。 アプリケーションを起動させるためのアイコンの表示例を示す図である。 コンテンツ対応処理の流れを説明するフローチャートである。 伝送システムの他の構成例を示す図である。 コンピュータの構成例を示す図である。
以下、図面を参照しながら本技術の実施の形態について説明する。なお、説明は以下の順序で行うものとする。
１．システムの構成
２．本技術の概要
３．シグナリングの具体的な内容
４．各装置で実行される処理の流れ
５．変形例
６．コンピュータの構成
＜１．システムの構成＞
（伝送システムの構成）
図１は、本技術を適用した伝送システムの一実施の形態の構成例を示す図である。なお、システムとは、複数の装置が論理的に集合したものをいう。
図１において、伝送システム１は、送信側システム１０と、受信側のクライアント装置２０から構成される。伝送システム１においては、送信側システム１０から送信されるデータが、放送伝送路３０を介してクライアント装置２０により受信される。
例えば、伝送システム１では、現在策定が進められている米国の次世代放送規格であるATSC(Advanced Television Systems Committee)3.0等の所定の規格に準拠したデータ伝送が行われる。
送信側システム１０は、所定の規格に準拠した伝送データを送信するための処理を行う。送信側システム１０は、DASHサーバ１０１、シグナリングサーバ１０２、アプリケーションサーバ１０３、SCH/PKGサーバ１０４、及び放送サーバ１０５から構成される。
DASHサーバ１０１は、MPEG-DASH(Dynamic Adaptive Streaming over HTTP)に対応した配信サービスを行うためのサーバである。DASHサーバ１０１は、外部からコンテンツのデータなどを受信する。DASHサーバ１０１は、外部からのデータに基づいて、番組やCM等のコンテンツのDASHセグメントのファイルを生成し、放送サーバ１０５に送信する。
シグナリングサーバ１０２は、外部から、シグナリングを生成するためのデータを受信する。シグナリングサーバ１０２は、外部からのデータに基づいて、シグナリングのファイルを生成し、放送サーバ１０５に送信する。
アプリケーションサーバ１０３は、外部からアプリケーションを生成するためのデータを受信する。アプリケーションサーバ１０３は、外部からのデータに基づいて、アプリケーションのファイルを生成し、SCH/PKGサーバ１０４に送信する。
なお、アプリケーションは、番組やCM等のコンテンツに付随するアプリケーションである。例えば、このようなアプリケーションとしては、HTML5(HyperText Markup Language 5)等のマークアップ言語や、JavaScript（登録商標）等のスクリプト言語で開発されたアプリケーションを用いることができる。
SCH/PKGサーバ１０４は、アプリケーションを構成するファイル（パッケージファイル）の配信スケジュールを決定する。また、SCH/PKGサーバ１０４は、配信スケジュールに応じて、アプリケーションのパッケージファイルと、アプリケーション制御情報（後述のHLSTメタデータ）を生成し、放送サーバ１０５に送信する。
なお、パッケージファイルには、例えば、HTML文書ファイル等のエントリページファイルや、画像ファイルやスクリプトファイル等のリソースファイルなどが含まれる。
放送サーバ１０５は、DASHサーバ１０１からのDASHセグメントのファイル、シグナリングサーバ１０２からのシグナリングのファイル、及び、SCH/PKGサーバ１０４からのアプリケーションのファイル（パッケージファイル）を受信する。放送サーバ１０５は、DASHセグメント、シグナリング、及び、アプリケーションのファイルを処理し、その結果得られる多重化ストリームを、放送波として、放送伝送路３０を介して送信する。
なお、SCH/PKGサーバ１０４からのアプリケーション制御情報（後述のHLSTメタデータ）は、シグナリングとして、多重化ストリームに含められる。
クライアント装置２０は、所定の規格に準拠した伝送データを受信可能な受信機である。例えば、クライアント装置２０は、テレビ受像機やセットトップボックス（STB：Set Top Box）などの固定受信機、あるいは、スマートフォンや携帯電話機、タブレット型コンピュータなどのモバイル受信機である。また、クライアント装置２０は、例えば車載テレビなどの自動車に搭載される機器であってもよい。なお、クライアント装置２０の詳細な構成は、図２を参照して後述する。
クライアント装置２０は、放送サーバ１０５から、放送伝送路３０を介して送信されてくる放送波を受信し、放送波に含まれる多重化ストリームからDASHセグメントやシグナリングのファイルなどのデータを抽出して処理することで、番組やCM等のコンテンツの映像や音声を再生する。
また、クライアント装置２０は、放送サーバ１０５から送信されてくるアプリケーションのファイルを処理することで、再生中のコンテンツに付随して、アプリケーションを起動（実行）することができる。ただし、アプリケーションは、何らかの情報を明示的に表示するだけでなく、非表示で（バックグラウンドで）動作する場合もある（エンドユーザに認識されずに起動することがある）。
なお、伝送システム１において、放送伝送路３０は、地上波（地上波放送）のほか、例えば、放送衛星（BS：Broadcasting Satellite）や通信衛星（CS：Communications Satellite）を利用した衛星放送、あるいは、ケーブルを用いた有線放送（CATV）などであってもよい。
また、図１の伝送システム１においては、説明を簡単にするために、クライアント装置２０を１つだけ図示しているが、クライアント装置２０は複数設けることができ、送信側システム１０が送信（一斉同報配信）する放送波は、放送伝送路３０を介して複数のクライアント装置２０で同時に受信することができる。
また、送信側システム１０も複数設けることができる。複数の送信側システム１０のそれぞれでは、別個のサービス（チャネル）としての、例えば、別個の周波数帯域で、多重化ストリームを含む放送波を送信し、クライアント装置２０では、複数の送信側システム１０のそれぞれのサービス（チャネル）の中から、多重化ストリームを受信するサービスを選択（選局）することができる。
（クライアント装置の構成）
図２は、図１のクライアント装置２０の構成例を示す図である。
図２において、クライアント装置２０は、制御部２０１、入力部２０２、メモリ２０３、受信部２０４、放送ミドルウェア２０５、DASHクライアント２０６、デコーダ２０７、出力部２０８、ブラウザ２０９、及びストレージ２１０から構成される。
制御部２０１は、例えば、CPU(Central Processing Unit)やマイクロプロセッサ等から構成される。制御部２０１は、クライアント装置２０の各部の動作を制御する。
入力部２０２は、例えば、入力インターフェース回路等から構成される。入力部２０２は、エンドユーザの操作に応じた操作信号を、制御部２０１に供給する。制御部２０１は、入力部２０２からの操作信号に基づいて、各部の動作を制御する。
メモリ２０３は、例えば、NVRAM(Non-Volatile RAM)等の半導体メモリから構成される。メモリ２０３は、制御部２０１からの制御に従い、各種のデータを記憶する。
受信部２０４は、例えば、チューナやデモジュレータ等から構成される。受信部２０４は、アンテナを介して受信された放送波に対し、復調処理を行い、その結果得られる多重化ストリームを、放送ミドルウェア２０５に供給する。
放送ミドルウェア２０５は、制御部２０１からの制御に従い、受信部２０４から供給される多重化ストリームを処理し、その結果得られるデータを、DASHクライアント２０６又はブラウザ２０９に供給する。
ここでは、処理対象のデータのうち、DASHセグメントファイルは、DASHクライアント２０６に供給され、アプリケーションのファイル（パッケージファイル）は、ブラウザ２０９に供給される。また、処理対象のデータのうち、シグナリングのファイルは、制御部２０１又は放送ミドルウェア２０５により処理される。
DASHクライアント２０６は、制御部２０１からの制御に従い、放送ミドルウェア２０５から供給されるDASHセグメントファイルを処理し、その結果得られるビデオやオーディオのデータを、デコーダ２０７に供給する。
デコーダ２０７は、例えば、デコーダ回路等から構成される。デコーダ２０７は、所定の復号方式に従い、DASHクライアント２０６から供給されるデータをデコードし、その結果得られるビデオやオーディオのデータを出力部２０８に供給する。
出力部２０８は、例えば、出力インターフェース回路等から構成される。出力部２０８は、デコーダ２０７から供給されるデータを処理し、表示装置やスピーカなどに出力する。これにより、クライアント装置２０では、コンテンツが再生され、その映像や音声が出力される。
ブラウザ２０９は、例えば、HTML5に対応したブラウザである。ブラウザ２０９は、制御部２０１からの制御に従い、放送ミドルウェア２０５から供給されるアプリケーションのファイル（パッケージファイル）を処理し、その結果得られるデータを、出力部２０８に供給する。
出力部２０８は、ブラウザ２０９から供給されるデータを処理し、表示装置などに出力する。これにより、クライアント装置２０では、コンテンツの映像に付随して、アプリケーションの映像が表示される。
ストレージ２１０は、例えば、HDD(Hard Disk Drive)や半導体メモリ等の大容量の記憶装置である。ストレージ２１０は、制御部２０１からの制御に従い、各種のデータを蓄積する。
なお、図２のクライアント装置２０において、放送ミドルウェア２０５、DASHクライアント２０６、及びブラウザ２０９の機能（の全部又は一部）は、例えば、CPUからなる制御部２０１が、メモリ２０３に記憶された所定のプログラムを実行することで実現されるようにすることができる。また、DASHクライアント２０６とデコーダ２０７の機能や、レンダリングの機能は、ブラウザ２０９が有するようにしてもよい。
また、図２においては、クライアント装置２０が、LCD(Liquid Crystal Display)やOELD(Organic Electroluminescence Display)等のディスプレイや、スピーカを有するようにして、出力部２０８からのデータに応じた映像や音声を出力するようにしてもよいし、外部の表示装置や外部のスピーカに対し、出力部２０８からのデータが出力されるようにしてもよい。
＜２．本技術の概要＞
本技術では、データの伝送方式として、現在広く普及しているMPEG2-TS(Transport Stream)方式ではなく、通信の分野で用いられているIP(Internet Protocol)パケットをデジタル放送に用いたIP伝送方式を導入することで、より高度なサービスを提供することができるようにする。なお、次世代放送規格の１つであるATSC3.0においても、IP伝送方式の採用が想定されている。
（本技術のプロトコルスタック）
図３は、本技術のIP伝送方式のプロトコルスタックの例を示す図である。
図３において、最も下位の階層は、物理層（Physical Layer）とされる。ATSC3.0等のIP伝送方式のデジタル放送では、一方向の放送を利用した伝送に限らず、一部のデータを、双方向の通信を利用して伝送する場合があるが、放送（Broadcast）を利用する場合、その物理層（Physical Layer）は、サービス（チャネル）のために割り当てられた放送波の周波数帯域が対応することになる。
物理層（Physical Layer）の上位の階層は、データリンク層（Data Link Layer）とされる。また、データリンク層の上位の階層は、IP(Internet Protocol)層とUDP(User Datagram Protocol)層とされる。IP層とUDP層は、通信の階層モデルにおけるネットワーク層とトランスポート層に相当する層であり、IPアドレスとポート番号により、IPパケットとUDPパケットが特定される。
ここで、ATSC3.0では、シグナリングとして、LLS(Low Level Signaling)とSLS(Service Layer Signaling)を用いることが想定されている。LLSは、SLSよりも下位の層で伝送されるシグナリングである。SLSは、サービス単位のシグナリングである。すなわち、ATSC3.0では、トランスポート層のシグナリングが、LLSとSLSの２階層で伝送される。
LLSは、UDP/IPパケットに格納されて伝送される。LLSには、SLT(Service List Table)等のメタデータが含まれる。SLTメタデータは、サービス（チャネル）の選局に必要な情報など、放送ネットワークにおけるストリームやサービスの構成を示す基本情報を含む。このSLTメタデータは、UDPパケットを含むIPパケットであるUDP/IPパケットに含めて伝送される。ただし、SLTメタデータを格納したUDP/IPパケットは、特別なIPアドレスとポート番号で伝送されることになる。
IP層とUDP層に隣接する上位の階層は、ROUTE(Real-time Object Delivery over Unidirectional Transport)とされる。ROUTEは、ストリーミングファイル転送用のプロトコルであって、FLUTE(File Delivery over Unidirectional Transport)を拡張したものである。
このROUTEセッションにより、サービスごとに、SLSのファイル（Signaling）や、NRT(Non Real Time)コンテンツのファイル（NRT）、DASHセグメントファイル（DASH）などが伝送される。
ここで、SLSは、サービスレベルのシグナリングであり、対象のサービスに属するコンポーネントの探索と選択に必要な情報や属性などを提供するものである。SLSは、USBD(User Service Bundle Description)，S-TSID(Service-based Transport Session Instance Description)，HLST(HTML pages entry Location Signaling Table)，MPD(Media Presentation Description)等のメタデータを含む。
USBDメタデータは、他のメタデータの取得先などの情報を含む。なお、USBDメタデータの詳細は、図５を参照して後述する。
S-TSIDメタデータは、LSID(LCT Session Instance Description)をATSC3.0向けに拡張したものであって、ROUTEプロトコルの制御情報である。また、S-TSIDメタデータは、ROUTEセッションで伝送されるEFDT(Extended FDT)を特定することができる。EFDTは、FLUTEで導入されていたFDT(File Delivery Table)を拡張したものであって、転送用の制御情報である。
HLSTメタデータは、コンテンツに付随するアプリケーションの起動（動作）を制御する制御情報である。なお、HLSTメタデータの詳細は、図６を参照して後述する。
MPDメタデータは、MPEG-DASHに準拠したストリーミング配信を行うために用いられる、ビデオやオーディオのファイルの制御情報である。ここで、MPEG-DASHは、OTT-V(Over The Top Video)に従ったストリーミング配信規格であって、HTTP(Hypertext Transfer Protocol)をベースとしたストリーミングプロトコルを用いたアダプティブストリーミング配信に関する規格である。
このMPEG-DASHの規格では、ビデオやオーディオのファイルの制御情報であるメタデータを記載するためのマニフェストファイルと、動画のコンテンツを伝送するためのファイルフォーマットが規定されている。ここでは、前者のマニフェストファイルが、MPD(Media Presentation Description)と称され、後者のファイルフォーマットは、セグメントフォーマットとも称される。
また、トランスポート・プロトコルとして、ROUTEを用いる場合には、ストリーミングのファイルフォーマットとして、MP4ファイルフォーマットを用いることができる。MP4ファイルフォーマットは、ISO/IEC 14496-12で規定されているISO BMFF(ISO Base Media File Format)の派生フォーマットである。
ROUTEセッションで伝送されるセグメントは、イニシャライゼイションセグメント（IS：Initialization Segment）と、メディアセグメント（MS：Media Segment）から構成される。イニシャライゼイションセグメントは、データ圧縮方式等の初期化情報を含んでいる。また、メディアセグメントは、ビデオやオーディオ、字幕のストリームのデータを格納している。すなわち、このメディアセグメントが、DASHセグメント（DASHセグメントファイル）に相当するものである。
このように、番組等のコンテンツを構成するサービスコンポーネント（ビデオやオーディオ、字幕等）のストリームデータは、ISO BMFFの規格に準じたDASHセグメント単位で、ROUTEセッションにより伝送されることになる。
なお、NRTコンテンツは、受信機のストレージに一旦蓄積された後で再生が行われる。また、NRTコンテンツ以外のファイル（例えば、アプリケーションや電子サービスガイド（ESG：Electronic Service Guide）のファイル）がROUTEセッションで伝送されるようにしてもよい。
また、LLSとしてのSLTメタデータや、SLSとしてのUSBD，S-TSID，HLST，MPD等のメタデータは、例えば、XML(Extensible Markup Language)等のマークアップ言語により記載されたテキスト形式のデータとすることができる。
一方で、双方向の通信（Broadband）を利用する場合、その物理層（Physical Layer）の上位の階層は、データリンク層（Data Link Layer）とされる。また、データリンク層の上位の階層は、ネットワーク層に相当するIP層とされる。IP層に隣接する上位階層は、トランスポート層に相当するTCP(Transmission Control Protocol)層とされ、さらに、TCP層に隣接する上位階層は、アプリケーション層に相当するHTTP層とされる。
すなわち、これらの階層によって、インターネット等の通信回線（例えば、後述の通信伝送路４０（図１３））で稼働するTCP/IPなどのプロトコルが実装される。
HTTP層に隣接する上位階層のうち、一部の階層は、シグナリング（Signaling）と、NRTコンテンツ（NRT）とされる。このシグナリングとしては、上述したROUTEセッションで伝送されるシグナリングなど、すべてのシグナリングが含まれる。また、NRTコンテンツは、通信経由で取得されるコンテンツであって、例えば、アプリケーションが含まれる。
HTTP層に隣接する上位階層のうち、上述した階層以外の他の階層は、DASHセグメント（DASH）とされる。すなわち、双方向の通信系のストリーミング配信では、VOD(Video On Demand)番組等のコンテンツを構成するサービスコンポーネント（ビデオやオーディオ、字幕等）のストリームデータが、ISO BMFFの規格に準じたDASHセグメント単位で伝送されることになる。
以上のように、本技術のIP伝送方式のプロトコルスタックにおいては、一方向の放送系の階層と、双方向の通信系の階層の一部が共通のプロトコルとなって、一方向の放送と双方向の通信で、コンテンツを構成するサービスコンポーネントのストリームデータを、ISO BMFFの規格に準じたDASHセグメント単位で伝送することができる。
そのため、一方向の放送系のストリーミング配信と、双方向の通信系のストリーミング配信の双方を行う場合において、上位の階層のプロトコルが共通化されているため、例えば、放送サーバ１０５やクライアント装置２０では、実装の負担や処理の負担を軽減することができる。
（シグナリングと伝送ファイルとの関係）
図４は、シグナリングと、伝送ファイルとの関係を示す図である。
図４に示すように、クライアント装置２０では、SLSに先行して、LLSとして伝送されるSLTメタデータ（のファイル）が取得される。そして、クライアント装置２０は、エンドユーザにより選局操作が行われた場合などに、先行して取得していたSLTメタデータに基づいて、サービス単位で伝送されるSLSのメタデータ（のファイル）を取得することになる。
すなわち、ROUTEセッションのSLSチャネルでは、USBD，S-TSID，HLST等のメタデータが伝送されている。クライアント装置２０では、SLSチャネルで伝送される他のメタデータに先行して、USBDメタデータを取得することで、当該USBDメタデータに記述された他のメタデータの取得先を示す情報（URL）に従い、S-TSIDメタデータやHLSTメタデータを取得することができる。
また、ROUTEセッションにおいては、S-TSIDメタデータに記述されたLCTチャネル（セッション）の１つが、NRTチャネルとして、ノンリアルタイムコンテンツであるNRTの転送に割り当てられている。また、NRTチャネルにおいては、EFDTにより、そのチャネルで転送するファイル群の転送制御パラメタが記述されている。
クライアント装置２０は、EFDTの転送制御パラメタに従い、ROUTEセッションのNRTチャネルで伝送されるパッケージファイルを取得することができる。このパッケージファイルには、コンテンツに付随するアプリケーションを構成するファイル群が含まれる。例えば、パッケージファイルには、HTML文書ファイル等のエントリページのファイルや、画像ファイルやスクリプトファイル等のリソースファイルが格納される。
ところで、HLSTメタデータは、アプリケーションの起動を周知するためのテーブルである。HLSTメタデータは、自身が流されているコンテンツに付随するアプリケーションの有効期間情報（図６のEntryLocation要素のvalidFrom属性とvalidUntil属性）を含むが、当該アプリケーションが取得可能になる期間を、取得期間情報（図６のDistribtuionWindow要素）として追加できるようにする提案がある。
通常、このDistribtuionWindow要素が示す期間は、同一番組の時間内に収まっていることが期待されるが、DistribtuionWindow要素に記述される取得期間を、対象のHLSTメタデータが流れている番組とは異なる時間帯（例えば、今晩の夜中）などに指定できるようにして、番組外の時間帯で、スケジュールダウンロード（Scheduled Download）的な機能として使えるようにすることもできる。
例えば、validFrom属性とvalidUntil属性により指定可能な期間として、明日の時間を指摘できるようにすることで、帯ドラマ形式の連続ドラマのような、今日と同じ時間帯で、明日も放送される番組シリーズの「明日」に使うであろうアプリケーションを、今晩のうちに放送して、クライアント装置２０に取得させておくといった運用が可能となる。
しかしながら、現状のHLSTメタデータには、番組内、あるいは番組外の時間帯に配信されるアプリケーションを、エンドユーザの意のままに、エンドユーザが再生したいと思った、番組とは独立した時間帯に、起動や再生、停止をさせるような柔軟性がない。
すなわち、例えば、クライアント装置２０が、スマートフォンやタブレット型コンピュータ等のモバイル受信機となる場合に、それらのモバイル受信機で実行されるアプリケーションのような、番組とは独立した起動制御エントリを定義することができないため、アプリケーションの動作を、より柔軟に制御することができるようにするための提案が要請されていた。
そこで、本技術では、HLSTメタデータに、エンドユーザの意志に応じて、アプリケーションの動作を制御することができるモードを指定可能にすることで、エンドユーザの操作に応じて、アプリケーションを動作させることができるようにする。
すなわち、上述の例によれば、HLSTメタデータで指定される、アプリケーションの有効期間（EntryLocation要素のvalidFrom属性とvalidUntil属性）は、例えば、帯ドラマ形式の連続ドラマで毎日同じ時間に放送される番組であれば、明日の同じ時間帯を指定し、通常は、この有効期間を過ぎてしまえば、対象のアプリケーションは即時に削除されることになる。
一方で、本技術では、対象のアプリケーションを、有効期間が過ぎても、すぐには削除せずに、例えば、EntryLocation要素のvalidFrom属性に、"*"などの特定のキーワードを指定することにより、エンドユーザの意志に応じて、アプリケーションの動作を制御できるモードとなるようにする。
つまり、HLSTメタデータのEntryLocation要素のvalidFrom属性に、"*"が指定された場合には、コンテンツに付随したアプリケーションを、いわば、インストールアプリケーションのように使用することが可能となり、当該アプリケーションの削除は、エンドユーザの意志に委ねられることになる。
逆に、EntryLocation要素のvalidFrom属性に、何も指定せずに、DistribtuionWindow要素（StartTime要素とEndTime要素）で、その番組時間以外の未来の時間が指定されている場合には、当該DistribtuionWindow要素に指定された取得期間に、アプリケーションを取得することになる。
そして、当該アプリケーションの動作（起動や停止）の制御は、新たにその後に送られてくる（いつかそう遠くない未来に送られてくる）HLSTメタデータのうち、同一のEntryLocation要素の値を有しているHLSTメタデータにより行うようにする。このとき、EntryLocation要素のvalidFrom属性に、"*"を指定した場合と異なり、アプリケーションの動作の制御は、エンドユーザの意志に委ねないことを指示することができる。
また、HLSTメタデータに、DistribtuionWindow要素の指定がない場合には、当該HLSTメタデータが流れている間は、常に、対象のアプリケーションが流れているものとし、クライアント装置２０では、任意のタイミングで、対象のアプリケーションが取得される。
さらに、当該HLSTメタデータに、EntryLocation要素のvalidFrom属性とvalidUntil属性の指定がない場合には、対象のアプリケーションの動作（起動や再生、停止）のタイミングは、例えば、次に示すようなタイミングとなる。すなわち、後日などに、新たにその後送られてくるHLSTメタデータのうち、同一のEntryLocation要素の値を有しているHLSTメタデータのEntryLocation要素のvalidFrom属性とvalidUntil属性の値により指定されるものとする。
なお、HLSTメタデータにおいて、EntryLocation要素のvalidUntil属性には、"*"がデフォルトで指定されているものとする。すなわち、仮に、EntryLocation要素のvalidFrom属性とvalidUntil属性が指定されていない対象のアプリケーションが、DistribtuionWindow要素による指定のもとに、スケジュール配信されたにもかかわらず、例えば、同一のサービスに再度選局する機会を逸したりすることで、対象のHLSTメタデータが永遠に取得されずに、当該アプリケーションの動作の制御が永遠に行われないことを避けるためである。
すなわち、EntryLocation要素のvalidUntil属性に、"*"を指定することで、エンドユーザの意志でアプリケーションを削除できる、あるいはクライアント装置２０の判断で自由にアプリケーションを削除できるモードを意味することになる。
＜３．シグナリングの具体的な内容＞
次に、図５及び図６を参照して、ROUTEセッションで伝送されるSLSのうち、USBDメタデータとHLSTメタデータの構造について説明する。
（USBDメタデータの構造の例）
図５は、USBDメタデータのフォーマットの例を示す図である。
なお、図５において、要素と属性のうち、属性には「@」が付されている。また、インデントされた要素と属性は、その上位の要素に対して指定されたものとなる。これらの関係は、後述する図６でも同様とされる。
bundleDescription要素は、ルート要素であって、userServiceDescription要素の上位要素となる。
userServiceDescription要素は、globalServiceID属性、serviceId属性、serviceStatus属性、fullMPDUri属性、sTSIDUri属性、hlstUri属性、name要素、serviceLanguage要素、及びdeliveryMethod要素の上位要素となる。
globalServiceID属性には、グローバルサービスIDが指定される。serviceId属性には、サービスIDが指定される。serviceStatus属性には、サービスのステータスに関する情報が指定される。
fullMPDUri属性には、MPDメタデータを参照するためのURI(Uniform Resource Identifier)が指定される。sTSIDUri属性には、S-TSIDメタデータを参照するためのURIが指定される。hlstUri属性には、HLSTメタデータを参照するためのURIが指定される。
name要素には、ATSC3.0のサービスの名称が指定される。name要素は、lang属性の上位要素となる。lang属性には、ATSC3.0のサービスの名称の言語が指定される。serviceLanguage要素には、ATSC3.0のサービスで利用できる言語が指定される。
deliveryMethod要素には、データの配信方法に関する情報が指定される。deliveryMethod要素は、apdUri属性、broadcastAppService要素、及びunicastAppService要素の上位要素となる。
apdUri属性には、SLSとして、APD(Associated Procedure Description)メタデータを伝送する場合に、その参照先を示すURIが指定される。
broadcastAppService要素は、basePattern要素の上位要素であって、放送経由での配信に関する情報が指定される。unicastAppService要素は、basePattern要素の上位要素であって、通信経由での配信に関する情報が指定される。
なお、USBDメタデータの詳細については、下記の非特許文献１の「Table 7.1 Semantics of the User Service Bundle Description Fragment for ROUTE/DASH」にその詳細な内容が記載されている。
非特許文献１：ATSC Candidate Standard：Signaling, Delivery, Synchronization, and Error Protection(A/331) Doc. S33-174r15 January 2016
（HLSTメタデータの構造の例）
図６は、HLSTメタデータのフォーマットの例を示す図である。
HLST要素は、ルート要素であって、HTMLEntryPage要素の上位要素となる。
HTMLEntryPage要素は、HTML形式のエントリページのプロパティを含む。HTMLEntryPage要素は、requiredCapabilities属性、linearSvcEnabling属性、coupledServices属性、及びEntryLocation要素の上位要素となる。
requiredCapabilities属性には、クライアント装置２０の機能が、エントリページを処理するために必要な機能にマッチしているかどうかを判別するための情報が指定される。
linearSvcEnabling属性には、アプリケーションが、ビデオのデータをレンダリングする際の要件に関する情報が指定される。coupledServices属性には、アプリケーションを共有するサービスに関する情報が指定される。
EntryLocation要素には、エントリロケーションに関する情報が指定される。EntryLocation要素は、entryURL要素、alternateEntryURL要素、validFrom属性、validUntil属性、及びDistribtuionWindow要素の上位要素となる。
entryURL要素には、アプリケーションのエントリポイントを示すURL(Uniform Resource Locator)が指定される。alternateEntryURL要素には、アプリケーション（のHTMLページ）の代替のパスが指定される。
validFrom属性には、アプリケーション（のHTMLページ）が有効となる期間の開始の時刻を示す開始時刻情報が指定される。この開始時刻情報には、アプリケーション（のHTMLページ）の表示を開始するタイミングが日時（dateTime型）で指定される。
validUntil属性には、アプリケーション（のHTMLページ）が有効となる期間の終了の時刻を示す終了時刻情報が指定される。この終了時刻情報には、アプリケーション（のHTMLページ）の表示を終了するタイミングが日時（dateTime型）で指定される。
すなわち、EntryLocation要素においては、validFrom属性により指定される開始時刻と、validUntil属性により指定される終了時刻により、コンテンツに付随するアプリケーション（のHTMLページ）が有効になる期間（有効期間）が指定されることになる。
ここで、validFrom属性に、特定のキーワードが指定された場合には、エンドユーザの意思に応じて、対象のアプリケーションの動作を制御できるモードとなる。この場合、アプリケーションの起動や停止、削除などの動作は、エンドユーザの意思に委ねられ、コンテンツに付随したアプリケーションを、いわば、インストールアプリケーションのように使用することが可能となる。
validFrom属性に指定される特定のキーワードとしては、例えば、"*"（アスタリスク）などの特別な記号を用いることができる。ただし、validFrom属性やvalidUntil属性のデータタイプは、dateTime型となるので、例えば、"*"を示す値を、"9999-12-31 23:59:59.999"のように定義するものとする。また、validUntil属性には、デフォルトで、"*"などの特定のキーワードが指定されているものと解釈することもできる。
DistribtuionWindow要素には、アプリケーションの配信スケジュールに関する情報が指定される。DistribtuionWindow要素は、StartTime要素及びEndTime要素の上位要素となる。
StartTime要素には、アプリケーションの配信期間の開始の時刻を示す開始時刻情報が指定される。EndTime要素には、アプリケーションの配信期間の終了の時刻を示す終了時刻情報が指定される。StartTime要素とEndTime要素には、例えば、NTP(Network Time Protocol)のタイムスタンプの32ビットの整数部分（Integer Part）を指定することができる。
すなわち、DistribtuionWindow要素においては、StartTime要素により指定される開始時刻と、EndTime要素により指定される終了時刻により、アプリケーションが配信される期間（取得可能になる期間）が指定されることになる。
以上のような構造からなるHLSTメタデータは、１つのアプリケーションを、１つのコンテンツに対して付随させるための情報とすることができる。
例えば、HLSTメタデータを、アプリケーションと番組に対し、１対１で紐付けて、紐付けられた番組よりもはやく、クライアント装置２０により取得されるようにすることで、当該HLSTメタデータが示す有効期間内でのみ、紐付けられたアプリケーションが起動されるようにすることが可能となる。そのため、HLSTメタデータと、番組と、アプリケーションを１つのまとまりとして取り扱うことができ、前後に再生される他の番組やアプリケーションの影響を受けずに処理を行うことができる。
なお、アプリケーション制御情報として知られているAITは、その送出のタイミングにより、アプリケーションのライフサイクルを制御しているため、時系列での連続性を必要とする。そのため、AITを用いる場合には、例えば、対象のアプリケーションを起動させるために、実行中の前のアプリケーションを終了させるなどの過渡的な処理が必要で、放送局側で、番組の進行と、AITによるアプリケーションの動作の制御を全体に渡って管理する必要があり、管理が煩雑になってしまう。一方で、本技術においては、１つのHLSTメタデータを独立させることで、他のアプリケーションや他の番組とは関係がなくなるようにすることができるため、放送局側ではその管理が容易であり、結果として、アプリケーションの動作を容易に制御することが可能となる。
なお、図５及び図６において、「Use」の項目であるが、"1"が指定された場合にはその要素又は属性は必ず１つだけ指定され、"1..N"が指定された場合には、その要素又は属性は、１以上指定される。また、"Cardinality"として、"0..1"が指定された場合には、その要素又は属性を指定するかどうかは任意であり、"0..N"が指定された場合には、その要素又は属性を１以上指定するかどうかは任意である。
また、「Data Type」の項目であるが、"anyURI"が指定された場合、その要素又は属性が、URLの形式をした文字列を表し、"unsignedShort"や"unsignedInt"が指定された場合、その要素又は属性の値が、整数型であることを示している。また、"boolean"が指定された場合、その要素又は属性がブール型であることを示し、string"が指定された場合には、その要素又は属性の値が、文字列型であることを示している。さらに、"dateTime"が指定された場合には、その要素又は属性が、特定の日時を表すことを示している。
なお、上述した図５や図６に示したUSBDメタデータや、HLSTメタデータのフォーマットは一例であって、例えば、XML形式の以外の他の形式を採用することもできる。また、USBDメタデータや、HLSTメタデータは、テキスト形式に限らず、バイナリ形式であってもよい。
＜４．各装置で実行される処理の流れ＞
次に、図７乃至図１２を参照して、図１の伝送システム１における、送信側システム１０とクライアント装置２０で実行される処理の流れを説明する。
図１の伝送システム１において、送信側システム１０とクライアント装置２０で処理されるデータとしては、主に、コンテンツに関するデータと、アプリケーションに関するデータがある。そこで、ここでは、まず、図７乃至図１１を参照しながら、アプリケーションに関するデータに対する処理を中心としたアプリケーション対応処理を説明し、その後、図１２を参照しながら、コンテンツに関するデータに対する処理を中心としたコンテンツ対応処理について説明する。
（アプリケーション対応処理）
まず、図７及び図８のフローチャートを参照して、送信側システム１０とクライアント装置２０で実行されるアプリケーション対応処理の流れを説明する。
図７のステップＳ１１１の処理は、アプリケーションサーバ１０３（図１）により実行される。
ステップＳ１１１において、アプリケーションサーバ１０３は、アプリケーションのオーサリング処理を行い、アプリケーション（のファイル）を生成する。アプリケーションサーバ１０３により生成されたアプリケーションは、SCH/PKGサーバ１０４に送信される。
このオーサリング処理では、エントリページファイルや、１又は複数のリソースファイルなどのファイル群から構成されるアプリケーションが生成される。例えば、アプリケーションが、HTML5やJavaScript（登録商標）で開発される場合、エントリページファイルは、HTML文書ファイルなどからなり、リソースファイルは、画像ファイルやスクリプトファイルなどからなる。
図７のステップＳ１２１乃至Ｓ１２４の処理は、SCH/PKGサーバ１０４（図１）により実行される。SCH/PKGサーバ１０４においては、アプリケーションサーバ１０３により生成されたアプリケーション（のファイル）が受信される。
ステップＳ１２１において、SCH/PKGサーバ１０４は、アプリケーションを構成するファイル群の配信のスケジューリング処理を行い、配信スケジュールを決定する。
ステップＳ１２２において、SCH/PKGサーバ１０４は、ステップＳ１２１の処理で決定された配信スケジュールに従い、HLSTメタデータを生成する。SCH/PKGサーバ１０４により生成されたHLSTメタデータは、放送サーバ１０５に送信される。
ステップＳ１２３において、SCH/PKGサーバ１０４は、ステップＳ１２１の処理で決定された配信スケジュールに従い、EFDTを生成する。SCH/PKGサーバ１０４により生成されたEFDTは、放送サーバ１０５に送信される。
ステップＳ１２４において、SCH/PKGサーバ１０４は、アプリケーションサーバ１０３により生成されたアプリケーションを構成するファイル群のパッケージング処理を行い、パッケージファイルを生成する。SCH/PKGサーバ１０４により生成されたアプリケーションのパッケージファイルは、放送サーバ１０５に送信される。
このパッケージング処理では、例えば、HTML文書ファイル等のエントリページファイルや、画像ファイルやスクリプトファイル等のリソースファイルがパッケージングされ、パッケージファイルが生成される。
図７のステップＳ１３１乃至Ｓ１３２の処理は、放送サーバ１０５（図１）により実行される。放送サーバ１０５においては、SCH/PKGサーバ１０４により生成されたHLSTメタデータ、EFDT、及びアプリケーションのパッケージファイルが受信される。
ステップＳ１３１において、放送サーバ１０５は、SCH/PKGサーバ１０４により生成されたHLSTメタデータを含むシグナリングを処理し、放送波として、放送伝送路３０を介して送信する。
ステップＳ１３２において、放送サーバ１０５は、SCH/PKGサーバ１０４により生成されたEFDTと、アプリケーションのパッケージファイルを処理し、放送波として、放送伝送路３０を介して送信する。
図７及び図８のステップＳ２１１乃至２２０の処理は、クライアント装置２０の放送ミドルウェア２０５により実行され、図８のステップＳ２３１乃至Ｓ２３４の処理は、クライアント装置２０のブラウザ２０９により実行される。クライアント装置２０の受信部２０４では、放送サーバ１０５から送信されてくる放送波が受信される。
ステップＳ２１１において、放送ミドルウェア２０５は、多重化ストリームから得られるシグナリングを処理する。ここでは、シグナリングとして、LLSやSLSが取得され、処理される。例えば、放送ミドルウェア２０５は、ROUTEセッションでSLSとして伝送されるHLSTメタデータをパースし、その解析結果に従い、アプリケーションに関する処理を行う。なお、放送ミドルウェア２０５は、ROUTEセッションで伝送されるS-TSIDメタデータの解析結果に従い、EFDTを取得することができる。
ステップＳ２１２において、放送ミドルウェア２０５は、HLSTメタデータの解析結果が、アプリケーションを取得すべきタイミングを示している場合、ROUTEセッションで伝送されるEFDTをパースし、その解析結果に従い、アプリケーションのパッケージファイルを取得する。このようにして得られるアプリケーションのファイルは、ストレージ２１０に蓄積される。
なお、放送ミドルウェア２０５は、蓄積されたアプリケーションのリスト（蓄積済みアプリリスト）を管理しており、アプリケーションがストレージ２１０に蓄積された場合には、当該アプリケーションを示す情報（エントリロケーション）を、蓄積済みアプリリストに追加する。このエントリロケーションは、例えば、エントリページを示すURLなどとすることができる。
ステップＳ２１４において、放送ミドルウェア２０５は、HLSTメタデータの解析結果に従い、validFrom属性とvalidUntil属性が、時刻指定と、"*"指定のいずれかであるかを判定する。
ステップＳ２１４において、validFrom属性とvalidUntil属性の指定が時刻指定であると判定された場合、処理は、ステップＳ２１５に進められる。ステップＳ２１５において、放送ミドルウェア２０５は、HLSTメタデータの解析結果に従い、validFrom属性が示す時刻に、ストレージ２１０に蓄積されたアプリケーションが起動されるように、ブラウザ２０９に対して指示する。
ステップＳ２３１において、ブラウザ２０９は、放送ミドルウェア２０５からの指示に従い、HLSTメタデータのvalidFrom属性が示す時刻になったとき、ストレージ２１０に蓄積されたアプリケーションを起動する。これにより、アプリケーションが起動され、コンテンツに付随して実行されることになる。
ステップＳ２１６において、放送ミドルウェア２０５は、HLSTメタデータの解析結果に従い、validUntil属性が示す時刻に、起動中のアプリケーションが停止されるように、ブラウザ２０９に対して指示する。
ステップＳ２３２において、ブラウザ２０９は、放送ミドルウェア２０５からの指示に従い、HLSTメタデータのvalidUntil属性が示す時刻になったとき、起動中のアプリケーションを停止する。
ステップＳ２３２の処理でアプリケーションが停止されると、ステップＳ２１７の処理が行われる。すなわち、ステップＳ２１７において、放送ミドルウェア２０５は、停止されたアプリケーションのファイルを、ストレージ２１０から削除する。
なお、このとき、放送ミドルウェア２０５は、蓄積済みアプリリストから、停止されたアプリケーションを示す情報（エントリロケーション）を削除する。
ステップＳ２１７，Ｓ２３２の処理が終了すると、validFrom属性とvalidUntil属性が、時刻指定となる場合における、アプリケーション対応処理は、終了される。
一方で、ステップＳ２１４において、validFrom属性とvalidUntil属性の指定が、"*"指定であると判定された場合、処理は、ステップＳ２１８に進められる。ステップＳ２１８において、放送ミドルウェア２０５は、エンドユーザの操作に応じて、ストレージ２１０に蓄積されたアプリケーションが起動されるように、ブラウザ２０９に対して指示する。
ステップＳ２３３において、ブラウザ２０９は、放送ミドルウェア２０５からの指示に従い、エンドユーザにより起動が指示されたとき、ストレージ２１０に蓄積されたアプリケーションを起動する。これにより、アプリケーションが起動され、コンテンツに付随して実行されることになる。
ステップＳ２１９において、放送ミドルウェア２０５は、エンドユーザの操作に応じて、起動中のアプリケーションが停止されるように、ブラウザ２０９に対して指示する。
ステップＳ２３４において、ブラウザ２０９は、放送ミドルウェア２０５からの指示に従い、エンドユーザにより停止が指示されたとき、起動中のアプリケーションを停止する。
ステップＳ２３４の処理でアプリケーションが停止されると、ステップＳ２２０の処理が行われる。すなわち、ステップＳ２２０において、放送ミドルウェア２０５は、停止されたアプリケーションのファイルを、ストレージ２１０から削除する。
なお、このとき、放送ミドルウェア２０５は、蓄積済みアプリリストから、停止されたアプリケーションを示す情報（エントリロケーション）を削除する。
ステップＳ２２０，Ｓ２３４の処理が終了すると、validFrom属性とvalidUntil属性が、"*"指定となる場合における、アプリケーション対応処理は、終了される。
以上、アプリケーション対応処理の流れを説明した。このアプリケーション対応処理においては、HLSTメタデータのvalidFrom属性とvalidUntil属性が、時刻指定となる場合には、validFrom属性とvalidUntil属性が示す期間に応じて、アプリケーションの動作を制御するモード（時刻指定モード）となる一方で、validFrom属性とvalidUntil属性が"*"指定となる場合には、エンドユーザの意思に応じて、アプリケーションの動作を制御するモード（ユーザ指定モード）となる。その結果として、放送局側で指定された期間のみならず、任意の時刻に、エンドユーザの意思でアプリケーションの動作を制御することができるため、より柔軟にアプリケーションの動作を制御することができる。
（HLSTメタデータ対応処理）
次に、図９のフローチャートを参照して、放送ミドルウェア２０５により実行されるHLSTメタデータ対応処理の流れを説明する。
ステップＳ２５１において、放送ミドルウェア２０５は、ROUTEセッションでSLSとして伝送されるHLSTメタデータを取得する。
ステップＳ２５２において、放送ミドルウェア２０５は、ステップＳ２５１の処理で得られたHLSTメタデータのパースを開始する。
ステップＳ２５３において、放送ミドルウェア２０５は、HLSTメタデータをパースして得られる解析結果（HLSTメタデータの解析結果）が示すエントリロケーションが、蓄積済みアプリリストに存在するかどうかを判定する。
ステップＳ２５３において、対象のエントリロケーションが、蓄積済みアプリリストに存在すると判定された場合、対象のアプリケーションのファイルが、ストレージ２１０に蓄積済みであるので、処理は、ステップＳ２５４に進められる。
ステップＳ２５４において、放送ミドルウェア２０５は、HLSTメタデータの解析結果に従い、validFrom属性とvalidUntil属性が存在するかどうかを判定する。
ステップＳ２５４において、validFrom属性とvalidUntil属性が存在すると判定された場合、処理は、ステップＳ２５５に進められる。ステップＳ２５５において、放送ミドルウェア２０５は、HLSTメタデータの解析結果に従い、validFrom属性とvalidUntil属性が、時刻指定と、"*"指定のいずれかであるかを判定する。
ステップＳ２５５において、validFrom属性とvalidUntil属性の指定が時刻指定であると判定された場合、処理は、ステップＳ２５６に進められる。ステップＳ２５６において、放送ミドルウェア２０５は、validFrom属性とvalidUntil属性が示す時刻に応じて、アプリケーションの起動や停止、蓄積済みアプリリストの情報の削除などを行う。
すなわち、このステップＳ２５６の処理では、放送ミドルウェア２０５により、図８のステップＳ２１５乃至Ｓ２１７に相当する処理が実行されるので、ブラウザ２０９側では、図８のステップＳ２３１乃至Ｓ２３２に相当する処理が実行され、アプリケーションの動作が制御される。
また、ステップＳ２５５において、validFrom属性とvalidUntil属性の指定が、"*"指定であると判定された場合、処理は、ステップＳ２５７に進められる。ステップＳ２５７において、放送ミドルウェア２０５は、エンドユーザの操作に応じて、アプリケーションの起動や停止、蓄積済みアプリリストの情報の削除などを行う。
すなわち、このステップＳ２５７の処理では、放送ミドルウェア２０５により、図８のステップＳ２１８乃至Ｓ２２０に相当する処理が実行されるので、ブラウザ２０９側では、図８のステップＳ２３３乃至Ｓ２３４に相当する処理が実行され、アプリケーションの動作が制御される。
ここで、例えば、図１０に示すように、クライアント装置２０がテレビ受像機である場合に、エンドユーザがクライアント装置２０を起動すると、その画面には、蓄積済みアプリリストに登録されたアプリケーションを起動するためのアイコンＡ１乃至Ａ４が表示される。すなわち、アプリケーションは、validFrom属性の指定が"*"指定となる場合には、番組とは独立して、動作を制御することが可能なアプリケーションとなり、アイコンＡ１乃至Ａ４は、当該アプリケーションを起動するための起動ボタンとして機能する。
この種のアプリケーションとしては、例えば、ある番組がシリーズで放送されている場合に、前回の放送分を、インターネット経由でビデオ・オン・デマンド（Video On Demand）により視聴できるようにする、キャッチアップテレビアプリケーションなどを提供することができる。エンドユーザは、例えば、リモートコントローラや入力部２０２などを操作して、アイコンＡ１乃至Ａ４のいずれかを選択することで、図１０の矢印で示すように、蓄積済みのキャッチアップテレビアプリケーションを起動して、選択されたアイコンに応じたVOD番組を再生することができる。
また、例えば、図１１に示すように、クライアント装置２０がテレビ受像機である場合に、エンドユーザにより電子番組表（ESG）の起動が指示されると、その画面には、サービス（チャネル）ごとに、所定の時間帯に放送される番組の情報を表した電子番組表が表示される。この電子番組表に表された番組の情報のうち、所定の番組の情報には、蓄積済みアプリリストに登録されたアプリケーションを起動するためのアイコンＢ１及びＢ２が重畳されている。
この種のアプリケーションとしては、例えば、番組の内容と関係はしているが、当該番組の放送時間とは独立して、動作を制御することが可能なアプリケーションなどを提供することができる。アイコンＢ１及びＢ２は、電子番組表において、当該アプリケーションを提供可能な番組の情報に重畳表示される。エンドユーザは、例えば、リモートコントローラや入力部２０２などを操作して、アイコンＢ１及びＢ２のいずれかを選択することで、蓄積済みのキャッチアップテレビアプリケーションを起動して、選択されたアイコンに応じたVOD番組を再生することができる。
図９のフローチャートの説明に戻り、ステップＳ２５６又はＳ２５７の処理が終了すると、処理は、ステップＳ２５８に進められる。ステップＳ２５８において、放送ミドルウェア２０５は、ステップＳ２５１の処理で得られた処理対象のHLSTメタデータのパースを停止する。
一方で、ステップＳ２５３において、対象のエントリロケーションが、蓄積済みアプリリストに存在しないと判定された場合、対象のアプリケーションのファイルが、ストレージ２１０に蓄積されていないので、処理は、ステップＳ２５９に進められる。
ステップＳ２５９において、放送ミドルウェア２０５は、HLSTメタデータの解析結果に従い、DistribtuionWindow要素が存在するかどうかを判定する。
ステップＳ２５９において、DistribtuionWindow要素が存在すると判定された場合、処理は、ステップＳ２６０に進められる。ステップＳ２６０において、放送ミドルウェア２０５は、StartTime要素とEndTime要素が示す時刻により定められる配信期間に応じて、ROUTEセッションで伝送されるアプリケーションのファイル（パッケージファイル）を取得する。
ステップＳ２６１において、放送ミドルウェア２０５は、ステップＳ２６０の処理で得られたアプリケーションのファイル（パッケージファイル）を、ストレージ２１０に蓄積する。また、放送ミドルウェア２０５は、当該アプリケーションを示す情報（エントリロケーション）を、蓄積済みアプリリストに追加する。
また、ステップＳ２５９において、DistribtuionWindow要素が存在しないと判定された場合、処理は、ステップＳ２６２に進められる。ステップＳ２６２において、放送ミドルウェア２０５は、ROUTEセッションで伝送されるアプリケーションのファイル（パッケージファイル）を取得する。
すなわち、この場合、HLSTメタデータに、DistribtuionWindow要素のStartTime要素とEndTime要素が存在しないので、放送ミドルウェア２０５は、処理対象のHLSTメタデータの配信時には、常に、対象のアプリケーションが配信されていると解釈し、任意のタイミングで、アプリケーションのファイルを取得することができる。例えば、ここでは、HLSTメタデータをパースした後、直ちに、アプリケーションのファイルが取得されるようにすることができる。
ステップＳ２６３においては、ステップＳ２６１と同様に、ステップＳ２６２の処理で得られたアプリケーションのファイル（パッケージファイル）が、ストレージ２１０に蓄積される。また、当該アプリケーションを示す情報（エントリロケーション）が、蓄積済みアプリリストに追加される。
ステップＳ２６１又はＳ２６３の処理が終了すると、処理は、ステップＳ２６４に進められる。ステップＳ２６４において、放送ミドルウェア２０５は、HLSTメタデータの解析結果に従い、validFrom属性とvalidUntil属性が存在するかどうかを判定する。
ステップＳ２６４において、validFrom属性とvalidUntil属性が存在すると判定された場合、処理は、ステップＳ２５５に進められ、それ以降の処理が実行される。すなわち、validFrom属性とvalidUntil属性が時刻指定の場合には、validFrom属性とvalidUntil属性が示す時刻に応じて、アプリケーションの動作が制御される。一方で、validFrom属性とvalidUntil属性が"*"指定の場合には、エンドユーザの操作に応じて、任意の時刻に、アプリケーションの動作が制御される。
また、ステップＳ２６４において、validFrom属性とvalidUntil属性が存在しないと判定された場合、処理は、ステップＳ２５８に進められる。ステップＳ２５８において、放送ミドルウェア２０５は、ステップＳ２５１の処理で得られた処理対象のHLSTメタデータのパースを停止する。ステップＳ２５８の処理が終了すると、図９のHLSTメタデータ対応処理は終了する。
この場合、起動時間が、将来取得される別のHLSTメタデータに記載されているものとみなして、処理対象のHLSTメタデータに対する処理を終わらせることになる。ただし、該当するHLSTメタデータを取りこぼす可能性もあるため、常に、validUntil属性には、"*"が指定されているものとみなして、HLSTメタデータ対応処理が行われるようにする。例えば、定期的に蓄積済みのアプリケーションのクリーンアップ処理を走らせて、長い間、蓄積済みアプリリストに残っているアプリケーションは削除されるようにすることができる。
以上、HLSTメタデータ対応処理の流れを説明した。
（コンテンツ対応処理）
最後に、図１２のフローチャートを参照して、送信側システム１０とクライアント装置２０により実行されるコンテンツ対応処理の流れを説明する。
なお、図１２において、ステップＳ１７１乃至Ｓ１７４の処理は、送信側システム１０により実行される処理であり、ステップＳ２７１乃至Ｓ２７５の処理は、クライアント装置２０により実行される処理である。
ステップＳ１７１において、DASHサーバ１０１は、コンテンツのデータから、DASHセグメントファイルを生成する。
ステップＳ１７２において、シグナリングサーバ１０２は、LLSやSLSのシグナリングを生成する。ここで、LLSには、SLTメタデータが含まれる。また、SLSには、USBD，S-TSID，MPD等のメタデータが含まれる。
ステップＳ１７３において、放送サーバ１０５は、ステップＳ１７１乃至Ｓ１７２の処理で得られたDASHセグメントファイルと、シグナリングのファイルを含む多重化ストリームを生成する。
ステップＳ１７４において、放送サーバ１０５は、ステップＳ１７３の処理で得られた多重化ストリームに対し、変調処理を行い、その結果得られる放送波を、放送伝送路３０を介して送信する。
ステップＳ２７１において、受信部２０４は、放送サーバ１０５から、放送伝送路３０を介して送信されてくる放送波を受信する。ここでは、受信部２０４により、放送波に対する復調処理が行われることで、多重化ストリームが得られる。
ステップＳ２７２において、放送ミドルウェア２０５は、ステップＳ２７１の処理で得られる多重化ストリームに含まれるシグナリングを処理する。ここでは、LLSやSLSのシグナリングが処理される。
ステップＳ２７３において、DASHクライアント２０６は、ステップＳ２７２の処理で得られる処理結果に従い、ステップＳ２７１の処理で得られる多重化ストリームに含まれるDASHセグメントファイルを処理する。
ステップＳ２７４において、デコーダ２０７は、ステップＳ２７３の処理で得られるデータをデコードする。
ステップＳ２７５において、出力部２０８は、ステップＳ２７４の処理で得られるデータを処理し、ディスプレイやスピーカに出力する。これにより、クライアント装置２０においては、エンドユーザの選局操作に応じたサービスのコンテンツが再生される。
以上、コンテンツ対応処理の流れについて説明した。
＜５．変形例＞
（通信経由の配信）
上述した図１の伝送システム１においては、コンテンツやアプリケーションのデータが、放送伝送路３０を介して放送経由で配信される場合を説明したが、コンテンツやアプリケーションのデータは、インターネット等の通信伝送路を介して通信経由で配信されるようにしてもよい。
図１３には、伝送システムの他の構成例を示している。図１３の伝送システム２においては、図１の伝送システム１と比べて、送信側システム１０に、DASHサーバ１０１乃至放送サーバ１０５のほかに、通信サーバ１０６が設けられる点が異なっている。また、クライアント装置２０は、通信機能を有しており、インターネット等の通信伝送路４０を介して、通信サーバ１０６と相互に接続されている。
通信サーバ１０６は、DASHサーバ１０１からのDASHセグメントファイルと、シグナリングサーバ１０２からのシグナリング（SLS）のファイルと、SCH/PKGサーバ１０４からのアプリケーションのファイルが送信されてくるので、それらのファイルを受信する。
通信サーバ１０６は、各サーバからのファイルを処理する。通信サーバ１０６は、クライアント装置２０からの要求に応じて、通信伝送路４０を介して、各種のファイルを送信する。ここでは、図３のプロトコルスタックに示したように、TCP/IPのプロトコル上のHTTPを用いて、それらのファイルが伝送される。
一方で、クライアント装置２０は、通信機能を有する場合、通信伝送路４０を介して、通信サーバ１０６にアクセスし、各種のファイルを受信することができる。
例えば、クライアント装置２０は、通信伝送路４０を介して、通信サーバ１０６から送信されてくるMPDメタデータやDASHセグメントファイルを受信して処理することで、適応的にストリーミング配信されるVOD番組などのコンテンツを再生することができる。
また、例えば、クライアント装置２０は、通信伝送路４０を介して、通信サーバ１０６から送信されてくるHLSTメタデータやアプリケーションのファイルを受信して処理することで、通信経由で取得されたアプリケーションを実行することができる。
ただし、ここでも、当該HLSTメタデータをパースして得られる解析結果に従い、時刻指定の場合には、時刻指定モードとなって、validFrom属性とvalidUntil属性が示す時刻に応じて、アプリケーションの動作が制御され、"*"指定の場合には、エンドユーザの操作に応じて、任意の時刻に、アプリケーションの動作が制御される。
なお、上述した説明では、DASHセグメントファイル、シグナリングのファイル、及びアプリケーションのファイルが、放送伝送路３０を介した放送経由、又は通信伝送路４０を介した通信経由のいずれか一方の経路で配信されるとして説明したが、一部のファイルを放送経由で配信し、残りのファイルを通信経由で配信することもできる。すなわち、クライアント装置２０においては、放送経由又は通信経由で取得されたコンテンツに付随して、放送経由又は通信経由で取得されたアプリケーションが実行される。
また、例えば、SLSのファイルのうち、USBD，S-TSID等のメタデータを、放送経由で配信し、HLST，MPD等のメタデータを、通信経由で配信することができる。また、例えば、アプリケーションのファイルのうち、文書ファイルなどのエントリページファイルを、放送経由で配信し、画像ファイルやスクリプトファイルなどのリソースファイルを、通信経由で配信することができる。
（他の放送規格への適用）
上述した説明としては、デジタル放送の規格として、米国等で採用されている方式である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）等の有線放送などの規格に適用することができる。
（アプリケーションの他の例）
また、上述した説明では、コンテンツに付随するアプリケーションは、HTML5などのマークアップ言語やJavaScript（登録商標）等のスクリプト言語で開発されたアプリケーションに限らず、例えば、Java（登録商標）などのプログラミング言語で開発されたアプリケーションであってもよい。また、アプリケーションは、ブラウザにより実行されるアプリケーションに限らず、いわゆるネイティブアプリケーションとして、オペレーティングシステム（OS：Operating System）環境などで実行されるようにしてもよい。
ただし、アプリケーションは、何らかの情報を明示的に表示するだけでなく、非表示で（バックグラウンドで）動作されるようにしてもよい（エンドユーザに認識されずに起動するようにしてもよい）。また、アプリケーションが付随するコンテンツは、動画や音楽のほか、例えば、電子書籍やゲーム、広告など、あらゆるコンテンツを含めることができる。
また、上述した説明では、アプリケーションを構成するファイルが、パッケージファイルに格納されて伝送される場合を例示したが、アプリケーションを構成するファイルは、パッケージファイルに格納せずに、個々のファイル（独立したファイル）として、NRTチャネルで伝送されるようにしてもよい。この場合、EFDTには、転送パラメタとして、NRTチャネルで伝送される個々のファイルを特定するための情報が列挙されることになる（個々のファイルごとに、個別のTOIが割り当てられる）。
（その他の変形例）
上述したシグナリングやパケットなどの名称は、一例であって、他の名称が用いられる場合がある。ただし、これらの名称の違いは、形式的な違いであって、対象のシグナリングやパケットなどの実質的な内容が異なるものではない。例えば、USBD(User Service Bundle Description)は、USD(User Service Description)などと称される場合がある。また、例えば、NRT(Non Real Time)コンテンツは、LCC(Locally Cached Content)などと称され、AIT(Application Information Table)は、AST(Application Signaling Table)などと称される場合がある。また、ESG(Electronic Service Guide)は、EPG(Electronic Program Guide)などと称される場合がある。
また、図１の伝送システム１や図１３の伝送システム２においては、説明の簡略化のため、放送局の放送サーバ１０５が単独で、マルチプレクサと変調器を有するものとして、その構成を説明したが、一般的なデジタル放送のシステムでは、マルチプレクサと変調器は異なる場所に設置されるものである。例えば、マルチプレクサは、放送局内に設置される一方で、変調器は、送信局（送信所）に設置される。また、図１の送信側システム１０や図１３の伝送システム２の全体を１つの装置と捉えて、各サーバの機能を有する装置とすることもできる。
＜６．コンピュータの構成＞
上述した一連の処理（例えば、アプリケーション対応処理やコンテンツ対応処理）は、ハードウェアにより実行することもできるし、ソフトウェアにより実行することもできる。一連の処理をソフトウェアにより実行する場合には、そのソフトウェアを構成するプログラムが、コンピュータにインストールされる。図１４は、上述した一連の処理をプログラムにより実行するコンピュータのハードウェアの構成例を示す図である。
コンピュータ１０００において、CPU(Central Processing Unit)１００１、ROM(Read Only Memory)１００２、RAM(Random Access Memory)１００３は、バス１００４により相互に接続されている。バス１００４には、さらに、入出力インターフェース１００５が接続されている。入出力インターフェース１００５には、入力部１００６、出力部１００７、記録部１００８、通信部１００９、及び、ドライブ１０１０が接続されている。
入力部１００６は、キーボード、マウス、マイクロフォンなどよりなる。出力部１００７は、ディスプレイ、スピーカなどよりなる。記録部１００８は、ハードディスクや不揮発性のメモリなどよりなる。通信部１００９は、ネットワークインターフェースなどよりなる。ドライブ１０１０は、磁気ディスク、光ディスク、光磁気ディスク、又は半導体メモリなどのリムーバブル記録媒体１０１１を駆動する。
以上のように構成されるコンピュータ１０００では、CPU１００１が、ROM１００２や記録部１００８に記録されているプログラムを、入出力インターフェース１００５及びバス１００４を介して、RAM１００３にロードして実行することにより、上述した一連の処理が行われる。
コンピュータ１０００（CPU１００１）が実行するプログラムは、例えば、パッケージメディア等としてのリムーバブル記録媒体１０１１に記録して提供することができる。また、プログラムは、ローカルエリアネットワーク、インターネット、デジタル衛星放送といった、有線又は無線の伝送媒体を介して提供することができる。
コンピュータ１０００では、プログラムは、リムーバブル記録媒体１０１１をドライブ１０１０に装着することにより、入出力インターフェース１００５を介して、記録部１００８にインストールすることができる。また、プログラムは、有線又は無線の伝送媒体を介して、通信部１００９で受信し、記録部１００８にインストールすることができる。その他、プログラムは、ROM１００２や記録部１００８に、あらかじめインストールしておくことができる。
ここで、本明細書において、コンピュータがプログラムに従って行う処理は、必ずしもフローチャートとして記載された順序に沿って時系列に行われる必要はない。すなわち、コンピュータがプログラムに従って行う処理は、並列的あるいは個別に実行される処理（例えば、並列処理あるいはオブジェクトによる処理）も含む。また、プログラムは、１のコンピュータ（プロセッサ）により処理されるものであってもよいし、複数のコンピュータによって分散処理されるものであってもよい。
なお、本技術の実施の形態は、上述した実施の形態に限定されるものではなく、本技術の要旨を逸脱しない範囲において種々の変更が可能である。
また、本技術は、以下のような構成をとることができる。
（１）
コンテンツを受信する受信部と、
前記コンテンツに付随するアプリケーションが有効になる期間を示す有効期間情報に基づいて、前記アプリケーションの動作を制御する制御部と
を備え、
前記有効期間情報は、前記期間に応じて前記アプリケーションの動作を制御する第１のモードと、エンドユーザの意志に応じて前記アプリケーションの動作を制御する第２のモードとのいずれかを指定可能であり、
前記制御部は、前記有効期間情報として、前記第２のモードが指定されている場合、前記エンドユーザの操作に応じて、前記アプリケーションの動作を制御する
受信装置。
（２）
前記制御部は、前記有効期間情報に、
前記第１のモードが指定されている場合、前記期間内のみ、前記コンテンツに付随して、前記アプリケーションが起動されるようにし、
前記第２のモードが指定されている場合、前記エンドユーザの操作に応じて、前記アプリケーションが起動又は停止されるようにする
（１）に記載の受信装置。
（３）
前記アプリケーションは、１又は複数のファイルから構成され、
前記有効期間情報は、前記ファイルから得られる対象のページが有効となる期間の開始の時刻を示す第１の開始時刻情報と、前記ファイルから得られる対象のページが有効となる期間の終了の時刻を示す第１の終了時刻情報とからなる
（１）又は（２）に記載の受信装置。
（４）
前記有効期間情報において、前記第１の開始時刻情報及び前記第１の終了時刻情報の少なくとも一方の時刻情報に対し、あらかじめ定められた特定のキーワードが指定された場合に、前記第２のモードが指定されたとみなされる
（３）に記載の受信装置。
（５）
前記制御部は、前記アプリケーションが取得可能になる期間を示す取得期間情報に基づいて、前記アプリケーションが取得されるようにする
（１）乃至（４）のいずれかに記載の受信装置。
（６）
前記アプリケーションは、１又は複数のファイルから構成され、
前記取得期間情報は、前記ファイルの配信期間の開始の時刻を示す第２の開始時刻情報と、前記ファイルの配信期間の終了の時刻を示す第２の終了時刻情報とからなる
（５）に記載の受信装置。
（７）
前記制御部は、前記取得期間情報が存在しない場合、任意の期間に、前記アプリケーションが取得されるようにする
（５）又は（６）に記載の受信装置。
（８）
前記有効期間情報と前記取得期間情報は、サービスごとに提供される、前記アプリケーションを制御するための制御情報に含まれ、
前記受信部は、前記コンテンツとともに送信される、前記制御情報を受信する
（５）に記載の受信装置。
（９）
１つの前記制御情報は、１つの前記アプリケーションを、１つの前記コンテンツに対して付随させるための情報である
（８）に記載の受信装置。
（１０）
受信装置のデータ処理方法において、
前記受信装置が、
コンテンツを受信し、
前記コンテンツに付随するアプリケーションが有効になる期間を示す有効期間情報に基づいて、前記アプリケーションの起動を制御する
ステップを含み、
前記有効期間情報は、前記期間に応じて前記アプリケーションの動作を制御する第１のモードと、エンドユーザの意志に応じて前記アプリケーションの動作を制御する第２のモードとのいずれかを指定可能であり、
前記有効期間情報として、前記第２のモードが指定されている場合、前記エンドユーザの操作に応じて、前記アプリケーションの動作を制御する
データ処理方法。
（１１）
コンテンツに付随するアプリケーションが有効になる期間を示す有効期間情報であって、前記期間に応じて前記アプリケーションの動作を制御する第１のモードと、エンドユーザの意志に応じて前記アプリケーションの動作を制御する第２のモードとのいずれかを指定可能な前記有効期間情報を生成する生成部と、
前記コンテンツとともに、前記有効期間情報を送信する送信部と
を備える送信装置。
（１２）
前記有効期間情報は、
前記第１のモードが指定されている場合、前記期間内のみ、前記コンテンツに付随して前記アプリケーションが起動されるようにするための情報であり、
前記第２のモードが指定されている場合、前記エンドユーザの操作に応じて、前記アプリケーションが起動又は停止されるようにするための情報となる
（１１）に記載の送信装置。
（１３）
前記アプリケーションは、１又は複数のファイルから構成され、
前記有効期間情報は、前記ファイルから得られる対象のページが有効となる期間の開始の時刻を示す第１の開始時刻情報と、前記ファイルから得られる対象のページが有効となる期間の終了の時刻を示す第１の終了時刻情報とからなる
（１１）又は（１２）に記載の送信装置。
（１４）
前記生成部は、前記第２のモードを指定する場合に、前記第１の開始時刻情報及び前記第１の終了時刻情報の少なくとも一方の時刻情報に対し、あらかじめ定められた特定のキーワードを指定する
（１３）に記載の送信装置。
（１５）
前記生成部は、前記アプリケーションが取得可能になる期間を示す取得期間情報を生成し、
前記送信部は、前記取得期間情報を送信する
（１１）乃至（１４）のいずれかに記載の送信装置。
（１６）
前記アプリケーションは、１又は複数のファイルから構成され、
前記取得期間情報は、前記ファイルの配信期間の開始の時刻を示す第２の開始時刻情報と、前記ファイルの配信期間の終了の時刻を示す第２の終了時刻情報とからなる
（１５）に記載の送信装置。
（１７）
前記生成部は、前記有効期間情報と前記取得期間情報を、サービスごとに提供される、前記アプリケーションを制御するための制御情報に含めて生成し、
前記送信部は、前記コンテンツとともに、前記制御情報を送信する
（１５）又は（１６）に記載の送信装置。
（１８）
前記生成部は、任意の期間に、前記アプリケーションが取得されるようにする場合、前記制御情報に、前記有効期間情報のみを含める
（１７）に記載の送信装置。
（１９）
１つの前記制御情報は、１つの前記アプリケーションを、１つの前記コンテンツに対して付随させるための情報である
（１７）又は（１８）に記載の送信装置。
（２０）
送信装置のデータ処理方法において、
前記送信装置が、
コンテンツに付随するアプリケーションが有効になる期間を示す有効期間情報であって、前記期間に応じて前記アプリケーションの動作を制御する第１のモードと、エンドユーザの意志に応じて前記アプリケーションの動作を制御する第２のモードとのいずれかを指定可能な前記有効期間情報を生成し、
前記コンテンツとともに、前記有効期間情報を送信する
ステップを含むデータ処理方法。
１，２ 伝送システム， １０ 送信側システム， ２０ クライアント装置， ３０ 放送伝送路， ４０ 通信伝送路， １０１ DASHサーバ， １０２ シグナリングサーバ， １０３ アプリケーションサーバ， １０４ SCH/PKGサーバ， １０５ 放送サーバ， １０６ 通信サーバ， ２０１ 制御部， ２０２ 入力部， ２０３ メモリ， ２０４ 受信部， ２０５ 放送ミドルウェア， ２０６ DASHクライアント， ２０７ デコーダ， ２０８ 出力部， ２０９ ブラウザ， ２１０ ストレージ， １０００ コンピュータ， １００１ CPU

Claims (20)

  1. コンテンツを受信する受信部と、
    前記コンテンツに付随するアプリケーションが有効になる期間を示す有効期間情報に基づいて、前記アプリケーションの動作を制御する制御部と
    を備え、
    前記有効期間情報は、前記期間に応じて前記アプリケーションの動作を制御する第１のモードと、エンドユーザの意志に応じて前記アプリケーションの動作を制御する第２のモードとのいずれかを指定可能であり、
    前記制御部は、前記有効期間情報として、前記第２のモードが指定されている場合、前記エンドユーザの操作に応じて、前記アプリケーションの動作を制御する
    受信装置。
  2. 前記制御部は、前記有効期間情報に、
    前記第１のモードが指定されている場合、前記期間内のみ、前記コンテンツに付随して、前記アプリケーションが起動されるようにし、
    前記第２のモードが指定されている場合、前記エンドユーザの操作に応じて、前記アプリケーションが起動又は停止されるようにする
    請求項１に記載の受信装置。
  3. 前記アプリケーションは、１又は複数のファイルから構成され、
    前記有効期間情報は、前記ファイルから得られる対象のページが有効となる期間の開始の時刻を示す第１の開始時刻情報と、前記ファイルから得られる対象のページが有効となる期間の終了の時刻を示す第１の終了時刻情報とからなる
    請求項２に記載の受信装置。
  4. 前記有効期間情報において、前記第１の開始時刻情報及び前記第１の終了時刻情報の少なくとも一方の時刻情報に対し、あらかじめ定められた特定のキーワードが指定された場合に、前記第２のモードが指定されたとみなされる
    請求項３に記載の受信装置。
  5. 前記制御部は、前記アプリケーションが取得可能になる期間を示す取得期間情報に基づいて、前記アプリケーションが取得されるようにする
    請求項２に記載の受信装置。
  6. 前記アプリケーションは、１又は複数のファイルから構成され、
    前記取得期間情報は、前記ファイルの配信期間の開始の時刻を示す第２の開始時刻情報と、前記ファイルの配信期間の終了の時刻を示す第２の終了時刻情報とからなる
    請求項５に記載の受信装置。
  7. 前記制御部は、前記取得期間情報が存在しない場合、任意の期間に、前記アプリケーションが取得されるようにする
    請求項５に記載の受信装置。
  8. 前記有効期間情報と前記取得期間情報は、サービスごとに提供される、前記アプリケーションを制御するための制御情報に含まれ、
    前記受信部は、前記コンテンツとともに送信される、前記制御情報を受信する
    請求項５に記載の受信装置。
  9. １つの前記制御情報は、１つの前記アプリケーションを、１つの前記コンテンツに対して付随させるための情報である
    請求項８に記載の受信装置。
  10. 受信装置のデータ処理方法において、
    前記受信装置が、
    コンテンツを受信し、
    前記コンテンツに付随するアプリケーションが有効になる期間を示す有効期間情報に基づいて、前記アプリケーションの起動を制御する
    ステップを含み、
    前記有効期間情報は、前記期間に応じて前記アプリケーションの動作を制御する第１のモードと、エンドユーザの意志に応じて前記アプリケーションの動作を制御する第２のモードとのいずれかを指定可能であり、
    前記有効期間情報として、前記第２のモードが指定されている場合、前記エンドユーザの操作に応じて、前記アプリケーションの動作を制御する
    データ処理方法。
  11. コンテンツに付随するアプリケーションが有効になる期間を示す有効期間情報であって、前記期間に応じて前記アプリケーションの動作を制御する第１のモードと、エンドユーザの意志に応じて前記アプリケーションの動作を制御する第２のモードとのいずれかを指定可能な前記有効期間情報を生成する生成部と、
    前記コンテンツとともに、前記有効期間情報を送信する送信部と
    を備える送信装置。
  12. 前記有効期間情報は、
    前記第１のモードが指定されている場合、前記期間内のみ、前記コンテンツに付随して前記アプリケーションが起動されるようにするための情報であり、
    前記第２のモードが指定されている場合、前記エンドユーザの操作に応じて、前記アプリケーションが起動又は停止されるようにするための情報となる
    請求項１１に記載の送信装置。
  13. 前記アプリケーションは、１又は複数のファイルから構成され、
    前記有効期間情報は、前記ファイルから得られる対象のページが有効となる期間の開始の時刻を示す第１の開始時刻情報と、前記ファイルから得られる対象のページが有効となる期間の終了の時刻を示す第１の終了時刻情報とからなる
    請求項１２に記載の送信装置。
  14. 前記生成部は、前記第２のモードを指定する場合に、前記第１の開始時刻情報及び前記第１の終了時刻情報の少なくとも一方の時刻情報に対し、あらかじめ定められた特定のキーワードを指定する
    請求項１３に記載の送信装置。
  15. 前記生成部は、前記アプリケーションが取得可能になる期間を示す取得期間情報を生成し、
    前記送信部は、前記取得期間情報を送信する
    請求項１２に記載の送信装置。
  16. 前記アプリケーションは、１又は複数のファイルから構成され、
    前記取得期間情報は、前記ファイルの配信期間の開始の時刻を示す第２の開始時刻情報と、前記ファイルの配信期間の終了の時刻を示す第２の終了時刻情報とからなる
    請求項１５に記載の送信装置。
  17. 前記生成部は、前記有効期間情報と前記取得期間情報を、サービスごとに提供される、前記アプリケーションを制御するための制御情報に含めて生成し、
    前記送信部は、前記コンテンツとともに、前記制御情報を送信する
    請求項１５に記載の送信装置。
  18. 前記生成部は、任意の期間に、前記アプリケーションが取得されるようにする場合、前記制御情報に、前記有効期間情報のみを含める
    請求項１７に記載の送信装置。
  19. １つの前記制御情報は、１つの前記アプリケーションを、１つの前記コンテンツに対して付随させるための情報である
    請求項１７に記載の送信装置。
  20. 送信装置のデータ処理方法において、
    前記送信装置が、
    コンテンツに付随するアプリケーションが有効になる期間を示す有効期間情報であって、前記期間に応じて前記アプリケーションの動作を制御する第１のモードと、エンドユーザの意志に応じて前記アプリケーションの動作を制御する第２のモードとのいずれかを指定可能な前記有効期間情報を生成し、
    前記コンテンツとともに、前記有効期間情報を送信する
    ステップを含むデータ処理方法。
JP2018529493A 2016-07-25 2017-07-11 受信装置、送信装置、及び、データ処理方法 Pending JPWO2018021015A1 (ja)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
JP2016145101 2016-07-25
JP2016145101 2016-07-25
PCT/JP2017/025256 WO2018021015A1 (ja) 2016-07-25 2017-07-11 受信装置、送信装置、及び、データ処理方法

Publications (1)

Publication Number Publication Date
JPWO2018021015A1 true JPWO2018021015A1 (ja) 2019-05-09

Family

ID=61016522

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2018529493A Pending JPWO2018021015A1 (ja) 2016-07-25 2017-07-11 受信装置、送信装置、及び、データ処理方法

Country Status (8)

Country Link
US (1) US10742339B2 (ja)
EP (1) EP3490265A4 (ja)
JP (1) JPWO2018021015A1 (ja)
KR (1) KR102491466B1 (ja)
BR (1) BR112019001062A2 (ja)
CA (1) CA3030391C (ja)
MX (1) MX2019000782A (ja)
WO (1) WO2018021015A1 (ja)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2020162712A1 (ko) * 2019-02-07 2020-08-13 엘지전자 주식회사 방송 신호 송신 장치, 방송 신호 송신 방법, 방송 신호 수신 방법 및 방송 신호 수신 장치

Family Cites Families (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2001292427A (ja) 2000-04-06 2001-10-19 Nippon Television Network Corp コンテンツの連動方法、及びそのシステム
JP2006050105A (ja) 2004-08-02 2006-02-16 Toshiba Corp メタデータの構造及びその再生装置と方法
KR100813985B1 (ko) * 2006-09-06 2008-03-14 삼성전자주식회사 저장된 데이터 방송 서비스들 중에서 애플리케이션을포함하는 데이터 방송 서비스를 필터링하기 위한 데이터방송 서비스 제공 장치 및 방법
KR101485461B1 (ko) * 2008-10-23 2015-01-22 삼성전자주식회사 Ａｉｔ를 이용한 애플리케이션의 제공 방법 및 그 장치
CA2838471C (en) * 2012-05-10 2020-08-18 Sony Corporation Receiving apparatus, reception method, transmitting apparatus, transmission method, and program
US9883247B2 (en) * 2012-08-13 2018-01-30 Saturn Licensing Llc Reception apparatus, reception method, transmission apparatus, and transmission method
JP6316196B2 (ja) 2012-10-10 2018-04-25 サターン ライセンシング エルエルシーＳａｔｕｒｎ Ｌｉｃｅｎｓｉｎｇ ＬＬＣ 受信装置、受信方法、送信装置、送信方法、及び、プログラム
JP2015119286A (ja) 2013-12-17 2015-06-25 株式会社Ｎｔｔぷらら コンテンツサーバ、コンテンツ再生装置、コンテンツ再生制御方法、コンテンツ再生制御プログラム
JP2016103745A (ja) 2014-11-28 2016-06-02 ソニー株式会社 送信装置及び送信方法、並びに、受信装置並びに受信方法

Also Published As

Publication number Publication date
EP3490265A1 (en) 2019-05-29
US20190190633A1 (en) 2019-06-20
WO2018021015A1 (ja) 2018-02-01
US10742339B2 (en) 2020-08-11
CA3030391A1 (en) 2018-02-01
KR102491466B1 (ko) 2023-01-25
EP3490265A4 (en) 2019-05-29
KR20190031238A (ko) 2019-03-25
CA3030391C (en) 2023-08-15
BR112019001062A2 (pt) 2019-05-07
MX2019000782A (es) 2019-06-20

Similar Documents

Publication Publication Date Title
KR102637023B1 (ko) 수신 장치, 송신 장치, 및 데이터 처리 방법
CA2875465C (en) Apparatus and method for processing an interactive service
KR102443060B1 (ko) 정보 처리 장치 및 정보 처리 방법
US10805028B2 (en) Receiving device, transmitting device, and data processing method
KR102558781B1 (ko) 수신 장치, 송신 장치 및 데이터 처리 방법
US11336957B2 (en) Reception apparatus, transmission apparatus, and data processing method
KR102491466B1 (ko) 수신 장치, 송신 장치, 및 데이터 처리 방법
US10972205B2 (en) Reception apparatus, transmission apparatus, and data processing method
US20220376804A1 (en) Reception device, transmission device, and data processing method