CN108293148A

CN108293148A - 接收装置、发送装置以及数据处理方法

Info

Publication number: CN108293148A
Application number: CN201680067759.9A
Authority: CN
Inventors: 山岸靖明; 五十岚卓也
Original assignee: Sony Corp
Current assignee: Sony Corp
Priority date: 2015-11-25
Filing date: 2016-11-11
Publication date: 2018-07-17
Anticipated expiration: 2036-11-11
Also published as: WO2017090457A1; JPWO2017090457A1; KR20240025698A; KR20180088383A; MX2018006174A; EP3383054A1; EP3383054A4; US11575961B2; US20210266629A1; AU2016360190A1; US10986397B2; KR102637023B1; CA3003683A1; CN108293148B; AU2021202436B2; AU2021202436A1; EP3383054B1; US20180288468A1

Abstract

本发明的技术涉及使得能够在多个服务中共享重复使用的资源的接收装置、发送装置以及数据处理方法。接收装置接收内容，并且基于与内容一起传输并且包括指示内容资源是否是多个服务共享的资源的资源共享信息的控制信息，接收装置控制资源在存储装置中的存储，使得多个服务共享内容资源。本发明的技术可应用于支持例如ATSC3.0的电视接收器。

Description

接收装置、发送装置以及数据处理方法

技术领域

本技术涉及接收装置、发送装置、以及数据处理方法，并且更具体地，涉及允许在多个服务中共享重复使用的资源的接收装置、发送装置、以及数据处理方法。

背景技术

为了改善访问客户端装置中随附有特定服务的应用的文件的性能，必须将必要的文件预先缓存到本地缓存中。

ATSC(高级电视系统委员会)3.0，当前正在开发的美国下一代的广播标准，例如，假定了这样的模型，即，经由广播或者通信获得的所有文件暂时累积在客户端装置中的本地文件系统上的本地缓存中并且提供至流渲染器和应用。然而，应当注意的是，例如，诸如存储器或固态存储器(Solid State Drive)或特定数据库上的文件系统用作本地文件系统。

首先将本地缓存中的这些文件在缓存中保留有限时长并且然后基于文件所附的HTTP(超文本传输协议)报头的超高速缓存控制报头的参数进行删除。应注意，在选择实体模式的情况下，进行这样的处理，实体模式是一种ROUTE(通过单向传输的实时对象传送)协议传送模式。

通常，由于客户端装置的调谐器和存储资源限制性而不能缓存可接收的广播电波中的所有文件。因此，假定这样一种操作类型，即，在该点仅获得并缓存调谐服务所需的一组文件，在服务(信道)切换到其他服务的情况下，立刻释放存储资源。

应注意，正在踊跃尝试开发经由单向广播从广播站的广播服务器传送内容(诸如，广播节目和广告)或者经由双向通信将内容从通信服务器传送到客户端装置的技术并且使其标准化。作为经由广播或者通信实现数据传送的这种技术，例如，已知的是在PTL1中公开的技术。

[引用列表]

[专利文献]

[PTL 1]

JP 2014-57227A

发明内容

[技术问题]

在此，可通过共享例如在服务中传输的那些文件中的广告内容文件(即，在任何服务中普遍使用的文件)实现缓存存储区、传送频带等的有效使用。由于这个原因，建议要求在多个服务中共享重复使用的资源。

已考虑到以上情况设计本技术，并且本技术的目的是允许在多个服务中共享重复使用的资源。

[问题的解决方案]

本技术的第一方面的接收装置是包括接收部和控制部的接收装置。接收部接收内容。控制部基于与内容一起传输的并且包括指示是否在多个服务中共享内容的资源的资源共享信息的控制信息控制资源在存储装置中的存储，使得在多个服务中共享资源。

本技术的第一方面的接收装置可以是独立的装置或者组成装置的内部块。另外，本技术的第一方面的数据处理方法是与上述本技术的第一方面的接收装置相关联的数据处理方法。

在本技术的第一方面的接收装置和数据处理方法中，接收内容，并且基于与内容一起传输的并且包括指示是否在多个服务中共享内容的资源的资源共享信息的控制信息控制资源在存储装置中的存储，使得在多个服务中共享资源。

本技术的第二方面的发送装置是包括生成部和传输部的发送装置。生成部生成包括指示是否在多个服务中共享内容的资源的资源共享信息的控制信息。传输部将控制信息连同内容一起发送。

本技术的第二方面的发送装置可以是独立的装置或者组成装置的内部块。另外，本技术的第二方面的数据处理方法是与上述本技术的第二方面的发送装置相关联的数据处理方法。

在本技术的第二方面的发送装置和数据处理方法中，生成包括指示是否在多个服务中共享内容的资源的资源共享信息的控制信息并且将控制信息连同内容一起发送。

[发明的有利效果]

根据本技术的第一方面和第二方面，可共享多个服务重复使用的资源。

应注意，本文中描述的效果不必限于此并且可以是本公开中描述的任一种效果。

附图说明

[图1]图1是示出了应用本技术的传输系统的实施方式的配置的示图。

[图2]图2是示出了本技术的IP传输方案的协议栈的实例的示图。

[图3]图3是示出了ROUTE/FLUTE结构的示图。

[图4]图4是示出了详细的ROUTE结构的示图。

[图5]图5是示出了缓存配额域的概述的示图。

[图6]图6是示出了配额域标识符的布置的示图。

[图7]图7是示出了指定配额域标识符的方法的示图。

[图8]图8是示出了配额域标识符指定与文件缓存之间的关系的示图。

[图9]图9是示出了广告插入的流程的示图。

[图10]图10是示出了接收侧上的上层中的处理的流程的示图。

[图11]图11是示出了MPD元数据的周期元素的xlink:href属性的描述实例的示图。

[图12]图12是使用MPD元数据描述按时间顺序的广告插入控制的示图。

[图13]图13是示出了MPD元数据的描述实例的示图。

[图14]图14是示出了MPD元数据的描述实例的示图。

[图15]图15是示出了SLT格式的实例的示图。

[图16]图16是示出了USBD格式的实例的示图。

[图17]图17是示出了S-TSID格式的实例的示图。

[图18]图18是示出了srcFlow格式的实例的示图。

[图19]图19是示出了AST格式的实例的示图。

[图20]图20是示出了AST格式的实例的示图。

[图21]图21是示出了AST格式的实例的示图。

[图22]图22是示出了Ad/DASH服务器的配置实例的示图。

[图23]图23是示出了广播服务器的配置实例的示图。

[图24]图24是示出了通信服务器的配置实例的示图。

[图25]图25是示出了客户端装置的配置实例的示图。

[图26]图26是描述了发送侧的处理流程的流程图。

[图27]图27是描述了接收侧的处理流程的流程图。

[图28]图28是描述了接收侧的处理流程的流程图。

[图29]图29是示出了计算机的配置实例的示图。

具体实施方式

将参照示图对本技术的实施方式进行描述。应注意，将按照下列顺序给出描述。

1.系统配置

2.缓存配额域的概述

3.应用的应用例

4.信令的实例

5.每个装置的配置

6.每个装置执行的处理流程

7.变形例

8.计算机的配置

<1.系统配置>

(传输系统的配置)

图1是示出了应用了本技术的传输系统的实施方式的配置的示图。应注意，系统是指多个装置的逻辑集。

在图1中，传输系统1包括Ad/DASH服务器10、广播服务器20、通信服务器30、以及客户端装置40。

Ad/DASH服务器10是用于处理支持MPEG-DASH(通过HTTP的动态自适应流)的传送服务的服务器。在此，MPEG-DASH是符合OTT-V(越顶视频)的流式传送标准，OTT-V指的是使用基于HTTP(超文本传输协议)的流协议的自适应流式传送。

在该MPEG-DASH标准中，规定了用于描述视频及音频文件的元数据、管理信息的manifest文件以及用于传输视频内容的文件格式。应注意，前者manifest文件称为MPD(媒体呈现描述)。另外，后者文件格式还称为片段格式。

Ad/DASH服务器10生成节目内容片段(在下文中还称为DASH片段)和广告内容片段(在下文中还称为Ad片段)的文件并且将文件发送给广播服务器20或通信服务器30。另外，Ad/DASH服务器10生成MPD元数据并且将其发送给广播服务器20或通信服务器30。

另外，Ad/DASH服务器10生成应用并且将其发送给广播服务器20或通信服务器30。对于该应用，例如，包括可以执行脚本的脚本应用。应注意，可以将使用诸如HTML5(超文本标记语言5)的标记语言开发的应用和使用诸如Java脚本(注册商标)的脚本语言开发的那些应用用作脚本应用。

广播服务器20是能够传输符合数字广播标准(诸如，ATSC 3.0)的数据的发送器。广播服务器20处理DASH片段、Ad片段、MPD元数据、以及从Ad/DASH服务器10发送的应用文件并且经由传输信道80将它们与信令一起发送(广播)。

另外，将NRT内容输入至广播服务器20。NRT内容是由NRT(非时实)广播传输并且在临时存储在客户端装置40的存储器中之后再现的内容。广播服务器20处理向其输入的NRT内容文件并且经由传输信道80发送(广播)它们。

通信服务器30是响应于来自连接到互联网90的客户端装置40的请求经由互联网90提供各种数据的服务器。通信服务器30处理DASH片段、Ad片段、MPD元数据、以及从Ad/DASH服务器10发送的应用文件。然后，通信服务器30响应于来自客户端装置40的请求经由互联网90发送各种文件。

客户端装置40是能够接收符合数字广播标准(诸如，ATSC 3.0)的传输数据的接收器。例如，客户端装置40是静止的接收器(诸如，电视接收器或机顶盒)或者移动接收器(诸如，智能电话、移动电话、或平板电脑)。例如，客户端装置40可以是安装在汽车上的一台设备，诸如，车载电视。

客户端装置40通过接收并且处理文件(诸如，DASH片段、广告片段、信令、MPD元数据、应用、以及经由传输信道80从广播服务器20发送(广播)的NRT内容)输出内容(诸如，广播节目和广告)的图像和声音。

另外，在配备有通信能力的情况下，客户端装置40可以通过经由互联网90访问通信服务器30获取各种文件。例如，客户端装置40通过接收并且处理文件(诸如，DASH片段、广告片段、以及经由互联网90从通信服务器30发送的MPD元数据(通过流自适应传送的))输出内容(诸如，VOD(视频点播)节目和广告)的图像和声音。

应当注意的是，在传输系统1中，传输信道80不仅可以是地面波(地面波广播)而且还是使用广播卫星(BS)或通信卫星(CS)的卫星广播或者使用电缆(CATV)的有线广播。

另外，ATSC 3.0是当下正进行开发的美国下一代广播标准。ATSC 3.0假定通过引入在通信领域使用的用于数字广播的使用IP(互联网协议)数据的方案(IP传输方案)而不是当前普及的MPEG2-TS(传输流)方案作为传输方案而提供更高级的服务。

(本技术的协议栈)

图2是示出了本技术的IP传输方案的协议栈的实例的示图。

在图2中，最底层是物理层。IP传输方案(诸如，ATSC 3.0)中的数字广播不仅使用单向广播处理传输而且还通过双向通信传输一部分数据。在使用广播的情况下，其(广播)物理层与为服务分配的广播波的频带(信道)相关联。

