Digital television broadcasting system, method

Abstract

To collect receiver data while securing confidentiality.SOLUTION: A digital television broadcast system according to an embodiment includes a broadcast signal receiver configured to receive a broadcast signal, an encryption key obtainer configured to obtain an encryption key from the broadcast signal, an encryptor configured to encrypt receiver data in the receiver using the encryption key based on a write command included in the broadcast signal to generate encrypted data, and an information writer configured to write the encrypted data into an information storage.SELECTED DRAWING: Figure 8

Description

Technical Field

[0001] Embodiments relate to digital television broadcast systems and methods.

Background Art

[0002] Receivers corresponding to BS digital broadcast, 110-degree CS digital broadcast, terrestrial digital broadcast (collectively also referred to as 2K broadcast), and high-definition broadband satellite digital broadcast (also referred to as 4K / 8K broadcast) (hereinafter, simply also referred to as a receiver) are equipped with an NVRAM (Non-Volatile Memory), which is a rewritable and non-volatile memory medium that retains the stored content even when the power is turned off. The NVRAM is used as a storage medium (also referred to as NVRAM for data broadcast) for data (also referred to as receiver data) handled in data broadcast, which is one of the services implemented in 2K broadcast and 4K / 8K broadcast. The NVRAM for data broadcast stores data created and transmitted by a broadcaster and is accessible from data broadcast content executed on the receiver. Access control technology is provided to conceal data recorded in the NVRAM for data broadcast by one broadcaster from other broadcasters, such as by determining an accessible area for each broadcaster.

Prior Art Documents

Patent Documents

[0003]

Patent Document 1

Non-Patent Documents

[0004]

Non-Patent Document 1

Non-Patent Document 2

Summary of the Invention

[0005] However, if a third party who is neither the owner of the receiver nor the broadcaster accesses the data broadcasting NVRAM using a method other than accessing it from the data broadcasting content (for example, by connecting a reading device to the semiconductor memory that is the actual data broadcasting NVRAM and reading the data), that third party can obtain the information represented by that data. In other words, the confidentiality of the information is not guaranteed. Since data recorded in NVRAM, a non-volatile storage medium, is retained unless explicitly erased, there is a possibility that information could be retrieved by a third party, for example, if the receiver is transferred to someone else or disposed of. Considering that some data broadcasting content created by broadcasters (including those to be created in the future) may contain information that could cause serious problems if retrieved by a third party, such as personal information, it is necessary to ensure the confidentiality of the information even if the data is retrieved by a third party.

[0006] The problem that this invention aims to solve is to provide a digital television broadcasting system and method for recording and collecting receiver data while ensuring the confidentiality of the information. [Means for solving the problem]

[0007] According to one embodiment, a digital television broadcasting system comprising a transmitter, a server, and a receiver, The transmitter has an application data generation means, The aforementioned application data generation means uses the following as API commands: A key acquisition command to cause the receiver to obtain an encryption key, A write command to generate encrypted data by encrypting the receiver data present in the receiver using the encryption key and writing it to the information storage unit, A read command instructs the information reading means of the receiver to read the encrypted data from the information storage unit, A transmission command that instructs the server to send the encrypted data that has been read, The application data generation means generates and includes in the broadcast signal, The aforementioned server, The receiver includes means for transmitting, via the transmitter, a read command for reading the encrypted data from the information storage unit, and a transmit command for transmitting the read encrypted data to the server, means for decrypting the received encrypted data, It has, The aforementioned receiver is The system includes receiving means for receiving the broadcast signal sent from the transmitter, and application execution means, The aforementioned application execution means is An encryption key acquisition means that acquires the encryption key from the server based on the key acquisition command included in the broadcast signal, An encryption means that, based on the write command included in the broadcast signal, encrypts the receiver data present in the receiver using the encryption key to generate the encrypted data, The system includes an information writing means for writing the encrypted data to the information storage unit. A digital television broadcasting system will be provided. [Brief explanation of the drawing]

[0008] [Figure 1] Figure 1 is a block diagram showing an example of the system configuration according to the embodiment. [Figure 2] Figure 2 is a block diagram showing an example of the functional configuration of a broadcasting station transmitter according to this embodiment. [Figure 3] Figure 3 shows an example of an API command that can be written in the application data generation unit of the transmitter according to this embodiment. [Figure 4]FIG. 4 is a block diagram showing an example of the functional configuration of a server of a broadcasting station according to an embodiment. [Figure 5] FIG. 5 is a block diagram showing an example of the functional configuration of a receiver according to an embodiment. [Figure 6] FIG. 6 is a diagram showing an example of the storage data area of the information storage unit of the receiver according to an embodiment. [Figure 7] FIG. 7 is a block diagram showing an example of the functional configuration of the application execution unit of the receiver according to an embodiment. [Figure 8] FIG. 8 is a sequence chart showing an example of the operation of the system according to the first embodiment. [Figure 9] FIG. 9 is a flowchart showing an example of the processing operation of the transmitter according to the same embodiment. [Figure 10] FIG. 10 is a flowchart showing an example of the processing operation of the receiver in the same embodiment. [Figure 11] FIG. 11 is a flowchart showing an example of the processing operation of the application execution unit at the time of obtaining an encryption key in the same embodiment. [Figure 12] FIG. 12 is a flowchart showing an example of the processing operation of the server at the time of obtaining an encryption key in the same embodiment. [Figure 13] FIG. 13 is a flowchart showing an example of the processing operation of the application execution unit at the time of data writing in the same embodiment. [Figure 14] FIG. 14 is a flowchart showing an example of the processing operation of the application execution unit at the time of data reading in the same embodiment. [Figure 15] FIG. 15 is a flowchart showing an example of the processing operation of the application execution unit at the time of data transmission in the same embodiment. [Figure 16] FIG. 16 is a flowchart showing an example of the processing operation of the server at the time of data reception in the same embodiment. [Figure 17] FIG. 17 is a sequence chart of the system according to the second embodiment. [Figure 18]Figure 18 is a flowchart showing an example of the processing operation of the transmitter according to the same embodiment. [Figure 19] Figure 19 is a flowchart showing an example of the processing operation of the application execution unit when obtaining an encryption key in the same embodiment. [Figure 20] Figure 20 is a sequence chart of the system according to the third embodiment. [Figure 21] Figure 21 shows an example of transmitting the encryption key in the SI of the TS broadcast wave 4 in the same embodiment. [Figure 22] Figure 22 shows an example of transmitting the encryption key in the SI of the MMT broadcast wave 4 in the same embodiment. [Figure 23] Figure 23 is a flowchart showing an example of the receiver's processing operation in the same embodiment. [Figure 24] Figure 24 is a flowchart showing an example of the processing operation of the application execution unit when writing data in the same embodiment. [Figure 25] Figure 25 is a flowchart showing an example of the processing operation of the write processing unit when writing data in the fourth embodiment. [Figure 26] Figure 26 is a flowchart showing an example of the processing operation of the application execution unit when writing data in the same embodiment. [Modes for carrying out the invention]

[0009] The embodiments will be described below with reference to the drawings.

[0010] Figure 1 is a block diagram showing an example of the system configuration according to the embodiment.

[0011] Broadcasting station 10 is a broadcasting station for 2K broadcasting or 4K / 8K broadcasting. When distinguishing between a 2K broadcasting station and a 4K / 8K broadcasting station, they will be referred to as a 2K broadcasting station and a 4K / 8K broadcasting station, respectively. Broadcasting station 10 includes a transmitter 1 and a server 2.

[0012] Transmitter 1 transmits a digital broadcast signal, including application data and various control information, onto a broadcast wave such as a 2K broadcast or a 4K / 8K broadcast, and outputs the broadcast wave from an antenna or cable.

[0013] Server 2 is, for example, a computer, equipped with a communication interface for communicating with external devices and a CPU for processing data. Specifically, Server 2 exchanges various data with Receiver 3 via Network 5. Server 2 also exchanges various data with Transmitter 1 via Network 6. Transmitter 1 can transmit the data received from Server 2 via broadcast waves 4. In Figure 1, only one broadcasting station 10 and one receiver 3 are shown, but typically there are multiple broadcasting stations 10 (transmitter 1, Server 2) and receivers 3. In this case, each broadcasting station's Server 2 can exchange data with multiple receivers 3. Each broadcasting station's Transmitter 1 also outputs its own broadcast wave 4, and each receiver 3 can receive one or more broadcast waves 4 from multiple transmitters 1.

[0014] Broadcast wave 4 is, for example, a radio wave, which may be output from an antenna or transmitted via a wired connection such as cable broadcasting.

[0015] Network 5 is, for example, a telecommunications line such as the Internet, and the medium can be either wireless or wired.

[0016] Network 6 is an interface within the broadcasting station primarily for communication between transmitter 1 and the server. It may be a telecommunications line such as the internet, or a dedicated line. The medium may be wireless or wired.

[0017] Figure 2 is a block diagram showing an example of the functional configuration of a broadcasting station transmitter according to this embodiment.

