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

Description

The techniques disclosed in the present specification include a transmission device and a transmission method for transmitting a file for data broadcasting by a predetermined transport method, and a receiving device for receiving a file for data broadcasting transmitted by a predetermined transport method. And the receiving method.

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

According to the MMT method, it is possible to transmit both timed media (Timed media) such as video and audio, which are stream media, and non-timed media (Non timed media) such as files on MMT packets. Is. The timed media referred to here is stream data of the main part of a broadcast program such as video, audio, and subtitles. The non-timed media is file data of a data broadcasting application (content) such as an HTML (HyperText Markup Language) document.

Data broadcasting linked to broadcast programs 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 broadcasting transmission band. The receiving terminal can realize timely presentation of data broadcasting by caching the file for data broadcasting. However, in a receiving terminal that is not equipped with abundant cache memory, if a necessary file is cache-missed, it is necessary to wait until the next repetition cycle, which causes a delay of, for example, several tens of seconds until the data broadcast is presented. It ends up.

In the data broadcasting service by BML (Broadcast Markup Language) operated at the time of the present application, a specific file is pre-cached in the cache memory by calling an API (Application Programming Interface) called "LockModuleOnMemory ()" from a script. It can be retained (see, eg, Patent Document 2).

Japanese Unexamined Patent Publication No. 2013-153291 JP-A-2007-274193

ISO / IEC FDIS 2300-1: 2013 (E) Information technology-High efficiency coding and media delivery in heterogeneous programming (Part1: MPEG Medit)

An object of the technique disclosed in the present specification is to provide a transmission device and a transmission method capable of suitably transmitting a file for data broadcasting by a predetermined transport method.

A further object of the technique disclosed herein is to provide a receiving device and receiving method capable of suitably receiving a file for data broadcasting transmitted by a predetermined transport method.

The present application has been made in consideration of the above-mentioned problems, and the technique according to claim 1 is a technique.
A file data transmitter that transmits file data used in data broadcasting,
A signaling message transmitter that sends including forced cache information that specifies a forced cache for file data for signaling related to data broadcasting,
It is a transmission device provided with.

According to the technique according to claim 2 of the present application, the signaling message transmission unit of the transmission device according to claim 1 includes a broadcast transmission file list and a center constituting the presentation unit for each data broadcasting presentation unit. It is configured to send a data transmission message containing the file and the data content management table that describes the information in the precache target file list.

According to the technique according to claim 3 of the present application, the signaling message transmission unit of the transmission device according to claim 1 includes a broadcast transmission file list and a center constituting the presentation unit for each data broadcasting presentation unit. It is configured to send a data transmission message containing a data content management table that describes information about the file, the target file to be locked in the cache, and the target file to be unlocked.

According to the technique according to 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 for transmitting media data of a broadcast program main body linked with data broadcasting. I have.

Further, the technique according to claim 5 of the present application is:
File data transmission step to transmit file data used in data broadcasting,
A signaling message transmission step that includes forced cache information that specifies a forced cache of file data for signaling related to data broadcasting, and a signaling message transmission step.
It is a transmission method having.

In addition, the technique according to claim 6 of the present application
A file / data receiver that transmits file data used in data broadcasting,
A signaling message receiver that sends including forced cache information that specifies a forced cache of file data for signaling related to data broadcasting,
A control unit that controls caching of file data received by the file data receiving unit in a cache memory based on the forced cache information.
It is a receiving device provided with.

According to the technique according to claim 7 of the present application, the signaling message receiving unit of the receiving device according to claim 6 includes a broadcast transmission file list and a center constituting the presentation unit for each data broadcasting presentation unit. It is configured to receive a data transmission message containing a data content management table that describes the file and the information in the precache target file list.

According to the technique according to claim 8 of the present application, when the control unit of the receiving device according to claim 7 receives the file included in the target file list of the precache, the file data receives the file. It is configured to precache in the cache memory.

According to the technique according to claim 9 of the present application, the signaling message receiving unit of the receiving device according to claim 6 includes a broadcast transmission file list and a center constituting the presentation unit for each data broadcasting presentation unit. It is configured to receive a data transmission message containing a data content management table that describes information about the file, the target file to be locked in the cache, and the target file to be unlocked.

According to the technique according to 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 precaches it in the cache memory. It is configured in.

According to the technique according to 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 technique according to claim 12 of the present application, the control unit of the receiving device according to any one of claims 6 or 9 is centered on a broadcast transmission file list constituting the current data broadcasting presentation unit. When the file data receives the file, it is configured to be cached in the cache memory.

According to the technique according to claim 13 of the present application, the receiving device according to any one of claims 6 to 12 further includes a data broadcasting presenting unit that presents data broadcasting using file data.

According to the technique according to 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 linked with data broadcasting. It also has a broadcast program presentation unit that presents broadcast programs based on media data.

In addition, the technique according to claim 15 of the present application
File data reception step to send file data used in data broadcasting,
A signaling message reception step to send including forced cache information that specifies a forced cache of file data for signaling related to data broadcasting, and
A control step that controls caching of file data received by the file data receiver in a cache memory based on the forced cache information, and
It is a receiving method having.

The technique disclosed in the present specification assumes that, for example, a file of data broadcasting by HTML (HyperText Markup Language) 5 is transmitted by the MMT method. According to the technique disclosed in the present specification, a transmitting device such as a broadcasting station can transmit information related to data broadcasting including information specifying a forced cache. Further, according to the technique disclosed in the present specification, a receiving device such as an STB (SetTopBox) or a television receiving terminal installed in a home is based on forced cache information included in signaling related to received data broadcasting. Therefore, the cache control of each file for data broadcasting can be preferably performed, and the data broadcasting linked to the broadcast program can be presented in a timely manner.

The effects described in the present specification are merely examples, and the effects of the present invention are not limited thereto. In addition, the present invention may exert additional effects in addition to the above effects.

Still other objectives, features and advantages of the techniques disclosed herein will become apparent by more detailed description based on embodiments and accompanying drawings described below.

FIG. 1 is a diagram schematically showing a configuration example of a digital broadcasting system 10 to which the technique disclosed in the present specification is applied. FIG. 2 is a diagram showing a stack model 200 of broadcast signals to which MMT is applied. FIG. 3 is a diagram showing a configuration example of a broadcast transmission system 11 that transmits the broadcast signal shown in FIG. FIG. 4 is a diagram showing a configuration example of the receiver 12 that receives the broadcast signal shown 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 showing a configuration example of a header of an MMT packet. FIG. 7 is a diagram showing a configuration example of the extension header 700 in the case of an MMTP packet for transmitting non-timed media. FIG. 8 is a diagram showing a configuration example of the MMTP payload 800 in the MPU mode. FIG. 9 is a diagram showing a configuration example of DU_Header900 of MFU in which timed media is arranged on the payload. FIG. 10 is a diagram showing a configuration example of DU_Header1000 of MFU in which non-timed media is arranged on the payload. FIG. 11 is a diagram showing an example of a packet configuration when transmitting non-timed media data. FIG. 12 is a diagram showing a configuration example of the PA message 1201 and the MP table 1202 included in the PA message. FIG. 13 is a diagram showing a syntax example of PA message 1300. FIG. 14 is a diagram showing a description of parameters included in the PA message. FIG. 15 is a diagram showing a syntax example (first half portion) of the MP table (MPT). FIG. 16 is a diagram showing 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 the MH AI (Application Information) table (MH AIT) 1900 transmitted by the M2 section message. FIG. 20 is a diagram showing a configuration example of the application information descriptor 2000. FIG. 21 is a diagram showing a description of parameters included in the application information descriptor. FIG. 22 is a diagram showing 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, which 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 transmitting, locating, and presenting a data broadcasting application (content) transmitted by MMT. FIG. 30 is a diagram for explaining a reference relationship of each table transmitted as signaling information when acquiring a data broadcasting application (content) from an MMT transmission line. 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 based on the method 1 in the receiver 12. FIG. 33 is a diagram showing an example of 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 based on the method 2 in the receiver 12. FIG. 35 is a diagram showing an example of locking and unlocking the cache of file data based on the method 2 in the receiver 12.

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

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

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

On the other hand, the receiver 12 receives the broadcast signal sent 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. Further, when the receiver 12 acquires each file data for data broadcasting from the received broadcast signal, it activates an application engine such as an HTML browser to present data broadcasting linked to the broadcast program.

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