物理层(广播)上的层是IP层。IP层对应于分级通信模型中的网络层。由IP地址标识IP数据包。邻近IP层的上层是对应于分级通信模型中的传输层的UDP(用户数据报协议)层，并且进一步在其上的层是ROUTE(通过单向传输的实时对象传送)或MMTP(MPEG媒体传输协议)。

另外，将在UDP层之上的层(即，包含UDP数据包的IP数据包)连同包含在其中的SLT元数据一起传输。SLS元数据是LLS(链路层信令)信令，该信令包括指示广播网中的流或服务配置的基本信息，诸如，调谐到服务所需的信息(调谐信息)。应注意，LLS信令是在SLS(服务层信令)信令之前获取的信令，并且根据LLS信令中包含的信息获取SLS信令。

用于流式文件传输的协议是FLUTE(单向传输的文件传输)的扩展协议。应注意，随后将参照图3和图4描述ROUTE的详细内容。

邻近ROUTE的上层的部分是信令(ROUTE特定信令)和NRT内容(NRT文件)。该信令是SLS信令并且包括元数据，诸如，USBD(用户服务包描述)、S-TSID(基于服务的传输会话实例描述)、MPD(媒体呈现描述)、AST(应用信令表)等等。

USD元数据包括诸如其他元数据获取目的地的信息。S-TSID元数据(ATSC 3.0的LSID(LCT会话实例描述)的扩展)是ROUTE协议的控制信息。MPD元数据是如先前描述的通过流传送的视频和音频文件的管理信息。AST是应用控制信息。

应注意，NRT内容是通过ROUTE会话传输的内容的实例，并且诸如应用或者电子服务指南(ESG)的内容可以例如通过ROUTE会话传输。

在邻近ROUTE的上层中，除上述那些以外的层是DASH片段(ISO BMFF)。另外，邻近DASH片段(ISO BMFF)的上层是DASH播放器/解码器。即，在ROUTE用作传输协议的情况下，以符合ISO BMFF(ISO基媒体文件格式)标准的DASH片段为单位通过ROUTE会话传输组成内容(诸如，广播节目)的服务组成(例如，视频、音频、字幕)的流式数据。

另一方面，MMTP是用于流式文件传输的协议。邻近MMTP的上层的部分是信令(MMTP特定信令)。包括元数据(诸如，USBD(用户服务包描述)和MPT(MMT封装表格))作为该信令。

在邻近MMTP的上层中，除信令以外的层是MPU(媒体处理单元)(ISO BMFF)。另外，邻近MPU(ISO BMFF)的上层是DASH播放器/解码器。即，在MMT用作传输协议的情况下，以符合ISO BMFF(ISO基媒体文件格式)标准的MPU为单位通过MMTP会话传输组成内容(诸如，广播节目)的服务组成(例如，视频、音频、字幕)的流式数据。

因此，在图2中描述的协议栈中，ROUTE和MMTP两者表示为传输协议。因此，在基于单向广播的流式传送中，使用两个协议中的一个，即，传输DASH片段(ISO BMFF)文件的ROUTE或传输MPU(ISO BMFF)文件的MMTP。

另外，在使用双向通信的情况下，在物理层(宽带)之上的层是对应于网络层的IP层。另外，邻近IP层的上层是对应于传输层的TCP(传输控制协议)层，并且此外，邻近TCP层的上层是对应于应用层的HTTP层。即，由于这些层，实现在网络(诸如，互联网90)中工作的TCP/IP和其他协议。

邻近HTTP层的上层的一部分是信令(所有信令对象)和NRT内容(NRT文件)。这个信令包括所有的信令，诸如，通过上述ROUTE和MMTP传输的信令。另外，NRT内容是经由通信获得的内容的实例，并且例如可以传输内容(诸如，应用)。

在邻近HTTP层的上层中，除上述那些以外的层是DASH片段(ISO BMFF)。此外，邻近DASH片段(ISO BMFF)的上层是DASH播放器/解码器。即，在基于双向通信的流式传送中，以符合ISO BMFF标准的DASH片段为单位传输组成内容(诸如，VOD节目)的服务组成(例如，视频、音频、字幕)的流式数据。

另外，可通过使用单向广播协议协议(诸如，ROUTE或MMTP)和双向通信协议(诸如，TCP/IP)传输应用。例如，这些应用可以是用HTML5或JS(Java脚本(注册商标))开发的那些应用。

应当注意的是，在图2中，HTTP代理被写入到ROUTE的部分中，因为在通过应用获取DASH片段(ISO BMFF)文件的情况下，假定了在客户端装置40中实现的广播中间件表现为HTTP服务器的实现方式。另外，在图2中，EME/CENC(加密媒体扩展/公共加密方案)符合W3C(万维网联盟)并且将MPEG(运动图像专家组)用作内容保护的安全架构。因此，EME/CENC被写到DASH片段(ISO BMFF)和MPU(ISO BMFF)的部分中。

另外，将包含SLT元数据作为LLS信令的元数据和作为SLS信令的USBD、S-TSID、MPD、以及AST以标记语言(诸如，XML(可扩展标记语言))写入。

如上所述，在本技术的IP传输方案的协议栈中，基于单向广播的层和基于双向通信的层中的一些用作公共协议，从而允许以符合ISO BMFF标准的DASH片段为单位通过单向广播和双向通信传输组成内容的服务组成的流式数据。由于这个原因，在基于单向广播的流式传送和基于双向通信的流式传送两者发生的情况下，由于上层协议已被共用，可以减少例如广播服务器20和客户端装置40中的实现负担和处理负担。(ROUTE结构)

图3是示出了ROUTE结构的示图。然而，应当注意的是，在图3中，为与ROUTE相比较，还写了FLUTE。

FLUTE包括用于称为ALC(异步分层编码)的文件对象的可扩展组播协议，并且具体地，其包括LCT(分层编码传输)和FEC(前向纠错)组成的组合、ALC的构建块。

在此，ALC是适于任意二进制文件的单向组播传输的协议。即，尽管开发为基于高度可靠的异步一对多广播的协议，但ALC使用LCT和FEC。因此，目标文件经历FEC并且被放入LCT数据包中，并且其中通过IP多播传输该目标文件，并将其放入UDP数据包和IP数据包。

通过发送者的IP地址覆盖的唯一的TS1(传输会话标识符)识别FLUTE传输会话。在FLUTE中，可针对每个传输会话或者文件改变FEC方案。另外，FLUTE与针对每个传输会话传输的称为FDT(文件传输表)的XML格式的传输控制信息一起导入。

目标文件的基本属性和传输控制参数写入FDT文件中，以通过与LCT数据包中包含的FEC编码符号相同的传输会话传输。FDT可以定义目标文件标识符与相应FEC编码符号串已放入其中的LCT数据包串之间的映射，并且进一步存储每个文件内容的MIME类型和尺寸、传输编码方案、消息摘要、FEC解码所需的参数等。应注意，FDT本身可经历FEC并且例如通过LCT层单独运输其自身的FEC参数。

顺便提及，ROUTE是FLUTE的扩展，并且可引用对象包和媒体感知分段作为其间的主要区别。图4示出了详细的ROUTE结构。

ROUTE的对象包的特征在于，其在协议层上支持通过将由不同尺寸的源块组成的视频和音频流捆绑在一起配置单个超级对象并且基于超级对象以及源流与修复流之间的关系的通知生成FEC修复流的方法。

通常，音频流等的每单位时间的数据量较小(具有小数据对象)。因此，在源对象尺寸方面，音频流小于视频流。使用每个流相同的FEC方案为具有不同尺寸的源对象的这些流生成修复符号导致不同的误差敏感度，这取决于源对象尺寸的大小。

ROUTE允许通过从具有不同速率的源流中切出源块以配置超级对象，从而准许使用基于超级对象生成的FEC修复符号配置修复流。即，生成跨过不同源流的修复流。在此，可以传输由源符号组成的源流和由修复符号组成的修复流作为一个ROUTE会话内的不同的LCT会话。

与如何通过由从多个源流中切出的源块配置超级对象以生成FEC流有关的信息(控制信息)写入S-TSID元数据，LSID(FDT)的扩展。接收侧可以通过基于在该S-TSID元数据中写入的信息，由经由ROUTE会话传输的LCT数据包串重建超级对象，来提取对象文件。

通常，广播流是发送器侧多路复用并且发送构成服务的所有流的模型并且接收器侧选择接收器本身所需的流。因此，在这样的使用情况下，通过ROUTE实现的FEC配置方法是有效的，即，配置超级对象并且重构超级对象并且在接收侧上选择所需的流的处理模型可用，超级对象由组成发送器侧上的服务的所有流构成。

迄今，已对ROUTE、FLUTE的扩展进行描述。

<2.缓存配额域的概述>

顺便提及，为了提高访问客户端装置40中的带有特定服务(诸如，广播节目)的应用的性能，必须将所需文件提前缓存在本地缓存中。例如，ATSC 3.0假定一种模型，在该模型中，经由广播或通信获得的所有文件暂时累积在客户端装置40的本地文件系统上的本地缓存中并且提供给流渲染器和应用。

另外，在客户端装置40中，由于调谐器和存储资源限制，不能缓存可接收的广播波中的所有文件。因此，假定一种操作类型，在该操作类型中，在该点仅获得并缓存调谐服务所需的一组文件，在服务(信道)切换到其他服务的情况下，立刻释放存储资源。

另一方面，例如，如果在服务中传输的那些文件中的广告内容文件以及在所有服务中普遍使用的文件可在多个服务中共享，那么可具有诸如有效使用高速缓存区和传送带宽的优势。由于这个原因，建议已要求在多个服务中共享重复使用的资源。本技术引入缓存配额域概念，通过传输用于标识缓存配额域的配额领域标识符作为信令，而允许在客户端装置40中的多个服务中共享重复使用的资源。

(缓存配额域的概述)

图5是示出了缓存配额域的概述的示图。

缓存配额域是用于共享重复使用的资源的域(群组)。图5示出了服务A、服务B、以及服务C属于配额域1并且服务X和服务Y属于配额域2的情况。应注意，在图5中描述的本地缓存的存储区相当于随后将在图25中描述的本地缓存404的持久高速缓存404B的存储区。

在这种情况下，将应用、DASH片段、以及属于配额域1的服务A到C共享的其他文件缓存在分配给客户端装置40中的本地缓存的配额域1的存储区中。即，将属于配额域1的服务所共享的文件缓存在本地缓存的通过配额域1(其配额域标识符)识别的存储区中。因此，在属于配额域1的服务中可获取并处理(再现)所讨论的存储区中的文件。

另一方面，将应用、DASH片段、周期文件(period file)、以及属于配额域2的服务X和Y共享的其他文件缓存在分配给本地缓存的配额域2的存储区中。即，将属于配额域2的服务共享的文件缓存在本地缓存的通过配额域2(其配额域标识符)识别的存储区中。因此，在属于配额域2的服务中可获取并处理(再现)所讨论的存储区中的文件。

然而，应当注意的是，每个服务不能延伸超过其所属的配额域而访问其他配额域的资源。例如，属于配额域1的服务A到C不能访问配额域2的资源，并且属于配额域2的服务X和Y不能访问配额域1的资源。

因此，通过引入缓存配额域概念，属于每个配额域的服务可以共享并且使用(重复使用)它们所属的配额域中可用的资源。

