Data distribution method, program and data distribution system

Abstract

In a data distribution method according to the present disclosure, a plurality of first authentication servers and a first data server belong to a first group, and a plurality of second authentication servers and a second data server belong to a second group different from the first group. One first authentication server acquires first transaction data including a data acquisition request indicating a request for acquisition of or reference to data relating to a device, and records a block including the first transaction data in a distributed ledger of one first authentication server belonging to the first group, and one second authentication server acquires the first transaction data, and records the block including the first transaction data in a distributed ledger belonging to the second group. Furthermore, the first data server is caused to transfer device data possessed by the first data server to the second data server, or to allow said data to be referred to by the second data server.

Description

[Technical Field]

[0001] The present disclosure relates to a data distribution method, a program, and a data distribution system for utilizing data collected from users. [Background technology]

[0002] In recent years, systems that collect, analyze, and distribute user data and device data have been under consideration. As the Internet of Things (IoT) advances and AI and other technologies become more widespread, it will become possible to collect more data than ever before, and it is expected that the collected data will be put to good use.

[0003] For example, Non-Patent Document 1 discloses Society 5.0, a human-centered society that achieves both economic development and the resolution of social issues through a system that highly integrates cyberspace (virtual space) and physical space (real space).

[0004] According to Non-Patent Document 1, in Society 5.0, personal data will be collected and utilized in, for example, tourism or healthcare. [Prior art documents] [Non-patent literature]

[0005] [Non-Patent Document 1] Strategy for Promoting Data Utilization to Realize Society 5.0, Internet〈URL:https: / / www.keidanren.or.jp / en / policy / 2017 / 104.html?v=p〉[Retrieved December 25, 2019] Summary of the Invention [Problem to be solved by the invention]

[0006] However, if it is not clear where and how the data collected from users is being used, i.e., if the traceability of the data collected from users cannot be ensured, users may be concerned about the risk of data leakage and may not provide the data itself. This problem means that it is not possible to collect enough data to be put to practical use.

[0007] The present disclosure has been made in consideration of the above-mentioned circumstances, and aims to provide a data distribution method etc. that enables data to be utilized while ensuring data traceability. [Means for solving the problem]

[0008] In order to achieve the above object, the data distribution method of the present disclosure is a data distribution method in a data distribution system consisting of a plurality of authentication servers, a plurality of data servers, and devices, each having a distributed ledger, wherein a first group includes a plurality of first authentication servers among the plurality of authentication servers and one or more first data servers among the plurality of data servers, and a second group different from the first group includes a plurality of second authentication servers different from the plurality of first authentication servers among the plurality of authentication servers and one or more second data servers different from the one or more first data servers among the plurality of data servers, and in the data distribution method, one first authentication server among the plurality of first authentication servers acquires or distributes data of the device. acquires first transaction data including a data acquisition request indicating that the one first authentication server requests to reference the data, and the one first authentication server records a block including the first transaction data in the distributed ledger of the one first authentication server belonging to the first group, and causes the one or more first data servers to transfer the device data held by the one or more first data servers to the one or more second data servers or make the data available for reference by the one or more second data servers, and one second authentication server among the plurality of second authentication servers acquires the first transaction data, and the one second authentication server records a block including the first transaction data in the distributed ledger of the one second authentication server belonging to the second group.

[0009] These comprehensive or specific aspects may be realized as a system, a method, an integrated circuit, a computer program, or a computer-readable recording medium such as a CD-ROM, or may be realized as any combination of a system, a method, an integrated circuit, a computer program, and a recording medium. [Effects of the Invention]

[0010] According to the present disclosure, it is possible to realize a data distribution method etc. that allows data to be utilized while ensuring data traceability. [Brief explanation of the drawings]

[0011] [Figure 1] FIG. 1 is a diagram illustrating an example of the overall configuration of a data distribution system according to an embodiment. [Figure 2] FIG. 2 is a diagram illustrating an example of the overall configuration of a house according to the embodiment. [Figure 3] FIG. 3 is a block diagram illustrating an example of the configuration of the controller illustrated in FIG. [Figure 4] FIG. 4 is a block diagram illustrating an example of a configuration of a terminal according to an embodiment. [Figure 5] FIG. 5 is a block diagram illustrating an example of the configuration of the authentication server according to the embodiment. [Figure 6] FIG. 6 is an explanatory diagram showing the data structure of a blockchain. [Figure 7] FIG. 7 is a block diagram illustrating an example of a data server according to the embodiment. [Figure 8] FIG. 8 is a block diagram illustrating an example of a service server according to the embodiment. [Figure 9A] FIG. 9A is an overall sequence diagram of a data distribution system according to an embodiment. [Figure 9B] FIG. 9B is an overall sequence diagram of the data distribution system according to the embodiment. [Figure 10] FIG. 10 is a sequence diagram showing consent information registration processing between the terminal and the authentication server according to the embodiment. [Figure 11] FIG. 11 is a sequence diagram showing a data registration process between a house, an authentication server, and a data server according to the embodiment. [Figure 12A] FIG. 12A is a sequence diagram showing a data reference process among a terminal, an authentication server, a data server, and a service server according to an embodiment. [Figure 12B] FIG. 12B is a sequence diagram showing a data reference process among the terminal, the authentication server, the data server, and the service server according to the embodiment. [Figure 13]FIG. 13 is a sequence diagram showing a smart contract registration process related to incentive payment between the authentication server and the service server according to the embodiment. [Figure 14A] FIG. 14A is a sequence diagram illustrating an example of a data providing process in the data distribution system according to the embodiment. [Figure 14B] FIG. 14B is a sequence diagram illustrating an example of a data providing process in the data distribution system according to the embodiment. [Figure 15A] FIG. 15A is a sequence diagram illustrating another example of the data providing process in the data distribution system according to the embodiment. [Figure 15B] FIG. 15B is a sequence diagram illustrating another example of the data providing process in the data distribution system according to the embodiment. [Figure 15C] FIG. 15C is a sequence diagram illustrating another example of the data providing process of the data distribution system according to the embodiment. DETAILED DESCRIPTION OF THE INVENTION

[0012] A data distribution method according to one embodiment of the present disclosure is a data distribution method in a data distribution system including a plurality of authentication servers, a plurality of data servers, and devices, each having a distributed ledger, wherein a first group includes a plurality of first authentication servers among the plurality of authentication servers and one or more first data servers among the plurality of data servers, and a second group different from the first group includes a plurality of second authentication servers different from the plurality of first authentication servers among the plurality of authentication servers and one or more second data servers different from the one or more first data servers among the plurality of data servers, and in the data distribution method, one first authentication server among the plurality of first authentication servers acquires or references data of the device. and the one first authentication server records a block including the first transaction data in a distributed ledger of the one first authentication server belonging to the first group, and causes the one or more first data servers to transfer the device data held by the one or more first data servers to the one or more second data servers or make the data accessible by the one or more second data servers, and one second authentication server among the plurality of second authentication servers acquires the first transaction data, and the one second authentication server records a block including the first transaction data in a distributed ledger of the one second authentication server belonging to the second group.

[0013] As a result, the fact that the data has been transferred or made accessible is recorded in both the distributed ledger belonging to the first group of the data provider and the distributed ledger belonging to the second group of the data recipient. In this way, data belonging to different groups can be linked. This makes it possible to realize a data distribution method that allows data to be utilized while ensuring data traceability, even between different groups.

[0014] Furthermore, the data distribution system may further include a service server, and in the data distribution method, the service server may generate the first transaction data and transmit it to the one first authentication server and the one second authentication server, and when the one first authentication server acquires the first transaction data, the one first authentication server may determine whether the data can be provided from the one or more first data servers to the one or more second data servers based on consent information obtained from the device, the consent information regarding the utilization of the data, and cause the one or more first data servers to transfer the data of the device held by the one or more first data servers to the one or more second data servers or make the data accessible to the one or more second data servers.

[0015] This ensures data traceability while allowing data to be utilized with the user's consent.

[0016] Furthermore, when the service server confirms that the one or more first data servers have transferred the device data to the one or more second data servers or made it accessible to the one or more second data servers, second transaction data for issuing a token to the device may be generated, the one first authentication server may acquire the second transaction data, the one first authentication server may record a block including the second transaction data in a distributed ledger of the one first authentication server belonging to the first group, and the one first authentication server may operate a smart contract programmed to issue a token based on the recorded second transaction data, thereby causing the smart contract to issue a token to the device.

[0017] Furthermore, the one first authentication server may acquire a smart contract that is programmed to be executable to determine whether the data can be provided based on the consent information, and when the one first authentication server acquires the first transaction data, by executing the smart contract based on the acquired first transaction data, when it determines that the data can be provided from the one or more first data servers to the one or more second data servers, it may cause the one or more first data servers to transfer the device data held by the one or more first data servers to the one or more second data servers or make the data accessible to the one or more second data servers.

[0018] Furthermore, when recording the first transaction data in the distributed ledger of the one first authentication server, the one first authentication server may verify the acquired first transaction data, and if the one first authentication server confirms the legitimacy of the first transaction data through the verification, execute a consensus algorithm together with multiple first authentication servers excluding the one first authentication server among the plurality of first authentication servers to reach an agreement on the legitimacy of the first transaction data, and if the legitimacy of the first transaction data is agreed upon by the consensus algorithm, the one first authentication server may record a block including the first transaction data in the distributed ledger of the one first authentication server belonging to the first group.

[0019] Furthermore, when recording in the distributed ledger of the one second authentication server, the one second authentication server may verify the acquired first transaction data, and if the one second authentication server confirms the legitimacy of the first transaction data through the verification, execute a consensus algorithm together with multiple second authentication servers excluding the one second authentication server among the plurality of second authentication servers to reach an agreement on the legitimacy of the first transaction data, and if the legitimacy of the first transaction data is agreed upon by the consensus algorithm, the one second authentication server may record a block including the first transaction data in the distributed ledger of the one second authentication server belonging to the second group.

