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

Abstract

本技術は、レジデントアプリケーションの実装負担をより少なくして、非リアルタイムのコンテンツのダウンロード再生を行うことができるようにする受信装置、送信装置、及び、データ処理方法に関する。
受信装置は、デジタル放送信号に含まれる第１のアプリケーションであって、非リアルタイムで再生されるコンテンツのダウンロードを処理する第１のアプリケーションを取得し、第１のアプリケーションの動作に応じて、デジタル放送信号に含まれるメタデータであって、コンテンツのダウンロードを制御するための情報を含むメタデータを取得し、メタデータに基づいて、第１のアプリケーションの動作を制御して、デジタル放送信号に含まれるコンテンツのダウンロードを処理する。本技術は、例えば、テレビ受像機に適用することができる。

Description

本技術は、受信装置、送信装置、及び、データ処理方法に関し、特に、レジデントアプリケーションの実装負担をより少なくして、非リアルタイムのコンテンツのダウンロード再生を行うことができるようにした受信装置、送信装置、及び、データ処理方法に関する。

放送の分野では、NRT(Non Real Time)サービスと称される技術が知られている（例えば、非特許文献１参照）。NRTサービスでは、受信装置において、非リアルタイムのコンテンツ（NRTコンテンツ）の蓄積予約に応じて、放送局（の送信装置）から送信されるNRTコンテンツのダウンロードが行われ、その後、蓄積されたNRTコンテンツの再生が行われる。

ATSC Standard Non-Real-Time Content Delivery（A/103:2014）

ところで、NRTサービスのように、受信装置で、NRTコンテンツのダウンロード再生を行う運用が行われる場合に、受信装置に内蔵されたレジデントアプリケーションの実装に、大きな負担がかかることがある。そのため、このような運用が行われる場合に、レジデントアプリケーションの実装負担をより少なくして、NRTコンテンツのダウンロード再生を行うことができるようにするための提案が要請されていた。

本技術はこのような状況に鑑みてなされたものであり、レジデントアプリケーションの実装負担をより少なくして、非リアルタイムのコンテンツのダウンロード再生を行うことができるようにするものである。

本技術の第１の側面の受信装置は、デジタル放送信号を受信する受信部と、前記デジタル放送信号に含まれる第１のアプリケーションであって、非リアルタイムで再生されるコンテンツのダウンロードを処理する前記第１のアプリケーションを取得する第１の取得部と、前記第１のアプリケーションの動作に応じて、前記デジタル放送信号に含まれるメタデータであって、前記コンテンツのダウンロードを制御するための情報を含む前記メタデータを取得する第２の取得部と、前記メタデータに基づいて、前記第１のアプリケーションの動作を制御して、前記デジタル放送信号に含まれる前記コンテンツのダウンロードを処理する制御部とを備える受信装置である。

本技術の第１の側面の受信装置は、独立した装置であってもよいし、１つの装置を構成している内部ブロックであってもよい。また、本技術の第１の側面のデータ処理方法は、上述した本技術の第１の側面の受信装置に対応するデータ処理方法である。

本技術の第１の側面の受信装置、及び、データ処理方法においては、デジタル放送信号が受信され、前記デジタル放送信号に含まれる第１のアプリケーションであって、非リアルタイムで再生されるコンテンツのダウンロードを処理する前記第１のアプリケーションが取得され、前記第１のアプリケーションの動作に応じて、前記デジタル放送信号に含まれるメタデータであって、前記コンテンツのダウンロードを制御するための情報を含む前記メタデータが取得され、前記メタデータに基づいて、前記第１のアプリケーションの動作を制御して、前記デジタル放送信号に含まれる前記コンテンツのダウンロードが処理される。

本技術の第２の側面の送信装置は、非リアルタイムで再生されるコンテンツのダウンロードを制御するための情報を含むメタデータを生成する第１の生成部と、前記コンテンツのダウンロードを処理する第１のアプリケーションを生成する第２の生成部と、前記メタデータ及び前記第１のアプリケーションを、デジタル放送信号に含めて送信する送信部とを備える送信装置である。

本技術の第２の側面の送信装置は、独立した装置であってもよいし、１つの装置を構成している内部ブロックであってもよい。また、本技術の第２の側面のデータ処理方法は、上述した本技術の第２の側面の送信装置に対応するデータ処理方法である。

本技術の第２の側面の送信装置、及び、データ処理方法においては、非リアルタイムで再生されるコンテンツのダウンロードを制御するための情報を含むメタデータが生成され、前記コンテンツのダウンロードを処理する第１のアプリケーションが生成され、前記メタデータ及び前記第１のアプリケーションが、デジタル放送信号に含めて送信される。

本技術の第１の側面、及び、第２の側面によれば、レジデントアプリケーションの実装負担をより少なくして、非リアルタイムのコンテンツのダウンロード再生を行うことができる。

なお、ここに記載された効果は必ずしも限定されるものではなく、本開示中に記載されたいずれかの効果であってもよい。

本技術を適用した伝送システムの一実施の形態の構成を示す図である。 本技術を適用したIP伝送方式のプロトコルスタックを示す図である。 通常のNRTサービスの概要を説明する図である。 本技術のNRTサービスの概要を説明する図である。 本技術のNRTサービスのコンセプトモデルを示す図である。 NRT連動TVサービスのシナリオの例を示す図である。 フォアグランドNRTサービスのシナリオの例を示す図である。 バックグラウンドNRTサービス（APPデータタイプ）のシナリオの例を示す図である。 バックグラウンドNRTサービス（APPデータタイプ）におけるアプリケーションとストレージのデータの関係を示す図である。 バックグラウンドNRTサービス（RAWデータタイプ）のシナリオの例を示す図である。 バックグラウンドNRTサービス（RAWデータタイプ）におけるアプリケーションとストレージのデータの関係を示す図である。 NRTサービスの状態遷移図を示す図である。 NRTサービスのシナリオの他の例を示す図である。 プログラム予約選局APIの例を示す図である。 NRTダウンロードAPIの例を示す図である。 アプリケーション遷移APIの例を示す図である。 その他のAPIの例を示す図である。 DITのシンタックスの例を示す図である。 送信装置の構成例を示す図である。 受信装置の構成例を示す図である。 受信装置におけるソフトウェアとハードウェアの階層構造の例を示す図である。 送信処理の流れについて説明するフローチャートである。 選局処理の流れについて説明するフローチャートである。 NRTサービス対応処理の流れについて説明するフローチャートである。 バックグラウンドNRTサービス対応処理の流れについて説明するフローチャートである。 イベント対応処理の流れについて説明するフローチャートである。 コンピュータの構成例を示す図である。

以下、図面を参照しながら本技術の実施の形態について説明する。なお、説明は以下の順序で行うものとする。

１．システムの構成
２．IP伝送方式によるデジタル放送の概要
３．NRTサービスの運用例
（１）NRT連動TVサービス
（２）フォアグランドNRTサービス
（３）バックグラウンドNRTサービス
（３−１）APPデータタイプ
（３−２）RAWデータタイプ
４．NRTサービスで用いられるAPIの例
５．シンタックスの例
６．各装置の構成
７．各装置で実行される処理の流れ
８．変形例
９．コンピュータの構成

＜１．システムの構成＞

（伝送システムの構成例）
図１は、本技術を適用した伝送システムの一実施の形態の構成を示す図である。なお、システムとは、複数の装置が論理的に集合したものをいう。

図１において、伝送システム１は、送信装置１０と受信装置２０から構成される。この伝送システム１では、ATSC(Advanced Television Systems Committee)3.0等を採用したデジタル放送の規格に準拠したデータ伝送が行われる。なお、ATSC3.0は、米国等で採用されている放送規格であるATSCの次世代放送規格である。

送信装置１０は、テレビ番組等の放送コンテンツを含む放送ストリームを、デジタル放送信号によって、伝送路３０を介して送信する。また、送信装置１０は、非リアルタイムのNRT(Non Real Time)コンテンツを放送ストリームに含めて送信することができる。

受信装置２０は、送信装置１０から伝送路３０を介して送信されてくるデジタル放送信号を受信して、放送ストリームに含まれる放送コンテンツを処理し、テレビ番組等の放送コンテンツの映像や音声を出力する。また、受信装置２０は、放送ストリームに含まれるNRTコンテンツを蓄積し、蓄積されたNRTコンテンツを再生（ダウンロード再生）することができる。

なお、図１の伝送システム１においては、説明を簡単にするために、受信装置２０を１つだけ図示しているが、受信装置２０は複数設けることができ、送信装置１０が送信するデジタル放送信号は、伝送路３０を介して複数の受信装置２０で同時に受信することができる。

また、送信装置１０も複数設けることができる。複数の送信装置１０のそれぞれでは、別個のチャネルとしての、例えば、別個の周波数帯域で、放送ストリームを含むデジタル放送信号を送信し、受信装置２０では、複数の送信装置１０のそれぞれのチャンネルの中から、放送ストリームを受信するチャネルを選択することができる。

さらに、図１の伝送システム１において、伝送路３０は、地上波放送のほか、例えば、放送衛星（BS：Broadcasting Satellite）や通信衛星（CS：Communications Satellite）を利用した衛星放送、あるいは、ケーブルを用いた有線放送（CATV）などであってもよい。

＜２．IP伝送方式によるデジタル放送の概要＞

ところで、各国のデジタル放送の規格では、伝送方式としてMPEG2-TS(Moving Picture Experts Group phase 2-Transport Stream)方式が採用されているが、今後は、通信の分野で用いられているIP(Internet Protocol)パケットをデジタル放送に用いた方式（以下、IP伝送方式という）を導入することで、より高度なサービスを提供することが想定されている。

特に、現在策定が進められている次世代放送規格であるATSC3.0では、IP伝送方式が採用されることが決定されている。また、ATSC3.0以外の放送規格でも、将来的に、IP伝送方式が採用されることが期待されている。

ATSC3.0では、データ伝送に、IP/UDPパケット、すなわち、UDP(User Datagram Protocol)パケットを含むIP(Internet Protocol)パケットが用いられる。また、ATSC3.0においては、トランスポート・プロトコルとして、ROUTE(Real-Time Object Delivery over Unidirectional Transport)と、MMT(MPEG Media Transport)が併存し、いずれか一方のトランスポート・プロトコルを用いてビデオやオーディオ、字幕等（のコンポーネント）のストリームが伝送される。

ここで、ROUTEは、バイナリファイルを一方向でマルチキャスト転送するのに適したプロトコルであるFLUTE(File Delivery over Unidirectional Transport)を拡張したプロトコルである。また、MMTは、IP(Internet Protocol)上で用いられるトランスポート方式であり、制御情報によりIPアドレスやURL(Uniform Resource Locator)を設定することで、ビデオやオーディオ等のデータを参照することができる。

さらに、ATSC3.0においては、シグナリングとして、LLS(Link Layer Signaling)シグナリングと、SLS(Service Layer Signaling)シグナリングを規定することが想定されており、先行して取得されるLLSシグナリングに記述される情報に従い、サービスごとのSLSシグナリングが取得されることになる。

ここで、LLSシグナリングとしては、例えば、SLT(Service List Table)等のメタデータが含まれる。SLTは、サービスの選局に必要な情報(選局情報)など、放送ネットワークにおけるストリームやサービスの構成を示す情報を含む。

また、SLSシグナリングとしては、例えば、USD(User Service Description)，LSID(LCT Session Instance Description)，MPD(Media Presentation Description)，AIT(Application Information Table)等のメタデータが含まれる。USDは、他のメタデータの取得先などの情報を含む。LSIDは、ROUTEプロトコルの制御情報である。MPDは、コンポーネントのストリームの再生を管理するための制御情報である。AITは、アプリケーションの制御情報である。例えば、AITには、アプリケーションのライフサイクルを管理するための情報が含まれる。

なお、USD，LSID，MPD，AIT等のメタデータは、XML(Extensible Markup Language)等のマークアップ言語により記述される。また、MPDは、MPEG-DASH(Dynamic Adaptive Streaming over HTTP)の規格に準じている。

また、LLSシグナリングとSLSシグナリング以外のシグナリングが伝送されるようにしてもよい。このようなシグナリングとしては、例えば、NRTコンテンツのダウンロードを制御するための情報を含むDIT(Download Information Table)等のメタデータを規定することができる。なお、詳細は後述するが、DITメタデータは、NRTコンポーネントとして伝送される。

（プロトコルスタック）
図２は、本技術を適用したIP伝送方式のプロトコルスタックを示す図である。

図２において、最も下位の階層は、物理層（Physical Layer）とされる。この物理層に隣接する上位の階層は、レイヤ２の階層（Layer2）とされ、さらに、レイヤ２の階層に隣接する上位の階層は、IP層とされる。また、IP層に隣接する上位の階層はUDP層とされる。すなわち、UDPパケットを含むIPパケット（IP/UDPパケット）が、レイヤ２のGenericパケットのペイロードに配置され、カプセル化（encapsulation）される。また、物理層のフレーム（Physical Frame）は、プリアンブルとデータ部から構成されるが、データ部には、複数のGenericパケットをカプセル化して得られるBBフレームに対してエラー訂正用のパリティを付加した後に、インターリーブやマッピング等の物理層に関する処理が行われることで得られるデータがマッピングされる。

UDP層に隣接する上位の階層は、ROUTE，MMT，SLTとされる。すなわち、ROUTEセッションで伝送される、ビデオ、オーディオ、及び、字幕（のコンポーネント）のストリームと、SLSシグナリングのストリームと、NRTコンポーネントのストリームは、IP/UDPパケットに格納されて伝送される。なお、NRTコンポーネントには、放送アプリケーションやNRTコンテンツなどが含まれる。NRTコンテンツは、受信装置２０のストレージに一旦蓄積された後で再生（ダウンロード再生）が行われる。

一方で、MMTセッションで伝送される、ビデオ、オーディオ、及び、字幕のストリームと、SLSシグナリングのストリームは、IP/UDPパケットに格納されて伝送される。また、SLTは、IP/UDPパケットに格納されて伝送される。

