WO2017141701A1 - 受信装置、送信装置、及び、データ処理方法 - Google Patents

受信装置、送信装置、及び、データ処理方法 Download PDF

Info

Publication number
WO2017141701A1
WO2017141701A1 PCT/JP2017/003531 JP2017003531W WO2017141701A1 WO 2017141701 A1 WO2017141701 A1 WO 2017141701A1 JP 2017003531 W JP2017003531 W JP 2017003531W WO 2017141701 A1 WO2017141701 A1 WO 2017141701A1
Authority
WO
WIPO (PCT)
Prior art keywords
file
resource
distribution
resource file
content
Prior art date
Application number
PCT/JP2017/003531
Other languages
English (en)
French (fr)
Inventor
山岸　靖明
五十嵐　卓也
義治 出葉
Original Assignee
ソニー株式会社
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by ソニー株式会社 filed Critical ソニー株式会社
Priority to US16/076,189 priority Critical patent/US11336957B2/en
Priority to KR1020187021835A priority patent/KR102656879B1/ko
Priority to JP2018500024A priority patent/JPWO2017141701A1/ja
Priority to MX2018009625A priority patent/MX2018009625A/es
Priority to CA3013426A priority patent/CA3013426A1/en
Publication of WO2017141701A1 publication Critical patent/WO2017141701A1/ja

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04H—BROADCAST COMMUNICATION
    • H04H20/00—Arrangements for broadcast or for distribution combined with broadcast
    • H04H20/86—Arrangements characterised by the broadcast information itself
    • H04H20/93—Arrangements characterised by the broadcast information itself which locates resources of other pieces of information, e.g. URL [Uniform Resource Locator]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/45—Management operations performed by the client for facilitating the reception of or the interaction with the content or administrating data related to the end-user or to the client device itself, e.g. learning user preferences for recommending movies, resolving scheduling conflicts
    • H04N21/458—Scheduling content for creating a personalised stream, e.g. by combining a locally stored advertisement with an incoming stream; Updating operations, e.g. for OS modules ; time-related management operations
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/236—Assembling of a multiplex stream, e.g. transport stream, by combining a video stream with other content or additional data, e.g. inserting a URL [Uniform Resource Locator] into a video stream, multiplexing software data into a video stream; Remultiplexing of multiplex streams; Insertion of stuffing bits into the multiplex stream, e.g. to obtain a constant bit-rate; Assembling of a packetised elementary stream
    • H04N21/2362—Generation or processing of Service Information [SI]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04H—BROADCAST COMMUNICATION
    • H04H60/00—Arrangements for broadcast applications with a direct linking to broadcast information or broadcast space-time; Broadcast-related systems
    • H04H60/09—Arrangements for device control with a direct linkage to broadcast information or to broadcast space-time; Arrangements for control of broadcast-related services
    • H04H60/13—Arrangements for device control affected by the broadcast information
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04H—BROADCAST COMMUNICATION
    • H04H60/00—Arrangements for broadcast applications with a direct linking to broadcast information or broadcast space-time; Broadcast-related systems
    • H04H60/76—Arrangements characterised by transmission systems other than for broadcast, e.g. the Internet
    • H04H60/81—Arrangements characterised by transmission systems other than for broadcast, e.g. the Internet characterised by the transmission system itself
    • H04H60/82—Arrangements characterised by transmission systems other than for broadcast, e.g. the Internet characterised by the transmission system itself the transmission system being the Internet
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/235—Processing of additional data, e.g. scrambling of additional data or processing content descriptors
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/25—Management operations performed by the server for facilitating the content distribution or administrating data related to end-users or client devices, e.g. end-user or client device authentication, learning user preferences for recommending movies
    • H04N21/262—Content or additional data distribution scheduling, e.g. sending additional data at off-peak times, updating software modules, calculating the carousel transmission frequency, delaying a video stream transmission, generating play-lists
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/25—Management operations performed by the server for facilitating the content distribution or administrating data related to end-users or client devices, e.g. end-user or client device authentication, learning user preferences for recommending movies
    • H04N21/262—Content or additional data distribution scheduling, e.g. sending additional data at off-peak times, updating software modules, calculating the carousel transmission frequency, delaying a video stream transmission, generating play-lists
    • H04N21/26258—Content or additional data distribution scheduling, e.g. sending additional data at off-peak times, updating software modules, calculating the carousel transmission frequency, delaying a video stream transmission, generating play-lists for generating a list of items to be played back in a given order, e.g. playlist, or scheduling item distribution according to such list
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/431—Generation of visual interfaces for content selection or interaction; Content or additional data rendering
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/435—Processing of additional data, e.g. decrypting of additional data, reconstructing software from modules extracted from the transport stream
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/435—Processing of additional data, e.g. decrypting of additional data, reconstructing software from modules extracted from the transport stream
    • H04N21/4351—Processing of additional data, e.g. decrypting of additional data, reconstructing software from modules extracted from the transport stream involving reassembling additional data, e.g. rebuilding an executable program from recovered modules
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/643—Communication protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/643—Communication protocols
    • H04N21/64315—DVB-H
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/81—Monomedia components thereof
    • H04N21/8126—Monomedia components thereof involving additional data, e.g. news, sports, stocks, weather forecasts
    • H04N21/8133—Monomedia components thereof involving additional data, e.g. news, sports, stocks, weather forecasts specifically related to the content, e.g. biography of the actors in a movie, detailed information about an article seen in a video program
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/83—Generation or processing of protective or descriptive data associated with content; Content structuring
    • H04N21/845—Structuring of content, e.g. decomposing content into time segments
    • H04N21/8456—Structuring of content, e.g. decomposing content into time segments by decomposing the content in the time domain, e.g. in time segments
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/85—Assembly of content; Generation of multimedia applications
    • H04N21/858—Linking data to content, e.g. by linking an URL to a video object, by creating a hotspot
    • H04N21/8586—Linking data to content, e.g. by linking an URL to a video object, by creating a hotspot by using a URL

