JP7760030B2 - Digital television broadcasting system and method - Google Patents

Description

Embodiments relate to digital television broadcasting systems and methods.

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), 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 handled in data broadcasting, a service offered in 2K broadcasting and 4K/8K broadcasting. Data broadcasting NVRAM is created and transmitted by broadcasters and is accessible from data broadcasting content executed on the receiver. However, access control technologies are provided to conceal data stored in data broadcasting NVRAM by a broadcaster from other broadcasters, such as by specifying accessible areas for each broadcaster.

Patent No. 5027636

ARIB TR-B14 6.2 Edition "Digital Terrestrial Television Broadcasting Operational Guidelines" ARIB TR-B39 2.2 Edition "Advanced Wideband Satellite Digital Broadcasting Operational Guidelines"

However, if a third party other than the receiver owner or broadcaster reads data recorded in the data broadcast NVRAM using a method other than accessing it from the data broadcast content (for example, by connecting a reading device to the semiconductor memory that constitutes the data broadcast NVRAM), the third party can obtain the information represented by that data. In other words, the confidentiality of the information is not ensured. Data recorded in NVRAM, a non-volatile storage medium, is retained unless explicitly erased, so there is a possibility that the information could be accessed by a third party if, for example, the receiver is transferred to another person or disposed of. Considering that some data broadcast content created by broadcasters (including that to be created in the future) may record information in the data broadcast NVRAM that could pose a serious problem if accessed by a third party, such as personal information, it is necessary to ensure the confidentiality of the information even if the data is accessed by a third party.

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

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 encryption key acquisition means for acquiring an encryption key from the broadcast signal or from the server via a communication line based on a key acquisition command;
an encryption means for encrypting receiver data stored in the receiver using the encryption key based on a write command included in the broadcast signal to generate encrypted data;
an information writing means for writing the encrypted data to an information storage unit,
The transmitter
The application data generating means includes:
the key acquisition command for causing the receiver to acquire the encryption key;
the write command for generating the encrypted data using the encryption key and writing the encrypted data to the information storage unit;
a read command for instructing the information reading means of the receiver to read the encrypted data from the information storage unit;
a transmission command for instructing the server to transmit the encrypted data that has been read out, and causing the generated command to be included in the broadcast signal;
A digital television broadcasting system is provided.

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

The following describes the embodiments with reference to the drawings.

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

Broadcast station 10 is a 2K broadcast or 4K/8K broadcast station. When distinguishing between a 2K broadcast station and a 4K/8K broadcast station, they are referred to as a 2K broadcast station and a 4K/8K broadcast station, respectively. Broadcast station 10 includes a transmitter 1 and a server 2.

Transmitter 1 transmits digital broadcast signals, including application data and various control information, onto broadcast waves such as 2K broadcasts, 4K/8K broadcasts, and outputs the broadcast waves from an antenna, cable, etc.

The server 2 is, for example, a computer, and is equipped with a communications interface for communicating with external devices and a CPU for processing data. Specifically, the server 2 exchanges various data with the receiver 3 via network 5. The server 2 also exchanges various data with the transmitter 1 via network 6. The transmitter 1 can transmit data obtained from the server 2 via broadcast waves 4. Note that while only one broadcast station 10 and one receiver 3 are shown in Figure 1, there are typically 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 each output broadcast waves 4 individually, and each receiver 3 can receive one or multiple broadcast waves 4 from multiple transmitters 1.

Broadcast wave 4 is, for example, a radio wave, but may also be output from an antenna or transmitted via a wire such as cable broadcasting.

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

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

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

Transmitter 1 generates a broadcast stream (digital data stream) conforming to various digital broadcasting standards from, for example, digital broadcast signals (digital data for digital broadcasting), application data, various control information, etc. obtained from server 2, and outputs the digital data stream via broadcast waves 4. Examples of various digital broadcasting standards include the MPEG2 Transport Stream (TS) method, which is a transmission method for 2K broadcasting, and the MPEG Media Transport (MMT) method, which is a transmission method for 4K/8K broadcasting.

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

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

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

