Receiving device and receiving method

Abstract

To transmit a file of data broadcasting by HTML5 in an MMT method.SOLUTION: In a data content management table, information of a broadcast transmission file list constituting a presentation unit and a file becoming a center, and of an object file list of pre-caching is described for every data broadcast presentation unit. When specifying a broadcast file list constituting a data broadcast presentation unit referred next as a target of pre-caching from a current data broadcast presentation unit, file data required for the data broadcast presentation unit to be transited next can be pre-cached on a receiver side, and timely data broadcast service linked to a broadcast program can be achieved.SELECTED DRAWING: Figure 33

Description

[Technical Field]

[0001] The technology disclosed in this specification relates to a transmitting device and a transmitting method for transmitting files for data broadcasting using a predetermined transport method, and a receiving device and a receiving method for receiving files for data broadcasting transmitted using a predetermined transport method. [Background technology]

[0002] 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). MMT (MPEG Media Transport) (see, for example, Non-Patent Document 1), which has been standardized by MPEG as a new media transport method, is being considered as a next-generation digital broadcasting method. MMT makes it easy to combine different transmission paths, and can be used commonly across multiple transmission paths for broadcasting and communications.

[0003] The MMT method makes it possible to transmit both timed media, such as video and audio streams, and non-timed media, such as files, on MMT packets. Timed media refers to the stream data of the main broadcast program, such as video, audio, and subtitles. Non-timed media refers to the file data of data broadcasting applications (content), such as HTML (Hyper Text Markup Language) documents.

[0004] Data broadcasting linked to broadcast programs requires timely presentation. Meanwhile, each file used in data broadcasting is repeatedly transmitted within the limited broadcast transmission bandwidth. Receiving terminals can achieve timely presentation of data broadcasting by caching the data broadcasting files. However, in receiving terminals that do not have ample cache memory, if a cache miss occurs for a necessary file, the terminal must wait until the next repeat cycle, resulting in a delay of, for example, several tens of seconds before the data broadcasting can be presented.

[0005] In the data broadcasting service using BML (Broadcast Markup Language) in operation at the time of this application, it is possible to pre-cache specific files in advance and keep them in cache memory by calling an API (Application Programming Interface) called "LockModuleOnMemory()" from a script (see, for example, Patent Document 2). [Prior art documents] [Patent documents]

[0006] [Patent Document 1] Japanese Patent Application Laid-Open No. 2013-153291 [Patent Document 2] Japanese Patent Application Laid-Open No. 2007-274193 [Non-patent literature]

[0007] [Non-Patent Document 1] ISO / IEC FDIS 23008-1:2013(E) Information technology-High efficiency coding and media delivery in heterogeneous environments-Part1:MPEG media transport(MMT) Summary of the Invention [Problem to be solved by the invention]

[0008] An object of the technology disclosed in this specification is to provide a transmission device and a transmission method that can suitably transmit files for data broadcasting using a predetermined transport method.

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

[0010] The present application has been made in consideration of the above problems, and the technology described in claim 1 is as follows: a file data transmission unit that transmits file data used in data broadcasting; a signaling message transmitting unit that transmits a signaling message related to data broadcasting including forced caching information that specifies forced caching of file data; The transmitting device is provided with:

[0011] According to the technology described in claim 2 of the present application, the signaling message sending unit of the transmitting device described in claim 1 is configured to send, for each data broadcasting presentation unit, a data transmission message including a data content management table describing the broadcast transmission file list and core file that constitute the presentation unit, and information on the file list to be pre-cached.

[0012] According to the technology described in claim 3 of the present application, the signaling message sending unit of the transmitting device described in claim 1 is configured to send, for each data broadcasting presentation unit, a data transmission message including a broadcast transmission file list and a data content management table that describes information on the central file and target files to be locked in the cache that constitute the presentation unit, and the target files to be unlocked from among the locked files.

[0013] According to the technology described in claim 4 of the present application, the transmitting device described in any one of claims 1 to 3 further includes a media data transmitting unit that transmits media data of the broadcast program main body to which the data broadcasting is linked.

[0014] Furthermore, the technology described in claim 5 of the present application is as follows: A file data transmission step of transmitting file data used in data broadcasting; a signaling message transmitting step of transmitting a signaling message related to data broadcasting including forced caching information specifying forced caching of file data; It is a transmission method having the following.

[0015] Furthermore, the technology described in claim 6 of the present application is as follows: a file data receiving unit that transmits file data used in data broadcasting; a signaling message receiving unit that includes forced caching information specifying forced caching of file data in signaling related to data broadcasting and transmits the signaling; a control unit that controls caching of the file data received by the file data receiving unit in a cache memory based on the forced caching information; The receiving device is provided with:

[0016] According to the technology described in claim 7 of the present application, the signaling message receiving unit of the receiving device described in claim 6 is configured to receive, for each data broadcasting presentation unit, a data transmission message including a data content management table describing the broadcast transmission file list and core file that constitute the presentation unit, and information on the file list to be pre-cached.

[0017] According to the technology described in claim 8 of the present application, the control unit of the receiving device described in claim 7 is configured to pre-cache a file included in the list of files to be pre-cached in the cache memory when the file data is received.

[0018] According to the technology described in claim 9 of the present application, the signaling message receiving unit of the receiving device described in claim 6 is configured to receive, for each data broadcasting presentation unit, a data transmission message including a data content management table describing information on the broadcast transmission file list and central file that constitute the presentation unit, the target files to be locked in the cache, and the target files to be unlocked from among the locked targets.

[0019] According to the technology described in claim 10 of the present application, the control unit of the receiving device described in claim 9 is configured to pre-cache the file to be locked in the cache memory when the file data is received.

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

[0021] According to the technology described in claim 12 of the present application, the control unit of the receiving device described in either claim 6 or 9 is configured to cache the broadcast transmission file list and core file that constitute the current data broadcast presentation unit in the cache memory when the file data is received.

[0022] According to the technology set forth in claim 13 of the present application, the receiving device set forth in any one of claims 6 to 12 further comprises a data broadcasting presenting unit that presents data broadcasting using file data.

[0023] According to the technology described in claim 14 of the present application, the receiving device described in any of claims 6 to 13 further includes a media data receiving unit that receives media data of the broadcast program itself to which the data broadcasting is linked, and a broadcast program presentation unit that presents the broadcast program based on the media data.

[0024] In addition, the technology described in claim 15 of the present application is as follows: A file data receiving step for transmitting file data used in data broadcasting; A signaling message receiving step for transmitting a signaling message related to data broadcasting including forced caching information for specifying forced caching 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 caching information; The receiving method has the following features. [Effects of the Invention]

[0025] The technology disclosed in this specification assumes that data broadcasting files written in, for example, HTML (Hyper Text Markup Language) 5 are transmitted using the MMT method. According to the technology disclosed in this specification, a transmitting device such as a broadcasting station can transmit signaling related to data broadcasting, including information specifying forced caching. Furthermore, according to the technology disclosed in this specification, a receiving device such as an STB (Set Top Box) or television receiving terminal installed in the home can appropriately control the caching of each file for data broadcasting based on the forced caching information included in the signaling related to the received data broadcasting, and can present data broadcasting linked to the broadcast program in a timely manner.

[0026] It should be noted that the effects described in this specification are merely examples, and the effects of the present invention are not limited to these. Furthermore, the present invention may also have additional effects in addition to the effects described above.

[0027] Further objects, features, and advantages of the technology disclosed in this specification will become apparent from the following detailed description based on the embodiments and accompanying drawings. [Brief explanation of the drawings]

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

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

[0030] 1 is a schematic diagram showing an example of the configuration of a digital broadcasting system 10 to which the technology disclosed in this specification is applied. The illustrated digital broadcasting system 10 is made up of a broadcast transmission system 11 and a receiver 12.

[0031] The broadcast transmission system 11 transmits IP (Internet Protocol) broadcast signals that include transmission media. The transmission media of the broadcast signals include both timed media and non-timed media such as files. Timed media is stream data related to the main broadcast program, such as video, audio, and subtitles. Non-timed media is file data used for data broadcasting, such as HTML documents. The following explanation assumes a data broadcasting service using HTML5.

[0032] Meanwhile, the receiver 12 receives the broadcast signal sent from the broadcast transmission system 11. The receiver 12 then acquires transmission media such as video, audio, and subtitles from the received broadcast signal and presents images and sounds. Furthermore, when the receiver 12 acquires each file data for data broadcasting from the received broadcast signal, it launches an application engine such as an HTML browser and presents the data broadcasting linked to the broadcast program.

[0033] The digital broadcasting system 10 shown in Fig. 1 is assumed to use MMT as the transport method for transmitting broadcast signals from the broadcast transmission system 11 to the receiver 12. Fig. 2 shows an example of the broadcast signal configuration in this case as a stack model 200.

[0034] The lowest layer of the stack model 200 is a physical layer (PHY) 201. The physical layer 201 includes a modulation method, an error correction method, and the like.

[0035] Above the physical layer 201 is a TLV (Type Length Value) transmission packet layer 202. Furthermore, an IP packet 203 is placed above the TLV 202, and above that is a UDP (User Datagram Protocol) 204. Also placed above the TLV transmission packet 202 are a header compressed IP 205, which is a compressed version of the headers of the IP 203 and UDP 204, and a transmission control signal 206 as signaling information.

[0036] On top of UDP 204 are MMT packets 207, NTP (Network Time Protocol) packets 208 containing information on the current time, etc. The MMT protocol (MMTP) is an application layer transport protocol for transmitting MMTP payloads 209 over IP networks.

[0037] The MMT payload 209 of the MMT packet 207 contains an MMT Fragment Unit (MFU) 210 or a signaling message (Signaling Message) 211 related to data broadcasting. The MFU 210 is a fragment of a Media Processing Unit (MPU), which is a container for encoded timed 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.

[0038] Fig. 3 shows an example of the configuration of a broadcast transmission system 11 that transmits the broadcast signal shown in Fig. 2. 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, an information 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.

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

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

