JP6624314B2 - Transmission device and transmission method, and reception device and reception method - Google Patents

Description

  The technology disclosed in the present specification relates to a transmitting device and a transmitting method for transmitting a data broadcast file by a predetermined transport method, and a receiving device for receiving a data broadcast file transmitted by a predetermined transport method And a receiving method.

  In the current broadcasting system, the MPEG-2 TS (Moving Picture Experts Group-2 Transport Stream) system and the RTP (Real Time Protocol) system are widely used as a media transport system (for example, see Patent Document 1). That). As a next-generation digital broadcasting system, MMT (MPEG Media Transport) standardized as a new media transport system by MPEG (for example, see Non-Patent Document 1) is under study. In MMT, it is easy to use a combination of different transmission paths, and it can be used in common for a plurality of transmission paths for broadcasting and communication.

  According to the MMT method, both timed media (Timed media) such as video and audio, which are stream media, and non-timed media (Non timed media) such as files can be transmitted on MMT packets. It is. The timed media referred to here is stream data of a main broadcast program such as video, audio, and subtitles. The non-timed media is, for example, file data of a data broadcasting application (content) such as an HTML (Hyper Text Markup Language) document.

  Data broadcasting linked to a broadcast program is required to be presented in a timely manner. On the other hand, each file used in data broadcasting is repeatedly transmitted in a limited broadcast transmission band. The receiving terminal can realize the timely presentation of the data broadcast by caching the data broadcast file. However, a receiving terminal that does not have ample cache memory will have to wait until the next repetition cycle if a required file is missed, resulting in a delay of several tens of seconds, for example, until a data broadcast is presented. Would.

  In a data broadcasting service based on BML (Broadcast Markup Language) operated at the time of the present application, a specific file is pre-cached in a cache memory by calling an API (Application Programming Interface) called "LockModuleOnMemory ()" from a script in advance. (See, for example, Patent Document 2).

JP 2013-153291 A JP 2007-274193 A

ISO / IEC FDIS 23008-1: 2013 (E) Information technology-High efficiency coding and media delivery in heterogeneous environmentals-Part 1

  An object of the technology disclosed in this specification is to provide a transmission device and a transmission method that can appropriately transmit a data broadcast file by a predetermined transport method.

  A further object of the technology disclosed in this specification is to provide a receiving device and a receiving method that can suitably receive a data broadcast file transmitted by a predetermined transport method.

The present application has been made in view of the above problems, and the technology according to claim 1
A file data transmission unit for transmitting file data used in data broadcasting,
A signaling message transmitting unit for transmitting including signaling for data broadcasting including forced cache information for specifying a forced cache of file data,
It is a transmission device provided with.

  According to the technology described in claim 2 of the present application, the signaling message transmitting unit of the transmission device according to claim 1 includes, for each data broadcast presentation unit, a broadcast transmission file list and a center that constitute a presentation unit. And a data transmission message including a data content management table in which information of a target file list to be pre-cached is described.

  According to the technology described in claim 3 of the present application, the signaling message transmitting unit of the transmission device according to claim 1 includes, for each data broadcast presentation unit, a broadcast transmission file list that forms a presentation unit and a center. A data transmission message including a data content management table in which information of a file to be locked, a file to be locked in the cache, and a file to be unlocked among the lock objects is transmitted.

  According to the technology described in claim 4 of the present application, the transmission device according to any one of claims 1 to 3 further includes a media data transmission unit that transmits media data of a broadcast program main body that is linked with data broadcasting. Have.

Further, the technology described in claim 5 of the present application is:
A file data transmission step of transmitting file data used in data broadcasting,
A signaling message transmitting step of transmitting the signaling relating to the data broadcasting including the compulsory cache information for specifying the compulsory cache of the file data,
Is a transmission method.

Further, the technology described in claim 6 of the present application is:
A file data receiving unit for transmitting file data used in data broadcasting,
A signaling message receiving unit that transmits the signaling related to the data broadcasting including the compulsory cache information for specifying the compulsory cache of the file data, and
A control unit that controls a cache in a cache memory of file data received by the file data receiving unit based on the forced cache information,
Is a receiving device including:

  According to the technology described in claim 7 of the present application, the signaling message receiving unit of the receiving device according to claim 6 is configured such that, for each data broadcast presentation unit, a broadcast transmission file list constituting a presentation unit and a center And a data transmission message including a data content management table in which information of a target file list to be pre-cached is described.

  According to the technology described in claim 8 of the present application, the control unit of the receiving device according to claim 7, when the file data receives a file included in the target file list of the pre-cache, The cache memory is configured to be pre-cached.

  According to the technology described in claim 9 of the present application, the signaling message receiving unit of the receiving device according to claim 6 includes, for each data broadcast presentation unit, a broadcast transmission file list that forms a presentation unit and a center. It is configured to receive a data transmission message including a data content management table describing information of a file to be locked, a target file to be locked in the cache, and a target file to be unlocked among the lock targets.

  According to the technology described in claim 10 of the present application, when the file data receives the file to be locked, the control unit of the receiving device according to claim 9 pre-caches the file in the cache memory. Is configured.

  According to the technology described in claim 11 of the present application, the control unit of the receiving device according to claim 9 is configured to delete the file to be unlocked from the cache memory.

  According to the technology described in claim 12 of the present application, the control unit of the receiving device according to any one of claims 6 and 9 is centered on a broadcast transmission file list constituting a current data broadcast presentation unit. A file is configured to be cached in the cache memory when the file data is received.

  According to the technology described in claim 13 of the present application, the receiving device according to any one of claims 6 to 12 further includes a data broadcast presentation unit that presents a data broadcast using file data.

  According to the technology described in claim 14 of the present application, the receiving device according to any one of claims 6 to 13 includes: a media data receiving unit that receives media data of a broadcast program main body in which data broadcasting is linked; A broadcast program presenting unit for presenting a broadcast program based on the media data is further provided.

The technology according to claim 15 of the present application is:
A file data receiving step of transmitting file data used in data broadcasting,
A signaling message receiving step of transmitting the signaling relating to the data broadcasting including the compulsory cache information designating the compulsory cache of the file data,
A control step of controlling the cache of the file data received by the file data receiving unit in the cache memory based on the forced cache information,
Is a receiving method.

  The technology disclosed in this specification assumes that a data broadcast file based on, for example, HTML (Hyper Text Markup Language) 5 is transmitted by the MMT method. According to the technology disclosed in this specification, a transmission device such as a broadcasting station can transmit signaling related to data broadcasting including information designating a compulsory cache. Further, according to the technology disclosed in this specification, a receiving device such as an STB (Set Top Box) or a television receiving terminal installed in a home uses a forced cache information included in signaling related to a received data broadcast. Thus, the cache control of each file for data broadcasting can be suitably performed, and the data broadcasting linked to the broadcasting program can be presented in a timely manner.

  Note that the effects described in this specification are merely examples, and the effects of the present invention are not limited thereto. In addition, the present invention may exhibit additional effects other than the above effects.

  Still other objects, features, and advantages of the technology disclosed in the present specification will become apparent from the following embodiments and the more detailed description based on the accompanying drawings.