[0020] Furthermore, a data distribution system according to an embodiment of the present disclosure is a data distribution system including a plurality of authentication servers and a plurality of data servers, each having a distributed ledger, wherein a first group includes a plurality of first authentication servers among the plurality of authentication servers and one or more first data servers among the plurality of data servers, and a second group different from the first group includes a plurality of second authentication servers different from the plurality of first authentication servers among the plurality of authentication servers and one or more second data servers different from the one or more first data servers among the plurality of data servers, and one first authentication server among the plurality of first authentication servers sends a first transaction including a data acquisition request indicating a request to acquire or refer to device data. a first communication unit that acquires the first transaction data, a first recording unit that causes the one first authentication server to record a block including the first transaction data in the distributed ledger of the one first authentication server that belongs to the first group, and an execution unit that causes the one or more first data servers to transfer the device data held by the one or more first data servers to the one or more second data servers or make the device data accessible by the one or more second data servers; and one second authentication server among the plurality of second authentication servers comprises a second communication unit that acquires the first transaction data, and a second recording unit that causes the one second authentication server to record a block including the first transaction data in the distributed ledger of the one second authentication server that belongs to the second group.

[0021] Hereinafter, embodiments will be described with reference to the drawings. Note that each of the embodiments described below represents a specific example of the present disclosure. Therefore, the numerical values, shapes, materials, components, component arrangements and connection forms, steps, step order, etc. shown in the following embodiments are examples of the present disclosure and are not intended to limit the present disclosure. Furthermore, among the components in the following embodiments, components that are not described in an independent claim showing an implementation form of one aspect of the present disclosure will be described as optional components. Implementation forms of the present disclosure are not limited to the current independent claim, but may also be expressed by other independent claims.

[0022] (Embodiment) First, the system configuration of the present disclosure will be described.

[0023] [1. System Configuration] The data distribution system of the present disclosure records that data has been transferred or made accessible in both the distributed ledger belonging to the data provider's group and the distributed ledger belonging to the data recipient's group. In this way, the data distribution system of the present disclosure utilizes blockchain technology to link data belonging to different groups while ensuring data traceability. In other words, the data distribution system of the present disclosure allows data to be utilized while ensuring data traceability. This allows users to provide data with peace of mind.

[0024] The data distribution system and the like according to the embodiment will be described below with reference to the drawings.

[0025] [1.1 Overall configuration of the data distribution system 10] Fig. 1 is a diagram showing an example of the overall configuration of a data distribution system 10 according to this embodiment. As shown in Fig. 1, the data distribution system 10 includes a house 100, a terminal 110, authentication servers 200a, 200b, 200c, 210a, 210b, and 210c, data servers 300 and 310, and service servers 400 and 410. These are connected via a communication network 500.

[0026] The authentication servers 200a, 200b, 200c, 210a, 210b, and 210c are connected to a storage device having a distributed ledger in which transaction data and blocks of the blockchain are electronically recorded. Note that the authentication server 200 may be connected to the storage device via a communication network 500, or may have the storage device built in.

[0027] Furthermore, the authentication servers 200a, 200b, and 200c and the data server 300 form one group (hereinafter referred to as the first group), and the authentication servers 200a, 200b, and 200c will be described as managing the data of the data server 300 using blockchain technology. The authentication servers 200a, 200b, and 200c will be described as authentication servers 200. Similarly, the authentication servers 210a, 210b, and 210c and the data server 310 form one group (hereinafter referred to as the second group) different from the first group, and the authentication servers 210a, 210b, and 210c will be described as managing the data of the data server 310 using blockchain technology. The authentication servers 210a, 210b, and 210c will be described as authentication servers 210. The first group and the second group are, for example, examples of different blockchain platforms, and the distributed ledgers belonging to each group contain different transaction data.

[0028] [1.2 Structure of the House 100] FIG. 2 is a diagram showing an example of the overall configuration of a house 100 according to this embodiment.

[0029] House 100 is an example of a device according to the present disclosure that acquires or collects user data. The acquired or collected data may be, for example, healthcare data such as the user's medical checkup data, sleep data, blood pressure data, weight data, and exercise data, but is not limited to this. The acquired or collected data is not limited to healthcare data, but may also be user personal data including vital data such as heart rate, measurement data, or device history information such as device operation history or device manipulation history. In this way, the acquired or collected data may be data that can be utilized by the service provider.

[0030] 2, a house 100 includes a controller 101, a solar power generation device 102, a storage battery 103, an air conditioner 104, a body composition monitor 105, and a blood pressure monitor 106. These are connected via a communication network.

[0031] In the following description, it is assumed that the data acquired or collected by the house 100 is stored in the data server 300 belonging to the first group.

[0032] <Controller 101> The controller 101 controls home appliances such as an air conditioner 104, a body composition monitor 105, and a blood pressure monitor 106. The control unit 1011 may also display the operating status of the solar power generation device 102 and the storage battery 103.

[0033] The controller 101 may also collect history information such as the operation history or manipulation history of the home appliances, or may collect history information on the operating status of the solar power generation device 102 and the storage battery 103. The controller 101 may also collect measurement data measured by the home appliances.

[0034] Furthermore, the controller 101 may transmit collected data such as history information and measurement data to the data server 300, and may transmit generated transaction data to the authentication server 200.

[0035] <Solar power generation device 102> The solar power generation device 102 is a device equipped with a power generation method that directly converts sunlight into electricity using a solar cell. The electricity generated by the solar power generation device 102 is used within the house 100 or stored in a storage battery 103. Note that the solar power generation device 102 is not an essential component and does not necessarily have to be provided in the house 100.

[0036] <Storage Battery 103> The storage battery 103 stores the power generated by the solar power generation device 102. Note that the storage battery 103 is not an essential component, and the house 100 does not necessarily have to include it.

[0037] <Air conditioner 104, body composition monitor 105 and blood pressure monitor 106> The air conditioner 104, the body composition meter 105, and the blood pressure monitor 106 are home appliances used by a user, but may also be examples of the appliances disclosed herein. For example, history information such as the operation history or manipulation history of the air conditioner 104 is transmitted to the data server 300. In addition, history information such as the operation history or manipulation history of the body composition meter 105 and the blood pressure monitor 106, weight data measured by the body composition meter 105, and / or blood pressure data measured by the blood pressure monitor 106, and other user measurement data are also transmitted to the data server 300. These data may be transmitted to the data server 300 via the controller 101, or may be transmitted directly to the data server 300.

[0038] An example of the configuration of the controller 101 will be described below.

[0039] [1.3 Controller 101 Configuration] FIG. 3 is a block diagram showing an example of the configuration of the controller 101 shown in FIG.

[0040] The controller 101 includes a processor (not shown) and a memory (not shown) that stores a program that causes the processor to execute a predetermined process. That is, the controller 101 is realized by the processor executing the predetermined program using the memory. In this embodiment, the controller 101 includes a control unit 1011, a transaction data generation unit 1012, an input unit 1013, a recording unit 1014, and a communication unit 1015, as shown in FIG. 3 .

[0041] <Control unit 1011> The control unit 1011 may control the home appliances. In the example shown in Fig. 2, the control unit 1011 operates the home appliances such as the air conditioner 104, the body composition meter 105, and the blood pressure monitor 106, and manages the operation history and status of the home appliances. The control unit 1011 may also display the operation status of the solar power generation device 102 and the storage battery 103. For example, the control unit 1011 may display the power generation status of the solar power generation device 102 or the power storage status of the storage battery 103. The control unit 1011 may also display the status of the home appliances or vital data measured by the body composition meter 105 or the blood pressure monitor 106.

[0042] The control unit 1011 may also collect history information such as the operation history or manipulation history of the home appliances, or may collect history information on the operating status of the solar power generation apparatus 102 and the storage battery 103. The control unit 1011 may also collect measurement data measured by the home appliances.

[0043] <Input section 1013> The input unit 1013 generates consent information regarding the utilization of acquired or collected data. Here, the consent information is information indicating the content of consent given by the user to the utilization of the acquired or collected data, and is generated based on the user's operation. The consent information may be generated, for example, by selecting or deselecting from a list of service providers to which the data is to be provided or a list of data provided by the input unit 1013. In this case, the consent information includes the service providers that can provide the data to which the user has consented, or the data or type of data that the user can provide. In other words, the consent information includes the service providers, data, or type of data to which the user has consented. Note that the consent information may, for example, be information agreeing to provide or allow the data to be referenced to a third party from the perspective of the data recipient provided by the input unit 1013, selected according to the user's predetermined criteria based on trustworthiness or incentives. The third party may be different from the group to which the data recipient provided by the input unit 1013 belongs. Furthermore, the consent information may include information agreeing to provide the data if feedback is above a certain level.

[0044] Furthermore, the input unit 1013 may generate a smart contract based on the generated consent information. Here, this smart contract is an executable program that determines whether data can be provided. This smart contract may include the consent information generated by the input unit 1013.

[0045] The input unit 1013 may be an application installed in the controller 101, in which case the installed application realizes the above-described functions of the input unit 1013.

[0046] <Transaction Data Generation Unit 1012> The transaction data generation unit 1012 generates transaction data in a blockchain. In this embodiment, the transaction data generation unit 1012 generates transaction data including the consent information generated by the input unit 1013. More specifically, the transaction data generation unit 1012 generates transaction data including, for example, a blockchain address held by the user, consent information including the service provider or data or type of data that the user has agreed to provide, and a signature. The transaction data generation unit 1012 may further assign an identifier to the transaction data when generating it. The transaction data generation unit 1012 generates a signature using a signature generation key individual to the user.

[0047] Furthermore, the transaction data generation unit 1012 may generate transaction data including the smart contract generated by the input unit 1013. Note that the transaction data generation unit 1012 may generate transaction data including the consent information and the smart contract generated by the input unit 1013.

[0048] Furthermore, the transaction data generation unit 1012 may generate transaction data including a data acquisition request acquired via the communication unit 1015. Here, the data acquisition request may be, for example, a request to acquire or make available data by a data server 310 that belongs to a group different from the group to which the controller 101 belongs. In this case, the transaction data generation unit 1012 may generate transaction data including the data acquisition request acquired via the communication unit 1015 and consent information for the data acquisition request.

[0049] Furthermore, the transaction data generation unit 1012 may generate transaction data including information indicating data such as history information or measurement data collected by the control unit 1011. In this case, the transaction data generation unit 1012 may generate transaction data including, for example, a blockchain address held by the user, information indicating the data collected by the control unit 1011, and a signature. Here, the information indicating the data may be, for example, the data itself collected by the control unit 1011, a hash value of the data, or a hash value of the data and attribute information of the data.

