JP6352992B2 - 対話型放送サービスを含む放送信号処理方法及び装置 - Google Patents

Description

本発明は、放送サービスを提供し、これを受信及び処理するための方法及び装置に係り、より詳細には、放送システムを介して提供される放送コンテンツ、並びにこれと関連する対話型放送サービスを提供する方法及び装置に関する。

放送網管理、オーディオ／ビデオコーデック、通信網の放送システムに利用などの技術発展に伴い、放送システムは、視聴者に、より鮮明な画面、よりきれいなオーディオ、より多様なコンテンツを提供できるようになった。さらに、視聴者は、視聴者経験（ｕｓｅｒ ｅｘｐｅｒｉｅｎｃｅ：ＵＸ）に応じて、放送コンテンツと関連する付加情報が提供されることを望んでいる。また、視聴者は、放送コンテンツを単純に受信する受動的な姿勢から、放送コンテンツに対する積極的な参加を願う能動的な姿勢を取るに至った。しかし、現在の放送システムは、このような視聴者の需要を満たす適切なシステムを構築していない。例えば、現在の放送システムは、特定の放送コンテンツと関連する付加情報をどの時点で、どのような処理を通じて提供すべきかに対する技術的準備が全くできていない状況である。

本発明が達成しようとする技術的課題は、前述した問題点を解決するためのもので、放送コンテンツが再生される過程において、適切な時期に放送コンテンツと関連する付加情報を対話型放送サービスの形態で提供することにある。

ここに含まれ、広範囲に記述されたように、本発明の意図に応じてこれら目的及び他の利点を達成するために、送信機側で対話型放送サービスを含む放送信号を処理する方法が提供される。前記方法は、アプリケーション及び前記アプリケーションをターゲットとする対話型放送イベントに関するメタデータを含むパラメータテーブルを生成するステップと、前記パラメータテーブルを複数のパラメータブロックに分離するステップと、それぞれの前記パラメータブロックをそれぞれの複数のパラメータテーブルセクションに挿入するステップと、シグナリングを識別し、前記対話型放送イベントの再生のタイミングを設定するために、シグナリングエレメントであるトリガーを生成するステップと、前記トリガーを前記放送信号のクローズドキャプションチャネルに挿入するステップと、前記クローズドキャプションチャネル及び前記複数のパラメータテーブルセクションを伝達する特定のチャネルを含む前記放送信号を伝送するステップとを含み、前記トリガーは、前記放送信号において前記パラメータテーブルの位置を特定する位置情報を含む。

前記パラメータテーブルセクションは、前記パラメータテーブルセクションを識別するテーブル識別子フィールドと、前記パラメータテーブルの定義のメジャーバージョン番号及びマイナーバージョン番号を示すプロトコルバージョンフィールドと、前記パラメータテーブルのバージョン番号を示すパラメータテーブルデータバージョンフィールドと、前記パラメータテーブルの他の全てのパラメータテーブルセクションと同じ値を有するシーケンス番号フィールドとを含むことが好ましい。

前記挿入するステップは、前記テーブル識別子フィールド、前記プロトコルバージョンフィールド、前記パラメータテーブルデータバージョンフィールド、前記シーケンス番号フィールドの共通値を有する前記複数のパラメータテーブルセクションを生成するステップと、それぞれの前記パラメータブロックをそれぞれの前記複数のパラメータテーブルセクションに挿入するステップとを含むことが好ましい。

前記パラメータテーブルセクションは、非リアルタイム伝送を通じて使用前に伝送されることが好ましい。

前記方法は、前記トリガーが前記放送信号の前記クローズドキャプションチャネルを介して伝送されることを明示するタイプ情報をエンコーディングするステップと、前記エンコーディングされたタイプ情報を前記クローズドキャプションチャネルに挿入するステップとをさらに含むことが好ましい。

前記パラメータテーブルセクションは、パラメータテーブルセクションのセクション番号を特定するセクション番号フィールドをさらに含み、前記セクション番号は、前記パラメータテーブルにおいて追加されるパラメータテーブルセクション毎に１ずつ増加することが好ましい。

前記パラメータテーブルセクションは、前記複数のパラメータテーブルセクションにおいてパラメータテーブルセクションの順序を特定するセクション番号フィールドをさらに含むことが好ましい。

前記パラメータテーブルセクションは、前記パラメータテーブルに記述されたコンテンツアイテムを提供する前記対話型放送サービスと関連する識別子を特定するサービス識別フィールドをさらに含むことが好ましい。

本発明の他の側面において、対話型放送サービスを含む放送信号を処理する受信機が提供される。前記受信機は、クローズドキャプションチャネル及び複数のパラメータテーブルセクションを伝達する特定のチャネルを含む前記放送信号を受信するように構成された受信装置と、シグナリングを識別するために、シグナリングエレメントとして、前記放送信号においてパラメータテーブルの位置を特定する位置情報を含むトリガーを抽出し、前記放送信号の前記クローズドキャプションチャネルから対話型放送イベントの再生のタイミングを設定するように構成された抽出装置と、前記トリガーでの前記位置情報に基づいて、前記パラメータテーブルから分離されたそれぞれの複数のパラメータブロックをそれぞれ含む複数のパラメータテーブルセクションを収集し、前記複数のパラメータブロックを用いて、アプリケーション及び前記アプリケーションをターゲットとする対話型放送イベントに関するメタデータを含む前記パラメータテーブルを形成するように構成されたトリガーモジュールと、前記形成されたパラメータテーブルに基づいて前記対話型放送サービスを提供するように構成されたプロセッサとを含む。

前記パラメータテーブルセクションは、前記パラメータテーブルセクションを識別するテーブル識別子フィールドと、前記パラメータテーブルの定義のメジャーバージョン番号及びマイナーバージョン番号を示すプロトコルバージョンフィールドと、前記パラメータテーブルのバージョン番号を示すパラメータテーブルデータバージョンフィールドと、前記パラメータテーブルの他の全てのパラメータテーブルセクションと同じ値を有するシーケンス番号フィールドとを含むことが好ましい。

前記トリガーモジュールは、前記テーブル識別子フィールド、前記プロトコルバージョンフィールド、前記パラメータテーブルデータバージョンフィールド、前記シーケンス番号フィールドの共通値を有する前記複数のパラメータテーブルセクションを収集し、それぞれの前記複数のパラメータテーブルセクションからそれぞれの前記パラメータブロックを抽出するようにさらに構成されることが好ましい。

前記パラメータテーブルセクションは、非リアルタイム伝送を通じて使用前に伝送されることが好ましい。

前記抽出装置は、前記トリガーが前記放送信号の前記クローズドキャプションチャネルを介して伝送されることを明示するタイプ情報を抽出するようにさらに構成されることが好ましい。

前記パラメータテーブルセクションは、パラメータテーブルセクションのセクション番号を特定するセクション番号フィールドをさらに含み、前記セクション番号は、前記パラメータテーブルにおいて追加されるパラメータテーブルセクション毎に１ずつ増加することが好ましい。

前記パラメータテーブルセクションは、前記複数のパラメータテーブルセクションにおいてパラメータテーブルセクションの順序を特定するセクション番号フィールドをさらに含むことが好ましい。

前記パラメータテーブルセクションは、前記パラメータテーブルに記述されたコンテンツアイテムを提供する前記対話型放送サービスと関連する識別子を特定するサービス識別フィールドをさらに含むことが好ましい。

本発明によれば、既存の放送システムを用いて、放送コンテンツと関連する対話型放送サービスまたは対話型放送イベントを提供できるという効果がある。

本発明によれば、放送コンテンツと関連する付加情報がディスプレイされなければならない時点を正確に把握して、適時に付加情報をユーザに提供できるという効果がある。

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

本発明の一実施例に係るリアルタイム（Ｒｅａｌ Ｔｉｍｅ：ＲＴ）サービス及び非リアルタイム（Ｎｏｎ−Ｒｅａｌ Ｔｉｍｅ：ＮＲＴ）サービスを提供する概念を示す図である。 本発明の一実施例に係るＮＲＴサービスをシグナリングする構造を示す図である。 本発明の一実施例に係るＴＤＯパラメータテーブル（ＴＤＯ Ｐａｒａｍｅｔｅｒ Ｔａｂｌｅ：ＴＰＴ）の一部分を示す図である。 本発明の一実施例に係るＴＤＯパラメータテーブル（ＴＤＯ Ｐａｒａｍｅｔｅｒ Ｔａｂｌｅ：ＴＰＴ）の他の一部分を示す図である。 本発明の一実施例に係るｃａｐａｂｉｌｉｔｉｅｓ_ｄｅｓｃｒｉｐｔｏｒを示す図である。 本発明の一実施例に係るアクティベーションメッセージテーブル（Ａｃｔｉｖａｔｉｏｎ Ｍｅｓｓａｇｅ Ｔａｂｌｅ：ＡＭＴ）を示す図である。 本発明の一実施例に係るトリガーフォーマットを示す図である。 本発明の一実施例に係るＴＰＴ要求に対する応答の一つの部分であるＵＲＬ情報を提供するＸＭＬ ｓｃｈｅｍｅを示す図である。 本発明の他の実施例に係るＴＰＴ要求に対する応答の一つの部分であるＵＲＬ情報を提供するＸＭＬ ｓｃｈｅｍｅを示す図である。 本発明の一実施例に係るトリガーのシンタックスを示す図である。 本発明の一実施例に係るバイナリフォーマット（ｂｉｎａｒｙ ｆｏｒｍａｔ）のＴＰＴの一部を示す図である。 本発明の一実施例に係るバイナリフォーマットのＴＰＴの他の一部を示す図である。 本発明の一実施例に係るバイナリフォーマットのＴＰＴの更に他の一部を示す図である。 本発明の一実施例に係るバイナリフォーマットのＴＰＴの更に他の一部を示す図である。 本発明の一実施例に係るバイナリフォーマットのＴＰＴの更に他の一部を示す図である。 本発明の一実施例に係るＴＰＴセクションの構造を示す図である。 本発明の一実施例に係る受信機の構造を示す図である。 本発明の他の一実施例に係る受信機の構造を示す図である。

発明のより容易な理解を助け、発明の実施例を示す添付の図面が、下記の記載と共に本発明の原理を説明するために提供される。
添付の図面は上記の通りである。
以下、上記の目的を具体的に実現することができる本発明の好適な実施例を添付の図面を参照して説明する。このとき、図面に図示され、またこれによって説明される本発明の構成と作用は、少なくとも１つの実施例として説明されるものであり、これによって本発明の技術的思想とその核心構成及び作用が制限されるものではない。

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

本発明で使用する用語のうちのｒｅａｌ ｔｉｍｅ（ＲＴ） ｓｅｒｖｉｃｅは、その言葉通りにリアルタイムサービスを意味する。すなわち、時間に拘束されるサービスである。一方、ｎｏｎ−ｒｅａｌ ｔｉｍｅ（ＮＲＴ） ｓｅｒｖｉｃｅは、ＲＴサービス以外の非リアルタイムサービスを意味する。すなわち、非リアルタイムサービスは、時間に拘束されないサービスである。そして、ＮＲＴサービスのためのデータをＮＲＴサービスデータと呼ぶことにする。

本発明に係る放送受信機は、地上波、ケーブル、インターネットなどのような媒体を介して非リアルタイム（ＮＲＴ）サービスを受信することができる。ＮＲＴサービスは、放送受信機の格納媒体に格納された後、既設定の時間やユーザの要求によってディスプレイ装置に表示される。ＮＲＴサービスは、ファイルの形態で受信され、格納媒体に格納されることを一実施例とする。格納媒体は、放送受信機の内部に装着された内蔵ＨＤＤであることを一実施例とする。他の例として、格納媒体は、放送受信システムの外部に接続されたＵＳＢ（Ｕｎｉｖｅｒｓａｌ Ｓｅｒｉａｌ Ｂｕｓ）メモリ、外装ＨＤＤなどであってもよい。ＮＲＴサービスを構成するファイルを受信して格納媒体に格納し、ユーザにサービスするためには、シグナリング情報が必要である。本発明は、これをＮＲＴサービスシグナリング情報又はＮＲＴサービスシグナリングデータと呼ぶことにする。本発明に係るＮＲＴサービスは、ＩＰデータグラムを得る方式に応じてＦｉｘｅｄ ＮＲＴサービスとＭｏｂｉｌｅ ＮＲＴサービスとに区分することができる。特に、Ｆｉｘｅｄ ＮＲＴサービスは固定型放送受信機に提供され、Ｍｏｂｉｌｅ ＮＲＴサービスは移動型放送受信機に提供される。本発明は、Ｆｉｘｅｄ ＮＲＴサービスを一実施例として説明する。しかし、本発明がＭｏｂｉｌｅ ＮＲＴサービスにも適用できることはいうまでもない。

本発明で使用する用語のうち、対話型付加サービス（Ｉｎｔｅｒａｃｔｉｖｅ Ａｄｊｕｎｃｔ Ｓｅｒｖｉｃｅ）または対話型放送サービス（Ｉｎｔｅｒａｃｔｉｖｅ Ｂｒｏａｄｃａｓｔ Ｓｅｒｖｉｃｅ）は、視聴経験（ｖｉｅｗｉｎｇ ｅｘｐｅｒｉｅｎｃｅ）の向上のために、視聴者に対話型経験を提供するデータサービスまたは放送サービスである。対話型放送サービスは、ＴＤＯ（Ｔｒｉｇｇｅｒｅｄ Ｄｅｃｌａｒａｔｉｖｅ Ｏｂｊｅｃｔ），ＤＯ（Ｄｅｃｌａｒａｔｉｖｅ Ｏｂｊｅｃｔ）、またはＮＤＯ（Ｎｏｎ−ｒｅａｌ−ｔｉｍｅ Ｄｅｃｌａｒａｔｉｖｅ Ｏｂｊｅｃｔ）を含む。

本発明で使用する用語のうち、トリガー（Ｔｒｉｇｇｅｒ）は、シグナリングを識別し、対話型サービスまたは対話型イベントの提供時点を設定するシグナリングエレメント（ｓｉｇｎａｌｉｎｇ ｅｌｅｍｅｎｔ）である。トリガーは、タイムベーストリガー（ｔｉｍｅ ｂａｓｅ ｔｒｉｇｇｅｒ）及び／又はアクティベーショントリガー（ａｃｔｉｖａｔｉｏｎ ｔｒｉｇｇｅｒ）としての役割を担うことができる。タイムベーストリガー（ｔｉｍｅ ｂａｓｅ ｔｒｉｇｇｅｒ）は、イベントの再生時刻の基準を提示するタイムベースを設定するために用いられる。アクティベーショントリガーは、イベントの動作時刻を設定するために用いられる。後述するタイムベースメッセージ（ｔｉｍｅ ｂａｓｅ ｍｅｓｓａｇｅｓ）がタイムベーストリガーとして用いられてもよく、またはタイムベーストリガーがタイムベースメッセージとして用いられてもよい。後述するアクティベーションメッセージ（ａｃｔｉｖａｔｉｏｎ ｍｅｓｓａｇｅｓ）がアクティベーショントリガーとして用いられてもよく、またはアクティベーショントリガーがアクティベーションメッセージとして用いられてもよい。

タイムベーストリガーは、タイムクロック（ｔｉｍｅ ｃｌｏｃｋ）でサンプリングされたタイムスタンプ（ｔｉｍｅｓｔａｍｐ）を伝送するトリガーである。詳細は後述する。

アクティベーショントリガーは、トリガー動作またはイベントの動作時間を示す情報を伝送するトリガーである。詳細は後述する。

メディアタイム（Ｍｅｄｉａ Ｔｉｍｅ）は、コンテンツの再生時に、特定の時点を参照するためのパラメータ（ｐａｒａｍｅｔｅｒ）である。

ＤＯ（Ｄｅｃｌａｒａｔｉｖｅ Ｏｂｊｅｃｔ）は、放送コンテンツと関連する付加情報を表出するアプリケーションまたはディスプレイ自体を示すことができる。ＤＯ（Ｄｅｃｌａｒａｔｉｖｅ Ｏｂｊｅｃｔ）は、放送コンテンツと関連する対話型サービスまたは対話型イベントを表出するアプリケーションまたはディスプレイ自体を示すことができる。１つのＤＯには１つ以上の対話型イベントが含まれてもよい。

ＴＤＯ（Ｔｒｉｇｇｅｒｅｄ Ｄｅｃｌａｒａｔｉｖｅ Ｏｂｊｅｃｔ）は、放送コンテンツ内の付加情報を示すものである。ＴＤＯは、付加情報を放送コンテンツ内でタイミングに合わせてトリガー（ｔｒｉｇｇｅｒ）する概念である。トリガーによってＤＯが実行される場合、このＤＯをＴＤＯと定義することができる。例えば、オーディションプログラムが放送される場合、視聴者が好むオーディション参加者の現在の順位などを当該放送コンテンツと共に表示することができ、このとき、オーディション参加者の現在の順位などに関する付加情報がＴＤＯとなり得る。このようなＴＤＯは、視聴者と対話型疎通を通じて変更されるか、または視聴者の意図を反映して提供されてもよい。

ＮＤＯ（Ｎｏｎ−ｒｅａｌ−ｔｉｍｅ Ｄｅｃｌａｒａｔｉｖｅ Ｏｂｊｅｃｔ）は、ＮＲＴサービスの一部として提供されるＤＯと定義することができる。

図１は、本発明の一実施例に係るリアルタイム（Ｒｅａｌ Ｔｉｍｅ；ＲＴ）サービス及び非リアルタイム（Ｎｏｎ−Ｒｅａｌ Ｔｉｍｅ；ＮＲＴ）サービスを提供する概念を示す図である。

