JP7386768B2 - Receiver, method and program - Google Patents

Description

Embodiments relate to receivers, methods, and programs.

A receiver (hereinafter simply referred to as a receiver) that supports BS digital broadcasting, 110-degree CS digital broadcasting, terrestrial digital broadcasting (also collectively referred to as 2K broadcasting), and advanced wideband satellite digital broadcasting (also referred to as 4K/8K broadcasting). The device is equipped with NVRAM (Non-Volatile Memory), which is a rewritable storage medium that retains its stored contents even when the power is turned off (that is, non-volatile). NVRAM is used as a storage medium (also called NVRAM for data broadcasting) for data handled in data broadcasting (also called receiver data), which is one of the services implemented in 2K broadcasting and 4K/8K broadcasting. . NVRAM for data broadcasting can be accessed from data broadcasting content created and transmitted by broadcasters and executed on receivers, but for certain broadcasts, for example, accessible areas are determined for each broadcaster. Access control technology has been provided for concealing data recorded by a broadcaster in a data broadcasting NVRAM from other broadcasters.

Patent No. 5027636

ARIB TR-B14 6.2 edition “Digital Terrestrial Television Broadcasting Operation Regulations” ARIB TR-B39 2.2 edition “Advanced Wideband Satellite Digital Broadcasting Operation Regulations”

However, a third party who is not the owner of the receiver or the broadcaster may access the data broadcasting content by a method other than accessing it (for example, by connecting a readout device to the semiconductor memory that is the substance of the NVRAM for data broadcasting). If the data recorded in the data broadcasting NVRAM is read out using a third party method, the third party can obtain the information represented by the data. In other words, the confidentiality of information is not ensured. Since data recorded in NVRAM, which is a non-volatile storage medium, is retained unless explicitly deleted, there is a possibility that the information could be retrieved by a third party, for example, if the receiver is transferred to another person or disposed of. is possible. Depending on the data broadcasting content created by the broadcaster (including those created in the future), information such as personal information that could cause serious problems if retrieved by a third party may not be recorded in the data broadcasting NVRAM. In view of this, it is necessary to ensure the confidentiality of information even if the data is taken out by a third party.

The problem to be solved by the present invention is to provide a receiver, a method, and a program for recording and collecting receiver data while ensuring the confidentiality of information.

A receiver for digital television broadcasting according to an embodiment is a receiver for digital television broadcasting, and includes a broadcast signal receiving means for receiving a broadcast signal, and a read command included in the broadcast signal. information reading means for reading encrypted data obtained by encrypting certain receiver data with an encryption key from the information storage means; and transmitting the encrypted data to an external device based on a transmission command included in the broadcast signal. and information transmitting means.

FIG. 1 is a block diagram showing an example of the configuration of a system according to an embodiment. FIG. 2 is a block diagram showing an example of the functional configuration of a transmitter of a broadcasting station according to the embodiment. FIG. 3 is an example of API commands that can be written in the application data generation unit of the transmitter according to the embodiment. FIG. 4 is a block diagram showing an example of a functional configuration of a server of a broadcasting station according to an embodiment. FIG. 5 is a block diagram showing an example of the functional configuration of the receiver according to the embodiment. FIG. 6 is a diagram illustrating an example of the accumulated data area of the information accumulation section of the receiver according to the embodiment. FIG. 7 is a block diagram illustrating an example of the functional configuration of the application execution unit of the receiver according to the embodiment. FIG. 8 is a sequence chart showing an example of the operation of the system according to the first embodiment. FIG. 9 is a flowchart illustrating an example of the processing operation of the transmitter according to the embodiment. FIG. 10 is a flowchart showing an example of the processing operation of the receiver in the same embodiment. FIG. 11 is a flowchart illustrating an example of the processing operation of the application execution unit when acquiring an encryption key in the same embodiment. FIG. 12 is a flowchart illustrating an example of the processing operation of the server when acquiring an encryption key in the same embodiment. FIG. 13 is a flowchart illustrating an example of the processing operation of the application execution unit when writing data in the same embodiment. FIG. 14 is a flowchart illustrating an example of the processing operation of the application execution unit when reading data in the same embodiment. FIG. 15 is a flowchart illustrating an example of the processing operation of the application execution unit during data transmission in the same embodiment. FIG. 16 is a flowchart showing an example of the processing operation of the server when receiving data in the same embodiment. FIG. 17 is a sequence chart of the system according to the second embodiment. FIG. 18 is a flowchart illustrating an example of the processing operation of the transmitter according to the embodiment. FIG. 19 is a flowchart illustrating an example of the processing operation of the application execution unit when acquiring an encryption key in the same embodiment. FIG. 20 is a sequence chart of the system according to the third embodiment. FIG. 21 is an example of a case where an encryption key is transmitted using the SI of broadcast wave 4 of the TS system in the same embodiment. FIG. 22 is an example of transmitting an encryption key using SI of broadcast wave 4 of the MMT system in the same embodiment. FIG. 23 is a flowchart showing an example of the processing operation of the receiver in the same embodiment. FIG. 24 is a flowchart illustrating an example of the processing operation of the application execution unit when writing data in the same embodiment. FIG. 25 is a flowchart illustrating an example of the processing operation of the write processing section when writing data in the fourth embodiment. FIG. 26 is a flowchart illustrating an example of the processing operation of the application execution unit when writing data in the same embodiment.

Hereinafter, embodiments will be described with reference to the drawings.

FIG. 1 is a block diagram showing an example of the configuration of a system according to an embodiment.

The broadcast station 10 is a 2K broadcast or 4K/8K broadcast station. In particular, when distinguishing between a 2K broadcast station and a 4K/8K broadcast station, they are referred to as a 2K broadcast station and a 4K/8K broadcast station, respectively. Broadcasting station 10 includes a transmitter 1 and a server 2.

The transmitter 1 transmits a digital broadcast signal including application data, various control information, etc. onto a broadcast wave such as 2K broadcast or 4K/8K broadcast, and outputs the broadcast wave from an antenna, a cable, or the like.

The server 2 is, for example, a computer, and includes a communication interface for communicating with external devices, a CPU for processing data, and the like. Specifically, the server 2 exchanges various data with the receiver 3 via the network 5. Further, the server 2 exchanges various data with the transmitter 1 via the network 6. The transmitter 1 can transmit data obtained from the server 2 using broadcast waves 4. Although FIG. 1 shows only one broadcast station 10 and one receiver 3, there are usually a plurality of broadcast stations 10 (transmitter 1, server 2) and receivers 3. In this case, the server 2 of each broadcast station can exchange data with a plurality of receivers 3, respectively. Furthermore, the transmitters 1 of each broadcasting station individually output broadcast waves 4, and each receiver 3 can receive one or more broadcast waves 4 from a plurality of transmitters 1.

The broadcast wave 4 is, for example, a radio wave, but may be output from an antenna or may be transmitted by wire such as cable broadcasting.

The network 5 is, for example, a telecommunications line such as the Internet, and its medium may be wireless or wired.

The network 6 is an interface for mainly communicating between the transmitter 1 and the server within the broadcasting station, and may be, for example, a telecommunications line such as the Internet, or a dedicated line. The medium may be wireless or wired.

FIG. 2 is a block diagram showing an example of the functional configuration of a transmitter of a broadcasting station according to the embodiment.

The transmitter 1 generates a broadcast stream (digital data stream) according to various digital broadcast standards from, for example, a digital broadcast signal (digital data for digital broadcast) obtained from the server 2, application data, various control information, etc. A digital data stream is output via broadcast waves 4. The standards for various digital broadcasts may be, for example, the MPEG2 transport stream system (TS system), which is a transmission system for 2K broadcasting, or the MPEG Media Transport system (MMT system), which is a transmission system for 4K/8K broadcasts.

The service data stream generation unit 11 encodes service data such as video, audio, subtitles, etc. by encoding including information source encoding or packetizing according to various digital broadcasting standards. Generate a stream.

The control information generation unit 12 generates control information regarding presentation of service data, control information for controlling an application (hereinafter referred to as application control information), and the like.

The application stream generation unit 13 generates a data stream of application data by encoding the application data, including information source encoding according to various digital broadcasting standards, and by packetizing the application data. Application data is generated as a data stream (application stream) based on a method conforming to various digital broadcasting standards, such as a data carousel method or an event message method.

The application data generation unit 14 generates data of an application to be executed in the receiver 3. In this embodiment, the application data generation unit 14 generates application data including commands for the Application Programming Interface (API) shown in FIG. 3 (hereinafter referred to as API commands). API is an interface provided to applications by the application engine, which is an execution program installed in the receiver 3, and is an interface for broadcasting extension functions (or broadcasting Also called extension object). The applications in this embodiment are assumed to be data broadcasting applications (in the case of 4K/8K broadcasting) and data broadcasting contents (in the case of 2K broadcasting). Specifically, files written in Broadcast Markup Language (BML), HyperText Markup Language (HTML), etc. (referred to as BML files and HTML files, respectively) are sent, and in this embodiment, these files include the following: Contains API commands for executing APIs such as Details will be described in the explanation of FIG.
・API to acquire and store the encryption key used for encryption (encryption key acquisition API)
・Data writing API (with encryption)
・Encrypted data read API (no decryption)
・Data transmission API
In this embodiment, the application data generation unit 14 is a function of the transmitter 1, but it may be a function of the server 2. When the application data generation unit 14 is a function of the server 2, the application data generated by the application data generation unit 14 is transmitted to the transmitter 1 via the network 6.

The encryption key storage unit 15 stores an encryption key for asymmetric encryption generated by the server 2 and outputs it to the application data generation unit 14 .

The broadcast stream generation unit 16 includes, for example, a multiplexer, multiplexes the data streams output by the service data stream generation unit 11, the control information generation unit 12, and the application stream generation unit 13 according to various digital broadcasting standards, and generates a broadcast stream. Output.

The broadcast signal transmitter 17 performs encoding and modulation, including transmission channel encoding, in accordance with various digital broadcasting standards, on the digital data of the broadcast stream, generates broadcast waves 4, and transmits them to an antenna (not shown). , output to a cable, etc.

The communication unit 18 is a function for communicating with the server 2, and when communicating via the network 6, for example, it implements a communication protocol applied to the network 6 (IP communication method, leased line method, etc.).