[0018] 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 broadcasting), application data, and various control information obtained from Server 2, and outputs the digital data stream via broadcast wave 4. Various digital broadcast standards may include, for example, the MPEG2 transport stream (TS) method, which is the transmission method for 2K broadcasting, or the MPEG Media Transport (MMT) method, which is the transmission method for 4K / 8K broadcasting.

[0019] The service data stream generation unit 11 generates a data stream of encoded service data, such as video, audio, and subtitles, by encoding and packetizing the service data, including source coding according to various digital broadcasting standards.

[0020] The control information generation unit 12 generates control information related to the presentation of service data, and control information for controlling the application (hereinafter referred to as application control information).

[0021] The application stream generation unit 13 generates a data stream of application data by encoding and packetizing the application data, including source coding in accordance with various digital broadcasting standards. The application data is generated as a data stream (application stream) based on a method in accordance with various digital broadcasting standards, such as a data carousel method or an event message method.

[0022] The application data generation unit 14 generates data for an application to be executed on the receiver 3. In this embodiment, the application data generation unit 14 generates application data that includes commands for the Application Programming Interface (API) shown in Figure 3 (hereinafter referred to as API commands). The API is an interface provided to the application by the application engine, which is an executable program built into the receiver 3, and is also referred to as a broadcast extension function (or broadcast extension object) as defined in standards such as ARIB STD-B24 and ARIB STD-B62. In this embodiment, the application is assumed to be a data broadcasting application (in the case of 4K / 8K broadcasting) or data broadcasting content (in the case of 2K broadcasting). Specifically, files written in Broadcast Markup Language (BML) or HyperText Markup Language (HTML) (referred to as BML files and HTML files, respectively) are transmitted, and in this embodiment, these files include API commands for executing the following API. Details will be described in the explanation of Figure 3. - API for acquiring and storing encryption keys used for encryption (encryption key acquisition API) - Data writing API (with encryption) - Encrypted data reading API (without decryption) - Data transmission API In this embodiment, the application data generation unit 14 is shown as a function of the transmitter 1, but it may also be a function of the server 2. If 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.

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

[0024] The broadcast stream generation unit 16 includes, for example, a multiplexer, and 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 outputs them as a broadcast stream.

[0025] The broadcast signal transmission unit 17 performs encoding and modulation, including transmission path coding according to various digital broadcasting standards, on the digital data of the broadcast stream to generate a broadcast wave 4, which is then output to an antenna, cable, etc. (not shown).

[0026] The communication unit 18 is a function for communicating with the server 2, and if it is communicating via network 6, for example, it implements the communication protocol applied to network 6 (such as IP communication method or dedicated line method).

[0027] Figure 3 shows an example of an API command that can be written in the application data generation unit 14 of the transmitter according to this embodiment. Each column, from left to right, shows the API No. (number in Figure 3), the API function, and the API command for the API function (API name, arguments, etc.) when written in BML or HTML. Here, the API is an interface provided to the application by the application engine, which is an executable program built into the receiver 3, and what the transmitter 1 writes in the BML or HTML file is the API command shown in this figure (API name, arguments to the API, etc.).

[0028] Line No. 1 is an API command that executes the encryption key acquisition API, which instructs receiver 3 to obtain the encryption key to be used for encryption from server 2.

[0029] In the case of BML, for example, it is an API command that calls downloadBroadcasterCertificate, which is an API defined as a method of the browser pseudo-object specified in ARIB STD-B24. The API command is, for example, downloadBroadcasterCertificate(arguments). In this embodiment, the arguments include at least information identifying the encryption key to be obtained from server 2 (for example, a URL such as "https: / / address of server 2 / path to encryption key file"), but may also include other information to be obtained by receiver 3 (for example, identification information indicating the attributes of the encryption key).

[0030] 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(arguments). In this embodiment, the arguments include at least information identifying the encryption key to be obtained from server 2 (for example, a URL such as "https: / / address of server 2 / path to encryption key file"), but may also include other information to be obtained by receiver 3 (for example, identification information indicating the attributes of the encryption key).

[0031] The reliability of the encryption key obtained by receiver 3 using API command No. 1 can also be ensured by the reliability of the hypertext transfer protocol secure (https) connection. When using API No. 1, receiver 3 first establishes a connection with broadcast server 2 using https, and obtains the encryption key from broadcast server 2 through communication over that https connection. Server 2 is authenticated from the receiver 3's perspective via the https connection, and the reliability of the obtained encryption key is ensured.

[0032] Line No. 2 is an API command that executes the encryption key acquisition API, which causes receiver 3 to acquire the encryption key being transmitted within the application stream during broadcast.

[0033] In the case of BML, for example, it is an API command that calls downloadBroadcasterCertificate, which is an API defined as a method of the browser pseudo-object specified in ARIB STD-B24. The API command is, for example, downloadBroadcasterCertificate(arguments). In this embodiment, the arguments include at least information that identifies the location where the encryption key in the broadcast data (broadcast signal) is stored (for example, a URL such as "arib-dc: / / resource name of the encryption key"), but may also include other information to be obtained by the receiver 3 (for example, identification information indicating the attributes of the encryption key).

[0034] 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(arguments). In this embodiment, the arguments include at least information that identifies the location where the encryption key in the broadcast data (broadcast signal) is stored (for example, a URL such as "arib-dc2: / / resource name of the encryption key"), but may also include other information to be obtained by the receiver 3 (for example, identification information indicating the attributes of the encryption key).

[0035] Line No. 3 is an API command that executes a data writing API, causing receiver 3 to encrypt the receiver data and write the encrypted data (hereinafter referred to as encrypted data) to the information storage unit 36 ​​(NVRAM for data broadcasting) of receiver 3.

[0036] In the case of BML, for example, it is an API command that calls writePersistentArray, an API defined in ARIB STD-B24. The API command is, for example, writePersistentArray(arguments). The arguments of the API command include at least information that identifies the receiver data to be written to the receiver 3 as encrypted data (receiver data identification information), information that instructs the receiver 3 to write the said data as encrypted data (encryption write instruction information), and information that identifies the storage location where the encrypted data will be written (storage location identification information). For example, the receiver data identification information may be as defined in ARIB TR-B14. Also, for the receiver data identification information and storage location identification information, instead of the URI (Uniform Resource Identifier) ​​"nvram: / / ~ / <block number>", which is a form of information that identifies the storage location in the NVRAM for data broadcasting as defined in ARIB TR-B14, the URI "nvrame: / / ~ / <block number>" may be used. Here, the meanings of ~ and <block number> are based on the values ​​specified in ARIB TR-B14.

[0037] In the case of HTML, for example, it is an API command that calls setItem, which is an API that uses a method of the LocalStorage object whose operation is defined in ARIB TR-B39. The API command is, for example, setItem(arguments). The arguments of the API command include at least receiver data identification information, encrypted write instruction information, and storage location identification information. For example, the receiver data identification information may be as defined in ARIB TR-B39. Also, for the encrypted write instruction information and storage location identification information, for example, instead of the access key name defined in ARIB TR-B39, for example "_wlocal" + item number, you may use "_e_wlocal" + item number, for example "_e_wlocal0".

[0038] Line No. 4 is an API command that executes a data writing API, causing receiver 3 to encrypt the receiver data and write the encrypted data (hereinafter referred to as encrypted data) to the information storage unit 36 ​​(NVRAM for data broadcasting) of receiver 3.

[0039] In the case of BML, for example, it is an API command that calls writePersistentArrayEncrypted, which is an API compliant with writePersistentArray as defined in ARIB STD-B24. The API command is, for example, writePersistentArrayEncrypted(arguments). The arguments of the API command include at least receiver data identification information and storage location identification information. For example, the arguments may be compliant with the configuration of arguments in the API command for BML in line No. 3 above, or they may be compliant with the arguments of writePersistentArray as defined in ARIB TR-B14. In the latter case, receiver 3 recognizes from "Encrypted" in the API name that it is necessary to encrypt the data to be written to NVRAM, and may encrypt the data to be written specified in the argument and then store it in NVRAM.

[0040] In the case of HTML, for example, it is an API command that calls setItemEncrypted, which is an API that conforms to the methods of the LocalStorage object whose operation is defined in ARIB TR-B39. The API command is, for example, setItemEncrypted(arguments). The arguments of the API command include at least receiver data identification information to be written to the receiver 3 as encrypted data, and storage location identification information. For example, the arguments may conform to the embodiment of the arguments in the API command for HTML in line No. 3 above, or they may conform to the arguments of setItem as defined in ARIB TR-B39. In the latter case, when the API of No. 4 is called, the receiver 3 may recognize from "Encrypted" in the API name that it is necessary to encrypt the data to be written to NVRAM, and may encrypt the data to be written specified in the argument and then store it in NVRAM. In this embodiment, an example is shown in which the receiver 3 uses the encryption key obtained with APIs No. 1 and No. 2 to perform encrypted writing with APIs No. 3 and No. 4.

