Digital television broadcasting system and 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] The embodiments relate to a digital television broadcasting system and method. [Background technology]

[0002] Receivers (hereafter simply referred to as receivers) compatible with satellite digital broadcasting, 110-degree CS digital broadcasting, terrestrial digital broadcasting (collectively referred to as 2K broadcasting), and advanced wideband satellite digital broadcasting (also referred to as 4K / 8K broadcasting) are equipped with non-volatile memory (NVRAM), a rewritable storage medium that retains its contents even when power is interrupted (i.e., non-volatile). NVRAM is used as a storage medium (also referred to as data broadcasting NVRAM) for data broadcasting (also referred to as receiver data), which is one of the services provided by 2K broadcasting and 4K / 8K broadcasting. Data broadcasting NVRAM is created and transmitted by broadcasters and can be accessed by data broadcasting content executed on the receiver. However, access control technologies are provided to conceal data stored in data broadcasting NVRAM by a broadcaster from other broadcasters, such as by specifying accessible areas for each broadcaster. [Prior art documents] [Patent documents]

[0003] [Patent Document 1] Patent No. 5027636 [Non-patent literature]

[0004] [Non-Patent Document 1] ARIB TR-B14 6.2 Edition "Digital Terrestrial Television Broadcasting Operational Guidelines" [Non-patent document 2] ARIB TR-B39 2.2 Edition "Advanced Wideband Satellite Digital Broadcasting Operational Guidelines" Summary of the Invention [Problem to be solved by the invention]

[0005] However, if a third party other than the receiver owner or broadcaster reads data recorded in 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 constitutes the data broadcasting NVRAM), the third party can obtain the information represented by that data. In other words, confidentiality of the information is not ensured. Since data recorded in NVRAM, a non-volatile storage medium, is retained unless explicitly erased, it is possible that the information could be accessed by a third party, for example, if the receiver is transferred to another person or disposed of. Considering that some data broadcasting content created by broadcasters (including content to be created in the future) will record information in the data broadcasting NVRAM that could pose a serious problem if accessed by a third party, such as personal information, it is necessary to ensure the confidentiality of the information even if the data is accessed by a third party.

[0006] The problem to be solved by the present invention is to provide a digital television broadcasting system and method for recording and collecting receiver data while ensuring confidentiality of the information. [Means for solving the problem]

[0007] According to one embodiment, there is provided a digital television broadcasting system comprising a transmitter, a server and a receiver, the transmitter has application data generating means; The application data generating means generates the following as an API command: a key acquisition command for causing the receiver to acquire an encryption key; a write command for generating encrypted data by encrypting receiver data present in the receiver with the encryption key using the encryption key, and writing the encrypted data to an information storage unit; a read command for instructing the information reading means of the receiver to read the encrypted data from the information storage unit; a transmission command to instruct the server to transmit the encrypted data that has been read; and include the generated application data in the broadcast signal, The server a means for transmitting, via the transmitter, to the receiver, the read command for reading the encrypted data from the information storage unit and the send command for sending the read encrypted data to the server; means for decrypting the received encrypted data; and The receiver includes: a receiving means (31, 32 (FIG. 5)) for receiving the broadcast signal transmitted from the transmitter, and an application execution means; The application execution means an encryption key acquisition means for acquiring the encryption key from the server based on the key acquisition command included in the broadcast signal; an encryption means for encrypting receiver data present in the receiver using the encryption key based on the write command included in the broadcast signal to generate the encrypted data; an information writing means for writing the encrypted data to the information storage unit, In the application execution means, the information writing means confirms that the API command indicates that encrypted data is to be handled and writes the encrypted data of the receiver data to the information storage unit, and if the API command indicates that encrypted data is not to be handled, writes the unencrypted data of the receiver data to the information storage unit; The digital television broadcasting system includes a means for the server to determine whether the data sent from the receiver is encrypted or not, and to decrypt the data if it is encrypted, and not to decrypt the data if it is non-encrypted. [Brief explanation of the drawings]

[0008] [Figure 1] FIG. 1 is a block diagram showing an example of the configuration of a system according to an embodiment. [Figure 2] FIG. 2 is a block diagram showing an example of the functional configuration of a transmitter of a broadcast station according to the embodiment. [Figure 3] FIG. 3 shows an example of an API command that can be written in the application data generation unit of the transmitter according to the embodiment. [Figure 4] FIG. 4 is a block diagram illustrating an example of a functional configuration of a server of a broadcast station according to an embodiment. [Figure 5] FIG. 5 is a block diagram illustrating an example of a functional configuration of a receiver according to the embodiment. [Figure 6] FIG. 6 is a diagram illustrating an example of a stored data area in the information storage unit of the receiver according to the embodiment. [Figure 7] FIG. 7 is a block diagram illustrating an example of a functional configuration of an application execution unit of the receiver according to the 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 a processing operation of the transmitter according to the embodiment. [Figure 10] FIG. 10 is a flowchart showing an example of processing operations of the receiver in the embodiment. [Figure 11] FIG. 11 is a flowchart showing an example of the processing operation of the application execution unit when an encryption key is obtained in the embodiment. [Figure 12] FIG. 12 is a flowchart showing an example of the processing operation of the server when obtaining an encryption key in this embodiment. [Figure 13] FIG. 13 is a flowchart showing an example of the processing operation of the application execution unit when writing data in this embodiment. [Figure 14]FIG. 14 is a flowchart showing an example of the processing operation of the application execution unit when reading data in this embodiment. [Figure 15] FIG. 15 is a flowchart showing an example of the processing operation of the application execution unit when transmitting data in this embodiment. [Figure 16] FIG. 16 is a flowchart showing an example of a processing operation of the server when receiving data in this embodiment. [Figure 17] FIG. 17 is a sequence chart of the system according to the second embodiment. [Figure 18] FIG. 18 is a flowchart showing an example of a processing operation of the transmitter according to the embodiment. [Figure 19] FIG. 19 is a flowchart showing an example of the processing operation of the application execution unit when an encryption key is obtained in the embodiment. [Figure 20] FIG. 20 is a sequence chart of the system according to the third embodiment. [Figure 21] FIG. 21 shows an example of a case where an encryption key is transmitted in the SI of the TS broadcast wave 4 in this embodiment. [Figure 22] FIG. 22 shows an example of transmitting an encryption key in SI of the MMT broadcast wave 4 in the same embodiment. [Figure 23] FIG. 23 is a flowchart showing an example of processing operations of the receiver in the same embodiment. [Figure 24] FIG. 24 is a flowchart showing an example of the processing operation of the application execution unit when writing data in this embodiment. [Figure 25] FIG. 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] FIG. 26 is a flowchart showing an example of the processing operation of the application execution unit when writing data in this embodiment. DETAILED DESCRIPTION OF THE INVENTION

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

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

[0011] The broadcast station 10 is a 2K broadcast station or a 4K / 8K broadcast station. When it is necessary to distinguish between a 2K broadcast station and a 4K / 8K broadcast station, they are referred to as a 2K broadcast station and a 4K / 8K broadcast station, respectively. The broadcast station 10 includes a transmitter 1 and a server 2.

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

