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

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

Info

Publication number
JP6045692B2
JP6045692B2 JP2015521559A JP2015521559A JP6045692B2 JP 6045692 B2 JP6045692 B2 JP 6045692B2 JP 2015521559 A JP2015521559 A JP 2015521559A JP 2015521559 A JP2015521559 A JP 2015521559A JP 6045692 B2 JP6045692 B2 JP 6045692B2
Authority
JP
Japan
Prior art keywords
trigger
activation
time
event
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.)
Active
Application number
JP2015521559A
Other languages
English (en)
Other versions
JP2015527807A (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 JP2015527807A publication Critical patent/JP2015527807A/ja
Application granted granted Critical
Publication of JP6045692B2 publication Critical patent/JP6045692B2/ja
Active 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/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
    • H04N21/2353—Processing of additional data, e.g. scrambling of additional data or processing content descriptors specifically adapted to content descriptors, e.g. coding, compressing or processing of metadata
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/75—Media network packet handling
    • H04L65/764—Media network packet handling at the destination 
    • 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
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/61—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
    • H04L65/611—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for multicast or broadcast
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/61—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
    • H04L65/612—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for unicast
    • 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/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/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/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
    • 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

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Computer Security & Cryptography (AREA)
  • Databases & Information Systems (AREA)
  • Library & Information Science (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 (12)

  1. 受信機が対話型サービスを処理する方法であって、
    外部復号部から非圧縮オーディオコンテンツ又は非圧縮ビデオコンテンツを受信するステップと、
    前記受信されたコンテンツのフレームから識別子を抽出するステップと、
    前記識別子を含む要求をサーバに送るステップと、
    前記要求に基づいて前記サーバから前記コンテンツに対するトリガを受信するステップと、を有し、
    前記トリガは、前記コンテンツの現在メディア時間を示すか、又はアプリケーションパラメータテーブル内のイベントの活性化を知らせ、
    前記アプリケーションパラメータテーブルは、前記コンテンツに関係するアプリケーションと前記アプリケーションを対象とするイベントとに関するメタデータを含み、
    前記アプリケーションパラメータテーブルは、前記アプリケーションに関する情報を含む少なくとも一つのアプリケーション要素を含み、
    前記少なくとも一つのアプリケーション要素は、前記イベントに関する情報を含む少なくとも一つのイベント要素を含む、方法。
  2. 次の要求の前にイベント活性化がスケジュールされていない場合、前記トリガは時間ベーストリガであり、
    前記時間ベーストリガは、前記コンテンツのメディア時間を維持するために用いられる、請求項１に記載の方法。
  3. 次の要求の前にイベント活性化がスケジュールされている場合、前記トリガは活性化トリガであり、
    前記活性化トリガは、前記アプリケーションパラメータテーブル内のアプリケーションと前記イベントとを参照することによって、前記イベントに対する活性化時刻を設定し、
    前記アプリケーションは前記イベントの対象である、請求項１に記載の方法。
  4. 前記トリガが前記新しいアプリケーションパラメータテーブルを識別するアプリケーションパラメータテーブル識別子を含むときは、前記新しいアプリケーションパラメータテーブルをダウンロードするステップを更に有する、請求項１に記載の方法。
  5. 前記受信機は、同一のイベント活性化に対して一つ以上の活性化トリガを受信したとき、活性化トリガのうち一つを適用する、請求項３に記載の方法。
  6. 活性化トリガが前記活性化時刻以降に受信されたとき、活性化トリガは到達すると直ちに適用される、請求項３に記載の方法。
  7. 対話型サービスを処理する装置であって、
    外部復号部から非圧縮オーディオコンテンツ又は非圧縮ビデオコンテンツを受信する受信モジュールと、
    前記受信されたコンテンツからフレームの識別子を抽出する識別子抽出モジュールと、
    前記識別子を含む要求をサーバに送り、前記要求に基づいて前記サーバから前記コンテンツに対するトリガを受信するネットワークインタフェースと、を備え、
    前記トリガは、前記コンテンツの現在メディア時間を示すか、又はアプリケーションパラメータテーブル内のイベントの活性化を知らせ、
    前記アプリケーションパラメータテーブルは、前記コンテンツに関係するアプリケーションと前記アプリケーションを対象とするイベントとに関するメタデータを含み、
    前記アプリケーションパラメータテーブルは、前記アプリケーションに関する情報を含む少なくとも一つのアプリケーション要素を含み、
    前記少なくとも一つのアプリケーション要素は、前記イベントに関する情報を含む少なくとも一つのイベント要素を含む、装置。
  8. 次の要求の前にイベント活性化がスケジュールされていない場合、前記トリガは時間ベーストリガであり、
    前記時間ベーストリガは、前記コンテンツのメディア時間を維持するために用いられる、請求項７に記載の装置。
  9. 次の要求の前にイベント活性化がスケジュールされている場合、前記トリガは活性化トリガであり、
    前記活性化トリガは、前記アプリケーションパラメータテーブル内のアプリケーションと前記イベントとを参照することによって、前記イベントに対する活性化時刻を設定し、
    前記アプリケーションは前記イベントの対象である、請求項７に記載の装置。
  10. 前記ネットワークインタフェースは、前記トリガが前記新しいアプリケーションパラメータテーブルを識別するアプリケーションパラメータテーブル識別子を含むときは、前記新しいアプリケーションパラメータテーブルをダウンロードする、請求項７に記載の装置。
  11. 同一のイベント活性化に対して一つ以上の活性化トリガを受信したとき、活性化トリガのうち一つを適用する、請求項９に記載の装置。
  12. 活性化トリガが前記活性化時刻以降に受信されたとき、活性化トリガは到達すると直ちに適用される、請求項９に記載の装置。
JP2015521559A 2012-08-22 2013-08-21 対話型サービスを処理する装置及び方法 Active JP6045692B2 (ja)

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
US201261691805P 2012-08-22 2012-08-22
US61/691,805 2012-08-22
US201261703749P 2012-09-20 2012-09-20
US61/703,749 2012-09-20
PCT/KR2013/007496 WO2014030924A1 (en) 2012-08-22 2013-08-21 Apparatus and method for processing an interactive service

Publications (2)

Publication Number Publication Date
JP2015527807A JP2015527807A (ja) 2015-09-17
JP6045692B2 true JP6045692B2 (ja) 2016-12-14

Family

ID=50148997

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2015521559A Active JP6045692B2 (ja) 2012-08-22 2013-08-21 対話型サービスを処理する装置及び方法

Country Status (8)

Country Link
US (3) US9071663B2 (ja)
EP (1) EP2839671B1 (ja)
JP (1) JP6045692B2 (ja)
KR (1) KR102068567B1 (ja)
CN (1) CN104584574B (ja)
CA (1) CA2875467C (ja)
MX (1) MX342972B (ja)
WO (1) WO2014030924A1 (ja)

Families Citing this family (20)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR101703866B1 (ko) * 2011-06-16 2017-02-07 엘지전자 주식회사 방송 서비스 전송 방법, 그 수신 방법 및 방송 서비스 수신 장치
US9769503B2 (en) * 2012-11-14 2017-09-19 Saturn Licensing Llc Information processor, information processing method and program
US9986307B2 (en) * 2013-07-19 2018-05-29 Bottle Rocket LLC Interactive video viewing
US10504200B2 (en) 2014-03-13 2019-12-10 Verance Corporation Metadata acquisition using embedded watermarks
JP2017514345A (ja) * 2014-03-13 2017-06-01 ベランス・コーポレイション 埋め込みコードを用いた対話型コンテンツ取得
EP3138264B1 (en) * 2014-05-02 2019-11-20 Verance Corporation Metadata acquisition using embedded codes
KR102481425B1 (ko) * 2014-05-30 2022-12-27 소니그룹주식회사 수신 장치, 수신 방법, 송신 장치, 및, 송신 방법
US10372511B2 (en) * 2014-07-18 2019-08-06 Verizon Patent And Licensing Inc. Method and apparatus for providing an application control trigger
WO2016028936A1 (en) 2014-08-20 2016-02-25 Verance Corporation Watermark detection using a multiplicity of predicted patterns
CA2955340C (en) * 2014-09-05 2022-12-06 Sony Corporation Receiving device, receiving method, transmitting device, and transmitting method
US9942602B2 (en) 2014-11-25 2018-04-10 Verance Corporation Watermark detection and metadata delivery associated with a primary content
EP3225034A4 (en) * 2014-11-25 2018-05-02 Verance Corporation Enhanced metadata and content delivery using watermarks
WO2016100916A1 (en) 2014-12-18 2016-06-23 Verance Corporation Service signaling recovery for multimedia content using embedded watermarks
US10547913B2 (en) * 2015-06-21 2020-01-28 Sharp Kabushiki Kaisha Extensible watermark associated information retrieval
US9813781B2 (en) * 2015-10-27 2017-11-07 Sorenson Media, Inc. Media content matching and indexing
US10506059B2 (en) * 2016-03-18 2019-12-10 Qualcomm Incorporated Signaling of application content packaging and delivery
US10419511B1 (en) * 2016-10-04 2019-09-17 Zoom Video Communications, Inc. Unique watermark generation and detection during a conference
TWI640195B (zh) * 2016-12-14 2018-11-01 日商夏普股份有限公司 具有統一資源識別符訊息浮水印有效負載之廣播系統
US9918135B1 (en) 2017-02-07 2018-03-13 The Directv Group, Inc. Single button selection to facilitate actions in a communications network
CN112612580A (zh) * 2020-11-25 2021-04-06 北京思特奇信息技术股份有限公司 一种组合事件触发方法及触发系统

Family Cites Families (12)

* 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
WO2002062009A1 (en) * 2001-01-30 2002-08-08 Digimarc Corporation 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
US8893210B2 (en) 2010-08-20 2014-11-18 Sony Corporation Server load balancing for interactive television
JP5765558B2 (ja) * 2010-08-27 2015-08-19 ソニー株式会社 受信装置、受信方法、送信装置、送信方法、プログラム、および放送システム
KR101960314B1 (ko) * 2010-11-24 2019-03-20 엘지전자 주식회사 영상 표시 장치 및 그 제어 방법
EP2658248A4 (en) * 2010-12-26 2014-07-09 Lg Electronics Inc AUDIOVISUAL SERVICE TRANSMISSION METHOD, AUDIOVISUAL SERVICE RECEIVING METHOD, AND AUDIOVISUAL SERVICE RECEIVING APPARATUS
US9554175B2 (en) * 2011-07-20 2017-01-24 Sony Corporation Method, computer program, reception apparatus, and information providing apparatus for trigger compaction

Also Published As

Publication number Publication date
MX342972B (es) 2016-10-20
CA2875467C (en) 2017-03-14
KR20150048669A (ko) 2015-05-07
US9912971B2 (en) 2018-03-06
US20140059116A1 (en) 2014-02-27
US9596494B2 (en) 2017-03-14
CN104584574B (zh) 2018-06-22
MX2014014754A (es) 2015-02-24
JP2015527807A (ja) 2015-09-17
CN104584574A (zh) 2015-04-29
KR102068567B1 (ko) 2020-02-11
WO2014030924A1 (en) 2014-02-27
US20150264410A1 (en) 2015-09-17
EP2839671B1 (en) 2018-10-10
EP2839671A4 (en) 2015-12-02
CA2875467A1 (en) 2014-02-27
US9071663B2 (en) 2015-06-30
EP2839671A1 (en) 2015-02-25
US20150172785A1 (en) 2015-06-18

Similar Documents

Publication Publication Date Title
JP6045692B2 (ja) 対話型サービスを処理する装置及び方法
US9794645B2 (en) Apparatus and method for processing an interactive service
JP6212557B2 (ja) 対話型サービスを処理する装置及び方法

Legal Events

Date Code Title Description
A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20160112

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20160209

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20160509

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: 20161101

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20161115

R150 Certificate of patent or registration of utility model

Ref document number: 6045692

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

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250