FIG. 3 is an example of API commands that can be written in the application data generation unit 14 of the transmitter according to the embodiment, and each column shows the API number from the left. (numbers in FIG. 3), API functions, and API commands (API names, arguments, etc.) for the API functions are described in BML or HTML. Here, API is an interface provided to the application by the application engine, which is an executable program installed in the receiver 3, and what the transmitter 1 writes in the BML file or HTML file is the API command ( API name, arguments to the API, etc.).

No. Line 1 is an API command that causes the encryption key acquisition API to be executed, and is an API command that causes the receiver 3 to acquire an encryption key used for encryption from the server 2.

In the case of BML, for example, this is an API command that calls downloadBroadcasterCertificate, which is an API defined as a method of a browser pseudo object defined in ARIB STD-B24. The API command is, for example, downloadBroadcasterCertificate (argument). In this embodiment, the argument includes at least information that identifies the encryption key to be obtained from the server 2 (for example, the URL "https://server 2 address/encryption key file path"); Other contents (for example, identification information indicating attributes of the encryption key) that the receiver 3 is allowed to acquire may also be included.

In the case of HTML, for example, it is an API command that calls downloadBroadcasterCertificate, which is an API defined as a method of the ReceiverDevice object specified in ARIB STD-B62. The API command is, for example, downloadBroadcasterCertificate (argument). In this embodiment, the argument includes at least information that identifies the encryption key to be obtained from the server 2 (for example, the URL "https://server 2 address/encryption key file path"); Other contents (for example, identification information indicating attributes of the encryption key) that the receiver 3 is allowed to acquire may also be included.

No. The reliability of the encryption key that the receiver 3 obtains using the API command No. 1 may be ensured by the reliability of a hypertext transfer protocol secure (https) connection. No. When using API No. 1, the receiver 3 first establishes a connection with the broadcast station server 2 using https, and acquires an encryption key from the broadcast station server 2 through communication over the https connection. The server 2 is authenticated from the receiver 3's perspective through the https connection, and the reliability of the acquired encryption key is ensured.

No. Line 2 is an API command that causes the encryption key acquisition API to be executed, and is an API command that causes the receiver 3 to acquire the encryption key that is being transmitted in the application stream that is being broadcast.

In the case of BML, for example, this is an API command that calls downloadBroadcasterCertificate, which is an API defined as a method of a browser pseudo object defined in ARIB STD-B24. The API command is, for example, downloadBroadcasterCertificate (argument). In this embodiment, the argument includes at least information that identifies the storage location of the encryption key in the broadcast data (broadcast signal) (for example, the URL "arib-dc://encryption key resource name"). However, other contents (for example, identification information indicating attributes of the encryption key) that the receiver 3 is allowed to acquire may also be included.

In the case of HTML, for example, it is an API command that calls downloadBroadcasterCertificate, which is an API defined as a method of the ReceiverDevice object specified in ARIB STD-B62. The API command is, for example, downloadBroadcasterCertificate (argument). In this embodiment, the argument includes at least information that identifies the storage location of the encryption key in the broadcast data (broadcast signal) (for example, the URL "arib-dc2://encryption key resource name"). However, other contents (for example, identification information indicating attributes of the encryption key) that the receiver 3 is allowed to acquire may also be included.

No. Line 3 is an API command that causes the data writing API to be executed, which causes the receiver 3 to encrypt the receiver data and store the encrypted data (hereinafter referred to as encrypted data) in the information storage of the receiver 3. This is an API command to be written into the unit 36 (NVRAM for data broadcasting).

In the case of BML, for example, this is an API command that calls writePersistentArray, which is an API defined in ARIB STD-B24. The API command is, for example, writePersistentArray (argument). The arguments of the API command include at least information that identifies receiver data to be written to the receiver 3 as encrypted data (receiver data identification information), and information that identifies the receiver data to be written as encrypted data to the receiver 3. (encrypted write instruction information) and information that identifies the storage location where the encrypted data is written (storage location identification information). For example, the receiver data identification information may be as specified in ARIB TR-B14. In addition, regarding receiver data identification information and storage location identification information, "nvram://~/<block number" is a form of information that identifies the storage location in NVRAM for data broadcasting specified in ARIB TR-B14. >” URI (Uniform Resource Identifier) may be replaced by a URI “nvrame://~/<block number>”. Here, the meanings of ~ and <block number> are values based on the specifications of ARIB TR-B14.

In the case of HTML, for example, this is an API command that calls setItem, which is an API that uses a method of the LocalStorage object whose operation is specified in ARIB TR-B39. The API command is, for example, setItem (argument). The argument of the API command includes at least receiver data identification information, encryption write instruction information, and storage location identification information. For example, the receiver data identification information may be as specified in ARIB TR-B39. For the encrypted write instruction information and storage location identification information, for example, instead of the access key name specified in ARIB TR-B39, such as "_wlocal" + item number, "_e_wlocal" + item number. ", for example, "_e_wlocal0" may be used.

No. Line 4 is an API command that causes the data writing API to be executed, which causes the receiver 3 to encrypt receiver data and store the encrypted data (hereinafter referred to as encrypted data) in the information storage of the receiver 3. This is an API command to be written into the unit 36 (NVRAM for data broadcasting).

In the case of BML, for example, this is an API command that calls writePersistentArrayEncrypted, which is an API based on writePersistentArray defined in ARIB STD-B24. The API command is, for example, writePersistentArrayEncrypted (argument). The argument of the API command includes at least receiver data identification information and storage location identification information. For example, the above No. It may be an argument according to the embodiment of the argument in the API command in the case of BML in line 3, or it may be an argument according to the argument of writePersistentArray defined in ARIB TR-B14. In the latter case, receiver 3 recognizes from "Encrypted" included in the API name that it is necessary to encrypt the data to be written to NVRAM, encrypts the write data specified in the argument, and then writes it to NVRAM. It may also be stored.

In the case of HTML, for example, this is an API command that calls setItemEncrypted, which is an API that conforms to the method of the LocalStorage object whose operation is specified in ARIB TR-B39. The API command is, for example, setItemEncrypted (argument). The argument of the API command includes at least receiver data identification information to be written into the receiver 3 as encrypted data and storage location identification information. For example, the above No. It may be an argument according to the embodiment of the argument in the API command in the case of HTML in line 3, or it may be an argument according to the argument of setItem defined in ARIB TR-B39. In the latter case, receiver 3 receives No. When API 4 is called, it recognizes that the data written to NVRAM needs to be encrypted from "Encrypted" included in the API name, encrypts the write data specified as an argument, and then writes it to NVRAM. It may also be stored. In this embodiment, the receiver 3 is No. 1 or No. Using the encryption key obtained with API No. 2, 3 and no. An example of writing with encryption using API No. 4 is shown below.

No. 3 and no. The NVRAM area in which encrypted data is written using the API command No. 4 may be a different area from the NVRAM area specified by ARIB TR-B14 or ARIB TR-B39, or may be the same area. For example, No. In the BML API command of 3, the area represented by the URL “nvram://~/0” that indicates the storage location to write the encrypted data is the URL “nvram://~/0” specified by ARIB TR-B14. It may be a different area from the area represented by ``, or it may be the same area. No. The same holds true for the area represented by the access key in the HTML API command No. 3. Furthermore, for example, No. 3 and no. For example, when specifying the URL "nvram://~/0" in the BML API command No. 4, that is, writePersistentArray (argument) and writePersistentArrayEncrypted (argument), the former No. The area where the receiver 3 writes data when the API is called by the API command No. 3, and the area where the receiver 3 writes data when the API is called by the API command No. The areas in which the receiver 3 writes encrypted data when the API is called by the API command No. 4 may be separate areas or may be the same area. No. The same applies to the HTML API commands in No. 4.

No. Line 5 is an API command that causes the encrypted data reading API to be executed, and is an API command that causes the receiver 3 to read encrypted data from the information storage unit 36 .