[0013] The server 2 is, for example, a computer, and includes a communication interface for communicating with external devices and a CPU for processing data. Specifically, the server 2 exchanges various data with the receiver 3 via a network 5. The server 2 also exchanges various data with the transmitter 1 via a network 6. The transmitter 1 can transmit data obtained from the server 2 via a broadcast wave 4. Note that while only one broadcast station 10 and one receiver 3 are shown in FIG. 1, there are typically multiple broadcast stations 10 (transmitters 1, servers 2) and multiple receivers 3. In this case, the server 2 of each broadcast station can exchange data with multiple receivers 3. The transmitters 1 of each broadcast station individually output broadcast waves 4, and each receiver 3 can receive one or multiple broadcast waves 4 from multiple transmitters 1.

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

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

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

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

[0018] The transmitter 1 generates a broadcast stream (digital data stream) conforming to various digital broadcast standards from, for example, a digital broadcast signal (digital data for digital broadcasting), application data, various control information, etc. obtained from the server 2, and outputs the digital data stream via broadcast waves 4. The various digital broadcast standards may be, for example, the MPEG2 Transport Stream method (TS method), which is a transmission method for 2K broadcasting, or the MPEG Media Transport method (MMT method), which is a transmission method for 4K / 8K broadcasting.

[0019] The service data stream generator 11 generates a data stream of coded service data such as video, audio, and subtitles by encoding and packetizing the data, including source coding, in accordance with various digital broadcasting standards.

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

[0021] The application stream generator 13 generates a data stream of the application data by encoding, including source coding, and packetizing the application data 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 in the receiver 3. In this embodiment, the application data generation unit 14 generates application data including commands (hereinafter referred to as API commands) for the Application Programming Interface (API) shown in FIG. 3. The API is an interface provided to an application by an application engine, which is an execution program installed in the receiver 3, and is also referred to as a broadcast extension function (or broadcast extension object) defined in standards such as ARIB STD-B24 and ARIB STD-B62. The application in this embodiment is assumed to be a data broadcast 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 APIs. Details will be described in the description of FIG. 3. · API for acquiring and storing the encryption key used for encryption (encryption key acquisition API) · Data write API (with encryption) · Encrypted data read API (without decryption) · Data transmission API Note that in this embodiment, an example is shown in which the application data generation unit 14 is a function of the transmitter 1, but it may also be a function of the server 2. When the application data generation unit 14 is a function of the server 2, the application data generated by the application data generation unit 14 is transmitted to the transmitter 1 via the network 6.

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