以上のようなプロトコルスタックが採用されているため、受信装置２０は、ROUTEセッションで伝送されるコンポーネントのストリームにより提供されるサービス（チャンネル）の選局時には、SLTに含まれる選局情報に従い、ROUTEセッションで伝送されるSLSシグナリングを取得する（Ｓ１−１，Ｓ１−２）。そして、受信装置２０は、USD，LSID，MPD等のメタデータに従い、選局されたサービスを提供するコンポーネントのストリームに接続する（Ｓ１−３）。これにより、受信装置２０では、選局されたサービスに応じた放送コンテンツ（例えばテレビ番組）の映像や音声が出力される。

また、受信装置２０は、MMTセッションで伝送されるコンポーネントのストリームにより提供されるサービスの選局時には、SLTに含まれる選局情報に従い、MMTセッションで伝送されるSLSシグナリングを取得する（Ｓ２−１，Ｓ２−２）。そして、受信装置２０は、SLSシグナリングに含まれる各種のメタデータに従い、選局されたサービスを提供するコンポーネントのストリームに接続する（Ｓ２−３）。これにより、受信装置２０では、選局されたサービスに応じた放送コンテンツ（例えばテレビ番組）の映像や音声が出力される。

＜３．NRTサービスの運用例＞

（NRTサービス）
図３は、NRTサービスの概要を説明する図である。

NRTサービスは、送信装置１０から伝送路３０を介してダウンロード配信された非リアルタイムのNRTコンテンツ（NRTコンポーネント）を、受信装置２０が、ストレージに一旦蓄積してから、その後に再生（ダウンロード再生）を行うサービスである。

ここで、ATSC3.0において、NRTサービスが提供される場合には、NRTコンポーネントとして、放送アプリケーション（図中の「App」）が配信されることが想定されている。この放送アプリケーションのファイルは、SLSシグナリングや他のファイル（図中の「Others」）などとともに、ROUTEセッションで伝送されることになる。また、放送アプリケーションは、他のファイルを参照することができる。

以下、本技術のNRTサービスとして、NRTコンポーネントとして、放送アプリケーションが配信されることを前提としたサービスについて説明する。

（本技術のNRTサービス）
図４は、本技術のNRTサービスの概要を説明する図である。

本技術のNRTサービスは、大別すると、NRT連動TVサービス（NRT embedded TV Service）、フォアグランドNRTサービス（Foreground NRT Service）、及び、バックグラウンドNRTサービス（Background NRT Service）に分類することができる。また、バックグラウンドNRTサービスには、APPデータタイプと、RAWデータタイプの２種類のデータタイプがある。

NRT連動TVサービスは、放送コンテンツ（例えばテレビ番組）に対して、NRTコンポーネントとして伝送される連動アプリケーション（Linked App：Linked Application）を連動して実行させるサービスである。ここで、連動アプリケーション（Linked App）は、放送コンテンツに連動して実行されるアプリケーションである。

フォアグランドNRTサービスは、NRTコンポーネントとして伝送されるフォアグランドアプリケーション（FG App：Foreground Application）によって、ポータル（ポータルページ）を表示させるサービスである。ここで、フォアグランドアプリケーション（FG App）は、ポータル（ポータルページ）の映像を、全画面で表示させるため、ユーザにより意識されるアプリケーションであるとも言える。

バックグラウンドNRTサービスは、NRTコンポーネントとして伝送されるバックグラウンドアプリケーション（BG App：Background Application）によって、NRTサービス（NRTコンテンツ）の予約選局に応じて、NRTコンポーネントとして伝送されるNRTコンテンツをダウンロードするサービスである。

ここで、バックグラウンドアプリケーション（BG App）は、NRTコンテンツのダウンロードを処理するアプリケーションである。また、バックグラウンドアプリケーション（BG App）は、バックグラウンド（裏）で動作するアプリケーションであって、スクリプト等により処理内容のみが記述されているため、非表示とされる。したがって、ユーザが、バックグラウンドアプリケーション（BG App）の動作を意識することなく、NRTコンテンツのダウンロードの処理が行われる。

また、バックグラウンドNRTサービスでは、そのタイプがAPPデータタイプとなる場合、対象ファイル群（Stored App，AITs）のデータと、その参照ファイル群（Content Meta，Content Resource）のデータが伝送されるので、受信装置２０では、対象ファイル群（Stored App，AITs）及び参照ファイル群（Content Meta，Content Resource）のデータが、ストレージに蓄積される。

ここで、対象ファイル群は、ストアドアプリケーション（Stored App：Stored Application）と、AITsを含んでいる。ストアドアプリケーション（Stored App）は、参照ファイル群のデータに対する処理を行う。AITs(Application Information Table Storage)は、ストアドアプリケーション（Stored App）の制御情報である。

参照ファイル群は、コンテンツメタデータ（Content Meta）と、コンテンツリソース（Content Resource）を含んでいる。コンテンツリソースは、動画や音楽などのNRTコンテンツの実体のデータであり、コンテンツメタデータは、NRTコンテンツのメタデータである。

バックグラウンドNRTサービスでは、そのタイプがRAWデータタイプとなる場合、参照ファイル群（Content Meta，Content Resource）のデータのみが伝送されるので、受信装置２０では、参照ファイル群（Content Meta，Content Resource）のデータが、ストレージに蓄積される。この場合、外部のアプリケーションが、参照ファイル群のデータに対する処理を行うことになる。

ここで、外部のアプリケーションは、参照ファイル群と共に伝送される対象ファイル群に含まれるストアドアプリケーション（Stored App）以外のアプリケーション、例えば、連動アプリケーション（Linked App）やフォアグランドアプリケーション（FG App）、他のストアドアプリケーション（Stored App）などである。

なお、連動アプリケーション（Linked App）、フォアグランドアプリケーション（FG App）、バックグラウンドアプリケーション（BG App）、及び、ストアドアプリケーション（Stored App）は、HTML5(HyperText Markup Language 5)等のマークアップ言語により開発されている。また、NRTコンテンツは、非リアルタイムのコンテンツである一方で、放送コンテンツがリアルタイムのコンテンツとされる。

また、受信装置２０においては、これらのNRTサービスに関連するアプリケーションの他に、レジデントアプリケーション（RA：Resident Application）やブラウザ、録画再生制御アプリケーションなどの機器内蔵アプリケーションも実行される。なお、レジデントアプリケーション（RA）は、受信装置２０にあらかじめ組み込まれたアプリケーションである。

以下の説明では、連動アプリケーション（Linked App）、フォアグランドアプリケーション（FG App）、バックグラウンドアプリケーション（BG App）、及び、ストアドアプリケーション（Stored App）を、特に区別する必要がない場合には、放送アプリケーション（BCA：Broadcast Application）と称して、レジデントアプリケーション（RA）等の機器内蔵アプリケーションと区別する。

なお、図５には、本技術のNRTサービスである、NRT連動TVサービス（NRT embedded TV Service）、フォアグランドNRTサービス（Foreground NRT Service）、及び、バックグラウンドNRTサービス（Background NRT Service）のコンセプトモデル（Conceptual Model）を示している。

（１）NRT連動TVサービス

図６は、NRT連動TVサービスのシナリオの例を示す図である。

図６において、放送ストリームには、ビデオコンポーネント、オーディオコンポーネント、NRTコンポーネント、SLSシグナリング、及び、ESG(Electronic Service Guide)サービスのストリームが含まれている。なお、図６の放送ストリームでは、説明を簡略化するために図示していないが、LLSシグナリングなどの他のストリームが含まれるようにしてもよい。

このような放送ストリームが、送信装置１０から、伝送路３０を介して受信装置２０に伝送される場合に、受信装置２０において提供されるNRT連動TVサービスは、次のように実現される。

すなわち、受信装置２０では、ユーザの選局操作などに応じて、ビデオコンポーネント及びオーディオコンポーネントのストリームが受信され、処理されることで、テレビ番組等の放送コンテンツが再生される。これにより、受信装置２０では、放送コンテンツの映像が表示部に表示され、その映像に同期した音声がスピーカから出力される。

また、受信装置２０では、SLSシグナリングとして、連動アプリケーション（Linked App）の動作を制御するためのAITが受信されると、当該AITに従い、NRTコンポーネントとして伝送されている連動アプリケーション（Linked App）が取得される（Ｓ１１）。そして、受信装置２０では、当該AITに従い、連動アプリケーション（Linked App）が起動される（Ｓ１２）。

このようにして、受信装置２０では、テレビ番組等の放送コンテンツに対して、連動アプリケーション（Linked App）が連動して実行され、受信装置２０では、放送コンテンツの映像とともに、連動アプリケーション（Linked App）の映像が表示される。

（２）フォアグランドNRTサービス

図７は、フォアグランドNRTサービスのシナリオの例を示す図である。

図７において、放送ストリームには、NRTコンポーネント、SLSシグナリング、及び、ESGサービスのストリームが含まれている。なお、図７の放送ストリームでは、説明を簡略化するために図示していないが、LLSシグナリングなどの他のストリームが含まれるようにしてもよい。また、NRTコンポーネントのストリームは、１つに限らず、複数のNRTコンポーネントのストリームが伝送されるようにしてもよい。

このような放送ストリームが、送信装置１０から、伝送路３０を介して受信装置２０に伝送される場合に、受信装置２０において提供されるフォアグランドNRTサービスは、次のように実現される。

すなわち、受信装置２０では、ユーザの選局操作（ポータルの表示指示）などに応じて、フォアグランドアプリケーション（FG App）の動作を制御するためのAITが受信されると、当該AITに従い、NRTコンポーネントとして伝送されるフォアグランドアプリケーション（FG App）が取得される（Ｓ２１）。そして、受信装置２０では、当該AITに従い、フォアグランドアプリケーション（FG App）が起動される（Ｓ２２）。

このようにして、受信装置２０では、フォアグランドアプリケーション（FG App）が実行され、フォアグランドアプリケーション（FG App）に応じたポータル（ポータルページ）の映像が、全画面で表示される。すなわち、フォアグランドNRTサービスでは、テレビ番組等の放送コンテンツの映像は、表示されずに、ポータル（ポータルページ）の映像のみが、全画面で表示されることになる。

（３）バックグラウンドNRTサービス

（３−１）APPデータタイプ

（シナリオの例）
図８は、APPデータタイプのバックグラウンドNRTサービスのシナリオの例を示す図である。

図８において、放送ストリームには、NRTコンポーネント、及び、SLSシグナリングのストリームが含まれている。ただし、図８の放送ストリームでは、説明を簡略化するために図示していないが、LLSシグナリングやESGサービスなどの他のストリームが含まれるようにしてもよい。また、NRTコンポーネントのストリームは、１つに限らず、複数のNRTコンポーネントのストリームが伝送されるようにしてもよい。

このような放送ストリームが、送信装置１０から、伝送路３０を介して受信装置２０に伝送される場合に、受信装置２０において提供されるバックグラウンドNRTサービス（APPデータタイプ）は、次のように実現される。

すなわち、受信装置２０では、連動アプリケーション（Linked App）又はフォアグランドアプリケーション（FG App）により、プログラム予約選局API(Application Programming Interface)が実行されると、NRTサービスの選局動作の予約が行われる（Ｓ３１−１，Ｓ３１−２）。これにより、蓄積対象のNRTコンテンツの予約が完了したことになる。なお、ここでは、プログラム予約選局APIの代わりに、シリーズ予約選局APIが実行され、プログラム単位ではなく、シリーズ単位で、NRTサービスの選局動作の予約が行われるようにしてもよい。

その後、受信装置２０では、プログラム予約選局APIで指定したプログラムの予約実行時刻（予約開始時刻）になると、該当するNRTサービスが選局される。受信装置２０は、選局したNRTサービスにおいて、バックグラウンドアプリケーション（BG App）の動作を制御するためのAITが受信されると、当該AITに従い、NRTコンポーネントとして伝送されるバックグラウンドアプリケーション（BG App）が取得される（Ｓ３２）。そして、受信装置２０では、当該AITに従い、バックグラウンドアプリケーション（BG App）が起動される（Ｓ３３）。

このとき、バックグラウンドアプリケーション（BG App）は、バックグラウンド（裏）で動作するアプリケーションであるため、非表示とされる。そして、このバックグラウンドアプリケーション（BG App）によって、NRTダウンロードAPIが実行される（Ｓ３４）。

受信装置２０では、バックグラウンドアプリケーション（BG App）によるNRTダウンロードAPIの実行に応じて、NRTコンポーネントとして伝送されるDITメタデータが取得される（Ｓ３５，Ｓ３６）。そして、バックグラウンドアプリケーション（BG App）は、取得されたDITメタデータに基づいて、NRTコンポーネントとして伝送される対象ファイル群（Stored App，AITs）及びその参照ファイル群（Content Meta，Content Resource）（のデータ）を取得する（Ｓ３７，Ｓ３８）。

ここで、対象ファイル群には、ストアドアプリケーション（Stored App）とその制御情報であるAITsが含まれる。また、参照ファイル群には、コンテンツリソース（Content Resource）と、そのメタデータであるコンテンツメタデータ（Content Meta）が含まれる。

このように、受信装置２０では、バックグラウンドで動作する非表示のバックグラウンドアプリケーション（BG App）によって、DITメタデータに応じて取得された対象ファイル群（Stored App，AITs）及び参照ファイル群（Content Meta，Content Resource）が、ストレージに蓄積されることになる（図中の点線で示す「Storage」）。なお、図８のストレージ（Storage）は、図２０の受信装置２０のストレージ２１２に対応するものである。

その後、受信装置２０では、連動アプリケーション（Linked App）又はフォアグランドアプリケーション（FG App）により、アプリケーションリスト取得APIが実行されると、ストレージ（Storage）に蓄積されたストアドアプリケーション（Stored App）のリストが取得され、表示される（Ｓ３９−１，Ｓ３９−２）。そして、例えばユーザにより、ストアドアプリケーション（Stored App）のリストの中から選択されたストアドアプリケーション（Stored App）が、AITsに従い、起動される（Ｓ４０）。

ここで、ストアドアプリケーション（Stored App）は、例えば、動画や音楽などのNRTコンテンツを再生するためのプレーヤなどである。そして、このストアドアプリケーション（Stored App）は、コンテンツメタデータに基づいて、動画や音楽などのNRTコンテンツ（コンテンツリソース）に関する情報を提示したり（Ｓ４１）、NRTコンテンツ（コンテンツリソース）を再生（ダウンロード再生）したりする（Ｓ４２）。