[0041] The video encoder 303 encodes the video signal sent from the signal sending unit 302, packetizes it, and sends the IP packets containing the video MMT packets to the IP service multiplexer 310. The audio encoder 304 encodes the audio signal sent from the signal sending unit 302, packetizes it, and sends the IP packets containing the audio MMT packets to the IP service multiplexer 310. The caption encoder 305 encodes the subtitle signal sent from the signal sending unit 302, packetizes it, and sends the IP packets containing the subtitle MMT packets to the IP service multiplexer 310.

[0042] The signaling encoder 306 generates a signaling message related to data broadcasting based on information sent from the information system 308, and sends an IP packet containing an MMT packet with this signaling message placed in the payload section to the IP service multiplexer 310. In this embodiment, signaling messages related to data broadcasting are broadly divided into three types: PA messages, M2 section messages, and data transmission messages. In this embodiment, information specifying forced caching of each file used in data broadcasting is included in the data transmission message. Details of each signaling message will be described later.

[0043] 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 sends IP packets containing these MMT packets to the IP service multiplexer 310. The file data constitutes the data broadcasting content (data broadcasting applications).

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

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

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

[0047] The modulation and transmission unit 312 performs RF modulation processing on the broadcast stream generated by the TLV multiplexer 311 and sends it out onto an RF transmission path.

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

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

[0050] The video signal sent from the signal sending unit 302 is supplied to the video encoder 303. In the video encoder 303, the video signal is encoded and further packetized to generate IP packets containing video MMT packets. These IP packets are sent to the IP service multiplexer 310.

[0051] Similar processing is also performed on the audio signal and subtitle signal sent from the signal sending unit 302. Then, IP packets containing audio MMT packets generated by the audio encoder 304 are sent to the IP service multiplexer 310, and IP packets containing subtitle MMT packets generated by the caption encoder 305 are sent to the IP service multiplexer 310.

[0052] The signaling encoder 306 also generates a signaling message related to data broadcasting based on information sent from the information system 308, and generates an IP packet containing an MMT packet with this signaling message placed in the payload section. This IP packet is sent to the IP service multiplexer 310.

[0053] Furthermore, file data sent from the signal sending unit 302 or the information system 308 is supplied to a 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. These IP packets are sent to an IP service multiplexer 310.

[0054] In each IP service multiplexer 310, IP packets containing video, audio, subtitles, signaling messages, and file data sent from each encoder 303 to 307 are multiplexed to generate TLV packets that make up one channel.

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

[0056] The TLV multiplexer 311 generates a broadcast stream by multiplexing the TLV packets generated by each of the IP service multiplexers 310-1 to 310-N and the TLV signaling encoder 309. The modulation and transmission unit 312 performs RF modulation processing on the broadcast stream generated by the TLV multiplexer 311, and sends the RF modulated signal to an RF transmission path.

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

[0058] The tuner / demodulator 401 receives the RF modulated signal and performs demodulation to obtain a broadcast stream. The demultiplexer 402 demultiplexes and packetizes this broadcast stream, outputting NTP time information, PTS (Presentation Time Stamp), signaling information, coded signals for video, audio, and captions related to the main broadcast program, file data used for data broadcasting linked to the broadcast program, and signaling information. The file data used for data broadcasting is, for example, a data broadcasting application written in HTML5 format.

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

[0060] The application data control unit 407 processes each file data used in data broadcasting. In this embodiment, it is assumed that each file data used in data broadcasting is transmitted via two systems: a broadcast signal and an IP network. The application data control unit 407 acquires the former via the tuner / demodulator unit 401 and demultiplexer 402, and the latter via the IP interface 412. The application data control unit 407 controls the processing of the acquired file data based on the signaling information output from the demultiplexer 402. Specifically, the application data control unit 407 manages which data broadcasting presentation unit (PU) the device is currently in and instructs the data broadcasting application engine 409, such as an HTML browser, to process the corresponding file data (data broadcasting application such as HTML5). The data broadcasting application engine 409 processes the data broadcasting application using file data that has been pre-cached or pre-cached in the cache memory 408 as appropriate.

[0061] The application data control unit 407 refers to the signaling tables included in each of the PA message, M2 section message, and data transmission message to identify the access range required to present the data broadcasting, and controls the filtering operation for pre-caching cacheable file data in the cache memory 408 by the data broadcasting application engine 407. Details of pre-caching of file data will be given later.

[0062] In addition, information specifying the forced caching of each file used in the data broadcasting is included in the data transmission message. In this embodiment, the application data control unit 407 pre-caches file data required to present the data broadcasting in a timely manner in the cache memory 408 based on the forced caching information included in the data transmission message. Details of file data pre-caching will be described later.

[0063] In a broadcast stream, file data of the same content is repeatedly transmitted. The system control unit 410 controls the filtering operation in the demultiplexer 402 so that the application data control unit 407 acquires only the data necessary for the demultiplexer 402 from the repeatedly transmitted file data.

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

[0065] The system control unit 410 also controls the decoding timing of each decoder 404-406 based on the PTS, and adjusts the presentation timing of the video, audio, and subtitles. The synthesis unit 411 synthesizes the subtitle display signal and the data broadcast display signal with the baseband video signal to obtain a video signal for video display. The baseband audio signal obtained by the audio decoder 405 becomes an audio signal for audio output. The main broadcast program consisting of the video signal and audio signal is output as video and audio from a monitor display (not shown). The data broadcast processed by the data broadcast application engine 409 is also displayed superimposed on the main broadcast program screen on the monitor display.

[0066] The operation of the receiver 12 shown in FIG. 4 will now be described.

[0067] The tuner / demodulator 401 receives the RF modulated signal and performs demodulation to obtain a broadcast stream. The demultiplexer 402 performs demultiplexing and packetization on this broadcast stream, extracting NTP time information, PTS, signaling information, video, audio, and caption coded signals, as well as file data.

[0068] The NTP time information extracted by the demultiplexer 402 is sent to the clock unit 403. The clock unit 403 generates time information synchronized with the NTP time information based on this time information. In other words, the clock unit 403 generates time information that matches the time information generated by the clock unit 301 on the broadcast transmission system 11 side.

[0069] The coded video signal extracted by the demultiplexer 402 is sent to a video decoder 404 where it is decoded to obtain a baseband video signal. The coded subtitle signal extracted by the demultiplexer 402 is sent to a caption decoder 406 where it is decoded to obtain a subtitle display signal. The file data extracted by the demultiplexer 402 is sent to a data broadcasting application engine 407 where it is processed to obtain a data broadcasting display signal. The system control unit 410 controls the filtering operation in the demultiplexer 402 so that only the necessary file data is obtained by the demultiplexer 402.

[0070] Then, in the combining unit 411, the baseband video signal is combined with the subtitle display signal and the data broadcast display signal to obtain a video signal for video display.

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

[0072] Meanwhile, the application data control unit 407 manages which data broadcasting presentation unit the user is currently in, and instructs the data broadcasting application engine 409, such as an HTML browser, to process the corresponding file data (data broadcasting application such as HTML5). The data broadcasting application engine 409 processes the data broadcasting application using file data that has been pre-cached or pre-cached in the cache memory 408 as appropriate. The data broadcasting processed by the data broadcasting application engine 409 is also displayed superimposed on the main broadcast program screen on the monitor display.

[0073] In addition, the application data control unit 407 refers to the signaling tables contained in each of the PA messages, M2 section messages, and data transmission messages to control pre-caching of file data according to the available capacity of the cache memory 408, and forced caching to present data broadcasts in a timely manner in conjunction with broadcast programs (described below).

[0074] In the digital broadcasting system 10 shown in Fig. 1, it is assumed that MMT is applied as a transport method 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 an RF transmission path in accordance with the MMT method.

[0075] The broadcast signal for one channel (broadcast program) consists of timed media related to the main broadcast program, such as video, audio, and subtitles, and non-timed media, such as file data used for data broadcasting linked to the broadcast program. These encoded media data are stored in an MPU and transmitted. Information related to the transmission control of these broadcast signals is also transmitted as signaling information. MMT makes it easy to use different combinations of transmission paths for the timed and non-timed media data that make up one channel (broadcast program). In the example shown in Figure 5, broadcast signal 500 uses MMT transmission paths 501-504 for each type of data, such as video, audio, subtitles, file data, and signaling information. For convenience, the transmission path for subtitle data is omitted from the diagram.

[0076] A channel (broadcast program) can be considered a "package" consisting of multiple assets of different types, such as video, audio, subtitles, and file data (data applications). (A package is a logical collection of media data transmitted over an MMT transmission path.) Each asset is a set (logical group) of one or more MPUs that share the same asset_id (asset identifier), and is transmitted over a dedicated ES (Elementary Stream), or MMT transmission path. (An asset is a data entity associated with a unique identifier and used to compose a multimedia presentation.) Specifically, transmission path 501 transmits video MMT packets (MMTPs) consisting of MPU logical groups with a common asset_id. Transmission path 502 transmits audio MMT packets consisting of MPU logical groups with a common asset_id. Transmission path 503 transmits file data MMT packets consisting of MPU logical groups with a common asset_id. An MPU is identified by its asset_id and its sequence number on the corresponding transmission path. In addition, the MMT transmission path that transmits each media can be identified by asset_id.

[0077] Additionally, multiple assets of the same type (i.e., different asset_ids) may be transmitted in one package (broadcast program). For example, two or more file contents (data broadcasting applications) may be provided for the same broadcast program. In such cases, different asset_ids are assigned to the different file contents and transmitted as separate MPU logical groups on separate MMT transmission paths. For simplicity, Figure 5 shows only one transmission path 503 for file data.

[0078] MMT can also be used across multiple broadcast and communication transmission paths. Non-timed media such as HTML document data can be transmitted together with timed media over broadcast transmission paths as shown in Figure 5, or can be provided over communication transmission paths such as IP networks.

[0079] Additionally, MMT packets containing the same signaling message are repeatedly transmitted over transmission path 504. To realize the technology disclosed herein, three types of signaling messages are involved: PA message 510, M2 section message 520, and data transmission message 530. Signaling tables are transmitted using these signaling messages. For example, PA message 510 contains MP (MMT Package) table 511. M2 section message 520 contains MH AI (Application Information) table 521. Data transmission message 530 is a message for notifying the data transmission method and data management control method, and contains the following signaling tables: data directory management table 531, data asset management table 532, and data content management table 533. Details of each table will be provided later.

