JP2016092504A - Receiver unit, broadcasting system, reception method, and program - Google Patents

Abstract

PROBLEM TO BE SOLVED: To provide a receiver unit, a broadcasting system, a reception method, and a program, capable of securely updating software.SOLUTION: A software acquisition part acquires software associated with operation of a receiver unit. A reception route determination part, when a failure is detected during reception of the software through broadcasting, determines a reception route of the software to be communication. The present invention can also be embodied as a receiver unit, a broadcasting system, a reception method, and a program.SELECTED DRAWING: Figure 1

Description

  The present invention relates to a receiving apparatus, a broadcasting system, a receiving method, and a program.

2. Description of the Related Art Conventionally, a receiving apparatus for receiving a digital broadcast has a mechanism for realizing a predetermined function using software as described in Patent Document 1 and updating the software distributed by broadcast waves, for example. There was something with. The software is updated in accordance with, for example, bug correction and various operation parameter changes. When updating the software, the broadcasting station that transmits the broadcast wave notifies the receiving device of the software update using a part of the information transmitted on the broadcast wave, and then transmits the broadcast wave on which the data indicating the updated software is superimposed. Send. The receiving device receives software by broadcast waves and updates existing software to the received software.
On the other hand, in recent years, the fusion of broadcasting and communication has progressed, and many receiving apparatuses have means for connecting to a network, and various contents and data can be accessed via the network.

JP 2008-16969 A

  However, the conventional software update mechanism needs to receive a broadcast wave at the timing of software update. If broadcast waves are not received at that timing, there is a problem that the software cannot be updated. For example, if there is any obstacle in the reception environment, for example, a decrease in electric field strength due to rain, or a tuner is occupied for viewing or recording a program, the receiving device cannot receive software data. If this state continues, the software update timing may be lost as a result.

  The present invention has been made to solve the above problems, and one aspect of the present invention is a software acquisition unit that acquires software related to the operation of its own device, and a failure is detected in reception of the software by broadcasting. And a reception path determination unit that determines that the reception path of the software is communication.

  According to the present invention, the receiving device can reliably update the software.

It is a block diagram which shows the structure of the broadcast system which concerns on 1st Embodiment. It is a block diagram which shows the structure of the transmitter which concerns on 1st Embodiment. It is a figure which shows the example of a DII message. It is a figure which shows the example of a compatibility descriptor. It is a figure which shows the example of a DDB message. It is a figure which shows the example of notification information. It is a figure which shows the example of a download content descriptor. It is a figure which shows the example of a network download content descriptor. It is a block diagram which shows the structure of the server apparatus which concerns on 1st Embodiment. It is a block diagram which shows the structure of the receiver which concerns on 1st Embodiment. It is a block diagram which shows the structure of the control part which concerns on 1st Embodiment. It is a flowchart which shows operation | movement of the receiver which concerns on 1st Embodiment. It is a block diagram which shows the structure of the control part which concerns on 2nd Embodiment. It is a flowchart which shows operation | movement of the receiver which concerns on 2nd Embodiment. It is a block diagram which shows the structure of the control part which concerns on 3rd Embodiment. It is a flowchart which shows operation | movement of the receiver which concerns on 3rd Embodiment. It is a block diagram which shows the structure of the control part which concerns on 4th Embodiment. It is a flowchart which shows operation | movement of the receiver which concerns on 4th Embodiment.

(First embodiment)
A first embodiment of the present invention will be described with reference to the drawings.
FIG. 1 is a block diagram showing a configuration of a broadcasting system 1 according to the present embodiment. The broadcast system 1 includes a transmission device 11, a server device 21, and a reception device 31. The transmission device 11 and the server device 21 constitute a broadcasting facility possessed by a broadcasting company. The reception device 31 receives a broadcast program broadcast from the transmission device 11, displays a video of the received broadcast program, and reproduces the sound of the broadcast program. The receiving device 31 is installed in each home or business office.

  The transmission device 11 sequentially transmits broadcast program data (program data) to the reception device 31 via the broadcast transmission path 12. Further, the transmission device 11 acquires new software and transmits the acquired software by a predetermined method, for example, a data carousel method. The data carousel method is a transmission method in which the same data is repeatedly transmitted for a certain period. Here, the software is a program for operating to realize part or all of the functions of the transmission device 11. New software is transmitted as new software for the purpose of updating the existing software used in the receiving device 31, for example, software that fixes a bug found in existing software of the same type, and changes operating parameters. Software with new functions added or part of existing functions deleted.

  The broadcast transmission path 12 is a transmission path for transmitting various data transmitted by the transmission apparatus 11 to an unspecified number of reception apparatuses 31 in one direction at the same time. The broadcast transmission path 12 is, for example, a radio wave (broadcast wave) in a predetermined frequency band that is relayed by the broadcast satellite 13. A part of the broadcast transmission path 12 may include a communication line, for example, a communication line from the transmission device 11 to a transmission facility for transmitting radio waves. Note that transmitting (or receiving) various data via the broadcast transmission path 12 may be referred to as “transmitting (or receiving or downloading) by broadcasting”.

  The server device 21 is a server device that acquires new software transmitted by the transmission device 11 and stores the acquired software. The location of the server device 21 is notified to the receiving device 31 via the broadcast transmission path 12 by, for example, a URL (Uniform Resource Locator). When the server device 21 receives the software request signal from the receiving device 31, the server device 21 transmits the requested software to the receiving device 31.

  The communication transmission path 22 is a transmission path for bidirectionally transmitting various data between the server device 21 and the receiving device 31. The communication transmission path 22 includes, for example, a wide area communication network such as the Internet having a wired large-capacity backbone network. The communication transmission path 22 may be a communication network including a wireless access network in part, for example, a public wireless communication network. Note that transmitting various data via the communication transmission path 22 may be referred to as “transmitting (receiving or downloading) by communication”.

