接收设备、发送设备和数据处理方法与流程

本公开涉及接收设备、发送设备和数据处理方法。更具体地，本公开涉及例如经由广播波或网络进行数据接收的接收设备，例如经由广播波或网络进行数据发送的发送设备，以及用于数据通信的数据处理方法。

背景技术：

已经积极进行下述系统的开发和标准化，在该系统中，通过使用广播波等的单向通信或通过经由网络(诸如因特网等)的双向或单向通信，在提供内容的发送设备(诸如广播站或内容服务器)和接收设备(诸如电视、pc或移动终端)之间进行内容(诸如广播节目)的发送和接收。

注意，在例如专利文献1(日本专利申请公开no.2014-057227)中公开了这样的相关技术：经由广播波和网络实现数据传送的技术。

高级电视系统委员会(atsc)3.0的标准化已经作为与经由广播波和网络的数据传送系统相关的标准之一。

在atsc3.0中，用于下载类型应用传送管理的封包方案和离线应用注册/更新管理方案仍在审查中。

同时，作为万维网(www)使用技术的国际标准化组织的万维网联盟(w3c)正在开发服务工作者(sw)的规范，该规范包括用于实现便于客户端使用应用的控制程序等。

为了在客户端(广播内容的接收设备)中实现服务工作者(sw)的框架的有效使用，需要能够有效地管理传送管理(其为广播和传送的应用部分)和服务工作者(sw)。

引用列表

专利文献

专利文献1：日本专利申请公开no.2014-057227

技术实现要素：

本发明待解决的问题

本公开的目的在于提供一种接收设备、发送设备和数据处理方法，它们能够在用作广播内容接收设备的客户端中实现服务工作者(sw)框架的有效使用。

此外，具体地，本发明目的在于提供一种接收设备、发送设备和数据处理方法，它们能够使用被应用至确定处理的控制信息来实现例如传送控制，该确定处理用于确定在接收设备处是经由广播还是经由网络进行数据获取。

问题的解决方案

根据本公开的第一方面，提供了接收设备，包括数据处理单元，接收其中记录了类信息的信令数据，并且根据类信息确定是经由广播还是经由网络进行数据接收，所述类信息用于指示允许经由网络进行数据接收的一组接收设备或用户。

另外，根据本公开的第二方面，提供发送信令数据的发送设备，在该信令数据中记录了类信息，所述类信息用于指示允许经由网络进行数据接收的一组接收设备或用户。

另外，根据本公开的第三方面，

提供了在接收设备中进行的数据处理方法，该方法包括：

由通信单元接收其中记录了类信息的信令数据，所述类信息用于指示允许经由网络进行数据接收的一组接收设备或用户；和

由数据处理单元根据类信息确定是经由广播还是经由网络进行数据接收。

另外，根据本公开的第四方面，

提供了在发送设备中进行的数据处理方法，该方法包括：

发送其中记录了类信息的信令数据，所述类信息用于指示允许经由网络进行数据接收的一组接收设备或用户。

通过基于接下来描述的本公开的实施例的具体实施方式和附图，本公开的其他目的、特征和优点将变得显而易见。需注意，在本说明书中，系统是多个设备的逻辑集合配置并且不限于其中各个组件的设备在系统外壳中的配置。

本发明的效果

根据本公开的实施例的配置，实现了这种配置：接收设备可以基于信令数据确定是否允许经由网络接收数据。

具体地，例如，将用于指示允许经由网络进行数据接收的一组接收设备或用户的类标识符记录在从发送设备发送到接收设备的信令数据中。接收设备确定类标识符是否与已设置给接收设备或用户的类标识符相同，并且当类标识符彼此相同时，经由网络进行数据接收。应用于经由广播波或网络接收数据的url基本模式(basepattern)被记录在信令数据中，并且接收设备获取应用了url基本模式的数据。

根据本配置，实现了以下配置：接收设备可以基于信令数据确定是否允许经由网络的数据接收。

需注意，在本说明书中描述的效果仅仅是示例而非限于此，并且可以获得附加效果。

附图说明

图1是用于描述进行本公开的处理的通信系统的示例性配置的示图。

图2是用于描述发送设备的发送数据的示图。

图3是示出发送设备和接收设备的协议栈的示例的示图。

图4是用于描述使用服务工作者(sw)的处理的具体示例(用例)的示图。

图5是用于描述使用服务工作者(sw)的处理的具体示例(用例)的示图。

图6是用于描述使用服务工作者(sw)的处理的示例的示图。

图7是用于描述接收设备的示例性配置的示图。

图8是用于描述文件获取处理顺序的示图。

图9是用于描述文件获取处理顺序的示图。

图10是用于描述通过服务工作者(sw)对接收设备的存储单元(永久缓存)的控制处理顺序的示图。

图11是用于描述通过服务工作者(sw)对接收设备的存储单元(永久缓存)的控制处理顺序的示图。

图12是示出从发送设备发送的信令数据(元数据)的示例性配置的示图。

图13是用于描述用户业务描述(usd)的整体示例性配置的示图。

图14是示出在构成信令数据的用户业务束描述(usd)下的示例性分级配置的示图。

图15是示出在传送方法(deliverymethod)元素下的信令数据配置的示图。

图16是示出当根据flute协议进行文件传输时在传送方法(deliverymethod)元素中设置的flute的参考信息的示例的图。

图17是示出当根据flute协议进行文件传输时在传送方法(deliverymethod)元素中设置的flute的参考信息的示例的图。

图18是示出当根据route协议进行文件传输时在传送方法(deliverymethod)元素中设置的flute的参考信息的示例的图。

图19是示出当根据route协议进行文件传输时在传送方法(deliverymethod)元素中设置的flute的参考信息的示例的图。

图20是用于描述fdt-实例元素的配置的示图。

图21(a)和21(b)是分别用于描述与fdt实例对应的属性和与文件对应的属性的详细配置的示图。

图22是示出在route中规定的lsid下的数据配置的示图。

图23(a)和23(b)是分别用于描述在efdt元素单元中的属性数据元素的细节和文件单元的属性数据元素的细节的示图。

图24是示出根据传送路径的信令数据(usd)的配置和处理示例的示图。

图25是示出在传送方法(deliverymethod)元素下的信令数据配置的示图。

图26是描述用于根据传送路径进行用于接收控制的信令数据(usd)的配置和处理示例的示图。

图27是示出在构成信令数据的用户业务束描述(usd)下的示例性分级配置的示图。

图28是描述根据传送路径进行用于接收控制的信令数据(usd)的配置和处理示例的示图。

图29是描述根据传送路径进行用于接收控制的信令数据(usd)的配置和处理示例的示图。

图30是用于描述用作通信设备的发送设备和接收设备的示例性配置的示图。

图31是用于描述用作通信设备的发送设备和接收设备的示例性硬件配置的示图。

具体实施方式

以下将参照附图详细描述本公开的接收设备、发送设备和数据处理方法。需注意，将根据以下部分形成说明书。

1.通信系统的示例配置

2.数据通信协议flute和route

3.由发送设备和接收设备进行的示例性通信处理

4.服务工作者(sw)

5.接收设备中的应用的获取和执行的示例

6.接收设备中的文件获取处理顺序

7.服务工作者(sw)对接收设备的存储单元(永久缓存)的控制处理

8.使用信令数据(usd)通知数据接收路径信息的配置

9.重定向策略的控制

9.1.经由网络的传送数据获取允许示例1

9.2.经由网络的传送数据获取允许示例2

9.3.经由网络的传送数据获取允许示例3

10.发送设备和接收设备的示例配置

11.本公开的配置的结论

[1.通信系统的配置的示例]

首先，将参考图1描述进行本公开的处理的通信系统的示例性配置。

通信系统10包括发送设备20和接收设备30，该发送设备20用作发送诸如图像数据、音频数据等内容的通信设备，该接收设备30用作接收从如图1所示的发送设备20发送的内容的通信设备。

具体地，发送设备20是例如内容提供侧的设备，诸如广播站21和内容服务器22。另一方面，接收设备30是普通用户的客户端设备，具体而言，接收设备30包括例如电视31、pc32、移动终端33等。

像使用经由网络(诸如因特网)的双向通信或单向通信和经由广播波等的单向通信中的至少一个或两者的通信那样，进行发送设备20和接收设备30之间的数据通信。

例如，根据为自适应流技术的标准的mpeg-dash标准，进行从发送设备20到接收设备30的内容发送。

mpeg-dash标准包括以下两个标准：

(a)与用于描述元数据(用作运动图像或音频文件的管理信息)的清单文件(媒体呈现描述(mpd))相关的标准；和

(b)与用于运动图像内容发送的文件格式(段格式)相关的标准。

根据mpeg-dash标准进行从发送设备20到接收设备30的内容传送。

发送设备20编码内容数据并且生成包括编码数据和编码数据的元数据的数据文件。

例如，根据在mpeg中指定的mp4文件格式进行编码处理。

注意，当发送设备20生成mp4格式数据文件时，编码数据的文件被称为“mdat”，而元数据被称为“moov”、“moof”等。

由发送设备20提供至接收设备30的内容是各种数据，例如音乐数据，视频数据诸如电影、电视节目、视频，照片，文档，绘画和示图、游戏和软件。

将参考图2描述发送设备20的发送数据。

根据mpeg-dash标准进行数据传输的发送设备20发送的数据大致被分为如图2所示的多种类型的以下数据：