[0050] The attribute information of data may include, for example, the type of sensor or device that collected the data. Furthermore, when the data is step count data, weight data, body fat percentage data, blood pressure data, or the like, the attribute information of the data may include data items indicating when, how, and for what items the data was measured or collected. When the device is a home appliance or other in-home device, the data may also include data items indicating its operation history, operation date and time, etc.

[0051] The transaction data generation unit 1012 records the generated transaction data in the recording unit 1014. The transaction data generation unit 1012 transmits the transaction data to the authentication server 200 via the communication unit 1015.

[0052] <Recording Unit 1014> The recording unit 1014 records data such as history information and measurement data collected by the control unit 1011. The recording unit 1014 also records transaction data generated by the transaction data generation unit 1012. The recording unit 1014 may also record consent information and smart contracts generated by the input unit 1013.

[0053] <Communications Department 1015> The communication unit 1015 communicates with the authentication servers 200 and 210, the data server 300, and the service servers 400 and 410 via the communication network 500. This communication may be performed using TLS (Transport Layer Security). In this case, the communication unit 1015 may hold an encryption key for TLS communication.

[0054] Next, an example of the configuration of the terminal 110 will be described.

[0055] [1.4 Configuration of Terminal 110] 4 is a block diagram showing an example of the configuration of a terminal 110 according to the present embodiment. The terminal 110 is an example of a device of the present disclosure, and is realized by a processor executing a predetermined program using a memory. The terminal 110 is, for example, a device having a display unit and an input unit, such as a smartphone, or a device that acquires measurement data of a user, such as a wearable device.

[0056] 4, terminal 110 includes transaction data generation unit 1101, input unit 1102, data acquisition unit 1103, recording unit 1104, and communication unit 1105. In the following description, it is assumed that data acquired or collected by terminal 110 is stored in data server 300 belonging to the first group.

[0057] <Input section 1102> The input unit 1102 generates user consent information regarding the utilization of data. As described above, the consent information is information indicating the content of consent given by the user regarding the utilization of acquired or collected data, and is generated based on the user's operation.

[0058] For example, the consent information may be generated by selecting or deselecting from a list of service providers to which data is to be provided or a list of data provided by the input unit 1102. In this case, the user may select a service provider to which data is to be provided based on the purpose of using the data, the track record of using the data, or feedback or incentives to the user for using the data. An example of an incentive or feedback is when the service provider pays the user virtual currency or displays information that the user can enjoy when the user provides data to the service provider. Another example of an incentive or feedback is when the user provides measurement data, such as the measurement history of a body composition monitor or blood pressure monitor, to a sports club and displays information that the user can enjoy a free trial or a reduction in membership fees from the sports club.

[0059] Similarly to the above, the consent information may be information agreeing to provide or allow reference to data to a third party selected by the user based on a predetermined criterion of the user on the basis of trustworthiness or incentive, which is a third party from the perspective of the data recipient provided by the input unit 1102. The third party may be different from the group to which the data recipient provided by the input unit 1102 belongs.

[0060] The input unit 1102 may also generate a smart contract that is programmed to be executable to determine whether data can be provided based on the generated consent information.

[0061] <Transaction Data Generation Unit 1101> The transaction data generation unit 1101 generates transaction data in a blockchain. In this embodiment, the transaction data generation unit 1101 generates transaction data in a blockchain that includes consent information generated by the input unit 1102. More specifically, the transaction data generation unit 1101 generates transaction data that includes, for example, a blockchain address held by the user, consent information including the service provider or data or type of data that the user has agreed to provide, and a signature.

[0062] The transaction data generation unit 1101 may further assign an identifier to the transaction data when generating the transaction data. The transaction data generation unit 1101 may generate a signature using a signature generation key individual to the user.

[0063] Furthermore, the transaction data generation unit 1101 may generate transaction data including information indicating the data acquired by the data acquisition unit 1103. In this case, the transaction data generation unit 1101 may generate transaction data including, for example, a blockchain address held by the user, information indicating the data acquired by the data acquisition unit 1103, and a signature. The information indicating the data may be, for example, the data itself acquired by the data acquisition unit 1103, a hash value of the data, or a hash value of the data and attribute information of the data.

[0064] Furthermore, the transaction data generation unit 1101 may generate transaction data including the smart contract generated by the input unit 1102. Note that the transaction data generation unit 1101 may generate transaction data including the consent information and the smart contract generated by the input unit 1102.

[0065] The transaction data generation unit 1101 records the generated transaction data in the recording unit 1104. The transaction data generation unit 1101 transmits the generated transaction data to the authentication server 200 or the data server 300 via the communication unit 1105.

[0066] Furthermore, the transaction data generation unit 1101 may generate transaction data including a data acquisition request acquired via the communication unit 1105. Here, the data acquisition request may be, for example, a request to acquire or make available data by a data server 310 that belongs to a group different from the group to which the terminal 110 belongs. In this case, the transaction data generation unit 1101 may generate transaction data including the data acquisition request acquired via the communication unit 1105 and consent information for the data acquisition request.

[0067] <Data Acquisition Unit 1103> The data acquisition unit 1103 acquires data such as measurement data acquired by sensors included in the terminal 110. For example, if the terminal 110 has an acceleration sensor and a GPS sensor, the data acquisition unit 1103 acquires, as measurement data, step count data including the number of steps acquired from the acceleration sensor and location information acquired from the GPS sensor. The data acquisition unit 1103 may also acquire blood pressure data or heart rate data as measurement data. In other words, the data acquisition unit 1103 acquires data that can be utilized by the service provider.

[0068] The data acquisition unit 1103 records the acquired data in the recording unit 1104. The data acquisition unit 1103 may transmit the data to the data server 300 via the communication unit 1105.

[0069] <Recording Unit 1104> The recording unit 1104 records the transaction data generated by the transaction data generation unit 1101. The recording unit 1104 also records the data acquired by the data acquisition unit 1103. The recording unit 1104 may also record the consent information and smart contract generated by the input unit 1102.

[0070] <Communications Department 1105> The communication unit 1105 communicates with the authentication server 200 and the data server 300 via the communication network 500. This communication may be performed using TLS. In this case, the communication unit 1105 may hold an encryption key for TLS communication.

[0071] Next, an example of the configuration of the authentication server 200 will be described.

[0072] [1.5 Configuration of authentication servers 200 and 210] The authentication servers 200 and 210 manage data acquired from the house 100 or the terminal 110 .

[0073] As described above, authentication server 200 and data server 300 belong to the first group, and authentication server 200 manages data of data server 300 using blockchain technology. Here, authentication server 200, i.e., authentication servers 200a, 200b, and 200c, are an example of a plurality of first authentication servers, and authentication server 200a is an example of one of the plurality of first authentication servers.

[0074] Furthermore, authentication server 210 and data server 310 belong to a second group, and authentication server 210 manages data of data server 310 using blockchain technology. Here, authentication server 210, i.e., authentication servers 210a, 210b, and 210c, are an example of a plurality of second authentication servers, and authentication server 210c, for example, is an example of one of the plurality of second authentication servers.

[0075] Since the authentication servers 200a, 200b, 200c, 210a, 210b, and 210c have the same configuration, the following description will be given taking the authentication server 200a as an example.

[0076] FIG. 5 is a block diagram showing an example of the configuration of authentication server 200a according to this embodiment.

[0077] 5, the authentication server 200a includes a transaction data verification unit 211, a block generation unit 212, a synchronization unit 213, a smart contract execution unit 214, a recording unit 215, and a communication unit 216. The authentication server 200a can be realized by a processor executing a predetermined program using a memory. Each component will be described below.

[0078] <Transaction Data Verification Unit 211> The transaction data verification unit 211 verifies the acquired transaction data. Specifically, when transaction data is acquired from a device such as the house 100 or the terminal 110, the transaction data verification unit 211 verifies whether the format of the transaction data is correct and whether the signature is valid. For example, when verifying transaction data including a data acquisition request, the transaction data verification unit 211 verifies whether the address, data acquisition request, and signature included in the transaction data are valid. Note that, for example, when verifying transaction data including information indicating data, the transaction data verification unit 211 only needs to verify whether the address, information indicating the data, and signature included in the transaction data are valid.

[0079] In this way, the transaction data verification unit 211 verifies the acquired transaction data by checking the validity of the transaction data.

[0080] If the transaction data verification unit 211 verifies the validity of the transaction data, it records the transaction data in the recording unit 215. If it determines that the transaction data is valid, it notifies the synchronization unit 213.

[0081] <Block Generation Unit 212> If the transaction data verification unit 211 successfully verifies the transaction data, the block generation unit 212 executes a consensus algorithm for the transaction data among the multiple authentication servers 200. Here, the consensus algorithm may be a consensus algorithm called PBFT (Practical Byzantine Fault Tolerance), or may be any other known consensus algorithm such as PoW (Proof of Work).

[0082] In this embodiment, the block generation unit 212 executes a consensus algorithm among the authentication servers 200a, 200b, and 200c that belong to the same group, i.e., the first group. That is, the block generation unit 212 first generates a block of a blockchain that includes one or more transaction data. Next, the block generation unit 212 executes the consensus algorithm. Then, if consensus is reached by executing the consensus algorithm, the block generation unit 212 records the generated block in the recording unit 215. The block generated by the block generation unit 212 is connected to the blockchain by the recording unit 215 and recorded.

[0083] Here, the data structure of the blockchain will be explained.

[0084] FIG. 6 is an explanatory diagram showing the data structure of a blockchain.

[0085] A blockchain is a chain of blocks, which are the units of record. Each block contains multiple transaction data and the hash value of the previous block. Specifically, block B2 contains the hash value of the previous block B1. A hash value calculated from the multiple transaction data contained in block B2 and the hash value of block B1 is included in block B3 as the hash value of block B2. In this way, by connecting blocks in a chain while including the contents of the previous block as a hash value, tampering with the connected transaction data is effectively prevented.

[0086] If past transaction data were to be changed, the hash value of the block would be different from before the change, and in order to make the altered block appear correct, all subsequent blocks would have to be recreated, which is a very difficult task in reality.

[0087] <Synchronization unit 213> The synchronization unit 213 synchronizes the blocks of the blockchain or the transaction data among the multiple authentication servers 200 (authentication servers 200a to 200c) that belong to the same group, that is, the first group.