Definitions

  • the present technology relates to a reception device, a transmission device, and a data processing method, and in particular, a reception device, a transmission device, and data that can perform processing according to distribution of an application resource file associated with content. It relates to the processing method.
  • AIT Application information table
  • CM program or CM
  • the present technology has been made in view of such a situation, and enables processing according to the distribution of the resource file of the application accompanying the content.
  • a receiving device includes: a receiving unit that receives content; and resource distribution information regarding distribution of one or more resource files that are transmitted together with the content and that are part of an application that accompanies the content And a processing unit that performs processing according to the distribution of the resource file based on the acquired resource distribution information.
  • the receiving device may be an independent device, or may be an internal block constituting one device.
  • the data processing method according to the first aspect of the present technology is a data processing method corresponding to the above-described receiving device according to the first aspect of the present technology.
  • distribution of one or a plurality of resource files, which are a part of an application associated with the content is received and transmitted together with the content.
  • Resource distribution information is acquired, and processing according to the distribution of the resource file is performed based on the acquired resource distribution information.
  • the transmission device includes a generation unit that generates resource distribution information regarding distribution of one or more resource files that are part of an application associated with content, and the resource distribution information together with the content.
  • a transmission device including a transmission unit for transmission.
  • the transmission device according to the second aspect of the present technology may be an independent device, or may be an internal block constituting one device.
  • a data processing method according to the second aspect of the present technology is a data processing method corresponding to the transmission device according to the second aspect of the present technology described above.
  • resource distribution information related to distribution of one or more resource files that are part of an application associated with content is generated, and together with the content, Resource distribution information is transmitted.
  • FIG. 1 is a diagram illustrating a configuration example of an embodiment of a transmission system to which the present technology is applied.
  • the system refers to a logical collection of a plurality of devices.
  • the transmission system 1 includes a transmission side system 10 and a reception side client device 20.
  • the data transmitted from the transmission side system 10 is received by the client device 20 via the transmission path 80 as a broadcasting network or the Internet 90 as a communication network.
  • IP Internet Protocol
  • MPEG2-TS Transport Stream
  • the transmission system 10 performs processing for transmitting data compliant with a predetermined standard such as ATSC3.0.
  • the transmission side system 10 includes a DASH server 101, a signaling server 102, an application server 103, a SCH / PKG server 104, a broadcast server 105, and a communication server 106.
  • the DASH server 101 is a server for providing a distribution service compatible with MPEG-DASH (Dynamic Adaptive Streaming over HTTP).
  • MPEG-DASH is a streaming distribution standard according to OTT-V (Over The Top Video) and is a standard related to adaptive streaming distribution using a streaming protocol based on HTTP (Hypertext Transfer Protocol).
  • This MPEG-DASH standard defines a manifest file for describing metadata, which is management information for moving image and audio files, and a file format for transmitting moving image content.
  • the former manifest file is called MPD (Media Presentation Description).
  • the latter file format is also called a segment format.
  • the DASH server 101 receives data for generating MPD metadata, content data, and the like from the outside.
  • the DASH server 101 generates MPD metadata based on data from the outside and transmits it to the signaling server 102.
  • the DASH server 101 generates a content segment (DASH segment) file such as a program or CM based on data from the outside, and transmits the file to the broadcast server 105 or the communication server 106.
  • DASH segment content segment
  • the signaling server 102 receives data for generating signaling from the outside. Further, the signaling server 102 receives MPD metadata from the DASH server 101. The signaling server 102 generates signaling based on data from the outside, MPD metadata, and the like, and transmits the signaling to the broadcast server 105 or the communication server 106.
  • LLS Link Layer Signaling
  • SLS Service Layer Signaling
  • LLS signaling includes metadata such as SLT (Service List).
  • SLT metadata includes basic information indicating the stream and service configuration in the broadcast network, such as information necessary for channel selection (channel selection information).
  • SLS signaling includes metadata such as USD (User Service Description), S-TSID (Service-based Transport Session Instance Description), and MPD (Media Presentation Description).
  • USD User Service Description
  • S-TSID Service-based Transport Session Instance Description
  • MPD Media Presentation Description
  • the USD metadata includes information such as an acquisition destination of other metadata. However, USD may be referred to as USBD (User Service Bundle Description).
  • the S-TSID metadata is an extension of LSID (LCT Session Instance Description) for ATSC 3.0, and is control information for the ROUTE (Real-time Object Delivery Service Unidirectional Transport) protocol.
  • ROUTE Real-time Object Delivery Service Unidirectional Transport
  • FLUTE FLUTE
  • the S-TSID metadata can specify EFDT (Extended FDT) transmitted in the ROUTE session.
  • EFDT is an extension of FDT (File Delivery Table) introduced in FLUTE, and is control information for transfer.
  • MPD metadata is management information for video and audio files that are streamed.
  • metadata such as SLT, USD, S-TSID, and MPD can be described in a markup language such as XML (Extensible Markup Language).
  • the signaling server 102 generates LLS signaling including SLT metadata and SLS signaling including USD metadata, S-TSID metadata, and MPD metadata. However, the signaling server 102 processes the MPD metadata generated by the DASH server 101 as SLS signaling.
  • Application server 103 receives data for generating a file constituting an application from the outside.
  • the application server 103 generates a startup page file (for example, an HTML document file) that constitutes the application and one or a plurality of resource files (for example, an image file, a script file, and the like) based on data from the outside, Transmit to the SCH / PKG server 104.
  • a startup page file for example, an HTML document file
  • resource files for example, an image file, a script file, and the like
  • the application is an application that accompanies content such as a program or CM.
  • an application developed in a markup language such as HTML5 (HyperTextperMarkup Language 5) or a script language such as JavaScript (registered trademark) can be used.
  • the SCH / PKG server 104 determines the distribution schedule of the files (resource files) constituting the application and includes them in the application manifest file. Further, the SCH / PKG server 104 generates a startup package file including an application manifest file, a startup page file, and a resource file, and transmits it to the broadcast server 105.
  • the startup package file does not necessarily include the startup page file and the resource file. Further, the startup page file and the resource file are transmitted to the communication server 106 when distributed via communication.
  • the SCH / PKG server 104 generates an EFDT including transfer control information corresponding to the distribution schedule of the files (resource files) constituting the application, and transmits the EFDT to the broadcast server 105.
  • the transfer control information is information regarding a specific resource file whose distribution schedule may be changed according to the time zone, and details thereof will be described later.
  • the SCH / PKG server 104 transmits an additional resource file, which is a resource file that is referred to later by the startup page file, to the broadcast server 105 or the communication server 106.
  • the broadcast server 105 is a transmitter capable of performing data transmission conforming to digital broadcasting standards such as ATSC 3.0.
  • the broadcast server 105 receives a DASH segment transmitted from the DASH server 101, a signaling transmitted from the signaling server 102, and a file (for example, a startup package file) related to the application transmitted from the SCH / PKG server 104. To do.
  • the broadcast server 105 processes files related to the DASH segment, signaling, and application, and transmits (broadcast broadcast) via the transmission path 80.
  • the communication server 106 is a server that provides various data via the Internet 90 in response to a request from the client device 20 connected to the Internet 90.
  • the communication server 106 receives a DASH segment transmitted from the DASH server 101, a signaling transmitted from the signaling server 102, and a file (for example, an additional resource file) related to the application transmitted from the SCH / PKG server 104. To do.
  • the communication server 106 processes files related to DASH segments, signaling, and applications.
  • the communication server 106 transmits various files via the Internet 90 in response to requests from the client device 20.
  • the client device 20 is a receiver that can receive transmission data compliant with a predetermined standard such as ATSC3.0.
  • the client device 20 is a fixed receiver such as a television receiver or a set-top box, or a mobile receiver such as a smartphone, a mobile phone, or a tablet computer.
  • the client device 20 may be a device mounted on an automobile such as an in-vehicle television. The detailed configuration of the client device 20 will be described later with reference to FIG.
  • the client device 20 receives and processes files such as DASH segments and signaling that are transmitted (broadcast delivery) from the broadcast server 105 via the transmission path 80, thereby processing a video of content such as a broadcast program. Output audio.
  • the client device 20 can access the communication server 106 via the Internet 90 and acquire various files.
  • the client device 20 receives and processes a file such as a DASH segment or MPD metadata transmitted (adaptive streaming delivery) from the communication server 106 via the Internet 90, thereby processing VOD (Video On Demand). ) Output video and audio of content such as programs.
  • the client device 20 executes the application by receiving and processing a file related to the application transmitted from the broadcast server 105 or the communication server 106.
  • the client device 20 executes an application acquired via broadcast or communication along with the content acquired via broadcast or communication.
  • the application not only explicitly displays some information, but may operate in the non-display (in the background) (may be started without being recognized by the user).
  • the client device 20 can perform processing according to the distribution of the resource file of the application based on the distribution schedule information included in the application manifest file of the startup package file and the transfer control information included in the EFDT. Details of the distribution schedule information and transfer control information will be described later with reference to FIGS.
  • the transmission path 80 is not limited to terrestrial (terrestrial broadcast), for example, satellite broadcasting using a broadcasting satellite (BS: Broadcasting Satellite) or communication satellite (CS: Communications Satellite), or cable. It may be cable broadcasting (CATV) using BS: Broadcasting Satellite
  • BS Broadcasting Satellite
  • CS Communications Satellite
  • CATV cable broadcasting
  • the transmission side system 10 transmits ( Digital broadcast signals to be broadcast simultaneously) can be simultaneously received by a plurality of client devices 20 via the transmission path 80.
  • a plurality of transmission side systems 10 can be provided.
  • Each of the plurality of transmission-side systems 10 transmits a digital broadcast signal including a broadcast stream as a separate channel, for example, in a separate frequency band.
  • each channel of the plurality of transmission-side systems 10 is transmitted.
  • the channel for receiving the broadcast stream can be selected from the list.
  • FIG. 2 is a diagram illustrating a configuration example of the client device 20 of FIG.
  • the client device 20 includes a processing unit 201, an input unit 202, a memory 203, a receiving unit 204, a broadcast middleware 205, a DASH client 206, a decoder 207, an output unit 208, a browser 209, and a communication unit 210.
  • the processing unit 201 performs processing for controlling the operation of each unit of the client device 20.
  • the input unit 202 supplies an operation signal corresponding to a user operation to the processing unit 201.
  • the processing unit 201 controls the operation of each unit of the client device 20 based on the operation signal supplied from the input unit 202.
  • the memory 203 stores various data according to control from the processing unit 201.
  • the receiving unit 204 includes a tuner and the like.
  • the receiving unit 204 receives and processes a broadcast wave (digital broadcast signal) transmitted (broadcast broadcast) from the broadcast server 105 via the transmission path 80 by the antenna 221 and processes the data obtained thereby.
  • the broadcast middleware 205 is supplied.
  • the broadcast middleware 205 processes the data supplied from the receiving unit 204 and supplies the processed data to the processing unit 201, the DASH client 206, or the browser 209.
  • MPD metadata and DASH segments are supplied to the DASH client 206
  • data related to the application is supplied to the browser 209
  • data such as signaling is supplied to the processing unit 201.
  • the DASH client 206 is supplied with MPD metadata and a DASH segment from the broadcast middleware 205.
  • the DASH client 206 processes the DASH segment based on the MPD metadata.
  • Video and audio data obtained by processing the DASH segment is supplied to the decoder 207.
  • the decoder 207 decodes video and audio data supplied from the DASH client 206 in accordance with a predetermined decoding method (for example, HEVC (High Efficiency Video Coding), AAC (Advanced Audio Audio Coding), etc.). Video and audio data obtained by this decoding is supplied to the output unit 208.
  • a predetermined decoding method for example, HEVC (High Efficiency Video Coding), AAC (Advanced Audio Audio Coding), etc.
  • the output unit 208 outputs video and audio data supplied from the decoder 207.
  • the client device 20 reproduces content such as a program or CM, and outputs the video and audio.
  • the browser 209 is a browser that supports, for example, HTML5.
  • the browser 209 processes application data supplied from the broadcast middleware 205 and supplies it to the output unit 208.
  • the output unit 208 outputs application data supplied from the browser 209.
  • the client device 20 displays the video of the application in conjunction with the program or the like.
  • the communication unit 210 exchanges data with the communication server 106 via the Internet 90 in accordance with the control from the processing unit 201.
  • MPD metadata and DASH segments are supplied to the DASH client 206, data related to the application is supplied to the browser 209, and data such as signaling is supplied to the processing unit 201. . Since the processing for the data acquired via the communication is the same as the data acquired via the broadcast described above, the description thereof is omitted here.
  • the processing unit 201 includes a control unit 211, a proxy server 212, and a renderer 213.
  • the control unit 211 controls the operation of each unit of the client device 20.
  • the proxy server 212 performs processing related to transmission / reception of data to be processed.
  • the renderer 213 performs processing for outputting data to be processed.
  • the client device 20 is configured as described above.
  • FIG. 3 is a diagram illustrating an example of a protocol stack of the IP transmission scheme of the present technology.
  • the lowest hierarchy is a physical layer.
  • the physical layer corresponds to the frequency band of the broadcast wave allocated for the service (channel).
  • the upper layer of the physical layer is the data link layer.
  • the upper layer of the data link layer is an IP layer.
  • the IP layer corresponds to a network layer in a communication hierarchical model, and an IP packet is specified by an IP address.
  • the upper layer adjacent to the IP layer is a UDP (User Datagram Protocol) layer corresponding to the transport layer in the communication layer model, and the higher layer is ROUTE.
  • UDP User Datagram Protocol
  • SLT metadata is stored and transmitted in an upper layer of the UDP layer, that is, an IP packet (IP / UDP packet) including a UDP packet.
  • IP packet IP / UDP packet
  • the SLS metadata is LLS signaling and includes basic information indicating the configuration of a stream and a service in the broadcast network.
  • ROUTE is a protocol for transferring streaming files and is an extension of FLUTE.
  • some layers are used for signaling (Signaling) and LCC (Locally Cached Content) content (LCC (NRT)).
  • This signaling is SLS signaling and includes metadata such as USD, S-TSID, and MPD, for example. That is, as shown in FIG. 4, the client device 20 first acquires SLT metadata as LLS signaling and then acquires SLS signaling (S-TSID or the like) for each service.
  • S-TSID SLS signaling
  • the LCC content is content that is once stored in the storage of the client device 20 and then played back.
  • LCC Longcally Cached Content
  • NRT Non Real Time
  • the above-described application can be transmitted as LCC content through a ROUTE session.
  • LCC content for example, content such as an electronic service guide (ESG: Electronic Service Guide) may be transmitted through the ROUTE session.
  • ESG Electronic Service Guide
  • DASH segments DASH segments
  • stream data of service components video, audio, subtitles, etc.
  • ISO FFFF ISO Base Media File Format
  • the upper layer of the physical layer is the data link layer (Data Link layer).
  • the upper layer of the data link layer is an IP layer corresponding to the network layer.
  • an upper layer adjacent to the IP layer is a TCP (Transmission Control Protocol) layer corresponding to the transport layer
  • an upper layer adjacent to the TCP layer is an HTTP layer corresponding to the application layer. That is, a protocol such as TCP / IP operating on a network such as the Internet 90 is implemented by these layers.
  • TCP Transmission Control Protocol
  • LCC LCC
  • This signaling includes all signaling such as signaling transmitted by the above-described ROUTE.
  • the LCC content is content acquired via communication, and includes, for example, an application.
  • DASH segments DASH segments
  • the stream data of service components video, audio, subtitles, etc.
  • VOD programs must be transmitted in DASH segment units according to the ISO BMFF standard. become.
  • a one-way broadcasting layer and a part of a two-way communication layer become a common protocol, so Can transmit the stream data of the service components that make up the content in units of DASH segments according to the ISO BMFF standard. For this reason, when both one-way broadcast streaming distribution and two-way communication streaming distribution are performed, the higher-layer protocol is shared. For example, the broadcast server 105 and the client device 20 , Mounting burden and processing burden can be reduced.
  • an application URL (App URL)
  • App URL an application URL
  • an application manifest file described later
  • signaling or the like. Therefore, the application control model can be implemented simply.
  • the client device 20 when a service is selected, the application is acquired and started immediately according to the application URL described in the file or signaling.
  • the URL (startup page URL) of the file (startup page file (for example, HTML document file)) of the first page of the application is determined by the application URL.
  • the client device 20 can be notified.
  • various resources such as image files (for example, jpeg files) and script files (for example, files in which JavaScript (registered trademark) codes are described) referenced in the page file (startup page file) indicated by the URL
  • the file is acquired via broadcasting or communication (via the Internet) at a necessary timing according to the needs of the application after acquiring the file of the first page (startup page file).
  • the browser 209 (FIG. 2) of the client device 20 parses (syntactically analyzes) the file (startup page file) of the page acquired first, and the URL indicating the acquisition source of the necessary resource file is resolved. Then, a request for acquiring the resource file specified by each URL is issued.
  • an HTML document (page) refers to a plurality of resource files
  • the application (page) is displayed when all the resource files are arranged in the memory 203 (FIG. 2) of the client device 20. There is a need to.
  • the browser 209 (FIG. 2) of the client device 20 accesses (the destination to which the HTTP request is sent) is the local proxy server 212 (FIG. 2).
  • the broadcast middleware 205 (FIG. 2) that terminates the signaling and transport protocols defined in ATSC 3.0 expands the signaling and content distributed via the broadcast in the local file system, and the local proxy server 212 (FIG. 2).
  • the server side script (module) or the like mounted on the DASH client 206 (FIG. 2) or the browser 209 (FIG. 2) directly or integrally with the broadcast middleware 205 (FIG. 2).
  • a model that responds to an acquisition request from an application to be executed (client) is assumed.
  • the browser 209 parses the first HTML document file (startup page file) and issues a request for acquiring a resource file referenced by the HTML document file
  • the resource The file must be in a state where it is expanded on the local file system, or a server side script (module) of the local proxy server 212 (FIG. 2) must be accessible.
  • the resource file acquisition request will time out without being able to display all resource files of the HTML document file (startup page file), and depending on the user, It will be mistakenly recognized that the application has been loaded in an incomplete state. Therefore, it is essential that all resource files are prepared together first.
  • the resource file to be presented for each scene is generally changed (added) sequentially. If the necessary resource files cannot be viewed over the entire program, protocol processing and memory management cannot be optimized. That is, how many resource files are required at what timing in the future, overlooking the entire program, how the computing resources of the client device 20 are allocated to each service (program). It is necessary to optimize whether to distribute to each other.
  • the transfer control attribute including the URL for the startup package file (startup package URL) is described in EFDT, which is the control information of the ROUTE protocol, and the entry of the target application is entered in the application manifest file included in the startup package file.
  • a URL startup page URL
  • a startup page file for example, an HTML document file
  • this startup page URL corresponds to the above-described application URL (FIG. 5).
  • the distribution lifecycle control is not performed, and the startup page URL (application URL in FIG. 5) is immediately performed. Since the application is started (obtained), the application control model can be implemented more simply.
  • the startup package file is a file configured in the ROUTE package mode, and can include a startup page file (for example, an HTML document file) and a resource file (for example, an image file or a script file).
  • a startup page file for example, an HTML document file
  • a resource file for example, an image file or a script file
  • the application manifest file of the startup package file should be able to describe attributes that can be used to optimize distribution scheduling for all resource files included in the target application. If there is a resource list for bird's-eye view of such an entire resource file, the reliability of the resource file acquisition timing can be improved. Furthermore, the transfer attribute of each resource file can be described in the EFDT that describes the transfer control attribute including the URL of each file.
  • an LCT channel (session is described by an S-TSID used for control of the service layer of the ROUTE protocol. ) Is assigned to transfer of LCC content which is non-real-time content.
  • the transfer control parameters of the file group transferred in the channel are described by the EFDT transmitted in the file mode.
  • the file mode (File Mode) is a mode for transferring a single file.
  • the package mode (Package Mode) is a mode in which a plurality of files are transferred together (packaged) as a package.
  • FIG. 7 is a diagram illustrating an example of the structure of a startup package file.
  • the startup package file is distributed in the package mode, and a startup page file (for example, an HTML document file) and a resource file (for example, an image file, a script file, etc.) can be bundled together with the application manifest file.
  • a startup page file for example, an HTML document file
  • a resource file for example, an image file, a script file, etc.
  • the application manifest file uses, for example, Web App Manifest ("https://www.w3.org/TR/appmanifest/”), which is being standardized by W3C (World Wide Web Consortium). can do.
  • FIG. 7 which format the application manifest file uses is determined by the content-Type attribute of the item element of the MetadataEnvelope stored in the root part of the Multipart MIME format used in the package mode. It can be identified by the specified MIME type.
  • the upper item element corresponds to the format of the application manifest file
  • the lower item element corresponds to the format of the startup page file.
  • FIG. 8 shows an example of the format of W3C Web App Manifest.
  • the value of the startup page URL can be specified for "start_url”.
  • distribution schedule information related to the distribution schedule of one or more resource files that are part of the application is distributed as the resource distribution information.
  • the distribution schedule information Cannot be specified.
  • extended Web App Manifest (hereinafter also referred to as extended Web App Manifest) from the W3C Web App Manifest (Fig. 8)
  • the extended Web App Manifest is used as the format of the application manifest file.
  • “application / atsc-manifest + json” is specified as the content-Type attribute of the item element of MetadataEnvelope in the startup package file (FIG. 7) (FIG. 9).
  • “json” means being expressed in JSON (JavaScript (registered trademark) ⁇ Object Notation) format, which is a kind of text format.
  • FIG. 10 is a diagram illustrating an example of the format of the extended Web App Manifest.
  • An example of this format is described in JSON format.
  • This JSON-formatted object consists of a pair of key / value pairs separated by colons (:), and zero or more of these pairs separated by commas (,). The whole is enclosed in curly braces ( ⁇ ). It is expressed by
  • delivery schedule information for each resource file can be specified as a delivery schedule attribute.
  • the distribution schedule attribute for example, information indicating the acquisition destination of the resource file, the size of the resource file, and the distribution time of the resource file can be specified.
  • the value indicating the file URL of the resource file is designated as a pair for the key “url”.
  • the file URL of the resource file is a mandatory value.
  • a value indicating the size (in bytes) of the resource file is specified as a pair for the key "sizes”.
  • the size of the resource file is an arbitrary value.
  • the value indicating the delivery start time in absolute time is specified as a pair for the key that is “absoluteDeliveryTimeStart”. Also, a value indicating the delivery end time in absolute time is specified as a pair for the key “absoluteDeliveryTimeEnd”.
  • the format of the distribution start time and the distribution end time in absolute time can be “YYYY-MM-DDTHH: mm: ssZ”. Further, the distribution start time and the distribution end time in absolute time are arbitrary values.
  • a value indicating a distribution start time at a relative time from the beginning of a normal play time (Normal Play Time) program is specified as a pair.
  • a value indicating a distribution end time at a relative time from the head of a normal play time (Normal Play Time) program is specified as a pair for the key “relativeDeliveryTimeEnd”.
  • the format of the distribution start time and the distribution end time in relative time can be “THH: mm: ss.fffffff”.
  • the distribution start time and the distribution end time at the relative time are arbitrary values.
  • FIG. 11 is a diagram illustrating a description example of the extended Web App Manifest.
  • a URL “ResourceFile-10-url” is specified as the file URL of the resource file, and 123 bytes are specified as the size of the resource file.
  • “T00: 10: 22.123456” and “T00: 12: 33.654321” are specified as the distribution start time and distribution end time at the relative time of the resource file. ing.
  • a URL “ResourceFile-11-url” is specified as the file URL of the resource file, and 4567 bytes are specified as the size of the resource file.
  • “T00: 13: 44.345678” and “T00: 16: 55.654321” are specified as the distribution start time and distribution end time at the relative time of the resource file. ing.
  • the example in FIG. 12 represents a case where the resource file is distributed via broadcast.
  • the communication server 106 on the Internet 90 receives the resource file during a specified period. This indicates that the target resource file can be acquired.
  • FIG. 13 is a diagram for explaining transfer control information described in the EFDT.
  • transfer control information transfer control attribute
  • distribution schedule information distribution schedule attribute
  • This transfer control information is information for performing detailed transfer control of a specific resource file whose distribution schedule may be changed according to the time zone.
  • transfer control information for performing detailed transfer control for each resource file can be specified as a transfer control attribute.
  • the transfer control attribute for example, at least one of the retransmission cycle and the retransmission end date / time of each resource file can be designated.
  • “everyDay”, “everyHour”, “everyMinute”, “everySecond”, etc. can be specified as the attribute of the resource file retransmission cycle (Retransmission-Cycle).
  • EveryDay means that the target resource file may be retransmitted once a day. In other words, when “everyDay” is specified as the attribute of the retransmission period, the client device 20 is surely likely to be reacquired after waiting for one day.
  • EveryHour means that there is a possibility of resending once per hour.
  • “everyMinute” means that there is a possibility of resending once per minute.
  • “everySecond” means that there is a possibility of retransmission once per second.
  • the resource file retransmission end date (Retransmission-End) attribute should be specified in the format "YYYY-MM-DDTHH: mm: ss", for example, indicating the date and time when the retransmission ends. Can do.
  • “everyMinute” is described as the attribute of the resource file retransmission cycle (Retransmission-Cycle), and “2012-03- 14T00: 00: 00 "is described.
  • the client device 20 can predict when a missed resource file (for example, an image file) will be retransmitted by using the attribute of the resending period and resending end date / time of the resource file as a hint. Scheduling for acquisition can be optimized.
  • a missed resource file for example, an image file
  • At least one of the attributes of the resource file retransmission cycle (Retransmission-Cycle) and retransmission end date and time (Retransmission-End) may be described.
  • the retransmission end is completed without describing the attribute of the retransmission cycle.
  • the date / time attribute it means that the target resource file is retransmitted only once by the date / time (time) specified by the retransmission end date / time attribute.
  • the delivery schedule information is specified by the application manifest file using the extended Web ⁇ ⁇ App Manifest format, so that the client device 20 recognizes the size and delivery timing of each resource file over the entire program. can do. Further, by specifying a detailed retransmission cycle and retransmission end date and time within the distribution schedule section of each resource file as transfer control information by EFDT, the client device 20 has more fine-tuned resources for receiving processing. In addition, optimal allocation can be performed.
  • FIG. 14 is a diagram illustrating a configuration example of a typical application.
  • the broadcast program includes scenes 1 to 3, and transitions are made in the order of scene 1 (Scene 1), scene 2 (Scene 2), and scene 3 (Scene 3).
  • a startup page file (StartUpPage) that is the first entry of the application is presented.
  • the startup page file is composed of, for example, an HTML document file, and includes various resource files (Resource1, Resource2, Resource3) such as an image file (for example, a jpeg file) and a script file (for example, a file in which a JavaScript (registered trademark) code is described). ) Is simultaneously presented as the first view of the application (The 1 st View).
  • the application from the second view, switch to the third view (The 3 rd View), the contents of the third view is presented.
  • the HTML document file itself is the same as the first startup page file, but the presented resource file (Resource4) is deleted as a newly presented content, and a new resource file is created. The difference is that (Resource5) is added.
  • display contents (view contents) corresponding to each scene are presented by adding or deleting a referenced resource file with the startup page file as the center of control.
  • display contents view contents
  • an inline frame iframe element defined in HTML
  • the broadcast mode the hybrid mode
  • the communication mode can be set as the distribution mode.
  • Broadcast mode is a mode in which a startup page file (HTML document file) that constitutes an application and a resource file that is referenced by the startup page file are completed by distribution via broadcasting.
  • HTML document file HTML document file
  • Hybrid mode is a mode in which a startup page file (HTML document file) that constitutes an application and resource files other than resource files that are always referenced in the startup page file are distributed via broadcast or communication It is.
  • the startup package file URL is always described in the EFDT, and for other resource files, the transfer control attribute is described only for those distributed via broadcasting.
  • the startup page file and the resource file referenced by the startup page file are acquired and displayed atomically.
  • the communication mode (Broadband Only Mode) is a mode in which the startup page file (HTML document file) constituting the application and all resource files referenced by the startup page file are distributed via communication.
  • the startup page file URL is always described in the EFDT, and only the application manifest file is stored in the startup package file, transfer control attributes of other files are not described.
  • FIG. 15 is a diagram for explaining the flow of data related to the application associated with the content, which is processed when the broadcast mode is set in the client device 20 (FIG. 1). Note that the data flow related to the application in FIG. 15 corresponds to the display contents (view contents) of the application presented in accordance with each scene of the broadcast program shown in FIG.
  • the EFDT distributed in the LCC channel of the ROUTE session is represented in time series on the upper side of the time axis from the left side to the right side in the figure, while the LCC of the ROUTE session is shown on the lower side of the time axis.
  • the startup package file and resource file distributed on the channel are schematically shown.
  • the version of the EFDT distributed in the file mode is updated in time series, but the first acquired EFDT of Ver1.0 (v.1) is distributed during the scene 1 (FIG. 14).
  • the startup package URL is described in addition to the EFDT URL for identifying the EFDT.
  • the startup package file distributed in the package mode is acquired in accordance with the startup package URL of this EFDT (Ver1.0) (S11).
  • a startup package URL (StartUpPackageURL) for identifying the startup package file is described
  • an application manifest file (AppManifest)
  • a startup page file (HTML document file)
  • a resource file (Resource1, Resource2, Resource3)
  • the files that are bundled with the application manifest file include a startup page file (HTML document file) and resource files (Resource1, Resource2, Resource3). These files are the application manifest. It is guaranteed that it will be acquired at the same time as the file.
  • resource file is, for example, an image file or a script file.
  • Resource 1 is a file in which a JavaScript (registered trademark) code is described
  • Resource 2 is a jpeg format image file
  • Resource 3 is an mp4 format video file.
  • the resource file (Resource1, Resource2, Resource3) is referred to by this startup page file (HTML document file), so that the first view (FIG. 14) of the application is presented.
  • the application manifest file adopts the format of extended Web App Manifest (Fig. 10).
  • the startup page URL (StartUpPageURL)
  • the resource It includes distribution schedule information (Attributes) related to the distribution schedule for each file.
  • This startup page URL indicates an application entry file (startup page file).
  • the distribution schedule information includes information on the file URL, size, and distribution time of each resource file.
  • the startup package URL acquired according to the EFDT of Ver1.0 is referred to by the startup package URL of Ver2.0 (S12), and the resource file (Resource4) distributed in the file mode via broadcasting is referred to by the resource file URL. , Resource5) is acquired (S13, S14).
  • the startup page file itself is the same as the first startup page file, but the second view (FIG. 14) in which a new resource file (Resource4) is added or the resource file ( A third view (FIG. 14) in which Resource4) is deleted and a resource file (Resource5) is added is presented.
  • the startup page file (HTML document file) refers to Resource1 to Resource4 as resource files.
  • the startup page file (HTML document file) refers to Resource1 to Resource3 and Resource5 as resource files.
  • the EFDT version is updated sequentially from Ver2.0 (v.2) to Ver M (v.M) during the transition from Scene 2 to Scene 3.
  • the Ver.M EFDT is an EFDT distributed during the scene 3 (FIG. 14), and describes the URL of the resource file (ResourceN) along with the startup package URL.
  • the startup package URL acquired according to the EFDT of Ver1.0 is referenced by the startup package URL of Ver M (S15), and the resource file (Resource N) distributed in the file mode via broadcasting is referred to by the resource file URL ) Is acquired (S15, S16).
  • the startup page file (HTML document file) itself is the same as the initial startup page file, but the resource file (Resource4 to Resource N-1) is deleted and the resource file (Resource N) is added.
  • a th view (FIG. 14) is presented.
  • the startup page file (HTML document file) refers to Resource1 to Resource3 and Resource N as resource files.
  • steps S301 to S302 in FIG. 16 is executed by the application server 103 (FIG. 1).
  • step S301 the application server 103 performs an application authoring process.
  • an application authoring process a startup page file and one or a plurality of resource files are generated, and an application including these file groups is generated.
  • step S302 the application server 103 transmits to the SCH / PKG server 104 the file group such as the startup page file and one or a plurality of resource files generated in the process of step S301.
  • steps S401 to S408 in FIG. 16 is executed by the SCH / PKG server 104 (FIG. 1). Further, the SCH / PKG server 104 receives the file group transmitted in the process of step S302.
  • step S401 the SCH / PKG server 104 determines a distribution schedule of files (resource files) constituting the application.
  • step S402 the SCH / PKG server 104 generates an EFDT according to the distribution schedule determined in the process of step S401.
  • the EFDT can include transfer control information according to the distribution schedule determined in step S401.
  • step S403 the SCH / PKG server 104 transmits the EFDT generated in the process of step S402 to the broadcast server 105.
  • step S404 the SCH / PKG server 104 generates a startup package file based on the file group (for example, the startup page file and one or a plurality of resource files) generated in the process of step S301.
  • the application manifest file stored in the startup package file may include distribution schedule information corresponding to the distribution schedule determined in the processing of step S401 by adopting the format of extended Web App Manifest (FIG. 10). it can.
  • step S405 the SCH / PKG server 104 transmits the startup package file generated in the process of step S404 to the broadcast server 105.
  • step S406 the SCH / PKG server 104 generates an EFDT according to the distribution schedule determined in the process of step S401.
  • the EFDT can include transfer control information according to the distribution schedule determined in step S401.
  • step S407 the SCH / PKG server 104 transmits the EFDT generated in the process of step S406 to the broadcast server 105.
  • step S408 the SCH / PKG server 104 transfers the additional resource file among the file group generated in the process of step S301 to the broadcast server 105.
  • Steps S501 to S504 in FIG. 16 are executed by the broadcast server 105 (FIG. 1).
  • the broadcast server 105 In the broadcast server 105, the EFDT transmitted in the process of step S403 or S407, the startup package file transmitted in the process of step S405, and the additional resource file transmitted in the process of step S407 are received.
  • step S501 the broadcast server 105 transmits (simultaneous broadcast delivery) the EFDT generated in the process of step S402 via the transmission path 80 in the file mode.
  • step S502 the broadcast server 105 transmits the start-up package file generated by the process in step S404 via the transmission path 80 (simultaneous broadcast distribution) in the package mode.
  • step S503 the broadcast server 105 transmits (simultaneous broadcast delivery) the EFDT generated in the process of step S406 via the transmission line 80 in the file mode.
  • step S504 the broadcast server 105 transmits the additional resource file transferred in step S408 (the resource file generated in step S301) via the transmission line 80 in the file mode (broadcast distribution). )
  • step S201 the broadcast middleware 205 acquires SLT metadata stored in the IP / UDP packet and SLS signaling transmitted in the ROUTE session.
  • SLS signaling by acquiring USD metadata, S-TSID metadata is acquired in accordance with information described therein.
  • step S202 the broadcast middleware 205 acquires the EFDT distributed in the file mode on the LCC channel of the ROUTE session based on the SLS signaling (S-TSID metadata) acquired in the process of step S201.
  • S-TSID metadata SLS signaling
  • step S203 the broadcast middleware 205 parses the EFDT acquired in step S202.
  • step S204 the broadcast middleware 205 acquires a startup package file distributed in the package mode on the LCC channel of the ROUTE session based on the analysis result of the process in step S203.
  • step S205 the broadcast middleware 205 determines whether a new startup page URL is described in the application manifest file of the startup package file acquired in the process of step S204.
  • step S205 If it is determined in step S205 that a new startup page URL is not described, the process returns to step S201, and the subsequent processes are repeated. If the process of steps S201 to S205 is repeated and it is determined in the determination process of step S205 that a new startup page URL is described, the process proceeds to step S206.
  • step S206 the broadcast middleware 205 notifies the browser 209 of the (new) startup page URL described in the application manifest file of the startup package file. Thereby, the activation of the application is started.
  • the startup page file and one or more resource files stored in the startup package file acquired in step S204 are: It is developed on the local file system of the memory 203, or the server side script of the proxy server 212 is accessible. In other words, when the application is started, a response for the startup page file and the resource file is prepared so that the request from the browser 209 can be immediately answered.
  • the application manifest file adopts the format of extended Web App Manifest (Fig. 10)
  • the delivery schedule information (resource file size and delivery time) for each resource file is described.
  • the information is analyzed by the broadcast middleware 205 or the processing unit 201 (control unit 211), and the analysis result is stored in the memory 203.
  • the analysis result is stored in the memory 203.
  • memory management of the memory 203 if there is sufficient capacity in the memory 203, first, according to the analysis result of the distribution schedule information, first according to the total number of bytes of each resource file.
  • the storage area can be secured in the memory unit 203.
  • the analysis result of the distribution schedule information is referred to and the storage area required at that time is determined. Processing such as securing can be performed. Further, when the capacity of the memory 203 is not sufficient, before the EFDT of the resource file to be acquired in the future is acquired, the response of the resource file (at the appropriate timing) according to the analysis result of the distribution schedule information When the preparation of () is required, it is possible to perform processing such as securing a necessary storage area in the memory 203 in advance by estimating the size of the resource file.
  • the process using the distribution schedule information (analysis result) described here is an example, and various processes according to the distribution of the resource file can be performed.
  • step S221 the browser 209 requests a startup page file from the proxy server 212 according to the startup page URL notified in the process of step S206.
  • step S207 the proxy server 212 responds to the browser 209 with a startup page file that is prepared for a response in response to a request for the startup page file from the browser 209.
  • the browser 209 can acquire the startup page file from the proxy server 212.
  • step S222 the browser 209 requests the proxy server 212 for a resource file in the startup page file bundled with the startup page file.
  • step S208 in response to the request for the resource file in the startup page file from the browser 209, the proxy server 212 converts the resource file in the startup page file included in the startup page file that is prepared for the response to the browser. Reply to 209.
  • step S223 the browser 209 presents the startup page file via the renderer 213 based on the startup page file acquired from the proxy server 212 and the resource file in the startup page file. Thereby, the application (startup page thereof) is displayed together with contents such as a broadcast program.
  • step S209 the broadcast middleware 205 acquires the EFDT distributed in the file mode on the LCC channel of the ROUTE session based on the SLS signaling (S-TSID metadata) acquired in the process of step S201.
  • S-TSID metadata SLS signaling
  • step S210 the broadcast middleware 205 parses the EFDT acquired in step S209. It is assumed that the EFDT version (for example, Ver2.0) acquired in the process of step S209 is newer than the EFDT version (for example, Ver1.0) acquired in the process of step S202.
  • transfer control information (FIG. 13) is described as the transfer control attribute of the EFDT
  • the broadcast middleware 205 or the processing unit 201 (control unit 211) analyzes the transfer control information and responds to the analysis result. Can be processed. For example, since the transfer control information (FIG.
  • the broadcast middleware 205 specifies the specific resource to be retransmitted according to the retransmission cycle and retransmission end date / time. You can get the file.
  • step S211 the broadcast middleware 205 acquires an additional resource file distributed in the file mode on the LCC channel of the ROUTE session based on the analysis result in step S210.
  • the browser 209 monitors the presentation timing of the additional resource file (S224). In step S225, the browser 209 determines whether the presentation timing of the additional resource file has been detected based on the monitoring result in step S224.
  • the additional resource can be programmed by programming the timer so that the timer fires at that timing.
  • the timing to present the file can be detected.
  • additional resources can be added by programming a script so that the startup page file has an external event (for example, a stream event issued by the application server 103 transferred in-band to a content stream or an interaction with a user). Can be detected.
  • the same startup page file may be used for the entire program, and it is not necessary to update the startup page file. That is, since there is no update of the startup page file in the startup package file, the resource file (for example, Resource1, Resource2, Resource3) first referenced in the application manifest file, the startup page file, and the startup page file is not always updated. Therefore, there is no update of the startup package file itself.
  • the resource file for example, Resource1, Resource2, Resource3
  • step S225 when it is determined that the presentation timing of the additional resource file has not been detected, the process returns to step S224, and the monitoring processes in steps S224 to S225 are repeated. If it is determined in step S225 that the presentation timing of the additional resource file has been detected, the process proceeds to step S226.
  • step S226 the browser 209 requests the proxy server 212 for an additional resource file in accordance with the detection result of the process in step S225 (presentation timing detection).
  • step S212 the proxy server 212 responds to the browser 209 with an additional resource file that is prepared for a response in response to an additional resource file request from the browser 209. Accordingly, the browser 209 can acquire the additional resource file from the proxy server 212.
  • step S227 the browser 209 controls the renderer 213 to present the additional resource file acquired from the proxy server 212.
  • the information of the additional resource is added to the application (the startup page).
  • FIG. 19 is a diagram illustrating a data flow regarding an application associated with content, which is processed when the hybrid mode is set in the client device 20 (FIG. 1). Note that the flow of data related to the application in FIG. 19 corresponds to the display content (view content) of the application presented in accordance with each scene of the broadcast program shown in FIG.
  • the client device 20 obtains a startup package file distributed in the package mode in accordance with the startup package URL of EFDT (Ver1.0) as in S11 (broadcast mode) of FIG. 15 described above (S21). ).
  • the startup package file contains the application manifest file, startup page file (HTML document file), and resource files (Resource1, Resource2, Resource3). It is packaged.
  • the first view (FIG. 14) of the application is presented by referring to the resource files (Resource1, Resource2, Resource3) by the startup page file (HTML document file). Is done.
  • the resource file (Resource5) is distributed via broadcast, while the resource file (Resource4) is distributed via communication. Only information related to the resource file (Resource5) to be distributed is described.
  • the startup package file acquired according to the EFDT of Ver1.0 is referred to by the startup package URL of Ver2.0 EFDT (S22), and the resource file (Resource4) distributed via communication is referred to by the resource file URL Or, a resource file (Resource5) distributed via broadcasting is acquired (S23, S24).
  • the resource file URL of the resource file (Resource4) distributed via communication for example, the file URL of each resource file (Resource4) of the distribution schedule information of the application manifest file is used. Further, the resource file URL described in the EFDT of Ver2.0 is used as the resource file URL of the resource file (Resource5) distributed via broadcasting.
  • the startup page file itself is the same as the initial startup page file, but the resource file (Resource4) distributed via communication is added 2
  • a th view (FIG. 14) is presented.
  • the startup page file itself is the same as the initial startup page file, but the resource file (Resource4) is deleted and the resource file (Resource5) distributed via broadcasting is used. ) Is added for the third view (FIG. 14).
  • the EFDT version is updated sequentially from Ver2.0 (v.2) to Ver M (v.M).
  • the Ver.M EFDT is an EFDT distributed during scene 3 (FIG. 14), and only the startup package URL is described.
  • the startup package file acquired according to the EFDT of Ver1.0 is referred to by the startup package URL of Ver M EFDT (S25), and the resource file (Resource) N) distributed via communication is referred to by the resource file URL Is acquired (S26).
  • the resource file URL of the resource file (Resource ⁇ ⁇ ⁇ N) distributed via communication
  • the file URL of each resource file in the distribution schedule information of the application manifest file can be used.
  • the startup page file itself is the same as the initial startup page file, but the Nth view in which the resource file (Resource N) distributed via communication is added (FIG. 14). Is presented.
  • step S321 to S322 in FIG. 20 the authoring process is performed by the application server (FIG. 1), as in steps S301 to S302 in FIG. 16, and a file group constituting the application is generated.
  • the SCH / PKG server 104 determines the distribution schedule, generates the EFDT, and generates the startup package file.
  • the transfer destination of the additional resource file includes not only the broadcast server 105 but also the communication server 106.
  • step S428 the SCH / PKG server 104 transfers a part of the additional resource file in the file group generated in the process of step S321 to the broadcast server 105.
  • step S429 the SCH / PKG server 104 transfers a part of the additional resource file in the file group generated in the process of step S321 to the communication server 106.
  • the broadcast server 105 performs EFDT and additional resource files in file mode and startup package file in package mode via the transmission line 80. Sent (simultaneous broadcast delivery).
  • step S621 the communication server 106 determines whether an additional resource file is requested from the client device 20 via the Internet 90. If it is determined in step S621 that an additional resource file is not requested, the determination process in step S621 is repeated.
  • step S621 determines whether an additional resource file has been requested. If it is determined in step S621 that an additional resource file has been requested, the process proceeds to step S622.
  • step S622 the communication server 106 distributes the additional resource file transferred in step S429 (the resource file generated in step S321) to the requesting client device 20 via the Internet 90. To do.
  • the broadcast middleware 205 processes the EFDT and the startup package file distributed from the broadcast server 105, and creates an application manifest file for the startup package file.
  • the startup page URL is notified to the browser 209.
  • the proxy server 212 returns a startup page file and a resource file in the startup file.
  • the browser 209 requests the startup page file and the resource file in the startup file as in steps S221 to S223 in FIG.
  • a startup page is presented.
  • steps S239 to S242 in FIG. 22 the EFDT and additional resource file distributed from the broadcast server 105 are processed by the broadcast middleware 205 in the same manner as in steps S209 to S212 in FIG.
  • the proxy server 212 returns an additional resource file in response to a request from the browser 209.
  • steps S254 to S257 in FIG. 22 as in steps S224 to S227 in FIG. 18, the presentation timing of the additional resource file distributed via broadcasting is monitored by the browser 209, and the presentation timing is reached. Additional resource files are requested.
  • the renderer 213 presents an additional resource file in response to a response from the proxy server 212.
  • the additional resource file distributed from the broadcast server 105 via the broadcast is presented.
  • the additional resource file is distributed from the communication server 106 via communication, the following process is performed.
  • step S258 in FIG. 22 the browser 209 monitors the presentation timing of the additional resource file distributed via communication.
  • step S259 the browser 209 determines whether the presentation timing of the additional resource file distributed via communication is detected based on the monitoring result in step S258.
  • step S259 If it is determined in step S259 that the presentation timing of the additional resource file has not been detected, the process returns to step S258, and the monitoring processes in steps S258 to S259 are repeated. If it is determined in step S259 that the presentation timing of the additional resource file has been detected, the process proceeds to step S260.
  • step S260 the browser 209 requests the proxy server 212 for an additional resource file according to the detection result (of the presentation timing detection) of the process in step S259.
  • step S243 the proxy server 212 requests an additional resource file from the communication server 106 via the Internet 90 in response to a request for the additional resource file from the browser 209.
  • step S244 the proxy server 212 acquires an additional resource file distributed from the communication server 106 via the Internet 90 in response to the request in step S243.
  • step S245 the proxy server 212 returns the additional resource file acquired in step S244 to the browser 209. Accordingly, the browser 209 can acquire the additional resource file from the proxy server 212.
  • step S261 the browser 209 controls the renderer 213 to present the additional resource file acquired from the proxy server 212. As a result, the information of the additional resource is added to the application (the startup page).
  • FIG. 23 is a diagram for explaining the flow of data regarding the application associated with the content, which is processed when the communication mode is set in the client device 20 (FIG. 1). Note that the flow of data related to the application in FIG. 23 corresponds to the display content (view content) of the application presented in accordance with each scene of the broadcast program shown in FIG.
  • the client device 20 acquires a startup package file distributed in the package mode in accordance with the startup package URL of EFDT (Ver1.0) in the same manner as S11 (broadcast mode) in FIG. 15 described above (S31). ).
  • This startup package file includes an application manifest file in addition to a startup package URL that identifies the startup package file.
  • the file URL of each resource file is described as distribution schedule information.
  • the client device 20 accesses the communication server 106 via the Internet 90 in accordance with these URLs, thereby delivering a startup page file (HTML document file) and resource files (Resource1, Resource2, Resource3) distributed via communication. Can be obtained.
  • HTML document file HTML document file
  • resource files Resource1, Resource2, Resource3
  • the first view (FIG. 14) of the application is presented by referring to the resource files (Resource1, Resource2, Resource3) by the startup page file (HTML document file). Is done.
  • the contents of EFDT are changed and the version is updated from Ver1.0 (v.1) to Ver2.0 (v.2).
  • the EFDT of Ver2.0 is an EFDT distributed during scene 2 (FIG. 14), and describes a startup package URL.
  • the resource files (Resource4, Resource5) presented in the first part and the second part of the scene 2 are both distributed via communication. It is unnecessary.
  • the startup package file acquired according to the EFDT of Ver1.0 is referred to by the startup package URL of EFDT of Ver2.0 (S32), and the resource file (Resource4, Resource4, distributed via communication is transmitted by the resource file URL) Resource5) is acquired (S33, S34).
  • the resource file URL of the resource file (Resource4, Resource5) distributed via communication for example, the file URL of each resource file (Resource4, Resource5) of the distribution schedule information of the application manifest file can be used.
  • the startup page file itself is the same as the initial startup page file, but the resource file (Resource4) distributed via communication is added 2
  • a th view (FIG. 14) is presented.
  • the startup page file itself is the same as the first startup page file, but the resource file (Resource4) is deleted and the resource file (Resource5) distributed via communication is used. ) Is added for the third view (FIG. 14).
  • the EFDT version is updated sequentially from Ver2.0 (v.2) to Ver M (v.M).
  • the Ver.M EFDT is an EFDT distributed during scene 3 (FIG. 14), and only the startup package URL is described.
  • the startup package file acquired according to the EFDT of Ver1.0 is referred to by the startup package URL of Ver M's EFDT (S35), and the resource file (Resource N) distributed via communication is referred to by the resource file URL Is acquired (S36).
  • the resource file URL of the resource file (Resource ⁇ ⁇ ⁇ N) distributed via communication
  • the file URL of each resource file in the distribution schedule information of the application manifest file can be used.
  • the startup page file itself is the same as the initial startup page file, but the Nth view in which the resource file (Resource N) distributed via communication is added (FIG. 14). Is presented.
  • step S341 to S342 in FIG. 24 as in steps S301 to S302 in FIG. 16, authoring processing is performed by the application server (FIG. 1), and a file group constituting the application is generated.
  • steps S421 to S427 in FIG. 24 the process of determining the distribution schedule, generating the EFDT, and generating the startup package file is performed by the SCH / PKG server 104 (FIG. 1), as in steps S401 to S408 in FIG.
  • the difference is that the transfer destination of the startup page file, the resource file in the startup page file, and the additional resource file is not the broadcast server 105 but the communication server 106.
  • the broadcast server 105 uses the EFDT in the file mode and the startup package file in the package mode via the transmission line 80. Transmitted (simultaneous broadcast delivery).
  • Steps S641 to S646 in FIG. 24 are executed by the communication server 106 (FIG. 1).
  • the communication server 106 receives the startup page file transferred in step S446, the resource file in the startup page file, and the additional resource file transferred in step S447.
  • steps S641 to S646 in FIG. 24 various files are distributed in response to requests from the client device 20 via the Internet 90, as in steps S621 to S622 in FIG.
  • step S641 the communication server 106 determines whether a startup page file is requested from the client device 20 via the Internet 90. If it is determined in step S641 that a startup page file is not requested, the determination process in step S641 is repeated.
  • step S641 if it is determined in step S641 that a startup page file has been requested, the process proceeds to step S642.
  • step S642 the communication server 106 transmits the startup page file transferred in step S446 (the startup page file generated in step S341) to the requesting client device 20 via the Internet 90. To deliver.
  • step S643 the communication server 106 determines whether a resource file in the startup page file has been requested from the client device 20 via the Internet 90. If it is determined in step S643 that the resource file in the startup page file is not requested, the determination process in step S643 is repeated.
  • step S643 if it is determined in step S643 that the resource file in the startup page file has been requested, the process proceeds to step S644.
  • step S644 the communication server 106 transmits the resource file in the startup page file transferred in step S446 (the resource file generated in step S341) to the requesting client device 20 via the Internet 90. To deliver through.
  • step S645 the communication server 106 determines whether an additional resource file is requested from the client device 20 via the Internet 90. If it is determined in step S645 that an additional resource file is not requested, the determination process in step S645 is repeated.
  • step S645 determines whether an additional resource file has been requested. If it is determined in step S645 that an additional resource file has been requested, the process proceeds to step S646.
  • step S646 the communication server 106 distributes the additional resource file transferred in step S447 (the resource file generated in step S341) to the requesting client device 20 via the Internet 90. To do.
  • the broadcast middleware 205 processes the EFDT and the startup package file distributed from the broadcast server 105 in the same manner as steps S201 to S205 in FIG. It is determined whether a new startup page URL is described (S275).
  • step S275 If it is determined in step S275 that a new startup page URL is described in the application manifest file, the process proceeds to step S276.
  • step S276 the proxy server 212 requests a startup page file from the communication server 106 via the Internet 90 according to the determination result in step S275.
  • step S277 the proxy server 212 acquires a startup page file distributed from the communication server 106 via the Internet 90 in response to the request in step S276.
  • step S278 the proxy server 212 notifies the browser 209 of the startup page URL described in the application manifest file of the startup package file.
  • step S291 the browser 209 requests a startup page file from the proxy server 212 according to the startup page URL notified in the process of step S278.
  • step S279 the proxy server 212 responds to the browser 209 with a startup page file that is prepared for a response in response to a request for the startup page file from the browser 209.
  • the browser 209 can acquire the startup page file from the proxy server 212.
  • step S292 the browser 209 requests the proxy server 212 for a resource file in the startup page file.
  • step S280 the proxy server 212 requests the communication server 106 for the resource file in the startup page file via the Internet 90 in response to the request for the resource file in the startup page file from the browser 209.
  • step S281 the proxy server 212 acquires a resource file in the startup page file distributed from the communication server 106 via the Internet 90 in response to the request in step S280.
  • step S282 the proxy server 212 returns the resource file in the startup page file acquired in step S281 to the browser 209.
  • step S293 the browser 209 presents a startup page based on the startup page file acquired from the proxy server 212 and the resource file in the startup page file. Thereby, an application is displayed with content, such as a broadcast program.
  • Steps S294 to S296 in FIG. 26 are similar to steps S258 to S260 in FIG. 22.
  • the browser 209 monitors the presentation timing of the additional resource file distributed via communication. A file is requested.
  • steps S283 to S285 in FIG. 26 an additional resource file is acquired from the communication server 106 via the Internet 90 by the proxy server 212 and returned in the same manner as steps S243 to S245 in FIG.
  • step S297 in FIG. 26 an additional resource file is presented by the renderer 213 in response to a response from the proxy server 212, as in step S261 in FIG. As a result, the information of the additional resource is added to the application (the startup page).
  • FIG. 27 is a diagram illustrating an example of the format of USD metadata in XML format.
  • “@” is added to the attribute.
  • the indented element and attribute are specified for the upper element.
  • the bundleDescription element is a root element and is an upper element of the userServiceDescription element (USD element).
  • This userServiceDescription element is an upper element of the serviceId attribute, atsc: serviceId attribute, atsc: fullMPDUri attribute, atsc: sTSIDUri attribute, name element, serviceLanguage element, atsc: capabilityCode element, and deliveryMethod element.
  • Service ID is specified in serviceId attribute and atsc: serviceId attribute.
  • atsc fullMPDUri attribute
  • a URI for referring to MPD metadata is specified.
  • atsc sTSIDUri attribute
  • a URI for referring to the S-TSID metadata is specified. Details of the format of the S-TSID metadata will be described with reference to FIG.
  • the name element specifies the name of the ATSC 3.0 service.
  • the name element is an upper element of the lang attribute.
  • the lang attribute the language of the service name of ATSC 3.0 is specified.
  • the serviceLanguage element a language that can be used for an ATSC 3.0 service is specified.
  • capabilityCode element a code related to the function is specified.
  • the deliveryMethod element is an upper element of the atsc: broadcastAppService element and the atsc: unicastAppService element.
  • the atsc: broadcastAppService element is an upper element of the basePattern element, and specifies information related to distribution via broadcasting.
  • the atsc: unicastAppService element is an upper element of the basePattern element, and specifies information related to delivery via communication.
  • FIG. 28 is a diagram illustrating an example of the format of S-TSID metadata in the XML format.
  • the S-TSID element is a root element and is an upper element of the RS element.
  • the RS element information on the ROUTE session is specified.
  • the RS element is an upper element of the bsid attribute, sIpAddr attribute, dIpAddr attribute, dport attribute, PLPID attribute, and LS element.
  • the broadcast stream ID is specified in the bsid attribute.
  • the IP address of the source is specified.
  • the IP address of the destination is specified.
  • a destination port number is specified.
  • the PLPID attribute the ID of the PLP of the ROUTE session is specified.
  • the LS element is an upper element of the tsi attribute, PLPID attribute, bw attribute, startTime attribute, endTime attribute, SrcFlow element, and RprFlow element.
  • ⁇ TSI is specified in the tsi attribute.
  • a PLP ID is specified in the PLPID attribute.
  • a bandwidth is specified in the bw attribute.
  • startTime attribute and endTime attribute a start date and time and an end date and time are specified.
  • Source flow information is specified in the SrcFlow element.
  • FIG. 29 shows the format of the SrcFlow element included in the S-TSID metadata of FIG.
  • the SrcFlow element in FIG. 29 is an upper element of the rt attribute, minBuffSize attribute, EFDT element, ContentInfo element, and Payload element.
  • the minimum buffer size required by the client device 20 is specified.
  • the EFDT element information related to an extended FDT (Extended FDT) is specified.
  • Information related to the content is specified in the ContentInfo element.
  • the Payload element is a higher-level element of the codePoint attribute, formatID attribute, frag attribute, order attribute, srcFecPayloadID attribute, and FECParams attribute, and specifies information related to the payload of the ROUTE packet that stores the source flow object.
  • the file mode (structure storing a single file) or the package mode (structure including multiple files) is distinguished by the value of the formatID attribute. That is, the value of the codePoint attribute that is the attribute of the Payload element is equal to the CodePoint of the LCT packet header that carries the file in a divided manner.
  • a set of attribute values of the Payload element (a set of values of Payload @ formatID, Payload @ frag, Payload @ order, Payload @ srcFecPayloadID) can be uniquely specified.
  • the description of the corresponding LCT channel (session) in the S-TSID is retrieved by the value of TSI (Transport Session Identifier) of the LCT packet (S-TSID / RS / LS @ tsi), and further, the LS Search for a Payload attribute that matches the value of SrcFlow / Payload @ codePoint with the value of CodePoint in the LCT packet header. Based on the value of the formatID attribute described as the attribute of the searched Payload attribute, it is distinguished whether the file carried by the LCT packet is in the file mode or the package mode.
  • TSI Transport Session Identifier
  • FIG. 30 shows the format of the EFDT element included in the SrcFlow element of FIG.
  • the EFDT element in FIG. 30 is an upper element of the tsi attribute, idRef attribute, version attribute, maxExpiresDelta attribute, maxTransportSize attribute, FileTemplate attribute, and FDTParameters attribute.
  • EFFT file
  • a group of files described by the EFDT are transferred to the LCT channel (session) of the ROUTE protocol indicated by the value of the tsi attribute of the EFDT element.
  • the EFDT element has the structure shown in FIG. 30, and the root element is called FDT-Instance and has the FDT-Instance type.
  • FDT-Instance there are a plurality of File elements, and transfer control attributes of each file are described.
  • the main transfer control attributes include, for example, a Content-Location that is a file name and a TOI that is an identifier for transfer.
  • FIG. 31 shows an example of the XML schema of EFDT.
  • an attribute of a resource file retransmission cycle (Retransmission-Cycle) (FIG. 13) and an attribute of a resource file retransmission end date (Retransmission-End) (FIG. 13) are defined in a frame A. .
  • ATSC particularly ATSC 3.0
  • ATSC 3.0 which is a method adopted in the United States and the like
  • ISDB Integrated (Services Digital Broadcasting)
  • DVB Digital Video Broadcasting
  • ATSC 3.0 in which the IP transmission method is adopted has been described as an example.
  • the present invention is not limited to the IP transmission method, and is applied to other methods such as an MPEG2-TS (TransportTSStream) method, for example. You may do it.
  • digital broadcasting standards include satellite broadcasting using broadcasting satellites (BS: BroadcastingliteSatellite) and communication satellites (CS: Communications Satellite), cable broadcasting such as cable TV (CATV), etc. Can be applied to
  • the above-mentioned names such as signaling are merely examples, and other names may be used.
  • the difference between these names is a formal difference and does not differ in substantial contents such as target signaling.
  • AST Application Signaling Table
  • AIT Application Information Table
  • signaling is described in a markup language such as XML
  • the names of those elements and attributes are merely examples, and other names may be adopted.
  • the difference between these names is a formal difference, and the substantial contents of those elements and attributes are not different.
  • the SLT metadata is described as the LLS signaling.
  • the LLS signaling may include metadata such as EAT (Emergency Alerting Table) and RRT (Region Risk Rating Table).
  • EAT metadata contains information about emergency information that needs to be urgently announced.
  • RRT metadata includes information about ratings.
  • the application is not limited to an application developed in a markup language such as HTML5 or a script language such as JavaScript (registered trademark), but may be an application developed in a programming language such as Java (registered trademark). Good.
  • the content described above can include any content such as an electronic book, a game, and music.
  • the present technology provides a predetermined standard (assuming that a transmission line other than a broadcast network, that is, a communication line (communication network) such as the Internet or a telephone network) is used as a transmission line.
  • a predetermined standard assuming that a transmission line other than a broadcast network, that is, a communication line (communication network) such as the Internet or a telephone network) is used as a transmission line.
  • the present invention can also be applied to standards other than digital broadcasting standards.
  • FIG. 32 is a diagram illustrating a configuration example of hardware of a computer that executes the above-described series of processing by a program.
  • a CPU Central Processing Unit
  • ROM Read Only Memory
  • RAM Random Access Memory
  • An input / output interface 1005 is further connected to the bus 1004.
  • An input unit 1006, an output unit 1007, a recording unit 1008, a communication unit 1009, and a drive 1010 are connected to the input / output interface 1005.
  • the input unit 1006 includes a keyboard, a mouse, a microphone, and the like.
  • the output unit 1007 includes a display, a speaker, and the like.
  • the recording unit 1008 includes a hard disk, a nonvolatile memory, and the like.
  • the communication unit 1009 includes a network interface or the like.
  • the drive 1010 drives a removable medium 1011 such as a magnetic disk, an optical disk, a magneto-optical disk, or a semiconductor memory.
  • the CPU 1001 loads the program recorded in the ROM 1002 or the recording unit 1008 to the RAM 1003 via the input / output interface 1005 and the bus 1004 and executes the program. A series of processing is performed.
  • the program executed by the computer 1000 can be provided by being recorded on the removable medium 1011 as a package medium, for example.
  • the program can be provided via a wired or wireless transmission medium such as a local area network, the Internet, or digital satellite broadcasting.
  • the program can be installed in the recording unit 1008 via the input / output interface 1005 by attaching the removable medium 1011 to the drive 1010.
  • the program can be received by the communication unit 1009 via a wired or wireless transmission medium and installed in the recording unit 1008.
  • the program can be installed in the ROM 1002 or the recording unit 1008 in advance.
  • the processing performed by the computer according to the program does not necessarily have to be performed in chronological order in the order described as the flowchart. That is, the processing performed by the computer according to the program includes processing executed in parallel or individually (for example, parallel processing or object processing).
  • the program may be processed by a single computer (processor) or may be distributedly processed by a plurality of computers.
  • the present technology can take the following configurations.
  • a receiving unit for receiving content An acquisition unit for acquiring resource distribution information related to distribution of one or more resource files that are transmitted together with the content and are part of an application accompanying the content; And a processing unit that performs processing according to the distribution of the resource file based on the acquired resource distribution information.
  • the resource distribution information includes distribution schedule information related to a distribution schedule for each resource file.
  • the distribution schedule information includes information indicating an acquisition destination for each resource file, and information regarding at least one of a size and a distribution time for each resource file.
  • the resource distribution information includes transfer control information related to distribution of a specific resource file whose distribution schedule may be changed according to a time zone.
  • the receiving apparatus wherein the transfer control information includes information related to at least one of a retransmission cycle and a retransmission end time of the specific resource file.
  • the video and audio data of the content is transmitted in a ROUTE (Real-time Object Delivery over Unidirectional Transport) session which is a protocol for streaming file transfer,
  • the delivery schedule information is included in an application manifest file bundled with a startup package file transmitted in a ROUTE session,
  • the transfer control information is included in an EFDT (Extended FDT) transmitted in the ROUTE session specified by S-TSID (Service-based Transport Session Instance Description) which is control information of the ROUTE protocol (4) or (5 ).
  • S-TSID Service-based Transport Session Instance Description
  • the receiving device is Obtaining resource delivery information relating to the delivery of one or more resource files that are transmitted with the content and are part of an application associated with the content; A data processing method including a step of performing processing according to distribution of the resource file based on the acquired resource distribution information.
  • the resource distribution information includes distribution schedule information related to a distribution schedule for each resource file.
  • the distribution schedule information includes information indicating an acquisition destination for each resource file, and information regarding at least one of a size and a distribution time for each resource file.
  • the resource distribution information includes transfer control information related to distribution of a specific resource file whose distribution schedule may be changed according to a time zone.
  • the transfer control information includes information related to at least one of a retransmission cycle and a retransmission end time of the specific resource file.
  • the video and audio data of the content is transmitted in a ROUTE session, which is a protocol for streaming file transfer,
  • the delivery schedule information is included in an application manifest file bundled with a startup package file transmitted in a ROUTE session,
  • a generation unit that generates resource distribution information related to distribution of one or more resource files that are part of an application associated with the content;
  • a transmission apparatus comprising: a transmission unit that transmits the resource distribution information together with the content.
  • the distribution schedule information includes information indicating an acquisition destination for each resource file, and information regarding at least one of a size and a distribution time for each resource file.
  • the resource distribution information includes transfer control information related to distribution of a specific resource file whose distribution schedule may be changed according to a time zone.
  • the transfer control information includes information regarding at least one of a retransmission cycle and a retransmission end time of the specific resource file.
  • the video and audio data of the content is transmitted in a ROUTE session, which is a protocol for streaming file transfer,
  • the delivery schedule information is included in an application manifest file bundled with a startup package file transmitted in a ROUTE session,
  • the transmitting device is Generating resource distribution information relating to the distribution of one or more resource files that are part of the application associated with the content; A data processing method including a step of transmitting the resource distribution information together with the content.

