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

Abstract

【課題】対話型サービスを処理する方法及びその装置を提供する。【解決手段】本発明による方法は、トリガを生成するステップであって、トリガは、第１識別子及びパラメータを含み、第１識別子は、開始されるアプリケーションを識別し、パラメータは、メディア時間スタンプとコンテンツ識別子を含み、メディア時間スタンプは、コンテンツの再生における現在時点を示し、コンテンツ識別子は、現在視聴されているコンテンツを識別し、トリガは、アプリケーションが開始された後、アプリケーションに送られ、アプリケーションは、現在視聴されているコンテンツを識別するためにコンテンツ識別子をサーバに配信する、ステップと、トリガを含む放送信号を生成するステップと、放送信号を送信するステップと、を含む。【選択図】図２６

Description

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

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

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

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

上記の技術的課題を解決するために、本発明による対話型サービス（ｉｎｔｅｒａｃｔｉｖｅ ｓｅｒｖｉｃｅ）を処理する方法は、トリガを生成するステップであって、トリガは、第１識別子及びパラメータを含み、第１識別子は、開始されるアプリケーションを識別し、パラメータは、メディア時間スタンプ及びコンテンツ識別子を含み、メディア時間スタンプは、コンテンツの再生における現在時点を示し、コンテンツ識別子は、現在視聴されているコンテンツを識別し、トリガは、アプリケーションが開始された後、アプリケーションに送られ、アプリケーションは、現在視聴されているコンテンツを識別するためにコンテンツ識別子をサーバに配信する、ステップと、トリガを含む放送信号を生成するステップと、放送信号を送信するステップと、を含む。

好適には、第１識別子は、第１部分及び第２部分で構成され、第１部分は、登録されたインターネットドメイン名を参照し、第２部分は、ドメイン名を識別する権限を持つエンティティの制御及び管理下でディレクトリ経路を識別する。

好適には、トリガは、最大５２バイトの長さを有する。

好適には、アプリケーションがあらかじめ設置されていないか、又は既にキャッシュに記憶されていない場合、アプリケーションはダウンロードされ、アプリケーションは第１識別子によって識別される。

好適には、コンテンツの再生における現在時点は、セグメントのメディア時間である。

好適には、アプリケーションは、宣言的オブジェクト（Ｄｅｃｌａｒａｔｉｖｅ Ｏｂｊｅｃｔ）、トリガされた宣言的オブジェクト（Ｔｒｉｇｇｅｒｅｄ Ｄｅｃｌａｒａｔｉｖｅ Ｏｂｊｅｃｔ）、非実時間宣言的オブジェクト、又は非結合宣言的オブジェクト（Ｕｎｂｏｕｎｄ Ｄｅｃｌａｒａｔｉｖｅ Ｏｂｊｅｃｔ）である。

好適には、放送信号内のＤＴＶ字幕（ｃｌｏｓｅｄ ｃａｐｔｉｏｎ）チャネルにトリガを挿入するステップを含む。

上記の技術的課題を解決するために、本発明による対話型サービスを受信する装置は、放送信号を受信するように構成されたチューナ、放送信号をパースし、トリガを取得し、トリガをパースし、開始されるアプリケーションを識別する第１識別子及びパラメータを取得し、第１識別子によって識別されたアプリケーションを開始し、トリガは、アプリケーションが開始された後にアプリケーションに送られ、パラメータをパースし、メディア時間スタンプ及びコンテンツ識別子を得るように構成され、メディア時間スタンプは、コンテンツの再生における現在時点を示し、コンテンツ識別子は、現在視聴されているコンテンツを識別する、トリガモジュールと、サーバと通信するように構成された通信網インタフェースであって、アプリケーションは、現在視聴されているコンテンツを識別するためにコンテンツ識別子を通信網インタフェースを用いてサーバに配信する、通信網インタフェースと、アプリケーションを表示するように構成された表示と、を備える。

好適には、第１識別子は、第１部分及び第２部分で構成され、第１部分は、登録されたインターネットドメイン名を参照し、第２部分は、ドメイン名を識別する権限を持つエンティティの制御及び管理下でディレクトリ経路を識別する。

好適には、トリガは、最大５２バイトの長さを有する。

好適には、アプリケーションがあらかじめ組み込まれていないか、又は既にキャッシュに記憶されていない場合、アプリケーションはダウンロードされ、アプリケーションは、第１識別子によって識別される。

好適には、コンテンツの再生における現在時点は、セグメントのメディア時間である。

好適には、アプリケーションは、宣言的オブジェクト、トリガされた宣言的オブジェクト、非実時間宣言的オブジェクト、又は非結合宣言的オブジェクトである。

