CN110226330A

CN110226330A - 具有内容标识符的恢复数据

Info

Publication number: CN110226330A
Application number: CN201880008466.2A
Authority: CN
Inventors: 萨钦·G·德施潘德
Original assignee: Sharp Corp
Current assignee: Sharp Corp
Priority date: 2017-02-14
Filing date: 2018-02-13
Publication date: 2019-09-10
Also published as: CA3049348A1; US20200128290A1; US11019390B2; WO2018151105A1; CA3049348C; TW201836362A; TWI793106B

Abstract

公开了一种用于接收“恢复数据表”(参见图36A和38F)的方法和接收器，所述“恢复数据表”用于检索“补充内容”。所述“恢复数据表”(参见图36A和38F)具有“contentID.type”字段，该字段描述“内容标识符的类型”并定义“统一资源名”(参见段落[0230]‑[0241])。

Description

具有内容标识符的恢复数据

技术领域

本发明通常涉及具有视听内容水印的系统。

背景技术

在许多数字广播系统中，广播站传送视听内容和一个或多个增强服务数据。增强服务数据可以与视听(AV)内容一起提供以提供信息和服务，或者可以与AV内容分开提供以提供信息和服务。

在许多广播环境中，AV呈现设备不直接接收来自广播站的AV内容和一个或多个增强服务数据。而是诸如电视的AV呈现设备典型地连接到下述广播接收设备，该广播接收设备以压缩的形式接收AV内容和一个或多个增强服务数据并且将未压缩的AV内容提供给AV呈现设备。

在一些广播环境中，广播接收设备接收来自服务器(有时称为多信道视频节目分销商(MVPD))的AV内容。MVPD接收来自广播站的AV广播信号，从所接收到的AV广播信号提取内容，将所提取的内容转换成具有适于传输的格式的AV信号，并且将所转换的AV信号提供给广播接收设备。在转换处理期间，MVPD经常移除从广播站所提供的增强服务数据或者可以并入要提供给广播接收设备的不同的增强服务数据。按照这种方式，广播站可以提供具有增强服务数据的AV内容，但是如果有的话最终提供给AV呈现设备和/或广播接收设备的增强服务数据可能与广播站所提供的不同。

因为广播接收设备从MVPD所接收到的信号提取AV内容并且仅将未压缩的AV数据提供给AV呈现设备，因此仅提供给广播接收设备的增强服务数据是可获得的。此外，可以不将广播站所提供的相同的增强服务数据提供给广播接收设备和/或AV呈现设备。

结合附图，当考虑对本发明的以下详细描述时，将更容易地理解本发明的上述及其它目的、特征、以及优点。

发明内容

根据本公开的一个示例，一种用于接收来自提供商的补充内容的方法包括以下步骤：(a)接收包括RecoveryDataTable元素的恢复文件格式的恢复数据表；(b)接收所述RecoveryDataTable元素的contentID字段，该contentID字段描述关于在消息中所提供的内容标识符的信息；(c)接收所述contentID字段的type字段，该type字段描述内容标识符的类型并定义统一资源名；(d)接收所述contentID字段的cid字段，该cid字段描述广告标识符并且其中所述cid字段的最大长度为10；(e)接收所述contentID字段的valid from字段，该字段描述内容标识符自何时起有效；(f)接收所述contentID字段的valid until字段，该字段描述内容标识符直至何时有效；(g)根据所述恢复数据表接收补充内容。

根据本公开的另一示例，一种用于接收来自提供商的补充内容的接收器包括以下步骤：(a)所述接收器接收包括RecoveryDataTable元素的恢复文件格式的恢复数据表；(b)所述接收器接收所述RecoveryDataTable元素的contentID字段，该contentID字段描述关于在消息中所提供的内容标识符的信息；(c)所述接收器接收所述contentID字段的type字段，该type字段描述内容标识符的类型并定义统一资源名；(d)所述接收器接收所述contentID字段的cid字段，该cid字段描述广告标识符并且其中所述cid字段的最大长度为10；(e)所述接收器接收所述contentID字段的valid from字段，该字段描述内容标识符自何时起有效；(f)所述接收器接收所述contentID字段的valid until字段，该字段描述内容标识符直至何时有效；(g)所述接收器根据所述恢复数据表接收补充内容。

附图说明

[图1]图1说明了具有增强服务信息的系统。

[图2]图2说明了具有增强信息的另一系统。

[图3]图3说明了具有增强信息的系统的数据流。

[图4]图4说明了具有增强信息的另一系统。

[图5]图5说明了水印有效载荷。

[图6]图6说明了另一水印有效载荷。

[图7]图7说明了水印有效载荷之间的关系。

[图8]图8说明了水印有效载荷之间的关系。

[图9]图9说明了水印有效载荷之间的关系。

[图10]图10说明了具有增强信息的另一系统。

[图11]图11说明了获得同步并保持同步。

[图12]图12说明了另一水印有效载荷。

[图13]图13说明了标准开发组织(SDO)私有数据。

[图14]图14说明了使用一个或多个cmdID封装在SDO私有数据内的作为SDO有效载荷的元数据。

[图15]图15说明了示例性JavaScript对象表示法模式。

[图16A]图16A说明了JavaScript对象表示法模式的逻辑结构。

[图16B]图16B说明了JavaScript对象表示法模式的逻辑结构。

[图16C]图16C说明了JavaScript对象表示法模式的逻辑结构。

[图16D]图16D说明了JavaScript对象表示法模式的逻辑结构。

[图17]图17说明了示例性水印相关信息检索JavaScript对象表示法模式。

[图18]图18说明了示例性恢复文件格式JavaScript对象表示法模式。

[图19]图19说明了示例性水印相关信息检索JavaScript对象表示法模式。

[图20]图20说明了示例性恢复文件格式JavaScript对象表示法模式。

[图21]图21说明了示例性恢复文件格式JavaScript对象表示法模式。

[图22]图22说明了示例性恢复文件格式逻辑结构。

[图23]图23说明了示例性组件描述逻辑结构。

[图24A]图24A示出了示例性组件锚点逻辑结构。

[图24B]图24B说明了示例性组件锚点逻辑结构。

[图24C]图24C说明了示例性组件锚点逻辑结构。

[图25A]图25A说明了示例性恢复文件格式JavaScript对象表示法模式。

[图25B]图25B说明了图25A的接下来部分。

[图25C]图25C说明了图25B的接下来部分。

[图25D]图25D说明了图25C的接下来部分。

[图26A]图26A说明了示例性恢复文件格式JavaScript对象表示法模式。

[图26B]图26B说明了图26A的接下来部分。

[图26C]图26C说明了图26B的接下来部分。

[图26D]图26D说明了图26C的接下来部分。

[图27A]图27A说明了示例性恢复文件格式JavaScript对象表示法模式。

[图27B]图27B说明了图27A的接下来部分。

[图27C]图27C说明了图27B的接下来部分。

[图27D]图27D说明了图27C的接下来部分。

[图28]图28说明了示例性恢复文件格式逻辑结构。

[图29]图29说明了示例性组件描述逻辑结构。

[图30]图30说明了示例性组件锚点逻辑结构。

[图31]图31说明了示例性slsProtocol值。

[图32]图32说明了示例性urlType值。

[图33A]图33A说明了示例性恢复文件格式JavaScript对象表示法模式。

[图33B]图33B说明了图33A的接下来部分。

[图33C]图33C说明了图33B的接下来部分。

[图33D]图33D说明了图33C的接下来部分。

[图33E]图33E说明了图33D的接下来部分。

[图34A]图34A说明了示例性恢复文件格式JavaScript对象表示法模式。

[图34B]图34B说明了图34A的接下来部分。

[图34C]图34C说明了图34B的接下来部分。

[图34D]图34D说明了图34C的接下来部分。

[图35A]图35A说明了示例性恢复文件格式JavaScript对象表示法模式。

[图35B]图35B说明了图35A的接下来部分。

[图35C]图35C说明了图35B的接下来部分。

[图35D]图35D说明了图35C的接下来部分。

[图35E]图35E说明了图35D的接下来部分。

[图36A]图36A说明了示例性恢复文件格式逻辑结构。

[图36B]图36B说明了图36A的接下来部分。

[图37A]图37A说明了示例性恢复文件格式JavaScript对象表示法模式。

[图37B]图37B说明了图37A的接下来部分。

[图37C]图37C说明了图37B的接下来部分。

[图37D]图37D说明了图37C的接下来部分。

[图37E]图37E说明了图37D的接下来部分。

[图38A]图38A说明了示例性恢复文件格式JavaScript对象表示法模式。

[图38B]图38B说明了图38A的接下来部分。

[图38C]图38C说明了图38B的接下来部分。

[图38D]图38D说明了图38C的接下来部分。

[图38E]图38E说明了图38D的接下来部分。

[图38F]图38F说明了图38E的接下来部分。

[图38G]图38G说明了图38F的接下来部分。

[图38H]图38H说明了图38G的接下来部分。

[图38I]图38I说明了图38H的接下来部分。

[图38J]图38J说明了图38I的接下来部分。

具体实施方式

参考图1，该系统可以包括内容源100、内容识别服务提供服务器120、MVPD 130、增强服务信息提供服务器140、广播接收设备160、网络170、以及AV呈现设备180。

内容源100可以对应于广播包括一个或多个AV内容(例如音频和/或视频)流的广播信号的广播站。广播站可以使用高级电视系统委员会(ATSC)发射规范。广播信号可以进一步包括增强服务数据和/或信令信息。增强服务数据优选地涉及一个或多个AV广播流。增强数据服务可以具有诸如例如服务信息、元数据、附加数据、编译的执行文件、web应用程序、超文本标记语言(HTML)文档、可扩展标记语言(XML)文档、层叠样式表单(CSS)文档、音频文件、视频文件、ATSC、未来版本内容、以及诸如统一资源定位符(URL)的地址的任何合适格式。