The reception device 31 activates a CAS program for decoding data received from the transmission device 11 via the broadcast transmission path 12, and decodes the received data by executing the activated CAS program.
The receiving device 31 receives software related to the operation of the own device from the transmitting device 11 or the server device 21. When a failure is detected in the reception by broadcasting from the transmission device 11, the reception device 31 determines that the software reception path is the communication transmission path 22, and tries to receive the communication from the server apparatus 21 by communication. The receiving device 31 is, for example, a television receiving device, a video recording device, or the like.

  With this configuration, even if a failure is detected in receiving software by broadcasting, the receiving device 31 can acquire the software by communication. Therefore, the receiving device can update existing software more reliably. Examples of obstacles in receiving software by broadcasting include reception obstacles when broadcast waves are blocked by buildings or other objects when the electric field strength of the broadcast waves is reduced due to rainfall.

(Configuration of transmitter)
Next, the configuration of the transmission device 11 according to the present embodiment will be described.
FIG. 2 is a block diagram illustrating a configuration of the transmission device 11 according to the present embodiment. The transmission device 11 includes a distribution data generation unit 111, a program data generation unit 112, a notification information generation unit 113, a multiplexing unit 114, an encryption unit 115, and a transmission unit 116.

The distribution data generation unit 111 receives a new version of software. The distribution data generation unit 111 converts the input software into data in a predetermined format, for example, section format, and generates distribution data (distribution data). Distribution data generation unit 111 outputs the generated distribution data to multiplexing unit 114.
Specifically, the distribution data generation unit 111 divides the input software into a predetermined size, divides the divided data (divided data) into a predetermined size as a DDB message, and converts the configuration information into a DII message. Generate as The distribution data is formed by the generated DII message and the DDB message. The DII message includes, for example, the manufacturer identification (maker_id), model identification (model_id), and version identification (version_id) of the software. “Identification (id)” is information for identifying an individual thing, and is sometimes referred to as an “identifier”.

The distribution data generation unit 111 calculates an error detection code calculated by a predetermined algorithm for the entire encrypted divided data (that is, software) stored in the DDB messages of all modules. The predetermined algorithm is, for example, cyclic redundancy check (CRC: Cyclic Redundancy Check). A CRC value is calculated as an error detection code by the cyclic redundancy check. The distribution data generation unit 111 describes the calculated CRC value, for example, in the CRC descriptor of the DII message. The receiving device 31 can verify whether or not the decoding is correctly performed based on whether or not the error detection code calculated based on the stored software data matches the added CRC value.
Distribution data generation unit 111 outputs the generated distribution data to multiplexing unit 114.

  Program data is input to the program data generation unit 112. The program data is data including video data and audio data representing a broadcast program. The program data generation unit 112 converts the input program data into a predetermined format, for example, a stream format, and outputs the converted program data to the multiplexing unit 114.

  The notification information generation unit 113 receives download information related to downloading new software. The notification information generation unit 113 includes the download information and generates notification information expressed in a predetermined format. The notification information includes a set of manufacturer identification (maker_id), model identification (model_id), and version identification (version_id) as information for specifying distributed software, as well as a distribution time and an address to the server device 21 that is a separate distribution source. , The priority of the distribution source, that is, the reception (download) route, and the like. The notification information is represented by, for example, an SDTT (Software Download Trigger Table) which is a section format table. The notification information generation unit 113 outputs the generated notification information SDTT to the multiplexing unit 114.

The multiplexing unit 114 multiplexes the distribution data input from the distribution data generation unit 111, the program data input from the program data generation unit 112, and the notification information input from the notification information generation unit 113 to obtain a predetermined format. Multiplexed data (for example, a transport stream) is generated. The multiplexing unit 114 outputs the generated multiplexed data to the encryption unit 115.
The encryption unit 115 encrypts the multiplexed data input from the multiplexing unit 114 by using a predetermined encryption method (for example, MULTI2). The encryption unit 115 outputs the encrypted multiplexed data to the transmission unit 116.
The transmission unit 116 transmits the multiplexed data input from the encryption unit 115 to the reception device 31 via the broadcast transmission path 12. Here, the transmitting unit 116 modulates a carrier wave having a predetermined carrier frequency with multiplexed data that is a baseband signal, and radiates a radio wave (broadcast wave) in a channel band corresponding to the carrier frequency using an antenna. .

(Data structure of DII message)
Next, an example of a DII message when transmitting software will be described.
FIG. 3 is a diagram illustrating an example of the DII message. In the example illustrated in FIG. 3, the DII message includes a compatibility descriptor (compatibilityDescriptor ()). An example of the compatibility descriptor (compatibilityDescriptor ()) will be described later. The DII message includes the number of modules (numberOfModules), module identification (module_id), and module size (module_size).

(Compatibility descriptor data structure)
Next, the data structure of the compatibility descriptor will be described. In the compatibility descriptor (compatibilityDescriptor ()), information that cannot be represented by the table identification (table_id) or group area (group) of the notification information SDTT is described.
FIG. 4 is a diagram illustrating an example of a compatibility descriptor. In the example shown in FIG. 4, the compatibility descriptor includes a model area (model) and a version area (version). In the upper 8 bits and lower 8 bits of the model area (model), manufacturer identification (maker_id) indicating the producer of software and model identification (model_id) indicating the target model (model) are described, respectively. In the version area (version), version identification (version_id) indicating the version of the software is described.

(Data structure of DDB message)
Next, the data structure of a DDB message used when distributing software will be described.
FIG. 5 is a diagram illustrating an example of the DDB message. In the example shown in FIG. 5, the DDB message includes a block number (BlockNumber), a module identification (moduleId), and a payload area (blockDataByte). The block number (BlockNumber) is information that is incremented and written for each block by the distribution data generation unit 111. Therefore, the block number (BlockNumber) is a number indicating the order of the divided software. The module identification (moduleId) is identification information that identifies each DDB message. The payload area (blockDataByte) is an area in which software divided by the distribution data generation unit 111 is written.