(a)信令数据50；

(b)av段60；和

(c)其他数据(esg、nrt内容等)70。

例如，av段60配置有在接收设备中再现的图像(视频)或音频数据，即，从广播站提供的节目内容等。例如，av段60被配置有mp4编码的数据(mdat)和元数据(moov和moof)。

另一方面，信令数据50配置有节目调度信息，诸如节目表、节目获取所需的地址信息(统一资源定位符(url)等)，包括用于诸如编解码器信息(编码方案等)等所需的信息的指南信息，以及控制信息。

在接收av段60(存储有用作再现目标的节目内容)之前，接收设备30必须接收信令数据50。

例如，信令数据50作为可扩展标记语言(xml)格式的数据被发送到作为用户设备(诸如智能电话或电视)的接收设备(客户端)。

如上所述，根据需要重复发送信令数据。

例如，以100毫秒的间隔频繁并重复地发送信令数据。

这是因为接收设备(客户端)可以在任何时间立即获取信令数据。

根据需要，客户端(接收设备)可以基于可接收的信令数据，迅速地进行接收和再现节目内容所需的处理，诸如获取必要节目内容的访问地址，编解码器设置处理等。

其他数据70包括例如电子业务指南(esg)、nrt内容等

esg是电子业务指南，例如，诸如节目表的指南信息。

nrt内容是非实时类型内容。

例如，在nrt内容中包括在用作客户端的接收设备30的浏览器上执行的数据文件，诸如各种应用文件、运动图像或静止图像。

在nrt内容中还包括用作应用的控制程序的服务工作者(稍后将描述)等。

例如根据数据通信协议—单向传输的文件传送(flute)发送图2所示的以下数据：

(a)信令数据50；

(b)av段60；和

(c)其他数据(esg、nrt内容等)70。

[2.数据通信协议flute和route]

数据通信协议flute是这样的协议：用于以多播方式进行待发送内容的会话管理。

例如，根据flute协议，将在用作发送设备的服务器侧处生成的文件(其由url和版本识别)发送到用作接收设备的客户端。

接收设备(客户端)30将所接收到的文件的url和版本以及文件彼此相关联地存储在例如接收设备(客户端)30的存储单元(客户端缓存)中。

当url相同但版本不同时，认为文件的内容被更新过。在flute协议中，仅进行单向文件传输控制，在客户端中没有文件的选择性过滤功能，但是可以通过选择文件实现选择性过滤，该文件根据客户端侧的flute使用与该文件链接的元数据经历传输控制，并配置、更新和管理反应用户偏好的本地缓存。

注意，元数据可以被扩展并合并到flute协议中，或者可以通过诸如电子业务指南(esg)的协议单独描述。

注意，flute最初就已经被标准化为多播中的文件传输协议。

flute配置有fdt和称为alc的可扩展文件对象的多播协议，具体地，作为其构建块的lct或fec组件的组合。

现有技术的flute主要被开发用于异步文件传输，并且目前flute被扩展以容易地应用于高级电视系统委员会(atsc)中的广播实况流，该高级电视系统委员会(atsc)是与经由广播波和网络的数据传送系统相关的标准化组织。

flute的扩展规范被称为通过单向传输的实时对象传送(route)。

高级电视系统委员会(atsc)3.0目前正在被标准化成与经由广播波和网络的数据传送系统相关的标准之一。atsc3.0指定了代替相关技术的flute协议的栈配置，采用route用于信令数据、esg、异步文件、同步流等的发送。

[3.由发送设备和接收设备进行的示例性通信处理]

接下来，将描述由发送设备和接收设备进行的示例性通信处理。

图3是示出发送设备和接收设备的协议栈的示例的示图。

在图3所示的示例中，示出了用于处理以下两条通信数据的两个协议栈：

(a)广播(包括多播)通信(例如，广播类型数据传送)；和

(b)单播(宽带)通信(例如，http类型p2p通信)。

图3的左侧是(a)与广播通信(例如，广播类型数据传送)对应的协议栈。

图3的右侧是(b)与单播(宽带)通信(例如，http类型p2p通信)对应的协议栈。

与(a)在图3的左侧上示出的广播通信(例如，广播类型数据传送)对应的协议栈从下层起依次具有以下层：

(1)广播物理层(广播phy)；

(2)ip多播层(ip多播)；

(3)udp层；

(4)route(＝扩展flute)层；

(5)esg、nrt内容、dash(isobmff)和视频/音频/cc；和

(6)应用层(应用(html5))。

注意，信令层被设置为在ip多播层(ip多播)之上的层(2)。

信令层是应用于上面参照图2描述的信令数据50的发送和接收的层。信令数据包括获取节目所需的诸如节目表、地址信息(url等)的节目调度信息、指南信息以及控制信息，其中，指南信息包括对于诸如编解码器信息(编码方案或等)等内容再现处理所需的信息。

需注意，将来新协议的使用允许层(未来可扩展性)被设置为(1)广播物理层(广播phy)之上的层。

(1)广播物理层(广播phy)是配置有通信控制单元的物理层，该通信控制单元用于控制例如用于执行广播通信的广播系统的通信单元。

(2)ip多播层(ip多播)是其中根据ip多播进行数据发送/接收处理的层。

(3)udp层是进行生成和分析udp分组的处理的层。

(4)route层是其中根据用作扩展flute协议的route协议存储和提取传输数据的层。

与flute类似，route是被称为alc的可扩展文件对象的多播协议，并且具体地，route被配置有作为其构建块的lct或fec组件的组合。

(5)esg、nrt内容、dash(isobmff)和视频/音频/cc是根据route协议传输的数据。

根据dash标准的广播类型传送业务被称为多媒体广播多播业务(mbms)。存在作为用于在lte中有效实现mbms的方案的演进多媒体广播多播业务(embms)。

mbms和embms是广播类型传送业务，即这样的业务：用于通过公共载体向作为位于特定区域中的接收设备的多个用户终端(ue)同时传送诸如电影内容等的相同数据。通过根据mbms或embms的广播传送，可以将相同的内容同时提供到位于传送业务提供区域中的诸如多个智能电话、pc或电视的接收设备。

在mbms和embms中，根据传输协议route或flute具体说明了根据3gpp文件格式(iso-bmff文件或mp4文件)的下载文件的处理。

将以上参考图2描述的以下数据中的多数根据route协议或flute协议发送：

(a)信令数据50；

(b)av段60；和

(c)其他数据(esg、nrt内容等)70。

(5)esg、nrt内容、dash(isobmff)和视频/音频/cc是根据route协议传输的数据。

esg是电子业务指南，例如，诸如节目表的指南信息。

nrt内容是非实时类型内容。

如上所述，例如，在nrt内容中包括在用作客户端的接收设备的浏览器上执行的数据文件，诸如各种应用文件、运动图像或静止图像。另外，在nrt内容中还包括用作应用的控制程序的服务工作者(sw)(稍后将描述)等。

视频/音频/cc是用作再现目标(诸如根据dash标准传送的视频或音频)的实际数据。

(6)应用层(应用(html5))是这样的应用层：在其中进行根据route协议待传送的数据的生成或分析，以及进行各种数据的输出控制，例如应用了html5的数据生成、分析、输出处理等。

另一方面，与(b)在图3的右侧上示出的单播(广播)通信(例如，http类型p2p通信)对应的协议栈从下层起依次具有以下层：

(1)宽带物理层(宽带phy)；

(2)ip单播层(ip单播)；

(3)tcp层；

(4)http层；

(5)esg、信令、nrt内容、dash(isobmff)和视频/音频/cc；

(6)应用层(应用(html5))。

(1)宽带物理层(广播phy)是配置有通信控制单元(诸如设备驱动器)的物理层，该通信控制单元用于控制用于执行宽带通信的通信单元(诸如网卡)。

(2)ip单播层(ip单播)是进行ip单播发送/接收处理的层。

(3)http层是http分组生成/分析处理层。

上层类似于图3左侧的(a)广播通信(例如，广播类型数据传送)的栈配置。

需注意，发送设备(服务器)20和接收设备(客户端)30进行根据图3的两个处理系统中的至少一个的处理，即以下两个通信协议栈：

(a)广播通信(例如，广播类型数据传送)；

(b)单播(宽带)通信(例如，http类型p2p通信)。

在图3所示的协议栈中，当根据route(flute)多播并传输的文件组的属性(包括用作文件标识符的url)可以在route(flute)的控制文件中描述时，其可以在描述文件传输会话的信令数据中描述。另外，文件传输会话的更详细属性可以由esg(其也可以用于向最终用户呈现)来描述。

[4.服务工作者(sw)]

接下来，将描述由发送设备(服务器)20提供并主要在接收设备(客户端)30中使用的服务工作者(sw)。

服务工作者(sw)从诸如广播服务器21或数据传送服务器22的发送设备20提供至接收设备。

服务工作者(sw)是进行获取处理的程序、在存储单元(缓存)的存储处理、更新处理、删除处理等，其中，该获取处理用于在接收设备(客户端)30中执行的应用(＝应用程序)、在执行应用时使用的数据文件等。具体地，服务工作者(sw)例如用javascript(注册商标)配置。

例如，服务工作者(sw)被设置为对应于与由传送设备20(诸如广播服务器21、数据传送服务器22等)提供的广播节目(广播内容)，并且作为从发送设备20提供至接收设备30的应用的控制/管理程序提供至接收设备30。