The application data generation unit 14 generates application data to be executed on the receiver 3. In this embodiment, the application data generation unit 14 generates application data including commands (hereinafter referred to as API commands) for the Application Programming Interface (API) shown in FIG. 3. The API is an interface provided to an application by an application engine, which is an execution program built into the receiver 3, and is also referred to as a broadcast extension function (or broadcast extension object) defined in standards such as ARIB STD-B24 and ARIB STD-B62. The application in this embodiment is assumed to be a data broadcasting application (in the case of 4K/8K broadcasting) or data broadcasting content (in the case of 2K broadcasting). Specifically, files written in Broadcast Markup Language (BML) or HyperText Markup Language (HTML) (referred to as BML files and HTML files, respectively) are transmitted. In this embodiment, these files contain API commands for executing the following APIs. Details are provided in the description of FIG. 3: API for acquiring and storing the encryption key used for encryption (encryption key acquisition API); Data write API (encrypted); Encrypted data read API (no decryption); Data transmission API. Note that, although the application data generation unit 14 is an example of a function of the transmitter 1 in this embodiment, 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.

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

The broadcast stream generation unit 16 includes, for example, a multiplexer, and multiplexes the data streams output by the service data stream generation unit 11, control information generation unit 12, and application stream generation unit 13 in accordance with various digital broadcasting standards, and outputs the multiplexed data stream as a broadcast stream.

The broadcast signal transmitter 17 performs encoding and modulation, including transmission path coding, on the digital data of the broadcast stream in accordance with various digital broadcasting standards, to generate broadcast waves 4, which are output to an antenna, cable, etc. (not shown).

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

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

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

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

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

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

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

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

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

Line No. 3 is an API command that executes the data writing API, causing the 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 the receiver 3.

In the case of BML, for example, this is an API command that calls writePersistentArray, an API specified in ARIB STD-B24. The API command is, for example, writePersistentArray (argument). The argument of the API command includes at least information identifying the receiver data to be written to the receiver 3 as encrypted data (receiver data identification information), information instructing the receiver 3 to write the data as encrypted data (encryption write instruction information), and information identifying the storage location to which the encrypted data will be written (storage location identification information). For example, the receiver data identification information may be as specified in ARIB TR-B14. Additionally, for the receiver data identification information and storage location identification information, instead of the URI (Uniform Resource Identifier) "nvram://~/<block number>", which is one form of information for identifying a storage location in the data broadcasting NVRAM specified in ARIB TR-B14, the URI "nvram://~/<block number>" may be used. Here, the meanings of ~ and <block number> shall be values conforming to the specifications of ARIB TR-B14.

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

Line No. 4 is an API command that executes the data writing API, causing the 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 the receiver 3.

In the case of BML, for example, this is an API command that calls writePersistentArrayEncrypted, an API that conforms to writePersistentArray specified in ARIB STD-B24. The API command is, for example, writePersistentArrayEncrypted (argument). The argument of the API command includes at least receiver data identification information and storage location identification information. For example, the argument may conform to the embodiment of the argument in the API command for BML in row No. 3 above, or may conform to the argument of writePersistentArray specified in ARIB TR-B14. In the latter case, the receiver 3 may recognize from the "Encrypted" included in the API name that the data to be written to NVRAM needs to be encrypted, and may encrypt the write data specified in the argument before storing it in NVRAM.

In the case of HTML, for example, this is an API command that calls setItemEncrypted, an API that conforms to the method of the LocalStorage object, the operation of which is specified in ARIB TR-B39. The API command is, for example, setItemEncrypted (argument). The argument of the API command includes at least the receiver data identification information that the receiver 3 writes as encrypted data, and storage location identification information. For example, the argument may conform to the embodiment of the argument in the API command for HTML in line No. 3 above, or may conform to the argument of setItem specified in ARIB TR-B39. In the latter case, the receiver 3 calls No. When API No. 4 is called, it is possible to recognize from the "Encrypted" included in the API name that the data to be written to NVRAM needs to be encrypted, and encrypt the write data specified in the argument before storing it in NVRAM. In this embodiment, an example is shown in which the receiver 3 uses the encryption key obtained with API No. 1 or No. 2 to perform encrypted writing with API No. 3 and No. 4.

The NVRAM area to which encrypted data is written using 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 "nvram://~/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 command No. 3 and No. For example, when the URL "nvram://~/0" is specified in the BML API commands No. 4, i.e., writePersistentArray (argument) and writePersistentArrayEncrypted (argument), the area to which the receiver 3 writes data when the API is called by the former API command No. 3 and the area to which the receiver 3 writes encrypted data when the API is called by the latter API command No. 4 may be separate areas or the same area. The same applies to the HTML API command No. 4.

Line No. 5 is an API command that executes the encrypted data read API, which causes the receiver 3 to read encrypted data from the information storage unit 36.

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

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

Line No. 6 is an API command that executes the encrypted data read API, which causes the receiver 3 to read encrypted data from the information storage unit 36.