[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 the multiplexed data stream as a broadcast stream.

[0025] The broadcast signal transmitting 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 output to an antenna, cable, etc. (not shown).

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

[0027] 3 shows examples of API commands that can be written by the application data generation unit 14 of the transmitter according to the embodiment, and shows, from left to right, the API No. (the number in FIG. 3), the API function, and the API command for the API function (API name, arguments, etc.) written in BML or HTML. Here, the API is an interface that an application engine, which is an execution program built into the receiver 3, provides to an application, and what the transmitter 1 writes in a BML file 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 for executing the encryption key acquisition API, and is an API command for causing the receiver 3 to acquire from the server 2 an encryption key used for encryption.

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

[0030] In the case of HTML, for example, this is an API command that calls downloadBroadcasterCertificate, which is an API defined as a method of the ReceiverDevice object specified in ARIB STD-B62. The API command is, for example, downloadBroadcasterCertificate (argument). In this embodiment, the argument includes at least information that identifies the encryption key to be acquired from the server 2 (for example, a URL such as "https: / / address of server 2 / path to encryption key file"), but may also include other content to be acquired by the receiver 3 (for example, identification information indicating the attributes of the encryption key).

[0031] The reliability of the encryption key obtained by the receiver 3 using the API command No. 1 may be guaranteed by the reliability of the hypertext transfer protocol secure (https) connection. When using the API No. 1, the receiver 3 first establishes a connection with the broadcasting station server 2 using https, and obtains the encryption key from the broadcasting station server 2 through communication over that https connection. The https connection authenticates the server 2 from the receiver 3's perspective, ensuring the reliability of the obtained encryption key.

[0032] Line No. 2 is an API command for executing the encryption key acquisition API, and is an API command for causing the receiver 3 to acquire the encryption key transmitted in the application stream being broadcast.

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

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

[0035] Line No. 3 is an API command that executes the data writing API, which causes receiver 3 to encrypt 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, this is an API command that calls writePersistentArray, an API defined in ARIB STD-B24. The API command is, for example, writePersistentArray (argument). The argument of the API command includes at least information identifying the receiver data to be written to the receiver 3 as encrypted data (receiver data identification information), information instructing the receiver 3 to write the data as encrypted data (encryption write instruction information), and information identifying the storage location to which the encrypted data is to be written (storage location identification information). For example, the receiver data identification information may be as defined in ARIB TR-B14. Furthermore, for the receiver data identification information and the storage location identification information, a URI such as "nvrame: / / ~ / <block number>" may be used instead of the URI (Uniform Resource Identifier) ​​such as "nvram: / / ~ / <block number>", which is one form of information identifying a storage location in the NVRAM for data broadcasting defined in ARIB TR-B14. Here, the meanings of ~ and <block number> are values ​​conforming to the ARIB TR-B14 standard.

[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 specified in ARIB TR-B39. The API command is, for example, setItem (argument). 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 specified in ARIB TR-B39. Furthermore, for the encrypted write instruction information and storage location identification information, for example, instead of the access key name specified in ARIB TR-B39, for example, "'_e_wlocal' + item number", "_e_wlocal0" may be used.

[0038] Line No. 4 is an API command that executes the data writing API, which causes receiver 3 to encrypt 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, this is an API command that calls writePersistentArrayEncrypted, which is an API that conforms to writePersistentArray specified in ARIB STD-B24. The API command is, for example, writePersistentArrayEncrypted (argument). The argument of the API command includes at least receiver data identification information and storage location identification information. For example, the argument may conform to the embodiment of the argument in the API command for BML in line No. 3 above, or may conform to the argument of writePersistentArray specified in ARIB TR-B14. In the latter case, the receiver 3 may recognize from "Encrypted" included in the API name that the data to be written to NVRAM needs to be encrypted, and may encrypt the write data specified in the argument before storing it in NVRAM.

[0040] In the case of HTML, for example, this is an API command that calls setItemEncrypted, an API that conforms to a method of the LocalStorage object whose operation is specified in ARIB TR-B39. The API command is, for example, setItemEncrypted(argument). The argument of the API command includes at least receiver data identification information and storage location identification information that the receiver 3 writes as encrypted data. For example, the argument may conform to the embodiment of the argument in the API command for HTML in line No. 3 above, or may conform to the argument of setItem specified in ARIB TR-B39. In the latter case, when the API No. 4 is called, the receiver 3 recognizes that the data to be written to NVRAM needs to be encrypted based on the "Encrypted" included in the API name, and encrypts the write data specified in the argument and stores it in NVRAM. In this embodiment, an example is shown in which the receiver 3 performs encrypted writing using the API Nos. 3 and 4 using the encryption key obtained using the API Nos. 1 and 2.

[0041] The NVRAM area where encrypted data is written by the API commands No. 3 and No. 4 may be a different area from the NVRAM area specified in ARIB TR-B14 and ARIB TR-B39, or it may be the same area. For example, in the BML API command No. 3, the area indicated by the URL "nvrame: / / ~ / 0" that specifies the storage location where encrypted data is written may be a different area from the area indicated by the URL "nvram: / / ~ / 0" specified in ARIB TR-B14, or it may be the same area. The same applies to the area indicated by the access key in the HTML API command No. 3. Furthermore, for example, in the BML API commands No. 3 and No. 4, i.e., writePersistentArray(argument) and writePersistentArrayEncrypted(argument), when the URL "nvram: / / ~ / 0" is specified, the area where the receiver 3 writes data when the API is called by the former API command No. 3 and the area where the receiver 3 writes encrypted data when the API is called by the latter API command No. 4 may be different areas or may be the same area. The same is true for the HTML API command No. 4.

[0042] Line No. 5 is an API command for executing the encrypted data read API, which is an API command for causing the receiver 3 to read the encrypted data from the information storage unit 36 ​​.

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

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

[0045] Line No. 6 is an API command for executing the encrypted data read API, which is an API command for causing the receiver 3 to read the encrypted data from the information storage unit 36 ​​.

[0046] In the case of BML, for example, it is an API command that calls ReadPersistentArrayEncrypted, which is an API conforming to ReadPersistentArray specified in ARIB STD-B24. The API command is, for example, ReadPersistentArrayEncrypted (argument). The argument of the API command includes at least storage location identification information of the encrypted data to be read by the receiver 3. The storage location identification information of the encrypted data to be read is, for example, ARIB It is also possible to specify the URI "nvram: / / ~ / <block number>", which is one form of information that identifies the storage location in the data broadcasting NVRAM specified in TR-B14. In this case, in an embodiment where 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 recognizes from the "Encrypted" included in the API name that it is to read from the area where encrypted data is stored, and reads the encrypted data from NVRAM.

[0047] In the case of HTML, for example, this is an API command that calls getItemEncrypted, an API conforming to the LocalStorage object whose operation is specified in ARIB TR-B39. The API command is, for example, getItemEncrypted(argument). The argument of the API command includes at least information that identifies the storage location of the encrypted data to be read by the receiver 3. For example, an access key name specified in ARIB TR-B39 may be specified as information that identifies the storage location of the encrypted data to be read. 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" included in the API name that it will read from the area where encrypted data is stored, and read the encrypted data from NVRAM.

[0048] Line No. 7 is an API command for executing the data transmission API, and is an API command for causing the receiver 3 to transmit encrypted data to the server 2 of the broadcast station.

[0049] In the case of BML, for example, this is an API command that calls transmitTextDataOverIP, an API specified in ARIB STD-B24. The API command is, for example, transmitTextDataOverIP (argument). In this embodiment, the argument of the API command includes the encrypted data read using the API command No. 4 or No. 5 and information identifying the destination. In this embodiment, the encrypted data may be text data. Note that encrypted data is generally binary data, not text data. Therefore, for example, encrypted data reversibly converted to text data using Base64 encoding may be used as the argument. The information identifying the destination may be, for example, the URL of server 2, "https: / / server2 address," with the parameter "?datatype=nvram&encrypted=yes" added. This information indicates that the receiver 3 receiving this API command is to transmit encrypted data to the server 2 of the broadcast station. More specifically, the receiver 3 requests a connection to the server 2 to transmit the encrypted data. The above parameters are transmitted during the connection request. When the server 2 receives a connection for transmission from the receiver 3, it confirms from the received parameters that the receiver 3 is attempting to transmit encrypted data.

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

[0051] In this embodiment, an example is shown in which API commands, which are instructions to the API of the receiver 3, are included in application data broadcast by a digital television data broadcasting service, but this is not limiting. For example, instructions for API functions may be included in a TS-type Signaling Information (SI) signal or the like.

[0052] FIG. 4 is a block diagram illustrating an example of a functional configuration of a server of a broadcast station according to an embodiment.

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

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

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

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

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

[0058] The key generation unit 25 generates encryption keys and encryption / decryption keys and stores them in the key storage unit 24. In this embodiment, asymmetric key cryptography is applied, with the encryption key being a public key and the encryption / decryption key being a private key. The key generation unit 25 generates a one-to-one combination of a public key and a private key. The private key is kept secret by the generator, while the public key does not need to be kept secret and may be made public to a third party. As asymmetric key cryptography and methods for generating public and private keys are common techniques, a description thereof will be omitted.

[0059] The decryption processing unit 26 decrypts the encrypted data received from the receiver 3 using the encryption / decryption key, obtains and outputs the receiver data. 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 the encryption / decryption key (private key) according to asymmetric key cryptography is a common technique, so a description thereof will be omitted. Note that in this embodiment, an example is shown in which the server 2 holds the encryption key and the encryption / decryption key, but the encryption key and the encryption / decryption key may be held by different servers. In that case, the server holding the encryption / decryption key has a function for performing processing using the encryption / decryption key. Note that in this embodiment, an example is shown in which the server 2 holds the encryption key and the encryption / decryption key, but the encryption key and the encryption / decryption key may be held by different servers. In that case, the server holding the encryption / decryption key has a function for performing 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 any data such as installation location information, owner information, viewing data, and viewing behavior data related to the receiver 3 owned by the receiver 3, and for example, the viewing data and viewing behavior data are used as analysis data for viewing analysis and the like.

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

[0062] The receiver 3 is, for example, a digital television receiver and has a function for receiving digital broadcasts, including 2K broadcasts and 4K / 8K broadcasts. The receiver 3 also has a communication interface for exchanging data with the server 2 and an external server (not shown) via the network 5. The receiver 3 also has a function for linking data obtained from digital broadcasts with data obtained from the server to realize various broadcast-communication collaboration services. The receiver 3 can also acquire and store viewing behavior data, such as the viewing history of digital broadcast programs viewed by the receiver 3, as well as information about the owner of the receiver 3. All of this data that can be stored by the receiver 3 is referred to as receiver data. The receiver 3 can store all or part of the receiver data in the information storage unit 36 ​​(NVRAM for data broadcasting). The receiver 3 can transmit the receiver data to the server 2, for example, via the network 5. The server 2 uses the received receiver data by analyzing it, etc. In this embodiment, the receiver data is encrypted and stored as encrypted data in the information storage unit 36. The encrypted data is then read from the information storage unit 36 ​​and transmitted to the server 2. The receiver 3 also has a processing function such as a CPU for realizing the above functions.

[0063] The broadcast tuner 31 receives the broadcast wave 4 from an antenna or cable, and performs decoding and demodulation on the broadcast wave 4 in accordance with the transmission path coding and modulation method of the transmitter 1 according to various digital broadcasting standards, thereby obtaining and outputting the digital data of the broadcast stream.

[0064] The broadcast stream processing unit 32 performs, for example, demultiplexing (data separation), information source encoding / decoding, etc. on the broadcast stream input from the broadcast tuner 31 in accordance with various digital broadcasting standards, and obtains and outputs service data, data broadcasting service data, application data, various control information, etc.

[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. The control unit 33 may also 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 various 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 that stores 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, an HTML browser, etc. This will be described in detail in the description of FIG.

[0068] The information storage unit 36 ​​is, for example, a non-volatile memory (NVRAM). The information storage unit 36 ​​may be a storage medium (also referred to as data broadcasting NVRAM) for data (also referred to as receiver data) handled in data broadcasting, which is one of the services provided in 2K broadcasting and 4K / 8K broadcasting. The information storage unit 36 ​​may distinguish whether the stored data is encrypted or not by the 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 data or non-encrypted data.

[0070] 6 is a diagram showing an example of a stored data area in the information storage unit of the receiver according to the embodiment. This diagram is for the purpose of explaining the data stored in the information storage unit 36, and shows logical distinctions based on the content of the data, but does not necessarily show the physical relationships in the information storage unit 36. Therefore, not all of the content shown in the diagram is necessarily stored in the information storage unit 36.

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

[0072] The address "nvram: / / b_id" shown in area 3601 indicates the location of a storage area on information accumulation unit 36 ​​(NVRAM). Specifically, b_id is the value of the broadcaster identifier of a broadcaster, and can also be represented by the symbol ~ in an application transmitted by the broadcaster to which the broadcaster identifier is assigned. Here, area 3601 itself does not have to be on NVRAM; a correspondence table linking storage locations in NVRAM with broadcasters can be stored in another memory (not shown), and receiver 3 can refer to that correspondence table when accessing NVRAM.

[0073] In this embodiment, "name," "address," and "email address" are stored in blocks (or items). Note that, although types of information such as "name," "address," and "email address" are illustrated as "information element names," they are not stored as data. In other words, the "information element names" are shown for the sake of convenience in the explanation of FIG. 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 "data body" and "registration date and time" are written in each field.

[0074] Area 3602 is field 1, and stores the data itself. For example, field 1 of block 0 stores "name."

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

[0076] Area 3604 shows the data of block 1, which is a storage area on 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 indicates data of block N, which is a storage area on information storage unit 36. The information element stored in block N is "viewing behavior data," and more detailed information is omitted since it is the same as area 3604.

[0078] Figure 6(b) shows an example of data stored in a 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 an area assigned to the broadcaster identified by the same broadcaster identifier b_id as in Figure 6(a), but indicates that it is an area on the information storage unit 36 ​​that stores encrypted data. The "data body" in field 1 in Figure 6(b) is all encrypted data (encrypted data).

[0079] Figure 6(c) shows an example of data stored in a storage area of ​​the information storage unit 36. The difference from Figure 6(a) is area 3607. In Figure 6(c), field 3 "encrypted or not" 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 based on the address shown in area 3606, but in the case of Figure 6(c), it is possible to determine whether the data is encrypted based on field 3.

[0080] 5, the receiver data storage unit 37 stores receiver data such as viewing behavior data acquired by the receiver 3 and receiver-specific information relating to the owner of the receiver 3. The receiver data storage unit 37 may be, for example, a part of the work memory used by the application execution unit 35. The work memory may be a 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 is equipped with a communication protocol applied to the network 5 (such as an IP communication method or a dedicated line method).

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

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

[0084] The interface unit 302 is a user interface between the receiver 3 and the user, and may include, for example, IR communication as an interface with a remote controller (remote control) included with the receiver 3, and USB as an interface with a mouse, keyboard, etc. for a PC. Note that there may also be cases where data, signals, etc. are exchanged with functional blocks within the receiver 3 that are not wired to the interface unit 302.

[0085] Remote control unit 303 is, for example, a remote control attached to receiver 3. For example, when a user operates remote control unit 303, remote control unit 303 outputs control data. Control unit 33 receives the output control data via interface unit 302, and control unit 33 controls functions within receiver 3, allowing the user to control receiver 3.

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

[0087] The data analysis unit 350 has a function of analyzing application data. The application data may be data written in BML or HTML, for example. The data analysis unit 350 extracts API commands from 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 results or the API commands themselves to the related functions. Specifically, the API processing unit 351 causes the related functions to execute API processing based on the API commands input from the data analysis unit 350 (API name, accompanying arguments, etc.).

[0089] The read processing unit 352 receives an execution command for reading the encrypted data from the API processing unit 351 and executes processing in accordance with the command. Specifically, the read processing unit 352 executes the processing to read the encrypted data from the information storage unit 36 ​​(NVRAM) and output it to, for example, the communication processing unit 359.

[0090] The encryption determination unit 353 receives an API command from the API processing unit 351 and determines whether the API command is related to encrypted data. Specifically, if the API name includes "encrypted" or the like, as in the case of APIs No. 4 and No. 6 in Fig. 3, or if this is indicated by an argument, as in the case of APIs No. 3 and No. 5 in Fig. 3 (for example, if "nvrame: / / ~ / <block number>" is specified as storage destination identification information), the encryption determination unit 353 recognizes that the API command is an API command that handles 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 processing in accordance with the received execution command. Specifically, the encryption key acquisition unit 354 executes processing to acquire an encryption key and to check whether an encryption key has already been acquired in the encryption key storage unit 355.

[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 well-known techniques, and therefore will not be described here.

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

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

[0096] The communication processing unit 359 has a function that enables the application execution unit 35 to communicate with a device (e.g., the server 2) external to the receiver 3 via the network 5. Specifically, the communication processing unit 359 has 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 from the communication unit 38 to the network 5.

[0097] (First embodiment) In this embodiment, an example is described in which commands included in a data broadcasting service application cause the receiver 3 to encrypt receiver data, specify a storage area for the encrypted data and write it to the information storage unit 36, and then 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 FIG. 1, the functional configuration of the transmitter 1 in FIG. 2, the functional configuration of the server 2 in FIG. 4, and the functional configuration of the receiver 3 in FIGS.

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

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

[0101] The operation of the system according to this embodiment is divided into four main phases. The operation of each device in each phase will be described below.

[0102] Phase 1 is the phase in which receiver 3 acquires the encryption key. Transmitter 1 transmits an "encryption key acquisition command" via broadcast waves 4 (step P11). Receiver 3 receives broadcast waves 4 and, upon acquiring the "encryption key acquisition command," outputs an "encryption key request" to server 2 (step P12). Upon receiving the "encryption key request," server 2 outputs the "encryption key" to receiver 3, and receiver 3 receives the "encryption key" and stores it in encryption key storage unit 355 (step P13).

[0103] Phase 2 is the phase in which receiver 3 writes encrypted data to information storage unit 36. Transmitter 1 transmits a write command (for encrypted data) over broadcast waves 4 (step P21). Receiver 3 receives broadcast waves 4 and, upon acquiring the write command (for encrypted data), encrypts the receiver data using the "encryption key" acquired in phase 1 (step P22). Receiver 3 stores the encrypted receiver data in information storage unit 36 ​​(step P23).

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

[0105] Phase 4 is the phase in which the receiver 3 transmits encrypted data to the server 2, and the server 2 acquires the receiver data. The transmitter 1 transmits a "send command (for the encrypted data)" via the broadcast waves 4 (step P41). The receiver 3 receives the broadcast waves 4 and, upon acquiring the "send command (for the encrypted data)," transmits the encrypted data to a specified device (the server 2 in this embodiment) (step P42). The 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, an example is shown in which the transmitter 1 generates a "write command," a "read command," and a "transmit command." However, it is also possible for the server 2 to generate each command, transfer it to the transmitter 1 via the network 6, and have the transmitter 1 transmit each command via the broadcast wave 4.

[0107] Below, examples of the operations of the transmitter 1, server 2, and receiver 3 in each phase will be explained using the respective flowcharts.

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

[0109] The application data generation unit 14 of the transmitter 1 generates application data including API commands for causing the receiver 3 to execute the processes of all of the above phases in order (step S11). Specific examples of application data are shown below: <When the application data is a BML file> {downloadBroadcasterCertificate(argument 1) writePersistentArray(argument 2, argument 3) readPersistentArray(argument 2) transmitTextDataOverIP(argument 4, argument 5)} <When 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 files 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, and may be, for example, "https: / / address of server 2?datatype=nvram&encrypted=yes" when sending encrypted data to server 2 of a broadcasting station. Argument 5 is information that indicates the encrypted data that is read by the API command for each file, i.e., readPersistentArray(argument 2) or getItem(argument 2), and may be, for example, a variable or object that indicates the storage location of the encrypted data that is read. The broadcast stream generating unit 16 multiplexes the generated application data (BML file or HTML file) with the data streams output by the service data stream generating unit 11 and the control information generating unit 12, and outputs the multiplexed data as a broadcast stream (step S12).

[0110] When the digital data of the broadcast stream is input, the broadcast signal transmitter 17 performs transmission path coding and modulation according to various digital broadcasting standards to generate and output the broadcast wave 4 (step S13). The broadcast wave 4 is output from an antenna, cable, etc. (not shown).

[0111] FIG. 10 is a flowchart showing an example of processing operations of the receiver in the embodiment.

[0112] For example, suppose a user changes a channel 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 accordance with 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 from the data obtained by the broadcast stream processing unit 32 is output to the control unit 33, the control unit 33 analyzes the application control information (step S33). When the control unit 33 analyzes the application control information and detects an "application execution command," the control unit 33 activates the application execution unit 35 (step S34). Meanwhile, the application data from the data obtained from the broadcast stream processing unit 32 is temporarily stored in the application data storage unit 34 (step S35). When the application execution unit 35 is started, the data analysis unit 350 acquires application data from the application storage unit 34 and analyzes the application data (step S36). The data analysis unit 350 analyzes the application data and outputs the extracted API command to the API processing unit 351. The API processing unit 351 interprets the API command and executes the API function (step S37).

[0113] 11 is a flowchart showing an example of the processing operation of the application execution unit when acquiring an encryption key in this embodiment, and corresponds to the processing operation in phase 1. This diagram corresponds to details of step S37 in the flowchart in FIG.

[0114] The API processing unit 351 receives the API command shown in the row No. 1 in FIG. 3 and recognizes the API command (step S311). Regarding the API of each function, although the API command differs between 2K broadcasting (TS format) and 4K8K format (MMT format), there is no particular difference in the processing of the API command and the processing by the API. Therefore, unless otherwise specified, the following description of the embodiment is applicable to both 2K broadcasting (TS format) and 4K8K format (MMT format). Whether the broadcast wave 4 received by the receiver 3 is 2K broadcasting (TS format) or 4K8K format (MMT format) is determined in step S32 of FIG. 10. The API processing unit 351 recognizes that the received API command is an API command requesting an encryption key from the server 2 and causes the encryption key acquisition unit 354 to execute encryption key acquisition processing. The encryption key acquisition unit 354 requests the 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 transmits 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 transmitted from the server 2, the encryption key acquisition unit 354 receives the encryption key via the communication unit 38 and the communication processing unit 359, and stores the encryption key in the encryption key storage unit 355 (step S313).

[0115] FIG. 12 is a flowchart showing an example of the processing operation of the server when obtaining an encryption key in this embodiment.

[0116] In the server 2, the key generation unit 25 generates an encryption key and an encryption / decryption key and stores them in the key storage unit 24 (step S211). The key generation unit 25 may generate the encryption key and the encryption / decryption key when it receives an encryption key request message from the receiver 3, or may generate them at any time regardless of whether or not it receives an encryption key request message from the receiver 3, and store them in the key storage unit 24. The application data processing unit 22 receives the message via the communication unit 21, and upon recognizing that it is an encryption key request message, outputs the encryption key request message to the encryption key request processing unit 23 (step S212). The encryption key request processing unit 23 obtains the encryption key from the key storage unit 24 based on the received encryption key request message (step S213). The encryption key request processing unit 23 transmits the encryption key to the receiver 3, for example, via https communication (step S214). Through the above procedure, the receiver 3 can obtain the encryption key owned by the server 2.

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

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

[0119] When the API command handles encrypted data, API processing unit 351 causes encryption processing unit 356 to execute processing based on the API command, and encryption processing unit 356 recognizes the receiver data to be encrypted from receiver data identification information specified by an argument or the like of the API command, and encrypts the specified receiver data (unencrypted data) (Yes in step S322, step S323). More specifically, upon receiving a command to execute processing from API processing unit 351, encryption processing unit 356 acquires receiver data, for example, from receiver data storage unit 37 (or information accumulation unit 36 ​​in some cases), encrypts the acquired receiver data using the encryption key stored in encryption key storage unit 355, and outputs the encrypted data to write processing unit 358. Write processing unit 358 stores the encrypted data in a storage area for encrypted data in information accumulation 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 encrypting it (No in step S322, step S325).

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

[0121] The API processing unit 351 receives the API command shown on line No. 5 or No. 6 in FIG. 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 argument or the like (step S332). In this embodiment, for example, if the API command name is "readPersistentArrayEncrypted", it may be determined that the API command handles encrypted data, and if the API command name is "readPersistentArray", it may be determined that the API command does not handle encrypted data. Alternatively, if the argument of the API command is "nvrame: / / ~ / <block number>", it may be determined that the API command handles encrypted data, and if the argument of the API command is "nvram: / / ~ / <block number>", it may be determined that the API command does not handle encrypted data. If the API command handles encrypted data, the read processing unit 352 retrieves the encrypted data from the storage area for encrypted data in 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 storage area for unencrypted data in the information storage unit 36 ​​and outputs it to the communication processing unit 359 (step S334). In an embodiment in which the storage area for encrypted data and the storage area for unencrypted data are not distinguished, the read processing unit 352 may retrieve the data from the information storage unit 36 ​​and output it to the communication processing unit 359 without determining whether the API command handles encrypted data (step S332). The communication processing unit 359 may store the encrypted data in, for example, a memory or buffer (not shown).

[0122] 15 is a flowchart showing an example of the processing operation of the application execution unit when transmitting data in this embodiment, and corresponds to the processing operation in phase 4. This diagram corresponds to details of step S37 in the flowchart in FIG.

[0123] The API processing unit 351 receives the API command shown on line 7 of FIG. 3 and recognizes the API command (step S341). The API processing unit 351 causes the communication processing unit 359 to execute processing based on the recognized API command. Specifically, the communication processing unit 359 converts data specified in the API command into data to be transmitted via https communication (hereinafter referred to as https transmission data) (step S342). The https transmission data is transmitted from the communication unit 38 via the network 5 to the server 2 identified by the URL specified in the API command (step S343). Note that the communication processing unit 359 may transmit the encrypted data read from the information storage unit 36 ​​in phase 3 regardless of the argument of the API command on line 7 of FIG. 3 by continuously executing the API function corresponding to the API command on line 5 or 6 of FIG. 3, which is phase 3.

[0124] FIG. 16 is a flowchart showing an example of a processing operation of the server when receiving data in this embodiment.

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

[0126] Through the above procedure, the API commands included in the application for the data broadcasting service can be used to cause the receiver 3 to encrypt the receiver data and write it to the information storage unit 36 ​​(NVRAM). Furthermore, the API commands included in the application for the data broadcasting service can be used to cause the 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 the receiver 3 and obtain the receiver data by decrypting the encrypted receiver data.

[0127] In this embodiment, asymmetric key cryptography is used to encrypt data stored in the information storage unit 36, so that the encrypted data stored in the information storage unit 36 ​​can be decrypted only with an encryption / decryption key possessed by the server 2. This allows the server 2 to collect receiver data while ensuring confidentiality (or confidentiality in information security technology). Note that symmetric key cryptography can also be used as the encryption technology for data. However, when symmetric key cryptography is used, a common key is used to encrypt the data. The common key is required for encrypting and decrypting the encrypted data. If symmetric key cryptography is applied in this embodiment, the receiver 3, which encrypts the data, and the server 2, which decrypts the encrypted data, share the same common key. Therefore, when symmetric key cryptography is applied, the receiver 3 also possesses a key capable of decrypting the encrypted data. If a third party other than the owner of receiver 3 or the broadcaster who manages server 2 reads the encrypted data from information storage unit 36 ​​by some means (for example, by connecting a reading device to the semiconductor memory that constitutes the data broadcasting NVRAM and reading the data), and also retrieves the common key held by receiver 3, the third party can decrypt the encrypted data and obtain the receiver data, leaving the problem of ensuring the confidentiality of information unresolved. Asymmetric key cryptography uses a public key that can be made public and that may be known to third parties as the encryption key, eliminating the need to share the decryption key, and is therefore very effective in ensuring the confidentiality of information in a system such as this embodiment. In this embodiment, the above problem is solved by applying asymmetric key cryptography.

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

[0129] The system configuration of this embodiment will be described with reference to FIG. 1, the functional configuration of the transmitter 1 with reference to FIG. 2, the functional configuration of the server 2 with reference to FIG. 4, and the functional configuration of the receiver 3 with reference to FIGS.

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

[0131] FIG. 17 is a sequence chart of the system according to the second embodiment, showing an example of the operation of the system in the phase in which the receiver 3 acquires 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 the transmitter 1 via the network 6 (step P121). The transmitter 1 transmits the encryption key via the broadcast waves 4 (step P122). Here, the transmitter 1 stores the encryption key within the application data and transmits it via the broadcast waves 4. Separately from transmitting the encryption key, the transmitter 1 transmits an "encryption key acquisition command" via the broadcast waves 4 (step P123). The receiver 3 receives and analyzes the broadcast waves 4 (step P124). If the receiver 3 detects the "encryption key acquisition command" as a result of the analysis, it further analyzes the broadcast waves 4 and acquires the encryption key within the application data (step P125).

[0133] FIG. 18 is a flowchart showing an example of a processing operation of the transmitter according to the 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 over the broadcast wave 4 (step S1201). Specifically, the encryption key transmission data may be stored as a resource (file) constituting an application, which is a storage location on the broadcast wave 4 according to the type of broadcast wave 4 (conforming to ARIB STD-B24, ARIB STD-B62, etc.) as shown below. <If the broadcast wave 4 is in the TS format> arib-dc: / / encryption key resource name<If the broadcast wave 4 is in the MMT format> arib-dc2: / / encryption key resource name Furthermore, independently of (in parallel with) step S1201, application data is generated including an API command as shown below to cause the 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)} Regarding argument 1 and argument 2, for example, argument 1 for a BML file is "arib-dc: / / encryption key resource name", and argument 2 for an HTML file is "arib-dc2: / / encryption key resource name".

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

[0136] When the digital data of the broadcast stream is input, the broadcast signal transmitting unit 17 performs transmission path coding and modulation according to various digital broadcasting standards to generate and output the broadcast wave 4 (step S1204). The broadcast wave 4 is output from an antenna, cable, etc. (not shown).

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

[0138] The API processing unit 351 of the receiver 3 receives the API command shown on line No. 2 in FIG. 3 and recognizes the API command (step S3201). When the API processing unit 351 recognizes from the argument 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 analyzes the broadcast wave 4 (step S3202). Specifically, the control unit 33 identifies the encryption key from the data of the data broadcasting service output by the broadcast stream processing unit 32, based on the storage location of the encryption key data specified as the 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] Through the above procedure, the receiver 3 can obtain the encryption key transmitted in the broadcast wave 4 by using a command included in the application of the data broadcasting service.

[0140] (Third embodiment) In this embodiment, an example will be described in which the receiver 3 is caused to acquire an encryption key included in a broadcast signal. In this embodiment, an example will be described in which the encryption key is acquired from signaling information (SI) transmitted separately from application data via the same broadcast wave 4.

[0141] The system configuration of this embodiment will be described with reference to FIG. 1, the functional configuration of the transmitter 1 with reference to FIG. 2, the functional configuration of the server 2 with reference to FIG. 4, and the functional configuration of the receiver 3 with reference to FIGS.

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

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

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

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

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

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

[0148] The transmitter 1 transmits the encryption key as control information (e.g., SI) in the control information generation unit 12, for example. Furthermore, the application data generation unit 14 of the transmitter 1 generates application data including the API command in line No. 3 of FIG. 3 as follows, independent of the transmission of the encryption key: <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)} where argument 1 may be "nvrame: / / ~ / <block number>" and argument 3 may be "_e_wlocal+item number". Furthermore, arguments 2 and 4 may be receiver data identification information. The above API commands are the same as those used in the first embodiment, so a description thereof will be omitted.

