JP7248155B2 - receiver - Google Patents

Description

The technology disclosed in this specification includes a transmission device and a transmission method for transmitting data broadcasting files according to a predetermined transport method, and a receiving device for receiving data broadcasting files transmitted according to a predetermined transport method. and a receiving method.

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

According to the MMT system, it is possible to transmit both timed media such as video and audio, which are stream media, and 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, subtitles, and the like. Non-timed media are file data of data broadcasting applications (contents) such as HTML (Hyper Text Markup Language) documents.

Data broadcasting linked to broadcast programs requires timely presentation. On the other hand, each file used in data broadcasting is repeatedly transmitted in a limited broadcast transmission band. The receiving terminal can implement timely presentation of data broadcasting by caching files for data broadcasting. However, in a receiving terminal which is not equipped with an ample cache memory, if a necessary file is cache-missed, it must wait until the next repetition period, causing a delay of, for example, several tens of seconds until data broadcasting is presented. end up

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

JP 2013-153291 A JP 2007-274193 A

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

An object of the technique disclosed in this 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 technology disclosed in this specification is to provide a receiving device and a receiving method capable of suitably receiving data broadcasting files transmitted by a predetermined transport method.

The present application was made in consideration of the above problems, and the technology described in claim 1 is
a file data transmission unit for transmitting file data used in data broadcasting;
a signaling message transmission unit that transmits signaling related to data broadcasting including forced cache information specifying forced cache of file data;
It is a transmitting device comprising

According to the technique recited in claim 2 of the present application, the signaling message transmission unit of the transmission apparatus recited in claim 1 transmits, for each data broadcast presentation unit, a broadcast transmission file list that constitutes the presentation unit and a and a data transmission message containing a data content management table describing information on a file list to be precached.

According to the technique recited in claim 3 of the present application, the signaling message transmission unit of the transmission apparatus recited in claim 1 transmits, for each data broadcast presentation unit, a broadcast transmission file list that constitutes the presentation unit and A data transmission message including a data content management table describing information on a file to be locked in the cache, a file to be locked in the cache, and a file to be unlocked among the lock targets.

According to the technology recited in claim 4 of the present application, the transmission device according to any one of claims 1 to 3 further includes a media data transmission unit for transmitting media data of a broadcast program main body linked to data broadcasting. I have.

In addition, the technology according to claim 5 of the present application is
a file data transmission step of transmitting file data used in data broadcasting;
a signaling message transmission step of transmitting signaling related to data broadcasting including forced cache information designating forced cache of file data;
is a transmission method having

In addition, the technique according to claim 6 of the present application is
a file data receiver for transmitting file data used in data broadcasting;
a signaling message receiver that transmits signaling related to data broadcasting including forced cache information specifying forced cache of file data;
a control unit for controlling caching of the file data received by the file data receiving unit in a cache memory based on the forced cache information;
is a receiving device comprising

According to the technique recited in claim 7 of the present application, the signaling message receiving unit of the receiving device recited in claim 6 receives, for each data broadcasting presentation unit, a broadcast transmission file list that constitutes the presentation unit and a and a data content management table describing information on a file list to be pre-cached.

According to the technology recited in claim 8 of the present application, the control unit of the receiving device recited in claim 7, when the file data receives a file included in the precache target file list, configured to pre-cache in said cache memory;

According to the technique recited in claim 9 of the present application, the signaling message receiving unit of the receiving device recited in claim 6 receives, for each data broadcast presentation unit, a broadcast transmission file list that constitutes the presentation unit and a A data transmission message including a data content management table describing information on a file to be locked in the cache, a file to be locked in the cache, and a file to be unlocked among the lock targets.

According to the technique recited in claim 10 of the present application, the control unit of the receiving device recited in claim 9 precaches the file to be locked in the cache memory when the file data is received. is configured to

According to the technique recited in claim 11 of the present application, the control unit of the receiving device recited in claim 9 is configured to delete the unlock target file from the cache memory.

According to the technique recited in claim 12 of the present application, the control unit of the receiving device recited in either claim 6 or 9 is central to the broadcast transmission file list that constitutes the current data broadcast presentation unit. A file is configured to be cached in the cache memory as the file data is received.

According to the technique recited in claim 13 of the present application, the receiving device recited in 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 recited in claim 14 of the present application, the receiving device according to any one of claims 6 to 13 includes a media data receiving unit for receiving media data of a broadcast program main body linked to data broadcasting; A broadcast program presenter is further provided for presenting the broadcast program based on the media data.

In addition, the technology according to claim 15 of the present application is
a file/data receiving step of transmitting file/data used in data broadcasting;
a signaling message receiving step of transmitting signaling related to data broadcasting including forced cache information designating forced cache of file data;
a control step of controlling caching of the file data received by the file data receiving unit in a cache memory based on the forced cache information;
is a receiving method having

The technology disclosed in this specification is based on the assumption that data broadcasting files based on, for example, HTML (Hyper Text Markup Language) 5 are transmitted by the MMT method. According to the technology disclosed in this specification, a transmitting device such as a broadcasting station can transmit information specifying forced caching in signaling related to data broadcasting. Further, according to the technology disclosed in this specification, a receiving device such as an STB (SetTopBox) or a television receiving terminal installed in a home receives forced cache information based on signaling related to data broadcasting. It is possible to appropriately perform cache control of each file for data broadcasting and timely present data broadcasting linked to a broadcast program.

Note that the effects described in this specification are merely examples, and the effects of the present invention are not limited to these. Moreover, the present invention may have additional effects in addition to the effects described above.

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

FIG. 1 is a diagram schematically showing a configuration example of a digital broadcasting system 10 to which the technique disclosed in this specification is applied. FIG. 2 shows a stack model 200 of a broadcast signal applying MMT. FIG. 3 is a diagram showing a configuration example of the 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 system. FIG. 6 is a diagram showing a configuration example of the header of an MMT packet. FIG. 7 is a diagram showing a configuration example of an extension header 700 in the case of an MMTP packet that transmits 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_Header 900 of MFU in which timed media is placed in the payload. FIG. 10 is a diagram showing a configuration example of DU_Header 1000 of MFU in which non-timed media is arranged in 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 a PA message 1201 and an MP table 1202 included in the PA message. FIG. 13 is a diagram showing a syntax example of the PA message 1300. As shown in FIG. FIG. 14 is a diagram showing an explanation of parameters included in the PA message. FIG. 15 is a diagram showing a syntax example (first half) of the MP table (MPT). FIG. 16 is a diagram showing a syntax example of the MP table. FIG. 17 is a diagram explaining each parameter included in the MP table. FIG. 18 is a diagram showing a configuration example of the M2 section message 1800. As shown in FIG. FIG. 19 is a diagram showing a configuration example of an MH AI (Application Information) table (MH AIT) 1900 transmitted by an M2 section message. FIG. 20 is a diagram showing a configuration example of the application information descriptor 2000. As shown in FIG. FIG. 21 is a diagram showing explanations of parameters included in the application information descriptor. FIG. 22 is a diagram showing a configuration example of the transmission protocol descriptor 2200. As shown in FIG. 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 signaling messages. FIG. 25 is a diagram showing a configuration example of a data asset management table (DAMT) 2500. As shown in FIG. FIG. 26 is a diagram showing a configuration example of a data directory management table (DDMT) 2600. As shown in FIG. FIG. 27 is a diagram showing a configuration example of a data content management table (DCMT) 2700. As shown in FIG. FIG. 28 is a diagram showing a configuration example of a data content management table (DCMT) 2700. As shown in FIG. 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 reference relationships among tables transmitted as signaling information when a data broadcasting application (content) is acquired from an MMT transmission line. FIG. 31 is a diagram schematically showing a mechanism for caching data broadcasting applications (contents) within a receiver. FIG. 32 is a flow chart showing a file data cache control procedure based on Method 1 in the receiver 12 . FIG. 33 is a diagram showing an example of pre-cache operation of file data based on method 1 in the receiver 12 . FIG. 34 is a flow chart showing a file data cache control procedure based on method 2 in the receiver 12 . FIG. 35 is a diagram showing an example of lock and unlock operations of the file data cache based on Method 2 in the receiver 12 .

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

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

