(57)【要約】  本技術は、確実に、AVコンテンツに連動して実行されるアプリケーションの運用を行うことができるようにする受信装置、受信方法、送信装置、及び、送信方法に関する。AVコンテンツに連動して実行されるアプリケーションの動作を制御するための情報として、ロケーション情報を少なくとも含むトリガ情報を取得するトリガ情報取得部と、アプリケーションの動作を制御するためのアプリケーション制御情報を取得するメタデータ取得部と、トリガ情報、及び、アプリケーション制御情報に基づいて、アプリケーションの動作を制御するアプリケーション制御部とを備える受信装置が提供される。本技術は、例えば、テレビ受像機に適用することができる。
2016017451.tif 000002
【特許請求の範囲】
【請求項１】
AV（Audio Video）コンテンツに連動して実行されるアプリケーションの動作を制御するための情報として、ロケーション情報を少なくとも含むトリガ情報を取得する第１の取得部と、
前記アプリケーションの動作を制御するためのアプリケーション制御情報を取得する第２の取得部と、
前記トリガ情報、及び、前記アプリケーション制御情報に基づいて、前記アプリケーションの動作を制御する制御部と
を備える受信装置。
【請求項２】
前記トリガ情報は、前記アプリケーションの動作の制御を行う時刻の基準となる時刻情報を含み、
前記第２の取得部は、前記アプリケーションの動作を時系列で規定したスケジュール制御情報を取得し、
前記制御部は、前記時刻情報を基準に計時された時刻が、前記スケジュール制御情報に規定された時刻を経過したとき、当該時刻に対応した前記アプリケーションに対するアクション情報に応じて、前記アプリケーションの動作を制御する
請求項１に記載の受信装置。
【請求項３】
前記アプリケーションは、複数のファイルから構成されており、
前記第２の取得部は、前記アプリケーションを構成するファイル群のキャッシュを制御するためのキャッシュ制御情報を取得し、
前記制御部は、前記キャッシュ制御情報に基づいて、前記アプリケーションを構成するファイル群をキャッシュメモリに保持させる
請求項２に記載の受信装置。
【請求項４】
前記トリガ情報は、前記スケジュール制御情報に規定された内容を編集するための編集情報を含み、
前記制御部は、前記編集情報に基づいて、前記スケジュール制御情報を編集する
請求項３に記載の受信装置。
【請求項５】
前記ロケーション情報は、前記アプリケーション制御情報、前記スケジュール制御情報、及び、前記キャッシュ制御情報を取得するための情報であり、
前記アプリケーション制御情報、前記スケジュール制御情報、及び、前記キャッシュ制御情報は、前記アプリケーションの識別情報により関連付けられている
請求項４に記載の受信装置。
【請求項６】
前記トリガ情報は、前記アプリケーションに対するアクション情報を含み、
前記制御部は、前記トリガ情報が取得されたとき、当該トリガ情報に含まれる前記アクション情報に応じて、前記アプリケーションの動作を制御する
請求項１に記載の受信装置。
【請求項７】
前記アプリケーションは、複数のファイルから構成されており、
前記第２の取得部は、前記アプリケーションを構成するファイル群のキャッシュを制御するためのキャッシュ制御情報を取得し、
前記制御部は、前記キャッシュ制御情報に基づいて、前記アプリケーションを構成するファイル群をキャッシュメモリに保持させる
請求項６に記載の受信装置。
【請求項８】
前記ロケーション情報は、前記アプリケーション制御情報、及び、前記キャッシュ制御情報を取得するための情報であり、
前記トリガ情報、前記アプリケーション制御情報、及び、前記キャッシュ制御情報は、前記アプリケーションの識別情報により関連付けられている
請求項７に記載の受信装置。
【請求項９】
前記AVコンテンツは、デジタル放送信号で送信される放送コンテンツであり、
前記トリガ情報は、デジタル放送信号に含めて配信されるか、あるいはインターネット上のサーバから配信され、
前記第１の取得部は、放送又は通信で配信される前記トリガ情報を取得する
請求項１に記載の受信装置。
【請求項１０】
受信装置の受信方法において、
前記受信装置が、
AVコンテンツに連動して実行されるアプリケーションの動作を制御するための情報として、ロケーション情報を少なくとも含むトリガ情報を取得し、
前記アプリケーションの動作を制御するためのアプリケーション制御情報を取得し、
前記トリガ情報、及び、前記アプリケーション制御情報に基づいて、前記アプリケーションの動作を制御する
ステップを含む受信方法。
【請求項１１】
AVコンテンツを取得する取得部と、
前記AVコンテンツに連動して実行されるアプリケーションの動作を制御するための情報として、ロケーション情報を少なくとも含むトリガ情報を生成する第１の生成部と、
前記アプリケーションの動作を制御するためのアプリケーション制御情報を生成する取得する第２の第２の生成部と、
前記AVコンテンツとともに、前記トリガ情報、及び、アプリケーション制御情報を送信する送信部と
を備える送信装置。
【請求項１２】
前記第１の生成部は、前記アプリケーションの動作の制御を行う時刻の基準となる時刻情報を含む前記トリガ情報を生成し、
前記第２の生成部は、前記アプリケーションの動作を時系列で規定したスケジュール制御情報を生成し、
前記送信部は、前記時刻情報を含む前記トリガ情報、及び、前記スケジュール制御情報を送信する
請求項１１に記載の送信装置。
【請求項１３】
前記アプリケーションは、複数のファイルから構成されており、
前記第２の生成部は、前記アプリケーションを構成するファイル群のキャッシュを制御するためのキャッシュ制御情報を生成し、
前記送信部は、前記キャッシュ制御情報をさらに送信する
請求項１２に記載の送信装置。
【請求項１４】
前記第１の生成部は、前記スケジュール制御情報に規定された内容を編集するための編集情報を含む前記トリガ情報を生成し、
前記送信部は、前記編集情報を含む前記トリガ情報を送信する
請求項１３に記載の送信装置。
【請求項１５】
前記ロケーション情報は、前記アプリケーション制御情報、前記スケジュール制御情報、及び、前記キャッシュ制御情報を取得するための情報であり、
前記アプリケーション制御情報、前記スケジュール制御情報、及び、前記キャッシュ制御情報は、前記アプリケーションの識別情報により関連付けられている
請求項１４に記載の送信装置。
【請求項１６】
前記第１の生成部は、前記アプリケーションに対するアクション情報を含む前記トリガ情報を生成し、
前記送信部は、前記アクション情報を含む前記トリガ情報を送信する
請求項１１に記載の送信装置。
【請求項１７】
前記アプリケーションは、複数のファイルから構成されており、
前記第２の生成部は、前記アプリケーションを構成するファイル群のキャッシュを制御するためのキャッシュ制御情報を生成し、
前記送信部は、前記キャッシュ制御情報をさらに送信する
請求項１６に記載の送信装置。
【請求項１８】
前記ロケーション情報は、前記アプリケーション制御情報、及び、前記キャッシュ制御情報を取得するための情報であり、
前記トリガ情報、前記アプリケーション制御情報、及び、前記キャッシュ制御情報は、前記アプリケーションの識別情報により関連付けられている
請求項１７に記載の送信装置。
【請求項１９】
前記AVコンテンツは、放送コンテンツであり、
前記送信部は、前記AVコンテンツとともに、前記トリガ情報、及び、アプリケーション制御情報を、デジタル放送信号で送信する
請求項１１に記載の送信装置。
【請求項２０】
送信装置の送信方法において、
前記送信装置が、
AVコンテンツを取得し、
前記AVコンテンツに連動して実行されるアプリケーションの動作を制御するための情報として、ロケーション情報を少なくとも含むトリガ情報を生成し、
前記アプリケーションの動作を制御するためのアプリケーション制御情報を生成する取得し、
前記AVコンテンツとともに、前記トリガ情報、及び、アプリケーション制御情報を送信する
ステップを含む送信方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本技術は、受信装置、受信方法、送信装置、及び、送信方法に関し、特に、確実に、AVコンテンツに連動して実行されるアプリケーションの運用を行うことができるようにした受信装置、受信方法、送信装置、及び、送信方法に関する。
【背景技術】
【０００２】
地上波放送で放送された番組等のAV（Audio Video）コンテンツを、ケーブルテレビ（CATV：Cable Television）や衛星放送により再配信する運用が行われている（例えば、特許文献１参照）。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２００１−１３６４４４号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
ところで、地上波放送で放送された番組等のAVコンテンツが、ケーブルテレビ等で再配信される場合に、当該AVコンテンツと連動して実行されるアプリケーションの制御など、地上波放送において規定された仕組みが、ケーブルテレビ等の再配信において維持することができない場合がある。この場合に、受信機では、番組等のAVコンテンツに連動して実行されるアプリケーションを動作させることができないため、確実に、当該アプリケーションを運用するための技術が要求されていた。【０００５】
本技術はこのような状況に鑑みてなされたものであり、確実に、AVコンテンツに連動して実行されるアプリケーションの運用を行うことができるようにするものである。
【課題を解決するための手段】
【０００６】
本技術の第１の側面の受信装置は、AV（Audio Video）コンテンツに連動して実行されるアプリケーションの動作を制御するための情報として、ロケーション情報を少なくとも含むトリガ情報を取得する第１の取得部と、前記アプリケーションの動作を制御するためのアプリケーション制御情報を取得する第２の取得部と、前記トリガ情報、及び、前記アプリケーション制御情報に基づいて、前記アプリケーションの動作を制御する制御部とを備える受信装置である。【０００７】
前記トリガ情報は、前記アプリケーションの動作の制御を行う時刻の基準となる時刻情報を含み、前記第２の取得部は、前記アプリケーションの動作を時系列で規定したスケジュール制御情報を取得し、前記制御部は、前記時刻情報を基準に計時された時刻が、前記スケジュール制御情報に規定された時刻を経過したとき、当該時刻に対応した前記アプリケーションに対するアクション情報に応じて、前記アプリケーションの動作を制御するようにすることができる。【０００８】
前記アプリケーションは、複数のファイルから構成されており、前記第２の取得部は、前記アプリケーションを構成するファイル群のキャッシュを制御するためのキャッシュ制御情報を取得し、前記制御部は、前記キャッシュ制御情報に基づいて、前記アプリケーションを構成するファイル群をキャッシュメモリに保持させるようにすることができる。【０００９】
前記トリガ情報は、前記スケジュール制御情報に規定された内容を編集するための編集情報を含み、前記制御部は、前記編集情報に基づいて、前記スケジュール制御情報を編集するようにすることができる。【００１０】
前記ロケーション情報は、前記アプリケーション制御情報、前記スケジュール制御情報、及び、前記キャッシュ制御情報を取得するための情報であり、前記アプリケーション制御情報、前記スケジュール制御情報、及び、前記キャッシュ制御情報は、前記アプリケーションの識別情報により関連付けられているようにすることができる。【００１１】
前記トリガ情報は、前記アプリケーションに対するアクション情報を含み、前記制御部は、前記トリガ情報が取得されたとき、当該トリガ情報に含まれる前記アクション情報に応じて、前記アプリケーションの動作を制御するようにすることができる。【００１２】
前記アプリケーションは、複数のファイルから構成されており、前記第２の取得部は、前記アプリケーションを構成するファイル群のキャッシュを制御するためのキャッシュ制御情報を取得し、前記制御部は、前記キャッシュ制御情報に基づいて、前記アプリケーションを構成するファイル群をキャッシュメモリに保持させるようにすることができる。【００１３】
前記ロケーション情報は、前記アプリケーション制御情報、及び、前記キャッシュ制御情報を取得するための情報であり、前記トリガ情報、前記アプリケーション制御情報、及び、前記キャッシュ制御情報は、前記アプリケーションの識別情報により関連付けられているようにすることができる。【００１４】
前記AVコンテンツは、デジタル放送信号で送信される放送コンテンツであり、前記トリガ情報は、デジタル放送信号に含めて配信されるか、あるいはインターネット上のサーバから配信され、前記第１の取得部は、放送又は通信で配信される前記トリガ情報を取得するようにすることができる。【００１５】
本技術の第１の側面の受信装置は、独立した装置であってもよいし、１つの装置を構成している内部ブロックであってもよい。また、本技術の第１の側面の受信方法は、上述した本技術の第１の側面の受信装置に対応する受信方法である。【００１６】
本技術の第１の側面の受信装置、及び、受信方法においては、AVコンテンツに連動して実行されるアプリケーションの動作を制御するための情報として、ロケーション情報を少なくとも含むトリガ情報が取得され、前記アプリケーションの動作を制御するためのアプリケーション制御情報が取得され、前記トリガ情報、及び、前記アプリケーション制御情報に基づいて、前記アプリケーションの動作が制御される。【００１７】
本技術の第２の側面の送信装置は、AVコンテンツを取得する取得部と、前記AVコンテンツに連動して実行されるアプリケーションの動作を制御するための情報として、ロケーション情報を少なくとも含むトリガ情報を生成する第１の生成部と、前記アプリケーションの動作を制御するためのアプリケーション制御情報を生成する取得する第２の第２の生成部と、前記AVコンテンツとともに、前記トリガ情報、及び、アプリケーション制御情報を送信する送信部とを備える送信装置である。【００１８】
前記第１の生成部は、前記アプリケーションの動作の制御を行う時刻の基準となる時刻情報を含む前記トリガ情報を生成し、前記第２の生成部は、前記アプリケーションの動作を時系列で規定したスケジュール制御情報を生成し、前記送信部は、前記時刻情報を含む前記トリガ情報、及び、前記スケジュール制御情報を送信するようにすることができる。【００１９】
前記アプリケーションは、複数のファイルから構成されており、前記第２の生成部は、前記アプリケーションを構成するファイル群のキャッシュを制御するためのキャッシュ制御情報を生成し、前記送信部は、前記キャッシュ制御情報をさらに送信するようにすることができる。【００２０】
前記第１の生成部は、前記スケジュール制御情報に規定された内容を編集するための編集情報を含む前記トリガ情報を生成し、前記送信部は、前記編集情報を含む前記トリガ情報を送信するようにすることができる。【００２１】
前記ロケーション情報は、前記アプリケーション制御情報、前記スケジュール制御情報、及び、前記キャッシュ制御情報を取得するための情報であり、前記アプリケーション制御情報、前記スケジュール制御情報、及び、前記キャッシュ制御情報は、前記アプリケーションの識別情報により関連付けられているようにすることができる。【００２２】
前記第１の生成部は、前記アプリケーションに対するアクション情報を含む前記トリガ情報を生成し、前記送信部は、前記アクション情報を含む前記トリガ情報を送信するようにすることができる。【００２３】
前記アプリケーションは、複数のファイルから構成されており、前記第２の生成部は、前記アプリケーションを構成するファイル群のキャッシュを制御するためのキャッシュ制御情報を生成し、前記送信部は、前記キャッシュ制御情報をさらに送信するようにすることができる。【００２４】
前記ロケーション情報は、前記アプリケーション制御情報、及び、前記キャッシュ制御情報を取得するための情報であり、前記トリガ情報、前記アプリケーション制御情報、及び、前記キャッシュ制御情報は、前記アプリケーションの識別情報により関連付けられているようにすることができる。【００２５】
前記AVコンテンツは、放送コンテンツであり、前記送信部は、前記AVコンテンツとともに、前記トリガ情報、及び、アプリケーション制御情報を、デジタル放送信号で送信するようにすることができる。【００２６】
本技術の第２の側面の送信装置は、独立した装置であってもよいし、１つの装置を構成している内部ブロックであってもよい。また、本技術の第２の側面の送信方法は、上述した本技術の第２の側面の送信装置に対応する送信方法である。【００２７】
本技術の第２の側面の送信装置、及び、送信方法においては、AVコンテンツが取得され、前記AVコンテンツに連動して実行されるアプリケーションの動作を制御するための情報として、ロケーション情報を少なくとも含むトリガ情報が生成され、前記アプリケーションの動作を制御するためのアプリケーション制御情報が生成され、前記AVコンテンツとともに、前記トリガ情報、及び、アプリケーション制御情報が送信される。
【発明の効果】
【００２８】
本技術の第１の側面、及び、第２の側面によれば、確実に、AVコンテンツに連動して実行されるアプリケーションの運用を行うことができる。【００２９】
なお、ここに記載された効果は必ずしも限定されるものではなく、本開示中に記載されたいずれかの効果であってもよい。
【図面の簡単な説明】
【００３０】
【図１】トリガ情報の構成を示す図である。
【図２】アクション情報の記述方法を示す図である。
【図３】イベント情報の記述方法を示す図である。
【図４】トリガ情報の記述例を示す図である。
【図５】AITのシンタックスの例を示す図である。
【図６】EMTのシンタックスの例を示す図である。
【図７】CCTの概要を説明する図である。
【図８】CCTの概要を説明する図である。
【図９】CCTのシンタックスの例を示す図である。
【図１０】IP伝送方式のデジタル放送のシステムパイプモデルを示す図である。
【図１１】ユースケース１を説明する図である。
【図１２】ユースケース１を説明する図である。
【図１３】ユースケース１における各データの対応関係を示す図である。
【図１４】ユースケース２を説明する図である。
【図１５】ユースケース２を説明する図である。
【図１６】ユースケース２における各データの対応関係を示す図である。
【図１７】ユースケース３を説明する図である。
【図１８】ユースケース３を説明する図である。
【図１９】ユースケース４を説明する図である。
【図２０】ユースケース４における各データの対応関係を示す図である。
【図２１】ユースケース５を説明する図である。
【図２２】ユースケース５における各データの対応関係を示す図である。
【図２３】ユースケース６を説明する図である。
【図２４】放送通信システムの構成例を示す図である。
【図２５】送信装置の構成例を示す図である。
【図２６】受信装置の構成例を示す図である。
【図２７】制御部の構成例を示す図である。
【図２８】各サーバの構成例を示す図である。
【図２９】デジタル放送信号送信処理の流れを説明するフローチャートである。
【図３０】デジタル放送信号受信処理の流れを説明するフローチャートである。
【図３１】収録済み番組に連動したアプリケーション制御処理の流れを説明するフローチャートである。
【図３２】ライブ番組に連動したアプリケーション制御処理の流れを説明するフローチャートである。
【図３３】ハイブリッド型のアプリケーション制御処理の流れを説明するフローチャートである。
【図３４】アプリケーション配信処理の流れを説明するフローチャートである。
【図３５】メタデータ配信処理の流れを説明するフローチャートである。
【図３６】トリガ情報配信処理の流れを説明するフローチャートである。
【図３７】コンピュータの構成例を示す図である。
【発明を実施するための形態】
【００３１】
以下、図面を参照しながら本技術の実施の形態について説明する。なお、説明は以下の順序で行うものとする。
【００３２】
１．アプリケーション制御の概要
２．IP伝送方式によるデジタル放送の概要
３．具体的なユースケース
（１）ユースケース１：収録済み番組に連動したアプリケーションの制御
（２）ユースケース２：ライブ番組に連動したアプリケーションの制御
（３）ユースケース３：ハイブリッド型のアプリケーションの制御
（４）ユースケース４：収録済み番組に連動したアプリケーションの制御（ACR対応）
（５）ユースケース５：ライブ番組に連動したアプリケーションの制御（ACR対応）
（６）ユースケース６：SCSシグナリング情報を用いたアプリケーションの制御
４．システムの構成
５．各装置で実行される処理の流れ
６．コンピュータの構成
【００３３】
＜１．アプリケーション制御の概要＞
【００３４】
まず、本技術を適用したアプリケーション制御の概要を説明する。
【００３５】
本技術を適用したアプリケーション制御では、トリガ情報、及び、メタデータを用いて、番組等のAVコンテンツに連動して実行されるアプリケーションの動作が制御される。
【００３６】
トリガ情報は、アプリケーションの動作を制御するための情報として、ロケーション情報を少なくとも含んでいる。メタデータは、AIT（Application Information Table）、EMT（Event Message Table）、及び、CCT（Content Configuration Table）から構成される。
【００３７】
AITは、アプリケーションの動作を制御するためのアプリケーション制御情報である。EMTは、アプリケーションの動作を時系列で規定したスケジュール制御情報である。CCTは、アプリケーションを構成するファイル群のキャッシュを制御するためのキャッシュ制御情報である。以下、トリガ情報と、メタデータの詳細な構成を説明する。
【００３８】
（トリガ情報の詳細な構成）
図１は、トリガ情報の構成を示す図である。
【００３９】
トリガ情報は、トリガ情報の種類を示すコマンドID（cmdID）と、トリガ情報本体であるロケーション情報としてのURI（Uniform Resource Identifier）が記述される構造となる。コマンドIDには、本技術に関連するアプリケーション制御にトリガ情報を適用する場合には、例えば、"0"が指定される。図１において、locator_partが、URIに相当し、タームス（terms）をオプションで指定することができる。なお、図１においては、コマンドIDは省略してある。
【００４０】
タームスには、アクション情報（action）、メディアタイム情報（media_time）、又はイベント情報（event）が指定される。アクション情報には、アプリケーションに対する各種のアクションが指定される。メディアタイム情報には、アプリケーションの動作の制御を行う基準となる時刻（例えば現在の時刻）を示す情報（時刻情報）が指定される。イベント情報には、EMTに規定された内容を編集するための情報（編集情報）が指定される。
【００４１】
また、タームスには、オプションとして、スプレッド情報（spread）、バージョン情報（version）、又はその他（others）のパラメータを指定することができる。スプレッド情報には、アプリケーションに関する動作を確率的に分散させるための情報が指定される。バージョン情報としては、AIT、EMT、CCTのバージョン情報が指定される。なお、これらのパラメータは、"&"により連結されることになる。
【００４２】
ここで、図２に示すように、図１のタームスに指定されるアクション情報は、アプリケーションID（appID）と、アクションコード（action_code）が、ピリオドにより連結されている。アプリケーションIDには、対象のアプリケーションの識別情報が指定される。
【００４３】
アクションコードには、アプリケーションIDにより識別されるアプリケーションに実行させるアクションが指定される。例えば、アクションコードには、"a1"〜"a4"や、"e1"〜"eN"（Nは１以上の整数）等のコードが指定される。
【００４４】
プリフェッチ（Prefetch）は、アプリケーションの取得を指示するためのアクションである。プリフェッチのアクションコードは、"a1"とされる。なお、プリフェッチは、プリペア（Prepare）と称される場合があるが、ここでは、プリフェッチに統一して説明する。
【００４５】
エクスキュート（Execute（Exec））は、アプリケーションの取得又は起動を指示するためのアクションである。なお、対象のアプリケーションが休止している場合には、そのアプリケーションの実行を再開させる。エクスキュートのアクションコードは、"a2"とされる。
【００４６】
キル（Kill）は、実行中のアプリケーションを終了させるためのアクションである。キルのアクションコードは、"a3"とされる。
【００４７】
サスペンド（Suspend）は、実行中のアプリケーションを中断して、休止させるためのアクションである。サスペンドのアクションコードは、"a4"とされる。
【００４８】
また、アクションコードには、イベントID（ストリームイベントID）として、"e1"〜"eN"（Nは１以上の整数）が指定される。アクションコードとして、ストリームイベントIDが指定された場合、当該ストリームイベントに付随するデータが、イベントデータ（event_data）に指定される。すなわち、イベントデータは、ストリームイベントに応じたオプショナルな値となる。ストリームイベントIDを指定することで、実行中のアプリケーションに対して、イベントを発火させる（所定のスクリプトを実行させる）ことができる。
【００４９】
なお、複数のアクション情報を同時に記述する場合には、アプリケーションID（appID）、アクションコード（action_code）、オプショナルなイベントデータ（event_data）を繰り返して記述することになる。また、イベントタイム（event_time）には、アプリケーションに対するアクションを実行する時刻が指定される。トリガ情報を取得後、直ちに実行する場合には、イベントタイムを指定する必要はない。
【００５０】
また、図３に示すように、図１のタームスに指定されるイベント情報は、イベントID（eventID）と、エディットコード（edit_code）がピリオドにより連結されている。イベントIDには、EMTに時系列で規定されるイベントのうち、対象のイベントの識別情報が指定される。
【００５１】
エディットコードには、イベントIDにより識別されるイベントを編集するための情報（編集情報）が指定される。この編集情報としては、削除（delete）又は更新（update）が指定される。ただし、更新の場合には、イベントタイム（event_time）に更新後の時刻を示す情報が指定される。なお、削除のエディットコードは"1"とされ、更新のエディットコードは"2"とされる。
【００５２】
（トリガ情報の記述例）
図４は、トリガ情報の記述例を示す図である。
【００５３】
図４において、１行目の「xbc.tv/e12」は、タームスが指定されていない場合のトリガ情報を示している。メタデータ（AIT、EMT、CCT）が通信で配信されている場合には、当該トリガ情報の先頭に、"http://"を付加したURL（Uniform Resource Locator）に従い、インターネット上のサーバに接続することで、当該メタデータのファイルが取得される。また、メタデータ（AIT、EMT、CCT）が放送で配信されている場合には、当該トリガ情報から得られるURLに従い、FLUTE（File Delivery over Unidirectional Transport）セッションで伝送されているSCS（Service Channel Signaling）ストリームに接続することで、当該メタデータのファイルが取得される。
【００５４】
２行目の「xbc.tv/e12?m=5a33」は、タームスとして、メディアタイム情報（m：media_time）が指定されている場合のトリガ情報を示している。"m=5a33"によって、当該トリガ情報を受信した時刻が指定されている。
【００５５】
３行目の「xbc.tv/e12?a=42a8.a2」は、タームスとして、アクション情報（a：action）が指定されている場合のトリガ情報を示している。"a=42a8.a2"によって、"42a8"であるアプリケーションIDと、"a2"であるアクションコードが指定されている。すなわち、当該トリガ情報は、"42a8"であるアプリケーションIDのアプリケーションに対するエクスキュートアクションを指定している。
【００５６】
４行目の「xbx.tv/e12?a=42a8.a4&a=4314.a2」は、タームスとして、複数のアクションが指定されている場合のトリガ情報を示している。すなわち、当該トリガ情報は、"42a8"であるアプリケーションIDのアプリケーションに対するサスペンドアクションと、"4314"であるアプリケーションIDのアプリケーションに対するエクスキュートアクションを指定している。
【００５７】
５行目の「xbc.tv/e12?a=42a8.e1.1762&t=77ee」は、タームスとして、イベント発火のアクションが指定されている場合のトリガ情報を示している。すなわち、当該トリガ情報は、"42a8"であるアプリケーションIDのアプリケーションに対する、"e1"であるイベント（ストリームイベント）を指定している。ただし、当該イベントは、"77ee"である時刻に実行され、イベント発火の際には"1762"であるデータが使用されることになる。
【００５８】
６行目の「xbc.tv/e12?e=12.1」は、タームスとして、イベントが指定されている場合のトリガ情報を示している。すなわち、当該トリガ情報は、EMTに時系列で規定されているイベントのうち、"12"であるイベントIDのイベントを削除することを指定している。
【００５９】
７行目の「xbc.tv/e12?e=12.2&t=77ee」は、タームスとして、イベントが指定されている場合のトリガ情報を示している。すなわち、当該トリガ情報は、EMTに時系列で規定されているイベントのうち、"12"であるイベントIDのイベントの時刻を、"77ee"である時刻に更新することを指定している。
【００６０】
（メタデータの詳細な構成）
【００６１】
（AITの詳細な構成）
図５は、AITのシンタックスの例を示す図である。
【００６２】
AITは、例えばXML（Extensible Markup Language）等のマークアップ言語により記述される。なお、図５において、要素と属性のうち、属性には「@」が付されている。また、インデントされた要素と属性は、その上位の要素に対して指定されたものとなる。これらの関係は、後述する他のシンタックスでも同様とされる。
【００６３】
図５において、ServiceDiscovery要素におけるApplicationDiscovery要素は、DomainName属性とApplicationList要素の上位要素とされる。DomainName属性は、ドメインの名称が指定される。ApplicationList要素は、Application要素の上位要素であって、１又は複数のApplication要素を、リストとして記述する。
【００６４】
Application要素には、アプリケーションに関する情報が指定される。Application要素は、appName要素、applicationIdentifier要素、applicationDescriptor要素、applicationTransport要素、applicationLocation要素、application Boundary要素の上位要素とされる。
【００６５】
appName要素には、アプリケーションの名称が指定される。
【００６６】
applicationIdentifier要素は、アプリケーションの識別情報に関する情報が指定される。applicationIdentifier要素は、orgId要素とappId要素の上位要素とされる。orgId要素には、オーガニゼーションIDが指定される。appId要素には、アプリケーションIDが指定される。このアプリケーションIDが、図２のトリガ情報のアプリケーションIDに対応している。
【００６７】
applicationDescriptor要素は、type要素、controlCode要素、serviceBound要素、priority要素、及びicon要素の上位要素とされる。type要素には、アプリケーションに関するタイプ情報が指定される。
【００６８】
controlCode要素には、アプリケーションに実行させるアクションが指定される。このアクション情報としては、例えば、オートスタート、プレゼント、キル、又はプリフェッチが指定される。
【００６９】
オートスタート（AUTO START）は、アプリケーションの自動実行を指示するためのアクションである。一方、プレゼント（PRESENT）は、アプリケーションを自動実行しないことを意味する。キル（KILL）は、実行中のアプリケーションを終了させるためのアクションである。プリフェッチ（PREFETCH）は、アプリケーションの取得を指示するためのアクションである。なお、当該アクション情報として、上述したトリガ情報で規定されたアクション情報を用いるようにしてもよい。
【００７０】
serviceBound要素には、サービスに依存したアプリケーションかどうかを示す情報が指定される。priority要素には、複数のアプリケーションが存在する場合の優先度を示す情報が指定される。icon要素には、アプリケーションで使用されるアイコンの取得先やサイズが指定される。
【００７１】
applicationTransport要素は、type属性、URLBase要素、及び、URLExtension要素の上位要素とされる。Type属性には、アプリケーションの伝送に関するタイプ情報が指定される。また、URLBase要素、URLExtension要素、及び、applicationLocation要素により、アプリケーションの取得先のURL（アプリケーションURL）が指定される。application Boundary要素には、アプリケーションが動作する範囲を示すドメインが指定される。
【００７２】
なお、図５において、出現数（Cardinality）であるが、"1"が指定された場合にはその要素又は属性は必ず１つだけ指定され、"0..1"が指定された場合には、その要素又は属性を指定するかどうかは任意である。また、"1..N"が指定された場合には、その要素又は属性は１以上指定され、"0..N"が指定された場合には、その要素又は属性を１以上指定するかどうかは任意である。これらの出現数の意味は、後述する他のシンタックスでも同様とされる。
【００７３】
（EMTの詳細な構成）
図６は、EMTのシンタックスの例を示す図である。なお、EMTは、例えばXML等のマークアップ言語により記述される。
【００７４】
EMT要素は、majorProtocolversion属性、minorProtocolVersion属性、id属性、EMTVersion属性、beginMT属性、LiveTrigger要素、及び、Event要素の上位要素とされる。
【００７５】
majorProtocolversion属性と、minorProtocolVersion属性には、シンタックスのバージョン情報が指定される。id属性には、EMTを識別するための識別情報が指定される。例えば、id属性には、domain_nameと、program_id（segment_id）とを、"/"により連結した文字列が指定される。EMTVersion属性には、EMTのバージョン情報が指定される。beginMT属性には、EMTに対応するメディアタイムが開始する時刻を示す情報が指定される。
【００７６】
LiveTrigger要素には、トリガ情報がインターネット上のサーバから伝送される場合のトリガ情報（ライブトリガ情報）に関する情報が記述される。LiveTrigger要素は、URL属性とpollPeriod属性が指定される。URL属性には、ライブトリガ情報を提供するサーバに接続するためのURLが指定される。pollPeriod属性には、サーバからライブトリガ情報を取得する際のポーリング周期が指定される。
【００７７】
Event要素には、イベント情報が、時系列で規定される。Event要素は、id属性、appID属性、action属性、startTime属性、endTime属性、及び、Data要素の上位要素とされる。id属性には、イベントIDが指定される。appID属性には、アプリケーションIDが指定される。
【００７８】
action属性には、アプリケーションに実行させるアクションが指定される。このアクション情報としては、プリフェッチ、エクスキュート、サスペンド、キル、又はインジェクトイベントが指定される。
【００７９】
プリフェッチ（Prefetch）は、アプリケーションの取得を指示するためのアクションである。なお、上述したように、プリフェッチは、プリペア（Prepare）と称される場合がある。
【００８０】
エクスキュート（Execute）は、アプリケーションの取得又は起動を指示するためのアクションである。なお、対象のアプリケーションが休止している場合には、そのアプリケーションの実行を再開させる。
【００８１】
サスペンド（Suspend）は、実行中のアプリケーションを中断して、休止させるためのアクションである。キル（Kill）は、実行中のアプリケーションを終了させるためのアクションである。インジェクトイベント（Inject Event）は、ストリームイベントとしてイベントを発火させるためのアクションである。
【００８２】
startTime属性には、アプリケーションに対するアクションの有効期間の開始時刻を示す情報が指定される。endTime属性には、アプリケーションに対するアクションの有効期間の終了時刻を示す情報が指定される。
【００８３】
すなわち、アプリケーションに対するアクションの有効期間は、対応するAVコンテンツの進行時間軸上の２点を示すstartTime属性及びendTime属性により定められる。そして、例えば、受信機の内部時計（メディアタイム情報）により計時されるAVコンテンツの進行タイミングが、startTime属性の示す有効開始時刻を経過したとき、その有効開始時刻に対応するアクションが有効とされる。この場合、endTime属性を指定せずに、startTime属性のみが指定されるようにしてもよい。
【００８４】
また、受信機の内部時計により計時されるAVコンテンツの進行タイミングが、有効期間内であるときに、その有効期間に対応するアクションが有効とされ、AVコンテンツの進行タイミングが有効期間に達していない、又はそれを過ぎたときは、その有効期間に対応するアクションが無効とされるようにしてもよい。すなわち、受信機では、内部時計（メディアタイム情報）により計時される時刻が、有効期間等に基づいた所定の有効条件を満たしたときに、その有効期間に対応するアクションが有効とされる。
【００８５】
Data要素は、アクション情報として、インジェクトイベントが指定された場合に、当該イベントで使用されるデータが指定される。当該データを識別するためのデータIDが、Data要素の子要素のdataID属性により指定される。
【００８６】
（CCTの詳細な構成）
図７は、CCTの概要を説明する図である。
【００８７】
図７は、"a1"であるアプリケーションIDを有するアプリケーションの構造を示している。アプリケーションは、HTML（HyperText Markup Language）ファイルやJPEG（Joint Photographic Experts Group）ファイル等の複数のファイルから構成されている。図７においては、HTMLファイルを、「An」で表し、JPEGファイル等のHTMLファイルから参照されるリソースファイルを、「Bn」で表している。なお、「An」と「Bn」において、「n」には、各ファイルを識別するための数字が指定される。
【００８８】
また、トップページのHTMLファイルA11は、HTMLファイルA01、及び、HTMLファイルA12とリンクされている。また、HTMLファイルA01は、HTMLファイルA02とリンクされ、HTMLファイルA02はさらに、HTMLファイルA03とリンクされている。
【００８９】
ここで、アプリケーションを構成する複数のファイルを、提示される単位（すなわち、ページ単位、以下、「PU（Presentation Unit）」という）で、グループ分けすれば、トップページとなるHTMLファイルA11では、リソースファイルB02、B11、B14を参照しているので、これらの４つのファイルを、１つの集まりとして、PU_ID=1を付与するものとする。
【００９０】
同様に、HTMLファイルA12は、リソースファイルB07、B09、B12、B13を参照しているので、これらの５つのファイルを、PU_ID=2の集合とすることができる。また、HTMLファイルA01は、リソースファイルB01、B03、B04を参照しているので、これらの４つのファイルを、PU_ID=3の集合とすることができる。さらに、HTMLファイルA02は、リソースファイルB05、B06を参照しているので、これらの３つのファイルを、PU_ID=4の集合とすることができる。HTMLファイルA03は、リソースファイルB05、B08を参照しているので、これらの３つのファイルを、PU_ID=5の集合とすることができる。
【００９１】
以上のように、"a1"であるアプリケーションIDを有するアプリケーションを構成するファイル群は、PU_ID=1〜5で識別される集合ごとに、PU単位で、複数のグループに分けることができる。
【００９２】
ところで、受信機では、アプリケーションを構成するファイル群を、キャッシュメモリに保持することで、アプリケーションに関する処理を高速化することができるが、キャッシュメモリに保持できるファイルは、キャッシュメモリの容量などに応じて限られる。そこで、CCTとして、アプリケーションを構成するファイル群のキャッシュを制御するためのキャッシュ制御情報を提供することで、受信機が、キャッシュメモリの容量などに応じて、ファイルをキャッシュメモリに保持できるようにする。
【００９３】
例えば、図８に示すように、受信機が、最小限のファイル群しかキャッシュメモリに保持できない場合（図中左側の「Minimum Cache」）、提示されているHTMLファイルとそのリソースファイルのみがキャッシュメモリに保持されるようにする。具体的には、トップページのHTMLファイルA11が提示されている場合には、PU_ID=1に属するファイル群のみが、キャッシュメモリに保持される。また、HTMLファイルA11からHTMLファイルA01に遷移した場合には、PU_ID=3に属するファイル群のみが、キャッシュメモリに保持される。
【００９４】
また、例えば、受信機が、最小限のファイル群よりも多い、中間のファイル群をキャッシュメモリに保持できる場合（図中中央の「Medium Cache」）、提示されているHTMLファイルとそのリソースファイルのみならず、その周辺のファイル群もキャッシュメモリに保持されるようにする。具体的には、トップページのHTMLファイルA11が提示されている場合には、PU_ID=1に属するファイル群のみならず、そのリンク先となるPU_ID=2、3に属するファイル群もキャッシュメモリに保持される。また、HTMLファイルA11からHTMLファイルA01に遷移した場合には、PU_ID=3に属するファイル群のみならず、そのリンク先となるPU_ID=4、5に属するファイル群もキャッシュメモリに保持される。
【００９５】
また、例えば、受信機が、最大限のファイル群をキャッシュメモリに保持できる場合（図中右側の「Maximum Cache」）、提示されているHTMLファイルとそのリソースファイルのみならず、アプリケーションを構成するすべてのファイル群が、キャッシュメモリに保持されるようにする。具体的には、トップページのHTMLファイルA11が提示されている場合には、PU_ID=1に属するファイル群のみならず、PU_ID=2〜5に属するファイル群もキャッシュメモリに保持される。また、HTMLファイルA11からHTMLファイルA01に遷移した場合には、PU_ID=3に属するファイル群のみならず、PU_ID=1、2、4、5に属するファイル群もキャッシュメモリに保持される。
【００９６】
このように、キャッシュ制御情報としてのCCTを提供することで、受信機では、キャッシュメモリの容量などに応じて、適応的に、ファイルをキャッシュメモリに保持することができるようになる。特に、放送で配信されるファイルは、周期的に配信されているため、所望のファイルを取り損ねると、数十秒後や数分後でないと当該ファイルを取得できないケースも想定されるので、受信機側で、適切にファイルをキャッシュメモリに保持できるようにして、このようなケースを回避できるようにしている。
【００９７】
図９は、CCTのシンタックスの例を示す図である。なお、CCTは、例えばXML等のマークアップ言語により記述される。
【００９８】
CCT要素は、majorProtocolversion属性、minorProtocolVersion属性、CCTVersion属性、baseURI属性、及び、Application要素の上位要素とされる。
【００９９】
majorProtocolversion属性と、minorProtocolVersion属性には、シンタックスのバージョン情報が指定される。CCTVersion属性には、CCTのバージョン情報が指定される。baseURI属性には、CCTに関するURLのベースとなる共通のURLが指定される。
【０１００】
Application要素には、アプリケーションごとのキャッシュ制御情報が指定される。Application要素は、appID属性、size属性、及び、PU要素の上位要素とされる。appID属性には、アプリケーションIDが指定される。このアプリケーションIDが、図５のAIT等のアプリケーションIDに対応している。size属性には、アプリケーション全体のサイズを示す情報が指定される。
【０１０１】
PU要素には、提示される単位ごとのキャッシュ制御情報が指定される。PU要素は、id属性、size属性、Item要素、及び、LinkedPU要素の上位要素とされる。id属性には、PUの識別情報（図７等のPU_ID）が指定される。size属性には、PU単位のサイズを示す情報が指定される。受信機は、このPU単位のサイズ情報を確認することで、キャッシュメモリに保持するファイルを決定することができる。
【０１０２】
Item要素には、PUを構成する各ファイルに関する情報が指定される。Item要素は、primary属性、uri属性、及び、type属性の上位要素とされる。primary属性には、PUにおけるプライマリのファイルに関する情報が指定される。例えば、アプリケーションにおいて、プライマリのファイルはHTMLファイルとされ、この情報によって、受信機側では特定のPUを取り込んだことを認識することができる。
【０１０３】
uri属性には、各ファイルのURLが指定される。このURLとしては、baseURI属性で指定されるURLに対する相対的なURLが指定される。type属性には、タイプ情報として、"m"又は"p"が指定される。このタイプ情報として、"m"が指定された場合は、PUを構成するファイルであることを示す。一方、タイプ情報として、"p"が指定された場合には、PUを構成するファイルではなく、特定のファイルであることを示す。例えば、放送事業者側で、あらかじめ強制的に取得させたい特定のファイルには、"p"であるタイプ情報が指定されることになる。
【０１０４】
LinkedPU要素は、対象のPUにリンクされたPUに関する情報が指定される。このLinkedPU要素の子要素のid属性には、リンクされたPUの識別情報（図７等のPU_ID）が指定される。このリンクされたPUの識別情報を参照することで、受信機側では、例えば、最小限のファイル群よりも多い、中間のファイル群をキャッシュメモリに保持することができる（図８の中央の「Medium Cache」）。
【０１０５】
＜２．IP伝送方式によるデジタル放送の概要＞
【０１０６】
番組等のAVコンテンツは、IP（Internet Protocol）伝送方式を採用したデジタル放送により伝送することができる。
【０１０７】
（システムパイプモデル）
図１０は、IP伝送方式のデジタル放送のシステムパイプモデルを示す図である。
【０１０８】
図１０において、所定の周波数帯域を有する放送波（RF Channel）には、複数のBBP（Base Band Packet）ストリームが伝送されている。また、各BBPストリームには、NTP（Network Time Protocol）、複数のサービスチャンネル（Service Channel）、ESG（Electronic Service Guide）サービス、及び、LLS（Low Layer Signaling）が含まれる。なお、NTP、サービスチャンネル、及び、ESGサービスは、UDP/IP（User Datagram Protocol/Internet Protocol）のプロトコルに従って伝送されるが、LLSは、BBPストリーム上で伝送される。
【０１０９】
NTPは、時刻情報である。ESGサービスは、電子サービスガイドである。LLSは、低レイヤのシグナリング情報が伝送される。例えば、LLSとしては、SCD（Service Configuration Description）、EAD（Emergency Alerting Description）、RRD（Region Rating Description）等のLLSシグナリング情報が伝送される。
【０１１０】
SCDは、MPEG2-TS（Moving Picture Experts Group phase 2 - Transport Stream）方式に対応したID体系によって、放送ネットワーク内のBBPストリーム構成とサービス構成を示している。また、SCDには、サービス単位の属性・設定情報や、ESGサービスやSCSに接続するためのbootstrap情報などが含まれる。
【０１１１】
EADは、緊急告知に関する情報を含んでいる。RRDは、レーティング情報を含んでいる。なお、SCD、EAD、RRD等のLLSシグナリング情報は、例えば、XML等のマークアップ言語により記述される。
【０１１２】
サービスチャンネル（以下、「サービス」という）は、SCS（Service Channel Signaling）と、ビデオやオーディオ、字幕等の番組を構成するコンポーネント（Component）から構成される。なお、各サービスを構成する要素には、共通のIPアドレスが付与されており、このIPアドレスを用いて、サービスごとに、コンポーネントやSCSなどをパッケージ化することができる。
【０１１３】
SCSは、サービス単位のシグナリング情報が伝送される。例えば、SCSとしては、USD（User Service Description）、MPD（Media Presentation Description）、SDP（Session Description Protocol）、FDD（File Delivery Description）、SPD（Service Parameter Description）、IS（Initialization Segment）等のSCSシグナリング情報が伝送される。
【０１１４】
USDは、MPD、FDD、SDP等のSCSシグナリング情報を参照するための参照情報を含んでいる。なお、USDは、USBD（User Service Bundle Description）と称される場合がある。MPDは、サービス単位で伝送されるコンポーネントのストリームごとのセグメントURLなどの情報を含んでいる。なお、MPDは、MPEG-DASH（Moving Picture Expert Group - Dynamic Adaptive Streaming over HTTP）の規格に準じている。SDPは、サービス単位のサービス属性、ストリームの構成情報や属性、フィルタ情報、ロケーション情報などを含んでいる。
【０１１５】
FDDは、TSI（Transport Session Identifier）ごとのインデックス情報として、ロケーション情報（例えばURLなど）やTOI（Transport Object Identifier）などの情報を含んでいる。ここで、FLUTE（File Delivery over Unidirectional Transport）セッションでは、送信するファイルなどを１つのオブジェクトとして、TOIにより管理する。また、複数のオブジェクトの集合を１つのセッションとして、TSIにより管理する。
【０１１６】
すなわち、FLUTEセッションにおいては、TSIとTOIの２つの識別情報によって特定のファイルを指定することが可能となる。なお、FDDは、USDに要素として含めるようにしてもよい。また、FLUTEの代わりに、FLUTEを拡張したFLUTE +（FLUTE plus）を用いるようにしてもよい。
【０１１７】
SPDは、サービスやコンポーネントのレベルで規定された各種のパラメータを含んで構成される。ISは、FLUTEセッションで伝送されるビデオやオーディオのコンポーネントのセグメントデータに関する制御情報を含んでいる。
【０１１８】
すなわち、FLUTEセッションでビデオやオーディオのコンポーネントを伝送する場合、これらのコンポーネントのファイルは、セグメントごとに分割され、各セグメントは、IS（Initialization Segment）と、MS（Media Segment）から構成される。ISには、データ圧縮方式等の初期化情報や制御情報が含まれる。また、MSには、ビデオやオーディオのコンポーネントのデータが格納される。なお、FLUTEセッションの各セグメントは、ISO Base Media File Formatの規定に準じている。
【０１１９】
なお、USD、MPD、SDP、FDD、SPD、IS等のSCSシグナリング情報は、例えば、XML等のマークアップ言語により記述される。また、ISは、SCSストリームで伝送するのではなく、ビデオやオーディオのストリームで伝送するようにしてもよい。また、以下、LLSシグナリング情報と、SCSシグナリング情報を特に区別する必要がない場合には、単に「シグナリング情報」と称して説明する。
【０１２０】
ここで、所定の周波数帯域を有する放送波（RF Channel）には、例えば放送事業者ごとに、RFチャンネルID（RF Channel ID）が割り当てられている。また、各放送波で伝送される１又は複数のBBPストリームには、BBPストリームID（BBP Stream ID）が割り当てられる。さらに、各BBPストリームで伝送される１又は複数のサービスには、サービスID（Service ID）が割り当てられる。
【０１２１】
このように、IP伝送方式のID体系としては、MPEG2-TS方式で用いられているネットワークID（Network ID）と、トランスポートストリームID（Transport Stream ID）と、サービスID（Service ID）の組み合わせ（トリプレット（Triplet））に対応する構成が採用され、このトリプレットによって、放送ネットワーク内のBBPストリーム構成とサービス構成が示される。
【０１２２】
このようなID体系を用いることで、現在広く普及しているMPEG2-TS方式との整合をとることができる。なお、IP伝送方式のID体系では、RFチャンネルIDとBBPストリームIDが、MPEG2-TS方式におけるネットワークIDとトランスポートストリームIDに対応している。
【０１２３】
＜３．具体的なユースケース＞
【０１２４】
（１）ユースケース１：収録済み番組に連動したアプリケーションの制御
【０１２５】
図１１と図１２は、ユースケース１を説明する図である。なお、図１１と図１２においては、時間の方向が、図中の左側から右側の方向とされ、別の図面で表しているが、図中の縦方向の点線Ｌ１を介して時間的に連続しているものとする。
【０１２６】
図１１と図１２において、RFチャンネルIDにより識別される放送局（放送事業者）の送信機は、IP伝送方式を用いたデジタル放送信号によって、BBPストリームIDにより識別されるBBPストリームを伝送している。BBPストリームでは、サービスIDで識別されるサービスを構成するAVコンテンツ（図中の「A/V」）やSCSシグナリング情報（図中の「SCS」）、メタデータ（図中の「SCS」）、及び、アプリケーション（図中の「NRT」）のストリームが伝送されている。
【０１２７】
なお、これらのストリームで伝送されるファイルは、FLUTEセッションで伝送されている。また、AVコンテンツを構成するビデオデータには、トリガ情報（Trigger）が埋め込まれている。また、図１１と図１２において、インターネット（Internet）上に設けられたアプリケーションサーバ（Application Server）が、アプリケーションを配信し、メタデータサーバ（Matadata Server）が、メタデータを配信している。
【０１２８】
このユースケース１においては、送信機から配信されるAVコンテンツ（図中の「A/V」）として、例えばドラマ等の収録済み番組が送信されている。図１１において、各家庭等に設置された受信機では、A/Vストリームに接続することで、収録済み番組が再生されている。
【０１２９】
受信機は、メモリからSCDを読み出して、SCS Bootstrap情報に従い、放送波で伝送されているSCSストリームに接続して、SCSシグナリング情報を取得する（図１１のＳ１１）。なお、受信機は、初期スキャン処理時などに、LLSで伝送されるLLSシグナリング情報を取得してメモリに記録している。なお、再配信環境において、シグナリング情報を取得することができない場合には、これらの情報は取得しなくてもよい。
【０１３０】
また、受信機は、送信機がトリガ情報を伝送するタイミングで、ビデオストリームで伝送されるトリガ情報を取得する（図１１のＳ１２）。このトリガ情報には、ロケーション情報（Locator）とメディアタイム情報（Media Time）が含まれている。受信機は、トリガ情報に含まれるメディアタイム情報を設定して、当該メディアタイム情報による時刻の計時を開始する（図１１のＳ１３）。
【０１３１】
受信機は、ステップＳ１１の処理で取得したSCSシグナリング情報に含まれるUSDと、ステップＳ１２の処理で取得したトリガ情報に含まれるロケーション情報に基づいて、メタデータの配信経路が放送又は通信のいずれであるかを判定する。なお、再配信環境において、シグナリング情報を取得することができない場合には、当該配信経路が通信のみであると判定してもよい。
【０１３２】
そして、メタデータが放送で配信されている場合、受信機は、SCSシグナリング情報に含まれるSDPやFDD等に従い、SCSストリームに接続して、FLUTEセッションで伝送されているメタデータのファイルを取得する（図１１のＳ１４）。一方、メタデータが通信で配信されている場合、受信機は、トリガ情報に含まれるロケーション情報に従い、インターネットを介してメタデータサーバに接続し、メタデータのファイルを取得する（図１１のＳ１４）。
【０１３３】
このようにして、受信機では、放送又は通信で配信されるメタデータが取得される。このメタデータには、AIT、EMT、及び、CCTが含まれる。AITには、オーガニゼーションID（OrgID）、アプリケーションID（AppID）、アプリケーションURL（App_URL）等のアプリケーション制御情報が含まれる。
【０１３４】
EMTには、アプリケーションごとのアクション情報が時系列で規定されている。図１１のEMTには、アプリケーション１（App1）に対するアクション情報として、時刻T0でのプリフェッチ（Pref）、時刻T1でのエクスキュート（Exec）、時刻T2でのインジェクトイベント（Inj_A_E）、時刻T4でのサスペンド（Susp）、時刻T5でのエクスキュート（Exec）、時刻T6でのキル（Kill）が規定されている。また、図１１のEMTには、アプリケーション２（App2）に対するアクション情報として、時刻T3でのプリフェッチ（Pref）、時刻T4でのエクスキュート（Exec）、時刻T5でのキル（Kill）が規定されている。
【０１３５】
CCTには、アプリケーション１とアプリケーション２について、PUを構成する各ファイルのURL等のキャッシュ制御情報が含まれる。
【０１３６】
ここで、受信機では、ステップＳ１３の処理で、メディアタイム情報による時刻の計時が開始されているが、この計時されている時刻が、EMTのアプリケーションごとのアクション情報に指定された時刻になったかどうか（時刻を経過したかどうか）が常に監視されている。
【０１３７】
そして、計時時刻が、時刻T0となったとき、EMTに規定されたアプリケーション１（App1）に対するプリフェッチアクションを実行するタイミングとなったので、受信機は、アプリケーション１のアプリケーションID（AppID）に従い、AITを参照して、アプリケーション１のアプリケーションURLを取得する（図１１のＳ１５）。また、受信機は、CCTを参照して、アプリケーション１を構成するファイル群のうち、キャッシュメモリに保持するファイルを決定する。ここでは、例えば、受信機が有するキャッシュメモリの容量に応じて、キャッシュメモリに保持するファイルが決定される。
【０１３８】
受信機は、ステップＳ１１の処理で取得したSCSシグナリング情報に含まれるUSDと、アプリケーションURLと、アプリケーションアイテムURL（キャッシュメモリに保持するファイルの取得先を示すURL）に基づいて、アプリケーション１（のファイル）の配信経路が放送又は通信のいずれであるかを判定する。なお、再配信環境において、シグナリング情報を取得することができない場合には、当該配信経路が通信のみであると判定してもよい。
【０１３９】
そして、アプリケーション１（のファイル）が放送で配信されている場合、受信機は、SCSシグナリング情報に含まれるSDPやFDD等に従い、NRTストリームに接続して、FLUTEセッションで伝送されているアプリケーション１のファイルを取得する（図１１のＳ１５）。一方、アプリケーション１（のファイル）が通信で配信されている場合、受信機は、アプリケーションURL等に従い、インターネットを介してアプリケーションサーバに接続し、アプリケーション１のファイルを取得する（図１１のＳ１５）。
【０１４０】
このようにして、受信機では、放送又は通信で配信されるアプリケーション１（のファイル）が取得され、キャッシュメモリ（Cache）に保持される。なお、このキャッシュメモリに保持される、アプリケーション１のファイルは、当該キャッシュメモリの容量と、キャッシュ制御情報としてのCCTに基づいたものとなる。
【０１４１】
その後、計時時刻が、時刻T1となったとき、EMTに規定されたアプリケーション１（App1）に対するエクスキュートアクションを実行するタイミングとなったので、受信機では、キャッシュメモリに保持されていたアプリケーション１（のファイル）が読み出され、実行されることになる（図１１のＳ１６）。これにより、受信機では、収録済み番組に連動して、アプリケーション１が動作することになる。
【０１４２】
次に、計時時刻が、時刻T2になったとき、EMTに規定されたアプリケーション１（App1）に対するインジェクトイベントアクションを実行するタイミングとなったので、受信機では、実行中のアプリケーション１に対するイベントを発火する（図１１のＳ１７）。これにより、受信機では、例えば、収録済み番組に連動して実行されているアプリケーション１の表示が切り替わる。
【０１４３】
その後、図１２において、計時時刻が時刻T3となったとき、EMTに規定されたアプリケーション２（App2）に対するプリフェッチアクションを実行するタイミングとなったので、受信機では、アプリケーション２のアプリケーションID（AppID）に従い、AITを参照して、アプリケーション２のアプリケーションURLを取得する（図１２のＳ１８）。また、受信機は、CCTを参照して、アプリケーション２を構成するファイル群のうち、キャッシュメモリに保持するファイルを決定する。ここでは、例えば、受信機が有するキャッシュメモリの容量に応じて、キャッシュメモリに保持するファイルが決定される。
【０１４４】
受信機は、ステップＳ１１の処理で取得したSCSシグナリング情報に含まれるUSDと、アプリケーションURLと、アプリケーションアイテムURL（キャッシュメモリに保持するファイルの取得先を示すURL）に基づいて、アプリケーション２（のファイル）の配信経路が放送又は通信のいずれかであるかを判定する。なお、再配信環境において、シグナリング情報を取得することができない場合には、当該配信経路が通信のみであると判定してもよい。
【０１４５】
そして、アプリケーション２（のファイル）が放送で配信されている場合、受信機は、SCSシグナリング情報に含まれるSDPやFDD等に従い、NRTストリームに接続して、FLUTEセッションで伝送されているアプリケーション２のファイルを取得する（図１２のＳ１８）。一方、アプリケーション２が通信で配信されている場合、受信機は、アプリケーションURL等に従い、インターネットを介してアプリケーションサーバに接続し、アプリケーション２のファイルを取得する（図１２のＳ１８）。
【０１４６】
このようにして、受信機では、放送又は通信で配信されるアプリケーション２が取得され、キャッシュメモリ（Cache）に保持される。なお、このキャッシュメモリに保持される、アプリケーション２のファイルは、当該キャッシュメモリの容量と、キャッシュ制御情報としてのCCTに基づいたものとなる。
【０１４７】
その後、計時時刻が、時刻T4となったとき、EMTに規定されたアプリケーション１（App1）に対するサスペンドアクションと、アプリケーション２（App2）に対するエクスキュートアクションを同時に実行するタイミングとなったので、まず、受信機は、実行中のアプリケーション１を、キャッシュメモリ（Cache）に退避させる（図１２のＳ１９）。続いて、受信機では、キャッシュメモリに保持されていたアプリケーション２（のファイル）が読み出され、実行されることになる（図１２のＳ１９）。これにより、受信機では、収録済み番組に連動して、アプリケーション１の代わりに、アプリケーション２が動作することになる。
【０１４８】
また、計時時刻が、時刻T5となったとき、EMTに規定されたアプリケーション２（App2）に対するキルアクションと、アプリケーション１（App1）に対するエクスキュートアクションを同時に実行するタイミングとなったので、まず、受信機は、実行中のアプリケーション２を終了させる（図１２のＳ２０）。続いて、受信機では、ステップＳ１９の処理でキャッシュメモリに退避されていたアプリケーション１が読み出され、実行されることになる（図１２のＳ２０）。これにより、受信機では、収録済み番組に連動して実行されていたアプリケーション２が終了され、再度、アプリケーション１が、収録済み番組に連動して動作することになる。
【０１４９】
そして、計時時刻が、時刻T6となったとき、EMTに規定されたアプリケーション１（App1）に対するキルアクションを実行するタイミングとなったので、受信機では、実行中のアプリケーション１が終了される（図１２のＳ２１）。これにより、受信機では、収録済み番組に連動して実行されていたアプリケーション１が終了され、収録済み番組のみが表示される。
【０１５０】
なお、図１３には、ユースケース１における各データの対応関係を示している。図１３においては、AITやEMT等のメタデータは、トリガ情報に含まれるロケーション情報に従い、取得されることが示されている。また、AITとEMTにおいては、アプリケーションIDが関連付けられている。さらに、アプリケーションは、AITのアプリケーションURLに従い、取得されることが示されている。
【０１５１】
以上、ユースケース１について説明した。
【０１５２】
（２）ユースケース２：ライブ番組に連動したアプリケーションの制御
【０１５３】
図１４と図１５は、ユースケース２を説明する図である。図１４と図１５においては、時間の方向が、図中の左側から右側の方向とされ、別の図面で表しているが、図中の縦方向の点線Ｌ２を介して時間的に連続しているものとする。
【０１５４】
図１４と図１５においては、上述した図１１等と同様に、放送局（放送事業者）の送信機は、IP伝送方式を用いたデジタル放送の放送波によって、BBPストリームを伝送している。このBBPストリームでは、サービスを構成するAVコンテンツ（図中の「A/V」）やSCSシグナリング情報（図中の「SCS」）、メタデータ（図中の「SCS」）、及び、アプリケーション（図中の「NRT」）のストリームが伝送されている。
【０１５５】
なお、これらのストリームで伝送されるファイルは、FLUTEセッションで伝送されている。また、AVコンテンツを構成するビデオデータには、トリガ情報（Trigger）が埋め込まれている。また、図１４と図１５において、インターネット（Internet）上に設けられたアプリケーションサーバ（Application Server）が、アプリケーションを配信し、メタデータサーバ（Matadata Server）が、メタデータを配信している。
【０１５６】
このユースケース２においては、送信機から配信されるAVコンテンツ（図中の「A/V」）として、例えばスポーツ中継等のライブ番組が送信されている。図１４において、各家庭等に設置された受信機では、A/Vストリームに接続することで、ライブ番組が再生されている。
【０１５７】
受信機は、メモリからSCDを読み出して、SCS Bootstrap情報に従い、放送波で伝送されているSCSストリームに接続して、SCSシグナリング情報を取得する（図１４のＳ３１）。なお、再配信環境において、シグナリング情報を取得することができない場合には、これらの情報は取得しなくてもよい。
【０１５８】
また、受信機は、送信機がトリガ情報を伝送するタイミングで、ビデオストリームで伝送されるトリガ情報を取得する（図１４のＳ３２）。このトリガ情報には、ロケーション情報（Locator）が含まれている。また、ロケーション情報には、アプリケーション１（App1）に対するアクション情報として、プリフェッチが付加されている。
【０１５９】
受信機は、ステップＳ３１の処理で取得したSCSシグナリング情報に含まれるUSDと、ステップＳ３２の処理で取得したトリガ情報に含まれるロケーション情報に基づいて、メタデータの配信経路が放送又は通信のいずれであるかを判定する。なお、再配信環境において、シグナリング情報を取得することができない場合には、当該配信経路が通信のみであると判定してもよい。
【０１６０】
そして、メタデータが放送で配信されている場合、受信機は、SCSシグナリング情報に含まれるSDPやFDD等に従い、SCSストリームに接続して、FLUTEセッションで伝送されているメタデータのファイルを取得する（図１４のＳ３３）。一方、メタデータが通信で配信されている場合、受信機は、トリガ情報に含まれるロケーション情報に従い、インターネットを介してメタデータサーバに接続し、メタデータのファイルを取得する（図１４のＳ３３）。
【０１６１】
このようにして、受信機では、放送又は通信で配信されるメタデータが取得される。このメタデータには、AIT及びCCTが含まれる。AITには、オーガニゼーションID（OrgID）、アプリケーションID（AppID）、アプリケーションURL（App_URL）等のアプリケーション制御情報が含まれる。CCTには、アプリケーション１とアプリケーション２について、PUを構成する各ファイルのURL等のキャッシュ制御情報が含まれる。
【０１６２】
また、受信機は、トリガ情報に含まれるロケーション情報に付加されたプリフェッチアクションの対象となるアプリケーション１（App1）のアプリケーションID（AppID）に従い、AITを参照して、アプリケーション１のアプリケーションURLを取得する（図１４のＳ３４）。また、受信機は、CCTを参照して、アプリケーション１を構成するファイル群のうち、キャッシュメモリに保持するファイルを決定する。
【０１６３】
受信機は、ステップＳ３１の処理で取得したSCSシグナリング情報に含まれるUSDと、アプリケーションURLと、アプリケーションアイテムURL（キャッシュメモリに保持するファイルの取得先を示すURL）に基づいて、アプリケーション１の配信経路が放送又は通信のいずれであるかを判定する。なお、再配信環境において、シグナリング情報を取得することができない場合には、当該配信経路が通信のみであると判定してもよい。
【０１６４】
そして、アプリケーション１（のファイル）が放送で配信されている場合、受信機は、SCSシグナリング情報に含まれるSDPやFDD等に従い、NRTストリームに接続して、FLUTEセッションで伝送されているアプリケーション１のファイルを取得する（図１４のＳ３４）。一方、アプリケーション１（のファイル）が通信で配信されている場合、受信機は、アプリケーションURL等に従い、インターネットを介してアプリケーションサーバに接続し、アプリケーション１のファイルを取得する（図１４のＳ３４）。
【０１６５】
このようにして、受信機では、放送又は通信で配信されるアプリケーション１（のファイル）が取得され、キャッシュメモリ（Cache）に保持される。なお、このキャッシュメモリに保持される、アプリケーション１のファイルは、当該キャッシュメモリの容量と、キャッシュ制御情報としてのCCTに基づいたものとなる。
【０１６６】
その後、受信機では、ビデオストリームでトリガ情報が伝送されているかどうかが監視され、送信機がトリガ情報を伝送するタイミングで、トリガ情報が取得される（図１４のＳ３５）。このトリガ情報には、ロケーション情報に、アプリケーション１（App1）に対するエクスキュートアクションが付加されている。受信機は、当該トリガ情報に従い、AITを参照して確認した後に、キャッシュメモリに保持されていたアプリケーション１を読み出して、実行する（図１４のＳ３６）。これにより、受信機では、ライブ番組に連動して、アプリケーション１が動作することになる。
【０１６７】
受信機においては、その後もビデオストリームでトリガ情報が伝送されているかどうかが常に監視され、送信機がトリガ情報を伝送するタイミングで、トリガ情報が取得される（図１４のＳ３７）。このトリガ情報には、ロケーション情報に、アプリケーション１（App1）に対するインジェクトイベントアクションが付加されている。受信機は、当該トリガ情報に従い、AITを参照して確認した後に、実行中のアプリケーション１に対するイベントを発火する（図１４のＳ３８）。これにより、受信機では、例えば、ライブ番組に連動して実行されているアプリケーション１の表示が切り替わる。
【０１６８】
その後、図１５において、受信機では、送信機がトリガ情報を伝送するタイミングで、トリガ情報が取得される（図１５のＳ３９）。このトリガ情報には、ロケーション情報に、アプリケーション２（App2）に対するプリフェッチアクションが付加されている。受信機は、当該ロケーション情報に付加されたアプリケーション２のアプリケーションID（AppID）に従い、AITを参照して、アプリケーション２のアプリケーションURLを取得する（図１５のＳ４０）。また、受信機は、CCTを参照して、アプリケーション１を構成するファイル群のうち、キャッシュメモリに保持するファイルを決定する。
【０１６９】
受信機は、ステップＳ３１の処理で取得したSCSシグナリング情報に含まれるUSDと、アプリケーションURLと、アプリケーションアイテムURL（キャッシュメモリに保持するファイルの取得先を示すURL）に基づいて、アプリケーション２の配信経路が放送又は通信のいずれかであるかを判定する。なお、再配信環境において、シグナリング情報を取得することができない場合には、当該配信経路が通信のみであると判定してもよい。
【０１７０】
そして、アプリケーション２が放送で配信されている場合、受信機は、SCSシグナリング情報に含まれるSDPやFDD等に従い、NRTストリームに接続して、FLUTEセッションで伝送されているアプリケーション２のファイルを取得する（図１５のＳ４０）。一方、アプリケーション２が通信で配信されている場合、受信機は、アプリケーションURL等に従い、インターネットを介してアプリケーションサーバに接続し、アプリケーション２のファイルを取得する（図１５のＳ４０）。
【０１７１】
このようにして、受信機では、放送又は通信で配信されるアプリケーション２が取得され、キャッシュメモリ（Cache）に保持される。なお、このキャッシュメモリに保持される、アプリケーション２のファイルは、当該キャッシュメモリの容量と、キャッシュ制御情報としてのCCTに基づいたものとなる。
【０１７２】
その後、受信機では、送信機がトリガ情報を伝送するタイミングで、トリガ情報が取得される（図１５のＳ４１）。このトリガ情報には、ロケーション情報に、アプリケーション１（App1）に対するサスペンドアクションと、アプリケーション２（App2）に対するエクスキュートアクションが付加されている。
【０１７３】
受信機は、まず、当該ロケーション情報に付加されたアプリケーション１に対するサスペンドアクションに従い、AITを参照して確認した後に、実行中のアプリケーション１を、キャッシュメモリ（Cache）に退避させる（図１５のＳ４２）。続いて、受信機は、当該ロケーション情報に付加されたアプリケーション２に対するエクスキュートアクションに従い、AITを参照して確認した後に、キャッシュメモリに保持されていたアプリケーション２を読み出して、実行する（図１５のＳ４２）。これにより、受信機では、ライブ番組に連動して、アプリケーション１の代わりに、アプリケーション２が動作することになる。
【０１７４】
また、受信機では、送信機がトリガ情報を伝送するタイミングで、トリガ情報が取得される（図１５のＳ４３）。このトリガ情報には、ロケーション情報に、アプリケーション２（App2）に対するキルアクションと、アプリケーション１（App1）に対するエクスキュートアクションが付加されている。
【０１７５】
受信機は、まず、当該ロケーション情報に付加されたアプリケーション２に対するキルアクションに従い、AITを参照して確認した後に、実行中のアプリケーション２を終了させる（図１５のＳ４４）。続いて、受信機は、当該ロケーション情報に付加されたアプリケーション１に対するエクスキュートアクションに従い、AITを参照して確認した後に、ステップＳ４２の処理でキャッシュメモリに退避されていたアプリケーション１を読み出して、その実行を再開することになる（図１５のＳ４４）。これにより、受信機では、ライブ番組に連動して実行されていたアプリケーション２が終了され、再度、アプリケーション１が、ライブ番組に連動して動作することになる。
【０１７６】
また、受信機では、送信機がトリガ情報を伝送するタイミングで、トリガ情報が取得される（図１５のＳ４５）。このトリガ情報には、ロケーション情報に、アプリケーション１（App1）に対するキルアクションが付加されている。受信機は、当該ロケーション情報に付加されたアプリケーション１に対するキルアクションに従い、AITを参照して確認した後に、実行中のアプリケーション１を終了させる。これにより、受信機では、ライブ番組に連動して実行されていたアプリケーション１が終了され、ライブ番組のみが表示される。
【０１７７】
なお、図１６には、ユースケース２における各データの対応関係を示している。図１６においては、AIT等のメタデータは、トリガ情報に含まれるロケーション情報に従い、取得されることが示されている。また、アプリケーションは、AITのアプリケーションURLに従い、取得されることが示されている。
【０１７８】
以上、ユースケース２について説明した。
【０１７９】
（３）ユースケース３：ハイブリッド型のアプリケーションの制御
【０１８０】
図１７と図１８は、ユースケース３を説明する図である。図１７と図１８においては、時間の方向が、図中の左側から右側の方向とされ、別の図面で表しているが、図中の縦方向の点線Ｌ３を介して時間的に連続しているものとする。
【０１８１】
図１７と図１８においては、上述した図１１等と同様に、放送局（放送事業者）の送信機は、IP伝送方式を用いたデジタル放送の放送波によって、BBPストリームを伝送している。このBBPストリームでは、サービスを構成するAVコンテンツ（図中の「A/V」）やSCSシグナリング情報（図中の「SCS」）、メタデータ（図中の「SCS」）、及び、アプリケーション（図中の「NRT」）のストリームが伝送されている。
【０１８２】
なお、これらのストリームで伝送されるファイルは、FLUTEセッションで伝送されている。また、AVコンテンツを構成するビデオデータには、トリガ情報（Trigger）が埋め込まれている。また、図１７と図１８において、インターネット（Internet）上に設けられたアプリケーションサーバ（Application Server）が、アプリケーションを配信し、メタデータサーバ（Matadata Server）が、メタデータを配信している。
【０１８３】
図１７において、各家庭等に設置された受信機では、A/Vストリームに接続することで、番組が再生されている。受信機は、メモリからSCDを読み出して、SCS Bootstrap情報に従い、放送波で伝送されているSCSストリームに接続して、SCSシグナリング情報を取得する（図１７のＳ５１）。なお、再配信環境において、シグナリング情報を取得することができない場合には、これらの情報は取得しなくてもよい。
【０１８４】
また、受信機は、送信機がトリガ情報を伝送するタイミングで、ビデオストリームで伝送されるトリガ情報を取得する（図１７のＳ５２）。このトリガ情報には、ロケーション情報（Locator）とメディアタイム情報（Media Time）が含まれている。受信機は、トリガ情報に含まれるメディアタイム情報を設定して、メディアタイム情報による時刻の計時を開始する（図１７のＳ５３）。
【０１８５】
受信機は、ステップＳ５１の処理で取得したSCSシグナリング情報に含まれるUSDと、ステップＳ５２の処理で取得したトリガ情報に含まれるロケーション情報に基づいて、メタデータの配信経路が放送又は通信のいずれであるかを判定する。なお、再配信環境において、シグナリング情報を取得することができない場合には、当該配信経路が通信のみであると判定してもよい。
【０１８６】
そして、メタデータが放送で配信されている場合、受信機は、SCSシグナリング情報に含まれるSDPやFDD等に従い、SCSストリームに接続して、FLUTEセッションで伝送されているメタデータのファイルを取得する（図１７のＳ５４）。一方、メタデータが通信で配信されている場合、受信機は、トリガ情報に含まれるロケーション情報に従い、インターネットを介してメタデータサーバに接続し、メタデータのファイルを取得する（図１７のＳ５４）。
【０１８７】
このようにして、受信機では、放送又は通信で配信されるメタデータが取得される。このメタデータには、AIT、EMT、及び、CCTが含まれる。AITには、オーガニゼーションID（OrgID）、アプリケーションID（AppID）、アプリケーションURL（App_URL）等のアプリケーション制御情報が含まれる。
【０１８８】
EMTには、アプリケーションごとのアクション情報が時系列で規定されている。図１７のEMTには、アプリケーション１（App1）に対するアクションとして、時刻T0でのプリフェッチ（Pref）、時刻T1でのエクスキュート（Exec）、時刻T2でのインジェクトイベント（Inj_A_E）、時刻T3でのキル（Kill）が規定されている。
【０１８９】
CCTには、アプリケーション１について、PUを構成する各ファイルのURL等のキャッシュ制御情報が含まれる。
【０１９０】
ここで、受信機では、ステップＳ５３の処理で、メディアタイム情報による時刻の計時が開始されているが、この計時されている時刻が、EMTのアプリケーションごとのアクション情報に指定された時刻になったかどうか（時刻を経過したかどうか）が常に監視されている。
【０１９１】
そして、計時時刻が、時刻T0となったとき、EMTに規定されたアプリケーション１（App1）に対するプリフェッチアクションを実行するタイミングとなったので、受信機では、アプリケーション１のアプリケーションID（AppID）に従い、AITを参照して、アプリケーション１のアプリケーションURLを取得する（図１７のＳ５５）。また、受信機は、CCTを参照して、アプリケーション１を構成するファイル群のうち、キャッシュメモリに保持するファイルを決定する。
【０１９２】
受信機は、ステップＳ５１の処理で取得したSCSシグナリング情報に含まれるUSDと、アプリケーションURLと、アプリケーションアイテムURL（キャッシュメモリに保持するファイルの取得先を示すURL）に基づいて、アプリケーション１（のファイル）の配信経路が放送又は通信のいずれであるかを判定する。なお、再配信環境において、シグナリング情報を取得することができない場合には、当該配信経路が通信のみであると判定してもよい。
【０１９３】
そして、アプリケーション１（のファイル）が放送で配信されている場合、受信機は、SCSシグナリング情報に含まれるSDPやFDD等に従い、NRTストリームに接続して、FLUTEセッションで伝送されているアプリケーション１のファイルを取得する（図１７のＳ５５）。一方、アプリケーション１（のファイル）が通信で配信されている場合、受信機は、アプリケーションURL等に従い、インターネットを介してアプリケーションサーバに接続し、アプリケーション１のファイルを取得する（図１７のＳ５５）。
【０１９４】
このようにして、受信機では、放送又は通信で配信されるアプリケーション１（のファイル）が取得され、キャッシュメモリ（Cache）に保持される。なお、このキャッシュメモリに保持される、アプリケーション１のファイルは、当該キャッシュメモリの容量と、キャッシュ制御情報としてのCCTに基づいたものとなる。
【０１９５】
その後、受信機では、送信機がトリガ情報を伝送するタイミングで、トリガ情報が取得される（図１７のＳ５６）。このトリガ情報には、ロケーション情報に、アプリケーション１（App1）に対するエクスキュートアクションの実行時刻を、時刻T1から時刻T1Aに更新するためのイベント情報が付加されている。受信機は、当該トリガ情報に含まれるイベント情報に従い、EMTに規定された、アプリケーション１に対するエクスキュートアクションの実行時刻を、時刻T1から時刻T1Aに更新する（図１７のＳ５７）。
【０１９６】
そして、計時時刻が、更新後の時刻T1Aとなったとき、EMTに規定されたアプリケーション１に対するエクスキュートアクションを実行するタイミングとなったので、受信機では、キャッシュメモリに保持されていたアプリケーション１が読み出され、実行されることになる（図１７のＳ５８）。これにより、受信機では、番組に連動して、アプリケーション１が動作することになる。
【０１９７】
その後、図１８において、受信機では、送信機がトリガ情報を伝送するタイミングで、トリガ情報が取得される（図１８のＳ５９）。このトリガ情報には、ロケーション情報に、アプリケーション１（App1）に対する、時刻T2でのインジェクトイベントアクションを削除するためのイベント情報が付加されている。受信機は、当該トリガ情報に含まれるイベント情報に従い、EMTに規定された、アプリケーション１（App1）に対する、時刻T2でのインジェクトイベントアクションを削除する（図１８のＳ６０）。
【０１９８】
また、受信機では、送信機がトリガ情報を伝送するタイミングで、トリガ情報が取得される（図１８のＳ６１）。このトリガ情報には、ロケーション情報に、アプリケーション１（App1）に対するインジェクトイベントアクションが付加されている。受信機は、当該トリガ情報に従い、AITを参照して確認した後に、実行中のアプリケーション１に対するイベントを発火する（図１８のＳ６２）。これにより、受信機では、例えば番組に連動して実行されているアプリケーション１の表示が切り替わる。すなわち、ここでは、EMTにあらかじめ規定された時刻ではなく、トリガ情報に含まれるイベント情報に指定された変更後の時刻に、アプリケーション１に対するイベントが発火されたことになる。
【０１９９】
その後、計時時刻が、時刻T3になったとき、EMTに規定されたアプリケーション１（App1）に対するキルアクションを実行するタイミングとなったので、受信機では、実行中のアプリケーション１が終了される（図１８のＳ６３）。これにより、受信機では、番組に連動して実行されていたアプリケーション１が終了され、番組のみが表示させる。
【０２００】
以上、ユースケース３について説明した。
【０２０１】
（４）ユースケース４：収録済み番組に連動したアプリケーションの制御（ACR対応）
【０２０２】
図１９は、ユースケース４を説明する図である。
【０２０３】
図１９においては、上述した図１１等と同様に、放送局（放送事業者）の送信機は、IP伝送方式を用いたデジタル放送の放送波によって、BBPストリームを伝送している。このBBPストリームでは、サービスを構成するAVコンテンツ（図中の「A/V」）のストリームが伝送されている。なお、当該ストリームで伝送されるファイルは、FLUTEセッションで伝送されている。
【０２０４】
また、図１９において、インターネット（Internet）上に設けられたアプリケーションサーバ（Application Server）が、アプリケーションを配信し、メタデータサーバ（Matadata Server）が、メタデータを配信している。また、インターネット上には、ACRサーバ（ACR Server）が設けられており、受信機からの問い合わせに応じて、ACR（Automatic Content Recognition）技術を用いたAVコンテンツの識別を行い、その識別結果に応じたトリガ情報を提供する。
【０２０５】
このユースケース４においては、送信機から配信されるAVコンテンツ（図中の「A/V」）として、例えばドラマ等の収録済み番組が送信されている。図１９において、各家庭等に設置された受信機では、A/Vストリームに接続することで、収録済み番組が再生されている。
【０２０６】
受信機は、再生中の収録済み番組のビデオデータ及びオーディオデータの少なくとも一方から抽出される特徴量（以下、「フィンガプリント情報（Finger Print）」という）を、インターネットを介してACRサーバに送信する（Ｓ７１）。このフィンガプリント情報は、例えば数秒周期で、受信機から、ACRサーバに送信される。
【０２０７】
ACRサーバは、受信機からフィンガプリント情報を受信した場合、当該フィンガプリント情報をデータベースと照合することで、受信機で再生中の収録済み番組を、ACR技術を用いて識別し、その識別結果に応じたトリガ情報を生成する。ACRサーバは、ACR識別結果に応じたトリガ情報を、インターネットを介して受信機に送信する。
【０２０８】
なお、ここでは、フィンガプリント情報の代わりに、ウォータマーク情報（Water Mark）を用いるようにしてもよい。ウォータマーク情報を用いた場合、番組のシーンを特定する情報を含めることができるので、その場合には、ACRサーバ側で番組のシーンを特定する必要はない。
【０２０９】
そして、受信機は、インターネットを介してACRサーバから送信されるトリガ情報を受信して取得する（Ｓ７２）。このトリガ情報には、ロケーション情報（Locator）とメディアタイム情報（Media Time）が含まれている。受信機は、トリガ情報に含まれるメディアタイム情報を設定して、当該メディアタイム情報による時刻の計時を開始する（Ｓ７３）。
【０２１０】
また、受信機は、ステップＳ７２の処理で取得したトリガ情報に含まれるロケーション情報に従い、インターネットを介してメタデータサーバに接続し、メタデータのファイルを取得する（Ｓ７４）。このメタデータには、AIT、EMT、及び、CCTが含まれる。AITには、オーガニゼーションID（OrgID）、アプリケーションID（AppID）、アプリケーションURL（App_URL）等のアプリケーション制御情報が含まれる。
【０２１１】
EMTには、アプリケーションごとのアクション情報が時系列で規定されている。図１９のEMTには、アプリケーション１（App1）に対するアクション情報として、時刻T0でのプリフェッチ（Prep）、時刻T1でのエクスキュート（Exec）、時刻T2でのインジェクトイベント（Inj_A_E）、時刻T4でのサスペンド（Susp）、時刻T5でのエクスキュート（Exec）、時刻T6でのキル（Kill）が規定されている。また、図１９のEMTには、アプリケーション２（App2）に対するアクション情報として、時刻T3でのプリフェッチ（Prep）、時刻T4でのエクスキュート（Exec）、時刻T5でのキル（Kill）が規定されている。
【０２１２】
CCTには、アプリケーション１とアプリケーション２について、PUを構成する各ファイルのURL等のキャッシュ制御情報が含まれる。
【０２１３】
ここで、受信機では、ステップＳ７３の処理で、メディアタイム情報による時刻の計時が開始されているが、この計時されている時刻が、EMTのアプリケーションごとのアクション情報に指定された時刻になったかどうか（時刻を経過したかどうか）が常に監視されている。
【０２１４】
そして、計時時刻が、時刻T0となったとき、EMTに規定されたアプリケーション１（App1）に対するプリフェッチアクションを実行するタイミングとなったので、受信機では、アプリケーション１のアプリケーションID（AppID）に従い、AITを参照して、アプリケーション１のアプリケーションURLを取得する（Ｓ７５）。また、受信機は、CCTを参照して、アプリケーション１を構成するファイル群のうち、キャッシュメモリに保持するファイルを決定する。
【０２１５】
受信機は、アプリケーションURL等に従い、インターネットを介してアプリケーションサーバに接続し、アプリケーション１のファイルを取得する（Ｓ７５）。このようにして、受信機では、通信で配信されるアプリケーション１が取得され、キャッシュメモリ（Cache）に保持される。なお、このキャッシュメモリに保持される、アプリケーション１のファイルは、当該キャッシュメモリの容量と、キャッシュ制御情報としてのCCTに基づいたものとなる。
【０２１６】
その後、計時時刻が、時刻T1となったとき、EMTに規定されたアプリケーション１（App1）に対するエクスキュートアクションを実行するタイミングとなったので、受信機では、キャッシュメモリに保持されていたアプリケーション１が読み出され、実行されることになる（Ｓ７６）。これにより、受信機では、収録済み番組に連動して、アプリケーション１が動作することになる。
【０２１７】
なお、それ以降のアプリケーション１の動作については、図１９には図示していないが、計時時刻が、時刻T2になったとき、EMTに規定されたアプリケーション１（App1）に対するインジェクトイベントアクションを実行するタイミングとなるので、受信機では、実行中のアプリケーション１に対するイベントが発火される。
【０２１８】
また、計時時刻が、時刻T3となったとき、EMTに規定されたアプリケーション２（App2）に対するプリフェッチを実行するタイミングとなるので、受信機では、アプリケーション２を取得するためのアプリケーションURLに従い、インターネットを介してアプリケーションサーバに接続し、アプリケーション２のファイルを取得する。このアプリケーション２は、キャッシュメモリ（Cache）に保持される。
【０２１９】
その後、計時時刻が、時刻T4となったとき、EMTに規定されたアプリケーション１（App1）に対するサスペンドアクションと、アプリケーション２（App2）に対するエクスキュートアクションを同時に実行するタイミングとなるので、まず、受信機は、実行中のアプリケーション１を、キャッシュメモリ（Cache）に退避させる。続いて、受信機では、キャッシュメモリに保持されていたアプリケーション２が読み出され、実行されることになる。
【０２２０】
また、計時時刻が、時刻T5となったとき、EMTに規定されたアプリケーション２（App2）に対するキルアクションと、アプリケーション１（App1）に対するエクスキュートアクションを同時に実行するタイミングとなるので、まず、受信機は、実行中のアプリケーション２を終了させる。続いて、受信機では、キャッシュメモリに退避されていたアプリケーション１が読み出され、実行されることになる。
【０２２１】
そして、計時時刻が、時刻T6となったとき、EMTに規定されたアプリケーション１（App1）に対するキルアクションを実行するタイミングとなるので、受信機では、実行中のアプリケーション１が終了させる。これにより、受信機では、収録済み番組に連動して実行されていたアプリケーション１が終了され、収録済み番組のみが表示させる。
【０２２２】
なお、図２０には、ユースケース４における各データの対応関係を示している。図２０においては、トリガ情報は、ビデオストリーム等で伝送されるのではなく、フィンガプリント情報やウォータマーク情報をACRサーバに送信することで、その問い合わせの結果として取得される。
【０２２３】
また、図２０においては、AITやEMT等のメタデータは、トリガ情報に含まれるロケーション情報に従い、取得されることが示されている。また、AITとEMTにおいては、アプリケーションIDが関連付けられている。さらに、アプリケーションは、AITのアプリケーションURLに従い、取得されることが示されている。
【０２２４】
以上、ユースケース４について説明した。
【０２２５】
（５）ユースケース５：ライブ番組に連動したアプリケーションの制御（ACR対応）
【０２２６】
図２１は、ユースケース５を説明する図である。
【０２２７】
図２１においては、上述した図１１等と同様に、放送局（放送事業者）の送信機は、IP伝送方式を用いたデジタル放送の放送波によって、BBPストリームを伝送している。このBBPストリームでは、各サービスを構成するAVコンテンツ（図中の「A/V」）のストリームが、FLUTEセッションで伝送されている。
【０２２８】
また、図２１において、インターネット（Internet）上に設けられたアプリケーションサーバ（Application Server）が、アプリケーションを配信し、メタデータサーバ（Matadata Server）が、メタデータを配信している。また、ACRサーバ（ACR Server）が、ACR技術を用いたAVコンテンツの識別結果に応じたトリガ情報を提供している。
【０２２９】
このユースケース５においては、送信機から配信されるAVコンテンツ（図中の「A/V」）として、例えばスポーツ中継等のライブ番組が送信されている。図２１において、各家庭等に設置された受信機では、A/Vストリームに接続することで、ライブ番組が再生されている。
【０２３０】
図２１において、受信機は、再生中のライブ番組のビデオデータ及びオーディオデータの少なくとも一方から抽出されるフィンガプリント情報を、インターネットを介してACRサーバに送信する（Ｓ８１）。
【０２３１】
ACRサーバは、受信機からフィンガプリント情報を受信した場合、当該フィンガプリント情報をデータベースと照合することで、受信機で再生中のライブ番組を、ACR技術を用いて識別し、その識別結果に応じたトリガ情報を生成する。ACRサーバは、トリガ情報を、インターネットを介して受信機に送信する。なお、フィンガプリント情報の代わりに、ウォータマーク情報を用いるようにしてもよい。
【０２３２】
これにより、受信機は、インターネットを介してACRサーバから送信されるトリガ情報を受信して取得する（Ｓ８２）。このトリガ情報には、ロケーション情報が含まれている。また、ロケーション情報には、アプリケーション１（App1）に対するアクション情報として、プリフェッチアクションが付加されている。受信機は、ステップＳ８２の処理で取得したトリガ情報に含まれるロケーション情報に従い、インターネットを介してメタデータサーバに接続し、メタデータのファイルを取得する（Ｓ８３）。このメタデータには、AIT及びCCTが含まれる。AITには、オーガニゼーションID（OrgID）、アプリケーションID（AppID）、アプリケーションURL（App_URL）等のアプリケーション制御情報が含まれる。CCTには、アプリケーション１等について、PUを構成する各ファイルのURL等のキャッシュ制御情報が含まれる。
【０２３３】
受信機は、トリガ情報に含まれるロケーション情報に付加されたプリフェッチアクションの対象となるアプリケーション１（App1）のアプリケーションID（AppID）に従い、AITを参照して、アプリケーション１のアプリケーションURLを取得する（Ｓ８４）。また、受信機は、CCTを参照して、アプリケーション１を構成するファイル群のうち、キャッシュメモリに保持するファイルを決定する。
【０２３４】
受信機は、アプリケーションURLとアプリケーションアイテムURL（キャッシュメモリに保持するファイルの取得先を示すURL）に従い、インターネットを介してアプリケーションサーバに接続し、アプリケーション１のファイルを取得する（Ｓ８４）。このようにして、受信機では、通信で配信されるアプリケーション１が取得され、キャッシュメモリ（Cache）に保持される。なお、このキャッシュメモリに保持される、アプリケーション１のファイルは、当該キャッシュメモリの容量と、キャッシュ制御情報としてのCCTに基づいたものとなる。
【０２３５】
その後、受信機では、定期的に（例えば数秒周期）、再生中のライブ番組から抽出されるフィンガプリント情報が、インターネットを介してACRサーバに送信され、ACR識別結果に応じたトリガ情報が取得される（Ｓ８５）。このトリガ情報には、ロケーション情報に、アプリケーション１（App1）に対するエクスキュートアクションが付加されている。受信機は、当該トリガ情報に従い、AITを参照して確認した後に、キャッシュメモリに保持されていたアプリケーション１を読み出して、実行する（Ｓ８６）。これにより、受信機では、ライブ番組に連動して、アプリケーション１が動作することになる。
【０２３６】
それ以降のアプリケーション１の動作については、図２１には図示していないが、その後も、受信機では、定期的に（例えば数秒周期）、再生中のライブ番組から抽出されるフィンガプリント情報が、インターネットを介してACRサーバに送信され、トリガ情報が取得される。このトリガ情報において、ロケーション情報に、アプリケーション１（App1）に対するインジェクトイベントアクションが付加されている場合、受信機では、当該トリガ情報に従い、実行中のアプリケーション１に対するイベントが発火される。
【０２３７】
また、取得済みのトリガ情報において、アプリケーション２（App2）に対するプリフェッチアクションが指定されている場合、受信機では、当該トリガ情報に従い、インターネットを介してアプリケーションサーバに接続し、アプリケーション２のファイルが取得され、キャッシュメモリ（Cache）に保持される。
【０２３８】
また、取得済みのトリガ情報において、アプリケーション１（App1）に対するサスペンドアクションと、アプリケーション２（App2）に対するエクスキュートアクションが指定されている場合、実行中のアプリケーション１を、キャッシュメモリに退避させるとともに、キャッシュメモリに保持されていたアプリケーション２が読み出され、実行されることになる。
【０２３９】
また、取得済みのトリガ情報において、アプリケーション２（App2）に対するキルアクションと、アプリケーション１（App1）に対するエクスキュートアクションが指定されている場合、実行中のアプリケーション２を終了させるとともに、キャッシュメモリに退避されていたアプリケーション１が読み出され、その実行が再開されることになる。そして、取得済みのトリガ情報において、アプリケーション１（App1）に対するキルアクションが含まれている場合、受信機では、実行中のアプリケーション１が終了される。
【０２４０】
なお、図２２には、ユースケース５における各データの対応関係を示している。図２２においては、トリガ情報は、ビデオストリーム等で伝送されるのではなく、フィンガプリント情報やウォータマーク情報をACRサーバに送信することで、その問い合わせの結果として取得される。
【０２４１】
また、図２２においては、AIT等のメタデータは、トリガ情報に含まれるロケーション情報に従い、取得されることが示されている。また、アプリケーションは、AITのアプリケーションURLに従い、取得されることが示されている。
【０２４２】
以上、ユースケース５について説明した。
【０２４３】
（６）ユースケース６：SCSシグナリング情報を用いたアプリケーションの制御
【０２４４】
図２３は、ユースケース６を説明する図である。
【０２４５】
図２３においては、上述した図１１等と同様に、放送局（放送事業者）の送信機は、IP伝送方式を用いたデジタル放送の放送波によって、BBPストリームを伝送している。このBBPストリームでは、サービスを構成するAVコンテンツ（図中の「A/V」）やSCSシグナリング情報（図中の「SCS」）、アプリケーション（図中の「NRT」）のストリームが伝送されている。なお、これらのストリームで伝送されるファイルは、FLUTEセッションで伝送されている。
【０２４６】
また、図２３において、インターネット（Internet）上に設けられたアプリケーションサーバ（Application Server）が、アプリケーションを配信している。なお、図２３においては、メタデータサーバ（Matadata Server）が図示されているが、メタデータの配信を行っていないものとする。
【０２４７】
ただし、ユースケース６では、SCSシグナリング情報にメタデータ（AITやCCT等）が含まれている。また、ユースケース６では、トリガ情報を使用しないため、ビデオデータなどにはトリガ情報は埋め込まれておらず、また、トリガ情報を提供可能なACRサーバも設けられていない。
【０２４８】
図２３において、各家庭等に設置された受信機では、A/Vストリームに接続することで、番組が再生されている。受信機は、メモリからSCDを読み出して、SCS Bootstrap情報に従い、放送波で伝送されているSCSストリームに接続して、SCSシグナリング情報を取得する（Ｓ９１）。このSCSシグナリング情報には、USD等のほか、AITとCCTが含まれる。図２３のAITには、オーガニゼーションID（OrgID）、アプリケーションID（AppID）、アプリケーションURL（App_URL）の他に、アクション情報として、プリフェッチ（Prefetch）が含まれている。また、CCTには、アプリケーション１について、PUを構成する各ファイルのURL等のキャッシュ制御情報が含まれる。
【０２４９】
受信機は、AITを参照して、プリフェッチアクションの対象となるアプリケーション１（App1）のアプリケーションID（AppID）に対応する、アプリケーションURLを取得する（Ｓ９２）。また、受信機は、CCTを参照して、アプリケーション１を構成するファイル群のうち、キャッシュメモリに保持するファイルを決定する。
【０２５０】
受信機は、ステップＳ９１の処理で取得したSCSシグナリング情報に含まれるUSDと、アプリケーションURLと、アプリケーションアイテムURL（キャッシュメモリに保持するファイルの取得先を示すURL）に基づいて、アプリケーション１の配信経路が放送又は通信のいずれであるかを判定する。
【０２５１】
そして、アプリケーション１（のファイル）が放送で配信されている場合、受信機は、SCSシグナリング情報に含まれるSDPやFDD等に従い、NRTストリームに接続して、FLUTEセッションで伝送されているアプリケーション１のファイルを取得する（Ｓ９２）。一方、アプリケーション１（のファイル）が通信で配信されている場合、受信機は、アプリケーションURL等に従い、インターネットを介してアプリケーションサーバに接続し、アプリケーション１のファイルを取得する（Ｓ９２）。
【０２５２】
このようにして、受信機では、放送又は通信で配信されるアプリケーション１（のファイル）が取得され、キャッシュメモリ（Cache）に保持される。なお、このキャッシュメモリに保持される、アプリケーション１のファイルは、当該キャッシュメモリの容量と、キャッシュ制御情報としてのCCTに基づいたものとなる。
【０２５３】
その後、受信機では、SCSストリームで伝送されるSCSシグナリング情報に含まれるAITとCCTが更新されたかどうかが監視され、AIT及びCCTの少なくとも一方が更新された場合、当該AIT及びCCTを含むSCSシグナリング情報が取得される（Ｓ９３）。このAITには、アプリケーション１（App1）に対するエクスキュートアクションが指定されている。受信機は、当該AITに従い、キャッシュメモリに保持されていたアプリケーション１を読み出して、実行する（Ｓ９４）。これにより、受信機では、番組に連動して、アプリケーション１が動作することになる。
【０２５４】
また、受信機では、その後もAITとCCTの更新が監視され、AIT及びCCTの少なくとも一方が更新された場合、当該AIT及びCCTを含むSCSシグナリング情報が取得される（Ｓ９５）。このAITには、アプリケーション１（App1）に対するキルアクションが指定されている。受信機は、当該AITに従い、実行中のアプリケーション１を終了させる。これにより、受信機では、番組に連動して実行されていたアプリケーション１が終了され、番組のみが表示される。
【０２５５】
以上、ユースケース６について説明した。
【０２５６】
＜４．システムの構成＞
【０２５７】
（放送通信システムの構成例）
図２４は、放送通信システムの構成例を示す図である。なお、システムとは、複数の構成要素（装置等）の集合を意味する。
【０２５８】
図２４の放送通信システム１は、上述したユースケース１乃至６を実現するための構成を有している。すなわち、図２４において、放送通信システム１は、送信装置１０、受信装置２０、アプリケーションサーバ３０、メタデータサーバ４０、及び、ACRサーバ５０から構成される。また、受信装置２０は、アプリケーションサーバ３０、メタデータサーバ４０、及び、ACRサーバ５０と、インターネット９０を介して相互に接続されている。
【０２５９】
送信装置１０は、収録済み番組やライブ番組等のAVコンテンツとシグナリング情報を、デジタル放送信号により送信する。また、送信装置１０は、トリガ情報、メタデータ、又はアプリケーションを、デジタル放送信号に含めて送信する。なお、送信装置１０は、上述した送信機に対応するものであり、例えば放送事業者により提供され、その放送局内に配置される。
【０２６０】
受信装置２０は、送信装置１０から送信されるデジタル放送信号を受信する。受信装置２０は、デジタル放送信号から得られるシグナリング情報に基づいて、AVコンテンツの映像及び音声を取得し、出力する。また、受信装置２０は、送信装置１０からのデジタル放送信号を受信し、トリガ情報、メタデータ、又はアプリケーションを取得する。
【０２６１】
受信装置２０は、インターネット９０を介してアプリケーションサーバ３０に接続し、アプリケーションを取得する。また、受信装置２０は、インターネット９０を介してメタデータサーバ４０に接続し、メタデータを取得する。
【０２６２】
受信装置２０は、放送又は通信経由で取得したシグナリング情報、トリガ情報、及び、メタデータに基づいて、放送又は通信経由で取得したアプリケーションの動作を制御する。なお、受信装置２０は、上述した受信機に対応するテレビ受像機等であり、家庭内などに配置される。
【０２６３】
アプリケーションサーバ３０は、受信装置２０からの要求に応じて、アプリケーションを、インターネット９０を介して受信装置２０に配信する。なお、アプリケーションサーバ３０は、上述したアプリケーションサーバ（図１１等の「Application Server」）に対応するものであり、例えば、放送事業者等により設置される。
【０２６４】
メタデータサーバ４０は、受信装置２０からの要求に応じて、メタデータを、インターネット９０を介して受信装置２０に配信する。なお、メタデータサーバ４０は、上述したメタデータサーバ（図１１等の「Matadata Server」）に対応するものであり、例えば、放送事業者等により設置される。
【０２６５】
また、受信装置２０は、インターネット９０を介してACRサーバ５０に接続して、トリガ情報を問い合わせる。その際、受信装置２０は、ACRサーバ５０に対して、フィンガプリント情報を送信する。受信装置２０は、ACRサーバ５０から送信されるトリガ情報を取得し、当該トリガ情報に基づいて、アプリケーションの動作を制御する。
【０２６６】
ACRサーバ５０は、受信装置２０からの問い合わせに応じて、フィンガプリント情報に対するACR処理を行い、受信装置２０で再生されているAVコンテンツを識別する。ACRサーバ５０は、ACR識別結果に応じたトリガ情報を生成し、インターネット９０を介して受信装置２０に送信する。なお、ACRサーバ５０は、上述したACRサーバ（図１９等の「ACR Server」）に対応するものであり、例えば、放送事業者等により設置される。
【０２６７】
放送通信システム１は、以上のように構成される。次に、図２４の放送通信システム１を構成する各装置の構成例について説明する。
【０２６８】
（送信装置の構成例）
図２５は、図２４の送信装置の構成例を示す図である。
【０２６９】
図２５において、送信装置１０は、シグナリング情報生成部１１１、シグナリング情報処理部１１２、メタデータ生成部１１３、メタデータ処理部１１４、オーディオデータ取得部１１５、オーディオエンコーダ１１６、ビデオデータ取得部１１７、ビデオエンコーダ１１８、トリガ情報生成部１１９、多重化部１２０、及び、送信部１２１から構成される。
【０２７０】
シグナリング情報生成部１１１は、シグナリング情報を生成し、シグナリング情報処理部１１２に供給する。シグナリング情報処理部１１２は、シグナリング情報生成部１１１から供給されるシグナリング情報を処理し、多重化部１２０に供給する。
【０２７１】
メタデータ生成部１１３は、メタデータを生成し、メタデータ処理部１１４に供給する。メタデータ処理部１１４は、メタデータ生成部１１３から供給されるメタデータを処理し、多重化部１２０に供給する。
【０２７２】
オーディオデータ取得部１１５は、外部のサーバ、マイクロフォン、又は記録媒体等から、AVコンテンツのオーディオデータを取得し、オーディオエンコーダ１１６に供給する。オーディオエンコーダ１１６は、オーディオデータ取得部１１５から供給されるオーディオデータを、MPEG（Moving Picture Experts Group）等の符号化方式に準拠して符号化し、多重化部１２０に供給する。
【０２７３】
ビデオデータ取得部１１７は、外部のサーバ、カメラ、又は記録媒体等から、AVコンテンツのビデオデータを取得し、ビデオエンコーダ１１８、及び、トリガ情報生成部１１９に供給する。ビデオエンコーダ１１８は、ビデオデータ取得部１１７から供給されるビデオデータを、MPEG等の符号化方式に準拠して符号化し、多重化部１２０に供給する。
【０２７４】
トリガ情報生成部１１９は、ビデオデータ取得部１１７から供給されるビデオデータに対応するAVコンテンツの進行にあわせてトリガ情報を生成し、ビデオエンコーダ１１８又は多重化部１２０に供給する。ビデオエンコーダ１１８は、ビデオデータの符号化を行うに際して、ビデオデータに、トリガ情報生成部１１９から供給されるトリガ情報を埋め込んで符号化することができる。
【０２７５】
多重化部１２０は、シグナリング情報処理部１１２からのシグナリング情報と、メタデータ処理部１１４からのメタデータと、オーディオエンコーダ１１６からのオーディオデータと、ビデオエンコーダ１１８からのビデオデータとを多重化して、その結果得られるBBPストリームを、送信部１２１に供給する。
【０２７６】
なお、多重化部１２０は、トリガ情報生成部１１９からトリガ情報が供給された場合には、オーディオデータとビデオデータに、さらにトリガ情報を多重化して、BBPストリームを生成する。また、メタデータは、その配信経路が通信となる場合には、必ずしも送信する必要はなく、その場合には、メタデータをBBPストリームに含めなくてもよい。さらに、図２５の構成では図示していないが、アプリケーションがBBPストリームに含めて送信されるようにしてもよい。
【０２７７】
送信部１２１は、多重化部１２０から供給されるBBPストリームを、アンテナ１２２を介して、デジタル放送信号として送信する。
【０２７８】
なお、図２５においては、トリガ情報を、ビデオデータに埋め込まれる場合と、BBPストリームに多重化される場合を例示したが、例えば、トリガ情報をオーディオデータに埋め込むなど、それ以外の方法によって、トリガ情報を配置するようにしてもよい。
【０２７９】
（受信装置の構成例）
図２６は、図２４の受信装置の構成例を示す図である。
【０２８０】
図２６において、受信装置２０は、チューナ２１２、多重分離部２１３、オーディオデコーダ２１４、オーディオ出力部２１５、ビデオデコーダ２１６、ビデオ出力部２１７、制御部２１８、メモリ２１９、入力部２２０、通信部２２１、アプリケーションエンジン２２２、及び、キャッシュメモリ２２３から構成される。
【０２８１】
チューナ２１２は、アンテナ２１１を介して受信されたデジタル放送信号を選局・復調し、その結果得られるBBPストリームを多重分離部２１３に供給する。多重分離部２１３は、チューナ２１２から供給されるBBPストリームを、オーディオデータと、ビデオデータと、シグナリング情報と、メタデータに分離する。多重分離部２１３は、オーディオデータをオーディオデコーダ、ビデオデータをビデオデコーダ、シグナリング情報及びメタデータを、制御部２１８にそれぞれ供給する。
【０２８２】
オーディオデコーダ２１４は、多重分離部２１３から供給されるオーディオデータを、オーディオエンコーダ１１６（図２５）による符号化方式に対応する復号方式で復号し、その結果得られるオーディオデータを、オーディオ出力部２１５及び制御部２１８に供給する。
【０２８３】
オーディオ出力部２１５は、オーディオデコーダ２１４から供給されるオーディオデータを、スピーカ（不図示）に出力する。スピーカは、オーディオ出力部２１５から供給されるオーディオデータに対応する音声を出力する。
【０２８４】
ビデオデコーダ２１６は、多重分離部２１３から供給されるビデオデータを、ビデオエンコーダ１１８（図２５）による符号化方式に対応する復号方式で復号し、その結果得られるビデオデータを、ビデオ出力部２１７及び制御部２１８に供給する。
【０２８５】
ビデオ出力部２１７は、ビデオデコーダ２１６から供給されるビデオデータを、ディスプレイ（不図示）に出力する。ディスプレイは、ビデオ出力部２１７から供給されるビデオデータに対応する映像を表示する。
【０２８６】
制御部２１８は、チューナ２１２、多重分離部２１３、及び、通信部２２１など、受信装置２０の各部の動作を制御する。メモリ２１９は、制御部２１８から供給される各種のデータを記憶する。入力部２２０は、ユーザからの操作を受け付けて、それに対応する操作信号を制御部２１８に供給する。
【０２８７】
また、制御部２１８は、多重分離部２１３から供給される、シグナリング情報及びメタデータを取得する。さらに、制御部２１８は、オーディオデコーダ２１４から供給されるオーディオデータ、又はビデオデコーダ２１６から供給されるビデオデータに基づいて、トリガ情報を取得したり、フィンガプリント情報を取得したりする。制御部２１８は、フィンガプリント情報を、通信部２２１に供給する。
【０２８８】
通信部２２１は、制御部２１８からの制御に従い、インターネット９０を介してアプリケーションサーバ３０に接続し、アプリケーションを要求する。通信部２２１は、アプリケーションサーバ３０からインターネット９０を介して送信されるアプリケーションを取得し、キャッシュメモリ２２３に保持させる。
【０２８９】
また、通信部２２１は、制御部２１８からの制御に従い、インターネット９０を介してメタデータサーバ４０に接続し、メタデータを要求する。通信部２２１は、メタデータサーバ４０からインターネット９０を介して送信されるメタデータを取得し、制御部２１８に供給する。
【０２９０】
さらに、通信部２２１は、制御部２１８からの制御に従い、インターネット９０を介してACRサーバ５０に接続してフィンガプリント情報を送信し、トリガ情報を問い合わせる。通信部２２１は、ACRサーバ５０からインターネット９０を介して送信されるトリガ情報を取得し、制御部２１８に供給する。
【０２９１】
制御部２１８は、放送又は通信経由で取得したシグナリング情報、トリガ情報、及び、メタデータに基づいて、放送又は通信経由で取得したアプリケーションの動作を制御する。アプリケーションエンジン２２２は、制御部２１８からの制御に従い、キャッシュメモリ２２３に保持されているアプリケーションを読み出して、実行する。また、アプリケーションエンジン２２２は、制御部２１８からの制御に従い、例えば、アプリケーションの休止（中断）、イベント発火、終了などの動作を制御する。
【０２９２】
アプリケーションのビデオデータは、ビデオ出力部２１７に供給される。ビデオ出力部２１７は、アプリケーションエンジン２２２から供給されるビデオデータを、ビデオデコーダ２１６から供給されたビデオデータと合成し、それにより得られる映像を、ディスプレイに表示させる。
【０２９３】
なお、図２６の構成では図示していないが、アプリケーションの配信経路が放送であって、アプリケーションがBBPストリームに含めて送信される場合には、多重分離部２１３により分離されたアプリケーションがキャッシュメモリ２２３に保持されることになる。
【０２９４】
（制御部の構成例）
図２７は、図２６の制御部２１８における、アプリケーションの制御に関する処理を行う部分の機能的構成例を示す図である。
【０２９５】
図２７において、制御部２１８は、シグナリング情報取得部２５１、トリガ情報取得部２５２、メタデータ取得部２５３、フィンガプリント情報取得部２５４、解析部２５５、メディアタイム計時部２５６、及び、アプリケーション制御部２５７から構成される。
【０２９６】
シグナリング情報取得部２５１は、SCS Bootstrap情報に従い、SCSストリームに接続して、SCSシグナリング情報を取得し、解析部２５５に供給する。
【０２９７】
トリガ情報取得部２５２は、ビデオデコーダ２１６から供給されるビデオデータを常に監視して、ビデオデータに埋め込まれているトリガ情報を取得し、解析部２５５に供給する。また、トリガ情報取得部２５２は、トリガ情報にメディアタイム情報が含まれている場合、メディアタイム情報を、メディアタイム計時部２５６に供給する。
【０２９８】
なお、トリガ情報がBBPストリームに配置されている場合には、トリガ情報取得部２５２は、多重分離部２１３により分離されたトリガ情報を含むパケットを監視し、そこからトリガ情報を取得することになる。
【０２９９】
メタデータ取得部２５３は、解析部２５５による解析結果に従い、放送又は通信で配信されるメタデータを取得し、解析部２５５に供給する。
【０３００】
フィンガプリント情報取得部２５４は、オーディオデコーダ２１４から供給されるオーディオデータ、及び、ビデオデコーダ２１６から供給されるビデオデータの少なくとも一方から、フィンガプリント情報を取得（抽出）し、通信部２２１に供給する。通信部２２１は、インターネット９０を介してACRサーバ５０に接続して、フィンガプリント情報を送信する。通信部２２１は、ACRサーバ５０から送信されるトリガ情報を受信し、トリガ情報取得部２５２に供給する。トリガ情報取得部２５２は、通信部２２１から供給されるトリガ情報を取得し、解析部２５５に供給する。
【０３０１】
解析部２５５には、シグナリング情報取得部２５１からのシグナリング情報、トリガ情報取得部２５２からのトリガ情報、メタデータ取得部２５３からのメタデータが供給される。解析部２５５は、シグナリング情報、トリガ情報、及び、メタデータのうちの少なくとも１つの情報の解析を行い、その解析結果を、メタデータ取得部２５３又はアプリケーション制御部２５７に供給する。
【０３０２】
メディアタイム計時部２５６は、トリガ情報取得部２５２から供給されるメディアタイム情報を設定し、当該メディアタイム情報による時刻の計時を行う。
【０３０３】
アプリケーション制御部２５７は、解析部２５５からの解析結果に従い、アプリケーションエンジン２２２（図２６）を制御して、アプリケーションの動作を制御する。
【０３０４】
（各サーバの構成例）
図２８は、図２４の各サーバの構成例を示す図である。図２８には、アプリケーションサーバ３０、メタデータサーバ４０、及び、ACRサーバ５０の構成例が示されている。
【０３０５】
図２８において、アプリケーションサーバ３０は、制御部３１１、アプリケーション生成部３１２、アプリケーション保持部３１３、及び、通信部３１４から構成される。制御部３１１は、アプリケーションサーバ３０の各部の動作を制御する。アプリケーション生成部３１２は、制御部３１１からの制御に従い、AVコンテンツに連動して実行されるアプリケーション（例えばHTMLファイルやJPEGファイル等から構成される）を生成し、アプリケーション保持部３１３に保持させる。
【０３０６】
通信部３１４は、制御部３１１からの制御に従い、インターネット９０を介して受信装置２０と通信を行う。制御部３１１は、通信部３１４の通信状況を常に監視し、受信装置２０からアプリケーションが要求された場合、アプリケーション保持部３１３からアプリケーションを取得して、通信部３１４に供給する。通信部３１４は、制御部３１１からの制御に従い、アプリケーションを、インターネット９０を介して要求元の受信装置２０に送信する。
【０３０７】
アプリケーションサーバ３０は、以上のように構成される。
【０３０８】
図２８において、メタデータサーバ４０は、制御部４１１、メタデータ生成部４１２、メタデータ保持部４１３、及び、通信部４１４から構成される。制御部４１１は、メタデータサーバ４０の各部の動作を制御する。メタデータ生成部４１２は、制御部４１１からの制御に従い、AIT、EMT、及び、CCTのうち、少なくとも１つの情報を含むメタデータを生成し、メタデータ保持部４１３に保持させる。
【０３０９】
通信部４１４は、制御部４１１からの制御に従い、インターネット９０を介して受信装置２０と通信を行う。制御部４１１は、通信部４１４の通信状況を常に監視し、受信装置２０からメタデータが要求された場合、メタデータ保持部４１３からメタデータを取得して、通信部４１４に供給する。通信部４１４は、制御部４１１からの制御に従い、メタデータを、インターネット９０を介して要求元の受信装置２０に送信する。
【０３１０】
メタデータサーバ４０は、以上のように構成される。
【０３１１】
図２８において、ACRサーバ５０は、通信部５１１、ACR識別処理部５１２、FPデータベース５１３、トリガ情報生成部５１４、及び、トリガ情報用データベースから構成される。通信部５１１は、インターネット９０を介して受信装置２０と通信を行う。通信部５１１は、受信装置２０からトリガ情報の問い合わせを受けた場合、フィンガプリント情報を受信して、ACR識別処理部５１２に供給する。
【０３１２】
ACR識別処理部５１２は、通信部５１１から供給されるフィンガプリント情報を、あらかじめ用意されたFPデータベース５１３と照合して、問い合わせ元の受信装置２０で再生中のAVコンテンツを識別するACR識別処理を行う。ACR識別処理部５１２は、ACR識別処理の結果を、トリガ情報生成部５１４に供給する。
【０３１３】
なお、フィンガプリント情報（特徴量）は、例えば、AVコンテンツの全体又は一部構成要素の固有情報であって、FPデータベース５１３には、あらかじめ多数のAVコンテンツの固有情報が登録されている。ACR識別処理では、例えば、それらの固有情報の類似度又は一致度が判定される。また、この類似度又は一致度の判定方法としては、各種の文献などによって開示されている、公知の技術を用いることができる。
【０３１４】
トリガ情報生成部５１４は、ACR識別処理部５１２から供給されるACR識別処理の結果と、トリガ情報用データベース５１５に登録された各種の情報に基づいて、トリガ情報を生成し、通信部５１１に供給する。通信部５１１は、トリガ情報生成部５１４から供給されるトリガ情報を、インターネット９０を介して、問い合わせ元の受信装置２０に送信する。
【０３１５】
ACRサーバ５０は、以上のように構成される。
【０３１６】
＜５．各装置で実行される処理の流れ＞
【０３１７】
次に、図２９乃至図３６のフローチャートを参照して、図２４の放送通信システム１を構成する各装置で実行される処理の流れを説明する。
【０３１８】
（デジタル放送信号送信処理）
まず、図２９のフローチャートを参照して、図２４の送信装置１０により実行されるデジタル放送信号送信処理の流れについて説明する。
【０３１９】
ステップＳ１１１において、シグナリング情報生成部１１１は、シグナリング情報を生成する。ステップＳ１１２において、シグナリング情報処理部１１２は、ステップＳ１１１の処理で生成されたシグナリング情報を処理する。
【０３２０】
ステップＳ１１３において、メタデータ生成部１１３は、メタデータを生成する。ステップＳ１１４において、メタデータ処理部１１４は、ステップＳ１１３の処理で生成されたメタデータを処理する。
【０３２１】
ステップＳ１１５において、オーディオデータ取得部１１５は、外部のサーバ等から、AVコンテンツのオーディオデータを取得する。ステップＳ１１６において、オーディオエンコーダ１１６は、ステップＳ１１５の処理で取得されたオーディオデータを、MPEG等の符号化方式に準拠して符号化する。
【０３２２】
ステップＳ１１７において、ビデオデータ取得部１１７は、外部のサーバ等から、AVコンテンツのビデオデータを取得する。ステップＳ１１８において、トリガ情報生成部１１９は、ステップＳ１１７の処理で取得されたビデオデータに対応するAVコンテンツの進行にあわせてトリガ情報を生成する。
【０３２３】
ステップＳ１１９において、ビデオエンコーダ１１８は、ステップＳ１１７の処理で取得されたビデオデータを、MPEG等の符号化方式に準拠して符号化する。ただし、ビデオエンコーダ１１８は、ビデオデータの符号化を行うに際して、ビデオデータに、トリガ情報生成部１１９から供給されるトリガ情報を埋め込んで符号化を行う。
【０３２４】
ステップＳ１２０において、多重化部１２０は、ステップＳ１１２で処理されたシグナリング情報と、ステップＳ１１４で処理されたメタデータと、ステップＳ１１６で符号化されたオーディオデータと、ステップＳ１１９の処理で符号化されたビデオデータとを多重化して、その結果得られるBBPストリームを、送信部１２１に供給する。
【０３２５】
ステップＳ１２１において、送信部１２１は、ステップＳ１２０の処理で生成されたBBPストリームを、アンテナ１２２を介して、IP伝送方式を用いたデジタル放送信号として送信する。ステップＳ１２１の処理が終了すると、図２９のデジタル放送信号送信処理は終了する。
【０３２６】
以上、デジタル放送信号送信処理の流れについて説明した。なお、図２９のデジタル放送信号送信処理では、説明を簡略化するため、トリガ情報がビデオデータに埋め込まれる場合を一例に説明した。
【０３２７】
（デジタル放送信号受信処理）
次に、図３０のフローチャートを参照して、図２４の受信装置２０により実行されるデジタル放送信号受信処理の流れについて説明する。
【０３２８】
ステップＳ２１１において、チューナ２１２は、アンテナ２１１を介して受信された、IP伝送方式を用いたデジタル放送信号の選局・復調を行う。また、ステップＳ２１２において、多重分離部２１３は、ステップＳ２１１の処理で復調されたBBPストリームから、オーディオデータと、ビデオデータを分離する。
【０３２９】
ステップＳ２１３において、オーディオデコーダ２１４は、ステップＳ２１２の処理で分離されたオーディオデータを、オーディオエンコーダ１１６（図２５）による符号化方式に対応する復号方式で復号する。また、ステップＳ２１４において、ビデオデコーダ２１６は、ステップＳ２１２の処理で分離されたビデオデータを、ビデオエンコーダ１１８（図２５）による符号化方式に対応する復号方式で復号する。
【０３３０】
ステップＳ２１５において、オーディオ出力部２１５は、ステップＳ２１３の処理で復号されたオーディオデータを、スピーカ（不図示）に出力する。また、ステップＳ２１６において、ビデオ出力部２１７は、ステップＳ２１４の処理で復号されたビデオデータを、ディスプレイ（不図示）に出力する。これにより、ディスプレイには、AVコンテンツの映像が表示され、スピーカからは、その映像に同期した音声が出力される。
【０３３１】
ステップＳ２１６の処理が終了すると、図３０のデジタル放送信号受信処理は終了する。
【０３３２】
以上、デジタル放送信号受信処理の流れについて説明した。
【０３３３】
（収録済み番組に連動したアプリケーション制御処理）
次に、図３１のフローチャートを参照して、図２４の受信装置２０により実行される収録済み番組に連動したアプリケーション制御処理の流れについて説明する。なお、この収録済み番組に連動したアプリケーション制御処理に先立って、受信装置２０では、送信装置１０からのデジタル放送信号が受信され、AVコンテンツとして、例えばドラマ等の収録済み番組が再生されているものとする。
【０３３４】
ステップＳ２３１において、シグナリング情報取得部２５１は、SCS Bootstrap情報に従い、SCSストリームに接続して、SCSシグナリング情報を取得する。このSCSシグナリング情報は、解析部２５５により解析される。
【０３３５】
ステップＳ２３２において、トリガ情報取得部２５２は、ビデオデコーダ２１６から供給されるビデオデータを常に監視して、ビデオデータに埋め込まれているトリガ情報を取得する。このトリガ情報は、解析部２５５により解析される。
【０３３６】
ステップＳ２３３において、メディアタイム計時部２５６は、ステップＳ２３２の処理で取得されたトリガ情報の解析結果に従い、メディアタイム情報を設定して、当該メディアタイム情報による時刻の計時を開始する。
【０３３７】
ステップＳ２３４において、メタデータ取得部２５３は、解析部２５５による解析結果に従い、放送又は通信で配信されるメタデータ（AIT、EMT、CCT）を取得する。具体的には、ステップＳ２３１の処理で取得されたSCSシグナリング情報に含まれるUSDと、ステップＳ２３２の処理で取得されたトリガ情報に含まれるロケーション情報に基づいて、メタデータの配信経路が放送又は通信のいずれであるかが判定される。
【０３３８】
そして、メタデータが放送で配信されている場合、メタデータ取得部２５３は、SCSシグナリング情報に含まれるSDPやFDD等に従い、SCSストリームに接続して、FLUTEセッションで伝送されているメタデータのファイルを取得する。一方、メタデータが通信で配信されている場合、メタデータ取得部２５３は、通信部２２１を制御して、トリガ情報に含まれるロケーション情報に従い、インターネット９０を介してメタデータサーバ４０に接続し、メタデータのファイルを取得する。このメタデータは、解析部２５５により解析される。
【０３３９】
ステップＳ２３５においては、メディアタイム計時部２５６による計時時刻が、EMTのリストに規定されたイベントの開始時刻となったかどうかが判定される。ステップＳ２３５において、計時時刻が、EMTのリストに規定されたイベントの開始時刻になっていないと判定された場合、処理は、ステップＳ２３５に戻り、ステップＳ２３５の判定処理が繰り返される。すなわち、ステップＳ２３５においては、計時時刻が、EMTのリストに規定されたイベントの開始時刻になるのを待って、処理は、ステップＳ２３６に進められる。
【０３４０】
ステップＳ２３６において、アプリケーション制御部２５７は、アプリケーションエンジン２２２を制御して、ステップＳ２３５の判定処理で、計時時刻が、開始時刻になったと判定されたイベントに対応するアプリケーションのアクションを実行させる。
【０３４１】
ステップＳ２３７においては、EMTのリストに、実行するイベントが残っているかどうかが判定される。ステップＳ２３７において、実行するイベントが残っていると判定された場合、処理は、ステップＳ２３５に戻り、それ以降の処理が繰り返される。
【０３４２】
すなわち、ステップＳ２３４の処理で、例えば、上述した図１１のEMTが取得された場合、このEMTには、アプリケーション１（App1）に対するアクション情報として、時刻T0でのプリフェッチ（Pref）、時刻T1でのエクスキュート（Exec）、時刻T2でのインジェクトイベント（Inj_A_E）、時刻T4でのサスペンド（Susp）、時刻T5でのエクスキュート（Exec）、時刻T6でのキル（Kill）が規定されている。また、図１１のEMTには、アプリケーション２（App2）に対するアクション情報として、時刻T3でのプリフェッチ（Pref）、時刻T4でのエクスキュート（Exec）、時刻T5でのキル（Kill）が規定されている。
【０３４３】
この場合においては、ステップＳ２３５乃至Ｓ２３７の処理が繰り返されて、メディアタイム計時部２５６による計時時刻が、時刻T0〜T6と一致したタイミングで、対応するイベント、すなわち、アプリケーション１に対するプリフェッチアクションやエクスキュートアクション、アプリケーション２に対するプリフェッチアクションなどが順次実行されることになる。
【０３４４】
ステップＳ２３７において、実行するイベントが残っていないと判定された場合、図３１の収録済み番組に連動したアプリケーション制御処理は終了する。
【０３４５】
以上、収録済み番組に連動したアプリケーション制御処理の流れについて説明した。なお、この収録済み番組に連動したアプリケーション制御処理は、上述したユースケース１、４に対応している。
【０３４６】
（ライブ番組に連動したアプリケーション制御処理）
次に、図３２のフローチャートを参照して、図２４の受信装置２０により実行されるライブ番組に連動したアプリケーション制御処理の流れについて説明する。なお、このライブ番組に連動したアプリケーション制御処理に先立って、受信装置２０では、送信装置１０からのデジタル放送信号が受信され、AVコンテンツとして、例えばスポーツ中継等のライブ番組が再生されているものとする。
【０３４７】
ステップＳ２５１において、シグナリング情報取得部２５１は、SCS Bootstrap情報に従い、SCSストリームに接続して、SCSシグナリング情報を取得する。このSCSシグナリング情報は、解析部２５５により解析される。
【０３４８】
ステップＳ２５２において、トリガ情報取得部２５２は、ビデオデコーダ２１６から供給されるビデオデータを常に監視して、ビデオデータに埋め込まれているトリガ情報を取得する。このトリガ情報は、解析部２５５により解析される。
【０３４９】
ステップＳ２５３において、メタデータ取得部２５３は、解析部２５５による解析結果に従い、放送又は通信で配信されるメタデータ（AIT、CCT）を取得する。具体的には、ステップＳ２５１の処理で取得されたSCSシグナリング情報に含まれるUSDと、ステップＳ２５２の処理で取得されたトリガ情報に含まれるロケーション情報に基づいて、メタデータの配信経路が放送又は通信のいずれであるかが判定される。
【０３５０】
そして、メタデータが放送で配信されている場合、メタデータ取得部２５３は、SCSシグナリング情報に含まれるSDPやFDD等に従い、SCSストリームに接続して、FLUTEセッションで伝送されているメタデータのファイルを取得する。一方、メタデータが通信で配信されている場合、メタデータ取得部２５３は、通信部２２１を制御して、トリガ情報に含まれるロケーション情報に従い、インターネット９０を介してメタデータサーバ４０に接続し、メタデータのファイルを取得する。このメタデータは、解析部２５５により解析される。
【０３５１】
ステップＳ２５４において、アプリケーション制御部２５７は、解析部２５５による解析結果に従い、放送又は通信で配信されるアプリケーションが、アプリケーションエンジン２２２に供給されるようにする。具体的には、ステップＳ２５１の処理で取得されたSCSシグナリング情報に含まれるUSDと、ステップＳ２５３の処理で取得されたアプリケーションURLと、アプリケーションアイテムURL（キャッシュメモリに保持するファイルの取得先を示すURL）に基づいて、アプリケーションの配信経路が放送又は通信のいずれであるかが判定される。
【０３５２】
そして、アプリケーションが放送で配信されている場合、アプリケーション制御部２５７は、SCSシグナリング情報に含まれるSDPやFDD等に従い、NRTストリームに接続して、FLUTEセッションで伝送されているアプリケーションのファイルを取得する。一方、アプリケーションが通信で配信されている場合、アプリケーション制御部２５７は、通信部２２１を制御して、アプリケーションURL等に従い、インターネット９０を介してアプリケーションサーバ３０に接続し、アプリケーションのファイルを取得する。このようにして取得されたアプリケーションは、キャッシュメモリ２２３に保持される。なお、このキャッシュメモリ２２３に保持される、アプリケーションのファイルは、キャッシュメモリ２２３の容量と、キャッシュ制御情報としてのCCTに基づいたものとなる。
【０３５３】
ステップＳ２５５においては、トリガ情報取得部２５２によって、ビデオデコーダ２１６から供給されるビデオデータが常に監視されて、ビデオデータに埋め込まれているトリガ情報が取得されたかどうかが判定される。ステップＳ２５５において、トリガ情報が取得されたと判定された場合、処理は、ステップＳ２５６に進められる。
【０３５４】
ステップＳ２５６において、アプリケーション制御部２５７は、アプリケーションエンジン２２２を制御して、ステップＳ２５５の処理で取得されたトリガ情報に含まれるアプリケーションのアクションを実行させる。なお、ステップＳ２５６の処理が終了すると、処理は、ステップＳ２５７に進められる。また、ステップＳ２５５において、トリガ情報が取得されていないと判定された場合、ステップＳ２５６の処理はスキップされ、処理は、ステップＳ２５７に進められる。
【０３５５】
ステップＳ２５７においては、再生中のライブ番組が終了したかどうかが判定される。ステップＳ２５７において、再生中のライブ番組が終了していないと判定された場合、処理は、ステップＳ２５５に戻り、それ以降の処理が繰り返される。
【０３５６】
そして、ステップＳ２５５乃至Ｓ２５７の処理が繰り返されて、トリガ情報が取得されたタイミングで、当該トリガ情報に含まれるアクション情報に応じて、例えば、アプリケーション１に対するプリフェッチアクションやエクスキュートアクション、アプリケーション２に対するプリフェッチアクションなどが実行されることになる。
【０３５７】
また、ステップＳ２５７において、ライブ番組が終了したと判定された場合、図３２のライブ番組に連動したアプリケーション制御処理は終了する。
【０３５８】
以上、ライブ番組に連動したアプリケーション制御処理の流れについて説明した。なお、このライブ番組に連動したアプリケーション制御処理は、上述したユースケース２、５に対応している。
【０３５９】
（ハイブリッド型のアプリケーション制御処理）
次に、図３３のフローチャートを参照して、図２４の受信装置２０により実行されるハイブリッド型のアプリケーション制御処理の流れについて説明する。なお、受信装置２０では、番組等のAVコンテンツが再生されているものとする。
【０３６０】
ステップＳ２７１において、シグナリング情報取得部２５１は、SCS Bootstrap情報に従い、SCSストリームに接続して、SCSシグナリング情報を取得する。このSCSシグナリング情報は、解析部２５５により解析される。
【０３６１】
ステップＳ２７２において、トリガ情報取得部２５２は、ビデオデコーダ２１６から供給されるビデオデータを常に監視して、ビデオデータに埋め込まれているトリガ情報を取得する。このトリガ情報は、解析部２５５により解析される。
【０３６２】
ステップＳ２７３において、メディアタイム計時部２５６は、ステップＳ２７２の処理で取得されたトリガ情報の解析結果に従い、メディアタイム情報を設定して、当該メディアタイム情報による時刻の計時を開始する。
【０３６３】
ステップＳ２７４において、メタデータ取得部２５３は、解析部２５５による解析結果に従い、放送又は通信で配信されるメタデータ（AIT、EMT、CCT）を取得する。具体的には、ステップＳ２７１の処理で取得されたSCSシグナリング情報に含まれるUSDと、ステップＳ２７２の処理で取得されたトリガ情報に含まれるロケーション情報に基づいて、メタデータの配信経路が放送又は通信のいずれであるかが判定される。
【０３６４】
そして、メタデータが放送で配信されている場合、メタデータ取得部２５３は、SCSシグナリング情報に含まれるSDPやFDD等に従い、SCSストリームに接続して、FLUTEセッションで伝送されているメタデータのファイルを取得する。一方、メタデータが通信で配信されている場合、メタデータ取得部２５３は、通信部２２１を制御して、トリガ情報に含まれるロケーション情報に従い、インターネット９０を介してメタデータサーバ４０に接続し、メタデータのファイルを取得する。このメタデータは、解析部２５５により解析される。
【０３６５】
ステップＳ２７５において、メディアタイム計時部２５６による計時時刻が、EMTのリストに規定されたイベントの開始時刻となったかどうかが判定される。ステップＳ２７５において、計時時刻が、EMTのリストに規定されたイベントの開始時刻になったと判定された場合、ステップＳ２７６に進められる。
【０３６６】
ステップＳ２７６において、アプリケーション制御部２５７は、アプリケーションエンジン２２２を制御して、ステップＳ２７５の判定処理で、計時時刻が、開始時刻になったと判定されたイベントに対応するアプリケーションのアクションを実行させる。なお、ステップＳ２７６の処理が終了すると、処理は、ステップＳ２７７に進められる。また、ステップＳ２７５において、計時時刻が、EMTのリストに規定されたイベントの開始時刻になっていないと判定された場合、ステップＳ２７６の処理はスキップされ、処理は、ステップＳ２７７に進められる。
【０３６７】
ステップＳ２７７においては、ビデオデコーダ２１６から供給されるビデオデータを常に監視して、ビデオデータに埋め込まれているトリガ情報が取得されたかどうかが判定される。ステップＳ２７７において、トリガ情報が取得されたと判定された場合、処理は、ステップＳ２７８に進められる。
【０３６８】
ステップＳ２７８においては、ステップＳ２７７の処理で取得されたトリガ情報にイベント情報が指定されているかどうかが判定される。ステップＳ２７８において、トリガ情報にイベント情報が指定されていると判定された場合、処理は、ステップＳ２７９に進められる。
【０３６９】
ステップＳ２７９において、解析部２５５は、トリガ情報に含まれるイベント情報の編集内容に応じて、EMTの編集を行う。ここでは、例えば、EMTに規定された、アプリケーション１に対するエクスキュートアクションの実行時刻を、時刻T1から時刻T1Aに更新したり、アプリケーション１に対する、時刻T2でのインジェクトイベントアクションを削除したりするなどの編集が行われる。
【０３７０】
一方、ステップＳ２７８において、トリガ情報にイベント情報が指定されていないと判定された場合、処理は、ステップＳ２８０に進められる。ステップＳ２８０において、アプリケーション制御部２５７は、アプリケーションエンジン２２２を制御して、トリガ情報に含まれるアプリケーションのアクションを実行させる。
【０３７１】
なお、ステップＳ２７７において、トリガ情報が取得されていないと判定された場合、ステップＳ２７８乃至Ｓ２８０はスキップされ、処理は、ステップＳ２８１に進められる。また、ステップＳ２７９又はＳ２８０の処理が終了すると、処理は、ステップＳ２８１に進められる。
【０３７２】
ステップＳ２８１においては、再生中の番組が終了したかどうかが判定される。ステップＳ２８１において、再生中の番組が終了していないと判定された場合、処理は、ステップＳ２７５に戻り、それ以降の処理が繰り返される。また、ステップＳ２８１において、再生中の番組が終了したと判定された場合、図３３のハイブリッド型のアプリケーション制御処理は終了する。
【０３７３】
以上、ハイブリッド型のアプリケーション制御処理の流れについて説明した。なお、このハイブリッド型のアプリケーション制御処理は、上述したユースケース３に対応している。
【０３７４】
（アプリケーション配信処理）
次に、図３４のフローチャートを参照して、図２４のアプリケーションサーバ３０により実行されるアプリケーション配信処理の流れについて説明する。
【０３７５】
ステップＳ３１１において、制御部３１１は、通信部３１４の通信状況を常に監視して、受信装置２０からアプリケーションが要求されたかどうかを判定する。ステップＳ３１１において、アプリケーションが要求されていないと判定された場合、ステップＳ３１１の判定処理が繰り返される。すなわち、ステップＳ３１１においては、受信装置２０からアプリケーションが要求されるのを待って、処理は、ステップＳ３１２に進められる。
【０３７６】
ステップＳ３１２において、通信部３１４は、制御部３１１からの制御に従い、アプリケーション保持部３１３に保持されているアプリケーションを取得する。また、ステップＳ３１３において、通信部３１４は、制御部３１１からの制御に従い、ステップＳ３１２の処理で取得されたアプリケーションを、インターネット９０を介して要求元の受信装置２０に送信する。ステップＳ３１３の処理が終了すると、図３４のアプリケーション配信処理は終了する。
【０３７７】
以上、アプリケーション配信処理の流れについて説明した。
【０３７８】
（メタデータ配信処理）
次に、図３５のフローチャートを参照して、図２４のメタデータサーバ４０により実行されるメタデータ配信処理の流れについて説明する。
【０３７９】
ステップＳ４１１において、制御部４１１は、通信部４１４の通信状況を常に監視して、受信装置２０からメタデータが要求されたかどうかを判定する。ステップＳ４１１において、メタデータが要求されていないと判定された場合、ステップＳ４１１の判定処理が繰り返される。すなわち、ステップＳ４１１においては、受信装置２０からメタデータが要求されるのを待って、処理は、ステップＳ４１２に進められる。
【０３８０】
ステップＳ４１２において、通信部４１４は、制御部４１１からの制御に従い、メタデータ保持部４１３に保持されているメタデータを取得する。また、ステップＳ４１３において、通信部４１４は、制御部４１１からの制御に従い、ステップＳ４１２の処理で取得されたメタデータを、インターネット９０を介して要求元の受信装置２０に送信する。ステップＳ４１３の処理が終了すると、図３５のメタデータ配信処理は終了する。
【０３８１】
以上、メタデータ配信処理の流れについて説明した。
【０３８２】
（トリガ情報配信処理）
次に、図３６のフローチャートを参照して、図２４のACRサーバ５０により実行されるトリガ情報配信処理の流れについて説明する。
【０３８３】
ステップＳ５１１においては、受信装置２０からトリガ情報の問い合わせを受け、フィンガプリント情報が受信されたかどうかが判定される。ステップＳ５１１において、フィンガプリント情報が受信されていないと判定された場合、ステップＳ５１１の判定処理が繰り返される。すなわち、ステップＳ５１１においては、通信部５１１によりフィンガプリント情報が受信されるのを待って、処理は、ステップＳ５１２に進められる。
【０３８４】
ステップＳ５１２において、ACR識別処理部５１２は、ステップＳ５１１の処理で受信されたフィンガプリント情報を、あらかじめ用意されたFPデータベース５１３と照合して、問い合わせ元の受信装置２０で再生中のAVコンテンツを識別するACR識別処理を行う。
【０３８５】
ステップＳ５１３において、トリガ情報生成部５１４は、ステップＳ５１２の処理で求められたACR識別処理の結果と、トリガ情報用データベース５１５に登録された各種の情報に基づいて、トリガ情報を生成する。
【０３８６】
ステップＳ５１４において、通信部５１１は、ステップＳ５１３の処理で生成されたトリガ情報を、インターネット９０を介して、問い合わせ元の受信装置２０に送信する。ステップＳ５１４の処理が終了すると、図３６のトリガ情報配信処理は終了する。
【０３８７】
以上、トリガ情報配信処理の流れについて説明した。
【０３８８】
なお、上述した説明では、AVコンテンツとして、収録済み番組やライブ番組等の放送コンテンツを説明したが、放送コンテンツの代わりに、通信コンテンツが、インターネット９０を介してストリーミングサーバ（不図示）からストリーミング配信されるようにしてもよい。
【０３８９】
＜６．コンピュータの構成＞
【０３９０】
上述した一連の処理は、ハードウェアにより実行することもできるし、ソフトウェアにより実行することもできる。一連の処理をソフトウェアにより実行する場合には、そのソフトウェアを構成するプログラムが、コンピュータにインストールされる。図３７は、上述した一連の処理をプログラムにより実行するコンピュータのハードウェアの構成例を示す図である。
【０３９１】
コンピュータ９００において、CPU（Central Processing Unit）９０１、ROM（Read Only Memory）９０２、RAM（Random Access Memory）９０３は、バス９０４により相互に接続されている。バス９０４には、さらに、入出力インターフェース９０５が接続されている。入出力インターフェース９０５には、入力部９０６、出力部９０７、記録部９０８、通信部９０９、及び、ドライブ９１０が接続されている。
【０３９２】
入力部９０６は、キーボード、マウス、マイクロフォンなどよりなる。出力部９０７は、ディスプレイ、スピーカなどよりなる。記録部９０８は、ハードディスクや不揮発性のメモリなどよりなる。通信部９０９は、ネットワークインターフェースなどよりなる。ドライブ９１０は、磁気ディスク、光ディスク、光磁気ディスク、又は半導体メモリなどのリムーバブルメディア９１１を駆動する。
【０３９３】
以上のように構成されるコンピュータ９００では、CPU９０１が、ROM９０２や記録部９０８に記憶されているプログラムを、入出力インターフェース９０５及びバス９０４を介して、RAM９０３にロードして実行することにより、上述した一連の処理が行われる。
【０３９４】
コンピュータ９００（CPU９０１）が実行するプログラムは、例えば、パッケージメディア等としてのリムーバブルメディア９１１に記録して提供することができる。また、プログラムは、ローカルエリアネットワーク、インターネット、デジタル衛星放送といった、有線又は無線の伝送媒体を介して提供することができる。
【０３９５】
コンピュータ９００では、プログラムは、リムーバブルメディア９１１をドライブ９１０に装着することにより、入出力インターフェース９０５を介して、記録部９０８にインストールすることができる。また、プログラムは、有線又は無線の伝送媒体を介して、通信部９０９で受信し、記録部９０８にインストールすることができる。その他、プログラムは、ROM９０２や記録部９０８に、あらかじめインストールしておくことができる。
【０３９６】
ここで、本明細書において、コンピュータがプログラムに従って行う処理は、必ずしもフローチャートとして記載された順序に沿って時系列に行われる必要はない。すなわち、コンピュータがプログラムに従って行う処理は、並列的あるいは個別に実行される処理（例えば、並列処理あるいはオブジェクトによる処理）も含む。また、プログラムは、１のコンピュータ（プロセッサ）により処理されるものであってもよいし、複数のコンピュータによって分散処理されるものであってもよい。
【０３９７】
なお、本技術の実施の形態は、上述した実施の形態に限定されるものではなく、本技術の要旨を逸脱しない範囲において種々の変更が可能である。
【０３９８】
また、本技術は、以下のような構成をとることができる。
【０３９９】
（１）
AV（Audio Video）コンテンツに連動して実行されるアプリケーションの動作を制御するための情報として、ロケーション情報を少なくとも含むトリガ情報を取得する第１の取得部と、
前記アプリケーションの動作を制御するためのアプリケーション制御情報を取得する第２の取得部と、
前記トリガ情報、及び、前記アプリケーション制御情報に基づいて、前記アプリケーションの動作を制御する制御部と
を備える受信装置。
（２）
前記トリガ情報は、前記アプリケーションの動作の制御を行う時刻の基準となる時刻情報を含み、
前記第２の取得部は、前記アプリケーションの動作を時系列で規定したスケジュール制御情報を取得し、
前記制御部は、前記時刻情報を基準に計時された時刻が、前記スケジュール制御情報に規定された時刻を経過したとき、当該時刻に対応した前記アプリケーションに対するアクション情報に応じて、前記アプリケーションの動作を制御する
（１）に記載の受信装置。
（３）
前記アプリケーションは、複数のファイルから構成されており、
前記第２の取得部は、前記アプリケーションを構成するファイル群のキャッシュを制御するためのキャッシュ制御情報を取得し、
前記制御部は、前記キャッシュ制御情報に基づいて、前記アプリケーションを構成するファイル群をキャッシュメモリに保持させる
（２）に記載の受信装置。
（４）
前記トリガ情報は、前記スケジュール制御情報に規定された内容を編集するための編集情報を含み、
前記制御部は、前記編集情報に基づいて、前記スケジュール制御情報を編集する
（２）又は（３）に記載の受信装置。
（５）
前記ロケーション情報は、前記アプリケーション制御情報、前記スケジュール制御情報、及び、前記キャッシュ制御情報を取得するための情報であり、
前記アプリケーション制御情報、前記スケジュール制御情報、及び、前記キャッシュ制御情報は、前記アプリケーションの識別情報により関連付けられている
（３）又は（４）に記載の受信装置。
（６）
前記トリガ情報は、前記アプリケーションに対するアクション情報を含み、
前記制御部は、前記トリガ情報が取得されたとき、当該トリガ情報に含まれる前記アクション情報に応じて、前記アプリケーションの動作を制御する
（１）に記載の受信装置。
（７）
前記アプリケーションは、複数のファイルから構成されており、
前記第２の取得部は、前記アプリケーションを構成するファイル群のキャッシュを制御するためのキャッシュ制御情報を取得し、
前記制御部は、前記キャッシュ制御情報に基づいて、前記アプリケーションを構成するファイル群をキャッシュメモリに保持させる
（６）に記載の受信装置。
（８）
前記ロケーション情報は、前記アプリケーション制御情報、及び、前記キャッシュ制御情報を取得するための情報であり、
前記トリガ情報、前記アプリケーション制御情報、及び、前記キャッシュ制御情報は、前記アプリケーションの識別情報により関連付けられている
（７）に記載の受信装置。
（９）
前記AVコンテンツは、デジタル放送信号で送信される放送コンテンツであり、
前記トリガ情報は、デジタル放送信号に含めて配信されるか、あるいはインターネット上のサーバから配信され、
前記第１の取得部は、放送又は通信で配信される前記トリガ情報を取得する
（１）乃至（８）のいずれかに記載の受信装置。
（１０）
受信装置の受信方法において、
前記受信装置が、
AVコンテンツに連動して実行されるアプリケーションの動作を制御するための情報として、ロケーション情報を少なくとも含むトリガ情報を取得し、
前記アプリケーションの動作を制御するためのアプリケーション制御情報を取得し、
前記トリガ情報、及び、前記アプリケーション制御情報に基づいて、前記アプリケーションの動作を制御する
ステップを含む受信方法。
（１１）
AVコンテンツを取得する取得部と、
前記AVコンテンツに連動して実行されるアプリケーションの動作を制御するための情報として、ロケーション情報を少なくとも含むトリガ情報を生成する第１の生成部と、
前記アプリケーションの動作を制御するためのアプリケーション制御情報を生成する取得する第２の第２の生成部と、
前記AVコンテンツとともに、前記トリガ情報、及び、アプリケーション制御情報を送信する送信部と
を備える送信装置。
（１２）
前記第１の生成部は、前記アプリケーションの動作の制御を行う時刻の基準となる時刻情報を含む前記トリガ情報を生成し、
前記第２の生成部は、前記アプリケーションの動作を時系列で規定したスケジュール制御情報を生成し、
前記送信部は、前記時刻情報を含む前記トリガ情報、及び、前記スケジュール制御情報を送信する
（１１）に記載の送信装置。
（１３）
前記アプリケーションは、複数のファイルから構成されており、
前記第２の生成部は、前記アプリケーションを構成するファイル群のキャッシュを制御するためのキャッシュ制御情報を生成し、
前記送信部は、前記キャッシュ制御情報をさらに送信する
（１２）に記載の送信装置。
（１４）
前記第１の生成部は、前記スケジュール制御情報に規定された内容を編集するための編集情報を含む前記トリガ情報を生成し、
前記送信部は、前記編集情報を含む前記トリガ情報を送信する
（１２）又は（１３）に記載の送信装置。
（１５）
前記ロケーション情報は、前記アプリケーション制御情報、前記スケジュール制御情報、及び、前記キャッシュ制御情報を取得するための情報であり、
前記アプリケーション制御情報、前記スケジュール制御情報、及び、前記キャッシュ制御情報は、前記アプリケーションの識別情報により関連付けられている
（１３）又は（１４）に記載の送信装置。
（１６）
前記第１の生成部は、前記アプリケーションに対するアクション情報を含む前記トリガ情報を生成し、
前記送信部は、前記アクション情報を含む前記トリガ情報を送信する
（１１）に記載の送信装置。
（１７）
前記アプリケーションは、複数のファイルから構成されており、
前記第２の生成部は、前記アプリケーションを構成するファイル群のキャッシュを制御するためのキャッシュ制御情報を生成し、
前記送信部は、前記キャッシュ制御情報をさらに送信する
（１６）に記載の送信装置。
（１８）
前記ロケーション情報は、前記アプリケーション制御情報、及び、前記キャッシュ制御情報を取得するための情報であり、
前記トリガ情報、前記アプリケーション制御情報、及び、前記キャッシュ制御情報は、前記アプリケーションの識別情報により関連付けられている
（１７）に記載の送信装置。
（１９）
前記AVコンテンツは、放送コンテンツであり、
前記送信部は、前記AVコンテンツとともに、前記トリガ情報、及び、アプリケーション制御情報を、デジタル放送信号で送信する
（１１）乃至（１８）のいずれかに記載の送信装置。
（２０）
送信装置の送信方法において、
前記送信装置が、
AVコンテンツを取得し、
前記AVコンテンツに連動して実行されるアプリケーションの動作を制御するための情報として、ロケーション情報を少なくとも含むトリガ情報を生成し、
前記アプリケーションの動作を制御するためのアプリケーション制御情報を生成する取得し、
前記AVコンテンツとともに、前記トリガ情報、及び、アプリケーション制御情報を送信する
ステップを含む送信方法。
【符号の説明】
【０４００】
１  放送通信システム，  １０  送信装置，  ２０  受信装置，  ３０  アプリケーションサーバ，  ４０  メタデータサーバ，  ５０  ACRサーバ，  ９０  インターネット，  １１１  シグナリング情報生成部，  １１３  メタデータ生成部，  １１５  オーディオデータ取得部，  １１７  ビデオデータ取得部，  １１９  トリガ情報生成部，  １２１  送信部，  ２１２  チューナ，  ２１８  制御部，  ２２１  通信部，  ２２２  アプリケーションエンジン，  ２２３  キャッシュメモリ，  ２５１  シグナリング情報取得部，  ２５２  トリガ情報取得部，  ２５３  メタデータ取得部，  ２５４  フィンガプリント情報取得部，  ２５５  解析部，  ２５６  メディアタイム計時部，  ２５７  アプリケーション制御部，  ３１１  制御部，  ３１３  アプリケーション保持部，  ３１４  通信部，  ４１１  制御部，  ４１３  メタデータ保持部，  ４１４  通信部，  ５１１  通信部，  ５１２  ACR識別処理部，  ５１４  トリガ情報生成部，  ９００  コンピュータ，  ９０１  CPU
【図１】
2016017451.tif 000003
【図２】
2016017451.tif 000004
【図３】
2016017451.tif 000005
【図４】
2016017451.tif 000006
【図５】
2016017451.tif 000007
【図６】
2016017451.tif 000008
【図７】
2016017451.tif 000009
【図８】
2016017451.tif 000010
【図９】
2016017451.tif 000011
【図１０】
2016017451.tif 000012
【図１１】
2016017451.tif 000013
【図１２】
2016017451.tif 000014
【図１３】
2016017451.tif 000015
【図１４】
2016017451.tif 000016
【図１５】
2016017451.tif 000017
【図１６】
2016017451.tif 000018
【図１７】
2016017451.tif 000019
【図１８】
2016017451.tif 000020
【図１９】
2016017451.tif 000021
【図２０】
2016017451.tif 000022
【図２１】
2016017451.tif 000023
【図２２】
2016017451.tif 000024
【図２３】
2016017451.tif 000025
【図２４】
2016017451.tif 000026
【図２５】
2016017451.tif 000027
【図２６】
2016017451.tif 000028
【図２７】
2016017451.tif 000029
【図２８】
2016017451.tif 000030
【図２９】
2016017451.tif 000031
【図３０】
2016017451.tif 000032
【図３１】
2016017451.tif 000033
【図３２】
2016017451.tif 000034
【図３３】
2016017451.tif 000035
【図３４】
2016017451.tif 000036
【図３５】
2016017451.tif 000037
【図３６】
2016017451.tif 000038
【図３７】
2016017451.tif 000039
【国際調査報告】
2016017451.tif 000040
2016017451.tif 000041
2016017451.tif 000042
2016017451.tif 000043