将执行应用时所使用的服务工作者(sw)、应用和数据文件从发送设备20提供至接收设备30，例如作为以上参考图1、图2和图3描述的nrt内容(非实时内容)。

另选地，与传送广播节目标服务器不同的数据提供服务器可以被配置为向接收设备30提供执行应用时所使用的服务工作者(sw)、应用和数据文件。

例如，服务工作者(sw)对使用浏览器进行信息显示的应用等进行管理(获取、保留、更新、删除等)，其中，浏览器是用于在接收设备30上进行网页等浏览的程序。

将参考4图和图5描述使用服务工作者(sw)的处理的具体示例(用例)。

图4示出接收设备30从发送设备20(诸如广播服务器21)接收某个节目内容并且在接收设备30的显示单元上显示该节目内容的状态。

除了节目传送之外，传送设备20(诸如广播服务器21)将用于显示天气信息的应用和用于天气信息显示应用的各种数据文件作为nrt内容(非实时内容)提供至接收设备30，例如，包括诸如运动图像、静止图像和音频的数据文件)的数据文件。

在下文中，应用和数据文件被称为“资源”。

广播服务器21还将用作用于管理“资源”的资源管理程序的服务工作者(sw)作为nrt内容(非实时内容)提供至接收设备30。

接收设备30可以使用从发送设备20接收的“资源”(即应用和数据文件)进行天气信息的显示以及图4所示的节目显示。

在上述数据传送配置中，在由应用提供的内容结束时，同时禁用使用应用的此类数据显示。

这是因为资源(诸如天气信息显示应用)在节目接收期间被设置为在接收设备30中可使用，例如，存储在临时存储缓存中、并且被设置为可用状态，但是当节目结束时或用户切换频道时，将此类缓存数据擦除或设置成不可访问状态。

服务工作者(sw)用作资源管理程序，其使得即使在节目结束之后、甚至在频道切换之后、或甚至在离线状态(诸如广播不可接收状态或网络不可连接状态)下，应用或与节目对应的数据能够可用。

即使在由应用提供的节目结束之后、在切换到另一频道之后、或者甚至在其中不能进行数据接收的离线状态下，也可以使天气信息显示应用可用。换句话说，可以使天气信息显示在接收设备30的显示单元上并进行浏览。

需注意，天气信息显示应用例如是显示在浏览器上的程序。

天气信息显示应用在服务工作者(sw)的控制下存储在接收设备30的存储单元(永久缓存)中。例如，当存在请求(事件)(诸如来自用户的显示请求)时，在服务工作者(sw)的控制下从存储单元(永久缓存)中读取天气信息显示应用并且显示在显示单元上。

需注意，存储资源(诸如应用)的存储单元(永久缓存)优选地是即使当接收设备30断电时所存储数据也不被擦除的非易失性存储器。

如上所述，使用服务工作者(sw)，可以使用与节目显示或不显示无关的各种节目对应的应用。

需注意，服务工作者(sw)例如设置在与特定节目相对应的资源单元中(在应用和应用相关数据的单元中)，并且与资源一起或在发送资源之前或之后从发送设备20提供到接收设备30。

可以针对每个节目设置服务工作者(sw)，但是也可以设置可以与包括多个节目的特定频道相对应的资源共同使用的服务工作者(sw)。

服务工作者(sw)和由服务工作者(sw)管理的资源(应用和应用相关数据)存储在接收设备30的存储单元(永久缓存)中。

图6是用于描述使用服务工作者(sw)的处理的示例的示图。

图6示出接收设备30从发送设备20获取用作资源的网页(例如，图4和图5所示的天气信息显示页)、将网页存储在接收设备30的存储单元(永久缓存)中并使用网页的顺序的示例。

需注意，使用预定网页显示应用和配置有显示数据的资源显示网页。

图6示出了作为接收设备中的输出控制单元90的组件的显示处理单元91，服务工作者(sw)92和缓存(存储单元)93。

步骤s101至s102是所进行的资源(网页)获取处理，使得接收设备30对发送设备20进行第一访问处理。

例如，从来自广播服务器发送的nrt内容中获取。

在获取处理之后，显示处理单元91使得网页95显示在接收设备30的显示单元上。

该显示是其中提供网页的节目也被显示的状态并且对应于上面参考图3描述的显示状态。

在该显示期间中，例如，在步骤s103中，存在作为用户指令的资源(网页)注册(安装)请求时，服务工作者(sw)92开始资源(网页)注册(安装)过程。

具体地，如在步骤s104中那样进行将资源移交到缓存93并将资源存储在存储单元(永久缓存)中的处理。

此后，在节目结束之后，在频道切换之后，或者在离线设置状态下，在步骤s105中，用户做出网页浏览请求。

服务工作者(sw)92检测作为抓取事件的浏览请求输入，并且在步骤s106中，服务工作者(sw)92响应于抓取事件检测获取来自存储单元(永久缓存)的资源。

在步骤s107中，显示处理单元91显示网页96。

网页显示处理是在程序结束之后，频道切换之后或者处于离线设置状态的显示处理并且对应于上面参照图5所述的显示状态。

如上所述，使用服务工作者(sw)，不管是否显示节目，都可以使用各种节目对应应用，例如，可以进行显示网页的处理，该网页被设置为在与节目无关的任意定时处的节目属性的显示信息。

如上所述，例如，服务工作者(sw)进行诸如资源的获取、存储、更新和删除的资源管理，该资源包括作为组件的应用或在应用中使用的数据等，该应用具有网页、html页面、javascript(注册商标)等。

其中，存储资源的存储单元(缓存)是其中存储数据被永久存储的存储单元(缓存)，并且即使当应用不像公共本地/临时缓存那样操作时也存储数据。

在用作网页显示节目的浏览器中实现一种代理服务器，并且它是在任何时间可以根据需要访问代理服务器、获取网页并显示网页的图像。

需注意，服务工作者(sw)也存储(安装)在永久缓存中。当服务工作者(sw)安装在接收设备中时，可以对用作该服务工作者(sw)的管理对象的资源进行各种控制。

例如，响应于对资源的访问请求(对资源的抓取请求)，在浏览器侧处理(从本地缓存或网络获取资源)开始之前，服务工作者(sw)的处理开始并且进行从永久缓存提供资源。

此外，因为服务工作者(sw)由javascirpt(注册商标)提供，所以可以兼容各种处理，并且可以对缓存控制(诸如更新永久缓存的一些资源)进行灵活的处理描述。

需注意，服务工作者(sw)也可以更新。服务工作者(sw)是从发送设备20提供的，但是更新处理所需的各种类型的信息(诸如更新日期/时间信息以及更新日期的访问信息)被记录在服务工作者(sw)的头信息(http缓存控制)中，并且基于头信息进行更新处理。

例如，当基于在头部中设置的截止日期等到达截止日期时，接收设备30进行服务工作者(sw)的新版本的获取处理，并且进行将存储在缓存中的sw旧版本取代的处理。

[5.接收设备中的应用的获取和执行的示例]

如上所述，接收设备30可以执行例如应用诸如上面参考图4和5描述的天气信息显示应用，即，接收设备30可以使用服务工作者(sw)在任意定时执行服务工作者(sw)的管理对象。

在接收设备30侧处的用户可以在任意定时执行应用，并且可以随时浏览天气信息显示页面或各种网页。

将参照图7描述执行应用的接收设备30的配置。

图7示出主要应用于获取和执行应用的示例性配置，其作为用于执行服务工作者(sw)管理应用(诸如天气信息显示应用)的接收设备30的部分配置。

如图7所示，接收设备30包括中间件110、http代理服务器120和输出控制单元130。

中间件110接收并分析广播服务器21的提供数据。

中间件110包括通信单元(phy/mac)111、获取信令数据的信令获取单元112、分析信令数据的信令分析单元113以及文件获取单元114，文件获取单元114获取信令数据和节目内容数据(诸如视频和语音或诸如应用的nrt内容等的数据文件)。

中间件110接收的数据被存储在代理服务器120的缓存单元(代理缓存)121中。代理服务器120还将经由网络从数据传送服务器22获取的数据存储在缓存单元(代理缓存)122中。

代理服务器120将从输出控制单元130传送的数据请求输入到地址解析单元123，从缓存单元(代理缓存)121或122或外部获取请求的数据，并提供所请求的数据。

输出控制单元130是执行服务工作者(sw)管理应用(诸如天气信息显示应用)的数据处理单元。例如，输出控制单元130在浏览器上进行网页显示处理等。

输出控制单元130包括显示数据(例如，html/javascript(注册商标))获取和分析单元131和显示处理单元(渲染器)132。

输出控制单元130获取并呈现中间件(客户端本地atsc中间件)110或者经由公共网络栈获取并呈现应用和部分(html页面和javascript)，其中，在中间件110中经由代理服务器(客户端本地http代理服务器)120实现广播系统接收栈，在所述公共网络栈中，执行网络系统发送/接收处理。

需注意，还可以在经由网络(诸如lan)连接到接收设备30的外部设备140的输出控制单元141中传送应用和部分(html页面或javascript)，并且在外部设备140中执行该应用。

输出控制单元130可以将服务工作者(sw)和用作服务工作者(sw)的管理对象的资源(应用和应用相关数据)存储在存储单元(永久缓存)133中，并在任意定时进行使用服务工作者(sw)和存储在存储单元(永久缓存)中的资源的处理。