[0080] As mentioned above, MMTP transmits timed media such as video, audio, and subtitles, as well as non-timed media such as file data. Figure 6 shows an example of the structure of an MMTP packet 600. An MMTP packet is a unit of media data formatted to be transmitted using the MMT protocol. For details, see, for example, Non-Patent Document 1.

[0081] When the packet counter flag "C" indicated by reference number 601 is set to 1, it indicates that the packet counter field indicated by reference number 602 is present in this MMTP packet. The packet counter 602 is a 32-bit field in which an integer value that counts MMTP packets is written, and is incremented by 1 each time an MMTP packet is sent.

[0082] When the extension flag "X" indicated by reference number 603 is set to 1, it indicates the presence of an extension header 604 indicated by reference number 604. An example of the configuration of the extension header 604 is also shown at the bottom of FIG. 6. The extension header 604 is made up of a 16-bit 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 byte length of the header_extension_value field is written in the length field. Extension information that deviates from the MMT specifications can be written in the header_extension_value field.

[0083] A type value indicating the type of payload data of the MMTP packet is written in the type field indicated by reference number 606. The definitions of the type values are shown in Table 1 below.

[0084] [Table 1]

[0085] If the RAP (Random Access Point) flag indicated by reference number 605 is set to 1, it indicates that the payload of the MMTP packet contains a Random Access Point to the data stream of the data type.

[0086] The 16-bit packet_id field, denoted by reference number 607, contains an integer value used to distinguish assets. The value of this field is derived from the asset_id of the asset to which the MMTP packet belongs. The mapping between packet_id and asset_id is shown in the MMT Package (MP) table, which is part of the signaling message.

[0087] In the 32-bit timestamp field indicated by reference number 608, the transmission time of the MMTP packet is written in the short format defined by the NTP protocol.

[0088] 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.

[0089] 7 shows an example of the configuration of an extension header 700 for an MMTP packet transmitting non-timed media. As shown in the figure, in this case, 4 is written as the byte length of the header_extension_value field in the length field 701. The header_extension_value field 702 contains a 4-byte download_id.

[0090] When transmitting an MPU using the MMT protocol, packetization and depacketization are required on the sending and receiving sides, respectively. Packetization inserts the MPU into an MMTP payload and transmits it in an MMTP packet. The MMTP payload format allows fragmentation of the MMTP payload to enable the transmission of larger payloads. The MTP payload format also allows aggregation, where multiple MMTP payloads are inserted into a single MMTP payload to accommodate smaller data units. On the receiving side, depacketization is performed to restore the original MPU data.

[0091] Figure 8 shows an example of the configuration of an MMTP payload 800 in MPU mode. For details, see, for example, Non-Patent Document 1. MPU mode occurs 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 broadcast program, as well as file data (data broadcasting applications) linked to the broadcast program.

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

[0093] [Table 2]

[0094] When the Timed (T) flag indicated by reference numeral 802 is set to 1, it indicates that the MPU transmitting timed media is fragmented, and when it is set to 0, it indicates that the MPU transmitting non-timed media is fragmented.

[0095] The Fragmentation Identifier (f_i) field, denoted by reference numeral 803, uses two bits to indicate information about fragmentation of data units in the payload. The four values of f_i are defined in Table 3 below.

[0096] [Table 3]

[0097] If the payload is an aggregate of multiple data units, an aggregation (A) flag indicated by reference number 804 is set to 1.

[0098] The 8-bit fragment_counter field, denoted by reference numeral 805, describes the number of payloads containing fragments of the same data unit that follow the MMTP payload.

[0099] The length of the data (DU: Data Unit) that follows this field is written in a 16-bit DU_length field indicated by reference number 806. However, when the A flag 804 is 0, the DU_length field 806 does not exist.

[0100] The DU_Header, indicated by reference numeral 807, is the header of the data unit. However, when the FT value 801 is 0 or 1 (in other words, when it is not an MFU), the DU_Header 807 is not present. An MFU contains a sample or sub-sample of timed media, or an item of non-timed media.

[0101] Figure 9 shows an example of the structure of the DU_Header 900 for an MFU with timed media in the payload. Figure 10 shows an example of the structure of the DU_Header 1000 for an MFU with non-timed media in the payload. As shown in Figure 10, the DU_Header 1000 for non-timed media consists of a 32-bit item_ID, which is an identifier for the item transmitted as part of the MFU. An item is a resource that constitutes an application, such as HTML document data or monomedia data referenced from an HTML document. On the MMT transmission path specified by the asset_id, an item can be uniquely identified by the combination of the packet_id in the header of the MMTP packet mentioned above, the download_id in the extension header, and the item_ID in the DU header.

[0102] FIG. 11 shows an example of a packet structure when transmitting non-timed media data.

[0103] Figure 11(a) shows the state of the original file data. In the figure, F1 and F2 each represent one file data. The file data may be, for example, an HTML document, and may contain one or more items. The HTML document itself is also an item.

[0104] Figure 11(b) shows how file data F1 and F2 are placed in an MFU. Since file data F1 is not large, it is placed as is in the payload of a single MFU. On the other hand, since file data F2 is large, it is split into multiple pieces, each of which is placed in the payload of an MFU. In the example shown, file data F2 is split into two pieces, F2-1 and F2-2, each of which is placed in the payload of a different MFU.

[0105] Here, MFUs in which non-timed media such as HTML document data or monomedia are placed in the payload are each assigned a DU_Header (see Figure 10) containing an item_ID that uniquely identifies the item.

[0106] Next, as shown in Figure 11(c), an MMT payload header (see Figure 8) is attached to each MFU to form an MMT payload. Here, the value 2 is entered in the Fragment Type (FT) field of the MMT payload header to indicate that the fragment type is an MFU. In addition, the value 0 is entered in the Timed (T) flag to indicate that this is an MPU that transmits non-timed media. In addition, for an MFU in which non-fragmented non-timed media is placed, the value 0 is entered in the Fragmentation Identifier (f_i) field. On the other hand, for an MFU in which fragmented non-timed media is placed, the value 1 is entered in the Fragmentation Identifier (f_i) field and the corresponding count value is entered in the fragment_counter field.

[0107] Next, as shown in Figure 11(d), an MMTP packet header and extension header (see Figure 6) are attached to each MMT payload to form an MMT packet stream. Here, the type field of the MMTP header is set to 0 to indicate that the payload data type is MPU, and an integer value for identifying the asset is written in the packet_id field. The extension header also contains the download_id. Therefore, on the MMT transmission path specified by the asset_id, an item can be uniquely identified by the combination of the packet_id in the MMTP packet header and the download_id in the extension header, and the item_ID in the DU header.

[0108] Furthermore, as shown in Figure 11(e), an IP header and a UDP header are attached to each MMT packet to form an IP packet stream. Although not shown in the figure, TLV packets that make up the broadcast stream are generated by attaching a TLV header to each IP packet.

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

[0110] Next, we will explain the structure of signaling messages used in the MMT protocol, which are relevant to realizing the technology disclosed in this specification. Signaling messages are signaling information required for package transmission control and package use, and they transmit various signaling tables.

[0111] MMT signaling messages use a general format consisting of three common fields, one specific field for each signaling message type, and a message payload. The message payload carries the signaling information. Below, we will explain PA messages, M2 section messages, and data transmission messages in that order.

[0112] The PA (Package Access) message transmits a PA table that contains all the signaling table information required for Package Access. The PA table includes an MMT Package (MP) table. Fig. 12 shows an example of the configuration of a PA message 1201, which is one of the signaling messages, and an MP table 1202 included in the PA message. Fig. 13 also shows an example of the syntax of a PA message 1300, and Fig. 14 shows an explanation of the parameters included in the PA message.

[0113] "message_id" is a fixed 16-bit value that identifies the 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, "version" is incremented by +1. "length" is a 32-bit parameter that indicates the size of the PA message in bytes, counted from immediately after this field.

[0114] The extension field contains index information for the MP table (MPT) placed in the payload 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.

[0115] The payload field of the PA message contains the MP table, which stores information related to the package, including a list of all assets.

[0116] Figures 15 and 16 show an example of the syntax of the MP table (Figure 16 is the second half of Figure 15). Figure 17 shows an explanation of the parameters included in the MP table. The configuration of the MP table will be explained below.

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

[0118] MMT_package_id is the identification information for the entire package, consisting of all signals (video, audio, subtitles) transmitted in the broadcast signal, as well as assets such as file data. This identification information is text information. MMT_package_id_length indicates the size of the text information in bytes.

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

[0120] "number_of_assets" is an 8-bit parameter that indicates the number of assets (signals, files) that make up the package. The following Asset loops are placed for the number of "number_of_asset" (N3).

[0121] Within one Asset loop, the following parameters are placed as information about each asset: asset_id_len, asset_id, gen_loc_info, asset_dsc_len, and asset_descriptor.

[0122] 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 that indicates the location from which the asset is acquired. In this embodiment, gen_loc_info is written in the format of a packet ID on the transmission path from which the asset is acquired. Therefore, by looking up asset_id in the MP table, it is possible to extract the corresponding packet ID on the MMT transmission path.

[0123] 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. It is assumed that N5 (one or more) asset_descriptors will be placed, specifying descriptors for various purposes.

[0124] The M2 section message is a signaling message used to transmit the MPEG-2 System section extension format as is. Figure 18 shows an example of the structure of an M2 section message 1800. The meaning of each parameter in the M2 section message is explained below.