Landscapes

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

Abstract

本技術は、コンテンツに付随するアプリケーションのリソースファイルの配信に応じた処理を行うことができるようにする受信装置、送信装置、及び、データ処理方法に関する。 受信装置は、コンテンツを受信し、コンテンツとともに伝送される、コンテンツに付随するアプリケーションの一部である１又は複数のリソースファイルの配信に関するリソース配信情報を取得し、取得されたリソース配信情報に基づいて、リソースファイルの配信に応じた処理を行う。本技術は、例えば、デジタル放送を受信可能なテレビ受像機に適用することができる。

Description

受信装置、送信装置、及び、データ処理方法
　本技術は、受信装置、送信装置、及び、データ処理方法に関し、特に、コンテンツに付随するアプリケーションのリソースファイルの配信に応じた処理を行うことができるようにした受信装置、送信装置、及び、データ処理方法に関する。
　番組やCM等のコンテンツに付随するアプリケーション（以下、単にアプリケーションともいう）の配信ライフサイクルコントロールに、AIT(Application information Table)等のアプリケーション制御情報を用いることが知られている（例えば、特許文献１参照）。このアプリケーション制御情報によって、受信機では、アプリケーションの起動や終了の動作を制御することができる。
特開２０１５－１８００６５号公報
　ところで、アプリケーションの配信ライフサイクルコントロールを簡素化する一方で、受信機側で、コンテンツに付随するアプリケーションのリソースファイルの配信に応じた処理を行うことができるようにするための提案が要請されていた。
　本技術はこのような状況に鑑みてなされたものであり、コンテンツに付随するアプリケーションのリソースファイルの配信に応じた処理を行うことができるようにするものである。
　本技術の第１の側面の受信装置は、コンテンツを受信する受信部と、前記コンテンツとともに伝送される、前記コンテンツに付随するアプリケーションの一部である１又は複数のリソースファイルの配信に関するリソース配信情報を取得する取得部と、取得された前記リソース配信情報に基づいて、前記リソースファイルの配信に応じた処理を行う処理部とを備える受信装置である。
　本技術の第１の側面の受信装置は、独立した装置であってもよいし、１つの装置を構成している内部ブロックであってもよい。また、本技術の第１の側面のデータ処理方法は、上述した本技術の第１の側面の受信装置に対応するデータ処理方法である。
　本技術の第１の側面の受信装置、及び、データ処理方法においては、コンテンツが受信され、前記コンテンツとともに伝送される、前記コンテンツに付随するアプリケーションの一部である１又は複数のリソースファイルの配信に関するリソース配信情報が取得され、取得された前記リソース配信情報に基づいて、前記リソースファイルの配信に応じた処理が行われる。
　本技術の第２の側面の送信装置は、コンテンツに付随するアプリケーションの一部である１又は複数のリソースファイルの配信に関するリソース配信情報を生成する生成部と、前記コンテンツとともに、前記リソース配信情報を送信する送信部とを備える送信装置である。
　本技術の第２の側面の送信装置は、独立した装置であってもよいし、１つの装置を構成している内部ブロックであってもよい。また、本技術の第２の側面のデータ処理方法は、上述した本技術の第２の側面の送信装置に対応するデータ処理方法である。
　本技術の第２の側面の送信装置、及び、データ処理方法においては、コンテンツに付随するアプリケーションの一部である１又は複数のリソースファイルの配信に関するリソース配信情報が生成され、前記コンテンツとともに、前記リソース配信情報が送信される。
　本技術の第１の側面、及び、第２の側面によれば、コンテンツに付随するアプリケーションのリソースファイルの配信に応じた処理を行うことができる。
　なお、ここに記載された効果は必ずしも限定されるものではなく、本開示中に記載されたいずれかの効果であってもよい。
本技術を適用した伝送システムの一実施の形態の構成例を示す図である。 クライアント装置の構成例を示す図である。 本技術のIP伝送方式のプロトコルスタックの例を示す図である。 LLSシグナリングとSLSシグナリングとの関係を示す図である。 アプリURLに応じたアプリケーション制御を説明する図である。 SLSシグナリングチャネルとLCCチャネルとの関係を示す図である。 スタートアップパッケージファイルの構造の例を示す図である。 W3CのWeb App Manifestのフォーマットの例を示す図である。 拡張Web App Manifestを利用する場合のスタートアップパッケージファイルの記述例を示す図である。 拡張Web App Manifestのフォーマットの例を示す図である。 拡張Web App Manifestの記述例を示す図である。 図１１の拡張Web App Manifestの記述例を時系列で表した図である。 EFDTに記述される転送制御情報を説明する図である。 典型的なアプリケーションの構成例を示す図である。 放送モードが設定されたときに処理されるアプリケーションに関するデータの流れを説明する図である。 放送モードが設定された場合の送信側の処理の流れについて説明するフローチャートである。 放送モードが設定された場合の受信側の処理の流れについて説明するフローチャートである。 放送モードが設定された場合の受信側の処理の流れについて説明するフローチャートである。 ハイブリッドモードが設定されたときに処理されるアプリケーションに関するデータの流れを説明する図である。 ハイブリッドモードが設定された場合の送信側の処理の流れについて説明するフローチャートである。 ハイブリッドモードが設定された場合の受信側の処理の流れについて説明するフローチャートである。 ハイブリッドモードが設定された場合の受信側の処理の流れについて説明するフローチャートである。 通信モードが設定されたときに処理されるアプリケーションに関するデータの流れを説明する図である。 通信モードが設定された場合の送信側の処理の流れについて説明するフローチャートである。 通信モードが設定された場合の受信側の処理の流れについて説明するフローチャートである。 通信モードが設定された場合の受信側の処理の流れについて説明するフローチャートである。 USDメタデータのフォーマットの例を示す図である。 S-TSIDメタデータのフォーマットの例を示す図である。 SrcFlow要素のフォーマットの例を示す図である。 EFDT要素のフォーマットの例を示す図である。 EFDTのXMLスキーマの例を示す図である。 コンピュータの構成例を示す図である。
　以下、図面を参照しながら本技術の実施の形態について説明する。なお、説明は以下の順序で行うものとする。
１．システムの構成
２．本技術の概要
３．具体的な運用例
（Ａ）放送モード
（Ｂ）ハイブリッドモード
（Ｃ）通信モード
４．シグナリングの例
５．変形例
６．コンピュータの構成
＜１．システムの構成＞
（伝送システムの構成）
　図１は、本技術を適用した伝送システムの一実施の形態の構成例を示す図である。なお、システムとは、複数の装置が論理的に集合したものをいう。
　図１において、伝送システム１は、送信側システム１０と、受信側のクライアント装置２０から構成される。伝送システム１においては、送信側システム１０から送信されるデータが、放送網としての伝送路８０、又は通信網としてのインターネット９０を介してクライアント装置２０により受信される。
　例えば、伝送システム１では、現在策定が進められている米国の次世代放送規格であるATSC(Advanced Television Systems Committee)3.0等の所定の規格に準拠したデータ伝送が行われる。
　なお、ATSC3.0では、伝送方式として、現在広く普及しているMPEG2-TS(Transport Stream)方式ではなく、通信の分野で用いられているIP(Internet Protocol)パケットをデジタル放送に用いたIP伝送方式を導入することで、より高度なサービスを提供することが想定されている。
　送信側システム１０は、ATSC3.0等の所定の規格に準拠したデータを送信するための処理を行う。送信側システム１０は、DASHサーバ１０１、シグナリングサーバ１０２、アプリケーションサーバ１０３、SCH/PKGサーバ１０４、放送サーバ１０５、及び通信サーバ１０６から構成される。
　DASHサーバ１０１は、MPEG-DASH(Dynamic Adaptive Streaming over HTTP)に対応した配信サービスを行うためのサーバである。ここで、MPEG-DASHは、OTT-V(Over The Top Video)に従ったストリーミング配信規格であって、HTTP(Hypertext Transfer Protocol)をベースとしたストリーミングプロトコルを用いたアダプティブストリーミング配信に関する規格である。
　このMPEG-DASHの規格では、動画や音声のファイルの管理情報であるメタデータを記述するためのマニフェストファイルと、動画のコンテンツを伝送するためのファイルフォーマットが規定されている。なお、前者のマニフェストファイルは、MPD(Media Presentation Description)と称される。また、後者のファイルフォーマットは、セグメントフォーマットとも称される。
　DASHサーバ１０１は、外部からMPDメタデータを生成するためのデータや、コンテンツのデータなどを受信する。DASHサーバ１０１は、外部からのデータに基づいて、MPDメタデータを生成し、シグナリングサーバ１０２に送信する。また、DASHサーバ１０１は、外部からのデータに基づいて、番組やCM等のコンテンツのセグメント（DASHセグメント）のファイルを生成し、放送サーバ１０５又は通信サーバ１０６に送信する。
　シグナリングサーバ１０２は、外部からシグナリングを生成するためのデータを受信する。また、シグナリングサーバ１０２は、DASHサーバ１０１からのMPDメタデータを受信する。シグナリングサーバ１０２は、外部からのデータや、MPDメタデータなどに基づいて、シグナリングを生成し、放送サーバ１０５又は通信サーバ１０６に送信する。
　ここで、例えば、ATSC3.0では、シグナリングとして、LLS(Link Layer Signaling)シグナリングとSLS(Service Layer Signaling)シグナリングを用いることが想定されている。LLSシグナリングは、SLSシグナリングに先行して取得されるシグナリングであって、LLSシグナリングに含まれる情報に従い、SLSシグナリングが取得される。SLSシグナリングは、サービス単位のシグナリングである。
　LLSシグナリングは、SLT(Service List Table)等のメタデータを含む。SLTメタデータは、サービスの選局に必要な情報（選局情報）など、放送ネットワークにおけるストリームやサービスの構成を示す基本情報を含んでいる。
　SLSシグナリングは、USD(User Service Description)，S-TSID(Service-based Transport Session Instance Description)，MPD(Media Presentation Description)等のメタデータを含む。USDメタデータは、他のメタデータの取得先などの情報を含む。ただし、USDは、USBD(User Service Bundle Description)と称されることがある。
　S-TSIDメタデータは、LSID(LCT Session Instance Description)をATSC3.0向けに拡張したものであって、ROUTE(Real-time Object Delivery over Unidirectional Transport)プロトコルの制御情報である。なお、ROUTEは、ストリーミングファイル転送用のプロトコルであって、FLUTE(File Delivery over Unidirectional Transport)を拡張したものである。また、S-TSIDメタデータは、ROUTEセッションで伝送されるEFDT(Extended FDT)を特定することができる。EFDTは、FLUTEで導入されていたFDT(File Delivery Table)を拡張したものであって、転送用の制御情報である。
　MPDメタデータは、上述したように、ストリーミング配信される動画や音声のファイルの管理情報である。なお、SLT，USD，S-TSID，MPD等のメタデータは、例えば、XML(Extensible Markup Language)等のマークアップ言語により記述することができる。
　シグナリングサーバ１０２は、SLTメタデータを含むLLSシグナリングと、USDメタデータ、S-TSIDメタデータ、及びMPDメタデータを含むSLSシグナリングを生成する。ただし、シグナリングサーバ１０２は、DASHサーバ１０１により生成されたMPDメタデータを、SLSシグナリングとして処理する。
　アプリケーションサーバ１０３は、外部からアプリケーションを構成するファイルを生成するためのデータを受信する。アプリケーションサーバ１０３は、外部からのデータに基づいて、アプリケーションを構成するスタートアップページファイル（例えば、HTML文書ファイル等）や、１又は複数のリソースファイル（例えば、画像ファイルやスクリプトファイル等）を生成し、SCH/PKGサーバ１０４に送信する。
　なお、アプリケーションは、番組やCM等のコンテンツに付随するアプリケーションである。また、このようなアプリケーションとしては、例えば、HTML5(HyperText Markup Language 5)等のマークアップ言語や、JavaScript（登録商標）等のスクリプト言語で開発されたアプリケーションを用いることができる。
　SCH/PKGサーバ１０４は、アプリケーションを構成するファイル（リソースファイル）の配信スケジュールを決定し、アプリケーションマニフェストファイルに含める。また、SCH/PKGサーバ１０４は、アプリケーションマニフェストファイル、スタートアップページファイル、及びリソースファイルを含むスタートアップパッケージファイルを生成し、放送サーバ１０５に送信する。
　なお、スタートアップパッケージファイルとアプリケーションマニフェストファイルの詳細は、後述する。また、スタートアップパッケージファイルには、スタートアップページファイルとリソースファイルを必ずしも含める必要はない。また、スタートアップページファイルとリソースファイルは、通信経由で配信される場合、通信サーバ１０６に送信される。
　また、SCH/PKGサーバ１０４は、アプリケーションを構成するファイル（リソースファイル）の配信スケジュールに応じた転送制御情報を含むEFDTを生成し、放送サーバ１０５に送信する。なお、転送制御情報は、時間帯に応じて配信スケジュールが変更される可能性のある特定のリソースファイルに関する情報であって、その詳細については後述する。
　さらに、SCH/PKGサーバ１０４は、スタートアップページファイルにより後から参照されるリソースファイルである追加リソースファイルを、放送サーバ１０５又は通信サーバ１０６に送信する。
　放送サーバ１０５は、ATSC3.0等のデジタル放送の規格に準拠したデータ伝送を行うことが可能な送信機である。
　放送サーバ１０５は、DASHサーバ１０１から送信されてくるDASHセグメント、シグナリングサーバ１０２から送信されてくるシグナリング、及び、SCH/PKGサーバ１０４から送信されるアプリケーションに関するファイル（例えば、スタートアップパッケージファイル等）を受信する。放送サーバ１０５は、DASHセグメント、シグナリング、及び、アプリケーションに関するファイルを処理し、伝送路８０を介して送信（一斉同報配信）する。
　通信サーバ１０６は、インターネット９０に接続されたクライアント装置２０からの要求に応じて、インターネット９０を介して各種のデータを提供するサーバである。
　通信サーバ１０６は、DASHサーバ１０１から送信されてくるDASHセグメント、シグナリングサーバ１０２から送信されてくるシグナリング、及び、SCH/PKGサーバ１０４から送信されるアプリケーションに関するファイル（例えば、追加リソースファイル等）を受信する。通信サーバ１０６は、DASHセグメント、シグナリング、及び、アプリケーションに関するファイルを処理する。そして、通信サーバ１０６は、クライアント装置２０からの要求に応じて、インターネット９０を介して、各種のファイルを送信する。
　クライアント装置２０は、ATSC3.0等の所定の規格に準拠した伝送データを受信可能な受信機である。例えば、クライアント装置２０は、テレビ受像機やセットトップボックスなどの固定受信機、あるいは、スマートフォンや携帯電話機、タブレット型コンピュータなどのモバイル受信機である。また、クライアント装置２０は、例えば車載テレビなどの自動車に搭載される機器であってもよい。なお、クライアント装置２０の詳細な構成は、図２を参照して後述する。
　クライアント装置２０は、放送サーバ１０５から伝送路８０を介して送信（一斉同報配信）されてくる、DASHセグメント、シグナリングなどのファイルを受信して処理することで、放送番組などのコンテンツの映像や音声を出力する。
　また、クライアント装置２０は、通信機能を有する場合、インターネット９０を介して、通信サーバ１０６にアクセスし、各種のファイルを取得することができる。例えば、クライアント装置２０は、通信サーバ１０６からインターネット９０を介して送信（適応的にストリーミング配信）される、DASHセグメントやMPDメタデータ等のファイルを受信して処理することで、VOD(Video On Demand)番組などのコンテンツの映像や音声を出力する。
　また、クライアント装置２０は、放送サーバ１０５又は通信サーバ１０６から送信される、アプリケーションに関するファイルを受信して処理することで、アプリケーションを実行する。すなわち、クライアント装置２０では、放送経由又は通信経由で取得されたコンテンツに付随して、放送経由又は通信経由で取得されたアプリケーションが実行される。ただし、アプリケーションは、何らかの情報を明示的に表示するだけでなく、非表示で（バックグラウンドで）動作する場合もある（ユーザに認識されずに起動することがある）。
　さらに、クライアント装置２０は、スタートアップパッケージファイルのアプリケーションマニフェストファイルに含まれる配信スケジュール情報や、EFDTに含まれる転送制御情報に基づいて、アプリケーションのリソースファイルの配信に応じた処理を行うことができる。なお、配信スケジュール情報や転送制御情報の詳細は、図７乃至図１３などを参照して後述する。
　なお、伝送システム１において、伝送路８０は、地上波（地上波放送）のほか、例えば、放送衛星（BS：Broadcasting Satellite）や通信衛星（CS：Communications Satellite）を利用した衛星放送、あるいは、ケーブルを用いた有線放送（CATV）などであってもよい。
　ここで、図１の伝送システム１においては、説明を簡単にするために、クライアント装置２０を１つだけ図示しているが、クライアント装置２０は複数設けることができ、送信側システム１０が送信（一斉同報配信）するデジタル放送信号は、伝送路８０を介して複数のクライアント装置２０で同時に受信することができる。
　また、送信側システム１０も複数設けることができる。複数の送信側システム１０のそれぞれでは、別個のチャンネルとしての、例えば、別個の周波数帯域で、放送ストリームを含むデジタル放送信号を送信し、クライアント装置２０では、複数の送信側システム１０のそれぞれのチャンネルの中から、放送ストリームを受信するチャンネルを選択することができる。
（クライアント装置の構成）
　図２は、図１のクライアント装置２０の構成例を示す図である。
　図２において、クライアント装置２０は、処理部２０１、入力部２０２、メモリ２０３、受信部２０４、放送ミドルウェア２０５、DASHクライアント２０６、デコーダ２０７、出力部２０８、ブラウザ２０９、及び通信部２１０から構成される。
　処理部２０１は、クライアント装置２０の各部の動作を制御する処理など行う。
　入力部２０２は、ユーザの操作に応じた操作信号を処理部２０１に供給する。処理部２０１は、入力部２０２から供給される操作信号に基づいて、クライアント装置２０の各部の動作を制御する。メモリ２０３は、処理部２０１からの制御に従い、各種のデータを記憶する。
　受信部２０４は、チューナなどから構成される。受信部２０４は、アンテナ２２１によって、放送サーバ１０５から伝送路８０を介して送信（一斉同報配信）されてくる放送波（デジタル放送信号）を受信して処理し、それにより得られるデータを、放送ミドルウェア２０５に供給する。
　放送ミドルウェア２０５は、受信部２０４から供給されるデータを処理し、処理部２０１、DASHクライアント２０６、又はブラウザ２０９に供給する。ここで、処理対象のデータのうち、MPDメタデータ及びDASHセグメントは、DASHクライアント２０６に供給され、アプリケーションに関するデータは、ブラウザ２０９に供給され、シグナリング等のデータは、処理部２０１に供給される。
　DASHクライアント２０６には、放送ミドルウェア２０５からMPDメタデータ及びDASHセグメントが供給される。DASHクライアント２０６は、MPDメタデータに基づいて、DASHセグメントを処理する。このDASHセグメントを処理して得られるビデオとオーディオのデータは、デコーダ２０７に供給される。
　デコーダ２０７は、所定の復号方式（例えばHEVC(High Efficiency Video Coding)やAAC(Advanced Audio Coding)等）に従い、DASHクライアント２０６から供給されるビデオとオーディオのデータのデコードを行う。このデコードにより得られるビデオとオーディオのデータは、出力部２０８に供給される。
　出力部２０８は、デコーダ２０７から供給されるビデオとオーディオのデータを出力する。これにより、クライアント装置２０では、番組やCM等のコンテンツが再生され、その映像や音声が出力されることになる。
　ブラウザ２０９は、例えばHTML5に対応したブラウザである。ブラウザ２０９は、放送ミドルウェア２０５から供給される、アプリケーションのデータを処理し、出力部２０８に供給する。出力部２０８は、ブラウザ２０９から供給されるアプリケーションのデータを出力する。これにより、クライアント装置２０では、番組等に連動して、アプリケーションの映像が表示されることになる。
　通信部２１０は、処理部２０１からの制御に従い、インターネット９０を介して、通信サーバ１０６とデータのやりとりを行う。通信部２１０により受信されるデータのうち、MPDメタデータ及びDASHセグメントは、DASHクライアント２０６に供給され、アプリケーションに関するデータは、ブラウザ２０９に供給され、シグナリング等のデータは、処理部２０１に供給される。これらの通信経由で取得されたデータに対する処理は、上述した放送経由で取得されたデータと同様であるため、ここでは、その説明は省略する。
　また、処理部２０１は、制御部２１１、プロキシサーバ２１２、及びレンダラ２１３を含んで構成される。制御部２１１は、クライアント装置２０の各部の動作を制御する。プロキシサーバ２１２は、処理対象のデータの送受信に関する処理などを行う。レンダラ２１３は、処理対象のデータを出力するための処理を行う。
　クライアント装置２０は、以上のように構成される。
＜２．本技術の概要＞
（本技術のプロトコルスタック）
　図３は、本技術のIP伝送方式のプロトコルスタックの例を示す図である。
　図３において、最も下位の階層は、物理層（Physical Layer）とされる。ATSC3.0等のIP伝送方式のデジタル放送では、一方向の放送を利用した伝送に限らず、一部のデータを、双方向の通信を利用して伝送する場合があるが、放送（Broadcast）を利用する場合、その物理層（Physical Layer）は、サービス（チャネル）のために割り当てられた放送波の周波数帯域が対応することになる。
　物理層（Physical Layer）の上位の階層は、データリンク層（Data Link Layer）とされる。また、データリンク層の上位の階層は、IP層とされる。IP層は、通信の階層モデルにおけるネットワーク層に相当するものであり、IPアドレスによりIPパケットが特定される。IP層に隣接する上位階層は、通信の階層モデルにおけるトランスポート層に相当するUDP(User Datagram Protocol)層とされ、さらにその上位の階層は、ROUTEとされる。
　また、UDP層の上位の階層、すなわち、UDPパケットを含むIPパケット（IP/UDPパケット）には、SLTメタデータが格納され、伝送される。SLSメタデータは、LLSシグナリングであって、放送ネットワークにおけるストリームやサービスの構成を示す基本情報を含んでいる。
　ROUTEは、ストリーミングファイル転送用のプロトコルであって、FLUTEを拡張したものである。ROUTEに隣接する上位階層のうち、一部の階層は、シグナリング（Signaling）と、LCC(Locally Cached Content)コンテンツ（LCC（NRT））とされる。
　このシグナリングは、SLSシグナリングであって、例えば、USD，S-TSID，MPD等のメタデータが含まれる。すなわち、図４に示すように、クライアント装置２０では、最初に、LLSシグナリングとしてのSLTメタデータを取得してから、サービス単位のSLSシグナリング（S-TSID等）を取得することになる。
　図３の説明に戻り、LCCコンテンツは、クライアント装置２０のストレージに一旦蓄積された後で再生が行われるコンテンツである。なお、LCC(Locally Cached Content)は、NRT(Non Real Time)と称される場合がある。上述したアプリケーションは、LCCコンテンツとしてROUTEセッションにより伝送することができる。さらに、LCCコンテンツとして、例えば、電子サービスガイド（ESG：Electronic Service Guide）などのコンテンツが、ROUTEセッションにより伝送されるようにしてもよい。
　ROUTEに隣接する上位階層のうち、上述した階層以外の他の階層は、DASHセグメント（DASH）とされる。すなわち、放送番組等のコンテンツを構成するサービスコンポーネント（ビデオやオーディオ、字幕等）のストリームデータは、ISO BMFF(ISO Base Media File Format)の規格に準じたDASHセグメント単位で、ROUTEセッションにより伝送されることになる。
　また、双方向の通信（Broadband）を利用する場合、その物理層（Physical Layer）の上位の階層は、データリンク層（Data Link Layer）とされる。また、データリンク層の上位の階層は、ネットワーク層に相当するIP層とされる。また、IP層に隣接する上位階層は、トランスポート層に相当するTCP(Transmission Control Protocol)層とされ、さらに、TCP層に隣接する上位階層は、アプリケーション層に相当するHTTP層とされる。すなわち、これらの階層によって、インターネット９０等のネットワークで稼働するTCP/IPなどのプロトコルが実装される。
　HTTP層に隣接する上位階層のうち、一部の階層は、シグナリング（Signaling）と、LCCコンテンツ（LCC（NRT））とされる。このシグナリングとしては、上述したROUTEで伝送されるシグナリングなど、すべてのシグナリングが含まれる。また、LCCコンテンツは、通信経由で取得されるコンテンツであって、例えば、アプリケーションが含まれる。
　HTTP層に隣接する上位階層のうち、上述した階層以外の他の階層は、DASHセグメント（DASH）とされる。すなわち、双方向の通信系のストリーミング配信では、VOD番組等のコンテンツを構成するサービスコンポーネント（ビデオやオーディオ、字幕等）のストリームデータが、ISO BMFFの規格に準じたDASHセグメント単位で伝送されることになる。
　以上のように、本技術のIP伝送方式のプロトコルスタックにおいては、一方向の放送系の階層と、双方向の通信系の階層の一部が共通のプロトコルとなって、一方向の放送と双方向の通信で、コンテンツを構成するサービスコンポーネントのストリームデータを、ISO BMFFの規格に準じたDASHセグメント単位で伝送することができる。そのため、一方向の放送系のストリーミング配信と、双方向の通信系のストリーミング配信の双方を行う場合において、上位の階層のプロトコルが共通化されているため、例えば、放送サーバ１０５やクライアント装置２０では、実装の負担や処理の負担を軽減することができる。
（アプリケーションの制御）
　ところで、番組やCM等のコンテンツに付随するアプリケーションを用いたサービスを提供するに際し、アプリケーションの制御モデルをシンプルに実装する提案が要請されている。例えば、ATSC3.0では、アプリケーションの配信ライフサイクルコントロールに、AST(Application Signaling Table)を用いることが検討されているが、ASTを利用する以外に、よりアプリケーションの制御モデルをシンプルに実装することが求められている。
　例えば、図５に示すように、コンテンツに付随して起動するアプリケーションのURL（以下、アプリURL（App URL）という）を、特定のファイル（後述するアプリケーションマニフェストファイル）やシグナリングなどに記述しておくことで、アプリケーションの制御モデルをシンプルに実装することができる。このような実装を行った場合、クライアント装置２０においては、サービスが選局されたときに、直ちにそのファイルやシグナリングに記述されたアプリURLに従い、アプリケーションが取得され、起動されることになる。
　このようなアプリURLに応じてアプリケーションを起動する手法を採用した場合、当該アプリURLにより、アプリケーションの最初のページのファイル（スタートアップページファイル（例えばHTML文書ファイル））のURL（スタートアップページURL）を、クライアント装置２０に通知することはできる。一方で、そのURLで示されるページのファイル（スタートアップページファイル）において参照される、画像ファイル（例えばjpegファイル）やスクリプトファイル（例えばJavaScript（登録商標）のコードが記述されたファイル）等の各種リソースファイルは、最初のページのファイル（スタートアップページファイル）を取得した後で、アプリケーションのニーズに応じて必要なタイミングで放送経由又は通信経由（インターネット経由）で取得される。
　この場合、クライアント装置２０のブラウザ２０９（図２）では、最初に取得されたページのファイル（スタートアップページファイル）をパース（構文解析）して、必要なリソースファイルの取得先を示すURLが解決されると、その各々のURLにより特定されるリソースファイルを取得するためのリクエストを発行することになる。一般に、HTML文書（ページ）では、複数のリソースファイルを参照しているため、すべてのリソースファイルが、クライアント装置２０のメモリ２０３（図２）内に揃った時点で、アプリケーション（のページ）を表示する必要がある。
　ここで、ATSC3.0では、クライアント装置２０のブラウザ２０９（図２）がアクセスする先（HTTPリクエストを送る先）は、ローカルのプロキシサーバ２１２（図２）とされている。そして、ATSC3.0で規定されるシグナリングやトランスポートプロトコルを終端する放送ミドルウェア２０５（図２）が、放送経由で配信されたシグナリングやコンテンツをローカルファイルシステムに展開し、ローカルのプロキシサーバ２１２（図２）上に実装されたサーバサイドスクリプト（モジュール）等によるプログラム処理により、放送ミドルウェア２０５（図２）と直接又は一体となって、DASHクライアント２０６（図２）やブラウザ２０９（図２）上で実行されるアプリケーション等（クライアント）からの取得リクエストに応じるモデルが想定されている。
　上述したように、ブラウザ２０９（図２）が、最初のHTML文書ファイル（スタートアップページファイル）をパースして、そのHTML文書ファイルにより参照されているリソースファイルの取得リクエストを発行したとしても、そのリソースファイルが、ローカルファイルシステム上に展開されている状態となっているか、あるいは、ローカルのプロキシサーバ２１２（図２）のサーバサイドスクリプト（モジュール）がアクセス可能な状態となっていなければならならい。
　すなわち、このような状態になっていないと、HTML文書ファイル（スタートアップページファイル）のすべてのリソースファイルを表示可能な状態とすることができないまま、リソースファイルの取得リクエストがタイムアウトとなり、ユーザによっては、不完全な状態でアプリケーション（のページ）がロードされたと誤認識されてしまうことになる。そのため、すべてのリソースファイルが最初にまとめて準備されていることが必須となる。
　また、例えば、放送番組に付随するアプリケーションでは、最初のHTML文書ファイル（スタートアップページファイル）をロードした後に、各シーンごとに提示するリソースファイルが逐次変化（追加）していくのが一般的であり、このような番組全体に渡って必要なリソースファイルを俯瞰できないと、プロトコル処理やメモリ管理の最適化を行うことができない。すなわち、どれだけのリソースファイルがどういったタイミングで今後必要となってくるかについて、番組全体に渡って俯瞰して、クライアント装置２０のコンピューティングリソースを、各サービス（番組）に対してどのように分配するかなどについての最適化を図る必要がある。
　本技術では、これらの問題を解決するために、次のような提案を行うものとする。すなわち、ROUTEプロトコルの制御情報であるEFDTに、スタートアップパッケージファイルについてのURL（スタートアップパッケージURL）を含む転送制御属性を記述し、そのスタートアップパッケージファイルに含まれるアプリケーションマニフェストファイルに、対象のアプリケーションのエントリのスタートアップページファイル（例えばHTML文書ファイル）を指定したURL（スタートアップページURL）が記述されるようにする。
　すなわち、このスタートアップページURLが、上述したアプリURL（図５）に相当するものとなる。つまり、本技術のアプリケーション制御では、AITやAST等のアプリケーション制御情報を用いた場合のアプリケーション制御とは異なり、配信ライフサイクルコントロールは行わずに、スタートアップページURL（図５のアプリURL）に従い、即時にアプリケーションが起動（取得）されるという流れになるので、アプリケーションの制御モデルをよりシンプルに実装することができる。
　なお、スタートアップパッケージファイルは、ROUTEのパッケージモードで構成されたファイルであって、スタートアップページファイル（例えばHTML文書ファイル）と、リソースファイル（例えば画像ファイルやスクリプトファイル等）を含むことができる。
　また、スタートアップパッケージファイルのアプリケーションマニフェストファイルには、対象のアプリケーションに含まれるリソースファイルのすべてについての配信スケジューリングの最適化に利用可能な属性を記述できるようにする。このようなリソースファイルの全体を俯瞰するためのリソースリストがあれば、リソースファイルの取得タイミングの信頼性などを向上させることができる。さらに、各々のリソースファイルの転送属性が、各ファイルのURLを含む転送制御属性を記述するEFDTに記述できるようにする。
　なお、上述したように、SLSシグナリングやLCCコンテンツは、ROUTEセッションで伝送されるが、図６に示すように、ROUTEプロトコルのサービスレイヤの制御に用いられるS-TSIDにより記述されるLCTチャネル（セッション）の１つが、ノンリアルタイムコンテンツであるLCCコンテンツの転送に割り当てられている。また、LCCコンテンツ用のLCTチャネルにおいては、ファイルモードで伝送されるEFDTにより、そのチャネルで転送するファイル群の転送制御パラメタが記述されるようにする。ここで、ファイルモード（File Mode）は、単一のファイルを転送するモードである。一方で、パッケージモード（Package Mode）は、複数のファイルをまとめて（同梱して）パッケージとして転送するモードとなる。
（スタートアップパッケージファイルの構造）
　図７は、スタートアップパッケージファイルの構造の例を示す図である。
　スタートアップパッケージファイルは、パッケージモードで配信され、アプリケーションマニフェストファイルとともに、スタートアップページファイル（例えばHTML文書ファイル）やリソースファイル（例えば画像ファイルやスクリプトファイル等）を同梱することができる。
　ここで、アプリケーションマニフェストファイルは、フォーマットとして、例えば、W3C(World Wide Web Consortium)により標準化が進められているWeb App Manifest（"https://www.w3.org/TR/appmanifest/"）を利用することができる。
　また、図７に示すように、アプリケーションマニフェストファイルが、どのフォーマットを利用するかは、パッケージモードで利用しているMultipart MIMEフォーマットのルートパートに格納される、MetadataEnvelopeのitem要素のcontent-Type属性に指定されるMIMEタイプ等により識別されるようにすることができる。なお、図７に示した２つのitem要素のうち、上側のitem要素は、アプリケーションマニフェストファイルのフォーマットに対応し、下側のitem要素は、スタートアップページファイルのフォーマットに対応している。
　例えば、現状のアプリケーションマニフェストファイルでは、MetadataEnvelopeのitem要素のcontent-Type属性として、"application/w3c-manifest+json"が指定された場合には、W3CのWeb App Manifestのフォーマットを利用することになる。図８には、W3CのWeb App Manifestのフォーマットの例が示されている。図８のWeb App Manifestのフォーマットでは、"start_url"に対して、スタートアップページURLの値が指定可能である。
　本技術では、リソース配信情報として、アプリケーションの一部である１又は複数のリソースファイルの配信スケジュールに関する配信スケジュール情報が配信されるようにするが、現状のアプリケーションマニフェストファイルのフォーマットでは、当該配信スケジュール情報を指定することができない。
　そこで、本技術では、アプリケーションマニフェストファイルのフォーマットの１つである、Web App Manifestを拡張することで、スタートアップページURLだけでなく、リソースファイルごとに、配信スケジュール情報が指定できるようにする。
　ただし、この拡張されたWeb App Manifest（以下、拡張Web App Manifestとも記述する）を、W3CのWeb App Manifest（図８）と区別するために、アプリケーションマニフェストファイルのフォーマットとして、拡張Web App Manifestを利用する場合には、スタートアップパッケージファイル（図７）のMetadataEnvelopeのitem要素のcontent-Type属性として、"application/atsc-manifest+json"が指定されるようにする（図９）。なお、"json"は、テキストフォーマットの一種であるJSON(JavaScript（登録商標） Object Notation)形式で表されることを意味している。
（拡張Web App Manifestの構造）
　図１０は、拡張Web App Manifestのフォーマットの例を示す図である。なお、このフォーマットの例は、JSON形式で記述されている。このJSON形式のオブジェクトは、キーと値のペアをコロン（：）で対にして、これらの対をコンマ（，）で区切ってゼロ個以上列挙し、全体を波括弧（{}）でくくることで表現される。
　図１０の拡張Web App Manifestでは、スタートアップページURLのほかに、リソースファイルごとの配信スケジュール情報が、配信スケジュール属性として指定可能である。この配信スケジュール属性としては、例えば、リソースファイルの取得先を示す情報、リソースファイルのサイズ、及びリソースファイルの配信時刻を指定することができる。
　例えば、図１０の拡張Web App Manifestにおいて、"url"であるキーに対し、リソースファイルのファイルURLを示す値がペアになって指定されることを表している。ただし、リソースファイルのファイルURLは、必須の値である。また、"sizes"であるキーに対し、リソースファイルのサイズ（バイト単位）を示す値がペアになって指定される。ただし、リソースファイルのサイズは、任意の値である。
　"absoluteDeliveryTimeStart"であるキーに対し、絶対時刻での配信開始時刻を示す値がペアになって指定される。また、"absoluteDeliveryTimeEnd"であるキーに対し、絶対時刻での配信終了時刻を示す値がペアになって指定される。ただし、絶対時刻での配信開始時刻と配信終了時刻の形式は、"YYYY-MM-DDTHH:mm:ssZ"とすることができる。また、絶対時刻での配信開始時刻と配信終了時刻は、任意の値である。
　"relativeDeliveryTimeStart"であるキーに対し、ノーマルプレイタイム（Normal Play Time）的な番組の先頭からの相対時刻での配信開始時刻を示す値がペアになって指定される。また、"relativeDeliveryTimeEnd"であるキーに対し、ノーマルプレイタイム（Normal Play Time）的な番組の先頭からの相対時刻での配信終了時刻を示す値がペアになって指定される。ただし、相対時刻での配信開始時刻と配信終了時刻の形式は、"THH:mm:ss.ffffff"とすることができる。また、相対時刻での配信開始時刻と配信終了時刻は、任意の値である。
　なお、図１０の拡張Web App Manifestの例では、１つのリソースファイルに対する配信スケジュール属性が指定される場合が例示されているが、複数のリソースファイルが存在する場合には、リソースファイルごとに、配信スケジュール属性が記述される。一方で、リソースファイルが存在しない場合には、この配信スケジュール属性を記述する必要はない。
（拡張Web App Manifestの記述例）
　図１１は、拡張Web App Manifestの記述例を示す図である。
　図１１の拡張Web App Manifestにおいては、"StartUpPage-url"であるスタートアップページURLとともに、２つのリソースファイルごとの配信スケジュール属性が記述されている。
　１つ目のリソースファイルの配信スケジュール属性には、当該リソースファイルのファイルURLとして、"ResourceFile-10-url"であるURLが指定され、当該リソースファイルのサイズとして、123バイトが指定されている。また、１つ目のリソースファイルの配信スケジュール属性には、当該リソースファイルの相対時刻での配信開始時刻と配信終了時刻として、"T00:10:22.123456"と"T00:12:33.654321"が指定されている。
　２つ目のリソースファイルの配信スケジュール属性には、当該リソースファイルのファイルURLとして、"ResourceFile-11-url"であるURLが指定され、当該リソースファイルのサイズとして、4567バイトが指定されている。また、２つ目のリソースファイルの配信スケジュール属性には、当該リソースファイルの相対時刻での配信開始時刻と配信終了時刻として、"T00:13:44.345678"と"T00:16:55.654321"が指定されている。
　図１１の拡張Web App Manifestの記述例を時系列で表すと、図１２に示すようになる。すなわち、図１２においては、時間の方向は、図中の左側から右側に向かう方向とされるが、番組の先頭を起点（T00:00:00.000000）として、"T00:10:22.123456"から"T00:12:33.654321"までの間に、"ResourceFile-10-url"であるファイルURLのリソースファイルが提示される。また、番組の先頭を起点（T00:00:00.000000）として、"T00:13:44.345678"から"T00:16:55.654321"までの間に、"ResourceFile-11-url"であるファイルURLのリソースファイルが提示される。
　なお、図１２の例は、リソースファイルが放送経由で配信される場合を表しており、リソースファイルが通信経由で配信される場合には、指定された期間に、インターネット９０上の通信サーバ１０６から対象のリソースファイルが取得可能であることを示すことになる。
（EFDTの転送制御情報）
　図１３は、EFDTに記述される転送制御情報を説明する図である。
　リソース配信情報としては、上述した拡張Web App Manifestのフォーマットに記述される配信スケジュール情報（配信スケジュール属性）のほかに、EFDTに記述される転送制御情報（転送制御属性）がある。
　この転送制御情報は、時間帯に応じて配信スケジュールが変更される可能性のある特定のリソースファイルの詳細な転送制御を行うための情報である。EFDTでは、リソースファイルごとの詳細な転送制御を行うための転送制御情報が、転送制御属性として指定可能である。この転送制御属性としては、例えば、各リソースファイルの再送周期及び再送終了日時の少なくとも一方を指定することができる。
　ここで、リソースファイルの再送周期（Retransmission-Cycle）の属性としては、例えば、"everyDay"，"everyHour"，"everyMinute"，"everySecond"などを指定することができる。
　"everyDay"は、対象のリソースファイルが１日１回は再送される可能性があることを意味する。すなわち、再送周期の属性として、"everyDay"が指定された場合、クライアント装置２０は、１日待っていれば、必ず再取得の可能性があることになる。
　"everyHour"は、１時間に１回は再送される可能性があることを意味する。"everyMinute"は、１分に１回は再送される可能性があることを意味する。"everySecond"は、１秒に１回は再送される可能性があることを意味する。
　また、リソースファイルの再送終了日時（Retransmission-End）の属性としては、例えば、その再送が終了する日時を表す、"YYYY-MM-DDTHH:mm:ss"の形式で指定されるようにすることができる。
　例えば、図１３のEFDTにおいては、リソースファイルの再送周期（Retransmission-Cycle）の属性として、"everyMinute"が記述され、リソースファイルの再送終了日時（Retransmission-End）の属性として、"2012-03-14T00:00:00"が記述されている。
　図１３のEFDTの記述例を時系列で表すと、図１３の右側に示すような関係となる。すなわち、図１３の右側の時系列においては、時間の方向は、図中の左側から右側に向かう方向とされるが、"ResourceFile-url"で識別されるリソースファイルは、毎秒ごとに再送され（00:00:00，00:01:00，00:02:00，・・・）、その再送が終わる日時（時刻）は、2012年3月14日の午前0時となる。
　クライアント装置２０では、リソースファイルの再送周期や再送終了日時の属性をヒントにして、取りこぼしたリソースファイル（例えば画像ファイル等）が、いつ再送されてくるのかを予測することができるため、リソースファイルを取得するためのスケジューリングの最適化を行うことができる。
　なお、リソースファイルの再送周期（Retransmission-Cycle）や再送終了日時（Retransmission-End）の属性は、少なくとも一方が記述されていればよく、例えば、再送周期の属性の記述をせずに、再送終了日時の属性のみが記述された場合には、当該再送終了日時の属性により指定される日時（時刻）までに、対象のリソースファイルが１度だけ再送されることを意味する。
　このように、拡張Web App Manifestのフォーマットを利用したアプリケーションマニフェストファイルによって、配信スケジュール情報が指定されることで、クライアント装置２０では、番組全体に渡っての個々のリソースファイルのサイズや配信タイミングを認識することができる。また、EFDTによって、転送制御情報として、個々のリソースファイルの配信予定区間内の細やかな再送周期や再送終了日時が指定されることで、クライアント装置２０では、受信処理を行うリソースについて、よりきめ細やかに、最適な配分を行うことが可能となる。
＜３．具体的な運用例＞
　図１４は、典型的なアプリケーションの構成例を示す図である。
　図１４においては、時間の方向が、図中の左側から右側に向かう方向とされる。放送番組（Program）は、シーン１乃至シーン３を含み、シーン１（Scene1）、シーン２（Scene2）、シーン３（Scene3）の順に遷移される。
　最初のシーン１には、アプリケーションの最初のエントリとなるスタートアップページファイル（StartUpPage）が提示される。このスタートアップページファイルは、例えば、HTML文書ファイルからなり、画像ファイル（例えばjpegファイル）やスクリプトファイル（例えばJavaScript（登録商標）のコードが記述されたファイル）等の各種リソースファイル（Resource1，Resource2，Resource3）を参照することで、アプリケーションの１番目のビュー（The 1st View）として、同時に提示される。
　シーン１からシーン２に遷移すると、アプリケーションの２番目のビュー（The 2nd View）の内容が提示される。このとき、２番目のビューにおいて、HTML文書ファイル自体は、最初のスタートアップページファイルと同じであるが、同時に提示される内容として、新たなリソースファイル（Resource4）が追加されている点が異なっている。
　また、シーン２において、アプリケーションは、２番目のビューから、３番目のビュー（The 3rd View）に切り替わり、３番目のビューの内容が提示される。このとき、３番目のビューにおいて、HTML文書ファイル自体は、最初のスタートアップページファイルと同じであるが、同時に提示される内容として、提示されていたリソースファイル（Resource4）が消去され、新たなリソースファイル（Resource5）が追加されている点が異なっている。
　なお、繰り返しになるので、その説明は省略するが、各シーンにおいて、スタートアップページファイルにより参照されるリソースファイルが追加又は消去されることで、アプリケーションのビューが切り替わることになる。
　シーン２に続く、シーン３においては、アプリケーションは、N-1番目のビューから、N番目のビュー（The Nth View）に切り替わり、N番目のビューの内容が提示される。このとき、N番目のビューにおいて、HTML文書ファイル自体は、最初のスタートアップページファイルと同じであるが、同時に提示される内容として、提示されていたリソースファイル（Resource4乃至Resource N-1）が消去され、新たなリソースファイル（Resource N）が提示されている。
　このように、放送番組に付随するアプリケーションでは、スタートアップページファイルを制御の中心にして、参照されるリソースファイルを追加又は消去することで、各シーンに応じた表示内容（ビューの内容）が提示されることになる。なお、異なるHTML文書ファイルが複数取得されるようにし、例えばインラインフレーム（HTMLで規定されるiframe要素）などを利用して、異なる文書（ドキュメント）をそのまま、一連のビューとして提示する方法もあるが、本技術の実施の形態では、スタートアップページファイルを制御の中心とした場合を説明する。
　また、本技術の実施の形態では、アプリケーションの配信モード（デリバリモード）として、次の３種類のモードをサポートする場合を説明する。すなわち、配信モードとしては、放送モード、ハイブリッドモード、及び通信モードを設定することができる。
　放送モード（Broadcast Only Mode）は、アプリケーションを構成するスタートアップページファイル（HTML文書ファイル）と、そのスタートアップページファイルにより参照されるリソースファイルが、放送経由での配信により完結しているモードである。
　ハイブリッドモード（Hybrid Mode）は、アプリケーションを構成するスタートアップページファイル（HTML文書ファイル）と、そのスタートアップページファイルで常に参照されるリソースファイル以外のリソースファイルについては、放送経由又は通信経由で配信されるモードである。この場合、EFDTには、常にスタートアップパッケージファイルURLが記述され、それ以外のリソースファイルについては、放送経由で配信するものについてのみ、転送制御属性を記述することになる。スタートアップページファイルとそのスタートアップページファイルで参照されるリソースファイルは、アトミックに取得、表示される。
　通信モード（Broadband Only Mode）は、アプリケーションを構成するスタートアップページファイル（HTML文書ファイル）と、そのスタートアップページファイルにより参照されるすべてのリソースファイルが、通信経由で配信されるモードである。この場合、EFDTには、常にスタートアップパッケージファイルURLが記述され、スタートアップパッケージファイルには、アプリケーションマニフェストファイルのみが格納されるため、それ以外のファイルの転送制御属性は記述されないことになる。
　以下、配信モードとして、放送モード、ハイブリッドモード、又は通信モードが設定された場合のそれぞれについて説明する。
（Ａ）放送モード
　まず、図１５乃至図１８を参照して、配信モードとして、放送モードが設定された場合について説明する。
（放送モード時のデータの流れ）
　図１５は、クライアント装置２０（図１）において、放送モードが設定されたときに処理される、コンテンツに付随するアプリケーションに関するデータの流れを説明する図である。なお、図１５のアプリケーションに関するデータの流れは、図１４に示した放送番組の各シーンに応じて提示されるアプリケーションの表示内容（ビューの内容）に対応している。
　図１５においては、図中の左側から右側に向かう時間軸の上側に、ROUTEセッションのLCCチャネルで配信されるEFDTが時系列で表される一方で、時間軸の下側に、ROUTEセッションのLCCチャネルで配信されるスタートアップパッケージファイルやリソースのファイルが模式的に表されている。
　図１５において、ファイルモードで配信されるEFDTは、時系列でバージョンが更新されるが、最初に取得されるVer1.0（v.1）のEFDTは、シーン１（図１４）の間に配信されるEFDTであって、当該EFDTを識別するEFDT URLのほかに、スタートアップパッケージURLが記述されている。クライアント装置２０では、このEFDT（Ver1.0）のスタートアップパッケージURLに従い、パッケージモードで配信されるスタートアップパッケージファイルが取得される（Ｓ１１）。
　このスタートアップパッケージファイル（StartUpPackage）には、当該スタートアップパッケージファイルを識別するスタートアップパッケージURL（StartUpPackageURL）が記述されるほかに、アプリケーションマニフェストファイル（AppManifest）と、スタートアップページファイル（HTML文書ファイル）と、リソースファイル（Resource1，Resource2，Resource3）が同梱されている。
　なお、スタートアップパッケージファイルにおいて、アプリケーションマニフェストのファイルと同梱されるファイルには、スタートアップページファイル（HTML文書ファイル）と、リソースファイル（Resource1，Resource2，Resource3）があるが、これらのファイルは、アプリケーションマニフェストのファイルと同時に取得されることが保証されている。
　また、リソースファイルは、例えば画像ファイルやスクリプトファイルである。例えば、Resource1は、JavaScript（登録商標）のコードが記述されたファイルであり、Resource2は、jpeg形式の画像ファイルであり、Resource3は、mp4形式の動画ファイルである。
　このスタートアップページファイル（HTML文書ファイル）によって、リソースファイル（Resource1，Resource2，Resource3）が参照されることで、アプリケーションの１番目のビュー（図１４）が提示される。
　ここで、アプリケーションマニフェストファイルは、拡張Web App Manifest（図１０）のフォーマットを採用しており、ファイルURLとしてのアプリケーションマニフェストURL（AppManifestURL）が記述されるほかに、スタートアップページURL（StartUpPageURL）と、リソースファイルごとの配信スケジュールに関する配信スケジュール情報（Attributes）を含んでいる。このスタートアップページURLによって、アプリケーションのエントリファイル（スタートアップページファイル）を示している。また、配信スケジュール情報には、各リソースファイルのファイルURL、サイズ、及び配信時刻に関する情報などが含まれる。
　シーン１からシーン２に遷移すると、EFDTの内容が変更され、そのバージョンがVer1.0（v.1）からVer2.0（v.2）に更新される。Ver2.0のEFDTは、シーン２（図１４）の間に配信されるEFDTであって、スタートアップパッケージURLとともに、シーン２の前段のパートで提示されるリソースファイル（Resource4）と、シーン２の後段のパートで提示されるリソースファイル（Resource5）のURLなどが記述される。
　Ver2.0のEFDTのスタートアップパッケージURLにより、Ver1.0のEFDTに応じて取得済みのスタートアップパッケージファイルが参照され（Ｓ１２）、リソースファイルURLにより、放送経由のファイルモードで配信されるリソースファイル（Resource4，Resource5）が取得される（Ｓ１３，Ｓ１４）。
　すなわち、スタートアップページファイル（HTML文書ファイル）自体は、最初のスタートアップページファイルと同じであるが、新たなリソースファイル（Resource4）の追加が行われた２番目のビュー（図１４）や、リソースファイル（Resource4）の消去とリソースファイル（Resource5）の追加が行われた３番目のビュー（図１４）が提示される。
　２番目のビュー（図１４）では、スタートアップページファイル（HTML文書ファイル）が、リソースファイルとして、Resource1乃至Resource4を参照している。また、３番目のビュー（図１４）では、スタートアップページファイル（HTML文書ファイル）が、リソースファイルとして、Resource1乃至Resource3と、Resource5を参照している。
　さらに、シーン２からシーン３に遷移するまでの間に、EFDTのバージョンが、Ver2.0（v.2）からVer M（v.M）まで順次更新される。Ver MのEFDTは、シーン３（図１４）の間に配信されるEFDTであって、スタートアップパッケージURLとともに、リソースファイル（Resource N）のURLなどが記述される。
　Ver MのEFDTのスタートアップパッケージURLにより、Ver1.0のEFDTに応じて取得済みのスタートアップパッケージファイルが参照され（Ｓ１５）、リソースファイルURLにより、放送経由のファイルモードで配信されるリソースファイル（Resource N）が取得される（Ｓ１５，Ｓ１６）。
　すなわち、スタートアップページファイル（HTML文書ファイル）自体は、最初のスタートアップページファイルと同じであるが、リソースファイル（Resource4乃至Resource N-1）の消去とリソースファイル（Resource N）の追加が行われたN番目のビュー（図１４）が提示される。N番目のビュー（図１４）では、スタートアップページファイル（HTML文書ファイル）が、リソースファイルとして、Resource1乃至Resource3と、Resource Nを参照している。
　次に、図１６乃至図１８のフローチャートを参照して、放送モードが設定された場合における伝送システム１（図１）の各装置で実行される処理の流れを説明する。
（送信側の処理の流れ）
　最初に、図１６のフローチャートを参照して、送信側システム１０により実行される、放送モードが設定された場合の送信側の処理の流れについて説明する。なお、この送信側の処理では、アプリケーションサーバ１０３、SCH/PKGサーバ１０４、及び放送サーバ１０５により実行される、コンテンツに付随するアプリケーションに関する処理を中心に説明し、DASHサーバ１０１などにより実行される、放送番組等のコンテンツに関する処理は省略するものとする。
　図１６のステップＳ３０１乃至Ｓ３０２の処理は、アプリケーションサーバ１０３（図１）により実行される。
　ステップＳ３０１において、アプリケーションサーバ１０３は、アプリケーションのオーサリング処理を行う。このオーサリング処理では、スタートアップページファイルや１又は複数のリソースファイルが生成され、それらのファイル群により構成されるアプリケーションが生成される。
　ステップＳ３０２において、アプリケーションサーバ１０３は、ステップＳ３０１の処理で生成されたスタートアップページファイルや１又は複数のリソースファイルなどのファイル群を、SCH/PKGサーバ１０４に送信する。
　図１６のステップＳ４０１乃至Ｓ４０８の処理は、SCH/PKGサーバ１０４（図１）により実行される。また、SCH/PKGサーバ１０４においては、ステップＳ３０２の処理で送信されたファイル群が受信される。
　ステップＳ４０１において、SCH/PKGサーバ１０４は、アプリケーションを構成するファイル（リソースファイル）の配信スケジュールを決定する。
　ステップＳ４０２において、SCH/PKGサーバ１０４は、ステップＳ４０１の処理で決定された配信スケジュールに従い、EFDTを生成する。なお、EFDTには、ステップＳ４０１の処理で決定された配信スケジュールに応じた転送制御情報を含めることができる。ステップＳ４０３において、SCH/PKGサーバ１０４は、ステップＳ４０２の処理で生成されたEFDTを、放送サーバ１０５に送信する。
　ステップＳ４０４において、SCH/PKGサーバ１０４は、ステップＳ３０１の処理で生成されたファイル群（例えば、スタートアップページファイルや１又は複数のリソースファイル等）に基づいて、スタートアップパッケージファイルを生成する。なお、スタートアップパッケージファイルに格納されるアプリケーションマニフェストファイルは、拡張Web App Manifest（図１０）のフォーマットを採用することで、ステップＳ４０１の処理で決定された配信スケジュールに応じた配信スケジュール情報を含めることができる。
　ステップＳ４０５において、SCH/PKGサーバ１０４は、ステップＳ４０４の処理で生成されたスタートアップパッケージファイルを、放送サーバ１０５に送信する。
　ステップＳ４０６において、SCH/PKGサーバ１０４は、ステップＳ４０１の処理で決定された配信スケジュールに従い、EFDTを生成する。なお、EFDTには、ステップＳ４０１の処理で決定された配信スケジュールに応じた転送制御情報を含めることができる。ステップＳ４０７において、SCH/PKGサーバ１０４は、ステップＳ４０６の処理で生成されたEFDTを、放送サーバ１０５に送信する。
　ステップＳ４０８において、SCH/PKGサーバ１０４は、ステップＳ３０１の処理で生成されたファイル群のうち、追加リソースファイルを、放送サーバ１０５に転送する。
　図１６のステップＳ５０１乃至Ｓ５０４は、放送サーバ１０５（図１）により実行される。また、放送サーバ１０５においては、ステップＳ４０３又はＳ４０７の処理で送信されたEFDTと、ステップＳ４０５の処理で送信されたスタートアップパッケージファイルと、ステップＳ４０７の処理で送信された追加リソースファイルが受信される。
　ステップＳ５０１において、放送サーバ１０５は、ステップＳ４０２の処理で生成されたEFDTを、ファイルモードで、伝送路８０を介して送信（一斉同報配信）する。
　ステップＳ５０２において、放送サーバ１０５は、ステップＳ４０４の処理で生成されたスタートアップパッケージファイルを、パッケージモードで、伝送路８０を介して送信（一斉同報配信）する。
　ステップＳ５０３において、放送サーバ１０５は、ステップＳ４０６の処理で生成されたEFDTを、ファイルモードで、伝送路８０を介して送信（一斉同報配信）する。
　ステップＳ５０４において、放送サーバ１０５は、ステップＳ４０８の処理で転送された追加リソースファイル（ステップＳ３０１の処理で生成されたリソースファイル）を、ファイルモードで、伝送路８０を介して送信（一斉同報配信）する。
　以上、送信側の処理の流れについて説明した。
（受信側の処理の流れ）
　次に、図１７及び図１８のフローチャートを参照して、クライアント装置２０により実行される、放送モードが設定された場合の受信側の処理の流れについて説明する。なお、この受信側の処理では、コンテンツに付随するアプリケーションに関する処理を中心に説明し、放送番組等のコンテンツに関する処理は省略するものとする。すなわち、図１７及び図１８の処理が実行される前提として、クライアント装置２０では、放送サーバ１０５から配信される放送番組や、通信サーバ１０６から配信されるVOD番組などのコンテンツが再生されているものとする。
　ステップＳ２０１において、放送ミドルウェア２０５は、IP/UDPパケットに格納されるSLTメタデータと、ROUTEセッションで伝送されるSLSシグナリングを取得する。ここで、SLSシグナリングとしては、USDメタデータが取得されることで、そこに記述されている情報に従い、S-TSIDメタデータが取得される。
　ステップＳ２０２において、放送ミドルウェア２０５は、ステップＳ２０１の処理で取得されたSLSシグナリング（S-TSIDメタデータ）に基づいて、ROUTEセッションのLCCチャネルで、ファイルモードにより配信されるEFDTを取得する。
　ステップＳ２０３において、放送ミドルウェア２０５は、ステップＳ２０２の処理で取得されたEFDTをパースする。
　ステップＳ２０４において、放送ミドルウェア２０５は、ステップＳ２０３の処理の解析結果に基づいて、ROUTEセッションのLCCチャネルで、パッケージモードにより配信されるスタートアップパッケージファイルを取得する。
　ステップＳ２０５において、放送ミドルウェア２０５は、ステップＳ２０４の処理で取得されたスタートアップパッケージファイルのアプリケーションマニフェストファイルに、新しいスタートアップページURLが記述されているかどうかを判定する。
　ステップＳ２０５において、新しいスタートアップページURLが記述されていないと判定された場合、処理は、ステップＳ２０１に戻り、それ以降の処理が繰り返される。そして、ステップＳ２０１乃至Ｓ２０５の処理が繰り返されることで、ステップＳ２０５の判定処理で、新しいスタートアップページURLが記述されていると判定された場合、処理は、ステップＳ２０６に進められる。
　ステップＳ２０６において、放送ミドルウェア２０５は、スタートアップパッケージファイルのアプリケーションマニフェストファイルに記述された（新しい）スタートアップページURLを、ブラウザ２０９に通知する。これにより、アプリケーションの起動が開始されることになる。
　なお、このスタートアップページURLが、放送ミドルウェア２０５から、ブラウザ２０９に通知される時点で、ステップＳ２０４の処理で取得されたスタートアップパッケージファイルに格納されたスタートアップページファイルと１又は複数のリソースのファイルが、メモリ２０３のローカルファイルシステム上に展開されているか、あるいはプロキシサーバ２１２のサーバサイドスクリプトがアクセス可能になっている。すなわち、アプリケーションの起動が開始された場合に、ブラウザ２０９からの要求に対して、直ちに返答できるように、スタートアップページファイルやリソースファイルの返答の準備がなされている。
　また、アプリケーションマニフェストファイルは、拡張Web App Manifest（図１０）のフォーマットを採用しているため、リソースファイルごとの配信スケジュール情報（リソースファイルのサイズや配信時刻）が記述されているが、この配信スケジュール情報は、放送ミドルウェア２０５又は処理部２０１（制御部２１１）により解析され、その解析結果は、メモリ２０３に記憶される。そして、例えば、メモリ２０３のメモリ管理を行う場合に、メモリ２０３の容量に十分な余裕があるときには、この配信スケジュール情報の解析結果を用いて、最初に、各リソースファイルのバイト数の総和に応じた記憶領域をメモリ部２０３に確保しておく、といった処理を行うことができる。
　一方で、例えば、メモリ２０３の容量に、十分な余裕がないときには、メモリ２０３の記憶領域の確保が必要になった時に、配信スケジュール情報の解析結果を参照して、その時に必要な記憶領域を確保するといった処理を行うことができる。さらに、メモリ２０３の容量に、十分な余裕がないときには、将来取得するリソースファイルのEFDTが取得される前に、配信スケジュール情報の解析結果に応じて（しかるべきタイミングで）、リソースファイル（の返答）の準備が必要になったとき、リソースファイルのサイズを見積もることで、あらかじめ必要な記憶領域をメモリ２０３上に確保しておく、といった処理を行うこともできる。ただし、ここに述べた配信スケジュール情報（の解析結果）を用いた処理は一例であって、リソースファイルの配信に応じた各種の処理を行うことができる。
　ステップＳ２２１において、ブラウザ２０９は、ステップＳ２０６の処理で通知されたスタートアップページURLに応じて、プロキシサーバ２１２に対し、スタートアップページファイルを要求する。
　ステップＳ２０７において、プロキシサーバ２１２は、ブラウザ２０９からのスタートアップページファイルの要求に応じて、返答の準備がなされているスタートアップページファイルを、ブラウザ２０９に返答する。これにより、ブラウザ２０９は、プロキシサーバ２１２からのスタートアップページファイルを取得することができる。
　ステップＳ２２２において、ブラウザ２０９は、プロキシサーバ２１２に対し、スタートアップページファイルに同梱されたスタートアップページファイル内のリソースファイルを要求する。
　ステップＳ２０８において、プロキシサーバ２１２は、ブラウザ２０９からのスタートアップページファイル内リソースファイルの要求に応じて、返答の準備がなされているスタートアップページファイルに同梱されたスタートアップページファイル内のリソースファイルを、ブラウザ２０９に返答する。
　ステップＳ２２３において、ブラウザ２０９は、プロキシサーバ２１２から取得されたスタートアップページファイル及びそのスタートアップページファイル内のリソースファイルに基づいて、レンダラ２１３を介してスタートアップページファイルを提示する。これにより、アプリケーション（のスタートアップページ）が、放送番組などのコンテンツとともに表示される。
　ステップＳ２０９において、放送ミドルウェア２０５は、ステップＳ２０１の処理で取得されたSLSシグナリング（S-TSIDメタデータ）に基づいて、ROUTEセッションのLCCチャネルで、ファイルモードにより配信されるEFDTを取得する。
　ステップＳ２１０において、放送ミドルウェア２０５は、ステップＳ２０９の処理で取得されたEFDTをパースする。なお、ステップＳ２０９の処理で取得されたEFDTのバージョン（例えばVer2.0）は、ステップＳ２０２の処理で取得されたEFDTのバージョン（例えばVer1.0）よりも新しいものとする。また、EFDTの転送制御属性として、転送制御情報（図１３）が記述されている場合、放送ミドルウェア２０５又は処理部２０１（制御部２１１）は、転送制御情報を解析して、その解析結果に応じた処理を行うことができる。例えば、転送制御情報（図１３）は、特定のリソースファイルの再送周期や再送終了日時が記述されるので、放送ミドルウェア２０５は、この再送周期や再送終了日時に応じて、再送される特定のリソースファイルを取得することができる。
　ステップＳ２１１において、放送ミドルウェア２０５は、ステップＳ２１０の解析結果に基づいて、ROUTEセッションのLCCチャネルで、ファイルモードにより配信される追加リソースファイルを取得する。
　一方で、ブラウザ２０９では、追加リソースファイルの提示タイミングが監視される（Ｓ２２４）。ステップＳ２２５において、ブラウザ２０９は、ステップＳ２２４の監視結果に基づいて、追加リソースファイルの提示タイミングが検知されたかどうかを判定する。
　ここでは、例えば、スタートアップページファイル内に、すべてのリソースファイルの提示タイミングが（番組全体にわたって）スケジューリングされている場合には、そのタイミングでタイマが発火するようにスクリプトをプログラムすることで、追加リソースファイルを提示するタイミングを検知することができる。また、スタートアップページファイルが、外部からのイベント（例えばコンテンツストリームにインバンドで転送されるアプリケーションサーバ１０３が発行するストリームイベント、又はユーザとのインタラクション）を持つようにスクリプトをプログラムすることで、追加リソースを提示するタイミングを検知することができる。
　これらのいずれにより検知する場合も、番組全体に渡って同一のスタートアップページファイルであればよく、スタートアップページファイルの更新は不要である。すなわち、スタートアップパッケージファイル内のスタートアップページファイルの更新はないため、常に、アプリケーションマニフェストファイル、スタートアップページファイル、スタートアップページファイル内で最初に参照されるリソースファイル（例えば、Resource1，Resource2，Resource3）は更新されないため、スタートアップパッケージファイルそのものの更新がないからである。
　ステップＳ２２５において、追加リソースファイルの提示タイミングが検知されていないと判定された場合、処理は、ステップＳ２２４に戻り、ステップＳ２２４乃至Ｓ２２５の監視処理が繰り返される。そして、ステップＳ２２５において、追加リソースファイルの提示タイミングが検知されたと判定された場合、処理は、ステップＳ２２６に進められる。
　ステップＳ２２６において、ブラウザ２０９は、ステップＳ２２５の処理の（提示タイミング検知の）検知結果に応じて、プロキシサーバ２１２に対し、追加リソースファイルを要求する。
　ステップＳ２１２において、プロキシサーバ２１２は、ブラウザ２０９からの追加リソースファイル要求に応じて、返答の準備がなされている追加リソースファイルを、ブラウザ２０９に返答する。これにより、ブラウザ２０９は、プロキシサーバ２１２からの追加リソースファイルを取得することができる。
　ステップＳ２２７において、ブラウザ２０９は、レンダラ２１３を制御して、プロキシサーバ２１２から取得された追加リソースファイルを提示する。これにより、アプリケーション（のスタートアップページ）に、追加リソースの情報が追加されることになる。
　以上、受信側の処理の流れについて説明した。
（Ｂ）ハイブリッドモード
　次に、図１９乃至図２２を参照して、配信モードとして、ハイブリッドモードが設定された場合について説明する。
（ハイブリッドモード時のデータの流れ）
　図１９は、クライアント装置２０（図１）において、ハイブリッドモードが設定されたときに処理される、コンテンツに付随するアプリケーションに関するデータの流れを説明する図である。なお、図１９のアプリケーションに関するデータの流れは、図１４に示した放送番組の各シーンに応じて提示されるアプリケーションの表示内容（ビューの内容）に対応している。
　図１９において、クライアント装置２０では、上述した図１５のＳ１１（放送モード）と同様に、EFDT（Ver1.0）のスタートアップパッケージURLに従い、パッケージモードで配信されるスタートアップパッケージファイルが取得される（Ｓ２１）。
　このスタートアップパッケージファイルには、当該スタートアップパッケージファイルを識別するスタートアップパッケージURLが記述されるほかに、アプリケーションマニフェストファイルと、スタートアップページファイル（HTML文書ファイル）と、リソースファイル（Resource1，Resource2，Resource3）が同梱されている。
　これにより、シーン１（図１４）においては、スタートアップページファイル（HTML文書ファイル）によって、リソースファイル（Resource1，Resource2，Resource3）が参照されることで、アプリケーションの１番目のビュー（図１４）が提示される。
　シーン１からシーン２に遷移すると、EFDTの内容が変更され、そのバージョンがVer1.0（v.1）からVer2.0（v.2）に更新される。Ver2.0のEFDTは、シーン２（図１４）の間に配信されるEFDTであって、スタートアップパッケージURLとともに、シーン２の後段のパートで提示されるリソースファイル（Resource5）のURLのみが記述される。
　すなわち、図１９の例では、リソースファイル（Resource5）は、放送経由で配信される一方で、リソースファイル（Resource4）は、通信経由で配信されるので、Ver2.0のEFDTには、放送経由で配信されるリソースファイル（Resource5）に関する情報のみが記述される。
　そして、Ver2.0のEFDTのスタートアップパッケージURLにより、Ver1.0のEFDTに応じて取得済みのスタートアップパッケージファイルが参照され（Ｓ２２）、リソースファイルURLにより、通信経由で配信されるリソースファイル（Resource4）や、放送経由で配信されるリソースファイル（Resource5）が取得される（Ｓ２３，Ｓ２４）。
　ただし、通信経由で配信されるリソースファイル（Resource4）のリソースファイルURLは、例えば、アプリケーションマニフェストファイルの配信スケジュール情報の各リソースファイル（Resource4）のファイルURLが用いられる。また、放送経由で配信されるリソースファイル（Resource5）のリソースファイルURLは、Ver2.0のEFDTに記述されるリソースファイルURLが用いられる。
　これにより、シーン２（図１４）の前段のパートでは、スタートアップページファイル自体は、最初のスタートアップページファイルと同じであるが、通信経由で配信されるリソースファイル（Resource4）の追加が行われた２番目のビュー（図１４）が提示される。また、シーン２（図１４）の後段のパートでは、スタートアップページファイル自体は、最初のスタートアップページファイルと同じであるが、リソースファイル（Resource4）の消去と、放送経由で配信されるリソースファイル（Resource5）の追加が行われた３番目のビュー（図１４）が提示される。
　さらに、シーン２からシーン３に遷移する間に、EFDTのバージョンが、Ver2.0（v.2）からVer M（v.M）まで順次更新される。Ver MのEFDTは、シーン３（図１４）の間に配信されるEFDTであって、スタートアップパッケージURLのみが記述される。
　そして、Ver MのEFDTのスタートアップパッケージURLにより、Ver1.0のEFDTに応じて取得済みのスタートアップパッケージファイルが参照され（Ｓ２５）、リソースファイルURLにより、通信経由で配信されるリソースファイル（Resource N）が取得される（Ｓ２６）。
　ただし、通信経由で配信されるリソースファイル（Resource N）のリソースファイルURLは、例えば、アプリケーションマニフェストファイルの配信スケジュール情報の各リソースファイルのファイルURLを用いることができる。
　これにより、シーン３では、スタートアップページファイル自体は、最初のスタートアップページファイルと同じであるが、通信経由で配信されるリソースファイル（Resource N）の追加が行われたN番目のビュー（図１４）が提示される。
　次に、図２０乃至図２２のフローチャートを参照して、ハイブリッドモードが設定された場合における伝送システム１（図１）の各装置で実行される処理の流れを説明する。
（送信側の処理の流れ）
　最初に、図２０のフローチャートを参照して、送信側システム１０により実行される、ハイブリッドモードが設定された場合の送信側の処理の流れについて説明する。
　図２０のステップＳ３２１乃至Ｓ３２２においては、図１６のステップＳ３０１乃至Ｓ３０２と同様に、アプリケーションサーバ（図１）によって、オーサリング処理が行われ、アプリケーションを構成するファイル群が生成される。
　図２０のステップＳ４２１乃至Ｓ４２９においては、図１６のステップＳ４０１乃至Ｓ４０８と同様に、SCH/PKGサーバ１０４（図１）によって、配信スケジュールの決定と、EFDTの生成と、スタートアップパッケージファイルの生成の処理が行われるが、追加リソースファイルの転送先に、放送サーバ１０５だけでなく、通信サーバ１０６が含まれる点が異なっている。
　すなわち、ステップＳ４２８において、SCH/PKGサーバ１０４は、ステップＳ３２１の処理で生成されたファイル群のうち、追加リソースファイルの一部を、放送サーバ１０５に転送する。また、ステップＳ４２９において、SCH/PKGサーバ１０４は、ステップＳ３２１の処理で生成されたファイル群のうち、追加リソースファイルの一部を、通信サーバ１０６に転送する。
　ステップＳ５２１乃至Ｓ５２４においては、図１６のステップＳ５０１乃至Ｓ５０４と同様に、放送サーバ１０５（図１）によって、EFDTと追加リソースファイルがファイルモードで、スタートアップパッケージファイルがパッケージモードで、伝送路８０を介して送信（一斉同報配信）される。
　図２０のステップＳ６２１乃至Ｓ６２２は、通信サーバ１０６（図１）により実行される。また、通信サーバ１０６においては、ステップＳ４２９の処理で転送された追加リソースファイルが受信される。
　ステップＳ６２１において、通信サーバ１０６は、インターネット９０を介して、クライアント装置２０から追加リソースファイルが要求されたかどうかを判定する。ステップＳ６２１において、追加リソースファイルが要求されていないと判定された場合、ステップＳ６２１の判定処理が繰り返される。
　一方で、ステップＳ６２１において、追加リソースファイルが要求されたと判定された場合、処理は、ステップＳ６２２に進められる。ステップＳ６２２において、通信サーバ１０６は、ステップＳ４２９の処理で転送された追加リソースファイル（ステップＳ３２１の処理で生成されたリソースファイル）を、要求元のクライアント装置２０に対して、インターネット９０を介して配信する。
　以上、送信側の処理の流れについて説明した。
（受信側の処理の流れ）
　次に、図２１及び図２２のフローチャートを参照して、クライアント装置２０により実行される、ハイブリッドモードが設定された場合の受信側の処理の流れについて説明する。なお、この受信側の処理が実行される前提として、上述した図１７及び図１８と同様に、クライアント装置２０では、放送サーバ１０５から配信される放送番組や、通信サーバ１０６から配信されるVOD番組などのコンテンツが再生されているものとする。
　図２１のステップＳ２３１乃至Ｓ２３８においては、図１７のステップＳ２０１乃至Ｓ２０８と同様に、放送ミドルウェア２０５によって、放送サーバ１０５から配信されるEFDTとスタートアップパッケージファイルが処理され、スタートアップパッケージファイルのアプリケーションマニフェストファイルに、新しいスタートアップページURLが記述されている場合には、当該スタートアップページURLが、ブラウザ２０９に通知される。また、プロキシサーバ２１２によって、ブラウザ２０９からの要求に応じて、スタートアップページファイルとそのスタートアップファイル内のリソースファイルが返答される。
　また、図２１のステップＳ２５１乃至Ｓ２５３においては、図１７のステップＳ２２１乃至Ｓ２２３と同様に、ブラウザ２０９によって、スタートアップページファイルとそのスタートアップファイル内のリソースファイルが要求され、レンダラ２１３によって、プロキシサーバ２１２からの返答に応じて、スタートアップページが提示される。
　図２２のステップＳ２３９乃至Ｓ２４２においては、図１８のステップＳ２０９乃至Ｓ２１２と同様に、放送ミドルウェア２０５によって、放送サーバ１０５から配信されるEFDTと追加リソースファイルが処理される。また、プロキシサーバ２１２によって、ブラウザ２０９からの要求に応じて、追加リソースファイルが返答される。
　また、図２２のステップＳ２５４乃至Ｓ２５７においては、図１８のステップＳ２２４乃至Ｓ２２７と同様に、ブラウザ２０９によって、放送経由で配信される追加リソースファイルの提示タイミングが監視され、その提示タイミングになったとき、追加リソースファイルが要求される。また、レンダラ２１３によって、プロキシサーバ２１２からの返答に応じて、追加リソースファイルが提示される。
　このようにして、放送サーバ１０５から放送経由で配信される追加リソースファイルが提示される。一方で、追加リソースファイルが、通信サーバ１０６から通信経由で配信される場合、以下のように処理される。
　すなわち、図２２のステップＳ２５８において、ブラウザ２０９は、通信経由で配信される追加リソースファイルの提示タイミングを監視する。ステップＳ２５９において、ブラウザ２０９は、ステップＳ２５８の監視結果に基づいて、通信経由で配信される追加リソースファイルの提示タイミングが検知されたかどうかを判定する。
　ステップＳ２５９において、追加リソースファイルの提示タイミングが検知されていないと判定された場合、処理は、ステップＳ２５８に戻り、ステップＳ２５８乃至Ｓ２５９の監視処理が繰り返される。そして、ステップＳ２５９において、追加リソースファイルの提示タイミングが検知されたと判定された場合、処理は、ステップＳ２６０に進められる。
　ステップＳ２６０において、ブラウザ２０９は、ステップＳ２５９の処理の（提示タイミング検知の）検知結果に応じて、プロキシサーバ２１２に対し、追加リソースファイルを要求する。
　ステップＳ２４３において、プロキシサーバ２１２は、ブラウザ２０９からの追加リソースファイルの要求に応じて、インターネット９０を介して通信サーバ１０６に対し、追加リソースファイルを要求する。ステップＳ２４４において、プロキシサーバ２１２は、ステップＳ２４３の要求に応じて、インターネット９０を介して通信サーバ１０６から配信される追加リソースファイルを取得する。
　ステップＳ２４５において、プロキシサーバ２１２は、ステップＳ２４４の処理で取得した追加リソースファイルを、ブラウザ２０９に返答する。これにより、ブラウザ２０９は、プロキシサーバ２１２からの追加リソースファイルを取得することができる。
　ステップＳ２６１において、ブラウザ２０９は、レンダラ２１３を制御して、プロキシサーバ２１２から取得された追加リソースファイルを提示する。これにより、アプリケーション（のスタートアップページ）に、追加リソースの情報が追加されることになる。
　以上、受信側の処理の流れについて説明した。
（Ｃ）通信モード
　最後に、図２３乃至図２６を参照して、配信モードとして、通信モードが設定された場合について説明する。
（通信モード時のデータの流れ）
　図２３は、クライアント装置２０（図１）において、通信モードが設定されたときに処理される、コンテンツに付随するアプリケーションに関するデータの流れを説明する図である。なお、図２３のアプリケーションに関するデータの流れは、図１４に示した放送番組の各シーンに応じて提示されるアプリケーションの表示内容（ビューの内容）に対応している。
　図２３において、クライアント装置２０では、上述した図１５のＳ１１（放送モード）と同様に、EFDT（Ver1.0）のスタートアップパッケージURLに従い、パッケージモードで配信されるスタートアップパッケージファイルが取得される（Ｓ３１）。
　このスタートアップパッケージファイルには、当該スタートアップパッケージファイルを識別するスタートアップパッケージURLが記述されるほかに、アプリケーションマニフェストファイルが含まれる。
　アプリケーションマニフェストファイルには、スタートアップページURLのほか、配信スケジュール情報として、各リソースファイルのファイルURLが記述されている。クライアント装置２０は、これらのURLに従い、インターネット９０を介して通信サーバ１０６にアクセスすることで、通信経由で配信される、スタートアップページファイル（HTML文書ファイル）と、リソースファイル（Resource1，Resource2，Resource3）を取得することができる。
　これにより、シーン１（図１４）においては、スタートアップページファイル（HTML文書ファイル）によって、リソースファイル（Resource1，Resource2，Resource3）が参照されることで、アプリケーションの１番目のビュー（図１４）が提示される。
　シーン１からシーン２に遷移すると、EFDTの内容が変更され、そのバージョンがVer1.0（v.1）からVer2.0（v.2）に更新される。Ver2.0のEFDTは、シーン２（図１４）の間に配信されるEFDTであって、スタートアップパッケージURLが記述される。すなわち、通信モードでは、シーン２の前段のパートと後段のパートで提示されるリソースファイル（Resource4，Resource5）が共に通信経由で配信されるため、Ver2.0のEFDTには、リソースファイルのURLは不要とされる。
　そして、Ver2.0のEFDTのスタートアップパッケージURLにより、Ver1.0のEFDTに応じて取得済みのスタートアップパッケージファイルが参照され（Ｓ３２）、リソースファイルURLにより、通信経由で配信されるリソースファイル（Resource4，Resource5）が取得される（Ｓ３３，Ｓ３４）。
　ただし、通信経由で配信されるリソースファイル（Resource4，Resource5）のリソースファイルURLは、例えば、アプリケーションマニフェストファイルの配信スケジュール情報の各リソースファイル（Resource4，Resource5）のファイルURLが用いることができる。
　これにより、シーン２（図１４）の前段のパートでは、スタートアップページファイル自体は、最初のスタートアップページファイルと同じであるが、通信経由で配信されるリソースファイル（Resource4）の追加が行われた２番目のビュー（図１４）が提示される。また、シーン２（図１４）の後段のパートでは、スタートアップページファイル自体は、最初のスタートアップページファイルと同じであるが、リソースファイル（Resource4）の消去と、通信経由で配信されるリソースファイル（Resource5）の追加が行われた３番目のビュー（図１４）が提示される。
　さらに、シーン２からシーン３に遷移する間に、EFDTのバージョンが、Ver2.0（v.2）からVer M（v.M）まで順次更新される。Ver MのEFDTは、シーン３（図１４）の間に配信されるEFDTであって、スタートアップパッケージURLのみが記述される。
　そして、Ver MのEFDTのスタートアップパッケージURLにより、Ver1.0のEFDTに応じて取得済みのスタートアップパッケージファイルが参照され（Ｓ３５）、リソースファイルURLにより、通信経由で配信されるリソースファイル（Resource N）が取得される（Ｓ３６）。
　ただし、通信経由で配信されるリソースファイル（Resource N）のリソースファイルURLは、例えば、アプリケーションマニフェストファイルの配信スケジュール情報の各リソースファイルのファイルURLを用いることができる。
　これにより、シーン３では、スタートアップページファイル自体は、最初のスタートアップページファイルと同じであるが、通信経由で配信されるリソースファイル（Resource N）の追加が行われたN番目のビュー（図１４）が提示される。
　次に、図２４乃至図２６のフローチャートを参照して、通信モードが設定された場合における伝送システム１（図１）の各装置で実行される処理の流れを説明する。
（送信側の処理の流れ）
　最初に、図２４のフローチャートを参照して、送信側システム１０により実行される、通信モードが設定された場合の送信側の処理の流れについて説明する。
　図２４のステップＳ３４１乃至Ｓ３４２においては、図１６のステップＳ３０１乃至Ｓ３０２と同様に、アプリケーションサーバ（図１）によって、オーサリング処理が行われ、アプリケーションを構成するファイル群が生成される。
　図２４のステップＳ４２１乃至Ｓ４２７においては、図１６のステップＳ４０１乃至Ｓ４０８と同様に、SCH/PKGサーバ１０４（図１）によって、配信スケジュールの決定と、EFDTの生成と、スタートアップパッケージファイルの生成の処理が行われるが、スタートアップページファイルとそのスタートアップページファイル内のリソースファイル、追加リソースファイルの転送先が、放送サーバ１０５ではなく、通信サーバ１０６となる点が異なっている。
　図２４のステップＳ５４１乃至Ｓ５４２においては、図１６のステップＳ５０１乃至Ｓ５０２と同様に、放送サーバ１０５（図１）によって、EFDTがファイルモードで、スタートアップパッケージファイルがパッケージモードで、伝送路８０を介して送信（一斉同報配信）される。
　図２４のステップＳ６４１乃至Ｓ６４６は、通信サーバ１０６（図１）により実行される。また、通信サーバ１０６においては、ステップＳ４４６の処理で転送されたスタートアップページファイルとそのスタートアップページファイル内のリソースファイルと、ステップＳ４４７の処理で転送された追加リソースファイルが受信される。
　図２４のステップＳ６４１乃至Ｓ６４６においては、図２０のステップＳ６２１乃至Ｓ６２２と同様に、インターネット９０を介したクライアント装置２０からの要求に応じて、各種のファイルが配信される。
　ステップＳ６４１において、通信サーバ１０６は、インターネット９０を介して、クライアント装置２０からスタートアップページファイルが要求されたかどうかを判定する。ステップＳ６４１において、スタートアップページファイルが要求されていないと判定された場合、ステップＳ６４１の判定処理が繰り返される。
　一方で、ステップＳ６４１において、スタートアップページファイルが要求されたと判定された場合、処理は、ステップＳ６４２に進められる。ステップＳ６４２において、通信サーバ１０６は、ステップＳ４４６の処理で転送されたスタートアップページファイル（ステップＳ３４１の処理で生成されたスタートアップページファイル）を、要求元のクライアント装置２０に対して、インターネット９０を介して配信する。
　ステップＳ６４３において、通信サーバ１０６は、インターネット９０を介して、クライアント装置２０からスタートアップページファイル内リソースファイルが要求されたかどうかを判定する。ステップＳ６４３において、スタートアップページファイル内リソースファイルが要求されていないと判定された場合、ステップＳ６４３の判定処理が繰り返される。
　一方で、ステップＳ６４３において、スタートアップページファイル内リソースファイルが要求されたと判定された場合、処理は、ステップＳ６４４に進められる。ステップＳ６４４において、通信サーバ１０６は、ステップＳ４４６の処理で転送されたスタートアップページファイル内リソースファイル（ステップＳ３４１の処理で生成されたリソースファイル）を、要求元のクライアント装置２０に対して、インターネット９０を介して配信する。
　ステップＳ６４５において、通信サーバ１０６は、インターネット９０を介して、クライアント装置２０から追加リソースファイルが要求されたかどうかを判定する。ステップＳ６４５において、追加リソースファイルが要求されていないと判定された場合、ステップＳ６４５の判定処理が繰り返される。
　一方で、ステップＳ６４５において、追加リソースファイルが要求されたと判定された場合、処理は、ステップＳ６４６に進められる。ステップＳ６４６において、通信サーバ１０６は、ステップＳ４４７の処理で転送された追加リソースファイル（ステップＳ３４１の処理で生成されたリソースファイル）を、要求元のクライアント装置２０に対して、インターネット９０を介して配信する。
　以上、送信側の処理の流れについて説明した。
（受信側の処理の流れ）
　次に、図２５及び図２６のフローチャートを参照して、クライアント装置２０により実行される、通信モードが設定された場合の受信側の処理の流れについて説明する。なお、この受信側の処理が実行される前提として、上述した図１７及び図１８と同様に、クライアント装置２０では、放送サーバ１０５から配信される放送番組や、通信サーバ１０６から配信されるVOD番組などのコンテンツが再生されているものとする。
　図２５のステップＳ２７１乃至Ｓ２７５においては、図１７のステップＳ２０１乃至Ｓ２０５と同様に、放送ミドルウェア２０５によって、放送サーバ１０５から配信されるEFDTとスタートアップパッケージファイルが処理され、スタートアップパッケージファイルのアプリケーションマニフェストファイルに、新しいスタートアップページURLが記述されているかどうかが判定される（Ｓ２７５）。
　ステップＳ２７５において、アプリケーションマニフェストファイルに、新しいスタートアップページURLが記述されていると判定された場合、処理は、ステップＳ２７６に進められる。
　ステップＳ２７６において、プロキシサーバ２１２は、ステップＳ２７５の判定結果に応じて、インターネット９０を介して通信サーバ１０６に対し、スタートアップページファイルを要求する。ステップＳ２７７において、プロキシサーバ２１２は、ステップＳ２７６の要求に応じて、インターネット９０を介して通信サーバ１０６から配信されるスタートアップページファイルを取得する。
　ステップＳ２７８において、プロキシサーバ２１２は、スタートアップパッケージファイルのアプリケーションマニフェストファイルに記述されるスタートアップページURLを、ブラウザ２０９に通知する。
　ステップＳ２９１において、ブラウザ２０９は、ステップＳ２７８の処理で通知されたスタートアップページURLに応じて、プロキシサーバ２１２に対し、スタートアップページファイルを要求する。
　ステップＳ２７９において、プロキシサーバ２１２は、ブラウザ２０９からのスタートアップページファイルの要求に応じて、返答の準備がなされているスタートアップページファイルを、ブラウザ２０９に返答する。これにより、ブラウザ２０９は、プロキシサーバ２１２からのスタートアップページファイルを取得することができる。
　ステップＳ２９２において、ブラウザ２０９は、プロキシサーバ２１２に対し、スタートアップページファイル内のリソースファイルを要求する。
　ステップＳ２８０において、プロキシサーバ２１２は、ブラウザ２０９からのスタートアップページファイル内のリソースファイルの要求に応じて、インターネット９０を介して通信サーバ１０６に対し、スタートアップページファイル内のリソースファイルを要求する。ステップＳ２８１において、プロキシサーバ２１２は、ステップＳ２８０の要求に応じて、インターネット９０を介して通信サーバ１０６から配信されるスタートアップページファイル内のリソースファイルを取得する。
　ステップＳ２８２において、プロキシサーバ２１２は、ステップＳ２８１の処理で取得されたスタートアップページファイル内のリソースファイルを、ブラウザ２０９に返答する。
　ステップＳ２９３において、ブラウザ２０９は、プロキシサーバ２１２から取得されたスタートアップページファイル及びそのスタートアップページファイル内のリソースファイルに基づいて、スタートアップページを提示する。これにより、アプリケーションが、放送番組などのコンテンツとともに表示される。
　図２６のステップＳ２９４乃至Ｓ２９６は、図２２のステップＳ２５８乃至Ｓ２６０と同様に、ブラウザ２０９によって、通信経由で配信される追加リソースファイルの提示タイミングが監視され、その提示タイミングになったとき、追加リソースファイルが要求される。
　図２６のステップＳ２８３乃至Ｓ２８５は、図２２のステップＳ２４３乃至Ｓ２４５と同様に、プロキシサーバ２１２によって、インターネット９０を介して通信サーバ１０６から追加リソースファイルが取得され、返答される。また、図２６のステップＳ２９７は、図２２のステップＳ２６１と同様に、レンダラ２１３によって、プロキシサーバ２１２からの返答に応じて、追加リソースファイルが提示される。これにより、アプリケーション（のスタートアップページ）に、追加リソースの情報が追加されることになる。
　以上、受信側の処理の流れについて説明した。
＜４．シグナリングの例＞
　次に、図２７乃至図３１を参照して、シグナリングのフォーマットの例を説明する。
（USDのフォーマット）
　図２７は、XML形式のUSDメタデータのフォーマットの例を示す図である。なお、図２７において、要素と属性のうち、属性には「@」が付されている。また、インデントされた要素と属性は、その上位の要素に対して指定されたものとなる。これらの関係は、後述する他のシグナリングのフォーマットでも同様とされる。
　bundleDescription要素は、ルート要素であって、userServiceDescription要素（USD要素）の上位要素となる。このuserServiceDescription要素は、serviceId属性、atsc:serviceId属性、atsc:fullMPDUri属性、atsc:sTSIDUri属性、name要素、serviceLanguage要素、atsc:capabilityCode要素、及び、deliveryMethod要素の上位要素となる。
　serviceId属性とatsc:serviceId属性には、サービスIDが指定される。atsc:fullMPDUri属性には、MPDメタデータを参照するためのURIが指定される。atsc:sTSIDUri属性には、S-TSIDメタデータを参照するためのURIが指定される。なお、S-TSIDメタデータのフォーマットの詳細は、後述する図２８を参照して説明する。
　name要素には、ATSC3.0のサービスの名称が指定される。name要素は、lang属性の上位要素となる。lang属性には、ATSC3.0のサービスの名称の言語が指定される。serviceLanguage要素には、ATSC3.0のサービスで利用できる言語が指定される。atsc:capabilityCode要素には、機能に関するコードが指定される。
　deliveryMethod要素には、データの配信方法に関する情報が指定される。deliveryMethod要素は、atsc:broadcastAppService要素及びatsc:unicastAppService要素の上位要素となる。atsc:broadcastAppService要素は、basePattern要素の上位要素であって、放送経由での配信に関する情報が指定される。atsc:unicastAppService要素は、basePattern要素の上位要素であって、通信経由での配信に関する情報が指定される。
（S-TSIDのフォーマット）
　図２８は、XML形式のS-TSIDメタデータのフォーマットの例を示す図である。
　S-TSID要素は、ルート要素であって、RS要素の上位要素となる。RS要素には、ROUTEセッションに関する情報が指定される。RS要素は、bsid属性、sIpAddr属性、dIpAddr属性、dport属性、PLPID属性、及び、LS要素の上位要素となる。
　bsid属性には、ブロードキャストストリームIDが指定される。sIpAddr属性には、送信元（source）のIPアドレスが指定される。dIpAddr属性には、宛先（destination）のIPアドレスが指定される。dport属性には、宛先（destination）のポート番号が指定される。PLPID属性には、ROUTEセッションのPLPのIDが指定される。
　LS要素には、LCTセッションに関する情報が指定される。LS要素は、tsi属性、PLPID属性、bw属性、startTime属性、endTime属性、SrcFlow要素、及び、RprFlow要素の上位要素となる。
　tsi属性には、TSIが指定される。PLPID属性には、PLPのIDが指定される。bw属性には、帯域幅が指定される。startTime属性とendTime属性には、開始日時と終了日時が指定される。SrcFlow要素には、ソースフロー情報が指定される。
　ここで、図２９には、図２８のS-TSIDメタデータに含まれるSrcFlow要素のフォーマットが示されている。
　図２９のSrcFlow要素は、rt属性、minBuffSize属性、EFDT要素、ContentInfo要素、及び、Payload要素の上位要素となる。
　minBuffSize属性には、クライアント装置２０が必要とする最小バッファサイズが指定される。EFDT要素には、拡張されたFDT（Extended FDT）に関する情報が指定される。ContentInfo要素には、コンテンツに関する情報が指定される。
　Payload要素は、codePoint属性、formatID属性、frag属性、order属性、srcFecPayloadID属性、及び、FECParams属性の上位要素であって、ソースフローのオブジェクトを格納するROUTEパケットのペイロードに関する情報が指定される。
　なお、formatID属性の値により、ファイルモード（単一のファイルを格納する構造）又はパッケージモード（複数のファイルを同梱する構造）が区別される。すなわち、Payload要素の属性であるcodePoint属性の値は、ファイルを分割して運ぶLCTパケットヘッダのCodePointに等しくなる。このCodePointの値によって、Payload要素の属性の値の組（Payload@formatID，Payload@frag，Payload@order，Payload@srcFecPayloadIDの値の組）を一意に指定することができるようになっている。
　すなわち、LCTパケットのTSI(Transport Session Identifier)の値により、S-TSIDの中の該当するLCTチャネル（セッション）の記述を検索し（S-TSID/RS/LS@tsi）、さらに、当該LSのSrcFlow/Payload@codePointの値と、LCTパケットヘッダのCodePointの値がマッチするPayload属性を検索する。そして、検索されたPayload属性の属性として記述されるformatID属性の値により、そのLCTパケットが運ぶファイルが、ファイルモードであるのか、あるいはパッケージモードであるのかが区別されることになる。
　ここで、図３０には、図２９のSrcFlow要素に含まれるEFDT要素のフォーマットが示されている。図３０のEFDT要素は、tsi属性、idRef属性、version属性、maxExpiresDelta属性、maxTransportSize属性、FileTemplate属性、及び、FDTParameters属性の上位要素となる。
　EFDT要素のtsi属性の値で示されるROUTEプロトコルのLCTチャネル（セッション）には、EFDT（のファイル）と、そのEFDTにより記述されるファイル群が転送される。EFDT（のファイル）と、EFDTにより参照されるファイル群が転送されるLCTチャネル（セッション）において、EFDTは、TOI(Transport Object Identifier) = 0がアサインされる一方で、その他のファイル群のTOIは、EFDT内に記述される。
　ここで、EFDT要素は、図３０に示した構造を有し、ルート要素は、FDT-Instanceと呼ばれ、FDT-Instance型を持っている。このFDT-Instanceの中には、複数のFile要素が存在し、それぞれのファイルの転送制御属性が記述される。この転送制御属性の主なものとしては、例えば、ファイル名であるContent-Locationや、転送上の識別子であるTOIなどがある。
　図３１には、EFDTのXMLスキーマの例が図示されている。図３１においては、枠Ａ内に、リソースファイルの再送周期（Retransmission-Cycle）の属性（図１３）と、リソースファイルの再送終了日時（Retransmission-End）の属性（図１３）が定義されている。
＜５．変形例＞
　上述した説明としては、デジタル放送の規格として、米国等で採用されている方式であるATSC（特に、ATSC3.0）を説明したが、本技術は、日本等が採用する方式であるISDB(Integrated Services Digital Broadcasting)や、欧州の各国等が採用する方式であるDVB(Digital Video Broadcasting)などに適用するようにしてもよい。また、上述した説明では、IP伝送方式が採用されるATSC3.0を例にして説明したが、IP伝送方式に限らず、例えば、MPEG2-TS(Transport Stream)方式等の他の方式に適用するようにしてもよい。
　また、デジタル放送の規格としては、地上波放送のほか、放送衛星（BS：Broadcasting Satellite)や通信衛星（CS：Communications Satellite）等を利用した衛星放送や、ケーブルテレビ（CATV）等の有線放送などの規格に適用することができる。
　また、上述したシグナリングなどの名称は、一例であって、他の名称が用いられる場合がある。ただし、これらの名称の違いは、形式的な違いであって、対象のシグナリングなどの実質的な内容が異なるものではない。例えば、AST(Application Signaling Table)は、AIT(Application Information Table)などと称される場合がある。さらに、シグナリングがXML等のマークアップ言語により記述される場合において、それらの要素や属性の名称は一例であって、他の名称が採用されるようにしてもよい。ただし、これらの名称の違いは、形式的な違いであって、それらの要素や属性の実質的な内容が異なるものではない。
　また、上述した説明では、LLSシグナリングとして、SLTメタデータを説明したが、LLSシグナリングには、EAT(Emergency Alerting Table)やRRT(Region Rating Table)などのメタデータが含まれるようにしてもよい。EATメタデータは、緊急に告知する必要がある緊急情報に関する情報を含む。RRTメタデータは、レーティングに関する情報を含む。
　なお、アプリケーションは、HTML5等のマークアップ言語やJavaScript（登録商標）等のスクリプト言語で開発されたアプリケーションに限らず、例えば、Java（登録商標）などのプログラミング言語で開発されたアプリケーションであってもよい。また、上述したコンテンツには、動画や広告のほか、例えば、電子書籍やゲーム、音楽など、あらゆるコンテンツを含めることができる。
　また、本技術は、伝送路として、放送網以外の伝送路、すなわち、例えば、インターネットや電話網等の通信回線（通信網）などを利用することを想定して規定されている所定の規格（デジタル放送の規格以外の規格）などにも適用することができる。
＜６．コンピュータの構成＞
　上述した一連の処理は、ハードウェアにより実行することもできるし、ソフトウェアにより実行することもできる。一連の処理をソフトウェアにより実行する場合には、そのソフトウェアを構成するプログラムが、コンピュータにインストールされる。図３２は、上述した一連の処理をプログラムにより実行するコンピュータのハードウェアの構成例を示す図である。
　コンピュータ１０００において、CPU(Central Processing Unit)１００１、ROM(Read Only Memory)１００２、RAM(Random Access Memory)１００３は、バス１００４により相互に接続されている。バス１００４には、さらに、入出力インターフェース１００５が接続されている。入出力インターフェース１００５には、入力部１００６、出力部１００７、記録部１００８、通信部１００９、及び、ドライブ１０１０が接続されている。
　入力部１００６は、キーボード、マウス、マイクロフォンなどよりなる。出力部１００７は、ディスプレイ、スピーカなどよりなる。記録部１００８は、ハードディスクや不揮発性のメモリなどよりなる。通信部１００９は、ネットワークインターフェースなどよりなる。ドライブ１０１０は、磁気ディスク、光ディスク、光磁気ディスク、又は半導体メモリなどのリムーバブルメディア１０１１を駆動する。
　以上のように構成されるコンピュータ１０００では、CPU１００１が、ROM１００２や記録部１００８に記録されているプログラムを、入出力インターフェース１００５及びバス１００４を介して、RAM１００３にロードして実行することにより、上述した一連の処理が行われる。
　コンピュータ１０００（CPU１００１）が実行するプログラムは、例えば、パッケージメディア等としてのリムーバブルメディア１０１１に記録して提供することができる。また、プログラムは、ローカルエリアネットワーク、インターネット、デジタル衛星放送といった、有線又は無線の伝送媒体を介して提供することができる。
　コンピュータ１０００では、プログラムは、リムーバブルメディア１０１１をドライブ１０１０に装着することにより、入出力インターフェース１００５を介して、記録部１００８にインストールすることができる。また、プログラムは、有線又は無線の伝送媒体を介して、通信部１００９で受信し、記録部１００８にインストールすることができる。その他、プログラムは、ROM１００２や記録部１００８に、あらかじめインストールしておくことができる。
　ここで、本明細書において、コンピュータがプログラムに従って行う処理は、必ずしもフローチャートとして記載された順序に沿って時系列に行われる必要はない。すなわち、コンピュータがプログラムに従って行う処理は、並列的あるいは個別に実行される処理（例えば、並列処理あるいはオブジェクトによる処理）も含む。また、プログラムは、１のコンピュータ（プロセッサ）により処理されるものであってもよいし、複数のコンピュータによって分散処理されるものであってもよい。
　なお、本技術の実施の形態は、上述した実施の形態に限定されるものではなく、本技術の要旨を逸脱しない範囲において種々の変更が可能である。
　また、本技術は、以下のような構成をとることができる。
（１）
　コンテンツを受信する受信部と、
　前記コンテンツとともに伝送される、前記コンテンツに付随するアプリケーションの一部である１又は複数のリソースファイルの配信に関するリソース配信情報を取得する取得部と、
　取得された前記リソース配信情報に基づいて、前記リソースファイルの配信に応じた処理を行う処理部と
　を備える受信装置。
（２）
　前記リソース配信情報は、前記リソースファイルごとの配信スケジュールに関する配信スケジュール情報を含んでいる
　（１）に記載の受信装置。
（３）
　前記配信スケジュール情報は、前記リソースファイルごとの取得先を示す情報、並びに前記リソースファイルごとのサイズ及び配信時刻の少なくとも一方に関する情報を含んでいる
　（２）に記載の受信装置。
（４）
　前記リソース配信情報は、時間帯に応じて配信スケジュールが変更される可能性のある特定のリソースファイルの配信に関する転送制御情報を含んでいる
　（２）に記載の受信装置。
（５）
　前記転送制御情報は、前記特定のリソースファイルの再送周期及び再送終了時刻の少なくとも一方に関する情報を含んでいる
　（４）に記載の受信装置。
（６）
　前記コンテンツのビデオとオーディオのデータは、ストリーミングファイル転送用のプロトコルであるROUTE(Real-time Object Delivery over Unidirectional Transport)セッションで伝送され、
　前記配信スケジュール情報は、ROUTEセッションで伝送されるスタートアップパッケージファイルに同梱されるアプリケーションマニフェストファイルに含まれ、
　前記転送制御情報は、ROUTEプロトコルの制御情報であるS-TSID(Service-based Transport Session Instance Description)により特定される、ROUTEセッションで伝送されるEFDT(Extended FDT)に含まれる
　（４）又は（５）に記載の受信装置。
（７）
　受信装置のデータ処理方法において、
　前記受信装置が、
　コンテンツとともに伝送される、前記コンテンツに付随するアプリケーションの一部である１又は複数のリソースファイルの配信に関するリソース配信情報を取得し、
　取得された前記リソース配信情報に基づいて、前記リソースファイルの配信に応じた処理を行う
　ステップを含むデータ処理方法。
（８）
　前記リソース配信情報は、前記リソースファイルごとの配信スケジュールに関する配信スケジュール情報を含んでいる
　（７）に記載のデータ処理方法。
（９）
　前記配信スケジュール情報は、前記リソースファイルごとの取得先を示す情報、並びに前記リソースファイルごとのサイズ及び配信時刻の少なくとも一方に関する情報を含んでいる
　（８）に記載のデータ処理方法。
（１０）
　前記リソース配信情報は、時間帯に応じて配信スケジュールが変更される可能性のある特定のリソースファイルの配信に関する転送制御情報を含んでいる
　（８）に記載のデータ処理方法。
（１１）
　前記転送制御情報は、前記特定のリソースファイルの再送周期及び再送終了時刻の少なくとも一方に関する情報を含んでいる
　（１０）に記載のデータ処理方法。
（１２）
　前記コンテンツのビデオとオーディオのデータは、ストリーミングファイル転送用のプロトコルであるROUTEセッションで伝送され、
　前記配信スケジュール情報は、ROUTEセッションで伝送されるスタートアップパッケージファイルに同梱されるアプリケーションマニフェストファイルに含まれ、
　前記転送制御情報は、ROUTEプロトコルの制御情報であるS-TSIDにより特定される、ROUTEセッションで伝送されるEFDTに含まれる
　（１０）又は（１１）に記載のデータ処理方法。
（１３）
　コンテンツに付随するアプリケーションの一部である１又は複数のリソースファイルの配信に関するリソース配信情報を生成する生成部と、
　前記コンテンツとともに、前記リソース配信情報を送信する送信部と
　を備える送信装置。
（１４）
　前記リソース配信情報は、前記リソースファイルごとの配信スケジュールに関する配信スケジュール情報を含んでいる
　（１３）に記載の送信装置。
（１５）
　前記配信スケジュール情報は、前記リソースファイルごとの取得先を示す情報、並びに前記リソースファイルごとのサイズ及び配信時刻の少なくとも一方に関する情報を含んでいる
　（１４）に記載の送信装置。
（１６）
　前記リソース配信情報は、時間帯に応じて配信スケジュールが変更される可能性のある特定のリソースファイルの配信に関する転送制御情報を含んでいる
　（１４）に記載の送信装置。
（１７）
　前記転送制御情報は、前記特定のリソースファイルの再送周期及び再送終了時刻の少なくとも一方に関する情報を含んでいる
　（１６）に記載の送信装置。
（１８）
　前記コンテンツのビデオとオーディオのデータは、ストリーミングファイル転送用のプロトコルであるROUTEセッションで伝送され、
　前記配信スケジュール情報は、ROUTEセッションで伝送されるスタートアップパッケージファイルに同梱されるアプリケーションマニフェストファイルに含まれ、
　前記転送制御情報は、ROUTEプロトコルの制御情報であるS-TSIDにより特定される、ROUTEセッションで伝送されるEFDTに含まれる
　（１６）又は（１７）に記載の送信装置。
（１９）
　送信装置のデータ処理方法において、
　前記送信装置が、
　コンテンツに付随するアプリケーションの一部である１又は複数のリソースファイルの配信に関するリソース配信情報を生成し、
　前記コンテンツとともに、前記リソース配信情報を送信する
　ステップを含むデータ処理方法。
　１　伝送システム，　１０　送信側システム，　２０　クライアント装置，　８０　伝送路，　９０　インターネット，　１０１　DASHサーバ，　１０２　シグナリングサーバ，　１０３　アプリケーションサーバ，　１０４　SCH/PKGサーバ，　１０５　放送サーバ，　１０６　通信サーバ，　２０１　処理部２０１，　２０２　入力部，　２０３　メモリ，　２０４　受信部，　２０５　放送ミドルウェア，　２０６　DASHクライアント，　２０７　デコーダ，　２０８　出力部，　２０９　ブラウザ，　２１０　通信部，　２１１　制御部，　２１２　プロキシサーバ，　２１３　レンダラ，　１０００　コンピュータ，　１００１　CPU