The broadcast transmission system 11 transmits IP (Internet Protocol) broadcast signals including transmission media. Broadcast signal transmission media include 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, subtitles, and the like. Non-timed media are file data used for data broadcasting, such as HTML documents. The following description assumes a data broadcasting service based on HTML5.

On the other hand, the receiver 12 receives broadcast signals sent from the broadcast transmission system 11 . The receiver 12 acquires transmission media such as video, audio, subtitles, etc. from the received broadcast signal, and presents images and sounds. When the receiver 12 acquires each file and data for data broadcasting from the received broadcast signal, the receiver 12 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 system for transmitting broadcast signals from the broadcast transmission system 11 to the receiver 12 . FIG. 2 shows a stack model 200 of a broadcast signal configuration example in this case.

At the lowest layer of stack model 200 is physical layer (PHY) 201 . The physical example 201 includes modulation schemes, error correction schemes, and the like.

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

An MMT packet 207, an NTP (Network Time Protocol) packet 208 containing current time information, and the like are placed on the UDP 204. FIG. The MMT Protocol (MMTP) is an application layer transport protocol for transmitting MMTP payloads 209 over IP networks.

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

FIG. 3 shows a configuration example of the broadcast transmission system 11 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 comprises a system 308 , a TLV signaling encoder 309 , an IP service multiplexer (MUX) 310 , a TLV multiplexer (MUX) 311 and a modulation and transmission unit 312 .

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

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

The video encoder 303 encodes the video signal sent from the signal sending unit 302 , packetizes it, and sends IP packets including video MMT packets to the IP service multiplexer 310 . The audio encoder 304 also encodes the audio signal sent from the signal sending unit 302 , further packetizes it, and sends IP packets including audio MMT packets to the IP service multiplexer 310 . The caption encoder 305 also encodes the caption signal sent from the signal sending unit 302 , packetizes it, and sends IP packets including caption MMT packets to the IP service multiplexer 310 .

The signaling encoder 306 generates a signaling message related to data broadcasting based on information sent from the information system 308, and converts an IP packet including an MMT packet in which the signaling message is placed in the payload portion to IP service multiplexing. to processor 310. In this embodiment, signaling messages related to data broadcasting are roughly classified into three types: PA messages, M2 section messages, and data transmission messages. In this embodiment, information designating forced caching of 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 sent from the signal sending unit 302 or the information system 308 as necessary, generates MMT packets containing the file data, and converts IP packets containing the MMT packets. Send to IP service multiplexer 310 . The file data constitute 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. One-channel IP service multiplexer 310 multiplexes IP packets containing video, audio, subtitles, signaling messages, and file data sent from each encoder 303-307 into one Generate the TLV packets that make up the channel.

The TLV signaling encoder 309 encodes signaling information sent from the information system 308 to generate TLV packets to be placed in the payload section.

The TLV multiplexer 311 multiplexes the TLV packets generated by each IP service multiplexer 310-1 to 310-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 the result 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 obtained from the NTP server, and generates IP packets containing this time information.

A video signal sent from the signal sending unit 302 is supplied to the video encoder 303 . At the video encoder 303, the video signal is encoded and further packetized to generate IP packets containing MMT packets of the video. This IP packet is sent to IP service multiplexer 310 .

Similar processing is also performed on the audio signal and caption signal sent from the signal sending section 302 . Then, the IP packets including the audio MMT packets generated by the audio encoder 304 are sent to the IP service multiplexer 310, and the IP packets including the caption MMT packets generated by the caption encoder 305 are sent to the IP service. • sent to the multiplexer 310;

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

File data sent from the signal sending unit 302 or the information system 308 is supplied to the file encoder 307 . The file encoder 307 divides the file data as necessary, generates MMT packets containing the file data, and generates IP packets containing these MMT packets. This IP packet is sent to IP service multiplexer 310 .

Each IP service multiplexer 310 multiplexes IP packets including video, audio, subtitles, signaling messages, and file data sent from each encoder 303-307 to form one channel. A TLV packet is generated to

The TLV signaling encoder 309 encodes the signaling information sent from the information system 308 to generate TLV packets to be placed in the payload section.

The TLV multiplexer 311 multiplexes the TLV packets generated by the IP service multiplexers 310-1 to 310-N and the TLV signaling encoder 309 to generate a broadcast stream. The modulation/transmission unit 312 performs RF modulation processing on the broadcast stream generated by the TLV multiplexer 311, and outputs the RF modulated signal to the RF transmission line.

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

A tuner/demodulator 401 receives the RF modulated signal and performs demodulation processing to obtain a broadcast stream. The demultiplexer 402 performs demultiplexing and packetization processing on this broadcast stream, and extracts NTP time information, PTS (Presentation Time Stamp), signaling information, video related to the main part of the broadcast program. , audio and caption coded signals, file data used for data broadcasting linked to broadcast programs, and signaling information. The file data used for data broadcasting is, for example, a data broadcasting application described in HTML5 format.

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

The application data control unit 407 processes each file data used in data broadcasting. In this embodiment, it is assumed that each file and data used in data broadcasting are transmitted from two systems, a broadcast signal and an IP network. The application data control unit 407 acquires them via the IP interface 412 . The application data control unit 407 controls processing of acquired file data based on signaling information output from the demultiplexer 402 . Specifically, the application data control unit 407 manages which data broadcasting presentation unit (Presentation Unit: PU) the user is currently in, and processes the corresponding file data (data broadcasting application such as HTML5) in the HTML browser. and so on to the data broadcasting application engine 409 . The datacasting application engine 409 processes datacasting applications using pre-cached or pre-cached file data 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, M2 section message, and data transmission message, identifies the access range required for presenting data broadcasting, and It controls filtering operations for pre-caching cacheable file data in cache memory 408 in broadcast application engine 407 . The details of pre-caching of file data will be given later.

Also included in the data transmission message is information specifying forced caching of each file used in data broadcasting. In this embodiment, the application data control unit 407 stores file data necessary for timely presentation of data broadcasting in the cache memory based on the forced cache information included in the data transmission message. 408 pre-cache. The details of pre-caching of file data will be given later.

In the broadcast stream, file 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 the necessary data in the demultiplexer 402 from the file data group repeatedly sent. make it

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. Based on the NTP time information obtained by the demultiplexer 402, the clock unit 403 generates time information synchronized with this time information.