例如，如参考图4和5的以上所述，在任意定时使用应用输出各种数据。此外，输出控制单元130根据需要进行服务工作者(sw)或资源(应用和应用相关数据)的更新处理或删除处理。

这同样应用于外部设备140的输出控制单元141，并且服务工作者(sw)或资源(应用和应用相关数据)存储在外部设备140的存储单元(永久缓存)142中，并且在任意定时进行使用服务工作者(sw)或应用的各种数据处理。此外，根据需要进行服务工作者(sw)或资源(应用和应用相关数据)的更新处理或删除处理。

需注意，在图7所示的模型中，因为当进行对外部的访问时，输出控制单元130和140一致地经由代理服务器120访问，所以不区分是经由广播还是网络获取资源(诸如应用)。换句话说，提供了网络透明度。

将描述根据来自输出控制单元130的数据请求的示例性数据获取/提供处理。

例如，当输出控制单元130请求获取构成应用(http请求)的html页面或javascript(注册商标)时，已经接收请求的代理服务器120确定是经由广播接收栈还是经由地址解析单元(广播/宽带地址解析器)123中的网络获取html页面或javascript(注册商标)。

通过信令分析单元113从信令数据的分析结果中获得用作确定材料的信息。

信令分析单元(信号分析器)113发送usbd(usd、sdp等)的获取请求到信令取得单元(信令获取器)112，该获取请求是包括在atsc3.0的信令数据中的元数据。

信令分析单元(信令解析器)113提取包括在通过信令数据存储lct分组发送的信令数据中的元数据，该分组经由通信单元(atsc调谐器：atsc3.0phy/mac)111被广播和接收。

此外，信令分析单元(信令解析器)113基于包括在应用组件(部分)的获取请求中的url解析广播传送地址信息，该广播传送地址信息用于从信令数据(元数据)中获取所请求的文件。当确定应用组件(部分)是广播传送目标数据时，文件获取单元(文件获取器)114基于广播传送地址信息获取其中存储有期望文件的文件存储lct分组，并且将该文件存储lct分组存储在缓存单元(代理缓存)121中。

代理服务器120将所缓存的文件返回到输出控制单元130(作为http响应)。当包括在应用部分的获取请求中的url未被设置在元数据(被包括在信令数据中)中时，代理服务器120经由公共网络栈从数据传送服务器22获取文件。

[6.接收设备中的文件获取处理顺序]

接下来，将描述接收设备中的文件获取处理顺序。

接收设备(客户端)30进行从发送设备20(包括广播服务器21或数据传送服务器22)发送的各种数据文件的获取处理。

例如，获取内容片段文件、诸如数据文件的应用文件、其中存储有服务工作者(sw)的文件等，其中，内容片段文件为广播节目(内容)的分割数据文件，数据文件存储当执行应用时所使用的运动图像、静止图像、声音等。

例如，根据在接收设备30中执行的广播流再现应用(其在浏览器或本地环境中执行)的处理，接收设备(客户端)30获取作为获取对象的各种文件的url。

例如，用于通知url(其用于激活应用)的触发信息被包括在特定节目的广播流中，并且再现应用可以基于该触发信息获取文件url。

例如，接收设备30从广播流中提取由url指定的文件，或者使用url经由网络获取文件。

将参考图8至图9所示顺序示图描述文件获取处理顺序。

需注意，接收设备30获取上述各种文件，诸如内容段文件，应用文件，存储运动图像、静止图像、声音等的数据文件，具有存储其中的服务工作者(sw)的文件等。

在图8和图9中，从左边起示出以下组件。

(a)用作发送设备20的广播服务器；

(b)用作发送设备20的数据传送服务器；

(c)用作接收设备30的组件的中间件；

(d)用作接收设备30的组件的代理服务器；和

(e)用作接收设备30的组件的输出控制单元。

将顺序地描述图8和图9的顺序图中示出的步骤的处理。。

需注意，假设在图8和图9的处理顺序开始之前，在接收设备30的输出控制单元中激活浏览器上的本地流再现应用或流再现应用。

(步骤s211)

首先，由在浏览器上的本地流再现应用(其由作为接收设备30组件的输出控制单元执行)或流再现应用发送对特定数据文件的获取请求。例如，发送指定了文件url的数据文件获取请求。

需注意，如上所述，例如根据作为自适应流媒体技术标准的mpeg-dash标准来执行从发送设备20到接收设备30的数据发送。

如以上参考图2所述的，由根据mpeg-dash标准进行数据发送的发送设备20发送的数据大致分为以下数据的多种类型：

(a)信令数据50；

(b)av段60；和

(c)其他数据(esg、nrt内容等)70。

例如，av段60配置有在接收设备中再现的图像(视频)或音频数据，即，从广播站提供的节目内容等。例如，av段60被配置有mp4编码数据(mdat)和元数据(moov和moof)。

信令数据50配置有获取节目所需的节目调度信息(诸如节目表、地址信息(url等))、指南信息和控制信息，其中，指南信息包括对于诸如编解码器信息(编码方案或等)等的内容进行再现处理所需的信息。

其他数据70包括例如电子业务指南(esg)、nrt内容等

esg是电子业务指南，例如，指南信息(诸如节目表)。

nrt内容是非实时类型内容。

例如，在nrt内容中包括在用作客户端的接收设备的浏览器上执行的数据文件(诸如各种应用文件、运动图像或静止图像)。服务工作者(sw)也包括在nrt内容中。

(媒体呈现描述(mpd))是描述元数据的清单文件，该元数据是运动图像和音频文件的管理信息。具体地，例如，记录从广播站传送的节目内容的传送开始时间信息、av段的访问信息等。

在步骤s211中，例如，接收设备30的输出控制单元获取段url(该段url是mpd中描述的内容存储段的访问信息，该mpd是广播内容流的dash流的控制文件)，并且将用于内容段文件的获取请求发送到使用所获取的段url的代理服务器。

对于其他应用文件、数据文件、服务工作者(sw)文件等，从信令数据等获取用作访问信息的url，并且进行其中应用url的文件访问。

(步骤s212至s213)

接着，在步骤s212中，当由文件url识别的文件存储在由代理服务器管理的缓存中时，接收设备30的代理服务器从缓存获取文件并作为响应将所获取文件发送到控制单元。

另一方面，在步骤s213中，当确定由文件url识别的文件未存储在由代理服务器管理的缓存中时，接收设备30的代理服务器将文件获取请求输出到中间件。

(步骤s214)

步骤s214的处理指示由广播服务器21连续进行的处理。广播服务器21连续地将信令数据(元数据等)以及节目内容提供至接收设备30，其中，信令数据包括与传送内容有关的控制信息、管理信息等。

(步骤s215)

当在步骤s213中从代理服务器输出文件请求时，由中间件执行步骤s215的处理。

中间件基于从广播服务器21接收的信令数据(元数据)确定是否能够经由广播接收针对从代理服务器输出的获取请求的文件，并且将指示确定信息的通知提供给代理服务器。

(步骤s216)

当从中间件接收了用于指示可以经由广播接收文件的通知时，代理服务器处于待机状态，以将文件形成(存储)到代理服务器的管理缓存。

另一方面，当从中间件接收到用于指示不能经由广播接收文件的通知时，代理服务器经由网络将用于获取文件的获取请求发送到数据传送服务器22。

(步骤s217至s218)

步骤s217至s218的处理是当可以经由广播接收到针对从代理服务器输出的获取请求的文件时进行的处理。

在这种情况下，在步骤s217中，广播服务器21经由广播波发送文件。

在步骤s218中，接收设备30的中间件接收从广播服务器21发送的文件，并将该文件形成(存储)到代理服务器的管理缓存中。

(步骤s219)

步骤s219的处理是当不能经由广播接收到针对从代理服务器输出的获取请求的文件时进行的处理。

在这种情况下，在步骤s219中，数据传送服务器22将接收设备30所请求的文件发送到接收设备30。

接收设备30的代理服务器接收所发送文件，并将该文件形成(存储)到代理服务器的管理缓存中。

(步骤s220)

在步骤s220中，将从广播服务器21或数据传送服务器22获取的并存储在代理服务器管理缓存中的文件从代理服务器提供至输出控制单元。

[7.服务工作者(sw)对接收设备的存储单元(永久缓存)的控制处理]

接下来，将描述由根据文件获取处理等存储在接收设备30中的服务工作者(sw)对接收设备的存储单元(永久缓存)的控制处理。

存储在接收设备30中的服务工作者(sw)使用管理对象的资源(即作为管理进程之一的应用或与应用相关数据)控制存储单元(永久缓存)，即存储资源的缓存。

首先，服务工作者(sw)根据在接收设备30的存储单元(永久缓存)中的预定事件的检测，存储初始激活服务工作者(sw)的应用所需的文件。

接收到用作触发服务工作者(sw)的资源存储的事件的定时是执行服务工作者(sw)的注册处理或重新注册(更新)处理的定时。此时，服务工作者(sw)接收注册(安装)事件。

此外，在应用请求html页面或javascript(注册商标)的定时(当接收到抓取事件时)或者在由服务工作者(sw)生成的定时器重新激活时，接收用作资源存储处理的触发的事件。

由服务工作者(sw)形成到存储单元(永久缓存)中的应用(部分组)可以被激活为这样的应用(离线应用)：该应用不仅与广播流相关联地(同时)被激活，而且还被安装在独立于广播流的客户端。