内容识别服务提供服务器120提供内容识别服务，该内容识别服务允许AV呈现设备180根据来自内容源100的AV内容来识别内容。内容识别服务提供服务器120可以诸如通过包含水印，可选地修改AV广播内容。

内容识别服务提供服务器120可以包括水印插入器。水印插入器可以插入水印，该水印被设计为当对观看者来说不可察觉或至少最小程度地干扰的同事携带增强服务数据和/或信令信息。在其它情况下，可以插入易于可观察的水印(例如易于可观察的可以是在图像中容易被看到的和/或易于可观察的可以是在音频中容易被听到的)。例如，易于可观察的水印可以是诸如在每帧的左上或右上的内容提供商的标志的标志。

内容识别服务提供服务器120可以包括水印插入器，该水印插入器修改AV内容以包括不易于可观察的水印(例如不易于可观察的可以是在图像中不易看见的和/或不易于可观察的可以是在音频中不易听见的)。例如，不易于可观察的水印可以包括安全信息、跟踪信息、数据、或其它。另一示例包括信道、内容、定时、触发器、和/或URL信息。

MVPD 130接收来自一个或多个广播站的广播信号并且通常将多路复用的广播信号提供给广播接收设备160。MVPD 130可以对所接收到的广播信号执行解调和信道解码以提取AV内容和增强服务数据。MVPD 130还可以对所提取的AV内容和增强服务数据执行信道编码以生成用于进一步分发的多路复用信号。MVPD 130可以排除所提取的增强服务数据和/或可以包括不同的增强服务数据。

广播接收设备160可以调谐到用户所选的信道并接收调谐信道的AV信号。广播接收设备160典型地对所接收到的信号执行解调和频道信道解码以提取期望的AV内容。广播接收设备160使用诸如例如H.264、运动图像专家组(MPEG)高级视频编码(AVC)、H.265、高效视频编码(HEVC)、杜比数字(AC3)、和/或高级音频编码(AAC)系统的任何合适技术对所提取的AV内容进行解码。广播接收设备160典型地将未压缩的AV内容提供给AV呈现设备180。

增强服务信息提供服务器140响应于来自AV呈现设备180的请求而向AV内容提供增强服务信息。

AV呈现设备180可以包括诸如例如电视、笔记本电脑、移动电话、以及智能电话的显示器。AV呈现设备180可以接收来自广播接收设备160的未压缩(或压缩)的AV或者视频或音频内容，接收来自内容源100的包括编码的AV或者视频或音频内容的广播信号，和/或接收来自MVPD 130的编码或解码的AV或者视频或音频内容。在一些情况下，可以经由高清晰度多媒体接口(HDMI)电缆接收未压缩的视频和音频。AV呈现设备180可以通过网络170接收来自内容识别服务提供服务器120的与来自增强服务信息提供服务器140的AV内容有关的增强服务的地址。

应该理解的是可以根据需要对内容源100、内容识别服务提供服务器120、MVPD130、以及增强服务信息提供服务器140进行组合或忽略。应该理解是这些是逻辑角色。在一些情况下，这些实体中的一些可以是单独的物理设备。在其它情况下，这些逻辑实体中的一些可以实现在同一物理设备中。例如，如果需要，可以对广播接收设备160和AV呈现设备180进行组合。

参考图2，修改的系统可以包括水印插入器190。水印插入器190可以修改AV(例如音频和/或视频)内容以在AV内容中包括附加信息。MVPD 130可以接收和分发包括具有水印的修改的AV内容的广播信号。

水印插入器190优选地按照包括数字信息形式的不易于(例如视觉地和/或听觉地)可观察的附加信息的方式来修改信号。在不易于可观察的水印中，所插入的信息在音频和/或视频中可以是易于可标识的。在不易于可观察的水印中，尽管信息包括在AV内容(例如音频和/或视频)中，但是用户不容易知道该信息。

水印的一个用途是用于禁止非法复制数字媒体的版权保护。水印的另一用途是对数字媒体的源跟踪。水印的进一步用途是数字媒体的描述性信息。水印的又一用途是提供可以接收到与数字媒体相关联的附加内容的位置信息。水印的又一用途是标识正在观看的内容和内容源以及该内容中的当前时间点，并且此后允许设备经由因特网连接访问期望的附加功能。区别于与AV内容一起传递的元数据，水印信息包含在AV内容本身内。作为示例，可以通过使用扩频技术、量化技术、和/或幅度调制技术来包括水印信息。

参考图3，说明了示例性数据流。内容源100将包括至少一个AV内容和增强服务数据201的广播信号传送到水印插入器190。

水印插入器190接收内容源100所提供的广播信号并且使易于可观察和/或不易于可观察的水印包含在AV内容中。将具有水印的修改的AV内容与增强服务数据203一起提供给MVPD 130。

与水印相关联的内容信息可以包括例如提供AV内容的内容提供商的标识信息、AV内容标识(ContentID)信息、在内容信息获取中所使用的内容部分的时间信息、通过其广播AV内容的信道的名称、通过其广播AV内容的信道信道的标记、通过其广播AV内容的信道的描述、报告周期的使用信息、使用信息获取的最小使用时间、体育赛事的统计、有用信息的显示、小部件、应用程序、可执行文件、和/或与AV内容有关的可用的增强服务信息。

可以以诸如基于因特网协议(IP)的路径或ATSC-移动手持式路径的任何方式来表示可用的增强服务数据的获取路径。

MVPD 130接收包括加水印的AV内容和增强数据服务的广播信号，并且可以产生复用信号以将其提供给广播接收设备160。此时，复用信号可以不包括(exclude)所接收到的增强服务数据和/或可以包括不同增强型服务数据。

广播接收设备160可以调谐到用户所选的信道并且接收调谐信道的信号，对接收到的信号进行解调，对解调的信号执行信道解码和音频-视频解码以生成未压缩的音频-视频内容，并且此后将未压缩的AV内容提供206给AV呈现设备180。内容源100还可以通过信道向AV呈现设备180广播207AV内容。MVPD 130可以直接将包括AV内容的广播信号传送208到AV呈现设备180而无需经过广播接收设备160。在又一情况下，可以通过宽带连接将一些AV信息发送到AV呈现设备180。在一些情况下，这可以是托管型宽带连接。在另一情况下，它可能是非托管型宽带连接。

AV呈现设备180可以接收来自广播接收设备160的未压缩(或压缩)的AV内容。另外，AV呈现设备180可以通过信道接收来自内容源100的广播信号，并且此后，可以对所接收到的广播信号进行解调和解码以获得AV内容。另外，AV呈现设备180可以接收来自MVPD 130的广播信号，并且此后，可以对所接收到的广播信号进行解调和解码以获得AV内容。AV呈现设备180(或广播接收设备160)从一个或多个视频帧或者对所接收到的AV内容的音频样本的选择中提取水印信息。AV呈现设备180可以使用从水印所获得的信息以向增强服务信息提供服务器140(或任何其它设备)提出对附加信息的请求209。增强服务信息提供服务器140可以响应于此而提供应答。

参考图4，进一步示例包括将AV内容与增强服务数据(如果需要)一起提供给水印插入器190的内容源100。另外，内容源100可以将代码300与AV内容一起提供给水印插入器190。代码300可以是标识应该用水印修改多个AV流当中的哪一个的任何合适代码。例如，代码＝1可以标识第一AV流，代码＝2可以标识第二AV流，代码＝3可以标识第三AV流，代码＝4可以标识第四AV流等等。代码可以包括AV内容内的时序位置信息。如果需要，代码可以包括其它元数据。

水印插入器190将加水印的AV内容和相关数据、以及信令提供给MVPD，MVPD继而可以将加水印的压缩AV内容提供给广播接收设备160(例如机顶盒)。广播接收设备160可以将加水印的AV内容(例如典型地是未压缩的)提供给AV呈现设备180。AV呈现设备180可以包括具有水印能力的接收器310以及水印客户端320。具有水印能力的接收器310适合于对AV内容内的水印的存在性进行检测并且从AV内容提取水印数据。水印客户端320适合于使用从水印所提取的数据以根据其请求附加数据，并且随后以合适的方式使用该附加数据。

AV呈现设备180可以使用来自所提取的水印的代码300来向元数据服务器350提出请求。代码数据库370接收来自内容源100的包括代码300和元数据360的数据。将代码300和元数据360存储在代码数据库370中以供随后使用。按照这种方式，还将提供给编码在AV内容内的水印插入器190的代码300与其元数据360一起存储在代码数据库370中。在MVPD 130或者否则移除相关元数据或者否则改变相关元数据的情况下，它可由AV呈现设备180从元数据服务器350恢复，该元数据服务器350使用所提供的代码351来查询代码数据库370并向AV呈现设备180提供与元数据353相关联的响应。AV呈现设备180使用由元数据服务器350所提供的应答元数据以形成提供给内容和信令服务器380的请求355。响应于该请求，内容和信令服务器380将所选内容和信令357提供给AV呈现设备180。通常，内容和信令服务器380可以与元数据服务器350不同。

然而，向元数据服务器提出第一请求以获得对所提供的代码的响应并且此后随后使用元数据以向内容和信令服务器380提供请求是繁重的，并且由于利用了两个不同的服务器和/或请求而极易发生故障。另外，它可能增加延迟。

举例来说，元数据可以由以下语法元素中的一个或多个组成：