Claims (19)

  1. 　コンテンツを受信する受信部と、
    　前記コンテンツとともに伝送される、前記コンテンツに付随するアプリケーションの一部である１又は複数のリソースファイルの配信に関するリソース配信情報を取得する取得部と、
    　取得された前記リソース配信情報に基づいて、前記リソースファイルの配信に応じた処理を行う処理部と
    　を備える受信装置。
  2. 　前記リソース配信情報は、前記リソースファイルごとの配信スケジュールに関する配信スケジュール情報を含んでいる
    　請求項１に記載の受信装置。
  3. 　前記配信スケジュール情報は、前記リソースファイルごとの取得先を示す情報、並びに前記リソースファイルごとのサイズ及び配信時刻の少なくとも一方に関する情報を含んでいる
    　請求項２に記載の受信装置。
  4. 　前記リソース配信情報は、時間帯に応じて配信スケジュールが変更される可能性のある特定のリソースファイルの配信に関する転送制御情報を含んでいる
    　請求項２に記載の受信装置。
  5. 　前記転送制御情報は、前記特定のリソースファイルの再送周期及び再送終了時刻の少なくとも一方に関する情報を含んでいる
    　請求項４に記載の受信装置。
  6. 　前記コンテンツのビデオとオーディオのデータは、ストリーミングファイル転送用のプロトコルであるROUTE(Real-time Object Delivery over Unidirectional Transport)セッションで伝送され、
    　前記配信スケジュール情報は、ROUTEセッションで伝送されるスタートアップパッケージファイルに同梱されるアプリケーションマニフェストファイルに含まれ、
    　前記転送制御情報は、ROUTEプロトコルの制御情報であるS-TSID(Service-based Transport Session Instance Description)により特定される、ROUTEセッションで伝送されるEFDT(Extended FDT)に含まれる
    　請求項４に記載の受信装置。
  7. 　受信装置のデータ処理方法において、
    　前記受信装置が、
    　コンテンツとともに伝送される、前記コンテンツに付随するアプリケーションの一部である１又は複数のリソースファイルの配信に関するリソース配信情報を取得し、
    　取得された前記リソース配信情報に基づいて、前記リソースファイルの配信に応じた処理を行う
    　ステップを含むデータ処理方法。
  8. 　前記リソース配信情報は、前記リソースファイルごとの配信スケジュールに関する配信スケジュール情報を含んでいる
    　請求項７に記載のデータ処理方法。
  9. 　前記配信スケジュール情報は、前記リソースファイルごとの取得先を示す情報、並びに前記リソースファイルごとのサイズ及び配信時刻の少なくとも一方に関する情報を含んでいる
    　請求項８に記載のデータ処理方法。
  10. 　前記リソース配信情報は、時間帯に応じて配信スケジュールが変更される可能性のある特定のリソースファイルの配信に関する転送制御情報を含んでいる
    　請求項８に記載のデータ処理方法。
  11. 　前記転送制御情報は、前記特定のリソースファイルの再送周期及び再送終了時刻の少なくとも一方に関する情報を含んでいる
    　請求項１０に記載のデータ処理方法。
  12. 　前記コンテンツのビデオとオーディオのデータは、ストリーミングファイル転送用のプロトコルであるROUTEセッションで伝送され、
    　前記配信スケジュール情報は、ROUTEセッションで伝送されるスタートアップパッケージファイルに同梱されるアプリケーションマニフェストファイルに含まれ、
    　前記転送制御情報は、ROUTEプロトコルの制御情報であるS-TSIDにより特定される、ROUTEセッションで伝送されるEFDTに含まれる
    　請求項１０に記載のデータ処理方法。
  13. 　コンテンツに付随するアプリケーションの一部である１又は複数のリソースファイルの配信に関するリソース配信情報を生成する生成部と、
    　前記コンテンツとともに、前記リソース配信情報を送信する送信部と
    　を備える送信装置。
  14. 　前記リソース配信情報は、前記リソースファイルごとの配信スケジュールに関する配信スケジュール情報を含んでいる
    　請求項１３に記載の送信装置。
  15. 　前記配信スケジュール情報は、前記リソースファイルごとの取得先を示す情報、並びに前記リソースファイルごとのサイズ及び配信時刻の少なくとも一方に関する情報を含んでいる
    　請求項１４に記載の送信装置。
  16. 　前記リソース配信情報は、時間帯に応じて配信スケジュールが変更される可能性のある特定のリソースファイルの配信に関する転送制御情報を含んでいる
    　請求項１４に記載の送信装置。
  17. 　前記転送制御情報は、前記特定のリソースファイルの再送周期及び再送終了時刻の少なくとも一方に関する情報を含んでいる
    　請求項１６に記載の送信装置。
  18. 　前記コンテンツのビデオとオーディオのデータは、ストリーミングファイル転送用のプロトコルであるROUTEセッションで伝送され、
    　前記配信スケジュール情報は、ROUTEセッションで伝送されるスタートアップパッケージファイルに同梱されるアプリケーションマニフェストファイルに含まれ、
    　前記転送制御情報は、ROUTEプロトコルの制御情報であるS-TSIDにより特定される、ROUTEセッションで伝送されるEFDTに含まれる
    　請求項１６に記載の送信装置。
  19. 　送信装置のデータ処理方法において、
    　前記送信装置が、
    　コンテンツに付随するアプリケーションの一部である１又は複数のリソースファイルの配信に関するリソース配信情報を生成し、
    　前記コンテンツとともに、前記リソース配信情報を送信する
    　ステップを含むデータ処理方法。