[0125] The message_id (message identification) is a 16-bit fixed value that identifies the M2 section message in various signaling information, and is set to 0x8000 in this embodiment. The version (version) is an 8-bit integer parameter that indicates the version of the M2 section message. The length (message length) is a 16-bit parameter that indicates the size of the M2 section message in bytes, counting from immediately after this field. The table_id (table identification) is an area used to identify the table to which the section belongs. The section_syntax_indicator (section syntax indication) is set to '1', indicating the extended format. The section_length (section length) is an area to write the number of bytes of data that follow the section length area. The table_id_extension (table identification extension) is an area to extend the table identification. The version_number (version number) is an area to write the version number of the table. The current_next_indicator is '1' if the table is currently usable, and '0' if the table is currently unusable and will be valid next. The section_number is an area where the section numbers that make up the table are written. The last_section_number is an area where the last section number that makes up the table is written. CRC32 (CRC) is a cyclic redundancy code that conforms to ITU-T Recommendation H.222.0.

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

[0127] The table_id (table identification) is an 8-bit fixed value that identifies the table as an application information (AI) table in various signaling information, and is set to 0x89 in this embodiment. The section_syntax_indicator (section syntax indication) is a 1-bit field that is always set to "1." The section_length (section length) is a 12-bit field, and the first 2 bits are always set to "00." This specifies the number of bytes in the section from the section length field to the end of the section, including the CRC32. This value must not exceed 1021 (0x3FD in hexadecimal). The application_type (application type) is a 16-bit field that indicates the value of the application being transmitted in the AIT. In DVB, 0x0001 is assigned to DVB-J applications. 0x0001 is also assigned to ARIB-J applications. The version_number (version number) is a 5-bit field that indicates the version number of the subtable. The version_number is the version number of the MH AI table, and is incremented by +1 when there is a change in the information in the subtable. Also, when the version number value reaches "31", it returns to "0" the next time. The current_next_indicator is always "1". The section_number is an 8-bit field that indicates the section number. The section number of the first section in a subtable is 0x00. The section number is incremented by +1 each time a section with the same table identification and application format is added. The last_section_number is an 8-bit field that specifies the last section number in the subtable to which the section belongs.

[0128] common_descriptor_length (common descriptor loop length) is an 8-bit field that specifies the byte length of the following descriptor (descriptor in the descriptor area). This descriptor (descriptor in the descriptor area) stores descriptor information in a series of areas consisting of loops equal to the number of common_descriptor_length. The descriptor applies to all applications in the AIT subtable. For example, a transmission protocol descriptor is written in the descriptor field.

[0129] The application_loop_length is an area for writing the number of pieces of application information included in this MH AI table. Then, the number of loops of application information indicated by the application_loop_length is arranged.

[0130] Within one application information loop, there are placed application_identifier (application identifier), application_control_code (application control code), and descriptors (application information descriptors) written in a series of areas consisting of loops equal to the application_descriptor_loop_length (application information descriptor loop length). The descriptors in this descriptor area apply only to the specified application.

[0131] The application_identifier is a parameter that identifies the application. The application_control_code is an 8-bit field that specifies the control code that controls the application state. The semantics of this field depend on the value of the application type. If "autostart" is specified as the application_control_code, a receiver that references this MHAT table will start the application specified in the application_identifier. If "prefetch" is specified as the application_control_code, a receiver that references this MHAT table will prefetch the application specified in the application_identifier. If "kill" is specified as the application_control_code, a receiver that references this MHAT table will stop the execution of the application specified in the application_identifier. CRC32 (CRC) is a cyclic redundancy code that conforms to ITU-T Recommendation H.222.0.

[0132] In short, the MH AI table is a table that specifies the processing method, transmission method (transport_protocol), and location (URL) of the application (file data) sent over the MMT transmission path. When the receiver receives the MH AI table sent in the M2 section message, it retrieves the application from the specified location using the specified transport_protocol to perform the processing specified in the application_control_code.

[0133] Fig. 20 shows an example of the configuration of an application information descriptor 2000 stored in the application information loop of the MH AI table. Fig. 21 shows an explanation of the parameters included in the application information descriptor 2000. The meaning of each parameter of the application information descriptor 2000 will be explained below.

[0134] The descriptor_tag is an 8-bit integer value that identifies the relevant descriptor 2000. The descriptor_length is an area in which the number of bytes of data of the relevant descriptor 2000 that follows this field is written.

[0135] The application_profile information is written in a series of areas consisting of loops equal to the application_profile_length. The application_profile is the profile of the receiver on which this application can be executed, and indicates the requested functions using a bitmap for each function requested of the receiver. However, the top 3 bits indicate function bitmap switching. The above bitmap is specified for each version. Additionally, version_major, version_minor, and version_micro are the versions of the application profile specification, respectively.

[0136] service_bound_flag is a flag indicating whether this application is valid only for the current service. visibility indicates whether the application is visible or not. application_priority is the relative priority between applications advertised within this service. transport_protocol_label indicates the protocol used to transmit the application. As a value for transport_protocol_label, 0x0003 specifies HTTP / HTTPS transmission, and 0x0005 specifies MMT and non-timed transmission.

[0137] 22 shows an example of the configuration of a transmission protocol descriptor 2200. The meaning of each parameter of the transmission protocol descriptor 2200 will be explained below.

[0138] The descriptor_tag is an 8-bit integer value that identifies the relevant descriptor 2200. The descriptor_length is an 8-bit field in which the number of bytes of data of the relevant descriptor 2200 that follows this field is written.

[0139] The protocol_id (protocol identifier) indicates the protocol used to transmit the application. The value 0x0003 specifies HTTP / HTTPS transmission, and 0x0005 specifies MMT and non-timed transmission. The transport_protocol_label (transmission protocol label) is a value that uniquely identifies the transmission method when an application is transmitted over multiple routes, and corresponds to the field of the same name in the application information descriptor. The selector_byte (selector byte) is an area where the syntax is specified for each protocol ID, and where the acquisition location is written.

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

[0141] URL_base_byte stores text information indicating the URL_base of the URL character string in a series of areas consisting of loops equal to the number of URL_base_length.

[0142] The URL_extension_count indicates the number of URL_extensions following the URL_base, and there are as many URL_extension loops as the URL_extension_count. Within one URL_extension loop, the URL_extension_byte stores text information indicating each URL_extension in a series of areas consisting of loops equal to the URL_extension_length, which specifies the length of the URL_extension. Each URL_extension is a URL string following the URL_base. For example, if the URL_base is "http: / / www.xbc.com" and the URL_extension is "index.html", these strings can be concatenated to obtain the complete URL "http: / / xbc.com / index.html".

[0143] In short, by referencing 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) can be obtained.

[0144] 24 shows an example of the structure of a data transmission message 2400, which is one of the signaling messages. The meaning of each parameter of the data transmission message will be explained below.

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

[0146] num_of_tables indicates the number of tables stored in this data transmission message. A loop of table information is placed as many times as the number of tables indicated by num_of_tables as the tables stored in the data transmission message.

[0147] Within a single table information loop, the following table information is stored: table_id (table identification), table_version (table version), and table_length (table length). table_id (table identification) is an area used to identify the table to be stored in this data transmission message. Data transmission messages transmit three types of signaling tables: Data Asset Management Table (DAMT), Data Directory Management Table (DDMT), and Data Content Management Table (DCMT) (as described above), and table_id (table identifier) identifies which of these tables it is. table_version (table version) indicates the version of the table to be stored in this data transmission message. table_length (table length) indicates the size of the table to be stored in this data transmission message in bytes.

[0148] Also, table loops are placed for the number indicated by num_of_tables. Each table loop stores the contents of the table identified by table_id. table indicates the table to be stored in this data transmission message.

[0149] Figure 25 shows an example of the configuration of a data asset management table 2500 transmitted in a data transmission message. The data asset management table is a table that manages information about file data assets transmitted as MMTP packets and information about items included in each asset of the file data. The meaning of each parameter in this data asset management table is explained below.

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

[0151] "number_of_asset" is an 8-bit parameter that indicates the number of file data assets included in the package. The following asset information loop is placed the same number of times as "number_of_asset", and file data information for each asset is stored.

[0152] The loop of one asset information contains the download_id, information about the asset (file data) itself, and information about each item contained in the asset. The download_id is identification information written in the extension header of the MMTP packet that carries non-timed media (file data) (see Figure 7).

[0153] Information about the asset itself stored within the asset information loop includes asset_ID_scheme, asset_ID_length, asset_ID_length, and asset_ID_byte. asset_ID_scheme indicates the asset_ID format. Examples of asset_ID formats that can be assigned include UUID (Universal Unique Identifier), URI (Uniform Resource Identifier), and GURL (General URL). asset_ID_length indicates the length of asset_ID_byte in bytes. asset_ID_byte indicates asset_ID in the format specified by asset_ID_scheme, in a series of areas consisting of loops equal to the asset_ID_length. In this embodiment, this information is used to identify assets in both the MP table and the data asset management table. However, since the data volume is large, other alternative 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 that component_tag is used instead of asset_ID in the data asset management table.

[0154] "number_of_items" is the field where the number of items that make up the asset of the corresponding file data is written. Then, a loop of items is placed for the number of items specified by "number_of_items", and information about each item that makes up the asset (file data) is written.

[0155] The item loop contains the following parameters for each item: item_ID, node_tag, item_size, item_version, item_checksum, and item_info. The item_ID is a 32-bit value that identifies the item transmitted via non-timed MFU. The node_tag is a 16-bit value that similarly identifies the item. For signaling information, using a 16-bit node_tag instead of the 32-bit item_ID reduces the bit size required for item identification. Note that "node" refers to each directory and item that serves as a node in the directory structure that makes up the data broadcasting application (content). Both items and directories can be specified using node_tag. The item_size represents the item size in bytes. The item_version indicates the item version; the version is incremented by +1 each time the item's contents are updated. The item_checksum indicates the item's checksum. Note that the amount of information required to set a checksum for every file is considered too large. Therefore, taking such considerations into account, for example, a 1-bit check_sum_flag may be set, and the 32-bit item_check_sum may appear only when this bit is set to 1. Alternatively, instead of signaling, the checksum may be indicated as type in the extension header of the MMTP packet shown in Figure 7, with the 32-bit checksum placed after length. item_info_length indicates the size of the information field in item_info_byte in bytes. Then, item_info_byte stores information about the item (item_info()) in a series of fields consisting of loops equal to the number of items specified by item_info_length.