(1)内容和信令服务器的位置(例如服务器所处的位置，诸如其网络地址。网络地址的示例是域名、IP v4地址等)；

(2)用于与内容和信令服务器进行通信的协议；例如安全超文本传输协议(HTTPS)或超文本传输协议(HTTP)；

(3)标识AV内容中的时序位置的时间码(例如AV内容中元数据应与其相关联的位置)；

(4)时间敏感事件触发(例如AV内容中的特定位置的广告或事件)；

(5)信道标识(例如信道特定信息；本地信道内容)；

(6)客户端随机执行内容和信令服务器请求的持续时间(例如用于负载平衡)。为简洁起见，还可以将该语法元素称为内容服务器请求的持续时间；

(7)等等。

当加水印的音频-视频广播具有不易于可观察的信息时，嵌入在音频-视频内容中的水印典型地具有仅携带几比特的有效载荷信息的能力。对于相对小的有效载荷大小，时间码(上面的元素3)和/或内容和信令服务器的位置(上面的元素1)倾向于占据可用有效载荷的很大一部分，这为剩余数据留下有限的附加有效载荷，这往往是有问题的。

为了在水印内包括足够的元数据以使得时间码和位置信息这两者可以与附加信息一起提供，可能需要跨多个水印有效载荷划分元数据。每个水印有效载荷同样优选地包括在AV内容的不同部分内。将从多个水印有效载荷所提取的数据组合在一起以形成将用于提出请求的期望信息集。在下面的描述中，术语有效载荷可以用于指示水印有效载荷。每个语法元素可以包含在单个有效载荷内、跨越多个有效载荷、和/或分段跨多个有效载荷。为了标识的目的，可以为每个有效载荷分配有效载荷类型。此外，可以在属于相同或近似相同时间线位置的多个有效载荷之间建立关联。此外，根据需要，该关联可以是单向的或双向的。

可以从跨越AV内容的若干时序位置的有效载荷获得期望的时间码数据。因此，一些系统可以建立规则以使所确定的时间码与AV内容的特定时序位置相关联。在示例中，所选的时序位置可以对应于预定水印有效载荷末端处的时序位置。

例如，有效载荷大小可以是50比特，而期望元数据可以是70比特，因而超过了单个水印的有效载荷大小。期望的元数据的示例可以如下：

内容和服务器的位置(I)32比特(IP地址)

应用层协议(A)1比特(HTTP或HTTPS)

时间码(T)25比特(1年的唯一性，其中粒度为1秒)

时间敏感触发(D)1比特(值为1指示AV呈现设备应查询交互内容。值为0指示AV呈现设备不应查询交互内容(例如，如在时间基础触发中))。

信道标识(L)9比特

内容服务器请求的持续时间(R)2比特

期望的元数据的另一示例可以如下：

内容和服务器的位置(I)32比特(IP地址)

应用层协议(A)2比特(00＝HTTP，01＝HTTPS，10＝保留，11＝保留)

时间码(T)25比特(1年的唯一性，其中粒度为1秒)

时间敏感触发(D)1比特

信道标识(L)9比特

内容服务器请求的持续时间(R)2比特

划分元数据的一个方式是使内容和信号服务器通信信息(CSSCI)包括在一个有效载荷中并且使时间线信息包括在另一有效载荷中。CSSCI有效载荷可以包括例如位置信息(例如内容和信令服务器的位置)、关联信息(例如使CSSCI有效载荷与一个或多个其它有效载荷相关联的标识符)、以及如何信息(例如应用层协议、内容服务器请求的持续时间)。时间线信息可以包括例如关联信息(例如使时间线与一个或多个其它有效载荷相关联的标识符)、何时信息(例如时间码信息)、以及哪些信息(例如信道标识)。

参考图5，说明了示例性CSSCI有效载荷。

参考图6，说明了示例性时间位置有效载荷。可以替代地使用术语时间(time)位置以代替术语时序(temporal)位置。

有效载荷类型可以由第一比特“Y”来标识。当Y被设置为0时，有效载荷对应于CSSCI有效载荷并且14比特有效载荷标识符(P)用于标记CSSCI。当Y被设置为1时，有效载荷对应于时序位置有效载荷并且14比特有效载荷标识符(P)发信号通知相应CSSCI。结果，具有相同有效载荷标识符(P)值的不同有效载荷类型彼此相关联。标识符R指示传播内容和信令服务器请求的持续时间。在示例中，Y可以对应于2比特字段，其中值00指示出CSSCI有效载荷，值01指示时序位置有效载荷，并且值10、11被保留以供将来使用。

参考图7，示出了示例性时间线。第一CSSCI类型有效载荷(例如CSSCI-0)具有第一集合关联信息P，而第二CSSCI类型有效载荷(例如CSSCI-1)具有第二不同集合关联信息P。具有用于CSSCI-0和CSSCI-1的两个不同关联信息P以区分并标识两个CSSCI有效载荷。第一时间位置有效载荷(例如时间线-0)具有与CSSCI-0的关联信息P相匹配的第一集合关联信息P，第二时间位置有效载荷(例如时间线-1)具有与CSSCI-0的关联信息P相匹配的相同第一集合关联信息P，第三时间位置有效载荷(例如时间线-2)具有与CSSCI-1的关联信息P相匹配的相同第二集合关联信息P。按照这种方式，将CSSCI-0，Timeline-0；CSSCI-0，时间轴-1；以及CSSCI-1，时间轴-2关联在一起以作为具有跨越的水印信息的对。这允许相同的CSSCI类型有效载荷用于多个不同的时间位置有效载荷。

如所说明的，每个时序位置有效载荷与先前接收到的CSSCI类型有效载荷相关联，并且因而在其关联中是单向的。在与时序位置有效载荷相匹配的先前CSSCI类型有效载荷不可用的情况下，则系统可以能够确定数据包已丢失或否则水印无效。水印数据的丢失以某种频率发生，因为音频-视频内容往往通过音频-视频转码来修改，诸如以降低音频-视频内容的比特率。

参考图8，说明了示例性时间线。第一CSSCI类型有效载荷(例如CSSCI-0)具有第一集合关联信息P，而第二CSSCI类型有效载荷(例如CSSCI-1)具有第二不同集合关联信息P。具有用于CSSCI-0和CSSCI-1的两个不同关联信息P以区分并标识两个CSSCI有效载荷。第一时间位置有效载荷(例如时间线-0)具有与CSSCI-0的关联信息P相匹配的第一集合关联信息P，第二时间位置有效载荷(例如时间线-1)具有与CSSCI-0的关联信息P相匹配的相同第一集合关联信息P，第三时间位置有效载荷(例如时间线-2)具有与CSSCI-1的关联信息P相匹配的相同第二集合关联信息P。按照这种方式，将CSSCI-0，Timeline-0；CSSCI-0，时间轴-1；以及CSSCI-1，时间轴-2关联在一起以作为具有跨越的水印信息的对。这允许相同的CSSCI类型有效载荷用于多个不同的时间位置有效载荷。如所说明的，时序位置有效载荷中的两个与先前接收到的CSSCI类型有效载荷相关联，并且CSSCI类型有效载荷中的一个与随后接收到的时序位置有效载荷相关联，并且因而在其关联中是双向的。在与时序位置有效载荷相匹配的相应CSSCI类型有效载荷不可用的情况下，则系统可以能够确定数据包已丢失或否则水印无效。类似地，在与CSSCI有效载荷相匹配的相应时间线类型有效载荷不可用的情况下，则系统可以能够确定数据包已丢失或否则水印无效。水印数据的丢失以某种频率发生，因为音频-视频内容往往通过音频-视频转码来修改，诸如以降低音视频内容的比特率。

在示例中，CSSCI类型有效载荷(例如CSSCI-0)具有两个集合关联信息P0和P1。时间位置有效载荷(例如时间线-0)具有与CSSCI-0的关联信息P0和P1相匹配的两个集合关联信息P0和P1。在该示例中，对于CSSCI-0，时间线-0对，存在双向关联，其中P0指向CSSCI-0并且P1指向时间线-0。

可以根据需要对分配给有效载荷标识符(P)的比特数进行修改(例如对于期望的鲁棒性)。类似地，可以根据需要对分配给I、A、T、D、L、以及R的比特数进行修改。

在示例中，AV呈现设备180可以保持列表，该列表可以由例如最近接收到的CSSCI有效载荷“c”的变量listC来表示。如果需要，“c”可以提供于水印中或者否则由系统来设置。按照这种方式，AV呈现设备180可以仅需要在存储器中保持有限数量的CSSCI有效载荷。在c＝1的情况下，一旦接收到CSSCI有效载荷，则它就保持有效直到接收到另一CSSCI有效载荷，如图9所示。可以使用有效载荷标识符(P)来检测CSSCI有效载荷的丢失；例如，时序位置有效载荷包含与listC中的任何CSSCI有效载荷不对应的P。按照这种方式，可以跨不同的AV呈现设备实现相同的用户体验。

在示例中，AV呈现设备180可以保持多于一个的接收到的CSSCI有效载荷列表。每个列表的大小可以不同并且可以使用不同规则集来保持(即在列表内添加或删除条目)。应该理解的是这并不排除列表的子集可以具有相同大小和/或相同保持规则这样的可能性。作为示例，可以存在由180所保持的两个列表，其中一个列表包含最近接收的CSSCI有效载荷“c1”，其中以“0”CSSCI有效载荷的间隔接收每个有效载荷；而另一列表包含最近接收的CSSCI有效载荷“c2”，其中以“d”CSSCI有效载荷的间隔接收每个有效载荷。