(Data structure of notification information)
Next, the data structure of the notification information SDTT generated by the notification information generation unit 113 will be described. FIG. 6 is a diagram illustrating an example of the notification information SDTT. In the example illustrated in FIG. 6, the notification information SDTT includes a table identification extension (table_id_ext), a target version (target_version), a new version (new_version), a download level (download_level), a version instruction (version_indicator), a version number (version_time), and a start time. (Start_time), distribution duration (duration), and descriptor area (descriptors ()).

The maker identification (maker_id) is described in the upper 8 bits of the table identification extension (table_id_ext), and the model identification (model_id) is described in the lower 8 bits.
The target version (target_version) describes the version identification of the software to be updated. In the new version (new_version), the version identification of the software transmitted by the transmission device 11 is described.
In the download level (download_level), a value indicating a download mode is stored. For example, “01” indicates forced download, and “00” indicates optional download.
The version instruction (version_indicator) indicates the range of versions to be updated. '00' indicates all versions, and '03' indicates only the specified version.

The start time (start_time) indicates a time at which the transmission apparatus 11 starts transmission of software.
The distribution continuation time (duration) indicates a time during which the transmission device 11 continues to transmit software. In the notification information SDTT, a plurality of start times (start_time) and distribution duration (duration) can be set.
In the descriptor area (descriptors ()), a download content descriptor and a network download content descriptor are described.

(Data structure of download content descriptor)
Next, the data structure of the download content descriptor will be described.
FIG. 7 is a diagram illustrating an example of a download content descriptor. The download content descriptor includes a compatibility flag (compatibility_flag), a compatibility descriptor (compatibilityDescriptor ()), a module number (num_of_modules), a module identification (module_id), a module size (module_size), and a private data area (description). Including.

The compatibility flag (compatibility_flag) is a flag indicating the presence or absence of a compatibility descriptor (compatibilityDescriptor ()). In the example illustrated in FIG. 7, the compatibility flag (compatibility_flag) is set with a flag indicating “presence / absence” of the compatibility descriptor (compatibilityDescriptor ()).
The compatibility descriptor (compatibilityDescriptor ()) includes the same content as the above-described compatibility descriptor (FIG. 4). Here, manufacturer identification (maker_id), model identification (model_id), and version identification (version_id) are described.

In the number of modules (num_of_modules), module identification (module_id), and module size (module_size), the number of modules in the DII / DDB message for transmitting software, the module identification, and the module size are described.
Download priority (download_priority) is described in the first byte of the private data area (private_data_byte). In the download priority (download_priority), a value indicating which of broadcast and communication is given priority as a download path is stored. In the following description, download priority (download_priority) may be referred to as a “priority flag”.

(Data structure of network download content descriptor)
Next, the data structure of the network download content descriptor will be described.
FIG. 8 is a diagram illustrating an example of a network download content descriptor. The network download content descriptor includes a compatibility flag (compatibility_flag), a compatibility descriptor (compatibilityDescriptor ()), a session protocol number (session_protocol_number), a reconnection count (retry), an address type (address_type), and an address type (address_type). ) And a port number (port_number).

  Also in the example shown in FIG. 8, the compatibility flag (compatibility_flag) is set with a value (1) indicating that there is a compatibility descriptor (compatibleDescriptor ()), as in the example shown in FIG. Yes. The compatibility descriptor (compatibilityDescriptor ()) includes the same content as the above-described compatibility descriptor (FIG. 4). Here, as described above, manufacturer identification (maker_id), model identification (model_id), and version identification (version_id) are described.

  The session protocol number (session_protocol_number) is a number indicating a protocol (for example, TCP: Transmission Control Protocol) used for network download, that is, download via the communication transmission path 22. The address type (address_type) is a number indicating the type of address indicating the location of the transmission source communication server. In the example shown in FIG. 8, any of IPv4, IPv6, and URL (Uniform Resource Locator) can be specified as the address type. The address indicates the location of the transmission source communication server (for example, the server device 21), and is an address represented by the type specified by the address type (address_type). The port number (port_number) indicates the port number of the communication server.

(Server device configuration)
Next, the configuration of the server device 21 will be described.
FIG. 9 is a block diagram showing a configuration of the server device 21 according to the present embodiment. The server device 21 includes a control unit 210, a communication unit 213, and a storage unit 214. The control unit 210 implements a distribution data acquisition unit 211 and a distribution data distribution unit 212 by executing a control program stored in the storage unit 214. The control unit 210 is, for example, a CPU.

  The distribution data acquisition unit 211 acquires the distribution data of the software generated by the distribution data generation unit 111 from the transmission device 11. The distribution data acquisition unit 211 reads the software manufacturer identification (maker_id), model identification (model_id), and version identification (version_id) from the DII included in the acquired distribution data. The distribution data acquisition unit 211 stores the read software maker identification (maker_id), model identification (model_id), and version identification (version_id) in association with the acquired distribution data in the storage unit 214. Accordingly, the server device 21 stores distribution data related to the latest version of software that can be transmitted at that time. In the following description, a set of manufacturer identification (maker_id), model identification (model_id), and version identification (version_id) may be referred to as “software identification”.

  The distribution data distribution unit 212 receives a distribution request signal from the receiving device 31. The distribution request signal is a signal for requesting distribution data related to the software identified by the designated software identification. The distribution data distribution unit 212 reads distribution data corresponding to the software identification designated by the distribution request signal from the storage unit 214. The distribution data distribution unit 212 transmits the read distribution data to the receiving device 31 via the communication transmission path 22.

