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

対話型サービスを処理する装置及び方法 Download PDF

Info

Publication number
JP6212557B2
JP6212557B2 JP2015528407A JP2015528407A JP6212557B2 JP 6212557 B2 JP6212557 B2 JP 6212557B2 JP 2015528407 A JP2015528407 A JP 2015528407A JP 2015528407 A JP2015528407 A JP 2015528407A JP 6212557 B2 JP6212557 B2 JP 6212557B2
Authority
JP
Japan
Prior art keywords
trigger
activation
event
time
receiver
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Fee Related
Application number
JP2015528407A
Other languages
English (en)
Other versions
JP2015532045A (ja
Inventor
セチン オ
セチン オ
チンピル キム
チンピル キム
スンチュ アン
スンチュ アン
チンウォン リ
チンウォン リ
キョンホ キム
キョンホ キム
キョンス ムン
キョンス ムン
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
LG Electronics Inc
Original Assignee
LG Electronics Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by LG Electronics Inc filed Critical LG Electronics Inc
Publication of JP2015532045A publication Critical patent/JP2015532045A/ja
Application granted granted Critical
Publication of JP6212557B2 publication Critical patent/JP6212557B2/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/47—End-user applications
    • H04N21/478—Supplemental services, e.g. displaying phone caller identification, shopping application
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/235—Processing of additional data, e.g. scrambling of additional data or processing content descriptors
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/238—Interfacing the downstream path of the transmission network, e.g. adapting the transmission rate of a video stream to network bandwidth; Processing of multiplex streams
    • H04N21/2389—Multiplex stream processing, e.g. multiplex stream encrypting
    • H04N21/23892—Multiplex stream processing, e.g. multiplex stream encrypting involving embedding information at multiplex stream level, e.g. embedding a watermark at packet level
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/4302—Content synchronisation processes, e.g. decoder synchronisation
    • H04N21/4307—Synchronising the rendering of multiple content streams or additional data on devices, e.g. synchronisation of audio on a mobile phone with the video output on the TV screen
    • H04N21/43072—Synchronising the rendering of multiple content streams or additional data on devices, e.g. synchronisation of audio on a mobile phone with the video output on the TV screen of multiple content streams on the same device
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/434—Disassembling of a multiplex stream, e.g. demultiplexing audio and video streams, extraction of additional data from a video stream; Remultiplexing of multiplex streams; Extraction or processing of SI; Disassembling of packetised elementary stream
    • H04N21/4348—Demultiplexing of additional data and video streams
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/435—Processing of additional data, e.g. decrypting of additional data, reconstructing software from modules extracted from the transport stream
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/44—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream or rendering scenes according to encoded video stream scene graphs
    • H04N21/44008—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream or rendering scenes according to encoded video stream scene graphs involving operations for analysing video streams, e.g. detecting features or characteristics in the video stream
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/45—Management operations performed by the client for facilitating the reception of or the interaction with the content or administrating data related to the end-user or to the client device itself, e.g. learning user preferences for recommending movies, resolving scheduling conflicts
    • H04N21/462—Content or additional data management, e.g. creating a master electronic program guide from data received from the Internet and a Head-end, controlling the complexity of a video stream by scaling the resolution or bit-rate based on the client capabilities
    • H04N21/4622—Retrieving content or additional data from different sources, e.g. from a broadcast channel and the Internet
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/81—Monomedia components thereof
    • H04N21/8126—Monomedia components thereof involving additional data, e.g. news, sports, stocks, weather forecasts
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/83—Generation or processing of protective or descriptive data associated with content; Content structuring
    • H04N21/835—Generation of protective data, e.g. certificates
    • H04N21/8358—Generation of protective data, e.g. certificates involving watermark
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/83—Generation or processing of protective or descriptive data associated with content; Content structuring
    • H04N21/845—Structuring of content, e.g. decomposing content into time segments
    • H04N21/8455—Structuring of content, e.g. decomposing content into time segments involving pointers to the content, e.g. pointers to the I-frames of the video stream
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/83—Generation or processing of protective or descriptive data associated with content; Content structuring
    • H04N21/845—Structuring of content, e.g. decomposing content into time segments
    • H04N21/8456—Structuring of content, e.g. decomposing content into time segments by decomposing the content in the time domain, e.g. in time segments
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/85—Assembly of content; Generation of multimedia applications
    • H04N21/854—Content authoring
    • H04N21/8547—Content authoring involving timestamps for synchronizing content
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/85—Assembly of content; Generation of multimedia applications
    • H04N21/858—Linking data to content, e.g. by linking an URL to a video object, by creating a hotspot
    • H04N21/8586—Linking data to content, e.g. by linking an URL to a video object, by creating a hotspot by using a URL

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Databases & Information Systems (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)

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 (10)

  1. 受信機において対話型サービスを処理する方法であって、
    外部の復号部から非圧縮オーディオコンテンツ又は非圧縮ビデオコンテンツを受信するステップと、
    前記受信されたコンテンツのフレームから周期的に署名を抽出するステップと、
    前記署名を含む要求を、前記署名を署名のデータベースに対して検査するサーバへ送信するステップと、
    新しいセグメントが検出されたか、又はイベント活性化が前記受信機に配信される必要があるとき、前記サーバから前記コンテンツに対するトリガを受信するステップであって、前記トリガが時間ベーストリガであるか活性化トリガであるかは、前記署名により示される前記フレームに基づいて前記サーバにより決定される、ステップと、を有し、
    イベント活性化が次の要求の前に発生するようスケジュールされていないとき、前記トリガは、前記時間ベーストリガであり、前記時間ベーストリガは、前記コンテンツの現在メディア時間を示すために用いられ、
    イベントが活性化される予定であるとき、前記トリガは、前記活性化トリガであり、前記活性化トリガは、アプリケーションパラメータテーブルから活性化される前記イベントを識別し、前記メディア時間に基づいて前記イベントのための活性化時刻を示し、
    前記アプリケーションパラメータテーブルは、アプリケーションに関するメタデータを有する複数のアプリケーション要素を含み、前記アプリケーション要素は、前記アプリケーションのａｐｐＩＤと、対応するアプリケーションを対象とするイベントに関するメタデータを有する複数のイベント要素とを含み、前記イベント要素は、対応するアプリケーション要素の範囲内で前記イベントを識別するｅｖｅｎｔＩＤを含み、前記イベント要素は、対応するイベントのために用いられるデータセットを有する複数のデータ要素をさらに含み、前記データ要素は、前記データセットのｄａｔａＩＤを含み、
    前記活性化トリガは、前記アプリケーションパラメータテーブルからアプリケーション要素のａｐｐＩＤを参照し、前記参照されたアプリケーション要素は、活性化される前記イベントと関係したアプリケーションに関するメタデータを有し、
    前記活性化トリガは、前記参照されたアプリケーション要素内のイベント要素のｅｖｅｎｔＩＤをさらに参照し、前記参照されたイベント要素は、活性化される前記イベントに関するメタデータを有し、
    前記活性化トリガは、前記参照されたイベント要素内のデータ要素のｄａｔａＩＤをさらに参照し、前記参照されたデータ要素は、活性化される前記イベントのために用いられるデータセットを有する、方法。
  2. 前記トリガは、前記送信された署名が前記新しいセグメントに対応するとき、前記時間ベーストリガであり、
    前記時間ベーストリガは、前記受信機が前記新しいセグメントに関係した新しいアプリケーションパラメータテーブルを取得できるようにするために用いられる、請求項１に記載の方法。
  3. 前記活性化トリガが前記活性化時刻以降に受信されたとき、前記イベントは、前記活性化トリガが受信され次第活性化される、請求項１に記載の方法。
  4. 前記新しいセグメントのための前記新しいアプリケーションパラメータテーブルをダウンロードするステップを更に有する、請求項２に記載の方法。
  5. 前記受信機が同一のイベント活性化に対して一つよりも多い活性化トリガを受信したとき、前記活性化トリガは一回適用される、請求項１に記載の方法。
  6. 対話型サービスを処理する装置であって、
    外部の復号部から非圧縮オーディオコンテンツ又は非圧縮ビデオコンテンツを受信するように構成された受信モジュールと、
    前記受信されたコンテンツのフレームから周期的に署名を抽出するように構成された識別子抽出モジュールと、
    前記署名を含む要求を、前記署名を署名のデータベースに対して検査するサーバへ送信するよう構成されたネットワークインタフェースであって、
    新しいセグメントが検出されたか、又はイベント活性化が前記装置に配信される必要があるとき、前記サーバから前記コンテンツに対するトリガを受信するようにさらに構成され、前記トリガが時間ベーストリガであるか活性化トリガであるかは、前記署名により示される前記フレームに基づいて前記サーバにより決定される、ネットワークインタフェースと、を備え、
    イベント活性化が次の要求の前に発生するようスケジュールされていないとき、前記トリガは、前記時間ベーストリガであり、前記時間ベーストリガは、前記コンテンツの現在メディア時間を示すために用いられ、
    イベントが活性化される予定であるとき、前記トリガは、前記活性化トリガであり、前記活性化トリガは、アプリケーションパラメータテーブルから活性化される前記イベントを識別し、前記メディア時間に基づいて前記イベントのための活性化時刻を示し、
    前記アプリケーションパラメータテーブルは、アプリケーションに関するメタデータを有する複数のアプリケーション要素を含み、前記アプリケーション要素は、前記アプリケーションのａｐｐＩＤと、対応するアプリケーションを対象とするイベントに関するメタデータを有する複数のイベント要素とを含み、前記イベント要素は、対応するアプリケーション要素の範囲内で前記イベントを識別するｅｖｅｎｔＩＤを含み、前記イベント要素は、対応するイベントのために用いられるデータセットを有する複数のデータ要素をさらに含み、前記データ要素は、前記データセットのｄａｔａＩＤを含み、
    前記活性化トリガは、前記アプリケーションパラメータテーブルからアプリケーション要素のａｐｐＩＤを参照し、前記参照されたアプリケーション要素は、活性化される前記イベントと関係したアプリケーションに関するメタデータを有し、
    前記活性化トリガは、前記参照されたアプリケーション要素内のイベント要素のｅｖｅｎｔＩＤをさらに参照し、前記参照されたイベント要素は、活性化される前記イベントに関するメタデータを有し、
    前記活性化トリガは、前記参照されたイベント要素内のデータ要素のｄａｔａＩＤをさらに参照し、前記参照されたデータ要素は、活性化される前記イベントのために用いられるデータセットを有する、装置。
  7. 前記トリガは、前記送信された署名が前記新しいセグメントに対応するとき、前記時間ベーストリガであり、
    前記時間ベーストリガは、前記装置が前記新しいセグメントに関係した新しいアプリケーションパラメータテーブルを取得できるようにするために用いられる、請求項６に記載の装置。
  8. 前記活性化トリガが前記活性化時刻以降に受信されたとき、前記イベントは、前記活性化トリガが受信され次第活性化される、請求項６に記載の装置。
  9. 前記ネットワークインタフェースは、前記新しいセグメントのための前記新しいアプリケーションパラメータテーブルをダウンロードするように更に構成された、請求項７に記載の装置。
  10. 前記装置が同一のイベント活性化に対して一つよりも多い活性化トリガを受信したとき、前記活性化トリガは一回適用される、請求項６に記載の装置。
JP2015528407A 2012-09-12 2013-08-28 対話型サービスを処理する装置及び方法 Expired - Fee Related JP6212557B2 (ja)

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
US201261700310P 2012-09-12 2012-09-12
US61/700,310 2012-09-12
US201261703749P 2012-09-20 2012-09-20
US61/703,749 2012-09-20
PCT/KR2013/007722 WO2014042368A1 (en) 2012-09-12 2013-08-28 Apparatus and method for processing an interactive service

Publications (2)

Publication Number Publication Date
JP2015532045A JP2015532045A (ja) 2015-11-05
JP6212557B2 true JP6212557B2 (ja) 2017-10-11

Family

ID=50234775

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2015528407A Expired - Fee Related JP6212557B2 (ja) 2012-09-12 2013-08-28 対話型サービスを処理する装置及び方法

Country Status (9)

Country Link
US (3) US9078042B2 (ja)
EP (1) EP2896212B1 (ja)
JP (1) JP6212557B2 (ja)
KR (1) KR101939296B1 (ja)
CN (1) CN104662925B (ja)
CA (1) CA2880254C (ja)
DE (1) DE112013004029B4 (ja)
MX (2) MX368285B (ja)
WO (1) WO2014042368A1 (ja)

Families Citing this family (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB2527734A (en) * 2014-04-30 2016-01-06 Piksel Inc Device synchronization
JPWO2016017451A1 (ja) 2014-08-01 2017-05-18 ソニー株式会社 受信装置、受信方法、送信装置、及び、送信方法
US10904617B1 (en) * 2015-02-19 2021-01-26 Amazon Technologies, Inc. Synchronizing a client device with media content for scene-specific notifications
KR101757878B1 (ko) 2015-12-10 2017-07-14 삼성전자주식회사 컨텐츠 처리장치, 그의 컨텐츠 처리방법, 서버, 서버의 정보 제공방법 및 정보제공 시스템
US10523244B2 (en) * 2016-08-11 2019-12-31 Zebware Ab Device and associated methodoloy for encoding and decoding of data for an erasure code
TWI640195B (zh) * 2016-12-14 2018-11-01 日商夏普股份有限公司 具有統一資源識別符訊息浮水印有效負載之廣播系統
US11095927B2 (en) 2019-02-22 2021-08-17 The Nielsen Company (Us), Llc Dynamic watermarking of media based on transport-stream metadata, to facilitate action by downstream entity
WO2020231821A1 (en) 2019-05-10 2020-11-19 The Nielsen Company (Us), Llc Content-modification system with fingerprint data match and mismatch detection feature
US11736742B2 (en) 2019-05-10 2023-08-22 Roku, Inc. Content-modification system with responsive transmission of reference fingerprint data feature
WO2020231927A1 (en) 2019-05-10 2020-11-19 The Nielsen Company (Us), Llc Content-modification system with responsive transmission of reference fingerprint data feature
US11234050B2 (en) 2019-06-18 2022-01-25 Roku, Inc. Use of steganographically-encoded data as basis to control dynamic content modification as to at least one modifiable-content segment identified based on fingerprint analysis
US11051057B2 (en) 2019-06-24 2021-06-29 The Nielsen Company (Us), Llc Use of steganographically-encoded time information as basis to establish a time offset, to facilitate taking content-related action
US11012757B1 (en) 2020-03-03 2021-05-18 The Nielsen Company (Us), Llc Timely addition of human-perceptible audio to mask an audio watermark
WO2023176997A1 (ko) * 2022-03-17 2023-09-21 엘지전자 주식회사 디스플레이 장치

Family Cites Families (20)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6415438B1 (en) * 1999-10-05 2002-07-02 Webtv Networks, Inc. Trigger having a time attribute
US20030192060A1 (en) * 2001-01-30 2003-10-09 Levy Kenneth L. Digital watermarking and television services
US20020162118A1 (en) * 2001-01-30 2002-10-31 Levy Kenneth L. Efficient interactive TV
US8407752B2 (en) * 2004-03-18 2013-03-26 Digimarc Corporation Synchronizing broadcast content with corresponding network content
US20070072543A1 (en) * 2005-09-06 2007-03-29 Nokia Corporation Enhanced signaling of pre-configured interaction message in service guide
US20070074079A1 (en) * 2005-09-27 2007-03-29 Forster Darren P System and method for providing trigger information in a video signal and playing out a triggered event
US20070162399A1 (en) * 2005-12-22 2007-07-12 Alexander Medvinsky Method and apparatus for providing broadcast trigger messages
US8813152B2 (en) * 2008-08-26 2014-08-19 At&T Intellectual Property I, L.P. Methods, apparatus, and computer program products for providing interactive services
US20110154404A1 (en) * 2009-12-17 2011-06-23 At & T Intellectual Property I, L.P. Systems and Methods to Provide Data Services for Concurrent Display with Media Content Items
US8817072B2 (en) * 2010-03-12 2014-08-26 Sony Corporation Disparity data transport and signaling
US8893210B2 (en) * 2010-08-20 2014-11-18 Sony Corporation Server load balancing for interactive television
CN103081508B (zh) * 2010-08-30 2016-03-23 索尼公司 接收设备、接收方法和程序
JP5691316B2 (ja) 2010-09-09 2015-04-01 新東工業株式会社 バケットエレベータ内部の結露または粉体の付着を予測及び検出する方法及び装置とそれに用いられる測定ユニット
US9078031B2 (en) 2010-10-01 2015-07-07 Sony Corporation Reception apparatus, reception method, and program
KR101960314B1 (ko) * 2010-11-24 2019-03-20 엘지전자 주식회사 영상 표시 장치 및 그 제어 방법
EP2645732A4 (en) 2010-11-24 2014-05-21 Lg Electronics Inc IMPROVED SERVICE RECEIVING METHOD AND DISPLAY APPARATUS THEREFOR
KR20140084348A (ko) * 2010-12-26 2014-07-04 엘지전자 주식회사 방송 서비스 전송 방법, 그 수신 방법 및 그 수신 장치
JP5783402B2 (ja) * 2011-01-25 2015-09-24 ソニー株式会社 受信装置、受信方法、供給装置、供給方法、プログラム、および放送システム
US9554175B2 (en) * 2011-07-20 2017-01-24 Sony Corporation Method, computer program, reception apparatus, and information providing apparatus for trigger compaction
US9154840B2 (en) * 2012-07-31 2015-10-06 Sony Corporation Reception apparatus, reception method, transmission apparatus, and transmission method

Also Published As

Publication number Publication date
US9912995B2 (en) 2018-03-06
EP2896212A1 (en) 2015-07-22
US20150281786A1 (en) 2015-10-01
CN104662925B (zh) 2018-12-04
MX2015001908A (es) 2015-06-05
EP2896212A4 (en) 2016-03-16
KR20150056523A (ko) 2015-05-26
DE112013004029T5 (de) 2015-04-30
US20150172782A1 (en) 2015-06-18
CA2880254A1 (en) 2014-03-20
US9078042B2 (en) 2015-07-07
CN104662925A (zh) 2015-05-27
US20140075470A1 (en) 2014-03-13
JP2015532045A (ja) 2015-11-05
MX368285B (es) 2019-09-27
CA2880254C (en) 2017-09-19
KR101939296B1 (ko) 2019-01-16
WO2014042368A1 (en) 2014-03-20
MX343885B (es) 2016-11-25
EP2896212B1 (en) 2017-10-25
DE112013004029B4 (de) 2018-06-14
US9398341B2 (en) 2016-07-19

Similar Documents

Publication Publication Date Title
JP6212557B2 (ja) 対話型サービスを処理する装置及び方法
JP6045692B2 (ja) 対話型サービスを処理する装置及び方法
JP6174691B2 (ja) 対話型サービスを処理する装置及び方法

Legal Events

Date Code Title Description
A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20160310

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20160315

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20160613

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20161206

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20170306

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20170905

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20170915

R150 Certificate of patent or registration of utility model

Ref document number: 6212557

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

LAPS Cancellation because of no payment of annual fees