[0149] FIG. 23 is a flowchart showing an example of processing operations of the receiver in the same embodiment.

[0150] The operations from steps S3301 to S3306 are similar to steps S31 to S37 of the first embodiment in Fig. 10, and therefore will not be described here. In this embodiment, steps S3307 to S3309 are added, unlike the operation example of the first embodiment. The flowchart in Fig. 23 shows that after step S3302, S3303, S3304, and S3307 operate 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 SI including the encryption key (step S3307). The control unit 33 further 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] FIG. 24 is a flowchart showing an example of the processing operation of the application execution unit when writing data in this embodiment, and corresponds to details of step S3310 in the flowchart of FIG.

[0153] The API processing unit 351 receives the API command shown on the line No. 3 in FIG. 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, its arguments, etc. (step S3322). In this embodiment, since the arguments of the API command include "nvrame:", the encryption determination unit 353 determines that the API command is an API command that handles encrypted data. Based on this determination, the API processing unit 351 causes the encryption key acquisition unit 354 to check whether the necessary encryption key is stored in the encryption key storage unit 355 (step S3323). If the necessary encryption key is stored in the encryption key storage unit 355, the encryption key acquisition unit 354 acquires the encryption key from the encryption key storage unit 355 and inputs it to the encryption processing unit 356 (steps S3323: Yes, S3324). The encryption processing unit 356 encrypts the receiver data (unencrypted data) specified by the receiver data identification information of the argument of the API command, etc., with the encryption key obtained in the previous step to generate 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 a storage area for encrypted data in the information storage unit 36 ​​(e.g., nvrame: / / ~ / <block number>) (step S3326). If the encryption determination unit 353 determines that the API command does not handle encrypted data, the API processing unit 351 stores the specified data in the information storage unit 36 ​​without encrypting it (No in steps S3322, S3327). If the required encryption key is not stored in the encryption key storage unit 355, the encryption key acquisition unit 354 ends the process without encrypting the specified receiver data (No in step S3323). Alternatively, the process may be repeated from step S3323 after waiting for a while.