また、例えば、ストアドアプリケーション（Stored App）が、プログラム予約選局APIを実行して、NRTサービスの選局動作の予約を行うなど（Ｓ４３）、放送アプリケーション（BCA）が各種のAPI（後述する図１４乃至図１７のAPI）を実行することで、それらのAPIに応じた各種の処理が実行される。

すなわち、受信装置２０において、放送アプリケーション（BCA）が各種のAPIに応じた処理を行うことで、いわば、放送アプリケーション（BCA）が、連鎖的に（チェーンして）動作することになる。なお、放送アプリケーション（BCA）による各種のAPIに応じた処理の詳細については、図９を参照して後述する。

このようにして、受信装置２０では、NRTサービスの選局動作の予約開始時刻になったとき、該当するNRTサービスの受信を開始して、AITに応じてバックグラウンドアプリケーション（BG App）を取得した上で、非表示のバックグラウンドアプリケーション（BG App）の実行が開始され、DITメタデータに応じて、ストアドアプリケーション（Stored App）やコンテンツリソースなどが、ストレージ（Storage）に蓄積される。そして、受信装置２０では、このストレージに蓄積されたストアドアプリケーション（Stored App）が、各種のAPIに応じて動作することで、NRTコンテンツに関する処理などが行われる。

これにより、APPデータタイプのバックグラウンドNRTサービスでは、NRTコンテンツのダウンロード再生を行うための処理が、バックグラウンドアプリケーション（BG App）やストアドアプリケーション（Stored App）等の放送アプリケーション（BCA）の実装により実現されることになるため、レジデントアプリケーション（RA）の実装負担をより少なくして、NRTコンテンツのダウンロード再生を行うことができる。

（APIによる処理の例）
図９は、APPデータタイプのバックグラウンドNRTサービスにおけるアプリケーションとストレージのデータの関係を示す図である。

ただし、図９において、受信装置２０では、連動アプリケーション（Linked App）又はフォアグランドアプリケーション（FG App）によって、プログラム予約選局API又はシリーズ予約選局APIが実行され、NRTサービスの選局動作が予約済みであるものとする。また、図９において、一点鎖線で表された楕円で囲まれたストレージ（Storage）は、図２０の受信装置２０のストレージ２１２に対応している。

図９において、受信装置２０では、NRTサービスの選局動作の予約開始時刻になったとき、該当するNRTサービスを選局することにより取得されたバックグラウンドアプリケーション（BG App）が、非表示で起動され、このバックグラウンドアプリケーション（BG App）によって、NRTダウンロードAPIが実行される。これにより、DITメタデータが取得されるので、バックグラウンドアプリケーション（BG App）は、DITメタデータに基づいて、NRTコンポーネントとして伝送される対象ファイル群及び参照ファイル群（のデータ）を取得し、ストレージ（Storage）に蓄積する。

これにより、受信装置２０のストレージ（Storage）には、対象ファイル群及び参照ファイル群（のデータ）が蓄積される。すなわち、当該ストレージ（Storage）には、対象ファイル群としての、ストアドアプリケーション（Stored App）とその制御情報であるAITsと、参照ファイル群としての、コンテンツリソース（Content Resource）とそのメタデータであるコンテンツメタデータ（Content Meta）が蓄積される。なお、図９のストレージ（Storage）には、いまのタイミングで蓄積された対象ファイル群及び参照ファイル群（のデータ）の他に、その前のタイミングで、他のデータ（対象ファイル群及び参照ファイル群のデータ）も蓄積済みであるものとする。

その後、受信装置２０においては、連動アプリケーション（Linked App）、フォアグランドアプリケーション（FG App）、又はストアドアプリケーション（Stored App）によって、アプリケーションリスト取得APIが実行された場合、ストレージ（Storage）に蓄積された１又は複数のAITsに基づいて、ストレージ（Storage）に蓄積されたストアドアプリケーション（Stored App）のリストが生成され、表示される。これにより、例えば、ユーザによって、ストアドアプリケーション（Stored App）のリストの中から選択されたストアドアプリケーション（Stored App）が、対応するAITsに従い、起動されることになる。

また、受信装置２０においては、連動アプリケーション（Linked App）、フォアグランドアプリケーション（FG App）、又はストアドアプリケーション（Stored App）によって、アプリケーション遷移APIが実行された場合、ストレージ（Storage）に蓄積された１又は複数のAITsのうち、遷移の対象のストアドアプリケーション（Stored App）に対応するAITsに基づいて、遷移対象のストアドアプリケーション（Stored App）が起動される。これにより、連動アプリケーション（Linked App）、フォアグランドアプリケーション（FG App）、又はストアドアプリケーション（Stored App）から、遷移対象のストアドアプリケーション（Stored App）への遷移が行われる。

ストアドアプリケーション（Stored App）は、例えば、動画や音楽などのNRTコンテンツを再生するためのプレーヤ（player）などである。

ストアドアプリケーション（Stored App）によって、コンテンツリスト取得APIが実行された場合、ストレージ（Storage）に蓄積された１又は複数のコンテンツメタデータ（Content Meta）に基づいて、ストレージ（Storage）に蓄積されたNRTコンテンツ（コンテンツリソース（Content Resource））のリストが生成され、表示される。これにより、例えば、ユーザによって、NRTコンテンツのリストの中から選択された、動画や音楽などのNRTコンテンツ（コンテンツリソース（Content Resource））が再生されることになる。

また、ストアドアプリケーション（Stored App）によって、コンテンツ情報取得APIが実行された場合、ストレージ（Storage）に蓄積された１又は複数のコンテンツメタデータ（Content Meta）のうち、取得の対象のコンテンツメタデータ（Content Meta）に基づいて、NRTコンテンツに関する情報（コンテンツ情報）が表示される。これにより、例えば、ユーザによって、コンテンツ情報の表示されたNRTコンテンツの再生が指示された場合、当該NRTコンテンツ（コンテンツリソース（Content Resource））の再生が開始される。

また、ストアドアプリケーション（Stored App）によって、コンテンツ再生APIが実行された場合、ストレージ（Storage）に蓄積されたNRTコンテンツのうち、再生の対象の動画や音楽などのNRTコンテンツ（コンテンツリソース（Content Resource））が再生されることになる。

以上のように、受信装置２０では、APPデータタイプのバックグラウンドNRTサービスに応じた動作を行う場合、連動アプリケーション（Linked App）、フォアグランドアプリケーション（FG App）、バックグラウンドアプリケーション（BG App）、又は、ストアドアプリケーション（Stored App）が、各種のAPIを実行することで、APIに応じた各種の処理が実行される。すなわち、受信装置２０において、放送アプリケーション（BCA）が各種のAPIに応じた処理を行うことで、いわば、放送アプリケーション（BCA）が、連鎖的に（チェーンして）動作することになる。

なお、図９においては、放送アプリケーション（BCA）が、APIに応じた各種の処理を実行する例を示したが、例えば、レジデントアプリケーション（RA）が、ストレージ（Storage）に蓄積されたAITsに従い、ストアドアプリケーション（Stored App）を起動するようなど、放送アプリケーション（BCA）以外のアプリケーションが、ストレージ（Storage）に蓄積されたデータを処理してもよい。

（３−２）RAWデータタイプ

図１０は、RAWデータタイプのバックグラウンドNRTサービスのシナリオの例を示す図である。

図１０において、放送ストリームには、NRTコンポーネント、及び、SLSシグナリングのストリームが含まれている。ただし、図１０の放送ストリームでは、説明を簡略化するために図示していないが、LLSシグナリングやESGサービスなどの他のストリームが含まれるようにしてもよい。また、NRTコンポーネントのストリームは、１つに限らず、複数のNRTコンポーネントのストリームが伝送されるようにしてもよい。

このような放送ストリームが、送信装置１０から、伝送路３０を介して受信装置２０に伝送される場合に、受信装置２０において提供されるバックグラウンドNRTサービス（RAWデータタイプ）は、次のように実現される。

すなわち、受信装置２０では、連動アプリケーション（Linked App）又はフォアグランドアプリケーション（FG App）により、プログラム予約選局APIが実行されると、NRTサービスの選局動作の予約が行われる（Ｓ５１−１，Ｓ５１−２）。これにより、蓄積対象のNRTコンテンツの予約が完了したことになる。なお、ここでは、プログラム予約選局APIの代わりに、シリーズ予約選局APIによって、NRTサービスの選局動作の予約が行われるようにしてもよい。

その後、受信装置２０では、プログラム予約選局APIで指定したプログラムの予約実行時刻（予約開始時刻）になると、該当するNRTサービスが選局される。受信装置２０は、選局したNRTサービスにおいて、バックグラウンドアプリケーション（BG App）の動作を制御するためのAITが受信されると、当該AITに従い、NRTコンポーネントとして伝送されるバックグラウンドアプリケーション（BG App）が取得される（Ｓ５２）。そして、受信装置２０では、当該AITに従い、バックグラウンドアプリケーション（BG App）が起動される（Ｓ５３）。

このとき、バックグラウンドアプリケーション（BG App）は、非表示で実行される。そして、このバックグラウンドアプリケーション（BG App）によって、NRTダウンロードAPIが実行される（Ｓ５４）。

受信装置２０では、バックグラウンドアプリケーション（BG App）によるNRTダウンロードAPIの実行に応じて、NRTコンポーネントとして伝送されるDITメタデータが取得される（Ｓ５５，Ｓ５６）。そして、バックグラウンドアプリケーション（BG App）は、取得されたDITメタデータに基づいて、NRTコンポーネントとして伝送される参照ファイル群（Content Meta，Content Resource）（のデータ）を取得する（Ｓ５７，Ｓ５８）。

ここで、参照ファイル群には、コンテンツリソース（Content Resource）と、そのメタデータであるコンテンツメタデータ（Content Meta）が含まれる。

このように、受信装置２０では、バックグラウンドで動作する非表示のストアドアプリケーション（Stored App）によって、DITメタデータに応じて取得された参照ファイル群（Stored App，AITs）が、ストレージ（Storage）に蓄積されることになる。なお、図１０のストレージ（Storage）は、図２０の受信装置２０のストレージ２１２に対応するものである。

その後、受信装置２０では、連動アプリケーション（Linked App）又はフォアグランドアプリケーション（FG App）により、コンテンツ情報取得APIが実行された場合（Ｓ５９−１，５９−２）、ストレージ（Storage）に蓄積されたコンテンツメタデータ（Content Meta）に基づいて、NRTコンテンツに関する情報（コンテンツ情報）が表示される（Ｓ６０）。これにより、例えば、ユーザによって、コンテンツ情報の表示されたNRTコンテンツの再生が指示された場合、当該NRTコンテンツ（コンテンツリソース（Content Resource））の再生が開始される。

また、連動アプリケーション（Linked App）又はフォアグランドアプリケーション（FG App）により、コンテンツ再生APIが実行された場合、ストレージ（Storage）に蓄積されたNRTコンテンツ（コンテンツリソース（Content Resource））が再生されることになる。

このようにして、受信装置２０では、NRTサービスの選局動作の予約開始時刻になったとき、該当するNRTサービスの受信を開始して、AITに応じてバックグラウンドアプリケーション（BG App）を取得した上で、非表示のバックグラウンドアプリケーション（BG App）の実行が開始され、DITメタデータに応じて、コンテンツリソース（Content Resource）及びコンテンツメタデータ（Content Meta）を含む参照ファイル群のみが、ストレージ（Storage）に蓄積される。そして、受信装置２０では、連動アプリケーション（Linked App）又はフォアグランドアプリケーション（FG App）等の放送アプリケーション（BCA）によって、各種のAPIを実行することで、NRTコンテンツに関する処理が行われる。

これにより、RAWデータタイプのバックグラウンドNRTサービスでは、NRTコンテンツのダウンロード再生を行うための処理が、バックグラウンドアプリケーション（BG App）等の放送アプリケーション（BCA）の実装により実現されることになるため、レジデントアプリケーション（RA）の実装負担をより少なくして、NRTコンテンツのダウンロード再生を行うことができる。

（APIによる処理の例）
図１１は、RAWデータタイプのバックグラウンドNRTサービスにおけるアプリケーションとストレージのデータの関係を示す図である。

ただし、図１１において、受信装置２０では、連動アプリケーション（Linked App）又はフォアグランドアプリケーション（FG App）によって、プログラム予約選局API又はシリーズ予約選局APIが実行され、NRTサービスの選局動作が予約済みであるものとする。また、図１１においても、一点鎖線で表された楕円で囲まれたストレージ（Storage）は、図２０の受信装置２０のストレージ２１２に対応している。

図１１において、受信装置２０では、NRTサービスの選局動作の予約開始時刻になったとき、該当するNRTサービスを選局することにより取得されたバックグラウンドアプリケーション（BG App）が、非表示で起動され、このバックグラウンドアプリケーション（BG App）によって、NRTダウンロードAPIが実行される。これにより、DITメタデータが取得されるので、バックグラウンドアプリケーション（BG App）は、DITメタデータに基づいて、NRTコンポーネントとして伝送される参照ファイル群（のデータ）のみを取得し、ストレージ（Storage）に蓄積する。

これにより、受信装置２０のストレージ（Storage）には、参照ファイル群（のデータ）のみが蓄積される。すなわち、当該ストレージ（Storage）には、参照ファイル群としての、コンテンツリソース（Content Resource）とそのメタデータであるコンテンツメタデータ（Content Meta）が蓄積される。なお、図１１のストレージ（Storage）には、いまのタイミングで蓄積された参照ファイル群（のデータ）の他に、その前のタイミングで、他のデータ（対象ファイル群及び参照ファイル群のデータ）も蓄積済みであるものとする。

その後、受信装置２０においては、連動アプリケーション（Linked App）、フォアグランドアプリケーション（FG App）、又はストアドアプリケーション（Stored App）によって、コンテンツリスト取得APIが実行された場合、ストレージ（Storage）に蓄積された１又は複数のコンテンツメタデータ（Content Meta）に基づいて、ストレージ（Storage）に蓄積されたNRTコンテンツ（コンテンツリソース（Content Resource））のリストが生成され、表示される。これにより、例えば、ユーザによって、NRTコンテンツのリストの中から選択された、動画や音楽などのNRTコンテンツ（コンテンツリソース（Content Resource））が再生されることになる。