[0088] The synchronization units 213 of the multiple authentication servers 200 synchronize blockchain transaction data on a peer-to-peer basis. The synchronization units 213 then record the synchronized blockchain transaction data in the recording unit 215. For example, when the transaction data verification unit 211 verifies the validity of the transaction data, the synchronization unit 213 transfers the verified transaction data to authentication servers 200b and 200c, which are other authentication servers 200. Furthermore, when the synchronization unit 213 receives verified transaction data from another authentication server 200, it records the received verified transaction data in the recording unit 215.

[0089] <Smart contract execution unit 214> The smart contract execution unit 214 stores the smart contracts recorded in the distributed ledger in a working memory. The smart contract execution unit 214 executes the smart contracts stored in the working memory.

[0090] For example, when a block containing transaction data including a data acquisition request is generated and recorded in the distributed ledger of the authentication server 200a, the smart contract execution unit 214 stores the smart contract generated based on the user's consent information in the working memory. By executing the smart contract stored in the working memory, the smart contract execution unit 214 can cause the executed smart contract to determine whether or not to provide the data. The executed smart contract also notifies the user of the determination result on whether or not to provide the data, and grants access rights to the blockchain address included in the transaction data including the data acquisition request. In this way, the smart contract execution unit 214 can manage the service server 400's access to data held by the data server 300 by executing the smart contract, for example, triggered by access from the service server 400.

[0091] If the data acquisition request is a request to acquire or make accessible data to a data server 310 or the like belonging to a second group different from the first group to which the authentication server 200a belongs, the executed smart contract operates as follows. That is, the executed smart contract determines whether to provide data to the data server 310 or the like belonging to the second group based on the user's consent information. Then, if the executed smart contract determines that data can be provided, it instructs the data server 300 belonging to the first group to transfer the user's data to the data server 310 or make the data accessible by the data server 310. In this way, the smart contract execution unit 214 executes the smart contract when transaction data including the data acquisition request is recorded in the distributed ledger, and provides the data held by the data server 300 to a different group. Furthermore, since the fact that the data has been transferred or made accessible is recorded in the distributed ledger, data traceability can be ensured.

[0092] Furthermore, for example, when transaction data including information regarding an incentive payment or feedback provision is recorded in the distributed ledger, the smart contract execution unit 214 stores in the working memory a smart contract generated based on the incentive payment or feedback provision. The smart contract execution unit 214 executes the smart contract stored in the working memory, thereby causing the executed smart contract to pay an incentive or provide feedback. The incentive payment or feedback provision may be a notification that the incentive payment or feedback provision has been made, or may be the incentive payment or feedback provision to the user.

[0093] <Recording Unit 215> The recording unit 215 includes the transaction data in a block and records it in the distributed ledger of the authentication server 200a. The distributed ledger may be configured inside the recording unit 215, or may be configured inside an external storage device of the authentication server 200a.

[0094] The transaction data includes transaction data acquired from the house 100 or the terminal 110.

[0095] In this embodiment, when the recording unit 215 confirms the authenticity of transaction data received from the device of the present disclosure, it records a block including the transaction data in the distributed ledger of the authentication server 200a. Note that the block of the blockchain recorded in the distributed ledger may be made public to the service server 400, the house 100, or the terminal 110.

[0096] <Communications Department 216> The communication unit 216 communicates with the house 100, the terminal 110, the authentication servers 200b and 200c, the data server 300, and the service server 400. The communication unit 216 may also communicate with the authentication server 210. These communications may be performed using TLS. In this case, the communication unit 216 may hold an encryption key for the TLS communication.

[0097] In this way, authentication server 200a performs processes to verify the validity of data acquired from house 100 or terminal 110, manage whether data can be provided, and provide data to service server 400. Authentication server 200a also performs processes to manage whether data can be provided to a second group different from the first group to which it belongs, and to provide data to the second group. Note that providing data here may be, for example, data transfer or making data accessible.

[0098] Furthermore, although it has been described that the data acquired from the house 100 or the terminal 110 is recorded in the data server 300 and not in the authentication server 200a, this is not limiting. The data may be recorded in the authentication server 200a. In this case, the data may be recorded as transaction data including the data in the distributed ledger of the authentication server 200a.

[0099] Next, the data servers 300 and 310 will be described.

[0100] [1.6 Configuration of Data Servers 300 and 310] The data servers 300, 310 manage data acquired from the house 100 or the terminal 110 by recording (storing) the data. The data servers 300, 310 are an example of a plurality of data servers. The data server 300 is an example of one or more first data servers, and as described above, belongs to the first group. The data server 310 is an example of one or more second data servers different from the one or more first data servers, and as described above, belongs to the second group.

[0101] Since the data servers 300 and 310 have the same configuration, the following description will be given taking the data server 300 as an example.

[0102] FIG. 7 is a block diagram showing an example of the configuration of the data server 300 according to this embodiment.

[0103] 7, the data server 300 includes a data management unit 311, a user management unit 312, a recording unit 313, and a communication unit 314. The data server 300 can be realized by a processor executing a predetermined program using a memory. Each component will be described below.

[0104] <Data Management Department 311> The data management unit 311 manages data acquired from the house 100 or the terminal 110. In this embodiment, the data management unit 311 records the data acquired from the house 100 or the terminal 110 in the recording unit 313. Here, the acquired data may be data collected from a user by a device disclosed herein, such as the house 100 or the terminal 110, or may be user information. As described above, the collected data is not limited to healthcare data, but may also be user personal data including vital data such as heart rate, measurement data, or device history information such as the device operation history or the device manipulation history.

[0105] The user management unit 312 also manages user information of the acquired data. The user information is, for example, information about the user using the terminal 110, information about the family composition of the user including the user in the house 100, etc.

[0106] Furthermore, when the data management unit 311 receives a data provision request from a service server 400 that can access the first group to which the data server 300 belongs, it provides the user's data based on the consent information recorded in the distributed ledger of the authentication server 200. For example, assume that the authentication server 200 executes a smart contract generated based on the consent information, and the data server 300 receives a notification from the authentication server 200 indicating that the data can be provided. In this case, when the data management unit 311 receives a data provision request from the service server 400, it provides the user's data. Note that the data management unit 311 may also receive a blockchain address corresponding to the data to be provided from the service server 400 along with the data provision request.

[0107] For example, when a service server 410 that cannot access the first group but can access the second group requests authentication server 200a that belongs to the first group to provide data, data management unit 311 operates as follows: That is, data management unit 311 is controlled by authentication server 200a based on the consent information to transfer the user data recorded in recording unit 313 to, for example, data server 310 that belongs to the second group, or to make the data available for reference by data server 310. In this way, data management unit 311 is controlled by authentication server 200a based on the consent information to provide data to data server 310 that belongs to a different group, for example, the second group.

[0108] <Recording Unit 313> The recording unit 313 records data acquired from the device of the present disclosure, such as the house 100 or the terminal 110.

[0109] <Communications Department 314> The communication unit 314 communicates with the house 100, the terminal 110, the authentication server 200, and the service server 400 via the communication network 500. The communication unit 314 may also communicate with the data server 310 or the service server 400 via the communication network 500. These communications may be performed using TLS. In this case, the encryption key for the TLS communication may be held in the communication unit 314.

[0110] In this way, the data server 300 belonging to the first group records data acquired from the house 100 or the terminal 110. Furthermore, the data server 300 belonging to the first group provides data to the data server 310 belonging to a different group, the second group, under the control of the authentication server 200, such as a smart contract. Providing data includes transferring data and / or making the data available for reference, as described above.

[0111] In the present embodiment, the data server 300 and the authentication server 200 are described as independent servers, but this is not limiting. The functions of the data server 300 may be included in the authentication server 200 and may operate.

[0112] Next, an example of the configuration of the service servers 400 and 410 will be described.

[0113] [1.7 Configuration of the service server 400] The service servers 400 and 410 are servers managed by different service providers, and manage users and services provided by the service providers. The service providers are, for example, sports clubs. The service servers 400 and 410 each provide services by utilizing data acquired from each terminal 110 and / or house 100. In this embodiment, the service server 400 cannot access the second group but can access the first group, and can utilize data held by the data server 300 belonging to the first group. On the other hand, the service server 410 cannot access the first group but can access the second group, and can utilize data held by the data server 310 belonging to the second group.

[0114] Since the service servers 400 and 410 have the same configuration, the following description will be given taking the service server 400 as an example.

[0115] FIG. 8 is a block diagram showing an example of the configuration of service server 400 according to this embodiment.

[0116] 8, service server 400 includes service management unit 411, user management unit 412, transaction data generation unit 413, recording unit 414, and communication unit 415. Service server 400 can be realized by a processor using a memory to execute a predetermined program. Each component will be described below.

[0117] <Service Management Department 411> The service management unit 411 provides services by utilizing user information managed by the user management unit 412. For example, the service management unit 411 acquires data including measurement data such as the user's body composition measurement value or blood pressure measurement value from the data server 300, and provides new healthcare services or demonstrates their effectiveness.

[0118] The service management unit 411 uses user information managed by the user management unit 412 to generate a data acquisition request indicating a request to acquire data, and transmits the request to the transaction data generation unit 413. The service management unit 411, for example, determines what kind of data the user wants to acquire, and generates the data acquisition request based on the user's attribute information or the type of data to be acquired. The data acquisition request may include, for example, a request specifying the user's identifier if the user's identifier is known in advance, a request specifying a blockchain address, or a request specifying an attribute. The attribute here may be the type of device, such as the house 100 or the terminal 110, the type of data acquired from the device, or a user attribute.

[0119] Note that there may be cases where the data that the service management unit 411 desires to acquire is not recorded in the data server 300 belonging to the first group, but is recorded only in the data server 310 belonging to a second group different from the first group. In this case, the service management unit 411 transmits transaction data including a data acquisition request generated by the transaction data generation unit 413 to the authentication server 200 belonging to the first group and the authentication server 210 belonging to the second group via the communication unit 415. When the authentication server 210 belonging to the second group determines that it is OK to provide data to the data server 300, etc., of the first group, the data held by the data server 310 belonging to the second group is provided to the data server 300 belonging to the first group under the control of the authentication server 210. In this way, even when the data that the service management unit 411 desires to acquire is not recorded in the data server 300, but is recorded only in the data server 310, the data can be acquired from the data server 300 by providing it to the data server 300.