[0156] descriptor_loop_length indicates the total byte length of the descriptor. The descriptor stores the descriptor information (descriptor()) in a series of areas consisting of loops equal to the descriptor_loop_length. The stored descriptors are defined separately.

[0157] In short, the data asset management table 2500 is a table that manages information about the file data (content) assets contained in a package and the items contained in the assets. Item version information is also managed as information about the items. By referencing the data asset management table 2500, it is possible to retrieve the corresponding asset_id from the node_tag (or Item_ID) or the downloadID or item_info written in the MMT extension header that transmits the asset, or to retrieve the item_ID or item_info on the file data transmission path from the node_tag handled on the signaling information transmission path.

[0158] Figure 26 shows an example of the structure of the Data Directory Management Table (DDMT) 2600 transmitted in a data transmission message. The Data Directory Management Table is a table that manages the directories that make up a data broadcasting application (content) and the location information of each node (subordinate directories and items (file data)) contained in the directory. The meaning of each parameter in this Data Directory Management Table is explained below.

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

[0160] base_folder_path_length indicates 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 equal to the number of base_folder_path_length. base_folder_path_byte is expressed, for example, in the form of an absolute URL for accessing the corresponding directory.

[0161] num_of_folder_nodes indicates the number of folder nodes to be recorded in the data directory management table. A loop of folder nodes is placed for the number of num_of_folder_nodes.

[0162] Within a single folder node loop, information on each folder node described in the data directory management table and information on each file data included in the base folder are stored.

[0163] folder_node_path_length indicates the size of the folder_node_path_byte information area in bytes. folder_node_path_byte stores the pathname to folder_node in a series of areas consisting of loops equal to the number of folder_node_path_length. folder_node_path_byte is expressed, for example, in the form of a relative URL from base_folder_path to access the corresponding directory. Although not shown, folder_node_version (folder node version information) may also be included as folder node information. For example, if the pathname (URL) of base_folder is "http: / / www.xbc.com" and the path name (URL) of a folder_node is "index.html", the complete URL "http: / / xbc.com / index.html" can be obtained by concatenating these strings.

[0164] num_of_files indicates the number of files recorded in the data directory management table. A file loop is placed for the number of files specified by num_of_files.

[0165] Within a single file loop, the node_tag and file_name_byte (file name) are stored as information about each file data contained in the base folder. The node_tag is a 16-bit identifier that identifies the item transmitted in non-timed MFU, which is shorter than the 32-bit item_ID. Note that node refers to each directory and item that serves as a node in the directory structure that makes up the data broadcasting application (content). Not only items but also directories can be specified with node_tag (as described above). The file_name_byte is stored in a series of areas consisting of loops equal to the number of file_name_length.

[0166] In essence, the data directory management table 2600 is a table that manages the directory structure of the directories contained in a single package, as well as the subdirectories and files (items) contained within those directories. The data directory management table 2600 allows the file structure of a data broadcasting application to be separated from the structure for file transmission. By referencing the data directory management table 2600, it is possible to look up the path name (URL) of a corresponding item from its node_tag, or conversely, look up the corresponding node_tag from its path name (URL). In this configuration example, the data directory management table sets the location information of the directory in which the file resides as folder_path_byte, provides identification information for each directory as node_tag, and specifies only the file name and node_tag for each item. This prevents the amount of information in folder_path_byte from becoming too large.

[0167] Next, we will explain the Data Content Management Table (DCMT) transmitted in the data transmission message.

[0168] The Data Content Management Table (DCMT) is a table that manages information about file data transmitted as non-timed media, i.e., content (data broadcasting applications). In this embodiment, the Data Content Management Table is transmitted with information specifying forced caching. Data broadcasting linked to broadcast programs requires timely presentation. In such cases, by including information specifying forced caching in the Data Content Management Table (DCMT) from the broadcast transmission system 11, the receiver 12 can pre-cache each file used in the data broadcasting linked to the broadcast program, thereby realizing timely presentation of the data broadcasting.

[0169] There are two methods for transmitting forced cache information using the Data Content Management Table (DCMT):

[0170] (Method 1) In the data content management table, for each data broadcasting presentation unit (PU), the list of broadcast transmission files (member items) that make up the presentation unit, the central file (primary item), and, if there are files to be pre-cached, the list of files to be pre-cached (pre-cache item) are described.

[0171] The files to be pre-cached here are, for example, composed of a broadcast file list that constitutes the next data broadcasting presentation unit (PU) to be referenced from the current data broadcasting presentation unit (PU). By presenting a list of files to be pre-cached in the data broadcasting signaling information in this way, the broadcast program producer can perform cache control operations using pre-caching, in which the receiver pre-caches the file data required for the next data broadcasting presentation unit to be transitioned to. As a result, it is possible to realize a timely data broadcasting service linked to the broadcast program.

[0172] (Method 2) In the data content management table, for each data broadcasting presentation unit (PU), the list of broadcast transmission files (member items) that make up the presentation unit and the central file (primary item), as well as information on the target file to be locked in the cache (lock cache item) and the target file to be unlocked from the locked items (unlock cache item) are described.

[0173] The files to be locked here may, for example, consist of a broadcast file list to be used in the next data broadcasting presentation unit (PU) to be referenced from the current data broadcasting presentation unit (PU). By presenting a list of files to be locked and unlocked in the data broadcasting signaling information, the broadcast program producer can control the cache on the receiver side by locking and unlocking them. For example, the receiver side can lock the file data required for the next data broadcasting presentation unit in the cache. This makes it possible to realize a timely data broadcasting service linked to the broadcast program. Furthermore, the files to be unlocked may, for example, consist of a broadcast file list that is no longer needed in the current data broadcasting presentation unit (PU). By specifying files to be unlocked, unnecessary files can be deleted from the cache memory 408, thereby saving memory space.

[0174] FIG. 27 shows an example of the configuration of a data content management table (DCMT) 2700 transmitted in a data transmission message that realizes method 1.

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

[0176] "number_of_content" is an 8-bit parameter that indicates the number of contents included in the package (content is, for example, file data such as an HTML document describing a data broadcasting application). The following content loop is placed for the number of times specified by "number_of_content", and information for each content is stored.

[0177] Within a loop for one piece of content, information about the content is written, including content_ID, content_version, content_cache_size, and information about the data broadcasting presentation unit (PU) included in the content. content_ID is content identification information. content_version indicates the version of the content. content_cache_size indicates the size of the cache for the content.

[0178] 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_PU.

[0179] Within the loop for one PU, written are PU_tag, which is the PU's identification information, PU_cache_size, which indicates the size to cache the PU, and PU_primary_item_node_tag, which identifies the central file (primary item) of the data broadcasting presentation unit (PU).

[0180] Also, within the PU loop, a list of broadcast transmission files (member items) that make up the data broadcasting presentation unit (PU) is written. Specifically, number_of_PU_member_nodes indicates the number of nodes included in the data broadcasting presentation unit (PU) (i.e., the number of nodes that are members of the PU). After that, a loop of PU member nodes is placed for the number of nodes equal to number_of_PU_member_nodes, and within each PU member node loop, the node_tag of the PU member node is written. The PU member nodes include directory nodes and item nodes.

[0181] Additionally, if there are files to be pre-cached in the corresponding PU, the information of the target file list (pre-cache item) is written within the PU loop. Specifically, number_of_pre_cache_nodes is the number of nodes to be pre-cached, and the same number of pre-cache node loops as number_of_pre_cache_nodes are placed. Within one pre-cache node loop, pre_cache_node_tag, which identifies the pre-cache node, is written.

[0182] The files to be pre-cached here are, for example, composed of a broadcast file list that constitutes the next data broadcasting presentation unit (PU) to be referenced from the current data broadcasting presentation unit (PU). By presenting a list of files to be pre-cached in the data broadcasting signaling information in this way, the broadcast program producer can pre-cache the file data required for the next data broadcasting presentation unit to be transitioned to on the receiver side. As a result, it is possible to realize a timely data broadcasting service linked to the broadcast program.

[0183] In addition, within the loop for one PU, there is placed number_of_linked_PU, which indicates the number of other PUs linked from this PU, and there are as many linked_PU loops as there are number_of_linked_PUs. Within the loop for one linked_PU, there is written linked_PU_tag, which is the identification information for the linked_PU.

[0184] FIG. 28 shows an example of the configuration of a data content management table (DCMT) 2800 transmitted in a data transmission message that realizes method 2.

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

[0186] "number_of_content" is an 8-bit parameter that indicates the number of contents included in the package (content is, for example, file data such as an HTML document describing a data broadcasting application). The following content loop is placed for the number of times specified by "number_of_content", and information for each content is stored.

[0187] Within a loop for one piece of content, information about the content is written, including content_ID, content_version, content_cache_size, and information about the data broadcasting presentation unit (PU) included in the content. content_ID is content identification information. content_version indicates the version of the content. content_cache_size indicates the size of the cache for the content.

[0188] 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_PU.

[0189] Within the loop for one PU, written are PU_tag, which is the PU's identification information, PU_cache_size, which indicates the size to cache the PU, and PU_primary_item_node_tag, which identifies the central file (primary item) of the data broadcasting presentation unit (PU).

[0190] Also, within the PU loop, a list of broadcast transmission files (member items) that make up the data broadcasting presentation unit (PU) is written. Specifically, number_of_PU_member_nodes indicates the number of nodes included in the data broadcasting presentation unit (PU) (i.e., the number of nodes that are members of the PU). After that, loops of PU member nodes are placed for the number of nodes equal to number_of_PU_member_nodes, and the node_tag of the PU member node is written within the loop of each PU member node. PU member nodes include directory nodes and item nodes.

[0191] Also, within the loop for a PU, information is written about the file (lock cache item) whose cache in the cache memory 408 is to be locked and the file (unlock cache item) among the locked files that is to be unlocked for the corresponding PU. Specifically, number_of_lock_cache_nodes is the number of nodes to be pre-cached, followed by a loop of the nodes to be locked as many times as number_of_lock_cache_nodes. Within the loop for one node to be locked, a lock_cache_node_tag is written that identifies the node to be locked. Additionally, number_of_unlock_cache_nodes is the number of nodes to be pre-cached, followed by a loop of the nodes to be unlocked as many times as number_of_unlock_cache_nodes. Within the loop for one node to be unlocked, a unlock_cache_node_tag is written that identifies the node to be unlocked.