好適には、トリガは、放送信号内のＤＴＶ字幕チャネルに挿入される。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

このような対話型付加データサービスを実行するための２つのモデルがあり得る。直接実行モデル及びトリガされた宣言的オブジェクト（ＴＤＯ）モデルがそれである。

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

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

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

ＴＤＯモデルでは、宣言的オブジェクト、連携するデータ、スクリプト、テキスト及びグラヒックの配信を、対話型イベントの再生に対する特定タイミングの信号通知と区別する。

対話型イベントのタイミングを設定する要素はトリガである。

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

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

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

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

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

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

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

トリガは、信号通知（ｓｉｇｎａｌｉｎｇ）を識別し、対話型イベントの再生タイミングを設定する機能を担う信号通知要素である。

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

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

１．ＴＰＴ（放出ストリーム内のＦＬＵＴＥセッション、インターネットサーバ、又はこれら両者を介して利用可能なＴＰＴ）の位置を信号通知する。
２．次のプログラムセグメントに対する対話型コンテンツがプリロードされることを示す。
３．連携するオーディオ／ビデオコンテンツ又はオーディオコンテンツの現在メディア時間を示す。
４．ＴＰＴ内特定対話型イベントを参照し、当該イベントが今又は特定の未来メディア時刻に実行されなければならないということを知らせる。
５．需要が最大となることを避けるために、インターネットサーバに対する接続が特定の期間内にランダムに分散されることを示す。

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

図２は、あらかじめ作成されたコンテンツの場合に、トリガタイミングの一実施例を示す図である。

図２は、２つのプログラムセグメントと連携して配信されるトリガを示す。この例では、２つのセグメントとも“あらかじめ作成（ｐｒｅ−ｐｒｏｄｕｃｅ）”されるが、これは、コンテンツがライブコンテンツではなく、対話型要素はポストプロダクションで追加されたことを意味する。

図示のように、プログラムセグメント１の発生前の短い時間に“プリロード”トリガが配信されて、受信機と連携されているＴＰＴ及び単方向コンテンツを取得できる機会を受信機に許容することができる。プリロードトリガが送信されないとき、受信機は、コンテンツを取得するために該当のセグメント内で遭遇する最初のトリガを用いるはずである。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

活性化メッセージ及び時間ベースメッセージは双方とも、ある送信環境で次のような一般的な“トリガ”フォーマットを有してもよい。

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

このようなトリガ構文は、＜ｓｃｈｅｍｅ＞と“：／／”部分を除いて、付加的な制限事項と共にＵＲＩの一般構文（Ｇｅｎｅｒｉｃ Ｓｙｎｔａｘ）に基づく。

図４は、トリガ構文の一実施例を示す図である。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

次は、図４に示した構文において“ｅｖｅｎｔ＿ｔｉｍｅ”、“ｍｅｄｉａ＿ｔｉｍｅ”、“ｓｐｒｅａｄ”に関する部分である。

event_time ="e="1*digit["&t="1*7hexdigit]

media_time ="m="1*7hexdigit

spread ="s="1*digit

“ｅｖｅｎｔ＿ｔｉｍｅ”項は、対象とされたイベント（“ｅ＝”項）と当該イベントが活性化されるべき時間（“ｔ＝”項）を識別するために活性化トリガにおいて用いることができる。“ｔ＝”項がないときは、トリガが到達する時間にイベントが活性化されなければならないことを意味する。

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

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

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

すなわち、“ｍ＝”は、その次に１６進数を表示する１乃至８文字長の文字列が続くメディア時間スタンプ項であって、現在のメディア時間を示すことができる。

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

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

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

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

以下、ＴＤＯのライフサイクル及び状態、状態変化イベントについて説明する。

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

ＴＤＯは、次の４つの状態を有してもよい。

１．Ｒｅａｄｙ − ダウンロードされて実行準備ができているが、まだ実行されていない
２．Ａｃｔｉｖｅ − 実行中である
３．Ｓｕｓｐｅｎｄｅｄ − 状態が記憶され、一時的に実行が中止される
４．Ｒｅｌｅａｓｅｄ − 実行可能、実行中又は中止状態でない

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

１．“ｐｒｅｐａｒｅ”をトリガする − 装置は、ＴＤＯが実行（資源割当、主メモリへのロードなど）をするように準備されることを要求するトリガを（現在選択された１次仮想チャネルで）受信する。
２．“ｅｘｅｃｕｔｅ”をトリガする − 装置は、ＴＤＯが活性化されることを要求するトリガを（現在選択された１次仮想チャネルで）受信する。
３．“ｓｕｓｐｅｎｄ”をトリガする − 装置は、ＴＤＯの中止を示すトリガを（現在選択された１次仮想チャネルで）受信する。
４．“ｋｉｌｌ”をトリガする − 装置は、ＴＤＯの終了を示すトリガを（現在選択された１次仮想チャネルで）受信する。

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

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

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

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