参考图10，修改的系统可以包括内容源100、水印插入器190、MVPD 130、广播接收设备160、以及AV呈现设备180及其具有水印能力的接收器310和水印客户端320。内容服务器400可以被修改为包括代码数据库370、元数据服务器350、以及内容和信令服务器380中的一个或多个。内容源100将代码300和元数据360提供给内容服务器400。将内容和信令数据提供给内容和信令服务器390。

AV呈现设备180可以根据来自音频-视频广播的解码的一个或多个水印在请求中提供代码。内容服务器400接收具有来自AV呈现设备180的代码的请求。此后元数据服务器350对所接收到的代码请求进行解析并且根据来自代码数据库370的信息，向内容和信令服务器390提出请求以确定此后提供给AV呈现设备180的内容和信令信息。按照这种方式，AV呈现设备180仅需要向内容服务器400提出单个请求，内容服务器400继而向AV呈现设备180提供响应。应当理解的是可以通过将现有功能组合在一起、将现有功能分成更多组件、省略组件、和/或任何其它技术来实现内容服务器400的不同功能。

当时间敏感触发D等于1时，可以将图5和图6中的HTTP或HTTPS请求URL(其将被发送到内容服务器400)定义为：

如果A等于0，则HTTP请求URL为：

HTTP://IIIIIIII.IIIIIIII.IIIIIIII.IIIIIIII/LLLLLLLLL？time＝TTTTTTTTTTTTTTTTTTTTTTTTT

否则，HTTPS请求URL为：

HTTPS://IIIIIIII.IIIIIIII.IIIIIIII.IIIIIIII/LLLLLLLLL？time＝TTTTTTTTTTTTTTTTTTTTTTTTT

其中上面的IIIIIIII.IIIIIIII.IIIIIIII.IIIIIIII与CSSCI有效载荷中的发信号通知的32比特IP地址相对应。

在示例中，以设计的有效载荷类型携带指定诸如内容服务器位置、通信协议、通信端口、登录信息、内容服务器上的文件夹的信息的URL子集。

在一些实施方式中，可以使用解码处理来导出语法元素的值，所述解码处理可以访问跨越多个有效载荷的信息。例如，可以将时间码分段成多个水印有效载荷并且此后对其进行重新组装以构造完整的时间码。在示例中，时间码可以与AV内容内的时序位置相对应。在示例中，时间码可以与AV内容的时间线数据相对应。

例如，有效载荷大小可以是50比特，而期望的元数据可以是66比特，因而超过了单个水印的有效载荷大小。期望的元数据的示例可以如下：

内容和服务器的位置(I)32比特(IP地址)

应用层协议(A)1比特(HTTP或HTTPS)

时间码(T)25比特(1年的唯一性，其中粒度为1秒)

时间敏感触发(D)1比特

信道标识(L)5比特

内容服务器请求的持续时间(R)2比特

期望的元数据的另一示例可以如下：

内容和服务器的位置(I)32比特(IP地址)

应用层协议(A)2比特(00＝HTTP，01＝HTTPS，10＝保留，11＝保留)

时间码(T)25比特(1年的唯一性，其中粒度为1秒)

时间敏感触发(D)1比特

信道标识(L)5比特

内容服务器请求的持续时间(R)2比特

参考图11，状态转换图说明了一种计算时间码的技术。为了获得时间码同步，以有效载荷类型“start sync”开始的多个连续有效载荷之后是类型为“not start sync”的有效载荷，其总数等于“r”。通过使用每一个都具有包含在其中的一些时间信息的总共“r”个连续有效载荷，可以通过计算锚点时间来确定时间同步。在计算了锚点时间码之后，可以通过按照接收其中包括部分时间码信息的附加有效载荷，以不需要接收另外总共“r”个连续有效载荷以确定下一个时间码的方式来更新时间码。实现该时间同步的一种技术是在连续有效载荷中划分时间码并在每个连续有效载荷中划分增量时间码。当同步丢失时，诸如通过改变信道，执行获得同步处理。首次初始化或打开时的视频显示设备进入初始获得同步状态。

参考图12，说明了水印有效载荷的示例性结构。Z指示有效载荷类型，其中Z等于1指示开始时间同步，并且Z等于0指示不开始时间同步。S指示在确定绝对时间码中所使用的时间同步有效载荷比特。M指示出在保持时间码中所使用的时间同步有效载荷比特。

举例来说，AV呈现设备180可以接收n＝7个连续水印有效载荷，其中第一有效载荷具有Z＝1而其余的具有Z＝0。从第(t-n+1)至第t水印有效载荷提取与“SSSS”相对应的比特并使其级连在一起以获得对时序位置的时间码“T_t”的28比特表示。还将锚点时间码“C_t”设置为“T_t”。“T_t”可以被表示为SSSS_{z＝1，t-n+1}…SSSS_z＝0，t-1SSSS_z＝0，t，“C_t”＝“T_t”。在另一示例中，可以添加(以选择未来时间)和/或乘以(以改变粒度)常数到导出值。在示例中，通过使用映射函数将导出值映射到另一值。

一旦获得初始化同步，则使用每个有效载荷来更新锚点时间和有效载荷时间。例如，这可以如下执行：

T_t＝f(C_t-1，MMMMt)

C_t＝g(T_t)

其中，f表示将两个值作为输入并输出一个值的映射函数；g表示将一个值作为输入并输出一个值的映射函数；/表示结果截断趋向于零的整数除法。例如，7/4和-7/-4被截断为1，并且-7/4和7/-4被截断为-1。在示例中：

T_t＝C_t-1+MMMM_I

C_t＝T_t

如上所述，每“n”个有效载荷，还可以使用与“SSSS”相对应的比特来确定锚点时间。使用“SSSS”所确定的锚点时间可以与上面的锚点时间求导相匹配并且能够用于验证所保持的时间码的正确性。

因为水印可以跨越非零时间，因此时间码T_t的时序位置可以由规则集合来确定，诸如例如T_t可以对应于第t个水印有效载荷末端时的时刻。

应该理解的是可以对多个语法元素进行组合以形成代码。此后该代码可以由AV呈现设备180或者使用另一服务器映射到不同的语法元素值。例如，将服务器信息(例如内容和信令服务器的位置和/或应用层协议等)和时间码组合成单个代码。此后将该单个代码映射到未压缩音频-视频流中的时序位置以及内容和信令服务器的位置。按照这种方式，可以向服务器提出对附加信息的单个请求。

按照允许时间码中的冲突的方式，有限数量的比特可以用于时间码。例如，对时间码使用20比特允许粒度为1秒的最多12天的唯一性。在12天之后，与时间码相对应的代码空间将被重用，这往往导致冲突。

在示例中，可以使用一个或多个cmdID将水印有效载荷封装在SDO私有数据命令内以作为SDO有效载荷。作为示例，可以将图5或图6的水印有效载荷封装为SDO有效载荷。cmdID值0x05可以指基于水印的交互服务触发或触发的声明对象(TDO)模型。cmdID值0x06可以指基于水印的交互服务触发(直接执行模型)。这有助于重复使用为触发传输所构建的现有分段和重组模块。如果需要，可以将分段命令嵌入在水印中。诸如图13中所说明的，包含数据包以作为SDO_payload()的一部分的SDO私有数据可能是期望的。在一些示例中，可以将按照这种方式所接收到的水印有效载荷传递到接收器中的对这些定义的cmdID类型进行处理的实体或模块。此后如果水印有效负载数据包需要被拆分为多个数据包，则可以重用该模块的分段和重组功能-这取决于就比特数量而言所选水印方案的容量。

参数类型T是2比特字段，该字段指示SDO私有数据或者SDOP rivateData命令的实例是否是分段可变长度命令的一部分，并且如果是，则该实例是分段可变长度命令的第一部分、中间部分、还是最后部分。在一个示例中，SDOPrivateData由“CEA：“DigitalTelevision(DTV)Closed Captioning(CEA：“数字电视(DTV)隐藏式字幕”)，CEA-708-E，消费者电子协会，2013年6月(CEA-708)的第7.1.11.2节定义，并且如在CEA-708第7.1.11.2节中所指定的，对SDO私有数据命令中的类型字段进行编码。pr是一个标记，该标记当被设置为‘1’时指示出该命令的内容被断言为与节目有关。当标志被设置为‘0’时，命令的内容不会如此断言。长度(L)是无符号整数，该无符号整数指示出报头后面的范围为2到27字节数并且在SDO私有数据命令中被表示为比特L₄到L₀的集合，其中L₄是最重要的并且L₀是最不重要的。cmdID是标识已定义要遵循的SDO_payload()数据结构的语法和语义SDO的信号。在示例中，cmdID是8比特字段。可以使用如图14所示的一个或多个cmdID将元数据封装在SDO私有数据内以作为SDO有效载荷。

可以使用一个或多个cmdID将在图5和图6中所定义的有效载荷封装在SDO私有数据命令内以作为SDO有效载荷。cmdID值0x05和0x06可以分别指对在图5和图6中所定义的有效载荷的封装。这有助于重复使用为触发传输而构建的现有分段和重组模块。如果需要，可以将分段命令嵌入在水印中。诸如图13中所说明的，包含有效载荷数据包以作为SDO_payload()的一部分的SDO私有数据可能是期望的。

可以使用一个或多个cmdID将在图12中所定义的有效载荷封装在SDO私有数据命令内以作为SDO有效载荷。cmdID值0x05可以指对在图12中所定义的有效载荷的封装。这有助于重复使用为触发传输而构建的现有分段和重组模块。如果需要，可以将分段命令嵌入在水印中。诸如图13中所说明的，包含数据包以作为SDO_payload()的一部分的SDO私有数据可能是期望的。

接下来对水印相关信息检索系统的示例进行描述。