将参照图10至图11所示的顺序图描述服务工作者(sw)对接收设备的存储单元(永久缓存)的控制处理顺序。

在图10至11中，以下组件从左边起示出：

(a)构成发送设备的广播服务器；

(b)构成发送设备的数据传送服务器；

(c)接收设备的中间件；

(d)接收设备的代理服务器；

(e)由接收设备的输出控制单元执行的浏览器管理的存储单元(永久缓存)

(f)在由接收设备的输出控制单元执行的浏览器上执行的服务工作者(sw)；

(g)在由接收设备的输出控制单元执行的浏览器上执行的应用；和

(h)由接收设备的输出控制单元执行的本地应用。

需注意，本地应用是由接收设备30执行的应用，但是本地应用不是由服务工作者(sw)管理的应用，而是例如用于与内容(节目)对应的应用的激活处理的应用。

将顺序地描述在图10至图11的顺序图中示出的步骤的处理。

(步骤s301)

步骤s301的处理是通过本地应用激活与内容(节目)相对应的应用的处理。

如上所述，本地应用是用于与内容(节目)相对应的应用的激活处理的应用。

在基于例如嵌入在程序中的触发信息激活与内容(节目)对应的应用的设置的情况下，不需要本地应用的激活处理。

(步骤s302)

在步骤s302中，被激活的应用进行服务工作者(sw)的注册处理。

通过注册处理，服务工作者(sw)被存储在存储单元(永久缓存)中并且进入可以随时使用该服务工作者(sw)的状态。

服务工作者(sw)基于注册(安装)事件的检测来检测服务工作者(sw)注册处理，并且服务工作者(sw)使用注册(安装)事件的检测作为触发来开始步骤s303的缓存控制。

(步骤s303至s305)

当检测到注册(安装)事件时，在步骤s303中，服务工作者(sw)例如根据脚本描述开始存储单元(永久缓存)的控制。

具体地，开始获取处理和缓存形成(存储)处理，该获取处理和缓存形成(存储)处理用于作为服务工作者(sw)的管理对象的资源(应用和应用相关数据)。

需注意，在步骤s304中，从发送设备(诸如广播服务器、数据传送服务器等)连续地发送用作服务工作者(sw)的管理对象的资源(应用和应用相关数据)。

需注意，在步骤s304中，进行以下处理：用资源处理取代在以上参考图8至图9描述的资源发送/接收处理(其具有用于资源的处理)中的在图8至9的步骤中的段文件的处理(a-1至a-2)。

在步骤s305中，通过代理服务器的管理缓存将传输数据形成(存储)到存储单元(永久缓存)中。

(步骤s306至s309)

在步骤s306中，应用请求服务工作者(sw)发送应用部分，例如，执行应用所需的运动图像文件或静止图像文件，或者应用相关数据(诸如javascript(注册商标)程序或音频数据)。

该请求处理对应于在服务工作者(sw)中的抓取事件检测。

在步骤s307至s309中，服务工作者(sw)从存储单元(永久缓存)获取所请求的部分，并将所请求的部分提供至应用。

(步骤s310至s311)

步骤s310至s311的处理是当服务工作者(sw)检测到激活事件时的处理。

例如，当用户输入资源删除请求时或者当应用的截止日期到期时，检测到激活事件。

当服务工作者(sw)检测到激活事件时，例如，根据脚本描述开始存储单元(永久缓存)的控制。

具体地，例如，进行针对用作服务工作者(sw)的管理对象的资源(应用和应用相关数据)的删除处理。

(步骤s312至s315)

步骤s312至s315的处理是当服务工作者(sw)检测到定时器事件时的处理。

例如，当应用的截止日期到期时，当更新期限到达时等，检测定时器事件。

根据定时器事件的处理的示例包括缓存资源的删除和更新资源或添加资源的获取处理。

步骤s313是与定时器事件对应的缓存资源的删除处理的顺序。

步骤s314至s315示出与定时器事件对应的更新资源或添加资源的获取处理的顺序。

注意，在步骤s314中，进行以下处理：将用于资源的处理替换在以上参考图8至图9描述的资源发送/接收处理中的图8至图9的步骤中用于段文件的处理。

[8.使用信令数据(usd)通知数据接收路径信息的配置]

接下来，将描述使用信令数据(usd)来通知数据接收路径信息的配置

图7所示的接收设备30的中间件110基于从发送设备20发送的信令数据确定是否可以经由广播接收目标文件，经由广播将指示目标文件是否可以经由广播接收的信息发送到http代理服务器120的地址解析单元(广播/宽带地址解析器)123，并且确定获取是经由广播的缓存获取还是经由网络的缓存获取。

用户业务描述(usd：userservicedescription)用作信令数据，在usd中存储了以下信息：基于该信息执行上述确定的信息。

图12是示出从发送设备(诸如广播服务器21)发送的信令数据(元数据)的示例性配置的示图。

信令数据(元数据)具有如图12所示的以下三个层：

(1)服务层(开放移动联盟-电子业务指南(oma-esg))；

(2)文件传输会话层(3gpp-mbms-usd)；和

(3)flute(route)参数层(flute(route))。

(1)服务层是其中描述特别旨在呈现给用户的服务或内容的属性信息的层。

(2)文件传输会话层是其中描述文件等的传输参数的层。

(3)flute(route)参数层是其中描述与flute(route)协议对应的参数的层。

需注意，图12的箭头示出在属性信息(元素)记录区(片段)之间的参考关系。

例如，从业务段(a)延伸到调度段(d)的箭头指示与在业务段(a)中记录的业务(例如，频道和节目)对应的传送调度信息被记录在调度段(d)中。

每个段(元素)被分类成其中记录不同类型属性信息的区域。

在节目或频道的单元中设置的业务单元的信令数据(元数据)被记录在(1)最高级服务层(oma-esg)中。

(2)文件传输会话层(3gpp-mbms-usd)设置在服务层(oma-esg)(1)下。用户业务描述(usd)包括在信令数据(元数据)中。

需注意，usd存储例如与传送方法相关的信息，并且包括例如以下信令数据：

会话描述(sdp)；

文件传送描述(fdd)；

修复流描述(rfd)；和

调度描述(sd)。

另外，usd包括作为信令数据的媒体呈现描述(mpd)，该信令数据具有其中存储与内容(av段)对应的各种指南信息和控制信息的清单文件。

(3)flute(route)参数层设置在usd元数据下。在该层中设置根据flute(route)协议待传送的特定传送数据信息，例如route元数据，其中例如记录了实际传送的各个文件的传输参数。

下面将描述在(2)文件传输会话层(3gpp-mbms-usd)中记录文件传输路径信息的示例。

用户业务描述(usd)是类集线器元件，其中存储有构成业务的传输会话的属性。此外，元素具有与段相同的含义。

图13示出用户业务描述(usd)的整体示例性配置。

用户业务束描述(usd)210是多个用户业务描述(usd)211的集合。

图13所示的中空菱形箭头指示在中空箭头侧的元素包括连接元素。

正常箭头表示参考关系。

传送方法(deliverymethod)元素212设置在用户业务描述(usd)211下。

与每个文件的传送处理相关的信息被记录在传送方法(deliverymethod)元素212中。

在本公开的实施例中，用于指示每个文件是经由广播还是网络发送的传输路径信息被记录在作为用户业务描述(usd)211下级元素的传送方法(deliverymethod)元素212中。

图14示出在构成信令数据的用户业务束描述(usd)200下的示例性分级配置。

以下元素设置在用户业务束描述(usd)210下：

用户业务描述(usd)元素211；和

传送方法(deliverymethod)元素212。

图15是示出在传送方法(deliverymethod)元素211下的信令数据配置的示图。

需注意，传送方法设置在发送内容或发送数据的单元中。

例如，在信令数据(元数据)中指定设置在应用单元、服务工作者(sw)的单元、运动图像的单元、静止图像的单元等中的传送处理方法。

以下元素中的任何一个设置在如图15所示的传送方法(deliverymethod)元素212下。

(a)广播应用服务(broadcastappservice)元素223；和

(b)单播应用服务(unicastappservice)元素224。

当(a)设置广播应用服务(broadcastappservice)元素223并且文件url的基本模式记录在其下面的基本模式(basepattern)信息225中时，这指示通过传送方法(deliverymethod)待传送的文件经由广播传送，例如，经由广播波传送。

另一方面，当(b)设置单播应用服务(unicastappservice)元素224并且文件url的基本模式记录在其下面的基本模式(basepattern)信息226中时，这指示通过传送方法(deliverymethod)待传送的文件经由单播(宽带传送)传送，例如，经由网络。

当设置(a)广播应用服务(broadcastappservice)元素223时，在其下记录基本模式(basepattern)信息225。

基本模式(basepattern)信息225是指示与待经由广播传送的文件对应的url路径组的数据。

接收设备使用url信息从广播波获取目标文件。

另一方面，当设置(b)单播应用服务(unicastappservice)元素224时，在其下记录基本模式(basepattern)信息226。

基本模式(basepattern)信息226是指示与待经由单播传送的文件对应的url路径组的数据。

接收设备使用url信息经由网络获取目标文件。

例如，文件url的第一url的路径部分在基本模式(basepattern)信息225和226中指示。具体地，例如http://a.com/bc，http://a.com/bb等。其指示具有从路径开始的文件url的文件通过由其上的一个人元素指示的路径(广播或网络)传送。