ＴＰＴ構造内のフィールドの具体的な意味（ｓｅｍａｎｔｉｃｓ）は次のとおりである。

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

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

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

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

ＵＲＩである＠ｉｄは、当該ＴＰＴ要素に関連する対話型プログラムセグメントを一意に識別することができる。

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

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

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

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

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

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

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

ＬｉｖｅＴｒｉｇｇｅｒの子要素及び属性については後述する。

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

ＴＤＯの子要素及び属性については後述する。

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

ＬｉｖｅＴｒｉｇｇｅｒ要素は、＠ＵＲＬ及び＠ｐｏｌｌＰｅｒｉｏｄ属性を含むことができる。

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

ＬｉｖｅＴｒｉｇｇｅｒ要素の属性である＠ＵＲＬは、インターネットを介して活性化トリガを配信し得るサーバのＵＲＬを示すことができる。活性化トリガは、対話型サービスプロバイダの選択によって、ＨＴＴＰショートポーリング、ＨＴＴＰロングポーリング、又はＨＴＴＰストリーミングを用いてインターネットを介して配信することができる。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ＵＲＬ要素の属性である＠ｅｎｔｒｙは“ｔｒｕｅ”値を有すると、当該ＵＲＬが当該アプリケーションのエントリポイント、すなわち、当該アプリケーションを開始するために開始され得るファイルであることを示すことができる。“ｆａｌｓｅ”値を有すると、当該ＵＲＬが当該アプリケーションのエントリポイントでないことを示すことができる。当該属性が出現しないとき、デフォルト値は“ｆａｌｓｅ”であってもよい。

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

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

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

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

受信端でＴＰＴを受けてパースすると、ＴＤＯ及び上述したＴＤＯの子要素及び属性の情報を得ることができる。

ＴＤＯ要素の子要素の一つである、ｃｏｎｔｅｎｔＩｔｅｍ要素は、＠ｕｐｄａｔｅＡｖａｉｌ、＠ｐｏｌｌＰｅｒｉｏｄ、＠ｓｉｚｅ、＠ａｖａｉｌＩｎｔｅｒｎｅｔ、＠ａｖａｉｌＢｒｏａｄｃａｓｔａｔｔｒｉｂｕｔｅ及び／又はＵＲＬ要素を含むことができる。

ここで、ＵＲＬ要素は＠ｅｎｔｒｙ属性を含むことができる。

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

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

ＣｏｎｔｅｎｔＩｔｅｍ要素のブールのである＠ｕｐｄａｔｅｓＡｖａｉｌは、当該コンテンツアイテムがたまに更新されるか否か、すなわち、コンテンツアイテムが静的ファイル（ｓｔａｔｉｃ ｆｉｌｅ）で構成されるか、それとも、当該アイテムが実時間データ供給（ｆｅｅｄ）であるかを示すことができる。その値が“ｔｒｕｅ”のとき、当該コンテンツアイテムは時々更新され、その値が“ｆａｌｓｅ”のとき、当該コンテンツアイテムは更新されない。この属性が出現しないと、デフォルト値は“ｆａｌｓｅ”であってもよい。

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

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

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

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

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

ＴＤＯ要素の子要素の一つである、Ｅｖｅｎｔ要素は、＠ｅｖｅｎｔＩＤ、＠ａｃｔｉｏｎ、＠ｄｅｓｔｉｎａｔｉｏｎ、＠ｄｉｆｆｕｓｉｏｎ属性、及び／又はＤａｔａ要素を含むことができる。ここでＤａｔａ要素は＠ｄａｔａＩＤ属性を含むことができる。

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

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

“ｐｒｅｐ”は、“Ｔｒｉｇ ｐｒｅｐ”動作に対応できる。対象となったアプリケーションの状態が“Ｒｅｌｅａｓｅｄ”のとき、この動作は“Ｒｅａｄｙ”への状態変更を起こすことができる。

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

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

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

Ｅｖｅｎｔ要素の属性である＠ｄｅｓｔｉｎａｔｉｏｎは、当該イベントの対象装置を示すことができる。＠ｄｅｓｔｉｎａｔｉｏｎに関する詳細な内容は後述する。

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

Ｅｖｅｎｔ要素の子要素であるＤａｔａは、存在する場合、当該イベントに関連するデータを提供することができる。Ｅｖｅｎｔの別個の活性化は、それらと連携する異なるＤａｔａ要素を有してもよい。ここで、Ｄａｔａ要素は＠ｄａｔａＩＤ属性を含むことができる。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

