(57)【要約】  本技術は、コンテンツに付随するアプリケーションの動作を容易に制御することができるようにする受信装置、送信装置、及び、データ処理方法に関する。受信装置は、コンテンツを受信し、コンテンツに付随するアプリケーションが有効になる期間を示す有効期間情報に基づいて、アプリケーションの起動を制御することで、コンテンツに付随するアプリケーションの動作を容易に制御することができる。本技術は、例えば、地上波放送を受信可能なテレビ受像機などに適用することができる。
2017212932.tif 000002
【特許請求の範囲】
【請求項１】
コンテンツを受信する受信部と、
前記コンテンツに付随するアプリケーションが有効になる期間を示す有効期間情報に基づいて、前記アプリケーションの起動を制御する制御部と
を備える受信装置。
【請求項２】
前記制御部は、前記有効期間情報が示す期間内のみ、前記コンテンツに付随して、前記アプリケーションが起動されるようにする
請求項１に記載の受信装置。
【請求項３】
前記アプリケーションは、１又は複数のファイルから構成され、
前記有効期間情報は、前記ファイルから得られる対象のページが有効となる期間の開始の時刻を示す開始時刻情報と、前記ファイルから得られる対象のページが有効となる期間の終了の時刻を示す終了時刻情報とからなる
請求項２に記載の受信装置。
【請求項４】
前記制御部は、前記アプリケーションの取得先を示す事前取得情報に基づいて、前記有効期間情報が示す期間に応じて、前記アプリケーションが取得されるようにする
請求項２に記載の受信装置。
【請求項５】
前記事前取得情報は、前記有効期間情報が示す期間の前に、前記アプリケーションが取得されるようにするための情報である
請求項４に記載の受信装置。
【請求項６】
前記アプリケーションは、１又は複数のファイルから構成され、
前記事前取得情報は、前記ファイルごとの取得先を示す情報である
請求項５に記載の受信装置。
【請求項７】
前記事前取得情報は、前記ファイルに応じたURL(Uniform Resource Locator)のリストである
請求項６に記載の受信装置。
【請求項８】
前記有効期間情報と前記事前取得情報は、サービスごとに提供される、前記アプリケーションを制御するための制御情報に含まれ、
前記受信部は、前記コンテンツとともに送信される、前記制御情報を受信する
請求項４に記載の受信装置。
【請求項９】
１つの前記制御情報は、１つの前記アプリケーションを、１つの前記コンテンツに対して付随させるための情報である
請求項８に記載の受信装置。
【請求項１０】
受信装置のデータ処理方法において、
前記受信装置が、
コンテンツを受信し、
前記コンテンツに付随するアプリケーションが有効になる期間を示す有効期間情報に基づいて、前記アプリケーションの起動を制御する
ステップを含むデータ処理方法。
【請求項１１】
コンテンツに付随するアプリケーションが有効になる期間を示す有効期間情報を生成する生成部と、
前記コンテンツとともに、前記有効期間情報を送信する送信部と
を備える送信装置。
【請求項１２】
前記有効期間情報は、特定の期間内のみ、前記コンテンツに付随して前記アプリケーションが起動されるようにするための情報である
請求項１１に記載の送信装置。
【請求項１３】
前記アプリケーションは、１又は複数のファイルから構成され、
前記有効期間情報は、前記ファイルから得られる対象のページが有効となる期間の開始の時刻を示す開始時刻情報と、前記ファイルから得られる対象のページが有効となる期間の終了の時刻を示す終了時刻情報とからなる
請求項１２に記載の送信装置。
【請求項１４】
前記生成部は、前記アプリケーションの取得先を示す情報であって、前記有効期間情報が示す期間に応じて前記アプリケーションが取得されるようにするための情報である事前取得情報を生成し、
前記送信部は、前記事前取得情報を送信する
請求項１２に記載の送信装置。
【請求項１５】
前記事前取得情報は、前記有効期間情報が示す期間の前に、前記アプリケーションが取得されるようにするための情報である
請求項１４に記載の送信装置。
【請求項１６】
前記アプリケーションは、１又は複数のファイルから構成され、
前記事前取得情報は、前記ファイルごとの取得先を示す情報である
請求項１５に記載の送信装置。
【請求項１７】
前記事前取得情報は、前記ファイルに応じたURLのリストである
請求項１６に記載の送信装置。
【請求項１８】
前記生成部は、前記有効期間情報と前記事前取得情報を、サービスごとに提供される、前記アプリケーションを制御するための制御情報に含めて生成し、
前記送信部は、前記コンテンツとともに、前記制御情報を送信する
請求項１４に記載の送信装置。
【請求項１９】
１つの前記制御情報は、１つの前記アプリケーションを、１つの前記コンテンツに対して付随させるための情報である
請求項１８に記載の送信装置。
【請求項２０】
送信装置のデータ処理方法において、
前記送信装置が、
コンテンツに付随するアプリケーションが有効になる期間を示す有効期間情報を生成し、
前記コンテンツとともに、前記有効期間情報を送信する
ステップを含むデータ処理方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本技術は、受信装置、送信装置、及び、データ処理方法に関し、特に、コンテンツに付随するアプリケーションの動作を容易に制御することができるようにした受信装置、送信装置、及び、データ処理方法に関する。
【背景技術】
【０００２】
番組やCM等のコンテンツに付随するアプリケーション（以下、単にアプリケーションともいう）の配信ライフサイクルコントロールに、AIT(Application Information Table)等のアプリケーション制御情報を用いることが知られている（例えば、特許文献１参照）。このアプリケーション制御情報によって、受信機では、アプリケーションの起動や終了の動作を制御することができる。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２０１５−１８００６５号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
ところで、AITは、送信側の送出タイミングにより、アプリケーションのライフサイクルを制御するため、その制御に時間的な連続性が必要となり、アプリケーションの動作の制御が煩雑になる場合があった。そのため、アプリケーションの動作を容易に制御するための提案が要請されていた。【０００５】
本技術はこのような状況に鑑みてなされたものであり、コンテンツに付随するアプリケーションの動作を容易に制御することができるようにするものである。
【課題を解決するための手段】
【０００６】
本技術の第１の側面の受信装置は、コンテンツを受信する受信部と、前記コンテンツに付随するアプリケーションが有効になる期間を示す有効期間情報に基づいて、前記アプリケーションの起動を制御する制御部とを備える受信装置である。【０００７】
本技術の第１の側面の受信装置は、独立した装置であってもよいし、１つの装置を構成している内部ブロックであってもよい。また、本技術の第１の側面のデータ処理方法は、上述した本技術の第１の側面の受信装置に対応するデータ処理方法である。【０００８】
本技術の第１の側面の受信装置、及び、データ処理方法においては、コンテンツが受信され、前記コンテンツに付随するアプリケーションが有効になる期間を示す有効期間情報に基づいて、前記アプリケーションの起動が制御される。【０００９】
本技術の第２の側面の送信装置は、コンテンツに付随するアプリケーションが有効になる期間を示す有効期間情報を生成する生成部と、前記コンテンツとともに、前記有効期間情報を送信する送信部とを備える送信装置である。【００１０】
本技術の第２の側面の送信装置は、独立した装置であってもよいし、１つの装置を構成している内部ブロックであってもよい。また、本技術の第２の側面のデータ処理方法は、上述した本技術の第２の側面の送信装置に対応するデータ処理方法である。【００１１】
本技術の第２の側面の送信装置、及び、データ処理方法においては、コンテンツに付随するアプリケーションが有効になる期間を示す有効期間情報が生成され、前記コンテンツとともに、前記有効期間情報が送信される。
【発明の効果】
【００１２】
本技術の第１の側面、及び、第２の側面によれば、コンテンツに付随するアプリケーションの動作を容易に制御することができる。【００１３】
なお、ここに記載された効果は必ずしも限定されるものではなく、本開示中に記載されたいずれかの効果であってもよい。
【図面の簡単な説明】
【００１４】
【図１】本技術を適用した伝送システムの一実施の形態の構成例を示す図である。
【図２】クライアント装置の構成例を示す図である。
【図３】本技術のプロトコルスタックの構成例を示す図である。
【図４】SLSチャネルとLCCチャネルとの関係を示す図である。
【図５】パッケージファイルの例を示す図である。
【図６】HLSTメタデータのフォーマットの例を示す図である。
【図７】HLSTメタデータの記述例を示す図である。
【図８】Capability Codeの例を示す図である。
【図９】HLSTメタデータに応じたアプリケーションの動作の例を時系列で示した図である。
【図１０】送受信処理を説明するフローチャートである。
【図１１】アプリケーション制御処理を説明するフローチャートである。
【図１２】コンピュータの構成例を示す図である。
【発明を実施するための形態】
【００１５】
以下、図面を参照しながら本技術の実施の形態について説明する。なお、説明は以下の順序で行うものとする。
【００１６】
１．システムの構成
２．シグナリングの構成
３．HLSTメタデータの具体的な内容
４．各装置で実行される処理の流れ
５．変形例
６．コンピュータの構成
【００１７】
＜１．システムの構成＞
【００１８】
（伝送システムの構成）
図１は、本技術を適用した伝送システムの一実施の形態の構成を示す図である。なお、システムとは、複数の装置が論理的に集合したものをいう。
【００１９】
図１において、伝送システム１は、送信側システム１０と、受信側のクライアント装置２０から構成される。伝送システム１においては、送信側システム１０から送信されるデータが、伝送路３０を介してクライアント装置２０により受信される。
【００２０】
例えば、伝送システム１では、現在策定が進められている米国の次世代放送規格であるATSC(Advanced Television Systems Committee)3.0等の所定の規格に準拠したデータ伝送が行われる。
【００２１】
送信側システム１０は、所定の規格に準拠した伝送データを送信するための処理を行う。送信側システム１０は、DASHサーバ１０１、シグナリングサーバ１０２、アプリケーションサーバ１０３、及び放送サーバ１０４から構成される。
【００２２】
DASHサーバ１０１は、MPEG-DASH(Dynamic Adaptive Streaming over HTTP)に対応した配信サービスを行うためのサーバである。DASHサーバ１０１は、外部からコンテンツのデータなどを受信する。DASHサーバ１０１は、外部からのデータに基づいて、番組やCM等のコンテンツのセグメント（DASHセグメント）のファイルを生成し、放送サーバ１０４に送信する。
【００２３】
シグナリングサーバ１０２は、外部から、シグナリングを生成するためのデータを受信する。シグナリングサーバ１０２は、外部からのデータに基づいて、シグナリングを生成し、放送サーバ１０４に送信する。なお、シグナリングサーバ１０２により生成されるシグナリングの詳細は、図３を参照して後述する。
【００２４】
アプリケーションサーバ１０３は、外部から、アプリケーションを構成するファイルを生成するためのデータを受信する。アプリケーションサーバ１０３は、外部からのデータに基づいて、アプリケーションを生成し、放送サーバ１０４に送信する。
【００２５】
なお、アプリケーションは、番組やCM等のコンテンツに付随するアプリケーションである。例えば、このようなアプリケーションとしては、HTML5(HyperText Markup Language 5)等のマークアップ言語や、JavaScript（登録商標）等のスクリプト言語で開発されたアプリケーションを用いることができる。
【００２６】
放送サーバ１０４は、DASHサーバ１０１から送信されてくるDASHセグメント、シグナリングサーバ１０２から送信されてくるシグナリング、及び、アプリケーションサーバ１０３から送信されてくるアプリケーションのデータが受信される。放送サーバ１０４は、DASHセグメント、シグナリング、及び、アプリケーションを処理し、その結果得られる多重化ストリームを、放送波として、伝送路３０を介して送信する。
【００２７】
クライアント装置２０は、所定の規格に準拠した伝送データを受信可能な受信機である。例えば、クライアント装置２０は、テレビ受像機やセットトップボックス（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セグメントを処理し、その結果得られるビデオやオーディオのデータを、デコーダ２０７に供給する。
【００４２】
デコーダ２０７は、例えば、メインSoC(System On Chip)等から構成される。デコーダ２０７は、所定の復号方式に従い、DASHクライアント２０６から供給されるデータをデコードし、その結果得られるビデオやオーディオのデータを出力部２０８に供給する。
【００４３】
出力部２０８は、例えば、出力インターフェース回路等から構成される。出力部２０８は、デコーダ２０７から供給されるデータを処理し、表示装置やスピーカなどに出力する。これにより、クライアント装置２０では、番組やCM等のコンテンツが再生され、その映像や音声が出力される。
【００４４】
ブラウザ２０９は、例えば、HTML5に対応したブラウザである。ブラウザ２０９は、制御部２０１からの制御に従い、放送ミドルウェア２０５から供給されるアプリケーションのデータを処理し、その結果得られるデータを、出力部２０８に供給する。
【００４５】
出力部２０８は、ブラウザ２０９から供給されるデータを処理し、表示装置などに出力する。これにより、クライアント装置２０では、番組等のコンテンツの映像に付随して、アプリケーションの映像が表示される。
【００４６】
ストレージ２１０は、例えば、HDD(Hard Disk Drive)等の大容量の記憶装置である。ストレージ２１０は、制御部２０１からの制御に従い、各種のデータを蓄積する。
【００４７】
なお、図２において、放送ミドルウェア２０５、DASHクライアント２０６、及びブラウザ２０９の機能（の全部又は一部）は、例えば、CPUからなる制御部２０１が、メモリ２０３に記憶された所定のプログラムを実行することで実現されるようにすることができる。
【００４８】
また、図２においては、クライアント装置２０が、LCD(Liquid Crystal Display)やOELD(Organic Electroluminescence Display)等のディスプレイやスピーカを有するようにして、出力部２０８からのデータに応じた映像や音声を出力するようにしてもよいし、外部の表示装置や外部のスピーカに対し、出力部２０８からのデータが出力されるようにしてもよい。
【００４９】
＜２．シグナリングの構成＞
【００５０】
（プロトコルスタックの構成）
図３は、本技術のプロトコルスタックの構成例を示す図である。
【００５１】
本技術では、伝送方式として、現在広く普及しているMPEG2-TS(Transport Stream)方式ではなく、通信の分野で用いられているIP(Internet Protocol)パケットをデジタル放送に用いたIP伝送方式を導入することで、より高度なサービスを提供することができるようにする。なお、ATSC3.0においても、IP伝送方式の採用が想定されている。
【００５２】
図３のプロトコルスタックにおいて、物理層(PHY：Physical Layer)とMAC層の上位の階層は、UDP/IP層とされる。UDP/IP層は、通信の階層モデルにおけるネットワーク層とトランスポート層に相当する層であり、IPアドレスとポート番号により、IPパケットとUDP(User Datagram Protocol)パケットが特定される。
【００５３】
このUDPパケットを含むIPパケットであるUDP/IPパケットには、SLT(Service Layer Signaling)メタデータを含めることができる。SLTメタデータは、サービスの選局に必要な情報など、放送ネットワークにおけるストリームやサービスの構成を示す基本情報を含む。
【００５４】
SLTメタデータは、LLS(Low Level Signaling)として規定される。すなわち、ATSC3.0では、シグナリングとして、LLS(Low Level Signaling)とSLS(Service Layer Signaling)を用いることが想定されている。このLLSは、SLSに先行して取得されるシグナリングであって、LLSに含まれる情報に従い、SLSが取得される。SLSは、サービス単位のシグナリングである。
【００５５】
なお、ATSC3.0では、その他のシグナリングとして、物理層で伝送されるL1シグナリングと、MAC層で伝送されるLMT(Link Mapping Table)メタデータが規定されている。L1シグナリングは、復調情報等を含む。LMTメタデータは、PLP(Physical Layer Pipe)と、IPアドレスやポート番号とを対応付けたマッピング情報を含む。LMTメタデータは、LLS(Link Layer Signaling)として規定される。
【００５６】
UDP/IP層に隣接する上位の階層は、ROUTE(Real-time Object Delivery over Unidirectional Transport)とされる。ROUTEは、ストリーミングファイル転送用のプロトコルであって、FLUTE(File Delivery over Unidirectional Transport)を拡張したものである。
【００５７】
このROUTEセッションにより、サービス（Service）ごとに、SLSのファイル（Service Signaling File）や、DASHセグメントのファイル（Audio/Video/CC DASH File）、LCC(Locally Cached Content)のファイル（LCC(NRT) File）が伝送される。
【００５８】
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メタデータは、他のメタデータの取得先などの情報を含む。
【００６０】
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)と称され、後者のファイルフォーマットは、セグメントフォーマットとも称される。
【００６４】
なお、LLSとしてのSLTメタデータと、SLSとしてのUSBD，S-TSID，HLST，MPD等のメタデータは、例えば、XML(Extensible Markup Language)等のマークアップ言語により記述されたテキスト形式のデータとすることができる。一方で、LMTメタデータは、バイナリ形式のデータとされる。
【００６５】
（SLSチャネルとLCCチャネルとの関係）
図４は、SLSチャネルとLCCチャネルとの関係を示す図である。
【００６６】
上述したように、SLSやLCCのファイルは、ROUTEセッションで伝送される。図４においては、ROUTEセッションのSLSチャネルで、USBDメタデータ、S-TSIDメタデータ、及びHLSTメタデータが伝送されている。ただし、クライアント装置２０では、SLSチャネルで伝送される他のメタデータに先行して、USBDメタデータを取得することで、当該USBDメタデータに記述された他のメタデータの取得先を示す情報（URL）に従い、S-TSIDメタデータやHLSTメタデータを取得することができる。
【００６７】
また、図４においては、S-TSIDに記述されたLCTチャネル（セッション）の１つが、LCCチャネルとして、ノンリアルタイムコンテンツであるLCCの転送に割り当てられている。また、LCCチャネルにおいては、ファイルモードで伝送されるEFDTにより、そのチャネルで転送するファイル群の転送制御パラメタが記述されている。ここで、ファイルモード（File Mode）は、単一のファイルを転送するモードである。一方で、パッケージモード（Package Mode）は、複数のファイルをまとめて（同梱して）パッケージとして転送するモードとなる。
【００６８】
図４の例では、EFDTの転送制御パラメタとして、"PackageFile-url"であるURLで識別されるパッケージファイル（PackageFile）と、"File-3-url"であるURLで識別されるファイル３（File-3）に関する情報が記述されている。ここで、HLSTメタデータには、EntryLocation要素の内容として、"PackageFile-url"が記述されており、クライアント装置２０では、このEntryLocation要素の内容に従い、EFDTに記述された複数の転送制御パラメタの中から、パッケージファイル（PackageFile）を取得するための転送制御パラメタを特定する。
【００６９】
そして、クライアント装置２０では、このようにして特定されたEFDTの転送制御パラメタに従い、ROUTEセッションのLCCチャネルで伝送されるパッケージファイル（PackageFile）が取得される。このパッケージファイルには、コンテンツに付随するアプリケーションを構成するファイル群が含まれる。
【００７０】
図５には、パッケージファイルの例が示されている。図５のパッケージファイルにおいては、アプリケーションを構成するファイルとして、エントリページ（EntryPage）のファイル（例えば、HTMLページファイル等）を格納したパートを例示している。また、パッケージファイルには、エントリページのファイルのほか、当該エントリページから参照される、１又は複数のリソースファイル（例えば、画像ファイルやスクリプトファイル等）などを、各パートに格納することができる。
【００７１】
なお、図４及び図５の例では、アプリケーションを構成するファイルが、パッケージファイルに格納されて伝送される場合を例示したが、アプリケーションを構成するファイルは、パッケージファイルに格納せずに、個々のファイル（独立したファイル）として、LLCチャネルで伝送されるようにしてもよい。この場合、EFDTには、転送パラメタとして、LLCチャネルで伝送される個々のファイルを特定するための情報が列挙されることになる（個々のファイルごとに、個別のTOIが割り当てられる）。
【００７２】
＜３．HLSTメタデータの具体的な内容＞
【００７３】
（HLSTメタデータの構造の例）
図６は、HLSTメタデータのフォーマットの例を示す図である。なお、図６において、要素と属性のうち、属性には「@」が付されている。また、インデントされた要素と属性は、その上位の要素に対して指定されたものとなる。
【００７４】
EntryPageCollection要素は、ルート要素であって、HTMLEntryPage要素の上位要素となる。
【００７５】
HTMLEntryPage要素は、HTML形式のエントリページのプロパティを含む。HTMLEntryPage要素は、specVersion属性、requiredCapabilities属性、EntryLocation要素、及びPrefetchHintList要素の上位要素となる。
【００７６】
specVersion属性には、エントリページのバーションアップ対応のためのバージョンを示す情報が指定される。
【００７７】
requiredCapabilities属性には、クライアント装置２０の機能が、エントリページを処理するために必要な機能にマッチしているかどうかを判別するための情報が指定される。
【００７８】
EntryLocation要素には、エントリポイントを示すURL(Uniform Resource Locator)が指定される。EntryLocation要素は、transport属性、validFrom属性、及びvalidUntil属性の上位要素となる。
【００７９】
transport属性には、アプリケーションのファイルの配信の方式が指定される。ここでは、アプリケーションのファイルが放送経由で配信される場合には、"broadcast"が指定され、アプリケーションのファイルが通信経由で配信される場合には、"broadband"が指定される。
【００８０】
validFrom属性には、アプリケーション（のHTMLページ）が有効となる期間の開始の時刻を示す開始時刻情報が指定される。この開始時刻情報には、アプリケーション（のHTMLページ）の表示を開始するタイミングが日時（dateTime型）で指定される。
【００８１】
validUntil属性には、アプリケーション（のHTMLページ）が有効となる期間の終了の時刻を示す終了時刻情報が指定される。この終了時刻情報には、アプリケーション（のHTMLページ）の表示を終了するタイミングが日時（dateTime型）で指定される。
【００８２】
すなわち、validFrom属性により指定される開始時刻と、validUntil属性により指定される終了時刻により、コンテンツに付随するアプリケーション（のHTMLページ）が有効になる期間（有効期間）が指定されることになる。
【００８３】
PrefetchHintList要素は、アプリケーションのファイルを事前に取得（プリフェッチ）しておくためのURLのリストである。PrefetchHintList要素は、item要素の上位要素となる。
【００８４】
item要素には、ファイルごとのURLが指定される。
【００８５】
なお、図６において、"Cardinality"の項目であるが、"1"が指定された場合にはその要素又は属性は必ず１つだけ指定され、"1...N"が指定された場合には、その要素又は属性は、１以上指定される。また、"Cardinality"として、"0..1"が指定された場合には、その要素又は属性を指定するかどうかは任意であり、"1..2"が指定された場合には、その要素又は属性は、1又は２だけ指定される。
【００８６】
また、"Data Type"の項目であるが、"string"が指定された場合には、その要素又は属性の値が、文字列型であることを示している。また、"Data Type"として、"anyURI"が指定された場合には、その要素又は属性が、URLの形式をした文字列を表し、"dateTime"が指定された場合には、その要素又は属性が、特定の日時を表すことを示している。
【００８７】
（HLSTメタデータの記述例）
図７は、XML形式のHLSTメタデータの記述例を示す図である。
【００８８】
図７においては、ルート要素としてのEntryPageCollection要素内に、specVersion属性により指定されるバージョン（バージョン3.0，3.2，3.5，3.5）ごとに、４つのHTMLEntryPage要素が記述されている。
【００８９】
バージョン3.0に対応した１つ目のHTMLEntryPage要素において、EntryLocation要素の開始ダグと終了タグとの間には、エントリポイントを示すURLとして、"http://www.xbc.com/pkg1"が記述される。このEntryLocation要素では、transport属性として、"broadcast"が指定され、アプリケーションのファイルが、放送経由で配信されることを示している。
【００９０】
また、EntryLocation要素において、validFrom属性の開始時刻情報として、"2016-06-30T09:00:00Z"が指定され、validUntil属性の終了時刻情報として、"2016-06-30T09:30:00Z"が指定される。すなわち、このアプリケーションの有効期間は、2016年6月30日の9:00から、2016年6月30日の9:30までの間となる。
【００９１】
また、１つ目のHTMLEntryPage要素には、PrefetchList要素として、３つのitem要素が記述されている。１つ目のitem要素には、"index.html"が指定され、２つ目のitem要素には、"logo.png"が指定され、３つ目のitem要素には、"background.jpg"が指定される。
【００９２】
なお、１つ目のHTMLEntryPage要素では、specVersion属性によりバージョンは指定されていないが、デフォルトの値が、3.0とされる。
【００９３】
バージョン3.2に対応した２つ目のHTMLEntryPage要素においては、２つのEntryLocation要素が記述されている。
【００９４】
１つ目のEntryLocation要素の開始タグと終了タグとの間には、エントリポイントを示すURLとして、"http://www.xbc.com/pkg41"が記述される。このEntryLocation要素では、transport属性として、"broadcast"が指定され、アプリケーションのファイルが、放送経由で配信される。また、１つ目のEntryLocation要素においては、validFrom属性とvalidUntil属性により、アプリケーションの有効期間として、2016年6月30日の9:00から、2016年6月30日の9:30までの間が指定される。
【００９５】
２つ目のEntryLocation要素の開始タグと終了タグとの間には、エントリポイントを示すURLとして、"http://www.xbc.com/pkg42"が記述される。このEntryLocation要素では、transport属性として、"broadband"が指定され、アプリケーションのファイルが、通信経由で配信される。また、２つ目のEntryLocation要素においては、validFrom属性とvalidUntil属性により、アプリケーションの有効期間として、2016年6月30日の9:00から、2016年6月30日の9:30までの間が指定される。
【００９６】
バージョン3.5に対応した３つ目のHTMLEntryPage要素では、requiredCapabilities属性として、"xxx"が指定され、クライアント装置２０の機能が、処理を行うために必要な機能にマッチしているかどうかが判別される。
【００９７】
また、３つ目のHTMLEntryPage要素において、EntryLocation要素の開始ダグと終了タグとの間には、エントリポイントを示すURLとして、"http://www.xbc.com/pkg6"が記述される。このEntryLocation要素では、transport属性として、"broadcast"が指定され、アプリケーションのファイルが、放送経由で配信されることを示している。また、このEntryLocation要素においては、validFrom属性とvalidUntil属性により、アプリケーションの有効期間として、2016年6月30日の9:00から、2016年6月30日の9:30までの間が指定される。
【００９８】
バージョン3.5に対応した４つ目のHTMLEntryPage要素では、requiredCapabilities属性として、"yyy"が指定され、クライアント装置２０の機能が、処理を行うために必要な機能にマッチしているかどうかが判別される。ここで、図８には、requiredCapabilities属性に、"yyy"として指定される、Capability Codeの例を示している。
【００９９】
すなわち、HTMLEntryPage要素のrequiredCapabilities属性には、図８に示したcapability_codeが指定される。例えば、capability_codeとして、"0x0101"が指定された場合には、FLUTEプロトコルを表し、"0x0102"が指定された場合には、HTTP(Hypertext Transfer Protocol)を表している。
【０１００】
なお、capability_codeについては、下記の非特許文献１の「Table 5.10 Capability Codes」にその詳細な内容が記載されている。そのため、図８のシンタックスには、capability_codeの一部を抜粋して記述している。
【０１０１】
非特許文献１：ATSC Candidate Standard：Service Announcement (A/332) Doc. S33-159r124 November 2015
【０１０２】
図７の説明に戻り、４つ目のHTMLEntryPage要素において、EntryLocation要素の開始ダグと終了タグとの間には、エントリポイントを示すURLとして、"http://www.xbc.com/pkg7"が記述される。このEntryLocation要素では、transport属性として、"broadband"が指定され、アプリケーションのファイルが、通信経由で配信されることを示している。また、このEntryLocation要素においては、validFrom属性とvalidUntil属性により、アプリケーションの有効期間として、2016年6月30日の9:00から、2016年6月30日の9:30までの間が指定される。
【０１０３】
なお、図７に示したHLSTメタデータの記述例は一例であって、例えば、XML形式の以外の他の形式を採用することもできる。また、図７の記述例では、EntryLocation要素として、アプリケーションを構成するファイルが、パッケージファイルに格納される場合を例示したが、アプリケーションを構成するファイルが、個々のファイルとして伝送される場合には、個々のファイルを特定するための情報が記述されることになる。また、図７に示したPrefetchList要素は、図６に示したPrefetchHintList要素に相当するものである。
【０１０４】
（アプリケーションの動作）
図９は、HLSTメタデータに応じたアプリケーションの動作の例を時系列で示した図である。
【０１０５】
図９においては、時間tの方向を、図中の左側から右側に向かう方向とした場合に、番組に付随したアプリケーションの起動のタイミングの例を表している。
【０１０６】
この例では、ROUTEセッションのSLSチャネルで伝送されるHLSTメタデータ（HLST Signaling）と、LCCチャネルで伝送される番組（TV Program）のコンポーネントのデータを同一の時間軸で示している。
【０１０７】
すなわち、放送サーバ１０４から、時刻t1乃至時刻t2の間に、番組Ａ（TV Program A）が放送され、時刻t2乃至時刻t3の間に、番組Ｂ（TV Program B）が放送される。一方で、放送サーバ１０４では、番組Ａの放送が開始される前に、番組Ａ用のHLSTメタデータHAとアプリケーションＡの提供が開始され、番組Ａの放送が終了する前に、HLSTメタデータHAとアプリケーションＡの提供が終了される。同様に、放送サーバ１０４では、番組Ｂの放送が開始される前に、番組Ｂ用のHLSTメタデータHBとアプリケーションＢの提供が開始され、番組Ｂの放送が終了する前に、HLSTメタデータHBとアプリケーションＢの提供が終了される。
【０１０８】
このように、番組に付随したアプリケーションを制御するためのHLSTメタデータは、各番組に対応して提供されるが、その提供を開始するタイミングが、対象の番組の開始時刻よりもはやいため、番組と、その番組に付随したアプリケーション用のHLSTメタデータのタイミングには、ずれが生じている。
【０１０９】
ここで、クライアント装置２０における、（ａ）時刻t1乃至時刻ta、（ｂ）時刻ta乃至時刻t2、（ｃ）時刻t2、（ｄ）時刻t2乃至時刻tb、及び（ｅ）時刻tb乃至時刻t3の各時間帯で想定される動作について説明する。ただし、時刻taは、時刻t1乃至時刻t2の間における任意の時刻である。また、時刻tbは、時刻t2乃至時刻t3の間における任意の時刻である。
【０１１０】
（ａ）時刻t1乃至時刻taでの動作
まず、クライアント装置２０において、時刻t1乃至時刻taの間に、番組Ａのサービスが選局され、番組Ａの再生が開始された場合を想定する。
【０１１１】
この場合、クライアント装置２０は、ROUTEセッションのSLSチャネルで、HLSTメタデータHAが伝送されているため、当該HLSTメタデータHAを取得することができる。図９に示すように、HLSTメタデータHAには、EntryLocation Aに対し、validFrom属性の属性値として、時刻t1が指定され、validUntil属性の属性値として、時刻t2が指定されている。すなわち、HLSTメタデータHAは、番組Ａに付随するアプリケーションＡについて、時刻t1乃至時刻t2の間が有効期間（有効に表示される期間）となり、その期間内であれば起動可能であることを表している。
【０１１２】
したがって、クライアント装置２０においては、時刻t1乃至時刻taの間に、番組Ａの再生が開始された場合、HLSTメタデータHAが示す有効期間（時刻t1乃至時刻t2）内となるので、番組Ａに付随してアプリケーションＡが起動されることになる。また、このアプリケーションＡは、HLSTメタデータHAが示す有効期間（時刻t1乃至時刻t2）に従い、時刻t2になったとき、番組Ａと同時に終了することになる。
【０１１３】
（ｂ）時刻ta乃至時刻t2での動作
次に、クライアント装置２０において、時刻ta乃至時刻t2の間に、番組Ａのサービスが選局され、番組Ａの再生が開始された場合を想定する。
【０１１４】
この場合、クライアント装置２０は、ROUTEセッションのSLSチャネルで、HLSTメタデータHBが伝送されているが、HLSTメタデータHAは伝送されていないため、HLSTメタデータHAを取得することができない。したがって、クライアント装置２０においては、時刻ta乃至時刻t2の間に、番組Ａの再生が開始された場合、アプリケーションＡは起動しないことになる。
【０１１５】
一方で、時刻ta乃至時刻t2の間に、ROUTEセッションのSLSチャネルで、HLSTメタデータHBが伝送されているため、クライアント装置２０は、当該HLSTメタデータHBを取得することができる。図９に示すように、HLSTメタデータHBには、EntryLocation Bに対し、validFrom属性の属性値として、時刻t2が指定され、validUntil属性の属性値として、時刻t3が指定されている。すなわち、HLSTメタデータHBは、番組Ｂに付随するアプリケーションＢについて、時刻t2乃至時刻t3の間が有効期間（有効に表示される期間）となり、その期間であれば起動可能であることを表している。
【０１１６】
したがって、クライアント装置２０においては、時刻ta乃至時刻t2の間に、番組Ａの再生が開始された場合、HLSTメタデータHBが示す有効期間（時刻t2乃至時刻t3）外となるので、アプリケーションＢが起動されることはない。しかしながら、HLSTメタデータHBには、事前取得情報（PrefetchHintList要素のitem要素の内容）として、アプリケーションＢを構成するファイルの取得先を示すURLのリストが含まれている。クライアント装置２０は、このURLのリストに従い、ROUTEセッションのLCCチャネルで伝送される、エントリページファイルやリソースファイル等のアプリケーションＢを構成するファイルを、事前に取得（プリフェッチ）し、ストレージ２１０に蓄積（キャッシュ）しておくことができる。
【０１１７】
（ｃ）時刻t2での動作
次に、クライアント装置２０において、時刻t2に、再生中の番組が、番組Ａから番組Ｂに切り替わる場合を想定する。
【０１１８】
この場合、クライアント装置２０は、取得済みのHLSTメタデータHBが示す有効期間（時刻t2乃至時刻t3）内になったので、時刻ta乃至時刻t2の間にあらかじめ取得（プリフェッチ）しておいたアプリケーションＢを構成するファイルを、ストレージ２１０から読み出して、アプリケーションＢを起動する。これにより、番組Ｂに付随してアプリケーションＢを、迅速に起動することができる。また、このアプリケーションＢは、HLSTメタデータHBが示す有効期間（時刻t2乃至時刻t3）に従い、時刻t3になったとき、番組Ｂと同時に終了することになる。
【０１１９】
（ｄ）時刻t2乃至時刻tbでの動作
次に、クライアント装置２０において、時刻t2乃至時刻tbの間に、番組Ｂのサービスが選局され、番組Ｂの再生が開始された場合を想定する。
【０１２０】
この場合、クライアント装置２０は、ROUTEセッションのSLSチャネルで、HLSTメタデータHBが伝送されているため、当該HLSTメタデータHBを取得することができる。したがって、クライアント装置２０においては、時刻t2乃至時刻tbの間に、番組Ｂの再生が開始された場合、HLSTメタデータHBが示す有効期間（時刻t2乃至時刻t3）内となるので、番組Ｂに付随してアプリケーションＢが起動されることになる。また、このアプリケーションＢは、HLSTメタデータHBが示す有効期間（時刻t2乃至時刻t3）に従い、時刻t3になったとき、番組Ｂと同時に終了することになる。
【０１２１】
（ｅ）時刻tb乃至時刻t3での動作
最後に、クライアント装置２０において、時刻tb乃至時刻t3の間に、番組Ｂのサービスが選局され、番組Ｂの再生が開始された場合を想定する。
【０１２２】
この場合、クライアント装置２０は、ROUTEセッションのSLSチャネルで、HLSTメタデータHBが伝送されていないため、HLSTメタデータHBを取得することができない。したがって、クライアント装置２０においては、時刻tb乃至時刻t3の間に、番組Ｂの再生が開始された場合、アプリケーションＢは起動しないことになる。
【０１２３】
なお、この場合には、SLSチャネルで、次の番組用のHLSTメタデータが伝送されているので、当該HLSTメタデータを取得して、次の番組用のアプリケーションを事前に取得（プリフェッチ）しておくことが可能となる。そして、時刻t3になって、次の番組が開始されたときには、事前に取得しておいたアプリケーションが起動されることになる。
【０１２４】
以上のように、本技術では、HLSTメタデータを、アプリケーションと番組に対し、１対１で紐付けて、紐付けられた番組よりもはやく、クライアント装置２０により取得されるようにして、当該HLSTメタデータが示す有効期間内でのみ、紐付けられたアプリケーションが起動されるようにしている。そのため、HLSTメタデータと、番組と、アプリケーションを１つのまとまりとして取り扱うことができ、前後に再生される他の番組やアプリケーションの影響を受けずに処理を行うことができる。
【０１２５】
ところで、アプリケーション制御情報として知られているAITは、その送出のタイミングにより、アプリケーションのライフサイクルを制御しているため、時系列での連続性を必要とする。そのため、AITを用いる場合には、例えば、対象のアプリケーションを起動させるために、実行中の前のアプリケーションを終了させるなどの過渡的な処理が必要で、放送局側で、番組の進行と、AITによるアプリケーションの動作の制御を全体に渡って管理する必要があり、管理が煩雑になってしまう。一方で、本技術では、１つのHLSTメタデータは独立しているため、他のアプリケーションや他の番組とは関係がないため、放送局側ではその管理が容易であり、結果として、アプリケーションの動作を容易に制御することが可能となる。
【０１２６】
なお、上述したように、各番組の終了間際の時間帯（例えば、時刻ta乃至時刻t2や時刻tb乃至時刻t3等）では、再生中の番組用のHLSTメタデータが伝送されておらず（次の番組用のHLSTメタデータが伝送されている）、再生中の番組に付随したアプリケーションを起動することはできない。しかしながら、実際の運用では、アプリケーションを起動できない時間帯（例えば、時刻ta乃至時刻t2や時刻tb乃至時刻t3等）は、アプリケーションを起動できる時間帯（例えば、時刻t1乃至時刻taや時刻t2乃至時刻tb等）と比べて、非常に短く（例えば1/10程度）、さらに時間帯が番組の終了間際であるため、運用上問題になることはない。
【０１２７】
＜４．各装置で実行される処理の流れ＞
【０１２８】
次に、図１０及び図１１のフローチャートを参照して、送信側システム１０とクライアント装置２０で実行される処理の流れを説明する。
【０１２９】
（送受信処理）
まず、図１０のフローチャートを参照して、放送サーバ１０４とクライアント装置２０により実行される送受信処理の流れを説明する。
【０１３０】
ステップＳ１０１乃至Ｓ１０３においては、放送サーバ１０４によって、DASHサーバ１０１、シグナリングサーバ１０２、及びアプリケーションサーバ１０３により生成されたDASHセグメント、シグナリング、及びアプリケーションが取得される。
【０１３１】
ステップＳ１０４において、放送サーバ１０４は、ステップＳ１０１乃至Ｓ１０３の処理で取得されたDASHセグメント、シグナリング、及びアプリケーションを含む多重化ストリームを生成する。
【０１３２】
ステップＳ１０５において、放送サーバ１０４は、ステップＳ１０４の処理で生成された多重化ストリームに対し、変調処理を行い、その結果得られる放送波を、伝送路３０を介して送信する。
【０１３３】
ステップＳ２０１において、クライアント装置２０の受信部２０４は、放送サーバ１０から、伝送路３０を介して送信されてくる放送波を受信する。ここでは、受信部２０４により、放送波に対する復調処理が行われることで、多重化ストリームが得られる。
【０１３４】
ステップＳ２０２において、クライアント装置２０の放送ミドルウェア２０５は、ステップＳ２０１の処理で得られる多重化ストリームに含まれるシグナリングを処理する。
【０１３５】
ステップＳ２０３において、クライアント装置２０のDASHクライアント２０６は、ステップＳ２０２の処理で得られる処理結果（シグナリングの処理結果）に基づいて、ステップＳ２０１の処理で得られる多重化ストリームに含まれるDASHセグメントを処理する。
【０１３６】
ステップＳ２０４において、クライアント装置２０のデコーダ２０７は、ステップＳ２０３の処理で得られるデータをデコードする。
【０１３７】
ステップＳ２０５において、クライアント装置２０の出力部２０８は、ステップＳ２０４の処理で得られるデータを処理し、表示装置やスピーカに出力する。これにより、クライアント装置２０においては、ユーザにより選局されたサービスに応じた番組が再生される。
【０１３８】
以上、送受信処理の流れについて説明した。
【０１３９】
（アプリケーション制御処理）
次に、図１１のフローチャートを参照して、クライアント装置２０により実行されるアプリケーション制御処理の流れを説明する。なお、このアプリケーション制御処理は、例えば、クライアント装置２０において、図１０の送受信処理が実行され、選局されたサービスに応じた番組が再生されるときに実行される。
【０１４０】
ステップＳ２３１において、放送ミドルウェア２０５は、ROUTEセッションのSLSチャネルで伝送されるSLSを取得する。このSLSには、サービスごとに、USBD，S-TSID，HLST等のメタデータが含まれており、USBDメタデータの記述内容に従い、S-TSIDメタデータやHLSTメタデータが取得される。
【０１４１】
ステップＳ２３２において、放送ミドルウェア２０５は、ステップＳ２３１の処理で取得されたSLSを、パースする。このパースによって、USBDメタデータに応じて取得されたS-TSIDメタデータやHLSTメタデータの記述内容が解析される。
【０１４２】
ステップＳ２３３において、放送ミドルウェア２０５は、ステップＳ２３２の処理で得られるHLSTメタデータの解析結果に基づいて、対象のアプリケーション（のHTMLページ）が有効期間内となるかどうかを判定する。
【０１４３】
ここで、HLSTメタデータには、有効期間情報として、対象のアプリケーションを構成するHTMLページ（エントリページ）が有効となる有効期間の開始の時刻を示す開始時刻情報（validFrom属性の属性値）と、当該有効期間の終了の時刻を示す終了時刻情報（validUntil属性の属性値）とが含まれている。そのため、クライアント装置２０では、この有効期間情報を用いて、対象のアプリケーションが、開始時刻情報が示す時刻と終了時刻情報が示す時刻により定められる有効期間内となるかどうかを判定することができる。
【０１４４】
ステップＳ２３３において、対象のアプリケーションが有効期間内ではない、すなわち、有効期間よりも前であると判定された場合、処理は、ステップＳ２３４に進められる。
【０１４５】
ステップＳ２３４において、放送ミドルウェア２０５は、ROUTEセッションのLCCチャネルで伝送されるEFDTに従い、LCCチャネルで伝送される必要なファイルを取得する。
【０１４６】
ここでは、まず、ステップＳ２３２の処理で得られるS-TSIDメタデータやHLSTメタデータの解析結果に従い、LCCチャネルで伝送されるEFDTが取得される。次に、当該EFDTをパースして、その結果得られるEFDTの解析結果に従い、LCCチャネルで伝送されるパッケージファイルが取得される。そして、このパッケージファイルのマルチパート部分に格納されたエントリページファイル（例えば、HTMLページファイル等）と、そこから参照されるリソースファイル群（例えば、画像ファイルやスクリプトファイル等）が、必要なファイルとして取得される。
【０１４７】
なお、HLSTメタデータには、事前取得情報（PrefetchHintList要素のitem要素の内容）として、エントリページファイルやリソースファイルの取得先を示すURLのリストが含まれるが、このリストのURLに応じたファイルが、パッケージファイルのマルチパート部分に格納されている。そのため、放送ミドルウェア２０５は、HLSTメタデータに含まれる事前取得情報により、事前に取得すべきファイル（プリフェッチするファイル）を特定することができる。
【０１４８】
このようにして取得されたエントリページファイルやリソースファイル群は、ストレージ２１０に蓄積（キャッシュ）される（Ｓ２３５）。
【０１４９】
その後、所定の間隔で、対象のアプリケーション（のHTMLページ）が有効期間内となるかどうかが判定され（Ｓ２３６）、対象のアプリケーションが未だ有効期間内ではないと判定された場合（Ｓ２３６の「NO」）、ステップＳ２３６の判定処理が繰り返される。そして、一定期間が経過することで、対象のアプリケーションが有効期間内であると判定された場合（Ｓ２３６の「YES」）、処理は、ステップＳ２３７に進められる。
【０１５０】
ステップＳ２３７において、ブラウザ２０９は、ステップＳ２３５の処理で蓄積されたファイルを読み出し、アプリケーションを起動する。ここでは、アプリケーションの最初のエントリとなるエントリページ（Entry Page）が表示される。このエントリページは、HTMLページファイルからなり、画像ファイル（例えばjpegファイル）や、スクリプトファイル（例えば、JavaScript（登録商標）のコードが記述されたファイル）等の各種のリソースファイルを参照することで、これらのファイルに応じたアプリケーションの映像が表示される。
【０１５１】
このように、対象のアプリケーション（のHTMLページ）が有効期間内とはならない場合には、事前に対象のアプリケーションを取得して蓄積しておき、有効期間内になるのを待って、蓄積しておいた対象のアプリケーションを起動することになる。
【０１５２】
ステップＳ２３７の処理で、アプリケーションが起動されると、処理は、ステップＳ２４０に進められる。
【０１５３】
一方で、ステップＳ２３３において、対象のアプリケーションが有効期間内、すなわち、開始時刻情報（validFrom属性の属性値）が示す時刻から、終了時刻情報（validUntil属性の属性値）が示す時刻までの間であると判定された場合、処理は、ステップＳ２３８に進められる。
【０１５４】
ステップＳ２３８において、放送ミドルウェア２０５は、ROUTEセッションのLCCチャネルで伝送されるEFDTに従い、LCCチャネルで伝送される必要なファイルを取得する。なお、ステップＳ２３８の処理で、エントリページファイルやリソースファイル群を取得するための処理は、上述したステップＳ２３４の処理と同様であるため、ここでは、その説明を省略する。
【０１５５】
ステップＳ２３９において、ブラウザ２０９は、ステップＳ２３８の処理で取得されたファイルに基づいて、アプリケーションを起動する。ここでは、エントリページが、画像ファイル等の各種のリソースファイルを参照することで、これらのファイルに応じたアプリケーションの映像が表示される。
【０１５６】
このように、対象のアプリケーション（のHTMLページ）が有効期間内となる場合には、対象のアプリケーションを取得し、即時に、その対象のアプリケーションを起動することになる。
【０１５７】
ステップＳ２３９の処理で、アプリケーションが起動されると、処理は、ステップＳ２４０に進められる。
【０１５８】
ステップＳ２４０においては、ステップＳ２３７又はＳ２３９の処理で対象のアプリケーションが起動された後、所定の間隔で、対象のアプリケーション（のHTMLページ）が有効期間内となるかどうかが判定される。ステップＳ２４０において、対象のアプリケーションが、有効期間内であると判定された場合、ステップＳ２４０の判定処理が繰り返される。すなわち、この場合、対象のアプリケーションの実行が継続される。
【０１５９】
そして、一定期間が経過することで、対象のアプリケーションが、有効期間外であると判定された場合（Ｓ２４０の「NO」）、処理は、ステップＳ２４１に進められる。ステップＳ２４１において、ブラウザ２０９は、実行中のアプリケーションを終了する。
【０１６０】
すなわち、ステップＳ２３７又はＳ２３９の処理で起動された対象のアプリケーションが、ステップＳ２４１の処理で終了されるので、HLSTメタデータに含まれる有効期間情報により定められる有効期間内のみ、対象の番組に付随して、対象のアプリケーションが実行されていたことになる。
【０１６１】
なお、上述したステップＳ２３５の処理で、エントリページファイルやリソースファイル群を、ストレージ２１０に蓄積する際に、それらのファイルを蓄積する十分な容量が、ストレージ２１０にない場合には、ファイルのストレージ２１０への蓄積を中止するようにしてもよい。また、対象のアプリケーションが存在しない場合には、例えば、HLSTメタデータのEntryLocation要素の記述を省略したり、あるいは、HLSTメタデータそのものを伝送しないようにしたりするなどの運用で対処することができる。
【０１６２】
以上、アプリケーション制御処理の流れについて説明した。
【０１６３】
＜５．変形例＞
【０１６４】
上述した説明としては、デジタル放送の規格として、米国等で採用されている方式であるATSC（特に、ATSC3.0）を説明したが、本技術は、日本等が採用する方式であるISDB(Integrated Services Digital Broadcasting)や、欧州の各国等が採用する方式であるDVB(Digital Video Broadcasting)などに適用するようにしてもよい。
【０１６５】
また、上述した説明では、IP伝送方式が採用されるATSC3.0を例にして説明したが、IP伝送方式に限らず、例えば、MPEG2-TS(Transport Stream)方式等の他の方式に適用するようにしてもよい。さらに、上述した説明では、コンテンツのデータを伝送する方式として、MPEG-DASHに対応した方式を採用した場合を説明したが、MPEG-DASHに対応した方式以外の他の方式を用いるようにしてもよい。
【０１６６】
また、デジタル放送の規格としては、地上波放送のほか、放送衛星（BS：Broadcasting Satellite)や通信衛星（CS：Communications Satellite）等を利用した衛星放送や、ケーブルテレビ（CATV）等の有線放送などの規格に適用することができる。
【０１６７】
また、上述した説明では、伝送システム１（図１）として、コンテンツやアプリケーションは、放送サーバ１０４（図１）により、放送経由で配信される場合を説明したが、放送サーバ１０４の代わりに、通信サーバを設けて、当該通信サーバによって、クライアント装置２０に対し、コンテンツやアプリケーション（の全部又は一部のデータ）が、インターネットや電話網などの通信回線を介して、通信経由で配信されるようにしてもよい。すなわち、クライアント装置２０においては、放送経由又は通信経由で取得されたコンテンツに付随して、放送経由又は通信経由で取得されたアプリケーションが実行される。
【０１６８】
さらに、図１の伝送システムにおいては、説明の簡略化のため、放送局の放送サーバ１０４が単独で、マルチプレクサと変調器を有するものとして、その構成を説明したが、一般的なデジタル放送のシステムでは、マルチプレクサと変調器は異なる場所に設置されるものである。例えば、マルチプレクサは、放送局内に設置される一方で、変調器は、送信局（送信所）に設置される。また、図１の送信側システム１０全体を１つの装置と捉えて、各サーバの機能を有する装置とすることもできる。
【０１６９】
また、上述したシグナリングやパケットなどの名称は、一例であって、他の名称が用いられる場合がある。ただし、これらの名称の違いは、形式的な違いであって、対象のシグナリングやパケットなどの実質的な内容が異なるものではない。例えば、USBD(User Service Bundle Description)は、USD(User Service Description)などと称される場合がある。また、例えば、LCC(Locally Cached Content)は、NRT(Non Real Time)コンテンツなどと称され、AIT(Application Information Table)は、AST(Application Signaling Table)などと称される場合がある。
【０１７０】
さらに、シグナリングがXML等のマークアップ言語により記述される場合において、それらの要素や属性の名称は一例であって、他の名称が採用されるようにしてもよい。ただし、これらの名称の違いは、形式的な違いであって、それらの要素や属性の実質的な内容が異なるものではない。
【０１７１】
また、上述した説明では、コンテンツに付随するアプリケーションは、HTML5などのマークアップ言語やJavaScript（登録商標）等のスクリプト言語で開発されたアプリケーションに限らず、例えば、Java（登録商標）などのプログラミング言語で開発されたアプリケーションであってもよい。また、アプリケーションは、ブラウザにより実行されるアプリケーションに限らず、いわゆるネイティブアプリケーションとして、OS（Operating System）環境などで実行されるようにしてもよい。さらに、上述したコンテンツには、動画や音楽のほか、例えば、電子書籍やゲーム、広告など、あらゆるコンテンツを含めることができる。
【０１７２】
また、本技術は、伝送路として、放送網以外の伝送路、すなわち、例えば、インターネットや電話網等の通信回線（通信網）などを利用することを想定して規定されている所定の規格（デジタル放送の規格以外の規格）などにも適用することができる。その場合には、伝送システム１（図１）の伝送路３０として、インターネットや電話網などの通信回線が利用され、放送サーバ１０４は、インターネット上に設けられた通信サーバとすることができる。そして、当該通信サーバと、クライアント装置２０とが、伝送路３０（通信回線）を介して双方向の通信を行うことになる。
【０１７３】
＜６．コンピュータの構成＞
【０１７４】
上述した一連の処理は、ハードウェアにより実行することもできるし、ソフトウェアにより実行することもできる。一連の処理をソフトウェアにより実行する場合には、そのソフトウェアを構成するプログラムが、コンピュータにインストールされる。図１２は、上述した一連の処理をプログラムにより実行するコンピュータのハードウェアの構成例を示す図である。
【０１７５】
コンピュータ１０００において、CPU(Central Processing Unit)１００１、ROM(Read Only Memory)１００２、RAM(Random Access Memory)１００３は、バス１００４により相互に接続されている。バス１００４には、さらに、入出力インターフェース１００５が接続されている。入出力インターフェース１００５には、入力部１００６、出力部１００７、記録部１００８、通信部１００９、及び、ドライブ１０１０が接続されている。
【０１７６】
入力部１００６は、キーボード、マウス、マイクロフォンなどよりなる。出力部１００７は、ディスプレイ、スピーカなどよりなる。記録部１００８は、ハードディスクや不揮発性のメモリなどよりなる。通信部１００９は、ネットワークインターフェースなどよりなる。ドライブ１０１０は、磁気ディスク、光ディスク、光磁気ディスク、又は半導体メモリなどのリムーバブル記録媒体１０１１を駆動する。
【０１７７】
以上のように構成されるコンピュータ１０００では、CPU１００１が、ROM１００２や記録部１００８に記録されているプログラムを、入出力インターフェース１００５及びバス１００４を介して、RAM１００３にロードして実行することにより、上述した一連の処理が行われる。
【０１７８】
コンピュータ１０００（CPU１００１）が実行するプログラムは、例えば、パッケージメディア等としてのリムーバブル記録媒体１０１１に記録して提供することができる。また、プログラムは、ローカルエリアネットワーク、インターネット、デジタル衛星放送といった、有線又は無線の伝送媒体を介して提供することができる。
【０１７９】
コンピュータ１０００では、プログラムは、リムーバブル記録媒体１０１１をドライブ１０１０に装着することにより、入出力インターフェース１００５を介して、記録部１００８にインストールすることができる。また、プログラムは、有線又は無線の伝送媒体を介して、通信部１００９で受信し、記録部１００８にインストールすることができる。その他、プログラムは、ROM１００２や記録部１００８に、あらかじめインストールしておくことができる。
【０１８０】
ここで、本明細書において、コンピュータがプログラムに従って行う処理は、必ずしもフローチャートとして記載された順序に沿って時系列に行われる必要はない。すなわち、コンピュータがプログラムに従って行う処理は、並列的あるいは個別に実行される処理（例えば、並列処理あるいはオブジェクトによる処理）も含む。また、プログラムは、１のコンピュータ（プロセッサ）により処理されるものであってもよいし、複数のコンピュータによって分散処理されるものであってもよい。
【０１８１】
なお、本技術の実施の形態は、上述した実施の形態に限定されるものではなく、本技術の要旨を逸脱しない範囲において種々の変更が可能である。
【０１８２】
また、本技術は、以下のような構成をとることができる。
【０１８３】
（１）
コンテンツを受信する受信部と、
前記コンテンツに付随するアプリケーションが有効になる期間を示す有効期間情報に基づいて、前記アプリケーションの起動を制御する制御部と
を備える受信装置。
（２）
前記制御部は、前記有効期間情報が示す期間内のみ、前記コンテンツに付随して、前記アプリケーションが起動されるようにする
（１）に記載の受信装置。
（３）
前記アプリケーションは、１又は複数のファイルから構成され、
前記有効期間情報は、前記ファイルから得られる対象のページが有効となる期間の開始の時刻を示す開始時刻情報と、前記ファイルから得られる対象のページが有効となる期間の終了の時刻を示す終了時刻情報とからなる
（２）に記載の受信装置。
（４）
前記制御部は、前記アプリケーションの取得先を示す事前取得情報に基づいて、前記有効期間情報が示す期間に応じて、前記アプリケーションが取得されるようにする
（２）又は（３）に記載の受信装置。
（５）
前記事前取得情報は、前記有効期間情報が示す期間の前に、前記アプリケーションが取得されるようにするための情報である
（４）に記載の受信装置。
（６）
前記アプリケーションは、１又は複数のファイルから構成され、
前記事前取得情報は、前記ファイルごとの取得先を示す情報である
（５）に記載の受信装置。
（７）
前記事前取得情報は、前記ファイルに応じたURL(Uniform Resource Locator)のリストである
（６）に記載の受信装置。
（８）
前記有効期間情報と前記事前取得情報は、サービスごとに提供される、前記アプリケーションを制御するための制御情報に含まれ、
前記受信部は、前記コンテンツとともに送信される、前記制御情報を受信する
（４）乃至（７）のいずれかに記載の受信装置。
（９）
１つの前記制御情報は、１つの前記アプリケーションを、１つの前記コンテンツに対して付随させるための情報である
（８）に記載の受信装置。
（１０）
受信装置のデータ処理方法において、
前記受信装置が、
コンテンツを受信し、
前記コンテンツに付随するアプリケーションが有効になる期間を示す有効期間情報に基づいて、前記アプリケーションの起動を制御する
ステップを含むデータ処理方法。
（１１）
コンテンツに付随するアプリケーションが有効になる期間を示す有効期間情報を生成する生成部と、
前記コンテンツとともに、前記有効期間情報を送信する送信部と
を備える送信装置。
（１２）
前記有効期間情報は、特定の期間内のみ、前記コンテンツに付随して前記アプリケーションが起動されるようにするための情報である
（１１）に記載の送信装置。
（１３）
前記アプリケーションは、１又は複数のファイルから構成され、
前記有効期間情報は、前記ファイルから得られる対象のページが有効となる期間の開始の時刻を示す開始時刻情報と、前記ファイルから得られる対象のページが有効となる期間の終了の時刻を示す終了時刻情報とからなる
（１２）に記載の送信装置。
（１４）
前記生成部は、前記アプリケーションの取得先を示す情報であって、前記有効期間情報が示す期間に応じて前記アプリケーションが取得されるようにするための情報である事前取得情報を生成し、
前記送信部は、前記事前取得情報を送信する
（１２）又は（１３）に記載の送信装置。
（１５）
前記事前取得情報は、前記有効期間情報が示す期間の前に、前記アプリケーションが取得されるようにするための情報である
（１４）に記載の送信装置。
（１６）
前記アプリケーションは、１又は複数のファイルから構成され、
前記事前取得情報は、前記ファイルごとの取得先を示す情報である
（１５）に記載の送信装置。
（１７）
前記事前取得情報は、前記ファイルに応じたURLのリストである
（１６）に記載の送信装置。
（１８）
前記生成部は、前記有効期間情報と前記事前取得情報を、サービスごとに提供される、前記アプリケーションを制御するための制御情報に含めて生成し、
前記送信部は、前記コンテンツとともに、前記制御情報を送信する
（１４）乃至（１７）のいずれかに記載の送信装置。
（１９）
１つの前記制御情報は、１つの前記アプリケーションを、１つの前記コンテンツに対して付随させるための情報である
（１８）に記載の送信装置。
（２０）
送信装置のデータ処理方法において、
前記送信装置が、
コンテンツに付随するアプリケーションが有効になる期間を示す有効期間情報を生成し、
前記コンテンツとともに、前記有効期間情報を送信する
ステップを含むデータ処理方法。
【符号の説明】
【０１８４】
１  伝送システム，  １０  送信側システム，  ２０  クライアント装置，  ３０  伝送路，  １０１  DASHサーバ，  １０２  シグナリングサーバ，  １０３  アプリケーションサーバ，  １０４  放送サーバ，  ２０１  制御部，  ２０２  入力部，  ２０３  メモリ，  ２０４  受信部，  ２０５  放送ミドルウェア，  ２０６  DASHクライアント，  ２０７  デコーダ，  ２０８  出力部，  ２０９  ブラウザ，  ２１０  ストレージ，  １０００  コンピュータ，  １００１  CPU
【図１】
2017212932.tif 000003
【図２】
2017212932.tif 000004
【図３】
2017212932.tif 000005
【図４】
2017212932.tif 000006
【図５】
2017212932.tif 000007
【図６】
2017212932.tif 000008
【図７】
2017212932.tif 000009
【図８】
2017212932.tif 000010
【図９】
2017212932.tif 000011
【図１０】
2017212932.tif 000012
【図１１】
2017212932.tif 000013
【図１２】
2017212932.tif 000014
【国際調査報告】
2017212932.tif 000015
2017212932.tif 000016
2017212932.tif 000017
2017212932.tif 000018