FIG. 1 is a diagram schematically illustrating a configuration example of a digital broadcasting system 10 to which the technology disclosed in this specification is applied. FIG. 2 is a diagram showing a stack model 200 of a broadcast signal to which the MMT is applied. FIG. 3 is a diagram illustrating a configuration example of the broadcast transmission system 11 that transmits the broadcast signal illustrated in FIG. FIG. 4 is a diagram illustrating a configuration example of the receiver 12 that receives the broadcast signal illustrated in FIG. FIG. 5 is a diagram showing an image of a broadcast signal (package) 500 transmitted from the broadcast transmission system 11 to the RF transmission line according to the MMT method. FIG. 6 is a diagram illustrating a configuration example of the header of the MMT packet. FIG. 7 is a diagram showing a configuration example of the extension header 700 in the case of an MMTP packet transmitting non-timed media. FIG. 8 is a diagram showing a configuration example of the MMTP payload 800 in the case of the MPU mode. FIG. 9 is a diagram illustrating a configuration example of a DU_Header 900 of an MFU in which timed media is arranged in a payload. FIG. 10 is a diagram illustrating a configuration example of a DU_Header 1000 of an MFU in which non-timed media is arranged in a payload. FIG. 11 is a diagram illustrating a packet configuration example when transmitting non-timed media data. FIG. 12 is a diagram showing a configuration example of a PA message 1201 and an MP table 1202 included in the PA message. FIG. 13 is a diagram illustrating a syntax example of the PA message 1300. FIG. 14 is a diagram illustrating the description of the parameters included in the PA message. FIG. 15 is a diagram illustrating a syntax example (first half) of the MP table (MPT). FIG. 16 is a diagram illustrating an example of the syntax of the MP table. FIG. 17 is a diagram illustrating each parameter included in the MP table. FIG. 18 is a diagram showing a configuration example of the M2 section message 1800. FIG. 19 is a diagram showing a configuration example of an MH AI (Application Information) table (MH AIT) 1900 transmitted by an M2 section message. FIG. 20 is a diagram illustrating a configuration example of the application information descriptor 2000. FIG. 21 is a diagram illustrating the description of the parameters included in the application information descriptor. FIG. 22 is a diagram illustrating a configuration example of the transmission protocol descriptor 2200. FIG. 23 is a diagram showing a configuration example of a selector byte common to HTTP / HTTPS, MMT, and non-timed transmission. FIG. 24 is a diagram showing a configuration example of a data transmission message that is one of the signaling messages. FIG. 25 is a diagram showing a configuration example of the data asset management table (DAMT) 2500. FIG. 26 is a diagram showing a configuration example of the data directory management table (DDMT) 2600. FIG. 27 is a diagram showing a configuration example of the data content management table (DCMT) 2700. FIG. 28 is a diagram showing a configuration example of the data content management table (DCMT) 2700. FIG. 29 is a diagram for explaining a mechanism for performing transmission, location, and presentation of a data broadcast application (content) transmitted by MMT. FIG. 30 is a diagram for describing a reference relationship of each table transmitted as signaling information when acquiring a data broadcasting application (content) from the MMT transmission path. FIG. 31 is a diagram schematically showing a mechanism for caching a data broadcasting application (content) in the receiver. FIG. 32 is a flowchart showing a file data cache control procedure in the receiver 12 based on the scheme 1. FIG. 33 is a diagram showing an example of a pre-cache operation of file data based on the method 1 in the receiver 12. FIG. 34 is a flowchart showing a file data cache control procedure in the receiver 12 based on the scheme 2. FIG. 35 is a diagram showing an example of the locking and unlocking operation of the file data cache based on the scheme 2 in the receiver 12.

  Hereinafter, embodiments of the technology disclosed in this specification will be described in detail with reference to the drawings.

  FIG. 1 schematically illustrates a configuration example of a digital broadcasting system 10 to which the technology disclosed in this specification is applied. The illustrated digital broadcast system 10 includes a broadcast transmission system 11 and a receiver 12.

  The broadcast transmission system 11 transmits a broadcast signal of an IP (Internet Protocol) system including a transmission medium. Transmission media for broadcast signals include both timed media and non-timed media such as files. The timed media is, for example, stream data related to the main broadcast program such as video, audio, and subtitles. The non-timed media is each file data used for data broadcasting, such as an HTML document. In the following description, a data broadcasting service using HTML5 is assumed.

  On the other hand, the receiver 12 receives a broadcast signal transmitted from the broadcast transmission system 11. Then, the receiver 12 acquires transmission media such as video, audio, and subtitles from the received broadcast signal, and presents images and sounds. When the receiver 12 acquires each file data for data broadcasting from the received broadcast signal, the receiver 12 activates an application engine such as an HTML browser and presents a data broadcast linked to the broadcast program.

  In the digital broadcasting system 10 shown in FIG. 1, it is assumed that the MMT is applied as a transport system for transmitting a broadcast signal from the broadcast transmission system 11 to the receiver 12. FIG. 2 shows a configuration example of the broadcast signal in this case using a stack model 200.

  At the bottom of the stack model 200 is a physical layer (PHY) 201. The physical example 201 includes a modulation method, an error correction method, and the like.

  Above the physical layer 201, there is a layer 202 of TLV (Type Length Value) transmission packets. An IP packet 203 is placed on the TLV 202, and a UDP (User Datagram Protocol) 204 is placed on the IP packet 203. Further, on the transmission packet 202 of the TLV, a header compression IP 205 obtained by compressing the header of the IP 203 and the UDP 204 and a transmission control signal 206 as signaling information are also carried.

  On the UDP 204, an MMT packet 207, an NTP (Network Time Protocol) packet 208 including current time information, and the like are placed. The MMT protocol (MMTP) is an application layer transport protocol for transmitting the MMTP payload 209 over an IP network.

  The MMT payload 209 of the MMT packet 207 includes an MFU (MMT Fragment Unit) 210 or a signaling message (Signaling Message) 211 related to data broadcasting. The MFU 210 is a fragment of an MPU (Media Processing Unit) that is a container for encoded timed media and non-timed media. Stream data (timed media) 212 such as video, audio, and subtitles, and file data (non-timed media) 213 such as HTML document data are inserted into the MFU 210.

  FIG. 3 shows a configuration example of the broadcast transmission system 11 for transmitting the broadcast signal shown in FIG. The illustrated broadcast transmission system 11 includes a clock unit 301, a signal transmission unit 302, a video encoder 303, an audio encoder 304, a caption encoder 305, a signaling encoder 306, a file encoder 307, The system includes a system 308, a TLV signaling encoder 309, an IP service multiplexer (MUX) 310, a TLV multiplexer (MUX) 311, and a modulation / transmission unit 312.

  The clock unit 301 generates time information synchronized with time information obtained from an NTP server (not shown), and sends an IP packet including this time information to the IP service multiplexer 310.

  The signal transmission unit 302 is, for example, a recording / reproducing device such as a studio of a TV broadcasting station or a VTR, and stream data such as timed media such as video, audio and subtitles, and HTML documents for data broadcasting which is non-timed media File data such as data is sent to a video encoder 303, an audio encoder 304, a caption encoder 305, and a file encoder 307, respectively. The information system 308 is a scheduler of a TV broadcast station and a file supply source, and sends HTML document data, which is non-timed media, and signaling information to a file encoder 307 and a signaling encoder 306, respectively.

  The video encoder 303 encodes the video signal transmitted from the signal transmission unit 302, packetizes the video signal, and transmits an IP packet including a video MMT packet to the IP service multiplexer 310. Further, the audio encoder 304 encodes the audio signal transmitted from the signal transmission unit 302, packetizes the audio signal, and transmits an IP packet including an audio MMT packet to the IP service multiplexer 310. Also, the caption encoder 305 encodes the subtitle signal transmitted from the signal transmission unit 302, further packetizes the subtitle signal, and transmits the IP packet including the MMT packet of the subtitle to the IP service multiplexer 310.

  The signaling encoder 306 generates a signaling message related to data broadcasting based on information transmitted from the information system 308, and converts an IP packet including an MMT packet in which the signaling message is arranged in a payload portion into an IP service multi-cast. Send to Xar 310. In the present embodiment, signaling messages related to data broadcasting are roughly classified into three types: PA messages, M2 section messages, and data transmission messages. In the present embodiment, information specifying the compulsory cache of each file used in the data broadcast is included in the data transmission message. The details of each signaling message will be described later.

  The file encoder 307 divides the file data transmitted from the signal transmission unit 302 or the information system 308 as necessary to generate an MMT packet including the file data, and converts the IP packet including the MMT packet into an MMT packet. Send to IP service multiplexer 310. The file data constitutes data broadcasting content (data broadcasting application).

  The broadcast transmission system 11 includes an IP service multiplexer 310 for each channel (broadcast program) to be transmitted. The IP service multiplexer 310 for one channel multiplexes IP packets including each of video, audio, subtitles, signaling messages, and file data sent from each of the encoders 303 to 307, and Generate a TLV packet constituting a channel.

  The TLV signaling encoder 309 encodes the signaling information sent from the information system 308 and generates a TLV packet to be placed in the payload.

  The TLV multiplexer 311 multiplexes the TLV packets generated by each of the IP service multiplexers 310-1 to 310-N and the TLV signaling encoder 309 to generate a broadcast stream.

  The modulation / transmission unit 312 performs an RF modulation process on the broadcast stream generated by the TLV multiplexer 311 and sends the broadcast stream to an RF transmission path.

  The operation of the broadcast transmission system 11 shown in FIG. 3 will be described.

  In the clock unit 301, time information synchronized with the time information acquired from the NTP server is generated, and an IP packet including this time information is generated.

  The video signal transmitted from the signal transmission unit 302 is supplied to a video encoder 303. In the video encoder 303, the video signal is encoded and further packetized to generate an IP packet including a video MMT packet. This IP packet is sent to the IP service multiplexer 310.

  Further, the same processing is performed on the audio signal and the subtitle signal transmitted from the signal transmission unit 302. Then, the IP packet including the audio MMT packet generated by the audio encoder 304 is sent to the IP service multiplexer 310, and the IP packet including the subtitle MMT packet generated by the caption encoder 305 is transmitted to the IP service multiplexer 310. -It is sent to the multiplexer 310.

  Further, the signaling encoder 306 generates a signaling message related to data broadcasting based on the information transmitted from the information system 308, and generates an IP packet including an MMT packet in which the signaling message is arranged in a payload portion. You. This IP packet is sent to the IP service multiplexer 310.

  The file data transmitted from the signal transmission unit 302 or the information system 308 is supplied to the file encoder 307. In the file encoder 307, the file data is divided as necessary, an MMT packet including the file data is generated, and an IP packet including the MMT packet is generated. This IP packet is sent to the IP service multiplexer 310.

  In each IP service multiplexer 310, IP packets including each of video, audio, subtitles, signaling messages, and file data sent from each of encoders 303 to 307 are multiplexed to form one channel. Is generated.

  The TLV signaling encoder 309 encodes the signaling information sent from the information system 308 and generates a TLV packet to be arranged in the payload.

  In the TLV multiplexer 311, the TLV packets generated by the IP service multiplexers 310-1 to 310 -N and the TLV signaling encoder 309 are multiplexed to generate a broadcast stream. The modulation / transmission unit 312 performs an RF modulation process on the broadcast stream generated by the TLV multiplexer 311 and sends the RF modulation signal to the RF transmission path.

  FIG. 4 shows a configuration example of the receiver 12 that receives the broadcast signal shown in FIG. The illustrated receiver 12 includes a tuner / demodulation unit 401, a demultiplexer (DEMUX) 402, a clock unit 403, a video decoder 404, an audio decoder 405, a caption decoder 406, and application data control. A unit 407, a cache memory 408, a data broadcasting application engine 409, a system control unit 410, a synthesizing unit 411, and an IP interface 412 are provided.

  The tuner / demodulator 401 receives the RF modulation signal, performs a demodulation process, and obtains a broadcast stream. The demultiplexer 402 performs a demultiplexing process and a packetization process on the broadcast stream to obtain NTP time information, PTS (Presentation Time Stamp: presentation time information), signaling information, and video related to the main broadcast program. It outputs coded signals of audio and captions, file data used for data broadcasting linked to a broadcast program, and signaling information. The file data used for the data broadcasting is, for example, a data broadcasting application described in the HTML5 format.

  The video decoder 404 decodes the encoded video signal obtained by the demultiplexer 402 to obtain a baseband video signal. The audio decoder 405 decodes the encoded audio signal obtained by the demultiplexer 402 to obtain a baseband audio signal. The caption decoder 406 decodes the encoded subtitle signal obtained by the demultiplexer 402 to obtain a subtitle display signal.

  The application data control unit 407 processes each file data used in data broadcasting. In the present embodiment, it is assumed that each file / data used in the data broadcasting is transmitted from a broadcast signal and two systems of an IP network. The application / data control unit 407 acquires each of them via the IP interface 412. The application data control unit 407 controls the processing of the acquired file data based on the signaling information output from the demultiplexer 402. Specifically, the application data control unit 407 manages which data broadcasting presentation unit (Presentation Unit: PU) is currently in use, and performs processing of the corresponding file data (data broadcasting application such as HTML5) using an HTML browser. , Etc., to the data broadcasting application engine 409. The data broadcasting application engine 409 processes the data broadcasting application using file data pre-cached or pre-cached in the cache memory 408 as appropriate.

  The application data control unit 407 refers to a signaling table included in each of the PA message, the M2 section message, and the data transmission message, specifies an access range required for presenting a data broadcast, and A filtering operation for caching file data that can be cached by the broadcast application engine 407 in the cache memory 408 in advance is controlled. Details of the pre-cache of the file data will be described later.

  Further, information designating a compulsory cache of each file used in the data broadcasting is included in the data transmission message. In the present embodiment, the application data control unit 407 stores, in a cache memory, file data necessary for presenting a data broadcast in a timely manner based on the compulsory cache information included in the data transmission message. 408 is pre-cached. Details of the pre-cache of the file data will be described later.

  In the broadcast stream, file data of the same content is repeatedly sent. The system control unit 410 controls the filtering operation in the demultiplexer 402, and only the necessary data in the demultiplexer 402 is acquired by the application data control unit 407 from the repeatedly sent file data group. To do.

  The system control unit 410 controls the operation of each unit of the receiver 12 based on signaling information obtained by the demultiplexer 402, operation information from a user via a user operation unit (not shown), and the like. The clock unit 403 generates time information synchronized with the time information based on the NTP time information obtained by the demultiplexer 402.

  Further, the system control unit 410 controls the decoding timing in each of the decoders 404 to 406 based on the PTS, and adjusts the presentation timing of video, audio, and subtitles. The synthesizing unit 411 synthesizes a subtitle display signal and a data broadcast display signal with a baseband video signal to obtain a video signal for video display. The baseband audio signal obtained by the audio decoder 405 is an audio signal for audio output. The main part of the broadcast program composed of the video signal and the audio signal is output as video and audio from a monitor / display (not shown). The data broadcast processed by the data broadcast application engine 409 is also displayed on the monitor display so as to be superimposed on the screen of the main broadcast program.

  The operation of the receiver 12 shown in FIG. 4 will be described.

  The tuner / demodulator 401 receives the RF modulated signal, performs demodulation processing, and obtains a broadcast stream. The demultiplexer 402 performs a demultiplexing process and a packetizing process on the broadcast stream, and encodes NTP time information, PTS, signaling information, video, audio, caption coded signals, and a file / file. The data is extracted.

  The NTP time information extracted by the demultiplexer 402 is sent to the clock unit 403. The clock unit 403 generates time information synchronized with the time information based on the NTP time information. That is, the clock unit 403 generates time information that matches the time information generated by the clock unit 301 on the broadcast transmission system 11 side.

  The coded video signal extracted by the demultiplexer 402 is sent to a video decoder 404 and decoded to obtain a baseband video signal. The coded subtitle signal extracted by the demultiplexer 402 is sent to a caption decoder 406 and decoded to obtain a subtitle display signal. The file data extracted by the demultiplexer 402 is sent to the data broadcasting application engine 407 and processed, and a display signal of data broadcasting is obtained. The filtering operation in the demultiplexer 402 is controlled by the system control unit 410 so that only the necessary file data is acquired by the demultiplexer 402.

  Then, the synthesizing unit 411 synthesizes the subtitle display signal and the data broadcast display signal with the baseband video signal to obtain a video signal for video display.

  The coded audio signal extracted by the demultiplexer 402 is sent to the audio decoder 405 and decoded to obtain a baseband audio signal for audio output. The main part of the broadcast program composed of the video signal and the audio signal is output as video and audio from a monitor / display (not shown).

  On the other hand, the application data control unit 407 manages which data broadcast presentation unit is currently present, and processes the corresponding file data (data broadcast application such as HTML5) to the data broadcast application engine 409 such as an HTML browser. Instruct. The data broadcasting application engine 409 processes the data broadcasting application using file data pre-cached or pre-cached in the cache memory 408 as appropriate. The data broadcast processed by the data broadcast application engine 409 is also displayed on the monitor display so as to be superimposed on the screen of the main broadcast program.

  Further, the application data control unit 407 refers to the signaling table included in each of the PA message, the M2 section message, and the data transmission message, and It controls a pre-cache and a forced cache for presenting a data broadcast in a timely manner in conjunction with a broadcast program (described later).

  In the digital broadcasting system 10 shown in FIG. 1, it is assumed that the MMT is applied as a transport system for transmitting a broadcast signal from the broadcast transmission system 11 to the receiver 12. FIG. 5 shows an image of a broadcast signal 500 transmitted from the broadcast transmission system 11 to the RF transmission line according to the MMT method.

  Broadcast signals of one channel (broadcast program) include timed media related to the main broadcast program such as video, audio and subtitles, and non-timed media such as file data used for data broadcasting linked to the broadcast program. The media data that is configured and encoded is stored in the MPU and transmitted. In addition, information on transmission control of these broadcast signals is transmitted as signaling information. In the MMT, it is easy to use data of timed media and non-timed media constituting one channel (broadcast program) by combining different transmission paths. In the example illustrated in FIG. 5, MMT transmission paths 501 to 504 for each data type, such as video, audio, subtitles, file data, and signaling information, are used as the broadcast signal 500. In the figure, the transmission path for caption data is not shown for convenience.

  One channel (broadcast program) can be called a “package” composed of a plurality of assets of different types such as video, audio, subtitles, file data (data application) (the package uses an MMT transmission path). Is a logical set of media data transmitted by Each asset is a set (logical group) of one or more MPUs sharing the same asset_id (asset identifier), and is transmitted on a dedicated ES (Elementary Stream) or MMT transmission path (the asset is a unique asset). An entity of data associated with an identifier and used to compose a multimedia presentation). That is, the transmission path 501 transmits a video MMT packet (MMTP) including an MPU logical group having a common asset_id, and the transmission path 502 transmits an audio MMT packet including an MPU logical group having a common asset_id. In the transmission path 503, an MMT packet of file data composed of an MPU logical group having a common asset_id is transmitted. The MPU is specified by asset_id and the sequence number of the MPU on the corresponding transmission path. Also, the MMT transmission path for transmitting each medium can be identified by asset_id.

  In addition, one package (broadcast program) may transmit a plurality of assets of the same type (that is, different asset_id). For example, there is a case where two or more file contents (data broadcasting applications) are provided for the same broadcast program. In such a case, different asset_ids are allocated to different file contents, and transmitted as different MPU logical groups on different MMT transmission paths. FIG. 5 shows only one transmission line 503 for file data for simplification.

  Further, the MMT can be used in common for a plurality of transmission paths for broadcasting and communication. Non-timed media such as HTML document data can be provided via a communication transmission path such as an IP network in addition to being transmitted along with the timed media on a broadcast transmission path as shown in FIG.

  In the transmission path 504, an MMT packet containing the same signaling message is repeatedly transmitted. In realizing the technology disclosed in this specification, three types of signaling messages, that is, a PA message 510, an M2 section message 520, and a data transmission message 530, are related to a signaling message to be transmitted. A signaling table is transmitted in various signaling messages. For example, the PA message 510 includes an MP (MMT Package) table 511. The M2 section message 520 includes an MH AI (Application Information) table 521. The data transmission message 530 is a message for notifying a data transmission method and a data management control method, and includes a data directory management table 531, a data asset management table 532, and a data content. -Each signaling table of the management table 533 is included. Details of each table will be described later.

  As described above, in MMTP, timed media such as video, audio, and subtitles, and non-timed media such as file data are transmitted. FIG. 6 shows a configuration example of the MMTP packet 600. An MMTP packet is a unit of media data formatted to be transmitted using the MMT protocol. For details, refer to Non-Patent Document 1, for example.

  If 1 is substituted for the packet counter flag “C” indicated by reference numeral 601, it indicates that the field of the packet counter indicated by reference numeral 602 exists in this MMTP packet. The packet counter 602 is a 32-bit length field for writing an integer value obtained by counting MMTP packets, and is incremented by one each time an MMTP packet is transmitted.

  When 1 is assigned to the extension flag “X” indicated by the reference number 603, it indicates that the extension header 604 indicated by the reference number 604 exists. A configuration example of the extension header 604 is also shown below FIG. The extension header 604 includes a 16-bit type field indicated by reference number 604-1, a length field indicated by reference number 604-2, and a header_extensin_value field indicated by reference number 604-3. In the length field, the byte length of the header_extensin_value field is written. In the header_extensin_value field, extended information that deviates from the MMT specification can be written.

  In the type field indicated by reference numeral 606, a type value indicating the type of the payload data of the MMTP packet is written. The definition of the type value is shown in Table 1 below.

  When 1 is assigned to a RAP (Random Access Point) flag indicated by reference numeral 605, it indicates that the payload of the MMTP packet includes a Random Access Point to a data stream of the data type.

  An integer value for distinguishing assets is written in a 16-bit packet_id field indicated by reference numeral 607. The value of this field is derived from asset_id of the asset to which the MMTP packet belongs. The mapping between packet_id and asset_id is indicated in the MMT package (MP) table that is part of the signaling message.

  The transmission time of the MMTP packet is described in a short-format specified by the NTP protocol in a 32-bit timestamp field indicated by reference numeral 608.

  In a 32-bit packet_sequence_number field indicated by reference numeral 609, an integer value (sequence number on the MMT transmission path) for identifying packets having the same packet_id is described.

  FIG. 7 shows a configuration example of the extension header 700 in the case of an MMTP packet transmitting non-timed media. As illustrated, in this case, 4 is written in the length field 701 as the byte length of the header_extensin_value field. In the header_extensin_value field 702, download_id is described in 4 bytes.

  When transmitting an MPU using the MMT protocol, the transmitting side and the receiving side need to be packetized and depacketized, respectively. Due to the packetization, the MPU is inserted into the MMTP payload and transmitted in the MMTP packet. The format of the MMTP payload allows for fragmentation of the MMTP payload so that large payloads can be transmitted. The format of the MTP payload also allows for aggregation of multiple MMTP payloads into a single MMTP payload, corresponding to small data units. On the receiving side, the packet is depacketized to restore the original MPU data.

  FIG. 8 shows a configuration example of the MMTP payload 800 in the case of the MPU mode. For details, refer to Non-Patent Document 1, for example. In the MPU mode, “0x00” is written in the type field 606 of the MMTP header. The MMTP packet in the MPU mode is used for transmitting video and audio related to the main part of the broadcast program, and file data (data broadcast application) linked to the broadcast program.

  In the MPU Fragment Type (FT) field indicated by reference numeral 801, the type of the fragment is indicated by a 4-bit value. The definition of the FT value is shown in Table 2 below.

  When 1 is entered in the Timed (T) flag indicated by reference numeral 802, it indicates that the MPU transmitting the timed media is fragmented, and when 0 is entered, the MPU transmitting the non-timed media is fragmented. Indicates that is fragmented.

  A Fragmentation Identifier (f_i) field indicated by reference numeral 803 represents information on fragmentation of a data unit in the payload by two bits. Table 3 below defines the four values of f_i.

  When the payload is an aggregate of a plurality of data units, 1 is written in the aggregation (A) flag indicated by reference numeral 804.

  The number of payloads including fragments of the same data unit followed by the MMTP payload is described in an 8-bit fragment_counter field indicated by reference numeral 805.

  A 16-bit DU_length field indicated by reference numeral 806 describes the length of data (DU: Data Unit) following the field. However, when the A flag 804 is 0, there is no DU_length field 806.

  DU_Header indicated by reference numeral 807 is a data unit header. However, when the FT value 801 is 0 or 1 (in other words, when the FT value is not MFU), there is no DU_Header 807. The MFU contains timed media samples or subsamples or non-timed media items.

  FIG. 9 illustrates a configuration example of a DU_Header 900 of an MFU in which timed media is arranged in a payload. FIG. 10 shows a configuration example of the DU_Header 1000 of the MFU in which non-timed media is arranged in the payload. As shown in FIG. 10, DU_Header 1000 in the case of non-timed media is configured by a 32-bit item_ID that is an identifier of an item transmitted as a part of the MFU. An item is a resource that constitutes an application, such as HTML document data or monomedia data referenced from the HTML document. On the MMT transmission path specified by the asset_id, an item can be uniquely specified by a combination of the packet_id in the header of the MMTP packet, the download_id in the extension header, and the item_ID in the DU header.

  FIG. 11 shows an example of a packet configuration when transmitting non-timed media data.

  FIG. 11A shows the state of the original file data. In the figure, F1 and F2 are each one file data. The file data is, for example, an HTML document and includes one or more items. Further, the HTML document itself is one item.

  FIG. 11B shows a state where the file data F1 and F2 are arranged in the MFU. Since the file data F1 does not have a large file size, it is directly arranged in the payload of one MFU. On the other hand, since the file data F2 has a large file size, it is divided into a plurality of pieces, each of which is arranged in the payload of the MFU. In the illustrated example, the file data F2 is divided into two parts, F2-1 and F2-2, each of which is arranged in a payload of another MFU.

  Here, a DU_Header (see FIG. 10) in which an item_ID uniquely indicating the item is described is attached to the MFU in which non-timed media such as HTML document data and mono media are arranged in the payload.

  Next, as shown in FIG. 11 (c), each MFU is attached with a header of an MMT payload (see FIG. 8) to become an MMT payload. Here, the value 2 is described in the Fragment Type (FT) field of the header of the MMT payload to indicate that the fragment type is MFU. In addition, a value 0 is described in the Timed (T) flag to indicate that the MPU transmits non-timed media. In the MFU in which non-timed media that is not fragmented is arranged, a value 0 is described in the Fragmentation Identifier (f_i) field. On the other hand, in the MFU in which the fragmented non-timed media is arranged, a value 1 is described in a Fragmentation Identifier (f_i) field, and a corresponding count value is described in a fragment_counter field.

  Next, as shown in FIG. 11D, the header of the MMTP packet and the extension header (see FIG. 6) are added to each MMT payload to form an MMT packet stream. Here, 0 is described in the type field of the MMTP header to indicate that the type of payload data is MPU, and an integer value for distinguishing assets is written in the packet_id field. Also, download_id is described in the extension header. Therefore, on the MMT transmission path specified by asset_id, an item can be uniquely specified by a combination of the above-described packet_id in the header of the MMTP packet, download_id in the extension header, and item_ID in the DU header.

  Further, as shown in FIG. 11E, an IP header and a UDP header are added to each MMT packet to form an IP packet stream. Although not shown, by attaching a TLV header to each IP packet, a TLV packet constituting a broadcast stream is generated.

  Although not shown in FIG. 11, the MMT packet includes an MMT packet including a signaling message in a payload. Signaling messages include PA messages, M2 section messages, and data transmission messages (see above and FIG. 5). Whether the MMTP payload includes transmission media such as timed media or non-timed media, or includes a signaling message can be identified by referring to the value of the type field in the MMTP header.

  Subsequently, a configuration of a signaling message used in the MMT protocol, which is relevant for realizing the technology disclosed in this specification, will be described. The signaling message is signaling information necessary for controlling transmission of the package and using the package, and transmits various signaling tables.

  MMT signaling messages use a general format consisting of three common fields, one specific field for each signaling message type, and the message payload. The message payload carries signaling information. Hereinafter, the PA message, the M2 section message, and the data transmission message will be described in this order.

  The PA (Package Access) message transmits a PA table having information on all signaling tables required for the Package Access. The PA table includes an MMT Package (MP) table. FIG. 12 shows a configuration example of a PA message 1201 which is one of the signaling messages and an MP table 1202 included in the PA message. FIG. 13 shows a syntax example of the PA message 1300, and FIG. 14 shows a description of parameters included in the PA message.

  The message_id is a fixed 16-bit value for identifying a PA message in various types of signaling information. version is an 8-bit integer value parameter indicating the version of the PA message. For example, when some parameters constituting the MP table are updated, the version is incremented by +1. The length is a 32-bit parameter that indicates the size of the PA message in bytes, counted immediately after this field.

  In the extension field, index information of an MP table (MPT) arranged in the payload field is arranged. In this field, an 8-bit table_id, an 8-bit table_version, and a 16-bit table_length are arranged. table_id is a fixed value for identifying the MP table. table_version indicates the version of the MP table. table_length indicates the size of the MP table in bytes.

  The MP table is arranged in the payload field of the PA message. The MP table stores information related to the package including a list of all assets.

  FIGS. 15 and 16 show examples of the syntax of the MP table (FIG. 16 shows the latter half of FIG. 15). FIG. 17 illustrates the parameters included in the MP table. Hereinafter, the configuration of the MP table will be described.

  The table_id is an 8-bit fixed value that identifies an MP table in various types of signaling information. "version" is an 8-bit integer value indicating the version of the MP table. For example, when some of the parameters that make up the MP table are updated, the version is incremented by +1. length is a 32-bit parameter indicating the size of the MP table in bytes, which is counted immediately after this field.

  The MMT_package_id is identification information as an entire package including assets such as all signals (video, audio, subtitles) and file data transmitted as broadcast signals. This identification information is text information. MMT_package_id_length indicates the size of the text information in bytes.

  The MP_table_descriptors field is a storage area for descriptors relating to the entire package. MPT_table_descriptor_length is a 16-bit parameter indicating the size N2 of the field in bytes. MP_table_descriptor presupposes that N2 bytes (one or more) are arranged after defining various target descriptors.

  The number_of_assets is an 8-bit parameter indicating the number of assets (signals, files) as elements constituting the package. The following Asset loops are arranged by the number (N3) of the number_of_assets.

  In one Asset loop, each parameter of asset_id_len, asset_id, gen_loc_info, asset_dsc_len, asset_descriptor as information of each asset is arranged.

  asset_id is text information that uniquely identifies an asset. asset_id_len indicates the size of asset_id in bytes. gen_loc_info is information indicating the location from which the asset is obtained. In the present embodiment, gen_loc_info is described in the format of packet id on the transmission path from which the asset is acquired. Therefore, the corresponding packet ID on the MMT transmission path can be extracted by subtracting asset_id on the MP table.

  The asset_descriptor field is an area for storing descriptors related to assets. asset_descriptor_length indicates the size N5 of the asset_descriptor field in bytes. As for asset_descriptor, it is assumed that N5 (one or plural) descriptors are arranged after defining various target descriptors.

  The M2 section message is a signaling message used for transmitting the section extension format of the MPEG-2 System as it is. FIG. 18 shows a configuration example of the M2 section message 1800. Hereinafter, the meaning of each parameter of the M2 section message will be described.

  The message_id (message identification) is a fixed 16-bit value for identifying the M2 section message in various types of signaling information, and is set to 0x8000 in the present embodiment. "version" is an 8-bit integer value parameter indicating the version of the M2 section message. The length (message length) is a 16-bit parameter, which is counted immediately after this field and indicates the size of the M2 section message in bytes. table_id (table identification) is an area used for identifying a table to which the section belongs. The section_syntax_indicator (section syntax instruction) is set to “1” indicating an extended format. section_length (section length) is an area in which the number of bytes of data following the section length area is written. The table_id_extension (table identification extension) is an area for extending the table identification. The version_number (version number) is an area for writing the version number of the table. The current_next_indicator (current next instruction) is set to “1” when the table is currently usable, and is set to “0” when it indicates that the table is currently unusable and becomes valid next. section_number (section number) is an area in which a section number constituting the table is written. last_section_number (final section number) is an area in which the last section number constituting the table is written. CRC32 (CRC), ITU-T Recommendation H.264. It is a cyclic redundancy code according to 222.0.

  FIG. 19 shows a configuration example of an MH AI (Application Information) table (MH AIT) 1900 transmitted by an M2 section message. Hereinafter, the meaning of each parameter of the MH AI table will be described.

  The table_id (table identification) is an 8-bit fixed value that identifies an application information (AI) table in various types of signaling information, and is set to 0x89 in the present embodiment. The section_syntax_indicator (section syntax indication) is a 1-bit field and is always “1”. The section_length (section length) is a 12-bit field, and the first two bits are always “00”. This defines the number of bytes in the section from the section length field to the end of the section including CRC32. This value shall not exceed 1021 (0x3FD in hexadecimal). “applicaton_type” (application format) is a 16-bit field and indicates a value of an application transmitted by AIT. In DVB, 0x0001 is assigned to the DVB-J application. It is set to 0x0001 also in the ARIB-J application. The version_number (version number) is a 5-bit field and is a version number of the sub-table. The version_number is the version number of the MH AI table, and is incremented by +1 when the information in the sub-table changes. When the value of the version number becomes “31”, the value returns to “0” next. The current_next_indicator (current next instruction) is always “1”. section_number (section number) is an 8-bit field and represents a section number. The section number of the first section in the sub-table is 0x00. The section number is incremented by +1 each time a section having the same table identification and application type is added. last_section_number (last section number) is an 8-bit field and defines the last section number in the sub-table to which the section belongs.

  The common_descriptor_length (common descriptor loop length) is an 8-bit field and defines the byte length of the subsequent descriptor (descriptor in the description area). This descriptor (descriptor in the description area) stores information on the descriptor (descriptor) in a series of areas composed of loops for the number of common_descriptor_length. Descriptor applies to all applications in the AIT sub-table. For example, a transmission protocol descriptor is written in the descriptor field.

  application_loop_length is an area in which the number of pieces of application information included in the MH AI table is written. Then, application information loops are arranged by the number indicated by application_loop_length.

  In one application information loop, a descriptor described in a series of loops corresponding to application_identifier (application identifier), application_control_code (application control code), and application_descriptor_loop_length (application information descriptor loop length) is included. Application information descriptor). Descriptors in this descriptor area apply only to the specified application.

  application_identifier (application identifier) is a parameter for identifying an application. The application_control_code (application control code) is an 8-bit field that defines a control code for controlling the state of the application. The semantics of this field depend on the value of the application type. If “autostart” is indicated as the application_control_code, the receiver that refers to the MHAT table starts the application specified by the application_identifier. If “prefetch” is specified as the application_control_code, the receiver that refers to the MHAT table prefetches the application specified by the application_identifier. If “kill” is indicated as the application_control_code, the receiver that refers to the MHAT table stops executing the application specified by the application_identifier. CRC32 (CRC), ITU-T Recommendation H.264. It is a cyclic redundancy code according to 222.0.

  In short, the MH AI table is a table that specifies a processing method, a transmission method (transport_protocol), and a location (URL) of an application (file data) transmitted through the MMT transmission path. Upon receiving the MH AI table sent in the M2 section message, the receiver acquires an application from the specified location with the specified transport_protocol in order to execute the process specified by application_control_code.

  FIG. 20 illustrates a configuration example of the application information descriptor 2000 stored in the loop of the application information of the MH AI table. FIG. 21 shows the description of the parameters included in the application information descriptor 2000. Hereinafter, the meaning of each parameter of the application information descriptor 2000 will be described.

  “descriptor_tag” is an 8-bit integer value that identifies the descriptor 2000. “descriptor_length” is an area for writing the number of bytes of data of the descriptor 2000 following the field.

  Application_profile information is written in a series of regions consisting of loops corresponding to the number of application_profile_lengths. The application_profile is a profile of a receiver that can execute this application, and indicates a requested function in a bitmap for each function requested to the receiver. However, the upper three bits indicate the function bitmap switching. The bitmap is defined for each version. Further, version_major, version_minor, and version_micro are each a version defined in the application profile.

  service_bound_flag is a flag indicating whether this application is valid only for the current service. Visibility indicates whether or not the application is visible. application_priority is the relative priority between applications advertised in this service. “transport_protocol_label” indicates a protocol for transmitting the application. As the value of the transport_protocol_label, 0x0003 specifies HTTP / HTTPS transmission, and 0x0005 specifies MMT and non-timed transmission.

  FIG. 22 shows a configuration example of the transmission protocol descriptor 2200. Hereinafter, the meaning of each parameter of the transmission protocol descriptor 2200 will be described.

  “descriptor_tag” is an 8-bit integer value that identifies the descriptor 2200. The descriptor_length is an 8-bit area in which the number of bytes of data of the descriptor 2200 following the field is written.

  protocol_id (protocol identifier) indicates a protocol for transmitting the application. As values, 0x0003 specifies HTTP / HTTPS transmission, and 0x0005 specifies MMT and non-timed transmission. The transport_protocol_label (transmission protocol label) is a value for uniquely identifying a transmission means when one application is transmitted through a plurality of routes, and corresponds to a field having the same name in the application information descriptor. “selector_byte” (selector byte) is an area in which syntax is defined for each protocol ID, and an acquisition location is written in the area.

  FIG. 23 shows a configuration example of a selector byte 2300 common to HTTP / HTTPS and MMT non-timed transmission.

  The URL_base_byte stores text information indicating the URL_base of the URL character string in a series of regions including loops corresponding to the number of URL_base_lengths.

  URL_extension_count indicates the number of URL_extensions following the URL_base, and URL_extension loops are arranged by the number of URL_extension_counts. In one URL_extension loop, URL_extension_byte stores text information indicating each URL_extension in a series of loops corresponding to the number of URL_extension_lengths defining the length of the URL_extension. Each URL_extension is a URL character string following the URL_base. For example, if the URL_base is “http://www.xbc.com” and the URL_extension is “index.html”, these character strings are concatenated to form a complete URL “http://xbc.com/index. .Html "can be obtained.

  In short, by referring to the application information descriptor and the transmission protocol descriptor in the loop of the application information of the MH AI table, the transmission means (MMT transmission or HTML transmission) of the application and the location information (URL) are obtained. can do.

  FIG. 24 shows a configuration example of a data transmission message 2400 which is one of the signaling messages. Hereinafter, the meaning of each parameter of the data transmission message will be described.

  The message_id (message identification) is a fixed 16-bit value for identifying a data transmission message in various types of signaling information, and is set to 0xF000 in the present embodiment. The version (version) is an area for writing a version number of the data transmission message. The length (message length) is a 32-bit parameter indicating the size of the data of the message following this field in bytes.

  num_of_tables (the number of tables) indicates the number of tables to be stored in the data transmission message. As a table to be stored in the data transmission message, table information loops are arranged by the number indicated by num_of_tables.

  In the loop of one table information, table_id (table identification), table_version (table version), and table_length (table length) are stored as table information. The table_id (table identification) is an area used for identifying a table stored in the data transmission message. In the data transmission message, three types of signaling tables are transmitted: a data asset management table (DAMT), a data directory management table (DDMT), and a data content management table (DCMT). (Described above), and the table_id (table identifier) identifies which of these tables it is. table_version (table version) indicates the version of the table stored in the data transmission message. table_length (table length) indicates the size of the table stored in the data transmission message in byte units.

  Also, table loops are arranged by the number indicated by num_of_tables. In the loop of one table, information on the contents of the table identified by table_id is stored. "table" indicates a table to be stored in the data transmission message.

  FIG. 25 shows a configuration example of the data asset management table 2500 transmitted by the data transmission message. The data asset management table is a table that manages information on assets of file data transmitted as MMTP packets and information on items included in each asset of file data. Hereinafter, the meaning of each parameter of the data asset management table will be described.

  The table_id (table identification) is a fixed value of 8 bits indicating that it is a data asset management table in various types of signaling information, and is set to 0xA2 in the present embodiment. version_ (version) is an 8-bit integer value parameter indicating the version of the data asset management table. For example, if some of the parameters making up the data asset management table are updated, the version is incremented by +1. The length is a 16-bit parameter indicating the size of this data asset management table in bytes, which is counted immediately after this field.

  The number_of_asset is an 8-bit parameter indicating the number of file data assets included in the package. The following loops of asset information are arranged by the number of number_of_assets, and information of file data for each asset is stored.

  The loop of one asset information includes download_id, information on the asset (file data) itself, and information on each item included in the asset. download_id is identification information written in an extension header of an MMTP packet transmitting non-timed media (file data) (see FIG. 7).

  The information about the asset itself stored in the asset information loop includes asset_ID_scheme, asset_ID_length, asset_ID_length, and asset_ID_byte. asset_ID_scheme indicates the format of asset_ID. As a format of the asset_ID, for example, a UUID (Universal Unique Identifier), a URI (Uniform Resource Identifier), and a GUIL (General URL) can be assigned. asset_ID_length represents the length of asset_ID_byte in bytes. The asset_ID_byte indicates the asset_ID in a series of loops corresponding to the number of the assets_ID_length in the format specified by the asset_ID_scheme. Incidentally, in the present embodiment, this information is used as information for identifying the asset in common with the MP table and the data asset management table. However, since the data amount is large, other substitute asset identification information may be used. . For example, it is assumed that 16-bit component_tag is defined as information corresponding to asset_ID in the MP table, and component_tag is used instead of asset_ID in the data asset management table.

  The number_of_items is an area in which the number of items constituting the asset of the corresponding file data is written. Then, item loops are arranged by the number of number_of_items, and information on each item constituting an asset (file data) is written.

  In the loop of one item, each parameter of item_ID, node_tag, item_size, item_version, item_checksum, and item_info is described as information on the item. item_ID is a 32-bit value indicating an ID for identifying an item transmitted in non-timed MFU. The node_tag is information for similarly identifying an item, and is a 16-bit value. By using a 16-bit node_tag instead of the 32-bit item_ID as the signaling information, the bit size required for identifying the item can be reduced. The node indicates each of a directory and an item which are nodes on a directory structure constituting a data broadcasting application (content). A directory as well as an item can be specified by node_tag. item_size represents the size of the item in bytes. item_version indicates the version of the item, and the version is incremented by +1 each time the content of the item is updated. item_checksum indicates the checksum of the item. It should be noted that it is considered that the checksum is always set for all files because of a large amount of information. Therefore, with such considerations, for example, a 1-bit check_sum_flag may be set, and a 32-bit item_check_sum may appear only when 1 is substituted into this. Alternatively, instead of signaling, a checksum may be indicated as a type as an extension header of the MMTP packet shown in FIG. 7, and a 32-bit checksum may be arranged after length. item_info_length indicates the size of the information area of item_info_byte in bytes. The item_info_byte stores information (item_info ()) related to the item in a series of regions each including a number of loops corresponding to the number of item_info_length.

  “descriptor_loop_length” indicates the total byte length of the descriptor. The descriptor stores descriptor information (descriptor ()) in a series of areas composed of a number of loops equal to the number of descriptor_loop_length. Descriptors to be stored are defined separately.

  In short, the data asset management table 2500 is a table that manages information on assets of file data (content) included in one package and items included in the asset. The version information of the item is also managed as the information on the item. Referring to data asset management table 2500, node_tag (or Item_ID) is subtracted from corresponding asset_id or downloadID or item_info described in the MMT extension header for transmitting the asset, and node_tag handled on the transmission path of signaling information. , Item_ID and item_info on the file / data transmission path can be subtracted.

  FIG. 26 shows a configuration example of a data directory management table (DDMT) 2600 transmitted by a data transmission message. The data directory management table is a table that manages directories constituting data broadcasting applications (contents) and location information of each node (lower-order directories and items (file data)) included in the directories. Hereinafter, the meaning of each parameter of the data directory management table will be described.

  In table_id (table identification), an 8-bit fixed value indicating a data directory management table is written in various kinds of signaling information. version_ (version) is an 8-bit integer value parameter indicating the version of the data directory management table. For example, if some of the parameters constituting the data directory management table are updated, the version is incremented by +1. The length is a 16-bit parameter indicating the size of this data directory management table in bytes, which is counted immediately after this field.

  base_folder_path_length indicates the size of the information area of base_folder_path_byte in bytes. The base_folder_path_byte stores the path name to the base_folder (upper-level directory) in a series of loops corresponding to the number of base_folder_path_length. The base_folder_path_byte is expressed in, for example, an absolute URL format for accessing a corresponding directory.

  num_of_folder_nodes indicates the number of folder nodes described in the data directory management table. Then, folder node loops are arranged by the number of num_of_folder_nodes.

  In the loop of one folder node, information of each folder node described in the data directory management table and information of each file data included in the base folder are stored.

  folder_node_path_length indicates the size of the information area of folder_node_path_byte in bytes. The folder_node_path_byte stores a path name to the folder_node in a series of regions each including a number of loops corresponding to the number of the folder_node_path_length. The folder_node_path_byte is expressed in a URL format relative to the base_folder_path for accessing a corresponding directory, for example. Although not shown, folder_node_version (folder node version information) may be included as folder node information. For example, if the path name (URL) of base_folder is “http://www.xbc.com” and the bus name (URL) of a certain folder_node is “index.html”, these character strings are concatenated. The complete URL "http://xbc.com/index.html" can be obtained.

  num_of_files indicates the number of files described in the data directory management table. Then, file loops are arranged by the number of num_of_files.

  In a loop of one file, node_tag and file_name_byte (file name) are stored as information of each file data included in the base folder. The node_tag represents information for identifying an item transmitted by the non-timed MFU by 16 bits shorter than the 32-bit item_ID. The node indicates each of a directory and an item which are nodes on a directory structure constituting a data broadcasting application (content). A directory as well as an item can be specified by node_tag (described above). The file_name_byte is stored in a series of areas including loops corresponding to the number of file_name_lengths.

  In short, the data directory management table 2600 is a table for managing the directory structure of directories included in one package and subdirectories and files (items) included in the directory. By the data directory management table 2600, the file configuration of the data broadcasting application and the configuration for file transmission can be separated. Also, by referring to the data directory management table 2600, the path name (URL) of the corresponding item can be subtracted from the node_tag, or the corresponding node_tag can be subtracted from the path name (URL). In this configuration example, in the data directory management table, the location information of the directory where the file exists is set as folder_path_byte, and each directory is given identification information as node_tag, and the information for each item is the file name and node_tag. Since only the folder_path_byte is specified, the amount of information of folder_path_byte does not become too large.

  Next, the data content management table (DCMT) transmitted in the data transmission message will be described.

  The data content management table (DCMT) is a table for managing file data transmitted as non-timed media, that is, information of content (data broadcasting application). In the present embodiment, the data content management table is transmitted including information specifying the compulsory cache. Data broadcasting linked to a broadcast program is required to be presented in a timely manner. In such a case, the broadcast transmission system 11 includes information for designating a compulsory cache in the data content management table (DCMT) so that the receiver 12 can use the data in a data broadcast linked to the broadcast program. Each file is pre-cached, and timely presentation of a data broadcast can be realized.

  The following two methods can be cited as a method of transmitting forced cache information using a data content management table (DCMT).