At the bottom of the stack model 200 is a physical layer (PHY) 201. 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. Further, the IP packet 203 is placed on the TLV 202, and the UDP (User Datagram Protocol) 204 is placed on the IP packet 203. Further, on the transmission packet 202 of the TLV, a header compression IP205 obtained by compressing the headers of the IP203 and the UDP204, and a transmission control signal 206 as signaling information are also mounted.

On the UDP 204, an MMT packet 207, an NTP (Network Time Protocol) packet 208 containing information on the current time, 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), which 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 that transmits 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, and information. It includes a system 308, a TLV signaling encoder 309, an IP service multiplexer (MUX) 310, a TLV multiplexer (MUX) 311 and a modulator / transmitter 312.

The clock unit 301 generates time information synchronized with the time information acquired 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 / playback device for a TV broadcasting station studio or VTR, and is a timed media such as video, audio, subtitles, or other stream data, or a non-timed media for data broadcasting. File data such as data is sent to the video encoder 303, the audio encoder 304, the caption encoder 305, and the file encoder 307, respectively. Further, the information system 308 sends the HTML document data and the signaling information, which are the scheduler and the file supply source of the TV broadcasting station and are non-timed media, to the file encoder 307 and the signaling encoder 306, respectively.

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

The signaling encoder 306 generates a signaling message related to data broadcasting based on the information transmitted from the information system 308, and IP packet including the MMT packet in which the signaling message is arranged in the payload section is an IP service multiplier. Send to the packet 310. In the present embodiment, signaling messages related to data broadcasting are roughly classified into three types: PA message, M2 section message, and data transmission message. In this embodiment, information that specifies a forced cache for each file used in data broadcasting is included in the data transmission message. Details of each signaling message will be given 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 containing the file data, and generates an MMT packet containing the MMT packet, and generates an IP packet containing the MMT packet. Send to IP service multiplexer 310. The file data constitutes a data broadcasting content (data broadcasting application).

The broadcast transmission system 11 is equipped with an IP service multiplexer 310 for each channel (broadcast program) to be transmitted. The one-channel IP service multiplexer 310 multiplexes an IP packet containing each of video, audio, subtitles, signaling messages, and file data sent from each encoder 303-307 into one. Generates TLV packets that make up the channel.

The TLV signaling encoder 309 encodes the signaling information transmitted from the information system 308 to generate a TLV packet to be placed in the payload section.

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

The modulation / transmission unit 312 performs RF modulation processing on the broadcast stream generated by the TLV multiplexer 311 and sends it to the RF transmission line.

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

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

The video signal transmitted from the signal transmission unit 302 is supplied to the video encoder 303. In the video encoder 303, the video signal is encoded and further packetized to generate an IP packet containing 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 MMT packet of the audio generated by the audio encoder 304 is sent to the IP service multiplexer 310, and the IP packet including the MMT packet of the subtitle generated by the caption encoder 305 is the IP service. -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 the payload section. To. This IP packet is sent to the IP service multiplexer 310.

Further, 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 containing 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 containing each of video, audio, subtitles, signaling messages, and file data sent from each encoder 303 to 307 are multiplexed to form one channel. A TLV packet is generated.

In the TLV signaling encoder 309, the signaling information transmitted from the information system 308 is encoded to generate a TLV packet to be placed in the payload section.

In the TLV multiplexer 311, the TLV packets generated by each IP service multiplexer 310-13 to 10-N and the TLV signaling encoder 309 are multiplexed to generate a broadcast stream. The modulation / transmission unit 312 performs RF modulation processing on the broadcast stream generated by the TLV multiplexer 311 and sends the RF modulation signal to the RF transmission line.

Further, FIG. 4 shows a configuration example of the receiver 12 that receives the broadcast signal shown in FIG. The receiver 12 shown is 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. It includes a unit 407, a cache memory 408, a data broadcasting application engine 409, a system control unit 410, a synthesis unit 411, and an IP interface 412.

The tuner / demodulation unit 401 receives the RF modulation signal, performs demodulation processing, and obtains a broadcast stream. The demultiplexer 402 performs demultiplexing processing and packetizing processing on this broadcast stream to perform NTP time information, PTS (Presentation Time Stamp: presentation time information), signaling information, and a video related to the main part of the broadcast program. , Audio, each coded signal of caption, file data used for data broadcasting linked to a broadcast program, and signaling information are output. The file data used for data broadcasting is, for example, a data broadcasting application described in HTML5 format.

The video decoder 404 decodes the encoded video signal obtained by the demultiplexer 402 to obtain a baseband video signal. Further, the audio decoder 405 decodes the encoded audio signal obtained by the demultiplexer 402 to obtain a baseband audio signal. Further, the caption decoder 406 decodes the encoded subtitle signal obtained by the demultiplexer 402 to obtain the 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 data broadcasting is transmitted from two systems of a broadcasting signal and an IP network, the former is via the tuner / demodulation unit 401 and the demultiplexer 402, and the latter is. Each is acquired by the application data control unit 407 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, and processes the corresponding file data (data broadcasting application such as HTML5) with an HTML browser. Instruct the data broadcasting application engine 409 such as. The data broadcasting application engine 409 processes the data broadcasting application by using the file data pre-cached or pre-cached in the cache memory 408 as appropriate.

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, identifies the access range required to present the data broadcast, and determines the data. It controls the filtering operation for caching the cacheable file data in the cache application engine 407 in the cache memory 408 in advance. Details of pre-cache of file data will be described later.

In addition, information that specifies the forced cache of each file used in data broadcasting is included in the data transmission message. In the present embodiment, the application data control unit 407 caches the file data necessary for presenting the data broadcast in a timely manner based on the forced cache information included in the data transmission message. Pre-cache to 408. Details of file data pre-cache will be given later.

In the broadcast stream, files and data of the same content are repeatedly sent. The system control unit 410 controls the filtering operation in the demultiplexer 402, and the application data control unit 407 acquires only those necessary for the demultiplexer 402 from the repeatedly sent file data group. To do so.

The system control unit 410 controls the operation of each unit of the receiver 12 based on the signaling information obtained by the demultiplexer 402, the operation information from the user via the user operation unit (not shown), and the like. The clock unit 403 generates time information synchronized with this 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 the video, audio, and subtitles. The compositing unit 411 synthesizes the subtitle display signal and the data broadcasting display signal with the baseband video signal to obtain a video signal for video display. Further, the baseband audio signal obtained by the audio decoder 405 becomes an audio signal for audio output. The main part of the broadcast program composed of video signals and audio signals is output as video and audio from a monitor display (not shown). In addition, the data broadcasting processed by the data broadcasting application engine 409 is also displayed superimposed on the screen of the main part of the broadcast program on the monitor display.

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

The tuner / demodulation unit 401 receives the RF modulation signal, performs demodulation processing, and obtains a broadcast stream. In the demultiplexer 402, the broadcast stream is subjected to demultiplexing processing and packetizing processing, and NTP time information, PTS, signaling information, video, audio, caption encoded signals, and a 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 this 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 the video decoder 404 for decoding to obtain a baseband video signal. Further, the encoded subtitle signal extracted by the demultiplexer 402 is sent to the caption decoder 406 for decoding, and a subtitle display signal is obtained. Further, the file data extracted by the demultiplexer 402 is sent to the data broadcasting application engine 407 for processing, and a data broadcasting display signal is obtained. The system control unit 410 controls the filtering operation of the demultiplexer 402 so that only the necessary file data is acquired by the demultiplexer 402.

Then, in the synthesis unit 411, the display signal of the subtitle and the display signal of the data broadcasting are combined with the video signal of the baseband, and the video signal for video display is obtained.

Further, the encoded audio signal extracted by the demultiplexer 402 is sent to the audio decoder 405 for decoding, and a baseband audio signal for audio output is obtained. The main part of the broadcast program composed of video signals and audio signals 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 broadcasting presentation unit is currently used, and processes the corresponding file data (data broadcasting application such as HTML5) to the data broadcasting application engine 409 such as an HTML browser. Instruct. The data broadcasting application engine 409 processes the data broadcasting application by using the 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 superimposed on the screen of the main broadcast program on the monitor display.

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 refers to the file data according to the free space of the cache memory 408. It controls the advance cache and the forced cache for presenting data broadcasting in a timely manner in conjunction with the broadcast program (described later).

In the digital broadcasting system 10 shown in FIG. 1, it is assumed that MMT is applied as a transport method when a broadcasting signal is transmitted from the broadcasting 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) are timed media related to the main part of the 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 related to transmission control of these broadcast signals is transmitted as signaling information. In MMT, it is easy to use the data of the timed media and the non-timed media constituting one channel (broadcast program) in a combination of different transmission lines. In the example shown in FIG. 5, MMT transmission lines 501 to 504 for each type of data such as video, audio, subtitles, file data, and signaling information are used as the broadcast signal 500. In the figure, the transmission line for subtitle data is omitted for convenience.

