JP5997839B2 - 対話型サービスを処理する装置及び方法 - Google Patents

Description

本発明は、放送サービスを提供、受信及び処理する方法及び装置に関し、特に、放送コンテンツに関連する付加サービスを提供する方法及び装置に関する。

ＴＶは、１９世紀末に初めて登場して以来、画面表示方法やデザインなどにおいて発展を遂げ続け、２０世紀後半からは最も大衆的な情報伝達機器として確立された。ただし、ＴＶは、放送局から提供する一方向の情報を視聴者たちが一方的に受容するという根本的な形態をしていた。このようなＴＶの限界は、１９９０年代からＰＣ（個人用コンピュータ）及びインターネットが大衆化するにつれてより明らかになり始めた。そこで、ＴＶは対話型サービスが可能な方向に進化を続けてきている。

しかしながら、現在、コンテンツプロバイダと視聴者との間には、上記のような対話型サービスを本格的に実行するシステムがない実情である。特に、上記のような対話型サービスの提供のために、放映中の放送コンテンツに関連するアプリケーションを特定時点に駆動し、情報の特定処理を通じて、視聴者に関連情報を提供する方法及びフォーマットに関する技術的支援が必要な状況である。

本発明が遂げようとする技術的課題は、前述した問題点を解決するためのもので、放送コンテンツが再生される期間中に、適切な時期に放送コンテンツに関連する付加情報を提供することにある。

上記の技術的課題を解決するために、本発明に係る対話型サービス（ｉｎｔｅｒａｃｔｉｖｅ ｓｅｒｖｉｃｅ）を処理する方法において、アプリケーションのうち少なくとも一つに関する情報を含むアプリケーションパラメータテーブルを生成するステップであって、前記アプリケーションパラメータテーブルは、第１識別子と第２識別子を含み、前記第１識別子は、前記対話型パラメータテーブルに関連する対話型プログラムセグメント（ｉｎｔｅｒａｃｔｉｖｅ ｐｒｏｇｒａｍｍｉｎｇ ｓｅｇｍｅｎｔ）を識別し、前記第２識別子は、アプリケーションパラメータテーブルの範囲内のアプリケーションを識別する、ステップと、前記アプリケーションの活性化時間のうち少なくとも一つを示す活性化メッセージファイルを生成するステップであって、前記活性化時間は、活性化の時間を意味し、前記活性化メッセージファイルは、第３識別子と活性化メッセージを含み、第３識別子は、前記活性化メッセージファイル内の活性化メッセージが適用される前記アプリケーションを含むアプリケーションパラメータテーブルの前記第１識別子とマッチングされ、前記活性化メッセージは、第４識別子と開始時間情報を含み、前記第４識別子は、前記活性化メッセージファイルが連携された前記アプリケーションパラメータテーブル内のアプリケーションの前記第２識別子とマッチングされ、前記開始時間情報は、前記セグメントの時間を基準に前記アプリケーションにターゲットとなったイベントのための時間期間の開始を示す、ステップと、前記アプリケーションパラメータテーブルを第１部分とし、前記活性化メッセージファイルを第２部分とする多重部分メッセージ（ｍｕｌｔｉ−ｐａｒｔ ｍｅｓｓａｇｅ）を生成するステップと、、ＨＴＴＰを通じて前記多重部分メッセージを受信機に送信するステップを含む。

好ましくは、前記アプリケーションパラメータテーブルは、第５識別子をさらに含み、前記第５識別子は、前記イベントを識別し、前記活性化メッセージは、第６識別子をさらに含み、前記第６識別子は、前記第４識別子によって識別されるアプリケーションの前記第５識別子とマッチングされる。

好ましくは、前記活性化は、前記イベントのための時間期間の開始後に前記活性化メッセージファイルが受信されると直ちに発生する。

好ましくは、前記アプリケーションパラメータテーブルは、前記アプリケーションパラメータテーブルの定義のバージョン番号を示すバージョン情報をさらに含む。

好ましくは、前記アプリケーションパラメータテーブルは、第７識別子をさらに含み、前記第７識別子は、前記第５識別子によって識別された前記イベントのために用いられるデータを識別し、前記活性化メッセージは、第８識別子をさらに含み、前記第８識別子は、前記第４識別子によって識別されたアプリケーションの前記第７識別子とマッチングされる。

好ましくは、前記活性化メッセージは、終了時間情報をさらに含み、前記終了時間情報は、前記セグメントの時間を基準に前記イベントのための時間期間の終わりを示す。

好ましくは、前記アプリケーションは、トリガーされた宣言的客体（Ｔｒｉｇｇｅｒｅｄ Ｄｅｃｌａｒａｔｉｖｅ Ｏｂｊｅｃｔ、ＴＤＯ）であり、前記アプリケーションパラメータテーブルは、ＴＤＯパラメータテーブルである。

好ましくは、前記セグメントの前記時間は、前記セグメントのメディア時間であり、前記セグメントのメディア時間は、コンテンツアイテムの再生における一時点を参照するパラメータである。

また、上記の技術的課題を解決するために、本発明に係る対話型サービス（ｉｎｔｅｒａｃｔｉｖｅ ｓｅｒｖｉｃｅ）を受信する装置は、ＨＴＴＰを通じて多重部分メッセージ（ｍｕｌｔｉ−ｐａｒｔ ｍｅｓｓａｇｅ）を受信するように構成されたネットワークインターフェースであって、前記多重部分メッセージは、前記多重部分メッセージの第１部分であるアプリケーションパラメータテーブルと前記多重部分メッセージの第２部分である活性化メッセージファイルとて構成された、ネットワークインターフェースと、トリガーモジュールであって、前記多重部分メッセージをパーシング（ｐａｒｓｅ）するように構成され、前記アプリケーションパラメータテーブルと前記活性化メッセージファイルを取得するように構成され、アプリケーションのうち少なくとも一つに関する情報を含む前記アプリケーションパラメータテーブルをパーシングするように構成され、第１識別子、第２識別子及びＵＲＬ情報を取得するするように構成され、ここで、前記第１識別子は、前記アプリケーションパラメータテーブルに関連する対話型プログラムセグメント（ｉｎｔｅｒａｃｔｉｖｅ ｐｒｏｇｒａｍｍｉｎｇ ｓｅｇｍｅｎｔ）を識別し、前記第２識別子は、前記アプリケーションパラメータテーブルの範囲内の前記アプリケーションを識別し、前記ＵＲＬ情報は、前記アプリケーションを伝達可能なサーバーのＵＲＬを示し、前記ＵＲＬ情報は、前記アプリケーションの一部であるファイルを識別し、前記ネットワークインターフェースは前記ＵＲＬ情報を用いて前記アプリケーションをダウンロードし、活性化の時間を意味する前記アプリケーションの活性化時間のうち少なくとも一つを示す活性化メッセージファイルをパーシングするように構成され、第３識別子と活性化メッセージを取得するように構成され、ここで、第３識別子は、前記活性化メッセージファイル内の前記活性化メッセージが適用される前記アプリケーションを含む前記アプリケーションパラメータテーブルの前記第１識別子とマッチングされ、前記活性化メッセージをパーシングするように構成され、第４識別子と開始時間情報を取得するように構成された、ここで、前記第４識別子は、前記活性化メッセージファイルが連携された前記アプリケーションパラメータテーブル内のアプリケーションの前記第２識別子とマッチングされ、前記開始時間情報は前記セグメントの時間を基準に前記アプリケーションにターゲットとなったイベントのための時間期間の開始を示す、トリガーモジュールと、前記アプリケーションを表示するように構成されたディスプレイモジュールを含む。

好ましくは、前記アプリケーションパラメータテーブルは、第５識別子をさらに含み、前記アプリケーションパラメータテーブルをパーシングするように構成されたトリガーモジュールは、第５識別子をさらに取得し、前記第５識別子は、前記イベントを識別し、前記活性化メッセージは、第６識別子をさらに含み、前記活性化メッセージをパーシングするように構成された前記トリガーモジュールは、第６識別子をさらに取得し、前記第６識別子は、前記第４識別子によって識別されるアプリケーションの前記第５識別子とマッチングされる。

好ましくは、前記活性化は、前記イベントのための時間期間の開始後に前記活性化メッセージファイルが受信されると直ちに発生する。

好ましくは、前記アプリケーションパラメータテーブルは、前記アプリケーションパラメータテーブルの定義のバージョン番号を示すバージョン情報をさらに含む。

好ましくは、前記アプリケーションパラメータテーブルは、第７識別子をさらに含み、前記アプリケーションパラメータテーブルをパーシングするように構成された前記トリガーモジュールは、前記第７識別子をさらに取得し、前記第７識別子は、前記第５識別子によって識別された前記イベントのために用いられるデータを識別し、前記活性化メッセージは、第８識別子をさらに含み、前記第８識別子は、前記第４識別子によって識別されたアプリケーションの前記第７識別子とマッチングされ、前記活性化メッセージをパーシングするように構成された前記トリガーモジュールは、前記第８識別子をさらに取得し、前記第８識別子は、前記第４識別子によって識別されたアプリケーションの前記第７識別子とマッチングされる。

好ましくは、前記活性化メッセージは、終了時間情報をさらに含み、前記活性化メッセージをパーシングするように構成された前記トリガーモジュールは、前記終了時間情報をさらに取得し、前記終了時間情報は、前記セグメントの時間を基準に前記イベントのための時間期間の終わりを示す。

好ましくは、前記アプリケーションは、トリガーされた宣言的客体（Ｔｒｉｇｇｅｒｅｄ Ｄｅｃｌａｒａｔｉｖｅ Ｏｂｊｅｃｔ、ＴＤＯ）であり、前記アプリケーションパラメータテーブルはＴＤＯパラメータテーブルである。

好ましくは、前記セグメントの前記時間は、前記セグメントのメディア時間であり、前記セグメントのメディア時間は、コンテンツアイテムの再生における一時点を参照するパラメータである。

本発明によれば、既存放送システムを用いて、放送コンテンツと関連する付加情報を提供することが可能になる。

本発明によれば、放送コンテンツに関連する付加情報がディスプレイされるべき時点を正確に把握し、適時に付加情報をユーザに提供することが可能になる。

本発明によれば、放送信号を直接受信できない放送受信機にとっても、放送コンテンツに関連する付加情報を取得し、適切な時点に関する付加情報を視聴者に提供することが可能になる。

一般的な放送ストリームの一実施例を示す図である。 予め生成された（Ｐｒｅ−ｐｒｏｄｕｃｅｄ）コンテンツの場合に、トリガータイミングの一実施例を示す図である。 ライブ（Ｌｉｖｅ）コンテンツの場合に、トリガータイミングの一実施例を示す図である。 トリガーシンタックスの一実施例を示す図である。 ＴＤＯパラメータテーブルの一実施例を示す図である。 ＴＤＯパラメータテーブルの一実施例を示す図である。 ‘Ｆｒｅｑｕｅｎｃｙ ｏｆ Ｕｓｅ’属性値の意味の一実施例を示す図である。 ‘ｄｅｓｔｉｎａｔｉｏｎ’属性値の意味の一実施例を示す図である。 ＴＤＯパラメータテーブルの２進形態のシンタックスの一実施例を示す図である。 ＴＤＯパラメータテーブルの２進形態のシンタックスの一実施例を示す図である。 ＴＤＯパラメータテーブルの２進形態のシンタックスの一実施例を示す図である。 ＴＤＯパラメータテーブルの２進形態のシンタックスの一実施例を示す図である。 ＴＤＯパラメータテーブルの２進形態のシンタックスの一実施例を示す図である。 活性化メッセージテーブル構造の一実施例を示す図である。 ＵＲＬリスト構造の一実施例を示す図である。 ＴＰＴを含むプライベートセクション（ｐｒｉｖａｔｅ ｓｅｃｔｉｏｎ）の２進フォーマットの一実施例を示す図である。 ＸＭＬ文書としてエンコードされたＵＲＬ目録の一実施例を示す図である。 ａｄｄＴｒｉｇｇｅｒＥｖｅｎｔＬｉｓｔｅｎｅｒの一実施例を示す図である。 ｒｅｍｏｖｅＴｒｉｇｇｅｒＥｖｅｎｔＬｉｓｔｅｎｅｒの一実施例を示す図である。 ＥｖｅｎｔＬｉｓｔｅｎｅｒタイプの定義の一実施例を示す図である。 ＴｒｉｇｇｅｒＥｖｅｎｔタイプの定義の一実施例を示す図である。 ＴＤＯモデルにおける送信方法の一実施例を示す図である。 本発明において、受信機の構造の一実施例を示す図である。 放送をセットトップボックス（ＳｅｔＴｏｐ Ｂｏｘ）でＨＤＭＩ或いは外部入力を介して受信する場合の受信機構造の一実施例を示す図である。 ＴＤＯモデルにおける受信装置の一実施例を示す図である。 直接実行モデルにおける送信方法の一実施例を示す図である。 直接実行モデルにおける受信装置の一実施例を示す図である。

本明細書で使われる用語としては、本発明においての機能を考慮したうえ、できるだけ現在広く使われている一般的な用語を選択したが、これは、当該分野に従事する技術者の意図、慣例又は新しい技術の出現などによって変更されてもよい。また、特定の場合、出願人が任意に選定した用語もあり、その場合には、該当する発明の説明の部分においてその意味を記載するものとする。したがって、本明細書で使われる用語は、単純な用語の名称ではなく、その用語が持つ実質的な意味と本明細書の全般にわたる内容に基づいて解釈されなければならいということは明らかである。

この明細書でいうメディア時間（ｍｅｄｉａ ｔｉｍｅ）は、オーディオ／ビデオ又はオーディオコンテンツアイテムの再生（ｐｌａｙｏｕｔ）における一時点を参照するパラメータを指す。ＡＣＲは自動コンテンツ認識（Ａｕｔｏｍａｔｉｃ Ｃｏｎｔｅｎｔ Ｒｅｃｏｇｎｉｔｉｏｎ）を表す。ＡＭＴは活性化メッセージテーブル（Ａｃｔｉｖａｔｉｏｎ Ｍｅｓｓａｇｅｓ Ｔａｂｌｅ）を表す。ＡＰＩはアプリケーションプログラミングインターフェース（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍｉｎｇ Ｉｎｔｅｒｆａｃｅ）を表す。ＤＡＥは宣言的応用環境（Ｄｅｃｌａｒａｔｉｖｅ Ａｐｐｌｉｃａｔｉｏｎ Ｅｎｖｉｒｏｎｍｅｎｔ）を表す。ＤＯは宣言的客体（Ｄｅｃｌａｒａｔｉｖｅ Ｏｂｊｅｃｔ）を表す。ＦＬＵＴＥは、単方向送信を用いたファイル伝達（Ｆｉｌｅ Ｄｅｌｉｖｅｒｙ ｏｖｅｒ Ｕｎｉｄｉｒｅｃｔｉｏｎａｌ Ｔｒａｎｓｐｏｒｔ）を表す。ＧＰＳは、位置確認システム（Ｇｌｏｂａｌ Ｐｏｓｉｔｉｏｎｉｎｇ Ｓｙｓｔｅｍ）を表す。ＨＴＴＰは、ハイパーテキスト送信プロトコル（Ｈｙｐｅｒｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）を表す。ＩＰはインターネットプロトコル（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）を表す。ＩＰＴＶはインターネットプロトコルテレビ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ Ｔｅｌｅｖｉｓｉｏｎ）を表す。ｉＴＶは対話型テレビ（Ｉｎｔｅｒａｃｔｉｖｅ Ｔｅｌｅｖｉｓｉｏｎ）を表す。ＭＩＭＥはインターネットメディアタイプ（Ｉｎｔｅｒｎｅｔ Ｍｅｄｉａ Ｔｙｐｅ）を表す。ＮＤＯはＮＲＴ宣言的客体（ＮＲＴ Ｄｅｃｌａｒａｔｉｖｅ Ｏｂｊｅｃｔ）を表す。ＮＲＴは非実時間（Ｎｏｎ−Ｒｅａｌ Ｔｉｍｅ）を表す。ＳＭＴはサービスマップテーブル（Ｓｅｒｖｉｃｅ Ｍａｐ Ｔａｂｌｅ）を表す。ＳＳＣはサービスシグナリングチャネル（Ｓｅｒｖｉｃｅ Ｓｉｇｎａｌｉｎｇ Ｃｈａｎｎｅｌ）を表す。ＴＤＯは、トリガーされた宣言的客体（Ｔｒｉｇｇｅｒｅｄ Ｄｅｃｌａｒａｔｉｖｅ Ｏｂｊｅｃｔ）を表す。ＴＰＴは、ＴＤＯパラメータテーブル（ＴＤＯ Ｐａｒａｍｅｔｅｒｓ Ｔａｂｌｅ）を表す。ＵＤＯは、非結合宣言的客体（Ｕｎｂｏｕｎｄ Ｄｅｃｌａｒａｔｉｖｅ Ｏｂｊｅｃｔ）を表す。ＵＰｎＰはユーザプラグアンドプレイ（Ｕｓｅｒ Ｐｌｕｇ ａｎｄ Ｐｌａｙ）を表す。ＵＲＩは統合リソース識別子（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｉｄｅｎｔｉｆｉｅｒ）を表す。ＵＲＬはリソース位置表示子（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ）を表す。ＸＭＬは拡張性生成言語（ｅＸｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）を表す。詳細な内容は後述する。

この明細書で、時間ベースメッセージ（ｔｉｍｅ ｂａｓｅ ｍｅｓｓａｇｅ）は、時間ベーストリガー及びその等価物を含む概念である。したがって、時間ベースメッセージは時間ベーストリガーと同じ意味で使われてもよい。

この明細書で、活性化メッセージは、活性化トリガー及び／又はＡＭＴ内の活性化エレメントなど、活性化を起こし得るいずれの形態の情報伝達をも含む概念である。

この明細書で、ＤＯ、ＴＤＯ、ＮＤＯ、ＵＤＯは次のような意味を有することができる。

ＤＯ（Ｄｅｃｌａｒａｔｉｖｅ Ｏｂｊｅｃｔ）は、対話型アプリケーション（例えば、ＨＴＭＬ、ＪａｖａＳｃｒｉｐｔ、ＣＳＳ、ＸＭＬ及びマルチメディアファイル）を構成するコレクション（ｃｏｌｌｅｃｔｉｏｎ）であってもよい。

トリガーされた対話型付加データサービスによって開始された宣言的客体又はトリガーによって開始されたＤＯによって実行されたＤＯなどを指定するために「トリガーされた宣言的客体（ＴＤＯ）」を使用する。

トリガーされた対話型データサービスではなくＮＲＴサービスの一部として実行された宣言的客体を表すために、「ＮＲＴ宣言的客体」（ＮＤＯ）という用語を使用する。

パッケージ型アップ（Ｐａｃｋａｇｅｄ Ａｐｐ）のようにサービスに結合されない宣言的客体、リンクによって実行されたＤＯ、又はそのようなＤＯによって実行されたＤＯなどを表すために「非結合宣言的客体（ＵＤＯ）」という用語を使用する。

「リンク」は、現在のＴＶプログラム又はＮＲＴサービスに関連するオンライン情報又は機能を提供するウェブサイトを示す放送局提供ＵＲＬである。

「パッケージ型アップ」は、放送局が視聴者に提供しようとする情報又は機能を提供し、視聴者がダウンロードして設置できる一つのファイルとしてまとめられた放送局提供宣言的客体（ＤＯ）である。

一般的な放送ストリームはＴＶプログラムのシーケンスで構成されている。各ＴＶプログラムは、基本となるショー（ｓｈｏｗ）で構成され、ショーは一般的に広告及び／又は他の介在物（ｉｎｔｅｒｓｔｉｔｉａｌ ｍａｔｅｒｉａｌ）によって分離されたブロックに分けられる。

図１は、一般的な放送ストリームの一実施例を示す図である。

同図では、放送ストリームに、ショーＡ（Ｓｈｏｗ Ａ）セグメント、広告１（Ａｄ１）、広告２（Ａｄ２）、ショーＢ（Ｓｈｏｗ Ｂ）セグメントなどが順次に含まれている。各ショーをなすセグメントをショー材料、広告を介在物と呼ぶことができる。

各ショー又は介在物は、それと連携している対話型付加データサービスを有しても有さなくてもよい。

本明細書では、統合ユニットとして放送局によって扱われる対話型付加サービスの一部を表すために「対話型サービスセグメント」、又は単純に「セグメント」という用語を使用する。対話型サービスセグメントは一般的に単一ショー又は１個の介在物と連携するが、必ずしもそうでない。

このような対話型付加データサービスを実行するための２つのモデルがあり得る。直接実行モデルとトリガーされた宣言的客体（Ｔｒｉｇｇｅｒｅｄ Ｄｅｃｌａｒａｔｉｖｅ Ｏｂｊｅｃｔ、ＴＤＯ）モデルがそれである。

直接実行モデルでは、仮想チャネルが選択されると直ちに宣言的客体（Ｄｅｃｌａｒａｔｉｖｅ Ｏｂｊｅｃｔ、ＤＯ）は自動で開始され得る。宣言的客体は、スクリーン上の特定位置での画面の生成、世論調査の実行、他の特殊ＤＯの開始などのように、オーディオ−ビデオプログラムと同期化される対話型特徴の提供のための具体的な指示事項を得るために、インターネットを介してバックエンド（ｂａｃｋｅｎｄ）サーバーと通信することができる。

ＴＤＯモデルでは、ＴＤＯの開始、ＴＯＤの終了、又はＴＤＯによる一部作業の誘発のようにＴＤＯイベントを開始するために信号を放送ストリームで伝達したり又はインターネットを介して伝達することができる。これらのイベントは、特定時間に開始され、一般的にオーディオ−ビデオプログラムと同期化される。ＴＤＯが開始されると、プログラムされた対話型特徴を提供することができる。

ＴＤＯモデルの基本概念は、ＴＤＯを構成するファイル及びある動作を取るためにＴＤＯによって用いられるデータファイルはいずれも、その大きさによって受信機に伝達されるには一定量の時間がかかるということである。対話型エレメントに対するユーザ経験は、コンテンツの放送前に作成（ａｕｔｈｏｒ）されてもよいが、ある振舞いは、プログラム内のイベント、例えば、商業広告セグメントの発生と同時に起きるように注意して時間を決めなければならない。

ＴＤＯモデルでは、宣言的客体、連携されたデータ、スクリプト、テキスト及びグラフィックの伝達を、対話型イベントの再生に対する特定タイミングのシグナリングと区別する。

対話型イベントのタイミングを設定するエレメントはトリガー（Ｔｒｉｇｇｅｒ）である。

一つのセグメント内で用いられるＴＤＯとトリガーによって開始される連携ＴＤＯイベントに関する情報は、「ＴＤＯパラメータテーブル」（ＴＰＴ）と呼ばれるデータ構造によって提供される。

本発明を説明するための明細書の構造を簡単に説明する。まず、トリガー、ＴＰＴについて説明し、活性化トリガーが大量でインターネットを介して伝達される場合であるＡＭＴについて説明する。

ＵＲＬリストの構造について説明する。ＵＲＬリストは、受信機に対して使用潜在性のあるＵＲＬを含む。ＵＲＬリストは、一つ以上の未来セグメントに対するＴＰＴのためのＵＲＬ、ＮＲＴシグナリングサーバーのＵＲＬ、使用報告サーバー（Ｕｓａｇｅ Ｒｅｐｏｒｔｉｎｇ Ｓｅｒｖｅｒ）のＵＲＬなどを含むことができる。

その後、ＴＰＴと共に伝達され得る、トリガー、ＴＰＴ及びＡＭＴと、ＵＲＬリストの放送ストリームと、インターネットを介した伝達メカニズムについて説明し、ＡＴＳＣ ＪａｖａＳｃｒｉｐｔ ＡＰＩについて説明する。

続いて、本発明である、ＴＤＯモデルによる送信方法及び受信装置について説明する。

直接実行モデルについて説明した後、同様に本発明である、直接実行モデルによる送信方法及び受信装置について説明する。

以下、トリガーについて説明する。

トリガーは、シグナリングを識別し、対話型イベントの再生タイミングを設定する機能を担うシグナリングエレメントである。