In the case of BML, for example, it is an API command that calls ReadPersistentArray, which is an API defined in ARIB STD-B24. The API command is, for example, ReadPersistentArray (argument). The argument of the API command includes at least information that identifies the storage location of the encrypted data to be read by the receiver 3 (storage location identification information, for example, nvrame://~/<block number>). However, ~ and <block number> are the above No. This is the same as in case 3.

In the case of HTML, for example, this is an API command that calls getItem, which is an API defined as a method of the LocalStorage object whose operation is specified in ARIB TR-B39. The API command is, for example, getItem (argument). The argument of the API command includes information that identifies the storage location of the encrypted data to be read by the receiver 3 (storage location identification information, for example, "_e_wlocal"+item number). The item number is the above No. This is the same as in case 3.

No. Line 6 is an API command that causes the encrypted data reading API to be executed, and is an API command that causes the receiver 3 to read encrypted data from the information storage unit 36 .

In the case of BML, for example, this is an API command that calls ReadPersistentArrayEncrypted, which is an API based on ReadPersistentArray defined in ARIB STD-B24. The API command is, for example, ReadPersistentArrayEncrypted (argument). The argument of the API command includes at least the storage location identification information of the encrypted data to be read by the receiver 3. As the storage location identification information of the encrypted data to be read, for example, "nvram://~/<block number", which is a form of information that identifies the storage location in the NVRAM for data broadcasting specified in ARIB TR-B14. >" URI may be specified. At this time, in the case of an embodiment in which encrypted data and non-encrypted receiver data are stored in different areas even if they have the same block number, the receiver 3 stores No. When the API command No. 6 is received, it may be recognized from "Encrypted" included in the API name that the encrypted data is to be read from the area storing it, and the encrypted data may be read from the NVRAM.

In the case of HTML, for example, this is an API command that calls getItemEncrypted, which is an API based on the LocalStorage object whose operation is specified in ARIB TR-B39. The API command is, for example, getItemEncrypted (argument). The argument of the API command includes at least information identifying the storage location of the encrypted data to be read by the receiver 3. For example, an access key name defined in ARIB TR-B39 may be specified as the information for identifying the storage location of the encrypted data to be read. At this time, in the case of an embodiment in which encrypted data and non-encrypted receiver data are stored in different areas even if they have the same block number, the receiver 3 stores No. When the API command No. 6 is received, it may be recognized from "Encrypted" included in the API name that the encrypted data is to be read from the area storing it, and the encrypted data may be read from the NVRAM.

No. Line 7 is an API command that causes the data transmission API to be executed, and is an API command that causes the receiver 3 to transmit encrypted data to the server 2 of the broadcasting station.

In the case of BML, for example, it is an API command that calls transmitTextDataOverIP, which is an API defined in ARIB STD-B24. The API command is, for example, transmitTextDataOverIP (argument). In this embodiment, the arguments of the API command include No. 4 or No. It includes the encrypted data read using API command No. 5 and information identifying the destination. In this embodiment, the encrypted data may be text data. Since encrypted data is generally binary data and not text data, the argument may be data obtained by reversibly converting encrypted data into text data by Base64 encoding, for example. Further, the information identifying the transmission destination is, for example, the URL of the server 2 "https://address of the server 2", which is further added with "?datatype=nvram&encrypted=yes" as a parameter. This information indicates that the receiver 3 that received this API command is to transmit encrypted data to the broadcasting station server 2. More specifically, the receiver 3 makes a connection request to the server 2 in order to transmit encrypted data. The above parameters are sent when making a connection request. The server 2, which has received the connection for transmission from the receiver 3, confirms that the receiver 3 is about to transmit encrypted data based on the received parameters.

In the case of HTML, communication with the server 2 can be performed using a communication means that is a standard function. In this embodiment, encrypted data is sent to the server 2 using, for example, a JavaScript XMLHttpRequest object. In this case, the API command is, for example, XMLHttpRequest. open(argument) and XMLHttpRequest. send (argument) (the former argument is information that identifies the destination to which the encrypted data is sent, and the latter argument is the encrypted data to be sent). These embodiments may be the same as the embodiments in transmitTextOverIP of the BML. No. 7, the receiver 3 transmits the encrypted data read from the information storage unit 36 (NVRAM for data broadcasting) to the server 2 of the designated broadcasting station as is, without decoding the encryption. .

Note that in this embodiment, an example is shown in which an API command, which is a command to the API of the receiver 3, is included in application data broadcast on a digital television data broadcasting service, but the present invention is not limited to this. For example, the API function command may be included in a TS-based Signaling Information (SI) signal.

FIG. 4 is a block diagram showing an example of a functional configuration of a server of a broadcasting station according to an embodiment.

The broadcast station server 2 is, for example, a computer, and includes a communication interface for communicating with external devices, a CPU for processing data, and the like. Specifically, the broadcast station server 2 exchanges various data with the receiver 3 via the network 5. Further, the server 2 exchanges various data with the transmitter 1 via the network 6.

The communication unit 21 includes a communication interface for the server 2 to communicate via the network 5 and the network 6, and communicates with the communication protocol (IP communication method, leased line method, etc.) applied to the network 5 and the network 6. Each is implemented.

The application data processing unit 22 exchanges application level data with the receiver 3 and transmitter 2 through HTTPS communication and processes the data. For example, the application data processing unit 22 analyzes application data (here, not limited to BML files and HTML files) from the receiver 3, and issues processing instructions to functions within the server 2 as necessary.

The encryption key request processing unit 23 outputs the encryption key stored in the server 2 to the application data processing unit 22 in response to the received encryption key request from the receiver 3. The output encryption key is transmitted to the receiver 3 via the communication unit 21 or the like.

The key storage unit 24 is, for example, a nonvolatile memory, and stores an encryption key and an encryption/decryption key. However, the encryption key and the encryption/decryption key may be stored in physically different memories in consideration of the difference in the importance of their confidentiality.

The key generation unit 25 generates an encryption key and an encryption/decryption key and stores them in the key storage unit 24. In this embodiment, asymmetric key cryptography is applied, and the encryption key is a public key, and the encryption/decryption key is a private key. The key generation unit 25 generates a one-to-one combination of a public key and a private key. The private key is held secretly by the generator, and the public key need not be kept secret and may be disclosed to a third party. Since the asymmetric key encryption technology and the method of generating the public key and private key are common technologies, their explanation will be omitted.

The decryption processing unit 26 decrypts the encrypted data received from the receiver 3 using the encryption/decryption key, obtains receiver data, and outputs the data. Specifically, the decryption processing unit 26 receives encrypted data, which is receiver data encrypted with an encryption key, from the application data processing unit 22. The decryption processing unit 26 decrypts the encrypted data using the encryption/decryption key to obtain receiver data. The decryption method using the encryption/decryption key (private key) based on the asymmetric key cryptography is a common technology, so a description thereof will be omitted. In this embodiment, an example is shown in which the server 2 has an encryption key and an encryption/decryption key, but the servers having the encryption key and the encryption/decryption key may be different. In that case, the server that has the encryption/decryption key has a function to perform processing using the encryption/decryption key. In this embodiment, an example is shown in which the server 2 has an encryption key and an encryption/decryption key, but the servers having the encryption key and the encryption/decryption key may be different. In that case, the server that has the encryption/decryption key has a function to perform processing using the encryption/decryption key.

The receiver data storage section 27 stores receiver data output from the decoding processing section 26. Receiver data is arbitrary data such as installation location information, owner information, viewing data, and viewing behavior data regarding the receiver 3 owned by the receiver 3. For example, viewing data and viewing behavior data may be used for viewing analysis, etc. Used as analysis data.

FIG. 5 is a block diagram showing an example of the functional configuration of the receiver according to the embodiment.

The receiver 3 is, for example, a digital television receiver, and has a function of receiving digital broadcasts including 2K broadcasts and 4K/8K broadcasts. The receiver 3 also includes a communication interface for exchanging data with the server 2 and an external server (not shown) via the network 5. Furthermore, the receiver 3 has a function for realizing various broadcasting and communication cooperation services by linking data obtained from digital broadcasting and data obtained from a server. Further, the receiver 3 can acquire and store viewing behavior data such as the viewing history of digital broadcast programs viewed by the receiver 3, and information regarding, for example, the owner of the receiver 3. Data including these that can be stored by the receiver 3 is referred to as receiver data. The receiver 3 can store all or part of the receiver data in the information storage section 36 (NVRAM for data broadcasting). The receiver 3 can transmit receiver data to the server 2 via the network 5, for example. The server 2 analyzes and utilizes the received receiver data. In this embodiment, the receiver data is encrypted and stored as encrypted data in the information storage unit 36, and the encrypted data is read from the information storage unit 36 and transmitted to the server 2. Further, the receiver 3 includes arithmetic processing functions such as a CPU for realizing the above functions.

The broadcast tuner 31 receives the broadcast wave 4 from an antenna, cable, etc., and performs decoding and demodulation on the broadcast wave 4 corresponding to the transmission line encoding and modulation method of the transmitter 1 according to various digital broadcasting standards. to obtain and output the digital data of the broadcast stream.

The broadcast stream processing unit 32 performs, for example, a demultiplexer (data separation), information source encoding and decoding, etc. on the broadcast stream input from the broadcast tuner 31 in accordance with various digital broadcasting standards, and provides services. Acquires and outputs data, data broadcasting service data, application data, various control information, etc.

The control unit 33 performs overall control of the receiver 3. For example, the control unit 33 acquires various control information from the broadcast stream processing unit 32, and controls various functions of the receiver 3 based on the acquired various control information. The control unit 33 may also receive various control commands from the user via the remote control unit 303 and the interface unit 302, and control various functions of the receiver 3 based on the various control commands.

The application data storage unit 34 is, for example, a memory, and stores application data output by the broadcast stream processing unit 32. Specifically, a cache that stores application data received from when the broadcast tuner 31 starts receiving broadcast signals until the receiver 3 (specifically, the application execution unit 35) executes the application; It may also be used as a buffer.

The application execution unit 35 includes functions of an application engine such as a BML browser and an HTML browser. This will be explained in detail in the explanation of FIG.

The information storage unit 36 is, for example, NVRAM (Non-Volatile Memory), which is a non-volatile storage medium. The information storage unit 36 is a storage medium (also referred to as NVRAM for data broadcasting) for data (also referred to as receiver data) handled in data broadcasting, which is one of the services implemented in 2K broadcasting and 4K/8K broadcasting. Good too. The information storage unit 36 may distinguish whether stored data is encrypted or not based on the identifiers nvram and nvram in the logical address.

In this embodiment, encrypted data is stored in the information storage unit 36 (NVRAM), and it is possible to determine whether the stored data is encrypted data or non-encrypted data.

FIG. 6 is a diagram illustrating an example of the accumulated data area of the information accumulation section of the receiver according to the embodiment. This figure is for the purpose of explaining the data stored in the information storage unit 36, and is shown logically differentiated based on the content of the data.It also shows the physical relationship in the information storage unit 36. is not limited. Therefore, not all of the contents shown in the figure are necessarily stored in the information storage section 36.

FIG. 6(a) shows an example of a storage area on NVRAM allocated to a broadcaster. The NVRAM is broadly divided into areas for each broadcaster and areas shared by broadcasters, and the areas for each broadcaster and areas shared by broadcasters are further divided into small areas called blocks (or items).

The address “nvram://b_id” shown in the area 3601 indicates the location of the storage area on the information storage unit 36 (NVRAM). Specifically, b_id is the value of a broadcaster identifier of a broadcaster, and can also be represented by the symbol ~ in an application transmitted by a broadcaster to which the broadcaster identifier is assigned. Here, the area 3601 itself does not have to be on the NVRAM; instead, a correspondence table linking the storage location of the NVRAM and the broadcasting company is stored on another memory (not shown), and the receiver 3 is stored on the NVRAM. When accessing, you may refer to the correspondence table.

In this embodiment, "name", "address", and "email address" are stored in a block (or item). Although the types of information such as "name," "address," and "email address" are illustrated as "information element names," they are not stored as data. That is, the "information element name" is shown for convenience in explaining FIG. 6, and does not need to be stored in the information storage unit 36 as specific data. Furthermore, each block is divided into field 1 and field 2, and "data body" and "registration date and time" are written in each field.

Area 3602 is field 1 and stores the data body. For example, field 1 of block 0 stores "name".

Area 3603 is field 2, and the "registration date and time" for the data body stored in field 1 is stored. For example, in block 0, the date and time when "name" was written (registered) in block 0 is stored.

An area 3604 indicates data of block 1, which is a storage area on the information storage unit 36. The information element stored in block 1 is "address". More specifically, field 1 of block 1 stores a specific "address" as the data body, and field 2 stores the "registration date and time" at which the "address" was registered.

An area 3605 indicates data of block N, which is a storage area on the information storage unit 36. The information element stored in block N is "viewing behavior data", and since it is the same as area 3604, the details will be omitted.

FIG. 6(b) shows an example of data stored in the storage area of the information storage unit 36. The difference from FIG. 6A is the address shown in area 3606. The address nvrame://b_id shown in the area 3606 is an area allocated to the broadcaster identified by the same broadcaster identifier b_id as in FIG. Indicates that the area is above. The "data body" in field 1 in FIG. 6(b) is entirely encrypted data (encrypted data).

FIG. 6(c) shows an example of data stored in the storage area of the information storage unit 36. The difference from FIG. 6(a) is a region 3607. In FIG. 6(c), field 3 "encryption presence/absence" is added. In the case of FIG. 6(b), it is possible to determine whether the data stored in the information storage unit 36 is encrypted by the address shown in the area 3606, but in the case of FIG. 3, it can be determined whether the data is encrypted or not.

Returning to FIG. 5, the receiver data storage unit 37 stores receiver data such as viewing behavior data acquired by the receiver 3 and receiver-specific information regarding the owner of the receiver 3. For example, the receiver data storage section 37 may be part of a work memory used by the application execution section 35. The work memory may be a DRAM (Dynamic Random Access Memory) or the like.

The communication unit 38 includes a communication interface for the receiver 3 to communicate via the network 5, and implements a communication protocol applied to the network 5 (IP communication method, leased line method, etc.).

The presentation control unit 39 adjusts the output timing of each data, the processing of each data, etc. in order to display or audio output service data, data broadcasting service data, application data, etc. on the presentation unit 301, and then displays the data (presentation data). data) is output to the presentation unit 301.