PCT/JP2017/003531 2016-02-15 2017-02-01 受信装置、送信装置、及び、データ処理方法 WO2017141701A1 (ja)

Priority Applications (5)

Application Number Priority Date Filing Date Title
US16/076,189 US11336957B2 (en) 2016-02-15 2017-02-01 Reception apparatus, transmission apparatus, and data processing method
KR1020187021835A KR102656879B1 (ko) 2016-02-15 2017-02-01 수신 장치, 송신 장치 및 데이터 처리 방법
JP2018500024A JPWO2017141701A1 (ja) 2016-02-15 2017-02-01 受信装置、送信装置、及び、データ処理方法
MX2018009625A MX2018009625A (es) 2016-02-15 2017-02-01 Aparato de recepcion, aparato de transmision y metodo de procesamiento de datos.
CA3013426A CA3013426A1 (en) 2016-02-15 2017-02-01 Reception apparatus, trasmission apparatus, and data processing method

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2016026420 2016-02-15
JP2016-026420 2016-02-15

Publications (1)

Publication Number Publication Date
WO2017141701A1 true WO2017141701A1 (ja) 2017-08-24

Family

ID=59625054

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2017/003531 WO2017141701A1 (ja) 2016-02-15 2017-02-01 受信装置、送信装置、及び、データ処理方法