The communication unit 213 transmits and receives various data between external devices, for example, the transmission device 11 and the reception device 31. Transmission / reception by each component of the server device 21 is performed via the communication unit 213. The communication unit 213 is, for example, a communication interface.
The storage unit 214 stores various data. The storage unit 214 includes a storage medium, for example, an HDD (Hard-Disk Drive), a flash memory, a ROM (Read-only Memory), a RAM (Random Access Memory), or any combination thereof.

(Receiver configuration)
Next, the configuration of the receiving device 31 will be described. FIG. 10 is a block diagram illustrating a configuration of the receiving device 31 according to the present embodiment. The reception device 31 includes a tuner 311 (reception unit), a decoding unit 312, a separation unit 313, an audio decoding unit 314, a reproduction unit 315, a video decoding unit 316, a display unit 317, a communication unit 321, a control unit 331, and a storage unit 341. It is comprised including.

The tuner 311 receives the multiplexed data from the transmission device 11 via the broadcast transmission path 12 using an antenna. The tuner 311 demodulates the received signal in the channel band received by radio waves into multiplexed data that is a baseband signal at the carrier frequency. The tuner 311 outputs the demodulated multiplexed data to the decoding unit 312.
The decryption unit 312 decrypts the multiplexed data (encrypted) input from the tuner 311 with a decryption method (for example, MULTI2) corresponding to the method used by the encryption unit 115 of the transmission device 11, Decoded multiplexed data is generated. The decoding unit 312 outputs the generated multiplexed data to the separation unit 313.

  The separation unit 313 separates the multiplexed data input from the decoding unit 312 into program data, distribution data, and notification information. The separation unit 313 outputs the distribution data and the notification information to the control unit 331. Further, the separation unit 313 extracts audio data and video data from the program data. The separation unit 313 outputs the extracted audio data to the audio decoding unit 314 and outputs the video data to the video decoding unit 316.

The audio decoding unit 314 receives audio data from the separation unit 313. The input audio data is data encoded by a predetermined audio encoding method (for example, MPEG-2 audio). The audio decoding unit 314 decodes audio data input by a decoding method corresponding to the encoding method used for encoding, and generates decoded audio data. The decoded audio data is data indicating the audio level at each time. The audio decoding unit 314 outputs the decoded audio data to the reproduction unit 315.
The reproduction unit 315 reproduces audio based on the audio data input from the audio decoding unit 314. The reproduction unit 315 includes, for example, a speaker.

The video decoding unit 316 receives video data from the separation unit 313. The input video data is data encoded by a predetermined video encoding method (for example, MPEG-2 video). The video decoding unit 316 decodes video data input by a decoding method corresponding to the encoding method used for encoding, and generates decoded video data. The decoded video data is data indicating signal values forming a video (frame image) at each time. The video decoding unit 316 outputs the decoded video data to the display unit 317.
The display unit 317 reproduces a video based on the video data input from the video decoding unit 316. The display unit 317 includes, for example, a display.

The communication unit 321 transmits and receives various data to and from the server device 21 via the communication transmission path 22. Transmission / reception by each component of the reception device 31 is performed via the communication unit 321. The communication unit 321 is, for example, a communication interface.
The control unit 331 controls various operations of the receiving device 31. For example, the control unit 331 extracts software related to the operation of the receiving device 31 from distribution data input (received by broadcasting) from the separation unit 313 in the time zone described in the notification information SDTT, and stores the extracted software in the storage unit Store in 341. In addition, when a failure is detected in the reception of software by broadcasting from the transmission device 11, the control unit 331 determines that the software reception path is communication. A functional configuration of the control unit 331 will be described later.
The storage unit 341 stores various data. The storage unit 341 includes a storage medium, for example, an HDD (Hard-disk Drive), a flash memory, a ROM (Read-only Memory), a RAM (Random Access Memory), or a combination thereof.

(Configuration of control unit)
Next, the configuration of the control unit 331 according to the present embodiment will be described. FIG. 11 is a block diagram illustrating a configuration of the control unit 331 according to the present embodiment. The control unit 331 includes a notification information analysis unit 332, a reception state determination unit 333, a reception route determination unit 334, and a software acquisition unit 335.

  The notification information analysis unit 332 extracts the start time (start_time) and the distribution duration (duration) from the notification information SDTT input from the separation unit 313, and specifies the distribution time. The notification information analysis unit 332 extracts manufacturer identification (maker_id), model identification (model_id), and version identification (version_id) from the notification information SDTT, and specifies the software to be received. The notification information analysis unit 332 determines the presence / absence of a priority flag (download_priority) from the notification information SDTT, and determines whether or not the priority order of the download route is set. When the notification information analysis unit 332 determines that there is a priority setting, the notification information analysis unit 332 specifies the priority. The notification information analysis unit 332 extracts the address of the communication server that is the transmission source (that is, the server device 21) from the notification information SDTT, and specifies the server device 21 that is the transmission source.

The reception state determination unit 333 determines whether or not a failure has occurred in receiving distribution data based on the distribution data input from the separation unit 313. The distribution data is data including the DII message and the DDB message obtained by dividing the software as described above. If the reception state determination unit 333 determines that a failure has occurred, the reception state determination unit 333 outputs a failure flag indicating the occurrence of the failure in the broadcast to the reception path determination unit 334.
In the present embodiment, the failure in reception means that reception has failed or that reception has failed. The fact that no failure has occurred means that reception has been successful or that reception has been successful. For example, the reception state determination unit 333 determines that a failure has occurred in reception when any of the following or a combination is applicable, and determines that no failure has occurred in reception when none of the following is true.