In the case of BML, for example, it is an API command that calls ReadPersistentArrayEncrypted, which is an API conforming to ReadPersistentArray specified in ARIB STD-B24. The API command is, for example, ReadPersistentArrayEncrypted (argument). The argument of the API command includes at least storage location identification information of the encrypted data to be read by the receiver 3. The storage location identification information of the encrypted data to be read is, for example, ARIB
A URI such as "nvram://~/<block number>", which is one form of information for identifying a storage location in the data broadcasting NVRAM specified 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 API command No. 6, it may recognize from the "Encrypted" included in the API name that it is to read from the area where encrypted data is stored, and read the encrypted data from the NVRAM.

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

Line No. 7 is an API command that executes the data transmission API, and is an API command that causes the receiver 3 to transmit encrypted data to the broadcast station's server 2.

In the case of BML, for example, this is an API command that invokes transmitTextDataOverIP, an API specified in ARIB STD-B24. The API command is, for example, transmitTextDataOverIP (argument). In this embodiment, the argument of the API command includes the encrypted data read using API command No. 4 or No. 5 and information identifying the destination. In this embodiment, the encrypted data may be text data. Note that encrypted data is generally binary data, not text data, so the argument may be, for example, data obtained by reversibly converting the encrypted data into text data using Base64 encoding. The information identifying the destination is, for example, the URL of server 2, "https://server2address," to which the parameter "?datatype=nvram&encrypted=yes" is added. This information indicates that the receiver 3 that received this API command should send encrypted data to the broadcast station's server 2. More specifically, the receiver 3 requests a connection to the server 2 to send encrypted data. When requesting a connection, the above parameters are sent. When the server 2 receives a connection from the receiver 3 for transmission, it uses the received parameters to confirm that the receiver 3 is attempting to send encrypted data.

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

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

Figure 4 is a block diagram showing an example of the functional configuration of a server at a broadcast station according to an embodiment.

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

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.

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

In response to an 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.

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

The key generation unit 25 generates encryption keys and encryption/decryption keys and stores them in the key storage unit 24. In this embodiment, asymmetric key cryptography is applied, with the encryption key being a public key and the encryption/decryption key being a private key. The key generation unit 25 generates a one-to-one combination of public and private keys. 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 third parties. As asymmetric key cryptography and methods for generating public and private keys are common technologies, a description of them will be omitted.

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

The receiver data storage unit 27 stores the receiver data output from the decoding processing unit 26. The receiver data is any data owned by the receiver 3, such as installation location information, owner information, viewing data, and viewing behavior data related to the receiver 3; for example, the viewing data and viewing behavior data are used as analytical data for viewing analysis, etc.

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

The receiver 3 is, for example, a digital television receiver, and is capable of receiving digital broadcasts, including 2K, 4K, and 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 integrated services. The receiver 3 can also acquire and store viewing behavior data, such as the viewing history of digital broadcast programs viewed by the receiver 3, as well as information about the owner of the receiver 3. All of this data that the receiver 3 can store is referred to as receiver data. The receiver 3 can store all or part of the receiver data in the information storage unit 36 (NVRAM for data broadcasting). The receiver 3 can transmit the receiver data to the server 2, for example, via the network 5. The server 2 uses the received receiver data by analyzing it, etc. In this embodiment, the receiver data is encrypted and stored as encrypted data in the information storage unit 36. The encrypted data is then read from the information storage unit 36 and transmitted to the server 2. The receiver 3 also has a CPU and other processing functions to implement the above functions.

The broadcast tuner 31 receives broadcast waves 4 from an antenna, cable, etc., and performs decoding and demodulation on the broadcast waves 4 in accordance with the transmitter 1's transmission path coding and modulation methods in accordance with various digital broadcast standards, obtaining and outputting the digital data of the broadcast stream.

The broadcast stream processing unit 32 performs processes such as demultiplexing (data separation) and source encoding/decoding 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.

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

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

The application execution unit 35 includes application engine functions such as a BML browser and an HTML browser. This is described in detail in the description of Figure 7.

The information storage unit 36 is, for example, NVRAM (Non-Volatile Memory), a non-volatile storage medium. The information storage unit 36 may also be a storage medium (also called data broadcasting NVRAM) 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 nvram and nvram in the logical address.

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

Figure 6 is a diagram showing an example of a stored data area in the information storage unit of a receiver according to an embodiment. This diagram is intended to explain the data stored in the information storage unit 36, and shows logical divisions based on the content of the data. It does not necessarily show the physical relationships within the information storage unit 36. Therefore, not all of the content shown in the diagram is necessarily stored in the information storage unit 36.

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

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

