WO2020080522A1 - 制御方法、制御システム、第１サーバ、及び、データ構造 - Google Patents

制御方法、制御システム、第１サーバ、及び、データ構造 Download PDF

Info

Publication number
WO2020080522A1
WO2020080522A1 PCT/JP2019/041094 JP2019041094W WO2020080522A1 WO 2020080522 A1 WO2020080522 A1 WO 2020080522A1 JP 2019041094 W JP2019041094 W JP 2019041094W WO 2020080522 A1 WO2020080522 A1 WO 2020080522A1
Authority
WO
WIPO (PCT)
Prior art keywords
transaction data
iot device
unit
servers
server
Prior art date
Application number
PCT/JP2019/041094
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 CN201980048752.6A priority Critical patent/CN112470179B/zh
Priority to JP2020553337A priority patent/JP7458321B2/ja
Priority to EP19873575.5A priority patent/EP3869425A4/en
Publication of WO2020080522A1 publication Critical patent/WO2020080522A1/ja
Priority to US17/159,714 priority patent/US11556103B2/en

Links

Images

Classifications

    • G—PHYSICS
    • G05—CONTROLLING; REGULATING
    • G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B19/00—Programme-control systems
    • G05B19/02—Programme-control systems electric
    • G05B19/04—Programme control other than numerical control, i.e. in sequence controllers or logic controllers
    • G05B19/042—Programme control other than numerical control, i.e. in sequence controllers or logic controllers using digital processors
    • 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
    • G06Q10/00—Administration; Management
    • 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
    • G06Q10/00—Administration; Management
    • G06Q10/02—Reservations, e.g. for tickets, services or events
    • G—PHYSICS
    • G05—CONTROLLING; REGULATING
    • G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B2219/00—Program-control systems
    • G05B2219/20—Pc systems
    • G05B2219/25—Pc structure of the system
    • G05B2219/25011—Domotique, I-O bus, home automation, building automation