[0120] Furthermore, when the service management unit 411 acquires data, it generates information regarding an incentive payment or feedback provision to the user of the acquired data as consideration for the acquired data, and transmits the information to the transaction data generation unit 413. Here, the information regarding the incentive payment or feedback provision may include information indicating that virtual currency has been paid to the user's blockchain address as consideration for the acquired data. Note that the service management unit 411 may generate a smart contract based on the generated incentive payment or feedback provision. In this case, the smart contract may include, for example, a program for executing the payment of virtual currency to the user's blockchain address as consideration for the acquired data.

[0121] <User management unit 412> The user management unit 412 acquires information about users to whom the service is to be provided, and manages the acquired user information.

[0122] <Transaction Data Generation Unit 413> The transaction data generation unit 413 generates transaction data including the data acquisition request generated by the service management unit 411 .

[0123] Furthermore, the transaction data generation unit 413 generates transaction data including information regarding the incentive payment or feedback provision generated by the service management unit 411 .

[0124] The transaction data generation unit 413 may also generate transaction data including a smart contract based on the incentive payment or feedback provided by the service management unit 411.

[0125] <Recording Unit 414> The recording unit 414 records user information or service information required for providing a service. The recording unit 414 also records transaction data generated by the transaction data generation unit 413. The recording unit 414 may also record data acquisition requests, information related to incentive payments or feedback provision, and smart contracts generated by the service management unit 411.

[0126] <Communications Department 415> The communication unit 415 communicates with the authentication server 200 and the data server 300 via the communication network 500. This communication may be performed using TLS. In this case, the communication unit 415 may hold an encryption key for TLS communication.

[0127] [1.8 Overall sequence of data distribution system 10] Next, a description will be given of the overall sequence of the data distribution system 10. Figures 9A and 9B are overall sequence diagrams of the data distribution system 10 according to this embodiment. Each process will be described later.

[0128] 9A, in step S100, consent information registration processing is performed between terminal 110, house 100, and authentication servers 200a to 200c belonging to the first group. In Fig. 9A, consent information registration processing is performed between terminal 110 and authentication servers 200a to 200c belonging to the first group, for example.

[0129] Furthermore, in step S200, data registration processing is performed between the terminal 110, the residence 100, the authentication servers 200a to 200c belonging to the first group, and the data server 300. In Fig. 9A, for example, data registration processing is performed between the residence 100 and the authentication servers 200a to 200c belonging to the first group.

[0130] In step S300, data reference processing is performed between the terminal 110, the house 100, the authentication servers 200a to 200c, the data server 300, and the service server 400.

[0131] The data reference process in step S300 can be executed after the user's consent information is registered in the consent information registration process in step S100. In Fig. 9A, the data reference process is performed between the terminal 110, the authentication servers 200a to 200c, the data server 300, and the service server 400, for example.

[0132] 9B, in step S500, a data providing process is performed between the terminal 110, the service server 400, the authentication server 200 and the data server 300 belonging to the first group, and the authentication server 210 and the data server 310 belonging to the second group. The data providing process in step S500 can be executed after the user data is registered in the data registration process in step S200. In the data providing process described below, a case will be described in which data from the data server 300 belonging to the first group is provided to the data server 310 belonging to the second group.

[0133] [1.8.1 Consent information registration process] Next, the consent information registration process between the terminal 110 and the authentication servers 200a to 200c will be described.

[0134] Fig. 10 is a sequence diagram showing consent information registration processing between terminal 110 and authentication servers 200a to 200c according to this embodiment. Although Fig. 10 shows a case where terminal 110 registers consent information, the same processing is performed when controller 101 of house 100 registers consent information. Furthermore, Fig. 10 shows consent information registration processing between terminal 110 and authentication servers 200a to 200c belonging to the first group, but this is not limiting. The same processing is performed when consent information registration processing is performed between house 100 and authentication servers 210a to 210c belonging to the second group.

[0135] First, terminal 110 generates consent information based on a user operation (S101). Here, an application may be installed in terminal 110 as input unit 1013, and the application may generate consent information based on a user operation. In this case, the user can cause terminal 110 to generate consent information simply by instructing whether to select or deselect from a list of service providers to which data is provided or a list of data provided by input unit 1013.

[0136] When the user generates consent information in terminal 110, the user may generate the consent information after determining whether there is a lot of feedback from the service provider. For example, the user may decide which data provider to select (i.e., consent to data provision) based on the content of the feedback, such as that virtual currency will be provided or that a coupon or discount from the service provider will be provided if the user provides data to the service provider. Furthermore, the user may decide which data provider to select (i.e., consent to data provision) based on the content of the feedback to the user, such as the amount of virtual currency or the amount of the coupon or discount to be provided if the user provides data to the service provider. The content of the feedback may be made public by the service provider or may be recorded in the blockchain of authentication server 200.

[0137] Next, the terminal 110 generates a smart contract based on the consent information generated in step S101 (S102). This smart contract is an executable program that determines whether data can be provided. This smart contract may include the consent information generated in step S101. Furthermore, this smart contract may include an executable program that determines whether to provide the data when the feedback is equal to or greater than a certain level.

[0138] Next, the terminal 110 generates transaction data including the generated consent information and the smart contract (S103).

[0139] Next, terminal 110 transmits the transaction data generated in step S103 to authentication server 200a (S104). Note that in the example shown in Fig. 10, terminal 110 transmits the generated transaction data to authentication server 200a, but it may also transmit it to authentication servers 200b and 200c. The same applies when transmitting it to authentication servers 200b and 200c.

[0140] Next, when authentication server 200a acquires transaction data from terminal 110 (S105), it verifies the acquired transaction data (S106).

[0141] In step S106, if the verification of the transaction data is not successful (N in S106), authentication server 200a sends a notification to that effect to terminal 110 (S107).

[0142] On the other hand, if the verification of the transaction data is successful in step S106 (Y in S106), the authentication server 200a transfers the transaction data to other authentication servers 200 (authentication servers 200b, 200c) (S108). The other authentication servers 200 also verify the transferred transaction data.

[0143] Next, authentication server 200a, authentication server 200b, and authentication server 200c execute a consensus algorithm (S109). When authentication server 200a, authentication server 200b, and authentication server 200c verify that the transaction data is legitimate (i.e., validity), they each generate a block containing the transaction data. Then, authentication servers 200a, 200b, and 200c record the block containing the transaction data in the distributed ledger.

[0144] In this way, the smart contract created by terminal 110 and the consent information are recorded in the distributed ledger.

[0145] Then, the smart contract becomes executable, i.e., it runs, by being recorded in the distributed ledger (S110). Note that by being recorded in the distributed ledger, the smart contract is stored in the working memory of the authentication server 200a, etc., and therefore becomes executable.

[0146] [1.8.2 Data registration process] Next, the data registration process between the house 100, the authentication servers 200a to 200c, and the data server 300 will be described.

[0147] Fig. 11 is a sequence diagram showing data registration processing between the house 100, the authentication servers 200a-200c, and the data server 300 according to this embodiment. While Fig. 11 illustrates a case where data acquired by the house 100 is registered in the data server 300, the same processing is performed when data acquired by the terminal 110 is registered. Fig. 11 also illustrates data registration processing between the house 100 and the authentication servers 200a-200c and data server 300 belonging to the first group, but this is not limiting. The same processing is performed when data registration processing is performed between the house 100 and the authentication servers 210a-210c and data server 310 belonging to the second group.

[0148] First, the house 100 acquires data obtained by the home appliances and the like of the house 100 (S201). The data acquired by the house 100 may be, for example, the operation history of the home appliances, the amount of power generated by the solar power generation device 102, or power amount data output by the storage battery 103. The data acquired by the house 100 may also be the operation history of the air conditioner 104, or vital sign data measured by the body composition monitor 105 and / or the blood pressure monitor 106. In other words, the data may be any data that is acquired by the house 100 and that can be utilized by the service provider.

[0149] Next, the house 100 generates transaction data for data registration including information about the data acquired in step S201 (S202). The information about the data here is, for example, the hash value of the data and attribute information of the data. In this case, the transaction data includes the blockchain address, the hash value, the attribute information, and the signature.

[0150] Next, the house 100 transmits the data acquired in step S201 to the authentication server 200a and the transaction data generated in step S202 to the data server 300 (S203). Note that in the example shown in Fig. 11, the house 100 transmits the transaction data acquired in step S201 to the authentication server 200a, but it may also transmit it to the authentication servers 200b and 200c. The same applies when transmitting it to the authentication servers 200b and 200c.

[0151] Next, when the data server 300 acquires data from the house 100 (S204), the data server 300 records the data acquired in step S204 (S205).

[0152] Next, when the authentication server 200a acquires the transaction data from the house 100 (S206), it verifies the acquired transaction data (S207). Note that the order of steps S204 and S206 may be changed.

[0153] If the verification of the transaction data is not successful in step S207 (N in S207), the authentication server 200a sends a notification to that effect to the house 100 (S208). Note that the authentication server 200a is not limited to notifying the house 100 of this effect, and may also notify the data server 300 of this effect. Furthermore, in this case, the data server 300 may delete the data recorded in step S205.

[0154] On the other hand, if the verification of the transaction data is successful in step S207 (Y in S207), the authentication server 200a transfers the transaction data to other authentication servers 200 (authentication servers 200b, 200c) (S209). The other authentication servers 200 also verify the transferred transaction data.

[0155] Next, authentication server 200a, authentication server 200b, and authentication server 200c execute a consensus algorithm (S210). When authentication server 200a, authentication server 200b, and authentication server 200c verify that the transaction data is legitimate (i.e., validity), they each generate a block containing the transaction data. Then, authentication servers 200a, 200b, and 200c record the block containing the transaction data in the distributed ledger.

[0156] In this way, a block containing transaction data for data registration, including information about the data, is recorded in the distributed ledger, and the data itself is recorded in the data server 300.

[0157] [1.8.3 Data Reference Processing] Next, the data reference process between the terminal 110, the authentication servers 200a to 200c, the data server 300, and the service server 400 will be described.

