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

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

Info

Publication number
CN104871552B
CN104871552B CN201380062174.4A CN201380062174A CN104871552B CN 104871552 B CN104871552 B CN 104871552B CN 201380062174 A CN201380062174 A CN 201380062174A CN 104871552 B CN104871552 B CN 104871552B
Authority
CN
China
Prior art keywords
application
receiver
event
triggering
service
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
CN201380062174.4A
Other languages
English (en)
Other versions
CN104871552A (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 CN104871552A publication Critical patent/CN104871552A/zh
Application granted granted Critical
Publication of CN104871552B publication Critical patent/CN104871552B/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/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/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/41—Structure of client; Structure of client peripherals
    • H04N21/4104—Peripherals receiving signals from specially adapted client devices
    • H04N21/4122—Peripherals receiving signals from specially adapted client devices additional display device, e.g. video projector
    • 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/41—Structure of client; Structure of client peripherals
    • H04N21/4104—Peripherals receiving signals from specially adapted client devices
    • H04N21/4126—The peripheral being portable, e.g. PDAs or mobile phones
    • H04N21/41265—The peripheral being portable, e.g. PDAs or mobile phones having a remote control device for bidirectional communication between the remote control device and client device
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/436—Interfacing a local distribution network, e.g. communicating with another STB or one or more peripheral devices inside the home
    • H04N21/43615—Interfacing a Home Network, e.g. for connecting the client to a plurality of peripherals
    • 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/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/8166—Monomedia components thereof involving executable data, e.g. software
    • H04N21/8173—End-user applications, e.g. Web browser, game
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/83—Generation or processing of protective or descriptive data associated with content; Content structuring
    • H04N21/845—Structuring of content, e.g. decomposing content into time segments
    • H04N21/8456—Structuring of content, e.g. decomposing content into time segments by decomposing the content in the time domain, e.g. in time segments
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/85—Assembly of content; Generation of multimedia applications
    • H04N21/858—Linking data to content, e.g. by linking an URL to a video object, by creating a hotspot
    • H04N21/8586—Linking data to content, e.g. by linking an URL to a video object, by creating a hotspot by using a URL

Landscapes

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

Abstract

公开了一种处理数字服务信号的方法及其设备。本发明包括：执行用于所述数字服务信号的主应用，其中，所述主应用是触发应用或非触发应用；发送针对与所述主应用关联的副应用的交互服务的消息，其中，所述交互服务包括与所述触发应用有关的第一模式或者与所述非触发应用有关的第二模式；接收针对标识所述交互服务的描述的请求；发送所述描述，所述描述具有标识各个所述交互服务的服务id信息以及指示各个所述交互服务的类型的服务类型信息；以及通过发送用于所述交互服务的信息来提供所述交互服务。

Description

处理交互服务的设备和方法
技术领域
本发明涉及用于提供、接收和处理广播服务的方法和设备，更具体地讲，涉及一种用于提供与广播内容相关的补充服务的方法和设备。
背景技术
TV首次出现于19世纪末，并且自20世纪末以来随着其屏幕显示方法或设计不断发展，已成为最普及的信息传送设备。然而，TV通常使得观看者能够从广播台接收单向信息。随着自20世纪90年代以来个人计算机(PC)和互联网得到广泛使用，TV的这些局限已成为问题。因此，TV已发展为能够提供交互服务。
然而，目前，没有用于在内容提供商与观看者之间提供交互服务的系统。具体地讲，为了提供这种交互服务，需要一种在特定时间执行与当前广播的广播内容相关的应用并且通过特殊信息处理将相关信息提供给观看者的方法。
发明内容
技术问题
为解决所述问题而设计出的本发明的目的在于在广播内容被回放的时间段期间的适当时间与广播内容相关的补充信息。
技术方案
本发明的目的可通过提供一种处理数字服务信号的方法来实现，该方法包括以下步骤：执行用于所述数字服务信号的主应用，其中，所述主应用是触发应用或非触发应用；发送用于与所述主应用关联的副应用的交互服务的消息，其中，所述交互服务包括与所述触发应用有关的第一模式或者与所述非触发应用有关的第二模式；接收针对标识所述交互服务的描述的请求；发送所述描述，所述描述具有标识各个所述交互服务的服务id信息以及指示各个所述交互服务的类型的服务类型信息；以及通过发送用于所述交互服务的信息来提供所述交互服务。
优选地，用于所述交互服务的所述信息根据各个所述交互服务来定义，并且用于所述交互服务的所述信息是触发、字节和URL信息中的一个。
优选地，当用于所述交互服务的所述信息是触发时，所述触发中的至少一个包括信道改变信息，所述信道改变信息具有用于指示所述数字服务信号的改变的信道号的值。
优选地，当用于所述交互服务的所述信息是触发时，所述方法还包括以下步骤：通过与TPT中的信息组合来增强所述触发，其中，所述TPT包含关于所述触发应用的元数据；以及发送增强触发，所述增强触发具有指示所述触发中标识的事件的事件指示符。
优选地，用于所述交互服务的所述信息是字节，所述交互服务包括指示所述应用是否被执行并准备参与与所述副应用的通信的status状态变量，所述方法还包括设定所述status状态变量。
优选地，所述主应用使用API来提供交互服务。
优选地，所述API包括具有关于用于所述字节的地址和端口的信息的address参数(argument)以及bytes参数。
优选地，该方法还包括以下步骤：在所述发送消息的步骤之前，接收针对与所述主应用关联的所述副应用的交互服务的所述消息的请求。
在本发明的另一方面中，本文提供了一种处理数字服务信号的方法，该方法包括以下步骤：执行用于所述数字服务信号的应用；接收用于所执行的应用的交互服务的消息；发送针对标识所述交互服务的描述的请求；接收所述描述，所述描述具有标识各个所述交互服务的服务id信息以及指示各个所述交互服务的类型的服务类型信息；利用所述描述访问至少一个交互服务，其中，所述访问步骤还包括订用用于所述至少一个交互服务的通知的协议，接收所述通知，以及利用所接收到的通知来接收用于所述至少一个交互服务的信息；以及下载用于所访问的交互服务的文件。
优选地，用于所述至少一个交互服务的所述信息根据所述交互服务来定义，并且用于所述至少一个交互服务的所述信息是触发、字节和URL信息中的一个。
优选地，当用于所发现的交互服务的所述信息是触发时，其中，所述触发中的至少一个包括信道改变信息，所述信道改变信息具有用于指示所述数字服务信号的改变的信道号的值。
优选地，当用于所访问的交互服务的所述信息是字节时，所述方法还包括以下步骤：利用所接收到的通知来确定所述交互服务是否准备开始；以及利用所接收到的通知来发送针对用于发送所述字节的连接的请求。
优选地，该方法还包括以下步骤：在所述接收消息的步骤之前，发送针对所执行的应用的交互服务的所述消息的请求。
在本发明的另一方面中，本文提供了一种用于处理数字服务信号的设备，该设备包括：执行模块，其被配置为执行用于所述数字服务信号的主应用，其中，所述主应用是触发应用或非触发应用；发送模块，其被配置为发送用于与所述主应用关联的副应用的交互服务的消息以及标识所述交互服务的描述，其中，所述交互服务包括与所述触发应用有关的第一模式或者与所述非触发应用有关的第二模式，其中，所述描述根据请求来发送；接收模块，其被配置为接收针对所述描述的请求，所述描述具有标识各个所述交互服务的服务id信息以及指示各个所述交互服务的类型的服务类型信息；以及提供模块，其被配置为通过发送用于所述交互服务的信息来提供所述交互服务。
优选地，用于所述交互服务的所述信息根据各个所述交互服务来定义，并且用于所述交互服务的所述信息是触发、字节和URL信息中的一个。
优选地，当用于所述交互服务的所述信息是触发时，所述触发中的至少一个包括信道改变信息，所述信道改变信息具有用于指示所述数字服务信号的改变的信道号的值。
优选地，当用于所述交互服务的所述信息是触发时，所述设备还包括增强模块，该增强模块被配置为通过与TPT中的信息组合来增强所述触发，其中，所述TPT包含关于所述触发应用的元数据，其中，所述发送模块还发送增强触发，所述增强触发具有指示所述触发中标识的事件的事件指示符。
优选地，用于所述交互服务的所述信息是字节，所述交互服务包括指示所述应用是否被执行并准备参与与所述副应用的通信的status状态变量，所述方法还包括设定所述status状态变量。
优选地，所述主应用使用API来提供交互服务。
优选地，所述API包括具有关于用于所述字节的地址和端口的信息的address参数以及bytes参数。
优选地，所述接收模块还被配置为在所述发送模块发送所述消息之前，接收针对与所述主应用关联的所述副应用的交互服务的所述消息的请求。
在本发明的另一方面中，本文提供了一种用于处理数字服务信号的设备，该设备包括：执行模块，其被配置为执行用于所述数字服务信号的应用；接收模块，其被配置为接收用于所执行的应用的交互服务的消息以及描述；发送模块，其被配置为发送针对标识所述交互服务的描述的请求，其中，所述描述具有标识各个所述交互服务的服务id信息以及指示各个所述交互服务的类型的服务类型信息；访问模块，其被配置为利用所述描述访问至少一个交互服务，其中，所述访问模块还订用用于所述至少一个交互服务的通知的协议，接收所述通知，并且利用所接收到的通知来接收用于所述至少一个交互服务的信息；以及下载模块，其被配置为下载用于所访问的交互服务的文件。
优选地，用于所述至少一个交互服务的所述信息根据所述交互服务来定义，并且用于所述至少一个交互服务的所述信息是触发、字节和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是示出UPnP RemoteUI客户机服务的动作列表的实施方式的示图；
图40是示出UPnP RemoteUI客户机服务的实施方式的示图；
图41是示出DTVCC服务编号6中的触发的实施方式的示图；
图42是示出用于第二屏幕情景的系统架构的实施方式的示图；
图43是示出ATSC 2.0接收机与第二屏幕之间的拓扑(直接连接)的实施方式的示图；
图44是示出ATSC 2.0接收机与第二屏幕之间的拓扑(间接连接)的实施方式的示图；
图45是示出第二屏幕服务应用的软件层的实施方式的示图；
图46是示出第二屏幕服务应用的软件层的示图；
图47是示出根据第二屏幕应用生命周期管理的传输顺序与传输的数据之间的差异的表的示图；
图48是示出集中执行模型的操作概念的示图；
图49是示出基于集中执行模型的接收机与第二屏幕之间的协作的流程的示图；
图50是示出在接收机处向第二屏幕装置通知UI信息的方法的实施方式的示图；
图51是示出在接收机处向第二屏幕装置通知UI信息的方法的实施方式的示图；
图52是示出RemoteUI服务器服务的广播信令的实施方式的示图；
图53是示出分布执行模型的操作概念的示图；
图54是示出基于分布执行模型的接收机与第二屏幕之间的协作的流程的示图；
图55是示出基于分布执行模型的接收机与第二屏幕之间的协作的流程的示图；
图56是示出在接收机处向第二屏幕装置通知TDO和Event信息的方法的实施方式的示图；
图57是示出在第二屏幕装置处访问TPT和第二屏幕应用的方法的实施方式的示图；
图58是示出在第二屏幕装置处访问TPT和第二屏幕应用的方法的实施方式的示图；
图59是示出RemoteUI服务器服务的广播信令的另一实施方式的示图；
图60是示出第二屏幕服务的装置发现和装置能力交换的实施方式的示图；
图61是示出UPnP论坛的DeviceProfile XML模式(XML schema)的实施方式的示图；
图62是示出第二屏幕装置的装置配置文件的实施方式的示图；
图63是示出第二屏幕服务的Protocolnfo的描述的实施方式的示图；
图64是示出在第二屏幕装置中正执行AddUIListing和RemoteUIListing动作时的UIListing的实施方式的示图；
图65是示出RemoteUI客户机服务的单播信令的实施方式的示图；
图66是示出RemoteUI客户机服务的单播信令的实施方式的示图；
图67是示出RemoteUI客户机服务的单播信令的实施方式的示图；
图68是示出通过ProcessInput动作传送给第二屏幕装置的“EventInfo”信息的实施方式的示图；
图69是示出接收机与第二屏幕装置之间的配置的示图；
图70是示出服务的服务类型和服务ID的实施方式的示图；
图71是示出触发传送服务的操作概念的示图；
图72是示出生成扩展激活触发的处理的实施方式的示图；
图73是示出增强激活触发的XML模式描述的实施方式的示图；
图74是示出URI_data()的句法的实施方式的示图；
图75是示出URI_type的含义的实施方式的示图；
图76是示出未增强的触发的XML模式描述的实施方式的示图；
图77是示出增强激活触发的格式的实施方式的示图；
图78是示出增强激活触发的格式的实施方式的示图；
图79是示出增强激活触发的格式的实施方式的示图；
图80是示出增强激活触发的格式的实施方式的示图；
图81是示出根据基于HTTP长轮询的方法的触发服务状态变量的实施方式的示图；
图82是示出根据基于HTTP长轮询的方法的触发服务动作的实施方式的示图；
图83是示出根据基于HTTP长轮询的方法的GetTrigServerURL动作的参数的实施方式的示图；
图84是示出触发服务状态变量的实施方式的示图；
图85是示出触发服务动作的实施方式的示图；
图86是示出GetLatestUnfilteredTrigger动作的参数的实施方式的示图；
图87是示出GetLatestFilteredTrigger动作的参数的实施方式的示图；
图88是示出基于UPnP事件触发机制的方法的实施方式的示图；
图89是示出触发服务状态变量的实施方式的示图；
图90是示出触发服务动作的实施方式的示图；
图91是示出当经由触发传送服务获取触发时第二屏幕上的操作的实施方式的示图；
图92是示出触发传送服务的操作概念的示图；
图93是示出根据第一方法的双向通信服务状态变量的实施方式的示图；
图94是示出根据第一方法的ClientList状态变量的XML模式表的实施方式的示图；
图95是示出根据第一方法触发服务动作的实施方式的示图；
图96是示出根据第一方法的SignUp动作的参数的实施方式的示图；
图97是示出根据第一方法的SignOff动作的参数的实施方式的示图；
图98是示出根据第二方法的双向通信服务状态变量的实施方式的示图；
图99是示出根据第二方法的onBytesReceived函数的实施方式的示图；
图100是示出根据第二方法的setStatusYes()的实施方式的示图；
图101是示出根据第二方法的setStatusNo()的实施方式的示图；
图102是示出根据第二方法的setStatus()的实施方式的示图；
图103是示出根据第二方法的sendBytes()的实施方式的示图；
图104是示出AppURL服务状态变量的示图；
图105是示出AppURL服务动作的示图；
图106是示出GetAppURL动作的参数的示图；
图107是示出代理HTTP服务器服务的操作概念的示图；
图108是示出代理服务器服务状态变量的实施方式的示图；
图109是示出代理服务器服务动作的实施方式的示图；
图110是示出GetProxyURL动作的参数的实施方式的示图；
图111是示出RequestFiles()的实施方式的示图；
图112是示出第二屏幕装置架构的实施方式的示图；
图113是示出接收机的简化结构的实施方式的示图；
图114是示出第二屏幕装置的结构的实施方式的示图；
图115是示出第二屏幕服务情景的示图；
图116是示出在主装置中处理数字服务信号的方法的实施方式的示图；
图117是示出在副应用中处理数字服务信号的方法的实施方式的示图；
图118是示出作为主装置处理数字服务信号的设备的实施方式的示图；以及
图119是示出作为副应用处理数字服务信号的设备的实施方式的示图。
具体实施方式
尽管本发明中使用的术语选自通常所知并使用的术语，但本文使用的术语可根据运营商的意图或者本领域的惯例、新技术的出现等而变化。另外，本发明的描述中提及的一些术语由申请人酌情选择，其详细含义在本文描述的相关部分中进行描述。另外，本发明不能简单地通过实际使用的术语来理解，而是需要通过各个术语的内部含义来理解。
在本说明书中，术语媒体时间代表参考音频/视频或音频内容项的播出中的点的参数。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。通过<domainname 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(S38030)、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是示出UPnP RemoteUI客户机服务的动作列表的实施方式的示图。
第二屏幕支持涉及一种在接收机处将广播商的服务或者适合于广播商所提供的节目的补充服务提供给第二屏幕装置的方法。补充内容可经由应用来提供，所述应用可显示在TV屏幕上，使得用户通过操纵遥控器来使用所述补充内容。然而，近来，经由个性化信息设备(智能电话、智能板以及小型化膝上型计算机)，在显示TV屏幕上回放的内容的同时可在第二屏幕装置上显示补充服务。因此，用户可在不中断广播内容的情况下个人地使用补充服务。如果在第二屏幕装置上显示并处理这些补充数据或信息，则当多个人一起观看TV时，仅对补充服务感兴趣的人可获得补充内容，而不会中断其他人的TV观看。除了上述效果以外，还可各种各样地使用第二屏幕支持。
为了一个装置与其它装置的连接和控制，首先应该确定家庭网络中包括哪些装置。因此，一个或更多个装置周期性地向家庭网络发送消息以通知装置存在于家庭网络中。如果一个装置新连接到家庭网络，则在通知该装置新连接之前，该装置可询问哪些装置存在于家庭网络中。这种连接方法可帮助容易且快速地识别装置的存在。UPnP装置发现是实现此的一种方法。如果检测到装置，则对检测到的装置感兴趣的其它装置可能需要关于可向该装置提供哪些服务的信息。安装有UPnP框架的电子设备可确认相互功能和支持的功能范围。此信息可被定义于UPnP装置配置文件中，使得装置确认相互提供的服务的属性。可一直等待提供特定服务的装置。如果检测到提供特定服务的装置，则可询问检测到的装置中包括哪些服务。如果检测到的装置中存在期望的服务，则检测到的装置可被立即连接以执行通信。如UPnP服务描述符中所定义的，可限定并交换服务。
由于一个装置具有单个服务或多个服务，所述服务可由其它装置控制和使用。如果装置具有一个或更多个功能，则包括与所述功能对应的多个服务并由其它装置控制。装置的定义可具有关于该装置的唯一信息。例如，关于装置的唯一信息可包括诸如型号名称、序列号、型号、CE制造商名称和网站的信息。此信息可针对各个装置具有唯一值，并且可一般不改变。服务是由装置执行的操作(被称作动作)，各个装置可具有一个或更多个动作。动作具有诸如函数的参数值，并且可具有一个或更多个参数值。动作由装置的服务执行，在执行动作之后可返回根据需要定义的返回值。
作为动作的示例，图39示出UPnP RemoteUI客户机服务的动作的类型及其描述。Connection/disconnection可以是返回当前连接状态的动作。GetCurrentConnection可以是返回当前连接列表的动作。GetDeviceProfile可以是返回以XML表达的装置配置文件的动作。GetUIListing可以是返回以XML表达的可兼容UI列表的动作。AddUIListing/RemoveUIListing可以是将远程UI的URL添加到UI列表或者将远程UI的URL从UI列表去除的动作。ProcessInput可以是将数据发送给RemoteUI客户机服务的动作。DisplayMessage可以是在包括RemoteUI客户机服务的装置上显示消息的动作。
图40是示出UPnP RemoteUI客户机服务的实施方式的示图。
在UPnP中，可使用诸如SOAP的XML消息格式来发送上述动作和必要参数值，并且可使用SOAP来远程地执行远程过程。这些消息可利用HTTP来发送。
上述RemoteUI客户机的动作可如图40所示执行。图40所示的动作仅是上述动作的示例。
UPnP RemoteUI客户机服务的一个实施方式可分成UPnP发现处理和RemoteUI客户机动作。
UPnP发现处理可包括执行用于第二屏幕服务的UPnP应用(s40001)、寻找UPnP装置(s40010)、寻找RemoteUIClient(s40020)、请求装置描述(s40030)、接收装置描述(s40040)、请求服务控制描述(s40050)和/或接收服务控制描述(s40060)。
RemoteUI客户机动作可包括请求装置配置文件(s40070)、接收装置配置文件(s40080)、放置远程UI的URL(s40090)、发送响应1(s40100)、向RemoteUI客户机服务发送消息(s40110)、发送响应2(s40120)和/或用户点击屏幕上的按钮(s40130)。
执行用于第二屏幕服务的UPnP应用(s40001)可包括在第二屏幕装置(RemoteUI客户机)中执行UPnP应用。
寻找UPnP装置(s40010)可包括主装置向在第二屏幕装置中执行的应用多播发现消息。通过此步骤，可找到网络中的第二屏幕装置。主装置可经由发现消息来指示由此提供的第二屏幕支持服务。
寻找RemoteUIClient(s40020)可包括第二屏幕装置接收发现消息并且向主装置发送通知消息。
请求装置描述(s40030)可包括主装置向第二屏幕装置请求第二屏幕装置的装置描述。
接收装置描述(s40040)可包括当第二屏幕装置响应于装置描述的请求发送第二屏幕装置的装置配置文件时，主装置接收第二屏幕装置的装置配置文件(s40030)。
请求服务控制描述(s40050)可包括主装置向第二屏幕装置请求服务控制描述。
接收服务控制描述(s40060)可包括主装置从第二屏幕装置接收所请求的服务控制描述。
存在于网络上的主装置和第二屏幕装置可经由UPnP发现处理来寻找并识别彼此。另外，主装置和第二屏幕装置可彼此连接。
请求装置配置文件(s40070)可包括请求第二屏幕装置的装置配置文件。可使用上述GetDeviceProfile动作。
接收装置配置文件(s4008)可包括主装置接收所请求的第二屏幕装置的装置配置文件。具有“RemoteUI客户机服务”的装置(第二屏幕装置和RemoteUI客户机)可负责在远程装置(主装置)发送UI的URL地址的情况下寻找并在屏幕上显示UI的URL地址。另外，具有“RemoteUI服务器服务”的装置可多播UI的URL地址以将URL地址通知给感兴趣的装置。然而，在这种情况下，由于远程UI用于特定装置，所以应该提供适合于特定装置的远程UI。因此，还需要发送装置配置文件信息，并且请求装置配置文件(s40070)和接收装置配置文件(s40080)可为必要的。
放置远程UI的URL(s40090)可包括向第二屏幕装置通知远程UI的URL地址。可使用上述AddUIListing动作。第二屏幕装置可将远程UI的URL地址添加到UIListing。
发送响应(s40100)可包括发送放置远程UI的URL的结果(s40090)。根据情况，可发送诸如HTTP/1.1 200 OK(请求被成功处理)、HTTP/1.1 501 Method Not Implemented(处理请求所需的功能没有被实现)和HTTP/1.1 400 Not Found(请求的文件/资源不存在)的响应。
向RemoteUI客户机服务发送消息(s40110)可包括主装置向第二屏幕装置发送显示消息。显示消息可包括诸如消息类型的信息。可使用上述DispalyMessage动作。第二屏幕装置可根据显示消息在第二屏幕上显示消息。
发送响应2(s40120)可包括发送向RemoteUI客户机服务发送消息的结果(s40110)。类似于发送响应1(s40100)，可发送诸如HTTP/1.1 200 OK的响应。
用户点击屏幕上的按钮(s40130)可包括用户根据显示在第二屏幕上的消息来执行选择。
RemoteUI客户机动作描述了经由上述动作操作RemoteUI客户机服务的处理。
在远程用户接口的描述中，现有PC系统中可使用的功能可考虑电子设备的资源来简化，其功能被增加或限制以使得电子设备中可使用基于HTML的应用。该描述大体包括两个角度：将显示在屏幕上的HTML应用于消费电子产品以及定义适用于消费电子产品的浏览器API。可从作为广泛使用的脚本语言的JavaScript调用并使用浏览器API。结果，从JavaScript调用的API调用接收机的功能。
除了别的以外，上述UPnP装置和服务可通过在浏览器中执行的JavaScript来执行。需要新的API来将其它参数传送给浏览器中的UPnP装置。
图41是示出DTVCC服务编号6中的触发的实施方式的示图。
如上所述，上述触发可利用数字TV隐藏字幕服务(DTVCC)来发送。触发可具有一个URL字符串值，并且可作为DTVCC服务系列#6被接收。MPEG-2传输处理器41010可接收作为DTVCC服务系列#6的触发并且经由传输处理器驱动器41020将该触发发送给DTV-CC模块41040。此时，用户数据可经过缓冲器41030。DTV-CC模块41040可用作DTVCC解码器。DTV-CC模块41040可将具有URI字符串值的触发发送给附属服务模块41050。附属服务模块41050是触发模块，其可检测URI字符串值以获取上述TPT(TDO参数表)。如上所述，可利用触发、TPT和TDO来提供附属服务。
图42是示出用于第二屏幕情景的系统架构的实施方式的示图。
为了第二屏幕支持，可能有多个要求。1)接收机可连接到一个或更多个第二屏幕装置。2)第二屏幕装置可以是诸如膝上型计算机、平板、智能电话或PDA的便携式装置。3)第二屏幕的主内容可以是HTML、文本、视频、音频等。4)在第二屏幕上回放的内容可被设计为不中断主装置(接收机)的广播节目。5)第二屏幕可直接或者经由3GPP网络间接连接到ATSC2.0接收机。6)提供商可用信号通知特定内容仅被显示在第二屏幕上。7)根据情况，由接收机回放的内容可被设计用于由第二屏幕回放。8)经受验证和授权的第二屏幕可使用第二屏幕服务。9)可测量第二屏幕内容的受众使用。(在这种情况下，为了获得这些信息，必需获得用户同意，并且用于这些信息的功能可为必要的)并且10)这可经由能够增强副语言或内容的装置来提供。
本说明书可描述可由接收器提供以支持通过在第二屏幕装置(智能电话、平板、膝上型计算机等)上运行的应用来显示与A/V广播有关的内容(包括与广播的节目同步的内容)的服务。所述服务可基于UPnP装置架构来描述。
在本说明书中，ATSC 2.0接收机可以是TV接收机或普通接收机。另外，ATSC 2.0接收机可以是DVB、ATSC等的接收机。
UPnP装置架构定义了在提供服务的“受控装置”与利用那些服务的“控制点”之间的IP网络中的通信协议。在“第二屏幕”情景中，TV接收机可扮演“受控装置”的角色，第二屏幕装置可扮演“控制点”的角色，反之亦然。
UPnP装置架构规定了控制点发现感兴趣的受控装置的“发现”协议、控制点获悉关于受控装置和服务的细节的“描述”协议、控制点调用受控装置上的“动作”(方法)的“控制”协议、以及受控装置将异步通知传送给控制点的“事件触发”协议。所述动作和事件可通过装置服务来提供。
当UPnP受控装置加入网络时，它可向“熟知的”IP多播地址和端口多播发现消息。这些消息可标识装置类型以及由该装置提供的服务类型，它们可给出可获得装置和服务的描述的URL。
当UPnP控制点加入网络时，它可多播搜索消息以要求受控装置公告自己。搜索消息可指定感兴趣的装置类型和/或服务类型。相关装置可通过向控制点发送单播发现消息来响应。
一旦控制点得到关于感兴趣的装置和服务的发现消息，它就可使用消息中的URL来请求装置和服务的描述。这些描述可包括可用于调用动作并且订用服务的事件的URL。
典型的第二屏幕发现情景可大体分为情景A和情景B。在情景A的情况下，当TV接收机加入网络时(可能发生在TV接收机被打开时或者可能发生在其网络接口被启用时)用户在他/她的第二屏幕装置中运行第二屏幕应用。在情景B的情况下，当TV接收机加入网络时用户没有在他/她的第二屏幕装置中运行第二屏幕应用。
情景A可如下。1)提供第二屏幕支持的TV接收机加入网络。2)TV接收机多播其发现消息，该发现消息对其第二屏幕支持服务进行广告。3)在第二屏幕装置中运行的第二屏幕应用接收多播发现消息并且向TV接收机发送对其服务的描述的请求。4)TV接收机用其服务的描述来响应。5)第二屏幕应用使用描述中给出的信息来访问适当服务并且提供与TV节目同步的交互体验。
情景B可如下。1)正在TV接收机上观看的TV节目进入提供第二屏幕支持的节目段。(这可发生在TV机被打开时、或者信道从不提供具有第二屏幕支持的交互数据服务的信道改变为提供它的信道时、或者正在观看的信道从不提供具有第二屏幕支持的交互数据服务的节目段来到提供它的节目段时。)2)这使得TV接收机以特定方式告知观看者第二屏幕支持可用–例如，通过在屏幕拐角的小图标。3)观看者决定利用第二屏幕支持并且在他/她的第二屏幕装置上激活第二屏幕应用。然后，第二屏幕应用对搜索提供第二屏幕支持的装置的消息进行多播。TV接收机用其发现消息来对该消息作出响应。4)当第二屏幕应用接收到发现消息时，它向TV接收机发送对其服务的描述的请求。5)TV接收机用其服务的描述来响应。6)第二屏幕应用使用描述中给出的信息来访问适当服务并且提供与TV节目同步的交互体验。
情景A还可如下。1)提供第二屏幕支持的TV机加入网络。(这可发生在TV机被打开时或者其网络接口被启用时。)2)这使得TV接收机多播其发现消息，该发现消息对它自己及其第二屏幕支持服务进行广告。3)如果用户此时正在他/她的第二屏幕装置上运行第二屏幕应用，则该应用接收多播发现消息并且进行至步骤(7)。4)正在TV接收机上观看的TV节目进入提供第二屏幕支持的节目段。(这可发生在TV机被打开时、或者信道从不提供具有第二屏幕支持的交互数据服务的信道改变为提供它的信道时、或者正在观看的信道从不提供具有第二屏幕支持的交互数据服务的节目段来到提供它的节目段时。)5)这使得TV接收机以特定方式告知观看者第二屏幕支持可用–例如，通过在屏幕拐角的小图标。6)如果观看者还未在他/她的第二屏幕装置中运行第二屏幕应用，则观看者可决定利用第二屏幕支持并且在他/她的第二屏幕装置上激活第二屏幕应用。然后，第二屏幕应用对搜索提供第二屏幕支持的装置的消息进行多播。TV接收机用其发现消息来对该消息作出响应。7)当第二屏幕应用接收到发现消息时，它向TV接收机发送对其服务的描述的请求。8)TV接收机用其服务的描述来响应。这些将是触发服务以及可选的HTTP代理服务器服务。9)第二屏幕应用将订用触发服务的“事件触发”特征。如果提供的交互数据服务的交互模型是直接执行模型，则触发服务将在通过TV接收机接收到触发时将所有触发发送给第二屏幕装置。如果交互数据服务的交互模型是TDO模型，则触发服务将每当新的激活触发的激活时间到来时向第二屏幕应用发送激活触发。10)第二屏幕应用将处置触发，根据需要下载TDO和其它文件(或者从互联网链接或者从TV接收机所提供的HTTP代理服务器服务)，并且向第二屏幕装置用户提供交互服务。11)每当TV接收机上的TV节目来到不提供具有第二屏幕支持的交互数据服务的片段时，触发服务将向第二屏幕应用发送“空触发”以通知它第二屏幕装置的交互数据服务不再可用。12)然后，第二屏幕装置的用户可关闭第二屏幕应用，或者任由其运行以在TV接收机上的节目进入提供第二屏幕支持的另一片段时重新开始交互。
在任一情景下，住户在家庭网络上具有不止一个TV接收机是可能的。在这种情况下，第二屏幕应用将从多个不同的接收机接收发现消息。如果是这样，则第二屏幕应用可询问用户与哪一个交互(显示来自描述消息的信息以帮助用户决定)。
提供第二屏幕支持的TV接收机可提供多个UPnP服务以便于使用第二屏幕应用。UPnP服务可以是从接收机至第二屏幕应用的“触发传送服务”、在接收机中运行的声明对象(DO)与第二屏幕应用之间的“双向通信服务”以及“HTTP代理服务器服务”。根据配置，这些服务可为可选的。
这些服务可被设计为支持从各种各样不同的来源获得的在各种各样不同类型的第二屏幕装置中的各种各样不同的操作环境中运行的各种各样不同类型的第二屏幕应用。
典型的第二屏幕打包应用情景如下。1)第二屏幕装置上的控制点订用第一屏幕装置上的打包应用服务。2)消费者在第一屏幕装置上开始打包应用。3)打包应用使得第二屏幕应用的名称和第二屏幕应用的URL对打包应用服务可用。4)第二屏幕装置上的控制点接收伙伴应用名称和URL。5)控制点在第二屏幕上设定标记以指示需要的消费者动作。6)消费者检查第二屏幕应用名称并选择它。7)控制点启动指示的第二屏幕应用。
提供第二屏幕支持的第一屏幕装置可提供多个UPnP服务以便于使用第二屏幕应用。UPnP服务之一是“应用URL服务”，其提供将要在第二屏幕装置上执行的伙伴第二屏幕应用的名称和URL。
将描述用于第二屏幕情景的系统架构。
用于第二屏幕情景的系统架构可包括广播系统42010、ACR服务器42020、广播商ATSC 2.0iTV服务器42030、ATSC 2.0接收机42040和/或第二屏幕装置42050。
广播系统42010可以是普通广播系统，并且可经由广播网络传送触发、A/V、TPT和/或其它数据文件。可如上所述经由DTVCC来发送触发。
ACR服务器42020是管理广播内容的ACR相关数据的服务器，并且可将触发发送给ATSC 2.0接收机42040，使得ATSC 2.0接收机42040根据请求或需要来获取交互服务。这可等同于上述ACR服务器。
广播商ATSC 2.0iTV服务器42030是生成并管理交互服务的服务器，可管理关联的TDO/文件并且生成并管理包括关于关联的TDO/文件的信息的TDO参数表(TPT)。
ATSC 2.0接收机42040可接收与广播A/V和交互服务有关的触发并且利用该触发获取并在屏幕上提供交互服务。这可等同于上述接收机。
第二屏幕装置42050可包括移动电话、平板、膝上型计算机等，其是第二屏幕装置。这可等同于上述第二屏幕装置。
可经由DTVCC信道或者经由ACR处理或者从广播交互TV(iTV)服务器(42030)将触发传送给ATSC 2.0接收机(42040)。在所有情况下，在适当的时间将触发从ATSC 2.0接收机(42040)传递给第二屏幕装置(42050)。本说明书描述了将触发传递给第二屏幕装置(42050)的机制。它还描述了在ATSC 2.0接收机(42040)上运行的DO与第二屏幕装置(42050)建立双向通信的机制。
经由互联网可用的应用和其它文件可通过第二屏幕装置(42050)经由家庭网络、经由单独的3GPP网络、或者经由ATSC 2.0接收机(42040)上的HTTP代理服务器(未示出)来检索，如果它提供该服务的话。在第一屏幕装置上执行的应用可以是从互联网下载的打包应用或者通过广播发送的应用。
仅经由广播中的FLUTE会话可用的应用和其它文件只有在ATSC 2.0接收机(42040)提供HTTP代理服务器时才可通过第二屏幕装置(42050)来检索，其将在被请求时传送FLUTE文件(假设第二屏幕装置(42050)不包括TV接收机)。
本说明书还描述了在ATSC 2.0接收机(42040)上运行的打包应用支持在第二屏幕装置(42050)上的应用的启动的机制。
图43是示出ATSC 2.0接收机与第二屏幕之间的拓扑(直接连接)的实施方式的示图。
图43示出ATSC 2.0接收机与第二屏幕装置之间的直接连接。
ATSC 2.0接收机与第二屏幕之间的拓扑(直接连接)的实施方式可包括广播系统43010、广播商ATSC 2.0服务器43020、ATSC 2.0接收机43030和/或第二屏幕装置43040。
广播系统43010可等同于广播系统42010。
广播商ATSC 2.0服务器43020可等同于广播商ATSC 2.0iTV服务器42030。
ATSC 2.0接收机43030可等同于ATSC 2.0接收机42040。
第二屏幕装置43040可等同于第二屏幕装置42050。
ATSC 2.0接收机43030可连接到广播网络以直接接收地面广播。因此，ATSC 2.0接收机43030可提取经由DTVCC从DTVCC服务编号6发送的iTV消息的URL字符串。另外，ATSC2.0接收机43030可根据需要连接到家庭网关以访问互联网。ATSC 2.0接收机43030可利用家庭联网技术(UPnP)来与连接在其它家庭网络中的装置通信。
第二屏幕装置43040全部连接到家庭网关以与装置通信并自由地访问互联网。家庭网关可包括用于支持以太网和Wi-Fi的所有功能。
广播商可经由互联网服务器提供补充服务以用于交互服务。ATSC 2.0接收机43030或第二屏幕装置43040可访问服务器以为移动装置下载TDO或网页。在ATSC 2.0接收机43030的情况下，网页可被呈现至TV的分辨率，在第二屏幕装置43040的情况下，网页可被呈现至与TV不同的API的分辨率。
图44是示出ATSC 2.0接收机与第二屏幕之间的拓扑(间接连接)的实施方式的示图。
图44示出ATSC 2.0接收机与第二屏幕之间的拓扑(间接连接)的实施方式。
图44示出ATSC 2.0接收机与第二屏幕装置之间的间接连接。
ATSC 2.0接收机与第二屏幕之间的拓扑(间接连接)的实施方式可包括广播系统44010、广播商ATSC 2.0服务器4020、广播商会话管理装置44030、ATSC 2.0接收机44040和/或第二屏幕装置44050。
广播系统44010可等同于广播系统42010。
广播商ATSC 2.0服务器44020可等同于广播商ATSC 2.0iTV服务器42030。
广播商会话管理装置44030可用于管理第二屏幕装置44050与ATSC 2.0接收机44040之间的间接连接。
ATSC 2.0接收机44040可等同于ATSC 2.0接收机42040。
第二屏幕装置44050可等同于第二屏幕装置42050。
图44的间接连接并非指示第二屏幕装置44050经由家庭网关连接到ATSC 2.0接收机44040，而是指示第二屏幕装置44050直接连接到3GPP网络以经由家庭网络连接到ATSC2.0接收机44040。在这种情况下，难以将第二屏幕装置44050连接到家庭网络或者可能不存在支持家庭网络的网络接口。
在这种情况下，第二屏幕装置44050可能需要存储在外部互联网服务器上的关于ATSC 2.0接收机44040的信息。另外，ATSC 2.0接收机44040在操作时向外部互联网服务器报告访问地址。
图45是示出第二屏幕服务应用的软件层的实施方式的示图。
第二屏幕装置通常利用OS来执行应用。通常，为了重量轻，移动装置的OS的一些功能可能不被包括。因此，OS不支持的功能需要被包括在应用中。
图45的软件层示出第二屏幕服务所需的第二屏幕服务应用的软件结构。图45可示出接收机管理第二屏幕应用的生命周期的情况。
由于第二屏幕装置可回放互联网内容，所以OS可向使用平台SDK的程序员提供可执行web应用的环境。该环境可按照SDK的形式来提供，使得由OS执行的应用直接显示互联网内容。
在图45中，第二屏幕服务应用可在第二屏幕装置上运行。该应用可从AppStore(或者特定应用市场)下载。第二屏幕服务应用可包括ACR客户机并且使用麦克风和相机来从TV机捕获视频和音频数据。此外，ACR客户机可对视频和音频数据进行采样并且将媒体签名发送给ACR服务器。第二屏幕服务应用可在OS上运行并且包括诸如HTTP、SSDP或多播事件的协议，UPnP框架可据此来操作，可包括浏览器模块以便执行并显示web应用。
浏览器模块可以是呈现互联网网页的模块。浏览器模块是呈现Web应用的web浏览器引擎的核心部分(例如，ECMAScript、HTML和XHTML)。另外，浏览器模块可意指提供与OS所提供的浏览器相同或相似的功能的软件模块。OS之间使用浏览器的方法和可控制的功能不同。
第二屏幕应用可以是为第二屏幕装置设计的web应用。第二屏幕应用可以是根据ECMAScript调用功能的web应用或者大小被控制以在移动OS所提供的浏览器模块中执行的web应用。该web应用可在第二屏幕服务应用中执行。
移动装置的操作系统可由支持硬件的驱动器组成，并且包括内核特定服务的驱动器。从根本上，可仅支持IP、TCP和UDP协议。网络协议栈存在于OS上方。在UPnP的情况下，可利用UDP来发送HTTP。
UPnP DCP框架可意指UPnP论坛中所定义的装置控制点。
SSDP(简单服务发现协议)可根据家庭网络中连接到网络的装置来搜索一个或更多个服务。
图46是示出第二屏幕服务应用的软件层的示图。
图46的软件层示出第二屏幕服务所需的第二屏幕服务应用的软件结构。图46可示出第二屏幕服务应用管理第二屏幕应用的生命周期的情况。
图46的各个实体的描述在角色和功能方面可等同于图45的各个实体的描述。
ATSC 2.0触发客户机可意指接收并处理上述触发、TPT、AMT等的模块。该模块可根据情况被包括在第二屏幕装置中。如果该模块被包括在第二屏幕装置中，则该模块可直接处理TPT和AMT以直接检查应用的生命周期。
图47是示出示出根据第二屏幕应用生命周期管理的传输顺序和传输的数据之间的差异的表的示图。
接收机可经由广播网络利用DTVCC直接接收TPT和AMT或者经由互联网下载TPT和AMT，并且处理TPT和AMT。如上所述，TPT包括event信息，event信息可包括EventId、Action、Destination和Data信息。“Event@Destination”可指示该event信息是为哪一装置而生成的。例如，目的地可以是接收机或第二屏幕装置。如果目的地被设定为第二屏幕装置，则接收机应该将event信息传送给第二屏幕装置。
因此，需要一种将该信息传送给第二屏幕装置的方法。第二屏幕应用的生命周期可由接收机或第二屏幕服务应用来管理。
图47的表示出信息传送方法的概述，实体据此来管理第二屏幕应用的生命周期。
第一行可以是下述图51的情况的描述的概述，其详细描述将在下面给出。
第二行可以是接收机管理第二屏幕应用的生命周期的情况的描述的概述，其详细描述将在下面给出。
第三行可以是接收机过滤(增强)并传送第二屏幕装置所需的触发信息的情况的描述的概述，其详细描述将在下面给出。
第四行可以是下述图58的情况的描述的概述，其详细描述将在下面给出。
第五行可以是下述图57的情况的描述的概述，其详细描述将在下面给出。
图48是示出集中执行模型的操作概念的示图。
有效地将交互服务传送给第二屏幕装置的方法可包括集中执行模型和分布执行模型。
如示出集中执行模型的操作概念的示图中所示，TV机可利用UPnP的RUI机制来生成并更新将要显示在各个第二屏幕装置上的RUI，并且经由网络发送该RUI。各个第二屏幕装置可经由RUI客户机来实时地接收RUI并且将该RUI显示在屏幕上。与分布执行模型不同，DAE可存在于主装置中。
图49是示出基于集中执行模型的接收机与第二屏幕之间协作的流程的示图。
图49的流程可以是在集中执行模型的操作概念的实施方式中在接收机能够经由广播网络获取交互服务并且与第二屏幕装置协作的环境中应用集中执行模型机制时的操作。
基于集中执行模型的接收机与第二屏幕之间协作的流程的实施方式可包括发送时基触发(s49010)、请求TPT(s49020)、发送TPT作为响应(s49030)、解析TPT(s49040)、发送对第二屏幕的执行触发(s49050)、下载TDO/文件(s49060)、生成RUI(s49070)、经由RUI协议发送RUI(s49080)、在屏幕上显示UI(s49090)、用户点击用于新页面的链接(s49100)、发送输入数据(s49110)、下载新TDO/文件(s49120)、更新RUI(s49130)、经由RUI协议发送RUI(s49140)和/或在屏幕上显示UI(s49150)。
发送时基触发(s49010)可包括接收机经由DTVCC或ACR服务器接收时基触发。在上面描述了时基触发。
请求TPT(s49020)可包括接收机解释所接收到的触发，获取能够获取TPT的服务器的URL，并且请求TPT。
发送TPT作为响应(s49030)可包括响应于请求TPT(s49020)中的请求，发送TPT。
解析TPT(s49040)可包括接收机解析所请求的TPT。
发送对第二屏幕的执行触发(s49050)可包括接收机经由DTVCC或ACR服务器接收对第二屏幕的执行触发。该执行触发可等同于上述激活触发。
下载TDO/文件(s49060)可包括接收机从所接收到的TPT获取关于与时基触发或执行触发关联的TDO和文件的信息并且从内容服务器下载由触发指示的TDO和文件。
生成RUI(s49070)可包括为下载的TDO和文件生成RUI。
经由RUI协议发送RUI(s49080)可包括接收机利用RUI协议发送在第二屏幕上生成的RUI。
在屏幕上显示UI(s49090)可包括将所接收到的RUI显示在第二屏幕上。
用户点击用于新页面的链接(s49100)可包括通过用户在第二屏幕上的选择来点击RUI上的特定链接。
发送输入数据(s49110)可包括如果点击的特定链接连接到另一页面，则将用户的输入信息传送给接收机。
下载新TDO/文件(s49120)可包括接收机下载与用户输入关联的TDO和文件。
更新RUI(s49130)可包括根据所下载的TDO和文件更新RUI。
经由RUI协议发送RUI(s49140)可包括接收机利用RUI协议将更新的RUI发送给第二屏幕。
在屏幕上显示UI(s49150)可包括将更新的RUI显示在第二屏幕上。
图50是示出在接收机处向第二屏幕装置通知UI信息的方法的实施方式的示图。
图50示出接收机从广播商接收触发并且将触发传送给第二屏幕装置的逻辑顺序。
该处理可包括接收对接收机的触发(s50010)、接收对第二屏幕服务的触发(s50020)、发送关于更新的UI信息的通知(s50030)、请求更新的UI信息(s50040)、发送兼容UI信息作为响应(s50050)以及接收对接收机的另一触发(s50060)。
接收对接收机的触发(s50010)可包括主装置经由广播流从广播商接收对接收机(即，主装置)的触发。
接收对第二屏幕服务的触发(s50020)可包括主装置经由广播流从广播商接收对第二屏幕服务的触发。
发送关于更新的UI信息的通知(s50030)可包括就更新的UI进行通知。如上所述，如果在观看广播节目的同时接收到触发，则接收机可检查触发是对第二屏幕装置还是主装置的。此时，如果触发是对第二屏幕装置的，则可向所有UPnP装置或者仅特定UPnP装置通知新UI信息更新。这可对应于第二屏幕装置使用UPnP协议订用的情况。
请求更新的UI信息(s50040)可包括第二屏幕装置向主装置请求更新的UI信息。
发送兼容UI信息作为响应(s50050)可包括主装置将兼容UI信息发送给第二屏幕装置。
接收对接收机的另一触发(s50060)可等同于接收对接收机的触发(s50010)。即，可再次执行上述操作。
由于接收机可包括触发模块，所以接收机可经由广播网络或互联网来接收诸如TPT和AMT的XML文件，解析XML文件，并且执行适当操作。如果找到第二屏幕装置，则可利用Event@Destination字段来识别传送给第二屏幕装置的Action、TDO URL和Data。第二屏幕装置可不直接接收诸如TPT或AMT的XML文件，因此可不包括触发模块。如果RemoteUI客户机服务被包括，则接收机可管理所有第二屏幕应用的生命周期。相比之下，如果多个第二屏幕装置被连接，则用于控制第二屏幕应用的数据应该被发送多次。
图51是示出在接收机处向第二屏幕装置通知UI信息的方法的实施方式的示图。
与图50不同，图51示出被确定为适用于第二屏幕装置的第二屏幕装置的所有UI信息被直接传送的情况。即，可发送第二屏幕装置的TDO URL。
该处理可包括接收对接收机的触发(s51010)、接收对第二屏幕服务的触发(s51020)、通知UI信息(s51030)、发送响应“ok”(s51040)、接收对接收机的触发(s51050)、接收对接收机的触发(s51060)、接收对第二屏幕服务的触发(s51070)、通知UI信息(s51080)和/或发送响应“ok”(s51090)。
接收对接收机的触发(s51010)可等同于接收对接收机的触发(s50010)。
接收对第二屏幕服务的触发(s51020)可等同于接收对第二屏幕服务的触发(s50020)。
通知UI信息(s51030)可包括通知UI信息更新。
发送响应“ok”(s51040)可包括发送指示UI通知已被接收的消息。
接收对接收机的触发(s51050)和接收对接收机的触发(s51060)可等同于接收对接收机的触发(s50010)。即，可再次执行上述操作。
接收对第二屏幕服务的触发(s51070)可等同于接收对第二屏幕服务的触发(s50020)。即，可再次执行上述操作。
通知UI信息(s51080)可等同于通知UI信息(s51030)。即，可再次执行上述操作。
发送响应“ok”(s51090)可等同于发送响应“ok”(s51040)。即，可再次执行上述操作。
在图51的方法中，接收机应该知道哪一UPnP装置是第二屏幕装置以及包括什么装置配置文件。具体地讲，接收机应该知道第二屏幕装置是否支持第二屏幕服务。
在确定触发是对第二屏幕装置还是对主装置之后通知UI信息的方法(图50的情况)以及传送被确定为适用于第二屏幕装置的第二屏幕装置的所有UI信息的方法(图51的情况)的相同之处可在于接收机处理TPT和触发并且仅将TDO URL传送给第二屏幕装置。这两种方法的不同之处可在于接收机间接地将TDO传送给第二屏幕装置或者接收机直接记录各个装置的装置配置文件并且仅向第二屏幕装置通知第二屏幕应用的位置。
图52是示出RemoteUI服务器服务的广播信令的实施方式的示图。
RemoteUI服务器服务的广播信令的一个实施方式可包括UPnP装置和服务发现(s52010)、请求UIListing(s52020)、发送UIListing(s52030)、订用事件(s52040)、返回HTTP消息(s52050)、发送UIListingUpdate消息(s52060)、请求UIListing(s52070)和/或返回UIListing(s52080)。
UPnP装置和服务发现(s52010)可包括发现接收机和第二屏幕装置。新连接到家庭网络的装置或者已经连接到家庭网络的装置(接收机或第二屏幕装置)可多播用于发现的消息。此时，可利用多播来搜索期望的服务，可针对多个非特定的UPnP装置搜索所有服务。这可根据装置提供什么服务而改变。在此步骤中，第二屏幕装置可知道主装置的装置配置文件。主装置可处理装置配置文件并构建适当的UIListing。RemoteUI服务器可给予第二屏幕装置CompatibleUIs XSD模式。该模式可包括应用的URL、该UI的唯一id(“uiID”)、名称、protocolInfo等。
请求UIListing(s52020)可包括第二屏幕装置发送其装置配置文件并请求UIListing。可使用能够获得兼容UI的GetCompatibleUIs动作。(UIFilter可为可选的)。其详细描述将在下面给出。
发送UIListing(s52030)可包括主装置根据请求将适当的UI listing发送给第二屏幕装置。其详细描述将在下面给出。
订用事件(s52040)可包括订用主装置的适当暴露的Event。订用事件(s52040)可被选择性地执行以便接收作为由RemoteUI服务器服务提供的事件信息的“UIListingUpdate”。在返回UIListing(s52080)中，可通知第二屏幕装置RemoteUI的地址已改变或者UI已改变。即，由于仅通知第二屏幕装置UI已改变，所以如果需要详细位置或附加信息，则应该将“GetCompatibleUIs”动作发送给接收机以获得“UIListing”值。
返回HTTP消息(s52050)可包括发送订用事件(s52040)的结果。类似于发送响应1(s40100)，可根据情况发送诸如HTTP/1.1 200 OK的响应。
发送UIListingUpdate消息(s52060)可包括将“UIListingUpdate”消息发送给订户。
请求UIListing(s52070)可包括第二屏幕装置发送其装置配置文件并请求UIListing。可使用能够获得兼容UI的GetCompatibleUIs动作。发送UIListingUpdate消息(s52060)和请求UIListing(s52070)可包括执行时间设定以使得第二屏幕应用不改变，并且选择性地只有当服务器支持时才可行。该步骤是可选的。该方法可以是在接收机处利用UPnP事件通知所有第二屏幕装置存在第二屏幕服务的方法。即，可通知家庭网络中的所有第二屏幕装置与第二屏幕服务关联的UI已改变。如果利用UPnP事件向所有第二屏幕装置通知“UIListingUpdate”变量，则第二屏幕装置可确认UI已被重新更新。随后，第二屏幕装置可执行“GetCompatibleUIs”动作，选择适合于硬件装置的UI，并且通过参考装置配置文件来执行UI。
返回UIListing(s52080)可包括主装置根据请求将适当的UI listing发送给第二屏幕装置。如上所述，返回UIListing(s52080)可包括向订用的第二屏幕装置通知RemoteUI的地址已改变或者UI已改变。即，由于仅通知第二屏幕装置UI已改变，所以如果需要详细位置或附加信息，则应该将“GetCompatibleUIs”动作发送给接收机以获得“UIListing”值。
当RemoteUI服务器服务操作时，接收机应该根据请求装置的装置配置文件来提供远程UI信息。从向后兼容的角度，装置配置文件“DeviceInfo”被交换，并且当稍后向接收机请求“GetCompatibleUIs”动作时，由RemoteUI服务器服务发送的URL可根据请求客户机的配置文件而改变。如果传统UPnP装置向RemoteUI服务器请求“GetCompatibleUIs”动作，则应该提供适合于该传统UPnP装置的DeviceInfo的UI。然而，如果支持第二屏幕服务的装置请求“GetCompatibleUIs”动作，则RemoteUI服务器服务装置还应该发送URL信息。
接收机可经由DTVCC获得触发信息并且从触发信息获得媒体时间和事件时间信息。此时，可利用“t＝media_time”句法来确认TDO的“appID”、“URL”(TDO_URL)、“eventID”、“action”以及可选的“Data”或者执行时间。如果接收机管理第二屏幕应用的生命周期，则将由第二屏幕服务应用处理的信息量可减少。相比之下，如果第二屏幕服务应用直接管理第二屏幕应用的生命周期，则必要信息可增加。
图53是示出分布执行模型的操作概念的示图。
作为有效地将交互服务传送给第二屏幕装置的方法，将描述分布执行模型。
如示出分布执行模型的操作概念的示图中所示，TV机可利用UPnP等将诸如触发的信息传送给第二屏幕装置。各个第二屏幕装置具有触发处理机并且可实时地处理经由触发处理机接收的诸如触发的信息。浏览器可执行与其关联的交互服务。
与集中执行模型不同，DAE可存在于各个第二屏幕装置中。
基于分布执行模型将交互服务传送给第二屏幕装置的处理可按照如下顺序执行。1.接收机呈现具有第二屏幕支持的片段。2.接收机显示第二屏幕支持可用的特定指示。3.用户在第二屏幕装置上启动第二屏幕应用。4.接收机和第二屏幕装置经由UPnP机制发现彼此(通过接收机上的本机代码和装置上的第二屏幕应用来执行)。5.TV机得到触发(从DTVCC流或ACR)以启动第二屏幕装置上的TDO。6.TV机将触发与来自TPT的信息组合并在激活时间发送给第二屏幕装置。7.第二屏幕装置下载TDO(一个或更多个文件)并在浏览器中执行它。8.用户与TDO交互，这可导致TDO下载附加文件。9.接收机得到触发以针对第二屏幕装置上的TDO生成Event。10.接收机将触发与来自TPT的信息组合并在激活时间发送给第二屏幕装置。11.第二屏幕装置针对浏览器中的TDO生成TriggerEvent(类似DVB StreamEvent)。12.TDO执行通过TriggerEvent请求的动作，这可导致它下载数据文件。
图54是示出基于分布执行模型的接收机与第二屏幕之间的协作的流程的示图。
分布执行模型的流程可以是在接收机将经由DTVCC或ACR服务器接收的信息没有改变地发送给第二屏幕的情况下的数据流。现在将描述详细流程。
基于分布执行模型的接收机与第二屏幕之间的协作的流程的实施方式可包括发送时基触发(s54010)、发送时基触发(s54020)、请求TPT(s54030)、发送TPT作为响应(s54040)、解析TPT(s54050)、发送对第二屏幕的执行触发(s54060)、发送执行触发(s54070)、下载TDO/文件(s54080)、在浏览器中执行TDO(s54090)、用户点击用于新页面的链接(s54100)、下载新TDO/文件(s54110)和/或在浏览器中执行新TDO(s54120)。
发送时基触发(s54010)可等同于发送时基触发(s49010)。
发送时基触发(s54020)可包括接收机将所接收到的触发没有改变地发送给第二屏幕。
请求TPT(s54030)可包括第二屏幕解释所接收到的触发，获取能够获取TPT的服务的URL并且请求TPT。
发送TPT作为响应(s54040)可包括响应于请求TPT(s54030)中的请求发送TPT。
解析TPT(s54050)可包括解析所请求的TPT。
发送对第二屏幕的执行触发(s54060)可等同于发送对第二屏幕的执行触发(s49050)。
发送执行触发(s54070)可包括接收机将所接收到的触发没有改变地发送给第二屏幕。
下载TDO/文件(s54080)可包括第二屏幕从TPT获取与触发关联的TDO/文件并且从内容服务器下载TDO/文件。
在浏览器中执行TDO(s54090)可包括在浏览器上执行所下载的TDO和文件。
用户点击用于新页面的链接(s54100)可包括用户点击所执行的TDO上的特定链接。
下载新TDO/文件(s54110)可包括如果建立至另一TDO的特定链接，则下载关联的TDO/文件。
在浏览器中执行新TDO(s54120)可包括在浏览器上执行关联的TDO和文件。
图55是示出基于分布执行模型的接收机与第二屏幕之间的协作的流程的示图。
分布执行模型的流程可以是在接收机没有将经由DTVCC或ACR服务器接收的信息没有改变地发送给第二屏幕，而是根据适合于第二屏幕的触发插入必要信息，将信息改变为扩展触发并且将信息发送给第二屏幕的情况下的数据流。现在将描述详细流程。
基于分布执行模型的接收机与第二屏幕之间的协作的流程的实施方式可包括发送时基触发(s55010)、请求TPT(s55020)、发送TPT作为响应(s55030)、解析TPT(s55040)、发送对第二屏幕的执行触发(s55050)、生成扩展触发(s55060)、发送扩展触发(s55070)、下载TDO/文件(s55080)、在浏览器中执行TDO(s55090)、用户点击用于新页面的链接(s55100)、下载新TDO/文件(s55110)和/或在浏览器中执行新TDO(s55120)。
发送时基触发(s55010)可等同于发送时基触发(s54010)。
请求TPT(s55020)可等同于请求TPT(s54030)。
发送TPT作为响应(s55030)可等同于发送TPT作为响应(s54040)。
解析TPT(s55040)可等同于解析TPT(s54050)。
发送对第二屏幕的执行触发(s55050)可等同于发送对第二屏幕的执行触发(s54060)。
生成扩展触发(s55060)可包括接收机从TPT获取关于触发所关联的TDO和文件的信息并且生成包括其的扩展触发。
发送扩展触发(s55070)可包括接收机将所生成的扩展触发发送给第二屏幕。
下载TDO/文件(s55080)可等同于下载TDO/文件(s54080)。
在浏览器中执行TDO(s55090)可等同于在浏览器中执行TDO(s54090)。
用户点击用于新页面的链接(s55100)可等同于用户点击用于新页面的链接(s54100)。
下载新TDO/文件(s55110)可等同于下载新TDO/文件(s54110)。
在浏览器中执行新TDO(s55120)可等同于在浏览器中执行新TDO(s54120)。
图56是示出在接收机处向第二屏幕装置通知TDO和Event信息的方法的实施方式的示图。
图56示出在接收机处接收触发和TPT，根据触发执行处理，当对第二屏幕装置的触发到来时将触发与TPT进行比较，提取并配置需要由第二屏幕装置识别的XML文件形式的信息，并且将该信息发送给第二屏幕装置的方法。该方法的优点可在于第二屏幕装置可主动地操作并执行预测。
该处理可包括接收对接收机的触发(s56010)、接收对第二屏幕服务的触发(s56020)、转换TPT和触发并生成事件信息(s56030)、发送TDO和事件信息(s56040)、发送响应“ok”(s56050)、接收对接收机的触发(s56060)、接收对接收机的触发(s56070)、接收对第二屏幕服务的触发(s56080)、转换TPT和触发并生成事件信息(s56090)、发送TDO和事件信息(s56100)和/或发送响应“ok”(s56110)。
接收对接收机的触发(s56010)可等同于接收对接收机的触发(s50010)。
接收对第二屏幕服务的触发(s56020)可等同于接收对第二屏幕服务的触发(s50020)。
转换TPT和触发并生成事件信息(s56030)可包括解释TPT和触发并生成事件信息。所生成的信息可用于组合包括在TPT和触发中的信息以用于生成新数据结构并且可包括关于生成什么TDO或者何时生成TDO的信息。该数据结构将在下面描述。如果决定了新数据结构，则除了TDO URL以外还可发送各种必要信息。
发送TDO和事件信息(s56040)可包括将所生成的事件信息和TDO发送给第二屏幕装置。
发送响应“ok”(s56050)可包括发送指示所接收到的TDO和事件信息已被接收的消息。
接收对接收机的触发(s56060)和接收对接收机的触发(s56070)可等同于接收对接收机的触发(s50010)。
接收对第二屏幕服务的触发(s56080)可等同于接收对第二屏幕服务的触发(s50020)。
转换TPT和触发并生成事件信息(s56090)可等同于转换TPT和触发并生成事件信息(s56030)。
发送TDO和事件信息(s56100)可等同于发送TDO和事件信息(s56040)。
发送响应“ok”(s56110)可等同于发送响应“ok”(s56050)。
接收对接收机的触发(s56060)、接收对接收机的触发(s56070)、接收对第二屏幕服务的触发(s56080)、转换TPT和触发并生成事件信息(s56090)、发送TDO和事件信息(s56100)以及发送响应“ok”(s56110)可等同于上述操作。
图57是示出在第二屏幕装置处访问TPT和第二屏幕应用的方法的实施方式的示图。
第二屏幕装置是独立装置，如果接收机经由互联网接收到诸如TPT和AMT的XML文件或者知道TPT和AMT服务器地址，则它可直接执行第二屏幕应用。在这种情况下，触发模块被包括在第二屏幕装置中。第二屏幕装置可接收由接收机接收的iTV消息的URI字符串。该消息适用于1)在RemoteUI服务器服务的情况下发送iTV消息(触发)的URI字符串的方法以及2)在RemoteUI客户机服务的情况下发送iTV消息(触发)的URI字符串的方法二者。
首先，将描述在RemoteUI服务器服务的情况下发送iTV消息(触发)的URI字符串的方法。
该处理可包括接收对接收机的触发(s57010)、接收对第二屏幕服务的触发(s57020)、发送关于更新的UI信息的通知(s57030)、请求更新的UI信息(s57040)、发送UI信息作为响应(s57050)、请求TPT XML文件(s57060)、返回TPT XML文件(s57070)、接收对第二屏幕服务的触发(s57080)、发送关于更新的UI信息的通知(s57090)、请求更新的UI信息(s57100)、发送UI信息作为响应(s57110)、接收对第二屏幕服务的触发(s57120)、发送关于更新的UI信息的通知(s57130)、请求更新的UI信息(s57140)、发送UI信息作为响应(s57150)、请求第二屏幕应用(s57160)和/或返回第二屏幕应用(s57170)。
接收对接收机的触发(s57010)可等同于接收对接收机的触发(s50010)。由于第一触发不是对第二屏幕装置的，所以接收机没有将触发传送给第二屏幕装置。
接收对第二屏幕服务的触发(s57020)可等同于接收对第二屏幕服务的触发(s50020)。该触发可具有关于第二屏幕服务的媒体时间的信息。第二触发可用作上述预载触发。
发送关于更新的UI信息的通知(s57030)可包括通知更新的UI信息。由于第二触发是对第二屏幕服务的，所以接收机可将所接收到的URIString发送给第二屏幕装置。此时，第二屏幕装置可被告知存在新信息并且可被允许直接读取该信息。
请求更新的UI信息(s57040)可等同于请求更新的UI信息(s50040)。
发送UI信息作为响应(s57050)可包括主装置将UI信息发送给第二屏幕装置。此时，可发送第二触发。
请求TPT XML文件(s57060)可包括第二屏幕装置解析从主装置接收的信息(第二触发)并且向TPT服务器请求TPT XML文件。
返回TPT XML文件(s57070)可包括第二屏幕装置从TPT服务器下载所请求的TPTXML文件。
接收对第二屏幕服务的触发(s57080)可等同于接收对第二屏幕服务的触发(s50020)。第三触发与第二屏幕装置关联并且可具有关于媒体时间的信息。第三触发是媒体时间触发，其可执行与上述时基触发相同的功能。
发送关于更新的UI信息的通知(s57090)可包括通知更新的UI信息。由于确定第三触发与第二屏幕装置关联，所以接收机可向第二屏幕装置通知第三触发。
请求更新的UI信息(s57100)可等同于请求更新的UI信息(s50040)。
发送UI信息作为响应(s57110)可包括主装置将UI信息发送给第二屏幕装置。此时，可发送第三触发。然而，由于第三触发是媒体时间触发，所以可仅控制第二屏幕装置的媒体时间。因此，可执行第二屏幕装置与接收机之间的媒体时间同步。
接收对第二屏幕服务的触发(s57120)可等同于接收对第二屏幕服务的触发(s50020)。第四触发与第二屏幕装置关联并且可具有关于事件时间的信息。第四触发是事件时间触发，其可执行与上述激活触发相同的功能。
发送关于更新的UI信息的通知(s57130)可包括通知更新的UI。由于确定第四触发与第二屏幕装置关联，所以接收机可将第四触发通知给第二屏幕装置。
请求更新的UI信息(s57140)可等同于请求更新的UI信息(s50040)。
发送UI信息作为响应(s57150)可包括主装置将UI信息发送给第二屏幕装置。此时，可发送第四触发。
请求第二屏幕应用(s57160)可包括第二屏幕装置检查关于第四触发的信息并且向应用服务器请求第二屏幕应用以便下载TDO URL的位置的第二屏幕应用。
返回第二屏幕应用(s57170)可包括根据请求下载第二屏幕应用。可下载第二屏幕应用以执行Event@Action。此时，由于向应用服务器告知了关于第二屏幕装置的浏览器的信息，所以应用服务器可容易地检查哪一第二屏幕装置被连接。因此，可自动地选择并从服务器下载应用。
总之，如果经由DTVCC接收到iTV消息的URI字符串，则接收机可向所找到的第二屏幕装置发送指示新UI已被更新的事件。第二屏幕装置可检查事件信息并发送“GetCompatibleUIs”动作以便获得新UI信息。接收机可发送所接收到的TPT服务器的URI信息。通过该方法，第二屏幕装置可接收URI信息，直接处理TPT和AMT信息，并且直接控制第二屏幕应用。
如果第二屏幕服务应用中包括ATSC 2.0触发客户机，则该处理可行。
图58是示出在第二屏幕装置处访问TPT和第二屏幕应用的方法的实施方式的示图。
在上述两种方法之间，将描述在RemoteUI客户机服务的情况下发送iTV消息(触发)的URI字符串的方法。
该处理可包括接收对接收机的触发(s58010)、接收对第二屏幕服务的触发(s58020)、通知触发(s58030)、发送响应“ok”(s58040)、请求TPT XML文件(s58050)、返回TPT XML文件(s58060)、接收对第二屏幕服务的触发(s58070)、通知触发(s58080)、发送响应“ok”(s58090)、接收对第二屏幕服务的触发(s58100)、通知触发(s58110)、发送响应“ok”(s58120)、请求第二屏幕应用(s58130)和/或返回第二屏幕应用(s58140)。
接收对接收机的触发(s58010)可包括主装置经由广播流从广播商接收对接收机(即，主装置)的触发。由于第一触发是对接收机的，所以没有将第一触发传送给第二屏幕装置。
接收对第二屏幕服务的触发(s58020)可等同于接收对第二屏幕服务的触发(s50020)。第二触发是对第二屏幕服务的触发，并且可具有关于媒体时间的信息。第二触发可用作上述预载触发。
与图57不同，通知触发(s58030)可包括接收机立即将触发发送给第二屏幕装置。如果经由DTVCC接收到iTV消息的URI字符串，则接收机可利用“AddUIListing”动作将由接收机接收的URI值传送给第二屏幕装置。
发送响应“ok”(s58040)可包括发送指示触发已被接收的消息。
请求TPT XML文件(s58050)可等同于请求TPT XML文件(s57060)。包括在第二屏幕装置中的触发模块可利用所接收到的URI值访问TPT服务器，下载TPT和AMT文件，并且直接控制第二屏幕应用。
返回TPT XML文件(s58060)可等同于返回TPT XML文件(s57070)。
接收对第二屏幕服务的触发(s58070)可等同于接收对第二屏幕服务的触发(s50020)。第三触发与第二屏幕装置关联并且可具有关于媒体时间的信息。第三触发是媒体时间触发，其可执行与上述时基触发相同的功能。
通知触发(s58080)可包括传送触发，类似于通知触发(s58030)。
发送响应“ok”(s58090)可等同于发送响应“ok”(s58040)。
接收对第二屏幕服务的触发(s58100)可等同于接收对第二屏幕服务的触发(s50020)。第四触发与第二屏幕装置关联并且可具有关于事件时间的信息。第四触发是事件时间触发，其可执行与上述激活触发相同的功能。
通知触发(s58110)可包括传送触发，类似于通知触发(s58030)。
发送响应“ok”(s58120)可等同于发送响应“ok”(s58040)。
请求第二屏幕应用(s58130)可等同于请求第二屏幕应用(s57160)。
返回第二屏幕应用(s58140)可等同于返回第二屏幕应用(s57170)。
即，接收机可总是将具有与第二屏幕服务关联的事件信息的触发传送给第二屏幕装置，第二屏幕装置可利用所下载的TPT信息立即操作。由于利用DTVCC周期性地传送媒体时间触发，所以接收机应该连续传送该信息。
由于主装置或第二屏幕装置具有TPT XML，所以在实时地从实时触发服务器接收事件触发时还可接收AMT。
可根据应用什么URL值来不同地执行上述两种方法，并且接收机的操作或者第二屏幕服务应用的结构和操作可改变。
将描述第二屏幕服务的信令机制。
第二屏幕服务的信令可使用两种方法：在接收机处通知存在第二屏幕服务的第一方法以及当第二屏幕装置连接到家庭网络时搜索装置和服务以便检测提供第二屏幕服务的电子设备的第二方法。另选地，接收机可确认新电子设备的装置描述符并请求服务描述符。
以下将描述广播信令和单播信令。
在广播信令的情况下，第二屏幕装置检测RemoteUI服务器服务，确认装置描述符并且请求与第二屏幕服务兼容的DeviceInfo配置文件。可接收事件，并且可接收根据经由接收机观看的节目而改变的TDO(交互应用)的URL。
相比之下，在单播信令的情况下，接收机可确认第二屏幕装置的DeviceInfo是否兼容并且发送兼容TDO URL。可发送RemoveUIListing动作以终止当前执行的第二屏幕应用以支持显示消息的动作，并且终止当前执行的UI。可通过ProcessInput动作将由接收机解析并处理的补充Event@data传送给第二屏幕服务应用。
下面将描述广播信令和单播信令。
图59是示出RemoteUI服务器服务的广播信令的另一实施方式的示图。
在广播信令中，如果接收机首次连接到家庭网络，则接收机可将其装置描述符和服务描述符通知给所有电子设备，或者接收来自另一控制点的请求并发送其装置描述符和服务描述符。
RemoteUI服务器服务的广播信令的另一实施方式可包括UPnP装置和服务发现(s59010)、发送UIListing(s59020)、发送UIListing(s59030)、请求UIListing(s59040)和/或返回UIListing(s59050)。
UPnP装置和服务发现(s59010)可等同于UPnP装置和服务发现(s52010)。
发送UIListing(s59020)可包括将“UIListingUpdate”消息发送给所有UPnP装置。主装置可将UIListingUpdate的公告发送给唯一“uiID”列表上的UPnP装置。第二屏幕装置可接收该消息并且检查uiID。然而，由于与特定uiID不匹配，第二屏幕装置可不执行UI更新。
发送UIListing(s59030)可包括将“UIListingUpdate”消息发送给所有UPnP装置。与发送UIListing(s59020)不同，可存在匹配uiID。
请求UIListing(s59040)可包括第二屏幕装置发送其装置配置文件并请求UIListing，因为发送UIListing(s59030)中存在匹配uiID。可使用能够获得兼容UI的GetCompatibleUIs动作。
返回UIListing(s59050)可包括主装置根据请求将适当UI Listing发送给第二屏幕装置。
图60是示出第二屏幕服务的装置发现和装置能力交换的实施方式的示图。
如上所述，如果接收机首次连接到家庭网络，则接收机可将其装置描述符和服务描述符通知给所有电子设备或者接收来自另一控制点的请求并发送其装置描述符和服务描述符。
连接到家庭网络的接收到接收机的装置描述符和服务描述符的各个UPnP装置可利用HTTP的“LOCATION”头来发送其装置描述符的位置。即，UPnP装置可发送UPnP装置描述符的位置。如果利用“LOCATION”作出HTTP GET请求，则可接收包括关于装置的信息的XML文件。
在UPnP装置和服务发现中，将引入在主装置处检测能够提供第二屏幕服务的第二屏幕装置的方法。该方法可大体分为两种方法。作为第一方法，第二屏幕装置准备两个装置配置文件并且利用HTTP头来通知装置配置文件的XML文件。假设不兼容主装置忽略无法理解的HTTP头。作为第二方法，在装置配置文件中，调用提供第二屏幕服务的第二屏幕装置的信息可被包括在“Protocol Info”中。
图60示出第一方法。
第二屏幕服务的装置发现和装置能力交换的一个实施方式可包括执行用于第二屏幕服务的UPnP应用(s60001)、寻找UPnP装置(s60010)、寻找RemoteUIClient(s60020)、请求装置描述(s60030)、接收装置描述(s60040)、请求服务控制描述(s60050)、接收服务控制描述(s60060)、请求装置配置文件(s60070)、接收装置配置文件(s60080)、放置远程UI的URL(s60090)、发送响应1(s60100)、向RemoteUI客户机服务发送消息(s60110)、发送响应2(s60120)和/或用户点击屏幕上的按钮(s60130)。
执行用于第二屏幕服务的UPnP应用(s60001)、寻找UPnP装置(s60010)、寻找RemoteUIClient(s60020)、请求装置描述(s60030)、接收装置描述(s60040)、请求服务控制描述(s60050)、接收服务控制描述(s60060)、请求装置配置文件(s60070)、接收装置配置文件(s60080)、放置远程UI的URL(s60090)、发送响应1(s60100)、向RemoteUI客户机服务发送消息(s60110)、发送响应2(s60120)以及用户点击屏幕上的按钮(s60130)可分别等同于执行用于第二屏幕服务的UPnP应用(s40001)、寻找UPnP装置(s40010)、寻找RemoteUIClient(s40020)、请求装置描述(s40030)、接收装置描述(s40040)、请求服务控制描述(s40050)、接收服务控制描述(s40060)、请求装置配置文件(s40070)、接收装置配置文件(s40080)、放置远程UI的URL(s40090)、发送响应1(s40100)、向RemoteUI客户机服务发送消息(s40110)、发送响应2(s40120)以及用户点击屏幕上的按钮(s40130)。
在第一方法中，如图60所示，在寻找UPnP装置(s60010)之后，可利用从HTTP头获得的“X-ATSC-COMPANION-LOCATION”来通知支持第二屏幕服务的装置配置文件的位置。由X-ATSC-COMPANION-LOCATION:http://10.177.56.36:37900/ ATSC2ndScreenRemoteUIClient1.xml\r\n表示的部分是“X-ATSC-COMPANION-LOCATION”。接收机可忽略“LOCATION”头，而获得接收机所期望的第二屏幕装置的装置配置文件。
在上述第二方法中主装置检测能够提供第二屏幕服务的第二屏幕装置的方法当中，可在“LOCATION”头的位置获得装置配置文件，并且可在装置配置文件内解析并处理第二屏幕装置的“Protocol Info”的值。这可在RemoteUI服务器服务#1的广播信令的实施方式的请求UIListing(s52020)中执行。
在特定UPnP装置的装置描述符中，存在可提供装置的列表，并且可提供一个或多个服务。UPnP装置的各个服务可由另一远程UPnP装置来控制，并且可接收事件。只有当利用事件通知所提供的服务时才可接收事件。可通知URL，使得由UPnP装置提供的服务被控制并且生成事件。
图61是示出UPnP论坛的DeviceProfile XML模式的实施方式的示图。
在RemoteUI服务器服务#1的广播信令的实施方式中，请求UIListing(s52020)将被另外描述。该步骤可包括第二屏幕装置询问具有RemoteUI服务器服务的接收机是否存在适合于第二屏幕装置的UI。“InputDeviceProfile”应该为图61所示的XSD文件的格式。
因此，第二屏幕装置应该以图61的格式将关于其装置配置文件的信息发送给接收机。
图62是示出第二屏幕装置的装置配置文件的实施方式的示图。
在RemoteUI服务器服务#1的广播信令的实施方式中，请求UIListing(s52020)将被另外描述。图62示出装置配置文件的示例。在请求UIListing(s52020)中，诸如所示装置配置文件的信息可被发送给接收机。
通过确定第二屏幕装置期望检测到的装置配置文件的第二屏幕服务是否存在于接收机中，所示信息可被存储在“InputDeviceProfile”变量中并且可被发送。接收机可确认“InputDeviceProfile”信息以限定将要提供的服务类型、版本、第二屏幕装置的分辨率、可接收图像编码方法等。
图63是示出第二屏幕服务的Protocolnfo的描述的实施方式的示图。
在RemoteUI服务器服务#1的广播信令的实施方式中，请求UIListing(s52020)和发送UIListing(s52030)将被另外描述。
如上所述，接收机可确认“InputDeviceProfile”信息以限定将要提供的服务类型、版本、第二屏幕装置的分辨率、可接收图像编码方法等。“第二屏幕服务的Protocolnfo的描述”的一个实施方式可以是“InputDeviceProfile”信息的一个实施方式。
当所示信息被传送给接收机时(请求UIListing(s52020))，XML中的UILising信息被发送给第二屏幕装置(发送UIListing(s52030))。
如果RemoteUI服务器服务不支持期望的第二屏幕装置，则在发送UIListing(s52030)中，可返回错误信息以指示RemoteUI服务器服务无法支持第二屏幕服务。
图64是示出在第二屏幕装置中正执行AddUIListing和RemoteUIListing动作时的UIListing的实施方式的示图。
在RemoteUI服务器服务#1的广播信令的实施方式中，请求UIListing(s52020)和发送UIListing(s52030)将被另外描述。
在请求UIListing(s52020)之后，接收机可检测兼容RemoteUI信息并将其传送给请求第二屏幕装置(发送UIListing(s52030))。在发送UIListing(s52030)中接收的信息示出于图64中。
当所接收到的信息可从接收机被发送给第二屏幕时，TPT和AMP可被处理以插入TDO URL。因此，第二屏幕装置可仅从接收机获得关于远程UI的信息，并且可从家庭网络之外的互联网应用服务器下载并执行第二屏幕应用。此时，应用可通过第二屏幕服务应用来执行。
广播商可经由广播网络将用于第二屏幕装置的第二屏幕应用发送给接收机。在这种情况下，接收机可存储用于第二屏幕服务的应用并且直接提供所述应用。在这种情况下，web服务器可在接收机中操作，并且可从外部应用服务器(而非接收机或家庭网络)下载关联的图像和数据。如果DO是NDO，则可在ATSC-NRT中经由广播网络发送NDO和关联的资源文件，并且可提供第二屏幕服务。
在广播信令的情况下，第二屏幕应用的生命周期可由接收机或第二屏幕服务应用来管理。
首先，将描述在接收机处管理第二屏幕应用的生命周期的方法。
接收机可处理关于利用DTVCC发送的媒体时间触发的信息，然后当与第二屏幕关联的事件存在并且该事件被执行时，立即向家庭网络中的所有装置通知“UIListingUpdate”变量。订用该事件的装置可检查出UI信息已更新并且执行“GetCompatibleUIs”动作以便获得必要信息。此时，接收机的RemoteUI服务器可立即传送TDO地址。
其次，将描述在第二屏幕服务应用处管理第二屏幕应用的生命周期的方法。
在这种情况下，接收机可将所接收到的信息传送给第二屏幕装置，并且可执行第二屏幕服务应用。在广播的情况下，如果第二屏幕服务的客户机请求“GetComaptibleUIs”动作，则接收机可直接返回经由DTVCC接收的iTV消息(触发)的URIString，并且第二屏幕装置可利用所接收到的URIString下载TPT文件并解释TPT以类似于接收机来操作。每当利用DTVCC接收到媒体时间触发或事件时间触发时接收机可立即改变“UIListingUpdate”变量并且将改变的变量发送给所有装置，使得所述装置执行“GetCompatibleUIs”动作以接收iTV消息(触发)的新URIString。
图65是示出RemoteUI客户机服务的单播信令的实施方式的示图。
将描述单播信令。
在该方法中，第二屏幕装置中包括RemoteUIClient服务。如果UPnP装置首次连接到家庭网络，则该UPnP装置向其它装置通知新装置连接到家庭网络。作为另一方法，如果请求关于新装置的周期性通知的消息被传送给连接到家庭网络的所有装置，则连接到家庭网络的所有装置可响应于该信息将NOTIFY消息发送给所有装置。首先，应该确定第二屏幕装置是否支持第二屏幕服务。
RemoteUI客户机服务的单播信令的一个实施方式可包括UPnP装置和服务发现(s65010)、请求装置配置文件(s65020)、返回装置配置文件(s65030)、发送TDO URL信息(s65040)、返回HTTP消息(s65050)、发送显示消息(s65060)和/或返回HTTP消息(s65070)。
UPnP装置和服务发现(s65010)可等同于UPnP装置和服务发现(s52010)。
请求装置配置文件(s65020)可包括接收机将“StaticDeviceInfo”信息发送给新检测到的第二屏幕装置以便确定第二屏幕装置是否支持第二屏幕服务。
返回装置配置文件(s65030)是对请求装置配置文件(s65020)的响应，其获得第二屏幕装置的装置配置文件。如果确定由新检测到的第二屏幕装置发送的装置配置文件不匹配“Static DeviceInfo”或者新检测到的第二屏幕装置不支持第二屏幕服务，则第二屏幕服务可不开始。“StaticDeviceInfo”可等同于上面定义的“DeviceInfo”。接收机可确定“StaticDeviceInfo”是否匹配DeviceInfo。如果在家庭网络中新检测到的第二屏幕装置的数量是一个或更多个，则重复该处理。即使当所检测到的第二屏幕装置不支持第二屏幕服务时，也继续执行该处理。一个或更多个软件可被安装在第二屏幕装置中或从第二屏幕装置删除，该处理的结果值可根据用户是否执行软件而改变。如果第二屏幕服务应用已被执行，则可发送TDO URL信息(s65040)。
发送TDO URL信息(s65040)可包括接收机发送作为TPT和AMT的解析结果的TDOURL信息。可使用UPnP RemoteUI客户机服务中定义的“AddUIString”。“AddUIString”可以是在第二屏幕装置满足第二屏幕服务的DeviceInfo时执行的动作。TDO URL可包括一个或更多个URL。在一个或更多个URL的情况下，可发送用于立即执行的URL。此时，可选择性地发送显示消息(s65060)。
返回HTTP消息(s65050)可包括对发送TDO URL信息(s65040)的结果进行发送。类似于发送响应1(s40100)，可根据情况发送诸如HTTP/1.1 200 OK的响应。
发送显示消息(s65060)可包括将显示消息发送给第二屏幕装置。由于RemoteUI客户机服务具有能够在第二屏幕装置的屏幕上显示消息的DisplayMessage动作，所以可将TDO URL发送给第二屏幕装置，并且可利用DisplayMessage动作显示指示存在与当前观看的广播节目关联的第二屏幕应用的消息。如果用户确认该消息，则可立即执行第二屏幕应用。
返回HTTP消息(s65070)可包括将发送显示消息(s65060)的结果发送。类似于发送响应1(s40100)，可根据情况发送诸如HTTP/1.1 200 OK的响应。
图66是示出RemoteUI客户机服务的单播信令的实施方式的示图。
每当新UI的URL被添加到第二屏幕装置的UIListing时，第二屏幕服务应用可提供执行该新第二屏幕应用的环境。
图66的RemoteUI客户机服务的单播信令的一个实施方式示出终止所执行的第二屏幕应用并且执行新第二屏幕应用的处理。
RemoteUI客户机服务的单播信令的一个实施方式可包括发送RemoveUIListing动作(s66010)、返回HTTP消息(s66020)、发送显示消息(s66030)、返回HTTP消息(s66040)、发送TDO URL信息(s66050)、返回HTTP消息(s66060)、发送显示消息(s66070)和/或返回HTTP消息(s66080)。
发送RemoveUIListing动作(s66010)可包括利用RemoteUI客户机服务中定义的“RemoveUIListing”动作终止正在第二屏幕服务应用中执行的第二屏幕应用。当接收机终止使用UI的当前执行的应用时，第二屏幕服务应用可知道发送RemoveUIListing动作。因此，如果第二屏幕装置接收到RemoveUIListing动作，则第二屏幕服务应用应该立即终止当前执行的第二屏幕应用。
返回HTTP消息(s66020)可包括将发送RemoveUIListing动作(s66010)的结果发送。类似于发送响应1(s40100)，可根据情况发送诸如HTTP/1.1 200 OK的响应。
发送显示消息(s66030)可包括将显示消息发送给第二屏幕装置。在发送RemoveUIListing动作(s66010)之后，指示执行终止的消息可显示在第二屏幕装置的屏幕上。在这种情况下，可利用DisplayMessage动作将适当消息显示在屏幕上。
返回HTTP消息(s66040)可包括将发送显示消息(s66030)的结果发送。类似于发送响应1(s40100)，可根据情况发送诸如HTTP/1.1 200 OK的响应。
发送TDO URL信息(s66050)可包括执行AddUIListing动作，使得接收机发送将新执行的UI的TDO URL。当执行新第二屏幕应用时，TDO URL一被添加到UIListing，就可执行第二屏幕服务应用。作为参考，TDO URL涉及可从接收机直接下载并执行的第二屏幕应用，或者可仅从互联网服务器下载一些资源数据。另外，TDOURL可指示外部互联网服务器地址。如果TDO URL指示外部互联网服务器地址，则可从互联网服务器下载第二屏幕应用以及执行所需的所有数据。
返回HTTP消息(s66060)可包括将发送TDO URL信息(s66050)的结果发送。类似于发送响应1(s40100)，可根据情况发送诸如HTTP/1.1 200 OK的响应。
发送显示消息(s66070)可包括将显示消息发送给第二屏幕装置。在发送TDO URL信息(s66050)之后，指示提供新第二屏幕服务的消息可显示在第二屏幕装置的屏幕上。类似于发送显示消息(s66030)，可利用DisplayMessage动作将适当消息显示在屏幕上。
返回HTTP消息(s66080)可包括将发送显示消息(s66070)的结果发送。类似于发送响应1(s40100)，可根据情况发送诸如HTTP/1.1 200 OK的响应。
在单播信令的情况下，第二屏幕应用的生命周期可由接收机或第二屏幕服务应用管理。
首先，将描述在接收机处管理第二屏幕应用的生命周期的方法。
第二屏幕服务应用可仅知道“URL”(TDO_URL)信息。因此，接收机可针对第二屏幕装置中的RemoteUI客户机服务执行“AddUIListing”动作并且在预定时间在第二屏幕装置中执行第二屏幕应用。如果第二屏幕应用被终止，则可执行“RemoveUIListing”动作以在预定时间内终止第二屏幕应用。
如果除了URL以外还提供执行TDO的媒体时间信息以用于详细定时，则可在预定时间执行第二屏幕服务应用。然而，由于媒体时间是由接收机当前回放的媒体的相对时间，该时间需要被改变为各个装置能理解的绝对时间。可使用网络时间协议(NTP)或其它时间信息，并且可通过将具有未来时间信息的媒体时间添加到NTP或其它时间信息来获得执行动作的时间。在第二屏幕装置中，由于动作包括执行和终止，所以这可根据AddUIListing和RemoveUIListing动作的实现方式而改变。
其次，将描述在第二屏幕服务应用处管理第二屏幕应用的生命周期的方法。
第二屏幕服务应用应该知道关于在第二屏幕装置中执行和终止第二屏幕应用时的事件或时间的信息。因此，如上所述，第二屏幕服务应用包括触发客户机，接收机可根据接收机的DeviceInfo(装置配置文件)发送利用DTVCC接收的iTV消息(触发)信息的URIString。
传输方法可大体分为两种方法：没有改变地发送利用DTVCC发送并由接收机处理的触发消息的第一方法以及在接收机处仅收集第二屏幕装置所需的信息并且仅以XML传送必要信息和数据的第二方法。
首先，将描述在接收机处将触发没有改变地传送给第二屏幕装置的方法。
该方法可通过针对所接收到的触发执行“AddUIListing”动作来完成。RemoteUI客户机服务可将该信息传送给触发客户机，触发客户机可像接收机中一样下载并处理TPT。每当利用DTVCC接收到媒体时间触发时，接收机应该将媒体时间触发传送给第二屏幕装置。接收机可确认“appID”、“eventID”和“event@destination”，并且如果第二屏幕装置不需要接收触发，则可不将触发传送给第二屏幕装置。
其次，将描述在接收机处过滤并传送第二屏幕装置所需的触发信息的方法。
在该方法中，接收机可处理TPT文件和触发，并且生成并传送将由第二屏幕装置处理的数据。即使当触发客户机没有在第二屏幕服务应用中操作时也可执行该方法，并且可经由“ProgressInput”动作发送并处理XML文件。即，第二屏幕服务应用不处理整个TPT，而是仅处理由接收机过滤的当前或未来处理所需的数据。该方法的优点在于还可传送“Event@Data”字段。
图67是示出RemoteUI客户机服务的单播信令的实施方式的示图。
图67示出上述第二方法，即，在接收机处过滤并传送第二屏幕装置所需的触发信息的方法。
RemoteUI客户机服务的单播信令的一个实施方式可包括发送事件1信息(s67010)、返回HTTP消息(s67020)、发送事件2信息(s67030)、返回HTTP消息(s67040)、发送事件3信息(s67050)和/或返回HTTP消息(s67060)。
发送事件1信息(s67010)可包括接收机将所接收到的事件信息发送给第二屏幕。如上所述，接收机可处理可处理TPT文件和触发，并且生成并传送将由第二屏幕装置处理的数据。在第二屏幕服务应用中，触发客户机可不操作，并且可经由“ProgressInput”动作接收并处理XML文件。
返回HTTP消息(s67020)可包括将发送事件1信息(s67010)的结果发送。类似于发送响应1(s40100)，可根据情况发送诸如HTTP/1.1 200 OK的响应。
发送事件2信息(s67030)可包括发送关于事件的信息，类似于发送事件1信息(s67010)。像TPT XML中一样，可根据事件将数据传送给TDO。在该步骤中，可传送关于事件2的信息。
返回HTTP消息(s67040)可包括将发送事件2信息(s67030)的结果发送。类似于发送响应1(s40100)，可根据情况发送诸如HTTP/1.1 200 OK的响应。
类似地，发送事件3信息(s67050)可包括发送关于事件3的信息。
返回HTTP消息(s67060)可包括将发送事件3信息(s67050)的结果发送。类似于发送响应1(s40100)，可根据情况发送诸如HTTP/1.1 200 OK的响应。
在上述第二方法中，接收机可管理第二屏幕应用的生命周期。第二屏幕应用的生命周期可意指解析并处理第二屏幕装置的TPT和AMT信息的处理。
图68是示出通过ProcessInput动作传送给第二屏幕装置的“EventInfo”信息的实施方式的示图。
图68示出在接收机处过滤并传送第二屏幕装置所需的触发信息的上述方法中接收机处理TPT文件和触发并且生成并传送将由第二屏幕装置处理的数据时的事件信息的XML数据结构的示例。
即，如果接收机管理第二屏幕应用的生命周期，则可利用processInput动作经由具有图68的数据结构的XML文件将事件信息传送给RemoteUI客户机。即使当接收机接收到实时触发时，类似地，也可处理实时触发，并且可仅将关于执行时间和TDO URL的信息传送给第二屏幕装置。
在图68的表中，@appID、URL、Event、@eventID、@action和Data可等同于关于由接收机接收的触发或AMT的信息。然而，“@mediaTime”、“@startTime”和“@endTime”可由接收机特殊处理。根据“@mediaTime”，利用DTVCC发送的触发的“time＝”句法的信息(或者AMT的“@beginMT”信息)可被处理以再次确定“@startTime”和“@endTime”。由于接收机和第二屏幕装置可能没有使用相同的绝对时间信息(挂钟时间)，所以第二屏幕装置可根据内容的媒体时间来操作。即，如果假设在接收机与第二屏幕装置之间根据实际NTP设定诸如动作的执行开始时间和结束时间的时间信息，则可由接收机在传输之前执行转换操作。
将描述传输延迟和媒体时间估计。
如上所述，由于在从接收机发送至第二屏幕装置时基于当前mediaTime值相对地创建并发送@startTime和@endTime，所以传输时产生的时间损失可以是HTTP头和HTTP响应的“Date”值。利用到达时间值的差异，第二屏幕装置可寻找更准确的时间值。由于当前媒体时间与@mediaTime之差是传输延迟时间，所以当前媒体时间可通过下式获得。
当前媒体时间＝传输延迟时间(接收时的时间值–HTTP头“Date”值)+@mediaTime
因此，可估计当前接收机的当前媒体时间值。
图69是示出接收机与第二屏幕装置之间的配置的示图。
示出了接收机与第二屏幕装置之间的配置。接收机可以是受控装置(服务器)。第二屏幕装置可以是控制点(客户机)。
在发现步骤中，接收机可多播服务列表并且加入网络，第二屏幕应用可多播对服务列表的请求并启动。
在描述步骤中，第二屏幕应用可请求接收机的服务描述。
在本发明中，可定义新UPnP装置和服务以便基于UPnP经由第二屏幕装置获取与经由TV机(即，接收机)接收的A/V广播内容关联的交互服务。
图70是示出服务的服务类型和服务ID的实施方式的示图。
接收机可支持触发服务、双向通信服务和AppURL服务。它还可支持HTTP代理服务器服务。服务类型和服务ID示出于图70中。
双向通信服务可允许第二屏幕装置确定是否有准备参与与第二屏幕装置中的应用的双向通信的DO在由主装置执行。
触发服务、AppURL服务和HTTP代理服务器服务将在下面描述。
图71是示出触发传送服务的操作概念的示图。
触发传送服务可意指基于UPnP经由第二屏幕装置获取与经由TV接收机接收的A/V广播内容关联的交互服务的服务。
图71示出在接收机处从DTVCC或ACR服务器获取触发并且将触发没有改变地或者在将触发改变(扩展)为适合于第二屏幕装置的格式的状态下发送给第二屏幕装置的处理。
每当触发改变时，应该从接收机向第二屏幕装置实时地发送触发或扩展触发。
图72是示出生成扩展激活触发的处理的实施方式的示图。
可通过将从DTVCC流或ACR服务器获取的触发与TPT中的信息组合来生成扩展触发(扩展激活触发)。可通过将包括在触发中的TDO ID和Event ID、Data ID和Activationtime与TPT中的TDO URL、TDO attributes、Event、Action、Diffusion和data组合来生成扩展触发。TDO中的信息可以是关于TDO的信息以及与触发中的信息关联的事件。
这里，扩展触发可被称作增强触发。
图73是示出增强激活触发的XML模式描述的实施方式的示图。
将描述触发服务的规范。
触发服务可传送触发。可由TV机从(a)ACR处理、(b)当前观看的信道的DTV CC服务#6、(c)远程“实时触发”服务器或者(d)激活消息表(AMT)获取触发。其可取决于情况。
触发服务还可每当信道被改变时传送特殊“信道改变”触发。信道改变触发将在下面描述。可基本上存在将要传送的四种类型的触发，1)TDO交互服务模型的时基触发、2)TDO交互服务模型的激活触发、3)直接执行交互服务模型的触发以及4)特殊“信道改变”触发。
为了最大灵活性，可为可取的是具有将所有类型的触发传送给第二屏幕装置的选项并且它们一到达接收机就传送它们。
然而，对于被设计为按照与接收机提供交互几乎相同的方式提供交互的第二屏幕应用，可为可取的是省略TDO交互模型的时基触发并且在其激活时间传送TDO交互模型的各个激活触发。这可使这些第二屏幕应用免于维持时基并计算激活时间的需要。还可为可取的是通过将来自触发的信息与来自关于触发中参考的TDO元素及其Event子元素的TPT的信息组合来增强各个激活触发，从而使这些第二屏幕应用免于应对TPT的需要。
因此，触发服务可为触发传送提供两个选项。其中一个可以是接收机传送所有触发(没有增强)的“未过滤流”选项。另一个可以是仅传送TDO交互模型的增强激活触发、TDO交互模型以外的交互模型的所有触发以及特殊信道改变触发的“过滤流”选项。
TDO交互模型的各个增强激活触发的目标传送时间可为其激活时间。所有其它触发(包括在未过滤流选项中在没有增强的情况下传送的激活触发)的目标传送时间可以是它们被接收机接收的时间。各个特殊信道改变触发的目标传送时间可以是信道改变的时间。
触发服务的目标传送格式可分为增强激活触发的传送格式以及所有其它触发的传送格式。
图73示出增强激活触发的传送格式。所有其它触发的传送格式将在下面描述。
增强激活触发的传送格式可包括@interactionModel、@appURL和/或@cookieSpace属性以及Capabilities和/或Event元素。
Event元素可包括@action、@destination、@diffusion和/或@data属性。
字段的语义如下。
@interactionModel属性的值可以是与触发关联的交互模型的数码，其使用与用于传送触发的DTVCC信道的服务#6中的SDOPrivateData命令中的cmdID字段相同的编码。在本发明的一个实施方式中，所述数码可以使用与用于传送触发的DTV CC信道的服务6中的URLString命令中的URI_data()结构中的URI_type字段相同的编码。URI_data()的句法将在下面描述。
@appURL属性的值可以是由触发中的event(“e＝”)项标识的TPT TDO元素的第一URL子元素的值。
每当由触发中的event(“e＝”)项标识的TPT TDO元素包含@cookieSpace属性时可存在@cookieSpace属性，它可具有与该属性相同的值。
每当由触发中的event(“e＝”)项标识的TPT TDO元素包含Capabilities元素时可存在Capabilities元素，它可与该元素相同。
Event元素可表示由触发中的event(“e＝”)项标识的Event元素。(严格地讲，触发中的event项标识TPT中的TDO元素以及该TDO元素中的Event子元素。这在这里被称为由触发中的event项标识的Event元素。)
@action属性的值可与由触发中的event(“e＝”)项标识的Event元素的action属性的值相同。
每当由触发中的event(“e＝”)项标识的Event元素包含destination属性时可存在@destination，它可具有与该属性相同的值。在本发明的一个实施方式中，每当由触发中的“e＝”项标识的TDO元素包含destination属性时可存在@destination属性。
每当由触发中的event(“e＝”)项标识的Event元素包含diffusion属性时可存在@diffusion属性，它可具有与该属性相同的值。在本发明的一个实施方式中，每当由触发中的“e＝”项标识的TDO元素包含diffusion属性时可存在@diffusion属性。
每当Event元素的Data子元素由触发中的(“e＝”)项标识时可存在@data属性，它可具有与该元素相同的值。
如上所述，可通过将TPT中的信息与从DTVCC流或ACR服务器获取的触发组合来生成增强触发。
如上所述，扩展触发也可被称为增强触发。
图74是示出URI_data()的句法的实施方式的示图。
图74的URI_data()可以是在以上AugmentedTrigger的@interactionModel属性的详细描述中提及的URI_data()。
URI_data()结构可包括URI_type和/或多个URI_charaters。另外，URI_data()结构可包括预留比特。
URI_type(可为4比特无符号整数)可指示命令中承载的URI的类型。URI_type的含义可如图75所示。接收机会不管指示未识别类型的URIString命令的实例。当在两个片段中发送URI时，在两个片段中URI_type字段可相同。
URI_character可为8比特ASCII字符，其值被限制为统一资源标识符(URI)允许的那些。如果URI在两个片段中发送，则在重组之后通过URI_character值的序列形成的字符串可为有效URI。
图75是示出URI_type的含义的实施方式的示图。
图75的URI_type的含义可以是在以上URI_data()的句法的URI_data()的详细描述中提及的URI_type的含义。
当URI_type为0时，URI_type可意指URI_data()与交互TV触发关联。
当URI_type为1时，URI_type可意指URI_data()与服务使用报告服务器(SURS)定位符关联。
当URI_type为2-15时，URI_data()的类型不确定，可为未来使用而预留。
图76是示出未增强的触发的XML模式描述的实施方式的示图。
这可以是未增强的触发的XML格式。上述特殊“信道改变”触发也可遵循该格式。
未增强的触发的XML模式描述的一个实施方式可包括@interactionModel属性和/或@triggerString属性。
字段的语义如下。
对于特殊“信道改变”触发，@interactionModel属性无法存在。对于其它触发，interactionModel可存在，其值可以是与触发关联的交互模型的数码，该数码使用与DTVCC信道中的SDOPrivateData命令中的cmdID字段相同的编码。在本发明的一个实施方式中，所述数码可使用与DTV CC信道的服务6中的URLString命令中的URI_data()结构中的URI_type字段相同的编码。从实时触发服务器获取或者从AMT传送的触发的@interactionModel可被认为是TDO模型。
@triggerString属性的值可以是触发的字符串表示。触发的字符串表示在触发句法中描述。然而，特殊“信道改变”触发可能是不同的。特殊“信道改变”触发的@triggerString属性可具有值“**<major_num>.<minor_num>”，其中<major_num>可以是新信道的原始主信道号(当它被TV台广播时)，<minor_num>可以是新信道的原始次信道号(当它被TV台广播时)。如果信道号未知，则<major_num>和<minor_num>值可均为“0”。
图77是示出增强激活触发的格式的实施方式的示图。
这可以是上述增强触发的格式的另一实施方式。
@cookieSpace、Capabilities、Event、@action、@destination、@diffusion和@data上面已描述。
@activationTime可以是媒体时间尺度上的激活时间。
@tdoURL可等同于上述@appURL。
图78是示出增强激活触发的格式的实施方式的示图。
这可以是上述增强触发的格式的另一实施方式。
@activationTime、@tdoURL、@cookieSpace、Capabilities、Event、@action、@destination、@diffusion和@data上面已描述。
@availInternet和@availBroadcast可来自TPT。@availInternet和@availBroadcast上面已描述。
图79是示出增强激活触发的格式的实施方式的示图。
这可以是上述增强触发的格式的另一实施方式。
@activationTime、@tdoURL、@cookieSpace、Capabilities、Event、@action、@destination、@diffusion和@data上面已描述。
ContentItem元素、@updatesAvail、@pollPeriod、@size、@availInternet和@availBroadcast属性可等同于当生成增强触发时TPT的元素和属性。ContentItem元素、@updatesAvail、@pollPeriod、@size、@availInternet和@availBroadcast上面已描述。
图80是示出增强激活触发的格式的实施方式的示图。
这可以是上述增强触发的格式的另一实施方式。
@cookieSpace、@availInternet、@availBroadcast、Capabilities、ContentItem、@updatesAvail、@pollPeriod、@size、@availInternet、@availBroadcast、Event、@action、@destination和@data上面已描述。
TDO元素中的@appID、@appType、@appName、@globalId、@appVersion、@frequencyOfUse、@expireDate、@testTDO、URTL以及ContentItem元素中的URL可等同于当生成增强触发时TPT的元素和属性。TDO元素中的@appID、@appType、@appName、@globalId、@appVersion、@frequencyOfUse、@expireDate、@testTDO、URL以及ContentItem元素中的URL将在下面描述。
图81是示出根据基于HTTP长轮询的方法的触发服务状态变量的实施方式的示图。
这里，可存在多种方法来支持触发服务。所述多种方法可包括基于HTTP长轮询的方法和基于UPnP事件触发机制的方法。
以下将描述基于HTTP长轮询的方法。
在基于HTTP长轮询的方法中，触发服务可具有一个状态变量。
TrigServerURL状态变量的值可以是将由客户机使用以检索触发的URL，没有协议项。
可利用HTTP请求或WebSocket请求来作出检索触发的请求。当作出HTTP请求(利用前面带有协议项http://的TrigServerURL)时，服务器可在HTTP长轮询传送模式下响应。当作出WebSocket请求(利用前面带有协议项“ws://”的TrigServerURL)时，服务器可在WebSocket传送模式下响应。
如果请求URL不包含查询项，或者如果它包含查询项“？level＝unfilter”，则服务器可在未过滤流选项下响应。如果请求URL包含查询项“？level＝filter”，则服务器可在过滤流选项下响应。
当在未过滤流选项下传送触发时并且当针对TDO模型以外的交互模型传送触发时，响应主体可具有符合图76所表示的XML模式的XML文档的形式。
当在过滤流选项下传送激活触发时，响应主体可具有符合图73所表示的XML模式的XML文档的形式。
图82是示出根据基于HTTP长轮询的方法的触发服务动作的实施方式的示图。
在基于HTTP长轮询的方法中，触发服务可具有单个动作，GetTrigServerURL动作。GetTrigServerURL动作可由客户机用来得到TrigServerURL的值。
图83是示出根据基于HTTP长轮询的方法的GetTrigServerURL动作的参数的实施方式的示图。
TrigServerURL输出参数可以是TrigServerURL状态变量的当前值。
根据本实施方式，第二屏幕应用可利用GetTrigServerURL动作来获取将由客户机使用以检索触发的URL。
图84是示出触发服务状态变量的实施方式的示图。
图84所示的实施方式可以基于以UPnP事件触发机制为基础的方法。
以下将描述基于UPnP事件触发机制的方法。
触发服务状态变量的一个实施方式可定义所示的触发服务状态变量。触发服务可具有图84中所列的状态变量。
LatestUnfilteredTrigger状态变量的值可表示未过滤流中具有最近目标传送时间的触发。该状态变量的格式可以是符合图76中所描述的模式的XML文档。
LatestFilteredTrigger状态变量的值可表示过滤流中具有最近目标传送时间的触发。当它是激活触发时，它可通过将激活触发中的信息与TPT中的信息组合以生成符合图73中所描述的表所表示的XML模式的XML文档来增强。当它是具有TDO以外的交互模型的触发时，它可具有符合图76中所描述的模式的XML文档的形式。当它是特殊信道改变触发时，如之前所述，格式可为“**<major_num>.<minor_num>”。
UnfilteredTriggerDeliveryTime状态变量的值可以是未过滤流中具有最近目标传送时间的触发的传送时间。“dateTime”数据类型可以是表示自1970年1月1日00:00:00以来的毫秒数的数字。
FilteredTriggerDeliveryTime状态变量的值可以是过滤流中具有最近目标传送时间的触发的传送时间。
图85是示出触发服务动作的实施方式的示图。
图85所示的实施方式可以基于以UPnP事件触发机制为基础的方法。
动作可被定义为使得第二屏幕装置或接收机任意读取触发服务状态变量的值。
在基于UPnP事件触发机制的方法中，触发服务动作可定义GetLatestUnfilteredTrigger和GetLatestFilteredTrigger动作。
图86是示出GetLatestUnfilteredTrigger动作的参数的实施方式的示图。
图86所示的实施方式可以基于以UPnP事件触发机制为基础的方法。
LatestUnfilteredTrigger输出参数的值可为LatestUnfilteredTrigger状态变量的值。
第二屏幕应用可利用GetLatestUnfilteredTrigger动作获得LatestUnfilteredTrigger状态变量(即，未过滤流中具有最近目标传送时间的触发)的值。
图87是示出GetLatestFilteredTrigger动作的参数的实施方式的示图。
图87所示的实施方式可以基于以UPnP事件触发机制为基础的方法。
LatestFilteredTrigger输出参数的值可为LatestFilteredTrigger状态变量的值。
第二屏幕应用可利用GetLatestFilteredTrigger动作获得LatestFilteredTrigger状态变量(即，过滤流中具有最近目标传送时间的触发)的值。
图88是示出基于UPnP事件触发机制的方法的实施方式的示图。
基于UPnP事件触发机制的方法的实施方式可包括接收触发(s88010)、改变UnfilteredTriggerDeliveryTime(s88020)、传送异步通知(s88030)、使用GetLatestUnfilteredTrigger动作(s88040)、以非增强触发响应(s88050)、接收激活触发(s88060)、改变FilteredTriggerDeliveryTime(s88070)、传送异步通知(s88080)、使用GetLatestFilteredTrigger动作(s88090)和/或以增强激活触发响应(s88100)。
在图88中，接收机可以是上述接收机。第二屏幕装置#1可以是支持“未过滤流选项”的第二屏幕装置。第二屏幕装置#2可以是支持“过滤流选项”的第二屏幕装置。
接收触发(s88010)可以是接收机如上所述通过DTVCC信道、ACR处理或广播商交互TV(iTV)服务器接收触发的步骤。在这种情况下，接收的触发可以是所有非增强类型的触发。
改变UnfilteredTriggerDeliveryTime(s88020)可以是改变上述UnfilteredTriggerDeliveryTime状态变量的步骤。
传送异步通知(s88030)可基于上述“事件触发”协议来执行。第二屏幕应用可订用触发服务的“事件触发”特征。
使用GetLatestUnfilteredTrigger动作(s88040)可以是使用上述GetLatestUnfilteredTrigger动作以使得第二屏幕应用获取触发的步骤。
以非增强触发响应(s88050)可以是响应于GetLatestUnfilteredTrigger动作发送非增强触发的步骤。第二屏幕应用可利用GetLatestUnfilteredTrigger动作在适当时间获取适当触发。
接收激活触发(s88060)可以是接收机如上所述通过DTVCC信道、ACR处理或广播商交互TV(iTV)服务器接收激活触发的步骤。
改变FilteredTriggerDeliveryTime(s88070)可以是改变上述FilteredTriggerDeliveryTime状态变量的步骤。
传送异步通知(s88080)可与上述传送异步通知(s88030)相同。
使用GetLatestFilteredTrigger动作(s88090)可以是第二屏幕应用使用上述GetLatestFilteredTrigger动作以便获取触发的步骤。
以增强激活触发响应(s88100)可以是响应于GetLatestFilteredTrigger动作发送增强激活触发的步骤。第二屏幕应用可利用GetLatestFilteredTrigger动作在适当时间获取适当触发。
图89是示出触发服务状态变量的实施方式的示图。
支持上述触发服务的多种方法除了基于HTTP长轮询的方法和基于UPnP事件触发机制的方法以外还可包括其它实施方式。以下将参照图89和图90描述这些实施方式。
在本实施方式中，触发服务状态变量可与图89中相同。
CurrentTrigger状态变量的值可取决于以下三种情形中的哪一种起作用。1)不存在与主屏幕上当前观看的节目关联的交互附属数据服务。2)存在与主屏幕上当前观看的节目关联的交互附属数据服务并且它具有直接执行交互模型。3)存在与主屏幕上当前观看的节目关联的交互附属数据服务并且它具有TDO交互模型。
在情况(1)中，CurrentTrigger状态变量的值可为空串。
在情况(2)中，CurrentTrigger状态变量的值可以是由TV机针对主屏幕上当前观看的节目接收的最近触发。
在情况(3)中，CurrentTrigger状态变量的值可以是由TV机针对主屏幕上当前观看的节目接收的激活触发当中的最近激活的激活触发的增强形式。(即，当其激活时间到来时激活触发可成为CurrentTrigger状态变量的基础，它可一直是所述基础，直至另一激活触发到达其激活时间。)激活触发的增强形式可通过将激活触发中的信息与TPT中的信息组合来获得。所述增强形式可等同于上述增强触发格式之一。
CurrentTrigger状态变量的定义可暗示对于TDO交互模型，在触发激活时间将激活触发传送给UPnP客户机。
在触发服务状态变量的另一实施方式中，每当触发改变时，为了实时地将触发或扩展触发从接收机发送至第二屏幕装置，ATSCTrigger和ATSCExpandedTrigger可被定义为状态变量。
ATSCTrigger状态变量可包含对从DTVCC流或ACR服务器接收的触发的引用(URI的形式)。该变量可包括TPT(TDO参数表)的URL、TDO ID、事件ID、数据ID、媒体时间、内容ID、目标事件的激活时间等。
ATSCExpandedTrigger状态变量可包含与第二屏幕装置的TDO关联的元数据(XML分段的形式)。该元数据可从接收自DTVCC流或ACR服务器的TPT和触发二者提取。该变量可具有与图80的实施方式相同的XML模式。
当接收机基于UPnP的事件触发机制改变状态变量时，可实时地获取上面定义的ATSCTrigger和ATSCExpandedTrigger的改变的值。
图90是示出触发服务动作的实施方式的示图。
在ATSCTrigger和ATSCExpandedTrigger被定义为状态变量的上述触发服务状态变量的另一实施方式中，将描述触发服务动作。
即使在此实施方式中，动作也可被定义为使得第二屏幕装置或接收机任意写入或读取ATSCTrigger和ATSCExpandedTrigger的值。
SetTrigger()动作可允许使用ATSCTrigger的值。CurrentTrigger可为参数。
SetExpandedTrigger()动作可允许使用ATSCExpandedTrigger的值。CurrentTrigger可为参数。
GetTrigger()动作可允许读取ATSCTrigger的值。CurrentTrigger可为参数。
GetExpandedTrigger()可允许读取ATSCExpandedTrigger的值。CurrentTrigger可为参数。
图91是示出当经由触发传送服务获取触发时第二屏幕上的操作的实施方式的示图。
可示出第二屏幕装置如何根据经由触发传送服务从第二屏幕装置接收的触发或扩展激活触发中包括的动作信息进行操作。
可经由触发传送服务获取执行/终止动作的触发。
第二屏幕装置可经由触发传送服务获取执行/终止动作的触发并且将目标TDO的URL以及来自所获取的触发的关联信息传送给DAE/浏览器。浏览器可执行包括在触发中的动作(例如，执行或终止)。
图92是示出触发传送服务的操作概念的示图。
可示出第二屏幕装置如何根据经由触发传送服务从第二屏幕装置接收的触发或扩展激活触发中包括的动作信息进行操作。
第二屏幕装置可经由触发传送服务获取触发事件动作的触发，然后从所获取的触发提取诸如Data ID的信息。随后，可利用AJAX将数据传送给当前执行的TDO。TDO可根据所接收到的数据执行适当操作。
在ATSCTrigger和ATSCExpandedTrigger被定义为状态变量的上述触发服务状态变量的另一实施方式中，将描述触发传送服务的操作概念。
在此实施方式中，在直接执行模型的情况下，如果经由DTVCC流或ACR服务器接收的触发中包括内容id(即，“c＝”)，则接收机可将所接收到的时基触发值设定为ATSCTrigger状态变量的值。当时基触发到达接收机时，状态变量的值可经由SetTrigger动作被立即改变或者可被传送给第二屏幕装置。
在本实施方式中，在TDO模型的情况下，如果经由DTVCC流或ACR服务器接收的触发中包括内容id(即，“c＝”)，则接收机接收激活触发，然后提取并组合来自TPT的关联信息和触发信息以生成扩展触发。随后，在扩展触发的激活时间(或之前)，ATSCExpandedTrigger状态变量的值可经由SetExpandedTrigger动作被设定或传送给第二屏幕装置。
图93是示出根据第一方法的双向通信服务状态变量的实施方式的示图。
双向通信服务可允许客户机装置确定是否有准备参与与第二屏幕装置中的应用的双向通信的DO在主装置中执行。
双向通信服务可允许客户机装置从在接收机中执行的DO接收双向通信。为了支持它，可存在两种不同的方法。
以下将描述实现双向通信服务的第一方法。
首先，当客户机装置签约时，它可提供WebSocket服务器(通常在客户机装置上)的IP地址和TCP端口。当DO想要与客户机装置通信时，它可利用当客户机装置签约时提供的地址和端口来建立与客户机装置的WebSocket连接。
在第一方法中，双向通信服务可具有图93所示的状态变量。
ClientList状态变量可以是已针对双向通信签约的客户机的列表。并且Name、IPAddress和Port可意指各个客户机的名称、IP地址和TCP端口。
图94是示出根据第一方法的ClientList状态变量的XML模式表的实施方式的示图。
ClientList可以是符合图94中的表所描述的XML模式的XML文档的形式。
Name状态变量可以是针对双向通信签约的客户机的名称。
IPAddress状态变量可以是针对双向通信签约的客户机的WebSocket服务器的IP地址。
TCPPort状态变量可以是针对双向通信签约的客户机的WebSocket服务器的TCP端口。
图95是示出根据第一方法的触发服务动作的实施方式的示图。
在第一方法中，双向通信服务可具有如图95中的表所描述的两个动作。
SignUp动作可由客户机用来指示它对参与双向通信感兴趣并且提供建立连接所使用的名称和IP地址和端口。
SignOff动作可由客户机用来指示它不再对参与双向通信感兴趣。
图96是示出根据第一方法的SignUp动作的参数的实施方式的示图。
Name输入参数可以是与签约的客户机关联的名称。它可以是装置的主机名称。它可不同于已经签约的任何其它客户机的Name。
IPAddress输入参数可以是将由DO在建立连接时使用的WebSocket服务器的IP地址。
TCPPort输入参数可以是将由DO在建立连接时使用的WebSocket服务器的TCP端口。
图97是示出根据第一方法的SignOff动作的参数的实施方式的示图。
Name输入参数可以是客户机在针对双向通信服务签约时提供的名称。其目的可以是标识现在正注销的客户机。
图98是示出根据第二方法的双向通信服务状态变量的实施方式的示图。
以下将描述实现双向通信服务的第二方法。
当主装置中有这样的DO在执行时，第二屏幕装置中的应用可请求TCP/IP连接，其指示第二屏幕装置中的应用也准备参与双向通信。连接的第二屏幕装置方的TCP/IP地址和端口可用作第二屏幕装置的唯一标识符。可经由TCP/IP连接在第二屏幕装置与主装置中的DO之间自由地来回发送字节。
双向通信服务可具有图98所示的两个状态变量。
ConnectionAddress状态变量可包含来自第二屏幕装置的连接请求应该指向的IP地址和TCP端口，为<address>:<port>的格式。
Status状态变量可告知是否有准备参与与第二屏幕装置的双向通信的DO在执行，“true”表示有这样的DO在执行，“false”表示没有这样的DO在执行。
在本发明的一个实施方式中，Status状态变量的数据类型可以是“string”。在此实施方式中，Status状态变量的可能值可为“Yes”和“No”。
在第二方法中，双向通信服务可不具有任何动作。
图99是示出根据第二方法的onBytesReceived函数的实施方式的示图。
以下将描述由主装置中的DO用来发送和接收消息的API。
以下API可允许在主装置中执行的DO利用双向通信服务参与与在第二屏幕装置中运行的应用的双向通信。
每当DO终止时TV接收机可将双向通信服务的UPnP“Status”状态变量设定为“false”，以使得新DO可在通信之前主动将它设定为“true”。
当上述“Status”状态变量的数据类型为string时，每当DO开始执行时TV接收机可将UPnP状态变量“Status”设定为“No”，使得DO必须在通信之前主动将它设定为“Yes”。
新的性质onBytesReceived函数可被添加到NetworkInterface类。
onBytesReceived函数是回调函数，它可在经由双向通信服务针对DO接收到字节时被调用。可定义两个参数“address”和“bytes”。
“address”可以是包含所接收到的字节的发送方的IP地址和UDP端口的字符串，为<address>:<port>的格式。
“bytes”可以是表示所接收到的字节的字符串。在一些实施方式中，可不包括UDP和/或IP头。
图100是示出根据第二方法的setStatusYes()的实施方式的示图。
新方法setStatusYes()可被添加到NetworkInterface类。
setStatusYes()可将双向通信服务的UPnP Boolean状态变量“Status”的值设定为“true”，指示DO准备参与通信。
setStatusYes()可不具有任何参数。
图101是示出根据第二方法的setStatusNo()的实施方式的示图。
新方法setStatusNo()可被添加到NetworkInterface类。
setStatusNo()可将双向通信服务的UPnP Boolean状态变量“Status”的值设定为“false”，指示DO没有准备参与通信。
setStatusNo()可不具有任何参数。
图102是示出根据第二方法的setStatus()的实施方式的示图。
当上述“Status”状态变量的数据类型为string时，setStatus()可被添加到NetworkInterface类。
setStatus()可设定双向通信服务的UPnP状态变量“Status”的值。
setStatus()可具有State参数。
如果DO能够参与与第二屏幕装置的双向通信则state参数可被设定为“Yes”，否则被设定为“No”。
图103是示出根据第二方法的sendBytes()的实施方式的示图。
新方法sendBytes()可被添加到NetworkInterface类。
sendBytes()可利用双向通信服务来发送字节。
sendBytes()可具有两个参数address和bytes。
“address”参数可表示字节的目的地TCP/IP地址和端口，为<address>:<port>的格式。
“bytes”参数可表示将要发送的字节。
图104是示出AppURL服务状态变量的示图。
AppURL服务可允许第二屏幕装置确定与当前执行的DO关联的第二屏幕应用的基本URL和名称。
UPnP AppURL服务可具有两个状态变量AppURL和AppName。
AppURL状态变量的值可以是与当前执行的DO关联的第二屏幕应用的基本URL。当没有与第二屏幕应用关联的DO在第一屏幕装置上执行时，AppURL状态变量的值可为空串。
AppName状态变量的值可以是与当前执行的DO关联的第二屏幕应用的名称。当没有与第二屏幕应用关联的DO在第一屏幕装置上执行时，AppName状态变量的值可为空串。
图105是示出AppURL服务动作的示图。
AppURL服务可具有一个动作GetAppURL。
图106是示出GetAppURL动作的参数的示图。
GetAppURL动作可具有两个参数AppURL和AppName。
AppURL输出参数可以是AppURL状态变量的当前值。并且AppName输出参数可以是AppName状态变量的当前值。
因此，可经由GetAppURL动作获得AppURL状态变量的当前值和AppName状态变量的当前值。
图107是示出代理HTTP服务器服务的操作概念的示图。
接收机可支持代理HTTP服务器服务。代理HTTP服务器服务可表示如果第二屏幕装置经由广播网络发送TDO/文件，则经由TV接收机获取TDO/文件的服务。
示出代理HTTP服务器服务的操作概念的示图可包括广播系统107010、ACR服务器107020、广播商ATSC 2.0iTV服务器107030、ATSC 2.0接收机107040和/或第二屏幕装置107050。
广播系统107010可等同于广播系统42010。
ACR服务器107020可等同于ACR服务器42020。
广播商ATSC 2.0iTV服务器107030可等同于广播商ATSC 2.0 iTV服务器42030。
ATSC 2.0接收机107040可接收与广播A/V和交互服务关联的触发，利用该触发获取交互服务，并且在屏幕上提供交互服务。这可等同于上述接收机。代理HTTP服务器服务可使得ATSC 2.0接收机107040能够执行与代理服务器相似的功能，以便有效地将第二屏幕装置所请求的文件提供给第二屏幕装置。
第二屏幕装置107050可等同于第二屏幕装置42050。
代理HTTP服务器服务可使得接收机能够经由第二屏幕装置通过互联网访问广播流或文件，并且使得第二屏幕装置能够访问经由广播流发送的内容。如果多个第二屏幕装置经由互联网访问相同文件，则可使第二屏幕装置对相同文件的访问最小化。
图108是示出代理服务器服务状态变量的实施方式的示图。
UPnP代理服务器服务可提供HTTP代理服务器，以允许第二屏幕装置经由FLUTE会话访问在广播中传送给TV接收机的文件，并且在住户中的多个第二屏幕装置同时检索相同的文件的情况下使得第二屏幕装置更有效地从互联网服务器检索文件。
为此可定义状态变量和动作。
UPnP HTTP代理服务器服务可具有单个状态变量ProxyServerURL。
ProxyServerURL状态变量的值可以是HTTP代理服务器的URL–即，HTTP请求将要指向的URL，以便通过代理服务器对请求进行路由。
图109是示出代理服务器服务动作的实施方式的示图。
UPnP代理服务器服务可具有单个动作GetProxyURL。
图110是示出GetProxyURL动作的参数的实施方式的示图。
GetProxyURL动作可具有单个参数ProxyURL。
ProxyURL输出参数可以是ProxyServerURL状态变量的当前值。
因此，可经由GetProxyURL动作获得ProxyServerURL状态变量的当前值。
图111是示出RequestFiles()的实施方式的示图。
在UPnP HTTP代理服务器服务状态变量的另一实施方式中，可定义称为ATSCProxySeverURL的UPnP HTTP代理服务器服务状态变量。另外，在此实施方式中，可定义称为GetProxyServerURL()的动作。
ATSCProxySeverURL状态变量可包含对接收机中的代理服务器的引用(URI的形式)。代理服务器从第二屏幕装置得到对文件的HTTP请求，并且从广播流中的FLUTE会话或互联网检索该文件。然后，代理服务器将所检索到的文件作为HTTP响应发送给第二屏幕装置。
GetProxyServerURL()可以是允许读取ProxySeverURL的值的动作。可包括ProxySeverURL作为参数。
在UPnP HTTP代理服务器服务状态变量的另一实施方式中，可定义称为ATSCFileList的UPnP HTTP代理服务器服务状态变量。另外，在此实施方式中，可定义称为RequestFiles()的动作。
包括在广播流中的文件仅可被能够接收广播内容的接收机获取。因此，为了使得无法接收广播内容的第二屏幕装置能够访问包括在广播内容中的文件，可定义必要的UPnP状态变量和动作。即，ATSCFileList(是将要经由FLUTE会话下载的文件列表)被设定为UPnP状态变量，或者可使得第二屏幕装置能够经由向接收机请求文件的RequestFiles()动作来获取特定文件或多个文件。
ATSCFileList状态变量可包含向接收机中的代理服务器请求的文件的CSV列表。
RequestFiles()可以是请求经由互联网下载包括在广播流中的特定文件的动作。具体地讲，在包括在广播流中的文件的情况下，所请求的文件可经由FLUTE会话来下载。
图112是示出第二屏幕装置架构的实施方式的示图。
将描述操作理论。
可存在两个操作模式：触发应用(TDO)在TV接收机上执行的一个模式以及非触发应用(打包应用)在TV接收机上执行的另一模式。
在触发应用在TV接收机上执行的情况下，当TV接收机上当前观看的节目具有与第二屏幕支持关联的交互数据服务时，第二屏幕装置的用户可激活该装置上的适当应用。该应用可经历UPnP发现和描述处理以发现TV接收机上的触发服务、双向通信服务和代理服务器服务。
然后，第二屏幕应用可订用触发服务的UPnP“事件触发”以得到准备好传送的触发的通知，并且可使用GetLatestUnfilteredTrigger或GetLatestFilteredTrigger动作以得到它被设计使用的触发。这样做的结果是第二屏幕应用可获得适当时间的适当触发。然后，应用可按照它被设计使用的方式来处置这些触发。
第二屏幕应用还可订用双向通信服务的UPnP“事件触发”以得到用来请求双向通信的连接的TCP/IP地址和端口的通知以及何时有准备通信的DO在主装置中执行的通知。然后，应用可参与与支持这样的通信的任何DO的双向通信。
由触发导致的动作和/或双向通信常常会需要第二屏幕应用下载文件。这些文件可能可从互联网上的HTTP服务器得到，或者可能可从TV广播中的d会话得到(或者二者)。
如果所有期望的文件均可经由互联网得到，并且如果第二屏幕装置具有与网络的良好连接性，则应用可仅仅直接检索文件。
如果一些或所有期望的文件仅可经由TV广播得到，并且如果接收机提供HTTP代理服务器服务，则应用可利用GetProxyURL动作得到代理服务器URL并且经由代理服务器检索期望的文件。应用还可在那样检索文件可能比直接检索文件更方便的其它情形下选择使用代理服务器。
在非触发应用在TV接收机上执行的情况下，不管当前观看的节目，用户可激活TV接收机上的DO，其(除了别的以外)使得可通过AppURL服务得到第二屏幕装置上将启动的伙伴应用的名称和位置。
第二屏幕装置上的控制点可订用与AppURL服务关联的UPnP“事件触发”以得到对AppURL和AppName变量的改变的通知。然后，控制点将向第二屏幕装置的用户指示可用服务待定。随后，用户将查看AppName并选择服务，导致在第二屏幕装置上启动伙伴第二屏幕应用。
第二屏幕应用可与ATSC 2.0接收机上执行的DO关联，即使该DO是先前下载到接收机的广播商提供的打包应用，其生命周期由消费者控制，而非由广播商控制。在缺少标识伙伴第二屏幕应用的触发情况下，接收机提供允许第二屏幕装置上的控制点使用GetAppURL动作来访问公布的第二屏幕应用URL并在第二屏幕装置上启动它的AppURL服务。
第二屏幕装置架构的一个实施方式示出第二屏幕应用以及与接收机协作的第二屏幕装置。
第二屏幕装置架构的一个实施方式可包括远程内容服务器112010、TV接收机112020和/或第二屏幕装置112030。
远程内容服务器112010可提供内容。所述内容可被提供给接收机112020或第二屏幕装置112030。
TV接收机112020可提供UPnP触发服务和UPnP代理服务器服务。该接收机可等同于上述接收机。
第二屏幕装置112030可具有第二屏幕应用(ATSC 2.0App)，第二屏幕应用可在触发处理机中具有UPnP控制点(CP)模块。UPnP控制点(CP)模块处理第二屏幕应用(ATSC2.0App)与TV接收机(112020)上的触发服务和代理服务器服务之间的所有UPnP通信。它可管理发现处理，获得代理服务器URL，并且订用触发服务事件触发。
来自UPnP触发服务的触发可被移交给触发处理机。如果触发指示新声明对象(DO)将被下载并在DAE(声明应用环境–即，浏览器)中执行，则触发处理机可应对它。如果触发指示已经在浏览器中执行的DO应该采取特定动作，则触发处理机可将触发传递给DO。第二屏幕装置的用户可与DO交互。触发处理机对于用户而言可为不可见的。
第二屏幕应用可根据需要执行以下功能。1)使用UPnP发现和描述协议来寻找触发服务以及(如果可用的话)TV接收机上的代理服务器服务。2)使用UPnP SUBSCRIBE协议来订用触发服务事件触发。3)调用代理服务器服务的GetProxyURL动作以得到HTTP代理服务器(如果可用的话)的URL。4)接收经由触发服务事件传送的触发。5)如果接收到直接执行触发，并且触发中标识的DO还未在DAE中运行，则开始在DAE中运行它(如果需要的话首先下载它)。6)将各个接收的直接执行触发传递给触发中标识的DO(如果需要在下载并开始DO之后)。7)如果接收到TDO触发，并且如果触发的动作属性不是“TriggerEvent”，则执行该动作(例如，准备运行TDO、运行TDO、终止TDO等)。8)如果接收到TDO触发，并且如果触发的动作属性是“TriggerEvent”，则将触发传递给被标识为触发的目标的TDO。如果TDO还未在DAE中运行，则丢弃该触发。9)根据需要经由直接互联网连接或者经由TV接收机上的代理服务器服务下载文件(包括TDO)。
直接执行触发和TDO触发可在被接收时被立即处置，除非它们包含“spread”或“diffusion”属性。当触发包含“spread”或“diffusion”属性时，动作可被延迟随机间隔。
图113是示出接收机的简化结构的实施方式的示图。
示出接收机的简化结构的示图可包括天线(rcvr2010)、调谐器(rcvr2020)、EPG(rcvr2030)、VSB或DVB解调器(rcvr2040)、信道管理器(rcvr2050)、SI模块(rcvr2051)、MPEG-2TS系统解码器(rcvr2060)、字幕模块(rcvr2070)、触发模块(rcvr2080)、web浏览器(rcvr2090)、UPnP框架(rcvr2091)、网络协议栈(rcvr2100)、网络接口(rcvr2110)、UI模块(rcvr2120)、音频解码器(rcvr2140)、视频解码器(rcvr2150)、扬声器(rcvr2160)、显示模块(rcvr2170)、图形处理器(rcvr2180)、遥控器接收器(rcvr2190)和/或遥控器(rcvr2200)。
天线(rcvr2010)可根据广播流接收广播信号。这里，天线(rcvr2010)可以是技术领域中常用的天线。
调谐器(rcvr2020)可搜寻或调谐接收机的信道，并且可包括射频放大器、本地振荡器、频率转换和输入电路、搜寻器等。调谐器(rcvr2020)可以是技术领域中常用的调谐器。
EPG(rcvr2030)可以是利用TV广播的空白频率或补充信道提供TV节目广播时间、内容和演员信息的广播节目指南服务(电子节目指南)。所接收到的EPG数据被存储，观看者利用遥控器操纵EPG以选择并保留节目，从而执行依照观看节目顺序的支付、依照主题或类型的节目搜索、视频记录等。所接收到的EPG还可被传送给UI模块。
VSB或DVB解调器(rcvr2040)可对VSB信号或DVB信号进行调制。VSB或DVB解调器(rcvr2040)可将调制的VSB或DVB(例如，OFDM调制信号)恢复成原始信号。VSB或DVB解调器(rcvr2040)的解调处理可以是技术领域中常用的解调处理。
信道管理器(rcvr2050)可利用所接收到的EPG执行信道管理。可传送由SI模块处理的EPG。信道管理器可用作一般信道管理器。
如果经由MPEG-2TS系统解码器(rcvr2060)接收到广播流，则SI模块(rcvr2051)可确认节目特定信息。利用所确认的信息，可确定广播节目中存在多少字幕以及服务#6中是否存在触发。
MPEG-2TS系统解码器(rcvr2060)可将解调信号的传输流(TS)解码。MPEG-2TS系统解码器rcvr2060可从传输流获得字幕流并传送给字幕模块rcvr2070。MPEG-2TS系统解码器rcvr2060可将解码的音频和视频信号发送给音频/视频解码器。
字幕模块(rcvr2070)可接收字幕流。字幕模块rcvr2070可监测服务#6或其它服务，并且确定服务#6或用于发送触发的服务是否被选择并发送给触发模块rcvr2080或者字幕文本是否被处理并显示在屏幕上。触发数据可被传送给触发模块rcvr2080。其它字幕服务可经受字幕文本处理并被发送给图形处理器rcvr2180。如果当前接收的数字字幕中包括触发，则字幕模块(rcvr2070)经由所确认的信息将触发传送给触发模块(rcvr2080)。
触发模块(rcvr2080)可解析触发、TPT和/或AMT信息并且处理所解析的数据。触发模块rcvr2080可利用触发的URI信息值经由网络协议栈rcvr2100访问网络。URI信息值可以是HTTP服务器的地址。触发模块rcvr2080可分析TPT文件内容以获得TDO URL。另外，触发模块rcvr2080可解析AMT以处理数据。可通过解析获得其它信息。在接收到AMT消息之后，根据预定时间和操作传送与web浏览器对应的TDO URL，或者可在预定时间停止当前操作的TDO。这对应于TDO动作，触发模块rcvr2080可向web浏览器发送命令以进行操作。与本发明有关的触发模块rcvr2080的操作将在下面详细描述。触发模块(rcvr2080)可经由网络协议栈(rcvr2100)直接或间接访问互联网服务器。触发模块(rcvr2080)可立即解释经由DTVCC接收的触发，并且根据需要经由网络接口(rcvr2110)从互联网下载并处理TPT文件。TPT文件可在下载之后被立即处理，从而执行必要操作。此时，如果存在与第二屏幕关联的触发以及关联的事件，如上所述，可利用各种方法执行与第二屏幕装置的通信。这种通信可通过下述UPnP框架(rcvr2091)来执行。
Web浏览器(rcvr2090)可接收来自触发模块rcvr2080的命令、来自UI模块rcvr2120的浏览器键码以及来自遥控器接收器rcvr2190的浏览器键码并且与网络协议栈rcvr2100进行通信。
UPnP框架(rcvr2091)可检测第二屏幕装置，并且发送触发或者重新生成并发送第二屏幕装置所需的信息。如上所述，当经由网络接口(rcvr2110)接收到触发时，如果存在与第二屏幕关联的触发以及关联的事件时，UPnP框架(rcvr2091)可执行与第二屏幕装置的通信。
网络协议栈(rcvr2100)可与触发模块rcvr2080和web浏览器通信以经由网络接口rcvr2110访问服务器。
网络接口(rcvr2110)执行多个其它设备的公共连接或者网络计算机和外部网络的连接。网络接口可连接到服务器以下载TDO、TPT、AMT等。这里，网络接口rcvr2110的操作可以是技术领域中常用的网络接口rcvr2110的操作。与本发明有关的网络接口rcvr1090的操作将在下面详细描述。
UI模块(rcvr2120)可通过遥控器接收器rcvr2190接收由观看者利用遥控器rcvr2200输入的信息。如果所接收到的信息与使用网络的服务有关，则可将浏览器键码传送给web浏览器。如果所接收到的信息与当前显示的视频有关，则可经由图形处理器rcvr2180将信号传送给显示模块rcvr2170。
音频解码器(rcvr2140)可将从MPEG-2TS系统解码器rcvr2060接收的音频信号解码。随后，解码的音频信号可被发送给扬声器并输出给观看者。这里，音频解码器rcvr2140可以是技术领域中常用的音频解码器。
视频解码器(rcvr2150)可将从MPEG-2TS系统解码器rcvr2060接收的视频信号解码。随后，解码的视频信号可被发送给显示模块rcvr2170以输出给观看者。这里，视频解码器rcvr2150可以是技术领域中常用的视频解码器。
扬声器(rcvr2160)可将音频信号输出给观看者。扬声器可以是技术领域中常用的扬声器。
显示模块(rcvr2170)可将视频信号输出给观看者。显示模块rcvr2170可以是技术领域中常用的显示模块。
图形处理器(rcvr2180)可针对从字幕模块rcvr2070接收的字幕文本以及从UI模块rcvr2120接收的观看者输入信息执行图形处理。处理的信息可被传送给显示模块rcvr2170。图形处理器rcvr2180可以是技术领域中常用的图形处理器。
遥控器接收器(rcvr2190)可从遥控器rcvr2200接收信息。此时，键码可被传送给UI模块rcvr2120，浏览器键码可被传送给web浏览器。
遥控器(rcvr2200)将观看者所输入的信号传送给遥控器接收器rcvr2190。遥控器rcvr2200可接收用于改变虚拟信道的观看者输入。另外，遥控器可接收由观看者针对应用选择的信息。遥控器rcvr2200可将所接收到的信息传送给遥控器接收器rcvr2190。此时，可在超出预定范围之外的距离处利用红外(IR)光来远程地传送信息。
图114是示出第二屏幕装置的结构的实施方式的示图。
第二屏幕装置的结构的一个实施方式可包括IO子系统114010、文件系统114020、网络协议子系统114030和基本模块114040。
IO子系统114010可与可安装在第二屏幕装置中以用于外部连接的所有装置连接。IO子系统114010可与键区、显示器、麦克风、扬声器、立体声插孔、运动传感器、光传感器、GPS和相机连接。各个I/O装置可通过键模块、显示控制模块、音频控制模块、传感器控制模块和/或相机控制模块来控制。如果由IO子系统114010调用的功能为SDK形式，则各个I/O装置通过装置驱动器来控制并且各个传感器或相机可访问任何程序。在一些情况下，可限制功能以使得仅可在本机应用中进行访问。
文件系统114020可针对外部SD卡读取和写入文件，并且可连接到USB以执行数据通信。诸如SD卡、闪存或USB的装置可连接。这可通过SD接口、闪存控制或USB BUS控制来控制。
网络协议子系统114030可经由3GPP、Wi-Fi和/或蓝牙来执行通信。
基本模块114040可被包括在第二装置中。电池管理器可管理第二屏幕装置的电量，通知模块可在通信提供商或制造商向第二屏幕装置提供通知时使用。另外，商店模块可用于购买利用第二屏幕装置所提供的开放SDK制作的第二屏幕的应用。应用管理器可管理利用商店模块安装的应用并且通知应用升级。另外，web模块可被包括以使得第二屏幕装置执行互联网接入。第二屏幕的各种功能可根据个人偏好来设定，并且可使用用户偏好程序。
基本模块114040具有各种功能并且可以是安装在第二屏幕装置中的程序。然而，由虚线表示的模块可以是由用户选择性地安装的软件模块。
例如，UPnP框架模块可能不被第二屏幕装置支持或者可被安装在第二屏幕装置中。如果UPnP框架模块被安装，则本机应用也被安装以容易地执行UPnP操作。然而，在接收机的结构中，UPnP框架可使得用户能够安装第二屏幕服务应用或者支持UPnP框架的应用。可经由UPnP框架模块寻找能够接收地面波的接收机。
图115是示出第二屏幕服务情景的示图。
将描述第二屏幕服务情景的一个实施方式。
第二屏幕服务情景的一个实施方式可包括接收触发(s115010)、请求TPT(s115020)、发送TPT作为响应(s115030)、请求TDO(s115040)、发送TDO作为响应(s115050)、执行TDO(s115060)、发送scanDeviceList消息(s115070)、调用发现功能(s115080)、执行UPnP应用(s115090)、多播搜索消息(s115100)、通知UPnP框架(s115110)、返回装置列表(s115120)、返回装置句柄(s115130)、发送scanServiceList消息(s115140)、调用服务列表功能(s115150)、发送GetServiceDescription消息(s115160)、发送HTTP消息(s115170)、返回服务列表(s115180)、返回服务句柄列表(s115190)、发送hnHandle消息(s115200)、调用服务列表功能(s115210)、发送GetDeviceProfile消息(s115220)、发送HTTP消息(s115230)、返回soap响应(s115240)、返回soap响应XML(s115250)、解析soap响应(s115260)、发送hnHandle消息(s115270)、调用服务列表功能(s115280)、发送InputUIListing消息(s115290)、发送HTTP消息(s115300)、返回soap响应(s115310)、返回TimeToLive(s115320)、发送hnHandle消息(s115330)、调用服务列表功能(s115340)、发送DisplayMessage(s115350)、发送HTTP消息(s115360)、返回Null(s115370)、返回Null(s115380)和/或执行第二屏幕应用(s115390)。
接收触发(s115010)可包括经由广播流利用DTVCC iTV消息从广播商接收触发。
请求TPT(s115020)可包括解析并解释所接收到的触发并且请求与广播商互联网服务器有关的TPT。
发送TPT作为响应(s115030)可包括发送TPT作为响应。
请求TDO(s115040)可包括如果需要下载相关的TDO则向广播商互联网服务器请求TDO。
发送TDO作为响应(s115050)可包括发送所请求的TDO。
执行TDO(s115060)可包括触发模块执行TDO。
发送scanDeviceList消息(s115070)可包括所执行的DO(或TDO)发送请求装置列表扫描的消息。
调用发现功能(s115080)可包括调用用于装置发现的UPnP框架的发现功能。
执行UPnP应用(s115090)可包括第二屏幕装置执行用于第二屏幕服务启动器的UPnP应用。该步骤独立于主装置，可在执行UPnP应用(s115090)之前执行。
多播搜索消息(s115100)可包括UPnP框架多播搜索消息以搜索家庭网络中的第二屏幕装置。
通知UPnP框架(s115110)可包括接收到搜索消息的第二屏幕装置将通知消息发送给主装置。因此，可通知第二屏幕装置的存在。
返回装置列表(s115120)可包括UPnP框架在装置发现之后返回装置列表。
返回装置句柄(s115130)可包括将所接收到的装置列表传送给DO。
发送scanServiceList消息(s115140)可包括所执行的DO(或TDO)发送请求服务列表扫描的消息。
调用服务列表功能(s115150)可包括调用用于服务发现的UPnP框架的服务列表功能。
发送GetServiceDescription消息(s115160)可包括向第二屏幕装置请求第二屏幕装置的服务描述。
发送HTTP消息(s115170)可包括将发送GetServiceDescription消息(s115160)的结果发送。如上所述，可发送诸如HTTP/1.1 200 OK(成功)的消息。服务描述可在XML中接收。
返回服务列表(s115180)可包括在UPnP框架接收到服务描述之后返回服务列表。
返回服务句柄列表(s115190)可包括返回所接收到的服务列表。
发送hnHandle消息(s115200)可包括发送消息以便获得装置配置文件。
调用服务列表功能(s115210)可包括调用用于服务发现的UPnP框架的服务列表功能。
发送GetDeviceProfile消息(s115220)可包括向第二屏幕装置请求第二屏幕装置的服务描述。发送HTTP消息(s115230)可包括将发送GetDeviceProfile消息(s115220)的请求结果发送。如上所述，可发送诸如HTTP/1.1 200 OK(成功)的消息。可接收装置配置文件。
返回soap响应(s115240)可包括返回所接收到的装置配置文件。
返回soap响应XML(s115250)可包括以XML返回所接收到的装置配置文件。
解析soap响应(s115260)可包括DO解析所接收到的SOAP消息。
发送hnHandle消息(s115270)可包括发送消息以便向第二屏幕装置通知第二屏幕服务的URL地址。
调用服务列表功能(s115280)可包括调用UPnP框架的服务列表功能。
发送InputUIListing消息(s115290)可包括向第二屏幕装置通知第二屏幕服务的URL地址。可使用上述AddUIListing动作。第二屏幕装置可将所获取的URL添加到UIListing。
发送HTTP消息(s115300)可包括将发送InputUIListing消息(s115290)的请求结果发送。如上所述，可发送诸如HTTP/1.1 200 OK(成功)的消息。
返回soap响应(s115310)可包括返回指示URL已被发送的消息。
返回TimeToLive(s115320)可包括将发送InputUIListing消息(s115290)的请求结果发送，类似于发送HTTP消息(s115300)。
发送hnHandle消息(s115330)可包括发送消息以便将显示消息传送给第二屏幕装置。
调用服务列表功能(s115340)可包括调用UPnP框架的服务列表功能。
发送DisplayMessage(s115350)可包括将显示消息发送给第二屏幕装置。显示消息可包括诸如消息类型的信息。可使用上述DispalyMessage动作。第二屏幕装置可根据显示消息在第二屏幕上显示消息。
发送HTTP消息(s115360)可包括将发送DisplayMessage(s115350)的结果发送。如上所述，可发送诸如HTTP/1.1 200 OK(成功)的消息。
返回null(s115370)可包括如果接收到HTTP/1.1 200 OK则返回null。
返回null(s115380)可包括如果作为响应接收到null则将null返回给DO。
执行第二屏幕应用(s115390)可包括第二屏幕装置执行第二屏幕应用。
图116是示出在主装置中处理数字服务信号的方法的实施方式的示图。
在主装置中处理数字服务信号的方法的实施方式可包括执行主应用(s116010)、发送交互服务的消息(s116020)、接收对描述的请求(s116030)、发送描述(s116040)和/或提供交互服务(s116050)。
执行主应用(s116010)可以是主装置针对数字服务信号执行主应用的步骤。这里，主应用可以是触发应用或者非触发应用。这里，主装置可以是上述TV接收机。这里，主应用可表示可由TV接收机执行的DO。这里，主应用可以是DO、TDO、NDO或UDO。
在发送交互服务的消息(s116020)中，消息可表示用于与主应用关联的副应用的交互服务的消息。这里，可从主装置将上述消息发送给第二屏幕装置(或者由第二屏幕装置执行的应用)。这里，交互服务可包括与触发应用有关的第一模式或者与非触发应用有关的第二模式。这里，副应用可与上述主应用以及由第二屏幕装置执行的应用关联。应用可表示DO、TDO、NDO或UDO。这里，触发应用可表示TDO，非触发应用可表示NDO。
接收对描述的请求(s116030)可以是主装置从第二屏幕装置(或者由第二屏幕装置执行的应用)接收描述的步骤。这里，所述描述可表示用于标识上述交互服务的描述。
发送描述(s116040)可以是主装置将请求的描述发送给第二屏幕装置(或者由第二屏幕装置执行的应用)的步骤。这里，所述描述可包括描述中所描述的各个交互服务的服务类型信息和服务id信息。这里，服务id信息可标识各个交互服务。这里，服务类型信息可指示各个交互服务的类型。
提供交互服务(s116050)可以是主装置向第二屏幕装置(或者由第二屏幕装置执行的应用)提供交互服务的步骤。可通过发送用于交互服务的信息来提供交互服务。
在本发明的一个实施方式中，上述用于交互服务的信息可根据各个交互服务来定义。并且上述用于交互服务的信息可以是触发、字节和URL信息之一。这里，当上述用于交互服务的信息对应于触发时，主装置可提供触发服务。这里，当上述用于交互服务的信息对应于字节时，主装置可提供双向通信服务。这里，当上述用于交互服务的信息是URL信息时，主装置可提供AppURL服务。
在本发明的另一实施方式中，上述用于交互服务的信息可以是触发。并且触发中的至少一个可包括信道改变信息，所述信道改变信息的值指示数字服务信号的改变的信道号。本实施方式可对应于上述触发服务发送上述信道改变触发的情况。包括信道改变信息的至少一个触发可表示上述信道改变触发。信道改变信息可具有指示改变的信道号的值。
在本发明的另一实施方式中，当上述用于交互服务的信息是触发时，所述方法还可包括以下步骤：通过与TPT中的信息组合来增强触发，其中，所述TPT包含关于触发应用的元数据；以及发送具有事件指示符的增强触发，所述事件指示符指示触发中标识的事件。这里，“当用于交互服务的信息是触发时”可表示主装置提供触发服务的情况。本实施方式可对应于生成并发送上述增强触发的情况。“通过与TPT中的信息组合来增强触发”可以是将TPT中包含的信息与触发组合的步骤。这里，事件指示符可表示上述AugmentedTrigger中的event元素。
在本发明的另一实施方式中，上述用于交互服务的信息可以是字节。并且交互服务可包括指示应用是否被执行并准备参与与副应用的通信的status状态变量。并且所述方法还可包括设定所述status状态变量。本实施方式可表示主装置提供双向通信服务的情况。这里，status状态变量可表示上述双向通信服务的第二方法中的Status状态变量。这里，“设定status状态变量”可表示使用上述setStatusYes()、setStatusNo()或setStatus()API的情况。
在本发明的另一实施方式中，主应用使用API来提供交互服务。本实施方式可表示主装置提供双向通信服务的情况。这里，API可表示上述双向通信服务的API当中的sendBytes API。
在本发明的另一实施方式中，API可包括具有关于用于字节的地址和端口的信息的address参数以及bytes参数。这里，address参数可表示sendBytes API的address参数。这里，bytes参数可表示sendBytes API的bytes参数。
在本发明的另一实施方式中，所述方法还包括以下步骤：在发送消息之前，接收对与主应用关联的副应用的交互服务的消息的请求。第二屏幕装置可向主装置发送请求。该请求是对与主应用关联的副应用的交互服务的消息的请求。这里，所述消息可表示上述发现消息。当主装置接收到对所述消息的请求时，主装置可将所述消息发送给第二屏幕装置。本实施方式可对应于装置发现或服务发现。
图117是示出在副应用中处理数字服务信号的方法的实施方式的示图。
在副应用中处理数字服务信号的方法的实施方式可包括执行应用(s117010)、接收交互服务的消息(s117020)、发送对描述的请求(s117030)、接收描述(s117040)、订用用于通知的协议(s117050)、接收通知(s117060)、利用所接收到的通知接收信息(s117070)和/或下载文件(s117080)。
执行应用(s117010)可以是第二屏幕装置针对数字服务信号执行应用的步骤。这里，应用可表示可由第二屏幕装置执行的DO、TDO、NDO或UDO。
在接收交互服务的消息(s117020)中，所述消息可表示用于所执行的应用的交互服务的消息。这里，可从主装置将所述消息发送给第二屏幕装置。
发送对描述的请求(s117030)可以是第二屏幕装置(或者由第二屏幕装置执行的第二屏幕应用)向主装置请求描述的步骤。这里，所述描述可标识交互服务。
接收描述(s117040)可以是第二屏幕装置(或者由第二屏幕装置执行的第二屏幕应用)接收主装置所请求的描述的步骤。这里，所述描述可具有标识各个交互服务的服务id信息以及指示各个交互服务的类型的服务类型信息。
订用用于通知的协议(s117050)、接收通知(s117060)以及利用所接收到的通知接收信息(s117070)可被包括在第二屏幕装置(或者由第二屏幕装置执行的第二屏幕应用)利用上述描述实现至少一个交互服务的步骤中。
订用用于通知的协议(s117050)可以是第二屏幕装置(或者由第二屏幕装置执行的第二屏幕应用)订用用于由主装置提供的至少一个交互服务的通知的协议的步骤(可以是上述订用“事件触发”协议的步骤)。
接收通知(s117060)可以是上述从主装置接收交互服务的通知的步骤。所述通知可以是上述异步通知。
利用所接收到的通知接收信息(s117070)可以是利用所接收到的通知接收关于交互服务的信息的步骤。
下载文件(s117080)可以是下载用于实现交互服务的文件的步骤。所述文件可以是上述应用。
在本发明的一个实施方式中，上述用于交互服务的信息可根据各个交互服务来定义。并且上述用于交互服务的信息可以是触发、字节和URL信息之一。这里，当上述用于交互服务的信息对应于触发时，主装置可提供触发服务。这里，当上述用于交互服务的信息对应于字节时，主装置可提供双向通信服务。这里，当上述用于交互服务的信息是URL信息时，主装置可提供AppURL服务。
在本发明的另一实施方式中，当用于发现的交互服务的信息是触发时，触发中的至少一个可包括信道改变信息，所述信道改变信息的值指示数字服务信号的改变的信道号。本实施方式可对应于上述触发服务发送上述信道改变触发的情况。包括信道改变信息的至少一个触发可表示上述信道改变触发。信道改变信息可具有指示所改变的信道号的值。
在本发明的另一实施方式中，当用于所访问的交互服务的信息可为字节时，所述方法还包括以下步骤：利用所接收到的通知确定交互服务是否准备开始；以及利用所接收到的通知发送对用于发送字节的连接的请求。本实施方式可对应于提供上述双向通信服务的情况。在本实施方式中，通知可用于指示由主装置执行的DO是否准备好通信。在本实施方式中，用于发送字节的连接可以是TCP/IP连接。另外，本实施方式可对应于向主装置请求TCP/IP连接的操作。
在本发明的另一实施方式中，所述方法还包括以下步骤：在接收消息之前，发送对所执行的应用的交互服务的消息的请求。第二屏幕装置可向主装置发送请求。该请求是对副应用的交互服务的消息的请求。这里，所述消息可表示上述发现消息。当主装置接收到对所述消息的请求时，主装置可将所述消息发送给第二屏幕装置。本实施方式可对应于装置发现或服务发现。
图118是示出作为主装置处理数字服务信号的设备的实施方式的示图。
作为主装置处理数字服务信号的设备的实施方式可包括执行模块118010、发送模块118020、接收模块118030和/或提供模块118040。
执行模块118010可被配置为针对数字服务信号执行主应用。这里，主应用可以是触发应用或者非触发应用。这里，主装置可以是上述TV接收机。这里，主应用可表示可由TV接收机执行的DO。这里，主应用可以是DO、TDO、NDO或UDO。
发送模块118020可被配置为发送与主应用关联的副应用的交互服务的消息。并且发送模块118020可被配置为发送标识交互服务的描述。这里，交互服务可包括与触发应用有关的第一模式或者与非触发应用有关的第二模式。这里，可根据请求发送所述描述。上述消息可被发送给第二屏幕装置(或者由第二屏幕装置执行的应用)。这里，副应用可以是与上述主应用以及由第二屏幕装置执行的应用关联的应用。所述应用可表示DO、TDO、NDO或UDO。这里，触发应用可表示TDO，非触发应用可表示NDO。
接收模块118030可被配置为接收对描述的请求，所述描述具有标识各个交互服务的服务id信息以及指示各个交互服务的类型的服务类型信息。这里，所述描述可包括该描述中所描述的各个交互服务的服务类型信息和服务id信息。
这里，发送模块118020和接收模块118030可根据设计者的意图被包括在一个模块中。
提供模块118040可被配置为通过发送用于交互服务的信息来提供交互服务。提供模块118040可向第二屏幕装置(或者由第二屏幕装置执行的应用)提供交互服务。
在本发明的一个实施方式中，上述用于交互服务的信息可根据各个交互服务来定义。并且上述用于交互服务的信息可以是触发、字节和URL信息之一。这里，当上述用于交互服务的信息对应于触发时，主装置可提供触发服务。这里，当上述用于交互服务的信息对应于字节时，主装置可提供双向通信服务。这里，当上述用于交互服务的信息是URL信息时，主装置可提供AppURL服务。
在本发明的另一实施方式中，上述用于交互服务的信息可以是触发。并且触发中的至少一个可包括信道改变信息，所述信道改变信息的值指示数字服务信号的改变的信道号。本实施方式可对应于上述触发服务发送上述信道改变触发的情况。包括信道改变信息的至少一个触发可表示上述信道改变触发。信道改变信息可具有指示改变的信道号的值。
在本发明的另一实施方式中，当上述用于交互服务的信息是触发时，所述设备还可包括增强模块。该增强模块可被配置为通过与TPT中的信息组合来增强触发。所述TPT可包含关于触发应用的元数据。上述发送模块还可发送具有事件指示符的增强触发，所述事件指示符指示触发中标识的事件。这里，“当用于交互服务的信息是触发时”可表示主装置提供触发服务的情况。本实施方式可对应于生成并发送上述增强触发的情况。增强模块可将包括在TPT中的信息与触发组合。这里，事件指示符可表示上述AugmentedTrigger中的event元素。
在本发明的另一实施方式中，上述用于交互服务的信息可以是字节。并且交互服务可包括指示应用是否被执行并准备参与与副应用的通信的status状态变量。并且所述方法还可包括设定所述status状态变量。本实施方式可表示主装置提供双向通信服务的情况。这里，status状态变量可表示上述双向通信服务的第二方法中的Status状态变量。这里，“设定status状态变量”可表示使用上述setStatusYes()、setStatusNo()或setStatus()API的情况。
在本发明的另一实施方式中，主应用使用API来提供交互服务。本实施方式可表示主装置提供双向通信服务的情况。这里，API可表示上述双向通信服务的API当中的sendBytes API。
在本发明的另一实施方式中，API可包括具有关于用于字节的地址和端口的信息的address参数以及bytes参数。这里，address参数可表示sendBytes API的address参数。这里，bytes参数可表示sendBytes API的bytes参数。在本发明的另一实施方式中，接收模块还被配置为在发送模块发送消息之前，接收对与主应用关联的副应用的交互服务的消息的请求。第二屏幕装置可向主装置发送请求。该请求是对与主应用关联的副应用的交互服务的消息的请求。这里，所述消息可表示上述发现消息。当主装置(或接收模块)接收到对所述消息的请求时，主装置(或发送模块)可将所述消息发送给第二屏幕装置。本实施方式可对应于装置发现或服务发现。
图119是示出作为副应用处理数字服务信号的设备的实施方式的示图。
作为副应用处理数字服务信号的设备可包括执行模块119010、接收模块119020、发送模块119030、访问模块119040和/或下载模块119050。
执行模块119010可被配置为针对数字服务信号执行应用。这里，所述应用可表示可由第二屏幕装置执行的DO、TDO、NDO或UDO。
接收模块119020可被配置为接收用于所执行的应用的交互服务的消息以及描述。这里，所述消息可从主装置发送。这里，描述可由主装置请求。这里，所述描述可标识交互服务。
发送模块119030可被配置为发送对标识交互服务的描述的请求。这里，所述描述可具有标识各个交互服务的服务id信息以及指示各个交互服务的类型的服务类型信息。
访问模块119040可被配置为利用所述描述访问至少一个交互服务。访问模块119040还可订用用于至少一个交互服务的通知的协议(对应于上述订用“事件触发”协议的操作)。访问模块119040还可接收通知。所述通知可以是上述异步通知。访问模块119040还可利用所接收到的通知接收用于至少一个交互服务的信息。
下载模块119050可以是被配置为下载用于所访问的交互服务的文件的模块。这里，所述文件可以是上述应用。
在本发明的一个实施方式中，上述用于交互服务的信息可根据各个交互服务来定义。并且上述用于交互服务的信息可以是触发、字节和URL信息之一。这里，当上述用于交互服务的信息对应于触发时，主装置可提供触发服务。这里，当上述用于交互服务的信息对应于字节时，主装置可提供双向通信服务。这里，当上述用于交互服务的信息是URL信息时，主装置可提供AppURL服务。
在本发明的另一实施方式中，当用于所发现的交互服务的信息是触发时，触发中的至少一个可包括信道改变信息，所述信道改变信息的值指示数字服务信号的改变的信道号。本实施方式可对应于上述触发服务发送上述信道改变触发的情况。包括信道改变信息的至少一个触发可表示上述信道改变触发。信道改变信息可具有指示所改变的信道号的值。
在本发明的另一实施方式中，当用于访问的交互服务的信息为字节时，访问模块119040还可利用所接收到的通知确定交互服务是否准备开始。并且访问模块119040还可利用所接收到的通知发送对用于发送字节的连接的请求。本实施方式可对应于提供上述双向通信服务的情况。在本实施方式中，通知可用于指示由主装置执行的DO是否准备好通信。在本实施方式中，用于发送字节的连接可以是TCP/IP连接。另外，本实施方式可对应于向主装置请求TCP/IP连接的操作。
在本发明的另一实施方式中，发送模块还被配置为在接收模块接收消息之前，发送对所执行的应用的交互服务的消息的请求。第二屏幕装置(或发送模块)可向主装置发送请求。该请求是对副应用的交互服务的消息的请求。这里，所述消息可表示上述发现消息。当主装置接收到对所述消息的请求时，主装置可将所述消息发送给第二屏幕装置。本实施方式可对应于装置发现或服务发现。
可通过将电子设备连接到家庭网络并且根据电子设备起作用来提供UPnP框架。本发明涉及现有UPnP RemoteUI客户机服务和UPnP RemoteUI服务器客户机的扩展。因此，可在与现有UPnP设备兼容的同时接收第二屏幕服务。
尽管为了清晰而参照各个附图说明了本发明的描述，可通过将附图中所示的实施方式彼此合并来设计新的实施方式。另外，如果本领域技术人员需要设计记录有用于执行以上描述中所提及的实施方式的程序的可由计算机读取的记录介质，则它可属于所附权利要求及其等同物的范围。
根据本发明的设备和方法可不受以上描述中提及的实施方式的配置和方法的限制。并且，以上描述中提及的实施方式可按照完整地或部分地彼此选择性地组合的方式来配置，以允许各种修改。
另外，根据本发明的方法可利用提供给网络装置的处理器可读记录介质中的处理器可读代码来实现。处理器可读介质可包括能够存储可由处理器读取的数据的所有类型的记录装置。处理器可读介质可包括例如ROM、RAM、CD-ROM、磁带、软盘、光学数据存储装置等之一，并且还包括诸如经由互联网的传输的载波型实现方式。另外，当处理器可读记录介质被分布于经由网络连接的计算机系统时，计算机可读代码可根据分布式系统来保存和执行。
本领域技术人员将理解，在不脱离本发明的精神或范围的情况下可对本发明进行各种修改和变化。因此，本发明旨在涵盖本发明的这些修改和变化，只要它们落入所附权利要求及其等同物的范围内。
本说明书中提及了设备和方法发明二者，设备和方法发明二者的描述可补充地应用于彼此。
本发明的模式
在具体实施方式中描述了各种实施方式。
工业实用性
本发明可用于一系列广播服务提供领域。
对于本领域技术人员而言将显而易见的是，在不脱离本发明的精神或范围的情况下可对本发明进行各种修改和变化。因此，本发明旨在涵盖本发明的这些修改和变化，只要它们落入所附权利要求及其等同物的范围内即可。