[0192] The files to be locked here are, for example, the broadcast file list to be used in the next data broadcasting presentation unit (PU) to be referenced from the current data broadcasting presentation unit (PU). By presenting the locked file list in the data broadcasting signaling information in this way, the broadcast program producer can lock the file data required for the next data broadcasting presentation unit in the cache on the receiver side. As a result, it is possible to realize a timely data broadcasting service linked to the broadcast program. Furthermore, the files to be unlocked are, for example, the broadcast file list that is no longer needed in the current data broadcasting presentation unit (PU). By specifying the files to be unlocked, unnecessary files can be deleted from the cache memory 408, thereby saving memory size.

[0193] In addition, within the loop for one PU, there is placed number_of_linked_PU, which indicates the number of other PUs linked from this PU, and there are as many linked_PU loops as there are number_of_linked_PUs. Within the loop for one linked_PU, there is written linked_PU_tag, which is the identification information for the linked_PU.

[0194] In short, the data content management table is a table that manages each content (data broadcasting application) in one package by data broadcasting presentation unit (PU), and by referencing the data content management table, the PU_tag of the data broadcasting presentation unit that includes that node can be obtained from the node_tag. The data content management table also has the aspect of controlling the forced caching of data broadcasting files on the data content management table receiver 12 side. However, details of cache control operations using the data content management table will be discussed later.

[0195] Figure 29 illustrates the transmission of data broadcasting applications (content) transmitted via MMT, the location of the content, and the mechanism for presenting the application.

[0196] Figure 29(A) shows the directory structure of content. Each piece of content (content1, 2, ...) consists of a datacasting application (app) and material. Datacasting applications and material are resources whose entity is file data. Each resource corresponds to an item, which is a component of an asset, on the MMT transmission path and can be identified by a 32-bit item_ID. Furthermore, within the signaling information, an item can be identified by a 16-bit node_tag. As shown in Figure 29(C), each resource is transmitted as an item on the MMT transmission path of the corresponding asset (described below). An application consists of one or more HTML documents referenced during content execution (during datacasting presentation). Furthermore, material is monomedia data such as JPEG images and text referenced from HTML documents. One HTML document and the material referenced from it constitute one datacasting presentation unit (PU). In the example shown in Figure 29(A), content1 has one or more HTML documents such as A11.html, A12.html, and A13.html as resources of the data broadcasting application. Of these, A11.html is a resource that is directly referenced when the content is executed.

[0197] Figure 29(B) shows the reference relationships between resources when content is executed (when data broadcasting is presented). In the example shown, application A11, which is directly referenced when content is executed, and materials B11 and B02 that it references, form resource group 2801, which makes up one data broadcasting presentation unit PU, and p1 is assigned as the PU_tag (note that B14 is material that is not transmitted by MMT via broadcasting but can be obtained at any time via HTTP transmission via communication, and in the following it will be treated as not being included in the resource group of the data broadcasting presentation unit).

[0198] Similarly, application A12 and the materials B12, B02, and B13 it references are resource group 2802 that make up one data broadcasting presentation unit PU, and p2 is assigned as the PU_tag (note that B07 is material that is not transmitted by MMT via broadcasting but can be obtained at any time via HTTP transmission over the Internet, and in the following it will be treated as not being included in the resource group of the data broadcasting presentation unit).Similarly, application A01 and the materials B03, B01, and B04 it references are resource group 2803 that make up one data broadcasting presentation unit PU, and p3 is assigned as the PU_tag.

[0199] Furthermore, multiple HTML documents can have link reference relationships (as is well known). In the example shown in Figure 29(B), resource A11.html is an HTML document that describes the application presentation screen that is directly referenced when the content is executed and is displayed first. In contrast, resource A12.html, which is included in the same content1, and resource A01.html, which is included in common outside content1, are HTML documents that describe the application presentation screen to which A11.html is displayed when A11.html is executed, and they have a link reference relationship with A11.html. Resources A11.html, A12.html, and A01.html each form resource groups 2801, 2802, and 2803, which each constitute a single data broadcasting presentation unit PU. The linked data broadcasting presentation units 2801, 2802, and 2803 then form a larger, higher-level resource group 2810. Resources A11.html, A12.html, and A01.html are the central file data (primary item_node) of each data broadcasting presentation unit PU.

[0200] Furthermore, the entire content, which is the entire application included in a package (one broadcast program), constitutes a larger resource group, i.e., the entire data content. The entire data content is the range of data broadcasting presentation units PUs that have a common content_ID. By looping through the PUs with the corresponding content_ID in the data content management table, it is possible to identify all data broadcasting presentation units PUs included in the content all at once. In the example shown in Figure 29(B), the applications included in content1 and common form resource group 2820 for the entire content.

[0201] Figure 29(C) shows a schematic diagram of content transmission using MMT. The applications and materials that make up content are each represented by file data and are also called "resources." On the MMT transmission path, each resource corresponds to an item, which is a component of an asset. In MMT transmission, each piece of content included in a package is treated as a single asset and is assigned an Asset_ID. In the example shown, content1 is assigned an asset_ID of a1. Also, in MMT transmission, individual resources such as HTML document data and materials are treated as single items and are assigned an Item_ID. In the example shown, the resources included in content1 are assigned Item_IDs i11, i12, i13, and i14, respectively.

[0202] Furthermore, resources contained in the same content share the same asset_ID and are transmitted on the same MMT transmission path. In the example shown in Figure 29(C), items with Item_IDs i11, i12, i13, and i14 share the same Asset_ID a1 and are transmitted on the same MMT transmission path. The aforementioned data directory management table is represented in Figure 29(A), the data content management table is represented in Figure 29(B), and the data asset management table is represented in Figure 29(C), and these are related by item_ID or node_tag.

[0203] The reference relationships between the tables transmitted as signaling information when a data broadcasting application (content) is acquired from an MMT transmission path will be described with reference to FIG.

[0204] When the receiver 12 obtains the MH-AI table (MH AIT) 2901 in the M2 section message, it references the application_control_code to determine how the application state is controlled. If "autostart" is specified, it references the transport_protocol_label in the table to determine that MMT transmission is specified, and extracts the URL information of the item (file data) directly referenced when presenting this application from the transmission protocol descriptor. The receiver then references 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 the base_folder_path_byte, folder_node_path_byte, and file_name_byte.

[0205] Next, the receiver 12 refers to the Data Asset Management Table (DAMT) 2903 sent in the data transmission message, returns the acquired node_tag to the item_ID on the MMT transmission path, identifies the corresponding asset, and acquires its asset_ID and download_id.

[0206] The receiver then refers to the MP table (MPT) 2904 sent in the PA message to obtain the packet_id corresponding to the acquired asset_ID, and then filters the file data on the MMT transmission path based on the packet_id in the MMTP packet header, the download_id in the extension header, and the item_ID in the DU header to obtain the desired item (which is directly referenced when presented in the application).

[0207] The receiver 12 can also retrieve the PU_tag of the corresponding application presentation unit in the data content management table (DCMT) 2905 sent in the data transmission message by looking up the node_tag obtained from the data directory management table 2902. Also, by running the linked_PU loop within the PU loop of this PU_tag, it is possible to collectively retrieve the PU_tags of other application presentation units linked to it.

[0208] Figure 31 shows a schematic diagram of a mechanism for caching file data used for data broadcasting within a receiver. Caching here includes caching and pre-caching of file data to be executed.

[0209] The application data control unit 407 analyzes the signaling messages demultiplexed from the broadcast stream by the demultiplexer 402 and controls operations within the receiver. Regarding content pre-caching, the application data control unit 407 pre-caches each file used in data broadcasting linked to a broadcast program based on the forced caching information contained in the data content management table.

[0210] Specifically, the application data control unit 407 obtains the cache_node_tag of the node (directory or file data) designated for pre-caching in the data content management table transmitted in the data transmission message. As explained with reference to Figure 30, the corresponding MMTP packet can be identified from the node_tag.

[0211] 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 to obtain the asset_ID of the asset to which that node belongs, and then looks up the 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. The system control unit 408 also obtains the download_id written in the extension header of the MMTP packet transmitting the desired item from the data asset management table, and then filters the data on the MMT transmission path of the file data based on the packet_id in the MMTP packet header, the download_id in the extension header, and the item_ID in the DU header to obtain the entity of the desired item and pre-caches it in the cache memory 408.

[0212] When the data broadcasting application engine 409 executes an application, if the required item (file data) has already been cached in the cache memory 408, it can retrieve it from the cache memory 408 and respond quickly to generate a data broadcasting display signal without waiting for the file data demultiplexed from the broadcast stream to arrive by the demultiplexer 402. 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 file data demultiplexed from the broadcast stream to arrive, and then responds by generating a data broadcasting display signal.

[0213] Next, the control operation of caching file data used in data broadcasting in the receiver 12 will be explained in detail.

[0214] As mentioned above, there are two methods for transmitting forced cache information using the Data Content Management Table (DCMT): Method 1 and Method 2. First, we will explain the cache control operation using Method 1.

[0215] In Method 1, the broadcast transmission system 11 transmits the data content management table (DCMT) 2700 shown in Figure 27 in a data transmission message. For each data broadcast presentation unit (PU), the data content management table (DCMT) 2700 describes the list of broadcast transmission files (member items) that make up the presentation unit, the core file (primary item), and, if there are files to be pre-cached, the list of files to be pre-cached (pre-cache item). Therefore, the receiver 12 can perform cache control operations using pre-caching as shown below.