该系统由水印检测器、AV呈现设备、水印信息服务器组成。在一个示例中，水印检测器可以驻留在AV呈现设备内。在一个示例中，AV呈现设备可以是AV呈现设备180。在一个示例中，水印信息服务器可以是增强服务信息提供服务器140。

在一个示例中，水印检测器可以对水印进行检测和解码。水印可以是音频水印。水印检测器和/或AV呈现设备可以使用水印中的信息来标识嵌入水印的媒体内容的时间线位置和/或可被级连以获得与水印相关联的进一步信息的服务器的地址(例如IP地址)。在示例中，这可能是必需的，因为水印有效载荷容量可能仅为几比特。例如，在1秒或1.5秒或2秒的时间段内容量可以是50比特。在这种情况下，AV呈现设备可以联系水印信息服务器以获得与当前媒体的当前时间线位置有关的更多信息。水印服务器可以发送“水印相关信息”作为对该请求的响应。

JavaScript对象表示法(JSON)是数据交换格式。

JSON模式定义了基于JSON的格式，该格式用于定义JSON数据的结构。JSON模式旨在定义对JSON数据的验证、文档编制、超链接导航、以及交互控制。

对象是零个或多个名称与值对的无序集合，其中名称是字符串并且值是字符串、数字、布尔值、空值、对象、或数组。

JSON模式是JSON文档，该JSON文档可以是对象。将由JSON模式所定义的对象属性称为关键字或模式关键字。

JSON模式可能包含不是模式关键字的属性。

JSON值可以是对象、数组、数字、字符串，或者false(假)、null(空)、或true(真)之一。

可以在本文档中互换地使用术语元素、键、关键字、以及名称。术语键可以用于指代对象在本文档中的名称。

可以在本文档中互换地使用术语恢复文件格式和恢复数据表。

图15示出了水印相关信息的示例性JSON模式。就图15而言应注意以下内容。

可以使用JSON，以代替使用XML来表示所检索到的水印相关信息。在这种情况下，代替使用元素(例如XML元素)和属性(XML属性)，JSON对象与其属性一起使用。

娱乐标识符寄存器(EIDR)是电影和电视资产的通用标识符系统。从顶级标题、编辑、以及DVD到编码、剪辑、以及混搭，EIDR为与娱乐商务有关的整个范围的视听对象类型提供全局标识符。在HTTP://eidr.org/documents/EIDR_ID_Format_v1.2.pdf描述了EIDR格式并且通过参考并入本文。可以使用EIDR标识符格式的后续版本。

还可以称为Ad-ID的广告标识符(AD-ID)是用于标识跨媒体平台的广告资产的行业标准。Ad-ID代码结构如在HTTP://www.Ad-ID.org/how-it-works/Ad-ID-structure中所示，并且通过参考并入本文。

参考图15，在JSON模式中定义了基于正则表达式的语法，以在ContentID事件中包含EIDR和Ad-ID信息。与使用字符串相反，这种形式语法强制对EIDR和Ad-ID只能发信号通知有效值。

这在下面的从图15的JSON模式的所提取的部分中进行了说明：

在使用基于正则表达式“范式”的模式中，包括作为内容标识符值(CID)的值、或者ContentID、EIDR类型的键的字符串在设计上总是有效的EIDR字符串。在使用基于正则表达式的范式的模式中，所包括的用于AD-ID类型的CID键的字符串在设计上总是有效的Ad-ID字符串。作为结果，无法在JSON数据中从水印服务器发送无效的EIDR和Ad-ID字符串。

进一步就图15而言，为ContentID类型定义枚举数据类型而不是通用字符串。这将值限制为仅有效值。作为结果，无法为ContentID类型定义无效值。这可以在使用“enum”：[“EIDR”]和“enum”：[“AD-ID”]值中看到，这些值是为图15中的模式中的ContentID对象内的相应的Type(或类型)字符串所定义的。作为结果，可以定义并返回无效的ContentID类型值。

进一步就图15而言，为由图15中的触发键所表示的触发事件定义扩展机制以在将来返回除当前定义的URI类型以外的一个或多个通用资源指示符(URI)事件类型。使用设计的前缀来定义扩展的URI类型。这在下面的从图15中的JSON模式的所提取的部分中说明。在示例中，JSON模式包括应用程序信息表(AIT)、媒体呈现描述(MPD)、和/或电子服务指南(ESG)值。

可以看出将诸如AIT、MPD、以及ESG的触发类型定义为有效的字符串值。这由UriType字符串的“enum”：[“AIT”，“MPD”，“ESG”]表示。将来可以定义其它有效的触发类型。这是通过允许对UriType使用其它字符串值来实现的。在示例中，这些字符串可以以EXT前缀开始。如下通过对UriType字符串使用“oneOf”约束来定义此行为：

将上面定义的前缀表示为EXT，这意味着扩展UriType可以以字符EXT开始。可以改为使用其它字符。例如，可以使用字符串FUT、NEXT、或任何其它合适字符串以代替EXT。

在示例中，可以允许将来的UriType是任何有效的字符串，在这种情况下，可以将模式的相关部分定义为：

在另一示例中，支持图15和图16A-D中所示的模式的附加整体扩展以用于将来的可扩展性。在另一示例中，为了允许将来的可扩展性，可以使用additionalProperties：true的键/值对来定义JSON模式。

例如，JSON模式的最后4行可以替换为以下：

这允许在返回的JSON数据内定义具有属性的其它对象和类型。

图16A-D示出了用于水印相关信息检索的JSON模式的逻辑结构。图16A-D的结构与图15的JSON模式相对应。然而，逻辑结构的某些或部分可以用变体JSON模式来表现。

在示例中，经由在图15和/或图16A-D中所说明的JSON模式从水印服务器所返回的水印相关信息可以是恢复文件格式。

在另一示例中，代替使用JSON来表示从水印服务器所返回的水印相关信息，可以使用XML格式。接下来描述从水印服务器返回XML格式数据及与所定义的XML模式的一致性的若干增强和方法。

在示例中，对使用XML的基于范式的语法进行定义用于在ContentID事件中包含的EIDR和Ad-ID信息中的一个或多个。与使用通用xs:String数据类型相反，该形式语法强制对EIDR和AD-ID仅发信号通知有效值。

在示例中，用于EIDR信息包含的XML模式是：

在示例中，用于Ad-ID信息包含的XML模式是：

用于EIDR或Ad-ID包含的组合的XML模式如下所示：

在另一示例中，对ContentID的类型或ContentIDType定义枚举数据类型，以代替通用字符串。这将值限制为仅有效值。

在示例中，用于此的XML模式是：

用于包含约束类型和contentID属性的ContentID事件的整体XML模式如下所示：

接下来描述使用XML模式的另一示例。

上述XML模式定义允许定义类型等于Ad-ID但是为EIDR标识符所定义的ContentID值的ContentID事件。

类似地，上述XML模式定义允许定义类型等于EIDR但是为Ad-ID标识符所定义的ContentID值的ContentID事件。

为了防止这种定义，XML模式可以定义如下。

当ContentID事件具有等于Ad-ID的类型时，该XML模式严格地强制ContentID值只能是有效Ad-ID标识符值。此外，当ContentID事件具有等于EIDR的类型时，XML模式强制ContentID值只能是有效EIDR标识符值。

将查询展开属性的基数从0..N修改为0..1。发信号通知多个查询展开值可能导致混淆接收器行为，因而最多只发信号通知1个查询展开值。

在示例中，用于此的XML模式是：

为将来的扩展定义了扩展元素。定义类型“RecoveryExtType”的RecoveryExt元素以允许定义水印相关信息的专有扩展。

在示例中，可以为此定义以下XML模式。

如下可以将扩展元素定义为整个根元素的子元素或者在整个XML模式中的任何其它合适位置：

<xs：element name＝″RecoveryExt″type＝″RecoveryExtType″minOccurs＝″0″/>

在示例中，扩展元素RecoveryExtType的XML数据类型是：

现在对JSON模式描述其它示例以使模式可扩展。

在图17中示出了用于水印相关信息检索的附加JSON模式。在该模式中，为了可扩展性包括了对JSON模式可扩展性的支持。

在图17中的JSON模式中，与图15中的JSON模式相比，为了可扩展性包含以下：

(1)定义了诸如RecoveryFF这样的顶级键并且将图17中的当前恢复文件格式模式定义为该顶级键的对象。因而，可以将图15中的模式包裹在顶级键内。这通过使用JSON模式的“allOf”和“$ref”关键字来允许当前恢复文件格式的可扩展性。

在HTTP://tools.ietf.org/html/draft-fge-json-Schema-validation-00中定义了JSON关键字“allOf”，其通过参考并入本文。在示例中，“allOf”定义了给定数据可能对于关键字值所定义的所有模式是有效的。在示例中，为了验证“allOf”，给定数据可能对于该关键字的值所定义的所有模式是有效的。

可以使用$ref关键字指模式的一部分。$ref在逻辑上被它所指向的模式部分替换。

(2)键是唯一的。因而即使它们属于不同对象，也没有一个键具有相同的键名称。这有利于可扩展性。

进行扩展的一个示例是当定义了第二版本的恢复文件格式时。在这种情况下，可以将新的键和值对添加到模式，同时保持旧的键值对以用于与图17中的模式向后兼容。

当扩展图17中的JSON模式时，可以定义以下类型的新键：

在示例中，新键是“RecoveryFFV2”键。

在这种情况下，使用allOf关键字，数据可能对于所有给定的模式是有效的。