Also, the system control unit 410 controls the decoding timings of the decoders 404 to 406 based on the PTS, and adjusts the presentation timings of the video, audio, and subtitles. The synthesizing unit 411 synthesizes the caption display signal and the data broadcasting display signal with the baseband video signal to obtain a video signal for image display. Also, the baseband audio signal obtained by the audio decoder 405 becomes an audio output audio signal. A main broadcast program consisting of a video signal and an audio signal is output as video and audio from a monitor display (not shown). The data broadcast processed by the data broadcast application engine 409 is also superimposed on the screen of the main part of the broadcast program and displayed on the monitor display.

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

The tuner/demodulator 401 receives the RF modulated signal, demodulates it, and obtains a broadcast stream. Demultiplexer 402 demultiplexes and packetizes this broadcast stream, and converts NTP time information, PTS, signaling information, video, audio, and caption coded signals, and file/ Data is extracted.

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

The encoded video signal extracted by the demultiplexer 402 is sent to the video decoder 404 and decoded to obtain a baseband video signal. Also, the encoded caption signal extracted by the demultiplexer 402 is sent to the caption decoder 406 and decoded to obtain a caption display signal. Also, the file data extracted by the demultiplexer 402 is sent to the data broadcasting application engine 407 and processed to obtain a data broadcasting display signal. Note that the system control unit 410 controls the filtering operation in the demultiplexer 402 so that the demultiplexer 402 acquires only necessary file data.

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

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

On the other hand, the application data control unit 407 manages which data broadcasting presentation unit the user is currently in, 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 datacasting application engine 409 processes datacasting applications using pre-cached or pre-cached file data in the cache memory 408 as appropriate. The data broadcast processed by the data broadcast application engine 409 is also superimposed on the screen of the main part of the broadcast program and displayed on the monitor display.

Application data control unit 407 also refers to signaling tables included in each of the PA message, M2 section message, and data transmission message, and distributes file data according to the free space in cache memory 408. It controls advance caching and forced caching for timely presentation of data broadcasting in conjunction with broadcast programs (described later).

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

The broadcast signal of one channel (broadcast program) consists of 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 constructed and encoded are stored in the MPU and transmitted. Information related to transmission control of these broadcast signals is also transmitted as signaling information. In MMT, it is easy to use timed media data and non-timed media data constituting one channel (broadcast program) by combining different transmission paths. In the example shown in FIG. 5, as a broadcast signal 500, MMT transmission paths 501 to 504 are used for each type of data such as video, audio, subtitles, file data, and signaling information. In the figure, the illustration of the transmission path for caption data is omitted for the sake of convenience.

One channel (broadcast program) can be said to be a "package" consisting of multiple assets of different types such as video, audio, subtitles, file data (data application) (a package uses an MMT transmission path). is a logical collection of media data transmitted over a network). Each asset is a set (logical group) of one or more MPUs sharing the same asset_id (asset identifier), and each is transmitted on a dedicated ES (Elementary Stream), that is, an MMT transmission path (an asset is a unique is an entity of data associated with an identifier and used to organize a multimedia presentation). That is, the transmission path 501 transmits video MMT packets (MMTP) composed of MPU logical groups having a common asset_id, and the transmission path 502 transmits audio MMT packets composed of MPU logical groups having a common asset_id. , the transmission path 503 transmits MMT packets of file data composed of MPU logical groups having a common asset_id. An MPU is identified by an asset_id and a sequence number of the MPU on the corresponding transmission path. Also, the MMT transmission line that transmits each medium can be identified by asset_id.

In addition, a single package (broadcast program) may transmit multiple assets of the same type (that is, with different asset_ids). For example, two or more file contents (data broadcasting applications) are provided for the same broadcast program. In such a case, different file contents will be assigned different asset_ids and transmitted over different MMT transmission paths as different MPU logical groups. In FIG. 5, only one transmission path 503 for file data is drawn for simplification.

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

Also, on the transmission line 504, MMT packets containing the same signaling message are repeatedly transmitted. Three types of signaling messages are involved in implementing the techniques disclosed herein: PA messages 510, M2 section messages 520, and data transmission messages 530. Signaling tables are transmitted in various signaling messages. For example, PA message 510 includes MP (MMT Package) table 511 . Also included in the M2 section message 520 is an MH AI (Application Information) table 521 . A data transmission message 530 is a message for notifying a data transmission method and a data management control method. - Each signaling table of the management table 533 is included. Details of each table will be given later.

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

A packet counter flag "C" indicated by reference numeral 601 is assigned a value of 1 to indicate that a packet counter field indicated by reference numeral 602 is present in this MMTP packet. A packet counter 602 is a 32-bit long field in which an integer value counting MMTP packets is written, and is incremented by 1 each time an MMTP packet is transmitted.

When 1 is assigned to the extension flag “X” indicated by reference number 603, it indicates that the extension header 604 indicated by reference number 604 is present. A configuration example of the extension header 604 is also shown at the bottom of FIG. The extension header 604 is composed of a 16-bit length type field indicated by reference number 604-1, a length field indicated by reference number 604-2, and a header_extension_value field indicated by reference number 604-3. The length field is written with the byte length of the header_extension_value field. Extension information outside the MMT specification can be written in the header_extension_value field.

A type field indicated by reference numeral 606 is written with a type value representing the type of payload data of the MMTP packet. The definitions of the type values are shown in Table 1 below.

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

A 16-bit packet_id field indicated by reference number 607 is written with an integer value for distinguishing the asset. The value of this field comes from the asset_id of the asset to which the MMTP packet belongs. The mapping between packet_id and asset_id is indicated in the MMT Package (MP) table which is part of the signaling message.

A 32-bit timestamp field indicated by reference number 608 describes the transmission time of the MMTP packet in the short-format defined by the NTP protocol.

A 32-bit packet_sequence_number field indicated by reference number 609 describes an integer value (sequence number on the MMT transmission path) for identifying packets having the same packet_id.

FIG. 7 shows a configuration example of an extension header 700 for an MMTP packet that transmits non-timed media. As shown, in this case, the length field 701 is written with 4 as the byte length of the header_extensin_value field. The download_id is written in 4 bytes in the header_extension_value field 702 .

When transmitting an MPU using the MMT protocol, packetization and depacketization are required at the sender and receiver, respectively. With packetization, the MPU is inserted into the MMTP payload and transmitted in the MMTP packet. The MMTP payload format allows fragmentation of the MMTP payload so that transmission of large payloads is possible. The MTP payload format also allows aggregation of multiple MMTP payloads into a single MMTP payload, corresponding to a small data unit. The receiving side depacketizes and restores the original MPU data.

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

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

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

The Fragmentation Identifier (f_i) field indicated by reference number 803 represents information about the fragmentation of the data unit in the payload with 2 bits. The four values of f_i are defined in Table 3 below.

When the payload is an aggregation of multiple data units, the aggregation (A) flag indicated by reference numeral 804 is set to 1.

An 8-bit long fragment_counter field indicated by reference numeral 805 describes the number of payloads containing fragments of the same data unit followed by the MMTP payload in question.

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

DU_Header, indicated by reference number 807, is the header of the data unit. However, when the FT value 801 is 0 or 1 (in other words, not MFU), there is no DU_Header 807 . An MFU may contain samples or sub-samples of timed media or items of non-timed media.

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

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

FIG. 11(a) shows the state of the original file data. In the figure, F1 and F2 are each one file data. File data is, for example, an HTML document and contains one or more items. Also, the HTML document itself is an item.

FIG. 11(b) 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 placed as it is in the payload of one MFU. On the other hand, since the file data F2 has a large file size, it is divided into a plurality of pieces, each of which is placed 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 the payload of another MFU.

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

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

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