例如，http://a.com/bc/x.js指示文件通过广播传送，

http://a.com/bb/y.js表示文件通过网络传送。

此外，属性数据227设置在传送方法(deliverymethod)元素212下，并且会话描述uri(sessiondescriptionuri)元素228设置在属性数据222中，如图15所示。

这里，存储用于flute(route)的参考信息。

图16是示出当根据flute协议进行文件传输时在传送方法(deliverymethod)元素212中设置的flute的参考信息的示例的图。

如图16所示的以下信息记录为sdp，其如图16所示，涉及来自在传送方法(deliverymethod)元素212下设置的属性227之中的会话描述uri(sessiondescriptionuri)属性228，

v＝…

o＝…

s＝…

t＝…

a＝atsc-mode:frequencypipeid(bbpstreamid){具有在频率内的不同频率和调制/编码参数的发送管道的id}

a＝flute-tsi:(tsi-传输会话标识符)

s＝sourcefilter:inip4ipaddress(源ip地址)

m＝applicationport(端口号)flute/udp

c＝inip4ipaddress(目标ip地址)

图17示出根据上述信息指定的文件指定配置。

根据flute(route)协议传输的所有文件存储在ip分组上的udp分组上的lct分组中并被传输。

在flute的情况下，文件由sdp指示的源ip地址(sourceipaddress)、目标ip地址(destinationipaddress)、端口号(port)和tsi指定。这是在flute会话的单元中进行的)。

源ip地址(sourceipaddress)和目标ip地址(destinationipaddress)用于指定ip分组，端口号(port)用于指定udp分组，而tsi用于指定lct分组字符串。

此外，通过存储在lct分组中的toi(transportobjectidentifier)指定期望的文件。

文件描述表(fdt)存储在toi为0的lct分组中，并且解析在每个文件url(存储在fdt-instance/file/@contentlocatoin中)和对应的toi(存储在fdt-instance/file/@toi)之间的关系，以用于由相同tsi指定的传输会话中的其他文件对象。

另一方面，图18是示出当根据route协议进行文件传输时在传送方法(deliverymethod)元素212中设置的flute的参考信息的示例的图。

如图18所示的以下信息被记录为sdp，其如图18所示涉及来自在传送方法(deliverymethod)元素212下设置的属性(属性)227之中的会话描述uri(sessiondescriptionuri)属性228：

v＝…

o＝…

s＝…

t＝…

a＝atsc-mode:frequencypipeid(bbpstreamid){具有在频率内的不同频率和调制/编码参数的发送管道的id}

s＝sourcefilter:inip4ipaddress(源ip地址)

m＝applicationport(端口号)route/udp

c＝inip4ipaddress(目标ip地址)

图19示出根据上述信息指定的文件指定配置。

在route的情况下，文件由sdp指示的源ip地址(sourceipaddress)、目标ip地址(destinationipaddress)和端口号(port)指定。其在route会话的单元中进行。

源ip地址(sourceipaddress)和目标ip地址(destinationipaddress)用于指定ip分组，且端口号用于指定udp分组。

在route会话中，lct会话实例描述(lsid)存储在lct分组的tsi为0的lct分组中，并且toi为0，并且在route会话中存储用于其他传输会话的属性(由lct分组的tsi指定)存储。解析在contentlocation属性(用作lsid的transportsession/sourceflow/efdt/file元素的属性)与toi(通过toi属性与文件url对应)之间的关系。

如上面参考图12所描述的，

信令数据(元数据)具有如图12所示的以下三个层：

(1)服务层(oma-esg)

(2)文件传输会话层(3gpp-mbms-usd)

(3)flute(route)参数层(flute(route))。

flute(route)参数层(flute(route))包括描述了整个文件传输会话的flute的fdt(fdt实例)元素或描述了会话中携带的每个文件的属性的文件元素。文件url存储在作为文件元素的属性的内容位置(content-location)属性中。

图20是示出构成信令数据的在flute(route)参数层中的fdt实例元素下的数据存储配置的示图。

在fdt实例元素301下，

集合是对应于fdt实例的属性302以及

文件元素303

此外，在文件元素303下面，集合为

对应于文件的属性304。

图21(a)和21(b)示出了与fdt实例对应的属性302和与该文件对应的属性304的详细配置。

文件url被存储在与如图21所示的文件对应的属性304中设置的内容位置(content-location)属性记录区域305中。

另一方面，对于route，在flute中指定的文件元素被存储在lsid(用作route中规定的信令数据)中。

图22示出在route中规定的lsid下的数据配置。

如图22所示，如下进行分层设置：

lsid元素351；

传输会话(transportsession)元素352；

源流(sourceflow)元素353；

efdt元素354；和

文件元素355。

如图22所示，在route的情况下，设置了lsid/transportsession/sourceflow/efdt元素，作为描述了整个文件传输会话的数据元素，此外，存在文件元素355，其描述了在会话中携带的每个文件的属性。这与上述flute的情况下的文件元素相同。

文件url存储在作为文件元素355的属性的内容位置(content-location)属性记录区域中。

图23(a)和23(b)示出在图22所示的属性记录区域的详细配置，即，(a)efdt元素354单元的属性数据元素361和(b)文件355单元的属性数据元素362。

文件url记录在如图23所示的与文件对应的属性362中的内容位置(content-location)属性记录区域363中，。

当通信协议是flute时，接收设备(客户端)30的中间件分析(解析)fdt(fdt实例)。当通信协议是route时，接收设备(客户端)30的中间件可以分析(解析)lsid并检测通过文件传输会话传输的文件url。

接收设备(客户机)30基于文件url检查url路径的上级部分记录在上面参照图15描述的usd的基本模式记录区225和226中的哪一个中。

换句话说，可以通过检查包括在以下记录区域中的哪一个而确定传送是广播流传送还是网络传送：

基本模式记录区域225＝[r12：broadcastappservice/basepattern]；和

在bundledescription/userservicedescription/deliverymethod下的基本模式记录区域226＝[r12：unicastappservice/basepattern]。

当它被包括在基本模式记录区域225中时，进行广播流传送。

当其包括在基本模式记录区域226中时，进行经由网络的传送。

需注意，当它包括在基本模式记录区域225和226中时，它指示经由网络的传送与广播流传送一起进行。

[9.重定向策略的控制]

接下来，将描述用于根据接收设备(设备)、接收设备的用户、数据传送时区等控制是否接收经由广播的数据传送或经由网络的数据传送的配置。

如上所述，接收设备30可以基于记录在用户业务描述(usd)中的数据获得计划要获取的文件url并且使用获得的文件url获取预定数据文件(内容、应用、服务工作者(sw)或其他数据文件)，该用户业务描述(usd)是从发送设备发送的信令数据。

例如，当在接收设备30的浏览器上的应用使用某个文件url进行文件获取请求时，如果经由广播传送目标文件，则从以上参考图15描述的基本模式记录区域225获取url基本模式。

换句话说，从bundledescription/userservicedescription/deliverymethod下的基本模式记录区域225＝[r12:broadcastappservice/basepattern]获取url基本模式。

文件url的路径(整个路径或者从头开始的部分)存储在基本模式记录区域225中。在这种情况下，图7所示的http代理服务器120的地址解析单元(广播/宽带地址解析器)123进行用于从广播流获取文件的设置，并且不经由网络进行获取。

图24的(1)示出在经由广播传送的情况下的usd的记录信息和可以经由广播获取的文件的url的示例。

另一方面，例如，当在接收设备30的浏览器上的应用使用某个文件url进行文件获取请求时，如果经由网络传送目标文件，则从参考图15所述的模式记录区域226获取url基本模式。

换句话说，从bundledescription/userservicedescription/deliverymethod下的基本模式记录区域226＝[r12:unicastappservice/basepattern]中获取url基本模式。

文件url的路径(整个路径或者从头开始的部分)存储在基本模式记录区域226中。在这种情况下，所图7所示的http代理服务器120的地址解析单元(广播/宽带地址解析器)123经由网络进行文件获取。

图24的(2)示出在经由网络传送的情况下的usd的记录信息和可以经由网络获取的文件的url的示例。

需注意，当可以从基本模式记录区域225和基本模式记录区域226这两者获取文件url的路径(整个路径或者从头开始的部分)时，图7所示的http代理服务器120的地址解析单元(广播/宽带地址解析器)123进行从广播流获取文件的尝试，但当经由网络的获取比经由广播的文件获取更快完成时(例如，当在网络带宽存在余量，并且在网络路径上的网络配置设备的资源或文件服务器的可用容量足够时)，存在经由网络进行获取的情况，并且其也响应于请求源客户端应用。

[9.1.允许经由网络的获取传送数据的示例1]

接下来，将描述以下配置：执行控制使得根据接收设备或其用户允许或不允许接收待经由网络传送的数据文件，例如用作服务工作者(sw)管理对象的资源(应用文件或应用相关数据文件)，或其他文件(内容、应用、服务工作者(sw)或其他数据文件)。

类(组)分配至接收设备(客户端)30或拥有接收设备(客户端)30的用户。

控制是否可以根据类经由网络获取文件。

换句话说，使用信令数据进行控制，在所述信令数据中包括类信息，该类信息用于指示允许经由网络进行数据接收的一组接收设备或用户。