Definitions

  • the present disclosure relates to a control method, a control system, a first server, and a data structure.
  • Non-Patent Document 1 there is disclosed a technique of managing the unlocking (unlocking) or locking of a unit that constitutes a delivery box by using a block chain (see Non-Patent Document 1).
  • a smart contract using a block chain may be used to manage the lock / unlock of the units constituting the delivery box.
  • GMO Internet Co., Ltd. “GMO Internet Group, Hong Information Systems, PARCO jointly carry out second demonstration test using blockchain and IoT”, [online], June 21, 2017, [2018 October 25, 2014], Internet ⁇ URL: https: //cloud.z.com/jp/news-ep/IoT2/>
  • the delivery company delivers the parcel to the delivery box, it purchases usage rights for one or more units that make up the delivery box, and then moves to the actual location of the unit. Therefore, even if the delivery company arrives at the site and tries to unlock the unit in order to use the unit, the unit may be out of order due to a malfunction.
  • IoT Internet of Things
  • the point where the usage right is purchased and the point where the IoT device, which is the point where the usage right is actually used are separated.
  • the distributed ledger of the block chain has a characteristic that it operates without being affected even if a disaster or the like occurs at a certain point because a plurality of ledger are installed at physically different bases.
  • an IoT device such as a home delivery box cannot be used due to a failure or the like due to a disaster, aging, or the like when it should operate. Therefore, even if the usage right can be purchased on the system for a certain IoT device, it may actually break down, and the IoT device may not be available locally.
  • the present disclosure has been made in view of the above circumstances, and provides a control method and the like that can further reduce time cost and energy cost by using a distributed ledger.
  • a control method includes one or more IoT (Internet of Things) devices and a plurality of servers capable of communicating with the one or more IoT devices via a network.
  • a first consensus algorithm for agreeing on the correctness of the first transaction data, and if the first consensus algorithm verifies the correctness of the first transaction data, the block containing the first transaction data is executed. The data is recorded in the distributed ledger of the first server.
  • a recording medium such as a system, a method, an integrated circuit, a computer program, or a computer-readable CD-ROM, and the system, the method, the integrated circuit, the computer. It may be realized by any combination of the program and the recording medium.
  • control method and the like of the present disclosure it is possible to further reduce the time cost and the energy cost by using the distributed ledger.
  • FIG. 1 is a block diagram schematically showing the configuration of the control system in the embodiment.
  • FIG. 2 is a diagram schematically showing an example of the overall configuration of the server shown in FIG.
  • FIG. 3 is a block diagram showing a functional configuration of the server according to the embodiment.
  • FIG. 4 is an explanatory diagram showing the data structure of the block chain.
  • FIG. 5 is an explanatory diagram showing the data structure of transaction data.
  • FIG. 6 is a block diagram showing a functional configuration of the smart contract unit in the embodiment.
  • FIG. 7 is a block diagram showing a functional configuration of the IoT device management unit according to the embodiment.
  • FIG. 8 is a block diagram showing a functional configuration of the user request processing unit in the embodiment.
  • FIG. 1 is a block diagram schematically showing the configuration of the control system in the embodiment.
  • FIG. 2 is a diagram schematically showing an example of the overall configuration of the server shown in FIG.
  • FIG. 3 is a block diagram showing a functional configuration of the server according to the
  • FIG. 9 is a flowchart showing a control method executed by the control system according to the embodiment.
  • FIG. 10 is a sequence diagram showing a user request process when control of the IoT device is unnecessary in the embodiment.
  • FIG. 11A is a diagram showing an example of a data structure of transaction data used when the processing of the user request shown in FIG. 10 is performed.
  • FIG. 11B is a diagram showing an example of the data structure of the OK notification used when the processing of the user request shown in FIG. 10 is performed.
  • FIG. 11C is a diagram showing an example of a data structure of transaction data used when the processing of the user request shown in FIG. 10 is performed.
  • FIG. 12 is a sequence diagram showing processing of a user request when control of the IoT device in the embodiment is necessary.
  • FIG. 11A is a diagram showing an example of a data structure of transaction data used when the processing of the user request shown in FIG. 10 is performed.
  • FIG. 11B is a diagram showing an example of the data structure of the OK notification
  • FIG. 13A is a diagram showing an example of the data structure of an OK notification used when the processing of the user request shown in FIG. 12 is performed.
  • FIG. 13B is a diagram showing an example of a data structure of transaction data used when the processing of the user request shown in FIG. 12 is performed.
  • FIG. 13C is a diagram showing an example of the data structure of transaction data used when the processing of the user request shown in FIG. 12 is performed.
  • FIG. 14 is a sequence diagram showing a failure detection process when the IoT device according to the embodiment detects a failure.
  • FIG. 15 is a diagram showing an example of the data structure of transaction data used when the failure detection process shown in FIG. 14 is performed.
  • FIG. 16A is a diagram showing state information managed by the smart contract unit in the embodiment.
  • FIG. 16B is a diagram showing state information managed by the smart contract unit in the embodiment.
  • FIG. 17 is a sequence diagram showing another example of the processing of the user request when the control of the IoT device is unnecessary in the embodiment.
  • FIG. 18 is a diagram showing an example of the data structure of the NG notification used when the processing of the user request shown in FIG. 17 is performed.
  • FIG. 19 is a diagram schematically showing a problem in the comparative example.
  • FIG. 20 is a diagram schematically showing the effect of the present disclosure.
  • a control method includes a plurality of servers in a system including one or more IoT (Internet of Things) devices and a plurality of servers capable of communicating with the one or more IoT devices via a network. And a failure information indicating that one IoT device among the one or more IoT devices has failed, and the one IoT device acquiring the failure information.
  • First transaction data including time information at the time of performing the first transaction data from the one IoT device, and the obtained first transaction data is stored in a plurality of servers different from the first server among the plurality of servers.
  • the distributed ledger can be used to further reduce the time cost and the energy cost.
  • the system further includes a terminal that is used by a user and is a terminal that can communicate with the plurality of servers via the network, and the control method is such that the user uses the one of the one of the terminals.
  • the state information indicating whether the one IoT device is available is read out, and the one IoT device is available from the read state information.
  • a first signal indicating that the use of the one IoT device is permitted under a predetermined condition is transmitted to the terminal.
  • the distributed ledger can be used to reduce time cost and energy cost.
  • control method determines from the read state information that the one IoT device is unavailable, the control method does not permit the terminal to use the one IoT device. Send the signal shown.
  • the control method when the control method further acquires second transaction data indicating that the usage right of the one IoT device has been purchased from the terminal, the acquired second transaction data is converted into Transfer to the plurality of second servers of the plurality of servers and execute, together with the plurality of second servers, a second consensus algorithm for agreeing on the validity of the second transaction data; When the legitimacy of the second transaction data is verified by the consensus algorithm of 1., the block including the second transaction data is recorded in the distributed ledger of the first server.
  • the state information further includes an open / closed state of the one IoT device
  • the control method further includes a first lock request from the terminal indicating an unlocking request of the one IoT device based on the usage right.
  • acquiring the third transaction data transferring the acquired third transaction data to the plurality of second servers, and agreeing with the plurality of second servers about the validity of the third transaction data.
  • the block including the third transaction data is recorded in the distributed ledger of the first server. Change the open / closed state of the one IoT device included in the state information. To.
  • the history of unlocking and locking of IoT devices can be recorded in the distributed ledger. Therefore, the history of unlocking / locking of the IoT device is disclosed and tampering can be detected, so that the unauthorized use of the IoT device can be suppressed.
  • control method reads the first transaction data recorded in the distributed ledger, generates the state information based on the read first transaction data, and the first server has the state information.
  • the state information in the memory is read.
  • the distributed ledger can be used to further reduce the time cost and the energy cost.
  • the time information is a time stamp or a sequence number when the failure information is acquired.
  • the control method operates the smart contract stored in the distributed ledger to acquire the first transaction data.
  • a control system includes one or more IoT devices and a plurality of servers capable of communicating with the one or more IoT devices via a network.
  • the server includes first transaction data including failure information indicating that one IoT device among the one or more IoT devices has failed, and time information when the one IoT device acquires the failure information. From the one IoT device, and transfers the acquired first transaction data to a plurality of second servers different from the first server among the plurality of servers, and the plurality of second servers. Together with executing a first consensus algorithm for agreeing on the legitimacy of the first transaction data, If the by emissions Census algorithm validity of the first transaction data is verified, recording a block including the first transaction data in a distributed ledger of the first server.
  • a first server is one of the plurality of servers in a system including one or more IoT devices and a plurality of servers capable of communicating with the one or more IoT devices via a network.
  • a first server of the above including a processor, a memory in which a program for causing the processor to execute processing is stored, and a storage device in which a distributed ledger in which a smart contract is stored is stored.
  • failure information indicating that one IoT device among the one or more IoT devices has failed, and when the one IoT device acquires the failure information, And acquiring first transaction data including time information from the one IoT device,
  • the processor transfers the acquired first transaction data to a plurality of second servers different from the first server of the plurality of servers by executing the program stored in the memory, Executing a first consensus algorithm with the plurality of second servers for agreeing on the legitimacy of the first transaction data, the legitimacy of the first transaction data being verified by the first consensus algorithm.
  • the block including the first transaction data is recorded in the distributed ledger of the first server.
  • a data structure according to an aspect of the present disclosure is applied to a block recorded in a distributed ledger in a system including one or more IoT devices and a plurality of servers capable of communicating with the one or more IoT devices via a network.
  • a data structure used wherein the data structure includes failure information indicating that one IoT device among the one or more IoT devices has failed, and the failure information when the one IoT device acquires the failure information.
  • Including first transaction data including time information wherein the first transaction data is acquired by a first server of the plurality of servers by operating a smart contract stored in the distributed ledger, The acquired first transaction data is included in the block and recorded in the distributed ledger. That.
  • control system 1 of the present disclosure uses the smart contract stored in the distributed ledger to record whether the result of the failure detection of the IoT device is recorded in the distributed ledger or not. It also has a mechanism to record.
  • FIG. 1 is a block diagram schematically showing the configuration of the control system 1 in this embodiment.
  • the control system 1 includes servers 10A, 10B, ..., 10E, a terminal 21, and one or more IoT devices 30. These are connected via the network N.
  • the servers 10A, 10B, ..., 10E are also referred to as “server 10A and the like”, and each of the servers 10A and the like is also referred to as “server 10”.
  • FIG. 1 shows an example in which the control system 1 includes five servers 10, but the present invention is not limited to this. That is, the control system 1 may include six or more servers 10.
  • FIG. 2 is a diagram schematically showing an example of the overall configuration of the server 10A shown in FIG.
  • FIG. 3 is a block diagram showing a functional configuration of the server 10A according to this embodiment.
  • the server 10A is connected to the storage device 12A as shown in FIG.
  • the server 10A may be connected to the storage device 12A via the network N, or may include the storage device 12A inside.
  • the storage device 12A has a distributed ledger 13A in which a smart contract unit 14A described later is stored.
  • the server 10A is an example of the first server.
  • the server 10A includes a smart contract execution unit 111, a transaction data verification unit 112, a block generation unit 114, a synchronization unit 115, a recording unit 116, and a communication unit 117, as shown in FIG.
  • the server 10A can be realized by the processor executing a predetermined program using the memory.
  • each component will be described.
  • the smart contract execution unit 111 operates the smart contract unit 14A by executing the contract code or the like stored in the distributed ledger 13A. By operating the smart contract unit 14A, the smart contract execution unit 111 can manage the buying and selling, unlocking, locking, and the like of the usage right of the IoT device 30 by the distributed ledger 13A.
  • the smart contract execution unit 111 executes the smart contract unit 14A.
  • the smart contract execution unit 111 includes, in the smart contract unit 14A, a first information including failure information indicating that one IoT device 30 has failed and time information when the one IoT device 30 acquired the failure information. Get transaction data. That is, the smart contract execution unit 111 acquires the first transaction data by operating the smart contract stored in the distributed ledger 13A.
  • the time information may be a time stamp when the failure information is acquired, or a sequence number.
  • the smart contract execution unit 111 may store information obtained as a result of operating the smart contract unit 14A in the on-memory of the server 10A.
  • the smart contract execution unit 111 may read the information recorded in the distributed ledger 13A as a result of operating the smart contract unit 14A, write the information in the memory (on-memory) of the server 10A, and store the information.
  • the smart contract execution unit 111 reads the first transaction data recorded in the distributed ledger 13A and generates status information indicating whether or not the IoT device 30 is available based on the read first transaction data. Good. Then, the smart contract execution unit 111 may write the generated state information in the memory included in the first server. The smart contract execution unit 111 may also write and retain the information indicating the usage right of the IoT device 30 and the open / closed state of the key of the IoT device 30 in the on-memory.
  • Transaction data verification unit 112 When the transaction data verification unit 112 receives the transaction data, it verifies the validity of the received transaction data.
  • the transaction data verification unit 112 includes a first transaction including failure information indicating that at least one IoT device 30 has failed and time information when the one IoT device 30 acquired the failure information. Data is received from the smart contract execution unit 111. Then, the transaction data verification unit 112 verifies the electronic signature included in the received first transaction data, and verifies the validity of the first transaction data. When the transaction data verification unit 112 receives the second transaction data indicating that the usage right of one IoT device 30 has been purchased, the transaction data verification unit 112 verifies the electronic signature included in the second transaction data, and then Validate the validity of the transaction data of. Similarly, when the transaction data verification unit 112 receives the third transaction data indicating the key unlock request of the one IoT device 30, the transaction data verification unit 112 verifies the electronic signature included in the third transaction data, and Validate the validity of the transaction data of.
  • the transaction data verification unit 112 verifies the acquired transaction data.
  • the transaction data verification unit 112 confirms the validity of the transaction data as a result of the verification, the transaction data verification unit 112 records the transaction data in the recording unit 116 and notifies the synchronization unit 115.
  • the transaction data verification unit 112 does not have to verify the validity of the transaction data when the transaction data is generated by the transaction data generation unit 113.
  • the block generation unit 114 executes a consensus algorithm for agreeing on the legitimacy of the transaction data together with the other second server (servers 10B to 10E) different from the first server.
  • the consensus algorithm here corresponds to the first consensus algorithm to the third consensus algorithm. That is, the first consensus algorithm to the third consensus algorithm are the same consensus algorithm and merely indicate that they are executed at different timings. Further, the transaction data here corresponds to the first transaction data to the third transaction data.
  • the block generation unit 114 executes the consensus algorithm among a plurality of authentication servers.
  • a consensus algorithm called PBFT (Practical Byzantine Fault Tolerance) may be used, or another known consensus algorithm may be used.
  • Known consensus algorithms include, for example, POW (Proof Of Work) and POS (Proof Of Stake).
  • POW Proof Of Work
  • POS Proof Of Stake
  • the block generation unit 114 first receives a report indicating whether the transaction verification is successful from each of the other authentication servers 200b and 200c, and the number of reports exceeds a predetermined number. It is determined whether or not. Then, the block generation unit 114 may determine that the validity of the transaction data is verified by the consensus algorithm when the number of reports exceeds a predetermined number.
  • the block generation unit 114 records the block including the transaction data in the distributed ledger of the storage device 12A of the server 10A when the validity of the transaction data is verified by the consensus algorithm.
  • the block generation unit 114 executes the consensus algorithm among the servers 10A to 10E. More specifically, the block generation unit 114 first generates a block of a block chain including one or more transaction data. Next, the block generator 114 executes a consensus algorithm. Then, when the consensus can be formed by executing the consensus algorithm, the block generation unit 114 records the generated block in the recording unit 116. The block generated by the block generation unit 114 is connected to the block chain stored in the distributed ledger 13A and recorded by the recording unit 116.
  • FIG. 4 is an explanatory diagram showing the data structure of the block chain.
  • a block chain is one in which the blocks that are the recording units are connected in a chain.
  • Each block has a plurality of transaction data and the hash value of the immediately preceding block.
  • the block B2 includes the hash value of the preceding 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.
  • FIG. 5 is an explanatory diagram showing the data structure of transaction data.
  • the transaction data D1 shown in FIG. 5 is an example of first to third transaction data.
  • the transaction data D1 should be signed with the requester's signature key P1 indicating the requester such as the user A, the smart contract address, the function name, the address P2 indicating the argument, and the hash values of the addresses P1 and P2.
  • the smart contract address, the function name, and the argument are described in, for example, the JSON format, but the present invention is not limited to this.
  • the smart contract address is the address of a smart contract which is a program for contract.
  • the synchronization unit 115 synchronizes block chain blocks or transaction data among a plurality of servers (server 10A to server 10E).
  • the synchronization unit 115 copies the first to third transaction data to other servers (server 10B to server 10E). Forward.
  • block chain transaction data is synchronized with peer to peer. Then, the synchronization unit 115 records the synchronized block chain transaction data in the recording unit 116.
  • the synchronization unit 115 transfers the contents of the first transaction data to other servers (servers 10B to 10E). Further, the synchronization unit 115 records the verified first transaction data in the recording unit 116.
  • the synchronization unit 115 when the synchronization unit 115 receives the first transaction data from another server (one of the servers 10B to 10E), the synchronization unit 115 records the first transaction data in the recording unit 116. Since the same applies to the second and third transaction data, a description thereof will be omitted.
  • the recording unit 116 includes the transaction data in a block and records it in the distributed ledger 13A of the storage device 12A.
  • the recording unit 116 records the block including the first transaction data in the distributed ledger 13A of the server 10A when the validity of the first transaction data is verified by the first consensus algorithm. Since the same applies to the second and third transaction data, a description thereof will be omitted.
  • the communication unit 117 communicates with the terminal 21, the IoT device 30, and a plurality of other servers 10 (servers 10B to 10E). More specifically, the communication unit 117 is a communication interface that communicates with the terminal 21, the IoT device 30, and a plurality of other servers 10 (servers 10B to 10E). Communication with the terminal 21, the IoT device 30, and the plurality of other servers 10 (servers 10B to 10E) may be performed by TLS. In this case, the communication unit 117 may hold the encryption key for TLS communication.
  • the storage device 12A has a distributed ledger 13A for managing the buying, selling, unlocking and locking of the usage right of the IoT device 30.
  • the storage device 12A is realized by an HDD (Hard Disk Drive), an SSD (Solid State Drive), or the like.
  • the distributed ledger 13A block chain transaction data and blocks are electronically recorded. Further, the distributed ledger 13A stores a smart contract unit 14A which is a program.
  • the storage device 12A stores, for example, a program code called a contract code, and the smart contract unit 14A may be able to be executed by executing this contract code.
  • FIG. 6 is a block diagram showing a functional configuration of the smart contract unit 14A in the present embodiment.
  • the smart contract unit 14A includes a device usage right management unit 141, a service providing unit 142, and a failure registration unit 145.
  • the device usage right management unit 141 manages the usage right of the IoT device 30.
  • the device usage right management unit 141 receives, as a user request, an inquiry as to whether the target IoT device 30 is available from the terminal 21, the target IoT device 30 recorded in the distributed ledger 13A. Check the latest status of usage rights of.
  • the device usage right management unit 141 determines whether the usage right of the target IoT device 30 can be purchased, or the usage right of the target IoT device 30 is purchased by the user A of the terminal 21.
  • the service providing unit 142 is informed of whether or not the service is being provided.
  • the service providing unit 142 includes a usability determination unit 143 and a ledger event issuing unit 144.
  • the availability determining unit 143 determines whether the request is from a user A who has the right to use the target IoT device 30 and whether the target IoT device 30 can provide a service.
  • the availability determination unit 143 receives a user request from the terminal 21 to inquire whether the user A can use the one IoT device 30, whether the one IoT device 30 is available is determined. Read out the status information.
  • the state information may be held in the on-memory, that is, the memory of the server 10A.
  • the availability determination unit 143 may read the state information in the memory of the server 10A when the user request is received from the terminal 21.
  • the availability determination unit 143 determines from the read state information that the one IoT device 30 is available, the availability of the one IoT device 30 under a predetermined condition is used for the terminal 21. A first signal indicating that the permission is permitted. On the other hand, if the availability determination unit 143 determines from the read state information that the one IoT device 30 is unavailable, it indicates that the terminal 21 is not permitted to use the one IoT device. Send the signal shown.
  • the availability determination unit 143 when the availability determination unit 143 receives the user request, the availability determination unit 143 reads out the status information that can be obtained from the first transaction data recorded in the distributed ledger 13A or is on-memory, and the target IoT. It is confirmed whether the device 30 is in a failure state.
  • the availability determination unit 143 determines whether the target IoT device 30 is available based on the latest status of the usage right notified from the device usage right management unit 141 and whether or not the target IoT device 30 is in a failure state. Determine whether
  • the availability determining unit 143 determines that the target IoT device 30 is available, it sends an OK notification to the terminal 21.
  • the target IoT device 30 can be used and the usage right can be purchased, or the usage right of the target IoT device 30 has been purchased by the user A of the terminal 21 according to the content of the user request. And indicates that the IoT device 30 is available.
  • the availability determination unit 143 determines that the target IoT device 30 is not available, it sends a signal indicating an NG notification to the terminal 21.
  • the NG notification is unavailable because the usage right of the target IoT device 30 has been purchased by another person and cannot be used, or the target IoT device 30 is out of order and cannot be used. Indicates that.
  • the ledger event issuing unit 144 issues ledger events necessary for providing services.
  • the ledger event issuing unit 144 receives (acquires) the transaction data of the key opening / closing request of the IoT device 30 from the terminal 21, the ledger event issuing unit 144 detects the key of the IoT device 30 recorded in the distributed ledger 13A. Change the open / closed state. More specifically, when the ledger event issuing unit 144 receives the transaction data of the opening / closing request, it sends it to the server 10A.
  • the server 10A synchronizes the block having the transaction of the opening / closing request with the consensus algorithm and then records the block in the distributed ledger 13A, thereby causing a state change on the distributed ledger 10A.
  • the transaction data of the opening / closing request for example, in P2 shown in FIG. 5, the contract address, the function for opening / closing the key, and the argument are set in the JSON format.
  • the ledger event issuing unit 144 changes the open / closed state of the key of the target IoT device 30 held on the on-memory, for example.
  • the ledger event issuing unit 144 changes the open / closed state of the key of the target IoT device 30 held in the on-memory from the locked state to the unlocked state.
  • the ledger event issuing unit 144 may record the transaction data in the distributed ledger 13A.
  • the ledger event issuing unit 144 may record the transaction data in the distributed ledger 13A.
  • the failure registration unit 145 confirms that the failure notification is from the IoT device 30 itself, and puts the service in an unavailable state.
  • the failure registration unit 145 when the failure registration unit 145 acquires a failure notification indicating that one IoT device 30 has failed, whether or not the failure notification is from the IoT device 30 itself is determined by an electronic signature or the like. Check. Upon confirming that the IoT device 30 itself is the failure notification, the failure registration unit 145 changes the state information of the IoT device 30 on the on-memory from normal to information indicating a failure.
  • the failure registration unit 145 includes the first transaction data including failure information indicating that one IoT device 30 has failed and time information when the one IoT device 30 acquires the detection information or the failure information. May be received from one IoT device 30. .
  • the failure registration unit 145 transmits the received first transaction data to the server 10A and causes the server 10A to record the first transaction data in the distributed ledger 13A. In this way, the failure registration unit 145 can register the failure of one IoT device 30 in the distributed ledger 13A.
  • the IoT device 30 is, for example, a delivery box, a sharing car, a sharing bike, a hotel room, or the like.
  • the IoT device 30 is not limited to these, and may be any device as long as the point where the user A tries to obtain the usage permission and the point where the user A is actually used are distant from each other.
  • the IoT device 30 can be used only by a person who is permitted to use it, that is, a person who has a right (use right) to lock and unlock.
  • the number of persons having the authority (usage right) to unlock and lock is, for example, one, but is not limited to one.
  • the IoT device 30 when the IoT device 30 is a delivery box, it is equipped with one or more units 31 each capable of storing the article 5.
  • the unit 31 is a temporary storage place for the article 5 and is used by the user A to hand over the article 5 to another user.
  • the unlocking or locking of the IoT device 30 is controlled by a smart contract operating on the server 10A or the like.
  • the IoT device 30 has a function of detecting a failure of itself and a function of notifying the server 10A of failure information indicating the failure. These functions, that is, the function of controlling itself, the function of detecting the function, and the function of notifying are performed by a program recorded in the IoT device 30 (hereinafter referred to as the IoT device management unit 32).
  • FIG. 7 is a block diagram showing a functional configuration of the IoT device management unit 32 in this embodiment.
  • the IoT device management unit 32 is composed of a ledger event monitoring unit 321, a device control unit 322, and a failure control unit 323.
  • the ledger event monitoring unit 321 monitors the events recorded in the distributed ledger 13A and acquires the event issued by the smart contract unit 14A. This event also contains transaction data.
  • the ledger event monitoring unit 321 monitors the open / closed state of the key of the IoT device 30 held in the on-memory.
  • the ledger event monitoring unit 321 issues the open / closed state of the key of the one IoT device 30 by the smart contract unit 14A. It is acquired as the event type. Further, the ledger event monitoring unit 321 may instruct the device control unit 322 to bring the key of the one IoT device 30 into the changed open / closed state based on the acquired event type.
  • the ledger event monitoring unit 321 may monitor the distributed ledger 13A by the smart contract unit 14A. For example, when ledger event monitoring unit 321 records transaction data that changes the open / closed state of the key of target IoT device 30 in distributed ledger 13A, it acquires that as the event type issued by smart contract unit 14A. May be. The ledger event monitoring unit 321 may instruct the device control unit 322 to open and close the key of the target IoT device 30 recorded in the distributed ledger 13A based on the acquired event type.
  • the device control unit 322 controls the IoT device 30 based on the event type acquired by the ledger event monitoring unit 321.
  • the device control unit 322 determines the key of the target IoT device 30 based on the open / closed state of the key of the target IoT device 30 which is changed in the on-memory or is newly recorded in the distributed ledger 13A. Control the opening and locking of.
  • the device control unit 322 may control the lock / unlock of the key of the target IoT device 30 based on the content instructed by the ledger event monitoring unit 321.
  • the device control unit 322 may control the opening and locking of the key of the target IoT device 30 and then generate transaction data to that effect and send it to the server 10A.
  • the transaction data includes unlocking information indicating that the key of the target IoT device 30 has been unlocked, and time information when the unlocking information was acquired.
  • the device control unit 322 unlocks the key of the IoT device, for example, when the smart contract unit 14A acquires the unlock request for the IoT device based on the usage right of the target IoT device.
  • the failure control unit 323 includes a failure detection unit 324 and a failure notification unit 325.
  • the failure detection unit 324 detects a failure of the IoT device 30.
  • the failure detection unit 324 detects the failure of the IoT device 30 by checking the state of the IoT device 30 constantly or at predetermined intervals.
  • the failure notification unit 325 notifies the failure of the IoT device 30 by using the failure registration unit 145 of the smart contract unit 14A recorded in the distributed ledger 13A.
  • the failure notification unit 325 sends the first transaction data to the failure registration unit 145 of the smart contract unit 14A when the failure detection unit 324 detects the failure of the IoT device 30.
  • the first transaction data includes failure information indicating that the IoT device 30 has failed and time information when the IoT device detects the failure information.
  • the failure notification unit 325 sends the first transaction data to the failure registration unit 145 of the smart contract unit 14A, including the identification information such as a number for identifying the IoT device 30 and the identification information indicating the transmission source. You may.
  • the terminal 21 is a terminal that can communicate with the plurality of servers 10 (servers 10A, 10B, ..., 10E) via the network N, and is a terminal used by the user A.
  • the terminal 21 is, for example, a smartphone or a personal computer.
  • the terminal 21 receives an operation for acquiring a usage right for using the IoT device 30 or an operation for unlocking or locking the key from the user, and sends information related to the operation to the server 10A or the like as a user request. Send.
  • the terminal 21 is used by the user A and is shown to use one unit 31 of the IoT device 30, which is a delivery box, to deliver the article 5 to another user.
  • the function of accepting an operation from the user A and authenticating the user A in order to transmit the user request to the server 10A is performed by a program recorded in the terminal 21 (hereinafter, a user request processing unit). 22).
  • FIG. 8 is a block diagram showing a functional configuration of the user request processing unit 22 in this embodiment.
  • the user request processing unit 22 is composed of a user request receiving unit 221, a user authentication unit 222, and a transaction data processing unit 223.
  • the user request receiving unit 221 receives a user request for unlocking the IoT device 30 or the like.
  • the user request receiving unit 221 receives an inquiry as to whether the target IoT device 30 is available or a user request indicating an unlock request for the target IoT device 30.
  • the user request may be an inquiry about whether or not the user A has the usage right of the target IoT device 30 other than these.
  • the user authentication unit 222 carries out personal authentication of the user who has issued the user request.
  • the user authentication unit 222 authenticates the user A who has issued the user request in order to verify the validity of the user request received by the user request reception unit 221.
  • the transaction data processing unit 223 includes a usability inquiry unit 224 and a transaction data generation unit 225.
  • the availability inquiry unit 224 inquires whether transaction data can be received based on a user request.
  • the availability inquiry unit 224 inquires whether the target IoT device 30 is available and inquires whether an unlock request for the target IoT device 30 is accepted.
  • transaction data including information indicating the requester, information indicating the inquiry content, and identification information such as a number for identifying the IoT device 30 to be inquired is generated and transmitted to the smart contract unit 14A. May be done by that.
  • the transaction data generation unit 225 issues transaction data based on a user request to the distributed ledger 13A.
  • the transaction data based on the user request is encrypted with the secret key of the user A, and the personal authentication of the user A can be performed by using this secret key.
  • the transaction data generation unit 225 may generate transaction data indicating an inquiry. Further, the transaction data generation unit 225 may generate transaction data indicating that the right to use one IoT device 30 is purchased. Further, the transaction data generation unit 225 may generate transaction data indicating an unlock request for the target IoT device 30 as a user request indicating an unlock request for the target IoT device 30.
  • FIG. 9 is a flowchart showing a control method executed by the control system 1 in this embodiment.
  • the first server in the control system 1 such as the server 10A determines whether or not the first transaction data is acquired from at least one IoT device 30 among the one or more IoT devices 30. Confirm (S12).
  • the first transaction data includes failure information indicating that at least one IoT device has failed, and time information when the at least one IoT device acquired the failure information.
  • step S12 when the first server acquires the first transaction data from at least one IoT device 30 (Yes in S12), the first server acquires the acquired first transaction data as the first server among the plurality of servers 10. Transfer to a plurality of second servers different from (S13).
  • the first server together with the plurality of second servers, executes the first consensus algorithm for agreeing on the validity of the first transaction data (S14).
  • the first server records the block including the first transaction data in the distributed ledger of the first server. Yes (S16).
  • the first server ends the process when the validity of the first transaction data is not verified by the first consensus algorithm (No in S15).
  • the IoT device 30 is a home delivery box and includes three units 31 to which ID0001 to ID0003 are assigned.
  • FIG. 10 is a sequence diagram showing a user request process when control of the IoT device 30 in this embodiment is unnecessary.
  • 11A and 11C are diagrams showing an example of the data structure of transaction data used when the processing of the user request shown in FIG. 10 is performed.
  • FIG. 11B is a diagram showing an example of the data structure of the OK notification used when the processing of the user request shown in FIG. 10 is performed.
  • the target that is, the usage target
  • the usage right of the target IoT device 30 can be purchased.
  • the user A makes a user request to the terminal 21 to obtain a use permission of the unit 31 of ID0002 of the IoT device 30, for example.
  • the user request processing unit 22 of the terminal 21 accepts the user request and performs a user authentication process for authenticating whether or not the user A who issued the user request is the user (S101).
  • the user request processing unit 22 issues an inquiry to the distributed ledger 13A as to whether the unit 31 of ID0002 is available (S102).
  • the user request processing unit 22 operates the smart contract unit 14A by issuing transaction data having a data structure as shown in FIG. 11A to the distributed ledger 13A.
  • FIG. 11A has a data structure including usrA indicating that the requester is user A, 0002 indicating the identification information of the unit 31 of ID0002, and query_reserve indicating an inquiry as to whether or not the unit 31 of ID0002 is available.
  • the transaction data that is composed is shown.
  • FIG. 11A as an inquiry as to whether the unit 31 of ID0002 is available, an inquiry is made as to whether the usage right of the unit 31 of ID0002 has been purchased.
  • the smart contract unit 14A confirms the latest status of the distributed ledger 13A to confirm the status of the usage right of the unit 31 of ID0002 and the service mode (S103).
  • the smart contract unit 14A determines whether or not the unit 31 of ID0002 can provide a service based on the status of the usage right and the service mode of the unit 31 of ID0002 that have been confirmed (S104).
  • the smart contract unit 14A determines that the unit 31 of ID0002 is available because the usage right of the unit 31 of ID0002 can be purchased and the unit 31 of ID0002 is not broken.
  • the smart contract unit 14A since the smart contract unit 14A determines that the unit 31 of ID0002 is available, it sends an OK notification to the user request processing unit 22 of the terminal 21 (S105).
  • the smart contract unit 14A sends an OK notification having a data structure as shown in FIG. 11B to the user request processing unit 22.
  • FIG. 11B is composed of a data structure including 0002 indicating the identification information of the unit 31 of ID0002, Notuse indicating that the unit 31 of ID0002 is not used, and 100 yen indicating the amount of money for which the usage right can be purchased.
  • the data structure of the OK notification is shown.
  • the user request processing unit 22 issues transaction data indicating that the usage right of the unit 31 of ID0002 is purchased to the distributed ledger 13A (S106).
  • the user request processing unit 22 operates the smart contract unit 14A by generating transaction data having a data structure as shown in FIG. 11C and transmitting the transaction data to the distributed ledger 13A.
  • FIG. 11C includes data including usrA indicating that the requester is the user A, 0002 indicating identification information of the unit 31 of ID0002, and reserve indicating that the unit 31 of ID0002 is reserved, that is, the usage right is purchased. Transaction data composed of structures is shown.
  • the smart contract unit 14A performs a service process of issuing transaction data indicating that the user A has purchased the usage right of the unit 31 of ID0002 to the distributed ledger 13A (S107).
  • the smart contract unit 14A receives the second transaction data indicating that the user A has purchased the usage right of the unit 31 of ID0002 from the user request processing unit 22, the smart contract unit 14A transmits it to the server 10 and distributes it. It is recorded in the ledger 13A.
  • FIG. 12 is a sequence diagram showing processing of a user request when control of the IoT device 30 in this embodiment is necessary.
  • FIG. 13A is a diagram showing an example of the data structure of an OK notification used when the processing of the user request shown in FIG. 12 is performed.
  • 13B and 13C are diagrams showing an example of the data structure of transaction data used when the processing of the user request shown in FIG. 12 is performed.
  • the target IoT device 30 has not failed, and the usage right of the target IoT device 30 has been purchased by the user A.
  • the user A makes a user request to the terminal 21, for example, a request to unlock the key of the unit 31 of ID0002 of the IoT device 30.
  • the user request processing unit 22 of the terminal 21 accepts the user request and performs a user authentication process for authenticating whether the user A who issued the user request is the user (S201).
  • the user request processing unit 22 issues an inquiry to the distributed ledger 13A as to whether the unit 31 of ID0002 is available (S202).
  • the user request processing unit 22 operates the smart contract unit 14A by issuing transaction data having a data structure as shown in FIG. 11A to the distributed ledger 13A.
  • the smart contract unit 14A confirms the latest status of the distributed ledger 13A to confirm the status of the usage right of the unit 31 of ID0002 and the service mode (S203).
  • the smart contract unit 14A determines whether the service of the unit 31 of ID0002 can be provided based on the status of the usage right of the unit 31 of ID0002 and the service mode which are confirmed (S204). Here, the smart contract unit 14A determines that the unit 31 of ID0002 is available because the user has purchased the right to use the unit 31 of ID0002 and the unit 31 of ID0002 is not broken.
  • the smart contract unit 14A since the smart contract unit 14A determines that the unit 31 of ID0002 is available, it sends an OK notification to the user request processing unit 22 of the terminal 21 (S205).
  • the smart contract unit 14A sends an OK notification having a data structure as shown in FIG. 13A to the user request processing unit 22.
  • FIG. 13A 0002 indicating the identification information of the unit 31 of ID0002, usrA indicating that the usage right of the unit 31 of ID0002 is purchased by the user A, and 100 yen indicating the amount of the usage right purchased.
  • the data structure of the OK notification composed of the data structure including is shown.
  • the user request processing unit 22 issues transaction data indicating an unlock request for the key of the unit 31 of ID0002 to the distributed ledger 13A (S206).
  • the user request processing unit 22 operates the smart contract unit 14A by generating transaction data having a data structure as shown in FIG. 13B and transmitting it to the distributed ledger 13A.
  • FIG. 13B has a data structure including usrA indicating that the requester is the user A, 0002 indicating the identification information of the unit 31 of ID0002, and open indicating the unlocking request of the key of the unit 31 of ID0002. Transaction data to be processed is shown.
  • the smart contract unit 14A acquires the transaction data indicating the unlock request from the user request processing unit 22, the open / closed state of the key of the unit 31 of ID0002 held in the on-memory is opened. Service processing for shifting to the locked state is performed (S207). Further, the smart contract unit 14A changes the open / closed state of the key of the unit 31 of ID0002 recorded in the distributed ledger 13A (S208). More specifically, the smart contract unit 14A transmits transaction data indicating the unlock request to the server 10A having the distributed ledger 13A. Then, the server 10A synchronizes the block having the transaction of the opening / closing request with the consensus algorithm and then records the block in the distributed ledger 13A, thereby causing a state change on the distributed ledger 10A.
  • the IoT device management unit 32 monitors ledger events such as the open / closed state of the key of the IoT device 30 held in the on-memory, and the open / closed state of the key of the unit 31 of ID0002 becomes the unlocked state. The fact that the transfer has been made is acquired (S209).
  • the IoT device management unit 32 performs unlocking control to unlock the key of the unit 31 of ID0002 (S210), and generates the third transaction data indicating that the key of the unit 31 of ID0002 is unlocked. (S211). Then, the IoT device management unit 32 transmits the generated third transaction data to the distributed ledger 13A. In the present embodiment, the IoT device management unit 32 generates the third transaction data having the data structure shown in FIG. 13C and sends it to the distributed ledger 13A.
  • FIG. 13C has a data structure including dev indicating that the implementer is the IoT device management unit 32, 0002 indicating the identification information of the unit 31 of ID0002, and register_opened indicating that the key is unlocked. The transaction data that is composed is shown.
  • the smart contract unit 14A acquires the third transaction data, it records the third transaction data in the distributed ledger 13A (S212).
  • FIG. 14 is a sequence diagram showing a failure detection process when the IoT device 30 according to the present embodiment detects a failure.
  • FIG. 15 is a diagram showing an example of the data structure of transaction data used when the failure detection process shown in FIG. 14 is performed. In the following, it is assumed that the unit 31 to which ID0002 is given out of the three units 31 forming the target IoT device 30 has failed.
  • the IoT device management unit 32 of the IoT device 30 always confirms the state of the IoT device 30 or at every predetermined period, and thus detects that the unit 31 of ID0002 has failed (S301). ).
  • the IoT device management unit 32 generates transaction data indicating that the unit 31 of ID0002 has failed (S302).
  • the IoT device management unit 32 sends a failure notification that transmits the transaction data generated in step S302 to the smart contract unit 14A as failure information indicating that the unit 31 of ID0002 of the IoT device 30 has failed (S303).
  • the IoT device management unit 32 generates transaction data having a data structure as shown in FIG. In FIG. 15, data including dev indicating that the detector is the IoT device management unit 32, 0002 indicating identification information of the unit 31 of ID0002, and disabled indicating that the unit 31 of ID0002 is unavailable. Transaction data composed of structures is shown. Then, the IoT device management unit 32 operates the smart contract unit 14A by issuing the transaction data thus created to the distributed ledger 13A.
  • the smart contract unit 14A performs failure registration to change the status information of the unit 31 of ID0002 held in the on-memory from normal to failure (S304).
  • the smart contract unit 14A manages the state information of the IoT device 30 by writing and holding the state information in the on-memory of the server 10A.
  • FIG. 16A and 16B are diagrams showing state information managed by the smart contract unit 14A in the embodiment.
  • the state information shown in FIG. 16A indicates that all the three units 31 configuring the IoT device 30 are normal with no failure.
  • FIG. 16A shows that the usage right of the unit 31 of ID0001 has been purchased by the user A. It is shown that the service company owns the usage right of the ID0002 and the unit 31 of the ID0003, and the usage right can be purchased, that is, can be used.
  • the state information shown in FIG. 16B indicates that the unit 31 of ID0002 out of the three units 31 forming the IoT device 30 is out of order. That is, in the present embodiment, the smart contract unit 14A performs failure registration by updating the state information shown in FIG. 16A to the state information shown in FIG. 16B.
  • the smart contract unit 14A includes the first transaction including failure information indicating that the unit 31 of ID0002 has failed and time information when the unit 31 of ID0002 acquires the failure information. Get the data. Therefore, the smart contract unit 14A records the first transaction data in the distributed ledger 13A by transmitting the acquired first transaction data to the distributed ledger 13A.
  • the smart contract unit 14A manages the unit 31 of ID0002 as the unavailable service state using the state information shown in FIG. 16B (S305).
  • FIG. 17 is a sequence diagram showing another example of the processing of the user request when the control of the IoT device 30 in this embodiment is unnecessary.
  • FIG. 18 is a diagram showing an example of the data structure of the NG notification used when the processing of the user request shown in FIG. 17 is performed.
  • the unit 31 assigned with ID0002 is out of order.
  • the user A makes a user request to the terminal 21 to obtain a permission to use the unit 31 of ID0002 of the IoT device 30, for example.
  • the user request processing unit 22 of the terminal 21 accepts the user request and carries out a user authentication process for authenticating whether or not the user A who issued the user request is the principal (S401).
  • the user request processing unit 22 issues an inquiry to the distributed ledger 13A as to whether the unit 31 of ID0002 is available (S402).
  • the user request processing unit 22 operates the smart contract unit 14A by issuing transaction data having a data structure as shown in FIG. 11A to the distributed ledger 13A. Since FIG. 11A has been described above, its description is omitted here.
  • the smart contract unit 14A confirms the latest status of the distributed ledger 13A to confirm the status of the usage right of the unit 31 of ID0002 and the service mode (S403).
  • the smart contract unit 14A determines whether or not the service of the unit 31 of ID0002 can be provided, based on the status of the usage right and the service mode of the unit 31 of ID0002 that have been confirmed (S404).
  • the smart contract unit 14A determines that the usage right of the unit 31 of ID0002 can be purchased, but the unit 31 of ID0002 is out of order and the unit 31 of ID0002 is unavailable.
  • the smart contract unit 14A since the smart contract unit 14A determines that the unit 31 of ID0002 is unavailable, it sends an NG notification to the user request processing unit 22 of the terminal 21 (S405).
  • the smart contract unit 14A sends an NG notification having a data structure as shown in FIG. 18 to the user request processing unit 22.
  • FIG. 18 has a data structure including 0002 indicating the identification information of the unit 31 of ID0002, disable indicating that the unit 31 of ID0002 is unavailable, and 100 yen indicating the amount of money for which the usage right can be purchased.
  • the data structure of the NG notification is shown.
  • the user request processing unit 22 since the user request processing unit 22 receives the NG notification, the user request processing unit 22 transmits the NG notification to the user A (S406) and notifies the user A that the use permission of the unit 31 having ID0002 cannot be obtained. .
  • control method and control system 1 of the present disclosure has a method for notifying that an IoT device has failed using a smart contract.
  • the IoT device detects a failure by itself, the IoT device uses a method for notifying that it has failed and notifies that it is in a failure state.
  • the PKI signature
  • the notification is from the IoT device that detected the failure.
  • FIG. 19 is a diagram schematically showing a problem in the comparative example.
  • FIG. 20 is a diagram schematically showing the effect of the present disclosure. 19 and 20 will be described assuming that one unit 31 out of the plurality of units 31 configuring the IoT device 30, which is, for example, a home delivery box, is out of order.
  • the delivery company 50 does not know that the one unit 31 to be used is out of order. By purchasing the usage right of the unit 31, it is possible to reserve the usage of the one unit 31. Therefore, the delivery company 50 moves to the site where the unit 31 is located after purchasing the usage right of the unit 31. However, since the one unit 31 is out of order, the delivery company 50 does not operate even if the delivery company 50 tries to unlock the unit to use the one unit after arriving at the site.
  • the delivery company 50 does not need to know that the one unit 31 is out of order to deliver the package to the one unit 31.
  • the use of the unit 31 cannot be reserved.
  • the delivery company 50 can suppress the actual movement to the malfunctioning IoT device, do not take extra trouble such as movement, and do not spend time and energy for the movement.
  • control method and control system of the present disclosure by storing the program of the transaction conditions as a smart contract in the distributed ledger, it is possible to record information indicating whether or not the IoT device has a failure in the distributed ledger. In this way, the information indicating whether or not the IoT device is out of order can be disclosed in a form that cannot be tampered with by the block chain, and thus illegal transactions can be suppressed.
  • the IoT device fails after starting the service of using the IoT device, not only the user can be notified that the IoT device has failed, but also the distributed ledger as evidence. Can be recorded in. With this, even a user who uses the IoT device and a provider who provides a service of using the IoT device can promptly deal with the damage, and the damage can be minimized.
  • the present disclosure also includes a data structure used for blocks recorded as a block chain in the control system 1 of the above embodiment. More specifically, the data structure of the present disclosure is used for blocks recorded in a distributed ledger in a system including one or more IoT devices and a plurality of servers capable of communicating with one or more IoT devices via a network. It is a data structure that is used.
  • the data structure includes first transaction data including failure information indicating that one IoT device out of one or more IoT devices has failed and time information when the one IoT device acquires the failure information. including.
  • the first transaction data included in the data structure of the present disclosure is acquired by the first server of the plurality of servers by operating the smart contract stored in the distributed ledger, and the acquired first transaction data is acquired. Transaction data is contained in blocks and recorded in the distributed ledger.
  • the blockchain is described as the blockchain mounting base that realizes the distributed ledger management, but the present invention is not limited to this.
  • Other blockchain implementation platforms such as Hyperledger fabric may be used.
  • Each device in the above embodiments is specifically a computer system including 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.
  • Each device achieves its function by the microprocessor operating according to the computer program.
  • the computer program is configured by combining a plurality of instruction codes indicating instructions to the computer in order to achieve a predetermined function.
  • the system LSI is a super-multifunctional LSI manufactured by integrating a plurality of components on a single chip, and specifically, is a computer system including a microprocessor, ROM, RAM and the like. . A computer program is recorded in the RAM. The system LSI achieves its function by the microprocessor operating according to the computer program.
  • each part of the constituent elements of each of the above devices may be individually made into one chip, or may be made into one chip so as to include a part or all.
  • system LSI may also be called IC, LSI, super LSI, or ultra LSI depending on the degree of integration.
  • the method of circuit integration is not limited to LSI, and it may be realized by a dedicated circuit or a general-purpose processor.
  • a programmable programmable gate array (FPGA) that can be programmed after the LSI is manufactured, or a reconfigurable processor that can reconfigure the connection and setting of circuit cells inside the LSI may be used.
  • each of the above devices may be composed of an IC card that can be attached to and detached from each device or a single module.
  • the IC card or the module is a computer system including a microprocessor, ROM, RAM and the like.
  • the IC card or the module may include the super multifunctional LSI described above. When the microprocessor operates according to the computer program, the IC card or the module achieves its function. This IC card or this module may be tamper resistant.
  • the present disclosure may be the method described above. Further, it may be a computer program that realizes these methods by a computer, or may be a digital signal including the computer program.
  • the present disclosure also discloses a computer-readable recording medium such as a flexible disk, a hard disk, a CD-ROM, a MO, a DVD, a DVD-ROM, a DVD-RAM, or a BD (Blu-ray). (Registered trademark) Disc), a semiconductor memory, or the like. Further, it may be the digital signal recorded on these recording media.
  • a computer-readable recording medium such as a flexible disk, a hard disk, a CD-ROM, a MO, a DVD, a DVD-ROM, a DVD-RAM, or a BD (Blu-ray). (Registered trademark) Disc), a semiconductor memory, or the like. Further, it may be the digital signal recorded on these recording media.
  • the present disclosure may transmit the computer program or the digital signal via an electric communication line, a wireless or wired communication line, a network represented by the Internet, a data broadcast, or the like.
  • the present disclosure may be a computer system including a microprocessor and a memory, the memory recording the computer program, and the microprocessor may operate according to the computer program.
  • the present disclosure can be used for a control method, a control system, a first server, and a data structure.
  • the present invention can be used for a control method, a control system, a first server, a data structure, etc. for recording in a distributed ledger using a smart contract stored in.