The presentation unit 301 is, for example, a monitor or a speaker, and displays presentation data as video data or image data, or outputs the presentation data as audio from the speaker.

The interface unit 302 is a user interface between the receiver 3 and the user, and includes, for example, IR communication, which is an interface with a remote controller attached to the receiver 3, and USB, which is an interface with a PC mouse, keyboard, etc. It may also include. Note that data, signals, etc. may be exchanged with a functional block within the receiver 3 that is not connected to the interface section 302.

The remote control unit 303 is, for example, a remote control attached to the receiver 3. For example, when a user operates the remote control unit 303, the remote control unit 303 outputs control data. The control unit 33 receives the output control data via the interface unit 302, and the control unit 33 controls functions within the receiver 3, so that the user can control the receiver 3.

FIG. 7 is a block diagram illustrating an example of the functional configuration of the application execution unit of the receiver according to the embodiment.

The data analysis unit 350 has functions such as analyzing application data. The application data may be data written in BML or HTML, for example. The data analysis unit 350 extracts API commands from application data and outputs them to the API processing unit 351.

The API processing unit 351 interprets various API commands input from the data analysis unit 350, and outputs the interpretation results or the API commands themselves to related functions. Specifically, the API processing unit 351 causes related functions to execute API processing based on the API command (API name, accompanying arguments, etc.) input from the data analysis unit 350.

The read processing unit 352 receives an execution command regarding reading of encrypted data from the API processing unit 351, and executes processing according to the command. Specifically, the read processing unit 352 reads encrypted data from the information storage unit 36 (NVRAM) by executing a process, and outputs it to the communication processing unit 359, for example.

The encryption determining unit 353 receives an API command from the API processing unit 351 and determines whether the API command is related to encrypted data. Specifically, No. 3 in FIG. 4.No. In cases where the API name includes "encrypted" etc., such as API No. 6 in FIG. 3.No. If this is indicated by an argument as in API 5 (for example, if “nvrame://~/<block number>” is specified as the storage destination identification information), those API commands are encrypted. It is recognized as an API command that handles data.

The encryption key acquisition unit 354 receives an execution command to acquire an encryption key from the API processing unit 351, and executes processing according to the received execution command. Specifically, the encryption key acquisition unit 354 executes processing to acquire the encryption key and check whether the encryption key has been acquired in the encryption key storage unit 355.

The encryption key storage unit 355 is a memory that stores the encryption key acquired by the encryption key acquisition unit 354.

The encryption processing unit 356 encrypts the receiver data using the encryption key acquired by the encryption key acquisition unit 354 in response to an execution command from the API processing unit 351. Since the encryption and decryption methods using the asymmetric key cryptography are common techniques, their explanation will be omitted.

The receiver data acquisition unit 357 executes processing in response to an execution command from the API processing unit 351. Specifically, the receiver data acquisition unit 357 acquires receiver data from the information storage unit 36, the receiver data storage unit 37, etc., and outputs the acquired receiver data to the encryption processing unit 356.

The write processing unit 358 executes processing in response to an execution command from the API processing unit 351. Specifically, the write processing unit 358 writes the encrypted data input from the encryption processing unit 356 into a block or item of the information storage unit 36 specified by the API command.

The communication processing unit 359 has a function for the application execution unit 35 to communicate with a device outside the receiver 3 (for example, the server 2) via the network 5. Specifically, HyperText Transfer Protocol (HTTP) communication, hypertext transfer protocol secure (https) communication, or Transport Layer Security/Secure Sockets It has functions such as Layer (TLS/SSL) communication. Data output from the communication processing unit 359 is output from the communication unit 38 to the network 5.

(First embodiment)
In this embodiment, a command included in a data broadcasting service application causes the receiver 3 to encrypt receiver data, and writes the encrypted data to the information storage unit 36 by specifying a storage area. An example will be described in which the encrypted receiver data is further read out from the information storage unit 36 and the encrypted data is transmitted to a server of a broadcasting station.

The system configuration of this embodiment is shown in FIG. 1, the functional configuration of the transmitter 1 is shown in FIG. 2, the functional configuration of the server 2 is shown in FIG. 4, and the functional configuration of the receiver 3 is shown in FIG. 5, FIG. 6(a), and FIG. 7.

An example of the operation of the system according to this embodiment will be described below.

FIG. 8 is a sequence chart showing an example of the operation of the system according to the first embodiment.

The operation of the system according to this embodiment has four main phases. The operation of each device is shown for each phase.

Phase 1 is a phase in which the receiver 3 obtains an encryption key. The transmitter 1 transmits an "encryption key acquisition command" using the broadcast wave 4 (step P11). When the receiver 3 receives the broadcast wave 4 and obtains the "encryption key acquisition command", it outputs an "encryption key request" to the server 2 (step P12). When the server 2 receives the "encryption key request", it outputs the "encryption key" to the receiver 3, and the receiver 3 receives the "encryption key" and stores it in the encryption key storage unit 355 ( Step P13).

Phase 2 is a phase in which the receiver 3 writes encrypted data to the information storage section 36. The transmitter 1 transmits a write command (of encrypted data) using the broadcast wave 4 (step P21). When the receiver 3 receives the broadcast wave 4 and obtains a write command (for encrypted data), it encrypts the receiver data using the "encryption key" obtained in phase 1 (step P22). . The receiver 3 stores the encrypted receiver data in the information storage unit 36 (step P23).

Phase 3 is a phase in which the receiver 3 reads encrypted data from the information storage section 36. The transmitter 1 transmits a "read command (of encrypted data)" using the broadcast wave 4 (step P31). When the receiver 3 receives the broadcast wave 4 and obtains the "read command (of encrypted data)," it reads out the specified encrypted data from the information storage section 36 (step P32).

Phase 4 is a phase in which the receiver 3 transmits encrypted data to the server 2, and the server 2 acquires the receiver data. The transmitter 1 transmits the "transmission command (of encrypted data)" using the broadcast wave 4 (step P41). When the receiver 3 receives the broadcast wave 4 and obtains the "transmission command (of encrypted data)," it transmits the encrypted data to the designated device (in this embodiment, the server 2). Step P42). The server 2 receives the encrypted data (step P43), decrypts the received encrypted data using the encryption/decryption key, and obtains receiver data (step P44).

In this embodiment, an example is shown in which the transmitter 1 generates a "write command," a "read command," and a "send command," but the server 2 generates each command and transmits it via the network 6. It is also possible to transfer the commands to the transmitter 1 and have the transmitter 1 transmit each command using the broadcast wave 4.

Hereinafter, an example of the operation of the transmitter 1, server 2, and receiver 3 in each phase will be explained using each flowchart.

FIG. 9 is a flowchart illustrating an example of the processing operation of the transmitter according to the embodiment.

The application data generation unit 14 of the transmitter 1 generates application data including API commands for causing the receiver 3 to sequentially execute the processes of all the phases described above (step S11). A specific example of application data is shown below.
<If the application data is a BML file> {
downloadBroadcasterCertificate (argument 1)
writePersistentArray(argument 2, argument 3)
readPersistentArray (argument 2)
transmitTextDataOverIP (argument 4, argument 5)
}
<If the application data is an HTML file> {
downloadBroadcasterCertificate (argument 1)
setItem(argument 2, argument 3)
getItem (argument 2)
XMLHttpRequest. open (argument 4)
XMLHttpRequest. send (argument 5)
}
However, for both BML and HTML files, argument 1 is "https://server 2 address/encryption key file path", argument 2 is nvrame://~/<block number>, and argument 3 is receiver data. It may also be used as identification information. Argument 4 is information that identifies the destination. For example, if you want to send encrypted data to server 2 of the broadcasting station, you can also use "https://address of server 2?datatype=nvram&encrypted=yes". good. Argument 5 is information representing encrypted data read by the API command for each file, that is, readPersistentArray (argument 2) or getItem (argument 2), and is, for example, a variable indicating the storage location of the encrypted data to be read. , an object, etc.
The broadcast stream generation unit 16 multiplexes the generated application data (BML file or HTML file) with the data stream output by the service data stream generation unit 11 or the control information generation unit 12, and outputs the multiplexed data stream as a broadcast stream (step S12). ).

When the digital data of the broadcast stream is input, the broadcast signal transmitter 17 performs transmission path encoding, modulation, etc. according to various digital broadcast standards, generates a broadcast wave 4, and outputs it (step S13). . Broadcast waves 4 are output from an antenna, cable, etc. (not shown).

