WO2016067988A1 - 受信装置、送信装置、およびデータ処理方法 - Google Patents
受信装置、送信装置、およびデータ処理方法 Download PDFInfo
- Publication number
- WO2016067988A1 WO2016067988A1 PCT/JP2015/079645 JP2015079645W WO2016067988A1 WO 2016067988 A1 WO2016067988 A1 WO 2016067988A1 JP 2015079645 W JP2015079645 W JP 2015079645W WO 2016067988 A1 WO2016067988 A1 WO 2016067988A1
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- data
- service
- token
- service worker
- receiving device
- Prior art date
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04H—BROADCAST COMMUNICATION
- H04H60/00—Arrangements for broadcast applications with a direct linking to broadcast information or broadcast space-time; Broadcast-related systems
- H04H60/09—Arrangements for device control with a direct linkage to broadcast information or to broadcast space-time; Arrangements for control of broadcast-related services
- H04H60/14—Arrangements for conditional access to broadcast information or to broadcast-related services
- H04H60/15—Arrangements for conditional access to broadcast information or to broadcast-related services on receiving information
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04H—BROADCAST COMMUNICATION
- H04H60/00—Arrangements for broadcast applications with a direct linking to broadcast information or broadcast space-time; Broadcast-related systems
- H04H60/09—Arrangements for device control with a direct linkage to broadcast information or to broadcast space-time; Arrangements for control of broadcast-related services
- H04H60/13—Arrangements for device control affected by the broadcast information
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/90—Details of database functions independent of the retrieved data types
- G06F16/907—Retrieval characterised by using metadata, e.g. metadata not derived from the content or metadata generated manually
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04H—BROADCAST COMMUNICATION
- H04H20/00—Arrangements for broadcast or for distribution combined with broadcast
- H04H20/86—Arrangements characterised by the broadcast information itself
- H04H20/91—Arrangements characterised by the broadcast information itself broadcasting computer programmes
-
- 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/35—Arrangements for identifying or recognising characteristics with a direct linkage to broadcast information or to broadcast space-time, e.g. for identifying broadcast stations or for identifying users
- H04H60/45—Arrangements for identifying or recognising characteristics with a direct linkage to broadcast information or to broadcast space-time, e.g. for identifying broadcast stations or for identifying users for identifying users
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04H—BROADCAST COMMUNICATION
- H04H60/00—Arrangements for broadcast applications with a direct linking to broadcast information or broadcast space-time; Broadcast-related systems
- H04H60/76—Arrangements characterised by transmission systems other than for broadcast, e.g. the Internet
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/90—Details of database functions independent of the retrieved data types
- G06F16/95—Retrieval from the web
- G06F16/955—Retrieval from the web using information identifiers, e.g. uniform resource locators [URL]
- G06F16/9566—URL specific, e.g. using aliases, detecting broken or misspelled links
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04H—BROADCAST COMMUNICATION
- H04H40/00—Arrangements specially adapted for receiving broadcast information
- H04H40/18—Arrangements characterised by circuits or components specially adapted for receiving
- H04H40/27—Arrangements characterised by circuits or components specially adapted for receiving specially adapted for broadcast systems covered by groups H04H20/53 - H04H20/95
Definitions
- the present disclosure relates to a reception device, a transmission device, and a data processing method. More specifically, for example, the present invention relates to a reception device that performs transmission or reception of data via a broadcast wave or a network, a transmission device, and a data processing method for communication data.
- One-way communication using a broadcast wave or the like from a transmitting device that provides content, such as a broadcasting station or a content server, to a receiving device such as a television, a PC, or a mobile terminal, or two-way communication via a network such as the Internet,
- a transmitting device that provides content
- a receiving device such as a television, a PC, or a mobile terminal
- two-way communication via a network such as the Internet
- ATSC Advanced Television System Commitment
- ATSC 3.0 The standardization of ATSC 3.0 is being promoted as one of the standards relating to data distribution systems via broadcast waves and networks.
- ATSC 3.0 a download type packaging method for application distribution management and an offline application registration / update management method are still under investigation.
- W3C World Wide Web Consortium
- SW service worker
- An object of the present disclosure is to provide a reception device, a transmission device, and a data processing method that can effectively use the above-described framework of a service worker (SW) in a client that is a broadcast content reception device. Furthermore, taking into account the constraints of various resources such as the execution environment and storage capacity of the receiving device (client), user preference information on the receiving device side, runtime capacity constraints such as storage capacity, local network, etc. It is an object of the present invention to provide a receiving device, a transmitting device, and a data processing method that realize cache control of applications (parts) that are finely cached by referring to various client environment attributes such as load. .
- the first aspect of the present disclosure is: A data management program used in a receiving apparatus, and includes a data processing unit that selectively acquires and uses a specific class of service workers (SW) from a plurality of class-compatible service workers (SW) having different data management types. It is in the receiving device.
- SW class of service workers
- SW class-compatible service workers
- the second aspect of the present disclosure is: A data management program used in a receiving apparatus, which is in a transmitting apparatus that transmits service workers (SW) corresponding to a plurality of classes having different data management types.
- SW service workers
- the third aspect of the present disclosure is: A data processing method executed in the receiving device,
- the data processing unit of the receiving device is a data management program used in the receiving device, and selectively acquires service workers (SW) of a specific class from a plurality of class-compatible service workers (SW) having different data management types. It is in the data processing method to be used.
- the fourth aspect of the present disclosure is: A data processing method executed in a transmission device, A data management program used in a receiving apparatus, which is a data processing method for transmitting service workers (SW) corresponding to a plurality of classes having different data management types.
- SW service workers
- system is a logical set configuration of a plurality of devices, and is not limited to one in which the devices of each configuration are in the same casing.
- an apparatus and a method that enable selection acquisition and use processing of a service worker (SW) that performs data management optimized for each reception apparatus are realized.
- SW service worker
- it is a data management program used in a receiving device, and a specific class SW is selectively acquired from a plurality of class-compatible service workers (SWs) having different data management types and can be used.
- SWs class-compatible service workers
- the receiving device acquires the access information of the specific class SW by using the signaling data in which the token for enabling efficient search of the access information of the specific class SW is recorded, and acquires the SW.
- SW service worker
- Service worker (SW) update processing 7.5.
- Control processing of storage unit (persistent cache) of receiving device by service worker (SW) Service worker (SW) distribution and cache control processing (push-type processing example) 8.1. Acquisition of service worker (SW) from broadcast stream application and registration processing 8.2. Configuration in which data acquisition process of receiving apparatus is made more efficient by applying token 8.3.
- Control processing of storage unit (persistent cache) of receiving device by service worker (SW) Configuration of signaling data (metadata) describing a token 9.1.
- the communication system 10 includes a transmission device 20 that is a communication device that transmits content such as image data and audio data, and a reception device 30 that is a communication device that receives content transmitted by the transmission device 20.
- a transmission device 20 that is a communication device that transmits content such as image data and audio data
- a reception device 30 that is a communication device that receives content transmitted by the transmission device 20.
- the transmission device 20 is a device that provides content, such as a broadcasting station 21 and a content server 22.
- the receiving device 30 is a client device of a general user, and specifically includes, for example, a television 31, a PC 32, a portable terminal 33, and the like.
- Data communication between the transmission device 20 and the reception device 30 is performed as communication using at least one of bidirectional communication, one-way communication, one-way communication using a broadcast wave, or the like via a network such as the Internet. Is called.
- the content transmission from the transmission device 20 to the reception device 30 is executed in accordance with, for example, the MPEG-DASH standard which is a standard of adaptive (adaptive) streaming technology.
- the MPEG-DASH standard includes the following two standards.
- A a standard concerning a manifest file (MPD: Media Presentation Description) for describing metadata that is management information of a moving image or an audio file
- B Standards related to file format (segment format) for video content transmission
- Content distribution from the transmission device 20 to the reception device 30 is executed in accordance with the MPEG-DASH standard.
- the transmission device 20 encodes the content data and generates a data file including the encoded data and the metadata of the encoded data.
- the encoding process is performed in accordance with, for example, an MP4 file format defined in MPEG.
- the encoded data file is called “mdat”, and the metadata is called “moov” or “moof”.
- the content provided by the transmitting device 20 to the receiving device 30 is various data such as music data, video data such as movies, television programs, videos, photos, documents, pictures and charts, games and software.
- Transmission data of the transmission device 20 will be described with reference to FIG. As shown in FIG. 2, the transmitting apparatus 20 that performs data transmission according to the MPEG-DASH standard transmits the following plural types of data roughly.
- A Signaling data 50
- B AV segment 60
- C Other data (ESG, NRT content, etc.) 70
- the AV segment 60 is composed of images (Video) and audio (Audio) data to be reproduced by the receiving device, that is, program content provided by a broadcasting station, for example.
- images Video
- Audio Audio
- the receiving device that is, program content provided by a broadcasting station, for example.
- it is configured by the above-described MP4 encoded data (mdat) and metadata (moov, moof).
- the signaling data 50 includes program schedule information such as a program guide, address information (URL (Uniform Resource Locator), etc.) necessary for program acquisition, and information necessary for content playback processing, such as codec information (encoding). System information), etc., and control information.
- the receiving device 30 needs to receive the signaling data 50 prior to receiving the AV segment 60 in which the program content to be reproduced is stored.
- the signaling data 50 is transmitted, for example, as data in XML (Extensible Markup Language) format to a receiving device (client) that is a user terminal such as a smartphone or a television.
- client Extensible Markup Language
- the signaling data is repeatedly transmitted as needed. For example, it is repeatedly transmitted every 100 msec. This is because the receiving device (client) can obtain the signaling data immediately at any time.
- the client (receiving device) executes processing necessary for receiving and playing program content without delay, such as acquisition of necessary program content access address and codec setting processing, based on receivable signaling data as needed. It becomes possible.
- the other data 70 includes, for example, ESG (Electronic Service Guide), NRT content, and the like.
- ESG is an electronic service guide, and is guide information such as a program guide.
- NRT content is non-real-time content.
- the NRT content includes, for example, various application files executed on the browser of the receiving device 30 that is a client, data files such as moving images and still images, and the like.
- a service worker used as a control program for an application or the like described later is also included in the NRT content.
- Signaling data 50 B
- AV segment 60 C
- Other data ESG, NRT content, etc.
- FLUTE File Delivery over Uni-directional Transport
- FLUTE File Delivery over Uni-directional Transport
- a file generated on the server side which is a transmission device is transmitted to a client which is a reception device in accordance with the FLUTE protocol.
- the receiving device (client) 30 stores the URL and version of the received file in association with the file, for example, in the storage unit (client cache) of the receiving device (client) 30. Files with the same URL but different versions are considered to have been updated.
- the FLUTE protocol performs only one-way file transfer control, and does not have a selective file filtering function on the client. However, on the client side using metadata associated with the file to be transferred by FLUTE, the metadata is associated with the file. By selecting, it becomes possible to realize selective filtering and to configure and update a local cache reflecting the user's preference.
- the metadata can be expanded and incorporated into the FLUTE protocol, or can be separately described using a protocol such as ESG (Electronic Service Guide).
- FLUTE was originally specified as a file transfer protocol in multicast.
- FLUTE is composed of a combination of FDT and a scalable file object multicast protocol called ALC, specifically, its building blocks LCT and FEC components.
- FLUTE Real-Time Object Delivery over Unidirectional Transport
- ATSC Advanced Television System Commitment
- FIG. 3 is a diagram illustrating an example of a protocol stack of the transmission device and the reception device.
- the example shown in FIG. 3 has two protocol stacks for processing the following two communication data.
- A Broadcast (including multicast) communication (for example, broadcast-type data distribution)
- B Unicast (broadband) communication (for example, HTTP-type P2P communication)
- the left side of FIG. 3 is a protocol stack corresponding to (a) broadcast communication (for example, broadcast-type data distribution).
- the right side of FIG. 3 is a protocol stack corresponding to (b) unicast (broadband) communication (for example, HTTP type P2P communication).
- the protocol stack corresponding to (a) broadcast communication (for example, broadcast-type data distribution) shown on the left side of FIG. 3 has the following layers in order from the lower layer.
- Broadcast physical layer Broadcast PHY
- IP Multicast IP Multicast
- Application layer Application layer (Applications (HTML5))
- a signaling layer is set as an upper layer of an IP multicast layer (IP Multicast).
- IP Multicast IP multicast layer
- the signaling layer is a layer applied to transmission / reception of the signaling data 50 described above with reference to FIG.
- the signaling data includes program schedule information such as a program guide, address information (URL and the like) necessary for program acquisition, and information necessary for content reproduction processing, such as codec information (encoding method and the like). Information, control information, and the like.
- a future new protocol use permission layer (Future Extension) is set as an upper layer of the broadcast physical layer (Broadcast PHY).
- the broadcast physical layer (Broadcast PHY) is a physical layer configured by a communication control unit that controls, for example, a broadcast communication unit for performing broadcast communication.
- the IP multicast layer (IP Multicast) is a layer that executes data transmission / reception processing according to IP multicast.
- the UDP layer is a UDP packet generation and analysis processing layer.
- the ROUTE layer is a layer that stores and retrieves transfer data according to the ROUTE protocol, which is an extended FLUTE protocol.
- ROUTE like FLUTE, is a multicast file object multicast protocol called ALC, and is specifically composed of a combination of its building blocks LCT and FEC components.
- ESG, NRT content, DASH (ISO BMFF), and Video / Audio / CC are data transferred according to the ROUTE protocol.
- the broadcast delivery service according to the DASH standard is called MBMS (Multimedia Broadcast Multicast Service).
- MBMS Multimedia Broadcast Multicast Service
- eMBMS evolved Multimedia Broadcast Service
- MBMS and eMBMS are broadcast-type delivery services that deliver the same data, such as movie content, all at once to a plurality of user terminals (UEs), which are receiving devices located in a specific area, using a common bearer. It is a service.
- UEs user terminals
- the same content can be simultaneously provided to a number of receiving devices such as smartphones, PCs, and televisions located in the distribution service providing area.
- MBMS and eMBMS specify a process for downloading a file according to the 3GPP file format (ISO-BMFF file, MP4 file) according to the transfer protocol ROUTE or FLUTE.
- 3GPP file format ISO-BMFF file, MP4 file
- Signaling data 50 (B) AV segment 60 (C) Other data (ESG, NRT content, etc.) 70 Many of these data are transmitted according to the ROUTE protocol or the FLUTE protocol.
- ESG, NRT content, DASH (ISO BMFF), and Video / Audio / CC are data transferred according to the ROUTE protocol.
- ESG is an electronic service guide, and is guide information such as a program guide.
- NRTcontent is non-real-time content.
- the NRT content includes, for example, various application files executed on the browser of the receiving device that is a client, data files such as moving images and still images, and the like.
- a service worker Service Worker (SW) used as a control program for an application or the like described later is also included in the NRT content.
- Video / Audio / CC is actual data to be played back, such as video and audio distributed according to the DASH standard.
- the application layer (Applications (HTML5)) is an application layer that executes generation or analysis of data to be transferred according to the ROUTE protocol, and other various data output control, for example, data generation using HTML5, Perform analysis and output processing.
- HTML5 Applications
- the protocol stack corresponding to (b) unicast (broadband) communication (for example, HTTP-type P2P communication) shown on the right side of FIG. 3 has the following layers in order from the lower layer.
- Broadband PHY (2) IP unicast layer (IP Unicast) (3) TCP layer (4) HTTP layer (5) ESG, Signaling, NRT content, DASH (ISO BMFF) and Video / Audio / CC (6) Application layer (Applications (HTML5))
- the broadband physical layer (Broband PHY) is a physical layer configured by a communication control unit such as a device driver that controls a communication unit such as a network card that performs broadband communication.
- the IP unicast layer (IP Unicast) is a layer that executes IP unicast transmission / reception processing.
- the HTTP layer is an HTTP packet generation and analysis processing layer. This upper layer is the same as the stack configuration of (a) broadcast communication (for example, broadcast-type data distribution) on the left side of FIG.
- the transmission device (server) 20 and the reception device (client) 30 have two processing systems shown in FIG. (A) Broadcast communication (for example, broadcast-type data distribution) (B) Unicast (broadband) communication (for example, HTTP-type P2P communication) Processing according to at least one of these two communication protocol stacks is performed.
- A Broadcast communication (for example, broadcast-type data distribution)
- B Unicast (broadband) communication (for example, HTTP-type P2P communication) Processing according to at least one of these two communication protocol stacks is performed.
- the attributes of a file group (including URL as a file identifier) multicast-transferred according to ROUTE (FLUTE) can be described in the control file of ROUTE (FLUTE). It can also be described in signaling data that describes the session. Further detailed attributes of the file transfer session can also be described by ESG (which can also be applied for presentation to the end user).
- SW Service Worker
- the service worker (SW) is provided from the transmission device 20 such as the broadcast server 21 or the data distribution server 22 to the reception device.
- the service worker (SW) is set corresponding to a broadcast program (broadcast content) provided by the transmission device 20 such as the broadcast server 21 or the data distribution server 22 and is provided from the transmission device 20 to the reception device 30. Is provided to the receiving device 30 as a control and management program.
- the service worker (SW), the application, and the data file used at the time of execution of the application are received from the transmission device 20 as, for example, the NRT content (non-real-time content) described above with reference to FIGS. Provided to device 30. Or it is good also as a structure which provides the data file utilized at the time of execution of a service worker (SW), an application, and an application to the receiver 30 from the data provision server different from the server which delivers a broadcast program.
- the service worker manages (acquires, holds, and updates) an application that performs information display using a browser that is a program used to execute browsing processing of a Web page or the like in the receiving device 30 , Delete, etc.) process.
- FIG. 4 shows a state in which the receiving device 30 receives a certain program content from the transmitting device 20 such as the broadcast server 21 and displays it on the display unit of the receiving device 30.
- the transmission device 20 such as the broadcast server 21 has an application for displaying weather information as NRT content (non-real time content) in conjunction with program distribution, and various data files used for the weather information display application, such as moving images, A data file including various data such as a still image and sound is provided to the receiving device 30.
- these applications and data files are referred to as “resources”.
- the broadcast server 21 further provides a service worker (SW) to the receiving apparatus 30 as NRT content (non-real time content) as a resource management program for managing these “resources”.
- SW service worker
- the reception device 30 can display weather information in addition to the program display as shown in FIG. Such data display using the application cannot be executed with the end of the program provided by the application in the conventional data distribution configuration.
- resources such as the weather information display application are set in a setting that can be used in the receiving device 30 during reception of a program, for example, in a temporary storage cache and set in a usable state. This is because, when the channel is switched, these cache data are erased or set in an inaccessible state.
- the service worker can use such program-compatible applications and data even after the program ends, after channel switching, or in an offline state such as a broadcast non-reception state or a network non-connection state. It functions as a resource management program.
- the weather information display application can be used even after the program providing this application is finished, after switching to another channel, or in an offline state in which data reception is not executed. It becomes possible. That is, the weather information can be displayed on the display unit of the receiving device 30 and browsed.
- the weather information display application is a program displayed on a browser, for example.
- This weather information display application is stored in the storage unit (permanent cache) of the receiving device 30 under the control of the service worker (SW). For example, when there is a request (event) such as a display request by the user, it is read from the storage unit (permanent cache) under the control of the service worker (SW) and displayed on the display unit.
- the storage unit (persistent cache) that stores resources such as applications is preferably a non-volatile memory that does not erase stored data even when the power of the receiving device 30 is turned off.
- various program-compatible applications can be used regardless of whether the program is displayed or not.
- the service worker (SW) is set for each resource (application and application-related data) corresponding to a certain program, for example, and is provided from the transmission device 20 to the reception device 30 together with the resource or before and after resource transmission. Is done.
- the service worker (SW) can be set for each program, but a service worker (SW) that can be commonly used can be set for a resource corresponding to a specific channel including a plurality of programs. .
- the service worker (SW) and the resources (application and application-related data) managed by the service worker (SW) are stored in the storage unit (persistent cache) of the receiving device 30.
- FIG. 6 is a diagram illustrating an example of processing using a service worker (SW).
- the receiving device 30 acquires a Web page (for example, the weather information display page shown in FIGS. 4 and 5) as a resource from the transmitting device 20 and stores it in the storage unit (permanent cache) of the receiving device 30.
- a Web page for example, the weather information display page shown in FIGS. 4 and 5
- An example of a sequence to be used is shown.
- the Web page is displayed using a resource configured by a predetermined Web page display application and display data.
- a display processing unit 91, a service worker (SW) 92, and a cache (storage unit) 93 are shown as components of the output control unit 90 in the receiving apparatus.
- Steps S101 to S102 are resource (Web page) acquisition processing by the initial access processing for the transmitting device 20 by the receiving device 30. This is acquired from NRT content transmitted from, for example, a broadcast server.
- the display processing unit 91 displays the web page 95 on the display unit of the receiving device 30. This display is a state in which the Web page is displayed together with the program, and corresponds to the display state described above with reference to FIG.
- step S103 For example, when a resource (Web page) registration (installation) request is made as an instruction from the user, the service worker (SW) 92 performs a resource (Web page) registration (installation) process in step S103. Start. Specifically, as shown in step S104, the resource is transferred to the cache 93 and stored in the storage unit (permanent cache).
- step S105 After the program ends, after channel switching, or in an offline setting state, the user makes a web page browsing request in step S105.
- the service worker (SW) 92 detects the input of the browsing request as a fetch event, and acquires a resource (Web page) from the storage unit (persistent cache) in step S106 in response to the fetch event detection.
- the display processing unit 91 displays the web page 96.
- This Web page display process is a display process after a program ends, after a channel is switched, or in an offline setting state, and corresponds to the display state described above with reference to FIG.
- SW service worker
- the service worker acquires, stores, and updates resources including, for example, applications including Web pages, HTML pages, Javascript (registered trademark), data used for the applications, and the like.
- Execute resource management such as deletion.
- the storage unit (cache) in which resources are stored is a storage unit (cache) that permanently stores stored data. Unlike normal local / temporary caches, data can be stored even if the application is not running. Saved.
- a type of proxy server is implemented in a browser that is a Web page display program, and the proxy server is accessed whenever necessary to acquire and display a Web page.
- the service worker (SW) itself is also stored (installed) in the permanent cache.
- various controls can be performed on the resources to be managed by the service worker (SW). For example, in response to an access request to a resource (a fetch request to a resource), before the processing on the browser side (acquisition of resources from a local cache or network) starts, the service worker (SW) process is started and Resources are provided from the cache.
- the service worker (SW) is provided by Java Script (registered trademark), it is possible to incorporate various procedures, and there is a flexible processing description for cache control such as updating a part of the resource of the persistent cache. It is possible.
- the service worker (SW) itself can also be updated.
- the service worker (SW) is provided from the transmission device 20, and the header information (HTTP Cache-Control) of the service worker (SW) includes various information necessary for the update process, such as update date / time information and update data access information. Information is recorded, and update processing is executed based on this header information. For example, when the expiration date comes based on the expiration date set in the header, the receiving device 30 executes acquisition processing of a new version of the service worker (SW), and the old version of the SW stored in the cache. Update process to replace.
- the receiving device 30 uses a service worker (SW) at an arbitrary timing, for example, an application such as a weather information display application described with reference to FIGS. 4 and 5, that is, a service worker. It is possible to execute an application that is a management target of (SW). The user on the receiving device 30 side can view the weather information display page and various Web pages at any time by executing the application at an arbitrary timing. With reference to FIG. 7, an application execution configuration in the reception device 30 will be described.
- SW service worker
- FIG. 7 shows a configuration example mainly applied to acquisition and execution of an application as a partial configuration of the reception device 30 that executes a service worker (SW) management application such as a weather information display application.
- the reception device 30 includes a middleware 110, an HTTP proxy server 120, and an output control unit 130.
- the middleware 110 receives the data provided by the broadcast server 21 and analyzes it.
- the middleware 110 includes a communication unit (PHY / MAC) 111, a signaling acquisition unit 112 that acquires signaling data, a signaling analysis unit 113 that analyzes signaling data, signaling data, and program content data such as video and audio, applications, and the like
- the file acquisition unit 114 acquires a data file such as the NRT content.
- Data received by the middleware 110 is stored in the cache unit (proxy cache) 121 of the proxy server 120.
- the proxy server 120 further stores data acquired from the data distribution server 22 via the network in the cache unit (proxy cache) 122.
- the proxy server 120 inputs a data request from the output control unit 130 to the address resolution unit 123, and obtains and provides the requested data from the cache units (proxy caches) 121 and 122 or from the outside.
- the output control unit 130 is a data processing unit that executes a service worker (SW) management application such as a weather information display application. For example, Web page display processing or the like is executed on a browser.
- the output control unit 130 includes a display data (HTML / JavaScript (registered trademark)) acquisition & analysis unit 131 and a display processing unit (Renderer) 132.
- the output control unit 130 is a middleware (Client Local ATSC Middleware) 110 in which a broadcast reception stack is mounted via a proxy server (Client Local HTTP Proxy Server) 120, or a normal network stack that performs network transmission / reception processing
- the application and parts (HTML page and JavaScript) are acquired and presented via the.
- the application and part (HTML page or JavaScript) may be transferred in the output control unit 141 of the external apparatus 150 connected to the receiving apparatus 30 via a network such as a LAN, and the application may be executed in the external apparatus 140. Is possible.
- the output control unit 130 stores the above-described service worker (SW) and resources (applications and application-related data) to be managed by the service worker (SW) in the storage unit (persistent cache) 133, and stores them at an arbitrary timing. It is possible to execute processing using service workers (SW) and resources stored in a unit (permanent cache). For example, as described above with reference to FIGS. 4 and 5, various data output using an application can be performed at an arbitrary timing. Further, the output control unit 130 performs update processing or deletion processing of service workers (SW) and resources (applications and application-related data) as necessary.
- the service worker (SW) and resources are stored in the storage unit (persistent cache) 142 of the external device 140, and the service worker is at an arbitrary timing. Various data processing using (SW) and applications is performed. Further, update processing and deletion processing of service workers (SW) and resources (applications and application-related data) are performed as necessary.
- the output control units 130 and 140 always access through the proxy server 120 when accessing the outside. There is no distinction as to whether it is acquired via the Internet. That is, network transparency is provided.
- the signaling analysis unit (Signaling Parser) 113 requests the signaling acquisition unit (Signaling Retriever) 112 to acquire USBD (USD, SDP, etc.), which is metadata included in the ATSC 3.0 signaling data.
- a signaling analysis unit (Signaling Parser) 113 extracts metadata included in signaling data transferred by a signaling data storage LCT packet that is broadcast-received via a communication unit (ATSC tuner: ATSC3.0PHY / MAC) 111.
- the signaling analysis unit (Signaling Parser) 113 resolves the broadcast distribution address information for acquiring the request file from the signaling data (metadata) based on the URL included in the application component (part) acquisition request. To do.
- the file acquisition unit (File retriever) 114 When it is determined that the application component (part) is broadcast distribution target data, the file acquisition unit (File retriever) 114 generates a file storage LCT packet in which a desired file is stored based on the broadcast distribution address information. Obtained from the broadcast stream and stored in the cache unit (proxy cache) 121.
- the proxy server 120 returns the cached file to the output control unit 130 (as an HTTP response). If the URL included in the application part acquisition request is not set in the metadata included in the signaling data, the proxy server 120 acquires a file from the data distribution server 22 via the normal net stack.
- the service worker (SW) is provided from the transmission device 20 to the reception device 30 and acquires an application executed in the reception device (client) 30 and a data file used when the application is executed.
- This program executes processing, storage processing for a storage unit (cache), update processing, deletion processing, and the like.
- Service workers that enables service workers (SW) to use applications and data corresponding to programs, for example, even after a program ends, after channel switching, or in an offline state such as a broadcast non-reception state or a network non-connection state Functions as a program. Furthermore, by applying a service worker (SW), it is possible to obtain a new or updated application set as service worker (SW) management data or a data file such as a moving image or a still image at any time. is there. That is, the service worker (SW) also implements acquisition control of various data that can be acquired by the receiving device 30.
- SW Service worker
- This service worker (SW) is classified, and the receiving device selects and acquires one of a plurality of class service workers (SW), and applies this, for example, according to the user preference on the receiving device side.
- Obtaining (caching) service worker management data (resources) can be realized.
- the receiving apparatus selects and acquires a specific class of service workers (SW) from a plurality of class-compatible service workers (SW) having different data management types. For example, a specific class of service worker (SW) is selected and acquired according to the data processing status in the receiving apparatus.
- the data processing status is, for example, an application status or data usage status in the receiving apparatus.
- the receiving apparatus 30 selects and acquires a class of service workers (SW) that is optimal for the receiving apparatus 30 from among a plurality of classes of service workers (SW) that are distributed simultaneously. For this process, for example, it is necessary for a client application running on the browser of the receiving device 30 to select and register an optimum service worker (SW).
- each class set in the service worker (SW) is set to select and acquire what kind of data, that is, a class service reflecting what caching policy.
- signaling data metadata
- the SW class class that reflects the caching policy
- USD which is one of the signaling data.
- the caching policy class referred to here is, for example, a class reflecting a preference analyzed from an end user application execution history or the like on the receiving device 30 side.
- the following class can be set, and the receiving apparatus can select and acquire a service worker (SW) of the class and apply the class.
- SW service worker
- SW class of service worker
- SW service workers
- the receiving device 30 is notified of the class of the service worker (SW) using signaling data such as USD, and the receiving device 30 selects and acquires the optimum service worker (SW) for the own device based on the signaling data.
- the receiving device 30 can acquire (cash) optimal data according to the situation on the receiving device 30 side and the user's preference.
- the receiving device (client) 30 acquires the URL of the application to be acquired by processing of a broadcast stream playback application (executed in a browser or a native environment) being executed in the receiving device 30.
- a broadcast stream of a specific program includes trigger information for notifying a URL for starting the application, and the playback application can acquire a URL for acquiring the application based on the trigger information.
- the receiving device 30 uses this URL to extract an application specified by the URL from the broadcast stream, or acquires the application via the network and executes the application on the browser.
- the application is a service worker (SW) [SW. js] is acquired and registered.
- SW. js in js means JavaScript (registered trademark).
- A Broadcast server that is the transmission device 20
- Data distribution server that is the transmission device 20
- Middleware that is a component of the reception device 30
- Proxy server that is a component of the reception device 30
- Reception Output control unit which is a component of device 30
- Step S211 First, the output control unit, which is a component of the receiving device 30, acquires the segment URL that is the access information of the content storage segment described in the MPD that is the control file for DASH streaming of the broadcast content stream, and acquires the acquired segment URL Is used to execute an acquisition request for a content segment file storing broadcast content.
- content transmission from the transmission device 20 to the reception device 30 is executed in accordance with, for example, the MPEG-DASH standard, which is a standard of adaptive (adaptive) streaming technology.
- the transmitting apparatus 20 that performs data transmission according to the MPEG-DASH standard transmits the following plural types of data.
- the AV segment 60 is composed of images (Video) and audio (Audio) data to be played back by the receiving device, that is, program content provided by a broadcasting station, for example.
- the signaling data 50 includes guide information including program schedule information such as a program guide, address information (URL and the like) necessary for program acquisition, and information necessary for content reproduction processing, such as codec information (encoding method and the like). It consists of information and control information.
- the other data 70 includes, for example, ESG (Electronic Service Guide), NRT content, and the like.
- the ESG is an electronic service guide, and is guide information such as a program guide.
- NRT content is non-real-time content.
- the NRT content includes, for example, various application files executed on the browser of the receiving device as a client, data files such as moving images and still images, and the like.
- a service worker (SW) is also included in the NRT content.
- MPD Media Presentation Description
- Metadata is a manifest file for describing metadata that is management information of moving images and audio files. Specifically, for example, distribution start time information of program content distributed by a broadcasting station, access information for an AV segment, and the like are recorded.
- step S211 the output control unit of the receiving device 30 acquires the segment URL that is the access information of the content storage segment described in the MPD that is the DASH streaming control file of the broadcast content stream, and uses the acquired segment URL.
- the content segment file acquisition request is executed to the proxy server.
- Step S212 if the content segment file identified by the segment URL is stored in the cache managed by the proxy server, the proxy server of the receiving device 30 acquires the content segment file from the cache and acquires the file. Is returned to the output control unit as a response. On the other hand, if the proxy server of the receiving device 30 determines in step S213 that the content segment file identified by the segment URL is not stored in the cache managed by the proxy server, the proxy server sends a content segment file acquisition request to the middleware. Output.
- Step S214 The process in step S214 indicates a process that is continuously executed by the broadcast server 21.
- the broadcast server 21 continuously provides the receiving device 30 with signaling data (metadata, etc.) including control information, management information, and the like related to the distribution content in conjunction with the distribution of the program content.
- Step S215 The processing in step S215 is executed by the middleware when a request for a content segment file is generated from the proxy server in step S213. Based on the signaling data (metadata) received from the broadcast server 21, the middleware determines whether or not the content segment file requested for acquisition from the proxy server can be received by broadcasting, and notifies the proxy server of the determination information. .
- Step S216 When the proxy server receives notification from the middleware that the content segment file can be received by broadcasting, it waits for the segment file to be expanded (stored) in the proxy server management cache. On the other hand, when a notification that the content segment file cannot be received by broadcasting is received from the middleware, a request for acquiring the segment file via the network is executed to the data distribution server 22.
- Steps S217 to S2128 The processes in steps S217 to S218 are executed when the content segment file requested for acquisition from the proxy server can be received by broadcasting.
- the broadcast server 21 transmits the content segment file by broadcast waves in step S217.
- the middleware of the receiving device 30 receives the segment file transmitted from the broadcast server 21 and expands (stores) it in the management cache of the proxy server.
- Step S219 The process of step S219 is a process executed when the content segment file requested for acquisition from the proxy server cannot be received by broadcasting.
- the data distribution server 22 transmits the content segment file requested from the receiving device 30 to the receiving device 30 in step S219.
- the proxy server of the receiving device 30 receives the transmitted segment file and expands (stores) it in the management cache of the proxy server.
- Step S220 The content segment file acquired from the broadcast server 21 or the data distribution server 22 and stored in the proxy server management cache is provided from the proxy server to the output control unit in step S220.
- step S221 the output control unit of the receiving device 30 starts playing the content acquired from the proxy server. Furthermore, the trigger information included in the content is acquired at the time of content playback, the application URL that is the access information of the application corresponding to the content recorded in the trigger information is acquired from the trigger information, and the application acquisition request to which the acquired application URL is applied To the proxy server.
- Step S223 The process of step S223 is an application acquisition and execution process set for the content (for example, a broadcast program) being reproduced in step S221.
- processing similar to the processing in steps S212 to S219 is executed for the application file. That is, a process in which “segment file” shown in steps S212 to S219 is replaced with “application file” is executed, an application file is acquired from the broadcast server 21 or the data distribution server 22, and is stored in the management cache of the proxy server. Store. If the target application file has already been expanded (stored) in the management cache of the proxy server, a new acquisition process is not necessary.
- Step S224 The application file acquired from the broadcast server 21 or the data distribution server 22 and stored in the proxy server management cache is provided from the proxy server to the output control unit in step S224.
- step S225 the output control unit of the receiving device 30 executes the application acquired from the proxy server.
- the application For example, Web page display processing and the like are executed in conjunction with display of program content. The processing contents differ depending on the application, and data display is not always executed.
- Step S226 The process of step S226 is a process executed under the control of the application being executed in step S225, and is a service worker (SW) acquisition and execution process.
- processing similar to the processing in steps S212 to S219 processing (A-1 to 2)) is executed for the service worker (SW) file. That is, the process of replacing the “segment file” shown in the processes of steps S212 to S219 with the “service worker file” is executed, and the service worker file is acquired from the broadcast server 21 or the data distribution server 22 to manage the proxy server. Store in cache. If the target service worker file has already been expanded (stored) in the management cache of the proxy server, a new acquisition process is not necessary.
- Step S227) The service worker file acquired from the broadcast server 21 or the data distribution server 22 and stored in the proxy server management cache is provided from the proxy server to the output control unit in step S227.
- Step S228) the output control unit of the receiving device 30 executes a service worker registration process acquired from the proxy server. Specifically, processing for storing the service worker (SW) in the storage unit (permanent cache) is executed.
- SW service worker
- SW Class setting for service worker
- the transmission device 20 simultaneously distributes various different classes of service workers (SW) in parallel, and the reception device 30 selectively acquires one class of service workers (SW) from these multiple classes of service workers (SW). A filtering process is performed.
- the application executed in the receiving device 30 or the service worker (SW) sets filtering information for the newly acquired service worker (SW) for the middleware of the receiving device 30. That is, the service worker (SW) class setting for which class of service worker (SW) should be acquired is performed.
- the middleware of the receiving device 30 executes the filtering process based on the service worker (SW) class setting information, and the service workers of classes specified from the various classes of service workers (SW) transmitted by the transmission ratio device 20 ( Select and acquire only SW).
- SW service worker
- the pre-filtering is, for example, a process of specifying (scoping) a search range when searching for a URL of a target file (for example, a service worker (SW) file of a specified class) from signaling data.
- a target file for example, a service worker (SW) file of a specified class
- the target file URL can be searched only from the signaling data of the channel provider (broadcast station) that is the provider of the specific application.
- a search scope token which will be described later, is used.
- the middleware receiving the broadcast signaling data corresponds to the corresponding service worker (SW) class in the signaling data based on the set service worker (SW) class. It is determined whether there is a file delivery session to be performed. Furthermore, reception scheduling is performed, and when the designated service worker (SW) is distributed via broadcasting, the service worker (SW) is automatically selected and acquired by the filtering module and developed in the cache of the local proxy server. It becomes possible. With respect to the files developed in the proxy server cache, it becomes possible to immediately respond to the request from the client application.
- a service worker (SW) class setting process and a service worker (SW) acquisition process sequence will be described with reference to sequence diagrams shown in FIGS. 11 to 12 show the following components from the left.
- Step S251 The process of step S251 is executed by an application executed by the output control unit of the receiving device.
- the application executes a service worker (SW) class setting request to the middleware.
- SW service worker
- the signaling analysis unit 113 of the middleware 110 shown in FIG. 7 is notified of token information indicating which class of service worker (SW) access information included in the signaling data should be detected, thereby performing signaling analysis.
- the service worker (SW) access information of the class to be detected is set to a state that can be discriminated by the unit 113.
- the application determines an optimum class based on, for example, environment attributes (state information) of the receiving device (client) and statistical information on usage history of the application and reproduction data.
- This class determination algorithm may be held by the application itself, or may be obtained by using a program or API that can be used by the application.
- Steps S252 to S253 The processes in steps S252 to S253 are executed by an application and a service worker executed by the output control unit of the receiving device.
- the service worker (SW) class setting process for the middleware may be executed as an application process as described in step S251, or may be executed as a service worker (SW) process.
- the processes in steps S252 to S253 are performed when a service worker (SW) class setting process for middleware is executed as a service worker (SW) process.
- step S252 the application executes a service worker (SW) registration process and starts a service worker (SW) process.
- the service worker (SW) is stored in the storage unit (permanent cache) and can be used anytime.
- the registered service worker (SW) executes a service worker (SW) class setting request to the middleware.
- the setting of the service worker (SW) class is the same process as the process of step S251. That is, for example, the signaling analysis unit 113 of the middleware 110 illustrated in FIG. 7 is notified of token information indicating which class of service worker (SW) access information is included in the signaling data, and the signaling analysis unit 113 is notified.
- the service worker (SW) access information of the class to be detected is set to a discriminable state.
- Step S254 The processing in step S254 is signaling data transmission processing that is continuously executed by the broadcast server.
- this signaling data for example, access information for acquiring service workers (SW) corresponding to various classes is recorded.
- Step S255 The process of step S255 is a middleware process of the receiving device 30.
- this is middleware processing that performs processing such as data reception and analysis of received data.
- the middleware sets the service worker (SW) class notified from the application or service worker (SW), and based on the set service worker (SW) class, the service worker (SW) of the class set from the signaling data Access information detection is performed.
- Step S256 the middleware of the receiving device 30 acquires the distribution schedule information of the acquisition target file based on the access information acquired from the signaling data, and starts the service worker (SW) stored file acquisition process using these. To do.
- Step S257 The process of step S257 is a transmission process of various files continuously executed by the broadcast server.
- the transmission file includes an application, application-related data such as a data file used when the application is executed, and a service worker (SW).
- SW service worker
- Step S258 The process of step S255 is a middleware process of the receiving device 30.
- the middleware selectively acquires a file to be acquired from the transmission file of the broadcast server, and expands (stores) the acquired file in the management cache of the proxy server.
- the service workers (SW) transmitted from the transmission device 20 are various classes of service workers (SW), and the reception device 30 is able to select a specific class of service workers (SW) from these many classes of service workers (SW). It is necessary to select and acquire only.
- SW service workers
- applications applications
- data files provided via broadcast waves are set corresponding to individual programs, and the number of files transmitted by the transmission device 20 may be enormous. is expected.
- the receiving device 30 needs to select and acquire a class of service workers (SW) most suitable for the own device from the enormous number of transmission files.
- the service worker (SW) is sequentially transmitted as a NRT content via a broadcast wave.
- the URL corresponding to the file which is access information necessary for acquiring a file such as a service worker (SW), the transmission timing information of each file, etc. is recorded in the signaling data (metadata) and provided to the receiving device 30 Is done.
- the receiving device 30 can analyze the signaling data (metadata) and know the URL and transmission timing of the file to be acquired.
- Signaling data has a configuration in which various information (metadata) for each service unit is recorded, for example, using one channel or one program as one service unit.
- Metadata with a description of service A Metadata with a description of service B
- Metadata with a description of service C Metadata with a description of service C
- metadata in service units program units and channel units
- the metadata for each service unit has metadata for each file transfer session as lower-level metadata.
- Access information of a file transferred in each session is recorded in the metadata for each file transfer session. Using this access information, the receiving device 30 obtains the file access information that matches the URL of the necessary file, obtained by the processing of the signaling analysis unit 113 and the address resolution unit 123 described above with reference to FIG. And get the file.
- the receiving device 30 cannot know in which metadata of the signaling data the access information of the necessary file is recorded. Therefore, it is necessary to examine all access information recorded in the synering data as a search target, and a long time is required for the search time.
- the token and the URL are search auxiliary information for efficiently searching for access information (metadata) related to the acquisition scheduled data of the receiving device 30.
- search assistance for efficiently searching for access information related to resources (application application related data) that are data to be managed by a specific class of service workers (SW) or a specific class of service workers (SW) Information.
- FIG. 14 shows a configuration example of signaling data (metadata) similar to FIG.
- the signaling data (metadata) has a configuration in which various information (metadata) of each service unit is recorded, for example, using one channel or one program as one service unit.
- Metadata with a description of service A Metadata with a description of service B
- Metadata with a description of service C Metadata with a description of service C
- metadata in service units program units and channel units
- the metadata for each service unit has metadata for each file transfer session as lower-level metadata.
- the metadata 151 having the description of service A includes a description of the token ⁇ SW-Scope>.
- the metadata 153 having the description of the file transfer session 1 which is the metadata of the lower-level session unit included in the metadata 151 includes a description of the file URL.
- These ⁇ SW-Scope>, ⁇ SW-Class>, and file URL are data described as tokens that are applied to improve the access information of the acquired file in the receiving device.
- the token ⁇ SW-Scope> recorded in the metadata 151 is a token used to limit the search range of metadata in which access information to be searched is recorded, “Service Worker (SW) Search Scope Token” It is.
- the token ⁇ SW-Class> recorded in the metadata 152 is a token indicating that URL information related to a specific SW management or update target file (cache target file) is recorded together. , "Service worker (SW) class designation token” It is. These tokens are all set as tokens corresponding to a specific service worker (SW).
- “Service worker (SW) search scope token ⁇ SW-Scope>” indicates that the file access information of a specific class of service worker (SW) to be acquired is stored in the metadata in which this token is recorded or in the metadata below it. Is a token indicating that it is recorded in
- the receiving device 30 selects the metadata in which the token is recorded, and performs a search using the metadata and the metadata lower than the metadata as a search range, the service worker of the class to be acquired by the receiving device ( SW) File access information can be acquired efficiently. That is, other metadata can be excluded from the search target, and the search efficiency can be improved by limiting the search range.
- the “service worker (SW) class designation token ⁇ SW-Class>” includes, for example, access information of a service worker (SW) file of a class to be acquired by the receiving device in the metadata in which the token is recorded. Is a token indicating a management target file group (group) of a specific service worker (SW) indicating that they are collectively recorded. If the receiving device 30 selects the metadata in which the token is recorded and acquires only the access information recorded in the metadata, the receiving device 30 obtains the access information of the service worker (SW) file of the class to be acquired by the receiving device. Can be acquired efficiently.
- the token and the URL are set as search auxiliary information for efficiently searching for access information (metadata) related to the acquisition scheduled data of the receiving device 30.
- the service worker (SW) search scope token is arranged in the description unit of the signaling data service unit, and the service worker (SW) class designation token is described in the signaling data file transfer session description part.
- the arrangement of the tokens is one example of a token setting that improves search efficiency. By adopting this configuration, it is possible to more efficiently obtain access information when signaling data is received at the receiving device (client).
- the receiving device 30 selectively extracts a service description group having a service worker (SW) search scope token, and then extracts a file transfer session description associated with the service description group and stores it in a service worker (SW) class designation token or a file URL.
- a matching file transfer address (address parameter necessary for acquiring an actual file transferred on the broadcast stream) is searched to acquire a desired file.
- the signaling data (metadata) transmitted from the transmission device 20 to the reception device 30 has a hierarchical configuration as shown in FIG. 14, but more specific configuration examples of signaling data (metadata) and token setting examples Will be described with reference to FIGS.
- the signaling data (metadata) shown in FIG. 15 (1) is service unit metadata (Service) whose highest level is set in units of programs and channels.
- Content unit metadata (Content) is set below the service unit metadata.
- Metadata (Schedule & Access) describing a distribution schedule and access information is set below the metadata (Service) for each service or the metadata (Content) for each content.
- USD user service description
- metadata is set below the metadata (Schedule & Access).
- the USD stores, for example, information related to the distribution method, and includes, for example, the following signaling data.
- SDP session description
- FDD File Delivery Description
- RFD Real Flow Description
- SD stationule description
- USD is a signaling data having a manifest file storing various guidance information and control information corresponding to the content (AV segment).
- MPD Media Presentation Description
- ROUTE metadata in which transfer parameters for individual files to be actually distributed are recorded is set below the USD metadata.
- service metadata 161 “service worker (SW) search scope token ⁇ SW-Scope>” is recorded.
- the receiving device 30 can limit the search range of the URL and access information of the service worker (SW) file of the acquisition scheduled class according to this token. That is, it is possible to set the search range indicated by the dotted frame in the figure and search the URL and access information of the file to be acquired.
- service worker (SW) class designation token ⁇ SW-Class> is recorded in the ROUTE metadata 162 and 163 in the lowest layer.
- the receiving device 30 can know that a specific class of service worker (SW), URL of the management resource file, and access information are recorded in the metadata 162 and 163.
- “service worker (SW) search scope token ⁇ SW-Scope>” is recorded.
- the receiving device 30 can limit the search range according to this token. That is, it is possible to set the search range indicated by the dotted frame in the figure and search the URL and access information of the file to be acquired.
- “service worker (SW) class designation token ⁇ SW-Class>” is recorded in the ROUTE metadata 165 at the lowest layer.
- the receiving apparatus 30 can know that the URL and access information of a specific class of service worker (SW) and an acquisition scheduled file of a group constituting the management resource are recorded in the metadata 165. .
- the receiving device 30 can limit the search range of the URL and access information of the service worker (SW) file of the acquisition scheduled class according to this token. That is, a search can be performed by setting a search range indicated by a dotted frame in the figure.
- “Service worker (SW) class designation token ⁇ SW-Class>” is recorded in the ROUTE metadata 167 at the lowest layer.
- the receiving device 30 can know that the metadata 167 records the URL and access information of a specific class of service workers (SW) and files to be acquired for a group constituting a management resource.
- Token setting example 4 shown in FIG. “Service worker (SW) search scope token ⁇ SW-Scope>” is recorded in the schedule description metadata 168 set in the lower level of the USD metadata.
- the receiving device 30 can limit the search range according to this token. That is, it is possible to set the search range indicated by the dotted frame in the figure and search the URL and access information of the file to be acquired.
- “service worker (SW) class designation token ⁇ SW-Class>” is recorded in the ROUTE metadata 169 at the lowest layer. According to this token, the receiving device 30 can know that the URL and access information of a specific service worker (SW) and an acquisition scheduled file of a group constituting the management resource are recorded in the metadata 169.
- token setting examples for signaling data Although a plurality of examples of token setting examples for signaling data have been described with reference to FIGS. 15 to 17, token setting in various modes is possible.
- the receiving device 30 can efficiently acquire the URL and access information of the file to be acquired based on the token included in the signaling data. For example, the receiving device 30 notifies the middleware receiving broadcast data of token information for token detection for detecting tokens to be applied to filtering processing such as limitation of the search range and group specification of the search target file described above.
- the signaling data transmitted from the transmission device 20 is analyzed to detect the token, and an efficient search process using the detected token is performed, and the storage unit (permanent cache) URL information, access information, distribution schedule information, and the like necessary for acquiring the file stored in the file are acquired.
- distribution schedule information for each file is also recorded along with the file URL.
- the token information setting process for the middleware can be executed by outputting a request to the server side script on the proxy server using ajax, for example.
- the token information setting mode includes the following setting modes. (1) Service worker (SW) class designation token (SW-Class) (2) Service worker (SW) search scope token (SW-Scope) +) Service worker (SW) class designation token (SW-Class)
- a service worker (SW) class identifier or the like is used.
- a file URL of a service worker (SW) corresponding to a specific class may be used.
- the file URLs of these resources may be specified together with the tokens as parameters.
- the service worker (SW) acquired by the receiving device 30 is stored in the storage unit (persistent cache) of the receiving device together with resources (applications and application-related data) to be managed by the service worker (SW), and can be used anytime. It becomes a setting.
- the service worker (SW) can set a use time limit, and the receiving device 30 can replace the service worker (SW) that has been used by the receiving device with a new service worker (SW) as needed.
- Service worker (SW) update processing to be replaced with can be performed.
- the service worker (SW) is acquired from the transmission device 20 such as the broadcast server 21 or the data distribution server 22 by an acquisition request using an application set corresponding to predetermined content (program), for example.
- predetermined content program
- “HTTP response header: Cache-control” which is communication data from the transmission device 20 to the reception device 30 during the service worker (SW) provision processing.
- the expiration date of the service worker (SW) can be designated.
- the service worker (SW) stored in the storage unit (permanent cache) of the receiving device 30 by the service worker registration process executed by the process of the application set corresponding to the predetermined content (program) is, for example, Expiration date confirmation processing and update processing are executed by the browser executed in the output control unit of the receiving apparatus.
- the browser checks the expiration date for each of a plurality of service workers (SW) stored in the storage unit (persistent cache) of the receiving device 30, and automatically makes an acquisition request to the local proxy server when the expiration date is reached. Is updated, the service worker (SW) is re-registered, that is, the update process is executed. Or, when a certain period of time set by the browser (for example, once a day) has passed, an acquisition request is automatically made to the local proxy server for the service worker (SW), and re-registration processing is performed if the contents are updated. Made.
- SW service workers
- a service worker (SW) update processing sequence will be described with reference to sequence diagrams shown in FIGS. 18 to 19 show the following components from the left.
- (A) Broadcast server constituting the transmission device (b) Data distribution server constituting the transmission device (c) Middleware of the reception device (d) Browser executed by the output control unit of the reception device (E) Service worker (SW) executed on the browser executed by the output control unit of the receiving device Each of these components is shown. The processing of each step shown in the sequence diagrams of FIGS. 18 to 19 will be described sequentially.
- Step S271 The processing in step S271 is signaling data transmission processing that is continuously executed by the broadcast server. For example, the token described above with reference to FIGS. 14 to 17 is set in the signaling data.
- Step S272 The process of step S272 is a middleware process of the receiving device 30.
- this is middleware processing that performs processing such as data reception and analysis of received data.
- the middleware sets token information notified from an application or a service worker (SW), and executes token (or file URL) detection from signaling data based on the set token information.
- SW service worker
- Step S273 The process of step S273 is a transmission process of various files continuously executed by the broadcast server.
- the transmission file includes an application, application-related data such as a data file used when the application is executed, and a service worker (SW).
- SW service worker
- Step S274 The processing in step S274 is middleware processing of the receiving device 30.
- the middleware selectively acquires a file to be acquired from the transmission file of the broadcast server, and expands (stores) the acquired file in the management cache of the proxy server.
- the cache data includes application-related data such as an application, a data file used when the application is executed, and a service worker (SW).
- the service worker (SW) includes an updated version of the service worker (SW) held by the receiving device 30.
- Step S275 is browser processing executed by the output control unit of the receiving apparatus.
- the browser confirms the expiration date for each of a plurality of service workers (SW) stored in the storage unit (permanent cache) of the receiving device 30, and automatically makes an acquisition request to the local proxy server when the expiration date is reached.
- SW service workers
- a certain time limit for example, once a day
- an acquisition request is automatically made to the local proxy server for the service worker (SW).
- Step S276 The process of step S276 is a middleware process of the receiving device 30.
- the middleware searches the management cache of the proxy server for the updated service worker (SW) requested for acquisition from the browser, and if detected, outputs the updated service worker (SW) to the browser.
- SW updated service worker
- Step S277 is browser processing executed by the output control unit of the receiving apparatus.
- the browser registers the updated service worker (SW) received from the proxy server. That is, it is stored in a storage unit (permanent cache).
- Step S278 is a service worker (SW) process executed by the output control unit of the receiving apparatus.
- the updated service worker (SW) executes a token information setting request to the middleware as necessary.
- the setting of token information is the same process as the process of step S251 in FIG. That is, for example, the signaling analysis unit 113 of the middleware 110 illustrated in FIG. 7 is notified of token information indicating which class of service worker (SW) access information is included in the signaling data, and the signaling analysis unit 113 is notified.
- the access information of the service worker (SW) of the class to be detected is set to a discriminable state.
- Step S279 The process of step S279 is a middleware process of the receiving device 30.
- this is middleware processing that performs processing such as data reception and analysis of received data.
- the middleware sets the token information notified from the updated service worker (SW), and executes token (or file URL) detection from the signaling data based on the set token information.
- the service worker (SW) stored in the receiving device 30 controls the storage unit (persistent cache) in which these resources are stored, that is, the management target resource, that is, the application or application-related data, as one of the management processes. Perform cache control.
- the service worker (SW) stores a file necessary for an application that has started itself in a storage unit (permanent cache) of the receiving device 30 in response to detection of a predetermined event.
- the timing of receiving an event that triggers resource storage by the service worker (SW) is during the registration process or re-registration (update) process of the service worker (SW). At these times, the service worker (SW) receives an install event.
- the application requests an HTML page or JavaScript (registered trademark) (receives a fetch event), or when the service worker (SW) is restarted by a timer generated by itself, the above resource storage is performed. Receive an event that triggers processing.
- the application (parts group) developed by the service worker (SW) in the storage unit (persistent cache) is not only started accompanying (simultaneously) with the broadcast stream, but also installed on the client independently of the broadcast stream. It can be started as an application (offline application).
- FIGS. 20 to 21 show the following components from the left.
- A Broadcast server constituting transmission device
- b Data distribution server constituting transmission device
- Middleware of reception device d
- Proxy server of reception device e
- F Service worker (SW) executed on the browser executed by the output control unit of the receiving device
- G Application executed on browser executed by output control unit of receiving device
- h Native application executed by output control unit of receiving device
- the native application is an application executed by the receiving device 30, but is not an application under the control of the service worker (SW), but an application used for, for example, activation processing of a content (program) compatible application. .
- SW service worker
- an application used for, for example, activation processing of a content (program) compatible application for, for example, activation processing of a content (program) compatible application.
- Step S301 The process in step S301 is an activation process of an application corresponding to content (program) by a native application.
- the native application is an application used for activation processing of an application corresponding to content (program). For example, when the application corresponding to the content (program) is set to be activated based on trigger information embedded in the program, the activation process by the native application is unnecessary.
- Step S302 the started application executes a service worker (SW) registration process.
- the service worker (SW) is stored in the storage unit (permanent cache) and can be used anytime.
- This service worker (SW) registration process is grasped from the service worker (SW) itself as detection of a registration (install) event, and the service worker (SW) is triggered by the detection of the registration (install) event, step S303. Start the cache control.
- Step S303 When the service worker (SW) detects a registration (install) event, in step S303, the service worker (SW) starts controlling the storage unit (persistent cache) according to, for example, a script description. Specifically, acquisition of a specific class of service workers (SW) or resources (applications and application-related data) to be managed by the specific class of service workers (SW) and cache expansion (storage) processing are started.
- SW specific class of service workers
- resources applications and application-related data
- step S304 a specific class of service workers (SW) or resources (applications or application-related data) to be managed by the specific class of service workers (SW) are transmitted in step S304, such as a broadcasting server or a data distribution server. Continuously sent from.
- step S304 the processing for the segment file in each step of FIGS. 8 to 9 (A-1 to 2) in the resource transmission / reception processing described with reference to FIGS. 8 to 9 is replaced with processing for the resource. Executed.
- step S305 the transmission data is expanded (stored) in the storage unit (persistent cache) via the management cache of the proxy server.
- Step S306 the application requests an application part, for example, a moving image file or a still image file necessary for execution of the application, application related data such as a JavaScript (registered trademark) program, audio data, or the like to the service worker (SW).
- This request processing corresponds to detection of a fetch event in the service worker (SW).
- the service worker (SW) acquires the requested parts from the storage unit (permanent cache) and provides them to the application.
- Steps S310 to S311) The processes in steps S310 to S311 are processes when an activation event is detected by the service worker (SW).
- the activate event is detected, for example, when an input of a resource deletion request is executed by a user or when an application expires.
- the service worker (SW) detects an activate event, for example, control of the storage unit (persistent cache) according to the script description is started. Specifically, a specific class of service workers (SW) or resources (applications and application related data) to be managed by the specific class of service workers (SW) are deleted.
- Steps S312 to S315) The processing in steps S312 to S315 is processing when a timer event is detected by the service worker (SW).
- the timer event is detected, for example, when the expiration date of the application has expired or when the update deadline has come.
- processing corresponding to the timer event there is, for example, deletion of cache resources or acquisition processing of update resources or additional resources.
- Step S313 is a sequence of cache resource deletion processing according to the timer event.
- Steps S314 to S315 show a sequence of processing for acquiring update resources and additional resources according to timer events.
- step S314 the processing for the segment file in each step of FIGS. 8 to 9 (A-1 to 2) in the resource transmission / reception processing described above with reference to FIGS. 8 to 9 is replaced with processing for resources. Processing is executed.
- SW Service worker (SW) distribution and cache control processing (push-type processing example)
- SW service worker
- a resource that includes data to be applied to an application to be managed by the service worker (SW) for example, triggered by an acquisition request from a browser installed in the receiving device 30
- the processing described with reference to FIGS. 8 to 21 acquires a service worker (SW) and its management resources (application and application related data) triggered by an acquisition request from a browser installed in the receiving device 30. It is an example of a polling type process.
- a push-type processing example that acquires the service worker (SW) and its management resources (application and application-related data) and provides them to the browser regardless of the acquisition request from the browser will be described.
- the middleware is requested to expand (store) the file specified by the token information (or file URL) in the cache of the local HTTP proxy server.
- an application or a service worker (SW) that has requested setting of token information cannot passively detect whether or not a file selected according to the token has been expanded (stored) in the proxy server cache.
- sequence described with reference to FIGS. 11 to 12 is a model that pulls in application parts and service workers (SW) from the proxy server in a polling type from the browser (application) side.
- SW application parts and service workers
- Step S321 The process in step S321 is executed by an application executed by the output control unit of the receiving device.
- the application executes a token information setting request to the middleware.
- the signaling analysis unit 113 of the middleware 110 shown in FIG. 7 is notified of token information indicating which class of service worker (SW) access information included in the signaling data should be detected, thereby performing signaling analysis.
- the access information of the service worker (SW) of the class to be detected is set to a state that can be discriminated by the unit 113.
- a service worker (SW) identifier or the like is notified and set as token information.
- step S321a and b the event registration and consent processing shown in steps S321a and b is executed between the application, middleware, and between the middleware and the transmission device (broadcast server, data distribution server).
- data application, application-related data, service worker (SW), etc.
- SW service worker
- it is a process for confirming that each device or component accepts and executes the process of notifying the application.
- Steps S322 to S323 The processes in steps S322 to S323 are executed by an application and a service worker executed by the output control unit of the receiving device.
- the token information setting process for the middleware may be executed as an application process as described in step S321, but may be executed as a service worker (SW) process.
- the processes in steps S322 to S323 are performed when the token information setting process for the middleware is executed as a service worker (SW) process.
- step S322 the application executes a service worker (SW) registration process, and starts a service worker (SW) process.
- the service worker (SW) is stored in the storage unit (permanent cache) and can be used anytime.
- the registered service worker (SW) executes a token information setting request to the middleware.
- the setting of token information is the same process as the process of step S321. That is, for example, the signaling analysis unit 113 of the middleware 110 illustrated in FIG. 7 is notified of token information indicating which class of service worker (SW) access information is included in the signaling data, and the signaling analysis unit 113 is notified.
- the access information of the service worker (SW) of the class to be detected is set to a discriminable state.
- steps S322 to S323 When the processes in steps S322 to S323 are executed, the events shown in steps S323a and b are performed in parallel with these processes, between the application and the middleware, and between the middleware and the transmission apparatus (broadcast server and data distribution server). Perform registration and consent processing. This is because data (application, application-related data, service worker (SW), etc.) transmitted from the transmitting device (broadcast server, data distribution server) to the receiving device is expanded (stored) in the proxy server management cache of the middleware. In this case, it is a process for confirming that each device or component accepts and executes the process of notifying the application.
- data application, application-related data, service worker (SW), etc.
- Step S324 The processing in step S324 is signaling data transmission processing that is continuously executed by the broadcast server.
- the token described above with reference to FIGS. 14 to 17 is set in the signaling data.
- Step S325 The process of step S325 is a middleware process of the receiving device 30.
- this is middleware processing that performs processing such as data reception and analysis of received data.
- the middleware sets token information notified from an application or a service worker (SW), and executes token (or file URL) detection from signaling data based on the set token information.
- the middleware of the receiving device 30 determines an acquisition target file based on the token (or file URL), and starts a file acquisition process according to the distribution schedule information of the selected file.
- Step S326 The process of step S326 is a transmission process of various files continuously executed by the broadcast server.
- the transmission file includes an application, application-related data such as a data file used when the application is executed, and a service worker (SW).
- SW service worker
- Steps S327 to S328 The process of step S327 is a middleware process of the receiving device 30.
- the middleware selectively acquires a file to be acquired from the transmission file of the broadcast server, and expands (stores) the acquired file in the management cache of the proxy server.
- step S327 When the process of step S327 is executed, the event notification process shown in steps S328a to d is executed between each device and each component. This is because data (application, application-related data, service worker (SW), etc.) transmitted from the transmitting device (broadcast server, data distribution server) to the receiving device is expanded (stored) in the proxy server management cache of the middleware. This is a process of notifying the application or service worker (SW) of the fact.
- four event notification lines of steps S328a to S328 are shown. However, for steps S328a and b, any device that has performed data transmission may perform event notification. Further, the notification processing from the middleware in steps S328c and d may be executed only for the token information setting request issuer, that is, only one of the application and the service worker (SW).
- a token (or file URL) setting by push API and a push event request event are registered in a push event server (publisher) mounted on the ATSC 3.0 client broadcast middleware.
- the push event server registers a push event request event to the transmission device via the network as necessary.
- the middleware When the data filtered by the set token (or file URL) is expanded on the proxy server, the middleware notifies the push event client (application or service worker (SW)) of the push event.
- the push event client application or service worker (SW)
- an acquisition request (drawing into the browser cache) can be made, so that when files are accumulated on the client side via broadcasting, they can be used immediately on the browser side It becomes possible.
- the push event can be sent and received via the Internet so that the client side can detect the fact of file transfer even when the client broadcast middleware is not tuned to the file transfer stream. is there.
- Service worker (SW) update process Next, service worker (SW) update processing in the case of executing push-type processing will be described. As described above, the service worker (SW) can set a usage time limit, and the receiving device 30 can use the service worker (SW) held by the receiving device for a new service if necessary. Service worker (SW) update processing for replacement with a worker (SW) can be performed.
- the polling type service worker (SW) update processing sequence is the sequence described above with reference to FIGS.
- push-type processing a push-type event notification mechanism that uses a push API or the like that notifies the browser of cache expansion when update service worker (SW) is expanded (stored) in the middleware management cache. Perform the process used.
- FIG. 24 shows the following components from the left.
- A Broadcast server constituting the transmission device
- b Data distribution server constituting the transmission device
- c Middleware of the reception device
- d Browser executed by the output control unit of the reception device
- E Service worker (SW) executed on the browser executed by the output control unit of the receiving device
- event registration and acceptance processing have already been performed between the devices and components similar to those illustrated in FIG. That is, for example, event registration and consent processing shown in steps S321a and b shown in FIG. 22 are executed between the application, middleware, and between the middleware and the transmission device (broadcast server, data distribution server). This is because data (application, application-related data, service worker (SW), etc.) transmitted from the transmitting device (broadcast server, data distribution server) to the receiving device is expanded (stored) in the proxy server management cache of the middleware. In this case, it is a process for confirming that each device or component accepts and executes the process of notifying the application.
- data application, application-related data, service worker (SW), etc.
- the sequence shown in FIG. 24 corresponds to the process after these event registration and consent processes are executed.
- the processing of each step shown in the sequence diagram of FIG. 24 will be described sequentially.
- Step S351 In steps S351a to d, data (update service worker (SW) in this example) transmitted from the transmission device (broadcast server, data distribution server) to the reception device is expanded (stored) in the proxy server management cache of the middleware. This is a process of notifying the application or service worker (SW) of the fact.
- the figure shows four event notification lines in steps S351a to S351d. However, for steps S351a and b, any device that has performed data transmission may perform event notification. Further, the notification processing from the middleware in steps S351c and d may be executed only for either the application or the service worker (SW).
- Step S352 is browser processing executed by the output control unit of the receiving apparatus. Based on the event notification, the browser makes an acquisition request to the local proxy server of the update service worker (SW).
- Step S353 The process of step S353 is a middleware process of the receiving device 30.
- the middleware searches the management cache of the proxy server for the updated service worker (SW) requested for acquisition from the browser, and if detected, outputs the updated service worker (SW) to the browser.
- SW updated service worker
- Step S354 is browser processing executed by the output control unit of the receiving apparatus.
- the browser registers the updated service worker (SW) received from the proxy server. That is, it is stored in a storage unit (permanent cache).
- Step S355 is a service worker (SW) process executed by the output control unit of the receiving apparatus.
- the updated service worker (SW) executes a token information setting request to the middleware as necessary.
- the setting of token information is the same process as the process of step S251 in FIG. That is, for example, the signaling analysis unit 113 of the middleware 110 illustrated in FIG. 7 is notified of token information indicating which class of service worker (SW) access information is included in the signaling data, and the signaling analysis unit 113 is notified.
- the access information of the service worker (SW) of the class to be detected is set to a discriminable state.
- step S355a the event registration / acceptance process shown in step S355a is executed.
- This is a process for notifying a service worker (SW) or an application when data corresponding to token information is expanded (stored) in a middleware proxy server.
- Step S356 The process of step S356 is a middleware process of the receiving device 30.
- this is middleware processing that performs processing such as data reception and analysis of received data.
- the middleware sets the token information notified from the updated service worker (SW), and executes token (or file URL) detection from the signaling data based on the set token information.
- SW updated service worker
- FIG. 25 is a diagram illustrating a configuration example of signaling data (metadata) transmitted from the transmission device 20 such as the broadcast server 21.
- the signaling data has the following three layers as shown in FIG. (1) Service layer (OMA-ESG) (2) File transfer session layer (3GPP-MBMS-USD) (3) FLUTE (ROUTE) parameter layer (FLUTE (ROUTE))
- the service layer is a layer that describes service and content attribute information specifically for user presentation.
- the file transfer session layer is a layer describing file transfer parameters and the like.
- the FLUTE (ROUTE) parameter layer is a layer describing parameters corresponding to the FLUTE (ROUTE) protocol.
- the following attribute information (element) recording area (fragment) is set below an OMA-ESG (Open Mobile Alliance-Electronic Service Guide) for recording a so-called program guide.
- a plurality of attribute information (element) recording areas (fragments) are set in the OMA-ESG, but the attribute information (element) recording areas (fragments) described in (a) to (e) above are set.
- An example in which is set as the token recording area will be described later.
- the arrows shown in the figure indicate the reference relationship between each attribute information (element) recording area (fragment).
- an arrow extending from (a) service fragment to (d) schedule fragment indicates that (a) distribution schedule information corresponding to each service (for example, channel or program) recorded in the service fragment is (d) Indicates that it is recorded in the fragment.
- the fragment suitable for storing a token includes the following attribute information (element) recording area (fragment) as described above.
- a service fragment is a fragment that describes attributes of a service layer such as a channel or a streaming service.
- a content fragment (Content Fragment) is a fragment that describes each content (a unit of a program or the like when the service describes a channel) that constitutes a service fragment (Service Fragment).
- a schedule fragment is a fragment for mapping a service (Service), content (Content), and interactivity data (InteractivityData) on the time axis (program distribution schedule, program presentation schedule, etc.) .
- An access fragment is a fragment for describing an address of an actual file or stream together with a schedule schedule distribution schedule.
- a private extension (PrivateExtension) element which is an extension area capable of recording various data.
- a new organization is required to add a functional element using this schema definition in a standardization organization different from OMA, various elements should be additionally specified under this extended area. Can do.
- the schema is extended by OMA itself, or when another standardization organization itself can change the entire schema, it is defined that the additional element itself is stored on the private extension (PrivateExtension) element.
- Service Fragment (Service Fragment) has the configuration shown in FIG. As shown in FIG. 26, the token recording area 202 can be set below the private extension (Private Extension) data recording area 201.
- service worker (SW) search scope token ⁇ SW-Scope> is recorded in the service metadata 161 shown in FIG. 15 (1) token setting example 1 described above with reference to FIG. Corresponds to the example.
- a token is recorded as, for example, XML data.
- An example of an XML instance of a service fragment (Service Fragment) has the following settings, for example.
- the USD (User Service Description) is a hub element that stores the attributes of transport sessions that constitute a service.
- FIG. 27 shows an example of the overall configuration of USD (User Service Description).
- a USD (User Service Bundle Description) 210 is a set of a plurality of USD (User Service Description) 211.
- the white diamond-shaped arrow shown in FIG. 27 means that the element on the white arrow side includes a connection element.
- a normal arrow indicates a reference relationship.
- a schedule element 212 is set below the USD (User Service Description) 211. Note that the element is the same as the fragment. At the time of the schedule element 212, a schedule description element 213 is set, and a filter description element 214 is set below the schedule description element 213.
- the Schedule element 212 under the USD element 211 describes the delivery schedule of the transport session. Used for filtering to be used when a service (stream session or file session) distributed in this schedule is selectively acquired from a schedule description element 213 referred to by this schedule element 212 A filter description element 214 that stores the parameters can be referenced.
- FIG. 28 shows an example of a hierarchical structure below USD (User Service Bundle Description) 210 constituting signaling data.
- a schedule description URI 212a is recorded as identification information of a schedule description element 213. Based on the schedule description URI 212a, a schedule description element 213 is specified.
- FIG. 29 is a diagram showing a configuration of signaling data below the schedule description element 213.
- An attribute (Attribute) data 222 is set below the Schedule Description element 213, and identification information for identifying a specific filter description element in the attribute (Attribute) data 222 A filter description reference 223 is recorded.
- filter ID filter ID
- attribute attribute
- FIG. 30 shows the data structure of the filter description element 231 specified by the filter description reference 223.
- a filter data element 232 for setting data corresponding to each filter is set.
- attribute (attribute) 233 of the filter data (filterData) element 232 id data 234 corresponding to the filter ID (filter ID) 225 shown in the data configuration of FIG. 29 is recorded.
- the token 235 described above is recorded in the data recording area below the filter data (filterData) element 232.
- the token 235 is recorded as XML data, for example.
- An example of an XML instance of a filter description fragment is as follows, for example.
- ⁇ FilterDescription> ...
- ⁇ FilterData> SW class string ⁇ / SWClass>
- ⁇ / FilterData> ⁇ / FilterDescription>
- the data that the receiving device 30 selectively acquires using the token is a file such as an application and application-related data or a service worker (SW), and these are transferred according to the FLUTE / ROUTE protocol.
- the receiving device 30 needs to identify and acquire a file transferred according to the FLUTE / ROUTE protocol based on, for example, a token described in USD or the like as the signaling data described above.
- a token described in USD or the like as the signaling data described above.
- FIG. 31 is a diagram illustrating an example of a hierarchical configuration below the USD (User Service Bundle Description) 210 that configures signaling data, as described above with reference to FIG. USD (User Service Bundle Description) 210 or less, USD (User Service Description) element 211, Schedule element 212 Each of these elements is set.
- USD User Service Bundle Description
- FIG. 31 is a diagram illustrating an example of a hierarchical configuration below the USD (User Service Bundle Description) 210 that configures signaling data, as described above with reference to FIG. USD (User Service Bundle Description) 210 or less, USD (User Service Description) element 211, Schedule element 212 Each of these elements is set.
- Reference information to FLUTE is stored in a delivery method (deliveryMethod) element 241 set in the USD (User Service Description) element 211 or lower.
- FIG. 32 is a diagram showing an example of reference information to FLUTE set in the delivery method (deliveryMethod) element 241 when file transfer is executed according to the FLUTE protocol.
- FIG. 33 shows a file specifying configuration specified according to this information.
- Any file transferred by the FLUTE (ROUTE) protocol is stored and transferred in an LCT packet above a UDP packet above an IP packet.
- the source IP address (SourceIPAddress)
- the destination IP address (DestinationIPAddress)
- the port number (Port)
- the TSI specified by the SDP is specified. This is performed on a FLUTE session basis).
- the source IP address (SourceIPAddress), the destination IP address (DestinationIPAddress) are used to specify the IP packet, the hort number (Port) is used to specify the UDP packet, and the TSI is used to specify the LCT packet sequence.
- a desired file is specified by a TOI (Transport Object Identifier) stored in the LCT packet.
- An LCT packet with a TOI of 0 stores an FDT (File Description Table).
- FDT File Description Table
- each file URL in FDT-Instance / File / @ ContentLocatoin
- Storage and the corresponding TOI (stored in FDT-Instance / File / @ TOI) is resolved.
- FIG. 34 is a diagram showing an example of reference information to FLUTE set in the delivery method (deliveryMethod) element 241 when file transfer is executed in accordance with the ROUTE protocol.
- FIG. 34 shows a file specifying configuration specified according to this information.
- ROUTE it is specified by a source IP address (SourceIPAddress), a destination IP address (DestinationIPAddress), and a port number (Port) specified by SDP. This is performed on a ROUTE session basis.
- a source IP address (SourceIPAddress) and a destination IP address (DestinationIPAddress) are used for specifying an IP packet, and a Port number is used for specifying a UDP packet.
- LSID (LCT Session Instance Description) is stored in the LCT packet in which the TSI of the LCT packet is 0 and the TOI is 0, and other transport sessions in the ROUTE session (specified by the TSI of the LCT packet)
- the attribute for is stored.
- the relation between the file URL and the corresponding TOI is resolved by the ContentLocation attribute and the TOI attribute which are attributes of the LSID TransportSession / SourceFlow / EFDT / File element.
- the client middleware parses (analyzes) the FLUTE FDT (FDT-Instance) or the ROUTE LSID and knows the file URL transferred in the file transfer session.
- the signaling data (metadata) has the following three layers as shown in FIG. (1) Service layer (OMA-ESG) (2) File transfer session layer (3GPP-MBMS-USD) (3) FLUTE (ROUTE) parameter layer (FLUTE (ROUTE))
- an element suitable for storing a token includes an FDT instance (FDT-Instance) element that describes the entire FLUTE file transfer session, or an attribute of an individual file carried in the session.
- FDT-Instance an FDT instance
- file element that describes.
- a file URL is stored in a content location (Content-Location) attribute that is an attribute of a file (File) element.
- FIG. 36 is a diagram showing a data storage configuration below the FDT instance element in the FLUTE (ROUTE) parameter layer constituting the signaling data.
- FDT instance (FDT Instance) element 301 Attribute 302 corresponding to an FDT instance, A file element 303 is set. Furthermore, below the file element 303, An attribute 304 corresponding to the file is set.
- Attribute 302 corresponding to the FDT instance
- Attribute 304 corresponding to the file (Attribute) 304
- a data recording field (any) in which free data can be stored is set in addition to a recording area of prescribed attribute (Attribute) information. Tokens are recorded in the data recording fields (any) 311 and 312.
- token recording example for example, in the lowermost ROUTE metadata 162 and 163 shown in FIG. 15 (1) token setting example 1 described above with reference to FIG. This corresponds to an example of recording “-Class>”.
- a file URL is recorded in a default content location (Content-Location) recording area in the attribute 304 corresponding to the file.
- the tokens recorded in the data record fields (any) 311 and 312 in the attribute (attribute) 302 corresponding to the FDT instance and the attribute (attribute) (Attribute) 304 corresponding to the file are recorded as XML data, for example.
- an example of an XML instance when a token is stored in an FDT instance (FDT-Instance) element is as follows.
- service worker (SW) search scope token ⁇ SW-Scope> is placed in the attribute of the FDT instance (FDT-Instance) element, it is desired for any of the files in this file transfer session. Indicates that the service worker (SW) related files are stored. On the other hand, when the “service worker (SW) class designation token ⁇ SW-Class>” is arranged, it indicates that all the files in this file transfer session are the desired service worker (SW) related files. .
- SW service worker
- FIG. 38 shows the data structure below LSID defined by ROUTE.
- LSID element 351 Transport Session element 352, Source flow (SourceFlow) element 353, EFDT element 354, File element 355, These hierarchical settings are used.
- SW service worker
- SW search scope token SW class designation token
- A EFDT element 354 unit attribute (Attribute) data element 361,
- B File (file) 355-unit attribute (Attribute) data element 362,
- C Application identifier (ApplicationIdentifier) element 363 in units of EFDT elements 354
- Each of these elements is a candidate.
- a data recording field (any) in which free data can be stored is set in addition to a recording area of prescribed attribute (Attribute) information. Tokens are recorded in the data recording fields (any) 371 and 372.
- token recording example for example, in the lowermost ROUTE metadata 162 and 163 shown in FIG. 15 (1) token setting example 1 described above with reference to FIG. This corresponds to an example of recording “-Class>”.
- file URL is recorded in the default content location (Content-Location) recording area in the file-related attribute (Attribute) 362.
- an example of an XML instance when a token is stored in an EFDT instance (EFDT-Instance) element is as follows, for example.
- EFDT-Instance EFDT-Instance
- SWClass "SW class character string"...> ... ⁇ / EFDT> ... ⁇ / SourceFlow> ... ⁇ / Transport Session> ... ⁇ / LSID>
- An example of an XML instance when the token is stored in the application identifier (ApplicationIdentifier) element 363 of the EFDT element 354 unit shown in FIG. 38 is as follows. ⁇ LSID> ... ⁇ TransportSession> ... ⁇ SourceFlow> ... ⁇ ApplicationIdentifier> SW class string ⁇ ApplicationIdentifier> ... ⁇ / SourceFlow> ... ⁇ / Transport Session> ... ⁇ / LSID>
- service worker (SW) search scope token ⁇ SW-Scope> When “service worker (SW) search scope token ⁇ SW-Scope>” is placed in the LSID / TransportSession / SourceFlow / ApplicationIdentifier element, the desired service worker (SW ) Indicates that related files are stored. On the other hand, when the “service worker (SW) class designation token ⁇ SW-Class>” is arranged, it indicates that all the files in this file transfer session are the desired service worker (SW) related files. .
- SW service worker
- the above-described embodiment is a model in which service workers (SW) are classified and the service workers (SW) themselves are prepared for each caching policy.
- the Hino model is effective when there are few policy types, but the service worker (SW) type (class) can be used to enable very fine-grained control according to the client environment. ) May be enormous.
- APIs for preparing the service worker (SW) as common as possible (several types) and acquiring the environment attribute of the receiving device (client) in the logic of the service worker (SW) It is also possible to realize caching optimization by applying.
- this is an implementation model that allows the user to select a caching policy while referring to status information of the application execution environment and statistical data of user viewing information by applying the API.
- the caching policy is selected while referring to the status information of the application execution environment and the statistical data of the viewing information of the user by applying the API, and the storage unit of the receiving device
- the (persistent cache) control processing sequence will be described. 40 to 41, the following components are shown from the left.
- A Broadcast server constituting transmission device
- b Data distribution server constituting transmission device
- c Middleware of reception device
- Proxy server of reception device e
- F Service worker (SW) executed on the browser executed by the output control unit of the receiving device
- G Application executed on browser executed by output control unit of receiving device
- the native application is an application executed by the receiving device 30, but is not an application under the control of the service worker (SW), but an application used for, for example, activation processing of a content (program) compatible application. .
- SW service worker
- an application used for, for example, activation processing of a content (program) compatible application for, for example, activation processing of a content (program) compatible application.
- Step S401 The process of step S401 is an activation process of an application corresponding to content (program) by a native application.
- the native application is an application used for activation processing of an application corresponding to content (program). For example, when the application corresponding to the content (program) is set to be activated based on trigger information embedded in the program, the activation process by the native application is unnecessary.
- Step S402 the activated application executes a service worker (SW) registration process.
- the service worker (SW) is stored in the storage unit (permanent cache) and can be used anytime.
- This service worker (SW) registration process is grasped from the service worker (SW) itself as detection of a registration (install) event, and the service worker (SW) is triggered by the detection of the registration (install) event, step S403. Start the cache control.
- Step S403 to S405 and Step S501 When the service worker (SW) detects a registration (install) event, in step S403, for example, the service worker (SW) starts control of the storage unit (persistent cache) according to the script description. Specifically, acquisition of a specific class of service workers (SW) or resources (applications and application-related data) to be managed by the specific class of service workers (SW) and cache expansion (storage) processing are started.
- SW specific class of service workers
- resources applications and application-related data
- step S501 file acquisition processing and cache expansion are executed according to the optimum file selection information obtained by applying the API.
- the optimum file selection information obtained by applying the API is information obtained based on, for example, application execution environment state information, user viewing information statistical data, and the like.
- step S404 a specific class of service workers (SW) or resources (applications and application-related data) to be managed by the specific class of service workers (SW) are transmitted in step S404, such as a broadcast server or a data distribution server. Continuously sent from.
- step S404 the processing for the segment file in each step of FIGS. 8 to 9 (A-1 to 2) in the resource transmission / reception processing described above with reference to FIGS. 8 to 9 is replaced with processing for the resource. Executed.
- step S405 the transmission data is expanded (stored) in the storage unit (permanent cache) via the proxy server management cache.
- Step S406 the application requests an application part, for example, a moving image file or a still image file necessary for execution of the application, application-related data such as a JavaScript (registered trademark) program, audio data, or the like to the service worker (SW).
- This request processing corresponds to detection of a fetch event in the service worker (SW).
- the service worker (SW) acquires the requested parts from the storage unit (permanent cache) and provides them to the application.
- a file acquisition process corresponding to the optimum file selection information obtained by applying the API is executed in step S501.
- the optimum file selection information obtained by applying the API is information obtained based on, for example, application execution environment state information, user viewing information statistical data, and the like.
- Steps S410 to S4111 The processing in steps S410 to S411 is processing when an activation event is detected by the service worker (SW).
- the activate event is detected, for example, when an input of a resource deletion request is executed by a user or when an application expires.
- the service worker (SW) detects an activate event, for example, control of the storage unit (persistent cache) according to the script description is started. Specifically, a specific class of service workers (SW) or resources (applications and application related data) to be managed by the specific class of service workers (SW) are deleted.
- file deletion according to the optimum file selection information obtained by applying the API is executed in step S502.
- the optimum file selection information obtained by applying the API is information obtained based on, for example, application execution environment state information, user viewing information statistical data, and the like.
- Steps S412 to S415 The processing in steps S412 to S415 is processing when a timer event is detected by the service worker (SW).
- the timer event is detected, for example, when the expiration date of the application has expired or when the update deadline has come.
- processing corresponding to the timer event there is, for example, deletion of cache resources or acquisition processing of update resources or additional resources.
- step S502 file deletion or acquisition processing and cache expansion according to optimum file selection information obtained by applying the API are executed in step S502.
- the optimum file selection information obtained by applying the API is information obtained based on, for example, application execution environment state information, user viewing information statistical data, and the like.
- Step S413 is a sequence of cache resource deletion processing according to the timer event.
- Steps S414 to S415 show a sequence of processing for acquiring update resources and additional resources according to timer events.
- step S414 the processing for the segment file in each step of FIGS. 8 to 9 (A-1 to 2) in the resource transmission / reception processing described above with reference to FIGS. 8 to 9 is replaced with processing for resources. Processing is executed.
- FIG. 42 shows a configuration example of the transmission device (server) 20 and the reception device (client) 30.
- the transmission device (server) 20 includes a data processing unit 751, a communication unit 752, and a storage unit 753.
- the receiving device (client) 30 includes a data processing unit 771, a communication unit 772, a storage unit 773, an input unit 774, and an output unit 775.
- the data processing unit includes a communication data processing unit 771a and a reproduction processing unit 771b.
- the data processing unit 751 of the transmission device (server) 20 executes various data processing for executing the data distribution service. For example, generation of configuration data of the data distribution service and transmission control are performed. Further, the data processing unit 751 performs processing for generating and transmitting an application provided to the receiving device (client) 30, a service worker (SW), various other data, and signaling data.
- SW service worker
- the communication unit 752 performs communication processing such as distribution of applications, service workers (SW), other various data, signaling data, etc. in addition to AV segments.
- the storage unit 753 stores AV segments, applications, service workers (SW) to be distributed, data used by applications, signaling data, and the like. Further, the storage unit 753 is used as a work area for data processing executed by the data processing unit 751 and is also used as a storage area for various parameters.
- the receiving device (client) 30 includes a data processing unit 771, a communication unit 772, a storage unit 773, an input unit 774, and an output unit 775.
- the communication unit 772 receives data distributed from the transmission device (server) 20, for example, AV segments, applications, service workers (SW), data used by applications, signaling data, and the like.
- the data processing unit 771 includes a communication data processing unit 771a and a reproduction processing unit 771b, and executes, for example, processing according to the above-described embodiment. Specifically, data processing using an application, an API, and a service worker (SW) is executed.
- SW service worker
- the storage unit 773 stores an AV segment, a service worker (SW), an application, data used by the application, signaling data, and the like. Further, the storage unit 773 is used as a work area for data processing executed by the data processing unit 771 and also used as a storage area for various parameters.
- SW service worker
- FIG. 43 shows a hardware configuration example of a communication device applicable as the transmission device 20 and the reception device 30.
- a CPU (Central Processing Unit) 801 functions as a data processing unit that executes various processes according to a program stored in a ROM (Read Only Memory) 802 or a storage unit 808. For example, processing according to the sequence described in the above-described embodiment is executed.
- a RAM (Random Access Memory) 803 stores programs executed by the CPU 801, data, and the like. These CPU 801, ROM 802, and RAM 803 are connected to each other by a bus 804.
- the CPU 801 is connected to an input / output interface 805 via a bus 804.
- the input / output interface 805 is connected to an input unit 806 including various switches, a keyboard, a mouse, and a microphone, and an output unit 807 including a display and a speaker. Yes.
- the CPU 801 executes various processes in response to a command input from the input unit 806 and outputs a processing result to the output unit 807, for example.
- the storage unit 808 connected to the input / output interface 805 includes, for example, a hard disk, and stores programs executed by the CPU 801 and various data.
- a communication unit 809 functions as a transmission / reception unit for data communication via a network such as the Internet or a local area network, and further functions as a transmission / reception unit for broadcast waves, and communicates with an external device.
- the drive 810 connected to the input / output interface 805 drives a removable medium 811 such as a semiconductor memory such as a magnetic disk, an optical disk, a magneto-optical disk, or a memory card, and executes data recording or reading.
- a removable medium 811 such as a semiconductor memory such as a magnetic disk, an optical disk, a magneto-optical disk, or a memory card, and executes data recording or reading.
- the encoding or decoding of data can be executed as a process of the CPU 801 as a data processing unit, but a configuration including a codec as dedicated hardware for executing the encoding process or the decoding process may be adopted.
- SW class-compatible service workers
- Access information of a specific class of service worker (SW) is acquired from signaling data which is metadata transmitted by the transmitting device, and a service worker (SW) is acquired using the acquired access information (1) to ( 4) The receiving device according to any one of the above.
- a token that is search auxiliary information for efficiently searching for access information of a specific class of service worker (SW) is recorded,
- the data processing unit The receiving device according to (5), wherein an access information search process using a token is executed.
- the token is The receiving device according to (6), which is a service worker (SW) search scope token capable of limiting a search range of access information of a specific class of service worker (SW).
- SW service worker
- the signaling data is (A) a service layer describing attribute information of a service or content intended for user presentation; (B) a file transfer session layer describing file transfer parameters; (C) FLUTE (ROUTE) parameter layer describing parameters corresponding to the FLUTE (ROUTE) protocol; It has the layers (a) to (c) above, The receiving device according to any one of (6) to (8), wherein a token is recorded in at least one of the layers (a) to (c).
- the application executed in the data processing unit of the receiving device executes a request for setting token information for detecting the token to middleware that executes processing of the received data.
- the receiving apparatus according to any one of (1) to (10), wherein the middleware performs token detection based on token information set in response to a token information setting request.
- a service worker which is a data management program executed in the data processing unit of the receiving device, requests to set the token information for detecting the token to middleware that executes processing of the received data Run
- the receiving apparatus according to any one of (1) to (11), wherein the middleware performs token detection based on token information set in response to a token information setting request.
- the token is It is information for improving the efficiency of the search process of access information corresponding to data to be managed by a specific service worker (SW),
- the data processing unit The receiving device according to (12), wherein a request for setting new token information is made to the middleware in response to the update of the service worker (SW).
- a data management program used in the receiving device which transmits a plurality of class-compatible service workers (SW) having different data management types.
- the transmission device includes: The transmitting apparatus according to (14), wherein the receiving apparatus transmits signaling data that is metadata in which a token that is search auxiliary information for efficiently searching for access information of a specific class of service worker (SW) is recorded.
- signaling data that is metadata in which a token that is search auxiliary information for efficiently searching for access information of a specific class of service worker (SW) is recorded.
- the token is Service worker (SW) search scope token that can limit the search range of access information of a specific class of service worker (SW), or
- the transmission apparatus according to (15) which is a service worker (SW) class designation token indicating that access information of a specific class of service worker (SW) is recorded.
- a data processing method executed in the receiving device is a data management program used in the receiving device, and selectively acquires service workers (SW) of a specific class from a plurality of class-compatible service workers (SW) having different data management types. Data processing method to use.
- a data processing method executed in the transmission device A data processing method for transmitting a plurality of class-compatible service workers (SW) having different data management types, which is a data management program used in a receiving apparatus.
- SW class-compatible service workers
- the series of processes described in the specification can be executed by hardware, software, or a combined configuration of both.
- the program recording the processing sequence is installed in a memory in a computer incorporated in dedicated hardware and executed, or the program is executed on a general-purpose computer capable of executing various processing. It can be installed and run.
- the program can be recorded in advance on a recording medium.
- the program can be received via a network such as a LAN (Local Area Network) or the Internet and installed on a recording medium such as a built-in hard disk.
- the various processes described in the specification are not only executed in time series according to the description, but may be executed in parallel or individually according to the processing capability of the apparatus that executes the processes or as necessary.
- the system is a logical set configuration of a plurality of devices, and the devices of each configuration are not limited to being in the same casing.
- an apparatus and a method that enable selection acquisition and use processing of a service worker (SW) that performs data management optimized for each receiving apparatus Is realized.
- SW service worker
- it is a data management program used in a receiving device, and a specific class SW is selectively acquired from a plurality of class-compatible service workers (SWs) having different data management types and can be used.
- SWs class-compatible service workers
- the receiving device acquires the access information of the specific class SW by using the signaling data in which the token for enabling efficient search of the access information of the specific class SW is recorded, and acquires the SW.
Landscapes
- Engineering & Computer Science (AREA)
- Signal Processing (AREA)
- General Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Databases & Information Systems (AREA)
- Multimedia (AREA)
- Library & Information Science (AREA)
- Data Mining & Analysis (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Information Transfer Between Computers (AREA)
- Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
- Small-Scale Networks (AREA)
Abstract
Description
なお、放送波およびネットワークを介したデータ配信を実現するための技術を開示した従来技術して。例えば特許文献1(特開2014-057227号公報)がある。
ATSC3.0では、ダウンロード型のアプリケーション配信管理用のパッケージング方式、ならびに、オフラインのアプリケーション登録・更新管理方式がまだ検討段階にある。
さらに、具体的には、受信装置(クライアント)の実行環境や記憶容量等の各種リソースの制約を考慮にいれて、受信装置側のユーザの嗜好情報や、記憶域容量他ランタイム環境制約、ローカルネットワーク負荷等のさまざまなクライアント環境属性を参照することにより、きめの細かなキャッシュ対象であるアプリケーション(パーツ)のキャッシュ制御を実現する受信装置、送信装置、およびデータ処理方法を提供することを目的とする。
受信装置において利用されるデータ管理プログラムであり、異なるデータ管理タイプを持つ複数のクラス対応のサービスワーカ(SW)から、特定クラスのサービスワーカー(SW)を選択取得して利用するデータ処理部を有する受信装置にある。
受信装置において利用されるデータ管理プログラムであり、異なるデータ管理タイプを持つ複数のクラス対応のサービスワーカ(SW)を送信する送信装置にある。
受信装置において実行するデータ処理方法であり、
前記受信装置のデータ処理部が、受信装置において利用されるデータ管理プログラムであり、異なるデータ管理タイプを持つ複数のクラス対応のサービスワーカ(SW)から、特定クラスのサービスワーカー(SW)を選択取得して利用するデータ処理方法にある。
送信装置において実行するデータ処理方法であり、
受信装置において利用されるデータ管理プログラムであり、異なるデータ管理タイプを持つ複数のクラス対応のサービスワーカ(SW)を送信するデータ処理方法にある。
具体的には、例えば、受信装置において利用されるデータ管理プログラムであり、異なるデータ管理タイプを持つ複数のクラス対応のサービスワーカ(SW)から、特定クラスのSWを選択取得して利用可能とした。例えば、受信装置におけるアプリケーション利用状況に応じて選択されるクラス対応のSWの利用を実現する。受信装置は、特定クラスのSWのアクセス情報を効率的に検索可能とするためのトークンを記録したシグナリングデータを利用して特定クラスのSWのアクセス情報を取得してSWを取得する。
本構成により、各々の受信装置に最適化したデータ管理を実行するサービスワーカー(SW)の選択取得および利用処理を可能とする装置、方法が実現される。
なお、本明細書に記載された効果はあくまで例示であって限定されるものではなく、また付加的な効果があってもよい。
1.通信システムの構成例について
2.データ通信プロトコルFLUTE、およびROUTEについて
3.送信装置と受信装置の実行する通信処理例について
4.サービスワーカー(SW)について
5.受信装置におけるアプリケーションの取得および実行例について
6.サービスワーカー(SW)のクラス分類と、クラス分類されたサービスワーカー(SW)の選択取得用情報の通知(シグナリング)処理につい
7.サービスワーカー(SW)の配信とキャッシュ制御処理について(ポーリング型の処理例)
7.1.放送ストリーム付随アプリケーションからのサービスワーカー(SW)の取得、登録処理について
7.2.サービスワーカー(SW)に対するクラス設定について
7.3.トークンを適用して特定クラスのサービスワーカー(SW)の取得処理を効率化した構成について
7.4.サービスワーカー(SW)の更新処理について
7.5.サービスワーカー(SW)による受信装置の記憶部(永続キャッシュ)の制御処理について
8.サービスワーカー(SW)の配信とキャッシュ制御処理について(プッシュ型の処理例)
8.1.放送ストリーム付随アプリケーションからのサービスワーカー(SW)の取得、登録処理について
8.2.トークンを適用して受信装置のデータ取得処理を効率化した構成について
8.3.サービスワーカー(SW)の更新処理について
8.4.サービスワーカー(SW)による受信装置の記憶部(永続キャッシュ)の制御処理について
9.トークンを記述するシグナリングデータ(メタデータ)の構成について
9.1.シグナリングデータ(メタデータ)を構成するOMA-ESGに対するトークン記録例について
9.2.シグナリングデータ(メタデータ)を構成するUSDに対するトークン記録例について
9.3.シグナリングデータ(メタデータ)を構成するFLUTE(ROUTE)パラメータレイヤに対するトークン記録例について
10.サービスワーカー(SW)の利用可能なAPIによるキャッシングの最適化処理例について
11.送信装置と受信装置の構成例について
12.本開示の構成のまとめ
まず、図1を参照して本開示の処理を実行する通信システムの一構成例について説明する。
図1に示すように、通信システム10は、画像データや音声データ等のコンテンツを送信する通信装置である送信装置20と、送信装置20の送信するコンテンツを受信する通信装置である受信装置30を有する。
一方、受信装置30は、一般ユーザのクライアント装置であり、具体的には、例えばテレビ31、PC32、携帯端末33等によって構成される。
MPEG-DASH規格には、以下の2つの規格が含まれる。
(a)動画や音声ファイルの管理情報であるメタデータを記述するためのマニフェスト・ファイル(MPD:Media Presentation Description)に関する規格、
(b)動画コンテンツ伝送用のファイル・フォーマット(セグメント・フォーマット)に関する規格、
送信装置20から、受信装置30に対するコンテンツ配信は、上記のMPEG-DASH規格に従って実行する。
MPEG-DASH規格に従ってデータ送信を実行する送信装置20は、図2に示すように、大きく分けて以下の複数種類のデータの送信を行う。
(a)シグナリングデータ50
(b)AVセグメント60
(c)その他のデータ(ESG,NRTコンテンツ等)70
受信装置30は、このシグナリングデータ50を、再生対象となる番組コンテンツを格納したAVセグメント60の受信に先行して受信することが必要となる。
このシグナリングデータ50は、例えばXML(Extensible Markup Language)形式のデータとして、スマホやテレビ等のユーザ端末である受信装置(クライアント)に送信される。
これは、受信装置(クライアント)が、いつでも、即座にシグナリングデータを取得することを可能とするためである。
クライアント(受信装置)は、随時、受信可能なシグナリングデータに基づいて、必要な番組コンテンツのアクセス用アドレスの取得や、コーデック設定処理など、番組コンテンツの受信および再生に必要な処理を遅滞なく実行することが可能となる。
ESGは、電子サービスガイド(Electronic Service Guide)であり、例えば番組表等の案内情報である。
NRTコンテンツはノンリアルタイム型のコンテンツである。
後述するアプリケーション等の制御プログラムとして利用されるサービスワーカー(Service Worker)も、NRTコンテンツに含まれる。
(a)シグナリングデータ50
(b)AVセグメント60
(c)その他のデータ(ESG,NRTコンテンツ等)70
これらのデータは、例えば、データ通信プロトコル:FLUTE(File Delivery over Uni-directional Transport)に従って送信される。
データ通信プロトコル:FLUTE(File Delivery over Uni-directional Transport)はマルチキャストにより伝送するコンテンツのセッション管理を行うプロトコルである。
例えば送信装置であるサーバ側で生成されるファイル(URLとバージョンで識別される)は、FLUTEプロトコルに従って、受信装置であるクライアントに送信される。
同じURLでバージョンが異なるものはファイルの中身が更新されているものとみなす。FLUTEプロトコルは一方向ファイル転送制御のみを行うもので、クライアントにおけるファイルの選択的なフィルタリング機能はないが、FLUTEで転送制御するファイルをそのファイルに紐づけられるメタデータを利用して、クライアント側で取捨選択することにより、選択的なフィルタリングを実現し、ユーザの嗜好を反映したローカルキャッシュを構成・更新管理することが可能となる。
なお、メタデータは、FLUTEプロトコルに拡張して組み込むこともできるし、別途ESG(Electronic Service Guide)等のプロトコルで記述することもできる。
次に、送信装置と受信装置の実行する通信処理例について説明する。
図3は、送信装置および受信装置のプロトコルスタックの例を示す図である。
図3に示す例は、以下の2つの通信データの処理を行なうための2つのプロトコルスタックを有する。
(a)ブロードキャスト(マルチキャストも含む)通信(例えば放送型データ配信)
(b)ユニキャスト(ブロードバンド)通信(例えばHTTP型のP2P通信)
図3の右側が、(b)ユニキャスト(ブロードバンド)通信(例えばHTTP型のP2P通信)に対応するプロトコルスタックである。
(1)ブロードキャスト物理レイヤ(Broadcast PHY)
(2)IPマルチキャストレイヤ(IP Multicast)
(3)UDPレイヤ
(4)ROUTE(=拡張型FLUTE)レイヤ
(5)ESG,NRTcontent,DASH(ISO BMFF)およびVideo/Audio/CC
(6)アプリケーションレイヤ(Applications(HTML5))
シグナリングレイヤは、先に図2を参照して説明したシグナリングデータ50の送受信に適用されるレイヤである。シグナリングデータには、番組表等の番組予定情報や、番組取得に必要となるアドレス情報(URL等)、さらにコンテンツの再生処理に必要な情報、例えばコーデック情報(符号化方式など)などからなる案内情報、制御情報などが含まれる。
なお、(1)ブロードキャスト物理レイヤ(Broadcast PHY)の上位レイヤとして将来の新たなプロトコルの利用許容レイヤ(Future Extensibility)が設定されている。
(2)IPマルチキャストレイヤ(IP Multicast)は、IPマルチキャストに従ったデータ送受信処理を実行するレイヤである。
(3)UDPレイヤは、UDPパケットの生成、解析処理レイヤである。
ROUTEは、FLUTEと同様、ALCと呼ばれるスケーラブルなファイルオブジェクトのマルチキャストプロトコルであり、具体的にはそのビルディングブロックであるLCTやFECコンポーネントの組み合わせにより構成される。
MBMSやeMBMSは、同報型配信サービスであり、特定のエリア内に位置する受信装置である複数のユーザ端末(UE)に対して共通のベアラで一斉に同一データ、例えば映画コンテンツなどを配信するサービスである。MBMSやeMBMSに従った同報配信により、配信サービス提供エリアに位置する多数のスマホやPC、あるいはテレビ等の受信装置に、同じコンテンツを同時に提供することができる。
(a)シグナリングデータ50
(b)AVセグメント60
(c)その他のデータ(ESG、NRTコンテンツ等)70
これらのデータの多くはROUTEプロトコル、またはFLUTEプロトコルに従って送信される。
前述したように、NRTコンテンツには、例えば、クライアントである受信装置のブラウザ上で実行される様々なアプリケーションファイル、動画、静止画等のデータファイル等が含まれる。さらに、後述するアプリケーション等の制御プログラムとして利用されるサービスワーカー(Service Worker(SW))も、NRTコンテンツに含まれる。
Video/Audio/CCは、DASH規格に従って配信されるビデオやオディオ等、再生対象となる実データである。
(1)ブロードバンド物理レイヤ(Broaband PHY)
(2)IPユニキャストレイヤ(IP Unicast)
(3)TCPレイヤ
(4)HTTPレイヤ
(5)ESG,Signaling,NRTcontent,DASH(ISO BMFF)およびVideo/Audio/CC
(6)アプリケーションレイヤ(Applications(HTML5))
(2)IPユニキャストレイヤ(IP Unicast)は、IPユニキャスト送受信処理を実行するレイヤである。
(3)HTTPレイヤは、HTTPパケットの生成、解析処理レイヤである。
この上位レイヤは、図3左側の(a)ブロードキャスト通信(例えば放送型データ配信)のスタック構成と同様である。
(a)ブロードキャスト通信(例えば放送型データ配信)
(b)ユニキャスト(ブロードバンド)通信(例えばHTTP型のP2P通信)
これら2つの通信プロトコルスタックの少なくともいずれかに従った処理を行なう。
次に、送信装置(サーバ)20が提供し、主に受信装置(クライアント)30において利用されるサービスワーカー(SW:Service Worker)について説明する。
サービスワーカー(SW)は、放送サーバ21や、データ配信サーバ22等の送信装置20から受信装置に提供される。
あるいは、放送番組を配信するサーバとは別のデータ提供サーバが、サービスワーカー(SW)、アプリケーション、およびアプリケーションの実行時に利用されるデータファイルを受信装置30に提供する構成としてもよい。
図4は、受信装置30が、放送サーバ21等の送信装置20から、ある番組コンテンツを受信し、受信装置30の表示部に表示している状態を示している。
以下では、これらのアプリケーションおよびデータファイルを「リソース」と呼ぶ。
放送サーバ21は、さらに、これらの「リソース」を管理するリソース管理プログラムとして、サービスワーカー(SW)を、やはりNRTコンテンツ(ノンリアルタイムコンテンツ)として受信装置30に提供する。
このような、アプリケーションを利用したデータ表示は、これまでのデータ配信構成では、アプリケーションの提供される番組の終了とともに実行できなくなってしまう。
なお、天気情報表示アプリケーションは、例えばブラウザ上で表示されるプログラムである。
なお、アプリケーション等のリソースを格納する記憶部(永続キャッシュ)は、受信装置30の電源がオフとなっても格納データが消去されない不揮発性メモリとすることが好ましい。
このように、サービスワーカー(SW)を利用することで、様々な番組対応アプリケーションを、番組の表示、非表示と無関係に利用することが可能となる。
サービスワーカー(SW)は、各番組対応の設定とすることもできるが、複数番組を含む特定のチャンネル対応のリソースに対して、共通に利用可能としたサービスワーカー(SW)を設定することもできる。
サービスワーカー(SW)と、サービスワーカー(SW)によって管理されるリソース(アプリケーションおよびアプリ関連データ)は、受信装置30の記憶部(永続キャッシュ)に格納される。
図6には、受信装置30が送信装置20からリソースとしてのWebページ(例えば図4、図5に示す天気情報表示ページ)を取得して受信装置30の記憶部(永続キャッシュ)に格納して利用するシーケンスの一例を示している。
なお、Webページは、所定のWebページ表示アプリケーションと、表示用データによって構成されるリソースを利用して表示される。
図6には、受信装置内出力制御部90の構成要素として表示処理部91、サービスワーカー(SW)92、キャッシュ(記憶部)93を示している。
これは、例えば放送サーバ等の送信するNRTコンテンツから取得される。
この取得処理後、表示処理部91によって、Webページ95が、受信装置30の表示部に表示される。この表示は、このWebページを提供している番組に併せて表示されている状態であり、先に図3を参照して説明した表示状態に相当する。
具体的には、ステップS104に示すようにリソースをキャッシュ93に渡し、記憶部(永続キャッシュ)に格納する処理を行なう。
サービスワーカー(SW)92は、この閲覧要求の入力をフェッチイベントとして検出し、フェッチイベント検出に応じて、ステップS106において、リソース(Webページ)を記憶部(永続キャッシュ)から取得する。
表示処理部91は、ステップS107において、Webページ96を表示する。
Webページ表示プログラムであるブラウザに一種のプロキシサーバが実装され、いつでも、必要なときにプロキシサーバをアクセスしてWebページを取得して表示可能としたイメージである。
例えば、リソースへのアクセスリクエスト(リソースへのフェッチリクエスト)に応じて、ブラウザ側の処理(ローカルキャッシュやネットワークからのリソースの取得)がはじまる前に、サービスワーカー(SW)の処理が開始され、永続キャッシュからのリソースの提供が行われる。
また、サービスワーカー(SW)は、JavaScirpt(登録商標)で提供されるため、さまざまな手続きを組み込むことが可能であり、永続キャッシュのリソースの一部の更新等キャッシュ制御についての柔軟な処理記述が可能となっている。
例えば、ヘッダに設定された使用期限等に基づいて、使用期限が来ると、受信装置30は、新しいバージョンのサービスワーカ(SW)の取得処理を実行して、キャッシュに格納された旧バージョンのSWを置き換える更新処理を行なう。
上述したように、受信装置30は、サービスワーカー(SW)を利用して、任意のタイミングで、例えば図4、図5を参照して説明したような天気情報表示アプリケーション等のアプリケーション、すなわちサービスワーカ(SW)の管理対象てあるアプリケーションを実行することが可能となる。
受信装置30側のユーザは、任意タイミングでアプリケーションを実行することで、天気情報表示ページや、様々なWebページをいつでも閲覧することが可能となる。
図7を参照して、受信装置30におけるアプリケーション実行構成について説明する。
図7に示すように、受信装置30はミドルウェア110、HTTPプロキシサーバ120、出力制御部130を有する。
ミドルウェア110は、通信部(PHY/MAC)111、シグナリングデータを取得するシグナリング取得部112、シグナリングデータを解析するシグナリング解析部113、シグナリングデータ、および、映像、音声等の番組コンテンツデータや、アプリケーション等のNRTコンテンツ等のデータファイルを取得するファイル取得部114を有する。
プロキシサーバ120は、出力制御部130からのデータ要求をアドレス解決部123に入力し、要求されたデータをキャッシュ部(プロキシキャッシュ)121,122、または外部から取得して提供する。
出力制御部130は、表示データ(HTML/JavaScript(登録商標)等)取得&解析部131、表示処理部(Renderer)132を有する。
なお、受信装置30にLAN等のネットワークを介して接続された外部装置150の出力制御部141においてアプリケーション、およびパーツ(HTMLページやJavaScript)を転送して、外部装置140においてアプリケーションを実行することも可能である。
例えば先に図4、図5を参照して説明したように、任意タイミングでアプリケーションを利用した様々なデータ出力を行うことができる。また、出力制御部130は、必要に応じて、サービスワーカー(SW)や、リソース(アプリケーション、およびアプリ関連データ)の更新処理や削除処理などを行う。
例えば、出力制御部130が、アプリケーションを構成するHTMLページもしくはJavaScript(登録商標)の取得を要求すると(HTTPリクエスト)、それを受けたプロキシサーバ120は、アドレス解決部(Broadcast/Broadband Address Resolver)123において放送受信スタックを介して取得するか、ネット経由で取得するかの判断を行う。
シグナリング解析部(Signaling Parser)113は、シグナリング取得部(Signaling Retriever)112に対して、ATSC3.0のシグナリングデータに含まれるメタデータであるUSBD(USD,SDP等)の取得要求を行う。
シグナリング解析部(Signaling Parser)113は、通信部(ATSCチューナー:ATSC3.0PHY/MAC)111を介して放送受信するシグナリングデータ格納LCTパケットによって転送されるシグナリングデータに含まれるメタデータを抽出する。
先に説明したように、サービスワーカー(SW)は、送信装置20から受信装置30に提供され、受信装置(クライアント)30において実行されるアプリケーションや、アプリケーションの実行時に利用されるデータファイル等の取得処理や、記憶部(キャッシュ)に対する格納処理、さらに更新処理、削除処理等を実行するプログラムである。
さらに、サービスワーカー(SW)を適用することで、サービスワーカー(SW)管理データとして設定された新規のあるいは更新されたアプリケーションや、動画、静止画等のデータファイルを、随時取得する処理が可能である。
すなわち、サービスワーカー(SW)は受信装置30において取得可能な様々なデータの取得制御も実現する。
例えば、受信装置におけるデータ処理状況に応じて特定クラスのサービスワーカー(SW)を選択取得して利用する。データ処理状況は、例えば、受信装置におけるアプリケーションまたはデータの利用状況である。
受信装置30は、同時に配信される複数のクラスのサービスワーカー(SW)の中から、受信装置30にとって最適なクラスのサービスワーカ(SW)を選択して取得する。
この処理のためには、例えば受信装置30のブラウザ上で稼働するクライアントアプリケーションが最適なサービスワーカー(SW)を選択して、登録できるようにすることが必要となる。
例えば、シグナリングデータの1つであるUSDを適用してSWのクラス(キャッシングポリシーを反映するクラス)を通知する。
キャッシュ対象のストリームの候補が複数ある場合(高画質、中画質、低画質版等)、高画質版ストリームのみをキャッシュするよう記述されたサービスワーカー(SW)を選択できるようにする。
キャッシュ対象のストリームが、当日の夕方までは、ネット経由の低品質版で配信され、夜まで待つとさらに高画質版が放送配信される場合に、放送配信高画質版をキャッシュするよう記述されたクラスのサービスワーカー(SW)を選択できるようにする。
このケースの場合、ネット経由の低品質版をキャッシュするよう記述されたクラスのサービスワーカー(SW)を選択できるようにする。
なお、クラス分類されたサービスワーカー(SW)を選択取得するためには、シグナリングデータが利用される。
例えば、USD等のシグナリングデータを用いて、サービスワーカー(SW)のクラスを受信装置30に通知し、受信装置30がシグナリングデータに基づいて、自装置に最適なサービスワーカー(SW)を選択取得することで、上記のように、受信装置30側の状況やユーザの嗜好に応じた最適なデータを受信装置30が取得(キャッシング)することが可能となる。
次に、サービスワーカー(SW)の配信とキャッシュ制御処理について説明する。
サービスワーカー(SW)、あるいはサービスワーカー(SW)の管理対象となるアプリケーションやアプリケーションに適用するデータからなるリソースは、例えば受信装置30に実装されたブラウザからの取得要求を契機としてポーリング型で取得処理を行なう構成と、ブラウザからの取得要求に関わらず取得してブラウザに提供するプッシュ型の2つの態様がある。
以下、これらの処理態様、すなわち、
(A)ポーリング型のデータ取得処理例
(B)プッシュ型のデータ取得処理例
上記(A),(B)の2つの処理態様について、順次、説明する。
まず、ポーリング型のデータ取得処理を行なう場合の処理例について説明する。
まず、サービスワーカー(SW)を、送信装置20から受信装置30に送信される放送ストリームに付随するアプリケーションを利用して取得し、登録する処理例について説明する。
例えば、特定の番組の放送ストリームには、アプリケーションを起動するためのURL通知するトリガー情報が含まれ、再生アプリケーションは、このトリガー情報に基づいてアプリケーションを取得するためのURLを取得することができる。
アプリケーションは、このアプリケーション自身を管理対象として設定したサービスワーカー(SW)[SW.js]の取得処理と登録処理を行う。SW.jsのjsはJavaScript(登録商標)を意味する。
図8~図10には、左から、以下の各構成要素を示している。
(a)送信装置20である放送サーバ
(b)送信装置20であるデータ配信サーバ
(c)受信装置30の構成要素であるミドルウェア
(d)受信装置30の構成要素であるプロキシサーバ
(e)受信装置30の構成要素である出力制御部
なお、図8~図10の処理シーケンスの開始前に、受信装置30の出力制御部では、ネイティブのストリーム再生アプリケーション、もしくは、ブラウザ上のストリーム再生アプリケーションが起動されているものとする。
まず、受信装置30の構成要素である出力制御部は、放送コンテンツストリームのDASHストリーミングの制御ファイルであるMPDに記述されたコンテンツ格納セグメントのアクセス情報であるセグメントURLを取得して、取得したセグメントURLを用いて放送コンテンツを格納したコンテンツセグメントファイルの取得要求を実行する。
MPEG-DASH規格に従ってデータ送信を実行する送信装置20は、先に図2を参照して説明したように、大きく分けて以下の複数種類のデータの送信を行う。
(a)シグナリングデータ50
(b)AVセグメント60
(c)その他のデータ(ESG,NRTコンテンツ等)70
シグナリングデータ50は、番組表等の番組予定情報や、番組取得に必要となるアドレス情報(URL等)、さらにコンテンツの再生処理に必要な情報、例えばコーデック情報(符号化方式など)などからなる案内情報、制御情報によって構成される。
その他のデータ70は、例えばESG(Electronic Service Guide)、NRTコンテンツ等が含まれる。
ESGは、電子サービスガイド(Electronic Service Guide)であり、例えば番組表等の案内情報である。
NRTコンテンツはノンリアルタイム型のコンテンツである。
NRTコンテンツには、例えば、クライアントである受信装置のブラウザ上で実行される様々なアプリケーションファイル、動画、静止画等のデータファイル等が含まれる。サービスワーカー(SW)も、NRTコンテンツに含まれる。
次に、受信装置30のプロキシサーバは、ステップS212において、セグメントURLで識別されるコンテンツセグメントファイルがプロキシサーバの管理するキャッシュに格納されていれば、キャッシュからコンテンツセグメントファイルを取得して取得したファイルをレスポンスとして出力制御部に返す。
一方、受信装置30のプロキシサーバは、ステップS213において、セグメントURLで識別されるコンテンツセグメントファイルがプロキシサーバの管理するキャッシュに格納されていないと判定した場合は、コンテンツセグメントファイルの取得要求をミドルウェアに出力する。
ステップS214の処理は、放送サーバ21によって継続的に実行される処理を示している。放送サーバ21は、番組コンテンツの配信に併せて、配信コンテンツに関する制御情報、管理情報等からなるシグナリングデータ(メタデータ等)を受信装置30に継続的に提供する。
ステップS215の処理は、ステップS213において、プロキシサーバからコンテンツセグメントファイルの要求が発生した場合に、ミドルウェアが実行する。
ミドルウェアは、放送サーバ21から受信するシグナリングデータ(メタデータ)に基づいて、プロキシサーバから取得要求のあったコンテンツセグメントファイルが放送によって受信可能か否かを判定し、判定情報をプロキシサーバに通知する。
プロキシサーバは、ミドルウェアからコンテンツセグメントファイルが放送によって受信可能であるとの通知を受けると、セグメントファイルのプロキシサーバ管理キュャッシュへの展開(格納)を待機する。
一方、ミドルウェアからコンテンツセグメントファイルが放送によって受信不可能であるとの通知を受けると、セグメントファイルのネット経由での取得要求をデータ配信サーバ22に対して実行する。
ステップS217~S218の処理は、プロキシサーバから取得要求のあったコンテンツセグメントファイルが放送によって受信可能である場合に実行される処理である。
この場合、放送サーバ21は、ステップS217において、コンテンツセグメントファイルを放送波によって送信する。
受信装置30のミドルウェアは、ステップS218において、放送サーバ21から送信されたセグメントファイルを受信して、プロキシサーバの管理キャッシュに展開(格納)する。
ステップS219の処理は、プロキシサーバから取得要求のあったコンテンツセグメントファイルが放送によって受信不可能である場合に実行される処理である。
この場合、データ配信サーバ22は、ステップS219において、受信装置30から要求されたコンテンツセグメントファイルを受信装置30に対して送信する。
受信装置30のプロキシサーバは、送信されたセグメントファイルを受信して、プロキシサーバの管理キャッシュに展開(格納)する。
放送サーバ21、またはデータ配信サーバ22から取得されプロキシサーバ管理キャッシュ内に格納されたコンテンツセグメントファイルは、ステップS220において、プロキシサーバから、出力制御部に提供される。
ステップS221において、受信装置30の出力制御部は、プロキシサーバから取得したコンテンツの再生を開始する。
さらに、コンテンツ再生時にコンテンツに含まれるトリガー情報を取得し、トリガー情報に記録されたコンテンツ対応のアプリケーションのアクセス情報であるアプリケーションURLをトリガー情報から取得して、取得したアプリケーションURLを適用したアプリケーション取得要求をプロキシサーバに対して実行する。
ステップS223の処理は、ステップS221において再生中のコンテンツ(例えば放送番組)に対して設定されたアプリケーションの取得と実行処理である。
ステップS223では、ステップS212~S219の処理(処理(A-1~2))と同様の処理を、アプリケーションファイルに対して実行する。
すなわち、ステップS212~S219の処理中に示す「セグメントファイル」を「アプリケーションファイル」に置き換えた処理を実行し、放送サーバ21、またはデータ配信サーバ22からアプリケーションファイルを取得してプロキシサーバの管理キャッシュに格納する。なお、すでにプロキシサーバの管理キャッシュに目的のアプリケーションファイルが展開(格納)されている場合は、新たな取得処理は不要である。
放送サーバ21、またはデータ配信サーバ22から取得されプロキシサーバ管理キャッシュ内に格納されたアプリケーションファイルは、ステップS224において、プロキシサーバから、出力制御部に提供される。
ステップS225において、受信装置30の出力制御部は、プロキシサーバから取得したアプリケーションを実行する。
例えば、番組コンテンツの表示に併せてWebページの表示処理等が実行される。なお、処理内容は、アプリケーションに応じて異なるものであり、必ずしもデータ表示が実行されるとは限らない。
ステップS226の処理は、ステップS225において実行中のアプリケーションの制御の下で実行される処理であり、サービスワーカー(SW)の取得と実行処理である。
ステップS226では、ステップS212~S219の処理(処理(A-1~2))と同様の処理を、サービスワーカー(SW)ファイルに対して実行する。
すなわち、ステップS212~S219の処理中に示す「セグメントファイル」を「サービスワーカーファイル」に置き換えた処理を実行し、放送サーバ21、またはデータ配信サーバ22からサービスワーカーファイルを取得してプロキシサーバの管理キャッシュに格納する。なお、すでにプロキシサーバの管理キャッシュに目的のサービスワーカーファイルが展開(格納)されている場合は、新たな取得処理は不要である。
放送サーバ21、またはデータ配信サーバ22から取得されプロキシサーバ管理キャッシュ内に格納されたサービスワーカーファイルは、ステップS227において、プロキシサーバから、出力制御部に提供される。
ステップS228において、受信装置30の出力制御部は、プロキシサーバから取得したサービスワーカーの登録処理を実行する。
具体的には、サービスワーカー(SW)を記憶部(永続キャッシュ)に格納する処理を実行する。
前述したようにサービスワーカー(SW)をクラス分類して、受信装置において所定クラスのサービスワーカー(SW)を選択取得して適用することにより、例えば、受信装置30側のユーザ嗜好に応じたアプリケーションやデータを取得し実行、再生することが可能となる。
具体的には、例えば、特定のアプリケーションの提供元のチャンネル提供者(放送局)のシグナリングデータのみから目的のファイルURLを探せるようにしておく等の処理である。
この処理には、後述する検索スコープトークンが利用される。
図11~図12には、左から、以下の各構成要素を示している。
(a)送信装置を構成する放送サーバ
(b)送信装置を構成するデータ配信サーバ
(c)受信装置のミドルウェア
(e)受信装置の出力制御部で実行されるアプリケーション
図11~図12のシーケンス図に示す各ステップの処理について、順次、説明する。
ステップS251の処理は、受信装置の出力制御部で実行されるアプリケーションによって実行される。
アプリケーションが、サービスワーカー(SW)クラスの設定要求をミドルウェアに対して実行する。
具体的には、例えば図7に示すミドルウェア110のシグナリング解析部113に対して、シグナリングデータに含まれるどのクラスのサービスワーカー(SW)アクセス情報検出すべきかを示すトークン情報を通知して、シグナリング解析部113に検出すべきクラスのサービスワーカー(SW)アクセス情報を判別可能な状態に設定する。
ステップS252~S253の処理は、受信装置の出力制御部で実行されるアプリケーションおよびサービスワーカーによって実行される。
ミドルウェアに対するサービスワーカー(SW)クラスの設定処理は、ステップS251で説明したように、アプリケーションの処理として実行してもよいが、サービスワーカー(SW)の処理として実行してもよい。
ステップS252~S253の処理は、ミドルウェアに対するサービスワーカー(SW)クラスの設定処理をサービスワーカー(SW)の処理として実行する場合に行われる。
登録処理によってサービスワーカー(SW)は、記憶部(永続キャッシュ)に格納され、いつでも利用可能な状態になる。
次に、登録されたサービスワーカー(SW)が、サービスワーカー(SW)クラスの設定要求をミドルウェアに対して実行する。
サービスワーカー(SW)クラスの設定は、ステップS251の処理と同様の処理である。すなわち、例えば図7に示すミドルウェア110のシグナリング解析部113に対して、シグナリングデータに含まれるどのクラスのサービスワーカー(SW)アクセス情報検出すべきかを示すトークン情報を通知して、シグナリング解析部113に検出すべきクラスのサービスワーカー(SW)アクセス情報を判別可能な状態に設定する。
ステップS254の処理は、放送サーバによって継続的に実行されているシグナリングデータの送信処理である。
このシグナリングデータには、例えば、様々なクラス対応のサービスワーカー(SW)を取得するためのアクセス情報が記録されている。
ステップS255の処理は、受信装置30のミドルウェアの処理である。すなわちデータ受信および受信データの解析等の処理を行なうミドルウェアの処理である。ミドルウェアは、アプリケーションまたはサービスワーカー(SW)から通知されたサービスワーカー(SW)クラスを設定し、設定したサービスワーカー(SW)クラスに基づいて、シグナリングデータから設定されたクラスのサービワーカー(SW)のアクセス情報検出を行う。
さらに、受信装置30のミドルウェアは、ステップS256において、シグナリングデータから取得したアクセス情報に基づいて、取得対象ファイルの配信スケジュール情報を取得し、これらを用いたサービスワーカー(SW)格納ファイル取得処理を開始する。
ステップS257の処理は、放送サーバによって継続的に実行されている各種ファイルの送信処理である。
送信ファイルには、アプリケーション、アプリケーション実行時に利用されるデータファイル等のアプリケーション関連データ、さらにサービスワーカー(SW)などが含まれる。
ステップS255の処理は、受信装置30のミドルウェアの処理である。ミドルウェアは、放送サーバの送信ファイルから、取得対象となるファイルを選択取得し、取得ファイルをプロキシサーバの管理キャッシュに展開(格納)する。
次に、受信装置における取得データの取得、選択処理を効率化した構成について説明する。
具体的には、トークンを適用して特定クラスのサービスワーカー(SW)の取得処理を効率化した構成について説明する。
受信装置30は、これらの膨大な数の送信ファイルから、自装置に最適なクラスのサービスワーカー(SW)を選択して取得する必要がある。
サービスワーカー(SW)は、例えばNRTコンテンツとして放送波を介して逐次、送信される。
さらに、サービスワーカー(SW)等のファイルを取得するために必要となるアクセス情報であるファイル対応のURLや各ファイルの送信タイミング情報等がシグナリングデータ(メタデータ)に記録されて受信装置30に提供される。
受信装置30は、シグナリングデータ(メタデータ)を解析して、取得すべきファイルのURLや送信タイミング等を知ることができる。
サービスAの記述を持つメタデータ、
サービスBの記述を持つメタデータ、
サービスCの記述を持つメタデータ、
このようにサービス単位(番組単位やチャンネル単位)のメタデータが記述されている。
さらに、各サービス単位のメタデータは、下位のメタデータとしてファイル転送セッション単位のメタデータを有する。
受信装置30は、このアクセス情報を利用して、先に図7参照して説明したシグナリング解析部113、アドレス解決部123の処理によって取得し、必要なファイルのURLにマッチするファイルアクセス情報を取得して、ファイルを取得することができる。
従って、シナリングデータに記録されたアクセス情報をすべて検索対象として調べる必要があり、検索時間に多大な時間を要することになる。
トークンやURLは、受信装置30の取得予定データに関するアクセス情報(メタデータ)を効率的に検索するための検索補助情報である。
例えば、特定のクラスのサービスワーカー(SW)や、特定のクラスのサービスワーカー(SW)の管理対象となるデータであるリソース(アプリケーションアプリ関連データ)に関するアクセス情報を効率的に検索するための検索補助情報である。
図14に示すように、
サービスAの記述を持つメタデータ、
サービスBの記述を持つメタデータ、
サービスCの記述を持つメタデータ、
このようにサービス単位(番組単位やチャンネル単位)のメタデータが記述されている。
さらに、各サービス単位のメタデータは、下位のメタデータとしてファイル転送セッション単位のメタデータを有する。
また、メタデータ151に含まれる下位のセッション単位のメタデータであるファイル転送セッション2の記述を持つメタデータ152と、ファイル転送セッション3の記述を持つメタデータ154には、トークン<SW-Class>とファイルURLの記述が含まれる。
また、メタデータ151に含まれる下位のセッション単位のメタデータであるファイル転送セッション1の記述を持つメタデータ153には、ファイルURLの記述が含まれる。
これら、<SW-Scope>、<SW-Class>やファイルURLが、受信装置において取得ファイルのアクセス情報を効率化するために適用されるトークンとして記述されるデータである。
「サービスワーカー(SW)検索スコープトークン」
である。
また、メタデータ152に記録されるトークン<SW-Class>は、特定のSWの管理、または更新対象となるファイル(キャッシュ対象ファイル)に関するURL情報がまとめて記録されていることを示すトークンであり、
「サービスワーカー(SW)クラス指定トークン」
である。
なお、これらのトークンは、いずれも特定のサービスワーカー(SW)対応のトークンとして設定されている。
受信装置30は、このトークンの記録されたメタデータを選択し、このメタデータ、およびこのメタデータの下位のメタデータを検索範囲として検索を行えば、受信装置の取得すべきクラスのサービスワーカー(SW)ファイルのアクセス情報を効率的に取得することができる。
すなわち、その他のメタデータを検索対象から除外することが可能となり、検索範囲を限定することで、検索効率を高めることが可能となる。
受信装置30は、このトークンの記録されたメタデータを選択し、このメタデータに記録されたアクセス情報のみを取得すれば、受信装置の取得すべきクラスのサービスワーカー(SW)ファイルのアクセス情報を効率的に取得することができる。
なお、図14に示すように、サービスワーカー(SW)検索スコープトークンを、シグナリングデータのサービス単位の記述パートに配置し、サービスワーカー(SW)クラス指定トークンを、シグナリングデータのファイル転送セッションの記述パートに配置する構成が検索効率を高めるトークン設定例の1つである。
この構成をとることにより、受信装置(クライアント)においてシグナリングデータを受信した場合のアクセス情報取得をより効率的に行うことが可能となる。
図15(1)に示すシグナリングデータ(メタデータ)は、最上位が番組やチャンネル単位で設定されるサービス単位のメタデータ(Service)である。
このサービス単位メタデータの下位にコンテンツ単位のメタデータ(Content)が設定される。
サービス単位のメタデータ(Service)、または、コンテンツ単位のメタデータ(Content)の下位には、配信スケジュールやアクセス情報を記述したメタデータ(Schedule&Access)が設定される。
なお、USDは、例えば配信メソッドに関する情報を格納し、例えば以下のシグナリングデータを含む。
SDP(セッションディスクリプション)
FDD(ファイルデリバリディスクリプション)
RFD(リペアフローディスクリプション)
SD(スケジュールディスクリプション)
さらに、USDは、コンテンツ(AVセグメント)に対応する様々な案内情報、制御情報を格納したマニフェスト・ファイルを持つシグナリングデータとして、
MPD(メディアプレゼンテーションディスクリプション)
を含む。
サービスメタデータ161に、「サービスワーカー(SW)検索スコープトークン<SW-Scope>」を記録している。
受信装置30は、このトークンに従って取得予定クラスのサービスワーカー(SW)ファイルのURLやアクセス情報の検索範囲を限定することができる。すなわち、図の点線枠で示す検索範囲を設定して取得予定ファイルのURLやアクセス情報の検索を行うことができる。
受信装置30は、このトークンに従って、このメタデータ162,163に特定クラスのサービスワーカー(SW)や、管理リソースファイルのURLやアクセス情報が記録されていることを知ることができる。
コンテンツメタデータ164に、「サービスワーカー(SW)検索スコープトークン<SW-Scope>」を記録している。
受信装置30は、このトークンに従って検索範囲を限定することができる。すなわち、図の点線枠で示す検索範囲を設定して取得予定ファイルのURLやアクセス情報の検索を行うことができる。
受信装置30は、このトークンに従って、このメタデータ165に特定クラスのサービスワーカー(SW)や、管理リソースを構成するグループの取得予定ファイルのURLやアクセス情報が記録されていることを知ることができる。
スケジュール&アクセスメタデータ166に、「サービスワーカー(SW)検索スコープトークン<SW-Scope>」を記録している。
受信装置30は、このトークンに従って取得予定クラスのサービスワーカー(SW)ファイルのURLやアクセス情報の検索範囲を限定することができる。すなわち、図の点線枠で示す検索範囲を設定して検索を行うことができる。
受信装置30は、このトークンに従って、このメタデータ167に特定クラスのサービスワーカー(SW)や管理リソースを構成するグループの取得予定ファイルのURLやアクセス情報が記録されていることを知ることができる。
USDメタデータの下位に設定されたスケジュールディスクリプションメタデータ168に、「サービスワーカー(SW)検索スコープトークン<SW-Scope>」を記録している。
受信装置30は、このトークンに従って検索範囲を限定することができる。すなわち、図の点線枠で示す検索範囲を設定して取得予定ファイルのURLやアクセス情報の検索を行うことができる。
受信装置30は、このトークンに従って、このメタデータ169に特定のサービスワーカー(SW)や、管理リソースを構成するグループの取得予定ファイルのURLやアクセス情報が記録されていることを知ることができる。
受信装置30は、例えば、放送データを受信するミドルウェアに、上述した検索範囲の限定や、検索対象ファイルのグループ特定等のフィルタリング処理に適用するトークンを検出するためのトークン検出用のトークン情報を通知(セット)し、セットされたトークン情報に従って、送信装置20から送信されるシグナリングデータを解析してトークンを検出し、検出したトークンを利用した効率的な検索処理を行ない、記憶部(永続キャッシュ)に格納するファイルの取得に必要なURL情報やアクセス情報、配信スケジュール情報等を取得する。なお、シグナリングデータにはファイルURLに併せて、各ファイルの配信スケジュール情報も記録されている。
なお、トークン情報のセット態様としては、以下の設定態様がある。
(1)サービスワーカー(SW)クラス指定トークン(SW-Class)
(2)サービスワーカー(SW)検索スコープトークン(SW-Scope)+)サービスワーカー(SW)クラス指定トークン(SW-Class)
また、特定クラスのサービスワーカー(SW)の管理データであるリソースの選択取得も併せて行う場合は、これらリソースのファイルURLをトークンに併せてパラメータ指定してもよい。
次に、受信装置30に格納されたサービスワーカー(SW)の更新処理について説明する。
受信装置30によって取得されたサービスワーカー(SW)は受信装置の記憶部(永続キャッシュ)に、サービスワーカー(SW)の管理対象となるリソース(アプリケーション、およびアプリ関連データ)とともに格納され、いつでも利用可能な設定となる。
例えば、この取得処理の際に(放送経由の場合もネット経由の場合も)、サービスワーカー(SW)の提供処理に際して送信装置20から受信装置30に対する通信データである「HTTPレスポンスヘッダ:Cache-control」にサービスワーカー(SW)自身の有効期限を指定することができる。
もしくは、ブラウザの設定した一定期限(例えば1日に一回等)がすぎると自動的にサービスワーカー(SW)についてローカルプロキシサーバに対する取得リクエストを行い、中身が更新されていれば再登録する処理がなされる。
図18~図19には、左から、以下の各構成要素を示している。
(a)送信装置を構成する放送サーバ
(b)送信装置を構成するデータ配信サーバ
(c)受信装置のミドルウェア
(d)受信装置の出力制御部で実行されるブラウザ
さらに、
(e)受信装置の出力制御部で実行されるブラウザ上で実行されるサービスワーカー(SW)
これらの各構成要素を示している。
図18~図19のシーケンス図に示す各ステップの処理について、順次、説明する。
ステップS271の処理は、放送サーバによって継続的に実行されているシグナリングデータの送信処理である。
このシグナリングデータには、例えば、先に図14~図17を参照して説明したトークンが設定されている。
ステップS272の処理は、受信装置30のミドルウェアの処理である。すなわちデータ受信および受信データの解析等の処理を行なうミドルウェアの処理である。ミドルウェアは、アプリケーションまたはサービスワーカー(SW)から通知されたトークン情報を設定し、設定したトークン情報に基づいて、シグナリングデータからのトークン(もしくはファイルURL)検出を実行する。
ステップS273の処理は、放送サーバによって継続的に実行されている各種ファイルの送信処理である。
送信ファイルには、アプリケーション、アプリケーション実行時に利用されるデータファイル等のアプリケーション関連データ、さらにサービスワーカー(SW)などが含まれる。
ステップS274の処理は、受信装置30のミドルウェアの処理である。ミドルウェアは、放送サーバの送信ファイルから、取得対象となるファイルを選択取得し、取得ファイルをプロキシサーバの管理キャッシュに展開(格納)する。
このキャッシュデータには、アプリケーション、アプリケーション実行時に利用されるデータファイル等のアプリケーション関連データ、さらにサービスワーカー(SW)などが含まれる。
サービスワーカー(SW)には、受信装置30が保持しているサービスワーカー(SW)の更新バージョンも含まれる。
ステップS275は、受信装置の出力制御部で実行されるブラウザの処理である。
ブラウザは、受信装置30の記憶部(永続キャッシュ)に格納された複数のサービスワーカー(SW)各々について、有効期限を確認し、有効期限になると自動的にローカルプロキシサーバに対する取得リクエストを行う。
もしくは、ブラウザの設定した一定期限(例えば1日に一回等)がすぎると自動的にサービスワーカー(SW)についてローカルプロキシサーバに対する取得リクエストを行う。
ステップS276の処理は、受信装置30のミドルウェアの処理である。ミドルウェアは、プロキシサーバの管理キャッシュに、ブラウザから取得要求のあった更新されたサービスワーカー(SW)の検索を行い、検出された場合、更新されたサービスワーカー(SW)をブラウザに出力する。
ステップS277は、受信装置の出力制御部で実行されるブラウザの処理である。
ブラウザは、プロキシサーバから受領した更新後のサービスワーカー(SW)を登録する。すなわち、記憶部(永続キャッシュ)に格納する。
ステップS278は、受信装置の出力制御部で実行されるサービスワーカー(SW)の処理である。ここでは、新たに登録された更新後のサービスワーカー(SW)の処理を示している。
更新後のサービスワーカー(SW)は、必要に応じて、トークン情報の設定要求をミドルウェアに対して実行する。
トークン情報の設定は、前述した図11のステップS251の処理と同様の処理である。すなわち、例えば図7に示すミドルウェア110のシグナリング解析部113に対して、シグナリングデータに含まれるどのクラスのサービスワーカー(SW)アクセス情報検出すべきかを示すトークン情報を通知して、シグナリング解析部113に検出すべきクラスのサービスワーカー(SW)のアクセス情報を判別可能な状態に設定する。
ステップS279の処理は、受信装置30のミドルウェアの処理である。すなわちデータ受信および受信データの解析等の処理を行なうミドルウェアの処理である。ミドルウェアは、更新後のサービスワーカー(SW)から通知されたトークン情報を設定し、設定したトークン情報に基づいて、シグナリングデータからのトークン(もしくはファイルURL)検出を実行する。
次に、受信装置30に格納されたサービスワーカー(SW)による受信装置の記憶部(永続キャッシュ)の制御処理について説明する。
サービスワーカー(SW)によるリソース格納のトリガーとなるイベントを受け取るタイミングは、サービスワーカー(SW)の登録処理、または再登録(更新)処理時である。これらの時点でサービスワーカー(SW)は、登録(install)イベントを受領する。
その他、アプリケーションがHTMLページやJavaScript(登録商標)を要求する時点(フェッチ(fetch)イベントを受領)、あるいは、サービスワーカー(SW)自身が生成したタイマーにより再起動される時点等に上記のリソース格納処理のトリガーとなるイベントを受領する。
図20~図21には、左から、以下の各構成要素を示している。
(a)送信装置を構成する放送サーバ
(b)送信装置を構成するデータ配信サーバ
(c)受信装置のミドルウェア
(d)受信装置のプロキシサーバ
(e)受信装置の出力制御部で実行されるブラウザの管理下の記憶部(永続キャッシュ)
(f)受信装置の出力制御部の実行するブラウザ上で実行されるサービスワーカー(SW)
(g)受信装置の出力制御部の実行するブラウザ上で実行されるアプリケーション
(h)受信装置の出力制御部で実行されるネィティブアプリケーション
これらの各構成要素を示している。
図20~図21のシーケンス図に示す各ステップの処理について、順次、説明する。
ステップS301の処理は、ネィティブアプリケーションによるコンテンツ(番組)対応のアプリケーションの起動処理である。
上述したように、ネィティブアプリケーションは、コンテンツ(番組)対応のアプリケーションの起動処理等に用いられるアプリケーションである。
コンテンツ(番組)対応のアプリケーションが、例えば、番組中に埋め込まれたトリガー情報に基づいて起動する設定の場合は、このネィティブアプリケーションによる起動処理は不要である。
ステップS302において、起動されたアプリケーションが、サービスワーカー(SW)の登録処理を実行する。
登録処理によってサービスワーカー(SW)は、記憶部(永続キャッシュ)に格納され、いつでも利用可能な状態になる。
このサービスワーカー(SW)登録処理は、サービスワーカー(SW)自身からは、登録(install)イベントの検出として把握され、サービスワーカー(SW)は、この登録(install)イベント検出を契機として、ステップS303のキャッシュ制御を開始する。
サービスワーカー(SW)は、登録(install)イベントを検出すると、ステップS303において、例えばスクリプト記述に従った記憶部(永続キャッシュ)の制御を開始する。
具体的には、特定クラスのサービスワーカー(SW)、または特定クラスのサービスワーカー(SW)の管理対象となるリソース(アプリケーションや、アプリ関連データ)の取得、キャッシュ展開(格納)処理を開始する。
ステップS304では、先に図8~図9を参照して説明したリソース送受信処理における図8~9(A-1~2)の各ステップのセグメントファイルに対する処理を、リソースに対する処理に置き換えた処理が実行される。
ステップS306において、アプリケーションがアプリケーションパーツ、例えばアプリケーションの実行に必要となる動画ファイルや静止画ファイル、あるいはJavaScript(登録商標)プログラム、音声データ等のアプリ関連データをサービスワーカー(SW)に要求する。
この要求処理は、サービスワーカー(SW)におけるフェッチ(fetch)イベント検出に相当する。
ステップS307~S309において、サービスワーカー(SW)は、要求されたパーツを記憶部(永続キャッシュ)から取得して、アプリケーションに提供する。
ステップS310~S311の処理は、サービスワーカー(SW)によるアクティベート(activate)イベント検出時の処理である。
アクティベート(activate)イベントは、例えば、ユーザによるリソースの削除要求の入力が実行された場合、あるいはアプリケーションの有効期限が切れた場合などに検出される。
サービスワーカー(SW)が、アクティベート(activate)イベントを検出すると、例えばスクリプト記述に従った記憶部(永続キャッシュ)の制御を開始する。
具体的には、特定クラスのサービスワーカー(SW)、または特定クラスのサービスワーカー(SW)の管理対象となるリソース(アプリケーションや、アプリ関連データ)の削除処理等を行なう。
ステップS312~S315の処理は、サービスワーカー(SW)によるタイマーイベント検出時の処理である。
タイマーイベントは、例えば、アプリケーションの有効期限が切れた場合、更新期限がきた場合などに検出される。
タイマーイベントに応じた処理としては、例えばキャッシュリソースの削除、あるいは更新リソースや追加リソースの取得処理などがある。
ステップS314~S315は、タイマーイベントに応じた更新リソースや追加リソースの取得処理のシーケンスを示している。
なお、ステップS314では、先に図8~図9を参照して説明したリソース送受信処理における図8~9(A-1~2)の各ステップのセグメントファイルに対する処理を、リソースに対する処理に置き換えた処理が実行される。
前述したように、サービスワーカー(SW)、あるいはサービスワーカー(SW)の管理対象となるアプリケーションやアプリケーションに適用するデータからなるリソースは、例えば受信装置30に実装されたブラウザからの取得要求を契機としてポーリング型で取得処理を行なう構成と、ブラウザからの取得要求に関わらず取得してブラウザに提供するプッシュ型の2つの態様がある。
以下、ブラウザからの取得要求に関わらず、サービスワーカ(SW)やその管理リソース(アプリケーション、およびアプリ関連データ)を取得してブラウザに提供するプッシュ型の処理例について説明する。
プッシュ型処理においても、放送サーバ21から提供されるコンテンツ(番組)対応のアプリケーションを利用したサービスワーカー(SW)の取得、登録シーケンスは、先に図8~図10を参照して説明したポーリング型の処理例と同様の処理となる。
先に図11~図12を参照して説明したポーリングン型のトークン利用処理では、コンテンツ付随アプリケーション、もしくはサービスワーカー(SW)が、取得すべきリソースやサービスワーカー(SW)を含むファイルをミドルウェアにおいてフィルタリング取得するためのトークン情報(もしくはファイルURL)をセットする処理を実行するものとして説明した。
しかし、トークン情報の設定要求をしたアプリケーションやサービスワーカー(SW)は、プロキシサーバのキャッシュに、トークンに従って選択されたファイルが展開(格納)されたかどうかを受動的に検知することができない。
この処理は、キャッシュ有効期限/タイマー/ポーリング周期等が長いと、プロキシサーバのキャッシュで更新が行われたら即座にブラウザ側に引き込むというような、設定された時間間隔の粒度に依存しないような引き込みタイミング制御ができないという問題がある。
また、タイミング精度を上げるために時間間隔を短くすると、問い合わせ要求が頻繁になり、無駄な負荷を上げることとなる。
このプッシュ型のトークン適用データ選択取得処理シーケンスについて、図22~図23のシーケンス図を参照して説明する。
(a)送信装置を構成する放送サーバ
(b)送信装置を構成するデータ配信サーバ
(c)受信装置のミドルウェア
(d)受信装置の出力制御部で実行されるサービスワーカー
(e)受信装置の出力制御部で実行されるアプリケーション
図22~図23のシーケンス図に示す各ステップの処理について、順次、説明する。
ステップS321の処理は、受信装置の出力制御部で実行されるアプリケーションによって実行される。
アプリケーションが、トークン情報の設定要求をミドルウェアに対して実行する。
具体的には、例えば図7に示すミドルウェア110のシグナリング解析部113に対して、シグナリングデータに含まれるどのクラスのサービスワーカー(SW)アクセス情報検出すべきかを示すトークン情報を通知して、シグナリング解析部113に検出すべきクラスのサービスワーカー(SW)のアクセス情報を判別可能な状態に設定する。
具体的には、例えば、サービスワーカー(SW)識別子等をトークン情報として通知し、設定する。
これは、送信装置(放送サーバ、データ配信サーバ)から受信装置に送信されたデータ(アプリケーション、アブリケーション関連データ、サービスワーカ(SW)等)が、ミドルウェアのプロキシサーバ管理キャッシュに展開(格納)された場合に、アプリケーションに通知する処理の実行を各装置または構成部が承諾して実行することを確認する処理である。
ステップS322~S323の処理は、受信装置の出力制御部で実行されるアプリケーションおよびサービスワーカーによって実行される。
ミドルウェアに対するトークン情報の設定処理は、ステップS321で説明したように、アプリケーションの処理として実行してもよいが、サービスワーカー(SW)の処理として実行してもよい。
ステップS322~S323の処理は、ミドルウェアに対するトークン情報の設定処理をサービスワーカー(SW)の処理として実行する場合に行われる。
登録処理によってサービスワーカー(SW)は、記憶部(永続キャッシュ)に格納され、いつでも利用可能な状態になる。
次に、登録されたサービスワーカー(SW)が、トークン情報の設定要求をミドルウェアに対して実行する。
トークン情報の設定は、ステップS321の処理と同様の処理である。すなわち、例えば図7に示すミドルウェア110のシグナリング解析部113に対して、シグナリングデータに含まれるどのクラスのサービスワーカー(SW)アクセス情報検出すべきかを示すトークン情報を通知して、シグナリング解析部113に検出すべきクラスのサービスワーカー(SW)のアクセス情報を判別可能な状態に設定する。
これは、送信装置(放送サーバ、データ配信サーバ)から受信装置に送信されたデータ(アプリケーション、アブリケーション関連データ、サービスワーカ(SW)等)が、ミドルウェアのプロキシサーバ管理キャッシュに展開(格納)された場合に、アプリケーションに通知する処理の実行を各装置または構成部が承諾して実行することを確認する処理である。
ステップS324の処理は、放送サーバによって継続的に実行されているシグナリングデータの送信処理である。
このシグナリングデータには、例えば、先に図14~図17を参照して説明したトークンが設定されている。
ステップS325の処理は、受信装置30のミドルウェアの処理である。すなわちデータ受信および受信データの解析等の処理を行なうミドルウェアの処理である。ミドルウェアは、アプリケーションまたはサービスワーカー(SW)から通知されたトークン情報を設定し、設定したトークン情報に基づいて、シグナリングデータからのトークン(もしくはファイルURL)検出を実行する。
さらに、受信装置30のミドルウェアは、トークン(もしくはファイルURL)に基づいて、取得対象ファイルを決定し、選択ファイルの配信スケジュール情報に従って、ファイル取得処理を開始する。
ステップS326の処理は、放送サーバによって継続的に実行されている各種ファイルの送信処理である。
送信ファイルには、アプリケーション、アプリケーション実行時に利用されるデータファイル等のアプリケーション関連データ、さらにサービスワーカー(SW)などが含まれる。
ステップS327の処理は、受信装置30のミドルウェアの処理である。ミドルウェアは、放送サーバの送信ファイルから、取得対象となるファイルを選択取得し、取得ファイルをプロキシサーバの管理キャッシュに展開(格納)する。
これは、送信装置(放送サーバ、データ配信サーバ)から受信装置に送信されたデータ(アプリケーション、アブリケーション関連データ、サービスワーカ(SW)等)が、ミドルウェアのプロキシサーバ管理キャッシュに展開(格納)されたことを、アプリケーション、またはサービスワーカー(SW)に通知する処理である。
なお、図には、ステップS328a~dの4本のイベント通知ラインを示しているが、ステップS328a,bについては、データ送信を実行したいずれかの装置がイベント通知を実行すればよい。
また、ステップS328c,dのミドルウェアからの通知処理は、トークン情報設定要求の発行元、すなわちアプリケーションまたはサービスワーカー(SW)のいずれかのみに対して実行すればよい。
次に、プッシュ型の処理を実行する場合のサービスワーカー(SW)の更新処理について説明する。
前述したように、サービスワーカー(SW)には、利用期限を定めることができ、受信装置30は、必要に応じて、受信装置の保持する利用期限の来たサービスワーカー(SW)を新たなサービスワーカー(SW)に置き換えるサービスワーカー(SW)更新処理を行なうことができる。
プッシュ型処理では、ミドルウェアの管理キャッシュに対して更新サービスワーカー(SW)の展開(格納)が実行された場合に、キャッシュ展開をブラウザ側に通知させるプッシュAPI等を利用したプッシュ型イベント通知機構を利用した処理を行なう。
図24には、左から、以下の各構成要素を示している。
(a)送信装置を構成する放送サーバ
(b)送信装置を構成するデータ配信サーバ
(c)受信装置のミドルウェア
(d)受信装置の出力制御部で実行されるブラウザ
さらに、
(e)受信装置の出力制御部で実行されるブラウザ上で実行されるサービスワーカー(SW)
これらの各構成要素を示している。
図24のシーケンス図に示す各ステップの処理について、順次、説明する。
すなわち、アプリケーション、ミドルウェア間、およびミドルウェアと送信装置(放送サーバ、データ配信サーバ)間において、例えば図22に示すステップS321a,bに示すイベント登録、承諾処理が実行されている。
これは、送信装置(放送サーバ、データ配信サーバ)から受信装置に送信されたデータ(アプリケーション、アブリケーション関連データ、サービスワーカ(SW)等)が、ミドルウェアのプロキシサーバ管理キャッシュに展開(格納)された場合に、アプリケーションに通知する処理の実行を各装置または構成部が承諾して実行することを確認する処理である。
図24のシーケンス図に示す各ステップの処理について、順次、説明する。
ステップS351a~dは、送信装置(放送サーバ、データ配信サーバ)から受信装置に送信されたデータ(本例では、更新サービスワーカー(SW))が、ミドルウェアのプロキシサーバ管理キャッシュに展開(格納)されたことを、アプリケーション、またはサービスワーカー(SW)に通知する処理である。
なお、図には、ステップS351a~dの4本のイベント通知ラインを示しているが、ステップS351a,bについては、データ送信を実行したいずれかの装置がイベント通知を実行すればよい。
また、ステップS351c,dのミドルウェアからの通知処理は、アプリケーションまたはサービスワーカー(SW)のいずれかのみに対して実行すればよい。
ステップS352は、受信装置の出力制御部で実行されるブラウザの処理である。
ブラウザは、イベント通知に基づいて、更新サービスワーカー(SW)のローカルプロキシサーバに対する取得リクエストを行う。
ステップS353の処理は、受信装置30のミドルウェアの処理である。ミドルウェアは、プロキシサーバの管理キャッシュに、ブラウザから取得要求のあった更新されたサービスワーカー(SW)の検索を行い、検出された場合、更新されたサービスワーカー(SW)をブラウザに出力する。
ステップS354は、受信装置の出力制御部で実行されるブラウザの処理である。
ブラウザは、プロキシサーバから受領した更新後のサービスワーカー(SW)を登録する。すなわち、記憶部(永続キャッシュ)に格納する。
ステップS355は、受信装置の出力制御部で実行されるサービスワーカー(SW)の処理である。ここでは、新たに登録された更新後のサービスワーカー(SW)の処理を示している。
更新後のサービスワーカー(SW)は、必要に応じて、トークン情報の設定要求をミドルウェアに対して実行する。
トークン情報の設定は、前述した図11のステップS251の処理と同様の処理である。すなわち、例えば図7に示すミドルウェア110のシグナリング解析部113に対して、シグナリングデータに含まれるどのクラスのサービスワーカー(SW)アクセス情報検出すべきかを示すトークン情報を通知して、シグナリング解析部113に検出すべきクラスのサービスワーカー(SW)のアクセス情報を判別可能な状態に設定する。
ステップS356の処理は、受信装置30のミドルウェアの処理である。すなわちデータ受信および受信データの解析等の処理を行なうミドルウェアの処理である。ミドルウェアは、更新後のサービスワーカー(SW)から通知されたトークン情報を設定し、設定したトークン情報に基づいて、シグナリングデータからのトークン(もしくはファイルURL)検出を実行する。
プッシュ型処理においても、受信装置30に格納されたサービスワーカー(SW)による受信装置の記憶部(永続キャッシュ)の制御処理シーケンスは、先に図20~図21を参照して説明したポーリング型の処理例と同様の処理となる。
先に、図14~図17を参照して説明したように、例えば放送サーバ21等の送信装置20から送信されるシグナリングデータ(メタデータ)には、受信装置30における取得データの選択を効率化するためのトークン(もしくはURL)が記述されている。
図25は、例えば放送サーバ21等の送信装置20から送信されるシグナリングデータ(メタデータ)の構成例を示す図である。
(1)サービスレイヤ(OMA-ESG)
(2)ファイル転送セッションレイヤ(3GPP-MBMS-USD)
(3)FLUTE(ROUTE)パラメータレイヤ(FLUTE(ROUTE))
(2)ファイル転送セッションレイヤは、ファイルの転送パラメータ等を記述するレイヤである。
(3)FLUTE(ROUTE)パラメータレイヤは、FLUTE(ROUTE)プロトコル対応のパラメータを記述するレイヤである。
(a)サービス・フラグメント(Service Fragment)
(b)コンテンツ・フラグメント(Content Fragment)
(c)インタラクティビティデータ・フラグメント(InteractivityData Fragment)
(d)スケジュール・フラグメント(Schedule Fragment)
(e)アクセス・フラグメント(Access Fragment)
なお、OMA-ESGには、この他にも複数の属性情報(要素)記録領域(フラグメント)が設定されるが、上記の(a)~(e)の属性情報(要素)記録領域(フラグメント)を前述したトークンの記録領域として設定した例について、後段で説明する。
例えば(a)サービス・フラグメントから、(d)スケジュール・フラグメントに延びる矢印は、(a)サービス・フラグメントに記録された個々のサービス(例えばチャンネルや番組)対応の配信スケジュール情報が(d)スケジュール・フラグメントに記録されていることを示す。
(f)スケジュール・フラグメント(Schedule Fragment)
(g)フィルタディスクリプション・フラグメント(FilterDescription Fragment)
先に図25を参照して説明したように、
シグナリングデータ(メタデータ)は、図25に示すように、以下の3つのレイヤを持つ。
(1)サービスレイヤ(OMA-ESG)
(2)ファイル転送セッションレイヤ(3GPP-MBMS-USD)
(3)FLUTE(ROUTE)パラメータレイヤ(FLUTE(ROUTE))
サービスレイヤ(OMA-ESG)に設定される属性情報(要素)記録領域(フラグメント)のうちトークンを格納するのにふさわしいフラグメントには、前述したように、以下の属性情報(要素)記録領域(フラグメント)がある。
(a)サービス・フラグメント(Service Fragment)
(b)コンテンツ・フラグメント(Content Fragment)
(c)インタラクティビティデータ・フラグメント(InteractivityData Fragment)
(d)スケジュール・フラグメント(Schedule Fragment)
(e)アクセス・フラグメント(Access Fragment)
(b)コンテンツ・フラグメント(Content Fragment)は、サービス・フラグメント(Service Fragment)を構成する各々のコンテンツ(サービスがチャネルを記述する場合は番組等の単位)を記述するフラグメントである。
例えば、OMAとは異なる標準化団体において、このスキーマ定義を利用して機能要素を追加するために新たな要素が必要となった場合には、この拡張領域下に、様々な要素を追加規定することができる。ただし、OMA自身でスキーマを拡張する場合、もしくは、他の標準化団体自身が全体のスキーマを変更できる場合には追加要素そのものをプライベート・エクステンション(PrivateExtension)要素上に格納するように定義される。
図26に示すように、プライベート・エクステンション(PrivateExtension)データ記録領域201の下位にトークン記録領域202を設定することができる。
トークンのXMLスキーマ定義は、例えば、以下の設定とする。
<xs:element name="SWClass" type="xs:string" xmlns:xs="http://www.w3.org/2001/XMLSchema"/>
上記設定の文字列表現としてエンコードする。
<Service>
・・・
<PrivateExt>
<SWClass>SWクラスの文字列</SWClass>
</PrivateExt>
</Service>
先に図25を参照して説明したように、
シグナリングデータ(メタデータ)は、図25に示すように、以下の3つのレイヤを持つ。
(1)サービスレイヤ(OMA-ESG)
(2)ファイル転送セッションレイヤ(3GPP-MBMS-USD)
(3)FLUTE(ROUTE)パラメータレイヤ(FLUTE(ROUTE))
サービス単位のシグナリングデータであるUSD(ユーザサービスディスクリプション)に設定される属性情報(要素)記録領域(フラグメント)のうちトークンを格納するのにふさわしいフラグメントには、前述したように、以下の属性情報(要素)記録領域(フラグメント)がある。
(f)スケジュール・フラグメント(Schedule Fragment)
(g)フィルタディスクリプション・フラグメント(FilterDescription Fragment)
USD(ユーザサービスディスクリプション)の全体構成例を図27に示す。
USD(ユーザサービスバンドルディスクリプション)210は、複数のUSD(ユーザサービスディスクリプション)211の集合である。
図27に示す白抜きひし形の矢印は、白抜き矢印側の要素が接続要素を含む(include)ことを意味する。
通常矢印は、参照(reference)関係を示す。
スケジュール(Schedule)要素212が設定される。なお、要素は、フラグメントと同意である。
スケジュール(Schedule)要素212の回に、スケジュールディスクリプション(Schedule Description)要素213、さらに、その下意にフィルタディスクリプション(Filter Description)要素214が設定される。
USD(ユーザサービスバンドルディスクリプション)210以下、
USD(ユーザサービスディスクリプション)要素211、
スケジュール(Schedule)要素212
これらの各要素が設定される。
このスケジュールディスクリプションURI 212aに基づいて、スケジュールディスクリプション(Schedule Description)要素213が特定される。
スケジュールディスクリプション(Schedule Description)要素213以下に、アトリビュート(属性)(Attribute)データ222が設定され、アトリビュート(属性)(Attribute)データ222内に、特定のフィルタディスクリプション要素を識別するための識別情報であるフィルタディスクリプションリファレンス(filter Description Reference)223が記録される。
フィルタディスクリプション(filter Description)要素231以下には、各フィルタ対応のデータを設定するフィルタデータ(filterData)要素232が設定される。
さらに、フィルタデータ(filterData)要素232のアトリビュート(属性)(attribute)233には、図29のデータ構成に示すフィルタID(filter ID)225に対応するidデータ234が記録される。
さらに、フィルタデータ(filterData)要素232以下のデータ記録領域に上述したトークン235を記録する。
トークンのXMLスキーマ定義は、例えば、以下の設定とする。
<xs:element name="SWClass" type="xs:string" xmlns:xs="http://www.w3.org/2001/XMLSchema"/>
として、文字列表現としてエンコードする。
<filterDescription>
・・・
<filterData>
<SWClass>SWクラスの文字列</SWClass>
</filterData>
</filterDescription>
受信装置30が、トークンを利用して選択取得するデータは、アプリケーション、およびアプリケーション関連データ、あるいはサービスワーカー(SW)等のファイルであり、これらは、FLUTE/ROUTEプロトコルに従って転送される。
受信装置30は、例えば上述したシグナリングデータであるUSD等に記載されたトークンに基づいて、FLUTE/ROUTEプロトコルに従って転送されるファイルを識別して取得することが必要となる。
以下、この処理のための構成について、図31以下を参照して説明する。
USD(ユーザサービスバンドルディスクリプション)210以下、
USD(ユーザサービスディスクリプション)要素211、
スケジュール(Schedule)要素212
これらの各要素が設定される。
v=・・・
o=・・・
s=・・・
t=・・・
a=ATSC-mode:Frequency PipeID(BBPStreamID) {周波数とその周波数内のmodulation/codingパラメータ等が異なる伝送パイプのID}
a=flute-tsi: (TSI-TransportSessionIdentifier)
s=sourceFilter: IN IP4 IP Address(ソースIPアドレス)
m=APPLICATION port(ポート番号) FLUTE/UDP
c=IN IP4 IPAddress(ディスティネーションIPアドレス)
この情報に従って特定されるファイル特定構成を図33に示す。
FLUTEの場合は、SDPで指示されるソースIPアドレス(SourceIPAddress)、ディスティネーションIPアドレス(DestinationIPAddress)、ポート番号(Port)、TSIにて特定される。これは、FLUTEセッション単位で実行される)。
また、LCTパケットに格納されるTOI(TransportObjectIdentifier)により所望のファイルが特定される。
TOIが0のLCTパケットにはFDT(File Description Table)が格納され、同じTSIで特定されるトランスポートセッションの内の他のファイルオブジェクトについて、各々のファイルURL(FDT-Instance/File/@ContentLocatoinに格納)と、対応するTOI(FDT-Instance/File/@TOIに格納)との関係が解決される。
v=・・・
o=・・・
s=・・・
t=・・・
a=ATSC-mode: Frequency PipeID(BBPStreamID) {周波数とその周波数内のmodulation/codingパラメータ等が異なる伝送パイプのID}
s=sourceFilter: IN IP4 IP Address(ソースIPアドレス)
m=APPLICATION port(ポート番号) ROUTE/UDP
c=IN IP4 IPAddress(ディスティネーションIPアドレス)
この情報に従って特定されるファイル特定構成を図35に示す。
ソースIPアドレス(SourceIPAddress)、ディスティネーションIPアドレス(DestinationIPAddress)がIPパケットの特定に、Port番号がUDPパケットの特定に利用される。
先に図25を参照して説明したように、
シグナリングデータ(メタデータ)は、図25に示すように、以下の3つのレイヤを持つ。
(1)サービスレイヤ(OMA-ESG)
(2)ファイル転送セッションレイヤ(3GPP-MBMS-USD)
(3)FLUTE(ROUTE)パラメータレイヤ(FLUTE(ROUTE))
例えばファイル(File)要素の属性であるコンテンツロケーション(Content-Location)属性に、ファイルURLが格納される。
このFDT-Instance要素の属性、もしくは、File要素の属性にトークンを記録する構成について、図36以下を参照して説明する。
FDTインスタンス(FDT Instance)要素301以下に、
FDTインスタンス対応のアトリビュート(属性)(Attribute)302、
ファイル(File)要素303が設定される。
さらに、ファイル(File)要素303以下に、
ファイル対応のアトリビュート(属性)(Attribute)304が設定される。
ファイル対応のアトリビュート(属性)(Attribute)304、
これらの詳細構成を図37に示す。
このデータ記録フィールド(any)311,312にトークンを記録する。
トークンのXMLスキーマ定義は、例えば、以下の設定とする。
<xs:attribute name="SWClass"type="xs:string" xmlns:xs="http://www.w3.org/2001/XMLSchema"/>
上記設定の文字列表現としてエンコードする。
<FDT-Instance・・SWClass="SWクラスの文字列"・・・>
・・・
</FDT-Instance>
一方、「サービスワーカー(SW)クラス指定トークン<SW-Class>」が配置された場合には、このファイル転送セッションの中のすべてのファイルが所望のサービスワーカー(SW)関連ファイルであることを示す。
<FDT-Instance>
・・・
<File・・・SWClass="SWクラスの文字列"・・・>
・・・
</FDT-Instance>
図38にROUTEで規定しているLSID以下のデータ構成を示す。
図38に示すように、
LSID要素351、
トランスポートセッション(TransportSession)要素352、
ソースフロー(SourceFlow)要素353、
EFDT要素354、
ファイル(File)要素355、
これらの階層設定となる。
(a)EFDT要素354単位のアトリビュート(属性)(Attribute)データ要素361、
(b)ファイル(file)355単位のアトリビュート(属性)(Attribute)データ要素362、
(c)EFDT要素354単位のアプリケーション識別子(ApplicationIdentifier)要素363
これらの各要素が候補となる。
(b)ファイル(File)355単位のアトリビュート(属性)(Attribute)データ要素362、
これらの詳細構成を図39に示す。
このデータ記録フィールド(any)371,372にトークンを記録する。
<LSID>
・・・
<TransportSession>
・・・
<SourceFlow>
・・・
<EFDT … SWClass="SWクラスの文字列"・・・ >
・・・
</EFDT>
・・・
</SourceFlow>
・・・
</TransportSession>
・・・
</LSID>
<LSID>
・・・
<TransportSession>
・・・
<SourceFlow>
・・・
<ApplicationIdentifier>SWクラスの文字列<ApplicationIdentifier>
・・・
</SourceFlow>
・・・
</TransportSession>
・・・
</LSID>
一方、「サービスワーカー(SW)クラス指定トークン<SW-Class>」が配置された場合には、このファイル転送セッションの中のすべてのファイルが所望のサービスワーカー(SW)関連ファイルであることを示す。
<EFDT>
・・・
<File … SWClass="SWクラスの文字列"・・・ >
・・・
</EFDT >
次に、受信装置30において実行するサービスワーカー(SW)の利用可能なAPIによるキャッシングの最適化処理例について説明する。
ひのモデルは、ポリシーの種類が少ない場合には、効果があるが、クライアントの環境に応じた非常にきめの細かな制御を行えるようにする場合には、サービスワーカー(SW)の種類(クラス)が膨大になる恐れがある。この問題に対処するため、サービスワーカー(SW)はできるだけ共通のもの(多くても数種類)を用意して、サービスワーカー(SW)のロジックの中で受信装置(クライアント)の環境属性を取得するAPIを適用してキャッシングの最適化を実現することも可能である。
すなわち、APIを適用してアプリケーション実行環境の状態情報やユーザの視聴情報の統計データ等を参照しながら、キャッシングポリシーを選択できるようにする実装モデルである。
図40~図41には、左から、以下の各構成要素を示している。
(a)送信装置を構成する放送サーバ
(b)送信装置を構成するデータ配信サーバ
(c)受信装置のミドルウェア
(d)受信装置のプロキシサーバ
(e)受信装置の出力制御部で実行されるブラウザの管理下の記憶部(永続キャッシュ)
(f)受信装置の出力制御部の実行するブラウザ上で実行されるサービスワーカー(SW)
(g)受信装置の出力制御部の実行するブラウザ上で実行されるアプリケーション
(h)受信装置の出力制御部で実行されるネィティブアプリケーション
これらの各構成要素を示している。
図40~図41のシーケンス図に示す各ステップの処理について、順次、説明する。
ステップS401の処理は、ネィティブアプリケーションによるコンテンツ(番組)対応のアプリケーションの起動処理である。
上述したように、ネィティブアプリケーションは、コンテンツ(番組)対応のアプリケーションの起動処理等に用いられるアプリケーションである。
コンテンツ(番組)対応のアプリケーションが、例えば、番組中に埋め込まれたトリガー情報に基づいて起動する設定の場合は、このネィティブアプリケーションによる起動処理は不要である。
ステップS402において、起動されたアプリケーションが、サービスワーカー(SW)の登録処理を実行する。
登録処理によってサービスワーカー(SW)は、記憶部(永続キャッシュ)に格納され、いつでも利用可能な状態になる。
このサービスワーカー(SW)登録処理は、サービスワーカー(SW)自身からは、登録(install)イベントの検出として把握され、サービスワーカー(SW)は、この登録(install)イベント検出を契機として、ステップS403のキャッシュ制御を開始する。
サービスワーカー(SW)は、登録(install)イベントを検出すると、ステップS403において、例えばスクリプト記述に従った記憶部(永続キャッシュ)の制御を開始する。
具体的には、特定クラスのサービスワーカー(SW)、または特定クラスのサービスワーカー(SW)の管理対象となるリソース(アプリケーションや、アプリ関連データ)の取得、キャッシュ展開(格納)処理を開始する。
APIを適用して得られる最適ファイル選択情報は、例えば、アプリケーション実行環境の状態情報やユーザの視聴情報統計データ等に基づいて得られる情報である。
ステップS404では、先に図8~図9を参照して説明したリソース送受信処理における図8~9(A-1~2)の各ステップのセグメントファイルに対する処理を、リソースに対する処理に置き換えた処理が実行される。
ステップS406において、アプリケーションがアプリケーションパーツ、例えばアプリケーションの実行に必要となる動画ファイルや静止画ファイル、あるいはJavaScript(登録商標)プログラム、音声データ等のアプリ関連データをサービスワーカー(SW)に要求する。
この要求処理は、サービスワーカー(SW)におけるフェッチ(fetch)イベント検出に相当する。
ステップS407~S409において、サービスワーカー(SW)は、要求されたパーツを記憶部(永続キャッシュ)から取得して、アプリケーションに提供する。
APIを適用して得られる最適ファイル選択情報は、例えば、アプリケーション実行環境の状態情報やユーザの視聴情報統計データ等に基づいて得られる情報である。
ステップS410~S411の処理は、サービスワーカー(SW)によるアクティベート(activate)イベント検出時の処理である。
アクティベート(activate)イベントは、例えば、ユーザによるリソースの削除要求の入力が実行された場合、あるいはアプリケーションの有効期限が切れた場合などに検出される。
サービスワーカー(SW)が、アクティベート(activate)イベントを検出すると、例えばスクリプト記述に従った記憶部(永続キャッシュ)の制御を開始する。
具体的には、特定クラスのサービスワーカー(SW)、または特定クラスのサービスワーカー(SW)の管理対象となるリソース(アプリケーションや、アプリ関連データ)の削除処理等を行なう。
APIを適用して得られる最適ファイル選択情報は、例えば、アプリケーション実行環境の状態情報やユーザの視聴情報統計データ等に基づいて得られる情報である。
ステップS412~S415の処理は、サービスワーカー(SW)によるタイマーイベント検出時の処理である。
タイマーイベントは、例えば、アプリケーションの有効期限が切れた場合、更新期限がきた場合などに検出される。
タイマーイベントに応じた処理としては、例えばキャッシュリソースの削除、あるいは更新リソースや追加リソースの取得処理などがある。
APIを適用して得られる最適ファイル選択情報は、例えば、アプリケーション実行環境の状態情報やユーザの視聴情報統計データ等に基づいて得られる情報である。
ステップS414~S415は、タイマーイベントに応じた更新リソースや追加リソースの取得処理のシーケンスを示している。
なお、ステップS414では、先に図8~図9を参照して説明したリソース送受信処理における図8~9(A-1~2)の各ステップのセグメントファイルに対する処理を、リソースに対する処理に置き換えた処理が実行される。
次に、通信装置である送信装置(サーバ)20と、受信装置(クライアント)30の装置構成例について、図42、図43を参照して説明する。
送信装置(サーバ)20は、データ処理部751、通信部752、記憶部753を有する。
受信装置(クライアント)30は、データ処理部771、通信部772、記憶部773、入力部774、出力部775を有する。
データ処理部には通信データ処理部771a、再生処理部771bが含まれる。
記憶部753は配信対象とするAVセグメント、アプリケーション、サービスワーカー(SW)、アプリケーションによって利用されるデータ、シグナリングデータなどが格納される。
さらに、記憶部753は、データ処理部751の実行するデータ処理のワークエリアとして利用され、また各種パラメータの記憶領域としても利用される。
通信部772は、送信装置(サーバ)20から配信されるデータ、例えばAVセグメントやアプリケーション、サービスワーカー(SW)、アプリケーションによって利用されるデータ、シグナリングデータ等を受信する。
具体的には、アプリケーションや、API、さらに、サービスワーカー(SW)を利用したデータ処理等を実行する。
再生データは表示部やスピーカ等の出力部775に出力される。
記憶部773はAVセグメント、サービスワーカー(SW)、アプリケーション、アプリケーションによって利用されるデータ、シグナリングデータなどが格納される。
さらに、記憶部773は、データ処理部771の実行するデータ処理のワークエリアとして利用され、また各種パラメータの記憶領域としても利用される。
以上、特定の実施例を参照しながら、本開示の実施例について詳解してきた。しかしながら、本開示の要旨を逸脱しない範囲で当業者が実施例の修正や代用を成し得ることは自明である。すなわち、例示という形態で本発明を開示してきたのであり、限定的に解釈されるべきではない。本開示の要旨を判断するためには、特許請求の範囲の欄を参酌すべきである。
(1) 受信装置において利用されるデータ管理プログラムであり、異なるデータ管理タイプを持つ複数のクラス対応のサービスワーカ(SW)から、特定クラスのサービスワーカー(SW)を選択取得して利用するデータ処理部を有する受信装置。
受信装置におけるデータ処理状況に応じて特定クラスのサービスワーカー(SW)を選択取得する(1)に記載の受信装置。
送信装置の送信するメタデータであるシグナリングデータから、特定クラスのサービスワーカー(SW)のアクセス情報を取得し、取得したアクセス情報を利用して、サービスワーカー(SW)を取得する(1)~(4)いずれかに記載の受信装置。
前記データ処理部は、
トークンを利用したアクセス情報検索処理を実行する(5)に記載の受信装置。
特定クラスのサービスワーカー(SW)のアクセス情報の検索範囲を限定可能としたサービスワーカー(SW)検索スコープトークンである(6)に記載の受信装置。
(a)ユーザ提示を目的としたサービスまたはコンテンツの属性情報を記述するサービスレイヤ、
(b)ファイル転送パラメータを記述したファイル転送セッションレイヤ、
(c)FLUTE(ROUTE)プロトコル対応のパラメータを記述したFLUTE(ROUTE)パラメータレイヤ、
上記(a)~(c)のレイヤを有し、
少なくとも(a)~(c)いずれかのレイヤにトークンが記録された構成である(6)~(8)いずれかに記載の受信装置。
前記ミドルウェアは、トークン情報設定要求に応じて設定したトークン情報に基づいて、トークン検出を行う(1)~(10)いずれかに記載の受信装置。
前記ミドルウェアは、トークン情報設定要求に応じて設定したトークン情報に基づいて、トークン検出を行う(1)~(11)いずれかに記載の受信装置。
特定のサービスワーカー(SW)の管理対象となるデータに対応するアクセス情報の検索処理を効率化するための情報であり、
前記データ処理部は、
前記サービスワーカー(SW)の更新に応じて、前記ミドルウェアに対して、新たなトークン情報の設定要求を行う(12)に記載の受信装置。
受信装置において、特定クラスのサービスワーカー(SW)のアクセス情報を効率的に検索するための検索補助情報であるトークンを記録したメタデータであるシグナリングデータを送信する(14)に記載の送信装置。
特定クラスのサービスワーカー(SW)のアクセス情報の検索範囲を限定可能としたサービスワーカー(SW)検索スコープトークン、または、
特定クラスのサービスワーカー(SW)のアクセス情報が記録されていることを示すサービスワーカー(SW)クラス指定トークンである(15)に記載の送信装置。
前記受信装置のデータ処理部が、受信装置において利用されるデータ管理プログラムであり、異なるデータ管理タイプを持つ複数のクラス対応のサービスワーカ(SW)から、特定クラスのサービスワーカー(SW)を選択取得して利用するデータ処理方法。
受信装置において利用されるデータ管理プログラムであり、異なるデータ管理タイプを持つ複数のクラス対応のサービスワーカ(SW)を送信するデータ処理方法。
具体的には、例えば、受信装置において利用されるデータ管理プログラムであり、異なるデータ管理タイプを持つ複数のクラス対応のサービスワーカ(SW)から、特定クラスのSWを選択取得して利用可能とした。例えば、受信装置におけるアプリケーション利用状況に応じて選択されるクラス対応のSWの利用を実現する。受信装置は、特定クラスのSWのアクセス情報を効率的に検索可能とするためのトークンを記録したシグナリングデータを利用して特定クラスのSWのアクセス情報を取得してSWを取得する。
本構成により、各々の受信装置に最適化したデータ管理を実行するサービスワーカー(SW)の選択取得および利用処理を可能とする装置、方法が実現される。
20 送信装置
21 放送サーバ
22 データ配信サーバ
30 受信装置
31 TV
32 PC
33 携帯端末
50 シグナリングデータ
60 AVセグメント
70 その他のデータ
110 ミドルウェア
111 通信部(PHY/MAC)
112 シグナリング取得部
113 シグナリング解析部
114 ファイル取得部
120 HTTPプロキシサーバ
121,122 キャッシュ部
123 アドレス解決部
130 出力制御部
131 表示データ(HTML/JavaScript(登録商標)等)取得&解析部
132 表示処理部(Renderer)
133 記憶部(永続キャッシュ)
140 外部装置
141 出力制御部
142 記憶部(永続キャッシュ)
751 データ処理部
752 通信部
753 記憶部
771 データ処理部
772 通信部
773 記憶部
774 入力部
775 出力部
801 CPU
802 ROM
803 RAM
804 バス
805 入出力インタフェース
806 入力部
807 出力部
808 記憶部
809 通信部
810 ドライブ
811 リムーバブルメディア
Claims (18)
- 受信装置において利用されるデータ管理プログラムであり、異なるデータ管理タイプを持つ複数のクラス対応のサービスワーカ(SW)から、特定クラスのサービスワーカー(SW)を選択取得して利用するデータ処理部を有する受信装置。
- 前記データ処理部は、
受信装置におけるデータ処理状況に応じて特定クラスのサービスワーカー(SW)を選択取得する請求項1に記載の受信装置。 - 前記データ処理状況は、受信装置におけるアプリケーションまたはデータの利用状況である請求項2に記載の受信装置。
- 前記サービスワーカー(SW)は、管理対象データとしてアプリケーション、または画像、または音声、少なくともいずれかのデータファイルを含む請求項1に記載の受信装置。
- 前記データ処理部は、
送信装置の送信するメタデータであるシグナリングデータから、特定クラスのサービスワーカー(SW)のアクセス情報を取得し、取得したアクセス情報を利用して、サービスワーカー(SW)を取得する請求項1に記載の受信装置。 - 前記シグナリングデータには、特定クラスのサービスワーカー(SW)のアクセス情報を効率的に検索するための検索補助情報であるトークンが記録され、
前記データ処理部は、
トークンを利用したアクセス情報検索処理を実行する請求項5に記載の受信装置。 - 前記トークンは、
特定クラスのサービスワーカー(SW)のアクセス情報の検索範囲を限定可能としたサービスワーカー(SW)検索スコープトークンである請求項6に記載の受信装置。 - 前記トークンは、特定クラスのサービスワーカー(SW)のアクセス情報が記録されていることを示すサービスワーカー(SW)クラス指定トークンである請求項6に記載の受信装置。
- 前記シグナリングデータは、
(a)ユーザ提示を目的としたサービスまたはコンテンツの属性情報を記述するサービスレイヤ、
(b)ファイル転送パラメータを記述したファイル転送セッションレイヤ、
(c)FLUTE(ROUTE)プロトコル対応のパラメータを記述したFLUTE(ROUTE)パラメータレイヤ、
上記(a)~(c)のレイヤを有し、
少なくとも(a)~(c)いずれかのレイヤにトークンが記録された構成である請求項6に記載の受信装置。 - 前記データ処理部は、前記サービスレイヤ、または、前記ファイル転送セッションレイヤ、または、前記FLUTE(ROUTE)パラメータレイヤに記録されたトークンを取得する請求項9に記載の受信装置。
- 前記受信装置のデータ処理部において実行されるアプリケーションは、受信データの処理を実行するミドルウェアに対して、前記トークンを検出するためのトークン情報の設定要求を実行し、
前記ミドルウェアは、トークン情報設定要求に応じて設定したトークン情報に基づいて、トークン検出を行う請求項1に記載の受信装置。 - 前記受信装置のデータ処理部において実行されるデータ管理プログラムであるサービスワーカー(SW)は、受信データの処理を実行するミドルウェアに対して、前記トークンを検出するためのトークン情報の設定要求を実行し、
前記ミドルウェアは、トークン情報設定要求に応じて設定したトークン情報に基づいて、トークン検出を行う請求項1に記載の受信装置。 - 前記トークンは、
特定のサービスワーカー(SW)の管理対象となるデータに対応するアクセス情報の検索処理を効率化するための情報であり、
前記データ処理部は、
前記サービスワーカー(SW)の更新に応じて、前記ミドルウェアに対して、新たなトークン情報の設定要求を行う請求項12に記載の受信装置。 - 受信装置において利用されるデータ管理プログラムであり、異なるデータ管理タイプを持つ複数のクラス対応のサービスワーカ(SW)を送信する送信装置。
- 前記送信装置は、
受信装置において、特定クラスのサービスワーカー(SW)のアクセス情報を効率的に検索するための検索補助情報であるトークンを記録したメタデータであるシグナリングデータを送信する請求項14に記載の送信装置。 - 前記トークンは、
特定クラスのサービスワーカー(SW)のアクセス情報の検索範囲を限定可能としたサービスワーカー(SW)検索スコープトークン、または、
特定クラスのサービスワーカー(SW)のアクセス情報が記録されていることを示すサービスワーカー(SW)クラス指定トークンである請求項15に記載の送信装置。 - 受信装置において実行するデータ処理方法であり、
前記受信装置のデータ処理部が、受信装置において利用されるデータ管理プログラムであり、異なるデータ管理タイプを持つ複数のクラス対応のサービスワーカ(SW)から、特定クラスのサービスワーカー(SW)を選択取得して利用するデータ処理方法。 - 送信装置において実行するデータ処理方法であり、
受信装置において利用されるデータ管理プログラムであり、異なるデータ管理タイプを持つ複数のクラス対応のサービスワーカ(SW)を送信するデータ処理方法。
Priority Applications (7)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US15/520,150 US10880024B2 (en) | 2014-10-28 | 2015-10-21 | Reception device, transmission device, and data processing method |
MX2017005212A MX2017005212A (es) | 2014-10-28 | 2015-10-21 | Dispositivo de recepcion, dispositivo de transmision, y metodo de procesamiento de datos. |
CA2964719A CA2964719C (en) | 2014-10-28 | 2015-10-21 | Reception device, transmission device, and data processing method |
EP15854020.3A EP3214844B1 (en) | 2014-10-28 | 2015-10-21 | Reception device, transmission device, and data processing method |
CN201580057869.2A CN107113471A (zh) | 2014-10-28 | 2015-10-21 | 接收装置、发送装置和数据处理方法 |
KR1020177010488A KR102460099B1 (ko) | 2014-10-28 | 2015-10-21 | 수신 장치, 송신 장치 및 데이터 처리 방법 |
JP2016556516A JP6583281B2 (ja) | 2014-10-28 | 2015-10-21 | 受信装置、送信装置、およびデータ処理方法 |
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2014219659 | 2014-10-28 | ||
JP2014-219659 | 2014-10-28 |
Publications (1)
Publication Number | Publication Date |
---|---|
WO2016067988A1 true WO2016067988A1 (ja) | 2016-05-06 |
Family
ID=55857329
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
PCT/JP2015/079645 WO2016067988A1 (ja) | 2014-10-28 | 2015-10-21 | 受信装置、送信装置、およびデータ処理方法 |
Country Status (8)
Country | Link |
---|---|
US (1) | US10880024B2 (ja) |
EP (1) | EP3214844B1 (ja) |
JP (1) | JP6583281B2 (ja) |
KR (1) | KR102460099B1 (ja) |
CN (1) | CN107113471A (ja) |
CA (1) | CA2964719C (ja) |
MX (1) | MX2017005212A (ja) |
WO (1) | WO2016067988A1 (ja) |
Cited By (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN108287737A (zh) * | 2017-07-13 | 2018-07-17 | 广州市动景计算机科技有限公司 | Service Worker启动方法、装置及电子设备 |
WO2019076347A1 (zh) * | 2017-10-19 | 2019-04-25 | 华为技术有限公司 | 通信方法和通信装置 |
JP2022507266A (ja) * | 2018-11-14 | 2022-01-18 | サイトリックス システムズ,インコーポレイテッド | Saasアプリケーションのためのプッシュ配信通知サービスのためのシステムおよび方法 |
Families Citing this family (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20180007307A1 (en) * | 2016-07-02 | 2018-01-04 | Qualcomm Incorporated | Distributed Implementation Architecture for Broadcast Receiver |
CN111417130B (zh) * | 2019-01-07 | 2022-04-08 | 中国移动通信有限公司研究院 | 一种数据处理方法及设备 |
HUE061986T2 (hu) | 2019-05-10 | 2023-09-28 | Jt Int Sa | Személyi számítástechnikai készülék konfigurálása aeroszol elõállító készülékkel való kommunikációra |
EP3737108B1 (en) | 2019-05-10 | 2021-08-25 | JT International S.A. | Configuring a personal computing device for communication with an aerosol generation device |
US11422829B1 (en) | 2021-11-17 | 2022-08-23 | Morgan Stanley Services Group Inc. | Systems and methods for resilient service worker bridge |
Citations (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2008032371A1 (fr) * | 2006-09-13 | 2008-03-20 | Kddi Corporation | Dispositif et procédé de transmission de contenus de radiodiffusion |
Family Cites Families (18)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
DE4446286C1 (de) * | 1994-12-23 | 1996-06-20 | Siemens Ag | Responsives System zur Signalverarbeitung sowie Verfahren zur Herstellung eines responsiven Systems |
JP4261895B2 (ja) * | 2002-12-13 | 2009-04-30 | キヤノン株式会社 | デジタル放送受信機及びデジタル放送受信機の制御方法 |
EP2146528A1 (en) * | 2008-07-15 | 2010-01-20 | Gemplus | Method for accessing a service offered from a token, corresponding token and system |
KR101635889B1 (ko) * | 2008-11-18 | 2016-07-05 | 엘지전자 주식회사 | 비실시간 서비스 처리 방법 및 방송 수신기 |
CN102053984A (zh) | 2009-11-10 | 2011-05-11 | 杜卓 | 信息检索查询与信息发布的系统及方法 |
US9071531B2 (en) * | 2010-09-28 | 2015-06-30 | British Telecommunications Public Limited Company | Multi-class data transport |
TWI545955B (zh) * | 2011-04-28 | 2016-08-11 | Sony Corp | Signal receiving apparatus and method, a signal transmission apparatus and method, and program |
US9151630B2 (en) | 2011-07-05 | 2015-10-06 | Aisin Aw Co., Ltd. | Evaluation indication system, evaluation indication method and computer-readable storage medium |
WO2013022309A1 (ko) * | 2011-08-10 | 2013-02-14 | 엘지전자 주식회사 | 방송 서비스 전송 방법, 그 수신 방법 및 방송 서비스 수신 장치 |
JP6348251B2 (ja) | 2012-09-13 | 2018-06-27 | サターン ライセンシング エルエルシーSaturn Licensing LLC | 端末装置、受信方法、およびプログラム |
US9264648B2 (en) * | 2012-10-09 | 2016-02-16 | Sony Corporation | Receiving device, receiving method, transmitting device, and transmitting method |
MX345034B (es) * | 2012-11-28 | 2017-01-16 | Lg Electronics Inc | Aparato y metodo para procesar un servicio interactivo. |
WO2016018077A1 (ko) * | 2014-07-30 | 2016-02-04 | 엘지전자 주식회사 | 방송 전송 장치, 방송 수신 장치, 방송 전송 장치의 동작 방법 및 방송 수신 장치의 동작 방법 |
KR101973469B1 (ko) * | 2014-09-02 | 2019-04-29 | 엘지전자 주식회사 | 방송 수신 장치, 방송 수신 장치의 동작 방법, 방송 수신 장치와 연동하는 연동 장치 및 연동 장치의 동작 방법 |
US9979987B2 (en) * | 2014-10-12 | 2018-05-22 | Lg Electronics Inc. | Device for transmitting broadcast signal, device for receiving broadcast signal, method for transmitting broadcast signal, and method for receiving broadcast signal |
WO2016060410A1 (ko) * | 2014-10-14 | 2016-04-21 | 엘지전자 주식회사 | 방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호 송신 방법, 및 방송 신호 수신 방법 |
JP5880678B2 (ja) | 2014-12-25 | 2016-03-09 | 株式会社三洋物産 | 遊技機 |
US20170209867A1 (en) * | 2016-01-27 | 2017-07-27 | Size Reduction Specialists Corp. | Plastic granulator stationary cutting segment |
-
2015
- 2015-10-21 US US15/520,150 patent/US10880024B2/en active Active
- 2015-10-21 CA CA2964719A patent/CA2964719C/en active Active
- 2015-10-21 MX MX2017005212A patent/MX2017005212A/es unknown
- 2015-10-21 EP EP15854020.3A patent/EP3214844B1/en active Active
- 2015-10-21 WO PCT/JP2015/079645 patent/WO2016067988A1/ja active Application Filing
- 2015-10-21 JP JP2016556516A patent/JP6583281B2/ja not_active Expired - Fee Related
- 2015-10-21 KR KR1020177010488A patent/KR102460099B1/ko active IP Right Grant
- 2015-10-21 CN CN201580057869.2A patent/CN107113471A/zh active Pending
Patent Citations (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2008032371A1 (fr) * | 2006-09-13 | 2008-03-20 | Kddi Corporation | Dispositif et procédé de transmission de contenus de radiodiffusion |
Non-Patent Citations (2)
Title |
---|
See also references of EP3214844A4 * |
SERVICE WORKERS ET AL.: "W3C First Public Working Draft 08 May 21, W3C", XP009502496, Retrieved from the Internet <URL:http://www.w3.org/TR/2014/WD-service-workers-20140508> [retrieved on 20151203] * |
Cited By (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN108287737A (zh) * | 2017-07-13 | 2018-07-17 | 广州市动景计算机科技有限公司 | Service Worker启动方法、装置及电子设备 |
CN108287737B (zh) * | 2017-07-13 | 2021-08-17 | 阿里巴巴(中国)有限公司 | Service Worker启动方法、装置及电子设备 |
WO2019076347A1 (zh) * | 2017-10-19 | 2019-04-25 | 华为技术有限公司 | 通信方法和通信装置 |
JP2022507266A (ja) * | 2018-11-14 | 2022-01-18 | サイトリックス システムズ,インコーポレイテッド | Saasアプリケーションのためのプッシュ配信通知サービスのためのシステムおよび方法 |
US11323528B2 (en) | 2018-11-14 | 2022-05-03 | Citrix Systems, Inc. | Systems and methods for push notification service for SAAS applications |
JP7076641B2 (ja) | 2018-11-14 | 2022-05-27 | サイトリックス システムズ,インコーポレイテッド | Saasアプリケーションのためのプッシュ配信通知サービスのためのシステムおよび方法 |
Also Published As
Publication number | Publication date |
---|---|
CA2964719C (en) | 2023-03-07 |
MX2017005212A (es) | 2017-07-27 |
KR102460099B1 (ko) | 2022-10-31 |
CA2964719A1 (en) | 2016-05-06 |
EP3214844A4 (en) | 2018-05-30 |
JPWO2016067988A1 (ja) | 2017-08-03 |
US10880024B2 (en) | 2020-12-29 |
JP6583281B2 (ja) | 2019-10-02 |
CN107113471A (zh) | 2017-08-29 |
US20170317773A1 (en) | 2017-11-02 |
KR20170074874A (ko) | 2017-06-30 |
EP3214844A1 (en) | 2017-09-06 |
EP3214844B1 (en) | 2024-08-07 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
JP6583281B2 (ja) | 受信装置、送信装置、およびデータ処理方法 | |
JP6614154B2 (ja) | 受信装置、送信装置、およびデータ処理方法 | |
CN107615774B (zh) | 接收装置、发送装置及数据处理方法 | |
JP6589879B2 (ja) | 受信装置、送信装置、およびデータ処理方法 | |
CA2964712C (en) | Reception device, transmission device, and data processing method | |
KR102611253B1 (ko) | 수신 장치, 송신 장치 및 데이터 처리 방법 |
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: 15854020 Country of ref document: EP Kind code of ref document: A1 |
|
ENP | Entry into the national phase |
Ref document number: 2016556516 Country of ref document: JP Kind code of ref document: A |
|
ENP | Entry into the national phase |
Ref document number: 2964719 Country of ref document: CA |
|
ENP | Entry into the national phase |
Ref document number: 20177010488 Country of ref document: KR Kind code of ref document: A |
|
REEP | Request for entry into the european phase |
Ref document number: 2015854020 Country of ref document: EP |
|
WWE | Wipo information: entry into national phase |
Ref document number: 15520150 Country of ref document: US Ref document number: 2015854020 Country of ref document: EP |
|
WWE | Wipo information: entry into national phase |
Ref document number: MX/A/2017/005212 Country of ref document: MX |
|
NENP | Non-entry into the national phase |
Ref country code: DE |