One channel (broadcast program) can be said to be a "package" composed of multiple assets of different types such as video, audio, subtitles, and file data (data application) (the package uses the MMT transmission line). A logical set of media data to be transmitted). Each asset is a set (logical group) of one or more MPUs sharing the same attach_id (asset identifier), and is transmitted on a dedicated ES (Elementary Stream), that is, an MMT transmission path (the asset is unique). An entity of data associated with an identifier and used to compose a multimedia presentation). That is, the transmission line 501 transmits a video MMT packet (MMTP) consisting of an MPU logical group having a common attach_id, and the transmission line 502 transmits an audio MMT packet consisting of an MPU logical group having a common attach_id. On the transmission line 503, an MMT packet of file data composed of an MPU logical group having a common attach_id is transmitted. The MPU is specified by asset_id and the sequence number of the MPU on the corresponding transmission line. Further, the MMT transmission line that transmits 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, two or more file contents (data broadcasting applications) are provided for the same broadcast program. In such a case, different asset_ids are assigned to different file contents, and they are transmitted as separate MPU logical groups on different MMT transmission lines. In FIG. 5, for simplification, only one transmission line 503 for file data is drawn.

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

Further, on the transmission line 504, an MMT packet containing the same signaling message is repeatedly transmitted. In implementing the techniques disclosed herein, the signaling messages transmitted are associated with three types of signaling messages: PA message 510, M2 section message 520, and data transmission message 530. The signaling table is transmitted in various signaling messages. For example, the PA message 510 includes an MP (MMT Package) table 511. In addition, the MH AI (Application Information) table 521 is included in the M2 section message 520. The data transmission message 530 is a message for notifying a data transmission method and a data management control method, and is a data directory management table 531, a data asset management table 532, and a data content. Each signaling table of management table 533 is included. Details of each table will be given later.

As described above, MMTP transmits timed media such as video, audio, and subtitles, and non-timed media such as file data. 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, for example, Non-Patent Document 1.

When 1 is assigned to the packet counter flag "C" indicated by the reference number 601, it means that the field of the packet counter indicated by the reference number 602 exists in this MMTP packet. The packet counter 602 is a 32-bit length field for writing an integer value that counts MMTP packets, and is incremented by 1 each time an MMTP packet is transmitted.

When 1 is assigned to the extension flag "X" indicated by the reference number 603, it means that the extension header 604 indicated by the reference number 604 exists. Below FIG. 6, a configuration example of the extension header 604 is also shown. The extension header 604 is composed of a type field having a length of 16 bits indicated by the reference number 604-1, a length field indicated by the reference number 604-2, and a header_extensin_value field indicated by the reference number 604-2. The byte length of the header_extensin_value field is written in the lens field. Extended information that deviates from the MMT specifications can be written in the header_extensin_value field.

A type value representing the type of payload data of the MMTP packet is written in the type field indicated by the reference number 606. The definition of the type value is shown in Table 1 below.

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

An integer value for distinguishing the assets is written in the packet_id field having a length of 16 bits indicated by the reference number 607. The value of this field is derived from the asset_id of the asset to which the MMTP packet belongs. The mapping between packet_id and asset_id is shown in the MMT Package (MP) table, which is part of the signaling message.

In the 32-bit length timestamp field shown by reference number 608, the transmission time of the MMTP packet is described by the short-form specified by the NTP protocol.

In the packet_sequence_number field of 32-bit length indicated by the reference number 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 for transmitting non-timed media. As shown in the figure, in this case, 4 is written in the lens field 701 as the byte length of the header_extensin_value field. In the header_extensin_value field 702, the download_id is described in 4 bytes.

When transmitting an MPU using the MMT protocol, packetization and depacketization are required on the transmitting side and the receiving side, respectively. By packetization, the MPU is inserted into the MMTP payload and transmitted as an MMTP packet. The format of the MMTP payload allows fragmentation of the MMTP payload so that large payloads can be transmitted. The MTP payload format also allows aggregation to insert multiple MMTP payloads into a single MMTP payload, corresponding to small data units. On the receiving side, depacketize and restore the original MPU data.

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

The MPU Fragment Type (FT) field, referred to by reference number 801 shows the fragment type as 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 the reference number 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 entered. Indicates that is fragmented.

The Fragmentation Identifier (f_i) field, referred to by reference number 803, represents information about the fragmentation of data units in the payload in two bits. The definitions of the four values of f_i are shown in Table 3 below.

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

The 8-bit length fragment_counter field, referred to by reference number 805, describes the number of payloads containing fragments of the same data unit followed by the MMTP payload.

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

DU_Header, referred to by reference number 807, is the header of the data unit. However, when the FT value 801 is 0 or 1 (in other words, when it is not MFU), there is no DU_Header807. MFUs include timed media samples or subsamples, or non-timed media items.

FIG. 9 shows a configuration example of the DU_Header 900 of the MFU in which the timed media is arranged on the payload. Further, FIG. 10 shows a configuration example of DU_Header1000 of MFU in which non-timed media is arranged on the payload. As shown in FIG. 10, the DU_Header1000 in the case of non-timed media is composed of a 32-bit length item_ID which 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 an HTML document. On the MMT transmission path specified by asset_id, the item can be uniquely identified by the combination of the packet_id in the header of the MMTP packet and 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 contains one or more items. The HTML document itself is also an item.

FIG. 11B shows how the file data F1 and F2 are arranged in the MFU. Since the file data F1 is not large in 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 files, 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 placed in a different MFU payload.

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 monomedia are placed in the payload.

Then, as shown in FIG. 11 (c), each MFU is attached with a header of the MMT payload (see FIG. 8) to become the MMT payload. Here, a value of 2 is entered in the Fragment Type (FT) field of the header of the MMT payload to indicate that the fragment type is MFU. Further, a value 0 is described in the Timed (T) flag to indicate that the MPU transmits non-timed media. Further, in the MFU in which the non-fragmented non-timed media 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 the Fragmentation Identifier (f_i) field, and a count value corresponding to the fragment_counter field is described.

Then, as shown in FIG. 11 (d), each MMT payload is attached with an MMTP packet header and an extension header (see FIG. 6) to form an MMT packet stream. Here, 0 is described in the type field of the MMTP header to indicate that the payload data type is MPU, and an integer value for distinguishing the assets is written in the packet_id field. In addition, download_id is described in the extension header. Therefore, on the MMT transmission path specified by asset_id, the item can be uniquely identified by the combination of the packet_id in the header of the MMTP packet and the download_id in the extension header and the item_ID in the DU header.

Further, as shown in FIG. 11 (e), 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 also includes an MMT packet including a signaling message in the payload. Signaling messages include PA messages, M2 section messages, and data transmission messages (see above as well as FIG. 5). Whether the MMTP payload contains transmission media such as timed media or non-timed media, or whether it contains signaling messages can be identified by referring to the value in the type field in the MMTP header.

Subsequently, the structure of the signaling message used in the MMT protocol, which is relevant in realizing the technique disclosed herein, will be described. A signaling message is signaling information necessary for controlling the transmission of a package and using the package, and transmits various signaling tables.

MMT signaling messages use a common format consisting of three common fields, one specific field for each signaling message type, and a 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.

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

The message_id is a 16-bit fixed value that identifies a PA message in various signaling information. Version is an 8-bit integer parameter that indicates the version of the PA message. For example, if some parameters that make up the MP table are also updated, the version is incremented by +1. Length is a 32-bit length parameter that indicates the size of the PA message in bytes, which is counted immediately after this field.

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

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

15 and 16 show an example of the syntax of the MP table (FIG. 16 is the second half following FIG. 15). Further, FIG. 17 shows a description of the parameters included in the MP table. The structure of the MP table will be described below.

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

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

The field of MP_table_descriptors is a storage area for descriptors related to the entire package. MPT_table_descriptor_length is a 16-bit length parameter that indicates the size N2 of the field in bytes. Then, MP_table_descriptor is assumed to be N2 bytes (one or more) after defining descriptors for various purposes.

number_of_assets is an 8-bit parameter that indicates the number of assets (signals, files) as elements that make up the package. The following Asset loops are arranged for the number of number (N3) of number_of_asset.

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

