WO2017014034A1 - 受信装置、送信装置、およびデータ処理方法 - Google Patents

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

Info

Publication number
WO2017014034A1
WO2017014034A1 PCT/JP2016/069752 JP2016069752W WO2017014034A1 WO 2017014034 A1 WO2017014034 A1 WO 2017014034A1 JP 2016069752 W JP2016069752 W JP 2016069752W WO 2017014034 A1 WO2017014034 A1 WO 2017014034A1
Authority
WO
WIPO (PCT)
Prior art keywords
application
data
size
cache
unit
Prior art date
Application number
PCT/JP2016/069752
Other languages
English (en)
French (fr)
Inventor
淳 北原
北里　直久
山岸　靖明
Original Assignee
ソニー株式会社
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by ソニー株式会社 filed Critical ソニー株式会社
Priority to KR1020177036843A priority Critical patent/KR102611253B1/ko
Priority to EP16827596.4A priority patent/EP3327576A4/en
Priority to CA2987903A priority patent/CA2987903A1/en
Priority to MX2018000649A priority patent/MX2018000649A/es
Priority to US15/573,549 priority patent/US10820041B2/en
Priority to CN201680041699.3A priority patent/CN107851072B/zh
Priority to JP2017529533A priority patent/JPWO2017014034A1/ja
Publication of WO2017014034A1 publication Critical patent/WO2017014034A1/ja

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/433—Content storage operation, e.g. storage operation in response to a pause request, caching operations
    • H04N21/4331—Caching operations, e.g. of an advertisement for later insertion during playback
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G06F12/02—Addressing or allocation; Relocation
    • G06F12/08—Addressing or allocation; Relocation in hierarchically structured memory systems, e.g. virtual memory systems
    • G06F12/0802—Addressing of a memory level in which the access to the desired data or data block requires associative addressing means, e.g. caches
    • G06F12/0806—Multiuser, multiprocessor or multiprocessing cache systems
    • G06F12/0813—Multiuser, multiprocessor or multiprocessing cache systems with a network or matrix configuration
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F13/00—Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/434—Disassembling of a multiplex stream, e.g. demultiplexing audio and video streams, extraction of additional data from a video stream; Remultiplexing of multiplex streams; Extraction or processing of SI; Disassembling of packetised elementary stream
    • H04N21/4345—Extraction or processing of SI, e.g. extracting service information from an MPEG stream
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/435—Processing of additional data, e.g. decrypting of additional data, reconstructing software from modules extracted from the transport stream
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/435—Processing of additional data, e.g. decrypting of additional data, reconstructing software from modules extracted from the transport stream
    • H04N21/4355—Processing of additional data, e.g. decrypting of additional data, reconstructing software from modules extracted from the transport stream involving reformatting operations of additional data, e.g. HTML pages on a television screen
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/44—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream or rendering scenes according to encoded video stream scene graphs
    • H04N21/44004—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream or rendering scenes according to encoded video stream scene graphs involving video buffer management, e.g. video decoder buffer or video display buffer
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/45—Management operations performed by the client for facilitating the reception of or the interaction with the content or administrating data related to the end-user or to the client device itself, e.g. learning user preferences for recommending movies, resolving scheduling conflicts
    • H04N21/462—Content or additional data management, e.g. creating a master electronic program guide from data received from the Internet and a Head-end, controlling the complexity of a video stream by scaling the resolution or bit-rate based on the client capabilities
    • H04N21/4622—Retrieving content or additional data from different sources, e.g. from a broadcast channel and the Internet
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/47—End-user applications
    • H04N21/478—Supplemental services, e.g. displaying phone caller identification, shopping application
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/61—Network physical structure; Signal processing
    • H04N21/6106—Network physical structure; Signal processing specially adapted to the downstream path of the transmission network
    • H04N21/6125—Network physical structure; Signal processing specially adapted to the downstream path of the transmission network involving transmission via Internet
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/64—Addressing
    • H04N21/6405—Multicasting
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/64—Addressing
    • H04N21/6408—Unicasting
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/643—Communication protocols
    • H04N21/64322—IP
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/81—Monomedia components thereof
    • H04N21/812—Monomedia components thereof involving advertisement data
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/81—Monomedia components thereof
    • H04N21/8166—Monomedia components thereof involving executable data, e.g. software
    • H04N21/8173—End-user applications, e.g. Web browser, game
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2212/00—Indexing scheme relating to accessing, addressing or allocation within memory systems or architectures
    • G06F2212/31—Providing disk cache in a specific location of a storage system
    • G06F2212/314—In storage network, e.g. network attached cache

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 receiving device, a transmitting device, and a data processing method corresponding to communication data that execute reception or transmission of data via a broadcast wave or a network.
  • OTT Over The Top
  • OTT content Distribution content by OTT
  • OTT video image (video) data distribution service using OTT
  • OTT-V Over The Top Video
  • DASH Dynamic Adaptive Streaming HTTP
  • HTTP HyperText Transfer Protocol
  • a content distribution server such as a broadcasting station can reproduce content on various clients as data distribution destinations. Create a manifest file describing URL and URL (Uniform Resource Locator) and provide it to the client.
  • URL Uniform Resource Locator
  • the client acquires the manifest file from the server, selects the optimum bit rate content according to the size of the display unit of the own device and the available communication band, and receives and plays back the selected content. It is possible to dynamically change the bit rate according to fluctuations in the network bandwidth, and it is possible for the client side to switch and receive the optimal content according to the situation at any time, reducing the occurrence of video interruptions Playback is realized. Note that adaptive (adaptive) streaming is described in, for example, Japanese Patent Application Laid-Open No. 2011-87103.
  • One-way communication by broadcast waves, etc., or two-way communication via a network such as the Internet one-way from a transmission device such as a broadcasting station or other content server to a reception device such as a TV, PC, or portable terminal
  • a transmission device such as a broadcasting station or other content server
  • a reception device such as a TV, PC, or portable terminal
  • a transmission device such as a broadcasting station or other content server
  • a reception device such as a TV, PC, or portable terminal
  • ATSC Advanced Television System Commitment
  • ATSC-PHY ATSC3.0 broadcast receiving processing and other middleware on a broadcast distribution device (tuner-equipped device) that implements an ATSC3.0-compliant physical layer (ATSC-PHY).
  • application programs used on the Internet or the like that is, so-called client applications are used as they are under the control of signaling data, and various applications provided by broadcast content output processing, broadcast waves, etc. are used.
  • client applications are used as they are under the control of signaling data
  • various applications provided by broadcast content output processing, broadcast waves, etc. are used.
  • a broadcast service receiving device (a dedicated server, PC, TV, tablet, smartphone, etc.) installed at home or in a hot spot, an ATSC 3.0 compliant physical layer (ATSC-PHY), and an ATSC 3.0 broadcast Implement receiving middleware.
  • an application for example, an ATSC 3.0 DASH client application running on the playback control unit or application control unit of the receiving device is used to play back broadcast content or broadcast.
  • Various applications to be distributed can be executed.
  • a cache process is required to store various files constituting the application, for example, image files such as moving images, audio files, and the like in a cache (storage unit) in the user apparatus.
  • image files such as moving images, audio files, and the like
  • a cache storage unit
  • the present disclosure has been made in view of the above-described problems, for example, and acquires data size and link information for each application or application component in a receiving apparatus that receives and executes an application via a broadcast wave or the like.
  • a receiving apparatus, a transmitting apparatus, and a data processing method are provided that enable execution of a predetermined application unit or application component unit application by the cache processing.
  • data size information and link information of application components are acquired, and cacheable applications or application components are selected based on the acquired information, and cache processing is performed.
  • a receiving device, a transmitting device, and a data processing method are provided that enable reliable application execution based on cache data.
  • the first aspect of the present disclosure is: A communication unit that receives first signaling data in which application size that is data size of an application and application link information that is link information between applications is recorded; One or more cacheable applications are cached by comparing the cache size, which is the data size that can be stored in the storage unit of the own device, with the data size of each application having a link relationship acquired from the first signaling data.
  • the receiving apparatus includes a data processing unit that determines a target application and executes cache processing for each application.
  • the second aspect of the present disclosure is: A packet storing application configuration data; A data processing unit that generates a packet storing first signaling data in which application size that is data size of the application and application link information that is link information between applications is recorded; A communication unit for transmitting the packet generated by the data processing unit; In the transmission device.
  • the third aspect of the present disclosure is: A data processing method executed in the receiving device,
  • the communication unit receives the first signaling data in which the application size which is the data size of the application and the application link information which is the link information between the applications are recorded,
  • the data processing unit compares the cache size, which is the data size that can be stored in the storage unit of the device itself, with the data size of each application in the link relationship acquired from the first signaling data, and can cache one
  • the fourth aspect of the present disclosure is: A data processing method executed in a transmission device,
  • the data processor A packet storing application configuration data; Generating a packet storing the first signaling data in which the application size that is the data size of the application and the application link information that is link information between the applications is recorded;
  • the communication unit transmits the packet generated by the data processing unit.
  • 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 application execution processing with a high degree of perfection by executing cache processing in units of applications or presentation units in a receiving device.
  • the receiving device receives the application data that is the data size of the application, the application link information, and the signaling data that records the data size of each presentation unit (PU) that is the application component from the transmitting device. To do.
  • the receiving device compares the cache size with the data size of each application and PU, determines a cacheable application or PU as cache target data, and executes cache processing for each application or PU.
  • FIG. 4 is a diagram for explaining an example of data output in a receiving device (client) 30.
  • FIG. It is a figure explaining the example of selection of the output advertisement using various user information.
  • FIG. It is a figure explaining the structural example of a receiver.
  • FIG. It is a figure explaining the structural example of an application. It is a figure explaining the structure and link of an application. It is a figure explaining the correspondence example of the size of an application, and a cache size.
  • 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 includes, for example, a broadcast server (broadcast station) 21 that mainly transmits TV programs, an advertisement server 22 that mainly transmits advertisement data, and a data distribution server 23 that transmits various data. And the like, which provide various contents (broadcast programs, advertisements, other data).
  • 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. In FIG.
  • a television 31, a PC 32, and a mobile terminal 33 are shown as representative examples of the receiving device, but other receiving devices that can execute the processing of the present disclosure include, for example, a smartphone, a tablet terminal, Various receiving devices such as a smart watch and a wearable device are included.
  • the broadcast server (broadcasting station) 21, the advertisement server 22, and the data distribution server 23 are distinguished from each other as an example of the transmission device 20, but one server is a broadcast program, advertisement, and other data. It is good also as a structure which transmits all. For example, one broadcasting station distributes various programs, advertisements, applications, and other data via broadcast waves, or one server transmits various programs, advertisements, applications, and others via a communication network. A configuration for distributing the data is also possible.
  • 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 various formats such as MPEG-DASH standard which is a standard of adaptive (adaptive) streaming technology and MMT (MPEG Media Transport).
  • 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 AV segment is also called a DASH segment.
  • 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), etc., and various control information such as application 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 from the transmission device 20 as data in, for example, an XML (Extensible Markup Language) format.
  • the signaling data is repeatedly transmitted from time to time. 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 applications 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.
  • 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 a storage unit (client cache). 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
  • ESG ESG
  • NRT content
  • DASH ISO BMFF
  • Video / Audio / CC (6)
  • Application layer Application layer (Applications (HTML5 (HyperText Markup Language 5))
  • a signaling layer is set as an upper layer of an IP multicast layer (IP Multicast).
  • IP Multicast IP Multicast
  • 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.
  • the signaling data is data including access information of AV segments received and reproduced by the receiving device (client) and guidance information and control information necessary for post-reception processing such as decoding processing, and is repeatedly transmitted from the transmitting device as needed. Data.
  • USD User Service Description
  • MPD Media Presentation Description
  • signaling data are data necessary for reception, playback processing, and control processing of AV segments and applications (application programs) transmitted from the transmission device in the reception device (client). It is set as (metafile) and transmitted from the transmission device.
  • 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.
  • FIG. 4 shows protocol stacks for ROUTE and FLUTE.
  • 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.
  • 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 performs generation or analysis of data to be transferred according to the ROUTE protocol, and other various data output control. For example, data generation and analysis using HTML5 , Perform output processing.
  • 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).
  • ATSC Advanced Television System Commitment
  • IP-based transport stack a file based on the MPEG-DASH file format (ISO-BMFF file, MP4 file) is expanded to RUTE (File Delivery over Unidirectional Transport) (ROUTE (Real-Time Object).
  • RUTE File Delivery over Unidirectional Transport
  • ROUTE Real-Time Object
  • a fragmented MP4 fragmented MP4 (fragmented MP4) file sequence of DASH standard, MPD (Media Presentation Description) which is a control file (signaling data) storing DASH standard, and broadcast distribution Signaling data for USBD / USD (User Service Bundle Description / User Service Description), S-TSID (Service based Transport Session Description), For example, these signal link data can be transferred.
  • MPD Media Presentation Description
  • S-TSID Service based Transport Session Description
  • the USD is composed of information of a predetermined service unit, such as a broadcasting station or a program, for example, for using the service in the receiving apparatus such as access information (URL, etc.) for receiving the service, codec information, reproduction timing information, etc. It consists of information required for USBD is a bundle of USDs. S-TSID is additional information for each service unit, and additional information not recorded in USD is recorded.
  • the ROUTE protocol is a protocol based on FLUTE.
  • the metadata file describing the transfer control parameters in FLUTE is called FDT (File Delivery Table), and the metadata file describing the transfer control parameters in ROUTE is called S-TSID (Service based Transport Session Description).
  • S-TSID is a superset of FDT and includes FDT.
  • USBD / USD, S-TSID, MPD, etc. proposed as ATSC 3.0 service layer signaling data SLS: Service Layer Signaling
  • SLS Service Layer Signaling
  • MMT MPEG Media Transport
  • FIG. 5 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 reception device 30 can display weather information together with the program display as shown in FIG. 5.
  • all files constituting the application for example, HTML (HyperText Markup Language) files, Video files, Audio files, Style sheet,
  • HTML HyperText Markup Language
  • Video files Video files
  • Audio files Style sheet
  • the reception device 30 uses an application received from the transmission device 20 for advertisement display
  • movies, news, other broadcast programs (main content) and advertisements are alternately output to the receiving device 30 according to the timeline (time axis (t)) shown in the lower part of FIG.
  • the program start time of a certain channel selected by the user is t0
  • broadcast programs and advertisements are alternately output according to the transition as follows.
  • Time t0 to t1 Advertisement Time t1 to t2: Broadcast program
  • Time t2 to t3 Advertisement Time t3 to t4: Broadcast program
  • Time t4 to t5 Advertisement Time t5 to: Broadcast program
  • the advertisement output to the receiving device 30 is displayed using an application that is transmitted separately from the program content transmitted by the transmitting device 20.
  • the transmission apparatus 20 transmits a plurality of advertisement applications that display advertisements according to various users, so-called target advertisements, to the reception apparatus 30 as NRT (non-real time) content.
  • NRT non-real time
  • the transmission device 20 transmits advertisement applications for such various users (viewers) to the reception device 30.
  • the receiving device 30 Based on the user (viewer) information set on the receiving device 30 side, the receiving device 30 selects and acquires an advertisement optimal for the user and outputs it.
  • User information is various information, such as a user's (viewer's) age, sex, address, hobby preference, etc., for example.
  • information registered in advance in the storage unit of the receiving apparatus is used. Or it is good also as a structure which makes a user (viewer) input user information at the time of a program start, and uses this input information.
  • the application acquired by the receiving device 30 via, for example, a broadcast wave is configured by various data files. That is, as mentioned above, HTML (HyperText Markup Language) files, Video files, Audio files, Style sheet, For example, after all of the plurality of application configuration files are acquired and stored in the cache unit that is the storage unit of the receiving device 30, the execution of the application is started, whereby complete advertisement reproduction can be performed.
  • HTML HyperText Markup Language
  • the receiving device 30 In order to reliably execute the cache processing of the application configuration file, the receiving device 30 selectively acquires cacheable data after comparing the cache free capacity of the own device with the data size of the application to be acquired. It is important to start the cache process. By executing such cache control, the data for which the cache process has been started can be reliably stored in the cache unit (storage unit) of the receiving device 30. If the cache process is started without performing such cache control, there is a possibility that the cache unit (storage unit) overflows during the cache process and a part of data cannot be cached. .
  • the receiving device 30 performs cache control for selectively acquiring cacheable data and starting cache processing after comparing the cache free capacity of the device with the data size of the application to be acquired. .
  • cache control process A specific configuration of this cache control process will be described later.
  • the example of the application described with reference to FIGS. 5 and 6 is an example, and the application provided to the receiving device 30 by the transmitting device 20 is not the example described with reference to FIGS. 5 and 6.
  • there are various applications such as a news information providing application, a player information providing application during a baseball broadcast, an application for executing map information on a travel program, hotel information, quiz, questionnaire processing, and the like.
  • the receiving device 30 may be various devices such as a television 31, a PC 32, a portable terminal 33, or other devices such as a smartphone, a tablet terminal, a smart watch, and a wearable device. Consists of.
  • the 7 includes a middleware 110 that receives transmission data from a transmission device 20 such as a broadcast server or an advertisement server, a proxy server 120 that performs analysis and cache processing of the received data, program reproduction, and application execution.
  • the data reproducing unit 130 executes the data reproducing process according to the above.
  • a transmission device 20 such as a broadcast server or an advertisement server transmits AV segments, applications, signaling data, and other data composed of broadcast contents and the like by data transmission via a broadcast wave or a communication network such as the Internet.
  • the middleware 110 of the receiving device 30 illustrated in FIG. 7 receives and analyzes provided data from the transmitting device 20 via a broadcast wave.
  • 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 segment acquisition unit 114 acquires a data file such as NRT content.
  • the data received by the middleware 110 is stored in the cache unit (proxy cache) 122 via the cache control unit 121 of the proxy server 120.
  • the proxy server 120 further stores data acquired from the transmission device 20 via the network in the cache unit 122.
  • the cache control unit 121 of the proxy server 120 inputs a data acquisition request from the reproduction control unit (DASH Client) 131 of the data reproduction unit 130 or the application control unit 132, and provides the requested data to the data reproduction unit. For example, the cache control unit 121 performs address resolution processing in response to a data acquisition request from the reproduction control unit (DASH Client) 131 or the application control unit 132 and acquires data corresponding to the address from the cache unit 121. The data is output to the reproduction control unit (DASH Client) 131 and the application control unit 132 of the data reproduction unit 130. If the request data is not stored in the cache unit 122, it may be obtained from the outside and provided.
  • a playback control unit (DASH Client) 131 of the data playback unit 130 executes playback control of content transmitted in accordance with the DASH (MPEG-DASH) standard.
  • 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 content is transmitted as a segment (AV segment or the like) which is a predetermined unit of divided data according to the MP4 file format defined in MPEG, for example, and the playback control unit (DASH Client) 131 refers to the manifest file (MPD). Then, processing for acquiring a segment storing the content to be reproduced is executed.
  • AV segment AV segment or the like
  • DASH Client DASH Client
  • the application control unit 132 performs control such as execution, start, and termination of an application provided from the transmission device 20 such as the weather forecast and the advertisement application described above with reference to FIGS.
  • the output control unit 133 acquires program configuration data and application execution data provided from the reproduction control unit 131 and the application control unit 132, and executes a process of decoding the acquired data, an output process to the display unit, and the like.
  • reproduction control unit (DASH Client) 131 and the application control unit 132 refer to signaling data transmitted by the transmission device 20 (broadcast server 21, advertisement server 22, etc.) and are necessary according to information described in the signaling data. Data is acquired from the proxy server 120, and reproduction control and application control are executed in accordance with information described in the signaling data.
  • 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 content reproduction processing.
  • program schedule information such as a program guide, address information (URL (Uniform Resource Locator), etc.) necessary for program acquisition, and content reproduction processing.
  • URL Uniform Resource Locator
  • guidance information consisting of codec information (encoding method, etc.), and various control information such as application control information.
  • the reproduction control unit (DASH Client) 131 and the application control unit 132 perform data acquisition processing based on signaling data acquired by acquiring signaling data (SLS: Service Layer Signaling), data reproduction control, application execution control, and the like. Execute.
  • SLS Service Layer Signaling
  • the application control unit 132 executes application control based on various signaling data in which attribute information and control information corresponding to the application are recorded.
  • various signaling data in which attribute information and control information corresponding to the application are recorded.
  • USBD / USD which is ATSC 3.0 signaling data, S-TSID, or application information table (AIT: Application) that records attribute information and control information corresponding to each application Execute application control using Information Table).
  • AIT Application
  • the playback control unit (DASH Client) 131 and the application control unit 132 execute processing using data stored in the cache unit 122 of the proxy server 120.
  • the data stored in the cache unit 122 is data received by a middleware (Client Local ATSC Middleware) 110 or data received by the proxy server 120 via a network.
  • middleware Client Local ATSC Middleware
  • the data acquired by the middleware 110 or the proxy server 120 via a broadcast wave or a communication network includes, for example, a DASH-MPD file, a DASH segment file, other general application files, and an SLS that stores signaling data. Service level Signaling) file or the like. These are stored in the cache unit 122 based on the control of the cache control unit 121.
  • the cache control unit 121 acquires request data from the cache unit 122 in response to a request from the reproduction control unit (DASH Client) 131 or the application control unit 132, and the reproduction control unit (DASH Client) 131 or application It is provided to the control unit 132 and used for data reproduction processing such as stream rendering and application execution.
  • the reproduction control unit (DASH Client) 131 and the application control unit 132 request the cache control unit 121 of the proxy server 120 to acquire a segment file, other general application files, and a signaling data file (HTTP) Upon receiving the request, the cache control unit 121 of the proxy server 120 that receives the request acquires data from the cache unit 122. When there is no data in the cache unit 122, an acquisition process via broadcasting or the network is performed.
  • the playback control (DASH Client) 131 and the application control unit 132 acquire signaling data in which content playback, application control information, and the like are recorded. These are acquired by a signaling acquisition unit (SLS Signaling Retriever) 112. For example, various signaling data such as USBD / USD, AIT, S-TSID, and MPD are acquired and used.
  • SLS Signaling Retriever signaling acquisition unit 112.
  • various signaling data such as USBD / USD, AIT, S-TSID, and MPD are acquired and used.
  • the signaling acquisition unit (SLS Signaling Retriever) 112 extracts the signaling data carried by the SLS LCT packet that is broadcast and received via the communication unit (ATSC tuner: ATSC 3.0 PHY / MAC) 111.
  • the signaling data are acquired by the signaling acquisition unit 112 of the middleware 110 and analyzed by the signaling analysis unit (SLS Signaling Parser) 113.
  • the signaling data includes, for example, address information (URL) for acquiring an AV segment necessary for program reproduction, various data files (resources) necessary for application execution, and the like. Performs an acquisition process of address information (broadcast distribution address information) for acquiring necessary segments and resource files.
  • an LCT packet storing a desired file is acquired from the broadcast stream, and the acquired data is expanded in the cache unit 122 of the proxy server 120.
  • the cache control unit 121 of the proxy server 120 confirms the cacheable data capacity of the cache unit 122 during application acquisition and cache processing, and further determines the application size from the signaling data and the data size of each component of the application. And cacheable data is selected and cache processing is executed. This cache processing will be described in detail later.
  • the reception device 30 receives various applications from the transmission device 20 via, for example, broadcast waves, and executes the received applications.
  • a configuration example of an application provided by the transmission device 20 to the reception device 30 will be described with reference to FIG.
  • FIG. 8 shows a configuration example of one application (APP1) 200.
  • the application (APP1) 200 is composed of one or more presentation units (PUs).
  • PUs presentation units
  • One presentation unit is composed of a set of one or a plurality of HTML (HyperText Markup Language) files 211 and a data file 212 presented using the HTML files.
  • HTML HyperText Markup Language
  • one presentation unit is a unit including the following components.
  • (1) One or a plurality of HTML files (2) Image (moving image, still image) files output in accordance with the above HTML, (3) an audio file output in accordance with the HTML, (4) A style sheet storage file that defines the data output style according to the above HTML.
  • one presentation unit (PU) is set by the above components.
  • the application (APP1) 200 is configured by one or a plurality of presentation units (PUs). In the example shown in FIG. 8, the application (APP1) 200 has three presentation units (PU11 (G1 (group 1)) to PU31 (G3 (group 3))).
  • a different group ID (groupId) is set for each presentation unit (PU) in one application.
  • Each of the configuration data (HDML file, data file) of the presentation unit (PU) is set with a group ID as an identifier so that each PU can be identified to which data.
  • a link may be set between presentation units (PU11 (G1) to PU31 (G3)).
  • a link 213a from the HTML file 211 of the presentation unit (PU11 (G1)) to the HTML file of the presentation unit (PU21 (G2)) is set.
  • a link 213b from the HTML file of the presentation unit (PU11 (G1)) to the HTML file of the presentation unit (PU31 (G3)) is set.
  • Two PUs to which a link is set for example, a relationship in which a PU transition is performed in which the execution of a linked presentation unit is started by using some event as a trigger during the execution of the linked presentation unit (PU). It is in.
  • the transition event is not limited to a user operation, and includes various events such as a description of signaling data such as an application information table (AIT), for example, an event based on the passage of time.
  • AIT application information table
  • AIT application information table
  • the control unit 132 executes the application according to the recorded information of the AIT.
  • the AIT includes various application information such as acquisition information (URL, etc.) of a specific application (APP), control codes that define the execution mode of the application, for example, automatic start processing (AUTOSTART), prefetch (prefetch), etc.
  • a control code which is execution mode defining information is also recorded.
  • An application ID that is an identifier for identifying an individual application is set in the application.
  • various information related to the application such as application size information, access information, control information, and the like are recorded together with the application ID. Details of information recorded in signaling data such as AIT will be described later.
  • the application ID is (A) Organization ID (orgId), (B) App body ID (appId), It is configured as concatenated data of these two IDs.
  • the organization ID is an identifier indicating an organization such as a broadcasting station that provides an application or an application creator.
  • the application main body ID is an identifier set in association with each application main body.
  • the organization ID in the first half of the application ID it is possible to check the organization of the broadcasting station that provides the application, the creator of the application, etc., and by referring to the application body ID in the second half of the application ID
  • One application among a plurality of applications provided by one organization can be individually identified.
  • a presentation unit ID that is an identifier for identifying an individual presentation unit (PU) is also set in the presentation unit (PU) that is a component of the application.
  • the presentation unit ID is associated with each file belonging to the presentation unit (PU). (PUID) is recorded.
  • the receiving device 30 refers to the S-TSID that is the signaling data provided by the transmitting device 20 such as a broadcasting station, and which presentation unit (PU) each file provided by the transmitting device 201 belongs to. Can be identified. Note that the data size of each presentation unit (PU) is also recorded in the S-TSID. Details of information recorded in signaling data such as S-TSID will be described later.
  • the presentation unit ID is (A) App body ID (appId), (B) Group ID (groupId), It is configured as data obtained by concatenating these two IDs.
  • the application main body ID is an identifier set in association with the application main body to which the presentation unit belongs. The same value as the “application main body ID” that is a component of the application ID is set.
  • the group ID is an individual identifier for each presentation unit (PU). When a plurality of presentation units (PU) are included in one application, different group IDs are set.
  • FIG. 9 shows the following three applications.
  • Application 1 (APP1)
  • Application 2 (APP2)
  • Application 3 (APP3)
  • the dotted arrows shown in FIG. 9 indicate the link relationship.
  • the link is set between the presentation units (PUs) in each application, and is also set between the applications in the example shown in FIG.
  • the first application to be activated is the application 1 (APP1)
  • the HTML document of one presentation unit (PU11) is the first HTML document to be activated.
  • An HTML document that is first used when an application is executed is referred to as an entry document.
  • the entry document of the application 1 (APP1) is the HTML document of the presentation unit (PU11), that is, the entry document 221 shown in FIG.
  • a link indicated by a dotted arrow from application 1 (APP1) to application 2 (APP2) is used to generate a transition event in a garden such as a screen operation by a user or time passage during the execution of application 1 (APP1). Based on this, it is shown that processing for starting application 2 (APP2) is performed. As described above, there are cases where processing is performed by setting links to a plurality of applications and applying the plurality of applications.
  • Signaling data such as AIT and S-TSID
  • the receiving apparatus 30 Based on the above, it becomes possible to grasp each link relation.
  • the application is executed by the application control unit 130, and the application control unit 130 acquires data (resources) necessary for executing the application from the cache unit 122 and executes the application. If necessary data is not stored in the cache unit 122, an application execution error may occur.
  • the reception device 30 compares the cache size corresponding to the data amount (free capacity) that can be stored in the cache unit 122 with the application size or the presentation unit (PU) size, and determines the presentation unit.
  • Data storage processing (cache processing) for the cache unit 122 is performed in units of (PU) or applications.
  • a cache process in the receiving apparatus 30 that is, a process of storing data in the cache unit 122 in application units or presentation unit (PU) units will be described.
  • FIG. 10 is a diagram for explaining an example of a correspondence relationship between the data size of the application and the presentation unit (PU) and the cache size of the receiving apparatus.
  • the horizontal axis is an axis corresponding to the data size and the cache size. From top to bottom, (A) Application size (B) Cache size of receiving apparatus Each of these size setting examples is shown.
  • the data size of application 1 is S3.
  • the total data size of application 1 (APP1) + application 2 (APP2) is S4.
  • the total data size of application 1 (APP1) to application 3 (APP3) is S5.
  • Application 1 is composed of three presentation units (PU).
  • the data size of the presentation unit (PU11) is S1.
  • the total data size of the presentation unit (PU11) + presentation unit (PU12) is S2.
  • the total data size of the presentation unit (PU11) to the presentation unit (PU13) is S3, which matches the data size of the application 1 (APP1), S3.
  • Minimum size (Minimum) (2) Small size (Small) (3) Medium size (4) Large size (5) Maximum size (Maximum) are examples of cache sizes that can be used by the reception device 30 as various user devices that execute applications provided by the transmission device 20, such as a mobile terminal and a PC.
  • the data size that can be stored (cached) in the large-sized cache, that is, the cache size is not less than S4 and less than S5.
  • the maximum data size (Maximum) cacheable data size, that is, the cache size is S5 or more.
  • the cache target is determined according to each cache size. It is necessary to select Ideally, it is desirable to cache all the application configuration data files of applications 1 to 3, but all three of these applications can be stored only in (5) Maximum size (Maximum) cache. It is.
  • a receiving apparatus having a cache having a minimum size (Minimum) to (4) a large size (Large) needs to select and cache the data to be cached.
  • the cache target selection process of the receiving device of the present disclosure is executed according to the following rules.
  • (Rule 1) If the cache size can store all the applications having the link relationship, all the applications having the link relationship are stored (cushed).
  • (Rule 2) If the cache size cannot store all of the applications in the link relationship, data is stored (cached) in units of applications or presentation units (PU).
  • (Rule 3) The application storage priority for each application follows the link path from the initial execution application.
  • the storage priority of each presentation unit (PU) follows the link path from the presentation unit (PU) having the entry document.
  • the receiving device applies the above rule, compares its own cache size, application size, and each presentation unit (PU) size, and selects a cache target.
  • the cache target data corresponding to the five cache sizes shown in FIG. 10 has the following settings.
  • Minimum size (Minimum) Presentation unit (PU11)
  • Small size (Small) Presentation unit (PU11) + Presentation unit (PU12)
  • Medium size (Medium) Application (APP1)
  • Large size (Large) Application (APP1) + Application (APP2)
  • Maximum size (Maximum) Application (APP1) + Application (APP2) + Application (APP3)
  • the receiving device refers to AIT and S-TSID that are signaling data transmitted by the transmitting device 20 in the cache target selection processing.
  • AIT and S-TSID that are signaling data transmitted by the transmitting device 20 in the cache target selection processing.
  • information for each application and information for each presentation unit (PU) are recorded.
  • the size information and link information of each application and each PU are recorded in association with the application ID and presentation unit ID (PUID) described above with reference to FIG.
  • FIG. 11 shows an example of cache target selection processing in the following five cache sizes described with reference to FIG. (1) Minimum size (Minimum) (2) Small size (Small) (3) Medium size (4) Large size (5) Maximum size (Maximum)
  • a receiving apparatus having an allowable cache size of the minimum size (Minimum) selects a presentation unit (PU11) having an entry document as the highest priority cache target PU.
  • the presentation unit (PU11) having the entry document can be determined based on the signaling data (AIT, S-TSID).
  • a file having the PUID of the presentation unit (PU11) having the entry document is selected as a cache target, and cache processing is executed.
  • the group ID of each file is recorded in units of files constituting the presentation unit (PU). That is, the group ID set as the second half ID constituting the presentation unit ID (PUID) described above with reference to FIG. 8 is recorded in association with each file.
  • the receiving apparatus having an allowable cache size of the minimum size (Minimum) has the same group ID as the group ID (groupId1) of the ID (PUID) of the presentation unit (PU11) having the entry document in the signaling data (S-TSID). Select a file recorded in the file list for caching. Details of the data recording configuration of the signaling data will be described later.
  • a receiving apparatus having an allowable cache size of a small size selects a presentation unit (PU11) having an entry document as the highest priority cache target PU, and further, a presentation unit having this entry document ( The second presentation unit (PU12) designated as the link destination from PU11) can be the cache target.
  • the S-TSID as the signaling data records the group ID of each file in units of files that make up the presentation unit (PU).
  • a receiving device having an allowable cache size of small size (Small)
  • Group ID (groupId2) of ID (PUID) of linked presentation unit (PU12) A file in which a group ID that matches one of these two group IDs (groupId1 or groupId2) is recorded is selected as a cache target from a file list of signaling data (S-TSID).
  • a receiving apparatus having an allowable cache size of medium size can cache all presentation units (PU11 to PU13) constituting the initial execution application (APP1).
  • a presentation unit ID (PUID) is set in the presentation unit (PU), and the first half of this ID is configured by the application main body ID, and the presentation unit The setting to which the application to which (PU) belongs can be identified.
  • the receiving apparatus determines that the application body ID set in the first half of the presentation unit ID (PUID) is the PU of the entry document from the list of presentation units (PU) recorded in the S-TSID as signaling data.
  • a presentation unit having the same value as the application main body ID may be selected as a cache target.
  • a receiving apparatus having an allowable cache size of large size targets the initial execution application (APP1) and another application (APP2) set as a link destination of the application (APP1) as a cache target. be able to.
  • a receiving apparatus having an allowable cache size of a large size has a configuration of an application (APP1) by a process similar to that of “(3) receiving apparatus having an allowable cache size of medium (Medium)”. Acquire all files, and for another application (APP2) set as the link destination of the application (APP1), search for a file belonging to the application 2 (APP2) using the application body ID (appId2) as a search key To be cached.
  • App body ID appId1
  • App body ID appId2
  • Any of these set presentation units (PU) that is, files belonging to PU11 to PU13 and PU21 to PU23 are selected as cache targets.
  • the receiving device having an allowable cache size of the maximum size (Maximum) includes an initial execution application (APP1), another application (APP2) set as a link destination of the application (APP1), and its link
  • the other application (APP3) set as the destination can be all cached.
  • a receiving device having an allowable cache size of the maximum size (Maximum) is configured so that the application (APP1) and the application (APP1) are processed in the same manner as the above-described “(4) receiving device having an allowable cache size of Large”. All the configuration files of the application (APP2) are acquired, and for another application (APP3) set as the link destination of the application (APP2), the application body ID (appId3) is used as a search key for the application 3 (APP3). ) To search for files belonging to.
  • App body ID appId1
  • App body ID appId2
  • App body ID appId3
  • Any of these set presentation units (PU) that is, files belonging to PU11 to PU13, PU21 to 23, and PU31 to 33 are selected as cache targets.
  • the transmission apparatus 20 provides the reception apparatus 30 with various signaling data in which the transmission apparatus 20 transmits the application to the reception apparatus 30 and records the access information of the transmission application, the attribute information of the application, and the control information.
  • Examples of signaling data related to applications provided by the transmission device 20 to the reception device 30 include the following data.
  • USBD / USD User Service Bundle Description / User Service Description
  • S-TSID Service based Transport Session Description
  • AIT Application Information Table
  • the USD is composed of information of a predetermined service unit such as a broadcasting station or a program, and access information (URL, etc.) for receiving the service, codec information, reproduction timing information, etc. in the receiving device. It consists of information necessary to use the service.
  • USBD is a bundle of USD, and both USD and USBD are signaling data in which the same control information is stored. .
  • S-TSID is additional information for each service unit, and additional information not recorded in USD is recorded.
  • the ROUTE protocol is a protocol based on FLUTE.
  • a metadata file describing transfer control parameters in FLUTE is called FDT (File Delivery Table), and a metadata file describing transfer control parameters in ROUTE is called S-TSID (Service based Transport Session Description).
  • S-TSID is a superset of FDT and includes FDT.
  • AIT is application-specific signaling data set corresponding to one or a plurality of applications, and records application acquisition information (URL), control information applied to application execution, and the like.
  • USBD / USD (2) AIT (3) S-TSID It is a figure explaining these partial data and the application acquisition process using these data.
  • signaling data such as USBD / USD, AIT, and S-TSID is repeatedly transmitted from the transmitting device 20 as needed, and the receiving device acquires these signaling data in advance before acquiring the application. Further, the access information of the application is acquired with reference to the acquired signaling data to acquire the application.
  • the application can be acquired via a broadcast wave or a communication network such as the Internet.
  • a base pattern corresponding to a broadcast wave which is access information configuration data for acquiring an application when the application is provided via a broadcast wave
  • USBD / USD shown in FIG. 12, when an application is transmitted via a broadcast wave, a base pattern is recorded in a base pattern recording area (USD / deliveryMethod / atsc: BcAppService / basePattern) corresponding to the broadcast wave.
  • USD / deliveryMethod / atsc: BcAppService / basePattern a base pattern recording area corresponding to the communication network.
  • the receiving apparatus transmits an application via a broadcast wave, or a communication network such as the Internet, or a broadcast wave and the Internet. It can be determined whether the data is transmitted via both of the communication networks.
  • a URI for acquiring a specific application is recorded in the AIT that is signaling data corresponding to the application.
  • the receiving device first refers to the base pattern recorded in the USBD (or USD) in step S11, and the application is distributed using either a broadcast wave or a communication network.
  • the access information (application acquisition address) of the application is generated by combining the URI recorded in the AIT, the base pattern, and the URI.
  • step S21 the generated access information (application acquisition address) is applied to acquire the application via the communication network.
  • step S31 when it is confirmed that the application is distributed via the broadcast wave, in step S31, another signaling data S-TSID is acquired,
  • the file unit information of a file having location information (RS / LS / ScFlw / EFDT / @ content-loc) that matches the application location (appLocation (URI)) recorded in the AIT is searched.
  • S-TSID information for each file constituting the presentation unit (PU) is recorded. Further, a TOI (Transport Object Identifier) recorded in the file unit information of the S-TSID is acquired.
  • TOI Transport Object Identifier
  • the TOI Transport Object Identifier
  • the TOI is a packet identifier recorded in a packet header of an LCT packet storing an application transmitted from the transmission device 20.
  • a TOI as an identifier corresponding to the payload of the packet is recorded in the packet header of the LCT packet.
  • step S32 the receiving apparatus selects and obtains an LCT packet storing a file included in the target application from LCT packets transmitted by broadcast waves based on the TOI recorded in the S-TSID.
  • FIG. 12A a base pattern as broadcast wave or communication network compatible application access information is recorded in USBD / USD.
  • USBD / USD A specific example of USBD / USD recording data indicating that an application is transmitted as NRT content via a broadcast wave will be described with reference to FIGS.
  • FIG. 13 (1) shows a setting that defines an NRT application transmission service via a broadcast wave as one of the NRT services transmitted via the broadcast wave.
  • an NRT application transmission service definition area 231 via a broadcast wave is newly set in a delivery method (deliveryMethod) in USBD / USD.
  • deliveryMethod deliveryMethod
  • FIG. 13 (2) shows a base pattern definition of an NRT application transmission service via a broadcast wave newly in an application transmission service definition area (atsc: broadcastAppService) defined in a delivery method (deliveryMethod) in USBD / USD.
  • the area 232 is set.
  • FIG. 14 (3) does not record the base pattern itself, but the service type, that is, the service provision mode is a linear type service that is a service such as distribution of a live program, or non-real-time including application distribution.
  • NRT A setting for recording a flag (0, 1) that can be identified as a content distribution service.
  • the flag recording area 233 is provided in an application transmission service definition area (atsc: broadcastAppService) defined in a delivery method (deliveryMethod) in USBD / USD.
  • the receiving device can confirm whether or not the application distribution by the broadcast service is executed by referring to the recorded data (1) to (3) shown in FIGS. 13 and 14, for example.
  • AIT application information table
  • S-TSID signaling data
  • FIG. 15 is a diagram illustrating an example of recorded data of an AIT (Application Information Table).
  • An AIT shown in FIG. 15 is an example of an AIT in which information corresponding to the three applications (APP1 to APP3) described above with reference to FIGS. 9 and 10 is recorded.
  • the AIT can be set to record information of only one application, but can also be set to record information of a plurality of related applications collectively.
  • Recording area 241 for information related to application 1 (APP1)
  • Recording area 242 for information related to application 2 (APP2)
  • Recording area 243 for information related to application 3 (APP3)
  • Application ID 251 In each of the application information recording areas 241 to 243, Application ID 251, Application access information (appLocation (URI)) 252, Application size 253, Link destination application information 254, These pieces of information are recorded.
  • Application access information AppLocation (URI)
  • Application size In each of the application information recording areas 241 to 243, Application ID 251, Application access information (appLocation (URI)) 252, Application size 253, Link destination application information 254, These pieces of information are recorded.
  • URI Application access information
  • the application ID 251 is the application identifier described above with reference to FIG. That is, the application ID includes an organization ID (orgId) and an application main body ID (appId).
  • orgId organization ID
  • appId application main body ID
  • Application access information (appLocation (URI)) 252 is a URI used for acquiring an application. As described above with reference to FIG. 12, the access information can be generated together with the base pattern recorded in the USBD.
  • the application size 253 is the total data size of all the configuration data included in one application. For example, in the case of application 1 (APP1) shown in FIG. 9, the total size of the files constituting the three presentation units (PU11 to PU13) is recorded. In the example shown in FIG. 10, the size of the application 1 (APP1) is S1, and this S1 is recorded as the application size 253.
  • the link destination application information 254 is information related to the link between applications described above with reference to FIG. Specifically, the application ID of the link destination application is recorded. If there is no link destination application, it is not recorded.
  • the S-TSID is a metadata file describing transfer control parameters for each service, and includes an FDT (file delivery table) that is information for each file of a large number of files provided in the service. Signaling data.
  • FDT file delivery table
  • FIGS. 9 and 10 shows only a part of the S-TSID in which information corresponding to the three applications (APP1 to APP3) described above with reference to FIGS. 9 and 10 is recorded.
  • FIG. 16 information recording areas corresponding to two presentation units (PU11, PU12) belonging to application 1 (APP1), that is, Presentation unit (PU11) correspondence information 262, Presentation unit (PU12) correspondence information 263, Only these information recording areas are extracted and shown.
  • Information of PU13, PU21 to PU23, and PU31 to PU33 is recorded below the information recording area corresponding to the presentation units (PU11, PU12) shown in FIG.
  • the PUID of the link source presentation unit (PU) and the PUID of the link destination presentation unit (PU) are recorded.
  • the PUID makes it possible to individually identify the application body ID (appId) of the application to which the presentation unit (PU) belongs and the presentation unit in the same application. It is configured by a group ID (groupId).
  • This PU is a PU having an entry document.
  • the first file (File) having the entry document is a file corresponding to the HTML document as the entry document.
  • the presentation unit (PU11) size information is recorded in the file unit information of the first file.
  • the presentation unit (PU11) correspondence information 262 information in units of files belonging to the presentation unit (PU11) is recorded.
  • the following information is recorded in the first file unit information.
  • TOI information as file access information, Group information 271 of the presentation unit (PU11) configuration file, Presentation unit (PU11) size information 272,
  • TOI information as file access information
  • Group information of presentation unit (PU11) configuration file These pieces of information are recorded.
  • the presentation unit (PU12) correspondence information 263 records information in units of files belonging to the presentation unit (PU12). The following information is recorded in the first file unit information.
  • TOI information as file access information, Group information 273 of the presentation unit (PU12) configuration file, Presentation unit (PU12) size information 274,
  • the S-TSID records the next usage of each file constituting the presentation unit (PU), and the presentation unit ID and the presentation unit size information are included in the file unit information.
  • FIG. 17 shows an example of data recording in an FDT (file delivery table), which is a data recording area for each S-TSID file.
  • FDT file delivery table
  • A Content location as file access information (@ Content-Location)
  • B TOI (Transport Object Identifier) which is a packet identifier recorded in the packet header of the LCT packet transmitted from the transmission device
  • C Content length, type
  • D Presentation unit ID
  • E Presentation unit
  • the presentation unit (PU) link information 261 is recorded in the S-TSID.
  • a specific recording example will be described with reference to FIG.
  • the presentation unit (PU) link information 261 is: The following recording areas in the S-TSID: RS / LS / ScFlw / ContentInfo Recorded below.
  • FIG. 18 is a diagram illustrating an example of inter-PU link information recorded in content information (ContentInfo).
  • ContentInfo content information
  • the link information between presentation units (PU) is recorded with the setting as shown in the data recording area 282 of FIG.
  • Link source presentation unit ID (PUID) Linked presentation unit ID (PUID)
  • PID link source presentation unit ID
  • PUID Linked presentation unit ID
  • an area for recording these two PUIDs is set.
  • USBD / USD AIT S-TSIS are application acquisition processing to which these signal link data are applied, and cache target data selection processing.
  • the processing according to the flow shown in FIG. 19 is processing executed in the data processing unit of the receiving device 30.
  • it is executed according to a program that records the processing sequence shown in FIG.
  • the data processing unit that executes the processing sequence illustrated in FIG. 19 is, for example, a data processing unit that performs functions such as the signaling analysis unit 113 and the cache control unit in the reception device 30 illustrated in FIG.
  • the processing of each step will be described sequentially.
  • step S51 the receiving apparatus acquires AIT (application information table) from SLS (service level signaling) transmitted from the transmitting apparatus, and acquires information on the distribution application.
  • AIT application information table
  • the AIT application information table
  • information regarding the distribution application is acquired. Specifically, for example, an application ID, application size information, inter-application link information, and the like are acquired.
  • step S52 the receiving apparatus compares the description of the delivery method (deliveryMethod) of USD (user service description) which is signaling data transmitted from the transmitting apparatus with the description of the application location (ApplicationLocation) of AIT. Based on this, the transmission path of the application (broadcast wave / net communication) is confirmed.
  • deliveryMethod delivery method
  • ApplicationLocation application location
  • Step S53 the receiving apparatus caches data based on the application size information acquired from the AIT that is signaling data transmitted from the transmitting apparatus, the inter-application link information, and the cache allowable size of the receiving apparatus. Determine the range. For example, according to the processing described above with reference to FIGS. 10 to 18, the cacheable application configuration data range is confirmed and the cache target data is determined.
  • step S54 the receiving apparatus determines whether one application unit can be cached. That is, it is determined whether or not the cache size described with reference to FIGS. 10 and 11 corresponds to a medium size (Medium) to a maximum size (Maximum).
  • step S54 If it is determined in step S54 that one application unit can be cached, the process proceeds to step S55. On the other hand, if it is determined in step S54 that one application unit cannot be cached, the process proceeds to step S56.
  • Step S55 If it is determined in step S54 that one application unit can be cached, in step S55, the receiving device is based on the application size information described in the AIT, the inter-application link information, and the cache allowable size of the receiving device. Acquire the cacheable range application determined in the above, and execute the cache processing.
  • This processing corresponds to the processing in the case where the cache size described with reference to FIGS. 10 and 11 corresponds to the medium size (Medium) to the maximum size (Maximum).
  • Step S56 On the other hand, if it is determined in step S54 that one application unit cannot be cached, the receiving apparatus, in step S56, the presentation unit (PU) size described in the EFDT / FILE element of the S-TSID, Based on the allowable cache size of the receiving apparatus, the presentation unit within the determined cacheable range is acquired, and the cache processing is executed.
  • the presentation unit (PU) size described in the EFDT / FILE element of the S-TSID Based on the allowable cache size of the receiving apparatus, the presentation unit within the determined cacheable range is acquired, and the cache processing is executed.
  • This processing corresponds to the processing in the case where the cache size described with reference to FIGS. 10 and 11 corresponds to the minimum size (Minimum) to the small size (Small).
  • the application size and the presentation unit (PU) size will also be described as the settings shown in FIGS. That is, the cache target data corresponding to the above five cache sizes has the following settings.
  • Minimum size (Minimum) Presentation unit (PU11)
  • Small size (Small) Presentation unit (PU11) + Presentation unit (PU12)
  • Medium size (Medium) Application (APP1)
  • Large size (Large) Application (APP1) + Application (APP2)
  • Maximum size (Maximum) Application (APP1) + Application (APP2) + Application (APP3)
  • FIG. 20 is a diagram for explaining data to be cached (stored) when the data storage allowable cache size of the receiving apparatus is the minimum size (Minimum).
  • the receiving device can store only one presentation unit (PU).
  • the processing executed by the receiving apparatus is a process of acquiring a presentation unit (PU11) composed of an HTML document (entry document 221) and a resource file that are read first after the application (APP1) is started, and displaying the cached unit. Obviously, a presentation unit (PU11) composed of an HTML document (entry document 221) and a resource file that are read first after the application (APP1) is started, and displaying the cached unit. Obviously, a presentation unit (PU11) composed of an HTML document (entry document 221) and a resource file that are read first after the application (APP1) is started, and displaying the cached unit. Become.
  • a presentation unit composed of an HTML document (entry document 221) and a resource file that are read first after the application (APP1) is started
  • FIG. 21 is a flowchart illustrating a processing sequence from when the receiving device acquires an application via a broadcast wave, performs a cache process, and executes the cache process. Further, FIG. 22 shows signaling data used in the processing of each step of the flowchart shown in FIG. (1) AIT (2) S-TSID These two signaling data.
  • each step number (S111 to S116) shown in FIG. 21 and the process of the same step number (S111 to S116) shown in FIG. 22 are the same process.
  • a recording area of signaling data (AIT, S-TSID) to be referred to in processing of each step and each step number are shown in association with each other.
  • AIT, S-TSID signaling data
  • Step S111 First, in step S111, the receiving apparatus acquires an AIT (application information table) and S-TSID from SLS (service level signaling) transmitted from the transmitting apparatus.
  • AIT application information table
  • S-TSID service level signaling
  • Step S112 the receiving apparatus acquires and confirms information related to the distribution application from the AIT. For example, the following processing is performed. (1) The URL of the entry document is acquired from the application location (applicationLocation). (2) It is confirmed that the control code is set to a code (AUTOSTART, Prefetch, etc.) that requires cache processing. (3) Obtain an application ID. (4) Acquire the application size.
  • the acquired application size is compared with the cacheable cache size of the receiving apparatus.
  • the cache size minimum (Minimum), which is smaller than the application size, and it is determined that the entire application cannot be cached.
  • Step S113 the reception apparatus acquires entry document acquisition destination information from the S-TSID. Specifically, as shown in step S113 of FIG. 22, the content location information (RS / LS / ScFlw / EFDT / content-location) recorded in the file unit information recorded in the S-TSID, and the AIT A file (FILE) matching the application location (applicationLocation) is searched, and the acquisition destination information is acquired.
  • the content location information RS / LS / ScFlw / EFDT / content-location
  • the S-TSID records information in units of files constituting the presentation unit (PU).
  • the receiving apparatus searches for a file (FILE) that matches the application location (applicationLocation) of the AIT, and acquires a TOI (Transport Object Identifier) recorded in the file unit information of the S-TSID as the acquisition destination information.
  • FILE File
  • applicationLocation applicationLocation
  • TOI Transport Object Identifier
  • the TOI Transport Object Identifier
  • the TOI is a packet identifier recorded in a packet header of an LCT packet storing an application transmitted from the transmission device 20.
  • a TOI as an identifier corresponding to the payload of the packet is recorded in the packet header of the LCT packet.
  • the receiving apparatus can select and acquire an LCT packet storing a file included in a target application from LCT packets transmitted by broadcast waves based on the TOI recorded in the S-TSID.
  • step S114 the receiving apparatus obtains the presentation unit (PU) including the entry document from the S-TSID and the ID of the presentation unit (PU) obtained by following the link information recorded in the S-TSID.
  • PID application main body ID + group ID
  • size information PUSize
  • the presentation unit ID includes an application main body ID (appId) and a group ID (groupId).
  • the application main body ID (appId) is an application main body ID (appId) that is configuration data of an application ID (organization ID (orgId) + application main body ID (appId)) set to the application to which the presentation unit (PU) to which the file belongs. ) Is the same value.
  • the receiving apparatus acquires link information recorded in the S-TSID.
  • PU presentation unit
  • PUSize size information
  • step S115 the receiving apparatus compares the cache size of the receiving apparatus, that is, the available cache size with the data size of each presentation unit (PU), and selects a presentation unit to be cached. .
  • the highest priority cache target PU is a presentation unit (for example, PU11) having an entry document.
  • the next priority cache target PU is the link destination PU of the PU 11 having the entry document, for example, the PU 12. Further, the link destination PU 13 of the PU 12 is selected as the next cache target PU, and the cache target PU is sequentially selected following the link. When the cache size is exceeded, the selection of the cache target PU is completed.
  • the cache target PUs are sequentially selected following the link.
  • PU11 size ⁇ cache size ⁇ (PU11 + PU12) size
  • PU11 size ⁇ cache size ⁇ (PU11 + PU12) size
  • Step S116 the receiving apparatus acquires a file having the same PUID as the PUID of the presentation unit (PU) to be cached determined in step S115, executes a cache process, and outputs an entry document ( indicate.
  • a file having the same PUID (PU11) as the PUID (PU11) of the presentation unit (PU) selected as the cache target is selected from the information of the file unit recorded in the S-TSID. Then, based on the TOI recorded in the file unit information, the packet storing the corresponding file is selected and acquired from the broadcast wave. Processing to store (cache) the selected and acquired file in the cache unit is executed, and then output (display) processing from the entry document is started.
  • FIG. 23 is a diagram for explaining data to be cached (stored) when the data storage allowable cache size of the receiving apparatus is a small size (Small).
  • the receiving device can store two presentation units (PU11 and PU12).
  • the processing executed by the receiving apparatus includes a presentation unit (PU11) composed of an HTML document (entry document 221) and a resource file that are read first after the application (APP1) is started, and a link between the presentation unit (PU11). This is a process of acquiring the presentation unit (PU12) set as the destination, caching it, and displaying it.
  • a presentation unit composed of an HTML document (entry document 221) and a resource file that are read first after the application (APP1) is started
  • the plurality of link destination PUs are acquired.
  • FIG. 24 shows a flowchart for explaining a processing sequence from when the receiving apparatus acquires an application via a broadcast wave, performs cache processing, and executes it. Further, FIG. 25 shows signaling data used in the processing of each step of the flowchart shown in FIG. (1) AIT (2) S-TSID These two signaling data.
  • each step number (S121 to S126) shown in FIG. 24 and the process of the same step number (S121 to S126) shown in FIG. 25 are the same process.
  • a recording area of signaling data (AIT, S-TSID) to be referred to in processing of each step and each step number are shown in association with each other. With reference to FIGS. 24 and 25, the processing of each step will be described sequentially.
  • Step S121 First, in step S121, the receiving apparatus acquires an AIT (application information table) and S-TSID from SLS (service level signaling) transmitted from the transmitting apparatus.
  • AIT application information table
  • S-TSID service level signaling
  • step S122 the receiving apparatus acquires and confirms information related to the distribution application from the AIT. For example, the following processing is performed. (1) The URL of the entry document is acquired from the application location (applicationLocation). (2) It is confirmed that the control code is set to a code (AUTOSTART, Prefetch, etc.) that requires cache processing. (3) Obtain an application ID. (4) Acquire the application size.
  • the acquired application size is compared with the cacheable cache size of the receiving apparatus.
  • the cache size is small (Small), which is smaller than the application size, and it is determined that the entire application cannot be cached.
  • Step S123 the receiving device acquires entry document acquisition destination information from the S-TSID. Specifically, as shown in step S123 of FIG. 25, the content location information (RS / LS / ScFlw / EFDT / content-location) recorded in the file unit information recorded in the S-TSID, and the AIT A file (FILE) matching the application location (applicationLocation) is searched, and the acquisition destination information is acquired.
  • the content location information (RS / LS / ScFlw / EFDT / content-location) recorded in the file unit information recorded in the S-TSID
  • the AIT A file (FILE) matching the application location (applicationLocation) is searched, and the acquisition destination information is acquired.
  • step S124 the receiving apparatus obtains the presentation unit (PU) including the entry document from the S-TSID and the ID of the presentation unit (PU) obtained by following the link information recorded in the S-TSID.
  • PID application main body ID + group ID
  • size information PUSize
  • the presentation unit ID is composed of an application main body ID (appId) and a group ID (groupId).
  • the application main body ID (appId) is an application main body ID (appId) that is configuration data of an application ID (organization ID (orgId) + application main body ID (appId)) set to the application to which the presentation unit (PU) to which the file belongs. ) Is the same value.
  • the reception apparatus acquires link information recorded in the S-TSID.
  • step S125 the receiving apparatus compares the cache size of the receiving apparatus, that is, the available cache size with the data size of each presentation unit (PU), and selects a presentation unit to be cached. .
  • the highest priority cache target PU is a presentation unit (for example, PU11) having an entry document.
  • the next priority cache target PU is the link destination PU of the PU 11 having the entry document, for example, the PU 12. Further, the link destination PU 13 of the PU 12 is selected as the next cache target PU, and the cache target PU is sequentially selected following the link. When the cache size is exceeded, the selection of the cache target PU is completed.
  • the cache target PUs are sequentially selected following the link.
  • (PU11 + PU12) size ⁇ cache size ⁇ (PU11 + PU12 + PU13) size is satisfied, and PU11 and PU12 are selected as cache target PUs.
  • Step S126 the receiving apparatus acquires a file having the same PUID as the PUID of the presentation unit (PU) to be cached determined in step S125, executes a cache process, and outputs an entry document ( indicate.
  • the receiving apparatus selects a file having the same PUID as the PUID of the cache target PU from the information of the file unit recorded in the S-TSID, and sets the file unit information.
  • the packet storing the corresponding file is selected and acquired from the broadcast wave based on the TOI recorded in. Processing to store (cache) the selected and acquired file in the cache unit is executed, and then output (display) processing from the entry document is started.
  • FIG. 26 is a diagram for explaining data to be cached (stored) when the data storage allowable cache size of the receiving apparatus is a medium size (Medium).
  • the receiving apparatus can store one application (APP1).
  • the processing executed by the receiving device is to execute all the configuration files of the application (APP1) to which the presentation unit (PU11) composed of the HTML document (entry document 221) and the resource file read first after the application (APP1) starts. Acquire, cache, and display.
  • FIG. 27 is a flowchart for explaining a processing sequence from when the receiving device acquires an application via a broadcast wave, performs a cache process, and executes the cache process. Further, FIG. 28 shows signaling data used in the processing of each step of the flowchart shown in FIG. (1) AIT (2) S-TSID These two signaling data.
  • each step number (S131 to S135) shown in FIG. 27 and the process of the same step number (S131 to S135) shown in FIG. 28 are the same process.
  • a recording area of signaling data (AIT, S-TSID) to be referred to in processing of each step and each step number are shown in association with each other.
  • AIT, S-TSID signaling data
  • Step S131 First, in step S131, the receiving apparatus acquires an AIT (application information table) and S-TSID from SLS (service level signaling) transmitted from the transmitting apparatus.
  • AIT application information table
  • S-TSID service level signaling
  • Step S132 the receiving apparatus acquires and confirms information related to the distribution application from the AIT. For example, the following processing is performed. (1) The URL of the entry document is acquired from the application location (applicationLocation). (2) It is confirmed that the control code is set to a code (AUTOSTART, Prefetch, etc.) that requires cache processing. (3) Obtain an application ID. (4) Acquire the application size. (5) Acquire a link destination application. (6) The link destination application size is acquired.
  • the acquired application size is compared with the cacheable cache size of the receiving apparatus.
  • the cache size medium, which is larger than the application size of the application (APP1), and the entire application (APP1) can be cached.
  • the data size obtained by adding the link destination application size to the application size is compared with the cache size of the receiving apparatus that can be cached.
  • the cache size is medium, and the cache size is smaller than the total application size of the two applications (APP1, APP2), and it is determined that the entire two applications (APP1, APP2) cannot be cached. To do. That is, it decides to execute the cache processing of one application (APP1).
  • Step S133 the receiving device acquires entry document acquisition destination information from the S-TSID. Specifically, as shown in step S133 of FIG. 28, the content location information (RS / LS / ScFlw / EFDT / content-location) recorded in the file unit information recorded in the S-TSID, and the AIT A file (FILE) matching the application location (applicationLocation) is searched, and the acquisition destination information is acquired.
  • the content location information (RS / LS / ScFlw / EFDT / content-location) recorded in the file unit information recorded in the S-TSID
  • the AIT A file (FILE) matching the application location (applicationLocation) is searched, and the acquisition destination information is acquired.
  • step S134 the receiving apparatus acquires an application body ID (appId) and a group ID (groupId) from the presentation unit ID (PUID) described in the group (Group) element of the entry document.
  • the presentation unit ID includes an application main body ID (appId) and a group ID (groupId).
  • the application main body ID (appId) is an application main body ID (appId) that is configuration data of an application ID (organization ID (orgId) + application main body ID (appId)) set to the application to which the presentation unit (PU) to which the file belongs. ) Is the same value.
  • step S135 the receiving apparatus acquires a file having the same application body ID (appId) as the application body ID (appId) in the PUID (application body ID (appId) + group ID (groupId)) of the entry document. Then, cache processing is executed and output (displayed).
  • a file having the same application main body ID (appId) as the application main body ID (appId) constituting the PUID of the entry document is obtained from the file unit information recorded in the S-TSID.
  • the cache process is executed and output (displayed).
  • FIG. 29 is a diagram for explaining data to be cached (stored) when the data storage allowable cache size of the receiving apparatus is a large size (Large).
  • the receiving apparatus can store two applications (APP1, APP2).
  • the processing executed by the receiving apparatus includes the configuration file of the application (APP1) to which the presentation unit (PU11) that is composed of the HTML document (entry document 221) and the resource file that are read first after the application (APP1) is started, and The processing is to obtain all the configuration files of the application (APP2), which is the link destination application of the application (APP1), and cache and display it.
  • FIG. 30 is a flowchart illustrating a processing sequence from when the receiving device acquires an application via a broadcast wave, performs a cache process, and executes the cache process. Further, FIG. 31 shows signaling data used in the processing of each step of the flowchart shown in FIG. (1) AIT (2) S-TSID These two signaling data.
  • each step number (S141 to S145) shown in FIG. 30 and the process of the same step number (S141 to S145) shown in FIG. 31 are the same process.
  • a recording area of signaling data (AIT, S-TSID) to be referred to in processing of each step and each step number are shown in association with each other.
  • AIT, S-TSID signaling data
  • Step S141 First, in step S141, the receiving apparatus acquires an AIT (application information table) and S-TSID from SLS (service level signaling) transmitted from the transmitting apparatus.
  • AIT application information table
  • S-TSID service level signaling
  • Step S142 the receiving apparatus acquires and confirms information related to the distribution application from the AIT. For example, the following processing is performed. (1) The URL of the entry document is acquired from the application location (applicationLocation). (2) It is confirmed that the control code is set to a code (AUTOSTART, Prefetch, etc.) that requires cache processing. (3) Obtain an application ID. (4) Acquire the application size. (5) Acquire a link destination application. (6) The link destination application size is acquired.
  • the acquired application size is compared with the cacheable cache size of the receiving apparatus.
  • the cache size Large, which is larger than the application size of the application (APP1), and that the entire application (APP1) can be cached.
  • the data size obtained by adding the link destination application size to the application size is compared with the cache size of the receiving apparatus that can be cached.
  • the cache size is large, and this cache size is larger than the total application size of the two applications (APP1, APP2), and it is determined that the entire two applications (APP1, APP2) can be cached. To do.
  • the size of the link destination application (APP3) of the link destination application (APP2) is acquired, and the total data size of the three applications is compared with the cache size.
  • the cache size is smaller than the total data size of the three applications, and it is determined that all three applications cannot be stored (cached). As a result, it decides to execute the cache processing of the two applications (APP1, APP2).
  • step S143 the receiving apparatus acquires the acquisition destination information of the entry document of the initial execution application (APP1) from the S-TSID. Specifically, as shown in step S143 of FIG. 31, the content location information (RS / LS / ScFlw / EFDT / content-location) recorded in the file unit information recorded in the S-TSID, and the AIT A file (FILE) matching the application location (applicationLocation) is searched, and the acquisition destination information is acquired. In this example, a file (FILE) that matches two application locations (applicationLocation) recorded in the AIT is searched, and the acquisition destination information is acquired.
  • a file (FILE) that matches two application locations (applicationLocation) recorded in the AIT is searched, and the acquisition destination information is acquired.
  • step S144 the receiving apparatus, from the presentation unit ID (PUID) described in the group (Group) element of the entry document of each of the two applications, the application body ID (appId) and the group ID (groupId). To get.
  • PID presentation unit ID
  • group group element of the entry document of each of the two applications
  • appId application body ID
  • groupId group ID
  • the presentation unit ID includes an application main body ID (appId) and a group ID (groupId).
  • the application main body ID (appId) is an application main body ID (appId) that is configuration data of an application ID (organization ID (orgId) + application main body ID (appId)) set to the application to which the presentation unit (PU) to which the file belongs. ) Is the same value.
  • Step S145 the receiving apparatus acquires a file having the same application body ID (appId) as the application body ID (appId) in the PUID (application body ID (appId) + group ID (groupId)) of the entry document. Then, the cache process is executed.
  • a file having two application IDs (appId1, appId2) is acquired, cache processing is executed, and execution of the application is started using the entry document of application 1 (APP1).
  • step S145 of FIG. 31 the same application main body ID (appId1) as the application main body ID (appId1, appId2) constituting the PUID (PUId11, PUId21) of the entry document is obtained from the information in file units recorded in the S-TSID. , AppId2) is acquired, cache processing is executed, and output (display) is performed.
  • the application is executed using all the configuration files of all the presentation units (PU11, PU12, PU13) belonging to the application (APP1), and further all the presentation units (PU21, PU22, PU, belonging to the application (APP2)). It is possible to execute an application using all the configuration files of the PU 23). That is, it is possible to reproduce data in a complete form in units of applications and presentation units. That is, application execution processing with a higher degree of completion is realized.
  • FIG. 32 is a diagram for explaining data to be cached (stored) when the data storage allowable cache size of the receiving apparatus is the maximum size (Maximum).
  • the receiving apparatus can store all three applications (APP1, APP2, APP3) for which the link relationship is set.
  • the processing executed by the receiving apparatus includes the configuration file of the application (APP1) to which the presentation unit (PU11) that is composed of the HTML document (entry document 221) and the resource file that are read first after the application (APP1) is started, and
  • the application (APP2) which is the link destination application of the application (APP1)
  • all the configuration files of the application (APP3) which is the link destination application of the application (APP2), are acquired, cached and displayed.
  • FIG. 33 shows a flowchart for explaining a processing sequence from when the receiving apparatus acquires an application via a broadcast wave, performs a cache process, and executes it. Further, FIG. 34 shows signaling data used in the processing of each step of the flowchart shown in FIG. (1) AIT (2) S-TSID These two signaling data.
  • each step number (S151 to S155) shown in FIG. 33 and the processing of the same step number (S151 to S155) shown in FIG. 34 are the same processing.
  • a recording area of signaling data (AIT, S-TSID) to be referred to in processing of each step and each step number are shown in association with each other. The processing of each step will be described sequentially with reference to FIG. 33 and FIG.
  • Step S151 First, in step S151, the receiving apparatus acquires an AIT (application information table) and S-TSID from SLS (service level signaling) transmitted from the transmitting apparatus.
  • AIT application information table
  • S-TSID service level signaling
  • Step S152 the receiving apparatus acquires and confirms information related to the distribution application from the AIT. For example, the following processing is performed. (1) The URL of the entry document is acquired from the application location (applicationLocation). (2) It is confirmed that the control code is set to a code (AUTOSTART, Prefetch, etc.) that requires cache processing. (3) Obtain an application ID. (4) Acquire the application size. (5) Acquire a link destination application. (6) The link destination application size is acquired.
  • the acquired application size is compared with the cacheable cache size of the receiving apparatus.
  • the cache size maximum (Maximum), which is larger than the application size of the application (APP1), and that the entire application (APP1) can be cached.
  • the data size obtained by adding the size of the link destination application (APP2) to the application size is compared with the cache size of the receiving apparatus that can be cached.
  • the cache size is the maximum (Maximum), and this cache size is larger than the total application size of the two applications (APP1, APP2), and it is determined that the entire two applications (APP1, APP2) can be cached. To do.
  • the size of the link destination application (APP3) of the link destination application (APP2) is acquired, and the total data size of the three applications is compared with the cache size.
  • the cache size is larger than the total data size of the three applications, and it is determined that all three applications can be stored (cached). As a result, it is decided to execute the cache processing of all three applications (APP1, APP2, APP3) in the link relationship.
  • Step S153 the receiving apparatus acquires entry document acquisition destination information from the S-TSID. Specifically, as shown in step S153 of FIG. 34, the content location information (RS / LS / ScFlw / EFDT / content-location) recorded in the file unit information recorded in the S-TSID, and the AIT A file (FILE) matching the application location (applicationLocation) is searched, and the acquisition destination information is acquired. In this example, a file (FILE) that matches three application locations (applicationLocation) recorded in the AIT is searched, and the acquisition destination information is acquired.
  • FILE file that matches three application locations (applicationLocation) recorded in the AIT
  • step S154 the receiving apparatus determines from the presentation unit ID (PUID) described in the group (Group) element of the entry document of each of the three applications, the application body ID (appId) and the group ID (groupId). To get.
  • PID presentation unit ID
  • group group element of the entry document of each of the three applications
  • appId application body ID
  • groupId group ID
  • the presentation unit ID is composed of an application main body ID (appId) and a group ID (groupId).
  • the application main body ID (appId) is an application main body ID (appId) that is configuration data of an application ID (organization ID (orgId) + application main body ID (appId)) set to the application to which the presentation unit (PU) to which the file belongs. ) Is the same value.
  • step S154a, S154b, and S154c in FIG. 34 three application IDs (appId1, appId2, and appId3) having a link relationship are acquired.
  • step S155 the receiving apparatus acquires a file having the same application body ID (appId) as the application body ID (appId) in the PUID (application body ID (appId) + group ID (groupId)) of the entry document. Then, the cache process is executed.
  • a file having three application IDs (appId1, appId2, and appId3) is acquired, cache processing is executed, and execution of the application is started using the entry document of application 1 (APP1).
  • step S155 of FIG. 34 the same application as the application main body ID (appId1, appId2, appId3) constituting the PUID (PUId11, PUId21, PUId31) of the entry document from the information of the file unit recorded in the S-TSID.
  • a file having a main body ID (appId1, appId2, appId3) is acquired, cache processing is executed, and output (display) is performed.
  • the application (APP1) for which the link relationship is set the application (APP2), and all the presentation units (PU11, PU12, PU13, PU21, PU22, PU23, PU31, PU32) belonging to the application (APP3). ) Can be acquired.
  • Step S201 is a channel selection process executed in the receiving apparatus. This is a reception channel (for example, broadcast station) selection process by the user on the reception device side.
  • This is a reception channel (for example, broadcast station) selection process by the user on the reception device side.
  • Step S202 When one reception channel is selected in step S201, in step SZ202, the reception apparatus executes a broadcast stream reception process corresponding to the selected channel. Details of this processing will be described later with reference to the flowchart of FIG.
  • Step S203 is a determination process step of the end of reception of the broadcast stream. For example, the broadcast stream reception process in step S202 is terminated with a process such as power-off of the reception device by the user as a trigger. If the broadcast stream reception is not terminated, the broadcast stream reception process in step S202 is continued.
  • Step S251 When the receiving device starts receiving the broadcast stream, the receiving device starts receiving the transmission packet from the transmitting device. Note that the data storage packet corresponding to the channel selected according to the channel selected in the receiving apparatus is selected and acquired. Note that the data transmitted by the transmission device is as described above with reference to FIG. AV segment, Signaling data, NRT data including applications, etc. These are various data.
  • the signaling data includes various types of signaling data such as USBD / USD, AIT, and S-TSID described above.
  • the receiving device refers to the packet header information of the received packet and the received data is Whether it is an AV segment such as video, audio, subtitle data, Whether it is NRT data such as application, Whether it is signaling data, Which of these is determined.
  • the process proceeds to step S253.
  • the received packet is a packet storing NRT data such as an application
  • the process proceeds to step S254.
  • the received packet is a packet storing signaling data such as USBD / USD, AIT, S-TSID, etc.
  • the process proceeds to step S255.
  • Step S253 If the received packet is a packet storing AV segments such as video, audio, and caption data, in step S253, video, audio, caption data, etc. are extracted from the received packet, predetermined decoding processing is executed, and rendering is performed. That is, reproduction output processing is executed.
  • This process is, for example, a broadcast program reproduction output process.
  • Step S254 If the received packet is a packet storing NRT data such as an application, NRT data is received and stored based on the signaling data in step S254. If the NRT data is an application, as described above, the process involving the selection process of the stored (cache) data is executed according to the recording information of the signaling data such as USBD / USD, AIT, S-TSID, etc. .
  • the acquisition of the signaling data corresponding to the application is executed prior to the application storing (cache) processing, and the application is selectively taken and the cache processing is executed according to the description of the previously acquired signaling data.
  • Step S255 If the received packet is a packet storing signaling data such as USBD / USD, AIT, S-TSID, etc., the process proceeds to step S255. In step S255, a signaling data reception and analysis process is executed. Details of this processing will be described later with reference to the flow of FIG.
  • Step S256 it is determined based on the analysis result of the signaling data in step S255 whether application acquisition processing is necessary. Specifically, a process for determining whether or not the receiving apparatus is set to execute an application acquisition process, that is, whether or not an application acquisition process flag is set to True is performed.
  • This flag setting is set when AIT is received as signaling data in step S255. Details will be described later with reference to the flow shown in FIG. If the flag setting is set to execute application acquisition processing, the process proceeds to step S257. If it is determined that the setting is not to acquire an application, the process returns to the start position of the broadcast stream reception process in step S202, and the next packet reception process, that is, the process from step S251 is executed.
  • Step S257 If it is determined in step S256 that the application acquisition process is necessary based on the analysis result of the signaling data in step S255, the process proceeds to step S257, and the application acquisition process is executed.
  • This process is an application acquisition process according to the recording information of signaling data such as USBD / USD, AIT, and S-TSID described above, and a process of selecting cache target data according to the cache capacity of the own device. It is an accompanying process. This process will be described in detail later with reference to the flow shown in FIG.
  • Step S281 the receiving apparatus determines whether the received signaling data is signaling data to be acquired. If unacquired signaling data or updated signaling data of a newer version than the acquired signaling data is received even if it has been acquired, it is determined that it is the acquisition target signaling data, and the process proceeds to step S282.
  • Step S282 the receiving device acquires signaling data.
  • signaling data such as USBD / USD, AIT, and S-TSID, and MPD that is signaling data corresponding to the AV stream.
  • step S283 the receiving apparatus determines whether or not the received signaling data is an AIT (application information table) in which control information corresponding to the application is recorded. If it is AIT, the process proceeds to step S284. If it is signaling data other than AIT, the process proceeds to step S285.
  • AIT application information table
  • Step S284 If it is determined in step S283 that the received signaling data is an AIT (application information table) in which control information corresponding to the application is recorded, the receiving apparatus executes an application acquisition process in step S284. Setting, that is, processing for setting the application acquisition processing flag to True is performed.
  • AIT application information table
  • Step S285 On the other hand, if it is determined in step S283 that the received signaling data is not AIT (application information table) in which control information corresponding to the application is recorded, but other signaling data, the receiving apparatus proceeds to step S285. Proceed, analyze the received signaling data other than the AIT, and execute processing according to the received signaling data.
  • AIT application information table
  • Step S301 First, in step S301, the receiving apparatus acquires control code (ctrlCode) information defining a processing mode for an application from the acquired AIT, and determines whether the control code is a code that requires cache processing of the application. judge.
  • control code ctrlCode
  • the code that requires cache processing includes, for example, a code that specifies an immediate execution of an application (AUTOSTART), or a code that acquires an application in advance and then executes it at a predetermined time (PREFETCH). If it is confirmed that the control code recorded in the AIT is a code that requires cache processing of these applications, the process proceeds to step S302. If the code does not require cache processing, the processing in step S302 and subsequent steps is not executed, and processing corresponding to the recording code is executed.
  • AUTOSTART a code that specifies an immediate execution of an application
  • PREFETCH predetermined time
  • Step S302 Upon confirming that the control code recorded in the AIT is a code that requires application cache processing, the receiving apparatus reads the application acquisition URI from the AIT in step S302. That is, the application access information (appLocation (URI)) in the AIT record information described above with reference to FIG.
  • URI application access information
  • step S303 the receiving apparatus refers to another signaling data USD (or USBD) to confirm whether the application is transmitted via a broadcast wave or a communication network.
  • USD or USBD
  • step S305 If it is confirmed that the application is transmitted via the broadcast wave, the process proceeds to step S305. On the other hand, if it is confirmed that the application is transmitted via a communication network such as the Internet, the process proceeds to step S306.
  • Step S305 When it is confirmed that the application is transmitted via the broadcast wave, in step S305, an application acquisition process via the broadcast wave is executed in step S305. This process will be described in detail later with reference to the flow shown in FIG.
  • Step S306 On the other hand, when it is confirmed that the application is transmitted via a communication network such as the Internet, in step S306, an application acquisition process via the communication network is executed in step S306.
  • Step S307 After the application acquisition process is performed in step S305 or step S306, the receiving apparatus executes the application in step s307. Note that the application execution timing and the like are recorded in the AIT corresponding to the application, and the receiving apparatus performs execution control of the application according to the description of the AIT.
  • Step S321 First, in step S321, the receiving device acquires a cache size that can be used by the receiving device.
  • Step S322 the reception apparatus acquires the data size of the application scheduled to be acquired, that is, the application size.
  • the application size is recorded in the AIT as described above with reference to FIG.
  • the application size is 253 (@appSize) shown in FIG.
  • the receiving apparatus reads the application size with reference to the AIT corresponding to the application scheduled to be acquired.
  • step S323 the receiving device compares the cache size available to the receiving device with the application size. If the cache size is smaller than the application size, the process proceeds to step S324. On the other hand, if the cache size is greater than or equal to the application size, the process proceeds to step S325.
  • Step S324 In the size comparison process in step S323, if it is determined that the cache size is smaller than the application size, the process proceeds to step S324, and the cache process for each presentation unit (PU) is executed.
  • This process is the process described above with reference to FIGS. This is a process corresponding to the process when the cache size is the minimum size (Minimum) or the small size (Small).
  • Step S325 On the other hand, in the size comparison process in step S323, if it is determined that the cache size is equal to or larger than the application size, the process proceeds to step S325, and the cache process for each application is executed.
  • This process is the process described above with reference to FIGS. 26 to 34, that is, This is a process corresponding to a process when the cache size is a medium size (Medium), a large size (Large), or a maximum size (Maximum).
  • Step S341 First, in step S341, the receiving apparatus determines from the S-TSID which is signaling data transmitted from the transmitting apparatus, the ID of the presentation unit (PU) including the entry document and the presentation unit (PU) linked from this PU. (PUID) is acquired.
  • the receiving device refers to the presentation unit-unit link information 261 in the S-TSID described above with reference to FIG. 16, and acquires the ID of the PU having a link relationship.
  • Step S342 the receiving apparatus compares the cache size of the receiving apparatus, that is, the available cache size with the data size of each presentation unit (PU), and selects a presentation unit to be cached.
  • the highest priority cache target PU is a presentation unit (for example, PU11) having an entry document.
  • the next priority cache target PU is the link destination PU of the PU 11 having the entry document, for example, the PU 12. Further, the link destination PU 13 of the PU 12 is selected as the next cache target PU, and the cache target PU is sequentially selected following the link. When the cache size is exceeded, the selection of the cache target PU is completed.
  • the cache target PUs are sequentially selected following the link.
  • Step S343 the receiving apparatus acquires the cache target presentation unit (PU) determined in step S342, and caches (stores) it in the cache unit (storage unit). Thereafter, in step S307 shown in the flow of FIG. 38, the application is executed using the cached presentation unit.
  • PU cache target presentation unit
  • the process according to the flow shown in FIG. 40 is the process described above with reference to FIGS. This is a process corresponding to the process when the cache size is the minimum size (Minimum) or the small size (Small).
  • one presentation unit is composed of a set of data presented using one or more HTML (HyperText Markup Language).
  • one presentation unit (PU) is a unit including the following components. (1) One or a plurality of HTML files (2) Image (moving image, still image) files output in accordance with the above HTML, (3) an audio file output in accordance with the HTML, (4) A style sheet storage file that defines the data output style according to the above HTML.
  • one presentation unit (PU) is set by the above components.
  • Step S361 First, in step S361, the reception apparatus acquires information on the initial execution application and the link destination application of the application from the AIT that is signaling data transmitted from the transmission apparatus.
  • the receiving device refers to the link destination application information 254 in the AIT described above with reference to FIG. 15 and acquires information on the application having the link relationship.
  • Step S362 the receiving apparatus compares the cache size of the receiving apparatus, that is, the available cache size with the data size of each application, and selects an application to be cached.
  • the highest priority cache target application is an initial activation application (for example, APP1) designated by the AIT.
  • the next priority cache target application is the link destination application of the initial activation application 1 (APP1), for example, APP2.
  • APP3 link destination application 3 of the application 2 (APP2) is selected as the next cache target application, and the cache target application is sequentially selected following the link.
  • selection of the cache target application is completed.
  • application 1 (APP1) + application 2 (APP2)) size ⁇ cache size ⁇ (application 1 (APP1) + application 2 (APP2) + application 3 (APP3)) size, then application 1 (APP1) and Application 2 (APP2) is selected as the cache target PU.
  • the cache target applications are sequentially selected following the link.
  • Step S363 the receiving apparatus acquires the cache target application determined in step S362 and caches (stores) it in the cache unit (storage unit). Thereafter, in step S307 shown in the flow of FIG. 38, the application is executed using the cached application.
  • the process according to the flow shown in FIG. 41 is the process described above with reference to FIGS. This is a process corresponding to a process when the cache size is a medium size (Medium), a large size (Large), or a maximum size (Maximum).
  • one application includes one or more presentation units (PUs).
  • Presentation unit (PU) (1) One or a plurality of HTML files (2) Image (moving image, still image) files output in accordance with the above HTML, (3) an audio file output in accordance with the HTML, (4) A style sheet storage file that defines the data output style according to the above HTML. For example, it is comprised by the said component.
  • the cache processing according to the present disclosure executes cache processing in units of applications or presentation units (PUs).
  • the minimum cache unit is a presentation unit (PU) and does not cause a situation in which a part of data constituting the PU is not cached. Therefore, the completed data output by the HTML document included in the presentation unit (PU) is executed.
  • Step S501 The process described below is a process performed while a predetermined application is being executed in the receiving apparatus.
  • the receiving apparatus waits for a transition event.
  • transition is a transition between applications that is a transition from a running application to a linked application, or a transition from a running presentation unit (PU) to a linked presentation unit (PU).
  • PU running presentation unit
  • PU linked presentation unit
  • the transition event is an event instructing a transition to a link destination generated based on, for example, AIT control information or a user operation, for example.
  • the receiving apparatus detects the transition event, the receiving apparatus proceeds to step S503.
  • Step S503 In response to the detection of the transition event, the receiving apparatus determines whether or not the transition destination application or the presentation unit (PU) has been cached in step S503. If already cached, the process proceeds to step S504. On the other hand, if not cached, the process proceeds to step S505.
  • Step S504 If it is determined in step S503 that the transition destination application or presentation unit (PU) has been cached, the transition destination application or presentation unit (PU) is acquired from the cache unit in step S504. Execute.
  • step S505 On the other hand, if it is determined in step S503 that the transition destination application or presentation unit (PU) has not been cached, in step S505, it is confirmed whether the transition mode is any of the following. (A) transitions between presentation units (PUs) in the application; (B) transition between applications,
  • step S506 If it is a transition between presentation units (PUs) in the application, the process proceeds to step S506. On the other hand, in the case of (b) transition between applications, the process proceeds to step S507.
  • Step S506 In step S505, if the transition event is (a) transition between presentation units (PU) in the application, in step S506, the cache processing of the transition destination presentation unit (PU) is executed. This process is the same as the cache process for each presentation unit (PU) described with reference to FIG.
  • the cached presentation unit (PU) is acquired from the cache unit and executed.
  • Step S507 On the other hand, if the transition event is (b) transition between applications in step S505, the transition destination application is acquired and cache processing is executed in step S507, and then the cache application is executed. This process is the same as the application acquisition and execution process described above with reference to FIG.
  • the cache processing is executed with the cache target as the application or presentation unit (PU) unit according to the link destination.
  • Example 1 Example of transition process from program-linked application to CM application executed together with program playback (Example 2) Example of transition process from program playback application to CM application
  • Example 1 An example of a transition process from a program-linked application to a CM application executed in conjunction with program playback will be described.
  • FIG. 43 shows the following four data provided by the transmission device via the broadcast wave corresponding to the channel selected by the reception device.
  • A Image (Video)
  • B Audio
  • C NRT (Application (APP))
  • D Signaling data
  • the receiving apparatus executes the processes of steps S701 to S707 shown in FIG. Each processing step will be described sequentially.
  • Step S701 First, in step S701, the receiving device receives signaling data transmitted from the transmitting device.
  • signaling data There are various types of signaling data, such as USBD / USD, AIT, S-TSID, and MPD used for program playback.
  • the receiving device receives these signal link data.
  • Step S702 the receiving apparatus analyzes the received signaling data, and based on the analysis result, it is necessary for program playback and application execution, such as access information such as AV segments that are program configuration data and application resources of the application. Get information that becomes.
  • step S703 the receiving apparatus executes data acquisition processing such as AV segments and application resources constituting the program, and cache processing based on the signaling data analysis information acquired in step S702.
  • an AV segment required for program playback, a program-linked application (APP1) to be executed in conjunction with program playback, and a CM application (CM) that is a link destination (transition destination) application of the program-linked application (APP1) APP) is acquired and stored in the cache unit.
  • Step S704 the receiving apparatus performs program playback using the AV segment acquired via the broadcast wave, and further executes the program-linked application (APP1) in parallel with the program playback.
  • the program is a baseball broadcast
  • the program-linked application (APP1) includes a combination of player information providing applications for participating players.
  • Step S705 an event notification using signaling data is made to the receiving apparatus.
  • This event notification is an event notification for requesting switching of an execution application, that is, an inter-application transition notification event.
  • Step S706 The receiving device executes an application transition process in response to the detection of the application transition event.
  • a specific processing sequence of this processing is processing according to the flowchart shown in FIG.
  • the transition destination application is a CM application (CM APP).
  • Step S707 In step S ⁇ b> 707, the reception apparatus starts a CM reproduction process using a previously cached CM application (CM APP).
  • CM APP previously cached CM application
  • the CM application to be played back here can be set as a CM corresponding to the viewer, as described above with reference to FIG.
  • the receiving device selects and caches CM apps to be received according to user information registered in advance. By executing such an application selection acquisition process, it is possible to display an optimal user-compatible CM according to the age, sex, preference, etc. of the user (viewer).
  • Example 2 An example of transition processing from a program playback application to a CM application will be described.
  • FIG. 44 also shows the following four data provided by the transmitting device via the broadcast wave corresponding to the channel selected by the receiving device, as in FIG. (A) Image (Video) (B) Audio (C) NRT (Application (APP)) (D) Signaling data
  • the receiving apparatus executes the processes of steps S801 to S807 shown in FIG. Each processing step will be described sequentially.
  • Step S801 First, in step S801, the receiving device receives signaling data transmitted from the transmitting device.
  • signaling data There are various types of signaling data, such as USBD / USD, AIT, S-TSID, and MPD used for program playback.
  • the receiving device receives these signal link data.
  • Step S802 the receiving apparatus analyzes the received signaling data, and based on the analysis result, it is necessary for program playback and application execution such as access information such as AV segment which is program configuration data, application resource of the application, etc. Get information that becomes.
  • access information such as AV segment which is program configuration data, application resource of the application, etc. Get information that becomes.
  • step S803 the receiving apparatus executes data acquisition processing such as AV segments and application resources constituting the program, and cache processing based on the signaling data analysis information acquired in step S702.
  • an AV segment required for program playback a program playback application (APP1) that executes program playback processing
  • a CM application CM APP
  • a link destination (transition destination) application of the program playback application (APP1) ) Is acquired and stored in the cache unit.
  • Step S804 the receiving apparatus performs program playback using the AV segment acquired through the broadcast wave and the program playback application (APP1).
  • APP1 program playback application
  • Step S805 the receiving apparatus detects an event caused by signaling data such as AIT or a user operation (remote control operation), for example.
  • This event is an event for requesting switching of the execution application. That is, it is an inter-application transition notification event.
  • Step S806 The receiving device executes an application transition process in response to the detection of the application transition event.
  • a specific processing sequence of this processing is processing according to the flowchart shown in FIG.
  • the transition destination application is a CM application (CM APP).
  • Step S807 the reception apparatus starts a CM reproduction process using a previously cached CM application (CM APP).
  • CM APP previously cached CM application
  • the CM application can be set as a CM corresponding to the viewer as described above with reference to FIG.
  • the transmitting device transmits different CM apps corresponding to various viewers
  • the receiving device selects and caches CM apps to be received according to user information registered in advance.
  • an application selection acquisition process it is possible to display an optimal user-compatible CM according to the age, sex, preference, etc. of the user (viewer).
  • SW Cuche Control Processing Using Service Worker
  • the service worker (SW) is provided from the transmitting device 20 such as a broadcast server or an advertisement server to the receiving device 30.
  • the service worker (SW) acquires an application executed in the receiving device (client) 30 and a data file used when executing the application, a storage process for the storage unit (cache), an update process, and a delete process. It is a program that executes etc. Specifically, for example, it is configured by JavaScript (registered trademark).
  • the service worker (SW) is set in correspondence with, for example, a broadcast program (broadcast content) provided by the transmission device 20, and is applied to the reception device 30 as an application control and management program provided from the transmission device 20 to the reception device 30. Provided.
  • 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. 45 shows a state in which the receiving device 30 receives 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 (resource) including various data such as a still image and audio is provided to the receiving device 30.
  • 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 together with 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.
  • the weather information display application is stored in the storage unit (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 (cache) under the control of the service worker (SW) and displayed on the display unit.
  • a storage unit (cache) that stores resources such as applications is preferably a nonvolatile 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 (cache) of the receiving device 30.
  • a cache control process can be executed using this service worker (SW). That is, the configuration is such that the presentation unit (PU) unit cache processing described with reference to the flowchart shown in FIG. 40 and the application unit cache control processing described with reference to FIG. 41 are executed. Can do.
  • SW service worker
  • FIG. 47 is a diagram illustrating an example of processing using a service worker (SW). 47, the receiving device 30 acquires a Web page (for example, the weather information display page shown in FIGS. 45 and 46) as a resource from the transmitting device 20, and stores it in the storage unit (cache) of the receiving device 30 for use. An example of the sequence to be performed is shown. The Web page is displayed using a resource configured by a predetermined Web page display application and display data.
  • FIG. 47 shows a display processing unit 451, a service worker (SW) 452, and a cache (storage unit) 453 as components of the browser 450 in the receiving apparatus.
  • SW service worker
  • Steps S851 to S852 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.
  • a service worker (SW) is applied to execute a resource acquisition process corresponding to the cache size, application size, and presentation unit (PU) size. That is, cache processing is executed with the minimum cache size as a presentation unit (PU).
  • the display processing unit 451 displays the Web page 455 by application execution 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 S855 the user makes a web page browsing request.
  • the service worker (SW) 452 detects the input of the browsing request as a fetch event, and acquires a resource (Web page) from the storage unit (cache) in step S856 in response to the fetch event detection.
  • step S857 the display processing unit 451 displays the web page 456.
  • 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 stores resources including, for example, applications and programs including Web pages, HTML pages, JavaScript (registered trademark), data used for applications, and the like.
  • Execute resource management such as updating and deleting.
  • 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 cache.
  • various controls can be performed on the resources to be managed by the service worker (SW). For example, in response to a resource access request (resource fetch request), before processing on the browser side (acquisition of resources from the local cache or network) begins, processing of the service worker (SW) is started and the cache Resources are provided from.
  • resource access request resource fetch request
  • the service worker (SW) is provided by Java Script (registered trademark)
  • various procedures can be incorporated, and flexible processing description of cache control such as updating of a part of cache resources is possible. It has become.
  • 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 or program such as a weather information display application as described with reference to FIGS. 45 and 46, that is, a service worker (SW). It is possible to execute an application or a program that is a management target.
  • SW service worker
  • FIG. 48 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 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 AV segment, application, and other various data provided to the receiving apparatus (client) 30 and signaling data.
  • the communication unit 752 performs communication processing such as distribution of applications, other various data, and signaling data in addition to AV segments.
  • the storage unit 753 stores AV segments to be distributed, applications, data used by the 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 data processing unit 751 stores a packet that stores application configuration data, an application size that is a data size of an application, and first signaling data (AIT) that records application link information that is link information between applications, Further, a packet storing the data size of the presentation unit, which is a component of the application, and second signaling data (S-TSID) in which link information between the presentation units is recorded is generated.
  • the communication unit 752 executes processing for transmitting these packets generated by the data processing unit 751 and the like.
  • 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, such as AV segments, applications, data used by applications, signaling data, and the like.
  • the data processing unit 771 executes communication data processing, signaling data analysis processing, data cache control processing, reproduction control processing, application control processing, etc., for example, processing according to the above-described embodiment. Specifically, cache control for each application, presentation unit (PU), application execution control, and the like are executed.
  • the storage unit 773 stores AV segments, applications, data used by applications, 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.
  • the communication unit 772 determines the application size that is the data size of the application, the first signaling data (AIT) that records the application link information that is the link information between the applications, and the data size of the presentation unit that is a component of the application.
  • the recorded second signaling data (S-TSID) and the like are received.
  • the data processing unit 771 compares the cache size, which is the data size that can be stored in the storage unit 773 of its own device, with the data size of each application having a link relationship acquired from the first signaling data (AIT). Then, one or more cacheable applications are determined as cache target applications, and cache processing for each application is executed.
  • the cache size which is the data size that can be stored in the storage unit 773 of its own device
  • the data processing unit 771 refers to the second signaling data (S-TSID), compares the data size of the presentation unit with the cache size, One or more presentation units having a size equal to or smaller than the cache size are determined as a cache target, and a cache process for each presentation unit is executed.
  • S-TSID second signaling data
  • FIG. 49 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.
  • the technology disclosed in this specification can take the following configurations.
  • a communication unit that receives first signaling data in which application size that is data size of an application and application link information that is link information between applications is recorded;
  • One or more cacheable applications are cached by comparing the cache size, which is the data size that can be stored in the storage unit of the own device, with the data size of each application having a link relationship acquired from the first signaling data.
  • a receiving apparatus that includes a data processing unit that determines a target application and executes cache processing for each application.
  • the first signaling data is: Correspondence data between the link source application ID and the link destination application ID is recorded as application link information, Further, the application size is recorded in association with each application ID, The data processing unit Obtaining a link source application ID and a link destination application ID from the application link information of the first signaling data; The receiving device according to (1), wherein application size information recorded corresponding to each acquired application ID is acquired, and one or more cacheable applications are determined as cache target applications.
  • the receiving device (5) The receiving device according to any one of (1) to (4), wherein the first signaling data is an application information table (AIT: Application Information Table) in which information in units of applications is recorded.
  • AIT Application Information Table
  • the communication unit The receiving device according to any one of (1) to (5), wherein the first signal data is received via a broadcast wave.
  • the receiving unit Receiving second signaling data in which the data size of the presentation unit that is a component of the application is recorded; The data processing unit When the cache size is smaller than the data size of one application, Referring to the second signaling data, comparing the data size of the presentation unit with the cache size; The receiving apparatus according to any one of (1) to (7), wherein one or more presentation units having a size equal to or smaller than a cache size is determined as a cache target, and cache processing for each presentation unit is executed.
  • the presentation unit is The receiving device according to (8), which is a set of data including one or a plurality of HTML (HyperText Markup Language) documents and a data file output by applying the HTML document.
  • HTML HyperText Markup Language
  • the second signaling data is: Corresponding data between the link source presentation unit ID and the link destination presentation unit ID is recorded as presentation unit link information. Furthermore, the presentation unit size is recorded in association with each presentation unit ID.
  • the data processing unit Obtaining a link source presentation unit ID and a link destination presentation unit ID from the presentation unit link information of the second signaling data; The presentation unit size information recorded corresponding to each acquired presentation unit ID is acquired, and one or more presentation units that can be cached are determined as a cache target application. (8) or (9) Receiver.
  • the data processing unit If there are multiple presentation units that are linked, The presentation unit including the entry document is selected as the highest priority cache target presentation unit, and the cache target presentation units are sequentially selected in accordance with the link from the presentation unit including the entry document (8). (10) The receiving device according to any one of (1) to (10).
  • the presentation unit ID is an ID including an application main body ID capable of identifying an application to which the presentation unit belongs and a group ID capable of individually identifying the presentation unit in the belonging application (10). Or the receiving apparatus as described in (11).
  • the communication unit The receiving apparatus according to any one of (8) to (14), wherein the second signal data is received via a broadcast wave.
  • the data processing unit further includes: Generating a packet storing the second signaling data in which the data size of the presentation unit as a component of the application and the link information between the presentation units are recorded; The transmission device according to (16), wherein the communication unit transmits a packet storing the second signaling data.
  • the presentation unit is The transmission device according to (17), which is a set of data composed of one or a plurality of HTML (HyperText Markup Language) documents and data files output by applying the HTML documents.
  • HTML HyperText Markup Language
  • the communication unit receives the first signaling data in which the application size which is the data size of the application and the application link information which is the link information between the applications are recorded,
  • the data processing unit compares the cache size, which is the data size that can be stored in the storage unit of the device itself, with the data size of each application in the link relationship acquired from the first signaling data, and can cache one
  • a data processing method in which the above applications are determined as cache target applications, and cache processing is performed in units of applications.
  • a data processing method to be executed in the transmission device The data processor A packet storing application configuration data; Generating a packet storing the first signaling data in which the application size that is the data size of the application and the application link information that is link information between the applications is recorded; A data processing method in which a communication unit transmits a packet generated by the data processing unit.
  • 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.
  • the reception apparatus executes cache processing in units of applications or presentation units, and enables application execution processing with high completeness.
  • the method is realized. Specifically, the receiving device receives the application data that is the data size of the application, the application link information, and the signaling data that records the data size of each presentation unit (PU) that is the application component from the transmitting device. To do.
  • the receiving device compares the cache size with the data size of each application and PU, determines a cacheable application or PU as cache target data, and executes cache processing for each application or PU.

Landscapes

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

Abstract

受信装置において、アプリケーション単位、またはプレゼンテーション・ユニット単位のキャッシュ処理を実行させ、完成度の高いアプリケーション実行処理を可能とする装置、方法を提供する。受信装置が、送信装置からアプリケーションのデータサイズであるアプリケーションサイズと、アプリケーションリンク情報、さらに、アプリケーション構成要素であるプレゼンテーション・ユニット（ＰＵ）各々のデータサイズを記録したシグナリングデータを受信する。受信装置はキャッシュサイズと、アプリケーションや、ＰＵ各々のデータサイズとを比較し、キャッシュ可能なアプリケーション、またはＰＵをキャッシュ対象データとして決定し、アプリケーションまたはＰＵ単位のキャッシュ処理を実行する。

Description

受信装置、送信装置、およびデータ処理方法
　本開示は、受信装置、送信装置、およびデータ処理方法に関する。さらに詳細には例えば放送波やネットワークを介したデータの受信または送信を実行する受信装置、送信装置、および通信データ対応のデータ処理方法に関する。
　画像データや音声データ等のコンテンツを各通信事業者のサービス形態に関わらず配信可能としたデータ配信方式としてＯＴＴ（Ｏｖｅｒ　Ｔｈｅ　Ｔｏｐ）がある。ＯＴＴによる配信コンテンツはＯＴＴコンテンツと呼ばれ、また、ＯＴＴを利用した画像（ビデオ）データの配信サービスはＯＴＴビデオやＯＴＴ－Ｖ（Ｏｖｅｒ　Ｔｈｅ　Ｔｏｐ　Ｖｉｄｅｏ）と呼ばれる。
　ＯＴＴ－Ｖに従ったデータストリーミング配信規格としてＤＡＳＨ（Ｄｙｎａｍｉｃ　Ａｄａｐｔｉｖｅ　Ｓｔｒｅａｍｉｎｇ　ｏｖｅｒＨＴＴＰ）規格がある。ＤＡＳＨは、ＨＴＴＰ（ＨｙｐｅｒＴｅｘｔ　Ｔｒａｎｓｆｅｒ　Ｐｒｏｔｏｃｏｌ）をベースとしたストリーミングプロトコルを用いたアダプティブ（適応型）ストリーミング配信に関する規格である。
　アダプティブ（適応型）ストリーミングでは、放送局等のコンテンツ配信サーバは、データ配信先となる様々なクライアントにおいてコンテンツ再生を可能とするため、複数のビットレートの動画コンテンツの細分化ファイルとこれらの属性情報やＵＲＬ（Ｕｎｉｆｏｒｍ　Ｒｅｓｏｕｒｃｅ　Ｌｏｃａｔｏｒ）を記述したマニフェスト・ファイルを作成し、クライアントに提供する。
　クライアントは、マニフェスト・ファイルをサーバから取得して、自装置の表示部のサイズや利用可能な通信帯域に応じた最適なビットレートコンテンツを選択し、選択コンテンツを受信して再生する。ネットワーク帯域の変動に応じてビットレートの動的な変更も可能であり、クライアント側では、状況に応じた最適なコンテンツを随時切り替えて受信することが可能となり、映像途切れの発生を低減した動画コンテンツ再生が実現される。なお、アダプティブ（適応型）ストリーミングについては、例えば特許文献１（特開２０１１－８７１０３号公報）に記載がある。
　放送局やその他のコンテンツサーバ等の送信装置から、テレビ、ＰＣ、携帯端末等の受信装置に対して、放送波等による一方向通信、あるいは、インターネット等のネットワークを介した双方向通信、一方向通信を用いて放送番組等のコンテンツを送受信するシステムについての開発や規格化が、現在、盛んに進められている。
　なお、放送波およびネットワークを介したデータ配信を実現するための技術を開示した従来技術として、例えば特許文献２（特開２０１４－０５７２２７号公報）がある。
　放送波およびネットワークを介したデータ配信システムに関する規格として、現在、ＡＴＳＣ（Ａｄｖａｎｃｅｄ　Ｔｅｌｅｖｉｓｉｏｎ　Ｓｙｓｔｅｍ　Ｃｏｍｍｉｔｔｅ）３．０の規格化が進行中である。
　ＡＴＳＣ３．０では、ＡＴＳＣ３．０準拠物理層（ＡＴＳＣ－ＰＨＹ）を実装した放送配信用デバイス（チューナ実装デバイス）上に、ＡＴＳＣ３．０放送の受信処理等を実行するミドルウェアを実装させることで、ＡＴＳＣ放送用の制御情報等を含むシグナリングデータを受信して、シグナリングデータによる様々な制御を可能とする構成を検討している。
　具体的には、シグナリングデータによる制御によって、インターネット等で利用されているアプリケーションプログラム、いわゆるクライアントアプリケーションをそのまま利用して、放送コンテンツの出力処理や、放送波等によって提供される様々なアプリケーションを利用したデータ処理を実現可能とする構成を検討している。
　例えば、家庭内やホットスポットに設置された放送サービスの受信装置（専用サーバの他、ＰＣ、ＴＶ、タブレット、スマホ等）にＡＴＳＣ３．０準拠物理層（ＡＴＳＣ－ＰＨＹ）、ならびに、ＡＴＳＣ３．０放送受信ミドルウェアを実装する。
　受信装置において、ＡＴＳＣ３．０放送サービスを受信後、受信装置の再生制御部やアプリケーション制御部上で稼働するアプリケーション（例えばＡＴＳＣ３．０　ＤＡＳＨクライアントアプリケーション）を利用して、放送コンテンツの再生や、放送で配信される様々なアプリケーションを実行することが可能となる。
　受信装置においてアプリケーションを実行するためには、アプリケーションを構成する様々なファイル、例えば動画等の画像ファイル、音声ファイル等をユーザ装置内のキャッシュ（記憶部）に格納するキャッシュ処理が必要となる。
　しかし、受信装置のキャッシュ（記憶部）に十分な空き容量が無い場合、アプリケーションの構成ファイルの全てを格納できない場合が発生する。
　アプリケーション構成ファイルの一部がキャッシュできないまま、アプリを実行すると、キャッシュできなかった画像（動画）や音声データの欠落や、全くアプリを実行できないといったアプリケーション・エラーが発生する場合がある。
特開２０１１－８７１０３号公報 特開２０１４－０５７２２７号公報
　本開示は、例えば上記問題点に鑑みてなされたものであり、放送波等を介してアイプリケーションを受信して実行する受信装置において、アプリケーション、またはアプリケーション構成要素単位のデータサイズやリンク情報を取得したキャッシュ処理により、所定のアプリ単位、またはアプリ構成要素単位のアプリケーションの実行を可能とする受信装置、送信装置、およびデータ処理方法を提供する。
　さらに、本開示の一実施態様では、アプリケーション構成要素のデータサイズ情報や、リンク情報を取得して、これらの取得情報に基づいて、キャッシュ可能なアプリケーション、またはアプリケーション構成要素を選択してキャッシュ処理を行なうことで、キャッシュデータに基づく確実なアプリケーションの実行を可能とする受信装置、送信装置、およびデータ処理方法を提供する。
　本開示の第１の側面は、
　アプリケーションのデータサイズであるアプリケーションサイズと、アプリケーション間のリンク情報であるアプリケーションリンク情報を記録した第１シグナリングデータを受信する通信部と、
　自装置の記憶部に格納可能なデータサイズであるキャッシュサイズと、前記第１シグナリングデータから取得するリンク関係にある各アプリケーションのデータサイズとを比較して、キャッシュ可能な１つ以上のアプリケーションをキャッシュ対象アプリケーションとして決定し、アプリケーション単位のキャッシュ処理を実行するデータ処理部を有する受信装置にある。
　さらに、本開示の第２の側面は、
　アプリケーション構成データを格納したパケットと、
　前記アプリケーションのデータサイズであるアプリケーションサイズと、アプリケーション間のリンク情報であるアプリケーションリンク情報を記録した第１シグナリングデータを格納したパケットを生成するデータ処理部と、
　前記データ処理部の生成したパケットを送信する通信部と、
　を有する送信装置にある。
　さらに、本開示の第３の側面は、
　受信装置において実行するデータ処理方法であり、
　通信部が、アプリケーションのデータサイズであるアプリケーションサイズと、アプリケーション間のリンク情報であるアプリケーションリンク情報を記録した第１シグナリングデータを受信し、
　データ処理部が、自装置の記憶部に格納可能なデータサイズであるキャッシュサイズと、前記第１シグナリングデータから取得するリンク関係にある各アプリケーションのデータサイズとを比較して、キャッシュ可能な１つ以上のアプリケーションをキャッシュ対象アプリケーションとして決定し、アプリケーション単位のキャッシュ処理を実行するデータ処理方法にある。
　さらに、本開示の第４の側面は、
　送信装置において実行するデータ処理方法であり、
　データ処理部が、
　アプリケーション構成データを格納したパケットと、
　前記アプリケーションのデータサイズであるアプリケーションサイズと、アプリケーション間のリンク情報であるアプリケーションリンク情報を記録した第１シグナリングデータを格納したパケットを生成し、
　通信部が、前記データ処理部の生成したパケットを送信するデータ処理方法にある。
　本開示のさらに他の目的、特徴や利点は、後述する本開示の実施例や添付する図面に基づくより詳細な説明によって明らかになるであろう。なお、本明細書においてシステムとは、複数の装置の論理的集合構成であり、各構成の装置が同一筐体内にあるものには限らない。
　本開示の一実施例の構成によれば、受信装置において、アプリケーション単位、またはプレゼンテーション・ユニット単位のキャッシュ処理を実行させ、完成度の高いアプリケーション実行処理を可能とする装置、方法が実現される。
　具体的には、受信装置が、送信装置からアプリケーションのデータサイズであるアプリケーションサイズと、アプリケーションリンク情報、さらに、アプリケーション構成要素であるプレゼンテーション・ユニット（ＰＵ）各々のデータサイズを記録したシグナリングデータを受信する。受信装置はキャッシュサイズと、アプリケーションや、ＰＵ各々のデータサイズとを比較し、キャッシュ可能なアプリケーション、またはＰＵをキャッシュ対象データとして決定し、アプリケーションまたはＰＵ単位のキャッシュ処理を実行する。
　本構成により、受信装置において、アプリケーション単位、またはプレゼンテーション・ユニット単位のキャッシュ処理を実行させ、完成度の高いアプリケーション実行処理を可能とする装置、方法が実現される。
　なお、本明細書に記載された効果はあくまで例示であって限定されるものではなく、また付加的な効果があってもよい。
本開示の処理を実行する通信システムの一構成例について説明する図である。 送信装置の送信データについて説明する図である。 送信装置および受信装置のプロトコルスタックの例を示す図である。 ＲＯＵＴＥ、およびＦＬＵＴＥに関するプロトコルスタックを示す図である。 受信装置（クライアント）３０におけるデータ出力例を説明する図である。 様々なユーザ情報を利用した出力広告の選択例について説明する図である。 受信装置の構成例について説明する図である。 アプリケーションの構成例について説明する図である。 アプリケーションの構成とリンクについて説明する図である。 アプリケーションのサイズと、キャッシュサイズとの対応例について説明する図である。 アプリケーションのサイズと、キャッシュサイズとの対応に基づくキャッシュ対象選択処理例について説明する図である。 シグナリングデータに基づくアプリケーション取得処理例について説明する図である。 ＵＳＢＤ／ＵＳＤにおける放送配信アプリケーション関連データの記録例について説明する図である。 ＵＳＢＤ／ＵＳＤにおける放送配信アプリケーション関連データの記録例について説明する図である。 ＡＩＴのデータ記録例について説明する図である。 Ｓ－ＴＳＩＤのデータ記録例について説明する図である。 Ｓ－ＴＳＩＤのデータ記録例について説明する図である。 Ｓ－ＴＳＩＤのデータ記録例について説明する図である。 キャッシュサイズに応じたキャッシュ処理のショリシーケンスについて説明するフローチャートを示す図である。 受信装置のキャッシュサイズに応じたキャッシュ処理の具体例について説明する図である。 受信装置のキャッシュサイズに応じたキャッシュ処理の具体的シーケンスについて説明するフローチャートを示す図である。 受信装置のキャッシュサイズに応じたキャッシュ処理二際して参照するシグナリングデータの記述について説明する図である。 受信装置のキャッシュサイズに応じたキャッシュ処理の具体例について説明する図である。 受信装置のキャッシュサイズに応じたキャッシュ処理の具体的シーケンスについて説明するフローチャートを示す図である。 受信装置のキャッシュサイズに応じたキャッシュ処理二際して参照するシグナリングデータの記述について説明する図である。 受信装置のキャッシュサイズに応じたキャッシュ処理の具体例について説明する図である。 受信装置のキャッシュサイズに応じたキャッシュ処理の具体的シーケンスについて説明するフローチャートを示す図である。 受信装置のキャッシュサイズに応じたキャッシュ処理二際して参照するシグナリングデータの記述について説明する図である。 受信装置のキャッシュサイズに応じたキャッシュ処理の具体例について説明する図である。 受信装置のキャッシュサイズに応じたキャッシュ処理の具体的シーケンスについて説明するフローチャートを示す図である。 受信装置のキャッシュサイズに応じたキャッシュ処理二際して参照するシグナリングデータの記述について説明する図である。 受信装置のキャッシュサイズに応じたキャッシュ処理の具体例について説明する図である。 受信装置のキャッシュサイズに応じたキャッシュ処理の具体的シーケンスについて説明するフローチャートを示す図である。 受信装置のキャッシュサイズに応じたキャッシュ処理二際して参照するシグナリングデータの記述について説明する図である。 受信装置の実行する処理について説明するフローチャートを示す図である。 受信装置の実行する処理について説明するフローチャートを示す図である。 受信装置の実行する処理について説明するフローチャートを示す図である。 受信装置の実行する処理について説明するフローチャートを示す図である。 受信装置の実行する処理について説明するフローチャートを示す図である。 受信装置の実行する処理について説明するフローチャートを示す図である。 受信装置の実行する処理について説明するフローチャートを示す図である。 受信装置の実行する処理について説明するフローチャートを示す図である。 受信装置の実行するアプリケーション遷移処理例について説明する図である。 受信装置の実行するアプリケーション遷移処理例について説明する図である。 サービスワーカー（ＳＷ）を利用した処理について説明する図である。 サービスワーカー（ＳＷ）を利用した処理について説明する図である。 サービスワーカー（ＳＷ）を利用した処理について説明する図である。 通信装置である送信装置と受信装置の構成例について説明する図である。 通信装置である送信装置と受信装置のハードウェア構成例について説明する図である。
　以下、図面を参照しながら本開示の受信装置、送信装置、およびデータ処理方法の詳細について説明する。なお、説明は以下の項目に従って行なう。
　１．通信システムの構成例について
　２．データ通信プロトコルＦＬＵＴＥ、およびＲＯＵＴＥについて
　３．送信装置と受信装置の実行する通信処理例について
　４．受信装置におけるアプリケーションを適用したデータ出力例について
　５．受信装置の構成例と処理例について
　６．アプリケーションの構成例について
　７．アプリケーションのキャッシュ処理について
　８．シグナリングデータの構成、およびシグナリングデータを適用したキャッシュ対象データ選択処理について
　９．受信装置のキャッシュサイズ（データ格納許容サイズ）に応じた具体的な処理例について
　９－１．受信装置のデータ格納許容キャッシュサイズが最小サイズ（Ｍｉｎｉｍｕｍ）であり、１つのプレゼンテーション・ユニット（ＰＵ）のみ格納可能である場合の処理例について
　９－２．受信装置のデータ格納許容キャッシュサイズが小サイズ（Ｓｍａｌｌ）であり、複数のプレゼンテーション・ユニット（ＰＵ）が格納可能である場合の処理例について
　９－３．受信装置のデータ格納許容キャッシュサイズが中サイズ（Ｍｅｄｉｕｍ）であり、１つのアプリケーションが格納可能である場合の処理例について
　９－４．受信装置のデータ格納許容キャッシュサイズが大サイズ（Ｌａｒｇｅ）であり、複数のアプリケーションが格納可能である場合の処理例について
　９－５．受信装置のデータ格納許容キャッシュサイズが最大サイズ（Ｍａｘｉｍｕｍ）であり、複数のアプリケーションが格納可能である場合の処理例について
　１０．受信装置におけるデータ処理の全体シーケンスについて
　１０－１．受信装置における放送ストリーム受信処理の全体シーケンス
　１０－２．受信装置における放送ストリーム受信処理の詳細シーケンス
　１０－３．受信装置におけるシグナリングの受信、解析処理の詳細シーケンス
　１０－４．受信装置におけるアプリケーションの取得、実行処理の詳細シーケンス
　１０－５．受信装置における放送経由のアプリケーションの取得処理の詳細シーケンス
　１０－６．受信装置におけるプレゼンテーション・ユニット（ＰＵ）単位のキャッシュ処理の詳細シーケンス
　１０－７．受信装置におけるアプリケーション単位のキャッシュ処理の詳細シーケンス
　１０－８．受信装置におけるアプリケーションまたはプレゼンテーション・ユニット（ＰＵ）間の遷移処理シーケンス
　１１．アプリケーション遷移処理の具体例について
　１２．サービスワーカー（ＳＷ）を利用したキュッシュ制御処理例について
　１３．送信装置と受信装置の構成例について
　１４．本開示の構成のまとめ
　　［１．通信システムの構成例について］
　まず、図１を参照して本開示の処理を実行する通信システムの一構成例について説明する。
　図１に示すように、通信システム１０は、画像データや音声データ等のコンテンツを送信する通信装置である送信装置２０と、送信装置２０の送信するコンテンツを受信する通信装置である受信装置３０を有する。
　送信装置２０は、具体的には、例えば、主にＴＶ番組等を送信する放送サーバ（放送局）２１や、主に広告データを送信する広告サーバ２２、様々なデータを送信するデータ配信サーバ２３等、様々なコンテンツ（放送番組、広告、その他のデータ）を提供する側の装置である。
　一方、受信装置３０は、一般ユーザのクライアント装置であり、具体的には、例えばテレビ３１、ＰＣ３２、携帯端末３３等によって構成される。
　なお、図１には、受信装置の代表例として、テレビ３１、ＰＣ３２、携帯端末３３を示しているが、本開示の処理を実行可能な受信装置としては、その他、例えば、スマートフォン、タブレット端末、スマートウォッチ、ウェアラブルデバイス等、様々な受信装置が含まれる。
　また、図１では、送信装置２０の例として、放送サーバ（放送局）２１、広告サーバ２２、データ配信サーバ２３を区別して記載しているが、１つのサーバが放送番組、広告、その他のデータをすべて送信する構成としてもよい。
　例えば、１つの放送局が、放送波を介して様々な番組、広告、アプリケーション、その他のデータを配信する構成、あるいは、１つのサーバが、通信ネットワークを介して様々な番組、広告、アプリケーション、その他のデータを配信する構成なども可能である。
　送信装置２０と受信装置３０間のデータ通信は、インターネット等のネットワークを介した双方向通信、一方向通信、あるいは、放送波等による一方向通信の少なくともいずれか、あるいは両者を利用した通信として行われる。
　送信装置２０から受信装置３０に対するコンテンツ送信は、例えばアダプティブ（適応型）ストリーミング技術の規格であるＭＰＥＧ－ＤＡＳＨ規格や、ＭＭＴ（ＭＰＥＧ　Ｍｅｄｉａ　Ｔｒａｎｓｐｏｒｔ）など、様々なフォーマットに従って実行される。なお、本開示の処理を実行する場合、データ配信フォーマットは限定されない。
　ＭＰＥＧ－ＤＡＳＨ規格には、以下の２つの規格が含まれる。
　（ａ）動画や音声ファイルの管理情報であるメタデータを記述するためのマニフェスト・ファイル（ＭＰＤ：Ｍｅｄｉａ　Ｐｒｅｓｅｎｔａｔｉｏｎ　Ｄｅｓｃｒｉｐｔｉｏｎ）に関する規格、
　（ｂ）動画コンテンツ伝送用のファイル・フォーマット（セグメント・フォーマット）に関する規格、
　送信装置２０から、受信装置３０に対するコンテンツ配信は、上記のＭＰＥＧ－ＤＡＳＨ規格に従って実行する。
　送信装置２０は、コンテンツデータを符号化し、符号化データおよび符号化データのメタデータを含むデータファイルを生成する。符号化処理は、例えばＭＰＥＧにおいて規定されるＭＰ４ファイルフォーマットに従って行われる。なお、送信装置２０がＭＰ４形式のデータファイルを生成する場合の符号化データのファイルは「ｍｄａｔ」、メタデータは「ｍｏｏｖ」や「ｍｏｏｆ」等と呼ばれる。
　送信装置２０が受信装置３０に提供するコンテンツは、例えば音楽データや、映画、テレビ番組、ビデオ、写真、文書、絵画および図表などの映像データや、ゲームおよびソフトウェアなど、様々なデータである。
　送信装置２０の送信データについて図２を参照して説明する。
　ＭＰＥＧ－ＤＡＳＨ規格に従ってデータ送信を実行する送信装置２０は、図２に示すように、大きく分けて以下の複数種類のデータの送信を行う。
　（ａ）シグナリングデータ５０
　（ｂ）ＡＶセグメント６０
　（ｃ）その他のデータ（ＥＳＧ，ＮＲＴコンテンツ等）７０
　ＡＶセグメント６０は、受信装置において再生する画像（Ｖｉｄｅｏ）や、音声（Ａｕｄｉｏ）データ、すなわち例えば放送局の提供する番組コンテンツ等によって構成される。例えば、上述したＭＰ４符号化データ（ｍｄａｔ）や、メタデータ（ｍｏｏｖ，ｍｏｏｆ）によって構成される。なお、ＡＶセグメントは、ＤＡＳＨセグメントとも呼ばれる。
　一方、シグナリングデータ５０は、番組表等の番組予定情報や、番組取得に必要となるアドレス情報（ＵＲＬ（Ｕｎｉｆｏｒｍ　Ｒｅｓｏｕｒｃｅ　Ｌｏｃａｔｏｒ）等）、さらにコンテンツの再生処理に必要な情報、例えばコーデック情報（符号化方式など）などからなる案内情報、アプリケーション制御情報等の様々な制御情報によって構成される。
　受信装置３０は、このシグナリングデータ５０を、再生対象となる番組コンテンツを格納したＡＶセグメント６０の受信に先行して受信することが必要となる。
　このシグナリングデータ５０は、例えばＸＭＬ（Ｅｘｔｅｎｓｉｂｌｅ　Ｍａｒｋｕｐ　Ｌａｎｇｕａｇｅ）形式のデータとして送信装置２０から送信される。
　シグナリングデータは、随時、繰り返し送信される。例えば１００ｍｓｅｃ毎など、頻繁に繰り返し送信される。
　これは、受信装置（クライアント）が、いつでも、即座にシグナリングデータを取得することを可能とするためである。
　クライアント（受信装置）は、随時、受信可能なシグナリングデータに基づいて、必要な番組コンテンツのアクセス用アドレスの取得や、コーデック設定処理など、番組コンテンツの受信および再生に必要な処理を遅滞なく実行することが可能となる。
　その他のデータ７０は、例えばＥＳＧ（Ｅｌｅｃｔｒｏｎｉｃ　Ｓｅｒｖｉｃｅ　Ｇｕｉｄｅ）、ＮＲＴコンテンツ等が含まれる。
　ＥＳＧは、電子サービスガイド（Ｅｌｅｃｔｒｏｎｉｃ　Ｓｅｒｖｉｃｅ　Ｇｕｉｄｅ）であり、例えば番組表等の案内情報である。
　ＮＲＴコンテンツはノンリアルタイム型のコンテンツである。
　ＮＲＴコンテンツには、例えば、クライアントである受信装置３０のブラウザ上で実行される様々なアプリケーションや、動画、静止画等のデータファイル等が含まれる。
　図２に示す以下のデータ、すなわち、
　（ａ）シグナリングデータ５０
　（ｂ）ＡＶセグメント６０
　（ｃ）その他のデータ（ＥＳＧ，ＮＲＴコンテンツ等）７０
　これらのデータは、例えば、データ通信プロトコル：ＦＬＵＴＥ（Ｆｉｌｅ　Ｄｅｌｉｖｅｒｙ　ｏｖｅｒ　Ｕｎｉ－ｄｉｒｅｃｔｉｏｎａｌ　Ｔｒａｎｓｐｏｒｔ）に従って送信される。
　　［２．データ通信プロトコルＦＬＵＴＥ、およびＲＯＵＴＥについて］
　データ通信プロトコル：ＦＬＵＴＥ（Ｆｉｌｅ　Ｄｅｌｉｖｅｒｙ　ｏｖｅｒ　Ｕｎｉ－ｄｉｒｅｃｔｉｏｎａｌ　Ｔｒａｎｓｐｏｒｔ）はマルチキャストにより伝送するコンテンツのセッション管理を行うプロトコルである。
　例えば送信装置であるサーバ側で生成されるファイル（ＵＲＬとバージョンで識別される）は、ＦＬＵＴＥプロトコルに従って、受信装置であるクライアントに送信される。
　受信装置（クライアント）３０は、例えば記憶部（クライアントキャッシュ）に、受信ファイルのＵＲＬおよびバージョンとファイルを対応付けて蓄積する。
　同じＵＲＬでバージョンが異なるものはファイルの中身が更新されているものとみなす。ＦＬＵＴＥプロトコルは一方向ファイル転送制御のみを行うもので、クライアントにおけるファイルの選択的なフィルタリング機能はないが、ＦＬＵＴＥで転送制御するファイルをそのファイルに紐づけられるメタデータを利用して、クライアント側で取捨選択することにより、選択的なフィルタリングを実現し、ユーザの嗜好を反映したローカルキャッシュを構成・更新管理することが可能となる。
　なお、メタデータは、ＦＬＵＴＥプロトコルに拡張して組み込むこともできるし、別途ＥＳＧ（Ｅｌｅｃｔｒｏｎｉｃ　Ｓｅｒｖｉｃｅ　Ｇｕｉｄｅ）等のプロトコルで記述することもできる。
　なお、ＦＬＵＴＥは、当初マルチキャストにおけるファイル転送プロトコルとして仕様化された。ＦＬＵＴＥは、ＦＤＴと、ＡＬＣと呼ばれるスケーラブルなファイルオブジェクトのマルチキャストプロトコル、具体的にはそのビルディングブロックであるＬＣＴやＦＥＣコンポーネント、の組み合わせにより構成される。
　従来のＦＬＵＴＥは、主に非同期型のファイル転送に利用するために開発されたが、現在、放送波およびネットワークを介したデータ配信システムに関する規格化団体であるＡＴＳＣ（Ａｄｖａｎｃｅｄ　Ｔｅｌｅｖｉｓｉｏｎ　Ｓｙｓｔｅｍ　Ｃｏｍｍｉｔｔｅ）において、ブロードキャストライブストリーミングにも適用しやすくするための拡張を行っている。このＦＬＵＴＥの拡張仕様がＲＯＵＴＥ（Ｒｅａｌ－Ｔｉｍｅ　Ｏｂｊｅｃｔ　Ｄｅｌｉｖｅｒｙ　ｏｖｅｒ　Ｕｎｉｄｉｒｅｃｔｉｏｎａｌ　Ｔｒａｎｓｐｏｒｔ）と呼ばれる。
　放送波およびネットワークを介したデータ配信システムに関する規格の１つとして現在、標準化が進められている規格としてＡＴＳＣ（Ａｄｖａｎｃｅｄ　Ｔｅｌｅｖｉｓｉｏｎ　Ｓｙｓｔｅｍ　Ｃｏｍｍｉｔｔｅ）３．０がある。このＡＴＳＣ３．０は、ＲＯＵＴＥを従来のＦＬＵＴＥプロトコルに置き換えて、シグナリングデータや、ＥＳＧ、あるいは非同期ファイル、同期型ストリーム等の送信に採用したスタック構成を規定している。
　　［３．送信装置と受信装置の実行する通信処理例について］
　次に、送信装置と受信装置の実行する通信処理例について説明する。
　図３は、送信装置および受信装置のプロトコルスタックの例を示す図である。
　図３に示す例は、以下の２つの通信データの処理を行なうための２つのプロトコルスタックを有する。
　（ａ）ブロードキャスト（マルチキャストも含む）通信（例えば放送型データ配信）
　（ｂ）ユニキャスト（ブロードバンド）通信（例えばＨＴＴＰ型のＰ２Ｐ通信）
　図３の左側が（ａ）ブロードキャスト通信（例えば放送型データ配信）に対応するプロトコルスタックである。
　図３の右側が、（ｂ）ユニキャスト（ブロードバンド）通信（例えばＨＴＴＰ型のＰ２Ｐ通信）に対応するプロトコルスタックである。
　図３左側に示す（ａ）ブロードキャスト通信（例えば放送型データ配信）に対応するプロトコルスタックは、下位レイヤから順に、以下のレイヤを持つ。
　（１）ブロードキャスト物理レイヤ（Ｂｒｏａｄｃａｓｔ　ＰＨＹ）
　（２）ＩＰマルチキャストレイヤ（ＩＰ　Ｍｕｌｔｉｃａｓｔ）
　（３）ＵＤＰレイヤ
　（４）ＲＯＵＴＥ（＝拡張型ＦＬＵＴＥ）レイヤ
　（５）ＥＳＧ，ＮＲＴｃｏｎｔｅｎｔ，ＤＡＳＨ（ＩＳＯ　ＢＭＦＦ）およびＶｉｄｅｏ／Ａｕｄｉｏ／ＣＣ
　（６）アプリケーションレイヤ（Ａｐｐｌｉｃａｔｉｏｎｓ（ＨＴＭＬ５（ＨｙｐｅｒＴｅｘｔ　Ｍａｒｋｕｐ　Ｌａｎｇｕａｇｅ　５））
　なお、（２）ＩＰマルチキャストレイヤ（ＩＰ　Ｍｕｌｔｉｃａｓｔ）の上位レイヤとしてシグナリング（Ｓｉｇｎａｌｉｎｇ）レイヤが設定される。
　シグナリングレイヤは、先に図２を参照して説明したシグナリングデータ５０の送受信に適用されるレイヤである。シグナリングデータには、番組表等の番組予定情報や、番組取得に必要となるアドレス情報（ＵＲＬ等）、さらにコンテンツの再生処理に必要な情報、例えばコーデック情報（符号化方式など）などからなる案内情報、制御情報などが含まれる。
　シグナリングデータは、受信装置（クライアント）が受信、再生するＡＶセグメントのアクセス情報や、復号処理等の受信後の処理に必要となる案内情報や制御情報を含むデータであり、送信装置から随時繰り返し送信されるデータである。
　シグナリングデータには、情報に応じた様々な種類がある。具体的には、例えば、サービス単位のシグナリングデータであるＵＳＤ（ユーザサービスディスクリプション（Ｕｓｅｒ　Ｓｅｒｖｉｃｅ　Ｄｅｓｃｒｉｐｔｉｏｎ））がある。
　ＵＳＤには、様々な種類の制御情報が含まれる。代表的な制御情報として、コンテンツ（ＡＶセグメント）に対応する様々な案内情報、制御情報を格納したマニフェスト・ファイルを持つシグナリングデータであるＭＰＤ（メディアプレゼンテーションディスクリプション（Ｍｅｄｉａ　Ｐｒｅｓｅｎｔａｔｉｏｎ　Ｄｅｓｃｒｉｐｔｉｏｎ））がある。
　各種のシグナリングデータは、それぞれ受信装置（クライアント）において、送信装置から送信されるＡＶセグメントやアプリケーション（アプリケーションプログラム）の受信、再生処理、制御処理に必要となるデータであり、例えばカテゴリ別に個別のファイル（メタファイル）として設定され、送信装置から送信される。
　なお、（１）ブロードキャスト物理レイヤ（Ｂｒｏａｄｃａｓｔ　ＰＨＹ）の上位レイヤとして将来の新たなプロトコルの利用許容レイヤ（Ｆｕｔｕｒｅ　Ｅｘｔｅｎｓｉｂｉｌｉｔｙ）が設定されている。
　（１）ブロードキャスト物理レイヤ（Ｂｒｏａｄｃａｓｔ　ＰＨＹ）は、ブロードキャスト通信を実行するための例えば放送系の通信部を制御する通信制御部によって構成される物理レイヤである。
　（２）ＩＰマルチキャストレイヤ（ＩＰ　Ｍｕｌｔｉｃａｓｔ）は、ＩＰマルチキャストに従ったデータ送受信処理を実行するレイヤである。
　（３）ＵＤＰレイヤは、ＵＤＰパケットの生成、解析処理レイヤである。
　（４）ＲＯＵＴＥレイヤは、拡張型ＦＬＵＴＥプロトコルであるＲＯＵＴＥプロトコルにしたがって転送データの格納や取り出しを行うレイヤである。
　ＲＯＵＴＥは、ＦＬＵＴＥと同様、ＡＬＣと呼ばれるスケーラブルなファイルオブジェクトのマルチキャストプロトコルであり、具体的にはそのビルディングブロックであるＬＣＴやＦＥＣコンポーネントの組み合わせにより構成される。
　図４に、ＲＯＵＴＥ、およびＦＬＵＴＥに関するプロトコルスタックを示す。
　（５）ＥＳＧ，ＮＲＴｃｏｎｔｅｎｔ，ＤＡＳＨ（ＩＳＯ　ＢＭＦＦ）およびＶｉｄｅｏ／Ａｕｄｉｏ／ＣＣは、ＲＯＵＴＥプロトコルに従って転送されるデータである。
　ＤＡＳＨ規格に従った同報型配信サービスは、ＭＢＭＳ（Ｍｕｌｔｉｍｅｄｉａ　Ｂｒｏａｄｃａｓｔ　Ｍｕｌｔｉｃａｓｔ　Ｓｅｒｖｉｃｅ）と呼ばれる。このＭＢＭＳをＬＴＥで効率的に実現させる方式としてｅＭＢＭＳ（ｅｖｏｌｖｅｄ　Ｍｕｌｔｉｍｅｄｉａ　Ｂｒｏａｄｃａｓｔ　Ｍｕｌｔｉｃａｓｔ　Ｓｅｒｖｉｃｅ）がある。
　ＭＢＭＳやｅＭＢＭＳは、同報型配信サービスであり、特定のエリア内に位置する受信装置である複数のユーザ端末（ＵＥ）に対して共通のベアラで一斉に同一データ、例えば映画コンテンツなどを配信するサービスである。ＭＢＭＳやｅＭＢＭＳに従った同報配信により、配信サービス提供エリアに位置する多数のスマホやＰＣ、あるいはテレビ等の受信装置に、同じコンテンツを同時に提供することができる。
　ＭＢＭＳ、およびｅＭＢＭＳは、３ＧＰＰファイルフォーマット（ＩＳＯ－ＢＭＦＦファイル、ＭＰ４ファイル）に従ったファイルを、転送プロトコルＲＯＵＴＥ、またはＦＬＵＴＥに従ってダウンロードする処理について規定している。
　先に図２を参照して説明した以下のデータ、すなわち、
　（ａ）シグナリングデータ５０
　（ｂ）ＡＶセグメント６０
　（ｃ）その他のデータ（ＥＳＧ、ＮＲＴコンテンツ等）７０
　これらのデータの多くはＲＯＵＴＥプロトコル、またはＦＬＵＴＥプロトコルに従って送信される。
　（５）ＥＳＧ，ＮＲＴｃｏｎｔｅｎｔ，ＤＡＳＨ（ＩＳＯ　ＢＭＦＦ）およびＶｉｄｅｏ／Ａｕｄｉｏ／ＣＣは、ＲＯＵＴＥプロトコルに従って転送されるデータである。
　ＥＳＧは、電子サービスガイド（Ｅｌｅｃｔｒｏｎｉｃ　Ｓｅｒｖｉｃｅ　Ｇｕｉｄｅ）であり、例えば番組表等の案内情報である。
　ＮＲＴｃｏｎｔｅｎｔはノンリアルタイム型のコンテンツである。
　前述したように、ＮＲＴコンテンツには、例えば、クライアントである受信装置のブラウザ上で実行される様々なアプリケーションファイル、動画、静止画等のデータファイル等が含まれる。
　Ｖｉｄｅｏ／Ａｕｄｉｏ／ＣＣは、ＤＡＳＨ規格に従って配信されるビデオやオディオ等、再生対象となる実データである。
　（６）アプリケーションレイヤ（Ａｐｐｌｉｃａｔｉｏｎｓ（ＨＴＭＬ５）は、ＲＯＵＴＥプロトコルに従って転送するデータの生成、あるいは解析、その他、様々なデータの出力制御等を実行するアプリケーションレイヤであり、例えばＨＴＭＬ５を適用したデータ生成、解析、出力処理等を行う。
　一方、図３の右側に示す、（ｂ）ユニキャスト（ブロードバンド）通信（例えばＨＴＴＰ型のＰ２Ｐ通信）に対応するプロトコルスタックは、下位レイヤから順に、以下のレイヤを持つ。
　（１）ブロードバンド物理レイヤ（Ｂｒｏａｂａｎｄ　ＰＨＹ）
　（２）ＩＰユニキャストレイヤ（ＩＰ　Ｕｎｉｃａｓｔ）
　（３）ＴＣＰレイヤ
　（４）ＨＴＴＰレイヤ
　（５）ＥＳＧ，Ｓｉｇｎａｌｉｎｇ，ＮＲＴｃｏｎｔｅｎｔ，ＤＡＳＨ（ＩＳＯ　ＢＭＦＦ）およびＶｉｄｅｏ／Ａｕｄｉｏ／ＣＣ
　（６）アプリケーションレイヤ（Ａｐｐｌｉｃａｔｉｏｎｓ（ＨＴＭＬ５））
　（１）ブロードバンド物理レイヤ（Ｂｒｏａｂａｎｄ　ＰＨＹ）は、ブロードバンド通信を実行する例えばネットワークカード等の通信部を制御するデバイスドライバ等の通信制御部によって構成される物理レイヤである。
　（２）ＩＰユニキャストレイヤ（ＩＰ　Ｕｎｉｃａｓｔ）は、ＩＰユニキャスト送受信処理を実行するレイヤである。
　（３）ＨＴＴＰレイヤは、ＨＴＴＰパケットの生成、解析処理レイヤである。
　この上位レイヤは、図３左側の（ａ）ブロードキャスト通信（例えば放送型データ配信）のスタック構成と同様である。
　なお、送信装置（サーバ）２０、受信装置（クライアント）３０は、図３の２つの処理系、すなわち、
　（ａ）ブロードキャスト通信（例えば放送型データ配信）
　（ｂ）ユニキャスト（ブロードバンド）通信（例えばＨＴＴＰ型のＰ２Ｐ通信）
　これら２つの通信プロトコルスタックの少なくともいずれかに従った処理を行なう。
　図３に示すプロトコルスタックにおいて、ＲＯＵＴＥ（ＦＬＵＴＥ）に従ってマルチキャスト転送されるファイル群の属性（ファイルの識別子であるＵＲＬを含む）は、ＲＯＵＴＥ（ＦＬＵＴＥ）の制御ファイル内に記述することもできれば、ファイル転送セッションを記述するシグナリング（Ｓｉｇｎａｌｉｎｇ）データ中に記述することもできる。また、ファイル転送セッションのさらなる詳細属性を（エンドユーザへの提示用途にも適用可能な）ＥＳＧにより記述することもできる。
　前述したように、放送波およびネットワークを介したデータ配信システムに関する規格の１つとしてＡＴＳＣ（Ａｄｖａｎｃｅｄ　Ｔｅｌｅｖｉｓｉｏｎ　Ｓｙｓｔｅｍ　Ｃｏｍｍｉｔｔｅ）３．０の規格化が進められている。
　ＡＴＳＣ３．０におけるＩＰベースのトランスポートスタックの標準化において、ＭＰＥＧ－ＤＡＳＨのファイルフォーマット（ＩＳＯ－ＢＭＦＦファイル、ＭＰ４ファイル）に基づくファイルをＦＬＵＴＥ（Ｆｉｌｅ　Ｄｅｌｉｖｅｒｙ　ｏｖｅｒ　Ｕｎｉｄｉｒｅｃｔｉｏｎａｌ　Ｔｒａｎｓｐｏｒｔ）を拡張したＲＯＵＴＥ（Ｒｅａｌ－Ｔｉｍｅ　Ｏｂｊｅｃｔ　Ｄｅｌｉｖｅｒｙ　ｏｖｅｒ　Ｕｎｉｄｉｒｅｃｔｉｏｎａｌ　Ｔｒａｎｓｐｏｒｔ）プロトコルにより転送する方法が提案され、標準候補方式として設定された。
　ＲＯＵＴＥプロトコルを適用することで、ＤＡＳＨ規格のフラグメント化されたＭＰ４（ｆｒａｇｍｅｎｔｅｄ　ＭＰ４）ファイルシーケンスと、ＤＡＳＨ規格の制御情報（シグナリングデータ）格納メタファイルであるＭＰＤ（Ｍｅｄｉａ　Ｐｒｅｓｅｎｔａｔｉｏｎ　Ｄｅｓｃｒｉｐｔｉｏｎ））、ならびに、放送配信のためのシグナリングデータである、
　ＵＳＢＤ／ＵＳＤ（Ｕｓｅｒ　Ｓｅｒｖｉｃｅ　Ｂｕｎｂｄｌｅ　Ｄｅｓｃｒｉｐｔｉｏｎ／Ｕｓｅｒ　Ｓｅｒｖｉｃｅ　Ｄｅｓｃｒｉｐｔｉｏｎ）、
　Ｓ－ＴＳＩＤ（Ｓｅｒｖｉｃｅ　ｂａｓｅｄ　Ｔｒａｎｓｐｏｒｔ　Ｓｅｓｓｉｏｎ　Ｄｅｓｃｒｉｐｔｉｏｎ）、
　例えば、これらのシグナリンクデータ等を転送することができる。
　ＵＳＤは、例えば放送局、あるいは番組など、所定のサービス単位の情報から構成され、サービスを受領するためのアクセス情報（ＵＲＬ等）、コーデック情報、再生タイミング情報等、受信装置においてサービスを利用するために必要となる情報から構成される。ＵＳＢＤは、ＵＳＤの束（バンドル）である。
　Ｓ－ＴＳＩＤは、各サービス単位の付加情報であり、ＵＳＤに記録されない付加的な情報が記録される。
　前述したように、ＲＯＵＴＥプロトコルはＦＬＵＴＥをベースとするプロトコルである。ＦＬＵＴＥにおける転送制御パラメータを記述したメタデータファイルをＦＤＴ（Ｆｉｌｅ　Ｄｅｌｉｖｅｒｙ　Ｔａｂｌｅ）と呼び、ＲＯＵＴＥにおける転送制御パラメータを記述したメタデータファイルをＳ－ＴＳＩＤ（Ｓｅｒｖｉｃｅ　ｂａｓｅｄ　Ｔｒａｎｓｐｏｒｔ　Ｓｅｓｓｉｏｎ　Ｄｅｓｃｒｉｐｔｉｏｎ）と呼ぶ。Ｓ－ＴＳＩＤはＦＤＴのスーパーセットでありＦＤＴを含む。
　ＡＴＳＣ３．０サービスレイヤのシグナリングデータ（ＳＬＳ：Ｓｅｒｖｉｃｅ　Ｌａｙｅｒ　Ｓｉｇｎａｌｉｎｇ）として提案されているＵＳＢＤ／ＵＳＤ、Ｓ－ＴＳＩＤ、ＭＰＤ等はすべてＲＯＵＴＥセッションにより転送される。
　なお、ＡＴＳＣ３．０に従った放送サービスにおいては、上述したＲＯＵＴＥプロトコルの他、ＭＭＴ（ＭＰＥＧ　Ｍｅｄｉａ　Ｔｒａｎｓｐｏｒｔ）を適用した通信も利用可能である。
　　［４．受信装置におけるアプリケーションを適用したデータ出力例について］
　次に、放送サーバ２１等の送信装置２０から様々な番組コンテンツや、アプリケーション等のデータを受信して、出力する受信装置（クライアント）３０におけるデータ出力例について説明する。
　図５は、受信装置３０が、放送サーバ２１等の送信装置２０から、ある番組コンテンツを受信し、受信装置３０の表示部に表示している状態を示している。
　放送サーバ２１等の送信装置２０は、番組配信に併せて、ＮＲＴコンテンツ（ノンリアルタイムコンテンツ）として、天気情報を表示するアプリケーション、およびこの天気情報表示アプリケーションに利用される様々なデータファイル、例えば動画、静止画、音声等の様々なデータを含むデータファイルを受信装置３０に提供する。
　以下では、これらのアプリケーションおよびデータファイルを「リソース」と呼ぶ。
　受信装置３０は、送信装置２０から受信した「リソース」、すなわちアプリケーションの構成するデータファイルを利用して、図５に示すように、番組表示に併せて、天気情報の表示を行うことができる。
　このような、アプリケーションを利用したデータ表示を行うためには、アプリケーションを構成する全てのファイル、例えば、
　ＨＴＭＬ（ＨｙｐｅｒＴｅｘｔ　Ｍａｒｋｕｐ　Ｌａｎｇｕａｇｅ）ファイル、
　動画ファイル、
　音声ファイル、
　スタイルシート、
　例えば、これらのアプリケーション構成ファイルを全て取得し、受信装置３０の記憶部であるキャッシュ部に格納しておくことが必要となる。
　しかし、例えば、受信装置のキャッシュ容量が不足して、一部の動画ファイルがキャッシュできないといっち状態が発生し、この状態でアプリケーションを実行すると、キャッシュできなかった動画の再生領域が空白となった不完全なアプリケーションが実行される事態が発生する。
　次に、図６を参照して、受信装置３０が、送信装置２０から受信するアプリケーションを広告表示に利用した例について説明する。
　受信装置３０には、図６下部に示すタイムライン（時間軸（ｔ））に従って、例えば映画やニュース、その他の放送番組（メインコンテンツ）と広告が交互に出力される。
　ユーザが選択したあるチャンネルの番組開始時間をｔ０とすると、以下のように、間推移に従って放送番組と広告が交互に出力される。
　時間ｔ０～ｔ１：広告
　時間ｔ１～ｔ２：放送番組
　時間ｔ２～ｔ３：広告
　時間ｔ３～ｔ４：放送番組
　時間ｔ４～ｔ５：広告
　時間ｔ５～：放送番組
　ここで、受信装置３０に出力される広告は、送信装置２０が送信する番組コンテンツとは別に送信するアプリケーションを利用して表示される。送信装置２０は、様々なユーザに応じた広告、いわゆるターゲット広告を表示する複数の広告アプリケーションをＮＲＴ（ノンリアルタイム）コンテンツとして受信装置３０に送信する。例えば、
　（ａ）子供向けのゲームの広告表示アプリケーション、
　（ｂ）若者向けのファッションアイテムの広告アプリケーション、
　（ｃ）大人向けのアルコール飲料の広告アプリケーション、
　送信装置２０は、例えば、このような様々なユーザ（視聴者）向けの広告アプリケーションを受信装置３０に対して送信する。
　受信装置３０は、受信装置３０側で設定したユーザ（視聴者）情報に基づいて、ユーザに最適な広告を選択取得し、出力する。
　ユーザ情報とは、例えば、ユーザ（視聴者）の年齢、性別、住所、趣味嗜好など、さまざまな情報である。
　これらのユーザ情報は、受信装置の記憶部に予め登録した情報を用いる。
　あるいは、番組開始時点で、ユーザ（視聴者）にユーザ情報を入力させ、この入力情報を用いる構成としてもよい。
　受信装置３０が、例えば放送波を介して取得するアプリケーションは、前述したように、様々なデーファイルによって構成される。すなわち、前述したように、
　ＨＴＭＬ（ＨｙｐｅｒＴｅｘｔ　Ｍａｒｋｕｐ　Ｌａｎｇｕａｇｅ）ファイル、
　動画ファイル、
　音声ファイル、
　スタイルシート、
　例えば、これらの複数のアプリケーション構成ファイルを全て取得し、受信装置３０の記憶部であるキャッシュ部に格納した後に、アプリケーションの実行を開始することで、完全な広告再生を行なうことができる。
　アプリケーション構成ファイルのキャッシュ処理を確実に実行するためには、受信装置３０は、自装置のキャッシュ空き容量と、取得予定のアプリケーションのデータサイズを比較した上で、キャッシュ可能なデータを選択的に取得してキャッシュ処理を開始することが重要となる。
　このようなキャッシュ制御を実行することで、キャッシュ処理を開始したデータは、確実に受信装置３０のキャッシュ部（記憶部）に格納することができる。
　このようなキャッシュ制御を行わずに、キャッシュ処理を開始してしまうと、キャッシュ処理の途中で、キャッシュ部（記憶部）が溢れ、データの一部がキャッシュできないといった事態が発生する可能性がある。
　本開示の受信装置３０は、自装置のキャッシュ空き容量と、取得予定のアプリケーションのデータサイズを比較した上で、キャッシュ可能なデータを選択的に取得してキャッシュ処理を開始するキャッシュ制御を実行する。
　このキャッシュ制御処理の具体的構成については後述する。
　なお、図５、図６を参照して説明したアプリケーションの例は一例であり、送信装置２０は、受信装置３０に対して提供するアプリケーションは、図５、図６を参照して説明した例以外にも様々なアプリケーションがある。
　例えば、ニュース情報提供アプリ、野球中継時の選手情報提供アプリ、旅番組における地図情報、ホテル情報、クイズ、アンケート処理等を実行するアプリケーション等、様々なアプリケーションがある。
　　［５．受信装置の構成例と処理例について］
　次に、図７以下を参照して受信装置３０の構成例と処理例について説明する。
　なお、受信装置３０は、先に図１を参照して説明したように、テレビ３１、ＰＣ３２、携帯端末３３、あるいは、その他、例えば、スマートフォン、タブレット端末、スマートウォッチ、ウェアラブルデバイス等、様々な機器によって構成される。
　図７に示す受信装置３０は、放送サーバや、広告サーバ等の送信装置２０からの送信データを受信するミドルウェア１１０と、受信データの解析やキャッシュ処理を実行するプロキシサーバ１２０、番組再生やアプリケーション実行によるデータ再生処理を実行するデータ再生部１３０を有する。
　放送サーバや、広告サーバ等の送信装置２０は、放送波や、インターネット等の通信ネットワークを介したデータ送信により、放送コンテンツ等からなるＡＶセグメント、アプリケーション、シグナリングデータ、その他のデータを送信する。
　図７に示す受信装置３０のミドルウェア１１０は、送信装置２０から放送波を介した提供データを受信し、解析する。
　ミドルウェア１１０は、通信部（ＰＨＹ／ＭＡＣ）１１１、シグナリングデータを取得するシグナリング取得部１１２、シグナリングデータを解析するシグナリング解析部１１３、シグナリングデータ、および、映像、音声等の番組コンテンツデータや、アプリケーション等のＮＲＴコンテンツ等のデータファイルを取得するセグメント取得部１１４を有する。
　ミドルウェア１１０が受信したデータは、プロキシサーバ１２０のキュッシュ制御部１２１介してキャッシュ部（プロキシキャッシュ）１２２に格納される。プロキシサーバ１２０は、さらにネットワーク経由で送信装置２０から取得したデータをキャッシュ部１２２に格納する。
　プロキシサーバ１２０のキャッシュ制御部１２１は、データ再生部１３０の再生制御部（ＤＡＳＨ　Ｃｌｉｅｎｔ）１３１や、アプリケーション制御部１３２からのデータ取得要求を入力し、要求データをデータ再生部に提供する。
　例えば、キャッシュ制御部１２１は、再生制御部（ＤＡＳＨ　Ｃｌｉｅｎｔ）１３１や、アプリケーション制御部１３２からのデータ取得要求に応じたアドレス解決処理等を行い、アドレスに応じたデータをキャッシュ部１２１から取得して、データ再生部１３０の再生制御部（ＤＡＳＨ　Ｃｌｉｅｎｔ）１３１や、アプリケーション制御部１３２に出力する。なお、キャッシュ部１２２に要求データが格納されていない場合は、外部から取得して提供する場合もある。
　データ再生部１３０の再生制御部（ＤＡＳＨ　Ｃｌｉｅｎｔ）１３１は、ＤＡＳＨ（ＭＰＥＧ－ＤＡＳＨ）規格に従って送信されたコンテンツの再生制御を実行する。
　前述したように、ＭＰＥＧ－ＤＡＳＨ規格には、以下の２つの規格が含まれる。
　（ａ）動画や音声ファイルの管理情報であるメタデータを記述するためのマニフェスト・ファイル（ＭＰＤ：Ｍｅｄｉａ　Ｐｒｅｓｅｎｔａｔｉｏｎ　Ｄｅｓｃｒｉｐｔｉｏｎ）に関する規格、
　（ｂ）動画コンテンツ伝送用のファイル・フォーマット（セグメント・フォーマット）に関する規格、
　送信装置２０から、受信装置３０に対するコンテンツ配信は、上記のＭＰＥＧ－ＤＡＳＨ規格に従って実行される。
　コンテンツは、例えばＭＰＥＧにおいて規定されるＭＰ４ファイルフォーマットに従って所定単位の分割データであるセグメント（ＡＶセグメント等）として送信され、再生制御部（ＤＡＳＨ　Ｃｌｉｅｎｔ）１３１は、マニフェスト・ファイル（ＭＰＤ）を参照して、再生対象コンテンツを格納したセグメントを取得する処理等を実行する。
　アプリケーション制御部１３２は、例えば、先に図５、図６を参照して説明した天気予報、広告のアプリケーション等、送信装置２０から提供されるアプリケーションの実行、開始、終了等の制御を行う。
　出力制御部１３３は、再生制御部１３１やアプリケーション制御部１３２から提供される番組構成データやアプリケーション実行用データを取得し、取得データの復号処理や、表示部への出力処理等を実行する。
　なお、再生制御部（ＤＡＳＨ　Ｃｌｉｅｎｔ）１３１や、アプリケーション制御部１３２は、送信装置２０（放送サーバ２１、広告サーバ２２等）が送信するシグナリングデータを参照し、シグナリングデータに記述された情報に従って必要なデータをプロキシサーバ１２０から取得し、また、シグナリングデータに記述された情報に従って再生制御やアプリケーション制御を実行する。
　先に図２を参照して説明したように、シグナリングデータ５０は、番組表等の番組予定情報や、番組取得に必要となるアドレス情報（ＵＲＬ（Ｕｎｉｆｏｒｍ　Ｒｅｓｏｕｒｃｅ　Ｌｏｃａｔｏｒ）等）、さらにコンテンツの再生処理に必要な情報、例えばコーデック情報（符号化方式など）などからなる案内情報、アプリケーション制御情報等の様々な制御情報によって構成される。
　再生制御部（ＤＡＳＨ　Ｃｌｉｅｎｔ）１３１や、アプリケーション制御部１３２は、シグナリングデータ（ＳＬＳ：Ｓｅｒｖｉｃｅ　Ｌａｙｅｒ　Ｓｉｇｎａｌｉｎｇ）を取得して取得したシグナリングデータに基づくデータ取得処理や、データ再生制御や、アプリケーション実行制御等を実行する。
　例えば、アプリケーション制御部１３２は、アプリケーション対応の属性情報や制御情報を記録した様々なシグナリングデータに基づくアプリケーション制御を実行する。具体的には、例えば、ＡＴＳＣ３．０のシグナリングデータであるＵＳＢＤ／ＵＳＤや、Ｓ－ＴＳＩＤ、あるいは、個々のアプリケーションに対応する属性情報や制御情報を記録したアプリケーション・インフォーメーション・テーブル（ＡＩＴ：Ａｐｐｌｉｃａｔｉｏｎ　Ｉｎｆｏｒｍａｔｉｏｎ　Ｔａｂｌｅ）などを利用したアプリケーション制御を実行する。
　なお、再生制御部（ＤＡＳＨ　Ｃｌｉｅｎｔ）１３１や、アプリケーション制御部１３２は、プロキシサーバ１２０のキャッシュ部１２２に格納されたデータを利用した処理を実行する。
　キャッシュ部１２２に格納されるデータは、ミドルウェア（Ｃｌｉｅｎｔ　Ｌｏｃａｌ　ＡＴＳＣ　Ｍｉｄｄｌｅｗａｒｅ）１１０が受信したデータや、プロキシサーバ１２０がネットワークを介して受信したデータである。
　ミドルウェア１１０、またはプロキシサーバ１２０が放送波あるいは通信ネットワークを介して取得するデータは、例えば、ＤＡＳＨ－ＭＰＤファイルやＤＡＳＨセグメント（ｓｅｇｍｅｎｔ）ファイル、その他一般のアプリケーションファイル、ならびに、シグナリングデータを格納したＳＬＳ（Ｓｅｒｖｉｃｅ　ｌｅｖｅｌ　Ｓｉｇｎａｌｉｎｇ）ファイル等である。
　これらは、キャッシュ制御部１２１の制御に基づいてキャッシュ部１２２に格納される。
　その後、キャッシュ制御部１２１は、再生制御部（ＤＡＳＨ　Ｃｌｉｅｎｔ）１３１や、アプリケーション制御部１３２の要求に応じて、キャッシュ部１２２から要求データを取得して、再生制御部（ＤＡＳＨ　Ｃｌｉｅｎｔ）１３１や、アプリケーション制御部１３２に提供され、ストリームのレンダリングや、アプリケーションの実行等のデータ再生処理に利用される。
　再生制御部（ＤＡＳＨ　Ｃｌｉｅｎｔ）１３１や、アプリケーション制御部１３２がセグメント（ｓｅｇｍｅｎｔ）ファイル、その他一般のアプリケーションファイル、ならびに、シグナリングデータファイルの取得を、プロキシサーバ１２０のキャッシュ制御部１２１に対して要求（ＨＴＴＰリクエスト）すると、それを受けたプロキシサーバ１２０のキャッシュ制御部１２１は、キャッシュ部１２２からデータ取得を行う。なお、キャッシュ部１２２にデータがない場合は、放送、またはネット経由での取得処理を行う。
　また、再生制御（ＤＡＳＨ　Ｃｌｉｅｎｔ）１３１や、アプリケーション制御部１３２は、コンテンツの再生、アプリケーションの制御情報等を記録したシグナリングデータを取得する。これらは、シグナリング取得部（ＳＬＳ　Ｓｉｇｎａｌｉｎｇ　Ｒｅｔｒｉｅｖｅｒ）１１２によって取得される。
　例えば、ＵＳＢＤ／ＵＳＤや、ＡＩＴや、Ｓ－ＴＳＩＤ、ＭＰＤ等の様々なシグナリングデータが取得され、利用される。
　シグナリング取得部（ＳＬＳ　Ｓｉｇｎａｌｉｎｇ　Ｒｅｔｒｉｅｖｅｒ）１１２は、通信部（ＡＴＳＣチューナ：ＡＴＳＣ３．０　ＰＨＹ／ＭＡＣ）１１１を介して放送受信するＳＬＳ　ＬＣＴパケットにより運ばれるシグナリングデータを抽出する。
　これらのシグナリングデータは、ミドルウェア１１０のシグナリング取得部１１２によって取得され、シグナリング解析部（ＳＬＳ　Ｓｉｇｎａｌｉｎｇ　Ｐａｒｓｅｒ）１１３において解析される。
　シグナリングデータには、例えば、番組再生に必要となるＡＶセグメントや、アプリケーションの実行に必要となる様々なデータファイル（リソース）等を取得するためのアドレス情報（ＵＲＬ）が含まれ、シグナリング解析部１１３は、必要となるセグメントやリソースファイルを取得するアドレス情報（放送配信アドレス情報）の取得処理などを行う。
　この放送配信アドレス情報に基づいて、所望のファイルが格納されたＬＣＴパケットを放送ストリームから取得し、取得データがプロキシサーバ１２０のキャッシュ部１２２内に展開される。
　なお、プロキシサーバ１２０のキャッシュ制御部１２１は、アプリケーションの取得、キャッシュ処理に際して、キャッシュ部１２２のキャッシュ可能なデータ容量を確認し、さらに、シグナリングデータからアプリケーションサイズや、アプリケーションの構成要素単位のデータサイズを取得して、キャッシュ可能なデータを選択してキャッシュ処理を実行する。このキャッシュ処理については、後段で詳細に説明する。
　　［６．アプリケーションの構成例について］
　先に図５、図６を参照して説明したように、受信装置３０は、送信装置２０から例えば放送波を介して様々なアプリケーションを受信し、受信したアプリケーションを実行する。
　送信装置２０が受信装置３０に提供するアプリケーションの構成例について、図８以下を参照して説明する。
　図８には、１つのアプリケーション（ＡＰＰ１）２００の構成例を示している。
　アプリケーション（ＡＰＰ１）２００は、１つ以上のプレゼンテーション・ユニット（ＰＵ：Ｐｅｒｅｓｅｎｔａｔｉｏｎ　Ｕｎｉｔ）２１０によって構成される。
　なお、１つのプレゼンテーション・ユニット（ＰＵ：Ｐｅｒｅｓｅｎｔａｔｉｏｎ　Ｕｎｉｔ）は、１つまたは複数のＨＴＭＬ（ＨｙｐｅｒＴｅｘｔ　Ｍａｒｋｕｐ　Ｌａｎｇｕａｇｅ）ファイル２１１と、このＨＴＭＬファイルを利用して提示されるデータファイル２１２のセットによって構成される。
　具体的には、例えば１つのプレゼンテーション・ユニット（ＰＵ）は、以下の構成要素からなるユニットである。
　（１）１つまたは複数のＨＴＭＬファイル
　（２）上記ＨＴＭＬに従って出力される画像（動画、静止画）ファイル、
　（３）上記ＨＴＭＬに従って出力される音声ファイル、
　（４）上記ＨＴＭＬに従ったデータ出力スタイルを規定したスタイルシート格納ファイル、
　例えば、上記構成要素によって１つのプレゼンテーション・ユニット（ＰＵ）が設定される。
　１つのプレゼンテーション・ユニット（ＰＵ）に属するデータが全て取得できれば、そのプレゼンテーション・ユニット（ＰＵ）に含まれるＨＴＭＬ文書によるデータ出力、例えばＷｅｂペーシの出力が完全な形で実行されることが保証される。
　なお、アプリケーション（ＡＰＰ１）２００は、１つ、または、複数のプレゼンテーション・ユニット（ＰＵ：Ｐｅｒｅｓｅｎｔａｔｉｏｎ　Ｕｎｉｔ）によって構成される。
　図８に示す例では、アプリケーション（ＡＰＰ１）２００は３つのプレゼンテーション・ユニット（ＰＵ１１（Ｇ１（グループ１））～ＰＵ３１（Ｇ３（グループ３）））を有している。
　１つのアプリケーション内の各プレゼンテーション・ユニット（ＰＵ）は、それぞれ異なるグループＩＤ（ｇｒｏｕｐＩｄ）が設定される。
　プレゼンテーション・ユニット（ＰＵ）の構成データ（ＨＤＭＬファイル、データファイル）の各々には、識別子としてグループＩＤが設定され、それぞれがどのＰＵに属するデータであるかを識別可能な構成となっている。
　また、プレゼンテーション・ユニット（ＰＵ１１（Ｇ１）～ＰＵ３１（Ｇ３））間にはリンクが設定される場合がある。図８に示す例では、プレゼンテーション・ユニット（ＰＵ１１（Ｇ１））のＨＴＭＬファイル２１１から、プレゼンテーション・ユニット（ＰＵ２１（Ｇ２））のＨＴＭＬファイルへのリンク２１３ａが設定されている。
　また、プレゼンテーション・ユニット（ＰＵ１１（Ｇ１））のＨＴＭＬファイルから、プレゼンテーション・ユニット（ＰＵ３１（Ｇ３））のＨＴＭＬファイルへのリンク２１３ｂが設定されている。
　リンクが設定された２つのＰＵは、例えば、リンク元のプレゼンテーション・ユニット（ＰＵ）の実行中に、何らかのイベントをトリガとして、リンク先のプレゼンテーション・ユニットの実行を開始するというＰＵの遷移を行う関係にある。
　例えばプレゼンテーション・ユニット（ＰＵ１１（Ｇ１））のＨＴＭＬ文書による表示データ中の一部の領域、例えばタグ等のアイコンの表示領域をユーザがクリックすると、このクリック処理が遷移実行イベントとして検出され、リンク先のプレゼンテーション・ユニット（ＰＵ２１（Ｇ２））のＨＴＭＬ文書に基づく表示データが表示されるといった処理が行われる。
　遷移イベントは、ユーザ操作に限らず、例えばアプリケーション・インフォメーション・テーブル（ＡＩＴ）等のシグナリングデータの記述等、例えば時間経過に基づくイベント等、様々なイベントがある。
　なお、アプリケーションの表示開始や、表示終了等を指定するコントロールコード、その他のアプリ制御情報は、アプリケーション対応のシグナリングデータであるアプリケーション・インフォメーション・テーブル（ＡＩＴ）に記録されており、受信装置３０のアプリケーション制御部１３２は、ＡＩＴの記録情報に従ってアプリケーションを実行する。
　なお、ＡＩＴには特定のアプリケーション（ＡＰＰ）の取得情報（ＵＲＬ等）や、アプリの実行態様を規定したコントロールコード、例えば、自動起動処理（ＡＵＴＯＳＴＡＲＴ）や、プリフェッチ（ｐｒｅｆｅｔｃｈ）等の様々なアプリの実行態様規定情報であるコントロールコードも記録されている。
　なお、アプリケーションには、個別のアプリケーションを識別する識別子であるアプリケーションＩＤが設定される。
　ＡＩＴ等のシグナリングデータには、アプリケーションＩＤとともに、そのアプリケーションに関する様々な情報、例えばアプリケーションサイズ情報や、アクセス情報や制御情報等が記録される。
　ＡＩＴ等のシグナリングデータに記録される情報の詳細については後段で説明する。
　図８に示すようにアプリケーションＩＤは、
　（ａ）組織ＩＤ（ｏｒｇＩｄ）、
　（ｂ）アプリ本体ＩＤ（ａｐｐＩｄ）、
　これらの２つのＩＤの連結データとして構成される。
　組織ＩＤは、アプリケーションを提供する放送局や、アプリケーションの制作者等の組織を示す識別子である。
　アプリ本体ＩＤは、アプリケーション本体各々に対応付けて設定される識別子である。
　例えばアプリケーションＩＤの前半の組織ＩＤを参照することで、アプリケーションを提供する放送局や、アプリケーションの制作者等の組織を確認することが可能となり、アプリケーションＩＤの後半のアプリ本体ＩＤを参照することで、１つの組織の提供する複数アプリの中の１つのアプリを個別に識別することが可能となる。
　また、アプリケーションの構成要素であるプレゼンテーション・ユニット（ＰＵ）にも、個別のプレゼンテーション・ユニット（ＰＵ）を識別する識別子であるプレゼンテーション・ユニットＩＤ（ＰＵＩＤ）が設定される。
　詳細は後述するが、プレゼンテーション・ユニット（ＰＵ）に関するアクセス情報等の属性情報を記録したＳ－ＴＳＩＤ等のシグナリングデータには、プレゼンテーション・ユニット（ＰＵ）に属する各ファイルに対応付けてプレゼンテーション・ユニットＩＤ（ＰＵＩＤ）が記録される。
　受信装置３０は、放送局等の送信装置２０の提供するシグナリングデータであるＳ－ＴＳＩＤを参照することで、送信装置２０１の提供する各ファイルがどのプレゼンテーション・ユニット（ＰＵ）に属するファイルであるかを識別することができる。
　なお、Ｓ－ＴＳＩＤには、各プレゼンテーション・ユニット（ＰＵ）単位のデータサイズも記録される。
　Ｓ－ＴＳＩＤ等のシグナリングデータに記録される情報の詳細については後段で説明する。
　図８に示すようにプレゼンテーション・ユニットＩＤ（ＰＵＩＤ）は、
　（ａ）アプリ本体ＩＤ（ａｐｐＩｄ）、
　（ｂ）グループＩＤ（ｇｒｏｕｐＩｄ）、
　これらの２つのＩＤを連結したデータとして構成される。
　アプリ本体ＩＤは、このプレゼンテーション・ユニットが属するアプリケーション本体に対応付けて設定される識別子である。
　前述のアプリケーションＩＤの構成要素となる「アプリ本体ＩＤ」と同一の値が設定されることになる。
　グループＩＤは、各プレゼンテーション・ユニット（ＰＵ）個別の識別子である。１つのアプリケーションに複数のプレゼンテーション・ユニット（ＰＵ）が含まれる場合、それぞれ異なるグループＩＤが設定される。
　プレゼンテーション・ユニットＩＤ（ＰＵＩＤ）の前半のアプリ本体ＩＤを参照することで、このプレゼンテーション・ユニットが属するアプリケーションを確認することが可能となり、プレゼンテーション・ユニットＩＤ（ＰＵＩＤ）の後半のグループＩＤを参照することで、１つのアプリケーションに含まれる複数のプレゼンテーション・ユニット（ＰＵ）を個別に識別することが可能となる。
　図８には、１つのアプリケーション（ＡＰＰ１）のみを示しているが、受信装置３０においてアプリケーションを実行する場合、複数のアプリケーションを利用した処理を行なう場合もある。
　具体的な例について、図９を参照して説明する。
　図９には、以下の３つのアプリケーションを示している。
　（１）アプリケーション１（ＡＰＰ１）
　（２）アプリケーション２（ＡＰＰ２）
　（３）アプリケーション３（ＡＰＰ３）
　図９に示す点線矢印はリンク関係を示している。
　リンクは、図８を参照して説明したように、各アプリケーション内のプレゼンテーション・ユニット（ＰＵ）間に設定されているとともに、図９に示す例では、各アプリケーション間にも設定されている。
　アプリケーション１～３を利用した処理において、最初に起動されるアプリケーションはアプリケーション１（ＡＰＰ１）であり、その中の１つのプレゼンテーション・ユニット（ＰＵ１１）のＨＴＭＬ文書が最初に起動されるＨＴＭＬ文書であるとする。
　なお、あるアプリの実行時に最初に利用されるＨＴＭＬ文書をエントリ文書と呼ぶ。
　図９に示す例では、アプリケーション１（ＡＰＰ１）のエントリ文書は、プレゼンテーション・ユニット（ＰＵ１１）のＨＴＭＬ文書である、すなわち図９に示すエントリ文書２２１である。
　アプリケーション１（ＡＰＰ１）から、アプリケーション２（ＡＰＰ２）に向かう点線矢印で示すリンクは、アプリケーション１（ＡＰＰ１）の実行中に、例えばユーザによる画面操作、あるいは時間経過等の所庭の遷移イベントの発生に基づいてアプリケーション２（ＡＰＰ２）を起動する処理が行われることを示す。
　このように、複数のアプリケーションにリンクを設定して、複数のアプリケーションを適用した処理が行われる場合もある。
　なお、アプリケーション間のリンク関係や、プレゼンテーション・ユニット（ＰＵ）間のリンク関係についての情報は、ＡＩＴやＳ－ＴＳＩＤ等のシグナリングデータに記録されており、受信装置３０は、これらのシグナリングデータの記述に基づいて、各リンク関係を把握することが可能となる。
　　［７．アプリケーションのキャッシュ処理について］
　受信装置３０において、アプリケーションを実行するためには、アプリケーションの構成データを受信装置の記憶部（キャッシュ部）に格納（キャッシュ）することが必要となる。
　例えば、図７に示すキャッシュ部１２２に、実行対象となるアプリケーションの構成データ（アプリケーションリソース）を格納することが必要である。
　アプリケーションを実行するのは、アプリケーション制御部１３０であり、アプリケーション制御部１３０は、アプリケーション実行に必要なデータ（リソース）をキャッシュ部１２２から取得してアプリケーションを実行する。
　キャッシュ部１２２に必要なデータが格納されていない場合、アプリケーションの実行エラーが発生する可能性がある。
　アプリケーションの実行タイミングまでに必要なデータをキャッシュ部１２２に格納することが必要となるが、キャッシュ部１２２に十分な空き容量が無い場合には、アプリケーション構成データを全てキャッシュ部１２２に格納することができない可能性もある。
　本開示の構成において、受信装置３０は、キャッシュ部１２２に格納可能なデータ量（空き容量）に相当するキャッシュサイズと、アプリケーションサイズ、またはプレゼンテーション・ユニット（ＰＵ）サイズを比較して、プレゼンテーション・ユニット（ＰＵ）単位、または、アプリケーション単位で、キャッシュ部１２２に対するデータ格納処理（キャッシュ処理）を行なう。
　少なくともプレゼンテーション・ユニット（ＰＵ）単位でキャッシュ部１２２にデータが格納されていれば、プレゼンテーション・ユニット（ＰＵ）に含まれるＨＴＭＬ文書を適用したデータ出力は完全な形で実行されることが保証される。
　以下、受信装置３０におけるキャッシュ処理、すなわち、アプリケーション単位、またはプレゼンテーション・ユニット（ＰＵ）単位でキャッシュ部１２２にデータを格納する処理について説明する。
　図１０は、アプリケーション、およびプレゼンテーション・ユニット（ＰＵ）のデータサイズと、受信装置のキャッシュサイズとの対応関係の一例について説明する図である。
　横軸がデータサイズ、およびキャッシュサイズに相当する軸である。
　上から、順に、
　（Ａ）アプリサイズ
　（Ｂ）受信装置のキャッシュサイズ
　これらの各サイズ設定例を示している。
　（Ａ）アプリサイズとして示す例は、図９を参照して説明した以下の３つのアプリケーションの各サイズを示している。
　（１）アプリケーション１（ＡＰＰ１）
　（２）アプリケーション２（ＡＰＰ２）
　（３）アプリケーション３（ＡＰＰ３）
　アプリケーション１（ＡＰＰ１）のデータサイズは、Ｓ３である。
　アプリケーション１（ＡＰＰ１）＋アプリケーション２（ＡＰＰ２）の合計データサイズは、Ｓ４である。
　アプリケーション１（ＡＰＰ１）～アプリケーション３（ＡＰＰ３）の合計データサイズは、Ｓ５である。
　また、アプリケーション１（ＡＰＰ１）は３つのプレゼンテーション・ユニット（ＰＵ）から構成されている。
　プレゼンテーション・ユニット（ＰＵ１１）のデータサイズは、Ｓ１である。
　プレゼンテーション・ユニット（ＰＵ１１）＋プレゼンテーション・ユニット（ＰＵ１２）の合計データサイズは、Ｓ２である。
　プレゼンテーション・ユニット（ＰＵ１１）～プレゼンテーション・ユニット（ＰＵ１３）の合計データサイズは、Ｓ３であり、アプリケーション１（ＡＰＰ１）のデータサイズ、Ｓ３に一致する。
　一方、（Ｂ）受信装置のキャッシュサイズの例として、以下の５つのキャッシュサイズを示している。
　（１）最小サイズ（Ｍｉｎｉｍｕｍ）
　（２）小サイズ（Ｓｍａｌｌ）
　（３）中サイズ（Ｍｅｄｉｕｍ）
　（４）大サイズ（Ｌａｒｇｅ）
　（５）最大サイズ（Ｍａｘｉｍｕｍ）
　これらは、例えば携帯端末、ＰＣ等、送信装置２０の提供するアプリケーションを実行する様々なユーザ装置としての受信装置３０の利用可能なキャッシュサイズの例である。
　（１）最小サイズ（Ｍｉｎｉｍｕｍ）のキャッシュの格納（キャッシュ）可能なデータサイズ、すなわちキャッシュサイズは、Ｓ１以上、Ｓ２未満である。
　（２）小サイズ（Ｓｍａｌｌ）のキャッシュの格納（キャッシュ）可能なデータサイズ、すなわちキャッシュサイズは、Ｓ２以上、Ｓ３未満である。
　（３）中サイズ（Ｍｅｄｉｕｍ）のキャッシュの格納（キャッシュ）可能なデータサイズ、すなわちキャッシュサイズは、Ｓ３以上、Ｓ４未満である。
　（４）大サイズ（Ｌａｒｇｅ）のキャッシュの格納（キャッシュ）可能なデータサイズ、すなわちキャッシュサイズは、Ｓ４以上、Ｓ５未満である。
　（５）最大サイズ（Ｍａｘｉｍｕｍ）のキャッシュの格納（キャッシュ）可能なデータサイズ、すなわちキャッシュサイズは、Ｓ５以上である。
　このような様々なキャッシュサイズを持つ受信装置が、送信装置から送信される３つのアプリケーションを、キャッシュ部にキャッシュ（格納）して、実行しようとする場合、それぞれのキャッシュサイズに応じて、キャッシュ対象を選択することが必要である。
　理想的には、アプリケーション１～アプリケーション３の全てのアプリ構成データファイルを全てキャッシュすることが望まれるが、これらの３つ全てのアプリを格納可能なのは、（５）最大サイズ（Ｍａｘｉｍｕｍ）のキャッシュのみである。
　（１）最小サイズ（Ｍｉｎｉｍｕｍ）～（４）大サイズ（Ｌａｒｇｅ）のキャッシュを持つ受信装置は、キャッシュ対象データを選択してキャッシュする処理を行なうことが必要となる。
　本開示の受信装置のキャッシュ対象選択処理は、以下のルールで実行される。
　（ルール１）キャッシュサイズが、リンク関係にあるアプリケーションの全てを格納可能であれば、リンク関係にあるアプリケーションの全てを格納（キュッシュ）する。
　（ルール２）キャッシュサイズが、リンク関係にあるアプリケーションの全てを格納可能でない場合、アプリケーション単位、またはプレゼンテーション・ユニット（ＰＵ）単位で、データを格納（キャッシュ）する。
　（ルール３）アプリケーション単位ののアプリ格納優先順位は、初期実行アプリケーションからのリンク経路に従う。
　（ルール４）プレゼンテーション・ユニット（ＰＵ）単位の格納優先順位は、エントリ文書を持つプレゼンテーション・ユニット（ＰＵ）からのリンク経路に従う。
　受信装置は、上記ルールを適用して、自装置のキャッシュサイズと、アプリケーションサイズ、および各プレゼンテーション・ユニット（ＰＵ）サイズを比較して、キャッシュ対象を選択する。
　上記ルールに従ったキャッシュ対象選択処理を行なった場合、図１０に示す５つのキャッシュサイズに応じたキャッシュ対象データは、以下の設定となる。
　（１）最小サイズ（Ｍｉｎｉｍｕｍ）＝プレゼンテーション・ユニット（ＰＵ１１）
　（２）小サイズ（Ｓｍａｌｌ）＝プレゼンテーション・ユニット（ＰＵ１１）＋プレゼンテーション・ユニット（ＰＵ１２）
　（３）中サイズ（Ｍｅｄｉｕｍ）＝アプリケーション（ＡＰＰ１）
　（４）大サイズ（Ｌａｒｇｅ）＝アプリケーション（ＡＰＰ１）＋アプリケーション（ＡＰＰ２）
　（５）最大サイズ（Ｍａｘｉｍｕｍ）＝アプリケーション（ＡＰＰ１）＋アプリケーション（ＡＰＰ２）＋アプリケーション（ＡＰＰ３）
　受信装置は、これらのキャッシュ対象選択処理に際して、送信装置２０が送信するシグナリングデータであるＡＩＴやＳ－ＴＳＩＤを参照する。
　これらのシグナリングデータには、アプリケーション単位の情報、プレゼンテーション・ユニット（ＰＵ）単位の情報が記録されている。
　例えば、先に図８を参照して説明したアプリケーションＩＤ、プレゼンテーション・ユニットＩＤ（ＰＵＩＤ）に対応付けて、各アプリ、各ＰＵのサイズ情報や、リンク情報が記録されている。
　ＩＤ情報を用いたキャッシュ対象選択処理例について、図１１を参照して説明する。
　図１１には、図１０を参照して説明した以下の５つのキャッシュサイズにおけるキャッシュ対象選択処理例を示している。
　（１）最小サイズ（Ｍｉｎｉｍｕｍ）
　（２）小サイズ（Ｓｍａｌｌ）
　（３）中サイズ（Ｍｅｄｉｕｍ）
　（４）大サイズ（Ｌａｒｇｅ）
　（５）最大サイズ（Ｍａｘｉｍｕｍ）
　（１）最小サイズ（Ｍｉｎｉｍｕｍ）の許容キャッシュサイズを持つ受信装置は、エントリ文書を持つプレゼンテーション・ユニット（ＰＵ１１）を最優先のキャッシュ対象ＰＵとして選択する。
　エントリ文書を持つプレゼンテーション・ユニット（ＰＵ１１）は、シグナリングデータ（ＡＩＴ，Ｓ－ＴＳＩＤ）に基づいて判別することができる。
　エントリ文書を持つプレゼンテーション・ユニット（ＰＵ１１）のＰＵＩＤを持つファイルをキャッシュ対象として選択してキャッシュ処理を実行する。
　シグナリングデータとしてのＳ－ＴＳＩＤには、プレゼンテーション・ユニット（ＰＵ）を構成するファイル単位で、各ファイルのグループＩＤが記録されている。すなわち、先に図８を参照して説明したプレゼンテーション・ユニットＩＤ（ＰＵＩＤ）を構成する後半ＩＤとして設定されるグループＩＤが、各ファイルに対応付けて記録されている。
　最小サイズ（Ｍｉｎｉｍｕｍ）の許容キャッシュサイズを持つ受信装置は、エントリ文書を持つプレゼンテーション・ユニット（ＰＵ１１）のＩＤ（ＰＵＩＤ）のグループＩＤ（ｇｒｏｕｐＩｄ１）と同じグループＩＤが、シグナリングデータ（Ｓ－ＴＳＩＤ）のファイルリストに記録されたファイルをキャッシュ対象として選択する。
　なお、シグナリングデータのデータ記録構成の詳細については後段で説明する。
　（２）小サイズ（Ｓｍａｌｌ）の許容キャッシュサイズを持つ受信装置は、エントリ文書を持つプレゼンテーション・ユニット（ＰＵ１１）を最優先のキャッシュ対象ＰＵとして選択し、さらに、このエントリ文書を持つプレゼンテーション・ユニット（ＰＵ１１）からリンク先として指定されている第２のプレゼンテーション・ユニット（ＰＵ１２）をキャッシュ対象とすることができる。
　前述したように、シグナリングデータとしてのＳ－ＴＳＩＤには、プレゼンテーション・ユニット（ＰＵ）を構成するファイル単位で、各ファイルのグループＩＤが記録されている。
　小サイズ（Ｓｍａｌｌ）の許容キャッシュサイズを持つ受信装置は、
　エントリ文書を持つプレゼンテーション・ユニット（ＰＵ１１）のＩＤ（ＰＵＩＤ）のグループＩＤ（ｇｒｏｕｐＩｄ１）、
　リンク先のプレゼンテーション・ユニット（ＰＵ１２）のＩＤ（ＰＵＩＤ）のグループＩＤ（ｇｒｏｕｐＩｄ２）、
　これら２つのグループＩＤ（ｇｒｏｕｐＩｄ１、またはｇｒｏｕｐＩｄ２）のいずれかと一致するグループＩＤが記録されたファイルを、シグナリングデータ（Ｓ－ＴＳＩＤ）のファイルリストからキャッシュ対象として選択する。
　（３）中サイズ（Ｍｅｄｉｕｍ）の許容キャッシュサイズを持つ受信装置は、初期実行アプリケーション（ＡＰＰ１）を構成するプレゼンテーション・ユニット（ＰＵ１１～ＰＵ１３）を全てキャッシュ対象とすることができる。
　先に図８を参照して説明したように、プレゼンテーション・ユニット（ＰＵ）にはプレゼンテーション・ユニットＩＤ（ＰＵＩＤ）が設定されており、このＩＤの前半は、アプリ本体ＩＤによって構成され、プレゼンテーション・ユニット（ＰＵ）の属するアプリケーションが識別可能な設定となっている。
　従って、受信装置は、シグナリングデータとしてのＳ－ＴＳＩＤに記録されたプレゼンテーション・ユニット（ＰＵ）のリストから、プレゼンテーション・ユニットＩＤ（ＰＵＩＤ）の前半に設定されたアプリ本体ＩＤが、エントリ文書のＰＵのアプリ本体ＩＤと同じ値を持つプレゼンテーション・ユニットをキャッシュ対象として選択すればよい。
　図１１に示す例では、アプリ本体ＩＤ＝ａｐｐＩｄ１の設定されたプレゼンテーション・ユニット（ＰＵ）、すなわち、ＰＵ１１～ＰＵ１３に属するファイルをキャッシュ対象として選択する。
　（４）大サイズ（Ｌａｒｇｅ）の許容キャッシュサイズを持つ受信装置は、初期実行アプリケーション（ＡＰＰ１）、および、アプリケーション（ＡＰＰ１）のリンク先として設定されたもう１つのアプリケーション（ＡＰＰ２）をキャッシュ対象とすることができる。
　（４）大サイズ（Ｌａｒｇｅ）の許容キャッシュサイズを持つ受信装置は、上述した「（３）中サイズ（Ｍｅｄｉｕｍ）の許容キャッシュサイズを持つ受信装置」と同様の処理によって、アプリケーション（ＡＰＰ１）の構成ファイルを全て取得し、さらに、および、アプリケーション（ＡＰＰ１）のリンク先として設定されたもう１つのアプリケーション（ＡＰＰ２）について、アプリ本体ＩＤ（ａｐｐＩｄ２）を検索キーとしてアプリケーション２（ＡＰＰ２）に属するファイルを検索してキャッシュ対象とする。
　図１１に示す例では、
　アプリ本体ＩＤ＝ａｐｐＩｄ１、または、
　アプリ本体ＩＤ＝ａｐｐＩｄ２、
　これらいずれかの設定されたプレゼンテーション・ユニット（ＰＵ）、すなわち、ＰＵ１１～ＰＵ１３、ＰＵ２１～ＰＵ２３に属するファイルをキャッシュ対象として選択する。
　（５）最大サイズ（Ｍａｘｉｍｕｍ）の許容キャッシュサイズを持つ受信装置は、初期実行アプリケーション（ＡＰＰ１）、および、アプリケーション（ＡＰＰ１）のリンク先として設定されたもう１つのアプリケーション（ＡＰＰ２）、さらに、そのリンク先として設定されたもう１つのアプリケーション（ＡＰＰ３）を全てキャッシュ対象とすることができる。
　（５）最大サイズ（Ｍａｘｉｍｕｍ）の許容キャッシュサイズを持つ受信装置は、上述した「（４）大サイズ（Ｌａｒｇｅ）の許容キャッシュサイズを持つ受信装置」と同様の処理によって、アプリケーション（ＡＰＰ１）と、アプリケーション（ＡＰＰ２）の構成ファイルを全て取得し、さらに、および、アプリケーション（ＡＰＰ２）のリンク先として設定されたもう１つのアプリケーション（ＡＰＰ３）について、アプリ本体ＩＤ（ａｐｐＩｄ３）を検索キーとしてアプリケーション３（ＡＰＰ３）に属するファイルを検索してキャッシュ対象とする。
　図１１に示す例では、
　アプリ本体ＩＤ＝ａｐｐＩｄ１、または、
　アプリ本体ＩＤ＝ａｐｐＩｄ２、または、
　アプリ本体ＩＤ＝ａｐｐＩｄ３、
　これらいずれかの設定されたプレゼンテーション・ユニット（ＰＵ）、すなわち、ＰＵ１１～ＰＵ１３、ＰＵ２１～２３、ＰＵ３１～３３に属するファイルをキャッシュ対象として選択する。
　　［８．シグナリングデータの構成、およびシグナリングデータを適用したキャッシュ対象データ選択処理について］
　次に、図１２以下を参照して、送信装置２０が受信装置３０に提供するシグナリングデータの構成と、受信装置３０において実行するシグナリングデータを適用したキャッシュ対象データ選択処理について説明する。
　送信装置２０は、送信装置２０が受信装置３０にアプリケーションを送信するとともに、送信アプリケーションのアクセス情報や、アプリケーションの属性情報、制御情報を記録した様々なシグナリングデータを受信装置３０に提供する。
　送信装置２０が受信装置３０に提供するアプリケーションに関するシグナリングデータとしては、例えば、以下のデータがある。
　（１）ＵＳＢＤ／ＵＳＤ（Ｕｓｅｒ　Ｓｅｒｖｉｃｅ　Ｂｕｎｂｄｌｅ　Ｄｅｓｃｒｉｐｔｉｏｎ／Ｕｓｅｒ　Ｓｅｒｖｉｃｅ　Ｄｅｓｃｒｉｐｔｉｏｎ）
　（２）Ｓ－ＴＳＩＤ（Ｓｅｒｖｉｃｅ　ｂａｓｅｄ　Ｔｒａｎｓｐｏｒｔ　Ｓｅｓｓｉｏｎ　Ｄｅｓｃｒｉｐｔｉｏｎ）、
　（３）アプリケーション・インフォーメーション・テーブル（ＡＩＴ：Ａｐｐｌｉｃａｔｉｏｎ　Ｉｎｆｏｒｍａｔｉｏｎ　Ｔａｂｌｅ）
　前述したように、ＵＳＤは、例えば放送局、あるいは番組など、所定のサービス単位の情報から構成され、サービスを受領するためのアクセス情報（ＵＲＬ等）、コーデック情報、再生タイミング情報等、受信装置においてサービスを利用するために必要となる情報から構成される。ＵＳＢＤは、ＵＳＤの束（バンドル）であり、ＵＳＤもＵＳＢＤも内容的には同じ制御情報を格納したシグナリングデータである。。
　Ｓ－ＴＳＩＤは、各サービス単位の付加情報であり、ＵＳＤに記録されない付加的な情報が記録される。
　前述したように、ＲＯＵＴＥプロトコルはＦＬＵＴＥをベースとするプロトコルである。ＦＬＵＴＥにおける転送制御パラメータを記述したメタデータファイルをＦＤＴ（Ｆｉｌｅ　Ｄｅｌｉｖｅｒｙ　Ｔａｂｌｅ）と呼び、ＲＯＵＴＥにおける転送制御パラメータを記述したメタデータファイルをＳ－ＴＳＩＤ（Ｓｅｒｖｉｃｅ　ｂａｓｅｄ　Ｔｒａｎｓｐｏｒｔ　Ｓｅｓｓｉｏｎ　Ｄｅｓｃｒｉｐｔｉｏｎ）と呼ぶ。Ｓ－ＴＳＩＤはＦＤＴのスーパーセットでありＦＤＴを含む。
　ＡＩＴは、１つまたは複数のアプリケーションに対応して設定されたアプリケーション固有のシグナリングデータであり、アプリケーションの取得用情報（ＵＲＬ）や、アプリ実行に適用される制御情報等が記録される。
　これらシグナリングデータの構成と、これらのシグナリングイデータを利用したキャッシュ対象データの選択処理例について、図１２以下を参照して説明する。
　図１２には、
　（１）ＵＳＢＤ／ＵＳＤ
　（２）ＡＩＴ
　（３）Ｓ－ＴＳＩＤ
　これらの一部データと、これらのデータを利用したアプリケーション取得処理について説明する図である。
　なお、ＵＳＢＤ／ＵＳＤ、ＡＩＴ、Ｓ－ＴＳＩＤ等のシグナリングデータは、送信装置２０から随時、繰り返し送信されており、受信装置は、アプリケーションの取得に先立ち、これらのシグナリングデータを予め取得する。さらに、取得したシグナリングデータを参照してアプリケーションのアクセス情報を取得してアプリケーションを取得する。
　アプリケーションは、放送波、または、インターネット等の通信ネットワークを介して取得することができる。
　ＵＳＢＤには、
　（ａ）放送波を介してアプリケーションが提供される場合のアプリケーション取得用のアクセス情報構成データである放送波対応ベースパターン、
　（ｂ）通信ネットワークを介してアプリケーションが提供される場合のアプリケーション取得用のアクセス情報構成データである通信ネットワーク対応ベースパターン、これらのいずれかのベースパターンが記録される。
　図１２に示すＵＳＢＤ／ＵＳＤには、アプリケーションが放送波を介して送信される場合、放送波に対応するベースパターン記録領域（ＵＳＤ／ｄｅｌｉｖｅｒｙＭｅｔｈｏｄ／ａｔｓｃ：ＢｃＡｐｐＳｅｒｖｉｃｅ／ｂａｓｅＰａｔｔｅｒｎ）にベースパターンが記録される。
　一方、アプリケーションが通信ネットワークを介して送信される場合、通信ネットワークに対応するベースパターン記録領域（ＵＳＤ／ｄｅｌｉｖｅｒｙＭｅｔｈｏｄ／ａｔｓｃ：ＵｃＡｐｐＳｅｒｖｉｃｅ／ｂａｓｅＰａｔｔｅｒｎ）にベースパターンが記録される。
　受信装置は、ＵＳＢＤまたはＵＳＤにどちらのベースパターンが記録されているかによって、アプリケーションが放送波を介して送信されるか、またはインターネット等の通信ネットワークを介して送信されるか、あるいは放送波とインターネット等の通信ネットワークの双方を介して送信されるかを判定することができる。
　また、アプリケーション対応のシグナリングデータであるＡＩＴには、特定のアプリケーションを取得するためのＵＲＩが記録される。
　受信装置は、アプリケーションの取得処理のために、まず、ステップＳ１１において、ＵＳＢＤ（またはＵＳＤ）に記録されたベースパターンを参照して、アプリケーションが放送波、通信ネットワークのどちらを利用して配信されているかを確認するとともに、ＡＩＴに記録されたＵＲＩと、ベースパターンとＵＲＩを組み合わせてアプリケーションのアクセス情報（アプリケーション取得用アドレス）を生成する。
　具体的には、送信装置から送信されるシグナリングデータであるＵＳＤ（ユーザ・サービス・ディスクリプション）のデリバリメソッド（ｄｅｌｉｖｅｒｙＭｅｔｈｏｄ）と、ＡＩＴのアプリケーションロケーション（ＡｐｐｌｉｃａｔｉｏｎＬｏｃａｔｉｏｎ）の記述に基づいて、アプリケーションの伝送経路（放送波／ネット
通信）を確認し、その後、いずれかのベースパターンとＵＲＩを組み合わせてアプリケーションのアクセス情報（アプリケーション取得用アドレス）を生成する。
　アプリケーションが通信ネットワークを介して配信されていると確認された場合、ステップＳ２１において、生成したアクセス情報（アプリケーション取得用アドレス）を適用して、通信ネットワークを介してアプリケーションを取得する。
　一方、アプリケーションが放送波を介して配信されていると確認された場合、ステップＳ３１において、もう１つのシグナリングデータであるＳ－ＴＳＩＤを取得し、
　ＡＩＴに記録されたアプリケーションロケーション（ａｐｐＬｏｃａｔｉｏｎ（ＵＲＩ）と一致するロケーション情報（ＲＳ／ＬＳ／ＳｃＦｌｗ／ＥＦＤＴ／＠ｃｏｎｔｅｎｔ－ｌｏｃ）を持つファイルのファイル単位情報を検索する。
　Ｓ－ＴＳＩＤには、プレゼンテーション・ユニット（ＰＵ）を構成する各ファイル単位の情報が記録されている。
　さらに、Ｓ－ＴＳＩＤのファイル単位情報に記録されたＴＯＩ（Ｔｒａｎｓｐｏｒｔ　Ｏｂｊｅｃｔ　Ｉｄｅｎｔｉｆｉｅｒ）を取得する。
　ＴＯＩ（Ｔｒａｎｓｐｏｒｔ　Ｏｂｊｅｃｔ　Ｉｄｅｎｔｉｆｉｅｒ）は、送信装置２０から送信されるアプリケーションを格納したＬＣＴパケットのパケットヘッダに記録されるパケット識別子である。
　ＬＣＴパケットのパケットヘッダにはパケットのペイロードに応じた識別子としてのＴＯＩが記録される。
　受信装置は、ステップＳ３２において、Ｓ－ＴＳＩＤに記録されたＴＯＩに基づいて放送波によって送信されるＬＣＴパケットから目的のアプリケーションに含まれるファイルを格納したＬＣＴパケットを選択して取得する。
　図１２（１）に示すように、ＵＳＢＤ／ＵＳＤには、放送波または通信ネットワーク対応のアプリケーションアクセス情報としてのベースパターンが記録される。
　放送波を介したＮＲＴコンテンツとしてアプリケーションを送信することを示すＵＳＢＤ／ＵＳＤの記録データの具体例について図１３、図１４を参照して説明する。
　図１３（１）は、放送波を介して送信されるＮＲＴサービスの１つとして放送波を介したＮＲＴアプリケーション送信サービスを定義した設定である。
　図に示すように、ＵＳＢＤ／ＵＳＤ内のデリバリメソッド（ｄｅｌｉｖｅｒｙＭｅｔｈｏｄ）に新たに放送波を介したＮＲＴアプリケーション送信サービスの定義領域２３１を設定する。
　この新たな定義領域に、１つ以上（１～Ｎ）の放送によって配信するＮＲＴアプリケーションのベースパターンを記録する。
　図１３（２）は、ＵＳＢＤ／ＵＳＤ内のデリバリメソッド（ｄｅｌｉｖｅｒｙＭｅｔｈｏｄ）内に定義されているアプリケーション送信サービス定義領域（ａｔｓｃ：ｂｒｏａｄｃａｓｔＡｐｐＳｅｒｖｉｃｅ）内に新たに放送波を介したＮＲＴアプリケーション送信サービスのベースパターン定義領域２３２を設定した構成である。
　図１４（３）は、ベースパターンそのものを記録するのではなく、サービスタイプ、すなわちサービス提供態様が、例えばライブ番組の配信等のサービスであるリニアタイプのサービスであるか、アプリケーション配信を含むノンリアルタイム（ＮＲＴ）コンテンツの配信サービスであるかを識別可能なフラグ（０，１）を記録する設定である。
　ＵＳＢＤ／ＵＳＤ内のデリバリメソッド（ｄｅｌｉｖｅｒｙＭｅｔｈｏｄ）内に定義されているアプリケーション送信サービス定義領域（ａｔｓｃ：ｂｒｏａｄｃａｓｔＡｐｐＳｅｒｖｉｃｅ）内に上記のフラグの記録領域２３３を設ける。
　受信装置は、例えば、これら図１３、図１４に示す（１）～（３）の記録データを参照することで、放送サービスによるアプリケーション配信が実行されているか否かを確認することができる。
　一方、シグナリングデータとしてのＡＩＴ（アプリケーション・インフォメーション・テーブル）、およびＳ－ＴＳＩＤには、先に図１０、図１１を参照して説明したキャッシュ対象データの選択処理を行なうためのデータが記録される。
　図１５、および図１６を参照して、ＡＩＴ、Ｓ－ＴＳＩＤの記録データの一例について説明する。
　図１５は、ＡＩＴ（アプリケーション・インフォメーション・テーブル）の記録データの例を示す図である。
　図１５に示すＡＩＴは、先に図９、図１０を参照して説明した３つのアプリケーション（ＡＰＰ１～ＡＰＰ３）に対応する情報を記録したＡＩＴの一例である。
　ＡＩＴは１つのアプリケーションのみの情報を記録した設定も可能であるが、複数の関連するアプリケーションの情報をまとめて記録した設定とすることもできる。
　図１５に示すＡＩＴには、
　アプリケーション１（ＡＰＰ１）に関する情報の記録領域２４１、
　アプリケーション２（ＡＰＰ２）に関する情報の記録領域２４２、
　アプリケーション３（ＡＰＰ３）に関する情報の記録領域２４３、
　これらの情報記録領域が含まれる。
　各アプリケーション情報記録領域２４１～２４３の各々には、
　アプリケーションＩＤ２５１、
　アプリケーションアクセス情報（ａｐｐＬｏｃａｔｉｏｎ（ＵＲＩ））２５２、
　アプリケーションサイズ２５３、
　リンク先アプリケーション情報２５４、
　これらの情報が記録される。
　アプリケーションＩＤ２５１は、先に図８を参照して説明したアプリケーション識別子である。
　すなわち、組織ＩＤ（ｏｒｇＩｄ）と、アプリ本体ＩＤ（ａｐｐＩｄ）から構成されるアプリケーションＩＤである。
　アプリケーションアクセス情報（ａｐｐＬｏｃａｔｉｏｎ（ＵＲＩ））２５２は、アプリケーションを取得するために利用されるＵＲＩである。先に図１２を参照して説明したように、ＵＳＢＤに記録されたベースパターンと併せてアクセス情報が生成可能となる。
　アプリケーションサイズ２５３は、１つのアプリケーションに含まれる全ての構成データの総データサイズである。
　例えば、図９に示すアプリケーション１（ＡＰＰ１）の場合、３つのプレゼンテーション・ユニット（ＰＵ１１～ＰＵ１３）を構成するファイルの総サイズが記録される。図１０に示す例では、アプリケーション１（ＡＰＰ１）のサイズはＳ１であり、このＳ１が、アプリケーションサイズ２５３として記録される。
　リンク先アプリケーション情報２５４は、先に図９を参照して説明したアプリ間のリンクに関する情報である。具体的には、リンク先のアプリケーションのアプリケーションＩＤが記録される。
　なお、リンク先のアプリケーションがない場合は、記録されない。
　次に、図１６を参照して、Ｓ－ＴＳＩＤの記録データについて説明する。
　前述したように、Ｓ－ＴＳＩＤは、サービス単位の転送制御パラメータを記述したメタデータファイルであり、サービスにおいて提供される多数のファイルのファイル単位の情報であるＦＤＴ（ファイル・デリバリ・テーブル）を含むシグナリングデータである。
　図１６に示すＳ－ＴＳＩＤは、先に図９、図１０を参照して説明した３つのアプリケーション（ＡＰＰ１～ＡＰＰ３）に対応する情報を記録したＳ－ＴＳＩＤの一部のみを示している。
　なお、図１６には、アプリケーション１（ＡＰＰ１）に属する２つのブレゼンテーション・ユニット（ＰＵ１１，ＰＵ１２）に対応する情報記録領域、すなわち、
　プレゼンテーション・ユニット（ＰＵ１１）対応情報２６２、
　プレゼンテーション・ユニット（ＰＵ１２）対応情報２６３、
　これらの情報記録領域のみを抜き出して示している。
　図１６に示すブレゼンテーション・ユニット（ＰＵ１１，ＰＵ１２）に対応する情報記録領域以下に、ＰＵ１３，ＰＵ２１～ＰＵ２３，ＰＵ３１～ＰＵ３３の情報が記録される。
　図１６に示すＳ－ＴＳＩＤには、以下の各情報が記録されている。
　プレゼンテーション・ユニット（ＰＵ）間リンク情報２６１、
　プレゼンテーション・ユニット（ＰＵ１１）対応情報２６２、
　プレゼンテーション・ユニット（ＰＵ１２）対応情報２６３、
　プレゼンテーション・ユニット（ＰＵ）間リンク情報２６１には、リンク元のプレゼンテーション・ユニット（ＰＵ）のＰＵＩＤと、リンク先のプレゼンテーション・ユニット（ＰＵ）のＰＵＩＤが記録される。
　なお、ＰＵＩＤは、先に図８を参照して説明したように、プレゼンテーション・ユニット（ＰＵ）の属するアプリケーションのアプリ本体ＩＤ（ａｐｐＩｄ）と、同一アプリ内のプレゼンテーション・ユニットを個別に識別可能としたグループＩＤ（ｇｒｏｕｐＩｄ）によって構成される。
　なお、ＰＵＩＤを構成するグループＩＤ（ｇｒｏｕｐＩｄ）は、１つのアプリケーションに含まれるブレゼンテーション・ユニット（ＰＵ）に対して、例えば１，２，３の連番が設定され、グループＩＤ（ｇｒｏｕｐＩｄ）＝１のＰＵがエントリ文書を持つＰＵとなる。
　さらに、そのエントリ文書を持つ最初のファイル（Ｆｉｌｅ）がエントリ文書としてのＨＴＭＬ文書に相当するファイルである。
　この最初のファイルのファイル単位情報に、プレゼンテーション・ユニット（ＰＵ１１）サイズ情報が記録される。
　図１６に示すように、プレゼンテーション・ユニット（ＰＵ１１）対応情報２６２には、プレゼンテーション・ユニット（ＰＵ１１）に属するファイル単位の情報が記録される。
　最初のファイル単位情報には、以下の各情報が記録されている。
　ファイルアクセス情報としてのＴＯＩ情報、
　プレゼンテーション・ユニット（ＰＵ１１）構成ファイルの所属グループ情報２７１、
　プレゼンテーション・ユニット（ＰＵ１１）サイズ情報２７２、
　２番目以降のファイル単位情報には、
　ファイルアクセス情報としてのＴＯＩ情報、
　プレゼンテーション・ユニット（ＰＵ１１）構成ファイルの所属グループ情報、
　これらの情報が記録される。
　また、プレゼンテーション・ユニット（ＰＵ１２）対応情報２６３には、プレゼンテーション・ユニット（ＰＵ１２）に属するファイル単位の情報が記録される。
　最初のファイル単位情報には、以下の各情報が記録されている。
　ファイルアクセス情報としてのＴＯＩ情報、
　プレゼンテーション・ユニット（ＰＵ１２）構成ファイルの所属グループ情報２７３、
　プレゼンテーション・ユニット（ＰＵ１２）サイズ情報２７４、
　このように、Ｓ－ＴＳＩＤには、プレゼンテーション・ユニット（ＰＵ）を構成する各ファイル単位の次用法が記録され、このファイル単位情報内に、プレゼンテーション・ユニットのＩＤや、プレゼンテーション・ユニットのサイズ情報が記録される。
　Ｓ－ＴＳＩＤのファイル単位のデータ記録領域であるＦＤＴ（ファイル・デリバリ・テーブル）のデータ記録例を図１７に示す。
　図１７に示すように、ファイル単位のデータ記録領域であるＦＤＴ（ファイル・デリバリ・テーブル）には、以下の各情報が記録される。
　（ａ）ファイルのアクセス情報としてのコンテンツロケーション（＠Ｃｏｎｔｅｎｔ－Ｌｏｃａｔｉｏｎ）
　（ｂ）送信装置から送信されるＬＣＴパケットのパケットヘッダに記録されるパケット識別子であるＴＯＩ（Ｔｒａｎｓｐｏｒｔ　Ｏｂｊｅｃｔ　Ｉｄｅｎｔｉｆｉｅｒ）
　（ｃ）コンテンツのレングス、タイプ、
　さらに、図に示すデータ記録領域２８１に、
　（ｄ）プレゼンテーション・ユニットＩＤ（ＰＵＩＤ）
　（ｅ）プレゼンテーション・ユニット（ＰＵ）サイズ
　これらの各データが記録される。
　また、図１６を参照して説明したように、Ｓ－ＴＳＩＤには、プレゼンテーション・ユニット（ＰＵ）間リンク情報２６１が記録される。
　この具体的記録例について、図１８を参照して説明する。
　プレゼンテーション・ユニット（ＰＵ）間リンク情報２６１は、
　Ｓ－ＴＳＩＤ内の以下の記録領域、すなわち、
　ＲＳ／ＬＳ／ＳｃＦｌｗ／ＣｏｎｔｅｎｔＩｎｆｏ
　以下に記録される。
　図１８は、コンテンツ情報（ＣｏｎｔｅｎｔＩｎｆｏ）内に記録されるＰＵ間リンク情報の例を示す図である。
　例えば、図１８のデータ記録領域２８２に示すような設定で、プレゼンテーション・ユニット（ＰＵ）間リンク情報が記録される。
　リンク元のプレゼンテーション・ユニットＩＤ（ＰＵＩＤ）
　リンク先のプレゼンテーション・ユニットＩＤ（ＰＵＩＤ）
　データ記録領域２８２には、これらの２つのＰＵＩＤを記録する領域が設定される。
　次に、図１９に示すフローチャートを参照して、受信装置においてシグナリングデータを参照して実行するアプリケーション取得処理と、キャッシュ対象データの選択処理シーケンスについて説明する。すなわち、
　ＵＳＢＤ／ＵＳＤ
　ＡＩＴ
　Ｓ－ＴＳＩＳ
　これらのシグナリンクデータを適用したアプリケーション取得処理と、キャッシュ対象データの選択処理である。
　なお、図１９に示すフローに従った処理は、受信装置３０のデータ処理部において実行される処理である。例えば、図１９に示す処理シーケンスを記録したプログラムに従って実行される。なお、図１９に示す処理シーケンスを実行するデータ処理部は、例えば、図７に示す受信装置３０におけるシグナリング解析部１１３や、キャッシュ制御部等の機能を実行するデータ処理部である。
　以下、各ステップの処理について、順次、説明する。
　　（ステップＳ５１）
　受信装置は、ステップＳ５１において、送信装置から送信されるＳＬＳ（サービスレベルシグナリング）からＡＩＴ（アプリケーション・インフォメーション・テーブル）を取得して、配信アプリケーションに関する情報を取得する。
　すなわち、図１５を参照して説明したＡＩＴ（アプリケーション・インフォメーション・テーブル）を取得して、配信アプリケーションに関する情報を取得する。
　具体的には、例えば、アプリケーションＩＤ、アプリケーションサイズ情報、アプリケーション間リンク情報等を取得する。
　　（ステップＳ５２）
　受信装置は、次に、ステップＳ５２において、送信装置から送信されるシグナリングデータであるＵＳＤ（ユーザ・サービス・ディスクリプション）のデリバリメソッド（ｄｅｌｉｖｅｒｙＭｅｔｈｏｄ）と、ＡＩＴのアプリケーションロケーション（ＡｐｐｌｉｃａｔｉｏｎＬｏｃａｔｉｏｎ）の記述の比較に基づいて、アプリケーションの伝送経路（放送波／ネット通信）を確認する。
　　（ステップＳ５３）
　次に、受信装置は、ステップＳ５３において、送信装置から送信されるシグナリングデータであるＡＩＴから取得したアプリケーションサイズ情報と、アプリケーション間リンク情報と、受信装置のキャッシュ許容サイズに基づいて、キャッシュ可能なデータ範囲を決定する。
　例えば、先に図１０～図１８を参照して説明した処理に従って、キャッシュ可能なアプリケーション構成データ範囲を確認して、キャッシュ対象データを決定する。
　　（ステップＳ５４）
　次に、受信装置は、ステップＳ５４において、１つのアプリケーション単位のキャッシュが可能か否かを判定する。
　すなわち、図１０、図１１を参照して説明したキャッシュサイズが、中サイズ（Ｍｅｄｉｕｍ）～最大サイズ（Ｍａｘｉｍｕｍ）に相当するか否かを判定する。
　ステップＳ５４において、１つのアプリケーション単位のキャッシュが可能と判定した場合は、ステップＳ５５に進む。
　一方、ステップＳ５４において、１つのアプリケーション単位のキャッシュが不可能と判定した場合は、ステップＳ５６に進む。
　　（ステップＳ５５）
　ステップＳ５４において、１つのアプリケーション単位のキャッシュが可能と判定した場合は、受信装置は、ステップＳ５５において、ＡＩＴに記述されたアプリケーションサイズ情報と、アプリケーション間リンク情報と、受信装置のキャッシュ許容サイズに基づいて決定したキャッシュ可能な範囲のアプリケーションを取得して、キャッシュ処理を実行する。
　この処理は、図１０、図１１を参照して説明したキャッシュサイズが、中サイズ（Ｍｅｄｉｕｍ）～最大サイズ（Ｍａｘｉｍｕｍ）に相当する場合の処理に対応する。
　　（ステップＳ５６）
　一方、ステップＳ５４において、１つのアプリケーション単位のキャッシュが不可能と判定した場合は、受信装置は、ステップＳ５６において、Ｓ－ＴＳＩＤのＥＦＤＴ／ＦＩＬＥ要素に記述されたプレゼンテーション・ユニット（ＰＵ）サイズと、受信装置のキャッシュ許容サイズに基づいて、決定したキャッシュ可能な範囲のプレゼンテーション・ユニットを取得して、キャッシュ処理を実行する。
　この処理は、図１０、図１１を参照して説明したキャッシュサイズが、最小サイズ（Ｍｉｎｉｍｕｍ）～小サイズ（Ｓｍａｌｌ）に相当する場合の処理に対応する。
　　［９．受信装置のキャッシュサイズ（データ格納許容サイズ）に応じた具体的な処理例について］
　次に、図２０以下を参照して、受信装置のキャッシュサイズ（データ格納許容サイズ）に応じた具体的な処理例について説明する。
　先に図１０、図１１を参照して説明した以下の５つのキャッシュサイズにおけるキャッシュ対象選択処理例について、順次、説明する。
　（１）最小サイズ（Ｍｉｎｉｍｕｍ）
　（２）小サイズ（Ｓｍａｌｌ）
　（３）中サイズ（Ｍｅｄｉｕｍ）
　（４）大サイズ（Ｌａｒｇｅ）
　（５）最大サイズ（Ｍａｘｉｍｕｍ）
　なお、アプリケーションサイズ、プレゼンテーション・ユニット（ＰＵ）サイズについても、図１０、図１１に示す設定であるものとして説明する。
　すなわち、上記５つのキャッシュサイズに応じたキャッシュ対象データは、以下の設定となる。
　（１）最小サイズ（Ｍｉｎｉｍｕｍ）＝プレゼンテーション・ユニット（ＰＵ１１）
　（２）小サイズ（Ｓｍａｌｌ）＝プレゼンテーション・ユニット（ＰＵ１１）＋プレゼンテーション・ユニット（ＰＵ１２）
　（３）中サイズ（Ｍｅｄｉｕｍ）＝アプリケーション（ＡＰＰ１）
　（４）大サイズ（Ｌａｒｇｅ）＝アプリケーション（ＡＰＰ１）＋アプリケーション（ＡＰＰ２）
　（５）最大サイズ（Ｍａｘｉｍｕｍ）＝アプリケーション（ＡＰＰ１）＋アプリケーション（ＡＰＰ２）＋アプリケーション（ＡＰＰ３）
　以下、５つの異なるサイズのデータ格納許容キャッシュサイズを持つ受信装置における処理例について、順次、説明する。
　なお、以下に説明する処理例は、アプリケーションが放送波を介して配信されている場合の処理例であり、受信装置は、放送波を介してアプリケーションを構成するファイルを取得する。
　　［９－１．受信装置のデータ格納許容キャッシュサイズが最小サイズ（Ｍｉｎｉｍｕｍ）であり、１つのプレゼンテーション・ユニット（ＰＵ）のみ格納可能である場合の処理例について］
　まず、図２０以下を参照して、受信装置のデータ格納許容キャッシュサイズが最小サイズ（Ｍｉｎｉｍｕｍ）であり、１つのプレゼンテーション・ユニット（ＰＵ）のみ格納可能である場合の処理例について説明する。
　図２０は、受信装置のデータ格納許容キャッシュサイズが最小サイズ（Ｍｉｎｉｍｕｍ）である場合の、キャッシュ（格納）対象データを説明する図である。
　受信装置は、１つのプレゼンテーション・ユニット（ＰＵ）のみ格納可能である。
　受信装置の実行する処理は、アプリケーション（ＡＰＰ１）の起動後に最初に読み込まれるＨＴＭＬ文書（エントリ文書２２１）とリソースファイルで構成されるプレゼンテーション・ユニット（ＰＵ１１）を取得し、キャッシュして表示する処理となる。
　図２１には、受信装置が放送波を介してアプリケーションを取得し、キャッシュ処理を行ない、実行するまでの処理シーケンスを説明するフローチャートを示している。
　さらに、図２２には、図２１に示すフローチャートの各ステップの処理に際して利用されるシグナリングデータを示している。
　（１）ＡＩＴ
　（２）Ｓ－ＴＳＩＤ
　これら２つのシグナリングデータである。
　図２１に示す各ステップ番号（Ｓ１１１～Ｓ１１６）の処理と、図２２に示す同じステップ番号（Ｓ１１１～Ｓ１１６）の処理は同一の処理である。図２２においては、各ステップの処理に際して参照するシグナリングデータ（ＡＩＴ，Ｓ－ＴＳＩＤ）の記録領域と各ステップ番号とを対応付けて示している。
　図２１、および図２２を参照して各ステップの処理について、順次、説明する。
　　（ステップＳ１１１）
　受信装置は、まず、ステップＳ１１１において、送信装置から送信されるＳＬＳ（サービスレベルシグナリング）からＡＩＴ（アプリケーション・インフォメーション・テーブル）、Ｓ－ＴＳＩＤを取得する。
　　（ステップＳ１１２）
　次に、受信装置は、ステップＳ１１２において、ＡＩＴから、配信アプリケーションに関する情報の取得、確認を行う。例えば、以下の処理を行なう。
　（１）アプリケーションロケーション（ａｐｐｌｉｃａｔｉｏｎＬｏｃａｔｉｏｎ）から、エントリ文書のＵＲＬを取得する。
　（２）コントロールコードがキャッシュ処理の必要なコード（ＡＵＴＯＳＴＡＲＴ，Ｐｒｅｆｅｔｃｈなど）に設定されていることを確認する。
　（３）アプリケーションＩＤを取得する。
　（４）アプリケーションサイズを取得する。
　さらに、取得したアプリケーションサイズと、受信装置のキャッシャ可能なキャッシュサイズを比較する。
　本例では、キャッシュサイズ＝最小（Ｍｉｎｉｍｕｍ）であり、アプリケーションサイズより小さく、アプリケーション全体のキャッシュ処理はできないと判断する。
　　（ステップＳ１１３）
　次に、受信装置は、ステップＳ１１３において、Ｓ－ＴＳＩＤから、エントリ文書の取得先情報を取得する。
　具体的には、図２２のステップＳ１１３に示すように、Ｓ－ＴＳＩＤに記録されたファイル単位の情報に記録されたコンテンツロケーション情報（ＲＳ／ＬＳ／ＳｃＦｌｗ／ＥＦＤＴ／ｃｏｎｔｅｎｔ－ｌｏｃａｔｉｏｎ）と、ＡＩＴのアプリケーションロケーション（ａｐｐｌｉｃａｔｉｏｎＬｏｃａｔｉｏｎ）の一致するファイル（ＦＩＬＥ）を検索して、その取得先情報を取得する。
　前述したように、Ｓ－ＴＳＩＤには、プレゼンテーション・ユニット（ＰＵ）を構成するファイル単位の情報が記録されている。
　受信装置は、ＡＩＴのアプリケーションロケーション（ａｐｐｌｉｃａｔｉｏｎＬｏｃａｔｉｏｎ）の一致するファイル（ＦＩＬＥ）を検索して、その取得先情報として、Ｓ－ＴＳＩＤのファイル単位情報に記録されたＴＯＩ（Ｔｒａｎｓｐｏｒｔ　Ｏｂｊｅｃｔ　Ｉｄｅｎｔｉｆｉｅｒ）を取得する。
　ＴＯＩ（Ｔｒａｎｓｐｏｒｔ　Ｏｂｊｅｃｔ　Ｉｄｅｎｔｉｆｉｅｒ）は、送信装置２０から送信されるアプリケーションを格納したＬＣＴパケットのパケットヘッダに記録されるパケット識別子である。
　ＬＣＴパケットのパケットヘッダにはパケットのペイロードに応じた識別子としてのＴＯＩが記録される。
　受信装置は、Ｓ－ＴＳＩＤに記録されたＴＯＩに基づいて放送波によって送信されるＬＣＴパケットから目的のアプリケーションに含まれるファイルを格納したＬＣＴパケットを選択して取得することができる。
　　（ステップＳ１１４）
　次に、受信装置は、ステップＳ１１４において、Ｓ－ＴＳＩＤから、エントリ文書を含むプレゼンテーション・ユニット（ＰＵ）と、Ｓ－ＴＳＩＤに記録されたリンク情報を辿って得られるプレゼンテーション・ユニット（ＰＵ）のＩＤ（ＰＵＩＤ＝アプリ本体ＩＤ＋グループＩＤ）、さらに、各プレゼンテーション・ユニット（ＰＵ）のサイズ情報（ＰＵＳｉｚｅ）を取得する。
　図２２のステップＳ１１４ａに示すように、プレゼンテーション・ユニットＩＤ（ＰＵＩＤ）は、アプリ本体ＩＤ（ａｐｐＩｄ）と、グループＩＤ（ｇｒｏｕｐＩｄ）から構成されている。
　アプリ本体ＩＤ（ａｐｐＩｄ）は、ファイルの属するプレゼンテーション・ユニット（ＰＵ）が属するアプリケーションに設定されたアプリケーションＩＤ（組織ＩＤ（ｏｒｇＩｄ）＋アプリ本体ＩＤ（ａｐｐＩｄ））の構成データであるアプリ本体ＩＤ（ａｐｐＩｄ）と同じ値である。
　また、図２２のステップＳ１１４ｂに示すように、受信装置は、Ｓ－ＴＳＩＤに記録されたリンク情報を取得する。
　受信装置は、このリンク情報を辿って得られるプレゼンテーション・ユニット（ＰＵ）のＩＤ（ＰＵＩＤ＝アプリ本体ＩＤ＋グループＩＤ）、さらに、各プレゼンテーション・ユニット（ＰＵ）のサイズ情報（ＰＵＳｉｚｅ）を取得する。
　　（ステップＳ１１５）
　次に、受信装置は、ステップＳ１１５において、受信装置のキャッシュサイズ、すなわち利用可能なキャッシュサイズと、各プレゼンテーション・ユニット（ＰＵ）のデータサイズを比較して、キャッシュ対象とするプレゼンテーション・ユニットを選択する。
　なお、最優先キャッシュ対象ＰＵは、エントリ文書を有するプレゼンテーション・ユニット（例えば、ＰＵ１１）である。
　その次の優先キャッシュ対象ＰＵは、エントリ文書を有するＰＵ１１のリンク先ＰＵ、例えばＰＵ１２となる。
　さらに、ＰＵ１２のリンク先ＰＵ１３が次のキャッシュ対象ＰＵとして選択され、リンクを辿って、順次、キャッシュ対象ＰＵが選択される。
　キャッシュサイズを超えた時点で、キャッシュ対象ＰＵの選択が完了する。
　具体的には、例えば、
　ＰＵ１１サイズ≦キャッシュサイズ＜（ＰＵ１１＋ＰＵ１２）サイズ
　の場合は、ＰＵ１１のみをキャッシュ対象ＰＵとして選択する。
　また、（ＰＵ１１＋ＰＵ１２）サイズ≦キャッシュサイズ＜（ＰＵ１１＋ＰＵ１２＋ＰＵ１３）サイズ
　の場合は、ＰＵ１１とＰＵ１２をキャッシュ対象ＰＵとして選択する。
　このように、ＰＵの総計サイズが、キャッシュサイズに達するまでの範囲内で、キャッシュ対象ＰＵを、リンクを辿って順次、選択する。
　本例の場合は、
　ＰＵ１１サイズ≦キャッシュサイズ＜（ＰＵ１１＋ＰＵ１２）サイズ
　上記式が満足され、ＰＵ１１のみをキャッシュ対象ＰＵとして選択する。
　　（ステップＳ１１６）
　次に、受信装置は、ステップＳ１１６において、ステップＳ１１５で決定したキャッシュ対象のプレゼンテーション・ユニット（ＰＵ）のＰＵＩＤと同じＰＵＩＤを持つファイルを取得して、キャッシュ処理を実行して、エントリ文書を出力（表示）する。
　図２２のステップＳ１１６に示すように、Ｓ－ＴＳＩＤに記録されたファイル単位の情報から、キャッシュ対象として選択したプレゼンテーション・ユニット（ＰＵ）のＰＵＩＤ（ＰＵ１１）と同じＰＵＩＤ（ＰＵ１１）を持つファイルを選択して、これらのファイル単位情報に記録されたＴＯＩに基づいて放送波から該当ファイルを格納したパケットを選択取得する。選択取得したファイルをキャッシュ部に格納（キャッシュ）する処理を実行して、その後、エントリ文書からの出力（表示）処理を開始する。
　これらの処理によって、アプリケーション（ＡＰＰ１）の１つのプレゼンテーション・ユニット（ＰＵ１１）に属する全てのファイルを取得することができる。
　従って、１つのプレゼンテーション・ユニット（ＰＵ）の全構成ファイルを利用したアプリケーションの実行が可能となり、プレゼンテーション・ユニット単位の完全な形態でのデータ再生が可能となる。
　すなわち、より完成度の高いアプリケーション実行処理が実現される。
　　［９－２．受信装置のデータ格納許容キャッシュサイズが小サイズ（Ｓｍａｌｌ）であり、複数のプレゼンテーション・ユニット（ＰＵ）が格納可能である場合の処理例について］
　次に、図２３以下を参照して、受信装置のデータ格納許容キャッシュサイズが小サイズ（Ｓｍａｌｌ）であり、複数のプレゼンテーション・ユニット（ＰＵ）が格納可能である場合の処理例について説明する。
　図２３は、受信装置のデータ格納許容キャッシュサイズが小サイズ（Ｓｍａｌｌ）である場合の、キャッシュ（格納）対象データを説明する図である。
　受信装置は、２つのプレゼンテーション・ユニット（ＰＵ１１とＰＵ１２）を格納可能である。
　受信装置の実行する処理は、アプリケーション（ＡＰＰ１）の起動後に最初に読み込まれるＨＴＭＬ文書（エントリ文書２２１）とリソースファイルで構成されるプレゼンテーション・ユニット（ＰＵ１１）、さらに、プレゼンテーション・ユニット（ＰＵ１１）のリンク先として設定されているプレゼンテーション・ユニット（ＰＵ１２）を取得し、キャッシュして表示する処理となる。
　なお、プレゼンテーション・ユニット（ＰＵ１１）のリンク先として設定されているプレゼンテーション・ユニットが複数ある場合は、それらの複数のリンク先ＰＵを取得する。
　図２４には、受信装置が放送波を介してアプリケーションを取得し、キャッシュ処理を行ない、実行するまでの処理シーケンスを説明するフローチャートを示している。
　さらに、図２５には、図２４に示すフローチャートの各ステップの処理に際して利用されるシグナリングデータを示している。
　（１）ＡＩＴ
　（２）Ｓ－ＴＳＩＤ
　これら２つのシグナリングデータである。
　図２４に示す各ステップ番号（Ｓ１２１～Ｓ１２６）の処理と、図２５に示す同じステップ番号（Ｓ１２１～Ｓ１２６）の処理は同一の処理である。図２５においては、各ステップの処理に際して参照するシグナリングデータ（ＡＩＴ，Ｓ－ＴＳＩＤ）の記録領域と各ステップ番号とを対応付けて示している。
　図２４、および図２５を参照して各ステップの処理について、順次、説明する。
　　（ステップＳ１２１）
　受信装置は、まず、ステップＳ１２１において、送信装置から送信されるＳＬＳ（サービスレベルシグナリング）からＡＩＴ（アプリケーション・インフォメーション・テーブル）、Ｓ－ＴＳＩＤを取得する。
　　（ステップＳ１２２）
　次に、受信装置は、ステップＳ１２２において、ＡＩＴから、配信アプリケーションに関する情報の取得、確認を行う。例えば、以下の処理を行なう。
　（１）アプリケーションロケーション（ａｐｐｌｉｃａｔｉｏｎＬｏｃａｔｉｏｎ）から、エントリ文書のＵＲＬを取得する。
　（２）コントロールコードがキャッシュ処理の必要なコード（ＡＵＴＯＳＴＡＲＴ，Ｐｒｅｆｅｔｃｈなど）に設定されていることを確認する。
　（３）アプリケーションＩＤを取得する。
　（４）アプリケーションサイズを取得する。
　さらに、取得したアプリケーションサイズと、受信装置のキャッシャ可能なキャッシュサイズを比較する。
　本例では、キャッシュサイズ＝小（Ｓｍａｌｌ）であり、アプリケーションサイズより小さく、アプリケーション全体のキャッシュ処理はできないと判断する。
　　（ステップＳ１２３）
　次に、受信装置は、ステップＳ１２３において、Ｓ－ＴＳＩＤから、エントリ文書の取得先情報を取得する。
　具体的には、図２５のステップＳ１２３に示すように、Ｓ－ＴＳＩＤに記録されたファイル単位の情報に記録されたコンテンツロケーション情報（ＲＳ／ＬＳ／ＳｃＦｌｗ／ＥＦＤＴ／ｃｏｎｔｅｎｔ－ｌｏｃａｔｉｏｎ）と、ＡＩＴのアプリケーションロケーション（ａｐｐｌｉｃａｔｉｏｎＬｏｃａｔｉｏｎ）の一致するファイル（ＦＩＬＥ）を検索して、その取得先情報を取得する。
　　（ステップＳ１２４）
　次に、受信装置は、ステップＳ１２４において、Ｓ－ＴＳＩＤから、エントリ文書を含むプレゼンテーション・ユニット（ＰＵ）と、Ｓ－ＴＳＩＤに記録されたリンク情報を辿って得られるプレゼンテーション・ユニット（ＰＵ）のＩＤ（ＰＵＩＤ＝アプリ本体ＩＤ＋グループＩＤ）、さらに、各プレゼンテーション・ユニット（ＰＵ）のサイズ情報（ＰＵＳｉｚｅ）を取得する。
　図２５のステップＳ１２４ａに示すように、プレゼンテーション・ユニットＩＤ（ＰＵＩＤ）は、アプリ本体ＩＤ（ａｐｐＩｄ）と、グループＩＤ（ｇｒｏｕｐＩｄ）から構成されている。
　アプリ本体ＩＤ（ａｐｐＩｄ）は、ファイルの属するプレゼンテーション・ユニット（ＰＵ）が属するアプリケーションに設定されたアプリケーションＩＤ（組織ＩＤ（ｏｒｇＩｄ）＋アプリ本体ＩＤ（ａｐｐＩｄ））の構成データであるアプリ本体ＩＤ（ａｐｐＩｄ）と同じ値である。
　また、図２５のステップＳ１２４ｂに示すように、受信装置は、Ｓ－ＴＳＩＤに記録されたリンク情報を取得する。
　図２５のステップＳ１２４ｃに示すように、受信装置は、このリンク情報を辿って得られるプレゼンテーション・ユニット（ＰＵ）のＩＤ（ＰＵＩＤ＝アプリ本体ＩＤ＋グループＩＤ）、さらに、各プレゼンテーション・ユニット（ＰＵ）のサイズ情報（ＰＵＳｉｚｅ）を取得する。
　　（ステップＳ１２５）
　次に、受信装置は、ステップＳ１２５において、受信装置のキャッシュサイズ、すなわち利用可能なキャッシュサイズと、各プレゼンテーション・ユニット（ＰＵ）のデータサイズを比較して、キャッシュ対象とするプレゼンテーション・ユニットを選択する。
　なお、最優先キャッシュ対象ＰＵは、エントリ文書を有するプレゼンテーション・ユニット（例えば、ＰＵ１１）である。
　その次の優先キャッシュ対象ＰＵは、エントリ文書を有するＰＵ１１のリンク先ＰＵ、例えばＰＵ１２となる。
　さらに、ＰＵ１２のリンク先ＰＵ１３が次のキャッシュ対象ＰＵとして選択され、リンクを辿って、順次、キャッシュ対象ＰＵが選択される。
　キャッシュサイズを超えた時点で、キャッシュ対象ＰＵの選択が完了する。
　具体的には、例えば、
　ＰＵ１１サイズ≦キャッシュサイズ＜（ＰＵ１１＋ＰＵ１２）サイズ
　の場合は、ＰＵ１１のみをキャッシュ対象ＰＵとして選択する。
　また、（ＰＵ１１＋ＰＵ１２）サイズ≦キャッシュサイズ＜（ＰＵ１１＋ＰＵ１２＋ＰＵ１３）サイズ
　の場合は、ＰＵ１１とＰＵ１２をキャッシュ対象ＰＵとして選択する。
　このように、ＰＵの総計サイズが、キャッシュサイズに達するまでの範囲内で、キャッシュ対象ＰＵを、リンクを辿って順次、選択する。
　本例の場合は、
　（ＰＵ１１＋ＰＵ１２）サイズ≦キャッシュサイズ＜（ＰＵ１１＋ＰＵ１２＋ＰＵ１３）サイズ
　が満足され、ＰＵ１１とＰＵ１２をキャッシュ対象ＰＵとして選択する。
　　（ステップＳ１２６）
　次に、受信装置は、ステップＳ１２６において、ステップＳ１２５で決定したキャッシュ対象のプレゼンテーション・ユニット（ＰＵ）のＰＵＩＤと同じＰＵＩＤを持つファイルを取得して、キャッシュ処理を実行して、エントリ文書を出力（表示）する。
　図２５のステップＳ１２６ａ，ｂに示すように、受信装置は、Ｓ－ＴＳＩＤに記録されたファイル単位の情報から、キャッシュ対象ＰＵのＰＵＩＤと同じＰＵＩＤを持つファイルを選択して、これらのファイル単位情報に記録されたＴＯＩに基づいて放送波から該当ファイルを格納したパケットを選択取得する。選択取得したファイルをキャッシュ部に格納（キャッシュ）する処理を実行して、その後、エントリ文書からの出力（表示）処理を開始する。
　これらの処理によって、アプリケーション（ＡＰＰ１）の２つのプレゼンテーション・ユニット（ＰＵ１１，ＰＵ１２）に属する全てのファイルを取得することができる。
　従って、２つのプレゼンテーション・ユニット（ＰＵ）の全構成ファイルを利用したアプリケーションの実行が可能となり、プレゼンテーション・ユニット単位の完全な形態でのデータ再生が可能となる。
　すなわち、より完成度の高いアプリケーション実行処理が実現される。
　　［９－３．受信装置のデータ格納許容キャッシュサイズが中サイズ（Ｍｅｄｉｕｍ）であり、１つのアプリケーションが格納可能である場合の処理例について］
　次に、図２６以下を参照して、受信装置のデータ格納許容キャッシュサイズが中サイズ（Ｍｅｄｉｕｍ）であり、１つのアプリケーション（Ａｐｐ１）が格納可能である場合の処理例について説明する。
　図２６は、受信装置のデータ格納許容キャッシュサイズが中サイズ（Ｍｅｄｉｕｍ）である場合の、キャッシュ（格納）対象データを説明する図である。
　受信装置は、１つのアプリケーション（ＡＰＰ１）を格納可能である。
　受信装置の実行する処理は、アプリケーション（ＡＰＰ１）の起動後に最初に読み込まれるＨＴＭＬ文書（エントリ文書２２１）とリソースファイルで構成されるプレゼンテーション・ユニット（ＰＵ１１）の属するアプリケーション（ＡＰＰ１）の構成ファイル全てを取得し、キャッシュして表示する処理となる。
　図２７には、受信装置が放送波を介してアプリケーションを取得し、キャッシュ処理を行ない、実行するまでの処理シーケンスを説明するフローチャートを示している。
　さらに、図２８には、図２７に示すフローチャートの各ステップの処理に際して利用されるシグナリングデータを示している。
　（１）ＡＩＴ
　（２）Ｓ－ＴＳＩＤ
　これら２つのシグナリングデータである。
　図２７に示す各ステップ番号（Ｓ１３１～Ｓ１３５）の処理と、図２８に示す同じステップ番号（Ｓ１３１～Ｓ１３５）の処理は同一の処理である。図２８においては、各ステップの処理に際して参照するシグナリングデータ（ＡＩＴ，Ｓ－ＴＳＩＤ）の記録領域と各ステップ番号とを対応付けて示している。
　図２７、および図２８を参照して各ステップの処理について、順次、説明する。
　　（ステップＳ１３１）
　受信装置は、まず、ステップＳ１３１において、送信装置から送信されるＳＬＳ（サービスレベルシグナリング）からＡＩＴ（アプリケーション・インフォメーション・テーブル）、Ｓ－ＴＳＩＤを取得する。
　　（ステップＳ１３２）
　次に、受信装置は、ステップＳ１３２において、ＡＩＴから、配信アプリケーションに関する情報の取得、確認を行う。例えば、以下の処理を行なう。
　（１）アプリケーションロケーション（ａｐｐｌｉｃａｔｉｏｎＬｏｃａｔｉｏｎ）から、エントリ文書のＵＲＬを取得する。
　（２）コントロールコードがキャッシュ処理の必要なコード（ＡＵＴＯＳＴＡＲＴ，Ｐｒｅｆｅｔｃｈなど）に設定されていることを確認する。
　（３）アプリケーションＩＤを取得する。
　（４）アプリケーションサイズを取得する。
　（５）リンク先アプリケーションを取得する。
　（６）リンク先アプリケーションサイズを取得する。
　さらに、取得したアプリケーションサイズと、受信装置のキャッシャ可能なキャッシュサイズを比較する。
　本例では、キャッシュサイズ＝中（Ｍｅｄｉｕｍ）であり、アプリケーション（ＡＰＰ１）のアプリケーションサイズより大きく、アプリケーション（ＡＰＰ１）全体のキャッシュ処理ができると判断する。
　さらに、アプリケーションサイズにリンク先アプリケーションサイズを加算したデータサイズと、受信装置のキャッシャ可能なキャッシュサイズを比較する。
　本例では、キャッシュサイズ＝中（Ｍｅｄｉｕｍ）であり、このキャッシュサイズは、２つのアプリケーション（ＡＰＰ１，ＡＰＰ２）のアプリケーション合計サイズより小さく、２つのアプリケーション（ＡＰＰ１，ＡＰＰ２）全体のキャッシュ処理はできないと判断する。
　すなわち、１つのアプリケーション（ＡＰＰ１）のキャッシュ処理を実行することに決定する。
　　（ステップＳ１３３）
　次に、受信装置は、ステップＳ１３３において、Ｓ－ＴＳＩＤから、エントリ文書の取得先情報を取得する。
　具体的には、図２８のステップＳ１３３に示すように、Ｓ－ＴＳＩＤに記録されたファイル単位の情報に記録されたコンテンツロケーション情報（ＲＳ／ＬＳ／ＳｃＦｌｗ／ＥＦＤＴ／ｃｏｎｔｅｎｔ－ｌｏｃａｔｉｏｎ）と、ＡＩＴのアプリケーションロケーション（ａｐｐｌｉｃａｔｉｏｎＬｏｃａｔｉｏｎ）の一致するファイル（ＦＩＬＥ）を検索して、その取得先情報を取得する。
　　（ステップＳ１３４）
　次に、受信装置は、ステップＳ１３４において、エントリ文書のグループ（Ｇｒｏｕｐ）要素に記述されたプレゼンテーション・ユニットＩＤ（ＰＵＩＤ）から、アプリ本体ＩＤ（ａｐｐＩｄ）と、グループＩＤ（ｇｒｏｕｐＩｄ）を取得する。
　図２８のステップＳ１３４に示すように、プレゼンテーション・ユニットＩＤ（ＰＵＩＤ）は、アプリ本体ＩＤ（ａｐｐＩｄ）と、グループＩＤ（ｇｒｏｕｐＩｄ）から構成されている。
　アプリ本体ＩＤ（ａｐｐＩｄ）は、ファイルの属するプレゼンテーション・ユニット（ＰＵ）が属するアプリケーションに設定されたアプリケーションＩＤ（組織ＩＤ（ｏｒｇＩｄ）＋アプリ本体ＩＤ（ａｐｐＩｄ））の構成データであるアプリ本体ＩＤ（ａｐｐＩｄ）と同じ値である。
　　（ステップＳ１３５）
　次に、受信装置は、ステップＳ１３５において、エントリ文書のＰＵＩＤ（アプリ本体ＩＤ（ａｐｐＩｄ）＋グループＩＤ（ｇｒｏｕｐＩｄ））中のアプリ本体ＩＤ（ａｐｐＩｄ）と同じアプリ本体ＩＤ（ａｐｐＩｄ）を持つファイルを取得して、キャッシュ処理を実行して、出力（表示）する。
　図２８のステップＳ１３５に示すように、Ｓ－ＴＳＩＤに記録されたファイル単位の情報から、エントリ文書のＰＵＩＤを構成するアプリ本体ＩＤ（ａｐｐＩｄ）と同じアプリ本体ＩＤ（ａｐｐＩｄ）を持つファイルを取得して、キャッシュ処理を実行して、出力（表示）する。
　これらの処理によって、アプリケーション（ＡＰＰ１）に属する全てのプレゼンテーション・ユニット（ＰＵ１１，ＰＵ１２，ＰＵ１３）に属する全てのファイルを取得することができる。
　従って、アプリケーション（ＡＰＰ１）に属する全てのプレゼンテーション・ユニット（ＰＵ１１，ＰＵ１２，ＰＵ１３）の全構成ファイルを利用したアプリケーションの実行が可能となり、アプリケーション単位、およびプレゼンテーション・ユニット単位の完全な形態でのデータ再生が可能となる。
　すなわち、より完成度の高いアプリケーション実行処理が実現される。
　　［９－４．受信装置のデータ格納許容キャッシュサイズが大サイズ（Ｌａｒｇｅ）であり、複数のアプリケーションが格納可能である場合の処理例について］
　次に、図２９以下を参照して、受信装置のデータ格納許容キャッシュサイズが大サイズ（Ｌａｒｇｅ）であり、複数のアプリケーション（ＡＰＰ１，ＡＰＰ２）が格納可能である場合の処理例について説明する。
　図２９は、受信装置のデータ格納許容キャッシュサイズが大サイズ（Ｌａｒｇｅ）である場合の、キャッシュ（格納）対象データを説明する図である。
　受信装置は、２つのアプリケーション（ＡＰＰ１，ＡＰＰ２）を格納可能である。
　受信装置の実行する処理は、アプリケーション（ＡＰＰ１）の起動後に最初に読み込まれるＨＴＭＬ文書（エントリ文書２２１）とリソースファイルで構成されるプレゼンテーション・ユニット（ＰＵ１１）の属するアプリケーション（ＡＰＰ１）の構成ファイル、さらに、アプリケーション（ＡＰＰ１）のリンク先アプリケーションであるアプリケーション（ＡＰＰ２）の構成ファイル全てを取得し、キャッシュして表示する処理となる。
　図３０には、受信装置が放送波を介してアプリケーションを取得し、キャッシュ処理を行ない、実行するまでの処理シーケンスを説明するフローチャートを示している。
　さらに、図３１には、図３０に示すフローチャートの各ステップの処理に際して利用されるシグナリングデータを示している。
　（１）ＡＩＴ
　（２）Ｓ－ＴＳＩＤ
　これら２つのシグナリングデータである。
　図３０に示す各ステップ番号（Ｓ１４１～Ｓ１４５）の処理と、図３１に示す同じステップ番号（Ｓ１４１～Ｓ１４５）の処理は同一の処理である。図３１においては、各ステップの処理に際して参照するシグナリングデータ（ＡＩＴ，Ｓ－ＴＳＩＤ）の記録領域と各ステップ番号とを対応付けて示している。
　図３０、および図３１を参照して各ステップの処理について、順次、説明する。
　　（ステップＳ１４１）
　受信装置は、まず、ステップＳ１４１において、送信装置から送信されるＳＬＳ（サービスレベルシグナリング）からＡＩＴ（アプリケーション・インフォメーション・テーブル）、Ｓ－ＴＳＩＤを取得する。
　　（ステップＳ１４２）
　次に、受信装置は、ステップＳ１４２において、ＡＩＴから、配信アプリケーションに関する情報の取得、確認を行う。例えば、以下の処理を行なう。
　（１）アプリケーションロケーション（ａｐｐｌｉｃａｔｉｏｎＬｏｃａｔｉｏｎ）から、エントリ文書のＵＲＬを取得する。
　（２）コントロールコードがキャッシュ処理の必要なコード（ＡＵＴＯＳＴＡＲＴ，Ｐｒｅｆｅｔｃｈなど）に設定されていることを確認する。
　（３）アプリケーションＩＤを取得する。
　（４）アプリケーションサイズを取得する。
　（５）リンク先アプリケーションを取得する。
　（６）リンク先アプリケーションサイズを取得する。
　さらに、取得したアプリケーションサイズと、受信装置のキャッシャ可能なキャッシュサイズを比較する。
　本例では、キャッシュサイズ＝大（Ｌａｒｇｅ）であり、アプリケーション（ＡＰＰ１）のアプリケーションサイズより大きく、アプリケーション（ＡＰＰ１）全体のキャッシュ処理ができると判断する。
　さらに、アプリケーションサイズにリンク先アプリケーションサイズを加算したデータサイズと、受信装置のキャッシャ可能なキャッシュサイズを比較する。
　本例では、キャッシュサイズ＝大（Ｌａｒｇｅ）であり、このキャッシュサイズは、２つのアプリケーション（ＡＰＰ１，ＡＰＰ２）のアプリケーション合計サイズより大きく、２つのアプリケーション（ＡＰＰ１，ＡＰＰ２）全体のキャッシュ処理ができると判断する。
　さらに、リンク先アプリケーション（ＡＰＰ２）のリンク先アプリケーション（ＡＰＰ３）のサイズを取得して、３つのアプリの総計データサイズと、キャッシュサイズと比較する。
　本例では、キャッシュサイズは３つのアプリケーションの総計データサイズより小さく、３つのアプリケーション全ての格納（キャッシュ）はできないと判断する。
　結果として、２つのアプリケーション（ＡＰＰ１，ＡＰＰ２）のキャッシュ処理を実行することに決定する。
　　（ステップＳ１４３）
　次に、受信装置は、ステップＳ１４３において、Ｓ－ＴＳＩＤから、初期実行アプリ（ＡＰＰ１）のエントリ文書の取得先情報を取得する。
　具体的には、図３１のステップＳ１４３に示すように、Ｓ－ＴＳＩＤに記録されたファイル単位の情報に記録されたコンテンツロケーション情報（ＲＳ／ＬＳ／ＳｃＦｌｗ／ＥＦＤＴ／ｃｏｎｔｅｎｔ－ｌｏｃａｔｉｏｎ）と、ＡＩＴのアプリケーションロケーション（ａｐｐｌｉｃａｔｉｏｎＬｏｃａｔｉｏｎ）の一致するファイル（ＦＩＬＥ）を検索して、その取得先情報を取得する。
　なお、本例では、ＡＩＴに記録された２つのアプリケーションロケーション（ａｐｐｌｉｃａｔｉｏｎＬｏｃａｔｉｏｎ）の一致するファイル（ＦＩＬＥ）を検索して、その取得先情報を取得する。
　　（ステップＳ１４４）
　次に、受信装置は、ステップＳ１４４において、２つのアプリケーション各々のエントリ文書のグループ（Ｇｒｏｕｐ）要素に記述されたプレゼンテーション・ユニットＩＤ（ＰＵＩＤ）から、アプリ本体ＩＤ（ａｐｐＩｄ）と、グループＩＤ（ｇｒｏｕｐＩｄ）を取得する。
　図３１のステップＳ１４４に示すように、プレゼンテーション・ユニットＩＤ（ＰＵＩＤ）は、アプリ本体ＩＤ（ａｐｐＩｄ）と、グループＩＤ（ｇｒｏｕｐＩｄ）から構成されている。
　アプリ本体ＩＤ（ａｐｐＩｄ）は、ファイルの属するプレゼンテーション・ユニット（ＰＵ）が属するアプリケーションに設定されたアプリケーションＩＤ（組織ＩＤ（ｏｒｇＩｄ）＋アプリ本体ＩＤ（ａｐｐＩｄ））の構成データであるアプリ本体ＩＤ（ａｐｐＩｄ）と同じ値である。
　本例では、図３１のステップＳ１４４ａ，Ｓ１４４ｂに示すように、リンク元とリンク先の２つのアプリケーションＩＤ（ａｐｐＩｄ１，ａｐｐＩｄ２）を取得する。
　　（ステップＳ１４５）
　次に、受信装置は、ステップＳ１４５において、エントリ文書のＰＵＩＤ（アプリ本体ＩＤ（ａｐｐＩｄ）＋グループＩＤ（ｇｒｏｕｐＩｄ））中のアプリ本体ＩＤ（ａｐｐＩｄ）と同じアプリ本体ＩＤ（ａｐｐＩｄ）を持つファイルを取得して、キャッシュ処理を実行する。
　本例では、２つのアプリケーションＩＤ（ａｐｐＩｄ１，ａｐｐＩｄ２）を持つファイルを取得して、キャッシュ処理を実行し、アプリケーション１（ＡＰＰ１）のエントリ文書を用いてアプリケーションの実行を開始する。
　図３１のステップＳ１４５に示すように、Ｓ－ＴＳＩＤに記録されたファイル単位の情報から、エントリ文書のＰＵＩＤ（ＰＵＩｄ１１，ＰＵＩｄ２１）を構成するアプリ本体ＩＤ（ａｐｐＩｄ１，ａｐｐＩｄ２）と同じアプリ本体ＩＤ（ａｐｐＩｄ１，ａｐｐＩｄ２）を持つファイルを取得して、キャッシュ処理を実行して、出力（表示）する。
　これらの処理によって、アプリケーション（ＡＰＰ１）と、リンク先のアプリケーション（ＡＰＰ２）に属する全てのプレゼンテーション・ユニット（ＰＵ１１，ＰＵ１２，ＰＵ１３、ＰＵ２１，ＰＵ２２，ＰＵ２３）に属する全てのファイルを取得することができる。
　これにより、アプリケーション（ＡＰＰ１）に属する全てのプレゼンテーション・ユニット（ＰＵ１１，ＰＵ１２，ＰＵ１３）の全構成ファイルを利用したアプリケーションの実行、さらに、アプリケーション（ＡＰＰ２）に属する全てのプレゼンテーション・ユニット（ＰＵ２１，ＰＵ２２，ＰＵ２３）の全構成ファイルを利用したアプリケーションの実行が可能となる。
　すなわち、アプリケーション単位、およびプレゼンテーション・ユニット単位の完全な形態でのデータ再生が可能となる。
　すなわち、より完成度の高いアプリケーション実行処理が実現される。
　　［９－５．受信装置のデータ格納許容キャッシュサイズが最大サイズ（Ｍａｘｉｍｕｍ）であり、複数のアプリケーションが格納可能である場合の処理例について］
　次に、図３２以下を参照して、受信装置のデータ格納許容キャッシュサイズが最大サイズ（Ｍａｘｉｍｕｍ）であり、リンク関係の設定された３つ全てのアプリケーション（ＡＰＰ１，ＡＰＰ２，ＡＰＰ３）が格納可能である場合の処理例について説明する。
　図３２は、受信装置のデータ格納許容キャッシュサイズが最大サイズ（Ｍａｘｉｍｕｍ）である場合の、キャッシュ（格納）対象データを説明する図である。
　受信装置は、リンク関係の設定された３つ全てのアプリケーション（ＡＰＰ１，ＡＰＰ２，ＡＰＰ３）を格納可能である。
　受信装置の実行する処理は、アプリケーション（ＡＰＰ１）の起動後に最初に読み込まれるＨＴＭＬ文書（エントリ文書２２１）とリソースファイルで構成されるプレゼンテーション・ユニット（ＰＵ１１）の属するアプリケーション（ＡＰＰ１）の構成ファイル、さらに、アプリケーション（ＡＰＰ１）のリンク先アプリケーションであるアプリケーション（ＡＰＰ２）、さらに、アプリケーション（ＡＰＰ２）のリンク先アプリケーションであるアプリケーション（ＡＰＰ３）の構成ファイル全てを取得し、キャッシュして表示する処理となる。
　図３３には、受信装置が放送波を介してアプリケーションを取得し、キャッシュ処理を行ない、実行するまでの処理シーケンスを説明するフローチャートを示している。
　さらに、図３４には、図３３に示すフローチャートの各ステップの処理に際して利用されるシグナリングデータを示している。
　（１）ＡＩＴ
　（２）Ｓ－ＴＳＩＤ
　これら２つのシグナリングデータである。
　図３３に示す各ステップ番号（Ｓ１５１～Ｓ１５５）の処理と、図３４に示す同じステップ番号（Ｓ１５１～Ｓ１５５）の処理は同一の処理である。図３４においては、各ステップの処理に際して参照するシグナリングデータ（ＡＩＴ，Ｓ－ＴＳＩＤ）の記録領域と各ステップ番号とを対応付けて示している。
　図３３、および図３４を参照して各ステップの処理について、順次、説明する。
　　（ステップＳ１５１）
　受信装置は、まず、ステップＳ１５１において、送信装置から送信されるＳＬＳ（サービスレベルシグナリング）からＡＩＴ（アプリケーション・インフォメーション・テーブル）、Ｓ－ＴＳＩＤを取得する。
　　（ステップＳ１５２）
　次に、受信装置は、ステップＳ１５２において、ＡＩＴから、配信アプリケーションに関する情報の取得、確認を行う。例えば、以下の処理を行なう。
　（１）アプリケーションロケーション（ａｐｐｌｉｃａｔｉｏｎＬｏｃａｔｉｏｎ）から、エントリ文書のＵＲＬを取得する。
　（２）コントロールコードがキャッシュ処理の必要なコード（ＡＵＴＯＳＴＡＲＴ，Ｐｒｅｆｅｔｃｈなど）に設定されていることを確認する。
　（３）アプリケーションＩＤを取得する。
　（４）アプリケーションサイズを取得する。
　（５）リンク先アプリケーションを取得する。
　（６）リンク先アプリケーションサイズを取得する。
　さらに、取得したアプリケーションサイズと、受信装置のキャッシャ可能なキャッシュサイズを比較する。
　本例では、キャッシュサイズ＝最大（Ｍａｘｉｍｕｍ）であり、アプリケーション（ＡＰＰ１）のアプリケーションサイズより大きく、アプリケーション（ＡＰＰ１）全体のキャッシュ処理ができると判断する。
　さらに、アプリケーションサイズにリンク先アプリケーション（ＡＰＰ２）のサイズを加算したデータサイズと、受信装置のキャッシャ可能なキャッシュサイズを比較する。
　本例では、キャッシュサイズ＝最大（Ｍａｘｉｍｕｍ）であり、このキャッシュサイズは、２つのアプリケーション（ＡＰＰ１，ＡＰＰ２）のアプリケーション合計サイズより大きく、２つのアプリケーション（ＡＰＰ１，ＡＰＰ２）全体のキャッシュ処理ができると判断する。
　さらに、リンク先アプリケーション（ＡＰＰ２）のリンク先アプリケーション（ＡＰＰ３）のサイズを取得して、３つのアプリの総計データサイズと、キャッシュサイズと比較する。
　本例では、キャッシュサイズは３つのアプリケーションの総計データサイズより大きく、３つのアプリケーション全ての格納（キャッシュ）が可能であると判断する。
　結果として、リンク関係にある３つ全てのアプリケーション（ＡＰＰ１，ＡＰＰ２，ＡＰＰ３）のキャッシュ処理を実行することに決定する。
　　（ステップＳ１５３）
　次に、受信装置は、ステップＳ１５３において、Ｓ－ＴＳＩＤから、エントリ文書の取得先情報を取得する。
　具体的には、図３４のステップＳ１５３に示すように、Ｓ－ＴＳＩＤに記録されたファイル単位の情報に記録されたコンテンツロケーション情報（ＲＳ／ＬＳ／ＳｃＦｌｗ／ＥＦＤＴ／ｃｏｎｔｅｎｔ－ｌｏｃａｔｉｏｎ）と、ＡＩＴのアプリケーションロケーション（ａｐｐｌｉｃａｔｉｏｎＬｏｃａｔｉｏｎ）の一致するファイル（ＦＩＬＥ）を検索して、その取得先情報を取得する。
　なお、本例では、ＡＩＴに記録された３つのアプリケーションロケーション（ａｐｐｌｉｃａｔｉｏｎＬｏｃａｔｉｏｎ）の一致するファイル（ＦＩＬＥ）を検索して、その取得先情報を取得する。
　　（ステップＳ１５４）
　次に、受信装置は、ステップＳ１５４において、３つのアプリケーション各々のエントリ文書のグループ（Ｇｒｏｕｐ）要素に記述されたプレゼンテーション・ユニットＩＤ（ＰＵＩＤ）から、アプリ本体ＩＤ（ａｐｐＩｄ）と、グループＩＤ（ｇｒｏｕｐＩｄ）を取得する。
　図３４のステップＳ１５４に示すように、プレゼンテーション・ユニットＩＤ（ＰＵＩＤ）は、アプリ本体ＩＤ（ａｐｐＩｄ）と、グループＩＤ（ｇｒｏｕｐＩｄ）から構成されている。
　アプリ本体ＩＤ（ａｐｐＩｄ）は、ファイルの属するプレゼンテーション・ユニット（ＰＵ）が属するアプリケーションに設定されたアプリケーションＩＤ（組織ＩＤ（ｏｒｇＩｄ）＋アプリ本体ＩＤ（ａｐｐＩｄ））の構成データであるアプリ本体ＩＤ（ａｐｐＩｄ）と同じ値である。
　本例では、図３４のステップＳ１５４ａ，Ｓ１５４ｂ，Ｓ１５４ｃに示すように、リンク関係にある３つのアプリケーションＩＤ（ａｐｐＩｄ１，ａｐｐＩｄ２，ａｐｐＩｄ３）を取得する。
　　（ステップＳ１５５）
　次に、受信装置は、ステップＳ１５５において、エントリ文書のＰＵＩＤ（アプリ本体ＩＤ（ａｐｐＩｄ）＋グループＩＤ（ｇｒｏｕｐＩｄ））中のアプリ本体ＩＤ（ａｐｐＩｄ）と同じアプリ本体ＩＤ（ａｐｐＩｄ）を持つファイルを取得して、キャッシュ処理を実行する。
　本例では、３つのアプリケーションＩＤ（ａｐｐＩｄ１，ａｐｐＩｄ２，ａｐｐＩｄ３）を持つファイルを取得して、キャッシュ処理を実行し、アプリケーション１（ＡＰＰ１）のエントリ文書を用いてアプリケーションの実行を開始する。
　図３４のステップＳ１５５に示すように、Ｓ－ＴＳＩＤに記録されたファイル単位の情報から、エントリ文書のＰＵＩＤ（ＰＵＩｄ１１，ＰＵＩｄ２１，ＰＵＩｄ３１）を構成するアプリ本体ＩＤ（ａｐｐＩｄ１，ａｐｐＩｄ２，ａｐｐＩｄ３）と同じアプリ本体ＩＤ（ａｐｐＩｄ１，ａｐｐＩｄ２，ａｐｐＩｄ３）を持つファイルを取得して、キャッシュ処理を実行して、出力（表示）する。
　これらの処理によって、リンク関係の設定されたアプリケーション（ＡＰＰ１）と、アプリケーション（ＡＰＰ２）、およびアプリケーション（ＡＰＰ３）に属する全てのプレゼンテーション・ユニット（ＰＵ１１，ＰＵ１２，ＰＵ１３、ＰＵ２１，ＰＵ２２，ＰＵ２３，ＰＵ３１，ＰＵ３２）に属する全てのファイルを取得することができる。
　これにより、３つのアプリケーション（ＡＰＰ１～ＡＰＰ３）に属する全てのプレゼンテーション・ユニット（ＰＵ１１～ＰＵ３２）の全構成ファイルを利用したアプリケーションの実行が可能となる。
　すなわち、アプリケーション単位、およびプレゼンテーション・ユニット単位の完全な形態でのデータ再生が可能となる。
　すなわち、より完成度の高いアプリケーション実行処理が実現される。
　　［１０．受信装置におけるデータ処理の全体シーケンスについて］
　次に、図３５以下に示すフローチャートを参照して、受信装置の実行する主要な処理のシーケンスについて説明する。
　図３５以下に示すフローチャートは、受信装置において実行する例えば以下の処理を中心として説明するフローチャートである。
　（１）放送ストリームの受信処理、
　（２）アプリケーション構成ファイルのキャッシュ処理、
　（３）アプリケーションの実行およびアプリケーション間の遷移処理
　　［１０－１．受信装置における放送ストリーム受信処理の全体シーケンス］
　まず、図３５に示すフローを参照して受信装置の実行する放送ストリームの受信処理の全体シーケンスについて説明する。各ステップの処理について説明する。
　　（ステップＳ２０１）
　ステップＳ２０１は、受信装置において実行する選局処理である。
　これは、受信装置側のユーザによる受信チャンネル（例えば放送局）選択処理である。
　　（ステップＳ２０２）
　ステップＳ２０１において、１つの受信チャンネルが選択されると、ステップＳＺ２０２において、受信装置は、選択チャンネルに応じた放送ストリームの受信処理を実行する。
　この処理の詳細については、図３６以下のフローを参照して後段で説明する。
　　（ステップＳ２０３）
　ステップＳ２０３は、放送ストリームの受信終了の判定処理ステップである。例えばユーザによる受信装置の電源オフ等の処理をトリガとしてステップＳ２０２の放送ストリーム受信処理を終了する。
　放送ストリームの受信終了がなされない場合は、ステップＳ２０２の放送ストリームの受信処理を継続して実行する。
　　［１０－２．受信装置における放送ストリーム受信処理の詳細シーケンス］
　次に、図３６に示すフローを参照して受信装置の実行する放送ストリームの受信処理の詳細シーケンスについて説明する。各ステップの処理について説明する。
　　（ステップＳ２５１）
　受信装置は、放送ストリームの受信処理を開始すると、送信装置からの送信パケットの受信処理を開始する。
　なお、受信装置において選択されたチャンネルに従って選択されたチャンネル対応のデータ格納パケットを選択して取得する。
　なお、送信装置の送信するデータは、先に図２参照して説明したように、
　ＡＶセグメント、
　シグナリングデータ、
　アプリケーション等を含むＮＲＴデータ等、
　これら様々なデータがである。
　なお、シグナリングデータには、先に説明したＵＳＢＤ／ＵＳＤ、ＡＩＴ、Ｓ－ＴＳＩＤ等、様々な種類のシグナリングデータが含まれる。
　　（ステップＳ２５２）
　受信装置は、受信パケットのパケットヘッダ情報等を参照して、受信データが、
　ビデオ、音声、字幕データ等のＡＶセグメントであるか、
　アプリケーション等のＮＲＴデータであるか、
　シグナリングデータであるか、
　これらのいずれであるかを判定する。
　受信パケットが、ビデオ、音声、字幕データ等のＡＶセグメントを格納したパケットである場合は、ステップＳ２５３に進む。、
　受信パケットが、アプリケーション等のＮＲＴデータを格納したパケットである場合は、ステップＳ２５４に進む。、
　受信パケットが、ＵＳＢＤ／ＵＳＤ、ＡＩＴ、Ｓ－ＴＳＩＤ等のシグナリングデータを格納したパケットである場合は、ステップＳ２５５に進む。、
　　（ステップＳ２５３）
　受信パケットが、ビデオ、音声、字幕データ等のＡＶセグメントを格納したパケットである場合は、ステップＳ２５３において、受信パケットから、ビデオ、音声、字幕データ等を取り出し、所定の復号処理を実行し、レンダリング、すなわち再生出力処理を実行する。
　この処理は、例えば放送番組の再生出力処理である。
　　（ステップＳ２５４）
　受信パケットが、アプリケーション等のＮＲＴデータを格納したパケットである場合は、ステップＳ２５４において、シグナリングデータに基づいてＮＲＴデータを受信し、蓄積する処理を行なう。
　なお、ＮＲＴデータがアプリケーションである場合は、先に説明したように、ＵＳＢＤ／ＵＳＤ、ＡＩＴ、Ｓ－ＴＳＩＤ等のシグナリングデータの記録情報に従って、格納（キャッシュ）データの選択処理を伴う処理を実行する。
　すなわち、アプリケーションの格納（キャッシュ）処理に先行してアプリケーション対応のシグナリングデータの取得が実行され、先行取得したシグナリングデータの記述に従ってアプリケーションの選択的取、キャッシュ処理が実行されることになる。
　　（ステップＳ２５５）
　受信パケットが、ＵＳＢＤ／ＵＳＤ、ＡＩＴ、Ｓ－ＴＳＩＤ等のシグナリングデータを格納したパケットである場合は、ステップＳ２５５に進む。
　ステップＳ２５５では、シグナリングデータの受信、解析処理を実行する。
　この処理の詳細については、図３７のフローを参照して後段で説明する。
　　（ステップＳ２５６）
　ステップＳ２５６において、ステップＳ２５５におけるシグナリングデータの解析結果に基づいて、アプリケーションの取得処理が必要か否かを判定する。
　具体的には、受信装置がアプリケーションの取得処理を実行する設定となっているか、すなわち、アプリケーション取得処理フラグがＴｒｕｅに設定されているか否かを判定する処理を行なう。
　なお、このフラグ設定は、ステップＳ２５５においてシグナリングデータとしてＡＩＴを受信した場合に設定される。詳細については、後段において図３７に示すフローを参照して説明する。
　フラグ設定がアプリケーション取得処理を実行する設定になっている場合は、ステップＳ２５７に進む。
　アプリケーションの取得を行う設定でないと判定した場合は、ステップＳ２０２の放送ストリーム受信処理の開始位置に戻り、次のパケットの受信処理、すなわち、ステップＳ２５１以下の処理を実行する。
　　（ステップＳ２５７）
　ステップＳ２５６において、ステップＳ２５５におけるシグナリングデータの解析結果に基づいて、アプリケーションの取得処理が必要と判定した場合は、ステップＳ２５７に進み、アプリケーションの取得処理を実行する。
　この処理は、先に説明したＵＳＢＤ／ＵＳＤ、ＡＩＴ、Ｓ－ＴＳＩＤ等のシグナリングデータの記録情報に従ったアプリケーションの取得処理であり、キャッシュ対象データを自装置のキャッシュ容量に応じて選択する処理を伴う処理である。
　この処理については、図３８に示すフローを参照して後段で詳細に説明する。
　　［１０－３．受信装置におけるシグナリングの受信、解析処理の詳細シーケンス］
　次に、図３７に示すフローを参照して、図３６のステップＳ２５５において実行するシグナリングデータの受信、解析処理の詳細シーケンスについて説明する。
　以下、各ステップの処理について説明する。
　　（ステップＳ２８１）
　まず、受信装置は、ステップＳ２８１において、受信したシグナリングデータが、取得対象となるシグナリングデータであるか否かを判定する。
　未取得のシグナリングデータや、取得済みであっても取得済みシグナリングデータより新しいバージョンの更新されたシグナリングデータを受信した場合等は、取得対象のシグナリングデータであると判定してステップＳ２８２に進む。
　　（ステップＳ２８２）
　ステップＳ２８２において、受信装置は、シグナリングデータを取得する。
　なお、先に説明したように、シグナリングデータには、様々な種類がある。
　例えば、ＵＳＢＤ／ＵＳＤ、ＡＩＴ、Ｓ－ＴＳＩＤ等のシグナリングデータ、さらに、ＡＶストリーム対応のシグナリングデータであるＭＰＤ等、様々な種類のシグナリングデータがある。
　　（ステップＳ２８３）
　次に、受信装置は、ステップＳ２８３において、受信したシグナリングデータが、アプリケーションに対応する制御情報等を記録したＡＩＴ（アプリケーション・インフォメーション・テーブル）であるか否かを判定する。
　ＡＩＴである場合は、ステップＳ２８４に進む。
　ＡＩＴ以外のシグナリングデータである場合は、ステップＳ２８５に進む。
　　（ステップＳ２８４）
　ステップＳ２８３において、受信したシグナリングデータが、アプリケーションに対応する制御情報等を記録したＡＩＴ（アプリケーション・インフォメーション・テーブル）であると判定した場合、受信装置は、ステップＳ２８４において、アプリケーションの取得処理を実行する設定、すなわち、アプリケーション取得処理フラグをＴｒｕｅとする処理を行なう。
　　（ステップＳ２８５）
　一方、ステップＳ２８３において、受信したシグナリングデータが、アプリケーションに対応する制御情報等を記録したＡＩＴ（アプリケーション・インフォメーション・テーブル）でなく、その他のシグナリングデータあると判定した場合、受信装置は、ステップＳ２８５に進み、受信したＡＩＴ以外のシグナリングデータの解析、および受信シグナリングデータに従った処理を実行する。
　　［１０－４．受信装置におけるアプリケーションの取得、実行処理の詳細シーケンス］
　次に、図３８に示すフローを参照して、図３６のステップＳ２５７において実行するアプリケーションの取得、実行処理の詳細シーケンスについて説明する。
　以下、各ステップの処理について説明する。
　　（ステップＳ３０１）
　まず、受信装置は、ステップＳ３０１において、取得したＡＩＴから、アプリケーションに対する処理態様を規定したコントロールコード（ｃｔｒｌＣｏｄｅ）情報を取得し、コントロールコードがアプリケーションのキャッシュ処理を必要とするコードであるか否かを判定する。
　キャッシュ処理の必要なコードは、例えば、アプリケーションの即時実行を指定したコードである（ＡＵＴＯＳＴＡＲＴ）、あるいはアプリケーションを事前取得し、その後、所定時間に実行させるコードである（ＰＲＥＦＥＴＣＨ）等がある。
　ＡＩＴに記録されたコントロールコードが、これらのアプリケーションのキャッシュ処理を必要とするコードであることを確認すると、ステップＳ３０２に進む。
　なお、これら、キャッシュ処理が必要となるコードでない場合は、ステップＳ３０２以下の処理は実行されず、記録コードに応じた処理が実行されることになる。
　　（ステップＳ３０２）
　受信装置は、ＡＩＴに記録されたコントロールコードが、アプリケーションのキャッシュ処理を必要とするコードであることを確認すると、ステップＳ３０２において、ＡＩＴから、アプリケーションの取得先ＵＲＩを読み取る。
　すなわち、先に図１５を参照して説明したＡＩＴ記録情報中のアプリケーションアクセス情報（ａｐｐＬｏｃａｔｉｏｎ（ＵＲＩ））である。
　　（ステップＳ３０３～Ｓ３０４）
　次に、受信装置は、ステップＳ３０３において、もう１つのシグナリングデータであるＵＳＤ（またはＵＳＢＤ）を参照して、アプリケーションが放送波、または通信ネットワークのいずれを介して送信されるかを確認する。
　これは、先に図１２を参照して説明した処理であり、図１２に示すＵＳＤ（ＵＳＢＤ）に記録されたベースパターン情報を参照して確認する。
　図１２に示すＵＳＤ（ＵＳＢＤ）には、アプリケーションが放送波を介して送信される場合、放送波に対応するベースパターン記録領域（ＵＳＤ／ｄｅｌｉｖｅｒｙＭｅｔｈｏｄ／ａｔｓｃ：ＢｃＡｐｐＳｅｒｖｉｃｅ／ｂａｓｅＰａｔｔｅｒｎ）にベースパターンが記録される。
　一方、アプリケーションが通信ネットワークを介して送信される場合、通信ネットワークに対応するベースパターン記録領域（ＵＳＤ／ｄｅｌｉｖｅｒｙＭｅｔｈｏｄ／ａｔｓｃ：ＵｃＡｐｐＳｅｒｖｉｃｅ／ｂａｓｅＰａｔｔｅｒｎ）にベースパターンが記録される。
　受信装置は、ＵＳＤにどちらのベースパターンが記録されているかによって、アプリケーションが放送波を介して送信されるか、インターネット等の通信ネットワークを介して送信されるかを判定することができる。
　アプリケーションが放送波を介して送信されることが確認された場合は、ステップＳ３０５に進む。
　一方、アプリケーションがインターネット等の通信ネットワークを介して送信されることが確認された場合は、ステップＳ３０６に進む。
　　（ステップＳ３０５）
　アプリケーションが放送波を介して送信されることが確認された場合は、ステップＳ３０５にみ、ステップＳ３０５において、放送波を介したアプリケーション取得処理を実行する。
　この処理については、後段で図３９に示すフローを参照して詳細に説明する。
　　（ステップＳ３０６）
　一方、アプリケーションがインターネット等の通信ネットワークを介して送信されることが確認された場合は、ステップＳ３０６にみ、ステップＳ３０６において、通信ネットワークを介したアプリケーション取得処理を実行する。
　　（ステップＳ３０７）
　ステップＳ３０５、またはステップＳ３０６においてアプリケーションの取得処理が行われた後、受信装置は、ステップｓ３０７においてアプリケーションを実行する。
　なお、アプリケーションの実行タイミング等は、アプリケーション対応のＡＩＴに記録されており、受信装置は、ＡＩＴの記述に従ってアプリケーションの実行制御を行う。
　　［１０－５．受信装置における放送経由のアプリケーションの取得処理の詳細シーケンス］
　次に、図３９に示すフローを参照して、図３８のステップＳ３０５において実行する放送経由でのアプリケーションの取得処理の詳細シーケンスについて説明する。
　以下、各ステップの処理について説明する。
　　（ステップＳ３２１）
　まず、受信装置は、ステップＳ３２１において、受信装置の利用可能なキャッシュサイズを取得する。
　　（ステップＳ３２２）
　次に、受信装置は、ステップＳ３２２において、取得予定のアプリケーションのデータサイズ、すなわちアプリケーションサイズを取得する。
　アプリケーションサイズは、先に図１２を参照して説明したようにＡＩＴに記録されている。図１２に示すアプリケーションサイズ２５３（＠ａｐｐＳｉｚｅ）である。
　受信装置は、取得予定のアプリケーションに対応するＡＩＴを参照して、アプリケーションサイズを読み取る。
　　（ステップＳ３２３）
　次に、受信装置は、ステップＳ３２３において、受信装置の利用可能なキャッシュサイズと、アプリケーションサイズを比較する。
　キャッシュサイズが、アプリケーションサイズより小さい場合は、ステップＳ３２４に進む。
　一方、キャッシュサイズが、アプリケーションサイズ以上である場合は、ステップＳ３２５に進む。
　　（ステップＳ３２４）
　ステップＳ３２３におけるサイズ比較処理において、キャッシュサイズが、アプリケーションサイズより小さいと判定した場合は、ステップＳ３２４に進み、プレゼンテーション・ユニット（ＰＵ）単位のキャッシュ処理を実行する。
　この処理は、先に図２０～図２５を参照して説明した処理、すなわち、
　キャッシュサイズが最小サイズ（Ｍｉｎｉｍｕｍ）、または小サイズ（Ｓｍａｌｌ）の場合の処理に相当する処理である。
　　（ステップＳ３２５）
　一方、ステップＳ３２３におけるサイズ比較処理において、キャッシュサイズが、アプリケーションサイズ以上であると判定した場合は、ステップＳ３２５に進み、アプリケーション単位のキャッシュ処理を実行する。
　この処理は、先に図２６～図３４を参照して説明した処理、すなわち、
　キャッシュサイズが中サイズ（Ｍｅｄｉｕｍ）、または大サイズ（Ｌａｒｇｅ）、または最大サイズ（Ｍａｘｉｍｕｍ）の場合の処理に相当する処理である。
　　［１０－６．受信装置におけるプレゼンテーション・ユニット（ＰＵ）単位のキャッシュ処理の詳細シーケンス］
　次に、図４０に示すフローを参照して、図３９のステップＳ３２４において実行するプレゼンテーション・ユニット（ＰＵ）単位のキャッシュ処理の詳細シーケンスについて説明する。
　以下、各ステップの処理について説明する。
　　（ステップＳ３４１）
　まず、受信装置は、ステップＳ３４１において、送信装置から送信されるシグナリングデータであるＳ－ＴＳＩＤから、エントリ文書を含むプレゼンテーション・ユニット（ＰＵ）と、このＰＵからリンクするプレゼンテーション・ユニット（ＰＵ）のＩＤ（ＰＵＩＤ）を取得する。
　受信装置は、先に図１６を参照して説明したＳ－ＴＳＩＤにおけるプレゼンテーション・ユニット間リンク情報２６１を参照して、リンク関係にあるＰＵのＩＤを取得する。
　　（ステップＳ３４２）
　次に、受信装置は、受信装置のキャッシュサイズ、すなわち利用可能なキャッシュサイズと、各プレゼンテーション・ユニット（ＰＵ）のデータサイズを比較して、キャッシュ対象とするプレゼンテーション・ユニットを選択する。
　なお、最優先キャッシュ対象ＰＵは、エントリ文書を有するプレゼンテーション・ユニット（例えば、ＰＵ１１）である。
　その次の優先キャッシュ対象ＰＵは、エントリ文書を有するＰＵ１１のリンク先ＰＵ、例えばＰＵ１２となる。
　さらに、ＰＵ１２のリンク先ＰＵ１３が次のキャッシュ対象ＰＵとして選択され、リンクを辿って、順次、キャッシュ対象ＰＵが選択される。
　キャッシュサイズを超えた時点で、キャッシュ対象ＰＵの選択が完了する。
　具体的には、例えば、
　ＰＵ１１サイズ≦キャッシュサイズ＜（ＰＵ１１＋ＰＵ１２）サイズ
　の場合は、ＰＵ１１のみをキャッシュ対象ＰＵとして選択する。
　また、（ＰＵ１１＋ＰＵ１２）サイズ≦キャッシュサイズ＜（ＰＵ１１＋ＰＵ１２＋ＰＵ１３）サイズ
　の場合は、ＰＵ１１とＰＵ１２をキャッシュ対象ＰＵとして選択する。
　このように、ＰＵの総計サイズが、キャッシュサイズに達するまでの範囲内で、キャッシュ対象ＰＵを、リンクを辿って順次、選択する。
　　（ステップＳ３４３）
　次に、受信装置は、ステップＳ３４２で決定したキャッシュ対象プレゼンテーション・ユニット（ＰＵ）を取得して、キャッシュ部（記憶部）にキュッシュ（格納）する。
　その後、図３８のフローに示すステップＳ３０７において、キャッシュされたプレゼンテーション・ユニットを利用してアプリケーションが実行される。
　なお、この図４０に示すフローに従った処理は、先に図２０～図２５を参照して説明した処理、すなわち、
　キャッシュサイズが最小サイズ（Ｍｉｎｉｍｕｍ）、または小サイズ（Ｓｍａｌｌ）の場合の処理に相当する処理である。
　先に説明したように、１つのプレゼンテーション・ユニット（ＰＵ：Ｐｅｒｅｓｅｎｔａｔｉｏｎ　Ｕｎｉｔ）は、１つまたは複数のＨＴＭＬ（ＨｙｐｅｒＴｅｘｔ　Ｍａｒｋｕｐ　Ｌａｎｇｕａｇｅ）を利用して提示されるデータのセットによって構成される。
　具体的には、１つのプレゼンテーション・ユニット（ＰＵ）は、以下の構成要素からなるユニットである。
　（１）１つまたは複数のＨＴＭＬファイル
　（２）上記ＨＴＭＬに従って出力される画像（動画、静止画）ファイル、
　（３）上記ＨＴＭＬに従って出力される音声ファイル、
　（４）上記ＨＴＭＬに従ったデータ出力スタイルを規定したスタイルシート格納ファイル、
　例えば、上記構成要素によって１つのプレゼンテーション・ユニット（ＰＵ）が設定される。
　１つのプレゼンテーション・ユニット（ＰＵ）に属するデータが全て取得できれば、そのプレゼンテーション・ユニット（ＰＵ）に含まれるＨＴＭＬ文書によるデータ出力、例えばＷｅｂペーシの出力が完全な形で実行されることが保証される。
　　［１０－７．受信装置におけるアプリケーション単位のキャッシュ処理の詳細シーケンス］
　次に、図４１に示すフローを参照して、図３９のステップＳ３２５において実行するアプリケーション単位のキャッシュ処理の詳細シーケンスについて説明する。
　以下、各ステップの処理について説明する。
　　（ステップＳ３６１）
　まず、受信装置は、ステップＳ３６１において、送信装置から送信されるシグナリングデータであるＡＩＴから、初期実行アプリケーションと、そのアプリケーションのリンク先アプリケーションの情報を取得する。
　受信装置は、例えば、先に図１５を参照して説明したＡＩＴにおけるリンク先アプリケーション情報２５４を参照して、リンク関係にあるアプリケーションの情報を取得する。
　　（ステップＳ３６２）
　次に、受信装置は、受信装置のキャッシュサイズ、すなわち利用可能なキャッシュサイズと、各アプリケーションのデータサイズを比較して、キャッシュ対象とするアプリケーションを選択する。
　なお、最優先キャッシュ対象アプリケーションは、ＡＩＴによって指定された初期起動アプリケーション（例えば、ＡＰＰ１）である。
　その次の優先キャッシュ対象アプリは、初期起動アプリ１（ＡＰＰ１）のリンク先アプリ、例えばＡＰＰ２となる。
　さらに、アプリ２（ＡＰＰ２）のリンク先アプリ３（ＡＰＰ３）が次のキャッシュ対象アプリとして選択され、リンクを辿って、順次、キャッシュ対象アプリが選択される。
　キャッシュサイズを超えた時点で、キャッシュ対象アプリの選択が完了する。
　具体的には、例えば、
　アプリ１（ＡＰＰ１）サイズ≦キャッシュサイズ＜（アプリ１（ＡＰＰ１）＋アプリ２（ＡＰＰ２））サイズ
　の場合は、アプリ１（ＡＰＰ１）のみをキャッシュ対象ＰＵとして選択する。
　また、アプリ１（ＡＰＰ１）＋アプリ２（ＡＰＰ２））サイズ≦キャッシュサイズ＜（アプリ１（ＡＰＰ１）＋アプリ２（ＡＰＰ２）＋アプリ３（ＡＰＰ３））サイズ
　の場合は、アプリ１（ＡＰＰ１）と、アプリ２（ＡＰＰ２）をキャッシュ対象ＰＵとして選択する。
　このように、アプリの総計サイズが、キャッシュサイズに達するまでの範囲内で、キャッシュ対象アプリを、リンクを辿って順次、選択する。
　　（ステップＳ３６３）
　次に、受信装置は、ステップＳ３６２で決定したキャッシュ対象アプリケーションを取得して、キャッシュ部（記憶部）にキュッシュ（格納）する。
　その後、図３８のフローに示すステップＳ３０７において、キャッシュされたアプリケーションを利用してアプリケーションが実行される。
　なお、この図４１に示すフローに従った処理は、先に図２６～図３４を参照して説明した処理、すなわち、
　キャッシュサイズが中サイズ（Ｍｅｄｉｕｍ）、または大サイズ（Ｌａｒｇｅ）、または最大サイズ（Ｍａｘｉｍｕｍ）の場合の処理に相当する処理である。
　先に説明したように、１つのアプリケーションには１つ以上のプレゼンテーション・ユニット（ＰＵ：Ｐｅｒｅｓｅｎｔａｔｉｏｎ　Ｕｎｉｔ）が含まれる。プレゼンテーション・ユニット（ＰＵ）は、
　（１）１つまたは複数のＨＴＭＬファイル
　（２）上記ＨＴＭＬに従って出力される画像（動画、静止画）ファイル、
　（３）上記ＨＴＭＬに従って出力される音声ファイル、
　（４）上記ＨＴＭＬに従ったデータ出力スタイルを規定したスタイルシート格納ファイル、
　例えば、上記構成要素によって構成される。
　１つのプレゼンテーション・ユニット（ＰＵ）に属するデータが全て取得できれば、そのプレゼンテーション・ユニット（ＰＵ）に含まれるＨＴＭＬ文書によるデータ出力、例えばＷｅｂペーシの出力が完全な形で実行されることが保証される。
　本開示のキャッシュ処理は、アプリケーション単位、またはプレゼンテーション・ユニット（ＰＵ）単位でキャッシュ処理を実行する。
　すなわち、最小キャッシュ単位は、プレゼンテーション・ユニット（ＰＵ）であり、ＰＵを構成するデータの一部がキャッシュされていないといった事態を発生させることかない。
　従って、プレゼンテーション・ユニット（ＰＵ）のに含まれるＨＴＭＬ文書による完成されたデータ出力が実行される。
　　［１０－８．受信装置におけるアプリケーションまたはプレゼンテーション・ユニット（ＰＵ）間の遷移処理シーケンス］
　次に、図４２に示すフローを参照して、アプリケーション実行中に発生するアプリケーションまたはプレゼンテーション・ユニット（ＰＵ）間の遷移処理シーケンスについて説明する。
　以下、各ステップの処理について説明する。
　　（ステップＳ５０１～Ｓ５０２）
　以下において説明する処理は、受信装置において所定のアプリケーションを実行中に行われる処理である。
　受信装置は、ステップＳ５０１において遷移イベントを待機する。
　なお、ここで遷移とは、実行中のアプリケーションからリンク先アプリへの遷移であるアプリ間遷移、または、実行中のプレゼンテーション・ユニット（ＰＵ）からリンク先のプレゼンテーション・ユニット（ＰＵ）への遷移であるＰＵ間遷移のいずれかである。
　なお、遷移イベントは、例えばＡＩＴの制御情報、あるいは、例えばユーザの操作に基づいて発生するリンク先への遷移を指示するイベントである。
　受信装置は、遷移イベントを検出するとステップＳ５０３に進む。
　　（ステップＳ５０３）
　受信装置は、遷移イベントの検出に応じて、ステップＳ５０３において、遷移先のアプリケーション、またはプレゼンテーション・ユニット（ＰＵ）がキャッシュ済みであるか否かを判定する。
　キャッシュ済みである場合は、ステップＳ５０４に進む。
　一方、キャッシュ済みでない場合は、ステップＳ５０５に進む。
　　（ステップＳ５０４）
　ステップＳ５０３において、遷移先のアプリケーション、またはプレゼンテーション・ユニット（ＰＵ）がキャッシュ済みであると判定した場合は、ステップＳ５０４において、遷移先のアプリケーション、またはプレゼンテーション・ユニット（ＰＵ）をキャッシュ部から取得して実行する。
　　（スップＳ５０５）
　一方、ステップＳ５０３において、遷移先のアプリケーション、またはプレゼンテーション・ユニット（ＰＵ）がキャッシュ済みでないと判定した場合は、ステップＳ５０５において、遷移態様が、以下のいずれであるかを確認する。
　（ａ）アプリケーション内のブレゼンテーション・ユニット（ＰＵ）間の遷移、
　（ｂ）アプリケーション間の遷移、
　（ａ）アプリケーション内のブレゼンテーション・ユニット（ＰＵ）間の遷移である場合は、ステップＳ５０６に進む。
　一方、（ｂ）アプリケーション間の遷移である場合は、ステップＳ５０７に進む。
　　（ステップＳ５０６）
　ステップＳ５０５において、遷移イベントが、（ａ）アプリケーション内のブレゼンテーション・ユニット（ＰＵ）間の遷移である場合は、ステップＳ５０６において、遷移先のプレゼンテーション・ユニット（ＰＵ）のキャッシュ処理を実行する。
　この処理は、先に図４０を参照して説明したプレゼンテーション・ユニット（ＰＵ）単位のキャッシュ処理と同じ処理である。
　このキャッシュ処理を実行した後、キャッシュしたプレゼンテーション・ユニット（ＰＵ）をキャッシュ部から取得して実行する。
　　（ステップＳ５０７）
　一方、ステップＳ５０５において、遷移イベントが、（ｂ）アプリケーション間の遷移である場合は、ステップＳ５０７において、遷移先のアプリケーションを取得してキャッシュ処理を実行し、その後、キャッシュアプリケーションを実行する。
　この処理は、先に図３８を参照して説明したアプリケーションの取得、実行処理と同じ処理である。
　このように、リンク先のアプリケーション、またはプレゼンテーション・ユニット（ＰＵ）がキャッシュされていない場合においても、リンク先に応じてキャッシュ対象をアプリケーション、またはプレゼンテーション・ユニット（ＰＵ）単位としたキャッシュ処理を実行する。
　　［１１．アプリケーション遷移処理の具体例について］
　次に、図４２に示すフローチャートを参照して説明したアプリケーションの遷移処理の具体例について説明する。
　図４３、図４４を参照して、以下の２つの遷移処理例について説明する。
　（例１）番組再生に併せて実行される番組連動アプリからＣＭアプリへの遷移処理例
　（例２）番組再生アプリからＣＭアプリへの遷移処理例
　まず、図４３を参照して、
　（例１）番組再生に併せて実行される番組連動アプリからＣＭアプリへの遷移処理例
　について説明する。
　図４３には、受信装置の選択したチャンネルに対応して、送信装置が放送波を介して提供する以下の４つのデータを示している。
　（ａ）画像（Ｖｉｄｅｏ）
　（ｂ）音声（Ａｕｄｉ）
　（ｃ）ＮＲＴ（アプリケーション（ＡＰＰ））
　（ｄ）シグナリングデータ
　受信装置は、図４３に示すステップＳ７０１～Ｓ７０７の処理を実行する。
　各処理ステップについて、順次、説明する。
　　（ステップＳ７０１）
　まず、受信装置は、ステップＳ７０１において、送信装置の送信するシグナリングデータを受信する。
　シグナリングデータには、様々な種類があり、ＵＳＢＤ／ＵＳＤ、ＡＩＴ、Ｓ－ＴＳＩＤ、さらに、番組再生に利用されるＭＰＤ等がある。
　受信装置は、これらのシグナリンクデータを受信する。
　　（ステップＳ７０２）
　次に、受信装置は、ステップＳ７０２において、受信したシグナリングデータを解析し、解析結果に基づいて番組構成データであるＡＶセグメント、アプリのケーションリソース等のアクセス情報等、番組再生やアプリケーションの実行に必要となる情報を取得する。
　　（ステップＳ７０３）
　次に、受信装置は、ステップＳ７０３において、ステップＳ７０２で取得したシグナリングデータ解析情報に基づいて、番組を構成するＡＶセグメントやアプリケーションリソース等のデータ取得処理、キャッシュ処理を実行する。
　本例では、番組再生に必要となるＡＶセグメント、および番組再生に併せて実行させる番組連動アプリ（ＡＰＰ１）、さらに、番組連動アプリ（ＡＰＰ１）のリンク先（遷移先）アプリであるＣＭアプリケーション（ＣＭ　ＡＰＰ）を取得し、キャッシュ部に格納する。
　　（ステップＳ７０４）
　受信装置は、ステップＳ７０４において、放送波を介して取得したＡＶセグメントを用いて番組再生を行ない、さらに番組再生に並列して番組連動アプリ（ＡＰＰ１）を実行する。
　例えば、一例として、番組が野球中継であり、番組連動アプリ（ＡＰＰ１）は出場選手の選手情報提供アプリケーション等の組み合わせ等がある。
　　（ステップＳ７０５）
　次に、受信装置に対して、シグナリングデータによるイベント通知がなされる。
　このイベント通知は、実行アプリケーションの切り替えを要求するイベント通知で、すなわちアプリケーション間遷移通知イベントである。
　　（ステップＳ７０６）
　受信装置は、このアプリ遷移イベントの検出に応じて、アプリケーションの遷移処理を実行する。
　この処理の具体的処理シーケンスは、図４２に示すフローチャートに従った処理となる。
　ここで、遷移先のアプリケーションは、ＣＭアプリケーション（ＣＭ　ＡＰＰ）であるものとする。
　　（ステップＳ７０７）
　受信装置は、ステップＳ７０７において、予めキャッシュされているＣＭアプリケーション（ＣＭ　ＡＰＰ）を利用してＣＭの再生処理を開始する。
　例えば、ここで再生するＣＭアプリは、先に図６を参照して説明したように、視聴者に応じたＣＭとして設定することができる。
　送信装置が、様々な視聴者に対応した異なるＣＭアプリを送信する構成として、受信装置側で、予め登録したユーザ情報に応じて受信するＣＭアプリを選択してキャッシュする。
　このようなアプリの選択取得処理を実行することで、ユーザ（視聴者）の年齢、性別、好み等に応じた最適なユーザ対応ＣＭを表示することも可能となる。
　次に、図４４を参照して、
　（例２）番組再生アプリからＣＭアプリへの遷移処理例
　について説明する。
　図４４にも、図４３と同様、受信装置の選択したチャンネルに対応して、送信装置が放送波を介して提供する以下の４つのデータを示している。
　（ａ）画像（Ｖｉｄｅｏ）
　（ｂ）音声（Ａｕｄｉ）
　（ｃ）ＮＲＴ（アプリケーション（ＡＰＰ））
　（ｄ）シグナリングデータ
　受信装置は、図４４に示すステップＳ８０１～Ｓ８０７の処理を実行する。
　各処理ステップについて、順次、説明する。
　　（ステップＳ８０１）
　まず、受信装置は、ステップＳ８０１において、送信装置の送信するシグナリングデータを受信する。
　シグナリングデータには、様々な種類があり、ＵＳＢＤ／ＵＳＤ、ＡＩＴ、Ｓ－ＴＳＩＤ、さらに、番組再生に利用されるＭＰＤ等がある。
　受信装置は、これらのシグナリンクデータを受信する。
　　（ステップＳ８０２）
　次に、受信装置は、ステップＳ８０２において、受信したシグナリングデータを解析し、解析結果に基づいて番組構成データであるＡＶセグメント、アプリのケーションリソース等のアクセス情報等、番組再生やアプリケーションの実行に必要となる情報を取得する。
　　（ステップＳ８０３）
　次に、受信装置は、ステップＳ８０３において、ステップＳ７０２で取得したシグナリングデータ解析情報に基づいて、番組を構成するＡＶセグメントやアプリケーションリソース等のデータ取得処理、キャッシュ処理を実行する。
　本例では、番組再生に必要となるＡＶセグメント、および番組再生処理を実行する番組再生アプリ（ＡＰＰ１）、さらに、番組再生アプリ（ＡＰＰ１）のリンク先（遷移先）アプリであるＣＭアプリケーション（ＣＭ　ＡＰＰ）を取得し、キャッシュ部に格納する。
　　（ステップＳ８０４）
　受信装置は、ステップＳ８０４において、放送波を介して取得したＡＶセグメントと番組再生アプリ（ＡＰＰ１）を用いて番組再生を行なう。
　　（ステップＳ８０５）
　次に、受信装置は、例えばＡＩＴ等のシグナリングデータ、あるいは、ユーザの操作（リモコン操作）等によるイベントを検出する。
　このイベントは、実行アプリケーションの切り替えを要求するイベントである。すなわちアプリケーション間遷移通知イベントである。
　　（ステップＳ８０６）
　受信装置は、このアプリ遷移イベントの検出に応じて、アプリケーションの遷移処理を実行する。
　この処理の具体的処理シーケンスは、図４２に示すフローチャートに従った処理となる。
　ここで、遷移先のアプリケーションは、ＣＭアプリケーション（ＣＭ　ＡＰＰ）であるものとする。
　　（ステップＳ８０７）
　受信装置は、ステップＳ８０７において、予めキャッシュされているＣＭアプリケーション（ＣＭ　ＡＰＰ）を利用してＣＭの再生処理を開始する。
　この例においても、ＣＭアプリは、先に図６を参照して説明したように、視聴者に応じたＣＭとして設定することができる。
　送信装置が、様々な視聴者に対応した異なるＣＭアプリを送信する構成として、受信装置側で、予め登録したユーザ情報に応じて受信するＣＭアプリを選択してキャッシュする。
　このようなアプリの選択取得処理を実行することで、ユーザ（視聴者）の年齢、性別、好み等に応じた最適なユーザ対応ＣＭを表示することも可能となる。
　　［１２．サービスワーカー（ＳＷ）を利用したキュッシュ制御処理例について］
　次に、サービスワーカー（ＳＷ）を利用してアプリケーションのキャッシュ制御を行う処理例について説明する。
　まず、サービスワーカー（ＳＷ：Ｓｅｒｖｉｃｅ　Ｗｏｒｋｅｒ）の概要について、図４５～図４７を参照して説明する。
　サービスワーカー（ＳＷ）は、放送サーバや、広告サーバ等の送信装置２０から受信装置３０に提供される。
　サービスワーカー（ＳＷ）は、受信装置（クライアント）３０において実行されるアプリケーションや、アプリケーションの実行時に利用されるデータファイル等の取得処理や、記憶部（キャッシュ）に対する格納処理、さらに更新処理、削除処理等を実行するプログラムである。具体的には、例えばＪａｖａＳｃｒｉｐｔ（登録商標）によって構成される。
　サービスワーカー（ＳＷ）は、例えば送信装置２０が提供する放送番組（放送コンテンツ）に対応して設定され、送信装置２０から受信装置３０に提供されるアプリケーションの制御および管理プログラムとして、受信装置３０に提供される。
　サービスワーカー（ＳＷ）、アプリケーション、およびアプリケーションの実行時に利用されるデータファイル、これらは、例えば先に図２、図３を参照して説明したＮＲＴコンテンツ（ノンリアルタイムコンテンツ）として、送信装置２０から受信装置３０に提供される。
　あるいは、放送番組を配信するサーバとは別のデータ提供サーバが、サービスワーカー（ＳＷ）、アプリケーション、およびアプリケーションの実行時に利用されるデータファイルを受信装置３０に提供する構成としてもよい。
　サービスワーカー（ＳＷ）は、例えば、受信装置３０においてＷｅｂページ等の閲覧処理を実行するために利用されるプログラムであるブラウザを利用して情報表示を実行するアプリケーション等の管理（取得、保持、更新、削除等）処理などを実行する。
　サービスワーカー（ＳＷ）を利用した処理の具体例（ユースケース）について、図４５、図４６を参照して説明する。
　図４５は、受信装置３０が、放送サーバ２１等の送信装置２０から、ある番組コンテンツを受信し、受信装置３０の表示部に表示している状態を示している。
　放送サーバ２１等の送信装置２０は、番組配信に併せて、ＮＲＴコンテンツ（ノンリアルタイムコンテンツ）として、天気情報を表示するアプリケーション、およびこの天気情報表示アプリケーションに利用される様々なデータファイル、例えば動画、静止画、音声等の様々なデータを含むデータファイル（リソース）を受信装置３０に提供する。
　放送サーバ２１は、さらに、これらの「リソース」を管理するリソース管理プログラムとして、サービスワーカー（ＳＷ）を、やはりＮＲＴコンテンツ（ノンリアルタイムコンテンツ）として受信装置３０に提供する。
　受信装置３０は、送信装置２０から受信した「リソース」、すなわちアプリケーションおよびデータファイルを利用して、図４５に示すように、番組表示に併せて、天気情報の表示を行うことができる。
　このような、アプリケーションを利用したデータ表示は、これまでのデータ配信構成では、アプリケーションの提供される番組の終了とともに実行できなくなってしまう。
　これは、天気情報表示アプリケーション等のリソースは、番組受信中は、受信装置３０において利用可能な設定、例えば、一時記憶キャッシュに格納され、利用可能な状態に設定されるが、番組終了、あるいはユーザがチャンネルを切り替えると、これらのキャッシュデータが消去、あるいはアクセス不可能な状態に設定されてしまうためである。
　サービスワーカー（ＳＷ）は、このような番組対応のアプリケーションやデータを、番組終了後や、チャンネル切り替え後、あるいは放送の非受信状態、ネットワーク非接続状態等のオフライン状態であっても利用可能とするためのリソース管理プログラムとして機能する。
　図４６に示すように、天気情報表示アプリケーションを、このアプリを提供した番組の終了後や、他のチャンネルに切り換え後、あるいはデータ受信を実行していないオフライン状態であっても、利用することが可能となる。すなわち天気情報を受信装置３０の表示部に表示して閲覧することが可能となる。
　なお、天気情報表示アプリケーションは、例えばブラウザ上で表示されるプログラムである。
　この天気情報表示アプリケーションは、サービスワーカー（ＳＷ）の制御によって、受信装置３０の記憶部（キャッシュ）に格納される。例えばユーザによる表示要求等のリクエスト（イベント）があると、サービスワーカー（ＳＷ）の制御によって、の記憶部（キャッシュ）から読み出され、表示部に表示される。
　なお、アプリケーション等のリソースを格納する記憶部（キャッシュ）は、受信装置３０の電源がオフとなっても格納データが消去されない不揮発性メモリとすることが好ましい。
　このように、サービスワーカー（ＳＷ）を利用することで、様々な番組対応アプリケーションを、番組の表示、非表示と無関係に利用することが可能となる。
　なお、サービスワーカー（ＳＷ）は、例えばある番組対応のリソース（アプリケーション、およびアプリ関連データ）単位ごとに設定され、リソースに併せて、あるいはリソース送信に前後して送信装置２０から受信装置３０に提供される。
　サービスワーカー（ＳＷ）は、各番組対応の設定とすることもできるが、複数番組を含む特定のチャンネル対応のリソースに対して、共通に利用可能としたサービスワーカー（ＳＷ）を設定することもできる。
　サービスワーカー（ＳＷ）と、サービスワーカー（ＳＷ）によって管理されるリソース（アプリケーションおよびアプリ関連データ）は、受信装置３０の記憶部（キャッシュ）に格納される。
　このサービスワーカー（ＳＷ）を利用してキャッシュ制御処理を実行させる構成とすることができる。
　すなわち、先に、図４０をに示すフローチャートを参照して説明したプレゼンテーション・ユニット（ＰＵ）単位のキャッシュ処理や、図４１を参照して説明したアプリケーション単位のキャッシュ制御処理を実行させる構成とすることができる。
　図４７は、サービスワーカー（ＳＷ）を利用した処理の一例を説明する図である。
　図４７には、受信装置３０が送信装置２０からリソースとしてのＷｅｂページ（例えば図４５、図４６に示す天気情報表示ページ）を取得して受信装置３０の記憶部（キャッシュ）に格納して利用するシーケンスの一例を示している。
　なお、Ｗｅｂページは、所定のＷｅｂページ表示アプリケーションと、表示用データによって構成されるリソースを利用して表示される。
　図４７には、受信装置内のブラウザ４５０の構成要素として表示処理部４５１、サービスワーカー（ＳＷ）４５２、キャッシュ（記憶部）４５３を示している。
　ステップＳ８５１～Ｓ８５２は、受信装置３０による送信装置２０に対する初回アクセス処理によるリソース（Ｗｅｂページ）取得処理である。
　これは、例えば放送サーバ等の送信するＮＲＴコンテンツから取得される。
　このリソース取得処理に際してサービスワーカー（ＳＷ）を適用し、キャッシュサイズとアプリサイズやプレゼンテーション・ユニット（ＰＵ）サイズに応じたリソース取得処理を実行させる。
　すなわち、最小キャッシュサイズをブレゼンテーション・ユニット（ＰＵ）としたキャッシュ処理を実行する。
　このキャッシュ処理によるリソース取得後、表示処理部４５１によって、アプリケーション実行によるＷｅｂページ４５５が、受信装置３０の表示部に表示される。この表示は、このＷｅｂページを提供している番組に併せて表示されている状態であり、先に図４５を参照して説明した表示状態に相当する。
　その後、番組終了後、あるいはチャンネル切り替え後、あるいはオフライン設定状態において、ステップＳ８５５において、ユーザがＷｅｂペーシの閲覧要求を行う。
　サービスワーカー（ＳＷ）４５２は、この閲覧要求の入力をフェッチイベントとして検出し、フェッチイベント検出に応じて、ステップＳ８５６において、リソース（Ｗｅｂページ）を記憶部（キャッシュ）から取得する。
　表示処理部４５１は、ステップＳ８５７において、Ｗｅｂページ４５６を表示する。
　このＷｅｂページ表示処理は、番組終了後、あるいはチャンネル切り替え後、あるいはオフライン設定状態における表示処理であり、先に図４６を参照して説明した表示状態に相当する。
　このように、サービスワーカー（ＳＷ）を利用することで、様々なアプリケーション等のプログラムを、番組の表示、非表示と無関係に利用することが可能となり、例えば、番組付属の表示情報として設定されたＷｅｂページを番組と無関係に、任意のタイミングで表示する等の処理が可能となる。
　このように、サービスワーカー（ＳＷ）は、例えば、Ｗｅｂページ、ＨＴＭＬページ、ＪａｖａＳｃｒｉｐｔ（登録商標）等を構成要素としたアプリケーションやプログラム、アプリケーション等に利用されるデータ等からなるリソースの取得、保存、更新、削除等の、リソース管理を実行する。
　リソースの保存される記憶部（キャッシュ）は、通常のローカル／テンポラリなキャッシュとは異なり、アプリケーションが稼働していなくても、データが保存される。
　Ｗｅｂページ表示プログラムであるブラウザに一種のプロキシサーバが実装され、いつでも、必要なときにプロキシサーバをアクセスしてＷｅｂページを取得して表示可能としたイメージである。
　なお、サービスワーカー（ＳＷ）自身もキャッシュに格納（インストール）される。サービスワーカー（ＳＷ）が、受信装置にインストールされると、このサービスワーカー（ＳＷ）の管理対象とするリソースについて、様々な制御が可能となる。
　例えば、リソースへのアクセスリクエスト（リソースへのフェッチリクエスト）に応じて、ブラウザ側の処理（ローカルキャッシュやネットワークからのリソースの取得）がはじまる前に、サービスワーカー（ＳＷ）の処理が開始され、キャッシュからのリソースの提供が行われる。
　また、サービスワーカー（ＳＷ）は、ＪａｖａＳｃｉｒｐｔ（登録商標）で提供されるため、さまざまな手続きを組み込むことが可能であり、キャッシュのリソースの一部の更新等キャッシュ制御についての柔軟な処理記述が可能となっている。
　なお、サービスワーカー（ＳＷ）自身も更新可能である。サービスワーカー（ＳＷ）は、送信装置２０から提供されるが、このサービスワーカー（ＳＷ）のヘッダ情報（ＨＴＴＰ　Ｃａｃｈｅ－Ｃｏｎｔｒｏｌ）に更新日時情報や更新データのアクセス情報等、更新処理に必要となる各種情報が記録され、このヘッダ情報に基づいて更新処理が実行される。
　例えば、ヘッダに設定された使用期限等に基づいて、使用期限が来ると、受信装置３０は、新しいバージョンのサービスワーカ（ＳＷ）の取得処理を実行して、キャッシュに格納された旧バージョンのＳＷを置き換える更新処理を行なう。
　受信装置３０は、サービスワーカー（ＳＷ）を利用して、任意のタイミングで、例えば図４５、図４６を参照して説明したような天気情報表示アプリケーション等のアプリケーションやプログラム、すなわちサービスワーカ（ＳＷ）の管理対象てあるアプリケーションやプログラムを実行することが可能となる。
　　［１３．送信装置と受信装置の構成例について］
　次に、通信装置である送信装置（サーバ）２０と、受信装置（クライアント）３０の装置構成例について、図４８、図４９を参照して説明する。
　図４８には、送信装置（サーバ）２０と、受信装置（クライアント）３０の構成例を示している。
　送信装置（サーバ）２０は、データ処理部７５１、通信部７５２、記憶部７５３を有する。
　受信装置（クライアント）３０は、データ処理部７７１、通信部７７２、記憶部７７３、入力部７７４、出力部７７５を有する。
　送信装置（サーバ）２０のデータ処理部７５１は、データ配信サービスを実行するための各種のデータ処理を実行する。例えばデータ配信サービスの構成データの生成や送信制御を行う。さらに、データ処理部７５１は、受信装置（クライアント）３０に提供するＡＶセグメント、アプリケーション、その他の様々なデータや、シグナリングデータの生成、送信処理を行う。
　通信部７５２は、ＡＶセグメントの他、アプリケーション、その他の様々なデータ、シグナリングデータ等の配信等の通信処理を行う。
　記憶部７５３は配信対象とするＡＶセグメント、アプリケーション、アプリケーションによって利用されるデータ、シグナリングデータなどが格納される。
　さらに、記憶部７５３は、データ処理部７５１の実行するデータ処理のワークエリアとして利用され、また各種パラメータの記憶領域としても利用される。
　送信装置２０の実行する具体的な処理は、例えば、以下の処理である。
　データ処理部７５１は、アプリケーション構成データを格納したパケットと、アプリケーションのデータサイズであるアプリケーションサイズと、アプリケーション間のリンク情報であるアプリケーションリンク情報を記録した第１シグナリングデータ（ＡＩＴ）を格納したパケット、さらに、アプリケーションの構成要素であるプレゼンテーション・ユニットのデータサイズと、プレゼンテーション・ユニット間のリンク情報を記録した第２シグナリングデータ（Ｓ－ＴＳＩＤ）を格納したパケットなどを生成する。
　通信部７５２は、データ処理部７５１の生成したこれらのパケットを送信する処理などを実行する。
　一方、受信装置（クライアント）３０は、データ処理部７７１、通信部７７２、記憶部７７３、入力部７７４、出力部７７５を有する。
　通信部７７２は、送信装置（サーバ）２０から配信されるデータ、例えばＡＶセグメントやアプリケーション、アプリケーションによって利用されるデータ、シグナリングデータ等を受信する。
　データ処理部７７１は、通信データ処理、シグナリングデータ解析処理、データキャッシュ制御処理、再生制御処理、アプリケーション制御処理等、例えば先に説明した実施例に従った処理等を実行する。
　具体的には、アプリケーションや、プレゼンテーション・ユニット（ＰＵ）単位のキャッシュ制御、アプリケーションム実行制御等を実行する。
　ユーザの指示コマンド、例えばチャンネル選択、アプリケーション起動、アプリケーション遷移等の様々なコマンドは入力部７７４を介して入力される。
　再生データは表示部やスピーカ等の出力部７７５に出力される。
　記憶部７７３はＡＶセグメント、アプリケーション、アプリケーションによって利用されるデータ、シグナリングデータなどが格納される。
　さらに、記憶部７７３は、データ処理部７７１の実行するデータ処理のワークエリアとして利用され、また各種パラメータの記憶領域としても利用される。
　受信装置３０の実行する具体的な処理は、例えば以下の処理である。
　通信部７７２は、アプリケーションのデータサイズであるアプリケーションサイズと、アプリケーション間のリンク情報であるアプリケーションリンク情報を記録した第１シグナリングデータ（ＡＩＴ）や、アプリケーションの構成要素であるプレゼンテーション・ユニットのデータサイズを記録した第２シグナリングデータ（Ｓ－ＴＳＩＤ）等を受信する。
　また、データ処理部７７１は、自装置の記憶部７７３に格納可能なデータサイズであるキャッシュサイズと、第１シグナリングデータ（ＡＩＴ）から取得するリンク関係にある各アプリケーションのデータサイズとを比較して、キャッシュ可能な１つ以上のアプリケーションをキャッシュ対象アプリケーションとして決定し、アプリケーション単位のキャッシュ処理を実行する。
　さらに、データ処理部７７１は、キャッシュサイズが、１つのアプリケーションのデータサイズより小さい場合、第２シグナリングデータ（Ｓ－ＴＳＩＤ）を参照し、プレゼンテーション・ユニットのデータサイズと、キャッシュサイズとを比較し、キャッシュサイズ以下の１つ以上のプレゼンテーション・ユニットをキャッシュ対象として決定し、プレゼンテーション・ユニット単位のキャッシュ処理を実行する。
　図４９は、送信装置２０、受信装置３０として適用可能な通信装置のハードウェア構成例を示している。
　ＣＰＵ（Ｃｅｎｔｒａｌ　Ｐｒｏｃｅｓｓｉｎｇ　Ｕｎｉｔ）８０１は、ＲＯＭ（Ｒｅａｄ　Ｏｎｌｙ　Ｍｅｍｏｒｙ）８０２、または記憶部８０８に記憶されているプログラムに従って各種の処理を実行するデータ処理部として機能する。例えば、上述した実施例において説明したシーケンスに従った処理を実行する。ＲＡＭ（Ｒａｎｄｏｍ　Ａｃｃｅｓｓ　Ｍｅｍｏｒｙ）８０３には、ＣＰＵ８０１が実行するプログラムやデータなどが記憶される。これらのＣＰＵ８０１、ＲＯＭ８０２、およびＲＡＭ８０３は、バス８０４により相互に接続されている。
　ＣＰＵ８０１はバス８０４を介して入出力インタフェース８０５に接続され、入出力インタフェース８０５には、各種スイッチ、キーボード、マウス、マイクロホンなどよりなる入力部８０６、ディスプレイ、スピーカなどよりなる出力部８０７が接続されている。ＣＰＵ８０１は、入力部８０６から入力される指令に対応して各種の処理を実行し、処理結果を例えば出力部８０７に出力する。
　入出力インタフェース８０５に接続されている記憶部８０８は、例えばハードディスク等からなり、ＣＰＵ８０１が実行するプログラムや各種のデータを記憶する。通信部８０９は、インターネットやローカルエリアネットワークなどのネットワークを介したデータ通信の送受信部、さらに放送波の送受信部として機能し、外部の装置と通信する。
　入出力インタフェース８０５に接続されているドライブ８１０は、磁気ディスク、光ディスク、光磁気ディスク、あるいはメモリカード等の半導体メモリなどのリムーバブルメディア８１１を駆動し、データの記録あるいは読み取りを実行する。
　なお、データの符号化あるいは復号は、データ処理部としてのＣＰＵ８０１の処理として実行可能であるが、符号化処理あるいは復号処理を実行するための専用ハードウェアとしてのコーデックを備えた構成としてもよい。
　　［１４．本開示の構成のまとめ］
　以上、特定の実施例を参照しながら、本開示の実施例について詳解してきた。しかしながら、本開示の要旨を逸脱しない範囲で当業者が実施例の修正や代用を成し得ることは自明である。すなわち、例示という形態で本発明を開示してきたのであり、限定的に解釈されるべきではない。本開示の要旨を判断するためには、特許請求の範囲の欄を参酌すべきである。
　なお、本明細書において開示した技術は、以下のような構成をとることができる。
　（１）　アプリケーションのデータサイズであるアプリケーションサイズと、アプリケーション間のリンク情報であるアプリケーションリンク情報を記録した第１シグナリングデータを受信する通信部と、
　自装置の記憶部に格納可能なデータサイズであるキャッシュサイズと、前記第１シグナリングデータから取得するリンク関係にある各アプリケーションのデータサイズとを比較して、キャッシュ可能な１つ以上のアプリケーションをキャッシュ対象アプリケーションとして決定し、アプリケーション単位のキャッシュ処理を実行するデータ処理部を有する受信装置。
　（２）　前記第１シグナリングデータは、
　リンク元アプリケーションＩＤと、リンク先アプリケーションＩＤとの対応データを、アプリケーションリンク情報として記録し、
　さらに、各アプリケーションＩＤに対応付けてアプリケーションサイズを記録した構成であり、
　前記データ処理部は、
　前記第１シグナリングデータのアプリケーションリンク情報から、リンク元アプリケーションＩＤと、リンク先アプリケーションＩＤを取得し、
　取得した各アプリケーションＩＤに対応して記録されたアプリケーションサイズ情報を取得して、キャッシュ可能な１つ以上のアプリケーションをキャッシュ対象アプリケーションとして決定する（１）に記載の受信装置。
　（３）　前記データ処理部は、
　リンク関係にある複数のアプリケーションが存在する場合、
　初期実行アプリケーションを最優先のキャッシュ対象アプリケーションとして選択し、以下、前記初期実行アプリケーションからのリンクに順に従って、キャッシュ対象アプリケーションを順次、選択する（１）または（２）に記載の受信装置。
　（４）　前記アプリケーションＩＤは、組織ＩＤと、アプリケーション本体ＩＤが含まれた識別子である（２）または（３）に記載の受信装置。
　（５）　前記第１シグナリングデータは、アプリケーション単位の情報を記録したアプリケーション・インフォーメーション・テーブル（ＡＩＴ：Ａｐｐｌｉｃａｔｉｏｎ　Ｉｎｆｏｒｍａｔｉｏｎ　Ｔａｂｌｅ）である（１）～（４）いずれかに記載の受信装置。
　（６）　前記通信部は、
　前記第１シグナリナングデータを、放送波を介して受信する（１）～（５）いずれかに記載の受信装置。
　（７）　前記アプリケーションは、広告出力処理を実行するアプリケーションである（１）～（６）いずれかに記載の受信装置。
　（８）　前記受信部は、
　アプリケーションの構成要素であるプレゼンテーション・ユニットのデータサイズを記録した第２シグナリングデータを受信し、
　前記データ処理部は、
　前記キャッシュサイズが、１つのアプリケーションのデータサイズより小さい場合、
　前記第２シグナリングデータを参照し、前記プレゼンテーション・ユニットのデータサイズと、前記キャッシュサイズとを比較し、
　キャッシュサイズ以下の１つ以上のプレゼンテーション・ユニットをキャッシュ対象として決定し、プレゼンテーション・ユニット単位のキャッシュ処理を実行する（１）～（７）いずれかに記載の受信装置。
　（９）　前記プレゼンテーション・ユニットは、
　１つまたは複数のＨＴＭＬ（ＨｙｐｅｒＴｅｘｔ　Ｍａｒｋｕｐ　Ｌａｎｇｕａｇｅ）文書と、該ＨＴＭＬ文書を適用して出力されるデータファイルによって構成されるデータの集合である（８）に記載の受信装置。
　（１０）　前記第２シグナリングデータは、
　リンク元プレゼンテーション・ユニットＩＤと、リンク先プレゼンテーション・ユニットＩＤとの対応データを、プレゼンテーション・ユニットリンク情報として記録し、
　さらに、各プレゼンテーション・ユニットＩＤに対応付けてプレゼンテーション・ユニットサイズを記録した構成であり、
　前記データ処理部は、
　前記第２シグナリングデータのプレゼンテーション・ユニットリンク情報から、リンク元プレゼンテーション・ユニットＩＤと、リンク先プレゼンテーション・ユニットＩＤを取得し、
　取得した各プレゼンテーション・ユニットＩＤに対応して記録されたプレゼンテーション・ユニットサイズ情報を取得して、キャッシュ可能な１つ以上のプレゼンテーション・ユニットをキャッシュ対象アプリケーションとして決定する（８）または（９）に記載の受信装置。
　（１１）　前記データ処理部は、
　リンク関係にある複数のプレゼンテーション・ユニットが存在する場合、
　エントリ文書を含むプレゼンテーション・ユニットを最優先のキャッシュ対象プレゼンテーション・ユニットとして選択し、以下、前記エントリ文書を含むプレゼンテーション・ユニットからのリンクに順に従って、キャッシュ対象プレゼンテーション・ユニットを順次、選択する（８）～（１０）いずれかに記載の受信装置。
　（１２）　前記プレゼンテーション・ユニットＩＤは、プレゼンテーション・ユニットの属するアプリケーションを識別可能としたアプリケーション本体ＩＤと、所属アプリケーション内のプレゼンテーション・ユニットを個別に識別可能としたグループＩＤを含むＩＤである（１０）または（１１）に記載の受信装置。
　（１３）　前記第２シグナリングデータは、アプリケーションを構成するプレゼンテーション・ユニットに含まれるファイル単位の情報を記録したＳ－ＴＳＩＤである（８）～（１１）いずれかに記載の受信装置。
　（１４）　前記第２シグナリングデータには、プレゼンテーション・ユニットに含まれるファイル単位の情報が記録され、
　ファイル単位情報の各々には、ファイルの属するプレゼンテーション・ユニットに設定されたグループＩＤが対応付けて記録されており、
　前記データ処理部は、
　グループＩＤに基づいて、キャッシュ対象ファイルの選択処理を実行する（８）～（１３）いずれかに記載の受信装置。
　（１５）　前記通信部は、
　前記第２シグナリナングデータを、放送波を介して受信する（８）～（１４）いずれかに記載の受信装置。
　（１６）　アプリケーション構成データを格納したパケットと、
　前記アプリケーションのデータサイズであるアプリケーションサイズと、アプリケーション間のリンク情報であるアプリケーションリンク情報を記録した第１シグナリングデータを格納したパケットを生成するデータ処理部と、
　前記データ処理部の生成したパケットを送信する通信部と、
　を有する送信装置。
　（１７）　前記データ処理部は、さらに、
　アプリケーションの構成要素であるプレゼンテーション・ユニットのデータサイズと、プレゼンテーション・ユニット間のリンク情報を記録した第２シグナリングデータを格納したパケットを生成し、
　前記通信部は、前記第２シグナリングデータを格納したパケットを送信する（１６）に記載の送信装置。
　（１８）　前記プレゼンテーション・ユニットは、
　１つまたは複数のＨＴＭＬ（ＨｙｐｅｒＴｅｘｔ　Ｍａｒｋｕｐ　Ｌａｎｇｕａｇｅ）文書と、該ＨＴＭＬ文書を適用して出力されるデータファイルによって構成されるデータの集合である（１７）に記載の送信装置。
　（１９）　受信装置において実行するデータ処理方法であり、
　通信部が、アプリケーションのデータサイズであるアプリケーションサイズと、アプリケーション間のリンク情報であるアプリケーションリンク情報を記録した第１シグナリングデータを受信し、
　データ処理部が、自装置の記憶部に格納可能なデータサイズであるキャッシュサイズと、前記第１シグナリングデータから取得するリンク関係にある各アプリケーションのデータサイズとを比較して、キャッシュ可能な１つ以上のアプリケーションをキャッシュ対象アプリケーションとして決定し、アプリケーション単位のキャッシュ処理を実行するデータ処理方法。
　（２０）　送信装置において実行するデータ処理方法であり、
　データ処理部が、
　アプリケーション構成データを格納したパケットと、
　前記アプリケーションのデータサイズであるアプリケーションサイズと、アプリケーション間のリンク情報であるアプリケーションリンク情報を記録した第１シグナリングデータを格納したパケットを生成し、
　通信部が、前記データ処理部の生成したパケットを送信するデータ処理方法。
　また、明細書中において説明した一連の処理はハードウェア、またはソフトウェア、あるいは両者の複合構成によって実行することが可能である。ソフトウェアによる処理を実行する場合は、処理シーケンスを記録したプログラムを、専用のハードウェアに組み込まれたコンピュータ内のメモリにインストールして実行させるか、あるいは、各種処理が実行可能な汎用コンピュータにプログラムをインストールして実行させることが可能である。例えば、プログラムは記録媒体に予め記録しておくことができる。記録媒体からコンピュータにインストールする他、ＬＡＮ（Ｌｏｃａｌ　Ａｒｅａ　Ｎｅｔｗｏｒｋ）、インターネットといったネットワークを介してプログラムを受信し、内蔵するハードディスク等の記録媒体にインストールすることができる。
　なお、明細書に記載された各種の処理は、記載に従って時系列に実行されるのみならず、処理を実行する装置の処理能力あるいは必要に応じて並列的にあるいは個別に実行されてもよい。また、本明細書においてシステムとは、複数の装置の論理的集合構成であり、各構成の装置が同一筐体内にあるものには限らない。
　以上、説明したように、本開示の一実施例の構成によれば、受信装置において、アプリケーション単位、またはプレゼンテーション・ユニット単位のキャッシュ処理を実行させ、完成度の高いアプリケーション実行処理を可能とする装置、方法が実現される。
　具体的には、受信装置が、送信装置からアプリケーションのデータサイズであるアプリケーションサイズと、アプリケーションリンク情報、さらに、アプリケーション構成要素であるプレゼンテーション・ユニット（ＰＵ）各々のデータサイズを記録したシグナリングデータを受信する。受信装置はキャッシュサイズと、アプリケーションや、ＰＵ各々のデータサイズとを比較し、キャッシュ可能なアプリケーション、またはＰＵをキャッシュ対象データとして決定し、アプリケーションまたはＰＵ単位のキャッシュ処理を実行する。
　本構成により、受信装置において、アプリケーション単位、またはプレゼンテーション・ユニット単位のキャッシュ処理を実行させ、完成度の高いアプリケーション実行処理を可能とする装置、方法が実現される。
　　１０　通信システム
　　２０　送信装置
　　２１　放送サーバ
　　２２　広告サーバ
　　２３　データ配信サーバ
　　３０　受信装置
　　３１　ＴＶ
　　３２　ＰＣ
　　３３　携帯端末
　　５０　シグナリングデータ
　　６０　ＡＶセグメント
　　７０　その他のデータ
　１１０　ミドルウェア
　１１１　通信部（ＰＨＹ／ＭＡＣ）
　１１２　シグナリング取得部
　１１３　シグナリング解析部
　１１４　セグメント取得部
　１２０　ＨＴＴＰプロキシサーバ
　１２１　キャッシュ制御部
　１２２　キャッシュ部
　１３０　データ再生部
　１３１　再生制御部
　１３２　アプリケーション制御部
　１３３　出力制御部
　２００　アプリケーション
　２１０　プレゼンテーション・ユニット（ＰＵ）
　２１１　ＨＴＭＬファイル
　２１２　データファイル
　２１３　リンク
　２２１　エントリ文書
　４５０　ブラウザ
　４５１　表示処理部
　４５２　サービスワーカー（ＳＷ）
　４５３　キャッシュ
　４５５，４５６　Ｗｅｂページ
　７５１　データ処理部
　７５２　通信部
　７５３　記憶部
　７７１　データ処理部
　７７２　通信部
　７７３　記憶部
　７７４　入力部
　７７５　出力部
　８０１　ＣＰＵ
　８０２　ＲＯＭ
　８０３　ＲＡＭ
　８０４　バス
　８０５　入出力インタフェース
　８０６　入力部
　８０７　出力部
　８０８　記憶部
　８０９　通信部
　８１０　ドライブ
　８１１　リムーバブルメディア

Claims (20)

  1. 　アプリケーションのデータサイズであるアプリケーションサイズと、アプリケーション間のリンク情報であるアプリケーションリンク情報を記録した第１シグナリングデータを受信する通信部と、
    　自装置の記憶部に格納可能なデータサイズであるキャッシュサイズと、前記第１シグナリングデータから取得するリンク関係にある各アプリケーションのデータサイズとを比較して、キャッシュ可能な１つ以上のアプリケーションをキャッシュ対象アプリケーションとして決定し、アプリケーション単位のキャッシュ処理を実行するデータ処理部を有する受信装置。
  2. 　前記第１シグナリングデータは、
    　リンク元アプリケーションＩＤと、リンク先アプリケーションＩＤとの対応データを、アプリケーションリンク情報として記録し、
    　さらに、各アプリケーションＩＤに対応付けてアプリケーションサイズを記録した構成であり、
    　前記データ処理部は、
    　前記第１シグナリングデータのアプリケーションリンク情報から、リンク元アプリケーションＩＤと、リンク先アプリケーションＩＤを取得し、
    　取得した各アプリケーションＩＤに対応して記録されたアプリケーションサイズ情報を取得して、キャッシュ可能な１つ以上のアプリケーションをキャッシュ対象アプリケーションとして決定する請求項１に記載の受信装置。
  3. 　前記データ処理部は、
    　リンク関係にある複数のアプリケーションが存在する場合、
    　初期実行アプリケーションを最優先のキャッシュ対象アプリケーションとして選択し、以下、前記初期実行アプリケーションからのリンクに順に従って、キャッシュ対象アプリケーションを順次、選択する請求項１に記載の受信装置。
  4. 　前記アプリケーションＩＤは、組織ＩＤと、アプリケーション本体ＩＤが含まれた識別子である請求項２に記載の受信装置。
  5. 　前記第１シグナリングデータは、アプリケーション単位の情報を記録したアプリケーション・インフォーメーション・テーブル（ＡＩＴ：Ａｐｐｌｉｃａｔｉｏｎ　Ｉｎｆｏｒｍａｔｉｏｎ　Ｔａｂｌｅ）である請求項１に記載の受信装置。
  6. 　前記通信部は、
    　前記第１シグナリナングデータを、放送波を介して受信する請求項１に記載の受信装置。
  7. 　前記アプリケーションは、広告出力処理を実行するアプリケーションである請求項１に記載の受信装置。
  8. 　前記受信部は、
    　アプリケーションの構成要素であるプレゼンテーション・ユニットのデータサイズを記録した第２シグナリングデータを受信し、
    　前記データ処理部は、
    　前記キャッシュサイズが、１つのアプリケーションのデータサイズより小さい場合、
    　前記第２シグナリングデータを参照し、前記プレゼンテーション・ユニットのデータサイズと、前記キャッシュサイズとを比較し、
    　キャッシュサイズ以下の１つ以上のプレゼンテーション・ユニットをキャッシュ対象として決定し、プレゼンテーション・ユニット単位のキャッシュ処理を実行する請求項１に記載の受信装置。
  9. 　前記プレゼンテーション・ユニットは、
    　１つまたは複数のＨＴＭＬ（ＨｙｐｅｒＴｅｘｔ　Ｍａｒｋｕｐ　Ｌａｎｇｕａｇｅ）文書と、該ＨＴＭＬ文書を適用して出力されるデータファイルによって構成されるデータの集合である請求項８に記載の受信装置。
  10. 　前記第２シグナリングデータは、
    　リンク元プレゼンテーション・ユニットＩＤと、リンク先プレゼンテーション・ユニットＩＤとの対応データを、プレゼンテーション・ユニットリンク情報として記録し、
    　さらに、各プレゼンテーション・ユニットＩＤに対応付けてプレゼンテーション・ユニットサイズを記録した構成であり、
    　前記データ処理部は、
    　前記第２シグナリングデータのプレゼンテーション・ユニットリンク情報から、リンク元プレゼンテーション・ユニットＩＤと、リンク先プレゼンテーション・ユニットＩＤを取得し、
    　取得した各プレゼンテーション・ユニットＩＤに対応して記録されたプレゼンテーション・ユニットサイズ情報を取得して、キャッシュ可能な１つ以上のプレゼンテーション・ユニットをキャッシュ対象アプリケーションとして決定する請求項８に記載の受信装置。
  11. 　前記データ処理部は、
    　リンク関係にある複数のプレゼンテーション・ユニットが存在する場合、
    　エントリ文書を含むプレゼンテーション・ユニットを最優先のキャッシュ対象プレゼンテーション・ユニットとして選択し、以下、前記エントリ文書を含むプレゼンテーション・ユニットからのリンクに順に従って、キャッシュ対象プレゼンテーション・ユニットを順次、選択する請求項８に記載の受信装置。
  12. 　前記プレゼンテーション・ユニットＩＤは、プレゼンテーション・ユニットの属するアプリケーションを識別可能としたアプリケーション本体ＩＤと、所属アプリケーション内のプレゼンテーション・ユニットを個別に識別可能としたグループＩＤを含むＩＤである請求項１０に記載の受信装置。
  13. 　前記第２シグナリングデータは、アプリケーションを構成するプレゼンテーション・ユニットに含まれるファイル単位の情報を記録したＳ－ＴＳＩＤである請求項８に記載の受信装置。
  14. 　前記第２シグナリングデータには、プレゼンテーション・ユニットに含まれるファイル単位の情報が記録され、
    　ファイル単位情報の各々には、ファイルの属するプレゼンテーション・ユニットに設定されたグループＩＤが対応付けて記録されており、
    　前記データ処理部は、
    　グループＩＤに基づいて、キャッシュ対象ファイルの選択処理を実行する請求項８に記載の受信装置。
  15. 　前記通信部は、
    　前記第２シグナリナングデータを、放送波を介して受信する請求項８に記載の受信装置。
  16. 　アプリケーション構成データを格納したパケットと、
    　前記アプリケーションのデータサイズであるアプリケーションサイズと、アプリケーション間のリンク情報であるアプリケーションリンク情報を記録した第１シグナリングデータを格納したパケットを生成するデータ処理部と、
    　前記データ処理部の生成したパケットを送信する通信部と、
    　を有する送信装置。
  17. 　前記データ処理部は、さらに、
    　アプリケーションの構成要素であるプレゼンテーション・ユニットのデータサイズと、プレゼンテーション・ユニット間のリンク情報を記録した第２シグナリングデータを格納したパケットを生成し、
    　前記通信部は、前記第２シグナリングデータを格納したパケットを送信する請求項１６に記載の送信装置。
  18. 　前記プレゼンテーション・ユニットは、
    　１つまたは複数のＨＴＭＬ（ＨｙｐｅｒＴｅｘｔ　Ｍａｒｋｕｐ　Ｌａｎｇｕａｇｅ）文書と、該ＨＴＭＬ文書を適用して出力されるデータファイルによって構成されるデータの集合である請求項１７に記載の送信装置。
  19. 　受信装置において実行するデータ処理方法であり、
    　通信部が、アプリケーションのデータサイズであるアプリケーションサイズと、アプリケーション間のリンク情報であるアプリケーションリンク情報を記録した第１シグナリングデータを受信し、
    　データ処理部が、自装置の記憶部に格納可能なデータサイズであるキャッシュサイズと、前記第１シグナリングデータから取得するリンク関係にある各アプリケーションのデータサイズとを比較して、キャッシュ可能な１つ以上のアプリケーションをキャッシュ対象アプリケーションとして決定し、アプリケーション単位のキャッシュ処理を実行するデータ処理方法。
  20. 　送信装置において実行するデータ処理方法であり、
    　データ処理部が、
    　アプリケーション構成データを格納したパケットと、
    　前記アプリケーションのデータサイズであるアプリケーションサイズと、アプリケーション間のリンク情報であるアプリケーションリンク情報を記録した第１シグナリングデータを格納したパケットを生成し、
    　通信部が、前記データ処理部の生成したパケットを送信するデータ処理方法。
PCT/JP2016/069752 2015-07-23 2016-07-04 受信装置、送信装置、およびデータ処理方法 WO2017014034A1 (ja)

Priority Applications (7)

Application Number Priority Date Filing Date Title
KR1020177036843A KR102611253B1 (ko) 2015-07-23 2016-07-04 수신 장치, 송신 장치 및 데이터 처리 방법
EP16827596.4A EP3327576A4 (en) 2015-07-23 2016-07-04 Reception device, transmission device, and data processing method
CA2987903A CA2987903A1 (en) 2015-07-23 2016-07-04 Reception apparatus, transmission apparatus and data processing method
MX2018000649A MX2018000649A (es) 2015-07-23 2016-07-04 Aparato de recepcion, aparato de transmision y metodo de procesamiento de datos.
US15/573,549 US10820041B2 (en) 2015-07-23 2016-07-04 Reception apparatus, transmission apparatus and data processing method
CN201680041699.3A CN107851072B (zh) 2015-07-23 2016-07-04 接收设备、发送设备和数据处理方法
JP2017529533A JPWO2017014034A1 (ja) 2015-07-23 2016-07-04 受信装置、送信装置、およびデータ処理方法

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2015-145494 2015-07-23
JP2015145494 2015-07-23

Publications (1)

Publication Number Publication Date
WO2017014034A1 true WO2017014034A1 (ja) 2017-01-26

Family

ID=57833882

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2016/069752 WO2017014034A1 (ja) 2015-07-23 2016-07-04 受信装置、送信装置、およびデータ処理方法

Country Status (8)

Country Link
US (1) US10820041B2 (ja)
EP (1) EP3327576A4 (ja)
JP (1) JPWO2017014034A1 (ja)
KR (1) KR102611253B1 (ja)
CN (1) CN107851072B (ja)
CA (1) CA2987903A1 (ja)
MX (1) MX2018000649A (ja)
WO (1) WO2017014034A1 (ja)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10938878B2 (en) * 2017-05-16 2021-03-02 Red Hat, Inc. Separate cache servers for storing objects in different dedicated size ranges
CN110891246B (zh) * 2018-09-11 2022-07-05 成都鼎桥通信技术有限公司 一种组播媒体数据的处理方法

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2013009358A (ja) * 2011-05-20 2013-01-10 Nippon Hoso Kyokai <Nhk> 放送通信連携受信装置
JP5725235B1 (ja) * 2014-04-22 2015-05-27 ソニー株式会社 受信装置及び受信方法、並びに、送信装置及び送信方法
JP5725242B1 (ja) * 2014-06-04 2015-05-27 ソニー株式会社 送信装置及び送信方法、並びに受信装置並びに受信方法
US20150156546A1 (en) * 2011-08-10 2015-06-04 Lg Electronics Inc. Method for transmitting broadcast service, method for receiving broadcast service, and apparatus for receiving broadcast service
JP2015126466A (ja) * 2013-12-27 2015-07-06 日立マクセル株式会社 放送受信装置及び携帯情報端末
WO2015104743A1 (ja) * 2014-01-07 2015-07-16 ソニー株式会社 情報処理装置および情報処理方法

Family Cites Families (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2004034698A1 (ja) * 2002-10-09 2004-04-22 Matsushita Electric Industrial Co., Ltd. 情報処理装置
US20070174356A1 (en) * 2004-02-10 2007-07-26 Matsushita Electric Industrial Co., Ltd. Program execution device, program execution method, and program
WO2010058964A2 (en) 2008-11-18 2010-05-27 Lg Electronics Inc. Method for receiving a broadcast signal
JP2011087103A (ja) 2009-10-15 2011-04-28 Sony Corp コンテンツ再生システム、コンテンツ再生装置、プログラム、コンテンツ再生方法、およびコンテンツサーバを提供
JP6076248B2 (ja) * 2011-05-20 2017-02-08 日本放送協会 放送通信連携システム、アプリケーション管理サーバー、および、アプリケーション管理サーバーにおけるアプリケーション管理方法
CA2843583C (en) * 2011-09-23 2016-11-01 Lg Electronics Inc. Method for receiving broadcast service and reception device thereof
BR112014014585A8 (pt) * 2011-12-21 2017-07-04 Sony Corp aparelho e método de processamento de informação, aparelho de servidor, método de processamento de servidor, e, programa
CN103650520A (zh) * 2012-05-10 2014-03-19 索尼公司 接收设备、接收方法、发送设备、发送方法和程序
US9154840B2 (en) * 2012-07-31 2015-10-06 Sony Corporation Reception apparatus, reception method, transmission apparatus, and transmission method
JP6348251B2 (ja) 2012-09-13 2018-06-27 サターン ライセンシング エルエルシーＳａｔｕｒｎ Ｌｉｃｅｎｓｉｎｇ ＬＬＣ 端末装置、受信方法、およびプログラム
BR112015007003A2 (pt) * 2012-10-10 2017-07-04 Sony Corp dispositivos de recepção e de transmissão, métodos de recepção para um dispositivo de recepção e de transmissão para um dispositivo de transmissão, e, programa
CN103905147B (zh) * 2012-12-28 2017-03-22 联芯科技有限公司 数据处理方法、发送设备、接收设备和通信***
US20160182977A1 (en) * 2014-12-19 2016-06-23 Telefonaktiebolaget L M Ericsson (Publ) User interaction with advertisements on hybrid terminals

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2013009358A (ja) * 2011-05-20 2013-01-10 Nippon Hoso Kyokai <Nhk> 放送通信連携受信装置
US20150156546A1 (en) * 2011-08-10 2015-06-04 Lg Electronics Inc. Method for transmitting broadcast service, method for receiving broadcast service, and apparatus for receiving broadcast service
JP2015126466A (ja) * 2013-12-27 2015-07-06 日立マクセル株式会社 放送受信装置及び携帯情報端末
WO2015104743A1 (ja) * 2014-01-07 2015-07-16 ソニー株式会社 情報処理装置および情報処理方法
JP5725235B1 (ja) * 2014-04-22 2015-05-27 ソニー株式会社 受信装置及び受信方法、並びに、送信装置及び送信方法
JP5725242B1 (ja) * 2014-06-04 2015-05-27 ソニー株式会社 送信装置及び送信方法、並びに受信装置並びに受信方法

Non-Patent Citations (1)

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

Also Published As

Publication number Publication date
CA2987903A1 (en) 2017-01-26
KR20180034332A (ko) 2018-04-04
EP3327576A1 (en) 2018-05-30
US10820041B2 (en) 2020-10-27
CN107851072B (zh) 2021-03-12
US20180124454A1 (en) 2018-05-03
JPWO2017014034A1 (ja) 2018-05-10
KR102611253B1 (ko) 2023-12-08
MX2018000649A (es) 2018-04-24
EP3327576A4 (en) 2018-12-12
CN107851072A (zh) 2018-03-27

Similar Documents

Publication Publication Date Title
WO2014084071A1 (ja) 受信装置、受信方法、送信装置、及び、送信方法
JP6583281B2 (ja) 受信装置、送信装置、およびデータ処理方法
JP4878642B2 (ja) コンテンツ配信システム、コンテンツ配信装置、コンテンツ再生端末およびコンテンツ配信方法
WO2016203850A1 (ja) 受信装置、送信装置、およびデータ処理方法
US11115335B2 (en) Information processing device and information processing method
WO2015070796A1 (zh) 智能电视向移动通信终端推送资源的方法和装置
JPWO2016174960A1 (ja) 受信装置、送信装置、およびデータ処理方法
KR102532046B1 (ko) 수신 장치, 송신 장치 및 데이터 처리 방법
JP6614154B2 (ja) 受信装置、送信装置、およびデータ処理方法
JP6589879B2 (ja) 受信装置、送信装置、およびデータ処理方法
WO2017014034A1 (ja) 受信装置、送信装置、およびデータ処理方法
JP6597604B2 (ja) 受信装置、送信装置、データ通信方法、およびデータ処理方法
KR102460444B1 (ko) 수신 장치, 송신 장치 및 데이터 처리 방법
JPWO2016174959A1 (ja) 受信装置、送信装置、およびデータ処理方法
JP2015165699A (ja) データ配信装置、データ配信方法、データ受信装置およびデータ受信方法

Legal Events

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

Ref document number: 16827596

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2017529533

Country of ref document: JP

Kind code of ref document: A

WWE Wipo information: entry into national phase

Ref document number: 15573549

Country of ref document: US

ENP Entry into the national phase

Ref document number: 2987903

Country of ref document: CA

ENP Entry into the national phase

Ref document number: 20177036843

Country of ref document: KR

Kind code of ref document: A

WWE Wipo information: entry into national phase

Ref document number: MX/A/2018/000649

Country of ref document: MX

NENP Non-entry into the national phase

Ref country code: DE

WWE Wipo information: entry into national phase

Ref document number: 2016827596

Country of ref document: EP