包含在allOf关键字内的第一模式是{“$ref”：“#/RecoveryFF”}，其是指如图17所示的恢复文件格式的第一版本的模式。此后恢复文件格式的第二版本的模式的新的键和值包括为：

因而恢复文件格式的第二版本的整体示例模式如图18所示。

下面说明了用于提供可扩展模式的第二示例。在该示例中，通过包含@context关键字来定义基于链接数据的JSON(JSON-LD)的扩展机制。JSON-LD是用于使链接数据序列化的格式。将JSON-LD语法设计成集成到已使用JSON的系统中并提供从JSON到JSON-LD的升级路径。JSON-LD主要旨在是在基于Web的编程环境中使用链接数据、构建可互操作的Web服务、并且在基于JSON的存储引擎中存储链接数据的方式。链接数据是跨不同文档和网站创建基于标准的机器可解释数据的网络的方式。它允许应用程序开始于一段链接数据并且跟随链接到托管在不同站点上的其它链接数据段的嵌入链接。

图19示出了用于水印相关信息检索的JSON模式的示例。

在图19中的JSON模式中，与图15中的JSON模式相比，为了可扩展性，增加以下：

(1)键(@context)被定义并且图19中的当前恢复文件格式模式被包括为键(@context)内的“RecoveryFF”:HTTP：//www.atsc.org/contexts/3.0/RecoveryFF。此后将该模式包裹在键“RecoveryFF”内。

(2)键是唯一的，因为键不具有相同的键名，即使它们位于不同的对象之下。这有利于可扩展性。

能够扩展的一个示例是定义恢复文件格式的第二版本。在该示例中，新的键和值对将被添加到模式，同时保持旧的键值对以用于与图19中的模式向后兼容。

当能够对图19中的JSON模式扩展时，对于新的键和值对可包括@contex：

在这种情况下新的键是“RecoveryFF2”。

新的键“RecoveryFF2”的新“@context”是

"RecoveryFF2":"HTTP://www.atsc.org/contexts/3.1/RecoveryFF"

在示例中，恢复文件格式的第二版本的模式的新的键和值是：

在图20中示出了恢复文件格式的第二版本的整体示例性模式。

在示例中，当进行扩展时，定义恢复文件格式的第二版本，对于旧的和新的键和值可以仅包括如下新的@context。

在该示例中，恢复文件格式的第二版本的新的键和值是：

″newkeyA″：″valueA″，

″newkeyB″：″valueB″，

其可以包括有图19中的先前版本的模式中的其它键和值。

因而，在该示例中，通过改变“@context”内的“RecoveryFF”键的值，如图21所示可以将新的和旧的键和值包含在一起。

因而恢复文件格式的整体模式如图21所示。

现在为恢复文件格式结构提供替代示例。

在图22中示出了恢复文件格式表的替代逻辑结构。在图23中示出了组件描述的逻辑结构。在图24A、图24B、以及图24C中示出了组件锚点的三种不同逻辑结构。参考图22，各种元素的语义如下所述。

ThisComponent-嵌入有水印的媒体组件的描述。

serverCode–当存在时，该元素可以提供在下述HTTP请求中所采用的serverCode值，恢复文件作为响应被提供给该HTTP请求。

intervalCode-当存在时，该元素可以提供来自查询请求的intervalCode值，恢复数据表作为响应被提供给该查询请求。

ComponentDescription–描述在图23中所定义的格式中的ThisComponent的数据元素。

querySpread-当存在时，该元素可以表示建议接收器延迟提交HTTP请求的最大持续时间。

OtherComponent–描述与和在图23中所定义的格式中的ThisComponent相同的服务相关联的另一加水印的媒体组件的元素。

ContentID-该字段可以标识内容标识符。

代替使用ContentID List容器对象，ContentID对象的数组被定义为有效基数是0..N而不是1..N(即在数组中0到N个条目)。这通过不需要增加了解析复杂性的容器对象而使整体数据结构简单化并且允许更容易地解析JSON数据，同时仍保持期望的灵活性。

ContentID.type–当包括ContentId元素时优选需要的字段。可以定义两个值：

“EIDR”指示出每个EIDR注册表的内容标识。

“Ad-ID”指示出每个Ad-ID注册表的内容标识符。

ContentID.cid–当包括提供内容标识的ContentId元素时所使用的字段。内容标识符的类型可以如ContentID.type属性中所给出的。可包括EIDR(具有连字符的34个字符规范形式)或Ad-ID(11或12个字符规范形式)。

ContentID.validFrom–提供与ContentId自何时起有效有关的信息的字段。

ContentID.validUntil-提供与ContentId直至何时有效有关的信息的字段。

SourceID–描述采用ATSC发射规范的分发源的元素。该元素适用于加水印的内容被包括在根据ATSC发射规范广播的服务的再分发中的情况。

country–与主要管理实体相关联的国家代码，在所述主要管理实体下使用如在ISO 3166-1中所定义的适用的alpha-2国家代码格式来分配在bsid中所提供的值。通过参考将http://webstore.ansi.org/RecordDetail.aspx？sku＝ISO％203166-1:2013上可获得的ISO 3166-1并入本文。bsid-ATSC分发源的广播服务标识符(BSID)。

majorChannelNo-分配给ATSC分发源的主要信道号。该值的范围限定为BSID。

minorChannelNo-分配给ATSC分发源的次要信道号。该值的范围限定为BSID。

Service–该元素描述服务、其信令格式、以及宽带位置。

serviceId-可以在该广播区域范围内唯一标识该Service的16比特整数。

sltSvcSeqNum–该整数可以指示出服务标识符等于上面的serviceId属性的服务信息的序列号。每个服务的sltSvcSeqNum值可以从0开始并且每当该Service元素的任何属性或子元素改变时，sltSvcSeqNum值可以递增1。如果与具有特定值的serviceID的先前Service元素相比没有属性或子元素值改变，则sltSvcSeqNum可能不会递增。sltSvcSeqNum字段可在达到最大值后回绕到0。

slsProtocol-指定与该服务相关联的信令格式。

slsMajorProtcolVersion–在slsProtocol中所指定的信令协议的主要版本号。

slsMinorProtocolVersion–在slsProtocol中所指定的信令协议的次要版本号。

svcInetUrl-提供与URL有关的信息，如果可获得，以经由宽带访问该服务的ESG或服务级信令文件。

URLtype-svcInetUrl可获得的文件类型。

URLValue–用于访问serviceidentifier serviceId所标识的该服务的因特网信令文件的URL。

URL值属性(URLValue)被定义用于指示出包含的对象内的服务因特网URL值，该包含的对象包含与服务因特网URL有关的属性。URLtype可能是服务因特网URL的必需属性(而不是可选属性)，因为否则将不知道发信号通知什么类型的URL。

参考图23，各个元素的语义如下所述。

ComponentDescription-提供对与服务相关联的加水印媒体组件的描述。

ComponentAnchor–与如在图24A或图24B或图24C所定义的加水印媒体组件中的第一有效载荷有关的信息。

mediaType-字符串，该字符串具有用于指示出描述仅适用于音频组件的值“audio”、用于指示出描述仅适用于视频组件的值“video”、以及用于指示出描述适用于音频组件和视频组件的值“both”。

descriptor-与由应用程序消费的加水印媒体组件相关联的任意描述性字符串。

priority-指示出所述组件的相对优先级的数值。如果没有为组件指示优先级值，则其优先级可以为0。

参考图24A，各个元素的语义如下所述。

ComponentAnchor–指定视频或音频水印段中的第一有效载荷的特征的元素。

intervalCodeAnchor-视频或音频水印段中的第一有效载荷中的intervalCode。

PresentationTime-视频水印段中的第一消息块的第一帧的挂钟呈现时间，或者对于音频组件，音频水印段的第一单元中的第一符号的第一样本的挂钟呈现时间。

具有图22、图23、图24A中所示的逻辑结构的恢复文件格式的JSON模式如下图25A-D所示。

就JSON模式而言，在替代示例中，可以用除类型“string”之外的数据类型来发信号通知presentationTime。例如，可以使用类型“number”。

在这种情况下参考图24，相应JSON模式部分如下：

“presentationTime”：{“type”：“number”}而不是“presentationTime”：{“type”：“string”}

在替代示例中，可以用除字符串“string”之外的数据类型来发信号通知presentationTime。例如，可以使用“integer”类型。

在这种情况下参考图24，相应JSON模式部分如下：

“presentationTime”：{“type”：“integer”}而不是“presentationTime”：{“type”：“string”}

就恢复文件格式逻辑结构而言，在替代示例中，可以在容器SourceID元素内使用父元素ATSCSourceID和备选选择。这可以允许在将来定义除ATSC之外的源标识符。恢复文件格式逻辑结构的这部分可能如下所示。

在这种情况下，SourceID和ATSCSourceID的语义可能如下：

SourceID–描述加水印内容所属的分发源的元素。

ATSCSourceID–描述采用ATSC发射规范的分发源的元素。该元素适用于加水印内容被包括在根据ATSC发射规范广播的服务的再分发之中的情况。

在这种情况下，与此相对应的JSON模式部分可能如下所示。

在图24B中示出了组件锚点的替代示例性逻辑结构。图24B与图24A之间的主要区别是代替定义了单个presentationTime元素或键或属性来表示呈现时间，而是定义了两个元素或键或属性presentationTime和presentationTimeMsec。

参考图24B，各个元素的语义如下所述。

PresentationTimeInteger-视频水印段中的第一消息块的第一帧的64比特网络时间协议(NTP)格式化挂钟呈现时间中的整数部分-前32比特，或者，对于音频组件而言，音频水印段的第一单元中的第一符号的第一样本的挂钟呈现时间。

PresentationTimeFraction-视频水印段中的第一消息块的第一帧的64比特NTP格式挂钟呈现时间的小数部分-后32比特，或者，对于音频组件而言，音频水印段的第一单元中的第一符号的第一样本的挂钟呈现时间。在该32比特小数部分中，可以将非重要低位比特设置为0。

具有图22、图23、图24B所示的逻辑结构的恢复文件格式的JSON模式如图26A-D所示。

在图24C中示出了组件锚点的替代示例性逻辑结构。图24C与图24A之间的主要区别是代替定义了单个presentationTime元素或键或属性来表示呈现时间，而是定义了两个元素或键或属性presentationTime和presentationTimeMsec。

参考图24C，各个元素的语义如下所述。

PresentationTime-该32比特无符号整数可以指示出视频水印段中的第一消息块的第一帧的呈现时间，或者对于音频组件而言，可以指示为对自从1970年1月1日00:00:00，国际原子时(TAI)以来的秒数的计数的最低有效32比特。

PresentationTimeMsec-范围在0到999中的该10位无符号整数可以指示与从在PresentationTime中所指示出的时间的毫秒偏移量，以便公式PresentationTime+(PresentationTimeMsec/1000)产生视频水印段中的第一消息块的第一帧的实际呈现时间，或者，对于音频组件而言，至最接近的1毫秒。(PresentationTimeMsec/1000)是指PresentationTimeMsec除以1000。

具有图22、图23、图24C所示的逻辑结构的恢复文件格式的JSON模式如图27A-D所示。

在图28中示出了恢复文件格式表的替代逻辑结构。在图29中示出了组件描述的逻辑结构。在图30中示出了组件锚点的逻辑结构。图31说明了图28的恢复文件格式的示例性slsProtocol值。图32说明了图28的恢复文件格式的示例性urlType值。

参考图248，各个元素的语义如下所述。

thisComponent–对嵌入有包含VP1有效载荷的水印的媒体组件的描述，该VP1有效载荷包含serverCode和intervalCode。VP1有效载荷是50比特音频水印有效载荷数据的特定排列。

serverCode–当存在时，该元素可以提供在HTTP请求中所使用的serverCode值，恢复文件作为响应被提供给该HTTP请求。

intervalCode-当存在时，该元素可以提供来自查询请求的intervalCode值，恢复数据表作为响应被提供给所述查询请求。

componentDescription–描述以图29中所定义的格式的thisComponent以及随后的参数说明的数据元素。

querySpread-当存在时，该元素可以表示建议接收器延迟提交动态事件HTTP请求的最大持续时间，以1毫秒为单位。期望接收器将应用足够小的粒度级别以在诸如1毫秒的querySpread持续时间内实现均匀的查询展开。

otherComponent–描述以和图25A-D中所定义的格式的thisComponent相同的服务相关联的另一个加水印媒体组件及随后的参数描述的元素。

contentID-该字段可以标识内容标识符。

contentID.type-Content ID的Content ID系统的类型。目前ATSC定义了三个值：

“EIDR”指示出如在(http://eidr.org)中所定义的每个EIDR注册表的内容标识。

“Ad-ID”指示出如在(http://ad-id.org)中所定义的每个Ad-ID注册表的内容标识符。

“UserPriv”指示出用户私有内容标识符

在将来ATSC可能会定义另外的Content ID系统类型。

对于“UserPriv”内容标识符，应当注意的是contentID.cid在此广播流中出现的Content ID系统类型当中是唯一的。

contentID.type的替代语义可能如下：

用于该Content ID的Content ID系统类型。例如，ATSC可以定义两个值：

“EIDR”指示出每个EIDR注册表(http://eidr.org)的内容标识。

“Ad-ID”指示出每个Ad-ID注册表(http://ad-id.org)的内容标识符。

可定义用户私有内容标识符的附加类型。这些可以使用前缀“x-”来指示用户私有内容标识符类型。

ATSC可以定义另外的Content ID系统类型。

对于用户私有内容标识符类型，这种系统的contentID.type优选地不重复ATSC所定义的任何Content ID系统类型并且在广播流中出现的Content ID系统类型当中是唯一的。

应当注意的是可以使用任何其它指定的前缀，代替要求使用“x-”作为用户私有内容标识符的前缀。例如，可以指定使用前缀“UserPriv-”。

此外代替“用户私有内容标识符”可以使用术语“私有使用内容标识符”。

contentID.cid–当包含用于提供内容标识的contentID元素时所需的字段。在EIDR Content ID系统的情况下，这可以是标识符的34字符规范形式(带有连字符)。在Ad-ID Content ID系统的情况下，这可以是标识符的11个字符或12个字符的规范形式。在UserPriv Content ID系统(例如房屋号码(House Number)、ISCI等)的情况下，由系统的规范来确定标识符的格式。

房屋号码可以包括广播者特定的私有内容标识符。例如，广播公司A可以使用他们的私有内容标识符作为他们的私有房屋号码，并且广播公司B可以使用他们的私有内容标识符作为他们的私有房屋号码。

行业标准编码识别(ISCI)是被创建为标识从1970年至2004年在美国为广告代理商和广告商在电视上所播出的商业广告的标准。它在2005年被Ad-ID替换。

contentID.value的替代语义可以如下：

contentID.cid–当包括提供内容标识的contentID元素时所使用的字段。在EIDRContent ID系统的情况下，这可以是标识符的34字符的规范形式(带有连字符)。在Ad-IDContent ID系统的情况下，这可以是标识符的11个字符或12个字符的规范形式。在用户定义的Content ID类型(对于contentID.type具有前缀“x-”)或任何其它ATSC私有ContentID系统(例如房屋号码)的情况下，可以由系统的规范来确定标识符的格式。

contentID.validFrom-contentID值的有效的间隔的开始时间。

contentID.validUntil-contentID值的有效的间隔的结束时间。

SourceID–描述采用ATSC发射规范的分发源的元素。该元素适用于加水印内容被包括在根据ATSC发射规范的广播的服务的再分发之中的情况。

country–与主要管理实体相关联的国家代码，在该主要管理实体下使用如在ISO3166-1中所定义的适用的alpha-2国家代码格式来分配在bsid中所提供的值。ISO 3166-1在ISO：ISO 3166-1：2013(E/F)，“Codes for the representation of names ofcountries and their subdivisions-Part 1:Country codes”，国际标准化组织，第3版，11/13/2013中定义并且通过参考整体并入不本文。

bsid–可归属ATSC分发源的BSID。

majorChannelNo-分配给可归属ATSC分发源的主要信道号。该值的范围限定为BSID。

minorChannelNo-分配给可归属ATSC分发源的次要信道号。该值的范围限定为BSID。

service–该元素描述服务、其信令格式、以及宽带位置。

serviceId-可以在该广播区域范围内唯一标识该服务的16比特整数。

sltSvcSeqNum–该整数可以指示服务ID等于上面的serviceId属性的服务列表(SLT)服务信息的序列号。对于每个服务，sltSvcSeqNum值可以0开始，并且每当该服务元素的任何属性或子元素改变时可以递增1。如果与具有特定值的serviceID的先前服务元素相比没有属性或子元素值改变，则sltSvcSeqNum可能不会递增。sltSvcSeqNum字段可在达到最大值后回绕到0。

SLT是信令信息表，该信令信息表用于构建基本服务列表并提供对对信令的发现，该信令提供用于获取ATSC 3.0服务及其内容组件的信息。

slsProtocol-指定与该服务相关联的信令格式，具有图31所示的允许值及其含义。

svcInetUrl-如果可获得，经由宽带来访问该服务的电子服务指南(ESG)或服务级信令文件的基本URL。

urlType-svcInetUrl可获得的文件类型，具有如图32所示的允许值及其含义。

urlValue-用于访问由服务标识符serviceId所标识的该服务的因特网信令文件的URL。

具有图28中所示的逻辑结构的恢复文件格式的示例性JSON模式如图33A-E所示。

具有图28中所示的逻辑结构的恢复文件格式的另一示例性JSON模式如图34A-D所示。

具有图28中所示的逻辑结构的恢复文件格式的另一示例性JSON模式如图35A-E所示。

图35A-E中的模式允许任何“string”数据类型值被用于情况之一中的“type”字段。这允许定义另外的ATSC定义的内容ID类型以及用户私有内容ID类型。

在又一示例中，通过将如下定义数据类型可以在模式中强制与对用户私有内容标识符使用前缀“x-”有关的要求：

图33A-E和图34中的JSON模式之间的区别涉及contentID.type和contentID.cid属性的语义区别。对于图34A-D中的模式，属性contentID.type和contentID.cid的语义可能如下：

contentID.type-用于该Content ID的Content ID系统的类型。目前由ATSC定义以下值：

在将来ATSC可能会定义其它Content ID系统类型。

可以使用(或可以在此处出现)用户定义的Content ID系统类型的合适缩写。当此完成时，应注意的是该缩写在此广播流中出现的Content ID系统类型当中是唯一的。

contentID.cid-Content ID值。在EIDR Content ID系统的情况下，这可以是标识符的34字符规范形式。在Ad-ID Content ID系统的情况下，这可以是标识符的11个字符或12个字符的形式。在用户私有内容ID系统(例如房屋号码、ISCI等)的情况下，标识符的格式是由系统的规范来确定的。

图33A-E和图34A-D中的JSON模式包括以下以作为对象contentID的模式的一部分：

其中“...”指示出如图33A-E和图34A-D所示的在这里被省略的不同JSON模式部分。

在这种情况下，包括{“type”：“object”}作为模式的一部分提供了将来的可扩展性。包含{“type”：“object”}作为contentID对象的模式的一部分除了其必须遵守EIDR或AD-ID或“userPriv模式属性的contentID的特定定义的约束模式语法之外，还允许contentID对象的自由形式的JSON对象。在将来可定义此对象的语法。因而这支持将来的可扩展性。在这种情况下，当前版本的接收器可跳过通用JSON对象。此外在另一使用示例中，在contentID对象内包括{“type”：“object”}的图34A-D中的模式可用作包括任何不同私有内容id值的另一方式。

图36说明了示例性恢复文件格式逻辑结构。图28与图36之间的一个区别在于支持紧凑的Ad-ID格式。按照这种格式，可以将Ad-ID表示为ASCII字符，该ASCII字符表示4字节无符号整数紧凑Ad-ID标识符的十进制值。

具有图36中所示的逻辑结构的恢复文件格式的另一示例性JSON模式如图37A-E所示。

图37A-E中的模式允许Ad-ID类型的内容标识符的附加范式条目，其允许将Ad-ID表示为ASCII字符，该ASCII字符表示4字节无符号整数紧凑Ad-ID的十进制值。在示例中，这是通过定义通过对每个单独范式执行逻辑OR运算而创建的范式来实现的。在一个示例中，该模式的这部分可以如下所示。

具有图36中所示的逻辑结构的恢复文件格式的另一示例性JSON模式如图38A-J所示。

在这种情况下，图36中的一些语法元素的语义可以修改如下：

contentID.type–当包括contentId元素时所需的字段。目前定义了两个值：

-“urn：eidr”指示出每个EIDR注册表(http://eidr.org)的内容标识。

-“Designator”，用于在SMPTE 2092-1中所定义的“完整”或“紧凑”编码的“Designator”指示出每个Ad-ID注册表(http://ad-id.org)的内容标识符。SMPTE：Societyof Motion Picture and Television Engineers(电影和电视工程师协会)在2015年出版的“Advertising Digital Identifier(Ad-ID(Registered Trademark(广告数字标识符(Ad-ID(注册商标)))表示”，RP 2092-1，在本文档中被称为“SMPTE 2092-1”并且通过参考整体并入本文。

通过将该字段设置为如在IETF RFC 4151的第2.1节中所定义的taggingEntity令牌(例如“atsc.org，2016”)可使用用户私有内容标识符的另外类型。IETF RFC 4151从https://www.ietf.org/rfc/rfc4151.txt可获得，并且通过参考整体并入本文。

在将来ATSC可能会定义其它Content ID系统类型。

contentID.cid–当包括用于提供内容标识的contentId元素时所需的字段。在以下情况下：

-“urn：eidr”：EIDR内容ID系统，这应是如在SMPTE中所定义的标识符的34个字符规范形式(带有连字符)，SMPTE：电影和电视工程师协会(电影和电视工程师协会)在2013年出版的“Digital Object Identifier(DOI)Name and Entertainment ID Registry(EIDR)Identifier Representations(数字对象标识符(DOI)名称和娱乐ID注册表(EIDR)标识符表示)”，RP 2079-2013，其全部内容通过参考整体并入本文。

-“Designator”，用于在“SMPTE 2092-1”Ad-ID Content ID系统中所定义的“完整”或“紧凑”编码，这应为11个字符或12个字符的规范形式或者用于表示4字节无符号整数紧凑Ad-ID标识符的十进制值

-对于其它域名，该字段不是由ATSC定义。标识符的格式由系统规范来确定。

与图37A-E中的模式相比，图38A-J中的模式包括以下变化：

在图37A-E模式中，仅使用“ad-id.org，2016”的单个URN来发信号通知Ad-ID“类型”的“完整”和“紧凑”形式。与图38A-J中的此相比，两个单独的URN(一个用于完整并且另一个用于紧凑形式)用于两个“类型”。

在图37A-E模式中，用于单个“类型”的“cid”是两个可能的Ad-ID值(完整或紧凑)的逻辑OR(||)。与图38A-J中的此相比，Ad-ID值可仅用“完整”类型URN来发信号通知并且紧凑Ad-ID值可用“紧凑”类型URN来发信号通知。

此外在图38A-J模式中，与图37A-E模式相比，对于“紧凑”格式maxLength限制是变化的。这允许对“紧凑”格式值进行更有效地解析。

就图38A-J中的模式而言，应该注意的是可以使用一些其它URN值代替指定的URN值。特别是：

在图38A-J中代替“完整”Ad-ID的“urn:smpte:ul:060E2B34.01040101.01200900.00000000”，可以使用例如“urn:smpte:ul:060E2B34.0101010C.0101110B.00000000”的另一URN或例如“urn:smpte:ul:060e2b34.01040101.01100200.00000000”的另一URN或者一些其它URN或URI。

在图38A-J中代替“完整”Ad-ID的“urn:smpte:ul:060E2B34.01040101.01200900.00000000”，可以使用例如“urn:smpte:ul:060e2b34.01040101.01010300.00000000”的另一URN或例如“urn:smpte:ul:060E2B34.0101010E.0101110E.00000000”的另一URN或者一些其它URN或URI。

在参考图17、图18、图19、图20、图21、图25A-D、图26A-D、图27A-D、图27A-D、图28、图29、图29、图30、图31、图32的示例中，可以用additionalProperties：true来定义JSON模式的进一步可扩展性。在参考图17、图18、图19、图20、图21、图25A-D、图26A-D、图27A-D、图27A-D、图28、图29、图29、图30、图31、图32的防止模式变化的其它示例中，可以用additionalProperties：false来定义JSON模式的进一步可扩展性。

就各个JSON模式而言，在替代示例中，某些元素或键或属性的数据类型可以与模式中所指示出的不同。例如，可以使用数据类型“整数”或“数字”或“布尔”或“数组”或“对象”以代替数据类型“字符串”。类似地，可以替代地将任何其它JSON日期类型作为任何其它JSON数据类型来发信号通知。结合详细描述中的示例，预料到所有这些变化。

此外，在每个前述实施例中所使用的基站设备和终端设备的每个功能块或各种特性可以是由电路实现或执行的，该电路典型地是集成电路或多个集成电路。被设计成用于执行在本说明书中所述的功能的电路可以包括通用处理器、数字信号处理器(DSP)、专用集成电路(ASIC)或通用应用集成电路、现场可编程门阵列信号(FPGA)、或其它可编程逻辑设备、离散门或晶体管逻辑、或分立硬件组件、或其组合。通用处理器可以是微处理器，或者替代地，处理器可以是传统处理器、控制器、微控制器、或状态机。上述通用处理器或每个电路可以是由数字电路来配置的或者可以是由模拟电路来配置的。此外，当由于半导体技术的进步而出现了制成取代当前集成电路的集成电路的技术时，也能够使用通过该技术的集成电路。

应该理解的是权利要求不限于上面所说明的精确配置和组件。在不脱离权利要求的范围的情况下，可以对本文所述的系统、方法、以及装置的安排、操作、以及细节进行各种修改、改变、以及变化。

Claims

1.一种用于接收来自提供商的补充内容的方法，包括以下步骤：

(a)接收包括RecoveryDataTable元素的恢复文件格式的恢复数据表；

(b)接收所述RecoveryDataTable元素的contentID字段，所述contentID字段描述与在消息中所提供的内容标识符有关的信息；

(c)接收所述contentID字段的type字段，所述type字段描述内容标识符的类型并定义统一资源名；

(d)接收所述contentID字段的cid字段，所述cid字段描述广告标识符并且其中所述cid字段的最大长度为10；

(e)接收所述contentID字段的valid from字段，所述valid from字段描述内容标识符自何时起有效；

(f)接收所述contentID字段的valid until字段，所述valid until字段描述内容标识符直至何时有效；

(g)根据所述恢复数据表接收所述补充内容。

2.根据权利要求1所述的方法，其中，所述统一资源名是060E2B34.01040101.01012009.00000000。

3.根据权利要求1所述的方法，其中，所述统一资源名是060E2B34.01040101.01200900.00000000。

4.根据权利要求1所述的方法，其中，所述恢复数据表是符合javascript对象表示法(JSON)模式的javascript对象表示法(JSON)格式。

5.根据权利要求1所述的方法，其中，使用第一接口接收所述恢复文件格式，并且使用第二接口接收所述补充内容。

6.根据权利要求1所述的方法，其中，在所述接收之后再现所述补充内容。

7.一种用于接收来自提供商的补充内容的接收器，包括以下步骤：

(a)所述接收器接收包括RecoveryDataTable元素的恢复文件格式的恢复数据表；

(b)所述接收器接收所述RecoveryDataTable元素的contentID字段，所述contentID字段描述与在消息中所提供的内容标识符有关的信息；

(c)所述接收器接收所述contentID字段的type字段，所述type字段描述内容标识符的类型并定义统一资源名；

(d)所述接收器接收所述contentID字段的cid字段，所述cid字段描述广告标识符并且其中所述cid字段的最大长度为10；

(e)所述接收器接收所述contentID字段的valid from字段，所述valid from字段描述内容标识符自何时起有效；

(f)所述接收器接收所述contentID字段的valid until字段，所述valid until字段描述内容标识符直至何时有效；

(g)所述接收器根据所述恢复数据表接收补充内容。

8.根据权利要求7所述的接收器，其中，所述统一资源名是060E2B34.01040101.01012009.00000000。

9.根据权利要求7所述的接收器，其中，所述统一资源名是060E2B34.01040101.01200900.00000000。

10.根据权利要求7所述的接收器，其中，所述恢复数据表是符合javascript对象表示法(JSON)模式的javascript对象表示法(JSON)格式。

11.根据权利要求7所述的接收器，其中，使用第一接口接收所述恢复文件格式，并且使用第二接口接收所述补充内容。

12.根据权利要求7所述的接收器，其中，在所述接收之后再现所述补充内容。