(1) The case where the data input from the separation unit 313 does not include the DII message related to the reception target software specified by the notification information analysis unit 332 and the corresponding DDB message.
(2) When at least a part of the DDB message constituting the delivery data is missing. The reception state determination unit 333 can determine whether or not a DDB message is missing by checking the number of modules described in the DDI message, the module ID, and the module ID described in the DDB message.
(3) The CRC value described in the DII message and the CRC value calculated by performing the cyclic redundancy check on the entire divided data (software) divided and stored in the DDB message do not match.
(4) The DII message and the corresponding DDB message relating to the software to be received are not input from the separation unit 313 within a predetermined time (for example, 3 minutes) from the end time of the delivery time specified by the notification information analysis unit 332 If (timeout).

  The reception path determination unit 334 determines the reception path based on the notification information SDTT analyzed by the notification information analysis unit 332. When the notification information analysis unit 332 determines that the priority flag (download_priority) is included, the reception path determination unit 334 determines to download the software through the reception path specified by the priority flag (download_priority). For example, when the value set in the priority flag (download_priority) is 0x01 or 0x02, the reception path determination unit 334 determines that the download is first performed by broadcasting, and determines the reception path as communication when the download fails. When the value set in the priority flag (download_priority) is 0x03, the reception path determination unit 334 determines that the download is first performed by communication, and determines the reception path as broadcast when the download fails.

  On the other hand, when the notification information analysis unit 332 determines that there is no priority flag (download_priority), the reception path determination unit 334 determines to download the software by broadcasting. However, when a failure flag is input from the reception state determination unit 333, that is, when downloading by broadcasting fails, it is determined that downloading is performed by communication. The reception path determination unit 334 outputs a reception path signal indicating which of communication and broadcast is used as the reception path to the software acquisition unit 335.

  The software acquisition unit 335 acquires software via the reception path determined by the reception path determination unit 334. When the reception path indicated by the reception path signal is broadcast, the software acquisition unit 335 inputs the software distribution data specified by the notification information analysis unit 332 from the reception state determination unit 333. When the reception path indicated by the reception path signal is communication, the software acquisition unit 335 generates a distribution request signal for requesting the software specified by the notification information analysis unit 332 and notifies the generated distribution request signal. The data is transmitted to the server device 21 specified by the information analysis unit 332. Accordingly, the software acquisition unit 335 can receive distribution data relating to software requested from the server device 21.

The software acquisition unit 335 extracts divided data from each DDB message constituting the input or received distribution data, and acquires the software by concatenating the extracted divided data in ascending order of module IDs attached to the DDB message. The software acquisition unit 335 stores the acquired software in the storage unit 341 in association with manufacturer identification (maker_id), model identification (model_id), and version identification (version_id) that specify the software.
When the notification information SDTT includes a descriptor that instructs activation of the software to be received, the control unit 331 may activate the acquired software and execute the function.

(Receiver operation)
Next, the operation of the receiving device 31 will be described. FIG. 12 is a flowchart showing the operation of the receiving device 31 according to this embodiment.
(Step S101) The separation unit 313 detects the notification information SDTT from the multiplexed data decoded by the decoding unit 312 from the broadcast wave received by the tuner 311 and separates the detected notification information SDTT. Thereafter, the process proceeds to step S102.
(Step S102) The notification information analysis unit 332 detects whether or not a priority flag (download_priority) is set in the notification information SDTT. Thereafter, the process proceeds to step S103.
(Step S103) The reception path determination unit 334 determines whether or not a priority order is specified for the reception path by a priority flag (download_priority). If it is determined that it is designated (step S103 YES), the process proceeds to step S105. If it is determined that it has not been designated (NO in step S103), the process proceeds to step S104.

(Step S104) The reception path determination unit 334 determines to download the software designated by the notification information SDTT by broadcasting. Thereafter, the process proceeds to step S106.
(Step S105) The reception path determination unit 334 determines to download the software specified by the notification information SDTT with the specified priority. The software acquisition unit 335 downloads the software through the reception path specified by the determined priority order. Then, the process shown in FIG.
(Step S <b> 106) The reception state determination unit 333 determines whether the download has succeeded without causing a failure based on the distribution data received by broadcasting. If it is determined that the process has succeeded (YES in step S106), the software acquisition unit 335 acquires the software downloaded by broadcasting, and ends the process shown in FIG. When it determines with having failed (step S106 NO), it progresses to step S107.
(Step S107) The reception path determination unit 334 determines to download the software designated by the notification information SDTT by communication. The software acquisition unit 335 downloads the software from the server device 21 by communication. Then, the process shown in FIG.

As described above, the reception device 31 according to the present embodiment includes the software acquisition unit 335 that acquires software related to the operation of the device itself, and the software reception path when a failure is detected in the reception of software by broadcasting. And a reception path determination unit 334 that determines communication as a communication (communication transmission path 22).
With this configuration, even when a failure is detected in receiving software by broadcasting, the software is acquired through communication, so that the software can be updated more reliably. Further, when the priority order of the reception path is not determined, since the broadcast is given priority as the reception path, the load on the communication transmission path 22 can be reduced.