Furthermore, 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 illustration is omitted, TLV packets forming a broadcast stream are generated by attaching a TLV header to each IP packet.

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

Next, the construction of signaling messages used in the MMT protocol, which is relevant for implementing the technology disclosed in this specification, will be described. The signaling message is signaling information required for package transmission control and package use, and transmits various signaling tables.

MMT signaling messages use a general format consisting of three common fields, one specific field per signaling message type, and the message payload. A message payload carries signaling information. The PA message, the M2 section message, and the data transmission message are described below in this order.

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

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 even some of the parameters that make up the MP table are updated, the version is incremented by +1. length is a 32-bit long parameter that indicates the size of the PA message in bytes, counted immediately after this field.

Index information of the MP table (MPT) arranged in the payload field is arranged in the extension field. This field contains an 8-bit table_id, an 8-bit table_version, and a 16-bit table_length. 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.

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

FIGS. 15 and 16 show examples of MP table syntax (FIG. 16 is the second half following FIG. 15). Also, FIG. 17 shows an explanation of the parameters included in the MP table. The configuration of the MP table will be described below.

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

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

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

number_of_assets is an 8-bit parameter that indicates the number of assets (signals, files) that constitute the package. The following Asset loops are arranged by the 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 as information of individual assets is arranged.

asset_id is text information that uniquely identifies an asset. asset_id_len indicates the size of asset_id in bytes. gen_loc_info is information indicating the location of the acquisition destination of the asset. In this embodiment, gen_loc_info is described in the format of packet id on the transmission path from which the asset is acquired. Therefore, by looking up asset_id on the MP table, it is possible to retrieve the corresponding packet ID on the MMT transmission path.

The asset_descriptor field is a storage area for descriptors related to assets. asset_descriptor_length indicates the size N5 of the asset_descriptor field in bytes. Asset_descriptor prescribes descriptors for various purposes, and assumes that N5 pieces (one or more) are arranged.

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

message_id (message identification) is a 16-bit fixed value that identifies an M2 section message in various signaling information, and is 0x8000 in this embodiment. version is an 8-bit integer parameter that indicates the version of the M2 section message. length (message length) is a 16-bit length parameter indicating the size of the M2 section message in bytes, counted immediately after this field. table_id (table identification) is an area used to identify the table to which the section belongs. Section_syntax_indicator (section syntax indicator) shall be '1' indicating an extended format. section_length (section length) is an area in which the number of bytes of data following the section length area is written. table_id_extension (table identification extension) is an area for extending table identification. version_number (version number) is an area in which the version number of the table is written. The current_next_indicator (current/next indicator) is '1' if the table is currently available, and '0' if the table is currently unavailable and will be valid next. section_number (section number) is an area in which the section number constituting the table is written. last_section_number (last section number) is an area in which the last section number constituting the table is written. CRC32 (CRC), ITU-T Recommendation H. A cyclic redundancy code conforming to H.222.0.

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

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

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

application_loop_length is an area to write the number of application information included in this MH AI table. Then, loops of application information are arranged for the number indicated by application_loop_length.

In one application information loop, descriptor ( application information descriptor). The descriptors in this descriptor area apply only to the specified application.

application_identifier (application identifier) is a parameter that identifies an application. 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 application type value. If "autostart" is indicated as application_control_code, the receiver referring to this MH AT table starts the application specified by application_identifier. Also, if "prefetch" is indicated as application_control_code, the receiver referring to this MH AT table prefetches the application specified by application_identifier. Also, if "kill" is indicated as application_control_code, the receiver referring to this MH AT table stops executing the application specified by application_identifier. CRC32 (CRC), ITU-T Recommendation H. A cyclic redundancy code conforming to H.222.0.

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

FIG. 20 shows a configuration example of an application information descriptor 2000 stored in the application information loop of the MH AI table. Also, FIG. 21 shows an explanation of the parameters included in the application information descriptor 2000. As shown in FIG. 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 in question. descriptor_length is an area in which the number of bytes of data of the descriptor 2000 following this field is written.

Information of application_profile is written in a series of areas consisting of loops of the number of application_profile_length. application_profile is the profile of the receiver that can execute this application, and indicates the requested function with a bitmap for each function requested of the receiver. However, the upper 3 bits indicate function bitmap switching. The above bitmap is specified for each version. Also, version_major, version_minor, and version_micro are versions of the application profile definition, respectively.

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

Also, 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 explained below.

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

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

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

URL_base_byte stores text information indicating URL_base in the URL character string in a series of loops for the number of URL_base_length.

URL_extension_count indicates the number of URL_extensions following URL_base, and URL_extension loops are arranged for the number of URL_extension_count. In one URL_extension loop, URL_extension_byte stores text information indicating each URL_extension in a series of loops corresponding to the number of URL_extension_lengths that define the length of the URL_extension. Each URL_extension is a URL string following URL_base. For example, if the URL_base is "http://www.xbc.com" and the URL_extension is "index.html", concatenate these strings to get the complete URL "http://xbc.com/index .html" can be obtained.

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

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

message_id (message identification) is a 16-bit fixed value that identifies a data transmission message in various signaling information, and is 0xF000 in this embodiment. version is an area to write the version number of the data transmission message. length (message length) is a 32-bit parameter that indicates, in bytes, the size of the message data that follows this field.

num_of_tables indicates the number of tables stored in this data transmission message. A loop of table information is arranged as the table to be stored in the data transmission message and as many times as 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. table_id (table identification) is an area used to identify the table stored in this data transmission message. Data transmission messages carry three types of signaling tables: data asset management table (DAMT), data directory management table (DDMT), and data content management table (DCMT). (described above), the table_id (table identifier) identifies which of these tables it is. table_version (table version) indicates the version of the table stored in this data transmission message. table_length indicates the size of the table stored in this data transmission message in bytes.

Also, the number of table loops indicated by num_of_tables is arranged. Information on the content of the table identified by table_id is stored in the loop of one table. table indicates a table to be stored in this data transmission message.

FIG. 25 shows a configuration example of a data asset management table 2500 transmitted by a data transmission message. The data asset management table is a table for managing asset information of file data transmitted as MMTP packets and information of items included in each asset of file data. The meaning of each parameter of this data asset management table will be explained below.

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 0xA2 in this embodiment. version_ (version) is an 8-bit integer parameter indicating the version of this data asset management table. For example, if some of the parameters that make up the data asset management table are also updated, the version is incremented by +1. length is a 16-bit long parameter that indicates the size in bytes of this data asset management table, counting immediately after this field.

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

One asset information loop contains the download_id, information about the asset (file data) itself, and information about each item contained in the asset. download_id is identification information written in the extension header of the MMTP packet that transmits non-timed media (file data) (see FIG. 7).

Information about the asset itself stored in the asset information loop includes asset_ID_scheme, asset_ID_length, asset_ID_length, and asset_ID_byte. asset_ID_scheme indicates the format of asset_ID. As a format of 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. asset_ID_byte indicates asset_ID in a series of areas consisting of loops for the number of asset_ID_length in the format specified by asset_ID_scheme. Incidentally, in this embodiment, this information is used as information for identifying assets in common to the MP table and the data asset management table, but since the amount of data is large, other substitute asset identification information may be used. . For example, it is assumed that a 16-bit component_tag is defined as information corresponding to asset_ID in the MP table, and component_tag is used instead of asset_ID in the data asset management table.

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

