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

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

Info

Publication number
WO2017090457A1
WO2017090457A1 PCT/JP2016/083467 JP2016083467W WO2017090457A1 WO 2017090457 A1 WO2017090457 A1 WO 2017090457A1 JP 2016083467 W JP2016083467 W JP 2016083467W WO 2017090457 A1 WO2017090457 A1 WO 2017090457A1
Authority
WO
WIPO (PCT)
Prior art keywords
resource
content
signaling
service
cache
Prior art date
Application number
PCT/JP2016/083467
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
Priority to CA3003683A priority Critical patent/CA3003683A1/en
Priority to KR1020187013711A priority patent/KR102637023B1/ko
Priority to US15/766,850 priority patent/US10986397B2/en
Priority to KR1020247004799A priority patent/KR20240025698A/ko
Priority to AU2016360190A priority patent/AU2016360190A1/en
Priority to JP2017552356A priority patent/JPWO2017090457A1/ja
Application filed by ソニー株式会社 filed Critical ソニー株式会社
Priority to MX2018006174A priority patent/MX2018006174A/es
Priority to CN201680067759.9A priority patent/CN108293148B/zh
Priority to EP16868405.8A priority patent/EP3383054B1/en
Publication of WO2017090457A1 publication Critical patent/WO2017090457A1/ja
Priority to US17/189,827 priority patent/US11575961B2/en
Priority to AU2021202436A priority patent/AU2021202436B2/en

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/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/433—Content storage operation, e.g. storage operation in response to a pause request, caching 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/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/434—Disassembling of a multiplex stream, e.g. demultiplexing audio and video streams, extraction of additional data from a video stream; Remultiplexing of multiplex streams; Extraction or processing of SI; Disassembling of packetised elementary stream
    • H04N21/4348—Demultiplexing of additional data and video streams
    • 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]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F13/00—Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
    • 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/27—Arrangements for recording or accumulating broadcast information or broadcast-related information
    • 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/23614—Multiplexing of additional data and video streams
    • 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/433—Content storage operation, e.g. storage operation in response to a pause request, caching operations
    • H04N21/4331—Caching operations, e.g. of an advertisement for later insertion during playback
    • 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/434—Disassembling of a multiplex stream, e.g. demultiplexing audio and video streams, extraction of additional data from a video stream; Remultiplexing of multiplex streams; Extraction or processing of SI; Disassembling of packetised elementary 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/434—Disassembling of a multiplex stream, e.g. demultiplexing audio and video streams, extraction of additional data from a video stream; Remultiplexing of multiplex streams; Extraction or processing of SI; Disassembling of packetised elementary stream
    • H04N21/4345—Extraction or processing of SI, e.g. extracting service information from an MPEG 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/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/61—Network physical structure; Signal processing
    • H04N21/6106—Network physical structure; Signal processing specially adapted to the downstream path of the transmission network
    • H04N21/6112—Network physical structure; Signal processing specially adapted to the downstream path of the transmission network involving terrestrial transmission, e.g. DVB-T
    • 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/61—Network physical structure; Signal processing
    • H04N21/6106—Network physical structure; Signal processing specially adapted to the downstream path of the transmission network
    • H04N21/6125—Network physical structure; Signal processing specially adapted to the downstream path of the transmission network involving transmission via 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/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/64322—IP
    • 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/65—Transmission of management data between client and server
    • H04N21/654—Transmission by server directed to the client
    • H04N21/6543—Transmission by server directed to the client for forcing some client operations, e.g. recording
    • 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/812—Monomedia components thereof involving advertisement data
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/81—Monomedia components thereof
    • H04N21/8166—Monomedia components thereof involving executable data, e.g. software
    • H04N21/8173—End-user applications, e.g. Web browser, game
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/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

