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

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

Info

Publication number
CN104904230B
CN104904230B CN201380054691.7A CN201380054691A CN104904230B CN 104904230 B CN104904230 B CN 104904230B CN 201380054691 A CN201380054691 A CN 201380054691A CN 104904230 B CN104904230 B CN 104904230B
Authority
CN
China
Prior art keywords
trigger
event
application
receiver
activation
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
CN201380054691.7A
Other languages
English (en)
Other versions
CN104904230A (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 CN104904230A publication Critical patent/CN104904230A/zh
Application granted granted Critical
Publication of CN104904230B publication Critical patent/CN104904230B/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/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/81—Monomedia components thereof
    • H04N21/8126—Monomedia components thereof involving additional data, e.g. news, sports, stocks, weather forecasts
    • H04N21/8133—Monomedia components thereof involving additional data, e.g. news, sports, stocks, weather forecasts specifically related to the content, e.g. biography of the actors in a movie, detailed information about an article seen in a video program
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/51—Discovery or management thereof, e.g. service location protocol [SLP] or web services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/50—Network service management, e.g. ensuring proper service fulfilment according to agreements
    • H04L41/5058—Service discovery by the service manager
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1083—In-session procedures
    • H04L65/1093—In-session procedures by adding participants; by removing participants
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1083—In-session procedures
    • H04L65/1094—Inter-user-equipment sessions transfer or sharing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/61—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
    • H04L65/611—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for multicast or broadcast
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/21—Server components or server architectures
    • H04N21/222—Secondary servers, e.g. proxy server, cable television Head-end
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/235—Processing of additional data, e.g. scrambling of additional data or processing content descriptors
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/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/4302—Content synchronisation processes, e.g. decoder synchronisation
    • H04N21/4307—Synchronising the rendering of multiple content streams or additional data on devices, e.g. synchronisation of audio on a mobile phone with the video output on the TV screen
    • H04N21/43079—Synchronising the rendering of multiple content streams or additional data on devices, e.g. synchronisation of audio on a mobile phone with the video output on the TV screen of additional data with content streams on multiple devices
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/435—Processing of additional data, e.g. decrypting of additional data, reconstructing software from modules extracted from the transport stream
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/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/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/437—Interfacing the upstream path of the transmission network, e.g. for transmitting client requests to a VOD server
    • 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/85—Assembly of content; Generation of multimedia applications
    • H04N21/858—Linking data to content, e.g. by linking an URL to a video object, by creating a hotspot
    • H04N21/8586—Linking data to content, e.g. by linking an URL to a video object, by creating a hotspot by using a URL
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/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/85—Assembly of content; Generation of multimedia applications
    • H04N21/854—Content authoring
    • H04N21/8543—Content authoring using a description language, e.g. Multimedia and Hypermedia information coding Expert Group [MHEG], eXtensible Markup Language [XML]

Abstract

公开了一种处理交互服务的方法及其设备。本发明包括以下步骤：向在第二装置中运行的第二屏幕应用发送发现消息，其中，所述发现消息通告所述第一装置能够提供的第二屏幕支持服务；从所述第二屏幕应用接收对所述第二屏幕支持服务的描述的请求；向所述第二屏幕应用发送具有所述描述的响应；使用允许所述第二装置访问由所述第一装置在广播流中接收到的文件的HTTP代理服务器服务来提供HTTP代理服务器，其中，所述HTTP代理服务器服务是所述第二屏幕支持服务中的一个；从所述广播流接收所述文件；以及经由所述HTTP代理服务器将所述文件递送给所述第二装置。

Description

处理交互服务的设备和方法
技术领域
本发明涉及用于提供、接收并且处理广播服务的方法和设备，并且更具体地，涉及一种用于提供与广播内容有关的补充服务的方法和设备。
背景技术
TV首先出现在19世纪末并且自20世纪末以来随着屏幕显示方法或其设计已被连续地开发而已成为最流行的信息递送设备。然而，TV通常使得观看者能够从广播站接收单向信息。自二十世纪90年代以来随着个人计算机(PC)和互联网已取得广泛使用，这样的TV限制已变得有问题。因此，TV已经被开发为能够提供交互服务。
然而，当前，不存在用于在内容提供方与观看者之间提供交互服务的系统。具体地，为了提供这样的交互服务，存在对于在特定时间执行与当前正被广播的广播内容有关的应用并且通过特殊信息处理将有关信息提供给观看者的方法的需要。
发明内容
技术问题
设计来解决问题的本发明的目的在于在当广播内容被重放时的时段期间的适当时间与广播内容有关的补充信息。
问题的解决方案
本发明的目的能够通过提供一种在第一装置处处理交互服务的方法来实现，该方法包括以下步骤：向在第二装置中运行的第二屏幕应用发送发现消息，其中，所述发现消息通告所述第一装置能够提供的第二屏幕支持服务；从所述第二屏幕应用接收对所述第二屏幕支持服务的描述的请求；向所述第二屏幕应用发送具有所述描述的响应；从广播流或互联网服务器接收触发器；以及使用触发器服务将所述触发器递送给所述第二装置，其中，所述触发器服务是所述第二屏幕支持服务中的一个，其中，所述触发器服务用于递送所述触发器，其中，所述触发器是其功能在于识别信令并且为由应用参数表描述的段建立以应用为目标的交互事件的播出的定时，其中，所述触发器是时基触发器、激活触发器、交互触发器或频道改变触发器中的一个，其中，所述时基触发器用来为所述事件建立时基，其中，所述激活触发器为所述事件设定激活时间，其中，所述交互触发器被用于除触发声明对象交互模型以外的交互模型，其中，每当频道被改变时所述频道改变触发器被递送。
优选地，所述方法还包括以下步骤：在发送所述发现消息之前接收用于搜索包括提供所述第二屏幕支持服务的所述第一装置的装置的搜索消息。
优选地，所述触发器服务提供未过滤流选项，并且所述未过滤流选项是递送所有类型的触发器的选项。
优选地，所述触发器一被所述第一装置接收到所述第一装置就递送所述所有类型的触发器。
优选地，递送所述触发器包括以下步骤：将来自所述激活触发器的信息与来自所述应用参数表的信息组合以生成增广激活触发器并且将所生成的增广激活触发器发送到所述第二屏幕应用。
优选地，所述触发器服务提供过滤流选项，并且所述过滤流选项是递送作为所述增广激活触发器、所述交互触发器或所述频道改变触发器中的一个的所述触发器的选项。
优选地，所述增广激活触发器包括具有与所述应用参数表中的应用元素的URL 元素相同的值的应用URL信息，所述URL元素识别作为所述应用的一部分的文件，并且所述应用元素由所述激活触发器识别。
优选地，所述增广激活触发器还包括表示所述应用参数表中的事件元素的事件信息，其中，由所述激活触发器识别的所述事件元素表示针对所述应用的所述事件，其中，所述事件信息包括具有与由所述激活触发器识别的所述事件元素的动作属性相同的值的动作信息，并且其中，所述动作属性指示要在所述事件被激活时应用的动作的类型。
优选地，所述第一装置在所述增广激活触发器的激活时间递送所述增广激活触发器，其中，当所述交互触发器被所述第一装置接收到时所述第一装置递送所述交互触发器，并且其中，当所述频道被改变时所述第一装置递送所述频道改变触发器。
在本发明的另一方面中，本文所提供的是一种在第二装置中运行的第二屏幕应用处处理交互服务的方法，该方法包括以下步骤：从第一装置接收发现消息，其中，所述发现消息通告所述第一装置能够提供的第二屏幕支持服务；向所述第一装置发送对所述第二屏幕支持服务的描述的请求；从所述第一装置接收对所述描述的响应；使用所述描述中给出的信息来访问触发器服务并且使用所述触发器服务从所述第一装置接收触发器，其中，所述触发器服务是所述第二屏幕支持服务中的一个，其中，所述触发器是其功能在于识别信令并且为由应用参数表描述的段建立以应用为目标的交互事件的播出的定时的信令元素，其中，所述触发器是时基触发器、激活触发器、交互触发器或频道改变触发器中的一个，其中，所述时基触发器用来为所述事件建立时基，其中，所述激活触发器为所述事件设定激活时间，其中，所述交互触发器被用于除触发声明对象交互模型以外的交互模型，其中，每当频道被改变时所述频道改变触发器被递送。
优选地，所述方法还包括以下步骤：在接收所述发现消息之前组播用于搜索包括提供所述第二屏幕支持服务的所述第一装置的装置的搜索消息。
优选地，所述触发器服务提供未过滤流选项，并且所述未过滤流选项是递送所有类型的触发器的选项。
优选地，所述所有类型的触发器被尽可能快地递送。
优选地，接收触发器包括接收通过将来自所述激活触发器的信息与来自所述应用参数表的信息组合所生成的增广激活触发器。
优选地，所述触发器服务提供过滤流选项，并且所述过滤流选项是递送作为所述增广激活触发器、所述交互触发器或所述频道改变触发器中的一个的所述触发器的选项。
优选地，所述增广激活触发器包括具有与所述应用参数表中的应用元素的URL 元素相同的值的应用URL信息，其中，所述URL元素识别作为所述应用的一部分的文件，并且其中，所述应用元素由所述激活触发器识别。
优选地，所述增广激活触发器还包括表示所述应用参数表中的事件元素的事件信息，其中，由所述激活触发器识别的所述事件元素表示针对所述应用的所述事件，其中，所述事件信息包括具有与由所述激活触发器识别的所述事件元素的动作属性相同的值的动作信息，并且其中，所述动作属性指示要在所述事件被激活时应用的动作的类型。
优选地，所述增广激活触发器在所述增广激活触发器的激活时间被递送，所述交互触发器被尽可能快地递送，并且当所述频道被改变时所述频道改变触发器被递送。
在本发明的另一方面中，本文所提供的是一种用于作为第一装置处理交互服务的设备，该设备包括：第一模块，该第一模块被配置为从广播流或互联网服务器接收触发器；以及第二模块，该第二模块被配置为向在第二装置中运行的第二屏幕应用发送发现消息，其中，所述发现消息通告所述第一装置能够提供的第二屏幕支持服务，从所述第二屏幕应用接收对所述第二屏幕支持服务的描述的请求，向所述第二屏幕应用发送具有所述描述的响应，并且使用触发器服务将所述触发器递送给所述第二装置，其中，所述触发器服务是所述第二屏幕支持服务中的一个，其中，所述触发器服务用于递送所述触发器，其中，所述触发器是其功能在于识别信令并且为由应用参数表描述的段建立以应用为目标的交互事件的播出的定时的信令元素，其中，所述触发器是时基触发器、激活触发器、交互触发器或频道改变触发器中的一个，其中，所述时基触发器用来为所述事件建立时基，其中，所述激活触发器为所述事件设定激活时间，其中，所述交互触发器被用于除触发声明对象交互模型以外的交互模型，其中，每当频道被改变时所述频道改变触发器被递送。
优选地，所述第二模块还被配置为在发送所述发现消息之前接收用于搜索包括提供所述第二屏幕支持服务的所述第一装置的装置的搜索消息。
优选地，所述触发器服务提供未过滤流选项，并且其中，所述未过滤流选项是递送所有类型的触发器的选项。
优选地，所述触发器一被所述第一模块接收到所述第二模块就递送所述所有类型的触发器。
优选地，所述第二模块还被配置为将来自所述激活触发器的信息与来自所述应用参数表的信息组合以生成增广激活触发器并且将所生成的增广激活触发器发送到所述第二屏幕应用。
优选地，所述触发器服务提供过滤流选项，并且其中，所述过滤流选项是递送作为所述增广激活触发器、所述交互触发器或所述频道改变触发器中的一个的所述触发器的选项。
优选地，所述增广激活触发器包括具有与所述应用参数表中的应用元素的URL 元素相同的值的应用URL信息，其中，所述URL元素识别作为所述应用的一部分的文件，并且其中，所述应用元素由所述激活触发器识别。
优选地，所述增广激活触发器还包括表示所述应用参数表中的事件元素的事件信息，其中，由所述激活触发器识别的所述事件元素表示针对所述应用的所述事件，其中，所述事件信息包括具有与由所述激活触发器识别的所述事件元素的动作属性相同的值的动作信息，并且其中，所述动作属性指示要在所述事件被激活时应用的动作的类型。
优选地，所述第二模块在所述增广激活触发器的激活时间递送所述增广激活触发器，当所述交互触发器被所述第一模块接收到时所述第二模块递送所述交互触发器，以及当所述频道被改变时所述第二模块递送所述频道改变触发器。
在本发明的另一方面中，本文所提供的是一种用于作为在第二装置中运行的第二屏幕应用处理交互服务的设备，该设备包括：第一模块，该第一模块被配置为从第一装置接收发现消息，其中，所述发现消息通告所述第一装置能够提供的第二屏幕支持服务，向所述第一装置发送对所述第二屏幕支持服务的描述的请求，并且从所述第一装置接收对所述描述的响应；以及第二模块，该第二模块被配置为使用所述描述中给出的信息来访问触发器服务，并且使用所述触发器服务从所述第一装置接收触发器，其中，所述触发器服务是所述第二屏幕支持服务中的一个，其中，所述触发器是其功能在于识别信令并且为由应用参数表描述的段建立以应用为目标的交互事件的播出的定时的信令元素，其中所述触发器是时基触发器、激活触发器、交互触发器或频道改变触发器中的一个，其中，所述时基触发器用来为所述事件建立时基，其中，所述激活触发器为所述事件设定激活时间，其中，所述交互触发器被用于除触发声明对象交互模型以外的交互模型，其中，每当频道被改变时所述频道改变触发器被递送。
优选地，所述第一模块还被配置为在接收所述发现消息之前组播用于搜索包括提供所述第二屏幕支持服务的所述第一装置的装置的搜索消息。
优选地，所述触发器服务提供未过滤流选项，并且其中，所述未过滤流选项是递送所有类型的触发器的选项。
优选地，所述所有类型的触发器被尽可能快地递送。
优选地，所述第二模块还被配置为接收通过将来自所述激活触发器的信息与来自所述应用参数表的信息组合所生成的增广激活触发器。
优选地，所述触发器服务提供过滤流选项，并且其中，所述过滤流选项是递送作为所述增广激活触发器、所述交互触发器或所述频道改变触发器中的一个的所述触发器的选项。
优选地，所述增广激活触发器包括具有与所述应用参数表中的应用元素的URL 元素相同的值的应用URL信息，其中，所述URL元素识别作为所述应用的一部分的文件，并且其中，所述应用元素由所述激活触发器识别。
优选地，所述增广激活触发器还包括表示所述应用参数表中的事件元素的事件信息，其中，由所述激活触发器识别的所述事件元素表示针对所述应用的所述事件，其中，所述事件信息包括具有与由所述激活触发器识别的所述事件元素的动作属性相同的值的动作信息，并且其中，所述动作属性指示要在所述事件被激活时应用的动作的类型。
优选地，所述增广激活触发器在所述增广激活触发器的激活时间被递送，其中，所述交互触发器被尽可能快地递送，并且其中，当所述频道被改变时所述频道改变触发器被递送。
发明的有益效果
根据本发明，能够使用常规广播系统来提供与广播内容有关的补充信息。
根据本发明，能够检测需要显示与广播内容有关的补充信息的时间并且在适当时间将所述补充信息提供给用户。
根据本发明，能够向第二屏幕装置提供与广播内容有关的补充信息。
附图说明
附图被包括以提供对本发明的进一步理解，附图例示了本发明的实施方式，并且与本说明书一起用来说明本发明的原理。
附图中：
图1是示出了典型广播流的实施方式的图；
图2是示出了在预制内容情况下触发器定时的实施方式的图；
图3是示出了在实况内容情况下触发器定时的实施方式的图；
图4是示出了触发器语法的实施方式的图；
图5是示出了TDO参数表的实施方式的图；
图6是示出了TDO参数表的实施方式的图；
图7是示出了“使用频率”属性值的意义的图；
图8是示出了“目的地”属性值的意义的图；
图9是示出了TDO参数表的二进制形式的语法的实施方式的图；
图10是示出了TDO参数表的二进制形式的语法的实施方式的图；
图11是示出了TDO参数表的二进制形式的语法的实施方式的图；
图12是示出了TDO参数表的二进制形式的语法的实施方式的图；
图13是示出了TDO参数表的二进制形式的语法的实施方式的图；
图14是示出了激活消息表结构的实施方式的图；
图15是示出了URL列表结构图的实施方式的图；
图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和事件信息的方法的实施方式的图；
图57是示出了在第二屏幕装置处访问TPT和第二屏幕应用的方法的实施方式的图；
图58是示出了在第二屏幕装置处访问TPT和第二屏幕应用的方法的实施方式的图；
图59是示出了用于RemoteUI服务器服务的广播信令的另一实施方式的图；
图60是示出了针对第二屏幕服务的装置发现和装置能力交换的实施方式的图；
图61是示出了UPnP论坛的DeviceProfile XML模式的实施方式的图；
图62是示出了第二屏幕装置的装置配置文件的实施方式的图；
图63是示出了针对第二屏幕服务的Protocolnfo的描述的实施方式的图；
图64是示出了当正在第二屏幕装置中执行AddUIListing动作和RemoteUIListing动作时UIListing的实施方式；
图65是示出了用于RemoteUI客户端服务的单播信令的实施方式的图；
图66是示出了用于RemoteUI客户端服务的单播信令的实施方式的图；
图67是示出了用于RemoteUI客户端服务的单播信令的实施方式的图；
图68是示出了通过ProcessInput动作递送给第二屏幕装置的“EventInfo”信息的实施方式的图；
图69是示出了接收机与第二屏幕装置之间的配置的图；
图70是示出了服务的服务类型和服务ID的实施方式的图；
图71是示出了触发器递送服务的操作构思的图；
图72是示出了生成扩展激活触发器的过程的实施方式的图；
图73是示出了针对增广激活触发器的XML模式描述的实施方式的图；
图74是示出了针对未被增广的触发器的XML模式描述的实施方式的图；
图75是示出了增广激活触发器的格式的实施方式的图；
图76是示出了增广激活触发器的格式的实施方式的图；
图77是示出了增广激活触发器的格式的实施方式的图；
图78是示出了增广激活触发器的格式的实施方式的图；
图79是示出了触发器服务状态变量的实施方式的图；
图80是示出了触发器服务状态变量的实施方式的图；
图81是示出了触发器服务动作的实施方式的图；
图82是示出了GetLatestUnfilteredTrigger动作的变元的实施方式的图；
图83是示出了GetLatestFilteredTrigger动作的变元的实施方式的图；
图84是示出了触发器服务动作的实施方式的图；
图85是示出了当经由触发器递送服务获取触发器时第二屏幕上的操作的实施方式的图；
图86是示出了触发器递送服务的操作构思的图；
图87是示出了AppURL服务状态变量的图；
图88是示出了AppURL服务动作的图；
图89是示出了GetAppURL动作的变元的图；
图90是示出了代理HTTP服务器服务的操作构思的图；
图91是示出了代理服务器服务状态变量的实施方式的图；
图92是示出了代理服务器服务动作的实施方式的图；
图93是示出了GetProxyURL动作的变元的实施方式的图；
图94是示出了RequestFiles()的实施方式的图；
图95是示出了第二屏幕装置架构的实施方式的图；
图96是示出了接收机的简化结构的实施方式的图；
图97是示出了第二屏幕装置的结构的实施方式的图；
图98是示出了第二屏幕服务场景的图；
图99是示出了在第一装置处处理交互服务的方法的图；
图100是示出了在第二装置中运行的第二屏幕应用处处理交互服务的方法的图；
图101是示出了用于作为第一装置处理交互服务的设备的实施方式的图；以及
图102是示出了用于作为在第二装置中运行的第二屏幕应用处理交互服务的设备的实施方式的图。
具体实施方式
尽管本发明中所使用的术语是从通常已知且使用的术语中选择的，但是本文所使用的术语可以根据运营商在现有技术中的意图或定制、新技术的出现等而变化。另外，本发明的描述中提到的术语中的一些已经由本申请人以他的或她的判断选择，其详细意义在本文描述的相关部分中被描述。此外，要求本发明不简单地由所使用的实际术语而是由位于之内的各个术语的意义来理解。
在本说明书中，术语媒体时间代表参照音频/视频或音频内容项的播出中的点的参数。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、链接和打包App具有以下意义。
DO(声明对象)可以是构成交互应用的合集。(例如，HTML、JavaScript、CSS、 XML和多媒体文件)
术语“触发声明对象”(TDO)用来迭代地指定已由触发器在触发交互附属数据服务中启动的声明对象，或已由已被触发器启动的DO所启动的DO等。
术语“NRT声明对象”(NDO)用来指定已作为不是触发交互数据服务的NRT服务的一部分被启动的声明对象。
术语“未绑定声明对象”(UDO)用来迭代地指定未被绑定到服务(诸如打包App 或由链路启动的DO)的声明对象，或已由这样的DO启动的DO等。
“链链”是指向提供与当前TV广播节目或NRT服务有关的在线信息或功能性的网站的广播装置提供的URL。
“打包App”是提供广播装置想要给观看者提供的信息或功能性、并且被打包成单个文件以便观看者下载和安装的广播装置提供的声明对象(DO)。
下面将描述其细节。
在本说明书中，时基消息包括时基触发器及其等同物。因此，术语“时基消息”可以与术语“时基触发器”可交换地使用。
在本说明书中，激活消息包括引起激活的所有信息递送，诸如AMT和/或激活触发器中的激活元素。
图1是示出了典型广播流的实施方式的图。
典型广播流包括TV节目的序列。各个TV节目包括底层电视节目，其通常被分解为由广告和/或其它插播材料分开的块。
在图1中，电视节目A的段、Ad1、Ad2、电视节目B的段等被依次包括在广播流中。配置各个电视节目的段可以被称为电视节目内容并且Ads可以被称为插播内容。
各个电视节目或各条插播材料可能或可能不具有与它相关联的交互附属数据服务。
术语“交互服务段”或仅仅“段”将在本说明书中用来指代被广播装置视为集成单元的交互附属服务的部分。交互服务段通常但未必与单个电视节目或单条插播材料相关联。
为了执行这样的交互附属数据服务，存在两个模型：直接执行模型和触发声明对象(TDO)模型。
在直接执行模型中，一选择虚拟频道就能够自动地启动声明对象(DO)。它能够通过互联网与后端服务器进行通信以得到用于提供全部与音频-视频节目同步的交互特征的详细指令-在屏幕上的特定位置中创建显示、进行轮询、启动其它专门DO 等。
在TDO模型中，能够在广播流中或经由互联网递送信号以便发起TDO事件，诸如启动TDO、终止TDO或通过TDO促进某个任务。这些事件能够在特定时间被发起，通常与音频-视频节目同步。当TDO被启动时，它能够提供它被编程为提供的交互特征。
TDO模型后面的基本构思是组成TDO的文件以及要由TDO用来采取某个动作的数据文件，考虑到它们的大小全部需要一定数量的时间以被递送给接收机。虽然能够在内容的广播之前创造交互元素的用户体验，但是必须仔细地对特定行为进行定时以与节目本身中的事件(例如，商业广告段的出现)一致。
TDO模型使声明对象以及相关联的数据、脚本、文本和图形的递送与交互事件的播出的特定定时的信令分开。
建立交互事件的定时的元素是触发器。
关于在段中使用的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>和“://”部分，具有附加的限制。
触发器可以包括locator_part和项。可以省略项。如果项存在，则locator_part和项可以由‘？’连接。
locator_part可以包括可以由‘/’连接的主机名部分和path_segments部分。
主机名可以包括域标签和顶部标签，并且域标签可以连同‘.’一起重复0次或更多次。也就是说，主机名可以包括与顶部标签连接的重复域标签或包括仅顶部标签。
域标签可以包括一个字母数字或包括字母数字或重复地插入在字母数字与字母数字之间0次或更多次的“-”。
这里，字母数字可以意指字母或数字。
这里，字母可以是小写字母或大写字母中的一个。
这里，小写字母可以是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中的一个。
这里，大写字母可以是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中的一个。
这里，数字可以是0、1、2、3、4、5、6、7、8和9中的一个。
顶部标签包括一个字母或包括字母数字或重复地插入在字母与字母数字之间0次或更多次的“-”。
path_segments包括一个段，其后面是重复0次或更多次的段。这时，段可以由‘/’连接。
这里，段包括被重复一次或更多次的字母数字。
项可以包括event_time或media_time中的一个，其可能后面是扩展或其它项。可以省略扩展或其它项。如果扩展或其它项存在，则可以将‘&’放置在扩展和其它项前面并且可以将扩展和其它项放置在event_time或media_time之后。
这里，扩展可以包括在‘s＝’之后重复一次或更多次的数字。
Event_time可以包括在‘e＝’之后重复一次或更多次的数字，或者可以包括在‘&t＝’之后重复一次或更多次或七次或更少次的十六进制数。可以省略‘&t＝’和其后部分。
这里，十六进制数可以是0、1、2、3、4、5、6、7、8、9、a、b、c、d、e和f 中的一个。
Media_time可以包括在‘m＝’之后重复一次或比七次或多或少的十六进制数。
其它项可以包括一个“other”或后面是‘&’和“other”的“other”。
这里，其它可以包括被重复一次或更多次并且由‘＝’连接的resv_cmd和字母数字。
这里，resv_cmd可以是排除‘c’、‘e’、‘E’、‘m’、‘M’、‘s’、‘S’、‘t’和‘T’的字母数字。
触发器的长度可能不超过52个字节。另外，触发器的主机名部分可以是注册的互联网域名。
触发器能够被认为包括三个部分。
<域名部分>/<目录路径>[？<参数>]
<域名部分>可以是注册的域名，<目录路径>可以是如它将出现在URI中的路径。
<域名部分>能够参照注册的互联网域名。<目录路径>可以是标识在拥有对所标识的域名的权限的实体的控制和管理之下的目录路径的任意字符串。
在TDO模型中，<域名部分>和<目录路径>的组合能够唯一地标识能够由接收机处理以将交互性添加到所关联的内容的TPT。
<域名部分>和<目录路径>的组合可以是其中能够获得当前段的TPT的互联网位置的URL。
也就是说，触发器可以使用<域名部分>和<目录路径>来标识TPT。通过<域名部分>和<目录路径>，能够确认触发器适用于的TPT。通过对TPT应用触发器所执行的角色取决于<参数>。
在下文中，将对<参数>进行描述。
<参数>可以包括“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＝”项)能够被用在时基触发器中以标识相对于由时基触发器表示的时基的当前时间。用于标识当前显示的内容的内容标识符信息(“c＝”项)还可以被包括在media_time中。对于“c＝”项，下面将描述直接执行模型。
也就是说，后面是表示十六进制数长度为1至8个字符的字符串、作为媒体时间戳项的“m＝”能够指示当前媒体时间。
“spread”项能够用来指示响应于时基触发器(诸如从服务器中检索TPT)或激活触发器(诸如使TDO访问服务器)而采取的任何动作应该被延迟随机数量的时间，以展开服务器上的工作负荷。
“s＝”项能够指示期间所有接收机应该试图访问在触发器中标识的互联网服务器的时间的秒数。各个单独的接收机能够被预期得到指定间隔内的随机时间并且使访问请求延迟该数量，从而在时间上扩展可能另外在触发器首次出现在接收机处时发生的需求峰值。
包含<媒体时间>参数的触发器能够被称作时间基触发器，因为它用来为事件时间建立时基。
包含<事件时间>参数的触发器能够被称作激活触发器，因为它为事件设定激活时间。
图5和图6是示出了TDO参数表的实施方式的图。
TDO参数表(TPT)包含关于段的TDO以及以它们为目标的事件的元数据。
在下文中，将描述在表中包括的字段。可以根据设计者的意图添加或改变在表中包括的字段的大小和在表中包括的字段的类型。
TPT结构中的字段的详细语义如下。
TDO参数表(TPT)可以包括@majorProtocolVersion属性、@minorProtocolVersion属性、@id属性、@tptVersion属性、@expireDate属性、@updatingTime属性、@serviceID 属性、@baseURL属性、Capabilities、LiveTrigger和/或TDO元素。
TPT是TPT的根元素。一个TPT元素描述一个广播节目段的全部或一部分(在时间上)。
可以为4比特属性的MajorProtocolVersion能够指示表定义的主版本号。能够将主版本号将设定为1。接收机预期丢弃指示它们不能够支持的主版本值的TPT的实例。
当存在时，可以为4比特属性的@MinorProtocolVersion能够指示表定义的次版本号。当不存在时，值缺省为0。能够将次版本号设定为0。接收机预期不丢弃指示它们不能够支持的次版本值的TPT的实例。在这种情况下，它们预期忽略它们不支持的任何单独的元素或属性。
作为URI的@id能够唯一地标识这个TPT元素涉及的交互广播节目段。@id用作段的标识符。因此，在接收机解析TPT之后，与一个段有关的触发器、AMT等可以使用@id信息来和具有用于标识段的@id的TPT匹配。因此，可以找到触发器和 AMT将适用于的段。下面将描述AMT的细节。
可以为8比特整数的@tptVersion能够指示由id属性标识的TPT元素的版本号。每当对TPT做出了任何改变时能够递增tptVersion。
当存在时，TPT元素的@expireDate属性能够指示在这个TPT实例中包括的信息的期满的日期和时间。如果接收机缓存TPT，则能够再使用它直到expireDate为止。
当存在时，可以为16比特元素的@updatingTime能够指示TPT经受修正，并且它给出以秒为单位的推荐间隔以再次下载TPT并且检查新近下载的TPT是新版本。
当存在时，可以为16比特整数的@serviceID能够指示与该TPT实例中描述的交互服务相关联的NRT service_id。当在广播流中递送针对该交互服务的文件时这是需要的以便接收机从服务图表中得到FLUTE参数。
当存在时，@baseURL属性能够给出基础URL，其当被级联到出现在这个TPT 中的任何相对URL的前面上时，它能够给出文件的绝对URL。
当存在时，Capabilities元素能够指示对于与这个TPT相关联的交互服务的有意义呈现来说必要的能力。不具有所需要的能力中的一个或更多个的接收机预期不试图呈现服务。
当且仅当经由互联网递送激活触发器可用时LiveTrigger元素才存在。当存在时，它能够提供由接收机获得激活触发器所需的信息。下面将描述LiveTrigger的子元素和属性。
作为TPT元素的子元素的TDO能够表示应用(例如，TDO)，其在由这个TPT 实例描述的段期间提供交互服务的一部分。下面将描述TDO的子元素和属性。
LiveTrigger元素可以包括@URL属性和/或@pollPeriod属性。
如上所述，当且仅当经由互联网递送激活触发器可用时LiveTrigger元素存在。当存在时，它能够提供由接收机获得激活触发器所需的信息。
作为LiveTrigger元素的属性的@URL能够指示能够经由互联网递送激活触发器的服务器的URL。能够按交互服务提供方的意愿使用HTTP短轮询、HTTP长轮询或 HTTP流经由互联网递送激活触发器。
当存在时，作为LiveTrigger元素的属性的@pollPeriod能够指示短轮询正被用来递送激活触发器，并且pollPeriod属性的值能够指示用于接收机用作轮询周期的以秒为单位的推荐时间。
如果LiveTrigger元素存在，则接收机可以解析TPT并且获得用来使用互联网递送激活触发器的信息。可以利用@URL信息使用可以接收激活触发器的服务器的 URL。通过@pollPeriod信息或指示@pollPeriod属性不存在的信息，可以获得经由互联网递送激活触发器的方法和关于轮询周期的信息。下面将详细地描述@pollPeriod。
TDO元素可以包括@appID属性、@appType属性、@appName属性、@globalID 属性、@appVersion属性、@cookieSpace属性、@frequencyOfUse属性、@expireDate 属性、@testTDO属性、@availInternet属性、@availBroadcast属性、URL、Capabilities、 Contentitem和/或Event元素。
如上所述，作为TPT元素的子元素的TDO能够表示应用(例如，TDO)，其在由这个TPT实例描述的段期间提供交互服务的一部分。
可以为16比特整数的@appID能够在TPT范围内唯一地标识应用。激活触发器借助于对appID的参照来标识用于触发器的目标应用。@appID是应用的标识符。一个TPT可以包括数个应用(诸如TDO)。因此，在解析TPT之后，可以使用@appID 信息来标识应用。将适用于一个应用的触发器、AMT等可以和具有用于标识该应用的@appID的应用匹配。因此，可以找到触发器和AMT将适用于的应用。下面将详细地描述AMT。
可以为8比特整数的@appType能够指示应用格式类型。缺省值可以是1，其能够表示TDO。其它值能够表示其它格式。
作为TDO元素的属性的@appName可以是当观看者的许可寻求启动应用时能够被显示给观看者的人类可读名称。
作为TDO元素的属性的@globalID可以是应用的全局唯一标识符。在许多情况下，接收机将缓存将不久再次使用的app。为了让这个是有用的，下一次它出现时接收机必须能够识别该app。globalID是需要的以用于接收机能够在它再次出现在新的段中时识别app。
作为TDO元素的属性的@appVersion可以是应用的版本号。每当应用(如由globalID所标识的)改变时能够递增appVersion值。如果globalID属性不存在则appVersion属性不能够存在。
可以为8比特整数的@cookieSpace能够指示应用需要多少空间来存储调用之间的持久数据。
可以为4比特整数的@frequencyOfUse能够近似地指示应用将被用在广播中有多频繁，以向接收机提供关于管理它们的应用代码高速缓存空间的指南。下面将详细地描述‘@frequencyOfUse’。
作为TDO元素的属性的@expireDate能够指示在其之后接收机能够安全地删除应用和任何有关资源的日期和时间。
当存在有值“true”时，作为布尔属性的@testTDO能够指示应用仅用于测试目的，并且它能够被普通接收机忽视。
用于@availInternet属性的值“true”能够指示应用可用于通过互联网下载。值“false”能够指示应用不可用于通过互联网下载。当该属性不存在时，缺省值可以是“true”。
用于@availBroadcast属性的值“true”能够指示应用可用于从广播中提取。值“false”能够指示应用不可用于从广播中提取。当该属性不存在时，缺省值可以是“true”。
TDO元素的子元素URL的各个实例能够标识作为应用的一部分的文件。URL 元素可以包括@entry属性。URL元素的属性@entry有值“true”，其能够指示URL是应用的入口点-即，能够被启动以便启动应用的文件。当它有值“false”时，那能够指示URL不是应用的入口点。当属性不出现时的缺省值可以是“false”。作为TDO的子元素的URL元素标识像以上所描述的那样配置应用的文件。接收机解析TPT以获得 URL信息，使用该URL信息来访问服务器，并且下载由该URL信息指示的应用。
当存在时，作为TDO元素的子元素的Capabilities能够指示对于这个应用的有意义呈现来说必要的能力。不具有所需要的能力中的一个或更多个的接收机预期不试图呈现启动应用。
TDO元素的子元素ContentItem能够指示包括由应用所需的一个或更多个数据文件的内容项。ContentItem元素具有关于由这个元件所属于的TDO元素指示的应用所需要的数据文件的信息。如果ContentItem元素在解析之后存在，则接收机可以使用 ContentItem的URL信息等来下载应用所需要的数据文件。下面将描述ContentItem 的子元素和属性。
TDO元素的子元素Event能够表示针对应用的事件。Event元素指示这个元素所属于的应用的事件。事件元素包含指示哪些事件存在、哪一个数据存在、哪一个动作存在等的信息。接收机可以解析事件元素以获得关于应用的事件的信息。下面将描述子元素和事件的属性。
接收机可以接收并且解析TPT以获得TDO的子元素和关于属性的信息。
作为TDO元素的子元素的ContentItem元素可以包括@updateAvail属性、 @pollPeriod属性、@size属性、@availInternet属性、@availBroadcast属性和/或URL 元素。
这里，URL元素可以包括@entry属性。ContentItem元素的子元素URL的各个实例能够标识作为内容项的一部分的文件。URL元素可以包括@entry属性。URL元素的属性@entry有值“true”，其能够指示URL是内容项的入口点-即，能够被启动以便启动内容项的文件。当它有值“false”时，那能够指示URL不是内容项的入口点。当属性不出现时的缺省值可以是“false”。接收机可以在解析之后使用ContentItem的 URL信息来下载应用所需要的数据文件。在这个过程中，可以使用诸如以上描述的其它属性的信息。
作为ContentItem元素的布尔属性的@updatesAvail能够指示内容项是否将被不时更新-即，内容项是否包括静态文件或它是否是实时数据订阅源。当值是“true”时，将不时更新内容项；当值是“false”时，将不更新内容项。当这个属性不出现时的缺省值可以是false。
仅当updatesAvail属性的值是“true”时作为ContentItem元素的属性的@pollPeriod 可以存在。pollPeriod属性的存在能够指示短轮询正被用来递送激活触发器，并且 pollPeriod属性的值能够指示用于接收机用作轮询周期的以秒为单位的推荐时间。
作为ContentItem元素的属性的@Size能够指示内容项的大小。
用于@availInternet属性的值“true”能够指示内容项可用于通过互联网下载。值“false”能够指示内容项不可用于通过互联网下载。当这个属性不存在时，缺省值可以是“true”。
用于@availBroadcast属性的值“true”能够指示内容项可用于从广播中提取。值“false”能够指示内容项不可用于从广播中提取。当这个属性不存在时，缺省值可以是“true”。
事件元素包含关于由事件元素所属于的TDO元素指示的应用的事件的信息。接收机可以解析事件元素以获得关于事件的信息。
作为TDO元素的子元素的事件元素可以包括@eventID、@action属性、 @destination属性、@diffusion属性和/或Data元素。这里，数据元素可以包括@dataID 属性。
可以为Event元素的16比特整数属性的@eventID能够在包含它的TDO元素范围内唯一地标识事件。激活触发器(或AMT中的激活元素)能够通过appID和eventID 的组合来标识触发器的目标应用和事件。当事件被激活时，接收机将事件传递到应用中。@eventID用作事件的标识符。使用@eventID信息，用于激活事件的触发器、AMT 等可以和具有用于标识事件的@eventID的应用匹配。也就是说，激活触发器(或AMT 中的激活元素)能够通过appID和eventID的组合来标识触发器的目标应用和应用。当事件被激活时，接收机将事件传递到应用中。下面将详细地描述AMT。
作为Event元素的属性的@action能够指示要在事件被激活时应用的动作的类型。容许值可以是“prep”、“exec”、“susp”和“kill”。
“prep”能够对应于“Trig prep”动作。如果作为目标的应用的状态是“被释放”，则这个动作能够使状态改变为“就绪”。
“exec”能够对应于“Trig exec”动作。在接收到这个触发器后作为目标的应用的状态能够成为“激活”。
“susp”能够对应于“Trig susp”动作。如果作为目标的应用的状态是“激活”，则在接收到这个触发器后状态能够改变为“被挂起”，否则不存在改变。
“kill”能够对应于“Trig kill”动作。在接收到这个触发器后作为目标的应用的状态能够成为“被释放”。
@action能够指示要在事件被激活时应用的动作的类型。
作为Event元素的属性的@destination能够指示事件的目标装置。在下将详细地描述@destination。
当存在时，可以为Event元素的8比特整数属性的@diffusion能够用秒表示时间的周期T。扩散参数的目的是在服务器加载中使峰值平滑。接收机能够被预期按照10 毫秒的增量计算范围0-T内的随机时间，并且在访问互联网服务器以检索TPT中的URL所参照的内容之前延迟这个数量。
当存在时，作为Event元素的子元素的Data能够提供与事件有关的数据。Event 的不同激活能够具有与它们相关联的不同的Data元素。数据元素可以包括@dataID 属性。作为16比特整数属性的@dataID能够在包含它的Event元素范围内唯一地标识Data元素。当事件的激活具有与它相关联的数据时，激活触发器能够通过AppID、 EventID和DataID的组合来标识Data元素。数据元素指示用于事件的数据。一个事件元素可以具有数个数据元素。数据使用数据元素的@dataID属性来标识。在接收机中，如果与数据有关的事件被激活，则激活触发器(或AMT中的激活元素)能够通过AppID、EventID和DataID的组合来标识Data元素。下面将详细地描述AMT。
图7是示出了“使用频率”属性值的意义的图。
“意义”列指示包含这个应用的段的发生的频率。(当然，属性能够在单个段内出现多次。)如果globalID属性不存在则frequencyOfUse属性不能够存在。如果app将被缓存并且稍后再次使用，则当它再次出现时接收机需要识别它是同一app。这需要 globalId属性。
图8是示出了“destination”属性值的意义的图。
如图8所示，目的地属性值0指示“保留”，目的地属性值1指示仅主装置，目的地属性值2指示仅一个或更多个辅装置2，并且目的地属性值3指示主装置和/或一个或更多个辅装置。
图9、图10、图11、图12和图13是示出了TDO参数表的二进制形式的语法的实施方式的图。
这是以上描述的TPT结构的二进制格式。这个结构是当NRT发送TPT时必需的格式，并且被做出为使得TPT的XML结构被NRT适合地发送。
能够从二进制版本中省略在TPT的XML版本中包含的以下元素和/或属性，因为它们能够由用于在广播流中递送二进制表的封装报头来提供：@protocolVersion(主 /次)、@serviceID和/或@tptVersion。
这些字段的语义如下。将依次描述图9、图10、图11、图12和图13的TDO参数表的二进制格式的字段。
可以为1比特字段的expire_date_included能够指示expire_date字段是否被包括。值“1”能够意味着它被包括；值“0”能够意味着它未被包括。
可以为5比特字段的segment_id_length能够指示segment_id字段的字节长度。
作为可变长度字段的segment_id能够包含段id的字节，所述段id能够具有与TPTXML格式的“id”属性相同的语义。
可以为8比特字段的base_URL_length能够指示base_URL字段的字节长度。
作为可变长度字段的base_URL能够包含基础URL的字节，所述基础URL能够具有与TPT XML格式的baseURL属性相同的语义。
当存在时，可以为32比特字段的expire_date能够指示在这个TPT实例中包括的信息的期满的日期和时间。如果接收机缓存TPT，则能够再使用它直到expireDate为止。无符号整数能够被解释为自1980年1月6日00:00:00UTC以来的GPS秒数减GPS-UTC_offset。GPSUTC偏移可以是定义GPS与UTC时间标准之间的全部秒中的当前偏移的8比特无符号整数。
可以为8比特字段的trigger_server_URL_length能够指示trigger_server_URL字段的字节长度。当这个字段的值是0时，它能够指示单独的激活触发器的互联网递送不可用。
当trigger_server_URL_length的值不为0时，trigger_server_URL能够包含触发器服务器URL的字节，所述触发器服务器URL能够具有与TPT XML格式的LiveTrigger 元素的URL属性相同的语义。
可以为1比特字段的trigger_delivery_type能够指示单独的激活触发器通过互联网的递送模式。值‘0’能够指示HTTP短轮询正被使用；值‘1’能够指示HTTP长轮询或HTTP流正在被用。
可以为8比特整数的poll_period能够指示当HTTP短轮询正被使用时这些轮询之间的推荐秒数。
可以为8比特字段的num_apps_in_table能够指示在这个TPT实例中描述的应用(TDO)的数量。
可以为16比特字段的app_id能够包含这个应用(在num_apps_in_table循环的这个迭代中描述的应用)的标识符。它在这个TPT实例内可以是唯一的。
可以为1比特字段的app_type_included能够指示app_type字段是否被包括用于这个应用。值“1”能够意味着它被包括；值“0”能够意味着它未被包括。
可以为1比特字段的app_name_included能够指示app_name字段是否被包括用于这个应用。值“1”能够意味着它被包括；值“0”能够意味着它未被包括。
可以为1比特字段的global_id_included能够指示global_id字段是否被包括用于这个应用。值“1”能够意味着它被包括；值“0”能够意味着它未被包括。
可以为1比特字段的app_version_included能够指示app_version字段是否被包括用于这个应用。值“1”能够意味着它被包括；值“0”能够意味着它未被包括。
可以为1比特字段的acookie_space_included能够指示cookie_space字段是否被包括用于这个应用。值“1”能够意味着它被包括；值“0”能够意味着它未被包括。
可以为1比特字段的frequency_of_use_included能够指示frequency_of_use字段是否被包括用于这个应用。值“1”能够意味着它被包括；值“0”能够意味着它未被包括。
可以为1比特字段的expire_date_included能够指示expire_date字段是否被包括用于这个应用。值“1”能够意味着它被包括；值“0”能够意味着它未被包括。
当存在时，可以为8比特字段的app_type能够指示这个应用的格式类型。值0 能够指示应用是TDO。如果这个字段不存在，则值能够缺省为0。其它值能够表示其它格式。
当存在时，可以为8比特字段的app_name_length能够指示紧接它之后的 app_name字段的字节长度。这个字段的值0能够指示对于这个应用来说不存在 app_name字段。
当存在时，作为可变长度字段的app_name能够具有与TPT XML格式的TDO元素的appName属性相同的语义。
当存在时，可以为8比特字段的global_id_length能够指示紧接它之后的global_id 字段的字节长度。这个字段的值0能够指示对于这个应用来说不存在global_id字段。
当存在时，作为可变长度字段的global_id能够具有与TPT XML格式的TDO元素的globalId属性相同的语义。
当存在时，可以为8比特字段的app_version具有与TPT XML格式的TDO元素的appVersion属性相同的语义。
当存在时，可以为8比特字段的cookie_space能够具有与TPT XML格式的TDO 元素的cookieSpace属性相同的语义。
当存在时，可以为8比特字段的requency_of_use能够具有与TPT XML格式的 TDO元素的frequencyOfUse属性相同的语义。
当存在时，可以为8比特字段的expire_date能够具有与TPT XML格式的TDO 元素的expireDate属性相同的语义。
可以为1比特字段的test_app能够指示这个应用是否是旨在被普通接收机忽视的测试应用。值‘1’能够意味着它是测试应用；值‘0’能够意味着它不是测试应用。
可以为1比特字段的available_on_internet能够指示这个应用是否可经由互联网得到。值‘1’能够意味着它可经由互联网得到；值‘0’能够意味着它不可经由互联网得到。
可以为1比特字段的available_in_broadcast能够指示这个应用是否可经由互联网得到。值‘1’能够意味着它可经由广播得到；值‘0’能够意味着它不可经由广播得到。可以为4比特字段的number_URL能够指示包括这个应用的文件的数量。
可以为8比特字段的URL_length能够指示紧跟它之后的URL字段的长度。
作为可变长度字段的URL能够具有与TPT XML格式的TDO元素的URL属性相同的语义。
可以为8比特字段的number_content_items能够指示将被下载以用于由这个应用使用的内容项的数量。
可以为1比特字段updates_avail的能够指示这个内容项将被不时更新-即，无论它是一组静态文件还是实时数据订阅源。值‘1’能够指示它将被更新；值‘0’能够指示它将不被更新。
可以为1比特字段的avail_internet能够指示包括这个内容项的(一个或更多个)文件是否能够经由互联网下载。值‘1’能够意味着它们可用于经由互联网下载；值‘0’能够意味着它们是不可得到的。
可以为1比特字段的avail_broadcast能够指示包括这个内容项的(一个或更多个) 文件是否能够经由广播下载。值‘1’能够意味着它们可用于经由广播下载；值‘0’能够意味着它们是不可得到的。
可以为1比特字段的content_size_included能够指示content_size字段是否被包括用于这个应用。值“1”能够意味着它被包括；值“0”能够意味着它未被包括。
可以为4比特字段的number_URL能够指示包括这个内容项的文件的数量。
可以为8比特字段的URL_length能够指示紧跟它之后的URL字段的长度。
作为可变长度字段的URL能够具有与TPT XML格式的TDO元素的ContentItem 子元素的URL属性相同的语义。
可以为24比特字段的content_size能够具有与TPT XML格式的TDO元素的ContentItem子元素的contentSize属性相同的语义。
可以为8比特字段的num_content_descriptors能够指示紧接它之后的描述符循环中的内容描述符的数量。
作为可变长度字段的content_descriptor()可以是符合MPEG-2描述符格式(标签、长度、数据)的描述符。它能够提供关于这个内容项的附加信息。在可以被包括在这个描述符循环中的描述符当中的可以是指示这个内容项的有意义呈现所需的接收机能力的Capabilities描述符。
可以为8比特字段的number_events能够指示针对这个TDO定义的事件的数量。
可以为16比特字段的event_id能够包含这个事件(在number_events循环的这个迭代中描述的事件)的标识符。它在这个应用的范围内可以是唯一的。能够在激活触发器内通过app_id和event_id的组合引用事件。
可以为5比特字段的action能够具有与TPT XML格式的TDO元素的Event子元素的action属性相同的语义。
可以为1比特字段的destination_included能够指示destinationH字段是否被包括用于这个事件。值‘1’能够指示它被包括；值‘0’能够指示它未被包括。
可以为1比特字段的diffusion_included能够指示diffusion字段是否被包括用于这个事件。值‘1’能够指示它被包括；值‘0’能够指示它未被包括。
可以为1比特字段的data_included能够指示data_size字段和data_bytes字段是否被包括用于这个事件。值‘1’能够指示它们被包括；值‘0’能够指示它们未被包括。
当存在时，destination字段的语义可以与TPT XML格式的TDO元素的Event子元素的destination属性的语义相同。
当存在时，diffusion字段的语义可以与TPT XML格式的TDO元素的Event子元素的diffusion属性的语义相同。
当存在时，data_size字段能够指示紧接它之后的data_bytes字段的大小。
当存在时，data_bytes字段能够提供与这个事件有关的数据。当事件被激活时，目标应用将能够读取数据并且使用它来帮助执行所期望的动作。这个字段的内容可以与TPTXML格式的对应TDO元素的对应Event子元素的对应Data子元素的内容相同，除了这个字段能够包含原始二进制值，并且TPT XML格式的Data元素能够包含二进制值的base64编码。
可以为8比特字段的num_app_descriptors能够指示紧接它之后的描述符循环中的描述符的数量。
作为可变长度字段的app_descriptor()可以是符合MPEG-2描述符格式(标签、长度、数据)的描述符。它能够提供关于这个应用(TDO)的附加信息。在可以被包括在这个描述符循环中的描述符当中的是指示这个应用的有意义呈现所需的接收机能力的Capabilities描述符。
可以为8比特字段的num_TPT_descriptors能够指示紧接它之后的描述符循环中的描述符的数量。
作为可变长度字段的TPT_descriptor()可以是符合MPEG-2描述符格式(标签、长度、数据)的描述符。它能够提供关于这个TPT的附加信息。在可以被包括在这个描述符循环中的描述符当中的是指示由这个TPT表示的交互服务的有意义呈现所需的接收机能力的Capabilities描述符。
图14是示出激活消息表结构的实施方式的图。在下文中，将描述在表中包括的字段。可以根据设计者的意图添加或改变在表中包括的字段的大小和在表中包括的字段的类型。
激活消息表(AMT)能够包含针对段的激活触发器的等同物。在特定情况下它能够被递送给接收机代替激活触发器。能够通过ACR服务器、通过“实况触发器”服务器并且经由AMT在隐藏字幕流中递送触发器。
AMT结构中的字段的详细语义如下：
激活消息表(AMT)可以包括@majorProtocolVersion属性、@minorProtocolVersion 属性、@segmentId属性、@beginMT属性和/或Activation元素。
可以AMT元素的为4比特属性的@majorProtocolVersion能够指示AMT定义的主版本号。能够将主版本号设定为1。接收机能够被预期丢弃AMT的指示它们不能够支持的主版本值的实例。
当存在时，可以为AMT元素的4比特属性的@minorProtocolVersion能够指示 AMT定义的次版本号。当不存在时，值能够缺省为0。能够将次版本号设定为0。接收机能够被预期不丢弃AMT的指示它们不能够支持的次版本值的实例。在这种情况下，它们能够被预期忽视它们不支持的任何单独的元素或属性。
作为AMT的标识符的@segmentID和包含这个AMT中的Activation适用于的应用和事件的TPT的标识符。@segmentId可以用作AMT的标识符。因此，接收机可以接收和解析AMT以经由@segmentId信息标识AMT。@segmentId包含指示AMT 适用于哪一个段的信息，和与段有关的TPT的@id匹配，并且用来连接AMT和TPT。此外，可以标识段以提供标识AMT的激活元素的目标TDO和事件所必需的基本信息。
当存在时，作为AMT元素的属性的@beginMT能够指示这个AMT实例提供激活时间所针对的段的开始媒体时间。@beginMT可以指示媒体时间相对于AMT将适用于的段的开始。因此，能够判定当由激活元素指示的激活发生时的时间的准则。因此，如果@beginMT存在，则激活元素中的@startTime属性可能受由@beginMT指示的媒体时间的开始影响。
AMT的Activation元素的各个实例能够表示用来在特定时间激活特定事件的命令，其中特定数据与事件相关联。多个激活元素可以存在于AMT中。各个激活元素执行与激活触发器的角色相似的角色。激活元素可以适用于由AMT中的@segmentId 所指示的段。激活元素的属性可以包含关于在哪一个应用中发生激活、在哪一个事件中发生激活、激活何时发生等的信息。下面将详细地描述激活元素的属性。
激活元素可以包括@targetTDO属性、@targetEvent属性、@targetData属性、 @startTime属性和/或@endTime属性。
作为Activation元素的属性的@targetTDO能够和AMT与其相关联的TPT中的 TDO元素的appID属性匹配，从而标识激活命令的目标应用。@targetTDO可以包含 AMT的激活元素适用于哪一个应用的信息。接收机可以接收和解析AMT以获得 @targetTDO，并且在匹配TPT的TDO元素中找到@appID以标识激活元素将适用于的应用。
作为Activation元素的属性的@targetEvent能够和在由targetTDO属性所标识的TDO元素中包含的Event元素的eventID属性匹配，从而标识激活命令的目标事件。 @targetEvent可以包含AMT的激活元素适用于哪一个应用的哪一个事件的信息。接收机可以接收和解析AMT以获得@targetEvent，并且在匹配TPT的TDO元素中找到 @eventID以标识激活元素将适用于的事件。
作为Activation元素的属性的@targetData能够和在由targetTDO属性和targetEvent属性所标识的Event元素中包含的Data元素的dataID属性匹配，从而标识当激活命令适用时将与目标事件相关联的Data。@targetData可以标识当激活命令适用时与目标事件有关的数据。接收机可以接收和解析AMT以获得@targetData并且在TPT的事件元素中找到@dataID。
作为事件元素的属性的@startTime能够指示事件的有效时间段相对于媒体时间的开始。接收机能够被预期在媒体时间达到startTime中的值或其后尽快执行命令。 @startTime可以指示当事件发生时的开始时间。这个开始时间基于媒体时间。接收机可以解析AMT以获得@startTime信息并且使用@startTime来确认当事件发生时的时间。如果媒体时间达到基于由@segmentId标识的段的媒体时间的startTime则接收机可以激活事件。如果startTime已经过去，则可以尽可能快地激活事件。
当存在时，作为事件元素的属性的@endTime能够指示事件的有效时间段相对于媒体时间的结束。接收机能够被预期在媒体时间通过endTime中的值时不执行命令。 @endTime可以指示事件的结束时间。如果媒体时间达到endTime，则接收机可能不执行事件。
AMT中的Activation元素按照增长startTime值的顺序出现。
当接收机正在根据AMT中的Activation激活事件时，能够预期在其startTime处或其后尽快(例如，在当接收机在startTime之后并在startTime之前的某个时间加入服务并且接收AMT时的情况下)应用各个激活。如果TPT中的事件元素的“action”属性是“exec”，则接收机能够被预期将TriggerEvent传递到目标应用中。将在下面在与API有关的部分中描述TriggerEvent。
图15是示出了URL列表结构图的实施方式的图。
URL列表能够包含接收机的潜在使用的特定URL。URL列表可以包括以下URL 等。
1.针对一个或更多个将来段的TPT的URL，使得接收机能够预先下载文件。
2.从其中能够检索关于广播流中的独立NRT服务的信息的NRT信令服务器的 URL，即使它不能够访问NRT服务信令在广播流中的递送也使得接收机能够访问那些服务。
3.对于虚拟频道能够将使用报告发送到的使用报告服务器的URL，即使它不能够访问这个URL在广播流中的递送也使得接收机能够在这样的报告中发送。
4.针对虚拟频道的PDI-Q表的URL，即使它不能够访问在广播流中递送的PDI-Q 表也使得接收机能够使观看体验个性化。(PDI-Q表与用于在提供交互服务时提供针对用户定制的服务的个性化有关。能够经由PDI-Q表就个性化而询问用户。)
尤其，可以相对于UrsUrl元素做出URL列表以便进一步指示用于使用报告的服务器的URL，以便在商业上使用通过接收机当前观看和消费的内容的优选数据和类型。在URL列表中包括的UrsUrl元素可以被不同地解释如下。
首先，在使用报告服务器情况下，接收机可以利用使用报告服务器的URL通过预定协议(例如，数据结构、XML文件等)执行接收机的使用报告功能。
第二，可能存在在接收机的web浏览器上执行的TDO。在这种情况下，这指示使用报告TDO的位置。在这种情况下，TDO可以直接收集和报告关于存储在接收机中或使用接收机的web浏览器的API(例如，文件API或使用报告API)当前消费的内容的信息。TDO可以使用被称作XMLHttpRequest的Javascript API来发送所收集的数据。
URLlist可以包括UrlList、TptUrl、UrsUrl和/或PdiUrl。这些元素的语义如下。
作为UrlList元素的元素的TptUrl能够将用于将来段的TPT的URL包含在当前交互附属服务中。当包括了多个TptUrl元素时，能够按照段出现在广播中的顺序布置它们。
作为UrlList元素的元素的NrtSignalingUrl能够将接收机能够针对所有虚拟频道从其获得NRT信令表的服务器的URL包含在当前传输流中。
作为UrlList元素的元素的UrsUrl能够包含接收机能够将当前虚拟频道的使用(观众测量)报告发送到的服务器的URL。
作为UrlList元素的元素的PdiUrl能够包括当前虚拟频道的PDI-Q表的URL。
图16是示出了针对包含TPT的专用部分的二进制格式的实施方式的图。图16 例示了其中按照将在下面描述的递送机制在广播流中递送TPT的情况。稍后对细节进行描述。
将给出用于递送触发器、TPT等的递送机制的描述。将依次描述根据交互服务创建输出、在广播流中递送触发器、经由互联网递送触发器、经由互联网递送激活触发器(ACR场景)、在广播流中递送TPT、经由互联网递送TPT、移动TDO和内容项、将多个段组合成一个段。
在下文中，将描述根据交互服务创建的输出。
针对段的服务创建的过程能够产生包含所有TDO和其它内容项的文件夹、XML 格式的TPT文件以及XML格式的AMT文件。可以创建其它结果。
在下文中，将描述在广播流中递送触发器。
当在广播流中递送时，能够在DTV隐藏字幕频道中、在服务#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中)递送激活触发器的情况下，即，在具有“e＝”项、具有或没有“t＝”项的“触发器”格式的情况下，如果“t＝”项存在，则激活时间可以是相对于时基的时间戳。并且如果“t＝”项不存在，则激活时间可以是消息的到达时间。
在其中经由CC服务#6递送时基触发器和激活触发器的情况下，可能存在用于广播装置处理时基触发器和激活处理器的三个可能方式。三个方式是“没有显式时基的段模型”、“具有显式时基的段模型”和“具有显式时基的服务模式”。
能够在逐段基础上在广播内使这些混合。
在没有显式时基的段模式下，激活消息不包括时间戳，使得各个消息的激活时间可以是消息的递送时间，并且时基消息也不包括时间戳，使得它们的唯一目的可以是提供能够递送TPT文件的信令服务器的URL。甚至能够在这种模式下完全地省略时基消息，从而依靠激活消息中的URL来提供信令服务器的URL，但是然后接收机将不能够检索TPT并且开始下载TDO直到在第一激活消息出现之后为止，从而使对第一激活消息的响应延迟一些。
在这种情况下能够出现在CC服务#6中的时基消息能够包含“触发器”格式的“locator_part”以及可能“spread”项，但是没有“media_time”项，并且能够出现在CC服务#6中的激活消息能够包括“触发器”格式的“locator_part”、“event_time”项以及可能“spread”项，但是在“event_time”项中没有“t＝”部分。时基消息和激活消息这二者的“locator_part”可以是当前的segmentId。这个URL还能够用来经由互联网检索段的 TPT。
在具有显式时基的段模式下，时基消息包括时间戳以定义时基，并且激活消息可能包括时间戳以定义相对于时基的激活时间，或者它们可能不包括指示激活时间是消息的到达时间的时间戳。
在这种情况下能够出现在CC服务#6中的时基消息能够包含“触发器”格式的“locator_part”、“media_time”项以及可能“spread”项，并且能够出现在CC服务#6中的激活消息能够包括“触发器”格式的“locator_part”、“event_time”项以及可能“spread”项，在“event_time”项中有或没有“t＝”部分。时基消息和激活消息这二者的“locator_part”可以是当前segmentId，并且时基特定于段。这个URL还能够用来经由互联网检索段的 TPT。
在具有显式时基的服务模式下，时基消息包括时间戳以定义时基，并且激活消息可能或可能不包括时间戳。时基能够跨越多个段延伸，而不是特定于单个段。时基消息的“locator_part”可以是时基的标识符，并且同样是能够用来经由互联网检索服务的 TPT的URL。
在任何情况下将触发器插入到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＝0”项的“触发器”格式情况下，可以经由HTTP短轮询、长轮询或流递送这个。
当经由互联网递送时，能够使用这些机制(单独激活消息递送机制和成批激活触发器递送机制)中的任何一个或两者来递送激活消息。
在下文中，将描述单独激活触发器递送。
如上所述，当经由互联网递送单独的激活触发器时，能够使用HTTP短轮询、长轮询或流递送它们。激活触发器的格式可以确切地与当经由DTVCC服务#6递送它们时相同。
在短轮询情况下，必须指定轮询周期。在这个周期中，可以使用如在下面所描述的TPT中包括的pollPeriod来设定短轮询操作。
当激活触发器的互联网递送是可得到的时，TPT中的LiveTrigger元素的URL属性能够指示能够递送激活触发器的激活触发器服务器。如果LiveTrigger元素的 pollPeriod属性存在于TPT中，则这能够指示HTTP短轮询正被使用，并且它能够指示接收机应该使用的轮询周期。如果LiveTrigger元素的pollPeriod属性不存在于TPT 中，则这能够指示HTTP长轮询或HTTP流正被使用。
不管哪一个协议正被使用，接收机能够被预期利用查询项向激活触发器服务器发出HTTP请求：
？mt＝<media_time>
其中<media_time>可以是观看内容的当前媒体时间。
如果短轮询正被使用，则来自激活触发器服务器的响应能够包含已经在以 <media_time>结束的长度pollPeriod的时间间隔内发出的所有触发器。如果返回了超过一个激活触发器，则它们能够被一个或更多个空格字符分隔。如果没有返回激活触发器，则响应可以是空的。
如果HTTP长轮询或HTTP流正被使用，则激活触发器服务器能够等待返回响应直到当将在广播流中递送激活触发器时的媒体时间为止。这时它能够返回激活触发器。
如果HTTP长轮询正被使用，则激活触发器服务器在返回激活触发器之后能够关闭会话。接收机能够被预期随着更新的媒体时间立即发出另一请求。
如果HTTP流正被使用，则激活触发器服务器在返回各个激活触发器之后能够使会话保持开放，并且它能够随着用于它们被递送的时间到达而通过会话递送附加的激活触发器。
在所有情况下，HTTP响应能够包含以下形式中的一个的HTTP响应报头字段以用信号通知递送模式：
ATSC递送模式：短轮询[<轮询周期>]
ATSC递送模式：长轮询
ATSC递送模式：流
<轮询周期>参数能够指示针对接连轮询的轮询之间的推荐间隔。能够省略<轮询周期>。
在下文中，将描述成批激活触发器递送。
当经由互联网大批递送激活触发器时，能够以多部分MIME消息的形式连同针对段的TPT一起经由HTTP递送针对段的激活触发器，其中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字段能够用来区分同一SCC中承载的不同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()信息。
可以为8比特字段的table_id能够将这个表节标识为属于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字段的值能够反映段出现在广播流中的顺序。
可以为5比特字段的TPT_data_version能够指示这个TPT实例的版本号，其中 TPT实例能够由它的segment_id来定义。因为TPT版本预先是已知的以便确定所接收到的TPT节数据是否是新版本TPT，所以TPT_data_version字段可以存在于节表中。当TPT实例中的任何字段改变时版本号能够按1模32递增。
对于TPT节能够总是将可以为1比特指示符的current_next_indicator设定为‘1’，指示所发送的TPT总是由它的segment_id标识的段的当前TPT。
可以为8比特字段的section_number能够给出这个TPT实例节的节号，其中TPT 实例能够由它的segment_id标识。TPT实例中的第一节的section_number可以是0x00。section_number可能随着TPT实例中的各个附加节递增1。
可以为8比特字段的last_section_number能够给出该节为其一部分的TPT实例的最后一个节(即，具有最高section_number的节)的号码。
可以为16比特字段的service_id能够指定与提供在这个表实例中描述的内容项的交互服务相关联的service_id。
作为可变长度字段的tpt_bytes()能够包括由这个节部分地承载的TPT实例的块。当这个表实例的所有节的tpt_bytes()字段按照它们的section_number字段的顺序级联时，结果可能是完整TPT实例。
也就是说，在使用了TPT的二进制格式或者XML格式被改变为二进制格式之后，可以将TPT划分为适合于在专用节的tpt_bytes()字段中包括并且NRT发送的NRT传输。这时，如果一个TPT被划分成数个专用节，则该专用节可以具有相同的table_id 值、protocol_version值、TPT_data_version值和sequence_number值。可以按照 section_number字段值的顺序插入所划分的TPT块。
接收机可以解析所接收到的专用节。为了再次将专用节组合成一个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和内容项。
网络和站将常常需要提供它们自己的用于递送由TDO使用的TDO和内容项(文件)的HTTP服务器。当这个完成时，能够调整TPT中的baseURL以反映服务器的位置。
在下文中，将描述将多个段组合成一个段。
为了彻底地使段之间的边界混淆，能够将用于多个段的TPT和AMT组合成单个 TPT和AMT。可以执行以下步骤。
1.标识要组合的段的集合。
2.创建具有新的segmentId的新的TPT。
3.如果正被组合的段中的任一个具有实况激活，则提供提供对它们中的全部的访问的中继服务器，并且将用于这个服务器的参数放在“LiveTrigger”元素中。
4.对于如得到完全TDO和ContentItem URL所需的各个段应用baseURL。(也许能标识为正被组合的所有段所共用的较短baseURL，并且使那个保持为组合段的 baseURL。)
5.修订如去除冲突所需的appId值。
6.将针对正被组合的所有段的所有经修订的TDO元素插入到新的TPT中。
7.创建具有等于组合TPT的新的segmentId的segmentId的新的AMT。
8.为新的AMT选择适当新的“beginMT”值。
9.针对正被组合以反映appId值中的任何改变的段来调整AMT文件中的所有Activation元素的targetId值。
10.针对正被组合以反映新的“beginMT”值的段以及正被组合的段的广播时间表来调整AMT文件中的所有Activation元素的startTime值和endTime值。
11.将所有经修订的Activation元素插入到新的AMT中。
图17是示出了编码为XML文档的URL的列表的实施方式的图。
在下文中，将描述经由互联网递送TPT。
当通过互联网递送时，能够经由HTTP递送TPT。用于当前段的TPT的URL可以是时基消息中的“<域名部分>/<目录路径>”。对于TPT的请求的响应能够包括仅仅 TPT，或者它能够包括编码为XML文档的2部分MIME消息，其中所请求的TPT 在第一部分中并且URL的列表在第二部分中。(对请求的响应将总是包括当前段的 TPT。它也可以包括一个或更多个将来段的TPT。)
作为以上描述的响应的第二部分的URL可以具有图17所示的格式。
将描述图17的元素的语义。
“UrlList”能够包含对接收机有用的URL的列表。
“TptUrl”能够包含将来段的TPT的URL。当包括了多个TptUrl元素时，能够按照段出现在广播中的顺序布置它们。
“NrtSignalingUrl”能够包含服务器的URL，其中接收机能够将所有虚拟频道的NRT信令表包含在当前广播流中。
图18是示出了addTriggerEventListener的实施方式的图。
在下文中，将描述用于执行DO的环境的ATSC JavaScript API。
为了支持声明对象动作与广播节目的同步，对于视频/广播对象能够支持附加的方法。
如果经由DTVCC或互联网接收到TPT，则用于执行TDO的数个事件可以存在于TPT中，并且这些事件可以由激活触发器激活。
为了处理这个事件，可以在每eventID基础上注册监听器(Listener)函数。因此，作为以上描述的“附加方法”，可能存在用于注册监听器函数的两个函数addTriggerEventListener和removeTriggerEventListener。
在图18中，描述了addTriggerEventListener并且示出了格式、变元等。
addTriggerEventListener函数能够注册用于处理在每eventId基础上生成的事件的回调函数(listener函数)。addTriggerEventListener函数可以接收EventListener类型的 listener和Number类型的eventId作为变元。下面将描述eventListener类型。addTriggerEventListener函数可能不具有返回值(void)。这里，eventId变元可以是 TPT的事件元素中的eventID。这里，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的事件元素中的eventID。这里，listener变元可以是事件的监听器。
在javascript程序中，如果可以在每eventId基础上生成的事件期望不再被接收或者如果程序“DestroyWindow”完成，则可以取消使用“removeTriggerEventListener”注册的listener函数。
图20是示出了EventListener类型的定义的实施方式的图。
这里，EventListener类型的定义符合web接口定义语言(Web IDL)。Web IDL 能够用来描述旨在被实现在web浏览器中的接口。Web IDL是具有使得公共脚本对象在web平台的行为能够被更容易地指定的许多特征的IDL变例。
EventListener可以是接口对象。EventListener类型可以具有TriggerEvent类型的 event作为变元。
图21是示出了TriggerEvent类型的定义的实施方式的图。
TriggerEvent类型可以包含关于事件的信息。
TriggerEvent类型可以具有作为属性的eventId、data和status。这里，eventId可以是TPT的事件元素中的eventID。这里，data可以是用于事件的这个激活的数据。这里，data可以是十六进制的。这里，status可以意指事件的状态。这里，如果status 值是“触发器”，则这意指其中事件由激活触发器激活的状态。如果status值是“错误”，则这意指其中发生错误的状态。
已经对TDO模型进行了描述。在下文中，将对直接执行模型进行描述。
在直接执行模型中，一选择虚拟频道就能够自动地启动声明对象(DO)。它能够通过互联网与后端服务器进行通信以得到用于提供全部与音频-视频节目同步的交互特征的详细指令-在屏幕上的特定位置中创建显示、进行轮询、启动其它专门DO 等。
在下文中，将描述直接执行模型中的触发器操作。
触发器的角色、功能和语法在直接执行模型中未大大地改变。
触发器的执行相当于以上所描述的执行。
触发器语法相当于以上所描述的触发器语法。
可以认为触发器包括三个部分。
<域名部分>/<目录路径>[？<参数>]
在直接执行模型中，<域名路径>和<目录路径>的组合能够唯一地标识要启动的DO。
<参数>可以包括“event_time”、“media_time”或“spread”中的一个或更多个。
在直接执行模型中，一选择虚拟频道就自动地启动应用。应用能够经由“同步内容协议”通过互联网与后端服务器进行通信。服务器能够给出用于提供全部与音频-视频节目同步的交互特征的详细指令。
在直接执行模型情况下，因为立即执行应用，所以当时基触发器被递送时可以将信息递送给当前执行的应用。在这个模型中，应用需要将关于当前广播的内容的信息连续地递送给服务器以用于同步。为此，时基触发器还可以包括与TDO模型的信息不同的特殊信息。这个特殊信息可以是当前广播的内容的标识符。
类似地，内容标识符可以以参数的形式存在于触发器的参数部分中。
类似地，内容标识符可以以一个项的形式存在于触发器的media_time中。能够被称作可以由后面是字符串的“c＝”所指定的content_id的内容标识符项能够表示当前正被观看的内容的标识符。
content_id项可以旨在支持交互服务实现的直接执行模型。
如上所述，在这个模型中，在应用被启动之后能够将具有content_id项的时基触发器传递到应用中，并且应用能够将content_id递送给后端服务器以便标识交互的上下文。下面将描述其详细操作。
触发器在直接执行模块中的递送机制相当于以上所描述的递送机制。
然而，在广播流中递送触发器情况下，能够在DTV隐藏字幕频道中、在服务#6 中、在URLString命令中递送触发器。并且对于使用直接执行模型的交互服务，能够将URI_type字段设定为2(用于直接执行模型的交互TV触发器)。
在下文中，将描述直接执行模块的总体操作。
作为用于执行交互服务的一个模型，在直接执行模型中，一选择虚拟频道就能够自动地启动应用。应用能够经由“同步内容协议”通过互联网与后端服务器进行通信。服务器能够给出用于提供全部与音频-视频节目同步的交互特征的详细指令-在屏幕上的特定位置中创建显示、进行轮询、启动其它专门DO等。
可以执行操作如下。
首先，能够启动应用。然后，接收时基触发器。时基触发器在已执行应用之后被递送给应用。时基触发器的content_id项可以包括当前显示的内容的内容标识信息。应用能够将content_id递送给后端服务器以便标识交互的上下文，并且以便标识当前正被观看的内容。
已经对直接执行模型进行了描述。
图22是示出了针对WM方法的架构的图。
将给出经由其它接口递送的描述。
定义了使得能够在其中仅未压缩的视频和音频可访问的环境中获取交互服务的协议和架构(例如，如从有线电视或卫星机顶盒接收到的)。架构和协议能够被指定用于由具有互联网连接并且仅能够访问来自广播流的未压缩的音频和视频的接收机使用。当然，如果交互服务提供方选择支持架构和协议则能够成功地使用架构和协议。
能够将架构设计为支持用来标识正被观看的内容的两个基本方法，使得能够经由互联网递送任何关联的交互服务数据增强功能。两个基本方法可以是水印和指纹。
在水印方法和指纹方法这二者中，意图可以是使得接收机能够找出什么广播节目当前正被观看并且获得能够被用作起始点以得到关于用于广播节目的交互服务的附加信息的URL。
图22例示了针对WM方法的架构。
在针对WM方法的架构中，该架构可以包括广播装置22010、水印插入器22011、MVPD 22020、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能够从广播装置/水印插入器接收广播流，其中水印由水印插入器22011在水印ACR系统的情况下插入。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、STB23030、接收机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。 STB 23030可以是根据本发明的实施方式的外部解码单元。
接收机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中一样的水印插入器，但是它将插入代码，而不是接收机所需的信息。还将存在几乎起着与图23中的FP服务器相同的作用的 WM服务器。接收机将给它发送代码，而不是标记图，并且它们将取回它们需要的信息。
将给出访问交互服务的描述。
访问交互服务的描述包括直接执行模型、具有与ACR服务器无关的激活的TDO 模型、具有从ACR服务器接收到的激活的TDO模型的描述。虽然未示出模型，但是这些模型不限于描述，并且可以根据设计者的意图被改变。
取决于广播装置选择和ACR系统的性质，存在用于接收机在ACR环境中访问交互服务的许多不同的方式。交互服务模型可以是直接执行模型或TDO模型，以及在 TDO模型的情况下为Activation，能够独立于ACR服务器递送触发器，或者它们能够由ACR服务器递送。
将给出直接执行模型的描述。
包含具有直接执行模型的交互服务的虚拟频道的ACR过程能够向观看该频道的接收机提供包括media_time(“m＝”)项和content_id(“c＝”)项的时基触发器的等同物。这些触发器可以被标识为用于采用直接执行模型的交互服务的触发器。
当接收机首先接收到具有新的locator_part的这样的触发器时，能够预期将由触发器的locator_part指向的声明对象(DO)加载到它的浏览器中。通常DO将已被预先安装或预先下载并且缓存。否则接收机能够被预期使用HTTP GET请求来下载该 DO。
然后，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元素来在相对于由触发器中的媒体时间项所建立的时基的正确时间激活事件。(这些事件能够包括加载并且执行TDO、使TDO采取特定同步动作、挂起TDO等。)
如果LiveTrigger元素被包括在TPT中，接收机能够被预期使用LiveTrigger元素中用信号通知的轮询方法来从由LiveTrigger元素中的URL标识的实况触发器服务器中检索激活触发器，并且预期使用这些激活触发器来在相对于由触发器中的 media_time项建立的时基的正确时间激活事件。
ATM和实况触发器服务器这二者能够被用于同一服务，通常前者提供静态激活而后者提供动态激活。另选地，当针对段的所有激活是静态的时能够单独使用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)、时基触发器和激活触发器中的一个。
空响应能够指示标记图未被识别，或者(如果ACR摄取模块将帧的标记图包括在没有交互服务的节目段中)标记图表示属于不具有与其相关联的交互服务的段的帧。下面将描述ARC摄取模块。
时基触发器响应能够指示没有事件激活被调度为在客户端的下一个请求之前发生。客户端能够被预期使用时基触发器来维持媒体时间时钟。
激活触发器响应能够指示激活是由于早发生而导致的，其中激活的时间由触发器中的“t＝”项指示。
每当接收机得到具有新的locator_part的触发器时，能够预期立即下载新的TPT，除非它已经使用随着先前的TPT递送的URLList检索到该触发器。
每当接收机获得激活触发器时，能够预期在相对于媒体时间时钟、由触发器中的“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_time MTa露出时，ACR服务器不能够就它而通知接收机直到在本地时间LC3发生的来自接收机的下一个请求为止。在那时ACR服务器响应能够包含具有负<offset>值的激活触发器或包含“现在做(do it now)”激活触发器。
将给出使用事件驱动模型的ACR服务器的描述。
在事件驱动ACR模型中接收机能够被预期发起到ACR服务器的永久连接，周期性地(例如，每5秒)生成内容的标记图，并且通过连接提交标记图。ACR服务器不对各个标记图做出响应。当检测到新的段时或当需要将事件激活传送到接收机时它能够向接收机发送消息。在这个模型中，ACR服务器能够在任何时间向客户端发起消息。
对于正在使用这个事件驱动模型并且正在将激活递送给接收机的ACR服务器，以下规则能够适用于来自ACR服务器的消息。
首先，当ACR服务器从接收机接收到对应于新的段的标记图时，ACR服务器能够立即向接收机发送时基触发器，仅仅以使得接收机能够获得所关联的TPT。
其次，每当事件是由于被激活而导致的时，ACR服务器能够向接收机发送激活触发器。如有可能，它能够稍微在当接收机需要应用激活触发器时的时间的前面发送激活触发器。(这与请求/响应模型中的行为非常相似。)如果ACR服务器获悉激活如此晚以致它不能提前太多发送激活触发器(这在动态事件激活的情况下可能发生)，则它一能够发送它就仍然能够发送激活触发器。在该后者情况下，客户端将因为消息延迟而稍微在激活时间之后得到消息，在这种情况下接收机能够被预期在接收到消息后立即激活事件。
每当接收机得到具有新的locator_part的触发器时，能够被预期立即下载新的TPT，除非它已经使用随着先前的TPT递送的URLList检索到它。
将给出水印ACR系统直接插入信息的描述。虽然未示出水印ACR系统，但是水印ACR系统不限于以下描述并且可以由设计者改变。
在直接插入接收机需要的信息的水印系统的情况下，与帧相关联的水印能够遵循如以上针对请求/响应ACR服务器对于该帧将返回什么所陈述的相同规则如下。请求 /响应ACR服务器能够返回空、时基触发器和激活触发器中的一个。
空响应能够指示标记图未被识别，或者(如果ACR摄取模块将帧的标记图包括在没有交互服务的节目段中)标记图表示属于不具有与它相关联的交互服务的段的帧。
时基触发器响应能够指示没有事件激活被调度为在客户端的下一个请求之前发生。客户端能够被预期使用时基触发器来维持媒体时间时钟。
激活触发器响应能够指示激活是由于早发生而导致的，其中激活的时间由触发器中的“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发现服务器将能够给予接收机包含独立NRT服务以及每个NRT服务的信令服务器URL的广播流的列表。
图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能够使用出于本目的提供的API来从ACR 服务器28080获得激活触发器并且将这些激活触发器传递给主接收机代码。通常ACR 客户端28060将被内置到接收机28050中，但是其它配置是可能的。
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＝”)项插入到触发器中。摄取模块还能够被配置为(当许多接收机很可能正在同时请求新的TPT时)在适合时间(诸如在各个段开始的指定间隔期间)将“spread”(“s＝”)插入到触发器中。
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是在紧接触发器的接收之后的时间跨度L的间隔内。
如果条件(a)、条件(b)或条件(c)中的任一个成立，则激活触发器能够被包括在记录中，其中“e＝”项用来标识要激活的Event，并且“t＝”项用来指示AMT中的 Activation元素的startTime(针对条件(a))或动态触发器的event_time(针对条件 (b))。触发器还能够包含版本(“v＝”)项。
在情况(a)下贯穿从startTime到endTime的间隔继续使激活处理器与帧相关联的原因在于适应通过间隔加入频道通路的接收机。
注意，这个方法在ACR服务器的一部分上不需要额外的智能。它向ACR客户端简单地返回它在数据库中找到的信息。所有智能能够驻留在ACR摄取模块中。而且， ACR摄取模块需要做的计算可能是非常简单的。
利用这个方案，接收机能够对于同一事件激活得到超过一个激活触发器(与不同的帧相关联)是可能的。然而，接收机能够从“t＝”值容易地看到它们全部具有相同的激活时间，所以接收机能够确定它们是复本并且激活事件仅一次。
在“t＝”项上方的情形中的两个下激活触发器能够具有比它与其相关联的帧的media_time早的event_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)的示例。这还可以是以上步骤(4)中的情形(b)的示例，其中 ACR摄取模块在其激活时间之前发送了动态激活触发器至少M个时间单位。
图29示出了包含长度L1、长度L2和长度L3的间隔、在它之前具有长度M的间隔的时间线上方的事件激活时间。时间线下方的垂直箭头示出了单独帧的时间。在长度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)的示例。这也是以上步骤(4)中的情形(b)的示例，其中ACR 摄取模块在其激活时间之前发送了动态激活触发器至少M个时间单位。
图30示出了包含长度L1、长度L2和长度L3的间隔、具有长度M的在先间隔的时间线上方的事件激活时间。时间线下方的箭头示出了单独帧的时间。在长度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之前具有长度M的间隔的时间线上方的事件激活startTime和endTime。时间线下方的箭头示出了单独帧的时间。在长度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之前具有长度M的间隔的时间线上方的事件激活startTime和endTime。时间线下方的箭头示出了单独帧的时间。在长度M的间隔的开头之前或紧跟事件激活endTime之后的各个帧将在数据库中使它与没有 <media_time>项或<event_time>项的触发器相关联。在长度M的间隔内部的各个帧将在数据库中以由在图的底部的两个示例所示的形式具有激活触发器。各个帧的“d＝”项将指示该帧与事件激活时间(由圆圈垂直箭头指示)之间的时间的长度。
圆圈垂直箭头可以表示当典型接收机发送请求时的示例。在这种情况下接收机对于同一事件激活将得到三个激活触发器，但是通过将值<d1>加到接收机的帧f1的本地时间或者将值<d2>加到接收机的帧f2的本地时间或者将(负)值(d3)加到接收机的帧f3的本地时间所计算的激活时间全部给出相同的结果，使得接收机将会将激活时间识别为复本并且仅应用第一个。
当然，图中所示的前两个激活触发器将根本未被在startTime之后加入频道的接收机看到并且随着它的第一请求发送帧f3的标记图。
图33是示出了针对情况(c)的激活触发器的实施方式的图。
图33例示了以上动作(4)中的情形(c)，其中动态激活触发器被发送到ACR 摄取模块晚于激活时间之前M个时间单位。
图33示出了时间线上方的动态事件激活时间以及在当ACR摄取模块获悉事件活动时的事件激活之前不久的时间，其中长度L1的间隔紧跟当ACR摄取模块获悉事件激活时的时间之后。时间线下方的垂直箭头示出了单独帧的时间。在长度L1的间隔的开始之前或紧跟长度L1的间隔的结束之后的各个帧将在数据库中具有与它相关联的时基触发器。在长度L1的间隔内部的各个帧将在数据库中具有激活触发器，诸如在图的底部的示例中的激活触发器。各个帧的“t＝”项将指示相对于媒体时间线(由圆圈垂直箭头指示)的事件激活时间。圆圈垂直箭头可以表示当典型接收机发送请求时的示例。在这种情况下接收机将具有用于事件激活的仅仅一个激活触发器。因为激活触发器的激活时间先于它被接收到的时间，所以接收机将在接收后立即应用触发器。
图34是示出了针对情况(c)的激活触发器的实施方式的图。
将给出针对情况(c)的激活触发器的描述。
图34例示了以上动作(4)中的情形(c)，其中动态激活触发器被发送到ACR 摄取模块晚于激活时间之前M个时间单位。
图34示出了时间线上方的动态事件激活时间以及在当ACR摄取模块获悉事件活动时的事件激活之前不久的时间，其中长度M的间隔紧跟当ACR摄取模块获悉事件激活时的时间之后。时间线下方的箭头示出了单独帧的时间。在长度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处结束的时间间隔内。(如果激活没有endTime，则endTime被认为等于startTime。)(与针对请求/响应ACR模型的条件(a)相同)
(b)动态激活触发器在紧接触发器的激活时间(“t＝<event_time>”)前面的时间跨度M的时间间隔之前被摄取模块接收到，并且帧落在该间隔内。(与针对请求 /响应ACR模型的条件(b)相同)
如果条件(a)或条件(b)中的任何一个成立，则激活触发器能够被包括在记录中，其中“e＝”项用来标识要激活的Event，并且“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个时间单位被递送给ARC摄取模块的触发器的处理。差异是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协议请求TPT服务器(例如 http://xbc.com/tpt504)使用ACR响应2(S37040)中接收到的地址来提供对应TPT 的步骤。
HTTP响应1(S37060)是其中TPT服务器应接收机的请求发送用XML表示的 TPT的步骤。
HTTP请求2(S37070)是其中接收机请求内容服务器使用http协议提供诸如TDO 的应用的步骤。接收机能够解析在TPT中包括的TDO有关信息。TDO有关信息可以是通过其能够下载TDO的内容服务器的URL。能够使用内容服务器的URL来发送请求。
HTTP响应2(S37080)是其中内容服务器应接收机的请求发送所对应的TDO 的步骤。
ACR请求3(S37090)是其中接收机向ACR服务器发送当前观看的节目的帧的标记图的步骤。
ACR响应3(S37100)是其中ACR服务器返回包括地址的触发器(例如xbc.com/tpt504)的步骤，通过所述地址能够获得与对应节目有关的交互服务。在这种情况下，标记图被识别并且有关交互服务存在，与ACR响应1不同(S37020)。也就是说，触发器在这个步骤中可得到。
ACR请求4(S37110)是其中接收机向ACR服务器发送当前观看的节目的帧的标记图的步骤。
ACR响应4(S37120)是其中ACR服务器发送和与从服务器发送的标记图有关的交互服务有关的步骤。能够根据激活触发器在特定时间激活特定事件。
图38示出了在事件驱动ACR情况下的ACR客户端与其它服务器之间的顺序图。
图38示出了根据实施方式的在事件驱动模型中根据ACR服务器和接收机(ACR 客户端)的操作协议高效地发送触发器和TPT的顺序图。
现在将描述事件驱动模型按照请求、对请求的响应和事件的顺序的示例性操作。
在事件驱动ACR情况下的ACR客户端与其它服务器之间的顺序图可以包括 ACR请求1(S38010)、ACR请求2(S38020)、ACR事件1(S37030),HTTP请求 1(S38040)、HTTP请求1(S38050)、HTTP请求2(S38060)、HTTP响应2(S38070)、 ACR请求3(S38080)、ACR事件2(S38090)和/或ACR响应4(S38100)。
ACR请求1(S38010)是其中接收机向服务器发送当前观看的节目的标记图的步骤。服务器可以是以上描述的ACR服务器。标记图可以是指纹标记图或水印。这里，当标记图未被识别或有关交互服务不存在时，ACR服务器可以在不用返回NUL的情况下不发送对ACR请求1的响应，与图37的顺序不同。
ACR请求2(S38020)是其中当频道或节目被改变时、接收机向ACR服务器发送经改变的节目的标记图的步骤。
ACR事件1(S38030)是其中ACR服务器返回包括地址的触发器(例如 xbc.com/tpt504)的步骤，通过所述地址能够获得与对应节目有关的交互服务。这个步骤可以对应于其中标记图被识别并且有关交互服务存在的情况。也就是说，触发器在这个步骤中可得到。在这种情况下，所返回的触发器可以是没有关于media_time 的信息的时基触发器。
HTTP请求1(S38040)是其中接收机通过http协议请求TPT服务器(例如， http://xbc.com/tpt504)使用ACR事件1(S38030)中接收到的地址来提供对应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列表中去除远程UI的URL的动作。ProcessInput 可以是用于向RemoteUI客户端服务发送数据的动作。DisplayMessage可以是用于将消息显示在包括RemoteUI客户端服务的装置上的动作。
图40是示出了UPnP RemoteUI客户端服务的实施方式的图。
在UPnP中，诸如SOAP的XML消息格式可以用来发送以上描述的动作和必要的参数值并且SOAP可以用来远程地执行远程过程。可以使用HTTP发送这些消息。
可以像图40所示的那样执行以上描述的RemoteUI客户端的动作。图40所示的动作仅是以上描述的动作的示例。
可以将UPnP RemoteUI客户端服务的一个实施方式划分成UPnP发现过程和RemoteUI客户端动作。
UPnP发现过程可以包括执行用于第二屏幕服务的UPnP应用(s40001)、查找 UPnP装置(s40010)、查找RemoteUI客户端(s40020)、请求装置描述(s40030)、接收装置描述(s40040)、请求服务控制描述(s40050)和/或接收服务控制描述 (s40060)。
RemoteUI客户端动作可以包括请求装置配置文件(s40070)、接收装置配置文件(s40080)、放置远程UI的URL(s40090)、发送响应1(s40100)、向RemoteUI客户端服务发送消息(s40110)、发送响应2(s40120)和/或用户点击屏幕上的按钮 (s40130)。
执行用于第二屏幕服务的UPnP应用(s40001)可以包括在第二屏幕装置(RemoteUI客户端)中执行UPnP应用。
查找UPnP装置(s40010)可以包括主装置向正在第二屏幕装置中执行的应用组播发现消息。通过这个步骤，可以查找网络中的第二屏幕装置。主装置可以指示从而经由发现消息提供的第二屏幕支持服务。
查找RemoteUI客户端(s40020)可以包括第二屏幕装置接收发现消息并且向主装置发送通知消息。
请求装置描述(s40030)可以包括主装置从第二屏幕装置请求第二屏幕装置的装置描述。
接收装置描述(s40040)可以包括当第二屏幕装置响应于请求装置描述(s40030)而发送第二屏幕装置的装置配置文件时主装置接收第二屏幕装置的装置配置文件。
请求服务控制描述(s40050)可以包括主装置从第二屏幕装置请求服务控制描述。
请求服务控制描述(s40060)可以包括主装置从第二屏幕装置接收所请求的服务控制描述。
存在于网络上的主装置和第二屏幕装置可以经由UPnP发现过程找到并且识别彼此。另外，主装置和第二屏幕装置可以彼此连接。
请求装置配置文件(s40070)可以包括请求第二屏幕装置的装置配置文件。可以利用以上描述的GetDeviceProfile动作。
接收装置配置文件(s40080)可以包括主装置接收所请求的第二屏幕装置的装置配置文件。具有“RemoteUI客户端服务”的装置(第二屏幕装置和RemoteUI客户端) 可以负责如果远程装置(主装置)发送UI的URL地址)则查找UI的URL地址并且将它显示在屏幕上。另外，具有“RemoteUI服务器服务”的装置可以组播UI的URL 地址以向感兴趣的装置通知该URL地址。然而，在这种情况下，因为针对特定装置做出了远程UI，所以应该提供适合于该特定装置的远程UI。因此，还需要发送装置配置文件信息并且请求装置配置文件(s40070)和接收装置配置文件(s40080)可能是必要的。
放置远程UI的URL(s40090)可以包括向第二屏幕装置通知远程UI的URL地址。可以利用以上描述的AddUIListing动作。第二屏幕装置可以将远程UI的URL 地址添加到UIListing。
发送响应1(s40100)可以包括发送放置远程UI的URL(s40090)的结果。根据情况，可以发送诸如HTTP/1.1200OK(请求被成功地处理)、HTTP/1.1501方法未实现(处理请求所必需的功能未被实现)以及HTTP/1.1400未找到(所请求的文件/资源不存在)的响应。
向RemoteUI客户端服务发送消息(s40110)可以包括主装置向第二屏幕装置发送显示消息。显示消息可以包括诸如消息类型的信息。可以利用以上描述的 DispalyMessage动作。第二屏幕装置可以根据显示消息将消息显示在第二屏幕上。
发送响应2(s40120)可以包括发送向RemoteUI客户端服务发送消息(s40110) 的结果。类似于发送响应1(s40100)，可以发送诸如HTTP/1.1200OK的响应。
用户点击屏幕上的按钮(s40130)可以包括用户根据显示在第二屏幕上的消息执行选择。
RemoteUI客户端动作描述经由以上描述的动作操作RemoteUI客户端服务的过程。
在对远程用户接口的描述中，可以考虑到电子设备的资源简化可以被用在现有PC系统中的功能，所述电子设备的功能被添加或限制使得可以在电子设备中使用基于HTML的应用。本描述主要包括两个观点：对消费电子装置应用显示在屏幕上的 HTML以及定义适用于消费电子装置的浏览器API。可以从作为广泛使用的脚本语言的JavaScript调用和使用浏览器API。结果，从JavaScript调用的API调用接收机的功能。
尤其，以上描述的UPnP装置和服务可以由在浏览器中执行的JavaScript执行。存在对用于在浏览器中将其它参数递送给UPnP装置的新API的需要。
图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 可以向附属服务模块41050发送具有URI字符串值的触发器。附属服务模块41050 是可以检测URI字符串值以便获取以上描述的TPT(TDO参数表)的触发器模块。如上所述，能够使用触发器、TPT和TDO来提高附属服务。
图42是示出了针对第二屏幕场景的系统架构的实施方式的图。
对于第二屏幕支持，可能存在数个要求。1)接收机可以连接至一个或更多个第二屏幕装置。2)第二屏幕装置可以是诸如膝上型电脑、平板电脑、智能手机或PDA 的便携式装置。3)第二屏幕的主内容可以是HTML、文本、视频、音频等。4)可以设计在第二屏幕上重放的内容以便不中断主装置(接收机)的广播节目。5)第二屏幕可以经由3GPP网络直接或间接连接至ATSC 2.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接收机加入网络时在他的/她的第二屏幕装置中运行的第二屏幕app (这可能在TV接收机被接通时或可能在其网络接口被启用时发生)。在场景B情况下，用户不具有当TV接收机加入网络时在他的/她的第二屏幕装置中运行的第二屏幕 app。
场景A可以如下。1)提供第二屏幕支持的TV接收机加入网络。2)TV接收机组播它的通告其第二屏幕支持服务的发现消息。3)在第二屏幕装置中运行的第二屏幕app接收组播发现消息并且向TV接收机发送对其服务的描述的请求。4)TV接收机用其服务的描述做出响应。5)第二屏幕app使用描述中给出的信息来访问适当的服务并且提供与TV广播节目同步的交互体验。
场景B可以如下。1)正在TV接收机上观看的TV广播节目进入提供第二屏幕支持的节目段。(这可能是电视机一被接通，或当频道改变从不给交互数据服务提供第二屏幕支持的频道转向提供它的频道时，或当正被观看的频道从不给交互数据服务提供第二屏幕支持的节目段转向提供它的段时。)2)这使TV接收机以某种方式通知观看者第二屏幕支持可用-例如，通过屏幕的拐角中的小图标。3)观看者决定利用第二屏幕支持并且在他的/她的第二屏幕装置上激活第二屏幕app。第二屏幕app然后组播搜索提供第二屏幕支持的装置的消息。TV接收机用其发现消息对这个消息做出响应。4)当第二屏幕app接收到发现消息时，它向TV接收机发送对其服务的描述的请求。5)TV接收机用其服务的描述做出响应。6)第二屏幕app使用描述中给出的信息来访问适当的服务并且提供与TV广播节目同步的交互体验。
场景A还可以如下。1)提供第二屏幕支持的电视机加入网络。(这可能是当电视机被接通时或当其网络接口被启用时。)2)这使TV接收机组播它的通告它本身及其第二屏幕支持服务的发现消息。3)如果用户具有这时正在他的/她的第二屏幕装置中运行的第二屏幕app，则该app接收组播发现消息并且进行到步骤(7)。4)正在 TV接收机上观看的TV广播节目进入提供第二屏幕支持的节目段。(这可能是电视机一被接通，或当频道改变从不给交互数据服务提供第二屏幕支持的频道转向提供它的频道时，或当正被观看的频道从不给交互数据服务提供第二屏幕支持的节目段转向提供它的段时。)5)这使TV接收机以某种方式通知观看者第二屏幕支持可用-例如，通过屏幕的拐角中的小图标。6)如果观看者确实已经具有正在他的/她的第二屏幕装置中运行的第二屏幕App，则该观看者能够决定利用第二屏幕支持并且在他的/她的第二屏幕装置上激活第二屏幕App。第二屏幕App然后组播搜索提供第二屏幕支持的装置的消息。TV接收机用其发现消息对这个消息做出响应。7)当第二屏幕App 接收到发现消息时，它向TV接收机发送对其服务的描述的请求。8)TV接收机用其服务的描述做出响应。这些将是触发器服务以及可选地HTTP代理服务器服务。9) 第二屏幕App将订阅触发器服务的“事件”特征。如果正被提供的交互数据服务的交互模型是直接执行模型，则当触发器被TV接收机接收到时触发器服务将向第二屏幕装置发送所有触发器。如果交互数据服务的交互模型是TDO模型时，则每当新的激活触发器的激活时间达到时触发器服务将向第二屏幕App发送激活触发器。10)第二屏幕App将对触发器起作用，从而从互联网链路或从由TV接收机所提供的HTTP 代理服务器服务按需下载TDO和其它文件，并且将交互服务提供给第二屏幕装置用户。11)每当TV接收机上的TV广播节目转向不给交互数据服务提供第二屏幕支持的段时，触发器服务将向第二屏幕App发送“空触发器”以通知它用于第二屏幕装置的交互数据服务不再可用。12)每当TV接收机上的广播节目进入提供第二屏幕支持的另一段时，第二屏幕装置的用户然后能够关闭第二屏幕App或者让它运行以重新开始相互作用。
在任何一个场景中家庭在家庭网络上有超过一个TV接收机或许是可能的。在这种情况下第二屏幕app将从多个不同的接收机接收到发现消息。如果那发生，则第二屏幕app能够询问用户要与哪一个交互(显示来自描述消息的信息以帮助用户决定)。
提供第二屏幕支持的TV接收机能够为第二屏幕apps的使用提供数个UPnP服务。UPnP服务可以是从接收机到第二屏幕app的“触发器递送服务”、在接收机中运行的声明对象(DO)与第二屏幕app之间的“双向通信服务”以及“HTTP代理服务器服务”。取决于配置，这些服务可以是可选的。
这些服务能够被设计为支持在各式各样不同类型的第二屏幕装置中的各式各样不同的操作环境中运行、从各式各样不同的源获得的各式各样不同类型的第二屏幕应用。
典型的第二屏幕打包apps场景如下。1)第二屏幕装置上的控制点订阅第一屏幕装置上的打包Apps服务。2)消费者在第一屏幕装置上启动打包App。3)打包App 给打包App服务提供第二屏幕app的名称或第二屏幕app的URL。4)第二屏幕装置上的控制点接收伴随app名称和URL。5)控制点在第二屏幕上设定指示所需消费者动作的标记。6)消费者回故第二屏幕app名称并且选择它。7)控制点启动指示的第二屏幕app。
提供第二屏幕支持的第一屏幕装置能够为第二屏幕apps的使用提供数个UPnP 服务。UPnP服务之一是正在提供要在第二屏幕装置上执行的伴随第二屏幕app的名称和URL的“应用URL服务”。
将描述针对第二屏幕场景的系统架构。
针对第二屏幕场景的系统架构可以包括广播系统42010、ACR服务器42020、广播装置ATSC 2.0iTV服务器42030、ATSC 2.0接收机42040和/或第二屏幕装置42050。
广播系统42010可以是普通广播系统并且可以经由广播网络递送触发器、A/V、TPT和/或其它数据文件。可以经由如上所述的DTVCC发送触发器。
ACR服务器42020是用于管理广播内容的ACR有关数据的服务器，并且可以向 ATSC2.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)服务器 (42040)将触发器递送给ATSC 2.0接收机(42040)。在所有情况下，触发器在适当时间被从ATSC 2.0接收机(42040)传递给第二屏幕装置(42050)。本说明书描述了用于触发器被传递给第二屏幕装置(42050)的机制。它还描述了用于在ATSC 2.0接收机(42040)上运行的DO与第二屏幕装置(42050)建立双向通信的机制。
可经由互联网得到的Apps和其它文件如果它提供该服务则能够通过第二屏幕装置(42050)经由家庭网络、经由单独的3GPP网络或经由ATSC 2.0接收机(42040) 上的HTTP代理服务器(未示出)来检索。在第一屏幕装置上执行的Apps可以是从互联网下载的打包Apps或通过广播发送的apps。
只有当ATSC 2.0接收机(42040)提供将在请求时递送FLUTE文件的HTTP代理服务器，在广播中仅可经由FLUTE会话得到的Apps和其它文件才能够由第二屏幕装置(42050)检索到(假定第二屏幕装置(42050)不包括TV接收机)。
本说明书还描述了用于在ATSC 2.0接收机(42040)上运行的打包Apps支持在第二屏幕装置(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服务号6中提取经由DTVCC发送的iTV消息的URL 字符串。另外，必要时ATSC 2.0接收机43030可以连接至家庭网关以访问互联网。 ATSC 2.0接收机43030可以使用家庭联网技术(UPnP)与其它家庭网络中连接的装置进行通信。
第二屏幕装置43040全部连接至家庭网关以与装置进行通信并且以自由地访问互联网。家庭网关可以包括用于支持以太网和Wi-Fi的所有功能。
广播装置可以经由用于交互服务的因特网服务器提供补充服务。ATSC 2.0接收机43030或第二屏幕装置43040可以访问服务器以为移动装置下载TDO或网页。在 ATSC 2.0接收机43030的情况下，网页可以被渲染为TV的分辨率，并且在第二屏幕装置43040的情况下，网页可以被渲染为与TV的那些分辨率和API的不同分辨率和 API。
图44是示出了ATSC 2.0接收机与第二屏幕之间的拓扑(间接连接)的实例方式的图。
图44示出了ATSC 2.0接收机与第二屏幕之间的拓扑(间接连接)的实例方式。
图44例示了ATSC 2.0接收机与第二屏幕装置之间的间接连接。
ATSC 2.0接收机与第二屏幕之间的拓扑(间接连接)的实施方式可以包括广播系统44010、广播装置ATSC 2.0服务器44020、广播装置会话管理装置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网络以通过家庭网络连接至ATSC 2.0接收机44040。在这种情况下，难以将第二屏幕装置44050连接至家庭网络，或者支持家庭网络的网络接口可能不存在。
在这种情况下，第二屏幕装置44050可能需要存储在外部互联网服务器上的关于ATSC 2.0接收机44040的信息。另外，ATSC 2.0接收机44040在操作时向外部互联网服务器报告访问地址。
图45是示出了第二屏幕服务应用的软件层的实施方式的图。
第二屏幕装置通常使用OS来执行应用。一般而言，出于轻便的目的，可以不包括用于移动装置的OS的一些功能。因此，不由OS所支持的功能需要被包括在应用中。
图45的软件层示出了第二屏幕服务所必需的第二屏幕服务应用的软件结构。图45可以示出接收机管理第二屏幕应用的生命周期的情况。
因为第二屏幕装置可以重放互联网内容，所以OS可以使用平台SDK向程序员提供其中可以执行web应用的环境。可以SDK的形式提供环境，使得由OS执行的应用直接显示互联网内容。
在图45中，第二屏幕服务应用可以在第二屏幕装置上运行。能够从应用商店(或一些应用市场)下载这个应用。第二屏幕服务应用能够包括ACR客户端并且使用麦克风和相机来从电视机捕获视频数据和音频数据。而且，ACR客户端能够对视频数据和音频数据进行采样并且向ACR服务器发送介质标记图。第二屏幕服务应用可以在OS上运行并且包括UPnP框架可以根据来操作的诸如HTTP、SSDP或组播事件的协议，并且可以包括浏览器模块以便执行和显示web应用。
浏览器模块可以是用来渲染互联网网页的模块。浏览器模块是用来渲染Web应用(例如，ECMAScript、HTML和XHTML)的web浏览器引擎的核心部分。另外，浏览器模块可以意指用于提供与由OS提供的浏览器相等或相似的功能的软件模块。利用浏览器和可控功能的方法在OS之间不同。
第二屏幕应用可以是针对第二屏幕装置设计的web应用。第二屏幕应用可以是用于根据ECMAScript或web应用调用函数的web应用，其大小被控制为在由移动 OS提供的浏览器模块中被执行。可以在第二屏幕服务应用中执行这个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包括事件信息，并且事件信息可以包括EventId、Action、Destination和Data信息。“Event@Destination”可以指示这个事件信息是针对哪一个装置生成的。例如，目的地可以是接收机或第二屏幕装置。如果目的地被设定为第二屏幕装置，则接收机应该向第二屏幕装置递送事件信息。
因此，存在对将这个信息递送给第二屏幕装置的方法的需要。第二屏幕应用的生命周期可以由接收机或第二屏幕服务应用来管理。
图47的表示出了取决于哪一个实体管理第二屏幕应用的生命周期的信息递送方法的概要。
第一行可以是图51的下面描述的情况的描述的摘要，并且下面将给出其详细描述。
第二行可以是接收机管理第二屏幕应用的生命周期的情况的描述的摘要，并且下面将给出其详细描述。
第三行可以是接收机过滤(增广)并且递送第二屏幕装置所必需的触发器信息的情况的描述的概要，并且下面将给出其详细描述。
第四行可以是图58的下面描述的情况的描述的摘要，并且下面将给出其详细描述。
第五行可以是图57的下面描述的情况的描述的摘要，并且下面将给出其详细描述。
图48是示出了集中式执行模型的操作构思的图。
向第二屏幕装置高效地递送交互服务的方法可以包括集中式执行模型和分布式执行模型。
如示出集中式执行模型的操作构思的图中所示，电视机可以使用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字段来识别递送给第二屏幕装置的动作、TDO URL和数据。第二屏幕装置可能不直接接收诸如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服务器能够给予第二屏幕装置CpmpatibleUIs XSD 模式。这个模式能够包括应用的URL、这个UI的唯一id(“uiID”)、名称、协议信息等。
请求UIListing(s52020)可以包括第二屏幕装置发送其装置配置文件并且请求UIListing。可以使用能够获得兼容UI的GetCompatibleUIs动作。(UIFilter可以是可选的)下面将给出其详细描述。
发送UIListing(s52030)可以包括主装置根据请求向第二屏幕装置发送适当的UI列表。下面将给出其详细描述。
订阅事件(s52040)能够包括订阅主装置的适当暴露的事件。可以选择性执行订阅事件(s52040)以便接收作为通过RemoteUI服务器服务提供的事件信息的“UIListingUpdate”。在返回UIListing(s52080)时，可以通知第二屏幕装置RemoteUI 的地址已被改变或UI已被改变。也就是说，因为仅通知了第二屏幕装置UI已被改变，所以如果需要详细位置或附加信息，则应该向接收机发送“GetCompatibleUIs”动作以获得“UIListing”值。
返回HTTP消息(s52050)可以包括发送订阅事件(s52040)的结果。类似于发送响应1(s40100)，可以根据情况发送诸如HTTP/1.1200OK的响应。
发送UIListingUpdate消息(s52060)可以包括向订户发送“UIListingUpdate”消息。
请求UIListing(s52070)可以包括第二屏幕装置发送其装置配置文件并且请求UIListing。可以使用能够获得兼容UI的GetCompatibleUIs动作。发送UIListingUpdate 消息(s52060)并且请求UIListing(s52070)可以包括执行时间设定，使得第二屏幕应用未被改变并且仅当由服务器支持时是选择性地可能的。这个步骤是可选的。这个方法可以是在接收机处使用UPnP事件来通知所有第二屏幕装置第二屏幕服务存在的方法。也就是说，可以通知家庭网络中的所有第二屏幕装置UI已被与第二屏幕服务相关联地改变。如果使用UPnP事件向所有第二屏幕装置通知了“UIListingUpdate”变量，则第二屏幕装置可以确认UI已被新近更新。其后，第二屏幕装置可以执行“GetCompatibleUIs”动作、选择适合于硬件装置的UI，并且通过参照装置配置文件来执行UI。
返回UIListing(s52080)可以包括主装置根据请求向第二屏幕装置发送适当的UI列表。如上所述，返回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”语法确认“appID”、“URL” (TDO_URL)、“eventID”、“action”以及可选地TDO的“Data”或执行时间。如果接收机管理第二屏幕应用的生命周期，则可以减小要由第二屏幕服务应用处理的信息的量。相比之下，如果第二屏幕服务应用直接管理第二屏幕应用的生命周期，则可以增加必要的信息。
图53是示出了分布式执行模型的操作构思的图。
作为向第二屏幕装置高效地递送交互服务的方法，将对分布式执行模型进行描述。
如示出分布式执行模型的操作构思的图中所示，电视机可以使用UPnP等将诸如触发器的信息递送给第二屏幕装置。各个第二屏幕装置具有触发器处理机并且可以处理诸如经由触发器处理机实时地接收到的触发器的信息。浏览器可以执行与其相关联的交互服务。
与集中式执行模型不同，DAE可以存在于各个第二屏幕装置中。
可以按照以下顺序执行基于分布式执行模型将交互服务递送给第二屏幕装置的过程。1.接收机正在利用第二屏幕支持呈现段。2.接收机显示第二屏幕支持可用的某个指示。3.用户在第二屏幕装置上启动第二屏幕app。4.接收机和第二屏幕装置经由UPnP机制(由接收机上的本机代码和装置上的第二屏幕app执行)发现彼此。 5.电视机得到触发器(从DTVCC流或ACR)以在第二屏幕装置上启动TDO。6.电视机将触发器与来自TPT的信息组合并且在激活时间发送到第二屏幕装置。7.第二屏幕装置下载TDO(一个或更多个文件)并且在浏览器中执行它。8.用户与TDO 交互，这可能使TDO下载附加文件。9.接收机得到触发器以在第二屏幕装置上为TDO生成事件。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时响应于请求而发送TPT(s54030)。
解析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和事件信息的方法的实施方式的图。
图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)可以包括向所有UPnP装置发送“UIListingUpdate”消息。主装置能够向唯一“uiID”列表上的UPnP装置发送UIListingUpdate的通告。第二屏幕装置可以接收这个消息并且检查uiID。然而，由于与特定uiID失配，第二屏幕装置可能不执行UI更新。
发送UIListing(s59030)可以包括向所有UPnP装置发送“UIListingUpdate”消息。与发送UIListing(s59020)不同，匹配uiID可能存在。
请求UIListing(s59040)可以包括第二屏幕装置发送其装置配置文件并且请求UIListing，因为匹配uiID在发送UIListing(s59030)时存在。可以使用能够获得兼容UI的GetCompatibleUIs动作。
返回UIListing(s59050)可以包括主装置根据请求向第二屏幕装置发送适当的UI列表。
图60是示出了针对第二屏幕服务的装置发现和装置能力交换的实施方式的图。
如上所述，如果接收机首先连接至家庭网络，则接收机可以向所有电子设备通知装置描述符及其服务描述符，或者接收来自另一控制点的请求并且发送装置描述符及其服务描述符。
接收接收机的装置描述符和服务描述符的连接至家庭网络的各个UPnP装置可以使用HTTP的“LOCATION(位置)”报头来发送其装置描述符的位置。也就是说，UPnP 装置可以发送UPnP装置描述符的位置。如果使用“LOCATION”做出HTTP GET请求，则可以接收到包括关于装置的信息的XML文件。
在UPnP装置和服务发现中，将引入在主装置处检测能够提供第二屏幕服务的第二屏幕装置的方法。可以主要将这个方法划分成两个方法。作为第一方法，第二屏幕装置准备两个装置配置文件并且使用HTTP报头就装置配置文件的XML文件进行通知。假定不兼容的主装置忽视未被了解的HTTP报头。作为第二方法，在装置配置文件中，可以在“ProtocolInfo”中包括调用了用于提供第二屏幕服务的第二屏幕装置的信息。
图60示出了第一方法。
针对第二屏幕服务的装置发现和装置能力交换的一个实施方式可以包括执行用于第二屏幕服务的UPnP应用(s60001)、查找UPnP装置(s60010)、查找RemoteUI 客户端(s60020)、请求装置描述(s60030)、接收装置描述(s60040)、请求服务控制描述(s60050)、接收服务控制描述(s60060)、请求装置配置文件(s60070)、接收装置配置文件(s60080)、放置远程UI的URL(s60090)、发送响应1(s60100)、向RemoteUI客户端服务发送消息(s60110)、发送响应2(s60120)和/或用户点击屏幕上的按钮(s60130)。
执行用于第二屏幕服务的UPnP应用(s60001)、查找UPnP装置(s60010)、查找RemoteUI客户端(s60020)、请求装置描述(s60030)、接收装置描述(s60040)、请求服务控制描述(s60050)、接收服务控制描述(s60060)、请求装置配置文件 (s60070)、接收装置配置文件(s60080)、放置远程UI的URL(s60090)、发送响应 1(s60100)、向RemoteUI客户端服务发送消息(s60110)、发送响应2(s60120)以及用户点击屏幕上的按钮(s60130)可以分别相当于执行用于第二屏幕服务的UPnP 应用(s40001)、查找UPnP装置(s40010)、查找RemoteUI客户端(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的UIListing 信息被发送到第二屏幕装置(发送UIListing(s52030))。
如果RemoteUI服务器服务不支持所期望的第二屏幕装置，则在发送UIListing(s52030)时，可以返回错误信息以指示RemoteUI服务器服务不能够支持第二屏幕服务。
图64是示出了当正在第二屏幕装置中执行AddUIListing动作和RemoteUIListing动作时UIListing的实施方式。
在针对RemoteUI服务器服务#1的广播信令的实施方式中，将另外描述请求UIListing(s52020)以及发送UIListing(s52030)。
在请求UIListing(s52020)之后，接收机可以检测兼容的RemoteUI信息并且将兼容的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解释为与接收机类似地操作。接收机可以立即改变“UIListingUpdate”变量，并且每当使用DTVCC接收到媒体时间触发器或事件事件触发器时向所有装置发送经改变的变量，使得这些装置执行“GetCompatibleUIs”动作以便接收iTV消息(触发器)的新的URIString。
图65是示出了针对RemoteUI客户端服务的单播信令的实施方式的图。
将对单播信令进行描述。
在这个方法中，RemoteUI客户端服务被包括在第二屏幕装置中。如果UPnP装置首先连接至家庭网络，则UPnP装置通知其它装置新的装置已连接至家庭网络。作为另一方法，如果请求关于新的装置的周期性通知的消息被递送给连接至家庭网络的所有装置，则连接至家庭网络的所有装置可以响应于这个信息而向所有装置发送 NOTIFY消息。首先，应该确定第二屏幕装置是否支持第二屏幕服务。
针对RemoteUI客户端服务的单播信令的一个实施方式可以包括UPnP装置和服务发现(s65010)、请求装置配置文件(s65020)、返回装置配置文件(s65030)、发送TDO URL信息(s65040)、返回HTTP消息(s65050)、发送显示消息(s65060) 和/或返回HTTP消息(s65070)。
UPnP装置和服务发现(s65010)可以相当于UPnP装置和服务发现(s52010)。
请求装置配置文件(s65020)可以包括接收机向新近检测到的第二屏幕装置发送“StaticDeviceInfo”信息以便确定第二屏幕装置是否支持第二屏幕服务。
返回装置配置文件(s65030)是对请求装置配置文件(s65020)的响应，其包含第二屏幕装置的装置配置文件。如果确定了由新近检测到的第二屏幕装置发送的装置配置文件不和“StaticDeviceInfo”匹配或者新近检测到的第二屏幕装置不支持第二屏幕服务，则第二屏幕服务可能不开始。“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.1200OK的响应。
发送显示消息(s65060)可以包括向第二屏幕装置发送显示消息。因为RemoteUI客户端服务具有能够将消息显示在第二屏幕装置的屏幕上的DisplayMessage动作，所以可以向第二屏幕装置发送TDO URL并且可以使用DisplayMessage动作来显示指示与当前观看的广播节目相关联的第二屏幕应用存在的消息。如果用户确认这个消息，则可以立即执行第二屏幕应用。
返回HTTP消息(s65070)可以包括传送发送显示消息(s65060)的结果。类似于发送响应1(s40100)，可以根据情况发送诸如HTTP/1.1200OK的响应。
图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.1200OK的响应。
发送显示消息(s66030)可以包括向第二屏幕装置发送显示消息。在发送RemoveUIListing动作(s66010)之后，可以在第二屏幕装置的屏幕上显示指示执行终止的消息。在这种情况下，可以使用DisplayMessage动作在屏幕上显示适当的消息。
返回HTTP消息(s66040)可以包括发送发送显示消息(s66030)的结果。类似于发送响应1(s40100)，可以根据情况发送诸如HTTP/1.1200OK的响应。
发送TDO URL信息(s66050)可以包括执行AddUIListing动作，使得接收机发送要新近执行的UI的TDO URL。当执行了新的第二屏幕应用时，TDO URL一被添加到UIListing就可以执行第二屏幕服务应用。为了参照，TDO URL涉及可以从接收机直接下载和执行的第二屏幕应用或者可以从互联网服务器下载仅一些资源数据。另外，TDO URL可以指示外部互联网服务地址。如果TDO URL指示外部互联网服务器地址，则可以从互联网服务器下载执行所必需的第二屏幕应用和所有数据。
返回HTTP消息(s66060)可以包括发送发送TDO URL信息(s66050)的结果。类似于发送响应1(s40100)，可以根据情况发送诸如HTTP/1.1200OK的响应。
发送显示消息(s66070)可以包括向第二屏幕装置发送显示消息。在发送TDO URL信息(s66050)之后，可以在第二屏幕装置的屏幕上显示指示提供了新的第二屏幕服务的消息。类似于发送显示消息(s66030)，可以使用DisplayMessage动作在屏幕上显示适当的消息。
返回HTTP消息(s66080)可以包括发送发送显示消息(s66070)的结果。类似于发送响应1(s40100)，可以根据情况发送诸如HTTP/1.1200OK的响应。
在单播信令情况下，第二屏幕应用的生命周期可以由接收机或第二屏幕服务应用来管理。
首先，将描述在接收机处管理第二屏幕应用的生命周期的方法。
第二屏幕服务应用可能知道仅“URL”(TDO_URL)信息。因此，接收机可以在第二屏幕装置中相对于RemoteUI客户端服务执行“AddUIListing”动作并且在预定时间在第二屏幕装置中执行第二屏幕应用。如果第二屏幕应用被终止，则可以执行“RemoveUIListing”动作以在预定时间内终止第二屏幕应用。
如果除用于详细定时的URL之外还提供了用于执行TDO的媒体时间信息，则可以在预定时间执行第二屏幕服务应用。然而，因为媒体时间是当前正由接收机重放的媒体的相对时间，所以需要将这个时间改变为由各个装置理解的绝对时间。可以使用网络时间协议(NTP)或其它时间信息并且可以通过将具有将来时间信息的媒体时间添加到NTP或其它时间信息来获得当动作被执行时的时间。在第二屏幕装置中，因为动作包括执行和终止，所以可以根据AddUIListing动作和RemoveUIListing动作的实施方式改变这个。
第二，将描述在第二屏幕服务应用处管理第二屏幕应用的生命周期的方法。
第二屏幕服务应用应该知道有关当在第二屏幕装置中执行和终止第二屏幕应用时的事件或时间的信息。因此，如上所述，第二屏幕服务应用包括触发器客户端并且接收机可以根据接收机的DeviceInfo(装置配置文件)发送使用DTVCC接收到的 iTV消息(触发器)信息的URIString。
可以将发送方法主要划分成两个方法：在没有改变的情况下发送使用DTVCC发送并且由接收机处理的触发器消息的第一方法以及在接收机处仅收集第二屏幕装置所必需的信息并且用XML递送仅必要的信息和数据的第二方法。
首先，将描述在接收机处在没有改变的情况下向第二屏幕装置递送触发器的方法。
这个方法可以通过相对于所接收到的触发器执行“AddUIListing”动作而完成。Remote客户端服务可以向触发器客户端递送这个信息并且触发器客户端可以像在接收机中那样下载和处理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.1200OK的响应。
发送事件2信息(s67030)可以包括与发送事件1信息(s67010)类似地发送关于事件的信息。如在TPT XML中一样，可以根据事件向TDO递送数据。在这个步骤中，可以递送关于事件2的信息。
返回HTTP消息(s67040)可以包括发送发送事件2信息(s67030)的结果。类似于发送响应1(s40100)，可以根据情况发送诸如HTTP/1.1200OK的响应。
类似地，发送事件3信息(s67050)可以包括发送关于事件3的信息。
返回HTTP消息(s67060)可以包括发送发送事件3信息(s67050)的结果。类似于发送响应1(s40100)，可以根据情况发送诸如HTTP/1.1200OK的响应。
在以上描述的第二方法中，接收机可以管理第二屏幕应用的生命周期。第二屏幕应用的生命周期可以意指解析并且处理第二屏幕装置的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在接收机与第二屏幕装置之间设定了诸如动作的执行开始时间和结束时间的时间信息，则可以在传输之前通过接收机执行转换操作。
将描述传输延迟和媒体时间估计。
如上所述，因为@startTime和@endTime当正被从接收机发送到第二屏幕装置时基于当前mediaTime值而被相对地创建并且传送，所以在传输时生成的时间损失可以是HTTP报头和HTTP响应的“Date”值。使用到达时间值的差，第二屏幕装置可以找到更准确的时间值。因为当前媒体时间与@mediaTime之间的差是传输延迟时间，所以可以通过以下等式获得当前媒体时间。
当前媒体时间＝传输延迟时间(在接收时的时间值-HTTP报头“Date”值)+ @mediaTime。
因此，能够估计当前接收机的当前媒体时间值。
图69是示出了接收机与第二屏幕装置之间的配置的图。
示出了接收机与第二屏幕装置之间的配置。接收机可以是受控装置(服务器)。第二屏幕装置可以是控制点(客户端)。
在发现步骤中，接收机可以组播服务列表并且加入网络，以及第二屏幕app可以组播对服务列表的请求并且启动。
在描述步骤中，第二屏幕app可以请求接收机的服务描述。
在本发明中，可以定义新的UPnP装置和服务以便经由第二屏幕装置基于UPnP 获取与经由电视机(即，接收机)接收到的A/V广播内容相关联的交互服务。
图70是示出了服务的服务类型和服务ID的实施方式的图。
接收机能够支持触发器服务、双向通信服务和AppURL服务。它还可以支持HTTP 代理服务器服务。在图70中示出了服务类型和服务ID。
双向通信服务能够使得第二屏幕装置能够确定是否存在正由准备参加与第二屏幕装置中的应用的双向通信的主装置执行的DO。
下面将描述触发器服务、AppURL服务和HTTP代理服务器服务。
图71是示出了触发器递送服务的操作构思的图。
触发器递送服务可以意指用于经由第二屏幕装置基于UPnP获取与经由TV接收机接收到的A/V广播内容相关联的交互服务的服务。
图71示出了在接收机处从DTVCC和ACR服务器获取触发器并且在没有改变的情况下或在将触发器改变(扩展)为适合于第二屏幕装置的格式的状态下将触发器发送到第二屏幕装置的过程。
每当触发器被改变时，应该实时地将该触发器或扩展触发器从接收机发送到第二屏幕装置。
图72是示出了生成扩展激活触发器的过程的实施方式的图。
可以通过组合从DTVCC流或ACR服务器获取的触发器何TPT中的信息来生成扩展触发器(扩展激活触发器)。可以通过组合在触发器中包括的TDO ID和事件ID、数据ID和激活时间以及TPT中的TDO URL、TDO属性、事件、动作、扩散和数据来生成扩展触发器。TDO中的信息可以是关于与触发器中的信息相关联的TDO和事件的信息。
这里，扩展触发器可以被称为增广触发器。
图73是示出了针对增广激活触发器的XML模式描述的实施方式的图。
将对触发器服务的规范进行描述。
触发器服务能够递送触发器。能够通过电视机从(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字段相同的编码与触发器相关联的交互模型的数值代码。
@appURL属性的值可以是由触发器中的事件(“e＝”)项所标识的TPT TDO元素的第一URL子元素的值。
每当由触发器中的事件(“e＝”)项所标识的TPT TDO元素包含@cookieSpace属性时@cookieSpace属性可能存在，并且它能够具有与该属性相同的值。
每当由触发器中的事件(“e＝”)项所标识的TPT TDO元素包含Capabilities元素时时Capabilities元素可能存在，并且它可以与该元素相同。
Event元素能够表示由触发器中的事件(“e＝”)项标识的Event元素。(严格地说，触发器中的事件项标识TPT中的TDO元素以及该TDO元素的Event子元素。这在这里被称为由触发器中的事件项所标识的Event元素。)
@action属性的值可以与由触发器中的事件(“e＝”)项标识的Event元素的动作属性的值相同。
每当由触发器中的事件(“e＝”)项所标识的Event元素包含目的地属性时 @destination属性可以存在，并且它能够具有与该属性相同的值。
每当由触发器中的事件(“e＝”)项所标识的Event元素包含扩散属性时@diffusion 属性可以存在，并且它能够具有与该属性相同的值。
每当Event元素的Data子元素由触发器中的(“e＝”)项标识时@data属性可以存在，并且它能够具有与该元素相同的值。
如上所述，可以通过组合从DTVCC流或ACR服务器获取的TPT和触发器中的信息来生成增广触发器。
如上所述，扩展触发器还可以被称作增广触发器。
图74是示出了针对未被增广的触发器的XML模式描述的实施方式的图。
这可以是未被增广的触发器的XML格式。以上描述的特殊“频道改变”触发器还可以遵循这个格式。
针对未被增广的触发器的XML模式描述的一个实施方式可以包括 @interactionModel属性和/或@triggerString属性。
这些字段的语义如下。
对于特殊“频道改变”触发器来说@interactionModel属性不能够存在。对于其它触发器，交互模型可以存在，并且它的值可以是使用与针对DTVCC频道中的SDOPrivateData命令中的cmdID字段相同的编码与触发器相关联的交互模型的数值代码。用于从实况触发器服务获取或从AMT得到的@interactionModel可以被视为 TDO模型。
@triggerString属性的值可以是触发器的字符串表示。触发器的字符串表示用触发器语法加以描述。然而，特殊“频道改变”触发器可以不同。用于特殊“频道改变”触发器的@triggerString属性能够具有值“**<major_num>.<minor_num>”，其中 <major_num>可以是新频道的原始主频道号码(因为它由TV站广播)，并且 <minor_num>可以是新频道的原始最小频道号码(因为它由TV站广播)。如果频道号码不是已知的，则<major_num>值和<minor_num>值皆可以是“0”。
图75是示出了增广激活触发器的格式的实施方式的图。
这可以是以上描述的增广触发器的格式的另一实施方式。
以上描述了@cookieSpace、Capabilities、Event、@action、@destination、@diffusion 和@data。
@activationTime可以是媒体时标上的激活时间。
@tdoURL可以相当于以上描述的@appURL。
图76是示出了增广激活触发器的格式的实施方式的图。
这可以是以上描述的增广触发器的格式的另一实施方式。
以上描述了@activationTime、@tdoURL、@cookieSpace、Capabilities、Event、 @action、@destination、@diffusion和@data。
@availInternet和@availBroadcast可以来自TPT。以上描述了@availInternet和@availBroadcast。
图77是示出了增广激活触发器的格式的实施方式的图。
这可以是以上描述的增广触发器的格式的另一实施方式。
以上描述了@activationTime、@tdoURL、@cookieSpace、Capabilities、Event、 @action、@destination、@diffusion和@data。
ContentItem元素、@updatesAvail属性、@pollPeriod属性、@size属性、 @availInternet属性和@availBroadcast属性在生成增广触发器时可以相当于TPT的元素和属性。以上描述了ContentItem元素、@updatesAvail、@pollPeriod、@size、@availInternet和@availBroadcast。
图78是示出了增广激活触发器的格式的实施方式的图。
这可以是以上描述的增广触发器的格式的另一实施方式。
以上描述了@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。
图79是示出了触发器服务状态变量的实施方式的图。
触发器服务状态变量的一个实施方式可以定义所示出的触发器服务状态变量。触发器服务能够具有图79中列举的状态变量。
LatestUnfilteredTrigger状态变量的值能够在具有最近目标递送时间的未过滤流中表示触发器。这个状态变量的格式可以是符合图74中所描述的模式的XML文档。
LatestFilteredTrigger状态变量的值能够在具有最近目标递送时间的过滤流中表示触发器。当它是激活触发器时，能够通过将激活触发器中的信息与TPT中的信息组合以产生符合由图73中所描述的表表示的XML模式的XML文档来增广它。当它是具有除TDO以外的交互模型的触发器时，它能够具有符合图74中所描述的模式的 XML文档的形式。当它是特殊频道改变触发器时，格式可以是“**<major_num>.<minor_num>”，如之前所描述的。
UnfilteredTriggerDeliveryTime状态变量的值可以是具有最近目标递送时间的未过滤流中的触发器的递送时间。
FilteredTriggerDeliveryTime状态变量的值可以是具有最近目标递送时间的过滤流中的触发器的递送时间。
图80是示出了触发器服务状态变量的实施方式的图。
触发器服务状态变量的另一实施方式可以具有与图80相同的状态变量。
CurrentTrigger状态变量的值能够取决于以下三个情形中的哪一个生效。1)不存在与当前正在主屏幕上观看的广播节目相关联的交互附属数据服务。2)存在与当前正在主屏幕上观看的广播节目相关联的交互附属数据服务，并且它具有直接执行交互模型。3)存在与当前正在主屏幕上观看的广播节目相关联的交互附属数据服务，并且它具有TDO交互模型。
在情况(1)下，CurrentTrigger状态变量的值可以是空字符串。
在情况(2)下，CurrentTrigger状态变量的值可以是已由电视机接收到以用于当前正在主屏幕上观看的广播节目的最近的触发器。
在情况(3)下，CurrentTrigger状态变量的值可以是已由电视机接收到以用于当前正在主屏幕上观看的激活触发器当中的最近激活的激活触发器的增广形式。(即，激活触发器在其激活时间到达时能够成为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和触发器这二者中提取到这个元数据。这个变量可以具有与图78的实施方式相同的 XML模式。
当接收机基于UPnP的事件机制改变状态变量时可以实时地获取以上定义的ATSCTrigger和ATSCExpandedTrigger的已改变值。
图81是示出了触发器服务动作的实施方式的图。
动作可以被定义为使得第二屏幕装置或接收机任意地读取触发器服务状态变量的值。
触发器服务动作的一个实施方式可以定义GetLatestUnfilteredTrigger动作和GetLatestFilteredTrigger动作。
图82是示出了GetLatestUnfilteredTrigger动作的变元的实施方式的图。
LatestUnfilteredTrigger输出变元的值可以是LatestUnfilteredTrigger状态变量的值。
第二屏幕应用可以使用GetLatestUnfilteredTrigger动作来获得LatestUnfilteredTrigger状态变量(即，具有最近目标递送时间的未过滤流中的触发器)的值。
图83是示出了GetLatestFilteredTrigger动作的变元的实施方式的图。
LatestFilteredTrigger输出变元的值可以是LatestFilteredTrigger状态变量的值。
第二屏幕应用可以使用GetLatestFilteredTrigger动作来获得LatestFilteredTrigger 状态变量(即，具有最近目标递送时间的过滤流中的触发器)的值。
图84是示出了触发器服务动作的实施方式的图。
在以上描述的触发器服务状态变量的另一实施方式中，其中ATSCTrigger和ATSCExpandedTrigger被定义为状态变量，将对触发器服务动作进行描述。
即使在这个实施方式中，动作可以被定义为使得第二屏幕装置或接收机任意地写入或读取ATSCTrigger和ATSCExpandedTrigger的值。
SetTrigger()动作可以使得能够使用ATSCTrigger的值。CurrentTrigger可以是变元。
SetExpandedTrigger()动作可以使得能够使用ATSCExpandedTrigger的值。可以增广CurrentTrigger。
GetTrigger()动作可以使得能够读取ATSCTrigger的值。CurrentTrigger可以是变元。
GetExpandedTrigger()动作可以使得能够使用ATSCExpandedTrigger的值。CurrentTrigger可以是变元。
图85是示出了当经由目标递送服务获取触发器时第二屏幕上的操作的实施方式的图。
可以示出第二屏幕装置如何根据经由触发器递送服务从第二屏幕装置接收到的触发器或扩展激活触发器中包括的动作信息操作。
可以经由触发器递送服务获取执行/终止动作的触发器。
第二屏幕装置可以经由触发器递送服务获取执行/终止动作的触发器并且将目标TDO的URL和关联的信息递送给DAE/浏览器。浏览器可以执行在触发器中包括的动作，诸如执行或终止。
图86是示出了触发器递送服务的操作构思的图。
可以示出第二屏幕装置如何根据在经由触发器递送服务从第二屏幕装置接收到的触发器或扩展激活触发器中包括的动作信息操作。
第二屏幕装置可以经由触发器递送服务获取触发器事件动作的触发器并且然后从所获取的触发器中提取诸如数据ID的信息。其后，可以使用AJAX将数据递送给当前执行的TDO。TDO可以根据所接收到的数据执行适当的操作。
在以上描述的触发器服务状态变量的另一实施方式中，其中ATSCTrigger和ATSCExpandedTrigger被定义为状态变量，将描述触发器递送服务的操作构思。
在这个实施方式中，在直接执行模型情况下，如果内容id(即，“c＝”)被包括在经由DTVCC流或ACR服务器接收到的触发器中，则接收机可以将所接收到的时基触发器值设定为ATSCTrigger状态变量的值。当时基触发器到达接收机时，状态变量的值可以被立即改变或者可以经由SetTrigger动作被递送给第二屏幕装置。
在本实施方式中，在TDO模型情况下，如果内容id(即，“c＝”)未被包括在经由DTVCC流或ACR服务器接收到的触发器中，则接收机接收激活触发器并且然后提取并且组合来自TPT的关联信息和触发器信息以生成扩展触发器。其后，在扩展触发器的激活时间处(或之前)，可以经由SetExpandedTrigger动作设定或向第二屏幕装置递送ATSCExpandedTrigger状态变量的值。
图87是示出了AppURL服务状态变量的图。
AppURL服务能够使得第二屏幕装置能够确定与当前执行的DO相关联的第二屏幕应用的基础URL和名称。
UPnP AppURL服务能够具有两个状态变量AppURL和AppName。
AppURL状态变量的值可以是与当前执行的DO相关联的第二屏幕应用的基础 URL。当不存在具有在第一屏幕装置上执行的关联的第二屏幕应用的DO时，AppURL 状态变量的值可以是空字符串。
AppName状态变量的值可以是与当前执行的DO相关联的第二屏幕应用的名称。当不存在具有在第一屏幕装置上执行的关联的第二屏幕应用的DO时，AppName状态变量的值可以是空字符串。
图88是示出了AppURL服务动作的图。
AppURL服务能够具有一个动作GetAppURL。
图89是示出了GetAppURL动作的变元的图。
GetAppURL动作能够具有两个变元AppURL和AppName。
AppURL输出变元可以是AppURL状态变量的当前值。并且AppName输出变元可以是AppName状态变量的当前值。
因此，能够经由GetAppURL动作获得AppURL状态变量的当前值和AppName 状态变量的当前值。
图90是示出了代理HTTP服务器服务的操作构思的图。
接收机能够支持代理HTTP服务器服务。代理HTTP服务器服务可以意指用于如果第二屏幕装置经由广播网络发送TDO/文件则经由TV接收机获取TDO/文件的服务。
示出代理HTTP服务器服务的操作构思的图可以包括广播系统90010、ACR服务器90020、广播装置ATSC 2.0iTV服务器90030、ATSC 2.0服务器90040和/或第二屏幕装置90050。
广播系统90010可以相当于于广播系统42010。
ACR服务器90020可以相当于ACR服务器42020。
广播装置ATSC 2.0iTV服务器90030可以相当于广播装置ATSC 2.0iTV服务器42030。
ATSC 2.0接收机90040可以接收与广播A/V和交互服务相关联的触发器，使用触发器获取交互服务，并且在屏幕上提供交互服务。这可以相当于以上描述的接收机。代理HTTP服务器服务可以使得ATSC 2.0服务器90040能够执行与代理服务器的功能相似的功能，以便高效地将由第二屏幕装置所请求的文件提供给第二屏幕装置。
第二屏幕装置90050可以相当于第二屏幕装置42050。
代理HTTP服务器服务可以使得接收机能够经由第二屏幕装置通过互联网来访问广播流或文件并且使得第二屏幕装置能够访问经由广播流发送的内容。如果多个第二屏幕装置通过互联网访问同一文件，则能够使这些第二屏幕装置对同一文件的访问最小化。
图91是示出了代理服务器服务状态变量的实施方式的图。
UPnP代理服务器服务能够提供HTTP代理服务器，以使得第二屏幕装置能够访问经由FLUTE会话在广播中递送给TV接收机的文件，并且以在当家庭中的多个第二屏幕装置正在同时检索相同的文件时的情况下使通过第二屏幕装置从互联网服务器中检索文件变得更高效。
可以定义状态变量和动作以便实现这个。
UPnP HTTP代理服务器服务能够具有单个状态变量ProxyServerURL。
ProxyServerURL状态变量的值可以是HTTP代理服务器的URL-即，HTTP请求将被导向以便通过代理服务器路由请求的URL。
图92是示出了代理服务器服务动作的实施方式的图。
UPnP代理服务器服务能够具有单个动作GetProxyURL。
图93是示出了GetProxyURL动作的变元的实施方式的图。
GetProxyURL动作能够具有单个变元ProxyURL。
ProxyURL输出变元可以是ProxyServerURL状态变量的当前值。
因此，能够经由GetProxyURL动作获得ProxyServerURL状态变量的当前值。
图94是示出了RequestFiles()的实施方式的图。
在UPnP HTTP代理服务器服务状态变量的另一实施方式中，可以定义被称作ATSCProxySeverURL的UPnP HTTP代理服务器服务状态变量。另外，在这个实施方式中，可以定义被称作GetProxyServerURL()的动作。
ATSCProxySeverURL状态变量能够包含对接收机中的代理服务器的形式为URI 的引用。代理服务器从第二屏幕装置得到对文件的HTTP请求并且从广播流中的 FLUTE会话或互联网中检索文件。然后，代理服务器向第二屏幕装置发送所检索到的文件作为HTTP响应。
GetProxyServerURL()可以是使得能够读取ProxySeverURL的值的动作。ProxySeverURL可以作为变元被包括。
在UPnP HTTP代理服务器服务状态变量的另一实施方式中，可以定义被称作ATSCFileList的UPnP HTTP代理服务器服务状态变量。另外，在这个实施方式中，可以定义被称作RequestFiles()的动作。
可以仅通过能够接收广播内容的接收机来获取在广播流中包括的文件。因此，为了使得不能够接收广播内容的第二屏幕装置能够访问在广播内容中包括的文件，可以定义必要的UPnP状态变量和动作。也就是说，作为要经由FLUTE会话下载的文件列表的ATSCFileList被设定为UPnP状态变量或者可以使得第二屏幕装置能够经由从接收机请求文件的RequestFiles()动作获取特定文件或多个文件。
ATSCFileList状态变量能够包含到接收机中的代理服务器的请求文件的CSV列表。
RequestFiles()可以是请求通过互联网下载在广播流中包括的特定文件的动作。具体地，在广播流流中包括的文件情况下，可以经由FLUTE会话下载所请求的文件。
图95是示出了第二屏幕装置架构的实施方式的图。
将对操作的理论进行描述。
可以存在操作的两个模式：其中触发应用(TDO)在TV接收机上执行的一个模式，并且非触发应用(打包App)在TV接收机上执行的另一模式。
在触发应用在TV接收机上执行的情况下，当当前正在TV接收机上观看的广播节目具有带第二屏幕支持的关联的交互数据服务时，第二屏幕装置的用户能够在装置上激活适当的应用。这个应用可能经历UPnP发现和描述过程以在TV接收机上发现触发器服务、双向通信服务和代理服务器服务。
第二屏幕应用然后能够订阅用于触发器服务得到准备递送的触发器的通知的UPnP“事件”，并且它能够使用GetLatestUnfilteredTrigger动作或GetLatestFilteredTrigger动作来得到它被设计为使用的触发器。这个的结果是第二屏幕应用能够在适当的时间获得适当的触发器。应用然后能够以它被设计为使用的无论什么方式对这些触发器起作用。
第二屏幕应用还能够订阅UPnP“事件”以用于双向通信服务得到用来请求用于双向通信的连接的TCP/IP地址和端口的通知，以及何时存在在准备通信的主装置中执行的DO的通知。应用然后能够参加与支持这样的通信的任何DO的双向通信。
由触发器和/或双向通信引起的动作常常可能需要第二屏幕应用来下载文件。这些文件可能可从互联网上的HTTP服务器得到，或者它们可能可从TV广播的会话得到(或这二者)。
如果所有所期望的文件可经由互联网得到，并且如果第二屏幕装置具有到网络的良好连接性，则应用能够直接简单地检索文件。
如果所期望的文件中的一些或全部可仅经由TV广播得到，并且如果接收机提供HTTP代理服务器服务，则应用能够利用GetProxyURL动作得到代理服务器URL并且经由该代理服务器检索到所期望的文件。应用还能够选择在它可能更便于那样而不是直接检索文件的其它情形下使用代理服务器。
在非触发应用在TV接收机上执行的情况下，不管当前正被观看的广播节目，用户能够在TV接收机上激活DO，这还通过AppURL服务提供要在第二屏幕装置上启动的伴随应用的名称和位置。
第二屏幕装置上的控制点能够订阅与AppURL服务相关联的UPnP“事件”以得到对AppURL变量和AppName变量的改变的通知。控制点然后将向第二屏幕装置的用户指示可用服务悬而未决。随后，用户将查看AppName并且选择服务，导致伴随第二屏幕应用在第二屏幕装置上被启动。
即使当DO是其生命周期由消费者而不是由广播装置控制的预先下载到接收机的广播装置提供的打包App，第二屏幕应用也可以与在ATSC 2.0接收机上执行的DO 相关联。在缺乏用来标识伴随第二屏幕应用的触发器时，接收机提供使得第二屏幕装置上的控制点能够使用GetAppURL动作来访问发布的第二屏幕应用URL并且在第二屏幕装置上启动它的AppURL服务。
第二屏幕装置架构的一个实施方式示出了与接收机互相配合的第二屏幕应用和第二屏幕装置。
第二屏幕装置架构的一个实施方式可以包括远程内容服务器95010、TV接收机95020和/或第二屏幕装置95030。
远程内容服务器95010可以提供内容。可以将内容提供给接收机95020或第二屏幕装置95030。
TV接收机95020可以提供UPnP触发器服务和UPnP代理服务器服务。该接收机可以相当于以上描述的接收机。
第二屏幕装置95030可以具有第二屏幕应用(ATSC 2.0App)并且该第二屏幕应用可以具有触发器处理机中的UPnP控制点(CP)模块。UPnP控制点(CP)模块处理第二屏幕应用(ATSC 2.0App)与TV接收机(95020)上的触发器服务和代理服务器服务之间的所有UPnP通信。它能够管理发现过程，获得代理服务器URL，并且订阅触发器服务事件。
能够将从UPnP触发器服务到达的触发器递交给触发器处理机。如果触发器指示新的声明对象(DO)将在DAE(声明应用环境-即，浏览器)中被下载和执行，则触发器处理机能够看管那个。如果触发器指示已经在浏览器中执行的DO应该采取某个动作，则处理器处理机能够将触发器传递到DO中。第二屏幕装置的用户能够与 DO交互。触发器处理机对用户而言可能是不可见的。
第二屏幕App能够按需执行以下功能。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触发器，并且如果触发器的Action属性是“TriggerEvent”，则将触发器传递到标识为触发器的目标的TDO。如果TDO未已经在DAE中运行，则丢弃触发器。 9)经由直接互联网连接或经由TV接收机上的代理服务器服务按需下载文件(包括 TDO)。
直接执行触发器和TDO触发器在被接收到时能够立即起作用，除非它们包含“spread”属性或“diffusion”属性。当触发器包含“spread”属性或“diffusion”属性时，能够使动作延迟达随机间隔。
图96是示出了接收机的简化结构的实施方式的图。
示出接收机的简化结构的图可以包括天线(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)光远程地递送信息。
图97是示出了第二屏幕装置的结构的实施方式的图。
第二屏幕装置的结构的一个实施方式可以包括IO子系统97010、文件系统97020、网络协议子系统97030以及基本模块97040。
IO子系统97010可以与可以被安装在第二屏幕装置中的所有装置连接以得到外部连接。IO子系统97010可以与小键盘、显示器、麦克风、扬声器、立体声插孔、运动传感器、光传感器、GPS和相机连接。各个I/O装置可以由键模块、显示控制模块、音频控制模块、传感器控制模块和/或相机控制模块控制。如果功能由形式为SDK 的IO子系统97010调用，则各个I/O装置由装置驱动器控制并且各个传感器或相机可以访问任何程序。在一些情况下，功能可能被限制使得访问仅在本机应用中是可能的。
文件系统97020可以为外部SD卡读取和写入文件并且可以连接至USB以执行数据通信。可以连接诸如SD卡、闪速存储器或USB的装置。这可以通过SD接口、闪速存储器控制或USB BUS控制来控制。
网络协议子系统97030可以经由3GPP、Wi-Fi和/或蓝牙执行通信。
基本模块97040可以被包括第二装置中。电池管理器可以管理第二屏幕装置的电池量，并且当通信提供方或制造商将通知提供给第二屏幕装置时可以使用通知模块。另外，存储模块可以用来购买针对使用由第二屏幕装置提供的开放SDK制造的第二屏幕的应用。应用管理器可以管理使用存储模块安装的应用并且就应用升级进行通知。另外，web模块可以被包括使得第二屏幕装置执行互联网访问。可以根据个人偏好设定第二屏幕的各种功能并且可以使用用户偏好程序。
基本模块97040具有各种功能并且可以是安装在第二屏幕装置中的程序。然而，由虚线表示的模块可以是由用户选择性地安装的软件模块。
例如，UPnP框架模块可能不被第二屏幕装置支持或者可以被安装在第二屏幕装置中。如果安装了UPnP框架模块，则本机应用也被安装以容易地执行UPnP操作。然而，在接收机的结构中，UPnP框架可以使得用户能够安装第二屏幕服务应用或支持UPnP框架的应用。能够找到能够经由UPnP框架模块接收地面波的接收机。
图98是示出了第二屏幕服务场景的图。
将描述第二屏幕服务场景的一个实施方式。
第二屏幕服务场景的一个实施方式可以包括接收触发器(s98010)、请求TPT(s98020)、发送TPT作为响应(s98030)、请求TDO(s98040)、发送TDO作为响应(s98050)、执行TDO(s98060)、发送scanDeviceList消息(s98070)、调用发现函数(s98080)、执行UPnP应用(s98090)、组播搜索消息(s98100)、通知UPnP框架(s98110)、返回装置列表(s98120)、返回装置句柄(s98130)、发送scanServiceList 消息(s98140)、调用服务列表函数(s98150)、发送GetServiceDescription消息(s98160)、发送HTTP消息(s98170)、返回服务列表(s98180)、返回服务句柄的列表(s98190)、发送hnHandle消息(s98200)、调用服务列表函数(s98210)、发送GetDeviceProfile 消息(s98220)、发送HTTP消息(s98230)、返回soap响应(s98240)、返回soap响应XML(s98250)、解析对soap响应(s98260)、发送hnHandle消息(s98270)、调用服务列表函数(s98280)、发送InputUIListing消息(s98290)、发送HTTP消息(s98300)、返回soap响应(s98310)、返回存活时间(s98320)、发送hnHandle消息 (s98330)、调用服务列表函数(s98340)、发送DisplayMessage(s98350)；发送HTTP 消息(s98360)、返回空(s98370)、返回空(s98380)和/或执行第二屏幕应用(s98390)。
接收触发器(s98010)可以包括经由广播流使用DTVCC iTV消息从广播装置接收触发器。
请求TPT(s98020)可以包括解析并且解释所接收到的触发器以及请求与广播装置互联网服务器有关的TPT。
发送TPT作为响应(s98030)可以包括发送TPT作为响应。
请求TDO(s98040)可以包括如果需要下载相关TDO则从广播装置互联网服务器请求TDO。
发送TDO作为响应(s98050)可以包括发送所请求的TDO。
执行TDO(s98060)可以包括触发器模块执行TDO。
发送scanDeviceList消息(s98070)可以包括经执行的DO(或TDO)发送用于请求装置列表扫描的消息。
调用发现函数(s98080)可以包括调用用于装置发现的UPnP框架的发现函数。
执行UPnP应用(s98090)可以包括第二屏幕装置执行用于第二屏幕服务启动器的UPnP应用。这个步骤独立于主装置并且可以在执行UPnP应用之前被执行 (s98090)。
组播搜索消息(s98100)可以包括UPnP框架组播搜索消息以便在家庭网络中搜索第二屏幕装置。
通知UPnP框架(s98110)可以包括接收到搜索消息的第二屏幕装置向主装置发送通知消息。因此，能够就第二屏幕装置的存在进行通知。
返回装置列表(s98120)可以包括UPnP框架在装置发现之后返回装置列表。
返回装置句柄(s98130)可以包括将所接收到的装置列表递送给DO。
发送scanServiceList消息(s98140)可以包括经执行的DO(或TDO)发送用于请求服务列表扫描的消息。
调用服务列表函数(s98150)可以包括调用用于服务发现的UPnP框架的服务列表函数。
发送GetServiceDescription消息(s98160)可以包括从第二屏幕装置请求第二屏幕装置的服务描述。
发送HTTP消息(s98170)可以包括发送发送GetServiceDescription消息的结果(s98160)。如上所述，可以发送诸如HTTP/1.1200OK(成功)的消息。可以在XML 中接收到服务描述。
返回服务列表(s98180)可以包括在UPnP框架接收到服务描述之后返回服务列表。
返回服务句柄的列表(s98190)可以包括返回所接收到的服务列表。
发送hnHandle消息(s98200)可以包括发送消息以便获得装置配置文件。
调用服务列表函数(s98210)可以包括调用用于服务发现的UPnP框架的服务列表函数。
发送GetDeviceProfile消息(s98220)可以包括从第二屏幕装置请求第二屏幕装置的服务描述。发送HTTP消息(s98230)可以包括在发送GetDeviceProfile消息时发送请求结果(s98220)。如上所述，可以发送诸如HTTP/1.1200OK(成功)的消息。可以接收装置配置文件。
返回soap响应(s98240)可以包括返回所接收到的装置配置文件。
返回soap响应XML(s98250)可以包括返回所接收到的XML的装置配置文件。
解析soap响应(s98260)可以包括DO解析所接收到的SOAP消息。
发送hnHandle消息(s98270)可以包括发送消息以便向第二屏幕装置通知第二屏幕服务的URL地址。
调用服务列表函数(s98280)可以包括调用UPnP框架的服务列表函数。
发送InputUIListing消息(s98290)可以包括向第二屏幕装置通知第二屏幕服务的URL地址。可以使用以上描述的AddUIListing动作。第二屏幕装置可以将所需要的URL添加到UIListing。
发送HTTP消息(s98300)可以包括在发送InputUIListing消息时发送请求结果(s98290)。如上所述，可以发送诸如HTTP/1.1200OK(成功)的消息。
返回soap响应(s98310)可以包括返回指示URL已被发送了的消息。
返回存活时间(s98320)可以包括在发送InputUIListing消息时发送请求结果(s98290)，与发送HTTP消息(s98300)相似。
发送hnHandle消息(s98330)可以包括发送消息以便向第二屏幕装置递送显示消息。
调用服务列表函数(s98340)可以包括调用UPnP框架的服务列表函数。
发送DisplayMessage(s98350)可以包括向第二屏幕装置发送显示消息。显示消息可以包括诸如消息类型的信息。可以使用以上描述的DispalyMessage动作。第二屏幕装置可以根据显示消息将消息显示在第二屏幕上。
发送HTTP消息(s98360)可以包括发送发送DisplayMessage的结果(s98350)。如上所述，可以发送诸如HTTP/1.1200OK(成功)的消息。
返回空(s98370)可以包括如果接收到HTTP/1.1200OK则返回空。
返回空(s98380)可以包括如果作为响应接收到空则将空返回给DO。
执行第二屏幕应用(s98390)可以包括第二屏幕装置执行第二屏幕应用。
图99是示出了在第一装置处处理交互服务的方法的图。
在第一装置处处理交互服务的方法的一个实施方式可以包括发送发现消息(s99010)、接收对描述的请求(s99020)、发送具有描述的响应(s99030)、提供HTTP 代理服务器(s99040)、从广播流接收文件(s99050)以及将文件递送给第二装置 (s99060)。
发送发现消息(s99010)可以将发现消息发送到在第二装置中运行的第二屏幕应用。发现消息可以用来指示由第一装置提供的第二屏幕支持服务。这里，第一装置可以是以上描述的主装置或TV接收机。这里，发现消息可能未被发送到单个第二屏幕装置而是可以被组播到多个第二屏幕装置。这里，第二屏幕支持服务可以是以上描述的第二屏幕服务。发送发现消息(s99010)可以被包括在以上描述的装置发现步骤中。
接收对描述的请求(s99020)可以包括接收对由第一装置提供的第二屏幕支持服务的描述的请求。第二装置可以是以上描述的第二屏幕装置。正在第二屏幕装置中执行的第二屏幕应用可以从第一装置请求由第一装置提供的第二屏幕支持服务的描述。接收对描述的请求(s99020)可以包括第一装置接收请求。这个可以被包括在以上描述的装置发现步骤中。
发送具有描述的响应(s99030)可以包括第一装置在接收到对描述的请求时响应于请求将描述发送到第二屏幕应用(s99020)。这个响应可以包括除描述之外的其它信息。这个可以被包括在以上描述的装置发现步骤中。
提供HTTP代理服务器(s99040)可以包括第一装置生成HTTP代理服务器并且将HTTP代理服务器提供给第二装置。HTTP代理服务器可以通过由第二装置访问的 HTTP代理服务器服务来提供。这里，HTTP代理服务器服务可以是第二屏幕支持服务中的一个。
从广播流接收文件(s99050)可以包括第一装置从广播流接收诸如TDO或应用的数据。这样的数据可以被用于第二装置。
将文件递送给第二装置(s99060)可以包括第一装置经由在提供HTTP代理服务器(s99040)的步骤中提供的代理服务器递送在从广播流接收文件(s99050)的步骤中接收到的文件。如上所述，第二装置能够经由广播流接收数据。
在本发明的一个实施方式中，可以在发送发现消息之前执行接收搜索消息的步骤。搜索消息可以用来检测用于提供第二屏幕支持服务的装置。可以使用单播方法或组播方法来发送搜索消息。通过这个步骤，第二屏幕装置可以检测第一装置。
在本发明的另一实施方式中，可以在第一装置将文件递送给第二装置之前首先提供HTTP代理服务器的URL。第二装置可以使用第一装置的HTTP代理服务器服务的GetProxyURL动作。以上描述了HTTP代理服务器服务和GetProxyURL动作。
在本发明的另一实施方式中，可以从广播流或互联网服务器接收触发器并且可以使用触发器服务将所接收到的触发器递送给第二装置。这里，触发器服务可以是第二屏幕支持服务中的一个。以上描述了触发器。经递送的触发器可以应用于第二装置中的应用以用作以上描述的时基触发器或激活触发器。因此，能够在特定时间执行应用的事件。
在本发明的另一实施方式中，应用可以是声明对象、触发声明对象、非实时声明对象或未绑定声明对象。
在本发明的另一实施方式中，首先，可以通知第二装置伴随应用的URL和名称已被改变。这里，伴随应用可以意指与在第一装置中正被执行的应用有关的应用。伴随应用可以是第二屏幕应用中的一个。其后，可以将伴随应用的URL和名称递送给第二装置，并且可以使用HTTP代理服务器将伴随应用递送给第二装置。这时，可以使用HTTP代理服务器服务来生成HTTP代理服务器。在这个实施方式中，第二装置可以使用第一装置的AppURL服务的GetAppURL动作。以上描述了AppURL服务和 GetAppURL动作。AppURL服务可以是第二屏幕支持服务中的一个。
图100是示出了在第二装置中运行的第二屏幕应用处处理交互服务的方法的图。
在第二装置中运行的第二屏幕应用处处理交互服务的方法的一个实施方式可以包括接收发现消息(s10010)、发送对描述的请求(s10020)、接收带描述的响应 (s10030)、访问HTTP代理服务器服务(s10040)和/或从第一装置接收文件(s10050)。
接收发现消息(s10010)可以包括从第一装置接收发现消息。如上所述，第一装置可以是主装置或TV接收机。第二装置可以是上面描述的第二屏幕装置。发现消息可以用来指示由第一装置提供的第二屏幕支持服务。第一装置可以将发现消息发送到仅第二装置或者可以将发现消息组播到家庭网络中的所有装置。这个步骤可以被包括在以上描述的装置发现步骤中。这个步骤可以是第二装置从第一装置接收发现消息。可以从第二屏幕应用的观点描述发送发现消息(s99010)。
发送对描述的请求(s10020)可以包括从第一装置请求由第一装置提供的第二屏幕支持服务的描述。可以从第二屏幕应用的观点描述接收对描述的请求(s99020)。这个步骤可以被包括在以上描述的装置发现中。
接收带描述的响应(s10030)可以包括响应接收服务的描述作为对在发送对描述的请求(s10020)的步骤中发送的请求的响应。第一装置可以将其服务的描述发送到第二屏幕应用。可以从第二屏幕应用的观点描述发送具有描述的响应(s99030)。这个步骤可以被包括在以上描述的装置发现步骤中。
访问HTTP代理服务器服务(s10040)可以包括访问作为第二屏幕支持服务之一的HTTP代理服务器服务。第一装置可以从广播流接收文件。可以基于在接收带描述的响应(s10030)的步骤中接收到的描述来执行访问HTTP代理服务器服务。在接收带描述的响应(s10030)的步骤中接收到的描述当中，可以使用HTTP代理服务器服务的描述。
从第一装置接收文件(s10050)可以是第一装置经由由第一装置提供的HTTP代理服务器接收文件。如上所述，第二装置能够经由广播流接收数据。
在本发明的一个实施方式中，可以进一步包括组播搜索消息的步骤。可以在接收发现消息之前执行这个步骤。搜索消息可以用来检测用于提供第二屏幕支持服务的装置。根据该实施方式，可以单播搜索消息。通过这个步骤，第二装置可以检测第一装置。
在本发明的另一实施方式中，可以在第二屏幕应用接收文件之前从第一装置接收HTTP代理服务器的URL。第二屏幕应用可以使用第一装置的HTTP代理服务器服务的GetProxyURL动作。以上描述了HTTP代理服务器服务和GetProxyURL动作。
在本发明的另一实施方式中，可以使用所接收到的描述来访问触发器服务并且可以从第一装置接收触发器。这里，触发器服务可以是第二屏幕支持服务中的一个。以上描述了触发器。所接收到的触发器可以应用于第二装置中的应用以用作以上描述的时基触发器或激活触发器。因此，能够在特定时间执行应用的事件。
在本发明的另一实施方式中，应用可以是声明对象、触发声明对象、非实时声明对象或未绑定声明对象。
在本发明的另一实施方式中，首先，可以接收关于伴随应用的URL和名称的改变的通知。这里，伴随应用可以意指与在第一装置中正被执行的应用有关的应用。伴随应用可以是第二屏幕应用中的一个。其后，可以接收伴随应用的URL和名称并且可以使用HTTP代理服务器来接收伴随应用。这时，可以使用HTTP代理服务器服务来生成HTTP代理服务器。在这个实施方式中，第二装置可以使用第一装置的AppURL 服务的GetAppURL动作。以上描述了AppURL服务和GetAppURL动作。AppURL 服务可以是第二屏幕支持服务中的一个。
图101是示出了用于作为第一装置处理交互服务的设备的图。
用于作为第一装置处理交互服务的设备的一个实施方式可以包括第一模块101010、第二模块101020和第三模块101030。
这里，第一装置可以是以上描述的主装置或TV接收机。
第一模块101010可以发送发现消息、接收对服务描述的请求并且发送对请求的响应。第一模块101010可以是以上描述的UPnP框架模块。
第一模块101010能够被配置为将发现消息发送到在第二装置中运行的第二屏幕应用。发现消息可以用来指示由第一装置提供的第二屏幕支持服务。这里，发现消息可能未被发送到单个第二屏幕装置而是可以被组播到多个第二屏幕装置。这里，第二屏幕支持服务可以是以上描述的第二屏幕服务。可以执行这个操作以用于装置发现。
第一模块101010能够被配置为从第二屏幕应用接收对第二屏幕支持服务的描述的请求。可以接收到对由第一装置提供的第二屏幕支持服务的描述的请求。由第二屏幕装置执行的第二屏幕应用可以从第一装置请求由第一装置提供的第二屏幕支持服务的描述。可以接收这个请求。可以执行这个操作以用于装置发现。
第一模块101010能够被配置为向第二屏幕应用发送具有描述的响应。作为对所接收到的请求的响应，可以将描述发送到第二屏幕应用。这个响应可以包括除描述之外的其它信息。可以执行这个操作以用于装置发现。
第二模块101020可以用来从广播流接收文件。如果接收到广播流，则可以经由如以上所描述的DTVCC接收到这个。第二模块101020可以是以上描述的调谐器。文件可以包括应用、TDO等。这样的数据可以被用于第二装置。
第三模块101030能够被配置为使用HTTP代理服务器服务来提供HTTP代理服务器。HTTP代理服务器服务能够允许第二装置访问由第二模块在广播流中接收到的文件。HTTP代理服务器服务可以是第二屏幕支持服务中的一个。第一装置可以生成 HTTP代理服务器并且将HTTP代理服务器提供给第二装置。可以通过由第二装置访问的HTTP代理服务器服务来提供HTTP代理服务器。
第三模块101030能够被配置为经由HTTP代理服务器将文件递送给第二装置。第三模块101030可以经由代理服务器将从广播流接收到的文件递送给第二模块 101020。如上所述，通过这个方法，第二装置能够经由广播流接收数据。
在本发明的一个实施方式中，第一模块101010可以在递送发现消息之前接收搜索消息。搜索消息可以用来检测用于提供第二屏幕支持服务的装置。可以使用单播方法或组播方法来发送搜索消息。因此，第二屏幕装置可以检测第一装置。
在本发明的另一实施方式中，在第三模块101030将文件递送给第二装置之前，可以首先提供HTTP代理服务器的URL。第二装置可以使用第一装置的HTTP代理服务器服务的GetProxyURL动作。以上描述了HTTP代理服务器服务和GetProxyURL 动作。
在本发明的另一实施方式中，所述设备还可以包括第四模块101040。第四模块101040可以从广播流或互联网服务器接收触发器。第一模块101010可以使用触发器服务将由第四模块101040接收到的触发器递送给第二装置。这里，触发器服务可以是第二屏幕支持服务中的一个。以上描述了触发器。经递送的触发器可以应用于第二装置中的应用以用作以上描述的时基触发器或激活触发器。因此，能够在特定时间执行应用的事件。这里，以上描述的第二模块101020可以根据设计者的意图被包括在第四模块101040中。也就是说，如果假如经由广播流接收到文件则第四模块101040 可以是以上描述的调谐器，以及假如经由互联网接收到文件则可以是以上描述的网络接口。因此，第四模块101040可以被设计为执行第二模块101020的功能以经由广播流接收文件。
在本发明的另一实施方式中，应用可以是声明对象、触发声明对象、非实时声明对象或未绑定声明对象。
在本发明的另一实施方式中，首先，第三模块101030可以通知第二装置伴随应用的URL和名称已被改变。这里，伴随应用可以意指与在第一装置中正被执行的应用有关的应用。伴随应用可以是第二屏幕应用中的一个。其后，可以将伴随应用的 URL和名称递送给第二装置，并且可以使用HTTP代理服务器将伴随应用递送给第二装置。这时，可以使用HTTP代理服务器服务来生成HTTP代理服务器。在这个实施方式中，第二装置可以使用第一装置的AppURL服务的GetAppURL动作。以上描述了AppURL服务和GetAppURL动作。AppURL服务可以是第二屏幕支持服务中的一个。
图102是示出了用于作为在第二装置中运行的第二屏幕应用处理交互服务的设备的图。
用于作为在第二装置中运行的第二屏幕应用处理交互服务的设备的一个实施方式可以包括第一模块102010和/或第二模块102020。
这里，第二装置可以是以上描述的第二屏幕装置。
第一模块102010可以接收发现消息、请求服务描述并且接收对请求的响应。这里，第一模块102010可以是第二屏幕装置中的UPnP框架模块。
第一模块102010能够被配置为从第一装置接收发现消息。发现消息可以用来指示由第一装置提供的第二屏幕支持服务。第一装置可以将发现消息发送到仅第二装置，或者可以将发现消息组播到家庭网络中的所有装置。可以执行这个操作以用于装置发现。
第一模块102010能够被配置为向第一装置发送对第二屏幕支持服务的描述的请求。第一模块102010可以从第一装置请求由第一装置提供的第二屏幕支持服务的描述。可以执行这个操作以用于装置发现。
第一模块102010能够被配置为从第一装置接收带描述的响应。第一模块102010可以接收服务的描述作为对所发送的请求的响应。第一装置可以将其服务的描述发送到第二屏幕应用。可以接收到描述。可以执行这个操作以用于装置发现。
第二模块102020可以访问HTTP代理服务器服务并且经由HTTP代理服务器接收文件。第二模块102020可以是以上描述的网络协议子系统。
第二模块102020能够被配置为使用描述中给出的信息来访问HTTP代理服务器服务。HTTP代理服务器服务能够用来提供HTTP代理服务器以使得第二装置能够访问由第一装置在广播流中接收到的文件。HTTP代理服务器服务可以是第二屏幕支持服务中的一个。第一装置可以从广播流接收文件。可以基于由第一模块102010接收到的描述来执行对HTTP代理服务器服务的访问。在所接收到的描述当中，可以使用 HTTP代理服务器服务的描述。
第二模块102020能够被配置为经由HTTP代理服务器从第一装置接收文件。第二模块102020可以经由由第一装置提供的HTTP代理服务器来接收由第一装置接收到的文件。如上所述，通过这个操作，第二装置可以经由广播流接收数据。
在本发明的一个实施方式中，第一模块102010可以组播搜索消息。可以在接收发现消息之前执行这个。搜索消息可以用来检测用于提供第二屏幕支持服务的装置。根据该实施方式，可以单播搜索消息。通过这个操作，第二装置可以检测第一装置。
在本发明的另一实施方式中，第二模块102020可以在第二屏幕应用接收文件之前从第一装置接收HTTP代理服务器的URL。第二屏幕应用可以使用第一装置的HTTP代理服务器服务的GetProxyURL动作。以上描述了HTTP代理服务器服务和 GetProxyURL动作。
在本发明的另一实施方式中，第二模块102020可以使用所接收到的描述来访问触发器服务并且从第一装置接收触发器。这里，触发器服务可以是第二屏幕支持服务中的一个。以上描述了触发器。所接收到的触发器可以应用于第二装置中的应用以用作以上描述的时基触发器或激活触发器。因此，能够在特定时间执行应用的事件。
在本发明的另一实施方式中，应用可以是声明对象、触发声明对象、非实时声明对象或未绑定声明对象。
在本发明的另一实施方式中，首先，第二模块102020可以接收关于伴随应用的URL和名称的改变的通知。这里，伴随应用可以意指与在第一装置中正被执行的应用有关的应用。伴随应用可以是第二屏幕应用中的一个。其后，第二模块102020可以接收伴随应用的URL和名称并且使用HTTP代理服务器来接收伴随应用。这时，可以使用HTTP代理服务器服务来生成HTTP代理服务器。在这个实施方式中，第二装置可以使用第一装置的AppURL服务的GetAppURL动作。以上描述了AppURL 服务和GetAppURL动作。AppURL服务可以是第二屏幕支持服务中的一个。
本发明的模式
已经在用于执行本发明的最佳模式下描述了各种实施方式。
工业适用性
本发明可用于一系列广播服务提供领域。
对于本领域技术人员而言将显而易见的是，在不脱离本发明的精神或范围的情况下，能够对本发明做出各种修改和变化。因此，本发明旨在涵盖此发明的修改和变化，只要他们落入所附权利要求及其等同物的范围内即可。