[0154] By following the above procedure, the receiver 3 can obtain the encryption key from the SI transmitted in the same broadcast wave 4 separately from the application data in the broadcast wave 4, and can cause the receiver 3 to encrypt the receiver data and write the encrypted data to the information storage unit 36 ​​(NVRAM) using a command included in the application of the data broadcasting service.

[0155] In the second embodiment, an example in which an encryption key is transmitted as part of application data in the broadcast waves 4 has been described, and in the third embodiment, an example in which an encryption key is transmitted as SI in the broadcast waves 4 has been described. However, for example, it is also possible to transmit the encryption key as SI in the second embodiment or to transmit the encryption key as part of an application in the third embodiment. Specifically, in the former embodiment, an API command for acquiring the encryption key may be configured to set, for example, an empty string as information identifying the storage location of the encryption key in the broadcast waves 4, and when the control unit 33 confirms that an empty string has been specified as the information identifying the storage location of the encryption key, it may acquire the encryption key from the SI in the broadcast waves 4 and output the acquired encryption key to the API processing unit 351. In the latter embodiment, the encryption key may be stored as a predetermined resource of the application data. As described above, the transmitting side (transmitter 1) can transmit the key by transmitting it as part of application data or by transmitting it as SI. Furthermore, the receiving side (receiver 3) can receive the key by using an API or by the receiver in the background without using an API. There are no particular restrictions on the combination of the key transmission method and the key reception method, and any combination is possible.