例如，如果由单个广播站提供的多个服务或者由多个广播站组成的广播站联盟提供的多个服务可以通过属于相同的缓存配额域共享每个缓存配额域的资源(文件)。

(配额域标识符的布置实例)

图6是示出了配额域标识符的布置实例的示图。

可由通过广播波的每个层传输的信令传输用于识别缓存配额域的配额域标识符。即，通过在信令中添加可指定对象服务属于的缓存配额域的配额域标识符的属性(或元素)，可以基于客户端装置40中的信令包含的配额域标识符在属于相同的缓存配额域的服务之间共享资源(文件)。

如图6所示，通过扩展SLT元数据、IP/UDP数据包的有效载荷中包含的LLS信令、USBD元数据、S-TSID元数据、或AST元数据、IP/UDP数据包的有效载荷中包含的并且通过LCT会话传输的SLS信令，配额域标识符可以布置在其中。

(A)SLT元数据中的布置

在通过扩展SLT元数据指定缓存配额域的配额域标识符，SLT元数据可以指定多个服务属性。因此，添加可指定配额域标识符的属性(或元素)作为对象服务的属性。在此，例如，可通过在SLT元数据的服务元素中定义配额域属性指定对象服务所属的缓存配额域的配额域标识符。

例如，在提供服务A到Z的情况下，将配额域1的配额域标识符(图5)指定为在SLT元数据中指定服务A到C的服务ID的服务元素的配额域属性。另外，在该SLT元数据中，将配额域2(图5)的配额域标识符指定为指定服务X和Y的服务ID的服务元素的配额域属性。

因此，可以通过在SLT元数据中在服务元素中定义配额域属性而以服务为单位指定配额域标识符。

(B)USBD元数据中的布置

在通过扩展USBD元数据指定缓存配额域的配额域标识符的情况下，可通过在USBD元数据的USD元素中定义配额域属性指定对象服务所属的缓存配额域的配额域标识符。

例如，在提供服务A到Z的情况下，将配额域1的配额域标识符(图5)指定为服务A到C的USBD元数据中的USD元素的配额域属性。另外，例如，在服务X和Y的USBD元数据中，将配额域2的配额域标识符(图5)指定为USD元素的配额域属性。

因此，可以通过在USBD元数据中在USD元素中定义配额域属性以服务为单位指定配额域标识符。

(C)S-TSID元数据中的布置

在通过扩展S-TSID元数据指定缓存配额域的配额域标识符的情况下，可通过在S-TSID元数据的RS元素的LS元素的srcFlow元素的ContentInfo元素中定义配额域属性，来指定目标LCT会话所属的缓存配额域的配额域标识符。

因此，可以通过在S-TSID元数据的RS元素的LS元素的srcFlow元素的ContentInfo元素中定义配额域属性以LCT会话为单位指定配额域标识符。

(D)AST元数据中的布置

在通过扩展AST元数据指定缓存配额域的配额域标识符的情况下，可通过在AST元数据的应用元素的特定应用的描述符元素的atsc:atscDescriptor元素中定义配额域属性，来指定对象应用所属的缓存配额域的配额域标识符。

因此，可以通过在AST元数据的应用元素的特定应用的描述符元素的atsc:atscDescriptor元素中定义配额域属性，而以应用为单位指定配额域标识符。

如上所述，通过扩展SLT元数据、USBD元数据、S-TSID元数据或AST元数据指定配额域标识符，可以在同一缓存配额域内以服务为单位、以LCT会话为单位、或以应用为单位共享资源(文件)。

即，如在图7中示出的，每个服务包括一个或多个会话，并且例如通过每个LCT会话传输DASH片段或应用文件或任意文件。

在此，如图7中所描述的，在期望以服务为单位共享资源的情况下，通过扩展SLT元数据服务条目(每个服务的基本属性)或USBD元数据的每个服务的属性，定义配额域属性。即，在与通过SLT元数据或USBD元数据的配额域属性指定的字符串对应的对象服务中传输用于识别存储文件的本地缓存的存储区的配额域标识符。例如，应注意，在这种情况下文件是诸如应用、DASH片段、或周期文件的文件并且不仅包括经由广播获得的文件而且还包括经由通信获得的那些文件。

然而，应当注意的是，在通过SLT元数据或USBD元数据的配额域属性在服务层处指定缓存配额域(例如，配额域1)的情况下，并且在发出了将通过属于对象服务的LCT会话传输的所有文件缓存在本地缓存(其持久高速缓存)中的指令的情况下，将所有的文件缓存到分配给本地缓存(图8中的A(B))的缓存配额域(例如，配额域1)的存储区中。

应注意，尽管随后将参照在图15中描述的SLT元数据格式描述细节，但在SLT元数据的服务元素中指定了SLS信令位置信息。然后，在经由广播获得SLS信令的情况下，通过BroadcastSvcSignaling元素指定该位置信息。在经由通信获得SLS信令的情况下，通过SvcInetUrl元素指定该位置信息。例如，根据SLT元数据的服务元素的位置信息经由广播或通信获得USBD元数据。

另外，如在图7中所示，在期望以LCT会话为单位共享资源的情况下，通过扩展S-TSID元数据的每个LCT会话属性，来定义配额域属性。即，用于识别存储文件的本地缓存的存储区的配额域标识符对应于通过S-TSID元数据的配额域属性指定的字符串，其中，经过对象LCT会话传输文件。应注意，在这种情况下，文件是例如诸如应用、DASH片段、或周期文件的文件。

然而，应当注意的是，在通过S-TSID元数据的配额域属性在LCT会话层处指定缓存配额域(例如，配额域1)的情况下，认识到，对象LCT会话所属的服务属于缓存配额域(例如，配额域1)。

然后，在发出将通过已指定其缓存配额域(例如，配额域1)的LCT会话传输的文件缓存到本地缓存(其持久高速缓存)中的指令的情况下，将那些文件缓存在本地缓存(图8中的C1)的缓存配额域(例如，配额域1)的存储区中。另一方面，即使当LCT会话属于与已指定其缓存配额域(例如，配额域1)的LCT会话相同的服务时，如果没有为该LCT会话指定缓存配额域，则文件不会持久缓存(图8中的C2)。

应注意，尽管随后将参照图16中描述的USBD元数据格式描述细节，但在USBD元数据的USD元素的STSIDUri属性中指定指示S-TSID元数据的获取目的地的URI(统一资源标识符)。然后，根据该URI获得S-TSID元数据。

另外，如图7所示，在期望以应用为单位共享资源的情况下，通过扩展AST元数据的每个应用的属性定义配额域属性。即，用于识别本地缓存的存储区的配额域标识符对应于由AST元数据的配额域属性指定的字符串，存储区存储要写到对象AST元数据中的应用的文件。

然而，应当注意的是，在通过AST元数据的配额域属性在应用层处指定缓存配额域(例如，配额域1)的情况下，认识到，对象应用所属的服务属于缓存配额域(例如，配额域1)。

然后，在发出了将通过已指定其缓存配额域(例如，配额域1)的应用的文件缓存到本地缓存(其持久高速缓存)中的指令的情况下，将那些文件缓存在本地缓存(图8中的D)的缓存配额域(例如，配额域1)的存储区中。另一方面，即使当应用属于与其缓存配额域(例如，配额域1)已指定的应用相同的服务时，如果没有为该应用指定缓存配额域，则不会持久缓存该文件。

因此，通过引入缓存配额域概念并且传输用于识别SLT、USBD、S-TSID、AST、或其他元数据(控制信息)中包括的缓存配额域的配额域标识符(资源共享信息)，客户端装置40可以在本地缓存(其持久高速缓存)中保留属于相同的缓存配额域的服务中所包含的文件(资源)并且以服务为单位、以LCT会话为单位、或以应用为单位共享文件(资源)。

<3.应用的应用例>

下面将参照图9至图14对在系统中实现缓存配额域的情况进行描述，该系统插入使用与第一内容(广播节目)一起传输的应用的第二内容(广告)。应注意，所讨论的应用被设计成通过执行脚本实现广告插入控制。因此，在下面的描述中，应用以下将简称脚本应用。

(广告插入的流程)

图9是示出了广告插入的流程的示图。

图9描述了插入适于用户的广告(TV2_Ad)代替在客户端装置40中的广播节目(BP1、BP2)之间再现默认广告(TV1_Ad)的情况。

在图中，在时间的方向是从左到右的情况下，实时获得的广告Ad1通常在广播节目BP1再现的时间t1到时间t2的时段以及广播节目BP2再现的时间t3到时间t4的时段之间的时间t2到时间t3期间再现。

另外，尽管在该实例中两种广告(即，默认广告Ad1和插入广告Ad2)都是可获得的，但广告Ad2是经由广播或者通信获得并且缓存在本地缓存(其持久高速缓存)中，而广播节目BP1-1是在时间t1到时间t2期间(即，在广告插入间隔之前的时间)再现。

在客户端装置40中，当广播节目BP1-2的场景出现时，用户的问题叠加显示在图像上。然后，客户端装置40响应于用户对该问题的答案显示适于所讨论用户的广告。在客户端装置40中，例如，在用户回答问题的情况下，从本地缓存(其持久高速缓存)中读取匹配答案的插入广告Ad2，并且然后用适于用户的广告Ad2替代默认广告Ad1。

因此，通过将用户更可能观看的广告缓存到客户端装置40的本地缓存中(其持久高速缓存)，可以通过使用缓存的广告显示适于用户的广告。

应注意，尽管在图9中描述的广告插入的实例中，描述了响应于用户的输入操作选择适于用户的广告内容的情况，但除了与用户交换消息(交互)之外，可以使用与预先指定的用户特征(诸如，用户偏好或配置文件)有关的信息(例如，性别、年龄、居民区)选择广告内容。

顺便提及，3GPP(第三代伙伴计划)和DASH-IF(行业论坛)，移动通信系统的标准化项目跟随广告插入控制实现方法的脚步，该广告插入控制实现方法通过MPEG-DASH规定的周期元素XLink个性化。假定ATSC3.0也将跟随该广告插入控制实现方法的脚步。应注意，XLink是用于定义XML文档之间的链接的描述，该描述通过W3C(万维网联盟)通知。

这种广告插入控制采用这样一种方法，即，预先使用于MPD元数据广告插入间隔的文件可用并且根据用户特征(例如，用户偏好)动态地改变用于指定广告内容流的片段的周期元素。在图10中描述了支持这种广告插入控制的客户端装置40。

在图10中，客户端装置40具有应用/编解码器能力、DASH客户端能力、以及传输栈/HTTP服务器能力。另外，传输栈/HTTP服务器能力包括XLink解析器能力和HTTP代理缓存能力。然而，应当注意的是，通信服务器30的HTTP服务器可具有XLink解析器能力。

在此，在客户端装置40接收作为SLS信令传输的MPD元数据的情况下，通过HTTP代理缓存获得MPD元数据，并且然后通知DASH客户端(S51)。在该MPD元数据中，指定要被XLink解析器解析的URL(统一资源定位符)，该XLink解析器在客户端装置40或通信服务器30的HTTP服务器上作为周期元素(period element，周期要素)的xlink:href属性运行。