assert_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 where the asset is acquired. In the present embodiment, gen_loc_info is described in the form of a packet id on the transmission path from which the asset is acquired. Therefore, the packet_id on the MP table can be subtracted to retrieve the corresponding packet ID on the MMT transmission path.

The field of asset_descriptor is the storage area of the descriptor related to the asset. assert_descriptor_length indicates the size N5 of the asset_descriptor field in bytes. Then, asset_descriptor is supposed to arrange N5 (one or more) after defining descriptors for various purposes.

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

The message_id (message identification) is a 16-bit fixed value that identifies the M2 section message in various signaling information, and is set to 0x8000 in this embodiment. Version is an 8-bit integer parameter that indicates the version of the M2 section message. The length (message length) is a 16-bit length parameter that indicates the size of the M2 section message in bytes, which is counted immediately after this field. The table_id (table identification) is an area used for identifying the table to which the section belongs. The section_synchrox_indicator (section syntax instruction) is set to "1" indicating an extended format. The section_length (section length) is an area for writing the number of bytes of data following the section length area. The table_id_extension (table identification extension) is an area for extending 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 ‘1’ if the table is currently available, and ‘0’ if it indicates that the table is currently unavailable and will be valid next. The section_number (section number) is an area for writing the section numbers constituting the table. The last_section_number (final section number) is an area for writing the last section number constituting the table. CRC32 (CRC), ITU-T Recommendation H. A cyclic redundant code according to 222.0.

FIG. 19 shows a configuration example of the MH AI (Application Information) table (MH AIT) 1900 transmitted by the 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 the table as an application information (AI) table in various signaling information, and is set to 0x89 in this embodiment. The statement_sync_indicator (section syntax instruction) is a 1-bit field and is always set to "1". sectoin_length (section length) is a 12-bit field, and the first 2 bits are always "00". This specifies the number of bytes in the section from the section length field to the end of the section containing CRC32. This value shall not exceed 1021 (0x3FD in hexadecimal). application_type (application format) is a 16-bit field that indicates the value of the application being transmitted by AIT. In DVB, 0x0001 is assigned to the DVB-J application. It is also set to 0x0001 in the ARIB-J application. version_number (version number) is a 5-bit field, which is the version number of the subtable. version_number is the version number of the MH AI table, and is incremented by +1 when the information in the sub-table changes. Moreover, when the value of the version number becomes "31", it returns to "0" next. The current_next_indicator (current next instruction) is always set to "1". section_number (section number) is an 8-bit field representing the section number. The section number of the first section in the subtable is 0x00. The section number is incremented by +1 each time a section with the same table identification and application format is added. The last_session_number (last section number) is an 8-bit field that specifies the last section number in the subtable to which the section belongs.

command_descriptor_length (common descriptor loop length) is an 8-bit field that defines the byte length of the subsequent descriptor (descriptor in the description area). This descriptor (descriptor in the description area) stores the information of the descriptor in a series of areas consisting of a loop of several minutes of command_descriptor_length. The descriptor applies to all applications in the AIT subtable. For example, the transmission protocol descriptor is written to the descriptor field.

The application_loop_length is an area for writing the number of application information included in this MH AI table. Then, the loop of application information is arranged for the number of minutes indicated by application_loop_length.

Within one application information loop, a descriptor (descript) described in a series of loops consisting of application_identifier (application identifier), application_control_code (application control code), and application_descriptor_loop_length (application information descriptor loop length). Application information descriptor) is placed. The descriptors in this descriptor area apply only to the specified application.

The application_identifier (application identifier) is a parameter that identifies the application. The application_control_code (application control code) is an 8-bit field that defines a control code that controls the state of the application. The semantics of this field depend on the value of the application format. If "autostart" is specified as application_control_code, the receiver that refers to this MH AT table starts the application specified by application_identifier. Further, if "prefetch" is instructed as application_control_code, the receiver referring to this MH AT table pre-reads the application specified by application_identifier. If "kill" is specified as application_control_code, the receiver that refers to this MH AT table stops the execution of the application specified by application_identifier. CRC32 (CRC), ITU-T Recommendation H. A cyclic redundant code according to 222.0.

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

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

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 this field.

Information on application_profile is written in a series of regions consisting of loops of several minutes of application_profile_length. The application_profile is a profile of the receiver on which this application can be executed, and the required function is indicated by a bitmap for each function requested from the receiver. However, the upper 3 bits indicate functional bitmap switching. The above bitmap is specified for each version. In addition, version_major, version_minor, and version_micro are versions specified in the application profile, respectively.

service_bound_flag is a flag indicating whether or not 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 the applications announced within this service. transport_protocol_label indicates a protocol for transmitting an application. As the value of transport_protocol_label, 0x0003 defines HTTP / HTTPS transmission, and 0x0005 defines MMT and non-timed transmission.

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

Descriptor_tag is an 8-bit integer value that identifies the descriptor 2200. Descriptor_length is an 8-bit area for writing the number of bytes of data of the descriptor 2200 following this field.

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

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

The URL_base_byte stores text information indicating the URL_base in the URL character string in a series of areas composed of loops of several minutes of the URL_base_length.

URL_extension_count indicates the number of URL_extensions following URL_base, and loops of URL_extension are arranged by the number of URL_extension_counts. Then, in one URL_extension loop, the URL_extension_byte stores text information indicating each URL_extension in a series of areas consisting of a number of loops of the URL_extension_length that defines 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 and the complete URL "http://xbc.com/index" is concatenated. You can get ".html".

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 acquired. can do.

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

The message_id (message identification) is a 16-bit fixed value that identifies a data transmission message in various signaling information, and is set to 0xF000 in this embodiment. The version is an area for writing the 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.

number_of_tables (number of tables) indicates the number of tables to be stored in this data transmission message. A loop of table information is arranged as a table to be stored in the data transmission message and for the number indicated by num_of_tables.

In one table information loop, 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 the table stored in this data transmission message. Data transmission messages carry three types of signaling tables: the data asset management table (DAMT), the data directory management table (DDMT), and the data content management table (DCMT). (As described above), the table_id (table identifier) identifies which of these tables. table_version (table version) indicates the version of the table to be stored in this data transmission message. table_length (table length) indicates the size of the table stored in this data transmission message in bytes.

In addition, the loops of the table are arranged for the number indicated by number_of_tables. Information on the contents of the table identified by table_id is stored in the loop of one table. The table indicates a table to be stored in this 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. The meaning of each parameter of this data asset management table will be described below.

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

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

Within one asset information loop, there is a download_id, information about the asset (file data) itself, and information about each item contained in the asset. The download_id is identification information written in the extended header of the MMTP packet that transmits the non-timed media (file data) (see FIG. 7).