[0158] 12A and 12B are sequence diagrams showing data reference processing between terminal 110, authentication servers 200a-200c, data server 300, and service server 400 according to this embodiment. In the example shown in FIGS. 12A and 12B, a case will be described in which service server 400 acquires data from data server 300. Note that the same processing is performed when data reference processing is performed between terminal 110, service server 410, and authentication servers 210a-210c and data server 310 belonging to the second group. In other words, the same is true when service server 410 acquires data from data server 310.

[0159] First, in FIG. 12A, when service server 400 determines what kind of data the user wants to acquire, it decides to make a request to acquire the data (S301).

[0160] Next, the service server 400 generates a data acquisition request indicating a request to acquire data, and generates transaction data for the data acquisition request including the data acquisition request (S302).

[0161] Next, service server 400 transmits the generated transaction data to authentication server 200c (S303). In the example shown in Fig. 12A, service server 400 transmits the transaction data generated in step S302 to authentication server 200c, but it may also transmit it to authentication servers 200a and 200b. The same applies when transmitting it to authentication servers 200a and 200b.

[0162] Next, when authentication server 200c acquires the transaction data from service server 400 (S304), it verifies the acquired transaction data (S305).

[0163] In step S305, if the verification of the transaction data is not successful (N in S305), the authentication server 200c sends a notification to that effect to the service server 400 (S306).

[0164] On the other hand, if the verification of the transaction data is successful in step S305 (Y in S305), the authentication server 200c transfers the transaction data to the other authentication servers 200 (authentication servers 200a and 200b) (S307). The other authentication servers 200 also verify the transferred transaction data.

[0165] Next, authentication server 200a, authentication server 200b, and authentication server 200c execute a consensus algorithm (S308). When authentication server 200a, authentication server 200b, and authentication server 200c verify that the transaction data is legitimate (i.e., validity), they each generate a block containing the transaction data. Then, authentication servers 200a, 200b, and 200c record the block containing the transaction data in the distributed ledger.

[0166] Next, authentication server 200a, authentication server 200b, and authentication server 200c execute the smart contract recorded in the distributed ledger (S309). This smart contract was generated based on the consent information, and by being recorded in the distributed ledger, it is stored in the working memory and is executable. Then, the smart contract executed by authentication server 200 determines whether the requested data can be provided to service server 400 based on the consent information. The smart contract sends a notification of the determination result to data server 300 and service server 400 (S310). Note that the smart contract is not limited to sending a notification of the determination result to data server 300 and service server 400. The smart contract may also notify terminal 110 used by the user that the requested data can be provided to service server 400.

[0167] Next, the data server 300 and the service server 400 receive the notification sent in step S310 (S311). Here, it is assumed that the notification sent in step S310 indicates that the service server 400 is able to provide the requested data.

[0168] Next, the service server 400 requests the data server 300 to provide data (S312). Note that the service server 400 may access the data server 300 to obtain the data provided.

[0169] Next, when the data server 300 receives a request to provide data from the service server 400 (S313), it checks the notification received from the authentication server 200c in step S311 and determines whether it is possible to provide the requested data to the service server 400 (S314). In step S314, the data server 300 checks the notification received from the authentication server 200c in step S311, and if it determines that it is not possible to provide the requested data to the service server 400 (N in S314), it sends a notification to that effect to the service server 400 (S315).

[0170] In step S314, the data server 300 checks the notification received from the authentication server 200 in step S311, and if it determines that the requested data can be provided to the service server 400 (Y in S314), it provides the requested data to the service server 400 (S316).

[0171] Next, the service server 400 acquires the requested data (S317).

[0172] Then, the service server 400 generates transaction data for the incentive payment (S318). More specifically, the service server 400 generates transaction data including information related to the incentive payment.

[0173] Next, service server 400 transmits the transaction data generated in step S318 to authentication server 200c (S319). Note that in the example shown in Fig. 12B, service server 400 transmits the generated transaction data to authentication server 200c, but it may also transmit it to authentication servers 200a and 200b. The same applies when transmitting it to authentication servers 200a and 200b.

[0174] Next, when authentication server 200c acquires transaction data from service server 400 (S320), it verifies the acquired transaction data (S321).

[0175] In step S321, if the verification of the transaction data is not successful (N in S321), the authentication server 200c sends a notification to that effect to the service server 400 (S322).

[0176] On the other hand, if the verification of the transaction data is successful in step S321 (Y in S321), the authentication server 200c transfers the transaction data to the other authentication servers 200 (authentication servers 200a, 200b) (S323). The other authentication servers 200 also verify the transferred transaction data.

[0177] Next, authentication server 200a, authentication server 200b, and authentication server 200c execute a consensus algorithm (S324). When authentication server 200a, authentication server 200b, and authentication server 200c verify that the transaction data is legitimate (i.e., validity), they each generate a block containing the transaction data. Then, authentication servers 200a, 200b, and 200c record the block containing the transaction data in the distributed ledger.

[0178] Next, authentication server 200a, authentication server 200b, and authentication server 200c execute the smart contract for incentive payment recorded in the distributed ledger (S325). This smart contract is generated based on the incentive payment, and by being recorded in the distributed ledger, it is stored in the working memory and becomes executable. In this embodiment, the smart contract for incentive payment may make an incentive payment to the user.

[0179] Then, for example, the smart contract of the authentication server 200a transmits an incentive notification to the user (specifically, the terminal 110) indicating that the incentive payment has been made (S326).

[0180] Note that the service server 400 may generate transaction data including information related to providing feedback in step S318. In this case, a smart contract related to providing feedback is executed in step S325.

[0181] In this way, data reference processing is performed between terminal 110, authentication servers 200a to 200c, data server 300, and service server 400, and then incentive payment processing is performed.

[0182] 12A, the smart contract executed by the authentication server 200 transmits the determination result to the data server 300 and the service server 400 in step S310, but this is not limiting. The smart contract executed by the authentication server 200 may also transmit a notification to the user, i.e., the terminal 110, in step S310, that the service server 400 will acquire the data.

[0183] 12A, in steps S311 and S312, the service server 400 receives the determination result of the smart contract executed by the authentication server 200, and then requests the provision of data and acquires the data, but this is not limited to this. In step S309, the smart contract executed by the authentication server 200 may provide the service server 400 with data recorded in the data server 300 and requested to be provided by the service server 400.

[0184] [1.8.4 Smart contract registration process for incentive payments] Next, a smart contract registration process regarding incentive payments between the authentication servers 200a to 200c and the service server 400 will be described.

[0185] Fig. 13 is a sequence diagram showing the smart contract registration process for incentive payment between the authentication servers 200a to 200c and the service server 400 according to this embodiment. Fig. 13 shows an example in which the smart contract registration process is performed between the service server 400 and the authentication servers 200a to 200c belonging to the first group, but this is not limiting. The same process is performed when consent information registration process is performed between the service server 410 and the authentication servers 210a to 210c belonging to the second group.

[0186] First, the service server 400 generates a smart contract for incentive payments (S401).

[0187] Next, the service server 400 generates transaction data for the smart contract registration, including the smart contract related to the incentive payment generated in step S401 (S402).

[0188] Next, service server 400 transmits the transaction data generated in step S402 to authentication server 200a (S403). In the example shown in Fig. 13, service server 400 transmits the transaction data generated in step S402 to authentication server 200a, but it may also transmit the data to authentication servers 200b and 200c. The same applies when the data is transmitted to authentication servers 200b and 200c.

[0189] Next, when authentication server 200a acquires the transaction data from service server 400 (S404), it verifies the acquired transaction data (S405).

[0190] In step S405, if the verification of the transaction data is not successful (N in S405), the authentication server 200a sends a notification to that effect to the service server 400 (S406).

[0191] On the other hand, if the verification of the transaction data is successful in step S405 (Y in S405), the authentication server 200a transfers the transaction data to other authentication servers 200 (authentication servers 200b, 200c) (S407). The other authentication servers 200 also verify the transferred transaction data.

[0192] Next, authentication server 200a, authentication server 200b, and authentication server 200c execute a consensus algorithm (S408). When authentication server 200a, authentication server 200b, and authentication server 200c verify that the transaction data is legitimate (i.e., validity), they each generate a block containing the transaction data. Then, authentication servers 200a, 200b, and 200c record the block containing the transaction data in the distributed ledger.

[0193] Next, the smart contract for incentive payment included in the transaction data is recorded in the distributed ledger, whereby it becomes executable, i.e., it is put into operation (S409). By being recorded in the distributed ledger, the smart contract for incentive payment is stored in the working memory of the authentication server 200a, etc., and thus becomes executable.

[0194] [1.8.5 Example of data provision processing] Next, a data providing process between the terminal 110, the service server 400, the authentication server 200 and the data server 300 belonging to the first group, and the authentication server 210 and the data server 310 belonging to the second group will be described.

[0195] 14A and 14B are sequence diagrams showing an example of data provision processing in the data distribution system according to this embodiment. In the example shown in FIGS. 14A and 14B, it is assumed that the data that service server 410 wants to acquire is not in data server 310 that service server 410 can access, but in data server 300 that service server 410 cannot access. A case will be described in which data is provided from data server 300 to data server 310 based on a data acquisition request from service server 410. A specific use case is when service server 410 of a service provider requests data server 310 to provide data of terminal 110 that is recorded on data server 300, and uses the data from data server 310 for a service. The same processing is also performed when data is provided from data server 310 to data server 300 based on a data acquisition request from service server 400.

[0196] 14A, in order to acquire user data, service server 410 generates and transmits a data acquisition request to terminal 110 that has registered data in data server 300 (S501). The data acquisition request indicates, for example, a request to acquire or refer to data on terminal 110. Note that service server 410 transmits the data acquisition request directly to terminal 110, but may also transmit the request via email or another service provider.

[0197] Next, upon receiving the request transmitted in step S501, terminal 110 generates consent information based on the request received by terminal 110 (S502). Here, an application may be installed in terminal 110 as input unit 1013, and the application may generate consent information based on the request in response to a user operation. For example, the user can select available data by simply instructing whether to select or deselect from a list of data recorded in data server 300, which is the data recipient. This allows terminal 110 to generate consent information regarding data utilization, indicating that the data requested for data acquisition can be provided with the user's consent.