Claims (8)

1.一种在第一装置处处理交互服务的方法，该方法包括以下步骤：
与第二装置配对；
提供允许所述第二装置访问经由广播流递送到所述第一装置的文件的HTTP代理服务器；
从所述广播流接收所述文件；
经由所述HTTP代理服务器将所述文件递送给所述第二装置；
从所述广播流或互联网服务器接收触发器，
其中，所述触发器是时基触发器或激活触发器，所述时基触发器用于为事件建立时基，并且所述激活触发器为以针对由应用参数表描述的段的应用作为目标的事件设定激活时间，
其中，所述应用参数表包括具有appID的应用元数据的应用元素，各个应用元素包括具有eventID的事件元数据的事件元素，并且各个事件元素包括具有dataID的数据集的数据元素，
其中，所述激活触发器通过参照appID来标识来自所述应用参数表的应用元素，并且所述激活触发器还通过参照eventID来标识来自所标识的应用元素的事件元素，并且所述激活触发器还通过参照dataID来标识来自所标识的事件元素的数据元素；
将来自所述激活触发器的信息与来自所述应用参数表的信息组合以生成增广触发器，其中，所述增广触发器包括来自所标识的应用元素的应用元数据、来自所标识的事件元素的事件元数据以及来自所标识的数据元素的数据集；以及
将所述增广触发器发送到所述第二装置。
2.根据权利要求1所述的方法，与所述第二装置配对的步骤还包括以下步骤：
向在所述第二装置中运行的第二屏幕应用发送发现消息，其中，所述发现消息通告所述第一装置提供的HTTP代理服务器服务，其中，所述HTTP代理服务器服务是用于提供HTTP代理服务器的服务；
从所述第二屏幕应用接收针对所述HTTP代理服务器服务的描述的请求；以及
向所述第二屏幕应用发送具有所述描述的响应。
3.根据权利要求1所述的方法，其中，递送所述文件的步骤包括以下步骤：
在递送所述文件之前将所述HTTP代理服务器的URL递送给所述第二装置。
4.根据权利要求1所述的方法，其中，递送所述文件的步骤包括：
向所述第二装置递送对伴随应用的名称和URL的改变的通知，其中，所述伴随应用与在所述第一装置中运行的应用相关联；
将所述伴随应用的所述名称和所述URL递送给所述第二装置；以及
经由所述HTTP代理服务器将所述伴随应用递送给所述第二装置。
5.一种用于作为第一装置处理交互服务的设备，该设备包括：
第一模块，所述第一模块与第二装置配对；
第二模块，所述第二模块从广播流接收文件；
第三模块，所述第三模块提供允许所述第二装置访问经由所述广播流递送到所述第二装置的文件的HTTP代理服务器，
其中，所述第三模块经由所述HTTP代理服务器将所述文件递送给所述第二装置；
第四模块，所述第四模块从所述广播流或互联网服务器接收触发器，
其中，所述触发器是时基触发器或激活触发器，所述时基触发器用于为事件建立时基，并且所述激活触发器为以针对由应用参数表描述的段的应用作为目标的事件设定激活时间，
其中，所述应用参数表包括具有appID的应用元数据的应用元素，各个应用元素包括具有eventID的事件元数据的事件元素，并且各个事件元素包括具有dataID的数据集的数据元素，
其中，所述激活触发器通过参照appID来标识来自所述应用参数表的应用元素，并且所述激活触发器还通过参照eventID来标识来自所标识的应用元素的事件元素，并且所述激活触发器还通过参照dataID来标识来自所标识的事件元素的数据元素；以及
其中，在所述第一装置中，将来自所述激活触发器的信息与来自所述应用参数表的信息组合以生成增广触发器，其中，所述增广触发器包括来自所标识的应用元素的应用元数据、来自所标识的事件元素的事件元数据以及来自所标识的数据元素的数据集，
其中，所述第一模块将所述增广触发器发送到所述第二装置。
6.根据权利要求5所述的设备，其中，所述第一模块通过以下处理与第二装置配对：
向在所述第二装置中运行的第二屏幕应用发送发现消息，其中，所述发现消息通告所述设备提供的HTTP代理服务器服务，其中，所述HTTP代理服务器服务是用于提供HTTP代理服务器的服务；
从所述第二屏幕应用接收针对所述HTTP代理服务器服务的描述的请求；以及
向所述第二屏幕应用发送具有所述描述的响应。
7.根据权利要求5所述的设备，
其中，所述第三模块在递送所述文件之前将所述HTTP代理服务器的URL递送给所述第二装置。
8.根据权利要求5所述的设备，
其中，所述第三模块向所述第二装置递送对伴随应用的名称和URL的改变的通知，其中，所述伴随应用与在所述设备中运行的应用相关联，
其中，所述第三模块将所述伴随应用的所述名称和所述URL递送给所述第二装置，并且
其中，所述第三模块经由所述HTTP代理服务器将所述伴随应用递送给所述第二装置。
CN201380054691.7A 2012-10-18 2013-10-17 处理交互服务的设备和方法 Active CN104904230B (zh)