放送局は、既存の方式に従って、すなわち、現在の地上波放送（又はモバイル放送）のようにリアルタイムサービスを送信する。このとき、放送局は、リアルタイムサービスを送信し、その過程で残る帯域幅を利用したり、または専用帯域幅を利用したりして非リアルタイムサービスを提供することができる。すなわち、リアルタイムサービス及び非リアルタイムサービスは、同じチャネルまたは異なるチャネルを介して伝送される。したがって、放送受信機でリアルタイムサービスと非リアルタイムサービスとを区分し、区分された非リアルタイムサービスを格納した後、必要時にユーザに提供するために、非リアルタイムサービスシグナリング情報（又はＮＲＴサービスシグナリングデータ）が要求される。非リアルタイムサービスシグナリング情報（又はＮＲＴサービスシグナリングデータ）は以降に詳細に説明する。例えば、放送局では、放送サービスデータをリアルタイムで送信し、ニュースクリップ、天気情報、広告、Ｐｕｓｈ ＶＯＤなどを非リアルタイムで送信することができる。また、非リアルタイムサービスは、ニュースクリップ、天気情報、広告、Ｐｕｓｈ ＶＯＤだけでなく、リアルタイム放送ストリームのうち特定の場面、特定のプログラムの詳細情報、プレビューなどであってもよい。

従来の放送受信機（即ち、ｌｅｇａｃｙ ｄｅｖｉｃｅ）は、リアルタイムサービスを受信して処理することはできるが、非リアルタイムサービスを受信して処理することはできない。すなわち、従来の放送受信機（即ち、ｌｅｇａｃｙ ｄｅｖｉｃｅ）は、リアルタイムサービスを伝送するチャネルに含まれた非リアルタイムストリームによってその動作が影響を受けないことが原則である。言い換えると、従来の放送受信機は、非リアルタイムサービスを受信しても、適切に処理できる手段が備えられていないため、受信された非リアルタイムサービスを処理することができない。

一方、本発明に係る放送受信機（即ち、ＮＲＴ ｄｅｖｉｃｅ）は、リアルタイムサービスと結合された非リアルタイムサービスを受信して適切に処理できるので、視聴者に従来の放送受信機に比べて多様な機能を提供することができる。

本発明に係る１つの非リアルタイムサービスは、１つ以上のコンテンツアイテム（又はコンテンツ又はＮＲＴコンテンツという）を含み、１つのコンテンツアイテムは、１つ以上のファイルを含むことを一実施例とする。本発明においてファイルとオブジェクトは同じ意味として使用される。コンテンツアイテムは、独立して再生が可能な最小単位である。例えば、非リアルタイムで提供されるニュースがあり、ニュースには経済ニュース、政治ニュース、生活ニュースが含まれるとするとき、ニュースは非リアルタイムサービスと言うことができ、経済ニュース、政治ニュース、生活ニュースのそれぞれはコンテンツアイテムと言える。そして、経済ニュース、政治ニュース、生活ニュースのそれぞれは、１つ以上のファイルで構成される。

このとき、非リアルタイムサービスは、リアルタイムサービスと同じ放送チャネルまたは専用放送チャネルを介してＭＰＥＧ−２トランスポートストリーム（ＴＳ）パケットの形態で伝送されてもよい。この場合、非リアルタイムサービスを識別するために、ユニークなＰＩＤがＮＲＴサービスデータのＴＳパケットに割り当てられて伝送される。本発明は、ＩＰベースのＮＲＴサービスデータがＭＰＥＧ−２ ＴＳパケット化されて伝送されることを一実施例とする。

このとき、ＮＲＴサービスデータを受信するのに必要なＮＲＴサービスシグナリングデータは、ＮＲＴサービスシグナリングチャネルを介して伝送される。ＮＲＴサービスシグナリングチャネルは、ＩＰ層上で特定のＩＰストリームを介して伝送され、このとき、ＩＰストリームもＭＰＥＧ−２ ＴＳパケット化されて伝送される。ＮＲＴサービスシグナリングチャネルで伝送されるＮＲＴサービスシグナリングデータは、ＮＲＴサービスマップテーブル（ＮＲＴ Ｓｅｒｖｉｃｅ Ｍａｐ Ｔａｂｌｅ； ＳＭＴ）及び／又はＮＲＴ情報テーブル（ＮＲＴ Ｉｎｆｏｒｍａｔｉｏｎ Ｔａｂｌｅ； ＮＲＴ−ＩＴ）を含む。ＳＭＴは、ＩＰ層で駆動する少なくとも１つの非リアルタイムサービス、非リアルタイムサービスを構成するコンテンツアイテム／ファイルなどの接続情報を提供することを一実施例とする。ＮＲＴ−ＩＴは、非リアルタイムサービスを構成するコンテンツアイテム／ファイルなどの詳細情報を提供することを一実施例とする。本発明は、ＳＭＴ及びＮＲＴ−ＩＴをシグナリング情報テーブルと呼ぶことにする。

本発明の一実施例によれば、放送コンテンツの他にＴＤＯも非リアルタイムサービスまたはリアルタイムサービスとして伝送されてもよい。また、ＴＤＯは、放送網ではなくインターネット網を介して伝送されてもよい。

図２は、本発明の一実施例に係るＮＲＴサービスをシグナリングする構造を示す図である。

本発明の一実施例に係るＳＭＴとＮＲＴ−ＩＴは、サービスシグナリングチャネル（Ｓｅｒｖｉｃｅ Ｓｉｇｎａｌｉｎｇ Ｃｈａｎｎｅｌ： ＳＳＣ）という特定のＩＰアドレスとｐｏｒｔ番号を有するチャネルを介して伝送されてもよい。

本発明の一実施例に係るＳＭＴは、多数のＮＲＴサービスのためのシグナリング情報を含むことができ、それぞれのＮＲＴサービスに対して、ｓｅｒｖｉｃｅ ｎａｍｅ情報、ＩＰ及びｐｏｒｔ情報、ＦＬＵＴＥ ｓｅｓｓｉｏｎ情報、ｓｅｒｖｉｃｅ ＩＤ情報、ｓｅｒｖｉｃｅ ｃａｔｅｇｏｒｙ情報、ｃｏｎｔｅｎｔ ｌｅｎｇｔｈ情報、ｓｔｏｒａｇｅ ｒｅｓｅｒｖａｔｉｏｎ情報、ＩＳＯ−６３９ Ｌａｎｇｕａｇｅ情報、Ｇｅｎｒｅ情報、及び／又はｉｃｏｎ ｃｏｎｔｅｎｔ ｌｉｎｋａｇｅ情報を含むことができる。

ｓｅｒｖｉｃｅ ｎａｍｅ情報は、ＮＲＴサービスに名を示す情報であって、ユーザとの相互作用のために使用することができる。すなわち、ユーザは、ＮＲＴサービス名で当該サービスを認識し、このサービスを要求することができる。

ＩＰ及びｐｏｒｔ情報は、ＮＲＴサービスを提供するＩＰアドレス及びｐｏｒｔ番号を示す。

ＦＬＵＴＥ ｓｅｓｓｉｏｎ情報は、ＮＲＴサービスと関連するファイルを伝送するＦＬＵＴＥ（Ｆｉｌｅ Ｄｅｌｉｖｅｒｙ ｏｖｅｒ Ｕｎｉｄｉｒｅｃｔｉｏｎａｌ Ｔｒａｎｓｐｏｒｔ）セッションを示す。

ｓｅｒｖｉｃｅ ＩＤ情報は、ＮＲＴサービスを識別する識別子である。Ｓｅｒｖｉｃｅ ＩＤ情報は、ＮＲＴ−ＩＴへのリンケージ（ｌｉｎｋａｇｅ）として使用することができる。

ｓｅｒｖｉｃｅ ｃａｔｅｇｏｒｙ情報は、サービスのカテゴリーを示す。例えば、サービスがＲＴサービス、ＩＰサービス、ＥＰＧサービス、またはＮＲＴサービスのいずれに属するかを示すことができる。

ｃｏｎｔｅｎｔ ｌｅｎｇｔｈ情報は、ＮＲＴサービスに含まれたｃｏｎｔｅｎｔの長さを示す情報である。

ｓｔｏｒａｇｅ ｒｅｓｅｒｖａｔｉｏｎ情報は、ＮＲＴサービスの提供を受けるために予約が必要な格納装置の容量を示す情報である。

ＩＳＯ−６３９ Ｌａｎｇｕａｇｅ情報は、ＮＲＴサービスにおいて使用される言語に関する情報である。

Ｇｅｎｒｅ情報は、ＮＲＴサービスのジャンルを示す情報である。

ｉｃｏｎ ｃｏｎｔｅｎｔ ｌｉｎｋａｇｅ情報は、ＮＲＴサービスを説明するアイコンに対する連結情報である。ｉｃｏｎ ｃｏｎｔｅｎｔ ｌｉｎｋａｇｅ情報は、ＦＬＵＴＥ ＦＤＴ（Ｆｉｌｅ Ｄｅｌｉｖｅｒｙ Ｔａｂｌｅ）のｃｏｎｔｅｎｔ−ｌｉｎｋａｇｅ情報とマッチングされる場合、受信機が、当該ｃｏｎｔｅｎｔ−ｌｉｎｋａｇｅと関連するｃｏｎｔｅｎｔ−ｌｏｃａｔｉｏｎ情報が示すアドレスからアイコンを受信できるようにするために使用される。

本発明の一実施例に係るＮＲＴ−ＩＴは、多数のＮＲＴコンテンツに関する情報を含むことができ、それぞれのコンテンツに対してｓｅｒｖｉｃｅ ＩＤ情報、ｃｏｎｔｅｎｔ ｎａｍｅ情報、ｃｏｎｔｅｎｔ ｌｉｎｋａｇｅ情報、ｄｉｓｔｒｉｂｕｔｉｏｎ ｓｔａｒｔ／ｅｎｄ ｔｉｍｅ情報、ｐｌａｙｂａｃｋ ｌｅｎｇｔｈ情報、ｃｏｎｔｅｎｔ ｌｅｎｇｔｈ情報、ｍｅｄｉａ ｔｙｐｅ情報、ｉｃｏｎ ｃｏｎｔｅｎｔ−ｌｉｎｋａｇｅ情報、ＩＳＯ−６３９ ｌａｎｇｕａｇｅ情報、ｃａｐｔｉｏｎ ｓｅｒｖｉｃｅ情報、ｃｏｎｔｅｎｔ ａｄｖｉｓｏｒｙ情報、ｇｅｎｒｅ情報、及び／又はｉｎｔｅｒｎｅｔ ｌｏｃａｔｉｏｎ情報を含むことができる。

ｃｏｎｔｅｎｔ ｌｉｎｋａｇｅ情報は、ＦＬＵＴＥ ＦＤＴのｃｏｎｔｅｎｔ−ｌｉｎｋａｇｅ情報とマッチングされる場合、受信機が、当該ｃｏｎｔｅｎｔ−ｌｉｎｋａｇｅと関連するｃｏｎｔｅｎｔ−ｌｏｃａｔｉｏｎ情報が示すアドレスから、ＮＲＴコンテンツを構成するファイルを受信できるようにするのに使用される。ｃｏｎｔｅｎｔ ｌｉｎｋａｇｅ情報は、ＮＲＴ−ＩＴとＴＦＴ（Ｔｅｘｔ Ｆｒａｇｍｅｎｔ Ｔａｂｌｅ；ＴＦＴ）を連結するリンケージ（ｌｉｎｋａｇｅ）として使用することができる。ＴＦＴは、ＮＲＴサービスまたはＮＲＴコンテンツに対する説明を提供するのに使用されるテキストフラグメントを含む。すなわち、ＴＦＴは、多数の言語を支援するデータ構造を伝送し、当該データ構造は、多数の他の言語でＮＲＴサービスまたはＮＲＴコンテンツに対する説明を提供するためのデータを含む。

ｉｃｏｎ ｃｏｎｔｅｎｔ−ｌｉｎｋａｇｅ情報は、ＮＲＴコンテンツを説明するアイコンに対する連結情報である。ｉｃｏｎ ｃｏｎｔｅｎｔ−ｌｉｎｋａｇｅ情報は、ＦＬＵＴＥ ＦＤＴのｃｏｎｔｅｎｔ−ｌｉｎｋａｇｅ情報とマッチングされる場合、受信機が、当該ｃｏｎｔｅｎｔ−ｌｉｎｋａｇｅと関連するｃｏｎｔｅｎｔ−ｌｏｃａｔｉｏｎ情報が示すアドレスから、ＮＲＴコンテンツのアイコンを受信できるようにするのに使用される。

図３は、本発明の一実施例に係るＴＤＯパラメータテーブル（ＴＤＯ Ｐａｒａｍｅｔｅｒ Ｔａｂｌｅ：ＴＰＴ）の一部分を示す図である。

図４は、本発明の一実施例に係るＴＤＯパラメータテーブル（ＴＤＯ Ｐａｒａｍｅｔｅｒ Ｔａｂｌｅ：ＴＰＴ）の他の一部分を示す図である。

本発明の一実施例に係るＴＤＯパラメータテーブルは、セグメントに含まれるＴＤＯ及び／又はＴＤＯに含まれるイベントに関するメタデータを含んでいる。

ＴＤＯパラメータテーブルは、ＴＰＴエレメント、ＭａｊｏｒＰｒｏｔｏｃｏｌＶｅｒｓｉｏｎエレメント、ＭｉｎｏｒＰｒｏｔｏｃｏｌＶｅｒｓｉｏｎエレメント、ｉｄエレメント、ｔｐｔＶｅｒｓｉｏｎエレメント、ｅｘｐｉｒｅＤａｔｅエレメント、ｓｅｒｖｉｃｅＩＤエレメント、ｂａｓｅＵＲＬエレメント、Ｃａｐａｂｉｌｉｔｉｅｓエレメント、ＬｉｖｅＴｒｉｇｇｅｒエレメント、ＵＲＬエレメント、ｐｏｌｌＰｅｒｉｏｄエレメント、ＴＤＯエレメント、ａｐｐＩＤエレメント、ａｐｐＴｙｐｅエレメント、ａｐｐＮａｍｅエレメント、ｇｌｏｂａｌＩＤエレメント、ａｐｐＶｅｒｓｉｏｎエレメント、ｃｏｏｋｉｅＳｐａｃｅエレメント、ｆｒｅｑｕｅｎｃｙＯｆＵｓｅエレメント、ｅｘｐｉｒｅＤａｔｅエレメント、ｔｅｓｔＴＤＯエレメント、ａｖａｉｌＩｎｔｅｒｎｅｔエレメント、ａｖａｉｌＢｒｏａｄｃａｓｔエレメント、ＵＲＬエレメント、Ｃａｐａｂｉｌｉｔｉｅｓエレメント、ＣｏｎｔｅｎｔＩｔｅｍエレメント、ＵＲＬエレメント、ｕｐｄａｔｅｓＡｖａｉｌエレメント、ｐｏｌｌＰｅｒｉｏｄエレメント、Ｓｉｚｅエレメント、ａｖａｉｌＩｎｔｅｒｎｅｔエレメント、ａｖａｉｌＢｒｏａｄｃａｓｔエレメント、Ｅｖｅｎｔエレメント、ｅｖｅｎｔＩＤエレメント、ａｃｔｉｏｎエレメント、ｄｅｓｔｉｎａｔｉｏｎエレメント、ｄｉｆｆｕｓｉｏｎエレメント、及び／又はＤａｔａエレメントを含む。

ＴＰＴエレメントはＴＰＴのルートエレメントである。

ＭａｊｏｒＰｒｏｔｏｃｏｌＶｅｒｓｉｏｎエレメントは、テーブルの定義のメジャーバージョン番号を示す。受信機は、自身が支援できないメジャーバージョン番号を有するＴＰＴは廃棄することができる。

ＭｉｎｏｒＰｒｏｔｏｃｏｌＶｅｒｓｉｏｎエレメントは、テーブルの定義のマイナーバージョン番号を示す。受信機は、自身が支援できないマイナーバージョン番号を有するＴＰＴは廃棄しない。この場合、受信機は、自身が支援しない情報又はエレメントは無視することでＴＰＴを処理する。

ｉｄエレメントは、ＵＲＩ形態を有することができ、このＴＰＴと関連する対話型プログラミングセグメント（又は、対話型サービスセグメント）を識別する。このｉｄエレメントは、相応するトリガーの‘ｌｏｃａｔｏｒ_ｐａｒｔ’となり得る。

ｔｐｔＶｅｒｓｉｏｎエレメントは、ｉｄエレメントによって識別されるＴＰＴのバージョン情報を示す。

ｅｘｐｉｒｅＤａｔｅエレメントは、ＴＰＴインスタンスに含まれた情報の満了日及び時間を示す。受信機がＴＰＴを格納している場合、ｅｘｐｉｒｅＤａｔｅエレメントによる日付及び時間までは当該ＴＰＴを再使用することができる。

ｓｅｒｖｉｃｅＩＤエレメントは、ＴＰＴインスタンスで説明される対話型サービスと関連するＮＲＴサービスの識別子を示す。

ｂａｓｅＵＲＬエレメントは、ＴＰＴに現れる関連ＵＲＬの前端に結合されて使用できるベースＵＲＬを示す。ｂａｓｅＵＲＬエレメントは、ファイルの絶対ＵＲＬを示す。

Ｃａｐａｂｉｌｉｔｉｅｓエレメントは、ＴＰＴと関連する対話型サービスを表出するために必須である能力を示す。Ｃａｐａｂｉｌｉｔｉｅｓと関連する情報は、図５で後述する。

ＬｉｖｅＴｒｉｇｇｅｒエレメントは、アクティベーショントリガー（Ａｃｔｉｖａｔｉｏｎ Ｔｒｉｇｇｅｒ）がインターネットを介して提供される場合に使用される情報を含む。ＬｉｖｅＴｒｉｇｇｅｒエレメントは、受信機がアクティベーショントリガーを得るために必要な情報を提供する。