可変長フィールドであるｓｅｇｍｅｎｔ＿ｉｄは、セグメントＩＤのバイトを含むことができるが、これは、ＴＰＴＸＭＬフォーマットの“ｉｄ”属性と同じ意味を有してもよい。

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

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

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

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

ｔｒｉｇｇｅｒ＿ｓｅｒｖｅｒ＿ＵＲＬ＿ｌｅｎｇｔｈフィールドが０でなければ、ｔｒｉｇｇｅｒ＿ｓｅｒｖｅｒ＿ＵＲＬは、Ｔｒｉｇｇｅｒ Ｓｅｒｖｅｒ ＵＲＬのバイトを含むことができ、これはＴＰＴＸＭＬフォーマットのＬｉｖｅＴｒｉｇｇｅｒ要素のＵＲＬ属性と同じ意味を有してもよい。

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

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

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

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

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

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

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

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

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

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

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

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

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

可変長フィールドであるａｐｐ＿ｎａｍｅは、ＴＰＴ ＸＭＬフォーマットであるＴＤＯ要素のａｐｐＮａｍｅ属性と同じ意味を有してもよい。

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

可変長フィールドであるｇｌｏｂａｌ＿ｉｄは、ＴＰＴ ＸＭＬフォーマットのＴＤＯ要素のｇｌｏｂａｌＩｄ属性と同じ意味を有してもよい。

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

８ビットフィールドであってもよいｃｏｏｋｉｅ＿ｓｐａｃｅは、ＴＰＴ ＸＭＬフォーマットのＴＤＯ要素のｃｏｏｋｉｅＳｐａｃｅ属性と同じ意味を有してもよい。

８ビットフィールドであってもよいｆｒｅｑｕｅｎｃｙ＿ｏｆ＿ｕｓｅは、存在する場合、ＴＰＴ ＸＭＬフォーマットのＴＤＯ要素のｆｒｅｑｕｅｎｃｙＯｆＵｓｅ属性と同じ意味を有してもよい。

８ビットフィールドであってもよいｅｘｐｉｒｅ＿ｄａｔｅは、ＴＰＴ ＸＭＬフォーマットのＴＤＯ要素のｅｘｐｉｒｅＤａｔｅ属性と同じ意味を有してもよい。

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

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

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

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

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

可変長フィールドであるＵＲＬは、ＴＰＴ ＸＭＬフォーマットであるＴＤＯ要素のＵＲＬ属性と同じ意味を有してもよい。

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

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

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

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

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

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

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

可変長フィールドであるＵＲＬは、ＴＰＴ ＸＭＬフォーマットであるＴＤＯ要素の子要素であるＣｏｎｔｅｎｔＩｔｅｍのＵＲＬ属性と同じ意味を有してもよい。

２４ビットフィールドであってもよいｃｏｎｔｅｎｔ＿ｓｉｚｅは、ＴＰＴ ＸＭＬフォーマットであるＴＤＯ要素の子要素であるＣｏｎｔｅｎｔＩｔｅｍのｃｏｎｔｅｎｔＳｉｚｅ属性と同じ意味を有してもよい。

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

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

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

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

５ビットフィールドであってもよいａｃｔｉｏｎは、ＴＰＴ ＸＭＬフォーマットであるＴＤＯ要素のＥｖｅｎｔ子要素のａｃｔｉｏｎ属性と同じ意味を有してもよい。

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

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

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

ｄｅｓｔｉｎａｔｉｏｎフィールドの意味は、存在する場合、ＴＰＴ ＸＭＬフォーマットであるＴＤＯ要素のＥｖｅｎｔ子要素のｄｅｓｔｉｎａｔｉｏｎ属性の意味と同一であってもよい。

ｄｉｆｆｕｓｉｏｎフィールドの意味は、存在する場合、ＴＰＴ ＸＭＬフォーマットであるＴＤＯ要素のＥｖｅｎｔ子要素のｄｉｆｆｕｓｉｏｎ属性の意味と同一であってもよい。

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

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

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

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

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

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

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

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

活性化メッセージテーブル（Ａｃｔｉｖａｔｉｏｎ Ｍｅｓｓａｇｅｓ Ｔａｂｌｅ、ＡＭＴ）は、セグメントのための活性化トリガに相応するものを含むことができる。ある環境では活性化トリガに代えてこのＡＭＴが受信機に配信してもよい。トリガは、“ｌｉｖｅ ｔｒｉｇｇｅｒ”サーバによって、ＡＣＲサーバによってＡＭＴを介して字幕ストリームで配信してもよい。

ＡＭＴ構造内のフィールドの具体的な意味は、次のとおりである。