また、連動アプリケーション（Linked App）、フォアグランドアプリケーション（FG App）、又はストアドアプリケーション（Stored App）によって、コンテンツ情報取得APIが実行された場合、ストレージ（Storage）に蓄積された１又は複数のコンテンツメタデータ（Content Meta）のうち、取得の対象のコンテンツメタデータ（Content Meta）に基づいて、NRTコンテンツに関する情報（コンテンツ情報）が表示される。これにより、例えば、ユーザによって、コンテンツ情報の表示されたNRTコンテンツの再生が指示された場合、当該NRTコンテンツ（コンテンツリソース（Content Resource））の再生が開始される。

また、連動アプリケーション（Linked App）、フォアグランドアプリケーション（FG App）、又はストアドアプリケーション（Stored App）によって、コンテンツ再生APIが実行された場合、ストレージ（Storage）に蓄積されたNRTコンテンツのうち、再生の対象の動画や音楽などのNRTコンテンツ（コンテンツリソース（Content Resource））が再生されることになる。

以上のように、受信装置２０では、RAWデータタイプのバックグラウンドNRTサービスに応じた動作を行う場合、連動アプリケーション（Linked App）、フォアグランドアプリケーション（FG App）、バックグラウンドアプリケーション（BG App）、又は、ストアドアプリケーション（Stored App）が、各種のAPIを実行することで、APIに応じた各種の処理が実行される。すなわち、受信装置２０において、放送アプリケーション（BCA）が各種のAPIに応じた処理を行うことで、いわば、放送アプリケーション（BCA）が、連鎖的に（チェーンして）動作することになる。

なお、図１１においては、ストアドアプリケーション（Stored App）は、いまのタイミングよりも前のタイミングで蓄積された対象ファイル群（のデータ）に含まれるものである。すなわち、図１１において、受信装置２０のストレージ（Storage）には、APPデータタイプのバックグラウンドNRTサービスで提供された対象ファイル群及び参照ファイル群（のデータ）と、RAWデータタイプのバックグラウンドNRTサービスで提供された参照ファイル群（のデータ）が混在していることになる。

（状態遷移図）
図１２は、NRTサービスの状態遷移図を示す図である。

図１２に示すように、レジデントアプリケーション（RA）の動作、又は電子サービスガイド（ESG）などによる選局動作に応じて、NRT連動TVサービス（NRT embedded TV Service）又はフォアグランドNRTサービス（Foreground NRT Service）が開始されることで、連動アプリケーション（Linked App）又はフォアグランドアプリケーション（FG App）が起動される。

そして、連動アプリケーション（Linked App）又はフォアグランドアプリケーション（FG App）によって、NRTサービスの選局動作の予約が行われると、その選局動作の予約に応じて、バックグラウンドNRTサービス（Background NRT Service）の受信が開始され、バックグラウンドアプリケーション（BG App）が起動される。このバックグラウンドアプリケーション（BG App）によって、ストアドアプリケーション（Stored App）や、NRTコンテンツのコンテンツリソース（Content Resource）などのダウンロードが行われ、それらのデータが、ストレージに蓄積される。

ここで、例えば、連動アプリケーション（Linked App）、フォアグランドアプリケーション（FG App）、又はストアドアプリケーション（Stored App）は、各種のAPIを実行することで、ストレージに蓄積されたストアドアプリケーション（Stored App）に遷移することができる。また、連動アプリケーション（Linked App）、フォアグランドアプリケーション（FG App）、又はストアドアプリケーション（Stored App）は、各種のAPIを実行することで、ストレージに蓄積されたNRTコンテンツのコンテンツリソース（Content Resource）に対する処理を行うことができる。

なお、例えば、レジデントアプリケーション（RA）が、ストレージに蓄積されたストアドアプリケーション（Stored App）を起動するなど、放送アプリケーション（BCA）以外のアプリケーションがストレージに蓄積されたデータを処理してもよい。

また、上述した説明では、説明の都合上、NRTサービスを、NRT連動TVサービス、フォアグランドNRTサービス、及び、バックグラウンドNRTサービスに分類して、バックグラウンドNRTサービスによって、対象ファイル群及び参照ファイル群（又は参照ファイル群のみ）のNRTコンポーネントが提供される場合を説明したが、当該NRTコンポーネントは、NRT連動TVサービス又はフォアグランドNRTサービスで提供されるようにしてもよい。

ここで、図１３のＡには、NRT連動TVサービスで、対象ファイル群及び参照ファイル群のNRTコンポーネントが提供される場合を示している。また、図１３のＢには、フォアグランドNRTサービスで、対象ファイル群及び参照ファイル群のNRTコンポーネントが提供される場合を示している。

＜４．NRTサービスで用いられるAPIの例＞

（プログラム予約選局API）
図１４は、プログラム予約選局APIの例を示す図である。

プログラム予約選局APIは、指定したアクションタイプ（action_type）の選局動作を予約するためのAPIである。

プログラム予約選局APIは、引数として、broadcast_stream_id，service_id，reservation_start_time，reservation_duration，schedule_fragment_uri，及び、action_typeを指定することができる。

broadcast_stream_idには、選局対象の周波数帯域（RF帯域）を識別する識別子であるブロードキャストストリームIDが指定される。service_idには、選局対象のサービスを識別する識別子であるサービスIDが指定される。すなわち、ブロードキャストストリームIDとサービスIDによって、選局対象の特定のサービスが識別されることになる。

reservation_start_timeには、選局を開始する時刻を示す選局開始時刻が指定される。reservation_durationには、選局している時間を示す選局時間が指定される。

なお、reservation_start_timeと、reservation_durationは、オプションとされ、引数として指定するかどうかは任意である。すなわち、例えば、ESGサービスを利用して予約対象のサービスの時刻情報を取得する場合には、reservation_start_timeとreservation_durationを指定する必要はない。

schedule_fragment_uriには、予約対象のプログラムのプログラムIDが指定される。なお、schedule_fragment_uriは、オプションとされ、引数として指定するかどうかは任意である。

action_typeには、選局時の動作を示すタイプ情報が指定される。例えば、action_typeとして、"1"が指定された場合、通常の選局再生が行われることを意味する。また、例えば、action_typeとして、"2"が指定された場合、バックグランドでの選局再生が行われることを意味する。すなわち、バックグラウンドNRTサービスで、プログラム予約選局APIが実行される場合、action_typeには、"2"が指定される。さらに、例えば、action_typeとして、"3"が指定された場合、録画（又は再生と録画）が行われることを意味する。

（NRTダウンロードAPI）
図１５は、NRTダウンロードAPIの例を示す図である。

NRTダウンロードAPIは、受信装置２０で現在受信中のNRTサービスで伝送されている特定のファイル（群）を取得し、ストレージに蓄積するためのAPIである。

NRTダウンロードAPIは、引数として、dit_uriを指定することができる。

dit_uriには、DITメタデータの取得先のURI(Uniform Resource Identifier)が指定される。

（アプリケーション遷移API）
図１６は、アプリケーション遷移APIの例を示す図である。

アプリケーション遷移APIは、当該メソッドを実行した放送アプリケーションを終了し、引数で指定する放送アプリケーションを起動するAPIである。

アプリケーション遷移APIは、organization_id，application_id，及び、ait_uriを引数として指定することができる。

organization_idには、起動すべき放送アプリケーション（BCA）の事業者を識別する識別子である事業者IDが指定される。application_idには、起動すべき放送アプリケーション（BCA）を識別する識別子であるアプリケーションIDが指定される。すなわち、事業者IDとアプリケーションIDによって、起動すべき遷移先の放送アプリケーション（BCA）が識別されることになる。

ait_uriには、遷移先の放送アプリケーション（BCA）のAITのロケーション情報（例えば、URL）が指定される。例えば、遷移先の放送アプリケーション（BCA）が、ストアドアプリケーション（Stored App）となる場合には、ait_uriとして、そのストアドアプリケーション（Stored App）に対応するAITsのURLが指定される。

（その他のAPI）
図１７は、その他のAPIの例を示す図である。

アプリケーションリスト取得APIは、受信装置２０のストレージに蓄積されたストアドアプリケーション（Stored App）のリストを取得するためのAPIである。また、コンテンツリストAPIは、受信装置２０のストレージに蓄積されたNRTコンテンツ（コンテンツリソース（Content Resource））のリストを取得するためのAPIである。

コンテンツ情報取得APIは、受信装置２０のストレージに蓄積されたNRTコンテンツのメタデータ（コンテンツメタデータ（Content Meta））に含まれる情報を取得するためのAPIである。また、コンテンツ再生APIは、受信装置２０のストレージに蓄積されたNRTコンテンツを再生するためのAPIである。

シリーズ予約選局APIは、シリーズ単位で、サービス（例えば、NRTサービス等）の選局動作の予約を行うためのAPIである。すなわち、プログラム予約選局API（図１４）の代わりに、このシリーズ予約選局APIを実行することで、プログラム単位ではなく、所定のシリーズ単位で、NRTサービスの選局動作の予約を行うことが可能となる。なお、ここに列挙したAPIは一例であって、放送アプリケーション（BCA）により実行される他のAPIが規定されるようにしてもよい。

＜５．シンタックスの例＞

（DITのシンタックス）
図１８は、XML形式のDIT(Download Information Table)のシンタックスの例を示す図である。なお、図１８において、要素と属性のうち、属性には「@」が付されている。また、インデントされた要素と属性は、その上位の要素に対して指定されたものとなる。

DIT要素は、ルート要素であって、dl_id属性、dl_version属性、app_included属性、app_type属性、organization_id属性、application_id属性、app_version属性、expire属性、baseURI属性、及び、content_item要素の上位要素となる。

dl_id属性には、ダウンロードの単位を識別するダウンロードIDが指定される。dl_version属性には、同一のダウンロードIDにおけるバージョンが指定される。

app_included属性には、バックグラウンドNRTサービスで提供されるストアドアプリケーション（Stored App）が含まれるかどうかを示すフラグが指定される。すなわち、このフラグによって、バックグラウンドNRTサービスのタイプが、APPデータタイプであるのか、あるいは、RAWデータタイプであるのかを識別することができる。

例えば、app_included属性として"0"が指定された場合、ストアドアプリケーション（Stored App）が含まれない、RAWデータタイプのバックグラウンドNRTサービスであることを表している。一方で、app_included属性として"1"が指定された場合には、ストアドアプリケーション（Stored App）が含まれる、APPデータタイプのバックグラウンドNRTサービスであることを表している。

ここで、app_type属性、organization_id属性、application_id属性、及び、app_version属性には、アプリケーションに関する情報が指定されるが、これらの属性には、app_included属性として"1"が指定された場合（APPデータタイプのバックグラウンドNRTサービスの場合）には、ストアドアプリケーション（Stored App）に関する情報が指定される。一方で、app_included属性として"0"が指定された場合（RAWデータタイプのバックグラウンドNRTサービスの場合）には、これらの属性には、NRTコンテンツ（コンテンツリソース（Content Resource））を参照可能なアプリケーションに関する情報が指定される。

app_type属性には、アプリケーションのタイプが指定される。例えば、app_type属性として"std"が指定された場合、AIT(Application Information Table)に応じて起動する標準の放送アプリケーション（BCA）であることを表している。

また、app_type属性としては、例えば、"android"や"iOS"などの実行環境で動作するアプリケーションを指定することができる。"android"は、Android（登録商標）のプラットフォーム上で実行されるアプリケーションであることを表している。また、"iOS"は、iOS（登録商標）のプラットフォーム上で実行されるアプリケーションであることを表している。

organization_id属性には、事業者IDが指定される。application_id属性には、アプリケーションを識別するアプリケーションIDが指定される。すなわち、事業者IDとアプリケーションIDによって、対象のアプリケーションが識別されることになる。app_version属性には、アプリケーションのバージョンが指定される。

expire属性には、アプリケーションやNRTコンテンツなどのファイルの保持期限が指定される。

baseURI属性には、ダウンロード対象のファイルのURLのうち、共通部分の基本となるURL（ベースURL）が指定される。

content_item要素には、ダウンロード対象のファイルに関する情報が指定される。content_item要素は、item_path属性、item_type属性、item_version属性、expire属性、及び、essential属性の上位要素となる。

item_path属性には、ファイルのURL又はベースURLに続くファイルのパスが指定される。すなわち、baseURI属性により指定されるベースURLと、item_path属性により指定されるURLとを結合することで、特定のファイルのURLが指定される。例えば、このURLによって、ROUTEセッションで伝送されるファイルを特定したり、あるいは、ストレージに蓄積されたファイルを特定したりすることができる。

item_type属性には、ファイルのタイプが指定される。item_version属性には、ファイルのバージョンが指定される。expire属性には、各ファイルの保持期限が指定される。essential属性には、ダウンロードが必須か、あるいはオプションであるかを示すフラグが指定される。例えば、プレーヤなどの、同一のストアドアプリケーション（Stored App）がダウンロード済みであって、再度ダウンロードする必要がない場合には、essential属性として、"0"が指定される。

なお、図１８において、出現数（Cardinality）であるが、"1"が指定された場合にはその要素又は属性は必ず１つだけ指定され、"0..1"が指定された場合には、その要素又は属性を指定するかどうかは任意である。また、"1..N"が指定された場合には、その要素又は属性は１以上指定され、"0..N"が指定された場合には、その要素又は属性を１以上指定するかどうかは任意である。

また、data_typeとして、"unsigned Short"又は"unsigned integer"が指定された場合、その要素又は属性の値が、整数型であることを示している。また、Data Typeとして、"Boolean"が指定された場合には、その要素又は属性がブール型であることを示し、"string"が指定された場合には、その要素又は属性の値が、文字列型であることを示している。さらに、Data Typeとして、"dateTime"が指定された場合、その要素又は属性が日時型であることを示し、"anyURI"が指定された場合、その要素又は属性の値が、anyURIデータ型であることを示している。

なお、図１８に示したDITのシンタックスは、一例であって、例えば、他の要素や属性を追加したり、あるいは一部の要素や属性を削除したりするなど、他のシンタックスを採用してもよい。また、DITは、XML形式に限らず、他のマークアップ言語により記述してもよいし、あるいはセクション形式であってもよい。

＜６．各装置の構成＞

次に、図１の伝送システムを構成する、送信装置１０と受信装置２０の詳細な構成例について説明する。

（送信装置の構成）
図１９は、図１の送信装置１０の構成例を示す図である。

