WO2021132159A1 - データ流通方法、プログラム及びデータ流通システム - Google Patents

データ流通方法、プログラム及びデータ流通システム Download PDF

Info

Publication number
WO2021132159A1
WO2021132159A1 PCT/JP2020/047681 JP2020047681W WO2021132159A1 WO 2021132159 A1 WO2021132159 A1 WO 2021132159A1 JP 2020047681 W JP2020047681 W JP 2020047681W WO 2021132159 A1 WO2021132159 A1 WO 2021132159A1
Authority
WO
WIPO (PCT)
Prior art keywords
data
servers
authentication
server
authentication server
Prior art date
Application number
PCT/JP2020/047681
Other languages
English (en)
French (fr)
Inventor
勇二 海上
松島　秀樹
芳賀　智之
前田　学
Original Assignee
パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ filed Critical パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ
Priority to EP20907325.3A priority Critical patent/EP4083834A4/en
Priority to CN202080090169.4A priority patent/CN114846471A/zh
Priority to JP2021567441A priority patent/JPWO2021132159A1/ja
Publication of WO2021132159A1 publication Critical patent/WO2021132159A1/ja
Priority to US17/843,408 priority patent/US12088664B2/en

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/104—Peer-to-peer [P2P] networks
    • H04L67/1087—Peer-to-peer [P2P] networks using cross-functional networking aspects
    • H04L67/1091—Interfacing with client-server systems or between P2P systems
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/64—Protecting data integrity, e.g. using checksums, certificates or signatures
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/01—Customer relationship services
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/02—Marketing; Price estimation or determination; Fundraising
    • G06Q30/0201—Market modelling; Market analysis; Collecting market data
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0807—Network architectures or network communication protocols for network security for authentication of entities using tickets, e.g. Kerberos
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/12—Applying verification of the received information
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q2220/00—Business processing using cryptography
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/56—Financial cryptography, e.g. electronic payment or e-cash