In this embodiment, "name," "address," and "email address" are stored in blocks (or items). Note that while information types 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 convenience of explaining Figure 6, and do not necessarily need to be stored as specific data in the information storage unit 36. Furthermore, each block is divided into field 1 and field 2, and the "data body" and "registration date and time" are written in each.

Area 3602 is field 1, where the data itself is stored. For example, field 1 of block 0 stores "Name."

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.

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

Area 3605 shows the data of block N, which is a storage area on the information storage unit 36. The information element stored in block N is "viewing behavior data," and more detailed information is omitted as it is the same as area 3604.

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

Figure 6(c) shows an example of data stored in the memory area of the information storage unit 36. The difference from Figure 6(a) is area 3607. In Figure 6(c), field 3 "Encrypted or not" has been added. In the case of Figure 6(b), it is possible to determine whether the data stored in the information storage unit 36 is encrypted based on the address shown in area 3606, but in the case of Figure 6(c), it is possible to determine whether the data is encrypted based on field 3.

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

The communication unit 38 includes a communication interface that enables the receiver 3 to communicate via the network 5, and implements the communication protocol applied to the network 5 (such as an IP communication method or a dedicated line method).

The presentation control unit 39 adjusts the output timing and processing of each piece of data, such as service data, data broadcasting service data, and application data, in order to display or output the data as audio on the presentation unit 301, and then outputs the data (referred to as presentation data) to the presentation unit 301.

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

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

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

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

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

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

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

The encryption determination unit 353 receives an API command from the API processing unit 351 and determines whether the API command is related to encrypted data. Specifically, if the API name includes "encrypted" or the like, as in APIs No. 4 and No. 6 in Figure 3, or if this is indicated by an argument, as in APIs No. 3 and No. 5 in Figure 3 (for example, if "nvrame://~/<block number>" is specified as storage destination identification information), the encryption determination unit 353 recognizes that the API command is an API command that handles encrypted data.

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

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

In response to an execution command from the API processing unit 351, the encryption processing unit 356 encrypts the receiver data using the encryption key acquired by the encryption key acquisition unit 354. Encryption and decryption methods using asymmetric key cryptography are common techniques, so a detailed description will be omitted.

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

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

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

(First embodiment)
In this embodiment, an example is described in which commands included in the application of a data broadcasting service cause the receiver 3 to encrypt receiver data, specify a storage area for the encrypted data and write it to the information storage unit 36, and then read the encrypted receiver data from the information storage unit 36 and transmit the encrypted data to the broadcasting station's server.

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

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

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

The operation of the system according to this embodiment can be broadly divided into four phases. The operation of each device for each phase is shown below.

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

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

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

Phase 4 is the phase in which receiver 3 transmits encrypted data to server 2, and server 2 acquires the receiver data. Transmitter 1 transmits a "send command (for encrypted data)" via broadcast wave 4 (step P41). Receiver 3 receives broadcast wave 4 and acquires the "send command (for encrypted data)," then transmits the encrypted data to the specified device (server 2 in this embodiment) (step P42). Server 2 receives the encrypted data (step P43), decrypts the received encrypted data using the encryption/decryption key, and acquires the receiver data (step P44).

In this embodiment, an example is shown in which the transmitter 1 generates the "write command," "read command," and "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.

Below, examples of the operation of the transmitter 1, server 2, and receiver 3 in each phase are explained using the respective flowcharts.

Figure 9 is a flowchart showing an example of the processing operation of the transmitter according to this embodiment.

The application data generation unit 14 of the transmitter 1 generates application data including API commands for causing the receiver 3 to execute the processes of all the above phases in order (step S11). Specific examples of application data are shown below. <When the application data is a BML file> {downloadBroadcasterCertificate (argument 1) writePersistentArray (argument 2, argument 3) readPersistentArray (argument 2) transmitTextDataOverIP (argument 4, argument 5)} <When the application data is an HTML file> {downloadBroadcasterCertificate (argument 1) setItem (argument 2, argument 3) getItem (argument 2) XMLHttpRequest. open(argument 4) XMLHttpRequest.send(argument 5)} However, for both BML files and HTML files, argument 1 may be "https://server 2 address/path to encryption key file," argument 2 may be nvram://~/<block number>, and argument 3 may be receiver data identification information. Argument 4 is information identifying the destination, and may be, for example, "https://server 2 address?datatype=nvram&encrypted=yes" when transmitting encrypted data to server 2 of a broadcasting station. Argument 5 is information representing 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 location of the encrypted data to be read.
The broadcast stream generating unit 16 multiplexes the generated application data (BML file or HTML file) with the data streams output by the service data stream generating unit 11 and the control information generating unit 12, and outputs the multiplexed data as a broadcast stream (step S12).

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