具体地，关注A1(广告时间#1)、M1(主节目)、A2(广告时间#2)、M2(主节目)、A3(广告时间#3)、以及M3(主节目)的周期元素，写到MPD元数据中的周期元素，如图11所示，“http://adservice.com/adp-1？user＝$groupID$”写成xlink:href属性URL。

应注意，“http://adservice.com/adp-1？user＝$groupID$”还写成A2(广告时间#2)或A3(广告时间#3)中的xlink:href属性URL并且与A1(广告时间#1)相似地处理URL。

参考回图10的描述，在客户端装置40中，通过在该URL的groupID的参数部分中插入标识用户的值向通信服务器30或客户端装置40的HTTP服务器上的XLink解析器发布HTTP请求(S52)。例如，向XLink解析器通知其中插入有groupID值的URL，诸如“http://adservice.com/adp-1？user＝classA”。

当从DASH客户端通知其中插入groupID值的URL时，客户端装置40的XLink解析器或通信服务器30向DASH客户端返回包含针对由groupID识别的特定用户(例如，classA用户)生成的URL的周期元素文件(以下简称周期文件)(S53)。该周期元素中包含的URL是在经由单向广播传送的情况下使用ROUTE协议和在经由双向通信传送的情况下使用HTTP协议传送的片段的URL(片段URL)。

然后，在客户端装置40中，DASH客户端和HTTP代理缓存根据在步骤S53中的处理获得的周期文件的周期元素参与交互，诸如，请求和传送片段。因此，获得匹配周期元素的片段URL的片段(S54)。

在该广告插入间隔期间(例如，图9中从时间t2到时间t3的间隔)再现与以这种方式获得的片段相匹配的广告内容。

更具体地，图12示出了在M1再现之前随时间插入A1(广告时间#1)，在M1与M2之间插入A2(广告时间#2)、以及在M2与M3之间插入A3(广告时间#3)的广告插入控制，其中从00:00:00到00:15:00再现M1(主节目)，从00:15:00到00:30:00再现M2(主节目)，并且从00:30:00到00:42:00再现M3(主节目)。

在该实例中，三种广告可用作A1(广告时间#1)，并且要再现的广告的内容根据诸如30多岁的男性或60多岁的女性的用户特征(例如，用户偏好)动态地改变。类似地，多个广告可用作A2(广告时间#2)和A3(广告时间#3)，从而允许再现与用户特征相比配的广告。

应注意，在图10中，尽管描述了在客户端装置40的HTTP服务器或通信服务器30上运行XLink解析器的实例，但脚本应用可以在客户端装置40中起到XLink解析器的作用。

即，在DASH客户端通过解析MPD元数据(分析MPD元数据的语法)检测广告插入的周期元素的xlink:href属性的URL的情况下，向脚本应用通知其URL，而不是立即向在HTTP服务器上运行的XLink解析器发送HTTP请求。

当从DASH客户端通知URL时(当请求XLink解析时)，脚本应用基于用于识别在URL的路径部分或查询字符串中反映的广告插入间隔的信息，在用于在该间隔插入的多条可能的广告内容(广告片段)中选择一条适于目标用户的广告内容(广告片段)。

然后，脚本应用生成包含适合于所选择的一条广告内容(广告片段)的周期元素的周期文件并且回复给DASH客户端。例如，该周期文件的周期元素包括针对groupID指定的特定用户(例如，classA用户)生成的URL，并且当再现一组广告片段时，基于片段URL的列表，再现广告内容。

在此，对于对适于用户的广告内容的选择，例如，可以在一些情况下根据由客户端装置40管理的用户偏好或者在其他情况下根据通过与用户交换消息(交互)获得的所需的信息，进行选择。例如，在上述图9描述的广告插入的情况下，根据用户输入操作选择适于用户的广告内容。

因此，在客户端装置40侧解析MPD元数据的周期元素的XLink消除了对请求在通信服务器30的HTTP服务器上运行的XLink解析器进行XLink解析的需要。

由于这个原因，在通过通信服务器30的XLink解析器解析XLink的情况下，预期紧接广告插入间隔之前从连接到互联网90的大量客户端装置40集中访问通信服务器30。然而，使用客户端装置40的XLink解析器的XLink解析消除了XLink解析的交易处理负荷增加。

另外，在客户端装置40中，通过在广告插入间隔之前随时间将经由广播或者通信获得的多条可能的广告内容(广告片段)缓存在本地缓存(其持久高速缓存)中，可以通过广告插入控制确保广告插入的可靠性。例如，在经由通信获得广告内容(广告片段)的情况下，可以不依赖于互联网90的通信条件等获得广告内容(广告片段)。然而，预先缓存广告内容(广告片段)有利于通过广告插入控制进行更可靠的广告插入。

此外，本技术引入缓存配额域概念，允许在客户端装置40中的多个服务中共享重复使用的广告内容(广告片段)文件。这有助于提高缓存在本地缓存(其持久高速缓存)中的可能的广告内容(广告片段)的可复用性，从而允许通过广告插入控制进行更可靠的广告插入。

(MPD描述实例)

下面将参照图13和图14对XML格式的MPD元数据的描述实例进行描述。

应注意，将周期元素、适应组元素、表示元素写到MPD元数据中的分级结构中。周期元素用作写入服务(诸如，内容)的配置的单元。另外，适应组元素和表示元素用于每个服务成分流，诸如视频、音频、字幕等并且允许写入这些元素的相应流属性。

在图13中描述的MPD元数据的描述实例中，写入主节目的周期元素和广告(Ad)的周期元素。

将用于管理主节目内容(MP4格式的视频文件)再现的信息写入主节目的周期元素中。然而，应当注意的是，将对应于EIDR(娱乐标识符注册)的ID分配给schemeIdUri属性和AssetIdentifier元素的值属性。

另一方面，在广告(Ad)的周期元素中，将URL与用于管理默认广告内容(MP4格式的视频文件)再现的信息一起写入周期元素的xlink:href属性中(图13中的A)。向在通信服务器30的HTTP服务器上运行的XLink解析器通知该URL，从而允许获得用于插入的广告并且允许用用于插入的广告来代替默认广告。

在图14中描述的元数据描述实例中，写入主节目的周期元素和广告(Ad)的周期元素。

将用于管理主节目内容(MP4格式的视频文件)再现的信息写入主节目的周期元素中。

另一方面，在广告(Ad)的周期元素中，将URL与用于管理默认广告内容(MP4格式的视频文件)再现的信息一起写入周期元素的xlink:href属性中(图14中的A)。在此，向在客户端装置40的HTTP服务器上运行的XLink解析器通知其中插入groupID值的URL，从而允许获得适于特定用户的广告并且允许用适于用户的广告代替默认广告。应注意，图14的A中的“urn:atsc:ad-insertion”指示对(客户端装置40)本地执行的脚本(脚本应用)必须做出的请求以解析广告插入控制，随后将描述其细节。

应注意，尽管上文通过引用广告内容作为例子描述了使用缓存配额域在多个服务中共享广告内容(广告片段)文件，但本技术还可适于除广告之外的其他内容。另外，文件仅仅是内容资源的实例，并且只要可通过客户端装置40处理，可以使用任何种类的数据。

4.<信令的实例>

下面将参照图15至图21描述用于传输用于识别缓存配额域的配额域标识符的信令格式的实例。

(SLT格式)

图15是示出了XML格式的SLT元数据格式的实例的示图。应当注意的是，在图15中的元素和属性中，属性标记有“@.”。另外，针对它们的上级元素指定缩进元素和属性。这些关系与随后将描述的其他信令格式相似。

SLT元素是根元素并且是bsid属性、sltCapabilities属性、sltInetUrl元素、以及服务元素的上级元素。

在bsid属性中指定广播流ID。在sltCapabilities属性中指定与所需能力有关的信息。

在sltInetUrl元素中指定用于获取ESG或SLS信令的基本URL。SltInetUrl元素是urlType属性的上级元素。在urlType属性中指定基本URL可以使用的文件类型。

在服务元素中指定与一个或多个服务有关的信息。服务元素是serviceId属性、sltSvcSeqNum属性、保护属性、majorChannelNo属性、minorChannelNo属性、serviceCategory属性、shortServiceName属性、隐含属性、broadbandAccessRequired属性、svcCapabilities属性、配额域属性、BroadcastSvcSignaling元素、以及SvcInetUrl元素的上级元素。

在serviceId属性中指定服务ID。在sltSvcSeqNum属性中指定与SLT元数据版本有关的信息。在保护属性中指定指示服务保护的加密信息。

在majorChannelNo属性中指定主信道号。在minorChannelNo属性中指定次信道号。在serviceCategory属性中指定服务类别。在shortServiceName属性中指定短服务名称。

在隐含属性中指定服务是否是隐藏的服务。在broadbandAccessRequired属性中指定是否必须访问通信电路(诸如，互联网90)。在svcCapabilities属性中指定与用于解码所需的能力有关的信息。

在配额域属性中指定对象服务所属的缓存配额域的配额域标识符。在属于相同的缓存配额域的服务中共享缓存在本地存储器中的资源(文件)。

在BroadcastSvcSignaling元素中指定与经由广播获得SLS信令的SLS信令获取目的地有关的信息。BroadcastSvcSignaling元素是slsProtocol属性、slsMajorProtocolVersion属性、slsMinorProtocolVersion属性、slsPlpId属性、slsDestinationIpAddress属性、slsDestinationUdpPort属性、以及slsSourceIpAddress属性的上级元素。

在slsProtocol属性中指定与SLS信令协议有关的信息。在slsMajorProtocolVersion属性中指定SLS信令协议的主版本号。在slsMinorProtocolVersion属性中指定SLS信令协议的次版本号。

在slsPlpId属性中指定传输SLS信令所经由的PLP(物理层管道)的ID。在slsDestinationIpAddress属性中指定SLS信令目的地的IP地址。在slsDestinationUdpPort属性中指定SLS信令目的地的端口号。在slsSourceIpAddress属性中指定SLS信令源的IP地址。

在经由通信获得SLS信令的SvcInetUrl元素中指定SLS信令获取目的地的URL。SvcInetUrl元素是urlType属性的上级元素。在urlType属性中指定该URL可以使用的文件类型。

应当注意的是，就图15中出现(使用)数而言，在指定“1”的情况下，元素或属性仅被指定一次，并且在指定“0..1”的情况下，可选地指定元素或属性。另外，在指定“1..N”的情况下，元素或属性被指定一次或多次，并且在指定“0..N”的情况下，可选地指定元素或属性一次或多次。

另外，在将“unsignedShort”或“unsignedByte”指定为数据类型的情况下，其指示元素或属性的值为整数型。在将“字符串”指定为数据类型的情况下，其指示元素或属性的值是字符串类型。在指定“anyURI”的情况下，其指示元素或属性的值是URI格式的字符串。在将“boolean”指定为数据类型的情况下，其指示元素或属性的值是布尔型。应注意，在将“语言”指定为数据类型的情况下，其指示元素或属性的值作为xml:lang属性的值有效。在指定“日期时间”的情况下，其指示元素或属性的值指示具体日期与时间。

(USBD格式)

图16是示出了XML格式的USBD元数据的实例的示图。

BundleDescription元素是根元素并且是userServiceDescription元素(USD元素)的上级元素。该userServiceDescription元素是globalServiceID属性、serviceId属性、serviceStatus属性、fullMPDUri属性、STSIDUri属性、配额域属性、名称元素、serviceLanguage元素、capabilityCode元素、以及deliveryMethod元素的上级元素。

在globalServiceID属性中指定全局服务ID。在serviceId属性中指定服务ID。在serviceStatus属性中指定与服务状态有关的信息。在fullMPDUri属性中指定参考MPD元数据的URI。在STSIDUri属性中指定参考S-TSID元数据的URI。

在配额域属性中指定对象服务所属的缓存配额域的配额域标识符。属于相同的缓存配额域的服务共享缓存在本地存储器中的资源(文件)。

在名称元素中指定ATSC 3.0服务的名称。名称元素是语言属性的上级元素。在语言属性中指定ATSC 3.0服务名称的语言。在serviceLanguage元素中指定在ATSC 3.0服务中可以使用的语言。在capabilityCode元素中指定与能力有关的代码。

在deliveryMethod元素中指定与数据传送方法有关的信息。DeliveryMethod元素是broadcastAppService元素和unicastAppService元素的上级元素。BroadcastAppService元素是basePattern元素的上级元素，并且在broadcastAppService元素中指定与经由广播进行传送有关的信息。UnicastAppService元素是basePattern元素的上级元素，并且在unicastAppService元素中指定与经由通信进行传送有关的信息。

(S-TSID格式)

图17是示出了S-TSID元数据格式的实例的示图。

S-TSID元素是根元素并且是serviceId属性和RS元素的上级元素。在serviceId属性中指定服务ID。

在RS元素中指定与ROUTE会话有关的信息。RS元素是bsid属性、sIpAddr属性、dIpAddr属性、dport属性、PLPID属性、以及LS元素的上级元素。

在bsid属性中指定广播流ID。在sIpAddr属性中指定源IP地址。在dIpAddr属性中指定目的地IP地址。在dport属性中指定目的地端口号。在PLPID属性中指定ROUTE会话PLPID。

在LS元素中指定与LCT会话有关的信息。LS元素是tsi属性、PLPID属性、bw属性、startTime属性、endTime属性、srcFlow元素、以及RprFlow元素的上级元素。

在tsi属性中指定TSI。在PLPID属性中指定PLP ID。在bw属性中指定带宽。分别在startTime属性和endTime属性中指定开始日期和时间和结束日期和时间。在srcFlow元素中指定源流信息。应注意，随后将参照图18描述该srcFlow元素的详细内容。在RprFlow元素中指定源流信息。

(srcFlow元素格式)

图18是示出了图17中描述的S-TSID元数据中包含的srcFlow元素的格式的实例的示图。

SrcFlow元素是rt属性、minBuffSize属性、EFDT元素、ContentInfo元素、以及有效载荷元素的上级元素。在minBuffSize属性中指定客户端装置40所需的最小缓冲区大小。

在EFDT元素中指定与扩展FDT有关的信息。在ContentInfo元素中指定与内容有关的信息。ContentInfo元素是配额域属性的上级元素。

在配额域属性中指定包含对象LCT会话的服务所属的缓存配额域的配额域标识符。在属于相同的缓存配额域的服务中共享缓存在本地存储器中的资源(文件)。

有效载荷元素是码点属性、formatID属性、frag属性、顺序属性、srcFecPayloadID属性、以及FECParams属性的上级元素，并且在有效载荷元素中指定与源流对象中包含的ROUTE数据包的有效载荷有关的信息。

(AST格式)

图19至图21是示出了AST元数据格式的实例的示图。

ApplicationList元素是根元素并且是应用元素和ApplicationReference元素的上级元素。

在应用元素中指定与应用有关的信息。应用元素是appName元素、applicationIdentifier元素、applicationDescriptor元素、applicationUsageDescriptor元素、applicationBoundary元素、applicationTransport元素、applicationLocation元素、以及applicationSpecificDescriptor元素的上级元素。

AppName元素是语言属性的上级元素，并且在appName元素中指定应用名。ApplicationIdentifier元素是orgID元素和appID元素的上级元素，并且在applicationIdentifier元素中指定应用的应用ID。

ApplicationDescriptor元素是类型元素、控制码元素、可视性元素、serviceBound元素、优先级元素、版本元素、图标元素、以及storageCapabilities元素的上级元素，并且指定与对象的应用特性有关的信息。

ApplicationUsageDescriptor元素是ApplicationUsage元素的上级元素，并且指定与应用使用类型有关的信息。在applicationBoundary元素中指定与应用边界有关的信息。在applicationTransport元素中指定与应用传输协议有关的信息。

在HTTP传输类型的情况下，提供URLBase元素和URLExtension元素，并且指定URL。在URLExtension元素中指定扩展URL。此外，在ROUTE传输类型的情况下，提供atsc:ROUTESessionInfo元素(包含LCTSession元素、tsi属性、以及plpID属性)、broadcastStreamId属性、plpID属性、sourceIpAddress属性、destinationIpAddress属性、以及destinationPort属性，并且指定与ROUTE会话有关的信息。

在applicationLocation元素中指定应用位置信息。在applicationSpecificDescriptor元素中提供应用描述符。对于该描述符，选择性地提供对应于DVB(数字视频广播)的dvbDescriptor、对应于HTML(超文本标记语言)的htmlDescriptor、对应于ATSC的atscDescriptor、或者对应于其他标准的otherDescriptor。

Atsc:atscDescriptor元素是配额域属性、尺寸元素、requiredCapabilities元素、图标元素、ApplicationRecordingDescriptor元素、timeSlotInfo元素、contentLinkage元素、contentItem元素、以及graphicConstraintsDescriptor的上级元素，并且指定与ATSC(ATSC 3.0)有关的信息。

在配额域属性中指定包含对象应用的服务所属的缓存配额域的配额域标识符。在属于相同的缓存配额域的服务中共享缓存在本地存储器中的资源(文件)。

然而，应当注意的是，图标元素包括文件名属性、尺寸属性、以及aspectRatio属性。另外，ApplicationRecordingDescriptor元素包括scheduled_recording_flag元素、trick_mode_aware_flag元素、time_shift_flag元素、dynamic_flag元素、av_synced_flag元素、initiating_replay_flag元素、以及storage_properties元素。此外，timeSlotInfo元素包括timeslot_type元素、timeslot_start元素、timeslot_length元素、acquisition_time元素、以及repeat_period元素。

另外，contentItem元素包括位置属性、contentLinkage属性、updatesAvailable属性、尺寸属性、以及timeSlotInfo元素。该timeSlotInfo元素包括timeslot_type元素、timeslot_start元素、timeslot_length元素、acquisition_time元素、以及repeat_period元素。GraphicConstraintsDescriptor元素包括can_run_without_visible_ui元素、handles_configuration_changed元素、handles_externally_controlled_video元素、graphics_configuration_byte元素、以及screenPosition元素。

应注意，如参照图15至图21描述的SLT元数据、USBD元数据、S-TSID元数据、以及AST元数据的格式仅是实例，并且例如可以使用通过添加其他元素和属性而部分改变的格式。另外，SLT元数据、USBD元数据、S-TSID元数据、以及AST元数据不限于XML格式并且可以用其他标记语言书写或者可以用章节格式书写。

另外，一种元数据或者多种元数据可以包括配额域标识符，其中，由通过扩展SLT元数据、USBD元数据、S-TSID元数据、AST元数据等的信令而添加的配额域属性指定配额域标识符。另外，在提供多个服务的情况下，将由配额域属性指定的配额域标识符写入各种元数据，每个服务一种。此外，尽管在上述元数据格式实例中的每一个中，描述了一个实例，在该实例中，配额域标识符由配额域属性指定，配额域标识符不必通过属性指定并且可以通过例如写成文本的元素或信息来指定。

<5.每个装置的配置>

接下来将参照图22至图25对图1中描述的传输系统1中的接收侧上的Ad/DASH服务器10、广播服务器20、通信服务器30、以及客户端装置40的配置进行描述。

(Ad/DASH服务器的配置)

图22是示出了在图1中描述的Ad/DASH服务器10的配置实例的示图。

在图22中，Ad/DASH服务器10包括接收部101、Ad/DASH片段生成部102、脚本应用生成部103、MPD生成部104、处理部105、以及传输部106。

接收部101例如从外部服务器(未描述)接收流式传送数据并且将数据提供至Ad/DASH片段生成部102、脚本应用生成部103、以及MPD生成部104。

Ad/DASH片段生成部102基于从接收部101提供的数据生成广告片段和DASH片段并且将片段提供至处理部105。

在此，广告片段是通过处理广告内容获得的片段文件。另外，DASH片段是通过处理经由传输信道或通信电路从广播站发送的实况内容(例如，实况广播节目，诸如，现场体育消息广播)或者累积在存储器中的记录内容(例如，预先记录的节目，诸如戏剧)获得的片段文件。可以说，广告片段也是一种DASH片段。然而，为了描述，将通过在广告片段与DASH片段之间进行区分来描述。

脚本应用生成部103基于从接收部101提供的数据生成脚本应用并且将数据提供至处理部105。在此，脚本应用是可以执行脚本的应用。该脚本应用可以是使用标记语言(诸如HTML5)开发的应用或使用脚本语言(诸如Java脚本(注册商标))开发的应用。

MPD生成部104基于从接收部101提供的数据生成MPD元数据并且将MPD元数据提供至处理部105。在此，尽管将适合于内容(诸如，节目或广告)的周期元素写入MPD元数据中，但随后将对其详细内容进行描述。

处理部105对从Ad/DASH片段生成部102提供的广告片段和DASH片段、从脚本应用生成部103提供的脚本应用、以及从MPD生成部104提供的MPD元数据执行必要处理，并且将数据提供至传输部106。

传输部106将从处理部105提供的数据发送至广播服务器20或通信服务器30。应当注意的是，在此，在广告片段和DASH片段的数据(文件)、脚本应用、以及MPD元数据中，将经由广播传送的数据发送至广播服务器20并且将经由通信传送的数据发送至通信服务器30。

Ad/DASH服务器10按上述配置。

(广播服务器的配置)

图23是示出了在图1中描述的广播服务器20的配置实例的示图。

在图23中，广播服务器20包括接收部201、信令产生部202、处理部203、以及传输部204。

接收部201接收从Ad/DASH服务器10发送的广告片段和DASH片段、脚本应用、以及MPD元数据并且将它们提供至处理部203。然而，应当注意的是，在此，不是所有的广告片段和DASH片段、脚本应用、以及MPD元数据必需从Ad/DASH服务器10提供，而是只有经由广播传送的数据(文件)被提供至接收部201并且由该接收部接收。

另外，接收部201从外部服务器(未描述)接收NRT内容数据(文件)并且将其提供至处理部203。

信令生成部202生成信令并且将其提供至处理部203。在此，信令包括LLS信令(诸如，SLT元数据)和SLS信令(诸如，USBD元数据、S-TSID元数据、以及AST元数据)。另外，在多个服务中共享资源(文件)的情况下，在SLT元数据、USBD元数据、S-TSID元数据或AST元数据中定义的配额域属性中指定对象缓存配额域的配额域标识符。

处理部203对从接收部201提供的广告片段和DASH片段、脚本应用、MPD元数据、以及NRT内容和从信令生成部202提供的信令执行必要的处理并且将数据提供至传输部204。在此，例如，执行生成在有效载荷中包含含有广告片段和DASH片段、脚本应用、NRT内容、以及SLS信令(例如，USBD元数据和MPD元数据)的LCT会话数据的IP/UDP数据包和在有效载荷中包含LLS信令(例如，SLT元数据)数据的IP/UDP数据包的处理。

传输部204针对从处理部203提供的数据经由传输信道80使用天线211发送(广播)广播波(数字广播信号)。

广播服务器20的配置如上所述。

(通信服务器的配置)

图24是示出了在图1中描述的通信服务器30的配置实例的示图。

在图24中，通信服务器30包括接收部301、周期文件生成部302、处理部303、以及通信部304。

接收部301接收从Ad/DASH服务器10发送的广告片段和DASH片段、脚本应用、以及MPD元数据并且将它们提供至处理部303。然而，应当注意的是，在此，不是所有的广告片段和DASH片段、脚本应用、以及MPD元数据必需从Ad/DASH服务器10提供，而是只有经由通信传送的数据(文件)被提供至接收部301并且由该接收部接收。

处理部303响应于由通信部304接收的来自客户端装置40的请求(XLink解析请求)而处理从接收部301提供的数据，并且将所得到的数据提供至通信部304。通信部304响应于来自客户端装置40的请求经由互联网90发送从处理部303提供的发给客户端装置40(数据的请求者)的数据(广告片段和DASH片段、脚本应用、以及MPD元数据中的至少一种)。

处理部303响应于来自从通信部304接收的来自客户端装置40的请求，而请求周期文件生成部302生成周期文件。周期文件生成部302响应于来自处理部303的请求生成周期文件，该周期文件包含适合使用客户端装置40的用户(用户的特征)的周期元素，并且周期文件生成部302将周期文件提供至处理部303。

处理部303处理从周期文件生成部302提供的周期文件并且将文件提供给通信部304。通信部304经由互联网90发送从处理部303提供的发给客户端装置40(XLink解析请求的请求者)的周期文件。

通信服务器30的配置如上所述。

(客户端装置的配置)

图25是示出了在图1中描述的客户端装置40的配置实例的示图。

在图25中，客户端装置40包括控制部401、接收部402、广播中间件403、本地缓存404、浏览器405、输出部406、以及通信部407。

控制部401控制客户端装置40的各个部分的操作。

接收部402经由传输信道80使用天线411接收并且处理从广播服务器20发送(广播)的广播波(数字广播信号)并且将从其中获取的数据提供至广播中间件403。应注意，例如，接收部402包括调谐器。

广播中间件403处理从接收部402提供的数据并且将所处理的数据提供至控制部401和本地缓存404。在此，在要被处理的数据中，将广告片段和DASH片段、脚本应用、以及MPD元数据提供至本地缓存404。另外，将信令提供至控制部401。

控制部401包括缓存控制部401A和再现控制部401B。缓存控制部401A基于从广播中间件403提供的信令、来自浏览器405的请求等等控制本地缓存404。另外，再现控制部401B基于从广播中间件403提供的信令等控制浏览器405。

例如，在存储器、固态存储器(Solid State Drive)或者其他本地文件系统中实现本地缓存404。

本地缓存404在缓存控制部401A的控制之下缓存从广播中间件403提供的数据(文件)。将诸如广告片段和DASH片段、脚本应用、以及MPD元数据的数据缓存到本地缓存404中。另外，本地缓存404包括正常缓存404A和持久高速缓存404B。

在此，正常缓存404A是正常缓存，并且在经过适当的时间长度(不是那么长的时期)之后删除其中的高速缓存的数据。另一方面，持久高速缓存404B是特殊的缓存，并且其中高速缓存的数据优先持续性并且比在正常缓存404A中缓存的数据还要保持缓存更长的时段。

在来自广播中间件403的信令(在信令中包含的SLT元数据、USBD元数据、S-TSID元数据、或AST元数据中定义了配额域属性)中指定(缓存配额域的)配额域标识符的情况下，并且当浏览器405(浏览器405的脚本执行部405A)请求将对象广告片段和DASH片段等引入到持久高速缓存404B中时，缓存控制部401A将目标广告片段和DASH片段等(其文件)引入到持久高速缓存404B。

因此，通过配额域标识符链接缓存在持久高速缓存404B中的一组文件，诸如，广告片段和DASH片段。因此，在属于相同的缓存配额域的多个服务中共享诸如广告片段和DASH片段的文件。

浏览器405是支持HTML5、Java脚本(注册商标)等的浏览器。浏览器405在再现控制部401B的控制之下处理从本地缓存404读取的数据(文件)。浏览器405包括脚本执行部405A和DASH客户端405B。

脚本执行部405A可执行用脚本语言(诸如Java脚本(注册商标))书写的脚本。例如，脚本执行部405A可以从本地缓存404(正常缓存404A或其持久高速缓存404B)读取脚本应用并且执行应用。

另外，脚本执行部405A通过执行写在脚本应用中的高速缓存API(应用程序接口)使得缓存控制部401A控制本地缓存404。应注意，随后将描述该高速缓存API的详细内容。此外，脚本执行部405A响应于来自DASH客户端405B的XLink解析请求生成匹配用户偏好等的周期文件，并且将文件发送至DASH客户端405B作为响应。

DASH客户端405B从本地缓存404(其正常缓存404A)读取MPD元数据(其文件)并且解析MPD元数据(分析其语法)。根据MPD元数据的分析结果，DASH客户端405B从本地缓存404(其正常缓存404A或持久高速缓存404B)读取广告片段或DASH片段(其文件)并且再现片段。

将通过DASH客户端405B再现的广告片段或DASH片段的数据提供至输出部406。输出部406在再现控制部401B的控制之下输出从DASH客户端405B提供的数据。因此，再现广播节目、广告、或其他内容，并且输出其视频和音频。

通信部407在控制部401的控制之下经由互联网90与通信服务器30交换数据。在由通信部407接收的数据中，将广告片段和DASH片段、脚本应用、以及MPD元数据提供至本地缓存404。另外，将信令提供至控制部401。对经由通信获取的这些数据执行的处理与经由广播获取的数据的上述处理相似。因此，在此省略其描述。

客户端装置40的配置如上所述。

<6.每个装置执行的处理流程>

接下来，将参照在图26至图28中描述的流程图，对由在图1中描述的传输系统1的每个装置处理的处理流程进行描述。

(传输侧的处理流程)

接下来，将首先参照在图26描述的流程图，对由Ad/DASH服务器10、广播服务器20、以及通信服务器30在传输侧执行的处理流程进行描述。

应当注意的是，在图26中，由Ad/DASH服务器10执行从步骤S101至步骤S106的处理，由广播服务器20执行从步骤S201至步骤S205的处理，并且由通信服务器30执行在步骤S301和S302中的处理。

在步骤S101中，Ad/DASH服务器10的Ad/DASH片段生成部102生成广告片段和DASH片段。另外，在步骤S102中，Ad/DASH服务器10的传输部106将通过在步骤S101中的处理生成的广告片段和DASH片段发送至广播服务器20。

在此，广告片段是通过处理广告内容获得的片段文件。另外，DASH片段是通过处理广播节目内容获得的片段文件。出于描述的原因，在此将对广告片段和DASH片段同时生成的情况进行描述。然而，可以在不同的时间生成这些片段。

在步骤S201中，广播服务器20的信令生成部202生成信令。在步骤S202中，广播服务器20的传输部204经由传输信道80发送(广播)由步骤S201中的处理生成的信令。

在此，生成LLS信令(诸如，SLT元数据)和SLS信令(诸如，USBD元数据)作为信令。另外，在多个服务中共享资源(文件)的情况下，在SLT元数据、USBD元数据、S-TSID元数据或AST元数据中定义的配额域属性中指定对象缓存配额域的配额域标识符。

另外，在广播服务器20中，由接收部201接收通过在步骤S202中的处理发送的广告片段和DASH片段。然后，在步骤S203中，广播服务器20的传输部204经由传输信道80发送(广播)通过Ad/DASH服务器10生成的广告片段和DASH片段。

在步骤S103中，Ad/DASH服务器10的脚本应用生成部103生成脚本应用。在步骤S104中，Ad/DASH服务器10的传输部106将通过在步骤S103中的处理生成的脚本应用发送至广播服务器20。

在广播服务器20中，由接收部201接收通过在步骤S104中的处理发送的脚本应用。然后，在步骤S204中，广播服务器20的传输部204经由传输信道80发送(广播)通过Ad/DASH服务器10生成的脚本应用。

在步骤S105中，Ad/DASH服务器10的MPD生成部104生成MPD元数据。在步骤S106中，Ad/DASH服务器10的传输部106将通过在步骤S105中的处理生成的MPD元数据发送至广播服务器20。

在此，将广播节目和广告的周期元素写在MPD元数据中。在广告的周期元素中，例如，写入URL“urn:atsc:ad-insertion:abc:1234”作为xlink:href属性。然而，应当注意的是，在该URL中的“urn:atsc:ad-insertion”指示必须对本地(由客户端装置40)执行的脚本(脚本应用)发出请求以解析广告插入控制。

即，根据MPEG-DASH规则，通过将由以正常“http:”开始的字符串组成的URL写入MPD元数据中的周期元素的xlink:href属性中，客户端装置40在由该“http:···”指定的互联网90上查询通信服务器30。然后，客户端装置40从通信服务器30接收周期文件作为响应并且基于周期文件中包含的周期元素的内容再现广告内容(广告片段)。

在该实例中，另一方面，将由以“urn:atsc:ad-insertion”开始的字符串组成的URN(统一资源名称)而不是以“http:”开始的字符串组成的URL写入MPD元数据的周期元素的xlink:href属性中。因此，在MPD元数据的解析(分析语法)过程中，在客户端装置40中检测到其中具有指定以“urn:atsc:ad-insertion”开始的字符串的xlink:href属性的周期元素的情况下，将事件而不是HTTP请求发布至同时执行的脚本应用以提示XLink解析(周期元素解析)。

应注意，尽管在这个实施例中将主要描述这种情况，即，在MPD元数据中的周期元素的xlink:href属性中指定由以“urn:atsc:ad-insertion”开始的字符串组成的URN，如上所述指定诸如“http://adservice.com/adp-1？user＝$groupID$”的URL，使得由groupID指定特定用户。

在广播服务器20中，由接收部201接收通过在步骤S106中的处理发送的MPD元数据。然后，在步骤S205中，广播服务器20的传输部204经由传输信道80发送(广播)通过Ad/DASH服务器10生成的MPD元数据。

应当注意的是，为了描述，在步骤S202至步骤S205中，描述了假定在不同时间发送信令、广告片段和DASH片段、脚本应用、以及MPD元数据，则发送广播流中包含的这些数据。

在通信服务器30中，由通信部304接收经由互联网90从客户端装置40发送的XLink解析请求。然后，在步骤S301中，通信服务器30的周期文件生成部302生成周期文件。在步骤S302中，通信服务器30的通信部304经由互联网90发送通过在步骤S301中的处理生成的发给客户端装置40(XLink解析请求的发送者)的周期文件。

应注意，如上所述，XLink解析请求被从客户端装置40发送至通信服务器30，其中将由以“http:”开始的字符串组成的URL写入MPD元数据中的周期元素的xlink:href属性中。

至此，已描述了传输侧的处理流程。

(接收侧的处理流程)

接下来将参照在图27和图28中描述的流程图对接收侧上的客户端装置40执行的处理流程进行描述。

应当注意的是，在图27和图28中，由广播中间件403执行从步骤S401至步骤S408的处理，并且由控制本地缓存404(正常缓存404A或持久高速缓存404B)的缓存控制部401A执行从步骤S421至步骤S423的处理和从步骤S441至步骤S443的处理。另外，由浏览器405的脚本执行部405A执行从步骤S461至步骤S466的处理，并且由浏览器405的DASH客户端405B执行从步骤S481至步骤S490的处理。

在步骤S401中，广播中间件403经由接收部402接收经由传输信道80从广播服务器20发送的信令。在步骤S402中，广播中间件403处理通过在步骤S401中的处理接收的信令。

在此，将LLS信令(诸如，SLT元数据)和SLS信令(诸如，USBD元数据)处理作为信令。另外，在多个服务中共享资源(文件)的情况下，在SLT元数据、USBD元数据、S-TSID元数据、或AST元数据中定义的配额域属性中指定对象缓存配额域的配额域标识符，从而使得能够识别属于该缓存配额域的服务。

在步骤S403中，广播中间件403经由接收部402接收经由传输信道80从广播服务器20发送的广告片段和DASH片段。在步骤S404中，广播中间件403将通过在步骤S403中的处理接收的广告片段和DASH片段传输至本地缓存404。

在步骤S421中，缓存控制部401A将通过在步骤S404中的处理传输的广告片段和DASH片段(其文件)缓存到本地缓存404的正常缓存404A中。

在这种情况下，将广告片段和DASH片段(其文件)缓存在正常缓存404A中。因此，如果该情况继续，则在经过适当的时间长度(不是那么长的时期)之后删除这些片段。另外，尽管这里出于描述的原因，描述了同时缓存广告片段和DASH片段(其文件)的情况，但可以在不同的时间缓存这些片段(其文件)。

在步骤S405中，广播中间件403经由接收部402接收经由传输信道80从广播服务器20发送的脚本应用。在步骤S406中，广播中间件403将通过在步骤S405中的处理接收的脚本应用传输至本地缓存404。

在步骤S422中，缓存控制部401A将通过在步骤S406中的处理传输的脚本应用缓存在本地缓存404的正常缓存404A中。在这种情况下，将脚本应用缓存在正常缓存404A中。因此，如果该情况继续，则在经过适当的时间量(不是那么长的时期)之后删除脚本应用。

在步骤S461中，脚本执行部405A通过在步骤S422中的处理从本地缓存404获取缓存在正常缓存404A中的脚本应用并且执行脚本应用。

在步骤S462中，脚本执行部405A响应于脚本应用的执行，请求缓存控制部401A将广告片段引入持久高速缓存404B(在步骤S461中的处理)。

在此，例如，由于执行写入到脚本应用中的以下高速缓存API，进行将广告片段引入(pull，拉入)到持久高速缓存404B的指令：

Interface Cache{

Promise<void>fetchPeriod(xmlElement)；

}

然而，应当注意的是，在以上的API中，fetchPeriod步骤用于指示进行引入到持久高速缓存404B中。另外，由写入xmlElement指定的周期元素中的片段URL指定的片段文件(广告片段文件)，(fetchPeriod步骤的引证)是存储在持久高速缓存404B中的文件。

另外，可以将以下高速缓存API写入脚本应用中：

Interface Cache{

Promise<void>fetchFile(url)；

}

然而，应当注意的是，在以上的API中，fetchFile步骤用于指示进行引入到持久高速缓存404B中。另外，由url指定的片段文件(广告片段文件)(fetchFile步骤的引证)是存储在持久高速缓存404B中的文件。

在步骤S441中，缓存控制部401A响应于通过在步骤S462中的处理作出的引入请求将广告片段(其文件)(潜在插入片段)从本地缓存404的正常缓存404A引入到持久高速缓存404B中。因此，将从正常缓存404A拖动的广告片段(其文件)缓存在本地缓存404的持久高速缓存404B中(S442)。

即，在通过广播中间件403终止ROUTE协议之后，将经由传输信道80通过广播的方式传送的一组文件加载到本地缓存404的正常缓存404A中(HTTP代理缓存(文件系统))，并且在经过适当的时间量(不是那么长的时期)之后删除。在此，例如，通过在ROUTE实体模式下进行文件传输等时添加的HTTP报头中写入的缓存到期时间确定的时间量经过之后，删除文件。

另一方面，本地缓存404的持久高速缓存404B是视为HTTP代理缓存的特殊区域的缓存。即，加载到持久高速缓存404B中的一组文件比缓存在正常缓存404A中的一组其他文件具有更优先的持续性。此外，即使在经过以上“适当的时间量”之后文件也不会被删除并且仍被缓存直到达到分配给本地缓存404的配额为止

然后，通过在SLT元数据、USBD元数据、S-TSID元数据、或AST元数据中定义的配额域属性指定的配额域标识符将缓存在持久高速缓存404B中的该组文件所属的服务链接。因此，在属于相同的缓存配额域的多个服务中共享特定文件(该实例中的广告片段文件)。

在步骤S407中，广播中间件403经由接收部402接收经由传输信道80从广播服务器20发送的MPD元数据。在步骤S408中，广播中间件403将通过在步骤S407中的处理接收的MPD元数据传输至本地缓存404。

在步骤S423中，缓存控制部401A将通过在步骤S408中的处理传输的MPD元数据缓存在本地缓存404的正常缓存404A中。在这种情况下，将MPD元数据缓存在正常缓存404A中。因此，在经过适当量的时间(不是那么长的时期)之后删除MPD元数据。

在步骤S481中，DASH客户端405B从本地缓存404获取通过在步骤S423中的处理缓存在正常缓存404A中的MPD元数据并且解析MPD元数据(分析其语法)。

在步骤S482中，DASH客户端405B从本地缓存404获取响应于在步骤S402或S481中的处理结果(SLT、USBD、S-TSID、MPD、或其他元数据的处理结果)获得的DASH片段并且缓存在正常缓存404A中。在步骤S483中，DASH客户端405B在再现控制部401B的控制之下再现通过在步骤S482中的处理获得的DASH片段。因此，在客户端装置40中再现广播节目内容。

在步骤S484中，DASH客户端405B确定是否插入广告。在步骤S484中确定未插入广告的情况下，处理返回至步骤S482，并且重复从步骤S482至步骤S484的处理。在这种情况下，广播节目内容的再现继续。另一方面，在步骤S484中确定插入了广告的情况下，处理进行至步骤S485。

在步骤S485中，DASH客户端405B响应于在步骤S481中的处理结果请求脚本执行部405A解析MPD元数据中包含的XLink。

然而，应当注意的是，在从通过在步骤S481中的处理由MPD元数据的周期元素的xlink:href属性指定的URL中检测到由以“urn:atsc:ad-insertion”为开始的字符串组成的URN的情况下，同时向由脚本执行部405A执行的脚本应用发布事件以提示XLink解析(周期元素解析)。

在步骤S463中，脚本执行部405A响应于通过在步骤S485中的处理进行的XLink解析请求而使用执行的脚本应用的脚本中的逻辑获取用户偏好。然后，在步骤S464中，脚本执行部405A基于由在步骤S463中的处理获得的用户偏好生成周期文件。

在此，脚本执行部405A基于由来自DASH客户端405B的事件通知的URL(例如，URL，诸如“urn:atsc:ad-insertion:abc:1234”)生成周期文件，该周期文件包括要被插入到MPD元数据中的周期元素。应注意，例如，PDI(偏好人口统计和兴趣)可以用作用户偏好。该PDI是通过生成指示用户对由特定服务器提供的问题的答案的信息，来确保仅再现(累积)匹配用户偏好的内容的机制。

在步骤S465中，脚本执行部405A将通过在步骤S464中的处理生成的周期文件发送到DASH客户端405B作为响应。

应注意，在由以“http:”开始的字符串组成的URL(例如，URL，诸如，“http://adservice.com/adp-1？user＝$groupID$”)写入MPD元数据中的周期元素的xlink:href属性中的情况下，将XLink解析请求经由互联网90发送至通信服务器30，如通过图中的虚线(虚线“5”)描述的。然后，如通过图中的虚线(虚线“6”)描述的，获得适于从通信服务器30发送的XLink解析请求的周期文件。

在步骤S486中，DASH客户端405B获取作为响应通过在步骤S465中的处理发送的周期文件并且解析周期文件(分析其语法)。

在步骤S487中，DASH客户端405B响应于在步骤S486中的处理结果获取缓存到本地缓存404的持久高速缓存404B中的广告片段。在此，通过在步骤S486中的处理获得对象广告片段的URL，作为周期元素的解析结果，并且根据URL获得持久高速缓存404B中的广告片段。然后，该广告片段的文件是在属于相同的缓存配额域的多个服务中共享的文件。因此，可以重复使用广告片段文件。

在步骤S488中，DASH客户端405B在再现控制部401B的控制之下再现通过在步骤S487中的处理获得的广告片段。因此，在客户端装置40中，将要再现的内容从广播节目切换至广告(插入广告)。

在步骤S489中，DASH客户端405B确定是否完成广告片段的再现(在步骤S488中的处理)。在步骤S489中确定广告片段再现还有待于完成的情况下，处理返回至步骤S488，并且广告片段再现继续。

另一方面，在步骤S489中确定广告片段再现完成的情况下，处理进行至步骤S490。在步骤S490中，DASH客户端405B通知脚本执行部405A广告片段再现完成。

在步骤S466中，脚本执行部405A响应于有关在步骤S490中广告片段再现完成的通知，使用正在执行的脚本应用请求缓存控制部401A从持久高速缓存404B删除再现完成的广告片段。

在此，例如，通过执行写入脚本应用中的以下高速缓存API，作出从持久高速缓存404B删除广告片段的指令：

Interface Cache{

Promise<void>deleteFile(url)；

}

然而，应当注意的是，在以上的API中，deleteFile步骤用于指示进行从持久高速缓存404B中删除。另外，由url指定的片段文件(广告片段文件)(删除文件方法的引证)是从持久高速缓存404B中删除的文件。

在步骤S443中，缓存控制部401A响应于通过在步骤S466中的处理作出的删除请求而从本地缓存404的持久高速缓存404B中删除再现完成的广告片段(其文件)。应当注意的是，在客户端装置40中，当广告片段再现结束时，将要再现的内容从广告切换至广播节目。

至此，已描述了接收侧的处理流程。

<7.变形例>

尽管，在以上描述中，描述了例如在美国采用的方案ATSC(具体地，ATSC 3.0)作为数字广播标准，但本技术可以应用于例如在日本和DVB(数字视频广播)采用的方案ISDB(综合服务数字广播)、在欧洲国家采用的方案等等。另外，尽管，在以上描述中已通过引用采用IP传输方案的ATSC 3.0作为实例进行了描述，但本技术所应用的传输方案不限于IP传输方案，并且本技术可以应用于诸如MPEG2-TS(传输流)的其他方案。

另外，在数字广播中，本技术不仅可适用于地面广播和卫星广播(诸如广播卫星(BS)和通信卫星(CS))而且还可适用于有线广播诸如有线电视(CATV)。

另外，上述域和信令名仅是实例，并且存在可以使用其他名称的情况。然而，应当注意的是，名称上的这些差异是形式上的差异，对象域或信令的实质内容是不存在差异的。例如，缓存配额域可以称为其他名称诸如具有类似的微小差别的缓存配额组。另外，例如，AST(应用信令表)可被称为AIT(应用信息表)等等，并且NRT(非时实)可称为LCC(本地缓存的内容)。此外，在用诸如XML的标记语言书写信令的情况下，其元素和属性的名称仅是示例性的，可以使用其他名称。然而，应当注意的是，名称上的这些差异是形式上的差异，其元素和属性的实质内容是不存在差异的。

另外，尽管在以上描述中，将SLT元数据描述为LLS信令，诸如EAT(紧急警告表)和RRT(区域等级表)的元数据可以包括在LLS信令中。EAT元数据包括与必须紧急通知的紧急信息有关的信息。RRT元数据包括与等级有关的信息。

应注意，应用不限于使用标记语言(诸如，HTML5)或脚本语言(诸如，Java脚本(注册商标))开发的那些应用并且可以是使用诸如Java(注册商标)的程序设计语言开发的应用。另外，除视频和广告之外的任何内容(诸如，电子书、游戏、以及音乐)可以包括在上述内容中。

另外，本技术可应用于在除广播网络以外的传输信道(即，诸如互联网和电话网的通信线(通信网络))用作传输信道的前提下指定的给定标准(除广播标准以外的标准)。

<8.计算机的配置>

如上所述的一系列处理可通过硬件或者软件执行。在通过软件执行一系列处理的情况下，将组成软件的程序安装到计算机中。图29是示出了使用程序执行以上一系列处理的计算机的硬件结构实例的示图。

在计算机1000中，CPU(中央处理单元)1001、ROM(只读存储器)1002和RAM(随机存取存储器)1003通过总线1004彼此连接。输入/输出(I/O)接口1005进一步连接到总线1004。将输入部1006、输出部1007、记录部1008、通信部1009、以及驱动器1010连接到I/O接口1005。

输入部1006包括键盘、鼠标、麦克风等等。输出部1007包括显示器、扬声器等等。记录部1008包括硬盘、非易失性存储器等等。通信部1009包括网络接口等等。驱动器1010驱动可移动介质1011，诸如磁盘、光盘、磁光盘或半导体存储器。

在如上所述配置的计算机1000中，当CPU 1001经由I/O接口1005和总线1004将例如记录在ROM 1002或记录部1008中的程序加载到RAM1003中用以执行时，执行以上一系列处理。

例如，可将由计算机1000(CPU 1001)执行的程序提供记录到可移除介质1011中作为封装介质等。可替代地，可以经由诸如局域网、因特网以及数字卫星广播等有线或者无线传输介质来提供程序。

在计算机1000中，由于可移除介质1011被插入到驱动器1010中，因此可经由I/O接口1005将程序安装到记录部1008中。可替换地，可由通信部1009经由有线或无线传输介质接收程序并安装在记录部1008中。除以上所述之外，可提前将程序安装至ROM 1002或记录部1008。

在此，在本说明中，不必根据作为流程图描述的顺序按序执行由计算机根据程序执行的处理。即，由计算机根据程序执行的处理包括并行执行或者单独执行的那些处理(例如，并行处理或基于对象的处理)。此外，可通过单个计算机(处理器)或者分布式的多个计算机处理程序。

应注意的是，本技术的实施方式不限于上述那些实施方式，并且只要不背离本技术的主旨，就可以各种各样的方式修改这些实施方式。

应指出，本技术可具有以下配置：

(1)一种接收装置，包括：

接收部，适于接收内容；以及

控制部，适于基于与内容一起传输的并且包括指示是否在多个服务中共享内容的资源的资源共享信息的控制信息，控制资源在存储装置中的存储，使得在多个服务中共享资源。

(2)根据项(1)所述的接收装置，其中，

在控制信息中包括的资源共享信息指示在多个服务中共享资源的情况下，控制部以将共享资源与其他资源区分开的方式存储共享的共享资源。

(3)根据项(1)或(2)所述的接收装置，其中，

由广播波传输内容和控制信息，

服务是数字广播服务，并且

控制信息是用于提供服务的信令。

(4)根据项(3)所述的接收装置，其中，

信令是允许对多个服务的属性进行指定的第一信令，并且

第一信令包括以服务为单位指定的资源共享信息。

(5)根据项(3)所述的接收装置，其中，

信令是允许对每个服务的属性进行指定的第二信令，并且

第二信令包括在对象服务内的给定单元中指定的资源共享信息。

(6)根据项(5)所述的接收装置，其中，

以服务为单位、以会话为单位、或者以应用为单位指定资源共享信息。

(7)根据项(2)至(6)中任一项所述的接收装置，其中，

内容资源是给定形式的文件，并且

控制部响应于与内容一起传输的应用的操作，将共享资源文件存储在与存储其他资源文件的第一存储区不同的第二存储区中。

(8)根据项(7)所述的接收装置，其中，

控制部响应于应用的操作而删除存储在第二存储区中的共享资源文件。

(9)根据项(3)至(8)中任一项所述的接收装置，其中，

广播波是符合IP(互联网协议)传输方案的广播波，并且

将内容资源文件的数据放到包括UDP(用户数据报协议)数据包的IP数据包中并且传输。

(10)根据项(1)至(9)中任一项所述的接收装置，其中，

内容包括广告内容，并且

资源共享信息是用于识别共享广告内容的资源的多个服务所属的组的识别信息。

(11)一种接收装置的数据处理方法，数据处理方法包括：

接收装置接收内容并且基于与内容一起传输的并且包括指示是否在多个服务中共享内容的资源的资源共享信息的控制信息，控制资源在存储装置中的存储，以使得在多个服务中共享资源的步骤。

(12)一种发送装置，包括：

生成部，适于生成包括指示是否在多个服务中共享内容的资源的资源共享信息的控制信息；以及

传输部，适于将控制信息与内容一起发送。

(13)根据项(12)所述的发送装置，其中，

由广播波传输内容和控制信息，

服务是是数字广播服务，并且

控制信息是用于提供服务的信令。

(14)根据项(13)所述的发送装置，其中，

信令是允许对多个服务的属性进行指定的第一信令，并且

第一信令包括以服务为单位指定的资源共享信息。

(15)根据项13)所述的发送装置，其中，

信令是允许对每个服务的属性进行指定的第二信令，并且

第二信令包括在对象服务内的给定单元中指定的资源分配信息。

(16)根据项(15)所述的发送装置，其中，

(17)根据项(12)至(16)中的任一项所述的发送装置，其中，

内容资源是给定形式的文件。

(18)根据项(13)至(17)中任一项所述的发送装置，其中，

广播波是符合IP传输方案的广播波，并且

将内容资源文件的数据放到包括UDP数据包的IP数据包中并且传输。

(19)根据项(12)至(18)中任一项所述的发送装置，其中，

内容包括广告内容，并且

(20)一种发送装置的数据处理方法，数据处理方法包括：

发送装置生成包括指示是否在多个服务中共享内容的资源的资源共享信息的控制信息并且将控制信息与内容一起发送的步骤。

[参考符号列表]

1传输系统、10 Ad/DASH服务器、20广播服务器、30通信服务器、40客户端装置、80传输信道、90互联网、101接收部、102 Ad/DASH片段生成部、103脚本应用生成部、104 MPD生成部、105处理部、106传输部、201接收部、202信令生成部、203处理部、204传输部、301接收部、302周期文件生成部、303处理部、304通信部、401控制部、401A缓存控制部、401B再现控制部、402接收部、403广播中间件、404本地缓存、404A正常缓存、404B持久高速缓存、405浏览器、405A脚本执行部、405B DASH客户端、406输出部、407通信部、1000计算机、1001 CPU。

Claims

1.一种接收装置，包括：

接收部，适于接收内容；以及

控制部，适于基于与所述内容一起传输的并且包括指示所述内容的资源是否在多个服务中共享的资源的资源共享信息的控制信息，来控制所述资源在存储装置中的存储，使得在多个服务中共享所述内容的资源。

2.根据权利要求1所述的接收装置，其中，

在所述控制信息中包括的所述资源共享信息指示在多个服务中共享资源的情况下，所述控制部以将共享资源与其他资源区分开的方式存储为共享的资源的共享资源。

3.根据权利要求2所述的接收装置，其中，

由广播波传输所述内容和所述控制信息，

所述服务是数字广播服务，并且

所述控制信息是用于提供所述服务的信令。

4.根据权利要求3所述的接收装置，其中，

所述信令是允许对多个服务的属性进行指定的第一信令，并且

所述第一信令包括逐个服务指定的所述资源共享信息。

5.根据权利要求3所述的接收装置，其中，

所述信令是允许对每个服务的属性进行指定的第二信令，并且

所述第二信令包括在对象服务内的给定单元中指定的所述资源共享信息。

6.根据权利要求5所述的接收装置，其中，

基于逐个服务、基于逐个会话、或者基于逐个应用指定所述资源共享信息。

7.根据权利要求3所述的接收装置，其中，

所述内容的资源是给定形式的文件，并且

所述控制部响应于与所述内容一起传输的应用的操作，将共享资源文件存储在与存储其他资源文件的第一存储区不同的第二存储区中。

8.根据权利要求7所述的接收装置，其中，

所述控制部响应于所述应用的操作，删除存储在所述第二存储区中的所述共享资源文件。

9.根据权利要求3所述的接收装置，其中，

所述广播波是符合IP(互联网协议)传输方案的广播波，并且

将所述内容的资源文件的数据放到包括UDP(用户数据报协议)数据包的IP数据包中并且传输。

10.根据权利要求1所述的接收装置，其中，

所述内容包括广告内容，并且

所述资源共享信息是用于识别共享所述广告内容的资源的多个服务所属的组的识别信息。

11.一种接收装置的数据处理方法，所述数据处理方法包括：

所述接收装置接收内容并且基于与所述内容一起传输的并且包括指示所述内容的资源是否是在多个服务中共享的资源的资源共享信息的控制信息，控制所述资源在存储装置中的存储，以使得在所述多个服务中共享所述内容的资源的步骤。

12.一种发送装置，包括：

生成部，适于生成包括指示内容的资源是否是在多个服务中共享的资源的资源共享信息的控制信息；以及

传输部，适于将所述控制信息与所述内容一起发送。

13.根据权利要求12所述的发送装置，其中，

由广播波传输所述内容和所述控制信息，

所述服务是数字广播服务，并且

所述控制信息是用于提供所述服务的信令。

14.根据权利要求13所述的发送装置，其中，

所述第一信令包括逐个服务指定的所述资源共享信息。

15.根据权利要求13所述的发送装置，其中，

16.根据权利要求15所述的发送装置，其中，

17.根据权利要求12所述的发送装置，其中，

所述内容的资源是给定形式的文件。

18.根据权利要求13所述的发送装置，其中，

所述广播波是符合IP传输方案的广播波，并且

将所述内容的资源文件的数据放到包括UDP数据包的IP数据包中并且传输。

19.根据权利要求12所述的发送装置，其中，

所述内容包括广告内容，并且

20.一种发送装置的数据处理方法，所述数据处理方法包括：

所述发送装置生成包括指示内容的资源是否是在多个服务中共享的资源的资源共享信息的控制信息并且将所述控制信息与所述内容一起发送的步骤。