FIG. 10 is a flowchart showing an example of the processing operation of the receiver in the same embodiment.

For example, assume that the user switches channels using the remote control 303. The receiver 3 receives a remote control control signal from the remote control 303 via the interface unit 302, and the control unit 33 recognizes that the remote control control signal is a "channel selection command" (Yes in step S31). When the control unit 33 controls the broadcast tuner 31 according to the "channel selection command", the broadcast tuner 31 receives the broadcast wave 4 of the selected channel (step S32). The broadcast tuner 31 processes the broadcast waves 4 to obtain a broadcast stream, and the broadcast stream processing section 32 processes the broadcast stream to obtain various data. Among the data acquired by the broadcast stream processing unit 32, when the application control information is output to the control unit 33, the control unit 33 analyzes the application control information (step S33). When the application control information is analyzed by the control unit 33 and an “application execution command” is detected, the control unit 33 starts the application execution unit 35 (step S34). On the other hand, application data among the data obtained from the broadcast stream processing section 32 is temporarily stored in the application data storage section 34 (step S35). When the application execution unit 35 starts, the data analysis unit 350 acquires application data from the application storage unit 34 and analyzes the application data (step S36). The data analysis unit 350 outputs the API command extracted by analyzing the application data to the API processing unit 351, and the API processing unit 351 interprets the API command and executes the API function (step S37).

FIG. 11 is a flowchart illustrating an example of the processing operation of the application execution unit when acquiring an encryption key in the same embodiment, and corresponds to the processing operation in phase 1. This figure corresponds to the details of step S37 in the flowchart of FIG.

The API processing unit 351 is No. 3 in FIG. The API command shown in line 1 is received and recognized (step S311). Regarding the API of each function, although there are differences in API commands between 2K broadcasting (TS system) and 4K8K system (MMT system), there is no particular difference in processing of API commands and processing by API. Therefore, unless otherwise specified hereinafter, the description in the embodiments is applicable to both the case of 2K broadcasting (TS system) and the case of 4K8K system (MMT system). It is determined in step S32 of FIG. 10 whether the broadcast wave 4 received by the receiver 3 is a 2K broadcast (TS system) or a 4K8K system (MMT system). The API processing unit 351 recognizes that the received API command is an API command requesting the server 2 for an encryption key, and causes the encryption key acquisition unit 354 to execute encryption key acquisition processing. The encryption key acquisition unit 354 requests an encryption key from the server 2 (step S312). Specifically, the encryption key acquisition unit 354 creates an encryption key request message in accordance with an execution request based on an API command from the API processing unit 351, and sends it to the server 2 via the communication processing unit 359 and the communication unit 38. Send an encryption key request message to. When the encryption key is transmitted from the server 2, the encryption key acquisition unit 354 receives the encryption key via the communication unit 38 and the communication processing unit 359, and stores the encryption key in the encryption key storage unit 355. (Step S313).

FIG. 12 is a flowchart illustrating an example of the processing operation of the server when acquiring an encryption key in the same embodiment.

In the server 2, the key generation unit 25 generates an encryption key and an encryption/decryption key, and stores them in the key storage unit 24 (step S211). Note that the key generation unit 25 may generate the encryption key and the encryption/decryption key at the timing of receiving the encryption key request message from the receiver 3, or may generate the encryption key and the encryption/decryption key at the timing when the encryption key request message from the receiver 3 is received. It is also possible to generate the key at any timing and store it in the key storage unit 24 regardless of the timing. When the application data processing unit 22 receives the message via the communication unit 21 and recognizes that it is an encryption key request message, it outputs the encryption key request message to the encryption key request processing unit 23 (step S212). . The encryption key request processing unit 23 obtains the encryption key from the key storage unit 24 based on the received encryption key request message (step S213). The encryption key request processing unit 23 transmits the encryption key to the receiver 3 using, for example, https communication (step S214). Through the above procedure, the receiver 3 can acquire the encryption key owned by the server 2.

FIG. 13 is a flowchart showing an example of the processing operation of the application execution unit when writing data in the same embodiment, and corresponds to the processing operation in phase 2. This figure corresponds to the details of step S37 in the flowchart of FIG.

The API processing unit 351 is No. 3 in FIG. 3 or no. Receive the API command shown in line 4. The API processing unit 351 recognizes the API command and outputs it to the encryption determination unit 353 (step S321). The encryption determination unit 353 determines whether the API command is an API command that handles encrypted data based on the API name or its argument (step S322). In this embodiment, for example, if the API command name is "writePersistentArrayEncrypted", it is determined that the API command handles encrypted data, and if the API command name is "writePersistentArray", it is determined that the API command does not handle encrypted data. You may judge. Alternatively, if the argument of the API command is "nvram://~/<block number>", it is determined that the API command handles encrypted data, and the argument of the API command is "nvram://~/<block number>". If the number>”, it may be determined that encrypted data is not handled.