Applications Claiming Priority (7)

Application Number Priority Date Filing Date Title
US201261715317P 2012-10-18 2012-10-18
US61/715,317 2012-10-18
US201261718679P 2012-10-25 2012-10-25
US61/718,679 2012-10-25
US201261721007P 2012-10-31 2012-10-31
US61/721,007 2012-10-31
PCT/KR2013/009303 WO2014062018A1 (en) 2012-10-18 2013-10-17 Apparatus and method for processing an interactive service

Publications (2)

Publication Number Publication Date
CN104904230A CN104904230A (zh) 2015-09-09
CN104904230B true CN104904230B (zh) 2018-10-09

Family

ID=50486340

Family Applications (2)

Application Number Title Priority Date Filing Date
CN201380054691.7A Active CN104904230B (zh) 2012-10-18 2013-10-17 处理交互服务的设备和方法
CN201380054721.4A Active CN104737549B (zh) 2012-10-18 2013-10-17 处理交互服务的设备和方法

Family Applications After (1)

Application Number Title Priority Date Filing Date
CN201380054721.4A Active CN104737549B (zh) 2012-10-18 2013-10-17 处理交互服务的设备和方法

Country Status (11)

Country Link
US (4) US8887223B2 (zh)
EP (2) EP2910029B1 (zh)
JP (2) JP6133996B2 (zh)
KR (2) KR20150073987A (zh)
CN (2) CN104904230B (zh)
AU (1) AU2013332537B2 (zh)
CA (2) CA2887653C (zh)
IN (1) IN2015MN01184A (zh)
MX (2) MX342463B (zh)
RU (1) RU2594295C1 (zh)
WO (2) WO2014062017A1 (zh)