[0041] The NVRAM area to which encrypted data is written using API commands No. 3 and No. 4 may be a different area from or the same area as the NVRAM area defined in ARIB TR-B14 and ARIB TR-B39. For example, in the BML API command No. 3, the area represented by the URL "nvrame: / / ~ / 0" that indicates the storage location to write encrypted data may be a different area from or the same area as the URL "nvram: / / ~ / 0" defined in ARIB TR-B14. The same applies to the area represented by the access key in the HTML API command No. 3. Furthermore, for example, in the BML API commands No. 3 and No. 4, namely writePersistentArray(arguments) and writePersistentArrayEncrypted(arguments), when a URL such as "nvram: / / ~ / 0" is specified, the area where receiver 3 writes data when the API is called by the former API command No. 3 and the area where receiver 3 writes encrypted data when the API is called by the latter API command No. 4 may be separate areas or the same area. The same applies to the HTML API command No. 4.

[0042] Line No. 5 is an API command that executes the encrypted data reading API, and it is an API command that causes receiver 3 to read encrypted data from information storage unit 36.

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

[0044] In the case of HTML, for example, it 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(arguments). The arguments of the API command include information that identifies the storage location of the encrypted data to be read by receiver 3 (storage location identification information, for example, "_e_wlocal" + item number). The item number is the same as in the case of No. 3 above.

[0045] Line No. 6 is an API command that executes the encrypted data reading API, and it is an API command that causes receiver 3 to read encrypted data from information storage unit 36.

[0046] In the case of BML, for example, it is an API command that calls ReadPersistentArrayEncrypted, which is an API compliant with ReadPersistentArray as defined in ARIB STD-B24. The API command is, for example, ReadPersistentArrayEncrypted(arguments). The arguments of the API command include at least the location identifier of the encrypted data to be read by receiver 3. As the location identifier of the encrypted data to be read, for example, ARIB You may also specify a URI such as “nvram: / / ~ / <block number>”, which is a form of information that identifies the storage location within the NVRAM for data broadcasting as defined in TR-B14. In this case, if the encrypted data and unencrypted receiver data are stored in different areas even if they are the same block number, when the receiver 3 receives the API command No. 6, it may recognize from “Encrypted” in the API name that it should read from the area where encrypted data is stored, and read the encrypted data from the NVRAM.

[0047] In the case of HTML, for example, it is an API command that calls getItemEncrypted, which is an API that conforms to the LocalStorage object whose operation is defined in ARIB TR-B39. The API command is, for example, getItemEncrypted(arguments). The arguments of the API command include at least information that identifies the storage location of the encrypted data to be read by the receiver 3. As information that identifies the storage location of the encrypted data to be read, for example, an access key name defined in ARIB TR-B39 may be specified. In this case, in an embodiment in which encrypted data and unencrypted receiver data are stored in different areas even if they have the same block number, when the receiver 3 receives the API command No. 6, it may recognize from "Encrypted" in the API name that it should read from the area where encrypted data is stored and read the encrypted data from NVRAM.

[0048] Line No. 7 is an API command that executes the data transmission API, and it is an API command that causes receiver 3 to send encrypted data to the broadcasting station's server 2.

[0049] In the case of BML, for example, it is an API command that calls transmitTextDataOverIP, an API defined in ARIB STD-B24. The API command is, for example, transmitTextDataOverIP(arguments). In this embodiment, the arguments of the API command include encrypted data read using API command No. 4 or No. 5, and information identifying the destination. In this embodiment, the encrypted data may be text data. Generally, encrypted data is binary data and not text data, so for example, data obtained by reversibly converting encrypted data to text data using Base64 encoding may be used as an argument. The information identifying the destination is, for example, the URL of server 2, "https: / / address of server 2", with the parameter "?datatype=nvram&encrypted=yes" added. This information indicates to the receiver 3, which receives this API command, that it should send the encrypted data to the broadcasting station's server 2. More specifically, the receiver 3 requests a connection from server 2 to send the encrypted data. The above parameters are sent when the connection request is made. Server 2, having received a connection from receiver 3 for transmission, confirms, based on the received parameters, that receiver 3 is attempting to transmit encrypted data.

[0050] In the case of HTML, communication with server 2 can be performed using standard communication functions. In this embodiment, for example, encrypted data is sent to server 2 using the JavaScript XMLHttpRequest object. In this case, the API command may include, for example, XMLHttpRequest.open(argument) and XMLHttpRequest.send(argument) (the former argument is information identifying the destination to which the encrypted data will be sent, and the latter argument is the encrypted data to be sent). These embodiments may be the same as the embodiments in transmitTextOverIP of BML described above. With API command No. 7, receiver 3 sends the encrypted data read from information storage unit 36 ​​(NVRAM for data broadcasting) as is, that is, without decrypting the encryption, to server 2 of the specified broadcasting station.

[0051] In this embodiment, an example is shown in which API commands, which are instructions to the API of receiver 3, are included in application data broadcast in the digital television data broadcasting service, but this is not limited to this. For example, API function commands may be included in TS-type Signaling Information (SI) signals, etc.

[0052] Figure 4 is a block diagram showing an example of the functional configuration of a broadcasting station server according to this embodiment.

[0053] The broadcasting station's server 2 is, for example, a computer, equipped with a communication interface for communicating with external devices and a CPU for processing data. Specifically, the broadcasting station's server 2 exchanges various data with the receiver 3 via network 5. Furthermore, server 2 exchanges various data with the transmitter 1 via network 6.

[0054] The communication unit 21 includes a communication interface for server 2 to communicate via network 5 and network 6, and implements the communication protocols (such as IP communication method and dedicated line method) applied to network 5 and network 6, respectively.

[0055] The application data processing unit 22 exchanges and processes application-level data with the receiver 3 and transmitter 2 via HTTPS communication. For example, the application data processing unit 22 analyzes application data from the receiver 3 (which may not be limited to BML or HTML files) and issues processing commands to functions within the server 2 as needed.

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

[0057] The key storage unit 24 is, for example, a non-volatile memory, which stores the encryption key and the encryption / decryption key. However, the encryption key and the encryption / decryption key may be stored in physically different memories, taking into account the difference in the importance of their confidentiality.

[0058] The key generation unit 25 generates encryption keys and decryption keys and stores them in the key storage unit 24. In this embodiment, asymmetric key cryptography is applied, with the encryption key being the public key and the decryption key being the private key. The key generation unit 25 generates the public key and private key in a one-to-one combination. The private key is kept secret by the generator, while the public key does not need to be kept secret and may be made public to third parties. Asymmetric key cryptography and the method of generating public and private keys are common techniques, so a detailed explanation is omitted.

[0059] The decryption processing unit 26 decrypts the encrypted data received from the receiver 3 using the encryption / decryption key, obtains the receiver data, and outputs it. Specifically, the decryption processing unit 26 receives encrypted data, which is receiver data encrypted with the encryption key, from the application data processing unit 22. The decryption processing unit 26 decrypts the encrypted data using the encryption / decryption key and obtains the receiver data. The decryption method using an encryption / decryption key (private key) with asymmetric key cryptography is a common technique, so an explanation is omitted. In this embodiment, an example is shown where server 2 has both the encryption key and the encryption / decryption key, but the servers holding the encryption key and the encryption / decryption key may be different. In that case, the server holding the encryption / decryption key will have the function to perform processing using the encryption / decryption key.

[0060] The receiver data storage unit 27 stores the receiver data output from the decoding processing unit 26. The receiver data is arbitrary data related to the receiver 3, such as installation location information, owner information, viewing data, and viewing behavior data. For example, viewing data and viewing behavior data are used as analytical data for viewing analysis.

[0061] Figure 5 is a block diagram showing an example of the functional configuration of a receiver according to an embodiment.

[0062] Receiver 3 is, for example, a digital television receiver and has the function of receiving digital broadcasts, including 2K broadcasts and 4K / 8K broadcasts. Receiver 3 also has a communication interface for exchanging data with server 2 and external servers (not shown) via network 5. Furthermore, receiver 3 has a function to realize various broadcast communication linkage services by linking data obtained from digital broadcasts with data obtained from servers. Receiver 3 can also acquire and store viewing behavior data, such as viewing history of digital broadcast programs viewed by receiver 3, and information about the owner of receiver 3, for example. All of this data that receiver 3 can store is referred to as receiver data. Receiver 3 can store all or part of the receiver data in an information storage unit 36 ​​(NVRAM for data broadcasting). Receiver 3 can transmit receiver data to server 2 via network 5, for example. Server 2 uses the received receiver data by analyzing it. In this embodiment, 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 server 2. Furthermore, the receiver 3 is equipped with a CPU and other arithmetic processing functions to realize the above-mentioned functions.

[0063] The broadcast tuner 31 receives the broadcast wave 4 from an antenna or cable, performs decoding and demodulation on the broadcast wave 4 in accordance with the transmission line coding and modulation scheme of the transmitter 1 according to various digital broadcast standards, acquires the digital data of the broadcast stream, and outputs it.

[0064] The broadcast stream processing unit 32 performs operations on the broadcast stream input from the broadcast tuner 31, such as demultiplexing (data separation) and source encoding / decoding, according to various digital broadcasting standards, to acquire and output service data, data broadcasting service data, application data, and various control information.

[0065] 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 control information. Alternatively, the control unit 33 may receive various control commands from the user via the remote control unit 303 or the interface unit 302 and control various functions of the receiver 3 based on the control commands.

