(57)【要約】  本技術は、コンテンツに付随するアプリケーションの動作を、より柔軟に制御することができるようにする受信装置、送信装置、及び、データ処理方法に関する。コンテンツに付随するアプリケーションが有効になる期間を示す有効期間情報は、期間に応じてアプリケーションの動作を制御する第１のモードと、エンドユーザの意志に応じてアプリケーションの動作を制御する第２のモードとのいずれかを指定可能であり、当該有効期間情報として、第２のモードが指定されている場合、エンドユーザの操作に応じて、アプリケーションの動作を制御する。本技術は、例えば、地上波放送を受信可能なテレビ受像機などに適用することができる。
2018021015.tif 000002
【特許請求の範囲】
【請求項１】
コンテンツを受信する受信部と、
前記コンテンツに付随するアプリケーションが有効になる期間を示す有効期間情報に基づいて、前記アプリケーションの動作を制御する制御部と
を備え、
前記有効期間情報は、前記期間に応じて前記アプリケーションの動作を制御する第１のモードと、エンドユーザの意志に応じて前記アプリケーションの動作を制御する第２のモードとのいずれかを指定可能であり、
前記制御部は、前記有効期間情報として、前記第２のモードが指定されている場合、前記エンドユーザの操作に応じて、前記アプリケーションの動作を制御する
受信装置。
【請求項２】
前記制御部は、前記有効期間情報に、
前記第１のモードが指定されている場合、前記期間内のみ、前記コンテンツに付随して、前記アプリケーションが起動されるようにし、
前記第２のモードが指定されている場合、前記エンドユーザの操作に応じて、前記アプリケーションが起動又は停止されるようにする
請求項１に記載の受信装置。
【請求項３】
前記アプリケーションは、１又は複数のファイルから構成され、
前記有効期間情報は、前記ファイルから得られる対象のページが有効となる期間の開始の時刻を示す第１の開始時刻情報と、前記ファイルから得られる対象のページが有効となる期間の終了の時刻を示す第１の終了時刻情報とからなる
請求項２に記載の受信装置。
【請求項４】
前記有効期間情報において、前記第１の開始時刻情報及び前記第１の終了時刻情報の少なくとも一方の時刻情報に対し、あらかじめ定められた特定のキーワードが指定された場合に、前記第２のモードが指定されたとみなされる
請求項３に記載の受信装置。
【請求項５】
前記制御部は、前記アプリケーションが取得可能になる期間を示す取得期間情報に基づいて、前記アプリケーションが取得されるようにする
請求項２に記載の受信装置。
【請求項６】
前記アプリケーションは、１又は複数のファイルから構成され、
前記取得期間情報は、前記ファイルの配信期間の開始の時刻を示す第２の開始時刻情報と、前記ファイルの配信期間の終了の時刻を示す第２の終了時刻情報とからなる
請求項５に記載の受信装置。
【請求項７】
前記制御部は、前記取得期間情報が存在しない場合、任意の期間に、前記アプリケーションが取得されるようにする
請求項５に記載の受信装置。
【請求項８】
前記有効期間情報と前記取得期間情報は、サービスごとに提供される、前記アプリケーションを制御するための制御情報に含まれ、
前記受信部は、前記コンテンツとともに送信される、前記制御情報を受信する
請求項５に記載の受信装置。
【請求項９】
１つの前記制御情報は、１つの前記アプリケーションを、１つの前記コンテンツに対して付随させるための情報である
請求項８に記載の受信装置。
【請求項１０】
受信装置のデータ処理方法において、
前記受信装置が、
コンテンツを受信し、
前記コンテンツに付随するアプリケーションが有効になる期間を示す有効期間情報に基づいて、前記アプリケーションの起動を制御する
ステップを含み、
前記有効期間情報は、前記期間に応じて前記アプリケーションの動作を制御する第１のモードと、エンドユーザの意志に応じて前記アプリケーションの動作を制御する第２のモードとのいずれかを指定可能であり、
前記有効期間情報として、前記第２のモードが指定されている場合、前記エンドユーザの操作に応じて、前記アプリケーションの動作を制御する
データ処理方法。
【請求項１１】
コンテンツに付随するアプリケーションが有効になる期間を示す有効期間情報であって、前記期間に応じて前記アプリケーションの動作を制御する第１のモードと、エンドユーザの意志に応じて前記アプリケーションの動作を制御する第２のモードとのいずれかを指定可能な前記有効期間情報を生成する生成部と、
前記コンテンツとともに、前記有効期間情報を送信する送信部と
を備える送信装置。
【請求項１２】
前記有効期間情報は、
前記第１のモードが指定されている場合、前記期間内のみ、前記コンテンツに付随して前記アプリケーションが起動されるようにするための情報であり、
前記第２のモードが指定されている場合、前記エンドユーザの操作に応じて、前記アプリケーションが起動又は停止されるようにするための情報となる
請求項１１に記載の送信装置。
【請求項１３】
前記アプリケーションは、１又は複数のファイルから構成され、
前記有効期間情報は、前記ファイルから得られる対象のページが有効となる期間の開始の時刻を示す第１の開始時刻情報と、前記ファイルから得られる対象のページが有効となる期間の終了の時刻を示す第１の終了時刻情報とからなる
請求項１２に記載の送信装置。
【請求項１４】
前記生成部は、前記第２のモードを指定する場合に、前記第１の開始時刻情報及び前記第１の終了時刻情報の少なくとも一方の時刻情報に対し、あらかじめ定められた特定のキーワードを指定する
請求項１３に記載の送信装置。
【請求項１５】
前記生成部は、前記アプリケーションが取得可能になる期間を示す取得期間情報を生成し、
前記送信部は、前記取得期間情報を送信する
請求項１２に記載の送信装置。
【請求項１６】
前記アプリケーションは、１又は複数のファイルから構成され、
前記取得期間情報は、前記ファイルの配信期間の開始の時刻を示す第２の開始時刻情報と、前記ファイルの配信期間の終了の時刻を示す第２の終了時刻情報とからなる
請求項１５に記載の送信装置。
【請求項１７】
前記生成部は、前記有効期間情報と前記取得期間情報を、サービスごとに提供される、前記アプリケーションを制御するための制御情報に含めて生成し、
前記送信部は、前記コンテンツとともに、前記制御情報を送信する
請求項１５に記載の送信装置。
【請求項１８】
前記生成部は、任意の期間に、前記アプリケーションが取得されるようにする場合、前記制御情報に、前記有効期間情報のみを含める
請求項１７に記載の送信装置。
【請求項１９】
１つの前記制御情報は、１つの前記アプリケーションを、１つの前記コンテンツに対して付随させるための情報である
請求項１７に記載の送信装置。
【請求項２０】
送信装置のデータ処理方法において、
前記送信装置が、
コンテンツに付随するアプリケーションが有効になる期間を示す有効期間情報であって、前記期間に応じて前記アプリケーションの動作を制御する第１のモードと、エンドユーザの意志に応じて前記アプリケーションの動作を制御する第２のモードとのいずれかを指定可能な前記有効期間情報を生成し、
前記コンテンツとともに、前記有効期間情報を送信する
ステップを含むデータ処理方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本技術は、受信装置、送信装置、及び、データ処理方法に関し、特に、コンテンツに付随するアプリケーションの動作を、より柔軟に制御することができるようにした受信装置、送信装置、及び、データ処理方法に関する。
【背景技術】
【０００２】
番組や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
【図１】
2018021015.tif 000003
【図２】
2018021015.tif 000004
【図３】
2018021015.tif 000005
【図４】
2018021015.tif 000006
【図５】
2018021015.tif 000007
【図６】
2018021015.tif 000008
【図７】
2018021015.tif 000009
【図８】
2018021015.tif 000010
【図９】
2018021015.tif 000011
【図１０】
2018021015.tif 000012
【図１１】
2018021015.tif 000013
【図１２】
2018021015.tif 000014
【図１３】
2018021015.tif 000015
【図１４】
2018021015.tif 000016
【国際調査報告】
2018021015.tif 000017
2018021015.tif 000018
2018021015.tif 000019
2018021015.tif 000020