[0156] (Fourth embodiment) In this embodiment, an example will be described in which a command included in a data broadcasting service application causes the receiver 3 to write encrypted data to the information storage unit 36 ​​(NVRAM) without specifying an encryption area, and then read out the written data. In this embodiment, the API name of the API command contains a word that indicates that it handles encrypted data, so that the receiver 3 recognizes that the API command handles encrypted data.

[0157] The system configuration of this embodiment will be described with reference to FIG. 1, the functional configuration of the transmitter 1 with reference to FIG. 2, the functional configuration of the server 2 with reference to FIG. 4, and the functional configuration of the receiver 3 with reference to FIGS.

[0158] An example of the operation of the system according to this embodiment will be described below. In this embodiment, it is assumed that the encryption key is stored in the encryption key storage unit 355. The example of the operation of the transmitter 1, server 2, and receiver 3 will be described using the flowchart used in the first embodiment. The description of the same parts as in the example of the operation in the first embodiment will be omitted.

[0159] An example of the operation of the transmitter 1 will be described below with reference to the flowchart of FIG.

[0160] The application data generation unit 14 generates application data as shown below, including the API commands in lines No. 4, No. 6, and No. 7 in Fig. 3, to cause the receiver 3 to write, read, and transmit encrypted receiver data (step S11 in Fig. 9). <If the application data is a BML file> {writePersistentArrayEncrypted(argument 1, argument 2) ReadPersistentArrayEncrypted(argument 1) transmitTextDataOverIP(argument 3, argument 4)} <If the application data is an HTML file> {setItemEncrypted(argument 1, argument 2) getItemEncrypted(argument 1) putItem(argument 3, argument 4)} Note that argument 1 may be "nvram: / / ~ / <block number>" for a BML file, or "_wlocal+item number" for an HTML file. 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), and may be, for example, a variable or object indicating the storage destination of the encrypted data to be read. Argument 4 is information identifying the destination, and may be, for example, "https: / / server2address?datatype=nvram&encrypted=yes" when transmitting encrypted data to server 2 of a broadcasting station. Unlike the arguments in the first embodiment, in this embodiment, argument 1 indicating the data write destination is "nvram:". Furthermore, for the data transmission API command (API on line No. 7 in FIG. 3), if an API command for executing the encrypted data read API and an API command for executing the data transmission API are written consecutively as described above, the data transmission API may transmit the data read by the encrypted data read API even if argument 2 is not specified.