送信装置１０は、例えば、ATSC3.0等の所定の放送規格に準拠した送信機であり、データ伝送を、IP伝送方式のデジタル放送信号により行う。

図１９において、送信装置１０は、ビデオ取得部１０１、ビデオエンコーダ１０２、オーディオ取得部１０３、オーディオエンコーダ１０４、NRTコンポーネント生成部１０５、NRTコンポーネント処理部１０６、シグナリング生成部１０７、シグナリング処理部１０８、マルチプレクサ１０９、及び、送信部１１０から構成される。

ビデオ取得部１０１は、テレビ番組などの放送コンテンツを構成するビデオコンポーネントのデータを取得し、ビデオエンコーダ１０２に供給する。ビデオエンコーダ１０２は、ビデオ取得部１０１から供給されるビデオコンポーネントのデータを、所定の符号化方式に応じてエンコードし、マルチプレクサ１０９に供給する。

オーディオ取得部１０３は、テレビ番組などの放送コンテンツを構成するオーディオコンポーネントのデータを取得し、オーディオエンコーダ１０４に供給する。オーディオエンコーダ１０４は、オーディオ取得部１０３から供給されるオーディオコンポーネントのデータを、所定の符号化方式に応じてエンコードし、マルチプレクサ１０９に供給する。

ここで、放送コンテンツとしては、例えば、中継場所から伝送路や通信回線を介して送られてくるライブコンテンツ（例えば、スポーツ中継等の生放送番組）や、ストレージに蓄積されている収録済みコンテンツ（例えば、ドラマ等の事前収録番組）などが含まれる。

NRTコンポーネント生成部１０５は、NRTコンポーネントを生成し、NRTコンポーネント処理部１０６に供給する。NRTコンポーネント処理部１０６は、NRTコンポーネント生成部１０５から供給されるNRTコンポーネントを処理して、マルチプレクサ１０９に供給する。

ここで、NRTコンポーネントとしては、例えば、連動アプリケーション（Linked App）、フォアグランドアプリケーション（FG App）、又は、バックグラウンドアプリケーション（BG App）等の放送アプリケーション（BCA）が生成される。また、バックグラウンドNRTサービスの運用を行う場合には、NRTコンポーネントとして、対象ファイル群（ストアドアプリケーション（Stored App）やAITs）や参照ファイル群（コンテンツメタデータ（Content Meta）やコンテンツリソース（Content Resource））なども生成される。

なお、ここでは、説明の都合上、NRTコンテンツ（コンテンツメタデータ（Content Meta））が、NRTコンポーネント生成部１０５により生成され、NRTコンポーネント処理部１０６により処理されるとして説明するが、ビデオ取得部１０１やオーディオ取得部１０３などで処理される放送コンテンツが、NRTコンテンツとして処理されるようにしてもよい。

シグナリング生成部１０７は、シグナリングを生成し、シグナリング処理部１０８に供給する。シグナリング処理部１０８は、シグナリング生成部１０７から供給されるシグナリングを処理して、マルチプレクサ１０９に供給する。

ここで、シグナリングとしては、例えば、LLSシグナリング、又は、SLSシグナリングが生成される。LLSシグナリングには、SLT等のメタデータが含まれる。また、SLSシグナリングには、AIT等のメタデータが含まれる。さらに、バックグラウンドNRTサービスの運用を行う場合には、シグナリングとして、AITsとDITメタデータが生成される。ただし、AITsとDITメタデータは、NRTコンポーネントとして処理される。

マルチプレクサ１０９には、ビデオエンコーダ１０２から供給されるエンコードされたビデオコンポーネントのデータ、オーディオエンコーダ１０４から供給されるエンコードされたオーディオコンポーネントのデータ、NRTコンポーネント処理部１０６から供給されるNRTコンポーネントのデータ、又は、シグナリング処理部１０８から供給されるシグナリングのデータが供給される。

マルチプレクサ１０９は、ビデオコンポーネントのデータ、オーディオコンポーネントのデータ、NRTコンポーネントのデータ、及び、シグナリングのデータを多重化して、多重化ストリームを生成し、送信部１１０に供給する。

ただし、フォアグランドNRTサービス又はバックグラウンドNRTサービスの運用を行う場合には、放送コンテンツを構成するビデオコンポーネントやオーディオコンポーネントのデータを、多重化ストリームに含めなくてもよい。また、ここでは説明を省略するが、電子サービスガイド（ESG）や時刻情報（例えば、NTP(Network Time Protocol)）などのデータが多重化ストリームに含まれるようにしてもよい。

送信部１１０は、マルチプレクサ１０９から供給される多重化ストリームを処理して、アンテナ１２１を介して、IP伝送方式のデジタル放送信号として送信する。

ここでは、例えば、多重化ストリームのデータに対する誤り訂正符号化処理（例えば、BCH符号化やLDPC(Low Density Parity Check)符号化等）や変調処理（例えば、OFDM(Orthogonal Frequency Division Multiplexing)変調等）が行われ、その処理の結果得られる信号が、RF(Radio Frequency)信号に変換されて送信される。

送信装置１０は、以上のように構成される。なお、図１９においては、説明の都合上、送信側の装置が、送信装置、すなわち、１つの装置で構成される場合を示しているが、図１９のブロックの各機能を有する複数の装置からなる送信システムとして構成されるようにしてもよい。

（受信装置の構成）
図２０は、図１の受信装置２０の構成例を示す図である。

受信装置２０は、例えば、ATSC3.0等の所定の放送規格に準拠した受信機であり、送信装置１０から送信されてくる、IP伝送方式のデジタル放送信号を受信して処理する。

図２０において、受信装置２０は、制御部２０１、メモリ２０２、入力部２０３、受信部２０４、デマルチプレクサ２０５、シグナリング処理部２０６、ビデオデコーダ２０７、ビデオ出力部２０８、オーディオデコーダ２０９、オーディオ出力部２１０、NRTコンポーネント処理部２１１、ストレージ２１２、表示部２１３、及び、スピーカ２１４から構成される。

制御部２０１は、受信装置２０の各部の動作を制御する。

メモリ２０２は、NVRAM(Non Volatile RAM)等の不揮発性メモリである。メモリ２０２は、制御部２０１からの制御に従い、各種のデータを記憶する。

入力部２０３は、ユーザからの操作に応じた操作信号を、制御部２０１に供給する。制御部２０１は、入力部２０３からの操作信号に基づいて、受信装置２０の各部の動作を制御する。

受信部２０４は、送信装置１０から送信されてくるIP伝送方式のデジタル放送信号を、アンテナ２２１を介して受信して処理し、それにより得られる多重化ストリームを、デマルチプレクサ２０５に供給する。

ここでは、例えば、RF信号が、IF(Intermediate Frequency)信号に周波数変換されて、復調処理（例えばOFDM復調等）が行われ、その処理で得られる信号に対する、誤り訂正復号処理（例えばLDPC復号やBCH復号等）が行われる。

デマルチプレクサ２０５は、制御部２０１からの制御に従い、受信部２０４から供給される多重化ストリームを、ビデオコンポーネントのデータ、オーディオコンポーネントのデータ、NRTコンポーネントのデータ、又は、シグナリングのデータに分離する。

デマルチプレクサ２０５は、ビデオコンポーネントのデータをビデオデコーダ２０７、オーディオコンポーネントのデータをオーディオデコーダ２０９、NRTコンポーネントのデータをNRTコンポーネント処理部２１１、シグナリングのデータをシグナリング処理部２０６にそれぞれ供給する。

ただし、ここでは、NRTコンポーネントのデータのうち、バックグラウンドNRTサービスの運用時における対象ファイル群（Stored App，AITs）や参照ファイル群（Content Meta，Content Resource）のデータは、ストレージ２１２に蓄積される。

また、フォアグランドNRTサービス又はバックグラウンドNRTサービスの運用を行う場合には、放送コンテンツを構成するビデオコンポーネントやオーディオコンポーネントのデータが、多重化ストリームに含まれていない場合がある。また、ここでは説明を省略するが、電子サービスガイド（ESG）や時刻情報（例えば、NTP）などのデータが多重化ストリームに含まれる場合には、それらのデータに対する処理も行われる。

シグナリング処理部２０６は、デマルチプレクサ２０５から供給されるシグナリングを処理して、制御部２０１に供給する。制御部２０１は、シグナリング処理部２０６から供給されるシグナリングの処理結果に基づいて、放送コンテンツに対する処理などを行う受信装置２０の各部の動作を制御する。

ここで、シグナリングとしては、例えば、LLSシグナリング、又は、SLSシグナリングが処理される。LLSシグナリングには、SLT等のメタデータが含まれる。また、SLSシグナリングには、AIT等のメタデータが含まれる。

また、バックグラウンドNRTサービスの運用を行う場合には、シグナリングとして、DITメタデータが含まれる。制御部２０１は、シグナリング処理部２０６から供給されるDITメタデータの処理結果に基づいて、放送アプリケーション（BCA）やNRTコンポーネントに対する処理などを行う受信装置２０の各部の動作を制御する。

ビデオデコーダ２０７は、デマルチプレクサ２０５から供給されるビデオコンポーネントのデータを、所定の復号方式に応じてデコードし、ビデオ出力部２０８に供給する。ビデオ出力部２０８は、ビデオデコーダ２０７から供給されるビデオコンポーネントのデータに対応する映像を、表示部２１３に表示させる。

オーディオデコーダ２０９は、デマルチプレクサ２０５から供給されるオーディオコンポーネントのデータを、所定の復号方式に応じてデコードし、オーディオ出力部２１０に供給する。オーディオ出力部２１０は、オーディオデコーダ２０９から供給されるオーディオコンポーネントのデータに対応する音声を、スピーカ２１４から出力させる。

これにより、受信装置２０では、ライブコンテンツ（例えば、スポーツ中継等の生放送番組）や、収録済みコンテンツ（例えば、ドラマ等の事前収録番組）などの放送コンテンツが再生され、その映像や音声が出力されることになる。

NRTコンポーネント処理部２１１は、制御部２０１からの制御に従い、デマルチプレクサ２０５から供給されるNRTコンポーネントのデータを処理し、映像に関するデータを、ビデオ出力部２０８に供給し、音声に関するデータを、オーディオ出力部２１０に供給する。ここでは、NRTコンポーネントとして、例えば、連動アプリケーション（Linked App）、フォアグランドアプリケーション（FG App）、又は、バックグラウンドアプリケーション（BG App）等の放送アプリケーション（BCA）が処理される。

連動アプリケーション（Linked App）、及び、フォアグランドアプリケーション（FG App）は、その映像が表示されるアプリケーションであるため、当該アプリケーションのデータが、ビデオ出力部２０８に供給される。これにより、表示部２１３には、連動アプリケーション（Linked App）、又は、フォアグランドアプリケーション（FG App）の動作に応じた映像が表示される。一方で、バックグラウンドアプリケーション（BG App）は、バックグラウンド（裏）で動作するアプリケーションであるため、非表示とされる。

ストレージ２１２は、デマルチプレクサ２０５から供給されるNRTコンポーネントを蓄積する。ストレージ２１２に蓄積されるNRTコンポーネントとしては、バックグラウンドNRTサービスの運用を行う場合に、対象ファイル群（Stored App，AITs）や参照ファイル群（Content Meta，Content Resource）のデータが蓄積される。

NRTコンポーネント処理部２１１は、制御部２０１からの制御に従い、ストレージ２１２に蓄積されたNRTコンポーネントのデータを読み出して処理し、映像に関するデータを、ビデオ出力部２０８に供給し、音声に関するデータを、オーディオ出力部２１０に供給する。ここでは、NRTコンポーネントとして、対象ファイル群（Stored App，AITs）や参照ファイル群（Content Meta，Content Resource）のデータが処理され、ストアドアプリケーション（Stored App）やNRTコンテンツに関する処理が行われる。

ストアドアプリケーション（Stored App）は、その映像が表示されるアプリケーションであるため、当該アプリケーションのデータが、ビデオ出力部２０８に供給される。これにより、表示部２１３には、ストアドアプリケーション（Stored App）の動作に応じた映像が表示される。

また、例えば、NRTコンテンツが動画等である場合には、そのビデオコンポーネントのデータがビデオ出力部２０８に供給され、そのオーディオコンポーネントのデータがオーディオ出力部２１０に供給され、動画等のNRTコンテンツの映像と音声が出力（再生）される。さらに、例えば、NRTコンテンツが音楽等である場合には、そのオーディオコンポーネントのデータがオーディオ出力部２１０に供給され、音楽等のNRTコンテンツの音声が出力（再生）される。

受信装置２０は、以上のように構成される。なお、受信装置２０は、例えば、テレビ受像機、セットトップボックス（STB：Set Top Box）、又は、録画機などの固定受信機のほか、携帯電話機、スマートフォン、又はタブレット端末などのモバイル受信機であってもよい。また、受信装置２０は、車両に搭載される車載機器でもよい。

さらに、図２０の受信装置２０の構成では、表示部２１３とスピーカ２１４が、内蔵されている構成を示したが、表示部２１３とスピーカ２１４は、受信装置２０の外部に設けられるようにしてもよい。また、図２０の受信装置２０の構成では、図示していないが、受信装置２０には、レジデントアプリケーション（RA）があらかじめ内蔵されており、このレジデントアプリケーション（RA）により各種の処理が実行される。また、NRTコンポーネント処理部２１１は、例えば、HTML5に対応したブラウザなどとされる。

（ソフトウェアとハードウェアの階層構造）
図２１は、図２０の受信装置２０における、ソフトウェアとハードウェアの階層構造の例を示す図である。

図２１において、オペレーティングシステム（OS：Operating System）は、ハードウェアの管理を行う。また、オペレーティングシステム（OS）は、アプリケーションとハードウェアの間のインターフェースを提供し、オペレーティングシステム（OS）上で動作するアプリケーションは、オペレーティングシステム（OS）に組み込まれた規則や手続きなどに従うことで、ハードウェアとやりとりを行うことができる。

ここで、受信装置２０において、オペレーティングシステム（OS）上で動作するアプリケーションとしては、大別すると、機器内蔵アプリケーションと、放送アプリケーション（BCA）の２種類がある。