对于该控制，网络传送数据接收允许的类(allowedclass)属性信息记录在单播应用服务(unicastappservice)元素224中设置的属性记录区域371的数据记录区域(任何)372中，该单播应用服务元素224是在图25所示的usd中的传送方法(deliverymethod)元素的下级元素。

这是因为取决于传送服务提供商，当在网络路径上的网络配置设备的资源或者文件服务器的可用容量不足时，存在期望仅允许高级类的用户(设备)通过网络进行访问的操作要求。

例如，网络传送数据接收允许类(permittedclass)属性的xml方案定义假定为以下定义：

<xs:attributename＝"permittedclass"type＝"stringlisttype"xmlns:xs＝"http://www.w3.org/2001/xmlschema"/>

<xs:simpletypename＝"stringlisttype"xmlns:xs＝"http://www.w3.org/2001/xmlschema">

<xs:listitemtype＝"xs:string">

</xs:simpletype>

基于上述定义，以下类标识符被存储作为允许经由网络的访问的类的类标识符：

<unicastappservicepermittedclass＝"classn,classm">

例如，当设置和传送包括图26所示的信令数据的usd时，只有被分配了记录在usd中的类n(classn)或类m(classm)的接收设备(客户端)或用户可以经由网络获取文件。

例如，仅当类n或类m被分配给自己时(例如，通过api参考接收设备(设备)或者使用设备的用户的类)，已经从由接收设备(客户端)30正在执行的应用接收到文件获取请求的http中间件120的地址解析单元(广播/宽带地址解析器)123进行经由网络的访问。未分配类的设备仅使用通过广播的传送。

需注意，类信息被记录在接收设备的存储器中作为注册信息，并且api参考注册信息。

需注意，对于类设置，例如，可以基于各种条件进行分类，诸如根据接收其中设备或用户所在的区域单元的分类或根据预先注册的设备信息或用户信息的分类。

[9.2.经由网络的传送数据获取允许示例2]

对于执行以下控制的配置：该控制使得根据接收设备或其用户允许或不允许接收待经由网络传送的数据文件，例如，用作服务工作者(sw)的管理对象的资源(应用文件或应用相关数据文件))或其他文件(内容、应用、服务工作者(sw)或其他数据文件)，除了以上配置外，传送多条usd和分配usd至与接收设备(设备)或用户对应的类的方法也是被考虑的。

在这种情况下，如图27所示，目标类(targetclass)属性被记录在作为usd元素的根元素的用户业务束描述(userservicebundledescription)元素下的属性数据记录区域381中的数据记录字段(任何)382中。

目标类(targetclass)指示与被允许接收与记录在用户业务描述(usd)中的信令数据对应的数据文件的接收设备(客户端设备)或用户相关联的类。

例如，目标类(targetclass)属性的xml方案定义假设为以下定义：

<xs:attributename＝"targetclass"type＝"stringlisttype"xmlns:xs＝"http://www.w3.org/2001/xmlschema"/>

<xs:simpletype

name＝"stringlisttype"xmlns:xs＝"ttp://www.w3.org/2001/xmlschema"

<xs:listitemtype＝"xs:string">

</xs:simpletype>

定义如上所述进行。目标类标识符例如被存储为以下设置：

<unicastappservicetargetclass＝"classn,classm">

例如，当设置和传送图28所示的包括信令数据的usd-1和usd-2时，仅一组被分配了类classn或classm的接收设备(客户端设备)或者用户可以使用usd-1并且经由网络获取文件。

在usd-1中，记录与广播传送文件对应的文件url的基本模式，并且还记录与经由网络传送的网络传送文件对应的文件url的基本模式。

允许使用该usd-1的类(n类或m类)的接收设备或用户可以使用与广播传送文件相对应的文件url的基本模式和与网络传送文件对应的文件url的基本模式，并且经由广播和网络这两者获取文件，其中，文件url的基本模式从usd-1中获取。

然而，除被允许使用usd-1的类(n类或m类)的用户或接收设备之外的接收设备或用户可以仅使用usd-2。

仅与广播传送文件对应的文件url的基本模式被记录在usd-2中。

因此，除了类(n类或m类)的接收设备或用户之外的接收设备或用户仅可以使用与从usd-2获得的与广播传送文件对应的文件url的基本模式，并且仅经由广播获取文件。

需注意，可以以各种形式分配在可以使用usd-1的类n或m的接收设备中的类的设置。

例如，可以根据用于允许经由网络获取数据的设备的能力设置类，例如，可以将这样的设备设置为类n或m：其内的缓存单元121中不存在足够空间，其中，该缓存单元121是在如图7所示的http代理服务器120中的存储广播传送文件的缓存。

另选地，可以根据随时改变的状态信息(诸如设备的用户的网络的拥塞状态)来分配类，该网络可以是设备直接连接到的家庭局域网或者在家庭和网络提供商的核心网络之间的接入网络。

另外，可以进行类分配以反映设备的终端用户的获取指令趋势(例如，其中总是依赖于广播传送的趋势或其中总是选择经由网络的访问的趋势)。

如上所述，存在各类的类型，并且可以灵活地改变和设置使用usd的目标设备的特性。

[9.3.经由网络的传送数据获取允许示例3]

允许根据接收设备及其用户接收或不接收经由网络传送的数据文件，例如由服务工作者(sw)作为管理对象的资源(应用文件、应用数据文件)，或其他文件(内容、应用、服务工作者(sw))。除了上述配置之外，还可以通过时区进一步控制。

在图29示出用于根据时区实现控制的usd的示例。

图29所示的示例是用于控制时区的设置，在该时区中，传送以上参考图28描述的两个usd(即，usd-1和usd-2)。

从左到右经过的时间轴在图29中示出。

时间t0至t1例如是午夜，即其中网络负载相对较低的时区。

时间t1至t2是白天，即其中网络负载相对高的时区。

在网络负载相对较低的时区t0至t1中，传送两个uisd，即usd-1和usd-2。

另一方面，在网络负载相对较高的时区t1至t2中，仅传送usd-2。

在网络负载相对低的时区t0至t1中，与允许使用usd-2的类(类n或m)相关联的用户接收设备(客户端)或可以经由网络获取文件。

另一方面，在网络负载相对较高的时区t1至t2中，不传送usd-2，并且所有接收设备(客户端)经由广播进行文件获取。

如上所述，可以通过根据时区改变要传送的usd来控制传送路线。

需注意，因为usd信令数据被设置使得当接收设备30使用usd信令数据时使用最新的信令数据，所以可以根据时区进行控制。可以预先定义usd的时区和配置，并且还可以考虑根据网络的动态变化动态地改变usd的配置的操作。

[10.发送设备和接收设备的示例配置]

接下来，将参照图30和图31描述作为通信设备的发送设备(服务器)20和接收设备(客户端)30的示例性设备配置。

图30示出发送设备(服务器)20和接收设备(客户端)30的示例性配置。

发送设备(服务器)20包括数据处理单元751、通信单元752和存储单元753。

接收设备(客户端)30包括数据处理单元771、通信单元772、存储单元773、输入单元774和输出单元775。

数据处理单元包括通信数据处理单元771a和再现处理单元771b。

发送设备(服务器)20的数据处理单元751执行用于执行数据传送服务的各种数据处理。例如，数据处理单元751进行数据传送服务的配置数据的生成和传送控制。此外，数据处理单元751进行应用、服务工作者(sw)、各种其他数据和待提供给接收设备(客户端)30的信令数据的生成和发送处理。

通信单元752还进行通信处理，诸如传送应用、服务工作者(sw)、各种其它数据、信令数据等(除了av段)。

存储单元753存储待传送的av段、应用和服务工作者(sw)，应用使用的数据，信令数据等。

此外，存储单元753被用作由数据处理单元751进行的数据处理的工作区域，并且还用作各种参数的存储区域。

另一方面，接收设备(客户端)30包括数据处理单元771、通信单元772、存储单元773、输入单元774和输出单元775。

通信单元772接收从发送设备(服务器)20传送的数据，例如，av段、应用、服务工作者(sw)、待由应用使用的数据、信令数据等。

数据处理单元771包括通信数据处理单元771a和再现处理单元771b，并且进行例如根据上述实施例的处理。

具体地，数据处理单元771使用应用、api、服务工作者(sw)等进行数据处理。

经由输入单元774输入用户的指令命令，例如用于频道选择、应用激活、安装等的各种命令。

再现数据被输出到输出单元775，诸如显示单元或扬声器。

存储单元773存储av段、服务工作者(sw)、应用、待由应用使用的数据、信令数据等。

此外，存储单元773用作由数据处理单元771进行的数据处理的工作区域，并且还用作各种参数的存储区域。

图31示出可用作发送设备20和接收设备30的通信设备的示例性硬件配置。

中央处理单元(cpu)801用作数据处理单元，其根据存储在只读存储器(rom)802或存储单元808中的程序进行各种处理。

例如，cpu801根据上述实施例中描述的顺序进行处理。

随机存取存储器(ram)803存储由cpu801执行的程序，数据等。cpu801、rom802和ram803经由总线804彼此连接。

cpu801经由总线804连接到输入/输出接口805、包括各种开关、键盘、鼠标、麦克风等的输入单元806和包括显示器、扬声器等的输出单元807。cpu801响应于从输入单元806输入的命令进行各种处理，并将处理结果输出到例如输出单元807。

