Digital television broadcasting system and method

Abstract

To collect receiver data while ensuring confidentiality.SOLUTION: A receiver for digital television broadcasting according to one embodiment includes: broadcasting signal reception means that receives a broadcasting signal; encryption key acquisition means that obtains an encryption key from the broadcasting signal; encryption means that generates data with encryption by encrypting receiver data in the receiver using the encryption key on the basis of a write instruction included in the broadcasting signal; and information writing means that writes the data with encryption to an information storage unit.SELECTED DRAWING: Figure 20

Description

[Technical field]

[0001] The embodiments relate to a digital television broadcasting system and method. [Background technology]

[0002] Receivers (hereinafter simply referred to as receivers) compatible with BS 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 NVRAM (Non-Volatile Memory), which is a rewritable storage medium that retains its contents even when the power is turned off (i.e., non-volatile). NVRAM is used as a storage medium (also referred to as data broadcasting NVRAM) for data (also referred to as receiver data) handled in data broadcasting, one of the services provided in 2K broadcasting and 4K / 8K broadcasting. Data broadcasting NVRAM is created and transmitted by broadcasting companies and can be accessed from data broadcasting contents executed on the receiver, but access control technology is provided to keep data recorded in data broadcasting NVRAM by a broadcasting company secret from other broadcasting companies, such as by determining the accessible area for each broadcasting company. [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 operation regulations" Summary of the Invention [Problem to be solved by the invention]

[0005] However, if a third party other than the owner of the receiver or the broadcasting company reads the data recorded in the NVRAM for data broadcasting using a method other than accessing it from the data broadcasting content (for example, a method of connecting a reading device to the semiconductor memory that is the actual substance of the NVRAM for data broadcasting and reading it) the third party can obtain the information represented by the data. In other words, the confidentiality of the information is not ensured. Since the data recorded in the NVRAM, which is a non-volatile storage medium, is retained unless it is explicitly erased, for example, if the receiver is transferred to another person or discarded, there is a possibility that the information may be extracted by a third party. Considering that some data broadcasting contents created by broadcasting companies (including those to be created in the future) record information such as personal information in the NVRAM for data broadcasting that may become a serious problem if extracted by a third party, it is necessary to ensure the confidentiality of the information even if the data is extracted 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 receiver, a server and a transmitter, The receiver includes: a receiving means for receiving a broadcast signal transmitted from the transmitter; an information reading means for reading encrypted data obtained by encrypting receiver data stored in the receiver with an encryption key from an information storage unit based on a read command included in the broadcast signal; an information transmitting means for transmitting the encrypted data to an external device based on a transmission command included in the broadcast signal; The transmitter includes: a means for including in the broadcast signal the read command for instructing the information read means of the receiver to read the encrypted data from the information storage unit, and the transmission command for instructing the information read means of the receiver to transmit the read encrypted data to the external device, The server, means for decrypting the received encrypted data; A digital television broadcasting system is provided, comprising: means for transmitting the read command and the transmission command to the transmitter. [Brief description 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. [Diagram 2] FIG. 2 is a block diagram showing an example of a functional configuration of a transmitter of a broadcast station according to the embodiment. [Diagram 3] FIG. 3 shows an example of an API command that can be described in the application data generating 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. [Diagram 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 showing an example of a stored data area of ​​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 a processing operation of the receiver in the embodiment. [Figure 11]FIG. 11 is a flowchart showing an example of a 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 a processing operation of the server when obtaining an encryption key in the embodiment. [Figure 13] FIG. 13 is a flowchart showing an example of a processing operation of the application execution unit when writing data in this embodiment. [Figure 14] FIG. 14 is a flowchart showing an example of a processing operation of the application execution unit when reading data in the embodiment. [Figure 15] FIG. 15 is a flowchart showing an example of a processing operation of the application execution unit when transmitting data in the 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 a 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 a case where an encryption key is transmitted using SI of the broadcast wave 4 of the MMT method in the same embodiment. [Diagram 23] FIG. 23 is a flowchart showing an example of a processing operation of the receiver in the 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. [Diagram 25] FIG. 25 is a flowchart showing an example of a 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 PREFERRED EMBODIMENTS

[0009] Hereinafter, an embodiment 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 or 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 and various control information onto broadcast waves such as 2K broadcast or 4K / 8K broadcast, and outputs the broadcast waves from an antenna, cable, or the like.

[0013] The server 2 is, for example, a computer, and includes a communication interface for communicating with an external device, a CPU for processing data, and the like. 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 by broadcast waves 4. Although only one broadcast station 10 and one receiver 3 are shown in FIG. 1, there are usually multiple broadcast stations 10 (transmitters 1, servers 2) and 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 also output broadcast waves 4 individually, 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, and may be output from an antenna or transmitted by 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 in the broadcasting station, and may be, for example, a telecommunication 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 a 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 broadcast), 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 encoded service data such as video, audio, and subtitles by encoding, including source encoding, and packetizing 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 encoding, 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 generating unit 14 generates data of an application to be executed in the receiver 3. In this embodiment, the application data generating unit 14 generates application data including a command (hereinafter referred to as an API command) for an 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 built into the receiver 3, and is also called a broadcast extension function (or a 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 broadcast) and a data broadcast content (in the case of 2K broadcast). Specifically, a file written in Broadcast Markup Language (BML) or HyperText Markup Language (HTML) (referred to as a BML file and an HTML file, respectively) is transmitted, and in this embodiment, these files include an API command for executing the following API. Details will be described in the description of FIG. 3. ·API for acquiring and storing an encryption key used for encryption (encryption key acquisition API) ·Data writing API (with encryption) ·Encrypted data reading API (without decryption) ·Data transmission API Note that, although an example is shown in this embodiment in which the application data generation unit 14 is a function of the transmitter 1, 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 generator 16 includes, for example, a multiplexer, and multiplexes the data streams output by the service data stream generator 11, the control information generator 12, and the application stream generator 13 in accordance with various digital broadcasting standards, and outputs the result as a broadcast stream.

[0025] The broadcast signal transmitting unit 17 performs encoding, modulation, etc., including transmission line coding in accordance with various digital broadcasting standards, on the digital data of the broadcast stream, generates a broadcast wave 4, and outputs it 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) that is applied to the network 6.

[0027] 3 shows an example 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, in each column an ​​API No. (the number in FIG. 3), an API function, and an 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 an 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, it 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 contents to be acquired by the receiver 3 (for example, identification information indicating the attributes of the encryption key, etc.).

[0030] In the case of HTML, for example, it is an API command that calls downloadBroadcasterCertificate, which is an API defined as a method of a 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 contents to be acquired by the receiver 3 (for example, identification information indicating the attributes of the encryption key, etc.).

[0031] The reliability of the encryption key acquired 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 command No. 1, the receiver 3 first establishes a connection with the broadcasting station server 2 using https, and acquires the encryption key from the broadcasting station server 2 through communication over that https connection. The https connection authenticates the server 2 from the perspective of the receiver 3, ensuring the reliability of the acquired encryption key.

[0032] Line No. 2 is an API command for executing an 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, it 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 called "arib-dc: / / encryption key resource name"), but may also include other content that is to be acquired by the receiver 3 (for example, identification information indicating the attributes of the encryption key, etc.).