Claims (6)

1.一种在显示广播内容的主装置处处理交互服务数据的方法，该方法包括以下步骤：
在所述主装置中执行主应用；
多播发现消息，其中，所述发现消息对所述主装置提供的第二屏幕服务进行广告；
从在副装置中运行的副应用接收针对所述第二屏幕服务的描述的请求；
向所述副应用发送所述描述；以及
向所述副应用传送信息来提供交互服务，
其中，传送信息的步骤还包括以下步骤：
通过将激活触发中的信息与应用参数表中的信息组合来增强所述激活触发，
其中，所述应用参数表包括具有与应用有关的元数据的应用元素、具有与事件有关的元数据的事件元素和具有由所述事件使用的数据集的数据元素，并且
其中，所述激活触发包括标识来自所述应用参数表的目标事件的第一项和指示针对所述目标事件的激活时间的第二项；并且
在由所述第二项指示的激活时间向所述副应用传送增强的激活触发，
其中，增强的激活触发包括第一元数据、第二元数据和数据集，所述第一元数据与应用元素中的应用ID被所述第一项参考的应用有关，所述第二元数据与事件元素中的事件ID被所述第一项参考的目标事件有关，并且所述数据集与数据ID被所述第一项参考的数据元素有关。
2.根据权利要求1所述的方法，该方法还包括以下步骤：
从所述副应用接收针对双向通信服务的订用，其中，所述双向通信服务是所述第二屏幕服务中的用于建立传输控制协议/网际协议TCP/IP连接的一个第二屏幕服务。
3.根据权利要求2所述的方法，该方法还包括以下步骤：
在所述主应用与所述副应用之间建立所述TCP/IP连接；以及
经由所述TCP/IP连接从所述主应用向所述副应用发送所述交互服务数据，其中，所述副应用利用来自所述主应用的所述交互服务数据提供与所述广播内容相关的所述交互服务。
4.一种用于在显示广播内容的主装置处处理交互服务数据的设备，该设备包括：
执行模块，其在所述设备中执行主应用；
UPnP模块，其多播发现消息，其中，所述发现消息对所述主装置提供的第二屏幕服务进行广告，其中，所述UPnP模块从在副装置中运行的副应用接收针对所述第二屏幕服务的描述的请求并且向所述副应用发送所述描述；以及
提供模块，其向所述副应用传送信息来提供交互服务，
其中，所述提供模块向所述副应用传送信息还包括以下步骤：
通过将激活触发中的信息与应用参数表中的信息组合来增强所述激活触发，
其中，所述应用参数表包括具有与应用有关的元数据的应用元素、具有与事件有关的元数据的事件元素和具有由所述事件使用的数据集的数据元素，并且
其中，所述激活触发包括标识来自所述应用参数表的目标事件的第一项和指示针对所述目标事件的激活时间的第二项；并且
在由所述第二项指示的激活时间向所述副应用传送增强的激活触发，
其中，增强的激活触发包括第一元数据、第二元数据和数据集，所述第一元数据与应用元素中的应用ID被所述第一项参考的应用有关，所述第二元数据与事件元素中的事件ID被所述第一项参考的目标事件有关，并且所述数据集与数据ID被所述第一项参考的数据元素有关。
5.根据权利要求4所述的设备，其中，所述UPnP模块从所述副应用接收针对双向通信服务的订用，其中，所述双向通信服务是所述第二屏幕服务中的用于建立传输控制协议/网际协议TCP/IP连接的一个第二屏幕服务。
6.根据权利要求5所述的设备，其中，所述UPnP模块在所述主应用与所述副应用之间建立所述TCP/IP连接，并且
其中，所述UPnP模块经由所述TCP/IP连接从所述主应用向所述副应用发送所述交互服务数据，其中，所述副应用利用来自所述主应用的所述交互服务数据提供与所述广播内容相关的所述交互服务。
CN201380062174.4A 2012-11-28 2013-11-26 处理交互服务的设备和方法 Active CN104871552B (zh)

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
US201261730937P 2012-11-28 2012-11-28
US61/730,937 2012-11-28
US201261736529P 2012-12-12 2012-12-12
US61/736,529 2012-12-12
PCT/KR2013/010788 WO2014084570A1 (en) 2012-11-28 2013-11-26 Apparatus and method for processing an interactive service