[0161] The broadcast stream generating 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 transmitting unit 17 outputs the broadcast stream as a broadcast wave 4 (steps S12, S13).

[0162] Next, an example of the operation of the receiver 3 when writing data will be described with reference to FIGS. 10 and 13 shown in the description of the first embodiment.

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

[0164] FIG. 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 details of step S324 in FIG.

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

[0166] FIG. 6(c) shows an example of data stored in the storage area of ​​the information storage unit 36, with an area 3607, a field for "encryption / non-encryption," added to FIG. 6(a). The encryption identification information may be, for example, 1-bit data, where 0 indicates unencrypted data and 1 indicates encrypted data. In this embodiment, an example is shown in which "data" is encrypted for each block, and 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 FIG. 6(b). In this embodiment, however, the area for storing encrypted receiver data is specified as "nvram: / / ~." Therefore, in this example, encrypted and unencrypted receiver data may be stored together. In this embodiment, adding area 3607 of FIG. 6(c) makes it possible to distinguish between encrypted and unencrypted receiver data. Note that instead of storing encryption identification information in area 3607, a correspondence table between blocks in the information storage unit 36 ​​and encryption identification information may be created and stored in a separate memory or the like.

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

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

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

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

[0171] The API processing unit 351 receives the API command shown on line 6 in FIG. 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, its arguments, etc. (step S3432). In this embodiment, since the API name includes "Encrypted," the encryption determination unit 353 determines that the API command is an API command that handles encrypted data. The API processing unit 351 then causes the read processing unit 352 to execute processing based on the API command, and the read processing unit 352 reads the encrypted data. If the encryption identification information (area 3607 in FIG. 6(c)) for the "information element" specified to be read in the receiver data identification information, which is an argument of the API command, is 1, the read processing unit 352 reads data of the "information element" specified to be read and outputs the data to the communication processing unit 359 (steps S3433: Yes, S3434). If the encryption identification information for the "information element" specified to be read is 0, the read processing unit 352 cancels reading of the "information element" specified to be read (No in step S3433, S3435). On the other hand, if the encryption determination unit 353 does not determine that the API command handles encrypted data, the API processing unit 351 causes the read processing unit 352 to perform a read process of unencrypted data. If the encryption identification information (area 3607 in FIG. 6(c)) for the "information element" specified to be read is 0, the read 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 to be read is 1, the read processing unit 352 cancels reading of the "information element" specified to be read (No in step S3433, S3435). When the data read by the read processing unit 352 is input to the communication processing unit 359, the data may be stored in a memory, a buffer, or the like (not shown), for example.In this embodiment, an API command for executing a data transmission API is written immediately after an API command for executing an encrypted data reading API, so 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 the above procedure, encrypted data can be read from the information storage unit 36 ​​(NVRAM for data broadcasting) without specifying an area for the encrypted data. If there is a correspondence table between blocks in the information storage unit 36 ​​and 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 data and unencrypted data are mixed in the information storage unit 36, which does not specify an area for the encrypted data, both the encrypted data and the unencrypted data can be selected and read.

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

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

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

[0176] The essential features of the receiver in the system described above can also be described as follows: (1) A receiver including application execution means (application execution unit 35) for executing application data of a data broadcasting service included in a broadcast signal, information writing means (write processing unit 358) for writing information instructed by the application data, and information storage means (information storage unit 36) for storing the information instructed by the application data, wherein the receiver further includes encryption means (encryption processing unit 356) for encrypting the information instructed by the application data, and encryption key storage means (encryption key storage unit 355) for storing an encryption key used by the encryption means, and wherein the information is encrypted by the encryption means before being written to the information storage means. (2) The receiver described in (1) further includes information reading means (read processing unit 352) for reading encrypted information from the information storage means in response to an instruction from the application data, and wherein the read information is output to an external device (server 2) without being decrypted. (3) The receiver described in (1) or (2) wherein the encryption key is a public key of a public key cryptosystem. (4) The receiver according to any one of (1) to (3), further comprising: encryption key storage instruction means for storing an encryption key in the encryption key storage means in accordance with an instruction included in the application data. (5) The receiver according to (4), further comprising: encryption key storage instruction means for storing an encryption key in the encryption key storage means in accordance with an instruction included in the application data. (6) The receiver according to (4), further comprising: encryption key storage instruction means for storing an encryption key in the encryption key storage means in accordance with an instruction included in the application data. (7) The receiver according to any one of (1) to (3), further comprising: encryption key separation means (control unit 33) for extracting the encryption key from a portion of the broadcast signal excluding the application data and storing the encryption key in the encryption key storage means. (8) The receiver according to any one of (1) to (7), further comprising: APIs provided by the application execution means for being called from a data application.(9) The receiver according to any one of (4) to (6), wherein the encryption key storage instruction means is an API provided by the application execution means and called from a data application.