(Method 1) In the data content management table, for each data broadcast presentation unit (PU), a broadcast transmission file (member item) list constituting a presentation unit, a primary file (primary item), and a pre-cache If the target file exists, the information of the target file list (pre-cache item) is described.

  The pre-cache target file referred to here is composed of, for example, a broadcast file list that configures a data broadcast presentation unit (PU) to be referred next from a current data broadcast presentation unit (PU). By presenting the pre-cache target file list with the data broadcast signaling information on the broadcast program production side, the receiver pre-caches the file data required for the next transition data broadcast presentation unit on the receiver side. That is, a cache control operation by a pre-cache can be performed. As a result, a timely data broadcast service linked to the broadcast program can be realized.

(Method 2) In the data content management table, for each data broadcast presentation unit (PU), a broadcast transmission file (member item) list constituting the presentation unit, a central file (primary item), and a lock to the cache are locked. The information on the target file (lock cache item) to be locked and the target file to be unlocked (unlock cache item) among the lock targets are described.

  The lock target file referred to here is composed of, for example, a broadcast file list used from the current data broadcast presentation unit (PU) to the next referenced data broadcast presentation unit (PU). By presenting the list of files to be locked and unlocked by the signaling information of the data broadcast on the production side of the broadcast program, the receiver can perform the cache control operation by locking and unlocking. For example, on the receiver side, file data required for the next transition data broadcasting presentation unit can be locked in the cache. As a result, a timely data broadcast service linked to the broadcast program can be realized. In addition, the unlock target file is composed of, for example, a broadcast file list that is unnecessary in the current data broadcast presentation unit (PU). By specifying the file to be unlocked, unnecessary files can be deleted from the cache memory 408, and the memory size can be saved.

  FIG. 27 shows a configuration example of a data content management table (DCMT) 2700 transmitted by a data transmission message that implements scheme 1.

  In the table_id (table identification), an 8-bit fixed value indicating a data content management table in various types of signaling information is written. version_ (version) is an 8-bit integer value parameter indicating the version of the data content management table. For example, when some parameters constituting the data content management table are updated, the version is incremented by +1. The length is a 16-bit parameter that indicates the size of this data content management table in bytes, which is counted immediately after this field.

  The number_of_content is an 8-bit parameter indicating the number of contents included in the package (the content is, for example, file data such as an HTML document describing a data broadcasting application). The following content loops are arranged by the number of number_of_contents, and information for each content is stored.

  In a loop of one content, content_ID, content_version, content_cache_size, and information on a data broadcast presentation unit (Presentation Unit: PU) included in the content are written as information on the content. content_ID is identification information of the content. content_version indicates the version of the content. content_cache_size indicates the size at which the content is cached.

  The number_of_PU is the number of data broadcast presentation units PUs included in the content, and PU loops are arranged by the number of the number_of_PUs.

  In a loop of one PU, PU_tag which is identification information of the PU, PU_cache_size which indicates a cache size of the PU, and PU_primary_item_node_tag which identifies a file (primary item) at the center of the data broadcast presentation unit (PU). Written.

  In the loop of the PU, a broadcast transmission file (member item) list constituting the data broadcast presentation unit (PU) is written. Specifically, number_of_PU_member_nodes indicates the number of nodes included in the data broadcast presentation unit (PU) (that is, members of the PU). Thereafter, as many loops of PU member nodes as the number of the number_of_PU_member_nodes are arranged, and the node_tag of the PU member node is written in the loop of each PU member node. PU member nodes include directory nodes and item nodes.

  Further, in the PU loop, if a target file to be pre-cached exists in the corresponding PU, information on the target file list (pre-cache item) is described. Specifically, number_of_pre_cache_nodes is the number of nodes to be pre-cached, and loops of pre-cache nodes by the number of number_of_pre_cache_nodes are arranged. In the loop of one precache node, a pre_cache_node_tag identifying the precache node is written.

  The pre-cache target file referred to here is composed of, for example, a broadcast file list that configures a data broadcast presentation unit (PU) to be referred next from a current data broadcast presentation unit (PU). By presenting the pre-cache target file list with the data broadcast signaling information on the broadcast program production side, the receiver pre-caches the file data required for the next transition data broadcast presentation unit on the receiver side. You can keep. As a result, a timely data broadcast service linked to the broadcast program can be realized.

  Further, within the loop of one PU, number_of_linked_PUs indicating the number of other PUs linked from this PU and loops of linked_PUs corresponding to the number of the number_of_linked_PUs are arranged. In one linked_PU loop, a linked_PU_tag which is identification information of the linked_PU is written.

  FIG. 28 shows a configuration example of a data content management table (DCMT) 2800 transmitted by a data transmission message that implements scheme 2.

  In the table_id (table identification), an 8-bit fixed value indicating a data content management table in various types of signaling information is written. version_ (version) is an 8-bit integer value parameter indicating the version of the data content management table. For example, when some parameters constituting the data content management table are updated, the version is incremented by +1. The length is a 16-bit parameter that indicates the size of this data content management table in bytes, which is counted immediately after this field.

  The number_of_content is an 8-bit parameter indicating the number of contents included in the package (the content is, for example, file data such as an HTML document describing a data broadcasting application). The following content loops are arranged by the number of number_of_contents, and information for each content is stored.

  In a loop of one content, content_ID, content_version, content_cache_size, and information on a data broadcast presentation unit (Presentation Unit: PU) included in the content are written as information on the content. content_ID is identification information of the content. content_version indicates the version of the content. content_cache_size indicates the size at which the content is cached.

  The number_of_PU is the number of data broadcast presentation units PUs included in the content, and PU loops are arranged by the number of the number_of_PUs.

  In a loop of one PU, PU_tag which is identification information of the PU, PU_cache_size which indicates a cache size of the PU, and PU_primary_item_node_tag which identifies a file (primary item) at the center of the data broadcast presentation unit (PU). Written.

  In the loop of the PU, a broadcast transmission file (member item) list constituting the data broadcast presentation unit (PU) is written. Specifically, number_of_PU_member_nodes indicates the number of nodes included in the data broadcast presentation unit (PU) (that is, members of the PU). Thereafter, as many loops of PU member nodes as the number of the number_of_PU_member_nodes are arranged, and the node_tag of the PU member node is written in the loop of each PU member node. PU member nodes include directory nodes and item nodes.

  Further, in the PU loop, in the corresponding PU, a file to be locked in the cache memory 408 (lock cache item) and a file to be unlocked among the lock targets (unlock cache item) Describe the information. Specifically, number_of_lock_cache_nodes is the number of nodes to be pre-cached, and thereafter, loops of lock target nodes for the number of number_of_lock_cache_nodes are arranged. Lock_cache_node_tag for identifying a lock target node is written in a loop of one lock target node. Further, number_of_unlock_cache_nodes is the number of nodes to be pre-cached, and thereafter, loops of unlock target nodes for the number of number_of_unlock_cache_nodes are arranged. Unlock_cache_node_tag identifying the unlock target node is written in the loop of one unlock target node.

  The lock target file referred to here is composed of, for example, a broadcast file list used from the current data broadcast presentation unit (PU) to the next referenced data broadcast presentation unit (PU). On the broadcast program production side, by presenting the lock target file list with the data broadcast signaling information in this way, the receiver locks the file data necessary for the next transition data broadcast presentation unit to the cache. Can be kept. As a result, a timely data broadcast service linked to the broadcast program can be realized. In addition, the unlock target file is composed of, for example, a broadcast file list that is unnecessary in the current data broadcast presentation unit (PU). By specifying the file to be unlocked, unnecessary files can be deleted from the cache memory 408, and the memory size can be saved.

  Further, within the loop of one PU, number_of_linked_PUs indicating the number of other PUs linked from this PU and loops of linked_PUs corresponding to the number of the number_of_linked_PUs are arranged. In one linked_PU loop, a linked_PU_tag which is identification information of the linked_PU is written.

  In short, the data content management table is a table that manages each content (data broadcast application) in data broadcast presentation units (PUs) in one package, and refers to the data_content management table to read the node_tag. Thus, PU_tag of the data broadcast presentation unit including the node can be obtained. Another feature is that the data content management table receiver 12 controls the compulsory caching of data broadcast files. However, the details of the cache control operation using the data content management table will be described later.

  FIG. 29 illustrates a mechanism for transmitting a data broadcast application (content) transmitted by MMT, a location of the content, and presentation of the application.

  FIG. 29A shows a directory structure of the content. Each of the contents 1, 2,... Is composed of a data broadcasting application (app) and a material. Data broadcasting applications and materials are resources each having file data as an entity. Each resource corresponds to an item that is a component of an asset on the MMT transmission path, and can be identified by a 32-bit item_ID. In the signaling information, an item can be identified by a 16-bit node_tag. As shown in FIG. 29C, each resource is transmitted as an item on the MMT transmission path of the corresponding asset (described later). The application includes one or more HTML documents that are referred to when executing the content (when presenting the data broadcast). The material is monomedia data such as a jpeg image or text referred to from an HTML document. One HTML document and the materials referred to from it form one data broadcast presentation unit PU. In the example shown in FIG. 29A, content1 is A11. html, A12. html, A13. It has one or more HTML documents such as html as resources of the data broadcasting application. Among them, A11. html is a resource that is directly referred to when executing the content.

  FIG. 29B shows a reference relationship between resources when content is executed (when data broadcasting is presented). In the illustrated example, the application A11 that is directly referred to when the content is executed and the materials B11 and B02 that are referred to by the application A11 are the resource group 2801 that constitutes one data broadcast presentation unit PU, and p1 is assigned as PU_tag ( Note that B14 is a material that can be acquired at any time by HTTP transmission by communication instead of MMT transmission by broadcasting, and is hereinafter treated as not included in the resource group of the data broadcasting presentation unit).

  Similarly, the application A12 and the materials B12, B02, and B13 to which the application A12 refers are a resource group 2802 that constitutes one data broadcast presentation unit PU, and p2 is assigned as PU_tag (B07 is an MMT based on broadcast. It is a material that can be obtained at any time by HTTP transmission through communication instead of being transmitted, and is hereinafter treated as not included in the resource group of the data broadcast presentation unit). Similarly, the application A01 and the materials B03, B01, and B04 to which the application A01 refers are a resource group 2803 that constitutes one data broadcast presentation unit PU, and p3 is assigned as PU_tag.

  Further, a link reference relationship can be established between a plurality of HTML documents (well-known). In the example shown in FIG. The html is an HTML document that directly refers to the content when it is executed and describes an application presentation screen that is displayed first. On the other hand, resources A12. html and resources A01. html is A11. html is an HTML document that describes an application presentation screen that transitions from a screen presented by executing html. A11. html and has a link reference relationship. Each resource A11. html, A12. html, A01. html form resource groups 2801, 2802, and 2803, each of which constitutes one data broadcast presentation unit PU. Then, the data broadcast presentation units 2801, 2802, and 2803 that are linked together constitute a higher-order large resource group 2810. Resource A11. html, A12. html, A01. html is the primary file data (primary item_node) in each data broadcast presentation unit PU.

  Further, a large resource group, that is, the entire data content is formed by the entire content, which is the entire application included in the package (one broadcast program). The entire data content is a range of the data broadcast presentation unit PU having a common content_ID. In the data content management table, all data broadcast presentation units PU included in the content can be specified collectively by turning the loop of the PU of the corresponding content_ID. In the example shown in FIG. 29B, a resource group 2820 of the entire content is formed by the applications included in content1 and common.

  FIG. 29C schematically shows how the content is transmitted by MMT. Each of the applications and materials, which are components of the content, has file data as an entity, and is also called a “resource”. Each resource corresponds to an item that is a component of an asset on the MMT transmission path. In the MMT transmission, each content included in the package is treated as one asset, and an Asset_ID is assigned to each asset. In the illustrated example, content1 is assigned a1 as asset_ID. In the MMT transmission, individual resources such as HTML document data and materials are treated as one item, and an Item_ID is assigned to each item. In the illustrated example, i11, i12, i13, and i14 are assigned to the respective resources included in content1 as Item_IDs.

  Also, resources included in the same content share the same asset_ID and are transmitted on the same MMT transmission path. In the example shown in FIG. 29C, items with Item_IDs i11, i12, i13, and i14 share a1 as the same Asset_ID and are transmitted on the same MMT transmission path. The data directory management table described above is represented in FIG. 29A, the data content management table is represented in FIG. 29B, and the data asset management table is represented in FIG. It is expressed and these are related by item_ID or node_tag.

  Referring to FIG. 30, a reference relationship between tables transmitted as signaling information when acquiring a data broadcasting application (content) from the MMT transmission path will be described.

  Upon receiving the MH-AI table (MH AIT) 2901 with the M2 section message, the receiver 12 refers to the application_control_code and checks how the state of the application is controlled. Then, when "autostart" is indicated, by referring to transport_protocol_label in the table and confirming that MMT transmission is specified, an item (file data) directly referred to when the application is presented From the transmission protocol descriptor. Then, the receiver refers to the data directory management table (DDMT) 2902 sent by the data transmission message, and acquires the node_tag of the item corresponding to the combination of the base_folder_path_byte, folder_node_path_byte, and file_name_byte. be able to.

  Next, the receiver 12 returns the obtained node_tag to the item_ID on the MMT transmission line with reference to the data asset management table (DAMT) 2903 sent by the data transmission message, and also converts the corresponding asset. Specifically, the asset_ID and download_id are obtained.

  Then, the receiver refers to the MP table (MPT) 2904 sent in the PA message and acquires the packet_id corresponding to the acquired asset_ID, and on the MMT transmission line of the file data, the receiver reads the packet_id in the header of the MMTP packet. Filtering can be performed based on the packet_id, the download_id in the extension header, and the item_ID in the DU header to obtain a desired (directly referred to when the application is presented) item.

  Further, the receiver 12 subtracts the node_tag acquired from the data directory management table 2902 in the data content management table (DCMT) 2905 sent by the data transmission message, and The PU_tag of the presentation unit can be extracted. In addition, by turning the linked_PU loop in the PU_tag PU loop, the PU_tag of another application presentation unit linked to the linked_PU can be extracted collectively.

  FIG. 31 schematically shows a mechanism for caching file data used for data broadcasting in the receiver. The cache here includes caching and pre-caching file data to be executed.

  The application data control unit 407 analyzes the signaling message demultiplexed from the broadcast stream by the demultiplexer 402 and controls the operation in the receiver. Regarding the content pre-cache, the application data control unit 407 pre-caches each file used in the data broadcast linked to the broadcast program based on the compulsory cache information included in the data content management table. I do.

  Specifically, the application data control unit 407 sets cache_node_tag of the node (directory or file data) designated to be pre-cached in the data content management table transmitted in the data transmission message. get. The fact that the corresponding MMTP packet can be specified from the node_tag is as described with reference to FIG.

  The application data control unit 407 obtains the asset_ID of the asset to which the node belongs by subtracting the node_tag of the file data to be pre-cached from the data asset management table transmitted in the data transmission message. , Asset_ID in the MP table transmitted in the PA message to obtain the packet_id of the MMTP packet in which the asset is transmitted. When the system control unit 408 obtains download_id described in the extension header of the MMTP packet transmitting the desired item from the data asset management table, the system control unit 408 sets the header of the MMTP packet on the MMT transmission path of the file data. , The entity of the desired item is obtained by filtering based on the packet_id in the, the download_id in the extension header, and the item_ID in the DU header, and is pre-cached in the cache memory 408.

  When executing the application, the data broadcasting application engine 409 performs demultiplexing from the broadcast stream by the demultiplexer 402 if necessary items (file data) are already cached in the cache memory 408 in advance. Without waiting for the file data to arrive, it can be retrieved from the cache memory 408 and quickly responded to generate a data broadcast display signal. On the other hand, when the required item does not exist in the cache memory 408, the data broadcast application engine 407 waits for the arrival of the demultiplexed file data from the broadcast stream and responds by displaying the data broadcast display signal. Generate

  Next, a control operation of caching file data used in data broadcasting in the receiver 12 will be described in detail.

  It has already been described that there are two types of transmission methods of forced cache information using the data content management table (DCMT), namely, method 1 and method 2. First, a cache control operation using the method 1 will be described.

  In the method 1, the data transmission management message (DCMT) 2700 shown in FIG. 27 is transmitted from the broadcast transmission system 11 in a data transmission message. The data content management table (DCMT) 2700 includes, for each data broadcast presentation unit (PU), a broadcast transmission file (member item) list that constitutes a presentation unit, a primary file (primary item), and a pre-cache file. If the target file exists, the information of the target file list (pre-cache item) is described. Therefore, the receiver 12 can perform a cache control operation using a pre-cache as described below.