[0066] The application data storage unit 34 is, for example, a memory, and stores the application data output by the broadcast stream processing unit 32. Specifically, it may be used as a cache or buffer to store the application data received from the time the broadcast tuner 31 starts receiving the broadcast signal until the receiver 3 (specifically the application execution unit 35) executes the application.

[0067] The application execution unit 35 includes the functions of an application engine, such as a BML browser or an HTML browser. This will be described in detail in the explanation of Figure 7.

[0068] The information storage unit 36 ​​is, for example, a non-volatile memory (NVRAM). The information storage unit 36 ​​may also be a storage medium (also called NVRAM for data broadcasting) for data handled in data broadcasting, which is one of the services implemented in 2K and 4K / 8K broadcasting. The information storage unit 36 ​​may distinguish whether the data stored is encrypted or not by identifiers nvrame and nvram in the logical address.

[0069] 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 or unencrypted.

[0070] Figure 6 shows an example of the data storage area of ​​the information storage unit of the receiver according to the embodiment. This figure is intended to explain the data stored in the information storage unit 36, and is shown logically distinguished based on the content of the data, and does not necessarily show the physical relationships in the information storage unit 36. Therefore, not all of the contents shown in the figure are necessarily stored in the information storage unit 36.

[0071] Figure 6(a) shows an example of the memory area on NVRAM allocated to a broadcaster. NVRAM is broadly divided into areas for each broadcaster and areas shared by all broadcasters. Furthermore, each broadcaster's area and the shared area are divided into smaller areas called blocks (or items).

[0072] The address “nvram: / / b_id” shown in area 3601 indicates the location of a memory area on the information storage unit 36 ​​(NVRAM). Specifically, b_id is the value of the broadcaster identifier of a broadcasting company, and in applications transmitted by a broadcasting company to which the broadcaster identifier has been assigned, it can also be represented by the symbol ~. Here, area 3601 itself does not necessarily have to be on NVRAM; a correspondence table linking the NVRAM storage location to the broadcasting company may be stored in another memory (not shown), and the receiver 3 may refer to this correspondence table when accessing NVRAM.

[0073] In this embodiment, "name," "address," and "email address" are stored in blocks (or items). Note that the types of information such as "name," "address," and "email address" are shown as "information element names" in the diagram, but they are not actually stored as data. In other words, the "information element names" are shown for convenience in explaining Figure 6 and do not necessarily have to be stored as specific data in the information storage unit 36. Furthermore, each block is divided into field 1 and field 2, and the "data body" and "registration date and time" are written to each, respectively.

[0074] Area 3602 is field 1, where the main data is stored. For example, field 1 of block 0 stores the "Name".

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

[0076] Area 3604 represents the data in Block 1, which is a memory area on the information storage unit 36. The information element stored in Block 1 is "address". More specifically, Field 1 of Block 1 stores the specific "address" as the data body, and Field 2 stores the "registration date and time" when the "address" was registered.

[0077] Area 3605 represents the data in block N, which is a memory area on the information storage unit 36. The information elements stored in block N are "viewing behavior data," and are similar in detail to area 3604, so they are omitted here.

[0078] Figure 6(b) shows an example of data stored in the memory area of ​​the information storage unit 36. The difference from Figure 6(a) is the address shown in area 3606. The address nvrame: / / b_id shown in area 3606 is the same area as in Figure 6(a), which is assigned to a broadcaster identified by the broadcaster identifier b_id, but it indicates that it is an area on the information storage unit 36 ​​that stores encrypted data. In Figure 6(b), the "data body" of field 1 is all encrypted data (encrypted data).

[0079] Figure 6(c) shows an example of data stored in the memory area of ​​the information storage unit 36. The difference from Figure 6(a) is area 3607. In Figure 6(c), field 3, "Encryption Status," has been added. In the case of Figure 6(b), it is possible to determine whether the data stored in the information storage unit 36 ​​is encrypted by the address shown in area 3606, but in the case of Figure 6(c), it is possible to determine whether the data is encrypted by field 3.

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

[0081] The communication unit 38 includes a communication interface for the receiver 3 to communicate via the network 5 and implements the communication protocol (such as IP communication method or dedicated line method) applied to the network 5.

[0082] The display control unit 39 adjusts the output timing and processing of each data in order to display or output audio service data, data broadcasting service data, application data, etc., to the display unit 301, and then outputs the data (referred to as display data) to the display unit 301.

[0083] The display unit 301 is, for example, a monitor and a speaker, and displays the display data as video data or image data, or outputs it as sound from the speaker.

[0084] The interface unit 302 is the user interface between the receiver 3 and the user, and may include, for example, IR communication, which is the interface with the remote controller (remote control) attached to the receiver 3, and USB, which is the interface with a PC mouse, keyboard, etc. It should also be noted that the interface unit 302 may exchange data and signals with functional blocks within the receiver 3 that are not connected to the interface unit 302.

[0085] 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 the functions within the receiver 3, thereby enabling the user to control the receiver 3.

[0086] Figure 7 is a block diagram showing an example of the functional configuration of the application execution unit of the receiver according to the embodiment.

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

[0088] The API processing unit 351 interprets various API commands input from the data analysis unit 350 and outputs the interpretation result or the API command itself to the relevant function. Specifically, the API processing unit 351 causes the relevant function to execute the API processing based on the API command (API name and associated arguments, etc.) input from the data analysis unit 350.

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

[0090] The encryption determination unit 353 receives API commands from the API processing unit 351 and determines whether the API command relates to encrypted data. Specifically, if the API name includes "encrypted" or similar, as in APIs No. 4 and No. 6 in Figure 3, or if this is indicated by an argument, as in APIs No. 3 and No. 5 in Figure 3 (for example, if "nvrame: / / ~ / <block number>" is specified as the storage location identifier), then the unit recognizes those API commands as API commands that handle encrypted data.

[0091] The encryption key acquisition unit 354 receives an execution command to acquire an encryption key from the API processing unit 351 and executes the process according to the received execution command. Specifically, the encryption key acquisition unit 354 acquires an encryption key or checks whether an encryption key has already been acquired in the encryption key storage unit 355 by executing the process.

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

[0093] 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. The encryption and decryption methods using asymmetric key cryptography are common techniques and therefore will not be explained.

[0094] The receiver data acquisition unit 357 executes processing in response to execution commands from the API processing unit 351. Specifically, the receiver data acquisition unit 357 acquires receiver data from the information storage unit 36 ​​and the receiver data storage unit 37, and outputs the acquired receiver data to the encryption processing unit 356.

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

[0096] The communication processing unit 359 provides functions for the application execution unit 35 to communicate with devices outside the receiver 3 (e.g., server 2) via the network 5. Specifically, it provides functions such as HyperText Transfer Protocol (HTTP) communication, HyperText Transfer Protocol Secure (https) communication, or Transport Layer Security / Secure Sockets Layer (TLS / SSL) communication. Data output from the communication processing unit 359 is output to the network 5 from the communication unit 38.

[0097] (First Embodiment) In this embodiment, we will describe an example in which a command included in the data broadcasting service application causes the receiver 3 to encrypt the receiver data, write the encrypted data to the information storage unit 36 ​​by specifying a storage area, read the encrypted receiver data from the information storage unit 36, and transmit the encrypted data to the broadcasting station's server.

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

[0099] The following describes an example of the operation of the system according to this embodiment.

[0100] Figure 8 is a sequence chart showing an example of the operation of the system according to the first embodiment.

[0101] The system according to this embodiment operates in four main phases. The operation of each device is described for each phase.

[0102] Phase 1 is the phase in which the receiver 3 obtains the encryption key. The transmitter 1 transmits an "encryption key acquisition command" on broadcast wave 4 (step P11). The receiver 3 receives broadcast wave 4, and upon obtaining the "encryption key acquisition command," outputs an "encryption key request" to the server 2 (step P12). Upon receiving the "encryption key request," the server 2 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).

[0103] Phase 2 is the phase in which the receiver 3 writes encrypted data to the information storage unit 36. The transmitter 1 transmits a write command (for encrypted data) via broadcast wave 4 (step P21). When the receiver 3 receives the broadcast wave 4 and obtains the 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).

[0104] Phase 3 is the phase in which the receiver 3 reads encrypted data from the information storage unit 36. The transmitter 1 transmits a "read command (for encrypted data)" on the broadcast wave 4 (step P31). When the receiver 3 receives the broadcast wave 4 and obtains the "read command (for encrypted data)", it reads the specified encrypted data from the information storage unit 36 ​​(step P32).

[0105] Phase 4 is the phase in which Receiver 3 transmits encrypted data to Server 2 and Server 2 acquires the receiver data. Transmitter 1 transmits a "transmit command (for encrypted data)" on broadcast wave 4 (step P41). Receiver 3 receives broadcast wave 4 and, upon acquiring the "transmit command (for encrypted data)," transmits the encrypted data to the designated device (Server 2 in this embodiment) (step P42). Server 2 receives the encrypted data (step P43), decrypts the received encrypted data using the encryption / decryption key, and acquires the receiver data (step P44).