[0177] The key points of the transmitter in the above system can also be described as follows: (A1) A digital television broadcast transmitter, an encryption key storage unit that acquires an encryption key from a server that has the encryption key and stores the encryption key; A transmitter comprising a broadcast signal transmitting means for transmitting a write command to the digital television broadcast receiver to cause the receiver data stored in the receiver to be encrypted with the encryption key and for causing the encrypted data to be written to an internal information storage means of the receiver, and the encryption key included in a broadcast signal. (A2) (A3) The transmitter according to (A1), wherein the encryption key is a public key of a public key cryptosystem. (A4) The transmitter according to any one of (A1) and (A2), comprising a write command sending means for sending a write command. The transmitter according to any one of (A1) to (A3), wherein the write command includes identification information of the receiver data to be written and data storage identification information indicating a storage destination of encrypted data generated by encrypting the receiver data. (A5) The receiver according to (A4), wherein the data storage identification information is encrypted write instruction information for encrypting and generating the receiver data. (A6) The receiver according to (A4), wherein the name of the write command includes discrimination information for discriminating that the receiver data to be written is the encrypted data. (A7) (A8) The transmitter according to any one of (A1) to (A6), wherein the write command is included in application data broadcasted in a data broadcasting service of the digital television broadcasting, and the application data is included in the broadcast signal. The transmitter according to (A7), wherein the write command is a command for an API incorporated in the receiver.

[0178] The main points of the present system described above can also be described as follows: (B1) In a digital television broadcasting system having a transmitter, a server, and a receiver, The sender and the server share an encryption key; the transmitter acquires an encryption key from a server having the encryption key, and an encryption key storage unit stores the encryption key; a write command for causing the receiver of the digital television broadcast to encrypt receiver data stored in the receiver with the encryption key and write the encrypted data to an information storage means within the receiver, and a broadcast signal transmitting means for transmitting the encryption key included in a broadcast signal; 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 broadcast signal; an encryption means for encrypting receiver data stored in the receiver using the encryption key based on a write command included in the broadcast signal to generate encrypted data; A system comprising an information writing means for writing the encrypted data to an information storage unit. (B2) (B3) The system according to (B1), wherein the encryption key is a public key of a public key cryptosystem. (B4) The system according to either one of (B1) or (B2), wherein the write command is included in application data broadcasted by a data broadcasting service of the digital television broadcasting, and the application data is included in the broadcast signal. (B5) The system according to any one of (B1) to (B3), wherein the encryption key is included in the application data. The system according to any one of (B1) to (B3), wherein the encryption key is included in a portion of the broadcast signal excluding the application data.

[0179] Although several embodiments of the present invention have been described, these embodiments are presented as examples and are not intended to limit the scope of the invention. These novel embodiments can be embodied 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 modifications are within the scope and spirit of the invention, and are also included in the scope of the invention and its equivalents as set forth in the claims. Furthermore, the scope of the present invention also includes cases in which each component of the claims is expressed separately, as a combination of multiple components, or as a combination of these components. Furthermore, multiple embodiments may be combined, and examples composed of such combinations are also within the scope of the invention.

[0180] In addition, to clarify the explanation, the drawings may show the width, thickness, shape, etc. of each part more schematically than in the actual state. In the functional block diagrams in the drawings, functional components necessary for explanation are represented by blocks, and general functional components may be omitted. Furthermore, the blocks representing functions are conceptual and do not necessarily have 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. Functional or physical distribution and integration may be configured depending on the usage situation of each functional block. In the block diagram, data and signals may be exchanged between unconnected blocks or in directions not indicated by arrows even if connected. Each function shown in the block diagram and the processes shown in the flowcharts and sequence charts may be realized by hardware (e.g., IC chips), software (e.g., programs), digital signal processing chips (Digital Signal Processors, DSPs), or a combination of these hardware and software. The present invention also applies to the device or method of the present invention when the claims are expressed as control logic, a program including instructions for causing a computer to execute the program, or a computer-readable recording medium containing the instructions. Furthermore, the names and terms used are not intended to be limiting, and other expressions that have substantially the same content and intent are also included in the present invention. [Explanation of symbols]

[0181] 1...transmitter, 2...server, 3...receiver, 4...broadcast wave, 5...network, 6...network, 10...broadcast 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 accumulation 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 application data generating means; The application data generating means generates the following API command: a key acquisition command for causing the receiver to acquire an encryption key; a write command for generating encrypted data by encrypting receiver data present in the receiver with the encryption key using the encryption key, and writing the encrypted data to an information storage unit; a read command for instructing the information reading means of the receiver to read the encrypted data from the information storage unit; a transmission command to instruct the server to transmit the encrypted data that has been read; and include the generated application data in the broadcast signal, The server a means for transmitting, via the transmitter, to the receiver, the read command for reading the encrypted data from the information storage unit and the send command for sending the read encrypted data to the server; means for decrypting the received encrypted data; and The receiver includes: a receiving means (31, 32 (FIG. 5)) for receiving the broadcast signal transmitted from the transmitter, and an application execution means; The application execution means an encryption key acquisition means for acquiring the encryption key from the server based on the key acquisition command included in the broadcast signal; an encryption means for encrypting receiver data present in the receiver using the encryption key based on the write command included in the broadcast signal to generate the encrypted data; an information writing means for writing the encrypted data to the information storage unit, In the application execution means, the information writing means confirms that the API command indicates that encrypted data is to be handled and writes the encrypted data of the receiver data to the information storage unit, and if the API command indicates that encrypted data is not to be handled, writes the unencrypted data of the receiver data to the information storage unit; The server includes a means for determining whether the data sent from the receiver is encrypted or not, and for decrypting the data if it is encrypted, and for not decrypting the data if it is not encrypted.

2. A digital television broadcasting method comprising a transmitter, a server, and a receiver, The application data generating means included in the transmitter As an API command, a key acquisition command for causing the receiver to acquire an encryption key; a write command for generating encrypted data by encrypting receiver data present in the receiver with the encryption key using the encryption key, and writing the encrypted data to an information storage unit; a read command for instructing the information reading means of the receiver to read the encrypted data from the information storage unit; a transmission command to instruct the server to transmit the encrypted data that has been read; and include it in the broadcast signal, The server: the receiver transmits, via the transmitter, the read command for reading the encrypted data from the information storage unit and the send command for sending the read encrypted data to the server; Decrypting the received encrypted data; The receiver, receiving the broadcast signal transmitted from the transmitter; The application execution means is acquires the encryption key from the server based on the key acquisition command included in the broadcast signal; encrypting receiver data present in the receiver using the encryption key based on the write command included in the broadcast signal to generate the encrypted data; writing the encrypted data into the information storage unit; The server determines whether the data sent from the receiver is encrypted or not, and if the data is encrypted, decrypts it, and if the data is not encrypted, does not decrypt it. Digital television broadcasting method.

Images