トリガーには、対話型サービスに関連するセグメントに対するメディア時間を示す役割を担う時間ベーストリガーと、対話型サービスに関連するアプリケーションのイベント発生時間を示す役割を担う活性化トリガーの２種類があり得る。

トリガーは、対話型サービスの支援のために、タイミングに関連する様々な機能を果たすことができる。トリガーはその機能によって多機能的であってもよく、特定トリガーインスタンス（ｉｎｓｔａｎｃｅ）は、次の機能のうち一つ以上を行うことができる。

１．ＴＰＴ（放出ストリーム内のＦＬＵＴＥセッション、インターネットサーバー、又はこれら両者を介して接近可能なＴＰＴ）の位置をシグナリングする。

２．次のプログラムセグメントに対する対話型コンテンツがプリロード（ｐｒｅ−ｌｏａｄ）されることを示す。

３．連携されたオーディオ／ビデオコンテンツ又はオーディオコンテンツの現在メディア時間を示す。

４．ＴＰＴ内特定対話型イベントを参照し、当該イベントが今又は特定の未来メディア時間に実行されなければならないということを知らせる。

５．需要が最大となることを避けるために、インターネットサーバーに対する接続が特定の時間区間上でランダムに分散されることを示す。

以下、トリガーの動作について例を挙げて説明する。

図２は、予め生成された（Ｐｒｅ−ｐｒｏｄｕｃｅｄ）コンテンツの場合に、トリガータイミングの一実施例を示す図である。

図２は、２つのプログラミングセグメントと連携して伝達されるトリガーを示す。この例では、２つのセグメントとも「予め生成」されるが、これは、コンテンツがライブコンテンツではなく、対話型エレメントはポストプロダクション（ｐｏｓｔ−ｐｒｏｄｕｃｔｉｏｎ）で追加されたことを意味する。

図示のように、プログラミングセグメント１の発生前の短い時間に「プリロード（ｐｒｅ−ｌｏａｄ）」トリガーが伝達されて、受信機と連携されているＴＰＴ及びー方向コンテンツを取得できる機会を受信機に許容することができる。万一、プリロードトリガーが送信されないと、受信機は、コンテンツを取得するために該当のセグメント内で会う最初のトリガーを用いるはずである。

図示のように、トリガーはＳｅｇｍｅｎｔ１を通して送信されて、当該セグメントに関する現在メディア時間（図では「ｍ」と表記）を示すことができる。当該チャネルに会うトリガーが対話型コンテンツを同期化して取得できるようにするためにメディア時間トリガーの周期的な伝達が必要なことがある。

Ｓｅｇｍｅｎｔ２の開始直前に当該セグメントに対するプリロードトリガーが送信される。

予め生成されたコンテンツ（非ライブ（ｎｏｎ−ｌｉｖｅ）コンテンツ）の場合、受信機が最初のトリガーを処理した後に取得できるＴＰＴは、当該セグメントに対する対話型経験の全てのエレメントのタイミングを定義することができる。当該受信機とＴＤＯが対話型エレメントを再生するようにするために必要なものは、メディアタイミングの知識であってもよい。このＴＰＴはメディア時間に関して対話型イベントを記述することができる。

図３は、ライブコンテンツの場合に、トリガータイミングの一実施例を示す図である。

ライブコンテンツの場合にも、ＴＰＴは、互いに異なる対話型イベントに関連するデータ及び情報を含むが、放送中にプログラム内の動作が展開するまでは、そのようなイベントの再生タイミングは知られないことがある。このようなライブの場合、トリガーの「イベント−タイミング（ｅｖｅｎｔ−ｔｉｍｉｎｇ）」機能が活用される。このモードでトリガーは、特定の対話型イベントが新しい特定メディア時間値に再設定（ｒｅ−ｔｉｍｅｄ）されることを知らせることができる。又は、トリガーは、あるイベントが直ちに実行されることを示すこともできる。

図３で、Ｓｅｇｍｅｎｔ ３に対する各トリガーの機能は次の通りである。

１番トリガーは、プリロードトリガーであって、セグメント３に関するファイルを得ることができるディレクトリを参照する。

２番トリガーは、メディア時間トリガーであって、Ｓｅｇｍｅｎｔ ３に対する再生タイミングを示すために用いられる。

３番トリガーは、イベントリタイミング（ｒｅ−ｔｉｍｉｎｇ）トリガーであって、ＴＰＴでｅｖｅｎｔＩＤ＝２のイベントがメディア時間２４０に発生するように時間が再設定されることを示す。ハッチングされた領域は、３番トリガーが受信機に伝達され得る２４０以前の時間区間を示す。

４番トリガーは、メディア時間トリガーである。

５番トリガーは、イベントリタイミングトリガーであって、ＴＰＴでｅｖｅｎｔＩＤ＝５のイベントがメディア時間４４４に発生するように時間が再設定されることを示す。

６番、７番トリガーは、メディア時間トリガーである。

８番トリガーは、イベントトリガーであって、ＴＰＴでｅｖｅｎｔＩＤ＝１２のイベントが直ちに実行されることを示す。

９番トリガーは、イベントリタイミングトリガーであって、ＴＰＴでｅｖｅｎｔＩＤ＝８９のイベントがメディア時間９００に発生するように時間が再設定されることを示す。

以下、トリガーシンタックスについて説明する。

活性化メッセージと時間ベースメッセージは両方とも、ある送信環境で次のような一般的な「トリガー」フォーマットを有することができる。

ここで、シンタックス上の定義は、アルタネイティブ（ａｌｔｅｒｎａｔｉｖｅ）を指定するために垂直バーシンボル”｜”が使われる場合以外は、ＡＢＮＦ（Ａｕｇｍｅｎｔｅｄ Ｂａｃｋｕｓ−Ｎａｕｒ Ｆｏｒｍ）文法を用いて記述する。ルール（ｒｕｌｅ）は等号”＝”によって定義と分離され、１行を超えてルール定義を続けるときは字下げ（ｉｎｄｅｎｔａｔｉｏｎ）を用い、リテラル（ｌｉｔｅｒａｌ）は””で引用し、エレメントのグループ化には括弧”（”と”）”を用い、選択的なエレメントは”［”と”］”との間に入れる。そして、エレメントの前に＜ｎ＞^*がつくと、その次のエレメントのｎ回以上の反復を指定でき、ｎは基本値として０に設定される。そして、エレメントの前に＜ｎ＞^*＜ｍ＞がつくと、その次にくるエレメントのｎ回以上ｍ回以下の反復を指定することができる。

このようなトリガーシンタックスは、＜ｓｃｈｅｍｅ＞と“：／／”部分を除いて、付加的な制限事項と共にＵＲＩ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｉｄｅｎｔｉｆｉｅｒ）：ジェネリックシンタックス（Ｇｅｎｅｒｉｃ Ｓｙｎｔａｘ）に基づく。

図４は、トリガーシンタックスの一実施例を示す図である。

以下、図４について説明する。

トリガーは、ｌｏｃａｔｏｒ＿ｐａｒｔとｔｅｒｍｓで構成することができる。ｔｅｒｍｓは、省略可能な構成である。ｔｅｒｍｓが存在するとｌｏｃａｔｏｒ＿ｐａｒｔとｔｅｒｍｓとを「？」で連結することができる。

ｌｏｃａｔｏｒ＿ｐａｒｔは、ｈｏｓｔｎａｍｅ部分とｐａｔｈ＿ｓｅｇｍｅｎｔｓ部分とで構成することができ、その間は「／」で連結することができる。

ｈｏｓｔｎａｍｅは、ｄｏｍａｉｎｌａｂｅｌとｔｏｐｌａｂｅｌとで構成することができ、ｄｏｍａｉｎｌａｂｅｌはその次に「．」と共に０回以上反復され得る。すなわち、ｈｏｓｔｎａｍｅは、反復されたｄｏｍａｉｎｌａｂｅｌがｔｏｐｌａｂｅｌと連結した形態であってもよく、又は、ｔｏｐｌａｂｅｌのみで構成された形態であってもよい。

ｄｏｍａｉｎｌａｂｅｌは、一つのａｌｐｈａｎｕｍからなる形態であってもよい。又は、２つのａｌｐｈａｎｕｍの間にａｌｐｈａｎｕｍ又は「−」が０回以上反復されたものが挿入された形態であってもよい。

ここで、ａｌｐｈａｎｕｍは、ａｌｐｈａ又はｄｉｇｉｔを意味することができる。

ここで、ａｌｐｈａは、ｌｏｗａｌｐｈａ又はｕｐａｌｐｈａのいずれかであってもよい。

ここで、ｌｏｗａｌｐｈａは、ａ、ｂ、ｃ、ｄ、ｅ、ｆ、ｇ、ｈ、ｉ、ｊ、ｋ、ｌ、ｍ、ｎ、ｏ、ｐ、ｑ、ｒ、ｓ、ｔ、ｕ、ｖ、ｗ、ｘ、ｙ、ｚのいずれか一つであってもよい。

ここで、ｕｐａｌｐｈａは、Ａ、Ｂ、Ｃ、Ｄ、Ｅ、Ｆ、Ｇ、Ｈ、Ｉ、Ｊ、Ｋ、Ｌ、Ｍ、Ｎ、Ｏ、Ｐ、Ｑ、Ｒ、Ｓ、Ｔ、Ｕ、Ｖ、Ｗ、Ｘ、Ｙ、Ｚのいずれか一つであってもよい。

ここで、ｄｉｇｉｔは、０、１、２、３、４、５、６、７、８、９のいずれか一つであってもよい。

ｔｏｐｌａｂｅｌは、一つのａｌｐｈａからなる形態であってもよい。又は、ａｌｐｈａとａｌｐｈａｎｕｍとの間にａｌｐｈａｎｕｍ又は「−」が０回以上反復されたものが挿入された形態であってもよい。

ｐａｔｈ＿ｓｅｇｍｅｎｔｓは、セグメントが一つがあり、その次にセグメントが０回以上反復されたものが続く形態であってもよい。このとき、セグメントの間は「／」で連結することができる。

ここで、セグメントは、ａｌｐｈａｎｕｍが１回以上反復された形態であってもよい。

ｔｅｒｍｓは、ｅｖｅｎｔ＿ｔｉｍｅ又はｍｅｄｉａ＿ｔｉｍｅのいずれかからなる形態であってもよい。続いてｓｐｒｅａｄ又はｏｔｈｅｒｓが来てもよい。ｓｐｒｅａｄとｏｔｈｅｒｓは省略可能な構成であってもよい。ｓｐｒｅａｄとｏｔｈｅｒｓが存在すると、これは「＆」を前に置いている形態であって、ｅｖｅｎｔ＿ｔｉｍｅ又はｍｅｄｉａ＿ｔｉｍｅの次に位置することができる。

ここで、ｓｐｒｅａｄは、「ｓ＝」の次にｄｉｇｉｔが１回以上反復されたものが続く形態であってもよい。

ｅｖｅｎｔ＿ｔｉｍｅは、「ｅ＝」の次にｄｉｇｉｔが１回以上反復されたものが続く形態であってもよい。又は、その後、「＆ｔ＝」の次にｈｅｘｄｉｇｉｔが１回以上７回以下反復されたものが続く形態であってもよい。「＆ｔ＝」とその次の部分は省略可能な構成であってもよい。

ここで、ｈｅｘｄｉｇｉｔは、０、１、２、３、４、５、６、７、８、９、ａ、ｂ、ｃ、ｄ、ｅ、ｆのいずれか一つであってもよい。

ｍｅｄｉａ＿ｔｉｍｅは、「ｍ＝」の次にｈｅｘｄｉｇｉｔが１回以上７回未満反復されたものが続く形態であってもよい。

ｏｔｈｅｒｓは、一つのｏｔｈｅｒからなる形態であってもよい。又は、その次に「＆」とｏｔｈｅｒが追加された形態であってもよい。

ここで、ｏｔｈｅｒは、ｒｅｓｖ＿ｃｍｄとａｌｐｈａｎｕｍが１回以上反復されたものとが「＝」によって連結された形態であってもよい。

ここで、ｒｅｓｖ＿ｃｍｄは、「ｃ」、「ｅ」、「Ｅ」、「ｍ」、「Ｍ」、「ｓ」、「Ｓ」、「ｔ」、「Ｔ」を除くａｌｐｈａｎｕｍであってもよい。

トリガーの長さは５２バイトを超えなくてもよい。そして、トリガーのｈｏｓｔｎａｍｅ部分は、登録されたインターネットドメイン名であってもよい。

トリガーは、３つの部分からなることがわかる。

＜ｄｏｍａｉｎ ｎａｍｅ ｐａｒｔ＞／＜ｄｉｒｅｃｔｏｒｙ ｐａｔｈ＞［？＜ｐａｒａｍｅｔｅｒｓ＞］

＜ｄｏｍａｉｎ ｎａｍｅ ｐａｒｔ＞は、登録されたドメイン名であり、＜ｄｉｒｅｃｔｏｒｙ ｐａｔｈ＞は、ドメイン名がＵＲＩにおいて登場するようになる経路であってもよい。

＜ｄｏｍａｉｎ ｎａｍｅ ｐａｒｔ＞は、登録されたインターネットドメイン名を参照することができる。＜ｄｉｒｅｃｔｏｒｙ ｐａｔｈ＞は、識別されたドメイン名に対する権限を持つエンティティ（ｅｎｔｉｔｙ）の制御及び管理下でディレクトリ経路を識別する任意の文字列であってもよい。

ＴＤＯモデルで、＜ｄｏｍａｉｎ ｎａｍｅ ｐａｒｔ＞と＜ｄｉｒｅｃｔｏｒｙ ｐａｔｈ＞の組合せは、連携されたコンテンツに対話型性を追加するために受信機によって処理され得るＴＰＴを固有に識別することができる。

＜ｄｏｍａｉｎ ｎａｍｅ ｐａｒｔ＞と＜ｄｉｒｅｃｔｏｒｙ ｐａｔｈ＞の組合せは、現在セグメントに対するＴＰＴが得られるインターネット位置のＵＲＬであってもよい。

すなわち、トリガーは、＜ｄｏｍａｉｎ ｎａｍｅ ｐａｒｔ＞と＜ｄｉｒｅｃｔｏｒｙ ｐａｔｈ＞を用いてＴＰＴを識別することができ、これによってトリガーの適用されるＴＰＴがわかる。当該ｔｒｉｇｇｅｒがＴＰＴに適用されてどのような役割を果たすかは、＜ｐａｒａｍｅｔｅｒｓ＞部分による。

以下、＜ｐａｒａｍｅｔｅｒｓ＞部分について説明する。

＜ｐａｒａｍｅｔｅｒｓ＞は、「ｅｖｅｎｔ＿ｔｉｍｅ」、「ｍｅｄｉａ＿ｔｉｍｅ」、又は「ｓｐｒｅａｄ」の一つ以上で構成することができる。

次は、図４に示したシンタックスにおいて「ｅｖｅｎｔ＿ｔｉｍｅ」、「ｍｅｄｉａ＿ｔｉｍｅ」、「ｓｐｒｅａｄ”に関する部分である。

event_time =”e=”1*digit[”&t=”1*7hexdigit]
media_time =”m=”1*7hexdigit
spread =”s=”1*digit
「ｅｖｅｎｔ＿ｔｉｍｅ」項は、ターゲットとされたイベント（「ｅ＝」項）と当該イベントが活性化されるべき時間（「ｔ＝」項）を識別するために活性化トリガーにおいて用いることができる。「ｔ＝」項がないと、これは、トリガーが到達する時間にイベントが活性化されなければならないことを意味する。

すなわち、対話型イベントＩＤ項である「ｅ＝」は、当該イベントのターゲットであるＴＤＯの連携されたＴＰＴ内のａｐｐＩＤ、当該特定イベントのｅｖｅｎｔｉｄｅ、及びこのイベント活性化のために用いられるデータエレメントのｄａｔａＩＤを参照することができる。

選択的なタイミング値項である「ｔ＝」は、指定されたイベントのための新しいメディアタイミングを示すことができる。「ｔ＝」部分が存在しないと、これは、指定されたイベントのためのタイミングがトリガーの到達時間であることを意味することができる。

「ｍｅｄｉａ＿ｔｉｍｅ」項（「ｍ＝」項）は、時間ベーストリガーによって示される時間ベースに対する現在時間を識別するために時間ベーストリガーにおいて用いることができる。そして、現在表れているコンテンツを識別できるコンテンツ識別子情報（「ｃ＝」項）がｍｅｄｉａ＿ｔｉｍｅにさらに含まれてもよい。「ｃ＝」項については、直接実行モデルに関する説明で後述する。

すなわち、「ｍ＝」は、その次に１６進数を表示する１乃至８文字長の文字列が続くメディアタイムスタンプ（ｔｉｍｅｓｔａｍｐ）項であって、現在のメディア時間を示すことができる。

「ｓｐｒｅａｄ」項は、サーバー上で作業負荷が分散するように、時間ベーストリガーに応答してなされる動作（サーバーからのＴＰＴの検索のような動作）又は活性化トリガーに応答してなされる動作（ＴＤＯをサーバーに接続させるような動作）がランダムな時間の間に遅延されなければならないということを示すために用いることができる。

「ｓ＝」項は、全ての受信機がトリガーで識別されたインターネットサーバーに接続を試みるべき秒単位の時間数を示すことができる。それぞれの個別受信機が、指定された区間内でランダムな時間を導出して、該当する量だけ接続要求を遅延させることによって、受信機でトリガーが初めて現れる時に発生しう需要の最大値を時間上で分散させると考えることができる。

＜ｍｅｄｉａ ｔｉｍｅ＞パラメータを含むトリガーは、イベント時間に対する時間ベースを設定するために用いられることから、時間ベーストリガーと呼ぶこともできる。

＜ｅｖｅｎｔ ｔｉｍｅ＞パラメータを含むトリガーは、イベントに対する活性化時間を設定することから、活性化トリガーと呼ぶこともできる。

以下、ＴＤＯのライフサイクル（ｌｉｆｅ ｃｙｃｌｅ）と状態、状態変化イベントについて説明する。

ＴＤＯは、解除（Ｒｅｌｅａｓｅｄ）、準備（Ｒｅａｄｙ）、活動（Ａｃｔｉｖｅ）、及び中止（Ｓｕｓｐｅｎｄｅｄ）の異なった４つの状態で存在することができる。多数の異なる要素（トリガー、ユーザ動作、変更されるチャネルなど）が一つの状態から他の状態への変動を引き起こし得る。

ＴＤＯは、次の４つの状態を有することができる。

１．準備（Ｒｅａｄｙ）−ダウンロードされて実行準備ができているが、まだ実行されていない

２．活動（Ａｃｔｉｖｅ）−実行中

３．中止（Ｓｕｓｐｅｎｄｅｄ）−状態が保存され、一時的に実行が中止される

４．解除（Ｒｅｌｅａｓｅｄ）−準備、活動又は中止状態でない

ＴＤＯの状態変化を起こし得るイベントの例には次のものがある。

１．「ｐｒｅｐａｒｅ」をトリガーする：装置は、ＴＤＯが実行（リソース割当、主メモリへのローディングなど）をするように準備されることを要求するトリガーを（現在選択された１次仮想チャネルで）受信する。

２．「ｅｘｅｃｕｔｅ」をトリガーする：装置は、ＴＤＯが活性化されることを要求するトリガーを（現在選択された１次仮想チャネルで）受信する。

３．「ｓｕｓｐｅｎｄ」をトリガーする：装置は、ＴＤＯの中止を示すトリガーを（現在選択された１次仮想チャネルで）受信する。

４．「ｋｉｌｌ」をトリガーする：装置は、ＴＤＯの終了を示すトリガーを（現在選択された１次仮想チャネルで）受信する。

以下、ＴＰＴについて説明する。

ＴＤＯパラメータテーブル（ＴＰＴ）は、一つのセグメントのＴＤＯ及びそれらのターゲットであるイベントに関するメタデータを含む。

図５及び図６は、ＴＤＯパラメータテーブルの一実施例を示す図である。

以下、テーブルに含まれる各フィールドについて説明する。各フィールドの大きさとテーブルに含み得るフィールドの種類は設計者の意図によって追加又は変更されてもよい。

ＴＰＴ構造内のフィールドの具体的なセマンティックス（ｓｅｍａｎｔｉｃｓ）は次の通りである。

ＴＤＯパラメータテーブル（ＴＰＴ）は、＠ｍａｊｏｒＰｒｏｔｏｃｏｌＶｅｒｓｉｏｎ、＠ｍｉｎｏｒＰｒｏｔｏｃｏｌＶｅｒｓｉｏｎ、＠ｉｄ、＠ｔｐｔＶｅｒｓｉｏｎ、＠ｅｘｐｉｒｅＤａｔｅ、＠ｕｐｄａｔｉｎｇＴｉｍｅ、＠ｓｅｒｖｉｃｅＩＤ、＠ｂａｓｅＵＲＬ属性、Ｃａｐａｂｉｌｉｔｉｅｓ、ライブトリガー（ＬｉｖｅＴｒｉｇｇｅｒ）、及び／又はＴＤＯエレメントを含むことができる。

ＴＰＴは、当該ＴＰＴのルートエレメントである。一つのＴＰＴエレメントは、一つのプログラミングセグメントの（時間上での）全体又は一部分を記述する。

４ビット属性であってもよい＠ＭａｊｏｒＰｒｏｔｏｃｏｌＶｅｒｓｉｏｎは、テーブル定義の主バージョン番号を示すことができる。主バージョン番号は１に設定することができる。受信機は、それらが支援しない主バージョン値を示すＴＰＴのインスタンスを捨てると予想され得る。

４ビット属性であってもよい＠ＭｉｎｏｒＰｒｏｔｏｃｏｌＶｅｒｓｉｏｎが存在する場合、テーブル定義の副バージョン番号を示すことができる。存在しない場合、その値は０にデフォルトすることができる。副バージョン番号は０に設定することができる。受信機は、それらが支援するように備えられていない副バージョン番号値を示すＴＰＴのインスタンスを捨てないと予想される。この場合、受信機はそれらが支援しない個別エレメント又は属性を無視すると予想される。

ＵＲＩである＠ｉｄは、当該ＴＰＴエレメントに関連する対話型プログラミングセグメントを固有に識別することができる。

８ビット整数であってもよい＠ｔｐｔＶｅｒｓｉｏｎは、ｉｄ属性によって識別されるｔｐｔエレメントのバージョン番号を示すことができる。ｔｐｔＶｅｒｓｉｏｎは、ＴＰＴが変更される度に増分（ｉｎｃｒｅｍｅｎｔ）されてもよい。

ＴＰＴエレメントの＠ｅｘｐｉｒｅＤａｔｅ属性は、存在する場合、当該ＴＰＴインスタンスに含まれた情報の満了日及び時間を示すことができる。万一、受信機がＴＰＴをキャッシュに保存すると、満了日まで再使用することができる。

１６ビットエレメントであってもよい＠ｕｐｄａｔｉｎｇＴｉｍｅは、存在する場合、ＴＰＴが修正されることを示すことができ、ＴＰＴを再びダウンロードするための秒単位の推薦区間を提供し、新しくダウンロードしたＴＰＴが新しいバージョンであるか否か確認する。

１６ビットエレメントであってもよい＠ｓｅｒｖｉｃｅＩＤは、存在する場合、このＴＰＴインスタンスで記述された対話型サービスと連携されたＮＲＴｓｅｒｖｉｃｅ＿ｉｄを示すことができる。これは、この対話型サービスのためのファイルが放送ストリームで伝達されるとき、受信機がサービスマップテーブルからＦＬＵＴＥパラメータを得るために必要である。

＠ｂａｓｅＵＲＬ属性は、存在する場合、当該ＴＰＴで登場する任意の相対ＵＲＬの前につくと、ベースＵＲＬを提供することができる。この属性は、ファイルの絶対ＵＲＬを提供することができる。

Ｃａｐａｂｉｌｉｔｉｅｓエレメントは、存在する場合、当該ＴＰＴと連携された対話型サービスの意味ある表出のために必須である能力を示すことができる。要求される能力のうち一つ以上を持たない受信機はサービスの表出を試みないと予想される。

ＬｉｖｅＴｒｉｇｇｅｒは、インターネットを介した活性化トリガーの伝達が利用可能な場合にのみ存在する。存在する場合、活性化トリガーを得るために受信機で必要とする情報を提供することができる。