(Second Embodiment)
A second embodiment of the present invention will be described with reference to the drawings. About the same structure as embodiment mentioned above, the same code | symbol is attached | subjected and description is used.
The receiving device 31 according to the present embodiment includes a control unit 331a instead of the control unit 331.
FIG. 13 is a block diagram illustrating a configuration of the control unit 331a according to the present embodiment. The control unit 331a includes a notification information analysis unit 332, a reception state determination unit 333a, a reception route determination unit 334a, and a software acquisition unit 335.

  The reception state determination unit 333a determines whether the reception state of the distribution data input from the separation unit 313 is good based on the reception state information input from the tuner 311. The reception status information is, for example, one or a combination of the electric field intensity of the broadcast wave detected by the tuner 311, the error rate of multiplexed data transmitted by the broadcast wave, and the CN value (Carrier-to-Noise Ratio). The reception state determination unit 333a generates reception state information indicating whether or not the reception state is good, and outputs the generated reception state information to the reception path determination unit 334a. For example, the reception state determination unit 333a determines that the reception state is inferior if any of the following is true, and determines that the reception state is good if none of the following is true. (A) The received electric field strength is lower than a predetermined electric field strength threshold, (b) the error rate is higher than the predetermined error rate threshold, and (c) the CN value is lower than the predetermined CN value threshold.

  Similarly to the reception route determination unit 334 (FIG. 11), the reception route determination unit 334a determines which reception route is to be prioritized based on reception when it is determined that the notification information SDTT has a priority flag (download_priority). Determine. For example, if the value set in the priority flag (download_priority) is 0x01 or 0x02, the reception path determination unit 334 determines that the broadcast is given priority. When the value set in the priority flag (download_priority) is 0x03, the reception path determination unit 334 determines that communication is prioritized. Also, when it is determined that there is no priority flag (download_priority), the reception path determination unit 334 determines that the broadcast is given priority.

  If the reception path determination unit 334a determines that priority is given to broadcasting, the reception path determination unit 334a determines the reception path based on the reception state information input from the reception state determination unit 333a. When the reception status information indicates that the reception status is good, the reception path determination unit 334a determines that the reception path is broadcast, and when the reception status information indicates that the reception status is poor, The reception path is defined as communication. The reception path determination unit 334a outputs a reception path signal indicating which of communication and broadcast is used as the reception path to the software acquisition unit 335.

(Receiver operation)
Next, the operation of the receiving device 31 will be described. FIG. 14 is a flowchart showing the operation of the receiving device 31 according to this embodiment. The process shown in FIG. 14 includes the processes of steps S101, S102, S113, S114, S115, S104, and S107. Since the process of step S101, S102, S104, and S107 is the same as the process of the applicable step shown in FIG. 12, the description is used.
In the processing shown in FIG. 14, after the processing of steps S101 and S102 is completed, the processing proceeds to step S113.

(Step S113) The reception path determination unit 334a determines whether to give priority to broadcasting as a reception path based on the notification information SDTT. When it is determined that the broadcast is given priority (YES in step S113), the process proceeds to step S114. When it is determined that communication is prioritized (NO in step S113), the process proceeds to step S107.
(Step S114) The reception state determination unit 333a determines whether the reception state of the distribution data input from the separation unit 313 is good based on the reception state information input from the tuner 311. Thereafter, the process proceeds to step S115.
(Step S115) If the reception state determined by the reception state determination unit 333a is good (YES in Step S115), the process proceeds to Step S104. When the reception state determined by the reception state determination unit 333a is inferior (NO in step S115), the process proceeds to step S107.

As described above, the reception device 31 according to the present embodiment includes the reception state determination unit 333a that determines the reception state of the broadcast wave, and the reception state determination unit 333a has a state that is worse than the predetermined reception state. Judged as a software reception failure.
This configuration ensures that the software is received using communication, which is a different reception route from the broadcast, because the software is received via communication when the broadcast reception status confirmed before receiving the software is poor. It can be carried out.

(Third embodiment)
A third embodiment of the present invention will be described with reference to the drawings. About the same structure as embodiment mentioned above, the same code | symbol is attached | subjected and description is used.
The receiving device 31 according to the present embodiment includes a control unit 331b instead of the control unit 331.
FIG. 15 is a block diagram illustrating a configuration of the control unit 331b according to the present embodiment. The control unit 331b includes a notification information analysis unit 332, a reception state determination unit 333b, a reception route determination unit 334b, a software acquisition unit 335, and a program reservation unit 336b.

  The program reservation unit 336b receives an input signal by a user's operation, and specifies a program to be viewed or recorded and a reception time of the program to be viewed or recorded by the input signal. The program scheduled to be broadcast and its broadcast time are represented in an EPG (Electronic Program Guide) included in the section data separated from the multiplexed data by the separation unit 313. The program reservation unit 336b generates program reservation information indicating the specified program and the reception time, and stores the generated program reservation information in the storage unit 341.

  The reception state determination unit 333b determines whether or not the program reservation information is stored in the storage unit 341. When it is determined that it is stored, the reception state determination unit 333b reads the program reservation information from the storage unit 341, and part or all of the delivery time specified based on the notification information SDTT by the notification information analysis unit 332 is It is determined whether or not it overlaps with part or all of the reception time of the program indicated by the program reservation information. The reception state determination unit 333b outputs reception state information indicating whether or not they overlap, to the reception path determination unit 334b.

  Similarly to the reception route determination unit 334a, the reception route determination unit 334b determines which reception route has priority based on the notification information analyzed by the notification information analysis unit 332. However, if the reception path determination unit 334b determines that the broadcast is given priority and indicates that the reception state information input from the reception state determination unit 333b is duplicated, the software specified by the notification information SDTT is downloaded by broadcasting. judge. When the reception status information indicates that there is no duplication, the reception path determination unit 334b determines to download via communication.

(Receiver operation)
Next, the operation of the receiving device 31 will be described. FIG. 16 is a flowchart showing the operation of the receiving device 31 according to this embodiment. The process shown in FIG. 16 includes the processes of steps S101, S102, S113, S124, S125, S104, and S107. The processes of steps S101, S102, S104, and S107 are the same as the processes of steps S101, S102, S104, and S107 shown in FIG. 12, respectively. The process of step S113 is the same as the process of step S113 shown in FIG. Therefore, those explanations are incorporated. In the process shown in FIG. 16, when the reception path determination unit 334b determines that the broadcast is given priority as the reception path in step S113 performed after the processes of steps S101 and S102 are completed (YES in step S113), the process proceeds to step S124. move on.

(Step S124) The reception state determination unit 333b determines whether or not the program reservation information generated by the program reservation unit 336b is stored in the storage unit 341. If it is determined that the information is stored, the reception state determination unit 333b reads the program reservation information, and a part or all of the distribution time indicated in the notification information SDTT is the reception time of the program indicated by the read program reservation information. It is determined whether or not some or all overlap (reservation confirmation). Thereafter, the process proceeds to step S125.