ＡＭＴは、＠ｍａｊｏｒＰｒｏｔｏｃｏｌＶｅｒｓｉｏｎ、＠ｍｉｎｏｒＰｒｏｔｏｃｏｌＶｅｒｓｉｏｎ、＠ｓｅｇｍｅｎｔＩｄ、＠ｂｅｇｉｎＭＴ属性、及び／又はＡｃｔｉｖａｔｉｏｎ要素を含むことができる。

ＡＭＴ要素の４ビット属性であってもよい＠ｍａｊｏｒＰｒｏｔｏｃｏｌＶｅｒｓｉｏｎは、ＡＭＴ定義のメジャーバージョン番号を示すことができる。メジャーバージョン番号は１に設定することができる。受信機は、それらがサポートするように備えられていないメジャーバージョン値を示すＡＭＴのインスタンスを捨てると予想され得る。

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

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

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

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

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

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

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

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

Ａｃｔｉｖａｔｉｏｎ要素の属性である＠ｔａｒｇｅｔＴＤＯは、ＡＭＴに連携するＴＰＴ内のＴＤＯ要素のａｐｐＩＤ属性と対照することによって、活性化命令に対する対象アプリケーションを識別することができる。

Ａｃｔｉｖａｔｉｏｎ要素の属性である＠ｔａｒｇｅｔＥｖｅｎｔは、ｔａｒｇｅｔＴＤＯ属性によって識別されるＴＤＯ要素に含まれたＥｖｅｎｔ要素のｅｖｅｎｔＩＤ属性と対照することによって、当該活性化命令に対する対象イベントを識別することができる。

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

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

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

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

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

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

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

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

ＡＭＴ内Ａｃｔｉｖａｔｉｏｎ要素は、ｓｔａｒｔＴｉｍｅ値の昇順で出現できる。

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

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

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

１．一つ又はそれ以上の未来セグメントに対するＴＰＴのためのＵＲＬ。受信機がファイルをあらかじめダウンロードできるようにする。
２．放送ストリーム内の独立型ＮＲＴサービスに関する情報が検索され得るＮＲＴ信号通知サーバのＵＲＬ。受信機に放送ストリーム内のＮＲＴサービス信号通知の配信に対する利用権限がなくてもこれらのサービスに利用可能になる。
３．仮想チャネルに対する使用報告が送信される使用報告サーバのＵＲＬ。受信機に放送ストリーム内のこのＵＲＬの配信に対する利用権限がなくてもこのような報告を送信可能にする。
４．仮想チャネルに対するＰＤＩ−ＱテーブルのＵＲＬ。受信機に放送ストリームで配信されたＰＤＩ−Ｑテーブルに対する利用権限がなくても視聴体験を個人化（ｐｅｒｓｏｎａｌｉｚａｔｉｏｎ）可能にする。（ＰＤＩ−Ｑテーブルは対話型サービスを提供するにあたり、ユーザにカスタマイズサービスを提供するための個人化に関連するテーブルである。ＰＤＩ−Ｑテーブルを介してユーザに個人化のための質問ができる。）

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

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

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

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

ＵＲＬｌｉｓｔは、ＵｒｌＬｉｓｔ、ＴｐｔＵｒｌ、ＵｒｓＵｒｌ、及び／又はＰｄｉＵｒｌなどを含むことができる。これらの要素の意味は次のとおりである。

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

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

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

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

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

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

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

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

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

放送ストリームで配信される場合、トリガはＵＲＬＳｔｒｉｎｇ命令内でサービス＃６でＤＴＶ字幕チャネルで配信することができる。

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

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

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

時間ベーストリガが（字幕サービス＃６で）放送ストリームで配信される場合に、“ｍ＝”項が不存在のとき、時間ベーストリガは単純に信号通知サーバのＵＲＬを配信することができる。そして、“ｍ＝”項が不存在のとき、“ｔ＝”項は活性化トリガに不存在でなければならない。

活性化トリガが（字幕サービス＃６で）放送ストリームで配信される場合に、すなわち、“Ｔｒｉｇｇｅｒ”フォーマットが“ｅ＝”項を有しており、“ｔ＝”項は有しているかいない場合に“ｔ＝”項が存在するときは、活性化時刻は時間ベースに対する時間スタンプであってもよい。そして、“ｔ＝”項が不存在のとき、活性化時刻はメッセージの到達時刻になってもよい。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

１．活性化トリガ個別配信
２．活性化トリガ一括配信

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

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

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

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

いずれのプロトコルが用いられるかにかかわらず、受信機は質疑形式で活性化トリガサーバにＨＴＴＰ要求をすると予想され得る。
?mt=<media_time>
ここで、＜ｍｅｄｉａ＿ｔｉｍｅ＞は、視聴されているコンテンツの現在メディア時間であってもよい。

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

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

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

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