機器内蔵アプリケーションは、あらかじめ内蔵されたアプリケーションであって、例えば、レジデントアプリケーション（RA）、録画再生制御アプリケーション、及び、ブラウザなどを含む。また、放送アプリケーション（BCA）は、放送経由で取得されるアプリケーションであって、連動アプリケーション（Linked App）、フォアグランドアプリケーション（FG App）、バックグラウンドアプリケーション（BG App）、及び、ストアドアプリケーション（Stored App）などを含む。なお、放送アプリケーション（BCA）は、HTML5などにより開発される。

従来の技術では、NRTサービスの運用を行う場合に、レジデントアプリケーション（RA）が、NRTコンテンツのダウンロード再生に関する処理を行っていたため、レジデントアプリケーション（RA）の実装に大きな負担がかかっていた。

一方で、本技術では、NRTサービスの運用を行う場合に、バックグラウンドアプリケーション（BG App）などの放送アプリケーション（BCA）が、NRTコンテンツのダウンロード再生に関する処理を行うため、レジデントアプリケーション（RA）の実装負担をより少なくして、NRTコンテンツのダウンロード再生を行うことができる。また、本技術では、バックグラウンドアプリケーション（BG App）が、NRTコンテンツのダウンロード時に参照するメタデータとして、DITメタデータを規定している。

＜７．各装置で実行される処理の流れ＞

次に、図１の伝送システムを構成する、送信装置１０と受信装置２０で実行される処理の流れについて説明する。

（送信処理の流れ）
まず、図２２のフローチャートを参照して、図１の送信装置１０により実行される送信処理の流れについて説明する。

ステップＳ１０１において、ビデオ取得部１０１及びビデオエンコーダ１０２は、ビデオコンポーネントを処理する。また、ステップＳ１０１において、オーディオ取得部１０３及びオーディオエンコーダ１０４は、オーディオコンポーネントを処理する。

このコンポーネントの処理では、ライブコンテンツ（例えば生放送番組）や収録済みコンテンツ（例えば事前収録番組）などの放送コンテンツが取得され、所定の符号化方式に応じたエンコードなどの処理が行われる。

ステップＳ１０２において、NRTコンポーネント生成部１０５及びNRTコンポーネント処理部１０６は、NRTコンポーネントを処理する。

このNRTコンポーネントの処理では、例えば、連動アプリケーション（Linked App）、フォアグランドアプリケーション（FG App）、バックグラウンドアプリケーション（BG App）、又は、ストアドアプリケーション（Stored App）等の放送アプリケーション（BCA）が生成され、処理される。また、バックグラウンドNRTサービスの運用を行う場合には、NRTコンポーネントとして、対象ファイル群（ストアドアプリケーション（Stored App）やAITs）や参照ファイル群（コンテンツメタデータ（Content Meta）やコンテンツリソース（Content Resource））なども生成され、処理される。

ステップＳ１０３において、シグナリング生成部１０７及びシグナリング処理部１０８は、シグナリングを処理する。

このシグナリングの処理では、SLT等のメタデータを含むLLSシグナリング、又は、AIT等のメタデータを含むSLSシグナリングが生成され、処理される。また、バックグラウンドNRTサービスの運用を行う場合には、シグナリングとして、DITメタデータが生成され、処理される。

ステップＳ１０４において、マルチプレクサ１０９は、ステップＳ１０１の処理で得られるビデオコンポーネント及びオーディオコンポーネントのデータ、ステップＳ１０２の処理で得られるNRTコンポーネントのデータ、及び、ステップＳ１０３の処理で得られるシグナリングのデータが多重化され、多重化ストリームが生成される。

ただし、フォアグランドNRTサービス又はバックグラウンドNRTサービスの運用を行う場合には、放送コンテンツを構成するビデオコンポーネントやオーディオコンポーネントのデータを、多重化ストリームに含めなくてもよい。

ステップＳ１０５において、送信部１１０は、ステップＳ１０４の処理で生成された多重化ストリームを処理して、アンテナ１２１を介して、IP伝送方式のデジタル放送信号として送信する。ステップＳ１０５の処理が終了すると、図２２の送信処理は終了される。

以上、送信処理の流れについて説明した。

（選局処理の流れ）
次に、図２３のフローチャートを参照して、図１の受信装置２０により実行される選局処理の流れについて説明する。

ステップＳ２０１においては、制御部２０１は、入力部２０３からの操作信号に基づいて、ユーザによりサービスの選局が指示されたかどうかを判定する。ステップＳ２０１においては、ユーザにより選局が指示されたと判定されるまで、判定処理が繰り返される。ステップＳ２０１において、ユーザにより選局が指示されたと判定された場合、処理は、ステップＳ２０２に進められる。

ステップＳ２０２乃至Ｓ２０６においては、制御部２０１が、メモリ２０２に記憶されている選局情報（例えば、SLTに含まれる情報）などに基づいて、受信装置２０の各部の動作を制御することで、選局処理が行われる。この選局処理では、具体的には、以下の処理が実行される。

ステップＳ２０２において、受信部２０４は、制御部２０１からの制御に従い、送信装置１０から伝送路３０を介して送信されてくる、IP伝送方式のデジタル放送信号を、アンテナ２２１を介して受信して、処理する。

ステップＳ２０３において、デマルチプレクサ２０５は、制御部２０１からの制御に従い、ステップＳ２０２の処理で得られる多重化ストリームを分離する。

ステップＳ２０４において、シグナリング処理部２０６は、ステップＳ２０３の処理で分離されたシグナリング（SLSシグナリング）のデータを処理する。制御部２０１は、ステップＳ２０４の処理で処理されたシグナリング（SLSシグナリング）に基づいて、コンポーネントの処理を行う各部の動作を制御する。

ステップＳ２０５において、ビデオデコーダ２０７は、ステップＳ２０３の処理で分離されたビデオコンポーネントのデータを処理（デコード）する。また、ステップＳ２０５において、オーディオデコーダ２０９は、ステップＳ２０３の処理で分離されたオーディオコンポーネントのデータを処理（デコード）する。

ステップＳ２０６において、ビデオ出力部２０８は、ビデオデコーダ２０７からのビデオコンポーネントのデータを処理（レンダリング処理）し、ビデオコンポーネントのデータに対応する映像を、表示部２１３に表示する。また、ステップＳ２０６において、オーディオ出力部２１０は、オーディオデコーダ２０９からのオーディオコンポーネントのデータを処理（レンダリング処理）し、オーディオコンポーネントのデータに対応する音声を、スピーカ２１４から出力する。

これにより、受信装置２０においては、ライブコンテンツ（例えば生放送番組）や収録済みコンテンツ（例えば事前収録番組）などの放送コンテンツの映像が、表示部２１３に表示され、その映像に同期した音声が、スピーカ２１４から出力される。ステップＳ２０６の処理が終了すると、図２３の選局処理は終了される。

以上、選局処理の流れについて説明した。

（NRTサービス対応処理の流れ）
次に、図２４のフローチャートを参照して、図１の受信装置２０により実行されるNRTサービス対応処理の流れについて説明する。

ステップＳ２１１において、制御部２０１は、受信装置２０により実行されるNRTサービスが、NRT連動TVサービスであるかどうかを判定する。ステップＳ２１１において、NRTサービスが、NRT連動TVサービスであると判定された場合、処理は、ステップＳ２１２に進められる。

ステップＳ２１２乃至Ｓ２１４においては、NRT連動TVサービスに対応した処理が実行されるが、このNRT連動TVサービスの場合、連動アプリケーション（Linked App）が、放送コンテンツに連動して実行されるアプリケーションであるため、受信装置２０では、図２３の選局処理によって、放送コンテンツが再生されているものとする。

ステップＳ２１２において、シグナリング処理部２０６は、ROUTEセッションで、SLSシグナリングとして伝送されるAITを取得して、処理する（例えば解析処理を行う）。また、制御部２０１は、ステップＳ２１２の処理結果（AITの解析結果）に基づいて、各部の動作を制御する。

ステップＳ２１３において、NRTコンポーネント処理部２１１は、制御部２０１からの制御に従い、ROUTEセッションで、NRTコンポーネントとして伝送される、連動アプリケーション（Linked App）を取得する。

ステップＳ２１４において、NRTコンポーネント処理部２１１は、ステップＳ２１３の処理で取得された連動アプリケーション（Linked App）を起動して、実行する。これにより、受信装置２０では、放送コンテンツに連動して、連動アプリケーション（Linked App）が実行され、表示部２１３には、放送コンテンツの映像とともに、連動アプリケーション（Linked App）の動作に応じた映像が表示される。

一方、ステップＳ２１１において、NRTサービスが、NRT連動TVサービスではないと判定された場合、処理は、ステップＳ２１５に進められる。

ステップＳ２１５において、制御部２０１は、受信装置２０により実行されるNRTサービスが、フォアグランドNRTサービスであるかどうかを判定する。ステップＳ２１５において、NRTサービスが、フォアグランドNRTサービスであると判定された場合、処理は、ステップＳ２１６に進められる。

ステップＳ２１６乃至Ｓ２１８においては、フォアグランドNRTサービスに対応した処理が実行されるが、このフォアグランドNRTサービスの場合、フォアグランドアプリケーション（FG App）が、ポータル（ポータルページ）の映像を全画面で表示させるアプリケーションであるため、受信装置２０では、放送コンテンツが必ずしも再生されている必要はない。

ステップＳ２１６において、シグナリング処理部２０６は、ROUTEセッションで、SLSシグナリングとして伝送されるAITを取得して、処理する（例えば解析処理を行う）。また、制御部２０１は、ステップＳ２１６の処理結果（AITの解析結果）に基づいて、各部の動作を制御する。

ステップＳ２１７において、NRTコンポーネント処理部２１１は、制御部２０１からの制御に従い、ROUTEセッションで、NRTコンポーネントとして伝送される、フォアグランドアプリケーション（FG App）を取得する。

ステップＳ２１８において、NRTコンポーネント処理部２１１は、ステップＳ２１７の処理で取得されたフォアグランドアプリケーション（FG App）を起動して、実行する。これにより、受信装置２０では、フォアグランドアプリケーション（FG App）の動作に応じたポータル（ポータルページ）の映像が、表示部２１３の全画面で表示される。

一方、ステップＳ２１５において、NRTサービスが、フォアグランドNRTサービスではないと判定された場合、処理は、ステップＳ２１９に進められる。

ステップＳ２１９において、制御部２０１は、受信装置２０により実行されるNRTサービスが、バックグラウンドNRTサービスであるかどうかを判定する。ステップＳ２１９において、NRTサービスが、バックグラウンドNRTサービスであると判定された場合、処理は、ステップＳ２２０に進められる。

ステップＳ２２０においては、バックグラウンドNRTサービスに対応した処理が実行されるが、このバックグラウンドNRTサービスの場合、バックグラウンドアプリケーション（BG App）が、バックグラウンド（裏）で動作する非表示のアプリケーションであるため、受信装置２０では、放送コンテンツが必ずしも再生されている必要はない。

ステップＳ２２０において、NRTコンポーネント処理部２１１などは、制御部２０１からの制御に従い、バックグラウンドNRTサービス対応処理を行う。このバックグラウンドNRTサービス対応処理では、APPタイプ又はRAWデータタイプのタイプに応じたバックグラウンドNRTサービス対応処理が実行される。

ここで、APPタイプのバックグラウンドNRTサービス対応処理の場合、対象ファイル群（ストアドアプリケーション（Stored App）やAITs）や参照ファイル群（コンテンツメタデータ（Content Meta）やコンテンツリソース（Content Resource））のデータが取得され、ストレージ２１２に蓄積される。一方で、RAWデータタイプのバックグラウンドNRTサービス対応処理の場合、参照ファイル群（コンテンツメタデータ（Content Meta）やコンテンツリソース（Content Resource））のデータのみが取得され、ストレージ２１２に蓄積される。

なお、バックグラウンドNRTサービス対応処理の詳細な内容は、図２５のフローチャートを参照して後述する。

また、ステップＳ２１９において、NRTサービスが、バックグラウンドNRTサービスではないと判定された場合、NRTサービスの処理は実行されないため、ステップＳ２２０の処理はスキップされる。そして、ステップＳ２１４、ステップＳ２１８、又は、ステップＳ２２０の処理が終了すると、図２４のNRTサービス対応処理は、終了される。

以上、NRTサービス対応処理の流れについて説明した。

（バックグラウンドNRTサービス対応処理の流れ）
次に、図２５のフローチャートを参照して、図２４のステップＳ２２０の処理に対応する、バックグラウンドNRTサービス対応処理の流れについて説明する。

ステップＳ２３１においては、制御部２０１は、連動アプリケーション（Linked App）又はフォアグランドアプリケーション（FG App）等の放送アプリケーション（BCA）の動作に応じて、例えばユーザによって予約選局が指示されたかどうかを判定する。ステップＳ２３１においては、予約選局が指示されたと判定されるまで、判定処理が繰り返される。ステップＳ２３１において、予約選局が指示されたと判定された場合、処理は、ステップＳ２３２に進められる。

ステップＳ２３２において、NRTコンポーネント処理部２１１は、制御部２０１からの制御に従い、連動アプリケーション（Linked App）又はフォアグランドアプリケーション（FG App）によって、プログラム予約選局API又はプログラム予約選局APIを実行することで、予約選局処理を行う。この予約選局処理によって、プログラム単位又はシリーズ単位でのNRTサービスの選局動作の予約が行われる。

ステップＳ２３３においては、ステップＳ２３２の処理（予約選局処理）で設定された選局開始時刻になったかどうかが判定される。ステップＳ２３３においては、選局開始時刻になったと判定されるまで、判定処理が繰り返される。ステップＳ２３３において、選局開始時刻になったと判定された場合、処理は、ステップＳ２３４に進められる。

ステップＳ２３４において、制御部２０１などは、ステップＳ２３２の処理（予約選局処理）で設定されたNRTサービスの選局を行う。また、ステップＳ２３４において、シグナリング処理部２０６は、NRTサービスの選局動作に応じて、ROUTEセッションで、SLSシグナリングとして伝送される、バックグラウンドアプリケーション（BG App）の動作を制御するためのAITを取得して処理（解析処理）する。制御部２０１は、ステップＳ２３４の処理（解析処理）の結果に基づいて、各部の動作を制御する。

ステップＳ２３５において、NRTコンポーネント処理部２１１は、制御部２０１からの制御に従い、ROUTEセッションで、NRTコンポーネントとして伝送される、バックグラウンドアプリケーション（BG App）を取得する。