Information about the asset itself stored in the asset information loop includes asset_ID_scape, asset_ID_length, asset_ID_length, and asset_ID_byte. asset_ID_scheme indicates the format of asset_ID. As the format of the asset_ID, for example, UUID (Universal Unique Identifier), URI (Uniform Resource Identifier), and GURL (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 the format specified by the asset_ID_scene in a series of regions consisting of a loop of several minutes of the asset_ID_length. By the way, in this embodiment, this information is used as information for identifying an asset in common with the MP table and the data asset management table, but since the amount of data is large, other substituteable asset identification information may be used. .. For example, it is assumed that a 16-bit component_tag is defined as information corresponding to the asset_ID in the MP table, and the component_tag is used instead of the asset_ID in the data asset management table.

The number_of_items is an area for writing the number of items constituting the assets of the corresponding file data. Then, loops of items are arranged for the number of number_of_items, and information about each item constituting the 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 about the item. Item_ID is a 32-bit value indicating an ID that identifies an item transmitted by a non-timed MFU. The node_tag is information for identifying an item as well, and is a 16-bit value. By using 16-bit node_tag instead of 32-bit item_ID as the signaling information, the bit size required for item identification can be reduced. Note that node refers to each of the directories and items that are nodes in the directory structure that compose the data broadcasting application (content). Not only items but also directories 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 each time the content of the item is updated, the version is incremented by +1. item_checksum indicates the checksum of the item. It is considered that the amount of information is large to always set the checksum for all files. Therefore, in consideration of such consideration, for example, a 1-bit check_sum_flag may be set so that a 32-bit item_check_sum appears only when 1 is assigned to the check_sum_flag. 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 placed after the lens. item_info_length represents the size of the information area of item_info_byte in bytes. Then, item_info_byte stores information (item_info ()) about the item in a series of areas including loops of several minutes of item_info_length.

descriptor_loop_length indicates the total byte length of the descriptor. The descriptor stores the descriptor information (descriptor ()) in a series of areas including a loop of several minutes of descriptor_loop_length. The descriptor to be stored is defined separately.

In short, the data asset management table 2500 is a table that manages information about the assets of file data (content) contained in one package and the items contained in the assets. Item version information is also managed as information about the item. With reference to the data asset management table 2500, the node_id or item_info described in the MMT extension header for transmitting the corresponding asset_id or asset can be subtracted from the node_tag (or Item_ID), or the node_tag handled on the transmission path of signaling information. It is possible to subtract item_ID and item_info on the transmission path of file data from.

FIG. 26 shows a configuration example of the data directory management table (DDMT) 2600 transmitted by the data transmission message. The data directory management table is a table that manages the directories that make up the data broadcasting application (content) and the location information of each node (subordinate directories and items (file data)) included in the directories. The meaning of each parameter of this data directory management table will be described below.

An 8-bit fixed value indicating that the table is a data directory management table is written in the table_id (table identification) in various signaling information. version_ is an 8-bit integer parameter that indicates the version of this data directory management table. For example, if you update some of the parameters that make up the data directory management table, the version will be incremented by +1. Length is a 16-bit length parameter that indicates the size of this data directory management table in bytes, which is counted immediately after this field.

base_folder_path_length represents the size of the information area of base_folder_path_byte in bytes. base_folder_path_byte stores the path name to base_folder (upper directory) in a series of areas consisting of loops of several minutes of base_folder_path_length. base_folder_path_byte is represented, for example, in the absolute URL format for accessing the corresponding directory.

number_of_folder_nodes indicates the number of folder nodes listed in the data directory management table. Then, loops of folder nodes are arranged for the number of number_of_folder_nodes.

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

folder_node_path_length represents the size of the information area of folder_node_path_byte in bytes. folder_node_path_byte stores the path name to folder_node in a series of areas consisting of loops of several minutes of folder_node_path_length. Folder_node_path_byte is represented, for example, in the form of a URL relative to base_folder_path for accessing the corresponding directory. Although not shown, folder_node_version (version information of the folder node) may be included as the information of the folder node. 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. You can get the complete URL "http://xbc.com/index.html".

number_of_files indicates the number of files listed in the data directory management table. Then, loops of files are arranged for the number of num_of_files.

In the 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 that identifies an item transmitted by a non-timed MFU in 16 bits, which is shorter than the 32-bit item_ID. Note that node refers to each of the directories and items that are nodes in the directory structure that compose the data broadcasting application (content). Not only items but also directories can be specified by node_tag (described above). file_name_byte is stored in a series of areas consisting of loops of several minutes of file_name_length.

In short, the data directory management table 2600 is a table that manages the directory structure of the directories contained in one package and the subdirectories and files (items) contained in the directories. The data directory management table 2600 allows the file structure of the data broadcasting application to be separated from the file structure for file transmission. Further, with reference to the data directory management table 2600, the path name (URL) of the corresponding item can be subtracted from the node_tag, and conversely, 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 in which the file exists is set as folder_path_byte, and identification information is given as node_tag for each directory. The file name and node_tag are used as the information for each item. Since only is specified, the amount of information in folder_path_byte does not become too large.

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

The data content management table (DCMT) is a table that manages information on file data, that is, content (data broadcasting application) transmitted as non-timed media. In the present embodiment, the data content management table includes information that specifies a forced cache and is transmitted. Data broadcasting linked to broadcast programs is required to be presented in a timely manner. In such a case, the broadcast transmission system 11 side includes the information for specifying the forced cache in the data content management table (DCMT), and the receiver 12 side uses it for data broadcasting linked to the broadcast program. It is possible to pre-cache each file to be generated and realize timely presentation of data broadcasting.

The following two methods can be mentioned as a transmission method of forced cache information by the data content management table (DCMT).

(Method 1) In the data content management table, for each data broadcasting presentation unit (PU), the broadcast transmission file (member time) list constituting the presentation unit, the core file (primary time), and the pre-cache If the target file exists, describe the information in the target file list (pre-cache item).

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

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

The lock target file referred to here is composed of, for example, a broadcast file list used in the data broadcasting presentation unit (PU) to be referred to next from the current data broadcasting presentation unit (PU). By presenting the lock and unlock target file list with the data broadcasting signaling information on the production side of the broadcast program, the receiver side can perform the cache control operation by locking and unlocking. For example, on the receiver side, the file data required for the next data broadcasting presentation unit to be transitioned can be locked in the cache. As a result, a timely data broadcasting service linked to the broadcasting program can be realized. Further, the unlock target file is composed of, for example, a broadcast file list that is unnecessary in the current data broadcasting 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 the data content management table (DCMT) 2700 transmitted by the data transmission message that realizes the method 1.

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

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

In the loop of one content, information about the content_ID, the content_version, the content_cache_size, and the data broadcasting presentation unit (Presentation Unit: PU) included in the content is written as the information about the content. The content_ID is the content identification information. content_version indicates the content version. content_cache_size indicates the size to cache the content.

The number_of_PU is the number of data broadcasting presentation unit PUs included in the content, and loops of PUs are arranged by the number of numbers_of_PU.

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

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

Further, in the loop of the PU, if the target file of the pre-cache exists in the corresponding PU, the information of 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 are arranged for the number of number_of_pre_cache_nodes. A pre_cache_node_tag that identifies the pre-cache node is written in the loop of one pre-cache node.

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

Further, in the loop of one PU, a number_of_linked_PU indicating the number of other PUs linked from this PU and a loop of linked_PU as many as the number of number_of_linked_PU are arranged. In the loop of one linked_PU, linked_PU_tag which is the identification information of linked_PU is written.

FIG. 28 shows a configuration example of the data content management table (DCMT) 2800 transmitted by the data transmission message realizing the method 2.

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

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

In the loop of one content, information about the content_ID, the content_version, the content_cache_size, and the data broadcasting presentation unit (Presentation Unit: PU) included in the content is written as the information about the content. The content_ID is the content identification information. content_version indicates the content version. content_cache_size indicates the size to cache the content.

The number_of_PU is the number of data broadcasting presentation unit PUs included in the content, and loops of PUs are arranged by the number of numbers_of_PU.

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

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

Further, in the loop of the PU, in the corresponding PU, a file to be locked (lock cache item) for locking the cache to the cache memory 408 and a file to be unlocked (unlock cache item) among the lock targets. Describe the information of. Specifically, number_of_lock_cache_nodes is the number of nodes to be pre-cached, and then loops of locked target nodes are arranged as many as the number of number_of_lock_cache_nodes. A lock_cache_node_tag that identifies the lock target node is written in the loop of one lock target node. Further, number_of_unlock_cache_nodes is the number of nodes to be pre-cached, and then loops of unlock target nodes are arranged as many as the number of number_of_unlock_cache_nodes. An unlock_cache_node_tag that identifies 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 in the data broadcasting presentation unit (PU) to be referred to next from the current data broadcasting presentation unit (PU). By presenting the lock target file list with the data broadcasting signaling information on the broadcast program production side in this way, the receiver side locks the file data required for the next data broadcasting presentation unit in the cache. Can be kept. As a result, a timely data broadcasting service linked to the broadcasting program can be realized. Further, the unlock target file is composed of, for example, a broadcast file list that is unnecessary in the current data broadcasting 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, in the loop of one PU, a number_of_linked_PU indicating the number of other PUs linked from this PU and a loop of linked_PU as many as the number of number_of_linked_PU are arranged. In the loop of one linked_PU, linked_PU_tag which is the identification information of linked_PU is written.

In short, the data content management table is a table that manages each content (data broadcasting application) in a data broadcasting presentation unit (PU) in one package, and refers to the data content management table to node_tag. From, the PU_tag of the data broadcasting presentation unit including the node can be acquired. Further, it has an aspect of controlling the forced cache of the data broadcasting file on the data content management table receiver 12 side. However, the details of the cache control operation using the data content management table will be described later.

FIG. 29 illustrates the transmission of the data broadcasting application (content) transmitted by MMT, the location of the content, and the mechanism for presenting the application.

FIG. 29 (A) shows the directory structure of the content. Each content 1, 2, ... Consists of a data broadcasting application (application) and a material. Data broadcasting applications and materials are resources whose substance is file data. 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. Also, in the signaling information, the item can be identified by a 16-bit node_tag. As shown in FIG. 29 (C), each resource is transmitted as an item on the MMT transmission path of the corresponding asset (described later). The application consists of one or more HTML documents that are referenced when the content is executed (when the data broadcast is presented). The material is monomedia data such as a jpg image or text referenced from an HTML document. One HTML document and materials referenced from the HTML document constitute one data broadcasting presentation unit PU. In the example shown in FIG. 29 (A), content1 is A11. html, A12. html, A13. It has one or more HTML documents such as html as a resource of a data broadcasting application. Of these, A11. The html is a resource that is directly referenced when the content is executed.

FIG. 29B shows a reference relationship between resources at the time of content execution (when data broadcasting is presented). In the illustrated example, the application A11 directly referred to when the content is executed and the materials B11 and B02 referred to by the application A11 are resource groups 2801 constituting one data broadcasting presentation unit PU, and p1 is assigned as the PU_tag (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 treated below as not included in the resource group of the data broadcasting presentation unit).

Similarly, application A12 and materials B12, B02, and B13 referred to therein are resource groups 2802 constituting one data broadcasting presentation unit PU, and p2 is assigned as PU_tag (Note that B07 is MMT by broadcasting). It is a material that can be acquired at any time by HTTP transmission by communication instead of being transmitted, and will be treated as not included in the resource group of the data broadcasting presentation unit below). Similarly, the application A01 and the materials B03, B01, and B04 referred to by the application A01 are resource groups 2803 that constitute one data broadcasting presentation unit PU, and p3 is assigned as the PU_tag.