いずれの場合においても、ＨＴＴＰ応答は、配信モードを知らせるために、次の形態のいずれかの形態からなるＨＴＴＰ Ｒｅｓｐｏｎｓｅ Ｈｅａｄｅｒフィールドを含むことができる。
ATSC-Delivery-Mode:ShortPolling[<poll-period>]
ATSC-Delivery-Mode:LongPolling
ATSC-Delivery-Mode:Streaming

＜ｐｏｌｌ−ｐｅｒｉｏｄ＞パラメータは、連続するポーリングに対してポーリング間の推奨間隔を示すことができる。＜ｐｏｌｌ−ｐｅｒｉｏｄ＞は省略してもよい。

次に、活性化トリガ一括配信について説明する。

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

図１６は、ＴＰＴを含むプライベートセクションの２進フォーマットの一実施例を示す図である。以下に説明するＮＲＴスタイルプライベートセクションは、図１６のとおりである。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

図１７の要素の意味について説明する。

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

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

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

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

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

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

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

１．結合されるセグメントの集合を識別する。
２．新しいｓｅｇｍｅｎｔＩｄを有する新しいＴＰＴを生成する。
３．結合されるセグメントの中でライブ活性化を有するものがあれば、それらの活性化のすべてに対して利用権限を付与するリレーサーバを提供し、このサーバに対するパラメータを“ＬｉｖｅＴｒｉｇｇｅｒ”要素に入れる。
４．必要によって各セグメントに対してｂａｓｅＵＲＬを適用して全体ＴＤＯとＣｏｎｔｅｎｔＩｔｅｍ ＵＲＬを得る（結合されるすべてのセグメントに共通するより短いｂａｓｅＵＲＬを識別し、それを、結合されたセグメントに対するｂａｓｅＵＲＬとして維持する）。
５．必要によって値を修正して衝突を除去する。
６．結合されるすべてのセグメントに対するすべての修正されたＴＤＯ要素を新しいＴＰＴに挿入する。
７．結合されたＴＰＴの新しいｓｅｇｍｅｎｔＩｄに相応するｓｅｇｍｅｎｔＩｄを有する新しいＡＭＴを生成する。
８．新しいＡＭＴに対して適切な新しい“ｂｅｇｉｎＭＴ”値を選択する。
９．ａｐｐＩｄ値における変更を反映して結合されるセグメントに対するＡＭＴファイル内のすべてのＡｃｔｉｖａｔｉｏｎ要素のｔａｒｇｅｔＩｄ値を調整する。
１０．新しい“ｂｅｇｉｎＭＴ”値と結合されるセグメントに対する放送スケジュールを反映して結合されるセグメントに対するＡＭＴファイル内のすべてのＡｃｔｉｖａｔｉｏｎ要素のｓｔａｒｔＴｉｍｅとｅｎｄＴｉｍｅ値を調整する。
１１．修正されたすべてのＡｃｔｉｖａｔｉｏｎ要素を新しいＡＭＴに挿入する。

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

放送プログラムに対する宣言的オブジェクト動作の同期化をサポートするために、ビデオ／放送オブジェクトに対して追加の方法がサポートしてもよい。

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

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

１．ａｄｄＴｒｉｇｇｅｒＥｖｅｎｔＬｉｓｔｅｎｅｒ： ｅｖｅｎｔＩｄ別に、発生するイベントを処理するためのコールバック関数（リスナ関数）を登録
２．ｒｅｍｏｖｅＴｒｉｇｇｅｒＥｖｅｎｔＬｉｓｔｅｎｅｒ： ｅｖｅｎｔＩｄ別に、発生するイベントを処理するためのコールバック関数（リスナ関数）登録を取消

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

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

ａｄｄＴｒｉｇｇｅｒＥｖｅｎｔＬｉｓｔｅｎｅｒ関数は、Ｎｕｍｂｅｒ型のｅｖｅｎｔＩｄと、ＥｖｅｎｔＬｉｓｔｅｎｅｒ型のｌｉｓｔｅｎｅｒを引数として受けることができる。ＥｖｅｎｔＬｉｓｔｅｎｅｒ型については後述する。ａｄｄＴｒｉｇｇｅｒＥｖｅｎｔＬｉｓｔｅｎｅｒ関数は返却値がなくてもよい（ｖｏｉｄ）。

ｅｖｅｎｔＩｄ引数は、ＴＰＴのイベント要素中のｅｖｅｎｔＩｄであってもよい。ｌｉｓｔｅｎｅｒ引数は、当該イベントのためのリスナであってもよい。

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

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

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