Publications (2)

Publication Number Publication Date
CN104871552A CN104871552A (zh) 2015-08-26
CN104871552B true CN104871552B (zh) 2018-05-01

Family

ID=50774515

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201380062174.4A Active CN104871552B (zh) 2012-11-28 2013-11-26 处理交互服务的设备和方法

Country Status (8)

Country Link
US (1) US9516384B2 (zh)
EP (1) EP2926568A4 (zh)
JP (1) JP6247309B2 (zh)
KR (1) KR102040623B1 (zh)
CN (1) CN104871552B (zh)
CA (1) CA2889868C (zh)
MX (1) MX345034B (zh)
WO (1) WO2014084570A1 (zh)

Families Citing this family (58)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2003026275A2 (en) 2001-09-19 2003-03-27 Meta Tv, Inc. Interactive user interface for television applications
US8413205B2 (en) 2001-09-19 2013-04-02 Tvworks, Llc System and method for construction, delivery and display of iTV content
US8042132B2 (en) 2002-03-15 2011-10-18 Tvworks, Llc System and method for construction, delivery and display of iTV content
US11388451B2 (en) 2001-11-27 2022-07-12 Comcast Cable Communications Management, Llc Method and system for enabling data-rich interactive television using broadcast database
US7703116B1 (en) 2003-07-11 2010-04-20 Tvworks, Llc System and method for construction, delivery and display of iTV applications that blend programming information of on-demand and broadcast service offerings
US8352983B1 (en) 2002-07-11 2013-01-08 Tvworks, Llc Programming contextual interactive user interface for television
US11070890B2 (en) 2002-08-06 2021-07-20 Comcast Cable Communications Management, Llc User customization of user interfaces for interactive television
US8220018B2 (en) 2002-09-19 2012-07-10 Tvworks, Llc System and method for preferred placement programming of iTV content
US11381875B2 (en) 2003-03-14 2022-07-05 Comcast Cable Communications Management, Llc Causing display of user-selectable content types
US8578411B1 (en) 2003-03-14 2013-11-05 Tvworks, Llc System and method for controlling iTV application behaviors through the use of application profile filters
US10664138B2 (en) * 2003-03-14 2020-05-26 Comcast Cable Communications, Llc Providing supplemental content for a second screen experience
US8819734B2 (en) 2003-09-16 2014-08-26 Tvworks, Llc Contextual navigational control for digital television
US7818667B2 (en) 2005-05-03 2010-10-19 Tv Works Llc Verification of semantic constraints in multimedia data and in its announcement, signaling and interchange
US11832024B2 (en) 2008-11-20 2023-11-28 Comcast Cable Communications, Llc Method and apparatus for delivering video and video-related content at sub-asset level
US9351037B2 (en) 2012-02-07 2016-05-24 Turner Broadcasting System, Inc. Method and system for contextual advertisement replacement utilizing automatic content recognition
US11115722B2 (en) 2012-11-08 2021-09-07 Comcast Cable Communications, Llc Crowdsourcing supplemental content
US9154841B2 (en) 2012-12-28 2015-10-06 Turner Broadcasting System, Inc. Method and system for detecting and resolving conflicts in an automatic content recognition based system
US9253262B2 (en) * 2013-01-24 2016-02-02 Rovi Guides, Inc. Systems and methods for connecting media devices through web sockets
US9553927B2 (en) 2013-03-13 2017-01-24 Comcast Cable Communications, Llc Synchronizing multiple transmissions of content
US10880609B2 (en) 2013-03-14 2020-12-29 Comcast Cable Communications, Llc Content event messaging
JP6168839B2 (ja) * 2013-05-15 2017-07-26 キヤノン株式会社 情報処理装置、その制御方法、プログラム
JP2015012561A (ja) * 2013-07-02 2015-01-19 ソニー株式会社 表示装置、情報取得方法及び情報提供方法
BR112016006403B1 (pt) 2013-09-23 2023-05-09 Samsung Electronics Co., Ltd Método para inicializar um segundo aplicativo em um segundo dispositivo, método para inicializar um segundo aplicativo através de um segundo dispositivo, primeiro e segundo dispositivos em um sistema de comunicação sem fio
EP2854317A1 (en) * 2013-09-26 2015-04-01 Alcatel Lucent Method for providing a client device with a media asset
CA2944773A1 (en) * 2014-04-11 2015-10-15 Sony Corporation Reception apparatus, reception method, transmission apparatus, and transmission method
CN106537928A (zh) * 2014-06-30 2017-03-22 Lg 电子株式会社 广播发送装置、广播接收装置、用于广播发送装置的操作方法以及用于广播接收装置的操作方法
CN111556342B (zh) * 2014-06-30 2022-04-05 Lg 电子株式会社 用于接收广播信号的装置与方法
CA2959353A1 (en) * 2014-09-05 2016-03-10 Sharp Kabushiki Kaisha Syntax and semantics for device capabilities
WO2016035588A1 (ja) 2014-09-05 2016-03-10 ソニー株式会社 受信装置、受信方法、送信装置、及び、送信方法
US9979993B2 (en) * 2014-09-15 2018-05-22 Verizon Patent And Licensing Inc. Network for personalized content aggregation platform
US11783382B2 (en) 2014-10-22 2023-10-10 Comcast Cable Communications, Llc Systems and methods for curating content metadata
MX2017005212A (es) * 2014-10-28 2017-07-27 Sony Corp Dispositivo de recepcion, dispositivo de transmision, y metodo de procesamiento de datos.
US10205556B2 (en) 2014-11-20 2019-02-12 Lg Electronics Inc. Apparatus for transmitting broadcast signal, apparatus for receiving broadcast signal, method for transmitting broadcast signal and method for receiving broadcast signal
CN104599163A (zh) * 2015-02-23 2015-05-06 佛山市恒南微科技有限公司 一种可溯源的农产品配送券
WO2016178319A1 (en) * 2015-05-06 2016-11-10 Sharp Kabushiki Kaisha Carrying multiple event times within a trigger
CA2986763C (en) * 2015-05-26 2020-06-23 Lg Electronics Inc. Broadcasting signal transmitting apparatus, broadcasting signal receiving apparatus, broadcasting signal transmitting method, and broadcasting signal receiving method
US10779057B2 (en) * 2015-06-08 2020-09-15 Qualcomm Incorporated Broadcast content redistribution and ad insertion
WO2017014553A1 (ko) 2015-07-21 2017-01-26 엘지전자 주식회사 방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호 송신 방법, 및 방송 신호 수신 방법
US10681147B2 (en) 2016-08-15 2020-06-09 Saturn Licensing Llc URLs for acquiring or transmitting data
US10893011B2 (en) * 2016-09-13 2021-01-12 Gluru Limited Semantic interface definition language for action discovery in cloud services and smart devices
TWI640195B (zh) 2016-12-14 2018-11-01 日商夏普股份有限公司 具有統一資源識別符訊息浮水印有效負載之廣播系統
US10701438B2 (en) 2016-12-31 2020-06-30 Turner Broadcasting System, Inc. Automatic content recognition and verification in a broadcast chain
EP3627322A4 (en) 2017-06-14 2020-04-29 Beijing Xiaomi Mobile Software Co., Ltd. APPLICATION INTERACTION METHOD, INTERACTION METHOD AND DEVICE
CN108139952B (zh) * 2017-06-14 2022-08-05 北京小米移动软件有限公司 应用交互方法、交互方法及装置
US11202252B2 (en) * 2018-02-06 2021-12-14 Telefonaktiebolaget Lm Ericsson (Publ) Inclusion of a message proxy in a service based architecture
CN108614978B (zh) * 2018-04-19 2022-04-15 中国平安人寿保险股份有限公司 压缩包的校验方法、装置、存储介质以及终端
US10740079B2 (en) * 2018-05-15 2020-08-11 Microsoft Technology Licensing, Llc Maintaining tight coupling between driver and application versions
CN111372135A (zh) * 2018-12-25 2020-07-03 中国移动通信集团浙江有限公司 一种机顶盒应用自动适配方法及系统
US11095927B2 (en) 2019-02-22 2021-08-17 The Nielsen Company (Us), Llc Dynamic watermarking of media based on transport-stream metadata, to facilitate action by downstream entity
WO2020231821A1 (en) 2019-05-10 2020-11-19 The Nielsen Company (Us), Llc Content-modification system with fingerprint data match and mismatch detection feature
US11736742B2 (en) 2019-05-10 2023-08-22 Roku, Inc. Content-modification system with responsive transmission of reference fingerprint data feature
WO2020231927A1 (en) 2019-05-10 2020-11-19 The Nielsen Company (Us), Llc Content-modification system with responsive transmission of reference fingerprint data feature
US11234050B2 (en) 2019-06-18 2022-01-25 Roku, Inc. Use of steganographically-encoded data as basis to control dynamic content modification as to at least one modifiable-content segment identified based on fingerprint analysis
US11704390B2 (en) * 2019-10-10 2023-07-18 Baidu Usa Llc Method and system for signing an artificial intelligence watermark using a query
US11405674B2 (en) 2019-11-12 2022-08-02 The Nielsen Company (Us), Llc Methods and apparatus to identify media for ahead of time watermark encoding
US11012757B1 (en) 2020-03-03 2021-05-18 The Nielsen Company (Us), Llc Timely addition of human-perceptible audio to mask an audio watermark
KR102504102B1 (ko) 2022-10-19 2023-02-28 주식회사 와이드테크 인터넷 텔레비전을 이용한 라이브 방송 송출 서비스 제공 방법을 제공하는 텔레비전
CN116302076B (zh) * 2023-05-18 2023-08-15 云账户技术(天津)有限公司 一种基于解析配置项表结构进行配置项配置的方法及装置

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2012112011A2 (ko) * 2011-02-20 2012-08-23 엘지전자 주식회사 심리스 콘텐트 재생 방법 및 장치