In addition, a link reference relationship can be established between a plurality of HTML documents (well-known). In the example shown in FIG. 29 (B), resource A11. html is an HTML document that describes the application presentation screen that is directly referenced and displayed first when the content is executed. On the other hand, resource A12, which is included in the same content1. Resources A01. Included in html and common outside content1. html is A11. This is an HTML document that describes an application presentation screen that transitions from the screen presented by executing html. A11. Has a link reference relationship with html. Each resource A11. html, A12. html, A01. The html forms resource groups 2801, 2802, and 2803, each of which constitutes one data broadcasting presentation unit PU. Then, the linked data broadcasting presentation units 2801, 2802, and 2803 form a larger resource group 2810 at a higher level. Resource A11. html, A12. html, A01. HTML is a file data (primary item_node) that is central to each data broadcasting presentation unit PU.

Also, the entire application contained in the package (one broadcast program), and the entire content, constitutes a large resource group, that is, the entire data content. The entire data content is the range of the data broadcasting presentation unit PU having a common content_ID. By turning the loop of the PU of the corresponding content_ID in the data content management table, all the data broadcasting presentation unit PUs included in the content can be collectively specified. In the example shown in FIG. 29 (B), the applications included in content 1 and common form a resource group 2820 for the entire content.

FIG. 29C schematically shows how the content is transmitted by MMT. Each application or material that is a component of content is an entity of file data 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 MMT transmission, each content contained in the package is treated as one asset, and Asset_ID is assigned to each. In the illustrated example, a1 is assigned to content1 as asset_ID. Further, in MMT transmission, individual resources such as HTML document data and materials are treated as one item, and Item_ID is assigned to each. In the illustrated example, i11, i12, i13, and i14 are assigned as Item_ID to each resource included in content1.

In addition, 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, the items having 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. 29 (A), the data content management table is represented in FIG. 29 (B), and the data asset management table is represented in FIG. 29 (C). It is expressed, and these are related by item_ID or node_tag.

The reference relationship of each table transmitted as signaling information when acquiring a data broadcasting application (content) from an MMT transmission line will be described with reference to FIG.

When the receiver 12 acquires the MH-AI table (MH AI) 2901 in the M2 section message, it refers to the application_control_code and confirms how the state of the application is controlled. Then, when "autostart" is instructed, if it is confirmed that MMT transmission is specified by referring to transport_protocol_label in the table, the item (file data) that is directly referred to when the application is presented. The URL information of is extracted from the transmission protocol descriptor. Then, the receiver refers to the data directory management table (DDMT) 2902 sent in 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 refers to the data asset management table (DAMT) 2903 sent in the data transmission message, returns the acquired node_tag to the item_ID on the MMT transmission path, and returns the corresponding asset. Identify and get its asset_ID and download_id.

Then, when the receiver refers to the MP table (MPT) 2904 sent in the PA message and acquires the packet_id corresponding to the acquired attach_ID, it is on the MMT transmission path of the file data and in the header of the MMTP packet. You can get the desired item (directly referenced when presenting the application) by filtering based on packet_id, download_id in the extension header, and item_ID in the DU header.

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

FIG. 31 schematically shows a mechanism for caching files and data used for data broadcasting in the receiver. The cache referred to here includes caching and pre-cache of the 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 broadcasting linked to the broadcast program based on the forced cache information included in the data content management table. To do.

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

The application data control unit 407 pulls the node_tag of the file data to be precached in the data asset management table transmitted by the data transmission message, acquires the asset_ID of the asset to which the node belongs, and then obtains the asset_ID of the asset to which the node belongs. , Asset_ID is subtracted from the MP table transmitted in the PA message to obtain the packet_id of the MMTP packet to which the asset is transmitted. Further, when the system control unit 408 obtains the download_id described in the extension header of the MMTP packet that transmits the desired item from the data asset management table, the header of the MMTP packet is on the MMT transmission path of the file data. Filtering based on the packet_id in, the downstream_id in the extension header, and the item_ID in the DU header to get the entity of the desired item and precache it in cache memory 408.

The data broadcasting application engine 409 was demultiplexed from the broadcasting stream by the demultiplexer 402 if the necessary items (file data) were already cached in the cache memory 408 when the application was executed. Without waiting for the file data to arrive, it can be retrieved from the cache memory 408 and respond quickly 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 broadcasting application engine 407 waits for the demultiplexed file data to arrive from the broadcasting stream and responds to the data broadcasting display signal. To generate.

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

It has already been mentioned that there are two methods for transmitting forced cache information by the data content management table (DCMT), method 1 and method 2. First, the cache control operation using the method 1 will be described.

In the method 1, the data content management table (DCMT) 2700 shown in FIG. 27 is transmitted as a data transmission message from the broadcast transmission system 11 side. The data content management table (DCMT) 2700 contains a list of broadcast transmission files (member time), a core file (primary time), and a pre-cache for each data broadcast presentation unit (PU). If the target file exists, describe the information in the target file list (pre-cache item). Therefore, on the receiver 12 side, a cache control operation by pre-cache can be performed as shown 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) Corresponding data is obtained by the application data control unit 407 accessing the application file (which is the center of the data broadcasting presentation unit) specified in prime_item by the instruction from the data broadcasting application control engine 409 or the like. Recognize that the broadcast presentation unit (PU) has entered the presentation state.
(Operation 03) In the data content management table (DCMT) included in the data transmission message, the application data control unit 407 includes each member file (PU_member_node) included in the corresponding data broadcasting 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 pre-caches. 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 prime_item from the cache memory 408.
(Operation 06) After that, by updating the data content management table (DCMT), the structure of the member file (PU_member_node) included in the data broadcasting presentation unit (PU) currently in the presentation state and the file to be pre-cached can be changed. If there is a change, or if the application operation in the data broadcasting application engine 409 causes a transition to the presentation state of another data broadcasting presentation unit (PU), the data broadcasting presentation unit (PU) currently in the presentation state is displayed. The above processes (operation 03) to (operation 05) are performed. Even if the file is held in the cache memory 408 in the previous state, the application data control unit 407 deletes an unnecessary file from the cache memory 408 in the current state.

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

When the data broadcasting application control engine 409 is performing the application operation, that is, presenting the data broadcasting (Yes in step S3201), the application data control unit 407 is set to prime_item (data broadcasting presentation unit) in the data content management table. By accessing the application file specified in (center of) (Yes in step S3202), it is recognized that the presentation state of the corresponding data broadcasting 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 data broadcasting presentation unit (PU) currently presented and each member file (PU_member_node). ) Is acquired and held in the cache memory 408 (step S3203). The data broadcasting application engine 409 executes the application file specified in prime_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 broadcasting presentation unit (PU) in the data content management table (step S3204). Then, when the target of the pre-cache is specified (Yes in step S3204), the application data control unit 407 also acquires each file (item) of the pre-cache target and pre-caches the cache memory 408. (Step S3205).

After that, when the configuration of the member file (PU_member_node) included in the data broadcasting presentation unit (PU) currently being presented or the file to be pre-cached changes due to the update of the data content management table (DCMT). (Yes in step S3206) returns to step S3203, and repeatedly executes the above process in the data broadcasting presentation unit (PU) currently in the presentation state.