ＬｉｖｅＴｒｉｇｇｅｒのチャイルド（ｃｈｉｌｄ）エレメントと属性については後述する。

ＴＰＴエレメントのチャイルドエレメントであるＴＤＯは、当該ＴＰＴインスタンスによって記述されたセグメントの間に対話型サービスの一部を提供するアプリケーション（例えば、ＴＤＯ）を示すことができる。

ＴＤＯのチャイルドエレメントと属性については後述する。

＠ｉｄの場合、セグメントの識別子の役割を担う。したがって、受信端でＴＰＴをパーシングした後に、＠ｉｄ情報を用いて、あるセグメントと連携されたトリガー又はＡＭＴなどを、そのセグメントを識別する＠ｉｄを有するＴＰＴとマッチングすることができる。したがって、トリガー及びＡＭＴの適用されるセグメントを探すことが可能になる。ＡＭＴに関する詳細な内容は後述する。

ＬｉｖｅＴｒｉｇｇｅｒエレメントは、＠ＵＲＬと＠ｐｏｌｌＰｅｒｉｏｄ属性を含むことができる。

上述した通り、ＬｉｖｅＴｒｉｇｇｅｒエレメントは、インターネットを介した活性化トリガーの伝達が利用可能な場合にのみ存在する。存在する場合、活性化トリガーを得るために受信機で必要とする情報を提供することができる。

ＬｉｖｅＴｒｉｇｇｅｒエレメントの属性である＠ＵＲＬは、インターネットを介して活性化トリガーを伝達し得るサーバーのＵＲＬを示すことができる。活性化トリガーは、対話型サービスプロバイダの選択によって、ＨＴＴＰショートポーリング（ｓｈｏｒｔ ｐｏｌｌｉｎｇ）、ＨＴＴＰロングポーリング（ｌｏｎｇ ｐｏｌｌｉｎｇ）、又はＨＴＴＰストリーミングを用いてインターネットを介して伝達することができる。

ＬｉｖｅＴｒｉｇｇｅｒエレメントの属性である＠ｐｏｌｌＰｅｒｉｏｄは、存在する場合、活性化トリガーの伝達のためにショートポーリングが使用中であることを示すことができ、ｐｏｌｌＰｅｒｉｏｄ属性値は、受信機がポーリング周期として用いる秒単位の推薦時間を示すことができる。

ＬｉｖｅＴｒｉｇｇｅｒエレメントが存在する場合、受信機は、当該ＴＰＴをパーシングして、活性化トリガーをインターネットを用いて伝達するための情報を得ることができる。＠ＵＲＬ情報から、活性化トリガーを伝達してもらえるサーバーのＵＲＬを得ることができる。＠ｐｏｌｌＰｅｒｉｏｄ情報から、或いは＠ｐｏｌｌＰｅｒｉｏｄ属性が存在しないという情報から、活性化トリガーがインターネットを介して伝達される方式とポーリング周期に関する情報を得ることができる。＠ｐｏｌｌＰｅｒｉｏｄの詳細な説明は後述する。

ＴＤＯエレメントは、＠ａｐｐＩＤ、＠ａｐｐＴｙｐｅ、＠ａｐｐＮａｍｅ、＠ｇｌｏｂａｌＩＤ、＠ａｐｐＶｅｒｓｉｏｎ、＠ｃｏｏｋｉｅＳｐａｃｅ、＠ｆｒｅｑｕｅｎｃｙＯｆＵｓｅ、＠ｅｘｐｉｒｅＤａｔｅ、＠ｔｅｓｔＴＤＯ、＠ａｖａｉｌＩｎｔｅｒｎｅｔ、＠ａｖａｉｌＢｒｏａｄｃａｓｔ属性と、ＵＲＬ、Ｃａｐａｂｉｌｉｔｉｅｓ、Ｃｏｎｔｅｎｔｉｔｅｍ、及び／又はＥｖｅｎｔエレメントを含むことができる。

上述した通り、ＴＰＴエレメントのチャイルドエレメントであるＴＤＯは、当該ＴＰＴインスタンスによって記述されたセグメントの間に対話型サービスの一部を提供するアプリケーション（例えば、ＴＤＯ）を示すことができる。

１６ビット整数であってもよい＠ａｐｐＩＤは、ＴＰＴ範囲内でアプリケーションを固有に識別することができる。活性化トリガーはａｐｐＩＤを参照してトリガーに対するターゲットアプリケーションを識別することができる。＠ａｐｐＩＤの場合、アプリケーションの識別子である。一つのＴＰＴには複数のアプリケーション（ＴＤＯのようなアプリケーション）があってもよい。したがって、ＴＰＴをパーシングした後に＠ａｐｐＩＤ情報を用いてアプリケーションを識別することができる。あるアプリケーションに適用されるトリガー又はＡＭＴなどを、そのアプリケーションを識別する＠ａｐｐＩＤを有するアプリケーションとマッチングさせることができる。したがって、トリガーとＡＭＴの適用されるアプリケーションを探すことが可能になる。ＡＭＴに関する詳細な内容は後述する。

８ビット整数であってもよい＠ａｐｐＴｙｐｅは、アプリケーションフォーマット類型を示すことができる。基本値は１に設定することができ、この値はＴＤＯを示すことができる。他の値は他のフォーマットを示すことができる。

ＴＤＯエレメントの属性である＠ａｐｐＮａｍｅは、アプリケーションを開始するために視聴者の許可を求めるとき、視聴者に表示し得る人間にとって読み取り可能な名前であってもよい。

ＴＤＯエレメントの属性である＠ｇｌｏｂａｌＩＤは、アプリケーションの全域的に固有な識別子であってもよい。多くの場合に、受信機は近いうちに再び用いるアップをキャッシュに保存する。このことが有用となるには、受信機は当該アップが将来に登場するとそれを認識できなければならない。当該アップが新しいセグメントで再び登場すると、受信機がそれを認識できるようにするためにｇｌｏｂａｌＩＤが必要である。

ＴＤＯエレメントの属性である＠ａｐｐＶｅｒｓｉｏｎは、アプリケーションのバージョン番号であってもよい。ａｐｐＶｅｒｓｉｏｎ値は、当該アプリケーション（ｇｌｏｂａｌＩＤによって識別されたアプリケーション）が変更される度に増分されてもよい。ａｐｐＶｅｒｓｉｏｎ属性は、ｇｌｏｂａｌＩＤ属性が存在しない限り存在することができない。

８ビット整数であってもよい＠ｃｏｏｋｉｅＳｐａｃｅは、各呼出し（ｉｎｖｏｃａｔｉｏｎ）間に持続性データ（ｐｅｒｓｉｓｔｅｎｔ ｄａｔａ）を保存するためにアプリケーションがどれくらい多くの空間を必要とするかを示すことができる。

４ビット整数であってもよい＠ｆｒｅｑｕｅｎｃｙＯｆＵｓｅは、受信機にそのアプリケーションコードキャッシュ空間の管理に関する案内を提供するために概略的にどれくらい頻繁に当該アプリケーションが放送で使われるかを示すことができる。‘＠ｆｒｅｑｕｅｎｃｙＯｆＵｓｅ’の詳細な説明は後述する。

ＴＤＯエレメントの属性である＠ｅｘｐｉｒｅＤａｔｅは、受信機が当該アプリケーション及び関連するリソースを安全に削除できる日付及び時間を示すことができる。

ブールの（Ｂｏｏｌｅａｎ）属性である＠ｔｅｓｔＴＤＯは、その値が“ｔｒｕｅ”として存在する場合、当該アプリケーションがテスト用であり、一般受信機では無視されてもよいことを示すことができる。

＠ａｖａｉｌＩｎｔｅｒｎｅｔ属性に対する「ｔｒｕｅ」値は、当該アプリケーションがインターネットを介したダウンロード用に利用可能であることを示すことができる。その値が「ｆａｌｓｅ」であれば、当該アプリケーションがインターネットを介したダウンロード用に利用可能でないことを示すことができる。属性が存在しない場合、基本値は「ｔｒｕｅ」であってもよい。

＠ａｖａｉｌＢｒｏａｄｃａｓｔ属性に対する「ｔｒｕｅ」値は、当該アプリケーションが放送からの抽出に利用可能であることを示すことができる。「ｆａｌｓｅ」値は、当該アプリケーションが放送からの抽出に利用可能でないことを示すことができる。属性が存在しない場合、基本値は「ｔｒｕｅ」であってもよい。

ＴＤＯエレメントのチャイルドエレメントであるＵＲＬの各インスタンスは、当該アプリケーションの一部であるファイルを識別することができる。インスタンスＵＲＬエレメントは＠ｅｎｔｒｙ属性を含むことができる。

ＵＲＬエレメントの属性である＠ｅｎｔｒｙは「ｔｒｕｅ」値を有すると、当該ＵＲＬが当該アプリケーションのエントリポイント（ｅｎｔｒｙ ｐｏｉｎｔ）、すなわち、当該アプリケーションを開始するために開始され得るファイルであることを示すことができる。「ｆａｌｓｅ」値を有すると、当該ＵＲＬが当該アプリケーションのエントリポイントでないことを示すことができる。当該属性が登場しないとき、基本値は「ｆａｌｓｅ」であってもよい。

ＴＤＯエレメントのチャイルドエレメントであるＵＲＬエレメントは、上述した通り、当該アプリケーションをなすファイルを識別する。受信端ではＴＰＴをパーシングして当該ＵＲＬ情報を得た後、それを用いてサーバーに接続して、当該ＵＲＬ情報が示すアプリケーションをダウンロードすることとなる。

ＴＤＯエレメントのチャイルドエレメントであるＣａｐａｂｉｌｉｔｉｅｓは、存在する場合、当該アプリケーションの意味ある表出のために必須である能力を示すことができる。要求される能力のうち一つ以上を持たない受信機は当該アプリケーションの開始を試みないと予想される。

ＴＤＯエレメントのチャイルドエレメントであるＣｏｎｔｅｎｔＩｔｅｍは、当該アプリケーションで必要とする一つ以上のデータファイルで構成されたコンテンツアイテムを示すことができる。ＣｏｎｔｅｎｔＩｔｅｍエレメントは、このエレメントの属しているＴＤＯエレメントが示すアプリケーションが必要とするデータファイルに関する情報を有する。受信端ではパーシングを行った後、ＣｏｎｔｅｎｔＩｔｅｍエレメントが存在する場合、ＣｏｎｔｅｎｔＩｔｅｍ内のＵＲＬ情報などを用いて、当該アプリケーションが必要とするデータファイルをダウンロードしたりできる。ＣｏｎｔｅｎｔＩｔｅｍのチャイルドエレメントと属性については後述する。

ＴＤＯエレメントのチャイルドエレメントであるＥｖｅｎｔは、当該アプリケーションのためのイベントを示すことができる。Ｅｖｅｎｔエレメントは、このエレメントの属しているアプリケーションのイベントを示す。いかなるイベントを有しているか、該当データにはどのようなものがあるか、該当動作にはどのようなものがあるか等に関する情報を含んでいる。これをパーシングして受信端ではアプリケーションのイベントに関する情報を得ることができる。Ｅｖｅｎｔのチャイルドエレメントと属性については後述する。

受信端でＴＰＴを受けてパーシングすると、ＴＤＯ及び上述したＴＤＯのチャイルドエレメントと属性の情報を得ることができる。

ＴＤＯエレメントのチャイルドエレメントの一つである、ｃｏｎｔｅｎｔＩｔｅｍエレメントは、＠ｕｐｄａｔｅＡｖａｉｌ、＠ｐｏｌｌＰｅｒｉｏｄ、＠ｓｉｚｅ、＠ａｖａｉｌＩｎｔｅｒｎｅｔ、＠ａｖａｉｌＢｒｏａｄｃａｓｔａｔｔｒｉｂｕｔｅ及び／又はＵＲＬエレメントを含むことができる。

ここで、ＵＲＬエレメントは＠ｅｎｔｒｙ属性を含むことができる。

ＣｏｎｔｅｎｔＩｔｅｍエレメントのチャイルドエレメントであるＵＲＬの各インスタンスは、コンテンツアイテムの一部であるファイルを識別することができる。ＵＲＬエレメントは＠ｅｎｔｒｙ属性を含むことができる。

ＵＲＬエレメントの属性である＠ｅｎｔｒｙは、「ｔｒｕｅ」値を有すると、該当ＵＲＬが当該コンテンツアイテムのエントリポイント、すなわち、当該コンテンツアイテムを開始するために開始され得るファイルであることを示すことができる。「ｆａｌｓｅ」値を有すると、当該ＵＲＬが当該コンテンツアイテムのエントリポイントでないことを示すことができる。当該属性が登場しないとき、基本値は「ｆａｌｓｅ」であってもよい。

ＣｏｎｔｅｎｔＩｔｅｍエレメントのブールのである＠ｕｐｄａｔｅｓＡｖａｉｌは、当該コンテンツアイテムがたまにアップデートされるか否か、すなわち、コンテンツアイテムが固定ファイル（ｓｔａｔｉｃ ｆｉｌｅ）で構成されるか、それとも、当該アイテムが実時間データフィード（ｆｅｅｄ）であるかを示すことができる。その値が「ｔｒｕｅ」であれば、当該コンテンツアイテムはたまにアップデートされ、その値が「ｆａｌｓｅ」であれば、当該コンテンツアイテムはアップデートされない。この属性が登場しないと、基本値は「ｆａｌｓｅ」であってもよい。

ＣｏｎｔｅｎｔＩｔｅｍエレメントの属性である＠ｐｏｌｌＰｅｒｉｏｄは、ｕｐｄａｔｅｓＡｖａｉｌ属性の値が「ｔｒｕｅ」の場合にのみ存在することができる。＠ｐｏｌｌＰｅｒｉｏｄが存在する場合、活性化トリガーを伝達するためにショートポーリングが用いられていることを示すことができ、＠ｐｏｌｌＰｅｒｉｏｄ属性の値は、受信機がポーリング周期として使用するための秒単位の推薦時間を示すことができる。

ＣｏｎｔｅｎｔＩｔｅｍエレメントの属性である＠Ｓｉｚｅは、当該コンテンツアイテムの大きさを示すことができる。

＠ａｖａｉｌＩｎｔｅｒｎｅｔ属性は、その値が「ｔｒｕｅ」であれば、当該コンテンツアイテムがインターネットを介したダウンロードに利用可能であることを示すことができる。その値が「ｆａｌｓｅ」であれば、当該コンテンツアイテムがインターネットを介したダウンロードに利用可能でないことを示すことができる。この属性が存在しない場合、基本値は「ｔｒｕｅ」であってもよい。

＠ａｖａｉｌＢｒｏａｄｃａｓｔ属性は、その値が「ｔｒｕｅ」であれば、当該コンテンツアイテムが放送からの抽出に利用可能であることを示すことができる。「ｆａｌｓｅ」値は、当該コンテンツアイテムが放送からの抽出に利用可能でないことを示すことができる。属性が存在しない場合、基本値は「ｔｒｕｅ」であってもよい。

受信端ではパーシングを行った後、ＣｏｎｔｅｎｔＩｔｅｍ内のＵＲＬ情報などを用いて、当該アプリケーションが必要とするデータファイルをダウンロードすることができる。この過程で上述したその他属性による情報を用いることができる。

ＴＤＯエレメントのチャイルドエレメントの一つである、Ｅｖｅｎｔエレメントは、＠ｅｖｅｎｔＩＤ、＠ａｃｔｉｏｎ、＠ｄｅｓｔｉｎａｔｉｏｎ、＠ｄｉｆｆｕｓｉｏｎ属性、及び／又はＤａｔａエレメントを含むことができる。ここでＤａｔａエレメントは＠ｄａｔａＩＤ属性を含むことができる。

Ｅｖｅｎｔエレメントの１６ビット整数属性である＠ｅｖｅｎｔＩＤは、これを含むＴＤＯエレメントの範囲内で当該イベントを固有に識別することができる。活性化トリガー（又は、ＡＭＴ内活性化エレメント）は、ａｐｐＩＤとｅｖｅｎｔＩＤの組合せによって当該トリガーに対するターゲットアプリケーションとイベントを識別することができる。イベントが活性化されると、受信機は当該イベントを当該アプリケーションに伝達することができる。

Ｅｖｅｎｔエレメントの属性である＠ａｃｔｉｏｎは、当該イベントが活性化されるときに適用される動作の類型を示すことができる。許容される値は、「ｐｒｅｐ」、「ｅｘｅｃ」、「ｓｕｓｐ」及び「ｋｉｌｌ」であってもよい。

「ｐｒｅｐ」は、「Ｔｒｉｇ ｐｒｅｐ」動作に対応できる。ターゲットとなったアプリケーションの状態が「Ｒｅｌｅａｓｅｄ」であれば、この動作は「Ｒｅａｄｙ」への状態変更を起こすことができる。

「ｅｘｅｃ」は、「Ｔｒｉｇ ｅｘｅｃ」動作に対応できる。このトリガーを受信すると、ターゲットとなったアプリケーションの状態は「Ａｃｔｉｖｅ」になり得る。

「ｓｕｓｐ」は、「Ｔｒｉｇ ｓｕｓｐ」動作に対応できる。このトリガーを受信すると、ターゲットとなったアプリケーションの状態が「Ａｃｔｉｖｅ」である場合、「Ｓｕｓｐｅｎｄｅｄ」に変更可能であり、そうでない場合は変更されない。

「ｋｉｌｌ」は、「Ｔｒｉｇ ｋｉｌｌ」動作に対応できる。このトリガーを受信すると、ターゲットとなったアプリケーションの状態は「Ｒｅｌｅａｓｅｄ」になり得る。

Ｅｖｅｎｔエレメントの属性である＠ｄｅｓｔｉｎａｔｉｏｎは、当該イベントのためのターゲット装置を示すことができる。＠ｄｅｓｔｉｎａｔｉｏｎに関する詳細な内容は後述する。

Ｅｖｅｎｔエレメントの８ビット整数属性であってもよい＠ｄｉｆｆｕｓｉｏｎは、存在する場合、秒単位の時間周期Ｔを示すことができる。この拡散パラメータの目的は、サーバーローディングの最大値を均一にすることである。受信機は０〜Ｔの範囲で１０ミリセカンド単位でランダム時間を算出し、ＴＰＴでＵＲＬによって参照されたコンテンツを検索するためにインターネットサーバーに接続する前にこの時間量だけ遅延されると予想され得る。

ＥｖｅｎｔエレメントのチャイルドエレメントであるＤａｔａは、存在する場合、当該イベントに関連するデータを提供することができる。Ｅｖｅｎｔの互いに異なる活性化は、それらと連携された異なるＤａｔａエレメントを有することができる。ここで、Ｄａｔａエレメントは＠ｄａｔａＩＤ属性を含むことができる。

１６ビット整数属性である＠ｄａｔａＩＤは、これを含むＥｖｅｎｔエレメントの範囲内でＤａｔａエレメントを固有に識別することができる。イベントの活性化がこれと連携されたデータを持つ場合、活性化トリガーは、ＡｐｐＩＤ、ＥｖｅｎｔＩＤ及びＤａｔａＩＤの組合せによって該当Ｄａｔａエレメントを識別することができる。

Ｅｖｅｎｔエレメントは、属しているＴＤＯエレメントが示すアプリケーションに対するイベントに関する情報を含んでいる。受信端ではＥｖｅｎｔエレメントをパーシングしてその情報を得ることができる。

＠ｅｖｅｎｔＩＤの場合、イベントの識別子の役割を担う。＠ｅｖｅｎｔＩＤ情報を用いて、そのイベントを活性化しようとする関連したトリガー又はＡＭＴなどをそのイベントを識別する＠ｅｖｅｎｔＩＤを有するアプリケーションとマッチングさせることができる。すなわち、活性化トリガー（又は、ＡＭＴ内活性化エレメント）はａｐｐＩＤとｅｖｅｎｔＩＤの組合せによって当該トリガーに対するターゲットアプリケーションを識別することができる。イベントが活性化されると、受信機はそのイベントを当該アプリケーションに渡すことができる。ＡＭＴに関する詳細な内容は後述する。

＠ａｃｔｉｏｎは、当該イベントが活性化されるときに適用される動作の類型を示すことができる。

Ｄａｔａエレメントの場合、当該イベントに用いられるデータを意味する。一つのイベントエレメントは複数のデータエレメントを有することができる。データエレメントの＠ｄａｔａＩＤ属性を用いてデータの識別をする。受信端では該当データに関連するイベントが活性化された場合、活性化トリガー（又は、ＡＭＴ内活性化エレメント）は、ＡｐｐＩＤ、ＥｖｅｎｔＩＤ、及びＤａｔａＩＤの組合せによってＤａｔａエレメントを識別することができる。ＡＭＴに関する詳細な内容は後述する。

図７は、「Ｆｒｅｑｕｅｎｃｙ ｏｆ Ｕｓｅ」属性値の意味の一実施例を示す図である。

「意味」列は、当該アプリケーションを含むセグメントの発生頻度を示す。（もちろん、一つのセグメント内で一つの属性が複数回登場可能である。）ｆｒｅｑｕｅｎｃｙＯｆＵｓｅ属性は、ｇｌｏｂａｌＩＤが存在しなければ存在することができない。万一、アップがキャッシュに保存されて後で用いられるとすれば、受信機は、該当アップが後で再び登場すると、同一のアップとして認識しなければならない。そのためにｇｌｏｂａｌＩｄ属性が必要である。

図８は、「ｄｅｓｔｉｎａｔｉｏｎ」属性値の意味の一実施例を示す図である。

図８に示すように、目的地属性の値が０のときに予約され、１のときに主装置のみを意味し、２のときに一つ以上の補助装置のみを意味し、３のときに主装置及び／又は一つ以上の補助装置を意味することができる。

図９、図１０、図１１、図１２、図１３は、ＴＤＯパラメータテーブルの２進形態のシンタックスの一実施例を示す図である。

これは、上述したＴＰＴ構造の２進フォーマットである。この構造は、ＮＲＴでＴＰＴを送信する場合に必要なフォーマットであって、ＴＰＴのＸＭＬ構造をＮＲＴで送信するのに適するように作成しておいたものである。ＴＰＴのＸＭＬバージョンに含まれた次のエレメント及び／又は属性、すなわち、＠ｐｒｏｔｏｃｏｌＶｅｒｓｉｏｎ（ｍａｊｏｒ／ｍｉｎｏｒ）、＠ｓｅｒｖｉｃｅＩＤ及び＠ｔｐｔＶｅｒｓｉｏｎは、２進テーブルを伝達するためのカプセル化ヘッダー（ｅｎｃａｐｓｕｌａｔｉｏｎ ｈｅａｄｅｒ）によって放送ストリームで提供できるため、２進バージョンから省略することができる。

フィールドのセマンティックスは、次の通りである。図９、図１０、図１１、図１２、図１３の順に続くＴＤＯパラメータテーブルの２進フォーマットにおいて、上から下に登場する順に記述した。

１ビットフィールドであってもよいｅｘｐｉｒｅ＿ｄａｔｅ＿ｉｎｃｌｕｄｅｄは、ｅｘｐｉｒｅ＿ｄａｔｅｆｉｅｌｄが含まれるか否かを示すことができる。その値が‘１’であれば、当該フィールドが含まれることを意味でき、その値が「０」であれば、含まれないことを意味できる。

５ビットフィールドであってもよいｓｅｇｍｅｎｔ＿ｉｄ＿ｌｅｎｇｔｈは、ｓｅｇｍｅｎｔ＿ｉｄのバイト長を示すことができる。

可変長フィールドであるｓｅｇｍｅｎｔ＿ｉｄは、セグメントＩＤのバイトを含むことができるが、これは、ＴＰＴＸＭＬフォーマットの「ｉｄ」属性と同じセマンティックスを有することができる。

８ビットフィールドであってもよいｂａｓｅ＿ＵＲＬ＿ｌｅｎｇｔｈは、ｂａｓｅ＿ＵＲＬフィールドのバイト長を示すことができる。

可変長フィールドであるｂａｓｅ＿ＵＲＬはベースＵＲＬのバイトを含むことができるが、これは、ＴＰＴＸＭＬフォーマットのｂａｓｅＵＲＬ属性と同じセマンティックスを有することができる。