ＵＲＬエレメントは、インターネットでアクティベーショントリガーを伝送するサーバーのＵＲＬを示す。アクティベーショントリガーは、ＨＴＴＰ ｓｈｏｒｔ ｐｏｌｌｉｎｇ、ＨＴＴＰ ｌｏｎｇ ｐｏｌｌｉｎｇまたはＨＴＴＰ ｓｔｒｅａｍｉｎｇを使用するインターネットを介して伝送されてもよい。

ｐｏｌｌＰｅｒｉｏｄエレメントが存在すれば、アクティベーショントリガーを伝送するためにｓｈｏｒｔ ｐｏｌｌｉｎｇが使用されることを示す。ｐｏｌｌＰｅｒｉｏｄエレメントはｐｏｌｌｉｎｇ周期を示す。

ＴＤＯエレメントは、ＴＰＴインスタンスによって説明されるセグメントの間の対話型サービスの一部を提供するアプリケーション（例えば、ＴＤＯ）に関する情報を含む。

ａｐｐＩＤエレメントは、ＴＰＴの範囲内でアプリケーション（例えば、ＴＤＯ）を識別する。アクティベーショントリガーは、ａｐｐＩＤエレメントを用いて、トリガーを適用するためのターゲットアプリケーションを識別する。

ａｐｐＴｙｐｅエレメントは、アプリケーションのフォーマットタイプを識別する。例えば、ａｐｐＴｙｐｅエレメントの値が‘１’にセットされる場合、アプリケーションがＴＤＯであることを示すことができる。

ａｐｐＮａｍｅエレメントは、視聴者のためにディスプレイされる、人間が読めるアプリケーションの名を示す。

ｇｌｏｂａｌＩＤエレメントは、アプリケーションのグローバル識別子を示す。ｇｌｏｂａｌＩＤエレメントが存在する場合、受信機は、アプリケーションコードを格納し、同一または異なる放送局の未来のセグメント内の同じアプリケーションの以降の表出のために当該アプリケーションコードを再使用することができる。

ａｐｐＶｅｒｓｉｏｎエレメントは、アプリケーション（ＴＤＯ）のバージョン番号を示す。

ｃｏｏｋｉｅＳｐａｃｅエレメントは、アプリケーション呼び出し（ｉｎｖｏｃａｔｉｏｎｓ）間において持続的にアプリケーションが必要とするデータを格納するために必要な空間の大きさを示す。

ｆｒｅｑｕｅｎｃｙＯｆＵｓｅエレメントは、放送においてどれぐらい頻繁にアプリケーションが使用されるかに対する概略的な頻度を示す。例えば、ｆｒｅｑｕｅｎｃｙＯｆＵｓｅエレメントは、アプリケーションが時間単位、日単位、週単位、月単位で反復的に使用されるか、またはただ一度だけ使用されるということを示すことができる。

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

ｔｅｓｔＴＤＯエレメントは、アプリケーションがテストの目的で使用されるかどうかを示す。アプリケーションがテストの目的で使用される場合、一般的な受信機は、このアプリケーションを無視することができる。

ａｖａｉｌＩｎｔｅｒｎｅｔエレメントは、アプリケーションをインターネットを介してダウンロードできるか否かを示す。

ａｖａｉｌＢｒｏａｄｃａｓｔエレメントは、アプリケーションを放送信号から抽出できるか否かを示す。

ＵＲＬエレメントは、このエレメントのそれぞれのインスタンスはアプリケーションの一部であるファイルを識別する。１つ以上のインスタンスが存在する場合、最初のインスタンスは、エントリポイント（ｅｎｔｒｙ ｐｏｉｎｔ）であるファイルを指定する。エントリポイントであるファイルは、アプリケーションを実行するために実行されなければならないファイルであり得る。

Ｃａｐａｂｉｌｉｔｉｅｓエレメントは、アプリケーションの意味のある表出のために必須である受信機の能力を示す。Ｃａｐａｂｉｌｉｔｉｅｓと関連する情報は、図５で後述する。

ＣｏｎｔｅｎｔＩｔｅｍエレメントは、アプリケーションが必要とする１つ以上のファイルで構成されたコンテンツアイテムに関する情報を含む。ＵＲＬエレメントは、コンテンツアイテムの一部であるファイルを識別する。ＵＲＬエレメントは、コンテンツアイテムが提供されるＵＲＬ情報を識別することができる。１つ以上のインスタンスが存在する場合、最初のインスタンスは、エントリポイントであるファイルを指定する。

ｕｐｄａｔｅｓＡｖａｉｌエレメントは、コンテンツアイテムがたまにアップデートされるか否かを示す。ｕｐｄａｔｅｓＡｖａｉｌエレメントは、コンテンツアイテムが固定された（ｓｔａｔｉｃ）ファイルで構成されるか否か、リアルタイムデータフィード（ｆｅｅｄ）であるか否かを示すことができる。

ｐｏｌｌＰｅｒｉｏｄエレメントが存在すれば、アクティベーショントリガーを伝送するためにｓｈｏｒｔ ｐｏｌｌｉｎｇが使用されることを示す。ｐｏｌｌＰｅｒｉｏｄエレメントは、受信機がｐｏｌｌｉｎｇ周期として使用する時間を示す。

Ｓｉｚｅエレメントは、コンテンツアイテムの大きさを示す。

ａｖａｉｌＩｎｔｅｒｎｅｔエレメントは、コンテンツアイテムがインターネットを介してダウンロード可能であるか否かを示す。

ａｖａｉｌＢｒｏａｄｃａｓｔエレメントは、コンテンツアイテムが放送信号から抽出可能であるか否を示す。

Ｅｖｅｎｔエレメントは、ＴＤＯのためのイベントに関する情報を含む。

ｅｖｅｎｔＩＤエレメントは、ＴＤＯの範囲内でイベントを識別する役割を担う。アクティベーショントリガーは、トリガーが適用されるターゲットアプリケーション及び／又はイベントをａｐｐＩＤエレメントとｅｖｅｎｔＩＤエレメントとの組み合わせで識別する。

ａｃｔｉｏｎエレメントは、イベントが動作するときに適用されなければならないＴＤＯアクションの種類を示す。図１１のアクション値は、次のような意味を含むことができる。

“ｒｅｇｉｓｔｅｒ”は、可能な場合、アプリケーションのリソースを獲得し、事前格納（ｐｒｅ−ｃａｃｈｅ）することを意味する。

“ｓｕｓｐｅｎｄ−ｅｘｅｃｕｔｅ”は、現在実行されている他のアプリケーションを猶予（又は、中断）させ、現在のアプリケーションを実行することを意味する。ターゲットアプリケーションが猶予された場合、受信機は以前の状態で当該アプリケーションを再開する。

“ｔｅｒｍｉｎａｔｅ−ｅｘｅｃｕｔｅ”は、現在実行されている他のアプリケーションを終了させ、現在のアプリケーションを実行することを意味する。ターゲットアプリケーションが猶予された場合、受信機は以前の状態で当該アプリケーションを再開する。

“ｔｅｒｍｉｎａｔｅ”は、アプリケーションを終了することを意味する。

“ｓｕｓｐｅｎｄ”は、アプリケーションの実行を中断することを意味する。ＵＩ及び／又はアプリケーションエンジン状態は、再び実行される前まで保存されることが要求される。

“ｓｔｒｅａｍ−ｅｖｅｎｔ”は、アプリケーションによって定義される特定の行動を適切に行うようにすることを意味する。ｄｅｓｔｉｎａｔｉｏｎエレメントは、イベントのためのターゲットデバイスタイプを示す。例えば、ｄｅｓｔｉｎａｔｉｏｎエレメントの値に応じて、メインスクリーン或いはセカンダリスクリーンで当該イベントが実行されなければならないことを示したり、または、メインスクリーン及び／又はセカンダリスクリーンで当該イベントが実行されなければならないことを示すことができる。ｄｅｓｔｉｎａｔｉｏｎエレメントは、位置ホルダー（ｐｌａｃｅ ｈｏｌｄｅｒ）として使用することができる。

ｄｉｆｆｕｓｉｏｎエレメントは、サーバーローディングのピークをスムージングするためのパラメータを示す。ｄｉｆｆｕｓｉｏｎエレメントは、周期Ｔを秒単位で示すことができ、受信機は、０秒からＴ秒までの範囲でランダムタイムを計算し、ＴＰＴのＵＲＬによって参照されるコンテンツを得るためにインターネットサーバーにアクセスする前に計算された時間の分だけディレイさせることができる。

Ｄａｔａエレメントは、イベントと関連するデータに関する情報を含む。イベントが動作する場合、ターゲットアプリケーションは、このデータを読み、所望の動作を行うために当該データを使用することができる。

図５は、本発明の一実施例に係るｃａｐａｂｉｌｉｔｉｅｓ_ｄｅｓｃｒｉｐｔｏｒを示す図である。

本発明の一実施例に係るｃａｐａｂｉｌｉｔｉｅｓ_ｄｅｓｃｒｉｐｔｏｒは、ｄｅｓｃｒｉｐｔｏｒ_ｔａｇ情報、ｄｅｓｃｒｉｐｔｏｒ_ｌｅｎｇｔｈ情報、ｃａｐａｂｉｌｉｔｙ_ｃｏｄｅ_ｃｏｕｎｔ情報、ｅｓｓｅｎｔｉａｌ_ｉｎｄｉｃａｔｏｒ情報、ｃａｐａｂｉｌｉｔｙ_ｃｏｄｅ情報、ｆｏｒｍａｔ_ｉｄｅｎｔｉｆｉｅｒ情報、ｃａｐａｂｉｌｉｔｙ_ｓｔｒｉｎｇ_ｃｏｕｎｔ情報、ｅｓｓｅｎｔｉａｌ_ｉｎｄｉｃａｔｏｒ情報、ｃａｐａｂｉｌｉｔｙ_ｃａｔｅｇｏｒｙ_ｃｏｄｅ情報、ｃａｐａｂｉｌｉｔｙ_ｓｔｒｉｎｇ_ｌｅｎｇｔｈ情報、ｃａｐａｂｉｌｉｔｙ_ｓｔｒｉｎｇ（）情報、ｃａｐａｂｉｌｉｔｙ_ｏｒ_ｓｅｔ_ｃｏｕｎｔ情報、ｅｓｓｅｎｔｉａｌ_ｉｎｄｉｃａｔｏｒ情報、ｃａｐａｂｉｌｉｔｙ_ｃｏｄｅｓ_ｉｎ_ｓｅｔ_ｃｏｕｎｔ情報、ｃａｐａｂｉｌｉｔｙ_ｃｏｄｅ情報、ｆｏｒｍａｔ_ｉｄｅｎｔｉｆｉｅｒ情報、ｃａｐａｂｉｌｉｔｙ_ｓｔｒｉｎｇｓ_ｉｎ_ｓｅｔ_ｃｏｕｎｔ情報、ｃａｐａｂｉｌｉｔｙ_ｃａｔｅｇｏｒｙ_ｃｏｄｅ情報、ｃａｐａｂｉｌｉｔｙ_ｓｔｒｉｎｇ_ｌｅｎｇｔｈ情報及び／又はｃａｐａｂｉｌｉｔｙ_ｓｔｒｉｎｇ（）情報を含む。

ｄｅｓｃｒｉｐｔｏｒ_ｔａｇ情報は、このデスクリプタがｃａｐａｂｉｌｉｔｉｅｓ_ｄｅｓｃｒｉｐｔｏｒであることを示す情報である。

ｄｅｓｃｒｉｐｔｏｒ_ｌｅｎｇｔｈ情報は、この情報の後に、このデスクリプタに含まれるデータの長さを示す。

ｃａｐａｂｉｌｉｔｙ_ｃｏｄｅ_ｃｏｕｎｔ情報は、ｃａｐａｂｉｌｉｔｙ_ｃｏｄｅ情報の数を示す。

ｅｓｓｅｎｔｉａｌ_ｉｎｄｉｃａｔｏｒ情報は、対話型サービスまたはコンテンツアイテムの意味のある表出のために、ｃａｐａｂｉｌｉｔｙ_ｃｏｄｅ情報によって識別される能力（ｃａｐａｂｉｌｉｔｙ）の支援が必須であるか否かを示す。

ｃａｐａｂｉｌｉｔｙ_ｃｏｄｅ情報は、特定の能力を識別する情報である。例えば、ｃａｐａｂｉｌｉｔｙ_ｃｏｄｅ情報は、その値に応じて、ダウンロードプロトコル、ＦＥＣアルゴリズム、Ｗｒａｐｐｅｒ／Ａｒｃｈｉｖｅフォーマット、圧縮アルゴリズム、メディアタイプに関する能力を識別するのに使用することができる。例えば、ｃａｐａｂｉｌｉｔｙ_ｃｏｄｅ情報は、ダウンロードプロトコルはＦＬＵＴＥプロトコルが使用されることを示すことができる、例えば、ｃａｐａｂｉｌｉｔｙ_ｃｏｄｅ情報は、ＦＥＣアルゴリズムはＦＥＣ ｓｃｈｅｍｅが使用されないか、またはＲａｐｔｏｒアルゴリズムが使用されることを示すことができる。例えば、ｃａｐａｂｉｌｉｔｙ_ｃｏｄｅ情報は、圧縮アルゴリズムはＤＥＦＬＡＴＥアルゴリズムが使用されることを示すことができる。例えば、ｃａｐａｂｉｌｉｔｙ_ｃｏｄｅ情報は、メディアタイプがＡＶＣ標準画質ビデオ、ＡＶＣ高画質ビデオ、ＡＣ−３オーディオ、Ｅ−ＡＣ−３オーディオ、ＭＰ３オーディオ、ＡＶＣモバイルビデオ、ＨＥ ＡＡＣ ｖ２モバイルオーディオ、ＨＥ ＡＡＣ ｖ２ ｌｅｖｅｒ４オーディオ、ＤＴＳ−ＨＤオーディオ、ＣＦＦ−ＴＴ、ＣＥＡ−７０８キャプション及び／又はＭＰＥＧ ｓｕｒｒｏｕｎｄが適用されたＨＥ ＡＡＣ ｖ２であることを示すことができる。

ｆｏｒｍａｔ_ｉｄｅｎｔｉｆｉｅｒ情報は、ＩＳＯ／ＩＥＣ １３８１８−１のセクション２．６．９においてｒｅｇｉｓｔｒａｔｉｏｎ_ｄｅｓｃｒｉｐｔｏｒ（）のために定義された内容と同一である。

ｃａｐａｂｉｌｉｔｙ_ｓｔｒｉｎｇ_ｃｏｕｎｔ情報は、ｃａｐａｂｉｌｉｔｙ_ｓｔｒｉｎｇ（）情報の数を示す。

ｅｓｓｅｎｔｉａｌ_ｉｎｄｉｃａｔｏｒ情報は、対話型サービス又はコンテンツアイテムの意味のある表出のために、この情報に後続するｃａｐａｂｉｌｉｔｙ ｓｔｒｉｎｇに関する情報による能力（ｃａｐａｂｉｌｉｔｙ）の支援が必須であるか否かを示す。

ｃａｐａｂｉｌｉｔｙ_ｃａｔｅｇｏｒｙ_ｃｏｄｅ情報は、この情報に後続するストリング（ｓｔｒｉｎｇ）値のための能力カテゴリー（ｃａｐａｂｉｌｉｔｙ ｃａｔｅｇｏｒｙ）を示す。例えば、ｃａｐａｂｉｌｉｔｙ_ｃａｔｅｇｏｒｙ_ｃｏｄｅ情報は、ダウンロードプロトコル、ＦＥＣアルゴリズム、ｗｒａｐｐｅｒ／ａｒｃｈｉｖｅフォーマット、圧縮アルゴリズムまたはメディアタイプに関する能力カテゴリーに対するものであることを示すことができる。

ｃａｐａｂｉｌｉｔｙ_ｓｔｒｉｎｇ_ｌｅｎｇｔｈ情報は、ｃａｐａｂｉｌｉｔｙ_ｓｔｒｉｎｇ（）情報の長さを示す。

ｃａｐａｂｉｌｉｔｙ_ｓｔｒｉｎｇ（）情報は、能力（ｃａｐａｂｉｌｉｔｙ）に関する情報を含む。ｃａｐａｂｉｌｉｔｙ_ｓｔｒｉｎｇ（）情報は、ｃａｐａｂｉｌｉｔｙ_ｃａｔｅｇｏｒｙ_ｃｏｄｅ情報によって識別されたカテゴリーの能力に関する情報を含む。

ｃａｐａｂｉｌｉｔｙ_ｏｒ_ｓｅｔ_ｃｏｕｎｔ情報は、能力‘ＯＲ ｓｅｔ’の数を示す。

ｅｓｓｅｎｔｉａｌ_ｉｎｄｉｃａｔｏｒ情報は、対話型サービス又はコンテンツアイテムの意味のある表出のために、この情報に後続する能力‘ＯＲ ｓｅｔ’による能力（ｃａｐａｂｉｌｉｔｙ）の支援が必須であるか否かを示す。

ｃａｐａｂｉｌｉｔｙ_ｃｏｄｅｓ_ｉｎ_ｓｅｔ_ｃｏｕｎｔ情報は、能力セット内のｃａｐａｂｉｌｉｔｙ_ｃｏｄｅ情報の数を示す。