In addition, when the application operation in the data broadcasting application engine 409 transitions 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 process is repeatedly executed in the data broadcasting presentation unit (PU) to which the transition has occurred.

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

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

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

When the data broadcasting application control engine 409 is performing the application operation of the data broadcasting presentation unit (PU) identified by PU_id = 1, the application data control unit 407 refers to the data content management table and refers to the data content management table. The application file "A01.html" designated as the primary_item (center of the data broadcast presentation unit) of the data broadcast presentation unit (PU_id = 1) currently being presented, and each member file (PU_member_node) "B01", "B02" When each node_tag is acquired from the data content management table and the file data entity corresponding to these node_tags is acquired from the MMT transmission line 503 that transmits the data assets, the reference number 3301 is used. As shown, cache in cache memory 408. The method of accessing the file transmitted from the node_tag on the MMT transmission line 503 is as described above with reference to FIG. 30 (hereinafter, the same applies). However, since the target of pre-cache is not specified for this data broadcasting presentation unit (PU), the pre-cache operation is not performed.

Next, it is assumed that the application operation in the data broadcasting application engine 409 causes a transition to the presentation state of another data broadcasting presentation unit (PU) identified by PU_id = 3. In the same manner as described above, the application data control unit 407 includes the application file "A11.html" designated as the prime_item (center of the data broadcast presentation unit) of the data broadcast presentation unit (PU_id = 3) to which the transition is made, and , Each member file (PU_member_node) "B11", "B12", "B13" each node_tag is acquired from the data content management table, and the file data enthusiast corresponding to these node_tags is obtained from the MMT transmission line 503. The tee is acquired and cached in the cache memory 408 as indicated by reference numeral 3302. However, since the target of pre-cache is not specified for this data broadcasting 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 line 504. Then, as shown by the reference number 3303, when it is detected that the version of the data content management table has been updated from 1 to 2, the application data control unit 407 is currently presenting the data broadcasting presentation unit ( It is checked whether there is any change in the priority_item of PU_id = 3), each member file, and the file to be pre-cached. Since there is no change in the member files this time, each previously cached member file is kept in the cache memory 408. Further, since "A12", "B14", and "B15" are added as files to be pre-cached for the data broadcasting presentation unit (PU_id = 3), the application data control unit 407 can be used from the MMT transmission line 503. The file data entity corresponding to the node_tag of is acquired and cached in the cache memory 408 as indicated by reference number 3304.

Then, as indicated by reference number 3305, upon receiving an event message from the MMT channel 504 instructing the update of the datacast presentation, the datacast application engine 409 has an HTML from the running A11 file to the A12 file. Perform document transition. On the other hand, almost at 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 the prime_item of the data broadcasting presentation unit (PU_id = 3) currently being presented. Is changed to "A12.html", and it is detected that the member file is changed to "B14", "B15", and "B16". As described above, since the primary_item "A12.html" and the member files "B14" and "B15" are already precached in the cache memory 408, the data broadcasting application engine 409 is stored in the cache memory 408. Data broadcasts can be displayed quickly using the retained files. That is, it is possible to present timely data broadcasting linked to a broadcast program. Further, since "B12" is added as a file to be pre-cached for the data broadcast presentation unit (PU_id = 3), the application data control unit 407 can perform the file data corresponding to the mode_tag from the MMT transmission line 503. The entity is fetched and cached in cache memory 408 as indicated by reference number 3306.

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

In the method 2, the data content management table (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 locks the broadcast transmission file (member time) list, the core file (primary time), and the cache that constitute the presentation unit for each data broadcasting presentation unit (PU). Describe the information of the target file (lock cache item) to be locked and the target file (unlock cache item) to be unlocked among the locked targets. Therefore, on the receiver 12 side, the cache control operation by locking and unlocking the cache can be performed as shown 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 corresponding data is obtained by the application data control unit 407 accessing the application file (which is the center of the data broadcasting presentation unit) specified in prime_item by the instruction from the data broadcasting application control engine 409 or the like. Recognize that the broadcast presentation unit (PU) has entered the presentation state.
(Operation 13) In the data content management table (DCMT) included in the data transmission message, the application data control unit 407 includes each member file (PU_member_node) included in the corresponding data broadcasting presentation unit (PU). ) Is also acquired at the same time and held in the cache memory 408.
(Operation 14) Further, when the target of the lock cache is specified for the corresponding data broadcasting presentation unit (PU) in the data content management table, the application data control unit 407 locks. 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) On the contrary, when the data broadcast presentation unit (PU) is designated as the unlock cache target in the data content management table, the application data control unit 407 is set. If the unlock target file is cached in the cache memory 408, it is deleted and also deleted from the separately managed lock cache target file.
(Operation 16) The data broadcasting application engine 409 executes the application file specified in prime_item from the cache memory 408.
(Operation 17) After that, by updating the data content management table (DCMT), the structure of the member file (PU_member_node) included in the data broadcasting presentation unit (PU) currently being presented and the file to be pre-cached can be changed. When the change occurs, the above processes (operation 13) to (operation 16) are performed.
(Operation 18) When the application operation in the data broadcasting application engine 409 causes a transition to the presentation state of another data broadcasting presentation unit (PU), the lock cache target file is temporarily held in the cache memory 408 and then held in the cache memory 408. The above processes (operation 13) to (operation 16) are performed. Files other than the lock cache target may be deleted from the cache memory 408.

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

When the data broadcasting application control engine 409 is performing the application operation, that is, the presentation of the data broadcasting (Yes in step S3401), the application data control unit 407 is in the data content management table, and the primary_item (data broadcasting presentation unit). By accessing the application file specified in (center of) (Yes in step S3402), it is recognized that the presentation state of the corresponding data broadcasting 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 data broadcasting presentation unit (PU) currently presented and each member file (PU_member_node). ) Is acquired and held in the cache memory 408 (step S3403). The data broadcasting application engine 409 executes the application file specified in prime_item from the cache memory 408.

Further, the application data control unit 407 checks whether or not the lock cache target is specified for the corresponding data broadcasting presentation unit (PU) in the data content management table (step S3404). Then, when the lock cache target is specified (Yes in step S3404), the application data control unit 407 also acquires each unacquired file (item) among the lock cache targets, and cache memory. It is cached in 408 and separately managed as a lock cache target file (step S3405).

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

After that, when the configuration of the member file (PU_member_node) included in the data broadcasting presentation unit (PU) currently being presented or the file to be pre-cached changes due to the update of the data content management table (DCMT). (Yes in step S3408) returns to step S3403, and repeatedly executes the above process in the data broadcasting presentation unit (PU) currently in the presentation state.

In addition, when the application operation in the data broadcasting application engine 409 transitions 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 process is repeatedly executed in the data broadcasting presentation unit (PU) at the transition destination.

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

FIG. 35 shows an example of the lock / unlock operation of the file / data cache based on the method 2 in the receiver 12.

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

When the data broadcasting application control engine 409 is performing the application operation of the data broadcasting presentation unit (PU) identified by PU_id = 1, the application data control unit 407 refers to the data content management table and 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) currently being presented, and each member file (PU_member_node) "B01", "B02" When each node_tag is acquired from the data content management table and the file data entity corresponding to these node_tags is acquired from the MMT transmission line 503 that transmits the data assets, the reference number 3501 is used. As shown, cache in cache memory 408. The method of accessing the file transmitted from the node_tag on the MMT transmission line 503 is as described above with reference to FIG. 30 (hereinafter, the same applies). However, since the lock cache target is not specified for this data broadcasting presentation unit (PU), the cache operation is not performed.

Next, it is assumed that the application operation in the data broadcasting application engine 409 causes a transition to the presentation state of another data broadcasting presentation unit (PU) identified by PU_id = 3. In the same manner as described above, the application data control unit 407 includes the application file "A11.html" designated as the prime_item (center of the data broadcast presentation unit) of the data broadcast presentation unit (PU_id = 3) to which the transition is made, and , Each member file (PU_member_node) "B11", "B12", "B13" each node_tag is acquired from the data content management table, and the file data enthusiast corresponding to these node_tags is obtained from the MMT transmission line 503. The tee is acquired and cached in the cache memory 408 as indicated by reference number 3502. However, since the lock cache target is not specified for this data broadcasting 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 line 504. Then, as shown by the reference number 3503, when it is detected that the version of the data content management table has been updated from 1 to 2, the application data control unit 407 is currently presenting the data broadcasting presentation unit ( Check whether there is any change in the primary_item of PU_id = 3), each member file, and the file to be locked cached. Since there is no change in the member files this time, each previously cached member file is kept in the cache memory 408. Further, since "A12", "B14", "B12", and "B15" are added as lock cache target files of the data broadcast presentation unit (PU_id = 3), the application data control unit 407 transmits MMT. The file data entity corresponding to these node_tags is acquired from the channel 503, cached in the cache memory 408 as shown by the reference number 3504, and separately managed as a lock cache target file. In the figure, the files managed as lock cache targets are underlined (the same applies hereinafter).