[0106] In this embodiment, the example shows the transmitter 1 generating "write commands," "read commands," and "transmit commands." However, the server 2 may generate each command, transfer it to the transmitter 1 via the network 6, and have the transmitter 1 transmit each command via broadcast waves 4.

[0107] The following flowcharts illustrate examples of the operation of transmitter 1, server 2, and receiver 3 in each phase.

[0108] Figure 9 is a flowchart showing an example of the processing operation of the transmitter according to the same embodiment.

[0109] The application data generation unit 14 of the transmitter 1 generates application data including API commands to cause the receiver 3 to execute the processing of all the above phases in order (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 may be "https: / / address of server 2 / path to encryption key file", argument 2 may be nvrame: / / ~ / <block number>, and argument 3 may be receiver data identification information. Argument 4 is information that identifies the destination. For example, if encrypted data is to be sent to the broadcasting station's server 2, it could be "https: / / server2's address?datatype=nvram&encrypted=yes". Argument 5 is information that represents the encrypted data read by the API command for each file, i.e., readPersistentArray(argument 2) or getItem(argument 2). For example, it could be a variable or object that indicates the storage location of the encrypted data to be read. 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 and the control information generation unit 12, and outputs it as a broadcast stream (step S12).

[0110] When the broadcast signal transmission unit 17 receives digital data of a broadcast stream, it generates and outputs a broadcast wave 4 by performing transmission line coding and modulation according to the standards of various digital broadcasts (step S13). The broadcast wave 4 is output from an antenna, cable, etc. (not shown).

[0111] Figure 10 is a flowchart showing an example of the receiver's processing operation in the same embodiment.

[0112] For example, suppose a user changes 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). The control unit 33 controls the broadcast tuner 31 in response to the "channel selection command," and the broadcast tuner 31 receives the broadcast wave 4 of the selected channel (step S32). The broadcast tuner 31 processes the broadcast wave 4 to obtain a broadcast stream, and the broadcast stream processing unit 32 processes the broadcast stream to obtain various data. When application control information is output to the control unit 33 from the data acquired by the broadcast stream processing unit 32, 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). Meanwhile, application data from the data acquired by the broadcast stream processing unit 32 is temporarily stored in the application data storage unit 34 (step S35). When the application execution unit 35 starts up, the data analysis unit 350 retrieves application data from the application storage unit 34 and analyzes the application data (step S36). The data analysis unit 350 outputs the API commands extracted from the analyzed application data to the API processing unit 351, which interprets the API commands and executes the API functions (step S37).

[0113] Figure 11 is a flowchart showing an example of the processing operation of the application execution unit when obtaining 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 Figure 10.

[0114] The API processing unit 351 receives the API command shown in row No. 1 of Figure 3 and recognizes the API command (step S311). Note that there are differences in the API commands for each function between 2K broadcasting (TS method) and 4K8K method (MMT method), but there are no particular differences in the processing of the API command and the processing by the API. Therefore, unless otherwise specified, the descriptions in the embodiments are applicable to both 2K broadcasting (TS method) and 4K8K method (MMT method). Whether the broadcast wave 4 received by the receiver 3 is 2K broadcasting (TS method) or 4K8K method (MMT method) is determined in step S32 of Figure 10. The API processing unit 351 recognizes that the received API command is an API command that requests an encryption key from the server 2, and causes the encryption key acquisition unit 354 to execute the encryption key acquisition process. 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 the execution request based on the API command from the API processing unit 351, and sends the encryption key request message to the server 2 via the communication processing unit 359 and the communication unit 38. When the encryption key is sent 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).

[0115] Figure 12 is a flowchart showing an example of the server's processing operation when obtaining an encryption key in the same embodiment.

[0116] In 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). The key generation unit 25 may generate the encryption key and encryption / decryption key when it receives an encryption key request message from receiver 3, or it may generate them at any time regardless of whether or not it has received an encryption key request message from receiver 3 and store them in the key storage unit 24. The application data processing unit 22 receives a message via the communication unit 21 and, upon recognizing that it is an encryption key request message, outputs an 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 sends the encryption key to receiver 3, for example, via HTTPS communication (step S214). Through the above procedure, receiver 3 can obtain the encryption key owned by server 2.

[0117] Figure 13 is a flowchart showing an example of the processing operation of the application execution unit during data writing 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 Figure 10.

[0118] The API processing unit 351 receives the API command shown in row No. 3 or No. 4 of Figure 3. 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 arguments (step S322). In this embodiment, for example, if the API command name is "writePersistentArrayEncrypted", it may be determined that it is an API command that handles encrypted data, and if the API command name is "writePersistentArray", it may be determined that it does not handle encrypted data. Alternatively, if the argument of the API command is "nvram: / / ~ / <block number>", it may be determined that it is an API command that handles encrypted data, and if the argument of the API command is "nvram: / / ~ / <block number>", it may be determined that it does not handle encrypted data.

[0119] If the API command handles encrypted data, the API processing unit 351 instructs the encryption processing unit 356 to perform processing based on the API command. The encryption processing unit 356 recognizes the receiver data to be encrypted from the receiver data identification information specified in the arguments of the API command, and encrypts the specified receiver data (unencrypted data) (Yes in step S322, step S323). More specifically, when the encryption processing unit 356 receives a processing execution command from the API processing unit 351, it retrieves the receiver data from, for example, the receiver data storage unit 37 (or the information storage unit 36 ​​in some cases), encrypts the retrieved receiver data using the encryption key stored in the encryption key storage unit 355, and outputs the encrypted data 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 indicated by <block number> in nvrame: / / ~ / <block number>) (step S324). On the other hand, if the encryption determination 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 encryption (No. in step S322, step S325).

[0120] Figure 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 Figure 10.

[0121] The API processing unit 351 receives the API command shown in row No. 5 or No. 6 of Figure 3 and recognizes the API command (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 arguments (step S332). In this embodiment, for example, if the API command name is "readPersistentArrayEncrypted", it may be determined that it is an API command that handles encrypted data, and if the API command name is "readPersistentArray", it may be determined that it does not handle encrypted data. Alternatively, if the argument of the API command is "nvram: / / ~ / <block number>", it may be determined that it is an API command that handles encrypted data, and if the argument of the API command is "nvram: / / ~ / <block number>", it may be determined that it does not handle encrypted data. 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 unencrypted data storage area of ​​the information storage unit 36 ​​and outputs it to the communication processing unit 359 (step S334). In embodiments where there is no distinction between the storage area for encrypted data and the storage area for unencrypted data, the read processing unit 352 may not perform the determination of whether the API command handles encrypted data (step S332), and may simply retrieve the data from the information storage unit 36 ​​and output it to the communication processing unit 359. The communication processing unit 359 may store the encrypted data in, for example, a memory or buffer not shown.

[0122] Figure 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 Figure 10.

[0123] The API processing unit 351 receives the API command shown in row No. 7 of Figure 3 and recognizes the API command (step S341). Based on the recognized API command, the API processing unit 351 causes the communication processing unit 359 to execute processing. 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 sent from the communication unit 38 via the network 5 to the server 2 identified by the URL specified by the API command (step S343). Alternatively, by immediately executing the API function corresponding to the API command in row No. 7 of Figure 3 after the execution of the API function corresponding to the API command in row No. 5 or No. 6 of Figure 3, which is phase 3, the communication processing unit 359 may transmit the encrypted data read from the information storage unit 36 ​​in phase 3 regardless of the arguments of the API command in row No. 7.

[0124] Figure 16 is a flowchart showing an example of the server's processing operation when receiving data in the same embodiment.

[0125] The application data processing unit 22 of server 2 receives the https transmission data sent by receiver 3 (step S221). The application data processing unit 22 analyzes the destination URL included in the https transmission data (step S222). For example, if the destination URL is "https: / / server2's address?datatype=nvram&encrypted=yes" and contains "encrypted=yes", the application data processing unit 22 determines that the data included in the https transmission data is encrypted. On the other hand, if the destination URL is "https: / / server2's address?datatype=nvram&encrypted=no" and contains "encrypted=no", the application data processing unit 22 determines that the data included in the https transmission data is not encrypted. If the analysis of the URL reveals that the data included in the https transmission data is encrypted, 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).

[0126] Through the above procedure, an API command included in the data broadcasting service application can cause receiver 3 to encrypt the receiver data and write it to the information storage unit 36 ​​(NVRAM). Furthermore, an API command included in the data broadcasting service application can cause receiver 3 to read the encrypted receiver data from the information storage unit 36 ​​and transmit it to the broadcasting station's server 2. The broadcasting station's server 2 can receive the encrypted receiver data from receiver 3 and obtain the receiver data by decrypting the encrypted receiver data.