３２ビットフィールドであってもよいｅｘｐｉｒｅ＿ｄａｔｅは、当該ＴＰＴインスタンスに含まれた情報の満了日及び時間を示すことができる。受信機がＴＰＴをキャッシュに保存すると、満了日まで再使用することができる。無符号整数（ｕｎｓｉｇｎｅｄ ｉｎｔｅｇｅｒ）は、１９８０年１月６日００：００：００ ＵＴＣ以後、ＧＰＳ秒（ｓｅｃｏｎｄ）の数からＧＰＳ−ＵＴＣ＿ｏｆｆｓｅｔを引いたものと解釈することができる。ＧＰＳ ＵＴＣオフセットはＧＰＳとＵＴＣ時刻標準間現在の全体秒単位オフセットを定義する８ビット無符号整数であってもよい。

８ビットフィールドであってもよいｔｒｉｇｇｅｒ＿ｓｅｒｖｅｒ＿ＵＲＬ＿ｌｅｎｇｔｈは、ｔｒｉｇｇｅｒ＿ｓｅｒｖｅｒ＿ＵＲＬフィールドのバイト長を示すことができる。このフィールドの値が０であれば、個々の活性化トリガーのインターネット伝達が利用可能でないことを示すことができる。

ｔｒｉｇｇｅｒ＿ｓｅｒｖｅｒ＿ＵＲＬ＿ｌｅｎｇｔｈフィールドが０でなければ、ｔｒｉｇｇｅｒ＿ｓｅｒｖｅｒ＿ＵＲＬは、Ｔｒｉｇｇｅｒ Ｓｅｒｖｅｒ ＵＲＬのバイトを含むことができ、これはＴＰＴＸＭＬフォーマットのＬｉｖｅＴｒｉｇｇｅｒエレメントのＵＲＬ属性と同じセマンティックスを有することができる。

１ビットフィールドであってもよいｔｒｉｇｇｅｒ＿ｄｅｌｉｖｅｒｙ＿ｔｙｐｅは、インターネットを介した個別活性化トリガーの伝達モードを示すことができる、「０」値を有すると、ＨＴＴＰショートポーリングが使用中であることを示すことができ、「１」値を有すると、ＨＴＴＰロングポーリング又はＨＴＴＰストリーミングが使用中であることを示すことができる。

８ビット整数であってもよいｐｏｌｌ＿ｐｅｒｉｏｄは、ＨＴＴＰショートポーリングが使用中であるとき、ポール間の推奨される秒の数を示すことができる。

８ビットフィールドであってもよいｎｕｍ＿ａｐｐｓ＿ｉｎ＿ｔａｂｌｅは、当該ＴＰＴインスタンスで記述されたアプリケーション（ＴＤＯ）の数を示すことができる。

１６ビットフィールドであってもよいａｐｐ＿ｉｄは、当該アプリケーション（ｎｕｍ＿ａｐｐｓ＿ｉｎ＿ｔａｂｌｅループ（ｌｏｏｐ）の反復で記述されるアプリケーション）に対する識別子を含むことができる。これは、当該ＴＰＴインスタンス内で固有であってもよい。

１ビットフィールドであってもよいａｐｐ＿ｔｙｐｅ＿ｉｎｃｌｕｄｅｄは、ａｐｐ＿ｔｙｐｅフィールドが当該アプリケーションに対して含まれるか否かを示すことができる。その値が「１」であれば、当該フィールドが含まれることを意味し、その値が‘０’であれば、含まれないことを意味できる。

１ビットフィールドであってもよいａｐｐ＿ｎａｍｅ＿ｉｎｃｌｕｄｅｄは、ａｐｐ＿ｎａｍｅフィールドが当該アプリケーションに対して含まれるか否かを示すことができる。その値が「１」であれば、当該フィールドが含まれることを意味し、その値が‘０’であれば、含まれないことを意味できる。

１ビットフィールドであってもよいｇｌｏｂａｌ＿ｉｄ＿ｉｎｃｌｕｄｅｄは、ｇｌｏｂａｌ＿ｉｄフィールドが当該アプリケーションに対して含まれるか否かを示すことができる。その値が「１」であれば、当該フィールドが含まれることを意味し、その値が‘０’であれば、含まれないことを意味できる。

１ビットフィールドであってもよいａｐｐ＿ｖｅｒｓｉｏｎ＿ｉｎｃｌｕｄｅｄは、ａｐｐ＿ｖｅｒｓｉｏｎフィールドがこのアプリケーションに対して含まれるか否かを示すことができる。その値が「１」であれば、当該フィールドが含まれることを意味し、その値が「０」であれば、含まれないことを意味できる。

１ビットフィールドであってもよいｃｏｏｋｉｅ＿ｓｐａｃｅ＿ｉｎｃｌｕｄｅｄは、ｃｏｏｋｉｅ＿ｓｐａｃｅフィールドがこのアプリケーションに対して含まれるか否かを示すことができる。その値が「１」であれば、当該フィールドが含まれることを意味し、その値が「０」であれば、含まれないことを意味できる。

１ビットフィールドであってもよいｆｒｅｑｕｅｎｃｙ＿ｏｆ＿ｕｓｅ＿ｉｎｃｌｕｄｅｄは、ｆｒｅｑｕｅｎｃｙ＿ｏｆ＿ｕｓｅフィールドがこのアプリケーションに対して含まれるか否かを示すことができる。その値が「１」であれば、当該フィールドが含まれることを意味し、その値が「０」であれば、含まれないことを意味できる。

１ビットフィールドであってもよいｅｘｐｉｒｅ＿ｄａｔｅ＿ｉｎｃｌｕｄｅｄは、ｅｘｐｉｒｅ＿ｄａｔｅフィールドがこのアプリケーションに対して含まれるか否かを示すことができる。その値が「１」であれば、当該フィールドが含まれることを意味し、その値が「０」であれば、含まれないことを意味できる。

８ビットフィールドであってもよいａｐｐ＿ｔｙｐｅは、存在する場合、このアプリケーションのフォーマット類型を示すことができる。その値が０であれば、そのアプリケーションがＴＤＯであることを示すことができる。万一、このフィールドが存在しない場合、その値は０にデフォルトされる。他の値は他のフォーマットを示すことができる。

８ビットフィールドであってもよいａｐｐ＿ｎａｍｅ＿ｌｅｎｇｔｈは、存在する場合、その直後にくるａｐｐ＿ｎａｍｅフィールドのバイト長を示すことができる。このフィールドの値が０であれば、該当アプリケーションのためのａｐｐ＿ｎａｍｅフィールドが存在しないことを示すことができる。

可変長フィールドであるａｐｐ＿ｎａｍｅは、ＴＰＴ ＸＭＬフォーマットであるＴＤＯエレメントのａｐｐＮａｍｅ属性と同じセマンティックスを有することができる。

８ビットフィールドであってもよいｇｌｏｂａｌ＿ｉｄ＿ｌｅｎｇｔｈは、その直後にくるｇｌｏｂａｌ＿ｉｄフィールドのバイト長を示すことができる。このフィールド値が０であれば、当該アプリケーションのためのｇｌｏｂａｌ＿ｉｄフィールドが存在しないことを示すことができる。

可変長フィールドであるｇｌｏｂａｌ＿ｉｄは、ＴＰＴ ＸＭＬフォーマットのＴＤＯエレメントのｇｌｏｂａｌＩｄ属性と同じセマンティックスを有することができる。

８ビットフィールドであってもよいａｐｐ＿ｖｅｒｓｉｏｎは、ＴＰＴ ＸＭＬフォーマットのＴＤＯエレメントのａｐｐＶｅｒｓｉｏｎ属性と同じセマンティックスを有する。

８ビットフィールドであってもよいｃｏｏｋｉｅ＿ｓｐａｃｅは、ＴＰＴ ＸＭＬフォーマットのＴＤＯエレメントのｃｏｏｋｉｅＳｐａｃｅ属性と同じセマンティックスを有することができる。

８ビットフィールドであってもよいｆｒｅｑｕｅｎｃｙ＿ｏｆ＿ｕｓｅは、存在する場合、ＴＰＴ ＸＭＬフォーマットのＴＤＯエレメントのｆｒｅｑｕｅｎｃｙＯｆＵｓｅ属性と同じセマンティックスを有することができる。

８ビットフィールドであってもよいｅｘｐｉｒｅ＿ｄａｔｅは、ＴＰＴ ＸＭＬフォーマットのＴＤＯエレメントのｅｘｐｉｒｅＤａｔｅ属性と同じセマンティックスを有することができる。

１ビットフィールドであってもよいｔｅｓｔ＿ａｐｐは、当該アプリケーションが一般受信機に無視されるようになっているテストアプリケーションであるか否かを示すことができる。その値が「１」であれば、テストアプリケーションであることを意味でき、その値が「０」であれば、テストアプリケーションでないことを意味できる。

１ビットフィールドであってもよいａｖａｉｌａｂｌｅ＿ｏｎ＿ｉｎｔｅｒｎｅｔは、当該アプリケーションがインターネットを介して利用可能か否かを示すことができる。その値が「１」であれば、インターネットを介して利用可能であることを意味でき、その値が「０」であれば、インターネットを介して利用可能でないことを意味できる。

１ビットフィールドであってもよいａｖａｉｌａｂｌｅ＿ｉｎ＿ｂｒｏａｄｃａｓｔは、当該アプリケーションが放送を介して利用可能か否かを示すことができる。その値が「１」であれば、放送を介して利用可能であることを意味でき、その値が「０」であれば、放送を介して利用可能でないことを意味できる。

４ビットフィールドであってもよいｎｕｍｂｅｒ＿ＵＲＬｓは、当該アプリケーションを含むファイルの数を示すことができる。

８ビットフィールドであってもよいＵＲＬ＿ｌｅｎｇｔｈは、それに続くＵＲＬフィールドの長さを示すことができる。

可変長フィールドであるＵＲＬは、ＴＰＴ ＸＭＬフォーマットであるＴＤＯエレメントのＵＲＬ属性と同じセマンティックスを有することができる。

８ビットフィールドであってもよいｎｕｍｂｅｒ＿ｃｏｎｔｅｎｔ＿ｉｔｅｍｓは、このアプリケーションによる使用のためにダウンロードしなければならないコンテンツアイテムの数を示すことができる。

１ビットフィールドであってもよいｕｐｄａｔｅｓ＿ａｖａｉｌは、このコンテンツアイテムがたまにアップデートされる否か、すなわち、コンテンツアイテムが固定ファイルの集合であるか、それとも、実時間データフィードであるかを示すことができる。その値が「１」であれば、アップデートされることを示すことができ、その値が「０」であれば、アップデートされないことを示すことができる。

１ビットフィールドであってもよいａｖａｉｌ＿ｉｎｔｅｒｎｅｔは、このコンテンツアイテムを含むファイルをインターネットを介してダウンロードできるか否かを示すことができる。その値が「１」であれば、インターネットを介したダウンロードに利用可能であることを意味でき、その値が「０」であれば、インターネットを介したダウンロードに利用可能でないことを意味できる。