Figure 10 is a flowchart showing an example of the processing operation of the receiver in this embodiment.

For example, suppose a user changes channels using the remote control 303. The receiver 3 receives a remote control control signal from the remote control 303 via the interface unit 302, and the control unit 33 recognizes that the remote control control signal is a "channel selection command" (Yes in step S31). The control unit 33 controls the broadcast tuner 31 in accordance with the "channel selection command," and the broadcast tuner 31 receives the broadcast wave 4 of the selected channel (step S32). The broadcast tuner 31 processes the broadcast wave 4 to obtain a broadcast stream, and the broadcast stream processing unit 32 processes the broadcast stream to obtain various data. When application control information from the data acquired by the broadcast stream processing unit 32 is output to the control unit 33, the control unit 33 analyzes the application control information (step S33). When the control unit 33 analyzes the application control information and detects an "application execution command," the control unit 33 activates the application execution unit 35 (step S34). Meanwhile, the application data from the data acquired 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 starts up, 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 analyzes the application data and outputs the extracted API command to the API processing unit 351, which then interprets the API command and executes the API function (step S37).

Figure 11 is a flowchart showing an example of the processing operation of the application execution unit when obtaining an encryption key in this embodiment, and corresponds to the processing operation in Phase 1. This figure corresponds to details of step S37 in the flowchart in Figure 10.

The API processing unit 351 receives the API command shown in row No. 1 in Figure 3 and recognizes the API command (step S311). Note that while the API commands for each function differ between 2K broadcasting (TS format) and 4K8K format (MMT format), there are no particular differences in the processing of the API commands and the processing by the API. Therefore, unless otherwise specified, the following description of the embodiment is applicable to both 2K broadcasting (TS format) and 4K8K format (MMT format). Whether the broadcast wave 4 received by the receiver 3 is 2K broadcasting (TS format) or 4K8K format (MMT format) is determined in step S32 of Figure 10. The API processing unit 351 recognizes that the received API command is an API command requesting an encryption key from the server 2 and causes the encryption key acquisition unit 354 to execute encryption key acquisition processing. The encryption key acquisition unit 354 requests an encryption key from the server 2 (step S312). Specifically, the encryption key acquisition unit 354 creates an encryption key request message in accordance with an execution request based on the API command from the API processing unit 351, and sends the encryption key request message to the server 2 via the communication processing unit 359 and the communication unit 38. When the encryption key is sent from the server 2, the encryption key acquisition unit 354 receives the encryption key via the communication unit 38 and the communication processing unit 359, and stores the encryption key in the encryption key storage unit 355 (step S313).

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

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

Figure 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 Figure 10.