Definitions

  • the present technology relates to a receiving device, a transmitting device, and a data processing method, and particularly to a receiving device, a transmitting device, and a data processing method that can share resources that are reused in a plurality of services.
  • ATSC Advanced Television Systems Systems Committee
  • a file system such as On Memory or SSD (Solid State Drive) or a special database is used.
  • Files in these local caches are kept in the cache for a limited period of time and then deleted based on the HTTP (Hypertext Transfer Protocol) header cache control header (Cache Control Header) parameters attached to the file.
  • HTTP Hypertext Transfer Protocol
  • cache Control Header cache Control Header
  • entity mode which is a kind of distribution mode of the ROUTE (Real-time Object-Delivery-over-Unidirectional Transport) protocol, is used.
  • Patent Document 1 a technique for realizing data distribution via broadcasting or communication.
  • This technology has been made in view of such a situation, and enables a resource reused in a plurality of services to be shared.
  • the receiving device is a receiving unit that receives content and control information transmitted together with the content, and whether or not the resource of the content is a resource shared by a plurality of services
  • a control unit that controls storage of the resource in the storage device so that the resource of the content is shared by a plurality of services based on the control information including resource sharing information indicating .
  • 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.
  • control information transmitted together with the content is received, and the resource of the content is shared by a plurality of services
  • the storage of the resource in the storage device is controlled so that the resource of the content is shared by a plurality of services.
  • the transmission device includes: a generation unit that generates control information including resource sharing information indicating whether a resource of content is a resource shared by a plurality of services; And a transmission unit that transmits control information.
  • 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.
  • control information including resource sharing information indicating whether a resource of content is a resource shared by a plurality of services is generated,
  • the control information is transmitted together with the content.
  • resources that are reused in a plurality of services can be shared.
  • FIG. 1 It is a figure showing the composition of the 1 embodiment of the transmission system to which this art is applied. It is a figure which shows the example of the protocol stack of the IP transmission system of this technique. It is a figure which shows the structure of ROUTE / FLUTE. It is a figure which shows the detailed structure of ROUTE. It is a figure which shows the outline
  • FIG. 1 is a diagram illustrating a configuration 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 an Ad / DASH server 10, a broadcast server 20, a communication server 30, and a client device 40.
  • the Ad / DASH server 10 is a server for performing a delivery 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 Ad / DASH server 10 generates a file of a program content segment (hereinafter also referred to as a DASH segment) or an advertisement content segment (hereinafter also referred to as an Ad segment), and transmits the file to the broadcast server 20 or the communication server 30. To do. Further, the Ad / DASH server 10 generates MPD metadata and transmits it to the broadcast server 20 or the communication server 30.
  • a DASH segment program content segment
  • Ad segment advertisement content segment
  • the Ad / DASH server 10 generates an application and transmits it to the broadcast server 20 or the communication server 30.
  • a script application capable of executing a script (Script) is included.
  • the script application may be an application developed in a markup language such as HTML5 (HyperTextperMarkup Language 5) or a script language such as JavaScript (registered trademark).
  • the broadcast server 20 is a transmitter capable of performing data transmission conforming to digital broadcasting standards such as ATSC 3.0.
  • the broadcast server 20 processes the DASH segment, Ad segment, MPD metadata, and application files transmitted from the Ad / DASH server 10 and transmits them via the transmission path 80 (simultaneous broadcast distribution) together with signaling.
  • NRT content is input to the broadcast server 20.
  • the NRT content is content transmitted by NRT (Non Real Time) broadcasting, and is reproduced after being once stored in the storage of the client device 40.
  • the broadcast server 20 processes the NRT content file input thereto, and transmits (broadcast broadcast) via the transmission path 80.
  • the communication server 30 is a server that provides various data via the Internet 90 in response to a request from the client device 40 connected to the Internet 90.
  • the communication server 30 processes the DASH segment, Ad segment, MPD metadata, and application file transmitted from the Ad / DASH server 10.
  • the communication server 30 transmits various files via the Internet 90 in response to a request from the client device 40.
  • the client device 40 is a receiver that can receive transmission data compliant with digital broadcasting standards such as ATSC 3.0.
  • the client device 40 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 40 may be a device mounted on an automobile such as an in-vehicle television.
  • the client device 40 receives and processes files such as DASH segment, Ad segment, signaling, MPD metadata, application, and NRT content transmitted (broadcast delivery) from the broadcast server 20 via the transmission path 80. By doing so, video and audio of content such as broadcast programs and advertisements are output.
  • files such as DASH segment, Ad segment, signaling, MPD metadata, application, and NRT content transmitted (broadcast delivery) from the broadcast server 20 via the transmission path 80.
  • the client device 40 can access the communication server 30 via the Internet 90 and acquire various files.
  • the client device 40 receives and processes a file such as a DASH segment, an Ad segment, and MPD metadata that is transmitted (adaptive streaming delivery) from the communication server 30 via the Internet 90, thereby processing VOD ( Video (On Demand) Outputs video and audio for content such as programs and advertisements.
  • VOD Video (On Demand) Outputs video and audio for content such as programs and advertisements.
  • 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
  • ATSC 3.0 is the next generation broadcasting standard in the United States that is currently being developed.
  • ATSC 3.0 instead of the currently widely used MPEG2-TS (Transport Stream) method, the IP transmission method that uses IP (Internet Protocol) packets used in the field of communication for digital broadcasting is used. By introducing it, it is expected to provide more advanced services.
  • MPEG2-TS Transport Stream
  • IP Internet Protocol
  • FIG. 2 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.
  • IP transmission system such as ATSC3.0
  • 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 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 that corresponds to the transport layer in the communication layer model, and the upper layer is ROUTE (Real-time Object Delivery Service Unidirectional Transport) or MMTP. (MPEG-Media-Transport-Protocol).
  • SLT metadata is stored and transmitted in the upper layer of the UDP layer, that is, the IP packet including the UDP packet.
  • the SLS metadata is LLS (Link Layer Signaling) signaling including basic information indicating a stream and a service configuration in a broadcast network, such as information necessary for channel selection (channel selection information). Note that the LLS signaling is signaling acquired prior to SLS (Service Layer Signaling) signaling, and the SLS signaling is acquired according to information included in the LLS signaling.
  • LLS Link Layer Signaling
  • ROUTE is a protocol for transferring streaming files and extends FLUTE (FileFLDelivery over Unidirectional Transport). The detailed contents of ROUTE will be described later with reference to FIGS.
  • SLS Session Specific signaling
  • metadata such as USBD (User Service Bundle Description), S-TSID (Service-based Transport Session Instance Description), MPD (Media Presentation Description), AST (Application Signaling Table), etc. Is included.
  • S-TSID metadata is an extension of LSID (LCT Session Instance Description) for ATSC 3.0, and is ROUTE protocol control information.
  • LSID LCT Session Instance Description
  • MPD metadata is management information of a moving image or audio file that is streamed.
  • AST is application control information.
  • the NRT content is an example of content transmitted in the ROUTE session.
  • content such as an application or an electronic service guide (ESG) may be transmitted in the ROUTE session.
  • ESG electronic service guide
  • the upper layer adjacent to the DASH segment is a DASH player / decoder.
  • the stream data of service components video, audio, subtitles, etc.
  • ISO BMFF ISO Base Media File Format
  • MMTP is a protocol for transferring streaming files.
  • some layers are set to signaling (MMTP (specific Signaling).
  • This signaling includes, for example, metadata such as USBD (User Service Bundle Description) and MPT (MMT Package Table).
  • the layer other than signaling is MPU (Media Processing Unit) (ISO BMFF).
  • MPU Media Processing Unit
  • the upper layer adjacent to the MPU is a DASH player / decoder.
  • the stream data of service components video, audio, subtitles, etc.
  • ISO BMFF ISO Base Media File Format
  • the upper layer of the physical 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
  • NRT content NRT Files
  • This signaling includes all signaling such as signaling transmitted by the above-described ROUTE and MMTP.
  • the NRT content is an example of content acquired via communication, and for example, content such as an application may be transmitted.
  • the layers other than the layers described above are DASH segments (ISO BMFF), and the upper layers adjacent to this DASH segment (ISO BMFF) are the DASH player / decoder. Is done.
  • the stream data of service components video, audio, subtitles, etc.
  • the stream data of service components that make up content such as VOD programs must be transmitted in DASH segment units according to the ISO BMFF standard. become.
  • Applications can be transmitted by using protocols such as ROUTE and MMTP for one-way broadcasting and TCP / IP protocol for two-way communication.
  • this application can be an application developed by HTML5, JS (JavaScript (registered trademark)), or the like.
  • the HTTP proxy (HTTP ⁇ Proxy) is described as part of ROUTE, which is implemented in the client device 40 when a DASH segment (ISO BMFF) file is acquired by an application.
  • DASH segment ISO BMFF
  • the broadcast middleware is supposed to be implemented as an HTTP server.
  • EME / CENC Encrypted Media Extension-/ Common Encryption Scheme
  • W3C World Wide Web Consortium
  • MPEG Motion Picture Experts Group
  • EME / CENC is described in part of DASH segment (ISO ⁇ ⁇ ⁇ ⁇ BMFF) and MPU (ISO BMFF).
  • SLT metadata as LLS signaling and metadata such as USBD, S-TSID, MPD, and AST as SLS signaling are described in a markup language such as XML (Extensible Markup Language).
  • 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, in the case of performing both one-way broadcast streaming distribution and two-way communication streaming distribution, the higher-layer protocol is shared. For example, in the broadcast server 20 and the client device 40, Mounting burden and processing burden can be reduced.
  • FIG. 3 shows the structure of ROUTE. However, FIG. 3 also describes FLUTE for comparison with ROUTE.
  • FLUTE is composed of a scalable file object multicast protocol called ALC (Asynchronous Layered Coding), specifically a combination of its building blocks, LCT (Layered Coding Transport) and FEC (Forward Error Correction) components.
  • ALC Asynchronous Layered Coding
  • LCT Layered Coding Transport
  • FEC Forward Error Correction
  • ALC is a protocol suitable for multicast transmission of arbitrary binary files in one direction.
  • ALC was developed as a highly reliable asynchronous one-to-many broadcast type protocol, but uses LCT and FEC, and applies the FEC to the target file and stores it in the LCT packet.
  • LCT low-density convergence protocol
  • FEC FEC-Fi Protected Access
  • a transport session in FLUTE is identified by a unique TSI (Transport Session Identifier) in the scope of the source IP address.
  • TSI Transaction Session Identifier
  • the FEC method can be changed for each transport session or for each file.
  • FLUTE has introduced transfer control information in XML format called FDT (File Delivery Table) transferred for each transport session.
  • the FDT defines the mapping between the identifier of the target file and the LCT packet sequence that stores the corresponding FEC encoding symbol sequence. Furthermore, the MIME type and size of each file, the transfer encoding method, the message digest, and the FEC Parameters necessary for decoding can be stored. Note that FEC can also be applied to the FDT itself, and its own FEC parameters and the like are transmitted separately in the LCT layer.
  • ROUTE is an extension of FLUTE, but the difference can mainly include object bundles and media-aware fragmentation.
  • FIG. 4 shows the detailed structure of ROUTE.
  • the feature of object bundle in ROUTE is that a stream of video and audio consisting of source blocks of different sizes is bundled and configured as one super object, and an FEC repair stream is generated based on that, a source stream, It is in the place of supporting the repair stream related notification at the protocol level.
  • an audio stream or the like has a small source object size compared to a video stream because the data amount per unit time (data object) is small.
  • data object data amount per unit time
  • a source block is cut out from a plurality of source streams with different rates to form a super object, and a repair stream can be configured by FEC repair symbols generated based on the super object. That is, a repair stream is generated across different types of source streams.
  • a source stream composed of source symbols, a repair stream composed of repair symbols, and another LCT session in the ROUTE session can be transferred.
  • control information on how to create a FEC stream from a source block cut out from multiple source streams is described in S-TSID metadata that extends LSID (FDT) Is done.
  • S-TSID metadata that extends LSID (FDT) Is done.
  • a broadcast stream is a model in which all the streams constituting a service are multiplexed and transmitted on the transmitter side, and streams necessary for the broadcast stream are selected on the receiver side. Therefore, it is possible to apply a processing model in which a super-object consisting of all the streams constituting the service is configured on the transmitter side, the super-object is restored on the receiver side, and then the necessary streams are selected.
  • the FEC configuration method realized by ROUTE is effective.
  • the client device 40 in order to improve the performance of access to an application associated with a specific service such as a broadcast program, it is necessary to cache a necessary file in a local cache in advance.
  • a model is assumed in which every file acquired via broadcast or communication is temporarily stored in a local cache on a local file system in the client device 40 and provided to a stream renderer or application. Has been.
  • the client device 40 cannot cache all receivable broadcast wave files due to limitations of tuners and storage resources, only the file group necessary for the currently selected service is stored.
  • the service channel
  • an operation of immediately releasing the storage resource is assumed.
  • FIG. 5 is a diagram showing an outline of a cache quota domain.
  • the cache quota domain is a domain (group) for sharing resources to be reused.
  • FIG. 5 illustrates a case where service A, service B, and service C belong to the quota domain 1, and service X and service Y belong to the quota domain 2. Note that the storage area of the local cache in FIG. 5 corresponds to a permanent cache 404B of the local cache 404 in FIG.
  • files such as applications and DASH segments shared by the services A to C belonging to the quota domain 1 are cached in a storage area allocated to the quota domain 1 of the local cache. That is, since the file shared by the service belonging to the quota domain 1 is cached in the storage area of the local cache identified by the quota domain 1 (the quota domain identifier thereof), in the service belonging to the quota domain 1, the storage area Files can be acquired and processed (played back).
  • files shared by the services X and Y belonging to the quota domain 2 and files such as DASH segments and period files are cached in a storage area allocated to the quota domain 2 of the local cache. That is, since the file shared by the service belonging to the quota domain 2 is cached in the storage area of the local cache identified by the quota domain 2 (the quota domain identifier thereof), the storage area of the service belonging to the quota domain 2 Files can be acquired and processed (played back).
  • each service cannot access resources of other quota domains across the quota domain to which it belongs. For example, services A to C belonging to the quota domain 1 cannot access the resources of the quota domain 2, and services X and Y belonging to the quota domain 2 cannot access the resources of the quota domain 1.
  • a service belonging to each quota domain can share (use) resources within the quota domain to which it belongs.
  • a plurality of services provided by a single broadcasting station or a plurality of services provided by a federation of broadcasting stations organized by a plurality of broadcasting stations belong to the same cash quota domain, so that For each domain, multiple services share resources (files).
  • FIG. 6 is a diagram illustrating an arrangement example of quota domain identifiers.
  • the quota domain identifier for identifying the cache quota domain can be transmitted by signaling transmitted in each layer of the broadcast wave. That is, in the signaling, by adding an attribute (or element) that can specify the quota domain identifier of the cache quota domain to which the target service belongs, the client device 40 can perform the same operation based on the quota domain identifier included in the signaling. Resources (files) can be shared by services belonging to the cache quota domain.
  • the quota domain identifier is SLS metadata that is LLS signaling stored in the payload of the IP / UDP packet or SLS transmitted in the LCT session that is stored in the payload of the IP / UDP packet.
  • SLS metadata LLS signaling stored in the payload of the IP / UDP packet or SLS transmitted in the LCT session that is stored in the payload of the IP / UDP packet.
  • the SLT metadata can specify attributes of multiple services.
  • an attribute an attribute (or element) that can specify a quota domain identifier is added.
  • the quotaDomain attribute in the service element of the SLT metadata it becomes possible to specify the quota domain identifier of the cache quota domain to which the target service belongs.
  • the SLT metadata specifies the quota domain identifier of the quota domain 1 (FIG. 5) as the quotaDomain attribute of the service element in which the service IDs of the services A to C are specified. So that In the SLT metadata, the quota domain identifier of the quota domain 2 (FIG. 5) is designated as the quotaDomain attribute of the service element in which the service IDs of the services X and Y are designated.
  • the target service is defined by defining the quotaDomain attribute in the USD element of the USBD metadata. It is possible to specify the quota domain identifier of the cache quota domain to which it belongs.
  • the quota domain identifier of the quota domain 1 (FIG. 5) is specified as the quotaDomain attribute of the USD element in the USBD metadata of the services A to C.
  • the quota domain identifier of the quota domain 2 (FIG. 5) is specified as the quotaDomain attribute of the USD element.
  • SLT metadata As described above, by expanding SLT metadata, USBD metadata, S-TSID metadata, or AST metadata and specifying a quota domain identifier, service units, LCTs can be created within the same cache quota domain.
  • Resources Files
  • each service is composed of one or a plurality of LCT sessions, and in each LCT session, for example, a DASH segment, an application file, an arbitrary file, and the like are transmitted.
  • the service entry (basic attribute for each service) of SLT metadata is extended, or the attribute for each service of USBD metadata.
  • a quotaDomain attribute For a file transmitted by the target service, a quota domain identifier for identifying a storage area of a local cache in which the file is stored is designated by a quotaDomain attribute of SLT metadata or USBD metadata. It corresponds to a character string.
  • the file in this case is, for example, a file such as a DASH segment, a period file, or an application, and includes not only a file acquired via broadcasting but also a file acquired via communication.
  • a cache quota domain for example, quota domain 1
  • quota domain 1 a cache quota domain 1
  • all files transmitted in the LCT session belonging to the target service When the cache is instructed to be cached in the local cache (permanent cache thereof), all files are cached in the storage area allocated to the cache quota domain (eg, quota domain 1) of the local cache (see FIG. 8 A (B)).
  • SLS signaling location information is specified in the service element of the SLT metadata.
  • This location information is specified by the BroadcastSvcSignaling element when SLS signaling is acquired via broadcasting, and is specified by the SvcInetUrl element when SLS signaling is acquired via communication.
  • the USBD metadata is acquired via broadcast or communication according to the location information of the service element of SLT metadata.
  • the attributes for each LCT session in the S-TSID metadata are extended and the quotaDomain attribute is defined. That is, for the files transmitted in the target LCT session, the quota domain identifier for identifying the storage area of the local cache where these files are stored is the character specified by the quotaDomain attribute of the S-TSID metadata. It corresponds to a column.
  • the file in this case is, for example, a file such as a DASH segment, a period file, or an application.
  • a cache quota domain for example, quota domain 1
  • the service to which the target LCT session belongs is changed to the cache quota domain (for example, It is recognized that it belongs to the quota domain 1).
  • the files are It is cached in the storage area of the cache quota domain (for example, quota domain 1) of the cache (C1 in FIG. 8).
  • the LCT session belongs to the same service as the LCT session for which the cache quota domain (for example, quota domain 1) is specified, the LCT session for which the cache quota domain (for example, quota domain 1) is not specified Is excluded from the target of the persistent cache (C2 in FIG. 8).
  • the STSIDUri attribute of the USD element of the USBD metadata contains a URI (Uniform Resource Identifier) indicating the acquisition source of the S-TSID metadata. It is specified. And according to this URI, S-TSID metadata is acquired.
  • URI Uniform Resource Identifier
  • the attribute for each application of the AST metadata is extended and the quotaDomain attribute is defined.
  • the quota domain identifier for identifying the storage area of the local cache where the application file to be described in the target AST metadata is stored corresponds to the character string specified by the quotaDomain attribute of the AST metadata. become.
  • a cache quota domain for example, quota domain 1
  • the service to which the target application belongs is assigned to the cache quota domain (for example, quota domain 1). Is recognized as belonging to.
  • the files of the application for which the cache quota domain (for example, quota domain 1) is designated in the local cache (permanent cache thereof)
  • the files are stored in the cache quota of the local cache. It is cached in a storage area of a domain (for example, quota domain 1) (D in FIG. 8).
  • a domain for example, quota domain 1
  • the application for which the cache quota domain (for example, quota domain 1) is not specified is persistent. Not eligible for caching.
  • the concept of the cache quota domain is introduced, and the quota domain identifier (resource sharing information) that identifies the cache quota domain is included in metadata (control information) such as SLT, USBD, S-TSID, and AST.
  • metadata control information
  • the files (resources) included in the service belonging to the same cache quota domain are held in the local cache (permanent cache), and are transmitted in units of services, units of LCT sessions, or applications. It becomes possible to share by unit.
  • FIGS. 9 to 14 a case where a cache quota domain is implemented in a system that inserts second content (advertisement) by an application transmitted together with first content (broadcast program). explain. Since the application performs advertisement insertion control (Ad-Insertion) by executing a script (Script), the application is hereinafter referred to as a script application (Script ⁇ App).
  • a script application Script ⁇ App
  • FIG. 9 is a diagram for explaining the flow of advertisement insertion.
  • FIG. 9 shows an example in which an advertisement (TV2_Ad) suitable for the user is inserted in the client device 40 instead of the default advertisement (TV1_Ad) reproduced during the broadcast program (BP1, BP2). ing.
  • TV2_Ad an advertisement suitable for the user is inserted in the client device 40 instead of the default advertisement (TV1_Ad) reproduced during the broadcast program (BP1, BP2). ing.
  • time t2 to time t2 between time t1 to time t2 at which the broadcast program BP1 is reproduced and time t3 to time t4 at which the broadcast program BP2 is reproduced.
  • the advertisement Ad1 that is acquired in real time is usually played back.
  • the advertisement Ad2 is displayed when the broadcast program BP1-1 is played from time t1 to time t2. That is, it is acquired via broadcasting or communication before the advertisement insertion interval and cached in a local cache (permanent cache).
  • the client device 40 when the scene of the broadcast program BP1-2 is reached, a question for the user is superimposed on the video. And the client apparatus 40 displays the advertisement suitable for the said user according to the user's answer with respect to a question. For example, in the client device 40, when the user answers the question, the advertisement Ad2 for insertion corresponding to the answer is read from the local cache (permanent cache thereof), and the default advertisement Ad1 is It will be replaced with the advertisement Ad2 suitable for the user.
  • an advertisement that is likely to be viewed by the user is cached in the local cache (permanent cache) of the client device 40, and the advertisement adapted to the user is used using the cached advertisement. Can be displayed.
  • advertisement insertion in FIG. 9 an example in which the content of an advertisement suitable for the user is selected in accordance with the input operation of the user is shown.
  • information exchange with such a user In addition to the interaction, for example, the user can select the content of the advertisement by using information on the user's preset characteristics such as the user's preference and profile (for example, gender, age, residential area, etc.) Also good.
  • a file including a Period element corresponding to an advertisement insertion section of MPD metadata is prepared in advance, and a Period element that specifies a segment corresponding to a stream of advertisement content is set to a user characteristic (for example, , A system that dynamically changes according to user preferences, etc.).
  • a client device 40 corresponding to such advertisement insertion control is shown in FIG.
  • the client device 40 has an application / codec function, a DASH client function, and a transport stack / HTTP server function.
  • the transport stack / HTTP server function includes an XLink resolver (XLink Resolver) and an HTTP proxy cache (HTTP Proxy Cache).
  • XLink Resolver XLink Resolver
  • HTTP Proxy Cache HTTP Proxy Cache
  • the HTTP server of the communication server 30 may have the function of the XLink resolver.
  • the MPD metadata transmitted as SLS signaling is received in the client device 40
  • the MPD metadata is acquired by the HTTP proxy cache and notified to the DASH client (S51).
  • a URL Uniform Resource Locator
  • XLink resolver operating on the HTTP server of the client device 40 or the communication server 30
  • A1 (Ad Break # 1), M1 (Main Program), A2 (Ad Break # 2), M2 (Main Program) which are Period elements described in the MPD metadata , A3 (Ad Break # 3), M3 (Main Program) If you focus on the Period element that is A1 (Ad Break # 1), the URL of the xlink: href attribute is "http://adservice.com/ adp-1? user $ groupID $ "is described.
  • A2 AdBreak # 2
  • A3 Ad Break ⁇ # 3
  • the XLink resolver of the client device 40 or the communication server 30 is generated for a specific user (for example, a user of class A) specified by the groupID when the URL in which the groupID value is inserted is notified from the DASH client.
  • a Period element file including the URL (hereinafter referred to as a period file) is returned to the DASH client (S53).
  • the URL included in the Period element is a segment URL (segment URL) distributed by the ROUTE protocol in the case of unidirectional broadcasting or the HTTP protocol in the case of bidirectional communication.
  • the DASH client and the HTTP proxy cache exchange segment requests and deliveries according to the Period element of the period file acquired in the process of Step S53, so that the Period element A segment corresponding to the segment URL is acquired (S54).
  • the content of the advertisement corresponding to the segment acquired in this way is reproduced in the advertisement insertion section (for example, the section from time t2 to time t3 in FIG. 9).
  • M1 Mainn Program
  • M2 Mainn Program
  • M3 Mainn Program
  • A1 Ad Break
  • # 1) is inserted
  • A2 Ad Break # 2
  • A3 Ad Break # 3
  • A1 Ad Break # 1
  • user characteristics for example, user preferences
  • A2 Ad Break # 2
  • A3 Ad Break # 3
  • FIG. 10 an example in which the XLink resolver is operated on the client device 40 or the HTTP server of the communication server 30 has been described. However, in the client device 40, the script application plays a role of the XLink resolver. can do.
  • the DASH client when the DASH client detects the URL of the xlink: href attribute of the Period element for advertisement insertion by parsing the MPD metadata (syntactic analysis), it immediately sends an HTTP request to the XLink that runs on the HTTP server. Instead of sending it to the resolver, notify the script application of the URL.
  • the script application is based on the information for identifying the advertisement insertion section reflected in the path part of the URL or the query string.
  • the advertisement content (Ad segment) that matches the target user is selected from the insertion candidates for the advertisement content (Ad segment) corresponding to the section.
  • the script application generates a period file including a Period element corresponding to the selected advertisement content (Ad segment), and responds to the DASH client.
  • the Period element of this period file contains a URL generated for a specific user (for example, a user of class A) specified by groupID, and when playing an Ad segment group based on this list of segment URLs, The content of the advertisement will be played.
  • the selection of advertisement content suitable for the user is performed depending on, for example, the user preference managed by the client device 40, or the exchange of information with the user (interaction). May be performed according to information acquired at any time.
  • an advertisement content suitable for the user is selected according to the input operation of the user.
  • the content of the advertisement (Ad segment) acquired via broadcasting or communication is temporally before the advertisement insertion section by the script application in the local cache (permanent cache).
  • the certainty of advertisement insertion by advertisement insertion control can be ensured. For example, when acquiring advertisement content (Ad segment) via communication, it is assumed that the advertisement content (Ad segment) cannot be acquired depending on the communication status of the Internet 90, etc. Thus, the certainty of advertisement insertion by advertisement insertion control can be improved.
  • the concept of the cache quota domain is introduced, and the client device 40 can share files of advertisement contents (Ad segments) that are reused in a plurality of services. It is possible to increase the reusability of the candidate advertisement content (Ad segment) cached in the persistent cache), and to perform the advertisement insertion by the advertisement insertion control more reliably.
  • the Period element is a unit for describing the configuration of a service such as content.
  • the AdaptationSet element and the Representation element are used for each stream of service components such as video, audio, and caption, and can describe the attributes of each stream.
  • ⁇ Period element of the main part describes information for managing the reproduction of the main part contents (MP4 format video file).
  • EIDR Entertainment Identifier Registry
  • schemeIdUri attribute and the value attribute of the AssetIdentifier element are assigned to the schemeIdUri attribute and the value attribute of the AssetIdentifier element.
  • the URL is described in the xlink: href attribute of the Period element together with information for managing the playback of the default advertisement content (MP4 format video file) ( A) in the figure.
  • This URL is notified to the XLink resolver operating on the HTTP server of the communication server 30, whereby the insertion advertisement is acquired, and the default advertisement is replaced with the insertion advertisement.
  • ⁇ Period element of the main part describes information for managing the reproduction of the main part contents (MP4 format video file).
  • the URL is described in the xlink: href attribute of the Period element together with information for managing the playback of the default advertisement content (MP4 format video file) ( A) in the figure.
  • the URL in which the value of the groupID is inserted is notified to the XLink resolver operating on the HTTP server of the client device 40, so that an advertisement suitable for the specific user specified by the groupID is acquired.
  • the advertisement is replaced with an advertisement suitable for the user.
  • “urn: atsc: ad-insertion” indicates that the solution for advertisement insertion control must be requested to a script (script application) executed locally (client device 40). However, the detailed contents thereof will be described later.
  • the advertisement content is described as an example, and the file of the advertisement content (Ad segment) can be shared by multiple services using the cache quota domain. It can also be applied to other content.
  • a file is an example of a content resource, and any data can be used as long as it can be processed by the client device 40.
  • FIG. 15 is a diagram illustrating an example of the format of SLT metadata in the XML format.
  • SLT format SLT format
  • FIG. 15 among the elements and attributes, “@” is added to the attribute. Further, the indented element and attribute are specified for the upper element.
  • the SLT element is a root element and is an upper element of the bsid attribute, sltCapabilities attribute, sltInetUrl element, and Service element.
  • the broadcast stream ID is specified in the bsid attribute.
  • the sltCapabilities attribute information about required functions is specified.
  • the base URL for acquiring ESG and SLS signaling is specified in the sltInetUrl element.
  • the sltInetUrl element is an upper element of the urlType attribute.
  • a file type that can be used in the base URL is specified.
  • the Service element is an upper element of the serviceId attribute, sltSvcSeqNum attribute, protected attribute, majorChannelNo attribute, minorChannelNo attribute, serviceCategory attribute, shortServiceName attribute, hidden attribute, broadbandAccessRequired attribute, svcCapabilities attribute, quotaDomain attribute, BroadcastSvcSignaling element, and svcInetUrl element.
  • the service ID is specified in the serviceId attribute.
  • the sltSvcSeqNum attribute information related to the version of SLT metadata is specified.
  • encryption information indicating protection of the service is designated.
  • the major channel number is specified in the majorChannelNo attribute.
  • a minor channel number is specified in the minorChannelNo attribute.
  • a service category is specified in the serviceCategory attribute.
  • a short service name is specified in the shortServiceName attribute.
  • the hidden attribute specifies whether the service is a hidden service.
  • the broadbandAccessRequired attribute specifies whether or not it is necessary to access a communication line such as the Internet 90.
  • Information such as functions necessary for decoding is specified in the svcCapabilities attribute.
  • the quota domain identifier of the cache quota domain to which the target service belongs is specified. Services that belong to the same cache quota domain share resources (files) cached in local memory.
  • the BroadcastSvcSignaling element when SLS signaling is acquired via broadcasting, information regarding the acquisition destination of the SLS signaling is specified.
  • the BroadcastSvcSignaling element is an upper element of the slsProtocol attribute, slsMajorProtocolVersion attribute, slsMinorProtocolVersion attribute, slsPlpId attribute, slsDestinationIpAddress attribute, slsDestinationUdpPort attribute, and slsSourceIpAddress attribute.
  • the slsMajorProtocolVersion attribute specifies the major version number of the SLS signaling protocol.
  • the slsMinorProtocolVersion attribute specifies the minor version number of the SLS signaling protocol.
  • slsPlpId an ID of a PLP (Physical Layer Layer) Pipe that transmits SLS signaling is specified.
  • slsDestinationIpAddress the IP address of the destination (destination) of SLS signaling is specified.
  • slsDestinationUdpPort the port number of the destination (destination) of SLS signaling is specified.
  • slsSourceIpAddress the IP address of the source of SLS signaling is specified.
  • the URL from which the SLS signaling is acquired is specified.
  • the svcInetUrl element is an upper element of the urlType attribute.
  • the urlType attribute file types that can be used with this URL are specified.
  • the number of occurrences (Use) is shown.
  • “1” is specified, only one element or attribute is specified.
  • “0..1” is specified, Specifying the element or attribute is optional. If “1..N” is specified, one or more elements or attributes are specified. If “0..N” is specified, one or more elements or attributes are specified. It is optional.
  • unsignedShort or “unsignedByte” is specified as Data Type
  • String indicates that the value of the element or attribute is a character string type.
  • anyURI is specified
  • the value of the element or attribute is the URI. This indicates that the character string has the form of.
  • boolean is specified as Data Type, it indicates that the element or attribute is a Boolean type.
  • language is specified as Data Type, it indicates that the value of the element or attribute is valid as the value of the xml: lang attribute.
  • dateTime is specified, the element Alternatively, the attribute value indicates a specific date and time.
  • FIG. 16 is a diagram illustrating an example of the format of the USB format metadata in the XML format.
  • the bundleDescription element is a root element and is an upper element of the userServiceDescription element (USD element).
  • the userServiceDescription element is an upper element of the globalServiceID attribute, serviceId attribute, serviceStatus attribute, fullMPDUri attribute, sTSIDUri attribute, quotaDomain attribute, name element, serviceLanguage element, capabilityCode element, and deliveryMethod element.
  • Global service ID is specified in the globalServiceID attribute.
  • a service ID is specified in the serviceId attribute.
  • information related to the service status is specified in the serviceStatus attribute.
  • a URI for referring to MPD metadata is specified in the fullMPDUri attribute.
  • a URI for referring to the S-TSID metadata is specified in the sTSIDUri attribute.
  • the quota domain identifier of the cache quota domain to which the target service belongs is specified. Services that belong to the same cache quota domain share resources (files) cached in local memory.
  • 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.
  • the capabilityCode element a code related to the capability is specified.
  • the deliveryMethod element is an upper element of the broadcastAppService element and the unicastAppService element.
  • the broadcastAppService element is an upper element of the basePattern element, and specifies information related to distribution via broadcasting.
  • the unicastAppService element is an upper element of the basePattern element, and specifies information related to delivery via communication.
  • FIG. 17 is a diagram illustrating an example of a format of S-TSID metadata.
  • the S-TSID element is a root element and is a higher element of the serviceId attribute and RS element.
  • a service ID is specified in the serviceId attribute.
  • 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. Details of the SrcFlow element will be described later with reference to FIG. Repair flow information is specified in the RprFlow element.
  • FIG. 18 is a diagram illustrating an example of the format of the SrcFlow element included in the S-TSID metadata of FIG.
  • the SrcFlow element is an upper element of the rt attribute, minBuffSize attribute, EFDT element, ContentInfo element, and Payload element.
  • minBuffSize attribute the minimum buffer size required by the client device 40 is specified.
  • the EFDT element information related to the extended FDT (Extended ⁇ FDT) is specified.
  • Information related to the content is specified in the ContentInfo element.
  • the ContentInfo element is an upper element of the quotaDomain attribute.
  • the quota domain identifier of the cache quota domain to which the service including the target LCT session belongs is specified. Services that belong to the same cache quota domain share resources (files) cached in local memory.
  • 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.
  • (AST format) 19 to 21 are diagrams showing examples of the format of AST metadata.
  • ApplicationList element is a root element and is an upper element of Application element and ApplicationReference element.
  • the Application element is an upper element of the appName element, applicationIdentifier element, applicationDescriptor element, applicationUsageDescriptor element, applicationBoundary element, applicationTransport element, applicationLocation element, and applicationSpecificDescriptor element.
  • the appName element is an upper element of the Language attribute and specifies the name of the application.
  • the applicationIdentifier element is an upper element of the orgID element and appID, and specifies the application ID of the application.
  • the applicationDescriptor element is a high-level element of the type element, controlCode element, visibility element, serviceBound element, priority element, version element, icon element, and storageCapabilities element, and specifies information related to the properties of the target application.
  • the applicationUsageDescriptor element is an upper element of the ApplicationUsage element, and specifies information related to the application usage type.
  • information related to the application boundary is specified.
  • Information related to the transport protocol of the application is specified in the applicationTransport element.
  • URLBase element and URLExtension element are arranged and URL is specified.
  • An extension URL is specified in the URLExtension element.
  • atsc ROUTESessionInfo element (including LCTSession element, tsi attribute, plpID attribute), broadcastStreamId attribute, plpID attribute, sourceIpAddress attribute, destinationIpAddress attribute, and destinationPort attribute are arranged, Information about the ROUTE session is specified.
  • application location information is specified.
  • applicationSpecificDescriptor element an application descriptor is arranged.
  • dvbDescriptor corresponding to DVB (Digital Video Broadcasting) htmlDescriptor corresponding to HTML (HyperText Markup Language), atscDescriptor corresponding to ATSC, or otherDescriptor corresponding to other standards are selectively arranged. .
  • the atsc: atscDescriptor element is a higher level element of the quotaDomain attribute, size element, requiredCapabilities element, icon element, ApplicationRecordingDescriptor element, timeSlotInfo element, contentLinkage element, contentItem element, and graphicConstraintsDescriptor, and specifies information related to ATSC (ATSC3.0) Is done.
  • the quota domain identifier of the cache quota domain to which the service including the target application belongs is specified. Services that belong to the same cache quota domain share resources (files) cached in local memory.
  • the icon element includes a filename attribute, a size attribute, and an aspectRatio attribute.
  • the ApplicationRecordingDescriptor element includes a scheduled_recording_flag element, a trick_mode_aware_flag element, a time_shift_flag element, a dynamic_flag element, an av_synced_flag element, an initializing_replay_flag element, and a storage_properties element.
  • the timeSlotInfo element includes a timeslot_type element, a timeslot_start element, a timeslot_length element, an acquisition_time element, and a repeat_period element.
  • the contentItem element includes a location attribute, a contentLinkage attribute, an updatesAvailable attribute, a size attribute, and a timeSlotInfo element.
  • This timeSlotInfo element includes a timeslot_type element, a timeslot_start element, a timeslot_length element, an acquisition_time element, and a repeat_period element.
  • the graphicConstraintsDescriptor element includes a can_run_without_visible_ui element, a handles_configuration_changed element, a handles_externally_controlled_video element, a graphics_configuration_byte element, and a screenPosition element.
  • SLT metadata, USBD metadata, S-TSID, and AST metadata are examples. For example, other elements and attributes are added. You may make it employ
  • the SLT metadata, USBD metadata, S-TSID, and AST metadata are not limited to the XML format, and may be described in other markup languages or may be in a section format.
  • the quota domain identifier specified by the quotaDomain attribute added by extending signaling such as SLT metadata, USBD metadata, S-TSID, and AST metadata should be included in one type of metadata. It may be included in a plurality of types of metadata. Further, when a plurality of services are provided, a quota domain identifier specified by the quotaDomain attribute may be described in different types of metadata for each service. Furthermore, in the example of the format of each metadata described above, the case where the quota domain identifier is specified by the quotaDomain attribute has been described as an example. However, the quota domain identifier is not limited to the attribute, and is described as an element or text, for example. It may be specified by the information etc.
  • FIG. 22 is a diagram illustrating a configuration example of the Ad / DASH server 10 of FIG.
  • the Ad / DASH server 10 includes a reception unit 101, an Ad / DASH segment generation unit 102, a script application generation unit 103, an MPD generation unit 104, a processing unit 105, and a transmission unit 106.
  • the receiving unit 101 receives streaming distribution data from an external server (not shown) or the like and supplies the data to the Ad / DASH segment generation unit 102, the script application generation unit 103, and the MPD generation unit 104.
  • the Ad / DASH segment generation unit 102 generates an Ad segment and a DASH segment based on the data supplied from the reception unit 101 and supplies the generated Ad segment and DASH segment to the processing unit 105.
  • the Ad segment is a segment file obtained by processing the content of the advertisement.
  • the DASH segment is a live content (for example, a live broadcast program such as a sports broadcast) sent from a relay location via a transmission line or communication line, or a recorded content (for example, a drama) stored in a storage.
  • This is a segment file obtained by processing content such as a pre-recorded program.
  • the Ad segment can be said to be a kind of DASH segment, here, for convenience of explanation, the Ad segment and the DASH segment will be described separately.
  • the script application generation unit 103 generates a script application based on the data supplied from the reception unit 101 and supplies the script application to the processing unit 105.
  • the script application is an application that can execute a script.
  • This script application may be an application developed in a markup language such as HTML5 or a script language such as JavaScript (registered trademark).
  • the MPD generation unit 104 generates MPD metadata based on the data supplied from the reception unit 101 and supplies it to the processing unit 105.
  • MPD metadata a Period element corresponding to content such as a program or an advertisement is described, and details thereof will be described later.
  • the processing unit 105 applies the Ad segment and DASH segment supplied from the Ad / DASH segment generation unit 102, the script application supplied from the script application generation unit 103, and the MPD metadata supplied from the MPD generation unit 104. Then, necessary processing is performed and the data is supplied to the transmission unit 106.
  • the transmission unit 106 transmits the data supplied from the processing unit 105 to the broadcast server 20 or the communication server 30.
  • data distributed via broadcasting is transmitted to the broadcast server 20, and data distributed via communication is It is transmitted to the communication server 30.
  • the Ad / DASH server 10 is configured as described above.
  • FIG. 23 is a diagram illustrating a configuration example of the broadcast server 20 of FIG.
  • the broadcast server 20 includes a reception unit 201, a signaling generation unit 202, a processing unit 203, and a transmission unit 204.
  • the receiving unit 201 receives the Ad segment, the DASH segment, the script application, and the MPD metadata transmitted from the Ad / DASH server 10 and supplies them to the processing unit 203. However, not all of the Ad segment, DASH segment, script application, and MPD metadata are provided from the Ad / DASH server 10, but only data (files) distributed via broadcasting are provided here. And received by the receiving unit 201.
  • the receiving unit 201 receives NRT content data (file) from an external server (not shown) or the like and supplies it to the processing unit 203.
  • the signaling generation unit 202 generates signaling and supplies it to the processing unit 203.
  • the signaling includes LLS signaling such as SLT metadata, and SLS signaling such as USBD metadata, S-TSID metadata, and AST metadata.
  • LLS signaling such as SLT metadata
  • SLS signaling such as USBD metadata, S-TSID metadata, and AST metadata.
  • the quota domain attribute defined in the SLT metadata, USBD metadata, S-TSID metadata, or AST metadata is set to the target cache quota domain.
  • a quota domain identifier will be specified.
  • the processing unit 203 performs necessary processing on the Ad segment and DASH segment, script application, MPD metadata, and NRT content supplied from the receiving unit 201 and the signaling supplied from the signaling generation unit 202, and transmits To the unit 204.
  • an IP / UDP packet in which LCT session data including Ad segment and DASH segment, script application, NRT content, and SLS signaling (USBD metadata, MPD metadata, etc.) are stored in the payload
  • SLS signaling Processing for generating an IP / UDP packet in which data (SLT metadata or the like) is stored in the payload is performed.
  • the transmission unit 204 transmits a broadcast wave (digital broadcast signal) corresponding to the data supplied from the processing unit 203 via the transmission path 80 by the antenna 211 (simultaneous broadcast distribution).
  • Broadcast server 20 is configured as described above.
  • FIG. 24 is a diagram illustrating a configuration example of the communication server 30 of FIG.
  • the communication server 30 includes a reception unit 301, a period file generation unit 302, a processing unit 303, and a communication unit 304.
  • the receiving unit 301 receives the Ad segment, the DASH segment, the script application, and the MPD metadata transmitted from the Ad / DASH server 10 and supplies them to the processing unit 303. However, not all of the Ad segment, DASH segment, script application, and MPD metadata are provided from the Ad / DASH server 10, but only data (files) distributed via communication are provided here. And is received by the receiving unit 301.
  • the processing unit 303 processes data supplied from the reception unit 301 in response to a request (XLink resolution request) from the client device 40 received by the communication unit 304 and supplies the processed data to the communication unit 304.
  • the communication unit 304 transmits data (at least one of Ad segment, DASH segment, script application, and MPD metadata) supplied from the processing unit 303 to the Internet 90.
  • data at least one of Ad segment, DASH segment, script application, and MPD metadata supplied from the processing unit 303 to the Internet 90.
  • the processing unit 303 requests the period file generation unit 302 to generate a period file.
  • the period file generation unit 302 In response to a request from the processing unit 303, the period file generation unit 302 generates a period file including a Period element corresponding to (a characteristic of) the user using the client device 40 and supplies the period file to the processing unit 303.
  • the processing unit 303 processes the period file supplied from the period file generation unit 302 and supplies it to the communication unit 304.
  • the communication unit 304 transmits the period file supplied from the processing unit 303 to the requesting client device 40 of the XLink resolution request via the Internet 90.
  • the communication server 30 is configured as described above.
  • FIG. 25 is a diagram illustrating a configuration example of the client device 40 of FIG.
  • the client device 40 includes a control unit 401, a reception unit 402, broadcast middleware 403, a local cache 404, a browser 405, an output unit 406, and a communication unit 407.
  • the control unit 401 controls the operation of each unit of the client device 40.
  • the receiving unit 402 receives and processes a broadcast wave (digital broadcast signal) transmitted (broadcast broadcast) from the broadcast server 20 via the transmission path 80 by the antenna 411, processes the received data,
  • the broadcast middleware 403 is supplied.
  • the receiving unit 402 includes a tuner and the like.
  • the broadcast middleware 403 processes data supplied from the receiving unit 402 and supplies the processed data to the control unit 401 or the local cache 404.
  • the Ad segment, the DASH segment, the script application, and the MPD metadata are supplied to the local cache 404. Further, the signaling is supplied to the control unit 401.
  • the control unit 401 includes a cache control unit 401A and a reproduction control unit 401B.
  • the cache control unit 401A controls the local cache 404 based on signaling supplied from the broadcast middleware 403, a request from the browser 405, and the like.
  • the playback control unit 401B controls the browser 405 based on signaling supplied from the broadcast middleware 403.
  • the local cache 404 is realized, for example, on a local file system such as on-memory or SSD (solid-state drive).
  • a local file system such as on-memory or SSD (solid-state drive).
  • the local cache 404 caches data (file) supplied from the broadcast middleware 403 according to the control from the cache control unit 401A.
  • data such as an Ad segment, a DASH segment, a script application, and MPD metadata are cached.
  • the local cache 404 includes a normal cache 404A and a permanent cache 404B.
  • the normal cache 404A is a normal cache, and the data cached therein is erased after an appropriate time (not so long) has elapsed.
  • the persistent cache 404B is a special cache, and the data cached therein has priority persistence and will be cached for a longer time than the data cached in the normal cache 404A.
  • the cache control unit 401A uses the quota (of the cache quota domain) in the signaling from the broadcast middleware 403 (quotaDomain attribute defined in SLT metadata, USBD metadata, S-TSID metadata, or AST metadata included in).
  • quotaDomain attribute defined in SLT metadata, USBD metadata, S-TSID metadata, or AST metadata included in.
  • file groups such as Ad segments and DASH segments cached in the persistent cache 404B are linked by the quota domain identifier, so in a plurality of services belonging to the same cache quota domain, Ad segments, DASH segments, etc. File can be shared.
  • the browser 405 is a browser that supports HTML5, JavaScript (registered trademark), and the like.
  • the browser 405 processes the data (file) read from the local cache 404 according to the control from the playback control unit 401B.
  • the browser 405 includes a script execution unit 405A and a DASH client 405B.
  • the script execution unit 405A can execute a script described in a script language such as JavaScript (registered trademark). For example, the script execution unit 405A can read a script application from the local cache 404 (the normal cache 404A or the permanent cache 404B) and execute the script application.
  • a script language such as JavaScript (registered trademark).
  • the script execution unit 405A can read a script application from the local cache 404 (the normal cache 404A or the permanent cache 404B) and execute the script application.
  • the script execution unit 405A executes control of the local cache 404 by the cache control unit 401A by executing CacheStorage API (Application Programming Interface) described in the script application. Details of the CacheStorage API will be described later. Further, the script execution unit 405A generates a period file according to the user preference or the like in response to the XLink resolution request from the DASH client 405B, and responds to the DASH client 405B.
  • CacheStorage API Application Programming Interface
  • the DASH client 405B reads (parses) MPD metadata (file) from the local cache 404 (ordinary cache 404A).
  • the DASH client 405B reads and reproduces the Ad segment or the DASH segment (file thereof) from the local cache 404 (the normal cache 404A or the permanent cache 404B) according to the analysis result of the MPD metadata.
  • the data of the Ad segment or DASH segment reproduced by the DASH client 405B is supplied to the output unit 406.
  • the output unit 406 outputs data supplied from the DASH client 405B in accordance with control from the playback control unit 401B. Thereby, contents such as broadcast programs and advertisements are reproduced, and the video and audio are output.
  • the communication unit 407 exchanges data with the communication server 30 via the Internet 90 according to the control from the control unit 401.
  • the Ad segment, the DASH segment, the script application, and the MPD metadata are supplied to the local cache 404. Further, the signaling is supplied to the control unit 401. 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.
  • the client device 40 is configured as described above.
  • steps S101 to S106 are executed by the Ad / DASH server 10
  • the processes of steps S201 to S205 are executed by the broadcast server 20
  • the processes of steps S301 to S302 are executed by the communication server 30. Executed.
  • step S101 the Ad / DASH segment generation unit 102 of the Ad / DASH server 10 generates an Ad segment and a DASH segment.
  • step S102 the transmission unit 106 of the Ad / DASH server 10 transmits the Ad segment and the DASH segment generated in the process of step S101 to the broadcast server 20.
  • the Ad segment is a segment file obtained by processing the content of the advertisement.
  • the DASH segment is a segment file obtained by processing broadcast program content.
  • the Ad segment and the DASH segment are generated at the same time. However, these segments may be generated at different timings.
  • step S201 the signaling generation unit 202 of the broadcast server 20 generates signaling.
  • step S202 the transmission unit 204 of the broadcast server 20 transmits (simultaneous broadcast delivery) the signaling generated in the process of step S201 via the transmission path 80.
  • LLS signaling such as SLT metadata and SLS signaling such as USBD metadata are generated as signaling.
  • the quota domain attribute defined in the SLT metadata, USBD metadata, S-TSID metadata, or AST metadata is set to the target cache quota domain.
  • a quota domain identifier will be specified.
  • the Ad segment and the DASH segment transmitted in the process of step S202 are received by the receiving unit 201.
  • the transmission unit 204 of the broadcast server 20 transmits the Ad segment and the DASH segment generated by the Ad / DASH server 10 via the transmission path 80 (simultaneous broadcast distribution).
  • step S103 the script application generation unit 103 of the Ad / DASH server 10 generates a script application.
  • step S104 the transmission unit 106 of the Ad / DASH server 10 transmits the script application generated in the process of step S103 to the broadcast server 20.
  • step S ⁇ b> 104 the script application transmitted in step S ⁇ b> 104 is received by the receiving unit 201.
  • step S204 the transmission unit 204 of the broadcast server 20 transmits the script application generated by the Ad / DASH server 10 via the transmission path 80 (simultaneous broadcast distribution).
  • step S105 the MPD generation unit 104 of the Ad / DASH server 10 generates MPD metadata.
  • step S106 the transmission unit 106 of the Ad / DASH server 10 transmits the MPD metadata generated in the process of step S105 to the broadcast server 20.
  • the Period element of the broadcast program and the advertisement is described.
  • the Period element of the advertisement as the xlink: href attribute, “urn: atsc: ad-insertion: abc: 1234” URL that is is described.
  • “urn: atsc: ad-insertion” indicates that the script (script application) executed locally (client device 40) must be requested to resolve advertisement insertion control. To do.
  • the client device 40 is allowed to describe the URL consisting of a character string starting from the usual “http:” in the xlink: href attribute of the Period element of the MPD metadata.
  • URN Uniform Resource Name
  • XLink resolution Period element resolution
  • the MPD metadata transmitted in step S ⁇ b> 106 is received by the receiving unit 201.
  • the transmission unit 204 of the broadcast server 20 transmits the MPD metadata generated by the Ad / DASH server 10 via the transmission path 80 (simultaneous broadcast distribution).
  • steps S202 to S205 it has been described that signaling, Ad segment and DASH segment, script application, and MPD metadata are transmitted at different timings. It will be included in the stream and transmitted.
  • the XLink resolution request transmitted from the client device 40 via the Internet 90 is received by the communication unit 304.
  • the period file generation unit 302 of the communication server 30 generates a period file.
  • the communication unit 304 of the communication server 30 transmits the period file generated in the process of step S301 to the client device 40 that is the transmission source of the XLink resolution request via the Internet 90.
  • the XLink resolution request is transmitted from the client device 40 to the communication server 30 because the URL including the character string starting from “http:” is the period element of the MPD metadata. This is when it is described in the xlink: href attribute.
  • the processing in steps S401 to S408 is executed by the broadcast middleware 403, and the processing in steps S421 to S423 and the processing in steps S441 to S443 are performed in accordance with the local cache 404 (normal cache 404A, permanent). This is executed by the cache control unit 401A that controls the cache 404B). Further, the processing of steps S461 to S466 is executed by the script execution unit 405A of the browser 405, and the processing of steps S481 to S490 is executed by the DASH client 405B of the browser 405.
  • step S 401 the broadcast middleware 403 receives signaling transmitted from the broadcast server 20 via the transmission path 80 via the receiving unit 402.
  • step S402 the broadcast middleware 403 processes the signaling received in the process of step S401.
  • LLS signaling such as SLT metadata and SLS signaling such as USBD metadata are processed as signaling.
  • the quota domain attribute defined in the SLT metadata, USBD metadata, S-TSID metadata, or AST metadata is set to the target cache quota domain. Since the quota domain identifier is designated, services belonging to this cache quota domain are recognized.
  • step S403 the broadcast middleware 403 receives the Ad segment and the DASH segment transmitted from the broadcast server 20 via the transmission path 80 via the receiving unit 402.
  • step S404 the broadcast middleware 403 transfers the Ad segment and DASH segment received in the process of step S403 to the local cache 404.
  • step S421 the cache control unit 401A caches the Ad segment and the DASH segment (file) transferred in the process of step S404 in the normal cache 404A of the local cache 404.
  • the Ad segment and the DASH segment (files thereof) are normally cached in the cache 404A. Therefore, if this state continues, the Ad segment and the DASH segment will be deleted after an appropriate time (not so long). become.
  • the Ad segment and the DASH segment (file) are cached at the same time is explained, but these segments (files) are cached at different timings. Also good.
  • step S405 the broadcast middleware 403 receives a script application transmitted from the broadcast server 20 via the transmission path 80 via the receiving unit 402.
  • step S406 the broadcast middleware 403 transfers the script application received in the process of step S405 to the local cache 404.
  • step S422 the cache control unit 401A caches the script application transferred in step S406 in the normal cache 404A of the local cache 404. In this case, since the script application is normally cached in the cache 404A, if the state as it is is continued, the script application is deleted after an appropriate time (not so long).
  • step S461 the script execution unit 405A acquires the script application cached in the normal cache 404A in the process of step S422 from the local cache 404, and executes the script application.
  • step S462 the script execution unit 405A requests the cache control unit 401A to pull the Ad segment into the permanent cache 404B in accordance with the execution of the script application (the process in step S461).
  • the instruction to pull the Ad segment into the persistent cache 404B is performed by executing the following CacheStorage API described in the script application, for example.
  • the fetchPeriod method is used for an instruction to pull into the persistent cache 404B.
  • the segment file (Ad segment file) specified by the segment URL described in the Period element specified by the xmlElement that is the argument of the fetchPeriod method is the target file stored in the persistent cache 404B.
  • the fetchFile method is used for an instruction to pull into the persistent cache 404B.
  • the segment file (Ad segment file) specified by the url that is the argument of the fetchFile method is the target file stored in the persistent cache 404B.
  • step S441 the cache control unit 401A pulls the Ad segment (file) of the insertion candidate from the normal cache 404A of the local cache 404 into the permanent cache 404B in response to the pull-in request of step S462.
  • the Ad segment (file) drawn from the normal cache 404A is cached in the permanent cache 404B of the local cache 404 (S442).
  • the file group distributed via the broadcast via the transmission path 80 is normally stored in the normal cache 404A (HTTP proxy cache (file system)) of the local cache 404 after the ROUTE protocol is terminated by the broadcast middleware 403. It is unpacked and erased after a certain amount of time (not too long).
  • the file is deleted after a time determined by the cache expiration date described in the HTTP header added at the time of ROUTE entity mode file transfer.
  • the persistent cache 404B of the local cache 404 is handled as a special area in the HTTP proxy cache.
  • the file group expanded in the permanent cache 404B has preferential persistence over the other file group cached in the normal cache 404A, and even if the above “appropriate time” elapses.
  • the file is cached until it reaches a quota (quota) allocated in advance in the local cache 404 without being erased.
  • the service to which the file group cached in the persistent cache 404B belongs is linked by the quota domain identifier specified in the quotaDomain attribute defined in the SLT metadata, USBD metadata, S-TSID metadata, or AST metadata. Therefore, a specific file (in this example, an Ad segment file) can be shared among a plurality of services belonging to the same cache quota domain.
  • step S407 the broadcast middleware 403 receives MPD metadata transmitted from the broadcast server 20 via the transmission path 80 via the receiving unit 402.
  • step S408 the broadcast middleware 403 transfers the MPD metadata received in step S407 to the local cache 404.
  • step S423 the cache control unit 401A caches the MPD metadata transferred in the process of step S408 in the normal cache 404A of the local cache 404.
  • the MPD metadata is normally cached in the cache 404A, the MPD metadata is deleted after an appropriate time (not so long).
  • step S481 the DASH client 405B acquires the MPD metadata cached in the normal cache 404A in the process of step S423 from the local cache 404, and parses (parses) the MPD metadata.
  • step S482 the DASH client 405B acquires the DASH segment acquired according to the processing results (metadata processing results of SLT, USBD, S-TSID, MPD, etc.) in steps S402 and S481, and cached in the normal cache 404A. , Obtained from the local cache 404.
  • step S483 the DASH client 405B plays back the DASH segment acquired in step S482 according to the control from the playback control unit 401B. As a result, the content of the broadcast program is reproduced on the client device 40.
  • step S484 the DASH client 405B determines whether to insert an advertisement. If it is determined in step S484 that the advertisement is not inserted, the process returns to step S482, and the processes of steps S482 to S484 are repeated. In this case, the reproduction of the content of the broadcast program is continued. On the other hand, if it is determined in step S484 that an advertisement is to be inserted, the process proceeds to step S485.
  • step S485 the DASH client 405B requests the script execution unit 405A to resolve the XLink included in the MPD metadata according to the processing result in step S481.
  • the URN consisting of a character string starting from “urn: atsc: ad-insertion” is detected from the URL specified in the xlink: href attribute of the Period element of the MPD metadata by the processing in step S481.
  • an event that prompts XLink resolution (Period element resolution) is issued to the script application simultaneously executed by the script execution unit 405A.
  • step S463 the script execution unit 405A acquires the user preference according to the logic in the script of the script application being executed in response to the XLink resolution request of the process in step S485.
  • step S464 the script execution unit 405A generates a period file based on the user preference acquired in the process of step S463.
  • the script execution unit 405A is inserted into the MPD metadata based on the URL notified by the event from the DASH client 405B (for example, the URL “urn: atsc: ad-insertion: abc: 1234”).
  • PDI Preference-Demographic-and-Interest
  • This PDI is a mechanism that reproduces (accumulates) only content that matches a user's preference by generating information indicating a user's answer to a question provided from a specific server.
  • step S465 the script execution unit 405A responds to the DASH client 405B with the period file generated by the process in step S464.
  • step S486 the DASH client 405B acquires the period file returned in the process of step S465, and parses (syntactically analyzes) the period file.
  • step S487 the DASH client 405B acquires the Ad segment cached in the permanent cache 404B of the local cache 404 according to the processing result in step S486.
  • the URL of the target Ad segment is obtained by parsing the Period element in the process of step S486, the Ad segment of the persistent cache 404B is acquired according to the URL.
  • the Ad segment file is a file shared by a plurality of services belonging to the same cache quota domain, the Ad segment file can be reused.
  • step S488 the DASH client 405B reproduces the Ad segment acquired in step S487 according to the control from the reproduction control unit 401B. Thereby, in the client device 40, the content to be reproduced is switched from the broadcast program to the advertisement (the advertisement is inserted).
  • step S489 the DASH client 405B determines whether reproduction of the Ad segment (processing in step S488) has been completed. If it is determined in step S489 that the playback of the Ad segment has not been completed, the process returns to step S488, and the playback of the Ad segment is continued.
  • step S489 if it is determined in step S489 that the playback of the Ad segment has been completed, the process proceeds to step S490.
  • step S490 the DASH client 405B notifies the script execution unit 405A of completion of playback of the Ad segment.
  • step S466 in response to the Ad segment playback completion notification in step S490, the script execution unit 405A deletes the playback completion Ad segment from the permanent cache 404B to the cache control unit 401A by the script application being executed. Request.
  • deletion instruction of the Ad segment from the persistent cache 404B is performed by executing the following CacheStorage API described in the script application, for example.
  • the deleteFile method is used for a deletion instruction from the persistent cache 404B.
  • the segment file (Ad segment file) specified by the url that is an argument of the deleteFile method becomes a file to be deleted from the persistent cache 404B.
  • step S443 the cache control unit 401A deletes the reproduction completed Ad segment (file thereof) from the permanent cache 404B of the local cache 404 in response to the processing deletion request in step S466.
  • the reproduced content is switched from the advertisement to the broadcast program.
  • 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 can be applied to satellite broadcasting using broadcasting satellites (BS: Broadcasting Satellite) and communication satellites (CS: Communications Satellite), cable broadcasting such as cable TV (CATV), etc. can do.
  • BS Broadcasting Satellite
  • CS Communications Satellite
  • CATV cable TV
  • a cache quota domain (Cache Quota Domain) may be referred to by other names having similar nuances such as a cache quota group (Cache Quota Group).
  • AST Application Signaling Table
  • AIT Application Information Table
  • NRT Non Real Time
  • LCC Locally Cached Content
  • 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. 29 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.
  • the control unit distinguishes the shared resource that is a shared resource from other resources.
  • the receiving device according to (1).
  • the content and the control information are transmitted by broadcast waves, The service is a digital broadcast service, The receiving apparatus according to (1) or (2), wherein the control information is signaling for providing the service.
  • the signaling is first signaling that can specify attributes of a plurality of services, The receiving apparatus according to (3), wherein the first signaling includes the resource sharing information specified in service units.
  • the signaling is second signaling that can specify attributes for each service, The receiving apparatus according to (3), wherein the second signaling includes the resource sharing information specified in a predetermined unit within a target service.
  • the content resource is a file of a predetermined format, The control unit stores the file of the shared resource in a second storage area different from the first storage area in which the file of the other resource is stored according to the operation of the application transmitted together with the content.
  • the receiving device according to any one of (6).
  • the receiving device (8) The receiving device according to (7), wherein the control unit deletes the file of the shared resource stored in the second storage area according to the operation of the application.
  • the broadcast wave is a broadcast wave corresponding to an IP (Internet Protocol) transmission method, The receiving device according to any one of (3) to (8), wherein data of the content resource file is stored and transmitted in an IP packet including a UDP (User Datagram Protocol) packet.
  • the receiving device is Receive content, Based on the control information, which is control information transmitted together with the content, the resource information indicating whether the resource of the content is a resource shared by a plurality of services, the resource of the content is: A data processing method including a step of controlling storage of the resource in a storage device so as to be shared by a plurality of services. (12) A generating unit that generates control information including resource sharing information indicating whether the resource of the content is a resource shared by a plurality of services; A transmission apparatus comprising: a transmission unit that transmits the control information together with the content.
  • the content and the control information are transmitted by broadcast waves,
  • the service is a digital broadcast service,
  • the signaling is first signaling that can specify attributes of a plurality of services,
  • the signaling is second signaling that can specify attributes for each service,
  • the transmission apparatus according to (13), wherein the second signaling includes the resource sharing information designated in a predetermined unit within a target service.
  • the transmission apparatus according to (15), wherein the resource sharing information is specified in service units, session units, or application units.
  • the transmission device according to any one of (12) to (16), wherein the content resource is a file in a predetermined format.
  • the broadcast wave is a broadcast wave corresponding to the IP transmission method,
  • the content resource file data is transmitted by being stored in an IP packet including a UDP packet (13) to (17).
  • the content includes advertising content,
  • the transmission device according to any one of (12) to (18), wherein the resource sharing information is identification information for identifying a group to which a plurality of services that share the content resource of the advertisement belongs.
  • the transmitting device is Generate control information including resource sharing information that indicates whether the content resource is a resource shared by multiple services, A data processing method including a step of transmitting the control information together with the content.
  • Ad / DASH server 10 Ad / DASH server, 20 broadcast server, 30 communication server, 40 client device, 80 transmission path, 90 Internet, 101 reception unit, 102 Ad / DASH segment generation unit, 103 script application generation unit, 104 MPD generation Unit, 105 processing unit, 106 transmission unit, 201 reception unit, 202 signaling generation unit, 203 processing unit, 204 transmission unit, 301 reception unit, 302 period file generation unit, 303 processing unit, 304 communication unit, 401 control unit, 401A Cache control unit, 401B playback control unit, 402 reception unit, 403 broadcast middleware, 404 local cache, 404A normal cache, 404B permanent cache Gerhard, 405 browser, 405A script execution unit, 405B DASH client, 406 output unit, 407 communication unit, 1000 Computer, 1001 CPU

Landscapes

  • Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • Multimedia (AREA)
  • General Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Business, Economics & Management (AREA)
  • Marketing (AREA)
  • Information Transfer Between Computers (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

本技術は、複数のサービスにおいて再利用されるリソースを共有することができるようにする受信装置、送信装置、及び、データ処理方法に関する。 受信装置は、コンテンツを受信し、コンテンツとともに伝送される制御情報であって、コンテンツのリソースが、複数のサービスで共有されるリソースであるかどうかを示すリソース共有情報を含む制御情報に基づいて、コンテンツのリソースが、複数のサービスで共有されるように、リソースの記憶装置への記憶を制御する。本技術は、例えば、ATSC3.0に対応したテレビ受像機に適用することができる。

Description

受信装置、送信装置、及び、データ処理方法
　本技術は、受信装置、送信装置、及び、データ処理方法に関し、特に、複数のサービスにおいて再利用されるリソースを共有することができるようにした受信装置、送信装置、及び、データ処理方法に関する。
　クライアント装置において、特定のサービスに付随するアプリケーションのファイルに対するアクセスのパフォーマンスを向上させるためには、ローカルキャッシュにあらかじめ必要なファイルをキャッシュしておく必要がある。
　例えば、現在策定が進められている米国の次世代放送規格であるATSC(Advanced Television Systems Committee)3.0では、放送経由又は通信経由で取得されるあらゆるファイルが、クライアント装置におけるローカルなファイルシステム上のローカルキャッシュに一旦蓄積されて、ストリームのレンダラやアプリケーションに提供されるモデルが想定されている。ただし、ローカルなファイルシステムとしては、例えば、オンメモリ（On Memory）やSSD(Solid State Drive)などのファイルシステム、又は特別なデータベースなどが用いられる。
　これらのローカルキャッシュ上のファイルは、ある限定された期間キャッシュに維持された後で、ファイルに付随されたHTTP(Hypertext Transfer Protocol)ヘッダのキャッシュコントロールヘッダ（Cache Control Header）のパラメタに基づいて消去される。ただし、このような処理が行われるのは、ROUTE(Real-time Object Delivery over Unidirectional Transport)プロトコルの配信モードの一種であるエンティティモードとなる場合である。
　一般的に、クライアント装置のチューナや記憶リソースの制限から、すべての受信可能な放送波上のファイルをキャッシュすることができないため、その時点で、選局しているサービスに必要なファイル群のみを取得してキャッシュし、サービス（チャネル）が切り替えられた場合には、直ちに記憶リソースが解放されるというような動作が想定される。
　なお、放送番組や広告などのコンテンツを、放送局の放送サーバから一方向の放送経由で、あるいは通信サーバから双方向の通信経由で、クライアント装置に配信するための技術の開発や規格化が、現在、盛んに進められている。このような放送経由又は通信経由でデータ配信を実現する技術としては、例えば、特許文献１に開示されている技術が知られている。
特開２０１４－５７２２７号公報
　ここで、あるサービスで転送されるファイルのうち、例えば、どのサービスでも共通に利用される、広告のコンテンツなどのファイルを、複数のサービスで共有できれば、キャッシュの記憶領域や配信帯域などを有効に利用することができる。そのため、複数のサービスにおいて再利用されるリソースを共有するための提案が要請されていた。
　本技術はこのような状況に鑑みてなされたものであり、複数のサービスにおいて再利用されるリソースを共有することができるようにするものである。
　本技術の第１の側面の受信装置は、コンテンツを受信する受信部と、前記コンテンツとともに伝送される制御情報であって、前記コンテンツのリソースが、複数のサービスで共有されるリソースであるかどうかを示すリソース共有情報を含む前記制御情報に基づいて、前記コンテンツのリソースが、複数のサービスで共有されるように、前記リソースの記憶装置への記憶を制御する制御部とを備える受信装置である。
　本技術の第１の側面の受信装置は、独立した装置であってもよいし、１つの装置を構成している内部ブロックであってもよい。また、本技術の第１の側面のデータ処理方法は、上述した本技術の第１の側面の受信装置に対応するデータ処理方法である。
　本技術の第１の側面の受信装置、及び、データ処理方法においては、コンテンツが受信され、前記コンテンツとともに伝送される制御情報であって、前記コンテンツのリソースが、複数のサービスで共有されるリソースであるかどうかを示すリソース共有情報を含む前記制御情報に基づいて、前記コンテンツのリソースが、複数のサービスで共有されるように、前記リソースの記憶装置への記憶が制御される。
　本技術の第２の側面の送信装置は、コンテンツのリソースが、複数のサービスで共有されるリソースであるかどうかを示すリソース共有情報を含む制御情報を生成する生成部と、前記コンテンツとともに、前記制御情報を送信する送信部とを備える送信装置である。
　本技術の第２の側面の送信装置は、独立した装置であってもよいし、１つの装置を構成している内部ブロックであってもよい。また、本技術の第２の側面のデータ処理方法は、上述した本技術の第２の側面の送信装置に対応するデータ処理方法である。
　本技術の第２の側面の送信装置、及び、データ処理方法においては、コンテンツのリソースが、複数のサービスで共有されるリソースであるかどうかを示すリソース共有情報を含む制御情報が生成され、前記コンテンツとともに、前記制御情報が送信される。
　本技術の第１の側面、及び、第２の側面によれば、複数のサービスにおいて再利用されるリソースを共有することができる。
　なお、ここに記載された効果は必ずしも限定されるものではなく、本開示中に記載されたいずれかの効果であってもよい。
本技術を適用した伝送システムの一実施の形態の構成を示す図である。 本技術のIP伝送方式のプロトコルスタックの例を示す図である。 ROUTE/FLUTEの構造を示す図である。 ROUTEの詳細な構造を示す図である。 キャッシュクォータドメインの概要を示す図である。 クォータドメイン識別子の配置例を示す図である。 クォータドメイン識別子の指定方法を示す図である。 クォータドメイン識別子の指定とファイルキャッシュの関係を示す図である。 広告挿入の流れを説明する図である。 受信側の上位層における処理の流れを示す図である。 MPDメタデータのPeriod要素のxlink:href属性の記述例を示す図である。 MPDメタデータによる時系列の広告挿入制御を説明する図である。 MPDメタデータの記述例を示す図である。 MPDメタデータの記述例を示す図である。 SLTのフォーマットの例を示す図である。 USBDのフォーマットの例を示す図である。 S-TSIDのフォーマットの例を示す図である。 SrcFlowのフォーマットの例を示す図である。 ASTのフォーマットの例を示す図である。 ASTのフォーマットの例を示す図である。 ASTのフォーマットの例を示す図である。 Ad/DASHサーバの構成例を示す図である。 放送サーバの構成例を示す図である。 通信サーバの構成例を示す図である。 クライアント装置の構成例を示す図である。 送信側の処理の流れを説明するフローチャートである。 受信側の処理の流れを説明するフローチャートである。 受信側の処理の流れを説明するフローチャートである。 コンピュータの構成例を示す図である。
　以下、図面を参照しながら本技術の実施の形態について説明する。なお、説明は以下の順序で行うものとする。
１．システムの構成
２．キャッシュクォータドメインの概要
３．アプリケーションの応用例
４．シグナリングの例
５．各装置の構成
６．各装置で実行される処理の流れ
７．変形例
８．コンピュータの構成
＜１．システムの構成＞
（伝送システムの構成）
　図１は、本技術を適用した伝送システムの一実施の形態の構成を示す図である。なお、システムとは、複数の装置が論理的に集合したものをいう。
　図１において、伝送システム１は、Ad/DASHサーバ１０、放送サーバ２０、通信サーバ３０、及び、クライアント装置４０から構成される。
　Ad/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)と称される。また、後者のファイルフォーマットは、セグメントフォーマットとも称される。
　Ad/DASHサーバ１０は、番組のコンテンツのセグメント（以下、DASHセグメントともいう）や、広告のコンテンツのセグメント（以下、Adセグメントともいう）のファイルを生成し、放送サーバ２０又は通信サーバ３０に送信する。また、Ad/DASHサーバ１０は、MPDメタデータを生成し、放送サーバ２０又は通信サーバ３０に送信する。
　また、Ad/DASHサーバ１０は、アプリケーションを生成し、放送サーバ２０又は通信サーバ３０に送信する。このアプリケーションとしては、例えば、スクリプト（Script）を実行可能なスクリプトアプリケーションが含まれる。なお、スクリプトアプリケーションは、例えば、HTML5(HyperText Markup Language 5)等のマークアップ言語や、JavaScript（登録商標）等のスクリプト言語で開発されたアプリケーションとすることができる。
　放送サーバ２０は、ATSC3.0等のデジタル放送の規格に準拠したデータ伝送を行うことが可能な送信機である。放送サーバ２０は、Ad/DASHサーバ１０から送信されてくるDASHセグメントやAdセグメント、MPDメタデータ、アプリケーションのファイルを処理し、シグナリングとともに、伝送路８０を介して送信（一斉同報配信）する。
　また、放送サーバ２０には、NRTコンテンツが入力される。NRTコンテンツは、NRT(Non Real Time)放送で伝送されるコンテンツであって、クライアント装置４０のストレージに一旦蓄積された後で再生が行われる。放送サーバ２０は、そこに入力されるNRTコンテンツのファイルを処理し、伝送路８０を介して送信（一斉同報配信）する。
　通信サーバ３０は、インターネット９０に接続されたクライアント装置４０からの要求に応じて、インターネット９０を介して各種のデータを提供するサーバである。通信サーバ３０は、Ad/DASHサーバ１０から送信されてくるDASHセグメントやAdセグメント、MPDメタデータ、アプリケーションのファイルを処理する。そして、通信サーバ３０は、クライアント装置４０からの要求に応じて、インターネット９０を介して、各種のファイルを送信する。
　クライアント装置４０は、ATSC3.0等のデジタル放送の規格に準拠した伝送データを受信可能な受信機である。例えば、クライアント装置４０は、テレビ受像機やセットトップボックスなどの固定受信機、あるいは、スマートフォンや携帯電話機、タブレット型コンピュータなどのモバイル受信機である。クライアント装置４０は、例えば車載テレビなどの自動車に搭載される機器であってもよい。
　クライアント装置４０は、放送サーバ２０から伝送路８０を介して送信（一斉同報配信）されてくる、DASHセグメントやAdセグメント、シグナリング、MPDメタデータ、アプリケーション、NRTコンテンツなどのファイルを受信して処理することで、放送番組や広告などのコンテンツの映像や音声を出力する。
　また、クライアント装置４０は、通信機能を有する場合、インターネット９０を介して、通信サーバ３０にアクセスし、各種のファイルを取得することができる。例えば、クライアント装置４０は、通信サーバ３０からインターネット９０を介して送信（適応的にストリーミング配信）される、DASHセグメントやAdセグメント、MPDメタデータなどのファイルを受信して処理することで、VOD(Video On Demand)番組や広告などのコンテンツの映像や音声を出力する。
　なお、伝送システム１において、伝送路８０は、地上波（地上波放送）のほか、例えば、放送衛星（BS：Broadcasting Satellite）や通信衛星（CS：Communications Satellite）を利用した衛星放送、あるいは、ケーブルを用いた有線放送（CATV）などであってもよい。
　また、ATSC3.0は、現在策定が進められている米国の次世代放送規格である。ATSC3.0では、伝送方式として、現在広く普及しているMPEG2-TS(Transport Stream)方式ではなく、通信の分野で用いられているIP(Internet Protocol)パケットをデジタル放送に用いたIP伝送方式を導入することで、より高度なサービスを提供することが想定されている。
（本技術のプロトコルスタック）
　図２は、本技術のIP伝送方式のプロトコルスタックの例を示す図である。
　図２において、最も下位の階層は、物理層（Physical Layer）とされる。ATSC3.0等のIP伝送方式のデジタル放送では、一方向の放送を利用した伝送に限らず、一部のデータを、双方向の通信を利用して伝送する場合があるが、放送を利用する場合、その物理層（Broadcast）は、サービス（チャネル）のために割り当てられた放送波の周波数帯域が対応することになる。
　物理層（Broadcast）の上位の階層は、IP層とされる。IP層は、通信の階層モデルにおけるネットワーク層に相当するものであり、IPアドレスによりIPパケットが特定される。IP層に隣接する上位階層は、通信の階層モデルにおけるトランスポート層に相当するUDP(User Datagram Protocol)層とされ、さらにその上位の階層は、ROUTE(Real-time Object Delivery over Unidirectional Transport)又はMMTP(MPEG Media Transport Protocol)とされる。
　また、UDP層の上位の階層、すなわち、UDPパケットを含むIPパケットには、SLTメタデータが格納され、伝送される。SLSメタデータは、サービスの選局に必要な情報（選局情報）など、放送ネットワークにおけるストリームやサービスの構成を示す基本情報を含むLLS(Link Layer Signaling)シグナリングである。なお、LLSシグナリングは、SLS(Service Layer Signaling)シグナリングに先行して取得されるシグナリングであって、LLSシグナリングに含まれる情報に従い、SLSシグナリングが取得される。
　ROUTEは、ストリーミングファイル転送用のプロトコルであって、FLUTE(File Delivery over Unidirectional Transport)を拡張したものである。なお、ROUTEの詳細な内容は、図３及び図４を参照して後述する。
　ROUTEに隣接する上位階層のうち、一部の階層は、シグナリング（ROUTE specific Signaling）とNRTコンテンツ（NRT Files）とされる。このシグナリングは、SLSシグナリングであって、例えば、USBD(User Service Bundle Description)，S-TSID(Service-based Transport Session Instance Description)，MPD(Media Presentation Description)，AST(Application Signaling Table)等のメタデータが含まれる。
　USDメタデータは、他のメタデータの取得先などの情報を含む。S-TSIDメタデータは、LSID(LCT Session Instance Description)をATSC3.0向けに拡張したものであって、ROUTEプロトコルの制御情報である。MPDメタデータは、上述したように、ストリーミング配信される動画や音声のファイルの管理情報である。ASTは、アプリケーションの制御情報である。
　なお、NRTコンテンツは、ROUTEセッションで伝送されるコンテンツの一例であり、例えば、アプリケーションや電子サービスガイド（ESG：Electronic Service Guide）などのコンテンツが、ROUTEセッションにより伝送されるようにしてもよい。
　ROUTEに隣接する上位階層のうち、上述した階層以外の他の階層は、DASHセグメント（ISO BMFF）とされる。また、DASHセグメント（ISO BMFF）に隣接する上位階層は、DASHプレーヤ／デコーダとされる。すなわち、トランスポートプロトコルとしてROUTEを用いる場合には、放送番組等のコンテンツを構成するサービスコンポーネント（ビデオやオーディオ、字幕等）のストリームデータが、ISO BMFF(ISO Base Media File Format)の規格に準じたDASHセグメント単位で、ROUTEセッションにより伝送される。
　一方で、MMTPは、ストリーミングファイルを転送するためのプロトコルである。MMTPに隣接する上位階層のうち、一部の階層は、シグナリング（MMTP specific Signaling）とされる。このシグナリングとしては、例えば、USBD(User Service Bundle Description)やMPT(MMT Package Table)等のメタデータが含まれる。
　また、MMTPに隣接する上位階層のうち、シグナリング以外の階層は、MPU(Media Processing Unit)（ISO BMFF）とされる。また、MPU（ISO BMFF）に隣接する上位階層は、DASHプレーヤ／デコーダとされる。すなわち、トランスポートプロトコルとしてMMTを用いる場合には、放送番組等のコンテンツを構成するサービスコンポーネント（ビデオやオーディオ、字幕等）のストリームデータが、ISO BMFF(ISO Base Media File Format)の規格に準じたMPU単位で、MMTPセッションにより伝送される。
　このように、図２のプロトコルスタックにおいては、トランスポートプロトコルとして、ROUTEとMMTPとが併記されているため、一方向の放送系ストリーミング配信では、DASHセグメント（ISO BMFF）のファイルを転送するROUTEプロトコルか、あるいは、MPU（ISO BMFF）のファイルを転送するMMTPのいずれか一方のプロトコルを用いることになる。
　また、双方向の通信を利用する場合、その物理層（Broadband）の上位の階層は、ネットワーク層に相当するIP層とされる。また、IP層に隣接する上位階層は、トランスポート層に相当するTCP(Transmission Control Protocol)層とされ、さらに、TCP層に隣接する上位階層は、アプリケーション層に相当するHTTP層とされる。すなわち、これらの階層によって、インターネット９０等のネットワークで稼働するTCP/IPなどのプロトコルが実装される。
　HTTP層に隣接する上位階層のうち、一部の階層は、シグナリング（All Signaling Objects）とNRTコンテンツ（NRT Files）とされる。このシグナリングとしては、上述したROUTEやMMTPで伝送されるシグナリングなど、すべてのシグナリングが含まれる。また、NRTコンテンツは、通信経由で取得されるコンテンツの一例であり、例えば、アプリケーションなどのコンテンツが伝送されるようにしてもよい。
　HTTP層に隣接する上位階層のうち、上述した階層以外の他の階層は、DASHセグメント（ISO BMFF）とされ、さらに、このDASHセグメント（ISO BMFF）に隣接する上位階層は、DASHプレーヤ／デコーダとされる。すなわち、双方向の通信系のストリーミング配信では、VOD番組等のコンテンツを構成するサービスコンポーネント（ビデオやオーディオ、字幕等）のストリームデータが、ISO BMFFの規格に準じたDASHセグメント単位で伝送されることになる。
　また、一方向の放送のROUTEやMMTP等のプロトコル、双方向の通信のTCP/IPプロトコルなどを用いることで、アプリケーション（Applications）を伝送することができる。例えば、このアプリケーションは、HTML5やJS（JavaScript（登録商標））などにより開発されたアプリケーションとすることができる。
　なお、図２において、ROUTEの一部に、HTTPプロキシ（HTTP Proxy）が記述されているのは、アプリケーションによって、DASHセグメント（ISO BMFF）のファイルを取得する場合に、クライアント装置４０に実装された放送ミドルウェアが、HTTPサーバとして振る舞う実装を想定しているためである。また、図２においては、コンテンツ保護のセキュリティフレームワークとして、W3C(World Wide Web Consortium)とMPEG(Moving Picture Experts Group)に準拠したEME/CENC(Encrypted Media Extension / Common Encryption Scheme)を採用しているため、DASHセグメント（ISO BMFF）と、MPU（ISO BMFF）の一部に、EME/CENCと記述されている。
　また、LLSシグナリングとしてのSLTメタデータや、SLSシグナリングとしてのUSBD，S-TSID，MPD，AST等のメタデータは、XML(Extensible Markup Language)等のマークアップ言語により記述される。
　以上のように、本技術のIP伝送方式のプロトコルスタックにおいては、一方向の放送系の階層と、双方向の通信系の階層の一部が共通のプロトコルとなって、一方向の放送と双方向の通信で、コンテンツを構成するサービスコンポーネントのストリームデータを、ISO BMFFの規格に準じたDASHセグメント単位で伝送することができる。そのため、一方向の放送系のストリーミング配信と、双方向の通信系のストリーミング配信の双方を行う場合において、上位の階層のプロトコルが共通化されているため、例えば、放送サーバ２０やクライアント装置４０では、実装の負担や処理の負担を軽減することができる。
（ROUTEの構造）
　図３は、ROUTEの構造を示す図である。ただし、図３には、ROUTEとの比較のため、FLUTEについても記述している。
　FLUTEは、ALC(Asynchronous Layered Coding)と呼ばれるスケーラブルなファイルオブジェクトのマルチキャストプロトコル、具体的には、そのビルディングブロックであるLCT(Layered Coding Transport)やFEC(Forward Error Correction)コンポーネントの組み合わせにより構成される。
　ここで、ALCは、任意のバイナリファイルを一方向でマルチキャスト転送するのに適したプロトコルである。すなわち、ALCは、高信頼の非同期型の１対多の放送型のプロトコルとして開発されたものであるが、LCTとFECを利用しており、対象のファイルにFECをかけてLCTパケットに格納し、IPマルチキャスト上で転送する場合には、UDPパケットとIPパケットに格納する。
　FLUTEにおけるトランスポートセッションは、送信元IPアドレスのスコープでユニークなTSI(Transport Session Identifier)により識別される。FLUTEでは、トランスポートセッションごと、又はファイルごとにFECの方式を変更することができる。また、FLUTEは、トランスポートセッションごとに転送されるFDT(File Delivery Table)と称されるXML形式の転送制御情報が導入されている。
　LCTパケットに格納されたFECエンコーディングシンボルと同一のトランスポートセッション内で転送されるFDTファイルに、対象のファイルの基本属性と転送制御パラメタを記述する。FDTは、対象のファイルの識別子と対応するFECエンコーディングシンボル列が格納されたLCTパケット列とのマッピングを定義し、さらに個々のファイルの内容のMIMEタイプやサイズ、転送符号化方式、メッセージダイジェスト、FECデコードに必要なパラメタなどを格納することができる。なお、FDT自身にもFECを適用することが可能であり、自身のFECパラメタなどは別途LCTのレイヤで伝送することになる。
　ところで、ROUTEは、FLUTEの拡張となるが、その差分としては、主に、オブジェクトバンドルとメディアアウェアなフラグメンテーションを挙げることができる。図４には、ROUTEの詳細な構造を示している。
　ROUTEにおけるオブジェクトバンドルの特徴は、異なるサイズのソースブロックからなるビデオやオーディオのストリームをバンドルして、１つのスーパーオブジェクトとして構成し、それをもとにFECリペアストリームを生成する方法と、ソースストリームとリペアストリームの関係通知をプロトコルレベルでサポートしているところにある。
　一般に、オーディオストリーム等は、単位時間あたりのデータ量（データオブジェクト）が小さいため、ビデオストリームと比べて、小さなソースオブジェクトサイズとなる。これらのソースオブジェクトサイズの異なるストリームに対して、同一のFEC方式でストリームごとにリペアシンボルを生成すると、ソースオブジェクトサイズの大小により、エラーに対する感受性が異なってくる。
　ROUTEでは、複数のレートの異なるソースストリームからソースブロックを切り出してスーパーオブジェクトを構成し、それをもとに生成されるFECリペアシンボルによりリペアストリームを構成することができる。すなわち、異なる種類のソースストリームに跨ってリペアストリームが生成される。ここで、ソースシンボルからなるソースストリームと、リペアシンボルからなるリペアストリームと、ROUTEセッション内の別のLCTセッションとして転送することができる。
　複数のソースストリームから切り出されたソースブロックから、どのようにスーパーオブジェクトを構成してFECストリームを生成するかについての情報（制御情報）が、LSID（FDT）を拡張したS-TSIDメタデータに記述される。受信機側では、このS-TSIDメタデータに記述された情報に基づいて、ROUTEセッションで伝送されるLCTパケット列から、スーパーオブジェクトを復元して、対象のファイルを抽出することができる。
　一般に、放送ストリームは、送信機側で、サービスを構成するすべてのストリームを多重化して送信し、受信機側で、自身に必要なストリームを取捨選択するモデルである。したがって、送信機側で、サービスを構成するすべてのストリームからなるスーパーオブジェクトを構成して、受信機側でスーパーオブジェクトを復元してから、必要なストリームを取捨選択するという処理モデルの適用が可能なユースケースにおいては、ROUTEにより実現されるFEC構成方法が有効である。
　以上、FLUTEの拡張であるROUTEについて説明した。
＜２．キャッシュクォータドメインの概要＞
　ところで、クライアント装置４０において、放送番組等の特定のサービスに付随するアプリケーションに対するアクセスのパフォーマンスを向上させるためには、ローカルキャッシュにあらかじめ必要なファイルをキャッシュしておく必要がある。例えば、ATSC3.0では、放送経由又は通信経由で取得されるあらゆるファイルが、クライアント装置４０におけるローカルなファイルシステム上のローカルキャッシュに一時蓄積されて、ストリームのレンダラやアプリケーションに提供されるモデルが想定されている。
　また、クライアント装置４０においては、チューナや記憶リソースの制限から、すべての受信可能な放送波上のファイルをキャッシュすることはできないため、その時点で選局しているサービスに必要なファイル群のみを取得してキャッシュし、サービス（チャネル）が切り替えられた場合には、直ちに記憶リソースを解放するというような動作が想定されている。
　一方で、あるサービスで転送されるファイルのうち、例えば、どのサービスでも共通に利用される、広告のコンテンツなどのファイルを、複数のサービスで共有できれば、キャッシュの記憶領域や配信帯域などを有効に利用することができるなどのメリットがある。そのため、複数のサービスにおいて再利用されるリソースを共有するための提案が要請されているが、本技術では、キャッシュクォータドメイン（Cache Quota Domain）の概念を導入して、キャッシュクォータドメインを識別するクォータドメイン識別子をシグナリングとして伝送することで、クライアント装置４０で、複数のサービスにおいて再利用されるリソースを共有することができるようにする。
（キャッシュクォータドメインの概要）
　図５は、キャッシュクォータドメインの概要を示す図である。
　キャッシュクォータドメインは、再利用されるリソースを共有するためのドメイン（グループ）である。図５においては、サービスＡ、サービスＢ、及び、サービスＣが、クォータドメイン１に属し、サービスＸ、及び、サービスＹが、クォータドメイン２に属する場合を例示している。なお、図５のローカルキャッシュの記憶領域は、後述する図２５のローカルキャッシュ４０４の永続キャッシュ４０４Ｂに相当するものである。
　この場合に、クライアント装置４０では、クォータドメイン１に属するサービスＡ乃至Ｃで共有されるアプリケーションやDASHセグメント等のファイルが、ローカルキャッシュのクォータドメイン１に割り当てられた記憶領域にキャッシュされる。すなわち、クォータドメイン１（のクォータドメイン識別子）により識別されるローカルキャッシュの記憶領域に、クォータドメイン１に属するサービスで共有されるファイルがキャッシュされるので、クォータドメイン１に属するサービスでは、当該記憶領域のファイルを取得して、処理（再生）することができる。
　一方で、クォータドメイン２に属するサービスＸ及びＹで共有されるアプリケーションやDASHセグメント、ピリオドファイル等のファイルが、ローカルキャッシュのクォータドメイン２に割り当てられた記憶領域にキャッシュされる。すなわち、クォータドメイン２（のクォータドメイン識別子）により識別されるローカルキャッシュの記憶領域に、クォータドメイン２に属するサービスで共有されるファイルがキャッシュされるので、クォータドメイン２に属するサービスでは、当該記憶領域のファイルを取得して、処理（再生）することができる。
　ただし、各サービスは、自身が属するクォータドメインを跨いで、他のクォータドメインのリソースにアクセスすることはできない。例えば、クォータドメイン１に属するサービスＡ乃至Ｃは、クォータドメイン２のリソースにアクセスすることはできないし、クォータドメイン２に属するサービスＸ及びＹは、クォータドメイン１のリソースにアクセスすることはできない。
　このように、キャッシュクォータドメインの概念を導入することで、各クォータドメインに属するサービスでは、自身の属するクォータドメイン内のリソースを共有して利用（再利用）することが可能となる。
　例えば、単一の放送局により提供される複数のサービス、あるいは、複数の放送局から組織される放送局連合により提供される複数のサービスなどが、同一のキャッシュクォータドメインに属することで、キャッシュクォータドメインごとに、複数のサービスが、リソース（ファイル）を共有することになる。
（クォータドメイン識別子の配置例）
　図６は、クォータドメイン識別子の配置例を示す図である。
　キャッシュクォータドメインを識別するクォータドメイン識別子は、放送波の各レイヤで伝送されるシグナリングにより伝送することができる。すなわち、シグナリングにおいて、対象のサービスが属するキャッシュクォータドメインのクォータドメイン識別子を指定可能な属性（又は要素）を追加することで、クライアント装置４０では、シグナリングに含まれるクォータドメイン識別子に基づいて、同一のキャッシュクォータドメインに属するサービスで、リソース（ファイル）を共有させることができる。
　図６に示すように、クォータドメイン識別子は、IP/UDPパケットのペイロードに格納される、LLSシグナリングであるSLTメタデータ、又はIP/UDPパケットのペイロードに格納される、LCTセッションで伝送されるSLSシグナリングであるUSBDメタデータ、S-TSIDメタデータ、若しくはASTメタデータを拡張することで、そこに配置することができる。
（Ａ）SLTメタデータに配置する場合
　キャッシュクォータドメインのクォータドメイン識別子が、SLTメタデータの拡張により指定される場合、SLTメタデータは、複数のサービスの属性を指定可能であるので、対象のサービスの属性として、クォータドメイン識別子を指定可能な属性（又は要素）を追加することになる。ここでは、例えば、SLTメタデータのservice要素に、quotaDomain属性を定義することで、対象のサービスが属するキャッシュクォータドメインのクォータドメイン識別子を指定することが可能となる。
　例えば、サービスＡ乃至Ｚが提供される場合に、SLTメタデータでは、サービスＡ乃至ＣのサービスIDが指定されたservice要素のquotaDomain属性として、クォータドメイン１（図５）のクォータドメイン識別子が指定されるようにする。また、このSLTメタデータでは、サービスＸ及びＹのサービスIDが指定されたservice要素のquotaDomain属性として、クォータドメイン２（図５）のクォータドメイン識別子が指定されるようにする。
　このように、SLTメタデータにおいて、service要素に、quotaDomain属性を定義することで、サービス単位で、クォータドメイン識別子を指定することが可能となる。
（Ｂ）USBDメタデータに配置する場合
　キャッシュクォータドメインのクォータドメイン識別子が、USBDメタデータの拡張により指定される場合、USBDメタデータのUSD要素に、quotaDomain属性を定義することで、対象のサービスが属するキャッシュクォータドメインのクォータドメイン識別子を指定することが可能となる。
　例えば、サービスＡ乃至Ｚが提供される場合に、サービスＡ乃至ＣのUSBDメタデータでは、USD要素のquotaDomain属性として、クォータドメイン１（図５）のクォータドメイン識別子が指定されるようにする。また、例えば、サービスＸ及びＹのUSBDメタデータでは、USD要素のquotaDomain属性として、クォータドメイン２（図５）のクォータドメイン識別子が指定されるようにする。
　このように、USBDメタデータにおいて、USD要素に、quotaDomain属性を定義することで、サービス単位で、クォータドメイン識別子を指定することが可能となる。
（Ｃ）S-TSIDメタデータに配置する場合
　キャッシュクォータドメインのクォータドメイン識別子が、S-TSIDメタデータの拡張により指定される場合、S-TSIDメタデータのRS要素のLS要素のsrcFlow要素のContentInfo要素に、quotaDomain属性を定義することで、対象のLCTセッションが属するキャッシュクォータドメインのクォータドメイン識別子を指定することが可能となる。
　このように、S-TSIDメタデータにおいて、RS要素のLS要素のsrcFlow要素のContentInfo要素に、quotaDomain属性を定義することで、LCTセッション単位で、クォータドメイン識別子を指定することが可能となる。
（Ｄ）ASTメタデータに配置する場合
　キャッシュクォータドメインのクォータドメイン識別子が、ASTメタデータの拡張により指定される場合、ASTメタデータのApplication要素のapplicationSpecificDescriptor要素のatsc:atscDescriptor要素に、quotaDomain属性を定義することで、対象のアプリケーションが属するキャッシュクォータドメインのクォータドメイン識別子を指定することが可能となる。
　このように、ASTメタデータにおいて、Application要素のapplicationSpecificDescriptor要素のatsc:atscDescriptor要素に、quotaDomain属性を定義することで、アプリケーション単位で、クォータドメイン識別子を指定することが可能となる。
　以上のように、SLTメタデータ、USBDメタデータ、S-TSIDメタデータ、又は、ASTメタデータを拡張して、クォータドメイン識別子を指定することで、同一のキャッシュクォータドメイン内で、サービス単位、LCTセッション単位、又は、アプリケーション単位で、リソース（ファイル）を共有させることができる。
　すなわち、図７に示すように、各サービスは、１又は複数のLCTセッションから構成され、各LCTセッションでは、例えば、DASHセグメントやアプリケーションのファイル、任意のファイルなどが伝送されている。
　ここで、図７に示すように、サービス単位でリソースを共有させたい場合には、SLTメタデータのサービスエントリ（サービスごとの基本属性）を拡張するか、又は、USBDメタデータのサービスごとの属性を拡張して、quotaDomain属性を定義するようにする。すなわち、対象のサービスで伝送されるファイルに対して、それらのファイルが格納されるローカルキャッシュの記憶領域を識別するためのクォータドメイン識別子が、SLTメタデータ又はUSBDメタデータのquotaDomain属性で指定される文字列に相当することになる。なお、この場合のファイルは、例えば、DASHセグメント、ピリオドファイル、又はアプリケーションなどのファイルであって、放送経由で取得されるファイルだけでなく、通信経由で取得されるファイルも含まれるものである。
　ただし、SLTメタデータ又はUSBDメタデータのquotaDomain属性により、サービスレベルで、キャッシュクォータドメイン（例えば、クォータドメイン１）が指定された場合に、対象のサービスに属するLCTセッションで伝送されるすべてのファイルについて、ローカルキャッシュ（の永続キャッシュ）にキャッシュすることが指示された場合には、すべてのファイルが、ローカルキャッシュのキャッシュクォータドメイン（例えば、クォータドメイン１）に割り当てられた記憶領域にキャッシュされる（図８のＡ（Ｂ））。
　なお、詳細は、図１５のSLTメタデータのフォーマットを参照して後述するが、SLTメタデータのservice要素には、SLSシグナリングのロケーション情報が指定される。そして、このロケーション情報は、SLSシグナリングが放送経由で取得される場合には、BroadcastSvcSignaling要素により指定され、SLSシグナリングが通信経由で取得される場合には、SvcInetUrl要素により指定される。例えば、USBDメタデータは、SLTメタデータのservice要素のロケーション情報に従い、放送経由又は通信経由で取得される。
　また、図７に示すように、LCTセッション単位でリソースを共有させたい場合には、S-TSIDメタデータのLCTセッションごとの属性を拡張して、quotaDomain属性を定義するようにする。すなわち、対象のLCTセッションで伝送されるファイルに対して、それらのファイルが格納されるローカルキャッシュの記憶領域を識別するためのクォータドメイン識別子が、S-TSIDメタデータのquotaDomain属性で指定される文字列に相当することになる。なお、この場合のファイルは、例えば、DASHセグメント、ピリオドファイル、又はアプリケーションなどのファイルである。
　ただし、S-TSIDメタデータのquotaDomain属性により、LCTセッションレベルで、キャッシュクォータドメイン（例えば、クォータドメイン１）が指定された場合には、対象のLCTセッションが属するサービスが、キャッシュクォータドメイン（例えば、クォータドメイン１）に属していると認識される。
　そして、キャッシュクォータドメイン(例えば、クォータドメイン１)が指定されたLCTセッションで伝送されるファイルについて、ローカルキャッシュ（の永続キャッシュ）にキャッシュすることが指示された場合には、それらのファイルが、ローカルキャッシュのキャッシュクォータドメイン(例えば、クォータドメイン１)の記憶領域にキャッシュされる（図８のＣ１）。一方で、キャッシュクォータドメイン（例えば、クォータドメイン１）が指定されたLCTセッションと同一のサービスに属するLCTセッションであっても、キャッシュクォータドメイン（例えば、クォータドメイン１）が指定されていないLCTセッションについては、永続キャッシュの対象外とされる（図８のＣ２）。
　なお、詳細は、図１６のUSBDメタデータのフォーマットを参照して後述するが、USBDメタデータのUSD要素のSTSIDUri属性には、S-TSIDメタデータの取得先を示すURI(Uniform Resource Identifier)が指定される。そして、このURIに従い、S-TSIDメタデータが取得される。
　また、図７に示すように、アプリケーション単位でリソースを共有させたい場合には、ASTメタデータのアプリケーションごとの属性を拡張して、quotaDomain属性を定義するようにする。すなわち、対象のASTメタデータの記述対象とするアプリケーションのファイルが格納されるローカルキャッシュの記憶領域を識別するためのクォータドメイン識別子が、ASTメタデータのquotaDomain属性で指定される文字列に相当することになる。
　ただし、ASTメタデータのquotaDomain属性により、アプリケーションレベルで、キャッシュクォータドメイン（例えば、クォータドメイン１）が指定された場合には、対象のアプリケーションが属するサービスが、キャッシュクォータドメイン（例えば、クォータドメイン１）に属していると認識される。
　そして、キャッシュクォータドメイン（例えば、クォータドメイン１）が指定されたアプリケーションのファイルについて、ローカルキャッシュ（の永続キャッシュ）にキャッシュすることが指示された場合には、それらのファイルが、ローカルキャッシュのキャッシュクォータドメイン(例えば、クォータドメイン１)の記憶領域にキャッシュされる（図８のＤ）。一方で、キャッシュクォータドメイン（例えば、クォータドメイン１）が指定されたアプリケーションと同一のサービスに属するアプリケーションであっても、キャッシュクォータドメイン（例えば、クォータドメイン１）が指定されていないアプリケーションについては、永続キャッシュの対象外とされる。
　以上のように、キャッシュクォータドメインの概念を導入して、キャッシュクォータドメインを識別するクォータドメイン識別子（リソース共有情報）を、SLT，USBD，S-TSID，AST等のメタデータ（制御情報）に含めて伝送することで、クライアント装置４０では、同一のキャッシュクォータドメインに属するサービスに含まれるファイル（リソース）を、ローカルキャッシュ（の永続キャッシュ）に保持して、サービス単位、LCTセッション単位、又は、アプリケーション単位で共有させることが可能となる。
＜３．アプリケーションの応用例＞
　次に、図９乃至図１４を参照して、第１のコンテンツ（放送番組）とともに伝送されるアプリケーションにより、第２のコンテンツ（広告）の挿入を行うシステムにおいて、キャッシュクォータドメインを実装する場合について説明する。なお、当該アプリケーションは、スクリプト（Script）を実行することで、広告挿入制御（Ad-Insertion）を行うものであるため、以下、スクリプトアプリケーション（Script App）と称して説明する。
（広告挿入の流れ）
　図９は、広告挿入の流れを説明する図である。
　図９においては、クライアント装置４０で、放送番組（BP1，BP2）の間に再生されるデフォルトの広告（TV1_Ad）の代わりに、ユーザに適合した広告（TV2_Ad）が挿入される場合の例を示している。
　図中の左側から右側の方向を時間の方向とした場合において、放送番組BP1が再生される時刻t1乃至時刻t2と、放送番組BP2が再生される時刻t3乃至時刻t4との間の時刻t2乃至時刻t3では、通常は、リアルタイムで取得される広告Ad1が再生される。
　また、この例では、デフォルトの広告Ad1と、挿入用の広告Ad2の２種類の広告が用意されているが、広告Ad2は、時刻t1乃至時刻t2で放送番組BP1-1が再生されているとき、すなわち、広告の挿入区間よりも時間的に前に、放送経由又は通信経由で取得され、ローカルキャッシュ（の永続キャッシュ）にキャッシュされている。
　クライアント装置４０では、放送番組BP1-2のシーンとなったとき、映像に、ユーザに対する質問が重畳表示される。そして、クライアント装置４０は、質問に対するユーザの回答に応じて、当該ユーザに適合した広告を表示させる。例えば、クライアント装置４０では、ユーザが質問に対して回答をした場合には、当該回答に応じた挿入用の広告Ad2が、ローカルキャッシュ（の永続キャッシュ）から読み出され、デフォルトの広告Ad1を、ユーザに適合した広告Ad2に差し替えて再生することになる。
　このように、ユーザにより視聴される可能性のある広告を、クライアント装置４０のローカルキャッシュ（の永続キャッシュ）にキャッシュしておくことで、そのキャッシュしていた広告を用いて、ユーザに適合した広告を表示させることができる。
　なお、図９の広告挿入の例では、ユーザの入力操作に応じて、当該ユーザに適合した広告のコンテンツが選択される例を示したが、このようなユーザとの間での情報のやりとり（インタラクション）のほか、例えば、ユーザのプリファレンスやプロファイル等のあらかじめ設定されたユーザの特性に関する情報（例えば、性別や年齢、居住地域等）などを用いて、広告のコンテンツが選択されるようにしてもよい。
　ところで、移動体通信システムの標準化プロジェクトである3GPP(Third Generation Partnership Project)や、DASH-IF(Industry Forum)においては、MPEG-DASHで規定されている、Period要素のXLinkによるパーソナライズされた広告挿入制御（Ad-Insertion）の実現方法が踏襲されているが、ATSC3.0においても、この広告挿入制御の実現方法が踏襲されることが想定されている。なお、XLinkは、XML文書同士のリンクを定義するための仕様であって、W3C(World Wide Web Consortium)により勧告されている。
　この広告挿入制御では、MPDメタデータの広告挿入区間に対応するPeriod要素を含むファイルをあらかじめ用意しておいて、広告のコンテンツのストリームに対応するセグメントを指定するPeriod要素を、ユーザの特性（例えば、ユーザプリファレンス等）に応じて動的に変更する方式を採用している。このような広告挿入制御に対応したクライアント装置４０が、図１０に示されている。
　図１０において、クライアント装置４０は、アプリケーション／コーデック機能と、DASHクライアント機能と、トランスポートスタック／HTTPサーバ機能を有している。また、トランスポートスタック／HTTPサーバ機能には、XLinkリゾルバ（XLink Resolver）と、HTTPプロキシキャッシュ（HTTP Proxy Cache）の機能が含まれる。ただし、XLinkリゾルバの機能は、通信サーバ３０のHTTPサーバが有するようにしてもよい。
　ここで、クライアント装置４０において、SLSシグナリングとして伝送されるMPDメタデータが受信された場合、MPDメタデータは、HTTPプロキシキャッシュにより取得され、DASHクライアントに通知される（Ｓ５１）。このMPDメタデータには、Period要素のxlink:href属性として、クライアント装置４０又は通信サーバ３０のHTTPサーバ上で稼働するXLinkリゾルバで解決されるURL(Uniform Resource Locator)が指定されている。
　具体的には、図１１に示すように、MPDメタデータに記述されたPeriod要素であるA1（Ad Break #1），M1（Main Program），A2（Ad Break #2），M2（Main Program），A3（Ad Break #3），M3（Main Program）のうち、A1（Ad Break #1）であるPeriod要素に注目すれば、xlink:href属性のURLとして、"http://adservice.com/adp-1?user=$groupID$"が記述されている。
　なお、A2（Ad Break #2）又はA3（Ad Break #3）においても、xlink:href属性のURLとして、"http://adservice.com/adp-1?user=$groupID$"が記述されており、A1（Ad Break #1）と同様に処理されるものとする。
　図１０の説明に戻り、クライアント装置４０においては、このURLのgroupIDのパラメタ部分に、ユーザを特定する値を挿入して、クライアント装置４０又は通信サーバ３０のHTTPサーバ上のXLinkリゾルバに、HTTPリクエストを発行することになる（Ｓ５２）。例えば、"http://adservice.com/adp-1?user=classA"のように、groupIDの値が挿入されたURLが、XLinkリゾルバに通知される。
　クライアント装置４０又は通信サーバ３０のXLinkリゾルバは、DASHクライアントから、groupIDの値が挿入されたURLが通知されると、groupIDにより指定される特定のユーザ（例えば、classAのユーザ）向けに生成されたURLを含むPeriod要素のファイル（以下、ピリオドファイルという）を、DASHクライアントに返信する（Ｓ５３）。このPeriod要素に含まれるURLは、一方向の放送経由の場合のROUTEプロトコルや、双方向の通信経由の場合のHTTPプロトコルにより配信されるセグメントのURL（セグメントURL）となる。
　そして、クライアント装置４０においては、DASHクライアントとHTTPプロキシキャッシュとが、ステップＳ５３の処理で取得されたピリオドファイルのPeriod要素に応じて、セグメントのリクエストやデリバリなどのやりとりを行うことで、当該Period要素のセグメントURLに応じたセグメントが取得される（Ｓ５４）。
　このようにして取得されるセグメントに応じた広告のコンテンツが、広告の挿入区間（例えば、図９の時刻t2乃至時刻t3の区間）で再生されることになる。
　より具体的には、図１２には、00:00:00～00:15:00の間に、M1（Main Program）が再生され、00:15:00～00:30:00の間に、M2（Main Program）が再生され、00:30:00～00:42:00の間に、M3（Main Program）が再生される場合において、M1の再生よりも時間的に前にA1（Ad Break #1）が挿入され、M1とM2の間にA2（Ad Break #2）が挿入され、M2とM3の間に、A3（Ad Break #3）が挿入されるときの広告挿入制御を例示している。
　この例では、A1（Ad Break #1）として、３種類の広告が用意されており、例えば30代の男性や60代の女性などのユーザの特性（例えば、ユーザプリファレンス等）に応じて、再生される広告の内容が、動的に変化することになる。同様に、A2（Ad Break #2）とA3（Ad Break #3）としても複数の広告が用意されており、ユーザの特性に応じた広告が再生されることになる。
　なお、図１０においては、クライアント装置４０又は通信サーバ３０のHTTPサーバ上で、XLinkリゾルバが稼働される例を説明したが、クライアント装置４０においては、スクリプトアプリケーションが、XLinkリゾルバの役割を担うようにすることができる。
　すなわち、DASHクライアントが、MPDメタデータをパース（構文解析）することで、広告挿入用のPeriod要素のxlink:href属性のURLを検出した場合に、直ちにHTTPリクエストを、HTTPサーバ上で稼働するXLinkリゾルバに送信するのではなく、そのURLを、スクリプトアプリケーションに通知するようにする。
　スクリプトアプリケーションは、DASHクライアントからURLが通知されると（XLinkの解決が要求されると）、当該URLのパス部分やクエリ文字列に反映されている広告挿入区間を識別するための情報に基づいて、その区間に対応する広告のコンテンツ（Adセグメント）の挿入候補のうち、対象のユーザに適合する広告のコンテンツ（Adセグメント）を選択する。
　そして、スクリプトアプリケーションは、選択した広告のコンテンツ（Adセグメント）に対応するPeriod要素を含むピリオドファイルを生成し、DASHクライアントに応答する。例えば、このピリオドファイルのPeriod要素は、groupIDにより指定される特定のユーザ（例えば、classAのユーザ）向けに生成されたURLを含み、このセグメントURLのリストに基づいて、Adセグメント群を再生すると、広告のコンテンツが再生されることになる。
　ここで、ユーザに適合した広告のコンテンツの選択であるが、例えば、クライアント装置４０で管理されるユーザプリファレンス等に応じて行われる場合もあれば、ユーザとの間で情報のやりとり（インタラクション）を行って、随時取得される情報に応じて行われるようにしてもよい。例えば、上述した図９の広告挿入の例では、ユーザの入力操作に応じて、当該ユーザに適合した広告のコンテンツが選択されている。
　このように、クライアント装置４０側で、MPDメタデータのPeriod要素のXLinkの解決が行われるようにすることで、通信サーバ３０のHTTPサーバ上で稼働するXLinkリゾルバに、XLinkの解決を依頼する必要がなくなることになる。
　そのため、通信サーバ３０のXLinkリゾルバでXLinkの解決を行うとした場合には、広告挿入区間の直前に、インターネット９０に接続された多数のクライアント装置４０からのアクセスが、通信サーバ３０に集中することが想定されるが、クライアント装置４０のXLinkリゾルバでXLinkの解決を行うことで、XLinkの解決のトランザクション処理の負荷増加の解消を図ることができる。
　また、クライアント装置４０では、スクリプトアプリケーションによって、広告挿入区間よりも時間的に前に、放送経由又は通信経由で取得される広告のコンテンツ（Adセグメント）の候補を、ローカルキャッシュ（の永続キャッシュ）にキャッシュしておくことで、広告挿入制御による広告挿入の確実性を担保することができる。例えば、広告のコンテンツ（Adセグメント）を通信経由で取得する場合には、インターネット９０の通信状況などにより、広告のコンテンツ（Adセグメント）を取得できないことも想定されるが、あらかじめキャッシュしておけば、広告挿入制御による広告挿入の確実性を高めることができる。
　さらに、本技術では、キャッシュクォータドメインの概念を導入し、クライアント装置４０において、複数のサービスで再利用される広告のコンテンツ（Adセグメント）のファイルを共有できるようにしているため、ローカルキャッシュ（の永続キャッシュ）にキャッシュされる広告のコンテンツ（Adセグメント）の候補の再利用性を高めて、より確実に、広告挿入制御による広告挿入を行うことができる。
（MPDの記述例）
　次に、図１３及び図１４を参照して、XML形式のMPDメタデータの記述例について説明する。
　なお、MPDメタデータでは、Period要素、AdaptationSet要素、及び、Representation要素が階層構造で記述されている。Period要素は、コンテンツ等のサービスの構成を記述する単位となる。また、AdaptationSet要素と、Representation要素は、ビデオやオーディオ、字幕等のサービスコンポーネントのストリームごとに利用され、それぞれのストリームの属性を記述できるようになっている。
　図１３のMPDメタデータの記述例では、本編のPeriod要素と、広告（Ad）のPeriod要素が記述されている。
　本編のPeriod要素には、本編のコンテンツ（MP4形式の動画ファイル）の再生を管理するための情報が記述されている。ただし、AssetIdentifier要素のschemeIdUri属性とvalue属性には、EIDR(Entertainment Identifier Registry)に対応したIDが付与されている。
　一方で、広告（Ad）のPeriod要素には、デフォルトの広告のコンテンツ（MP4形式の動画ファイル）の再生を管理するための情報とともに、Period要素のxlink:href属性にURLが記述されている（図中のＡ）。このURLが、通信サーバ３０のHTTPサーバ上で稼働するXLinkリゾルバに通知されることで、挿入用の広告が取得され、デフォルトの広告が、挿入用の広告に差し替えられる。
　図１４のMPDメタデータの記述例においても、本編のPeriod要素と、広告（Ad）のPeriod要素が記述されている。
　本編のPeriod要素には、本編のコンテンツ（MP4形式の動画ファイル）の再生を管理するための情報が記述されている。
　一方で、広告（Ad）のPeriod要素には、デフォルトの広告のコンテンツ（MP4形式の動画ファイル）の再生を管理するための情報とともに、Period要素のxlink:href属性にURLが記述されている（図中のＡ）。ここでは、groupIDの値が挿入されたURLが、クライアント装置４０のHTTPサーバ上で稼働するXLinkリゾルバに通知されることで、groupIDにより指定される特定のユーザに適合した広告が取得され、デフォルトの広告が、ユーザに適合した広告に差し替えられる。なお、図中のＡにおいて、"urn:atsc:ad-insertion"は、広告挿入制御の解決を、ローカル（クライアント装置４０）で実行されるスクリプト（スクリプトアプリケーション）に依頼しなければならないことを示すものであるが、その詳細な内容は後述するものとする。
　なお、上述した説明では、広告のコンテンツを一例に説明し、キャッシュクォータドメインを用いて、複数のサービスで、広告のコンテンツ（Adセグメント）のファイルを共有できるとしたが、本技術は、広告以外の他のコンテンツに適用することもできる。また、ファイルは、コンテンツのリソースの一例であり、クライアント装置４０が処理可能なデータであれば、あらゆるデータを対象とすることができる。
＜４．シグナリングの例＞
　次に、図１５乃至図２１を参照して、キャッシュクォータドメインを識別するクォータドメイン識別子を伝送するシグナリングのフォーマットの例を説明する。
（SLTのフォーマット）
　図１５は、XML形式のSLTメタデータのフォーマットの例を示す図である。なお、図１５において、要素と属性のうち、属性には「@」が付されている。また、インデントされた要素と属性は、その上位の要素に対して指定されたものとなる。これらの関係は、後述する他のシグナリングのフォーマットでも同様とされる。
　SLT要素は、ルート要素であって、bsid属性、sltCapabilities属性、sltInetUrl要素、及び、Service要素の上位要素となる。
　bsid属性には、ブロードキャストストリームIDが指定される。sltCapabilities属性には、必要とされる機能に関する情報が指定される。
　sltInetUrl要素には、ESGやSLSシグナリングを取得するためのベースURLが指定される。sltInetUrl要素は、urlType属性の上位要素となる。urlType属性には、ベースURLで利用可能なファイルの種類が指定される。
　Service要素には、１又は複数のサービスに関する情報が指定される。Service要素は、serviceId属性、sltSvcSeqNum属性、protected属性、majorChannelNo属性、minorChannelNo属性、serviceCategory属性、shortServiceName属性、hidden属性、broadbandAccessRequired属性、svcCapabilities属性、quotaDomain属性、BroadcastSvcSignaling要素、及び、svcInetUrl要素の上位要素となる。
　serviceId属性には、サービスIDが指定される。sltSvcSeqNum属性には、SLTメタデータのバージョンに関する情報が指定される。protected属性には、サービスの保護を示す暗号化情報が指定される。
　majorChannelNo属性には、メジャーチャネル番号が指定される。minorChannelNo属性には、マイナーチャネル番号が指定される。serviceCategory属性には、サービスのカテゴリが指定される。shortServiceName属性には、ショートサービス名が指定される。
　hidden属性には、サービスが、隠されたサービスであるかどうかが指定される。broadbandAccessRequired属性には、インターネット９０等の通信回線にアクセスする必要があるかどうかが指定される。svcCapabilities属性には、デコードに必要な機能などの情報が指定される。
　quotaDomain属性には、対象のサービスが属しているキャッシュクォータドメインのクォータドメイン識別子が指定される。同一のキャッシュクォータドメインに属するサービスでは、ローカルメモリにキャッシュされるリソース（ファイル）が共有されることになる。
　BroadcastSvcSignaling要素には、SLSシグナリングが放送経由で取得される場合に、当該SLSシグナリングの取得先に関する情報が指定される。BroadcastSvcSignaling要素は、slsProtocol属性、slsMajorProtocolVersion属性、slsMinorProtocolVersion属性、slsPlpId属性、slsDestinationIpAddress属性、slsDestinationUdpPort属性、及び、slsSourceIpAddress属性の上位要素となる。
　slsProtocol属性には、SLSシグナリングのプロトコルに関する情報が指定される。slsMajorProtocolVersion属性には、SLSシグナリングのプロトコルのメジャーバージョン番号が指定される。slsMinorProtocolVersion属性には、SLSシグナリングのプロトコルのマイナーバージョン番号が指定される。
　slsPlpId属性には、SLSシグナリングが伝送されるPLP(Physical Layer Pipe)のIDが指定される。slsDestinationIpAddress属性には、SLSシグナリングの宛先（destination）のIPアドレスが指定される。slsDestinationUdpPort属性には、SLSシグナリングの宛先（destination）のポート番号が指定される。slsSourceIpAddress属性には、SLSシグナリングの送信元（source）のIPアドレスが指定される。
　svcInetUrl要素には、SLSシグナリングが通信経由で取得される場合に、当該SLSシグナリングの取得先のURLが指定される。svcInetUrl要素は、urlType属性の上位要素となる。urlType属性には、このURLで利用可能なファイルの種類が指定される。
　なお、図１５において、出現数（Use）であるが、"1"が指定された場合にはその要素又は属性は必ず１つだけ指定され、"0..1"が指定された場合には、その要素又は属性を指定するかどうかは任意である。また、"1..N"が指定された場合には、その要素又は属性は１以上指定され、"0..N"が指定された場合には、その要素又は属性を１以上指定するかどうかは任意である。
　また、Data Typeとして、"unsignedShort"又は"unsignedByte"が指定された場合、その要素又は属性の値が、整数型であることを示している。Data Typeとして、"string"が指定された場合には、その要素又は属性の値が、文字列型であることを示し、"anyURI"が指定された場合、その要素又は属性の値が、URIの形式をした文字列であることを示している。Data Typeとして、"boolean"が指定された場合には、その要素又は属性がブール型であることを示している。なお、Data Typeとして、"language"が指定された場合、その要素又は属性の値が、xml:lang属性の値として有効なものであることを示し、"dateTime"が指定された場合、その要素又は属性の値が、特定の日時であることを示すものとする。
（USBDのフォーマット）
　図１６は、XML形式のUSBDメタデータのフォーマットの例を示す図である。
　bundleDescription要素は、ルート要素であって、userServiceDescription要素（USD要素）の上位要素となる。このuserServiceDescription要素は、globalServiceID属性、serviceId属性、serviceStatus属性、fullMPDUri属性、sTSIDUri属性、quotaDomain属性、name要素、serviceLanguage要素、capabilityCode要素、deliveryMethod要素の上位要素となる。
　globalServiceID属性には、グローバルサービスIDが指定される。serviceId属性には、サービスIDが指定される。serviceStatus属性には、サービスのステータスに関する情報が指定される。fullMPDUri属性には、MPDメタデータを参照するためのURIが指定される。sTSIDUri属性には、S-TSIDメタデータを参照するためのURIが指定される。
　quotaDomain属性には、対象のサービスが属しているキャッシュクォータドメインのクォータドメイン識別子が指定される。同一のキャッシュクォータドメインに属するサービスでは、ローカルメモリにキャッシュされるリソース（ファイル）が共有されることになる。
　name要素には、ATSC3.0のサービスの名称が指定される。name要素は、lang属性の上位要素となる。lang属性には、ATSC3.0のサービスの名称の言語が指定される。serviceLanguage要素には、ATSC3.0のサービスで利用できる言語が指定される。capabilityCode要素には、機能に関するコードが指定される。
　deliveryMethod要素には、データの配信方法に関する情報が指定される。deliveryMethod要素は、broadcastAppService要素及びunicastAppService要素の上位要素となる。broadcastAppService要素は、basePattern要素の上位要素であって、放送経由での配信に関する情報が指定される。unicastAppService要素は、basePattern要素の上位要素であって、通信経由での配信に関する情報が指定される。
（S-TSIDのフォーマット）
　図１７は、S-TSIDメタデータのフォーマットの例を示す図である。
　S-TSID要素は、ルート要素であって、serviceId属性及びRS要素の上位要素となる。serviceId属性には、サービスIDが指定される。
　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要素には、ソースフロー情報が指定される。なお、このSrcFlow要素の詳細な内容は、図１８を参照して後述する。RprFlow要素には、リペアフロー情報が指定される。
（SrcFlow要素のフォーマット）
　図１８は、図１７のS-TSIDメタデータに含まれるSrcFlow要素のフォーマットの例を示す図である。
　SrcFlow要素は、rt属性、minBuffSize属性、EFDT要素、ContentInfo要素、及び、Payload要素の上位要素となる。minBuffSize属性には、クライアント装置４０が必要とする最小バッファサイズが指定される。
　EFDT要素には、拡張されたFDT（Extended FDT）に関する情報が指定される。ContentInfo要素には、コンテンツに関する情報が指定される。ContentInfo要素は、quotaDomain属性の上位要素となる。
　quotaDomain属性には、対象のLCTセッションを含むサービスが属しているキャッシュクォータドメインのクォータドメイン識別子が指定される。同一のキャッシュクォータドメインに属するサービスでは、ローカルメモリにキャッシュされるリソース（ファイル）が共有されることになる。
　Payload要素は、codePoint属性、formatID属性、frag属性、order属性、srcFecPayloadID属性、及び、FECParams属性の上位要素であって、ソースフローのオブジェクトを格納するROUTEパケットのペイロードに関する情報が指定される。
（ASTのフォーマット）
　図１９乃至図２１は、ASTメタデータのフォーマットの例を示す図である。
　ApplicationList要素は、ルート要素であって、Application要素及びApplicationReference要素の上位要素となる。
　Application要素には、アプリケーションに関する情報が指定される。Application要素は、appName要素、applicationIdentifier要素、applicationDescriptor要素、applicationUsageDescriptor要素、applicationBoundary要素、applicationTransport要素、applicationLocation要素、及び、applicationSpecificDescriptor要素の上位要素となる。
　appName要素は、Language属性の上位要素であって、アプリケーションの名称が指定される。applicationIdentifier要素は、orgID要素及びappIDの上位要素であって、アプリケーションのアプリケーションIDが指定される。
　applicationDescriptor要素は、type要素、controlCode要素、visibility要素、serviceBound要素、priority要素、version要素、icon要素、及び、storageCapabilities要素の上位要素であって、対象のアプリケーションのプロパティに関する情報が指定される。
　applicationUsageDescriptor要素は、ApplicationUsage要素の上位要素であって、アプリケーションのUsageタイプに関する情報が指定される。applicationBoundary要素には、アプリケーションのバウンダリに関する情報が指定される。applicationTransport要素には、アプリケーションのトランスポートプロトコルに関する情報が指定される。
　トランスポートタイプが、HTTPの場合には、URLBase要素及びURLExtension要素が配置され、URLが指定される。URLExtension要素には、拡張URLが指定される。また、トランスポートタイプが、ROUTEの場合には、atsc:ROUTESessionInfo要素（LCTSession要素、tsi属性、plpID属性を含む）、broadcastStreamId属性、plpID属性、sourceIpAddress属性、destinationIpAddress属性、及び、destinationPort属性が配置され、ROUTEセッションに関する情報が指定される。
　applicationLocation要素には、アプリケーションのロケーション情報が指定される。applicationSpecificDescriptor要素には、アプリケーションの記述子が配置される。この記述子としては、DVB(Digital Video Broadcasting)に対応したdvbDescriptor、HTML(HyperText Markup Language)に対応したhtmlDescriptor、ATSCに対応したatscDescriptor、又は、その他の規格に対応したotherDescriptorが選択的に配置される。
　atsc:atscDescriptor要素は、quotaDomain属性、size要素、requiredCapabilities要素、icon要素、ApplicationRecordingDescriptor要素、timeSlotInfo要素、contentLinkage要素、contentItem要素、及び、graphicConstraintsDescriptorの上位要素であって、ATSC（ATSC3.0）に関する情報が指定される。
　quotaDomain属性は、対象のアプリケーションを含むサービスが属しているキャッシュクォータドメインのクォータドメイン識別子が指定される。同一のキャッシュクォータドメインに属するサービスでは、ローカルメモリにキャッシュされるリソース（ファイル）が共有されることになる。
　ただし、icon要素は、filename属性、size属性、及び、aspectRatio属性を含む。また、ApplicationRecordingDescriptor要素は、scheduled_recording_flag要素、trick_mode_aware_flag要素、time_shift_flag要素、dynamic_flag要素、av_synced_flag要素、initiating_replay_flag要素、及び、storage_properties要素を含む。さらに、timeSlotInfo要素は、timeslot_type要素、timeslot_start要素、timeslot_length要素、acquisition_time要素、及び、repeat_period要素を含む。
　また、contentItem要素は、location属性、contentLinkage属性、updatesAvailable属性、size属性、及び、timeSlotInfo要素を含む。このtimeSlotInfo要素は、timeslot_type要素、timeslot_start要素、timeslot_length要素、acquisition_time要素、及び、repeat_period要素を含む。graphicConstraintsDescriptor要素は、can_run_without_visible_ui要素、handles_configuration_changed要素、handles_externally_controlled_video要素、graphics_configuration_byte要素、及び、screenPosition要素を含む。
　なお、図１５乃至図２１を参照して説明したSLTメタデータ、USBDメタデータ、S-TSID、及び、ASTメタデータのフォーマットは一例であって、例えば、他の要素や属性を追加するなど、その一部を変更したフォーマットが採用されるようにしてもよい。また、SLTメタデータ、USBDメタデータ、S-TSID、及び、ASTメタデータは、XML形式に限らず、他のマークアップ言語により記述してもよいし、あるいはセクション形式であってもよい。
　また、SLTメタデータ、USBDメタデータ、S-TSID、及び、ASTメタデータ等のシグナリングを拡張することで追加されるquotaDomain属性により指定されるクォータドメイン識別子は、１種類のメタデータに含めるようにしてもよいし、複数種類のメタデータに含めるようにしてもよい。また、複数のサービスが提供される場合に、サービスごとに異なる種類のメタデータに、quotaDomain属性により指定されるクォータドメイン識別子が記述されるようにしてもよい。さらに、上述した各メタデータのフォーマットの例では、クォータドメイン識別子が、quotaDomain属性により指定される場合を一例に説明したが、クォータドメイン識別子は、属性に限らず、例えば、要素や、テキストとして記述された情報などにより指定されるようにしてもよい。
＜５．各装置の構成＞
　次に、図２２乃至図２５を参照して、図１の伝送システム１における、送信側のAd/DASHサーバ１０、放送サーバ２０、及び、通信サーバ３０と、受信側のクライアント装置４０の構成について説明する。
（Ad/DASHサーバの構成）
　図２２は、図１のAd/DASHサーバ１０の構成例を示す図である。
　図２２において、Ad/DASHサーバ１０は、受信部１０１、Ad/DASHセグメント生成部１０２、スクリプトアプリケーション生成部１０３、MPD生成部１０４、処理部１０５、及び、送信部１０６から構成される。
　受信部１０１は、外部のサーバ（不図示）などからストリーミング配信用のデータを受信し、Ad/DASHセグメント生成部１０２、スクリプトアプリケーション生成部１０３、及び、MPD生成部１０４に供給する。
　Ad/DASHセグメント生成部１０２は、受信部１０１から供給されるデータに基づいて、Adセグメント及びDASHセグメントを生成し、処理部１０５に供給する。
　ここで、Adセグメントは、広告のコンテンツを処理して得られるセグメントファイルである。また、DASHセグメントは、中継場所から伝送路や通信回線を介して送られてくるライブコンテンツ（例えば、スポーツ中継等の生放送番組）や、ストレージに蓄積された収録済みのコンテンツ（例えば、ドラマ等の事前収録番組）などのコンテンツを処理して得られるセグメントファイルである。なお、Adセグメントは、DASHセグメントの一種であるとも言えるが、ここでは、説明の都合上、AdセグメントとDASHセグメントとを区別して説明する。
　スクリプトアプリケーション生成部１０３は、受信部１０１から供給されるデータに基づいて、スクリプトアプリケーションを生成し、処理部１０５に供給する。ここで、スクリプトアプリケーションは、スクリプト（Script）を実行可能なアプリケーションである。このスクリプトアプリケーションは、例えば、HTML5等のマークアップ言語や、JavaScript（登録商標）等のスクリプト言語で開発されたアプリケーションとすることができる。
　MPD生成部１０４は、受信部１０１から供給されるデータに基づいて、MPDメタデータを生成し、処理部１０５に供給する。ここで、MPDメタデータには、番組や広告等のコンテンツに対応したPeriod要素が記述されるが、その詳細な内容は後述する。
　処理部１０５は、Ad/DASHセグメント生成部１０２から供給されるAdセグメント及びDASHセグメントと、スクリプトアプリケーション生成部１０３から供給されるスクリプトアプリケーションと、MPD生成部１０４から供給されるMPDメタデータに対して、必要な処理を施し、送信部１０６に供給する。
　送信部１０６は、処理部１０５から供給されるデータを、放送サーバ２０又は通信サーバ３０に送信する。なお、ここでは、Adセグメント及びDASHセグメント、スクリプトアプリケーション、並びに、MPDメタデータのデータ（ファイル）のうち、放送経由で配信されるデータが放送サーバ２０に送信され、通信経由で配信されるデータが通信サーバ３０に送信される。
　Ad/DASHサーバ１０は、以上のように構成される。
（放送サーバの構成）
　図２３は、図１の放送サーバ２０の構成例を示す図である。
　図２３において、放送サーバ２０は、受信部２０１、シグナリング生成部２０２、処理部２０３、及び、送信部２０４から構成される。
　受信部２０１は、Ad/DASHサーバ１０から送信されてくる、Adセグメント及びDASHセグメント、スクリプトアプリケーション、並びに、MPDメタデータを受信し、処理部２０３に供給する。ただし、ここでは、Adセグメント及びDASHセグメント、スクリプトアプリケーション、及び、MPDメタデータのすべてが、Ad/DASHサーバ１０から提供されるとは限らず、放送経由で配信されるデータ（ファイル）のみが提供され、受信部２０１により受信される。
　また、受信部２０１は、外部のサーバ（不図示）などからNRTコンテンツのデータ（ファイル）を受信し、処理部２０３に供給する。
　シグナリング生成部２０２は、シグナリングを生成し、処理部２０３に供給する。ここで、シグナリングには、SLTメタデータ等のLLSシグナリングと、USBDメタデータ、S-TSIDメタデータ、及び、ASTメタデータ等のSLSシグナリングが含まれる。また、複数のサービスで、リソース（ファイル）を共有させる場合には、SLTメタデータ、USBDメタデータ、S-TSIDメタデータ、又はASTメタデータに定義されたquotaDomain属性に、対象のキャッシュクォータドメインのクォータドメイン識別子が指定されることになる。
　処理部２０３は、受信部２０１から供給されるAdセグメント及びDASHセグメント、スクリプトアプリケーション、MPDメタデータ、並びにNRTコンテンツと、シグナリング生成部２０２から供給されるシグナリングに対して、必要な処理を施し、送信部２０４に供給する。ここでは、例えば、Adセグメント及びDASHセグメント、スクリプトアプリケーション、NRTコンテンツ、並びに、SLSシグナリング（USBDメタデータやMPDメタデータ等）を含むLCTセッションのデータをペイロードに格納したIP/UDPパケットと、LLSシグナリング（SLTメタデータ等）のデータをペイロードに格納したIP/UDPパケットを生成するための処理などが行われる。
　送信部２０４は、処理部２０３から供給されるデータに対応する放送波（デジタル放送信号）を、アンテナ２１１によって、伝送路８０を介して送信（一斉同報配信）する。
　放送サーバ２０は、以上のように構成される。
（通信サーバの構成）
　図２４は、図１の通信サーバ３０の構成例を示す図である。
　図２４において、通信サーバ３０は、受信部３０１、ピリオドファイル生成部３０２、処理部３０３、及び、通信部３０４から構成される。
　受信部３０１は、Ad/DASHサーバ１０から送信されてくる、Adセグメント及びDASHセグメント、スクリプトアプリケーション、並びに、MPDメタデータを受信し、処理部３０３に供給する。ただし、ここでは、Adセグメント及びDASHセグメント、スクリプトアプリケーション、及び、MPDメタデータのすべてが、Ad/DASHサーバ１０から提供されるとは限らず、通信経由で配信されるデータ（ファイル）のみが提供され、受信部３０１により受信される。
　処理部３０３は、通信部３０４により受信されたクライアント装置４０からの要求（XLinkの解決要求）に応じて、受信部３０１から供給されるデータを処理し、通信部３０４に供給する。通信部３０４は、クライアント装置４０からの要求に応じて、処理部３０３から供給されるデータ（Adセグメント及びDASHセグメント、スクリプトアプリケーション、並びに、MPDメタデータのうちの少なくとも１つのデータ）を、インターネット９０を介して、当該データの要求元のクライアント装置４０宛てに送信する。
　処理部３０３は、通信部３０４により受信されたクライアント装置４０からの要求に応じて、ピリオドファイルの生成を、ピリオドファイル生成部３０２に要求する。ピリオドファイル生成部３０２は、処理部３０３からの要求に応じて、クライアント装置４０を使用しているユーザ（の特性）に応じたPeriod要素を含むピリオドファイルを生成し、処理部３０３に供給する。
　処理部３０３は、ピリオドファイル生成部３０２から供給されるピリオドファイルを処理し、通信部３０４に供給する。通信部３０４は、処理部３０３から供給されるピリオドファイルを、インターネット９０を介して、XLinkの解決要求の要求元のクライアント装置４０宛てに送信する。
　通信サーバ３０は、以上のように構成される。
（クライアント装置の構成）
　図２５は、図１のクライアント装置４０の構成例を示す図である。
　図２５において、クライアント装置４０は、制御部４０１、受信部４０２、放送ミドルウェア４０３、ローカルキャッシュ４０４、ブラウザ４０５、出力部４０６、及び、通信部４０７から構成される。
　制御部４０１は、クライアント装置４０の各部の動作を制御する。
　受信部４０２は、アンテナ４１１によって、放送サーバ２０から伝送路８０を介して送信（一斉同報配信）されてくる放送波（デジタル放送信号）を受信して処理し、それにより得られるデータを、放送ミドルウェア４０３に供給する。なお、受信部４０２は、チューナなどから構成される。
　放送ミドルウェア４０３は、受信部４０２から供給されるデータを処理し、制御部４０１又はローカルキャッシュ４０４に供給する。ここで、処理対象のデータのうち、Adセグメント及びDASHセグメント、スクリプトアプリケーション、並びにMPDメタデータは、ローカルキャッシュ４０４に供給される。また、シグナリングは、制御部４０１に供給される。
　制御部４０１は、キャッシュ制御部４０１Ａ及び再生制御部４０１Ｂを含む。キャッシュ制御部４０１Ａは、放送ミドルウェア４０３から供給されるシグナリングや、ブラウザ４０５からの要求などに基づいて、ローカルキャッシュ４０４を制御する。また、再生制御部４０１Ｂは、放送ミドルウェア４０３から供給されるシグナリングなどに基づいて、ブラウザ４０５を制御する。
　ローカルキャッシュ４０４は、例えば、オンメモリ（On Memory）やSSD(Solid State Drive)などのローカルなファイルシステム上で実現される。
　ローカルキャッシュ４０４は、キャッシュ制御部４０１Ａからの制御に従い、放送ミドルウェア４０３から供給されるデータ（ファイル）をキャッシュする。このローカルキャッシュ４０４には、Adセグメント及びDASHセグメント、スクリプトアプリケーション、並びにMPDメタデータなどのデータがキャッシュされる。また、ローカルキャッシュ４０４は、通常キャッシュ４０４Ａ及び永続キャッシュ４０４Ｂを含む。
　ここで、通常キャッシュ４０４Ａは、通常のキャッシュであって、そこにキャッシュされたデータは、しかるべき時間（それほど長くない時間）を経過した後に消去される。一方で、永続キャッシュ４０４Ｂは、特別なキャッシュであって、そこにキャッシュされるデータは、優先的な永続性を持ち、通常キャッシュ４０４Ａにキャッシュされるデータよりも長い時間キャッシュされることになる。
　キャッシュ制御部４０１Ａは、放送ミドルウェア４０３からのシグナリング（に含まれるSLTメタデータ、USBDメタデータ、S-TSIDメタデータ、又はASTメタデータに定義されたquotaDomain属性）に、（キャッシュクォータドメインの）クォータドメイン識別子が指定されている場合であって、ブラウザ４０５（のスクリプト実行部４０５Ａ）から、対象のAdセグメントやDASHセグメント等の永続キャッシュ４０４Ｂへの引き込み要求があったとき、対象のAdセグメントやDASHセグメント等（のファイル）を、通常キャッシュ４０４Ａから永続キャッシュ４０４Ｂに引き込む。
　これにより、永続キャッシュ４０４ＢにキャッシュされるAdセグメントやDASHセグメント等のファイル群は、クォータドメイン識別子により紐付けられているので、同一のキャッシュクォータドメインに属する複数のサービスにおいて、AdセグメントやDASHセグメント等のファイルを共有することが可能となる。
　ブラウザ４０５は、HTML5やJavaScript（登録商標）等に対応したブラウザである。ブラウザ４０５は、再生制御部４０１Ｂからの制御に従い、ローカルキャッシュ４０４から読み出したデータ（ファイル）を処理する。ブラウザ４０５は、スクリプト実行部４０５Ａ及びDASHクライアント４０５Ｂを含む。
　スクリプト実行部４０５Ａは、JavaScript（登録商標）等のスクリプト言語で記述されたスクリプトを実行することができる。例えば、スクリプト実行部４０５Ａは、ローカルキャッシュ４０４（の通常キャッシュ４０４Ａ又は永続キャッシュ４０４Ｂ）からスクリプトアプリケーションを読み出して、実行することができる。
　また、スクリプト実行部４０５Ａは、スクリプトアプリケーションに記述されたCacheStorage API(Application Programming Interface)を実行することで、キャッシュ制御部４０１Ａによるローカルキャッシュ４０４の制御を実行させる。なお、CacheStorage APIの詳細な内容については後述する。さらに、スクリプト実行部４０５Ａは、DASHクライアント４０５ＢからのXLinkの解決要求に応じて、ユーザプリファレンス等に応じたピリオドファイルを生成し、DASHクライアント４０５Ｂに応答する。
　DASHクライアント４０５Ｂは、ローカルキャッシュ４０４（の通常キャッシュ４０４Ａ）からMPDメタデータ（のファイル）を読み出してパース（構文解析）する。DASHクライアント４０５Ｂは、MPDメタデータの解析結果に従い、ローカルキャッシュ４０４（の通常キャッシュ４０４Ａ又は永続キャッシュ４０４Ｂ）から、Adセグメント又はDASHセグメント（のファイル）を読み出して再生する。
　DASHクライアント４０５Ｂにより再生されたAdセグメント又はDASHセグメントのデータは、出力部４０６に供給される。出力部４０６は、再生制御部４０１Ｂからの制御に従い、DASHクライアント４０５Ｂから供給されるデータを出力する。これにより、放送番組や広告等のコンテンツが再生され、その映像や音声が出力されることになる。
　通信部４０７は、制御部４０１からの制御に従い、インターネット９０を介して、通信サーバ３０とデータのやりとりを行う。通信部４０７により受信されるデータのうち、Adセグメント及びDASHセグメント、スクリプトアプリケーション、並びにMPDメタデータは、ローカルキャッシュ４０４に供給される。また、シグナリングは、制御部４０１に供給される。これらの通信経由で取得されたデータに対する処理は、上述した放送経由で取得されたデータと同様であるため、その説明は省略する。
　クライアント装置４０は、以上のように構成される。
＜６．各装置で実行される処理の流れ＞
　次に、図２６乃至図２８のフローチャートを参照して、図１の伝送システム１の各装置で実行される処理の流れについて説明する。
（送信側の処理の流れ）
　まず、図２６のフローチャートを参照して、送信側のAd/DASHサーバ１０、放送サーバ２０、及び、通信サーバ３０により実行される処理の流れを説明する。
　なお、図２６において、ステップＳ１０１乃至Ｓ１０６の処理は、Ad/DASHサーバ１０により実行され、ステップＳ２０１乃至Ｓ２０５の処理は、放送サーバ２０により実行され、ステップＳ３０１乃至Ｓ３０２の処理は、通信サーバ３０により実行される。
　ステップＳ１０１において、Ad/DASHサーバ１０のAd/DASHセグメント生成部１０２は、Adセグメント及びDASHセグメントを生成する。また、ステップＳ１０２において、Ad/DASHサーバ１０の送信部１０６は、ステップＳ１０１の処理で生成されたAdセグメント及びDASHセグメントを、放送サーバ２０に送信する。
　ここで、Adセグメントは、広告のコンテンツを処理して得られるセグメントファイルである。また、DASHセグメントは、放送番組のコンテンツを処理して得られるセグメントファイルである。ここでは、説明の都合上、AdセグメントとDASHセグメントが同時に生成される場合を説明するが、これらのセグメントは、異なるタイミングで生成されるようにしてもよい。
　ステップＳ２０１において、放送サーバ２０のシグナリング生成部２０２は、シグナリングを生成する。ステップＳ２０２において、放送サーバ２０の送信部２０４は、ステップＳ２０１の処理で生成されたシグナリングを、伝送路８０を介して送信（一斉同報配信）する。
　ここで、シグナリングとしては、SLTメタデータ等のLLSシグナリングと、USBDメタデータ等のSLSシグナリングが生成される。また、複数のサービスで、リソース（ファイル）を共有させる場合には、SLTメタデータ、USBDメタデータ、S-TSIDメタデータ、又はASTメタデータに定義されたquotaDomain属性に、対象のキャッシュクォータドメインのクォータドメイン識別子が指定されることになる。
　また、放送サーバ２０においては、ステップＳ２０２の処理で送信されたAdセグメント及びDASHセグメントが、受信部２０１により受信される。そして、ステップＳ２０３において、放送サーバ２０の送信部２０４は、Ad/DASHサーバ１０により生成されたAdセグメント及びDASHセグメントを、伝送路８０を介して送信（一斉同報配信）する。
　ステップＳ１０３において、Ad/DASHサーバ１０のスクリプトアプリケーション生成部１０３は、スクリプトアプリケーションを生成する。ステップＳ１０４において、Ad/DASHサーバ１０の送信部１０６は、ステップＳ１０３の処理で生成されたスクリプトアプリケーションを、放送サーバ２０に送信する。
　放送サーバ２０においては、ステップＳ１０４の処理で送信されたスクリプトアプリケーションが、受信部２０１により受信される。そして、ステップＳ２０４において、放送サーバ２０の送信部２０４は、Ad/DASHサーバ１０により生成されたスクリプトアプリケーションを、伝送路８０を介して送信（一斉同報配信）する。
　ステップＳ１０５において、Ad/DASHサーバ１０のMPD生成部１０４は、MPDメタデータを生成する。ステップＳ１０６において、Ad/DASHサーバ１０の送信部１０６は、ステップＳ１０５の処理で生成されたMPDメタデータを、放送サーバ２０に送信する。
　ここで、MPDメタデータにおいては、放送番組と広告のPeriod要素が記述されるが、例えば、広告のPeriod要素には、xlink:href属性として、"urn:atsc:ad-insertion:abc:1234"であるURLが記述されるようにする。ただし、このURLにおいて、"urn:atsc:ad-insertion"は、広告挿入制御の解決を、ローカル（クライアント装置４０）で実行されるスクリプト（スクリプトアプリケーション）に依頼しなければならないことを示すものとする。
　すなわち、MPEG-DASHの規定では、通常の"http:"から開始される文字列からなるURLを、MPDメタデータのPeriod要素のxlink:href属性に記述することで、クライアント装置４０は、この"http:・・・"で指定される、インターネット９０上の通信サーバ３０に問い合わせることになる。そして、クライアント装置４０は、通信サーバ３０からの応答として、ピリオドファイルを受信し、当該ピリオドファイルに含まれるPeriod要素の内容に基づいて、広告のコンテンツ（Adセグメント）を再生することになる。
　その一方で、この例では、"http:"から開始される文字列からなるURLではなく、"urn:atsc:ad-insertion"から開始される文字列からなるURN(Uniform Resource Name)を、MPDメタデータのPeriod要素のxlink:href属性に記述するようにする。これにより、クライアント装置４０では、MPDメタデータをパース（構文解析）した際に、"urn:atsc:ad-insertion"で開始される文字列が指定されたxlink:href属性を有するPeriod要素が検出された場合には、HTTPリクエストを発行するのではなく、同時に実行されているスクリプトアプリケーションに対して、XLinkの解決（Period要素の解決）を促すイベントを発行することになる。
　なお、この例では、MPDメタデータにおいて、Period要素のxlink:href属性に、"urn:atsc:ad-insertion"から開始される文字列からなるURNが指定される場合を主に説明するが、上述したように、"http://adservice.com/adp-1?user=$groupID$"などのURLを指定し、groupIDにより特定のユーザが指定されるようにしてもよい。
　放送サーバ２０においては、ステップＳ１０６の処理で送信されたMPDメタデータが、受信部２０１により受信される。そして、ステップＳ２０５において、放送サーバ２０の送信部２０４は、Ad/DASHサーバ１０により生成されたMPDメタデータを、伝送路８０を介して送信（一斉同報配信）する。
　なお、説明の都合上、ステップＳ２０２乃至Ｓ２０５においては、シグナリング、Adセグメント及びDASHセグメント、スクリプトアプリケーション、及び、MPDメタデータが、異なるタイミングで送信されるものとして説明したが、これらのデータは、放送ストリームに含められ、送信されることになる。
　通信サーバ３０においては、インターネット９０を介して、クライアント装置４０から送信されてくる、XLinkの解決要求が通信部３０４により受信される。そして、ステップＳ３０１において、通信サーバ３０のピリオドファイル生成部３０２は、ピリオドファイルを生成する。ステップＳ３０２において、通信サーバ３０の通信部３０４は、ステップＳ３０１の処理で生成されたピリオドファイルを、インターネット９０を介して、XLinkの解決要求の送信元のクライアント装置４０宛てに送信する。
　なお、このように、クライアント装置４０から通信サーバ３０に対して、XLinkの解決要求が送信されるのは、"http:"から開始される文字列からなるURLが、MPDメタデータのPeriod要素のxlink:href属性に記述された場合である。
　以上、送信側の処理の流れについて説明した。
（受信側の処理の流れ）
　次に、図２７及び図２８のフローチャートを参照して、受信側のクライアント装置４０により実行される処理の流れを説明する。
　なお、図２７及び図２８において、ステップＳ４０１乃至Ｓ４０８の処理は、放送ミドルウェア４０３により実行され、ステップＳ４２１乃至Ｓ４２３の処理、及び、ステップＳ４４１乃至Ｓ４４３の処理は、ローカルキャッシュ４０４（通常キャッシュ４０４Ａ，永続キャッシュ４０４Ｂ）を制御するキャッシュ制御部４０１Ａにより実行される。また、ステップＳ４６１乃至Ｓ４６６の処理は、ブラウザ４０５のスクリプト実行部４０５Ａにより実行され、ステップＳ４８１乃至Ｓ４９０の処理は、ブラウザ４０５のDASHクライアント４０５Ｂにより実行される。
　ステップＳ４０１において、放送ミドルウェア４０３は、受信部４０２を介して、放送サーバ２０から伝送路８０を介して送信されてくるシグナリングを受信する。ステップＳ４０２において、放送ミドルウェア４０３は、ステップＳ４０１の処理で受信されたシグナリングを処理する。
　ここで、シグナリングとしては、SLTメタデータ等のLLSシグナリングと、USBDメタデータ等のSLSシグナリングが処理される。また、複数のサービスで、リソース（ファイル）を共有させる場合には、SLTメタデータ、USBDメタデータ、S-TSIDメタデータ、又はASTメタデータに定義されたquotaDomain属性に、対象のキャッシュクォータドメインのクォータドメイン識別子が指定されているので、このキャッシュクォータドメインに属するサービスが認識されることになる。
　ステップＳ４０３において、放送ミドルウェア４０３は、受信部４０２を介して、放送サーバ２０から伝送路８０を介して送信されてくるAdセグメント及びDASHセグメントを受信する。ステップＳ４０４において、放送ミドルウェア４０３は、ステップＳ４０３の処理で受信されたAdセグメント及びDASHセグメントを、ローカルキャッシュ４０４に転送する。
　ステップＳ４２１において、キャッシュ制御部４０１Ａは、ステップＳ４０４の処理で転送されてくるAdセグメント及びDASHセグメント（のファイル）を、ローカルキャッシュ４０４の通常キャッシュ４０４Ａにキャッシュする。
　この場合、Adセグメント及びDASHセグメント（のファイル）は、通常キャッシュ４０４Ａにキャッシュされているので、このままの状態が継続されると、しかるべき時間（それほど長くない時間）の経過後、消去されることになる。また、ここでは、説明の都合上、AdセグメントとDASHセグメント（のファイル）が同時にキャッシュされる場合を説明しているが、これらのセグメント（のファイル）は、異なるタイミングでキャッシュされるようにしてもよい。
　ステップＳ４０５において、放送ミドルウェア４０３は、受信部４０２を介して、放送サーバ２０から伝送路８０を介して送信されてくるスクリプトアプリケーションを受信する。ステップＳ４０６において、放送ミドルウェア４０３は、ステップＳ４０５の処理で受信されたスクリプトアプリケーションを、ローカルキャッシュ４０４に転送する。
　ステップＳ４２２において、キャッシュ制御部４０１Ａは、ステップＳ４０６の処理で転送されてくるスクリプトアプリケーションを、ローカルキャッシュ４０４の通常キャッシュ４０４Ａにキャッシュする。この場合、スクリプトアプリケーションは、通常キャッシュ４０４Ａにキャッシュされているので、このままの状態が継続されると、しかるべき時間（それほど長くない時間）の経過後、消去されることになる。
　ステップＳ４６１において、スクリプト実行部４０５Ａは、ステップＳ４２２の処理で通常キャッシュ４０４Ａにキャッシュされたスクリプトアプリケーションを、ローカルキャッシュ４０４から取得し、当該スクリプトアプリケーションを実行する。
　ステップＳ４６２において、スクリプト実行部４０５Ａは、スクリプトアプリケーションの実行（ステップＳ４６１の処理）に応じて、キャッシュ制御部４０１Ａに対して、Adセグメントの永続キャッシュ４０４Ｂへの引き込みを要求する。
　ここで、Adセグメントの永続キャッシュ４０４Ｂへの引き込み指示は、例えば、スクリプトアプリケーションに記述される、下記のCacheStorage APIを実行することで行われる。
Interface Cache {
  Promise<void> fetchPeriod(xmlElement);
}
　ただし、上記のAPIにおいて、fetchPeriodメソッドは、永続キャッシュ４０４Ｂへの引き込み指示に用いられる。また、fetchPeriodメソッドの引数であるxmlElementで指定されるPeriod要素の中に記述されるセグメントURLで指定されるセグメントファイル（Adセグメントのファイル）が、永続キャッシュ４０４Ｂに格納される対象のファイルとなる。
　また、スクリプトアプリケーションには、下記のCacheStorage APIが記述されるようにしてもよい。
Interface Cache {
  Promise<void> fetchFile(url);
}
　ただし、上記のAPIにおいて、fetchFileメソッドは、永続キャッシュ４０４Ｂへの引き込み指示に用いられる。また、fetchFileメソッドの引数であるurlで指定されるセグメントファイル（Adセグメントのファイル）が、永続キャッシュ４０４Ｂに格納される対象のファイルとなる。
　ステップＳ４４１において、キャッシュ制御部４０１Ａは、ステップＳ４６２の処理の引き込み要求に応じて、挿入候補のAdセグメント（のファイル）を、ローカルキャッシュ４０４の通常キャッシュ４０４Ａから、永続キャッシュ４０４Ｂに引き込む。これにより、ローカルキャッシュ４０４の永続キャッシュ４０４Ｂには、通常キャッシュ４０４Ａから引き込まれたAdセグメント（のファイル）がキャッシュされる（Ｓ４４２）。
　すなわち、伝送路８０を介して放送経由で配信されるファイル群は、通常、放送ミドルウェア４０３によって、ROUTEプロトコルが終端された後に、ローカルキャッシュ４０４の通常キャッシュ４０４Ａ（HTTPプロキシキャッシュ（ファイルシステム））に展開されて、しかるべき時間（それほど長くない時間）が経過後、消去される。ここでは、例えば、ROUTEのエンティティモードのファイル転送の際に付加されるHTTPヘッダに記述されるキャッシュ有効期限などにより定められる時間が経過後、ファイルが消去される。
　一方で、ローカルキャッシュ４０４の永続キャッシュ４０４Ｂは、HTTPプロキシキャッシュのうち、特別な領域として扱われるものである。すなわち、この永続キャッシュ４０４Ｂに展開されるファイル群は、通常キャッシュ４０４Ａにキャッシュされる他のファイル群よりも、優先的な永続性を持ち、さらに、上記の「しかるべき時間」が経過しても消去されず、ローカルキャッシュ４０４にあらかじめ割り当てられたクォータ（quota：割り当て量）に達するまで、ファイルがキャッシュされることになる。
　そして、永続キャッシュ４０４Ｂにキャッシュされるファイル群が属するサービスは、SLTメタデータ、USBDメタデータ、S-TSIDメタデータ、又はASTメタデータに定義されたquotaDomain属性に指定されたクォータドメイン識別子により紐付けられているので、同一のキャッシュクォータドメインに属する複数のサービスにおいて、特定のファイル（この例では、Adセグメントのファイル）を共有することが可能となる。
　ステップＳ４０７において、放送ミドルウェア４０３は、受信部４０２を介して、放送サーバ２０から伝送路８０を介して送信されてくるMPDメタデータを受信する。ステップＳ４０８において、放送ミドルウェア４０３は、ステップＳ４０７の処理で受信されたMPDメタデータを、ローカルキャッシュ４０４に転送する。
　ステップＳ４２３において、キャッシュ制御部４０１Ａは、ステップＳ４０８の処理で転送されてくるMPDメタデータを、ローカルキャッシュ４０４の通常キャッシュ４０４Ａにキャッシュする。この場合、MPDメタデータは、通常キャッシュ４０４Ａにキャッシュされているので、しかるべき時間（それほど長くない時間）の経過後、消去されることになる。
　ステップＳ４８１において、DASHクライアント４０５Ｂは、ステップＳ４２３の処理で通常キャッシュ４０４ＡにキャッシュされたMPDメタデータを、ローカルキャッシュ４０４から取得し、当該MPDメタデータをパース（構文解析）する。
　ステップＳ４８２において、DASHクライアント４０５Ｂは、ステップＳ４０２やＳ４８１の処理結果（SLT，USBD，S-TSID，MPD等のメタデータの処理結果）に応じて取得され、通常キャッシュ４０４ＡにキャッシュされたDASHセグメントを、ローカルキャッシュ４０４から取得する。ステップＳ４８３において、DASHクライアント４０５Ｂは、再生制御部４０１Ｂからの制御に従い、ステップＳ４８２の処理で取得されたDASHセグメントを再生する。これにより、クライアント装置４０では、放送番組のコンテンツが再生されることになる。
　ステップＳ４８４において、DASHクライアント４０５Ｂは、広告を挿入するかどうかを判定する。ステップＳ４８４において、広告を挿入しないと判定された場合、処理は、ステップＳ４８２に戻り、ステップＳ４８２乃至Ｓ４８４の処理が繰り返される。この場合、放送番組のコンテンツの再生が継続されることになる。一方で、ステップＳ４８４において、広告を挿入すると判定された場合、処理は、ステップＳ４８５に進められる。
　ステップＳ４８５において、DASHクライアント４０５Ｂは、ステップＳ４８１の処理結果に応じて、MPDメタデータに含まれるXLinkの解決を、スクリプト実行部４０５Ａに要求する。
　ただし、ここでは、ステップＳ４８１の処理によって、MPDメタデータのPeriod要素のxlink:href属性に指定されるURLから、"urn:atsc:ad-insertion"から開始される文字列からなるURNが検出された場合に、スクリプト実行部４０５Ａにより同時に実行されているスクリプトアプリケーションに対して、XLinkの解決（Period要素の解決）を促すイベントを発行することになる。
　ステップＳ４６３において、スクリプト実行部４０５Ａは、ステップＳ４８５の処理のXLink解決要求に応じて、実行中のスクリプトアプリケーションのスクリプト内のロジックにより、ユーザプリファレンスを取得する。そして、ステップＳ４６４において、スクリプト実行部４０５Ａは、ステップＳ４６３の処理で取得されたユーザプリファレンスに基づいて、ピリオドファイルを生成する。
　ここで、スクリプト実行部４０５Ａは、DASHクライアント４０５Ｂからのイベントにより通知されるURL（例えば、"urn:atsc:ad-insertion:abc:1234"であるURL）に基づいて、MPDメタデータに挿入されるべきPeriod要素を含むピリオドファイルを生成する。なお、ユーザプリファレンスとしては、例えば、PDI(Preference Demographic and Interest)を利用するようにしてもよい。このPDIは、特定のサーバから提供される質問に対するユーザの回答を示す情報を生成することで、ユーザの嗜好にマッチしたコンテンツのみが再生(蓄積)されるようにする仕組みである。
　ステップＳ４６５において、スクリプト実行部４０５Ａは、ステップＳ４６４の処理で生成されたピリオドファイルを、DASHクライアント４０５Ｂに応答する。
　なお、MPDメタデータのPeriod要素のxlink:href属性に、"http:"から開始される文字列からなるURL（例えば、"http://adservice.com/adp-1?user=$groupID$"などのURL）が記述されている場合には、図中の点線（「５」の点線）で示すように、XLinkの解決要求が、インターネット９０を介して通信サーバ３０に送信される。そして、図中の点線（「６」の点線）で示すように、通信サーバ３０から送信されてくる、XLinkの解決要求に応じたピリオドファイルが取得されることになる。
　ステップＳ４８６において、DASHクライアント４０５Ｂは、ステップＳ４６５の処理で応答されるピリオドファイルを取得し、当該ピリオドファイルをパース（構文解析）する。
　ステップＳ４８７において、DASHクライアント４０５Ｂは、ステップＳ４８６の処理結果に応じて、ローカルキャッシュ４０４の永続キャッシュ４０４ＢにキャッシュされたAdセグメントを取得する。ここでは、ステップＳ４８６の処理で、Period要素をパースすることで、対象のAdセグメントのURLが得られるので、当該URLに従い、永続キャッシュ４０４ＢのAdセグメントが取得される。そして、このAdセグメントのファイルは、同一のキャッシュクォータドメインに属する複数のサービスで共有されているファイルであるため、Adセグメントのファイルを再利用することができる。
　ステップＳ４８８において、DASHクライアント４０５Ｂは、再生制御部４０１Ｂからの制御に従い、ステップＳ４８７の処理で取得されたAdセグメントを再生する。これにより、クライアント装置４０では、再生されるコンテンツが、放送番組から広告に切り替わることになる（広告が挿入される）。
　ステップＳ４８９において、DASHクライアント４０５Ｂは、Adセグメントの再生（ステップＳ４８８の処理）が完了したかどうかを判定する。ステップＳ４８９において、Adセグメントの再生が完了していないと判定された場合、処理は、ステップＳ４８８に戻り、Adセグメントの再生が継続される。
　一方で、ステップＳ４８９において、Adセグメントの再生が完了したと判定された場合、処理は、ステップＳ４９０に進められる。ステップＳ４９０において、DASHクライアント４０５Ｂは、Adセグメントの再生完了を、スクリプト実行部４０５Ａに通知する。
　ステップＳ４６６において、スクリプト実行部４０５Ａは、ステップＳ４９０のAdセグメント再生完了通知に応じて、実行中のスクリプトアプリケーションによって、キャッシュ制御部４０１Ａに対して、再生完了のAdセグメントの永続キャッシュ４０４Ｂからの消去を要求する。
　ここで、Adセグメントの永続キャッシュ４０４Ｂからの消去指示は、例えば、スクリプトアプリケーションに記述される、下記のCacheStorage APIを実行することで行われる。
Interface Cache {
Promise<void> deleteFile(url);
}
　ただし、上記のAPIにおいて、deleteFileメソッドは、永続キャッシュ４０４Ｂからの消去指示に用いられる。また、deleteFileメソッドの引数であるurlで指定されるセグメントファイル（Adセグメントのファイル）が、永続キャッシュ４０４Ｂから削除される対象のファイルとなる。
　ステップＳ４４３において、キャッシュ制御部４０１Ａは、ステップＳ４６６の処理の消去要求に応じて、再生完了のAdセグメント（のファイル）を、ローカルキャッシュ４０４の永続キャッシュ４０４Ｂから消去する。なお、クライアント装置４０では、Adセグメントの再生が終了すると、再生されるコンテンツが、広告から放送番組に切り替わることになる。
　以上、受信側の処理の流れについて説明した。
＜７．変形例＞
　上述した説明としては、デジタル放送の規格として、米国等で採用されている方式である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）等の有線放送などに適用することができる。
　また、上述したドメインやシグナリングなどの名称は、一例であって、他の名称が用いられる場合がある。ただし、これらの名称の違いは、形式的な違いであって、対象のドメインやシグナリングなどの実質的な内容が異なるものではない。例えば、キャッシュクォータドメイン（Cache Quota Domain）は、キャッシュクォータグループ（Cache Quota Group）などの同様のニュアンスを有する他の名称で呼ばれる場合がある。また、例えば、AST(Application Signaling Table)は、AIT(Application Information Table)などと称され、NRT(Non Real Time)は、LCC(Locally Cached Content)などと称される場合がある。さらに、シグナリングが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１００２や記録部１００８に、あらかじめインストールしておくことができる。
　ここで、本明細書において、コンピュータがプログラムに従って行う処理は、必ずしもフローチャートとして記載された順序に沿って時系列に行われる必要はない。すなわち、コンピュータがプログラムに従って行う処理は、並列的あるいは個別に実行される処理（例えば、並列処理あるいはオブジェクトによる処理）も含む。また、プログラムは、１のコンピュータ（プロセッサ）により処理されるものであってもよいし、複数のコンピュータによって分散処理されるものであってもよい。
　なお、本技術の実施の形態は、上述した実施の形態に限定されるものではなく、本技術の要旨を逸脱しない範囲において種々の変更が可能である。
　また、本技術は、以下のような構成をとることができる。
（１）
　コンテンツを受信する受信部と、
　前記コンテンツとともに伝送される制御情報であって、前記コンテンツのリソースが、複数のサービスで共有されるリソースであるかどうかを示すリソース共有情報を含む前記制御情報に基づいて、前記コンテンツのリソースが、複数のサービスで共有されるように、前記リソースの記憶装置への記憶を制御する制御部と
　を備える受信装置。
（２）
　前記制御部は、前記制御情報に含まれる前記リソース共有情報が、複数のサービスで共有されるリソースであることを示している場合、共有されるリソースである共有リソースを、他のリソースと区別して記憶させる
　（１）に記載の受信装置。
（３）
　前記コンテンツ及び前記制御情報は、放送波により伝送され、
　前記サービスは、デジタル放送のサービスであり、
　前記制御情報は、前記サービスを提供するためのシグナリングである
　（１）又は（２）に記載の受信装置。
（４）
　前記シグナリングは、複数のサービスの属性を指定可能な第１のシグナリングであり、
　前記第１のシグナリングは、サービス単位で指定された前記リソース共有情報を含む
　（３）に記載の受信装置。
（５）
　前記シグナリングは、サービスごとの属性を指定可能な第２のシグナリングであり、
　前記第２のシグナリングは、対象のサービス内の所定の単位で指定された前記リソース共有情報を含む
　（３）に記載の受信装置。
（６）
　前記リソース共有情報は、サービス単位、セッション単位、又はアプリケーション単位で指定される
　（５）に記載の受信装置。
（７）
　前記コンテンツのリソースは、所定の形式のファイルであり、
　前記制御部は、前記コンテンツとともに伝送されるアプリケーションの動作に応じて、共有リソースのファイルを、他のリソースのファイルが記憶される第１の記憶領域とは異なる第２の記憶領域に記憶させる
　（２）乃至（６）のいずれかに記載の受信装置。
（８）
　前記制御部は、前記アプリケーションの動作に応じて、前記第２の記憶領域に記憶された共有リソースのファイルを消去する
　（７）に記載の受信装置。
（９）
　前記放送波は、IP(Internet Protocol)伝送方式に対応した放送波であり、
　前記コンテンツのリソースのファイルのデータは、UDP(User Datagram Protocol)パケットを含むIPパケットに格納されて伝送される
　（３）乃至（８）のいずれかに記載の受信装置。
（１０）
　前記コンテンツは、広告のコンテンツを含み、
　前記リソース共有情報は、前記広告のコンテンツのリソースを共有する複数のサービスが属するグループを識別するための識別情報である
　（１）乃至（９）のいずれかに記載の受信装置。
（１１）
　受信装置のデータ処理方法において、
　前記受信装置が、
　コンテンツを受信し、
　前記コンテンツとともに伝送される制御情報であって、前記コンテンツのリソースが、複数のサービスで共有されるリソースであるかどうかを示すリソース共有情報を含む前記制御情報に基づいて、前記コンテンツのリソースが、複数のサービスで共有されるように、前記リソースの記憶装置への記憶を制御する
　ステップを含むデータ処理方法。
（１２）
　コンテンツのリソースが、複数のサービスで共有されるリソースであるかどうかを示すリソース共有情報を含む制御情報を生成する生成部と、
　前記コンテンツとともに、前記制御情報を送信する送信部と
　を備える送信装置。
（１３）
　前記コンテンツ及び前記制御情報は、放送波により伝送され、
　前記サービスは、デジタル放送のサービスであり、
　前記制御情報は、前記サービスを提供するためのシグナリングである
　（１２）に記載の送信装置。
（１４）
　前記シグナリングは、複数のサービスの属性を指定可能な第１のシグナリングであり、
　前記第１のシグナリングは、サービス単位で指定された前記リソース共有情報を含む
　（１３）に記載の送信装置。
（１５）
　前記シグナリングは、サービスごとの属性を指定可能な第２のシグナリングであり、
　前記第２のシグナリングは、対象のサービス内の所定の単位で指定された前記リソース共有情報を含む
　（１３）に記載の送信装置。
（１６）
　前記リソース共有情報は、サービス単位、セッション単位、又はアプリケーション単位で指定される
　（１５）に記載の送信装置。
（１７）
　前記コンテンツのリソースは、所定の形式のファイルである
　（１２）乃至（１６）のいずれかに記載の送信装置。
（１８）
　前記放送波は、IP伝送方式に対応した放送波であり、
　前記コンテンツのリソースのファイルのデータは、UDPパケットを含むIPパケットに格納されて伝送される
　（１３）乃至（１７）のいずれかに記載の送信装置。
（１９）
　前記コンテンツは、広告のコンテンツを含み、
　前記リソース共有情報は、前記広告のコンテンツのリソースを共有する複数のサービスが属するグループを識別するための識別情報である
　（１２）乃至（１８）のいずれかに記載の送信装置。
（２０）
　送信装置のデータ処理方法において、
　前記送信装置が、
　コンテンツのリソースが、複数のサービスで共有されるリソースであるかどうかを示すリソース共有情報を含む制御情報を生成し、
　前記コンテンツとともに、前記制御情報を送信する
　ステップを含むデータ処理方法。
　１　伝送システム，　１０　Ad/DASHサーバ，　２０　放送サーバ，　３０　通信サーバ，　４０　クライアント装置，　８０　伝送路，　９０　インターネット，　１０１　受信部，　１０２　Ad/DASHセグメント生成部，　１０３　スクリプトアプリケーション生成部，　１０４　MPD生成部，　１０５　処理部，　１０６　送信部，　２０１　受信部，　２０２　シグナリング生成部，　２０３　処理部，　２０４　送信部，　３０１　受信部，　３０２　ピリオドファイル生成部，　３０３　処理部，　３０４　通信部，　４０１　制御部，　４０１Ａ　キャッシュ制御部，　４０１Ｂ　再生制御部，　４０２　受信部，　４０３　放送ミドルウェア，　４０４　ローカルキャッシュ，　４０４Ａ　通常キャッシュ，　４０４Ｂ　永続キャッシュ，　４０５　ブラウザ，　４０５Ａ　スクリプト実行部，　４０５Ｂ　DASHクライアント，　４０６　出力部，　４０７　通信部，　１０００　コンピュータ，　１００１　CPU

Claims (20)

  1. 　コンテンツを受信する受信部と、
    　前記コンテンツとともに伝送される制御情報であって、前記コンテンツのリソースが、複数のサービスで共有されるリソースであるかどうかを示すリソース共有情報を含む前記制御情報に基づいて、前記コンテンツのリソースが、複数のサービスで共有されるように、前記リソースの記憶装置への記憶を制御する制御部と
    　を備える受信装置。
  2. 　前記制御部は、前記制御情報に含まれる前記リソース共有情報が、複数のサービスで共有されるリソースであることを示している場合、共有されるリソースである共有リソースを、他のリソースと区別して記憶させる
    　請求項１に記載の受信装置。
  3. 　前記コンテンツ及び前記制御情報は、放送波により伝送され、
    　前記サービスは、デジタル放送のサービスであり、
    　前記制御情報は、前記サービスを提供するためのシグナリングである
    　請求項２に記載の受信装置。
  4. 　前記シグナリングは、複数のサービスの属性を指定可能な第１のシグナリングであり、
    　前記第１のシグナリングは、サービス単位で指定された前記リソース共有情報を含む
    　請求項３に記載の受信装置。
  5. 　前記シグナリングは、サービスごとの属性を指定可能な第２のシグナリングであり、
    　前記第２のシグナリングは、対象のサービス内の所定の単位で指定された前記リソース共有情報を含む
    　請求項３に記載の受信装置。
  6. 　前記リソース共有情報は、サービス単位、セッション単位、又はアプリケーション単位で指定される
    　請求項５に記載の受信装置。
  7. 　前記コンテンツのリソースは、所定の形式のファイルであり、
    　前記制御部は、前記コンテンツとともに伝送されるアプリケーションの動作に応じて、共有リソースのファイルを、他のリソースのファイルが記憶される第１の記憶領域とは異なる第２の記憶領域に記憶させる
    　請求項３に記載の受信装置。
  8. 　前記制御部は、前記アプリケーションの動作に応じて、前記第２の記憶領域に記憶された共有リソースのファイルを消去する
    　請求項７に記載の受信装置。
  9. 　前記放送波は、IP(Internet Protocol)伝送方式に対応した放送波であり、
    　前記コンテンツのリソースのファイルのデータは、UDP(User Datagram Protocol)パケットを含むIPパケットに格納されて伝送される
    　請求項３に記載の受信装置。
  10. 　前記コンテンツは、広告のコンテンツを含み、
    　前記リソース共有情報は、前記広告のコンテンツのリソースを共有する複数のサービスが属するグループを識別するための識別情報である
    　請求項１に記載の受信装置。
  11. 　受信装置のデータ処理方法において、
    　前記受信装置が、
    　コンテンツを受信し、
    　前記コンテンツとともに伝送される制御情報であって、前記コンテンツのリソースが、複数のサービスで共有されるリソースであるかどうかを示すリソース共有情報を含む前記制御情報に基づいて、前記コンテンツのリソースが、複数のサービスで共有されるように、前記リソースの記憶装置への記憶を制御する
    　ステップを含むデータ処理方法。
  12. 　コンテンツのリソースが、複数のサービスで共有されるリソースであるかどうかを示すリソース共有情報を含む制御情報を生成する生成部と、
    　前記コンテンツとともに、前記制御情報を送信する送信部と
    　を備える送信装置。
  13. 　前記コンテンツ及び前記制御情報は、放送波により伝送され、
    　前記サービスは、デジタル放送のサービスであり、
    　前記制御情報は、前記サービスを提供するためのシグナリングである
    　請求項１２に記載の送信装置。
  14. 　前記シグナリングは、複数のサービスの属性を指定可能な第１のシグナリングであり、
    　前記第１のシグナリングは、サービス単位で指定された前記リソース共有情報を含む
    　請求項１３に記載の送信装置。
  15. 　前記シグナリングは、サービスごとの属性を指定可能な第２のシグナリングであり、
    　前記第２のシグナリングは、対象のサービス内の所定の単位で指定された前記リソース共有情報を含む
    　請求項１３に記載の送信装置。
  16. 　前記リソース共有情報は、サービス単位、セッション単位、又はアプリケーション単位で指定される
    　請求項１５に記載の送信装置。
  17. 　前記コンテンツのリソースは、所定の形式のファイルである
    　請求項１２に記載の送信装置。
  18. 　前記放送波は、IP伝送方式に対応した放送波であり、
    　前記コンテンツのリソースのファイルのデータは、UDPパケットを含むIPパケットに格納されて伝送される
    　請求項１３に記載の送信装置。
  19. 　前記コンテンツは、広告のコンテンツを含み、
    　前記リソース共有情報は、前記広告のコンテンツのリソースを共有する複数のサービスが属するグループを識別するための識別情報である
    　請求項１２に記載の送信装置。
  20. 　送信装置のデータ処理方法において、
    　前記送信装置が、
    　コンテンツのリソースが、複数のサービスで共有されるリソースであるかどうかを示すリソース共有情報を含む制御情報を生成し、
    　前記コンテンツとともに、前記制御情報を送信する
    　ステップを含むデータ処理方法。
PCT/JP2016/083467 2015-11-25 2016-11-11 受信装置、送信装置、及び、データ処理方法 WO2017090457A1 (ja)

Priority Applications (11)

Application Number Priority Date Filing Date Title
KR1020187013711A KR102637023B1 (ko) 2015-11-25 2016-11-11 수신 장치, 송신 장치, 및 데이터 처리 방법
US15/766,850 US10986397B2 (en) 2015-11-25 2016-11-11 Reception apparatus, transmission apparatus, and data processing method
KR1020247004799A KR20240025698A (ko) 2015-11-25 2016-11-11 수신 장치, 송신 장치, 및 데이터 처리 방법
AU2016360190A AU2016360190A1 (en) 2015-11-25 2016-11-11 Reception device, transmission device and data processing method
JP2017552356A JPWO2017090457A1 (ja) 2015-11-25 2016-11-11 受信装置、送信装置、及び、データ処理方法
CA3003683A CA3003683A1 (en) 2015-11-25 2016-11-11 Reception apparatus, transmission apparatus, and data processing method
MX2018006174A MX2018006174A (es) 2015-11-25 2016-11-11 Aparato de recepcion, aparato de transmision y metodo de procesamiento de datos.
CN201680067759.9A CN108293148B (zh) 2015-11-25 2016-11-11 接收装置、发送装置以及数据处理方法
EP16868405.8A EP3383054B1 (en) 2015-11-25 2016-11-11 Reception device, transmission device and data processing method
US17/189,827 US11575961B2 (en) 2015-11-25 2021-03-02 Reception apparatus, transmission apparatus, and data processing method
AU2021202436A AU2021202436B2 (en) 2015-11-25 2021-04-21 Reception appartus, transmission apparatus, and data processing method

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2015229769 2015-11-25
JP2015-229769 2015-11-25

Related Child Applications (2)

Application Number Title Priority Date Filing Date
US15/766,850 A-371-Of-International US10986397B2 (en) 2015-11-25 2016-11-11 Reception apparatus, transmission apparatus, and data processing method
US17/189,827 Continuation US11575961B2 (en) 2015-11-25 2021-03-02 Reception apparatus, transmission apparatus, and data processing method

Publications (1)

Publication Number Publication Date
WO2017090457A1 true WO2017090457A1 (ja) 2017-06-01

Family

ID=58763199

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2016/083467 WO2017090457A1 (ja) 2015-11-25 2016-11-11 受信装置、送信装置、及び、データ処理方法

Country Status (9)

Country Link
US (2) US10986397B2 (ja)
EP (1) EP3383054B1 (ja)
JP (1) JPWO2017090457A1 (ja)
KR (2) KR102637023B1 (ja)
CN (1) CN108293148B (ja)
AU (2) AU2016360190A1 (ja)
CA (1) CA3003683A1 (ja)
MX (1) MX2018006174A (ja)
WO (1) WO2017090457A1 (ja)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2021108441A (ja) * 2019-12-27 2021-07-29 株式会社インフォシティ 放送サービス通信ネットワーク配信装置および方法
US11368730B2 (en) 2019-08-27 2022-06-21 Electronics And Telecommunications Research Institute Apparatus and method for transmitting broadcast content based on ATSC 3.0, and apparatus and method for receiving broadcast content based ATSC 3.0
JP2023008952A (ja) * 2021-06-30 2023-01-19 レモン インコーポレイテッド 事前選択の目的のシグナリング
US11985333B2 (en) 2021-06-30 2024-05-14 Lemon Inc. Indicating which video data units represent a target picture-in-picture region

Families Citing this family (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
AU2016360190A1 (en) * 2015-11-25 2018-04-19 Sony Corporation Reception device, transmission device and data processing method
US11044294B2 (en) 2018-01-03 2021-06-22 Sony Group Corporation ATSC 3.0 playback using MPEG media transport protocol (MMTP)
US11606528B2 (en) 2018-01-03 2023-03-14 Saturn Licensing Llc Advanced television systems committee (ATSC) 3.0 latency-free display of content attribute
US11109115B2 (en) * 2018-11-06 2021-08-31 At&T Intellectual Property I, L.P. Inserting advertisements in ATSC content
EP3884676A1 (en) * 2018-11-22 2021-09-29 Telefonaktiebolaget Lm Ericsson (Publ) Media descriptor file comprising a reference to other streaming media content
US10743069B2 (en) 2018-12-10 2020-08-11 Sony Corporation Delivery of information related to digital rights management (DRM) in a terrestrial broadcast system
US11706465B2 (en) 2019-01-15 2023-07-18 Sony Group Corporation ATSC 3.0 advertising notification using event streams
US11831702B2 (en) 2019-10-04 2023-11-28 Eexpway Method for broadcasting DASH/HLS hybrid multimedia streams
US11960507B2 (en) * 2020-01-17 2024-04-16 International Business Machines Corporation Hierarchical data
DE202020104113U1 (de) * 2020-07-16 2021-10-20 WAGO Verwaltungsgesellschaft mit beschränkter Haftung Elektronikeinrichtung für eine industrielle elektrische Anlage sowie Kommunikationsmodul
US11451872B1 (en) * 2021-05-27 2022-09-20 Sling TV L.L.C. System, device, and processes for intelligent start playback of program content

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2001197381A (ja) * 1999-11-05 2001-07-19 Dentsu Inc 蓄積情報の放送方法及びそのためのテレビジョン装置
JP2002101056A (ja) * 2000-07-17 2002-04-05 Matsushita Electric Ind Co Ltd 放送装置、放送方法、プログラム記録媒体、プログラム
JP2003032653A (ja) * 2001-07-16 2003-01-31 Funai Electric Co Ltd 双方向テレビシステムおよび双方向テレビ受信装置
JP2006099698A (ja) * 2004-09-30 2006-04-13 Toshiba Corp 配信情報再生装置、プログラム及び方法
JP2008017207A (ja) * 2006-07-06 2008-01-24 Kddi Corp 映像信号受信装置
JP2014057227A (ja) 2012-09-13 2014-03-27 Sony Corp コンテンツ供給装置、コンテンツ供給方法、プログラム、およびコンテンツ供給システム

Family Cites Families (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8300534B2 (en) * 2000-05-24 2012-10-30 Alcatel Lucent Programmable packet processor with flow resolution logic
US7096482B2 (en) 2000-07-17 2006-08-22 Matsushita Electric Industrial Co., Ltd. Broadcasting apparatus, broadcasting method, program recording medium, and program
US7073178B2 (en) * 2002-01-18 2006-07-04 Mobitv, Inc. Method and system of performing transactions using shared resources and different applications
US7721306B2 (en) 2006-02-15 2010-05-18 Sony Corporation Bandwidth sharing
US20080098420A1 (en) * 2006-10-19 2008-04-24 Roundbox, Inc. Distribution and display of advertising for devices in a network
JP4973246B2 (ja) * 2007-03-09 2012-07-11 日本電気株式会社 アクセス権管理システム、サーバ及びアクセス権管理プログラム
US9027100B2 (en) 2010-01-05 2015-05-05 Yahoo! Inc. Client-side ad caching for lower ad serving latency
US8307134B2 (en) * 2010-01-15 2012-11-06 Apple Inc. Multiple communication interfaces on a portable storage device
US8832750B2 (en) * 2012-05-10 2014-09-09 Time Warner Cable Enterprises Llc Media synchronization within home network using set-top box as gateway
KR20140029733A (ko) * 2012-08-29 2014-03-11 주식회사 팬택 어플리케이션 관리 기능을 갖는 디바이스 및 이를 위한 어플리케이션 관리 방법
US20140229580A1 (en) * 2013-02-12 2014-08-14 Sony Corporation Information processing device, information processing method, and information processing system
JP5865551B2 (ja) * 2013-04-16 2016-02-17 パナソニック インテレクチュアル プロパティ コーポレーション オブアメリカＰａｎａｓｏｎｉｃ Ｉｎｔｅｌｌｅｃｔｕａｌ Ｐｒｏｐｅｒｔｙ Ｃｏｒｐｏｒａｔｉｏｎ ｏｆ Ａｍｅｒｉｃａ コンテンツ表示方法、プログラム及びコンテンツ表示システム
EP3062521B1 (en) * 2013-10-25 2018-07-04 Sony Corporation Reception apparatus, reception method, transmission apparatus, and transmission method for services transmitted on a broadcast wave using ip packets
EP2922303A1 (en) * 2014-03-04 2015-09-23 LG Electronics Inc. Display device for managing a plurality of time source data and method for controlling the same
US9386027B2 (en) * 2014-08-11 2016-07-05 Indiana University Research & Technology Corporation Detection of pileup vulnerabilities in mobile operating systems
AU2016360190A1 (en) * 2015-11-25 2018-04-19 Sony Corporation Reception device, transmission device and data processing method

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2001197381A (ja) * 1999-11-05 2001-07-19 Dentsu Inc 蓄積情報の放送方法及びそのためのテレビジョン装置
JP2002101056A (ja) * 2000-07-17 2002-04-05 Matsushita Electric Ind Co Ltd 放送装置、放送方法、プログラム記録媒体、プログラム
JP2003032653A (ja) * 2001-07-16 2003-01-31 Funai Electric Co Ltd 双方向テレビシステムおよび双方向テレビ受信装置
JP2006099698A (ja) * 2004-09-30 2006-04-13 Toshiba Corp 配信情報再生装置、プログラム及び方法
JP2008017207A (ja) * 2006-07-06 2008-01-24 Kddi Corp 映像信号受信装置
JP2014057227A (ja) 2012-09-13 2014-03-27 Sony Corp コンテンツ供給装置、コンテンツ供給方法、プログラム、およびコンテンツ供給システム

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See also references of EP3383054A4

Cited By (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11368730B2 (en) 2019-08-27 2022-06-21 Electronics And Telecommunications Research Institute Apparatus and method for transmitting broadcast content based on ATSC 3.0, and apparatus and method for receiving broadcast content based ATSC 3.0
JP2021108441A (ja) * 2019-12-27 2021-07-29 株式会社インフォシティ 放送サービス通信ネットワーク配信装置および方法
JP2021108440A (ja) * 2019-12-27 2021-07-29 株式会社インフォシティ 放送サービス通信ネットワーク配信装置および方法
JP7058039B2 (ja) 2019-12-27 2022-04-21 株式会社インフォシティ 放送サービス通信ネットワーク配信装置および方法
JP2022095777A (ja) * 2019-12-27 2022-06-28 株式会社インフォシティ 放送サービス通信ネットワーク配信装置および方法
JP7125692B2 (ja) 2019-12-27 2022-08-25 株式会社インフォシティ 放送サービス通信ネットワーク配信装置および方法
JP7477116B2 (ja) 2019-12-27 2024-05-01 株式会社インフォシティ 放送サービス通信ネットワーク配信装置および方法
JP2023008952A (ja) * 2021-06-30 2023-01-19 レモン インコーポレイテッド 事前選択の目的のシグナリング
JP7460693B2 (ja) 2021-06-30 2024-04-02 レモン インコーポレイテッド 事前選択の目的のシグナリング
US11985333B2 (en) 2021-06-30 2024-05-14 Lemon Inc. Indicating which video data units represent a target picture-in-picture region

Also Published As

Publication number Publication date
US20210266629A1 (en) 2021-08-26
AU2021202436A1 (en) 2021-05-13
CN108293148A (zh) 2018-07-17
KR102637023B1 (ko) 2024-02-16
US20180288468A1 (en) 2018-10-04
CN108293148B (zh) 2022-07-26
US10986397B2 (en) 2021-04-20
KR20180088383A (ko) 2018-08-03
EP3383054A1 (en) 2018-10-03
EP3383054A4 (en) 2019-01-09
KR20240025698A (ko) 2024-02-27
AU2021202436B2 (en) 2023-03-16
US11575961B2 (en) 2023-02-07
JPWO2017090457A1 (ja) 2018-09-13
CA3003683A1 (en) 2017-06-01
AU2016360190A1 (en) 2018-04-19
MX2018006174A (es) 2018-08-01
EP3383054B1 (en) 2021-07-28

Similar Documents

Publication Publication Date Title
AU2021202436B2 (en) Reception appartus, transmission apparatus, and data processing method
CN103081507B (zh) 集成并处理到视频流中相关视频内容的嵌入式链接以提供广告信息
KR102443060B1 (ko) 정보 처리 장치 및 정보 처리 방법
US10469919B2 (en) Broadcast signal transmission apparatus, broadcast signal reception apparatus, broadcast signal transmission method, and broadcast signal reception method
WO2018034172A1 (ja) 情報処理装置、クライアント装置、及び、データ処理方法
JPWO2016174960A1 (ja) 受信装置、送信装置、およびデータ処理方法
US11336957B2 (en) Reception apparatus, transmission apparatus, and data processing method
WO2016067987A1 (ja) 受信装置、送信装置、およびデータ処理方法
KR102491466B1 (ko) 수신 장치, 송신 장치, 및 데이터 처리 방법
KR102600762B1 (ko) Atsc 3.0 기반의 방송 콘텐츠 전송 장치 및 방법과, 방송 콘텐츠 수신 장치 및 방법
WO2018012315A1 (ja) 情報処理装置、及び、情報処理方法
WO2017212932A1 (ja) 受信装置、送信装置、及び、データ処理方法
JP2012257231A (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: 16868405

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 15766850

Country of ref document: US

ENP Entry into the national phase

Ref document number: 2017552356

Country of ref document: JP

Kind code of ref document: A

ENP Entry into the national phase

Ref document number: 2016360190

Country of ref document: AU

Date of ref document: 20161111

Kind code of ref document: A

ENP Entry into the national phase

Ref document number: 3003683

Country of ref document: CA

ENP Entry into the national phase

Ref document number: 20187013711

Country of ref document: KR

Kind code of ref document: A

WWE Wipo information: entry into national phase

Ref document number: MX/A/2018/006174

Country of ref document: MX

NENP Non-entry into the national phase

Ref country code: DE

WWE Wipo information: entry into national phase

Ref document number: 2016868405

Country of ref document: EP