Then, as indicated by reference number 3505, upon receiving an event message from the MMT channel 504 instructing the update of the datacast presentation, the datacast application engine 409 has an HTML from the running A11 file to the A12 file. Perform document transition. On the other hand, almost at 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 the prime_item of the data broadcasting presentation unit (PU_id = 3) currently being presented. Is changed to "A12.html", and it is detected that the member file is 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 broadcasting application engine 409 is stored in the cache memory 408. Data broadcasts can be displayed quickly using the retained files. That is, it is possible to present timely data broadcasting linked to a broadcast program. Further, since the lock cache target is not specified for this data broadcasting presentation unit (PU), the lock cache operation is not performed. As shown by reference number 3506, the lock-cached files "A12", "B14", "B12", and "B15" are retained in the cache memory 408 as they are, while the unnecessary files "A11" are deleted. Has been done.

Further, when an event message instructing to update the presentation of the data broadcasting is received from the MMT transmission line 504, the application data control unit 407 refers to the data content management table and refers to the data broadcasting 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 shown by reference number 3507, the application data control unit 407 acquires the file data entity corresponding to the node_tag of the file “B17” from the MMT transmission line 503 and lock-caches it in the cache memory 408. At the same time, the lock-cached file "B12" is deleted from the cache memory 408 and removed from the lock target.

In the data broadcasting service by BML (Broadcast Markup Language) currently in operation, a specific file is pre-cached and stored in the cache memory in advance by calling an API (Application Programming Interface) called "LockModuleOnMemory ()" from a script. It is possible to keep it (see, for example, Patent Document 2). In this method, it is necessary to incorporate special specifications premised on broadcasting operation into the specifications of applications such as scripts.

On the other hand, according to the technology disclosed in the present specification, the transmitting side such as a broadcasting station transmits the information related to the data broadcasting including the information specifying the forced cache, and the receiver side receives the information. The cache control of each file for data broadcasting is performed based on the forced cache information included in the signaling related to data broadcasting. Therefore, according to the technology disclosed in the present specification, in data broadcasting by the new HTML5, a highly versatile format is maintained without incorporating special specifications premised on broadcasting operation in the specifications of applications such as scripts. be able to.

The techniques disclosed in the present specification have been described in detail with reference to the specific embodiments. However, it is self-evident that one of ordinary skill in the art can modify or substitute the embodiment without departing from the gist of the technique disclosed herein.

The techniques disclosed herein can be applied to various broadcasting systems that employ MMT as the transport method. In addition, the techniques disclosed herein can be applied to various data broadcasting systems that transmit file data used for data broadcasting linked to a broadcast program by the MMT method or other transport methods.

In short, the techniques disclosed in this specification have been described in the form of examples, and the contents of the present specification should not be interpreted in a limited manner. In order to determine the gist of the technology disclosed in this specification, the scope of claims should be taken into consideration.

The technology disclosed in the present specification can also have the following configuration.
(1) A file / data transmitter that transmits file data used in data broadcasting,
A signaling message transmitter that sends including forced cache information that specifies a forced cache for file data for signaling related to data broadcasting,
A transmitter equipped with.
(2) The signaling message transmission unit describes, for each data broadcasting presentation unit, information on a broadcasting transmission file list constituting the presentation unit, a core file, and a precache target file list. Send a data transmission message containing a content management table,
The transmitter according to (1) above.
(3) For each data broadcasting presentation unit, the signaling message transmission unit includes a broadcast transmission file list and a core file constituting the presentation unit, 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 that describes the information in
The transmitter according to (1) above.
(4) Further provided with a media data transmission unit for transmitting media data of the main body of the broadcast program linked with data broadcasting.
The transmitter according to any one of (1) to (3) above.
(5) A file data transmission step for transmitting file data used in data broadcasting, and
A signaling message transmission step that includes forced cache information that specifies a forced cache of file data for signaling related to data broadcasting, and a signaling message transmission step.
Transmission method with.
(6) A file / data receiver that transmits file data used in data broadcasting,
A signaling message receiver that sends including forced cache information that specifies a forced cache of file data for signaling related to data broadcasting,
A control unit that controls caching of file data received by the file data receiving unit in a cache memory based on the forced cache information.
A receiving device comprising.
(7) The signaling message receiving unit describes, for each data broadcasting presentation unit, information on a broadcast transmission file list constituting the presentation unit, a core file, and a precache target file list. Receive a data transmission message containing a content management table,
The receiving device according to (6) above.
(8) When the file data receives a file included in the target file list of the pre-cache, the control unit pre-caches the file in the cache memory.
The receiving device according to (7) above.
(9) The signaling message receiving unit for each data broadcasting presentation unit includes a broadcast transmission file list and a core file constituting the presentation unit, a target file to be locked in the cache, and a target file to be unlocked among the lock targets. Receive a data transmission message containing a data content management table that describes the information in
The receiving device according to (6) above.
(10) When the file data receives the file to be locked, the control unit pre-caches it in the cache memory.
The receiving device according to (9) above.
(11) The control unit deletes the unlocked file from the cache memory.
The receiving device according to (9) above.
(12) When the file data receives the broadcast transmission file list and the main file constituting the current data broadcasting presentation unit, the control unit caches the data in the cache memory.
The receiving device according to any one of (6) and (9) above.
(13) Further provided with a data broadcasting presentation unit that presents data broadcasting using file data.
The receiving device according to any one of (6) to (12) above.
(14) A media data receiving unit for receiving media data of a broadcasting program main body linked with data broadcasting and a broadcasting program presenting unit for presenting a broadcasting program based on the media data are further provided.
The receiving device according to any one of (6) to (13) above.
(15) A file data reception step for transmitting file data used in data broadcasting, and
A signaling message reception step to send including forced cache information that specifies a forced cache of file data for signaling related to data broadcasting, and
A control step that controls caching of file data received by the file data receiver in a cache memory based on the forced cache information, and
Receiving method having.

10 ... Digital broadcasting system 11 ... Broadcast transmission system, 12 ... Receiver 301 ... Clock unit, 302 ... Signal transmission unit, 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 / transmitter 401 ... Tuner / demodulator, 402 ... Demultiplexer 403 ... Clock section, 404 ... Video decoder 405 ... Audio decoder, 406 ... Caption decoder 407 ... Application data control unit, 408 ... Cache memory 409 ... Data broadcasting application engine 410 ... System control unit 411 ... Synthesis unit 412 ... IP interface

Claims (5)

It includes a file that constitutes an application and a transmitter that transmits a signaling message related to the transmission of the application.
The signaling message includes a first table that describes the location information of a directory of files constituting the application and a node tag that identifies the directory, and a second table that describes the node tag.
The transmitter further transmits information that specifies a file to be locked in the cache.
Transmitter. The transmitter further transmits information specifying the file to be unlocked from the cache.
The transmitting device according to claim 1. The transmission unit included in the transmission device has a transmission step of transmitting a file constituting the application and a signaling message related to the transmission of the application.
The signaling message includes a first table that describes the location information of a directory of files constituting the application and a node tag that identifies the directory, and a second table that describes the node tag.
The transmitter further transmits information that specifies a file to be locked in the cache.
Sending method. It includes a file that constitutes an application and a control unit that acquires signaling messages related to the transmission of the application.
The control unit further acquires the information for designating the file to be locked in the cache, and the information for designating the file to be locked in the cache and the directory of the files constituting the application included in the signaling message. Controls the caching of files that make up the application based on a first table that describes location information and node tags that identify the directory, and a second table that describes the node tags.
Receiver. The control unit included in the receiving device has an acquisition step of acquiring a file constituting the application and a signaling message related to the transmission of the application.
In the acquisition step, further information is acquired to specify the file to be locked in the cache.
A first table that describes information that specifies a file to be locked to the cache, location information of a directory of files that make up the application, and a node tag that identifies the directory, which is included in the signaling message. It further has control steps to control the cache of the files that make up the application, based on a second table that describes the node tags.
Reception method.