连接到输入/输出接口805的存储单元808被配置有例如硬盘等，并且存储由cpu801执行的程序和各种数据。通信单元809用作经由网络诸如因特网或局域网(lan)的数据通信的收发单元和用于广播波的收发单元，并且与外部设备通信。

连接到输入/输出接口805的驱动器810驱动可移除介质811诸如磁盘、光盘、磁光盘、半导体存储器诸如存储卡，并进行数据的记录或读取。

需注意，数据的编码或解码可以作为用作数据处理单元的cpu801的处理来执行，但是可以提供用作专用硬件(用于执行编码处理或解码处理)的编解码器。

[11.本公开的配置的结论]

已经参考具体示例详细描述本公开的实施例。然而，显而易见的是，领域技术人员可以在不脱离本公开的要旨的情况下对实施例进行修改或替换。换句话说，该实施例旨在将本发明公开为示例性形式，而不旨在以限制的方式解释。为了确定本公开的要旨，应当考虑以下阐述的权利要求。

注意，本说明书中公开的技术可以具有以下配置。

(1)一种接收设备，包括：

数据处理单元，接收其中记录了类信息的信令数据，并且根据所述类信息确定是经由广播还是经由网络进行所述数据接收，所述类信息指示允许经由网络进行所述数据接收的一组接收设备或用户。

(2)根据(1)所述的接收设备，

其中类标识符记录在所述信令数据中，

所述数据处理单元确定在所述信令数据中记录的所述类标识符与预先分配至所述接收设备或所述用户的类标识符是否相同，以及

当在所述信令数据中记录的类标识符与预先分配至所述接收设备或所述用户的类标识符相同时，经由所述网络进行所述数据接收。

(3)根据(1)或(2)所述的接收设备，

其中类标识符记录在所述信令数据中，

所述数据处理单元确定在所述信令数据中记录的所述类标识符与预先分配至所述接收设备或所述用户的类标识符是否相同，以及

当在所述信令数据中记录的所述类标识符与预先分配至所述接收设备或所述用户的类标识符不相同时，经由所述广播进行所述数据接收。

(4)根据(1)至(3)中任一项所述的接收设备，

其中，用作应用于经由广播波或网络的数据接收的数据访问信息的url基本模式被记录在所述信令数据中，并且

所述数据处理单元应用能够从所述信令数据获取的url基本模式并进行数据获取。

(5)根据(1)至(4)中任一项所述的接收设备，

其中，类标识符和用作应用于经由广播波或网络的数据接收的数据访问信息的和url基本模式被记录在所述信令数据中，并且

所述数据处理单元确定在所述信令数据中记录的所述类标识符与预先分配至所述接收设备或所述用户的类标识符是否相同，以及

当在所述信令数据中记录的所述类标识符与预先分配至所述接收设备或所述用户的所述类标识符相同时，应用被记录在所述信令数据中且应用于经由所述网络的所述数据接收的所述url基本模式被应用，并且进行经由所述网络的数据获取。

(6)根据(1)至(5)中任一项所述的接收设备，

其中，所述接收设备能够接收两种类型的信令数据，所述两种类型的信令数据为其中记录所述类信息的第一信令数据和其中未记录所述类信息的第二信令数据，并且

所述数据处理单元确定在其中记录所述类信息的所述第一信令数据中记录的所述类标识符与预先分配至所述接收设备或所述用户的类标识符是否相同，并且

当在其中记录所述类信息的所述第一信令数据中记录的所述类标识符与预先分配至所述接收设备或所述用户的所述类标识符相同时，应用被记录在所述第一信令数据中记录且应用于经由所述网络的所述数据接收的所述url基本模式，并且进行经由所述网络的所述数据获取。

(7)根据(6)所述的接收设备，

其中，所述数据处理单元确定在其中记录所述类信息的所述第一信令数据中记录的所述类标识符与预先分配至所述接收设备或所述用户的类标识符是否相同，并且

当在其中记录所述类信息的所述第一信令数据中记录的所述类标识符与预先分配至所述接收设备或所述用户的所述类标识符不相同时，应用被记录在所述第二信令数据中且应用于经由所述广播的所述数据接收的所述url基本模式，并且进行经由所述广播的所述数据获取。

(8)根据(1)至(7)中任一项所述的接收设备，

其中，所述接收设备根据时区接收不同设置的信令数据，类信息被记录在所述信令数据中，并且

基于根据所述时区接收的所述不同设置的所述信令数据来改变接收路径。

(9)根据(1)至(8)中任一项所述的接收设备，

其中，在其中记录所述类信息的所述信令数据是用户业务描述(usd)，以及

所述数据处理单元参考所述用户业务描述(usd)确定是经由所述广播还是经由所述网络进行所述数据接收。

(10)根据(1)至(9)中任一项所述的接收设备，

其中，在其中记录所述类信息的所述信令数据是在用户业务描述(usd)中设置的传送方法(deliverymethod)元素中的数据，以及

所述数据处理单元参考所述用户业务描述(usd)的所述传送方法(deliverymethod)元素确定是经由所述广播还是经由所述网络进行所述数据接收。

(11)根据(1)至(10)中任一项所述的接收设备，

其中，所述类是基于所述接收设备或所述用户的区域或者基于所述接收设备或所述用户的注册信息设置的类。

(12)根据(1)至(11)中任一项所述的接收设备，

其中，构成所述接收设备的所述数据处理单元的中间件根据所述类信息确定是经由所述广播还是经由所述网络进行所述数据接收。

(13)根据(1)至(12)中任一项所述的接收设备，

其中，其中记录了数据传送信息的信令数据，所述数据传送信息与用作特定服务工作者(sw)的管理对象的数据相关，所述服务工作者为数据管理程序，以及

所述数据处理单元确定是经由所述广播还是经由所述网络进行接收用作所述服务工作者(sw)的所述管理对象的所述数据。

(14)根据(1)至(13)中任一项所述的接收设备，

其中，在所述接收设备的所述数据处理单元中执行的应用将数据获取请求输出至处理接收数据的所述中间件，并且

响应于所述数据获取请求，所述中间件分析其中记录所述类信息的所述信令数据，并且根据作为分析结果的所获得的所述类信息确定是经由所述广播还是经由所述网络进行所述数据接收。

(15)一种发送信令数据的发送设备，所述信令数据中记录了类信息，所述类信息用于指示允许经由网络进行数据接收的一组接收设备或用户。

(16)根据(15)所述的发送设备，

中，所述信令数据为其中记录了允许经由所述网络进行所述数据接收的所述接收设备或所述用户的类标识符和用作应用于经由广播波或经由网络的数据接收的数据访问信息的url基本模式的信令数据。

(17)一种在接收设备中进行的数据处理方法，包括：

由通信单元接收其中记录了类信息的信令数据，所述类信息指示允许经由网络进行数据接收的一组接收设备或用户；和

由数据处理单元根据所述类信息确定是经由广播还是经由网络进行所述数据接收。

(18)一种在发送设备中进行的数据处理方法，包括：

发送其中记录了类信息的信令数据，所述类信息指示允许经由网络进行数据接收的一组接收设备或用户。

此外，说明书中描述的一系列处理可以通过硬件、软件或两者的复杂配置进行。当通过软件进行处理时，可以将其中记录有处理顺序的程序安装在结合到专用硬件的计算机的存储器中并进行该程序，或者可以将程序安装在能够执行各种处理的通用计算机中并进行程序。例如，程序可以预先记录在记录介质中。程序可以从记录介质安装在计算机中，并且该程序可以经由网络诸如因特网或lan接收且安装在记录介质诸如内部硬盘中。

注意，本说明书中描述的各种处理不仅可以根据描述按时间顺序进行，而且可以根据进行处理的设备的处理性能或根据需要并行或单独进行。此外，在本说明书中，系统是多个设备的逻辑集合配置并且不限于其中各个组件的设备在系统外壳中的配置。

工业适用性

如上所述，根据本公开的实施例的配置，实现了接收设备可以基于信令数据确定是否允许经由网络的数据接收的配置。

具体地，例如，用于指示允许经由网络进行数据接收的一组接收设备或用户的类标识符记录在从发送设备发送到接收设备的信令数据中。

接收设备确定类标识符是否与为接收设备或用户设置的类标识符相同并且当类标识符彼此相同时经由网络进行数据接收。应用于经由广播波或网络数据接收的url基本模式被记录在信令数据中，并且接收设备进行应用了url基本模式的数据获取。

根据本配置，实现了接收设备可以基于信令数据确定是否允许经由网络的数据接收的配置。

参考标记列表

10通信系统

20发送设备

21广播服务器

22数据传送服务器

30接收设备

31tv

32pc

33移动终端

50信令数据

60av段

70其他数据

110中间件

111通信单元(phy/mac)

112信令获取单元

113信令分析单元

114文件获取单元

120http代理服务器

121、122缓存单元

123地址解析单元

130输出控制单元

131显示数据(例如，html/javascript(注册商标))获取&分析单元

132显示处理单元(渲染器)

133存储单元(永久缓存)

140外部设备

141输出控制单元

142存储单元(永久缓存)

751数据处理单元

752通信单元

753存储单元

771数据处理单元

772通信单元

773存储单元

774输入单元

775输出单元

801cpu

802rom

803ram

804总线

805输入/输出接口

806输入单元

807输出单元

808存储单元

809通信单元

810驱动器

811可移除介质。