Family Cites Families (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
AU2003239385A1 (en) * 2002-05-10 2003-11-11 Richard R. Reisman Method and apparatus for browsing using multiple coordinated device
KR100717060B1 (ko) * 2005-12-05 2007-05-10 삼성전자주식회사 홈 네트워크를 통해 ｄｖｄ 컨텐츠를 이용하는 방법 및장치
CN101227418B (zh) * 2007-01-19 2012-04-04 华为技术有限公司 一种实现融合ip消息的方法、装置及系统
US8775647B2 (en) 2007-12-10 2014-07-08 Deluxe Media Inc. Method and system for use in coordinating multimedia devices
US8521078B2 (en) * 2008-03-21 2013-08-27 Qualcomm Incorporated Common interface protocol for sending FR-RDS messages in wireless communication systems
GB2466289A (en) * 2008-12-18 2010-06-23 Veda Technology Ltd Executing a service application on a cluster by registering a class and storing subscription information of generated objects at an interconnect
US8621520B2 (en) * 2009-05-19 2013-12-31 Qualcomm Incorporated Delivery of selective content to client applications by mobile broadcast device with content filtering capability
EP2343881B1 (en) * 2010-01-07 2019-11-20 LG Electronics Inc. Method of processing application in digital broadcast receiver connected with interactive network, and digital broadcast receiver
US8863171B2 (en) * 2010-06-14 2014-10-14 Sony Corporation Announcement of program synchronized triggered declarative objects
US8516528B2 (en) * 2010-06-30 2013-08-20 Cable Television Laboratories, Inc. Synchronization of 2nd screen applications
EP2472855A1 (en) * 2010-12-29 2012-07-04 Advanced Digital Broadcast S.A. Television user interface

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2012112011A2 (ko) * 2011-02-20 2012-08-23 엘지전자 주식회사 심리스 콘텐트 재생 방법 및 장치

Also Published As

Publication number Publication date
MX345034B (es) 2017-01-16
US20140150022A1 (en) 2014-05-29
US9516384B2 (en) 2016-12-06
JP2016506114A (ja) 2016-02-25
KR102040623B1 (ko) 2019-11-27
CA2889868C (en) 2018-01-02
EP2926568A1 (en) 2015-10-07
WO2014084570A1 (en) 2014-06-05
KR20150090049A (ko) 2015-08-05
CA2889868A1 (en) 2014-06-05
CN104871552A (zh) 2015-08-26
EP2926568A4 (en) 2016-06-08
MX2015005930A (es) 2015-09-08
JP6247309B2 (ja) 2017-12-13

Similar Documents

Publication Publication Date Title
CN104871552B (zh) 处理交互服务的设备和方法
CN104737549B (zh) 处理交互服务的设备和方法
CN104584574B (zh) 处理交互服务的设备和方法
CN104662925B (zh) 处理交互服务的设备和方法
JP5997839B2 (ja) 対話型サービスを処理する装置及び方法

Legal Events

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