Within 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 in non-timed MFU. node_tag is information for identifying an item, and is a 16-bit value. By using a 16-bit node_tag instead of a 32-bit item_ID as signaling information, the bit size required for item identification can be reduced. Note that node indicates each of the directory and items that are nodes on the directory structure that constitutes 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 version is incremented by +1 each time the content of the item is updated. item_checksum indicates the checksum of the item. It should be noted that the amount of information is considered to be large if the checksum is always set for all files. Thus, with such considerations, for example, a 1-bit check_sum_flag may be set such that the 32-bit item_check_sum appears only when 1 is assigned to it. Alternatively, instead of signaling, a checksum may be indicated as type as an extension header of the MMTP packet shown in FIG. 7, and a 32-bit checksum may be placed after length. 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 consisting of loops for the number of item_info_length.

descriptor_loop_length indicates the total byte length of descriptor. A descriptor stores descriptor information (descriptor( )) in a series of areas consisting of loops as many as descriptor_loop_length. Descriptors to be stored are defined separately.

In short, the data asset management table 2500 is a table that manages information related to assets of file data (contents) included in one package and items included in the assets. Item version information is also managed as information about the item. By referring to the data asset management table 2500, from the node_tag (or Item_ID), the downloadID or item_info described in the MMT extension header that transmits the corresponding asset_id or the asset is subtracted, or the node_tag handled on the transmission path of the signaling information. item_ID and item_info on the transmission path of file data can be subtracted from .

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

An 8-bit fixed value indicating a data directory management table in various signaling information is written in table_id (table identification). version_ (version) is an 8-bit integer parameter indicating the version of this data directory management table. For example, if some of the parameters that make up the data directory management table are also updated, the version is incremented by +1. length is a 16-bit long parameter that indicates the size in bytes of this data directory management table, counting 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 (higher level directory) in a series of areas consisting of loops for the number of base_folder_path_length. base_folder_path_byte is expressed in absolute URL format for accessing the corresponding directory, for example.

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

Information of each folder node described in the data directory management table and information of each file data included in the base folder are stored 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 for the number of folder_node_path_length. folder_node_path_byte is expressed in a relative URL format from base_folder_path for accessing the corresponding directory, for example. Although not shown, folder_node_version (folder node version information) may be included as folder node information. For example, if the path name (URL) of base_folder is "http://www.xbc.com" and the bus name (URL) of a certain folder_node is "index.html", concatenate these character strings, You can get the full URL "http://xbc.com/index.html".

num_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. node_tag represents information identifying an item transmitted in non-timed MFU with 16 bits shorter than 32-bit item_ID. Note that node indicates each of the directory and items that are nodes on the directory structure that constitutes 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 for the number of file_name_length.

In short, the data directory management table 2600 is a table for managing the directory structure related to directories contained in one package and subdirectories and files (items) contained in the directories. The data directory management table 2600 allows the file configuration of the data broadcasting application to be separated from the configuration for file transmission. Also, referring to the data directory management table 2600, it is possible to subtract the path name (URL) of the corresponding item from the node_tag, or conversely subtract the corresponding node_tag from the path name (URL). In this configuration example, in the data directory management table, the location information of the directory where the file exists is set as folder_path_byte, each directory is given identification information as node_tag, and the file name and node_tag are given as information for each item. is specified, the amount of information in folder_path_byte does not become too large.

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

A data content management table (DCMT) is a table for managing information of file data, ie content (data broadcasting application) transmitted as non-timed media. In this embodiment, the data content management table is transmitted including information specifying forced caching. Data broadcasting linked to broadcast programs requires timely presentation. In such a case, the data content management table (DCMT) from the broadcast transmission system 11 side includes information specifying the forced cache, so that the receiver 12 side can use the data broadcast linked to the broadcast program. Timely presentation of data broadcasting can be realized by pre-caching each file to be transmitted.

There are two methods for transmitting forced cache information using a data content management table (DCMT).

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

The file to be precached here is composed of, for example, a broadcast file list that forms a data broadcast presentation unit (PU) to be referred to next from the current data broadcast presentation unit (PU). On the broadcast program production side, by presenting the file list to be pre-cached in data broadcasting signaling information in this way, the receiver side pre-caches the files and data necessary for the next data broadcasting presentation unit. It is possible to perform a cache control operation by pre-cache. As a result, a timely data broadcasting service linked to broadcast programs can be realized.

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

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

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

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

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

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

number_of_PU is the number of data broadcasting presentation units PU included in the content, and PU loops are arranged for the number of number_of_PUs.

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

Also, in the loop of the PU, a list of broadcast transmission files (member items) constituting the data broadcast 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, the number of nodes that are members of the PU). After that, the number of PU member node loops corresponding to this number_of_PU_member_nodes are arranged, and the node_tag of the PU member node is written in the loop of each PU member node. PU member nodes include directory nodes and item nodes.

Also, in the loop of the PU, if there is a file to be pre-cached 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 precached, and loops of precache nodes corresponding to the number of number_of_pre_cache_nodes are arranged. A pre_cache_node_tag that identifies the precache node is written in the loop of one precache node.

The file to be precached here is composed of, for example, a broadcast file list that forms a data broadcast presentation unit (PU) to be referred to next from the current data broadcast presentation unit (PU). On the broadcast program production side, by presenting the file list to be pre-cached in data broadcasting signaling information in this way, the receiver side pre-caches the files and data necessary for the next data broadcasting presentation unit. can be kept. As a result, a timely data broadcasting service linked to broadcast programs can be realized.

Also, in the loop of one PU, a number_of_linked_PU indicating the number of other PUs linked from this PU and loops of linked_PUs corresponding to the number_of_linked_PU are arranged. Within 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 a data content management table (DCMT) 2800 transmitted by a data transmission message that implements method 2. As shown in FIG.

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

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

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

number_of_PU is the number of data broadcasting presentation units PU included in the content, and PU loops are arranged for the number of number_of_PUs.

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

Also, in the loop of the PU, a list of broadcast transmission files (member items) constituting the data broadcast 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, the number of nodes that are members of the PU). After that, the number of PU member node loops corresponding to this number_of_PU_member_nodes are arranged, and the node_tag of the PU member node is written in the loop of each PU member node. PU member nodes include directory nodes and item nodes.

In addition, in the loop of the PU, in the corresponding PU, there are a file to be locked in the cache memory 408 (lock cache item) and a file to be unlocked among the locked objects (unlock cache item). Describe the information of Specifically, number_of_lock_cache_nodes is the number of nodes to be precached, and after that, loops of lock target nodes for the number of number_of_lock_cache_nodes are arranged. A lock_cache_node_tag for identifying a lock target node is written in the loop of one lock target node. Also, number_of_unlock_cache_nodes is the number of nodes to be precached, and after that, loops of unlock target nodes corresponding to the number of number_of_unlock_cache_nodes are arranged. An unlock_cache_node_tag for identifying an unlock target node is written in the loop of one unlock target node.

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

Also, in the loop of one PU, a number_of_linked_PU indicating the number of other PUs linked from this PU and loops of linked_PUs corresponding to the number_of_linked_PU are arranged. Within 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 one package in units of data broadcasting presentation (PU). , the PU_tag of the data broadcasting presentation unit including the node can be acquired. It also has an aspect of controlling forced caching of data broadcast files 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 given later.

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

FIG. 29(A) shows the directory structure of the content. Each content content1, 2, . . . consists of a data broadcasting application (app) and material. Data broadcasting applications and materials are resources each of which has file data as an entity. Each resource corresponds to an item that is a component of an asset on the MMT transmission line, and can be identified by a 32-bit item_ID. Also, within the signaling information, an 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 line of the relevant asset (described later). An application consists of one or more HTML documents that are referenced when content is executed (when data broadcasting is presented). Materials are monomedia data such as jpeg images and texts referenced from HTML documents. One HTML document and materials referenced from it constitute one data broadcasting presentation unit PU. In the example shown in FIG. 29A, content1 is A11. html, A12. html, A13. It has one or more HTML documents such as html as resources of the data broadcasting application. Of these, A11. html is a resource that is directly referenced when the content is executed.

FIG. 29(B) shows reference relationships between resources at the time of content execution (at the time of presentation of data broadcasting). In the illustrated example, the application A11, which is directly referred to when the content is executed, and the materials B11 and B02 referred to by the application A11 form a resource group 2801 forming one data broadcasting presentation unit PU, and p1 is assigned as the PU_tag ( Note that B14 is material that can be obtained at any time not by MMT transmission by broadcasting but by HTTP transmission by communication, and is not included in the resource group of the data broadcasting presentation unit below).

Similarly, application A12 and materials B12, B02, and B13 referred to by application A12 form a resource group 2802 that constitutes one data broadcasting presentation unit PU, and p2 is assigned as PU_tag (B07 is MMT It is material that is not transmitted but can be acquired at any time by HTTP transmission through communication, and hereinafter, it is treated as not included in the resource group of the data broadcasting presentation unit). Similarly, application A01 and materials B03, B01, and B04 referred to by application A01 form resource group 2803 forming one data broadcasting presentation unit PU, and p3 is assigned as PU_tag.

In addition, it is possible to have a link reference relationship between multiple HTML documents (well-known). In the example shown in FIG. 29B, resource A11. html is an HTML document that describes the application presentation screen that is directly referenced and initially displayed when the content is executed. On the other hand, resource A12 . html and resource A01. html is A11. is an HTML document describing an application presentation screen transitioned from a screen presented by executing A11. It has a link reference relationship with html. Each resource A11. html, A12. html, A01. html forms resource groups 2801, 2802, 2803 each constituting one data broadcasting presentation unit PU. Data broadcasting presentation units 2801, 2802, and 2803 that are linked together constitute a large resource group 2810 of a higher order. Resource A11. html, A12. html, A01. html is the central file data (primary item_node) in each data broadcasting presentation unit PU.

In addition, the entire content, which is the entire application included in the package (one broadcast program), constitutes a large resource group, that is, the entire data content. The entire data content is a range of data broadcast presentation units PU having a common content_ID. All data broadcasting presentation unit PUs included in the content can be collectively specified by looping the PUs of the corresponding content_ID in the data content management table. In the example shown in FIG. 29B, applications included in content1 and common form a resource group 2820 for the entire content.

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

Also, resources included in the same content share the same asset_ID and are transmitted on the same MMT transmission path. In the example shown in FIG. 29C, items with Item_IDs i11, i12, i13, and i14 share a1 as the same Asset_ID and are transmitted on the same MMT transmission line. 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). are represented and will be related by item_ID or node_tag between them.

Referring to FIG. 30, the reference relationship of each table transmitted as signaling information when acquiring the data broadcasting application (content) from the MMT transmission line will be described.

When receiving the MH-AI table (MH AIT) 2901 with the M2 section message, the receiver 12 refers to application_control_code to confirm how the application state is controlled. Then, if "autostart" is specified, refer to the transport_protocol_label in the table to confirm that MMT transmission is specified, then the item (file data) that is directly referenced when presenting this application from the transmission protocol descriptor. The receiver then refers to the data directory management table (DDMT) 2902 sent in the data transmission message to obtain the node_tag of the item corresponding to the combination of 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 line, 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 asset_ID, on the MMT transmission path of the file data, the header of the MMTP packet You can filter based on the packet_id, the download_id in the extension header, and the item_ID in the DU header to get the desired item (to be referenced directly when presenting the application).

Also, the receiver 12 pulls the node_tag acquired from the data directory management table 2902 in the data content management table (DCMT) 2905 sent in the data transmission message, and extracts the corresponding application The PU_tag of the presentation unit can be retrieved. Further, by passing a linked_PU loop within the PU loop of this PU_tag, the PU_tag of other application presentation units linked to this can be taken out collectively.

FIG. 31 schematically shows a mechanism for caching file data used for data broadcasting within the receiver. Caching here includes caching and pre-caching file data for execution.

Application data control section 407 analyzes the signaling message demultiplexed from the broadcast stream by demultiplexer 402 and controls the operation within the receiver. As for 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 contained in the data content management table. do.

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

The application data control unit 407 looks up the node_tag of the file data to be pre-cached in the data asset management table transmitted in the data transmission message, acquires the asset_ID of the asset to which the node belongs, and then , asset_ID in the MP table transmitted in the PA message to obtain the packet_id of the MMTP packet in which the asset is transmitted. Further, when the system control unit 408 acquires the download_id described in the extension header of the MMTP packet that transmits the desired item from the data asset management table, the MMTP packet header on the MMT transmission line of the file data. , the download_id in the extension header, and the item_ID in the DU header to obtain the desired item entity and pre-cache it in the cache memory 408 .

When the data broadcasting application engine 409 executes the application, if the required items (file data) have already been pre-cached in the cache memory 408, they are demultiplexed from the broadcast stream in the demultiplexer 402. Without waiting for the file data to arrive, it can be retrieved from the cache memory 408 and rapidly responded to generate the display signal for data broadcasting. 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 arrival of the file data demultiplexed from the broadcast stream and responds by sending the data broadcasting display signal. to generate

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

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

In 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. A data content management table (DCMT) 2700 includes, for each data broadcasting presentation unit (PU), a broadcast transmission file (member item) list and a central file (primary item) that constitute a presentation unit, and pre-cache data. If the target file exists, describe the information of the target file list (pre-cache item). Therefore, on the receiver 12 side, the following cache control operation can be performed by pre-cache.

(Operation 01) The application data control unit 407 appropriately detects and updates data transmission messages transmitted on the MMT transmission line 504, and acquires the latest information.
(Operation 02) The application data control unit 407 accesses the application file (which is the center of the data broadcasting presentation unit) designated as the primary_item by an instruction from the data broadcasting application control engine 409 or the like, thereby displaying the corresponding data. It recognizes that it has entered the presentation state of a broadcast presentation unit (PU).
(Operation 03) The application data control unit 407 creates each member file (PU_member_node ) are also acquired at the same time and held in the cache memory 408 .
(Operation 04) Furthermore, 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 Each file (item) to be cached is also obtained and pre-cached in cache memory 408 .
(Action 05 ) The data broadcasting application engine 409 executes the application file specified in primary_item from the cache memory 408 .
(Operation 06) After that, by updating the data content management table (DCMT), the configuration of the member files (PU_member_node) included in the data broadcasting presentation unit (PU) currently being presented and the files to be precached are changed. When it changes, or when the presentation state of another data broadcasting presentation unit (PU) transitions due to an application operation in the data broadcasting application engine 409, in the data broadcasting presentation unit (PU) currently in the presentation state, The processes of (operation 03) to (operation 05) are performed. Even if the files were held in the cache memory 408 in the previous state, the application data control unit 407 deletes unnecessary files from the cache memory 408 in the current state.

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

When data broadcasting application control engine 409 is performing an application operation, that is, presenting data broadcasting (Yes in step S3201), application data control section 407 registers primary_item (data broadcasting presentation unit) in the data content management table. ) (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 currently presented data broadcasting presentation unit (PU) and each member file (PU_member_node ) and holds it in the cache memory 408 (step S3203). Data broadcasting application engine 409 executes the application file specified in primary_item from cache memory 408 .

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

After that, when the configuration of the member files (PU_member_node) included in the data broadcasting presentation unit (PU) currently being presented and the files to be precached change due to the update of the data content management table (DCMT) (Yes in step S3206), the process returns to step S3203, and the above processing is repeatedly executed in the data broadcasting presentation unit (PU) currently in the presentation state.

Further, when the application operation in the data broadcasting application engine 409 transitions to the presentation state of another data broadcasting presentation unit (PU), and the application file specified in the primary_item of the data broadcasting presentation unit is accessed (step Yes in S3207), the process returns to step S3203, and the above processing is repeatedly executed in the data broadcasting presentation unit (PU) to which the transition is made.

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

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

Application data control unit 407 analyzes various signaling messages received on MMT transmission path 504 . A data transmission message, one of the signaling messages, contains 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, The application file "A01.html" designated as the primary_item (the 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", When the node_tag of each "B02" is obtained from the data content management table and the entity of the file data corresponding to these node_tags is obtained from the MMT transmission path 503 that transmits the data asset, reference number 3301 It is cached in cache memory 408 as shown. The method of accessing the file transmitted on the MMT transmission line 503 from the node_tag has already been described with reference to FIG. 30 (same hereafter). However, since the target of pre-cache is not specified for this data broadcast presentation unit (PU), no pre-cache operation is performed.

Next, assume that an 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 selects the application file "A11.html" specified as the primary_item (the center of the data broadcasting presentation unit) of the data broadcasting presentation unit (PU_id=3) to which the transition is made, and , and each member file (PU_member_node) 'B11', 'B12', and 'B13'. A tee is obtained and cached in cache memory 408 as indicated by reference number 3302 . However, since the target of pre-cache is not specified for this data broadcast presentation unit (PU), no pre-cache operation is performed.

Application data control unit 407 constantly analyzes various signaling messages received on MMT transmission path 504 . Then, as indicated by reference number 3303, upon detecting that the version of the data content management table has been updated from 1 to 2, the application data control unit 407 updates 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 precached. Since there is no change in the member files this time, each member file previously cached is kept in the cache memory 408 . In addition, since "A12", "B14", and "B15" are added as files to be precached in data broadcast presentation units (PU_id=3), application data control section 407 outputs these files from MMT transmission path 503. , the entity of the file data corresponding to the node_tag of .

Then, as indicated by reference number 3305, upon receiving an event message from the MMT transmission line 504 instructing an update of the presentation of the data broadcasting, the data broadcasting application engine 409 converts the HTML from the A11 file being executed 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 replaces the primary_item of the data broadcasting presentation unit (PU_id=3) currently being presented. changed to "A12.html" and the member files changed to "B14", "B15", and "B16". As described above, the primary_item "A12.html" and the member files "B14" and "B15" have already been precached in the cache memory 408. The data broadcast can be quickly displayed using the held file. That is, it is possible to present timely data broadcasting linked to broadcast programs. Also, since "B12" has been added as a file to be precached in the data broadcast presentation unit (PU_id=3), application data control unit 407 transmits the file data corresponding to that node_tag from MMT transmission path 503. The entity is obtained and cached in cache memory 408 as indicated by reference number 3306 .

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

In 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. A data content management table (DCMT) 2800 contains, for each data broadcasting presentation unit (PU), a broadcast transmission file (member item) list and a central file (primary item) that constitute the presentation unit, and a cache lock. The information of the target file (lock cache item) to be locked and the target file (unlock cache item) to be unlocked among the lock targets is described. Therefore, the receiver 12 side can perform cache control operations by locking and unlocking the cache as described below.

(Operation 11) The application data control unit 407 appropriately detects the data transmission message transmitted on the MMT transmission line 504 and updates it to acquire the latest information.
(Operation 12) The application data control unit 407 accesses the application file (which is the center of the data broadcasting presentation unit) designated as the primary_item by an instruction from the data broadcasting application control engine 409 or the like, thereby displaying the corresponding data. It recognizes that it has entered the presentation state of a broadcast presentation unit (PU).
(Operation 13) The application data control unit 407 adds each member file (PU_member_node ) are also acquired at the same time and held in the cache memory 408 .
(Operation 14) Furthermore, if the data content management table specifies a lock cache target for the corresponding data broadcast presentation unit (PU), the application data control unit 407 Each file (item) that has not yet been acquired among the cache targets is also acquired, cached in the cache memory 408, and managed separately as lock cache target files.
(Operation 15) Conversely, if the corresponding data broadcast presentation unit (PU) is designated as an unlock cache target in the data content management table, the application data control unit 407 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 primary_item from the cache memory 408. FIG.
(Operation 17) After that, by updating the data content management table (DCMT), the structure of the member files (PU_member_node) included in the data broadcasting presentation unit (PU) currently being presented and the files to be precached are changed. If changed, the above-described (operation 13) to (operation 16) are performed.
(Operation 18) When the application operation in the data broadcasting application engine 409 transitions to the presentation state of another data broadcasting presentation unit (PU), the file to be locked and cached is temporarily held in the cache memory 408, and then The processes of (operation 13) to (operation 16) are performed. Files other than lock cache targets may be deleted from the cache memory 408 .

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

When data broadcasting application control engine 409 is performing an application operation, that is, presenting data broadcasting (Yes in step S3401), application data control section 407 registers primary_item (data broadcasting presentation unit) in the data content management table. ) (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 currently presented data broadcasting presentation unit (PU) and each member file (PU_member_node ) and holds it in the cache memory 408 (step S3403). Data broadcasting application engine 409 executes the application file specified in primary_item from cache memory 408 .

Also, the application data control unit 407 checks whether or not a lock cache target is specified for the corresponding data broadcast presentation unit (PU) in the data content management table (step S3404). Then, if the lock cache target is specified (Yes in step S3404), the application data control unit 407 also acquires each file (item) that has not yet been acquired among the lock cache targets, and stores it in the cache memory. 408 and separately managed as a lock cache target file (step S3405).

Also, the application data control unit 407 checks whether or not an unlock cache target is specified for the corresponding data broadcast presentation unit (PU) in the data content management table (step S3406). . If the unlock cache target 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 files (PU_member_node) included in the data broadcasting presentation unit (PU) currently being presented and the files to be precached change due to the update of the data content management table (DCMT) (Yes in step S3408), the process returns to step S3403, and the above processing is repeatedly executed in the data broadcasting presentation unit (PU) currently in the presentation state.

Further, when the application operation in the data broadcasting application engine 409 transitions to the presentation state of another data broadcasting presentation unit (PU), and the application file specified in the primary_item of the data broadcasting presentation unit is accessed (step Yes in S3409), the process returns to step S3403, and the above processing is repeatedly executed in the data broadcasting presentation unit (PU) to which the transition is made.

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

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

Application data control unit 407 analyzes various signaling messages received on MMT transmission line 504 . A data transmission message, one of the signaling messages, contains 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, The application file "A01.html" designated as the primary_item (the 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", When the node_tag of each "B02" is obtained from the data content management table and the entity of the file data corresponding to these node_tags is obtained from the MMT transmission line 503 that transmits the data asset, reference number 3501 It is cached in cache memory 408 as shown. The method of accessing the file transmitted on the MMT transmission line 503 from the node_tag has already been described with reference to FIG. 30 (same hereafter). However, since the lock cache target is not specified for this data broadcast presentation unit (PU), no cache operation is performed.

Next, assume that an 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 selects the application file "A11.html" specified as the primary_item (the center of the data broadcasting presentation unit) of the data broadcasting presentation unit (PU_id=3) to which the transition is made, and , and each member file (PU_member_node) 'B11', 'B12', and 'B13'. A tee is obtained and cached in cache memory 408 as indicated by reference numeral 3502 . However, since the lock cache target is not specified for this data broadcast presentation unit (PU), no lock cache operation is performed.

Application data control unit 407 constantly analyzes various signaling messages received on MMT transmission path 504 . Then, as indicated by reference number 3503, upon detecting that the version of the data content management table has been updated from 1 to 2, the application data control unit 407 updates the data broadcasting presentation unit ( Check whether the primary_item of PU_id=3), each member file, and the lock cache target file have been changed. Since there is no change in the member files this time, each member file previously cached is kept in the cache memory 408 . Also, since "A12", "B14", "B12", and "B15" have been added as files to be locked and cached in data broadcast presentation units (PU_id=3), application data control unit 407 performs MMT transmission. File data entities corresponding to these node_tags are acquired from the path 503 and cached in the cache memory 408 as indicated by the reference number 3504, and separately managed as lock-cache target files. In the figure, files managed as lock cache targets are underlined (same below).

Then, as indicated by reference numeral 3505, upon receiving an event message from the MMT transmission line 504 instructing an update of the presentation of the data broadcasting, the data broadcasting application engine 409 converts the HTML from the A11 file being executed 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 replaces the primary_item of the data broadcasting presentation unit (PU_id=3) currently being presented. changed to "A12.html" and the member files changed to "B14", "B15", and "B16". As described above, the primary_item "A12.html" and the member files "B14" and "B15" are already lock-cached in the cache memory 408, so the data broadcasting application engine 409 stores The data broadcast can be quickly displayed using the held file. That is, it is possible to present timely data broadcasting linked to broadcast programs. Also, since the target of lock cache is not specified for this data broadcast presentation unit (PU), no lock cache operation is performed. As indicated by reference number 3506, lock-cached files "A12", "B14", "B12", and "B15" are retained in cache memory 408 as they are, while file "A11", which is no longer needed, is deleted. It is

Furthermore, when an event message instructing updating of 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 currently presented data broadcasting. For the presentation unit (PU_id=3), "B17" is added as a lock cache target file, and "B14" is added as an unlock target file. Therefore, as indicated by reference 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 path 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 excluded from being locked.

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

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

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

The technology disclosed in this specification can be applied to various broadcasting systems that employ MMT as a transport method. Also, the technology disclosed in this specification can be applied to various data broadcasting systems that transmit file data used for data broadcasting linked to broadcast programs by the MMT method or other transport methods.

In short, the technology disclosed in this specification has been described in the form of an example, and the contents of this specification should not be construed in a limited manner. In order to determine the gist of the technology disclosed in this specification, the scope of claims should be considered.

It should be noted that the technology disclosed in this specification can also be configured as follows.
(1) a file data transmission unit that transmits file data used in data broadcasting;
a signaling message transmission unit that transmits signaling related to data broadcasting including forced cache information specifying forced cache of file data;
A transmitting device comprising:
(2) The signaling/message transmitting unit transmits, for each data broadcasting presentation unit, a data message describing information on a broadcast transmission file list and a main file that constitute the presentation unit, and a pre-cache target file list. send a data transmission message containing the content management table;
The transmission device according to (1) above.
(3) For each data broadcasting presentation unit, the signaling/message transmitting unit includes: a broadcast transmission file list that constitutes the presentation unit; a main file; a file to be locked in the cache; send a data transmission message containing a data content management table describing information about
The transmission device according to (1) above.
(4) further comprising a media data transmission unit that transmits media data of a broadcast program main body linked with data broadcasting;
The transmitter according to any one of (1) to (3) above.
(5) a file data transmission step of transmitting file data used in data broadcasting;
a signaling message transmission step of transmitting signaling related to data broadcasting including forced cache information designating forced cache of file data;
Sending method with
(6) a file data receiving unit for transmitting file data used in data broadcasting;
a signaling message receiver that transmits signaling related to data broadcasting including forced cache information specifying forced cache of file data;
a control unit for controlling caching of the file data received by the file data receiving unit in a cache memory based on the forced cache information;
A receiving device comprising:
(7) For each data broadcasting presentation unit, the signaling message receiving unit provides a data message describing information on a broadcast transmission file list and a main file that constitute the presentation unit, and a pre-cache target file list. receiving a data transmission message containing the content management table;
The receiving device according to (6) above.
(8) When the file data includes a file included in the pre-cache target file list, the control unit pre-caches the file in the cache memory.
The receiving device according to (7) above.
(9) For each data broadcasting presentation unit, the signaling message receiving unit includes: a broadcast transmission file list that constitutes the presentation unit; receiving a data transmission message containing a data content management table describing information about
The receiving device according to (6) above.
(10) When the file data of the file to be locked is received, the control unit precaches the file in the cache memory.
The receiving device according to (9) above.
(11) The control unit deletes the unlock target file from the cache memory.
The receiving device according to (9) above.
(12) When the file data receives a broadcast transmission file list and a central file that constitute the current data broadcast presentation unit, the control unit caches them in the cache memory.
The receiver according to either (6) or (9) above.
(13) further comprising a data broadcasting presenting unit that presents data broadcasting using file data;
The receiver according to any one of (6) to (12) above.
(14) further comprising a media data receiving unit for receiving media data of a main body of a broadcast program linked with data broadcasting, and a broadcast program presenting unit for presenting the broadcast program based on the media data;
The receiver according to any one of (6) to (13) above.
(15) a file data receiving step of transmitting file data used in data broadcasting;
a signaling message receiving step of transmitting signaling related to data broadcasting including forced cache information designating forced cache of file data;
a control step of controlling caching of the file data received by the file data receiving unit in a cache memory based on the forced cache information;
receiving method.

DESCRIPTION OF SYMBOLS 10... Digital broadcasting system 11... Broadcast transmission system 12... Receiver 301... Clock part 302... Signal transmission part 303... Video encoder 304... Audio encoder 305... Caption encoder 306... Signaling encoder 307... File Encoder 308 Information System 309 TLV Signaling Encoder 310 IP Service Multiplexer 311 TLV Multiplexer 312 Modulator/Transmitter 401 Tuner/Demodulator 402 Demultiplexer 403 Clock 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 (2)

a control unit that acquires files that constitute an application and signaling messages related to transmission of the application;
a memory unit in which files constituting the application are cached;
and
The control unit further acquires information designating a file to be locked in the cache, and includes the capacity of the memory unit, information designating the file to be locked in the cache, and the signaling message. location information of directories of files constituting the application, a first table describing node tags identifying the directories, and a second table describing the node tags. control the cache,
receiving device. The control unit deletes the cached files that make up the application from the memory unit.
The receiving device according to claim 1.

Images