[0216] (Operation 01) The application data control unit 407 detects and updates data transmission messages transmitted on the MMT transmission path 504 as needed, and acquires the latest information. (Operation 02) The application data control unit 407 recognizes that it has entered the presentation state of the corresponding data broadcasting presentation unit (PU) by accessing the application file (which is the center of the data broadcasting presentation unit) specified in primary_item in response to instructions from the data broadcasting application control engine 409 or the like. (Operation 03) The application data control unit 407 simultaneously obtains each member file (PU_member_node) contained in the corresponding data broadcasting presentation unit (PU) in the data content management table (DCMT) contained in the data transmission message and stores it in the cache memory 408. (Operation 04) Furthermore, if a pre-caching target is specified for the corresponding data broadcasting presentation unit (PU) in the data content management table, the application data control unit 407 also obtains each file (item) to be pre-cached and pre-caches it in the cache memory 408. (Operation 05) The data broadcasting application engine 409 executes the application file specified in primary_item from the cache memory 408. (Operation 06) After that, if the configuration of the member files (PU_member_node) or files to be pre-cached included in the data broadcasting presentation unit (PU) currently in presentation state changes due to an update of the data content management table (DCMT), or if the presentation state of another data broadcasting presentation unit (PU) is transitioned due to application operation in the data broadcasting application engine 409, the above-mentioned (Operation 03) to (Operation 05) processes are performed for the data broadcasting presentation unit (PU) currently in presentation state. Even if files were held in the cache memory 408 in the previous state, the application data control unit 407 deletes files that are not required in the current state from the cache memory 408.

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

[0218] When the data broadcasting application control engine 409 is performing application operation, i.e., presenting data broadcasting (Yes in step S3201), the application data control unit 407 recognizes that it has entered the presentation state of the corresponding data broadcasting presentation unit (PU) by accessing the application file specified as primary_item (center of the data broadcasting presentation unit) in the data content management table (Yes in step S3202).

[0219] The application data control unit 407 resets the cache memory 408, acquires the primary_item and each member file (PU_member_node) of the currently presented data broadcasting presentation unit (PU) in the data content management table (DCMT), and stores them in the cache memory 408 (step S3203). The data broadcasting application engine 409 executes the application file specified in the primary_item from the cache memory 408.

[0220] The application data control unit 407 also checks whether a pre-cache target is specified for the corresponding data broadcasting presentation unit (PU) in the data content management table (step S3204). If a pre-cache target is specified (Yes in step S3204), the application data control unit 407 also acquires each file (item) to be pre-cache and pre-caches it in the cache memory 408 (step S3205).

[0221] If the configuration of the member files (PU_member_node) or files to be pre-cached included in the currently presented data broadcasting presentation unit (PU) changes due to an update of the Data Content Management Table (DCMT) (Yes in step S3206), return to step S3203 and repeat the above process for the currently presented data broadcasting presentation unit (PU).

[0222] Furthermore, if 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 that data broadcasting presentation unit is accessed (Yes in step S3207), the process returns to step S3203 and the above processing is repeated in the data broadcasting presentation unit (PU) to which the transition has been made.

[0223] The above processing is repeated until the data broadcasting application engine 409 finishes the application operation (No in step S3208).

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

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

[0226] When the datacasting application control engine 409 is performing application operation for the datacasting presentation unit (PU) identified by PU_id=1, the application data control unit 407 references the data content management table and obtains the node_tags of the application file "A01.html" specified as the primary_item (center of the datacasting presentation unit) of the currently presented datacasting presentation unit (PU_id=1) and each of the member files (PU_member_node) "B01" and "B02" from the data content management table. After obtaining the file data entities corresponding to these node_tags from the MMT transmission path 503 that transmits the data assets, the application data control unit 407 caches them in the cache memory 408 as indicated by reference numeral 3301. The method for accessing files transmitted over the MMT transmission path 503 from the node_tags has already been explained with reference to Figure 30 (the same applies below). However, since no pre-caching target has been specified for this datacasting presentation unit (PU), pre-caching is not performed.

[0227] Next, suppose that application operation in the datacasting application engine 409 transitions to the presentation state of another datacasting presentation unit (PU) identified by PU_id=3. As described above, the application data control unit 407 obtains from the data content management table the application file "A11.html" specified as the primary_item (center of the datacasting presentation unit) of the transitioned datacasting presentation unit (PU_id=3), as well as the node_tags of each member file (PU_member_node) "B11," "B12," and "B13." Then, it obtains the file data entities corresponding to these node_tags from the MMT transmission path 503 and caches them in the cache memory 408, as indicated by reference numeral 3302. However, because no pre-caching target is specified for this datacasting presentation unit (PU), no pre-caching operation is performed.

[0228] The application data control unit 407 constantly analyzes various signaling messages received over the MMT transmission path 504. When it detects that the data content management table version has been updated from 1 to 2 (as indicated by reference numeral 3303), the application data control unit 407 checks whether there have been any changes to the primary_item, member files, and pre-cached files of the currently presented data broadcasting presentation unit (PU_id=3). Since there have been no changes to the member files this time, the previously cached member files remain in the cache memory 408. Furthermore, since "A12," "B14," and "B15" have been added as pre-cached files for the data broadcasting presentation unit (PU_id=3), the application data control unit 407 obtains the file data entities corresponding to these node_tags from the MMT transmission path 503 and caches them in the cache memory 408 (as indicated by reference numeral 3304).

[0229] Next, as shown by reference numeral 3305, upon receiving an event message from the MMT transmission path 504 instructing an update of the datacasting presentation, the datacasting application engine 409 transitions the HTML document from the currently running A11 file to the A12 file. At roughly the same time, the application data control unit 407 references the data content management table, whose version has been updated from 2 to 3, and detects that the primary_item of the currently presented datacasting presentation unit (PU_id=3) has changed to "A12.html" and that the member files have changed to "B14," "B15," and "B16." As described above, the primary_item "A12.html" and the member files "B14" and "B15" have already been pre-cached in the cache memory 408, so the datacasting application engine 409 can quickly display the datacasting using the files stored in the cache memory 408. In other words, timely datacasting presentation linked to the broadcast program can be performed. In addition, since "B12" has been added as a file to be pre-cached for the data broadcasting presentation unit (PU_id=3), the application data control unit 407 obtains the file data entity corresponding to that node_tag from the MMT transmission path 503 and caches it in the cache memory 408, as shown by reference number 3306.

[0230] Next, the cache control operation using method 2 will be explained.

[0231] In Method 2, the broadcast transmission system 11 transmits the data content management table (DCMT) 2800 shown in Figure 28 in a data transmission message. For each data broadcast presentation unit (PU), the data content management table (DCMT) 2800 describes the list of broadcast transmission files (member items) that make up the presentation unit, the central file (primary item), and information on the files to be locked in the cache (lock cache item) and the locked files to be unlocked (unlock cache item). Therefore, the receiver 12 can perform cache control operations by locking and unlocking the cache as shown below.

[0232] (Operation 11) The application data control unit 407 detects and updates data transmission messages transmitted on the MMT transmission path 504 as needed, and acquires the latest information. (Operation 12) The application data control unit 407 recognizes that it has entered the presentation state of the corresponding data broadcasting presentation unit (PU) by accessing the application file (which is the center of the data broadcasting presentation unit) specified in primary_item in response to instructions from the data broadcasting application control engine 409 or the like. (Operation 13) The application data control unit 407 simultaneously obtains each member file (PU_member_node) contained in the corresponding data broadcasting presentation unit (PU) in the data content management table (DCMT) contained in the data transmission message and stores it in the cache memory 408. (Operation 14) Furthermore, if a lock cache target is specified for the corresponding data broadcasting presentation unit (PU) in the data content management table, the application data control unit 407 also acquires each file (item) among the lock cache targets that has not yet been acquired, caches them in the cache memory 408, and manages them separately as lock cache target files. (Operation 15) Conversely, if the corresponding data broadcasting presentation unit (PU) is designated as a target for unlock caching in the data content management table, the application data control unit 407 deletes the unlock target file if it is cached in the cache memory 408, and also deletes it from the separately managed lock cache target files. (Operation 16) The data broadcasting application engine 409 executes the application file specified in primary_item from the cache memory 408. (Operation 17) If the configuration of the member files (PU_member_node) contained in the currently presented data broadcasting presentation unit (PU) or the files to be pre-cached changes due to an update of the Data Content Management Table (DCMT), the above steps (Operation 13) to (Operation 16) are performed. (Operation 18) When the presentation state of another data broadcasting presentation unit (PU) is transitioned due to application operation in the data broadcasting application engine 409, the files targeted for lock caching are temporarily stored in the cache memory 408, and then the above processes (Operations 13) to (Operation 16) are performed. Files other than those targeted for lock caching may be deleted from the cache memory 408.

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

[0234] When the data broadcasting application control engine 409 is performing application operation, i.e., presenting data broadcasting (Yes in step S3401), the application data control unit 407 recognizes that it has entered the presentation state of the corresponding data broadcasting presentation unit (PU) by accessing the application file specified as primary_item (center of the data broadcasting presentation unit) in the data content management table (Yes in step S3402).

[0235] The application data control unit 407 resets the cache memory 408, acquires the primary_item and each member file (PU_member_node) of the currently presented data broadcasting presentation unit (PU) in the data content management table (DCMT), and stores them in the cache memory 408 (step S3403). The data broadcasting application engine 409 executes the application file specified in the primary_item from the cache memory 408.

[0236] The application data control unit 407 also checks whether a lock cache target is specified for the corresponding data broadcasting presentation unit (PU) in the data content management table (step S3404). If a 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, caches them in the cache memory 408, and manages them separately as lock cache target files (step S3405).

[0237] The application data control unit 407 also checks whether an unlock cache target is specified for the corresponding data broadcasting presentation unit (PU) in the data content management table (step S3406). If an 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, and also deletes it from the separately managed lock cache target files (step S3407).

[0238] Subsequently, if the configuration of the member files (PU_member_node) included in the currently presented data broadcasting presentation unit (PU) or the files to be pre-cached changes due to an update of the Data Content Management Table (DCMT) (Yes in step S3408), return to step S3403 and repeat the above process for the currently presented data broadcasting presentation unit (PU).

[0239] Furthermore, if 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 that data broadcasting presentation unit is accessed (Yes in step S3409), the process returns to step S3403 and the above processing is repeated in the data broadcasting presentation unit (PU) to which the transition has been made.