The API processing unit 351 receives the API command shown in row No. 3 or No. 4 in Figure 3. The API processing unit 351 recognizes the API command and outputs it to the encryption determination unit 353 (step S321). The encryption determination unit 353 determines whether the API command is an API command that handles encrypted data based on the API name or its arguments, etc. (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 "nvram://~/<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 API processing unit 351 causes the encryption processing unit 356 to execute processing based on the API command. The encryption processing unit 356 recognizes the receiver data to be encrypted from receiver data identification information specified in the API command's arguments, etc., and encrypts the specified receiver data (unencrypted data) (Yes in step S322, step S323). More specifically, upon receiving a processing execution command from the API processing unit 351, the encryption processing unit 356 acquires receiver data, for example, from the receiver data storage unit 37 (or, in some cases, the information storage unit 36), 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 the encrypted data storage area of the information storage unit 36 (for example, the block indicated by <block number> in nvram://~/<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).

Figure 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 figure corresponds to details of step S37 in the flowchart in Figure 10.

The API processing unit 351 receives the API command shown in row No. 5 or No. 6 in Figure 3 and recognizes the API command (step S331). Specifically, the API processing unit 351 recognizes the API command and outputs it to the encryption determination unit 353. The encryption determination unit 353 determines whether the API command is an API command that handles encrypted data based on the API name or its arguments, etc. (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 API command argument is "nvram://~/<block number>," it may be determined that the API command handles encrypted data, and if the API command argument 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 encrypted data storage area in the information accumulation unit 36 and outputs it to the communication processing unit 359 (step S333). If the API command does not handle encrypted data, the read processing unit 352 retrieves the data from the storage area for unencrypted data in the information storage unit 36 and outputs it to the communication processing unit 359 (step S334). Note that in an embodiment in which the storage area for encrypted data and the storage area for unencrypted data are not distinguished, the read processing unit 352 may retrieve the data from the information storage unit 36 and output it to the communication processing unit 359 without determining whether the API command is an API command that handles encrypted data (step S332). The communication processing unit 359 may store the encrypted data in, for example, a memory or buffer (not shown).

Figure 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 Figure 10.

The API processing unit 351 receives the API command shown on line No. 7 in Figure 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 the data specified in the API command into data to be transmitted via https communication (hereinafter referred to as https transmission data) (step S342). The https transmission data is transmitted from the communication unit 38 via the network 5 to the server 2 identified by the URL specified in the API command (step S343). Note that by continuously executing the API function corresponding to the API command on line No. 7 in Figure 3 immediately after executing the API function corresponding to the API command on line No. 5 or No. 6 in Figure 3, which is Phase 3, the communication processing unit 359 executes the API function corresponding to the API command on line No. Regardless of the arguments of the API command on line 7, the encrypted data read from the information storage unit 36 in phase 3 may be sent.

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

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

By following 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 from the information storage unit 36 and transmit it to the broadcasting station's server 2. The broadcasting station's server 2 can receive the encrypted receiver data from the receiver 3 and obtain it by decrypting the encrypted receiver data.

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

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

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

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

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

The broadcasting station's server 2 generates an encryption key and transmits the generated "encryption key" to the transmitter 1 via the network 6 (step P121). The transmitter 1 transmits the encryption key via the broadcast waves 4 (step P122). Here, the transmitter 1 stores the encryption key within the application data and transmits it via the broadcast waves 4. Separately from transmitting the encryption key, the transmitter 1 transmits an "encryption key acquisition command" via the broadcast waves 4 (step P123). The receiver 3 receives and analyzes the broadcast waves 4 (step P124). If the receiver 3 detects the "encryption key acquisition command" as a result of the analysis, it further analyzes the broadcast waves 4 and obtains the encryption key within the application data (step P125).

Figure 18 is a flowchart showing an example of the processing operation of the transmitter according to this embodiment.

The application data generation unit 14 of the transmitter 1 generates encryption key transmission data for transmitting the encryption key data received from the server 2 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 (e.g., conforming to ARIB STD-B24, ARIB STD-B62, etc.) corresponding to the type of broadcast wave 4, as shown below: <When the broadcast wave 4 is in the TS format> arib-dc://encryption key resource name <When the broadcast wave 4 is in the MMT format> arib-dc2://encryption key resource name Furthermore, independently of (in parallel with) step S1201, application data including an API command, as shown below, is generated 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 arguments 1 and 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".

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

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

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

The API processing unit 351 of the receiver 3 receives the API command shown in row No. 2 in Figure 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 then analyzes the broadcast wave 4 (step S3202). Specifically, the control unit 33 identifies the encryption key from the data of the data broadcasting service output by the broadcast stream processing unit 32 based on the storage location of the encryption key data specified as an argument of the API command. The control unit 33 outputs the identified encryption key to the API processing unit 351, and the API processing unit 351 stores the input encryption key in the encryption key storage unit 355 (step S3203).

By following the above steps, the receiver 3 can obtain the encryption key transmitted in the broadcast wave 4 using commands included in the data broadcasting service application.

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

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

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

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

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

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

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

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

The transmitter 1 transmits the encryption key as control information (e.g., SI) using the control information generation unit 12, for example. Furthermore, the application data generation unit 14 of the transmitter 1 generates application data, independent of the transmission of the encryption key, including the API command in line No. 3 of Figure 3, as follows: <If the application data is a BML file> {writePersistentArray(argument 1, argument 2)} <If the application data is an HTML file> {setItem(argument 3, argument 4)} Note that argument 1 may be "nvframe://~/<block number>" and argument 3 may be "_e_wlocal+item number". Furthermore, arguments 2 and 4 may be receiver data identification information. The above API commands are the same as those used in the first embodiment, so a description thereof will be omitted.

Figure 23 is a flowchart showing an example of the processing operation of the receiver in this embodiment.

The operations from steps S3301 to S3306 are similar to steps S31 to S37 in Figure 10 of the first embodiment, so a description thereof will be omitted here. Unlike the operation example of the first embodiment, this embodiment adds steps S3307 to S3309. The flowchart in Figure 23 shows that steps S3302, S3303, S3304, and S3307 operate in parallel (independently).

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 then 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).

Figure 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 in Figure 23.

The API processing unit 351 receives the API command shown in row No. 3 in Figure 3 and recognizes the API command (step S3321). The API processing unit 351 outputs the recognized API command to the encryption determination unit 353. The encryption determination unit 353 determines whether the API command is an API command that handles encrypted data based on the API name or its arguments (step S3322). In this embodiment, since the arguments of the API command include "nvrame:", the encryption determination unit 353 determines that the API command is an API command that handles encrypted data. Based on this determination, the API processing unit 351 causes the encryption key acquisition unit 354 to confirm whether the necessary encryption key is stored in the encryption key storage unit 355 (step S3323). If the necessary encryption key is stored in the encryption key storage unit 355, the encryption key acquisition unit 354 acquires the encryption key from the encryption key storage unit 355 and inputs it to the encryption processing unit 356 (Yes in step S3323, S3324). The encryption processing unit 356 encrypts the receiver data (unencrypted data) specified by the receiver data identification information or other parameters of the API command using 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 encrypted data in the information accumulation unit 36 (e.g., nvram://~/<block number>) (step S3326). If the encryption determination unit 353 determines that the API command does not handle encrypted data, the API processing unit 351 stores the specified data in the information storage unit 36 without encrypting it (No in steps S3322, S3327). Furthermore, if the required encryption key is not stored in the encryption key storage unit 355, the encryption key acquisition unit 354 ends the process without encrypting the specified receiver data (No in step S3323). Alternatively, the process may be repeated from step S3323 after waiting for a while.

By following the above procedure, the receiver 3 obtains the encryption key from the SI transmitted over the same broadcast wave 4, separately from the application data in the broadcast wave 4, and can then use commands included in the data broadcasting service application to cause the receiver 3 to encrypt the receiver data and write the encrypted data to the information storage unit 36 (NVRAM).

In the second embodiment, an example of transmitting an encryption key as part of application data in the broadcast wave 4 was described, and in the third embodiment, an example of transmitting an encryption key as SI in the broadcast wave 4 was described. However, for example, it is also possible to transmit the encryption key as SI in the second embodiment, or to transmit the encryption key as part of an application in the third embodiment. Specifically, in the former embodiment, an API command for acquiring the encryption key may be set to, for example, an empty string as information identifying the storage location of the encryption key in the broadcast wave 4. When the control unit 33 confirms that an empty string has been specified as information identifying the storage location of the encryption key, it may acquire the encryption key from the SI in 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, methods for the transmitting side (transmitter 1) to transmit the key include transmitting it as part of application data or transmitting it as SI. Furthermore, methods for the receiving side (receiver 3) to receive the key include using an API or performing the receiver's background processing without using an API. There are no particular restrictions on the combination of these key transmission methods and key reception methods, and any combination is possible.

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

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

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

An example of the operation of transmitter 1 is explained below using the flowchart in Figure 9.

The application data generation unit 14 generates application data as shown below, including the API commands in lines No. 4, No. 6, and No. 7 of Figure 3, to enable the receiver 3 to write, read, and transmit encrypted receiver data (step S11 of Figure 9). <When the application data is a BML file> {writePersistentArrayEncrypted(argument 1, argument 2) ReadPersistentArrayEncrypted(argument 1) transmitTextDataOverIP(argument 3, argument 4)} <When the application data is an HTML file> {setItemEncrypted(argument 1, argument 2) getItemEncrypted(argument 1) putItem(argument 3, argument 4)} Note that argument 1 may be "nvram://~/<block number>" for a BML file, or "_wlocal+item number" for an HTML file. Argument 2 may be receiver data identification information for both BML and HTML files. Argument 3 is information representing the encrypted data read by the API command for each file, i.e., readPersistentArray (argument 1) or getItemEncrypted (argument 1), and may be, for example, a variable or object indicating the storage destination of the encrypted data to be read. Argument 4 is information identifying the destination, and may be, for example, "https://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 write destination is "nvram:". Furthermore, for the data transmission API command (API on line No. 7 in Figure 3), if an API command to execute the encrypted data read API and an API command to execute the data transmission API are written consecutively as described above, the data transmission API may send the data read by the encrypted data read API even if argument 2 is not specified.

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

Next, an example of the operation of the receiver 3 when writing data will be explained using Figures 10 and 13, which were shown in the explanation of the first embodiment.

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

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

The write processing unit 358 generates encryption identification information for the encrypted receiver data to indicate that it 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 Figure 6, and in particular, when the "data" in field 1 is encrypted receiver data, it may be referred to as an encrypted data block.

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

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

By following the above procedure, encrypted data can be written to the information storage unit 36 (NVRAM for data broadcasting) without having to specify an area for the encrypted data.

Below is an example of how receiver 3 operates when reading data.

Figure 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 in Figure 10.

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

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

The data read using the above procedure can be transmitted externally using the flowchart in Figure 15. Details of data transmission are the same as in the first embodiment, 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 Figure 16, and the encrypted data can be decrypted to obtain the (unencrypted) receiver data. Details of reception and decryption of encrypted data by the server 2 are the same as in the first embodiment, so a detailed explanation will be omitted.

According to this embodiment, commands included in the data broadcasting service application 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 then read and transmit the written data to the server 2.

At least one of the embodiments described above provides a receiver, method, and program for recording or collecting receiver data while ensuring the confidentiality of the information.

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

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

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

While several embodiments of the present invention have been described, these embodiments are presented as examples and are not intended to limit the scope of the invention. These novel embodiments can be embodied in a variety of other forms, and various omissions, substitutions, and modifications can be made without departing from the spirit of the invention. These embodiments and their variations are within the scope and spirit of the invention, and are also included in the inventions and their equivalents as set forth in the claims. Furthermore, the scope of the present invention also includes cases in which each component in the claims is expressed separately, as a combination of multiple components, or as a combination of these. Furthermore, multiple embodiments may be combined, and examples composed of such combinations are also within the scope of the invention.

In addition, to clarify the explanation, the drawings may show the width, thickness, shape, etc. of each part more schematically than in the actual configuration. In the functional block diagrams of the drawings, functional components necessary for explanation are represented by blocks, and descriptions of general functional components may be omitted. Furthermore, the blocks representing functions are conceptual and do not necessarily have to be physically configured as shown. For example, the specific form of distribution and integration of each functional block is not limited to the form shown in the diagram. Functional or physical distribution and integration may be configured depending on the usage situation of each functional block. In the block diagram, data and signals may be exchanged between unconnected blocks, or even between connected blocks in directions not indicated by arrows. Each function shown in the block diagram and the processes shown in the flowcharts and sequence charts may be realized by hardware (e.g., IC chips), software (e.g., programs), digital signal processing chips (Digital Signal Processors, DSPs), or a combination of these hardware and software. Furthermore, the device or method of the present invention is applied when the claims are expressed as control logic, as a program containing instructions for a computer to execute, or as a computer-readable recording medium containing the instructions. Furthermore, the names and terminology 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.

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 (4)

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 encryption key acquisition means for acquiring an encryption key from the broadcast signal or from the server via a communication line based on a key acquisition command;
an encryption means for encrypting receiver data stored in the receiver using the encryption key based on a write command included in the broadcast signal to generate encrypted data;
an information writing means for writing the encrypted data to an information storage unit,
The transmitter
The application data generating means includes:
the key acquisition command for causing the receiver to acquire the encryption key;
the write command for generating the encrypted data using the encryption key and writing the encrypted data to the information storage unit;
a read command for instructing the information reading means of the receiver to read the encrypted data from the information storage unit;
a transmission command for instructing the server to transmit the encrypted data that has been read out, and causing the generated command to be included in the broadcast signal;
Digital television broadcasting system. The storage data area of the information storage unit is divided into an area for each broadcasting company and an area shared by all broadcasting companies, and the area for each broadcasting company and the area shared by all broadcasting companies are further divided into small areas of blocks (or items).
2. The digital television broadcasting system of claim 1. A digital television broadcasting method in which broadcasting is performed in a state in which a receiver, a server, and a transmitter are able to communicate with each other, comprising the steps of:
The receiver includes:
receiving a broadcast signal sent from the transmitter;
acquiring an encryption key from the broadcast signal or from the server via a communication line based on a key acquisition command;
encrypting receiver data in the receiver using the encryption key based on a write command included in the broadcast signal to generate encrypted data;
The encrypted data can be written to an information storage unit,
The transmitter
The application data generating means
the key acquisition command for causing the receiver to acquire the encryption key;
the write command for generating the encrypted data using the encryption key and writing the encrypted data to the information storage unit;
a read command for instructing the information reading means of the receiver to read the encrypted data from the information storage unit;
and a transmission command for instructing the server to transmit the read encrypted data to the server, and the transmission command is generated and included in the broadcast signal. The storage data area of the information storage unit is divided into an area for each broadcasting company and an area shared by all broadcasting companies, and the area for each broadcasting company and the area shared by all broadcasting companies are further divided into small areas of blocks (or items).
4. The digital television broadcasting method according to claim 3.