CN104662925B - 处理交互服务的设备和方法 - Google Patents

处理交互服务的设备和方法 Download PDF

Info

Publication number
CN104662925B
CN104662925B CN201380047531.XA CN201380047531A CN104662925B CN 104662925 B CN104662925 B CN 104662925B CN 201380047531 A CN201380047531 A CN 201380047531A CN 104662925 B CN104662925 B CN 104662925B
Authority
CN
China
Prior art keywords
event
activation
time
receiver
triggering
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
CN201380047531.XA
Other languages
English (en)
Other versions
CN104662925A (zh
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 CN104662925A publication Critical patent/CN104662925A/zh
Application granted granted Critical
Publication of CN104662925B publication Critical patent/CN104662925B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

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

Landscapes

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

Abstract

公开了一种处理交互服务的方法及其设备。本发明包括从外部解码单元接收未压缩的音频内容或未压缩的视频内容，周期性地从所接收到的内容提取帧的标识符，提交包含所述标识符的请求，并且当检测到新片段时或者当需要将事件激活传达给所述接收机时，接收用于所述内容的触发，其中，所述触发指示所述内容的当前时间并且参考应用参数表中的特定交互事件或者用信号通知所述事件将现在执行或者在指定的未来时间执行，其中，所述应用参数表包括关于多个应用中的至少一个应用的信息。

Description

处理交互服务的设备和方法
技术领域
本发明涉及提供、接收和处理广播服务的方法和设备，更具体地讲，涉及一种提供与广播内容相关的补充服务的方法和设备。
背景技术
TV首次出现于19世纪末，并且自20世纪末以来随着其画面显示方法或设计不断发展，已成为最普及的信息传送设备。然而，TV通常使得观看者能够从广播台接收单向信息。随着自20世纪90年代以来个人计算机(PC)和互联网得到广泛使用，TV的这些局限已成为问题。因此，TV已发展为能够提供交互服务。
然而，目前，没有在内容提供商与观看者之间提供交互服务的系统。具体地讲，为了提供这种交互服务，需要一种在特定时间执行与当前广播的广播内容相关的应用并且通过特殊信息处理将相关信息提供给观看者的方法。
发明内容
技术问题
为解决所述问题而设计出的本发明的目的在于在广播内容被回放的时间段期间的适当时间与广播内容相关的补充信息。
技术方案
本发明的目的可通过提供一种根据本发明的在接收机处处理交互服务的方法来实现，该方法包括以下步骤：从外部解码单元接收未压缩的音频内容或未压缩的视频内容；周期性地从接收的内容提取帧的标识符；提交包含所述标识符的请求；以及当检测到新片段时或者当需要将事件激活传输给接收机时，接收用于所述内容的触发，其中，所述触发指示所述内容的当前时间并且参考应用参数表中的特定交互事件或者用信号通知所述事件将现在执行或者在指定的未来时间执行，其中，所述应用参数表包括关于多个应用中的至少一个应用的信息。
优选地，当所述标识符对应于所述新片段时所述触发是时基触发，并且所述时基触发用于使得接收机能够获得与所述新片段关联的新应用参数表。
优选地，每当事件将要被激活时所述触发是激活触发，所述激活触发设定所述事件的激活时间。
优选地，在接收机需要应用所述激活触发之前接收所述激活触发。
优选地，当在所述激活时间之后接收到所述激活触发时，在接收到所述激活触发时立即激活所述事件。
优选地，所述方法还包括以下步骤：当所述触发包括标识新应用参数表的应用参数表标识符时，立即下载所述新应用参数表，除非所述接收机已经利用所述应用参数表所传送的URL信息检索到所述新应用参数表。
优选地，当所述接收机针对同一事件激活接收到一个以上激活触发时，所述激活触发被应用一次。
优选地，所述时间是媒体时间，并且所述媒体时间是参考内容项的播出(playout)中的点的参数。
优选地，所述应用是声明对象、触发声明对象、非实时声明对象或无约束声明对象。
在本发明的另一方面中，本文提供了一种根据本发明的处理交互服务的设备，该设备包括：接收模块，其被配置为从外部解码单元接收未压缩的音频内容或未压缩的视频内容；标识符提取模块，其被配置为周期性地从接收的内容提取帧的标识符；以及网络接口，其被配置为提交包含所述标识符的请求，并且当检测到新片段时或者当需要将事件激活传输给所述设备时，接收用于所述内容的触发，其中，所述触发指示所述内容的当前时间并且参考应用参数表中的特定交互事件或者用信号通知所述事件将现在执行或者在指定的未来时间执行，其中，所述应用参数表包括关于多个应用中的至少一个应用的信息。
优选地，当所述标识符对应于所述新片段时所述触发是时基触发，并且所述时基触发用于使得所述设备能够获得与所述新片段关联的新应用参数表。
优选地，每当事件将要被激活时所述触发是激活触发，所述激活触发设定所述事件的激活时间。
优选地，在所述设备需要应用所述激活触发之前接收所述激活触发。
优选地，当在所述激活时间之后接收到所述激活触发时，在接收到所述激活触发时立即激活所述事件。
优选地，所述网络接口还被配置为当所述触发包括标识新应用参数表的应用参数表标识符时，立即下载所述新应用参数表，除非所述设备已经利用所述应用参数表所传送的URL信息检索到所述新应用参数表。
优选地，当所述设备针对同一事件激活接收到一个以上激活触发时，所述激活触发被应用一次。
优选地，所述时间是媒体时间，并且所述媒体时间是参考内容项的播出中的点的参数。
优选地，所述应用是声明对象、触发声明对象、非实时声明对象或无约束声明对象。
有益效果
根据本发明，可利用传统广播系统提供与广播内容相关的补充信息。
根据本发明，可检测与广播内容相关的补充信息需要被显示的时间并且在适当的时间向用户提供所述补充信息。
根据本发明，可为具有互联网连接并且仅可从广播流访问未压缩的音频和视频的接收机提供与广播内容相关的补充信息。
附图说明
附图被包括以提供对本发明的进一步理解，并且被并入本申请并构成本申请的一部分，附图示出本发明的实施方式并与说明书一起用于说明本发明的原理。附图中：
图1是示出典型广播流的实施方式的示图；
图2是示出在预制作的内容的情况下的触发定时的实施方式的示图；
图3是示出在直播内容的情况下的触发定时的实施方式的示图；
图4是示出触发句法的实施方式的示图；
图5是示出TDO参数表的实施方式的示图；
图6是示出TDO参数表的实施方式的示图；
图7是示出“Frequency of Use”属性值的含义的示图；
图8是示出“destination”属性值的含义的示图；
图9是示出TDO参数表的二进制形式的句法的实施方式的示图；
图10是示出TDO参数表的二进制形式的句法的实施方式的示图；
图11是示出TDO参数表的二进制形式的句法的实施方式的示图；
图12是示出TDO参数表的二进制形式的句法的实施方式的示图；
图13是示出TDO参数表的二进制形式的句法的实施方式的示图；
图14是示出激活消息表结构的实施方式的示图；
图15是示出URL List结构图的实施方式的示图；
图16是示出包含TPT的私有区段的二进制格式的实施方式的示图；
图17是示出被编码为XML文档的URL列表的实施方式的示图；
图18是示出addTriggerEventListener的实施方式的示图；
图19是示出removeTriggerEventListener的实施方式的示图；
图20是示出EventListener类型的定义的实施方式的示图；
图21是示出TriggerEvent类型的定义的实施方式的示图；
图22是示出用于WM方法的架构的实施方式的示图；
图23是示出用于FP方法的架构的实施方式的示图；
图24是示出请求/响应ACR情况下的静态激活的实施方式的示图；
图25是示出请求/响应ACR情况下的静态激活的实施方式的示图；
图26是示出请求/响应情况下的动态激活的实施方式的示图；
图27是示出请求/响应情况下的动态激活的实施方式的示图；
图28是示出用于ACR服务器激活的架构的实施方式的示图；
图29是示出没有EndTime的情况(b)和情况(a)下的激活触发的实施方式的示图；
图30是示出没有EndTime的情况(b)和情况(a)下的激活触发的实施方式的示图；
图31是示出具有EndTime的情况(a)下的激活触发的实施方式的示图；
图32是示出具有EndTime的情况(a)下的激活触发的实施方式的示图；
图33是示出情况(c)的激活触发的实施方式的示图；
图34是示出情况(c)的激活触发的实施方式的示图；
图35是示出在最后一刻传送的动态激活触发的实施方式的示图；
图36是示出在最后一刻传送的动态激活触发的实施方式的示图；
图37是在请求/响应情况下ACR客户机与其它服务器之间的顺序图；
图38是在事件驱动ACR情况下ACR客户机与其它服务器之间的顺序图；
图39是示出在事件驱动模型中在接收机处处理交互服务的方法的实施方式的示图；
图40是示出根据本发明的实施方式的接收机的结构的示图；
图41是示出在机顶盒经由高清晰多媒体接口(HDMI)或外部接口接收广播的情况下根据本发明的实施方式的接收机的结构的示图；以及
图42是示出在事件驱动模型中处理交互服务的设备的实施方式的示图。
具体实施方式
尽管本发明中使用的术语选自通常所知并使用的术语，但本文所用的术语可根据运营商的意图或者本领域的惯例、新技术的出现等而变化。另外，本发明的描述中所提及的一些术语由申请人酌情选择，其详细含义在本文描述的相关部分中进行描述。另外，本发明不能简单地通过实际使用的术语来理解，而是需要通过各术语的内部含义来理解。
在本说明书中，术语媒体时间代表参考音频/视频或音频内容项的播出中的点的参数。ACR代表自动内容识别。AMT代表激活消息表。API代表应用编程接口。DAE代表声明应用环境。DO代表声明对象。FLUTE代表单向传输的文件传送。GPS代表全球定位系统。HTTP代表超文本传送协议。IP代表互联网协议。IPTV代表互联网协议电视。iTV代表交互电视。MIME代表互联网媒体类型。NDO代表NRT声明对象。NRT代表非实时。SMT代表服务映射表。SSC代表服务信令信道。TDO代表触发声明对象。TPT代表TDO参数表。UDO代表无约束声明对象。UPnP代表用户即插即用。URI代表统一资源标识符。URL代表统一资源定位符。XML代表可扩展标记语言。TFT代表文本分段表。其细节将在下面描述。
在本说明书中，DO、TDO、NDO、UDO、链接(Link)和打包应用(Packaged App)具有以下含义。
DO(声明对象)可以是构成交互应用的收集。(例如，HTML、JavaScript、CSS、XML和多媒体文件)。
术语“触发声明对象”(TDO)用于指定通过触发交互附属数据服务中的触发启动的声明对象，或者通过触发所启动的DO启动的DO，以此类推。
术语“NRT声明对象”(NDO)用于指定作为NRT服务(不是触发交互数据服务)的一部分启动的声明对象。
术语“无约束声明对象”(UDO)用于指定未绑定到服务的声明对象，例如通过链接启动的打包应用或者DO，或者通过这种DO启动的DO，以此类推。
“链接”是广播商提供的URL，该URL指向提供与当前TV节目或NRT服务相关的在线信息或功能的网站。
“打包应用”是广播商提供的声明对象(DO)，该DO提供广播商想要提供给观看者的信息或功能，并且被打包成单个文件以便于观看者下载和安装。
其细节将在下面描述。
在本说明书中，时基消息包括时基触发及其等同物。因此，术语“时基消息”可与术语“时基触发”互换使用。
在本说明书中，激活消息包括导致激活的所有信息传送，例如AMT和/或激活触发中的激活元素。
图1是示出典型广播流的实施方式的示图。
典型广播流包括一系列TV节目。各个TV节目包括下层演出(show)，该演出通常被分成通过广告和/或其它间隙材料分开的块。
在图1中，广播流中顺序包括演出A的片段、广告1、广告2、演出B的片段等。配置各个演出的片段可被称作演出内容，广告可被称作间隙内容。
各个演出或各条间隙材料可能具有或者没有与其关联的交互附属数据服务。
在本说明书中将使用术语“交互服务片段”或者简称“片段”来表示被广播商当作整体单元处理的一部分交互附属服务。交互服务片段通常(但非必须)与单个演出或单条间隙材料关联。
为了执行这种交互附属数据服务，存在两个模型：直接执行模型和触发声明对象(TDO)模型。
在直接执行模型中，可一选择虚拟信道就自动启动声明对象(DO)。可经由互联网与后端服务器通信以得到用于提供交互特征的详细指令–在屏幕上的特定位置创建显示，进行轮询，启动其它专用DO等(全部与音频-视频节目同步)。
在TDO模型中，可在广播流中或者经由互联网传送信号以便发起TDO事件(例如，启动TDO、终止TDO或者通过TDO推动特定任务。这些事件可在特定时间发起(通常与音频-视频节目同步)。当TDO被启动时，其可提供其被编程提供的交互特征。
TDO模型背后的基本概念在于，组成TDO的文件以及TDO采取特定动作将要使用到的数据文件考虑到其大小全部需要一定量的时间来被传送至接收机。尽管可在内容的广播之前进行交互元素的用户体验，但特定行为必须被小心地定时，以与节目本身中的事件一致(例如，商业广告片段的发生)。
TDO模型将声明对象以及关联的数据、脚本、文本和图形的传送与交互事件的播出的特定定时的信令分开。
建立交互事件的定时的元素是触发(Trigger)。
关于片段中所使用的TDO以及通过触发发起的关联的TDO事件的信息通过称为“TDO参数表”(TPT)的数据结构来提供。
图2是示出在预制作的内容的情况下的触发定时的实施方式的示图。
触发是信令元素，其功能是标识信令并建立交互事件的播出的定时。
触发包括：时基触发，其用于指示与交互服务相关的片段的媒体时间；以及激活触发，其用于指示与交互服务相关的应用的事件发生时间。
触发可执行各种定时相关信令功能以支持交互服务。触发可为多功能的；根据其结构，特定触发实例可执行以下功能中的一个或更多个：
1.用信号通知TPT的位置(可经由发射流中的FLUTE会话、经由互联网服务器或者这二者得到)；
2.指示用于即将到来的节目片段的交互内容可用，能进行预载；
3.指示关联的音频/视频或仅音频内容的当前媒体时间；
4.参考TPT中的特定交互事件，并且用信号通知该事件将在现在执行或者在指定的未来媒体时间执行；
5.指示对互联网服务器的访问将被随机地分散在指定的时间间隔上，以便避开需求高峰。
图2示出与两个节目片段关联地传送的触发。在此示例中，两个片段均为“预制作的”(意味着内容不是来自直播广播)；在后期制作中已添加交互元素。
如所示，在节目片段1发生之前的较短时间，可传送“预载”触发以使得接收机能够有机会获取与节目片段1关联的TPT和交互内容。如果没有发送预载，则接收机应该会使用其在片段内看到的第一触发来获取内容。
如所示，贯穿片段1均可发送触发，以指示相对于片段的当前媒体时间(在图中标记为“m”)。为了使得刚刚遇到该信道的接收机能够同步并获取交互内容，可有必要周期性地传送媒体时间触发。
就在片段2开始之前，发送用于该即将到来的片段的预载触发。
在预制作的内容(非直播)的情况下，接收机在处理第一触发之后可获取的TPT可限定用于该片段的交互体验的所有元素的定时。接收机和TDO为了播出交互元素可只需知道媒体定时；TPT可相对于媒体时间描述交互事件。
图3是示出在直播内容的情况下的触发定时的实施方式的示图。
对于直播内容的情况，TPT仍包含与不同的交互事件有关的数据和信息，然而，在广播期间节目中的动作展现之前无法知道那些事件的播出的定时。对于直播情况，使用触发的“事件-定时”功能。在此模式下，触发可用信号通知指定的交互事件将被重新定时至媒体时间的指定的新值。另选地，触发可指示特定事件将被立即执行。
在图3中，现在将描述片段3的触发的功能。
第一触发是预载触发，其参考包含片段3的文件的目录。
第二触发是媒体时间触发，其用于指示片段3的播出定时。
第三触发是事件重新定时触发，并且指示TPT中具有eventID＝2的事件将被重新定时为在媒体时间240处发生。阴影区域指示触发#3可被传送给接收机的240之前的时间间隔。
第四触发是媒体时间触发。
第五触发是事件重新定时触发，并且指示TPT中具有eventID＝5的事件将被重新定时为在媒体时间444处发生。
第六触发和第七触发是媒体时间触发。
第八触发是事件触发，并且指示TPT中具有eventID＝12的事件将立即执行。
第九触发是事件重新定时触发，并且指示TPT中具有eventID＝89的事件将被重新定时为在媒体时间900处发生。
以下，将描述TDO的寿命周期、状态和状态改变事件。
TDO可存在于四种不同的状态下：释放、就绪、活动和暂停。多种不同的因素可导致从一种状态转变为另一状态(触发、用户动作、改变信道等)。
TDO可包括以下四种状态。这四种状态是就绪、活动、暂停和释放。就绪状态意指TDO被下载并准备好执行，但还未执行。活动状态意指TDO正在执行。暂停状态意指TDO被临时暂停执行，其状态被保存。释放状态意指TDO不是就绪、活动或暂停。
以下是可导致TDO的状态改变的一些事件：
1.触发“准备”？装置接收到触发(在当前选择的主虚拟信道中)，该触发请求TDO准备好执行(分配资源，加载到主存储器中等)。
2.触发“执行”？装置接收到触发(在当前选择的主虚拟信道中)，该触发请求激活TDO。
3.触发“暂停”？装置接收到触发(在当前选择的主虚拟信道中)，该触发指示暂停TDO。
4.触发“结束”？装置接收到触发(在当前选择的主虚拟信道中)，该触发指示终止TDO。
图4是示出触发句法的实施方式的示图。
在特定传送环境下，激活消息和时基消息均可具有一般“触发”格式。
除了竖线符号“|”用于指定另选方案之外，这里的句法定义利用扩展巴克斯范式(ABNF)语法来描述。规则通过等号“＝”与定义分开，缩进用于在不止一行上继续规则定义，文字用""引用，圆括号“(”和“)”用于将元素分组，可选元素被括在“[”和“]”括号中，元素前可加<n>*，以指定随后元素的n或以上个重复；n默认为0。并且元素前可加<n>*<m>，以指定随后元素的n或以上个重复以及m或以下个重复。
该触发句法基于统一资源标识符(URI)：<scheme>和“://”部分以外的通用句法，具有附加限制。
Trigger可包括locator_part和terms。terms可被省略。如果terms存在，则locator_part和terms可通过“？”连接。
locator_part可包括hostname部分和path_segments部分(可通过“/”连接)。
hostname可包括domainlabel和toplabel，domainlabel可随“.”一起重复0次或以上。即，hostname可包括与toplabel连接的重复的domainlabel或者仅包括toplabel。
domainlabel可包括一个alphanum，或者包括alphanum或者重复地插入alphanum与alphanum之间0次或以上的“-”。
这里，alphanum可意指alpha或digit。
这里，alpha可以是lowalpha或upalpha之一。
这里，lowalpha可以是a、b、c、d、e、f、g、h、i、j、k、l、m、n、o、p、q、r、s、t、u、v、w、x、y和z之一。
这里，upalpha可以是A、B、C、D、E、F、G、H、I、J、K、L、M、N、O、P、Q、R、S、T、U、V、W、X、Y和Z之一。
这里，digit可以是0、1、2、3、4、5、6、7、8和9之一。
Toplabel包括一个alpha，或者包括alphanum或者重复地插入alpha与alphanum之间0次或以上的“-”。
path_segments包括一个segment，之后跟随有重复0次或以上的segment。此时，segment可通过“/”连接。
这里，segment包括重复一次或以上的alphanum。
terms可包括event_time或media_time之一，之后可跟随有spread或others。spread和others可被省略。如果spread和others存在，则可将“&”置于spread和others的前面并且spread和others可被置于event_time或media_time之后。
这里，spread可包括在“s＝”之后重复一次或以上的digit。
Event_time可包括在“e＝”之后重复一次或以上的digit，或者包括在“&t＝”之后重复一次或以上或者七次或以下的hexdigit。“&t＝”及其后面的部分可被省略。
这里，hexdigit可以是0、1、2、3、4、5、6、7、8、9、a、b、c、d、e和f之一。
Media_time可包括在“m＝”之后重复一次或以上或者七次或以下的hexdigit。
Others可包括一个“other”或者包括“other”以及跟随的“&”和“other”。
这里，other可包括resv_cmd和alphanum(重复一次或以上并通过“＝”连接)。
这里，resv_cmd可以是“c”、“e”、“E”、“m”、“M”、“s”、“S”、“t”和“T”以外的alphanum。
触发的长度可不超过52字节。另外，Trigger的hostname部分可以是注册的互联网域名。
Trigger可被视为包括三个部分。
<domain name part>/<directory path>[？<parameters>]
<domain name part>可以是注册域名，<directory path>可以是URI中将出现的路径。
<domain name part>可参考注册的互联网域名。<directory path>可以是在对标识的域名有权的实体的控制和管理下标识目录路径的任意字符串。
在TDO模型中，<domain name part>和<directory path>的组合可唯一地标识可由接收机处理以向关联的内容添加交互性的TPT。
<domain name part>和<directory path>的组合可以是可获得用于当前片段的TPT的互联网位置的URL。
即，触发可利用<domain name part>和<directory path>来标识TPT。通过<domain name part>和<directory path>，可确定应用了触发的TPT。将触发应用于TPT所扮演的角色取决于<parameters>。
以下，将描述<parameters>。
<parameters>可包括“event_time”、“media_time”或“spread”中的一个或更多个。
接下来，将描述图4所示的句法的“event_time”、“media_time”和“spread”。
event_time＝"e＝"1*digit["&t＝"1*7hexdigit]
media_time＝"m＝"1*7hexdigit
spread＝"s＝"1*digit
“event_time”项可用在激活触发中以标识目标事件(“e＝”项)以及该事件应该被激活的时间(“t＝”项)。当缺少“t＝”项时，意味着该事件应该在触发到来的时间被激活。
即，作为交互事件ID项的“e＝”可参考以该事件为目标的TDO的关联TPT中的appID、特定事件的eventID以及将用于该事件激活的Data元素的dataID。
作为可选的定时值项的“t＝”可指示指定的事件的新媒体定时。如果不存在“t＝”部分，则可意味着指定的事件的定时是触发的到来事件。
“media_time”项(“m＝”项)可用在时基触发中以标识相对于由时基触发表示的时基的当前时间。media_time中可进一步包括用于标识当前显示的内容的内容标识符信息(“c＝”项)。对于“c＝”项，直接执行模型将在下面描述。
即，“m＝”(是媒体时间戳项)以及跟随的长度为1至8个字符的字符串(表示十六进制数)可指示当前媒体时间。
“spread”项可用于指示响应于时基触发(例如，从服务器检索TPT)或者激活触发(例如，导致TDO访问服务器)而采取的任何动作应该被延迟随机量的时间，以分散服务器上的工作负荷。
“s＝”项可指示所有接收机应该尝试访问触发中所标识的互联网服务器的时间(秒数)。各个单独的接收机应该会推导指定的间隔内的随机时间，并且将访问请求延迟该时间量，从而在接收机处在时间上分散需求高峰(否则的话在触发首次出现时可能发生所述需求高峰)。
包含<媒体时间>参数的触发可称为时基触发，因为它用于建立事件时间的时基。
包含<event time>参数的触发可称为激活触发，因为它设定事件的激活时间。
图5和图6是示出TDO参数表的实施方式的示图。
TDO参数表(TPT)包含关于片段的TDO以及以其为目标的事件的元数据。
以下，将描述表中所包括的字段。表中所包括的字段的大小和字段的类型可根据设计者的意图而增加或改变。
TPT结构中的字段的详细语义如下。
TDO参数表(TPT)可包括@majorProtocolVersion、@minorProtocolVersion、@id、@tptVersion、@expireDate、@updatingTime、@serviceID、@baseURL属性、Capabilities、LiveTrigger和/或TDO元素。
TPT是TPT的根元素。一个TPT元素描述一个节目片段的全部或一部分(时间上)。
MajorProtocolVersion(可为4比特属性)可指示表定义的主版本号。主版本号可被设定为1。接收机应该丢弃指示它们不能支持的主版本值的TPT的实例。
当存在时，@MinorProtocolVersion(可为4比特属性)可指示表定义的次版本号。当不存在时，该值默认为0。次版本号可被设置为0。接收机应该不丢弃指示它们不能支持的次版本值的TPT的实例。在这种情况下，它们应该忽略它们不支持的任何单独的元素或属性。
@id(是URI)可唯一地标识该TPT元素所涉及的交互节目片段。@id用作片段的标识符。因此，在接收机解析TPT之后，与一个片段相关的触发、AMT等可利用@id信息匹配具有标识该片段的@id的TPT。因此，可找到将应用触发和AMT的片段。AMT的细节将在下面描述。
@tptVersion(可为8比特整数)可指示由id属性标识的TPT元素的版本号。每当对TPT进行任何改变时，tptVersion可增加。
当存在时，TPT元素的@expireDate属性可指示包括在该TPT实例中的信息的期满日期和时间。如果接收机缓存TPT，则其可被重复使用直至expireDate。
当存在时，@updatingTime(可为16比特元素)可指示TPT经受修订，它给出推荐再次下载TPT的间隔(秒)并且检查新下载的TPT是否为新版本。
当存在时，@serviceID(可为16比特整数)可指示与该TPT实例中描述的交互服务关联的NRT service_id。这是接收机在用于交互服务的文件在广播流中传送时从服务映射表得到FLUTE参数所需要的。
当存在时，@baseURL属性可给出基本URL，该基本URL在被级联到该TPT中出现的任何相对URL的前面时，可给出文件的完全URL。
当存在时，Capabilities元素可指示与该TPT关联的交互服务的有意义呈现所必不可少的能力。没有一个或更多个所需的能力的接收机不应尝试呈现服务。
当且仅当经由互联网的激活触发的传送可用时，LiveTrigger元素才存在。当存在时，它可提供接收机获得激活触发所需的信息。LiveTrigger的子元素和属性将在下面描述。
TDO(是TPT元素的子元素)可表示在由该TPT实例描述的片段期间提供部分交互服务的应用(例如，TDO)。TDO的子元素和属性将在下面描述。
LiveTrigger元素可包括@URL和/或@pollPeriod属性。
如上所述，当且仅当经由互联网的激活触发的传送可用时，LiveTrigger元素才存在。当存在时，它可提供接收机获得激活触发所需的信息。
@URL(是LiveTrigger元素的属性)可指示可经由互联网传送激活触发的服务器的URL。可按照交互服务提供商的选择经由互联网利用HTTP短轮询、HTTP长轮询或HTTP流来传送激活触发。
当存在时，@pollPeriod(是LiveTrigger元素的属性)可指示使用短轮询来传送激活触发，并且pollPeriod属性的值可指示向接收机推荐的用作轮询周期的时间(秒)。
如果LiveTrigger元素存在，则接收机可解析TPT并且获得用于利用互联网传送激活触发的信息。可接收激活触发的服务器的URL可利用@URL信息来使用。通过@pollPeriod信息或者指示@pollPeriod属性不存在的信息，可获得经由互联网传送激活触发的方法以及关于轮询周期的信息。@pollPeriod将在下面详细描述。
TDO元素可包括@appID、@appType、@appName、@globalID、@appVersion、@cookieSpace、@frequencyOfUse、@expireDate、@testTDO、@availInternet、@availBroadcast属性、URL、Capabilities、Contentitem和/或Event元素。
如上所述，TDO(是TPT元素的子元素)可表示在由此TPT实例描述的片段期间提供部分交互服务的应用(例如，TDO)。
@appID(可为16比特整数)可在TPT的范围内唯一地标识应用。激活触发利用对appID的参考来标识触发的目标应用。@appID是应用的标识符。一个TPT可包括多个应用(例如，TDO)。因此，在解析TPT之后，可利用@appID信息来标识应用。将应用于一个应用的触发、AMT等可匹配具有标识该应用的@appID的应用。因此，可找到将应用触发和AMT的应用。AMT将在下面详细描述。
@appType(可为8比特整数)可指示应用格式类型。默认值可为1(可表示TDO)。其它值可表示其它格式。
@appName(是TDO元素的属性)可以是可在寻求观看者的许可以启动应用时显示给观看者的人可读的名称。
@globalID(是TDO元素的属性)可以是应用的全局唯一标识符。在许多情况下，接收机将缓存不久将被再次使用的应用。为此，接收机必须能够在应用下次出现时识别它。globalID就是接收机能够在应用下次出现在新片段中时识别它所需要的。
@appVersion(是TDO元素的属性)可以是应用的版本号。每当应用(由globalID标识)改变时，appVersion值可增加。如果globalID属性不存在，则appVersion属性也不存在。
@cookieSpace(可为8比特整数)可指示应用在调用之间存储永久数据需要多少空间。
@frequencyOfUse(可为4比特整数)可近似指示将在广播中多频繁地使用应用，以向接收机提供指导来管理它们的应用代码缓存空间。“@frequencyOfUse”将在下面详细描述。
@expireDate(是TDO元素的属性)可指示之后接收机可安全地移除应用和任何相关资源的日期和时间。
当以值“真”存在时，@testTDO(是布尔属性)可指示应用仅用于测试目的，它可被普通接收机忽略。
@availInternet属性的值“真”可指示应用可经互联网下载。值“假”可指示应用不可经互联网下载。当该属性不存在时，默认值可为“真”。
@availBroadcast属性的值“真”可指示应用可从广播提取。值“假”可指示应用不可从广播提取。当该属性不存在时，默认值可为“真”。
URL(TDO元素的子元素)的各个实例可标识作为应用的一部分的文件。URL元素可包括@entry属性。@entry(URL元素的属性)的值“真”可指示URL是应用(即，为了启动应用而可被启动的文件)的入口点。当它具有值“假”时，可指示URL不是应用的入口点。当该属性不出现时，默认值可为“假”。如上所述，URL元素(是TDO元素的子元素)标识配置应用的文件。接收机解析TPT以获得URL信息，利用该URL信息访问服务器，并下载由该URL信息指示的应用。
当存在时，Capabilities(是TDO元素的子元素)可指示此应用的有意义的呈现所必不可少的能力。不具有一个或更多个所需的能力的接收机不应尝试呈现启动应用。
ContentItem(TDO元素的子元素)可指示包括应用所需的一个或更多个数据文件的内容项。ContentItem元素具有关于此元素所属于的TDO元素所指示的应用所需的数据文件的信息。如果在解析之后存在ContentItem元素，则接收机可利用ContentItem的URL信息等来下载应用所需的数据文件。ContentItem的子元素和属性将在下面描述。
Event(TDO元素的子元素)可表示应用的事件。Event元素指示此元素所属于的应用的事件。event元素包含指示存在哪些事件、存在哪些数据、存在哪一动作等的信息。接收机可解析event元素以获得关于应用的事件的信息。event的子元素和属性将在下面描述。
接收机可接收并解析TPT以获得TDO的子元素以及关于属性的信息。
ContentItem元素(是TDO元素的子元素)可包括@updateAvail、@pollPeriod、@size、@availInternet、@availBroadcast属性和/或URL元素。
这里，URL元素可包括@entry属性。URL(ContentItem元素的子元素)的各个实例可标识作为内容项的一部分的文件。URL元素可包括@entry属性。@entry(URL元素的属性)的值“真”可指示URL是内容项？(即，为了启动内容项而可被启动的文件)的入口点。当它具有值“假”时，可指示URL不是内容项的入口点。当该属性不出现时，默认值可为“假”。接收机可在解析之后利用ContentItem的URL信息下载应用所需的数据文件。在此处理中，可使用诸如上述其它属性的信息。
@updatesAvail(是ContentItem元素的布尔属性)可指示内容项是否将被不时地更新？(即，内容项是否包括静态文件或者它是否为实时数据馈送)。当值为“真”时，内容项将被不时地更新；当值为“假”时，内容项将不被更新。当此属性不出现时，默认值可为假。
仅当updatesAvail属性的值为“真”时，@pollPeriod(是ContentItem元素的属性)才可存在。pollPeriod属性的存在可指示使用短轮询来传送激活触发，pollPeriod属性的值可指示向接收机推荐的用作轮询周期的时间(秒)。
@Size(是ContentItem元素的属性)可指示内容项的大小。
@availInternet属性的值“真”可指示内容项可经互联网下载。值“假”可指示内容项不可经互联网下载。当此属性不存在时，默认值可为“真”。
@availBroadcast属性的值“真”可指示内容项可从广播提取。值“假”可指示内容项不可从广播提取。当此属性不存在时，默认值可为“真”。
event元素包含关于event元素所属于的TDO元素所指示的应用的事件的信息。接收机可解析event元素以获得关于事件的信息。
event元素(是TDO元素的子元素)可包括@eventID、@action、@destination、@diffusion属性和/或Data元素。这里，data元素可包括@dataID属性。
@eventID(可为Event元素的16比特整数属性)可在包含其的TDO元素的范围内唯一地标识事件。激活触发(或AMT中的激活元素)可通过appID和eventID的组合来标识触发的目标应用和事件。当事件被激活时，接收机将事件变成应用。@eventID用作事件的标识符。利用@eventID信息，用于激活事件的触发、AMT等可匹配具有标识该事件的@eventID的应用。即，激活触发(或AMT中的激活元素)可通过appID和eventID的组合来标识触发的目标应用和事件。当事件被激活时，接收机将事件变成应用。AMT将在下面详细描述。
@action(是Event元素的属性)可指示当事件被激活时将应用的动作的类型。允许的值可为“prep”、“exec”、“susp”和“kill”。
“prep”可对应于“Trig prep”动作。如果目标应用的状态为“释放”，则该动作可导致状态改变为“就绪”。
“exec”可对应于“Trig exec”动作。在接收到此触发时目标应用的状态可变为“活动”。
“susp”可对应于“Trig susp”动作。如果目标应用的状态为“活动”，则在接收到此触发时状态可改变为“暂停”，否则不改变。
“kill”可对应于“Trig kill”动作。在接收到此触发时目标应用的状态可变为“释放”。
@action可指示当事件被激活时要应用的动作的类型。
@destination(是Event元素的属性)可指示事件的目标装置。@destination将在下面详细描述。
当存在时，@diffusion(可为Event元素的8比特整数属性)可表示时间周期T(秒)。散布参数的目的是使服务器负荷的峰值平滑。接收机应该会按照10毫秒的增量计算范围0-T内的随机时间，并且在访问互联网服务器之前延迟该时间量以检索TPT中的URL所参考的内容。
当存在时，Data(是Event元素的子元素)可提供与事件相关的数据。Event的不同激活可具有与其关联的不同Data元素。data元素可包括@dataID属性。@dataID(是16比特整数属性)可在包含其的Event元素的范围内唯一地标识Data元素。当事件的激活具有与其关联的数据时，激活触发可通过AppID、EventID和DataID的组合来标识Data元素。data元素指示用于事件的数据。一个event元素可具有多个data元素。利用data元素的@dataID属性来标识数据。在接收机中，如果与数据相关的事件被激活，则激活触发(或AMT中的激活元素)可通过AppID、EventID和DataID的组合来标识Data元素。AMT将在下面详细描述。
图7是示出“Frequency of Use”属性值的含义的示图。
“含义”列指示包含该应用的片段的发生频率。(当然，属性可在单个片段内出现多次。)如果globalID属性不存在，则frequencyOfUse属性无法存在。如果应用将被缓存并且稍后将被再次使用，则接收机需要在它再次出现时识别出它是同一应用。这需要globalId属性。
图8是示出“destination”属性值的含义的示图。
如图8所示，destination属性值0指示“预留”，destination属性值1指示仅主装置，destination属性值2指示仅一个或更多个副装置，destination属性值3指示主装置和/或一个或更多个副装置。
图9、图10、图11、图12和图13是示出TDO参数表的二进制形式的句法的实施方式的示图。
这是上述TPT结构的二进制格式。此格式是当在NRT中发送TPT时所需的格式，并且使得在NRT中合适地发送TPT的XML结构。
相对于二进制版本，TPT的XML版本中所包含的以下元素和/或属性可被省略，因为它们可由广播流中用于传送二进制表的封装头提供：@protocolVersion(主/次)、@serviceID和@tptVersion。
字段的语义如下。将顺序描述图9、图10、图11、图12和图13的TDO参数表的二进制格式的字段。
expire_date_included(可为1比特字段)可指示是否包括expire_date字段。值“1”可表示包括该字段；值“0”可表示不包括该字段。
segment_id_length(可为5比特字段，可指示segment_id字段的长度(字节)。
segment_id(为可变长度的字段)可包含字段id(可具有与TPT XML格式的“id”属性相同的语义)的字节。
base_URL_length(可为8比特字段)可指示base_URL字段的长度(字节)。
base_URL(为可变长度的字段)可包含基本URL(可具有与TPT XML格式的baseURL属性相同的语义)的字节。
当存在时，expire_date(可为32比特字段)可指示此TPT实例中包括的信息的期满日期和时间。如果接收机缓存TPT，则它可被重用直至expireDate。无符号整数可被解释为自1980年1月6日00:00:00UTC起的GPS秒数减去GPS-UTC_offset。GPS UTC偏移可以是定义GPS与UTC时间标准之间的总当前偏移(秒)的8比特无符号整数。
trigger_server_URL_length(可为8比特字段)可指示trigger_server_URL字段的长度(字节)。当此字段的值为0时，可指示各个激活触发的互联网传送不可用。
当trigger_server_URL_length字段的值为0时，trigger_server_URL可包含触发服务器URL(可具有与TPT XML格式的LiveTrigger元素的URL属性相同的语义)的字节。
trigger_delivery_type(可为1比特字段)可指示各个激活触发经互联网的传送模式。值“0”可指示使用HTTP短轮询；值“1”可指示使用HTTP长轮询或HTTP流。
poll_period(可为8比特整数)可指示当使用HTTP短轮询时推荐的轮询之间的秒数。
num_apps_in_table(可为8比特字段)可指示此TPT实例中描述的应用(TDO)数量。
app_id(可为16比特字段)可包含此应用(num_apps_in_table循环的此迭代中描述的应用)的标识符。它在此TPT实例中可为唯一的。
app_type_included(可为1比特字段)可指示针对此应用是否包括app_type字段。值“1”可表示包括该字段；值“0”可表示不包括该字段。
app_name_included(可为1比特字段)可指示针对此应用是否包括app_name字段。值“1”可表示包括该字段；值“0”可表示不包括该字段。
global_id_included(可为1比特字段)可指示针对此应用是否包括global_id字段。值“1”可表示包括该字段；值“0”可表示不包括该字段。
app_version_included(可为1比特字段)可指示针对此应用是否包括app_version字段。值“1”可表示包括该字段；值“0”可表示不包括该字段。
cookie_space_included(可为1比特字段)可指示针对此应用是否包括cookie_space字段。值“1”可表示包括该字段；值“0”可表示不包括该字段。
frequency_of_use_included(可为1比特字段)可指示针对此应用是否包括frequency_of_use字段。值“1”可表示包括该字段；值“0”可表示不包括该字段。
expire_date_included(可为1比特字段)可指示针对此应用是否包括expire_date字段。值“1”可表示包括该字段；值“0”可表示不包括该字段。
当存在时，app_type(可为8比特字段)可指示此应用的格式类型。值0可指示应用是TDO。如果此字段不存在，则该值可默认为0。其它值可表示其它格式。
当存在时，app_name_length(可为8比特字段)可指示紧随其之后的app_name字段的长度(字节)。此字段的值0可指示针对此应用不存在app_name字段。
当存在时，app_name(为可变长度的字段)可具有与TPT XML格式中的TDO元素的appName属性相同的语义。
当存在时，global_id_length(可为8比特字段)可指示紧随其之后的global_id字段的长度(字节)。此字段的值0可指示针对此应用不存在global_id字段。
当存在时，global_id(为可变长度的字段)可具有与TPT XML格式中的TDO元素的globalId属性相同的语义。
当存在时，app_version(可为8比特字段)具有与TPT XML格式中的TDO元素的appVersion属性相同的语义。
当存在时，cookie_space(可为8比特字段)可具有与TPT XML格式中的TDO元素的cookieSpace属性相同的语义。
当存在时，frequency_of_use(可为8比特字段)可具有与TPT XML格式中的TDO元素的frequencyOfUse属性相同的语义。
当存在时，expire_date(可为8比特字段)可具有与TPT XML格式中的TDO元素的expireDate属性相同的语义。
test_app(可为1比特字段)可指示此应用是否为测试应用，旨在被普通接收机忽略。值“1”可表示它是测试应用；值“0”可表示它不是测试应用。
available_on_internet(可为1比特字段)可指示此应用是否可经由互联网得到。值“1”可表示它可经由互联网得到；值“0”可表示它不可经由互联网得到。
available_in_broadcast(可为1比特字段)可指示此应用是否可经由广播得到。值“1”可表示它可经由广播得到；值“0”可表示它不可经由广播得到。
number_URLs(可为4比特字段)可指示包括此应用的文件的数量。
URL_length(可为8比特字段)可指示跟随其之后的URL字段的长度。
URL(为可变长度的字段)可具有与TPT XML格式中的TDO元素的URL属性相同的语义。
number_content_items(可为8比特字段)可指示将被下载以便于此应用使用的内容项的数量。
updates_avail(可为1比特字段)可指示此内容项是否将被不时地更新(即，它是一组静态文件还是实时数据馈送)。值“1”可指示它将被更新；值“0”可指示它将不被更新。
avail_internet(可为1比特字段)可指示包括此内容项的文件是否可经由互联网下载。值“1”可表示它们可经由互联网下载；值“0”可表示它们不可用。
avail_broadcast(可为1比特字段)可指示包括此内容项的文件是否可经由广播下载。值“1”可表示它们可经由广播下载；值“0”可表示它们不可用。
content_size_included(可为1比特字段)可指示针对此应用是否包括content_size字段。值“1”可表示包括该字段；值“0”可表示不包括该字段。
number_URLs(可为4比特字段)可指示包括此内容项的文件的数量。
URL_length(可为8比特字段)可指示跟随其之后的URL字段的长度。
URL(为可变长度的字段)可具有与TPT XML格式中的TDO元素的ContentItem子元素的URL属性相同的语义。
content_size(可为24比特字段)可具有与TPT XML格式中的TDO元素的ContentItem子元素的contentSize属性相同的语义。
num_content_descriptors(可为8比特字段)可指示紧随其之后的描述符循环中的内容描述符的数量。
content_descriptor()(为可变长度的字段)可以是符合MPEG-2描述符格式(标签、长度、数据)的描述符。它可提供关于此内容项的附加信息。在此描述符循环中可包括的描述符当中可有Capabilities描述符，指示此内容项的有意义的呈现所需的接收机能力。
number_events(可为8比特字段)可指示针对此TDO定义的事件的数量。
event_id(可为16比特字段)可包含此事件(number_events循环的此迭代中描述的事件)的标识符。它在此应用的范围内可为唯一的。可在激活触发内通过app_id和event_id的组合来参考事件。
action(可为5比特字段)可具有与TPT XML格式中的TDO元素的Event子元素的action属性相同的语义。
destination_included(可为1比特字段)可指示针对此事件是否包括destination字段。值“1”可指示包括该字段；值“0”可指示不包括该字段。
diffusion_included(可为1比特字段)可指示针对此事件是否包括diffusion字段。值“1”可指示包括该字段；值“0”可指示不包括该字段。
data_included(可为1比特字段)可指示针对此事件是否包括data_size和data_bytes字段。值“1”可指示包括这些字段；值“0”可指示不包括这些字段。
当存在时，destination字段的语义可与TPT XML格式中的TDO元素的Event子元素的destination属性的语义相同。
当存在时，diffusion字段的语义可与TPT XML格式中的TDO元素的Event子元素的diffusion属性的语义相同。
当存在时，data_size字段可指示紧随其之后的data_bytes字段的大小。
当存在时，data_bytes字段可提供与此事件相关的数据。每当事件被激活时，目标应用将能够读取数据并使用它来帮助执行期望的动作。除了此字段可包含原二进制值，而TPT XML格式中的Data元素可包含二进制值的base64编码以外，此字段的内容可与TPT XML格式中的对应TDO元素的对应Event子元素的对应Data子元素的内容相同。
num_app_descriptors(可为8比特字段)可指示紧随其之后的描述符循环中的描述符的数量。
app_descriptor()(为可变长度的字段)可以是符合MPEG-2描述符格式(标签、长度、数据)的描述符。它可提供关于此应用(TDO)的附加信息。在此描述符循环中可包括的描述符当中有Capabilities描述符，指示此应用的有意义的呈现所需的接收机能力。
num_TPT_descriptors(可为8比特字段)可指示紧随其之后的描述符循环中的描述符的数量。
TPT_descriptor()(为可变长度的字段)可以是符合MPEG-2描述符格式(标签、长度、数据)的描述符。它可提供关于此TPT的附加信息。在此描述符循环中可包括的描述符当中有Capabilities描述符，指示此TPT所表示的交互服务的有意义的呈现所需的接收机能力。
图14是示出激活消息表结构的实施方式的示图。以下将描述表中包括的字段。表中包括的字段的大小和字段的类型可根据设计者的意图而增加或改变。
激活消息表(AMT)可包含片段的激活触发的等同物。在特定环境下，可代替激活触发将它传送给接收机。可通过ACR服务器、通过“即时触发”服务器以及经由AMT在隐藏字幕流中传送触发。
AMT结构中的字段的详细语义如下：
激活消息表(AMT)可包括@majorProtocolVersion、@minorProtocolVersion、@segmentId、@beginMT属性和/或Activation元素。
@majorProtocolVersion(可为AMT元素的4比特属性)可指示AMT定义的主版本号。主版本号可被设定为1。接收机应该会丢弃指示它们不能支持的主版本值的AMT的实例。
当存在时，@minorProtocolVersion(可为AMT元素的4比特属性)可指示AMT定义的次版本号。当不存在时，该值可默认为0。次版本号可被设定为0。接收机应该会不丢弃指示它们不能支持的次版本值的AMT的实例。在这种情况下，它们应该会忽略它们不支持的任何单独的元素或属性。
@segmentID(是AMT的标识符)匹配包含应用了此AMT中的激活的应用和事件的TPT的标识符。@segmentId可用作AMT的标识符。因此，接收机可接收并解析AMT以经由@segmentId信息标识AMT。@segmentId包含指示AMT应用于哪一片段的信息，匹配与片段相关的TPT的@id，并且用于连接AMT和TPT。另外，可标识片段以提供标识AMT的activation元素的目标TDO和事件所需的基本信息。
当存在时，@beginMT(是AMT元素的属性)可指示此AMT实例提供激活时间的片段的开始媒体时间。@beginMT可指示相对于将应用AMT的片段的媒体时间的开始。因此，可决定由activation元素指示的激活发生时的时间标准。因此，如果@beginMT存在，则activation元素中的@startTime属性可受@beginMT所指示的媒体时间的开始影响。
AMT的Activation元素的各个实例可表示在特定时间利用与特定事件关联的特定数据激活该事件的命令。多个activation元素可存在于AMT中。各个activation元素扮演类似于激活触发的角色。activation元素可应用于AMT中的@segmentId所指示的片段。activation元素的属性可包含关于激活发生在哪一应用中、激活发生在哪一事件中、激活何时发生等的信息。activation元素的属性将在下面详细描述。
activation元素可包括@targetTDO、@targetEvent、@targetData、@startTime和/或@endTime属性。
@targetTDO(是Activation元素的属性)可匹配AMT所关联的TPT中的TDO元素的appID属性，从而标识激活命令的目标应用。@targetTDO可包含AMT的activation元素应用于哪一应用的信息。接收机可接收并解析AMT以获得@targetTDO并在匹配TPT的TDO元素中寻找@appID，以标识将应用activation元素的应用。
@targetEvent(是Activation元素的属性)可匹配targetTDO属性所标识的TDO元素中所包含的Event元素的eventID属性，从而标识激活命令的目标事件。@targetEvent可包含AMT的activation元素应用于哪一应用的哪一事件的信息。接收机可接收并解析AMT以获得@targetEvent并在匹配TPT的TDO元素中寻找@eventID以标识将应用activation元素的事件。
@targetData(是Activation元素的属性)可匹配由targetTDO和targetEvent属性标识的Event元素中所包含的Data元素的dataID属性，从而标识当激活命令应用时将与目标事件关联的数据。@targetData可标识当激活命令应用时与目标事件相关的数据。接收机可接收并解析AMT以获得@targetData并在TPT的event元素中寻找@dataID。
@startTime(是event元素的属性)可指示与媒体时间相关的事件的有效时间周期的起始。接收机应该会在媒体时间到达startTime中的值时或者在之后尽快地执行命令。@startTime可指示事件发生时的起始时间。此起始时间基于媒体时间。接收机可解析AMT以获得@startTime信息并利用@startTime确认事件发生时的时间。如果基于由@segmentId标识的片段的媒体时间，媒体时间到达startTime，则接收机可激活事件。如果startTime已过去，则可尽快激活事件。
当存在时，@endTime(是event元素的属性)可指示相对于媒体时间的事件的有效时间周期的结束。接收机应该会在媒体时间超过endTime中的值时不执行命令。@endTime可指示事件的结束时间。如果媒体时间到达endTime，则接收机可不执行事件。
AMT中的Activation元素可按照startTime值的升序出现。
当接收机根据AMT中的Activations激活事件时，它应该会在其startTime或者之后尽快地(例如，在接收机加入服务并且在startTime之后endTime之前的某一时间接收AMT的情况下)应用各个激活。如果TPT中的event元素的“action”属性为“exec”，则接收机应该会将TriggerEvent变成目标应用。TriggerEvent将在下面与API相关的部分中描述。
图15是示出URL List结构图的实施方式的示图。
URL List可包含接收机的可能使用的特定URL。URL list可包括以下URL等。
1.一个或更多个未来片段的TPT的URL，使得接收机能够预先下载文件。
2.可从其检索关于广播流中的独立NRT服务的信息的NRT信令服务器的URL，使得接收机即使无法访问广播流中传输的NRT服务信令的传送也能访问那些服务。
3.可针对虚拟信道发送使用报告的使用报告服务器的URL，使得接收机即使无法访问广播流中此URL的传送也能够在这些报告中发送。
4.虚拟信道的PDI-Q表的URL，使得接收机即使无法访问广播流中传送的PDI-Q表也能够使观看体验个性化。(PDI-Q表与在提供交互服务时进行个性化以提供用户定制的服务相关。可就经由PDI-Q表的个性化询问用户。)
除了别的以外，可相对于UrsUrl元素使URL list进一步指示用于使用报告的服务器的URL，以便使用优选数据和当前通过商业接收机观看和消费的内容的类型。URL list中所包括的UrsUrl元素可如下不同地解释。
首先，在使用报告服务器的情况下，接收机可利用使用报告服务器的URL通过预定协议(例如，数据结构、XML文件等)执行接收机的使用报告功能。
其次，可能存在于接收机的网络浏览器上执行的TDO。在这种情况下，这指示使用报告TDO的位置。在这种情况下，TDO可利用接收机的网络浏览器的API(例如，文件API或使用报告API)直接收集并报告关于存储在接收机中或者当前消费的内容的信息。TDO可利用称为XMLHttpRequest的Javascript API发送所收集的数据。
URLlist可包括UrlList、TptUrl、UrsUrl和/或PdiUrl。这些元素的语义如下。
TptUrl(是UrlList元素的元素)可包含当前交互附属服务中的未来片段的TPT的URL。当包括多个TptUrl元素时，它们可按照片段在广播中出现的顺序来排列。
NrtSignalingUrl(是UrlList元素的元素)可包含接收机可从其获得当前传输流中的所有虚拟信道的NRT信令表的服务器的URL。
UrsUrl(是UrlList元素的元素)可包含接收机可向其发送当前虚拟信道的使用(受众测量)报告的服务器的URL。
PdiUrl(是UrlList元素的元素)可包含当前虚拟信道的PDI-Q表的URL。
图16是示出包含TPT的私有区段的二进制格式的实施方式的示图。图16示出按照将在下面描述的传送机制在广播流中传送TPT的情况。细节稍后描述。
将描述传送触发、TPT等的传送机制。将顺序描述从交互服务创建的输出、广播流中的触发的传送、经由互联网的时基触发的传送、经由互联网的激活触发的传送(ACR场景)、广播流中的TPT的传送、经由互联网的TPT的传送、移动TDO和内容项、将多个片段组合成一个片段。
以下将描述从交互服务创建的输出。
针对片段的服务创建的处理可得到包含所有TDO和其它内容项、XML格式的TPT文件和XML格式的AMT文件的文件夹。可创建其它结果。
以下将描述广播流中的触发的传送。
当在广播流中传送时，可在DTV隐藏字幕信道中、在Service#6中、在URLString命令中传送触发。
如果触发的长度小于或等于26个字符，则它可不分段地发送(Type＝11)。如果触发的长度为27至52个字符，则它可在两个片段中发送(第一片段在Type＝00片段中，第二片段在Type＝10片段中)。
在命令的任何给定实例中传送的URI的类型可由8比特参数给出。
对于使用TDO模型的交互服务，URI数据结构的URI类型可被设定为0(用于TDO模型的交互TV触发)。这种传送机制包括时基触发和激活触发二者。
在经由广播流(在隐藏字幕服务#6中)传送时基触发的情况下，如果缺少“m＝”项，则时基触发可简单地传送信令服务器的URL。并且如果缺少“m＝”项，则激活触发必然缺少“t＝”项。
在经由广播流(在隐藏字幕服务#6中)传送激活触发的情况下(即，在“Trigger”格式带有“e＝”项，带有或不带有“t＝”项的情况下)，如果“t＝”项存在，则激活时间可以是相对于时基的时间戳。并且如果缺少“t＝”项，则激活时间可以是消息的到来时间。
在经由CC服务#6传送时基触发和激活触发的情况下，广播商处理时基触发和激活触发可有三种可能的方式。这三种方式是“没有显式时基的片段模式”、“具有显式时基的片段模式”和“具有显式时基的服务模式”。
这些方式可逐片段地在广播内混合。
在没有显式时基的片段模式下，激活消息不包括时间戳，因此各个消息的激活时基可以是消息的传送时间，并且时基消息也不包括时间戳，因此它们的仅有目的可为提供可传送TPT文件的信令服务器的URL。在这种模式下甚至可完全省略时基消息，依赖于激活消息中的URL来提供信令服务器的URL，但是这样的话接收机在第一激活消息出现之前将无法检索TPT并开始下载TDO，相当大地延迟了对第一激活消息的响应。
在这种情况下，可出现在CC服务#6中的时基消息可包含“Trigger”格式的“locator_part”并且可能包含“spread”项，但是不包含“media_time”项，可出现在CC服务#6中的激活消息可包含“Trigger”格式的“locator_part”、“event_time”项并且可能包含“spread”项，但是在“event_time”项中没有“t＝”部分。时基消息和激活消息二者的“locator_part”可以是当前segmentId。此URL还可用于经由互联网检索片段的TPT。
在具有显式时基的片段模式下，时基消息包括时间戳以限定时基，激活消息可能包括时间戳以限定相对于时基的激活时间，或者它们可能不包括时间戳，表示激活时间是消息的到来时间。
在这种情况下，可出现在CC服务#6中的时基消息可包含“Trigger”格式的“locator_part”、“media_time”项并且可能包含“spread”项，可出现在CC服务#6中的激活消息可包含“Trigger”格式的“locator_part”、“event_time”项并且可能包含“spread”项，在“event_time”项中有或没有“t＝”部分。时基消息和激活消息二者的“locator_part”可以是当前segmentId，并且时基是片段特定的。此URL还可用于经由互联网检索片段的TPT。
在具有显式时基的服务模式下，时基消息包括时间戳以限定时基，激活消息可能包括或者可能不包括时间戳。时基可延伸跨过多个片段，而不是单个片段所特定的。时基消息的“locator_part”可以是时基的标识符，并且URL还可用于经由互联网检索服务的TPT。
在任何情况下，将触发插入CC服务#6中的触发插入服务器均应该从AMT开始工作，将激活消息从AMT中的XML格式转化成CC服务#6中的传送所指定的触发格式。在没有endTime属性的Activation元素的情况下，可利用等于startTime属性的激活时间插入单个触发。在具有startTime和endTime元素二者的Activation元素的情况下，可利用相同的目标插入触发序列。序列中的第一触发可具有等于startTime属性的激活时间，序列中的最后触发可具有等于endTime属性的激活时间，并且序列中的触发的激活时间之间可存在固定的时间间隔(除了序列中的倒数第二个触发与最后触发之间的间隔可较短以外)。此固定的时间间隔的长度可为可配置的。
当时基消息和激活消息处于片段模式时，时基可为片段特定的。它可从片段开始处的“beginMT”值开始并且贯穿整个片段。各个Activation的“startTime”和“endTime”值可以是相对于“beginMT”值的值。当时基消息和激活消息处于服务模式时，时基可跨越片段，并且可考虑服务时基和广播调度来调节各个片段的“beginMT”值。
以下将描述经由互联网的时基触发的传送。
时基触发的互联网传送可用在所谓的自动内容识别(ACR)情形中，其中时基触发的接收者无法访问隐藏字幕服务#6。在这些情况下，接收机需要使用ACR以便识别视频帧并使时基与它们同步。在ACR情形中，可从水印或者从ACR服务器获得时基消息。在从ACR服务器接收的情况下，时基消息作为来自ACR服务器的响应而传送。
以下将描述经由互联网的激活触发的传送(ACR情形)。
激活消息可经由短轮询、长轮询或流来传送，但是所有这些均会给接收机和服务器带来大量开销。激活消息还可按照AMT的形式来传送，但是这可提供大量关于片段长度的信息，以方便广告杀手。可存在其它另选方案。
在以激活触发的形式传送激活消息的情况下，即，在具有“e＝”项、具有或没有“t＝”项的“Trigger”格式的情况下，这可经由HTTP短轮询、长轮询或流来传送。
当经由互联网传送时，激活消息可利用机制：单独激活触发传送机制和整体激活触发传送机制中的任一者或二者来传送。
以下将描述单独激活触发传送。
如上所述，当经由互联网传送单独的激活触发时，它们可利用HTTP短轮询、长轮询或流来传送。激活触发的格式可与经由DTVCC服务#6传送时的格式完全相同。
在短轮询的情况下，必须指定轮询周期。在此周期中，可利用如下所述的TPT中所包括的pollPeriod来设定短轮询操作。
当激活触发的互联网传送可用时，TPT中的LiveTrigger元素的URL属性可指示可传送激活触发的激活触发服务器。如果TPT中存在LiveTrigger元素的pollPeriod属性，则这可指示使用HTTP短轮询，并且可指示接收机的轮询周期应该使用。如果TPT中不存在LiveTrigger元素的pollPeriod属性，则这可指示使用HTTP长轮询或HTTP流。
不管使用哪一协议，接收机应该会利用查询项来向激活触发服务器发出HTTP请求：
？mt＝<media_time>
其中<media_time>可以是观看的内容的当前媒体时间。
如果使用短轮询，则来自激活触发服务器的响应可包含在<media_time>处结束的长度为pollPeriod的时间间隔内发出的所有触发。如果返回一个以上激活触发，则它们可通过一个或更多个空格字符分开。如果没有返回激活触发，则响应可为空。
如果使用HTTP长轮询或HTTP流，则激活触发服务器可等待返回响应，直至将在广播流中传送激活触发时的媒体时间。此时它可返回激活触发。
如果使用HTTP长轮询，则激活触发服务器可在返回激活触发之后关闭会话。接收机应该会利用更新的媒体时间立即发出另一请求。
如果使用HTTP流，则激活触发服务器在返回各个激活触发之后保持会话打开，并且当到时间传送另外的激活触发时它可经该会话传送这些激活触发。
在所有情况下，HTTP响应均可包含以下形式之一的HTTP响应头字段以用信号通知传送模式：
ATSC-Delivery-Mode：ShortPolling[<poll-period>]
ATSC-Delivery-Mode：LongPolling
ATSC-Delivery-Mode：Streaming
<poll-period>参数可指示用于后续轮询的推荐的轮询之间的间隔。<poll-period>可省略。
以下将描述整体激活触发传送。
当经由互联网整体传送激活触发时，片段的激活触发可随片段的TPT一起经由HTTP以多部分MIME消息的形式传送，其中TPT作为消息的第一部分，激活消息表(AMT)作为消息的第二部分。
以下将描述广播流中的TPT的传送。
当在广播流中传送时，可将TPT从其XML格式转化成等同二进制NRT风格信令表格式并封装在NRT风格私有区段中，每一个表实例一个TPT。当前片段的TPT总是存在。一个或更多个未来片段的TPT也可能存在。TPT实例由其segment_id字段的值定义。作为参考，上面描述了TDO参数表的二进制格式。这里，NRT风格私有区段可对应于图16的tpt_section()。
总而言之，为了按照NRT发送TPT的二进制结构，TPT可具有适合于NRT传输的区段结构。以下将详细描述此处理。
可通过将各个TPT划分成块并将这些块插入具有table_id、protocol_version、TPT_data_version和sequence_number字段的公共值的区段的tpt_bytes()字段中，来将各个TPT封装在NRT风格私有区段中。可按照section_number字段值的升序将这些块插入区段中。可在TPT所属的虚拟信道的IP子网的服务信令信道(SSC)中承载私有区段。这里，“服务信令信道”定义在ATSC-NRT标准中，意指具有特定IP地址和端口号的信道。区段中的sequence_number字段可用于区分同一SSC中承载的不同TPT实例。
以下将描述图16的字段。
私有区段(tpt_section())可包括table_id、protocol_version、sequence_number、TPT_data_version、current_next_indicator、section_number、last_section_number、service_id和/或tpt_bytes()信息。
table_id(可为8比特字段)可将此表区段标识为属于TDO参数表实例。
protocol_version可被分成两个部分。此8比特无符号整数字段的高位4比特可指示此表以及其中承载的TPT实例的定义的主版本号，低位4比特可指示次版本号。主版本号可被设定为1。接收机应该会丢弃指示它们不能支持的主版本值的AMT的实例。次版本号可被设定为0。接收机应该会不丢弃指示它们不能支持的次版本值的AMT的实例。在这种情况下，它们应该会忽略它们不能识别的任何描述符，并且忽略它们不支持的任何字段。
sequence_number可以是8比特字段。sequence_number的值可与此TPT实例的所有其它区段的sequence_number相同，并且不同于此服务信令信道中的任何其它TPT实例的sequence_number。因此，此字段可扮演不同于其它TPT实例的角色。sequence_number字段可指示此区段中与服务信令信道关联的IP子网。不同TPT实例的sequence_number字段的值可反映片段出现在广播流中的顺序。
TPT_data_version(可为5比特字段)可指示此TPT实例的版本号，其中TPT实例可由其segment_id定义。由于TPT版本是预先已知的，以便确定接收的TPT区段数据是否为新版本TPT，所以TPT_data_version字段可存在于区段表中。当TPT实例中的任何字段改变时，版本号可增加1模32。
current_next_indicator(可为1比特指示符)对于TPT区段可总是被设定为“1”，以指示发送的TPT对于由其segment_id标识的片段而言总是为当前TPT。
section_number(可为8比特字段)可给出此TPT实例区段的区段号，其中TPT实例可由其segment_id标识。TPT实例中的第一区段的section_number可为0x00。TPT实例中每增加一个区段，section_number可增加1。
last_section_number(可为8比特字段)可给出此区段所属的TPT实例的最后区段(即，具有最高section_number的区段)的编号。
service_id(可为16比特字段)可指定与提供此表实例中描述的内容项的交互服务关联的service_id。
tpt_bytes()(为可变长度的字段)可包括部分地由此区段承载的TPT实例的块。当此表实例的所有区段的tpt_bytes()字段按照其section_number字段的顺序级联时，结果可为完整的TPT实例。
即，在使用TPT的二进制格式或者XML格式改变为二进制格式之后，TPT可被划分以适合于NRT传输，被包括在私有区段的tpt_bytes()字段中，并按照NRT发送。此时，如果一个TPT被分成多个私有区段，则这些私有区段可具有相同的table_id、protocol_version、TPT_data_version和sequence_number值。划分的TPT块可按照section_number字段值的顺序插入。
接收机可解析接收的私有区段。为了将私有区段再次组合成一个TPT，可使用具有相同table_id、protocol_version TPT_data_version和sequence_number值的私有区段。此时，可使用能够从section_number和last_section_number信息获得的顺序信息。如果具有相同table_id、protocol_version TPT_data_version和sequence_number值的所有私有区段的tpt_bytes()被顺序连接，则可创建一个TPT。
将参照图17详细描述经由互联网的TPT的传送。
以下将描述移动TDO和内容项。
网络和站将常常需要提供它们自己的HTTP服务器以用于传送TDO和TDO所使用的内容项(文件)。当这样做时，可调节TPT中的baseURL以反映服务器的位置。
以下将描述将多个片段组合成一个片段。
为了彻底地使片段之间的边界模糊，用于多个片段的TPT和AMT可被组合成单个TPT和AMT。可执行以下步骤。
1.标识将要组合的片段的集合。
2.利用新segmentId创建新TPT。
3.如果被组合的任何片段具有即时激活，则提供支持所有这些激活的访问的中继服务器，并将用于此服务器的参数设置在“LiveTrigger”元素中。
4.根据需要应用各个片段的baseURL以得到完整TDO和ContentItem URL。(可标识被组合的所有片段所共同的较短baseURL，并将其保持作为组合的片段的baseURL。)
5.根据需要修正appId值以去除冲突。
6.将被组合的所有片段的所有修正的TDO元素插入到新TPT中。
7.创建具有与组合的TPT的新segmentId相同的segmentId的新AMT。
8.为新AMT选择适当的新“beginMT”值。
9.针对被组合的片段调节AMT文件中的所有Activation元素的targetId值以反映appId值的任何变化。
10.针对被组合的片段调节AMT文件中的所有Activation元素的startTime和endTime值以反映被组合的片段的新“beginMT”值和广播调度。
11.将所有修正的Activation元素插入到新AMT中。
图17是示出被编码为XML文档的URL列表的实施方式的示图。
以下将描述经由互联网的TPT的传送。
当经由互联网传送时，可经由HTTP传送TPT。在时基消息中用于当前片段的TPT的URL可以是“<domain name part>/<directory path>”。对TPT请求的响应可仅包括TPT，或者可包括被编码为XML文档的2部分MIME消息，其中请求的TPT在第一部分中，URL的列表在第二部分中。(对请求的响应将总是包括用于当前片段的TPT。它也可包括用于一个或更多个未来片段的TPT。)
作为上述响应的第二部分的URL可具有图17所示的格式。
将描述图17的元素的语义。
“UrlList”可包含接收机可用的URL的列表。
“TptUrl”可包含用于未来片段的TPT的URL。当包括多个TptUrl元素时，它们可按照片段在广播中出现的顺序来排列。
“NrtSignalingUrl”可包含接收机可从其获得针对当前广播流中的所有虚拟信道的NRT信令表的服务器的URL。
图18是示出addTriggerEventListener的实施方式的示图。
以下将描述用于执行DO的环境的ATSC JavaScript API。
为了支持声明对象动作与广播节目的同步，可针对视频/广播对象支持附加方法。
如果经由DTVCC或互联网接收到TPT，则执行TDO的多个事件可存在于TPT中，这些事件可通过激活触发来激活。
为了处理此事件，可基于eventID注册Listener函数。因此，作为上述“附加方法”，可存在两个函数addTriggerEventListener和removeTriggerEventListener以用于注册Listener函数。
在图18中，描述addTriggerEventListener并且示出格式、参数等。
addTriggerEventListener函数可注册用于处理基于eventId产生的事件的回调函数(listener函数)。addTriggerEventListener函数可接收EventListener类型的listener和Number类型的eventId作为参数。EventListener类型将在下面描述。addTriggerEventListener函数可不具有返回值(void)。这里，eventId参数可以是TPT的event元素中的event ID。这里，listener参数可以是用于该事件的监听器。
一接收到激活消息，接收机的触发处理模块就可利用“addTriggerEventListener”函数基于eventId注册listener函数。如果事件被激活，则可调用注册的listener函数。此时，可将TriggerEvent类型的对象传送给listener函数。TriggerEvent类型将在下面描述。
图19是示出removeTriggerEventListener的实施方式的示图。
在图19中，描述removeTriggerEventListener并且示出格式、参数等。
removeTriggerEventListener函数可取消用于处理基于eventId产生的事件的回调函数(listener函数)的注册。removeTriggerEventListener函数可接收EventListener类型的listener和Number类型的eventId作为参数。EventListener类型将在下面描述。removeTriggerEventListener函数可不具有返回值(void)。这里，eventId参数可以是TPT的event元素中的event ID。这里，listener参数可以是用于该事件的监听器。
在javascript程序中，如果期望不再接收可基于eventId产生的事件或者如果程序“DestroyWindow”完成，则可取消利用“removeTriggerEventListener”注册的listener函数。
图20是示出EventListener类型的定义的实施方式的示图。
这里，EventListener类型的定义符合Web接口定义语言(Web IDL)。Web IDL可用于描述旨在实现在网络浏览器中的接口。Web IDL是IDL变体，其具有多个特征以使得web平台中的公共脚本对象的行为能够被更容易地指定。
EventListener可以是接口对象。EventListener类型可具有TriggerEvent类型的事件作为参数。
图21是示出TriggerEvent类型的定义的实施方式的示图。
TriggerEvent类型可包含关于事件的信息。
TriggerEvent类型可具有eventId、data和status作为性质。这里，eventId可以是TPT的event元素中的eventID。这里，data可以是用于事件的此激活的数据。这里，data可为十六进制。这里，status可表示事件的状态。这里，如果status值为“trigger”，则意指通过激活触发激活事件的状态。如果status值为“error”，则意指发生错误的状态。
已描述了TDO模型。以下将描述直接执行模型。
在直接执行模型中，一选择虚拟信道就可自动启动声明对象(DO)。其可经互联网与后端服务器通信以得到提供交互特征–在屏幕上的特定位置创建显示，进行轮询，启动其它专用DO等(全部与音频-视频节目同步)的详细指令。
以下将描述直接执行模型中的触发操作。
在直接执行模型中触发的角色、功能和句法没有很大地改变。
触发的性能与上面所述相同。
触发句法与上面所述相同。
触发可被视为包括三个部分。
<domain name part>/<directory path>[？<parameters>]
在直接执行模型中，<domain name part>和<directory path>的组合可唯一地标识将要启动的DO。
<parameters>可包括“event_time”、“media_time”或“spread”中的一个或更多个。
在直接执行模型中，一选择虚拟信道就自动启动应用。应用可经由“同步内容协议”经互联网与后端服务器通信。服务器可给出用于提供交互特征的详细指令(全部与音频-视频节目同步)。
在直接执行模型的情况下，由于立即执行应用，所以可在传送时基触发时将信息传送给当前执行的应用。在此模型中，应用需要向服务器连续传送关于当前广播的内容的信息以便于同步。为此，时基触发还可包括不同于TDO模型的特殊信息。此特殊信息可以是当前广播的内容的标识符。
类似地，内容标识符可按照参数的形式存在于触发的参数部分中。
类似地，内容标识符可按照一项的形式存在于触发的media_time中。可由“c＝”以及随后的字符串指定的内容标识符项(可称为content_id)可表示当前观看的内容的标识符。
content_id项可旨在支持交互服务实现的直接执行模型。
如上所述，在此模型中，具有content_id项的时基触发可在其启动之后被变成应用，并且应用可将content_id传送给后端服务器以便标识交互的上下文。其详细操作将在下面描述。
直接执行模块中的触发的传送机制与上面所述相同。
然而，在广播流中的触发传送的情况下，可在DTV隐藏字幕信道、在Service#6中、在URLString命令中传送触发。并且对于使用直接执行模型的交互服务，URI_type字段可被设定为2(用于直接执行模型的交互TV触发)。
以下将描述直接执行模块的总体操作。
作为执行交互服务的一个模型，在直接执行模型中，一选择虚拟信道就可自动启动应用。应用可经由“同步内容协议”经互联网与后端服务器通信。服务器可给出用于提供交互特征？在屏幕上的特定位置创建显示，进行轮询，启动其它专用DO等(全部与音频-视频节目同步)的详细指令。
可如下执行操作。
首先，可启动应用。然后，接收时基触发。在执行应用之后将时基触发传送给应用。时基触发的content_id项可包括当前显示的内容的内容标识信息。应用可将content_id传送给后端服务器以便标识交互的上下文，并且以便标识当前观看的内容。
已描述了直接执行模型。
图22是示出用于WM方法的架构的示图。
将描述经由其它接口的传送。
定义在仅可访问未压缩的视频和音频(例如，从有线或卫星机顶盒接收)的环境中能够获取交互服务的协议和架构。所述架构和协议可被设计成由具有互联网连接并且仅能从广播流访问未压缩的音频和视频的接收机使用。当然，如果交互服务提供商选择支持它们，则所述架构和协议也可被成功使用。
所述架构可被设计成支持两个基本方法来标识观看的内容，以使得可经由互联网传送任何关联的交互服务数据增强。两个基本方法可以是水印和指纹。
在水印和指纹方法中，均旨在能允许接收机找出当前正在看什么节目并且获得URL，该URL可用作得到关于该节目的交互服务的附加信息的起始点。
图22示出用于WM方法的架构。
在用于WM方法的架构中，该架构可包括广播商22010、水印插入商22011、MVPD22020、STB 22030、接收机22040、WM客户机22050、TPT服务器22060和/或内容服务器22070。
广播商22010可以是输出音频/视频流以及与该音频/视频流相关的交互服务的源。TV台可以是广播商22010的示例。广播商22010可以是广播内容制造者或分销商。广播商可22010传送广播流、音频/视频内容、交互数据、广播调度或AMT。
水印插入商22011可将水印插入广播的音频/视频帧中。水印插入商22011可与广播商22010集成，或者可以是单独的模块。水印可以是接收机所需的信息。水印可以是诸如URL的信息。水印将稍后详细描述。
MVPD 22020是多程序视频节目分销商的缩写。MVPD 22020可以是有线运营商、卫星运营商或者IPTV运营商。MVPD 22020可从广播商/水印插入商接收广播流(在水印ACR系统的情况下，由水印插入商22011插入了水印)。MVPD 22020常常剔除音频和视频轨道以外的所有节目元素，并且将所得流发送给用户端的机顶盒(STB)。
STB 22030通常将音频和视频解码(解压缩)并且将其发送给电视机以便于呈现给观看者。STB可将未压缩的音频/视频内容发送给接收机22040。根据本发明的实施方式，STB可以是外部解码单元。
接收机22040可包括WM客户机22050。WM客户机22050可设置在接收机22040的外部。这里，接收机可以具有水印功能。接收机22040的结构将稍后描述。
WM客户机22050可从ACR服务器(未示出)获得激活触发并利用为这种目的提供的API将其变成主接收机码。通常，WM客户机22050将被内置于接收机中，但是其它配置也是可能的。WM客户机22050可从未压缩的音频/视频内容提取插入的水印。所述水印可以是诸如URL的信息。
TPT服务器22060可以是能够下载诸如TPT的应用的服务器。接收机22040将所提取的水印发送给ACR服务器。当该水印匹配存储在数据库(未示出)中的水印时，接收机22040可接收触发作为响应。当接收的触发可具有上述新locator_part或TPT，或者发现新版本的应用参数表时，接收机22040可请求TPT服务器22060以下载新TPT或应用参数表。
内容服务器22070可提供交互服务的提供所需的应用和TDO。当需要新应用或TDO时，可利用TPT或应用参数表中的URL来下载新应用。
在水印(WM)方法中，广播商/水印插入商可将水印插入广播音频或视频帧中。这些水印可被设计成向接收机承载适度量的信息，同时观看者难以察觉或者至少对观看者的干扰程度很低。这些水印可能直接提供接收机所需的信息，或者可能仅提供码值，接收机可经由互联网连接将该码值发送给远程服务器以便得到它们所需的信息。
图23是示出用于FP方法的架构的实施方式的示图。
在用于FP方法的架构中，该架构可包括广播商23010、MVPD 23020、STB 23030、接收机23040、FP客户机23050、TPT服务器23060、内容服务器23070、签名提取器23080和/或FP服务器23090。
广播商23010可以是输出音频/视频流以及与该音频/视频流相关的交互服务的源。TV台可以是广播商22010的示例。广播商22010可以是广播内容制造者或分销商。广播商22010可传送广播流、音频/视频内容、交互数据、广播调度或AMT。
MVPD 23020是多程序视频节目分销商的缩写。MVPD 22020可以是有线运营商、卫星运营商或者IPTV运营商。MVPD 23020常常剔除音频和视频轨道以外的所有节目元素，并且将所得流发送给用户端的机顶盒(STB)。
STB 23030通常将音频和视频解码(解压缩)并且将其发送给电视机以便于呈现给观看者。STB可将未压缩的音频/视频内容发送给接收机23040。根据本发明的实施方式，STB23030可以是外部解码单元。
接收机23040可包括FP客户机23050。FP客户机23050可设置在接收机23040的外部。这里，接收机23040可以具有指纹功能。接收机23040的结构将稍后描述。
FP客户机23050可从FP服务器23090获得激活触发并利用为这种目的提供的API将它们变成主接收机码。通常，FP客户机23050将被内置于接收机中，但是其它配置也是可能的。FP客户机23050可从未压缩的音频/视频内容提取指纹。所述指纹将稍后详细描述。
TPT服务器23060可以是能够下载诸如TPT的应用的服务器。接收机23060将所提取的指纹发送给FP服务器23090。当该指纹匹配签名提取器23080的签名时，接收机23040可接收触发作为响应。当接收的触发具有上述新locator_part或者发现新版本的TPT或应用参数表时，接收机22040可请求TPT服务器23060以下载新TPT或应用参数表。
内容服务器23070可提供交互服务的提供所需的应用和TDO。当需要新应用或TDO时，可利用TPT或应用参数表中的URL来下载新应用等。
签名提取器23080可从广播商23010接收元数据。签名提取器23080可从接收的元数据提取帧的签名。当发送给FP服务器23090的指纹匹配签名提取器23080的签名时，签名提取器23080可将与该签名相关的元数据传送给FP服务器23090。
FP服务器23090可执行与签名提取器23080的签名匹配操作。FP服务器23090可将签名与从接收机23040接收的指纹进行匹配。当签名匹配指纹时，FP服务器23090可从签名提取器23080接收与该签名相关的元数据。FP服务器23090可将元数据发送给接收机23040。
在指纹(FP)方法中，FP客户机23050可从音频或视频帧提取指纹(也可称为签名)并且对照来自该地区的多个广播商的广播帧的指纹数据库检查指纹以寻找接收机23040所需的信息。这些检查可由远程服务器通过签名进行然后得回具有期望的信息的记录，或者在一些情况下可通过对照下载到接收机23040中的签名数据库进行检查来完成。这里，远程服务器可以是FP服务器23090。
尽管水印和指纹可为不同的技术，但它们没有必要为彼此互斥的。很容易想到使用这两种技术的组合。术语自动内容识别(ACR)可用于单独地指这些技术中的任一个，或者指其任何组合。
接收机仅能从广播流访问未压缩的音频和视频的环境称为“ACR环境”。
在WM和FP两种情况下，接收机可使用URL作为起始点以获得交互服务内容(包括触发)。
在WM和FP两种情况下，定时信息可以是相对于广播侧时钟(其用于信道的时间临界事件的定时规范)的时间戳的形式，例如经互联网传送的触发中的激活时间戳。
假设广播商通常可为了从天线得到TV信号的接收机，支持直接在广播流中的交互服务的传送，并且为了得到未压缩音频和视频但具有互联网连接的接收机，还支持如上所述经互联网的交互服务的传送。然而，广播商可支持这两种传送机制中的任一个，而不支持另一个。
在水印仅提供码值的情况下用于水印方法的典型架构将看起来有点像图22和图23中的两个架构的组合。将存在水印插入商，如图22中一样，但它将插入码，而非接收机所需的信息。还将存在WM服务器，其扮演与图23中的FP服务器几乎一样的角色。接收机将向它发送码，而非签名，并且将得回它们所需的信息。
将描述访问交互服务。
访问交互服务的描述包括直接执行模型、具有独立于ACR服务器的激活的TDO模型、具有从ACR服务器接收的激活的TDO模型的描述，然而没有示出所述模块，所述模块不限于本说明书并且可根据设计者的意图而改变。
根据广播商的选择和ACR系统的性质，ACR环境中的接收机有多种不同的方式来访问交互服务。交互服务模型可以是直接执行模型或TDO模型，在TDO模型的情况下，触发可独立于ACR服务器来传送，或者可由ACR服务器传送。
将描述直接执行模型。
包含具有直接执行模型的交互服务的虚拟信道的ACR处理可向观看该信号的接收机提供包括media_time(“m＝”)项和content_id(“c＝”)项的时基触发的等同物。这些触发可被标识为具有直接执行模型的交互服务的触发。
当接收机首先接收到具有新locator_part的这种触发时，它应该会向其浏览器中加载触发的locator_part所指向的声明对象(DO)。通常，该DO将预先安装或者预先下载并缓存。或者，接收机应该会利用HTTP GET请求来下载它。
然后，DO可联系适当的后端服务器并提供后端服务器所指示的交互服务。
接收机应该会使得该初始触发以及DO可用的后续触发像其获得时一样，直至例如它从ACR服务器得到具有新locator_part的触发和/或与具有TDO模型的交互服务的触发相同的触发(通常均指示信道改变)的时间为止。
将描述具有独立于ACR服务器的激活的TDO模型。
包含具有TDO模型并且提供独立于ACR服务器的事件激活的交互服务的虚拟信道的ACR处理可向观看该信号的接收机提供可包括media_time(“m＝”)项的时基触发的等同物。这些触发可被标识为具有TDO模型的交互服务的触发。
当接收机首先接收到具有新locator_part的这种触发时，它应该会从触发的locator_part可指向的TPT服务器检索当前TDO参数表(TPT)，并且相对于可由ACR处理标识的音频或视频帧使用该触发以及后续触发中的媒体时间来为事件激活建立参考时基。
如果随TPT一起传送(激活消息表)AMT，则接收机应该会使用表中的各个Activation元素来在相对于通过触发中的media-time项建立的时基的正确时间激活事件。(这些事件可包括加载并执行TDO、使得TDO采取特定同步动作、暂停TDO等。)
如果TPT中包括LiveTrigger元素，则接收机应该会利用LiveTrigger元素中通知的轮询方法从LiveTrigger元素中的URL所标识的即时触发服务器检索激活触发，并且使用这些激活触发来在相对于通过触发中的media-time项建立的时基的正确时间激活事件。
AMT和即时触发服务器二者可用于相同的服务(通常，前者提供静态激活，后者提供动态激活)。另选地，当片段的所有激活为静态的时AMT可单独使用，或者可单独使用即时触发服务器来传送静态和动态激活二者。
将描述具有从ACR服务器接收的激活的TDO模型。
描述在ACR环境下没有单独的触发服务器的情况下如何传送TDO交互服务模型的激活触发。
指纹ACR系统可包括ACR服务器。接收机可将帧签名发送给ACR服务器，ACR服务器可标识签名所表示的帧并发送回接收机所需的信息。在水印至多包括这样的码，所述码可被发送给ACR服务器以得到接收机所需的信息的情况下，水印ACR系统可包括ACR服务器。在水印本身包含接收机所需的信息的情况下，水印ACR系统可不包括ACR服务器。在包括ACR服务器的那些ACR系统中，针对ACR服务器与接收机之间的通信可使用两个不同的模型：请求/响应模型和事件驱动模型。
假设广播商支持TDO交互模型。
可假设使用请求/响应模型的ACR服务器、使用事件驱动模型的ACR服务器和直接插入信息的水印ACR系统的三种情况。
在ACR服务器的情况下，ACR方法可以是指纹，在这种情况下接收机计算音频或视频帧的一些类型的签名(或指纹)并将其提交给ACR服务器以用于标识，或者它可以是水印，在这种情况下接收机从音频或视频帧提取水印形式的码并将所述码提交给ACR服务器以用于标识。
为了方便描述指纹签名的术语。然而，所述系统在水印码的情况下也按照相同的方式运行，本发明不限于指纹。
图24是示出在请求/响应ACR情况下的静态激活的示例的示图。
将描述ACR服务器使用请求/响应模型的情况。
在请求/响应ACR模型中，接收机应该会周期性地(例如，每5秒，这仅是示例性的，可由设计者改变)产生内容的签名并且将包含签名的请求发送给ACR服务器。当ACR服务器得到来自接收机的请求时，它可返回响应。在请求/响应实例之间通信会话可不保持打开。在此模型中，对于ACR服务器而言向客户机发起消息可能不可行。
对于使用此请求/响应模型并且将激活触发传送给接收机的ACR服务器，来自ACR服务器的各个响应可以是Null、时基触发和激活触发之一。
Null响应可指示没有识别出签名，或者(如果ACR摄取模块包括没有交互服务的节目片段中的帧的签名)签名表示属于没有与其关联的交互服务的片段的帧。ACR摄取模块将在下面描述。
时基触发响应可指示没有事件激活被调度为在客户机的下一请求之前发生。客户机应该会使用时基触发来维持media-time时钟。
激活触发响应可指示激活预计将很快发生，时间是触发中的“t＝”项所指示的激活的时间。
每当接收机得到具有新locator_part的触发时，它应该会立即下载新TPT，除非它已经利用以先前TPT传送的URLList检索到该新TPT。
每当接收机获得激活触发时，它应该会相对于媒体时间时钟在触发中的“t＝”项所指示的时间激活事件。
图24示出对于静态激活此方案如何起作用(或者对于动态激活，ACR系统何时足够提前地得知动态激活)。
在图24中，接收机可针对ACR服务器确定具有媒体时间MT1、MT2和MT3的帧发送签名。对于具有媒体时间MT1的帧，接收机仅获得包含时基触发的响应。对于具有媒体时间MT2的帧，静态激活预计将在media_time Mta，因此接收机获得包含具有“t＝MTa”项的激活触发的响应。对于具有媒体时间MT3的帧，接收机仅获得包含时基触发的响应。
接收机可针对相同的事件激活接收一个以上激活触发。然而，各个激活触发的媒体时间将相同，因此接收机可将它们识别为重复的，并且仅应用其中的一个。
图25是示出请求/响应ACR情况下的静态激活的实施方式的示图。
将描述ACR服务器使用请求/响应模型的情况。
在图25中，接收机可针对在本地时钟时间LC1、LC2、LC3等观看的帧发送签名。在本地时钟时间LC1观看的帧的media_time可被ACR服务器确定为MT1，接收机刚刚得到包含没有media_time或event_time的触发的响应。在本地时钟时间LC2观看的帧的media_time可被ACR服务器确定为MT2，ACR服务器知道静态激活预计将在media_time Mta，因此ACR服务器发送包含具有“d＝<offset>”项的激活触发的响应，这意味着激活的media_time Mta是在MT2之后<offset>时间单位。然后接收机将<offset>与时间LC2相加并且得到LCa作为它应该激活事件的本地时间。
图26是示出请求/响应ACR情况下的动态激活的实施方式的示图。
将描述在请求/响应ACR情况下发生动态激活的情况。
对于动态激活，在ACR系统不知道事件激活，直至对于提前向接收机发送触发而言太晚了的情形下，ACR服务器需要等待直至下一请求，然后发送激活触发。图26示出这种情况。这种情况的效果在于动态激活可被延迟一个请求间隔那么久。
在图26中，接收机可针对ACR服务器确定具有媒体时间MT1、MT2和MT3的帧发送签名。对于具有媒体时间MT1和MT2的帧，接收机刚刚得到包含时基触发的响应。当具有激活时间MTa的动态激活出现在media_time Mta处或者之前不久时，ACR服务器无法将它通知给接收机，直至来自接收机的下一请求(这发生在具有媒体时间MT3的帧的情况下)。此时，ACR服务器响应包含具有激活时间MTa(之前少许)的激活触发。在这种情形下，激活触发一到达，接收机应该就会应用激活触发。
这里同样，接收机可针对相同的事件激活接收一个以上激活触发。然而，各个激活触发的媒体时间将相同，因此接收机可将它们识别为重复的并且仅应用其中的一个。
图27是示出请求/响应ACR情况下的动态激活的实施方式的示图。
将描述在请求/响应ACR情况下发生动态激活的情况。
在图27中，接收机可针对在本地时钟时间LC1、LC2、LC3等观看的帧发送签名。在本地时钟时间LC1观看的帧的media_time可被ACR服务器确定为MT1，接收机刚刚得到包含没有media_time或event_time的触发的响应。在本地时钟时间LC2观看的帧的media_time可被ACR服务器确定为MT2，ACR服务器不知道动态激活将出现在media_time Mta，因此接收机刚刚得到包含没有media_time或event_time的触发的响应。当动态激活出现在media_timeMta时，ACR服务器无法将它通知给接收机，直至来自接收机的下一请求(这发生在本地时钟时间LC3处)。此时，ACR服务器响应可包含具有负<offset>值的激活触发，或者包含“立即行动”激活触发。
将描述使用事件驱动模型的ACR服务器。
在事件驱动ACR模型中，接收机应该会发起与ACR服务器的永久连接，周期性地(例如，每5秒)生成内容的签名，并且经所述连接提交签名。ACR服务器没有对每个签名作出响应。它可在检测到新片段时或者在需要将事件激活传达给接收机时向接收机发送消息。在此模型中，ACR服务器可在任何时间向客户机发起消息。
对于使用此事件驱动模型并且将激活传送给接收机的ACR服务器，以下规则可适用于来自ACR服务器的消息。
首先，当ACR服务器从对应于新片段的接收机接收到签名时，ACR服务器可立即将时基触发发送给接收机，正好使得接收机能够获得关联的TPT。
其次，每当事件将要被激活时，ACR服务器可将激活触发发送给接收机。如果可能，它可比接收机需要应用激活触发时略微提前地发送激活触发。(这非常类似于请求/响应模型中的行为。)如果ACR服务器知道激活太晚，无法提前太多时间发送激活触发(在动态事件激活的情况下会发生)，则它仍可尽可能快地发送激活触发。在这后一种情况下，由于消息延迟，客户机可能将比激活时间略微晚地得到消息，在这种情况下接收机应该会在接收到消息时立即激活事件。
每当接收机得到具有新locator_part的触发时，它应该会立即下载新的TPT，除非它已经利用随先前TPT传送的URLList检索到它。
将描述直接插入信息的水印ACR系统。尽管未示出水印ACR系统，但水印ACR系统不限于以下描述，可由设计者改变。
在直接插入接收机所需的信息的水印系统的情况下，与帧关联的水印可遵循如上所述相同的规则，请求/响应ACR服务器将针对该帧返回如下。请求/响应ACR服务器可返回Null、时基触发和激活触发之一。
Null响应可指示没有识别出签名，或者(如果ACR摄取模块包括没有交互服务的节目片段中的帧的签名)签名表示属于没有与其关联的交互服务的片段的帧。
时基触发响应可指示没有事件激活被调度为在客户机的下一请求之前发生。客户机应该会使用时基触发来维持media-time时钟。
激活触发响应可指示激活预计将很快发生，时间是触发中的“t＝”项所指示的激活的时间。
在通过将接收机所需的信息直接包括在水印中来传送该信息，从而不需要ACR服务器的水印ACR系统的情况下，摄取模块可遵循与上面针对请求/响应服务器模型所述相同的规则来确定与各个帧关联的触发，但是却将触发包括在帧的水印中，而非在数据库中将触发与帧关联。摄取模块和数据库将稍后描述。
将描述独立式NRT服务的支持。这未示出，但是本发明不限于以下描述，可由设计者改变。
为了使在ACR环境下的接收机能够访问独立式NRT服务，广播商可能需要支持对NRT服务的互联网访问，接收机可能需要获得服务的SMT和NRT-IT实例。
将描述经互联网获得PSIP表和NRT表的查询协议。
如果广播商对特定广播流支持此协议，则知道用于该广播流的广播商的信令服务器的URL的接收机可采取以下步骤。
首先，接收机可发出对指定的未来时间间隔(例如，接下来的12小时)的广播流的表的“基本NRT集”的查询。
其次，这将生成的各个独立式NRT虚拟信道的SMT和ILT以及覆盖指定的时间间隔的NRT-IT和TFT实例。
接收机可发现广播流的信令服务器的URL的一种方式可以是广播流中的交互服务片段的提供商可选择在随TPT一起传送的URLList元素中提供信令服务器URL。
接收机可发现信令服务器的URL的另一种方式可以是通过预先配置。按照与DTV接收机制造商可预先配置DTV接收机使其知道如何寻找覆盖任何特定广播区域的ACR服务器相同的方式，DTV接收机制造商可预先配置DTV接收机使其知道如何寻找覆盖任何特定广播区域的“NRT发现服务器”。这种NRT发现服务器将能够随每一个的信令服务器URL一起将包含独立式NRT服务的广播流的列表给予接收机。
图28是示出用于ACR服务器激活的架构的实施方式的示图。
一些ACR系统包括ACR服务器，一些ACR系统不包括ACR服务器。在指纹ACR系统中，接收机可计算并发送帧签名给ACR服务器，ACR服务器可发送回接收机所需的信息。因此，指纹ACR系统包括ACR服务器。在水印ACR系统中，水印可仅包含唯一地标识帧的码，或者水印可包含接收机所需的完整信息。当水印仅包含码时，接收机可提取所述码并将其发送给ACR服务器，ACR服务器发送回接收机所需的信息。在水印包括完整信息的情况下，接收机可仅直接从水印提取其需要的信息，不需要ACR服务器。
在包括ACR服务器的那些ACR系统中，通常针对ACR服务器与接收机之间的通信，可使用两种不同的模型：请求/响应模型和事件驱动模型。
在请求/响应ACR服务器模型中，接收机应该会周期性地(例如，每5秒)计算内容的签名或者从内容提取码，并且将包含签名或码的请求发送给ACR服务器。当ACR服务器得到来自接收机的请求时，它可返回响应。在请求/响应实例之间通信会话不保持打开。在此模型中，对于ACR服务器而言向接收机发起消息可能不可行。
假设处理的信道的广播商支持TDO交互模型。
可存在两种一般类型的事件激活：静态激活，其中在片段的广播开始之前就已知激活时间；以及动态激活，其中当片段被广播时动态地确定激活时间。在预记录的片段中，所有事件激活均可为静态的。在广播直播演出的片段中，事件激活中的一些或全部可为动态的。通常在激活消息表(AMT)中列出静态激活，但是它们可按照激活触发的形式被传送给接收机。动态激活可按照激活触发的形式传送，因为在产生AMT时不知道它们的定时。
图28示出支持使用ACR服务器的ACR系统的架构。这是逻辑框图，而不是实现架构。例如，ACR摄取模块可与广播源在同一位置，或者可在单独的位置。
在支持使用ACR服务器的ACR系统的架构中，该架构可包括广播源28010、ACR摄取模块28020、MVPD 28030、STB 28040、接收机28050、ACR客户机28060、ACR配置服务器28070、ACR服务器28080和/或数据库28090。
广播源28010可以是发送A/V流和关联的交互服务的点(例如，网络分布点或TV台)。
ACR摄取模块28020可计算帧的签名(指纹)(在指纹ACR系统的情况下)或者将包括码的水印插入帧中(在基于码的水印ACR系统的情况下)。它可将与签名或码关联的各个帧的media_time与其它元数据一起存储在数据库28090中。ACR摄取模块28020可处理广播流中的单个信道、或者整个广播流、或者多个广播流、或者其任何组合。为此，假设ACR摄取模块28020处理包含交互服务的节目片段的帧。然而，可具有处理所有帧的ACR系统，但是那些不是具有交互服务的片段部分的帧在其数据库28090条目中具有它们不是具有交互服务的片段部分的指示。
多程序视频节目分销商(MVPD)28030通常是有线运营商、卫星运营商或者IPTV运营商。它可按照一些方式从广播源接收广播流(在水印ACR系统的情况下被ACR摄取模块28020插入了水印)，这种系统常常剔除音频和视频轨道以外的所有节目元素，并且将所得流发送给用户端的机顶盒(STB)28040。
STB 28040通常将音频和视频解码(解压缩)并且将其发送给电视机以便于呈现给观看者。我们假设包含交互服务触发的DTV隐藏字幕服务#6对电视机不可用。
接收机28050可包括ACR客户机28060。ACR客户机28060可设置在接收机28050的外部。接收机28050的结构将稍后描述。
接收机28050中的ACR客户机28060可从ACR服务器28080获得激活触发并利用为该目的提供的API将其变成主接收机码。通常，ACR客户机28060将被内置于接收机中，但是其它配置也是可能的。
ACR配置服务器28070可为ACR客户机28060提供一种方式来确定合适的ACR服务器28080的位置。这种发现处理可通过其它方式来实现。
ACR服务器28080可从接收机获得签名或码并且在适当的时间返回激活触发。
数据库28090可以是某种类型的数据存储，但不必为严格意义上的数据库，其中存储有关于音频帧或视频帧(或二者)的信息以便于ACR服务器28080使用。
使用信息在水印中的直接传送的ACR系统的架构可不具有数据库和ACR服务器。ACR摄取模块可将信息以水印的形式直接插入广播流中的帧中，而不是插入包含帧的标识符以及与其关联的信息的数据库记录中。接收机然后可从广播中的帧提取此信息，而不是从ACR服务器获得该信息。
将逐步骤地描述经由请求/响应ACR服务器传送激活触发。这是本发明的实施方式，可省略步骤或者可增加新的步骤或者可改变顺序。
实现此ACR服务器行为的有效方式是遵循下述处理，其中处理中的动作的编号对应于以上架构图中的编号，如图28所示。
1)对各个片段的交互服务片段和AMT或其等同物的广播调度可在片段被广播之前被传送给ACR摄取模块。广播调度可包含各个片段(可包含与其关联的交互服务)的片段ID、GPS起始时间和GPS结束时间。如果存在对广播调度的任何最后改变，则可立即将这些改变通知给ACR摄取模块。广播调度还可包含各个片段的TPT的版本号，并且ACR摄取模块可实时地得到关于TPT版本的任何非调度改变的通知，以使得它可在需要时将“version”(“v＝”)项插入触发中。摄取模块还可被配置为在合适的时间将“spread”(“s＝”)项插入触发中，例如，在各个片段开始时(此时许多接收机很可能同时请求新TPT)的指定间隔期间。
2)如果存在任何动态激活，则可建立从动态激活源到ACR摄取模块的链接。
3)可将广播流路由至ACR摄取模块。
4)ACR摄取模块可针对具有关联的交互服务的片段中所包含的所有帧，从帧提取签名(在指纹ACR系统的情况下)或者将码插入帧中(在水印ACR系统的情况下)。(ACR摄取模块可利用GPS时钟以及广播调度中的片段的起始时间和结束时间来确定帧是否在这种片段中。)对于各个这种帧，ACR摄取模块可在数据库中插入记录，该记录可包括触发以及与帧关联的签名或码。插入什么触发的规则在此处理的动作列表的结尾描述。
5)广播流可继续流向MVPD。
6)MVPD可将广播流路由至订户位置处的STB(通常首先剔除所有交互内容)。
7)STB可将A/V解码并将未压缩的A/V发送给DTV接收机。
8)当接收机最初打开时，它可将其位置发送给ACR配置服务器。(ACR配置服务器的URL可被内置于接收机中。)
9)ACR配置服务器可发回ACR服务器的URL以便于接收机使用。
10)接收机中的ACR客户机可开始提取指纹签名或水印码并将它们发送给ACR服务器。
11)当ACR服务器接收到签名或码时，它可尝试将其在数据库中匹配。
12)如果签名或码没有匹配数据库中的任何签名或码，则ACR服务器可得回“无匹配”指示符。如果签名或码匹配数据库中的签名或码，则ACR服务器可得回具有匹配的签名或码的帧的记录。在后一种情况下，数据库中的记录可包含时基触发和/或它可包含一个或更多个激活触发(取决于ACR摄取模块向帧的记录中插入了什么)。
13)如果ACR服务器从数据库得回“无匹配”指示符，则它可将NULL响应返回给ACR客户机。否则，ACR服务器可向ACR客户机返回它所获得的触发。
以下规则可用于确定ACR摄取模块向数据库中的各个帧记录中插入了什么触发。
图29是示出没有EndTime的情况(b)和情况(a)下的激活触发的实施方式的示图。
可假设在接收机中的各个ACR客户机所使用的请求间隔的长度上存在某种上界L1。(ACR客户机是否知道此界限是什么不重要，只要它们实际在该界限内操作即可。)使L2为典型的ACR客户机计算签名或提取与帧关联的水印所花费的时间长度(从帧到达接收机的时间计起)。使L3为消息从ACR客户机到ACR服务器然后返回的典型往返时间。使M＝L1+L2+L3。(也可使用M的略大一些的值？略大一些的值的优点在于接收机得到少量额外时间来对激活触发做出反应；缺点是接收机更容易得到针对相同事件激活的多个激活触发？这不是太大的问题，因为它们将能够如下所述检测其为重复的，并且仅应用激活一次。)
ACR摄取模块可仅将时基触发插入与帧关联的记录中，除非满足以下三个条件中的至少一个：
(a)AMT中存在Activation元素使得帧的media_time在这样的时间间隔内，该时间间隔在Activation元素的startTime之前的时间跨度M处开始，在Activation元素的endTime处结束。(如果Activation没有endTime，则endTime被视为等于startTime。)
(b)在紧接着触发的激活时间(“t＝<event_time>”)之前的时间跨度M的时间间隔之前通过摄取模块接收到动态激活触发，并且帧落在该间隔内。
(c)在紧接着触发的激活时间之前的时间跨度M的时间间隔开始之后通过摄取模块接收到动态激活触发，并且帧的media_time在紧接着触发接收之后的时间跨度L1的间隔中。
如果满足条件(a)、(b)或(c)中的任何条件，则激活触发可被包括在记录中，其具有标识将要激活的事件的“e＝”项以及指示AMT中的Activation元素的startTime的“t＝”项(对于条件(a))或者动态触发的event_time(对于条件(b))。触发还可包含版本(“v＝”)项。
在情况(a)中贯穿从startTime至endTime的间隔始终将激活触发与帧关联的原因是顺应在该间隔中途加入信道的接收机。
需要注意的是，此方法在ACR服务器的部分不需要额外的智能。它仅向ACR客户机返回它在数据库中找到的信息。所有智能可存在于ACR摄取模块中。此外，ACR摄取模块需要进行的计算可非常简单。
通过此方案可能的是，接收机可得到针对同一事件激活的一个以上激活触发(与不同的帧关联)。然而，接收机可容易地从“t＝”值看出它们全部具有相同的激活时间，因此接收机可确定它们是重复的并且仅激活事件一次。
在上述两种情形中，激活触发中的“t＝”项的event_time可早于其所关联的帧的media_time。在情形(a)中，如果Activation元素的endTime显著晚于startTime，则接收机通常可贯穿startTime与endTime之间的间隔得到多个激活触发，并且这些激活触发可全部以startTime作为激活时间。在情形(c)中，用于激活的激活触发可被过晚插入帧记录中，使得接收机得到的激活触发可响应于具有media_time在激活时间之后的帧的签名的请求而到来。当接收机得到具有早于其所关联的帧的media_time的event_time的激活触发时，它应该会立即激活事件，除非它将该激活触发识别为它已经看到并用于激活事件的激活触发的重复。
针对帧media_time晚于event_activation时间的情形，使用过去的event_time值而不是“立即行动”触发的目的是因为接收机可得到这些“事后”激活触发中的一个以上。“t＝”值使得接收机能够确定它们全部具有相同的激活时间并且仅激活事件一次。
图29示出当AMT中的Activation元素没有endTime属性时的情形(b)和情形(a)。
图29示出在AMT中的Activation元素没有endTime的情况下，上述动作(4)中的情形(a)的示例。这也可以是在其激活时间之前至少M时间单位向ACR摄取模块发送动态激活触发的情况下，上述动作(4)中的情形(b)的示例。
图29在时间线上面示出事件激活时间，在其之前长度M的间隔涵盖长度L1、L2和L3的间隔。在时间线下面的垂直箭头示出各个帧的时间。在长度M的间隔开始之前或者事件激活时间之后的各个帧将在数据库中具有与其关联的时基触发。在长度M的间隔内的各个帧将在数据库中具有与其关联的激活触发，例如在图下部的两个示例(f1、f2)。各个帧的”t＝”项将指示相对于media_time的事件激活时间(由圈出的f1和f2指示)。
四个圈出的垂直箭头可表示当典型的接收机发送请求时的示例。在此示例中，接收机将针对同一事件激活得到两个激活触发，但是它们将具有相同的事件激活时间，因此接收机将它们识别为重复的，并且仅应用第一个。由于接收机请求之间的间隔小于L1，所以接收机被确保在图中所示的L1间隔中利用帧的签名作出至少一个请求。这给它时间来计算签名，将请求发送给ACR服务器，并在响应中得回激活触发(全部在激活时间之前)。在此示例中，接收机得到的第一激活触发将相当提前地传送；接收机得到的第二激活触发将勉强及时到达(其为重复的)。
图30是示出没有EndTime的情况(b)和情况(a)下的激活触发的实施方式的示图。
将描述没有EndTime的情况(b)和情况(a)下的激活触发。
图30示出在AMT中的Activation元素没有endTime的情况下，上述动作(4)中的情形(a)的示例。这也可以是在其激活时间之前至少M时间单位向ACR摄取模块发送动态激活触发的情况下，上述动作(4)中的情形(b)的示例。
图30在时间线上面示出事件激活时间，在其之前有长度M的间隔，涵盖长度L1、L2和L3的间隔。在时间线下面的箭头示出各个帧的时间。在长度M的间隔开始之前或者事件激活时间之后的各个帧将在数据库中具有与其关联的没有<media_time>或<event_time>项的触发。在长度M的间隔内的各个帧将在数据库中具有与其关联的激活触发，例如在图下部的两个示例。各个帧的”d＝”项将指示该帧与事件激活时间之间的时间长度(由圈出的f1和f2指示)。
四个圈出的垂直箭头可表示当典型的接收机发送请求时的示例。在此示例中，接收机将针对同一事件激活得到两个激活触发，但是通过将值<d1>与帧f1的接收机的本地时间相加或者通过将值<d2>与帧f2的接收机的本地时间相加而计算的激活时间均给出相同的结果，因此接收机将它们识别为重复的，并且仅应用第一个。由于接收机请求之间的间隔小于L1，所以接收机被确保在图中所示的L1间隔中利用帧的签名作出至少一个请求。这给它时间来计算签名，将请求发送给ACR服务器，并在响应中得回激活触发(全部在激活时间之前)。在此示例中，接收机接收到的第二激活触发将在激活时间之后到达。
图31是示出具有EndTime的情况(a)下的激活触发的实施方式的示图。
图31示出在AMT中的Activation元素具有endTime以及startTime的情况下，上述动作(4)中的情形(a)。
该图在时间线上面示出事件激活startTime和endTime，在startTime之前具有长度M的间隔。在时间线下面的箭头示出各个帧的时间。在长度M的间隔开始之前或者事件激活endTime之后的各个帧将在数据库中具有与其关联的时基触发。在长度M的间隔内或者在事件激活的startTime与endTime之间的各个帧将在数据库中具有与其关联的激活触发，其形式由图下部的三个示例示出。各个帧的”t＝”项将指示相对于media_time线的事件激活时间(由圈出的f1、f2和f3指示)。
三个圈出的垂直箭头可表示当典型的接收机发送请求时的示例。在这种情况下，接收机将针对同一事件激活得到三个激活触发，但是激活时间将全部相同，因此接收机将其识别为重复的，并且仅应用第一个。
当然，图中所示的前两个激活触发根本不会被在startTime之后加入信道并且利用其第一请求发送帧f3的签名的接收机看到。
图32是示出具有EndTime的情况(a)下的激活触发的实施方式的示图。
将描述具有EndTime的情况(a)下的激活触发。
图32示出在AMT中的Activation元素具有endTime以及startTime的情况下，上述动作(4)中的情形(a)。
该图在时间线上面示出事件激活startTime和endTime，在startTime之前具有长度M的间隔。在时间线下面的箭头示出各个帧的时间。在长度M的间隔开始之前或者事件激活endTime之后的各个帧将在数据库中具有与其关联的没有<media_time>或<event_time>项的触发。在长度M的间隔内的各个帧将在数据库中具有与其关联的激活触发，其形式由图下部的两个示例示出。各个帧的”d＝”项将指示该帧与事件激活时间之间的时间长度(由圈出的垂直箭头指示)。
圈出的垂直箭头可表示当典型的接收机发送请求时的示例。在这种情况下，接收机将针对同一事件激活得到三个激活触发，但是通过将值<d1>与帧f1的接收机的本地时间相加或者将值<d2>与帧f2的接收机的本地时间相加或者将(负)值<d3>与帧f3的接收机的本地时间相加而计算的激活时间均给出相同的结果，以使得接收机将其识别为重复的，并且仅应用第一个。
当然，图中所示的前两个激活触发根本不会被在startTime之后加入信道并且利用其第一请求发送帧f3的签名的接收机看到。
图33是示出情况(c)的激活触发的实施方式的示图。
图33示出在激活时间之前至少M时间单位之后向ACR摄取模块发送动态激活触发的情况下，上述动作(4)中的情形(c)。
图33在时间线上面示出动态事件激活时间，在事件激活时间之前不久的时间ACR摄取模块得知事件激活，在ACR摄取模块得知事件激活的时间之后具有长度L1的间隔。在时间线下面的垂直箭头示出各个帧的时间。在长度L1的间隔开始之前或者长度L1的间隔结束之后的各个帧将在数据库中具有与其关联的时基触发。在长度L1的间隔内的各个帧将在数据库中具有激活触发，例如在图下部的示例中的那一个。各个帧的“t＝”项将指示相对于媒体时间线的事件激活时间(由圈出的垂直箭头指示)。圈出的垂直箭头可表示当典型的接收机发送请求时的示例。在这种情况下，接收机将针对事件激活仅一个激活触发。由于激活触发的激活时间在它被接收的时间之前，所以接收机将在接收到时立即应用触发。
图34是示出情况(c)的激活触发的实施方式的示图。
将描述情况(c)的激活触发。
图34示出在激活时间之前至少M时间单位之后向ACR摄取模块发送动态激活触发的情况下，上述动作(4)中的情形(c)。
图34在时间线上面示出动态事件激活时间，在事件激活时间之前不久的时间ACR摄取模块得知事件激活，在ACR摄取模块得知事件激活的时间之后具有长度M的间隔。在时间线下面的箭头示出各个帧的时间。在长度M的间隔开始之前或者在长度M的间隔结束之后的各个帧将在数据库中具有不带<media_time>或<event_time>项的触发。在长度M的间隔内的各个帧将在数据库中具有激活触发，例如在图下部的两个示例中的那些。各个帧的”d＝”项将指示该帧与事件激活时间之间的时间长度(由圈出的垂直箭头指示)。圈出的垂直箭头可表示当典型的接收机发送请求时的示例。在这种情况下，接收机将针对同一事件激活得到两个激活触发，但是通过将(负)值<d1>与帧f1的接收机的本地时间相加并且将(负)值<d2>与帧f2的接收机的本地时间相加而计算的激活时间均给出相同的结果，因此接收机将它们识别为重复的，并且仅应用它所接收的第一个。由于第一触发的激活时间在它被接收的时间之前，所以接收机将在接收到它时立即应用触发。
图35是示出在最后一刻传送的动态激活触发的实施方式的示图。
在事件驱动ACR模型中，接收机应该会发起与ACR服务器的永久连接，按照规则间隔(例如，每5秒)生成与帧关联的签名，并且经所述连接提交签名。ACR服务器没有对每个签名作出响应。它可在检测到新片段时或者在需要将事件激活传达给接收机时向接收机发送消息。在此模型中，ACR服务器可在任何时间经所述永久连接向客户机发起消息。
此外，对于服务器而言维持关于各个接收机的特定量的信息(例如，与接收机的最近提交以及发送给接收机的最近激活触发对应的片段ID(触发的<locator_part>))很简单。
对于使用此事件驱动模型并且将激活传送给接收机的ACR服务器，以下规则可适用于来自ACR服务器的消息。
首先，当ACR服务器从接收机接收到与新片段中的帧对应的签名时，ACR服务器可立即利用时基触发向接收机发送消息，以使得接收机能够获得关联的TPT。
其次，当ACR服务器从接收机接收到与具有新TPT版本号(不同于接收机已看到的最近版本)的片段的一部分中的帧对应的签名时，ACR服务器可立即利用具有“v＝”项的时基触发向接收机发送消息，以使得接收机能够获得关联的TPT的新版本。
第三，当事件将要被激活时，ACR服务器可将激活触发发送给接收机。如果可能，它可比接收机需要应用激活触发时略微提前地发送激活触发，激活触发中的“t＝”项指示相对于媒体时间线的激活时间。(这非常类似于请求/响应模型中的行为。)如果ACR服务器知道激活太晚，无法像往常一样提前发送激活触发，则它可在知道激活之后尽可能快地发送激活触发。(在这后一种情况下，接收机可能比其激活时间晚地得到激活触发，在这种情况下接收机应该会一得到激活触发就激活事件。)
图28所示的用于请求/响应情况的架构也适合于此事件驱动情况，只有一个不同。该不同在于，对于事件驱动情况，可存在新动作(2a)。如果存在任何动态激活触发，则可在ACR摄取模块与使用ACR摄取模块的数据库的所有ACR服务器之间建立连接，以使得ACR摄取模块可将选择的动态激活触发发送给ACR服务器。
用于事件驱动情况的编号的动作可类似于用于请求/响应情况的那些。除了新动作(2a)以外，动作(4)略有不同，动作(13)略有不同，并且增加新动作(14)。
在动作(4)中，对于具有与其关联的交互服务的片段中所包含的所有帧，ACR摄取模块可从帧提取签名(在指纹ACR系统的情况下)或者将码插入帧中(在水印ACR系统的情况下)。(ACR摄取模块可利用GPS时钟以及广播调度中的片段的开始时间和结束时间来确定帧是否在这种片段中。)对于各个这种帧，ACR摄取模块可在数据库中插入记录，该记录可包括与帧关联的签名或码和触发。由ACR摄取模块包括在记录中的触发可以是时基触发，除非满足以下两个条件中的至少一个：
(a)在AMT中存在Activation元素，使得帧的media_time在这样的时间间隔中，该时间间隔在Activation元素的startTime之前时间跨度M处开始，在Activation元素的endTime处结束。(如果activation没有endTime，则endTime被视为等于startTime。)(与请求/响应ACR模型的条件(a)相同)
(b)在紧接着触发的激活时间(“t＝<event_time>”)之前的时间跨度M的时间间隔之前，通过摄取模块接收到动态激活触发，帧落在该间隔内。(与请求/响应ACR模型的条件(b)相同)
如果满足条件(a)或(b)，则激活触发可被包括在记录中，利用“e＝”项来标识将要激活的事件，“t＝”项指示AMT中的Activation元素的startTime(对于条件(a))或者动态触发的event_time(对于条件(b))。
如果在紧接着触发的激活时间之前的时间跨度M的间隔期间通过摄取模块接收到动态激活触发(其中M具有与请求/响应服务器情况中相同的含义)，则摄取模块可将激活触发传递给使用摄取模块可向其中插入记录的数据库的所有ACR服务器，而不在数据库中放置关于该动态激活触发的任何东西。(可在从动态激活触发源直接将动态激活触发传递给ACR服务器，而不经过摄取模块的情况下进行这种架构变化，但是ACR服务器得到在激活时间之前晚于M时间单位到达的动态激活触发，以使得它可立即将消息发送给相关接收机。如果它等待直至下一接收机提交，则可能太晚。)
在动作(13)中，如果ACR服务器在针对前一个提交没有接收到之后从数据库得回“不匹配”指示符，则它可将NULL消息发送给接收机。如果它得回具有与针对前一个提交得回的<locator_part>不同的<locator_part>的触发，则它可将触发发送给接收机。在两种情况下，这均可告诉接收机观看的信道改变或者观看的片段接近结束，因此接收机可终止当前执行的任何TDO，并且如果需要，下载新TPT。如果ACR服务器得回一个或更多个激活触发，则它可将它们发送给接收机，丢弃已经发送给接收机的激活触发的副本。或者，ACR服务器可无动作。
在新的动作(14)中，如果ACR服务器接收到动态激活触发，则它可将该动态激活触发的<locator_part>与其各个ACR客户机的当前<locator_part>进行比较(其中客户机的当前<locator_part>是ACR服务器针对ACR客户机的最近提交从数据库得到的触发的<locator_part>)。对于<locator_part>匹配的各个客户机，ACR服务器可将激活触发发送给客户机。
图29和图31示出在其激活时间之前至少M时间单位被传送给ACR摄取模块的用于静态激活和动态激活的触发的处理。不同在于，ACR服务器可丢弃重复的激活触发，而非将它们发送给接收机。
图35示出匆忙(在其激活时间之前短于M时间单位)接收的动态激活触发的处理的示例。
图35在时间线上方示出动态事件激活时间，以及在事件激活时间之前不久的时间ACR摄取模块知道事件激活。时间线下方的垂直箭头示出各个帧的时间。ACR服务器一从ACR摄取模块接收到激活触发，它就可将激活触发发送给当前正在观看与激活触发关联的片段(由触发的<locator_part>标识)的所有接收机。
图36是示出在最后一刻传送的动态激活触发的实施方式的示图。
将描述在最后一刻传送的动态激活触发。
图36示出匆忙(在其激活时间之前短于M时间单位)接收的动态激活触发的处理的示例。
图“在最后一刻传送的动态激活触发”在时间线上方示出动态事件激活时间，以及在事件激活时间之前不久的时间ACR摄取模块知道事件激活。时间线下方的箭头示出各个帧的时间。ACR服务器一从ACR摄取模块接收到激活触发，它就可将激活触发发送给当前正在观看与激活触发关联的片段(由触发的<locator_part>标识)的所有接收机。对于各个接收机，它将触发的event_time调节为相对于与接收机最近提交的签名对应的帧的<delay_time>。
图37示出在请求/响应ACR情况下ACR客户机与其它服务器之间的顺序图。
图37示出根据在请求/响应模型中根据ACR服务器和接收机(ACR客户机)的操作协议有效地发送触发和TPT的实施方式的顺序图。
现在将按照请求和响应的顺序描述请求/响应模型的示例性操作。
在请求/响应ACR情况下ACR客户机与其它服务器之间的顺序图可包括ACR请求1(S37010)、ACR响应1(S37020)、ACR请求2(S37030)、ACR响应2(S37040)、HTTP请求1(S37050)、HTTP响应1(S37060)、HTTP请求2(S37070)、HTTP响应2(S37080)、ACR请求3(S37090)、ACR响应3(S37100)、ACR请求4(S37110)和/或ACR响应4(S37120)。
ACR请求1(S37010)是接收机将当前观看的节目的签名发送给服务器的步骤。服务器可以是上述ACR服务器。签名可以是指纹签名或水印。
ACR响应1(S37020)是在没有识别出签名或者相关的交互服务不存在时ACR服务器返回NULL的步骤。这可以是与上述返回NULL响应的情况对应的情况。
ACR请求2(S37030)是在信道或节目改变时接收机将改变的节目的签名发送给ACR服务器的步骤。
ACR响应2(S37040)是ACR服务器返回包括可获得与对应节目相关的交互服务的地址的触发(例如，xbc.com/tpt504)的步骤。与ACR响应1(S37020)不同，此步骤可对应于识别出签名并且相关的交互服务存在的情况。即，在此步骤中触发可用。在这种情况下，返回的触发可以是没有关于media_time的信息的时基触发。
HTTP请求1(S37050)是接收机通过http协议利用在ACR响应2(S37040)中接收的地址请求TPT服务器(例如，http://xbc.com/tpt504等)提供对应TPT的步骤。
HTTP响应1(S37060)是TPT服务器应接收机的请求发送以XML表示的TPT的步骤。
HTTP请求2(S37070)是接收机利用http协议请求内容服务器提供诸如TDO的应用的步骤。接收机可解析包括在TPT中的TDO相关信息。TDO相关信息可以是可通过其下载TDO的内容服务器的URL。可利用内容服务器的URL来发送请求。
HTTP响应2(S37080)是内容服务器应接收机的请求发送对应TDO的步骤。
ACR请求3(S37090)是接收机将当前观看的节目的帧的签名发送给ACR服务器的步骤。
ACR响应3(S37100)是ACR服务器返回包括可用来获得与对应节目相关的交互服务的地址的触发(例如，xbc.com/tpt504)的步骤。在这种情况下，与ACR响应1(S37020)不同，识别出签名并且相关的交互服务存在。即，在此步骤中触发可用。
ACR请求4(S37110)是接收机将当前观看的节目的帧的签名发送给ACR服务器的步骤。
ACR响应4(S37120)是ACR服务器发送与从接收机发送的签名所相关的交互服务相关的激活触发的步骤。根据激活触发，可在特定时间激活特定事件。
图38示出在事件驱动ACR情况下ACR客户机与其它服务器之间的顺序图。
图38示出根据在事件驱动模型中根据ACR服务器和接收机(ACR客户机)的操作协议有效地发送触发和TPT的实施方式的顺序图。
现在将按照请求、对该请求的响应和事件的顺序描述事件驱动模型的示例性操作。
在事件驱动ACR情况下ACR客户机与其它服务器之间的顺序图可包括ACR请求1(S38010)、ACR请求2(S38020)、ACR事件1(S37030)、HTTP请求1(S38040)、HTTP响应1(S38050)、HTTP请求2(S38060)、HTTP响应2(S38070)、ACR请求3(S38080)、ACR事件2(S38090)和/或ACR响应4(S38100)。
ACR请求1(S38010)是接收机将当前观看的节目的签名发送给服务器的步骤。服务器可以是上述ACR服务器。签名可以是指纹签名或水印。这里，与图37的顺序不同，当没有识别出签名或者相关的交互服务不存在时，ACR服务器可不发送对ACR请求1的响应，不返回NULL。
ACR请求2(S38020)是在信道或节目改变时接收机将改变的节目的签名发送给ACR服务器的步骤。
ACR事件1(S38030)是ACR服务器返回包括可用来获得与对应节目相关的交互服务的地址的触发(例如，xbc.com/tpt504)的步骤。此步骤可对应于识别出签名并且相关的交互服务存在的情况。即，在此步骤中触发可用。在这种情况下，返回的触发可以是没有关于media_time的信息的时基触发。
HTTP请求1(S38040)是接收机通过http协议利用在ACR事件1(S38030)中接收的地址请求TPT服务器(例如，http://xbc.com/tpt504等)提供对应TPT的步骤。
HTTP响应1(S38050)是TPT服务器应接收机的请求发送以XML表示的TPT的步骤。
HTTP请求2(S38060)是接收机利用http协议请求内容服务器提供诸如TDO的应用的步骤。接收机可解析包括在TPT中的TDO相关信息。TDO相关信息可以是可通过其下载TDO的内容服务器的URL。可利用内容服务器的URL来发送请求。
HTTP响应2(S38070)是内容服务器应接收机的请求发送对应TDO的步骤。
ACR请求3(S38080)是接收机将当前观看的节目的帧的签名发送给ACR服务器的步骤。
ACR事件2(S38090)是ACR服务器发送与从接收机发送的签名所相关的交互服务相关的激活触发的步骤。根据激活触发，可在特定时间激活特定事件。
ACR请求4(S38100)是接收机将当前观看的节目的帧的签名发送给ACR服务器的步骤。
图39是示出在事件驱动模型中在接收机处处理交互服务的方法的实施方式的示图。
在事件驱动模型中在接收机处处理交互服务的方法的实施方式可包括：接收未压缩的音频内容或未压缩的视频内容(S39010)，提取标识符(S39020)，提交包含所述标识符的请求(S39030)，和/或接收用于该内容的触发(S39040)。
接收未压缩的音频内容或未压缩的视频内容(S39010)是接收机从外部解码单元接收未压缩的音频内容或未压缩的视频内容的步骤。
这里，外部解码单元可以是上述STB。STB将稍后详细描述。
未压缩的音频内容或未压缩的视频内容可以是从上述STB(外部解码单元)发送至接收机的音频/视频内容。
外部解码单元可将从MVPD等接收的A/V内容解压缩，并且将解压缩的A/V内容传送给接收机。接收机可从外部解码单元接收未压缩的音频内容或未压缩的视频内容并将接收的内容显示给观看者。未压缩的音频内容或未压缩的视频内容可根据上述ACR摄取模块来处理。即，ACR摄取模块可计算帧的签名(指纹)(在指纹ACR系统的情况下)或者将包括码的水印插入帧中(在基于码的水印ACR系统的情况下)。这里，帧可涉及在被STB解码/解压缩之前的音频/视频内容。ACR摄取模块可将与签名或码关联的各个帧的media_time与其它元数据一起存储在数据库中。
提取标识符(S39020)是接收机周期性地从接收的未压缩音频内容或未压缩视频内容的多个帧提取标识符的步骤。
标识符可标识接收的内容的帧。标识符可以是指纹签名或水印码。本实施方式不限于指纹或水印。
这里，“提取”是周期性地从接收的未压缩音频内容或未压缩视频内容的多个帧提取标识符的处理，并且可对应于上述“计算签名”、“提取水印”和“产生签名”。
另外，“提取”可以是在上述ACR客户机中执行的操作。然而，这是示例性的，本发明的精神不限于此，可根据设计者的意图在其它模块中执行“提取”。ACR客户机可设置在接收机中。
在提取标识符的步骤(S39020)中，可提取与单个帧对应的标识符。可周期性地执行提取。提取的标识符可如上所述发送给ACR服务器。如上所述，ACR服务器可将接收的标识符与数据库中的记录进行匹配。ACR服务器和数据库可以是上述ACR服务器和数据库。数据库中的记录可由ACR摄取模块预先存储。
在本发明的一个实施方式中，标识符提取循环可为5秒。可根据设计者的意图改变标识符提取循环。
提交包含标识符的请求的步骤(S39030)是将包括提取的标识符的请求发送给服务器的步骤。
提取的标识符可以是指纹签名或水印码。本实施方式不限于指纹或水印。
这里，请求可包括标识符。接收机可周期性地向服务器发送请求。单个请求可包括单个标识符。周期可由设计者改变。
服务器可以是上述ACR服务器。服务器可接收请求并将该请求与数据库中的记录进行匹配。ACR服务器和数据库可以是上述ACR服务器和数据库。数据库中的记录可以是由ACR摄取模块预先存储的记录。
接收用于内容的触发的步骤(S39040)是根据发送给服务器的请求和标识符是否匹配数据库中的记录或者存在于匹配的记录中的触发，来从服务器接收触发的步骤。
接收机在任何情况下均没有接收针对上述请求的响应。当检测到新片段时或者当需要将事件激活传达给接收机时，接收机可接收触发。在其它情况下，接收机可不接收触发。然而，根据设计者的意图，接收机可在上述情况以外的情况下接收触发。
这里，所述片段可以是上述交互服务片段。
所述新片段可指在当前应用参数表或TPT之后使用的片段。
这里，需要将事件激活传达给接收机可意指事件激活被调度的情况或者需要激活的事件还未被激活的情况。
所述触发可涉及由接收机从STB接收的内容。
所述内容可以是从STB接收的内容。
这里，所述触发可指示内容的当前时间并且参考应用参数表中的特定交互事件或者用信号通知事件将现在执行或在指定的未来时间执行。
这里，应用参数表可包括关于至少一个应用的信息。
服务器可以是上述ACR服务器。数据库可以是上述数据库。标识符可以是指纹签名或水印码。本实施方式不限于指纹或水印。
服务器可将接收的请求/标识符与数据库中的记录进行匹配。可将请求/标识符与由ACR摄取模块预先存储在数据库中的记录进行匹配。当标识符匹配存储在数据库中的标识符时，服务器可从数据库接收与该标识符相关的记录。在这种情况下，所述记录可包括时基触发或激活触发。记录中包括哪一触发可取决于先前由ACR摄取模块向记录中插入了什么触发。当从数据库接收到记录时，服务器可将接收的触发发送给接收机。这里，与请求/响应模型不同，服务器可仅在上述特定情况下发送触发。在其它情况下，服务器可不向接收机发送响应。
在本发明的实施方式中，当标识符对应于新片段时触发可为时基触发，时基触发可用于使得接收机能够获得与新片段关联的新应用参数表。时基触发可符合上述时基触发操作。
在本发明的实施方式中，每当事件将要被激活时触发可为激活触发，激活触发设定事件的激活时间。激活触发可符合上述激活触发操作。激活触发可被应用于应用的事件以在特定时间导致激活。可通过事件激活向观看者提供交互服务。在根据本发明的实施方式的激活触发传送的情况下，可在上述ACR环境中，即，当接收机具有互联网连接并且从广播流访问未压缩的音频和视频时，提供交互服务器。
在本发明的实施方式中，当接收机针对同一事件激活接收到一个以上激活触发时，激活触发可被应用一次。如上所述，针对同一事件激活，接收机可接收到多个激活触发。根据本发明的实施方式，标识符可被周期性地提取并发送给服务器。这里，作为对周期性请求的响应，可接收到多个激活触发。如上所述，在这种情况下，激活触发具有相同的“t＝”项，因此接收机可识别出激活触发为重复的并且仅应用一个激活触发。
在本发明的实施方式中，可在接收机需要应用激活触发的时间之前接收激活触发。这样，可在正确的激活时间激活事件。此实施方式可对应于上述静态激活。
在本发明的实施方式中，当在激活时间之后接收到激活触发时，可在接收到激活触发时立即激活事件。此实施方式可对应于上述动态激活。当服务器较晚识别出激活，使得服务器无法将激活触发发送给接收机时，服务器可等待接收机的下一请求，然后发送激活触发作为对下一请求的响应。在这种情况下，激活触发可指示过去的激活时间。这里，接收机一接收到激活触发，接收机就可应用激活触发。
在本发明的实施方式中，处理交互服务的方法还可包括立即下载新应用参数表。当触发包括标识新应用参数表的应用参数表标识符时，接收机立即下载新应用参数表，除非接收机已经利用应用参数表所传送的URL信息检索到新应用参数表。如上所述，当接收机接收到具有新应用参数表标识符的触发时，接收机可通过下载新应用参数表(例如，TPT)来获得用于针对相关片段提供交互服务的新信息。在本发明的实施方式中，接收机可利用http协议请求应用参数表服务器提供新应用参数表并且下载该新应用参数表。这里，根据本发明的实施方式，应用参数表可为XML格式或二进制格式。应用参数表标识符可以是上述locator_part。这里，URL信息可以是上述URLList。
在本发明的实施方式中，所述时间可以是媒体时间，媒体时间可以是参考内容项的播出中的点的参数。
在本发明的实施方式中，所述应用是声明对象、触发声明对象、非实时声明对象或无约束声明对象。
在本发明的实施方式中，除非发送和接收请求和响应，否则通信会话可被关闭。在请求实例之间通信会话没有保持打开。在通信会话保持打开时，接收机可通过通信会话接收响应。
在本发明的实施方式中，代替接收机，服务器可首先发送消息。即，服务器(例如，ACR服务器)可在任何时间将消息发送给客户机(例如，接收机)。
在本发明的实施方式中，服务器可不需要额外的智能。服务器可仅将从数据库找到的信息传送给接收机(例如，ACR客户机)。ACR摄取模块可负责关于本发明的操作的智能。
图40是示出根据本发明的实施方式的接收机的结构的示图。
在本发明的实施方式中，接收机可包括天线rcvr1010、调谐器rcvr1020、VSB或DVB解调器rcvr1030、MPEG-2TS系统解码器rcvr1040、字幕模块rcvr1050、触发模块rcvr1060、网络浏览器rcvr1070、网络协议栈rcvr1080、网络接口rcvr1090、UI模块rcvr1100、音频解码器rcvr1110、视频解码器rcvr1120、扬声器rcvr1130、显示模块rcvr1140、图形处理器rcvr1150、遥控器接收器rcvr1160和/或遥控器rcvr1170。
天线rcvr1010可根据广播流接收广播信号。这里，天线rcvr1010可以是技术领域中通常使用的天线。
调谐器rcvr1020可搜寻或调谐至接收机的信道，并且可包括射频放大器、本地振荡器、频率转换和输入电路、搜索器等。调谐器rcvr1020可以是技术领域中通常使用的调谐器。
VSB或DVB解调器rcvr1030可调制VSB信号或DVB信号。VSB或DVB解调器rcvr1030可将调制的VSB或DVB(例如，OFDM调制的信号)恢复为原始信号。VSB或DVB解调器rcvr1030的解调处理可以是技术领域中通常使用的解调处理。
MPEG-2TS系统解码器rcvr1040将解调的信号的传输流(TS)解码。MPEG-2TS系统解码器rcvr1040可从传输流获得字幕流并将其传送给字幕模块rcvr1050。MPEG-2TS系统解码器rcvr1040可将解码的音频和视频信号发送给音频/视频解码器rcvr1120。
字幕模块rcvr1050可接收字幕流。字幕模块rcvr1050可监测服务#6或其它服务并且确定服务#6或者用于发送触发的服务是否被选择并发送给触发模块rcvr1060或者字幕文本是否被处理并显示在屏幕上。触发数据可被传送给触发模块rcvr1060。其它字幕服务可经由字幕文本处理并被发送给图形处理器rcvr1150。
触发模块rcvr1060可解析触发、TPT和/或AMT信息并且处理解析的数据。触发模块rcvr1060可利用触发的URI信息值经由网络协议栈rcvr1080访问网络。URI信息值可以是HTTP服务器的地址。触发模块rcvr1060可分析TPT文件内容以获得TDO URL。另外，触发模块rcvr1060可解析AMT以处理数据。可通过解析获得其它信息。在接收到AMT消息之后，根据预定时间和操作传送与网络浏览器对应的TDO URL，或者可在预定时间停止当前操作的TDO。这对应于TDO动作，并且触发模块rcvr1060可向网络浏览器发送操作命令。与本发明相关的触发模块rcvr1060的操作将在下面详细描述。
网络浏览器rcvr1070可接收来自触发模块rcvr1060的命令、来自UI模块rcvr1100的浏览器键码以及来自遥控器接收器rcvr1160的浏览器键码并且与网络协议栈rcvr1080通信。
网络协议栈rcvr1080可与触发模块rcvr1060和网络浏览器通信以经由网络接口rcvr1090访问服务器。
网络接口rcvr1090执行多个其它设备的共同连接或者网络计算机和外部网络的连接。网络接口可连接到服务器以下载TDO、TPT、AMT等。这里，网络接口rcvr1090的操作可以是技术领域中通常使用的网络接口rcvr1090的操作。与本发明相关的网络接口rcvr1090的操作将在下面详细描述。
UI模块rcvr1100可通过遥控器接收器rcvr1160接收由观看者利用遥控器rcvr1170输入的信息。如果接收的信息涉及使用网络的服务，则可将浏览器键码传送给网络浏览器。如果接收的信息涉及当前显示的视频，则可经由图形处理器rcvr1150将信号传送给显示模块rcvr1140。
音频解码器rcvr1110可将从MPEG-2TS系统解码器rcvr1040接收的音频信号解码。随后，可将解码的音频信号发送给扬声器并输出给观看者。这里，音频解码器rcvr1110可以是技术领域中通常使用的音频解码器。
视频解码器rcvr1120可将从MPEG-2TS系统解码器rcvr1040接收的视频信号解码。随后，可将解码的视频信号发送给显示模块rcvr1140以输出给观看者。这里，视频解码器rcvr1120可以是技术领域中通常使用的视频解码器。
扬声器rcvr1130可将音频信号输出给观看者。扬声器可以是技术领域中通常使用的扬声器。
显示模块rcvr1140可将视频信号输出给观看者。显示模块rcvr1140可以是技术领域中通常使用的显示模块。与本发明相关的显示模块rcvr1140的操作将在下面详细描述。
图形处理器rcvr1150可针对从字幕模块rcvr1050接收的字幕文本以及从UI模块rcvr1100接收的观看者输入信息执行图形处理。处理的信息可被传送给显示模块rcvr1140。图形处理器rcvr1150可以是技术领域中通常使用的图形处理器。
遥控器接收器rcvr1160可从遥控器rcvr1170接收信息。此时，可将键码传送给UI模块rcvr1100，并且可将浏览器键码传送给网络浏览器。
遥控器rcvr1170将观看者所输入的信号传送给遥控器接收器rcvr1160。遥控器rcvr1170可接收用于改变虚拟信道的观看者输入。另外，遥控器可接收由观看者针对应用选择的信息。遥控器rcvr1170可将接收的信息传送给遥控器接收器rcvr1160。此时，可在预定范围以外的距离处利用红外(IR)光远程传送信息。
图41是示出在机顶盒经由高清晰多媒体接口(HDMI)或外部接口接收广播的情况下根据本发明的实施方式的接收机的结构的示图。
在图41所示的本发明的实施方式中，接收机可包括天线rcvr2010、调谐器rcvr2020、机顶盒rcvr2030、VSB或DVB解调器rcvr2040、HDMI RCVR2050、MPEG-2TS系统解码器rcvr2060、字幕模块rcvr2070、触发模块rcvr2080、网络浏览器rcvr2090、网络协议栈rcvr2100、网络接口rcvr2110、UI模块rcvr2120、ACR模块rcvr2130、音频解码器rcvr2140、视频解码器r rcvr2150、扬声器rcvr2160、显示模块rcvr2170、图形处理器rcvr2180、遥控器接收器rcvr2190和/或遥控器rcvr2200。
在这种情况下，由于广播流的视频和音频是原始数据，所以可能没有接收包括在字幕流中的触发。本发明的细节将在下面描述。
这里，除机顶盒rcvr2030、HDMI rcvr2050和ACR模块rcvr2130以外的模块在角色方面类似于图40的实施方式中所描述的模块。
现在将描述机顶盒rcvr2030、HDMI rcvr2050和ACR模块rcvr2130。
机顶盒rcvr2030可将通过数字网络从视频服务器接收的压缩信号恢复为原始视频和音频信号。TV可以是互联网用户接口。
HDMI rcvr2050可以是高清晰多媒体接口(非压缩数字视频/音频接口标准)。HDMIrcvr2050可在机顶盒rcvr2030与AV设备(即，音频解码器rcvr2140和视频解码器rcvr2150)之间提供接口。
ACR模块rcvr2130可自动识别来自音频解码器rcvr2140和视频解码器rcvr2150的广播内容。基于当前识别的内容，可经由触发模块rcvr2080和网络接口rcvr2110将查询发送给ACR服务器以接收用于触发的TPT/AMT。
图42是示出在事件驱动模型中处理交互服务的设备的实施方式的示图。
根据本发明的在事件驱动模型中处理交互服务的设备的实施方式可包括接收模块42010、标识符提取模块42020和/或网络接口42030。
接收模块42010从外部解码单元接收未压缩的音频内容或未压缩的视频内容。
外部解码单元可以是上述STB。
未压缩的音频内容或未压缩的视频内容可以是从上述STB(外部解码单元)发送至接收机的音频/视频内容。
这里，接收模块42010可对应于图41的HDMI。接收模块42010可以是图40或图41中未示出的模块。接收模块42010可由设计者修改。
外部解码单元可将从MVPD等接收的A/V内容解压缩，并且将解压缩的A/V内容传送给接收模块42010。未压缩的音频内容或未压缩的视频内容可根据上述ACR摄取模块而被处理。即，ACR摄取模块可计算帧的签名(指纹)(在指纹ACR系统的情况下)或者将包括码的水印插入帧中(在基于码的水印ACR系统的情况下)。这里，帧可涉及在被STB解码/解压缩之前的音频/视频内容。ACR摄取模块可将与签名或码关联的各个帧的media_time与其它元数据一起存储在数据库中。
标识符提取模块42020周期性地从通过接收模块42010接收的未压缩音频内容或未压缩视频内容的多个帧提取标识符。
标识符可标识接收的内容的帧。标识符可以是指纹签名或水印。本实施方式不限于指纹或水印。
这里，“提取”是周期性地从接收的未压缩音频内容或未压缩视频内容的多个帧提取标识符的处理，并且可对应于上述“计算签名”、“提取水印”和“产生签名”。
标识符提取模块42020周期性地提取与单个帧对应的标识符。提取的标识符可如上所述被发送给ACR服务器。如上所述，ACR服务器可将接收的标识符与数据库中的记录进行匹配。ACR服务器和数据库可以是上述ACR服务器和数据库。数据库中的记录可以是由ACR摄取模块预先存储的记录。
标识符提取模块42020可对应于图41的ACR模块。或者，标识符提取模块42020可以是图40或图41中未示出的模块。接收模块42020可由设计者修改。
在本发明的实施方式中，标识符提取循环可为5秒。标识符提取循环可根据设计者的意图而改变。
网络接口42030将包括提取的标识符的请求发送给服务器，并且根据发送给服务器的请求和标识符是否匹配数据库中的记录或者存在于匹配的记录中的触发来从服务器接收触发。这里，网络接口42030可基于请求来接收触发。
网络接口42030可对应于图41的网络接口。或者，网络接口42030是图40或图41中未示出的模块。网络接口42030可由设计者修改。
所提取的标识符可以是指纹签名或水印码。本实施方式不限于指纹或水印。
这里，请求可包括标识符。网络接口42030可周期性地向服务器发送请求。单个请求可包括单个标识符。周期可由设计者改变。
服务器可以是上述ACR服务器。服务器可接收请求并将该请求与数据库中的记录进行匹配。ACR服务器和数据库可以是上述ACR服务器和数据库。数据库中的记录可以是由ACR摄取模块预先存储的记录。
网络接口42030在任何情况下均没有接收针对上述请求的响应。当检测到新片段时或者当需要将事件激活传达给设备时，网络接口42030可接收触发。在其它情况下，设备可不接收触发。然而，根据设计者的意图，设备可在上述情况以外的情况下接收触发。
这里，所述片段可以是上述交互服务片段。
所述新片段可指在当前应用参数表或TPT之后使用的片段。
这里，将事件激活传达给接收机可意指事件激活被调度的情况或者需要被激活的事件还未激活的情况。
所述触发可涉及由接收模块42010从STB接收的内容。
所述内容可以是从STB接收的内容。
这里，所述触发可指示内容的当前时间并且参考应用参数表中的特定交互事件或者用信号通知事件将现在执行或在未来的指定时间执行。
这里，应用参数表可包括关于至少一个应用的信息。
服务器可以是上述ACR服务器。数据库可以是上述数据库。标识符可以是指纹签名或水印码。本实施方式不限于指纹或水印。
服务器可将接收的请求/标识符与数据库中的记录进行匹配。可将请求/标识符与由ACR摄取模块预先存储在数据库中的记录进行匹配。当标识符匹配存储在数据库中的标识符时，服务器可从数据库接收与该标识符相关的记录。在这种情况下，所述记录可包括时基触发或激活触发。记录中包括哪一触发可取决于先前由ACR摄取模块向记录中插入了什么触发。当从数据库接收到记录时，服务器可将接收的触发发送给网络接口39030。
在本发明的实施方式中，当标识符对应于新片段时触发可为时基触发，时基触发可用于使得接收机能够获得与新片段关联的新应用参数表。时基触发可符合上述时基触发操作。
在本发明的实施方式中，每当事件将要被激活时触发可为激活触发，激活触发设定事件的激活时间。激活触发可符合上述激活触发操作。激活触发可被应用于应用的事件以在特定时间导致激活。可通过事件激活向观看者提供交互服务。在根据本发明的实施方式的激活触发传送的情况下，可在上述ACR环境中，即，当接收机具有互联网连接并且从广播流访问未压缩的音频和视频时，提供交互服务器。
在本发明的实施方式中，当设备针对同一事件激活接收到一个以上激活触发时，激活触发可被应用一次。如上所述，针对同一事件激活，设备可接收到多个激活触发。根据本发明的实施方式，标识符可被周期性地提取并发送给服务器。这里，作为对周期性请求的响应，可接收到多个激活触发。如上所述，在这种情况下，激活触发具有相同的“t＝”项，因此设备可识别出激活触发为重复的并且仅应用一个激活触发。
在本发明的实施方式中，可在接收机需要应用激活触发的时间之前接收激活触发。这样，可在正确的激活时间激活事件。此实施方式可对应于上述静态激活。
在本发明的实施方式中，当在激活时间之后接收到激活触发时，可在接收到激活触发时立即激活事件。此实施方式可对应于上述动态激活。当服务器较晚识别出激活，使得服务器无法将激活触发发送给设备时，服务器可等待设备的下一请求，然后发送激活触发作为对下一请求的响应。在这种情况下，激活触发可指示过去的激活时间。这里，设备一接收到激活触发，设备就可应用激活触发。
在本发明的实施方式中，网络接口42030还被配置为当触发包括标识新应用参数表的应用参数表标识符时，立即下载该新应用参数表，除非设备已经利用随应用参数表传送的URL信息检索到该新应用参数表。如上所述，当设备接收到具有新应用参数表标识符的触发时，设备可通过下载新应用参数表(例如，TPT)来获得用于针对相关片段提供交互服务的新信息。在本发明的实施方式中，设备可利用http协议请求应用参数表服务器提供新应用参数表并且下载该新应用参数表。这里，根据本发明的实施方式，应用参数表可为XML格式或二进制格式。应用参数表标识符可以是上述locator_part。这里，URL信息可以是上述URLList。
在本发明的实施方式中，所述时间可以是媒体时间，媒体时间可以是参考内容项的播出中的点的参数。
在本发明的实施方式中，所述应用是声明对象、触发声明对象、非实时声明对象或无约束声明对象。
在本发明的实施方式中，除非发送和接收请求和响应，否则通信会话可被关闭。在请求实例之间通信会话没有保持打开。在通信会话保持打开时，接收机可通过通信会话接收响应。
在本发明的实施方式中，代替接收机，服务器可首先发送消息。即，服务器(例如，ACR服务器)可在任何时间向客户机(例如，接收机)发送消息。
在本发明的实施方式中，服务器可不需要额外的智能。服务器可仅将从数据库找到的信息传送给网络接口42030。ACR摄取模块可负责关于本发明的操作的智能。
参照附图分别描述的实施方式可被组合以实现新的实施方式。另外，在不脱离本发明的范围的情况下，本领域技术人员可设计可被存储有执行上述实施方式的程序的计算机读取的记录介质。
根据本发明的设备和方法不限于上述实施方式，这些实施方式可被选择性地组合并且以各种方式修改。
应用了本发明的处理与广播节目相关的交互服务的方法可被实现为代码，所述代码可被写在计算机可读记录介质上，因此可被处理器读取。计算机可读记录介质可以是以计算机可读方式存储数据的任何类型的记录装置。计算机可读记录介质的示例包括ROM、RAM、CD-ROM、磁带、软盘、光学数据存储和载波(例如，通过互联网的数据传输)。另外，分布在经网络连接的计算机装置中并且可被计算机以分布式方式读取的代码被存储在计算机可读记录介质中并执行。
本领域技术人员将理解，在不脱离本发明的精神和基本特性的情况下，本发明可按照本文所阐述的方式以外的特定方式来实现。因此，上述实施方式在所有方面均将被解释为示意性的，而非限制性的。本发明的范围应该由所附权利要求及其法律上的等同物来确定，而非由以上描述确定，落入所附权利要求书的含义和等同范围内的所有改变旨在被涵盖于其中。
本说明书中提及了设备和方法发明二者，设备和方法发明二者的描述可补充地应用于彼此。
本发明的模式
在具体实施方式中描述了各种实施方式。
工业实用性
本发明可用于一系列广播服务提供领域。
对于本领域技术人员而言将显而易见的是，在不脱离本发明的精神或范围的情况下可对本发明进行各种修改和变化。因此，本发明旨在涵盖本发明的这些修改和变化，只要它们落入所附权利要求及其等同物的范围内即可。

Claims (8)

1.一种在接收机处处理交互服务的方法，该方法包括以下步骤：
从外部解码单元接收未压缩的音频内容或未压缩的视频内容；
从所接收到的内容生成帧的签名；
向服务器发送具有所述签名的请求；
响应于所述请求从所述服务器接收针对所接收的内容的触发，
其中，所述触发是当在下一请求之前没有事件激活被调度发生时的时基触发，所述时基触发用于维持所接收的内容的媒体时间，
其中，所述触发是当特定事件预计要被激活时的激活触发，所述激活触发对来自应用参数表的要被激活的特定事件和所述特定事件的激活时间进行标识，
其中，所述应用参数表包括具有针对各个应用的元数据的应用元素，各个应用元素具有事件元素，所述事件元素具有针对目标为所述各个应用的各个事件的元数据，并且各个事件元素具有数据元素，所述数据元素具有要用于所述各个事件的各个数据集，
其中，所述激活触发包括ID项，所述ID项参考针对所述特定事件所指向的应用的应用元素的应用ID，并且所述ID项还参考针对所述特定事件的事件元素的事件ID；以及
通过利用所述触发和所述应用参数表来提供针对所接收的内容的所述交互服务。
2.根据权利要求1所述的方法，其中，在所述特定事件的激活时间之前接收所述激活触发。
3.根据权利要求1所述的方法，其中，当在所述特定事件的激活时间之后接收到所述激活触发时，在接收到所述激活触发时立即激活所述特定事件。
4.根据权利要求1所述的方法，其中，当所述接收机针对同一事件激活接收到一个以上激活触发时，所述激活触发被应用一次。
5.一种处理交互服务的设备，该设备包括：
接收模块，该接收模块从外部解码单元接收未压缩的音频内容或未压缩的视频内容；
签名模块，该签名模块从所接收到的内容生成帧的签名；
网络接口，该网络接口向服务器发送具有所述签名的请求，
其中，所述网络接口响应于所述请求从所述服务器接收针对所接收的内容的触发，
其中，所述触发是当在下一请求之前没有事件激活被调度发生时的时基触发，所述时基触发用于维持所接收的内容的媒体时间，
其中，所述触发是当特定事件预计要被激活时的激活触发，所述激活触发对来自应用参数表的要被激活的特定事件和所述特定事件的激活时间进行标识，
其中，所述应用参数表包括具有针对各个应用的元数据的应用元素，各个应用元素具有事件元素，所述事件元素具有针对目标为所述各个应用的各个事件的元数据，并且各个事件元素具有数据元素，所述数据元素具有要用于所述各个事件的各个数据集，
其中，所述激活触发包括ID项，所述ID项参考针对所述特定事件所指向的应用的应用元素的应用ID，并且所述ID项还参考针对所述特定事件的事件元素的事件ID；以及
交互模块，该交互模块通过利用所述触发和所述应用参数表来提供针对所接收的内容的所述交互服务。
6.根据权利要求5所述的设备，其中，在所述特定事件的激活时间之前接收所述激活触发。
7.根据权利要求5所述的设备，其中，当在所述特定事件的激活时间之后接收到所述激活触发时，在接收到所述激活触发时立即激活所述特定事件。
8.根据权利要求5所述的设备，其中，当所述设备针对同一事件激活接收到一个以上激活触发时，所述激活触发被应用一次。
CN201380047531.XA 2012-09-12 2013-08-28 处理交互服务的设备和方法 Active CN104662925B (zh)

Applications Claiming Priority (5)

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

Publications (2)

Publication Number Publication Date
CN104662925A CN104662925A (zh) 2015-05-27
CN104662925B true CN104662925B (zh) 2018-12-04

Family

ID=50234775

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201380047531.XA Active CN104662925B (zh) 2012-09-12 2013-08-28 处理交互服务的设备和方法

Country Status (9)

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

Families Citing this family (14)

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

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101297549A (zh) * 2005-09-06 2008-10-29 诺基亚公司 在服务指南中的预配置交互消息的增强信号传送
WO2012091322A1 (ko) * 2010-12-26 2012-07-05 엘지전자 주식회사 방송 서비스 전송 방법, 그 수신 방법 및 그 수신 장치

Family Cites Families (18)

* 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
US20020162118A1 (en) * 2001-01-30 2002-10-31 Levy Kenneth L. Efficient interactive TV
US20030192060A1 (en) * 2001-01-30 2003-10-09 Levy Kenneth L. Digital watermarking and television services
US8407752B2 (en) * 2004-03-18 2013-03-26 Digimarc Corporation Synchronizing broadcast content with corresponding network content
US20070074079A1 (en) * 2005-09-27 2007-03-29 Forster Darren P System and method for providing trigger information in a video signal and playing out a triggered event
US20070162399A1 (en) * 2005-12-22 2007-07-12 Alexander Medvinsky Method and apparatus for providing broadcast trigger messages
US8813152B2 (en) * 2008-08-26 2014-08-19 At&T Intellectual Property I, L.P. Methods, apparatus, and computer program products for providing interactive services
US20110154404A1 (en) * 2009-12-17 2011-06-23 At & T Intellectual Property I, L.P. Systems and Methods to Provide Data Services for Concurrent Display with Media Content Items
US8730301B2 (en) * 2010-03-12 2014-05-20 Sony Corporation Service linkage to caption disparity data transport
US8893210B2 (en) * 2010-08-20 2014-11-18 Sony Corporation Server load balancing for interactive television
JP5897468B2 (ja) * 2010-08-30 2016-03-30 ソニー株式会社 受信装置、受信方法、及びプログラム
JP5691316B2 (ja) 2010-09-09 2015-04-01 新東工業株式会社 バケットエレベータ内部の結露または粉体の付着を予測及び検出する方法及び装置とそれに用いられる測定ユニット
US9078031B2 (en) 2010-10-01 2015-07-07 Sony Corporation Reception apparatus, reception method, and program
US9398328B2 (en) * 2010-11-24 2016-07-19 Lg Electronics Inc. Video display device and method for controlling same
CA2820574C (en) 2010-11-24 2016-10-25 Lg Electronics Inc. Method of receiving enhanced service and video display device thereof
JP5783402B2 (ja) * 2011-01-25 2015-09-24 ソニー株式会社 受信装置、受信方法、供給装置、供給方法、プログラム、および放送システム
US9554175B2 (en) * 2011-07-20 2017-01-24 Sony Corporation Method, computer program, reception apparatus, and information providing apparatus for trigger compaction
US9154840B2 (en) * 2012-07-31 2015-10-06 Sony Corporation Reception apparatus, reception method, transmission apparatus, and transmission method

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101297549A (zh) * 2005-09-06 2008-10-29 诺基亚公司 在服务指南中的预配置交互消息的增强信号传送
WO2012091322A1 (ko) * 2010-12-26 2012-07-05 엘지전자 주식회사 방송 서비스 전송 방법, 그 수신 방법 및 그 수신 장치

Also Published As

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

Similar Documents

Publication Publication Date Title
CN104662925B (zh) 处理交互服务的设备和方法
CN104584574B (zh) 处理交互服务的设备和方法
CN104396186B (zh) 用于处理互动服务的装置及方法
JP6352992B2 (ja) 対話型放送サービスを含む放送信号処理方法及び装置
CN104871552B (zh) 处理交互服务的设备和方法
KR20150076163A (ko) 양방향 서비스를 처리하는 장치 및 방법
CN104012107B (zh) 处理与广播节目有关的双向服务的装置和方法

Legal Events

Date Code Title Description
C06 Publication
PB01 Publication
C10 Entry into substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant