(57)【要約】  本技術は、ＡＶコンテンツに連動して実行されるアプリケーションプログラムを提供することができるようにする受信装置、受信方法、プログラム、及び情報処理システムに関する。制御部は、放送波又はACR識別処理の識別結果から得られるトリガ情報に基づきTPTを取得し、取得したTPTに基づいて、トリガ情報に対応するコマンドを特定し、フルート処理部は、特定されたコマンドに応じて、SMT及びNRT-ITにより特定されるFDTを参照して、FLUTEセッションを利用したNRTサービスのNRTコンテンツとして伝送されるデータ放送用アプリを取得し、制御部は、取得されたデータ放送用アプリの動作を制御する。本技術は、例えば、デジタルテレビジョン放送信号を受信するテレビジョン受像機に適用することができる。
2013111630.tif 000002
【特許請求の範囲】
【請求項１】
放送波により伝送されるＡＶコンテンツを受信する受信部と、
受信した前記ＡＶコンテンツに連動して実行されるアプリケーションプログラムを動作させるためのトリガ情報を取得するトリガ取得部と、
前記トリガ情報と、前記アプリケーションプログラムの動作を制御するためのコマンドとを対応付けた対応テーブルを取得するテーブル取得部と、
取得した前記対応テーブルに基づいて、前記トリガ情報に対応する前記コマンドが前記アプリケーションプログラムの取得を示す場合、前記放送波により伝送される前記アプリケーションプログラムを取得するアプリ取得部と、
前記トリガ情報に対応する前記コマンドに応じて、取得した前記アプリケーションプログラムの動作を制御する制御部と
を備える受信装置。
【請求項２】
前記アプリケーションプログラムは、FLUTE（File Delivery over Unidirectional Transport）セッションを利用したNRT（Non-RealTime）サービスのNRTコンテンツとして伝送され、
前記アプリ取得部は、前記対応テーブルに記述された前記アプリケーションプログラムの取得先を示す取得先情報に基づいて、SMT（Service Map Table）及びNRT-IT（NRT Information Table）により特定されるFDT（File Delivery Table）を参照し、FLUTEセッションにより伝送されるアプリケーションプログラムを取得する
請求項１に記載の受信装置。
【請求項３】
前記制御部は、取得する前記アプリケーションプログラムを動作させる上で必要な性能を、前記受信装置が有しているかを確認し、
前記アプリ取得部は、前記受信装置が前記アプリケーションプログラムを動作させる性能を有している場合、FLUTEセッションにより伝送される前記アプリケーションプログラムを取得する
請求項２に記載の受信装置。
【請求項４】
前記アプリ取得部は、FLUTEセッションにより伝送される前記アプリケーションプログラムが取得できない場合、前記NRT-ITに記述される前記取得先情報に基づいて、インターネットを介して配信される前記アプリケーションプログラムを取得する
請求項３に記載の受信装置。
【請求項５】
前記対応テーブルは、前記コマンドと、前記コマンドの有効時刻とを対応付けており、
前記制御部は、前記対応テーブルに基づいて、前記トリガ情報から得られる前記ＡＶコンテンツの進行を示す時刻が、前記コマンドの有効時刻を基準にした所定の有効条件を満たした場合、その有効な前記コマンドに応じて、取得した前記アプリケーションプログラムの動作を制御する
請求項２に記載の受信装置。
【請求項６】
前記トリガ情報は、前記放送波により伝送され、
前記トリガ取得部は、前記放送波により伝送される前記トリガ情報を取得する
請求項５に記載の受信装置。
【請求項７】
受信した前記ＡＶコンテンツのデータから特徴量を抽出する特徴量抽出部をさらに備え、
前記トリガ取得部は、抽出した前記特徴量を用いて識別された前記ＡＶコンテンツの識別結果に対応する前記トリガ情報を取得する
請求項６に記載の受信装置。
【請求項８】
前記制御部は、取得した前記対応テーブルに基づき取得される前記アプリケーションプログラムを動作させる上で必要な性能を、前記受信装置が有しているかを確認し、
前記テーブル取得部は、前記受信装置が前記アプリケーションプログラムを動作させる性能を有していない場合、取得した前記対応テーブルと異なる他の対応テーブルを取得する
請求項５に記載の受信装置。
【請求項９】
前記テーブル取得部は、あらかじめ設定される、前記対応テーブルの取得優先度に応じて、前記対応テーブルを取得する
請求項８に記載の受信装置。
【請求項１０】
前記SMTには、前記NRTサービスの識別情報、並びに前記NRTコンテンツの伝送で用いられるIPアドレス及びポート番号が少なくとも記述され、
前記NRT-ITには、前記NRTサービス及び前記NRTコンテンツの識別情報、並びに前記アプリケーションプログラムの前記取得先情報が少なくとも記述され、
前記FDTには、前記NRTコンテンツの識別情報及びTOI（Transport Object Identifier）が少なくとも記述されており、
前記アプリ取得部は、
前記NRT-ITを参照して、前記対応テーブルに記述された前記取得先情報と一致する前記取得先情報に関連付けられた前記NRTサービス及び前記NRTコンテンツの識別情報を特定し、
前記SMTを参照して、特定した前記NRTサービスの識別情報と一致する識別情報に関連付けられた前記IPアドレス及び前記ポート番号の組み合わせにより特定されるTSI（Transport Session Identifier）のFLUTEセッションから前記FDTを特定し、
前記FDTを参照して、特定した前記NRTコンテンツの識別情報と一致する識別情報に関連付けられたTOIにより識別されるオブジェクトに基づいて、前記アプリケーションプログラムを取得する
請求項２に記載の受信装置。
【請求項１１】
前記コマンドは、前記アプリケーションプログラムの取得若しくは登録、取得若しくは起動、イベント発火、中断、又は終了のうちいずれかを示しており、
前記制御部は、前記コマンドに応じて、前記アプリケーションプログラムの取得若しくは登録、若しくは取得若しくは起動、又は実行中の前記アプリケーションプログラムのイベント発火、休止、若しくは終了を制御する
請求項１に記載の受信装置。
【請求項１２】
受信装置の受信方法において、
前記受信装置が、
放送波により伝送されるＡＶコンテンツを受信し、
受信した前記ＡＶコンテンツに連動して実行されるアプリケーションプログラムを動作させるためのトリガ情報を取得し、
前記トリガ情報と、前記アプリケーションプログラムの動作を制御するためのコマンドとを対応付けた対応テーブルを取得し、
取得した前記対応テーブルに基づいて、前記トリガ情報に対応する前記コマンドが前記アプリケーションプログラムの取得を示す場合、前記放送波により伝送される前記アプリケーションプログラムを取得し、
前記トリガ情報に対応する前記コマンドに応じて、取得した前記アプリケーションプログラムの動作を制御する
ステップを含む受信方法。
【請求項１３】
コンピュータを、
放送波により伝送されるＡＶコンテンツを受信する受信部と、
受信した前記ＡＶコンテンツに連動して実行されるアプリケーションプログラムを動作させるためのトリガ情報を取得するトリガ取得部と、
前記トリガ情報と、前記アプリケーションプログラムの動作を制御するためのコマンドとを対応付けた対応テーブルを取得するテーブル取得部と、
取得した前記対応テーブルに基づいて、前記トリガ情報に対応する前記コマンドが前記アプリケーションプログラムの取得を示す場合、前記放送波により伝送される前記アプリケーションプログラムを取得するアプリ取得部と、
前記トリガ情報に対応する前記コマンドに応じて、取得した前記アプリケーションプログラムの動作を制御する制御部と
して機能させるためのプログラム。
【請求項１４】
受信装置、第１の情報処理装置、及び第２の情報処理装置から構成される情報処理システムにおいて、
前記受信装置は、
放送波により伝送されるＡＶコンテンツを受信する受信部と、
前記放送波により伝送される、受信した前記ＡＶコンテンツに連動して実行されるアプリケーションプログラムを動作させるためのトリガ情報を取得するトリガ取得部と、
前記第１の情報処理装置から、前記トリガ情報と、前記アプリケーションプログラムの動作を制御するためのコマンドとを対応付けた対応テーブルを取得するテーブル取得部と、
取得した前記対応テーブルに基づいて、前記トリガ情報に対応する前記コマンドが前記アプリケーションプログラムの取得を示す場合、前記放送波により伝送される前記アプリケーションプログラムを取得するアプリ取得部と、
前記トリガ情報に対応する前記コマンドに応じて、取得した前記アプリケーションプログラムの動作を制御する制御部と
を備え、
前記アプリ取得部は、前記放送波により伝送される前記アプリケーションプログラムが取得できない場合、前記第２の情報処理装置から前記アプリケーションプログラムを取得し、
前記第１の情報処理装置は、
前記受信装置からの問い合わせに応じて、前記対応テーブルを提供する第１の提供部を備え、
前記第２の情報処理装置は、
前記受信装置からの問い合わせに応じて、前記アプリケーションプログラムを提供する第２の提供部を備える
情報処理システム。
【請求項１５】
受信装置、第１の情報処理装置、第２の情報処理装置、及び第３の情報処理装置から構成される情報処理システムにおいて、
前記受信装置は、
放送波により伝送されるＡＶコンテンツを受信する受信部と、
受信した前記ＡＶコンテンツのデータから特徴量を抽出する特徴量抽出部と、
受信した前記ＡＶコンテンツに連動して実行されるアプリケーションプログラムを動作させるためのトリガ情報であって、前記第１の情報処理装置にて前記特徴量を用いて識別された前記ＡＶコンテンツの識別結果に対応する前記トリガ情報を取得するトリガ取得部と、
前記第２の情報処理装置から、前記トリガ情報と、前記アプリケーションプログラムの動作を制御するためのコマンドとを対応付けた対応テーブルを取得するテーブル取得部と、
取得した前記対応テーブルに基づいて、前記トリガ情報に対応する前記コマンドが前記アプリケーションプログラムの取得を示す場合、前記放送波により伝送される前記アプリケーションプログラムを取得するアプリ取得部と、
前記トリガ情報に対応する前記コマンドに応じて、取得した前記アプリケーションプログラムの動作を制御する制御部と
を備え、
前記アプリ取得部は、前記放送波により伝送される前記アプリケーションプログラムが取得できない場合、前記第３の情報処理装置から前記アプリケーションプログラムを取得し、
前記第１の情報処理装置は、
前記受信装置からの前記特徴量を用いて識別された前記ＡＶコンテンツの識別結果に対応する前記トリガ情報を提供する第１の提供部を備え、
前記第２の情報処理装置は、
前記受信装置からの問い合わせに応じて、前記対応テーブルを提供する第２の提供部を備え、
前記第３の情報処理装置は、
前記受信装置からの問い合わせに応じて、前記アプリケーションプログラムを提供する第３の提供部を備える
情報処理システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本技術は、受信装置、受信方法、プログラム、及び情報処理システムに関し、特に、ＡＶコンテンツに連動して実行されるアプリケーションプログラムを提供することができるようにした受信装置、受信方法、プログラム、及び情報処理システムに関する。
【背景技術】
【０００２】
デジタルテレビジョン放送信号を受信する受信装置において、放送波やインターネットに接続されたサーバにより配信される、テレビ番組と連動して実行されるアプリケーションプログラムを提供するサービスが普及することが予想される。そのため、このようなサービスを実現するための技術の検討が行われている（例えば、特許文献１参照）。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２０１１−６６５５６号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
しかしながら、現状では、放送波やインターネットを介して配信されるアプリケーションプログラムを提供するための技術方式は確立されていない。【０００５】
本技術はこのような状況に鑑みてなされたものであり、ＡＶコンテンツに連動して実行されるアプリケーションプログラムを提供することができるようにするものである。
【課題を解決するための手段】
【０００６】
本技術の第１の側面の受信装置は、放送波により伝送されるＡＶコンテンツを受信する受信部と、受信した前記ＡＶコンテンツに連動して実行されるアプリケーションプログラムを動作させるためのトリガ情報を取得するトリガ取得部と、前記トリガ情報と、前記アプリケーションプログラムの動作を制御するためのコマンドとを対応付けた対応テーブルを取得するテーブル取得部と、取得した前記対応テーブルに基づいて、前記トリガ情報に対応する前記コマンドが前記アプリケーションプログラムの取得を示す場合、前記放送波により伝送される前記アプリケーションプログラムを取得するアプリ取得部と、前記トリガ情報に対応する前記コマンドに応じて、取得した前記アプリケーションプログラムの動作を制御する制御部とを備える。【０００７】
前記アプリケーションプログラムは、FLUTE（File Delivery over Unidirectional Transport）セッションを利用したNRT（Non-RealTime）サービスのNRTコンテンツとして伝送され、前記アプリ取得部は、前記対応テーブルに記述された前記アプリケーションプログラムの取得先を示す取得先情報に基づいて、SMT（Service Map Table）及びNRT-IT（NRT Information Table）により特定されるFDT（File Delivery Table）を参照し、FLUTEセッションにより伝送されるアプリケーションプログラムを取得する。【０００８】
前記制御部は、取得する前記アプリケーションプログラムを動作させる上で必要な性能を、前記受信装置が有しているかを確認し、前記アプリ取得部は、前記受信装置が前記アプリケーションプログラムを動作させる性能を有している場合、FLUTEセッションにより伝送される前記アプリケーションプログラムを取得する。【０００９】
前記アプリ取得部は、FLUTEセッションにより伝送される前記アプリケーションプログラムが取得できない場合、前記NRT-ITに記述される前記取得先情報に基づいて、インターネットを介して配信される前記アプリケーションプログラムを取得する。【００１０】
前記対応テーブルは、前記コマンドと、前記コマンドの有効時刻とを対応付けており、前記制御部は、前記対応テーブルに基づいて、前記トリガ情報から得られる前記ＡＶコンテンツの進行を示す時刻が、前記コマンドの有効時刻を基準にした所定の有効条件を満たした場合、その有効な前記コマンドに応じて、取得した前記アプリケーションプログラムの動作を制御する。【００１１】
前記トリガ情報は、前記放送波により伝送され、前記トリガ取得部は、前記放送波により伝送される前記トリガ情報を取得する。【００１２】
受信した前記ＡＶコンテンツのデータから特徴量を抽出する特徴量抽出部をさらに備え、前記トリガ取得部は、抽出した前記特徴量を用いて識別された前記ＡＶコンテンツの識別結果に対応する前記トリガ情報を取得する。【００１３】
前記制御部は、取得した前記対応テーブルに基づき取得される前記アプリケーションプログラムを動作させる上で必要な性能を、前記受信装置が有しているかを確認し、前記テーブル取得部は、前記受信装置が前記アプリケーションプログラムを動作させる性能を有していない場合、取得した前記対応テーブルと異なる他の対応テーブルを取得する。【００１４】
前記テーブル取得部は、あらかじめ設定される、前記対応テーブルの取得優先度に応じて、前記対応テーブルを取得する。【００１５】
前記SMTには、前記NRTサービスの識別情報、並びに前記NRTコンテンツの伝送で用いられるIPアドレス及びポート番号が少なくとも記述され、前記NRT-ITには、前記NRTサービス及び前記NRTコンテンツの識別情報、並びに前記アプリケーションプログラムの前記取得先情報が少なくとも記述され、前記FDTには、前記NRTコンテンツの識別情報及びTOI（Transport Object Identifier）が少なくとも記述されており、前記アプリ取得部は、前記NRT-ITを参照して、前記対応テーブルに記述された前記取得先情報と一致する前記取得先情報に関連付けられた前記NRTサービス及び前記NRTコンテンツの識別情報を特定し、前記SMTを参照して、特定した前記NRTサービスの識別情報と一致する識別情報に関連付けられた前記IPアドレス及び前記ポート番号の組み合わせにより特定されるTSI（Transport Session Identifier）のFLUTEセッションから前記FDTを特定し、前記FDTを参照して、特定した前記NRTコンテンツの識別情報と一致する識別情報に関連付けられたTOIにより識別されるオブジェクトに基づいて、前記アプリケーションプログラムを取得する。【００１６】
前記コマンドは、前記アプリケーションプログラムの取得若しくは登録、取得若しくは起動、イベント発火、中断、又は終了のうちいずれかを示しており、前記制御部は、前記コマンドに応じて、前記アプリケーションプログラムの取得若しくは登録、若しくは取得若しくは起動、又は実行中の前記アプリケーションプログラムのイベント発火、休止、若しくは終了を制御する。【００１７】
本技術の第１の側面の受信方法又はプログラムは、前述した本技術の第１の側面の受信装置に対応する受信方法又はプログラムである。【００１８】
本技術の第１の側面の受信装置、受信方法、及びプログラムにおいては、放送波により伝送されるＡＶコンテンツが受信され、受信されたＡＶコンテンツに連動して実行されるアプリケーションプログラムを動作させるためのトリガ情報が取得され、トリガ情報と、アプリケーションプログラムの動作を制御するためのコマンドとを対応付けた対応テーブルが取得され、取得された対応テーブルに基づいて、トリガ情報に対応するコマンドがアプリケーションプログラムの取得を示す場合、放送波により伝送されるアプリケーションプログラムが取得され、トリガ情報に対応するコマンドに応じて、取得されたアプリケーションプログラムの動作が制御される。【００１９】
本技術の第２の側面の情報処理システムは、受信装置、第１の情報処理装置、及び第２の情報処理装置から構成される情報処理システムにおいて、前記受信装置は、放送波により伝送されるＡＶコンテンツを受信する受信部と、前記放送波により伝送される、受信した前記ＡＶコンテンツに連動して実行されるアプリケーションプログラムを動作させるためのトリガ情報を取得するトリガ取得部と、前記第１の情報処理装置から、前記トリガ情報と、前記アプリケーションプログラムの動作を制御するためのコマンドとを対応付けた対応テーブルを取得するテーブル取得部と、取得した前記対応テーブルに基づいて、前記トリガ情報に対応する前記コマンドが前記アプリケーションプログラムの取得を示す場合、前記放送波により伝送される前記アプリケーションプログラムを取得するアプリ取得部と、前記トリガ情報に対応する前記コマンドに応じて、取得した前記アプリケーションプログラムの動作を制御する制御部とを備え、前記アプリ取得部は、前記放送波により伝送される前記アプリケーションプログラムが取得できない場合、前記第２の情報処理装置から前記アプリケーションプログラムを取得し、前記第１の情報処理装置は、前記受信装置からの問い合わせに応じて、前記対応テーブルを提供する第１の提供部を備え、前記第２の情報処理装置は、前記受信装置からの問い合わせに応じて、前記アプリケーションプログラムを提供する第２の提供部を備える。【００２０】
本技術の第２の側面の情報処理システムにおいては、受信装置によって、放送波により伝送されるＡＶコンテンツが受信され、放送波により伝送される、受信されたＡＶコンテンツに連動して実行されるアプリケーションプログラムを動作させるためのトリガ情報が取得され、第１の情報処理装置から、トリガ情報と、アプリケーションプログラムの動作を制御するためのコマンドとを対応付けた対応テーブルが取得され、取得された対応テーブルに基づいて、トリガ情報に対応するコマンドがアプリケーションプログラムの取得を示す場合、放送波により伝送されるアプリケーションプログラムが取得され、トリガ情報に対応するコマンドに応じて、取得されたアプリケーションプログラムの動作が制御され、放送波により伝送されるアプリケーションプログラムが取得できない場合、第２の情報処理装置からアプリケーションプログラムが取得され、第１の情報処理装置によって、受信装置からの問い合わせに応じて、対応テーブルが提供され、第２の情報処理装置によって、受信装置からの問い合わせに応じて、アプリケーションプログラムが提供される。【００２１】
本技術の第３の側面の情報処理システムは、受信装置、第１の情報処理装置、第２の情報処理装置、及び第３の情報処理装置から構成される情報処理システムにおいて、前記受信装置は、放送波により伝送されるＡＶコンテンツを受信する受信部と、受信した前記ＡＶコンテンツのデータから特徴量を抽出する特徴量抽出部と、受信した前記ＡＶコンテンツに連動して実行されるアプリケーションプログラムを動作させるためのトリガ情報であって、前記第１の情報処理装置にて前記特徴量を用いて識別された前記ＡＶコンテンツの識別結果に対応する前記トリガ情報を取得するトリガ取得部と、前記第２の情報処理装置から、前記トリガ情報と、前記アプリケーションプログラムの動作を制御するためのコマンドとを対応付けた対応テーブルを取得するテーブル取得部と、取得した前記対応テーブルに基づいて、前記トリガ情報に対応する前記コマンドが前記アプリケーションプログラムの取得を示す場合、前記放送波により伝送される前記アプリケーションプログラムを取得するアプリ取得部と、前記トリガ情報に対応する前記コマンドに応じて、取得した前記アプリケーションプログラムの動作を制御する制御部とを備え、前記アプリ取得部は、前記放送波により伝送される前記アプリケーションプログラムが取得できない場合、前記第３の情報処理装置から前記アプリケーションプログラムを取得し、前記第１の情報処理装置は、前記受信装置からの前記特徴量を用いて識別された前記ＡＶコンテンツの識別結果に対応する前記トリガ情報を提供する第１の提供部を備え、前記第２の情報処理装置は、前記受信装置からの問い合わせに応じて、前記対応テーブルを提供する第２の提供部を備え、前記第３の情報処理装置は、前記受信装置からの問い合わせに応じて、前記アプリケーションプログラムを提供する第３の提供部を備える。【００２２】
本技術の第３の側面の情報処理システムにおいては、受信装置によって、放送波により伝送されるＡＶコンテンツが受信され、受信されたＡＶコンテンツのデータから特徴量が抽出され、受信されたＡＶコンテンツに連動して実行されるアプリケーションプログラムを動作させるためのトリガ情報であって、第１の情報処理装置にて特徴量を用いて識別されたＡＶコンテンツの識別結果に対応するトリガ情報が取得され、第２の情報処理装置から、トリガ情報と、アプリケーションプログラムの動作を制御するためのコマンドとを対応付けた対応テーブルが取得され、取得された対応テーブルに基づいて、トリガ情報に対応するコマンドがアプリケーションプログラムの取得を示す場合、放送波により伝送されるアプリケーションプログラムが取得され、トリガ情報に対応するコマンドに応じて、取得したアプリケーションプログラムの動作が制御され、放送波により伝送されるアプリケーションプログラムが取得できない場合、第３の情報処理装置からアプリケーションプログラムが取得され、第１の情報処理装置によって、受信装置からの特徴量を用いて識別されたＡＶコンテンツの識別結果に対応するトリガ情報が提供され、第２の情報処理装置によって、受信装置からの問い合わせに応じて、対応テーブルが提供され、第３の情報処理装置によって、受信装置からの問い合わせに応じて、アプリケーションプログラムが提供される。
【発明の効果】
【００２３】
本技術の第１の側面乃至第３の側面によれば、ＡＶコンテンツに連動して実行されるアプリケーションプログラムを提供することができる。
【図面の簡単な説明】
【００２４】
【図１】本技術の基本概念を説明した図である。
【図２】放送ストリームの構成を示す図である。
【図３】FLUTEのプロトコルスタックを説明する図である。
【図４】FLUTEによるセッション管理を説明する図である。
【図５】ヘッダのフォーマットの例を示す図である。
【図６】FDTパケットのフォーマットの例を示す図である。
【図７】FDTのスキーマの例を示す図である。
【図８】FDTのスキーマの例を示す図である。
【図９】FDT Instanceの記述例を示す図である。
【図１０】本技術を適用した放送システムの一実施の形態の構成を示す図である。
【図１１】本技術を適用した受信装置の一実施の形態の構成を示す図である。
【図１２】トリガ情報に含まれる情報の項目の一例を示す図である。
【図１３】TPTのフォーマットの例を示す図である。
【図１４】capability要素に指定される値の具体例を示す図である。
【図１５】TPTの記述例を示す図である。
【図１６】トリガ情報とコマンドの対応関係の例を示す図である。
【図１７】データ放送用アプリの状態遷移を示す図である。
【図１８】放送波により伝送されるテーブルの例を示す図である。
【図１９】トリガ情報対応処理を説明するフローチャートである。
【図２０】アプリ制御処理を説明するフローチャートである。
【図２１】アプリ取得処理を説明するフローチャートである。
【図２２】TPTファイルの階層構造を示す図である。
【図２３】クラスに対応したTPTのフォーマットの例を示す図である。
【図２４】クラスに対応したTPTの記述例を示す図である。
【図２５】TPT取得処理を説明するフローチャートである。
【図２６】本技術を適用した放送システムの一実施の形態の構成を示す図である。
【図２７】本技術を適用した受信装置の一実施の形態の構成を示す図である。
【図２８】トリガ情報とコマンドの対応関係の例を示す図である。
【図２９】トリガ情報対応処理を説明するフローチャートである。
【図３０】トリガ情報とコマンドの対応関係の例を示す図である。
【図３１】tpt要素のtype属性を説明する図である。
【図３２】type属性に“static”が指定される場合の運用例を説明する図である。
【図３３】type属性に“static”が指定される場合の運用例を説明する図である。
【図３４】type属性に“dynamic”が指定される場合の運用例を説明する図である。
【図３５】コンピュータの構成例を示す図である。
【発明を実施するための形態】
【００２５】
以下、図面を参照しながら本技術の実施の形態について説明する。
【００２６】
［本技術の基本概念］
図１は、本技術の基本概念を説明した図である。
【００２７】
本技術は、放送波やインターネットに接続されたサーバにより配信されるデータ放送用アプリを、受信機に提供するためのものである。ここで、データ放送用アプリ（App）とは、テレビ番組やＣＭ等のＡＶコンテンツに連動して実行されるデータ放送用のアプリケーションプログラムである。
【００２８】
データ放送用アプリは、トリガ情報（Trigger）及びTPT（Trigger Parameter Table）に基づき特定されるコマンドに応じて、その動作が制御される。トリガ情報は、データ放送用アプリを動作させるための情報である。トリガ情報は、放送波に含めて送られる場合と、ACR識別処理の識別結果から得られる場合とがある。ACR（Automatic Content Recognition）とは、ＡＶコンテンツから得られる特徴量を用いて当該コンテンツを識別する技術である。
【００２９】
また、TPTとは、データ放送用アプリを制御するためのコマンドと、当該コマンドの有効期間を対応付けた対応テーブルである。コマンドの有効期間は、ＡＶコンテンツの進行にあわせて決定される。受信機は、TPTに基づいて、トリガ情報に対応するコマンドを特定し、当該コマンドに応じて、放送波又はインターネット上のサーバからデータ放送用アプリを取得する。
【００３０】
ここで、放送波で伝送されるデータ放送用アプリの取得方法について説明する。図２は、放送ストリームの構成を示す図である。
【００３１】
放送ストリームは、映像ストリーム及び音声ストリームのほか、PSIP、SMT、NRT-IT、及びFLUTEから構成される。映像ストリーム又は音声ストリームには、トリガ情報が挿入される。
【００３２】
PSIP（Program and System Information Protocol）は、特定のチャンネルを選択して受信する際に必要な制御情報や番組情報などの情報を送信する。受信機は、PSIPから得られる情報などに基づいて、例えば、NRTサービスにより提供されるNRTコンテンツのリストを生成する。ここで、NRT（Non-RealTime）サービスとは、NRT放送にて伝送されたNRTコンテンツを一旦受信機のストレージに蓄積した後で、再生を行うサービスである。
【００３３】
SMT（Service Map Table）は、トランスポートストリームに含まれるNRTサービスのサービスレベルの属性情報を示す。また、NRT-IT（NRT Information Table）は、１つのNRTサービスに含まれるコンテンツレベルの属性情報を示す。SMT及びNRT-ITは、トランスポートストリームにおいて固定のIPアドレスとUDPポートにて伝送されるSSC（Service Signaling Channel）に含まれる。ここでは、例えば、IPアドレスとして224.0.23.60が、ポート番号として4937が、それぞれ用いられる。
【００３４】
受信機は、SMT及びNRT-ITを参照することで、所望のNRTコンテンツの放送ストリームにおける取得位置（例えば時間位置など）を特定することが可能となる。
【００３５】
FLUTE（File Delivery over Unidirectional Transport）は、放送波により伝送されるファイルのセッション管理を行うプロトコルである。ここで、図３に示すように、FLUTEは、最も下位の階層となる物理層、さらにその上位の階層となるTS（Transport Stream）、IP（Internet Protocol）、及びUDP（User Datagram Protocol）の各層の上位の階層に位置する。また、FLUTEの上位の階層としては、NRTコンテンツ等の各種ファイルが位置する。すなわち、NRT放送においては、IP通信におけるUDPのポートが指定されたIPパケットが送信され、FLUTEによるセッションが確立されるようになされている。そして、FLUTEセッションにより、NRTコンテンツ等を構成するファイルが特定されることになる。
【００３６】
また、図３に示すように、FLUTEは、FEC（Forward Error Correction）、LCT（Layered Coding Transport）、ALC（Asynchronous Layered Coding）、FLUTEのプロトコルスタックを総称するものである。なお、FLUTEの詳細は、RFC3926として規定されている。FEC、LCT、ALCの詳細についてもそれぞれ、RFC3452、RFC3451、RFC3450として規定されている。ただし、FECは携帯端末での移動受信時等でのデータ消失耐性を高めるために適用されるものであり、固定端末での受信時には必ずしも適用する必要はない。また、FECアルゴリズムについては任意の方式を適用することができる。
【００３７】
ところで、FLUTEでは、送信するファイルなどを１つのオブジェクトとして、TOI（Transport Object Identifier）により管理する。また、複数のオブジェクトの集合を１つのセッションとして、TSI（Transport Session Identifier）により管理する。
【００３８】
図４は、FLUTEによるセッション管理を説明する図である。
【００３９】
図４に示すように、送信機から受信機に送信される各オブジェクトは、ALC/LCTのヘッダ等が付加されたIPパケットに格納されて送信される。当該ヘッダには、図５に示すように、Transport Session Identifier（TSI）として、各セッションの識別情報が記述される。また、当該ヘッダには、Transport Object Identifier（TOI）として、各セッションごとに送られる複数のオブジェクトの識別情報が記述される。すなわち、FLUTEによるセッションにおいては、TSIとTOIの２つの識別情報により特定のファイルを指定することが可能となる。
【００４０】
また、FLUTEによるセッションでは、NRTサービスのファイルの各種の属性情報を送るためのFDT（File Delivery Table）が周期的に送信される。FDTは、図６に示すように、TOI = 0のファイルとしてTSIごとに送信されるものであり、当該FDTには、TSIごとのインデックス情報が記述される。また、FDTは、FDTを伝送するためのオブジェクトであるFDT Instanceにより伝送される。従って、図６に示すように、FDTのパケットにはFDT Instanceが格納される。なお、FDTのスキーマとしては、例えば、図７及び図８に示すような情報が定義される。
【００４１】
また、図９は、FDT Instanceの記述例を示す図である。なお、FDT Instanceの記述方法は任意であって、図９の記述例に限定されるものではない。
【００４２】
このように、NRTコンテンツは、複数のファイルから構成されることが多いので、受信機は、FDTに記述されたインデックス情報を用いて、複数のファイルからNRTコンテンツを復元することになる。すなわち、受信機は、FLUTEセッションを利用することで、放送ストリームに含まれるIPパケットによって、NRTコンテンツをダウンロードすることが可能となる。そして、本技術では、NRTコンテンツが伝送される方法と同様に、FLUTEセッションを利用して、データ放送用アプリを伝送することになる。
【００４３】
すなわち、受信機は、放送波にて伝送されるデータ放送用アプリを、FLUTEセッションを利用して取得する。ただし、データ放送用アプリは、原則として放送波にて伝送されるものであるが、何らかの原因により、受信機側で取得できない場合も想定される。その場合には、受信機は、インターネットを介してアプリサーバにアクセスして、当該アプリサーバにより提供されるデータ放送用アプリを取得する。
【００４４】
以上、本技術の基本概念について説明してきたが、放送波にて伝送されるデータ放送用アプリを取得する前提として、受信機は、トリガ情報を取得する必要がある。このトリガ情報の取得方法としては、放送波に含めて送られるトリガ情報（Trigger）を取得する方法と、ACR識別処理の識別結果に応じたトリガ情報（ACR Response）を取得する方法の２通りの方法がある。従って、以下、前者の方法によりトリガ情報を取得する場合を第１の実施の形態で、後者の方法によりトリガ情報を取得する場合を第２の実施の形態でそれぞれ説明する。
【００４５】
＜第１の実施の形態＞
［放送システムの構成例］
図１０は、第１の実施の形態である放送システム１を示している。この放送システム１は、放送装置１１、受信装置１２、TPTサーバ１３、及びアプリサーバ１４から構成される。また、受信装置１２、TPTサーバ１３、及びアプリサーバ１４は、インターネット２０を介して、相互に接続されている。
【００４６】
放送装置１１は、テレビ番組やＣＭ等のＡＶコンテンツのデジタルテレビジョン放送信号（以下、単に放送信号という）を送信するようになされている。また、放送装置１１は、ＡＶコンテンツに連動して実行されるデータ放送用アプリを動作させるためのトリガ情報を、放送信号に含めて送信する。トリガ情報は、ＡＶコンテンツの映像信号又は音声信号に挿入したり、放送信号のトランスポートストリーム内に配置したりして送信される。
【００４７】
受信装置１２は、放送装置１１から送信された放送信号を受信して、ＡＶコンテンツの映像及び音声を取得する。受信装置１２は、取得した映像をディスプレイに出力するとともに、音声をスピーカに出力する。なお、受信装置１２は、単体として存在してもよいし、例えば、テレビジョン受像機やビデオレコーダ等に内蔵されているようにしてもよい。
【００４８】
また、受信装置１２は、放送装置１１からのトリガ情報に応じて、インターネット２０を介してTPTサーバ１３にアクセスして、TPTを取得する。
【００４９】
TPTサーバ１３は、例えば放送装置１１にてテレビ番組の放送を行う放送事業者等により提供され、TPTを管理する。TPTサーバ１３は、受信装置１２からの問い合わせに応じて、管理しているTPTを、インターネット２０を介して受信装置１２に提供する。
【００５０】
受信装置１２は、TPTサーバ１３から取得したTPTに基づいて、トリガ情報から得られるＡＶコンテンツの進行を示す時刻が有効期間内となるか、又は有効開始時刻を経過した場合、その有効なコマンドを特定する。受信装置１２は、特定したコマンドに応じて、データ放送用アプリの動作を制御する。
【００５１】
また、受信装置１２は、特定したコマンドに応じて、放送波により伝送されるデータ放送用アプリを取得する。ただし、放送波からデータ放送用アプリを取得できなかった場合には、受信装置１２は、インターネット２０を介してアプリサーバ１４にアクセスして、データ放送用アプリを取得する。
【００５２】
アプリサーバ１４は、例えば放送装置１１にてテレビ番組の放送を行う放送事業者等により提供され、データ放送用アプリを管理する。アプリサーバ１４は、受信装置１２からの問い合わせに応じて、管理しているデータ放送用アプリを、インターネット２０を介して受信装置１２に提供する。
【００５３】
放送システム１は、以上のように構成される。
【００５４】
［受信装置の構成例］
図１１は、図１０の受信装置１２の構成例を示している。
【００５５】
受信装置１２は、チューナ５１、多重分離部５２、音声デコーダ５３、音声出力部５４、映像デコーダ５５、映像出力部５６、トリガ抽出部５７、制御部５８、メモリ５９、操作部６０、通信I/F６１、TPT解析部６２、フルート処理部６３、アプリエンジン６４、キャッシュメモリ６５、及びアプリ用メモリ６６から構成される。
【００５６】
チューナ５１は、ユーザによって選局されたチャンネルに対応する放送信号を受信して復調し、その結果得られる放送ストリームを多重分離部５２に供給する。
【００５７】
多重分離部５２は、チューナ５１から供給される放送ストリームに多重化された音声ストリームと映像ストリームを分離し、それぞれを音声デコーダ５３と、映像デコーダ５５に供給する。また、多重分離部５２は、放送ストリームに多重化されたPSIP、SMT、NRT-IT、及びFLUTEを分離する。
【００５８】
音声デコーダ５３は、多重分離部５２から供給された音声ストリームをデコードし、その結果得られる音声信号を音声出力部５４に供給する。音声出力部５４は、音声デコーダ５３から供給された音声信号を、後段のスピーカ（不図示）に出力する。
【００５９】
映像デコーダ５５は、多重分離部５２から供給された映像ストリームをデコードし、その結果得られる映像信号を映像出力部５６及びトリガ抽出部５７に供給する。映像出力部５６は、映像デコーダ５５から供給された映像信号を、後段のディスプレイ（不図示）に出力する。
【００６０】
トリガ抽出部５７には、映像デコーダ５５から供給される映像信号を常に監視して、映像信号に埋め込まれているトリガ情報を抽出し、制御部５８に供給する。
【００６１】
なお、ここでは、トリガ情報が映像信号に埋め込まれている場合を一例に説明するが、トリガ情報が音声信号に埋め込まれている場合、トリガ抽出部５７は、音声デコーダ５３から供給される音声信号を常に監視し、音声信号に埋め込まれているトリガ情報を抽出する。また、トリガ情報がトランスポートストリームに配置されている場合、トリガ抽出部５７は、多重分離部５２から供給される、トリガ情報を含むPCRパケットからトリガ情報を抽出する。
【００６２】
制御部５８は、メモリ５９にあらかじめ記憶されている制御用プログラムを実行することにより受信装置１２の各部の動作を制御する。操作部６０は、ユーザからの各種の操作を受け付けて、それに対応する操作信号を制御部５８に供給する。
【００６３】
また、制御部５８は、トリガ抽出部５７から供給されるトリガ情報に応じて、通信I/F６１を制御して、インターネット２０を介してTPTサーバ１３にアクセスし、TPTを要求する。通信I/F６１は、TPTサーバ１３からインターネット２０を介して送信されるTPTを受信し、TPT解析部６２に供給する。
【００６４】
TPT解析部６２は、通信I/F６１から供給されるTPTを取得する。TPT解析部６２は、取得したTPTを解析して、内部に備えるメモリ（不図示）に保持する。また、TPT解析部６２は、制御部５８からの要求に応じて、メモリに保持しているTPTを供給する。
【００６５】
また、制御部５８は、TPT解析部６２からのTPTに基づいて、トリガ抽出部５７からのトリガ情報に含まれる時刻情報（media_time）から得られるＡＶコンテンツの進行を示す時刻が、コマンドの有効期間内となるか、又は有効開始時刻を経過した場合、その有効なコマンドを特定する。制御部５８は、特定したコマンドに応じて、データ放送用アプリの取得若しくは登録、取得若しくは起動、イベント発火、中断、又は終了等を制御する。
【００６６】
フルート処理部６３は、多重分離部５２により分離される放送ストリームを常時監視し、SMT及びNRT-ITを取得する。フルート処理部６３は、制御部５８からの制御に従い、取得したSMT及びNRT-ITを参照して、FDTを取得する。フルート処理部６３は、取得したFDTを参照して、FLUTEセッションにより伝送されるデータ放送用アプリを取得し、キャッシュメモリ６５に保持させる。
【００６７】
アプリエンジン６４は、制御部５８からの制御に従い、キャッシュメモリ６５に保持されているデータ放送用アプリを読み出して実行する。実行中のデータ放送用アプリの映像信号は、映像出力部５６に供給される。
【００６８】
映像出力部５６は、アプリエンジン６４から供給される映像信号と、映像デコーダ５５から供給された映像信号を合成して、後段のディスプレイに出力する。
【００６９】
アプリ用メモリ６６は、ワークメモリ６６Ａ及び退避メモリ６６Ｂとからなる。アプリエンジン６４は、実行中のデータ放送用アプリに関するデータ（具体的には、表示されている情報の階層などを含む）をワークメモリ６６Ａに記録する。また、アプリエンジン６４は、実行中のデータ放送用アプリを休止する場合、アプリ用メモリ６６のワークメモリ６６Ａのデータを退避メモリ６６Ｂに移動させる。そして、休止したデータ放送用アプリを再開する場合、退避メモリ６６Ｂのデータをワークメモリ６６Ａに移動させて休止前の状態を復活させる。
【００７０】
また、アプリエンジン６４は、制御部５８からの制御に従い、通信I/F６１を制御して、インターネット２０を介してアプリサーバ１４にアクセスし、データ放送用アプリを要求する。通信I/F６１は、アプリサーバ１４からのデータ放送用アプリを受信し、キャッシュメモリ６５に保持させる。
【００７１】
なお、図１１には図示されていないが、FLUTEセッションによりNRTコンテンツが伝送された場合には、フルート処理部６３は、SMT及びNRT-ITに基づいて、多重分離部５２により分離される放送ストリームからNRTコンテンツを取得し、ストレージ（不図示）に蓄積させる。そして、ストレージに蓄積されたNRTコンテンツは適宜読み出され、再生されることになる。
【００７２】
受信装置１２は、以上のように構成される。
【００７３】
［トリガ情報の詳細］
次に、トリガ情報の詳細について説明する。図１２は、トリガ情報に含まれる情報の項目の一例を示している。
【００７４】
program_idは、ＡＶコンテンツの識別情報である。すなわち、受信装置１２がトリガ情報に含まれるprogram_idをTPTサーバ１３に通知することで、TPTサーバ１３は、当該program_idに基づき、TPTを特定するためのテレビ番組等を識別することが可能となる。ただし、program_idは、channel_id（Ch_ID）と称される場合もある。
【００７５】
media_timeは、ＡＶコンテンツの進行時間軸上の特定の時間位置を示す情報である。例えば、media_timeには、テレビ番組の進行時間軸上の開始時刻や午前０時（0:00）等の特定の時刻を基準にして、その基準時刻からの時刻が指定される。また、media_timeに指定される時刻は、例えば秒やミリ秒単位とされる。
【００７６】
domain_nameは、TPTサーバ１３を特定するための情報であって、例えば、TPTサーバ１３のドメイン名を示す情報が指定される。すなわち、TPTサーバ１３は、放送装置１１にてテレビ番組の放送を行う放送事業者などの事業者により提供されるため、domain_nameは、それらの事業者ごとに異なるものとなる。
【００７７】
例えば、トリガ情報は、domain_name，program_id，及びmedia_timeを指定するための値と、“/”や“?mt=”などの所定の文字を連結させた文字列からなる。具体的には、domain_nameが、“xbc.com”，program_idが、“1”，media_timeが、“1000”である場合、トリガ情報を示す文字列は、“xbc.com/1?mt=1000”となるので、この文字列の先頭に、“http://”を付加すると、TPTサーバ１３にアクセスするための、URL（Uniform Resource Locator）を示す文字列が得られる。ただし、domain_nameにはドメイン名の代わりに、直接URLを指定することも可能である。
【００７８】
なお、トリガ情報に含まれる情報の項目は任意であって、図１２の例に限定されるものではない。
【００７９】
トリガ情報は、以上のように構成される。
【００８０】
［TPTの詳細］
次に、TPTの詳細について説明する。図１３はTPTのフォーマットの例を示す図である。
【００８１】
図１３に示すように、TPTは、tpt要素、command要素、application要素、event要素、及びdiffusion要素から構成される。
【００８２】
tpt要素には、TPTに関する情報が記述される。tpt要素は、id属性、type属性、version属性、updating_time属性、present_following属性、end_mt属性、及びexpire_date属性を含む。
【００８３】
id属性には、TPTを識別するための情報が指定される。例えば、id属性には、domain_nameと、program_idとを“/”により連結した文字列が指定される。
【００８４】
type属性には、その属性値として、“static”又は“dynamic”が指定される。“static”は、トリガ情報に含まれるprogram_idが変更された場合にのみ、TPTを更新する場合に指定される。また、“dynamic”は、トリガ情報に含まれるprogram_idが同一であっても、TPTを更新する場合に指定される。
【００８５】
version属性には、当該TPTのバージョンを示す情報が指定される。
【００８６】
updating_time属性には、TPTの更新期間を示す情報が指定される。updating_time属性は、type属性が“dynamic”となる場合にのみ指定される。
【００８７】
present_following属性には、その属性値として、“present”又は“following”が指定される。“present”は、当該TPTが例えば、現在のテレビ番組用のTPTであることを示し、“following”は、当該TPTが例えば、次のテレビ番組用のTPTであることを示す。
【００８８】
end_mt属性には、当該TPTに対応するＡＶコンテンツのmedia_timeが終了する時刻を示す情報が指定される。
【００８９】
expire_date属性には、当該TPTの有効期限を示す情報が指定される。expire_date属性は、type属性が“static”となる場合にのみ指定される。
【００９０】
command要素には、コマンドに関する情報が記述される。command要素は、id属性、start_time属性、end_time属性、destination属性、及びaction属性を含む。
【００９１】
id属性には、コマンドを識別するための情報が指定される。
【００９２】
start_time属性には、id属性により識別されるコマンドの有効期間の開始時刻を示す情報が指定される。end_time属性には、id属性により識別されるコマンドの有効期間の終了時刻を示す情報が指定される。
【００９３】
すなわち、コマンドの有効期間は、対応するＡＶコンテンツの進行時間軸上の２点を示すstart_time属性及びend_time属性によって示される。そして、ＡＶコンテンツの進行タイミングが有効期間内であるときには、その有効なコマンドが有効とされ、ＡＶコンテンツの進行のタイミングが有効期間に達していない、又はそれを過ぎたときは、その有効なコマンドは無効とされる。また、end_time属性は必須の項目ではなく、start_time属性のみが指定された場合には、ＡＶコンテンツの進行タイミングがstart_time属性の示す有効開始時刻を経過したとき、その有効なコマンドが有効とされる。
【００９４】
destination属性には、当該コマンドによるデータ放送用アプリ制御の対象となる機器が指定される。ここでは、受信装置本体（受信装置１２）のほか、受信装置１２に外部装置（不図示）が接続される場合には、その外部装置が、コマンドの対象機器として指定される。例えば、destination属性には、コマンドの対象機器が受信装置１２となる場合、“receiver”が指定され、コマンドの対象機器が外部装置となる場合、“external_1”や“external_2”が指定される。ただし、destination属性が指定されない場合には、“receiver”が指定されたものとみなされる。
【００９５】
action属性は、当該コマンドが、“execute”，“register”，“suspend”，“terminate”，“event”のいずれかであるかを示す。
【００９６】
エクスキュートコマンド（execute）は、受信装置１２に対して、データ放送用アプリの取得若しくは起動を指示するためのコマンドである。
【００９７】
レジスタコマンド（register）は、受信装置１２に対して、データ放送用アプリの取得若しくは登録を指示するためのコマンドである。
【００９８】
サスペンドコマンド（suspend）は、受信装置１２に対して、実行中のデータ放送用アプリを中断して、休止させるためのコマンドである。
【００９９】
ターミネートコマンド（terminate）は、受信装置１２に対して、実行中のデータ放送用アプリを終了させるためのコマンドである。
【０１００】
イベントコマンド（event）は、受信装置１２に対して、実行中のデータ放送用アプリにおいてイベントを発火させるためのコマンドである。
【０１０１】
application要素は、データ放送用アプリに関する情報が記述される。application要素は、id属性、type属性、url属性、priority属性、expire_date属性、及びcapability要素を含む。
【０１０２】
id属性には、当該データ放送用アプリを識別するためのアプリIDが指定される。type属性には、当該データ放送用アプリのファイル属性等に関する情報を示すアプリタイプが指定される。url属性には、コマンドが、エクスキュートコマンド又はレジスタコマンドである場合において、当該データ放送用アプリの取得先を示すアプリURLが指定される。従って、url属性には、アプリサーバ１４のURLが指定される。
【０１０３】
priority属性には、当該コマンドに対応するデータ放送用アプリを取得、保持するときの優先度を示す情報が指定される。expire_date属性には、データ放送用アプリの有効期限を示す情報が指定される。データ放送用アプリが登録される場合、アプリ有効期限とデータ放送用アプリ保持優先度が記憶され、データ放送用アプリは、それらの有効期限と優先度に従って管理される。
【０１０４】
なお、url属性及びexpire_date属性は、コマンドが、エクスキュートコマンド又はレジスタコマンドとなる場合には必須の項目となる。また、priority属性には、通常は“0”が指定され、優先度を高くする場合には、“1”が指定される。
【０１０５】
capability要素には、受信装置１２に要求される各種の性能が指定される。capability要素は、essential属性を含む。essential属性には、要求される性能が、必須の性能である場合には、“yes”が指定され、オプションの性能である場合には、“no”が指定される。
【０１０６】
図１４は、capability要素に指定される値の具体例を示す図である。
【０１０７】
capability要素に“flute”が指定された場合、受信装置１２に対して、FLUTEセッションの機能を利用可能であるか否かのチェックが行われる。受信装置１２は、FLUTEセッションの機能に対応している場合、FLUTEセッションにより伝送されるデータ放送用アプリを取得することになる。
【０１０８】
また、capability要素に“raptor”が指定された場合、Raptor FEC機能の利用可否がチェックされ、受信装置１２がRaptor FEC機能に対応しているときには、FLUTEセッションにてRaptor FECが利用される。さらに、capability要素に“html5”又は“browser_a”が指定された場合、HTML5又はCE-HTMLの文書形式の利用可否がチェックされ、受信装置１２がそれらの文書形式に対応しているときには、それらの文書形式で記述されたデータ放送用アプリが取得される。
【０１０９】
capability要素に“mp4”が指定された場合、MP4フォーマットの再生の可否がチェックされ、受信装置１２がMP4フォーマットに対応している場合、MP4フォーマットからなるデータ放送用アプリが取得される。同様に、capability要素に“zip”が指定された場合、ファイルのzipフォーマットのラッパーの利用可否がチェックされる。
【０１１０】
capability要素に“avc_40”が指定された場合、AVC level4.0の再生の可否がチェックされ、受信装置１２がその圧縮符号化方式に対応しているときには、データ放送用アプリから起動されるAVC level4.0で圧縮符号化されたコンテンツが取得される。また、capability要素に“avc_42”が指定された場合も同様である。
【０１１１】
capability要素に“mp3”、“he_aac”、又は“dts”が指定された場合、MP3、HE_AAC3（High Efficiency Advanced Audio Coding）、又はDTS（Digital Theater Systems）のフォーマットの再生の可否がチェックされ、受信装置１２がそれらのフォーマットに対応しているときには、それらのフォーマットの音声データを利用するデータ放送用アプリが取得される。
【０１１２】
なお、capability要素には、データ放送用アプリの取得や再生に関して、受信装置１２に要求される性能に関する値が指定され、図１４の具体例に限定されるものではない。
【０１１３】
図１３に戻り、event要素には、イベントコマンドに関する情報が記述される。event要素は、id属性及びdata要素を含む。
【０１１４】
id属性には、コマンドが、イベントコマンドである場合において、アプリIDにて指定されたデータ放送用アプリにおいて発火すべきイベントを識別するためのイベントIDが指定される。また、data要素には、コマンドが、イベントコマンドである場合において、イベントを発火する際に参照されるイベント付加データが記述される。
【０１１５】
なお、event要素は、action属性が、“event”となる場合には必須の項目となる。
【０１１６】
diffusion要素には、受信装置１２においてコマンドを適用するタイミングを確率的に分散させるための情報が指定される。この値を設定することにより、複数の受信装置１２がアプリサーバ１４からデータ放送用アプリを取得するに際し、そのアクセスが一時期に集中せず分散させることができる。diffusion要素は、rate属性、range属性、period属性を含み、それぞれ、分配数、最大遅延時間、コマンド適用拡散期間が指定される。
【０１１７】
［TPTの記述例］
図１５は、TPTの記述例を示す図である。
【０１１８】
図１５の例では、tpt要素のid属性には、“xbc.com/1”が指定される。すなわち、これは、例えば、xbc放送局（domain_name = “xbc.com”）により放送されるテレビ番組（program_id = “1”）用のTPTであることを意味する。
【０１１９】
また、tpt要素において、type属性には、“static”が指定されているので、program_idが変更された場合にのみTPTが更新される。さらに、expire_date属性には、“2011-01-21”が指定されているので、当該TPTの有効期限は、2011年1月21日までとなる。
【０１２０】
なお、説明の簡略化のためすべては記載していないが、このtpt要素中には、７個のcommand要素が記述されている。
【０１２１】
１つ目のcommand要素には、id属性として“1”、start_time属性として“0”、end_time属性として“600”、destination属性として“receiver”、action属性として“register”がそれぞれ指定されている。すなわち、当該コマンド（id = 1）は、0秒乃至600秒の有効期間内に実行される、受信装置１２に対するレジスタコマンドとなる。
【０１２２】
また、command要素の開始タグと終了タグの間には、application要素が記述される。application要素には、id属性として“1”、type属性として“html”、url属性として“xxx.com/yyy1”、expire_date属性として“2011-01-21”がそれぞれ指定されている。すなわち、当該application要素は、HTML（Hyper Text Markup Language）により記述されたデータ放送用アプリ（id = 1）が、“xxx.com/yyy1”であるURLにより特定されるアプリサーバ１４から取得できることを意味する。また、当該データ放送用アプリの有効期限は、2011年1月21日までとなる。
【０１２３】
さらに、command要素の開始タグと終了タグの間には、capability要素として、“flute”が記述される。また、capability要素には、essential属性として、“no”が指定されている。すなわち、FLUTEセッションは、オプションの機能となるため、受信装置１２は、FLUTEセッションの機能に対応していなくてもよいことになる。この記述例の場合、受信装置１２がFLUTEセッションの機能に対応していない場合には、アプリサーバ１４からデータ放送用アプリを取得すればいいので、essential属性には“no”が指定されている。
【０１２４】
また、capability要素として、“avc_40”が記述され、そのessential属性として、“yes”が指定されている。すなわち、AVC level4.0は、必須の機能となるため、受信装置１２は、AVC level4.0で圧縮符号化されたコンテンツを再生する機能に対応している必要がある。この記述例の場合、受信装置１２がAVC level4.0に対応していないと、データ放送用アプリから起動されるコンテンツを再生することができないので、essential属性に“yes”が指定されている。
【０１２５】
同様に、２つ目のcommand要素は、当該コマンド（id = 2）が、600秒乃至3500秒の有効期間内に実行される、受信装置１２に対するエクスキュートコマンドとなることを示す。また、エクスキュートコマンドに応じて取得されるデータ放送用アプリ（id = 1）が、“xxx.com/yyy1”であるURLにより特定されるアプリサーバ１４から取得できることを意味する。なお、diffusion要素が記述されているため、受信装置１２は、rate属性、range属性、及びperiod属性に指定される値により決定されるタイミングで、アプリサーバ１４にアクセスすることになる。
【０１２６】
３つ目のcommand要素は、1800秒乃至2000秒の有効期間内に実行されるコマンドであって、当該コマンド（id = 3）が、受信装置１２により実行されるデータ放送用アプリ（id = 1）に対するイベントコマンドとなることを示す。また、このcommand要素の開始タグと終了タグの間には、application要素及びevent要素が記述される。application要素には、id属性として“1”が指定されている。また、event要素には、id属性として”event1”が指定され、data要素として”zzzzzzz・・・z”が記述される。すなわち、当該コマンドでは、イベント発火に伴い、データ放送用アプリによって、”zzzzzzz・・・z”であるデータが利用される。
【０１２７】
また、４つ目のcommand要素は、当該コマンド（id = 4）が、2400秒乃至2520秒の有効期間内に実行される、受信装置１２により実行されるデータ放送用アプリ（id = 1）に対するサスペンドコマンドとなることを示す。さらに、５つ目のcommand要素は、当該コマンド（id = 5）が、3500秒乃至3600秒の有効期間内に実行される、受信装置１２により実行されるデータ放送用アプリ（id = 1）に対するターミネートコマンドとなることを示す。
【０１２８】
６つ目のcommand要素は、当該コマンド（id = 12）が、2400秒乃至2520秒の有効期間内に実行される、受信装置１２に対するエクスキュートコマンドとなることを示す。また、command要素の開始タグと終了タグの間のapplication要素には、id属性として“2”が指定され、type属性として“html”が指定され、url属性として“xxx.com/yyy2”が指定され、expire_date属性として“2011-01-22”が指定されている。すなわち、エクスキュートコマンドに応じて取得されるデータ放送用アプリ（id = 2）が、“xxx.com/yyy2”であるURLにより特定されるアプリサーバ１４から取得できることを意味する。
【０１２９】
同様に、７つ目のcommand要素は、当該コマンド（id = 15）が、2520秒乃至3600秒の有効期間内に実行される、受信装置１２により実行されるデータ放送用アプリ（id = 2）に対するターミネートコマンドとなることを示す。
【０１３０】
なお、TPTの記述方法は任意であって、図１５の記述例に限定されるものではない。
【０１３１】
TPTは、以上のように構成される。
【０１３２】
［トリガ情報とコマンドの対応関係］
次に、トリガ情報に対応付けられたコマンドを、TPTによって特定する処理の例を説明する。図１６は、トリガ情報とコマンドの対応関係の例を示す図である。
【０１３３】
図１６に示すように、受信装置１２では、映像信号からトリガ情報が抽出されると、トリガ情報に含まれるdomain_name及びprogram_idに基づいて、TPTサーバ１３からTPTを取得するか否かが判定される。なお、図１６の例では、テレビ番組やＣＭ等であるprogram A，Bのprogram_idはそれぞれ、“10”，“20”であるものとする。
【０１３４】
例えば、受信装置１２において、xbc放送局（domain_name = “xbc.com”）により放送されるprogram A（program_id = “10”）用のTPT（for program A）が保持されている場合に、映像信号から“xbc.com/20?mt=Tb”であるトリガ情報が抽出されたとき、program_idの値が変化したので、受信装置１２は、TPTを取得すると判定する。そして、受信装置１２は、トリガ情報から得られるURL（“http://xbc.com/20?mt=Tb”）により特定されるTPTサーバ１３にアクセスして、TPTを取得する。
【０１３５】
これにより、受信装置１２には、図中のTPT（for program B）が保持される。なお、図１６に示したTPTは、前述した図１５のTPTに対応するものであるが、ここでは、説明の簡略化のため、command要素のid属性、start_time属性、end_time属性、及びaction属性、application要素のid属性、並びにURLなどのパラメータのみを図示している。
【０１３６】
そして、例えば、１つ目のトリガ情報（“xbc.com/20?mt=Tb”）に含まれるmedia_timeが“Tb”である場合、受信装置１２では、Tbが、T1s乃至T1eの有効期間内となるので、TPTによって、“1”であるid属性に対応するレジスタコマンドが特定される。そして、受信装置１２は、レジスタコマンドに応じて、アプリIDが“1”となるデータ放送用アプリを取得して、登録する。ここで、データ放送用アプリは、基本的に放送波から取得されるものであるが、何らかの原因で取得できない場合にはアプリサーバ１４から取得される。
【０１３７】
続いて、受信装置１２では、２つ目のトリガ情報（“xbc.com/20?mt=Tc”）が抽出された場合、Tcであるmedia_timeが、T3s乃至T3eの有効期間内となるので、TPTによって、“3”であるid属性に対応するエクスキュートコマンドが特定される。そして、受信装置１２は、エクスキュートコマンドに応じて、取得済みのデータ放送用アプリを起動する。
【０１３８】
続いて、受信装置１２では、３つ目のトリガ情報（“xbc.com/20?mt=Td”）が抽出された場合、“Td”であるmedia_timeが、T5s乃至T5eの有効期間内となるので、TPTによって、“5”であるid属性に対応するサスペンドコマンドが特定される。そして、受信装置１２は、サスペンドコマンドに応じて、実行中のアプリIDが“1”のデータ放送用アプリを休止させる。
【０１３９】
また、Tdであるmedia_timeは、T2s乃至T2eの有効期間内ともなるので、受信装置１２では、TPTによって、“2”であるcommand要素のid属性に対応するエクスキュートコマンドが特定される。そして、受信装置１２は、エクスキュートコマンドに応じて、アプリIDが“2”となるデータ放送用アプリを取得して、起動する。
【０１４０】
その後、図１６には図示していないが、受信装置１２では、抽出されたトリガ情報に含まれるmedia_timeが有効期間内となる場合、その有効なコマンドに応じて、データ放送用アプリの動作が制御される。
【０１４１】
以上のように、受信装置１２においては、放送装置１１からのトリガ情報が抽出された場合、保持しているTPTに基づいて、当該トリガ情報に含まれるmedia_timeに対応するコマンドが特定され、特定されたコマンドに応じて、データ放送用アプリの動作が制御される。
【０１４２】
［データ放送用アプリの状態遷移］
図１７は、レジスタ、エクスキュート、イベント、サスペンド、及びターミネートの各コマンドに応じて受信装置１２にて動作するデータ放送用アプリの状態遷移図である。図１７に示すように、データ放送用アプリの状態は、解放状態(Released)、準備状態(Ready)、実行中状態(Active)、又は休止状態(Suspended)の４種類のうちいずれかに遷移していると定義される。
【０１４３】
解放状態は、データ放送用アプリが受信装置１２に未取得である状態を指す。準備状態は、そのデータ放送用アプリが受信装置１２に登録済みであって起動されていない状態を指す。実行中状態は、データ放送用アプリが起動されて実行中である状態を指す。休止状態は、データ放送用アプリの実行が中断され、その中断したときの状態を示す情報が退避メモリ６６Ｂに保持されている状態を指す。
【０１４４】
データ放送用アプリが解放状態に遷移しているとき（受信装置１２に未取得のとき）、レジスタコマンドが特定され、レジスタコマンドに従ってそのデータ放送用アプリが取得（登録）されると、準備状態に遷移する。
【０１４５】
データ放送用アプリが準備状態であるとき、エクスキュートコマンドが特定され、エクスキュートコマンドに従ってそのデータ放送用アプリが起動されると、実行中状態に遷移する。
【０１４６】
また、データ放送用アプリが解放状態に遷移しているとき（受信装置１２に未取得のとき）、エクスキュートコマンドが特定され、エクスキュートコマンドに従ってそのデータ放送用アプリが取得されて起動されると、実行中状態に遷移する。
【０１４７】
データ放送用アプリが実行中状態に遷移しているとき、サスペンドコマンドが特定され、サスペンドコマンドに従って実行中のデータ放送用アプリが中断されると休止状態に遷移する。
【０１４８】
データ放送用アプリが休止状態に遷移しているとき、エクスキュートコマンドが特定され、エクスキュートコマンドに従って、中断されていたデータ放送用アプリが再開されると、実行中状態に遷移する。
【０１４９】
データ放送用アプリが、実行中状態又は休止状態に遷移しているとき、ターミネートコマンドが特定され、ターミネートコマンドに従って、実行中のデータ放送用アプリが終了されると、準備状態に遷移する（図中の「Ａ」）。なお、準備状態への遷移は、ターミネートコマンドに基づくもののほか、他のデータ放送用アプリが実行されたときなどにも発生する。
【０１５０】
また、データ放送用アプリが、準備状態、実行中状態、又は休止状態に遷移しているとき、コマンドのアプリ有効期限が経過したとき、解放状態に遷移する（図中の「Ｂ」）。
【０１５１】
［データ放送用アプリの取得方法］
次に、図１８を参照して、放送波により伝送されるデータ放送用アプリの取得方法を説明する。受信装置１２は、TPTに基づいて、トリガ情報に対応するコマンドとして、レジスタコマンド又はエクスキュートコマンドが特定された場合に、放送波により伝送されるデータ放送用アプリの取得を試みる。その際、受信装置１２は、放送波により伝送される、SMT、NRT-IT、及びFDTの各テーブルを参照することになる。
【０１５２】
図１８は、放送波により伝送されるテーブルの例を示す図である。図１８には、SMT、NRT-IT、FDT、及びETTの各テーブルが図示されている。
【０１５３】
SMT（Service Map Table）は、NRTサービスのサービスレベルの属性情報が記述される。例えば、SMTには、Service#1，#2，・・・などのNRTサービス単位の属性情報が記述される。
【０１５４】
Service Nameには、当該NRTサービスの名称が記述される。
【０１５５】
IP(src)、IP(dest)には、送信元（source）と宛先（destination）のIPアドレスが記述される。また、FLUTE Session Infoには、ポート番号が記述される。このポート番号は、NRTサービスごとに異なる番号が指定される。すなわち、FLUTEセッションは、NRTコンテンツの伝送に用いるIPパケットの送信元IPアドレスと、宛先のIPアドレス及び宛先のポート番号の組み合わせにより区別される、一連のIPパケットの伝送により行われる。そして、それらのIPアドレスとポート番号の組み合わせによって、NRTサービスが特定されることになる。
【０１５６】
Service IDには、当該NRTサービスの識別情報が記述される。また、Service Categoryには、当該NRTサービスが属するカテゴリが記述される。Content typeには、当該NRTサービスにて提供されるコンテンツのタイプが記述される。MIME typesには、例えばHTMLなどのMIMEタイプが記述される。ISO-639 languageには、例えば日本語や英語などの言語が記述される。Genreには、当該NRTコンテンツが属するジャンルに関する情報が記述される。
【０１５７】
なお、詳細については省略するが、SMTには、Purchase data，STKM,LTKM info，Storage reservation，Service Icon Content-ID，その他のNRTサービスに関する情報を記述することが可能である。
【０１５８】
NRT-IT（NRT Information Table）には、１つのNRTサービスに含まれるコンテンツレベルの属性情報が記述される。例えば、NRT-ITには、Content#1，#2，・・・などのNRTコンテンツ単位の属性情報が記述される。
【０１５９】
NRT-ITには、当該NRTサービスを識別するためのService IDが記述される。このService IDは、SMTに記述されたNRTサービスごとのService IDに関連付けられている。
【０１６０】
Content nameには、当該NRTコンテンツの名称が記述される。Content Linkageには、当該NRTコンテンツの識別情報が記述される。ただし、Content Linkageは、Content IDと記述される場合がある。Distribution start/end timeには、当該NRTコンテンツの開始時刻と終了時刻を示す情報が記述される。Playback lengthには、当該NRTコンテンツのプレイバック時間が記述される。Content lengthには、ストレージに蓄積されるNRTコンテンツのデータ量が記述される。
【０１６１】
MIME typesには、例えばHTMLなどのMIMEタイプが記述される。ISO-639 languageには、例えば日本語や英語などの言語が記述される。MPEG-2 AAC audio infoやAVC video infoには、映像や音声のデータ圧縮に関する情報が記述される。Caption serviceには字幕に関する情報が記述される。
【０１６２】
また、Internet Locationには、インターネット２０を介して配信されるデータ放送用アプリを取得するための情報として、例えばアプリサーバ１４のURLが記述される。すなわち、受信装置１２は、何らかの原因により放送波により伝送されるデータ放送用アプリが取得できない場合、Internet Locationを参照して、インターネット２０を介してアプリサーバ１４からデータ放送用アプリを取得することができる。ただし、Internet Locationは、Content URLと記述される場合がある。
【０１６３】
なお、詳細については省略するが、NRT-ITには、Content advisory，Genre，SVC info，STKM,LTKM info，その他のNRTコンテンツに関する情報を記述することが可能である。
【０１６４】
FDT（File Delivery Table）には、FLUTEセッションを利用して配信するファイルについての属性情報が記述される。例えば、FDTには、TOI、Content Location、及びContent Linkageがそれぞれ関連付けられて記述される。
【０１６５】
TOI（Transport Object Identifier）には、伝送するファイルオブジェクトの識別情報が記述される。FDT InstanceのTOIには0が記述され、伝送するファイルオブジェクトのTOIには、例えばダウンロードヘッダに格納される識別情報が記述される。
【０１６６】
Content Locationには、ファイルの識別情報がURI（Uniform Resource Identifier）で記述される。Content Linkageには、NRTコンテンツの識別情報が記述される。このContent Linkageは、NRT-ITに記述されたNRTコンテンツごとのContent Linkageに関連付けられている。
【０１６７】
なお、TOI、Content Location、及びContent Linkageは、FDIに記述される属性情報の一例であって、その他の属性情報を記述することが可能である。
【０１６８】
ETT（Extended Text Table）には、Content LinkageとTextが関連付けられて記述される。Content Linkageには、コンテンツの識別情報が記述される。このContent Linkageは、NRT-ITに記述されたNRTコンテンツごとのContent Linkageに関連付けられている。Textには、テキスト情報が記述される。
【０１６９】
SMT、NRT-IT、FDT、及びETTの各テーブルは、以上のように構成される。
【０１７０】
ところで、受信装置１２は、SMT、NRT-IT、及びFDTを参照して、放送波により伝送されるデータ放送用アプリを取得することになるが、具体的には以下の流れで行われる。なお、ここでは、前述したNRTコンテンツとして（NRTコンテンツの代わりに）、データ放送用アプリが伝送されていることが前提となる。
【０１７１】
すなわち、受信装置１２は、TPTに基づいて、トリガ情報に対応するコマンドとして、レジスタコマンド又はエクスキュートコマンドを特定した場合に、それらのコマンドには、データ放送用アプリの取得先を示すアプリURLとして、アプリサーバ１４のURLが指定されているので、そのURLを取得する。そして、受信装置１２は、NRT-ITを参照して、NRT-ITに記述された各NRTコンテンツのInternet Locationの中から、取得したアプリURLと一致するURLの検索を行い、当該条件に一致するNRTコンテンツを特定する（Ｓ１）。
【０１７２】
次に、受信装置１２は、SMTを参照して、Ｓ１にて特定されたInternet Locationに関連付けられたService ID（NRT-IT）と同一のService ID（SMT）の検索を行い、当該条件に一致するNRTサービスを特定する（Ｓ２）。また、受信装置１２は、SMTを参照して、Ｓ２にて特定されたService IDに関連付けられたIP(src)、IP(dest)、FLUTE Session Infoを取得する。そして、受信装置１２は、取得したIPアドレス（S1）とポート番号（P1）の組み合わせにより特定されるFLUTEセッション（TSI = T1）から、TOI=0となるFDTを取得する（Ｓ３）。
【０１７３】
次に、受信装置１２は、Ｓ３にて取得したFDTを参照して、Ｓ１にて特定されたInternet Locationに関連付けられたContent Linkage（NRT-IT）と同一のContent Linkage（FDT）の検索を行い、当該条件に一致するContent Linkage（Content Linkage = id1）を特定する（Ｓ４）。そして、受信装置１２は、Ｓ４にて特定されたContent Linkageに関連付けられたTOI（TOI = 6）を特定する。
【０１７４】
これにより、受信装置１２は、FLUTEセッション（TSI = T1）において、特定されたTOI（TOI = 6）により識別されるオブジェクトに基づいて、データ放送アプリを取得することになる。
【０１７５】
このように、本来、NRT-ITのInternet Locationには、放送波により伝送されるデータ放送用アプリが取得できない場合に、インターネット２０を介してアプリサーバ１４からデータ放送用アプリを取得するためのURLが記述されるところ、本技術では、そこに記述されるURLと、TPTに記述されるアプリURLとを関連付けている。そして、NRT-ITのInternet Locationが特定されれば、上記のとおり、SMT及びNRT-ITを参照して、いわば逆引きすることで、FDTのTOIが特定され、FLUTEセッションで伝送されるデータ放送用アプリが取得されることになる。
【０１７６】
なお、上記の方法によって、放送波により伝送されるデータ放送用アプリが取得できない場合には、受信装置１２は、NRT-ITのInternet Locationを参照して、本来の目的のとおり、インターネット２０を介してアプリサーバ１４からデータ放送用アプリを取得することになる（Ｓ５）。
【０１７７】
以上、放送波により伝送されるデータ放送用アプリの取得方法について説明した。
【０１７８】
［トリガ情報対応処理］
次に、受信装置１２がトリガ情報を受信したときのトリガ情報対応処理について、図１９乃至図２１のフローチャートを参照して説明する。
【０１７９】
（トリガ情報対応処理）
まず、図１９のフローチャートを参照して、トリガ情報対応処理について説明する。なお、このトリガ情報対応処理は、ユーザがテレビ番組を視聴しているとき、すなわち、受信装置１２が放送信号を受信している間、繰り返して実行される。
【０１８０】
受信装置１２は、ユーザの操作によって、所定のチャンネルが選局されると、そのチャンネルのテレビ番組の映像の表示を開始する（ステップＳ１１）。
【０１８１】
ステップＳ１２において、トリガ抽出部５７は、映像デコーダ５５からの映像信号からトリガ情報を抽出するまで待機する。そして、受信装置１２により放送信号に含まれるトリガ情報が受信され、映像信号からトリガ情報が抽出された場合、処理は、ステップＳ１３に進められる。
【０１８２】
ステップＳ１３において、制御部５８は、トリガ抽出部５７により抽出されたトリガ情報の解析を行い、当該トリガ情報に含まれる、domain_name及びprogram_idのうちいずれか一方又は双方が変化したか否かを判定する。ステップＳ１３において、domain_name及びprogram_idのうちいずれか一方又は双方が変化したと判定された場合、処理は、ステップＳ１４に進められる。
【０１８３】
ステップＳ１４において、制御部５８は、通信I/F６１を制御して、例えば、トリガ情報の先頭に“http://”を付加することで得られるURLにより特定されるTPTサーバ１３にアクセスして、TPTを要求する。そして、TPT解析部６２は、通信I/F６１を制御して、TPTサーバ１３からのTPTを取得する。
【０１８４】
ステップＳ１５において、TPT解析部６２は、取得したTPTの解析を行い、id，versionが同一のTPTを取得済みであるか否かを判定する。なお、id，versionは、例えば、tpt要素のid属性と、version属性により指定されるものである。ステップＳ１５において、id，versionが同一のTPTが未取得であると判定された場合、処理は、ステップＳ１６に進められる。
【０１８５】
ステップＳ１６において、TPT解析部６２は、取得したTPT（例えば、図１５のTPT）を保持し、処理は、ステップＳ１８に進められる。
【０１８６】
また、ステップＳ１３において、domain_name及びprogram_idのうちいずれか一方又は双方が変化していないと判定された場合、処理は、ステップＳ１７に進められる。
【０１８７】
ステップＳ１７において、TPT解析部６２は、保持しているTPTに記述されたupdating_time属性の示す更新期間が経過したか否かを判定する。ステップＳ１７において、更新期間が経過したと判定された場合、処理は、ステップＳ１４に進められる。そして、TPT解析部６２によって、TPTサーバ１３から新たなTPTが取得され、その新たなTPTと、id，versionが同一のTPTが未取得であれば、保持される。
【０１８８】
なお、ステップＳ１５において、id，versionが同一のTPTを取得済みである場合と判定された場合、又はステップＳ１７において、更新期間が経過していないと判定された場合、処理は、ステップＳ１８に進められる。
【０１８９】
ステップＳ１８において、制御部５８は、TPT解析部６２からのTPTに基づいて、トリガ抽出部５７からのトリガ情報に含まれるmedia_timeが、有効期間内となるコマンドが存在するか否かを判定する。ステップＳ１８において、media_timeが有効期間内となるコマンドが存在すると判定された場合、処理は、ステップＳ１９に進められる。
【０１９０】
ステップＳ１９において、制御部５８は、フルート処理部６３及びアプリエンジン６４を制御して、アプリ制御処理を行う。このアプリ制御処理では、media_timeが有効期間内となる有効なコマンドが特定され、特定されたコマンドに応じて、データ放送用アプリの取得若しくは登録、取得若しくは起動、イベント発火、中断、又は終了などが制御される。
【０１９１】
なお、アプリ制御処理の詳細は、図２０のフローチャートを参照して後述する。
【０１９２】
ステップＳ２０において、制御部５８は、対象の有効なコマンドが、有効期間内に該当する最後のコマンドであるか否かを判定する。ステップＳ２０において、該当する最後のコマンドではないと判定された場合、処理は、ステップＳ１９に戻り、それ以降の処理が繰り返される。すなわち、有効なコマンドの実行がすべて終了するまで、ステップＳ１９，Ｓ２０の処理が繰り返される。
【０１９３】
そして、ステップＳ２０において、該当する最後のコマンドであると判定された場合、又はステップＳ１８において、media_timeが有効期間内となるコマンドが存在しないと判定された場合、処理は、ステップＳ１２に戻り、それ以降の処理が繰り返される。
【０１９４】
以上で、トリガ情報対応処理の説明を終了する。
【０１９５】
（アプリ制御処理）
次に、図２０のフローチャートを参照して、図１９のステップＳ１９に対応するアプリ制御処理の詳細について説明する。
【０１９６】
ステップＳ３１において、制御部５８は、TPT解析部６２からのTPTに基づいて、トリガ抽出部５７により抽出されたトリガ情報に含まれるmedia_timeが有効期間内となる有効なコマンドが、レジスタ、エクスキュート、ターミネート、イベント、又はサスペンドのいずれかのコマンドであるかを特定する。すなわち、TPTは、トリガ情報に含まれるmedia_timeからコマンドを特定するための辞書として用いられる。
【０１９７】
ステップＳ３２において、制御部５８は、ステップＳ３１の特定結果がレジスタコマンドであるか否かを判定し、レジスタコマンドであると判定された場合、処理はステップＳ３３に進められる。
【０１９８】
ステップＳ３３において、制御部５８は、フルート処理部６３を制御して、アプリ取得処理を行う。このアプリ取得処理では、TPTのアプリURLに関連付けられたNRT-ITのInternet Locationに基づいて、SMT及びNRT-ITを逆引きすることで、FLUTEセッションで伝送されるデータ放送用アプリが取得される。フルート処理部６３は、取得したデータ放送用アプリをキャッシュメモリ６５に保持させる。
【０１９９】
また、制御部５８は、取得されたデータ放送用アプリに対応付けて、そのアプリ有効期限とアプリ保持優先度を、メモリ５９に記憶する。これにより、キャッシュメモリ６５に保持されたデータ放送用アプリは、制御部５８により、有効期限と保持優先度に従って管理される。
【０２００】
なお、アプリ取得処理の詳細は、図２１のフローチャートを参照して後述する。
【０２０１】
この後、処理は、図１９のステップＳ１９に戻り、それ以降の処理が繰り返される。
【０２０２】
ステップＳ３２において、ステップＳ３１の特定結果がレジスタコマンドでないと判定された場合、処理は、ステップＳ３４に進められる。ステップＳ３４において、制御部５８は、ステップＳ３１の特定結果がエクスキュートコマンドであるか否かを判定し、エクスキュートコマンドであると判定された場合、処理は、ステップＳ３５に進められる。
【０２０３】
ステップＳ３５において、アプリエンジン６４は、制御部５８からの制御に従い、TPTのアプリIDにより特定されるデータ放送用アプリが休止中（休止状態）であるか否かを判定する。具体的には、退避メモリ６６Ｂに、アプリIDにより特定されるデータ放送用アプリに、休止の状態を示すデータが退避されている場合に休止中であると判定する。
【０２０４】
ステップＳ３５において、アプリIDにより特定されるデータ放送用アプリが休止中ではないと判定された場合、処理はステップＳ３６に進められる。ステップＳ３６において、アプリエンジン６４は、制御部５８からの制御に従い、アプリIDにより特定されるデータ放送用アプリが未取得（キャッシュメモリ６５に存在しない）の場合には、アプリ取得処理を実行して、それを取得する。
【０２０５】
なお、アプリ取得処理の詳細は、図２１のフローチャートを参照して後述する。
【０２０６】
ステップＳ３７において、アプリエンジン６４は、制御部５８からの制御に従い、現在実行中のデータ放送用アプリがあるならば、それを終了させる。そして、ステップＳ３８において、アプリエンジン６４は、制御部５８からの制御に従い、アプリIDにより特定されるデータ放送用アプリを起動する。
【０２０７】
また、ステップＳ３５において、アプリIDにより特定されるデータ放送用アプリが休止中（休止状態）であると判定された場合、処理はステップＳ３９に進められる。
【０２０８】
ステップＳ３９において、アプリエンジン６４は、制御部５８からの制御に従い、退避メモリ６６Ｂのデータをワークメモリ６６Ａに移して、アプリIDにより特定されるデータ放送用アプリを起動する。これにより、アプリIDにより特定される、休止中のデータ放送用アプリが休止された状態から再開されることになる。この後、処理は、図１９のステップＳ１９に戻り、それ以降が繰り返される。
【０２０９】
ステップＳ３４において、ステップＳ３１の特定結果がエクスキュートコマンドではないと判定された場合、処理はステップＳ４０に進められる。ステップＳ４０において、制御部５８は、ステップＳ３１の特定結果がイベントコマンドであるか否かを判定し、イベントコマンドであると判定された場合、処理はステップＳ４１に進められる。
【０２１０】
ステップＳ４１において、制御部５８は、TPTにより特定されるアプリIDと、動作中のデータ放送用アプリのアプリIDが一致する場合のみ、アプリエンジン６４を制御して、動作中のデータ放送用アプリにおいて、コマンドのイベントIDに対応するイベントを発火（実行）させる。この後、処理は、図１９のステップＳ１９に戻り、それ以降が繰り返される。
【０２１１】
ステップＳ４０において、ステップＳ３１の特定結果がイベントコマンドではないと判定された場合、処理はステップＳ４２に進められる。ステップＳ４２において、制御部５８は、ステップＳ３１の特定結果がサスペンドコマンドであるか否かを判定し、サスペンドコマンドであると判定された場合、処理はステップＳ４３に進められる。
【０２１２】
ステップＳ４３において、アプリエンジン６４は、制御部５８からの制御に従い、現在実行中のデータ放送用アプリの状態を示すデータを退避メモリ６６Ｂに退避させる。この後、処理は、図１９のステップＳ１９に戻り、それ以降が繰り返される。
【０２１３】
ステップＳ４２において、ステップＳ３１の特定結果がサスペンドコマンドではないと判定された場合、ステップＳ３１の特定結果はターミネートコマンドであるので、処理はステップＳ４４に進められる。
【０２１４】
ステップＳ４４において、アプリエンジン６４は、制御部５８からの制御に従い、アプリIDにより特定されるデータ放送用アプリが実行中であればそれを終了させる。ステップＳ４５において、アプリエンジン６４は、制御部５８からの制御に従い、アプリIDにより特定されるデータ放送用アプリに関するデータを、ワークメモリ６６Ａ及び退避メモリ６６Ｂから消去するとともに、データ放送用アプリをキャッシュメモリ６５から消去させる。この後、処理は、図１９のステップＳ１９に戻り、それ以降が繰り返される。
【０２１５】
以上で、アプリ制御処理の説明を終了する。アプリ制御処理によれば、例えばテレビ番組などに連動してデータ放送用アプリを起動したり、イベントを発火させたり、終了したりすることができる。さらに、データ放送用アプリを実行中の状態を保持したままで休止させて、他のデータ放送用アプリを実行、終了し、その後、休止したデータ放送用アプリを休止状態から再開することができる。
【０２１６】
（アプリ取得処理）
次に、図２１のフローチャートを参照して、図２０のステップＳ３３又はＳ３６に対応するアプリ取得処理の詳細について説明する。
【０２１７】
ステップＳ５１において、制御部５８は、TPT解析部６２からのTPTのcapability要素に指定された性能を、受信装置１２が有しているかを確認する。ここでは、例えば、capability要素に“avc_40”が指定された場合、受信装置１２がAVC level4.0で圧縮符号化されたコンテンツの再生機能に対応しているかが確認される。
【０２１８】
ステップＳ５２において、制御部５８は、ステップＳ５１の確認結果に基づいて、受信装置１２が、capability要素に指定された条件に適合しているか否かを判定する。ステップＳ５２において、capability要素に指定された条件に適合していると判定された場合、処理は、ステップＳ５３に進められる。
【０２１９】
ステップＳ５３において、制御部５８は、TPTのcapability要素に、“flute”が指定されているか否かを判定する。ステップＳ５３において、TPTのcapability要素に、“flute”が指定されていると判定された場合、放送波にてNRTサービスの伝送が行われているので、処理は、ステップＳ５４に進められる。
【０２２０】
ステップＳ５４において、フルート処理部６３は、制御部５８からの制御に従い、NRT-ITを参照して、TPTから得られるアプリURLと同一のInternet Locationが指定されているか否かを判定する。ステップＳ５４において、同一のURLが指定されていると判定された場合、処理は、ステップＳ５５に進められる。
【０２２１】
ステップＳ５５において、フルート処理部６３は、制御部５８からの制御に従い、SMTを参照して、Internet Locationに関連付けられたService ID（NRT-IT）と同一のService ID（SMT）の検索を行い、当該条件に一致するNRTサービスを特定する。
【０２２２】
ステップＳ５６において、フルート処理部６３は、制御部５８からの制御に従い、特定されたService IDに関連付けられたIP(src)、IP(dest)、FLUTE Session Infoを取得し、それらの組み合わせにより特定されるFLUTEセッションから、TOI=0となるFDTを取得する。
【０２２３】
ステップＳ５７において、フルート処理部６３は、制御部５８からの制御に従い、FDTを参照して、Internet Locationに関連付けられたContent Linkage（NRT-IT）と同一のContent Linkage（FDT）の検索を行い、当該条件に一致するContent Linkageに関連付けられたTOIを特定する。
【０２２４】
ステップＳ５８において、フルート処理部６３は、制御部５８からの制御に従い、FLUTEセッションにおいて、特定されたTOIにより識別されるオブジェクトに基づいて、データ放送アプリを取得し、キャッシュメモリ６５に保持させる。これにより、放送波からデータ放送用アプリが取得されたことになる。
【０２２５】
一方、ステップＳ５３において、TPTのcapability要素に、“flute”が指定されていないと判定された場合、又はステップＳ５４において、同一のURLが指定されていないと判定された場合、放送波からデータ放送用アプリを取得することができないので、処理は、ステップＳ５９に進められる。
【０２２６】
ステップＳ５９において、アプリエンジン６４は、制御部５８からの制御に従い、通信I/F６１を制御して、インターネット２０を介してアプリサーバ１４にアクセスし、データ放送用アプリを要求する。通信I/F６１は、アプリサーバ１４からのデータ放送用アプリを受信し、キャッシュメモリ６５に保持させる。この場合、放送波の代わりにインターネット２０を介してデータ放送用アプリが取得されたことになる。なお、アプリサーバ１４にアクセスする際のURLは、NRT-ITのInternet Location、又はTPTのアプリURLのいずれを参照してもよい。
【０２２７】
ステップＳ５８又はＳ５９の処理が終了すると、処理は、図２０のステップＳ３３又はＳ３６に戻り、それ以降が繰り返される。
【０２２８】
なお、ステップＳ５２において、capability要素に指定された条件に適合していないと判定された場合、処理は、ステップＳ６０に進められる。ステップＳ６０において、制御部５８は、当該コマンドを無効化する。その後、処理は、図１９のステップＳ１９に戻り、それ以降の処理が繰り返される。
【０２２９】
以上で、アプリ取得処理の説明を終了する。アプリ取得処理においては、原則として放送波により伝送されるデータ放送用アプリが取得されるが、例えばNRTサービスが提供されていない場合や、受信装置１２が取得すべきデータ放送用アプリが放送波に存在しない場合などには、インターネット２０を介してアプリサーバ１４から、データ放送用アプリが取得される。
【０２３０】
［TPTの取得方法］
ところで、前述した説明では、domain_name又はprogram_idの値が変化したとき、新たなTPTファイルを取得するとして説明したが、当該TPTファイルの取得の際には、受信装置１２の性能に応じたTPTファイルが取得されるようにしてもよい。例えば、受信装置１２の性能に応じたデータ放送用アプリが複数用意されている場合には、当該性能のクラスごとにTPTファイルが独立して用意されることになる。
【０２３１】
図２２に示すように、TPTサーバ１３は、クラスごとのTPTファイルを、所定のTPTフォルダに格納して保持する。受信装置１２は、放送波に含めて送られるトリガ情報から得られるURLに基づいて、TPTサーバ１３にアクセスすることになるが、当該URLには、所定のTPTファイルが指定されるのではなく、所定のTPTフォルダが指定されるものとする。また、受信装置１２には、TPTファイルの取得の優先度が、あらかじめ設定されており、TPTフォルダに格納されたTPTファイルを優先度に応じて指定することが可能となる。
【０２３２】
例えば、TPTサーバ１３において、TPTフォルダに、Main.tpt，Sub1.tpt，Sub2.tptのTPTファイルが格納されている場合に、受信装置１２で、Main.tpt，Sub1.tpt，Sub2.tptの順に取得の優先度が設定されているときには、その優先度の順序でのファイルの取得を試みる。このとき、受信装置１２は、トリガ情報から取得したURLを示す文字列に、TPTファイル名の文字列を付加することで、TPTフォルダに格納された所定のファイルにアクセスすることが可能となる。
【０２３３】
また、例えば、Main.tptが最も高い性能を要求するクラスに対応するTPTファイル、Sub1.tptがその次に高い性能を要求するクラスに対応するTPTファイル、Sub2.tptが最も低い性能を要求するクラスに対応するTPTファイルとすれば、受信装置１２は、まず、Main.tptを取得して、自身の性能が、要求される性能を満たしているかを確認する。受信装置１２は、要求される性能の満たしている場合には、Main.tptをTPTとして保持する。
【０２３４】
一方、Main.tptにより要求される性能を満たしていない場合、受信装置１２は、次にSub1.tptを取得する。受信装置１２は、Sub1.tptにより要求される性能を満たしている場合、Sub1.tptをTPTとして保持し、要求される性能を満たしていない場合には、次にSub2.tptを取得する。そして、受信装置１２は、Sub2.tptにより要求される性能を満たしている場合、Sub2.tptをTPTとして保持する。
【０２３５】
一方、Sub2.tptにより要求される性能を満たしていない場合、受信装置１２は、トリガ情報に含まれるdomain_name又はprogram_idの値が変化するまでは、TPTの取得動作と、データ放送用アプリの動作を行わないことになる。
【０２３６】
なお、上記の説明では、放送波に含めて送られるトリガ情報について説明したが、第２の実施の形態として後述する、ACR識別処理の識別結果に応じたトリガ情報（ACR Response）を取得した場合についても同様にクラスごとのTPTファイルを取得することができる。
【０２３７】
［クラスに対応したTPTの詳細］
図２３は、クラスに対応したTPTのフォーマットの例を示す図である。
【０２３８】
図２３のTPTは、図１３のTPTと比べて、tpt要素に、capability要素が加えられて、application要素のcapability要素が削除されている。それ以外の要素や属性については、図１３と同様であるため、その説明は省略する。
【０２３９】
tpt要素のcapability要素には、受信装置に要求される各種の性能が指定される。capability要素は、essential属性を含む。essential属性には、要求される性能が、必須の性能である場合には、“yes”が指定され、オプションの性能である場合には、“no”が指定される。
【０２４０】
なお、当該capability要素には、例えば、前述した図１４に示した値が指定される。
【０２４１】
［クラスに対応したTPTの記述例］
図２４は、クラスに対応したTPTの記述例を示す図である。
【０２４２】
tpt要素の開始タグの次に、capability要素として、“flute”が記述される。また、capability要素には、essential属性として、“no”が指定されている。すなわち、FLUTEセッションは、オプションの機能となるため、受信装置１２は、FLUTEセッションの機能に対応していなくてもよいことになる。この記述例の場合、受信装置１２がFLUTEセッションの機能に対応していない場合には、アプリサーバ１４からデータ放送用アプリを取得すればいいので、essential属性には“no”が指定されている。
【０２４３】
また、capability要素として、“avc_40”が記述され、そのessential属性として、“yes”が指定されている。すなわち、AVC level4.0は、必須の機能となるため、受信装置１２は、AVC level4.0で圧縮符号化されたコンテンツを再生する機能に対応している必要がある。この記述例の場合、受信装置１２がAVC level4.0に対応していないと、データ放送用アプリから起動されるコンテンツを再生することができないので、essential属性に“yes”が指定されている。
【０２４４】
なお、それ以外の記述については、図１５のTPTの記述例と基本的に同様であるため、その説明は省略する。
【０２４５】
［TPT取得処理］
次に、図２５のフローチャートを参照して、TPT取得処理について説明する。なお、TPT取得処理は、図１９のステップＳ１４に対応する処理である。
【０２４６】
ステップＳ７１において、制御部５８は、抽出したトリガ情報から得られるURLに第１候補TPTファイル名（例えばMain.tpt）を指定し、通信I/F６１を制御してTPTサーバ１３にアクセスして、TPTファイルを要求する。
【０２４７】
ステップＳ７２において、TPT解析部６２は、通信I/F６１を制御して、TPTサーバ１３からのTPTファイル（例えばMain.tpt）を取得する。
【０２４８】
ステップＳ７３において、制御部５８は、TPT解析部６２からのTPTのcapability要素に指定された性能を、受信装置１２が有しているかを確認する。ここでは、例えば、capability要素に“avc_42”が指定された場合、受信装置１２がAVC level4.2で圧縮符号化されたコンテンツの再生機能に対応しているかが確認される。
【０２４９】
ステップＳ７４において、制御部５８は、ステップＳ７３の確認結果に基づいて、受信装置１２が、capability要素に指定された条件に適合しているか否かを判定する。ステップＳ７４において、capability要素に指定された条件に適合していると判定された場合、処理は、ステップＳ７５に進められる。
【０２５０】
ステップＳ７５において、制御部５８は、capability要素に指定された条件に適合したTPTファイルを、保持する対象として選択する。これにより、図１９のステップＳ１６にて、TPT解析部６２によって、当該TPTファイルが保持される。
【０２５１】
一方、ステップＳ７４において、capability要素に指定された条件に適合していないと判定された場合、処理は、ステップＳ７６に進められる。ステップＳ７６において、制御部５８は、トリガ情報から得られるURLに次候補TPTファイル名（例えばSub1.tpt）を指定し、通信I/F６１を制御してTPTサーバ１３にアクセスして、TPTファイルを要求する。
【０２５２】
ステップＳ７７において、通信I/F６１を制御して、TPTサーバ１３からのTPTファイル（例えばSub1.tpt）を取得する。
【０２５３】
ステップＳ７８において、制御部５８は、TPT解析部６２からのTPTのcapability要素に指定された性能を、受信装置１２が有しているかを確認する。ここでは、例えば、capability要素に“avc_40”が指定された場合、受信装置１２がAVC level4.0で圧縮符号化されたコンテンツの再生機能に対応しているかが確認される。
【０２５４】
ステップＳ７９において、ステップＳ７８の確認結果に基づいて、受信装置１２が、capability要素に指定された条件に適合しているか否かを判定する。ステップＳ７９において、capability要素に指定された条件に適合していると判定された場合、処理は、ステップＳ７５に進められ、当該TPTファイルが、保持する対象として選択される。
【０２５５】
一方、ステップＳ７９において、capability要素に指定された条件に適合していないと判定された場合、処理は、ステップＳ８０に進められる。ステップＳ８０において、制御部５８は、次のTPTファイル候補が存在するか否かを確認する。
【０２５６】
ステップＳ８０において、次のTPTファイル候補が存在すると判定された場合、処理は、ステップＳ７６に戻り、以降の処理が繰り返される。ここでは、例えば、URLに次候補TPTファイル名としてSub2.tptが指定され、取得されたSub2.tptのcapability要素に指定された条件に適合するか否かが判定されることになる。
【０２５７】
なお、ステップＳ８０において、次のTPTファイル候補が存在しないと判定された場合、処理は、ステップＳ８１に進められる。ステップＳ８１において、制御部５８は、所定のエラー処理を行う。その後、処理は、図１９のステップＳ１２に戻り、それ以降の処理が繰り返される。
【０２５８】
以上で、TPT取得処理の説明を終了する。TPT取得処理においては、domain_name又はprogram_idの値が変化した場合に、新たなTPTファイルを取得するとき、受信装置１２の性能に応じたTPTファイルが取得されることになる。
【０２５９】
以上、第１の実施の形態について説明した。
【０２６０】
＜第２の実施の形態＞
［放送システムの構成例］
図２６は、第２の実施の形態である放送システム１０１を示している。この放送システム１０１は、放送装置１１、TPTサーバ１３、アプリサーバ１４、ACRサーバ１１１、及び受信装置１１２から構成される。また、TPTサーバ１３、アプリサーバ１４、ACRサーバ１１１、及び受信装置１１２は、インターネット２０を介して、相互に接続されている。
【０２６１】
すなわち、図２６の放送システム１０１は、図１０の放送システム１と比べて、ACRサーバ１１１が新たに設けられ、受信装置１２の代わりに、受信装置１１２が設けられている。それ以外の構成については、図１０と同様であるため、その説明は適宜省略する。
【０２６２】
受信装置１１２は、定期的に、インターネット２０を介してACRサーバ１１１にアクセスして、トリガ情報を問い合わせる。その際、テレビ番組等のＡＶコンテンツの映像信号及び音声信号のうちいずれか一方又は双方から抽出される特徴量（以下、フィンガプリント情報（Finger Print）ともいう）が、ACRサーバ１１１に送信される。
【０２６３】
ACRサーバ１１１は、例えば、放送装置１１にてテレビ番組の放送を行う放送事業者又はそれ以外の事業者により提供される。ACRサーバ１１１は、任意のＡＶコンテンツの映像信号及び音声信号から抽出された特徴量が登録されているデータベースを有しており、インターネット２０に接続された任意の受信装置１１２からの問い合わせに応じて、ACR技術を用いたＡＶコンテンツの識別処理を行う。
【０２６４】
具体的には、ACRサーバ１１１は、受信装置１１２からのフィンガプリント情報を、データベースと照合することで、ＡＶコンテンツを識別し、その識別結果に応じたトリガ情報（ACR Response）を生成する。ACRサーバ１１１は、生成したトリガ情報を、インターネット２０を介して受信装置１１２に送信する。
【０２６５】
受信装置１１２は、ACRサーバ１１１から受信したトリガ情報に応じて、インターネット２０を介してTPTサーバ１３にアクセスして、TPTを取得する。受信装置１１２は、TPTサーバ１３から取得したTPTに基づいて、放送装置１１からのトリガ情報から得られるＡＶコンテンツの進行を示す時刻が有効期間内となるか、又は有効開始時刻を経過した場合、その有効なコマンドを特定する。
【０２６６】
受信装置１１２は、特定したコマンドに応じて、データ放送用アプリの動作を制御する。また、受信装置１１２は、特定したコマンドに応じて、放送波により伝送されるデータ放送用アプリを取得する。ただし、受信装置１１２は、放送波により伝送されるデータ放送用アプリを取得できなかった場合、インターネット２０を介してアプリサーバ１４にアクセスし、データ放送用アプリを取得する。
【０２６７】
放送システム１０１は、以上のように構成される。
【０２６８】
［受信装置の構成例］
図２７は、図２６の受信装置１１２の構成例を示している。
【０２６９】
受信装置１１２は、図１１の受信装置１２と同様に、チューナ５１乃至アプリ用メモリ６６を有するが、図１１の受信装置１２と比べて、トリガ抽出部５７の代わりに、フィンガプリント抽出部１５１が設けられている点が異なる。受信装置１１２において、図１１の受信装置１２と同様の箇所には同一の符号が付してあり、その説明は適宜省略する。
【０２７０】
フィンガプリント抽出部１５１には、音声デコーダ５３からの音声信号と、映像デコーダ５５からの映像信号が供給される。フィンガプリント抽出部１５１は、音声信号及び映像信号のいずれか一方又は双方から特徴量を抽出し、フィンガプリント情報として、制御部５８に供給する。
【０２７１】
制御部５８は、通信I/F６１を制御して、フィンガプリント抽出部１５１からのフィンガプリント情報を、インターネット２０を介してACRサーバ１１１に送信する。また、通信I/F６１は、ACRサーバ１１１から送信されるトリガ情報を受信し、制御部５８に供給する。
【０２７２】
制御部５８は、取得したトリガ情報に応じて、通信I/F６１を制御して、インターネット２０を介してTPTサーバ１３にアクセスし、TPTを要求する。通信I/F６１は、TPTサーバ１３からインターネット２０を介して送信されるTPTを受信し、TPT解析部６２に供給する。これにより、TPT解析部６２は、内部に備えるメモリ（不図示）にTPTを保持し、制御部５８からの要求に応じて、メモリに保持しているTPTを供給する。
【０２７３】
また、制御部５８は、TPT解析部６２からのTPTに基づいて、通信I/F６１からのトリガ情報に含まれる時刻情報（media_time）から得られるＡＶコンテンツの進行を示す時刻がコマンドの有効期間内となるか、又は有効開始時刻を経過した場合、その有効なコマンドを特定する。制御部５８は、特定したコマンドに応じて、データ放送用アプリの取得若しくは登録、取得若しくは起動、イベント発火、中断、又は終了等を制御する。
【０２７４】
受信装置１１２は、以上のように構成される。
【０２７５】
［トリガ情報とコマンドの対応関係］
次に、フィンガプリント情報に応じて取得されるトリガ情報に対応付けられたコマンドを、TPTによって特定する処理の例を説明する。図２８は、トリガ情報とコマンドの対応関係の例を示す図である。
【０２７６】
図２８に示すように、受信装置１１２では、トランスポートストリームより得られるフィンガプリント情報が定期的に抽出されると、当該フィンガプリント情報は、ACRサーバ１１１（図中の「ACRシステム」）に送信される。ACRサーバ１１１では、受信装置１１２からのフィンガプリント情報に基づいて、トリガ情報が生成され、受信装置１１２に送信される。
【０２７７】
受信装置１１２は、定期的に抽出するフィンガプリント情報に応じて、トリガ情報を取得すると、トリガ情報に含まれるdomain_name及びprogram_idのうちいずれか一方又は双方に基づいて、TPTサーバ１３からTPTを取得するか否かが判定される。例えば、受信装置１１２は、program A用のTPT（for program A）を保持している場合に、取得したトリガ情報に含まれるprogram_idの値が変化したとき、TPTサーバ１３にアクセスして、TPTを取得する。これにより、受信装置１１２では、図中のTPT（for program B）が保持される。
【０２７８】
フィンガプリント情報に応じて取得されるトリガ情報に含まれるmedia_timeに対応付けられたコマンドを、TPTによって特定する処理のうち、トリガ情報を取得した後の処理については、図１６を参照して説明した処理と同様である。すなわち、フィンガプリント情報の抽出に応じて定期的に取得されるトリガ情報に含まれるmedia_timeが、TPT（for program B）に格納された各コマンドの有効期間内となるかが判定され、有効なコマンドが特定される。
【０２７９】
このように、受信装置１１２は、定期的に抽出されるフィンガプリント情報に応じて取得されるトリガ情報に含まれるmedia_timeが有効期間内となる場合、その有効なコマンドに応じて、データ放送用アプリの動作を制御する。
【０２８０】
［トリガ情報対応処理］
次に、受信装置１１２がトリガ情報を受信したときのトリガ情報対応処理について説明する。
【０２８１】
（ACR識別結果に応じたトリガ情報対応処理）
図２９は、ACR識別結果に応じたトリガ情報対応処理を示すフローチャートである。
【０２８２】
受信装置１１２は、ユーザの操作によって、所定のチャンネルが選局されると、そのチャンネルのテレビ番組の映像の表示を開始する（ステップＳ１１１）。
【０２８３】
ステップＳ１１２において、フィンガプリント抽出部１５１は、所定の時間を経過するまで待機する。そして、所定の時間が経過した場合、処理は、ステップＳ１１３に進められる。
【０２８４】
ステップＳ１１３において、フィンガプリント抽出部１５１は、音声信号及び映像信号のいずれか一方又は双方から特徴量（フィンガプリント情報）を抽出する。
【０２８５】
ステップＳ１１４において、制御部５８は、通信I/F６１を制御して、フィンガプリント情報を、インターネット２０を介してACRサーバ１１１に送信することで、トリガ情報を問い合わせる。
【０２８６】
ここで、フィンガプリント情報は、例えば、ＡＶコンテンツの全体又は一部構成要素の固有情報である。ACRサーバ１１１には、あらかじめ多数のＡＶコンテンツの固有情報が登録されており、ACR識別処理では、それらの固有情報の類似度又は一致度が判定される。このACR識別処理によって、テレビ番組のチャンネル番号を識別するための情報（以下、チャンネル識別情報という）と、テレビ番組の開始から終了までを時間軸で表したときのフィンガプリント情報が抽出された時間位置を示す情報（以下、時間位置情報という）が得られる。
【０２８７】
また、ACRサーバ１１１には、例えば、チャンネル識別情報に対応して、TPTサーバ１３を特定するためのサーバ特定情報及びＡＶコンテンツを識別するためのコンテンツ識別情報があらかじめ登録されている。ACRサーバ１１１は、ACR識別処理で得られたチャンネル識別情報に対応するサーバ特定情報及びコンテンツ識別情報を取得し、サーバ特定情報をdomain_name、コンテンツ識別情報をprogram_id、ACR識別処理で得られた時間位置情報をmedia_timeとして、トリガ情報（ACR Response）を生成する。ACRサーバ１１１は、生成したトリガ情報を、インターネット２０を介して受信装置１１２に送信する。
【０２８８】
ステップＳ１１５において、制御部５８は、通信I/F６１を制御して、ACRサーバ１１１からトリガ情報を受信したか否かを判定する。ステップＳ１１５において、トリガ情報を受信していないと判定された場合、処理は、ステップＳ１１２に戻り、以降の処理が繰り返される。一方、ステップＳ１１５において、トリガ情報を受信したと判定された場合、処理は、ステップＳ１１６に進められる。
【０２８９】
ステップＳ１１６乃至Ｓ１２３においては、図１９のステップＳ１３乃至Ｓ２０と同様に、例えば、ACRサーバ１１１から受信したトリガ情報に含まれるdomain_name，program_idが変化した場合、TPT解析部６２によって、TPTが取得され、取得されたTPTが未取得であれば保持される。また、制御部５８によって、受信したトリガ情報に含まれるmedia_timeが有効期間内となると判定された場合、その有効なコマンドに応じて、データ放送用アプリの動作が制御される。
【０２９０】
なお、ACR識別結果に応じたトリガ情報対応処理においても、データ放送用アプリを取得する場合には、原則として、TPTのアプリURLに応じたNRT-ITのInternet Locationが特定され、SMT及びNRT-ITを逆引きすることで、FLUTEセッションにて伝送されるデータ放送用アプリが取得されることになる。ただし、放送波から取得できない場合には、データ放送用アプリは、インターネット２０を介してアプリサーバ１４から取得される。
【０２９１】
また、前述したように、ステップＳ１１７において、図２５のTPT取得処理を行い、受信装置１１２の性能に応じたTPTファイルが取得されるようにしてもよい。
【０２９２】
以上で、ACR識別結果に応じたトリガ情報対応処理を終了する。
【０２９３】
以上、第２の実施の形態について説明した。
【０２９４】
なお、第１の実施の形態及び第２の実施の形態においては、トリガ情報の取得経路は異なるが、受信装置１２及び受信装置１１２にて取得されるトリガ情報及びTPTの形態は同一であるため、図３０に示すように、それらの実施の形態を同時に運用することもできる。
【０２９５】
また、前述の説明では、TPTサーバ１３、アプリサーバ１４、及びACRサーバ１１１など、提供する機能ごとにサーバを複数設ける例を説明したが、それらの機能の全部又は一部をまとめて、１又は複数のサーバにより提供されるようにしてもよい。
【０２９６】
［具体的な運用例］
次に、図３１乃至図３４を参照して、図１３のTPTのtpt要素の各属性の値を指定して受信装置１２（受信装置１１２）を動作させることで、実現可能な運用例について説明する。
【０２９７】
図３１は、tpt要素のtype属性を説明する図である。
【０２９８】
図３１の（Ａ）は、type属性に“static”が指定された場合のTPTの更新のタイミングを示している。例えば、受信装置１２において、あるテレビ番組のトランスポートストリームから抽出されたトリガ情報に応じたTPT1が保持されている場合、TPT1には、あるテレビ番組にて実行されるデータ放送用アプリの動作を制御するためのすべての情報が記述されている。
【０２９９】
そのため、あるテレビ番組に割り当てられたprogram_idが変更されない限り、TPT1を更新する必要がないが、program_idが変更された場合には、新たなprogram_idに対応するTPTが取得され、更新される。このように、type属性に“static”が指定された場合、program_idの変更がないときは、TPTは静的に保持される。
【０３００】
図３１の（Ｂ）は、type属性に“dynamic”が指定された場合のTPTの更新のタイミングを示している。例えば、受信装置１２において、あるテレビ番組のトランスポートストリームから抽出されたトリガ情報に応じたTPT1aが保持されている場合、TPT1aには、あるテレビ番組にて実行されるデータ放送用アプリの動作を制御するための情報の一部が記述されている。
【０３０１】
そのため、受信装置１２は、TPT1aを取得して保持した後、TPT1aのtpt要素のupdating_time属性が示す更新期間に応じて、TPTサーバ１３からTPT1bを取得して保持する。これにより、あるテレビ番組に割り当てられたprogram_idが変更されていない場合であっても、TPTが取得され、更新される。図３１の例では、TPT1a及びTPT1bにおいて、1である数字がprogram_idを示し、a，bであるアルファベットがversionを示している。つまり、TPT1aとTPT1bは、同一のprogram_idで、異なるversionのTPTである。なお、versionは、tpt要素のversion属性により指定される。
【０３０２】
また、異なるversionのTPT1aとTPT1bには、例えば、あるテレビ番組の進行にあわせて、そのテレビ番組にて実行されるデータ放送用アプリの動作を制御するためのすべての情報のうち一部が記述される。また、TPT1aとTPT1bの記述であるが、例えば、一部の情報が重複するように記述される。例えば、前述した、図１５のTPTに記述された内容が、あるテレビ番組にて実行されるデータ放送用アプリの動作を制御するためのすべての情報であるとすれば、TPT1aには、1乃至4であるid属性が指定されたcommand要素の内容が記述され、TPT1bには、4乃至12であるid属性が指定されたcommand要素の内容が記述される。つまり、この例の場合、TPT1aとTPT1bには、4であるid属性が指定されたcommand要素の内容が重複して記述されることになる。
【０３０３】
このように、type属性に“dynamic”が指定された場合、あるテレビ番組に割り当てられたprogram_idの変更がなくても、新たなversionに対応するTPTが取得され、更新される。すなわち、TPTは、program_idの変更に関係なく、動的に保持される。
【０３０４】
なお、type属性に“dynamic”が指定される場面としては、例えば、１つのチャンネルに対して、１つのprogram_idが割り当てられる場合、すなわち、チャンネル単位での認識はできるが、そのチャンネルで放送される番組単位での認識をすることができない場面が想定される。
【０３０５】
次に、type属性に“static”又は“dynamic”が指定された場合の具体的な運用例について説明する。
【０３０６】
図３２は、type属性に“static”が指定される場合の運用例を示している。
【０３０７】
図３２の運用例では、放送事業者側で、どのようなタイムスケジュールでテレビ番組やＣＭが放送され、どのようなTPTが必要となるか確定している場合に、受信装置１２が、TPTサーバ１３から必要なTPTをまとめて取得できるようにする。
【０３０８】
例えば、図３２に示すように、Program Aと、Program Bであるテレビ番組の間に、Program a，Program b，Program cであるＣＭが挿入される場面を想定する。この場合、ＣＭは15秒や30秒などの短い時間で放送されるため、ＣＭの放送が開始してからTPTを取得すると、データ放送用アプリの起動が間に合わない可能性がある。そこで、受信装置１２は、Program Aであるテレビ番組用のTPTAを取得する際に、Program aであるＣＭ用のTPTa、Program bであるＣＭ用のTPTb，Program cであるＣＭ用のTPTcをまとめて取得して、それらのTPTを保持する。
【０３０９】
これにより、受信装置１２は、例えば、Program Aであるテレビ番組から、Program aであるＣＭに切り替わった場合に、あらかじめ保持しているTPTaに基づいて、抽出されたトリガ情報に含まれるmedia_timeに応じたコマンドを特定し、特定されたコマンドに応じて、データ放送用アプリの動作を制御することができる。
【０３１０】
また、ＣＭは、例えば１ヶ月間など、所定の期間繰り返し放送されるが、TPTa，TPTb，TPTcのtpt要素のexpire_date属性に、その期間を指定しておくことで、受信装置１２はその指定された期間だけ、TPTa，TPTb，TPTcを保持する。その結果、例えば、Program Mであるテレビ番組に、Program a，Program cであるＣＭが挿入された場合、受信装置１２は、expire_date属性により指定された期間内であれば、保持しているTPTa，TPTcに基づいて、抽出されたトリガ情報に含まれるmedia_timeに応じたコマンドを特定できる。
【０３１１】
ところで、前述した説明では、トリガ情報に含まれるmedia_timeの示す時刻が、TPTのcommand要素のstart_time属性とend_time属性により定められる有効期間内となる場合に、その有効なコマンドが特定されことで、データ放送用アプリの運用が行われる方法（以下、メソッド１という）を説明した。しかしながら、メソッド１では、トリガ情報が抽出されたタイミングでコマンドを特定するため、トリガ情報を抽出するタイミングでしかコマンドを実行することができない。そのため、トリガ情報の抽出の間隔が長くなればなるほど、適切なタイミングでコマンドを実行することができない場合が出てくる。そこで、受信装置１２が、トリガ情報に含まれるmedia_timeに基づいて、ＡＶコンテンツの進行を示す時刻を計時し、その内部で計時された時刻が有効期間内となるタイミングで、コマンドが特定される方法（以下、メソッド２という）を採用することもできる。
【０３１２】
ここで、ＡＶコンテンツの進行を示す時刻を計時する受信装置１２の内部時計機能を、メディアクロック（media clock）と称する。すなわち、受信装置１２は、トリガ情報に含まれるmedia_timeをリファレンス情報として用いることで、メディアクロックを生成している。
【０３１３】
なお、メソッド１とメソッド２を比較すれば、前述のとおり、メソッド２のほうが、より適切なタイミングでコマンドを実行することが可能となるが、受信装置１２では、メディアクロックに関する各種の動作をしなければならないため、メソッド１よりも処理に負荷がかかる。そのため、例えば、コマンドの実行のタイミングの優先度や、受信装置１２の処理能力などの条件に応じて、いずれの方法を選択するかを決定することが望ましい。また、いずれの方法を選択したとしても、受信装置１２にて受信されるトリガ情報の形態には影響がないため、例えば、放送装置１１を提供する放送事業者側からすれば、受信装置１２側で、メソッド１とメソッド２のいずれが採用されても関係がないことになる。
【０３１４】
図３３は、type属性に“static”が指定される場合の運用例を示している。
【０３１５】
図３３の運用例では、放送事業者側で、どのようなタイムスケジュールでテレビ番組やＣＭが放送され、どのようなTPTが必要となるか確定している場合に、あるテレビ番組のTPTと、その次に放送されるテレビ番組のTPTが対になって取得できるようにする。
【０３１６】
例えば、図３３の上段に示すように、Program Aであるテレビ番組の次に、Program Bであるテレビ番組が放送され、Program Bであるテレビ番組の次に、Program Cであるテレビ番組が放送される場面を想定する。この場合、受信装置１２は、Program Aであるテレビ番組用のTPTAを取得する際に、その次に放送されるProgram Bであるテレビ番組用のTPTBをも取得する。
【０３１７】
そして、受信装置１２は、取得した現在のテレビ番組用のTPTAと、次のテレビ番組用のTPTBを保持するが、それらのTPTは、tpt要素のpresent_following属性により区別される。すなわち、TPTA（図中のTPTA for P）には、present_following属性として“present”が指定され、TPTB（図中のTPTB for F）には、present_following属性として“following”が指定される。
【０３１８】
また、受信装置１２は、Program Bであるテレビ番組を受信したとき、その次に放送されるProgram Cであるテレビ番組用のTPTCを取得して保持する。このとき、TPTB（図中のTPTB for P）には、present_following属性として“present”が指定され、TPTC（図中のTPTC for F）には、present_following属性として“following”が指定される。
【０３１９】
ここで、Program Aであるテレビ番組から、Program Bであるテレビ番組に切り替わるときに行われる処理の詳細を、図３３の下段に示す。
【０３２０】
この例では、切り替え直前のProgram Aであるテレビ番組のトランスポートストリームからはトリガ情報として、第１のトリガ情報（program_id = a ，media_time = 300秒）、第２のトリガ情報（program_id = a ，media_time = 310秒）が順次抽出される。また、切り替え直後のProgram Bであるテレビ番組のトランスポートストリームからはトリガ情報として、第３のトリガ情報（program_id = b ，media_time = 8秒）が抽出される。なお、Program Aであるテレビ番組と、Program Bであるテレビ番組は、同一の放送事業者により提供されるため、domain_nameが同一となるので、その記述は省略している。
【０３２１】
また、前述のとおり、受信装置１２には、TPTA（図中のTPTA for P）と、TPTB（図中のTPTB for F）が対になって保持されている。また、TPTAのtpt要素のend_mt属性には、312秒が指定されており、Program Aであるテレビ番組は、312秒であるmedia_timeで終了する。
【０３２２】
図３３において、受信装置１２は、前述したメソッド２により動作しており、トリガ情報に含まれるmedia_timeに基づいて、Program Aであるテレビ番組用のメディアクロックを計時している。従って、受信装置１２は、Program Aであるテレビ番組用のメディアクロックの示す時刻がend_mt属性に指定された312秒となったとき、Program Aであるテレビ番組が終了することを認識できる。このとき、受信装置１２は、現在のテレビ番組用のTPTを、TPTAからTPTBに切り替える。また、受信装置１２は、Program Bであるテレビ番組用のメディアクロックとして、0秒から計時を開始する。これにより、受信装置１２では、テレビ番組の切り替え直後から、Program Bであるテレビ番組用のメディアクロックの示す時刻が、TPTBのコマンドの有効期間内となる場合に、その有効なコマンドが特定されることになる。
【０３２３】
すなわち、仮に、present_following属性と、end_mt属性を指定しない場合には、Program AからProgram Bであるテレビ番組に切り替えられても、第３のトリガ情報が抽出されるまでは、Program Aであるテレビ番組用のメディアクロックを計時しているため、Program Bであるテレビ番組用のデータ放送用アプリの動作を制御することができない。例えば、図３３の例の場合、Program Bであるテレビ番組への切り替え後、第３のトリガ情報に含まれるmedia_timeの示す8秒までの時間は、Program Bであるテレビ番組用のメディアクロックを計時できない。そこで、図３３の下段の例では、end_mt属性を指定して、テレビ番組の切り替え直後から、切り替え後のテレビ番組用のメディアクロックが計時されるようにすることで、データ放送用アプリの動作を、厳密に制御することができるようにしている。
【０３２４】
なお、図３３の下段の説明では、テレビ番組の切り替え時について説明したが、テレビ番組とＣＭの切り替えでも同様である。図３３の上段には、Program Mであるテレビ番組から、Program ａであるＣＭに切り替えられ、さらに、Program ａであるＣＭから、Program bであるＣＭに切り替えられる例が図示されている。この場合も同様に、present_following属性と、end_mt属性を指定することで、例えば、ＣＭへの切り替え直後から、切り替え後のＣＭ用のメディアクロックが計時され、ＣＭ用のデータ放送用アプリの動作が厳密に制御される。
【０３２５】
図３４は、type属性に“dynamic”が指定される場合の運用例を示している。
【０３２６】
図３４の運用例では、例えば、１つのチャンネルに対し、１つのprogram_idが割り当てられている場合に、tpt要素のupdating_time属性を指定することで、TPTの更新が行われるようにする。
【０３２７】
ライブ放送の番組等では、次に動作させるべきデータ放送用アプリが予測できないため、放送事業者は、受信装置１２に対して、例えば、ある時点から１分後までの内容が記述されたTPTを取得させて、その後、さらに１分後までの内容が記述されたTPTを取得させるといった運用が予想される。
【０３２８】
図３４に示すように、受信装置１２では、Program Aであるライブ番組が選局されると、TPTサーバ１３からTPTA1が取得され、保持される。TPTA1には、tpt要素のupdating_time属性が指定されており、受信装置１２は、updating_time属性の示す時刻に応じて、TPTサーバ１３からTPTA2を取得して保持する。これにより、program_idが変更されていない場合であっても、受信装置１２では、updating_time属性により指定される更新期間に応じて、TPTが取得され、更新される。
【０３２９】
同様に、受信装置１２は、保持しているTPTA2のupdating_time属性の示す時刻に応じて、TPTサーバ１３からTPTA3を取得して保持する。さらに、受信装置１２は、保持しているTPTA3のupdating_time属性の示す時刻に応じて、TPTサーバ１３からTPTA4を取得して保持する。
【０３３０】
これにより、ライブ番組等の将来の内容が予測できない番組であっても、番組の進行状況に応じて適宜、TPTを更新するといった運用が可能となる。
【０３３１】
なお、この例では、TPTA1，TPTA2，TPTA3，TPTA4において、Aであるアルファベットがprogram_idを示し、1，2，3，4である数字がversionを示している。このようにTPTがバージョンで管理されているため、例えば、受信装置１２は、updating_time属性の示す時刻に応じて、TPTサーバ１３から、次のバージョンのTPTを取得しようとしたが、取得できない場合には、次のトリガ情報が抽出されたタイミングで、再度、次のバージョンのTPTの取得を試みるようにすればよい。このような、次のバージョンのTPTを取得できないケースとしては、例えば、TPTサーバ１３側で、次のバージョンのTPTの準備ができていない場合などが想定される。
【０３３２】
以上、具体的な運用例について説明した。
【０３３３】
［本技術を適用したコンピュータの説明］
前述した一連の処理は、ハードウェアにより実行することもできるし、ソフトウェアにより実行することもできる。一連の処理をソフトウェアにより実行する場合には、そのソフトウェアを構成するプログラムが、コンピュータにインストールされる。ここで、コンピュータには、専用のハードウェアに組み込まれているコンピュータや、各種のプログラムをインストールすることで、各種の機能を実行することが可能な、例えば汎用のパーソナルコンピュータなどが含まれる。
【０３３４】
図３５は、前述した一連の処理をプログラムにより実行するコンピュータのハードウェアの構成例を示すブロック図である。
【０３３５】
コンピュータ３００において、CPU（Central Processing Unit）３０１，ROM（Read Only Memory）３０２，RAM（Random Access Memory）３０３は、バス３０４により相互に接続されている。
【０３３６】
バス３０４には、さらに、入出力インタフェース３０５が接続されている。入出力インタフェース３０５には、入力部３０６、出力部３０７、記録部３０８、通信部３０９、及びドライブ３１０が接続されている。
【０３３７】
入力部３０６は、キーボード、マウス、マイクロフォンなどよりなる。出力部３０７は、ディスプレイ、スピーカなどよりなる。記録部３０８は、ハードディスクや不揮発性のメモリなどよりなる。通信部３０９は、ネットワークインタフェースなどよりなる。ドライブ３１０は、磁気ディスク、光ディスク、光磁気ディスク、又は半導体メモリなどのリムーバブルメディア３１１を駆動する。
【０３３８】
以上のように構成されるコンピュータ３００では、CPU３０１が、例えば、記録部３０８に記憶されているプログラムを、入出力インタフェース３０５及びバス３０４を介して、RAM３０３にロードして実行することにより、前述した一連の処理が行われる。
【０３３９】
コンピュータ３００（CPU３０１）が実行するプログラムは、例えば、パッケージメディア等としてのリムーバブルメディア３１１に記録して提供することができる。また、プログラムは、ローカルエリアネットワーク、インターネット、デジタル衛星放送といった、有線又は無線の伝送媒体を介して提供することができる。
【０３４０】
コンピュータ３００では、プログラムは、リムーバブルメディア３１１をドライブ３１０に装着することにより、入出力インタフェース３０５を介して、記録部３０８にインストールすることができる。また、プログラムは、有線又は無線の伝送媒体を介して、通信部３０９で受信し、記録部３０８にインストールすることができる。その他、プログラムは、ROM３０２や記録部３０８に、あらかじめインストールしておくことができる。
【０３４１】
なお、コンピュータ３００が実行するプログラムは、本明細書で説明する順序に沿って時系列に処理が行われるプログラムであっても良いし、並列に、あるいは呼び出しが行われたとき等の必要なタイミングで処理が行われるプログラムであっても良い。
【０３４２】
ここで、本明細書において、コンピュータ３００に各種の処理を行わせるためのプログラムを記述する処理ステップは、必ずしもフローチャートとして記載された順序に沿って時系列に処理する必要はなく、並列的あるいは個別に実行される処理（例えば、並列処理あるいはオブジェクトによる処理）も含むものである。
【０３４３】
また、プログラムは、１のコンピュータにより処理されるものであってもよいし、複数のコンピュータによって分散処理されるものであってもよい。さらに、プログラムは、遠方のコンピュータに転送されて実行されるものであってもよい。
【０３４４】
さらに、本明細書において、システムとは、複数の構成要素（装置、モジュール（部品）等）の集合を意味し、すべての構成要素が同一筐体中にあるか否かは問わない。したがって、別個の筐体に収納され、ネットワークを介して接続されている複数の装置、及び、１つの筐体の中に複数のモジュールが収納されている１つの装置は、いずれも、システムである。
【０３４５】
なお、本技術の実施の形態は、前述した実施の形態に限定されるものではなく、本技術の要旨を逸脱しない範囲において種々の変更が可能である。
【０３４６】
例えば、本技術は、１つの機能を、ネットワークを介して複数の装置で分担、共同して処理するクラウドコンピューティングの構成をとることができる。
【０３４７】
また、前述のフローチャートで説明した各ステップは、１つの装置で実行する他、複数の装置で分担して実行することができる。
【０３４８】
さらに、１つのステップに複数の処理が含まれる場合には、その１つのステップに含まれる複数の処理は、１つの装置で実行する他、複数の装置で分担して実行することができる。
【０３４９】
なお、本技術は、以下のような構成をとることができる。
【０３５０】
（１）
放送波により伝送されるＡＶコンテンツを受信する受信部と、
受信した前記ＡＶコンテンツに連動して実行されるアプリケーションプログラムを動作させるためのトリガ情報を取得するトリガ取得部と、
前記トリガ情報と、前記アプリケーションプログラムの動作を制御するためのコマンドとを対応付けた対応テーブルを取得するテーブル取得部と、
取得した前記対応テーブルに基づいて、前記トリガ情報に対応する前記コマンドが前記アプリケーションプログラムの取得を示す場合、前記放送波により伝送される前記アプリケーションプログラムを取得するアプリ取得部と、
前記トリガ情報に対応する前記コマンドに応じて、取得した前記アプリケーションプログラムの動作を制御する制御部と
を備える受信装置。
（２）
前記アプリケーションプログラムは、FLUTE（File Delivery over Unidirectional Transport）セッションを利用したNRT（Non-RealTime）サービスのNRTコンテンツとして伝送され、
前記アプリ取得部は、前記対応テーブルに記述された前記アプリケーションプログラムの取得先を示す取得先情報に基づいて、SMT（Service Map Table）及びNRT-IT（NRT Information Table）により特定されるFDT（File Delivery Table）を参照し、FLUTEセッションにより伝送されるアプリケーションプログラムを取得する
（１）に記載の受信装置。
（３）
前記制御部は、取得する前記アプリケーションプログラムを動作させる上で必要な性能を、前記受信装置が有しているかを確認し、
前記アプリ取得部は、前記受信装置が前記アプリケーションプログラムを動作させる性能を有している場合、FLUTEセッションにより伝送される前記アプリケーションプログラムを取得する
（２）に記載の受信装置。
（４）
前記アプリ取得部は、FLUTEセッションにより伝送される前記アプリケーションプログラムが取得できない場合、前記NRT-ITに記述される前記取得先情報に基づいて、インターネットを介して配信される前記アプリケーションプログラムを取得する
（２）又は（３）のいずれかに記載の受信装置。
（５）
前記対応テーブルは、前記コマンドと、前記コマンドの有効時刻とを対応付けており、
前記制御部は、前記対応テーブルに基づいて、前記トリガ情報から得られる前記ＡＶコンテンツの進行を示す時刻が、前記コマンドの有効時刻を基準にした所定の有効条件を満たした場合、その有効な前記コマンドに応じて、取得した前記アプリケーションプログラムの動作を制御する
（２）乃至（４）のいずれかに記載の受信装置。
（６）
前記トリガ情報は、前記放送波により伝送され、
前記トリガ取得部は、前記放送波により伝送される前記トリガ情報を取得する
（２）乃至（５）のいずれかに記載の受信装置。
（７）
受信した前記ＡＶコンテンツのデータから特徴量を抽出する特徴量抽出部をさらに備え、
前記トリガ取得部は、抽出した前記特徴量を用いて識別された前記ＡＶコンテンツの識別結果に対応する前記トリガ情報を取得する
（２）乃至（６）のいずれかに記載の受信装置。
（８）
前記制御部は、取得した前記対応テーブルに基づき取得される前記アプリケーションプログラムを動作させる上で必要な性能を、前記受信装置が有しているかを確認し、
前記テーブル取得部は、前記受信装置が前記アプリケーションプログラムを動作させる性能を有していない場合、取得した前記対応テーブルと異なる他の対応テーブルを取得する
（２）乃至（７）のいずれかに記載の受信装置。
（９）
前記テーブル取得部は、あらかじめ設定される、前記対応テーブルの取得優先度に応じて、前記対応テーブルを取得する
（８）に記載の受信装置。
（１０）
前記SMTには、前記NRTサービスの識別情報、並びに前記NRTコンテンツの伝送で用いられるIPアドレス及びポート番号が少なくとも記述され、
前記NRT-ITには、前記NRTサービス及び前記NRTコンテンツの識別情報、並びに前記アプリケーションプログラムの前記取得先情報が少なくとも記述され、
前記FDTには、前記NRTコンテンツの識別情報及びTOI（Transport Object Identifier）が少なくとも記述されており、
前記アプリ取得部は、
前記NRT-ITを参照して、前記対応テーブルに記述された前記取得先情報と一致する前記取得先情報に関連付けられた前記NRTサービス及び前記NRTコンテンツの識別情報を特定し、
前記SMTを参照して、特定した前記NRTサービスの識別情報と一致する識別情報に関連付けられた前記IPアドレス及び前記ポート番号の組み合わせにより特定されるTSI（Transport Session Identifier）のFLUTEセッションから前記FDTを特定し、
前記FDTを参照して、特定した前記NRTコンテンツの識別情報と一致する識別情報に関連付けられたTOIにより識別されるオブジェクトに基づいて、前記アプリケーションプログラムを取得する
（２）乃至（４）のいずれかに記載の受信装置。
（１１）
前記コマンドは、前記アプリケーションプログラムの取得若しくは登録、取得若しくは起動、イベント発火、中断、又は終了のうちいずれかを示しており、
前記制御部は、前記コマンドに応じて、前記アプリケーションプログラムの取得若しくは登録、若しくは取得若しくは起動、又は実行中の前記アプリケーションプログラムのイベント発火、休止、若しくは終了を制御する
（１）乃至（１０）のいずれかに記載の受信装置。
（１２）
受信装置の受信方法において、
前記受信装置が、
放送波により伝送されるＡＶコンテンツを受信し、
受信した前記ＡＶコンテンツに連動して実行されるアプリケーションプログラムを動作させるためのトリガ情報を取得し、
前記トリガ情報と、前記アプリケーションプログラムの動作を制御するためのコマンドとを対応付けた対応テーブルを取得し、
取得した前記対応テーブルに基づいて、前記トリガ情報に対応する前記コマンドが前記アプリケーションプログラムの取得を示す場合、前記放送波により伝送される前記アプリケーションプログラムを取得し、
前記トリガ情報に対応する前記コマンドに応じて、取得した前記アプリケーションプログラムの動作を制御する
ステップを含む受信方法。
（１３）
コンピュータを、
放送波により伝送されるＡＶコンテンツを受信する受信部と、
受信した前記ＡＶコンテンツに連動して実行されるアプリケーションプログラムを動作させるためのトリガ情報を取得するトリガ取得部と、
前記トリガ情報と、前記アプリケーションプログラムの動作を制御するためのコマンドとを対応付けた対応テーブルを取得するテーブル取得部と、
取得した前記対応テーブルに基づいて、前記トリガ情報に対応する前記コマンドが前記アプリケーションプログラムの取得を示す場合、前記放送波により伝送される前記アプリケーションプログラムを取得するアプリ取得部と、
前記トリガ情報に対応する前記コマンドに応じて、取得した前記アプリケーションプログラムの動作を制御する制御部と
して機能させるためのプログラム。
（１４）
受信装置、第１の情報処理装置、及び第２の情報処理装置から構成される情報処理システムにおいて、
前記受信装置は、
放送波により伝送されるＡＶコンテンツを受信する受信部と、
前記放送波により伝送される、受信した前記ＡＶコンテンツに連動して実行されるアプリケーションプログラムを動作させるためのトリガ情報を取得するトリガ取得部と、
前記第１の情報処理装置から、前記トリガ情報と、前記アプリケーションプログラムの動作を制御するためのコマンドとを対応付けた対応テーブルを取得するテーブル取得部と、
取得した前記対応テーブルに基づいて、前記トリガ情報に対応する前記コマンドが前記アプリケーションプログラムの取得を示す場合、前記放送波により伝送される前記アプリケーションプログラムを取得するアプリ取得部と、
前記トリガ情報に対応する前記コマンドに応じて、取得した前記アプリケーションプログラムの動作を制御する制御部と
を備え、
前記アプリ取得部は、前記放送波により伝送される前記アプリケーションプログラムが取得できない場合、前記第２の情報処理装置から前記アプリケーションプログラムを取得し、
前記第１の情報処理装置は、
前記受信装置からの問い合わせに応じて、前記対応テーブルを提供する第１の提供部を備え、
前記第２の情報処理装置は、
前記受信装置からの問い合わせに応じて、前記アプリケーションプログラムを提供する第２の提供部を備える
情報処理システム。
（１５）
受信装置、第１の情報処理装置、第２の情報処理装置、及び第３の情報処理装置から構成される情報処理システムにおいて、
前記受信装置は、
放送波により伝送されるＡＶコンテンツを受信する受信部と、
受信した前記ＡＶコンテンツのデータから特徴量を抽出する特徴量抽出部と、
受信した前記ＡＶコンテンツに連動して実行されるアプリケーションプログラムを動作させるためのトリガ情報であって、前記第１の情報処理装置にて前記特徴量を用いて識別された前記ＡＶコンテンツの識別結果に対応する前記トリガ情報を取得するトリガ取得部と、
前記第２の情報処理装置から、前記トリガ情報と、前記アプリケーションプログラムの動作を制御するためのコマンドとを対応付けた対応テーブルを取得するテーブル取得部と、
取得した前記対応テーブルに基づいて、前記トリガ情報に対応する前記コマンドが前記アプリケーションプログラムの取得を示す場合、前記放送波により伝送される前記アプリケーションプログラムを取得するアプリ取得部と、
前記トリガ情報に対応する前記コマンドに応じて、取得した前記アプリケーションプログラムの動作を制御する制御部と
を備え、
前記アプリ取得部は、前記放送波により伝送される前記アプリケーションプログラムが取得できない場合、前記第３の情報処理装置から前記アプリケーションプログラムを取得し、
前記第１の情報処理装置は、
前記受信装置からの前記特徴量を用いて識別された前記ＡＶコンテンツの識別結果に対応する前記トリガ情報を提供する第１の提供部を備え、
前記第２の情報処理装置は、
前記受信装置からの問い合わせに応じて、前記対応テーブルを提供する第２の提供部を備え、
前記第３の情報処理装置は、
前記受信装置からの問い合わせに応じて、前記アプリケーションプログラムを提供する第３の提供部を備える
情報処理システム。
【符号の説明】
【０３５１】
１，１０１  放送システム，  １１  放送装置，  １２，１１２  受信装置，  １３  TPTサーバ，  １４  アプリサーバ，  ５１  チューナ，  ５７  トリガ抽出部，  ５８  制御部，  ６１  通信I/F，  ６２  TPT解析部，  ６３  フルート処理部，  ６４  アプリエンジン，  １１１  ACRサーバ，  １５１  フィンガプリント抽出部，  ３００  コンピュータ，  ３０１  CPU
【図１】
2013111630.tif 000003
【図２】
2013111630.tif 000004
【図３】
2013111630.tif 000005
【図４】
2013111630.tif 000006
【図５】
2013111630.tif 000007
【図６】
2013111630.tif 000008
【図７】
2013111630.tif 000009
【図８】
2013111630.tif 000010
【図９】
2013111630.tif 000011
【図１０】
2013111630.tif 000012
【図１１】
2013111630.tif 000013
【図１２】
2013111630.tif 000014
【図１３】
2013111630.tif 000015
【図１４】
2013111630.tif 000016
【図１５】
2013111630.tif 000017
【図１６】
2013111630.tif 000018
【図１７】
2013111630.tif 000019
【図１８】
2013111630.tif 000020
【図１９】
2013111630.tif 000021
【図２０】
2013111630.tif 000022
【図２１】
2013111630.tif 000023
【図２２】
2013111630.tif 000024
【図２３】
2013111630.tif 000025
【図２４】
2013111630.tif 000026
【図２５】
2013111630.tif 000027
【図２６】
2013111630.tif 000028
【図２７】
2013111630.tif 000029
【図２８】
2013111630.tif 000030
【図２９】
2013111630.tif 000031
【図３０】
2013111630.tif 000032
【図３１】
2013111630.tif 000033
【図３２】
2013111630.tif 000034
【図３３】
2013111630.tif 000035
【図３４】
2013111630.tif 000036
【図３５】
2013111630.tif 000037
【国際調査報告】
2013111630.tif 000038
2013111630.tif 000039
2013111630.tif 000040