Definitions

  • This disclosure relates to a data distribution method, a program, and a data distribution system for utilizing the data collected from the user.
  • Non-Patent Document 1 Society 5 is a human-centered society that achieves both economic development and resolution of social issues through a system that highly integrates cyber space (virtual space) and physical space (real space). It is disclosed about .0.
  • Non-Patent Document 1 Society 5.0 states that personal data will be collected and utilized in tourism or health care, for example.
  • This disclosure was made in view of the above circumstances, and an object of the present disclosure is to provide a data distribution method, etc. that can utilize data while ensuring data traceability.
  • the data distribution method of the present disclosure is a data distribution method in a data distribution system including a plurality of authentication servers each having a distributed ledger, a plurality of data servers, and a device, and is classified into the first group.
  • a second group different from the first group to which 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 belong.
  • the first transaction data including the above is acquired, and the one first authentication server records the block containing the first transaction data in the distributed ledger of the one first authentication server belonging to the first group.
  • the data of the device possessed by the one or more first data servers can be transferred to one or more first data servers to the one or more second data servers, or can be referred to by the one or more second data servers.
  • the second authentication server of the plurality of second authentication servers acquires the first transaction data, and the one second authentication server obtains the block containing the first transaction data. Record in the distributed ledger of the one second authentication server belonging to the two groups.
  • FIG. 1 is a diagram showing an example of the overall configuration of the data distribution system according to the embodiment.
  • FIG. 2 is a diagram showing an example of the overall configuration of the house according to the embodiment.
  • FIG. 3 is a block diagram showing an example of the configuration of the controller shown in FIG.
  • FIG. 4 is a block diagram showing an example of the configuration of the terminal according to the embodiment.
  • FIG. 5 is a block diagram showing an example of the configuration of the authentication server according to the embodiment.
  • FIG. 6 is an explanatory diagram showing a data structure of the blockchain.
  • FIG. 7 is a block diagram showing an example of a data server according to the embodiment.
  • FIG. 8 is a block diagram showing an example of the service server according to the embodiment.
  • FIG. 9A is an overall sequence diagram of the data distribution system according to the embodiment.
  • FIG. 9A is an overall sequence diagram of the data distribution system according to the embodiment.
  • FIG. 9B is an overall sequence diagram of the data distribution system according to the embodiment.
  • FIG. 10 is a sequence diagram showing a consent information registration process between the terminal and the authentication server according to the embodiment.
  • FIG. 11 is a sequence diagram showing a data registration process between the house, the authentication server, and the data server according to the embodiment.
  • FIG. 12A is a sequence diagram showing data reference processing between the terminal, the authentication server, the data server, and the service server according to the embodiment.
  • FIG. 12B is a sequence diagram showing data reference processing between the terminal, the authentication server, the data server, and the service server according to the embodiment.
  • 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.
  • FIG. 14A is a sequence diagram showing an example of data provision processing of the data distribution system according to the embodiment.
  • FIG. 14B is a sequence diagram showing an example of data provision processing of the data distribution system according to the embodiment.
  • FIG. 15A is a sequence diagram showing another example of the data providing process of the data distribution system according to the embodiment.
  • FIG. 15B is a sequence diagram showing another example of the data providing process of the data distribution system according to the embodiment.
  • FIG. 15C is a sequence diagram showing another example of the data providing process of the data distribution system according to the embodiment.
  • the data distribution method of one embodiment of the present disclosure is a data distribution method in a data distribution system including a plurality of authentication servers each having a distributed ledger, a plurality of data servers, and a device, and the first group includes the plurality of data distribution methods.
  • a plurality of first authentication servers among the authentication servers of the above and one or more first data servers of the plurality of data servers belong to the second group different from the first group.
  • a plurality of second authentication servers different from the plurality of first authentication servers among the authentication servers and one or more second data servers different from the one or more first data servers among the plurality of data servers belong to the group.
  • the first authentication server includes a data acquisition request indicating that one of the plurality of first authentication servers requests the acquisition or reference of the data of the device.
  • the transaction data is acquired, and the one first authentication server records the block containing the first transaction data in the distributed ledger of the one first authentication server belonging to the first group, and the first or more first.
  • the data of the device possessed by the one or more first data servers is transferred to the one or more second data servers, or can be referred to by the one or more second data servers, and the plurality of data servers are made to be able to refer to the data.
  • the second authentication server of the second authentication server of the above acquires the first transaction data, and the one second authentication server belongs to the block containing the first transaction data in the second group. Record in the distributed ledger of the one second authentication server.
  • the data distribution system further includes a service server, and in the data distribution method, the service server generates the first transaction data, and the one first authentication server and the one second authentication server.
  • the service server generates the first transaction data
  • the one first authentication server obtains consent information from the device and uses the consent information regarding the utilization of the data. Based on this, it is determined whether the data can be provided from the one or more first data servers to the one or more second data servers, and the one or more first data servers are subjected to the one or more first data servers.
  • the data of the device possessed by the device may be transferred to the one or more second data servers, or may be made available for reference by the one or more second data servers.
  • the service server can transfer the data of the device to the one or more second data servers by the one or more first data servers, or can refer to the data by the one or more second data servers.
  • the second transaction data for issuing the token to the device is generated
  • the one first authentication server acquires the second transaction data, and the one first one.
  • the authentication server records the block containing the second transaction data in the distributed ledger of the one first authentication server belonging to the first group, and the second transaction data recorded by the one first authentication server.
  • the smart contract may be made to issue a token to the device by operating a smart contract programmed so as to be able to issue a token based on the above.
  • the one first authentication server acquires a smart contract programmed so that it can determine whether or not the data can be provided based on the consent information, and the one first authentication server obtains a smart contract.
  • the first transaction data is acquired, by executing the smart contract based on the acquired first transaction data, the data is transferred from the one or more first data server to the one or more second data server.
  • the data of the device possessed by the one or more first data servers is transferred to the one or more first data servers, or the data of the first or more data servers is transferred to the one or more second data servers, or the above 1 It may be made possible to refer to by the above-mentioned second data server.
  • the one first authentication server verifies the acquired first transaction data, and the one first authentication server performs the verification.
  • the validity of the first transaction data is confirmed by performing the operation, the validity of the first transaction data is confirmed together with a plurality of first authentication servers other than the one first authentication server among the plurality of first authentication servers.
  • the one first authentication server puts a block containing the first transaction data into the first. It may be recorded in the distributed ledger of the first authentication server belonging to one group.
  • the one second authentication server verifies the acquired first transaction data, and the one second authentication server performs the verification.
  • the validity of the first transaction data is confirmed by performing the operation, the validity of the first transaction data is confirmed together with a plurality of second authentication servers other than the one second authentication server among the plurality of second authentication servers.
  • the one second authentication server puts a block containing the first transaction data into the first. It may be recorded in the distributed ledger of the one second authentication server belonging to the two groups.
  • the data distribution system of one embodiment of the present disclosure is a data distribution system including a plurality of authentication servers each having a distributed ledger and a plurality of data servers, and the first group includes the plurality of authentication servers.
  • the plurality of first authentication servers and one or more first data servers of the plurality of data servers belong to the group, and the second group different from the first group includes the plurality of authentication servers.
  • a plurality of second authentication servers different from the plurality of first authentication servers, and one or more second data servers different from the one or more first data servers among the plurality of data servers belong to the above.
  • the first authentication server which is one of the plurality of first authentication servers, includes a first communication unit that acquires first transaction data including a data acquisition request indicating that the device data is requested to be acquired or referred to.
  • the first recording unit in which the one first authentication server records a block containing the first transaction data in the distributed ledger of the one first authentication server belonging to the first group, and the first or more first.
  • An execution unit that allows the data server to transfer the data of the device possessed by the one or more first data servers to the one or more second data servers, or to refer to the data by the one or more second data servers.
  • the second authentication server which is one of the plurality of second authentication servers, has a second communication unit that acquires the first transaction data, and the one second authentication server receives the first transaction data. It includes a second recording unit that records the including block in the distributed ledger of the one second authentication server belonging to the second group.
  • the data distribution system of the present disclosure records that data has been transferred or made visible to both the distributed ledger belonging to the data provider group and the distributed ledger belonging to the data provider group.
  • the data distribution system of the present disclosure can utilize blockchain technology to link data belonging to different groups while ensuring data traceability. That is, the data distribution system of the present disclosure can utilize the data while ensuring the traceability of the data. Therefore, the user can provide the data with peace of mind.
  • FIG. 1 is a diagram showing an example of the overall configuration of the data distribution system 10 according to the present embodiment.
  • the data distribution system 10 includes a house 100, a terminal 110, authentication servers 200a, 200b, 200c, 210a, 210b, 210c, data servers 300, 310, and service servers 400, 410. Be prepared. These are connected by a communication network 500.
  • the authentication servers 200a, 200b, 200c, 210a, 210b, 210c are connected to a storage device having a distributed ledger in which transaction data and blocks of the blockchain are electronically recorded.
  • the authentication server 200 may be connected to the storage device via the communication network 500, or the storage device may be provided inside.
  • the authentication servers 200a, 200b, 200c and the data server 300 form one group (hereinafter, referred to as a first group), and the authentication servers 200a, 200b, 200c use the blockchain technology of the data server 300.
  • the authentication servers 200a, 200b, and 200c may be hereinafter referred to as the authentication server 200.
  • the authentication servers 210a, 210b, 210c and the data server 310 form one group different from the first group (hereinafter referred to as the second group), and the authentication servers 210a, 210b, 210c are blockchain technology. Will be described as managing the data of the data server 310.
  • the authentication servers 210a, 210b, and 210c may be hereinafter referred to as the authentication server 210.
  • the first group and the second group are examples of different platforms of the blockchain, for example, and the distributed ledger belonging to each includes different transaction data.
  • FIG. 2 is a diagram showing an example of the overall configuration of the house 100 according to the present embodiment.
  • the house 100 is an example of the device according to the present disclosure that acquires or collects user data.
  • the data to be acquired or collected may be, for example, healthcare data such as user's medical examination data, sleep data, blood pressure data, weight data, exercise data, etc., but is not limited to this.
  • the data to be acquired or collected is not limited to healthcare data, but may be user personal data including vital data such as heartbeat, measurement data, device operation history, or device operation history. It may be the history information of the device such as. In this way, the data acquired or collected may be any data that can be utilized by the service provider.
  • the house 100 includes a controller 101, a photovoltaic power generation device 102, a storage battery 103, an air conditioner 104, a body composition meter 105, and a sphygmomanometer 106. These are connected by a communication network.
  • the data acquired or collected by the house 100 will be described as being stored in the data server 300 belonging to the first group.
  • the controller 101 controls home devices such as the air conditioner 104, the body composition analyzer 105, and the sphygmomanometer 106. Further, the control unit 1011 may display the operating status of the photovoltaic power generation device 102 and the storage battery 103.
  • the controller 101 may collect history information such as the operation history or operation history of the home device, or may collect the history information of the operation status of the photovoltaic power generation device 102 and the storage battery 103. In addition, the controller 101 may collect measurement data measured by a home device.
  • controller 101 may transmit the collected data such as history information and measurement data to the data server 300, or may transmit the generated transaction data to the authentication server 200.
  • the photovoltaic power generation device 102 is a device equipped with a power generation method that directly converts sunlight into electric power using a solar cell.
  • the electric power generated by the photovoltaic power generation device 102 is used in the house 100 or stored in the storage battery 103.
  • the photovoltaic power generation device 102 is not an indispensable configuration and may not be provided in the house 100.
  • the storage battery 103 stores the electric power generated by the photovoltaic power generation device 102.
  • the storage battery 103 is not an essential configuration and may not be provided in the house 100.
  • the air conditioner 104, the body composition analyzer 105, and the sphygmomanometer 106 are home devices used by the user, but may be examples of the devices of the present disclosure.
  • history information such as the operation history or operation history of the air conditioner 104 is transmitted to the data server 300.
  • user measurement data such as history information such as operation history or operation history of body composition meter 105 and sphygmomanometer 106, weight data measured by body composition meter 105, and / or blood pressure data measured by sphygmomanometer 106. Is also transmitted to the data server 300. These data may be transmitted to the data server 300 via the controller 101, or may be directly transmitted to the data server 300.
  • FIG. 3 is a block diagram showing an example of the configuration of the controller 101 shown in FIG.
  • the controller 101 includes a processor (not shown) and a memory (not shown) in which a program for causing the processor to execute a predetermined process is stored. That is, the controller 101 is realized by the processor executing a predetermined program using the memory.
  • 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.
  • the control unit 1011 may control the home device.
  • the control unit 1011 operates home devices such as the air conditioner 104, body composition meter 105, and sphygmomanometer 106, and manages the operation history and state of the home devices.
  • the control unit 1011 may display the operating status of the photovoltaic power generation device 102 and the storage battery 103.
  • the control unit 1011 may display the power generation status of the photovoltaic power generation device 102 or the storage status of the storage battery 103.
  • the control unit 1011 may display the state of the home device or vital data measured by the body composition analyzer 105 or the sphygmomanometer 106.
  • control unit 1011 may collect history information such as the operation history or operation history of the home device, or may collect the history information of the operation status of the photovoltaic power generation device 102 and the storage battery 103. Further, the control unit 1011 may collect the measurement data measured by the home device.
  • the input unit 1013 generates consent information regarding the utilization of the acquired or collected data.
  • the consent information is information indicating that the user has agreed that the acquired or collected data will be utilized, and is generated based on the user's operation.
  • the consent information may be generated, for example, by selecting or deselecting from the list of service providers of data providing destinations provided by the input unit 1013 or the list of data.
  • the consent information includes a service provider that can provide data that the user has agreed to, or data or a type of data that can be provided that the user has agreed to. That is, the consent information includes the service provider that the user has agreed to provide, or the data or the type of data.
  • the consent information is provided or referred to by, for example, a third party who is a third party from the viewpoint of the data providing destination provided by the input unit 1013 and is selected according to a predetermined criterion of the user based on the reliability or incentive. It may be information that agrees with. The third party may be different from the group to which the data providing destination provided by the input unit 1013 belongs. Further, the consent information may include information that agrees to be provided when the feedback is above a certain level.
  • the input unit 1013 may generate a smart contract based on the generated consent information.
  • this smart contract is an executable program that determines whether data can be provided.
  • the smart contract may include consent information generated by input unit 1013.
  • the input unit 1013 may be an application installed on the controller 101, in which case the installed application realizes the above-mentioned function of the input unit 1013.
  • the transaction data generation unit 1012 generates transaction data in the blockchain.
  • 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 includes, for example, a transaction including a blockchain address owned by the user, consent information including the service provider or data or data type to which the user has agreed to provide, and a signature. Generate data.
  • the transaction data generation unit 1012 may further add an identifier to generate transaction data.
  • the transaction data generation unit 1012 generates a signature using a user-specific signature generation key.
  • the transaction data generation unit 1012 may generate transaction data including the smart contract generated by the input unit 1013.
  • the transaction data generation unit 1012 may generate transaction data including the consent information generated by the input unit 1013 and the smart contract.
  • the transaction data generation unit 1012 may generate transaction data including a data acquisition request acquired via the communication unit 1015.
  • the data acquisition request may be, for example, a request for the data server 310 belonging to a group different from the group to which the controller 101 belongs to acquire or refer to the data.
  • the transaction data generation unit 1012 may generate transaction data including a data acquisition request acquired via the communication unit 1015 and consent information for the data acquisition request.
  • 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.
  • the transaction data generation unit 1012 may generate transaction data including, for example, a blockchain address owned by the user, information indicating data collected by the control unit 1011, and a signature.
  • the information indicating the data may be, for example, the data itself collected by the control unit 1011 or the hash value of the data, or the hash value of the data and the attribute information of the data. ..
  • the data attribute information may include, for example, the type of sensor or device that collected the data.
  • the attribute information of the data includes data items indicating when, how, and in what item the data was measured or collected. May be included.
  • the data may include data items indicating the operation history, the operation date and time, and the like.
  • the transaction data generation unit 1012 records the generated transaction data in the recording unit 1014.
  • the transaction data generation unit 1012 transmits to the authentication server 200 via the communication unit 1015.
  • the recording unit 1014 records data such as history information and measurement data collected by the control unit 1011. Further, the recording unit 1014 records the transaction data generated by the transaction data generation unit 1012. In addition, the recording unit 1014 may record the consent information and the smart contract generated by the input unit 1013.
  • 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 by TLS (Transport Layer Security). In this case, the encryption key for TLS communication may be held by the communication unit 1015.
  • TLS Transport Layer Security
  • FIG. 4 is a block diagram showing an example of the configuration of the terminal 110 according to the present embodiment.
  • the terminal 110 is an example of the device of the present disclosure, and is realized by the processor executing a predetermined program using the memory.
  • the terminal 110 is, for example, a device having a display unit and an input unit such as a smartphone, or a device such as a wearable device that acquires measurement data of a user.
  • the terminal 110 includes a transaction data generation unit 1101, an input unit 1102, a data acquisition unit 1103, a recording unit 1104, and a communication unit 1105.
  • the data acquired or collected by the terminal 110 will be described as being stored in the data server 300 belonging to the first group.
  • the input unit 1102 generates user consent information regarding the utilization of data.
  • the consent information is information indicating that the user has agreed that the acquired or collected data will be utilized, and is generated based on the user's operation.
  • the consent information may be generated by selecting or deselecting from the list of service providers of the data providing destination provided by the input unit 1102 or the list of data.
  • the user may select a service provider to which the data is provided based on the purpose of data utilization, the data utilization record, or the feedback or incentive to the user due to the utilization of the data.
  • an incentive or feedback when a user provides data to a service provider, the service provider may pay the user virtual currency or display information that can be enjoyed.
  • a user when a user provides measurement data such as a measurement history of a body composition analyzer or a sphygmomanometer to a sports club, the sports club can enjoy a free trial or a reduction in membership fee, or information that can be enjoyed. It can be displayed.
  • measurement data such as a measurement history of a body composition analyzer or a sphygmomanometer
  • the consent information is provided to, for example, a third party who is a third party from the viewpoint of the data provider provided by the input unit 1102 and is selected according to a predetermined criterion of the user based on the reliability or incentive. Alternatively, it may be information that you agree to refer to.
  • the third party may be different from the group to which the data providing destination provided by the input unit 1102 belongs.
  • the input unit 1102 may generate a smart contract programmed so that it can determine whether or not data can be provided based on the generated consent information.
  • the transaction data generation unit 1101 generates transaction data in the blockchain.
  • the transaction data generation unit 1101 generates transaction data in the block chain including the consent information generated by the input unit 1102. More specifically, the transaction data generation unit 1101 includes, for example, a transaction including a blockchain address owned by the user, consent information including the service provider or data or data type to which the user has agreed to provide, and a signature. Generate data.
  • transaction data generation unit 1101 may further add an identifier to generate transaction data.
  • the transaction data generation unit 1101 may generate a signature using a user-specific signature generation key.
  • the transaction data generation unit 1101 may generate transaction data including information indicating the data acquired by the data acquisition unit 1103.
  • the transaction data generation unit 1101 may generate transaction data including, for example, a blockchain address owned 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, the hash value of the data, the hash value of the data, and the attribute information of the data.
  • the transaction data generation unit 1101 may generate transaction data including the smart contract generated by the input unit 1102.
  • the transaction data generation unit 1101 may generate transaction data including the consent information generated by the input unit 1102 and the smart contract.
  • 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.
  • the transaction data generation unit 1101 may generate transaction data including a data acquisition request acquired via the communication unit 1105.
  • the data acquisition request may be, for example, a request for the data server 310 belonging to a group different from the group to which the terminal 110 belongs to acquire or refer to the data.
  • the transaction data generation unit 1101 may generate transaction data including a data acquisition request acquired via the communication unit 1105 and consent information for the data acquisition request.
  • the data acquisition unit 1103 acquires data such as measurement data acquired by the sensor held by the terminal 110.
  • the data acquisition unit 1103 acquires the number of steps obtained from the acceleration sensor and the number of steps data including the position information obtained from the GPS sensor as measurement data.
  • the data acquisition unit 1103 may acquire blood pressure data or heart rate data as measurement data. That is, the data acquisition unit 1103 acquires data that can be utilized by the service provider.
  • the data acquisition unit 1103 records the acquired data in the recording unit 1104.
  • the data acquisition unit 1103 may transmit to the data server 300 via the communication unit 1105.
  • the recording unit 1104 records the transaction data generated by the transaction data generation unit 1101. In addition, the recording unit 1104 records the data acquired by the data acquisition unit 1103. The recording unit 1104 may record the consent information and the smart contract generated by the input unit 1102.
  • the communication unit 1105 communicates with the authentication server 200 and the data server 300 via the communication network 500. This communication may be done by TLS. In this case, the encryption key for TLS communication may be held by the communication unit 1105.
  • the authentication servers 200 and 210 manage the data acquired from the house 100 or the terminal 110.
  • the authentication server 200 and the data server 300 belong to the first group, and the authentication server 200 manages the data of the data server 300 by using the blockchain technology.
  • the authentication server 200 that is, the authentication servers 200a, 200b, 200c is an example of a plurality of first authentication servers
  • the authentication server 200a is an example of a first authentication server of one of the plurality of first authentication servers. is there.
  • the authentication server 210 and the data server 310 belong to the second group, and the authentication server 210 manages the data of the data server 310 by using the blockchain technology.
  • the authentication server 210 that is, the authentication servers 210a, 210b, 210c is an example of a plurality of second authentication servers, and for example, the authentication server 210c is an example of a second authentication server of one of the plurality of second authentication servers. Is.
  • the authentication server 200a Since the authentication servers 200a, 200b, 200c, 210a, 210b, and 210c have the same configuration, the authentication server 200a will be described below as an example.
  • FIG. 5 is a block diagram showing an example of the configuration of the authentication server 200a according to the present embodiment.
  • 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 the processor executing a predetermined program using the memory.
  • each component will be described.
  • the transaction data verification unit 211 verifies the acquired transaction data. Specifically, when transaction data is acquired from a device such as a house 100 or a terminal 110, the transaction data verification unit 211 verifies whether the transaction data format 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. For example, when verifying transaction data including information indicating data, the transaction data verification unit 211 may verify whether the address, information indicating data, and signature included in the transaction data are valid.
  • the transaction data verification unit 211 verifies the transaction data by confirming the validity of the acquired transaction data.
  • the transaction data verification unit 211 When the transaction data verification unit 211 confirms the validity of the transaction data as a result of the verification, the transaction data verification unit 211 records the transaction data in the recording unit 215. Here, if it is determined that the transaction data is valid, the synchronization unit 213 is notified.
  • PBFT Practice Byzantine Facility Resource
  • PoW Proof of Work
  • the block generation unit 212 executes a consensus algorithm between the authentication server 200a, the authentication server 200b, and the authentication server 200c that belong to the same group, that is, the first group. That is, the block generation unit 212 first generates a block of the blockchain including one or more transaction data. Next, the block generation unit 212 executes the consensus algorithm. Then, when the consensus can be formed 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.
  • FIG. 6 is an explanatory diagram showing the data structure of the blockchain.
  • a blockchain is a block in which the blocks, which are the recording units, are connected in a chain shape.
  • Each block has a plurality of transaction data and a hash value of the immediately preceding block.
  • the block B2 contains the hash value of the previous block B1.
  • the hash value calculated from the plurality of transaction data included in the block B2 and the hash value of the block B1 is included in the block B3 as the hash value of the block B2.
  • the synchronization unit 213 synchronizes blockchain blocks or transaction data between a plurality of authentication servers 200 (authentication servers 200a to 200c) belonging to the same group, that is, the first group.
  • the synchronization unit 213 of the plurality of authentication servers 200 synchronizes the transaction data of the blockchain by peer-to-peer. Then, the synchronization unit 213 records the transaction data of the synchronized blockchain 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 the authentication servers 200b and 200c, which are other authentication servers 200. Further, when the synchronization unit 213 receives the verified transaction data from another authentication server 200, the synchronization unit 213 records the received verified transaction data in the recording unit 215.
  • the smart contract execution unit 214 stores the smart contract recorded in the distributed ledger in the working memory.
  • the smart contract execution unit 214 executes the smart contract stored in the working memory.
  • the smart contract execution unit 214 stores the smart contract generated based on the user's consent information in the working memory. Store in.
  • the smart contract execution unit 214 can make the executed smart contract determine whether or not to provide data by executing the smart contract stored in the working memory.
  • the executed smart contract notifies the judgment result of whether or not the data can be provided, and grants the access right to the blockchain address included in the transaction data including the data acquisition request.
  • the smart contract execution unit 214 can manage the access of the service server 400 to the data held by the data server 300 by executing the smart contract, for example, by using the access from the service server 400 as a trigger.
  • the executed smart contract is as follows. Works with. That is, the executed smart contract determines whether or not data can be provided to the data server 310 or the like belonging to the second group based on the consent information of the user. Then, when it is determined that the executed smart contract can be provided, the data server 300 belonging to the first group is made to transfer the user's data to the data server 310 or to make it referenceable by the data server 310. Just do it.
  • the smart contract execution unit 214 executes the smart contract by triggering that the transaction data including the data acquisition request is recorded in the distributed ledger, and provides the data held by the data server 300 to different groups. To do. In addition, since it is recorded that the data has been transferred or made visible to the distributed ledger, the traceability of the data can be ensured.
  • the smart contract execution unit 214 stores the smart contract generated based on the incentive payment or the feedback provision in the working memory when the transaction data including the information regarding the incentive payment or the feedback provision is recorded in the distributed ledger. ..
  • the smart contract execution unit 214 can make the executed smart contract provide incentive payment or feedback by executing the smart contract stored in the working memory.
  • the incentive payment or feedback provision may be a notification that the incentive payment or feedback provision has been made, or the incentive payment or feedback provision may be provided to the user.
  • the recording unit 215 includes the transaction data in the 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 the external storage device of the authentication server 200a.
  • the transaction data includes transaction data acquired from the house 100 or the terminal 110.
  • the recording unit 215 records the block including the transaction data in the distributed ledger of the authentication server 200a.
  • the block of the blockchain recorded in the distributed ledger may be open to the service server 400, the house 100, or the terminal 110.
  • 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. In addition, the communication unit 216 may communicate with the authentication server 210. These communications may be made by TLS. In this case, the encryption key for TLS communication may be held by the communication unit 216.
  • the authentication server 200a performs processing for verifying the validity of the data acquired from the house 100 or the terminal 110, managing whether or not the data can be provided, and providing the data to the service server 400.
  • the authentication server 200a manages whether or not data can be provided to a second group different from the first group to which the authentication server 200a belongs, and performs processing for providing data to the second group.
  • the data provided here may be, for example, data transfer or data reference.
  • the data acquired from the house 100 or the terminal 110 is recorded by the data server 300 and not by the authentication server 200a, but the present invention is not limited to this.
  • the data may be recorded on the authentication server 200a. In this case, it may be recorded as transaction data including the data in the distributed ledger of the authentication server 200a.
  • the data servers 300 and 310 manage the data by recording (storing) the data acquired from the house 100 or the terminal 110.
  • the data servers 300 and 310 are examples of a plurality of data servers.
  • the data server 300 is an example of one or more first data servers, and belongs to the first group as described above.
  • the data server 310 is an example of one or more second data servers different from one or more first data servers, and belongs to the second group as described above.
  • the data server 300 Since the data servers 300 and 310 have the same configuration, the data server 300 will be described below as an example.
  • FIG. 7 is a block diagram showing an example of the configuration of the data server 300 according to the present embodiment.
  • 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 the processor executing a predetermined program using the memory.
  • each component will be described.
  • the data management unit 311 manages the data acquired from the house 100 or the terminal 110.
  • the data management unit 311 records the data acquired from the house 100 or the terminal 110 in the recording unit 313.
  • the acquired data may be data collected from the user by the device of the present disclosure such as the house 100 or the terminal 110, or may be user information.
  • the collected data is not limited to health care data, but may be user personal data including vital data such as heartbeat, measurement data, device operation history, or device. It may be the history information of the device such as the operation history of.
  • the user management unit 312 manages the user information of the acquired data.
  • the user information is, for example, information about a user using the terminal 110, information about a user such as a family structure including a user in the house 100, and the like.
  • the data management unit 311 when the data management unit 311 receives a request for data provision from the service server 400 that can access the first group to which the data server 300 belongs, the data management unit 311 is based on the consent information recorded in the distributed ledger of the authentication server 200. Provide user data. For example, it is assumed that the smart contract generated based on the consent information is executed by the authentication server 200, and the data server 300 receives a notification indicating that data can be provided from the authentication server 200. In this case, the data management unit 311 further provides the user's data when receiving a data provision request from the service server 400. The data management unit 311 may receive a request for data provision from the service server 400 as well as a blockchain address corresponding to the data to be provided.
  • the data management unit 311 is as follows. It works like this. That is, the data management unit 311 is controlled by the authentication server 200a based on the consent information, and transfers the user data recorded in the recording unit 313 to, for example, the data server 310 belonging to the second group, or the data server. Make it referenceable by 310. In this way, the data management unit 311 is controlled by the authentication server 200a based on the consent information, and provides data to a data server 310 of a different group, for example, a second group.
  • the recording unit 313 records the data acquired from the device of the present disclosure such as the house 100 or the terminal 110.
  • 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. Further, the communication unit 314 may communicate with the data server 310 or the service server 400 via the communication network 500. These communications may be made by TLS. In this case, the encryption key for TLS communication may be held by the communication unit 314.
  • the data server 300 belonging to the first group records the data acquired from the house 100 or the terminal 110. Further, the data server 300 belonging to the first group provides data to the data server 310 belonging to the second group, which is a different group, by controlling the authentication server 200 such as a smart contract. Data provision includes transferring data and / or allowing reference to the data, as described above.
  • the data server 300 and the authentication server 200 are described as independent servers, but the present invention is not limited to this.
  • the function of the data server 300 may be included in the authentication server 200 and operate.
  • the service servers 400 and 410 are servers managed by different service providers, respectively, and manage users and services in the services provided by the service providers.
  • the service provider is, for example, a sports club.
  • the service servers 400 and 410 provide services by utilizing the data acquired from each terminal 110 and / or the house 100, respectively.
  • the service server 400 cannot access the second group but can access the first group, and can utilize the data possessed by the data server 300 belonging to the first group.
  • the service server 410 cannot access the first group but can access the second group, and can utilize the data possessed by the data server 310 belonging to the second group.
  • the service server 400 Since the service servers 400 and 410 have the same configuration, the service server 400 will be described below as an example.
  • FIG. 8 is a block diagram showing an example of the configuration of the service server 400 according to the present embodiment.
  • the service server 400 includes a service management unit 411, a user management unit 412, a transaction data generation unit 413, a recording unit 414, and a communication unit 415.
  • the service server 400 can be realized by the processor executing a predetermined program using the memory.
  • each component will be described.
  • the service management unit 411 utilizes the user information managed by the user management unit 412 to provide the service.
  • the service management unit 411 acquires data including measurement data such as a user's body composition measurement value or blood pressure measurement value from the data server 300, provides a new healthcare service, and demonstrates the effect.
  • the service management unit 411 uses the user information managed by the user management unit 412 to generate a data acquisition request indicating that the data acquisition is requested, and transmits the data acquisition request to the transaction data generation unit 413.
  • the service management unit 411 determines, for example, what kind of data the user wants to acquire, and generates a data acquisition request based on the attribute information of the user to be acquired, the data type to be acquired, and the like.
  • the data acquisition request may include, for example, a request in which the user's identifier is specified when the user's identifier is known in advance, or may include a request in which the blockchain address is specified. However, a request with specified attributes may be included.
  • the attribute here may be the type of the device such as the house 100 or the terminal 110, the type of the data acquired from the device, or the attribute of the user.
  • the data to be acquired by the service management unit 411 may not be recorded in the data server 300 belonging to the first group, but may be recorded only in the data server 310 belonging to the second group different from the first group.
  • the service management unit 411 transfers the transaction data including the data acquisition request generated by the transaction data generation unit 413 via the communication unit 415 to the authentication server 200 belonging to the first group and the authentication server belonging to the second group. Send to 210.
  • the authentication server 210 belonging to the second group determines that data may be provided to the data server 300 or the like of the first group
  • the data held by the data server 310 belonging to the second group is controlled by the authentication server 210. It is provided to the data server 300 belonging to the first group. In this way, even if the data to be acquired is not recorded in the data server 300 but is recorded only in the data server 310, the service management unit 411 is provided to the data server 300 to provide the data server 300.
  • the data can be obtained from.
  • the service management unit 411 when the data is acquired, the service management unit 411 generates information regarding incentive payment or feedback provision to the user of the acquired data as a consideration for the acquired data, and transmits the information to the transaction data generation unit 413.
  • the information regarding the incentive payment or the provision of feedback may include the fact that the virtual currency has been paid to the user's blockchain address as consideration for the acquired data.
  • the service management unit 411 may generate a smart contract based on the generated incentive payment or feedback provision.
  • the smart contract may include, for example, a program for executing payment of virtual currency to the user's blockchain address in exchange for the acquired data.
  • the user management unit 412 acquires the information of the user who is the target of providing the service, and manages the acquired user information.
  • the transaction data generation unit 413 generates transaction data including a data acquisition request generated by the service management unit 411.
  • the transaction data generation unit 413 generates transaction data including information regarding incentive payment or feedback provision generated by the service management unit 411.
  • the transaction data generation unit 413 may generate transaction data including a smart contract based on the incentive payment or feedback provision generated by the service management unit 411.
  • the recording unit 414 records user information or service information necessary for providing the service. Further, the recording unit 414 records the transaction data generated by the transaction data generation unit 413. The recording unit 414 may record the data acquisition request, incentive payment or feedback provision information generated by the service management unit 411, and the smart contract.
  • the communication unit 415 communicates with the authentication server 200 and the data server 300 via the communication network 500. This communication may be done by TLS. In this case, the encryption key for TLS communication may be held by the communication unit 415.
  • step S100 the consent information registration process is performed between the terminal 110, the house 100, and the authentication servers 200a to 200c belonging to the first group.
  • the consent information registration process is performed between the terminal 110 and the authentication servers 200a to 200c belonging to the first group.
  • step S200 data registration processing is performed between the terminal 110, the house 100, the authentication servers 200a to 200c belonging to the first group, and the data server 300.
  • step S200 data registration processing is performed between the house 100 and the authentication servers 200a to 200c belonging to the first group.
  • 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.
  • 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.
  • data reference processing is performed between the terminal 110, the authentication servers 200a to 200c, the data server 300, and the service server 400.
  • step S500 as shown in FIG. 9B, 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 Data provision processing is performed between them.
  • the data providing process in step S500 can be executed after the user data is registered in the data registration process in step S200.
  • the data providing process described later a case where the data of the data server 300 belonging to the first group is provided to the data server 310 belonging to the second group will be described.
  • FIG. 10 is a sequence diagram showing a consent information registration process between the terminal 110 and the authentication servers 200a to 200c according to the present embodiment.
  • FIG. 10 shows a case where the terminal 110 registers the consent information, the same process is performed even when the controller 101 of the house 100 registers the consent information.
  • FIG. 10 the consent information registration process between the terminal 110 and the authentication servers 200a to 200c belonging to the first group is shown, but the present invention is not limited to this. The same process is applied when the consent information registration process is performed between the house 100 and the authentication servers 210a to 210c belonging to the second group.
  • the terminal 110 generates consent information based on the user's operation (S101).
  • an application is introduced in the terminal 110 as an input unit 1013, and the application may generate consent information based on a user's operation.
  • the user simply instructs the terminal 110 to generate consent information from the list of service providers of data provision destinations provided by the input unit 1013 or the list of data, by instructing whether to select or remove the selection. Can be done.
  • the user may generate the consent information after determining whether or not there is a lot of feedback from the service provider when the terminal 110 generates the consent information.
  • the user selects the data provider (that is, the data provider) based on the content of feedback such as the provision of virtual currency or the provision of coupons or discounts of the service provider. You may decide (agreement to provide data).
  • the user selects a data provider (that is, data provider) based on the content of feedback to the user such as the amount of virtual currency or the amount of coupon or discount provided when the data is provided to the service provider. You may decide (agree).
  • the content of the feedback may be disclosed by the service provider or may be recorded in the blockchain of the authentication server 200.
  • the terminal 110 generates a smart contract based on the consent information generated in step S101 (S102).
  • This smart contract is executablely programmed to determine if data can be provided.
  • the smart contract may include the consent information generated in step S101. Further, the smart contract may include a program that makes it possible to determine whether or not to provide feedback when the feedback is above a certain level.
  • the terminal 110 generates transaction data including the generated consent information and the smart contract (S103).
  • the terminal 110 transmits the transaction data generated in step S103 to the authentication server 200a (S104).
  • the terminal 110 transmits the generated transaction data to the authentication server 200a, but the terminal 110 may transmit the generated transaction data to the authentication servers 200b and 200c. The same applies when the data is transmitted to the authentication servers 200b and 200c.
  • the authentication server 200a acquires transaction data from the terminal 110 (S105)
  • the authentication server 200a verifies the acquired transaction data (S106).
  • step S106 If the verification of the transaction data is not successful in step S106 (N in S106), the authentication server 200a transmits a notification to that effect to the terminal 110 (S107).
  • the authentication server 200a transfers the transaction data to another authentication server 200 (authentication servers 200b, 200c) (S108).
  • the other authentication server 200 also verifies the transferred transaction data.
  • the authentication server 200a, the authentication server 200b, and the authentication server 200c execute a consensus algorithm (S109).
  • the authentication server 200a, the authentication server 200b, and the authentication server 200c verify that the transaction data is legitimate transaction data (that is, legitimacy), they each generate a block containing the transaction data.
  • the authentication servers 200a, 200b, and 200c record the block including the transaction data in the distributed ledger.
  • the smart contract created by the terminal 110 and the consent information are recorded in the distributed ledger in this way.
  • the smart contract becomes feasible, that is, operates by being recorded in the distributed ledger (S110).
  • the smart contract can be executed because it is recorded in the distributed ledger and stored in the working memory of the authentication server 200a or the like.
  • FIG. 11 is a sequence diagram showing a data registration process between the house 100, the authentication servers 200a to 200c, and the data server 300 according to the present embodiment.
  • FIG. 11 shows a case where the data acquired by the house 100 is registered in the data server 300, the same process is performed even when the data acquired by the terminal 110 is registered.
  • FIG. 11 shows, but is not limited to, the data registration process between the house 100 and the authentication servers 200a to 200c and the data server 300 belonging to the first group. The same process is applied when the data registration process is performed between the house 100, the authentication servers 210a to 210c belonging to the second group, and the data server 310.
  • the house 100 acquires the data obtained by the in-house equipment of the house 100 (S201).
  • the data acquired by the house 100 may be, for example, the operation history of the home equipment, the electric energy generated by the photovoltaic power generation device 102, or the electric energy data output by the storage battery 103.
  • the data acquired by the house 100 may be the operation history of the air conditioner 104, or the vital data measured by the body composition analyzer 105 and / or the sphygmomanometer 106. That is, the data may be any data that is acquired by the house 100 and can be utilized by the service provider.
  • the house 100 generates transaction data for data registration including information about the data acquired in step S201 (S202). It is assumed that the information regarding the data here is, for example, the hash value of the data and the attribute information of the data.
  • the transaction data includes a blockchain address, a hash value, attribute information and a signature.
  • 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).
  • the house 100 transmits the transaction data acquired in step S201 to the authentication server 200a, but the house 100 may transmit the transaction data to the authentication servers 200b and 200c. The same applies when the data is transmitted to the authentication servers 200b and 200c.
  • the data server 300 acquires data from the house 100 (S204)
  • the data server 300 records the data acquired in step S204 (S205).
  • the authentication server 200a acquires transaction data from the house 100 (S206)
  • the authentication server 200a verifies the acquired transaction data (S207).
  • the order of steps S204 and step S206 is not the same, and may be changed.
  • the authentication server 200a transmits a notification to that effect to the house 100 (S208).
  • the authentication server 200a is not limited to notifying the house 100 to that effect, and may also notify the data server 300 to that effect. Further, in this case, the data server 300 may delete the data recorded in step S205.
  • the authentication server 200a transfers the transaction data to another authentication server 200 (authentication servers 200b, 200c) (S209).
  • the other authentication server 200 also verifies the transferred transaction data.
  • the authentication server 200a, the authentication server 200b, and the authentication server 200c execute a consensus algorithm (S210).
  • the authentication server 200a, the authentication server 200b, and the authentication server 200c verify that the transaction data is legitimate transaction data (that is, legitimacy), they each generate a block containing the transaction data.
  • the authentication servers 200a, 200b, and 200c record the block including the transaction data in the distributed ledger.
  • the block including the transaction data of the data registration including the information about the data is recorded in the distributed ledger, and the data itself is recorded in the data server 300.
  • FIGS. 12A and 12B are sequence diagrams showing data reference processing between the terminal 110, the authentication servers 200a to 200c, the data server 300, and the service server 400 according to the present embodiment.
  • the service server 400 acquires data from the data server 300 will be described.
  • the same processing is performed when the data reference processing is performed between the terminal 110, the service server 410, the authentication servers 210a to 210c belonging to the second group, and the data server 310. That is, the same applies when the service server 410 acquires data from the data server 310.
  • the service server 400 decides to request data acquisition when, for example, determines what kind of data the user wants to acquire (S301).
  • the service server 400 generates a data acquisition request indicating that the data acquisition is requested, and generates transaction data of the data acquisition request including the data acquisition request (S302).
  • the service server 400 transmits the generated transaction data to the authentication server 200c (S303).
  • the service server 400 transmits the transaction data generated in step S302 to the authentication server 200c, but the service server 400 may transmit the transaction data to the authentication servers 200a and 200b. The same applies when the data is transmitted to the authentication servers 200a and 200b.
  • the authentication server 200c acquires the transaction data from the service server 400 (S304)
  • the authentication server 200c verifies the acquired transaction data (S305).
  • step S305 If the verification of the transaction data is not successful in step S305 (N in S305), the authentication server 200c sends a notification to that effect to the service server 400 (S306).
  • the authentication server 200c transfers the transaction data to other authentication servers 200 (authentication servers 200a and 200b) (S307).
  • the other authentication server 200 also verifies the transferred transaction data.
  • the authentication server 200a, the authentication server 200b, and the authentication server 200c execute a consensus algorithm (S308).
  • the authentication server 200a, the authentication server 200b, and the authentication server 200c verify that the transaction data is legitimate transaction data (that is, legitimacy), they each generate a block containing the transaction data.
  • the authentication servers 200a, 200b, and 200c record the block including the transaction data in the distributed ledger.
  • the authentication server 200a, the authentication server 200b, and the authentication server 200c execute the smart contract recorded in the distributed ledger (S309).
  • This smart contract was generated based on the consent information, and since it was recorded in the distributed ledger, it is stored in the working memory and can be executed.
  • the smart contract executed by the authentication server 200 determines whether or not the requested data can be provided to the service server 400 based on the consent information.
  • the smart contract transmits a notification of the determination result to the data server 300 and the service server 400 (S310).
  • the smart contract is not limited to the case where the notification of the determination result is transmitted to the data server 300 and the service server 400.
  • the smart contract may notify the terminal 110 used by the user that the requested data can be provided to the service server 400.
  • the data server 300 and the service server 400 receive the notification transmitted in step S310 (S311).
  • the notification transmitted in step S310 indicates that the requested data can be provided to the service server 400.
  • the service server 400 requests the data server 300 to provide data (S312).
  • the service server 400 may access the data server 300 in order to acquire the data provision.
  • the data server 300 confirms the notification received from the authentication server 200c in step S311 and can provide the requested data to the service server 400. Is determined (S314). In step S314, the data server 300 confirms the notification received from the authentication server 200c in step S311 and determines that the data requested by the service server 400 cannot be provided (N in S314). A notification to that effect is transmitted to the server 400 (S315).
  • step S314 when the notification received from the authentication server 200 is confirmed in step S311 and it is determined that the data requested by the service server 400 can be provided (Y in S314), the data server 300 is determined to be the service server 400. To provide the requested data (S316).
  • the service server 400 acquires the requested data (S317).
  • the service server 400 generates transaction data for incentive payment (S318). More specifically, the service server 400 generates transaction data that includes information about incentive payments.
  • the service server 400 transmits the transaction data generated in step S318 to the authentication server 200c (S319).
  • the service server 400 transmits the generated transaction data to the authentication server 200c, but the service server 400 may transmit the generated transaction data to the authentication servers 200a and 200b. The same applies when the data is transmitted to the authentication servers 200a and 200b.
  • the authentication server 200c acquires transaction data from the service server 400 (S320)
  • the authentication server 200c verifies the acquired transaction data (S321).
  • step S321 If the verification of the transaction data is not successful in step S321 (N in S321), the authentication server 200c sends a notification to that effect to the service server 400 (S322).
  • the authentication server 200c transfers the transaction data to other authentication servers 200 (authentication servers 200a and 200b) (S323).
  • the other authentication server 200 also verifies the transferred transaction data.
  • the authentication server 200a, the authentication server 200b, and the authentication server 200c execute a consensus algorithm (S324).
  • the authentication server 200a, the authentication server 200b, and the authentication server 200c verify that the transaction data is legitimate transaction data (that is, legitimacy), they each generate a block containing the transaction data.
  • the authentication servers 200a, 200b, and 200c record the block including the transaction data in the distributed ledger.
  • the authentication server 200a, the authentication server 200b, and the authentication server 200c execute the smart contract related to the incentive payment recorded in the distributed ledger (S325).
  • This smart contract was generated based on incentive payments, and by being recorded in the distributed ledger, it is stored in the working memory and can be executed.
  • the smart contract regarding the incentive payment may make the incentive payment to the user.
  • the smart contract of the authentication server 200a sends an incentive notification to the user (specifically, the terminal 110 that the incentive payment has been made (S326).
  • the service server 400 may generate transaction data including information regarding feedback provision in step S318.
  • the smart contract for providing feedback will be executed.
  • 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, and then the incentive payment process is performed.
  • 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 the present invention is limited to this. Absent.
  • the smart contract executed by the authentication server 200 may further send a notification to the user, that is, the terminal 110 that the service server 400 acquires data.
  • the service server 400 receives the determination result of the smart contract executed by the authentication server 200, and then requests the data provision to obtain the data. It has been acquired, but it is not limited to this.
  • the data recorded in the data server 300 and requested to be provided by the service server 400 may be provided to the service server 400 by the smart contract executed by the authentication server 200.
  • FIG. 13 is a sequence diagram showing a smart contract registration process related to incentive payment between the authentication servers 200a to 200c and the service server 400 according to the present 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 the present invention is not limited to this. The same process is performed when the consent information registration process is performed between the service server 410 and the authentication servers 210a to 210c belonging to the second group.
  • the service server 400 generates a smart contract related to incentive payment (S401).
  • the service server 400 generates transaction data of the smart contract registration including the smart contract related to the incentive payment generated in step S401 (S402).
  • the service server 400 transmits the transaction data generated in step S402 to the authentication server 200a (S403).
  • the service server 400 transmits the transaction data generated in step S402 to the authentication server 200a, but the service server 400 may transmit the transaction data to the authentication servers 200b and 200c. The same applies when the data is transmitted to the authentication servers 200b and 200c.
  • the authentication server 200a acquires the transaction data from the service server 400 (S404)
  • the authentication server 200a verifies the acquired transaction data (S405).
  • step S405 If the verification of the transaction data is not successful in step S405 (N in S405), the authentication server 200a sends a notification to that effect to the service server 400 (S406).
  • the authentication server 200a transfers the transaction data to another authentication server 200 (authentication servers 200b, 200c) (S407).
  • the other authentication server 200 also verifies the transferred transaction data.
  • the authentication server 200a, the authentication server 200b, and the authentication server 200c execute a consensus algorithm (S408).
  • the authentication server 200a, the authentication server 200b, and the authentication server 200c verify that the transaction data is legitimate transaction data (that is, legitimacy), they each generate a block containing the transaction data.
  • the authentication servers 200a, 200b, and 200c record the block including the transaction data in the distributed ledger.
  • the smart contract related to the incentive payment included in the transaction data becomes feasible, that is, operates by being recorded in the distributed ledger (S409).
  • the smart contract related to incentive payment can be executed because it is recorded in the distributed ledger and stored in the working memory of the authentication server 200a or the like.
  • FIGS. 14A and 14B are sequence diagrams showing an example of data provision processing of the data distribution system according to the present embodiment.
  • the data to be acquired by the service server 410 is not in the data server 310 that the service server 410 can access, but in the data server 300 that the service server 410 cannot access.
  • the service server 410 of the service provider has the data server 310 provide the data of the terminal 110 recorded in the data server 300, and the data of the data server 310 is used as a service. It may be used.
  • the same process is performed when data is provided from the data server 310 to the data server 300 based on the request for data acquisition of the service server 400.
  • the service server 410 generates and transmits a data acquisition request to the terminal 110 that has registered the data in the data server 300 in order to acquire the user data (S501).
  • the data acquisition request for example, it is indicated that the request is made to acquire or refer to the data of the terminal 110.
  • the service server 410 directly transmits the data acquisition request to the terminal 110, it may be transmitted via e-mail or another service provider.
  • the terminal 110 when the terminal 110 receives the request transmitted in step S501, the terminal 110 generates consent information based on the request received by the terminal 110 (S502).
  • the application is introduced in the terminal 110 as the input unit 1013, and the application may generate the consent information based on the request by the operation of the user.
  • the user can select the data that can be provided only by instructing whether to select or deselect from the list of data recorded in the data server 300 that is the data providing destination.
  • the terminal 110 can generate consent information indicating that the data to be requested for data acquisition can be provided with the consent of the user as the consent information regarding the utilization of the data.
  • the terminal 110 generates a smart contract based on the consent information generated in step S502 (S503).
  • This smart contract is executablely programmed to determine if data can be provided based on consent information.
  • the terminal 110 generates transaction data for smart contract registration, including the generated consent information and the smart contract (S504).
  • the terminal 110 transmits the transaction data generated in step S504 to the authentication server 200a (S505).
  • the terminal 110 transmits the generated transaction data to the authentication server 200a, but the terminal 110 may transmit the generated transaction data to the authentication servers 200b and 200c. The same applies when the data is transmitted to the authentication servers 200b and 200c.
  • the authentication server 200a acquires transaction data from the terminal 110 (S506)
  • the authentication server 200a verifies the acquired transaction data (S507).
  • step S507 If the verification of the transaction data is not successful in step S507 (N in S507), the authentication server 200a transmits a notification to that effect to the terminal 110 (S508).
  • the authentication server 200a transfers the transaction data to another authentication server 200 (authentication servers 200b, 200c) (S509).
  • the other authentication server 200 also verifies the transferred transaction data.
  • the authentication server 200a, the authentication server 200b, and the authentication server 200c execute a consensus algorithm (S510).
  • the authentication server 200a, the authentication server 200b, and the authentication server 200c verify that the transaction data is legitimate transaction data (that is, legitimacy), they each generate a block containing the transaction data.
  • the authentication servers 200a, 200b, and 200c record the block including the transaction data in the distributed ledger.
  • the smart contract created by the terminal 110 in this way is recorded in the distributed ledger.
  • the smart contract becomes feasible, that is, operates by being recorded in the distributed ledger (S511).
  • the smart contract can be executed because it is recorded in the distributed ledger and stored in the working memory of the authentication server 200a or the like.
  • the terminal 110 generates the 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 request for data acquisition and the consent to provide the data from the data server 300 to the data server 310.
  • the terminal 110 has an application introduced as an input unit 1013. Therefore, the application may confirm the execution of the smart contract in step S501 after generating the consent information in step S502. As a result, the application can generate the first transaction data including the request for data acquisition and the consent to provide the data from the data server 300 to the data server 310.
  • the terminal 110 transmits the first transaction data generated in step S512 to the authentication server 200a belonging to the first group and the authentication server 210a belonging to the second group (S513).
  • the authentication server 200a is an example of a first authentication server among a plurality of first authentication servers belonging to the first group
  • the authentication server 210a is an example of a plurality of second authentication servers belonging to the second group. This is an example of one of the second authentication servers.
  • the authentication server 210a belonging to the second group acquires the first transaction data from the terminal 110 (S514), it verifies the acquired first transaction data (S515).
  • step S515 If the verification of the first transaction data is not successful in step S515 (N in S515), the authentication server 210a transmits a notification to that effect to the terminal 110 (S516).
  • step 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. Transfer (S517).
  • the other authentication server 210 also verifies the transferred first transaction data.
  • the authentication server 210a, the authentication server 210b, and the authentication server 210c execute a consensus algorithm (S518).
  • the authentication server 210a, the authentication server 210b, and the authentication server 210c verify that the first transaction data is legitimate transaction data (that is, legitimacy), they each generate a block containing the first transaction data.
  • the authentication servers 210a, 210b, 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.
  • the authentication server 200a belonging to the first group acquires the first transaction data from the terminal 110 (S519), it verifies the acquired first transaction data (S520).
  • step S520 If the verification of the first transaction data is not successful in step S520 (N in S520), the authentication server 200a transmits a notification to that effect to the terminal 110 (S521).
  • the authentication server 200a transfers the first transaction data to the other authentication servers 200 (authentication servers 200b, 200c) belonging to the first group. Transfer (S522). The other authentication server 200 also verifies the transferred first transaction data.
  • the authentication server 200a, the authentication server 200b, and the authentication server 200c execute a consensus algorithm (S523).
  • the authentication server 200a, the authentication server 200b, and the authentication server 200c verify that the first transaction data is legitimate transaction data (that is, legitimacy), they generate blocks including the first transaction data, respectively.
  • the 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.
  • 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 transmits a notification to the data server 300 that the designated data can be provided to the data server 310 (S525).
  • the notification includes the data to be provided and the information of the destination. Should be included.
  • the data server 300 can transfer its own data to the data server 310 or make the data server 310 referable.
  • the case where the data server 310 can be referred to includes the case where the data server 310 records the access information to the data server 300 and accesses the data server 300 to acquire the data when the data is used.
  • the data server 300 acquires a notification from the authentication server 200c (S526), the data server 300 provides data to the data server 310 based on the acquired notification (S527).
  • the data server 300 may provide the data to the data server 310 by transferring the data specified by the notification to the data server 310 or making the data server 310 referable.
  • the data server 310 records the data provided by the data server 300 (S528).
  • the service server 410 may make an incentive payment to the terminal 110. Since the processing of the incentive payment is the same as the processing described in steps S317 to S326, the description here will be omitted.
  • the data server 300 should provide the data to the data server 310. it can. Therefore, in the data distribution system according to the embodiment, data can be linked between different groups. In addition, since it is recorded that the data has been transferred or made available to both the distributed ledger belonging to the data providing group and the distributed ledger belonging to the group to which the data is provided and a different group, the data can be recorded. Data can be utilized while ensuring traceability.
  • the terminal 110 In the data provision process shown in FIGS. 14A and 14B, the terminal 110 generates a smart contract for data provision after receiving a request for data provision by the service server 410, but the present invention is not limited to this.
  • the terminal 110 may generate and execute a smart contract for data provision in advance. In this case, when the first transaction data that satisfies the data provision disapproval condition described in the smart contract is recorded in the distributed ledger, the smart contract is executed and the data to be provided is automatically provided. May be good.
  • 15A to 15C are sequence diagrams showing another example of data provision processing of the data distribution system according to the present embodiment.
  • 15A to 15C show the terminal 110, the service server 400, the authentication server 200 and the data server 300 belonging to the first group, the authentication server 210 and the data belonging to the second group, as in FIGS. 14A and 14B.
  • Another example of data provision processing with and from the server 310 is shown.
  • FIGS. 15A to 15C it is assumed that the data to be acquired by the service server 410 is not in the data server 310 that the service server 410 can access, but in the data server 300 that the service server 410 cannot access.
  • the terminal 110 generates consent information based on the user's operation (S551).
  • an application is introduced in the terminal 110 as an input unit 1013, and the application may generate consent information based on a user's operation.
  • the terminal 110 generates a smart contract based on the consent information generated in step S551 (S552).
  • This smart contract is executablely programmed to determine if data can be provided based on consent information.
  • the terminal 110 generates transaction data for smart contract registration, including the generated consent information and the smart contract (S553).
  • steps S554 to S560 are the same as the processes of steps S505 to S511 described above, the description thereof will be omitted.
  • the service server 410 decides to request data acquisition when, for example, determines what kind of data the user wants to acquire (S570).
  • the service server 410 generates a data acquisition request indicating that the data acquisition is requested, and generates the first transaction data of the data acquisition request including the data acquisition request (S571).
  • the service server 410 transmits the first transaction data generated in step S571 to the authentication server 210c belonging to the second group and the authentication server 200c belonging to the first group (S572).
  • the authentication server 200c is an example of the first authentication server of one of the plurality of first authentication servers belonging to the first group
  • the authentication server 210c is an example of the plurality of second authentication servers belonging to the second group. This is an example of one of the second authentication servers.
  • the data to be acquired by the service server 410 is not in the data server 310 that the service server 410 can access, but in the data server 300 that the service server 410 cannot access. Therefore, the service server 410 transmits the first transaction data generated in step S571 to the authentication server 210c and the authentication server 200c.
  • steps S573 to S578 are the same as the processes of steps S514 to S518 described above, except that the main body of the process is the authentication server 210c instead of the authentication server 210a, and thus the description thereof will be omitted.
  • the authentication server 200c acquires the first transaction data from the service server 410 (S579), the authentication server 200c verifies the acquired first transaction data (S580).
  • step S580 as shown in FIG. 15C, when the verification of the first transaction data is not successful (N in S580), the authentication server 200c transmits a notification to that effect to the data server 310 (S581).
  • the authentication server 200c transfers the first transaction data to the other authentication servers 200 (authentication servers 200a, 200b) belonging to the first group. Transfer (S582). The other authentication server 200 also verifies the transferred first transaction data.
  • steps S583 to S588 are the same as the processes of steps S523 to S528 described above, the description thereof will be omitted.
  • the user operates the terminal 110 to generate consent information at an arbitrary timing, but the present invention is not limited to this.
  • the user may operate the terminal 110 to generate consent information periodically or irregularly.
  • the user may generate consent information when the number of service providers is newly increased, or when incentives or feedback from service providers are newly added.
  • the user will generate new consent information based on the presented content. Can be done. As a result, it is possible to increase the opportunity for the user to provide data for utilizing the data of the terminal 110 and the house 100.
  • the data can be utilized while ensuring the traceability of the data.
  • the data server 300 can provide the data to the data server 310.
  • the information collected from the house 100 and the terminal 110 owned by the data servers belonging to one group can be safely provided to the data servers belonging to another group with the consent of the user.
  • the user information can be utilized by a plurality of service providers. Therefore, according to the present embodiment, it is possible to realize a data distribution method or the like that enables data to be linked between different groups.
  • the data is transferred or made visible to both the distributed ledger belonging to the group of the data providing source and the distributed ledger belonging to the group different from the group of the data providing destination. Is recorded.
  • blockchain technology it is possible to utilize blockchain technology to link data belonging to different groups while ensuring data traceability.
  • data can be utilized while ensuring data traceability. Therefore, the user can provide the data with peace of mind.
  • data can be provided between data servers of different groups based on the consent information generated by the house 100 or the terminal 110.
  • data such as user history information while restricting the distribution of user data.
  • the user's consent information can be safely recorded in the distributed ledger using the blockchain technology.
  • the authentication servers 200 and 210 and the data servers 300 and 310 have been described as separate devices, but the present invention is not limited to this.
  • the authentication server 200 and the data server 300, and the authentication server 210 and the data server 310 may be the same device.
  • the data servers 300 and 310 and the service servers 400 and 410 have been described as separate devices, but the present invention is not limited to this.
  • the data server 300 and the service server 400, and the data server 310 and the service server 410 may be the same device.
  • 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 the present invention is not limited to this.
  • the user may generate consent information based on the amount of user data handled by the service provider, the number of services linked with the service provider, and the like. This may not only increase the utilization of data, but also increase service proposals to users by service providers or incentives paid by service providers. Further, the incentive and / or feedback and the like may be recorded in the authentication servers 200 and 210.
  • Each device in the above embodiment is specifically a computer system composed of a microprocessor, a ROM, a RAM, a hard disk unit, a display unit, a keyboard, a mouse, and the like.
  • a computer program is recorded in the RAM or the hard disk unit.
  • the microprocessor operates according to the computer program, each device achieves its function.
  • a computer program is configured by combining a plurality of instruction codes indicating instructions to a computer in order to achieve a predetermined function.
  • Each device in the above embodiment may be composed of a part or all of the constituent elements of one system LSI (Large Scale Integration: large-scale integrated circuit).
  • the system LSI is an ultra-multifunctional LSI manufactured by integrating a plurality of components on one chip, and specifically, is a computer system including a microprocessor, a ROM, a RAM, and the like. .. A computer program is recorded in the RAM. When the microprocessor operates according to the computer program, the system LSI achieves its function.
  • each part of the constituent elements constituting each of the above devices may be individually integrated into one chip, or may be integrated into one chip so as to include a part or all of them.
  • system LSI Although it is referred to as a system LSI here, it may be referred to as an IC, an LSI, a super LSI, or an ultra LSI due to the difference in the degree of integration. Further, the method of making an integrated circuit is not limited to LSI, and may be realized by a dedicated circuit or a general-purpose processor. An FPGA (Field Programmable Gate Array) that can be programmed after the LSI is manufactured, or a reconfigurable processor that can reconfigure the connection and settings of the circuit cells inside the LSI may be used.
  • FPGA Field Programmable Gate Array
  • each of the above devices may be composed of an IC card or a single module that can be attached to and detached from each device.
  • the IC card or the module is a computer system composed of a microprocessor, a ROM, a RAM, and the like.
  • the IC card or the module may include the above-mentioned super multifunctional LSI.
  • the microprocessor operates according to a computer program, the IC card or the module achieves its function. This IC card or this module may have tamper resistance.
  • the present disclosure may be the method shown above. Further, it may be a computer program that realizes these methods by a computer, or it may be a digital signal composed of the computer program.
  • the present disclosure discloses a recording medium in which the computer program or the digital signal can be read by a computer, such as a flexible disk, a hard disk, a CD-ROM, an MO, a DVD, a DVD-ROM, a DVD-RAM, and a BD (Blu-ray). It may be recorded on a Disc (registered trademark), a semiconductor memory, or the like. Further, it may be the digital signal recorded on these recording media.
  • a computer such as a flexible disk, a hard disk, a CD-ROM, an MO, a DVD, a DVD-ROM, a DVD-RAM, and a BD (Blu-ray). It may be recorded on a Disc (registered trademark), a semiconductor memory, or the like. Further, it may be the digital signal recorded on these recording media.
  • the computer program or the digital signal may be transmitted via a telecommunication line, a wireless or wired communication line, a network typified by the Internet, data broadcasting, or the like.
  • the present disclosure is a computer system including a microprocessor and a memory, in which the memory records the computer program, and the microprocessor may operate according to the computer program.
  • This disclosure can be used for data distribution methods, programs and data distribution systems. For example, data distribution methods that enable reference or transfer of data between different groups based on user consent information and promote data utilization. , Programs and data distribution systems.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Business, Economics & Management (AREA)
  • Computing Systems (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • Finance (AREA)
  • Strategic Management (AREA)
  • Development Economics (AREA)
  • Theoretical Computer Science (AREA)
  • Accounting & Taxation (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Economics (AREA)
  • Marketing (AREA)
  • General Business, Economics & Management (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Game Theory and Decision Science (AREA)
  • Data Mining & Analysis (AREA)
  • Health & Medical Sciences (AREA)
  • Bioethics (AREA)
  • General Health & Medical Sciences (AREA)
  • Software Systems (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

本開示のデータ流通方法では、第１グループには、複数の第１認証サーバと、第１データサーバとが属しており、第１グループと異なる第２グループには、複数の第２認証サーバと、第２データサーバとが属している。一つの第１認証サーバが、機器のデータを取得または参照することを依頼する旨を示すデータ取得依頼を含む第１トランザクションデータを取得し、第１トランザクションデータを含むブロックを、第１グループに属する一つの第１認証サーバの分散台帳に記録し、一つの第２認証サーバが、第１トランザクションデータを取得し、第１トランザクションデータを含むブロックを、第２グループに属する分散台帳に記録する。そして、第１データサーバに、自身が有する機器のデータを、第２データサーバに転送、または、第２データサーバによる参照可能にさせる。

Description

データ流通方法、プログラム及びデータ流通システム
　本開示は、ユーザから収集したデータを利活用するためのデータ流通方法、プログラム及びデータ流通システムに関する。
　近年、ユーザのデータ及び機器のデータを収集、分析及び流通するシステムが検討されている。今後、ＩｏＴ（Ｉｎｔｅｒｎｅｔ　ｏｆ　Ｔｈｉｎｇｓ）が進展しＡＩ等が普及することにより、従来よりも多くのデータを収集することが可能となるため、収集等したデータの利活用が期待される。
　例えば非特許文献１では、サイバー空間（仮想空間）とフィジカル空間（現実空間）とを高度に融合させたシステムにより、経済発展と社会的課題の解決を両立する、人間中心の社会であるＳｏｃｉｅｔｙ　５．０について開示されている。
　非特許文献１によれば、Ｓｏｃｉｅｔｙ　５．０では、例えば観光またはヘルスケアにおいてパーソナルデータが収集等され利活用されるようになることが述べられている。
Ｓｔｒａｔｅｇｙ　ｆｏｒ　ＰｒｏｍｏｔｉｎｇＤａｔａ　Ｕｔｉｌｉｚａｔｉｏｎ　ｔｏ　Ｒｅａｌｉｚｅ　Ｓｏｃｉｅｔｙ　５．０、インターネット〈ＵＲＬ：https://www.keidanren.or.jp/en/policy/2017/104.html?v=p〉［２０１９年１２月２５日検索］
　しかしながら、ユーザから収集等したデータがどこでどのように活用されているのかがわからない場合、すなわちユーザから収集等したデータのトレーサビリティが確保できない場合、ユーザはデータの漏えいのリスクを心配してデータそのものを提供しないといった問題がある。この問題により、データを利活用できるほどのデータを収集できないことになる。
　本開示は、上述の事情を鑑みてなされたもので、データのトレーサビリティを確保しつつデータを利活用することができるデータ流通方法等を提供することを目的とする。
　上記目的を達成するために、本開示のデータ流通方法は、それぞれ分散台帳を有する複数の認証サーバと複数のデータサーバと機器とからなるデータ流通システムにおけるデータ流通方法であって、第１グループには、前記複数の認証サーバのうちの複数の第１認証サーバと、前記複数のデータサーバのうちの１以上の第１データサーバとが属しており、前記第１グループと異なる第２グループには、前記複数の認証サーバのうちの前記複数の第１認証サーバと異なる複数の第２認証サーバと、前記複数のデータサーバのうちの前記１以上の第１データサーバと異なる１以上の第２データサーバとが属しており、前記データ流通方法では、前記複数の第１認証サーバのうちの一つの第１認証サーバが、前記機器のデータを取得または参照することを依頼する旨を示すデータ取得依頼を含む第１トランザクションデータを取得し、前記一つの第１認証サーバが、前記第１トランザクションデータを含むブロックを、前記第１グループに属する前記一つの第１認証サーバの分散台帳に記録し、前記１以上の第１データサーバに、前記１以上の第１データサーバが有する前記機器のデータを、前記１以上の第２データサーバに転送、または、前記１以上の第２データサーバによる参照可能にさせ、前記複数の第２認証サーバのうちの一つの第２認証サーバが、前記第１トランザクションデータを取得し、前記一つの第２認証サーバが、前記第１トランザクションデータを含むブロックを、前記第２グループに属する前記一つの第２認証サーバの分散台帳に記録する。
　なお、これらの包括的または具体的な態様は、システム、方法、集積回路、コンピュータプログラムまたはコンピュータで読み取り可能なＣＤ－ＲＯＭ等の記録媒体で実現されてもよく、システム、方法、集積回路、コンピュータプログラム及び記録媒体の任意な組み合わせで実現されてもよい。
　本開示によれば、データのトレーサビリティを確保しつつデータを利活用することができるデータ流通方法等を実現できる。
図１は、実施の形態に係るデータ流通システムの全体構成の一例を示す図である。 図２は、実施の形態に係る住宅の全体構成の一例を示す図である。 図３は、図２に示すコントローラの構成の一例を示すブロック図である。 図４は、実施の形態に係る端末の構成の一例を示すブロック図である。 図５は、実施の形態に係る認証サーバの構成の一例を示すブロック図である。 図６は、ブロックチェーンのデータ構造を示す説明図である。 図７は、実施の形態に係るデータサーバの一例を示すブロック図である。 図８は、実施の形態に係るサービスサーバの一例を示すブロック図である。 図９Ａは、実施の形態に係るデータ流通システムの全体シーケンス図である。 図９Ｂは、実施の形態に係るデータ流通システムの全体シーケンス図である。 図１０は、実施の形態に係る端末と認証サーバとの間での同意情報登録処理を示すシーケンス図である。 図１１は、実施の形態に係る住宅と認証サーバとデータサーバとの間でのデータ登録処理を示すシーケンス図である。 図１２Ａは、実施の形態に係る端末と認証サーバとデータサーバとサービスサーバとの間でのデータ参照処理を示すシーケンス図である。 図１２Ｂは、実施の形態に係る端末と認証サーバとデータサーバとサービスサーバとの間でのデータ参照処理を示すシーケンス図である。 図１３は、実施の形態に係る認証サーバとサービスサーバとの間でのインセンティブ支払いに関するスマートコントラクト登録処理を示すシーケンス図である。 図１４Ａは、実施の形態に係るデータ流通システムのデータ提供処理の一例を示すシーケンス図である。 図１４Ｂは、実施の形態に係るデータ流通システムのデータ提供処理の一例を示すシーケンス図である。 図１５Ａは、実施の形態に係るデータ流通システムのデータ提供処理の別の一例を示すシーケンス図である。 図１５Ｂは、実施の形態に係るデータ流通システムのデータ提供処理の別の一例を示すシーケンス図である。 図１５Ｃは、実施の形態に係るデータ流通システムのデータ提供処理の別の一例を示すシーケンス図である。
　本開示の一実施態様のデータ流通方法は、それぞれ分散台帳を有する複数の認証サーバと複数のデータサーバと機器とからなるデータ流通システムにおけるデータ流通方法であって、第１グループには、前記複数の認証サーバのうちの複数の第１認証サーバと、前記複数のデータサーバのうちの１以上の第１データサーバとが属しており、前記第１グループと異なる第２グループには、前記複数の認証サーバのうちの前記複数の第１認証サーバと異なる複数の第２認証サーバと、前記複数のデータサーバのうちの前記１以上の第１データサーバと異なる１以上の第２データサーバとが属しており、前記データ流通方法では、前記複数の第１認証サーバのうちの一つの第１認証サーバが、前記機器のデータを取得または参照することを依頼する旨を示すデータ取得依頼を含む第１トランザクションデータを取得し、前記一つの第１認証サーバが、前記第１トランザクションデータを含むブロックを、前記第１グループに属する前記一つの第１認証サーバの分散台帳に記録し、前記１以上の第１データサーバに、前記１以上の第１データサーバが有する前記機器のデータを、前記１以上の第２データサーバに転送、または、前記１以上の第２データサーバによる参照可能にさせ、前記複数の第２認証サーバのうちの一つの第２認証サーバが、前記第１トランザクションデータを取得し、前記一つの第２認証サーバが、前記第１トランザクションデータを含むブロックを、前記第２グループに属する前記一つの第２認証サーバの分散台帳に記録する。
　これにより、データ提供元の第１グループに属する分散台帳とデータ提供先の第２グループに属する分散台帳との両方に、データが転送されたまたは参照可能にされたことが記録される。このようにして、異なるグループに属するデータの連携を行うことができる。よって、異なるグループ間であっても、データのトレーサビリティを確保しつつ、データを利活用することができるデータ流通方法等を実現できる。
　また、前記データ流通システムは、さらにサービスサーバを含み、前記データ流通方法では、前記サービスサーバが、前記第１トランザクションデータを生成して、前記一つの第１認証サーバ及び前記一つの第２認証サーバに送信し、前記一つの第１認証サーバが前記第１トランザクションデータを取得した際、前記一つの第１認証サーバが、前記機器から得た同意情報であって前記データの利活用に関する同意情報に基づいて前記データを前記１以上の第１データサーバから前記１以上の第２データサーバに提供可能であるかを判断し、前記１以上の第１データサーバに、前記１以上の第１データサーバが有する前記機器のデータを、前記１以上の第２データサーバに転送、または、前記１以上の第２データサーバによる参照可能にさせてもよい。
　これにより、データのトレーサビリティを確保しつつ、ユーザの同意の元にデータを利活用することができる。
　また、さらに、前記サービスサーバが、前記１以上の第１データサーバにより、前記機器のデータが、前記１以上の第２データサーバに転送、または、前記１以上の第２データサーバによる参照可能にされたことを確認した場合、前記機器に対してトークンを発行するための第２トランザクションデータを生成し、前記一つの第１認証サーバが、前記第２トランザクションデータを取得し、前記一つの第１認証サーバが、前記第２トランザクションデータを含むブロックを、前記第１グループに属する前記一つの第１認証サーバの分散台帳に記録し、前記一つの第１認証サーバが、記録した前記第２トランザクションデータに基づき、トークンを発行することを実行可能にプログラム化されたスマートコントラクトを動作させることで、前記スマートコントラクトに前記機器に対してトークンを発行させてもよい。
　また、前記一つの第１認証サーバが、前記同意情報に基づき前記データを提供可能であるかを判断することを実行可能にプログラム化されたスマートコントラクトを取得し、前記一つの第１認証サーバが、前記第１トランザクションデータを取得した場合、取得した前記第１トランザクションデータに基づき前記スマートコントラクトを実行することで、前記データを前記１以上の第１データサーバから前記１以上の第２データサーバに提供可能であると判断したとき、前記１以上の第１データサーバに、前記１以上の第１データサーバが有する前記機器のデータを、前記１以上の第２データサーバに転送、または、前記１以上の第２データサーバによる参照可能にさせてもよい。
　また、前記一つの第１認証サーバの分散台帳に記録する際、前記一つの第１認証サーバが、取得した前記第１トランザクションデータの検証を行い、前記一つの第１認証サーバが、前記検証を行うことで前記第１トランザクションデータの正当性を確認した場合、前記複数の第１認証サーバのうちの前記一つの第１認証サーバを除く複数の第１認証サーバとともに、前記第１トランザクションデータの正当性について合意するためのコンセンサスアルゴリズムを実行し、前記コンセンサスアルゴリズムによって前記第１トランザクションデータの正当性について合意された場合、前記一つの第１認証サーバが、前記第１トランザクションデータを含むブロックを前記第１グループに属する前記一つの第１認証サーバの分散台帳に記録するとしてもよい。
　また、前記一つの第２認証サーバの分散台帳に記録する際、前記一つの第２認証サーバが、取得した前記第１トランザクションデータの検証を行い、前記一つの第２認証サーバが、前記検証を行うことで前記第１トランザクションデータの正当性を確認した場合、前記複数の第２認証サーバのうちの前記一つの第２認証サーバを除く複数の第２認証サーバとともに、前記第１トランザクションデータの正当性について合意するためのコンセンサスアルゴリズムを実行し、前記コンセンサスアルゴリズムによって前記第１トランザクションデータの正当性について合意された場合、前記一つの第２認証サーバが、前記第１トランザクションデータを含むブロックを前記第２グループに属する前記一つの第２認証サーバの分散台帳に記録するとしてもよい。
　また、本開示の一実施態様のデータ流通システムは、それぞれ分散台帳を有する複数の認証サーバと複数のデータサーバとを備えるデータ流通システムであって、第１グループには、前記複数の認証サーバのうちの複数の第１認証サーバと、前記複数のデータサーバのうちの１以上の第１データサーバとが属しており、前記第１グループと異なる第２グループには、前記複数の認証サーバのうちの前記複数の第１認証サーバと異なる複数の第２認証サーバと、前記複数のデータサーバのうちの前記１以上の第１データサーバと異なる１以上の第２データサーバとが属しており、前記複数の第１認証サーバのうちの一つの第１認証サーバは、機器のデータを取得または参照することを依頼する旨を示すデータ取得依頼を含む第１トランザクションデータを取得する第１通信部と、前記一つの第１認証サーバが、前記第１トランザクションデータを含むブロックを、前記第１グループに属する前記一つの第１認証サーバの分散台帳に記録する第１記録部と、前記１以上の第１データサーバに、前記１以上の第１データサーバが有する前記機器のデータを、前記１以上の第２データサーバに転送、または、前記１以上の第２データサーバによる参照可能にさせる実行部と、を備え、前記複数の第２認証サーバのうちの一つの第２認証サーバは、前記第１トランザクションデータを取得する第２通信部と、前記一つの第２認証サーバが、前記第１トランザクションデータを含むブロックを、前記第２グループに属する前記一つの第２認証サーバの分散台帳に記録する第２記録部とを備える。
　以下、図面を参照しながら、実施の形態について説明する。なお、以下で説明する実施の形態は、いずれも本開示の一具体例を示すものである。従って、以下の実施の形態で示される数値、形状、材料、構成要素、構成要素の配置及び接続形態、ステップ、ステップの順序等は、本開示の一例であり、本開示を限定する主旨ではない。また、以下の実施の形態における構成要素のうち、本開示の一形態に係る実現形態を示す独立請求項に記載されていない構成要素については、任意の構成要素として説明される。本開示の実現形態は、現行の独立請求項に限定されるものではなく、他の独立請求項によっても表現され得る。
　（実施の形態）
　まず、本開示のシステム構成について説明する。
　［１．　システム構成］
　本開示のデータ流通システムは、データ提供元のグループに属する分散台帳とデータ提供先のグループに属する分散台帳との両方に、データが転送されたまたは参照可能にされたことを記録する。このようにして、本開示のデータ流通システムは、ブロックチェーン技術を活用して、データのトレーサビリティを確保しつつ、異なるグループに属するデータの連携を行うことができる。つまり、本開示のデータ流通システムは、データのトレーサビリティを確保しつつ、当該データの利活用を行うことができる。よって、ユーザは安心してデータを提供することができる。
　以下では、図面を参照しながら実施の形態におけるデータ流通システム等の説明を行う。
　［１．１　データ流通システム１０の全体構成］
　図１は、本実施の形態に係るデータ流通システム１０の全体構成の一例を示す図である。データ流通システム１０は、図１に示すように、住宅１００と、端末１１０と、認証サーバ２００ａ、２００ｂ、２００ｃ、２１０ａ、２１０ｂ、２１０ｃと、データサーバ３００、３１０と、サービスサーバ４００、４１０とを備える。これらは、通信ネットワーク５００で接続されている。
　認証サーバ２００ａ、２００ｂ、２００ｃ、２１０ａ、２１０ｂ、２１０ｃは、ブロックチェーンのトランザクションデータ及びブロックが電子的に記録される分散台帳を有する記憶装置と接続する。なお、認証サーバ２００は、当該記憶装置と通信ネットワーク５００を介して接続されていてもよいし、内部に当該記憶装置を備えるとしてもよい。
　また、認証サーバ２００ａ、２００ｂ、２００ｃとデータサーバ３００とは１つのグループ（以下、第１グループと称する）を形成し、認証サーバ２００ａ、２００ｂ、２００ｃは、ブロックチェーン技術を用いてデータサーバ３００のデータを管理しているとして説明する。認証サーバ２００ａ、２００ｂ、２００ｃは、以下、認証サーバ２００と表現される場合がある。同様に、認証サーバ２１０ａ、２１０ｂ、２１０ｃとデータサーバ３１０とは、第１グループと異なる１つのグループ（以下、第２グループと称する）を形成し、認証サーバ２１０ａ、２１０ｂ、２１０ｃは、ブロックチェーン技術を用いてデータサーバ３１０のデータを管理しているとして説明する。認証サーバ２１０ａ、２１０ｂ、２１０ｃは、以下、認証サーバ２１０と表現される場合がある。なお、第１グループと、第２グループとは、例えばブロックチェーンの異なるプラットフォームの一例であり、それぞれに属する分散台帳は、異なるトランザクションデータが含まれている。
　［１．２　住宅１００の構成］
　図２は、本実施の形態に係る住宅１００の全体構成の一例を示す図である。
　住宅１００は、ユーザのデータを取得または収集する本開示に係る機器の一例である。取得または収集されるデータは、例えばユーザの健診データ、睡眠データ、血圧データ、体重データ、運動データ等のヘルスケアデータであってもよいが、これに限らない。取得または収集されるデータは、ヘルスケアデータに限らず、心拍等のバイタルデータを含むユーザパーソナルデータであってもよいし、測定データであってもよいし、機器の動作履歴または機器の操作履歴等の機器の履歴情報であってもよい。このように、取得または収集されるデータは、サービス事業者が利活用できるデータであればよい。
　本実施の形態では、住宅１００は、図２に示すように、コントローラ１０１と、太陽光発電装置１０２と、蓄電池１０３と、エアコン１０４と、体組成計１０５と、血圧計１０６とを備える。これらは通信ネットワークで接続されている。
　なお、以下では、住宅１００により取得または収集されるデータは、第１グループに属するデータサーバ３００に記憶されるとして説明する。
　＜コントローラ１０１＞
　コントローラ１０１は、エアコン１０４、体組成計１０５及び血圧計１０６等の宅内機器の制御を行う。また、制御部１０１１は、太陽光発電装置１０２及び蓄電池１０３の動作状況を表示してもよい。
　また、コントローラ１０１は、宅内機器の動作履歴または操作履歴等の履歴情報を収集してもよいし、太陽光発電装置１０２及び蓄電池１０３の動作状況の履歴情報を収集してもよい。また、コントローラ１０１は、宅内機器により測定された測定データを収集してもよい。
　さらに、コントローラ１０１は、収集した履歴情報及び測定データ等のデータを、データサーバ３００に送信してもよいし、生成したトランザクションデータを認証サーバ２００に送信してもよい。
　＜太陽光発電装置１０２＞
　太陽光発電装置１０２は、太陽電池を用いて太陽光を直接的に電力に変換する発電方式が搭載された装置である。太陽光発電装置１０２が発電した電力は、住宅１００内で使用されたり、蓄電池１０３に蓄電されたりする。なお、太陽光発電装置１０２は必須の構成ではなく、住宅１００に備えられていなくてもよい。
　＜蓄電池１０３＞
　蓄電池１０３は、太陽光発電装置１０２が発電した電力を蓄電する。なお、蓄電池１０３は必須の構成ではなく、住宅１００に備えられていなくてもよい。
　＜エアコン１０４、体組成計１０５及び血圧計１０６＞
　エアコン１０４、体組成計１０５及び血圧計１０６は、ユーザが利用する宅内機器であるが、本開示の機器の一例であってもよい。例えばエアコン１０４の動作履歴または操作履歴等の履歴情報は、データサーバ３００に送信される。また、体組成計１０５及び血圧計１０６の動作履歴または操作履歴等の履歴情報、体組成計１０５により測定された体重データ、及び／または血圧計１０６により測定された血圧データ等のユーザの測定データもデータサーバ３００に送信される。なお、これらのデータは、コントローラ１０１を経由してデータサーバ３００に送信されてもよいし、直接データサーバ３００に送信されてもよい。
　以下、コントローラ１０１の構成の一例について説明する。
　［１．３　コントローラ１０１の構成］
　図３は、図２に示すコントローラ１０１の構成の一例を示すブロック図である。
　コントローラ１０１は、プロセッサ（不図示）と、プロセッサに所定の処理を実行させるプログラムが記憶されたメモリ（不図示）とを備える。つまり、コントローラ１０１は、プロセッサがメモリを用いて所定のプログラムを実行することで実現される。本実施の形態では、コントローラ１０１は、図３に示すように、制御部１０１１、トランザクションデータ生成部１０１２と、入力部１０１３と、記録部１０１４と、通信部１０１５とを備える。
　＜制御部１０１１＞
　制御部１０１１は、宅内機器の制御を行ってもよい。図２に示す例では、制御部１０１１は、エアコン１０４、体組成計１０５及び血圧計１０６等の宅内機器を操作したり、宅内機器の動作履歴、状態を管理したりする。また、制御部１０１１は、太陽光発電装置１０２及び蓄電池１０３の動作状況を表示してもよい。例えば、制御部１０１１は、太陽光発電装置１０２での発電状況または蓄電池１０３の蓄電状態を表示してもよい。また、制御部１０１１は、宅内機器の状態または体組成計１０５または血圧計１０６で測定したバイタルデータを表示してもよい。
　また、制御部１０１１は、宅内機器の動作履歴または操作履歴等の履歴情報を収集してもよいし、太陽光発電装置１０２及び蓄電池１０３の動作状況の履歴情報を収集してもよい。また、制御部１０１１は、宅内機器により測定された測定データを収集してもよい。
　＜入力部１０１３＞
　入力部１０１３は、取得または収集したデータの利活用に関する同意情報を生成する。ここで、同意情報は、取得または収集したデータが利活用されることについてユーザが同意している内容を示す情報であり、ユーザの操作に基づいて生成される。同意情報は、例えば入力部１０１３が提供するデータ提供先のサービス事業者の一覧またはデータの一覧の中から、選択または選択を外すことで生成されてもよい。この場合、同意情報には、ユーザが同意したデータ提供可能なサービス事業者またはユーザが同意した提供可能なデータもしくはデータの種類が含まれる。つまり、同意情報には、ユーザが提供を同意したサービス事業者、または、データもしくはデータの種類が含まれる。なお、同意情報は、例えば入力部１０１３が提供するデータ提供先からみた第３者であって信頼度またはインセンティブに基づきユーザの所定の基準により選別される第３者にデータを提供または参照させることを同意する情報であってもよい。第３者は、入力部１０１３が提供するデータ提供先が属するグループと異なっていてもよい。さらに、同意情報は、フィードバックが一定以上である場合に提供することを同意する情報が含まれていてもよい。
　また、入力部１０１３は、生成した同意情報に基づいて、スマートコントラクトを生成してもよい。ここで、このスマートコントラクトは、データを提供可能であるかを判断することを実行可能にプログラム化されたものである。このスマートコントラクトには、入力部１０１３により生成された同意情報が含まれてもよい。
　なお、入力部１０１３は、コントローラ１０１にインストールされたアプリケーションであってもよく、その場合には、インストールされたアプリケーションが入力部１０１３の上記機能を実現する。
　＜トランザクションデータ生成部１０１２＞
　トランザクションデータ生成部１０１２は、ブロックチェーンにおけるトランザクションデータを生成する。本実施の形態では、トランザクションデータ生成部１０１２は、入力部１０１３で生成された同意情報を含むトランザクションデータを生成する。より具体的には、トランザクションデータ生成部１０１２は、例えば、ユーザが保有するブロックチェーンアドレスと、ユーザが提供を同意したサービス事業者またはデータもしくはデータの種類を含む同意情報と、署名とを含むトランザクションデータを生成する。なお、トランザクションデータ生成部１０１２は、さらに、識別子を付与してトランザクションデータを生成してもよい。トランザクションデータ生成部１０１２は、ユーザ個別の署名生成鍵を用いて署名を生成する。
　また、トランザクションデータ生成部１０１２は、入力部１０１３で生成されたスマートコントラクトを含むトランザクションデータを生成してもよい。なお、トランザクションデータ生成部１０１２は、入力部１０１３で生成された同意情報とスマートコントラクトとを含むトランザクションデータを生成してもよい。
　また、トランザクションデータ生成部１０１２は、通信部１０１５を介して取得したデータ取得依頼を含むトランザクションデータを生成してもよい。ここで、データ取得依頼は、例えばコントローラ１０１が属するグループと異なるグループに属するデータサーバ３１０が、データを取得するまたは参照可能にする依頼であってもよい。この場合、トランザクションデータ生成部１０１２は、通信部１０１５を介して取得したデータ取得依頼とそれに対する同意情報とを含むトランザクションデータを生成すればよい。
　また、トランザクションデータ生成部１０１２は、制御部１０１１により収集等された履歴情報または測定データ等のデータを示す情報を含むトランザクションデータを生成してもよい。この場合、トランザクションデータ生成部１０１２は、例えば、ユーザが保有するブロックチェーンアドレスと、制御部１０１１で収集等されたデータを示す情報と、署名とを含むトランザクションデータを生成すればよい。ここで、データを示す情報は、例えば、制御部１０１１で収集等されたデータそのものであってもよいし、当該データのハッシュ値でもよいし、当該データのハッシュ値及び当該データの属性情報でもよい。
　データの属性情報には、例えば当該データを収集等したセンサまたは機器の種別が含まれてもよい。また、データが歩数データ、体重データ、体脂肪率データまたは血圧データ等である場合、データの属性情報には、当該データがいつ、どうやって、どの項目で、測定または収集されたかを示すデータ項目等が含まれてもよい。機器が家電機器等の宅内機器の場合も、データには、その動作履歴、動作日時等を示すデータ項目が含まれてもよい。
　トランザクションデータ生成部１０１２は、生成したトランザクションデータを記録部１０１４に記録する。トランザクションデータ生成部１０１２は、通信部１０１５を介して認証サーバ２００に送信する。
　＜記録部１０１４＞
　記録部１０１４は、制御部１０１１で収集した履歴情報及び測定データ等のデータを記録する。また、記録部１０１４は、トランザクションデータ生成部１０１２が生成したトランザクションデータを記録する。また、記録部１０１４は、入力部１０１３で生成された同意情報及びスマートコントラクトを記録してもよい。
　＜通信部１０１５＞
　通信部１０１５は、通信ネットワーク５００を介して、認証サーバ２００、２１０と、データサーバ３００、サービスサーバ４００、４１０と通信を行う。この通信は、ＴＬＳ（Ｔｒａｎｓｐｏｒｔ　Ｌａｙｅｒ　Ｓｅｃｕｒｉｔｙ）によりなされてもよい。この場合、ＴＬＳ通信用の暗号鍵は通信部１０１５で保持してもよい。
　続いて、端末１１０の構成の一例について説明する。
　［１．４　端末１１０の構成］
　図４は、本実施の形態に係る端末１１０の構成の一例を示すブロック図である。端末１１０は、本開示の機器の一例であり、プロセッサがメモリを用いて所定のプログラムを実行することで実現される。端末１１０は、例えばスマートフォンのような表示部及び入力部を有する機器、または、ウェアラブルデバイスのようなユーザの測定データを取得する機器等である。
　本実施の形態では、端末１１０は、図４に示すように、トランザクションデータ生成部１１０１と、入力部１１０２と、データ取得部１１０３と、記録部１１０４と、通信部１１０５とを備える。なお、以下では、端末１１０により取得または収集されるデータは、第１グループに属するデータサーバ３００に記憶されるとして説明する。
　＜入力部１１０２＞
　入力部１１０２は、データの利活用に関するユーザの同意情報を生成する。同意情報は、上述したように、取得または収集したデータが利活用されることについてユーザが同意している内容を示す情報であり、ユーザの操作に基づいて生成される。
　例えば、同意情報は、入力部１１０２が提供するデータ提供先のサービス事業者の一覧またはデータの一覧の中から、選択または選択を外すことで生成されてもよい。この場合、ユーザは、データの活用の目的、データの活用実績、または、データを活用したことによるユーザへのフィードバックもしくはインセンティブを基に、データ提供先のサービス事業者を選択してもよい。インセンティブまたはフィードバックの一例としては、ユーザがデータをサービス事業者に提供した場合に当該サービス事業者からユーザに仮想通貨が支払われることもしくは享受できる情報が表示されることが挙げられる。また、インセンティブまたはフィードバックの一例としては、ユーザが体組成計もしくは血圧計の測定履歴等の測定データをスポーツクラブに提供した場合にスポーツクラブから無料体験または会費の減額を享受できることもしくは享受できる情報が表示されることが挙げられる。
　なお、同意情報は、上記同様に、例えば入力部１１０２が提供するデータ提供先からみた第３者であって信頼度またはインセンティブに基づきユーザの所定の基準により選別される第３者にデータを提供または参照させることを同意する情報であってもよい。第３者は、入力部１１０２が提供するデータ提供先が属するグループと異なっていてもよい。
　また、入力部１１０２は、生成した同意情報に基づいて、データを提供可能であるかを判断することを実行可能にプログラム化されたスマートコントラクトを生成してもよい。
　＜トランザクションデータ生成部１１０１＞
　トランザクションデータ生成部１１０１は、ブロックチェーンにおけるトランザクションデータを生成する。本実施の形態では、トランザクションデータ生成部１１０１は、入力部１１０２で生成された同意情報を含むブロックチェーンにおけるトランザクションデータを生成する。より具体的には、トランザクションデータ生成部１１０１は、例えば、ユーザが保有するブロックチェーンアドレスと、ユーザが提供を同意したサービス事業者またはデータもしくはデータの種類を含む同意情報と、署名とを含むトランザクションデータを生成する。
　なお、トランザクションデータ生成部１１０１は、さらに、識別子を付与してトランザクションデータを生成してもよい。トランザクションデータ生成部１１０１は、ユーザ個別の署名生成鍵を用いて署名を生成すればよい。
　また、トランザクションデータ生成部１１０１は、データ取得部１１０３で取得したデータを示す情報を含むトランザクションデータを生成するとしてもよい。この場合、トランザクションデータ生成部１１０１は、例えば、ユーザが保有するブロックチェーンアドレスと、データ取得部１１０３で取得したデータを示す情報と、署名とを含むトランザクションデータを生成すればよい。データを示す情報は、例えば、データ取得部１１０３で取得したデータそのものであってもよいし、当該データのハッシュ値でもよいし、当該データのハッシュ値及び当該データの属性情報でもよい。
　また、トランザクションデータ生成部１１０１は、入力部１１０２で生成されたスマートコントラクトを含むトランザクションデータを生成してもよい。なお、トランザクションデータ生成部１１０１は、入力部１１０２で生成された同意情報とスマートコントラクトとを含むトランザクションデータを生成してもよい。
　トランザクションデータ生成部１１０１は、生成したトランザクションデータを記録部１１０４に記録する。トランザクションデータ生成部１１０１は、生成したトランザクションデータを、通信部１１０５を介して、認証サーバ２００またはデータサーバ３００に送信する。
　また、トランザクションデータ生成部１１０１は、通信部１１０５を介して取得したデータ取得依頼を含むトランザクションデータを生成してもよい。ここで、データ取得依頼は、例えば端末１１０が属するグループと異なるグループに属するデータサーバ３１０が、データを取得するまたは参照可能にする依頼であってもよい。この場合、トランザクションデータ生成部１１０１は、通信部１１０５を介して取得したデータ取得依頼とそれに対する同意情報とを含むトランザクションデータを生成すればよい。
　＜データ取得部１１０３＞
　データ取得部１１０３は、端末１１０が保有するセンサが得た測定データ等のデータを取得する。例えば端末１１０が加速度センサ及びＧＰＳセンサを保有する場合、データ取得部１１０３は、測定データとして、加速度センサから得た歩数、ＧＰＳセンサから得た位置情報を含む歩数データを取得する。また、データ取得部１１０３は、測定データとして、血圧データを取得してもよいし、心拍データを取得してもよい。つまり、データ取得部１１０３は、サービス事業者が利活用できるデータを取得する。
　データ取得部１１０３は、取得したデータを記録部１１０４に記録する。データ取得部１１０３は、通信部１１０５を介して、データサーバ３００に送信してもよい。
　＜記録部１１０４＞
　記録部１１０４は、トランザクションデータ生成部１１０１が生成したトランザクションデータを記録する。また、記録部１１０４は、データ取得部１１０３が取得したデータを記録する。なお、記録部１１０４は、入力部１１０２が生成した同意情報及びスマートコントラクトを記録してもよい。
　＜通信部１１０５＞
　通信部１１０５は、通信ネットワーク５００を介して、認証サーバ２００、データサーバ３００と通信を行う。この通信は、ＴＬＳによりなされてもよい。この場合、ＴＬＳ通信用の暗号鍵は通信部１１０５で保持してもよい。
　続いて、認証サーバ２００の構成の一例について説明する。
　［１．５　認証サーバ２００、２１０の構成］
　認証サーバ２００、２１０は、住宅１００または端末１１０から取得したデータを管理する。
　なお、上述したように、認証サーバ２００とデータサーバ３００とは第１グループに属しており、認証サーバ２００は、ブロックチェーン技術を用いてデータサーバ３００のデータを管理する。ここで、認証サーバ２００すなわち認証サーバ２００ａ、２００ｂ、２００ｃは、複数の第１認証サーバの一例であり、認証サーバ２００ａは、複数の第１認証サーバのうちの一つの第１認証サーバの一例である。
　また、認証サーバ２１０とデータサーバ３１０とは第２グループに属しており、認証サーバ２１０は、ブロックチェーン技術を用いてデータサーバ３１０のデータを管理する。ここで、認証サーバ２１０すなわち認証サーバ２１０ａ、２１０ｂ、２１０ｃは、複数の第２認証サーバの一例であり、例えば認証サーバ２１０ｃは、複数の第２認証サーバのうちの一つの第２認証サーバの一例である。
　認証サーバ２００ａ、２００ｂ、２００ｃ、２１０ａ、２１０ｂ、２１０ｃは同様の構成であるため、以下では、認証サーバ２００ａを例に挙げて説明する。
　図５は、本実施の形態に係る認証サーバ２００ａの構成の一例を示すブロック図である。
　認証サーバ２００ａは、図５に示すように、トランザクションデータ検証部２１１と、ブロック生成部２１２と、同期部２１３と、スマートコントラクト実行部２１４と、記録部２１５と、通信部２１６とを備える。認証サーバ２００ａは、プロセッサがメモリを用いて所定のプログラムを実行することで実現され得る。以下、各構成要素について説明する。
　＜トランザクションデータ検証部２１１＞
　トランザクションデータ検証部２１１は、取得したトランザクションデータを検証する。具体的には、住宅１００または端末１１０等の機器からのトランザクションデータを取得すると、トランザクションデータ検証部２１１は、トランザクションデータのフォーマットが合っているか、及び署名が正当であるかを検証する。例えば、データ取得依頼を含むトランザクションデータを検証する場合、トランザクションデータ検証部２１１は、当該トランザクションデータに含まれるアドレス、データ取得依頼及び署名が正当であるかを検証する。なお、例えばデータを示す情報を含むトランザクションデータを検証する場合、トランザクションデータ検証部２１１は、当該トランザクションデータに含まれるアドレス、データを示す情報及び署名が正当であるかを検証すればよい。
　このように、トランザクションデータ検証部２１１は、取得したトランザクションデータの正当性を確認することでトランザクションデータを検証する。
　トランザクションデータ検証部２１１は、検証した結果、トランザクションデータの正当性を確認した場合、そのトランザクションデータを記録部２１５に記録する。ここで、正当なトランザクションデータと判断した場合は、同期部２１３へ通知する。
　＜ブロック生成部２１２＞
　ブロック生成部２１２は、トランザクションデータ検証部２１１においてトランザクションデータの検証が成功した場合、複数の認証サーバ２００の間で、トランザクションデータについてのコンセンサスアルゴリズムを実行する。ここで、コンセンサスアルゴリズムは、ＰＢＦＴ（Ｐｒａｃｔｉｃａｌ　Ｂｙｚａｎｔｉｎｅ　Ｆａｕｌｔ　Ｔｏｌｅｒａｎｃｅ）とよばれるコンセンサスアルゴリズムを用いてもよいし、ＰｏＷ（Ｐｒｏｏｆ　ｏｆ　Ｗｏｒｋ）等その他の公知のコンセンサスアルゴリズムを用いてもよい。
　本実施の形態では、ブロック生成部２１２は、同一グループすなわち第１グループに属する認証サーバ２００ａ、認証サーバ２００ｂ及び認証サーバ２００ｃの間でコンセンサスアルゴリズムを実行する。すなわち、ブロック生成部２１２は、まず、１以上のトランザクションデータを含むブロックチェーンのブロックを生成する。次に、ブロック生成部２１２は、コンセンサスアルゴリズムを実行する。そして、ブロック生成部２１２は、コンセンサスアルゴリズムを実行することで合意形成ができた場合、生成したブロックを記録部２１５に記録する。ブロック生成部２１２により生成されたブロックは、記録部２１５によりブロックチェーンに接続されて記録される。
　ここで、ブロックチェーンのデータ構造について説明する。
　図６は、ブロックチェーンのデータ構造を示す説明図である。
　ブロックチェーンは、その記録単位であるブロックがチェーン（鎖）状に接続されたものである。それぞれのブロックは、複数のトランザクションデータと、直前のブロックのハッシュ値とを有している。具体的には、ブロックＢ２には、その前のブロックＢ１のハッシュ値が含まれている。そして、ブロックＢ２に含まれる複数のトランザクションデータと、ブロックＢ１のハッシュ値とから演算されたハッシュ値が、ブロックＢ２のハッシュ値として、ブロックＢ３に含められる。このように、前のブロックの内容をハッシュ値として含めながら、ブロックをチェーン状に接続することで、接続されたトランザクションデータの改ざんを有効に防止する。
　仮に過去のトランザクションデータが変更されると、ブロックのハッシュ値が変更前と異なる値になり、改ざんしたブロックを正しいものとみせかけるには、それ以降のブロックすべてを作り直さなければならず、この作業は現実的には非常に困難である。
　＜同期部２１３＞
　同期部２１３は、同一グループすなわち第１グループに属する複数の認証サーバ２００（認証サーバ２００ａ～２００ｃ）の間でブロックチェーンのブロック、または、トランザクションデータの同期を行う。
　複数の認証サーバ２００の同期部２１３では、ｐｅｅｒ ｔｏ　ｐｅｅｒでブロックチェーンのトランザクションデータの同期を行う。そして、同期部２１３は、同期が行われたブロックチェーンのトランザクションデータを記録部２１５に記録する。例えば、同期部２１３は、トランザクションデータ検証部２１１においてトランザクションデータの正当性が検証されると、他の認証サーバ２００である認証サーバ２００ｂ、２００ｃに検証済みのトランザクションデータを転送する。また、同期部２１３は、他の認証サーバ２００から検証済みのトランザクションデータを受信した場合、受信した検証済みのトランザクションデータを記録部２１５に記録する。
　＜スマートコントラクト実行部２１４＞
　スマートコントラクト実行部２１４は、分散台帳に記録されているスマートコントラクトを、ワーキングメモリに格納する。スマートコントラクト実行部２１４は、ワーキングメモリに格納されるスマートコントラクトを実行する。
　例えば、スマートコントラクト実行部２１４は、データ取得依頼を含むトランザクションデータを含むブロックが生成されて認証サーバ２００ａの分散台帳に記録されると、ユーザの同意情報に基づいて生成されたスマートコントラクトをワーキングメモリに格納する。スマートコントラクト実行部２１４は、ワーキングメモリに格納したスマートコントラクトを実行することで、実行されたスマートコントラクトに、データ提供可否を判断させることができる。また、実行されたスマートコントラクトは、データ提供可否の判断結果の通知をしたり、データ取得依頼を含むトランザクションデータに含まれるブロックチェーンアドレスに対して、アクセス権の付与を行ったりする。このように、スマートコントラクト実行部２１４は、例えばサービスサーバ４００からのアクセスをトリガにして、スマートコントラクトを実行することで、データサーバ３００が保有するデータに対するサービスサーバ４００のアクセス管理ができる。
　なお、データ取得依頼が認証サーバ２００ａと属する第１グループと異なる第２グループに属するデータサーバ３１０等がデータを取得するまたは参照可能にする依頼である場合、実行されたスマートコントラクトは、次のように動作する。すなわち、実行されたスマートコントラクトは、ユーザの同意情報に基づいて第２グループに属するデータサーバ３１０等に対するデータ提供可否を判断する。そして、実行されたスマートコントラクトは、提供可能であると判断したとき、第１グループに属するデータサーバ３００に、ユーザのデータを、データサーバ３１０に転送、または、データサーバ３１０により参照可能にさせればよい。このように、スマートコントラクト実行部２１４は、データ取得依頼を含むトランザクションデータが分散台帳に記録されたことをトリガにして、スマートコントラクトを実行して、データサーバ３００が保有するデータを異なるグループに提供する。また、分散台帳にデータが転送されたまたは参照可能にされたことが記録されるので、データのトレーサビリティを確保することができる。
　また、例えば、スマートコントラクト実行部２１４は、インセンティブ支払いまたはフィードバック提供に関する情報を含むトランザクションデータが分散台帳に記録されると、インセンティブ支払いまたはフィードバック提供に基づいて生成されたスマートコントラクトをワーキングメモリに格納する。スマートコントラクト実行部２１４は、ワーキングメモリに格納したスマートコントラクトを実行することで、実行されたスマートコントラクトに、インセンティブ支払いまたはフィードバック提供をさせることができる。インセンティブ支払いまたはフィードバック提供は、インセンティブ支払いまたはフィードバック提供をした旨の通知をすることでもよいし、ユーザに対してインセンティブ支払いまたはフィードバック提供をすることでもよい。
　＜記録部２１５＞
　記録部２１５は、トランザクションデータをブロックに含めて、認証サーバ２００ａの分散台帳に記録する。当該分散台帳は、記録部２１５の内部に構成されていてもよいし、認証サーバ２００ａの外部記憶装置の内部に構成されていてもよい。
　なお、当該トランザクションデータは、住宅１００または端末１１０から取得したトランザクションデータを含む。
　本実施の形態では、記録部２１５は、本開示の機器から受信したトランザクションデータの正当性が確認された場合、当該トランザクションデータを含むブロックを認証サーバ２００ａの分散台帳に記録する。なお、分散台帳に記録されるブロックチェーンのブロックは、サービスサーバ４００、住宅１００または端末１１０に公開されてもよい。
　＜通信部２１６＞
　通信部２１６は、住宅１００、端末１１０、認証サーバ２００ｂ、２００ｃ、データサーバ３００、及びサービスサーバ４００との通信を行う。また、通信部２１６は、認証サーバ２１０との通信を行う場合もある。これらの通信は、ＴＬＳによりなされてもよい。この場合、ＴＬＳ通信用の暗号鍵は通信部２１６で保持するとしてもよい。
　このように、認証サーバ２００ａは、住宅１００または端末１１０から取得したデータの正当性を検証したり、データ提供の可否を管理したり、サービスサーバ４００にデータ提供したりするための処理を行う。また、認証サーバ２００ａは、自身が属する第１グループと異なる第２グループに対するデータ提供の可否を管理したり、第２グループにデータ提供したりするための処理を行う。なお、ここでのデータ提供は、例えばデータの転送でもよいし、データを参照可能にすることでもよい。
　また、住宅１００または端末１１０から取得されるデータは、データサーバ３００で記録され、認証サーバ２００ａで記録されないとして説明したが、これに限らない。認証サーバ２００ａで当該データが記録されてもよい。この場合、認証サーバ２００ａの分散台帳に、当該データを含めたトランザクションデータとして記録されてもよい。
　次に、データサーバ３００、３１０について説明する。
　［１．６　データサーバ３００、３１０の構成］
　データサーバ３００、３１０は、住宅１００または端末１１０から取得したデータを記録（記憶）することで当該データを管理する。データサーバ３００、３１０は、複数のデータサーバの一例である。データサーバ３００は、１以上の第１データサーバの一例であり、上述したように第１グループに属している。また、データサーバ３１０は、１以上の第１データサーバと異なる１以上の第２データサーバの一例であり、上述したように第２グループに属している。
　データサーバ３００、３１０は、同様の構成であるため、以下では、データサーバ３００を例に挙げて説明する。
　図７は、本実施の形態に係るデータサーバ３００の構成の一例を示すブロック図である。
　データサーバ３００は、図７に示すように、データ管理部３１１と、ユーザ管理部３１２と、記録部３１３と、通信部３１４とを備える。データサーバ３００は、プロセッサがメモリを用いて所定のプログラムを実行することで実現され得る。以下、各構成要素について説明する。
　＜データ管理部３１１＞
　データ管理部３１１は、住宅１００または端末１１０から取得したデータを管理する。本実施の形態では、データ管理部３１１は、住宅１００または端末１１０から取得したデータを記録部３１３に記録する。ここで、取得したデータは、住宅１００または端末１１０等の本開示の機器がユーザから収集等したデータでもよいし、ユーザ情報であってもよい。収集等したデータは、上述したように、ヘルスケアデータに限らず、心拍等のバイタルデータを含むユーザパーソナルデータであってもよいし、測定データであってもよいし、機器の動作履歴または機器の操作履歴等の機器の履歴情報であってもよい。
　また、ユーザ管理部３１２は、取得したデータのユーザ情報を管理する。ユーザ情報は、例えば、端末１１０を利用しているユーザに関する情報、住宅１００内にいるユーザを含む家族構成等のユーザに関する情報である。
　また、データ管理部３１１は、データサーバ３００が属する第１グループにアクセス可能なサービスサーバ４００からデータ提供の依頼を受けたときには、認証サーバ２００の分散台帳に記録されている同意情報に基づいて、ユーザのデータを提供する。例えば、認証サーバ２００で同意情報に基づいて生成されたスマートコントラクトが実行され、データの提供可を示す通知を認証サーバ２００から、データサーバ３００が受信したとする。この場合、さらに、データ管理部３１１は、サービスサーバ４００からデータ提供の依頼を受けたときには、ユーザの当該データを提供する。なお、データ管理部３１１は、サービスサーバ４００から、データ提供の依頼とともに、データ提供してほしいデータに対応するブロックチェーンアドレスも受けてもよい。
　なお、例えば第１グループにアクセスできないが第２グループにアクセスできるサービスサーバ４１０から、第１グループに属する認証サーバ２００ａにデータ提供の依頼を受けた場合には、データ管理部３１１は、次のような動作をする。すなわち、データ管理部３１１は、同意情報に基づいて認証サーバ２００ａによって制御されて、記録部３１３に記録されているユーザのデータを、第２グループに属する例えばデータサーバ３１０に転送、または、データサーバ３１０による参照可能にさせる。このように、データ管理部３１１は、同意情報に基づいて認証サーバ２００ａによって制御されて、異なるグループである例えば第２グループのデータサーバ３１０にデータ提供する。
　＜記録部３１３＞
　記録部３１３は、住宅１００または端末１１０等の本開示の機器から取得したデータを記録する。
　＜通信部３１４＞
　通信部３１４は、通信ネットワーク５００を介して、住宅１００、端末１１０、認証サーバ２００、サービスサーバ４００と通信を行う。また、通信部３１４は、通信ネットワーク５００を介して、データサーバ３１０またはサービスサーバ４００と通信を行ってもよい。これらの通信は、ＴＬＳによりなされてもよい。この場合、ＴＬＳ通信用の暗号鍵は通信部３１４で保持してもよい。
　このように、第１グループに属するデータサーバ３００は、住宅１００または端末１１０から取得したデータを記録する。また、第１グループに属するデータサーバ３００は、スマートコントラクト等、認証サーバ２００の制御等により、異なるグループである第２グループに属するデータサーバ３１０にデータ提供を行う。データ提供は、上述したように、データを転送すること、及び／または、データの参照を可能にすることを含む。
　なお、本実施の形態では、データサーバ３００と認証サーバ２００とは独立したサーバとして説明しているが、これに限らない。データサーバ３００の機能は、認証サーバ２００に含まれて動作してもよい。
　続いて、サービスサーバ４００、４１０の構成の一例について説明する。
　［１．７　サービスサーバ４００の構成］
　サービスサーバ４００、４１０はそれぞれ、異なるサービス事業者が管理するサーバであり、サービス事業者が提供するサービスにおけるユーザ及びサービスの管理を行う。サービス事業者は、例えばスポーツクラブ等である。サービスサーバ４００、４１０はそれぞれ、各端末１１０及び／または住宅１００から取得したデータを活用し、サービスを提供する。本実施の形態では、サービスサーバ４００は、第２グループにアクセスできないが第１グループにアクセスでき、第１グループに属するデータサーバ３００が有するデータを利活用できる。一方、サービスサーバ４１０は、第１グループにアクセスできないが第２グループにアクセスでき、第２グループに属するデータサーバ３１０が有するデータを利活用できる。
　サービスサーバ４００、４１０は、同様の構成であるため、以下では、サービスサーバ４００を例に挙げて説明する。
　図８は、本実施の形態に係るサービスサーバ４００の構成の一例を示すブロック図である。
　サービスサーバ４００は、図８に示すように、サービス管理部４１１と、ユーザ管理部４１２と、トランザクションデータ生成部４１３と、記録部４１４と、通信部４１５とを備える。サービスサーバ４００は、プロセッサがメモリを用いて所定のプログラムを実行することで実現され得る。以下、各構成要素について説明する。
　＜サービス管理部４１１＞
　サービス管理部４１１は、ユーザ管理部４１２が管理するユーザの情報を活用し、サービスを提供する。例えば、サービス管理部４１１は、ユーザの体組成計測値または血圧計測値等の測定データを含むデータをデータサーバ３００から取得し、新たなヘルスケアサービスを提供したり、効果を実証したりする。
　サービス管理部４１１は、ユーザ管理部４１２が管理するユーザの情報を利用して、データの取得を依頼する旨を示すデータ取得依頼を生成し、トランザクションデータ生成部４１３に送信する。サービス管理部４１１は、例えば、ユーザのどのようなデータを取得したいかを決定し、取得したいユーザの属性情報または取得したいデータ種別等を基に、データ取得依頼を生成する。データ取得依頼には、例えば、ユーザの識別子が事前に判明している場合はユーザの識別子を指定した依頼が含まれていてもよいし、ブロックチェーンアドレスが指定した依頼が含まれていてもよいし、属性を指定した依頼が含まれていてもよい。ここでの属性は、住宅１００または端末１１０等の機器の種別でもよいし、機器から取得したデータの種別でもよいし、ユーザの属性でもよい。
　なお、サービス管理部４１１の取得したいデータが、第１グループに属するデータサーバ３００に記録されておらず、第１グループと異なる第２グループに属するデータサーバ３１０にのみ記録されている場合もある。この場合、サービス管理部４１１は、通信部４１５を介して、トランザクションデータ生成部４１３により生成されたデータ取得依頼を含むトランザクションデータを、第１グループに属する認証サーバ２００と第２グループに属する認証サーバ２１０に送信する。第２グループに属する認証サーバ２１０が、第１グループのデータサーバ３００等にデータ提供してもよいと判断した場合、当該認証サーバ２１０の制御により、第２グループに属するデータサーバ３１０が有するデータが第１グループに属するデータサーバ３００に提供される。このようにして、サービス管理部４１１は、取得したいデータが、データサーバ３００に記録されておらず、データサーバ３１０にのみ記録されている場合でも、データサーバ３００に提供されることでデータサーバ３００から当該データを取得することができる。
　また、サービス管理部４１１は、データを取得した場合、取得したデータに対する対価として、取得したデータのユーザに対してインセンティブ支払いまたはフィードバック提供に関する情報を生成し、トランザクションデータ生成部４１３に送信する。ここで、インセンティブ支払いまたはフィードバック提供に関する情報は、取得したデータに対する対価として、ユーザのブロックチェーンアドレスに対して仮想通貨が支払われた旨が含まれていてもよい。なお、サービス管理部４１１は、生成したインセンティブ支払いまたはフィードバック提供に基づいてスマートコントラクトを生成してもよい。この場合、スマートコントラクトには、例えば、取得したデータに対する対価として、ユーザのブロックチェーンアドレスに対して仮想通貨を支払うことを実行するためのプログラムが含まれていてもよい。
　＜ユーザ管理部４１２＞
　ユーザ管理部４１２は、サービスを提供する対象となるユーザの情報を取得し、取得したユーザの情報を管理する。
　＜トランザクションデータ生成部４１３＞
　トランザクションデータ生成部４１３は、サービス管理部４１１により生成されたデータ取得依頼を含むトランザクションデータを生成する。
　また、トランザクションデータ生成部４１３は、サービス管理部４１１により生成されたインセンティブ支払いまたはフィードバック提供に関する情報を含むトランザクションデータを生成する。
　また、トランザクションデータ生成部４１３は、サービス管理部４１１により生成されたインセンティブ支払いまたはフィードバック提供に基づくスマートコントラクトを含むトランザクションデータを生成してもよい。
　＜記録部４１４＞
　記録部４１４は、サービス提供に必要なユーザの情報またはサービスの情報を記録する。また、記録部４１４は、トランザクションデータ生成部４１３が生成したトランザクションデータを記録する。なお、記録部４１４は、サービス管理部４１１により生成されたデータ取得依頼、インセンティブ支払いもしくはフィードバック提供に関する情報、及び、スマートコントラクトを記録してもよい。
　＜通信部４１５＞
　通信部４１５は、通信ネットワーク５００を介して、認証サーバ２００及びデータサーバ３００と通信を行う。この通信は、ＴＬＳによりなされてもよい。この場合、ＴＬＳ通信用の暗号鍵は通信部４１５で保持するとしてもよい。
　［１．８　データ流通システム１０の全体シーケンス］
　続いて、データ流通システム１０の全体シーケンスについて説明する。図９Ａ及び図９Ｂは、本実施の形態に係るデータ流通システム１０の全体シーケンス図である。各処理については後述する。
　図９Ａに示すように、ステップＳ１００では、端末１１０と住宅１００と第１グループに属する認証サーバ２００ａ～２００ｃとの間で同意情報登録処理が行われる。図９Ａでは、例えば端末１１０と第１グループに属する認証サーバ２００ａ～２００ｃとの間で同意情報登録処理が行われる。
　また、ステップＳ２００では、端末１１０と住宅１００と第１グループに属する認証サーバ２００ａ～２００ｃとデータサーバ３００との間でデータ登録処理が行われる。図９Ａでは、例えば住宅１００と第１グループに属する認証サーバ２００ａ～２００ｃとの間でデータ登録処理が行われる。
　また、ステップＳ３００では、端末１１０と住宅１００と認証サーバ２００ａ～２００ｃとデータサーバ３００とサービスサーバ４００との間でデータ参照処理が行われる。
　なお、ステップＳ３００のデータ参照処理は、ステップＳ１００の同意情報登録処理においてユーザの同意情報が登録された後に実行可能になる。図９Ａでは、例えば端末１１０と認証サーバ２００ａ～２００ｃとデータサーバ３００とサービスサーバ４００との間でデータ参照処理が行われる。
　また、ステップＳ５００では、図９Ｂに示すように、端末１１０と、サービスサーバ４００と、第１グループに属する認証サーバ２００及びデータサーバ３００と、第２グループに属する認証サーバ２１０及びデータサーバ３１０との間でデータ提供処理が行われる。ステップＳ５００のデータ提供処理は、ステップＳ２００のデータ登録処理においてユーザのデータが登録された後に実行可能になる。後述するデータ提供処理では、第１グループに属するデータサーバ３００のデータが第２グループに属するデータサーバ３１０に提供される場合について説明する。
　［１．８．１　同意情報登録処理］
　続いて、端末１１０と認証サーバ２００ａ～２００ｃとの間での同意情報登録処理について説明する。
　図１０は、本実施の形態に係る端末１１０と認証サーバ２００ａ～２００ｃとの間での同意情報登録処理を示すシーケンス図である。なお、図１０では、端末１１０が同意情報を登録する場合が示されているが、住宅１００のコントローラ１０１が同意情報を登録する場合でも同様の処理となる。また、図１０では、端末１１０と、第１グループに属する認証サーバ２００ａ～２００ｃとの間での同意情報登録処理が示されているが、これに限らない。住宅１００と第２グループに属する認証サーバ２１０ａ～２１０ｃとの間で同意情報登録処理が行われる場合も同様の処理となる。
　まず、端末１１０は、ユーザの操作に基づいて同意情報を生成する（Ｓ１０１）。ここで、端末１１０には、入力部１０１３としてアプリケーションが導入されており、アプリケーションがユーザの操作に基づいて同意情報を生成してよい。この場合、ユーザは、入力部１０１３が提供するデータ提供先のサービス事業者の一覧またはデータの一覧の中から、選択または選択を外すかを指示するだけで、端末１１０に同意情報を生成させることができる。
　なお、ユーザは、端末１１０に同意情報を生成させる際、サービス事業者からのフィードバックが多いか否かを判断した上で同意情報を生成させてもよい。例えば、ユーザは、データをサービス事業者に提供した場合、仮想通貨が提供されること、または、サービス事業者のクーポンもしくは割引が提供されることといったフィードバックの内容から、選択するデータ提供先（つまりデータ提供の同意）を決めてもよい。また、例えば、ユーザは、データをサービス事業者に提供した場合に提供される仮想通貨の額またはクーポンもしくは割引の額等ユーザへのフィードバックの内容を基に選択するデータ提供先（つまりデータ提供の同意）を決めてもよい。フィードバックの内容は、サービス事業者から公開されるとしてもよいし、認証サーバ２００のブロックチェーンに記録されていてもよい。
　次に、端末１１０は、ステップＳ１０１で生成した同意情報に基づいて、スマートコントラクトを生成する（Ｓ１０２）。このスマートコントラクトは、データを提供可能であるかを判断することを実行可能にプログラム化されたものである。このスマートコントラクトには、ステップＳ１０１で生成された同意情報が含まれてもよい。さらに、このスマートコントラクトには、フィードバックが一定以上である場合に提供するか否かを判断することを実行可能にプログラムが含まれていてもよい。
　次に、端末１１０は、生成した同意情報とスマートコントラクトとを含むトランザクションデータを生成する（Ｓ１０３）。
　次に、端末１１０は、ステップＳ１０３で生成したトランザクションデータを、認証サーバ２００ａに送信する（Ｓ１０４）。なお、図１０に示す例では、端末１１０は、生成したトランザクションデータを認証サーバ２００ａに送信しているが、認証サーバ２００ｂ、２００ｃに送信してもよい。認証サーバ２００ｂ、２００ｃに送信した場合も同様である。
　次に、認証サーバ２００ａは、端末１１０からトランザクションデータを取得すると（Ｓ１０５）、取得した当該トランザクションデータの検証を行う（Ｓ１０６）。
　ステップＳ１０６において、当該トランザクションデータの検証が成功しなかった場合（Ｓ１０６でＮ）、認証サーバ２００ａは、端末１１０にその旨の通知を送信する（Ｓ１０７）。
　一方、ステップＳ１０６において、当該トランザクションデータの検証が成功した場合（Ｓ１０６でＹ）、認証サーバ２００ａは、他の認証サーバ２００（認証サーバ２００ｂ、２００ｃ）に当該トランザクションデータを転送する（Ｓ１０８）。なお、他の認証サーバ２００でも、転送された当該トランザクションデータを検証する。
　次に、認証サーバ２００ａと認証サーバ２００ｂと認証サーバ２００ｃとは、コンセンサスアルゴリズムを実行する（Ｓ１０９）。認証サーバ２００ａと認証サーバ２００ｂと認証サーバ２００ｃとは、当該トランザクションデータが正当なトランザクションデータであること（つまり正当性）を検証すると、それぞれ当該トランザクションデータを含むブロックを生成する。そして、認証サーバ２００ａ、２００ｂ、２００ｃは、当該トランザクションデータを含むブロックを分散台帳に記録する。
　このようにして端末１１０が作成したスマートコントラクトと同意情報とが分散台帳に記録される。
　そして、スマートコントラクトは、分散台帳に記録されることで、実行可能になるすなわち稼働する（Ｓ１１０）。なお、スマートコントラクトは、分散台帳に記録されることで、認証サーバ２００ａ等のワーキングメモリに格納されるので実行可能になる。
　［１．８．２　データ登録処理］
　続いて、住宅１００と認証サーバ２００ａ～２００ｃとデータサーバ３００との間でのデータ登録処理について説明する。
　図１１は、本実施の形態に係る住宅１００と認証サーバ２００ａ～２００ｃとデータサーバ３００との間でのデータ登録処理を示すシーケンス図である。なお、図１１では、住宅１００が取得したデータをデータサーバ３００に登録する場合について示されているが、端末１１０が取得したデータを登録する場合でも同様の処理となる。また、図１１では、住宅１００と、第１グループに属する認証サーバ２００ａ～２００ｃ及びデータサーバ３００との間でのデータ登録処理が示されているが、これに限らない。住宅１００と第２グループに属する認証サーバ２１０ａ～２１０ｃ及びデータサーバ３１０との間でデータ登録処理が行われる場合も同様の処理となる。
　まず、住宅１００は、住宅１００の宅内機器等により得られたデータを取得する（Ｓ２０１）。住宅１００が取得するデータは、例えば、宅内機器の操作履歴でもよいし、太陽光発電装置１０２で発電した電力量でもよいし、蓄電池１０３が出力する電力量データでもよい。また、住宅１００が取得するデータは、エアコン１０４の操作履歴でもよいし、体組成計１０５及び／または血圧計１０６で計測したバイタルデータでもよい。つまり、当該データは、住宅１００により取得され、かつ、サービス事業者が利活用できるデータであればよい。
　次に、住宅１００は、ステップＳ２０１で取得したデータに関する情報を含むデータ登録のトランザクションデータを生成する（Ｓ２０２）。ここでのデータに関する情報は、例えば、当該データのハッシュ値及び当該データの属性情報であるとする。この場合、当該トランザクションデータは、ブロックチェーンアドレス、ハッシュ値、属性情報及び署名を含む。
　次に、住宅１００は、ステップＳ２０１で取得したデータを認証サーバ２００ａに、ステップＳ２０２で生成した当該トランザクションデータをデータサーバ３００に送信する（Ｓ２０３）。なお、図１１に示す例では、住宅１００は、ステップＳ２０１で取得したトランザクションデータを認証サーバ２００ａに送信しているが、認証サーバ２００ｂ、２００ｃに送信してもよい。認証サーバ２００ｂ、２００ｃに送信した場合も同様である。
　次に、データサーバ３００は、住宅１００からデータを取得すると（Ｓ２０４）、データサーバ３００は、ステップＳ２０４で取得したデータを記録する（Ｓ２０５）。
　次に、認証サーバ２００ａは、住宅１００からトランザクションデータを取得すると（Ｓ２０６）、取得したトランザクションデータの検証を行う（Ｓ２０７）。なお、ステップＳ２０４とステップＳ２０６の順番は、この通りではなく、変更してもよい。
　ステップＳ２０７において、トランザクションデータの検証が成功しなかった場合（Ｓ２０７でＮ）、認証サーバ２００ａは、住宅１００にその旨の通知を送信する（Ｓ２０８）。なお、認証サーバ２００ａは、住宅１００にその旨の通知する場合に限らず、データサーバ３００にもその旨を通知するとしてもよい。さらに、この場合、データサーバ３００はステップＳ２０５で記録したデータを削除してもよい。
　一方、ステップＳ２０７において、トランザクションデータの検証が成功した場合（Ｓ２０７でＹ）、認証サーバ２００ａは、他の認証サーバ２００（認証サーバ２００ｂ、２００ｃ）にトランザクションデータを転送する（Ｓ２０９）。なお、他の認証サーバ２００でも、転送されたトランザクションデータを検証する。
　次に、認証サーバ２００ａと認証サーバ２００ｂと認証サーバ２００ｃとは、コンセンサスアルゴリズムを実行する（Ｓ２１０）。認証サーバ２００ａと認証サーバ２００ｂと認証サーバ２００ｃとは、当該トランザクションデータが正当なトランザクションデータであること（つまり正当性）を検証すると、それぞれ当該トランザクションデータを含むブロックを生成する。そして、認証サーバ２００ａ、２００ｂ、２００ｃは、当該トランザクションデータを含むブロックを分散台帳に記録する。
　このようにして、データに関する情報を含むデータ登録のトランザクションデータを含むブロックが分散台帳に記録され、データそのものがデータサーバ３００に記録される。
　［１．８．３　データ参照処理］
　続いて、端末１１０と認証サーバ２００ａ～２００ｃとデータサーバ３００とサービスサーバ４００との間でのデータ参照処理について説明する。
　図１２Ａ及び図１２Ｂは、本実施の形態に係る端末１１０と認証サーバ２００ａ～２００ｃとデータサーバ３００とサービスサーバ４００との間でのデータ参照処理を示すシーケンス図である。図１２Ａ及び図１２Ｂに示す例では、サービスサーバ４００が、データサーバ３００からデータを取得する場合について説明する。なお、端末１１０とサービスサーバ４１０と第２グループに属する認証サーバ２１０ａ～２１０ｃ及びデータサーバ３１０との間でデータ参照処理が行われる場合も同様の処理となる。つまり、サービスサーバ４１０が、データサーバ３１０からデータを取得する場合も同様である。
　まず、図１２Ａにおいて、サービスサーバ４００は、例えば、ユーザのどのようなデータを取得したいかを決定した場合、データ取得の依頼を行うことを決定する（Ｓ３０１）。
　次に、サービスサーバ４００は、データ取得を依頼する旨を示すデータ取得依頼を生成し、データ取得依頼を含むデータ取得依頼のトランザクションデータを生成する（Ｓ３０２）。
　次に、サービスサーバ４００は、生成したトランザクションデータを、認証サーバ２００ｃに送信する（Ｓ３０３）。図１２Ａに示す例では、サービスサーバ４００は、ステップＳ３０２で生成したトランザクションデータを認証サーバ２００ｃに送信しているが、認証サーバ２００ａ、２００ｂに送信してもよい。認証サーバ２００ａ、２００ｂに送信した場合も同様である。
　次に、認証サーバ２００ｃは、サービスサーバ４００から当該トランザクションデータを取得すると（Ｓ３０４）、取得した当該トランザクションデータの検証を行う（Ｓ３０５）。
　ステップＳ３０５において、当該トランザクションデータの検証が成功しなかった場合（Ｓ３０５でＮ）、認証サーバ２００ｃは、サービスサーバ４００にその旨の通知を送信する（Ｓ３０６）。
　一方、ステップＳ３０５において、当該トランザクションデータの検証が成功した場合（Ｓ３０５でＹ）、認証サーバ２００ｃは、他の認証サーバ２００（認証サーバ２００ａ、２００ｂ）に当該トランザクションデータを転送する（Ｓ３０７）。なお、他の認証サーバ２００でも、転送された当該トランザクションデータを検証する。
　次に、認証サーバ２００ａと認証サーバ２００ｂと認証サーバ２００ｃとは、コンセンサスアルゴリズムを実行する（Ｓ３０８）。認証サーバ２００ａと認証サーバ２００ｂと認証サーバ２００ｃとは、当該トランザクションデータが正当なトランザクションデータであること（つまり正当性）を検証すると、それぞれ当該トランザクションデータを含むブロックを生成する。そして、認証サーバ２００ａ、２００ｂ、２００ｃは、当該トランザクションデータを含むブロックを分散台帳に記録する。
　次に、認証サーバ２００ａと認証サーバ２００ｂと認証サーバ２００ｃとは、分散台帳に記録されたスマートコントラクトを実行する（Ｓ３０９）。このスマートコントラクトは、同意情報に基づいて生成されたものであり、分散台帳に記録されたことで、ワーキングメモリに格納されて実行可能になっている。そして、認証サーバ２００で実行されたスマートコントラクトは、同意情報に基づいて、サービスサーバ４００に依頼されたデータの提供が可能か否かを判断する。当該スマートコントラクトは、判断結果の通知を、データサーバ３００とサービスサーバ４００とに送信する（Ｓ３１０）。なお、当該スマートコントラクトは、判断結果の通知を、データサーバ３００とサービスサーバ４００とに送信する場合に限らない。スマートコントラクトは、サービスサーバ４００に依頼されたデータの提供が可能になったことを、ユーザが使用する端末１１０に通知してもよい。
　次に、データサーバ３００とサービスサーバ４００とは、ステップＳ３１０で送信された通知を受信する（Ｓ３１１）。ここで、ステップＳ３１０で送信された通知は、サービスサーバ４００に依頼されたデータの提供が可能である旨を示しているとする。
　次に、サービスサーバ４００は、データサーバ３００に対して、データ提供の依頼を行う（Ｓ３１２）。なお、サービスサーバ４００は、データ提供を取得するためにデータサーバ３００にアクセスするとしてもよい。
　次に、データサーバ３００は、サービスサーバ４００から、データ提供の依頼を取得すると（Ｓ３１３）、ステップＳ３１１で認証サーバ２００ｃから受信した通知を確認し、サービスサーバ４００に依頼されたデータの提供が可能であるかを判断する（Ｓ３１４）。なお、データサーバ３００は、ステップＳ３１４において、ステップＳ３１１で認証サーバ２００ｃから受信した通知を確認し、サービスサーバ４００に依頼されたデータの提供が不可であることを判断すると（Ｓ３１４でＮ）、サービスサーバ４００にその旨の通知を送信する（Ｓ３１５）。
　ステップＳ３１４において、ステップＳ３１１で認証サーバ２００から受信した通知を確認し、サービスサーバ４００に依頼されたデータの提供が可能であることを判断すると（Ｓ３１４でＹ）、データサーバ３００は、サービスサーバ４００に、依頼されたデータを提供する（Ｓ３１６）。
　次に、サービスサーバ４００は、依頼したデータを取得する（Ｓ３１７）。
　すると、サービスサーバ４００は、インセンティブ支払いのトランザクションデータを生成する（Ｓ３１８）。より具体的には、サービスサーバ４００は、インセンティブ支払いに関する情報を含むトランザクションデータを生成する。
　次に、サービスサーバ４００は、ステップＳ３１８で生成したトランザクションデータを、認証サーバ２００ｃに送信する（Ｓ３１９）。なお、図１２Ｂに示す例では、サービスサーバ４００は、生成したトランザクションデータを認証サーバ２００ｃに送信しているが、認証サーバ２００ａ、２００ｂに送信してもよい。認証サーバ２００ａ、２００ｂに送信した場合も同様である。
　次に、認証サーバ２００ｃは、サービスサーバ４００からトランザクションデータを取得すると（Ｓ３２０）、取得したトランザクションデータの検証を行う（Ｓ３２１）。
　ステップＳ３２１において、当該トランザクションデータの検証が成功しなかった場合（Ｓ３２１でＮ）、認証サーバ２００ｃは、サービスサーバ４００にその旨の通知を送信する（Ｓ３２２）。
　一方、ステップＳ３２１において、当該トランザクションデータの検証が成功した場合（Ｓ３２１でＹ）、認証サーバ２００ｃは、他の認証サーバ２００（認証サーバ２００ａ、２００ｂ）に当該トランザクションデータを転送する（Ｓ３２３）。なお、他の認証サーバ２００でも、転送されたトランザクションデータを検証する。
　次に、認証サーバ２００ａと認証サーバ２００ｂと認証サーバ２００ｃとは、コンセンサスアルゴリズムを実行する（Ｓ３２４）。認証サーバ２００ａと認証サーバ２００ｂと認証サーバ２００ｃとは、当該トランザクションデータが正当なトランザクションデータであること（つまり正当性）を検証すると、それぞれ当該トランザクションデータを含むブロックを生成する。そして、認証サーバ２００ａ、２００ｂ、２００ｃは、当該トランザクションデータを含むブロックを分散台帳に記録する。
　次に、認証サーバ２００ａと認証サーバ２００ｂと認証サーバ２００ｃとは、分散台帳に記録された、インセンティブ支払いに関するスマートコントラクトを実行する（Ｓ３２５）。このスマートコントラクトは、インセンティブ支払いに基づいて生成されたものであり、分散台帳に記録されたことで、ワーキングメモリに格納されて実行可能になっている。本実施の形態では、インセンティブ支払いに関するスマートコントラクトが、ユーザに対してインセンティブ支払いを行ってもよい。
　そして、例えば認証サーバ２００ａのスマートコントラクトは、ユーザ（具体的には端末１１０に対してインセンティブ支払いを行った旨のインセンティブ通知を送信する（Ｓ３２６）。
　なお、サービスサーバ４００は、ステップＳ３１８において、フィードバック提供に関する情報を含むトランザクションデータを生成してもよい。この場合、ステップＳ３２５において、フィードバック提供に関するスマートコントラクトが実行されることになる。
　このようにして、端末１１０と認証サーバ２００ａ～２００ｃとデータサーバ３００とサービスサーバ４００との間でデータ参照処理が行われ、その後、インセンティブ支払い処理が行われる。
　なお、図１２Ａに示すデータ参照処理の例では、認証サーバ２００により実行されたスマートコントラクトは、ステップＳ３１０において、その判断結果をデータサーバ３００とサービスサーバ４００とに送信しているが、これに限らない。認証サーバ２００により実行されたスマートコントラクトは、ステップＳ３１０において、さらに、サービスサーバ４００がデータを取得する旨の通知を、ユーザすなわち端末１１０に送信してもよい。
　また、図１２Ａに示すデータ参照処理の例では、ステップＳ３１１及びＳ３１２において、サービスサーバ４００は、認証サーバ２００で実行されたスマートコントラクトの判断結果を受信してから、データ提供を依頼してデータを取得しているが、これに限らない。ステップＳ３０９において、認証サーバ２００で実行されたスマートコントラクトによって、データサーバ３００に記録されたデータであってサービスサーバ４００が提供依頼したデータがサービスサーバ４００に提供されてもよい。
　［１．８．４　インセンティブ支払いに関するスマートコントラクト登録処理］
　続いて、認証サーバ２００ａ～２００ｃとサービスサーバ４００との間でのインセンティブ支払いに関するスマートコントラクト登録処理について説明する。
　図１３は、本実施の形態に係る認証サーバ２００ａ～２００ｃとサービスサーバ４００との間でのインセンティブ支払いに関するスマートコントラクト登録処理を示すシーケンス図である。図１３では、サービスサーバ４００と第１グループに属する認証サーバ２００ａ～２００ｃとの間でスマートコントラクト登録処理が行われている場合の例が示されているが、これに限らない。サービスサーバ４１０と第２グループに属する認証サーバ２１０ａ～２１０ｃとの間で同意情報登録処理が行われる場合も同様の処理となる。
　まず、サービスサーバ４００は、インセンティブ支払いに関するスマートコントラクトを生成する（Ｓ４０１）。
　次に、サービスサーバ４００は、ステップＳ４０１で生成したインセンティブ支払いに関するスマートコントラクトを含む当該スマートコントラクト登録のトランザクションデータを生成する（Ｓ４０２）。
　次に、サービスサーバ４００は、ステップＳ４０２で生成した当該トランザクションデータを、認証サーバ２００ａに送信する（Ｓ４０３）。図１３に示す例では、サービスサーバ４００は、ステップＳ４０２で生成した当該トランザクションデータを認証サーバ２００ａに送信しているが、認証サーバ２００ｂ、２００ｃに送信してもよい。認証サーバ２００ｂ、２００ｃに送信した場合も同様である。
　次に、認証サーバ２００ａは、サービスサーバ４００から当該トランザクションデータを取得すると（Ｓ４０４）、取得した当該トランザクションデータの検証を行う（Ｓ４０５）。
　ステップＳ４０５において、当該トランザクションデータの検証が成功しなかった場合（Ｓ４０５でＮ）、認証サーバ２００ａは、サービスサーバ４００にその旨の通知を送信する（Ｓ４０６）。
　一方、ステップＳ４０５において、当該トランザクションデータの検証が成功した場合（Ｓ４０５でＹ）、認証サーバ２００ａは、他の認証サーバ２００（認証サーバ２００ｂ、２００ｃ）に当該トランザクションデータを転送する（Ｓ４０７）。なお、他の認証サーバ２００でも、転送された当該トランザクションデータを検証する。
　次に、認証サーバ２００ａと認証サーバ２００ｂと認証サーバ２００ｃとは、コンセンサスアルゴリズムを実行する（Ｓ４０８）。認証サーバ２００ａと認証サーバ２００ｂと認証サーバ２００ｃとは、当該トランザクションデータが正当なトランザクションデータであること（つまり正当性）を検証すると、それぞれ当該トランザクションデータを含むブロックを生成する。そして、認証サーバ２００ａ、２００ｂ、２００ｃは、当該トランザクションデータを含むブロックを分散台帳に記録する。
　次に、当該トランザクションデータに含まれるインセンティブ支払いに関するスマートコントラクトは、分散台帳に記録されることで、実行可能になるすなわち稼働する（Ｓ４０９）。インセンティブ支払いに関するスマートコントラクトは、分散台帳に記録されることで、認証サーバ２００ａ等のワーキングメモリに格納されるので実行可能になる。
　［１．８．５　データ提供処理の一例］
　続いて、端末１１０と、サービスサーバ４００と、第１グループに属する認証サーバ２００及びデータサーバ３００と、第２グループに属する認証サーバ２１０及びデータサーバ３１０との間でのデータ提供処理について説明する。
　図１４Ａ及び図１４Ｂは、本実施の形態に係るデータ流通システムのデータ提供処理の一例を示すシーケンス図である。図１４Ａ及び図１４Ｂに示す例では、サービスサーバ４１０の取得したいデータが、サービスサーバ４１０がアクセスできるデータサーバ３１０になく、サービスサーバ４１０がアクセスできないデータサーバ３００にあるとしている。そして、サービスサーバ４１０のデータ取得の依頼を基に、データサーバ３００からデータサーバ３１０にデータが提供される場合について説明する。ここで、具体的なユースケースとしては、サービス事業者のサービスサーバ４１０は、データサーバ３００に記録している端末１１０のデータをデータサーバ３１０に提供してもらい、データサーバ３１０のデータをサービスに活用する場合がある。なお、サービスサーバ４００のデータ取得の依頼を基に、データサーバ３１０からデータサーバ３００にデータが提供される場合も同様の処理となる。
　まず、図１４Ａにおいて、サービスサーバ４１０は、ユーザのデータを取得するため、データサーバ３００にデータ登録を行った端末１１０に対して、データ取得の依頼を生成し、送信する（Ｓ５０１）。データ取得の依頼には、例えば端末１１０のデータを取得または参照することを依頼する旨が示されている。なお、サービスサーバ４１０は、端末１１０にデータ取得の依頼を直接送信しているが、メールまたは他のサービス事業者を介して送信してもよい。
　次に、端末１１０は、ステップＳ５０１で送信された依頼を受け取ると、端末１１０の受け取った依頼に基づいて同意情報を生成する（Ｓ５０２）。ここで、端末１１０には、入力部１０１３としてアプリケーションが導入されており、アプリケーションがユーザの操作により、当該依頼に基づく同意情報を生成してよい。例えば、ユーザは、データ提供先であるデータサーバ３００に記録しているデータの一覧の中から、選択または選択を外すかを指示するだけで、提供可能なデータを選択できる。これにより、端末１１０は、データの利活用に関する同意情報として、データ取得の依頼対象のデータがユーザの同意により提供可能である旨を示す同意情報を生成することができる。
　次に、端末１１０は、ステップＳ５０２で生成した同意情報に基づいて、スマートコントラクトを生成する（Ｓ５０３）。このスマートコントラクトは、同意情報に基づきデータを提供可能であるかを判断することを実行可能にプログラム化されたものである。
　次に、端末１１０は、生成した同意情報とスマートコントラクトとを含む、スマートコントラクト登録のトランザクションデータを生成する（Ｓ５０４）。
　次に、端末１１０は、ステップＳ５０４で生成したトランザクションデータを、認証サーバ２００ａに送信する（Ｓ５０５）。なお、図１４Ａに示す例では、端末１１０は、生成したトランザクションデータを認証サーバ２００ａに送信しているが、認証サーバ２００ｂ、２００ｃに送信してもよい。認証サーバ２００ｂ、２００ｃに送信した場合も同様である。
　次に、認証サーバ２００ａは、端末１１０からトランザクションデータを取得すると（Ｓ５０６）、取得した当該トランザクションデータの検証を行う（Ｓ５０７）。
　ステップＳ５０７において、当該トランザクションデータの検証が成功しなかった場合（Ｓ５０７でＮ）、認証サーバ２００ａは、端末１１０にその旨の通知を送信する（Ｓ５０８）。
　一方、ステップＳ５０７において、当該トランザクションデータの検証が成功した場合（Ｓ５０７でＹ）、認証サーバ２００ａは、他の認証サーバ２００（認証サーバ２００ｂ、２００ｃ）に当該トランザクションデータを転送する（Ｓ５０９）。なお、他の認証サーバ２００でも、転送された当該トランザクションデータを検証する。
　次に、認証サーバ２００ａと認証サーバ２００ｂと認証サーバ２００ｃとは、コンセンサスアルゴリズムを実行する（Ｓ５１０）。認証サーバ２００ａと認証サーバ２００ｂと認証サーバ２００ｃとは、当該トランザクションデータが正当なトランザクションデータであること（つまり正当性）を検証すると、それぞれ当該トランザクションデータを含むブロックを生成する。そして、認証サーバ２００ａ、２００ｂ、２００ｃは、当該トランザクションデータを含むブロックを分散台帳に記録する。このようにして端末１１０が作成したスマートコントラクトが分散台帳に記録される。
　次に、当該スマートコントラクトは、分散台帳に記録されることで、実行可能になるすなわち稼働する（Ｓ５１１）。なお、当該スマートコントラクトは、分散台帳に記録されることで、認証サーバ２００ａ等のワーキングメモリに格納されるので実行可能になる。
　次に、端末１１０は、ステップＳ５０１で送信されたデータ取得の依頼とステップＳ５０２で生成した同意情報に基づき、当該データ取得の依頼を含む第１トランザクションデータを生成する（Ｓ５１２）。具体的には、端末１１０は、当該データ取得の依頼と、データサーバ３００からデータサーバ３１０へのデータ提供の同意とを含めて第１トランザクションデータを生成する。ここで、端末１１０には、上述したように、入力部１０１３としてアプリケーションが導入されている。このため、アプリケーションは、ステップＳ５０２で同意情報を生成後、ステップＳ５０１におけるスマートコントラクトの実行を確認すればよい。これにより、アプリケーションは、当該データ取得の依頼とデータサーバ３００からデータサーバ３１０へのデータ提供の同意とを含む第１トランザクションデータを生成することができる。
　次に、端末１１０は、ステップＳ５１２で生成した第１トランザクションデータを、第１グループに属する認証サーバ２００ａ及び第２グループに属する認証サーバ２１０ａに送信する（Ｓ５１３）。なお、認証サーバ２００ａは、第１グループに属する複数の第１認証サーバのうちの一つの第１認証サーバの一例であり、認証サーバ２１０ａは、第２グループに属する複数の第２認証サーバのうちの一つの第２認証サーバの一例である。
　次に、第２グループに属する認証サーバ２１０ａは、端末１１０からの第１トランザクションデータを取得すると（Ｓ５１４）、取得した第１トランザクションデータの検証を行う（Ｓ５１５）。
　ステップＳ５１５において、第１トランザクションデータの検証が成功しなかった場合（Ｓ５１５でＮ）、認証サーバ２１０ａは、端末１１０にその旨の通知を送信する（Ｓ５１６）。
　一方、ステップＳ５１５において、第１トランザクションデータの検証が成功した場合（Ｓ５１５でＹ）、認証サーバ２１０ａは、第２グループに属する他の認証サーバ２１０（認証サーバ２１０ｂ、２１０ｃ）に第１トランザクションデータを転送する（Ｓ５１７）。なお、他の認証サーバ２１０でも、転送された第１トランザクションデータを検証する。
　次に、認証サーバ２１０ａと認証サーバ２１０ｂと認証サーバ２１０ｃとは、コンセンサスアルゴリズムを実行する（Ｓ５１８）。認証サーバ２１０ａと認証サーバ２１０ｂと認証サーバ２１０ｃとは、第１トランザクションデータが正当なトランザクションデータであること（つまり正当性）を検証すると、それぞれ第１トランザクションデータを含むブロックを生成する。そして、認証サーバ２１０ａ、２１０ｂ、２１０ｃは、第１トランザクションデータを含むブロックを分散台帳に記録する。このようにして第１トランザクションデータが第２グループに属する分散台帳に記録される。
　また、第１グループに属する認証サーバ２００ａは、端末１１０からの第１トランザクションデータを取得すると（Ｓ５１９）、取得した第１トランザクションデータの検証を行う（Ｓ５２０）。
　ステップＳ５２０において、第１トランザクションデータの検証が成功しなかった場合（Ｓ５２０でＮ）、認証サーバ２００ａは、端末１１０にその旨の通知を送信する（Ｓ５２１）。
　一方、ステップＳ５２０において、第１トランザクションデータの検証が成功した場合（Ｓ５２０でＹ）、認証サーバ２００ａは、第１グループに属する他の認証サーバ２００（認証サーバ２００ｂ、２００ｃ）に第１トランザクションデータを転送する（Ｓ５２２）。なお、他の認証サーバ２００でも、転送された第１トランザクションデータを検証する。
　次に、認証サーバ２００ａと認証サーバ２００ｂと認証サーバ２００ｃとは、コンセンサスアルゴリズムを実行する（Ｓ５２３）。認証サーバ２００ａと認証サーバ２００ｂと認証サーバ２００ｃとは、第１トランザクションデータが正当なトランザクションデータであること（つまり正当性）を検証すると、それぞれ第１トランザクションデータを含むブロックを生成する。そして、認証サーバ２００ａ、２００ｂ、２００ｃは、第１トランザクションデータを含むブロックを分散台帳に記録する。このようにして第１トランザクションデータが第１グループに属する分散台帳に記録される。
　次に、例えば認証サーバ２００ｃは、分散台帳に記録された第１トランザクションデータに基づいて、ステップＳ５１１で実行可能にさせたスマートコントラクトを実行する（Ｓ５２４）。実行された当該スマートコントラクトは、データサーバ３００に、指定データをデータサーバ３１０に提供可能である旨の通知を送信する（Ｓ５２５）なお、当該通知には、提供対象のデータと提供先の情報とを含んでいればよい。これにより、データサーバ３００に、自身が有するデータを、データサーバ３１０に転送、または、データサーバ３１０を参照可能にさせることができる。データサーバ３１０を参照可能にさせる場合には、データサーバ３１０がデータサーバ３００へのアクセス情報を記録し、データ利用時にはデータサーバ３００へアクセスしてデータを取得する場合も含む。
　次に、データサーバ３００は、認証サーバ２００ｃから通知を取得すると（Ｓ５２６）、取得した通知に基づいてデータサーバ３１０にデータを提供する（Ｓ５２７）。なお、データサーバ３００は、当該通知により指定されたデータを、データサーバ３１０に転送、または、データサーバ３１０による参照可能にさせることで、データサーバ３１０にデータを提供してもよい。ここでは、データサーバ３００は、当該通知により指定されたデータを、データサーバ３１０に転送したとする。
　次に、データサーバ３１０は、データサーバ３００から提供されたデータを記録する（Ｓ５２８）。
　なお、ステップＳ５２７においてデータが提供された場合、サービスサーバ４１０は、端末１１０に対してインセンティブ支払いを行ってもよい。インセンティブ支払いの処理については、ステップＳ３１７～ステップＳ３２６において説明した処理と同様のためここでの説明は省略する。
　以上のようにサービスサーバ４１０の取得したいデータが、サービスサーバ４１０がアクセスできるデータサーバ３１０になく、アクセスできないデータサーバ３００にある場合でも、データサーバ３００からデータサーバ３１０にデータを提供してもらうことできる。よって、実施の形態に係るデータ流通システムでは、異なるグループ間でデータの連携ができるようになる。また、データ提供元のグループに属する分散台帳とデータ提供先の当該グループと異なるグループに属する分散台帳との両方に、データが転送されたまたは参照可能にされたことが記録されるので、データのトレーサビリティを確保しつつ、データを利活用することができる。
　［１．８．６　データ提供処理の別の例］
　なお、図１４Ａ及び図１４Ｂで示されるデータ提供処理では、端末１１０は、サービスサーバ４１０によりデータ提供の依頼を受けてからデータ提供のためのスマートコントラクトを生成しているが、これに限らない。端末１１０は、データ提供のためのスマートコントラクトを事前に生成して実行させていてもよい。この場合、当該スマートコントラクトに記載されているデータ提供否の条件を満たす第１トランザクションデータが分散台帳に記録されたときに、当該スマートコントラクトを実行させて提供対象のデータを自動的に提供するとしてもよい。
　以下、この場合について図を用いて説明する。
　図１５Ａ～図１５Ｃは、本実施の形態に係るデータ流通システムのデータ提供処理の別の一例を示すシーケンス図である。図１５Ａ～図１５Ｃには、図１４Ａ及び図１４Ｂと同様に、端末１１０と、サービスサーバ４００と、第１グループに属する認証サーバ２００及びデータサーバ３００と、第２グループに属する認証サーバ２１０及びデータサーバ３１０との間でのデータ提供処理の別の一例が示されている。図１５Ａ～図１５Ｃに示す例でも、サービスサーバ４１０の取得したいデータが、サービスサーバ４１０がアクセスできるデータサーバ３１０になく、サービスサーバ４１０がアクセスできないデータサーバ３００にあるとしている。
　まず、端末１１０は、ユーザの操作に基づいて同意情報を生成する（Ｓ５５１）。ここで、端末１１０には、入力部１０１３としてアプリケーションが導入されており、アプリケーションがユーザの操作に基づいて同意情報を生成してよい。
　次に、端末１１０は、ステップＳ５５１で生成した同意情報に基づいて、スマートコントラクトを生成する（Ｓ５５２）。このスマートコントラクトは、同意情報に基づきデータを提供可能であるかを判断することを実行可能にプログラム化されたものである。
　次に、端末１１０は、生成した同意情報とスマートコントラクトとを含む、スマートコントラクト登録のトランザクションデータを生成する（Ｓ５５３）。
　なお、以降のステップＳ５５４～ステップＳ５６０の処理は、上述したステップＳ５０５～ステップＳ５１１の処理と同様のため、説明を省略する。
　次に、図１５Ｂにおいて、サービスサーバ４１０は、例えば、ユーザのどのようなデータを取得したいかを決定した場合、データ取得の依頼を行うことを決定する（Ｓ５７０）。
　次に、サービスサーバ４１０は、データ取得を依頼する旨を示すデータ取得依頼を生成し、データ取得依頼を含むデータ取得依頼の第１トランザクションデータを生成する（Ｓ５７１）。
　次に、サービスサーバ４１０は、ステップＳ５７１で生成した第１トランザクションデータを、第２グループに属する認証サーバ２１０ｃ及び第１グループに属する認証サーバ２００ｃに送信する（Ｓ５７２）。ここで、認証サーバ２００ｃは、第１グループに属する複数の第１認証サーバのうちの一つの第１認証サーバの一例であり、認証サーバ２１０ｃは、第２グループに属する複数の第２認証サーバのうちの一つの第２認証サーバの一例である。また、サービスサーバ４１０の取得したいデータが、サービスサーバ４１０がアクセスできるデータサーバ３１０になく、サービスサーバ４１０がアクセスできないデータサーバ３００にある。このため、サービスサーバ４１０は、ステップＳ５７１で生成した第１トランザクションデータを、認証サーバ２１０ｃ及び認証サーバ２００ｃに送信している。
　なお、以降のステップＳ５７３～ステップＳ５７８の処理は、処理の主体が認証サーバ２１０ａでなく認証サーバ２１０ｃであることを除き、上述したステップＳ５１４～ステップＳ５１８の処理と同様のため、説明を省略する。
　次に、認証サーバ２００ｃは、サービスサーバ４１０からの第１トランザクションデータを取得すると（Ｓ５７９）、取得した第１トランザクションデータの検証を行う（Ｓ５８０）。
　ステップＳ５８０において、図１５Ｃに示すように、第１トランザクションデータの検証が成功しなかった場合（Ｓ５８０でＮ）、認証サーバ２００ｃは、データサーバ３１０にその旨の通知を送信する（Ｓ５８１）。
　一方、ステップＳ５８０において、第１トランザクションデータの検証が成功した場合（Ｓ５８０でＹ）、認証サーバ２００ｃは、第１グループに属する他の認証サーバ２００（認証サーバ２００ａ、２００ｂ）に第１トランザクションデータを転送する（Ｓ５８２）。なお、他の認証サーバ２００でも、転送された第１トランザクションデータを検証する。
　以降のステップＳ５８３～ステップＳ５８８の処理は、上述したステップＳ５２３～ステップＳ５２８の処理と同様のため、説明を省略する。
　なお、図１５Ａに示す例では、ユーザは端末１１０を操作して任意のタイミングで同意情報を生成しているが、これに限らない。ユーザは端末１１０を操作して定期的または不定期に同意情報を生成してもよい。
　また、サービス事業者が新たに増えたとき、または、サービス事業者からのインセンティブもしくはフィードバックが新たに追加されたときにユーザは同意情報を生成してもよい。この場合、新たに増えたサービス事業者、または、新たに追加されたインセンティブもしくはフィードバックの内容が端末１１０に提示されれば、ユーザは提示された内容に基づいて、新たに同意情報を生成することができる。これにより、端末１１０、住宅１００のデータの利活用のためにユーザがデータ提供する機会を増やすことができる。
　［１．９　実施の形態の効果］
　以上のように、本実施の形態に係るデータ流通方法、プログラム及びデータ流通システムによれば、データのトレーサビリティを確保しつつ、データを利活用することができる。
　例えば、サービスサーバ４１０の取得したいデータが、サービスサーバ４１０がアクセスできるデータサーバ３１０になく、アクセスできないデータサーバ３００にある場合でも、データサーバ３００からデータサーバ３１０にデータを提供してもらうことできる。
　つまり、本実施の形態によれば、一にグループに属するデータサーバが有する住宅１００及び端末１１０から収集した情報をユーザの同意のもとに安全に他のグループに属するデータサーバに提供できる。これにより複数のサービス事業者でユーザの情報を利活用することができる。このため、本実施の形態によれば、異なるグループ間でデータの連携ができるようになるデータ流通方法等を実現できる。
　また、本実施の形態によれば、データ提供元のグループに属する分散台帳とデータ提供先の当該グループと異なるグループに属する分散台帳との両方に、データが転送されたまたは参照可能にされたことが記録される。このように、ブロックチェーン技術を活用して、データのトレーサビリティを確保しつつ、異なるグループに属するデータの連携を行うことができる。つまり、データのトレーサビリティを確保しつつ、データを利活用することができる。よって、ユーザは安心してデータを提供することができる。
　また、本実施の形態によれば、住宅１００や端末１１０で生成される同意情報に基づいて、グループの異なるデータサーバ間でのデータ提供を行うことができる。これにより、ユーザのデータの流通を制限しつつ、ユーザの履歴情報等のデータを活用することができる。また、本実施の形態によれば、ユーザの同意情報を、ブロックチェーン技術を用いた分散台帳に、安全に記録できる。
　［２．　その他の変形例］
　なお、本開示を上記各実施の形態に基づいて説明してきたが、本開示は、上記各実施の形態に限定されないのはもちろんである。以下のような場合も本開示に含まれる。
　（１）上記の実施の形態では、認証サーバ２００、２１０とデータサーバ３００、３１０とは別の装置であるとして説明したが、これに限らない。認証サーバ２００及びデータサーバ３００と、認証サーバ２１０及びデータサーバ３１０とは同一の装置であってもよい。
　（２）上記の実施の形態では、データサーバ３００、３１０とサービスサーバ４００、４１０は別の装置として説明したが、これに限らない。データサーバ３００及びサービスサーバ４００と、データサーバ３１０及びサービスサーバ４１０とは、同一の装置であってもよい。
　（３）上記の実施の形態では、ユーザは、端末１１０または住宅１００のコントローラ１０１を操作して、インセンティブ及び／またはフィードバックに基づいて同意情報を生成しているが、これに限らない。ユーザは、サービス事業者が取り扱うユーザデータの量またはサービス事業者と連携しているサービスの数等に基づいて同意情報を生成するとしてもよい。これにより、データの利活用が多くなるだけでなく、サービス事業者によるユーザへのサービス提案またはサービス事業者が支払うインセンティブ等が多くなる可能性がある。また、インセンティブ及び／またはフィードバック等は、認証サーバ２００、２１０に記録されるとしてもよい。
　（４）上記の実施の形態における各装置は、具体的には、マイクロプロセッサ、ＲＯＭ、ＲＡＭ、ハードディスクユニット、ディスプレイユニット、キーボード、マウス等から構成されるコンピュータシステムである。前記ＲＡＭまたはハードディスクユニットには、コンピュータプログラムが記録されている。前記マイクロプロセッサが、前記コンピュータプログラムにしたがって動作することにより、各装置は、その機能を達成する。ここでコンピュータプログラムは、所定の機能を達成するために、コンピュータに対する指令を示す命令コードが複数個組み合わされて構成されたものである。
　（５）上記の実施の形態における各装置は、構成する構成要素の一部または全部は、１個のシステムＬＳＩ（Ｌａｒｇｅ　Ｓｃａｌｅ　Ｉｎｔｅｇｒａｔｉｏｎ：大規模集積回路）から構成されているとしてもよい。システムＬＳＩは、複数の構成部を１個のチップ上に集積して製造された超多機能ＬＳＩであり、具体的には、マイクロプロセッサ、ＲＯＭ、ＲＡＭ等を含んで構成されるコンピュータシステムである。前記ＲＡＭには、コンピュータプログラムが記録されている。前記マイクロプロセッサが、前記コンピュータプログラムにしたがって動作することにより、システムＬＳＩは、その機能を達成する。
　また、上記の各装置を構成する構成要素の各部は、個別に１チップ化されていても良いし、一部またはすべてを含むように１チップ化されてもよい。
　また、ここでは、システムＬＳＩとしたが、集積度の違いにより、ＩＣ、ＬＳＩ、スーパーＬＳＩ、ウルトラＬＳＩと呼称されることもある。また、集積回路化の手法はＬＳＩに限るものではなく、専用回路または汎用プロセッサで実現してもよい。ＬＳＩ製造後に、プログラムすることが可能なＦＰＧＡ（Ｆｉｅｌｄ　Ｐｒｏｇｒａｍｍａｂｌｅ　Ｇａｔｅ　Ａｒｒａｙ）や、ＬＳＩ内部の回路セルの接続や設定を再構成可能なリコンフィギュラブル・プロセッサを利用しても良い。
　さらには、半導体技術の進歩または派生する別技術によりＬＳＩに置き換わる集積回路化の技術が登場すれば、当然、その技術を用いて機能ブロックの集積化を行ってもよい。バイオ技術の適用等が可能性としてありえる。
　（６）上記の各装置を構成する構成要素の一部または全部は、各装置に脱着可能なＩＣカードまたは単体のモジュールから構成されているとしてもよい。前記ＩＣカードまたは前記モジュールは、マイクロプロセッサ、ＲＯＭ、ＲＡＭ等から構成されるコンピュータシステムである。前記ＩＣカードまたは前記モジュールは、上記の超多機能ＬＳＩを含むとしてもよい。マイクロプロセッサが、コンピュータプログラムにしたがって動作することにより、前記ＩＣカードまたは前記モジュールは、その機能を達成する。このＩＣカードまたはこのモジュールは、耐タンパ性を有するとしてもよい。
　（７）本開示は、上記に示す方法であるとしてもよい。また、これらの方法をコンピュータにより実現するコンピュータプログラムであるとしてもよいし、前記コンピュータプログラムからなるデジタル信号であるとしてもよい。
　また、本開示は、前記コンピュータプログラムまたは前記デジタル信号をコンピュータで読み取り可能な記録媒体、例えば、フレキシブルディスク、ハードディスク、ＣＤ－ＲＯＭ、ＭＯ、ＤＶＤ、ＤＶＤ－ＲＯＭ、ＤＶＤ－ＲＡＭ、ＢＤ（Ｂｌｕ－ｒａｙ　Ｄｉｓｃ（登録商標））、半導体メモリ等に記録したものとしてもよい。また、これらの記録媒体に記録されている前記デジタル信号であるとしてもよい。
　また、本開示は、前記コンピュータプログラムまたは前記デジタル信号を、電気通信回線、無線または有線通信回線、インターネットを代表とするネットワーク、データ放送等を経由して伝送するものとしてもよい。
　また、本開示は、マイクロプロセッサとメモリを備えたコンピュータシステムであって、前記メモリは、上記コンピュータプログラムを記録しており、前記マイクロプロセッサは、前記コンピュータプログラムにしたがって動作するとしてもよい。
　また、前記プログラムまたは前記デジタル信号を前記記録媒体に記録して移送することにより、または前記プログラムまたは前記デジタル信号を前記ネットワーク等を経由して移送することにより、独立した他のコンピュータシステムにより実施するとしてもよい。
　（８）上記実施の形態及び上記変形例をそれぞれ組み合わせるとしてもよい。
　本開示は、データ流通方法、プログラム及びデータ流通システムに利用でき、例えばユーザの同意情報をもとに異なるグループ間でのデータの参照または転送が可能となり、データの利活用を促進するデータ流通方法、プログラム及びデータ流通システムに利用できる。
　１０　データ流通システム
　１００　住宅
　１０１　コントローラ
　１０２　太陽光発電装置
　１０３　蓄電池
　１０４　エアコン
　１０５　体組成計
　１０６　血圧計
　１１０　端末
　２００、２００ａ、２００ｂ、２００ｃ、２１０、２１０ａ、２１０ｂ、２１０ｃ　認証サーバ
　２１１　トランザクションデータ検証部
　２１２　ブロック生成部
　２１３　同期部
　２１４　スマートコントラクト実行部
　２１５、３１３、４１４、１０１４、１１０４　記録部
　２１６、３１４、４１５、１０１５、１１０５　通信部
　３００、３１０　データサーバ
　３１１　データ管理部
　３１２、４１２　ユーザ管理部
　４００、４１０　サービスサーバ
　４１１　サービス管理部
　４１３、１０１２、１１０１　トランザクションデータ生成部
　５００　通信ネットワーク
　１０１１　制御部
　１０１３、１１０２　入力部
　１１０３　データ取得部

Claims (8)

  1. 　それぞれ分散台帳を有する複数の認証サーバと複数のデータサーバと機器とからなるデータ流通システムにおけるデータ流通方法であって、
    　第１グループには、前記複数の認証サーバのうちの複数の第１認証サーバと、前記複数のデータサーバのうちの１以上の第１データサーバとが属しており、
    　前記第１グループと異なる第２グループには、前記複数の認証サーバのうちの前記複数の第１認証サーバと異なる複数の第２認証サーバと、前記複数のデータサーバのうちの前記１以上の第１データサーバと異なる１以上の第２データサーバとが属しており、
    　前記データ流通方法では、
    　前記複数の第１認証サーバのうちの一つの第１認証サーバが、前記機器のデータを取得または参照することを依頼する旨を示すデータ取得依頼を含む第１トランザクションデータを取得し、
    　前記一つの第１認証サーバが、前記第１トランザクションデータを含むブロックを、前記第１グループに属する前記一つの第１認証サーバの分散台帳に記録し、
    　前記１以上の第１データサーバに、前記１以上の第１データサーバが有する前記機器のデータを、前記１以上の第２データサーバに転送、または、前記１以上の第２データサーバによる参照可能にさせ、
    　前記複数の第２認証サーバのうちの一つの第２認証サーバが、前記第１トランザクションデータを取得し、
    　前記一つの第２認証サーバが、前記第１トランザクションデータを含むブロックを、前記第２グループに属する前記一つの第２認証サーバの分散台帳に記録する、
    　データ流通方法。
  2. 　前記データ流通システムは、さらにサービスサーバを含み、
    　前記データ流通方法では、
    　前記サービスサーバが、前記第１トランザクションデータを生成して、前記一つの第１認証サーバ及び前記一つの第２認証サーバに送信し、
    　前記一つの第１認証サーバが前記第１トランザクションデータを取得した際、
    　前記一つの第１認証サーバが、
    　前記機器から得た同意情報であって前記データの利活用に関する同意情報に基づいて前記データを前記１以上の第１データサーバから前記１以上の第２データサーバに提供可能であるかを判断し、
    　前記１以上の第１データサーバに、前記１以上の第１データサーバが有する前記機器のデータを、前記１以上の第２データサーバに転送、または、前記１以上の第２データサーバによる参照可能にさせる、
    　請求項１に記載のデータ流通方法。
  3. 　さらに、
    　前記サービスサーバが、前記１以上の第１データサーバにより、前記機器のデータが、前記１以上の第２データサーバに転送、または、前記１以上の第２データサーバによる参照可能にされたことを確認した場合、前記機器に対してトークンを発行するための第２トランザクションデータを生成し、
    　前記一つの第１認証サーバが、前記第２トランザクションデータを取得し、
    　前記一つの第１認証サーバが、前記第２トランザクションデータを含むブロックを、前記第１グループに属する前記一つの第１認証サーバの分散台帳に記録し、
    　前記一つの第１認証サーバが、記録した前記第２トランザクションデータに基づき、トークンを発行することを実行可能にプログラム化されたスマートコントラクトを動作させることで、前記スマートコントラクトに前記機器に対してトークンを発行させる、
    　請求項２に記載のデータ流通方法。
  4. 　前記一つの第１認証サーバが、前記同意情報に基づき前記データを提供可能であるかを判断することを実行可能にプログラム化されたスマートコントラクトを取得し、
    　前記一つの第１認証サーバが、前記第１トランザクションデータを取得した場合、取得した前記第１トランザクションデータに基づき前記スマートコントラクトを実行することで、前記データを前記１以上の第１データサーバから前記１以上の第２データサーバに提供可能であると判断したとき、前記１以上の第１データサーバに、前記１以上の第１データサーバが有する前記機器のデータを、前記１以上の第２データサーバに転送、または、前記１以上の第２データサーバによる参照可能にさせる、
    　請求項２または３に記載のデータ流通方法。
  5. 　前記一つの第１認証サーバの分散台帳に記録する際、
    　前記一つの第１認証サーバが、取得した前記第１トランザクションデータの検証を行い、
    　前記一つの第１認証サーバが、前記検証を行うことで前記第１トランザクションデータの正当性を確認した場合、前記複数の第１認証サーバのうちの前記一つの第１認証サーバを除く複数の第１認証サーバとともに、前記第１トランザクションデータの正当性について合意するためのコンセンサスアルゴリズムを実行し、
    　前記コンセンサスアルゴリズムによって前記第１トランザクションデータの正当性について合意された場合、前記一つの第１認証サーバが、前記第１トランザクションデータを含むブロックを前記第１グループに属する前記一つの第１認証サーバの分散台帳に記録する、
    　請求項１～４のいずれか１項に記載のデータ流通方法。
  6. 　前記一つの第２認証サーバの分散台帳に記録する際、
    　前記一つの第２認証サーバが、取得した前記第１トランザクションデータの検証を行い、
    　前記一つの第２認証サーバが、前記検証を行うことで前記第１トランザクションデータの正当性を確認した場合、前記複数の第２認証サーバのうちの前記一つの第２認証サーバを除く複数の第２認証サーバとともに、前記第１トランザクションデータの正当性について合意するためのコンセンサスアルゴリズムを実行し、
    　前記コンセンサスアルゴリズムによって前記第１トランザクションデータの正当性について合意された場合、前記一つの第２認証サーバが、前記第１トランザクションデータを含むブロックを前記第２グループに属する前記一つの第２認証サーバの分散台帳に記録する、
    　請求項１～５のいずれか１項に記載のデータ流通方法。
  7. 　それぞれ分散台帳を有する複数の認証サーバと複数のデータサーバと機器とからなるデータ流通システムにおけるデータ流通方法をコンピュータに実行させるプログラムであって、
    　第１グループには、前記複数の認証サーバのうちの複数の第１認証サーバと、前記複数のデータサーバのうちの１以上の第１データサーバとが属しており、
    　前記第１グループと異なる第２グループには、前記複数の認証サーバのうちの前記複数の第１認証サーバと異なる複数の第２認証サーバと、前記複数のデータサーバのうちの前記１以上の第１データサーバと異なる１以上の第２データサーバとが属しており、
    　前記複数の第１認証サーバのうちの一つの第１認証サーバが、前記機器のデータを取得または参照することを依頼する旨を示すデータ取得依頼を含む第１トランザクションデータを取得し、
    　前記一つの第１認証サーバが、前記第１トランザクションデータを含むブロックを、前記第１グループに属する前記一つの第１認証サーバの分散台帳に記録し、
    　前記１以上の第１データサーバに、前記１以上の第１データサーバが有する前記機器のデータを、前記１以上の第２データサーバに転送、または、前記１以上の第２データサーバによる参照可能にさせ、
    　前記複数の第２認証サーバのうちの一つの第２認証サーバが、前記第１トランザクションデータを取得し、
    　前記一つの第２認証サーバが、前記第１トランザクションデータを含むブロックを、前記第２グループに属する前記一つの第２認証サーバの分散台帳に記録することを、
    　コンピュータに実行させるプログラム。
  8. 　それぞれ分散台帳を有する複数の認証サーバと複数のデータサーバとを備えるデータ流通システムであって、
    　第１グループには、前記複数の認証サーバのうちの複数の第１認証サーバと、前記複数のデータサーバのうちの１以上の第１データサーバとが属しており、
    　前記第１グループと異なる第２グループには、前記複数の認証サーバのうちの前記複数の第１認証サーバと異なる複数の第２認証サーバと、前記複数のデータサーバのうちの前記１以上の第１データサーバと異なる１以上の第２データサーバとが属しており、
    　前記複数の第１認証サーバのうちの一つの第１認証サーバは、
    　機器のデータを取得または参照することを依頼する旨を示すデータ取得依頼を含む第１トランザクションデータを取得する第１通信部と、
    　前記一つの第１認証サーバが、前記第１トランザクションデータを含むブロックを、前記第１グループに属する前記一つの第１認証サーバの分散台帳に記録する第１記録部と、
    　前記１以上の第１データサーバに、前記１以上の第１データサーバが有する前記機器のデータを、前記１以上の第２データサーバに転送、または、前記１以上の第２データサーバによる参照可能にさせる実行部と、を備え、
    　前記複数の第２認証サーバのうちの一つの第２認証サーバは、
    　前記第１トランザクションデータを取得する第２通信部と、
    　前記一つの第２認証サーバが、前記第１トランザクションデータを含むブロックを、前記第２グループに属する前記一つの第２認証サーバの分散台帳に記録する第２記録部とを備える、
    　データ流通システム。
PCT/JP2020/047681 2019-12-26 2020-12-21 データ流通方法、プログラム及びデータ流通システム WO2021132159A1 (ja)

Priority Applications (4)

Application Number Priority Date Filing Date Title
EP20907325.3A EP4083834A4 (en) 2019-12-26 2020-12-21 DATA DISTRIBUTION METHOD, DATA DISTRIBUTION PROGRAM AND SYSTEM
CN202080090169.4A CN114846471A (zh) 2019-12-26 2020-12-21 数据流通方法、程序及数据流通系统
JP2021567441A JPWO2021132159A1 (ja) 2019-12-26 2020-12-21
US17/843,408 US12088664B2 (en) 2019-12-26 2022-06-17 Data distribution method, recording medium, and data distribution system

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US201962953761P 2019-12-26 2019-12-26
US62/953,761 2019-12-26

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US17/843,408 Continuation US12088664B2 (en) 2019-12-26 2022-06-17 Data distribution method, recording medium, and data distribution system

Publications (1)

Publication Number Publication Date
WO2021132159A1 true WO2021132159A1 (ja) 2021-07-01

Family

ID=76574757

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2020/047681 WO2021132159A1 (ja) 2019-12-26 2020-12-21 データ流通方法、プログラム及びデータ流通システム

Country Status (5)

Country Link
US (1) US12088664B2 (ja)
EP (1) EP4083834A4 (ja)
JP (1) JPWO2021132159A1 (ja)
CN (1) CN114846471A (ja)
WO (1) WO2021132159A1 (ja)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP7357096B1 (ja) 2022-03-24 2023-10-05 株式会社日立製作所 データ受け渡しシステム、データ受け渡し方法

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2003256738A (ja) * 2002-03-05 2003-09-12 Toshiba Corp 製品情報の流通に伴う料金決済方法およびその料金決済システム
JP2016091067A (ja) * 2014-10-29 2016-05-23 ソフトバンク株式会社 個人情報流通方法、個人情報流通システム及び個人情報流通事業者装置
JP6543743B1 (ja) * 2018-03-05 2019-07-10 富士通株式会社 管理プログラム
JP2019176458A (ja) * 2018-03-28 2019-10-10 マクロジェン・インコーポレイテッドＭａｃｒｏｇｅｎ， Ｉｎｃ． 複数のブロックチェーンに基づいたデータ共有方法

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20200126050A1 (en) * 2017-01-19 2020-04-23 Nokia Technologies Oy IoT GATEWAY AND DESTINATION CLOUD SERVER
EP4287104A3 (en) * 2018-01-29 2024-01-17 Panasonic Intellectual Property Corporation of America Control method, controller, data structure, and electric power transaction system

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2003256738A (ja) * 2002-03-05 2003-09-12 Toshiba Corp 製品情報の流通に伴う料金決済方法およびその料金決済システム
JP2016091067A (ja) * 2014-10-29 2016-05-23 ソフトバンク株式会社 個人情報流通方法、個人情報流通システム及び個人情報流通事業者装置
JP6543743B1 (ja) * 2018-03-05 2019-07-10 富士通株式会社 管理プログラム
JP2019176458A (ja) * 2018-03-28 2019-10-10 マクロジェン・インコーポレイテッドＭａｃｒｏｇｅｎ， Ｉｎｃ． 複数のブロックチェーンに基づいたデータ共有方法

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
KIYOMOTO, SHINSAKU: "[2-E-3-3] Distributed Blockchain Architecture and Its Application to Data Distribution Platform", PROCEEDINGS OF THE 38TH JOINT CONFERENCE ON MEDICAL INFORMATICS (THE 19TH ANNUAL MEETING OF JAPAN ASSOCIATION FOR MEDICAL INFORMATICS); NOVEMBER 22-25, 2018,20181122; 20181122 - 2018112538TH UNION CONFERENCE ON MEDICAL INFORMATICS CO., INC, JP, 22 November 2018 (2018-11-22) - 25 November 2018 (2018-11-25), JP , pages 174 - 177, XP009525428 *
See also references of EP4083834A4
STRATEGY FOR PROMOTING DATA UTILIZATION TO REALIZE SOCIETY 5.0, 25 December 2019 (2019-12-25), Retrieved from the Internet <URL:https://www.keidanren.or.jp/en/policy/2017/104.html?v=p>

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP7357096B1 (ja) 2022-03-24 2023-10-05 株式会社日立製作所 データ受け渡しシステム、データ受け渡し方法
JP2023152299A (ja) * 2022-03-24 2023-10-17 株式会社日立製作所 データ受け渡しシステム、データ受け渡し方法

Also Published As

Publication number Publication date
EP4083834A1 (en) 2022-11-02
JPWO2021132159A1 (ja) 2021-07-01
US20220321649A1 (en) 2022-10-06
CN114846471A (zh) 2022-08-02
US12088664B2 (en) 2024-09-10
EP4083834A4 (en) 2023-01-04

Similar Documents

Publication Publication Date Title
Sittón-Candanedo et al. A review of edge computing reference architectures and a new global edge proposal
Hsiao et al. Employing blockchain technology to strengthen security of wireless sensor networks
Rathee et al. A hybrid framework for multimedia data processing in IoT-healthcare using blockchain technology
Cullen et al. On the resilience of DAG-based distributed ledgers in IoT applications
CN109034480A (zh) 一种基于智能合约的互联微网分布式优化调度方法
JP2019153275A (ja) 制御方法、コントローラ、データ構造及び電力取引システム
Banotra et al. Use of blockchain and internet of things for securing data in healthcare systems
Delgado-Segura et al. Reputation and reward: Two sides of the same bitcoin
WO2021132159A1 (ja) データ流通方法、プログラム及びデータ流通システム
EP3534323A1 (en) Control method, controller, data structure, and power transaction system
Khan et al. A survey and ontology of blockchain consensus algorithms for resource-constrained IoT systems
Baashar et al. Toward blockchain technology in the energy environment
Sathish et al. A survey on Blockchain mechanisms (BCM) based on internet of things (IoT) applications
Almagrabi et al. Blockchain-as-a-Utility for Next-Generation Healthcare Internet of Things.
WO2020122039A1 (ja) データ管理方法、データ管理システム及びプログラム
Ferone et al. A blockchain-based infection tracing and notification system by non-fungible tokens
US20230306427A1 (en) Control method, data distribution system, and recording medium
Alrowaily et al. Modeling and analysis of proof-based strategies for distributed consensus in blockchain-based peer-to-peer networks
Kasyapa et al. Blockchain integration in healthcare: a comprehensive investigation of use cases, performance issues, and mitigation strategies
Liu HPCLS-BC: A novel blockchain framework using heterogeneous peer-node and cloud-based ledger storage for Internet of Things applications
JP6982152B2 (ja) 制御方法、プログラム及び不正データ検知システム
Mandal et al. Investigating Layer-2 Scalability Solutions for Blockchain Applications
WO2021240869A1 (ja) 制御方法、プログラム及び不正データ検知システム
Sahu et al. Blockchain-based dynamic pricing framework for electric vehicle charging
Ali Süzen et al. Protecting the privacy of IoT-based health records using blockchain technology

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 20907325

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2021567441

Country of ref document: JP

Kind code of ref document: A

NENP Non-entry into the national phase

Ref country code: DE

ENP Entry into the national phase

Ref document number: 2020907325

Country of ref document: EP

Effective date: 20220726