(Operation 01) The application data control unit 407 acquires the latest information while appropriately detecting and updating the data transmission message transmitted on the MMT transmission line 504.
(Operation 02) The application / data control unit 407 accesses an application file (which is the center of a data broadcast presentation unit) specified in the primary_item by an instruction from the data broadcast application control engine 409 or the like, and thereby the corresponding data. It recognizes that it has entered the presentation state of the broadcast presentation unit (PU).
(Operation 03) In the data content management table (DCMT) included in the data transmission message, the application data control unit 407 determines each member file (PU_member_node) included in the corresponding data broadcast presentation unit (PU). ) Is also acquired at the same time, and held in the cache memory 408.
(Operation 04) Further, when the target of pre-cache is specified for the corresponding data broadcast presentation unit (PU) in the data content management table, the application data control unit 407 sets Each file (item) to be cached is also acquired and pre-cached in the cache memory 408.
(Operation 05) The data broadcasting application engine 409 executes the application file specified in the primary_item from the cache memory 408.
(Operation 06) After that, by updating the data content management table (DCMT), the configuration of the member file (PU_member_node) included in the data broadcasting presentation unit (PU) in the present presentation state and the file to be pre-cached are changed. In the case of a change, or in the case of transition to a presentation state of another data broadcasting presentation unit (PU) due to an application operation in the data broadcasting application engine 409, in the data broadcasting presentation unit (PU) currently in the presentation state, The processing of (Operation 03) to (Operation 05) is performed. Even if the file is held in the cache memory 408 in the previous state, the application data control unit 407 deletes the unnecessary file from the cache memory 408 in the current state.

  FIG. 32 shows, in the form of a flowchart, a file data cache control procedure based on the method 1 in the receiver 12.

  When the data broadcast application control engine 409 is performing an application operation, that is, presenting a data broadcast (Yes in step S3201), the application data control unit 407 transmits a primary_item (data broadcast presentation unit) in the data content management table. By accessing the application file designated at the center (Yes in step S3202), it is recognized that the presentation state of the corresponding data broadcast presentation unit (PU) has been entered.

  The application data control unit 407 resets the cache memory 408, and in the data content management table (DCMT), the primary_item of the currently presented data broadcast presentation unit (PU) and each member file (PU_member_node). ) Is acquired and stored in the cache memory 408 (step S3203). The data broadcast application engine 409 executes the application file specified in the primary_item from the cache memory 408.

  Further, the application data control unit 407 checks whether or not the target of pre-cache is specified for the corresponding data broadcast presentation unit (PU) in the data content management table (step S3204). If the pre-cache target is specified (Yes in step S3204), the application data control unit 407 also acquires each file (item) to be pre-cached, and stores the pre-cache target file in the cache memory 408. (Step S3205).

  After that, when the data content management table (DCMT) is updated, the structure of the member file (PU_member_node) or the file to be pre-cached included in the data broadcast presentation unit (PU) in the present presentation state changes. (Yes in step S3206), the process returns to step S3203, and the above processing is repeatedly executed in the data broadcast presentation unit (PU) currently in the presentation state.

  When the application operation in the data broadcasting application engine 409 transits to the presentation state of another data broadcasting presentation unit (PU) and accesses the application file specified in the primary_item of the data broadcasting presentation unit (step (Yes in S3207), the process returns to step S3203, and the above processing is repeatedly executed in the data broadcast presentation unit (PU) to which the transition has been made.

  The above process is repeatedly executed until the data broadcasting application engine 409 ends the application operation (No in step S3208).

  FIG. 33 shows an example of a file data pre-caching operation based on the method 1 in the receiver 12.

  The application data control unit 407 analyzes various signaling messages received on the MMT transmission path 504. A data transmission message, which is one of the signaling messages, includes a data content management table (DCMT).

  When the data broadcast application control engine 409 performs an application operation of the data broadcast presentation unit (PU) identified by PU_id = 1, the application data control unit 407 refers to the data content management table, The application file “A01.html” designated as the primary_item (center of the data broadcasting presentation unit) of the data broadcasting presentation unit (PU_id = 1) in the present presentation state, and each member file (PU_member_node) “B01”; "B02" Each node_tag is obtained from the data content management table, and file data corresponding to these node_tags is transmitted from the MMT transmission line 503 for transmitting the data asset. Upon acquiring the entity, as indicated by reference numeral 3301, it is cached in the cache memory 408. The method of accessing the file transmitted on the MMT transmission path 503 from the node_tag is as described above with reference to FIG. 30 (the same applies hereinafter). However, since the pre-cache target is not specified for this data broadcast presentation unit (PU), the pre-cache operation is not performed.

  Next, it is assumed that a transition to a presentation state of another data broadcast presentation unit (PU) identified by PU_id = 3 due to an application operation in the data broadcast application engine 409. Similarly to the above, the application data control unit 407 transmits the application file “A11.html” designated as the primary_item (center of the data broadcast presentation unit) of the data broadcast presentation unit (PU_id = 3) to which the transition has been made, and When the node_tag of each of the member files (PU_member_node) “B11”, “B12”, and “B13” is acquired from the data content management table, the entity of the file data corresponding to these node_tags is transmitted from the MMT transmission path 503. The tee is obtained and cached in cache memory 408, as indicated by reference numeral 3302. However, since the pre-cache target is not specified for this data broadcast presentation unit (PU), the pre-cache operation is not performed.

  The application data control unit 407 constantly analyzes various signaling messages received on the MMT transmission path 504. Then, as indicated by reference numeral 3303, upon detecting that the version of the data content management table has been updated from 1 to 2, the application data control unit 407 causes the data broadcast presentation unit ( It is checked whether the primary_item of PU_id = 3), each member file, and the file to be pre-cached are not changed. This time, since there is no change in the member file, each member file previously cached is kept in the cache memory 408. In addition, since “A12”, “B14”, and “B15” are added as files to be pre-cached in the data broadcast presentation unit (PU_id = 3), the application / data control unit 407 transmits these files from the MMT transmission path 503. The entity of the file data corresponding to the node_tag is obtained and cached in the cache memory 408 as indicated by reference numeral 3304.

  Next, as indicated by reference numeral 3305, upon receiving from the MMT transmission line 504 an event message instructing the update of the presentation of the data broadcast, the data broadcast application engine 409 causes the running HTML file from the A11 file to the A12 file to be HTML. Perform document transition. On the other hand, at almost the same time, the application data control unit 407 refers to the data content management table whose version has been updated from 2 to 3, and refers to the primary_item of the data broadcasting presentation unit (PU_id = 3) in the present presentation state. Changes to "A12.html" and detects that the member file has changed to "B14", "B15", and "B16". As described above, since the primary_item “A12.html” and the member files “B14” and “B15” are already pre-cached in the cache memory 408, the data broadcast application engine 409 stores the primary_item “A12.html” in the cache memory 408. A data broadcast can be quickly displayed using the stored file. That is, it is possible to present a timely data broadcast linked to the broadcast program. In addition, since “B12” is added as a file to be pre-cached in the data broadcast presentation unit (PU_id = 3), the application data control unit 407 transmits the file data corresponding to the node_tag from the MMT transmission path 503. The entity is obtained and cached in cache memory 408, as indicated by reference numeral 3306.

  Subsequently, a cache control operation using the method 2 will be described.

  In the scheme 2, the data transmission management message (DCMT) 2800 shown in FIG. 28 is transmitted as a data transmission message from the broadcast transmission system 11 side. The data content management table (DCMT) 2800 includes, for each data broadcast presentation unit (PU), a broadcast transmission file (member item) list constituting the presentation unit, a primary file (primary item), and a lock to the cache. The information on the target file (lock cache item) to be locked and the target file to be unlocked (unlock cache item) among the lock targets are described. Therefore, the receiver 12 can perform a cache control operation by locking and unlocking the cache as described below.

(Operation 11) The application data control unit 407 acquires the latest information while appropriately detecting and updating the data transmission message transmitted on the MMT transmission line 504.
(Operation 12) The application / data control unit 407 accesses the application file specified in the primary_item (at the center of the data broadcast presentation unit) according to an instruction from the data broadcast application control engine 409 or the like, and thereby the corresponding data. It recognizes that it has entered the presentation state of the broadcast presentation unit (PU).
(Operation 13) In the data content management table (DCMT) included in the data transmission message, the application data control unit 407 determines each member file (PU_member_node) included in the corresponding data broadcast presentation unit (PU). ) Is also acquired at the same time, and held in the cache memory 408.
(Operation 14) Further, when the lock cache target is specified for the corresponding data broadcast presentation unit (PU) in the data content management table, the application data control unit 407 sets the lock Each unacquired file (item) among the cache targets is also acquired, cached in the cache memory 408, and separately managed as a lock cache target file.
(Operation 15) Conversely, if the data cache presentation unit (PU) is specified as an unlock cache target in the data content management table, the application data control unit 407 If the file to be unlocked is cached in the cache memory 408, the file is deleted and also deleted from the file to be locked and managed separately.
(Operation 16) The data broadcasting application engine 409 executes the application file specified in the primary_item from the cache memory 408.
(Operation 17) After that, by updating the data content management table (DCMT), the configuration of the member file (PU_member_node) and the file to be pre-cached included in the data broadcast presentation unit (PU) in the present presentation state are changed. If it has changed, the above-mentioned processes (operation 13) to (operation 16) are performed.
(Operation 18) When a transition to a presentation state of another data broadcasting presentation unit (PU) is made by an application operation in the data broadcasting application engine 409, the file to be locked is temporarily stored in the cache memory 408, and then The processing of (operation 13) to (operation 16) is performed. Files other than those to be locked may be deleted from the cache memory 408.

  FIG. 34 shows, in the form of a flowchart, a file data cache control procedure based on the scheme 2 in the receiver 12.

  When the data broadcast application control engine 409 is performing an application operation, that is, presenting a data broadcast (Yes in step S3401), the application data control unit 407 transmits a primary_item (data broadcast presentation unit) in the data content management table. By accessing the application file designated at the center (Yes in step S3402), it is recognized that the presentation state of the corresponding data broadcast presentation unit (PU) has been entered.

  The application data control unit 407 resets the cache memory 408, and in the data content management table (DCMT), the primary_item of the currently presented data broadcast presentation unit (PU) and each member file (PU_member_node). ) Is acquired and stored in the cache memory 408 (step S3403). The data broadcast application engine 409 executes the application file specified in the primary_item from the cache memory 408.

  Further, the application data control unit 407 checks whether or not a lock cache target is specified for the corresponding data broadcast presentation unit (PU) in the data content management table (step S3404). If the lock cache target is specified (Yes in step S3404), the application data control unit 407 also obtains each file (item) that has not been obtained from the lock cache target, and stores the cache memory in the cache memory. 408, and separately managed as a lock cache target file (step S3405).

  Also, the application data control unit 407 checks whether or not the target of the unlock cache is specified for the corresponding data broadcast presentation unit (PU) in the data content management table (step S3406). . If the target of the unlock cache is specified (Yes in step S3406), the application data control unit 407 deletes the unlock target file if the file is cached in the cache memory 408. At the same time, the file is also deleted from the lock cache target file managed separately (step S3407).

  After that, when the data content management table (DCMT) is updated, the structure of the member file (PU_member_node) or the file to be pre-cached included in the data broadcast presentation unit (PU) in the present presentation state changes. (Yes in step S3408), the process returns to step S3403, and the above processing is repeatedly executed in the data broadcast presentation unit (PU) currently in the presentation state.

  When the application operation in the data broadcasting application engine 409 transits to the presentation state of another data broadcasting presentation unit (PU) and accesses the application file specified in the primary_item of the data broadcasting presentation unit (step (Yes in S3409), the process returns to step S3403, and the above processing is repeatedly executed in the data broadcast presentation unit (PU) to which the transition has been made.

  The above processing is repeatedly executed until the data broadcasting application engine 409 ends the application operation (No in step S3410).

  FIG. 35 shows an example of file data cache locking and unlocking operations based on the scheme 2 in the receiver 12.

  The application data control unit 407 analyzes various signaling messages received on the MMT transmission path 504. A data transmission message, which is one of the signaling messages, includes a data content management table (DCMT).

  When the data broadcast application control engine 409 performs an application operation of the data broadcast presentation unit (PU) identified by PU_id = 1, the application data control unit 407 refers to the data content management table, The application file “A01.html” designated as the primary_item (center of the data broadcasting presentation unit) of the data broadcasting presentation unit (PU_id = 1) in the present presentation state, and each member file (PU_member_node) “B01”; "B02" Each node_tag is obtained from the data content management table, and file data corresponding to these node_tags is transmitted from the MMT transmission line 503 for transmitting the data asset. Upon acquiring the entity, as indicated by reference numeral 3501, it is cached in the cache memory 408. The method of accessing the file transmitted on the MMT transmission path 503 from the node_tag is as described above with reference to FIG. 30 (the same applies hereinafter). However, since no lock cache target is specified for this data broadcast presentation unit (PU), no cache operation is performed.

  Next, it is assumed that a transition to a presentation state of another data broadcast presentation unit (PU) identified by PU_id = 3 due to an application operation in the data broadcast application engine 409. Similarly to the above, the application data control unit 407 transmits the application file “A11.html” specified in the primary_item (center of the data broadcast presentation unit) of the data broadcast presentation unit (PU_id = 3) to which the transition has been made, and When the node_tag of each of the member files (PU_member_node) “B11”, “B12”, and “B13” is acquired from the data content management table, the entity of the file data corresponding to these node_tags is transmitted from the MMT transmission path 503. The tee is obtained and cached in cache memory 408, as indicated by reference numeral 3502. However, since the lock cache target is not specified for this data broadcast presentation unit (PU), the lock cache operation is not performed.

  The application data control unit 407 constantly analyzes various signaling messages received on the MMT transmission path 504. When detecting that the version of the data content management table has been updated from 1 to 2 as indicated by reference numeral 3503, the application data control unit 407 causes the data broadcast presentation unit ( It is checked whether or not the primary_item of PU_id = 3), each member file, and the file to be locked are changed. This time, since there is no change in the member file, each member file previously cached is kept in the cache memory 408. In addition, since “A12”, “B14”, “B12”, and “B15” are added as lock cache files of the data broadcast presentation unit (PU_id = 3), the application / data control unit 407 performs MMT transmission. The entity of the file data corresponding to these node_tags is obtained from the path 503 and cached in the cache memory 408 as indicated by reference numeral 3504, and separately managed as a lock cache target file. In the figure, files managed as lock cache targets are underlined (the same applies hereinafter).

  Next, as indicated by reference numeral 3505, upon receiving from the MMT transmission line 504 an event message instructing the update of the presentation of the data broadcast, the data broadcast application engine 409 converts the currently running HTML file from the A11 file to the A12 file. Perform document transition. On the other hand, at almost the same time, the application data control unit 407 refers to the data content management table whose version has been updated from 2 to 3, and refers to the primary_item of the data broadcasting presentation unit (PU_id = 3) in the present presentation state. Changes to "A12.html" and detects that the member file has changed to "B14", "B15", and "B16". As described above, since the primary_item “A12.html” and the member files “B14” and “B15” are already locked and cached in the cache memory 408, the data broadcast application engine 409 stores the primary_item “A12.html” in the cache memory 408. The data broadcast can be quickly displayed by using the stored files. That is, it is possible to present a timely data broadcast linked to the broadcast program. Further, since no lock cache target is specified for this data broadcast presentation unit (PU), the lock cache operation is not performed. As indicated by reference numeral 3506, the files “A12”, “B14”, “B12”, and “B15” that have been locked and cached are retained in the cache memory 408 as they are, while the unnecessary files “A11” are deleted. Have been.

  Further, upon receiving an event message instructing the update of the presentation of the data broadcast from the MMT transmission path 504, the application data control unit 407 refers to the data content management table and refers to the data broadcast currently in the presentation state. For the presentation unit (PU_id = 3), “B17” is added as a lock cache target file, and “B14” is added as an unlock target file. Therefore, as indicated by reference numeral 3507, the application data control unit 407 acquires the entity of the file data corresponding to the node_tag of the file “B17” from the MMT transmission path 503 and locks and caches it in the cache memory 408. At the same time, the file “B12” that has been locked in the cache is deleted from the cache memory 408 and removed from the lock target.

  In a data broadcasting service based on BML (Broadcast Markup Language) currently in operation, a specific file is pre-cached in a cache memory by calling an API (Application Programming Interface) called “LockModuleOnMemory ()” from a script in advance. (For example, see Patent Document 2). In this method, it is necessary to incorporate a special specification for broadcasting operation into the specification of an application such as a script.

  On the other hand, according to the technology disclosed in this specification, from the transmitting side such as a broadcasting station, the signaling related to the data broadcasting is transmitted including the information specifying the compulsory cache, and the receiving side receives the information. The cache control of each data broadcast file is performed based on the compulsory cache information included in the signaling related to the data broadcast. Therefore, according to the technology disclosed in the present specification, in data broadcasting using the new HTML5, a highly versatile format is maintained without incorporating special specifications that presuppose broadcasting operation into application specifications such as scripts. be able to.

  The technology disclosed in this specification has been described in detail with reference to the specific embodiments. However, it is obvious that those skilled in the art can modify or substitute the embodiment without departing from the gist of the technology disclosed in this specification.

  The technology disclosed in this specification can be applied to various broadcasting systems that employ MMT as a transport method. Further, the technology disclosed in the present specification can be applied to various data broadcasting systems that transmit file data used for data broadcasting linked to a broadcast program by the MMT system or another transport system.

  In short, the technology disclosed in this specification has been described by way of example, and the contents described in this specification should not be interpreted restrictively. In order to determine the gist of the technology disclosed in this specification, the claims should be considered.

The technology disclosed in the present specification may have the following configurations.
(1) a file data transmission unit for transmitting file data used in data broadcasting;
A signaling message transmitting unit for transmitting including signaling for data broadcasting including forced cache information for specifying a forced cache of file data,
A transmission device comprising:
(2) The signaling message transmitting unit, for each data broadcast presentation unit, includes a broadcast transmission file list constituting the presentation unit, a main file, and data describing information of a pre-cache target file list. Send a data transmission message containing a content management table,
The transmission device according to (1).
(3) The signaling message transmitting unit, for each data broadcast presentation unit, a broadcast transmission file list constituting the presentation unit, a central file, a target file to be locked in the cache, and a target file to be unlocked among the lock targets. Send a data transmission message containing a data content management table describing the information of
The transmission device according to (1).
(4) further comprising a media data transmission unit for transmitting media data of a broadcast program main body linked with the data broadcast;
The transmission device according to any one of (1) to (3).
(5) a file data transmission step of transmitting file data used in data broadcasting;
A signaling message transmitting step of transmitting the signaling relating to the data broadcasting including the compulsory cache information for specifying the compulsory cache of the file data,
A transmission method having:
(6) a file data receiving unit for transmitting file data used in data broadcasting;
A signaling message receiving unit that transmits the signaling related to the data broadcasting including the compulsory cache information for specifying the compulsory cache of the file data, and
A control unit that controls a cache in a cache memory of file data received by the file data receiving unit based on the forced cache information,
A receiving device comprising:
(7) The signaling message receiving unit, for each data broadcasting presentation unit, includes a data transmission list that describes a broadcast transmission file list and a main file constituting the presentation unit, and information of a file list to be pre-cached. Receiving a data transmission message containing a content management table;
The receiving device according to (6).
(8) when the file data receives a file included in the pre-cache target file list, the control unit pre-caches the file in the cache memory;
The receiving device according to the above (7).
(9) The signaling message receiving unit, for each data broadcast presentation unit, a broadcast transmission file list constituting the presentation unit, a central file, a file to be locked in a cache, and a file to be unlocked among lock objects. Receiving a data transmission message containing a data content management table describing the information of
The receiving device according to (6).
(10) when the file data receives the file to be locked, the control unit pre-caches the file in the cache memory;
The receiving device according to (9).
(11) The control unit deletes the unlock target file from the cache memory.
The receiving device according to (9).
(12) when the file data receives a broadcast transmission file list and a central file constituting a current data broadcast presentation unit, the control unit caches the cache data in the cache memory;
The receiving device according to any one of (6) and (9).
(13) further comprising a data broadcast presentation unit for presenting a data broadcast using file data;
The receiving device according to any one of (6) to (12).
(14) a media data receiving unit that receives media data of a broadcast program main body linked with the data broadcast; and a broadcast program presenting unit that presents a broadcast program based on the media data.
The receiving device according to any one of (6) to (13).
(15) a file data receiving step of transmitting file data used in data broadcasting;
A signaling message receiving step of transmitting the signaling relating to the data broadcasting including the compulsory cache information designating the compulsory cache of the file data,
A control step of controlling the cache of the file data received by the file data receiving unit in the cache memory based on the forced cache information,
Receiving method comprising:

DESCRIPTION OF SYMBOLS 10 ... Digital broadcasting system 11 ... Broadcasting transmission system, 12 ... Receiver 301 ... Clock part, 302 ... Signal transmission part, 303 ... Video encoder 304 ... Audio encoder, 305 ... Caption encoder 306 ... Signaling encoder, 307 ... File encoder 308 Information system 309 TLV signaling encoder 310 IP service multiplexer 311 TLV multiplexer 312 Modulation / transmission unit 401 Tuner / demodulation unit 402 Demultiplexer 403 Clock unit 404 video decoder 405 audio decoder 406 caption decoder 407 application data control unit 408 cache memory 409 data release Application engine 410 ... system control unit, 411 ... synthesis unit 412 ... IP interface

Claims (5)

Comprising a file constituting an application, a transmission unit for transmitting a signaling message related to the transmission of the application,
The signaling message includes: a first table describing location information of a directory of a file constituting the application and a node tag identifying the directory; and item identification information identifying an item associated with the node tag. Including a second table to list,
The transmission unit further transmits information specifying a file to be locked to a cache,
Transmission device. The transmitting unit further transmits information specifying the file to be unlocked from the cache,
The transmission device according to claim 1. A transmission unit included in the transmission device has a transmission step of transmitting a file constituting an application and a signaling message related to transmission of the application,
The signaling message includes: a first table describing location information of a directory of a file constituting the application and a node tag identifying the directory; and item identification information identifying an item associated with the node tag. Including a second table to list,
The transmission unit further transmits information specifying a file to be locked to a cache,
Transmission method. A file comprising an application, comprising a control unit for acquiring a signaling message related to the transmission of the application,
The control unit further obtains information that specifies a file to be locked to a cache, and information that specifies a file to be locked to the cache, and a directory of a file constituting the application, which is included in the signaling message. Configuring the application based on a first table listing location information and a node tag identifying the directory, and a second table listing item identification information identifying an item associated with the node tag. Control the caching of files that
Receiver. The control unit included in the receiving device, a file constituting an application, having an acquisition step of acquiring a signaling message related to the transmission of the application,
In the obtaining step, information for specifying a file to be locked to the cache is further obtained,
A first table describing information specifying a file to be locked to the cache, directory information of a directory of a file constituting the application included in the signaling message, and a node tag for identifying the directory; Controlling a cache of files constituting the application based on a second table describing item identification information identifying an item associated with the node tag.
Receiving method.