ステップＳ２３６において、NRTコンポーネント処理部２１１は、制御部２０１からの制御に従い、ステップＳ２３５の処理で取得されたバックグラウンドアプリケーション（BG App）を起動して実行を開始する。なお、バックグラウンドアプリケーション（BG App）は、バックグラウンド（裏）で動作するアプリケーションであるため、非表示とされる。

ステップＳ２３７において、NRTコンポーネント処理部２１１は、非表示のバックグラウンドアプリケーション（BG App）によって、NRTダウンロードAPIを実行する。これにより、シグナリング処理部２０６は、ROUTEセッションで、NRTコンポーネントとして伝送されるDITメタデータを取得する。

ステップＳ２３８において、シグナリング処理部２０６は、ステップＳ２３７の処理で取得されたDITメタデータを解析する。

ステップＳ２３９において、制御部２０１は、ステップＳ２３８の処理の解析結果に基づいて、DITメタデータに含まれるapp_included属性の属性値が、APPデータタイプのバックグラウンドNRTサービスを表しているか、あるいは、RAWデータタイプのバックグラウンドNRTサービスを表しているかを判定する。

ステップＳ２３９において、app_included属性の属性値が、APPデータタイプのバックグラウンドNRTサービスを表していると判定された場合、処理は、ステップＳ２４０に進められる。

ステップＳ２４０において、NRTコンポーネント処理部２１１は、制御部２０１からの制御に従い、非表示のバックグラウンドアプリケーション（BG App）を動作させることで、ROUTEセッションで、NRTコンポーネントとして伝送される、AITs及びストアドアプリケーション（Stored App）を含む対象ファイル群のデータ、並びに、コンテンツリソース（Content Resource）及びコンテンツメタデータ（Content Meta）を含む参照ファイル群のデータを取得する。

ステップＳ２４１において、NRTコンポーネント処理部２１１は、制御部２０１からの制御に従い、非表示のバックグラウンドアプリケーション（BG App）を動作させることで、ステップＳ２４０の処理で取得された、AITs及びストアドアプリケーション（Stored App）を含む対象ファイル群のデータ、並びに、コンテンツリソース（Content Resource）及びコンテンツメタデータ（Content Meta）を含む参照ファイル群のデータを、ストレージ２１２に記録（蓄積）する。

一方で、ステップＳ２３９において、app_included属性の属性値が、RAWデータタイプのバックグラウンドNRTサービスを表していると判定された場合、処理は、ステップＳ２４２に進められる。

ステップＳ２４２において、NRTコンポーネント処理部２１１は、制御部２０１からの制御に従い、非表示のバックグラウンドアプリケーション（BG App）を動作させることで、ROUTEセッションで、NRTコンポーネントとして伝送される、コンテンツリソース（Content Resource）及びコンテンツメタデータ（Content Meta）を含む参照ファイル群のデータを取得する。

ステップＳ２４３において、NRTコンポーネント処理部２１１は、制御部２０１からの制御に従い、非表示のバックグラウンドアプリケーション（BG App）を動作させることで、ステップＳ２４２の処理で取得された、コンテンツリソース（Content Resource）及びコンテンツメタデータ（Content Meta）を含む参照ファイル群のデータを、ストレージ２１２に記録（蓄積）する。

ステップＳ２４１、又は、ステップＳ２４３の処理が終了すると、処理は、ステップＳ２４４に進められる。ステップＳ２４４においては、ステップＳ２３２の処理（予約選局処理）で設定された選局時間を経過したかどうかが判定される。

ステップＳ２４４において、選局時間を経過していないと判定された場合、処理は、ステップＳ２３９に戻り、それ以降の処理が繰り返される。

すなわち、APPデータタイプのバックグラウンドNRTサービス対応処理が行われている場合、選局開始時刻から開始されたNRTコンテンツのダウンロード処理が、選局時間を経過するまで継続され、NRTコンポーネントとして伝送される対象ファイル群のデータ及び参照ファイル群のデータが、ストレージ２１２に蓄積される（Ｓ２４０，Ｓ２４１）。

また、RAWデータタイプのバックグラウンドNRTサービス対応処理が行われている場合、選局開始時刻から開始されたNRTコンテンツのダウンロード処理が、選局時間を経過するまで継続され、NRTコンポーネントとして伝送される参照ファイル群のデータのみが、ストレージ２１２に蓄積される（Ｓ２４２，Ｓ２４３）。

そして、ステップＳ２４４において、選局時間を経過したと判定された場合、処理は、図２４のステップＳ２２０の処理に戻り、それ以降の処理が実行される。

以上、バックグラウンドNRTサービス対応処理の流れについて説明した。

（イベント対応処理の流れ）
最後に、図２６のフローチャートを参照して、図１の受信装置２０により実行されるイベント対応処理の流れについて説明する。なお、このイベント対応処理は、連動アプリケーション（Linked App）、フォアグランドアプリケーション（FG App）、又はストアドアプリケーション（Stored App）などの放送アプリケーション（BCA）によって、各種のAPIが実行されることになるので、それらの放送アプリケーション（BCA）が起動していることが前提とされる。

ステップＳ２５１において、制御部２０１は、入力部２０３からの操作信号などに基づいて、ユーザにより、放送アプリケーション（BCA）の遷移が指示されたかどうかを判定する。

ステップＳ２５１において、放送アプリケーション（BCA）の遷移が指示されたと判定された場合、処理は、ステップＳ２５２に進められる。ステップＳ２５２において、NRTコンポーネント処理部２１１は、制御部２０１の制御に従い、放送アプリケーション（BCA）によって、アプリケーション遷移APIを実行することで、遷移元の放送アプリケーション（BCA）を終了し、遷移先の放送アプリケーション（BCA）を起動する。

ここでは、例えば、連動アプリケーション（Linked App）又はフォアグランドアプリケーション（FG App）から、ストアドアプリケーション（Stored App）に遷移したり、あるいは、ストアドアプリケーション（Stored App）から、連動アプリケーション（Linked App）又はフォアグランドアプリケーション（FG App）に遷移したりすることができる。

また、ステップＳ２５１において、放送アプリケーション（BCA）の遷移が指示されていないと判定された場合、処理は、ステップＳ２５３に進められる。ステップＳ２５３において、制御部２０１は、入力部２０３からの操作信号などに基づいて、ユーザにより、ストアドアプリケーション（Stored App）のリストの表示が指示されたかどうかを判定する。

ステップＳ２５３において、ストアドアプリケーション（Stored App）のリストの表示が指示されたと判定された場合、処理は、ステップＳ２５４に進められる。ステップＳ２５４において、NRTコンポーネント処理部２１１は、制御部２０１の制御に従い、放送アプリケーション（BCA）によって、アプリケーションリスト取得APIを実行することで、ストレージ２１２に蓄積されたストアドアプリケーション（Stored App）のリスト（AITsに応じたリスト）を取得する。

ステップＳ２５５において、NRTコンポーネント処理部２１１は、制御部２０１の制御に従い、ステップＳ２５４の処理で取得されたストアドアプリケーション（Stored App）のリストを、ビデオ出力部２０８を介して表示部２１３に表示させる。

ここでは、例えば、連動アプリケーション（Linked App）、フォアグランドアプリケーション（FG App）、又は、ストアドアプリケーション（Stored App）に対する、ユーザの操作に応じて、ストアドアプリケーション（Stored App）のリストの表示が指示され、ストアドアプリケーション（Stored App）のリストが表示される。

また、ステップＳ２５３において、ストアドアプリケーション（Stored App）のリストの表示が指示されていないと判定された場合、処理は、ステップＳ２５６に進められる。ステップＳ２５６において、制御部２０１は、入力部２０３からの操作信号などに基づいて、ユーザにより、NRTコンテンツのリストの表示が指示されたかどうかを判定する。

ステップＳ２５６において、NRTコンテンツのリストの表示が指示されたと判定された場合、処理は、ステップＳ２５７に進められる。ステップＳ２５７において、NRTコンポーネント処理部２１１は、制御部２０１の制御に従い、放送アプリケーション（BCA）によって、コンテンツリスト取得APIを実行することで、ストレージ２１２に蓄積されたNRTコンテンツのリスト（コンテンツメタデータ（Content Meta）に応じたリスト）を取得する。

ステップＳ２５８において、NRTコンポーネント処理部２１１は、制御部２０１の制御に従い、ステップＳ２５７の処理で取得されたNRTコンテンツのリストを、ビデオ出力部２０８を介して表示部２１３に表示させる。ここでは、例えば、ストアドアプリケーション（Stored App）に対する、ユーザの操作に応じて、NRTコンテンツのリストの表示が指示され、NRTコンテンツのリストが表示される。

また、ステップＳ２５６において、NRTコンテンツのリストの表示が指示されていないと判定された場合、処理は、ステップＳ２５９に進められる。ステップＳ２５９において、制御部２０１は、入力部２０３からの操作信号などに基づいて、ユーザにより、NRTコンテンツの情報の表示が指示されたかどうかを判定する。

ステップＳ２５９において、NRTコンテンツの情報の表示が指示されたと判定された場合、処理は、ステップＳ２６０に進められる。ステップＳ２６０において、NRTコンポーネント処理部２１１は、制御部２０１の制御に従い、放送アプリケーション（BCA）によって、コンテンツ情報取得APIを実行することで、ストレージ２１２に蓄積されたNRTコンテンツの情報（コンテンツメタデータ（Content Meta）に含まれる情報）を取得する。

ステップＳ２６１において、NRTコンポーネント処理部２１１は、制御部２０１の制御に従い、ステップＳ２６０の処理で取得されたNRTコンテンツの情報を、ビデオ出力部２０８を介して表示部２１３に表示させる。ここでは、例えば、ストアドアプリケーション（Stored App）に対する、ユーザの操作に応じて、NRTコンテンツの情報の表示が指示され、NRTコンテンツの情報が表示される。

また、ステップＳ２５９において、NRTコンテンツの情報の表示が指示されていないと判定された場合、処理は、ステップＳ２６２に進められる。ステップＳ２６２において、制御部２０１は、入力部２０３からの操作信号などに基づいて、ユーザにより、NRTコンテンツの再生が指示されたかどうかを判定する。

ステップＳ２６２において、NRTコンテンツの再生が指示されたと判定された場合、処理は、ステップＳ２６３に進められる。ステップＳ２６３において、NRTコンポーネント処理部２１１は、制御部２０１の制御に従い、放送アプリケーション（BCA）によって、コンテンツ再生APIを実行することで、ストレージ２１２に蓄積された再生対象のNRTコンテンツを再生する。ここでは、例えば、ストアドアプリケーション（Stored App）に対する、ユーザの操作に応じて、NRTコンテンツの再生が指示され、再生対象のNRTコンテンツが再生される。

なお、ステップＳ２６２において、NRTコンテンツの再生が指示されていないと判定された場合、各種のAPIに対応する処理は実行されないため、ステップＳ２６３の処理はスキップされる。ただし、上述したAPIは一例であって、他のAPIが規定される場合には、ステップＳ２６２の処理で、「NO」と判定された場合に、実行されるようにすればよい。

また、ステップＳ２５２、ステップＳ２５５、ステップＳ２５８、ステップＳ２６１、又は、ステップＳ２６３の処理が終了すると、図２６のイベント対応処理は終了される。

以上、イベント対応処理の流れについて説明した。

＜８．変形例＞

上述した説明としては、デジタル放送の規格として、米国等で採用されている方式であるATSC（特に、ATSC3.0）を説明したが、本技術は、日本等が採用する方式であるISDB(Integrated Services Digital Broadcasting)や、欧州の各国等が採用する方式であるDVB(Digital Video Broadcasting)などに適用するようにしてもよい。また、その場合において、デジタル放送としては、地上波放送のほか、BS(Broadcasting Satellite)やCS(Communications Satellite)等の衛星放送や、ケーブルテレビ（CATV）等の有線放送などに適用することができる。

また、本技術は、伝送路として、放送網以外の伝送路、すなわち、例えば、インターネットや電話網等の通信回線（通信網）などを利用することを想定して規定されている所定の規格（放送規格以外の規格）などにも適用することができる。その場合には、伝送路３０として、インターネットや電話網などの通信回線が利用され、送信装置１０は、インターネット上に設けられたサーバとすることができる。そして、受信装置２０が通信機能を有するようにすることで、送信装置１０は、受信装置２０からの要求に応じて、処理を行うことになる。また、受信装置２０は、送信装置１０（サーバ）から伝送路３０（通信回線）を介して送信されてくるデータを処理する。

さらに、上述したLLSやSLS等のシグナリングの名称は、一例であって、他の名称が用いられる場合がある。ただし、これらの名称の違いは、形式的な違いであって、各シグナリングの実質的な内容が異なるものではない。さらに、シグナリングがXML等のマークアップ言語により記述される場合において、それらの要素や属性の名称は一例であって、他の名称が採用されるようにしてもよい。ただし、これらの名称の違いは、形式的な違いであって、それらの要素や属性の実質的な内容が異なるものではない。

また、放送アプリケーション（BCA）は、HTML5などのマークアップ言語で開発されたアプリケーションに限らず、例えば、Java（登録商標）などのプログラミング言語で開発されたアプリケーションであってもよい。なお、連動アプリケーション（Linked App）は、TDO(Triggered Declarative Objects)と称され、フォアグランドアプリケーション（FG App）は、NDO(NRT Declarative Objects)と称される場合がある。また、NRTコンテンツには、動画や音楽のほか、例えば、電子書籍やゲーム、広告など、あらゆるコンテンツを含めることができる。

＜９．コンピュータの構成＞

上述した一連の処理は、ハードウェアにより実行することもできるし、ソフトウェアにより実行することもできる。一連の処理をソフトウェアにより実行する場合には、そのソフトウェアを構成するプログラムが、コンピュータにインストールされる。図２７は、上述した一連の処理をプログラムにより実行するコンピュータのハードウェアの構成例を示す図である。

コンピュータ９００において、CPU(Central Processing Unit)９０１，ROM(Read Only Memory)９０２，RAM(Random Access Memory)９０３は、バス９０４により相互に接続されている。バス９０４には、さらに、入出力インターフェース９０５が接続されている。入出力インターフェース９０５には、入力部９０６、出力部９０７、記録部９０８、通信部９０９、及び、ドライブ９１０が接続されている。