(Step S125) The reception state determination unit 333b has a part or all of the delivery time indicated in the notification information SDTT overlapped with part or all of the reception time of the program indicated by the read program reservation information (reserved). (Step S125 YES), the process proceeds to step S107. When the reception state determination unit 333b determines that part or all of the distribution time indicated in the notification information SDTT does not overlap with part or all of the reception time of the program indicated by the read program reservation information (step S125 NO), the process proceeds to step S104.

As described above, the receiving device 31 according to the present embodiment includes the notification information analysis unit 332 that analyzes the notification information indicating the software distribution time, and the program reservation unit 336b that reserves reception of the program. Also, the reception state determination unit 333b determines that a state in which at least a part of the reception time indicated by the notification information overlaps at least a part of the reception time of the program reserved by the program reservation unit 336b is a software reception failure. To do.
With this configuration, even when the tuner is expected to be occupied for the reception of a program reserved for reception, the receiving device 31 can reliably receive software by communication and be compatible with reception of a program reserved for reception. it can.

(Fourth embodiment)
A fourth embodiment of the present invention will be described with reference to the drawings. About the same structure as embodiment mentioned above, the same code | symbol is attached | subjected and description is used.
The receiving device 31 according to the present embodiment includes a control unit 331c instead of the control unit 331. FIG. 17 is a block diagram illustrating a configuration of the control unit 331c according to the present embodiment. The control unit 331c includes a notification information analysis unit 332, a reception state determination unit 333c, a reception route determination unit 334c, and a software acquisition unit 335c.

The reception state determination unit 333c determines the reception state of the distribution data using the same method as the reception state determination unit 333. However, when a download failure is detected during input from the distribution data separator 313, that is, during download, the reception state determination unit 333c interrupts input of distribution data. When the reception state determination unit 333c determines that a failure has occurred, the reception state determination unit 333c outputs a failure flag indicating the occurrence of a failure in the broadcast to the reception path determination unit 334c.
The reception state determination unit 333c refers to the module identification described in the input DII message in the DDB message that constitutes the distribution data transmitted by the transmission device 11, and is an unreceived part that has not been input. The module of the DDB message is specified. The reception state determination unit 333c generates unreceived information indicating a module of an unreceived DDB message. The reception state determination unit 333c outputs the input DII message, the completed DDB message, and the unreceived information to the software acquisition unit 335c.

  Similarly to the reception path determination unit 334, the reception path determination unit 334c determines the reception path based on the notification information SDTT. However, the reception path determination unit 334c determines that the reception path is communication and uses the communication as the reception path when the failure flag is input from the reception state determination unit 333c during reception of the distribution data in broadcasting. The received reception path signal is output to the software acquisition unit 335c.

  The software acquisition unit 335c generates a distribution request signal for requesting an unreceived DDB message indicated by unreceived information input from the reception state determination unit 333c among the software specified by the notification information analysis unit 332. The software acquisition unit 335c receives a reception path signal indicating that communication is used as the reception path from the reception path determination unit 334c, and determines the transmission source of the distribution data as the server device 21 specified by the notification information analysis unit 332. The software acquisition unit 335 c transmits the generated distribution request signal to the server device 21 specified by the notification information analysis unit 332. The server device 21 transmits an unreceived DDB message to the receiving device 31 among the distribution data related to the software designated by the distribution request signal. Thereby, the software acquisition unit 335c can receive the DDB message indicated by the unreceived information. The software acquisition unit 335c extracts divided data from each of the input DDB message and the newly received DDB message indicated by the unreceived information, and concatenates the extracted divided data in ascending order of module identification (moduleId). Get the software. The software acquisition unit 335 c stores the acquired software in the storage unit 341 in the same manner as the software acquisition unit 335.

(Receiver operation)
Next, the operation of the receiving device 31 will be described. FIG. 18 is a flowchart showing the operation of the receiving device 31 according to this embodiment. The process shown in FIG. 18 includes the processes of steps S104, S136, and S137.

(Step S104) The reception path determination unit 334c determines to download the software designated by the notification information SDTT by broadcasting. Thereafter, the process proceeds to step S136.
(Step S136) The reception state determination unit 333c detects whether or not a failure has occurred in the download during the broadcast download. When a failure is detected, the reception state determination unit 333c identifies an unreceived DDB message. Thereafter, the process proceeds to step S137.
(Step S137) The reception path determination unit 334c determines that the reception path is communication. The software acquisition unit 335c downloads an unreceived DDB message including a part of software designated by the notification information SDTT from the server device 21 by communication. Then, the process shown in FIG. 18 is complete | finished.

As described above, in the receiving device 31 according to the present embodiment, the reception path determination unit 334c communicates the communication path of software (communication transmission) when a failure is detected before the reception of software by broadcasting is completed. Path 22), the software acquisition unit 335 is caused to receive an unreceived portion of the software by communication.
With this configuration, the part of the reception software that has been received by broadcasting is used, and only the part that has not been received is acquired by communication. Since it is possible to reduce the amount of information and the time required for the part received by communication, it is possible to save communication resources with a limited transmission capacity.

It should be noted that the present invention is not limited to the above-described embodiments, and various modifications are possible within the scope indicated in the claims, and the technical configurations disclosed in different embodiments are appropriately combined. The obtained embodiment is also included in the technical scope of the present invention.
Each component of the present invention can be arbitrarily selected, and an invention having a selected configuration is also included in the present invention.