ｒｅｍｏｖｅＴｒｉｇｇｅｒＥｖｅｎｔＬｉｓｔｅｎｅｒ関数は、Ｎｕｍｂｅｒ型のｅｖｅｎｔＩｄと、ＥｖｅｎｔＬｉｓｔｅｎｅｒ型のｌｉｓｔｅｎｅｒを引数として受けることができる。ＥｖｅｎｔＬｉｓｔｅｎｅｒ型については後述する。ｒｅｍｏｖｅＴｒｉｇｇｅｒＥｖｅｎｔＬｉｓｔｅｎｅｒ関数は、返却値がなくてもよい（ｖｏｉｄ）。

ｅｖｅｎｔＩｄ引数は、ＴＰＴのイベント要素中のｅｖｅｎｔＩＤであってもよい。ｌｉｓｔｅｎｅｒ引数は、当該イベントのためのリスナであってもよい。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

第４識別子は、前述したＡＭＴの子要素である活性化の＠ｔａｒｇｅｔＴＤＯ属性であってもよい。したがって、活性化命令が対象としているアプリケーションを識別することができる。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ＭＰＥＧ−２ＴＳシステム復号器２３０４０は、復調された信号のトランスポートストリーム（ＴＳ）を復号する。ＭＰＥＧ−２ＴＳシステム復号器２３０４０は、トランスポートストリームから字幕ストリームを取得して字幕モジュール２３０５０に伝達することができる。ＭＰＥＧ−２ＴＳシステム復号器２３０４０は、復号されたオーディオ信号、ビデオ信号をオーディオ復号器２３１１０、ビデオ復号器２３１２０に送ることができる。

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

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

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

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

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

ＵＩモジュール２３１００は、リモコン２３１７０を用いて視聴者が入力した情報をリモコン受信器２３１６０を介して受信することができる。受信した情報が通信網を用いるサービスなどに関連するもののとき、ブラウザキーコードをウェブブラウザに伝達することができる。伝達された情報が現在表示されている単純な映像に関するもののとき、グラヒックプロセッサ２３１５０を介して表示モジュール２３１４０に信号を伝達することができる。

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

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

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

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

グラヒックプロセッサ２３１５０は、字幕モジュール２３０５０から伝達された字幕テキストと、ＵＩモジュール２３１００から受信した視聴者の入力情報とをグラヒック化する処理を行うことができる。処理した情報は表示モジュール２３１４０に伝達することができる。グラヒックプロセッサ２３１５０は、通常の技術の分野において用いられるグラヒックプロセッサであってもよい。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ＵＲＬ情報は、アプリケーションを配信し得るサーバのＵＲＬを示すことができる。ＵＲＬ情報は、図５でＴＰＴの子要素であるＴＤＯ要素内にあるＵＲＬ要素に該当し得る。ＵＲＬ情報は、アプリケーションの一部であるファイルを識別することができる。通信網インタフェースはＵＲＬ情報を用いてアプリケーションをダウンロードすることができる。

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

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

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

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

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

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

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

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

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

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

直接実行モデルにおいて、仮想チャネルが選択されると直ちに宣言的オブジェクト（ＤＯ）が自動で開始される。宣言的オブジェクトは、画面上の特定位置での表示の生成、世論調査実行、他の特殊ＤＯの開始などのようにオーディオ／ビデオプログラムと同期化される対話型機能の提供のための具体的な指示事項を得るために、インターネットを介してバックエンドサーバと通信することができる。

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

トリガの役割、機能、構文は、直接実行モデルだからといって大きく変わらない。

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

トリガ構文については、前述したとおりである。

トリガは３つの部分で構成されたことがわかる。
<domain name part>/<directory path>[?<parameters>]

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

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

直接実行モデルにおいて、仮想チャネルが選択されると直ちにアプリケーションが自動で開始され得る。アプリケーションは“Ｓｙｎｃｈｒｏｎｉｚｅｄ Ｃｏｎｔｅｎｔ Ｐｒｏｔｏｃｏｌ”を通じてインターネットでバックエンドサーバと通信することができる。このサーバは、オーディオ／ビデオプログラムとすべて同期化された対話型機能、すなわち、画面の特定の位置に表示を生成し、ポーリングを実行し、ほかの特殊ＤＯを開始する機能の提供のための指示事項を提供することができる。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

トリガ生成（ｓｗ０１０）段階で、本発明の一実施例においてトリガは最大５２バイトの長さを有してもよい。

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

トリガ生成（ｓｗ０１０）段階で、本発明の一実施例において「コンテンツの再生における現在時点」は、セグメントのメディア時間を意味することができる。

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

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

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

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

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

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

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

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

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

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

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

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