入力部９０６は、キーボード、マウス、マイクロフォンなどよりなる。出力部９０７は、ディスプレイ、スピーカなどよりなる。記録部９０８は、ハードディスクや不揮発性のメモリなどよりなる。通信部９０９は、ネットワークインターフェースなどよりなる。ドライブ９１０は、磁気ディスク、光ディスク、光磁気ディスク、又は半導体メモリなどのリムーバブルメディア９１１を駆動する。

以上のように構成されるコンピュータ９００では、CPU９０１が、ROM９０２や記録部９０８に記録されているプログラムを、入出力インターフェース９０５及びバス９０４を介して、RAM９０３にロードして実行することにより、上述した一連の処理が行われる。

コンピュータ９００（CPU９０１）が実行するプログラムは、例えば、パッケージメディア等としてのリムーバブルメディア９１１に記録して提供することができる。また、プログラムは、ローカルエリアネットワーク、インターネット、デジタル衛星放送といった、有線又は無線の伝送媒体を介して提供することができる。

コンピュータ９００では、プログラムは、リムーバブルメディア９１１をドライブ９１０に装着することにより、入出力インターフェース９０５を介して、記録部９０８にインストールすることができる。また、プログラムは、有線又は無線の伝送媒体を介して、通信部９０９で受信し、記録部９０８にインストールすることができる。その他、プログラムは、ROM９０２や記録部９０８に、あらかじめインストールしておくことができる。

ここで、本明細書において、コンピュータがプログラムに従って行う処理は、必ずしもフローチャートとして記載された順序に沿って時系列に行われる必要はない。すなわち、コンピュータがプログラムに従って行う処理は、並列的あるいは個別に実行される処理（例えば、並列処理あるいはオブジェクトによる処理）も含む。また、プログラムは、１のコンピュータ（プロセッサ）により処理されるものであってもよいし、複数のコンピュータによって分散処理されるものであってもよい。

なお、本技術の実施の形態は、上述した実施の形態に限定されるものではなく、本技術の要旨を逸脱しない範囲において種々の変更が可能である。

また、本技術は、以下のような構成をとることができる。

（１）
デジタル放送信号を受信する受信部と、
前記デジタル放送信号に含まれる第１のアプリケーションであって、非リアルタイムで再生されるコンテンツのダウンロードを処理する前記第１のアプリケーションを取得する第１の取得部と、
前記第１のアプリケーションの動作に応じて、前記デジタル放送信号に含まれるメタデータであって、前記コンテンツのダウンロードを制御するための情報を含む前記メタデータを取得する第２の取得部と、
前記メタデータに基づいて、前記第１のアプリケーションの動作を制御して、前記デジタル放送信号に含まれる前記コンテンツのダウンロードを処理する制御部と
を備える受信装置。
（２）
前記メタデータは、
前記コンテンツに関する第１の情報と、
前記コンテンツを処理する第２のアプリケーションに関する第２の情報と、
前記デジタル放送信号に、前記コンテンツとともに、前記第２のアプリケーションが含まれるかどうかを示す第３の情報と
を少なくとも含む
（１）に記載の受信装置。
（３）
前記第２の情報は、
前記第３の情報が、前記第２のアプリケーションが含まれることを示している場合、前記コンテンツとともにダウンロードされる前記第２のアプリケーションに関する情報を含み、
前記第３の情報が、前記第２のアプリケーションが含まれないことを示している場合、前記コンテンツとは別に取得される他のアプリケーションに関する情報を含む
（２）に記載の受信装置。
（４）
前記第１のアプリケーションは、バックグラウンドで動作するアプリケーションである
（１）乃至（３）のいずれか一項に記載の受信装置。
（５）
前記第１のアプリケーションは、前記第１のアプリケーションを制御するための第１の制御情報に応じて取得され、
前記第２のアプリケーションは、前記第２のアプリケーションを制御するための第２の制御情報に応じて取得される
（２）に記載の受信装置。
（６）
前記第１のアプリケーションは、前記コンテンツの予約を行う第３のアプリケーションの予約動作に応じて取得される
（１）又は（２）に記載の受信装置。
（７）
前記第３のアプリケーションは、前記第２のアプリケーションに遷移可能である
（６）に記載の受信装置。
（８）
前記第２のアプリケーションは、前記コンテンツの予約動作を行うことが可能である
（６）又は（７）に記載の受信装置。
（９）
前記第１のアプリケーション、前記第２のアプリケーション、及び、前記第３のアプリケーションは、所定のマークアップ言語により開発されたアプリケーションである
（６）乃至（８）のいずれか一項に記載の受信装置。
（１０）
受信装置のデータ処理方法において、
前記受信装置が、
デジタル放送信号を受信し、
前記デジタル放送信号に含まれる第１のアプリケーションであって、非リアルタイムで再生されるコンテンツのダウンロードを処理する前記第１のアプリケーションを取得し、
前記第１のアプリケーションの動作に応じて、前記デジタル放送信号に含まれるメタデータであって、前記コンテンツのダウンロードを制御するための情報を含む前記メタデータを取得し、
前記メタデータに基づいて、前記第１のアプリケーションの動作を制御して、前記デジタル放送信号に含まれる前記コンテンツのダウンロードを処理する
ステップを含むデータ処理方法。
（１１）
非リアルタイムで再生されるコンテンツのダウンロードを制御するための情報を含むメタデータを生成する第１の生成部と、
前記コンテンツのダウンロードを処理する第１のアプリケーションを生成する第２の生成部と、
前記メタデータ及び前記第１のアプリケーションを、デジタル放送信号に含めて送信する送信部と
を備える送信装置。
（１２）
前記メタデータは、
前記コンテンツに関する第１の情報と、
前記コンテンツを処理する第２のアプリケーションに関する第２の情報と、
前記デジタル放送信号に、前記コンテンツとともに、前記第２のアプリケーションが含まれるかどうかを示す第３の情報と
を少なくとも含む
（１１）に記載の送信装置。
（１３）
前記第２の情報は、
前記第３の情報が、前記第２のアプリケーションが含まれることを示している場合、前記コンテンツとともにダウンロードされる前記第２のアプリケーションに関する情報を含み、
前記第３の情報が、前記第２のアプリケーションが含まれないことを示している場合、前記コンテンツとは別に取得される他のアプリケーションに関する情報を含み、
前記送信部は、
前記第３の情報が、前記第２のアプリケーションが含まれることを示している場合、前記コンテンツとともに、前記第２のアプリケーションを送信し、
前記第３の情報が、前記第２のアプリケーションが含まれないことを示している場合、前記コンテンツのみを送信する
（１２）に記載の送信装置。
（１４）
前記第１のアプリケーションは、前記デジタル放送信号を受信する受信装置において、バックグラウンドで動作するアプリケーションである
（１１）乃至（１３）のいずれか一項に記載の送信装置。
（１５）
前記送信部は、
前記第１のアプリケーションの動作を制御するための第１の制御情報と、
前記第２のアプリケーションの動作を制御するための第２の制御情報と
を送信する
（１２）に記載の送信装置。
（１６）
前記送信部は、前記コンテンツの予約を行う第３のアプリケーションを送信する
（１３）に記載の送信装置。
（１７）
前記第１のアプリケーション、前記第２のアプリケーション、及び、前記第３のアプリケーションは、所定のマークアップ言語により開発されたアプリケーションである
（１６）に記載の送信装置。
（１８）
送信装置のデータ処理方法において、
前記送信装置が、
非リアルタイムで再生されるコンテンツのダウンロードを制御するための情報を含むメタデータを生成し、
前記コンテンツのダウンロードを処理する第１のアプリケーションを生成し、
前記メタデータ及び前記第１のアプリケーションを、デジタル放送信号に含めて送信する
ステップを含むデータ処理方法。

１ 伝送システム， １０ 送信装置， ２０ 受信装置， ３０ 伝送路， １０１ ビデオ取得部， １０２ ビデオエンコーダ， １０３ オーディオ取得部， １０４ オーディオエンコーダ， １０５ NRTコンポーネント生成部， １０６ NRTコンポーネント処理部， １０７ シグナリング生成部， １０８ シグナリング処理部， １０９ マルチプレクサ， １１０ 送信部， ２０１ 制御部， ２０２ メモリ， ２０３ 入力部， ２０４ 受信部， ２０５ デマルチプレクサ， ２０６ シグナリング処理部， ２０７ ビデオデコーダ， ２０８ ビデオ出力部， ２０９ オーディオデコーダ， ２１０ オーディオ出力部， ２１１ NRTコンポーネント処理部， ２１２ ストレージ， ２１３ 表示部， ２１４ スピーカ， ９００ コンピュータ， ９０１ CPU

Claims (18)

1. デジタル放送信号を受信する受信部と、
   前記デジタル放送信号に含まれる第１のアプリケーションであって、非リアルタイムで再生されるコンテンツのダウンロードを処理する前記第１のアプリケーションを取得する第１の取得部と、
   前記第１のアプリケーションの動作に応じて、前記デジタル放送信号に含まれるメタデータであって、前記コンテンツのダウンロードを制御するための情報を含む前記メタデータを取得する第２の取得部と、
   前記メタデータに基づいて、前記第１のアプリケーションの動作を制御して、前記デジタル放送信号に含まれる前記コンテンツのダウンロードを処理する制御部と
   を備える受信装置。
2. 前記メタデータは、
   前記コンテンツに関する第１の情報と、
   前記コンテンツを処理する第２のアプリケーションに関する第２の情報と、
   前記デジタル放送信号に、前記コンテンツとともに、前記第２のアプリケーションが含まれるかどうかを示す第３の情報と
   を少なくとも含む
   請求項１に記載の受信装置。
3. 前記第２の情報は、
   前記第３の情報が、前記第２のアプリケーションが含まれることを示している場合、前記コンテンツとともにダウンロードされる前記第２のアプリケーションに関する情報を含み、
   前記第３の情報が、前記第２のアプリケーションが含まれないことを示している場合、前記コンテンツとは別に取得される他のアプリケーションに関する情報を含む
   請求項２に記載の受信装置。
4. 前記第１のアプリケーションは、バックグラウンドで動作するアプリケーションである
   請求項１に記載の受信装置。
5. 前記第１のアプリケーションは、前記第１のアプリケーションを制御するための第１の制御情報に応じて取得され、
   前記第２のアプリケーションは、前記第２のアプリケーションを制御するための第２の制御情報に応じて取得される
   請求項２に記載の受信装置。
6. 前記第１のアプリケーションは、前記コンテンツの予約を行う第３のアプリケーションの予約動作に応じて取得される
   請求項２に記載の受信装置。
7. 前記第３のアプリケーションは、前記第２のアプリケーションに遷移可能である
   請求項６に記載の受信装置。
8. 前記第２のアプリケーションは、前記コンテンツの予約動作を行うことが可能である
   請求項６に記載の受信装置。
9. 前記第１のアプリケーション、前記第２のアプリケーション、及び、前記第３のアプリケーションは、所定のマークアップ言語により開発されたアプリケーションである
   請求項６に記載の受信装置。
10. 受信装置のデータ処理方法において、
    前記受信装置が、
    デジタル放送信号を受信し、
    前記デジタル放送信号に含まれる第１のアプリケーションであって、非リアルタイムで再生されるコンテンツのダウンロードを処理する前記第１のアプリケーションを取得し、
    前記第１のアプリケーションの動作に応じて、前記デジタル放送信号に含まれるメタデータであって、前記コンテンツのダウンロードを制御するための情報を含む前記メタデータを取得し、
    前記メタデータに基づいて、前記第１のアプリケーションの動作を制御して、前記デジタル放送信号に含まれる前記コンテンツのダウンロードを処理する
    ステップを含むデータ処理方法。
11. 非リアルタイムで再生されるコンテンツのダウンロードを制御するための情報を含むメタデータを生成する第１の生成部と、
    前記コンテンツのダウンロードを処理する第１のアプリケーションを生成する第２の生成部と、
    前記メタデータ及び前記第１のアプリケーションを、デジタル放送信号に含めて送信する送信部と
    を備える送信装置。
12. 前記メタデータは、
    前記コンテンツに関する第１の情報と、
    前記コンテンツを処理する第２のアプリケーションに関する第２の情報と、
    前記デジタル放送信号に、前記コンテンツとともに、前記第２のアプリケーションが含まれるかどうかを示す第３の情報と
    を少なくとも含む
    請求項１１に記載の送信装置。
13. 前記第２の情報は、
    前記第３の情報が、前記第２のアプリケーションが含まれることを示している場合、前記コンテンツとともにダウンロードされる前記第２のアプリケーションに関する情報を含み、
    前記第３の情報が、前記第２のアプリケーションが含まれないことを示している場合、前記コンテンツとは別に取得される他のアプリケーションに関する情報を含み、
    前記送信部は、
    前記第３の情報が、前記第２のアプリケーションが含まれることを示している場合、前記コンテンツとともに、前記第２のアプリケーションを送信し、
    前記第３の情報が、前記第２のアプリケーションが含まれないことを示している場合、前記コンテンツのみを送信する
    請求項１２に記載の送信装置。
14. 前記第１のアプリケーションは、前記デジタル放送信号を受信する受信装置において、バックグラウンドで動作するアプリケーションである
    請求項１１に記載の送信装置。
15. 前記送信部は、
    前記第１のアプリケーションの動作を制御するための第１の制御情報と、
    前記第２のアプリケーションの動作を制御するための第２の制御情報と
    を送信する
    請求項１２に記載の送信装置。
16. 前記送信部は、前記コンテンツの予約を行う第３のアプリケーションを送信する
    請求項１３に記載の送信装置。
17. 前記第１のアプリケーション、前記第２のアプリケーション、及び、前記第３のアプリケーションは、所定のマークアップ言語により開発されたアプリケーションである
    請求項１６に記載の送信装置。
18. 送信装置のデータ処理方法において、
    前記送信装置が、
    非リアルタイムで再生されるコンテンツのダウンロードを制御するための情報を含むメタデータを生成し、
    前記コンテンツのダウンロードを処理する第１のアプリケーションを生成し、
    前記メタデータ及び前記第１のアプリケーションを、デジタル放送信号に含めて送信する
    ステップを含むデータ処理方法。

Images