ｃａｐａｂｉｌｉｔｙ_ｃｏｄｅ情報は、特定の能力を識別する情報である。例えば、ｃａｐａｂｉｌｉｔｙ_ｃｏｄｅ情報は、その値に応じて、ダウンロードプロトコル、ＦＥＣアルゴリズム、Ｗｒａｐｐｅｒ／Ａｒｃｈｉｖｅフォーマット、圧縮アルゴリズム、メディアタイプに関する能力を識別するのに使用することができる。例えば、ｃａｐａｂｉｌｉｔｙ_ｃｏｄｅ情報は、ダウンロードプロトコルはＦＬＵＴＥプロトコルが使用されることを示すことができる、例えば、ｃａｐａｂｉｌｉｔｙ_ｃｏｄｅ情報は、ＦＥＣアルゴリズムはＦＥＣ ｓｃｈｅｍｅが使用されないか、またはＲａｐｔｏｒアルゴリズムが使用されることを示すことができる。例えば、ｃａｐａｂｉｌｉｔｙ_ｃｏｄｅ情報は、圧縮アルゴリズムはＤＥＦＬＡＴＥアルゴリズムが使用されることを示すことができる。例えば、ｃａｐａｂｉｌｉｔｙ_ｃｏｄｅ情報は、メディアタイプがＡＶＣ標準画質ビデオ、ＡＶＣ高画質ビデオ、ＡＣ−３オーディオ、Ｅ−ＡＣ−３オーディオ、ＭＰ３オーディオ、ＡＶＣモバイルビデオ、ＨＥ ＡＡＣ ｖ２モバイルオーディオ、ＨＥ ＡＡＣ ｖ２ ｌｅｖｅｒ４オーディオ、ＤＴＳ−ＨＤオーディオ、ＣＦＦ−ＴＴ、ＣＥＡ−７０８キャプション及び／又はＭＰＥＧ ｓｕｒｒｏｕｎｄが適用されたＨＥ ＡＡＣ ｖ２であることを示すことができる。

ｆｏｒｍａｔ_ｉｄｅｎｔｉｆｉｅｒ情報は、ＩＳＯ／ＩＥＣ １３８１８−１のセクション２．６．９においてｒｅｇｉｓｔｒａｔｉｏｎ_ｄｅｓｃｒｉｐｔｏｒ（）のために定義された内容と同一である。

ｃａｐａｂｉｌｉｔｙ_ｓｔｒｉｎｇｓ_ｉｎ_ｓｅｔ_ｃｏｕｎｔ情報は、能力セット内のｃａｐａｂｉｌｉｔｙ_ｓｔｒｉｎｇ情報の数を示す。

ｃａｐａｂｉｌｉｔｙ_ｃａｔｅｇｏｒｙ_ｃｏｄｅ情報は、この情報に後続するストリング（ｓｔｒｉｎｇ）値のための能力カテゴリー（ｃａｐａｂｉｌｉｔｙ ｃａｔｅｇｏｒｙ）を示す。例えば、ｃａｐａｂｉｌｉｔｙ_ｃａｔｅｇｏｒｙ_ｃｏｄｅ情報は、ダウンロードプロトコル、ＦＥＣアルゴリズム、ｗｒａｐｐｅｒ／ａｒｃｈｉｖｅフォーマット、圧縮アルゴリズムまたはメディアタイプに関する能力カテゴリーに対するものであることを示すことができる。

ｃａｐａｂｉｌｉｔｙ_ｓｔｒｉｎｇ_ｌｅｎｇｔｈ情報は、この情報に後続するｃａｐａｂｉｌｉｔｙ_ｓｔｒｉｎｇ（）情報の長さを示す。

ｃａｐａｂｉｌｉｔｙ_ｓｔｒｉｎｇ（）情報は、能力（ｃａｐａｂｉｌｉｔｙ）に関する情報を含む。ｃａｐａｂｉｌｉｔｙ_ｓｔｒｉｎｇ（）情報は、ｃａｐａｂｉｌｉｔｙ_ｃａｔｅｇｏｒｙ_ｃｏｄｅ情報によって識別されたカテゴリーの能力に関する情報を含む。

ｃａｐａｂｉｌｉｔｉｅｓ_ｄｅｓｃｒｉｐｔｏｒは、前述したＴＰＴのエレメント又はデスクリプタが含まれ得る領域を介して伝送されてもよい。

図６は、本発明の一実施例に係るアクティベーションメッセージテーブル（Ａｃｔｉｖａｔｉｏｎ Ｍｅｓｓａｇｅ Ｔａｂｌｅ；ＡＭＴ）を示す図である。

アクティベーションメッセージテーブルは、ｍａｊｏｒＰｒｏｔｏｃｏｌＶｅｒｓｉｏｎエレメント、ｍｉｎｏｒＰｒｏｔｏｃｏｌＶｅｒｓｉｏｎエレメント、ｓｅｇｍｅｎｔｅｄエレメント、ｂｅｇｉｎＭＴエレメント、Ａｃｔｉｖａｔｉｏｎエレメント、ｔａｒｇｅｔＴＤＯエレメント、ｔａｒｇｅｔＥｖｅｎｔエレメント、ｓｔａｒｔＴｉｍｅエレメント、及び／又はｅｎｄＴｉｍｅエレメントを含むことができる。

ｍａｊｏｒＰｒｏｔｏｃｏｌＶｅｒｓｉｏｎエレメントは、ＡＭＴ定義のメジャーバージョン番号を示す。受信機は、支援しないメジャーバージョン番号を示すＡＭＴのインスタンスは廃棄することができる。

ｍｉｎｏｒＰｒｏｔｏｃｏｌＶｅｒｓｉｏｎエレメントは、ＡＭＴ定義のマイナーバージョン番号を示す。受信機は、支援しないマイナーバージョン番号を示すＡＭＴのインスタンスを廃棄しなくてもよい。この場合、受信機は、ＡＭＴに含まれた支援しない個々のエレメントまたは成分を無視することができる。

ｓｅｇｍｅｎｔｅｄエレメントは、ＴＤＯ及び／又はＡＭＴのアクティベーションが適用されるイベントを含むＴＰＴの識別子とマッチングされ得、ＡＭＴの識別子として使用することができる。

ｂｅｇｉｎＭＴエレメントは、ＡＭＴインスタンスが提供するアクティベーションタイムが適用されるセグメントの開始メディアタイム（ｂｅｇｉｎｎｉｎｇ ｍｅｄｉａ ｔｉｍｅ）を示す。

Ａｃｔｉｖａｔｉｏｎエレメントは、特定の時間に特定のイベントの動作のためのコマンドを示す。

ｔａｒｇｅｔＴＤＯエレメントは、アクティベーションコマンドが適用されるイベントのためのターゲットＴＤＯを識別する。

ｔａｒｇｅｔＥｖｅｎｔエレメントは、ターゲットＴＤＯの範囲内で、アクティベーションコマンドが適用されるターゲットイベントを識別する。

ｓｔａｒｔＴｉｍｅエレメントは、メディアタイムと関連するイベントのための有効なタイム期間の開始を示す。受信機は、メディアタイムがｓｔａｒｔＴｉｍｅエレメントの値に到達する場合、コマンドを実行することができる。

ｅｎｄＴｉｍｅエレメントは、メディアタイムと関連するイベントのための有効なタイム期間の終わりを示す。受信機は、メディアタイムがｅｎｄＴｉｍｅエレメントの値に到達する場合、コマンドを実行しなくてもよい。

図７は、本発明の一実施例に係るトリガーフォーマットを示す図である。

アクティベーションメッセージ（又は、アクティベーショントリガー）とタイムベースメッセージ（又は、タイムベーストリガー）は、特定の伝送環境で一般的なトリガーフォーマットに従うことができる。

図７の（ａ）は、一般的なトリガーのフォーマットを示す図である。

＜ｄｏｍａｉｎ ｎａｍｅ ｐａｒｔ＞は、登録されたドメインネームを示すことができる。＜ｄｉｒｅｃｔｏｒｙ ｐａｔｈ＞は、ＵＲＩで表現できる経路（ｐａｔｈ）を示す。＜ｄｏｍａｉｎ ｎａｍｅ ｐａｒｔ＞及び＜ｄｉｒｅｃｔｏｒｙ ｐａｒｔ＞のいずれか１つ、または＜ｄｏｍａｉｎ ｎａｍｅ ｐａｒｔ＞及び＜ｄｉｒｅｃｔｏｒｙ ｐａｒｔ＞の組み合わせは、現在のセグメントのためのＴＰＴを獲得できるインターネット上のアドレスまたは位置のＵＲＬとして使用することができる。＜ｐａｒａｍｅｔｅｒｓ＞は、“ｅｖｅｎｔ_ｔｉｍｅ”、“ｍｅｄｉａ_ｔｉｍｅ”、または“ｓｐｒｅａｄ”の要素のうちの１つ以上を含むことができる。

図７の（ｂ）は、“ｅｖｅｎｔ_ｔｉｍｅ”、“ｍｅｄｉａ_ｔｉｍｅ”、“ｓｐｒｅａｄ”の要素を示す形式の一例である。

“ｅｖｅｎｔ_ｔｉｍｅ”要素は、アクティベーションメッセージ内で、ターゲットイベント（“ｅ＝”の形式使用）を識別したり、または当該イベントが動作しなければならない時間（“ｔ＝”の形式使用）を識別することができる。“ｔ＝”の形式が存在しない場合、当該イベントは、アクティベーションメッセージが到着する時間に動作しなければならないことを示すことができる。

“ｍｅｄｉａ_ｔｉｍｅ”要素は、タイムベースメッセージ内で、タイムベースメッセージによって表現されるタイムベース（ｔｉｍｅ ｂａｓｅ）と関連している現在の時間を識別することができる。

“ｓｐｒｅａｄ”要素は、タイムベースメッセージによって行われた動作（例えば、サーバーからＴＰＴを受信すること）を識別したり、またはアクティベーションメッセージによって行われた動作（例えば、ＴＤＯがサーバーに接続するようにすること）が、サーバーのワークロード（ｗｏｒｋｌｏａｄ）を分散させるために、ランダム（ｒａｎｄｏｍ）な時間の間に遅延されなければならないことを示すことができる。

トリガーは、放送ストリームで伝達され得る。

トリガーは、放送ストリームで伝達されると、ＣＥＡ−７０８．２ ＤＴＶクローズドキャプション対話型ＴＶ拡張子（ＣＥＡ−７０８．２ ＤＴＶ Ｃｌｏｓｅｄ Ｃａｐｔｉｏｎｉｎｇ： Ｉｎｔｅｒａｃｔｉｖｅ Ｔｅｌｅｖｉｓｉｏｎ Ｅｘｔｅｎｓｉｏｎｓ）に明示されたように、ＵＲＬＳｔｒｉｎｇ命令語でＤＴＶクローズドキャプションチャネルで伝達され得る。トリガーの長さが２６文字以下であれば、当該トリガーは分割されずに伝送され得る（Ｔｙｐｅ＝１１）。トリガーの長さが２７〜５２であれば、当該トリガーは２つのセグメントで伝送され得る（１番目のセグメントは、Ｔｙｐｅ＝００セグメントであり、２番目のセグメントは、Ｔｙｐｅ＝１０セグメントである）。

ＴＤＯモデルを利用する対話型サービスに対して、ＵＲＩ_ｄａｔａ（）構造でのＵＲＩ_ｔｙｐｅフィールドは０に設定することができる（ＴＤＯモデルに対する対話型ＴＶトリガー）。直接実行（ｄｉｒｅｃｔ ｅｘｅｃｕｔｉｏｎ）モデルを利用する対話型サービスに対して、ＵＲＩ_ｔｙｐｅフィールドは２に設定することができる（直接実行モデルに対する対話型ＴＶトリガー）。

この伝達メカニズムは、タイムベーストリガーとアクティベーションベーストリガーの両方を含む。

アクティベーションメッセージは、放送ストリームで伝送されてもよい。この場合、トリガーのフォーマットは、“ｅ＝”の形式を含むが、“ｔ＝”の形式は含んでも含まなくてもよい。このとき、当該トリガーは、クローズドキャプション（ｃｌｏｓｅｄ ｃａｐｔｉｏｎ）サービス領域を介して伝送されてもよい。すなわち、放送ストリーム内でクローズドキャプションサービスを伝送するチャネルを介してトリガーが伝送されてもよい。“ｔ＝”の形式が存在する場合、アクティベーションタイムは、タイムベースと関連しているタイムスタンプ（ｔｉｍｅｓｔａｍｐ）である。“ｔ＝”の形式が存在しない場合、アクティベーションタイムは、メッセージが到着する時間である。

タイムベースメッセージは、放送ストリームで伝送されてもよい。この場合、トリガーのフォーマットは、“ｍ＝”の形式を含んでも含まなくてもよい。“ｍ＝”の形式は、メディアタイムを示す形式である。このとき、タイムベースメッセージは、クローズドキャプション（ｃｌｏｓｅｄ ｃａｐｔｉｏｎ）サービス領域を介して伝送されてもよい。すなわち、放送ストリーム内でクローズドキャプションサービスを伝送するチャネルを介してタイムベースメッセージが伝送されてもよい。“ｍ＝”の形式がタイムベースメッセージに含まれていない場合、タイムベースメッセージは、シグナリングサーバーのＵＲＬを伝送する用途に使用することができる。“ｍ＝”の形式がタイムベースメッセージに含まれていない場合、“ｔ＝”の形式がアクティベーションメッセージに含まれなくてもよい。

アクティベーションメッセージは、インターネットを介して伝達されてもよい。アクティベーションメッセージは、インターネットを介して伝達される場合、次のメカニズムのいずれか一方または両方を用いて伝達されてもよい。第一に、個別アクティベーショントリガーが伝達され得る。個別アクティベーショントリガーは、インターネットを介して伝達される場合、ＨＴＴＰ ｓｈｏｒｔ ｐｏｌｌｉｎｇ、ＨＴＴＰ ｌｏｎｇ ｐｏｌｌｉｎｇまたはＨＴＴＰ ｓｔｒｅａｍｉｎｇを用いて伝達されてもよい。アクティベーショントリガーのフォーマットは、アクティベーショントリガーが放送ストリームを通じて伝達される場合と同一である。第二に、バルク（ｂｕｌｋ）アクティベーショントリガーが伝達され得る。アクティベーショントリガーがインターネットを介して大量に伝達されると、１つのセグメントに対するアクティベーショントリガーは、１番目のパートがＴＰＴであり、２番目のパートがＡＭＴであるマルチパートＭＩＭＥメッセージの形態で、当該セグメントに対してＴＰＴと共にＨＴＴＰを介して伝達され得る。

アクティベーショントリガーのインターネット伝達が可能であれば、ＴＰＴにおいてＬｉｖｅＴｒｉｇｇｅｒエレメントのＵＲＬ属性は、アクティベーショントリガーを伝達できるアクティベーショントリガーサーバーを示す。ＴＰＴにＬｉｖｅＴｒｉｇｇｅｒエレメントのｐｏｌｌＰｅｒｉｏｄ属性が存在すれば、これは、ＨＴＴＰ ｓｈｏｒｔ ｐｏｌｌｉｎｇが使用中であることを示し、またそれは、受信機が使用しなければならないｐｏｌｌｉｎｇ周期を示す。ＴＰＴにＬｉｖｅＴｒｉｇｇｅｒエレメントのｐｏｌｌＰｅｒｉｏｄ属性が存在しなければ、これは、ＨＴＴＰ ｌｏｎｇ ｐｏｌｌｉｎｇまたはＨＴＴＰ ｓｔｒｅａｍｉｎｇが使用中であることを示す。

どのプロトコルが使用されるかに関係なく、受信機は、クエリ用語“？ｍｔ＝＜ｍｅｄｉａ_ｔｉｍｅ＞”（＜ｍｅｄｉａ_ｔｉｍｅ＞は、視聴するコンテンツの現在のメディアタイム）でアクティベーショントリガーサーバーにＨＴＴＰ要求を発行すると予想される。

ｓｈｏｒｔ ｐｏｌｌｉｎｇが使用中であれば、アクティベーショントリガーサーバーからの応答は、＜ｍｅｄｉａ_ｔｉｍｅ＞に終了するｐｏｌｌＰｅｒｉｏｄの長さの時間間隔内で発行された全てのトリガーを含むことができる。１つより多いアクティベーショントリガーがリターンされる場合、それらは１つ以上のホワイトスペース文字によって分離できる。アクティベーショントリガーがリターンされない場合、応答は空いていてもよい。

ＴＴＰ ｌｏｎｇ ｐｏｌｌｉｎｇまたはＨＴＴＰ ｓｔｒｅａｍｉｎｇが使用中であれば、アクティベーショントリガーサーバーは、アクティベーショントリガーが放送ストリームで伝達されるメディアタイムまで、応答をリターンすることを待機することができる。このとき、それはアクティベーショントリガーをリターンすることができる。

ＨＴＴＰ ｌｏｎｇ ｐｏｌｌｉｎｇが使用中であれば、アクティベーショントリガーサーバーは、アクティベーショントリガーをリターンした後、セッションを終えることができる。受信機は、アップデートされたメディアタイムでまた他の要求を直ちに発行すると予想される。

ＨＴＴＰ ｓｔｒｅａｍｉｎｇが使用中であれば、アクティベーショントリガーサーバーは、各アクティベーショントリガーをリターンした後、セッションをオープン状態に維持することができ、伝達される時間に到達すると、当該セッションにわたって追加でアクティベーショントリガーを伝達することができる。

いずれの場合においても、ＨＴＴＰ応答は、伝達モードをシグナリングするために、次の形態のいずれか１つのＨＴＴＰ応答ヘッダーフィールドを含むことができる：

ATSC-Delivery-Mode:ShortPolling[<poll-period>]

ATSC-Delivery-Mode:LongPolling

ATSC-Delivery-Mode:Streaminｇ

＜ｐｏｌｌ−ｐｅｒｉｏｄ＞パラメータは、次のポール（ｐｏｌｌ）においてポール間の推奨間隔を示すことができる。