Country Status (6)

Country Link
US (1) US11336957B2 (ja)
JP (1) JPWO2017141701A1 (ja)
KR (1) KR102656879B1 (ja)
CA (1) CA3013426A1 (ja)
MX (2) MX2018009625A (ja)
WO (1) WO2017141701A1 (ja)

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2016182371A1 (ko) * 2015-05-12 2016-11-17 엘지전자 주식회사 방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호 송신 방법, 및 방송 신호 수신 방법
US11202314B2 (en) * 2019-06-18 2021-12-14 Sony Group Corporation Immediate retransmission scheme for real time applications
US11464054B2 (en) 2019-07-24 2022-10-04 Sony Group Corporation RTA contention collision avoidance
JP2022084136A (ja) * 2020-11-26 2022-06-07 株式会社東海理化電機製作所 無線通信装置、システムおよびプログラム

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2000031921A (ja) * 1998-05-07 2000-01-28 Matsushita Electric Ind Co Ltd 放送局システム及び受信機
JP2015529988A (ja) * 2012-06-25 2015-10-08 エルジー エレクトロニクス インコーポレイティド 対話型サービスを処理する装置及び方法

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9380096B2 (en) * 2006-06-09 2016-06-28 Qualcomm Incorporated Enhanced block-request streaming system for handling low-latency streaming
JP2011254410A (ja) * 2010-06-04 2011-12-15 Ntt Docomo Inc 放送コンテンツ送信装置及び放送コンテンツ受信装置
US9026671B2 (en) * 2011-04-05 2015-05-05 Qualcomm Incorporated IP broadcast streaming services distribution using file delivery methods
CA2838471C (en) 2012-05-10 2020-08-18 Sony Corporation Receiving apparatus, reception method, transmitting apparatus, transmission method, and program
JPWO2016017451A1 (ja) * 2014-08-01 2017-05-18 ソニー株式会社 受信装置、受信方法、送信装置、及び、送信方法
US20160164943A1 (en) * 2014-12-05 2016-06-09 Qualcomm Incorporated Transport interface for multimedia and file transport
US10129308B2 (en) * 2015-01-08 2018-11-13 Qualcomm Incorporated Session description information for over-the-air broadcast media data

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2000031921A (ja) * 1998-05-07 2000-01-28 Matsushita Electric Ind Co Ltd 放送局システム及び受信機
JP2015529988A (ja) * 2012-06-25 2015-10-08 エルジー エレクトロニクス インコーポレイティド 対話型サービスを処理する装置及び方法