[１ビットフィールドであってもよいａｖａｉｌ＿ｂｒｏａｄｃａｓｔは、このコンテンツアイテムを含むファイルを放送を介してダウンロードできるか否かを示すことができる。その値が「１」であれば、放送を介したダウンロードに利用可能であることを意味でき、その値が「０」であれば、放送を介したダウンロードに利用可能でないことを意味できる。

１ビットフィールドであってもよいｃｏｎｔｅｎｔ＿ｓｉｚｅ＿ｉｎｃｌｕｄｅｄは、このアプリケーションのためにｃｏｎｔｅｎｔ＿ｓｉｚｅフィールドが含まれるか否かを示すことができる。その値が「１」であれば、当該フィールドが含まれることを意味でき、その値が「０」であれば、含まれないことを意味できる。

４ビットフィールドであってもよいｎｕｍｂｅｒ＿ＵＲＬｓは、このコンテンツアイテムを含むファイルの数を示すことができる。

８ビットフィールドであってもよいＵＲＬ＿ｌｅｎｇｔｈは、それに続くＵＲＬフィールドの長さを示すことができる。

可変長フィールドであるＵＲＬは、ＴＰＴ ＸＭＬフォーマットであるＴＤＯエレメントのチャイルドエレメントであるＣｏｎｔｅｎｔＩｔｅｍのＵＲＬ属性と同じセマンティックスを有することができる。

２４ビットフィールドであってもよいｃｏｎｔｅｎｔ＿ｓｉｚｅは、ＴＰＴ ＸＭＬフォーマットであるＴＤＯエレメントのチャイルドエレメントであるＣｏｎｔｅｎｔＩｔｅｍのｃｏｎｔｅｎｔＳｉｚｅ属性と同じセマンティックスを有することができる。

８ビットフィールドであってもよいｎｕｍ＿ｃｏｎｔｅｎｔ＿ｄｅｓｃｒｉｐｔｏｒｓは、その直後にくるデスクリプタループ内のコンテンツデスクリプタの数を示すことができる。

可変長フィールドであるｃｏｎｔｅｎｔ＿ｄｅｓｃｒｉｐｔｏｒ（）は、ＭＰＥＧ−２デスクリプタフォーマット（タグ、長さ、データ）に従うデスクリプタであってもよい。このフィールドは、当該コンテンツアイテムに関する付加情報を提供することができる。このデスクリプタループに含み得るデスクリプタの中に、このコンテンツアイテムの意味ある表出のために必要な受信機能力を示すＣａｐａｂｉｌｉｔｉｅｓデスクリプタがあってもよい。

８ビットフィールドであってもよいｎｕｍｂｅｒ＿ｅｖｅｎｔｓは、このＴＤＯに対して定義されたイベントの数を示すことができる。

１６ビットフィールドであってもよいｅｖｅｎｔ＿ｉｄは、当該イベント（ｎｕｍｂｅｒ＿ｅｖｅｎｔｓループの反復で記述されたイベント）のための識別子を含むことができる。このフィールドは、当該アプリケーションの範囲内で唯一であってもよい。当該イベントはａｐｐ＿ｉｄとｅｖｅｎｔ＿ｉｄの組合せによって活性化トリガーら内で参照されてもよい。

５ビットフィールドであってもよいａｃｔｉｏｎは、ＴＰＴ ＸＭＬフォーマットであるＴＤＯエレメントのＥｖｅｎｔチャイルドエレメントのａｃｔｉｏｎ属性と同じセマンティックスを有することができる。

１ビットフィールドであってもよいｄｅｓｔｉｎａｔｉｏｎ＿ｉｎｃｌｕｄｅｄは、当該イベントのためにｄｅｓｔｉｎａｔｉｏｎフィールドが含まれるか否かを示すことができる。その値が「１」であれば、このフィールドが含まれることを示すことができ、その値が「０」であれば、含まれないことを示すことができる。

１ビットフィールドであってもよいｄｉｆｆｕｓｉｏｎ＿ｉｎｃｌｕｄｅｄは、当該イベントのためにｄｉｆｆｕｓｉｏｎフィールドが含まれるか否かを示すことができる。その値が「１」であれば、このフィールドが含まれることを示すことができ、その値が「０」であれば、含まれないことを示すことができる。

１ビットフィールドであってもよいｄａｔａ＿ｉｎｃｌｕｄｅｄは、当該イベントのためにｄａｔａ＿ｓｉｚｅとｄａｔａ＿ｂｙｔｅｓフィールドが含まれるか否かを示すことができる。その値が「１」であれば、このフィールドらが含まれることを示すことができ、その値が「０」であれば、含まれないことを示すことができる。

ｄｅｓｔｉｎａｔｉｏｎフィールドのセマンティックスは、存在する場合、ＴＰＴ ＸＭＬフォーマットであるＴＤＯエレメントのＥｖｅｎｔチャイルドエレメントのｄｅｓｔｉｎａｔｉｏｎ属性のセマンティックスと同一であってもよい。

ｄｉｆｆｕｓｉｏｎフィールドのセマンティックスは、存在する場合、ＴＰＴ ＸＭＬフォーマットであるＴＤＯエレメントのＥｖｅｎｔチャイルドエレメントのｄｉｆｆｕｓｉｏｎ属性のセマンティックスと同一であってもよい。

ｄａｔａ＿ｓｉｚｅフィールドは、存在する場合、その直後にくるｄａｔａ＿ｂｙｔｅｓフィールドの大きさを示すことができる。

ｄａｔａ＿ｂｙｔｅｓフィールドは、存在する場合、当該イベントに関連するデータを提供することができる。当該イベントが活性化される度にターゲットアプリケーションはそのデータを読み取り、それを用いて所望の動作の実行を助けることができる。このフィールドは、原始（ｒａｗ）の２進値を含み得るということを除けば、その内容がＴＰＴ ＸＭＬフォーマットである該当のＴＤＯエレメントの該当のＥｖｅｎｔチャイルドエレメントの該当のＤａｔａチャイルドエレメントの内容と同一なあってもよく、ＴＰＴ ＸＭＬフォーマットであるこのＤａｔａエレメントはその２進値のベース６４エンコーディングを含むことができる。

８ビットフィールドであってもよいｎｕｍ＿ａｐｐ＿ｄｅｓｃｒｉｐｔｏｒｓは、その直後にくるデスクリプタループ内のデスクリプタの数を示すことができる。

可変長フィールドであるａｐｐ＿ｄｅｓｃｒｉｐｔｏｒ（）は、ＭＰＥＧ−２デスクリプタフォーマット（タグ、長さ、データ）に従うデスクリプタであってもよい。このフィールドは、当該アプリケーション（ＴＤＯ）に関する付加情報を提供することができる。このデスクリプタループに含み得るデスクリプタの中に、このアプリケーションの意味ある表出のために必要な受信機能力を示すＣａｐａｂｉｌｉｔｉｅｓデスクリプタがあってもよい。

８ビットフィールドであってもよいｎｕｍ＿ＴＰＴ＿ｄｅｓｃｒｉｐｔｏｒｓは、その直後にくるデスクリプタループ内のデスクリプタの数を示すことができる。

可変長フィールドであるＴＰＴ＿ｄｅｓｃｒｉｐｔｏｒ（）は、ＭＰＥＧ−２デスクリプタフォーマット（タグ、長さ、データ）に従うデスクリプタであってもよい。このフィールドは、当該ＴＰＴに関する付加情報を提供することができる。このデスクリプタループに含み得るデスクリプタの中に、このＴＰＴによって示される対話型サービスの意味ある表出のために必要な受信機能力を示すＣａｐａｂｉｌｉｔｉｅｓデスクリプタがあってもよい。

図１４は、活性化メッセージテーブル構造の一実施例を示す図である。以下、テーブルに含まれる各フィールドについて説明する。各フィールドの大きさとテーブルに含み得るフィールドの種類は、設計者の意図によって追加又は変更されてもよい。

以下、ＡＭＴについて説明する。

ＡＭＴ（Ａｃｔｉｖａｔｉｏｎ Ｍｅｓｓａｇｅｓ Ｔａｂｌｅ）は、セグメントのための活性化トリガーに相応するものを含むことができる。ある環境では活性化トリガーに代えてこのＡＭＴが受信機に伝達されてもよい。トリガーは、「ｌｉｖｅ ｔｒｉｇｇｅｒ」サーバーによって、ＡＣＲサーバーによってＡＭＴを介してクローズドキャプション（ｃｌｏｓｅｄ ｃａｐｔｉｏｎ）ストリームで伝達されてもよい。

ＡＭＴ構造内のフィールドの具体的なセマンティックスは、次の通りである。

活性化メッセージテーブル（ＡＭＴ）は、＠ｍａｊｏｒＰｒｏｔｏｃｏｌＶｅｒｓｉｏｎ、＠ｍｉｎｏｒＰｒｏｔｏｃｏｌＶｅｒｓｉｏｎ、＠ｓｅｇｍｅｎｔＩｄ、＠ｂｅｇｉｎＭＴ属性、及び／又はＡｃｔｉｖａｔｉｏｎエレメントを含むことができる。

AMTエレメントの4ビット属性であってもよい＠majorProtocolＶｅｒｓｉｏｎは、ＡＭＴ定義の主バージョン番号を示すことができる。主バージョン番号は１に設定することができる。受信機は、それらが支援するように備えられていない主バージョン値を示すＡＭＴのインスタンスを捨てると予想され得る。

ＡＭＴエレメントの４ビット属性であってもよい＠ｍｉｎｏｒＰｒｏｔｏｃｏｌＶｅｒｓｉｏｎは、存在する場合、ＡＭＴ定義の副バージョン番号を示すことができる。存在しない場合、その値は０にデフォルトすることができる。副バージョン番号は０に設定することができる。受信機は、それらが支援するように備えられていない副バージョン値を示すＡＭＴのインスタンスを捨てないと予想され得る。この場合、受信機はそれらが支援しない個別エレメント又は属性を無視すると予想されてもよい。

ＡＭＴの識別子である＠ｓｅｇｍｅｎｔＩＤは、ＡＭＴ内Ａｃｔｉｖａｔｉｏｎが適用されるアプリケーション及びイベントを含むＴＰＴの識別子とマッチングされる。

ＡＭＴエレメントの属性である＠ｂｅｇｉｎＭＴは、存在する場合、ＡＭＴインスタンスが活性化時間を提供するセグメントのメディア時間の開始を示すことができる。

ＡＭＴのＡｃｔｉｖａｔｉｏｎエレメントの各インスタンスは、あるイベントをこのイベントと連携されたあるデータと共にある時間に活性化する命令を示すことができる。

＠ｓｅｇｍｅｎｔＩｄは、ＡＭＴの識別子の役割を担うことができる。したがって、受信端でＡＭＴを受信した後にこれをパーシングし、＠ｓｅｇｍｅｎｔＩｄ情報を用いてＡＭＴを識別することができる。＠ｓｅｇｍｅｎｔＩｄは、ＡＭＴがどのセグメントに適用されるべきかに関する情報を含んでおり、そのセグメントに関連するＴＰＴが有している＠ｉｄとマッチングされてＡＭＴとＴＰＴとを連結する役割を担うことができる。さらに、まず当該ｓｅｇｍｅｎｔを識別することによって、ＡＭＴ内のそれぞれのＡｃｔｉｖａｔｉｏｎエレメントがターゲットとするＴＤＯ、イベントを識別するために必要な基本的な情報を提供することができる。

＠ｂｅｇｉｎＭＴは、属しているＡＭＴが適用されるセグメントに対してメディア時間の開始を示すことができる。これによって、Ａｃｔｉｖａｔｉｏｎエレメントが示す活性化が発生する時間の基準を定めることができる。したがって、＠ｂｅｇｉｎＭＴがある場合、Ａｃｔｉｖａｔｉｏｎエレメント内の＠ｓｔａｒｔＴｉｍｅ属性は、＠ｂｅｇｉｎＭＴが示すメディア時間の開始に影響を受けることができる。

Ａｃｔｉｖａｔｉｏｎエレメントは、ＡＭＴ内に複数個が存在してもよい。各Ａｃｔｉｖａｔｉｏｎエレメントは、活性化トリガーと同様の役割を担うことができる。Ａｃｔｉｖａｔｉｏｎエレメントはいずれも、ＡＭＴ内の＠ｓｅｇｍｅｎｔＩｄが示すセグメントに適用することができる。Ａｃｔｉｖａｔｉｏｎエレメント内の属性に、該当活性化がどのアプリケーションの、どのイベントに、いつ起きるかに関する情報などを含めることができる。Ａｃｔｉｖａｔｉｏｎエレメント内の属性に関する詳細な説明は後述する。

Ａｃｔｉｖａｔｉｏｎエレメントは、＠ｔａｒｇｅｔＴＤＯ、＠ｔａｒｇｅｔＥｖｅｎｔ、＠ｔａｒｇｅｔＤａｔａ、＠ｓｔａｒｔＴｉｍｅ、＠ｅｎｄＴｉｍｅの属性を含むことができる。

Ａｃｔｉｖａｔｉｏｎエレメントの属性である＠ｔａｒｇｅｔＴＤＯは、ＡＭＴに連携されたＴＰＴ内のＴＤＯエレメントのａｐｐＩＤ属性とマッチングされることによって、活性化命令に対するターゲットアプリケーションを識別することができる。

Ａｃｔｉｖａｔｉｏｎエレメントの属性である＠ｔａｒｇｅｔＥｖｅｎｔは、ｔａｒｇｅｔＴＤＯ属性によって識別されるＴＤＯエレメントに含まれたＥｖｅｎｔエレメントのｅｖｅｎｔＩＤ属性とマッチングされることによって、当該活性化命令に対するターゲットイベントを識別することができる。

Ａｃｔｉｖａｔｉｏｎエレメントの属性である＠ｔａｒｇｅｔＤａｔａは、ｔａｒｇｅｔＴＤＯとｔａｒｇｅｔＥｖｅｎｔ属性によって識別されるＥｖｅｎｔエレメントに含まれたＤａｔａエレメントのｄａｔａＩＤとマッチングされることによって、活性化命令が適用される時にターゲットイベントと連携されるデータを識別することができる。

イベントエレメントの属性である＠ｓｔａｒｔＴｉｍｅは、メディア時間に対するイベントの有効期間の開始を示すことができる。受信機は、メディア時間がｓｔａｒｔＴｉｍｅ内の値に到達する時又はその後のできるだけ近いうちに当該命令を実行すると予想され得る。

イベントエレメントの属性である＠ｅｎｄＴｉｍｅは、メディア時間に対する当該イベントのための有効期間の終わりを示すことができる。受信機は、メディア時間がｅｎｄＴｉｍｅの値を経過すると当該命令を実行しないと予想され得る。

＠ｔａｒｇｅｔＴＤＯは、ＡＭＴ内のＡｃｔｉｖａｔｉｏｎエレメントがどのアプリケーションに適用されるかに関する情報を含むことができる。受信端ではＡＭＴを受信しパーシングして＠ｔａｒｇｅｔＴＤＯを得、マッチングされるＴＰＴ内のＴＤＯエレメント内の＠ａｐｐＩＤを探して、Ａｃｔｉｖａｔｉｏｎエレメントの適用されるアプリケーションを識別することができる。

＠ｔａｒｇｅｔＥｖｅｎｔは、ＡＭＴ内のＡｃｔｉｖａｔｉｏｎエレメントがどのアプリケーションのどのイベントに適用されるかに関する情報を含むことができる。受信端ではＡＭＴを受信しパーシングして＠ｔａｒｇｅｔＥｖｅｎｔを得、マッチングされるＴＰＴ内のＴＤＯエレメント内の＠ｅｖｅｎｔＩＤを探して、Ａｃｔｉｖａｔｉｏｎエレメントの適用されるイベントを識別することができる。

＠ｔａｒｇｅｔＤａｔａは、活性化命令が適用されるとき、ターゲットとなったイベントに関連するデータを識別することができる。受信端ではＡＭＴを受信しパーシングして＠ｔａｒｇｅｔＤａｔａを得、ＴＰＴ内の該当Ｅｖｅｎｔエレメント内の＠ｄａｔａＩＤを探すことができる。

＠ｓｔａｒｔＴｉｍｅは、当該イベントが起きる開始時間を示すことができる。この開始時間はメディア時間を基準とする。受信端ではＡＭＴをパーシングして＠ｓｔａｒｔＴｉｍｅ情報を得、これを用いてイベントの起きる時間が把握できる。受信端では、＠ｓｅｇｍｅｎｔＩｄによって識別されたセグメントのメディア時間を基準にメディア時間が開始時間（ｓｔａｒｔ Ｔｉｍｅ）に達すると、イベントを活性化させることができる。万一、既に開始時間が過ぎた場合は、できるだけ早くイベントを活性化させることができる。

＠ｅｎｄＴｉｍｅは、当該イベントが終わる時間を示すことができる。メディア時間が終わる時間に達すると、受信端ではイベントを実行させなくてもよい。

ＡＭＴ内Ａｃｔｉｖａｔｉｏｎエレメントは、ｓｔａｒｔＴｉｍｅ値の昇順で登場できる。

受信機がＡＭＴ内Ａｃｔｉｖａｔｉｏｎによってイベントを活性化させるとき、受信機は、各活性化をその開始時間に適用したり、又はその後にできるだけ近いうちに適用（例えば、受信機がサービスに加入して、開始時間以後と終了時間以前との間におけるある時間にＡＭＴを受信する場合）すると予想され得る。ＴＰＴ内イベントエレメントの「ａｃｔｉｏｎ」属性が「ｅｘｅｃ」であれば、受信機はＴｒｉｇｇｅｒＥｖｅｎｔをターゲットアプリケーションに渡すと予想できる。ＴｒｉｇｇｅｒＥｖｅｎｔについては、ＡＰＩに関する部分で後述する。

以下、ＵＲＬリストについて説明する。

ＵＲＬリストは、受信機に対して使用潜在性のあるＵＲＬを含むことができる。次のようなＵＲＬなどを含むことができる。

１．一つ又はそれ以上の未来セグメントに対するＴＰＴのためのＵＲＬ。受信機がファイルを予めダウンロードできるようにする。

２．放送ストリーム内の独立型ＮＲＴサービスに関する情報が検索され得るＮＲＴシグナリングサーバーのＵＲＬ。受信機に放送ストリーム内のＮＲＴサービスシグナリングの伝達に対する接近権限がなくてもこれらのサービスに接近可能になる。

３．仮想チャネルに対する使用報告が送信される使用報告サーバーのＵＲＬ。受信機に放送ストリーム内のこのＵＲＬの伝達に対する接近権限がなくてもこのような報告を送信可能にする。

４．仮想チャネルに対するＰＤＩ−ＱテーブルのＵＲＬ。受信機に放送ストリームで伝達されたＰＤＩ−Ｑテーブルに対する接近権限がなくても視聴経験を個人化可能にする。（ＰＤＩ−Ｑテーブルは対話型サービスを提供するにあたり、ユーザにカスタマイズサービスを提供するための個人化（ｐｅｒｓｏｎａｌｉｚａｔｉｏｎ）に関連するテーブルである。ＰＤＩ−Ｑテーブルを介してユーザに個人化のための質問ができる。）

そのうち、ＵｓｒＵｒｌエレメントに関して、ＵＲＬリストを作ってさらに使用報告のためのサーバーのＵＲＬを知らせる必要があり得る。これは、現在、受信機が視聴し消耗しているコンテンツの種類と好むデータを活用してビジネスに活用するためであってもよい。ＵＲＬリストにあるＵｓｒＵｒｌエレメントは、次のように様々に解釈可能である。

第一は、使用報告サーバーである場合は、受信機はこの使用報告サーバーのＵＲＬをもって、予め定められたプロトコル（例、データ構造、ＸＭＬファイルなど）によって受信機の使用報告機能を果たすことができる。

第二は、受信機のウェブブラウザで実行されるＴＤＯであってもよい。ここでは、使用報告ＴＤＯの位置を知らせ、この場合、ＴＤＯが直接、受信機のウェブブラウザのＡＰＩ（例、ファイルＡＰＩ、使用報告ＡＰＩ）を用いて受信機に保存された或いは現在消耗しているコンテンツの情報を収集して報告することができる。ＴＤＯは、独自でＸＭＬＨｔｔｐＲｅｑｕｅｓｔというジャバスクリプトＡＰＩを活用して収集されたデータを送信することができる。

図１５は、ＵＲＬリスト構造の一実施例を示す図である。

ＵＲＬｌｉｓｔは、ＵｒｌＬｉｓｔ、ＴｐｔＵｒｌ、ＵｒｓＵｒｌ、及び／又はＰｄｉＵｒｌなどを含むことができる。これらのエレメントのセマンティックスは次の通りである。

ＵｒｌＬｉｓｔエレメントのエレメントであるＴｐｔＵｒｌは、現在の対話型付加サービス内の未来セグメントに対するＴＰＴのＵＲＬを含むことができる。複数のＴｐｔＵｒｌエレメントが含まれた場合、放送内のセグメントの登場順に配列することができる。

ＵｒｌＬｉｓｔエレメントのエレメントであるＮｒｔＳｉｇｎａｌｉｎｇＵｒｌは、受信機が現在のトランスポートストリーム内の全ての仮想チャネルに対するＮＲＴシグナリングテーブルを取得し得るサーバーのＵＲＬを含むことができる。

ＵｒｌＬｉｓｔエレメントのエレメントであるＵｒｓＵｒｌは、受信機が現在の仮想チャネルに対する使用（視聴率調査）報告を送信し得るサーバーのＵＲＬを含むことができる。

ＵｒｌＬｉｓｔエレメントのエレメントであるＰｄｉＵｒｌは、現在の仮想チャネルに対するＰＤＩ−ＱテーブルのＵＲＬを含むことができる。

以下、伝達メカニズムについて説明する。

以下、対話型サービス生成からの結果、放送ストリーム内でのトリガーの伝達、インターネットを介した時間ベーストリガーの伝達、インターネットを介した活性化トリガーの伝達（ＡＣＲシナリオ）、放送ストリーム内でのＴＰＴの伝達、インターネットを介したＴＰＴの伝達、ＴＤＯ及びコンテンツアイテムの移動、複数のセグメントを一つのセグメントに結合の順に説明する。

以下、対話型サービス生成からの結果について説明する。

一つのセグメントに対するサービス生成過程は、全てのＴＤＯ及び他のコンテンツアイテムを含むフォルダ、ＸＭＬ ｆｏｒｍａｔのＴＰＴファイル、及びＸＭＬ ｆｏｒｍａｔのＡＭＴファイルを生成することができる。その他の結果物も生成することができる。

次に、放送ストリーム内でのトリガーの伝達について説明する。

放送ストリームで伝達される場合、トリガーはＵＲＬＳｔｒｉｎｇ命令内でサービス＃６でＤＴＶクローズドキャプションチャネルで伝達することができる。

万一、トリガーの長さが２６文字以下であれば、トリガーはセグメント化せずに送信することができる（Ｔｙｐｅ＝１１）。万一、トリガーの長さが２７乃至５２文字であれば、２つのセグメント（ｔｈｅ ｆｉｒｓｔ ｓｅｇｍｅｎｔ ｉｎ ａ Ｔｙｐｅ＝００セグメントである一番目のセグメントと、Ｔｙｐｅ＝１０セグメントである２番目のセグメント）で送信されてもよい。

当該命令の与えられた任意のインスタンスで伝達されたＵＲＩの類型は、インスタンス８ビットパラメータによって与えることができる。

ＴＤＯモデルを使用する対話型サービスの場合、ＵＲＩデータ構造のＵＲＩ類型は、０（ＴＤＯモデルのための対話型Ｉｎｔｅｒａｃｔｉｖｅ ＴＶトリガー）に設定することができる。この伝達メカニズムは、時間ベーストリガーも活性化トリガーも含む。

時間ベーストリガーが（クローズドキャプションサービス＃６で）放送ストリームで伝達される場合に、「ｍ＝」項が不在であれば、時間ベーストリガーは単純にシグナリングサーバーのＵＲＬを伝達することができる。そして、「ｍ＝」項が不在であれば、「ｔ＝」項は活性化トリガーに不在でなければならない。

活性化トリガーが（クローズドキャプションサービス＃６で）放送ストリームで伝達される場合に、すなわち、「Ｔｒｉｇｇｅｒ」フォーマットが「ｅ＝」項を有しており、「ｔ＝」項は有しているかいない場合に、「ｔ＝」項が存在すれば、活性化時間は時間ベースに対するタイムスタンプであってもよい。そして、「ｔ＝」項が不在であれば、活性化時間はメッセージの到達時間になってもよい。

時間ベーストリガーと活性化トリガーがＣＣサービス＃６を通じて伝達される場合、放送局が時間ベーストリガーと活性化トリガーを扱う方式には、次の３つがある。

１．明示的な時間ベースがないセグメントモード

２．明示的な時間ベースがあるセグメントモード

３．明示的な時間ベースがあるサービスモード

これらは放送内でセグメント単位で混合されてもよい。

明示的な時間ベースがないセグメントモードでは、活性化メッセージがタイムスタンプを含まないため、各メッセージの活性化時間はそのメッセージの伝達時間となり、また、時間ベースメッセージがタイムスタンプを含まないため、その唯一の目的はＴＰＴファイルを伝達し得るシグナリングサーバーのＵＲＬを提供することであり得る。このモードでは、シグナリングサーバーのＵＲＬを提供するための活性化メッセージ内のＵＲＬによって時間ベースメッセージが完全に省略されてもよいが、この場合受信機は、最初の活性化メッセージが登場するまでＴＰＴを検索したり、ＴＤＯのダウンロードを開始できなくなり、活性化メッセージに対する応答をだいぶ遅延することになる。

このような場合、ＣＣサービス＃６に登場し得る時間ベースメッセージは、「Ｔｒｉｇｇｅｒ」フォーマットの「ｌｏｃａｔｏｒ＿ｐａｒｔ」を含むことができ、「ｓｐｒｅａｄ」項も含むことができるが、「ｍｅｄｉａ＿ｔｉｍｅ」項は含まなくてもよい。そして、ＣＣサービス＃６で登場し得る活性化メッセージは、「Ｔｒｉｇｇｅｒ」フォーマットの「ｌｏｃａｔｏｒ＿ｐａｒｔ」と「ｅｖｅｎｔ＿ｔｉｍｅ」項を含むことができ、「ｓｐｒｅａｄ」項も含むことができるが、「イベント＿ｔｉｍｅ」項には「ｔ＝」部分がなくてもよい。時間ベース及び活性化メッセージの「ｌｏｃａｔｏｒ＿ｐａｒｔ」は現在のｓｅｇｍｅｎｔＩｄであってもよい。このＵＲＬは、インターネットを介してセグメントのためのＴＰＴを検索するために用いられてもよい。

明示的な時間ベースがあるサービスモードにおいて、時間ベースメッセージは時間ベースを定義するためにこのタイムスタンプを含む。活性化メッセージは、時間ベースに対する活性化時間を定義するために時間スタンプを含む。又は、これらのメッセージはタイムスタンプを含まなくてもよく、この場合、活性化時間はメッセージの到達時間である。

この場合、ＣＣサービス＃６で登場し得る時間ベースメッセージは、「Ｔｒｉｇｇｅｒ」フォーマットの「ｌｏｃａｔｏｒ＿ｐａｒｔ」と「ｍｅｄｉａ＿ｔｉｍｅ」項を含むことができ、「ｓｐｒｅａｄ」項も含んでもよく、ＣＣサービス＃６で登場し得る活性化メッセージは「Ｔｒｉｇｇｅｒ」フォーマットの「ｌｏｃａｔｏｒ＿ｐａｒｔ」と「ｅｖｅｎｔ＿ｔｉｍｅ」項を含むことができ、「ｓｐｒｅａｄ」項も含んでもよく、このとき、「ｅｖｅｎｔ＿ｔｉｍｅ」項内の「ｔ＝」部分は存在してもしなくてもよい。時間ベース及び活性化メッセージの「ｌｏｃａｔｏｒ＿ｐａｒｔ」は現在のｓｅｇｍｅｎｔＩｄであってもよく、該当時間ベースは該当セグメントに特定である。このＵＲＬは、インターネットを介してセグメントのためのＴＰＴを検索するために用いられてもよい。

明示的な時間ベースがあるサービスモードにおいて、時間ベースメッセージは時間ベースを定義するためにこのタイムスタンプを含み、活性化メッセージは時間スタンプを含んでも含まなくてもよい。時間ベースは特定の一セグメントに特定されるよりは、複数のセグメントにわたって延長することができる。時間ベースメッセージの「ｌｏｃａｔｏｒ＿ｐａｒｔ」は、時間ベースの識別子であってもよく、インターネットを介してサービスのためのＴＰＴを検索するために使用可能なＵＲＬであってもよい。

いずれの場合であれ、ＣＣサービス＃６にトリガーを挿入するトリガー挿入サーバーは、ＡＭＴから作業をして、活性化メッセージをＡＭＴ内のＸＭＳフォーマットからＣＣサービス＃６での伝達に特定されたトリガーフォーマットに変えなければならない。ｅｎｄＴｉｍｅ属性がないＡｃｔｉｖａｔｉｏｎエレメントの場合は、活性化時間がｓｔａｒｔＴｉｍｅ属性と同一であり、単一トリガーが挿入されてもよい。ｓｔａｒｔＴｉｍｅとｅｎｄＴｉｍｅエレメントの両方を有するＡｃｔｉｖａｔｉｏｎエレメントの場合は、同一のターゲットをもってトリガーシーケンスが挿入されてもよい。シーケンス内の最初のトリガーは、ｓｔａｒｔＴｉｍｅ属性と同じ活性化時間を有することができ、当該シーケンス内の最後のトリガーは、ｅｎｄＴｉｍｅ属性と同じ活性化時間を有することができ、シーケンス内のトリガーの活性化時間の間には固定した時間区間が存在できる（例外として、シーケンス内の最後のトリガーとその直前のトリガーとの間の区間はより短くてもよい。）。この固定した時間区間の長さは設定可能である。

時間ベース及び活性化メッセージがセグメントモードであるとき、時間ベースは、セグメントに対して特定することができる。このベースは、当該セグメントの開始時に「ｂｅｇｉｎＭＴ」値で始まって、セグメントを通じて行うことができる。個々の活性化の「ｓｔａｒｔＴｉｍｅ」と「ｅｎｄＴｉｍｅ」値は、「ｂｅｇｉｎＭＴ」値に対して相対的であってもよい。時間ベース及び活性化メッセージがサービスモードにあるとき、時間ベースはセグメントにわたっていてもよく、各セグメントに対する「ｂｅｇｉｎＭＴ」値は、サービス時間ベースと放送スケジュールを考慮して調整することができる。

次に、インターネットを介した時間ベーストリガーの伝達について説明する。

時間ベーストリガーインターネット伝達は、いわゆる自動コンテンツ認識（Ａｕｔｏｍａｔｉｃ Ｃｏｎｔｅｎｔ Ｒｅｃｏｇｎｉｔｉｏｎ、ＡＣＲ）状況で有用であり得るが、このような状況で、時間ベーストリガーの受信側はクローズドキャプションサービス＃６に対する接近権限がない。このような状況で受信機はビデオフレームを認識し、時間ベースをこれらのフレームと同期化させるためにＡＣＲを使用しなければならない。ＡＣＲ状況で時間ベースメッセージはウォーターマーク又はＡＣＲサーバーから得ることができる。ＡＣＲサーバーから受ける場合、時間ベースメッセージはＡＣＲサーバーから応答として伝達されてもよい。

次に、インターネットを介した活性化トリガーの伝達（ＡＣＲシナリオ）について説明する。

活性化メッセージは、ショートポーリング、ロングポーリング又はストリーミングを通じて伝達することができるが、これらのメッセージはいずれも受信機とサーバーに相当のオーバーロードを発生させ得る。活性化メッセージは、ＡＭＴの形態で伝達されてもよいが、セグメントの長さに関する多い量の情報を提供し、広告サイト遮断器（ａｄ ｋｉｌｌｅｒ）を可能にすることができる。他の方法もあり得る。

活性化メッセージが活性化トリガーの形態で伝達される場合に、すなわち、「Ｔｒｉｇｇｅｒ」ｆｏｒｍａｔにおいて「ｅ＝」項はあり、「ｔ＝」項はあるかない場合に、これは、ＨＴＴＰショートポーリング、ロングポーリング又はストリーミングを通じて伝達され得る。

インターネットを介して伝達される場合、活性化メッセージを次のメカニズムのいずれか一方又は両方を用いて伝達することができる。

１．活性化トリガー個別伝達

２．活性化トリガー一括伝達

次に、個別的活性化トリガー伝達について説明する。

前述したように、個別活性化トリガーは、インターネットを介して伝達されるとき、ＨＴＴＰショートポーリング、ロングポーリング又はストリーミングを用いて伝達すことができる。活性化トリガーのフォーマットはＤＴＶＣＣサービス＃６を通じて伝達されるときと同一であってもよい。

ショートポーリングの場合は、そのポーリング周期を指定しなければならない。この周期は、次の説明のように、ＴＰＴにあるｐｏｌｌＰｅｒｉｏｄを用いてショートポーリング動作を設定することができる。

活性化トリガーのインターネット伝達が利用可能な場合、ＴＰＴ内ＬｉｖｅＴｒｉｇｇｅｒエレメントのＵＲＬ属性は、活性化トリガーを伝達し得る活性化トリガーサーバーを示すことができる。ＬｉｖｅＴｒｉｇｇｅｒエレメントのｐｏｌｌＰｅｒｉｏｄ属性がＴＰＴに存在する場合、これはＨＴＴＰショートポーリングが使用中であることを示すことができ、この属性は、受信機が用いるべきポーリング周期を示すことができる。ＬｉｖｅＴｒｉｇｇｅｒエレメントのｐｏｌｌＰｅｒｉｏｄ属性がＴＰＴに存在しない場合、これは、ＨＴＴＰロングポーリングとＨＴＴＰストリーミングのいずれか一方が使用中であることを示すことができる。

いずれのプロトコルが用いられるかにかかわらず、受信機は質疑形式で活性化トリガーサーバーにＨＴＴＰ要求をすると予想され得る。

?mt=<media_time>

ここで、＜ｍｅｄｉａ＿ｔｉｍｅ＞は、視聴されているコンテンツの現在メディア時間であってもよい。

ショートポーリングが使用中である場合、活性化トリガーサーバーからの応答は、＜ｍｅｄｉａ＿ｔｉｍｅ＞で終わるｐｏｌｌＰｅｒｉｏｄ長の時間区間内で発生した全てのトリガーを含むことができる。一つ以上の活性化トリガーがリターンされる場合、これらは一つ以上の空白（ｗｈｉｔｅｓｐａｃｅ）文字によって分離することができる。万一、リターンされる活性化トリガーがないと、当該応答は空いていてもよい。

ＨＴＴＰロングポーリング又はＨＴＴＰストリーミングが使用中である場合は、活性化トリガーサーバーは、活性化トリガーが放送ストリームで伝達されるメディア時間まで応答のリターンを待機することができる。このとき、活性化トリガーをリターンすることができる。

ＨＴＴＰロングポーリングが使用中である場合、活性化トリガーサーバーは、活性化トリガーをリターン後にセッションを閉じることができる。受信機はアップデートされたメディア時間を用いて直ちに他の要求をすると予想され得る。

ＨＴＴＰストリーミングが使用中である場合、活性化トリガーサーバーは、各活性化トリガーをリターンした後に当該セッションを開いた状態に維持し、追加の活性化トリガーを伝達する時間が到達すると、当該セッションでそれらのトリガーを伝達することができる。

いずれの場合においても、ＨＴＴＰ応答は、伝達モードを知らせるために、次の形態のいずれかの形態からなるＨＴＴＰ Ｒｅｓｐｏｎｓｅ Ｈｅａｄｅｒフィールドを含むことができる。
ATSC-Delivery-Mode:ShortPolling[<poll-period>]
ATSC-Delivery-Mode:LongPolling
ATSC-Delivery-Mode:Streaming
＜ｐｏｌｌ−ｐｅｒｉｏｄ＞パラメータは、連続するポールに対してポール間の推奨間隔を示すことができる。＜ｐｏｌｌ−ｐｅｒｉｏｄ＞は省略されてもよい。

次に、活性化トリガー一括伝達について説明する。

活性化トリガーがインターネットを介して一括的に伝達される場合、一つのセグメントに対する活性化トリガーを、当該セグメントに対するＴＰＴをメッセージの一番目の部分とし、ＡＭＴをメッセージの二番目の部分とする多重部分ＭＩＭＥメッセージの形態としてＨＴＴＰを通じて当該セグメントに対するＴＰＴと共に伝達することができる。

図１６は、ＴＰＴを含むプライベートセクション（ｐｒｉｖａｔｅ ｓｅｃｔｉｏｎ）の２進フォーマットの一実施例を示す図である。以下に説明するＮＲＴ−スタイルプライベートセクションは、図１６の通りである。

以下、放送ストリームでのＴＰＴ伝達について説明する。

放送ストリームで伝達時に、ＴＰＴを、それらのＸＭＬフォーマットから相応する２進ＮＲＴ−スタイルシグナリングフォーマットに変換して、テーブルインスタンス当たり一つずつＮＲＴ−スタイルプライベートセクションにカプセル化することができる。現在セグメントに対するＴＰＴは常に存在する。一つ以上の未来セグメントにに対するＴＰＴも存在することができる。ＴＰＴインスタンスは、そのｓｅｇｍｅｎｔ＿ｉｄフィールドの値によって定義される。参考として、ＴＤＯパラメータテーブルの２進フォーマットは、上述した通りである。

要するに、ＴＰＴの２進構造をＮＲＴで送信するために、ＮＲＴ送信に合うようにセクション構造を有することができる。以下、この過程について詳しく説明する。

各ＴＰＴをブロックに分割し、それらのブロックをｔａｂｌｅ＿ｉｄ、ｐｒｏｔｏｃｏｌ＿ｖｅｒｓｉｏｎＴＰＴ＿ｄａｔａ＿ｖｅｒｓｉｏｎとｓｅｑｕｅｎｃｅ＿ｎｕｍｂｅｒフィールドの共通値を持つセクションのｔｐｔ＿ｂｙｔｅｓ（）フィールドに挿入することによって、各ＴＰＴをＮＲＴ−スタイルプライベートセクション内にカプセル化することができる。これらのブロックは、ｓｅｃｔｉｏｎ＿ｎｕｍｂｅｒフィールド値の昇順でセクションに挿入することができる。プライベートセクションは、ＴＰＴに関連する仮想チャネルのＩＰサブネットのサービスシグナリングチャネル（Ｓｅｒｖｉｃｅ Ｓｉｇｎａｌｉｎｇ Ｃｈａｎｎｅｌ；ＳＳＣ）で送信することができる。ここで、「Ｓｅｒｖｉｃｅ Ｓｉｇｎａｌｉｎｇ Ｃｈａｎｎｅｌ」は、ＡＴＳＣ−ＮＲＴ標準に定義されており、特定ＩＰアドレスとポートナンバーを持つチャネルを意味する。セクション内のｓｅｑｕｅｎｃｅ＿ｎｕｍｂｅｒフィールドは、同一ＳＳＣで送信される互いに異なるＴＰＴインスタンスを区別するために用いることができる。

プライベートセクション（ｔｐｔ＿ｓｅｃｔｉｏｎ（））は、ｔａｂｌｅ＿ｉｄ、ｐｒｏｔｏｃｏｌ＿ｖｅｒｓｉｏｎ、ｓｅｑｕｅｎｃｅ＿ｎｕｍｂｅｒ、ＴＰＴ＿ｄａｔａ＿ｖｅｒｓｉｏｎ、ｃｕｒｒｅｎｔ＿ｎｅｘｔ＿ｉｎｄｉｃａｔｏｒ、ｓｅｃｔｉｏｎ＿ｎｕｍｂｅｒ、ｌａｓｔ＿ｓｅｃｔｉｏｎ＿ｎｕｍｂｅｒ、及び／又はｓｅｒｖｉｃｅ＿ｉｄ、ｔｐｔ＿ｂｙｔｅｓ（）情報を含むことができる。

以下、図１６のフィールドについて説明する。

８ビットフィールドであってもよいｔａｂｌｅ＿ｉｄは、当該テーブルセクションをＴＤＯパラメータテーブルインスタンスに属するものとして識別することができる。

ｐｒｏｔｏｃｏｌ＿ｖｅｒｓｉｏｎは２つの部分に分けることができる。８ビット無符号整数フィールドのうち上位４ビットは、当該テーブルの定義の主バージョン番号と、ここに含まれて送信されるＴＰＴインスタンスを示すことができ、下位４ビットは、副バージョン番号を示すことができる。主バージョン番号は１に設定することができる。受信機は、それらが支援するように備えられていない主バージョン値を示すＡＭＴのインスタンスを捨てると予想され得る。副バージョン番号は０に設定することができる。受信機は、それらが支援するように備えられていない副バージョン値を示すＡＭＴのインスタンスを捨てないと予想され得る。この場合、受信機は、それらが認識できないデスクリプタと、それらが支援しないフィールドを無視すると予想され得る。

ｓｅｑｕｅｎｃｅ＿ｎｕｍｂｅｒは、８ビットフィールドであってもよい。ｓｅｑｕｅｎｃｅ＿ｎｕｍｂｅｒは、当該ＴＰＴインスタンスの他の全てのセクションのｓｅｑｕｅｎｃｅ＿ｎｕｍｂｅｒと同一であり、当該サービスシグナリングチャネル内の他のＴＰＴインスタンスの全てのセクションのｓｅｑｕｅｎｃｅ＿ｎｕｍｂｅｒとは異なってよい。したがって、他のＴＰＴインスタンスと区別する役割を担うことができる。ｓｅｑｕｅｎｃｅ＿ｎｕｍｂｅｒフィールドは、このセクションが現れるサービスシグナリングチャネルに連携されたＩＰサブネットを示すことができる。互いに異なるＴＰＴインスタンスのｓｅｑｕｅｎｃｅ＿ｎｕｍｂｅｒフィールド値は、放送ストリームでセグメントが登場する順序を反映することができる。

ＴＰＴ＿ｄａｔａ＿ｖｅｒｓｉｏｎは、５ビットフィールドであってもよく、当該ＴＰＴインスタンスのバージョン番号を示すことができるが、ここで、ＴＰＴインスタンスは、そのｓｅｇｍｅｎｔ＿ｉｄによって定義することができる。ＴＰＴバージョンをあらかじめ知ってこそ受信されたＴＰＴセクションデータが最新バージョンのＴＰＴであるか否かがわかるため、セクションテーブルにＴＰＴ＿ｄａｔａ＿ｖｅｒｓｉｏｎフィールドがあってもよい。バージョン番号は、ＴＰＴインスタンス内の任意のフィールドに変更がある場合、１ ｍｏｄｕｌｏ ３２分ずつ増分できる。

ｃｕｒｒｅｎｔ＿ｎｅｘｔ＿ｉｎｄｉｃａｔｏｒは１ビット指示子であってもよく、ＴＰＴセクションに対して常に「１」に設定されて送信されるＴＰＴがｓｅｇｍｅｎｔ＿ｉｄによって識別されるセグメントに対して常に現在ＴＰＴであることを示すことができる。

ｓｅｃｔｉｏｎ＿ｎｕｍｂｅｒは８ビットフィールドであってもよく、当該ＴＰＴインスタンスセクションのセクション番号を提供することができるが、ＴＰＴインスタンスはｓｅｇｍｅｎｔ＿ｉｄによって識別可能である。ＴＰＴインスタンス内の最初のセクションのｓｅｃｔｉｏｎ＿ｎｕｍｂｅｒは０ｘ００であってもよい。ｓｅｃｔｉｏｎ＿ｎｕｍｂｅｒは、ＴＰＴインスタンス内の各追加セクションと共に１ずつ増分可能である。

ｌａｓｔ＿ｓｅｃｔｉｏｎ＿ｎｕｍｂｅｒは８ビットフィールドであってもよく、最後のセクション（すなわち、ｓｅｃｔｉｏｎ＿ｎｕｍｂｅｒが最も高いセクション）が、その一部であるＴＰＴインスタンスの最後のセクション番号を提供することができる。

ｓｅｒｖｉｃｅ＿ｉｄは、当該テーブルインスタンスに記述されたコンテンツアイテムを提供する対話型サービスと連携されたｓｅｒｖｉｃｅ＿ｉｄを特定することができる。

ｔｐｔ＿ｂｙｔｅｓ（）は、可変長フィールドであって、当該セクションによって部分的に送信されるＴＰＴインスタンスブロックで構成することができる。当該テーブルインスタンスの全てのセクションのｔｐｔ＿ｂｙｔｅｓ（）フィールドがｓｅｃｔｉｏｎ＿ｎｕｍｂｅｒフィールドの順に連結されると、その結果として一つの完全なＴＰＴインスタンスが作成できる。

すなわち、ＴＰＴの２進フォーマットを用いたり、ＸＭＬフォーマットを２進フォーマットに変えた後、ＮＲＴ送信に合うようにそれを分けて、プライベートセクションのうちｔｐｔ＿ｂｙｔｅｓ（）フィールドに入れてＮＲＴ方式で送信することができる。このとき、一つのＴＰＴが複数のプライベートセクションに分けられると、それぞれのプライベートセクションは、同一のｔａｂｌｅ＿ｉｄ、ｐｒｏｔｏｃｏｌ＿ｖｅｒｓｉｏｎＴＰＴ＿ｄａｔａ＿ｖｅｒｓｉｏｎ、ｓｅｑｕｅｎｃｅ＿ｎｕｍｂｅｒ値を有することができる。分けられたＴＰＴブロックをｓｅｃｔｉｏｎ＿ｎｕｍｂｅｒフィールド値に従う順に挿入することができる。

受信端では、受信したプライベートセクションに対してパーシングできる。一つのＴＰＴに再びまとめるために、同一のｔａｂｌｅ＿ｉｄ、ｐｒｏｔｏｃｏｌ＿ｖｅｒｓｉｏｎＴＰＴ＿ｄａｔａ＿ｖｅｒｓｉｏｎ、ｓｅｑｕｅｎｃｅ＿ｎｕｍｂｅｒ値を持つプライベートセクションを用いることができる。このとき、ｓｅｃｔｉｏｎ＿ｎｕｍｂｅｒとｌａｓｔ＿ｓｅｃｔｉｏｎ＿ｎｕｍｂｅｒ情報から得られる順序情報を用いることができる。同一のｔａｂｌｅ＿ｉｄ、ｐｒｏｔｏｃｏｌ＿ｖｅｒｓｉｏｎＴＰＴ＿ｄａｔａ＿ｖｅｒｓｉｏｎ、ｓｅｑｕｅｎｃｅ＿ｎｕｍｂｅｒ値を持つ全てのプライベートセクションのｔｐｔ＿ｂｙｔｅｓ（）がｓｅｃｔｉｏｎ＿ｎｕｍｂｅｒの順に連結されると、その結果として一つの完全なＴＰＴを作成できる。

以下、インターネットを介したＴＰＴの伝達について説明する。

インターネットで伝達される場合、ＴＰＴはＨＴＴＰを通じて伝達することができる。時間ベースメッセージで現在セグメントに対するＴＰＴのＵＲＬは“＜ｄｏｍａｉｎ ｎａｍｅ ｐａｒｔ＞／＜ｄｉｒｅｃｔｏｒｙ ｐａｔｈ＞”であってもよい。ＴＰＴに対する要求に対する応答は、単純にＴＰＴで構成されてもよく、要求されたＴＰＴは第１部分にあり、ＵＲＬリストは第２部分にあってＸＭＬ文書としてエンコードされる２−部分ＭＩＭＥメッセージとして構成されてもよい（要求に対する応答は常に現在セグメントに対するＴＰＴを含む。一つ以上の未来セグメントらに対するＴＰＴも含むことができる）。

図１７は、ＸＭＬ文書としてエンコードされたＵＲＬ目録の一実施例を示す図である。

上述した応答の第２部分としてのＵＲＬは、図１７のような形態であってもよい。

図１７のエレメントのセマンティックスについて説明する。

「ＵｒｌＬｉｓｔ」は、受信機に有用なＵＲＬリストを含むことができる。

「ＴｐｔＵｒｌ」は、未来セグメントに対するＴＰＴのＵＲＬを含むことができる。複数のＴｐｔＵｒｌエレメントが含まれる場合、それらは、放送でセグメントの登場順に配列することができる。

「ＮｒｔＳｉｇｎａｌｉｎｇＵｒｌ」は、受信機が現在の放送ストリームで全ての仮想チャネルに対するＮＲＴシグナリングテーブルを取得し得るサーバーのＵＲＬを含むことができる。

次に、ＴＤＯ及びコンテンツアイテムの移動について説明する。

ネットワークと基地局は、ＴＤＯ及びこれらのＴＤＯによって用いられるコンテンツアイテム（ファイル）の伝達のために、自体ＨＴＴＰサーバーを頻繁に提供しなければならない。提供がなされると、ＴＰＴ内のｂａｓｅＵＲＬはサーバーの位置を反映して調整されてもよい。

次に、複数のセグメントを一つのセグメントへの結合について説明する。

セグメント間の境界を徹底的に曖昧にさせるために、複数のセグメントに対するＴＰＴとＡＭＴを一つのＴＰＴ及びＡＭＴに結合することができる。その段階は、次の通りである。

１．結合されるセグメントの集合を識別する。

２．新しいｓｅｇｍｅｎｔＩｄを有する新しいＴＰＴを生成する。

３．結合されるセグメントの中でライブ活性化を有するものがあれば、それらの活性化の全てに対して接近権限を付与するリレーサーバーを提供し、このサーバーに対するパラメータを「ＬｉｖｅＴｒｉｇｇｅｒ」エレメントに入れる。

４．必要によって各セグメントに対してｂａｓｅＵＲＬを適用して全体ＴＤＯとＣｏｎｔｅｎｔＩｔｅｍ ＵＲＬを得る（結合される全てのセグメントに共通するより短いｂａｓｅＵＲＬを識別し、それを、結合されたセグメントに対するｂａｓｅＵＲＬとして維持する）。

５．必要によって値を修正して衝突を除去する。

６．結合される全てのセグメントに対する全ての修正されたＴＤＯエレメントを新しいＴＰＴに挿入する。

７．結合されたＴＰＴの新しいｓｅｇｍｅｎｔＩｄに相応するｓｅｇｍｅｎｔＩｄを有する新しいＡＭＴを生成する。

８．新しいＡＭＴに対して適切な新しい「ｂｅｇｉｎＭＴ」値を選択する。

９．ａｐｐＩｄ値における変更を反映して結合されるセグメントに対するＡＭＴファイル内の全てのＡｃｔｉｖａｔｉｏｎ要素のｔａｒｇｅｔＩｄ値を調整する。

１０．新しい「ｂｅｇｉｎＭＴ」値と結合されるセグメントに対する放送スケジュールを反映して結合されるセグメントに対するＡＭＴファイル内の全てのＡｃｔｉｖａｔｉｏｎエレメントのｓｔａｒｔＴｉｍｅとｅｎｄＴｉｍｅ値を調整する。

１１．修正された全てのＡｃｔｉｖａｔｉｏｎエレメントを新しいＡＭＴに挿入する。

以下、ＤＯを実行するための環境のための、ＡＴＳＣＪａｖａＳｃｒｉｐｔＡＰＩについて説明する。

放送プログラムに対する宣言的客体動作の同期化を支援するために、ビデオ／放送客体に対して追加の方法が支援されてもよい。

ＤＴＶＣＣ或いはインターネットでＴＰＴが受信されると、ＴＰＴ内にはＴＤＯを実行するための複数のイベントがあってもよく、これらのイベントは活性化トリガーによって活性化されてもよい。

このイベントを処理するようにするために、リスナー（Ｌｉｓｔｅｎｅｒ）という関数をｅｖｅｎｔＩＤ別に登録しておくことができる。これによって、上述の‘追加の方案’として、リスナー関数を登録できる次の２つの関数があり得る。

１．ａｄｄＴｒｉｇｇｅｒＥｖｅｎｔＬｉｓｔｅｎｅｒ

：ｅｖｅｎｔＩｄ別に、発生するイベントを処理するためのコールバック（ｃａｌｌｂａｃｋ）関数（リスナー関数）登録

２．ｒｅｍｏｖｅＴｒｉｇｇｅｒＥｖｅｎｔＬｉｓｔｅｎｅｒ

：ｅｖｅｎｔＩｄ別に、発生するイベントを処理するためのコールバック関数（リスナー関数）登録を取消

図１８は、ａｄｄＴｒｉｇｇｅｒＥｖｅｎｔＬｉｓｔｅｎｅｒの一実施例を示す図である。

図１８には、ａｄｄＴｒｉｇｇｅｒＥｖｅｎｔＬｉｓｔｅｎｅｒについての説明とフォーマット、アーギュメント（ａｒｇｕｍｅｎｔ）などが示されている。

ａｄｄＴｒｉｇｇｅｒＥｖｅｎｔＬｉｓｔｅｎｅｒ関数は、ナンバータイプのｅｖｅｎｔＩｄと、ＥｖｅｎｔＬｉｓｔｅｎｅｒタイプのｌｉｓｔｅｎｅｒをアーギュメントとして受けることができる。ＥｖｅｎｔＬｉｓｔｅｎｅｒタイプについては後述する。ａｄｄＴｒｉｇｇｅｒＥｖｅｎｔＬｉｓｔｅｎｅｒ関数はリターン値がなくてもよい（ｖｏｉｄ）。

ここで、ｅｖｅｎｔＩｄアーギュメントは、ＴＰＴのイベントエレメント中のｅｖｅｎｔＩｄであってもよい。ここで、ｌｉｓｔｅｎｅｒアーギュメントは、当該イベントのためのリスナーであってもよい。

受信機のトリガー処理モジュールでは活性化メッセージを受信すると直ちに「ａｄｄＴｒｉｇｇｅｒＥｖｅｎｔＬｉｓｔｅｎｅｒ」関数を用いてｅｖｅｎｔＩｄごとにリスナー関数を登録することができる。後で当該イベントに活性化が起きると、登録されたリスナー関数を呼び出すことができる。このとき、ＴｒｉｇｇｅｒＥｖｅｎｔタイプの客体をリスナー関数として伝達することができる。ＴｒｉｇｇｅｒＥｖｅｎｔタイプについては後述する。

図１９は、ｒｅｍｏｖｅＴｒｉｇｇｅｒＥｖｅｎｔＬｉｓｔｅｎｅｒの一実施例を示す図である。

図１９には、ｒｅｍｏｖｅＴｒｉｇｇｅｒＥｖｅｎｔＬｉｓｔｅｎｅｒに対する説明とフォーマット、アーギュメントなどが示されている。

ｒｅｍｏｖｅＴｒｉｇｇｅｒＥｖｅｎｔＬｉｓｔｅｎｅｒ関数は、ＮｕｍｂｅｒタイプのｅｖｅｎｔＩｄと、ＥｖｅｎｔＬｉｓｔｅｎｅｒタイプのｌｉｓｔｅｎｅｒをアーギュメントとして受けることができる。ＥｖｅｎｔＬｉｓｔｅｎｅｒタイプについては後述する。ｒｅｍｏｖｅＴｒｉｇｇｅｒＥｖｅｎｔＬｉｓｔｅｎｅｒ関数は、リターン値がなくてもよい（ｖｏｉｄ）。

ここで、ｅｖｅｎｔＩｄアーギュメントは、ＴＰＴのイベントエレメント中のｅｖｅｎｔＩＤであってもよい。ここで、ｌｉｓｔｅｎｅｒアーギュメントは、当該イベントのためのリスナーであってもよい。

ジャバスクリプトプログラムでは、当該ｅｖｅｎｔＩｄ別に発生し得るイベントをそれ以上受信しないことを希望したり、「ＤｅｓｔｒｏｙＷｉｎｄｏｗ」のようなプログラム終了時には、「ｒｅｍｏｖｅＴｒｉｇｇｅｒＥｖｅｎｔＬｉｓｔｅｎｅｒ」を用いて、登録されたリスナー関数を取り消すことができる。

図２０は、ＥｖｅｎｔＬｉｓｔｅｎｅｒタイプの定義の一実施例を示す図である。

ＥｖｅｎｔＬｉｓｔｅｎｅｒタイプは、ＴｒｉｇｇｅｒＥｖｅｎｔタイプを持つイベントをアーギュメントとすることができる。ＥｖｅｎｔＬｉｓｔｅｎｅｒはインターフェースであってもよい。

図２１は、ＴｒｉｇｇｅｒＥｖｅｎｔタイプの定義の一実施例を示す図である。

ＴｒｉｇｇｅｒＥｖｅｎｔタイプは、イベントに関する情報を含むことができる。

ＴｒｉｇｇｅｒＥｖｅｎｔタイプは、ｅｖｅｎｔＩｄ、ｄａｔａ、ｓｔａｔｕｓを属性として有することができる。ここで、ｅｖｅｎｔＩｄは、ＴＰＴのイベントエレメント中のｅｖｅｎｔＩｄであってもよい。ここで、ｄａｔａは、イベントの活性化のためのものであってもよい。ここで、ｄａｔａは、１６進法となっていてもよい。ここで、ｓｔａｔｕｓは、イベントの状態を意味することができる。ここで、ｓｔａｔｕｓ値が「ｔｒｉｇｇｅｒ」の場合は、イベントが活性化トリガーによって活性化された状態を意味できる。ここで、ｓｔａｔｕｓ値が「ｅｒｒｏｒ」の場合は、エラーが発生した状態を意味できる。

図２２は、ＴＤＯモデルにおける送信方法の一実施例を示す図である。

本発明に係る送信方法の一実施例は、アプリケーションパラメータテーブル生成（ｓｕ０１０）、活性化メッセージテーブル生成（ｓｕ０２０）、多重部分メッセージ生成（ｓｕ０３０）、多重部分メッセージ送信（ｓｕ０４０）を含むことができる。

アプリケーションパラメータテーブル生成（ｓｕ０１０）は、送信側で送信するアプリケーションパラメータテーブルを生成する段階である。ここで、アプリケーションパラメータテーブルは、アプリケーションのうち少なくとも一つに関する情報を含むことができる。ここで、アプリケーションパラメータテーブルは、第１識別子と第２識別子を含むことができる。ここで、第１識別子は、アプリケーションパラメータテーブルに関連する対話型プログラムセグメントを識別することができる。また、第２識別子は、アプリケーションパラメータテーブル範囲内のアプリケーションを識別することができる。

アプリケーションパラメータテーブルは、当該アプリケーションに関する情報を含んでいるテーブルであって、上述のＴＤＯパラメータテーブル（ＴＰＴ）をその例とすることができる。アプリケーションパラメータテーブルに関するバージョン情報、アプリケーションに関するバージョン情報、アプリケーションが適用されるセグメントの識別子、アプリケーションの識別子、イベントに対する識別子などの情報を含むことができる。

第１識別子は、アプリケーションパラメータテーブルに関連する対話型プログラムセグメントを識別することができる。第１識別子は、前述したＴＰＴ内部の＠ｉｄ属性であってもよい。

第２識別子は、アプリケーションパラメータテーブル範囲内のアプリケーションを識別することができる。第２識別子は、前述したＴＰＴ内部のチャイルドエレメントであるＴＤＯエレメントの＠ａｐｐＩＤ属性であってもよい。

受信端ではＴＰＴを受信してそれをパーシングすることができる。パーシングして上記の第１識別子と第２識別子を得ることができる。第１識別子を用いて、第１識別子の属するアプリケーションパラメータテーブルと関連し、そのアプリケーションパラメータテーブルに関連するアプリケーションとそれらのイベントが適用されるセグメントを探すことができる。その後、第２識別子を用いて、活性化メッセージが適用されるアプリケーションを探すことができる。受信端では、上記の識別子を用いて、活性化メッセージと活性化されるべきイベントとをマッチングさせることができる。

アプリケーションパラメータテーブル生成（ｓｕ０１０）段階で、本発明の一実施例は、アプリケーションパラメータテーブルが第５識別子をさらに含んでもよい。第５識別子は、アプリケーションにターゲットとなったイベントを識別することができる。第５識別子は、前述したＴＰＴのチャイルドエレメントであるＴＤＯエレメント内のイベントエレメントの属性である＠ｅｖｅｎｔＩＤに該当し得る。第５識別子は、ＡＭＦの第６識別子とマッチングされてもよい。第６識別子の動作と、第６識別子が第５識別子とマッチングされる動作については、活性化メッセージテーブル生成（ｓｕ０２０）段階で後述する。

アプリケーションパラメータテーブル生成（ｓｕ０１０）段階で、本発明の一実施例ではアプリケーションパラメータテーブルがバージョン情報をさらに含んでもよい。バージョン情報は、アプリケーションパラメータテーブルの定義のバージョン番号を示すことができる。バージョン情報は、前述したＴＰＴ内の属性である＠ｔｐｔＶｅｒｓｉｏｎに該当し得る。受信端ではＴＰＴ又はアプリケーションパラメータテーブルをパーシングして、このバージョン情報を得ることができる。

アプリケーションパラメータテーブル生成（ｓｕ０１０）段階で、本発明の一実施例は、アプリケーションパラメータテーブルが第７識別子をさらに含んでもよい。ここで、第７識別子は、第５識別子によって識別されたイベントのために用いられるデータを識別することができる。ここで、第５識別子は、上述した第５識別子と同一である。第７識別子は、前述したＴＰＴのチャイルドエレメントであるＴＤＯエレメント内のＥｖｅｎｔエレメント内部のＤａｔａエレメントの属性である＠ｄａｔａＩＤに該当し得る。第７識別子はＡＭＦの第８識別子とマッチングされてもよい。第８識別子の動作と、第８識別子が第７識別子とマッチングされる動作については、活性化メッセージテーブル生成（ｓｕ０２０）段階で後述する。

アプリケーションパラメータテーブル生成（ｓｕ０１０）段階で、本発明の一実施例は、アプリケーションがトリガーされた宣言的客体（ＴＤＯ）であってもよく、アプリケーションパラメータテーブルがＴＤＯパラメータテーブルであってもよい。ＴＤＯとＴＰＴは、上述したＴＤＯ、ＴＰＴと同一である。

活性化メッセージテーブル生成（ｓｕ０２０）は、送信側で送信する活性化メッセージテーブルを生成する段階である。ここで、活性化メッセージファイルは、アプリケーションの活性化時間の少なくとも一つを示すことができる。ここで、活性化時間は、活性化の時間を意味できる。ここで、活性化メッセージファイルは、第３識別子と活性化メッセージを含むことができる。ここで、第３識別子は、活性化メッセージファイル内の活性化メッセージが適用されるアプリケーションを含むアプリケーションパラメータテーブルの第１識別子とマッチングされてもよい。ここで、活性化メッセージは、第４識別子と開始時間情報を含むことができる。ここで、第４識別子は、活性化メッセージファイルが連携されたアプリケーションパラメータテーブル内のアプリケーションの第２識別子とマッチングされてもよい。また、ここで、開始時間情報は、当該セグメントの時間に相対的なアプリケーションにターゲットとなったイベントに対する期間の開始を示すことができる。

活性化メッセージファイルは、前述した活性化メッセージテーブル（ＡＭＴ）であってもよい。複数の活性化メッセージを含むことができるため、特定セグメントに関連する複数の活性化メッセージを一度に伝達することができる。活性化メッセージファイルは、バージョン情報、関連のセグメントの識別子、各活性化メッセージに関する情報を含むことができる。

活性化時間は、通常の活性化が起きる時間を意味できる。

第３識別子は、前述したＡＭＴにおいて、＠ｓｅｇｍｅｎｔＩｄに該当し得る。活性化メッセージファイルの識別子で関連のセグメントを識別することによって、活性化メッセージファイルとアプリケーションパラメータテーブルとをマッチングさせることができる。

活性化メッセージは、前述したＡＭＴにおいてチャイルドエレメントである活性化に該当し得る。したがって、活性化メッセージは、ターゲットとしたアプリケーションに対する識別子、ターゲットとしたイベントに対する識別子、活性化の開始時間などの情報を含むことができる。

第４識別子は、前述したＡＭＴのチャイルドエレメントである活性化の＠ｔａｒｇｅｔＴＤＯ属性であってもよい。したがって、活性化命令がターゲットとしているアプリケーションを識別することができる。

開始時間情報は、前述したＡＭＴのチャイルドエレメントである活性化の＠ｓｔａｒｔＴｉｍｅ属性であってもよい。したがって、イベントの実行開始時間に関する情報を含むことができる。

受信端では受信した活性化メッセージファイルをパーシングして、活性化メッセージ、第３識別子、第４識別子、開始時間情報などの情報を得ることができる。パーシングされた第３識別子は、アプリケーションパラメータテーブル内のパーシングされた第１識別子情報とマッチングされてもよい。第１識別子は、活性化メッセージファイル内の活性化メッセージが適用されるアプリケーションを含むアプリケーションパラメータテーブルの識別子であってもよい。そして、第３識別子は、活性化メッセージが適用されるセグメントに対する識別子であって、第１識別子とマッチングされて、アプリケーションパラメータテーブルとＡＭＦとを連結させることができる。

パーシングされた第４識別子は、ＴＰＴ内のパーシングされた第２識別子情報とマッチングされてもよい。第２識別子は、活性化メッセージファイルが連携されたアプリケーションパラメータテーブル内のアプリケーションの識別子であってもよい。そして、第４識別子は、活性化命令が適用されるアプリケーションの識別子であって、第２識別子とマッチングされて、ＡＭＦ内の活性化メッセージが適用されるＴＰＴ内のアプリケーションと連結させることができる。

パーシングされた開始時間情報は、属しているＡＭＦ内の活性化メッセージが活性化させようとするイベントの活性化開始時間を示すことができる。これは、セグメントの時間に相対的な時間情報であってもよい。パーシングされた＠ｓｅｇｍｅｎｔＩｄと＠ｔａｒｇｅｔＴＤＯ情報で指定されたアプリケーションに対して活性化メッセージが適用されるイベントの活性化開始時間を示すことができる。

活性化メッセージテーブル生成（ｓｕ０２０）段階において、本発明の一実施例は、活性化メッセージが第６識別子をさらに含んでもよい。第６識別子は、活性化命令が適用されるイベントを識別することができる。第６識別子は、前述したＡＭＴ内のチャイルドエレメントであるＡｃｔｉｖａｔｉｏｎ内の＠ｔａｒｇｅｔＥｖｅｎｔに該当し得る。第６識別子は、第４識別子によって識別されたアプリケーションの第５識別子とマッチングされてもよい。ここで、第４識別子は、前述した第４識別子と同一である。受信端では活性化メッセージファイルをパーシングして第６識別子を得ると、アプリケーションパラメータテーブルをパーシングして得た第５識別子とマッチングすることができる。このマッチングを通じて、当該活性化メッセージが活性化させようとするイベントを、アプリケーション内の対応するイベント情報と連結し、そのイベントを活性化可能にして、活性化メッセージが動作するようにすることができる。

活性化メッセージテーブル生成（ｓｕ０２０）段階において、本発明の一実施例は、活性化メッセージファイルが開始時間情報によって指定された時刻よりも遅く受信された場合、活性化が直ちに起きるようにすることができる。

活性化メッセージテーブル生成（ｓｕ０２０）段階において、本発明の一実施例は、活性化メッセージが第８識別子をさらに含んでもよい。ここで、第８識別子は、ターゲットとなったイベントに関連するデータを識別することができる。第８識別子は、上述したＡＭＴのチャイルドエレメントであるＡｃｔｉｖａｔｉｏｎの属性である＠ｔａｒｇｅｔＤａｔａに該当し得る。第８識別子は、第４識別子によって識別されたアプリケーションの第７識別子とマッチングされてもよい。ここで、第４識別子は、上述した第４識別子と同一である。受信端では、パーシングされたＡＭＴの第８識別子をパーシングされたアプリケーションパラメータテーブルの第７識別子情報とマッチングすることができる。これを通じてアプリケーションメッセージによってターゲットとなったイベントに関連するデータを識別して、アプリケーションパラメータテーブル内のデータ情報と連携させることができる。

活性化メッセージテーブル生成（ｓｕ０２０）段階において、本発明の一実施例は、活性化メッセージが終了時間情報を含むことができる。ここで、終了時間情報は、セグメント時間に相対的なイベント期間の終わりを示すことができる。終了時間情報が示す時刻が過ぎた後にはイベントの実行が停止されてもよい。すなわち、開始時間情報による開始時間と終了時間情報による終了時間との間にイベントを活性化させることができる。

活性化メッセージテーブル生成（ｓｕ０２０）段階において、本発明の一実施例は、セグメントの時間がセグメントのメディア時間であってもよい。ここで、セグメントのメディア時間は、コンテンツアイテムの再生地点を参照するパラメータであってもよい。

[多重部分メッセージ生成（ｓｕ０３０）は、アプリケーションパラメータテーブルを多重部分メッセージの第１部分とし、活性化メッセージファイルを多重部分メッセージの第２部分とする多重部分メッセージを生成する段階である。ここで、アプリケーションパラメータテーブル及び活性化メッセージファイルは、上述したアプリケーションパラメータテーブル及び活性化メッセージファイルと同一である。

活性化トリガー一括伝達で説明したように、活性化トリガーが大量にインターネットで伝達される場合には、多重部分ＭＩＭＥメッセージ形態で伝達されてもよい。多重部分メッセージ生成（ｓｕ０３０）段階では、アプリケーションパラメータテーブルと活性化メッセージファイルの送信に先立ち、アプリケーションパラメータテーブルと活性化メッセージファイルをそれぞれ第１部分と第２部分とする多重部分メッセージを生成することができる。

受信端では、この多重部分メッセージを受けてパーシングし、アプリケーションパラメータテーブルと活性化メッセージファイルに関する情報を得ることができる。受信端の動作については後述する。

多重部分メッセージ送信（ｓｕ０４０）は、ＨＴＴＰを通じて多重部分メッセージを受信機に送信する段階である。

活性化トリガー一括伝達で説明したように、活性化トリガーが大量にインターネットで伝達される場合には、セグメントに対する活性化トリガーがＨＴＴＰを通じて伝達されてもよい。受信端では、この多重部分メッセージを受信する。受信端の動作については後述する。

図２３は、本発明において、受信機の構造の一実施例を示す図である。

図２３に示す本発明の実施例において、受信機は、アンテナ２３０１０、チューナー２３０２０、ＶＳＢ又はＤＶＢ復調器２３０３０、ＭＰＥＧ−２ＴＳシステムデコーダ２３０４０、キャプションモジュール２３０５０、トリガーモジュール２３０６０、ウェブブラウザ２３０７０、ネットワークプロトコルスタック２３０８０、ネットワークインターフェース２３０９０、ＵＩモジュール２３１００、オーディオデコーダ２３１１０、ビデオデコーダ２３１２０、スピーカ２３１３０、ディスプレイモジュール２３１４０、グラフィックプロセッサ２３１５０、リモコン受信器２３１６０及び／又はリモコン２３１７０を含むことができる。

アンテナ２３０１０は、放送ストリームによる放送信号を受信することができる。ここで、アンテナ２３０１０は、通常の技術の分野で用いられるアンテナであってもよい。

チューナー２３０２０は、受信機での選局や同調操作を行うことができる。高周波増幅、局部発振、周波数変換及び入力回路、選局機構などを含むことができる。ここで、チューナー２３０２０は、通常の技術の分野において用いられるチューナーであってもよい。

ＶＳＢ又はＤＶＢ復調器２３０３０は、ＶＳＢ信号又はＤＶＢ信号を復調することができる。ＶＳＢ又はＤＶＢ復調器２３０３０は、変調されたＶＳＢ又はＤＶＢ（例えば、ＯＦＤＭ変調された信号）を元の信号に復元することができる。ここでＶＳＢ又はＤＶＢ復調器２３０３０の復調過程は、通常の技術の分野において用いられる復調過程であってもよい。

ＭＰＥＧ−２ＴＳシステムデコーダ２３０４０は、復調された信号のトランスポートストリーム（Ｔｒａｎｓｐｏｒｔ Ｓｔｒｅａｍ；ＴＳ）をデコードする。ＭＰＥＧ−２ＴＳシステムデコーダ２３０４０は、トランスポートストリームからキャプションストリームを取得してキャプションモジュール２３０５０に伝達することができる。ＭＰＥＧ−２ＴＳシステムデコーダ２３０４０は、デコードされたオーディオ信号、ビデオ信号をオーディオデコーダ２３１１０、ビデオデコーダ２３１２０に送ることができる。

キャプションモジュール２３０５０は、キャプションストリームを受けることができる。キャプションモジュール２３０５０は、サービス＃６或いはその他のサービスを監視するが、サービス＃６或いはトリガーが送信されるサービスを選別してトリガーモジュール２３０６０に送るか或いはキャプションテキストを処理して画面に表示するかを判断することができる。トリガーデータの場合、トリガーモジュール２３０６０に伝達することができる。他のキャプションサービスなどの場合には、キャプションテキスト処理してグラフィックプロセッサ２３１５０に伝達することができる。

トリガーモジュール２３０６０は、トリガー、ＴＰＴ、及び／又はＡＭＴ情報などをパーシングし、パーシングされたデータを処理することができる。トリガーモジュール２３０６０は、トリガー内のＵＲＩ情報値を用いて、ネットワークプロトコルスタック２３０８０を介してネットワークに接近することができる。ここで、ＵＲＩ情報値は、ＨＴＴＰサーバーのアドレスであってもよい。トリガーモジュール２３０６０は、ＴＰＴファイル内容を分析してＴＤＯ ＵＲＬを得ることができる。また、ＡＭＴをパーシングしてデータを処理することができる。その他の情報もパーシングして得ることができる。ＡＭＴメッセージを受信した後には、定められた時間と動作に従ってウェブブラウザに該当するＴＤＯ ＵＲＬを伝達したり、或いは定められた時間に現在動作するＴＤＯを中断させたりすることができる。これは、ＴＤＯ ａｃｔｉｏｎに該当する動作であり、トリガーモジュール２３０６０がウェブブラウザに命令を下して動作できるようにすることができる。本発明に関するトリガーモジュール２３０６０の動作についての詳細な事項は後述する。

ウェブブラウザ２３０７０は、トリガーモジュール２３０６０が下した命令、ＵＩモジュール２３１００に伝達されたブラウザキーコード、リモコン受信器２３１６０が伝達したブラウザキーコードなどの伝達を受けてネットワークプロトコルスタック２３０８０と通信することができる。

ネットワークプロトコルスタック２３０８０は、トリガーモジュール２３０６０及びウェブブラウザと通信し、ネットワークインターフェース２３０９０を介してサーバーに接続することができる。

ネットワークインターフェース２３０９０は、他の複数の装置の共通接続や、網コンピュータと外部網の接続を行うことができる。サーバーに接続してＴＤＯ、ＴＰＴ、ＡＭＴなどをダウンロードすることができる。ここで、ネットワークインターフェース２３０９０の動作は、通常の技術の分野において用いられるネットワークインターフェース２３０９０の動作であってもよい。本発明に関するネットワークインターフェース２３０９０の動作についての詳細な事項は後述する。

ＵＩモジュール２３１００は、リモコン２３１７０を用いて視聴者が入力した情報をリモコン受信器２３１６０を介して受信することができる。受信した情報がｎｅｔｗｏｒｋを用いるサービスなどに関連するものであれば、ブラウザキーコードをウェブブラウザに伝達することができる。伝達された情報が現在表示される単純ｖｉｄｅｏに関するものであれば、グラフィックプロセッサ２３１５０を介してディスプレイモジュール２３１４０に信号を伝達することができる。

オーディオデコーダ２３１１０は、ＭＰＥＧ−２ＴＳシステムデコーダ２３０４０から伝達されたオーディオ信号をデコードすることができる。その後、デコードしたオーディオ信号をスピーカに送り、視聴者への出力を可能にする。ここで、オーディオデコーダ２３１１０は、通常の技術の分野において用いられるオーディオデコーダであってもよい。

ビデオデコーダ２３１２０は、ＭＰＥＧ−２ＴＳシステムデコーダ２３０４０から伝されたビデオ信号をデコードすることができる。その後、デコードしたビデオ信号をディスプレイモジュール２３１４０に送り、視聴者への出力を可能にする。ここで、ビデオデコーダ２３１２０は、通常の技術の分野において用いられるビデオデコーダであってもよい。

スピーカ２３１３０は、オーディオ信号を視聴者に出力することができる。ここで、スピーカは、通常の技術の分野において用いられるスピーカであってもよい。

ディスプレイモジュール２３１４０は、ビデオ信号を視聴者に出力することができる。ここで、ディスプレイモジュール２３１４０は、通常の技術の分野において用いられるディスプレイ装置であってもよい。本発明に関するディスプレイモジュール２３１４０の動作についての詳細な事項は後述する。

グラフィックプロセッサ２３１５０は、キャプションモジュール２３０５０から伝達されたｃａｐｔｉｏｎ ｔｅｘｔと、ＵＩモジュール２３１００から受信した視聴者の入力情報をグラフィック化する処理を行うことができる。処理した情報はディスプレイモジュール２３１４０に伝達することができる。ここで、グラフィックプロセッサ２３１５０は、通常の技術の分野において用いられるグラフィックプロセッサであってもよい。

リモコン受信器２３１６０は、リモコン２３１７０から入力される情報を受けることができる。このとき、キーコードはＵＩモジュール２３１００に伝達し、ブラウザキーコードはウェブブラウザに伝達することができる。

リモコン２３１７０は、視聴者が入力した信号をリモコン受信器２３１６０に伝達する。リモコン２３１７０は、視聴者が仮想チャネルを切り替えようとする入力などを受けることができる。また、アプリケーションに対して視聴者が選択した情報などを受けることもできる。リモコン２３１７０は、入力された情報をリモコン受信器２３１６０に伝達することができる。このとき、赤外線（ＩＲ）を用いて、当該情報を一定距離以上離れて遠隔で伝達することができる。

図２４は、放送をセットトップボックスでＨＤＭＩ或いは外部入力を介して受信する場合の受信機構造の一実施例を示す図である。

図２４に示す本発明の実施例において、受信機は、アンテナ２４０１０、チューナー２４０２０、セットトップボックス２４０３０、ＶＳＢ又はＤＶＢ復調器２４０４０、ＨＤＭＩ ２４０５０、ＭＰＥＧ−２ＴＳシステムデコーダ２４０６０、キャプションモジュール２４０７０、トリガーモジュール２４０８０、ウェブブラウザ２４０９０、ネットワークプロトコルスタック２４１００、ネットワークインターフェース２４１１０、ＵＩモジュール２４１２０、ＡＣＲモジュール２４１３０、オーディオデコーダ２４１４０、ビデオデコーダ２４１５０、スピーカ２４１６０、ディスプレイモジュール２４１７０、グラフィックプロセッサ２４１８０、リモコン受信器２４１９０、リモコン２４２００を含むことができる。

この場合には、一応、放送ストリームのビデオとオーディオが原始データ（Ｒａｗ Ｄａｔａ）であるため、キャプションストリームに含まれているトリガーを受信できないはずである。本発明に関する詳細な事項は後述する。

ここで、セットトップボックス２４０３０、ＨＤＭＩ ２４０５０、ＡＣＲモジュール２４１３０を除く残りのモジュールは、図２３の実施例で説明したモジュールと同様の役割を担う。

セットトップボックス２４０３０、ＨＤＭＩ ２４０５０、ＡＣＲモジュール２４１３０に関する説明は、次の通りである。

セットトップボックス２４０３０は、デジタル網を介してビデオサーバーから送信された圧縮信号を元の映像及び音声信号に復元することができる。ＴＶをインターネットユーザインターフェースにさせることができる。

ＨＤＭＩ ２４０５０は、非圧縮方式のデジタルビデオ／オーディオインターフェース規格の一つである高画質マルチメディアインターフェースであってもよい。ＨＤＭＩ ２４０５０は、セットトップボックス２４０３０とＡＶ機器、すなわち、オーディオデコーダ２４１４０、ビデオデコーダ２４１５０との間にインターフェースを提供することができる。

ＡＣＲモジュール２４１３０は、オーディオデコーダ２４１４０とビデオデコーダ２４１５０から自動で放映中のコンテンツを認識することができる。認識された現在のコンテンツに基づいてトリガーモジュール２４０８０とネットワークインターフェース２４１１０を介してＡＣＲサーバーに質疑（Ｑｕｅｒｙ）を送って、トリガーのためのＴＰＴ／ＡＭＴを受信することができる。

図２５は、ＴＤＯモデルにおける受信装置の一実施例を示す図である。

図２５に示す本発明の実施例において、受信機は、ネットワークインターフェースｖ０１０、トリガーモジュールｖ０２０、ディスプレイモジュールｖ０３０を含むことができる。

ネットワークインターフェースｖ０１０は、上述したネットワークインターフェースと同様の動作を行うことができる。ネットワークインターフェースｖ０１０は、多重部分メッセージをＨＴＴＰを通じて受けることができる。ここで、多重部分メッセージは、多重部分メッセージの第１部分であるアプリケーションパラメータテーブルと、多重部分メッセージの第２部分である活性化メッセージファイルとから構成されてもよい。

多重部分メッセージ、アプリケーションパラメータテーブル、活性化メッセージファイルは、上述したそれらと同一であってもよい。

トリガーモジュールｖ０２０は、上述したトリガーモジュールと同様の動作を行うことができる。トリガーモジュールｖ０２０は、多重部分メッセージをパーシングしてアプリケーションパラメータテーブルと活性化メッセージファイルを得ることができる。トリガーモジュールｖ０２０は、アプリケーションのうち少なくとも一つに関する情報を含むアプリケーションパラメータテーブルをパーシングして、第１識別子、第２識別子及びＵＲＬ情報を得ることができる。そして、トリガーモジュールｖ０２０は、アプリケーションの活性化時間のうち少なくとも一つを示す活性化メッセージファイルをパーシングして、第３識別子と活性化メッセージを得ることができる。そして、トリガーモジュールｖ０２０は、活性化メッセージをパーシングして、第４識別子と開始時間情報を得ることができる。

ここで、第１識別子は、アプリケーションパラメータテーブルに関連する対話型プログラムセグメントを識別することができる。ここで、第２識別子は、アプリケーションパラメータテーブル範囲内のアプリケーションを識別することができる。ここで、ＵＲＬ情報は、アプリケーションを伝達し得るサーバーのＵＲＬを示すことができる。ここで、ＵＲＬ情報は、アプリケーションの一部であるファイルを識別することができる。ここで、ネットワークインターフェースは、ＵＲＬ情報を用いてアプリケーションをダウンロードすることができる。ここで、活性化時間は、活性化の時間を意味できる。ここで、第３識別子は、活性化メッセージファイル内の活性化メッセージが適用されるアプリケーションを得ることができるアプリケーションパラメータテーブルの第１識別子とマッチングされてもよい。ここで、第４識別子は、活性化メッセージファイルが連携されたアプリケーションパラメータテーブル内のアプリケーションの第２識別子とマッチングされてもよい。ここで、開始時間情報は、セグメント時間に相対的なアプリケーションにターゲットとなったイベントの期間の開始を示すことができる。

ＵＲＬ情報は、アプリケーションを伝達し得るサーバーのＵＲＬを示すことができる。ＵＲＬ情報は、図５でＴＰＴのチャイルドエレメントであるＴＤＯエレメント内にあるＵＲＬエレメントに該当し得る。ＵＲＬ情報は、アプリケーションの一部であるファイルを識別することができる。ネットワークインターフェースはＵＲＬ情報を用いてアプリケーションをダウンロードすることができる。

多重部分メッセージ、アプリケーションパラメータテーブル、活性化メッセージファイル、第１識別子、第２識別子、第３識別子、活性化メッセージ、第４識別子、開始時間情報の意味と相互間の動作は、前述した送信端で説明した内容と同一であってもよい。

本発明の一実施例は、アプリケーションパラメータテーブルが第５識別子をさらに含んでもよい。この実施例では活性化メッセージが第６識別子をさらに含んでもよい。第５識別子と第６識別子の意味及び相互間の動作は、送信端で説明した内容と同一であってもよい。

本発明の一実施例は、活性化メッセージファイルが開始時間情報によって指定された時刻よりも遅く受信された場合、活性化が直ちに起きるようにすることができる。

本発明の一実施例は、アプリケーションパラメータテーブルがバージョン情報をさらに含んでもよい。バージョン情報の意味及び相互間の動作は、送信端で説明した内容と同一であってもよい。

本発明の一実施例は、アプリケーションパラメータテーブルが第７識別子をさらに含んでもよい。この実施例では活性化メッセージが第８識別子をさらに含んでもよい。第７識別子と第８識別子の意味及び相互間の動作はも送信端で説明した内容と同一であってもよい。

本発明の一実施例は、活性化メッセージが終了時間情報を含むことができる。終了時間情報の意味及び相互間の動作は、送信端で説明した内容と同一であってもよい。

本発明の一実施例は、アプリケーションが、ターゲットとなった宣言的客体（ＴＤＯ）であってもよく、アプリケーションパラメータテーブルがＴＤＯパラメータテーブルであってもよい。ＴＤＯとＴＰＴは、上述したＴＤＯ、ＴＰＴと同一である。

本発明の一実施例は、セグメントの時間がセグメントのメディア時間であってもよい。ここで、セグメントのメディア時間は、コンテンツアイテム再生のある地点を参照するパラメータであってもよい。

ディスプレイモジュールｖ０３０は、上述したディスプレイモジュールと同様の動作を行うことができる。ディスプレイモジュールｖ０３０は、アプリケーションを表示することができる。

以下、直接実行モデルについて説明する。

直接実行モデルにおいて、仮想チャネルが選択されると直ちに宣言的客体（Ｄｅｃｌａｒａｔｉｖｅ Ｏｂｊｅｃｔ；ＤＯ）が自動で開始され得る。宣言的客体は、スクリーン上の特定位置での画面の生成、世論調査実行、他の特殊ＤＯの開始などのようにオーディオ−ビデオプログラムと同期化される対話型特徴の提供のための具体的な指示事項を得るために、インターネットを介してバックエンド（ｂａｃｋｅｎｄ）サーバーと通信することができる。

次に、直接実行モデルにおけるトリガー動作について説明する。

トリガーの役割、機能、シンタックスは、直接実行モデルだからといって大きく変わらない。

トリガーの性能については、前述した通りである。

トリガーシンタックスについては、前述した通りである。

トリガーは３つの部分で構成されたことがわかる。

<domain name part>/<directory path>[?<parameters>]

直接実行モデルにおいて、＜ｄｏｍａｉｎ ｎａｍｅ ｐａｒｔ＞と＜ｄｉｒｅｃｔｏｒｙ ｐａｔｈ＞の組合せによって、開始されるＤＯを固有に識別することができる。

＜ｐａｒａｍｅｔｅｒｓ＞は、「ｅｖｅｎｔ＿ｔｉｍｅ」、「ｍｅｄｉａ＿ｔｉｍｅ」、又は「ｓｐｒｅａｄ」の一つ以上で構成することができる。

直接実行モデルにおいて、仮想チャネルが選択されると直ちにアプリケーションが自動で開始され得る。アプリケーションは「Ｓｙｎｃｈｒｏｎｉｚｅｄ Ｃｏｎｔｅｎｔ Ｐｒｏｔｏｃｏｌ」を通じてインターネットでバックエンドサーバーと通信することができる。このサーバーは、オーディオ−ビデオプログラムと全て同期化された対話型特徴の提供のための指示事項を提供することができる。

直接実行モデルの場合、直ちにアプリケーションが実行されるため、時間ベーストリガーが伝達され次第、現在実行中のアプリケーションに情報を伝達することができる。このモデルにおいて、アプリケーションはサーバーに、前述した同期化のために、現在放映中のコンテンツに関する情報を伝達し続ける必要がある。この必要に応じるために、時間ベーストリガーには、ＴＤＯモデルとは異なる特別な情報がさらに含まれてもよい。この特別な情報は、現在放映中のコンテンツに対する識別子であってもよい。

同様に、上記のコンテンツ識別子は、トリガーのパラメータ部分にパラメータの形態で存在することができる。

同様に、上記のコンテンツ識別子は、トリガーのｍｅｄｉａ＿ｔｉｍｅに一つの項の形態で存在してもよい。コンテンツ識別子項は、次に文字列が続く「ｃ＝」によって指定できるｃｏｎｔｅｎｔ＿ｉｄと呼ばれ、現在視聴されているコンテンツに対する識別子を示すことができる。

ｃｏｎｔｅｎｔ＿ｉｄ項は、対話型サービス実行の直接実行モデルを支援するためのものであってもよい。

上述した通り、このモデルにおいて、ｃｏｎｔｅｎｔ＿ｉｄ項を有する時間ベーストリガーは、アプリケーションの開始後にこのアプリケーションに伝達され、このアプリケーションは相互作用のためのコンテクスト（ｃｏｎｔｅｘｔ）の識別のためにｃｏｎｔｅｎｔ＿ｉｄをバックエンドサーバーに伝達することができる。その詳細な動作については後述する。

直接実行モデルにおけるトリガーの伝達メカニズムは、前述した通りである。

ただし、放送ストリームによるトリガーの伝達の場合において、トリガーはＵＲＬＳｔｒｉｎｇ命令内でサービス＃６を通じてＤＴＶクローズドキャプションチャネルに伝達されてもよい。そして、直接実行モデルを用いる対話型サービスは、ＵＲＩ＿ｔｙｐｅフィールドが２（直接実行モデルのための対話型ＴＶトリガー）に設定されてもよい。

以下、直接実行モデルの全体動作について説明する。

対話型サービスを実行する一つのモデルとして、直接実行モデルでは、仮想チャネルが選択されると直ちにアプリケーションが自動で開始され得る。アプリケーションは、「Ｓｙｎｃｈｒｏｎｉｚｅｄ Ｃｏｎｔｅｎｔ Ｐｒｏｔｏｃｏｌ」を通じてインターネットでバックエンドサーバーと通信することができる。このサーバーは、スクリーン上の特定位置での画面の生成、世論調査の実行、他の特殊ＤＯの開始などのように、オーディオ−ビデオプログラムと同期化される対話型特徴の提供のための具体的な指示事項を提供することができる。

上記の動作は同様に、次の通りである。

まず、アプリケーションが開始され得る。その後、時間ベーストリガーを受信する。時間ベーストリガーは、アプリケーションが実行された後にアプリケーションに伝達される。時間ベーストリガーのｃｏｎｔｅｎｔ＿ｉｄ項には、現在現れているコンテンツに関するコンテンツ識別情報が含まれている。アプリケーションは、相互作用のためのコンテクストを識別し、現在視聴中のコンテンツを識別するためにｃｏｎｔｅｎｔ＿ｉｄをバックエンドサーバーに伝達することができる。

図２６は、直接実行モデルにおける送信方法の一実施例を示す図である。

本発明に係る直接実行モデルにおける送信方法の一実施例は、トリガー生成（ｓｗ０１０）、放送信号生成（ｓｗ０２０）、放送信号伝達（ｓｗ０３０）を含むことができる。

トリガー生成（ｓｗ０１０）は、送信するトリガーを作成する段階である。ここで、トリガーは、第１識別子とパラメータを含むことができる。ここで、第１識別子は、開始されるアプリケーションを識別することができる。ここで、パラメータは、メディア時間スタンプとコンテンツ識別子を含むことができる。ここで、メディア時間スタンプは、コンテンツの再生において現在地点を示すことができる。ここで、コンテンツ識別子は、現在現れているコンテンツを識別することができる。ここで、トリガーは、アプリケーションが開始された後にアプリケーションに伝達され得る。ここで、アプリケーションは、現在視聴中のコンテンツを識別するために、コンテンツ識別子をサーバーに伝達することができる。

ここで、第１識別子は、前述したトリガーシンタックスにおいてｌｏｃａｔｏｒ＿ｐａｒｔに該当し得る。ｌｏｃａｔｏｒ＿ｐａｒｔは、＜ｄｏｍａｉｎ ｎａｍｅ ｐａｒｔ＞と＜ｄｉｒｅｃｔｏｒｙ ｐａｔｈ＞の部分からなっていてもよい。＜ｄｏｍａｉｎ ｎａｍｅ ｐａｒｔ＞と＜ｄｉｒｅｃｔｏｒｙ ｐａｔｈ＞の組合せによって、開始されるアプリケーションを固有に識別することができる。

パラメータは、前述したトリガーシンタックスにおいて＜ｐａｒａｍｅｔｅｒ＞部分に該当し得る。＜ｐａｒａｍｅｔｅｒｓ＞は、「ｅｖｅｎｔ＿ｔｉｍｅ」、「ｍｅｄｉａ＿ｔｉｍｅ」、又は「ｓｐｒｅａｄ」の一つ以上で構成されてもよい。

メディア時間スタンプは、＜ｐａｒａｍｅｔｅｒｓ＞のうち、前述した「ｍｅｄｉａ＿ｔｉｍｅ」に該当し得る。

コンテンツ識別子は、＜ｐａｒａｍｅｔｅｒｓ＞のうち、前述した「ｍｅｄｉａ＿ｔｉｍｅ」内のｃｏｎｔｅｎｔ＿ｉｄ項に該当し得る。

サーバーは、前述したバックエンドサーバーであってもよい。

受信端では、当該トリガーを受けてパーシングし、第１識別子、パラメータ、メディア時間スタンプ、コンテンツ識別子情報を得ることができる。第１識別子情報を用いて、実行されるアプリケーションを識別することができる。受信したトリガーは実行中のアプリケーションに伝達することができる。アプリケーションはパラメータ内のメディア時間スタンプ内のコンテンツ識別子情報をサーバーに伝達し、サーバーが、現在現れているコンテンツに関する情報を識別し得るようにすることができる。その後、サーバーは、対話型特徴の提供のための具体的な指示事項を提供することができる。

トリガー生成（ｓｗ０１０）段階において、本発明の一実施例は、次の通りである。第１識別子は、第１部分と第２部分からなり得る。ここで、第１部分は、前述した＜ｄｏｍａｉｎ ｎａｍｅ ｐａｒｔ＞であってもよい。ここで、第２部分は、前述した＜ｄｉｒｅｃｔｏｒｙ ｐａｔｈ＞であってもよい。＜ｄｏｍａｉｎ ｎａｍｅ ｐａｒｔ＞と＜ｄｉｒｅｃｔｏｒｙ ｐａｔｈ＞については前述したように、第１部分は、登録されたインターネットドメイン名を参照でき、第２部分は、識別されたドメイン名に対する権限を持つエンティティ（ｅｎｔｉｔｙ）の制御及び管理下でディレクトリ経路を識別することができる。

トリガー生成（ｓｗ０１０）段階で、本発明の一実施例においてトリガーは最大５２バイトの長さを有することができる。

トリガー生成（ｓｗ０１０）段階で、本発明の一実施例は次の通りである。アプリケーションがあらかじめ設置されていないか又は既にキャッシュに保存されている場合、アプリケーションがダウンロードされ、アプリケーションは第１識別子によって識別される。受信端では、第１識別子によって識別されるアプリケーションが存在しない場合に、それをダウンロードすることができる。

トリガー生成（ｓｗ０１０）段階で、本発明の一実施例において「ｔｈｅ ｃｕｒｒｅｎｔ ｐｏｉｎｔ ｉｎ ｔｈｅ ｐｌａｙｏｕｔ ｏｆ ｔｈｅ ｃｏｎｔｅｎｔ」は、セグメントのメディア時間を意味することができる。

トリガー生成（ｓｗ０１０）段階で、本発明の一実施例は、アプリケーションが宣言的客体、トリガーされた宣言的客体、非実時間宣言的客体、非結合宣言的客体のいずれか一つであってもよい。

放送信号生成（ｓｗ０２０）は、先に生成したトリガーを含む放送信号を作成する段階であってもよい。放送信号を生成する過程は、当該技術の分野において一般に用いられる方法であってもよい。

放送信号生成（ｓｗ０２０）段階で、本発明の一実施例は、放送信号を生成する過程において、トリガーを放送信号のＤＴＶクローズドキャプションチャネルに挿入することができる。

放送信号送信（ｓｗ０３０）は、生成された放送信号を送信する段階であってもよい。

直接実行モデルの場合にも、図２３、図２４で説明した受信機の構造を適用することができる。

図２７は、直接実行モデルにおける受信装置の一実施例を示す図である。

本発明に係る直接実行モデルにおける受信装置の一実施例は、チューナーｘ０１０、トリガーモジュールｘ０２０、ネットワークインターフェースｘ０３０、ディスプレイモジュールｘ０４０を含むことができる。

チューナーｘ０１０は、図２３で説明したチューナーと同様の動作を行うことができる。チューナーｘ０１０は、ｃｏｎｔｅｎｔ＿ｉｄ情報を有するトリガーを含む放送信号を受けることができる。ここで、ｃｏｎｔｅｎｔ＿ｉｄは、上述した現在放映中のコンテンツの識別子であってもよい。

トリガーモジュールｘ０２０は、図２３で説明したトリガーモジュールと同様の動作を行うことができる。トリガーモジュールｘ０２０は、放送信号をパーシングしてトリガーを得ることができる。そして、トリガーモジュールｘ０２０は、トリガーをパーシングして第１識別子とパラメータを得ることができる。トリガーモジュールｘ０２０は、第１識別子によって識別されたアプリケーションを開始することができる。そして、トリガーモジュールｘ０２０は、パラメータをパーシングして、メディア時間スタンプとコンテンツ識別子を得ることができる。

ここで、第１識別子は、開始されるアプリケーションを識別することができる。ここで、トリガーは、アプリケーションが開始された後にアプリケーションに伝達され得る。ここで、メディア時間スタンプは、コンテンツの再生において現在地点を示すことができる。ここで、コンテンツ識別子は、現在現れているコンテンツを識別することができる。

トリガー、第１識別子、パラメータ、メディア時間スタンプ、コンテンツ識別子の意味及び相互間の動作は、直接実行モデルにおける放送信号の送信過程で説明した内容と同一であってもよい。

本発明の一実施例は、次の通りである。第１識別子は、第１部分と第２部分からなり得る。ここで、第１部分は、前述した＜ｄｏｍａｉｎ ｎａｍｅ ｐａｒｔ＞であってもよい。ここで、第２部分は、前述した＜ｄｉｒｅｃｔｏｒｙ ｐａｔｈ＞であってもよい。＜ｄｏｍａｉｎ ｎａｍｅ ｐａｒｔ＞と＜ｄｉｒｅｃｔｏｒｙ ｐａｔｈ＞については前述したように、第１部分は、登録されたインターネットドメイン名を参照でき、第２部分は、識別されたドメイン名に対する権限を持つエンティティの制御及び管理下でディレクトリ経路を識別することができる。

本発明の一実施例において、トリガーは最大５２バイトの長さを有することができる。

本発明の一実施例において、「ｔｈｅ ｃｕｒｒｅｎｔ ｐｏｉｎｔ ｉｎ ｔｈｅ ｐｌａｙｏｕｔ ｏｆ ｔｈｅ ｃｏｎｔｅｎｔ」は、セグメントのメディア時間を意味できる。

本発明の一実施例は、アプリケーションが宣言的客体、トリガーされた宣言的客体、非実時間宣言的客体、非結合宣言的客体のいずれか一つであってもよい。

本発明の一実施例は、トリガーが放送信号内のＤＴＶクローズドキャプションチャネルに挿入されていてもよい。

ネットワークインターフェースｘ０３０はサーバーと通信することができる。ここで、アプリケーションは、現在現れているコンテンツを識別するために、ネットワークインターフェースを用いてコンテンツ識別子をサーバーに伝達することができる。

本発明の一実施例は、次の通りである。アプリケーションがあらかじめ設置されていないか、又は既にキャッシュに保存されている場合、アプリケーションがダウンロードされ、アプリケーションは第１識別子によって識別される。受信端では、第１識別子によって識別されるアプリケーションが存在しない場合に、これをネットワークインターフェースｘ０３０を介してダウンロードすることができる。

ディスプレイモジュールｘ０４０はアプリケーションを表示することができる。

様々な実施例が、発明を実施するための形態において上述されている。

本発明は、放送サービスの提供に関する一連の産業分野に利用可能である。

本発明の思想や範囲から逸脱することなく、本発明の様々な修正及び変形が可能であるということが、当該技術の分野における者には明らかである。したがって、添付の請求項及びその等価物の範囲内で提供される本発明の修正及び変形はいずれも本発明に含まれる。

Claims (16)

1. 対話型サービス（ｉｎｔｅｒａｃｔｉｖｅ ｓｅｒｖｉｃｅ）を処理する方法において、
   アプリケーションのうち少なくとも一つに関する情報を含むアプリケーションパラメータテーブルを生成するステップであって、
   前記アプリケーションパラメータテーブルは、第１識別子と第２識別子を含み、
   前記第１識別子は、前記アプリケーションパラメータテーブルに関連する対話型プログラムセグメント（ｉｎｔｅｒａｃｔｉｖｅ ｐｒｏｇｒａｍｍｉｎｇ ｓｅｇｍｅｎｔ）を識別し、
   前記第２識別子は、アプリケーションパラメータテーブルの範囲内のアプリケーションを識別する、ステップと、
   前記アプリケーションの活性化時間のうち少なくとも一つを示す活性化メッセージテーブルを生成するステップであって、
   前記活性化時間は、活性化の時間を意味し、
   前記活性化メッセージテーブルは、第３識別子と活性化メッセージを含み、
   第３識別子は、前記活性化メッセージテーブル内の活性化メッセージが適用される前記アプリケーションを含むアプリケーションパラメータテーブルの前記第１識別子とマッチングされ、
   前記活性化メッセージは、第４識別子と開始時間情報を含み、
   前記第４識別子は、前記活性化メッセージテーブルが連携された前記アプリケーションパラメータテーブル内のアプリケーションの前記第２識別子とマッチングされ、
   前記開始時間情報は、前記セグメントの時間を基準に前記アプリケーションにターゲットとなったイベントのための時間期間の開始を示す、ステップと、
   前記アプリケーションパラメータテーブルを第１部分とし、前記活性化メッセージテーブルを第２部分とする多重部分メッセージ（ｍｕｌｔｉ−ｐａｒｔ ｍｅｓｓａｇｅ）を生成するステップと、
   ＨＴＴＰを通じて前記多重部分メッセージを受信機に送信するステップと、
   を含む、対話型サービス処理方法。
2. 前記アプリケーションパラメータテーブルは、第５識別子をさらに含み、前記第５識別子は、前記イベントを識別し、前記活性化メッセージは、第６識別子をさらに含み、前記第６識別子は、前記第４識別子によって識別されるアプリケーションの前記第５識別子とマッチングされる、請求項１に記載の対話型サービス処理方法。
3. 前記活性化は、前記イベントのための時間期間の開始後に前記活性化メッセージテーブルが受信されると直ちに発生する、請求項１に記載の対話型サービス処理方法。
4. 前記アプリケーションパラメータテーブルは、前記アプリケーションパラメータテーブルの定義のバージョン番号を示すバージョン情報をさらに含む、請求項１に記載の対話型サービス処理方法。
5. 前記アプリケーションパラメータテーブルは、第７識別子をさらに含み、前記第７識別子は、前記第５識別子によって識別された前記イベントのために用いられるデータを識別し、前記活性化メッセージは、第８識別子をさらに含み、前記第８識別子は、前記第４識別子によって識別されたアプリケーションの前記第７識別子とマッチングされる、請求項２に記載の対話型サービス処理方法。
6. 前記活性化メッセージは、終了時間情報をさらに含み、前記終了時間情報は、前記セグメントの時間を基準に前記イベントのための時間期間の終わりを示す、請求項１に記載の対話型サービス処理方法。
7. 前記アプリケーションは、トリガーされた宣言的客体（Ｔｒｉｇｇｅｒｅｄ Ｄｅｃｌａｒａｔｉｖｅ Ｏｂｊｅｃｔ；ＴＤＯ）であり、前記アプリケーションパラメータテーブルは、ＴＤＯパラメータテーブルである、請求項１に記載の対話型サービス処理方法。
8. 前記セグメントの前記時間は、前記セグメントのメディア時間であり、前記セグメントのメディア時間は、コンテンツアイテムの再生における一時点を参照するパラメータである、請求項１に記載の対話型サービス処理方法。
9. 対話型サービス（ｉｎｔｅｒａｃｔｉｖｅ ｓｅｒｖｉｃｅ）を受信する装置において、
   ＨＴＴＰを通じて多重部分メッセージ（ｍｕｌｔｉ−ｐａｒｔ ｍｅｓｓａｇｅ）を受信するように構成されたネットワークインターフェースであって、前記多重部分メッセージは、前記多重部分メッセージの第１部分であるアプリケーションパラメータテーブルと前記多重部分メッセージの第２部分である活性化メッセージテーブルとで構成された、ネットワークインターフェースと、
   トリガーモジュールであって、
   前記多重部分メッセージをパーシング（ｐａｒｓｅ）し、
   前記アプリケーションパラメータテーブルと前記活性化メッセージテーブルを取得し、
   アプリケーションのうち少なくとも一つに関する情報を含む前記アプリケーションパラメータテーブルをパーシングし、
   第１識別子、第２識別子及びＵＲＬ情報を取得し、
   前記第１識別子は、前記アプリケーションパラメータテーブルに関連する対話型プログラムセグメント（ｉｎｔｅｒａｃｔｉｖｅ ｐｒｏｇｒａｍｍｉｎｇ ｓｅｇｍｅｎｔ）を識別し、
   前記第２識別子は、前記アプリケーションパラメータテーブルの範囲内の前記アプリケーションを識別し、
   前記ＵＲＬ情報は、前記アプリケーションを伝達可能なサーバーのＵＲＬを示し、
   前記ＵＲＬ情報は、前記アプリケーションの一部であるファイルを識別し、
   前記ネットワークインターフェースは、前記ＵＲＬ情報を用いて前記アプリケーションをダウンロードし、
   活性化の時間を意味する前記アプリケーションの活性化時間のうち少なくとも一つを示す活性化メッセージテーブルをパーシングし、
   第３識別子と活性化メッセージを取得し、
   前記第３識別子は、前記活性化メッセージテーブル内の前記活性化メッセージが適用される前記アプリケーションを含む前記アプリケーションパラメータテーブルの前記第１識別子とマッチングされ、
   前記活性化メッセージをパーシングし、
   第４識別子と開始時間情報を取得し、
   前記第４識別子は、前記活性化メッセージテーブルが連携された前記アプリケーションパラメータテーブル内のアプリケーションの前記第２識別子とマッチングされ、
   前記開始時間情報は、前記セグメントの時間を基準に前記アプリケーションにターゲットとなったイベントのための時間期間の開始を示す、ように構成されたトリガーモジュールと、
   前記アプリケーションを表示するように構成されたディスプレイモジュールと、
   を含む装置。
10. 前記アプリケーションパラメータテーブルは、第５識別子をさらに含み、
    前記アプリケーションパラメータテーブルをパーシングするように構成されたトリガーモジュールは、第５識別子をさらに取得し、
    前記第５識別子は、前記イベントを識別し、
    前記活性化メッセージは、第６識別子をさらに含み、
    前記活性化メッセージをパーシングするように構成された前記トリガーモジュールは、第６識別子をさらに取得し、
    前記第６識別子は、前記第４識別子によって識別されるアプリケーションの前記第５識別子とマッチングされる、請求項９に記載の装置。
11. 前記活性化は、前記イベントのための時間期間の開始後に前記活性化メッセージテーブルを受信すると直ちに発生する、請求項９に記載の装置。
12. 前記アプリケーションパラメータテーブルは、前記アプリケーションパラメータテーブルの定義のバージョン番号を示すバージョン情報をさらに含む、請求項９に記載の装置。
13. 前記アプリケーションパラメータテーブルは、第７識別子をさらに含み、前記アプリケーションパラメータテーブルをパーシングするように構成された前記トリガーモジュールは、前記第７識別子をさらに取得し、前記第７識別子は、前記第５識別子によって識別された前記イベントのために用いられるデータを識別し、
    前記活性化メッセージは、第８識別子をさらに含み、前記活性化メッセージをパーシングするように構成された前記トリガーモジュールは、前記第８識別子をさらに取得し、前記第８識別子は、前記第４識別子によって識別されたアプリケーションの前記第７識別子とマッチングされる、請求項１０に記載の装置。
14. 前記活性化メッセージは、終了時間情報をさらに含み、前記活性化メッセージをパーシングするように構成された前記トリガーモジュールは、前記終了時間情報をさらに取得し、前記終了時間情報は、前記セグメントの時間を基準に前記イベントのための時間期間の終わりを示す、請求項９に記載の装置。
15. 前記アプリケーションは、トリガーされた宣言的客体（Ｔｒｉｇｇｅｒｅｄ Ｄｅｃｌａｒａｔｉｖｅ Ｏｂｊｅｃｔ；ＴＤＯ）であり、前記アプリケーションパラメータテーブルは、ＴＤＯパラメータテーブルである、請求項９に記載の装置。
16. 前記セグメントの前記時間は、前記セグメントのメディア時間であり、前記セグメントのメディア時間は、コンテンツアイテムの再生における一時点を参照するパラメータである、請求項９に記載の装置。

Images