[0198] Next, the terminal 110 generates a smart contract based on the consent information generated in step S502 (S503). This smart contract is an executable program that determines whether data can be provided based on the consent information.

[0199] Next, the terminal 110 generates transaction data for smart contract registration, including the generated consent information and smart contract (S504).

[0200] Next, terminal 110 transmits the transaction data generated in step S504 to authentication server 200a (S505). Note that in the example shown in Fig. 14A, terminal 110 transmits the generated transaction data to authentication server 200a, but it may also transmit it to authentication servers 200b and 200c. The same applies when transmitting it to authentication servers 200b and 200c.

[0201] Next, when authentication server 200a acquires transaction data from terminal 110 (S506), it verifies the acquired transaction data (S507).

[0202] In step S507, if the verification of the transaction data is not successful (N in S507), authentication server 200a sends a notification to that effect to terminal 110 (S508).

[0203] On the other hand, if the verification of the transaction data is successful in step S507 (Y in S507), the authentication server 200a transfers the transaction data to other authentication servers 200 (authentication servers 200b, 200c) (S509). The other authentication servers 200 also verify the transferred transaction data.

[0204] Next, authentication server 200a, authentication server 200b, and authentication server 200c execute a consensus algorithm (S510). When authentication server 200a, authentication server 200b, and authentication server 200c verify that the transaction data is legitimate (i.e., validity), they each generate a block containing the transaction data. Then, authentication servers 200a, 200b, and 200c record the block containing the transaction data in the distributed ledger. In this way, the smart contract created by terminal 110 is recorded in the distributed ledger.

[0205] Next, the smart contract is recorded in the distributed ledger, whereby it becomes executable, i.e., it runs (S511). Note that by recording the smart contract in the distributed ledger, it is stored in the working memory of the authentication server 200a, etc., and thus becomes executable.

[0206] Next, the terminal 110 generates first transaction data including the data acquisition request based on the data acquisition request transmitted in step S501 and the consent information generated in step S502 (S512). Specifically, the terminal 110 generates the first transaction data including the data acquisition request and consent for data provision from the data server 300 to the data server 310. Here, as described above, an application is installed in the terminal 110 as the input unit 1013. Therefore, after generating the consent information in step S502, the application simply needs to confirm the execution of the smart contract in step S501. This allows the application to generate first transaction data including the data acquisition request and consent for data provision from the data server 300 to the data server 310.

[0207] Next, terminal 110 transmits the first transaction data generated in step S512 to authentication server 200a belonging to the first group and authentication server 210a belonging to the second group (S513). Note that authentication server 200a is an example of one of the multiple first authentication servers belonging to the first group, and authentication server 210a is an example of one of the multiple second authentication servers belonging to the second group.

[0208] Next, when authentication server 210a belonging to the second group acquires the first transaction data from terminal 110 (S514), it verifies the acquired first transaction data (S515).

[0209] In step S515, if the verification of the first transaction data is not successful (N in S515), authentication server 210a sends a notification to that effect to terminal 110 (S516).

[0210] On the other hand, if the verification of the first transaction data is successful in step S515 (Y in S515), the authentication server 210a transfers the first transaction data to the other authentication servers 210 (authentication servers 210b, 210c) belonging to the second group (S517). The other authentication servers 210 also verify the transferred first transaction data.

[0211] Next, authentication server 210a, authentication server 210b, and authentication server 210c execute a consensus algorithm (S518). When authentication server 210a, authentication server 210b, and authentication server 210c verify that the first transaction data is legitimate transaction data (i.e., legitimacy), they each generate a block including the first transaction data. Then, authentication servers 210a, 210b, and 210c record the block including the first transaction data in the distributed ledger. In this way, the first transaction data is recorded in the distributed ledger belonging to the second group.

[0212] Furthermore, when authentication server 200a belonging to the first group acquires the first transaction data from terminal 110 (S519), it verifies the acquired first transaction data (S520).

[0213] In step S520, if the verification of the first transaction data is not successful (N in S520), authentication server 200a sends a notification to that effect to terminal 110 (S521).

[0214] On the other hand, if the verification of the first transaction data is successful in step S520 (Y in S520), the authentication server 200a transfers the first transaction data to the other authentication servers 200 (authentication servers 200b, 200c) belonging to the first group (S522). The other authentication servers 200 also verify the transferred first transaction data.

[0215] Next, authentication server 200a, authentication server 200b, and authentication server 200c execute a consensus algorithm (S523). When authentication server 200a, authentication server 200b, and authentication server 200c verify that the first transaction data is legitimate transaction data (i.e., legitimacy), they each generate a block including the first transaction data. Then, authentication servers 200a, 200b, and 200c record the block including the first transaction data in the distributed ledger. In this way, the first transaction data is recorded in the distributed ledger belonging to the first group.

[0216] Next, for example, the authentication server 200c executes the smart contract made executable in step S511 based on the first transaction data recorded in the distributed ledger (S524). The executed smart contract sends a notification to the data server 300 that the specified data can be provided to the data server 310 (S525). Note that the notification only needs to include information about the data to be provided and the recipient. This allows the data server 300 to transfer its own data to the data server 310 or make the data server 310 accessible. Making the data server 310 accessible also includes cases where the data server 310 records access information to the data server 300 and accesses the data server 300 to obtain the data when using the data.

[0217] Next, when the data server 300 receives a notification from the authentication server 200c (S526), it provides data to the data server 310 based on the received notification (S527). Note that the data server 300 may provide the data to the data server 310 by transferring the data specified in the notification to the data server 310 or by making the data server 310 accessible to the data server 310. Here, it is assumed that the data server 300 transfers the data specified in the notification to the data server 310.

[0218] Next, the data server 310 records the data provided by the data server 300 (S528).

[0219] When the data is provided in step S527, service server 410 may make an incentive payment to terminal 110. The incentive payment process is similar to the process described in steps S317 to S326, and therefore will not be described here.

[0220] As described above, even if the data that service server 410 wants to acquire is not on a data server 310 that service server 410 can access, but on a data server 300 that service server 410 cannot access, data can still be provided from data server 300 to data server 310. Therefore, the data distribution system according to the embodiment enables data linkage between different groups. Furthermore, since the fact that data has been transferred or made accessible is recorded in both a distributed ledger belonging to the data provider's group and a distributed ledger belonging to a group different from the data recipient's group, data can be utilized while ensuring data traceability.

[0221] [1.8.6 Another example of data provision processing] 14A and 14B, the terminal 110 generates a smart contract for data provision after receiving a data provision request from the service server 410, but this is not limiting. The terminal 110 may generate and execute a smart contract for data provision in advance. In this case, when first transaction data that satisfies the condition for not providing data set forth in the smart contract is recorded in the distributed ledger, the smart contract may be executed to automatically provide the data to be provided.

[0222] This case will be explained below with reference to the drawings.

[0223] Figures 15A to 15C are sequence diagrams showing another example of the data provision processing in the data distribution system according to this embodiment. Similar to Figures 14A and 14B, Figures 15A to 15C show another example of the data provision processing between terminal 110, service server 400, authentication server 200 and data server 300 belonging to the first group, and authentication server 210 and data server 310 belonging to the second group. In the example shown in Figures 15A to 15C, it is assumed that the data that service server 410 wants to acquire is not in a data server 310 that service server 410 can access, but in a data server 300 that service server 410 cannot access.

[0224] First, the terminal 110 generates consent information based on a user operation (S551). Here, an application may be installed in the terminal 110 as the input unit 1013, and the application may generate consent information based on a user operation.

[0225] Next, the terminal 110 generates a smart contract based on the consent information generated in step S551 (S552). This smart contract is an executable program that determines whether data can be provided based on the consent information.

[0226] Next, the terminal 110 generates transaction data for smart contract registration, including the generated consent information and smart contract (S553).

[0227] The subsequent processing of steps S554 to S560 is the same as the processing of steps S505 to S511 described above, and therefore a description thereof will be omitted.

[0228] Next, in FIG. 15B, when service server 410 determines what kind of data the user wants to acquire, it decides to make a request to acquire the data (S570).

[0229] Next, the service server 410 generates a data acquisition request indicating that it is requesting data acquisition, and generates first transaction data of the data acquisition request including the data acquisition request (S571).

[0230] Next, service server 410 transmits the first transaction data generated in step S571 to authentication server 210c belonging to the second group and authentication server 200c belonging to the first group (S572). Here, authentication server 200c is an example of one of the multiple first authentication servers belonging to the first group, and authentication server 210c is an example of one of the multiple second authentication servers belonging to the second group. Furthermore, the data that service server 410 wants to acquire is not in data server 310 that service server 410 can access, but in data server 300 that service server 410 cannot access. Therefore, service server 410 transmits the first transaction data generated in step S571 to authentication server 210c and authentication server 200c.

[0231] The subsequent processing of steps S573 to S578 is the same as the processing of steps S514 to S518 described above, except that the processing is performed by authentication server 210c instead of authentication server 210a, and therefore a description thereof will be omitted.

[0232] Next, when authentication server 200c acquires the first transaction data from service server 410 (S579), authentication server 200c verifies the acquired first transaction data (S580).

[0233] In step S580, as shown in FIG. 15C, if the verification of the first transaction data is not successful (N in S580), the authentication server 200c sends a notification to that effect to the data server 310 (S581).

[0234] On the other hand, if the verification of the first transaction data is successful in step S580 (Y in S580), the authentication server 200c transfers the first transaction data to the other authentication servers 200 (authentication servers 200a, 200b) belonging to the first group (S582). The other authentication servers 200 also verify the transferred first transaction data.

[0235] The subsequent processing of steps S583 to S588 is the same as the processing of steps S523 to S528 described above, and therefore a description thereof will be omitted.

[0236] 15A, the user generates consent information at any timing by operating the terminal 110, but this is not limited to this. The user may also generate consent information periodically or irregularly by operating the terminal 110.

[0237] Furthermore, the user may generate consent information when a new service provider is added, or when new incentives or feedback are added from a service provider. In this case, if the details of the newly added service provider or the newly added incentives or feedback are presented to the terminal 110, the user can generate new consent information based on the presented details. This increases the opportunities for the user to provide data for the utilization of data from the terminal 110 and the house 100.

[0238] [1.9 Effects of the embodiment] As described above, according to the data distribution method, program, and data distribution system of this embodiment, data can be utilized while ensuring data traceability.