[0034] In the case of HTML, for example, it is an API command that calls downloadBroadcasterCertificate, which is an API defined as a method of a 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 called "arib-dc2: / / encryption key resource name"), but may also include other content that is to be acquired by the receiver 3 (for example, identification information indicating the attributes of the encryption key, etc.).

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

[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 a LocalStorage object whose operation is defined 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 defined in ARIB TR-B39. For the encrypted write instruction information and storage location identification information, for example, "_e_wlocal" + item number, for example, "_e_wlocal0", may be used instead of the access key name defined in ARIB TR-B39, for example, "_wlocal" + item number.

[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, it is an API command that calls writePersistentArrayEncrypted, which is an API conforming 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 be conforming to the embodiment of the argument in the API command in the case of BML in the row No. 3, or may be conforming to the argument of writePersistentArray specified in ARIB TR-B14. In the latter case, the receiver 3 recognizes that it is necessary to encrypt the data to be written to the NVRAM from "Encrypted" included in the API name, and may encrypt the write data specified in the argument and then store it in the NVRAM.

[0040] In the case of HTML, for example, it is an API command that calls setItemEncrypted, which is an API conforming to the method of the LocalStorage object whose operation is specified in ARIB TR-B39. The API command is, for example, setItemEncrypted (argument). The argument of the API command includes at least receiver data identification information to be written as encrypted data by the receiver 3, and storage location identification information. For example, the argument may be conforming to the embodiment of the argument in the API command in the case of HTML in the line No. 3, or may be conforming to the argument of setItem specified in ARIB TR-B39. In the latter case, when the API of No. 4 is called, the receiver 3 may recognize that it is necessary to encrypt the data to be written to the NVRAM from "Encrypted" included in the API name, and may encrypt the write data specified in the argument and store it in the NVRAM. In this embodiment, an example is shown in which the receiver 3 performs encrypted writing with the API of No. 3 and No. 4 using the encryption key acquired with the API of No. 1 or No. 2.

[0041] The NVRAM area to which 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 indicates the storage location to write encrypted data 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 reading API, and 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, which is an API defined in ARIB STD-B24. The API command is, for example, ReadPersistentArray (argument). The argument of the API command includes at least information for identifying the storage location of the encrypted data to be read by the receiver 3 (storage location identification information, for example, nvrame: / / ~ / <block number>). However, ~ and <block number> are the same as in No. 3 above.

[0044] In the case of HTML, for example, it is an API command that calls getItem, which is an API defined as a method of a LocalStorage object whose operation is prescribed 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 reading API, and 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 defined 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. For example, ARIB A URI such as "nvram: / / ~ / <block number>", which is one form of information for identifying a storage location in the data broadcasting NVRAM defined in TR-B14, may be specified. In this case, in an embodiment in which encrypted data and unencrypted receiver data are stored in different areas even if they have the same block number, when the receiver 3 receives the API command No. 6, it may recognize from "Encrypted" included in the API name that the data is to be read from the area storing the encrypted data, and read the encrypted data from the NVRAM.

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

[0048] Line No. 7 is an API command for executing a 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, it is an API command that calls transmitTextDataOverIP, which is an API defined in ARIB STD-B24. The API command is, for example, transmitTextDataOverIP (argument). In this embodiment, the argument of the API command includes the encrypted data read using the API command of No. 4 or No. 5, and information for identifying the destination. In this embodiment, the encrypted data may be text data. Note that encrypted data is generally binary data and not text data, so for example, data obtained by reversibly converting the encrypted data into text data by Base64 encoding may be used as the argument. The information for identifying the destination is, for example, the URL of the server 2, "https: / / address of the server 2", to which "?datatype=nvram&encrypted=yes" is added as a parameter. This information indicates that the receiver 3 that has received this API command is to transmit the encrypted data to the server 2 of the broadcast station. More specifically, the receiver 3 makes a connection request to the server 2 in order to transmit the encrypted data. When making the connection request, the above parameters are transmitted. When the server 2 receives a connection for transmission from the receiver 3, it verifies 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 transmit 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 to be transmitted, and the latter argument is the encrypted data to be transmitted). These embodiments may be the same as the embodiment in transmitTextOverIP of the BML. By the API command No. 7, the receiver 3 transmits the encrypted data read from the information storage unit 36 ​​(NVRAM for data broadcasting) to the server 2 of the specified broadcasting station as is, that is, without decrypting the encryption.

[0051] In the present embodiment, an example is shown in which an API command, which is an instruction to the API of the receiver 3, is included in application data broadcast by a digital television data broadcasting service, but this is not limiting. For example, an instruction for an API function may be included in a Signaling Information (SI) signal of the TS format.

[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 with the receiver 3 and the transmitter 2 via https communication. For example, the application data processing unit 22 analyzes application data (not limited to BML files and HTML files in this case) from the receiver 3, and issues processing commands to functions in 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 non-volatile memory, and stores the encryption key and the encryption / decryption key. However, the encryption key and the encryption / decryption key may be stored in physically different memories in consideration of the difference in the importance of their confidentiality.

[0058] The key generation unit 25 generates an encryption key and an encryption / decryption key, and stores them in the key storage unit 24. In this embodiment, an asymmetric key cryptography technique 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 held secretly 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 a method for generating a public key and a private key are common techniques, a description thereof will be omitted.

[0059] The decryption processing unit 26 decrypts the encrypted data received from the receiver 3 with the encryption / decryption key, obtains the receiver data, and outputs the data. Specifically, the decryption processing unit 26 receives the encrypted data, which is the receiver data encrypted with the encryption key, from the application data processing unit 22. The decryption processing unit 26 decrypts the encrypted data with the encryption / decryption key, and obtains the receiver data. The decryption method using the encryption / decryption key (secret key) by the asymmetric key cryptography is a common technique, so a description thereof will be omitted. In this embodiment, an example is shown in which the server 2 has the encryption key and the encryption / decryption key, but the servers having the encryption key and the encryption / decryption key may be different. In that case, the server having the encryption / decryption key has a function of performing a process using the encryption / decryption key. In this embodiment, an example is shown in which the server 2 has the encryption key and the encryption / decryption key, but the servers having the encryption key and the encryption / decryption key may be different. In that case, the server having the encryption / decryption key has a function of performing a process 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 such as viewing analysis.

[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 of 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 linkage 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, and information about the owner of the receiver 3, for example. All of these data that the receiver 3 can store are 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 broadcasts). The receiver 3 can transmit the receiver data to the server 2 via the network 5, for example. The server 2 uses the received receiver data by analyzing it, etc. In this embodiment, the receiver data is encrypted and then stored in the information storage unit 36 ​​as encrypted data, and the encrypted data is read from the information storage unit 36 ​​and transmitted to the server 2. Moreover, the receiver 3 includes a processing function such as a CPU for implementing the above functions.

[0063] The broadcast tuner 31 receives broadcast waves 4 from an antenna, cable, etc., and performs decoding, demodulation, etc. on the broadcast waves 4 in accordance with the transmission path coding and modulation methods of the transmitter 1 in accordance with various digital broadcasting standards, thereby obtaining and outputting 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 and the like from the broadcast stream processing unit 32, and controls various functions of the receiver 3 based on the acquired various control information and the like. The control unit 33 may also receive various control commands from a 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, the application data storage unit 34 may be used as a cache or buffer that stores the application data received from when the broadcast tuner 31 starts receiving a broadcast signal until the receiver 3 (specifically, the application execution unit 35) executes an 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 storage medium such as NVRAM (Non-Volatile Memory). The information storage unit 36 ​​may be a storage medium (also called NVRAM for data broadcasting) for data (also called 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 shown with logical distinction based on the contents of the data for the purpose of explaining the data stored in the information storage unit 36, and does not necessarily show the physical relationship in the information storage unit 36. Therefore, not all of the contents shown in the diagram are necessarily stored in the information storage unit 36.

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

[0072] 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, and a correspondence table linking storage locations in NVRAM with broadcasters may be stored in another memory (not shown), and receiver 3 may refer to the correspondence table when accessing NVRAM.

[0073] In this embodiment, "name", "address" and "email address" are stored in the 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 explaining FIG. 6, and do not need to be stored as specific data in the information storage unit 36. Also, each block is divided into field 1 and field 2, and "data body" and "registration date and time" are written in each.

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

[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 indicates data of block 1, which is a storage area on information accumulation unit 36. The information element stored in block 1 is "address." More specifically, field 1 of block 1 stores a specific "address" as the data body, and field 2 stores the "registration date and time" when the "address" was registered.

[0077] Area 3605 indicates data of block N, which is a storage area on information accumulation unit 36. The information element stored in block N is "viewing behavior data", and more detailed information is omitted since it is similar to area 3604.

[0078] Figure 6(b) shows an example of data stored in a memory area of ​​information storage unit 36. The difference from Figure 6(a) is the address shown in area 3606. 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 information storage unit 36 ​​that stores encrypted data. The "data body" of field 1 in Figure 6(b) is all encrypted data (encrypted data).

[0079] Fig. 6(c) shows an example of data stored in a memory area of ​​information storage unit 36. The difference from Fig. 6(a) is area 3607. In Fig. 6(c), field 3 "encrypted or not" is added. In the case of Fig. 6(b), it is possible to determine whether the data stored in information storage unit 36 ​​is encrypted based on the address shown in area 3606, but in the case of Fig. 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 related to the owner of the receiver 3. The receiver data storage unit 37 may be, for example, a part of a work memory used by the application execution unit 35. The work memory may be a dynamic random access memory (DRAM) 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 the 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 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 a 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 be cases where data, signals, etc. are exchanged with functional blocks in the receiver 3 that are not connected 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, thereby enabling 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 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 according to the command. Specifically, the read processing unit 352 executes the processing to read the encrypted data from the information storage unit 36 ​​(NVRAM), and outputs it to the communication processing unit 359, for example.

[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, when the API name includes "encrypted" or the like, such as API No. 4 and No. 6 in Fig. 3, or when this is indicated by an argument, such as API No. 3 and No. 5 in Fig. 3 (for example, when "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 according to 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 common techniques and 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 of the information storage unit 36 ​​specified by the API command.

[0096] The communication processing unit 359 has a function for 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 further 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 FIG. 5, FIG. 6(a) and FIG.

[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 roughly divided into four phases. The operation of each device for 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" over 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 the receiver 3 writes encrypted data to the information storage unit 36. The transmitter 1 transmits a write command (for the encrypted data) over the broadcast waves 4 (step P21). When the receiver 3 receives the broadcast waves 4 and acquires the write command (for the encrypted data), it encrypts the receiver data using the "encryption key" acquired in phase 1 (step P22). The receiver 3 stores the encrypted receiver data in the information storage unit 36 ​​(step P23).

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

[0105] Phase 4 is a phase in which the receiver 3 transmits encrypted data to the server 2, and the server 2 acquires the receiver data. The transmitter 1 transmits a "send command (for encrypted data)" over the broadcast waves 4 (step P41). The receiver 3 receives the broadcast waves 4 and, upon acquiring the "send command (for 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 an 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 waves 4.

[0107] Below, examples of the operations of the transmitter 1, the server 2, and the receiver 3 in each phase will be described with reference to each flowchart.

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

[0109] The application data generating unit 14 of the transmitter 1 generates application data including API commands for causing the receiver 3 to execute the processes of all 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 the BML file and the HTML file, 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 for identifying the destination, and may be, for example, "https: / / address of server 2?datatype=nvram&encrypted=yes" when transmitting encrypted data to server 2 of a broadcasting station. Argument 5 is information indicating the encrypted data 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 indicating the storage destination of the encrypted data to be read. Broadcast stream generating section 16 multiplexes the generated application data (BML file or HTML file) with the data streams output by service data stream generating section 11 and control information generating section 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 transmitting unit 17 performs transmission line coding and modulation according to various digital broadcast standards to generate and output the broadcast wave 4 (step S13). The broadcast wave 4 is output from an antenna, a cable, etc. (not shown).

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

[0112] For example, assume that the user switches the 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). When the control unit 33 controls the broadcast tuner 31 in response to the "channel selection command", the broadcast tuner 31 receives the broadcast wave 4 of the selected channel (step S32). The broadcast tuner 31 processes the broadcast 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 of 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 starts the application execution unit 35 (step S34). On the other hand, the application data of 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 obtains application data from the application storage unit 34 and analyzes the application data (step S36). The data analysis unit 350 outputs an API command extracted by analyzing the application data to the API processing unit 351, and the API processing unit 351 interprets the API command and executes the API function (step S37).

[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). Although the API of each function differs between the 2K broadcast (TS method) and the 4K8K method (MMT method), there is no particular difference in the processing of the API command and the processing by the API. Therefore, unless otherwise specified, the description in the embodiment is applicable to both the case of 2K broadcast (TS method) and the case of 4K8K method (MMT method). Whether the broadcast wave 4 received by the receiver 3 is the 2K broadcast (TS method) or the 4K8K method (MMT method) is determined in step S32 in FIG. 10. The API processing unit 351 recognizes that the received API command is an API command requesting the server 2 for an encryption key, and causes the encryption key acquisition unit 354 to execute encryption key acquisition processing. The encryption key acquisition unit 354 requests the server 2 for an encryption key (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 a processing operation of the server when obtaining an encryption key in the 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 at the timing of receiving the encryption key request message from the receiver 3, or may generate them at any timing regardless of whether the encryption key request message from the receiver 3 is received, and store them in the key storage unit 24. When the application data processing unit 22 receives the message via the communication unit 21 and recognizes that it is an encryption key request message, it outputs the encryption key request message to the encryption key request processing unit 23 (step S212). The encryption key request processing unit 23 obtains the encryption key from the key storage unit 24 based on the received encryption key request message (step S213). The encryption key request processing unit 23 transmits the encryption key to the receiver 3, for example, by 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 figure corresponds to details of step S37 in the flowchart in FIG.

[0118] The API processing unit 351 receives the API command shown in the 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 from the API name or its argument or the like (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, the API processing unit 351 causes the encryption processing unit 356 to execute processing based on the API command, and the encryption processing unit 356 recognizes the receiver data to be encrypted from the receiver data identification information specified by the argument of the API command or the like, and encrypts the specified receiver data (unencrypted data) (Yes in step S322, step S323). More specifically, when the encryption processing unit 356 receives a command to execute processing from the API processing unit 351, it acquires receiver data from, for example, the receiver data storage unit 37 (or the information accumulation unit 36 ​​in some cases), encrypts the acquired receiver data using the encryption key stored in the encryption key storage unit 355, and outputs the encrypted data to the write processing unit 358. The write processing unit 358 stores the encrypted data in a storage area for encrypted data in the information accumulation unit 36 ​​(for example, a block indicated by the <block number> of 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 in the row of 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 from 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, or 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 of ​​the 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 data from the storage area of ​​the 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 of ​​the encrypted data and the storage area of ​​the unencrypted data are not distinguished from each other, the read processing unit 352 may retrieve data from the information storage unit 36 ​​and output it to the communication processing unit 359 without determining whether the API command is an API command that handles encrypted data (step S332). In the communication processing unit 359, the encrypted data may be stored in, for example, a memory or a 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 figure corresponds to details of step S37 in the flowchart in FIG.

[0123] The API processing unit 351 receives the API command shown in line No. 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 for transmission by https communication (hereinafter referred to as https transmission data) (step S342). The https transmission data is transmitted from the communication unit 38 to the server 2 identified by the URL specified in the API command via the network 5 (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 in line No. 7 by continuously executing the API function corresponding to the API command in line No. 5 or No. 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 describes "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 describes "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 shows 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 data broadcasting service application can 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 data broadcasting service application can cause the receiver 3 to read the encrypted receiver data on 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, by encrypting the data stored in the information storage unit 36 ​​using asymmetric key encryption technology, the encrypted data stored in the information storage unit 36 ​​can be decrypted only by an encryption / decryption key held by the server 2 alone, and the server 2 can collect receiver data while ensuring confidentiality (or confidentiality in information security technology). It is also possible to use symmetric key encryption technology as the encryption technology for the data. However, when using symmetric key encryption technology, a common key is used to encrypt the data. The common key is required for encryption and decryption of the encrypted data. If the symmetric key encryption technology is applied in this embodiment, the receiver 3 that encrypts the data and the server 2 that decrypts the encrypted data share the same common key. Therefore, when the symmetric key encryption technology is applied, the receiver 3 also holds a key that can decrypt the encrypted data. If a third party other than the broadcasting company, which is the owner of the receiver 3 or the administrator of the server 2, reads the encrypted data from the information storage unit 36 ​​by some means (for example, by connecting a reading device to the semiconductor memory that is the entity of the data broadcasting NVRAM and reading it), and also retrieves the common key held by the receiver 3, the third party can decrypt the encrypted data and obtain the receiver data, and the problem of ensuring the confidentiality of information is not solved. Asymmetric key cryptography uses a public key that can be made public and may be known to a third party as an encryption key, and there is no need to share the decryption key, so it is 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 the asymmetric key cryptography.

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

[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 FIG. 5 and FIG.

[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 obtains the encryption key transmitted as part of the application data.

[0132] The broadcasting station's server 2 generates an encryption key and transmits the generated "encryption key" to the transmitter 1 via the network 6 (step P121). The transmitter 1 transmits the encryption key by broadcast waves 4 (step P122). Here, the transmitter 1 stores the encryption key in application data and transmits it by broadcast waves 4. In addition to transmitting the encryption key, the transmitter 1 transmits an "encryption key acquisition command" by 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 from 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 generating 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 as shown below (conforming to ARIB STD-B24, ARIB STD-B62, etc.). <When the broadcast wave 4 is in the TS format> arib-dc: / / resource name of the encryption key <When the broadcast wave 4 is in the MMT format> arib-dc2: / / resource name of the encryption key 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 line coding and modulation according to various digital broadcast 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 the embodiment. The processing operation of the receiver 3 is similar to 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 in the row 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 executes analysis of 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 is able to obtain the encryption key transmitted in the broadcast wave 4 by 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 obtain an encryption key contained in a broadcast signal. In this embodiment, an example will be described in which the encryption key is obtained 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 FIG. 5 and FIG.

[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 a phase in which the receiver 3 obtains an encryption key from SI transmitted over the same broadcast wave 4 separately from 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 transmit the encryption key repeatedly in the broadcast wave 4. The receiver 3 receives the broadcast wave 4 and analyzes it (step P133). Through the analysis, the receiver 3 obtains the encryption key stored in the broadcast wave 4 (step P134).

[0145] Fig. 21 shows an example of transmitting an encryption key in the SI of the TS broadcast wave 4 in the embodiment. Fig. 21(a) shows a descriptor (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 the descriptors defined in ARIB STD-B10. The descriptor is transmitted by allocating it to the 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 broadcast wave 4 of the MMT method in the 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 the descriptors defined in ARIB STD-B60. The above-mentioned descriptor is transmitted by arranging it in the descriptor area of ​​the MH-broadcaster information table (MH-BIT) defined 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 airwaves 4 (step P231), independent 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 the receiver 3 in this embodiment will be described below.

[0148] The transmitter 1 transmits the encryption key as control information (for example, SI) in the control information generating unit 12, for example. Furthermore, the application data generating 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. <When the application data is a BML file> {writePersistentArray (argument 1, argument 2)} <When the application data is an HTML file> {setItem (argument 3, argument 4)} However, argument 1 may be "nvrame: / / ~ / <block number>" and argument 3 may be "_e_wlocal+item number". Furthermore, argument 2 and argument 4 may be receiver data identification information. The above API command is the same as the API command used in the first embodiment, so a description thereof will be omitted.

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

[0150] The operations from steps S3301 to S3306 are similar to steps S31 to S37 in Fig. 10 of the first embodiment, so a description thereof will be omitted here. In this embodiment, unlike the operation example of the first embodiment, steps S3307 to S3309 are added. The flowchart in Fig. 23 shows that 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 in the row 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 from the API name or its argument or the like (step S3322). In this embodiment, since the argument of the API command includes "nvrame:", the encryption determination unit 353 determines that it is an API command that handles encrypted data, and the API processing unit 351 makes the encryption key acquisition unit 354 check whether a necessary encryption key is stored in the encryption key storage unit 355 based on the determination (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 (Yes in step S3323, S3324). The encryption processing unit 356 encrypts the receiver data (unencrypted data) designated by the receiver data identification information of the argument of the API command, etc., with the encryption key acquired in the previous step, to generate encrypted data (step S3325). The encryption processing unit 356 outputs the encrypted data to the writing processing unit 358, and the writing processing unit 358 stores the encrypted data in a storage area (for example, nvrame: / / ~ / <block number>) of the information storage unit 36 ​​(step S3326). If the encryption determination unit 353 determines that the API command is an API command that does not handle encrypted data, the API processing unit 351 stores the designated data in the information storage unit 36 ​​without encrypting it (No in steps S3322, S3327). If the encryption key required is not stored in the encryption key storage unit 355, the encryption key acquisition unit 354 ends the process without encrypting the designated 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 steps, the receiver 3 obtains an 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 of transmitting the encryption key as part of the application data of the broadcast wave 4 has been described, and in the third embodiment, an example of transmitting the encryption key as SI of the broadcast wave 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 the application in the third embodiment. Specifically, in the former embodiment, for example, a null character string is set as information identifying the storage location of the encryption key in the broadcast wave 4 in the API command for acquiring the encryption key, and when the control unit 33 confirms that a null character string is specified as the information identifying the storage location of the encryption key, it may acquire the encryption key from the SI of the broadcast wave 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 method of the transmitting side (transmitter 1) transmitting the key includes a method of transmitting the key as part of the application data, a method of transmitting the key as SI, and the like. In addition, the method of the receiving side (receiver 3) receiving the key includes a method of using the API, a method of the receiver performing in the background without using the API, and the like. There are no particular limitations on the combination of the method for transmitting the key and the method for receiving the key, 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 reads out the written data. In this embodiment, the receiver 3 recognizes that the API command handles encrypted data by including in the API name of the API command a word that indicates that it 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 FIG. 5 and FIG.

[0158] An operation example 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 operation examples of the transmitter 1, server 2, and receiver 3 will be described using the flowchart used in the first embodiment. Also, the description of the same parts as the operation example 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 generator 14 generates application data 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) as shown below. <When application data is a BML file> {writePersistentArrayEncrypted (argument 1, argument 2) ReadPersistentArrayEncrypted (argument 1) transmitTextDataOverIP (argument 3, argument 4)} <When 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, and "_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 encrypted data read by an API command for each file, i.e., readPersistentArray (argument 1) or getItemEncrypted (argument 1), and may be, for example, a variable or object indicating a storage destination of the encrypted data to be read. Argument 4 is information identifying a transmission destination, and may be, for example, "https: / / address of server 2?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 of the data writing destination is "nvram:". Also, for the data transmission API command (API in line No. 7 in FIG. 3), if an API command for executing an encrypted data reading API and an API command for executing a data transmission API are written consecutively as described above, the data transmission API may transmit the data read by the encrypted data reading 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 the 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 FIG. 10 and FIG. 13 shown in the description of the first embodiment.

[0163] It is assumed that the receiver 3 extracts the API command according to the flowchart in FIG. 10 (step S37), and further performs encryption processing of the receiver data according to the flowchart in 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 is encrypted receiver data in particular, it may be called an encrypted data block.

[0166] FIG. 6(c) shows an example of data stored in the storage area of ​​the information storage unit 36, and an area 3607, a field for "encryption / non-encryption", is added to FIG. 6(a). The encryption identification information may be, for example, 1-bit data, with 0 representing unencrypted data and 1 representing encrypted data. In this embodiment, an example is shown in which encryption processing of "data" is performed 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 is specified as nvrame: / / ~ as shown in area 3606 in FIG. 6(b), but in this embodiment, the area for storing encrypted receiver data is specified as nvram: / / ~. Therefore, in this embodiment, there is a possibility that encrypted receiver data and unencrypted receiver data are stored together. In this embodiment, by adding area 3607 in FIG. 6(c), it is possible to distinguish between encrypted receiver data and unencrypted receiver data. Note that instead of storing the encryption identification information in area 3607, a correspondence table between blocks of the information storage unit 36 ​​and encryption identification information may be created, and the correspondence table may be 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 broadcast) without determining 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 in the row No. 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 from the API name or its argument or the like (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, and the API processing unit 351 causes the read processing unit 352 to execute processing based on the API command, and the read processing unit 352 performs a read process of the encrypted data. When the encryption identification information (area 3607 in FIG. 6(c)) for the "information element" that is specified to be read by the receiver data identification information that is the argument of the API command is 1, the read processing unit 352 reads out data of the "information element" that is specified to be read, and outputs it to the communication processing unit 359 (Yes in step S3433, S3434). If the encryption identification information for the "information element" specified to be read is 0, the read processing unit 352 stops reading 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 execute a read process of the unencrypted data. If the encryption identification information (area 3607 in FIG. 6C) 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 stops reading 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, for example, a memory or a buffer (not shown).In this embodiment, an API command for executing a data transmission API is described immediately after an API command for executing an encrypted data reading API, so that 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 execute 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 ​​that 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 out by the above procedure can be transmitted to the outside using the flowchart in Fig. 15. Details of data transmission are the same as those in the first embodiment, so a detailed explanation will be omitted. Furthermore, 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 (unencrypted) receiver data. Details of reception and decryption of 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, commands included in the application of the data broadcasting service can cause 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 further read the written data and transmit it to the server 2.

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

[0176] The main features of the receiver in the above-mentioned system can be described as follows. (1) A receiver comprising 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 information instructed by the application data, characterized in that the receiver comprises encryption means (encryption processing unit 356) for encrypting 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 writes the information to the information storage means after encrypting it with the encryption means. (2) The receiver described in (1), characterized in that the receiver comprises 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 outputs the read information to an external device (server 2) without decrypting it. (3) The receiver described in (1) or (2), characterized in that 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 an encryption key storage instruction means for storing an encryption key in the encryption key storage means according to an instruction included in the application data. (5) The receiver according to (4), further comprising an encryption key that is a part of application data of a data broadcast included in the broadcast signal. (6) The receiver according to (4), further comprising an encryption key separation means (control unit 33) for extracting the encryption key from a part 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 an API 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-mentioned 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 having the encryption key and stores the encryption key; A transmitter including a broadcast signal transmitting means for transmitting a write command to the digital television broadcast receiver to encrypt receiver data in the receiver with the encryption key and write the encrypted data to an internal information storage means of the receiver, and the encryption key included in a broadcast signal. (A2) The transmitter according to (A1), wherein the encryption key is a public key of a public key cryptosystem. The transmitter according to any one of (A1) and (A2), further comprising a write command transmission means for transmitting a write command. (A4) 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 that is 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 identification information for identifying that the receiver data to be written is the encrypted data. (A7) The transmitter according to any one of (A1) to (A6), 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. (A8) The transmitter according to (A7), wherein the write command is a command for an API built into the receiver.

[0178] The main points of the 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 digital television broadcast receiver to encrypt receiver data stored in the receiver with the encryption key and write the encrypted data to an internal information storage means of 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 in the receiver using the encryption key based on a write command included in the broadcast signal to generate encrypted data; A system including an information writing means for writing the encrypted data to an information storage unit. (B2) The system according to (B1), wherein the encryption key is a public key of a public key cryptosystem. The system according to any one of (B1) and (B2), in which 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. (B4) (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 some 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 new embodiments can be implemented in various other forms, and various omissions, substitutions, and modifications can be made without departing from the gist of the invention. These embodiments and their modifications are included in the scope and gist of the invention, and are included in the scope of the invention and its equivalents described in the claims. Furthermore, even if each component of the claims is expressed by dividing the components, or expressing a plurality of components together, or expressing them in combination, it is within the scope of the present invention. In addition, multiple embodiments may be combined, and examples composed of this combination are also within the scope of the invention.

[0180] In addition, in order to clarify the explanation, the drawings may be shown in a schematic manner with respect to the width, thickness, shape, etc. of each part compared to the actual embodiment. In the functional block diagrams of the drawings, the components of the functions necessary for the explanation are represented by blocks, and the description of the components of general functions may be omitted. In addition, the blocks showing the functions are functional concepts, and do not necessarily have to be physically configured as shown in the drawings. For example, the specific form of distribution and integration of the blocks of each function is not limited to the form in the drawings. The blocks of each function are functionally or physically distributed and integrated according to the usage situation of each function block. In the block diagram, data and signals may be exchanged between blocks that are not connected, or in the direction where the arrow is not shown even if the blocks are connected. Each function shown in the block diagram and the processes shown in the flowchart and sequence chart may be realized by hardware (such as an IC chip), software (such as a program), a digital signal processing arithmetic chip (Digital Signal Processor, DSP), or a combination of these hardware and software. The present invention also applies to the device or method when the claims are expressed as control logic, when expressed as a program including instructions for causing a computer to execute the program, and when expressed as a computer-readable recording medium having the instructions written thereon. 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 receiver, a server, and a transmitter, The receiver includes: a receiving means for receiving a broadcast signal transmitted from the transmitter; an information reading means for reading encrypted data obtained by encrypting receiver data stored in the receiver with an encryption key from an information storage unit based on a read command included in the broadcast signal; an information transmitting means for transmitting the encrypted data to an external device based on a transmission command included in the broadcast signal; The transmitter includes: a means for including in the broadcast signal the read command for instructing the information read means of the receiver to read the encrypted data from the information storage unit, and the transmission command for instructing the information read means of the receiver to transmit the read encrypted data to the external device, The server, means for decrypting the received encrypted data; means for transmitting the read command and the transmission command to the transmitter.

2. The storage data area of ​​the information storage unit is divided into an area for each broadcasting company and an area shared by broadcasting companies, and the area for each broadcasting company and the area shared by broadcasting companies are further divided into small areas of blocks (or items).

2. The digital television broadcasting system according to claim 1.

3. A digital television broadcasting method comprising a receiver, a server, and a transmitter, In the receiver, the receiving means, the information reading means, and the information transmitting means are controlled, Receive a broadcast signal sent from the transmitter; Based on a read command included in the broadcast signal, encrypted data obtained by encrypting receiver data stored in the receiver with an encryption key is read from an information storage unit; Transmitting the encrypted data to an external device based on a transmission command included in the broadcast signal; In the transmitter, the read command for instructing the information reading means of the receiver to read the encrypted data from the information storage unit and the transmission command for instructing the information reading means of the receiver to transmit the read encrypted data to the external device are included in the broadcast signal and are transmitted; In the server, Decrypting the received encrypted data; Transmitting the read command and the transmission command to the transmitter. Digital television broadcasting methods.

4. The storage data area of ​​the information storage unit is divided into an area for each broadcasting company and an area shared by broadcasting companies, and the area for each broadcasting company and the area shared by broadcasting companies are further divided into small areas of blocks (or items). The digital television broadcasting method according to claim 3.

Images