本发明涉及一种用于提供、接收和处理广播服务的方法和设备，更具体地讲，涉及一种用于提供与广播内容相关的补充服务的方法和设备。
背景技术：
：：TV首次出现于19世纪末，并且自20世纪末起随着其画面显示方法或设计不断发展，已成为最普及的信息传送设备。然而，TV通常使得观看者能够从广播台接收单向信息。随着自20世纪90年代起个人计算机(PC)和互联网得以广泛使用，TV的这些局限已成为问题。因此，TV已发展为能够提供交互服务。然而，目前，没有在内容提供商与观看者之间提供交互服务的系统。具体地讲，为了提供这种交互服务，需要一种在特定时间执行与当前广播的广播内容相关的应用并且通过特殊信息处理将相关信息提供给观看者的方法。技术实现要素：技术问题为解决所述问题而设计出的本发明的目的在于在广播内容被回放的时间段期间的适当时间与广播内容相关的补充信息。技术方案为了实现本发明的目的，根据本发明的一种在接收机处处理交互服务的方法包括以下步骤：从外部解码单元接收未压缩的音频内容或未压缩的视频内容；从所接收到的内容提取帧的标识符；将包含所述标识符的请求发送给服务器；以及基于所述请求从所述服务器接收用于所述内容的触发，其中，所述触发指示所述内容的当前时间并且参考应用参数表中的特定交互事件或者用信号通知所述事件要现在执行或者在指定的未来时间执行，其中，所述应用参数表包括关于多个应用中的至少一个的信息。优选地，当在发送下一请求之前没有事件激活被调度发生时，所述触发是时基触发，并且所述时基触发用于维持片段的时间。优选地，当激活预计将发生时，所述触发是激活触发，其中，所述激活触发设定所述事件的激活时间，并且所述激活时间由所述激活触发中的定时值项来指示。优选地，所述方法还包括以下步骤：当所述触发包括标识新应用参数表的应用参数表标识符时，立即下载所述新应用参数表，除非所述接收机已经利用所述应用参数表所传送的URL信息检索到所述新应用参数表。优选地，所述方法还包括以下步骤：当所述接收机没有与所述触发关联的新应用时，从所述应用参数表或所述新应用参数表获得所述新应用的应用URL；以及利用所述应用URL来下载所述新应用。优选地，当所述接收机针对同一事件激活接收到不止一个激活触发时，所述激活触发被应用一次。优选地，当在所述激活时间之后接收到所述激活触发时，所述激活触发一到达就应用所述激活触发。优选地，所述时间是媒体时间，并且所述媒体时间是参考内容项的播出(playout)中的点的参数。优选地，所述应用是声明对象、触发声明对象、非实时声明对象或无约束声明对象。为了实现本发明的目的，一种根据本发明的处理交互服务的设备包括：接收模块，其被配置为从外部解码单元接收未压缩的音频内容或未压缩的视频内容；标识符提取模块，其被配置为从所接收到的内容提取帧的标识符；以及网络接口，其被配置为将包含所述标识符的请求发送给服务器，并且基于所述请求从所述服务器接收用于所述内容的触发，其中，所述触发指示所述内容的当前时间并且参考应用参数表中的特定交互事件或者用信号通知所述事件将现在执行或者在指定的未来时间执行，并且所述应用参数表包括关于至少一个应用的信息。优选地，当在发送下一请求之前没有事件激活被调度发生时所述触发是时基触发，并且所述时基触发用于维持片段的时间。优选地，当激活预计将发生时所述触发是激活触发，其中，所述激活触发设定所述事件的激活时间，并且所述激活时间由所述激活触发中的定时值项来指示。优选地，所述网络接口还被配置为当所述触发包括标识新应用参数表的应用参数表标识符时，立即下载所述新应用参数表，除非所述设备已经利用所述应用参数表所传送的URL信息检索到所述新应用参数表。优选地，所述设备还包括触发模块，该触发模块被配置为当所述设备没有与所述触发关联的新应用时，从所述应用参数表或所述新应用参数表获得所述新应用的应用URL，其中，所述网络接口还被配置为利用所述应用URL来下载所述新应用。优选地，当所述设备针对同一事件激活接收到不止一个激活触发时，所述激活触发被应用一次。优选地，当在所述激活时间之后接收到所述激活触发时，所述激活触发一到达就应用所述激活触发。优选地，其中，所述时间是媒体时间，并且所述媒体时间是参考内容项的播出中的点的参数。优选地，所述应用是声明对象、触发声明对象、非实时声明对象或无约束声明对象。有益效果根据本发明，可利用现有广播系统提供与广播内容相关的附加信息。根据本发明，可准确地确认与广播内容相关的附加信息何时显示并且在适当的时间向用户提供所述附加信息。根据本发明，可将与广播内容相关的附加信息提供给具有互联网连接并且可经由广播流访问未压缩的音频和视频的接收机。附图说明附图被包括以提供对本发明的进一步理解，附图示出本发明的实施方式并与说明书一起用于说明本发明的原理。附图中：图1是示出典型广播流的实施方式的示图；图2是示出在预制作的内容的情况下的触发定时的实施方式的示图；图3是示出在直播内容的情况下的触发定时的实施方式的示图；图4是示出触发句法的实施方式的示图；图5是示出TDO参数表的实施方式的示图；图6是示出TDO参数表的实施方式的示图；图7是示出“FrequencyofUse”属性值的含义的示图；图8是示出“destination”属性值的含义的示图；图9是示出TDO参数表的二进制形式的句法的实施方式的示图；图10是示出TDO参数表的二进制形式的句法的实施方式的示图；图11是示出TDO参数表的二进制形式的句法的实施方式的示图；图12是示出TDO参数表的二进制形式的句法的实施方式的示图；图13是示出TDO参数表的二进制形式的句法的实施方式的示图；图14是示出激活消息表结构的实施方式的示图；图15是示出URLList结构图的实施方式的示图；图16是示出包含TPT的私有区段的二进制格式的实施方式的示图；图17是示出被编码为XML文档的URL列表的实施方式的示图；图18是示出addTriggerEventListener的实施方式的示图；图19是示出removeTriggerEventListener的实施方式的示图；图20是示出EventListener类型的定义的实施方式的示图；图21是示出TriggerEvent类型的定义的实施方式的示图；图22是示出用于WM方法的架构的实施方式的示图；图23是示出用于FP方法的架构的实施方式的示图；图24是示出请求/响应ACR情况下的静态激活的实施方式的示图；图25是示出请求/响应ACR情况下的静态激活的实施方式的示图；图26是示出请求/响应ACR情况下的动态激活的实施方式的示图；图27是示出请求/响应ACR情况下的动态激活的实施方式的示图；图28是示出用于ACR服务器激活的架构的实施方式的示图；图29是示出没有EndTime的情况(b)和情况(a)下的激活触发的实施方式的示图；图30是示出没有EndTime的情况(b)和情况(a)下的激活触发的实施方式的示图；图31是示出具有EndTime的情况(a)下的激活触发的实施方式的示图；图32是示出具有EndTime的情况(a)下的激活触发的实施方式的示图；图33是示出情况(c)的激活触发的实施方式的示图；图34是示出情况(c)的激活触发的实施方式的示图；图35是示出在请求/响应ACR情况下ACR客户机与其它服务器之间的顺序图的实施方式的示图；图36是示出在请求/响应模型中在接收机处处理交互服务的方法的实施方式的示图；图37是示出根据本发明的实施方式的接收机的结构的示图；图38是示出在机顶盒经由高清晰多媒体接口(HDMI)或外部接口接收广播的情况下根据本发明的实施方式的接收机的结构的示图；以及图39是示出在请求/响应模型中处理交互服务的设备的实施方式的示图。具体实施方式尽管本发明中使用的术语选自通常所知并使用的术语，但本文所用的术语可根据运营商的意图或者本领域的惯例、新技术的出现等而变化。另外，本发明的描述中所提及的一些术语由申请人酌情选择，其详细含义在本文描述的相关部分中进行描述。另外，本发明不能简单地通过实际使用的术语来理解，而是需要通过各个术语的内部含义来理解。在本说明书中，术语媒体时间代表参考音频/视频或音频内容项的播出中的点的参数。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)和打包应用(PackagedApp)具有以下含义。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可被视为由三个部分组成。<domainnamepart>/<directorypath>[？<parameters>]<domainnamepart>可以是注册域名，<directorypath>可以是URI中将出现的路径。<domainnamepart>可参考注册的互联网域名。<directorypath>可以是在对标识的域名有权的实体的控制和管理下标识目录路径的任意字符串。在TDO模型中，<domainnamepart>和<directorypath>的组合可唯一地标识可由接收机处理以向关联的内容添加交互性的TPT。<domainnamepart>和<directorypath>的组合可以是可获得用于当前片段的TPT的互联网位置的URL。即，触发可利用<domainnamepart>和<directorypath>来标识TPT。通过<domainnamepart>和<directorypath>，可确定应用了触发的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*7hexdigitspread＝"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＝”项可指示所有接收机应该尝试访问触发中所标识的互联网服务器的时间(秒数)。各个单独的接收机应该会推导指定的间隔内的随机时间，并且将访问请求延迟该时间量，从而在接收机处在时间上分散需求高峰(否则的话在触发首次出现时可能发生所述需求高峰)。包含<mediatime>参数的触发可称为时基触发，因为它用于建立事件时间的时基。包含<eventtime>参数的触发可称为激活触发，因为它设定事件的激活时间。图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实例中描述的交互服务关联的NRTservice_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”可对应于“Trigprep”动作。如果目标应用的状态为“释放”，则该动作可导致状态改变为“就绪”。“exec”可对应于“Trigexec”动作。在接收到此触发时目标应用的状态可变为“活动”。“susp”可对应于“Trigsusp”动作。如果目标应用的状态为“活动”，则在接收到此触发时状态可改变为“暂停”，否则不改变。“kill”可对应于“Trigkill”动作。在接收到此触发时目标应用的状态可变为“释放”。@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是示出“FrequencyofUse”属性值的含义的示图。“含义”列指示包含该应用的片段的发生频率。(当然，属性可在单个片段内出现多次。)如果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(可具有与TPTXML格式的“id”属性相同的语义)的字节。base_URL_length(可为8比特字段)可指示base_URL字段的长度(字节)。base_URL(为可变长度的字段)可包含基本URL(可具有与TPTXML格式的baseURL属性相同的语义)的字节。当存在时，expire_date(可为32比特字段)可指示此TPT实例中包括的信息的期满日期和时间。如果接收机缓存TPT，则它可被重用直至expireDate。无符号整数可被解释为自1980年1月6日00:00:00UTC起的GPS秒数减去GPS-UTC_offset。GPSUTC偏移可以是定义GPS与UTC时间标准之间的总当前偏移(秒)的8比特无符号整数。trigger_server_URL_length(可为8比特字段)可指示trigger_server_URL字段的长度(字节)。当此字段的值为0时，可指示各个激活触发的互联网传送不可用。当trigger_server_URL_length字段的值不为0时，trigger_server_URL可包含触发服务器URL(可具有与TPTXML格式的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(为可变长度的字段)可具有与TPTXML格式中的TDO元素的appName属性相同的语义。当存在时，global_id_length(可为8比特字段)可指示紧随其之后的global_id字段的长度(字节)。此字段的值0可指示针对此应用不存在global_id字段。当存在时，global_id(为可变长度的字段)可具有与TPTXML格式中的TDO元素的globalId属性相同的语义。当存在时，app_version(可为8比特字段)具有与TPTXML格式中的TDO元素的appVersion属性相同的语义。当存在时，cookie_space(可为8比特字段)可具有与TPTXML格式中的TDO元素的cookieSpace属性相同的语义。当存在时，frequency_of_use(可为8比特字段)可具有与TPTXML格式中的TDO元素的frequencyOfUse属性相同的语义。当存在时，expire_date(可为8比特字段)可具有与TPTXML格式中的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(为可变长度的字段)可具有与TPTXML格式中的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(为可变长度的字段)可具有与TPTXML格式中的TDO元素的ContentItem子元素的URL属性相同的语义。content_size(可为24比特字段)可具有与TPTXML格式中的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比特字段)可具有与TPTXML格式中的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字段的语义可与TPTXML格式中的TDO元素的Event子元素的destination属性的语义相同。当存在时，diffusion字段的语义可与TPTXML格式中的TDO元素的Event子元素的diffusion属性的语义相同。当存在时，data_size字段可指示紧随其之后的data_bytes字段的大小。当存在时，data_bytes字段可提供与此事件相关的数据。每当事件被激活时，目标应用将能够读取数据并使用它来帮助执行期望的动作。除了此字段可包含原二进制值，而TPTXML格式中的Data元素可包含二进制值的base64编码以外，此字段的内容可与TPTXML格式中的对应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是示出URLList结构图的实施方式的示图。URLList可包含接收机可能使用的特定URL。URLlist可包括以下URL等。1.一个或更多个未来片段的TPT的URL，使接收机能够预先下载文件。2.可检索关于广播流中的独立NRT服务的信息的NRT信令服务器的URL，使接收机即使无法访问广播流中的NRT服务信令的传送也能访问那些服务。3.可针对虚拟信道发送使用报告的使用报告服务器的URL，使接收机即使无法访问广播流中此URL的传送也能够在这些报告中发送。4.虚拟信道的PDI-Q表的URL，使接收机即使无法访问广播流中传送的PDI-Q表也能够使观看体验个性化。(PDI-Q表与在提供交互服务时进行个性化以提供用户定制的服务相关。可就经由PDI-Q表的个性化询问用户。)除了别的以外，可相对于UrsUrl元素使URLlist进一步指示用于使用报告的服务器的URL，以便使用优选数据和当前通过商业接收机观看和消费的内容的类型。URLlist中所包括的UrsUrl元素可如下不同地解释。首先，在使用报告服务器的情况下，接收机可利用使用报告服务器的URL通过预定协议(例如，数据结构、XML文件等)执行接收机的使用报告功能。其次，可能存在于接收机的网络浏览器上执行的TDO。在这种情况下，这指示使用报告TDO的位置。在这种情况下，TDO可利用接收机的网络浏览器的API(例如，文件API或使用报告API)直接收集并报告关于存储在接收机中或者当前消费的内容的信息。TDO可利用称为XMLHttpRequest的JavascriptAPI发送所收集的数据。以下，将描述URLlist。URLlist可包括UrlList、TptUrl、UrsUrl和/或PdiUrl。这些元素的语义如下。TptUrl(是UrlList元素的元素)可包含当前交互附属服务中的未来片段的TPT的URL。当包括多个TptUrl元素时，它们可按照片段在广播中出现的顺序来排列。NrtSignalingUrl(是UrlList元素的元素)可包含接收机可从其获得当前传输流中的所有虚拟信道的NRT信令表的服务器的URL。UrsUrl(是UrlList元素的元素)可包含接收机可向其发送当前虚拟信道的使用(受众测量)报告的服务器的URL。PdiUrl(是UrlList元素的元素)可包含当前虚拟信道的PDI-Q表的URL。以下将描述传送机制。以下将顺序描述从交互服务创建的输出、广播流中的触发的传送、经由互联网的时基触发的传送、经由互联网的激活触发的传送(ACR场景)、广播流中的TPT的传送、经由互联网的TPT的传送、移动TDO和内容项、将多个片段组合成一个片段。除了别的以外，尽管未示出，但是从交互服务创建的输出、广播流中的触发的传送、经由互联网的时基触发的传送、经由互联网的激活触发的传送(ACR场景)、移动TDO和内容项、将多个片段组合成一个片段不限于此说明书，而是可根据设计者的意图而改变。图16和图17分别是示出在广播流中传送TPT和经由互联网传送TPT的示图。以下将描述传送机制。以下将描述从交互服务创建的输出。针对片段的服务创建的处理可得到包含所有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：LongPollingATSC-Delivery-Mode：Streaming<poll-period>参数可指示用于后续轮询的推荐的轮询之间的间隔。<poll-period>可省略。以下将描述整体激活触发传送。当经由互联网整体传送激活触发时，片段的激活触发可随片段的TPT一起经由HTTP以多部分MIME消息的形式传送，其中TPT作为消息的第一部分，激活消息表(AMT)作为消息的第二部分。图16是示出包含TPT的私有区段的二进制格式的实施方式的示图。下述NRT式私有区段可等同于图16。以下将描述广播流中的TPT的传送。当在广播流中传送时，可将TPT从其XML格式转化成等同二进制NRT式信令表格式并封装在NRT式私有区段中，每一个表实例一个TPT。当前片段的TPT总是存在。一个或更多个未来片段的TPT也可能存在。TPT实例由其segment_id字段的值定义。作为参考，上面描述了TDO参数表的二进制格式。总而言之，为了按照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实例。私有区段(tpt_section())可包括table_id、protocol_version、sequence_number、TPT_data_version、current_next_indicator、section_number、last_section_number和/或service_id和tpt_bytes()信息。以下将描述图16的字段。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是示出被编码为XML文档的URL列表的实施方式的示图。以下将描述经由互联网的TPT的传送。当经由互联网传送时，可经由HTTP传送TPT。用于当前片段的TPT的URL可以是时基消息中的“<domainnamepart>/<directorypath>”。对TPT请求的响应可仅由TPT组成，或者可由被编码为XML文档的2部分MIME消息(请求的TPT在第一部分中，URL的列表在第二部分中)组成。(对请求的响应将总是包括用于当前片段的TPT。它还可包括用于一个或更多个未来片段的TPT。)作为上述响应的第二部分的URL可具有图17所示的格式。将描述图17的元素的语义。“UrlList”可包含可用于接收机的URL的列表。“TptUrl”可包含用于未来片段的TPT的URL。当包括多个TptUrl元素时，它们按照片段在广播中出现的顺序来排列。“NrtSignalingUrl”可包含接收机可从其获得针对当前广播流中的所有虚拟信道的NRT信令表的服务器的URL。以下将描述移动TDO和内容项。网络和站将常常需要提供它们自己的HTTP服务器以用于传送TDO和TDO所使用的内容项(文件)。当这样做时，可调节TPT中的baseURL以反映服务器的位置。以下将描述将多个片段组合成一个片段。为了彻底地使片段之间的边界模糊，用于多个片段的TPT和AMT可被组合成单个TPT和AMT。可执行以下步骤。1.标识要组合的片段的集合。2.利用新segmentId创建新TPT。3.如果被组合的任何片段具有即时激活，则提供支持所有这些激活的访问的中继服务器，并将用于此服务器的参数设置在“LiveTrigger”元素中。4.根据需要应用各个片段的baseURL以得到完整TDO和ContentItemURL。(可标识被组合的所有片段所共同的较短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中。图18是示出addTriggerEventListener的实施方式的示图。图19是示出removeTriggerEventListener的实施方式的示图。图20是示出EventListener类型的定义的实施方式的示图。图21是示出TriggerEvent类型的定义的实施方式的示图。以下将描述用于执行DO的环境的ATSCJavaScriptAPI。为了支持声明对象动作与广播节目的同步，可针对视频/广播对象支持附加方法。如果经由DTVCC或互联网接收到TPT，则执行TDO的多个事件可存在于TPT中，这些事件可通过激活触发来激活。为了处理此事件，可基于eventID注册Listener函数。因此，作为上述“附加方法”，可存在两个函数addTriggerEventListener和removeTriggerEventListener，以用于注册Listener函数。addTriggerEventListener函数可注册用于处理基于eventId产生的事件的回调函数(listener函数)。removeTriggerEventListener函数可取消用于处理基于eventId产生的事件的回调函数(listener函数)的注册。在图18中，描述addTriggerEventListener并且示出格式、参数等。addTriggerEventListener函数可接收EventListener类型的listener和Number类型的eventId作为参数。EventListener类型将在下面描述。addTriggerEventListener函数可不具有返回值(void)。这里，eventId参数可以是TPT的event元素中的eventID。这里，listener参数可以是用于该事件的监听器。一接收到激活消息，接收机的触发处理模块就可利用“addTriggerEventListener”函数基于eventId注册listener函数。如果事件被激活，则可调用注册的listener函数。此时，可将TriggerEvent类型的对象传送给listener函数。TriggerEvent类型将在下面描述。在图19中，描述removeTriggerEventListener并且示出格式、参数等。removeTriggerEventListener函数可接收EventListener类型的listener和Number类型的eventId作为参数。EventListener类型将在下面描述。removeTriggerEventListener函数可不具有返回值(void)。这里，eventide参数可以是TPT的event元素中的eventide。这里，listener参数可以是用于该事件的监听器。在javascript程序中，如果期望不再接收可基于eventId产生的事件或者如果程序“DestroyWindow”完成，则可取消利用“removeTriggerEventListener”注册的listener函数。图20示出EventListener类型的定义。EventListener类型可具有事件TriggerEvent类型作为参数。EventListener可以是接口。图21示出TriggerEvent类型的定义。TriggerEvent类型可包含关于事件的信息。TriggerEvent类型可具有eventId、data和status作为性质。这里，eventId可以是TPT的event元素中的eventID。这里，data可以是用于事件的此激活的数据。这里，data可为十六进制。这里，status可表示事件的状态。这里，如果status值为“trigger”，则意指通过激活触发激活事件的状态。如果status值为“error”，则意指发生错误的状态。以下将描述直接执行模型。在直接执行模型中，一选择虚拟信道就可自动启动声明对象(DO)。其可经互联网与后端服务器通信以得到提供交互特征–在屏幕上的特定位置创建显示，进行轮询，启动其它专用DO等(全部与音频-视频节目同步)的详细指令。以下将描述直接执行模型中的触发操作。在直接执行模型中触发的角色、功能和句法没有很大地改变。触发的性能与上面所述相同。触发句法与上面所述相同。触发可被视为由三个部分组成。<domainnamepart>/<directorypath>[？<parameters>]在直接执行模型中，<domainnamepart>和<directorypath>的组合可唯一地标识要启动的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方法的架构的实施方式的示图。图23是示出用于FP方法的架构的实施方式的示图。以下将描述经由其它接口支持的传送。在仅可访问未压缩的视频和音频(例如，从有线或卫星机顶盒接收的)的环境中，定义能够获取交互服务的架构和协议。所述架构和协议可被设计成由具有互联网连接并且仅能从广播流访问未压缩的音频和视频的接收机使用。当然，如果交互服务提供商选择支持它们，则所述架构和协议也可被成功使用。所述架构可被设计成支持两个基本方法来标识观看的内容，使得可经由互联网传送任何关联的交互服务数据增强。两个基本方法可以是水印或指纹。在水印和指纹方法中，均旨在能允许接收机找出当前正在看什么节目并且获得URL，该URL可用作得到关于该节目的交互服务的附加信息的起始点。图22是示出WM方法的架构的实施方式的示图。在用于WM方法的架构中，该架构可包括广播商22010、水印插入商22011、MVPD22020、STB22030、接收机22040、WM客户机22050、TPT服务器22060和内容服务器22070。广播商22010可以是提供音频/视频流以及与其相关的交互服务的源。广播商的示例可包括TV台等。广播商可以是广播内容的制造者或分销商。广播商可传送广播流、音频/视频内容、交互数据、广播调度、AMT等。水印插入商22011可将水印到插入广播的音频/视频帧中。水印插入商22011可与广播商22010组合或与广播商22010分开。水印可以是接收机所需的信息。水印可以是诸如URL的信息。水印将在下面详细描述。MVPD22020可以是多程序视频节目分销商的缩写。MVPD22020可以是有线运营商、卫星运营商、或者IPTV运营商。MVPD22020可从广播商/水印插入商接收广播流(在水印ACR系统的情况下，由水印插入商22011插入了水印)。MVPD22020常常剔除音频和视频轨道以外的所有节目元素，并且将所得到的流发送给用户驻地的机顶盒(STB)。STB22030通常将音频和视频解码(解压缩)并且将它们发送给电视机以便呈现给观看者。STB可将未压缩的音频/视频内容发送给接收机22040。根据本发明的一个实施方式，STB可以是外部解码单元。接收机22040可包括WM客户机22050。WM客户机22050可设置在接收机22040的外部。这里，接收机是具有水印功能的接收机。接收机22040的结构将在下面描述。WM客户机22050可从ACR服务器(未示出)得到激活触发并利用为该目的提供的API将它们变成主接收机码。通常，WM客户机22050将被内置于接收机中，但是其它配置也是可能的。WM客户机22050可从未压缩的音频/视频内容提取插入的水印。所述水印可以是诸如URL的信息。TPT服务器22060可下载诸如TPT的应用。在所提取的水印被发送给ACR服务器之后，如果该水印匹配存储在数据库(未示出)中的水印，则接收机22040可接收触发作为响应。如果接收的触发可具有上述新locator_part或TPT，或者如果找到新版本号的应用参数表，则接收机22040可从TPT服务器22060请求并下载TPT或应用参数表。内容服务器22070可提供应用、TDO等(是提供交互服务所需的)。如果需要新应用或TDO，则可利用TPT或应用参数表的URL来下载新应用等。在水印(WM)方法中，广播商/水印插入商可将水印插入到广播音频或视频帧中。这些水印可被设计成向接收机承载适度量的信息，同时观看者难以察觉或者至少对观看者的干扰程度很低。这些水印可能直接提供接收机所需的信息，或者可能仅提供码值，接收机可经由互联网连接将该码值发送给远程服务器以便得到它们所需的信息。图23是示出FP方法的架构的实施方式的示图。在用于FP方法的架构中，该架构可包括广播商23010、MVPD23020、STB23030、接收机23040、FP客户机23050、TPT服务器23060、内容服务器23070、签名提取器23080和FP服务器23090。广播商23010可以是提供音频/视频流以及与其相关的交互服务的源。广播商的示例可包括TV台等。广播商可以是广播内容的制造者或分销商。广播商可传送广播流、音频/视频内容、交互数据、广播调度、AMT等。MVPD23020可以是多程序视频节目分销商的缩写。MVPD23020可以是有线运营商、卫星运营商或者IPTV运营商。MVPD23020常常剔除音频和视频轨道以外的所有节目元素，并且将所得到的流发送给用户驻地的机顶盒(STB)。STB23030通常将音频和视频解码(解压缩)并且将它们发送给电视机以便呈现给观看者。STB可将未压缩的音频/视频内容发送给接收机23040。根据本发明的一个实施方式，STB23030可以是外部解码单元。接收机23040可包括FP客户机23050。FP客户机23050可设置在接收机23040的外部。这里，接收机是具有指纹功能的接收机。接收机23040的结构将在下面描述。FP客户机23050可从FP服务器23090得到激活触发并利用为该目的提供的API将它们变成主接收机码。通常，FP客户机23050将被内置于接收机中，但是其它配置也是可能的。FP客户机23050可从未压缩的音频/视频内容提取指纹。所述指纹将在下面描述。TPT服务器23060可下载诸如TPT的应用。在所提取的指纹被发送给FP服务器23090之后，如果该指纹匹配签名提取器23080的签名，则接收机23040可接收触发作为响应。如果所接收到的触发可具有上述新locator_part或者如果找到新版本号的TPT或应用参数表，则接收机23040可从TPT服务器23060请求并下载TPT或应用参数表。内容服务器23070可提供应用、TDO等(是提供交互服务所需的)。如果需要新应用或TDO，则可利用TPT或应用参数表的URL来下载新应用等。签名提取器23080可从广播商23010接收元数据。签名提取器23080可从所接收到的元数据提取帧的签名。如果由FP服务器23090接收的指纹匹配签名提取器23080的签名，则签名提取器23080可将与其相关的元数据发送给FP服务器23090。FP服务器23090可执行与签名提取器23080的签名匹配处理。FP服务器可执行签名与从接收机23040接收的指纹之间的匹配处理。如果签名匹配指纹，则FP服务器可从签名提取器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将预先安装或者预先下载并缓存。或者，接收机应该会利用HTTPGET请求来下载它。然后，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_timeMta，因此接收机得到包含具有“t＝MTa”项的激活触发的响应。对于具有媒体时间MT3的帧，接收机刚刚得到包含时基触发的响应。接收机可针对相同的事件激活接收不止一个激活触发。然而，各个激活触发的媒体时间将相同，因此接收机可将它们识别为重复的，并且仅应用其中的一个。图25是示出请求/响应ACR情况下的静态激活的实施方式的示图。以下将描述ACR服务器使用请求/响应模型的情况。这类似于图24的描述。在图25中，接收机可针对在本地时钟时间LC1、LC2、LC3等观看的帧发送签名。在本地时钟时间LC1观看的帧的media_time可被ACR服务器确定为MT1，接收机刚刚得到包含没有media_time或event_time的触发的响应。在本地时钟时间LC2观看的帧的media_time可被ACR服务器确定为MT2，ACR服务器知道静态激活预计将在media_timeMta，因此ACR服务器发送包含具有“d＝<offset>”项的激活触发的响应，这意味着激活的media_timeMta是在MT2之后<offset>时间单位。然后接收机将<offset>与时间LC2相加并且得到LCa作为它应该激活事件的本地时间。图26是示出请求/响应ACR情况下的动态激活的实施方式的示图。以下将描述在请求/响应ACR情况下发生动态激活的情况。对于动态激活，在ACR系统不知道事件激活，直至对于提前向接收机发送触发而言太晚了的情形下，ACR服务器需要等待直至下一请求，然后发送激活触发。图26示出这种情况。这种情况的效果在于动态激活可被延迟一个请求间隔那么久。在图26中，接收机可针对ACR服务器确定具有媒体时间MT1、MT2和MT3的帧发送签名。对于具有媒体时间MT1和MT2的帧，接收机刚刚得到包含时基触发的响应。当具有激活时间MTa的动态激活出现在media_timeMta处或者之前不久时，ACR服务器无法将它通知给接收机，直至来自接收机的下一请求(这发生在具有媒体时间MT3的帧的情况下)。此时，ACR服务器响应包含具有激活时间MTa(之前少许)的激活触发。在这种情形下，激活触发一到达，接收机应该就会应用激活触发。这里同样，接收机可针对相同的事件激活接收不止一个激活触发。然而，各个激活触发的媒体时间将相同，因此接收机可将它们识别为重复的并且仅应用其中的一个。图27是示出请求/响应ACR情况下的动态激活的实施方式的示图。以下将描述在请求/响应ACR情况下发生动态激活的情况。这类似于图26的描述。在图27中，接收机可针对在本地时钟时间LC1、LC2、LC3等观看的帧发送签名。在本地时钟时间LC1观看的帧的media_time可被ACR服务器确定为MT1，接收机刚刚得到包含没有media_time或event_time的触发的响应。在本地时钟时间LC2观看的帧的media_time可被ACR服务器确定为MT2，ACR服务器不知道动态激活将出现在media_timeMta，因此接收机刚刚得到包含没有media_time或event_time的触发的响应。当动态激活出现在media_timeMta时，ACR服务器无法将它通知给接收机，直至来自接收机的下一请求(这发生在本地时钟时间LC3处)。此时，ACR服务器响应可包含具有负<offset>值的激活触发，或者包含“立即行动”激活触发。以下将描述直接插入信息的水印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、MVPD28030、STB28040、接收机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。STB28040通常将音频和视频解码(解压缩)并且将它们发送给电视机以便呈现给观看者。我们假设包含交互服务触发的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)下的激活触发。这类似于图29的描述。图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)下的激活触发。这类似于图31的描述。图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)的激活触发。这类似于图33的描述。图34示出在激活时间之前至少M时间单位之后向ACR摄取模块发送动态激活触发的情况下，上述动作(4)中的情形(c)的示例。图34在时间线上面示出动态事件激活时间，在事件激活时间之前不久的时间ACR摄取模块得知事件激活，在ACR摄取模块得知事件激活的时间之后具有长度M的间隔。时间线下面的箭头示出各个帧的时间。长度M的间隔开始之前或者长度M的间隔结束之后的各个帧将在数据库中具有不带<media_time>或<event_time>项的触发。长度M的间隔内的各个帧将在数据库在中具有激活触发，例如在图下部的两个示例中的那些。各个帧的”d＝”项将指示该帧与事件激活时间之间的时间长度(由圈出的垂直箭头表示)。圈出的垂直箭头可以是典型的接收机发送请求的示例。在这种情况下，接收机将针对同一事件激活得到两个激活触发，但是通过将(负)值<d1>与帧f1的接收机的本地时间相加并且将(负)值<d2>与帧f2的接收机的本地时间相加而计算的激活时间均给出相同的结果，因此接收机将它们识别为重复的，并且仅应用它所接收的第一个。由于第一触发的激活时间在它被接收的时间之前，所以接收机将在接收到它时立即应用触发。图35示出在请求/响应ACR情况下ACR客户机与其它服务器之间的顺序图。图35示出根据实施方式的顺序图，其中在请求/响应模型中根据ACR服务器和接收机(ACR客户机)的操作协议有效地发送触发和TPT。以下将按照请求/响应的顺序描述请求/响应模型的操作的示例。在请求/响应ACR情况下ACR客户机与其它服务器之间的顺序图可包括ACR请求1s35010、ACR响应1s35020、ACR请求2s35030、ACR响应2s35040、HTTP请求1s35050、HTTP响应1s35060、HTTP请求2s35070、HTTP响应2s35080、ACR请求3s35090、ACR响应3s35100、ACR请求4s35110和ACR响应4s35120。ACR请求1s35010是在接收机处将当前观看的节目的签名发送给服务器的步骤。服务器可以是上述ACR服务器。签名可以是指纹签名或水印码。ACR响应1s35020是如果没有识别出签名或者如果相关的交互服务不存在，则在ACR服务器处返回NULL的步骤。这可等同于返回上述NULL响应的情况。ACR请求2s35030是在信道或节目已改变之后在接收机处将改变的节目的签名发送给ACR服务器的步骤。ACR响应2s35040是在ACR服务器处返回包括能够获取与节目相关的交互服务的地址的触发(例如，xbc.com/tpt504)的步骤。在这种情况下，与ACR响应1s35020不同，可识别出签名并且相关的交互服务可存在。即，触发可用。在这种情况下，返回的触发可以是没有关于media_time的信息的时基触发。HTTP请求1s35050可以是在接收机处使用http协议利用在ACR响应2s25040中接收的地址向TPT服务器(例如，http://xbc.com/tpt504等)请求TPT的步骤。HTTP响应1s35060是在TPT服务器处根据接收机的请求发送以XML表示的TPT的步骤。HTTP请求2s35070是在接收机处利用http协议向内容服务器请求诸如TDO的应用的步骤。接收机可解析包括在TPT中的TDO相关信息。TDO相关信息可以是可从其下载TDO的内容服务器的地址。可利用内容服务器的地址来发送请求。HTTP响应2s35080是在内容服务器处根据接收机发送TDO的步骤。ACR请求3s35090是在接收机处将当前观看的节目的帧的签名发送给ACR服务器的步骤。ACR响应3s35100是在ACR服务器处返回包括能够获取与节目相关的交互服务的地址的触发(例如，xbc.com/tpt504)的步骤。在这种情况下，与上述ACR响应1s35020不同，可识别出签名并且相关的交互服务可存在。即，触发可用。ACR请求4s35110是在接收机处将当前观看的节目的帧的签名发送给ACR服务器的步骤。ACR响应4s35120是在ACR服务器处发送从接收机接收的签名以及与相关的交互服务相关的激活触发的步骤。根据激活触发，可在特定时间激活特定事件。图36是在请求/响应模型中在接收机处处理交互服务的方法的实施方式。在本发明的请求/响应模型中，在一个实施方式的接收机处处理交互服务的方法包括以下步骤：接收未压缩的音频内容或未压缩的视频内容(s36010)，提取标识符(s36020)，发送包含该标识符的请求(s36030)，以及接收用于该内容的触发(s36040)。接收未压缩的音频内容或未压缩的视频内容(s36010)是在接收机处从外部解码单元接收未压缩的音频内容或未压缩的视频内容的步骤。这里，外部解码单元可以是上述STB。STB将在下面详细描述。这里，未压缩的音频内容或未压缩的视频内容可以是从上述STB(外部解码单元)发送至接收机的音频/视频内容。外部解码单元可将从MVPD接收的A/V内容解码(解压缩)，并且将解码的A/V内容发送给接收机。接收机可从外部解码单元接收未压缩的音频内容或未压缩的视频内容并将其显示给观看者。未压缩的音频内容或未压缩视频内容可根据上述ACR摄取模块的操作来处理。即，ACR摄取模块可计算帧的签名(指纹)(在指纹ACR系统的情况下)或者将由码组成的水印插入到帧中(在基于码的水印ACR系统的情况下)。这里，帧可涉及在被STB解码/解压缩之前的音频/视频内容。ACR摄取模块可将与签名或码关联的各个帧的media_time与其它元数据一起存储在数据库中。提取标识符(s36020)是在接收机处从所接收到的未压缩音频内容或未压缩视频内容的一个帧提取标识符的步骤。这里，标识符可标识所接收到的内容的帧。此标识符可以是上述概念当中的指纹签名或水印码。本实施方式不限于指纹方法或水印方法中的任一个。这里，“提取”意指从所接收到的未压缩音频内容或未压缩视频内容的一个帧提取标识符，并且可对应于上述“计算签名”、“提取水印”或者“产生签名”。“提取”可以是在上述ACR客户机中执行的操作。这仅是示例性的，本发明不限于此，设计者可设计在另一模块中执行的“提取”。ACR客户机可设置在接收机中。在提取标识符的步骤(s36020)中，提取与一个帧对应的标识符。所提取的标识符可如上所述被发送给ACR服务器等。类似于上述操作，ACR服务器可执行将所接收到的标识符与存储在数据库中的记录匹配的处理。这里，ACR服务器和数据库可分别为上述ACR服务器和数据库。存储在数据库中的记录可由ACR摄取模块预先存储。在本发明的一个实施方式中，可从所接收到的内容的帧周期性地提取(产生)标识符。在本发明的一个实施方式中，提取标识符的周期可为5秒。这可根据设计者的意图而改变。在发送包含标识符的请求的步骤(s36030)中，将包括所提取的标识符的请求发送给服务器。所提取的标识符可以是指纹签名或水印码。本实施方式不限于指纹方法或水印方法中的任一个。这里，请求可包括标识符。这里，接收机可周期性地向服务器发送请求。一个请求可包括一个标识符。周期的长度可根据设计者的意图而改变。这里，服务器可以是上述ACR服务器。服务器可接收请求并执行与数据库的匹配处理。这里，ACR服务器和数据库可分别为上述ACR服务器和数据库。存储在数据库中的记录可由ACR摄取模块预先存储。在接收用于内容的触发的步骤(s36040)中，根据发送给服务器的请求和标识符是否匹配存储在数据库中的记录或者根据是否存在与记录匹配的触发，从服务器接收触发。这里，所述触发可涉及从STB发送给接收机的内容。这里，所述内容可从上述STB接收。这里，所述触发可指示内容的当前时间并且参考应用参数表中的特定交互事件或者用信号通知事件将现在执行或在指定的未来时间执行。这里，应用参数表可包括关于至少一个应用的信息。这里，服务器可以是上述ACR服务器。数据库可以是上述数据库。这里，标识符可以是指纹签名或水印码。本实施方式不限于指纹方法或水印方法中的任一个。服务器可利用所接收到的请求/标识符执行与数据库的匹配处理。可在ACR摄取模块与存储在数据库中的记录之间执行匹配处理。如果标识符匹配数据库的标识符，则服务器可从数据库接收与其相关的记录。在这种情况下，所述记录可包括时基触发或激活触发。所包括的触发可根据先前由ACR摄取模块向记录中插入了什么而改变。当服务器从数据库接收记录时，服务器可将所获取的触发发送给接收机。在本发明的一个实施方式中，当在发送下一请求之前没有事件激活被调度发生时，所述触发是时基触发。这里，时基触发用于维持片段的时间。时基触发可遵循时基触发的上述操作。在本发明的一个实施方式中，当激活预计将发生时，所述触发是激活触发。这里，激活触发设定事件的激活时间。这里，激活时间由激活触发中的定时值项来指示。激活触发可遵循激活触发的上述操作。对应用的事件应用激活触发以在特定时间导致激活。经由事件的激活，观看者可接收交互服务。在根据本发明的实施方式的激活触发传送的情况下，在上述ACR环境下，即，只有当接收机具有互联网连接并且经由广播流访问未压缩的音频和视频时，接收机才可接收交互服务。在本发明的一个实施方式中，当接收机针对同一事件激活接收到不止一个激活触发时，激活触发被应用一次。如上所述，针对同一事件激活，接收机可接收到多个激活触发。在本发明的一个实施方式中，标识符可被周期性地提取并发送给服务器。此时，作为对周期性请求的响应，可接收到多个激活触发。如上所述，在这种情况下，由于激活触发具有相同的“t＝”项，所以接收机可确认激活触发为重复的并且仅应用一个激活触发。在本发明的一个实施方式中，当在激活时间之后接收到激活触发时，激活触发一到达就应用激活触发。此实施方式等同于上述动态激活情况。如果较晚识别出激活，使得服务器无法在激活时间之前将激活触发发送给接收机，则服务器可等待接收机的下一请求，然后发送激活触发作为对下一请求的响应。在这种情况下，激活触发可指示过去的激活时间。在这种情况下，激活触发一到达接收机就可应用激活触发。在本发明的一个实施方式中，处理交互服务的方法还可包括立即下载新应用参数表。当触发包括标识新应用参数表的应用参数表标识符时，接收机立即下载新应用参数表，除非接收机已经利用应用参数表所传送的URL信息检索到新应用参数表。如上所述，如果接收到具有新应用参数表标识符的触发，则接收机可下载新应用参数表(例如，TPT)以获得用于提供相关片段的交互服务的新信息。在本发明的一个实施方式中，可利用http协议向应用参数表服务器请求并下载新应用参数表。在本发明的一个实施方式中，应用参数表可为XML格式或二进制格式。这里，应用参数表标识符可以是上述locator_part。这里，URL信息可以是上述URLList。在本发明的一个实施方式中，处理交互服务的方法还可包括获得应用URL并下载新应用。当接收机没有与触发关联的新应用时，接收机可从应用参数表或新应用参数表获得新应用的应用URL。接收机可利用应用URL来下载新应用。接收机可解析包括在应用参数表(例如，TPT)中的应用(例如，TDO)相关信息并向服务器请求应用。该请求可使用http协议。这里，服务器可以是内容服务器。服务器可根据接收机的请求来发送应用。在本发明的一个实施方式中，所述时间可以是媒体时间，该媒体时间可以是参考内容项的播出中的点的参数。在本发明的一个实施方式中，所述应用是声明对象、触发声明对象、非实时声明对象或无约束声明对象。在本发明的一个实施方式中，除了在交换请求和响应时以外，通信会话可被关闭。在请求/响应实例之间通信会话没有保持打开。在本发明的一个实施方式中，服务器可能没有早于接收机来发送消息。对于服务器(例如，ACR服务器)而言向客户机(例如，接收机)发起消息可能不可行。在本发明的一个实施方式中，接收机可接收NULL响应(不是触发)。如果由服务器接收的标识符没有匹配数据库的标识符，则服务器可从数据库接收“无匹配”指示符。如果服务器接收到“无匹配”指示符，则服务器可向接收机返回NULL响应。本发明的一个实施方式不需要服务器的额外的智能。服务器可仅将从数据库检索到的信息发送给接收机(例如，ACR客户机)。ACR摄取模块可提供本发明的操作的所有智能。图37是示出根据本发明的实施方式的接收机的结构的示图。在本发明的实施方式中，接收机可包括天线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文件内容以获得TDOURL。另外，触发模块rcvr1060可解析AMT以处理数据。可通过解析获得其它信息。在接收到AMT消息之后，根据预定时间和操作传送与网络浏览器对应的TDOURL，或者可在预定时间停止当前操作的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)光远程传送信息。图38是示出在机顶盒经由高清晰多媒体接口(HDMI)或外部接口接收广播的情况下根据本发明的实施方式的接收机的结构的示图。在图38所示的本发明的实施方式中，接收机可包括天线rcvr2010、调谐器rcvr2020、机顶盒rcvr2030、VSB或DVB解调器rcvr2040、HDMIRCVR2050、MPEG-2TS系统解码器rcvr2060、字幕模块rcvr2070、触发模块rcvr2080、网络浏览器rcvr2090、网络协议栈rcvr2100、网络接口rcvr2110、UI模块rcvr2120、ACR模块rcvr2130、音频解码器rcvr2140、视频解码器rcvr2150、扬声器rcvr2160、显示模块rcvr2170、图形处理器rcvr2180、遥控器接收器rcvr2190和遥控器rcvr2200。在这种情况下，由于广播流的视频和音频是原始数据，所以可能没有接收包括在字幕流中的触发。本发明的细节将在下面描述。这里，除机顶盒rcvr2030、HDMIrcvr2050和ACR模块rcvr2130以外的模块在角色方面类似于图37的实施方式中所描述的模块。现在将描述机顶盒rcvr2030、HDMIrcvr2050和ACR模块rcvr2130。机顶盒rcvr2030可将通过数字网络从视频服务器接收的压缩信号恢复为原始视频和音频信号。TV可以是互联网用户接口。HDMIrcvr2050可以是高清晰多媒体接口(非压缩数字视频/音频接口标准)。HDMIrcvr2050可在机顶盒rcvr2030与AV设备(即，音频解码器rcvr2140和视频解码器rcvr2150)之间提供接口。ACR模块rcvr2130可自动识别来自音频解码器rcvr2140和视频解码器rcvr2150的广播内容。基于当前识别的内容，可经由触发模块rcvr2080和网络接口rcvr2110将查询发送给ACR服务器以接收用于触发的TPT/AMT。图39是示出在请求/响应模型中处理交互服务的设备的实施方式的示图。在根据本发明的请求/响应模型中，处理交互服务的设备的实施方式可包括接收模块39010、标识符提取模块39020和网络接口39030。接收模块39010可从外部解码单元接收未压缩的音频内容或未压缩的视频内容。这里，外部解码单元可以是上述STB。这里，未压缩的音频内容或未压缩的视频内容可以是从上述STB(外部解码单元)发送至接收机的音频/视频内容。这里，接收模块39010可对应于图38的HDMI。接收模块39010可以是图37或图38中未示出的另一模块。这可根据设计者的意图而改变。外部解码单元可将从MVPD接收的A/V内容解码(解压缩)，并且将解码的A/V内容发送给接收模块39010。未压缩的音频内容或未压缩的视频内容可通过上述ACR摄取模块来处理。即，ACR摄取模块可计算帧的签名(指纹)(在指纹ACR系统的情况下)或者将由码组成的水印插入帧中(在基于码的水印ACR系统的情况下)。这里，所述帧可涉及在被STB解码/解压缩之前的音频/视频内容。ACR摄取模块可将与签名或码关联的各个帧的media_time与其它元数据一起存储在数据库中。标识符提取模块39020从通过接收模块39010接收的未压缩音频内容或未压缩视频内容的一个帧提取标识符。这里，标识符可标识所接收到的内容的帧。此标识符可以是指纹签名或水印码。本实施方式不限于指纹方法或水印方法中的任一个。这里，“提取”意指从接收的未压缩音频内容或未压缩视频内容的一个帧提取标识符，并且可对应于上述“计算签名”、“提取水印”或者“产生签名”。标识符提取模块39020提取与一个帧对应的标识符。所提取的标识符可如上所述被发送给ACR服务器。类似于上述操作，ACR服务器可将所接收到的标识符与数据库的记录进行匹配。这里，ACR服务器和数据库可分别为上述ACR服务器和数据库。存储在数据库中的记录可由ACR摄取模块预先存储。这里，标识符提取模块39020可对应于图38的ACR模块。标识符提取模块39020可以是图37或图38中未示出的另一模块。这可根据设计者的意图而改变。在本发明的一个实施方式中，可从所接收到的内容的帧周期性地提取(产生)标识符。在本发明的一个实施方式中，提取标识符的周期可为5秒。这可根据设计者的意图而改变。网络接口39030可将包括所提取的标识符的请求发送给服务器，并且从服务器接收与内容相关的触发。这里，可基于所述请求来接收所述触发。这里，网络接口39030可对应于图38的网络接口。另选地，网络接口39030可以是图37或图38中未示出的另一模块。这可根据设计者的意图而改变。这里，所提取的标识符可以是上述概念当中的指纹签名或水印码。本实施方式不限于指纹方法或水印方法中的任一个。这里，请求可包括标识符。这里，网络接口39030可周期性地向服务器发送请求。一个请求可包括一个标识符。周期的长度可根据设计者的意图而改变。这里，服务器可以是上述ACR服务器。服务器可接收请求并执行与数据库的匹配处理。这里，ACR服务器和数据库可分别为上述ACR服务器和数据库。存储在数据库中的记录可由ACR摄取模块预先存储。这里，所述触发可涉及由接收模块39010从STB接收的内容。这里，所述内容可从上述STB接收。这里，所述触发可指示内容的当前时间并且参考应用参数表中的特定交互事件或者用信号通知事件将现在执行或在指定的未来时间执行。这里，应用参数表可包括关于至少一个应用的信息。这里，服务器可以是上述ACR服务器。数据库可以是上述数据库。这里，标识符可以是指纹签名或水印码。本实施方式不限于指纹方法或水印方法中的任一个。服务器可利用所接收到的请求/标识符执行与数据库的匹配处理。可在ACR摄取模块与存储在数据库中的记录之间执行匹配处理。如果标识符匹配数据库的标识符，则服务器可从数据库接收与其相关的记录。在这种情况下，所述记录可包括时基触发或激活触发。所包括的触发可根据先前由ACR摄取模块向记录中插入了什么而改变。当服务器从数据库接收记录时，服务器可将所获取的触发发送给网络接口39030。在本发明的一个实施方式中，当在发送下一请求之前没有事件激活被调度发生时，所述触发是时基触发。这里，时基触发用于维持片段的时间。时基触发可遵循时基触发的上述操作。在本发明的一个实施方式中，当激活预计将发生时，所述触发是激活触发。这里，激活触发设定事件的激活时间。这里，激活时间由激活触发中的定时值项来指示。激活触发可遵循激活触发的上述操作。对应用的事件应用激活触发以在特定时间导致激活。经由事件的激活，观看者可接收交互服务。在根据本发明的实施方式的激活触发传送的情况下，在上述ACR环境下，即，只有当接收机具有互联网连接并且经由广播流访问未压缩的音频和视频时，接收机才可接收交互服务。在本发明的一个实施方式中，当接收机针对同一事件激活接收到不止一个激活触发时，激活触发被应用一次。如上所述，针对同一事件激活，设备可接收到多个激活触发。在本发明的一个实施方式中，标识符可被周期性地提取并发送给服务器。此时，作为对周期性请求的响应，可接收到多个激活触发。如上所述，在这种情况下，由于激活触发具有相同的“t＝”项，所以设备可确认激活触发为重复的并且仅应用一个激活触发。在本发明的一个实施方式中，当在激活时间之后接收到激活触发时，激活触发一到达就应用激活触发。此实施方式等同于上述动态激活情况。如果较晚识别出激活，使得服务器无法在激活时间之前将激活触发发送给设备，则服务器可等待设备的下一请求，然后发送激活触发作为对下一请求的响应。在这种情况下，激活触发可指示过去的激活时间。在这种情况下，激活触发一到达设备就可应用激活触发。在本发明的一个实施方式中，网络接口39030还被配置为当触发包括标识新应用参数表的应用参数表标识符时，立即下载新应用参数表，除非设备已经利用应用参数表所传送的URL信息检索到新应用参数表。如上所述，如果接收到具有新应用参数表标识符的触发，则设备可下载新应用参数表(例如，TPT)以获得用于提供相关片段的交互服务的新信息。在本发明的一个实施方式中，可利用http协议向应用参数表服务器请求并下载新应用参数表。在本发明的一个实施方式中，应用参数表可为XML格式或二进制格式。这里，应用参数表标识符可以是上述locator_part。这里，URL信息可以是上述URLList。在本发明的一个实施方式中，所述设备还包括触发模块，该触发模块被配置为当设备没有新应用时，从应用参数表或新应用参数表获得与触发关联的新应用的应用URL，其中，所述网络接口还被配置为利用应用URL来下载新应用。这里，所述设备可解析包括在应用参数表(例如，TPT)中的应用(例如，TDO)相关信息并向服务器请求应用。该请求可使用http协议。这里，服务器可以是内容服务器。服务器可根据接收机的请求来发送应用。在本发明的一个实施方式中，所述时间可以是媒体时间，该媒体时间可以是参考内容项的播出中的点的参数。在本发明的一个实施方式中，所述应用是声明对象、触发声明对象、非实时声明对象或无约束声明对象。在本发明的一个实施方式中，除了在交换请求和响应时以外，通信会话可被关闭。在请求/响应实例之间通信会话没有保持打开。在本发明的一个实施方式中，服务器可能没有早于接收机来发送消息。对于服务器(例如，ACR服务器)而言向客户机(例如，设备)发起消息可能不可行。在本发明的一个实施方式中，网络接口39030可接收NULL响应(不是触发)。如果由服务器接收的标识符没有匹配数据库的标识符，则服务器可从数据库接收“无匹配”指示符。如果服务器接收到“无匹配”指示符，则服务器可向网络接口39030返回NULL响应。本发明的一个实施方式不需要服务器的额外的智能。服务器可仅将数据库的信息发送给网络接口39030。ACR摄取模块可提供本发明的操作的所有智能。尽管为了清晰而参照各个附图说明了本发明的描述，可通过将附图中所示的实施方式彼此合并来设计新的实施方式。另外，如果本领域技术人员需要设计记录有用于执行以上描述中所提及的实施方式的程序的可由计算机读取的记录介质，则它可属于所附权利要求及其等同物的范围。根据本发明的设备和方法可不受以上描述中提及的实施方式的配置和方法的限制。并且，以上描述中提及的实施方式可按照完整地或部分地彼此选择性地组合的方式来配置，以允许各种修改。另外，根据本发明的处理与广播节目相关的交互服务的方法可利用提供给网络装置的处理器可读记录介质中的处理器可读代码来实现。处理器可读介质可包括能够存储可由处理器读取的数据的所有类型的记录装置。处理器可读介质可包括例如ROM、RAM、CD-ROM、磁带、软盘、光学数据存储装置等中的一个，并且还包括诸如经由互联网的传输的载波型实现方式。另外，当处理器可读记录介质被分布于经由网络连接的计算机系统时，计算机可读代码可根据分布式系统来保存和执行。本领域技术人员将理解，在不脱离本发明的精神或范围的情况下可对本发明进行各种修改和变化。因此，本发明旨在涵盖本发明的这些修改和变化，只要它们落入所附权利要求及其等同物的范围内。本说明书中提及了设备和方法发明二者，设备和方法发明二者的描述可彼此互补地应用。本发明的模式在具体实施方式中描述了各种实施方式。工业实用性本发明可用在一系列广播服务提供领域中。对于本领域技术人员而言将显而易见，在不脱离本发明的精神或范围的情况下可对本发明进行各种修改和变化。因此，本发明旨在涵盖本发明的这些修改和变化，只要它们落入所附权利要求及其等同物的范围内。当前第1页1 2 3 当前第1页1 2 3