ＡＣＲ（Ａｕｔｏｍａｔｉｃ Ｃｏｎｔｅｎｔ Ｒｅｃｏｇｎｉｔｉｏｎ）の放送受信機に適用される場合、アクティベーションメッセージはインターネットを介して伝送されてもよい。この場合、トリガーのフォーマットは、“ｅ＝”の形式を含むことができ、“ｔ＝”の形式は含んでも含まなくてもよい。トリガーフォーマットは、ＨＴＴＰ ｓｈｏｒｔ ｐｏｌｌｉｎｇ、ｌｏｎｇ ｐｏｌｌｉｎｇまたはｓｔｒｅａｍｉｎｇを用いて伝送されてもよい。または、トリガーフォーマットは、ファイルの形態でＨＴＴＰを介して伝送されてもよい。

タイムベースメッセージはインターネットを介して伝送されてもよい。ＡＣＲ環境において、放送受信機は、放送ストリームに含まれたクローズドキャプションサービスに接近できない。この状況では、受信機がビデオフレームを認識し、ビデオフレームとタイムベースの同期（ｓｙｎｃｈｒｏｎｉｚａｔｉｏｎ）を取る必要がある。したがって、ＡＣＲ環境でタイムベースメッセージがインターネットを介して伝送され得る。この場合、タイムベースメッセージは、ＡＣＲサーバーから応答の形態で伝送されてもよい。または、タイムベースメッセージは、ウォーターマーク（透かし）（ｗａｔｅｒｍａｒｋｓ）から獲得されてもよい。

セグメントのためのサービス生成のプロセスを通じて、ＴＤＯ及び他のコンテンツアイテムを含むフォルダー、ＸＭＬフォーマットのＴＰＴファイル、及び／又はＸＭＬフォーマットのアクティベーションメッセージファイル（Ａｃｔｉｖａｔｉｏｎ Ｍｅｓｓａｇｅ Ｆｉｌｅ：ＡＭＦ、あるいはアクティベーションメッセージテーブル（ＡＭＴ）と呼ぶことができる）が生成されてもよい。

タイムベースメッセージ及びアクティベーションメッセージがクローズドキャプションサービスを介して伝送される場合、放送局がタイムベースメッセージ及びアクティベーションメッセージを処理できる方法には、明確なタイムベースがないセグメントモード、明確なタイムベースがあるセグメントモード、または明確なタイムベースがあるサービスモードが存在し得る。このようなモードは、放送内でセグメント単位で混在して存在し得る。

明確なタイムベースがないセグメントモードにおいて、アクティベーションメッセージは、各メッセージのアクティベーションタイムがメッセージの伝達時間となるようにタイムスタンプを含まず、タイムベースメッセージも唯一の目的がＴＰＴファイルを伝達し得るシグナリングサーバーのＵＲＬを提供するものとなるようにタイムスタンプを含まない。このモードでは、シグナリングサーバーのＵＲＬを提供するように、アクティベーションメッセージでのＵＲＬに依存しながらタイムベースメッセージが完全に省略されてもよい。しかし、そのような場合、受信機は、最初のアクティベーションメッセージが登場した後まで、ＴＰＴの検索及びＴＤＯのダウンロードの開始を実行することができないため、最初のアクティベーションメッセージに対する応答が非常に遅延する。

この場合、ＣＣサービスに登場するタイムベースメッセージは、“Ｔｒｉｇｇｅｒ”フォーマットの“ｌｏｃａｔｏｒ_ｐａｒｔ”を含み、“ｓｐｒｅａｄ”項は含んでもよいが、“ｍｅｄｉａ_ｔｉｍｅ”項は含まず、ＣＣサービス＃６に登場するアクティベーションメッセージは、“Ｔｒｉｇｇｅｒ”フォーマットの“ｌｏｃａｔｏｒ_ｐａｒｔ”及び“ｅｖｅｎｔ_ｔｉｍｅ”項を含み、“ｓｐｒｅａｄ”項は含んでもよいが、“ｅｖｅｎｔ_ｔｉｍｅ”項において“ｔ＝”パートは含まない。タイムベースメッセージ及びアクティベーションメッセージの“ｌｏｃａｔｏｒ_ｐａｒｔ”は現在のｓｅｇｍｅｎｔＩｄである。このＵＲＬは、インターネットを介して当該セグメントに対するＴＰＴを検索するために使用されてもよい。

明確なタイムベースがあるセグメントモードにおいて、タイムベースメッセージは、タイムベースを定義するためにタイムスタンプを含み、アクティベーションメッセージは、タイムベースに比例するアクティベーションタイムを定義するためにタイムスタンプを含むことができる。または、それらは、アクティベーションタイムがメッセージの到着時間であることを示すタイムスタンプを含まなくてもよい。

この場合、ＣＣサービスに登場するタイムベースメッセージは、“Ｔｒｉｇｇｅｒ”フォーマットの“ｌｏｃａｔｏｒ_ｐａｒｔ”及び“ｍｅｄｉａ_ｔｉｍｅ”項を含み、“ｓｐｒｅａｄ”項は含んでもよく、ＣＣサービスに登場するアクティベーションメッセージは、“Ｔｒｉｇｇｅｒ”フォーマットの“ｌｏｃａｔｏｒ_ｐａｒｔ”及び“ｅｖｅｎｔ_ｔｉｍｅ”項を含み、“ｓｐｒｅａｄ”項は含んでもよく、“ｅｖｅｎｔ_ｔｉｍｅ”項において“ｔ＝”パートは含んでも含まなくてもよい。タイムベースメッセージ及びアクティベーションメッセージの“ｌｏｃａｔｏｒ_ｐａｒｔ”は現在のｓｅｇｍｅｎｔＩｄであり、タイムベースはセグメントに限定される。このＵＲＬは、インターネットを介して当該セグメントに対するＴＰＴを検索するために使用されてもよい。

明確なタイムベースがあるサービスモードにおいて、タイムベースメッセージは、タイムベースを定義するためにタイムスタンプを含み、アクティベーションメッセージは、タイムスタンプを含んでも含まなくてもよい。タイムベースは、単一のセグメントに限定されるよりは、多数のセグメントにわたって拡張される。タイムベースメッセージの“ｌｏｃａｔｏｒ_ｐａｒｔ”は、タイムベースの識別子であり、インターネットを介してサービスに対するＴＰＴを検索するために使用できるＵＲＬでもある。

いずれの場合においても、トリガーをＣＣサービスに挿入するトリガー挿入サーバーは、ＡＭＦから動作して、アクティベーションメッセージをＡＭＦにあるＸＭＬフォーマットからＣＣサービスにおいて伝達に対して指定したトリガーフォーマットに変換しなければならない。ｅｎｄＴｉｍｅ属性を有しないアクティベーションエレメントの場合、１つのトリガーがｓｔａｒｔＴｉｍｅ属性と同じアクティベーションタイムをもって挿入されなければならない。ｓｔａｒｔＴｉｍｅエレメント及びｅｎｄＴｉｍｅエレメントの両方を有するアクティベーションエレメントの場合、トリガーのシーケンスが同一のｔａｒｇｅｔＩｄ値をもって挿入されなければならない。シーケンスにおいて最初のトリガーは、ｓｔａｒｔＴｉｍｅ属性と同じアクティベーションタイムを有しなければならず、シーケンスにおいて最後のトリガーは、ｅｎｄＴｉｍｅ属性と同じアクティベーションタイムを有しなければならず、シーケンスにおいてトリガーのアクティベーションタイム間には一定の時間間隔が存在しなければならない（シーケンスでは、最後から２番目のトリガーと最後のトリガーとの間の間隔はさらに短くてもよい）。この一定の時間間隔の長さは設定可能でなければならない。

タイムベースメッセージ及びアクティベーションメッセージがセグメントモードにあれば、タイムベースはセグメントに限定的である。それは、セグメントの開始時に“ｂｅｇｉｎＭＴ”値を持って始まり、セグメントを通じて行われる。個別アクティベーションの“ｓｔａｒｔＴｉｍｅ”値及び“ｅｎｄＴｉｍｅ”値は“ｂｅｇｉｎＭＴ”値に比例する。タイムベースメッセージ及びアクティベーションメッセージがサービスモードにあれば、タイムベースはセグメントにわたっており、各セグメントに対する“ｂｅｇｉｎＭＴ”値は、サービスタイムベース及び放送スケジュールを勘案するために調整される。

タイムベースメッセージ及び／又はアクティベーションメッセージはインターネットを介して伝達されてもよい。

インターネットを介してタイムベースメッセージ及びアクティベーションメッセージを伝達する必要がある唯一の時は、受信機がＣＣサービスに接続していない状況、例えば、ＡＣＲ状況である。この場合、タイムベースメッセージはＡＣＲサーバーから伝達されてくる。アクティベーションメッセージは、ｓｈｏｒｔ ｐｏｌｌｉｎｇ、ｌｏｎｇ ｐｏｌｌｉｎｇまたはｓｔｒｅａｍｉｎｇを通じて伝達されてもよいが、これらはいずれも受信機及びサーバーに多くのオーバーヘッドを加える。アクティベーションメッセージは、ＡＭＦの形態で伝達されてもよいが、これは、セグメントの長さに対する多量の情報を提供し、広告キラーを容易にする。他の代案があり得る。

ＴＰＴは放送を介して伝達されてもよい。

放送を介した伝達のために、ＴＰＴは、ＸＭＬフォーマットから同等のバイナリフォーマットに変換された後、テーブルインスタンス当たり１つずつ放送を介した伝達のためのＮＲＴ形式のテーブルインスタントに圧縮される。現在のセグメントに対するＴＰＴは常に存在する。１つ以上の未来のセグメントに対するＴＰＴも存在し得る。

ＴＰＴはインターネットを介して伝達されてもよい。

ＴＰＴは、インターネットを介して伝達される場合、個別ファイル又はマルチパートＭＩＭＥメッセージの部分として伝達される。要求に対する応答は、常に現在のセグメントに対するＴＰＴを含む。それは、１つ以上の未来のセグメントに対するＴＰＴも含むことができる。

ＴＤＯ及びコンテンツアイテムのロケータ（ｌｏｃａｔｏｒ）は移動されてもよい。

ネットワーク及びステーションは、ＴＤＯ及びＴＤＯによって使用されるコンテンツアイテム（ファイル）を伝達するための自身のＨＴＴＰサーバーを提供する必要が頻繁にあり得る。これが実行されると、ＴＰＴにあるｂａｓｅＵＲＬはサーバーの位置を反映するために調節されてもよい。

多数のセグメントが１つのセグメントに結合することができる。

セグメント間の境界を徹底的に曖昧にするために、多数のセグメントに対するＴＰＴ及びＡＭＦは１つのＴＰＴ及びＡＭＦに結合することができる。これを実行するために要求される段階は、次の通りである。

１．結合するセグメントの集合を確認する。

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

３．結合するセグメントのいずれか１つでもライブアクティベーションを有していれば、それらの全てに対する接近を提供するリレーサーバーを提供し、このサーバーに対するパラメータを“ＬｉｖｅＴｒｉｇｇｅｒ”エレメントに置く。

４．フル（ｆｕｌｌ）ＴＤＯ及びＣｏｎｔｅｎｔＩｔｅｍ ＵＲＬを得るために、必要時に各セグメントに対するｂａｓｅＵＲＬを適用する。（結合する全てのセグメントに共通するより短いｂａｓｅＵＲＬを確認し、それを結合セグメントに対するｂａｓｅＵＲＬとして保有することができる。）

５．衝突を除去するために、必要時にａｐｐＩｄ値を変更する。

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

７．結合したＴＰＴの新しいｓｅｇｍｅｎｔＩｄと同じｓｅｇｍｅｎｔＩｄで新しいＡＭＦを生成する。

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

９．ａｐｐＩｄ値の全ての変化を反映するために結合したセグメントに対するＡＭＦにある全てのアクティベーションエレメントのｔａｒｇｅｔＩｄ値を調節する。

１０．結合したセグメントに対する放送スケジュール及び新しい“ｂｅｇｉｎＭＴ”値を反映するために結合したセグメントに対するＡＭＦにある全てのアクティベーションエレメントのｓｔａｒｔＴｉｍｅ値及びｅｎｄＴｉｍｅ値を調節する。

１１．変更された全てのアクティベーションエレメントを新しいＡＭＦに挿入する。

図８は、本発明の一実施例に係るＴＰＴ要求に対する応答の一つの部分であるＵＲＬ情報を提供するＸＭＬ ｓｃｈｅｍｅを示す図である。

ＴＰＴは、放送ストリームを介して伝送されてもよい。ＴＰＴが放送ストリームを介して伝送される場合、バイナリフォーマット（ｂｉｎａｒｙ ｆｏｒｍａｔ）に変更されて伝送されてもよい。ＴＰＴが放送ストリームを介して伝送される場合、ＮＲＴ伝送方式に従って伝送され得る。ＴＰＴがＮＲＴ形式で伝送される場合、ＴＰＴは、テーブルセクション当たり１つのＴＰＴが含まれるＮＲＴ形式のプライベートセクションに圧縮することができる。この場合、ＮＲＴプライベートセクション内のｓｕｂｎｅｔ_ｉｄフィールドは、サービスシグナリングチャネル（Ｓｅｒｖｉｃｅ Ｓｉｇｎａｌｉｎｇ Ｃｈａｎｎｅｌ；ＳＳＣ）内の他のテーブルインスタンスを区分するためのシーケンス（ｓｅｑｕｅｎｃｅ）番号として使用することができる。

ＴＰＴは、インターネットを介して伝送されてもよい。ＴＰＴがインターネットを介して伝送される場合、ＴＰＴはＨＴＴＰを介して伝送され得る。現在のセグメントのためのＴＰＴのＵＲＬは、タイムベースメッセージ内の＜ｄｏｍａｉｎ ｎａｍｅ ｐａｒｔ＞及び／又は＜ｄｉｒｅｃｔｏｒｙ ｐａｔｈ＞で識別することができる。受信機は、ＴＰＴを提供するサーバーに、ＴＰＴの伝送を要求することができる。ＴＰＴの伝送要求に対する応答は、ＴＰＴのみで構成されてもよく、または２−ｐａｒｔ ＭＩＭＥメッセージを含む形態で伝送されてもよい。２−ｐａｒｔ ＭＩＭＥメッセージの１番目のパートは要求したＴＰＴが含まれてもよく、２−ｐａｒｔ ＭＩＭＥメッセージの２番目のパートはＵＲＬのリストを含むことができる。このようなＵＲＬのリストを、図８に示したようなＸＭＬドキュメントの形態で伝送することができる。

ＸＭＬ形態のＵＲＬのリストは、ＵｒｌＬｉｓｔエレメント、ＴｐｔＵｒｌエレメント、及び／又はＮｒｔＳｉｇｎａｌｉｎｇＵｒｌエレメントを含むことができる。

ＵｒｌＬｉｓｔエレメントは、受信機で使用可能なＵＲＬのリストを含む。

ＴｐｔＵｒｌエレメントは、未来のセグメントのためのＴＰＴを提供するＵＲＬを含む。複数のＴｐｔＵｒｌエレメントが含まれた場合、放送内のセグメントの順序に従って当該ＴｐｔＵｒｌエレメントが割り当てられてもよい。

ＮｒｔＳｉｇｎａｌｉｎｇＵｒｌエレメントは、受信機が現在の放送ストリーム内の仮想チャネルのためのＮＲＴシグナリングテーブルを獲得することができるサーバーのＵＲＬを含む。

図９は、本発明の他の実施例に係るＴＰＴ要求に対する応答の一つの部分であるＵＲＬ情報を提供するＸＭＬ ｓｃｈｅｍｅを示す図である。

放送局は、現在、各受信機が視聴又は消耗している放送コンテンツの種類及び好むデータ放送などの情報を活用して、放送を通じたビジネスに活用することができる。この場合、受信機は、各受信機で消耗される放送コンテンツのようなユーザの選好度と関連する情報を特定のサーバーに伝送する必要がある。したがって、受信機に提供されるＵＲＬ情報内のＵＲＬ Ｌｉｓｔエレメントに、Ｕｓａｇｅ ＲｅｐｏｒｔｉｎｇのためのＳｅｒｖｅｒのＵＲＬを知らせるエレメントが追加されなければならない。

ＵＲＬリストは、対話型サービスを示す受信機に潜在的に使用される特定のＵＲＬを含む。ＵＲＬリストは、１つ以上の未来のセグメントに対するＴＰＴの少なくとも１つのＵＲＬ、放送ストリームでの独立型ＮＲＴサービスに関する情報が検索され得るＮＲＴシグナリングサーバーのＵＲＬ、使用報告が受信される使用報告サーバーのＵＲＬを含むことができる。

ＵＲＬリストは、ＸＭＬスキーマにおいてスキーマ定義に従う“ＵｒｌＬｉｓｔ”エレメントを含むＸＭＬ文書であってもよい。

ＵＲＬリストエレメントのＸＭＬスキーマは、ＵｒｌＬｉｓｔエレメント、ＴｐｔＵｒｌエレメント、及び／又はＮｒｔＳｉｇｎａｌｉｎｇＵｒｌエレメントを含む。

ＵｒｌＬｉｓｔエレメントは、受信機に有用なＵＲＬのリストを含む。

ＵｒｌＬｉｓｔエレメントのＴｐｔＵｒｌエレメントは、未来のセグメントに対するＴＰＴのＵＲＬを含むことができる。多数のＴｐｔＵｒｌエレメントが含まれる場合、それらは、放送でのセグメントの出現順に配列されてもよい。

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

ＵｒｌＬｉｓｔエレメントのＵｒｓＵｒｌエレメントは、受信機が当該アプリケーションに記述された特定のプロトコルを用いて使用（例えば、視聴率調査）報告を送信し得るサーバーのＵＲＬを含むことができる。

本発明の一実施例として、ＵｓｒＵｒｌエレメントに含まれる情報はＵｓａｇｅ Ｒｅｐｏｒｔｉｎｇ ＳｅｒｖｅｒのＵＲＬを含むことができる。この場合、受信機は、予め定められたプロトコル（例、ｄａｔａ ｓｔｒｕｃｔｕｒｅ、ＸＭＬ ｆｉｌｅなど）によって、この情報によるＵｓａｇｅ Ｒｅｐｏｒｔｉｎｇ Ｓｅｒｖｅｒに受信機のＵｓａｇｅ Ｒｅｐｏｒｔｉｎｇを行うことができる。

本発明の他の実施例として、ＵｓｒＵｒｌエレメントに含まれる情報は、受信機のウェブブラウザーで実行されるＴＤＯを識別することもできる。この場合、ＵｓｒＵｒｌエレメントは、Ｕｓａｇｅ Ｒｅｐｏｒｔｉｎｇ ＴＤＯの位置を知らせ、ＴＤＯが直接、受信機のウェブブラウザーのＡＰＩ（例えば、Ｆｉｌｅ ＡＰＩｓ、Ｕｓａｇｅ Ｒｅｐｏｒｔｉｎｇ ＡＰＩｓ）を用いて受信機に格納された又は現在消耗している放送コンテンツの情報を収集して報告することができる。すなわち、ＴＤＯを通じてＵｓａｇｅ Ｒｅｐｏｒｔｉｎｇが行われてもよい。一実施例として、ＴＤＯは、独自にＸＭＬＨｔｔｐＲｅｑｕｅｓｔというＪａｖａｓｃｒｉｐｔ ＡＰＩを活用して、収集されたデータを特定のサーバーに伝送することができる。

図１０は、本発明の一実施例に係るトリガーのシンタックスを示す図である。

放送局は、ユーザに、対話型付加データサービス（又は、対話型放送サービス／コンテンツ）を２つのモデルの形態で提供することができる。それらのうちの一方がＴＤＯ（Ｔｒｉｇｇｅｒｅｄ Ｄｅｃｌａｒａｔｉｖｅ Ｏｂｊｅｃｔ）モデルであり、他方がＤｉｒｅｃｔ Ｅｘｅｃｕｔｉｏｎ ｍｏｄｅｌである。

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

直接実行モデルでは、仮想チャネルが選択されると直ちにＤＯ（Ｄｅｃｌａｒａｔｉｖｅ Ｏｂｊｅｃｔ）が自動で開始される。それは、バックエンド（ｂａｃｋｅｎｄ）サーバーと“Ｓｙｎｃｈｒｏｎｉｚｅｄ Ｃｏｎｔｅｎｔ Ｐｒｏｔｏｃｏｌ”を介してインターネットで通信する。当該サーバーは、スクリーン上の特定の位置にディスプレイを生成し、ポールを実行し、他の専門的なＴＯを開始するなどの対話型特徴を提供するための詳細命令語を提供し、これは全てオーディオ−ビデオプログラムに同期化される。（近い将来に“Ｓｙｎｃｈｒｏｎｉｚｅｄ Ｃｏｎｔｅｎｔ Ｐｒｏｔｏｃｏｌ”は特定の放送局に所有権があるが、これから標準化され得る。）

当該セクションのほとんどは、ＴＤＯモデルに対するシグナリングを扱っているが、直接実行モデルに対するＤＯを開始するために必要なシグナリングも含むことができる。

ＴＤＯモデルの基本概念は、ＴＤＯを構成するファイル及びアクションを取るためにＴＤＯによって使用されるデータファイルはいずれも、その大きさを考慮したとき、受信機に伝達されるにはある程度の時間が要求されるということである。対話型エレメントのユーザ経験がコンテンツの放送前に作られ得る一方、特定の行為はプログラム自体のイベント、例えば、商業広告セグメントの発生と同時に起こるように注意深く調節しなければならない。

ＴＤＯモデルは、ＤＯ及び関連しているデータ、スクリプト、テキスト、グラフィックの伝達を、対話型イベントの再生の特定タイミングのシグナリングから分離する。

図９を参照して、トリガーに対する構文（ｓｙｎｔａｘ）を説明する。前述したように、アクティベーションメッセージ及びタイムベースメッセージは両方とも、特定の伝達状況で一般的な“Ｔｒｉｇｇｅｒ”フォーマットを有することができる。バーティカルバー記号“｜”が他の代案を指定するために使用される点以外は、ここでの構文定義は、ＡＢＮＦ（Ａｕｇｍｅｎｔｅｄ Ｂａｃｋｕｓ−Ｎａｕｒ Ｆｏｒｍ）文法を用いて記述される。規則は、等号“＝”によって定義及び分離され、１つより多いラインを通じて規則の定義を続けるために字下げ（ｉｎｄｅｎｔａｔｉｏｎ）が用いられ、リテラル（ｌｉｔｅｒａｌ）は“”で引用され、括弧“（“ 及び ”）”は、エレメントをグループ化するために用いられ、選択的なエレメントは、括弧“［“ 及び ”］”の中に入れ、次のエレメントのｎ以上の反復を指定するために＜ｎ＞＊がエレメントに先行することができる（ｎは、０にデフォルトされる）。また、次のエレメントのｎ以上の反復及びｍ以下の反復を指定するために、＜ｎ＞＊＜ｍ＞がエレメントに先行することができる。当該トリガー構文は、＜ｓｃｈｅｍｅ＞及び“：／／”部分を除外した絶対的ＵＲＩに基づく。

トリガーは、ｌｏｃａｔｏｒ_ｐａｒｔ及びｔｅｒｍｓを含むことができる。ｔｅｒｍｓは省略されてもよい。ｔｅｒｍｓが存在すれば、ｌｏｃａｔｏｒ_ｐａｒｔ及びｔｅｒｍｓは‘？’により連結することができる。

ｌｏｃａｔｏｒ_ｐａｒｔは、ｈｏｓｔｎａｍｅ部分及びｐａｔｈ_ｓｅｇｍｅｎｔｓ部分を含むことができ、これらは‘／’により連結することができる。

ｈｏｓｔｎａｍｅは、ｄｏｍａｉｎｌａｂｅｌ及びｔｏｐｌａｂｅｌを含むことができ、ｄｏｍａｉｎｌａｂｅｌは‘．’と共に０回以上繰り返すことができる。すなわち、ｈｏｓｔｎａｍｅは、ｔｏｐｌａｂｅｌが連結された反復されたｄｏｍａｉｎｌａｂｅｌを含むこともでき、ｔｏｐｌａｂｅｌのみを含むこともできる。

ｄｏｍａｉｎｌａｂｅｌは、１つのａｌｐｈａｎｕｍを含むか、または、ａｌｐｈａｎｕｍとａｌｐｈａｎｕｍとの間に０回以上反復的に挿入されたａｌｐｈａｎｕｍ又は“−”を含むことができる。

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

ここで、ａｌｐｈａは、ｌｏｗａｌｐｈａまたはｕｐａｌｐｈａであってもよい。

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

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

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

ｔｏｐｌａｂｅｌは、１つのａｌｐｈａを含むか、または、ａｌｐｈａとａｌｐｈａｎｕｍとの間に０回以上反復的に挿入されたａｌｐｈａｎｕｍ又は“−”を含む。

ｐａｔｈ_ｓｅｇｍｅｎｔｓは、１つのセグメントを含み、ここには０回以上反復されるセグメントが後続する。このとき、セグメントは‘／’で連結することができる。

ここで、セグメントは、１回以上反復されるａｌｐｈａｎｕｍを含む。

ｔｅｒｍｓは、ｅｖｅｎｔ_ｔｉｍｅ又はｍｅｄｉａ_ｔｉｍｅを含むことができ、ここにはｓｐｒｅａｄ又はｏｔｈｅｒｓが後続することができる。ｓｐｒｅａｄ及びｏｔｈｅｒｓは省略可能である。ｓｐｒｅａｄ及びｏｔｈｅｒｓが存在すれば、‘＆’がｓｐｒｅａｄ及びｏｔｈｅｒｓの前に置かれてもよく、ｓｐｒｅａｄ及びｏｔｈｅｒｓは、ｅｖｅｎｔ_ｔｉｍｅ又はｍｅｄｉａ_ｔｉｍｅの後に置かれてもよい。

ここで、ｓｐｒｅａｄは、‘ｓ＝’の後に１回以上反復されるｄｉｇｉｔを含むことができる。

ｅｖｅｎｔ_ｔｉｍｅは、‘ｅ＝’の後に１回以上反復されるｄｉｇｉｔを含むか、または‘＆ｔ＝’の後に１回以上又は７回以下反復されるｈｅｘｄｉｇｉｔを含むことができる。‘＆ｔ＝’及びその後ろのパートは省略可能である。

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

ｍｅｄｉａ_ｔｉｍｅは、‘ｍ＝’の後に１回以上又は７回未満反復されるｈｅｘｄｉｇｉｔを含むことができる。

ｏｔｈｅｒｓは、１つの“ｏｔｈｅｒ”、または、‘＆’及び“ｏｔｈｅｒ”が続く“ｏｔｈｅｒ”を含むことができる。

ここで、ｏｔｈｅｒｓは、１回以上反復され、‘＝’により連結されるａｌｐｈａｎｕｍ及びｒｅｓｖ_ｃｍｄを含むことができる。

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

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

トリガーは、３つの部分で構成されていると見なすことができる。

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

＜ｄｏｍａｉｎ ｎａｍｅ ｐａｒｔ＞は登録されたドメインネームであってもよく、＜ｄｉｒｅｃｔｏｒｙ ｐａｔｈ＞はＵＲＩにおいて現れる経路であってもよい。

＜ｄｏｍａｉｎ ｎａｍｅ ｐａｒｔ＞は、登録されたインターネットドメインネームを示す。＜ｄｉｒｅｃｔｏｒｙ ｐａｔｈ＞は、確認されたドメインネームに対する権限を有する主体の制御及び管理下でディレクトリ経路を識別する任意の文字列である。

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

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

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

すなわち、トリガーは、＜ｄｏｍａｉｎ ｎａｍｅ ｐａｒｔ＞及び＜ｄｉｒｅｃｔｏｒｙ ｐａｔｈ＞を用いてＴＰＴを識別することができる。＜ｄｏｍａｉｎ ｎａｍｅ ｐａｒｔ＞及び＜ｄｉｒｅｃｔｏｒｙ ｐａｔｈ＞を通じて、トリガーが適用されるＴＰＴを確認することができる。トリガーをＴＰＴに適用することによって実行される役割は＜ｐａｒａｍｅｔｅｒｓ＞に依存する。

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

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

次に、図４に示した構文の“ｅｖｅｎｔ_ｔｉｍｅ”、“ｍｅｄｉａ_ｔｉｍｅ”、“ｓｐｒｅａｄ”について説明する。

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

media_time =“m=”1*7hexdigit

spread =“s=”1*digit

“ｅｖｅｎｔ_ｔｉｍｅ”項は、ターゲットイベント（“ｅ＝”項）及びイベントが活性化されるべき時間（“ｔ＝”項）を識別するためにアクティベーショントリガーにおいて使用され得る。“ｔ＝”項が存在しなければ、これは、トリガーが到着する時にイベントが活性化されなければならないことを意味する。

すなわち、対話型イベントＩＤ項である“ｅ＝”は、イベントがターゲットとするＴＤＯの関連ＴＰＴでのａｐｐＩＤ、特定イベントのｅｖｅｎｔＩＤ、当該イベント活性化に使用されるｄａｔａエレメントのｄａｔａＩＤを示すことができる。

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

“ｍｅｄｉａ_ｔｉｍｅ”項（“ｍ＝”項）は、タイムベーストリガーによって示されるタイムベースに比例する現在時間を識別するためにタイムベーストリガーにおいて使用することができる。現在表示されるコンテンツを識別するコンテンツ識別子情報（“ｃ＝”項）は、ｍｅｄｉａ_ｔｉｍｅにさらに含まれてもよい。“ｃ＝”項について、直接実行モデルを以下に説明する。

すなわち、ｍｅｄｉａ ｔｉｍｅｓｔａｍｐ項であって、１６進数を示す長さが１〜８文字である文字列が続く“ｍ＝”は、現在のメディアタイムを示すことができる。

“ｓｐｒｅａｄ”項は、タイムベーストリガー（サーバーからＴＰＴを検索するなど）又はアクティベーショントリガー（ＴＤＯがサーバーに接続するようにするなど）に対して取る全てのアクションが、サーバーに加わる負荷を分散するために任意の時間の間に遅延されなければならないことを示すために使用することができる。

“ｓ＝”項は、全ての受信機がトリガーで識別されるインターネットサーバーに接続を試みるべき秒単位の時間を示すことができる。各個別受信機は、指定された区間内に任意の時間を誘導し、接続要求を該当する量だけ遅延させることによって、そうしないと受信機でトリガーの初出現時に発生し得る需要の多いピークを適時に分散すると予想することができる。

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

＜ｅｖｅｎｔ ｔｉｍｅ＞パラメータを含むトリガーは、イベントに対するアクティベーションタイムを設定することから、アクティベーショントリガーと呼ぶことができる。

図１１は、本発明の一実施例に係るバイナリフォーマット（ｂｉｎａｒｙ ｆｏｒｍａｔ）のＴＰＴの一部を示す図である。

図１２は、本発明の一実施例に係るバイナリフォーマットのＴＰＴの他の一部を示す図である。

図１３は、本発明の一実施例に係るバイナリフォーマットのＴＰＴの更に他の一部を示す図である。

図１４は、本発明の一実施例に係るバイナリフォーマットのＴＰＴの更に他の一部を示す図である。

図１５は、本発明の一実施例に係るバイナリフォーマットのＴＰＴの更に他の一部を示す図である。

すなわち、図１１乃至図１５は、本発明の一実施例に係るバイナリフォーマットのＴＰＴの全体の構造を示す。

ＴＰＴは、放送ストリームで伝達される場合、バイナリＮＲＴ形式のシグナリングテーブルフォーマットに変換され、テーブルインスタンス当たり１つのＴＰＴずつＮＲＴ形式のプライベートセクションに圧縮される。ＮＲＴプライベートセクション構文のｓｕｂｎｅｔ_ｉｄフィールドは、サービスシグナリングチャネルにおいて互いに異なるテーブルインスタントを区別するためにシーケンス番号として使用される。

図３及び図４に既に記述されたＴＰＴ内のエレメントあるいは情報のうち、一部のエレメントあるいは情報はバイナリフォーマットのＴＰＴから省略されてもよい。この場合、省略されるエレメントあるいは情報は、放送ストリーム内でバイナリフォーマットのＴＰＴの伝送のためのヘッダーで圧縮されて伝送されてもよい。例えば、ｍａｊｏｒ／ｍｉｎｏｒ ｐｒｏｔｏｃｏｌＶｅｒｓｉｏｎエレメント、ｓｅｒｖｉｃｅｄエレメント、及び／又はｔｐｔＶｅｒｓｉｏｎエレメントは、バイナリフォーマットのＴＰＴでは省略可能な情報に該当する。

バイナリフォーマットのＴＰＴは、ｅｘｐｉｒｅ_ｄａｔｅ_ｉｎｃｌｕｄｅｄフィールド、ｓｅｇｍｅｎｔ_ｉｄ_ｌｅｎｇｔｈフィールド、ｓｅｇｍｅｎｔ_ｉｄフィールド、ｂａｓｅ_ＵＲＬ_ｌｅｎｇｔｈフィールド、ｂａｓｅ_ＵＲＬフィールド、ｅｘｐｉｒｅ_ｄａｔｅフィールド、ｔｒｉｇｇｅｒ_ｓｅｒｖｅｒ_ＵＲＬ_ｌｅｎｇｔｈフィールド、ｔｒｉｇｇｅｒ_ｓｅｒｖｅｒ_ＵＲＬフィールド、ｔｒｉｇｇｅｒ_ｄｅｌｉｖｅｒｙ_ｔｙｐｅフィールド、ｐｏｌｌ_ｐｅｒｉｏｄフィールド、ｎｕｍ_ａｐｐｓ_ｉｎ_ｔａｂｌｅフィールド、ａｐｐ_ｉｄフィールド、ａｐｐ_ｔｙｐｅ_ｉｎｃｌｕｄｅｄフィールド、ａｐｐ_ｎａｍｅ_ｉｎｃｌｕｄｅｄフィールド、ｇｌｏｂａｌ_ｉｄ_ｉｎｃｌｕｄｅｄフィールド、ａｐｐ_ｖｅｒｓｉｏｎ_ｉｎｃｌｕｄｅｄフィールド、ｃｏｏｋｉｅ_ｓｐａｃｅ_ｉｎｃｌｕｄｅｄフィールド、ｆｒｅｑｕｅｎｃｙ_ｏｆ_ｕｓｅ_ｉｎｃｌｕｄｅｄフィールド、ｅｘｐｉｒｅ_ｄａｔｅ_ｉｎｃｌｕｄｅｄフィールド、ａｐｐ_ｔｙｐｅフィールド、ａｐｐ_ｎａｍｅ_ｌｅｎｇｔｈフィールド、ａｐｐ_ｎａｍｅフィールド、ｇｌｏｂａｌ_ｉｄ_ｌｅｎｇｔｈフィールド、ｇｌｏｂａｌ_ｉｄフィールド、ａｐｐ_ｖｅｒｓｉｏｎフィールド、ｃｏｏｋｉｅ_ｓｐａｃｅフィールド、ｆｒｅｑｕｅｎｃｙ_ｏｆ_ｕｓｅフィールド、ｅｘｐｉｒｅ_ｄａｔｅフィールド、ｔｅｓｔ_ａｐｐフィールド、ａｖａｉｌａｂｌｅ_ｏｎ_ｉｎｔｅｒｎｅｔフィールド、ａｖａｉｌａｂｌｅ_ｉｎ_ｂｒｏａｄｃａｓｔフィールド、ｎｕｍｂｅｒ_ＵＲＬｓフィールド、ＵＲＬ_ｌｅｎｇｔｈフィールド、ＵＲＬフィールド、ｎｕｍｂｅｒ_ｃｏｎｔｅｎｔ_ｉｔｅｍｓフィールド、ｕｐｄａｔｅｓ_ａｖａｉｌフィールド、ａｖａｉｌ_ｉｎｔｅｒｎｅｔフィールド、ａｖａｉｌ_ｂｒｏａｄｃａｓｔフィールド、ｃｏｎｔｅｎｔ_ｓｉｚｅ_ｉｎｃｌｕｄｅｄフィールド、ｎｕｍｂｅｒ_ＵＲＬｓフィールド、ＵＲＬ_ｌｅｎｇｔｈフィールド、ＵＲＬフィールド、ｃｏｎｔｅｎｔ_ｓｉｚｅフィールド、ｎｕｍ_ｃｏｎｔｅｎｔ_ｄｅｓｃｒｉｐｔｏｒｓフィールド、ｃｏｎｔｅｎｔ_ｄｅｓｃｒｉｐｔｏｒ（）フィールド、ｎｕｍｂｅｒ_ｅｖｅｎｔｓフィールド、ｅｖｅｎｔ_ｉｄフィールド、ａｃｔｉｏｎフィールド、ｄｅｓｔｉｎａｔｉｏｎ_ｉｎｃｌｕｄｅｄフィールド、ｄｉｆｆｕｓｉｏｎ_ｉｎｃｌｕｄｅｄフィールド、ｄａｔａ_ｉｎｃｌｕｄｅｄフィールド、ｄｅｓｔｉｎａｔｉｏｎフィールド、ｄｉｆｆｕｓｉｏｎフィールド、ｄａｔａ_ｓｉｚｅフィールド、ｄａｔａ_ｂｙｔｅｓフィールド、ｎｕｍ_ａｐｐ_ｄｅｓｃｒｉｐｔｏｒｓフィールド、ａｐｐ_ｄｅｓｃｒｉｐｔｏｒ（）フィールド、ｎｕｍ_ＴＰＴ_ｄｅｓｃｒｉｐｔｏｒｓフィールド、及び／又はＴＰＴ_ｄｅｓｃｒｉｐｔｏｒ（）フィールドを含む。