When the API command handles encrypted data, the API processing unit 351 causes the encryption processing unit 356 to execute processing based on the API command, and the encryption processing unit 356 handles data specified by the argument of the API command. The receiver data to be encrypted is recognized from the receiver data identification information, and the designated receiver data (unencrypted data) is encrypted (Yes in step S322, step S323). More specifically, upon receiving a process execution command from the API processing unit 351, the encryption processing unit 356 acquires the receiver data from the receiver data storage unit 37 (in some cases, the information storage unit 36), and encrypts the data. The acquired receiver data is encrypted using the encryption key stored in the key storage unit 355 and the encrypted data is output to the write processing unit 358. The write processing unit 358 stores the encrypted data in the encrypted data storage area of the information storage unit 36 (for example, the block specified by <block number> of nvrame://~/<block number>). (Step S324). On the other hand, if the encryption determining unit 353 determines that the received API command does not handle encrypted data, the API processing unit 351 stores the specified data in the information storage unit 36 without encrypting it ( No in step S322, step S325).

FIG. 14 is a flowchart showing an example of the processing operation of the application execution unit when reading data in the same embodiment, and corresponds to the processing operation in phase 3. This figure corresponds to the details of step S37 in the flowchart of FIG.

The API processing unit 351 is No. 3 in FIG. 5 or no. The API command shown in line 6 is received and recognized (step S331). Specifically, the API processing unit 351 recognizes the API command and outputs it to the encryption determination unit 353. The encryption determination unit 353 determines whether the API command is an API command that handles encrypted data based on the API name or its argument (step S332). In this embodiment, for example, if the API command name is "readPersistentArrayEncrypted", it is determined that the API command handles encrypted data, and if the API command name is "readPersistentArray", it is determined that the API command does not handle encrypted data. Alternatively, if the argument of the API command is "nvram://~/<block number>", it is determined that the API command handles encrypted data, and if the argument of the API command is "nvram ://~/<block number>”, it may be determined that encrypted data is not handled. If the API command handles encrypted data, the read processing unit 352 retrieves the encrypted data from the encrypted data storage area of the information storage unit 36 and outputs it to the communication processing unit 359 (step S333). If the API command does not handle encrypted data, the read processing unit 352 retrieves the data from the non-encrypted data storage area of the information storage unit 36 and outputs it to the communication processing unit 359 (step S334). Note that in an embodiment in which a storage area for encrypted data and a storage area for non-encrypted data are not distinguished, the determination as to whether the API command is an API command that handles encrypted data (step S332) is not performed. The read processing section 352 may take out data from the information storage section 36 and output it to the communication processing section 359. In the communication processing unit 359, the encrypted data may be stored in, for example, a memory or a buffer (not shown).

FIG. 15 is a flowchart showing an example of the processing operation of the application execution unit during data transmission in the same embodiment, and corresponds to the processing operation in phase 4. This figure corresponds to the details of step S37 in the flowchart of FIG.

The API processing unit 351 is No. 3 in FIG. The API command shown in line 7 is received and recognized (step S341). The API processing unit 351 causes the communication processing unit 359 to execute processing based on the recognized API command. Specifically, the communication processing unit 359 converts the data specified by the API command into data for transmission via https communication (hereinafter referred to as https transmission data) (step S342). The https transmission data is transmitted from the communication unit 38 via the network 5 to the server 2 identified by the URL specified by the API command (step S343). Note that No. 3 in FIG. 3, which is Phase 3, 5 or no. Immediately after executing the API function in response to the API command in line No. 6 in FIG. By continuously executing the API function according to the API command in line No. 7, the communication processing unit 359 executes the API function in line No. The encrypted data read from the information storage unit 36 in phase 3 may be transmitted regardless of the argument of the API command in line 7.

FIG. 16 is a flowchart showing an example of the processing operation of the server when receiving data in the same embodiment.

The application data processing unit 22 of the server 2 receives the https transmission data transmitted by the receiver 3 (step S221). The application data processing unit 22 analyzes the transmission destination URL included in the https transmission data (step S222). For example, in the destination URL
https://server 2 address? If "encrypted=yes" is written, such as "datatype=nvram&encrypted=yes", the application data processing unit 22 determines that the data included in the https transmission data is encrypted data. On the other hand, if "encrypted=no" is written in the transmission destination URL "https://server2address?datatype=nvram&encrypted=no", the data included in the https transmission data is unencrypted data. It is determined that As a result of the URL analysis, if the data included in the https transmission data is encrypted data, the application data processing unit 22 outputs the encrypted data to the decryption processing unit 26 (Yes in step S222). The decryption processing unit 26 decrypts the encrypted data using the encryption/decryption key stored in the key storage unit 24 (step S223).

Through the above procedure, it is possible to cause the receiver 3 to encrypt receiver data and write it into the information storage unit 36 (NVRAM) using the API command included in the data broadcasting service application. Further, by using an API command included in the data broadcasting service application, it is possible to cause the receiver 3 to read the encrypted receiver data on the information storage unit 36 and transmit it to the broadcasting station server 2. The server 2 of the broadcasting station receives the encrypted receiver data from the receiver 3 and decrypts the encrypted receiver data, thereby being able to obtain the receiver data.

In this embodiment, by encrypting the data stored in the information storage unit 36 using asymmetric key encryption technology, only the server 2 can encrypt the data stored in the information storage unit 36. Since decryption can be performed only with the possessed encryption/decryption key, the server 2 can collect receiver data while ensuring confidentiality (or confidentiality in information security technology). Note that it is also possible to use symmetric key encryption technology as an encryption technology for data. However, when using symmetric key cryptography, a common key is used to encrypt data. The common key is required to encrypt encrypted data and decrypt encrypted data. If symmetric key encryption technology is applied in this embodiment, the receiver 3 that encrypts data and the server 2 that decrypts encrypted data share the same common key. Therefore, when applying symmetric key cryptography, the receiver 3 also has a key that can decrypt encrypted data. A third party who is not a broadcaster, such as the owner of the receiver 3 or the administrator of the server 2, may perform reading by some means (for example, by connecting the reading device to the semiconductor memory that is the substance of the NVRAM for data broadcasting). When the encrypted data is read out from the information storage unit 36 by a method such as ``performing the above process'' and the common key held by the receiver 3 is also retrieved, the third party decrypts and receives the encrypted data. It is possible to obtain machine data and the issue of ensuring the confidentiality of information remains unsolved. Asymmetric key cryptography uses a publicly available public key that may be known to a third party as an encryption key, and there is no need to share a decryption key. Therefore, in a system like this embodiment, information cannot be kept confidential. It is very effective in ensuring sex. In this embodiment, the above problem is solved by applying asymmetric key encryption technology.

(Second embodiment)
In this embodiment, an example will be described in which the receiver 3 is caused to acquire an encryption key included in a broadcast signal using a command included in a data broadcasting service application. In this embodiment, an example will be described in which an encryption key transmitted via broadcast wave 4 as part of application data is acquired.

The system configuration of this embodiment will be explained using FIG. 1, the functional configuration of the transmitter 1 in FIG. 2, the functional configuration of the server 2 in FIG. 4, and the functional configuration of the receiver 3 in FIGS. 5 and 7.

An example of the operation of the system according to this embodiment will be described below.

FIG. 17 is a sequence chart of the system according to the second embodiment, and is an example of the operation of the system in a phase in which the receiver 3 acquires an encryption key transmitted as part of application data.

The broadcast station server 2 generates an encryption key, and transmits the generated "encryption key" to the transmitter 1 via the network 6 (step P121). The transmitter 1 transmits the encryption key using the broadcast wave 4 (step P122). Here, the transmitter 1 stores the encryption key in the application data and transmits it using the broadcast wave 4. In addition to transmitting the encryption key, the transmitter 1 transmits an "encryption key acquisition command" using the broadcast wave 4 (step P123). The receiver 3 receives the broadcast wave 4 and analyzes it (step P124). When the receiver 3 detects the "encryption key acquisition command" as a result of the analysis, it further analyzes the broadcast wave 4 and acquires the encryption key in the application data (step P125).

FIG. 18 is a flowchart illustrating an example of the processing operation of the transmitter according to the embodiment.

The application data generation unit 14 of the transmitter 1 generates encryption key transmission data for transmitting the encryption key data received from the server 2 on the broadcast wave 4 (step S1201). Specifically, the resources (files) that make up the application are storage locations on the broadcast wave 4 according to the type of broadcast wave 4 (based on ARIB STD-B24, ARIB STD-B62, etc.) as shown below. It is also possible to store the transmission data of the encryption key as .
<If the broadcast wave 4 is the TS method> arib-dc://Resource name of the encryption key <If the broadcast wave 4 is the MMT method> arib-dc2://Resource name of the encryption key Furthermore, what is step S1201? Independently (in parallel), application data is generated including an API command as shown below in order to cause the receiver 3 to acquire an encryption key (step S1202).
<If the application data is a BML file> {
downloadBroadcasterCertificate (argument 1)
}
<If the application data is an HTML file> {
downloadBroadcasterCertificate (argument 2)
}
Regarding argument 1 and argument 2, for example, argument 1 of the BML file is "arib-dc://Encryption key resource name", and argument 2 of the HTML file is "arib-dc2://Encryption key resource name". shall be.

The broadcast stream generation unit 16 multiplexes the generated encryption key transmission data and application data (BML file or HTML file) with data streams output by other service data stream generation units 11 and control information generation units 12. , and output as a broadcast stream (step S1203). The transmission data of the encryption key is stored in the application stream.

When the digital data of the broadcast stream is input, the broadcast signal transmitter 17 performs transmission path encoding, modulation, etc. according to various digital broadcast standards, generates broadcast waves 4, and outputs them (step S1204). . Broadcast waves 4 are output from an antenna, cable, etc. (not shown).

FIG. 19 is a flowchart illustrating an example of the processing operation of the application execution unit when acquiring an encryption key in the same embodiment. The processing operation of the receiver 3 is similar to the flowchart in FIG. 10, and FIG. 19 shows the processing operation corresponding to step S37 in FIG.

The API processing unit 351 of the receiver 3 is configured as No. 3 in FIG. The API command shown in line 2 is received and recognized (step S3201). When the API processing unit 351 recognizes that the encryption key is stored in the broadcast wave 4 from the argument of the API command, it causes the control unit 33 to execute processing based on the API command. The control unit 33 executes analysis of the broadcast wave 4. (Step S3202). Specifically, the control unit 33 identifies the encryption key from the data broadcasting service data output by the broadcast stream processing unit 32, based on the storage location of the encryption key data specified as an argument of the API command. . The control unit 33 outputs the specified encryption key to the API processing unit 351, and the API processing unit 351 stores the input encryption key in the encryption key storage unit 355 (step S3203).

Through the above procedure, the receiver 3 can acquire the encryption key included in the broadcast wave 4 and transmitted using the command included in the data broadcasting service application.

(Third embodiment)
In this embodiment, an example will be described in which the receiver 3 is caused to acquire an encryption key included in a broadcast signal. In this embodiment, an example will be described in which an encryption key is acquired from SI (Signaling Information) that is transmitted on the same broadcast wave 4 separately from application data.

The system configuration of this embodiment will be explained using FIG. 1, the functional configuration of the transmitter 1 in FIG. 2, the functional configuration of the server 2 in FIG. 4, and the functional configuration of the receiver 3 in FIGS. 5 and 7.

An example of the operation of the system according to this embodiment will be described below.

FIG. 20 is a sequence chart of the system according to the third embodiment, showing the operation of the system in the phase in which the receiver 3 acquires the encryption key from the SI transmitted on the same broadcast wave 4 separately from the application data. This is an example.

The broadcasting station server 2 generates an encryption key and transmits the generated encryption key to the transmitter 1 via the network 6 (step P131). The transmitter 1 transmits the encryption key using the SI of the broadcast wave 4 (step P132). Here, the transmitter 1 may repeatedly transmit the encryption key using the broadcast wave 4. The receiver 3 receives the broadcast wave 4 and analyzes it (step P133). Through the analysis, the receiver 3 obtains the encryption key stored in the broadcast wave 4 (step P134).

FIG. 21 is an example of a case where an encryption key is transmitted using the SI of broadcast wave 4 of the TS system in the same embodiment. Figure 21(a) shows a descriptor (broadcaster public key descriptor) that stores the broadcaster's public key, which is an encryption key, and its structure is the common structure of descriptors specified in ARIB STD-B10. It is as follows. The descriptor is placed in a descriptor area of a broadcaster information table (BIT) defined by ARIB STD-B10, for example, shown in area 1241A or 1241B in FIG. 21(b), and transmitted.

FIG. 22 is an example of transmitting an encryption key using SI of broadcast wave 4 of the MMT system in the same embodiment. Figure 22(a) shows a descriptor (MH-broadcaster public key descriptor) that stores the broadcaster's public key, which is an encryption key, and its structure is the same as that of the descriptor specified in ARIB STD-B60. As per the common structure. The descriptor is placed in the descriptor area of the MH-Broadcaster Information Table (MH-BIT) defined by ARIB STD-B60, for example, shown in area 1242A or 1242B in FIG. 22(b), and transmitted.

The transmitter 1 transmits a write command (of encrypted data) using the broadcast wave 4 independently of step P131 (step P231). When receiving the write command (of encrypted data), the receiver 3 checks whether the encryption key required for encryption is stored in the encryption key storage unit 355, for example (step P232). When the receiver 3 recognizes that the encryption key is stored in the encryption key storage unit 355, it encrypts the receiver data that is the target of the write command (of encrypted data) using the encryption key. (Step P233). The receiver 3 stores the encrypted receiver data in the information storage unit 36 (step P234). Hereinafter, an example of the operation of the transmitter 1 and receiver 3 in this embodiment will be described.

The transmitter 1 transmits an encryption key as control information (for example, SI) in the control information generation unit 12, for example. Further, the application data generation unit 14 of the transmitter 1 performs No. 1 in FIG. 3 independently of the transmission of the encryption key. Generate application data as shown below, including the API command in line 3.
<If the application data is a BML file> {
writePersistentArray(argument 1, argument 2)
}
<If the application data is an HTML file> {
setItem (argument 3, argument 4)
}
However, argument 1 may be “nvrame://~/<block number>” and argument 3 may be “_e_wlocal+item number”. Moreover, argument 2 and argument 4 may be receiver data identification information.
The above API commands are the same as the API commands used in the first embodiment, so a description thereof will be omitted.

FIG. 23 is a flowchart showing an example of the processing operation of the receiver in the same embodiment.

The operations from steps S3301 to S3306 are the same as steps S31 to S37 in FIG. 10 of the first embodiment, so a description thereof will be omitted here. In this embodiment, unlike the operation example of the first embodiment, steps S3307 to S3309 are added. The flowchart in FIG. 23 shows that steps S3303, S3304, and S3307 operate in parallel (independently) after step S3302.

The control unit 33 of the receiver 3 analyzes the broadcast stream output by the broadcast stream processing unit 32 and extracts the SI including the encryption key (step S3307). Furthermore, the control unit 33 extracts the encryption key from the extracted SI, and outputs the encryption key to the encryption key acquisition unit 354 (step S3308). The encryption key acquisition unit 354 stores the input encryption key in the encryption key storage unit 355 (step S3309).

FIG. 24 is a flowchart showing an example of the processing operation of the application execution unit when writing data in the same embodiment, and corresponds to the details of step S3310 in the flowchart of FIG. 23.

The API processing unit 351 is No. 3 in FIG. The API command shown in line 3 is received and recognized (step S3321). The API processing unit 351 outputs the recognized API command to the encryption determination unit 353. The encryption determination unit 353 determines whether the API command is an API command that handles encrypted data based on the API name or its argument (step S3322). In this embodiment, since "nvrame:" is included in the argument of the API command, the encryption determination unit 353 determines that the API command handles encrypted data, and the API processing unit 351 Based on the determination, the encryption key acquisition unit 354 is caused to confirm whether the necessary encryption key is stored in the encryption key storage unit 355 (step S3323). When the necessary encryption key is stored in the encryption key storage unit 355, the encryption key acquisition unit 354 acquires the encryption key from the encryption key storage unit 355 and inputs it to the encryption processing unit 356 ( Yes in step S3323, S3324). The encryption processing unit 356 encrypts the receiver data (unencrypted data) specified by the receiver data identification information etc. as an argument of the API command using the encryption key obtained in the previous step. The attached data is generated (step S3325). The encryption processing unit 356 outputs the encrypted data to the write processing unit 358, and the write processing unit 358 stores the encrypted data in the encrypted data storage area of the information storage unit 36 (for example, nvrame:// ~/<block number>) (step S3326). If the encryption determination unit 353 determines that the API command is an API command that does not handle encrypted data, the API processing unit 351 stores the specified data in the information storage unit 36 without encrypting it ( No in step S3322, S3327). Further, if the necessary encryption key is not stored in the encryption key storage unit 355, the encryption key acquisition unit 354 ends without encrypting the designated receiver data (No in step S3323). Alternatively, the process may be repeated from step S3323 after waiting for a while.

Through the above procedure, the receiver 3 acquires the encryption key from the SI transmitted on the same broadcast wave 4 separately from the application data on the broadcast wave 4, and the receiver 3, the receiver data can be encrypted and the encrypted data can be written into the information storage unit 36 (NVRAM).

In addition, in the second embodiment, an example will be described in which the encryption key is transmitted as part of the application data of broadcast wave 4, and in the third embodiment, an example will be described in which the encryption key is transmitted as part of the SI of broadcast wave 4. However, for example, in the second embodiment, the encryption key is transmitted as SI, or in the third embodiment, the encryption key is transmitted as part of the application. Specifically, in the former form, for example, an empty string is set as information for identifying the storage position of the encryption key in the broadcast wave 4 in the API command for acquiring the encryption key, and the control unit 33 When it is confirmed that an empty string is specified as information for identifying the storage location of the encryption key, the encryption key is obtained from the SI of the broadcast wave 4, and the obtained encryption key is output to the API processing unit 351. You can do it like this. In the latter form, the encryption key may be stored as a predetermined resource in the application data. As described above, methods for the transmitting side (transmitter 1) to transmit the key include a method of transmitting it as part of application data and a method of transmitting it as SI. Further, methods for the receiving side (receiver 3) to receive the key include a method using an API and a method in which the receiver performs the key in the background without using an API. There is no particular restriction on the combination of the method of transmitting the key and the method of receiving the key, and any combination is possible.

(Fourth embodiment)
In this embodiment, a command included in the data broadcasting service application causes the receiver 3 to write encrypted data to the information storage unit 36 (NVRAM) without specifying an encrypted area, and further An example of reading written data will be explained. In this embodiment, the receiver 3 recognizes that the API command handles encrypted data by including a word indicating that encrypted data is handled in the API name of the API command.

The system configuration of this embodiment will be explained using FIG. 1, the functional configuration of the transmitter 1 in FIG. 2, the functional configuration of the server 2 in FIG. 4, and the functional configuration of the receiver 3 in FIGS. 5 and 7.

An example of the operation of the system according to this embodiment will be described below. In this embodiment, it is assumed that the encryption key is stored in the encryption key storage section 355. Further, an example of the operation of the transmitter 1, server 2, and receiver 3 will be explained using the flowchart used in the first embodiment. Further, descriptions of parts similar to the operation example in the first embodiment will be omitted.

An example of the operation of the transmitter 1 will be described below using the flowchart in FIG.

The application data generation unit 14 uses No. 3 in FIG. 3 to cause the receiver 3 to write, read, and transmit encrypted receiver data. 4.No. 6, No. Application data including the API command in line 7 is generated as shown below (step S11 in FIG. 9).
<If the application data is a BML file>
{
writePersistentArrayEncrypted(argument 1, argument 2)
ReadPersistentArrayEncrypted(Argument 1)
transmitTextDataOverIP (argument 3, argument 4)
}
<If the application data is an HTML file> {
setItemEncrypted (argument 1, argument 2)
getItemEncrypted (argument 1)
putItem (argument 3, argument 4)
}
However, argument 1 may be "nvram://~/<block number>" in a BML file, or "_wlocal+item number" in an HTML file. Argument 2 may be receiver data identification information for both the BML file and the HTML file. Argument 3 is information representing encrypted data read by the API command for each file, that is, readPersistentArray (argument 1) or getItemEncrypted (argument 1), and is, for example, a variable indicating the storage location of the encrypted data to be read. , an object, etc. Argument 4 is information that identifies the destination. For example, if you want to send encrypted data to server 2 of the broadcasting station, you can also use "https://address of server 2?datatype=nvram&encrypted=yes". good.
Unlike the argument in the first embodiment, in this embodiment, argument 1 of the data write destination is "nvram:". Also, regarding the data transmission API command (API in line No. 7 in Figure 3), the API command to execute the encrypted data read API and the API command to execute the data transmission API are written consecutively as described above. In this case, the data transmission API may transmit the data read by the encrypted data reading API even if argument 2 is not specified.

The broadcast stream generation unit 16 generates a broadcast stream by multiplexing the generated application data (BML file or HTML file) and other data streams, and the broadcast signal transmission unit 17 outputs the broadcast stream as a broadcast wave 4 ( Steps S12, S13).

Next, an example of the operation of the receiver 3 when writing data will be described using FIG. 10 and FIG. 13 shown in the description of the first embodiment.

The receiver 3 extracts the API command according to the flowchart of FIG. 10 (step S37), and further performs the encryption process of the receiver data (step S323) according to the flowchart of FIG. 13 to obtain encrypted data. do.

FIG. 25 is a flowchart illustrating an example of the processing operation of the write processing unit when writing data in the fourth embodiment, and corresponds to the details of step S324 in FIG. 13.

The write processing unit 358 generates encryption identification information for indicating that the encrypted receiver data is "encrypted data" (step S3401). The write processing unit 358 generates a data block including the encrypted receiver data and encrypted identification information (step S3402). A data block refers to data in all fields for each block shown in Figure 6. In particular, if the "data" in field 1 is encrypted receiver data, it may also be referred to as an encrypted data block. good.

FIG. 6(c) shows an example of data stored in the storage area of the information storage unit 36, and an area 3607 and an "encryption presence/absence" field are added to FIG. 6(a). The encrypted identification information may be, for example, 1-bit data, where 0 indicates unencrypted data and 1 indicates encrypted data. This embodiment shows an example in which "data" is encrypted for each block and encrypted identification information for each block is stored in the area 3607. In the first embodiment, as shown in the area 3606 in FIG. 6(b), the area for storing the encrypted receiver data was specified as nvram://~, but in this embodiment, the area 3606 in FIG. The area for storing data is nvram://. Therefore, in the example of this embodiment, there is a possibility that encrypted receiver data and unencrypted receiver data are stored together. In this embodiment, by adding the area 3607 in FIG. 6(c), it is possible to distinguish between encrypted receiver data and unencrypted receiver data. Note that instead of storing the encrypted identification information in the area 3607, a correspondence table between the blocks of the information storage unit 36 and the encrypted identification information may be created and the correspondence table may be stored separately in a memory or the like.

Returning to FIG. 25, the write processing unit 358 writes the encrypted data block to the information storage unit 36 specified by nvram://~ (step S3403).

According to the above procedure, encrypted data can be written into the information storage section 36 (NVRAM for data broadcasting) without defining the area for the encrypted data.

An example of the operation of the receiver 3 when reading data will be described below.

FIG. 26 is a flowchart showing an example of the processing operation of the application execution unit when reading data in the same embodiment, and corresponds to the details of step S37 in the flowchart of FIG.

The API processing unit 351 is No. 3 in FIG. The API command shown in line 6 is received and recognized (step S3431). The API processing unit 351 outputs the recognized API command to the encryption determination unit 353. The encryption determination unit 353 determines whether the API command is an API command that handles encrypted data based on the API name or its argument (step S3432). In this embodiment, since the API name includes "Encrypted," the encryption determination unit 353 determines that the API command handles encrypted data, and the API processing unit 351 sends the read processing unit 352 to the API command. The read processing unit 352 executes processing based on the API command, and reads encrypted data. If the encrypted identification information (area 3607 in FIG. 6(c)) for the "information element" specified for reading by the receiver data identification information that is an argument of the API command is 1, the read processing unit 352 performs readout processing. The data of the "information element" is read out and output to the communication processing unit 359 (Yes in step S3433, S3434). If the encrypted identification information for the "information element" designated to be read is 0, the read processing unit 352 stops reading the "information element" designated to be read (No in step S3433, S3435). On the other hand, if the encryption determining unit 353 does not determine that the command is an API command that handles encrypted data, the API processing unit 351 causes the read processing unit 352 to perform read processing of unencrypted data. If the encrypted identification information (area 3607 in FIG. 6(c)) for the “information element” specified for reading is 0, the read processing unit 352 reads the data of the specified “information element” and performs communication processing. 359 (Yes in step S3436, S3434). If the encrypted identification information for the "information element" designated to be read is 1, the read processing unit 352 stops reading the "information element" designated to be read (No in step S3433, S3435). When the data read by the read processing unit 352 is input to the communication processing unit 359, the data may be stored in a memory, buffer, etc. (not shown), for example. In this embodiment, since the API command for executing the data transmission API is written immediately after the API command for executing the encrypted data read API, the data read by the read processing unit 352 is immediately sent to the communication processing unit 359. It may also be transmitted from the communication unit 38 to the server 2.

Through the above procedure, encrypted data can be read from the information storage unit 36 (NVRAM for data broadcasting) without determining the area of the encrypted data. Note that if there is a correspondence table between the blocks of the information storage unit 36 and the encrypted identification information, the readout processing unit 352 may perform the readout process based on the correspondence table. Further, according to the present embodiment, even when encrypted data and unencrypted data coexist in the information storage unit 36 that does not define an area for encrypted data, encrypted data and unencrypted data coexist. It is possible to select and read both data that are not included.

The data read in the above procedure can be transmitted to the outside using the flowchart in FIG. 15. Details of data transmission are the same as those in the first embodiment, so a description thereof will be omitted. Furthermore, the encrypted data sent from the receiver 3 can be received by the server 2 using the flowchart in FIG. 16, and can be decrypted to obtain (unencrypted) receiver data. can. The details of reception and decryption of encrypted data by the server 2 are the same as those in the first embodiment, so a description thereof will be omitted.

According to the present embodiment, a command included in a data broadcasting service application causes the receiver 3 to encrypt receiver data, and transfers the encrypted data to the information storage unit 36 without specifying an encryption area. (NVRAM for data broadcasting), the written data can be read out, and transmitted to the server 2.

According to at least one embodiment described above, it is possible to provide a receiver, method, and program for recording or collecting receiver data while ensuring the confidentiality of information.

The main points of the receiver in this system described above can also be described as follows.
(1) An application execution unit (application execution unit 35) that executes application data of a data broadcasting service included in a broadcast signal, and an information write unit (write processing unit 358) that executes writing of information instructed by the application data. , a receiver including an information storage unit (information storage unit 36) that stores information specified by the application data, and an encryption unit (encryption processing unit 36) that encrypts the information specified by the application data. 356), comprising an encryption key storage unit (encryption key storage unit 355) for storing an encryption key used by the encryption unit, and writes the information to the information storage unit after encrypting the information by the encryption unit. A receiver characterized by:
(2) Information reading means (reading processing unit 352) for reading encrypted information from the information storage means according to instructions from the application data, and outputting the read information to an external device (server 2) without decrypting it. The receiver according to (1), characterized in that:
(3) The receiver according to (1) or (2), wherein the encryption key is a public key of a public key cryptosystem.
(4) The receiver according to any one of (1) to (3), further comprising the encryption key storage instruction means for storing an encryption key in the encryption key storage means according to an instruction included in the application data. .
(5) The receiver according to (4), wherein the encryption key is part of data broadcast application data included in the broadcast signal.
(6) The receiver according to (4), wherein the encryption key is obtained from an external device (server 2) that owns the encryption/decryption key.
(7) Encryption key separation means (control unit 33) for extracting the encryption key from a portion of the broadcast signal excluding the application data and storing the encryption key in the encryption key storage means. (8) The receiver described in (1) to (3) is characterized in that the information writing means and the information reading means are APIs provided by the application execution means and called from a data application. The receiver described in (1) to (7), characterized in that:
(9) The receiver according to any one of (4) to (6), wherein the encryption key storage instruction means is an API provided by the application execution means and called from a data application.

The main points of the transmitter in this system described above can also be described as follows.
(A1)
A transmitter for digital television broadcasting,
Broadcast signal transmitting means for transmitting receiver data in the digital television broadcasting receiver as a broadcast signal including a command to read encrypted data obtained by encrypting receiver data with an encryption key and a command to transmit the encrypted data. transmitter.
(A2)
The transmitter according to (A2), wherein the encryption key is a public key based on a public encryption key system.
(A3)
The transmitter according to any one of (A1) and (A2), comprising a read command generation means for generating the read command.
(A4)
The transmitter according to any one of (A1) to (A3), comprising a transmission command generation means for generating the transmission command.
(A5)
The transmitter according to any one of (A1) to (A4), wherein the read command includes data storage identification information that is a storage location of the encrypted data.
(A6)
The transmitter according to any one of (A1) to (A5), wherein the transmission command includes a URL of a server as a transmission destination.
(A7)
The transmitter according to (A6), wherein the execution order of the transmission command is controlled so that the transmission command is executed after the read command in the receiver.
(A8)
The transmitter according to any one of (A1) to (A7), wherein the read command or the transmission command is transmitted while being included in application data of a data broadcasting service included in the broadcast signal.
(A9)
The transmitter according to (A8), wherein the read command is an API command that is a command for an API built into the receiver.
(A10)
The transmitter according to (A8), wherein the transmission command is an API command that is a command for an API built into the receiver.

The main points of this system described above can also be described as follows.
(B1)
In a digital television broadcasting system comprising a transmitter, a server, and a receiver,
The transmitter includes broadcast signal transmitting means for transmitting receiver data in the receiver as a broadcast signal including a read instruction for encrypted data that is encrypted with an encryption key and a command to transmit the encrypted data. ,
The receiver includes broadcast signal receiving means for receiving a broadcast signal;
information reading means for reading encrypted data obtained by encrypting receiver data in the receiver with an encryption key from the information storage means based on a read command included in the broadcast signal;
information transmitting means for transmitting the encrypted data to the server based on a transmission command included in the broadcast signal,
The system includes receiver data acquisition means in which the server receives the encrypted data, decrypts the encrypted data using an encryption/decryption key, and obtains receiver data.
(B2)
The system according to (B1), wherein the encryption key is a public key of a public encryption key system, and the encryption/decryption key is a private key generated at the same time as the public key.
(B3)
The reading command and the sending command are included in application data broadcast on the data broadcasting service of the digital television broadcasting and transmitted as the broadcast signal according to any one of (B1) and (B2). system.

Although several embodiments of the invention have been described, these embodiments are presented by way of example and are not intended to limit the scope of the invention. These novel embodiments can be implemented in various other forms, and various omissions, substitutions, and changes can be made without departing from the gist of the invention. These embodiments and their modifications are included within the scope and gist of the invention, as well as within the scope of the invention described in the claims and its equivalents. Furthermore, each component of the claims is within the scope of the present invention even when the component is expressed separately, or when a plurality of components are expressed together, or when these are expressed in combination. Further, a plurality of embodiments may be combined, and embodiments constituted by this combination are also within the scope of the invention.

Further, in order to make the explanation clearer, the drawings may schematically represent the width, thickness, shape, etc. of each part compared to the actual aspect. In the functional block diagrams of the drawings, functional components necessary for explanation are represented by blocks, and descriptions of general functional components may be omitted. Further, the blocks indicating functions are functionally conceptual, and do not necessarily need to be physically configured as illustrated. For example, the specific form of distributing and integrating the blocks of each function is not limited to the form shown in the figure. It is configured to be functionally or physically distributed and integrated depending on the usage status of each functional block. In a block diagram, data and signals may be exchanged between blocks that are not connected, or even in directions where arrows are not shown even if the blocks are connected. Each function shown in the block diagram and the processing shown in the flowchart and sequence chart are implemented in hardware (IC chip, etc.), software (program, etc.), digital signal processing arithmetic chip (Digital Signal Processor, DSP), or these hardware. It may be realized by a combination of hardware and software. Furthermore, the apparatus or method of the present invention can be applied even when the claims are expressed as control logic, as a program containing instructions for a computer to execute, or as a computer-readable recording medium containing the instructions. It is something. Furthermore, the names and terms used are not limited, and other expressions are included in the present invention as long as they have substantially the same content and purpose.

DESCRIPTION OF SYMBOLS 1... Transmitter, 2... Server, 3... Receiver, 4... Broadcast wave, 5... Network, 6... Network, 10... Broadcasting station, 11... Service data stream generation part, 12... Control information generation part, 13... Application Stream generation unit, 14...Application data generation unit, 15...Encryption key storage unit, 16...Broadcast stream generation unit, 17...Broadcast signal transmission unit, 21...Communication unit, 22...Application data processing unit, 23...Encryption key Request processing section, 24... Key storage section, 25... Key generation section, 26... Decryption processing section, 27... Receiver data storage, 31... Broadcast tuner, 32... Broadcast stream processing section, 33... Control section, 34... Application data Storage section, 35... Application execution section, 36... Information storage section, 37... Receiver data storage section, 38... Communication section, 39... Presentation control section, 301... Presentation section, 302... Interface section, 303... Remote control section, 350 ...Data analysis section, 351...API processing section, 352...Reading processing section, 353...Encryption determination section, 354...Encryption key acquisition section, 355...Encryption key storage section, 356...Encryption processing section, 357...Reception Machine data acquisition section, 358...Writing processing section, 359... Communication processing section.

Claims (10)

A receiver for digital television broadcasting,
broadcast signal receiving means for receiving a broadcast signal;
information reading means for reading encrypted data obtained by encrypting receiver data in the receiver with an encryption key from the information storage means based on a read command included in the broadcast signal;
and information transmitting means for transmitting the encrypted data to an external device based on a transmission command included in the broadcast signal. The receiver according to claim 1, wherein the encryption key is a public key based on a public encryption key system. 3. The receiver according to claim 1, further comprising command processing means for processing the read command or the transmission command. 4. The receiver according to claim 1, wherein the read command includes data storage identification information that is a storage location of the encrypted data. 5. The receiver according to claim 1, wherein the transmission command includes a server URL as a transmission destination. The read command or the transmission command is transmitted while being included in application data of a data broadcasting service included in the broadcast signal,
application data acquisition means for acquiring the application data from the broadcast signal;
6. The receiver according to claim 1, further comprising command extraction means for extracting the read command and the transmission command from the application data. The receiver according to claim 6, further comprising an API that causes the information reading means to execute based on the reading command. 8. The receiver according to claim 6, further comprising an API that causes the information transmitting means to execute based on the transmitting command. A method for receiving digital television broadcasting by a receiver , the method comprising:
receiving the broadcast signal by the broadcast signal receiving means ;
reading encrypted data obtained by encrypting receiver data in the receiver with an encryption key from the information storage means based on a read command included in the broadcast signal by the information reading means;
A receiving method comprising the step of transmitting the encrypted data to an external device based on a transmission command included in the broadcast signal by an information transmitting means . A program that functions multiple means included in a digital television broadcast receiver,
broadcast signal receiving means for receiving a broadcast signal;
information reading means for reading encrypted data obtained by encrypting receiver data in the receiver with an encryption key from the information storage means based on a read command included in the broadcast signal;
information transmitting means for transmitting the encrypted data to an external device based on a transmission command included in the broadcast signal;
A program that functions as

Images