Also Published As

Publication number Publication date
JPWO2017141701A1 (ja) 2018-12-13
MX2018009625A (es) 2018-09-11
US20200053427A1 (en) 2020-02-13
KR102656879B1 (ko) 2024-04-16
CA3013426A1 (en) 2017-08-24
KR20180113514A (ko) 2018-10-16
MX2022015427A (es) 2023-01-11
US11336957B2 (en) 2022-05-17

Similar Documents

Publication Publication Date Title
US11632578B2 (en) Apparatus and method for configuring control message in broadcasting system
US11575961B2 (en) Reception apparatus, transmission apparatus, and data processing method
US9043849B2 (en) Method for linking MMT media and DASH media
WO2012099423A2 (ko) 방송 시스템에서의 제어 메시지 구성 장치 및 방법
WO2017141701A1 (ja) 受信装置、送信装置、及び、データ処理方法
CN107534793B (zh) 接收装置、传输装置以及数据处理方法
WO2018079295A1 (ja) 情報処理装置、及び、情報処理方法
US11374670B2 (en) Receiving device, transmitting device, and data processing method
US10567098B2 (en) Reception apparatus, transmission apparatus, and data processing method
US11418273B2 (en) Reception device, transmission device, and data processing method
WO2018021015A1 (ja) 受信装置、送信装置、及び、データ処理方法
WO2016174959A1 (ja) 受信装置、送信装置、およびデータ処理方法

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 17752964

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 2018500024

Country of ref document: JP

WWE Wipo information: entry into national phase

Ref document number: 3013426

Country of ref document: CA

WWE Wipo information: entry into national phase

Ref document number: MX/A/2018/009625

Country of ref document: MX

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 17752964

Country of ref document: EP

Kind code of ref document: A1