ｅｘｐｉｒｅ_ｄａｔｅ_ｉｎｃｌｕｄｅｄフィールドは、ｅｘｐｉｒｅ_ｄａｔｅフィールドが含まれるか否かを示すことができる。‘１’の値は含まれたことを示し、‘０’の値は含まれていないことを示す。

ｓｅｇｍｅｎｔ_ｉｄ_ｌｅｎｇｔｈフィールドは、ｓｅｇｍｅｎｔ_ｉｄフィールドのバイト単位の長さを示すことができる。

ｓｅｇｍｅｎｔ_ｉｄフィールドは、ＴＰＴ ＸＭＬフォーマットの“ｉｄ”属性と同じセマンティックス（ｓｅｍａｎｔｉｃ）を有することができるｓｅｇｍｅｎｔ ｉｄのバイトを含むことができる。

ｂａｓｅ_ＵＲＬ_ｌｅｎｇｔｈフィールドは、ｂａｓｅ_ＵＲＬフィールドのバイト長を示すことができる。

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

ｅｘｐｉｒｅ_ｄａｔｅフィールドは、存在する場合、ＴＰＴに含まれた情報の満了日及び時間を示すことができる。受信機がＴＰＴをキャッシュに格納すると、それはｅｘｐｉｒｅＤａｔｅまで再使用することができる。符号なし整数は、ＡＴＳＣ ＰＳＩＰ標準（ＰＳＩＰ）に定義されたように、１９８０年１月６日００：００：００ ＵＴＣ以後のＧＰＳ秒単位時間マイナスＧＰＳ−ＵＴＣ_ｏｆｆｓｅｔと解釈することができる。

ｔｒｉｇｇｅｒ_ｓｅｒｖｅｒ_ＵＲＬ_ｌｅｎｇｔｈフィールドは、ｔｒｉｇｇｅｒ_ｓｅｒｖｅｒ_ＵＲＬフィールドのバイト長を示すことができる。当該フィールドの値が０であれば、これは、個別アクティベーショントリガーのインターネット伝達が不可能であることを示すことができる。

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

ｔｒｉｇｇｅｒ_ｄｅｌｉｖｅｒｙ_ｔｙｐｅフィールドは、インターネット上の個別アクティベーショントリガーの伝達モードを示すことができる。‘０’の値は、ＨＴＴＰ ｓｈｏｒｔ ｐｏｌｌｉｎｇが使用中であることを示すことができる。‘１’の値は、ＨＴＴＰ ｌｏｎｇ ｐｏｌｌｉｎｇ又はＨＴＴＰ ｓｔｒｅａｍｉｎｇが使用中であることを示すことができる。

ｐｏｌｌ_ｐｅｒｉｏｄフィールドは、ＨＴＴＰ ｓｈｏｒｔ ｐｏｌｌｉｎｇが使用中の場合、ポール間の推奨される秒数を示すことができる。

ｎｕｍ_ａｐｐｓ_ｉｎ_ｔａｂｌｅフィールドは、ＴＰＴインスタントに記述されたアプリケーション（ＴＤＯ）の数を示すことができる。

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

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

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

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

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

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

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

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

ａｐｐ_ｔｙｐｅフィールドは、存在する場合、当該アプリケーションのフォーマットタイプを示すことができる。“０”の値は、アプリケーションが当該標準の当該バージョンでの仕様に従うＴＤＯということを示すことができる。当該フィールドが存在しない場合、値が０にデフォルトされ得る。他のフォーマットを示す他の値は、当該標準の将来のバージョンで定義することができる。

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

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

ｇｌｏｂａｌ_ｉｄ_ｌｅｎｇｔｈフィールドは、存在する場合、その直後にくるｇｌｏｂａｌ_ｉｄフィールドのバイト長を示すことができる。当該フィールドに対する０の値は、当該アプリケーションに対してｇｌｏｂａｌ_ｉｄフィールドが存在しないことを示す。

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

ａｐｐ_ｖｅｒｓｉｏｎフィールドは、存在する場合、ＴＰＴ ＸＭＬフォーマットでのＴＤＯエレメントのａｐｐＶｅｒｓｉｏｎ属性と同じセマンティックスを有することができる。

ｃｏｏｋｉｅ_ｓｐａｃｅフィールドは、存在する場合、ＴＰＴ ＸＭＬフォーマットでのＴＤＯエレメントのｃｏｏｋｉｅＳｐａｃｅ属性と同じセマンティックスを有することができる。

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

ｅｘｐｉｒｅ_ｄａｔｅフィールドは、存在する場合、ＴＰＴ ＸＭＬフォーマットでのＴＤＯエレメントのｅｘｐｉｒｅＤａｔｅ属性と同じセマンティックスを有することができる。

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

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

ａｖａｉｌａｂｌｅ_ｉｎ_ｂｒｏａｄｃａｓｔフィールドは、当該アプリケーションが放送を介して利用可能であるか否かを示す。‘１’の値は、それが放送を介して利用可能であることを示し、‘０’の値は、それが放送を介して利用不可能であることを示す。

ｎｕｍｂｅｒ_ＵＲＬｓフィールドは、当該アプリケーションを含むファイルの数を示すことができる。

ＵＲＬ_ｌｅｎｇｔｈフィールドは、それに後続するＵＲＬフィールドの長さを示すことができる。

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

ｎｕｍｂｅｒ_ｃｏｎｔｅｎｔ_ｉｔｅｍｓフィールドは、当該アプリケーションによる使用のためにダウンロードされるコンテンツアイテムの数を示すことができる。

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

ａｖａｉｌ_ｉｎｔｅｒｎｅｔフィールドは、当該コンテンツアイテムを含むファイルをインターネットを介してダウンロードできるか否かを示す。‘１’の値は、それをインターネットを介してダウンロードできることを意味することができる。‘０’の値は、ダウンロードできないことを意味することができる。

ａｖａｉｌ_ｂｒｏａｄｃａｓｔフィールドは、当該コンテンツアイテムを含むファイルを放送を介してダウンロードできるか否かを示す。‘１’の値は、それを放送を介してダウンロードできることを意味することができる。‘０’の値は、ダウンロードできないことを意味することができる。

ｃｏｎｔｅｎｔ_ｓｉｚｅ_ｉｎｃｌｕｄｅｄフィールドは、当該アプリケーションに対してｃｏｎｔｅｎｔ_ｓｉｚｅフィールドが含まれるか否かを示す。‘１’の値は含まれることを意味し、‘０’の値は含まれないことを意味する。

ｎｕｍｂｅｒ_ＵＲＬｓフィールドは、当該コンテンツアイテムを含むファイルの数を示すことができる。

ＵＲＬ_ｌｅｎｇｔｈフィールドは、それに後続するＵＲＬフィールドの長さを示すことができる。

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

ｃｏｎｔｅｎｔ_ｓｉｚｅフィールドは、存在する場合、ＴＰＴ ＸＭＬフォーマットでのＴＤＯエレメントのＣｏｎｔｅｎｔＩｔｅｍ下位エレメントのｃｏｎｔｅｎｔＳｉｚｅ属性と同じセマンティックスを有することができる。

ｎｕｍ_ｃｏｎｔｅｎｔ_ｄｅｓｃｒｉｐｔｏｒｓフィールドは、その直後にくる記述語（ｄｅｓｃｒｉｐｔｏｒ）ループでのコンテンツ記述語の数を示すことができる。

ｃｏｎｔｅｎｔ_ｄｅｓｃｒｉｐｔｏｒ（）フィールドは、ＭＰＥＧ−２システム標準［１３８１８−１］に明示されたように、ＭＰＥＧ−２記述語フォーマット（タグ、長さ、データ）に従う記述語であってもよい。それは、当該コンテンツアイテムに関する付加情報を提供することができる。当該記述語ループに含まれ得る記述語のうちのＣａｐａｂｉｌｉｔｉｅｓ記述語は、当該コンテンツアイテムの意味のある表出に必要な受信機能力を示す。

ｎｕｍｂｅｒ_ｅｖｅｎｔｓフィールドは、当該ＴＤＯに対して定義されたイベントの数を示すことができる。

ｅｖｅｎｔ_ｉｄフィールドは、当該イベント（ｎｕｍｂｅｒ_ｅｖｅｎｔｓループの反復で記述されたイベント）に対する識別子を含むことができる。それは、当該アプリケーションの範囲内で唯一である。当該イベントは、ａｐｐ_ｉｄとｅｖｅｎｔ_ｉｄの組み合わせによってアクティベーショントリガー内で参照される。

ａｃｔｉｏｎフィールドはＴＰＴ ＸＭＬフォーマットでのＴＤＯエレメントのＥｖｅｎｔ下位エレメントのａｃｔｉｏｎ属性と同じセマンティックスを有することができる。

ｄｅｓｔｉｎａｔｉｏｎ_ｉｎｃｌｕｄｅｄフィールドは、ｄｅｓｔｉｎａｔｉｏｎフィールドが当該イベントに対して含まれるか否かを示すことができる。‘１’の値は含まれることを示すことができる。‘０’の値は含まれないことを示すことができる。

ｄｉｆｆｕｓｉｏｎ_ｉｎｃｌｕｄｅｄフィールドは、ｄｉｆｆｕｓｉｏｎフィールドが当該イベントに対して含まれるか否かを示すことができる。‘１’の値は含まれることを示すことができる。‘０’の値は含まれないことを示すことができる。

ｄａｔａ_ｉｎｃｌｕｄｅｄフィールドは、ｄａｔａ_ｓｉｚｅフィールド及びｄａｔａ_ｂｙｔｅｓフィールドが当該イベントに対して含まれるか否かを示すことができる。‘１’の値は含まれることを示すことができる。‘０’の値は含まれないことを示すことができる。

ｄｅｓｔｉｎａｔｉｏｎフィールドは、存在する場合、ＴＰＴ ＸＭＬフォーマットでのＴＤＯエレメントのＥｖｅｎｔ下位エレメントのｄｅｓｔｉｎａｔｉｏｎ属性と同じセマンティックスを有することができる。

ｄｉｆｆｕｓｉｏｎフィールドは、存在する場合、ＴＰＴ ＸＭＬフォーマットでのＴＤＯエレメントのＥｖｅｎｔ下位エレメントのｄｉｆｆｕｓｉｏｎ属性と同じセマンティックスを有することができる。

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

存在する場合、ｄａｔａ_ｂｙｔｅｓフィールドは、当該イベントに関連するデータを提供することができる。イベントが活性化される度に、ターゲットアプリケーションはデータを読み取り、所望のアクションを実行するのに助けとなるように使用することができる。当該フィールドが未処理バイナリ値を含み、ＴＰＴ ＸＭＬフォーマットでのＤａｔａエレメントがバイナリ値のｂａｓｅ６４エンコーディングを含むことを除いて、当該フィールドのコンテンツは、ＴＰＴ ＸＭＬフォーマットでの当該ＴＤＯエレメントの当該Ｅｖｅｎｔ下位エレメントの当該Ｄａｔａ下位エレメントのコンテンツと同一であってもよい。

ｎｕｍ_ａｐｐ_ｄｅｓｃｒｉｐｔｏｒｓフィールドは、その直後にくる記述語ループでの記述語の数を示すことができる。

ａｐｐ_ｄｅｓｃｒｉｐｔｏｒ（）フィールドは、ＭＰＥＧ−２システム標準［１３８１８−１］に明示されたように、ＭＰＥＧ−２記述語フォーマット（タグ、長さ、データ）に従う記述語であってもよい。それは、当該アプリケーション（ＴＤＯ）に関する付加情報を提供することができる。当該記述語ループに含まれ得る記述語のうちのＡＴＳＣ ＮＲＴ標準［ＮＲＴ］のセクション８．３に定義されたＣａｐａｂｉｌｉｔｉｅｓ記述語は、当該アプリケーションの意味のある表出に必要な受信機能力を示す。

ｎｕｍ_ＴＰＴ_ｄｅｓｃｒｉｐｔｏｒｓフィールドは、その直後にくる記述語ループで記述語の数を示すことができる。

ＴＰＴ_ｄｅｓｃｒｉｐｔｏｒ（）フィールドは、ＭＰＥＧ−２システム標準［１３８１８−１］に明示されたように、ＭＰＥＧ−２記述語フォーマット（タグ、長さ、データ）に従う記述語であってもよい。それは、当該ＴＰＴに関する付加情報を提供することができる。当該記述語ループに含まれ得る記述語のうちのＡＴＳＣ ＮＲＴ標準［ＮＲＴ］のセクション８．３に定義されたＣａｐａｂｉｌｉｔｉｅｓ記述語は、当該ＴＰＴによって示される対話型サービスの意味のある表出に必要な受信機能力を示す。

図１６は、本発明の一実施例に係るＴＰＴセクションの構造を示す。

ＴＰＴが放送ストリームで伝達されると、バイナリフォーマットのＴＰＴが各ＴＰＴインスタントに使用され得る（ＴＰＴインスタントは、そのｓｅｇｍｅｎｔ_ｉｄフィールドの値によって定義される）。各ＴＰＴをブロックに分離し、ブロックを共通値ｔａｂｌｅ_ｉｄを有するセクションのｔｐｔ_ｂｙｔｅｓ（）フィールド、ｐｒｏｔｏｃｏｌ_ｖｅｒｓｉｏｎ ＴＰＴ_ｄａｔａ_ｖｅｒｓｉｏｎ及びｓｅｑｕｅｎｃｅ_ｎｕｍｂｅｒフィールドに挿入することによって、各ＴＰＴは、以下に定義されたような構造を有するＮＲＴ形式のプライベートセクションに圧縮することができる。ブロックは、ｓｅｃｔｉｏｎ_ｎｕｍｂｅｒフィールド値の昇順でセクションに挿入することができる。“サービスシグナリングチャネル”及び“ＩＰサブネット”という用語がＡＴＳＣ ＮＲＴ標準［ＮＲＴ］に定義されたように、プライベートセクションは、ＴＰＴが属する仮想チャネルのＩＰサブネットのサービスシグナリングチャネルで伝達することができる。セクションにあるｓｅｑｕｅｎｃｅ_ｎｕｍｂｅｒフィールドは、同一のサービスシグナリングチャネルで伝達される互いに異なるＴＰＴインスタントを区別するために用いられる。

ｓｅｃｔｉｏｎ_ｓｙｎｔａｘ_ｉｎｄｉｃａｔｏｒフィールド、ｐｒｉｖａｔｅ_ｉｎｄｉｃａｔｏｒフィールド、ｓｅｃｔｉｏｎ_ｌｅｎｇｔｈフィールドのセマンティックスは、ＡＴＳＣ ＮＲＴ標準［ＮＲＴ］に定義されたＮＲＴ_ｉｎｆｏｒｍａｔｉｏｎ_ｔａｂｌｅ_ｓｅｃｔｉｏｎ（）での同じ名称のフィールドのセマンティックスと同一であってもよい。