Families Citing this family (71)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8365230B2 (en) 2001-09-19 2013-01-29 Tvworks, Llc 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
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
US8042132B2 (en) 2002-03-15 2011-10-18 Tvworks, Llc System and method for construction, delivery and display of iTV content
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
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
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
US11381875B2 (en) 2003-03-14 2022-07-05 Comcast Cable Communications Management, Llc Causing display of user-selectable content types
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
US20160196631A1 (en) * 2010-12-03 2016-07-07 Dolby Laboratories Licensing Corporation Hybrid Automatic Content Recognition and Watermarking
CA2839444C (en) * 2011-06-16 2016-05-31 Lg Electronics Inc. Method for transmitting a broadcast service, method for receiving a broadcast service, and apparatus for receiving a broadcast service
IN2015MN01184A (zh) 2012-10-18 2015-06-19 Lg Electronics Inc
US11115722B2 (en) 2012-11-08 2021-09-07 Comcast Cable Communications, Llc Crowdsourcing supplemental content
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
US9161074B2 (en) 2013-04-30 2015-10-13 Ensequence, Inc. Methods and systems for distributing interactive content
JP6168839B2 (ja) * 2013-05-15 2017-07-26 キヤノン株式会社 情報処理装置、その制御方法、プログラム
JP2015012561A (ja) * 2013-07-02 2015-01-19 ソニー株式会社 表示装置、情報取得方法及び情報提供方法
US9325646B2 (en) * 2013-10-28 2016-04-26 Verizon Patent And Licensing Inc. Providing contextual messages relating to currently accessed content
JP6325796B2 (ja) * 2013-11-06 2018-05-16 キヤノン株式会社 情報処理端末およびその制御方法、並びにプログラム
US10504200B2 (en) 2014-03-13 2019-12-10 Verance Corporation Metadata acquisition using embedded watermarks
WO2015138798A1 (en) * 2014-03-13 2015-09-17 Verance Corporation Interactive content acquisition using embedded codes
CN103826156B (zh) * 2014-03-17 2017-09-19 华为技术有限公司 终端遥控方法、机顶盒、移动终端及网页服务器
US9794599B2 (en) * 2014-04-10 2017-10-17 Telibrahma Convergent Communications Private Limited Method and system for auditing multimedia content
EP3131304A4 (en) * 2014-04-11 2018-01-24 Sony Corporation Reception apparatus, reception method, transmission apparatus, and transmission method
GB2527734A (en) * 2014-04-30 2016-01-06 Piksel Inc Device synchronization
US20170070790A1 (en) * 2014-05-13 2017-03-09 Sharp Kabushiki Kaisha A method of decoding a content bitstream
EP3163889A4 (en) * 2014-06-30 2018-02-14 LG Electronics Inc. -1- Broadcast transmitting device, broadcast receiving device, operating method for broadcast transmitting device and operating method for broadcast receiving device
FR3024813B1 (fr) * 2014-08-05 2016-09-02 Cineapps Procede de diffusion de sous-titres
US9538225B2 (en) 2014-08-06 2017-01-03 At&T Intellectual Property I, L.P. System and method for processing commerce events
US9805434B2 (en) 2014-08-20 2017-10-31 Verance Corporation Content management based on dither-like watermark embedding
US11783382B2 (en) 2014-10-22 2023-10-10 Comcast Cable Communications, Llc Systems and methods for curating content metadata
US9942602B2 (en) 2014-11-25 2018-04-10 Verance Corporation Watermark detection and metadata delivery associated with a primary content
WO2016086047A1 (en) 2014-11-25 2016-06-02 Verance Corporation Enhanced metadata and content delivery using watermarks
US10098168B2 (en) 2014-12-08 2018-10-09 Apple Inc. Neighbor awareness networking datapath
US9602891B2 (en) 2014-12-18 2017-03-21 Verance Corporation Service signaling recovery for multimedia content using embedded watermarks
US10455401B2 (en) * 2015-02-24 2019-10-22 Apple Inc. Neighbor awareness networking datapath—reciprocation and coexistence
KR101871727B1 (ko) * 2015-03-01 2018-06-27 엘지전자 주식회사 방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호 송신 방법, 및 방송 신호 수신 방법
WO2016140479A1 (ko) * 2015-03-01 2016-09-09 엘지전자 주식회사 방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호 송신 방법, 및 방송 신호 수신 방법
CA2981163A1 (en) * 2015-04-22 2016-10-27 Sharp Kabushiki Kaisha Systems and methods for content information communication
CA2984723A1 (en) * 2015-05-07 2016-11-10 Sharp Kabushiki Kaisha System for targeting and demographics
US10477283B2 (en) * 2015-05-22 2019-11-12 Dish Technologies Llc Carrier-based active text enhancement
US10893083B2 (en) 2015-05-25 2021-01-12 Apple Inc. Neighbor awareness networking datapath—scheduling, scheduler rank, and pre-datapath operation triggering
GB2538776A (en) * 2015-05-28 2016-11-30 Cisco Tech Inc Contextual content programming
EP3328019B1 (en) 2015-07-21 2019-11-27 LG Electronics Inc. Broadcasting signal transmitting apparatus, broadcasting signal receiving apparatus, broadcasting signal transmitting method, and broadcasting signal receiving method
CN113925665A (zh) 2015-10-13 2022-01-14 康迪普医疗有限公司 缓解骨盆腔器官脱垂的装置及系统
KR102393158B1 (ko) * 2015-10-13 2022-05-02 삼성전자주식회사 메타데이터를 포함하는 비트 스트림을 이용한 서비스 제공 방법 및 장치
MX2018010333A (es) * 2016-03-01 2018-11-09 Sharp Kk Sistemas y metodos para señalar identificadores de recursos usando marcas de agua.
JP2017188730A (ja) * 2016-04-01 2017-10-12 日本放送協会 情報提供システム、情報提供装置、提示端末及び視聴端末
US10110968B2 (en) 2016-04-19 2018-10-23 Google Llc Methods, systems and media for interacting with content using a second screen device
US10474745B1 (en) 2016-04-27 2019-11-12 Google Llc Systems and methods for a knowledge-based form creation platform
US11039181B1 (en) 2016-05-09 2021-06-15 Google Llc Method and apparatus for secure video manifest/playlist generation and playback
US10785508B2 (en) 2016-05-10 2020-09-22 Google Llc System for measuring video playback events using a server generated manifest/playlist
US10750248B1 (en) 2016-05-10 2020-08-18 Google Llc Method and apparatus for server-side content delivery network switching
US10771824B1 (en) 2016-05-10 2020-09-08 Google Llc System for managing video playback using a server generated manifest/playlist
US10750216B1 (en) 2016-05-10 2020-08-18 Google Llc Method and apparatus for providing peer-to-peer content delivery
US11069378B1 (en) 2016-05-10 2021-07-20 Google Llc Method and apparatus for frame accurate high resolution video editing in cloud using live video streams
US10595054B2 (en) 2016-05-10 2020-03-17 Google Llc Method and apparatus for a virtual online video channel
US11032588B2 (en) 2016-05-16 2021-06-08 Google Llc Method and apparatus for spatial enhanced adaptive bitrate live streaming for 360 degree video playback
US20180007307A1 (en) * 2016-07-02 2018-01-04 Qualcomm Incorporated Distributed Implementation Architecture for Broadcast Receiver
US10999331B1 (en) 2016-07-06 2021-05-04 Google Llc Reverse discovery and pairing of client devices to a media device
CN106656580B (zh) * 2016-11-29 2020-06-26 华为技术有限公司 一种业务状态的迁移方法及装置
CN112068908B (zh) 2017-10-23 2024-01-30 华为技术有限公司 图形处理方法及相关装置和设备
CN109034053A (zh) 2018-07-24 2018-12-18 京东方科技集团股份有限公司 显示模组及制备方法、控制方法和控制装置、显示装置
CN109358996B (zh) * 2018-10-08 2021-09-24 北京天弘瑞智科技有限公司 一种改变请求的处理方法及其处理系统
US11722741B2 (en) 2021-02-08 2023-08-08 Verance Corporation System and method for tracking content timeline in the presence of playback rate changes
US20220321945A1 (en) * 2021-04-06 2022-10-06 Infrared5, Inc. Server-side digital content insertion in audiovisual streams broadcasted through an interactive live streaming network

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101305611A (zh) * 2005-11-16 2008-11-12 阿尔卡特朗讯公司 交互式多用户电视方法和系统以及使用这种方法的电视接收器
WO2012112011A2 (ko) * 2011-02-20 2012-08-23 엘지전자 주식회사 심리스 콘텐트 재생 방법 및 장치
WO2012120524A2 (en) * 2011-03-09 2012-09-13 Tata Consultancy Services Limited A method and system for implementation of an interactive television application