本発明の一実施例において、トリガは最大５２バイトの長さを有してもよい。

本発明の一実施例において、「コンテンツの再生における現在時点」は、セグメントのメディア時間を意味する。

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

本発明の一実施例は、トリガが放送信号内のＤＴＶ字幕チャネルに挿入されていてもよい。

通信網インタフェースｘ０３０はサーバと通信することができる。アプリケーションは、現在視聴されているコンテンツを識別するために、通信網インタフェースを用いてコンテンツ識別子をサーバに配信することができる。

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

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

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

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

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

Claims (14)

1. 対話型サービスを処理する方法であって、
   トリガを生成するステップであって、
   前記トリガは、第１識別子及びパラメータを含み、
   前記第１識別子は、開始されるアプリケーションを識別し、
   前記パラメータは、メディア時間スタンプ及びコンテンツ識別子を含み、
   前記メディア時間スタンプは、コンテンツの再生における現在時点を示し、
   前記コンテンツ識別子は、現在視聴されているコンテンツを識別し、
   前記トリガは、前記アプリケーションが開始された後、前記アプリケーションに送られ、
   前記アプリケーションは、現在視聴されている前記コンテンツを識別するために前記コンテンツ識別子をサーバに配信する、ステップと、
   前記トリガを含む放送信号を生成するステップと、
   前記放送信号を送信するステップと、
   を有する方法。
2. 前記第１識別子は、第１部分及び第２部分で構成され、前記第１部分は、登録されたインターネットドメイン名を参照し、前記第２部分は、ドメイン名を識別する権限を持つエンティティの制御及び管理下でディレクトリ経路を識別する、請求項１に記載の方法。
3. 前記トリガは、最大５２バイトの長さを有する、請求項１に記載の方法。
4. 前記アプリケーションがあらかじめ設置されていないか、又は既にキャッシュに記憶されていない場合、前記アプリケーションはダウンロードされ、
   前記アプリケーションは、前記第１識別子によって識別される、請求項１に記載の方法。
5. 前記コンテンツの再生における前記現在時点は、セグメントのメディア時間である、請求項１に記載の方法。
6. 前記アプリケーションは、宣言的オブジェクト、トリガされた宣言的オブジェクト、非実時間宣言的オブジェクト、又は非結合宣言的オブジェクトである、請求項１に記載の方法。
7. 前記放送信号を生成するステップは、
   前記放送信号内のＤＴＶ字幕チャネルに前記トリガを挿入するステップを含む、請求項１に記載の方法。
8. 対話型サービスを受信する装置であって、
   放送信号を受信するように構成されたチューナと、
   トリガモジュールであって、
   前記放送信号をパースし、
   前記トリガを取得し、
   前記トリガをパースし、
   開始されるアプリケーションを識別する第１識別子及びパラメータを取得し、
   前記第１識別子によって識別された前記アプリケーションを開始し、
   前記トリガは、前記アプリケーションが開始された後に前記アプリケーションに送られ、
   前記パラメータをパースし、
   メディア時間スタンプ及びコンテンツ識別子を取得し、
   前記メディア時間スタンプはコンテンツの再生における現在時点を示し、
   前記コンテンツ識別子は、現在視聴されている前記コンテンツを識別する、
   ように構成されたトリガモジュールと、
   サーバと通信するように構成された通信網インタフェースであって、
   前記アプリケーションは現在視聴されているコンテンツを識別するために、前記コンテンツ識別子を前記通信網インタフェースを用いて前記サーバに配信する、通信網インタフェースと、
   前記アプリケーションを表示するように構成された表示モジュールと、
   を備える装置
9. 前記第１識別子は、第１部分及び第２部分で構成され、前記第１部分は、登録されたインターネットドメイン名を参照し、前記第２部分は、ドメイン名を識別する権限を持つエンティティの制御及び管理下でディレクトリ経路を識別する、請求項８に記載の装置。
10. 前記トリガは、最大５２バイトの長さを有する、請求項８に記載の装置。
11. 前記アプリケーションがあらかじめ設置されていないか、又は既にキャッシュに記憶されていない場合、前記アプリケーションはダウンロードされ、
    前記アプリケーションは、前記第１識別子によって識別される、請求項８に記載の装置。
12. 前記コンテンツの再生における前記現在時点は、セグメントのメディア時間である、請求項８に記載の装置。
13. 前記アプリケーションは、宣言的オブジェクト、トリガされた宣言的オブジェクト、非実時間宣言的オブジェクト、又は非結合宣言的オブジェクトである、請求項８に記載の装置。
14. 前記トリガは、前記放送信号内のＤＴＶ字幕チャネルに挿入される、請求項８に記載の装置。

Images