[0239] For example, even if the data that the service server 410 wants to obtain is not in a data server 310 that the service server 410 can access, but in a data server 300 that the service server 410 cannot access, the data can still be provided to the data server 310 from the data server 300.

[0240] That is, according to this embodiment, information collected from the homes 100 and terminals 110 owned by a data server belonging to one group can be safely provided to a data server belonging to another group with the user's consent. This allows multiple service providers to utilize user information. Therefore, according to this embodiment, it is possible to realize a data distribution method or the like that enables data linkage between different groups.

[0241] Furthermore, according to this embodiment, the fact that data has been transferred or made accessible is recorded in both the distributed ledger belonging to the data provider's group and the distributed ledger belonging to a group different from the data recipient's group. In this way, by utilizing blockchain technology, data belonging to different groups can be linked while ensuring data traceability. In other words, data can be utilized while ensuring data traceability. Therefore, users can provide data with peace of mind.

[0242] Furthermore, according to this embodiment, data can be provided between different data servers in a group based on consent information generated by the house 100 or the terminal 110. This makes it possible to utilize data such as user history information while restricting the distribution of user data. Furthermore, according to this embodiment, user consent information can be securely recorded in a distributed ledger using blockchain technology.

[0243] [2. Other Modifications] Although the present disclosure has been described based on the above-described embodiments, it goes without saying that the present disclosure is not limited to the above-described embodiments. The following cases are also included in the present disclosure.

[0244] (1) In the above embodiment, the authentication servers 200 and 210 and the data servers 300 and 310 are described as separate devices, but this is not limiting. The authentication server 200 and the data server 300, and the authentication server 210 and the data server 310 may be the same device.

[0245] (2) In the above embodiment, the data servers 300, 310 and the service servers 400, 410 are described as separate devices, but this is not limiting. The data server 300 and the service server 400, and the data server 310 and the service server 410 may be the same device.

[0246] (3) In the above embodiment, the user operates the terminal 110 or the controller 101 of the house 100 to generate consent information based on incentives and / or feedback, but this is not limited to this. The user may generate consent information based on the amount of user data handled by the service provider or the number of services linked to the service provider. This may not only increase the utilization of data but also increase the number of services the service provider offers to users or the incentives the service provider pays. Furthermore, the incentives and / or feedback may be recorded in the authentication servers 200 and 210.

[0247] (4) Each device in the above embodiments is specifically a computer system comprising a microprocessor, ROM, RAM, hard disk unit, display unit, keyboard, mouse, etc. A computer program is recorded in the RAM or hard disk unit. Each device achieves its function by the microprocessor operating in accordance with the computer program. Here, the computer program is composed of a combination of multiple instruction codes that indicate commands to a computer to achieve a predetermined function.

[0248] (5) In each of the above embodiments, some or all of the constituent elements may be configured from a single system LSI (Large Scale Integration). A system LSI is an ultra-multifunctional LSI manufactured by integrating multiple components on a single chip, and specifically, is a computer system configured to include a microprocessor, ROM, RAM, etc. A computer program is recorded in the RAM. The system LSI achieves its functions when the microprocessor operates in accordance with the computer program.

[0249] Furthermore, each of the components constituting each of the above devices may be individually integrated into a single chip, or some or all of them may be integrated into a single chip.

[0250] Although we refer to it as a system LSI here, it may also be called an IC, LSI, super LSI, or ultra LSI depending on the level of integration. Furthermore, the method of integration is not limited to LSI; it can also be realized using dedicated circuits or general-purpose processors. It is also possible to use FPGAs (Field Programmable Gate Arrays), which can be programmed after LSI manufacturing, or reconfigurable processors, which allow the connections and settings of circuit cells within LSI to be reconfigured.

[0251] Furthermore, if an integrated circuit technology that can replace LSI emerges due to advances in semiconductor technology or other derivative technologies, it is natural that such technology can be used to integrate functional blocks. The application of biotechnology is also a possibility.

[0252] (6) Some or all of the components constituting each of the above devices may be configured as an IC card or a standalone module that can be attached to each device. The IC card or module is a computer system composed of a microprocessor, ROM, RAM, etc. The IC card or module may include the above-mentioned ultra-multifunctional LSI. The IC card or module achieves its functions when the microprocessor operates according to a computer program. The IC card or module may be tamper-resistant.

[0253] (7) The present disclosure may be embodied as the methods described above, a computer program for implementing these methods on a computer, or a digital signal comprising the computer program.

[0254] The present disclosure may also be the computer program or the digital signal recorded on a computer-readable recording medium, such as a flexible disk, hard disk, CD-ROM, MO, DVD, DVD-ROM, DVD-RAM, BD (Blu-ray Disc (registered trademark)), semiconductor memory, etc. Alternatively, the present disclosure may be the digital signal recorded on such a recording medium.

[0255] Furthermore, the present disclosure may involve transmitting the computer program or the digital signal via a telecommunications line, a wireless or wired communication line, a network such as the Internet, data broadcasting, or the like.

[0256] The present disclosure may also be directed to a computer system having a microprocessor and a memory, the memory storing the computer program, and the microprocessor operating in accordance with the computer program.

[0257] The program or the digital signal may also be implemented by another independent computer system by recording it on the recording medium and transferring it, or by transferring it via the network or the like.

[0258] (8) The above-described embodiments and modifications may be combined with each other. [Industrial Applicability]

[0259] The present disclosure can be used in a data distribution method, a program, and a data distribution system, and can be used in a data distribution method, a program, and a data distribution system that, for example, enables data to be referenced or transferred between different groups based on user consent information, thereby promoting the utilization of data. [Explanation of symbols]

[0260] 10 Data Distribution System 100 Housing 101 Controller 102 Solar power generation equipment 103 Storage battery 104 Air Conditioner 105 Body Composition Monitor 106 Blood Pressure Monitor 110 Terminal 200, 200a, 200b, 200c, 210, 210a, 210b, 210c Authentication Server 211 Transaction Data Verification Department 212 Block Generation Unit 213 Synchronization Unit 214 Smart Contract Execution Unit 215, 313, 414, 1014, 1104 Recording section 216, 314, 415, 1015, 1105 Communications Department 300, 310 Data Server 311 Data Management Department 312, 412 User Management Department 400, 410 Service Server 411 Service Management Department 413, 1012, 1101 Transaction data generation unit 500 Communication Network 1011 Control unit 1013, 1102 Input section 1103 Data Acquisition Unit

Claims

1. A data distribution method in a data distribution system, comprising: The data distribution system includes: a first data server, one or more first servers having a first distributed ledger, a second data server different from the first data server, and one or more second servers having a second distributed ledger; The one or more first servers acquiring, from a device, first transaction data including a data acquisition request indicating a request to acquire or refer to device data held by the first data server; transmitting a notification to the first data server to cause the data of the device held by the first data server to be transferred to the second data server or to make the data available for reference by the second data server; The first data server In response to receiving the notification, the data of the device held by the first data server is transferred to the second data server without being converted into the data of the device, or the data is made available for reference by the second data server. Data distribution methods.

2. the data distribution system further includes a service server that is the device; In the data distribution method, the service server generates the first transaction data and transmits it to the one or more first servers and the one or more second servers; When the one or more first servers acquire the first transaction data, The one or more first servers, determining whether the data can be provided from the first data server to the second data server based on consent information regarding the utilization of the data obtained from the device; causing the first data server to transfer the data of the device held by the first data server to the second data server or to make the data available for reference by the second data server; The data distribution method according to claim 1 .

3. moreover, When the service server confirms that the first data server has transferred the data of the device to the second data server or made the data of the device accessible by the second data server, the service server generates second transaction data for issuing a token to the device; the one or more first servers acquire the second transaction data; the one or more first servers record a block including the second transaction data in the first distributed ledger; the one or more first servers operate a smart contract that is executable and programmed to issue tokens based on the recorded second transaction data, thereby causing the smart contract to issue tokens to the device; The data distribution method according to claim 2 .

4. The one or more first servers acquire a smart contract that is executable and programmed to determine whether the data can be provided based on the consent information; When the one or more first servers acquire the first transaction data, if it is determined that the data can be provided from the first data server to the second data server by executing the smart contract based on the acquired first transaction data, the first data server transfers the device data held by the first data server to the second data server or makes the data available for reference by the second data server; 4. The data distribution method according to claim 2 or 3.

5. A program for causing a computer to execute a data distribution method in a data distribution system, The data distribution system includes: a first data server, one or more first servers having a first distributed ledger, a second data server different from the first data server, and one or more second servers having a second distributed ledger; The one or more first servers acquiring, from a device, first transaction data including a data acquisition request indicating a request to acquire or refer to device data held by the first data server; transmitting a notification to the first data server to cause the data of the device held by the first data server to be transferred to the second data server or to make the data available for reference by the second data server; The first data server In response to receiving the notification, the data of the device held by the first data server is transferred to the second data server without being converted into the data of the device, or the data is made available for reference by the second data server. A program that makes a computer do something.

6. A data distribution system, The data distribution system includes: a first data server, one or more first servers having a first distributed ledger, a second data server different from the first data server, and one or more second servers having a second distributed ledger; The one or more first servers acquiring, from a device, first transaction data including a data acquisition request indicating a request to acquire or refer to device data held by the first data server; a first communication unit that causes the first data server to transfer the device data held by the first data server to the second data server, or transmits a notification to the first data server to make the device data accessible by the second data server; The first data server In response to receiving the notification, the data of the device held by the first data server is transferred to the second data server without being converted into the data of the device, or the data is made available for reference by the second data server. Data distribution system.

7. the data acquisition request is a request to allow the one or more second servers different from the one or more first servers to acquire or make reference to data of the device; The data distribution method according to claim 1 .

8. The data of the device is recorded in the first distributed ledger. The data distribution method according to claim 1 .

9. the one or more first servers record a block including the first transaction data in the first distributed ledger; the one or more second servers acquire the first transaction data, and one second server among the one or more second servers records a block including the acquired first transaction data in the second distributed ledger; The data distribution method according to claim 1 .

10. the device is a device that cannot acquire the data from the first data server but can acquire the data from the second data server, The equipment data is provided to the device from the second data server. The data distribution method according to claim 1 .

Images