Family Cites Families (63)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020056112A1 (en) * 1999-06-03 2002-05-09 Vincent Dureau Home digital assistant
US7222155B1 (en) * 1999-06-15 2007-05-22 Wink Communications, Inc. Synchronous updating of dynamic interactive applications
JP4597110B2 (ja) * 2000-04-14 2010-12-15 日本電信電話株式会社 放送情報に関連した情報の取得方法及びシステム並びに装置
US20050193425A1 (en) 2000-07-24 2005-09-01 Sanghoon Sull Delivery and presentation of content-relevant information associated with frames of audio-visual programs
US7305697B2 (en) * 2001-02-02 2007-12-04 Opentv, Inc. Service gateway for interactive television
US7146632B2 (en) * 2001-06-08 2006-12-05 Digeo, Inc. Interactive information aggregator for an interactive television system
US20030046304A1 (en) * 2001-09-05 2003-03-06 Peskin Christopher A. Event-based appointment scheduling adaptive to real-time information
US7634795B2 (en) * 2002-01-11 2009-12-15 Opentv, Inc. Next generation television receiver
US7944953B2 (en) * 2002-04-03 2011-05-17 Tvworks, Llc Method and apparatus for transmitting data in a data stream
WO2003088671A1 (en) 2002-04-05 2003-10-23 Matsushita Electric Industrial Co., Ltd. Asynchronous integration of portable handheld device
US8832754B2 (en) * 2002-05-03 2014-09-09 Tvworks, Llc System and method for providing synchronized events to a television application
JP3851217B2 (ja) 2002-05-09 2006-11-29 三洋電機株式会社 ディジタル放送受信装置
US8634030B2 (en) * 2002-10-25 2014-01-21 Disney Enterprises, Inc. Streaming of digital data to a portable device
WO2004095293A1 (ja) * 2003-04-24 2004-11-04 Mitsubishi Denki Kabushiki Kaisha 映像機器、映像モジュールユニット及び映像機器操作方法
US20040237120A1 (en) 2003-05-22 2004-11-25 Lewin Blake P. Systems and methods for dynamically generating and distributing synchronized enhancements to a broadcast signal
JP4478678B2 (ja) * 2003-06-02 2010-06-09 ディズニー エンタープライゼス インコーポレイテッド ビデオプレーヤを用いた商取引の方法及びシステム
US9380269B2 (en) 2003-09-23 2016-06-28 Time Warner Cable Enterprises Llc Scheduling trigger apparatus and method
US7421477B2 (en) * 2004-03-19 2008-09-02 Media Captioning Services Real-time media captioning subscription framework for mobile devices
US20080010664A1 (en) * 2004-08-30 2008-01-10 Maurizio Pelizza Method and System for Providing Interactive Services in Digital Television
US20100311399A1 (en) 2005-03-31 2010-12-09 United Video Properties, Inc. Systems and methods for generating audible reminders on mobile user equipment
JP2006323596A (ja) * 2005-05-18 2006-11-30 Toshiba Corp ネットワーク家電制御システム
US7711988B2 (en) * 2005-06-15 2010-05-04 The Board Of Trustees Of The University Of Illinois Architecture support system and method for memory monitoring
KR100703801B1 (ko) * 2005-10-21 2007-04-06 삼성전자주식회사 Ａｖ 태스크 계산 방법, ａｖ 태스크 계산을 위한 요약정보 제공 방법 및 이를 위한 장치
US20100062802A1 (en) 2006-04-10 2010-03-11 Noam Amram Method device and system for receiving a communication signal
US20100050205A1 (en) 2006-10-05 2010-02-25 Davis T Ron Method and system for supplementing television programming with e-mailed magazines
EP1976297A1 (en) * 2007-03-29 2008-10-01 Koninklijke KPN N.V. Method and system for autimatically selecting television channels
JP2009141389A (ja) * 2007-12-03 2009-06-25 Fujitsu Ten Ltd 表示装置および表示方法
US8775647B2 (en) * 2007-12-10 2014-07-08 Deluxe Media Inc. Method and system for use in coordinating multimedia devices
KR20090083273A (ko) * 2008-01-29 2009-08-03 삼성전자주식회사 부가 컨텐츠 제공을 위한 메타데이터를 저장한 정보저장매체, 부가 컨텐츠 제공 방법 및 디지털 방송 수신장치
KR20090088771A (ko) * 2008-02-15 2009-08-20 삼성전자주식회사 디지털 비디오 방송 시스템에서 통신채널로 통지메시지를전송하는 장치 및 방법
US8671424B2 (en) 2008-05-15 2014-03-11 Microsoft Corporation Log-based targeting of advertisements to groups
US20100098074A1 (en) * 2008-10-22 2010-04-22 Backchannelmedia Inc. Systems and methods for providing a network link between broadcast content and content located on a computer network
US9288444B2 (en) * 2008-12-30 2016-03-15 Bce Inc. System and method for video signal delivery
JP5433239B2 (ja) * 2009-01-15 2014-03-05 日本放送協会 放送型アプリケーションの起動システム
JP2010166355A (ja) 2009-01-16 2010-07-29 Nec Corp 通信システム
JP2011009838A (ja) * 2009-06-23 2011-01-13 Sumitomo Electric Ind Ltd 映像通信システム及び映像通信方法
EP2478699A4 (en) * 2009-09-17 2014-08-20 Ericsson Telefon Ab L M METHOD AND ARRANGEMENT FOR THE JOINT USE OF MEDIA CONTENT
US8010408B2 (en) * 2009-10-09 2011-08-30 Walter M. Rubinstein Packetized advertising utilizing information indicia
US9277183B2 (en) * 2009-10-13 2016-03-01 Sony Corporation System and method for distributing auxiliary data embedded in video data
KR101656882B1 (ko) * 2009-12-04 2016-09-12 삼성전자주식회사 네트워크에서 원격 유저 인터페이스 목록을 제공하는 방법 및 장치
CN102088680B (zh) 2009-12-07 2014-11-26 梁耀峰 基于有线和无线传感网络的通用移动通信系统
JP5720095B2 (ja) * 2009-12-18 2015-05-20 ソニー株式会社 受信装置、受信方法、送信装置、送信方法、プログラム、および放送システム
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
US8583811B2 (en) * 2010-04-23 2013-11-12 Qualcomm Incorporated Gateway device for multimedia content
US20110302599A1 (en) * 2010-06-07 2011-12-08 Mark Kenneth Eyer TV-Centric Actions in Triggered Declarative Objects
US8863171B2 (en) 2010-06-14 2014-10-14 Sony Corporation Announcement of program synchronized triggered declarative objects
US8843957B2 (en) * 2010-06-21 2014-09-23 Accenture Global Services Limited Frame accurate content insertion system
US8516528B2 (en) 2010-06-30 2013-08-20 Cable Television Laboratories, Inc. Synchronization of 2nd screen applications
US9832441B2 (en) 2010-07-13 2017-11-28 Sony Interactive Entertainment Inc. Supplemental content on a mobile device
US9814977B2 (en) 2010-07-13 2017-11-14 Sony Interactive Entertainment Inc. Supplemental video content on a mobile device
US8893210B2 (en) * 2010-08-20 2014-11-18 Sony Corporation Server load balancing for interactive television
US8595783B2 (en) * 2010-08-30 2013-11-26 Sony Corporation Receiving device, receiving method, program, and broadcasting system
US9179198B2 (en) * 2010-10-01 2015-11-03 Sony Corporation Receiving apparatus, receiving method, and program
KR101246129B1 (ko) * 2010-10-13 2013-03-21 에스케이플래닛 주식회사 멀티미디어 서비스 시스템 및 방법
CA3029177C (en) 2010-12-29 2020-09-22 Bce Inc. Method and system for trigger management in an interactive television environment
US9554175B2 (en) * 2011-07-20 2017-01-24 Sony Corporation Method, computer program, reception apparatus, and information providing apparatus for trigger compaction
TWI528749B (zh) 2011-09-06 2016-04-01 Sony Corp A signal receiving device, a signal receiving method, an information processing program and an information processing system
US10142121B2 (en) 2011-12-07 2018-11-27 Comcast Cable Communications, Llc Providing synchronous content and supplemental experiences
US8930988B2 (en) 2011-12-21 2015-01-06 Sony Corporation Reception apparatus, reception method, program, and information processing system
US9066200B1 (en) 2012-05-10 2015-06-23 Longsand Limited User-generated content in a virtual reality environment
US9479804B2 (en) 2012-08-30 2016-10-25 Verizon Patent And Licensing Inc. Digital video recorder program to mobile device
US9078129B1 (en) 2012-09-24 2015-07-07 Emc Corporation Knowledge-based authentication for restricting access to mobile devices
IN2015MN01184A (zh) 2012-10-18 2015-06-19 Lg Electronics Inc

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101305611A (zh) * 2005-11-16 2008-11-12 阿尔卡特朗讯公司 交互式多用户电视方法和系统以及使用这种方法的电视接收器
WO2012112011A2 (ko) * 2011-02-20 2012-08-23 엘지전자 주식회사 심리스 콘텐트 재생 방법 및 장치
WO2012120524A2 (en) * 2011-03-09 2012-09-13 Tata Consultancy Services Limited A method and system for implementation of an interactive television application