[0240] The above processing is repeated until the data broadcasting application engine 409 finishes the application operation (no in step S3410).

[0241] FIG. 35 shows an example of the operation of locking and unlocking the cache of file data in the receiver 12 based on method 2.

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

[0243] When the datacasting application control engine 409 is performing application operation for the datacasting presentation unit (PU) identified by PU_id=1, the application data control unit 407 references the data content management table and obtains the node_tags of the application file "A01.html" specified as the primary_item (center of the datacasting presentation unit) of the currently presented datacasting presentation unit (PU_id=1) and each of the member files (PU_member_node) "B01" and "B02" from the data content management table. After obtaining the file data entities corresponding to these node_tags from the MMT transmission path 503 that transmits the data assets, the application data control unit 407 caches them in the cache memory 408 as indicated by reference numeral 3501. The method for accessing files transmitted over the MMT transmission path 503 from the node_tags has already been described with reference to Figure 30 (the same applies below). However, since the target of the lock cache has not been specified for this datacasting presentation unit (PU), no caching operation is performed.

[0244] Next, suppose that application operation in the datacasting application engine 409 transitions to the presentation state of another datacasting presentation unit (PU) identified by PU_id=3. As described above, the application data control unit 407 obtains from the data content management table the application file "A11.html" specified as the primary_item (center of the datacasting presentation unit) of the transitioned datacasting presentation unit (PU_id=3), as well as the node_tags of each member file (PU_member_node) "B11," "B12," and "B13." Then, it obtains the file data entities corresponding to these node_tags from the MMT transmission path 503 and caches them in the cache memory 408, as indicated by reference numeral 3502. However, because the target of the lock cache is not specified for this datacasting presentation unit (PU), the lock cache operation is not performed.

[0245] The application data control unit 407 constantly analyzes various signaling messages received over the MMT transmission path 504. When it detects that the data content management table version has been updated from 1 to 2 (as indicated by reference numeral 3503), the application data control unit 407 checks whether there have been any changes to the primary_item, member files, and lock cache target files of the currently presented data broadcasting presentation unit (PU_id=3). Since there have been no changes to the member files this time, the previously cached member files remain in the cache memory 408. Furthermore, since "A12," "B14," "B12," and "B15" have been added as lock cache target files for the data broadcasting presentation unit (PU_id=3), the application data control unit 407 obtains the file data entities corresponding to these node_tags from the MMT transmission path 503, caches them in the cache memory 408 (as indicated by reference numeral 3504), and manages them separately as lock cache target files. In the figure, files that are managed as lock cache targets are underlined (the same applies below).

[0246] Next, as shown by reference numeral 3505, upon receiving an event message from the MMT transmission path 504 instructing an update of the datacasting presentation, the datacasting application engine 409 transitions the HTML document from the currently running A11 file to the A12 file. At roughly the same time, the application data control unit 407 references the data content management table, whose version has been updated from 2 to 3, and detects that the primary_item of the currently presented datacasting presentation unit (PU_id=3) has changed to "A12.html" and that the member files have changed to "B14," "B15," and "B16." As described above, the primary_item "A12.html" and the member files "B14" and "B15" are already locked and cached in the cache memory 408. Therefore, the datacasting application engine 409 can quickly display the datacasting using the files stored in the cache memory 408. This allows for timely presentation of datacasting in sync with the broadcast program. Also, since the lock cache target is not specified for this data broadcasting presentation unit (PU), the lock cache operation is not performed. As shown by reference number 3506, the lock cached files "A12", "B14", "B12", and "B15" are retained in the cache memory 408, while the unnecessary file "A11" is deleted.

[0247] Furthermore, when an event message instructing an update of the data broadcasting presentation is received from the MMT transmission path 504, the application data control unit 407 refers to the data content management table and finds that "B17" has been added as a file to be locked and "B14" has been added as a file to be unlocked for the data broadcasting presentation unit (PU_id=3) currently being presented. Therefore, as shown by reference number 3507, the application data control unit 407 obtains the file data entity corresponding to the node_tag of file "B17" from the MMT transmission path 503 and locks and caches it in the cache memory 408, and also deletes the locked cached file "B12" from the cache memory 408, removing it from the list of files to be locked.

[0248] In currently operating data broadcasting services using BML (Broadcast Markup Language), it is possible to pre-cache specific files in advance and store them in cache memory by calling an API (Application Programming Interface) called "LockModuleOnMemory()" from a script (see, for example, Patent Document 2). This method requires that special specifications that are intended for broadcasting operation be incorporated into the specifications of applications such as scripts.

[0249] In contrast, according to the technology disclosed in this specification, a transmitter such as a broadcasting station transmits signaling related to data broadcasting that includes information specifying forced caching, and the receiver controls the caching of each file for data broadcasting based on the forced caching information included in the received signaling related to data broadcasting. Therefore, according to the technology disclosed in this specification, in data broadcasting using the new HTML5, a highly versatile format can be maintained without incorporating special specifications that are intended for broadcasting operation into application specifications such as scripts. [Industrial Applicability]

[0250] Although the technology disclosed in this specification has been described in detail with reference to specific embodiments, it is obvious that those skilled in the art can modify or substitute the embodiments without departing from the spirit of the technology disclosed in this specification.

[0251] The technology disclosed in this specification can be applied to various broadcasting systems that use MMT as a transport method. The technology disclosed in this specification can also be applied to various data broadcasting systems that transmit file data used in data broadcasting linked to broadcast programs using the MMT method or other transport methods.

[0252] In short, the technology disclosed in this specification has been described in the form of examples, and the contents of this specification should not be interpreted in a limiting manner. To determine the gist of the technology disclosed in this specification, the claims should be taken into consideration.

[0253] 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 transmitting unit that transmits a signaling message related to data broadcasting including forced caching information that specifies forced caching of file data; A transmitting device comprising: (2) The signaling message sending unit sends, for each data broadcasting presentation unit, a data transmission message including a data content management table that describes the broadcast transmission file list and core file that constitute the presentation unit, and information on the pre-caching target file list. The transmitting device according to (1) above. (3) The signaling message sending unit sends, for each data broadcasting presentation unit, a data transmission message including a data content management table that describes the broadcast transmission file list and core file that make up the presentation unit, the target file to be locked in the cache, and the target file to be unlocked among the locked files. The transmitting device according to (1) above. (4) A media data transmission unit is further provided for transmitting media data of the broadcast program main body linked with the data broadcasting. A transmitting device according to any one of (1) to (3) above. (5) a file data transmission step for transmitting file data used in data broadcasting; a signaling message transmitting step of transmitting a signaling message related to data broadcasting including forced caching information specifying forced caching of file data; A transmission method comprising: (6) a file data receiving unit that transmits file data used in data broadcasting; a signaling message receiving unit that includes forced caching information specifying forced caching of file data in signaling related to data broadcasting and transmits the signaling; a control unit that controls caching of the file data received by the file data receiving unit in a cache memory based on the forced caching information; A receiving device comprising: (7) The signaling message receiving unit receives, for each data broadcasting presentation unit, a data transmission message including a data content management table describing the broadcast transmission file list and core file constituting the presentation unit, and information on the pre-caching target file list. The receiving device according to (6) above. (8) When the control unit receives the file data, the control unit pre-caches a file included in the list of files to be pre-cached in the cache memory. The receiving device according to (7) above. (9) The signaling message receiving unit receives, for each data broadcasting presentation unit, a data transmission message including a broadcast transmission file list and a central file constituting the presentation unit, a target file to be locked in the cache, and a data content management table describing information on a target file to be unlocked among the locked files. The receiving device according to (6) above. (10) When the control unit receives the file data of the file to be locked, the control unit pre-caches the file in the cache memory. The receiving device according to (9) above. (11) The control unit deletes the file to be unlocked from the cache memory. The receiving device according to (9) above. (12) When the control unit receives the file data, it caches the broadcast transmission file list and the core file that constitute the current data broadcast presentation unit in the cache memory. A receiving device according to either (6) or (9) above. (13) Further comprising a data broadcasting presentation unit that presents data broadcasting using file data. A receiving device according to any one of (6) to (12) above. (14) The data broadcasting system further includes a media data receiving unit that receives media data of a broadcast program linked to the data broadcasting system, and a broadcast program presenting unit that presents the broadcast program based on the media data. A receiving device according to any one of (6) to (13) above. (15) a file data receiving step for transmitting file data used in data broadcasting; A signaling message receiving step for transmitting a signaling message related to data broadcasting including forced caching information for specifying forced caching 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 caching information; A receiving method having the following features. [Explanation of symbols]

[0254] 10...Digital broadcasting system 11...Broadcast transmission system, 12...Receiver 301... Clock unit, 302... Signal transmission unit, 303... Video encoder 304...Audio Encoder, 305...Caption Encoder 306...Signaling Encoder, 307...File Encoder 308...Information Systems, 309...TLV Signaling Encoder 310...IP Service Multiplexer 311...TLV multiplexer, 312...Modulation and transmission unit 401... Tuner and demodulator, 402... Demultiplexer 403...Clock unit, 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

1. A control unit that acquires files that constitute an application, a first table that lists directory location information of the files that constitute the application and node tags that identify the directories, and a second table that lists the node tags; A cache memory; Equipped with the control unit further acquires information specifying files to be locked in the cache, and controls caching of files constituting the application in the cache memory based on the information specifying files to be locked in the cache, the first table, the second table, and the free space in the cache memory. Receiving device.

2. The control unit deletes cached files that constitute the application from the cache memory.

2. The receiving device according to claim 1.

3. A control unit provided in a receiving device has an acquisition step of acquiring files constituting an application, a first table describing location information of a directory of the files constituting the application and a node tag identifying the directory, and a second table describing the node tag; The acquiring step further acquires information specifying a file to be locked in the cache; The method further includes a control step of controlling caching of the files constituting the application in the cache memory based on information specifying a file to be locked in the cache, the first table, the second table, and free space in the cache memory of the receiving device. Receiving method.

4. The method further comprises a deletion step of deleting files that constitute the cached application from the cache memory. The receiving method according to claim 3.

Images