Landscapes

  • Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • Tourism & Hospitality (AREA)
  • Automation & Control Theory (AREA)
  • Marketing (AREA)
  • Theoretical Computer Science (AREA)
  • Strategic Management (AREA)
  • Operations Research (AREA)
  • Human Resources & Organizations (AREA)
  • General Business, Economics & Management (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Quality & Reliability (AREA)
  • Economics (AREA)
  • Development Economics (AREA)
  • Computer And Data Communications (AREA)
  • Hardware Redundancy (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

本開示の制御方法は、１以上のＩｏＴデバイスと、複数のサーバとを備えるシステムにおける、複数のサーバのうちの第１サーバによって実行される制御方法であって、１以上のＩｏＴデバイスのうちの一のＩｏＴデバイスが故障したことを示す故障情報と、前記一のＩｏＴデバイスが、故障情報を取得したときの時刻情報とを含む第１のトランザクションデータを取得し（Ｓ１２でｙｅｓ）、取得した第１のトランザクションデータを、第１サーバとは異なる複数の第２サーバに転送し（Ｓ１３）、複数の第２サーバとともに、第１のトランザクションデータの正当性について合意するための第１のコンセンサスアルゴリズムを実行し（Ｓ１４）、第１のコンセンサスアルゴリズムによって第１のトランザクションデータの正当性が検証された場合、第１のトランザクションデータを含むブロックを前記第１サーバの分散台帳に記録する（Ｓ１６）。

Description

制御方法、制御システム、第１サーバ、及び、データ構造
　本開示は、制御方法、制御システム、第１サーバ、及び、データ構造に関する。
　例えば宅配ボックスを構成するユニットの開錠（解錠）又は施錠である開施錠を、ブロックチェーンを用いて管理する技術が開示されている（非特許文献１参照）。宅配ボックスを構成するユニットの開施錠の管理には、ブロックチェーンを用いたスマートコントラクトが用いられ得る。
ＧＭＯインターネット株式会社、"ＧＭＯインターネットグループ、セゾン情報システムズ、パルコが共同でブロックチェーンとＩｏＴを活用した実証実験の第二弾を実施"、［ｏｎｌｉｎｅ］、平成２９年６月２１日、［平成３０年１０月２５日検索］、インターネット<URL:https://cloud.z.com/jp/news-ep/IoT2/>
　しかしながら、配送業者が宅配ボックスに荷物を配送する場合、当該宅配ボックスを構成する１以上のユニットの利用権を購入した後に当該ユニットが実在する現地に移動する。このため、配送業者が、現地に到着後、当該ユニットを利用するために開錠しようとしても当該ユニットが故障していて動作しないような場合も発生し得る。
　換言すると、宅配ボックスなどのＩｏＴ（Internet of Things）デバイスは、利用権を購入する地点と、現実に利用する地点であるＩｏＴデバイスがある地点とが離れている。さらに、ブロックチェーンの分散台帳は、複数の台帳を物理的に異なった拠点に設置されるので、ある地点に災害等が発生しても影響を受けずに動作するという特徴がある。一方で、宅配ボックスなどのＩｏＴデバイスは、自身が動作すべき場合に、災害、老朽化などにより故障等が発生して利用できないケースもある。このため、あるＩｏＴデバイスに対して、システム上で利用権を購入できるとしても、実際には故障している場合があり、現地では当該ＩｏＴデバイスを利用できないという場合も発生し得る。
　このような場合、現地において利用可能なＩｏＴデバイスを探索し、利用権を購入し直したり、現地に利用可能な他のＩｏＴデバイスがなければ利用可能なＩｏＴデバイスがある場所まで改めて移動したりしなければならない。そして、このような場合、故障しているＩｏＴデバイスまでの移動が無駄になり、移動等の手間が余計にかかるだけでなく移動に費やした時間とエネルギーとが無駄になる。
　本開示は、上述の事情を鑑みてなされたもので、分散台帳を用いて、時間コストとエネルギーコストとをより低減することができる制御方法などを提供する。
　上記課題を解決するために、本開示の一形態に係る制御方法は、１以上のＩｏＴ（Internet of Things）デバイスと、前記１以上のＩｏＴデバイスとネットワークを介して通信可能な複数のサーバとを備えるシステムにおける、前記複数のサーバのうちの第１サーバによって実行される制御方法であって、前記１以上のＩｏＴデバイスのうちの一のＩｏＴデバイスが故障したことを示す故障情報と、前記一のＩｏＴデバイスが前記故障情報を取得したときの時刻情報とを含む第１のトランザクションデータを、前記一のＩｏＴデバイスから取得し、取得した前記第１のトランザクションデータを、前記複数のサーバのうちの前記第１サーバとは異なる複数の第２サーバに転送し、前記複数の第２サーバとともに、前記第１のトランザクションデータの正当性について合意するための第１のコンセンサスアルゴリズムを実行し、前記第１のコンセンサスアルゴリズムによって前記第１のトランザクションデータの正当性が検証された場合、前記第１のトランザクションデータを含むブロックを前記第１サーバの分散台帳に記録する。
　なお、これらの全般的または具体的な態様は、システム、方法、集積回路、コンピュータプログラムまたはコンピュータで読み取り可能なＣＤ－ＲＯＭなどの記録媒体で実現されてもよく、システム、方法、集積回路、コンピュータプログラムおよび記録媒体の任意な組み合わせで実現されてもよい。
　本開示の制御方法等によれば、分散台帳を用いて、時間コストとエネルギーコストとをより低減することができる。
図１は、実施の形態における制御システムの構成を模式的に示すブロック図である。 図２は、図１に示すサーバの全体構成の一例を模式的に示す図である。 図３は、実施の形態におけるサーバの機能構成を示すブロック図である。 図４は、ブロックチェーンのデータ構造を示す説明図である。 図５は、トランザクションデータのデータ構造を示す説明図である。 図６は、実施の形態におけるスマートコントラクト部の機能構成を示すブロック図である。 図７は、実施の形態におけるＩｏＴデバイス管理部の機能構成を示すブロック図である。 図８は、実施の形態におけるユーザ要求処理部の機能構成を示すブロック図である。 図９は、実施の形態における制御システムが実行する制御方法を示すフローチャートである。 図１０は、実施の形態におけるＩｏＴデバイスの制御が不要な場合のユーザ要求の処理を示すシーケンス図である。 図１１Ａは、図１０に示すユーザ要求の処理が行われる際に用いられるトランザクションデータのデータ構造の一例を示す図である。 図１１Ｂは、図１０に示すユーザ要求の処理が行われる際に用いられるＯＫ通知のデータ構造の一例を示す図である。 図１１Ｃは、図１０に示すユーザ要求の処理が行われる際に用いられるトランザクションデータのデータ構造の一例を示す図である。 図１２は、実施の形態におけるＩｏＴデバイスの制御が必要な場合のユーザ要求の処理を示すシーケンス図である。 図１３Ａは、図１２に示すユーザ要求の処理が行われる際に用いられるＯＫ通知のデータ構造の一例を示す図である。 図１３Ｂは、図１２に示すユーザ要求の処理が行われる際に用いられるトランザクションデータのデータ構造の一例を示す図である。 図１３Ｃは、図１２に示すユーザ要求の処理が行われる際に用いられるトランザクションデータのデータ構造の一例を示す図である。 図１４は、実施の形態におけるＩｏＴデバイスが故障を検知した際の故障検知処理を示すシーケンス図である。 図１５は、図１４に示す故障検知処理が行われる際に用いられるトランザクションデータのデータ構造の一例を示す図である。 図１６Ａは、実施の形態におけるスマートコントラクト部により管理される状態情報を示す図である。 図１６Ｂは、実施の形態におけるスマートコントラクト部により管理される状態情報を示す図である。 図１７は、実施の形態におけるＩｏＴデバイスの制御が不要な場合のユーザ要求の処理の別の例を示すシーケンス図である。 図１８は、図１７に示すユーザ要求の処理が行われる際に用いられるＮＧ通知のデータ構造の一例を示す図である。 図１９は、比較例における問題を模式的に示す図である。 図２０は、本開示における効果を模式的に示す図である。
　本開示の一形態に係る制御方法は、１以上のＩｏＴ（Internet of Things）デバイスと、前記１以上のＩｏＴデバイスとネットワークを介して通信可能な複数のサーバとを備えるシステムにおける、前記複数のサーバのうちの第１サーバによって実行される制御方法であって、前記１以上のＩｏＴデバイスのうちの一のＩｏＴデバイスが故障したことを示す故障情報と、前記一のＩｏＴデバイスが前記故障情報を取得したときの時刻情報とを含む第１のトランザクションデータを、前記一のＩｏＴデバイスから取得し、取得した前記第１のトランザクションデータを、前記複数のサーバのうちの前記第１サーバとは異なる複数の第２サーバに転送し、前記複数の第２サーバとともに、前記第１のトランザクションデータの正当性について合意するための第１のコンセンサスアルゴリズムを実行し、前記第１のコンセンサスアルゴリズムによって前記第１のトランザクションデータの正当性が検証された場合、前記第１のトランザクションデータを含むブロックを前記第１サーバの分散台帳に記録する。
　これによれば、分散台帳に、ＩｏＴデバイスが故障しているかどうかを示す情報を記録することができる。このため、ＩｏＴデバイスが現実に存在する地点とは異なる場所でＩｏＴデバイスの利用許可を得ようしたときに、ＩｏＴデバイスが故障しているかどうかを知ることができる。よって、故障しているＩｏＴデバイスの利用許可を得てしまうことを抑制できるので、故障しているＩｏＴデバイスまで実際に移動することを抑制でき、移動等の手間が余計にかかることもなく、移動に時間とエネルギーとを費やすことを抑制できる。このようにして、分散台帳を用いて、時間コストとエネルギーコストとをより低減することができる。
　ここで、例えば、前記システムは、さらに、前記複数のサーバと前記ネットワークを介して通信可能な端末でありユーザが使用する端末を備え、前記制御方法は、前記端末から、前記ユーザが前記一のＩｏＴデバイスを利用可能かどうか問い合わせるためのユーザ要求を受信した場合、前記一のＩｏＴデバイスが利用可能かどうかを示す状態情報を読み出し、読み出した前記状態情報から、前記一のＩｏＴデバイスが利用可能であることを判定した場合、前記端末に対して、所定の条件下での前記一のＩｏＴデバイスの利用を許可する旨を示す第１信号を送信する。
　これによれば、ＩｏＴデバイスが現実に存在する地点とは異なる場所でＩｏＴデバイスの利用許可を得ようしたとき、故障しているＩｏＴデバイスの利用許可を得ることができない。よって、故障しているＩｏＴデバイスの利用許可を得てしまうことを抑制できるので、故障しているＩｏＴデバイスまで実際に移動することを抑制でき、移動等の手間が余計にかかることもなく、移動に時間とエネルギーとを費やすことがなくなる。このようにして、分散台帳を用いて、時間コストとエネルギーコストとを低減することができる。
　また、例えば、前記制御方法は、読み出した前記状態情報から、前記一のＩｏＴデバイスが利用不可であることを判定した場合、前記端末に対して、前記一のＩｏＴデバイスの利用を許可しない旨を示す信号を送信する。
　これによれば、ＩｏＴデバイスが現実に存在する地点とは異なる場所でＩｏＴデバイスの利用許可を得ようしたとき、故障していないＩｏＴデバイスの利用許可を確実に得ることができる。
　また、例えば、前記制御方法は、さらに、前記端末から、前記一のＩｏＴデバイスの利用権を購入した旨を示す第２のトランザクションデータを取得した場合、取得した前記第２のトランザクションデータを、前記複数のサーバのうちの前記複数の第２サーバに転送し、前記複数の第２サーバとともに、前記第２のトランザクションデータの正当性について合意するための第２のコンセンサスアルゴリズムを実行し、前記第２のコンセンサスアルゴリズムによって前記第２のトランザクションデータの正当性が検証された場合、前記第２のトランザクションデータを含むブロックを前記第１サーバの分散台帳に記録する。
　これによれば、ＩｏＴデバイスの利用許可を得たこと、すなわちＩｏＴデバイスの利用権を購入したことを履歴として分散台帳に記録することができる。よって、ＩｏＴデバイスの利用権を購入したことが公開され、改ざん検知が可能になるので、ＩｏＴデバイスの利用権についての不正な取引を抑制することができる。
　また、例えば、前記状態情報は、さらに、前記一のＩｏＴデバイスの開閉状態を含み、前記制御方法は、さらに、前記端末から、前記利用権に基づく前記一のＩｏＴデバイスの開錠要求を示す第３のトランザクションデータを取得し、取得した前記第３のトランザクションデータを、前記複数の第２サーバに転送し、前記複数の第２サーバとともに、前記第３のトランザクションデータの正当性について合意するための第３のコンセンサスアルゴリズムを実行し、前記第３のコンセンサスアルゴリズムによって前記第３のトランザクションデータの正当性が検証された場合、前記第３のトランザクションデータを含むブロックを前記第１サーバの分散台帳に記録することで、前記状態情報に含まれる前記一のＩｏＴデバイスの開閉状態を変更する。
　これによれば、ＩｏＴデバイスの開施錠の履歴を、分散台帳に記録することができる。よって、ＩｏＴデバイスの開施錠の履歴が公開され、改ざん検知が可能になるので、ＩｏＴデバイスの不正な利用を抑制することができる。
　また、例えば、前記制御方法は、前記分散台帳に記録された前記第１のトランザクションデータを読み出し、読み出した前記第１のトランザクションデータに基づいて前記状態情報を生成して、前記第１サーバが有するメモリ上に書き出しており、前記端末から、前記ユーザ要求を受信した場合、前記メモリ上における前記状態情報を読み出す。
　これによれば、分散台帳に記録されている第１のトランザクションデータを検索せずに、第１サーバのオンメモリに書き出されている状態情報を読み出すことで、ＩｏＴデバイスが利用可能かどうかを判定できる。よって、分散台帳を検索して、状態情報を取得する時間とエネルギーとをより節約することができる。このようにして、分散台帳を用いて、時間コストとエネルギーコストとをより低減することができる。
　また、例えば、前記時刻情報は、前記故障情報を取得したときのタイムスタンプまたはシーケンス番号である。
　また、例えば、前記制御方法は、前記故障情報を取得した場合、前記分散台帳に格納されたスマートコントラクトを動作させることで、前記第１のトランザクションデータを取得する。
　これにより、分散台帳に格納されるスマートコントラクトを用いて、ＩｏＴデバイスの故障検知の結果を分散台帳に記録する仕組みを構築することができる。
　また、本開示の一形態に係る制御システムは、１以上のＩｏＴデバイスと、前記１以上のＩｏＴデバイスとネットワークを介して通信可能な複数のサーバとを備え、前記複数のサーバのうちの第１サーバは、前記１以上のＩｏＴデバイスのうちの一のＩｏＴデバイスが故障したことを示す故障情報と、前記一のＩｏＴデバイスが前記故障情報を取得したときの時刻情報とを含む第１のトランザクションデータを、前記一のＩｏＴデバイスから取得し、取得した前記第１のトランザクションデータを、前記複数のサーバのうちの前記第１サーバとは異なる複数の第２サーバに転送し、前記複数の第２サーバとともに、前記第１のトランザクションデータの正当性について合意するための第１のコンセンサスアルゴリズムを実行し、前記第１のコンセンサスアルゴリズムによって前記第１のトランザクションデータの正当性が検証された場合、前記第１のトランザクションデータを含むブロックを前記第１サーバの分散台帳に記録する。
　また、本開示の一形態に係る第１サーバは、１以上のＩｏＴデバイスと、前記１以上のＩｏＴデバイスとネットワークを介して通信可能な複数のサーバとを備えるシステムにおける、前記複数のサーバのうちの第１サーバであって、プロセッサと、前記プロセッサに処理を実行させるプログラムが記憶されたメモリと、スマートコントラクトが格納された分散台帳が記憶されている記憶装置とを備え、前記プロセッサは、前記分散台帳に格納されたスマートコントラクトを動作させることで、前記１以上のＩｏＴデバイスのうちの一のＩｏＴデバイスが故障したことを示す故障情報と、前記一のＩｏＴデバイスが前記故障情報を取得したときの時刻情報とを含む第１のトランザクションデータを、前記一のＩｏＴデバイスから取得し、前記プロセッサは、前記メモリに記憶された前記プログラムを実行することにより、取得した前記第１のトランザクションデータを、前記複数のサーバのうちの前記第１サーバとは異なる複数の第２サーバに転送し、前記複数の第２サーバとともに、前記第１のトランザクションデータの正当性について合意するための第１のコンセンサスアルゴリズムを実行し、前記第１のコンセンサスアルゴリズムによって前記第１のトランザクションデータの正当性が検証された場合、前記第１のトランザクションデータを含むブロックを前記第１サーバの分散台帳に記録する。
　また、本開示の一形態に係るデータ構造は、１以上のＩｏＴデバイスと、前記１以上のＩｏＴデバイスとネットワークを介して通信可能な複数のサーバとを備えるシステムにおいて分散台帳に記録されるブロックに用いられるデータ構造であって、前記データ構造は、前記１以上のＩｏＴデバイスのうちの一のＩｏＴデバイスが故障したことを示す故障情報と、前記一のＩｏＴデバイスが前記故障情報を取得したときの時刻情報とを含む第１のトランザクションデータを含み、前記第１のトランザクションデータは、前記分散台帳に格納されたスマートコントラクトが動作されることで前記複数のサーバのうちの第１サーバによって取得され、取得された前記第１のトランザクションデータが前記ブロックに含まれて前記分散台帳に記録される。
　以下、図面を参照しながら、実施の形態について説明する。なお、以下で説明する実施の形態は、いずれも本開示の好ましい一具体例を示す。つまり、以下の実施の形態で示される数値、形状、材料、構成要素、構成要素の配置及び接続形態、ステップ、ステップの順序などは、一例であり、本開示を限定する主旨ではない。本開示は、請求の範囲の記載に基づいて特定される。したがって、以下の実施の形態における構成要素のうち、本開示の最上位概念を示す独立請求項に記載されていない構成要素は、本開示の課題を達成するために必ずしも必要ではないが、より好ましい形態を構成する構成要素として説明される。
　（実施の形態）
　以下では、図面を参照しながら、実施の形態における制御システム１について説明する。
　［制御システム１の構成］
　本開示の制御システム１は、分散台帳に格納されるスマートコントラクトを用いて、ＩｏＴデバイスの故障検知の結果を分散台帳に記録するなど、ブロックチェーン技術を活用してＩｏＴデバイスが故障しているかどうかも記録できる仕組みを有する。
　図１は、本実施の形態における制御システム１の構成を模式的に示すブロック図である。
　制御システム１は、図１に示されるように、サーバ１０Ａ、１０Ｂ、・・・、１０Ｅと、端末２１と、１以上のＩｏＴデバイス３０とを備える。これらはネットワークＮを介して接続されている。なお、サーバ１０Ａ、１０Ｂ、・・・、１０Ｅを「サーバ１０Ａ等」ともいい、サーバ１０Ａ等のそれぞれを「サーバ１０」ともいう。また、図１では、制御システム１が、５つサーバ１０を備える場合の例が示されているが、これに限らない。すなわち、制御システム１は、６つ以上のサーバ１０を備えてもよい。
　［サーバ１０Ａ］
　サーバ１０Ａ、１０Ｂ、・・・、１０Ｅは同様の構成であるため、以下では、サーバ１０Ａを例に挙げて説明する。
　図２は、図１に示すサーバ１０Ａの全体構成の一例を模式的に示す図である。図３は、本実施の形態に係るサーバ１０Ａの機能構成を示すブロック図である。
　サーバ１０Ａは、図２に示すように、記憶装置１２Ａと接続する。なお、サーバ１０Ａは、記憶装置１２ＡとネットワークＮを介して接続されていてもよいし、内部に記憶装置１２Ａを備えるとしてもよい。記憶装置１２Ａは、後述するスマートコントラクト部１４Ａが記憶された分散台帳１３Ａを有する。
　サーバ１０Ａは、第１サーバの一例である。本実施の形態では、サーバ１０Ａは、図３に示すように、スマートコントラクト実行部１１１、トランザクションデータ検証部１１２、ブロック生成部１１４、同期部１１５、記録部１１６、及び通信部１１７を備える。サーバ１０Ａは、プロセッサがメモリを用いて所定のプログラムを実行することで実現され得る。以下、各構成要素について説明する。
　＜スマートコントラクト実行部１１１＞
　スマートコントラクト実行部１１１は、分散台帳１３Ａに格納されているコントラクトコードなどを実行することで、スマートコントラクト部１４Ａを動作させる。スマートコントラクト実行部１１１は、スマートコントラクト部１４Ａを動作させることで、ＩｏＴデバイス３０の利用権の売買、開錠及び施錠などを分散台帳１３Ａによって管理することができる。
　本実施の形態では、スマートコントラクト実行部１１１は、スマートコントラクト部１４Ａを実行させる。例えば、スマートコントラクト実行部１１１は、スマートコントラクト部１４Ａに、一のＩｏＴデバイス３０が故障したことを示す故障情報と一のＩｏＴデバイス３０が故障情報を取得したときの時刻情報とを含む第１のトランザクションデータを、取得させる。つまり、スマートコントラクト実行部１１１は、分散台帳１３Ａに格納されたスマートコントラクトを動作させることで、第１のトランザクションデータを取得する。ここで、時刻情報は、当該故障情報を取得したときのタイムスタンプであってもよいし、シーケンス番号であってもよい。
　また、スマートコントラクト実行部１１１は、スマートコントラクト部１４Ａを動作させた結果、得られる情報をサーバ１０Ａのオンメモリに保持させてもよい。換言すると、スマートコントラクト実行部１１１は、スマートコントラクト部１４Ａを動作させた結果、分散台帳１３Ａに記録された情報を読み出して、サーバ１０Ａが有するメモリ（オンメモリ）に書き出して保持させてもよい。
　なお、スマートコントラクト実行部１１１は、分散台帳１３Ａに記録された第１のトランザクションデータを読み出し、読み出した第１のトランザクションデータに基づいてＩｏＴデバイス３０が利用可能かどうかを示す状態情報を生成してもよい。そして、スマートコントラクト実行部１１１は、生成した状態情報を第１サーバが有するメモリ上に書き出してもよい。スマートコントラクト実行部１１１は、ＩｏＴデバイス３０の利用権の有無、ＩｏＴデバイス３０の鍵の開閉状態を示す情報も同様に、オンメモリに書き出して保持させてもよい。
　＜トランザクションデータ検証部１１２＞
　トランザクションデータ検証部１１２は、トランザクションデータを受け取った場合、受け取ったトランザクションデータの正当性を検証する。
　本実施の形態では、トランザクションデータ検証部１１２は、少なくとも一のＩｏＴデバイス３０が故障したことを示す故障情報と一のＩｏＴデバイス３０が故障情報を取得したときの時刻情報とを含む第１のトランザクションデータをスマートコントラクト実行部１１１から受け取る。すると、トランザクションデータ検証部１１２は、受け取った第１のトランザクションデータに含まれる電子署名の検証を行い、第１のトランザクションデータの正当性の検証を行う。また、トランザクションデータ検証部１１２は、一のＩｏＴデバイス３０の利用権を購入した旨を示す第２のトランザクションデータを受け取った場合、第２のトランザクションデータに含まれる電子署名の検証を行い、第２のトランザクションデータの正当性の検証を行う。同様に、トランザクションデータ検証部１１２は、一のＩｏＴデバイス３０の鍵の開錠要求を示す第３のトランザクションデータを受け取った場合、第３のトランザクションデータに含まれる電子署名の検証を行い、第３のトランザクションデータの正当性の検証を行う。
　このように、トランザクションデータ検証部１１２は、取得したトランザクションデータを検証する。そして、トランザクションデータ検証部１１２は、検証した結果、トランザクションデータの正当性を確認した場合、そのトランザクションデータを記録部１１６に記録するとともに、同期部１１５へ通知する。
　なお、トランザクションデータ検証部１１２は、トランザクションデータがトランザクションデータ生成部１１３により生成される場合には、トランザクションデータの正当性の検証を行わなくてもよい。
　＜ブロック生成部１１４＞
　ブロック生成部１１４は、第１のサーバと異なる他の第２のサーバ（サーバ１０Ｂ～１０Ｅ）とともに、トランザクションデータの正当性について合意するためのコンセンサスアルゴリズムを実行する。
　ここでのコンセンサスアルゴリズムは、第１のコンセンサスアルゴリズム～第３のコンセンサスアルゴリズムに対応する。つまり、第１のコンセンサスアルゴリズム～第３のコンセンサスアルゴリズムは同一のコンセンサスアルゴリズムであり別タイミングで実施されたことを示すに過ぎない。また、ここでのトランザクションデータは、第１のトランザクションデータ～第３のトランザクションデータに対応する。
　このように、ブロック生成部１１４は、複数の認証サーバの間でコンセンサスアルゴリズムを実行する。コンセンサスアルゴリズムには、ＰＢＦＴ（Ｐｒａｃｔｉｃａｌ　Ｂｙｚａｎｔｉｎｅ　Ｆａｕｌｔ　Ｔｏｌｅｒａｎｃｅ）とよばれるコンセンサスアルゴリズムを用いてもよいし、その他の公知のコンセンサスアルゴリズムを用いてもよい。公知のコンセンサスアルゴリズムとしては、例えばＰＯＷ（Ｐｒｏｏｆ　Ｏｆ　Ｗｏｒｋ）またはＰＯＳ（Ｐｒｏｏｆ　Ｏｆ　Ｓｔａｋｅ）などがある。なお、ＰＢＦＴを用いる場合、ブロック生成部１１４は、まず、他の認証サーバ２００ｂ、２００ｃのそれぞれからトランザクションの検証が成功したか否かを示す報告を受け取り、当該報告の数が所定の数を超えたか否かを判定する。そして、ブロック生成部１１４は、当該報告の数が所定の数を超えたとき、コンセンサスアルゴリズムによってトランザクションデータの正当性が検証された場合であると判定すればよい。
　また、ブロック生成部１１４は、コンセンサスアルゴリズムによってトランザクションデータの正当性が検証された場合、トランザクションデータを含むブロックを、サーバ１０Ａの記憶装置１２Ａの分散台帳に記録する。
　このように、本実施の形態では、ブロック生成部１１４は、サーバ１０Ａ～サーバ１０Ｅの間でコンセンサスアルゴリズムを実行する。より具体的には、ブロック生成部１１４は、まず、１以上のトランザクションデータを含むブロックチェーンのブロックを生成する。次に、ブロック生成部１１４は、コンセンサスアルゴリズムを実行する。そして、ブロック生成部１１４は、コンセンサスアルゴリズムを実行することで合意形成ができた場合、生成したブロックを記録部１１６に記録する。ブロック生成部１１４により生成されたブロックは、記録部１１６により、分散台帳１３Ａに格納されているブロックチェーンに接続されて記録される。
　ここで、ブロックチェーンのデータ構造と、トランザクションデータのデータ構造とについて説明する。
　図４は、ブロックチェーンのデータ構造を示す説明図である。
　ブロックチェーンは、その記録単位であるブロックがチェーン（鎖）状に接続されたものである。それぞれのブロックは、複数のトランザクションデータと、直前のブロックのハッシュ値とを有している。具体的には、ブロックＢ２には、その前のブロックＢ１のハッシュ値が含まれている。そして、ブロックＢ２に含まれる複数のトランザクションデータと、ブロックＢ１のハッシュ値とから演算されたハッシュ値が、ブロックＢ２のハッシュ値として、ブロックＢ３に含められる。このように、前のブロックの内容をハッシュ値として含めながら、ブロックをチェーン状に接続することで、接続されたトランザクションデータの改ざんを有効に防止する。
　仮に過去のトランザクションデータが変更されると、ブロックのハッシュ値が変更前と異なる値になり、改ざんしたブロックを正しいものとみせかけるには、それ以降のブロックすべてを作り直さなければならず、この作業は現実的には非常に困難である。
　図５は、トランザクションデータのデータ構造を示す説明図である。
　図５に示されるトランザクションデータＤ１は、第１のトランザクションデータ～第３のトランザクションデータの一例である。トランザクションデータＤ１は、ユーザＡなどの要求者を示すＰ１と、スマートコントラクトアドレス、関数名、引数を示すアドレスＰ２と、アドレスＰ１及びＰ２のハッシュ値に対して、要求者の署名鍵で署名することで生成される電子署名Ｐ３とを含んでいる。なお、スマートコントラクトアドレス、関数名、引数は、例えばＪＳＯＮ形式で記述されるが、これに限らない。スマートコントラクトアドレスは、契約のためのプログラムであるスマートコントラクトのアドレスである。
　＜同期部１１５＞
　同期部１１５は、複数のサーバ（サーバ１０Ａ～サーバ１０Ｅ）の間でブロックチェーンのブロック、または、トランザクションデータの同期を行う。
　本実施の形態では、同期部１１５は、第１～第３のトランザクションデータの検証が成功した場合、他の複数のサーバ（サーバ１０Ｂ～サーバ１０Ｅ）に第１～第３のトランザクションデータの複製を転送する。
　複数のサーバ（サーバ１０Ａ～１０Ｅ）では、ｐｅｅｒ　ｔｏ　ｐｅｅｒでブロックチェーンのトランザクションデータの同期が行われる。そして、同期部１１５は、同期が行われたブロックチェーンのトランザクションデータを記録部１１６に記録する。
　例えば、同期部１１５は、第１のトランザクションデータの正当性が検証されると、他の複数のサーバ（サーバ１０Ｂ～１０Ｅ）に第１のトランザクションデータ内容を転送する。また、同期部１１５は、検証された第１のトランザクションデータを記録部１１６に記録する。
　また、例えば、同期部１１５は、他のサーバ（サーバ１０Ｂ～１０Ｅのいずれか）から第１のトランザクションデータを受信した場合、第１のトランザクションデータを記録部１１６に記録する。なお、第２及び第３のトランザクションデータも同様のため説明を省略する。
　＜記録部１１６＞
　記録部１１６は、トランザクションデータをブロックに含めて、記憶装置１２Ａの分散台帳１３Ａに記録する。本実施の形態では、記録部１１６は、第１のコンセンサスアルゴリズムによって第１のトランザクションデータの正当性が検証された場合、第１のトランザクションデータを含むブロックをサーバ１０Ａの分散台帳１３Ａに記録する。なお、第２及び第３のトランザクションデータも同様のため説明を省略する。
　＜通信部１１７＞
　通信部１１７は、端末２１、ＩｏＴデバイス３０、及び、他の複数のサーバ１０（サーバ１０Ｂ～１０Ｅ）との通信を行う。より具体的には、通信部１１７は、端末２１、ＩｏＴデバイス３０、及び、他の複数のサーバ１０（サーバ１０Ｂ～１０Ｅ）との通信を行う通信インタフェースである。端末２１、ＩｏＴデバイス３０、及び、他の複数のサーバ１０（サーバ１０Ｂ～１０Ｅ）との通信は、ＴＬＳによりなされてもよい。この場合、ＴＬＳ通信用の暗号鍵は通信部１１７で保持してもよい。
　［記憶装置１２Ａの構成］
　記憶装置１２Ａは、ＩｏＴデバイス３０の利用権の売買、開錠及び施錠を管理するための分散台帳１３Ａを有している。記憶装置１２Ａは、ＨＤＤ（Ｈａｒｄ　Ｄｉｓｋ　Ｄｒｉｖｅ）又はＳＳＤ（Ｓｏｌｉｄ　Ｓｔａｔｅ　Ｄｒｉｖｅ）などにより実現される。
　分散台帳１３Ａは、ブロックチェーンのトランザクションデータ及びブロックが電子的に記録される。また、分散台帳１３Ａは、プログラムであるスマートコントラクト部１４Ａが格納されている。記憶装置１２Ａは、例えばコントラクトコードと呼ばれるプログラムコードを記憶しており、このコントラクトコードを実行することで、スマートコントラクト部１４Ａを実行させることができるとしてもよい。
　［スマートコントラクト部１４Ａの構成］
　図６は、本実施の形態におけるスマートコントラクト部１４Ａの機能構成を示すブロック図である。
　スマートコントラクト部１４Ａは、図６に示されるように、デバイス利用権管理部１４１と、サービス提供部１４２と、故障登録部１４５とで構成される。
　＜デバイス利用権管理部１４１＞
　デバイス利用権管理部１４１は、ＩｏＴデバイス３０の利用権を管理する。本実施の形態では、デバイス利用権管理部１４１は、端末２１から、対象のＩｏＴデバイス３０が利用可能かの問い合わせをユーザ要求として受信すると、分散台帳１３Ａに記録されている、対象のＩｏＴデバイス３０の利用権の最新状況を確認する。デバイス利用権管理部１４１は、問い合わせの内容に応じて、対象のＩｏＴデバイス３０の利用権の購入が可能な状態かどうか、または、対象のＩｏＴデバイス３０の利用権が端末２１のユーザＡに購入されている状態であるかを確認し、サービス提供部１４２に通知する。
　＜サービス提供部１４２＞
　サービス提供部１４２は、利用可否判断部１４３と、台帳イベント発行部１４４と、で構成されている。
　利用可否判断部１４３は、対象のＩｏＴデバイス３０の利用権のあるユーザＡからの要求であるかどうか、及び、対象のＩｏＴデバイス３０がサービス提供可能であるかどうかを判断する。
　より具体的には、利用可否判断部１４３は、ユーザＡが一のＩｏＴデバイス３０を利用可能かどうか問い合わせるためのユーザ要求を端末２１から受信した場合、当該一のＩｏＴデバイス３０が利用可能かどうかを示す状態情報を読み出す。ここで、状態情報がオンメモリすなわちサーバ１０Ａのメモリに保持されていてもよい。この場合、利用可否判断部１４３は、当該ユーザ要求を端末２１から受信した場合、サーバ１０Ａのメモリにおける状態情報を読み出せばよい。
　利用可否判断部１４３は、読み出した状態情報から、当該一のＩｏＴデバイス３０が利用可能であることを判定した場合、端末２１に対して、所定の条件下での当該一のＩｏＴデバイス３０の利用を許可する旨を示す第１信号を送信する。一方、利用可否判断部１４３は、読み出した状態情報から、当該一のＩｏＴデバイス３０が利用不可であることを判定した場合、端末２１に対して、当該一のＩｏＴデバイスの利用を許可しない旨を示す信号を送信する。
　本実施の形態では、利用可否判断部１４３は、ユーザ要求を受信すると、分散台帳１３Ａに記録されている第１のトランザクションデータから取得できるまたはオンメモリ上にある状態情報を読み出して、対象のＩｏＴデバイス３０が故障状態であるか否かを確認する。
　また、利用可否判断部１４３は、デバイス利用権管理部１４１から通知された利用権の最新状況と、対象のＩｏＴデバイス３０が故障状態であるか否かとから、対象のＩｏＴデバイス３０が利用可能かどうかを判断する。
　利用可否判断部１４３は、対象のＩｏＴデバイス３０が利用可能であると判断すると、端末２１に対して、ＯＫ通知を送信する。ＯＫ通知は、ユーザ要求の内容に応じて、対象のＩｏＴデバイス３０が利用可能であり利用権を購入可能であること、または、対象のＩｏＴデバイス３０の利用権を端末２１のユーザＡが購入済であり、当該ＩｏＴデバイス３０が利用可能であることを示す。
　一方、利用可否判断部１４３は、対象のＩｏＴデバイス３０が利用可能でないと判断すると、端末２１に対して、ＮＧ通知を示す信号を送信する。ＮＧ通知は、ユーザ要求の内容に応じて、対象のＩｏＴデバイス３０の利用権が他者により購入済で利用不可であること、または、対象のＩｏＴデバイス３０が故障しており、利用不可であることを示す。
　台帳イベント発行部１４４は、サービス提供に必要な台帳イベントを発行する。本実施の形態では、台帳イベント発行部１４４は、端末２１から、ＩｏＴデバイス３０の鍵の開閉要求のトランザクションデータを受け取る（取得する）と、分散台帳１３Ａに記録されているＩｏＴデバイス３０の鍵の開閉状態を変更する。より具体的には、台帳イベント発行部１４４は、当該開閉要求のトランザクションデータを受け取ると、サーバ１０Ａに送信する。すると、サーバ１０Ａは、当該開閉要求のトランザクションを有するブロックをコンセンサスアルゴリズムで同期した後に、当該ブロックを分散台帳１３Ａに記録することで、分散台帳１０Ａ上での状態変更を発生させる。ここで、当該開閉要求のトランザクションデータは、例えば図５に示すＰ２において、コントラクトアドレスと鍵の開閉処理用の関数と引数とがＪＳＯＮ形式で設定されている。
　また、本実施の形態では、台帳イベント発行部１４４は、例えばオンメモリ上に保持されている対象のＩｏＴデバイス３０の鍵の開閉状態を変更させる。例えば、台帳イベント発行部１４４は、オンメモリ上に保持されている対象のＩｏＴデバイス３０の鍵の開閉状態を施錠状態から開錠状態に変更させる。
　なお、台帳イベント発行部１４４は、対象のＩｏＴデバイス３０から、鍵の開閉状態を変更させた旨を示すトランザクションデータを受け取る場合、当該トランザクションデータを分散台帳１３Ａに記録させてもよい。
　また、台帳イベント発行部１４４は、対象のＩｏＴデバイス３０の利用権をユーザＡが購入した旨を示すトランザクションデータを端末２１から受け取る場合、当該トランザクションデータを分散台帳１３Ａに記録させてもよい。
　＜故障登録部１４５＞
　故障登録部１４５は、ＩｏＴデバイス３０自身からの故障通知であることを確認し、サービスを提供不可状態にする。
　本実施の形態では、故障登録部１４５は、一のＩｏＴデバイス３０が故障したことを検知した旨の故障通知を取得すると、当該ＩｏＴデバイス３０そのものからの故障通知であるかどうかを電子署名等により確認する。故障登録部１４５は、ＩｏＴデバイス３０そのものからの故障通知であることを確認すると、オンメモリ上の当該ＩｏＴデバイス３０の状態情報を、正常から故障を示す情報に変更する。
　なお、故障登録部１４５は、一のＩｏＴデバイス３０が故障したことを示す故障情報と、当該一のＩｏＴデバイス３０が検知情報または故障情報を取得したときの時刻情報とを含む第１のトランザクションデータを、一のＩｏＴデバイス３０から受け取るとしてもよい。。この場合、故障登録部１４５は、受け取った第１のトランザクションデータをサーバ１０Ａに送信し、サーバ１０Ａに分散台帳１３Ａに記録させる。このようにして、故障登録部１４５は、一のＩｏＴデバイス３０が故障したことを分散台帳１３Ａに登録できる。
　［ＩｏＴデバイス３０］
　ＩｏＴデバイス３０は、例えば宅配ボックス、シェアリングカー、シェアリングバイク、ホテルの部屋などである。ＩｏＴデバイス３０は、これらに限られず、ユーザＡが利用許可を得ようとする地点と、現実に利用する地点とが離れているデバイスであれば該当し得る。また、ＩｏＴデバイス３０は、利用を許可された者すなわち開施錠をすることができる権限（利用権）を有する者のみが用いることができる。開施錠をすることができる権限（利用権）を有する者は、例えば１人であるが、１人に限られない。
　例えば図１に示すように、ＩｏＴデバイス３０が宅配ボックスの場合には、それぞれ物品５を格納できる１以上のユニット３１を備える。ユニット３１は、物品５の一時的な格納場所であり、ユーザＡが他のユーザに物品５を渡すために用いられる。
　なお、ＩｏＴデバイス３０の開錠又は施錠の制御は、サーバ１０Ａ等で動作するスマートコントラクトによりなされる。また、ＩｏＴデバイス３０は、自身を制御する機能以外に、自身が故障したことを検知する機能と、故障したことを示す故障情報をサーバ１０Ａに通知する機能とを有する。これらの機能すなわち自身を制御する機能と検知する機能と通知する機能とは、ＩｏＴデバイス３０に記録されたプログラム（以降ＩｏＴデバイス管理部３２と称する）によりなされる。
　［ＩｏＴデバイス管理部３２の構成］
　図７は、本実施の形態におけるＩｏＴデバイス管理部３２の機能構成を示すブロック図である。
　ＩｏＴデバイス管理部３２は、図７に示されるように、台帳イベント監視部３２１と、デバイス制御部３２２と、故障制御部３２３とで構成される。
　＜台帳イベント監視部３２１＞
　台帳イベント監視部３２１は、分散台帳１３Ａに記録されるイベントを監視し、スマートコントラクト部１４Ａが発行したイベントを取得する。このイベントには、トランザクションデータも含まれる。
　本実施の形態では、台帳イベント監視部３２１は、オンメモリ上に保持されているＩｏＴデバイス３０の鍵の開閉状態を監視している。台帳イベント監視部３２１は、オンメモリ上に保持されている一のＩｏＴデバイス３０の鍵の開閉状態が変更されると、当該一のＩｏＴデバイス３０の鍵の開閉状態を、スマートコントラクト部１４Ａが発行したイベント種別として取得する。また、台帳イベント監視部３２１は、取得したイベント種別に基づいて、当該一のＩｏＴデバイス３０の鍵を、変更された開閉状態となるようにデバイス制御部３２２に指示してもよい。
　なお、台帳イベント監視部３２１は、スマートコントラクト部１４Ａにより、分散台帳１３Ａを監視していてもよい。例えば、台帳イベント監視部３２１は、対象のＩｏＴデバイス３０の鍵の開閉状態を変更させたトランザクションデータが分散台帳１３Ａに記録された場合、そのことをスマートコントラクト部１４Ａが発行したイベント種別として取得してもよい。また、取得したイベント種別に基づいて、台帳イベント監視部３２１は、分散台帳１３Ａに記録された対象のＩｏＴデバイス３０の鍵の開閉状態となるようにデバイス制御部３２２に指示してもよい。
　＜デバイス制御部３２２＞
　デバイス制御部３２２は、台帳イベント監視部３２１が取得したイベント種別に基づき、ＩｏＴデバイス３０を制御する。
　本実施の形態では、デバイス制御部３２２は、オンメモリ上で変更された、または分散台帳１３Ａに新たに記録された対象のＩｏＴデバイス３０の鍵の開閉状態に基づき、対象のＩｏＴデバイス３０の鍵の開施錠を制御する。デバイス制御部３２２は、台帳イベント監視部３２１により指示された内容に基づき、対象のＩｏＴデバイス３０の鍵の開施錠を制御してもよい。
　なお、デバイス制御部３２２は、対象のＩｏＴデバイス３０の鍵の開施錠を制御した後、その旨を示すトランザクションデータを生成し、サーバ１０Ａに送信してもよい。この場合、当該トランザクションデータには、対象のＩｏＴデバイス３０の鍵が開錠された旨を示す開錠情報と当該開錠情報を取得したときの時刻情報とが含まれる。
　このようにして、デバイス制御部３２２は、例えばスマートコントラクト部１４Ａが対象のＩｏＴデバイスの利用権に基づく当該ＩｏＴデバイスの開錠要求を取得した場合、当該ＩｏＴデバイスの鍵を開錠する。
　＜故障制御部３２３＞
　故障制御部３２３は、故障検知部３２４と故障通知部３２５とで構成されている。
　故障検知部３２４は、ＩｏＴデバイス３０の故障を検知する。本実施の形態では、故障検知部３２４は、ＩｏＴデバイス３０の状態を常時または所定期間毎に確認することで、ＩｏＴデバイス３０の故障を検知する。
　故障通知部３２５は、分散台帳１３Ａに記録されたスマートコントラクト部１４Ａの故障登録部１４５を利用することで、ＩｏＴデバイス３０の故障を通知する。本実施の形態では、故障通知部３２５は、故障検知部３２４によりＩｏＴデバイス３０の故障が検知されると、第１のトランザクションデータを、スマートコントラクト部１４Ａの故障登録部１４５に送信する。第１のトランザクションデータは、上述したように、当該ＩｏＴデバイス３０が故障したことを示す故障情報と、当該ＩｏＴデバイスが故障情報を検知したときの時刻情報とを含む。なお、故障通知部３２５は、第１のトランザクションデータに、当該ＩｏＴデバイス３０を識別する番号等の識別情報と送信元を示す識別情報とを含めて、スマートコントラクト部１４Ａの故障登録部１４５に送信してもよい。
　［端末２１］
　端末２１は、複数のサーバ１０（サーバ１０Ａ、１０Ｂ、・・・、１０Ｅ）とネットワークＮを介して通信可能な端末であって、ユーザＡが使用する端末である。端末２１は、例えばスマートフォン、パーソナルコンピュータなどである。
　端末２１は、ＩｏＴデバイス３０を利用するための利用権の取得するための操作、または鍵の開錠又は施錠のための操作をユーザから受け、その操作に係る情報をユーザ要求としてサーバ１０Ａなどに送信する。図１では、端末２１は、ユーザＡにより使用され、他のユーザに物品５を渡すために宅配ボックスであるＩｏＴデバイス３０の一のユニット３１を利用しようとする場面が示されている。
　なお、端末２１では、ユーザＡより操作を受け付けたり、サーバ１０Ａにユーザ要求を送信するためにユーザＡの本人認証をしたりする機能は、端末２１に記録されたプログラム（以降、ユーザ要求処理部２２と称する）によりなされる。
　［ユーザ要求処理部２２の構成］
　図８は、本実施の形態におけるユーザ要求処理部２２の機能構成を示すブロック図である。
　ユーザ要求処理部２２は、図８に示されるように、ユーザ要求受付部２２１と、ユーザ認証部２２２と、トランザクションデータ処理部２２３とで構成される。
　＜ユーザ要求受付部２２１＞
　ユーザ要求受付部２２１は、ＩｏＴデバイス３０の開錠等のユーザ要求を受け付ける。
　本実施の形態では、ユーザ要求受付部２２１は、対象のＩｏＴデバイス３０が利用可能かどうかの問い合わせ、または、対象のＩｏＴデバイス３０の開錠要求を示すユーザ要求を受け付ける。なお、ユーザ要求は、これら以外に、対象のＩｏＴデバイス３０利用権をユーザＡが有するかの問い合わせであってもよい。
　＜ユーザ認証部２２２＞
　ユーザ認証部２２２は、ユーザ要求を発行しているユーザの本人認証を実施する。
　本実施の形態では、ユーザ認証部２２２は、ユーザ要求受付部２２１が受け付けたユーザ要求の正当性の検証のために、ユーザ要求を行ったユーザＡの本人認証を行う。
　＜トランザクションデータ処理部２２３＞
　トランザクションデータ処理部２２３は、利用可否問い合わせ部２２４と、トランザクションデータ生成部２２５とで構成されている。
　利用可否問い合わせ部２２４は、ユーザ要求に基づくトランザクションデータの受付が可能であるかの問い合わせを行う。本実施の形態では、利用可否問い合わせ部２２４は、対象のＩｏＴデバイス３０が利用可能かどうかの問い合わせ、対象のＩｏＴデバイス３０の開錠要求が受け付けられるかどうかの問い合わせを行う。なお、この問い合わせは、要求者を示す情報と、問い合わせ内容を示す情報と、問い合わせたいＩｏＴデバイス３０を識別する番号等の識別情報とを含むトランザクションデータが生成され、スマートコントラクト部１４Ａに送信されることで行われてもよい。
　トランザクションデータ生成部２２５は、ユーザ要求に基づくトランザクションデータを分散台帳１３Ａに発行する。なお、ユーザ要求に基づくトランザクションデータは、ユーザＡの秘密鍵で暗号化されており、この秘密鍵を用いることでユーザＡの本人認証を行うことができる。
　本実施の形態では、トランザクションデータ生成部２２５は、問い合わせを示すトランザクションデータを生成してもよい。また、トランザクションデータ生成部２２５は、一のＩｏＴデバイス３０の利用権を購入する旨を示すトランザクションデータを生成してもよい。また、トランザクションデータ生成部２２５は、対象のＩｏＴデバイス３０の開錠要求を示すユーザ要求として、対象のＩｏＴデバイス３０の開錠要求を示すトランザクションデータを生成してもよい。
　［本開示の制御方法］
　次に、制御システム１が行う制御方法の概要について説明する。
　図９は、本実施の形態における制御システム１が実行する制御方法を示すフローチャートである。
　図９に示されるように、まず、例えばサーバ１０Ａなどの制御システム１における第１サーバは、１以上のＩｏＴデバイス３０のうち少なくとも一のＩｏＴデバイス３０から第１のトランザクションデータを取得したかどうかを確認する（Ｓ１２）。ここで、第１のトランザクションデータには、少なくとも一のＩｏＴデバイスが故障したことを示す故障情報と、当該少なくとも一のＩｏＴデバイスが故障情報を取得したときの時刻情報とが含まれている。
　ステップＳ１２において、第１サーバは、少なくとも一のＩｏＴデバイス３０から第１のトランザクションデータを取得した場合（Ｓ１２でＹｅｓ）、取得した第１のトランザクションデータを、複数のサーバ１０のうちの第１サーバとは異なる複数の第２サーバに転送する（Ｓ１３）。
　次に、第１サーバは、複数の第２サーバとともに、第１のトランザクションデータの正当性について合意するための第１のコンセンサスアルゴリズムを実行する（Ｓ１４）。
　次に、第１サーバは、第１のコンセンサスアルゴリズムによって第１のトランザクションデータの正当性が検証された場合（Ｓ１５でｙｅｓ）、第１のトランザクションデータを含むブロックを第１サーバの分散台帳に記録する（Ｓ１６）。
　なお、第１サーバは、第１のコンセンサスアルゴリズムによって第１のトランザクションデータの正当性が検証されなかった場合（Ｓ１５でＮｏ）、処理を終了する。
　以下、制御システム１が行う制御方法の具体的態様について説明する。以下では、ＩｏＴデバイス３０が、宅配ボックスであり、ＩＤ０００１～ＩＤ０００３が付与された３つのユニット３１で構成されているとして説明する。
　［ＩｏＴデバイス３０の制御が不要なユーザ要求処理］
　図１０は、本実施の形態におけるＩｏＴデバイス３０の制御が不要な場合のユーザ要求の処理を示すシーケンス図である。図１１Ａ及び図１１Ｃは、図１０に示すユーザ要求の処理が行われる際に用いられるトランザクションデータのデータ構造の一例を示す図である。図１１Ｂは、図１０に示すユーザ要求の処理が行われる際に用いられるＯＫ通知のデータ構造の一例を示す図である。図１０に示す例では、対象（つまり利用対象）のＩｏＴデバイス３０は故障しておらず、対象のＩｏＴデバイス３０の利用権も購入できる状態であるとして説明する。
　図１０に示されるように、まず、ユーザＡは、例えばＩｏＴデバイス３０のＩＤ０００２のユニット３１の利用許可を得たい旨のユーザ要求を端末２１に行う。すると、端末２１のユーザ要求処理部２２は、ユーザ要求を受け付けて、ユーザ要求を発行したユーザＡが本人であるかを認証するユーザ認証処理を実施する（Ｓ１０１）。
　次に、ユーザ要求処理部２２は、ステップＳ１０１においてユーザＡのユーザ認証が成功すると、ＩＤ０００２のユニット３１が利用可能かどうかの問い合わせを分散台帳１３Ａに発行する（Ｓ１０２）。本実施の形態では、ユーザ要求処理部２２は、図１１Ａに示すようなデータ構造で構成されるトランザクションデータを分散台帳１３Ａに発行することで、スマートコントラクト部１４Ａを動作させる。図１１Ａには、要求者がユーザＡであることを示すｕｓｒＡと、ＩＤ０００２のユニット３１の識別情報を示す０００２と、ＩＤ０００２のユニット３１の利用可能かどうかの問い合わせを示すｑｕｅｒｙ＿ｒｅｓｅｒｖｅとを含むデータ構造で構成されるトランザクションデータが示されている。なお、図１１Ａでは、ＩＤ０００２のユニット３１の利用可能かどうかの問い合わせとして、ＩＤ０００２のユニット３１の利用権が購入済かどうかを問い合わせている。
　次に、スマートコントラクト部１４Ａは、分散台帳１３Ａの最新状態を確認することで、ＩＤ０００２のユニット３１の利用権の状況と、サービスモードとを確認する（Ｓ１０３）。
　次に、スマートコントラクト部１４Ａは、確認したＩＤ０００２のユニット３１の利用権の状況とサービスモードとから、ＩＤ０００２のユニット３１がサービス提供可能であるかどうかを判断する（Ｓ１０４）。ここでは、スマートコントラクト部１４Ａは、ＩＤ０００２のユニット３１の利用権が購入できる状況であり、ＩＤ０００２のユニット３１が壊れていないので、ＩＤ０００２のユニット３１が利用可能であると判断する。
　次に、スマートコントラクト部１４Ａは、ＩＤ０００２のユニット３１が利用可能であると判断したので、ＯＫ通知を端末２１のユーザ要求処理部２２に送信する（Ｓ１０５）。本実施の形態では、スマートコントラクト部１４Ａは、図１１Ｂに示すようなデータ構造で構成されるＯＫ通知をユーザ要求処理部２２に送信する。図１１Ｂには、ＩＤ０００２のユニット３１の識別情報を示す０００２と、ＩＤ０００２のユニット３１が使われていないことを示すＮｏｔｕｓｅと、利用権を購入できる金額を示す１００円とを含むデータ構造で構成されるＯＫ通知のデータ構造が示されている。
　次に、ユーザ要求処理部２２は、ＩＤ０００２のユニット３１の利用権を購入する旨を示すトランザクションデータを分散台帳１３Ａに発行する（Ｓ１０６）。本実施の形態では、ユーザ要求処理部２２は、図１１Ｃに示すようなデータ構造で構成されるトランザクションデータを生成し、分散台帳１３Ａに送信することで、スマートコントラクト部１４Ａを動作させる。図１１Ｃには、要求者がユーザＡであることを示すｕｓｒＡと、ＩＤ０００２のユニット３１の識別情報を示す０００２と、ＩＤ０００２のユニット３１の予約すなわち利用権の購入する旨を示すｒｅｓｅｒｖｅとを含むデータ構造で構成されるトランザクションデータが示されている。
　次に、スマートコントラクト部１４Ａは、ＩＤ０００２のユニット３１の利用権をユーザＡが購入した旨を示すトランザクションデータを分散台帳１３Ａに発行するサービス処理を行う（Ｓ１０７）。本実施の形態では、スマートコントラクト部１４Ａは、ＩＤ０００２のユニット３１の利用権をユーザＡが購入した旨を示す第２のトランザクションデータをユーザ要求処理部２２から受け取ると、サーバ１０に送信して分散台帳１３Ａに記録させる。
　［ＩｏＴデバイス３０の制御が必要なユーザ要求処理］
　図１２は、本実施の形態におけるＩｏＴデバイス３０の制御が必要な場合のユーザ要求の処理を示すシーケンス図である。図１３Ａは、図１２に示すユーザ要求の処理が行われる際に用いられるＯＫ通知のデータ構造の一例を示す図である。図１３Ｂ及び図１３Ｃは、図１２に示すユーザ要求の処理が行われる際に用いられるトランザクションデータのデータ構造の一例を示す図である。図１２に示す例では、対象のＩｏＴデバイス３０は故障しておらず、対象のＩｏＴデバイス３０の利用権がユーザＡに購入された状態であるとして説明する。
　図１２に示されるように、まず、ユーザＡは、例えばＩｏＴデバイス３０のＩＤ０００２のユニット３１の鍵の開錠要求を示すユーザ要求を端末２１に行う。すると、端末２１のユーザ要求処理部２２は、当該ユーザ要求を受け付けて、ユーザ要求を発行したユーザＡが本人であるかを認証するユーザ認証処理を実施する（Ｓ２０１）。
　次に、ユーザ要求処理部２２は、ステップＳ２０１においてユーザＡのユーザ認証が成功すると、ＩＤ０００２のユニット３１が利用可能かどうかの問い合わせを分散台帳１３Ａに発行する（Ｓ２０２）。本実施の形態では、ユーザ要求処理部２２は、図１１Ａに示すようなデータ構造で構成されるトランザクションデータを分散台帳１３Ａに発行することで、スマートコントラクト部１４Ａを動作させる。
　次に、スマートコントラクト部１４Ａは、分散台帳１３Ａの最新状態を確認することで、ＩＤ０００２のユニット３１の利用権の状況と、サービスモードとを確認する（Ｓ２０３）。
　次に、スマートコントラクト部１４Ａは、確認したＩＤ０００２のユニット３１の利用権の状況と、サービスモードとから、ＩＤ０００２のユニット３１がサービス提供可能であるかどうかを判断する（Ｓ２０４）。ここでは、スマートコントラクト部１４Ａは、ＩＤ０００２のユニット３１の利用権がユーザに購入されている状況であり、ＩＤ０００２のユニット３１が壊れていないので、ＩＤ０００２のユニット３１が利用可能であると判断する。
　次に、スマートコントラクト部１４Ａは、ＩＤ０００２のユニット３１が利用可能であると判断したので、ＯＫ通知を端末２１のユーザ要求処理部２２に送信する（Ｓ２０５）。本実施の形態では、スマートコントラクト部１４Ａは、図１３Ａに示すようなデータ構造で構成されるＯＫ通知をユーザ要求処理部２２に送信する。図１３Ａには、ＩＤ０００２のユニット３１の識別情報を示す０００２と、ＩＤ０００２のユニット３１の利用権がユーザＡに購入されていることを示すｕｓｒＡと、利用権が購入された金額を示す１００円とを含むデータ構造で構成されるＯＫ通知のデータ構造が示されている。
　次に、ユーザ要求処理部２２は、ＩＤ０００２のユニット３１の鍵の開錠要求を示すトランザクションデータを分散台帳１３Ａに発行する（Ｓ２０６）。本実施の形態では、ユーザ要求処理部２２は、図１３Ｂに示すようなデータ構造で構成されるトランザクションデータを生成し、分散台帳１３Ａに送信することで、スマートコントラクト部１４Ａを動作させる。図１３Ｂには、要求者がユーザＡであることを示すｕｓｒＡと、ＩＤ０００２のユニット３１の識別情報を示す０００２と、ＩＤ０００２のユニット３１の鍵の開錠要求を示すｏｐｅｎとを含むデータ構造で構成されるトランザクションデータが示されている。
　次に、スマートコントラクト部１４Ａは、ユーザ要求処理部２２から、当該開錠要求を示すトランザクションデータを取得すると、オンメモリ上に保持されているＩＤ０００２のユニット３１の鍵の開閉状態を、ｏｐｅｎすなわち開錠状態に移行させるサービス処理を行う（Ｓ２０７）。また、スマートコントラクト部１４Ａは、分散台帳１３Ａに記録されているＩＤ０００２のユニット３１の鍵の開閉状態を変更する（Ｓ２０８）。より具体的には、スマートコントラクト部１４Ａは、当該開錠要求を示すトランザクションデータを、分散台帳１３Ａを有するサーバ１０Ａに送信する。すると、サーバ１０Ａは、当該開閉要求のトランザクションを有するブロックをコンセンサスアルゴリズムで同期した後に、当該ブロックを分散台帳１３Ａに記録することで、分散台帳１０Ａ上での状態変更を発生させる。
　次に、ＩｏＴデバイス管理部３２は、オンメモリ上に保持されているＩｏＴデバイス３０の鍵の開閉状態などの台帳イベントを監視しており、ＩＤ０００２のユニット３１の鍵の開閉状態が開錠状態に移行したことを取得する（Ｓ２０９）。
　次に、ＩｏＴデバイス管理部３２は、ＩＤ０００２のユニット３１の鍵を開錠する開錠制御を行い（Ｓ２１０）、ＩＤ０００２のユニット３１の鍵を開錠したことを示す第３のトランザクションデータを生成する（Ｓ２１１）。そして、ＩｏＴデバイス管理部３２は、生成した第３のトランザクションデータを分散台帳１３Ａに送信する。本実施の形態では、ＩｏＴデバイス管理部３２は、図１３Ｃに示すようなデータ構造で構成される第３のトランザクションデータを生成し、分散台帳１３Ａに送信する。図１３Ｃには、実施者がＩｏＴデバイス管理部３２であることを示すｄｅｖと、ＩＤ０００２のユニット３１の識別情報を示す０００２と、その鍵が開錠されたことを示すｒｅｇｉｓｔ＿ｏｐｅｎｅｄとを含むデータ構造で構成されるトランザクションデータが示されている。
　次に、スマートコントラクト部１４Ａは、当該第３のトランザクションデータを取得すると、当該第３のトランザクションデータを分散台帳１３Ａに記録させる（Ｓ２１２）。
　［ＩｏＴデバイス３０の故障検知処理］
　図１４は、本実施の形態におけるＩｏＴデバイス３０が故障を検知した際の故障検知処理を示すシーケンス図である。図１５は、図１４に示す故障検知処理が行われる際に用いられるトランザクションデータのデータ構造の一例を示す図である。以下では、対象のＩｏＴデバイス３０を構成する３つのユニット３１のうち、ＩＤ０００２が付与されたユニット３１が故障したとする。
　図１４に示されるように、ＩｏＴデバイス３０のＩｏＴデバイス管理部３２は、ＩｏＴデバイス３０の状態を常時または所定期間毎に確認しているので、ＩＤ０００２のユニット３１が故障したことを検知する（Ｓ３０１）。
　すると、ＩｏＴデバイス管理部３２は、ＩＤ０００２のユニット３１が故障したことを示すトランザクションデータを生成する（Ｓ３０２）。ＩｏＴデバイス管理部３２は、ステップＳ３０２で生成したトランザクションデータを、当該ＩｏＴデバイス３０のＩＤ０００２のユニット３１が故障したことを示す故障情報として、スマートコントラクト部１４Ａに送信する故障通知を行う（Ｓ３０３）。本実施の形態では、ＩｏＴデバイス管理部３２は、図１５に示すようなデータ構造で構成されるトランザクションデータを生成する。図１５には、検知者がＩｏＴデバイス管理部３２であることを示すｄｅｖと、ＩＤ０００２のユニット３１の識別情報を示す０００２と、ＩＤ０００２のユニット３１が利用不可であることを示すｄｉｓａｂｌｅｄとを含むデータ構造で構成されるトランザクションデータが示されている。そして、ＩｏＴデバイス管理部３２は、このように作成したトランザクションデータを分散台帳１３Ａに発行することで、スマートコントラクト部１４Ａを動作させる。
　次に、スマートコントラクト部１４Ａは、オンメモリ上に保持されているＩＤ０００２のユニット３１の状態情報を、正常から故障を示すように変更する故障登録を行う（Ｓ３０４）。本実施の形態では、スマートコントラクト部１４Ａは、ＩｏＴデバイス３０の状態情報を、サーバ１０Ａのオンメモリに書き出して保持することで管理している。
　図１６Ａ及び図１６Ｂは、実施の形態におけるスマートコントラクト部１４Ａにより管理される状態情報を示す図である。図１６Ａに示す状態情報は、ＩｏＴデバイス３０を構成する３つのユニット３１すべてが故障していない正常であることを示している。なお、図１６Ａにおいて、ＩＤ０００１のユニット３１の利用権はユーザＡにより購入済であることが示されている。ＩＤ０００２及びＩＤ０００３のユニット３１の利用権はサービス会社が所有しており、利用権の購入が可能すなわち利用可能であることが示されている。一方、図１６Ｂに示す状態情報は、ＩｏＴデバイス３０を構成する３つのユニット３１のうちＩＤ０００２のユニット３１が故障していることを示している。つまり、本実施の形態では、スマートコントラクト部１４Ａは、図１６Ａに示す状態情報を、図１６Ｂに示す状態情報に更新することで、故障登録を行う。
　なお、本実施の形態では、スマートコントラクト部１４Ａは、ＩＤ０００２のユニット３１が故障したことを示す故障情報と、ＩＤ０００２のユニット３１が当該故障情報を取得したときの時刻情報とを含む第１のトランザクションデータを取得する。このため、スマートコントラクト部１４Ａは、取得した第１のトランザクションデータを、分散台帳１３Ａに送信することで、第１のトランザクションデータを分散台帳１３Ａに記録させる。
　このようにして、スマートコントラクト部１４Ａは、図１６Ｂに示す状態情報を用いて、ＩＤ０００２のユニット３１を利用不可であるサービス停止状態として管理する（Ｓ３０５）。
　［ＩｏＴデバイス３０の制御が不要なユーザ要求処理の別の例］
　図１７は、本実施の形態におけるＩｏＴデバイス３０の制御が不要な場合のユーザ要求の処理の別の例を示すシーケンス図である。図１８は、図１７に示すユーザ要求の処理が行われる際に用いられるＮＧ通知のデータ構造の一例を示す図である。図１７に示す例では、対象のＩｏＴデバイス３０を構成する３つのユニット３１のすべての利用権は購入可能であるが、ＩＤ０００２が付与されたユニット３１が故障しているとして以下説明する。
　図１７に示されるように、まず、ユーザＡは、例えばＩｏＴデバイス３０のＩＤ０００２のユニット３１の利用許可を得たい旨のユーザ要求を端末２１に行う。すると、端末２１のユーザ要求処理部２２は、ユーザ要求を受け付けて、ユーザ要求を発行したユーザＡが本人であるかを認証するユーザ認証処理を実施する（Ｓ４０１）。
　次に、ユーザ要求処理部２２は、ステップＳ４０１においてユーザＡのユーザ認証が成功すると、ＩＤ０００２のユニット３１が利用可能かどうかの問い合わせを分散台帳１３Ａに発行する（Ｓ４０２）。本実施の形態では、ユーザ要求処理部２２は、図１１Ａに示すようなデータ構造で構成されるトランザクションデータを分散台帳１３Ａに発行することで、スマートコントラクト部１４Ａを動作させる。図１１Ａについては上述したのでここでの説明を省略する。
　次に、スマートコントラクト部１４Ａは、分散台帳１３Ａの最新状態を確認することで、ＩＤ０００２のユニット３１の利用権の状況と、サービスモードとを確認する（Ｓ４０３）。
　次に、スマートコントラクト部１４Ａは、確認したＩＤ０００２のユニット３１の利用権の状況とサービスモードとから、ＩＤ０００２のユニット３１がサービス提供可能であるかどうかを判断する（Ｓ４０４）。ここでは、スマートコントラクト部１４Ａは、ＩＤ０００２のユニット３１の利用権が購入できる状況であるもの、ＩＤ０００２のユニット３１が故障しており、ＩＤ０００２のユニット３１が利用不可であると判断する。
　次に、スマートコントラクト部１４Ａは、ＩＤ０００２のユニット３１が利用不可であると判断したので、ＮＧ通知を端末２１のユーザ要求処理部２２に送信する（Ｓ４０５）。本実施の形態では、スマートコントラクト部１４Ａは、図１８に示すようなデータ構造で構成されるＮＧ通知をユーザ要求処理部２２に送信する。図１８には、ＩＤ０００２のユニット３１の識別情報を示す０００２と、ＩＤ０００２のユニット３１が利用不可であることを示すｄｉｓａｂｌｅと、利用権を購入できる金額を示す１００円とを含むデータ構造で構成されるＮＧ通知のデータ構造が示されている。
　次に、ユーザ要求処理部２２は、ＮＧ通知を受信したので、ユーザＡに、ＮＧ通知を送信し（Ｓ４０６）、ユーザＡに対してＩＤ０００２のユニット３１の利用許可が得られない旨を通知する。
　このように、ユーザＡは、故障しているＩｏＴデバイス３０の利用許可を得ることができないので、故障しているＩｏＴデバイスまで実際に移動することを抑制でき、移動等の手間が余計にかかることもなく、移動に時間とエネルギーとを費やすことがなくなる。
　［効果等］
　以上のように、本開示の制御方法、制御システムによれば、分散台帳に、ＩｏＴデバイスが故障しているかどうかを示す情報を記録することができる。このため、ユーザＡは、ＩｏＴデバイスが現実に存在する地点とは異なる場所でＩｏＴデバイスの利用許可を得ようしたときに、故障しているＩｏＴデバイスの利用許可を得てしまうことが抑制される。これにより、ユーザＡは、故障しているＩｏＴデバイスまで実際に移動することを抑制できるので、移動等の手間が余計にかかることもなく、移動に時間とエネルギーとを費やすことを抑制できる。このようにして、分散台帳を用いて、時間コストとエネルギーコストとをより低減することができる。
　別の観点から見ると、本開示の制御方法、制御システム１では、スマートコントラクトを用いてＩｏＴデバイスが故障したことを通知するためのメソッドを有する。例えば、ＩｏＴデバイスは、自ら故障を検知すると、故障したことを通知するためのメソッドを利用して、自分が故障状態であることを通知する。ここで、故障したことを通知するためのメソッドを利用する際には、ＰＫＩ（署名）を用いるので、故障を検知したＩｏＴデバイスからの通知であることを保証することができる。
　これにより、故障状態であるＩｏＴデバイスのサービスが停止されるので、故障しているＩｏＴデバイスの利用許可を得ることができない。したがって、故障しているＩｏＴデバイスまで実際に移動することを抑制でき、移動等の手間が余計にかかることもなく、移動に時間とエネルギーとを費やすことがなくなる。
　ここで、図１９及び図２０を用いて、本開示の制御方法、制御システム１の効果について説明する。図１９は、比較例における問題を模式的に示す図である。図２０は、本開示における効果を模式的に示す図である。図１９及び図２０はいずれも、例えば宅配ボックスであるＩｏＴデバイス３０を構成する複数のユニット３１のうちの一のユニット３１が故障しているとして説明する。
　図１９に示すように、比較例では、配送業者５０は、利用対象である一のユニット３１が故障しているのを知らないので、当該一のユニット３１に荷物を配送する場合、当該一のユニット３１の利用権を購入するなどにより、当該一のユニット３１の利用を予約できる。このため、配送業者５０は、当該一のユニット３１の利用権を購入後、当該ユニットがある現地に移動することになる。しかし、当該一のユニット３１は故障しているので、配送業者５０は、現地に到着後、当該一のユニットを利用するために開錠しようとしても当該一のユニットは動作しない。
　よって、故障している当該一のユニット３１までの移動が無駄になり、移動等の手間が余計にかかるだけでなく移動に費やした時間とエネルギーとが無駄になる。
　一方、図２０に示すように、本開示では、配送業者５０は、当該一のユニット３１が故障しているのを知らなくても、当該一のユニット３１に荷物を配送するために当該一のユニット３１の利用を予約することができない。このため、配送業者５０は、故障しているＩｏＴデバイスまで実際に移動することを抑制でき、移動等の手間が余計にかかることもなく、移動に時間とエネルギーとを費やすことがなくなる。
　また、本開示の制御方法、制御システムでは、分散台帳を利用するので、どのタイミングでＩｏＴデバイスが故障したのか、ＩｏＴデバイスの利用のための取引がいつ発生したのかなど、すべての履歴を改ざんできない状態で管理できるという効果もある。
　また、本開示の制御方法、制御システムでは、取引条件のプログラムをスマートコントラクトとして分散台帳に格納することで、分散台帳に、ＩｏＴデバイスが故障しているかどうかを示す情報を記録することができる。このようにして、ＩｏＴデバイスが故障しているかどうかを示す情報をブロックチェーンで改ざんできない形で公開することができるので、不正な取引を抑制できる。
　さらに、本開示の制御方法、制御システムでは、ＩｏＴデバイスを利用するというサービスを開始後に、ＩｏＴデバイスが故障したとしても、ＩｏＴデバイスが故障したことを利用者に通知できるだけでなく、エビデンスとして分散台帳に記録することができる。これにより、ＩｏＴデバイスを利用する利用者及びＩｏＴデバイスを利用するというサービスを提供する提供者においても、迅速に対応できるので、被害を最小限にすることができる。
　なお、本開示を上記の実施の形態に基づいて説明してきたが、本開示は、上記の実施の形態に限定されないのはもちろんである。以下のような場合も本開示に含まれる。
　（１）例えば本開示には、上記実施の形態の制御システム１においてブロックチェーンとして記録されるブロックに用いられるデータ構造も含まれる。より具体的には、本開示のデータ構造は、１以上のＩｏＴデバイスと、１以上のＩｏＴデバイスとネットワークを介して通信可能な複数のサーバとを備えるシステムにおいて分散台帳に記録されるブロックに用いられるデータ構造である。当該データ構造は、１以上のＩｏＴデバイスのうちの一のＩｏＴデバイスが故障したことを示す故障情報と、当該一のＩｏＴデバイスが故障情報を取得したときの時刻情報とを含む第１のトランザクションデータを含む。そして、本開示のデータ構造に含まれる第１のトランザクションデータは、分散台帳に格納されたスマートコントラクトが動作されることで複数のサーバのうちの第１サーバによって取得され、取得された第１のトランザクションデータがブロックに含まれて分散台帳に記録される。
　（２）なお、本開示では、分散型の台帳管理を実現するブロックチェーン実装基盤としてブロックチェーンを挙げて説明しているが、これに限らない。Hyperledger fabricなど、他のブロックチェーン実装基盤を用いてもよい。
　（３）上記の実施の形態における各装置は、具体的には、マイクロプロセッサ、ＲＯＭ、ＲＡＭ、ハードディスクユニット、ディスプレイユニット、キーボード、マウスなどから構成されるコンピュータシステムである。前記ＲＡＭまたはハードディスクユニットには、コンピュータプログラムが記録されている。前記マイクロプロセッサが、前記コンピュータプログラムにしたがって動作することにより、各装置は、その機能を達成する。ここでコンピュータプログラムは、所定の機能を達成するために、コンピュータに対する指令を示す命令コードが複数個組み合わされて構成されたものである。
　（４）上記の実施の形態における各装置は、構成する構成要素の一部または全部は、１個のシステムＬＳＩ（Ｌａｒｇｅ　Ｓｃａｌｅ　Ｉｎｔｅｇｒａｔｉｏｎ：大規模集積回路）から構成されているとしてもよい。システムＬＳＩは、複数の構成部を１個のチップ上に集積して製造された超多機能ＬＳＩであり、具体的には、マイクロプロセッサ、ＲＯＭ、ＲＡＭなどを含んで構成されるコンピュータシステムである。前記ＲＡＭには、コンピュータプログラムが記録されている。前記マイクロプロセッサが、前記コンピュータプログラムにしたがって動作することにより、システムＬＳＩは、その機能を達成する。
　また、上記の各装置を構成する構成要素の各部は、個別に１チップ化されていても良いし、一部またはすべてを含むように１チップ化されてもよい。
　また、ここでは、システムＬＳＩとしたが、集積度の違いにより、ＩＣ、ＬＳＩ、スーパーＬＳＩ、ウルトラＬＳＩと呼称されることもある。また、集積回路化の手法はＬＳＩに限るものではなく、専用回路または汎用プロセッサで実現してもよい。ＬＳＩ製造後に、プログラムすることが可能なＦＰＧＡ（Ｆｉｅｌｄ　Ｐｒｏｇｒａｍｍａｂｌｅ　Ｇａｔｅ　Ａｒｒａｙ）や、ＬＳＩ内部の回路セルの接続や設定を再構成可能なリコンフィギュラブル・プロセッサを利用しても良い。
　さらには、半導体技術の進歩または派生する別技術によりＬＳＩに置き換わる集積回路化の技術が登場すれば、当然、その技術を用いて機能ブロックの集積化を行ってもよい。バイオ技術の適用等が可能性としてありえる。
　（５）上記の各装置を構成する構成要素の一部または全部は、各装置に脱着可能なＩＣカードまたは単体のモジュールから構成されているとしてもよい。前記ＩＣカードまたは前記モジュールは、マイクロプロセッサ、ＲＯＭ、ＲＡＭなどから構成されるコンピュータシステムである。前記ＩＣカードまたは前記モジュールは、上記の超多機能ＬＳＩを含むとしてもよい。マイクロプロセッサが、コンピュータプログラムにしたがって動作することにより、前記ＩＣカードまたは前記モジュールは、その機能を達成する。このＩＣカードまたはこのモジュールは、耐タンパ性を有するとしてもよい。
　（６）本開示は、上記に示す方法であるとしてもよい。また、これらの方法をコンピュータにより実現するコンピュータプログラムであるとしてもよいし、前記コンピュータプログラムからなるデジタル信号であるとしてもよい。
　また、本開示は、前記コンピュータプログラムまたは前記デジタル信号をコンピュータで読み取り可能な記録媒体、例えば、フレキシブルディスク、ハードディスク、ＣＤ－ＲＯＭ、ＭＯ、ＤＶＤ、ＤＶＤ－ＲＯＭ、ＤＶＤ－ＲＡＭ、ＢＤ（Ｂｌｕ－ｒａｙ（登録商標）Ｄｉｓｃ）、半導体メモリなどに記録したものとしてもよい。また、これらの記録媒体に記録されている前記デジタル信号であるとしてもよい。
　また、本開示は、前記コンピュータプログラムまたは前記デジタル信号を、電気通信回線、無線または有線通信回線、インターネットを代表とするネットワーク、データ放送等を経由して伝送するものとしてもよい。
　また、本開示は、マイクロプロセッサとメモリを備えたコンピュータシステムであって、前記メモリは、上記コンピュータプログラムを記録しており、前記マイクロプロセッサは、前記コンピュータプログラムにしたがって動作するとしてもよい。
　また、前記プログラムまたは前記デジタル信号を前記記録媒体に記録して移送することにより、または前記プログラムまたは前記デジタル信号を、前記ネットワーク等を経由して移送することにより、独立した他のコンピュータシステムにより実施するとしてもよい。
　（７）上記実施の形態及び上記変形例をそれぞれ組み合わせるとしてもよい。
　本開示は、制御方法、制御システム、第１サーバ、及び、データ構造に利用でき、例えば宅配ボックス、シェアリングカー、シェアリングバイク、ホテルの部屋などのＩｏＴデバイスの故障検知の結果を、分散台帳に格納されるスマートコントラクトを用いて分散台帳に記録する制御方法、制御システム、第１サーバ、及び、データ構造などに利用可能である。
　１　　制御システム
　５　　物品
　１０、１０Ａ、１０Ｂ、１０Ｃ、１０Ｄ、１０Ｅ　　サーバ
　１２Ａ　　記憶装置
　１３Ａ　　分散台帳
　１４Ａ　　スマートコントラクト部
　２１　　端末
　２２　　ユーザ要求処理部
　３０　　ＩｏＴデバイス
　３１　　ユニット
　３２　　ＩｏＴデバイス管理部
　１１１　　スマートコントラクト実行部
　１１２　　トランザクションデータ検証部
　１１４　　ブロック生成部
　１１５　　同期部
　１１６　　記録部
　１４１　　デバイス利用権管理部
　１４２　　サービス提供部
　１４３　　利用可否判断部
　１４４　台帳イベント発行部
　１４５　　故障登録部
　２２１　　ユーザ要求受付部
　２２２　　ユーザ認証部
　２２３　　トランザクションデータ処理部
　２２４　　利用可否問い合わせ部
　２２５　　トランザクションデータ生成部
　３２１　　台帳イベント監視部
　３２２　　デバイス制御部
　３２３　　故障制御部
　３２４　　故障検知部
　３２５　　故障通知部

Claims (11)

  1. 　１以上のＩｏＴ（Internet of Things）デバイスと、前記１以上のＩｏＴデバイスとネットワークを介して通信可能な複数のサーバとを備えるシステムにおける、前記複数のサーバのうちの第１サーバによって実行される制御方法であって、
    　前記１以上のＩｏＴデバイスのうちの一のＩｏＴデバイスが故障したことを示す故障情報と、前記一のＩｏＴデバイスが前記故障情報を取得したときの時刻情報とを含む第１のトランザクションデータを、前記一のＩｏＴデバイスから取得し、
    　取得した前記第１のトランザクションデータを、前記複数のサーバのうちの前記第１サーバとは異なる複数の第２サーバに転送し、
    　前記複数の第２サーバとともに、前記第１のトランザクションデータの正当性について合意するための第１のコンセンサスアルゴリズムを実行し、
    　前記第１のコンセンサスアルゴリズムによって前記第１のトランザクションデータの正当性が検証された場合、前記第１のトランザクションデータを含むブロックを前記第１サーバの分散台帳に記録する、
    　制御方法。
  2. 　前記システムは、さらに、前記複数のサーバと前記ネットワークを介して通信可能な端末でありユーザが使用する端末を備え、
    　前記制御方法は、
    　前記端末から、前記ユーザが前記一のＩｏＴデバイスを利用可能かどうか問い合わせるためのユーザ要求を受信した場合、前記一のＩｏＴデバイスが利用可能かどうかを示す状態情報を読み出し、
    　読み出した前記状態情報から、前記一のＩｏＴデバイスが利用可能であることを判定した場合、前記端末に対して、所定の条件下での前記一のＩｏＴデバイスの利用を許可する旨を示す第１信号を送信する、
    　請求項１に記載の制御方法。
  3. 　前記制御方法は、
    　読み出した前記状態情報から、前記一のＩｏＴデバイスが利用不可であることを判定した場合、前記端末に対して、前記一のＩｏＴデバイスの利用を許可しない旨を示す信号を送信する、
    　請求項２に記載の制御方法。
  4. 　前記制御方法は、さらに、
    　前記端末から、前記一のＩｏＴデバイスの利用権を購入した旨を示す第２のトランザクションデータを取得した場合、取得した前記第２のトランザクションデータを、前記複数のサーバのうちの前記複数の第２サーバに転送し、
    　前記複数の第２サーバとともに、前記第２のトランザクションデータの正当性について合意するための第２のコンセンサスアルゴリズムを実行し、
    　前記第２のコンセンサスアルゴリズムによって前記第２のトランザクションデータの正当性が検証された場合、前記第２のトランザクションデータを含むブロックを前記第１サーバの分散台帳に記録する、
    　請求項２に記載の制御方法。
  5. 　前記状態情報は、さらに、前記一のＩｏＴデバイスの開閉状態を含み、
    　前記制御方法は、さらに、
    　前記端末から、前記利用権に基づく前記一のＩｏＴデバイスの開錠要求を示す第３のトランザクションデータを取得し、
    　取得した前記第３のトランザクションデータを、前記複数の第２サーバに転送し、
    　前記複数の第２サーバとともに、前記第３のトランザクションデータの正当性について合意するための第３のコンセンサスアルゴリズムを実行し、
    　前記第３のコンセンサスアルゴリズムによって前記第３のトランザクションデータの正当性が検証された場合、前記第３のトランザクションデータを含むブロックを前記第１サーバの分散台帳に記録することで、前記状態情報に含まれる前記一のＩｏＴデバイスの開閉状態を変更する、
    　請求項４に記載の制御方法。
  6. 　前記制御方法は、
    　前記分散台帳に記録された前記第１のトランザクションデータを読み出し、
    　読み出した前記第１のトランザクションデータに基づいて前記状態情報を生成して、前記第１サーバが有するメモリ上に書き出しており、
    　前記端末から、前記ユーザ要求を受信した場合、前記メモリ上における前記状態情報を読み出す、
    　請求項２～５のいずれか１項に記載の制御方法。
  7. 　前記時刻情報は、前記故障情報を取得したときのタイムスタンプまたはシーケンス番号である、
    　請求項１～６のいずれか１項に記載の制御方法。
  8. 　前記制御方法は、
    　前記故障情報を取得した場合、前記分散台帳に格納されたスマートコントラクトを動作させることで、前記第１のトランザクションデータを取得する、
    　請求項１～７のいずれか１項に記載の制御方法。
  9. 　１以上のＩｏＴデバイスと、
    　前記１以上のＩｏＴデバイスとネットワークを介して通信可能な複数のサーバとを備え、
    　前記複数のサーバのうちの第１サーバは、
    　前記１以上のＩｏＴデバイスのうちの一のＩｏＴデバイスが故障したことを示す故障情報と、前記一のＩｏＴデバイスが前記故障情報を取得したときの時刻情報とを含む第１のトランザクションデータを、前記一のＩｏＴデバイスから取得し、
    　取得した前記第１のトランザクションデータを、前記複数のサーバのうちの前記第１サーバとは異なる複数の第２サーバに転送し、
    　前記複数の第２サーバとともに、前記第１のトランザクションデータの正当性について合意するための第１のコンセンサスアルゴリズムを実行し、
    　前記第１のコンセンサスアルゴリズムによって前記第１のトランザクションデータの正当性が検証された場合、前記第１のトランザクションデータを含むブロックを前記第１サーバの分散台帳に記録する、
    　制御システム。
  10. 　１以上のＩｏＴデバイスと、前記１以上のＩｏＴデバイスとネットワークを介して通信可能な複数のサーバとを備えるシステムにおける、前記複数のサーバのうちの第１サーバであって、
    　プロセッサと、
    　前記プロセッサに処理を実行させるプログラムが記憶されたメモリと、
    　スマートコントラクトが格納された分散台帳が記憶されている記憶装置とを備え、
    　前記プロセッサは、前記分散台帳に格納されたスマートコントラクトを動作させることで、前記１以上のＩｏＴデバイスのうちの一のＩｏＴデバイスが故障したことを示す故障情報と、前記一のＩｏＴデバイスが前記故障情報を取得したときの時刻情報とを含む第１のトランザクションデータを、前記一のＩｏＴデバイスから取得し、
    　前記プロセッサは、前記メモリに記憶された前記プログラムを実行することにより、
    　取得した前記第１のトランザクションデータを、前記複数のサーバのうちの前記第１サーバとは異なる複数の第２サーバに転送し、
    　前記複数の第２サーバとともに、前記第１のトランザクションデータの正当性について合意するための第１のコンセンサスアルゴリズムを実行し、
    　前記第１のコンセンサスアルゴリズムによって前記第１のトランザクションデータの正当性が検証された場合、前記第１のトランザクションデータを含むブロックを前記第１サーバの分散台帳に記録する、
    　第１サーバ。
  11. 　１以上のＩｏＴデバイスと、前記１以上のＩｏＴデバイスとネットワークを介して通信可能な複数のサーバとを備えるシステムにおいて分散台帳に記録されるブロックに用いられるデータ構造であって、
    　前記データ構造は、
    　前記１以上のＩｏＴデバイスのうちの一のＩｏＴデバイスが故障したことを示す故障情報と、前記一のＩｏＴデバイスが前記故障情報を取得したときの時刻情報とを含む第１のトランザクションデータを含み、
    　前記第１のトランザクションデータは、前記分散台帳に格納されたスマートコントラクトが動作されることで前記複数のサーバのうちの第１サーバによって取得され、取得された前記第１のトランザクションデータが前記ブロックに含まれて前記分散台帳に記録される、
    　データ構造。
PCT/JP2019/041094 2018-10-18 2019-10-18 制御方法、制御システム、第１サーバ、及び、データ構造 WO2020080522A1 (ja)

Priority Applications (4)

Application Number Priority Date Filing Date Title
CN201980048752.6A CN112470179B (zh) 2018-10-18 2019-10-18 控制方法、控制系统、服务器及记录介质
JP2020553337A JP7458321B2 (ja) 2018-10-18 2019-10-18 制御方法、制御システム及び第１サーバ
EP19873575.5A EP3869425A4 (en) 2018-10-18 2019-10-18 CONTROL PROCESS, CONTROL SYSTEM, FIRST SERVER AND DATA STRUCTURE
US17/159,714 US11556103B2 (en) 2018-10-18 2021-01-27 Control method, control system, first server, and data structure

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US201862747295P 2018-10-18 2018-10-18
US62/747,295 2018-10-18

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US17/159,714 Continuation US11556103B2 (en) 2018-10-18 2021-01-27 Control method, control system, first server, and data structure

Publications (1)

Publication Number Publication Date
WO2020080522A1 true WO2020080522A1 (ja) 2020-04-23

Family

ID=70283042

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2019/041094 WO2020080522A1 (ja) 2018-10-18 2019-10-18 制御方法、制御システム、第１サーバ、及び、データ構造

Country Status (5)

Country Link
US (1) US11556103B2 (ja)
EP (1) EP3869425A4 (ja)
JP (1) JP7458321B2 (ja)
CN (1) CN112470179B (ja)
WO (1) WO2020080522A1 (ja)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20210073754A1 (en) * 2019-09-10 2021-03-11 Carrier Corporation Method and system to execute and record transactions for a key-box in a blockchain
US11695544B2 (en) * 2019-09-17 2023-07-04 Carrier Corporation Method and system to execute and record transactions for a key in a blockchain

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPS6363278B2 (ja) * 1979-12-20 1988-12-06

Family Cites Families (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2014182448A (ja) * 2013-03-18 2014-09-29 Fujitsu Ltd 情報処理装置、情報処理システム、情報処理方法および情報処理プログラム
AU2017204096A1 (en) * 2016-06-17 2018-01-18 Nomadic Lockers Pty Ltd Storage System
JP2018022941A (ja) * 2016-08-01 2018-02-08 大日本印刷株式会社 管理システム、管理サーバ及び管理プログラム
JP2018067310A (ja) * 2016-10-14 2018-04-26 株式会社テクニカルフィット 物品を保管する保管ボックスの管理方法
EP3563325A4 (en) * 2016-12-30 2020-09-02 Slock.it GmbH BLOCKCHAIN ACTIVATED SERVICE PROVIDER SYSTEM
JP6363278B1 (ja) * 2017-08-07 2018-07-25 株式会社Ａｅｒｉａｌ Ｌａｂ Ｉｎｄｕｓｔｒｉｅｓ 配送方法及び配送システム
US11227457B2 (en) * 2017-12-02 2022-01-18 International Business Machines Corporation Blockchain managed storage
US11328347B2 (en) * 2018-06-28 2022-05-10 International Business Machines Corporation Rental asset processing for blockchain
CN112601477A (zh) * 2018-07-30 2021-04-02 麦进斗研发公司 智能无人家庭递送箱

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPS6363278B2 (ja) * 1979-12-20 1988-12-06

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
GEN TADAO : "Delivery Lockers that are Secure When There's No Manager: Achieving Open Industry Participation with Distributed Accounting", NIKKEI COMMUNICATIONS, 1 January 2017 (2017-01-01), pages 48 - 49, XP009525402, ISSN: 0910-7215 *
GMO INTERNET, INC., GMO INTERNET GROUP, SAISON INFORMATION SYSTEMS, AND PARCO COLLABORATED SECOND DEMONSTRATION EXPERIMENT UTILIZING BLOCKCHAIN AND IOT, 21 June 2017 (2017-06-21), Retrieved from the Internet <URL:httpsV/cloud.z.com/jp/news-ep/IoT2>
OKINO KENICHI : "Security Requirements for Distributed Accounting Technology", KINYU KENKYU, vol. 37, no. 1, 22 January 2018 (2018-01-22), pages 89 - 108, XP009525407, ISSN: 0287-5306 *

Also Published As

Publication number Publication date
CN112470179A (zh) 2021-03-09
CN112470179B (zh) 2024-06-28
JPWO2020080522A1 (ja) 2021-09-09
EP3869425A4 (en) 2021-12-15
JP7458321B2 (ja) 2024-03-29
US11556103B2 (en) 2023-01-17
US20210149356A1 (en) 2021-05-20
EP3869425A1 (en) 2021-08-25

Similar Documents

Publication Publication Date Title
WO2020080524A1 (ja) 制御方法、制御システム、第１サーバ、及び、データ構造
US10855446B2 (en) Autonomous exchange via entrusted ledger
US9584509B2 (en) Auditing and permission provisioning mechanisms in a distributed secure asset-management infrastructure
US8300831B2 (en) Redundant key server encryption environment
TWI502396B (zh) 保全應用程式中購買
CN109891416A (zh) 用于认证和授权装置的系统和方法
JP2019537179A (ja) 機器の安全なプロビジョニングと管理
WO2010013092A1 (en) Systems and method for providing trusted system functionalities in a cluster based system
CN102571347A (zh) 现场可更换单元的校验方法、装置和通信设备
JP2009258917A (ja) プロキシサーバ、認証サーバおよび通信システム
WO2020080522A1 (ja) 制御方法、制御システム、第１サーバ、及び、データ構造
US11271757B2 (en) Monitoring device, monitoring system, information processing device, monitoring method, and program
KR102627868B1 (ko) 블록체인에서 생성된 데이터를 인증하는 방법 및 시스템
JP2011519088A (ja) 分散データ記憶装置
WO2020090418A1 (ja) 電子制御装置、電子制御装置のリプログラミング方法
JP5391743B2 (ja) 決済処理セキュリティ情報配信方法、決済処理セキュリティ情報配信システム、そのセンタ装置、サーバ装置、決済端末、及びプログラム
US9361435B1 (en) Multi-tier digital supply chain management
KR102572834B1 (ko) 서명 가능 컨트랙트를 이용하여 블록체인에서 생성된 데이터를 인증하는 방법 및 시스템
JP2019181149A (ja) 制御方法、情報処理装置、管理システム、及び、プログラム
US9602546B2 (en) Accurate license counting in synchronized servers
WO2020203010A1 (ja) 故障監視方法、監視装置及びプログラム
US20230116684A1 (en) Information processing system, installation device, and computer program product
JP5386860B2 (ja) 決済システム、決済処理装置、正当性検証装置、正当性検証要求処理プログラム、正当性検証処理プログラム、及び正当性検証方法
JP5712033B2 (ja) Ｉｃチップ処理システム、ｉｃチップ処理方法及びプログラム
Gonzalez et al. Trusted Computing Engineering for Resource Constrained Embedded Systems Applications

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: 19873575

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2020553337

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: 2019873575

Country of ref document: EP

Effective date: 20210518