For example, the transmission device 11 and the server device 21 may be configured as a single transmission device. In the receiving device 31, both or one of the reproduction unit 315 and the display unit 317 may be omitted. Further, either the audio decoding unit 314 or the video decoding unit 316 may be omitted.
Further, the transmission device 11 may include any one of the control units 331, 331a, 331b, and 331c, an arbitrary set of some of them, or all of them.
In the above-described embodiment, the case where the system defined by MPEG-2 Systems is used as an example of the transmission system for transmitting various types of data. However, other transmission systems such as MPEG-H are used. A media transport system based on MMT (MPEG Media Transport) may be used. In addition, a data format, an encryption method, and an encoding method related to transmission may be a format or a method defined by the transmission method.

  In addition, a part of the transmission device 11, the part of the server device 21, and the part of the reception device 31 in the above-described embodiment may be realized by a computer. In that case, the program for realizing the control function may be recorded on a computer-readable recording medium, and the program recorded on the recording medium may be read by the computer system and executed. Here, the “computer system” is a computer system built in the recognition data transmission apparatus, and includes an OS and hardware such as peripheral devices. The “computer-readable recording medium” refers to a storage device such as a flexible medium, a magneto-optical disk, a portable medium such as a ROM and a CD-ROM, and a hard disk incorporated in a computer system. Furthermore, the “computer-readable recording medium” is a medium that dynamically holds a program for a short time, such as a communication line when transmitting a program via a network such as the Internet or a communication line such as a telephone line, In this case, a volatile memory inside a computer system that serves as a server or a client may be included that holds a program for a certain period of time. The program may be a program for realizing a part of the functions described above, and may be a program capable of realizing the functions described above in combination with a program already recorded in a computer system.

In addition, this invention can be implemented also in the following aspect.
(1) A software acquisition unit that acquires software relating to the operation of the device itself, and a reception path determination unit that determines that the reception path of the software is communication when a failure is detected in reception of the software by broadcasting. Receiver device.

(2) The reception apparatus according to (1), further including a reception state determination unit that determines a reception state of a broadcast wave, wherein the failure is a state in which the reception state is worse than a predetermined reception state.

(3) a notification information analysis unit that analyzes notification information indicating a distribution time of the software, a program reservation unit that reserves reception of a program, and the failure includes at least a part of the reception time indicated by the notification information, The receiving apparatus according to (1) or (2), wherein the program reservation unit overlaps at least a part of a reception time of a program reserved for reception.

(4) When the failure is detected before reception of the software by broadcasting is completed, the reception path determination unit determines that the reception path of the software is communication, and an unreceived part of the software is determined as the communication. The receiving device according to any one of (1) to (3), which is received by the software acquisition unit.

(5) A broadcasting system including a transmitting device that transmits software related to the operation of the receiving device through broadcasting, a server device that stores the software, and the receiving device, wherein the receiving device acquires the software A broadcasting system comprising: a software acquisition unit; and a reception path determination unit that determines that the reception path of the software is communication when a failure is detected in reception of the software by broadcasting.

(6) A reception method in the reception device, wherein when a failure is detected in an acquisition process of acquiring software related to the operation of the reception device and reception of the software by broadcasting, the reception path of the software is determined to be communication And a reception path determination process.

(7) An acquisition procedure for acquiring software related to the operation of the receiving device in the computer of the receiving device, and a receiving route determination for determining that the software receiving route is communication when a failure is detected in receiving the software by broadcasting Program to execute the procedure.

1 ... broadcast system,
DESCRIPTION OF SYMBOLS 11 ... Transmission apparatus, 111 ... Delivery data generation part, 112 ... Program data generation part, 113 ... Notification information generation part, 114 ... Multiplexing part, 115 ... Encryption part, 116 ... Transmission part, 12 ... Broadcast transmission path, 13 ... broadcast satellite, 21 ... server equipment,
210: Control unit, 211: Distribution data acquisition unit, 212: Distribution data distribution unit, 213 ... Communication unit, 214 ... Storage unit, 22 ... Communication transmission path, 31 ... Receiver, 311 ... Tuner, 312 ... Decoding unit, 313 ... separation unit, 314 ... audio decoding unit, 315 ... reproduction unit, 316 ... video decoding unit, 317 ... display unit, 321 ... communication unit, 331, 331a, 331b, 331c ... control unit, 332 ... notification information analysis unit, 333 333a, 333b, 333c ... reception state determination unit, 334, 334a, 334b, 334c ... reception path determination unit, 335, 335c ... software acquisition unit, 336b ... program reservation unit, 341 ... storage unit

Claims (7)

A software acquisition unit that acquires software related to the operation of the device;
A reception path determination unit that determines that the reception path of the software is communication when a failure is detected in reception of the software by broadcasting; and
A receiving device. A reception state determination unit for determining the reception state of the broadcast wave;
The receiving device according to claim 1, wherein the failure is a state in which the reception state is worse than a predetermined reception state. A notification information analysis unit for analyzing notification information indicating a delivery time of the software;
A program reservation section for reserving program reception;
3. The failure according to claim 1, wherein at least a part of a reception time indicated by the notification information overlaps at least a part of a reception time of a program reserved for reception by the program reservation unit. Receiver device. The reception path determination unit
2. When the failure is detected before reception of the software by broadcasting is completed, the software reception path is determined as communication, and an unreceived portion of the software is received by the software acquisition unit. The receiving device according to claim 3. A broadcasting system comprising: a transmitting device that transmits software related to the operation of a receiving device through broadcasting; a server device that stores the software; and the receiving device,
The receiving device is:
A software acquisition unit for acquiring the software;
A reception path determination unit that determines that the reception path of the software is communication when a failure is detected in reception of the software by broadcasting; and
A broadcasting system comprising: A receiving method in a receiving device,
An acquisition process of acquiring software related to the operation of the receiving device;
A reception path determination process for determining that the reception path of the software is communication when a failure is detected in reception of the software by broadcasting;
Receiving method. In the computer of the receiving device,
Acquisition procedure for acquiring software related to the operation of the receiving device,
A program for executing a reception path determination procedure for determining that the reception path of the software is communication when a failure is detected in reception of the software by broadcasting.

Images