ＴＰＴセクションは、ａｂｌｅ_ｉｄフィールド、ｐｒｏｔｏｃｏｌ_ｖｅｒｓｉｏｎフィールド、ｓｅｑｕｅｎｃｅ_ｎｕｍｂｅｒフィールド、ＴＰＴ_ｄａｔａ_ｖｅｒｓｉｏｎフィールド、ｃｕｒｒｅｎｔ_ｎｅｘｔ_ｉｎｄｉｃａｔｏｒフィールド、ｓｅｃｔｉｏｎ_ｎｕｍｂｅｒフィールド、ｌａｓｔ_ｓｅｃｔｉｏｎ_ｎｕｍｂｅｒフィールド、ｓｅｒｖｉｃｅ_ｉｄフィールド、及び／又はｔｐｔ_ｂｙｔｅｓ（）フィールドを含む。

ｔａｂｌｅ_ｉｄフィールドは、当該テーブルセッションがＴＤＯパラメータテーブルインスタントに属することを確認することができる。

ｐｒｏｔｏｃｏｌ_ｖｅｒｓｉｏｎフィールドは、当該テーブル及びそれに含まれて伝達されるＴＰＴインスタントの定義のメジャーバージョン番号を示すことができ、下位４ビットは、マイナーバージョン番号を示すことができる。当該標準の当該バージョンに対するメジャーバージョン番号は１に設定することができる。受信機は、自身が支援できないメジャーバージョン値を示すＡＭＴのインスタントを廃棄すると予想される。当該標準の当該バージョンに対するマイナーバージョン番号は０に設定することができる。受信機は、自身が支援できないマイナーバージョン値を示すＡＭＴのインスタントは廃棄しない。この場合、それらは認識できない全ての記述語及び支援しない全てのフィールドを無視すると予想される。

ｓｅｑｕｅｎｃｅ_ｎｕｍｂｅｒフィールドは、当該ＴＰＴインスタントの他の全てのセクションのｓｅｑｕｅｎｃｅ_ｎｕｍｂｅｒと同一であり、当該サービスシグナリングチャネルでの他の全てのＴＰＴインスタントの全てのセクションのｓｅｑｕｅｎｃｅ_ｎｕｍｂｅｒと異なる。他のＴＰＴインスタントのｓｅｑｕｅｎｃｅ_ｎｕｍｂｅｒフィールドの値は、セグメントが放送ストリームに出現する順序を反映しなければならない。

ＴＰＴ_ｄａｔａ_ｖｅｒｓｉｏｎフィールドは、ｓｅｇｍｅｎｔ_ｉｄによって定義されるＴＰＴインスタントのバージョン番号を示す。バージョン番号は、ＴＰＴインスタントでのあるフィールドが変化すると、１モジュロ（ｍｏｄｕｌｏ）３２ずつ増加することができる。

ｃｕｒｒｅｎｔ_ｎｅｘｔ_ｉｎｄｉｃａｔｏｒフィールドは、ＴＰＴセクションに対して常に‘１’に設定されて、送信されたＴＰＴが、常にｓｅｇｍｅｎｔ_ｉｄによって識別されたセグメントに対する現在のＴＰＴであることを示すことができる。

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

ｌａｓｔ_ｓｅｃｔｉｏｎ_ｎｕｍｂｅｒフィールドは、ＴＰＴインスタントの最後のセクション（即ち、最高のｓｅｃｔｉｏｎ_ｎｕｍｂｅｒを有するセクション）の番号を提供することができ、当該セクションは、ＴＰＴインスタントの一部である。

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

ｔｐｔ_ｂｙｔｅｓ（）フィールドは、当該セクションによって部分的に伝達されるＴＰＴインスタントのブロックで構成される。当該テーブルインスタントの全てのセクションのｔｐｔ_ｂｙｔｅｓ（）フィールドがｓｅｃｔｉｏｎ_ｎｕｍｂｅｒフィールドの順に連結されると（ｃｏｎｃａｔｅｎａｔｅｄ）、完全なＴＰＴインスタントを得ることができる。

図１７は、本発明の一実施例に係る受信機の構造を示す図である。

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

アンテナ１７０１０は、放送ストリームによる放送信号を受信することができる。

チューナー１７０２０は、受信機のチャネルを探索したり、チャネルにチューニングすることができ、高周波増幅器、局部発振器、周波数変換及び入力回路、探索器などを含むことができる。

ＶＳＢ又はＤＶＢ復調器１７０３０は、ＶＳＢ信号又はＤＶＢ信号を復調することができる。ＶＳＢ又はＤＶＢ復調器１７０３０は、変調されたＶＳＢ又はＤＶＢ信号（例えば、ＯＦＤＭ変調信号）を元の信号に復元することができる。

ＭＰＥＧ−２ ＴＳシステムデコーダ１７０４０は、復調された信号の伝送ストリームをデコーディングする。ＭＰＥＧ−２ ＴＳシステムデコーダ１７０４０は、伝送ストリームからキャプションストリームを獲得してキャプションモジュール１７０５０に伝達することができる。ＭＰＥＧ−２ ＴＳシステムデコーダ１７０４０は、デコーディングされたオーディオ及びビデオ信号をオーディオデコーダ１７１１０及び／又はビデオデコーダ１７１２０に送ることができる。

キャプションモジュール１７０５０は、キャプションストリームを受信することができる。キャプションモジュール１７０５０は、サービス＃６又は他のサービスをモニタリングし、トリガーを伝送するためのサービス＃６又は他のサービスが選択されてトリガーモジュール１７０６０に送られたか否か、またはキャプションテキストが処理されてスクリーン上に表示されたか否かを判断することができる。トリガーデータはトリガーモジュール１７０６０に伝達することができる。他のキャプションサービスは、キャプションテキスト処理されてグラフィックプロセッサ１７１５０に送られてもよい。

トリガーモジュール１７０６０は、トリガー、ＴＰＴ及び／又はＡＭＴ情報をパーシングし、パーシングされたデータを処理することができる。トリガーモジュール１７０６０は、トリガーのＵＲＩ情報値を用いて、ネットワークプロトコルスタック１７０８０を介してネットワークに接続することができる。ＵＲＩ情報値は、ＨＴＴＰサーバーのアドレスであってもよい。トリガーモジュール１７０６０は、ＴＤＯ ＵＲＬを獲得するためにＴＰＴファイルコンテンツを分析することができる。また、トリガーモジュール１７０６０は、ＡＭＴをパーシングしてデータを処理することができる。他の情報がパーシングを介して獲得されてもよい。ＡＭＴメッセージが受信された後、ウェブブラウザーに対応するＴＤＯ ＵＲＬが所定時間によって伝達され、動作又は現在動作中のＴＤＯが所定時間に中止されてもよい。これは、ＴＤＯアクションに該当し、トリガーモジュール１７０６０は、ウェブブラウザーに命令を送って動作するようにすることができる。トリガーモジュールは、トリガーでの位置情報に基づいて、ＴＰＴパラメータテーブルから分離された複数のＴＰＴパラメータブロックをそれぞれ含む複数のＴＰＴパラメータテーブルセクションを収集し、複数のパラメータブロックを用いて、アプリケーション及び当該アプリケーションをターゲットとする対話型放送イベントに関するメタデータを含むＴＰＴパラメータテーブルを形成するように構成される。

ウェブブラウザー１７０７０は、トリガーモジュール１７０６０から命令語を受信し、ＵＩモジュール１７１００からブラウザーキーコードを受信し、リモコン受信機１７１６０からブラウザーキーコードを受信することができ、ネットワークプロトコルスタック１７０８０と通信することができる。

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

ネットワークインターフェース１７０９０は、他の様々な装置の共通接続又はネットワークコンピュータ及び外部ネットワークの接続を実行する。ネットワークインターフェースは、サーバーに接続して、ＴＤＯ、ＴＰＴ、ＡＭＴなどをダウンロードすることができる。

ＵＩモジュール１７１００は、リモコン受信機１７１６０を介して、リモコン１７１７０を用いて視聴者によって入力された情報を受信することができる。受信された情報が、ネットワークを使用するサービスに関連すれば、ブラウザーキーコードがウェブブラウザーに伝達されてもよい。受信された情報が現在表示されるビデオに関連すれば、信号がグラフィックプロセッサ１７１５０を介してディスプレイモジュール１７１４０に伝達されてもよい。

オーディオデコーダ１７１１０は、ＭＰＥＧ−２ ＴＳシステムデコーダ１７０４０から受信されたオーディオ信号をデコーディングすることができる。その後、デコーディングされたオーディオ信号がスピーカーに送られて視聴者に出力されてもよい。

ビデオデコーダ１７１２０は、ＭＰＥＧ−２ ＴＳシステムデコーダ１７０４０から受信されたビデオ信号をデコーディングすることができる。その後、デコーディングされたビデオ信号がディスプレイモジュール１７１４０に送られて視聴者に出力されてもよい。

スピーカー１７１３０は、オーディオ信号を視聴者に出力することができる。

ディスプレイモジュール１７１４０は、ビデオ信号を視聴者に出力することができる。

グラフィックプロセッサ１７１５０は、キャプションモジュール１７０５０から受信されたキャプションテキスト及びＵＩモジュール１７１００から受信された視聴者入力情報に対してグラフィック処理を実行することができる。処理された情報はディスプレイモジュール１７１４０に伝達されてもよい。

リモコン受信機１７１６０は、リモコン１７１７０から情報を受信することができる。このとき、キーコードがＵＩモジュール１７１００に伝達されてもよく、ブラウザーキーコードがウェブブラウザーに伝達されてもよい。

リモコン１７１７０は、視聴者によって入力された信号をリモコン受信機１７１６０に伝達する。リモコン１７１７０は、仮想チャネルを変更するための視聴者の入力を受信することができる。また、リモコンは、アプリケーションに対して視聴者によって選択された情報を受信することができる。リモコン１７１７０は、受信された情報をリモコン受信機１７１６０に伝達することができる。このとき、当該情報は、所定の範囲を超えた距離で赤外線を用いて遠隔で伝達されてもよい。

図１８は、本発明の他の実施例に係る受信機の構造を示す図である。この場合、セットトップボックスは、放送信号を受信し、処理された放送信号をＨＤＭＩ（ｈｉｇｈ ｄｅｆｉｎｉｔｉｏｎ ｍｕｌｔｉｍｅｄｉａ ｉｎｔｅｒｆａｃｅ）または外部インターフェースを介して放送受信機に伝送することができる。

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

この場合、放送ストリームのビデオ及びオーディオは未処理データであり、キャプションストリームに含まれたトリガーは受信できなくてもよい。以下で本発明について詳細に説明する。

ここで、セットトップボックス１８０３０、ＨＤＭＩ１８０５０、ＡＣＲモジュール１８１３０を除外したモジュールは、役割の面で、図１７の実施例で記述したモジュールとほぼ同一である。

セットトップボックス１８０３０は、デジタルネットワークを介してビデオサーバーから受信した圧縮された信号を元のビデオ及びオーディオ信号に復元することができる。ＴＶは、インターネットユーザインターフェースであってもよい。

ＨＤＭＩ１８０５０は、非圧縮デジタルビデオ／オーディオインターフェース標準であるＨＤＭＩであってもよい。ＨＤＭＩ１８０５０は、セットトップボックス１８０３０とＡＶ装置（即ち、オーディオデコーダ１８１４０及びビデオデコーダ１８１５０）との間のインターフェースを提供することができる。

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

明確性のために、本発明をそれぞれの添付図面を参照して説明したが、添付図面に示した実施例を併合することによって新しい実施例を設計することができる。また、前述した実施例を実行するためのプログラムが記録されたコンピュータ読み取り可能な記録媒体が当業者の必要によって設計されれば、これは、添付した請求項及びその同等の範囲に属し得る。

本発明に係る装置及び方法は、前述した実施例の構成及び方法によって制限されない。また、前述した実施例は、全体的又は部分的に互いに選択的に結合可能な方式で構成されて、様々な変形を可能にすることができる。

一方、本発明に係る方法をネットワークデバイスに備えられた、プロセッサが読み取り可能な記録媒体に、プロセッサが読み取り可能なコードとして具現することが可能である。プロセッサが読み取り可能な記録媒体は、プロセッサが読み取り可能なデータが格納されるいかなる種類の記録装置をも含む。プロセッサが読み取り可能な記録媒体の例としては、ＲＯＭ、ＲＡＭ、ＣＤ−ＲＯＭ、磁気テープ、フロッピーディスク、光データ格納装置などがあり、また、インターネットを介した伝送などのようなキャリアウェーブの形態で具現されるものも含む。また、プロセッサが読み取り可能な記録媒体は、ネットワークで接続されたコンピュータシステムに分散されて、分散方式でプロセッサが読み取り可能なコードが格納され、実行されてもよい。

本発明では、本発明の思想及び範囲から逸脱することなく様々な変更及び変形が可能であることは当業者に理解される。したがって、本発明は、添付した請求項及びその同等の範囲内で提供された本発明の変更及び変形を含むように意図される。

そして、当明細書では、物の発明及び方法の発明が全て説明されており、両発明の説明は補充的に適用されてもよい。

明確性のために、本発明をそれぞれの添付図面を参照して説明したが、添付図面に示した実施例を併合することによって新しい実施例を設計することができる。また、前述した実施例を実行するためのプログラムが記録されたコンピュータ読み取り可能な記録媒体が当業者の必要によって設計されれば、これは、添付した請求項及びその同等の範囲に属し得る。

本発明に係る装置及び方法は、前述した実施例の構成及び方法によって制限されない。また、前述した実施例は、全体的又は部分的に互いに選択的に結合可能な方式で構成されて、様々な変形を可能にすることができる。

一方、本発明に係る方法をネットワークデバイスに備えられた、プロセッサが読み取り可能な記録媒体に、プロセッサが読み取り可能なコードとして具現することが可能である。プロセッサが読み取り可能な記録媒体は、プロセッサが読み取り可能なデータが格納されるいかなる種類の記録装置をも含む。プロセッサが読み取り可能な記録媒体の例としては、ＲＯＭ、ＲＡＭ、ＣＤ−ＲＯＭ、磁気テープ、フロッピーディスク、光データ格納装置などがあり、また、インターネットを介した伝送などのようなキャリアウェーブの形態で具現されるものも含む。また、プロセッサが読み取り可能な記録媒体は、ネットワークで接続されたコンピュータシステムに分散されて、分散方式でプロセッサが読み取り可能なコードが格納され、実行されてもよい。

本発明では、本発明の思想及び範囲から逸脱することなく様々な変更及び変形が可能であることは当業者に理解される。したがって、本発明は、添付した請求項及びその同等の範囲内で提供された本発明の変更及び変形を含むように意図される。

そして、当明細書では、物の発明及び方法の発明が全て説明されており、両発明の説明は補充的に適用されてもよい。
〔発明を実施するための形態〕

発明を実施するための形態は、前述したように、発明を実施するための最良の形態で詳述された。

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

Claims (10)

1. 送信機側で放送サービスを処理する方法であって、
   セグメントのアプリケーション及び前記アプリケーションをターゲットとするイベントに関するメタデータを含むアプリケーションパラメータテーブルを生成するステップであって、前記アプリケーションは、前記放送サービスのための対話型サービスを提供するためである、ステップと、
   イベントのための活性化時間を設定する活性化トリガーの伝達に利用される活性化メッセージテーブルを生成するステップと、
   前記アプリケーションパラメータテーブルを１番目のパートとし、前記活性化メッセージテーブルを２番目のパートとして含むマルチパートメッセージを生成するステップと、
   放送チャネルを介して前記放送サービスを伝送するステップと、
   インターネットネットワークを介して前記生成したマルチパートメッセージを伝送するステップとを含み、
   前記活性化メッセージテーブルは、活性化コマンドのためのターゲットアプリケーションを識別するターゲットアプリケーション属性を含む、方法。
2. 前記活性化メッセージテーブルは、前記活性化コマンドのためのターゲットイベントを識別するターゲットイベント属性をさらに含み、
   前記ターゲットイベントは、前記ターゲットアプリケーション属性により識別される前記ターゲットアプリケーションに含まれる、請求項１に記載の方法。
3. 前記アプリケーションパラメータテーブルは、前記アプリケーションパラメータテーブルの範囲内でアプリケーションを識別するアプリケーション識別属性と、前記イベントと関連して前記アプリケーションの範囲内でイベントを識別するイベント識別属性を含み、
   前記活性化メッセージテーブルの前記ターゲットアプリケーション属性は、前記アプリケーションパラメータテーブルの前記アプリケーション識別属性と一致し、前記活性化メッセージテーブルの前記ターゲットイベント属性は前記アプリケーションパラメータテーブルの前記イベント識別属性と一致する、請求項２に記載の方法。
4. 前記イベントが前記活性化コマンドにより活性化されたとき、前記アプリケーションパラメータテーブルは、適用される活動のタイプを識別する行動属性を更に含む、請求項３に記載の方法。
5. 前記活動のタイプはプリペア(準備）タイプを含み、
   前記プリペアタイプが到着し、前記ターゲットアプリケーションがリリース状態にあるとき、前記ターゲットアプリケーションはレディー状態に移行する、請求項４に記載の方法。
6. 前記活動のタイプが実行タイプを含み、
   前記実行タイプが到着し、前記ターゲットアプリケーションがアクティブ状態になっていないとき、前記ターゲットアプリケーションは前記アクティブ状態に移行する、請求項４に記載の方法。
7. 前記活動のタイプが停止タイプを含み、
   前記停止タイプが到着し、前記ターゲットアプリケーションがアクティブ状態であるとき、前記ターゲットアプリケーションは中断状態に移行する、請求項４に記載の方法。
8. 前記アプリケーションパラメータテーブルは、前記アプリケーションの意味のある表出のために必須である能力を特定する能力エレメントをさらに含む、請求項１に記載の方法。
9. 前記能力エレメントは、必要とされる特定能力を表す能力コード属性を含む、請求項８に記載の方法。
10. 前記能力エレメントは、前記能力コード属性により表される前記特定能力のための支援が必須であるか否かを示す必須の指示子属性をさらに含む、請求項９に記載の方法。