Also Published As

Publication number Publication date
AU2013332537B2 (en) 2016-06-16
KR20150076163A (ko) 2015-07-06
US20140115060A1 (en) 2014-04-24
CA2887653A1 (en) 2014-04-24
MX2015004730A (es) 2015-07-23
JP2016503599A (ja) 2016-02-04
MX346770B (es) 2017-03-31
CN104904230A (zh) 2015-09-09
US8887223B2 (en) 2014-11-11
MX2015004659A (es) 2015-08-07
AU2013332537A1 (en) 2015-04-30
EP2910029B1 (en) 2019-06-05
WO2014062018A1 (en) 2014-04-24
RU2594295C1 (ru) 2016-08-10
CA2887659A1 (en) 2014-04-24
IN2015MN01184A (zh) 2015-06-19
EP2910030A1 (en) 2015-08-26
US9723375B2 (en) 2017-08-01
CA2887653C (en) 2017-12-12
KR20150073987A (ko) 2015-07-01
MX342463B (es) 2016-09-30
EP2910030A4 (en) 2016-06-08
US20140115644A1 (en) 2014-04-24
JP6133996B2 (ja) 2017-05-24
CN104737549B (zh) 2018-03-27
EP2910029A1 (en) 2015-08-26
EP2910030B1 (en) 2019-12-04
US20150026743A1 (en) 2015-01-22
JP2016500224A (ja) 2016-01-07
US9578391B2 (en) 2017-02-21
EP2910029A4 (en) 2016-05-18
JP6133997B2 (ja) 2017-05-24
CN104737549A (zh) 2015-06-24
CA2887659C (en) 2017-10-31
US20150058905A1 (en) 2015-02-26
WO2014062017A1 (en) 2014-04-24

Similar Documents

Publication Publication Date Title
CN104904230B (zh) 处理交互服务的设备和方法
CN104871552B (zh) 处理交互服务的设备和方法
CN104396186B (zh) 用于处理互动服务的装置及方法
CN104584574B (zh) 处理交互服务的设备和方法
CN104662925B (zh) 处理交互服务的设备和方法

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