[0127] In this embodiment, by encrypting the data stored in the information storage unit 36 ​​using asymmetric key cryptography, the encrypted data stored in the information storage unit 36 ​​can only be decrypted using the encryption / decryption key held only by the server 2. Therefore, the server 2 can collect receiver data while ensuring confidentiality (or confidentiality in information security technology). It is also possible to use symmetric key cryptography as the encryption technology for the data. However, when using symmetric key cryptography, a common key is used to encrypt the data. The common key is necessary for both encrypting and decrypting encrypted data. If symmetric key cryptography is applied in this embodiment, the receiver 3 that encrypts the data and the server 2 that decrypts the encrypted data share the same common key. Therefore, when symmetric key cryptography is applied, the receiver 3 also possesses a key that can decrypt encrypted data. If a third party, who is neither the owner of receiver 3 nor the administrator of server 2 (i.e., a broadcaster), reads encrypted data from the information storage unit 36 ​​by some means (for example, by connecting a reading device to the semiconductor memory that is the actual data broadcasting NVRAM and reading the data), and also retrieves the common key held by receiver 3, then the third party can decrypt the encrypted data and obtain the receiver data, thus failing to solve the problem of ensuring the confidentiality of information. Asymmetric key cryptography is very effective in ensuring the confidentiality of information in a system like this embodiment because it uses a publicly available key that can be made public and known to third parties as the encryption key, and does not require sharing a decryption key. In this embodiment, the above problems are solved by applying asymmetric key cryptography.

[0128] (Second embodiment) In this embodiment, an example is described in which a command included in the data broadcasting service application causes the receiver 3 to acquire the encryption key contained in the broadcast signal. In this embodiment, an example is described in which the encryption key transmitted on the broadcast wave 4 as part of the application data is acquired.

[0129] The system configuration of this embodiment will be explained using Figure 1, the functional configuration of the transmitter 1 using Figure 2, the functional configuration of the server 2 using Figure 4, and the functional configuration of the receiver 3 using Figures 5 and 7.

[0130] The following describes an example of the operation of the system according to this embodiment.

[0131] Figure 17 is a sequence chart of the system according to the second embodiment, which shows an example of the system's operation during the phase in which receiver 3 obtains the encryption key transmitted as part of the application data.

[0132] The broadcasting station's server 2 generates an encryption key and transmits the generated "encryption key" to transmitter 1 via network 6 (step P121). Transmitter 1 transmits the encryption key via broadcast wave 4 (step P122). Here, transmitter 1 stores the encryption key in the application data and transmits it via broadcast wave 4. In addition to transmitting the encryption key, transmitter 1 transmits an "encryption key acquisition command" via broadcast wave 4 (step P123). Receiver 3 receives and analyzes broadcast wave 4 (step P124). As a result of the analysis, if receiver 3 detects the "encryption key acquisition command", it further analyzes broadcast wave 4 and obtains the encryption key in the application data (step P125).

[0133] Figure 18 is a flowchart showing an example of the processing operation of the transmitter according to the same embodiment.

[0134] 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 encryption key transmission data may be stored as an application resource (file) in a storage location on the broadcast wave 4 (similar to ARIB STD-B24, ARIB STD-B62, etc.) depending on the type of broadcast wave 4, as shown below. <If broadcast wave 4 is TS method> arib-dc: / / encryption key resource name <If broadcast wave 4 is MMT method> arib-dc2: / / encryption key resource name Furthermore, independently of (in parallel with) step S1201, application data is generated including API commands as shown below to allow receiver 3 to obtain the 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)} For argument 1 and argument 2, for example, argument 1 for a BML file is "arib-dc: / / resource name of the encryption key", and argument 2 for an HTML file is "arib-dc2: / / resource name of the encryption key".

[0135] 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 unit 12, and outputs them as a broadcast stream (step S1203). The encryption key transmission data is stored in the application stream.

[0136] When the broadcast signal transmission unit 17 receives digital data of a broadcast stream, it generates and outputs a broadcast wave 4 by performing transmission line coding and modulation according to the standards of various digital broadcasts (step S1204). The broadcast wave 4 is output from an antenna, cable, etc. (not shown).

[0137] Figure 19 is a flowchart showing an example of the processing operation of the application execution unit when obtaining an encryption key in the same embodiment. The processing operation of the receiver 3 is the same as the flowchart in Figure 10, and Figure 19 shows the processing operation corresponding to step S37 in Figure 10.

[0138] The API processing unit 351 of the receiver 3 receives the API command shown in row No. 2 of Figure 3 and recognizes the API command (step S3201). When the API processing unit 351 recognizes from the arguments of the API command that an encryption key is stored in the broadcast wave 4, it causes the control unit 33 to execute processing based on the API command. The control unit 33 performs 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 identified 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).

[0139] By following the above procedure, the receiver 3 will be able to obtain the encryption key that is transmitted along with the broadcast wave 4, based on the instructions included in the data broadcasting service application.

[0140] (Third embodiment) In this embodiment, an example is described in which the receiver 3 is instructed to obtain the encryption key contained in the broadcast signal. In this embodiment, an example is described in which the encryption key is obtained from the SI (Signaling Information) transmitted on the same broadcast wave 4 separately from the application data.

[0141] The system configuration of this embodiment will be explained using Figure 1, the functional configuration of the transmitter 1 using Figure 2, the functional configuration of the server 2 using Figure 4, and the functional configuration of the receiver 3 using Figures 5 and 7.

[0142] The following describes an example of the operation of the system according to this embodiment.

[0143] Figure 20 is a sequence chart of the system according to the third embodiment, and is an example of the system's operation during the phase in which the receiver 3 obtains an encryption key from the SI transmitted on the same broadcast wave 4, separately from the application data.

[0144] The broadcasting station's server 2 generates an encryption key and sends the generated encryption key to the transmitter 1 via the network 6 (step P131). Transmitter 1 transmits the encryption key on the SI of broadcast wave 4 (step P132). Here, transmitter 1 may repeatedly transmit the encryption key on broadcast wave 4. Receiver 3 receives and analyzes broadcast wave 4 (step P133). Through analysis, receiver 3 obtains the encryption key stored on broadcast wave 4 (step P134).

[0145] Figure 21 shows an example of transmitting an encryption key in the SI of the TS-type broadcast wave 4 in the same embodiment. Figure 21(a) is a descriptor (broadcaster public key descriptor) that stores the public key of the broadcaster, which is the encryption key, and its structure is as per the common descriptor structure specified in ARIB STD-B10. The descriptor is transmitted by placing it in the descriptor area of ​​the broadcaster information table (BIT) specified in ARIB STD-B10, for example, shown in area 1241A or 1241B in Figure 21(b).

[0146] Figure 22 shows an example of transmitting an encryption key in the SI of the MMT broadcast wave 4 in the same embodiment. Figure 22(a) is a descriptor (MH-broadcaster public key descriptor) that stores the public key of the broadcaster, which is the encryption key, and its structure is as per the common descriptor structure specified in ARIB STD-B60. The descriptor is transmitted by placing it in the descriptor area of ​​the MH-broadcaster information table (MH-BIT) specified in ARIB STD-B60, for example, shown in area 1242A or 1242B in Figure 22(b).

[0147] Transmitter 1 transmits a write command (for encrypted data) via broadcast wave 4 independently of step P131 (step P231). When receiver 3 receives the write command (for encrypted data), it checks, for example, whether the encryption key required for encryption is stored in the encryption key storage unit 355 (step P232). When 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 (for encrypted data) using the encryption key (step P233). Receiver 3 stores the encrypted receiver data in the information storage unit 36 ​​(step P234). The following describes an example of the operation of transmitter 1 and receiver 3 in this embodiment.

[0148] Transmitter 1 transmits the encryption key as control information (e.g., SI) in, for example, the control information generation unit 12. In addition, the application data generation unit 14 of Transmitter 1 generates application data independently of the transmission of the encryption key, including the API command in row No. 3 of Figure 3, as follows: <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". Arguments 2 and 4 may also be receiver data identification information. The above API command is the same as the API command used in the first embodiment, so its explanation is omitted.

[0149] Figure 23 is a flowchart showing an example of the receiver's processing operation in the same embodiment.

[0150] The operations from steps S3301 to S3306 are the same as steps S31 to S37 in Figure 10 of the first embodiment, so their explanation is omitted here. In this embodiment, unlike the operation example of the first embodiment, steps S3307 to S3309 are added. In the flowchart of Figure 23, steps S3302 onwards, S3303, S3304, and S3307 are shown to be operating in parallel (independently).

[0151] 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).

[0152] Figure 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 Figure 23.

[0153] The API processing unit 351 receives the API command shown in row No. 3 of Figure 3 and recognizes the API command (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 arguments (step S3322). In this embodiment, since the arguments of the API command include "nvrame:", the encryption determination unit 353 determines that it is an API command that handles encrypted data, and based on this determination, the API processing unit 351 causes the encryption key acquisition unit 354 to check whether the encryption key required is stored in the encryption key storage unit 355 (step S3323). If the encryption key required 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 in the arguments of the API command using the encryption key obtained in the previous step, and generates encrypted data (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 encryption (steps S3322 and S3327). Also, if the encryption key acquisition unit 354 does not have the necessary encryption key stored in the encryption key storage unit 355, it terminates without encrypting the specified receiver data (step S3323). Alternatively, you can wait a while and then repeat from step S3323.

[0154] Through the above procedure, the receiver 3 can obtain an encryption key from the SI transmitted on the same broadcast wave 4, separately from the application data on the broadcast wave 4. By an instruction included in the data broadcasting service application, the receiver 3 can be instructed to encrypt the receiver data and write the encrypted data to the information storage unit 36 ​​(NVRAM).

[0155] In the second embodiment, an example of transmitting the encryption key as part of the application data of the broadcast wave 4 was described, and in the third embodiment, an example of transmitting the encryption key as the SI of the broadcast wave 4 was described. However, for example, it is also possible to transmit the encryption key as the SI in the second embodiment, or as part of the application in the third embodiment. Specifically, in the former embodiment, an empty string may be set as information identifying the storage location of the encryption key in the broadcast wave 4 in the API command for obtaining the encryption key, and the control unit 33 may, upon confirming that an empty string is specified as information identifying the storage location of the encryption key, obtain the encryption key from the SI of the broadcast wave 4 and output the obtained encryption key to the API processing unit 351. In the latter embodiment, the encryption key may be stored as a predetermined resource in the application data. As described above, there are methods for the transmitting side (transmitter 1) to transmit the key, such as transmitting it as part of the application data or transmitting it as the SI. Also, there are methods for the receiving side (receiver 3) to receive the key, such as using the API or the receiver performing the reception in the background without using the API. There are no particular restrictions on the combination of methods for sending and receiving these keys; any combination is possible.

[0156] (Fourth embodiment) In this embodiment, an example is described in which 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 then read the written data. In this embodiment, the receiver 3 recognizes that the API command handles encrypted data by including a word in the API name of the API command that indicates it handles encrypted data.

[0157] The system configuration of this embodiment will be explained using Figure 1, the functional configuration of the transmitter 1 using Figure 2, the functional configuration of the server 2 using Figure 4, and the functional configuration of the receiver 3 using Figures 5 and 7.

[0158] The following describes an example of the operation of the system according to this embodiment. In this embodiment, it is assumed that the encryption key is stored in the encryption key storage unit 355. The operation examples of the transmitter 1, server 2, and receiver 3 will be explained using the flowchart used in the first embodiment. Furthermore, explanations of parts that are the same as the operation example in the first embodiment will be omitted.

[0159] The following describes an example of the operation of transmitter 1 using the flowchart in Figure 9.

[0160] The application data generation unit 14 generates application data as shown below (step S11 in Figure 9) including the API commands in lines No. 4, No. 6, and No. 7 of Figure 3 in order to have the receiver 3 write, read, and transmit encrypted receiver data. <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>" for BML files, or "_wlocal+item number" for HTML files. Argument 2 may be receiver data identification information for both BML and HTML files. Argument 3 is information representing the encrypted data read by the API command for each file, i.e., readPersistentArray(argument 1) or getItemEncrypted(argument 1). For example, it may be a variable or object indicating the storage location of the encrypted data to be read. Argument 4 is information identifying the destination. For example, if encrypted data is to be sent to the broadcasting station's server 2, it may be "https: / / server2's address?datatype=nvram&encrypted=yes". Unlike the arguments in the first embodiment, in this embodiment, argument 1 for the data writing destination is set to "nvram:". Also, regarding the data transmission API command (the API in line No. 7 in Figure 3), if the API command that executes the encrypted data reading API and the API command that executes the data transmission API are written consecutively as described above, the data transmission API may send the data read by the encrypted data reading API even without specifying argument 2.

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

[0162] Next, an example of the operation of the receiver 3 during data writing will be explained using Figures 10 and 13, which were shown in the description of the first embodiment.

[0163] Receiver 3 extracts API commands according to the flowchart in Figure 10 (step S37), and then performs encryption processing of receiver data according to the flowchart in Figure 13 (step S323), thereby obtaining encrypted data.

[0164] Figure 25 is a flowchart showing 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 Figure 13.

[0165] The writing processing unit 358 generates encrypted identification information for the encrypted receiver data to indicate that it is "encrypted data" (step S3401). The writing processing unit 358 generates a data block including the encrypted receiver data and the encrypted identification information (step S3402). A data block represents the data of all fields in each block shown in Figure 6, and may be called an encrypted data block in particular when the "data" in field 1 is encrypted receiver data.

[0166] Figure 6(c) shows an example of data stored in the memory area of ​​the information storage unit 36, with the addition of area 3607 and the field "Encryption Status" compared to Figure 6(a). The encryption identification information may be, for example, a 1-bit data, where 0 indicates unencrypted data and 1 indicates encrypted data. In this embodiment, an example is shown in which encryption processing of "data" is performed for each block and the encryption identification information for each block is stored in area 3607. In the first embodiment, the area for storing encrypted receiver data was specified as nvrame: / / ~ as shown in area 3606 of Figure 6(b), but in this embodiment, the area for storing encrypted receiver data is nvram: / / ~. For this reason, in the example of this embodiment, encrypted receiver data and unencrypted receiver data may be stored together. In this embodiment, by adding area 3607 in Figure 6(c), it is possible to distinguish between encrypted receiver data and unencrypted receiver data. Alternatively, instead of storing the encryption identification information in area 3607, a correspondence table between the blocks of the information storage unit 36 ​​and the encryption identification information may be created and the correspondence table stored separately in memory or elsewhere.

[0167] Returning to Figure 25, the writing processing unit 358 writes the encrypted data block to the information storage unit 36 ​​specified by nvram: / / ~ (step S3403).

[0168] By following the above procedure, encrypted data can be written to the information storage unit 36 ​​(NVRAM for data broadcasting) without defining an area for encrypted data.

[0169] The following describes an example of the operation of receiver 3 when reading data.

[0170] Figure 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 Figure 10.

[0171] The API processing unit 351 receives the API command shown in row No. 6 of Figure 3 and recognizes the API command (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 arguments (step S3432). In this embodiment, since the API name contains "Encrypted", the encryption determination unit 353 determines that it is an API command that handles encrypted data, and the API processing unit 351 causes the read processing unit 352 to execute processing based on the API command, and the read processing unit 352 performs the processing to read the encrypted data. If the encryption identification information for the "information element" specified for reading in the receiver data identification information, which is an argument of the API command (area 3607 in Figure 6(c)) is 1, the read processing unit 352 reads the data of the "information element" specified for reading and outputs it to the communication processing unit 359 (Yes in step S3433, S3434). If the encryption identification information for the "information element" specified for reading is 0, the reading processing unit 352 cancels the reading of the "information element" specified for reading (No. in step S3433, S3435). On the other hand, if the encryption determination unit 353 does not determine that it is an API command that handles encrypted data, the API processing unit 351 causes the reading processing unit 352 to perform the reading process of unencrypted data. If the encryption identification information for the "information element" specified for reading (area 3607 in Figure 6(c)) is 0, the reading processing unit 352 reads the data of the specified "information element" and outputs it to the communication processing unit 359 (Yes in step S3436, S3434). If the encryption identification information for the "information element" specified for reading is 1, the reading processing unit 352 cancels the reading of the "information element" specified for reading (No. in step S3433, S3435). In the communication processing unit 359, when data read by the read processing unit 352 is input, it may be stored in, for example, a memory or buffer (not shown).In this embodiment, since an API command for executing an encrypted data reading API is written immediately after an API command for executing an encrypted data reading API, the data read by the reading processing unit 352 may be immediately transmitted from the communication processing unit 359 to the server 2 via the communication unit 38.

[0172] By following the above procedure, encrypted data can be read from the information storage unit 36 ​​(NVRAM for data broadcasting) without defining an area for encrypted data. If there is a correspondence table between the blocks of the information storage unit 36 ​​and the encrypted identification information, the read processing unit 352 may perform the read process based on the correspondence table. Furthermore, according to this embodiment, even if encrypted and unencrypted data are mixed in the information storage unit 36, which does not define an area for encrypted data, both encrypted and unencrypted data can be selected and read.

[0173] The data read using the above procedure can be transmitted externally using the flowchart in Figure 15. Details of data transmission are the same as in the first embodiment and will therefore be omitted. Furthermore, the encrypted data transmitted from receiver 3 can be received by server 2 using the flowchart in Figure 16, and the encryption can be decrypted to obtain the (unencrypted) receiver data. Details of the reception and decryption of encrypted data by server 2 are the same as in the first embodiment and will therefore be omitted.

[0174] According to this embodiment, a command included in the data broadcasting service application can cause the receiver 3 to encrypt the receiver data, write the encrypted data to the information storage unit 36 ​​(NVRAM for data broadcasting) without specifying an encryption area, read the written data, and transmit it to the server 2.

[0175] 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 the information.

[0176] The key features of the receiver in the above-mentioned system can also be described as follows: (1) A receiver comprising an application execution means (application execution unit 35) that executes application data of a data broadcasting service included in a broadcast signal, an information writing means (writing processing unit 358) that executes writing of information instructed by the application data, and an information storage means (information storage unit 36) that stores the information instructed by the application data, wherein the receiver comprises an encryption means (encryption processing unit 356) that encrypts the information instructed by the application data, and an encryption key storage means (encryption key storage unit 355) that stores the encryption key used by the encryption means, and is characterized in that the information is encrypted by the encryption means before being written to the information storage means. (2) The receiver according to (1), further comprising an information reading means (reading processing unit 352) that reads encrypted information from the information storage means in accordance with the instructions of the application data, and is characterized in that the read information is output to an external device (server 2) without decryption. (3) The receiver according to (1) or (2), wherein the encryption key is a public key of a public-key cryptography scheme. (4) The receiver according to (1) to (3), further comprising an encryption key storage instruction means for storing an encryption key in the encryption key storage means according to an instruction contained in the application data. (5) The receiver according to (4), further comprising an encryption key that is part of the application data of the data broadcast included in the broadcast signal. (6) The receiver according to (4), further comprising an encryption key that is obtained from an external device (server 2) that possesses an encryption decryption key. (7) The receiver according to (1) to (3), further comprising an encryption key separation means (control unit 33) for extracting the encryption key from the portion of the broadcast signal excluding the application data and storing the encryption key in the encryption key storage means. (8) The receiver according to (1) to (7), further comprising an information writing means and an information reading means that are APIs provided by the application execution means for being called from a data application.(9) The receiver according to (4) to (6), wherein the encryption key storage instruction means is an API provided by the application execution means for being called from a data application.

[0177] The key features of the transmitter in this system described above can also be described as follows: (A1) A transmitter for digital television broadcasting, An encryption key storage unit that retrieves an encryption key from a server that possesses the encryption key and stores the said encryption key, A transmitter comprising a digital television broadcast receiver, a write command that causes the receiver to encrypt the receiver data in the receiver with the encryption key and write the encrypted data to the receiver's internal information storage means, and a broadcast signal transmission means that transmits the encryption key along with the broadcast signal. (A2) The aforementioned encryption key is the public key of a public-key cryptosystem, as described in (A1) (A3). A transmitter according to either (A1) or (A2), comprising a means for transmitting write commands. (A4) The transmitter according to any one of (A1) to (A3), wherein the write command includes identification information for receiver data to be written and data storage identification information which is the storage location for encrypted data generated by encrypting the receiver data. (A5) The aforementioned data storage identification information is encrypted write instruction information generated by encrypting the receiver data, as described in (A4). (A6) The receiver described in (A4) includes identification information for determining that the receiver data to be written is encrypted data. (A7) The transmitter according to any one of (A1) to (A6), wherein the write command is included in application data broadcast in the data broadcasting service of the digital television broadcast, and the application data is included in the broadcast signal. (A8) The aforementioned write command is a command to the API incorporated in the receiver, as described in (A7).

[0178] The key points of this system described above can also be summarized as follows: (B1) In a digital television broadcasting system comprising a transmitter, a server, and a receiver, The transmitter and the server share an encryption key. The transmitter has an encryption key storage unit that obtains an encryption key from a server that has an encryption key and stores the encryption key, The receiver for the digital television broadcast is provided with a write command that encrypts the receiver data in the receiver with the encryption key and writes the encrypted data to the information storage means inside the receiver, and a broadcast signal transmission means that includes the encryption key in the broadcast signal and transmits it. The receiver includes a broadcast signal receiving means for receiving a broadcast signal, An encryption key acquisition means for acquiring an encryption key from the aforementioned broadcast signal, An encryption means that generates encrypted data by encrypting receiver data in the receiver using the encryption key based on a write command included in the broadcast signal, A system comprising: an information writing means for writing the encrypted data to an information storage unit. (B2) The aforementioned encryption key is the public key of the public-key cryptography system described in (B1). (B3) The system described in either (B1) or (B2), wherein the write command is included in application data broadcast in the data broadcasting service of the digital television broadcast, and the application data is included in the broadcast signal. (B4) The encryption key is included in the application data as described in any one of items (B1) to (B3). (B5) The encryption key is included in the portion of the broadcast signal excluding the application data, according to any one of the systems described in (B1) to (B3).

[0179] While several embodiments of the present invention have been described, these embodiments are presented as examples only 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 modifications can be made without departing from the spirit of the invention. These embodiments and their variations are included in the scope and spirit of the invention, as well as in the claims and their equivalents. Furthermore, even if each component of a claim is expressed by dividing it, by combining multiple components, or by combining them, it remains within the scope of the present invention. Multiple embodiments may also be combined, and embodiments composed of such combinations also fall within the scope of the invention.

[0180] Furthermore, drawings may schematically represent the width, thickness, shape, etc., of each part, even if they are not shown in their actual form, in order to make the explanation clearer. In functional block diagrams, the components of the functions necessary for the explanation are represented by blocks, and descriptions of general functional components may be omitted. Also, the blocks that represent functions are conceptual and do not necessarily need to be physically configured as shown. For example, the specific form of distribution and integration of each functional block is not limited to the form shown in the diagram. Depending on the usage situation of each functional block, they may be configured by distributing or integrating them functionally or physically. In block diagrams, data and signals may be exchanged between unconnected blocks or in directions where arrows are not shown even if they are connected. Each function shown in a block diagram, and the processes shown in flowcharts and sequence charts, may be realized by hardware (such as IC chips), software (such as programs), a digital signal processor (DSP), or a combination of these hardware and software. Furthermore, the present invention applies to any apparatus or method expressed as control logic, as a program containing instructions for a computer to execute, or as a computer-readable recording medium on which such instructions are described. The use of names and terms is also not limited; other expressions are included if they are substantially the same in content and spirit. [Explanation of symbols]

[0181] 1...Transmitter, 2...Server, 3...Receiver, 4...Broadcast wave, 5...Network, 6...Network, 10...Broadcasting station, 11...Service data stream generation unit, 12...Control information generation unit, 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 unit, 24...Key storage unit, 25...Key generation unit, 26...Decryption processing unit, 27...Receiver data storage, 31...Broadcast tuner 32...Broadcast stream processing unit, 33...Control unit, 34...Application data storage unit, 35...Application execution unit, 36...Information storage unit, 37...Receiver data storage unit, 38...Communication unit, 39...Presentation control unit, 301...Presentation unit, 302...Interface unit, 303...Remote control unit, 350...Data analysis unit, 351...API processing unit, 352...Read processing unit, 353...Encryption determination unit, 354...Encryption key acquisition unit, 355...Encryption key storage unit, 356...Encryption processing unit, 357...Receiver data acquisition unit, 358...Write processing unit, 359...Communication processing unit.

Claims

1. A digital television broadcasting system comprising a transmitter, a server, and a receiver, The transmitter has an application data generation means, The aforementioned application data generation means uses the following API commands: A key acquisition command to cause the receiver to obtain an encryption key, A write command to generate encrypted data by encrypting the receiver data present in the receiver using the encryption key and writing it to the information storage unit, A read command instructs the information reading means of the receiver to read the encrypted data from the information storage unit, A transmission command that instructs the server to send the encrypted data that has been read, The application data generation means generates and includes in the broadcast signal, The aforementioned server, The receiver includes means for transmitting, via the transmitter, a read command for reading the encrypted data from the information storage unit, and a transmit command for transmitting the read encrypted data to the server, means for decrypting the received encrypted data, It has, The aforementioned receiver is The system includes receiving means for receiving the broadcast signal sent from the transmitter, and application execution means, The aforementioned application execution means is An encryption key acquisition means that acquires the encryption key from the server based on the key acquisition command included in the broadcast signal, An encryption means that, based on the write command included in the broadcast signal, encrypts the receiver data present in the receiver using the encryption key to generate the encrypted data, The system includes an information writing means for writing the encrypted data to the information storage unit. Digital television broadcasting system.

2. In the aforementioned application execution means, The digital television broadcasting system according to claim 1, wherein the information writing means confirms that the API command handles encrypted data and writes the encrypted data of the receiver data to the information storage unit.

3. In the aforementioned application execution means, The digital television broadcasting system according to claim 1, wherein the information writing means writes unencrypted data of the receiver data to the information storage unit when the API command indicates that it does not handle encrypted data.

4. A digital television broadcasting method comprising a transmitter, a server, and a receiver, The application data generation means included in the transmitter is As an API command, A key acquisition command to cause the receiver to obtain an encryption key, A write command to generate encrypted data by encrypting the receiver data present in the receiver using the encryption key and writing it to the information storage unit, A read command instructs the information reading means of the receiver to read the encrypted data from the information storage unit, A transmission command that instructs the server to send the encrypted data that has been read, Generate and include in the broadcast signal. In the aforementioned server, The receiver transmits, via the transmitter, a read command to read the encrypted data from the information storage unit, and a transmit command to transmit the read encrypted data to the server. The received encrypted data is decrypted, In the aforementioned receiver, The broadcast signal sent from the aforementioned transmitter is received, In the application execution method, Based on the key acquisition command included in the broadcast signal, the encryption key is acquired from the server. Based on the write command included in the broadcast signal, the receiver data present in the receiver is encrypted using the encryption key to generate the encrypted data. The encrypted data is written to the information storage unit. Digital television broadcasting method.

5. The information writing means included in the application execution means, The digital television broadcasting method according to claim 4, wherein the API command indicates that encrypted data is to be handled, and the encrypted data of the receiver data is written to the information storage unit.

6. The information writing means included in the application execution means, If the API command indicates that encrypted data is not being handled, the digital television broadcasting method according to claim 4, wherein the unencrypted data of the receiver data is written to the information storage unit.

Images