WO2021166932A1 - 制御方法、制御装置、及び、プログラム - Google Patents

制御方法、制御装置、及び、プログラム Download PDF

Info

Publication number
WO2021166932A1
WO2021166932A1 PCT/JP2021/005833 JP2021005833W WO2021166932A1 WO 2021166932 A1 WO2021166932 A1 WO 2021166932A1 JP 2021005833 W JP2021005833 W JP 2021005833W WO 2021166932 A1 WO2021166932 A1 WO 2021166932A1
Authority
WO
WIPO (PCT)
Prior art keywords
transaction data
blockchain
mobile device
mobile
reservation
Prior art date
Application number
PCT/JP2021/005833
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 CN202180014836.5A priority Critical patent/CN115104117A/zh
Priority to JP2022501922A priority patent/JPWO2021166932A1/ja
Publication of WO2021166932A1 publication Critical patent/WO2021166932A1/ja
Priority to US17/888,702 priority patent/US20220391902A1/en

Links

Images

Classifications

    • 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
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/401—Transaction verification
    • 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
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/10—File systems; File servers
    • G06F16/18—File system types
    • G06F16/182—Distributed file systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/64—Protecting data integrity, e.g. using checksums, certificates or signatures
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/08—Payment architectures
    • G06Q20/10—Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems
    • G06Q20/102—Bill distribution or payments
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/06—Buying, selling or leasing transactions
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q2220/00—Business processing using cryptography

Definitions

  • This disclosure relates to control methods, control devices, and programs.
  • Patent Document 1 discloses a technique for appropriately managing information regarding usage reservations sent and received between a vehicle terminal and a user terminal using a blockchain.
  • Patent Document 1 abuses the behavior of the blockchain when a fork occurs to illegally use the object. There is a problem that it can be used.
  • the present disclosure has been made in view of the above circumstances, and an object of the present disclosure is to provide a control method, a control device, and a program capable of suppressing unauthorized use of a service target that abuses a blockchain.
  • the control method includes a first node that manages the first blockchain in the first distributed ledger, and a plurality of second nodes that manage the second blockchain in the second distributed ledger, respectively. It is the control method of the first node in the system used for the use of the service target, and is the first transaction data indicating that the lock of the service target is released when the service target is used, and is the use of the service target.
  • the first transaction data including the first transaction ID that uniquely identifies the first contract is generated, and the block including the first transaction data is stored in the first blockchain.
  • FIG. 1 is a diagram for explaining a procedure of a method of performing unauthorized use.
  • FIG. 2A is a diagram showing an example of a scene in which step 1 shown in FIG. 1 is performed.
  • FIG. 2B is a diagram showing an example of a scene in which steps 2 and 3 shown in FIG. 1 are performed.
  • FIG. 2C is a diagram showing an example of a scene in which step 4 shown in FIG. 1 is performed.
  • FIG. 2D is a diagram showing an example of a scene in which step 5 shown in FIG. 1 is performed.
  • FIG. 2E is a diagram showing an example of a scene in which step 6 shown in FIG. 1 is performed.
  • FIG. 2F is a diagram showing an example of a scene performed after step 6 shown in FIG. FIG.
  • FIG. 3A is a diagram for explaining the behavior of the blockchain when a fork is generated.
  • FIG. 3B is a diagram for explaining the behavior of the blockchain when a fork is generated.
  • FIG. 3C is a diagram for explaining the behavior of the blockchain when a fork is generated.
  • FIG. 4 is a diagram showing an example of the configuration of the system according to the embodiment.
  • FIG. 5A is a diagram showing another example of the configuration of the system according to the embodiment.
  • FIG. 5B is a diagram showing another example of the configuration of the system according to the embodiment.
  • FIG. 5C is a diagram showing another example of the configuration of the system according to the embodiment.
  • FIG. 6 is a diagram showing an example of the configuration of the mobile device according to the embodiment.
  • FIG. 7 is a diagram showing an example of the configuration of the terminal according to the embodiment.
  • FIG. 8 is a flowchart showing an operation outline of normal processing of the system according to the first example of the comparative example.
  • FIG. 9A is a diagram conceptually showing the blocks of the block chain stored in the ledger A and the ledger B by the operation of step S1 of FIG.
  • FIG. 9B is a diagram conceptually showing the blocks of the blockchain stored in the ledger A and the ledger B by the operation of step S3 of FIG.
  • FIG. 9C is a diagram for conceptually explaining the blocks of the block chain stored in the ledger A and the ledger B by the operation of step S5 of FIG.
  • FIG. 10 is a sequence diagram showing a reservation process of the system according to the first example of the comparative example.
  • FIG. 10 is a sequence diagram showing a reservation process of the system according to the first example of the comparative example.
  • FIG. 11 is a sequence diagram showing a system lending process according to the first example of the comparative example.
  • FIG. 12 is a sequence diagram showing a system return process according to the first example of the comparative example.
  • FIG. 13 is a flowchart for explaining the details of the charge calculation process of the system according to the comparative example.
  • FIG. 14 is a flowchart showing an operation outline of normal processing of the system according to the second example of the comparative example.
  • FIG. 15A is a diagram conceptually showing a block of a block chain stored in the ledger A by the operation of step S1A of FIG.
  • FIG. 15B is a diagram conceptually showing the blocks of the blockchain stored in the ledger A by the operation of step S3A of FIG.
  • FIG. 15C is a diagram conceptually showing a block of a block chain stored in the ledger A by the operation of step S5A of FIG.
  • FIG. 16 is a diagram for conceptually explaining the blocks of the blockchain stored in the ledger A and the ledger B by the operation of step S6A of FIG.
  • FIG. 17 is a diagram for conceptually explaining the blocks of the blockchain stored in the ledger A and the ledger B by the operation of step S6A of FIG.
  • FIG. 18 is a sequence diagram showing a reservation process of the system according to the second example of the comparative example.
  • FIG. 19 is a sequence diagram showing a system lending process according to the second example of the comparative example.
  • FIG. 20 is a sequence diagram showing a return process of the system according to the second example of the comparative example.
  • FIG. 21 is a sequence diagram showing system processing performed when the communication of the mobile device A according to the second example of the comparative example is restored.
  • FIG. 22 is a flowchart for explaining the block connection process of the system according to the comparative example.
  • FIG. 23 is a flowchart showing an operation outline of the fraudulent processing of the system according to the third example of the comparative example.
  • FIG. 24A is a diagram conceptually showing the blocks of the block chain stored in the ledger A by the operation of step S10 of FIG. 23.
  • FIG. 24B is a diagram conceptually showing the blocks of the block chain stored in the ledger A by the operation of step S11 of FIG. 23.
  • FIG. 24C is a diagram conceptually showing the blocks of the block chain stored in the ledger A by the operation of step S12 of FIG. 23.
  • FIG. 25 is a diagram for conceptually explaining the blocks of the blockchain stored in the ledger A and the ledger B by the operation of step S13 of FIG. 23.
  • FIG. 26 is a diagram for conceptually explaining the blocks of the blockchain stored in the ledger A and the ledger B by the operation of step S13 of FIG. 23.
  • FIG. 27 is a diagram conceptually showing the blocks of the block chain stored in the ledger A and the ledger B by the operation of step S14 of FIG. 23.
  • FIG. 28 is a sequence diagram showing a process when a local reservation of the system according to the third example of the comparative example is performed.
  • FIG. 29 is a sequence diagram showing a process when competing reservation of the system according to the third example of the comparative example is performed.
  • FIG. 29 is a sequence diagram showing a process when competing reservation of the system according to the third example of the comparative example is performed.
  • FIG. 30 is a sequence diagram showing the processing of local lending of the system according to the third example of the comparative example.
  • FIG. 31 is a sequence diagram showing the processing of the system performed when the communication of the mobile device A according to the third example of the comparative example is restored.
  • FIG. 32 is a sequence diagram showing a return process of the system according to the third example of the comparative example.
  • FIG. 33 is a flowchart showing an operation outline of the fraudulent processing of the system according to the fourth example of the comparative example.
  • FIG. 34A is a diagram conceptually showing the blocks of the block chain stored in the ledger A by the operation of step S10 of FIG. 33.
  • FIG. 34B is a diagram conceptually showing the blocks of the block chain stored in the ledger A by the operation of step S11 of FIG. 33.
  • FIG. 34A is a diagram conceptually showing the blocks of the block chain stored in the ledger A by the operation of step S10 of FIG. 33.
  • FIG. 34B is a diagram conceptually showing the blocks
  • FIG. 34C is a diagram conceptually showing the blocks of the block chain stored in the ledger A by the operation of step S12 of FIG. 33.
  • FIG. 34D is a diagram conceptually showing the blocks of the block chain stored in the ledger A by the operation of step S13A of FIG. 33.
  • FIG. 35 is a diagram for conceptually explaining the blocks of the blockchain stored in the ledger A and the ledger B by the operation of step S14A of FIG. 33.
  • FIG. 36 is a diagram for conceptually explaining the blocks of the blockchain stored in the ledger A and the ledger B by the operation of step S14A of FIG. 33.
  • FIG. 37 is a sequence diagram showing a local return process of the system according to the fourth example of the comparative example.
  • FIG. 37 is a sequence diagram showing a local return process of the system according to the fourth example of the comparative example.
  • FIG. 38 is a sequence diagram showing the processing of the system performed when the communication of the mobile device A according to the fourth example of the comparative example is restored.
  • FIG. 39 is a sequence diagram showing the processing of local lending of the system according to the embodiment.
  • FIG. 40 is a diagram conceptually showing a block of a blockchain stored in the ledger A by the processing of the local lending of FIG. 39.
  • FIG. 41 is a diagram conceptually showing the blocks of the block chain stored in the ledger A and the ledger B when the charge calculation process according to the embodiment is performed.
  • FIG. 42 is a flowchart for explaining the details of the charge calculation process according to the present embodiment.
  • FIG. 43 is a sequence diagram showing the processing of the system performed when the communication of the mobile device A according to the modified example of the embodiment is restored.
  • FIG. 44 is a flowchart showing a fraudulent reservation detection process according to a modified example of the embodiment.
  • FIG. 45 is a sequence diagram showing system processing performed when an incident report is created by executing fraudulent reservation detection
  • Patent Document 1 discloses a technique for appropriately managing information regarding usage reservations transmitted and received between a vehicle terminal and a user terminal by a blockchain.
  • Patent Document 1 can be abused by abusing the blockchain mechanism.
  • Patent Document 1 an example will be described.
  • FIG. 1 is a diagram for explaining a procedure of a method of performing unauthorized use.
  • 2A to 2F are diagrams showing an example of a scene in which the procedure shown in FIG. 1 is performed.
  • FIG. 1 shows a procedure for making a reservation for use of motorcycle A in a service for sharing a plurality of motorcycles and illegally using motorcycle A. The arrow indicates the current time.
  • each of the multiple bikes has a ledger whose reservations are managed by the blockchain.
  • FIG. 2A is a diagram showing an example of a scene in which step 1 shown in FIG. 1 is performed
  • FIG. 2B is a diagram showing an example of a scene in which steps 2 and 3 shown in FIG. 1 are performed.
  • FIG. 2C is a diagram showing an example of a scene in which step 4 shown in FIG. 1 is performed
  • FIG. 2D is a diagram showing an example of a scene in which step 5 shown in FIG. 1 is performed.
  • FIG. 2E is a diagram showing an example of a scene in which step 6 shown in FIG. 1 is performed
  • FIG. 2F is a diagram showing an example of a scene in step 7 performed after step 6 shown in FIG.
  • the user who intends to make an unauthorized use makes the first reservation to use the motorcycle A for 15 minutes, for example, between 12:00 and 12:15 in step 1.
  • the ledger A of the motorcycle A is in a state of being able to communicate (online) with the ledgers B and C of other motorcycles, as shown in step 1 of FIG. 1, the first reservation Tx shown in black is all. It is stored in the ledger (ledgers A, B and C).
  • the bike A is unlocked and the user can use it for 15 minutes between 12:00 and 12:15.
  • the user who intends to use the illegal use puts the ledger A of the motorcycle A into a non-communication (offline) state with the ledgers B and C of other motorcycles in steps 2 and 3. Subsequently, the user who intends to use the motorcycle makes a second reservation for using the motorcycle A for 15 minutes between 16:00 and 16:15, for example, for the ledgers B and C of the other motorcycles. Then, since the ledger A of the motorcycle A is in the offline state, the second reserved Tx shown in black as shown in step 3 of FIG. 1 is stored only in the ledger B and C in the online state.
  • the user who intends to make an unauthorized use makes an unauthorized reservation for using the motorcycle A to the ledger A of the motorcycle A in step 4, for example, between 12:15 and 16:15.
  • the ledger A of the motorcycle A cannot communicate with the ledgers B and C of other motorcycles (offline), as shown in step 4 of FIG. 1, the fraudulent reservation Tx indicated by hatching is the motorcycle A. It is stored only in ledger A.
  • the bike A is unlocked at 12:15, and as shown in step 5 shown in FIG. 2D, the user cheats the bike A while remaining offline between 12:15 and 16:15. It can be used.
  • the second reserved Tx shown in black is stored only in the online ledgers B and C.
  • the user can communicate the ledger A of the motorcycle A with the ledgers B and C of other motorcycles between 16:00 and 16:15 in step 6 (online).
  • a fork is generated in the blockchains of ledgers A, B, and C, and as shown in step 6 of FIG. 1, the blockchain of ledger A is the same as the blockchain of ledgers B and C.
  • the second reserved Tx will be stored.
  • the fraudulent reservation Tx is stored after the second reservation Tx.
  • the fraudulent reservation Tx is stored in the ledgers A, B, and C after the second reservation Tx, and the block when a fork occurs.
  • the behavior of the chain is explained.
  • FIGS. 3A to 3C are diagrams for explaining the behavior of the blockchain when a fork is generated.
  • 3A to 3C conceptually show transaction data stored in the ledger A of the moving body A and the ledger B of the moving body B.
  • Tx indicates transaction data.
  • the moving body A may be, for example, a motorcycle A.
  • Tx2 may correspond to the above-mentioned first reserved Tx, for example.
  • the ledger A and the ledger B contain blocks containing different Tx. Is stored.
  • the ledger A stores the block ⁇ containing the Tx ⁇ connected to the block 2
  • the ledger B contains the block containing the Tx3 connected to the block 2.
  • Tx3 may correspond to, for example, the above-mentioned second reserved Tx
  • Tx ⁇ may correspond to, for example, the above-mentioned fraudulent reserved Tx.
  • the ledger A and the ledger B share different block chains.
  • the block connected to the block 2 is branched, the block ⁇ containing Tx ⁇ is connected to the block 2, and the block containing Tx3 is connected to the block 2.
  • 3 and the block 4 including Tx4 are connected.
  • the longest blockchain among the blockchains branched and connected to the blocks will be referred to as a main chain, and the other blockchains will be referred to as side chains.
  • the block 3 containing Tx3 and the block 4 containing Tx4 correspond to the main chain of block 2
  • the block ⁇ containing Tx ⁇ corresponds to the side chain of block 2.
  • the block ⁇ including the side chain Tx ⁇ of the block 2 is deleted, and the fork is eliminated.
  • the Tx ⁇ included in the block ⁇ is not deleted and is stored in the transaction pool of the mobile device mounted on each mobile.
  • Tx ⁇ is stored in the transaction pools of the mobile device A and the mobile device B.
  • Tx ⁇ is included and stored at the timing of generating a new block.
  • the block 5 containing the same Tx ⁇ is concatenated and stored in the ledger A and the ledger B.
  • the user who attempted the unauthorized use returns the motorcycle A in step 7, as shown in FIG. 2F.
  • the toll collection algorithm is executed and the usage fee of the motorcycle A is collected.
  • the charges for the first reservation and the second reservation are collected, and the charges for the usage between 12:15 and 16:15, that is, the charges for unauthorized use are not collected.
  • the charge collection algorithm does not collect charges for fraudulent reservations that are booking reservations (that is, competing reservations) and later reservations. In this way, the user can use the bike A for 4 hours without paying a fee.
  • the control method is a first node that manages the first blockchain in the first distributed ledger, and a plurality of second nodes that manage the second blockchain in the second distributed ledger, respectively. It is a control method of the first node in the system used for the use of the service target, and is the first transaction data indicating that the lock of the service target is released when the service target is used.
  • the first transaction data including the first transaction ID that uniquely identifies the first contract that uses the service target is generated, and the block containing the first transaction data is stored in the first blockchain.
  • the first transaction data indicating that the lock of the service target has been released is stored in the first blockchain.
  • the charge using the service target triggered by the first transaction data stored in the first blockchain and the second blockchain is charged. Can be collected. Therefore, it is possible to suppress unauthorized use of the service target that abuses the blockchain.
  • the charge collection smart contract for collecting the usage fee for the service target is executed and the charge collection smart contract is executed
  • the first blockchain and the second blockchain are subjected to the first item.
  • 1 Transaction data is stored, and the usage fee for the first contract in the use of the service target is not collected for the first contract identified by the first contract ID included in the first transaction data.
  • the charge collection smart contract is made to confirm whether or not the contract is present, and when the first transaction data is stored and the charge is not collected, the charge collection smart contract is made to collect the usage charge for the first contract. You may.
  • the case where the service is not collected means that the first blockchain and the second blockchain have the second transaction data for making the first contract and the second contract for using the service target.
  • the third transaction data for performing the above is stored, and further, the time zone for using the service target included in the first contract and the time zone for using the service target included in the second contract. It may be the case that and is partially overlapped.
  • the charge collection smart contract may be made to create an incident report indicating that the use of the service target included in the first contract is fraudulent.
  • the first blockchain and the second blockchain are subjected to the second transaction data for making the first contract and the third transaction for making the second contract for using the service target.
  • conflict in which data is stored and the time zone for using the service target included in the first contract and the time zone for using the service target included in the second contract partially overlap.
  • the fraud detection smart contract is made to confirm whether or not there is a contract, and if the competing contract exists, the fraud detection smart contract is flagged as not collecting the usage fee to the first contract. Then, the charge collection smart contract for collecting the usage charge for the service target may be made to execute the charge collection for the first contract to which the flag is given.
  • the system is used for a service of sharing a plurality of mobile bodies
  • the service target is the plurality of mobile bodies
  • the first contract and the second contract are the first mobile bodies.
  • the second transaction data and the third transaction data are reserved transaction data for the user to make a reservation for the use of the first mobile body via the first node, and are reserved transaction data of the user.
  • the ID may include a reservation time zone indicating a time zone in which the user uses the first mobile body, and a reservation number for identifying the usage reservation.
  • the service target in the first contract is triggered by the first transaction data stored in the first blockchain and the second blockchain. You can collect the fee you used. Therefore, it is possible to suppress unauthorized use of the service target that abuses the blockchain.
  • the first node further receives a request for unlocking the first mobile body from the user as a request for starting the use of the first mobile body, and the first node receives a request for unlocking the first mobile body. It is confirmed whether the reserved transaction data corresponding to the unlock request is stored in the first blockchain, and if the reserved transaction data is stored, the unlocking of the first mobile body is performed in the time zone.
  • the first transaction data may be generated by permitting the user.
  • the lending transaction data indicating that the first moving object has been lent to the user, and the user's ID, the reservation number, and the first moving object are lent to the user.
  • the lending transaction data including the time stamp of the time is acquired, the second block including the lending transaction data is stored in the first blockchain, and it is shown that the user has returned the first moving object.
  • the return transaction data which includes the ID of the user, the reservation number, and the time stamp of the time when the user returned the first moving object, is acquired, and includes the return transaction data.
  • the third block may be stored in the first blockchain, and the usage fee of the first moving object may be collected for the user's ID included in the reserved transaction data.
  • the control device includes a control device that manages the first blockchain in the first distributed ledger, and a plurality of different control devices that manage the second blockchain in the second distributed ledger, respectively.
  • a control device in a system used for the use of the service target which includes a processor and a memory, and is a first transaction data indicating that the processor has released the lock of the service target when the service target is used. Therefore, the first transaction data including the first contract ID that uniquely identifies the first contract that uses the service target is generated, and the processor sets the block containing the first transaction data into the first block chain. Store in.
  • the program according to one aspect of the present disclosure includes a first node that manages the first blockchain in the first distributed ledger, and a plurality of second nodes that manage the second blockchain in the second distributed ledger, respectively, and provides services. It is a program for causing a computer to execute the control method of the first node in the system used for the use of the target, and is the first transaction data indicating that the lock of the service target is released when the service target is used. Therefore, the first transaction data including the first transaction ID that uniquely identifies the first contract that uses the service target is generated, and the block including the first transaction data is stored in the first block chain. , A program to make a computer execute.
  • the system includes a first node that manages the first blockchain in the first distributed ledger, and a plurality of second nodes that manage the second blockchain in the second distributed ledger, respectively, and is used for the use of the service target.
  • the system may be used, for example, in a service for sharing a plurality of mobile objects, and in this case, the service target is a plurality of mobile objects.
  • the system accepts a usage reservation of a specific mobile body from a user via a terminal (or a mobile body), and lends the specific mobile body to the user according to the received usage reservation.
  • the system When the system receives a loan request for a specific reserved mobile from the user via the terminal (or mobile) during the reserved time zone in the received usage reservation, the system lends the specific mobile to the user. Allow. Specifically, when the system receives an unlock request for a specific mobile object from the user, the system confirms the usage reservation made in advance and unlocks the specific mobile object at the reserved time according to the confirmation result. Allow the user to do so.
  • moving objects in the sharing service include, for example, bicycles, motorcycles, automobiles, ships, flying objects, and the like.
  • FIG. 4 is a diagram showing an example of the configuration of the system according to the embodiment.
  • the system 1 includes, for example, mobile bodies 10A to 10C and terminals 11A to 11C.
  • each of the mobile bodies 10A to 10C has a distributed ledger for sharing the same data.
  • distributed ledgers for example, a blockchain having the same configuration is shared.
  • the mobile bodies 10A to 10C and the terminals 11A to 11C are connected by a network.
  • the network is, for example, the Internet, a carrier network of a mobile phone, or the like, but may be composed of any communication line or network.
  • each of the moving bodies 10A to 10C is also referred to as a moving body 10, but the moving bodies 10A to 10C may be referred to as a moving body A to a moving body C.
  • the terminals 11A to 11C is also referred to as a terminal 11, the terminals 11A to 11C may be referred to as terminals A to C.
  • the distributed ledgers provided by the mobile bodies 10A to 10C may be referred to as ledgers A to C.
  • the system for managing the distributed ledger that stores the blockchain may be in any form of public type, private type, and consortium type.
  • FIG. 5A is a diagram showing another example of the configuration of the system according to the embodiment.
  • the mobile bodies 10A and 10B, the terminals 11A and 11B, and the management server 20 are shown.
  • the mobile bodies 10A and 10B and the management server 20 each have a distributed ledger for sharing the same data.
  • a distributed ledger for example, a blockchain having the same configuration is shared.
  • the mobile bodies 10A and 10B, the terminals 11A and 11B, and the management server 20 are connected by a network.
  • the network is, for example, the Internet, a carrier network of a mobile phone, or the like, but may be composed of any communication line or network.
  • FIG. 5B is a diagram showing another example of the configuration of the system according to the embodiment.
  • FIG. 5B for example, mobile bodies 10A to 10C and terminals 11A to 11C are shown.
  • each of the terminals 11A to 11C has a distributed ledger for sharing the same data.
  • a distributed ledger for example, a blockchain having the same configuration is shared.
  • the mobile bodies 10A to 10C and the terminals 11A to 11C are connected by a network.
  • the network is, for example, the Internet, a carrier network of a mobile phone, or the like, but may be composed of any communication line or network.
  • FIG. 5C is a diagram showing another example of the configuration of the system according to the embodiment.
  • mobile bodies 10A to 10C and terminals 11A to 11C are shown.
  • the mobile bodies 10A to 10C and the terminals 11A to 11C each have a distributed ledger for sharing the same data.
  • a distributed ledger for example, a blockchain having the same configuration is shared.
  • the mobile bodies 10A to 10C and the terminals 11A to 11C are connected by a network.
  • the network is, for example, the Internet, a carrier network of a mobile phone, or the like, but may be composed of any communication line or network.
  • FIGS. 5A to 5C are different from the system of FIG. 4 only in the device or terminal having the distributed ledger, and are similarly applicable.
  • the mobile device mounted on the mobiles 10A to 10C will be described.
  • the moving body devices mounted on the moving bodies 10A to 10C may be referred to as mobile body devices A to C, respectively.
  • the mobile device 100 is an example of a node that manages a blockchain in a distributed ledger.
  • a node can be rephrased as a control device.
  • the mobile device 100 is an information processing device mounted on the mobile device 10 and has a distributed ledger.
  • the mobile device 100 may be a mobile terminal such as a smartphone or a tablet.
  • FIG. 6 is a diagram showing an example of the configuration of the mobile device 100 according to the embodiment.
  • the mobile device 100 includes an input unit 101, a transaction data generation unit 102, a transaction data verification unit 103, a block generation unit 104, a synchronization unit 105, a smart contract execution unit 106, and a block. It includes a chain management unit 107, a distributed ledger storage unit 108, a state storage unit 109, a fraud detection unit 110, a communication unit 111, and a display unit 112.
  • the input unit 101 accepts input from the user.
  • the input unit 101 displays the received information input on the display unit 112, transmits it to the transaction data generation unit 102, or transmits it to the communication unit 111.
  • the input unit 101 may accept an information input indicating a return from the user.
  • Transaction data generator 102 The transaction data generation unit 102 generates transaction data.
  • the transaction data generation unit 102 generates lending transaction data indicating that the mobile body 10 has been lent to the user. Specifically, when the mobile body 10 is lent to the user, the transaction data generation unit 102 generates lending transaction data indicating that the mobile body 10 has been lent to the user. The transaction data generation unit 102 generates lending transaction data, for example, when the mobile body is unlocked in response to an unlock request from the user.
  • the lending transaction data includes a user ID, a reservation number (reservation ID) for identifying a usage reservation, and a time stamp of the time when the moving body 10 is lent to the user.
  • the transaction data generation unit 102 generates unlocking completion transaction data indicating to the user that the unlocking of the mobile body 10 is completed. Specifically, the transaction data generation unit 102 generates unlocking completion transaction data when, for example, the unlocking request from the user is received and the mobile body 10 is unlocked. In the unlocking completion transaction data, the user ID that unlocked the mobile body 10, the device ID of the mobile device 100 that unlocked the mobile body 10, the corresponding reservation number (reservation ID), and the mobile body 10 are unlocked. Including the date and time. The date and time when the mobile body 10 is unlocked may be a time stamp of the time when the mobile body 10 is unlocked.
  • the transaction data generation unit 102 generates unlocking completion transaction data when the mobile body 10 is unlocked in response to an unlocking request from the user, and then lends the data. Generate transaction data.
  • the transaction data generation unit 102 generates return transaction data indicating that the user has returned the mobile body 10. Specifically, when the moving body 10 is returned by the user, the transaction data generation unit 102 generates return transaction data indicating that the user has returned the moving body 10.
  • the fact that the moving body 10 has been returned by the user may be determined by the input unit 101 accepting the information input indicating the return from the user, or the input unit 101 accepting the information input indicating the return from the user via the terminal 11. (That is, it may be determined by the fact that the communication unit 111 receives the information input from the terminal 11), or it may be determined by the fact that the mobile body 10 has been locked by the user, or it may be determined in advance.
  • the return transaction data includes a user ID, a reservation number (reservation ID), and a time stamp of the time when the user returns the mobile body 10.
  • the reserved transaction data is generated by the terminal 11A, but when the mobile device 100 accepts the usage reservation from the user, the transaction data generation unit 102 generates the reserved transaction data for making the usage reservation. May be good. Specifically, the transaction data generation unit 102 generates reserved transaction data including reservation information indicating a usage reservation when an input for a usage reservation is made to the input unit 101 by the user.
  • the reservation information includes a user ID, a reservation number (reservation ID) for identifying the usage reservation, and a reservation time zone indicating a time zone in which the user uses the mobile body 10.
  • the reservation information may further include a device ID for identifying the mobile body 10 for which the usage reservation has been made.
  • the transaction data generation unit 102 detects the unlocking completion transaction data satisfying a predetermined condition by the fraud detection unit 110, the transaction data generation unit 102 issues an incident report indicating that the use of the mobile body 10 to be serviced has been fraudulent.
  • Transaction data including may be generated.
  • Transaction data verification unit 103 executes a verification algorithm when the communication unit 111 receives the transaction data, and verifies the validity of the transaction data. Then, the transaction data verification unit 103 stores the transaction data whose validity has been verified in the transaction pool area of the state storage unit 109. The legitimacy-verified transaction data stored in the state storage unit 109 is transmitted by the communication unit 111 to the other mobile device 100 as information on the transaction data to be stored in the block to be generated next.
  • the transaction data verification unit 103 verifies whether the transaction data received by the communication unit 111 is given an electronic signature generated by a correct method.
  • the transaction data received by the communication unit 111 is any one of the reserved transaction data, the unlocking completed transaction data, the lending transaction data, and the returning transaction data. That is, the transaction data verification unit 103 verifies the validity of the reserved transaction data, the unlocking completed transaction data, the lending transaction data, and the returned transaction data.
  • the transaction data verification unit 103 does not have to verify the validity of the transaction data when the transaction data is generated by the transaction data generation unit 102.
  • the block generation unit 104 generates a block including transaction data whose validity has been verified by the transaction data verification unit 103.
  • the block generation unit 104 generates a block containing a predetermined number of transaction data from the plurality of verified transaction data stored in the state storage unit 109.
  • the block generation unit 104 selects a plurality of blocks to be block-generated from a plurality of transaction data that have not yet been targeted for block generation among the plurality of transaction data.
  • the block generation unit 104 may delete a plurality of transaction data that have already been the target of block generation from the state storage unit 109.
  • the block generated by the block generation unit 104 of the mobile device 100 may be different from the block generated by the block generation unit 104 of the other mobile device 100. This is because the verified transaction data stored in the state storage unit 109 differs for each mobile device 100 depending on the communication state of each mobile device 100, and the judgment criteria for block generation in the block generation unit 104 differ. This is to do.
  • the block generation determination criteria may be held by each mobile device 100.
  • the block generation unit 104 has a plurality of verified transaction data stored in the state storage unit 109 based on the block generation determination criteria held by the mobile device 100 including the block generation unit 104. Select transaction data and generate a block containing multiple selected transaction data.
  • the synchronization unit 105 synchronizes the blocks generated by the block generation unit 104 with the other mobile device 100.
  • the synchronization unit 105 transmits the block generated by the block generation unit 104 to the other mobile device 100 via the communication unit 111. Then, the synchronization unit 105 jointly executes a consensus algorithm with the other mobile device 100 for the transmitted block.
  • a consensus algorithm a consensus algorithm called PBFT (Practical Byzantine Fault Tolerance) may be used, or other known consensus algorithms may be used.
  • Known consensus algorithms include, for example, POW (Proof Of Work) or POS (Proof Of Stake).
  • the synchronization unit 105 may determine that the validity of the transaction data is verified by the consensus algorithm when the number of the reports exceeds a predetermined number. In this way, the synchronization unit 105 agrees that the transaction data is legitimate transaction data (that is, legitimacy) based on the reports notified from each of the other mobile devices 100, and agrees on the legitimacy of the block. do.
  • the synchronization unit 105 connects the agreed blocks to the first block chain managed by the distributed ledger stored in the distributed ledger storage unit 108.
  • the smart contract execution unit 106 operates the smart contract by executing the contract code included in the transaction data stored in the distributed ledger of the distributed ledger storage unit 108.
  • the smart contract execution unit 106 may perform the reservation process for making a reservation for the use of the mobile object to be serviced by operating the reservation smart contract.
  • the smart contract execution unit 106 may perform the reservation process when a block including the reservation transaction data is added to the blockchain in the distributed ledger stored in the distributed ledger storage unit 108.
  • the smart contract execution unit 106 may perform the charge calculation process by operating the charge collection smart contract.
  • the smart contract execution unit 106 causes the charge calculation process to be performed when a block containing the return transaction data is added to the blockchain in the distributed ledger stored in the distributed ledger storage unit 108.
  • the charge calculation process is the same as the process performed by the blockchain management unit 107, which will be described later.
  • the smart contract execution unit 106 may cause the charge collection smart contract to collect the usage fee for the reservation when the unlocking completion transaction data is stored and has not been collected.
  • the smart contract execution unit 106 may perform the fraud detection process by operating the fraud detection smart contract.
  • the smart contract execution unit 106 causes fraud detection processing to be performed when a block containing reserved transaction data is added to the blockchain in the distributed ledger stored in the distributed ledger storage unit 108.
  • the fraud detection process is the same as the process performed by the fraud detection unit 110, which will be described later.
  • the smart contract execution unit 106 can manage the collection of usage fees, the detection of fraudulent reservations, etc. by the distributed ledger by operating the smart contract. It is assumed that the toll collection smart contract and the fraud detection smart contract are generated by the application of the terminal 11 by the user, and the blocks including these smart contracts are stored in the blockchain in advance.
  • the blockchain management unit 107 manages a blockchain (hereinafter referred to as a first blockchain) managed by a distributed ledger (hereinafter referred to as a first distributed ledger) stored in the distributed ledger storage unit 108.
  • a blockchain hereinafter referred to as a first blockchain
  • a distributed ledger hereinafter referred to as a first distributed ledger
  • the blockchain management unit 107 is a blockchain (hereinafter, referred to as a second distributed ledger) managed by a distributed ledger (hereinafter, referred to as a second distributed ledger) owned by another mobile device 100 via a communication unit 111.
  • the second blockchain (referred to as the second blockchain) is acquired, and the first blockchain managed by the first distributed ledger of the distributed ledger storage unit 108 is compared with the acquired second blockchain.
  • the blockchain management unit 107 determines whether or not the plurality of blocks constituting the first blockchain and the plurality of blocks constituting the second blockchain are the same.
  • the blockchain management unit 107 is included in the first blockchain and is the first. 2 Which is the number of 1 or more first difference blocks not included in the blockchain or the number of 1 or more second difference blocks included in the second blockchain and not included in the first blockchain? Determine if it is large (long). That is, the blockchain management unit 107 compares the number of one or more first difference blocks with the number of one or more second difference blocks to determine which is the main chain block and which is the side chain block. Determine if. In this determination, as a result of comparison between the first blockchain and the second blockchain, the first blockchain has one or more first difference blocks, and the second blockchain has one or more second difference blocks. It is done when you have.
  • the blockchain management unit 107 sets the larger (longer) of one or more first difference blocks and one or more second difference blocks to one or more common blocks that are common to each other in the first blockchain and the second blockchain. Add after. Then, the blockchain management unit 107 further includes one or more transaction data included in one or more first difference blocks and one or more second difference blocks, whichever is smaller (shorter), after the added more one. Add one or more blocks. That is, the blockchain management unit 107 determines which of one or more first difference blocks and one or more second difference blocks is the main chain block, and determines one or more first difference blocks and one or more second difference blocks. The smaller of the blocks is determined as the side chain block. Then, the blockchain management unit 107 adds a main chain block and an additional block in the order of one or more common blocks, followed by a main chain block and an additional block generated from one or more transaction data included in the side chain block. do.
  • the blockchain management unit 107 updates the first blockchain managed by the first distributed ledger of the distributed ledger storage unit 108. That is, the blockchain management unit 107 compares the first blockchain with the second blockchain managed by the second distributed ledger owned by the other mobile device 100, and configures these blockchains. If they are different, the first blockchain is updated so that the configurations are the same as each other.
  • the blockchain management unit 107 has one or more in the first blockchain when the first blockchain does not have one or more first difference blocks.
  • the first blockchain is updated by adding the second difference block.
  • one or more first difference blocks are included in the second block chain, which is generated when the mobile device 100 is added to the first block chain in a state where it cannot communicate with another mobile device 100, for example. It is a block that is not.
  • the number of one or more first difference blocks is likely to be smaller than the number of one or more second difference blocks when a plurality of other mobile devices 100 are in a state of being able to communicate with each other.
  • the second blockchain is managed synchronously by the second distributed ledger owned by each of a plurality of other mobile devices 100 having a larger number than the mobile device 100 that manages the first blockchain. This is because it is considered that there are more opportunities to generate blocks in the plurality of other mobile devices 100 than in one mobile device 100. Therefore, one or more first difference blocks generated in one mobile device 100 that cannot communicate with another mobile device 100 are more likely to be side chain blocks than main chain blocks.
  • the first difference block of one or more may have a block including transaction data including information about the contract.
  • the contract is, for example, a reservation for the use of the mobile body 10.
  • Transaction data including information about the contract is, for example, reserved transaction data, unlocking completed transaction data, lending transaction data, and return transaction data.
  • the blockchain management unit 107 does not have to acquire all of the second blockchain, but only a part of it.
  • the part of the second blockchain acquired by the blockchain management unit 107 here is one or more blocks after the last block after the previous update of the first blockchain is executed. Is.
  • the blockchain management unit 107 may perform a lending process for lending the mobile body 10 to the user.
  • the blockchain management unit 107 refers to the first blockchain in the first distributed ledger stored in the distributed ledger storage unit 108 to request the unlock. Check if the reservation is made based on.
  • the blockchain management unit 107 determines whether or not the reservation transaction data including the same reservation number as the reservation number included in the unlock request is stored in the first blockchain.
  • the blockchain management unit 107 determines that a reservation based on the unlock request has been made when the reservation transaction data including the same reservation number as the reservation number included in the unlock request is stored in the first blockchain. , Instruct the moving body 10 to unlock.
  • the moving body 10 obtains the unlocking instruction
  • the moving body 10 operates the locking actuator based on the unlocking instruction to unlock (unlock) the moving body.
  • the unlock request is information for unlocking the mobile body 10 reserved for use by the user in the usage reservation.
  • the unlock request may include at least the reservation number to identify the reservation.
  • the unlocking request further includes a user ID indicating a user who has reserved the use, a mobile ID of the mobile 10 to be reserved for use, a device ID of the mobile device 100 which has reserved the mobile 10, a reserved time zone, and the like. You may.
  • the blockchain management unit 107 is provided with the mobile device 100 when the start time of the reservation time zone of the usage reservation stored in the first blockchain is reached instead of receiving the unlock request. You may instruct the moving body to unlock it.
  • the blockchain management unit 107 may perform the charge calculation process instead of the smart contract executed by the smart contract execution unit 106.
  • the blockchain management unit 107 is connected to a block that has passed a certain interval since the previous processing was executed or is newly connected to the first blockchain in the first distributed ledger stored in the distributed ledger storage unit 108.
  • the charge calculation process is performed with the inclusion of the return transaction data as a trigger.
  • the blockchain management unit 107 searches the first blockchain of the distributed ledger storage unit 108, and two or more transaction data including contracts competing with each other are included in the first blockchain managed by the first distributed ledger. Determine if it is possible.
  • a contract that competes with each other is, for example, a contract in which the time zone for using the service target included in the first contract and the time zone for using the service target included in the second contract partially overlap.
  • the contracts competing with each other include, for example, a first reservation and a first reservation such that the same mobile ID and two or more reserved time zones in which some time zones overlap each other are included. The case where there is a second reservation that conflicts with the reservation can be mentioned.
  • the blockchain management unit 107 includes the transaction data including the first reservation and the transaction data including the conflict reservation in the transaction data previously added to the first blockchain. The first reservation or competing reservation is fulfilled.
  • the blockchain management unit 107 calculates a charge for the earliest usage reservation in the duplicate reservation, and executes a charge collection process for collecting the calculated charge from the user. In other words, the blockchain management unit 107 executes the charge collection process without calculating the charge for the usage reservation other than the earliest usage reservation among the duplicate reservations in order to prevent double collection from the same user. do not.
  • the unlocking completion transaction data is used as the first reservation or competing reservation for which no charge is collected. Collect the fee. Since the unlocked transaction data exists in the first blockchain, even if there is a first reservation or a competing reservation, the mobile body 10 is certainly used by the first reservation or the competing reservation for which no charge has been collected. This is because even if the fee is collected, it will not be double-collected.
  • the usage reservation for which the charge is calculated is the usage reservation of the reservation number included in the return transaction data stored in the first blockchain, and the usage reservation for which the charge has not been calculated yet. In other words, usage reservations for which charges have already been calculated are excluded from the subject of charge calculation. Further, if the usage reservation corresponding to the reservation number included in the return transaction data is not stored in the first blockchain, the charge is not calculated for the return transaction data.
  • the distributed ledger storage unit 108 stores the first distributed ledger managed by the first blockchain.
  • the first distributed ledger stores a block including a reservation transaction data, an unlocking completion transaction data, a lending transaction data, and a return transaction data in the first blockchain.
  • the state storage unit 109 is a storage unit that stores the latest version of the data of the distributed ledger.
  • the data stored in the state storage unit 109 is data that can be changed or deleted by a computer.
  • the state storage unit 109 includes, for example, an on-memory area in which variables, functions, and the like for executing a smart contract are stored, and a transaction pool area in which transaction data is stored.
  • the state storage unit 109 may store transaction data whose validity has been verified by the transaction data verification unit 103.
  • the state storage unit 109 may store the second blockchain acquired via the communication unit 111.
  • the state storage unit 109 may store one or more second difference blocks in the second block chain.
  • the state storage unit 109 may store the first blockchain stored in the distributed ledger storage unit 108.
  • the state storage unit 109 may store transaction data before it is stored in the distributed ledger.
  • the state storage unit 109 may store the smart contract called by the transaction data. Further, the state storage unit 109 may store the variables of the smart contract stored in the distributed ledger.
  • the state storage unit 109 may store the transaction data generated by the transaction data generation unit 102.
  • the state storage unit 109 may store the transaction data received by the communication unit 111.
  • the state storage unit 109 may temporarily store each of the above-mentioned data.
  • the fraud detection unit 110 satisfies a predetermined condition in the first blockchain managed by the first distributed ledger stored in the distributed ledger storage unit 108 instead of the smart contract executed by the smart contract execution unit 106.
  • Unauthorized reservation detection processing may be performed to detect whether or not the unlocking completion transaction data is stored.
  • the unlocking completion transaction data satisfying a predetermined condition may be, for example, unlocking completion transaction data including a reservation ID for which there is no corresponding reservation, or unlocking completion transaction data issued at a time when there is no reservation. It may be.
  • the fraud detection unit 110 detects that the unlocking completion transaction data satisfying a predetermined condition is stored in the fraud reservation detection process, so that there is a fraudulent reservation for which the existing charge calculation algorithm does not collect the charge. Can be detected.
  • the fraud detection unit 110 determines that the unlocking completion transaction data satisfying the predetermined condition is stored, the fraud detection unit 110 creates an incident report indicating that the use of the mobile body 10 to be serviced has been fraudulent.
  • the transaction data generation unit 102 may be notified.
  • the incident report may include a reason for determining that there was fraud, a block containing the detected unlocking completion transaction data or unlocking completion transaction data. The reasons for determining that there was fraud were that the reservations were in conflict, that the difference between the block generation time and the block concatenation time was large, that there were multiple reservations that corresponded to the returned transaction data, and that the lock was unlocked. Completed transaction data may meet certain conditions.
  • the unlocking completion transaction data or a block containing the unlocking completion transaction data may include one or more transaction data related to the unlocking completion transaction data.
  • the related transaction data includes lending transaction data having a reservation ID included in the unlocking completion transaction data, reservation transaction data, and the like.
  • the incident report may further include any one of the detection time, the user ID of the target user, and the terminal ID mounted on the target moving body.
  • the detection time indicates the time when the fraud detection unit 110 determines that the unlocking completion transaction data is stored in the first blockchain, or the time when the unlocking completion transaction data is generated.
  • the target user indicates the user who made the reservation included in the competing reservation transaction data.
  • the terminal ID indicates the mobile device 100 that has reserved the mobile 10 included in the unlocking completion transaction data.
  • the fraud detection unit 110 may add a flag indicating that the usage fee has not been collected to the reservation transaction data corresponding to the fraudulent reservation or the fraudulent reservation. good.
  • the fraud detection unit 110 further includes the device ID of the mobile device 100 that detects that there is a fraudulent reservation or the terminal ID of the terminal 11 that detects fraud in the reservation transaction data corresponding to the fraudulent reservation or the fraudulent reservation. The time when it is detected that the reservation has been made may be given.
  • the fraud detection unit 110 notifies the synchronization unit 105 of the fraudulent reservation with a flag and the like, or the reservation transaction data corresponding to the fraudulent reservation.
  • the flagged fraudulent reservation or the reserved transaction data corresponding to the fraudulent reservation is executed with the other mobile device 100 by a consensus algorithm and stored in the blockchain of each mobile device 100.
  • the charge collection smart contract described later can be made to execute the charge collection for the fraudulent reservation with the flag.
  • the communication unit 111 transmits information to another mobile device 100 or terminal 11 via a network, or receives information from another mobile device 100 or terminal 11.
  • the communication unit 111 communicates with another mobile device 100 or the terminal 11 via a network. Note that this communication may be performed by TLS (Transport Layer Security), and the encryption key for TLS communication may be held by the communication unit 111.
  • TLS Transport Layer Security
  • the communication unit 111 receives the reserved transaction data from the terminal 11. Further, the communication unit 111 receives the unlock request from the terminal 11. Further, the communication unit 111 receives transaction data verified by the other mobile device 100 from the other mobile device 100. The communication unit 111 transmits and receives blocks to and from another mobile device 100 in order to jointly execute a consensus algorithm.
  • the display unit 112 displays the information input received by the input unit 101.
  • the display unit 112 may display the information transmitted from the terminal 11.
  • the display unit 112 may display a display (UI: User Interface) for accepting the return of the mobile device 100 from the user.
  • UI User Interface
  • terminals 11A to 11C will be described. Since the configurations of the terminals 11A to 11C are common, they will be referred to as terminals 11 for description.
  • the terminal 11 is an example of a terminal used by a user.
  • the terminal 11 may be, for example, a personal computer or a mobile terminal such as a smartphone or tablet.
  • FIG. 7 is a diagram showing an example of the configuration of the terminal 11 according to the first embodiment.
  • the terminal 11 includes an input unit 1101, a display unit 1102, and a communication unit 1103.
  • the input unit 1101 accepts information input by the user's operation.
  • the input unit 1101 displays the received information input on the display unit 1102 or transmits it to the communication unit 1103.
  • the input unit 1101 has an application for making a usage reservation installed, and accepts input to the display (UI) for making a usage reservation.
  • This display (UI) is displayed on the display unit 1102.
  • the input unit 1101 accepts the electronic signature of the user who owns the terminal 11 and generates the reservation transaction data including the input for the received usage reservation and the electronic signature.
  • the input unit 1101 accepts the input to the display (UI) for unlocking request to the reserved mobile device 100.
  • This display (UI) is displayed on the display unit 1102.
  • the input unit 1101 receives the input for the unlock request and generates the unlock request.
  • the display unit 1102 displays the information input received by the input unit 1101.
  • the display unit 1102 displays a display (UI) for making a usage reservation.
  • the display unit 1102 displays a display (UI) for unlocking request.
  • the communication unit 1103 transmits information to the mobile device 100 via the network, and receives or notifies the information from the mobile device 100. Further, the communication unit 1103 may transmit information to another terminal 11 or receive information from another terminal 11 via a network.
  • the communication unit 1103 communicates with the mobile device 100 or the other terminal 11 via the network.
  • This communication may be performed by TLS, and the encryption key for TLS communication may be held by the communication unit 1103.
  • the communication unit 1103 transmits the reserved transaction data to the mobile device 100. Further, the communication unit 1103 transmits the unlocking request to the reserved mobile device 100.
  • FIG. 8 is a flowchart showing an operation outline of normal processing of the system according to the first example of the comparative example.
  • FIG. 8 shows an outline of the operation of normal processing in which the mobile devices A, B, and C normally perform processing on the mobile A in the online state.
  • 9A to 9C are diagrams for conceptually explaining the blocks of the block chain stored in the ledger A of the mobile device A and the ledger B of the mobile device B.
  • FIG. 9A is a diagram conceptually showing the blocks of the block chain stored in the ledger A and the ledger B by the operation of step S1 of FIG.
  • FIG. 9B is a diagram conceptually showing the blocks of the blockchain stored in the ledger A and the ledger B by the operation of step S3 of FIG.
  • 9C is a diagram conceptually showing the blocks of the block chain stored in the ledger A and the ledger B by the operation of step S5 of FIG.
  • a user who wants to use the mobile body A uses the terminal A to perform processing on the mobile body device A mounted on the mobile body A.
  • the terminal A communicates with the mobile device A and performs a reservation process for the mobile device A on which the mobile device A is mounted (S1). More specifically, the terminal A communicates with the mobile device A, generates reservation transaction data Trsv for making a reservation for using the mobile device A, and transmits the reserved transaction data Trsv to the mobile device A.
  • the terminal A since the mobile device A and the mobile device B are in a communicable (online) state with other mobile devices, both the ledger A and the ledger B are moved. A block containing the reserved transaction data Trsv for making a reservation for using the body A is stored.
  • the terminal A communicates with the mobile device A and performs the lending process of the mobile A (S3). More specifically, the terminal A communicates with the mobile device A and transmits an unlock request for the mobile A to use the mobile A. Then, the mobile device A unlocks the mobile A and generates lending transaction data Trnt indicating the start of lending of the mobile A triggered by the unlocking of the mobile A.
  • the terminal A communicates with the mobile device A and performs the lending process of the mobile A (S3). More specifically, the terminal A communicates with the mobile device A and transmits an unlock request for the mobile A to use the mobile A. Then, the mobile device A unlocks the mobile A and generates lending transaction data Trnt indicating the start of lending of the mobile A triggered by the unlocking of the mobile A.
  • FIG. 9B since the mobile device A and the mobile device B are in a communicable (online) state with other mobile devices, both the ledger A and the ledger B are moved. A block containing the lending transaction data Trnt indicating the lending start of
  • the terminal A communicates with the mobile device A and performs a return process of the mobile device A (S5). More specifically, the user who operates the terminal A uses the unlocked mobile body A for the reserved time and then returns it. When the mobile body A is returned, the mobile body device A generates return transaction data Trtn indicating that the return of the mobile body A is completed. In this case, for example, as shown in FIG. 9C, since the mobile device A and the mobile device B are in a communicable (online) state with other mobile devices, both the ledger A and the ledger B are moved. A block containing the return transaction data Trtn indicating the completion of the return of the body A is stored.
  • the charge calculation process is performed (S7). More specifically, in the mobile device A or the like, the charge calculation algorithm is executed, and the charge using the mobile A is collected for the usage reservation of the mobile A made by the user.
  • steps S1 to S5 shown in FIG. 8 that is, the details of the reservation processing, the lending processing, and the returning processing will be described with reference to the sequence diagram.
  • the user who wants to use the mobile body A uses the terminal A to perform the reservation process, the lending process, and the return process of the mobile body A with respect to the mobile body device A mounted on the mobile body A.
  • FIG. 10 is a sequence diagram showing a reservation process of the system according to the first example of the comparative example.
  • the terminal A generates reservation transaction data Trsv for making a reservation for using the mobile body A based on the operation of the user who wants to use the mobile body A (S101).
  • the application is introduced as the input unit 1101 in the terminal A, that is, the terminal 11A, and the application may generate the reserved transaction data Trsv based on the operation of the user.
  • the terminal A communicates with the mobile device A of the mobile A and transmits the reserved transaction data Trsv generated in step S101 to the mobile device A (S102).
  • the mobile device A when the mobile device A receives the reserved transaction data Trsv transmitted in step S102, the mobile device A transfers the reserved transaction data Trsv to the mobile devices B and C, which are other mobile devices (S103). As a result, the mobile devices B and C acquire the reserved transaction data Trsv.
  • each of the mobile devices A, B, and C executes a verification algorithm that performs verification including the validity of the acquired reserved transaction data Trsv (S104). If the verification of the reserved transaction data Trsv is not successful, the reservation process is terminated.
  • the mobile devices A, B, and C each store the reserved transaction data Trsv verified by the verification algorithm executed in step S104 in the transaction pool (S105). More specifically, the mobile device A stores the verified reserved transaction data Trsv in the transaction pool a, and the mobile device B stores the verified reserved transaction data Trsv in the transaction pool b. The mobile device C stores the verified reserved transaction data Trsv in the transaction pool c.
  • the mobile devices A, B, and C are in a state of being able to communicate with each other, information on transaction data to be stored in the block to be generated next is exchanged (S106).
  • the mobile devices A, B, and C confirm that the transaction data to be stored in the block to be generated next includes the verified reserved transaction data Trsv.
  • the mobile devices A, B, and C each generate a block Blc (Trsv) containing the verified reserved transaction data Trsv (S107).
  • the mobile devices A, B, and C each transmit the block Blc (Trsv) generated in step S107 to the other mobile devices (S108). Thereby, each of the mobile devices A, B, and C can notify the other mobile devices of the report that the verification of the validity of the reserved transaction data Trsv contained in the block Blc (Trsv) has been successful. ..
  • the mobile devices A, B, and C jointly execute the consensus algorithm (S109). Specifically, the mobile devices A, B, and C each agree that the reserved transaction data Trsv is legitimate transaction data (that is, legitimacy) based on the report notified in step S108, and block Blc (that is, legitimacy). Agree on the legitimacy of Trsv). In the example shown in FIG. 10, it is agreed that the reserved transaction data Trsv included in the block Blc (Trsv) is legitimate transaction data (that is, legitimacy), and the legitimacy of the block Blc (Trsv) is also agreed.
  • the processes of steps S107 and S108 may be performed when the consensus algorithm is executed in step S109.
  • the mobile devices A, B, and C each connect the block Blc (Trsv) agreed in step S109 to the blockchain in the distributed ledger (S110). More specifically, the mobile device A connects the agreed block Blc (Trsv) to the blockchain in the ledger A, and the mobile device B connects the agreed block Blc (Trsv) in the ledger B. Connect to the blockchain. The mobile device C connects the agreed block Blc (Trsv) to the blockchain in the ledger C.
  • a block including the reservation transaction data Trsv for making a reservation for using the mobile body A is stored in each of the ledger A, the ledger B, and the ledger C.
  • FIG. 11 is a sequence diagram showing a system lending process according to the first example of the comparative example.
  • the terminal A transmits an unlock request for the mobile body A to the mobile body device A based on the operation of the user who wants to use the mobile body A (S301).
  • an application is introduced as an input unit 1101 in the terminal A, that is, the terminal 11A, and the application may generate and transmit an unlock request for the mobile body A based on the operation of the user.
  • the unlock request for the mobile body A includes information such as a user's reservation ID that can identify the reservation for the corresponding mobile body A.
  • the mobile device A when the mobile device A receives the unlock request transmitted in step S301, it confirms whether the blockchain of the ledger A has a reservation corresponding to the unlock request (S302).
  • the mobile device A may confirm whether or not there is a reservation corresponding to the unlocking request by confirming whether or not there is reserved transaction data Trsv in the blockchain of the ledger A.
  • the mobile device A since the reservation transaction data Trsv is included in the blockchain of the ledger A, the mobile device A can confirm that the blockchain of the ledger A has a reservation corresponding to the unlock request.
  • the mobile device A unlocks the mobile device A (S303).
  • the mobile device A may unlock the mobile A by instructing the device that manages the lock of the mobile A to release the lock of the mobile A, or directly unlocks the mobile A. You may.
  • the mobile device A generates lending transaction data Trnt indicating the start of lending of the mobile A, triggered by the unlocking of the mobile A (S304).
  • the lending transaction data Trnt includes a lending start time as well as a user ID for using the mobile body A.
  • the lending start time is, for example, the time when the lock is released.
  • the mobile device A transfers the lending transaction data Trnt to the mobile devices B and C, which are other mobile devices (S305). As a result, the mobile devices B and C acquire the lending transaction data Trnt.
  • the mobile devices A, B, and C each execute a verification algorithm that performs verification including the validity of the loan transaction data Trnt (S306).
  • the mobile devices A, B, and C each store the loan transaction data Trnt verified by the verification algorithm executed in step S306 in the transaction pool (S307). More specifically, the mobile device A stores the verified lending transaction data Trnt in the transaction pool a, and the mobile device B stores the verified lending transaction data Trnt in the transaction pool b. The mobile device C stores the verified lending transaction data Trnt in the transaction pool c.
  • the mobile devices A, B, and C are in a state of being able to communicate with each other, information on transaction data to be stored in the block to be generated next is exchanged (S308).
  • the mobile devices A, B, and C confirm that the transaction data to be stored in the block to be generated next includes the verified loan transaction data Trnt.
  • the mobile devices A, B, and C each generate a block Blc (Trnt) containing the verified lending transaction data Trnt (S309).
  • the mobile devices A, B, and C each transmit the block Blc (Trnt) generated in step S309 to the other mobile devices (S310). Thereby, each of the mobile devices A, B, and C can notify the other mobile devices of the report that the verification of the validity of the loan transaction data Trnt contained in the block Blc (Trnt) has been successful. ..
  • the mobile devices A, B, and C jointly execute the consensus algorithm (S311). Specifically, the mobile devices A, B, and C each agree that the lending transaction data Trnt is legitimate transaction data (that is, legitimacy) based on the report notified in step S310, and block Blc (that is, legitimacy). Agree on the legitimacy of Trnt). In the example shown in FIG. 11, it is agreed that the lending transaction data Trnt contained in the block Blc (Trnt) is legitimate transaction data (that is, legitimacy), and the legitimacy of the block Blc (Trnt) is also agreed.
  • the processes of steps S309 and S310 may be performed when the consensus algorithm is executed in step S311.
  • the mobile devices A, B, and C each connect the block Blc (Trnt) agreed in step S311 to the blockchain in the distributed ledger (S312). More specifically, the mobile device A connects the agreed block Blc (Trnt) to the blockchain in the ledger A, and the mobile device B connects the agreed block Blc (Trnt) in the ledger B. Connect to the blockchain. The mobile device C connects the agreed block Blc (Trnt) to the blockchain in the ledger C.
  • a block containing the lending transaction data Trnt is stored in each of the ledger A, the ledger B, and the ledger C, and it is recorded that the mobile body A has started lending.
  • FIG. 12 is a sequence diagram showing a system return process according to the first example of the comparative example.
  • the moving body device A confirms that the moving body A has been returned (S501).
  • the user A puts the moving body A in a predetermined return facility, or puts the moving body A in a predetermined position and presses the return button of the UI of the moving body device A, so that the moving body A Can be returned.
  • the user A may return the mobile body A by pressing the return button of the UI displayed on the terminal A.
  • the mobile device A may confirm that the mobile A has been returned by inputting a message to the effect that the mobile A has been returned by the predetermined return facility or the terminal A, or the mobile device A may confirm that the mobile device A has been returned. It may be confirmed that the moving body A has been returned by pressing the return button of the UI of A.
  • the mobile device A generates the return transaction data Trtn indicating the completion of the return of the mobile A, triggered by the confirmation that the mobile A has been returned (S502).
  • the return transaction data Trtn includes a user ID for using the mobile body A, a return time, and a reservation ID for using the mobile body A.
  • the return time is, for example, the time when the mobile device A confirms that the mobile A has been returned. It should be noted that the return transaction data Trtn is not limited to the case of including it in the reservation ID, and may include information capable of calculating the usage fee of the user's mobile body A.
  • the mobile device A transfers the return transaction data Trtn to the mobile devices B and C, which are other mobile devices (S503).
  • the mobile devices B and C acquire the return transaction data Trtn.
  • the mobile devices A, B, and C each execute a verification algorithm that performs verification including the validity of the acquired return transaction data Trtn (S504).
  • the mobile devices A, B, and C each store the returned transaction data Trtn verified by the verification algorithm executed in step S504 in the transaction pool (S505). More specifically, the mobile device A stores the verified return transaction data Trtn in the transaction pool a, and the mobile device B stores the verified return transaction data Trtn in the transaction pool b. The mobile device C stores the verified return transaction data Trtn in the transaction pool c.
  • the mobile devices A, B, and C are in a state of being able to communicate with each other, information on transaction data to be stored in the block to be generated next is exchanged. In the example shown in FIG. 12, the mobile devices A, B, and C confirm that the transaction data to be stored in the block to be generated next includes the verified return transaction data Trtn.
  • the mobile devices A, B, and C each generate a block Blc (Trtn) containing the verified return transaction data Trtn (S506).
  • the mobile devices A, B, and C each transmit the block Blc (Trtn) generated in step S506 to the other mobile devices (S507).
  • each of the mobile devices A, B, and C can notify the other mobile device of the report that the verification of the validity of the return transaction data Trtn contained in the block Blc (Trtn) has been successful. ..
  • the mobile devices A, B, and C jointly execute the consensus algorithm (S508). Specifically, the mobile devices A, B, and C each agree that the returned transaction data Trtn is legitimate transaction data (that is, legitimacy) based on the report notified in step S507, and block Blc (that is, legitimacy). Agree on the legitimacy of Trtn). In the example shown in FIG. 12, it is agreed that the returned transaction data Trtn included in the block Blc (Trtn) is legitimate transaction data (that is, legitimacy), and the legitimacy of the block Blc (Trtn) is also agreed.
  • the processes of steps S506 and S507 may be performed when the consensus algorithm is executed in step S508.
  • each of the mobile devices A, B, and C connects the block Blc (Trnt) agreed in step S508 to the blockchain in the distributed ledger (S509). More specifically, the mobile device A connects the agreed block Blc (Trtn) to the blockchain in the ledger A, and the mobile device B connects the agreed block Blc (Trtn) in the ledger B. Connect to the blockchain. The mobile device C connects the agreed block Blc (Trtn) to the blockchain in the ledger C. As a result, as shown in FIG. 9C, a block including the return transaction data Trtn is stored in each of the ledger A, the ledger B, and the ledger C, and the completion of the return of the mobile body A is recorded.
  • each of the mobile devices A, B, and C each check the reservation information stored in the blockchain (S510). More specifically, each of the mobile devices A, B, and C causes the blockchain to execute the reservation smart contract by connecting the block containing the return transaction data Trtn to the blockchain in its own ledger. Confirm that the reserved transaction data Trsv exists as the stored reservation information.
  • the mobile devices A, B, and C each execute a charge calculation algorithm (S511).
  • the collection of charges using the mobile body A is executed.
  • the charge calculation algorithm may be included in the reservation smart contract or may be included in the charge collection smart contract.
  • the mobile devices A, B, and C each execute a charge collection smart contract or a reservation smart contract to collect a charge for the usage reservation of the mobile A included in the reservation transaction data Trsv. May be good.
  • the execution of the charge calculation algorithm has been described as part of the return process in the example shown in FIG. 12, but the present invention is not limited to this.
  • the charge calculation process shown in FIG. 8 may be performed.
  • FIG. 13 is a flowchart for explaining the details of the charge calculation process of the system according to the comparative example.
  • the processing is performed by the mobile device A will be described as a representative.
  • step S7 shown in FIG. 8 first, the mobile device A confirms whether or not there is a trigger for collecting charges (S71).
  • This trigger may be that a certain interval has elapsed, or that the return transaction data Trtn is included in the block newly connected to the blockchain of the ledger A.
  • step S71 when there is a trigger (Yes in S71), the mobile device A searches the blockchain of the ledger A (S72). In step S71, when there is no trigger (No in S71), the mobile device A returns to step S71.
  • the mobile device A confirms whether there are other reservations (that is, duplicate reservations) in the blockchain of the ledger A (S73).
  • step S73 when there is a duplicate reservation (Yes in S73), it is confirmed whether or not the reservation ID included in the reservation, that is, the return transaction data Trtn is the first among the duplicate reservations (S74). In step S73, when there is no duplicate reservation (No in S73), the process proceeds to step S75.
  • step S74 when the duplicate reservation is the first (Yes in S74), the mobile device A executes the charge calculation algorithm (S75). As a result, the charge for the reservation ID indicating the usage reservation of the mobile body A included in the reservation, that is, the return transaction data Trtn is calculated. In step S74, when the duplicate reservation is not the first (No in S74), the charge calculation process is terminated.
  • the mobile device A executes the charge collection process (S76). As a result, a fee for using the mobile body A is collected for the reservation ID indicating the usage reservation of the mobile body A made by the user. A process of collecting a charge may be performed on the usage reservation of the mobile body A included in the reserved transaction data Trsv.
  • FIG. 14 is a flowchart showing an operation outline of normal processing of the system according to the second example of the comparative example.
  • FIG. 14 shows a normal process in which the reservation process, the lending process, and the return process for the mobile device A are normally performed when the mobile device A is in the offline state and the mobile devices B and C are in the online state.
  • 15A to 17 are diagrams for conceptually explaining the blockchain stored in the ledger A of the mobile device A and the ledger B of the mobile device B.
  • FIG. 15A is a diagram conceptually showing a block of a block chain stored in the ledger A by the operation of step S1A of FIG. FIG.
  • FIG. 15B is a diagram conceptually showing the blocks of the blockchain stored in the ledger A by the operation of step S3A of FIG.
  • FIG. 15C is a diagram conceptually showing a block of a block chain stored in the ledger A by the operation of step S5A of FIG. 16 and 17 are diagrams for conceptually explaining the blocks of the block chain stored in the ledger A and the ledger B by the operation of step S6A of FIG.
  • a user who wants to use the mobile body A uses the terminal A to perform processing on the mobile body device A mounted on the mobile body A.
  • the terminal A communicates with the mobile device A in a non-communicable (offline) state with the other mobile devices B and C, and the mobile device A in the offline state is mounted.
  • the reservation process of the moving body A is performed (S1A). That is, the terminal A performs a reservation process for locally reserving the mobile body A with respect to the mobile body device A in the offline state. More specifically, the terminal A communicates with the mobile device A, generates reservation transaction data Trsv for making a reservation for using the mobile device A, and transmits the reserved transaction data Trsv to the mobile device A.
  • the reservation transaction data for making a reservation for using the mobile device A only in the ledger A.
  • the block containing the Trsv is stored.
  • the terminal A communicates with the mobile device A in the offline state and performs the lending process of the mobile A (S3A). That is, the terminal A performs a lending process of locally lending the mobile body A to the mobile body device A in the offline state. More specifically, the terminal A can communicate with the mobile device A and transmit an unlock request for the mobile A to use the mobile A. Then, the mobile device A unlocks the mobile A, unlocks the mobile A, and generates lending transaction data Trnt indicating the start of lending of the mobile A. In this case, for example, as shown in FIG. 15B, since the mobile device A is in the offline state, a block including the lending transaction data Trnt indicating the lending start of the mobile A is stored only in the ledger A.
  • the terminal A communicates with the mobile device A in the offline state and performs a return process of the mobile device A (S5A). That is, the terminal A performs a return process for locally returning the mobile device A to the mobile device A in the offline state. More specifically, the user who operates the terminal A uses the unlocked mobile body A for the reserved time and then returns it. When the mobile body A is returned, the mobile body device A generates return transaction data Trtn indicating that the return of the mobile body A is completed. In this case, for example, as shown in FIG. 15C, since the mobile device A is in the offline state, a block including the return transaction data Trtn indicating the completion of the return of the mobile A is stored only in the ledger A.
  • the mobile device A After that, it is assumed that the mobile device A returns to the online state. Then, when the mobile device A returns to the online state, the return processing is performed in the system (S6A). More specifically, in steps S1A to S5A, as described above, the mobile device A is in a non-communication (offline) state with the mobile device B. Therefore, as shown in FIG. 16A, when the mobile device A returns to the online state, different blocks are connected to the blockchains of the ledger A and the ledger B. Next, when the mobile device A returns to the online state, as shown in FIG. 16B, the ledger A of the mobile device A and the ledger B of the mobile device B share different block chains. And a fork is generated.
  • the block connected to the blockchain of the ledger A of the mobile device A in the offline state corresponds to the side chain block
  • the block connected to the blockchain of the ledger B of the mobile device B in the online state is the main chain.
  • the side chain block is deleted and the transaction data included in the side chain block is deleted. Is stored in the transaction pool, which eliminates the fork.
  • the reserved transaction data Trsv, the lending transaction data Trnt, and the returning transaction data Trntn are stored in the transaction pool.
  • the transaction data stored in the transaction pool is stored at the timing of generating a new block. Blocks containing are generated and concatenated.
  • step S7 the charge calculation process is performed (S7). Since the charge calculation process in step S7 is as described above, the description thereof will be omitted.
  • step S1A the details of the reservation process of step S1A, the lending process of step S3A, and the return process of S5A shown in FIG. 14, that is, the detailed processes of local reservation, local lending, and local return will be described with reference to the sequence diagram. Further, the details of the process at the time of returning the communication of the mobile device A in step S6A shown in FIG. 14 will also be described with reference to the sequence diagram.
  • a user who wants to use the mobile body A uses the terminal A to perform reservation processing, lending processing, and return processing of the mobile body A with respect to the mobile body device A mounted on the mobile body A.
  • FIG. 18 is a sequence diagram showing a system reservation process, that is, a local reservation process, according to the second example of the comparative example.
  • the same elements as those in FIG. 10 are designated by the same reference numerals, and detailed description thereof will be omitted.
  • the terminal A generates the reserved transaction data Trsv for making a reservation for using the mobile body A based on the operation of the user who wants to use the mobile body A (S101), and the generated reserved transaction data Trsv is used as the mobile device A. (S102).
  • the mobile device A when the mobile device A receives the reserved transaction data Trsv transmitted in step S102, it attempts to transfer the reserved transaction data Trsv to the mobile devices B and C, which are other mobile devices, but fails. (S103A). This is because the mobile device A is in the offline state, so that the reserved transaction data Trsv cannot be transferred to the mobile devices B and C. Therefore, the mobile devices B and C do not acquire the reserved transaction data Trsv.
  • the mobile device A executes a verification algorithm that performs verification including the validity of the acquired reserved transaction data Trsv (S104). If the verification of the reserved transaction data Trsv is not successful, the reservation process is terminated.
  • the mobile device A stores the reserved transaction data Trsv verified by the verification algorithm executed in step S104 in the transaction pool a (S105).
  • the mobile device A generates a block Blc (Trsv) including the verified reserved transaction data Trsv (S107). Since the mobile device A is in the offline state, the block Blc (Trsv) is generated without exchanging the transaction data information to be stored in the block to be generated next with the mobile devices B and C.
  • the mobile device A attempts to transmit the block Blc (Trsv) generated in step S107 to the mobile devices B and C, which are other mobile devices, but fails (S108A). This is because the mobile device A cannot transmit the block Blc (Trsv) to the mobile devices B and C because it is in the offline state.
  • the mobile device A independently executes the consensus algorithm (S109A). Specifically, the mobile device A independently agrees that the reserved transaction data Trsv is legitimate transaction data (that is, legitimacy), and independently agrees on the legitimacy of the block Blc (Trsv). In the example shown in FIG. 18, the mobile device A agrees that the reserved transaction data Trsv included in the block Blc (Trsv) is legitimate transaction data (that is, legitimacy), so that the block Blc (Trsv) I also agree on the legitimacy.
  • the process of step S107 may be performed when the consensus algorithm is executed independently in step S109A.
  • the mobile device A connects the block Blc (Trsv) agreed in step S109A to the blockchain in the ledger A (S110).
  • a block including the reservation transaction data Trsv for making a reservation for using the mobile body A is stored only in the ledger A, and the reservation is confirmed.
  • self-contained reservation is confirmed only by the offline ledger A, which is hereinafter referred to as local reservation.
  • FIG. 19 is a sequence diagram showing a system lending process, that is, a local lending process, according to the second example of the comparative example.
  • the same elements as those in FIG. 11 are designated by the same reference numerals, and detailed description thereof will be omitted.
  • the terminal A transmits an unlock request for the mobile body A to the mobile body device A based on the operation of the user who wants to use the mobile body A (S301).
  • the mobile device A when the mobile device A receives the unlock request transmitted in step S301, it confirms whether the blockchain of the ledger A has a reservation corresponding to the unlock request (S302), and locks the mobile A. Is released (S303).
  • the mobile device A generates lending transaction data Trnt indicating the start of lending of the mobile A, triggered by the unlocking of the mobile A (S304).
  • the mobile device A attempts to transfer the lending transaction data Trnt to the other mobile devices B and C, but fails (S305A). This is because the mobile device A is in the offline state, so that the loan transaction data Trnt cannot be transferred to the mobile devices B and C. Therefore, the mobile devices B and C do not acquire the lending transaction data Trnt.
  • the mobile device A executes a verification algorithm that performs verification including the validity of the loan transaction data Trnt (S306).
  • the mobile device A stores the loan transaction data Trnt verified by the verification algorithm executed in step S306 in the transaction pool a (S307).
  • each mobile device A generates a block Blc (Trnt) containing the verified lending transaction data Trnt (S309). Since the mobile device A is in the offline state, the block Blc (Trnt) is generated without exchanging the transaction data information to be stored in the block to be generated next with the mobile devices B and C.
  • the mobile device A attempts to transmit the block Blc (Trnt) generated in step S309 to the mobile devices B and C, which are other mobile devices, but fails (S310A). This is because the mobile device A cannot transmit the block Blc (Trnt) to the mobile devices B and C because it is in the offline state.
  • the mobile device A independently executes the consensus algorithm (S311A). Specifically, the mobile device A independently agrees that the loan transaction data Trnt is legitimate transaction data (that is, legitimacy), and independently agrees on the legitimacy of the block Blc (Trnt). In the example shown in FIG. 19, the mobile device A agrees that the lending transaction data Trnt contained in the block Blc (Trnt) is legitimate transaction data (that is, legitimacy), so that the block Blc (Trnt) I also agree on the legitimacy.
  • the process of step S309 may be performed when the consensus algorithm is executed in step S311.
  • the mobile device A connects the block Blc (Trnt) agreed in step S311A to the blockchain in the ledger A (S312).
  • the block including the lending transaction data Trnt is stored only in the ledger A, and it is recorded that the mobile body A has started lending.
  • the fact that the mobile body A is self-contained and the start of lending is recorded only by the ledger A in the offline state is hereinafter referred to as local lending.
  • FIG. 20 is a sequence diagram showing a return process of the system according to the second example of the comparative example.
  • the same elements as those in FIG. 12 are designated by the same reference numerals, and detailed description thereof will be omitted.
  • the moving body device A confirms that the moving body A has been returned (S501).
  • the mobile device A generates the return transaction data Trtn indicating the completion of the return of the mobile A, triggered by the confirmation that the mobile A has been returned (S502).
  • the mobile device A attempts to transfer the return transaction data Trtn to the other mobile devices B and C, but fails (S503A). This is because the mobile device A is in the offline state, so that the return transaction data Trtn cannot be transferred to the mobile devices B and C. Therefore, the mobile devices B and C do not acquire the return transaction data Trtn.
  • the mobile device A executes a verification algorithm that performs verification including the validity of the acquired return transaction data Trtn (S504).
  • the mobile device A stores the returned transaction data Trtn verified by the verification algorithm executed in step S504 in the transaction pool a (S505).
  • the mobile device A generates a block Blc (Trtn) including the verified return transaction data Trtn (S506). Since the mobile device A is in the offline state, the block Blc (Trtn) is generated without exchanging the transaction data information to be stored in the block to be generated next with the mobile devices B and C.
  • the mobile device A attempts to transmit the block Blc (Trtn) generated in step S506 to the mobile devices B and C, which are other mobile devices, but fails (S507A). This is because the mobile device A cannot transmit the block Blc (Trtn) to the mobile devices B and C because it is in the offline state.
  • the mobile device A independently executes the consensus algorithm (S508A). Specifically, the mobile device A independently agrees that the returned transaction data Trtn is legitimate transaction data (that is, legitimacy), and independently agrees on the legitimacy of the block Blc (Trtn). In the example shown in FIG. 20, the mobile device A agrees that the returned transaction data Trtn included in the block Blc (Trtn) is legitimate transaction data (that is, legitimacy), so that the block Blc (Trtn) has a legitimate transaction data. I also agree on the legitimacy.
  • the process of step S506 may be performed when the consensus algorithm is executed in step S508A.
  • the mobile device A connects the block Blc (Trtn) agreed in step S508A to the blockchain in the ledger A (S509).
  • the block including the return transaction data Trtn is stored only in the ledger A, and the completion of the return of the mobile body A is recorded.
  • self-contained recording of the completion of the return of the moving body A only with the ledger A in the offline state is hereinafter referred to as local return.
  • the mobile device A checks the reservation information stored in the blockchain (S510). More specifically, each of the mobile devices A, B, and C executes the reservation smart contract by connecting the return transaction data Trtn to the blockchain in its own ledger, and is stored in the blockchain. Confirm that the reserved transaction data Trsv exists as the reserved information.
  • the mobile device A executes the charge calculation algorithm (S511).
  • FIG. 21 is a sequence diagram showing the processing of the system performed when the communication of the mobile device A according to the second example of the comparative example is restored.
  • the mobile device A has returned to a communicable state (online state) with the mobile devices B and C, which are other mobile devices (S601). Since the mobile device A is mounted on the mobile A, it may go offline or online depending on the location of the mobile A.
  • the mobile device A transmits a signal to the mobile devices B and C, which are other mobile devices (S602).
  • the signal may be any signal that can notify that the mobile device A is online.
  • the mobile devices A, B, and C determine the difference between the blockchains in each ledger (S603). More specifically, the mobile device A determines the difference between the blockchain in the ledger A and the blockchain in the ledgers B and C of the other mobile devices B and C. The mobile devices B and C determine the difference between the blockchain in the ledgers B and C and the blockchain in the ledger A of the mobile device A which is another mobile device.
  • different blocks are connected to the blockchains of the ledger A and the ledgers B and C, and the blockchain in the ledger A and the ledgers B and C are included. It is different from the blockchain of. Therefore, as shown in the example shown in FIG. 16B, the mobile devices A, B, and C share different blockchains in the ledgers A, B, and C, so that a fork is generated.
  • the mobile devices A, B, and C transmit information about the blocks corresponding to the side chain block and the main chain block (S604, S605).
  • the block connected to the blockchain of the ledger A of the mobile device A that has been offline for a certain period of time corresponds to the side chain block.
  • the blocks connected to the blockchains of the ledgers B and C of the mobile devices B and C correspond to the main chain blocks.
  • the mobile devices A, B, and C each store the transaction data Tpol of the side chain block obtained in step S604 in the transaction pool (S606). More specifically, the mobile device A stores a copy of the transaction data Tpol of the side chain block connected to the blockchain of the ledger A in the transaction pool a. The mobile device B stores the transaction data Tpol of the side chain block in the transaction pool b, and the mobile device C stores the transaction data Tpol of the side chain block in the transaction pool c.
  • the mobile devices A, B, and C are updated so that they are the same as the blockchains of the ledgers A, B, and C, respectively (S607). More specifically, the mobile device A deletes the side chain block connected to the blockchain of the ledger A and leaves the main chain block so that it becomes the same as the blockchain of the ledgers B and C. Update the blockchain of ledger A.
  • the mobile device B deletes the side chain block connected to the blockchain of the ledger B and leaves the main chain block, so that the blockchain of the ledger B becomes the same as the blockchain of the ledger A and C. Update.
  • the mobile device C deletes the side chain block connected to the blockchain of the ledger C and leaves the main chain block, so that the blockchain of the ledger C becomes the same as the blockchain of the ledger A and B. Update.
  • the mobile devices A, B, and C each generate a block Blc (Tpol) including the transaction data Tpol stored in the transaction pool (S614).
  • the mobile devices A, B, and C each transmit the block Blc (Tpol) generated in step S614 to the other mobile devices (S615).
  • the mobile devices A, B, and C jointly execute the consensus algorithm (S616). Specifically, the mobile devices A, B, and C each agree that the transaction data Tpol is legitimate transaction data (that is, legitimacy), and agree the legitimacy of the block Blc (Tpol). In the example shown in FIG. 21, it is agreed that the transaction data Tpol included in the block Blc (Tpol) is legitimate transaction data (that is, legitimacy), and the legitimacy of the block Blc (Tpol) is also agreed.
  • the processes of steps S614 and S615 may be performed when the consensus algorithm is executed in step S616.
  • each of the mobile devices A, B, and C connects the block Blc (Tpol) agreed in step S616 to the blockchain in the distributed ledger (S617). More specifically, the mobile device A connects the agreed block Blc (Tpol) to the blockchain in the ledger A, and the mobile device B connects the agreed block Blc (Tpol) in the ledger B. Connect to the blockchain. The mobile device C connects the agreed block Blc (Tpol) to the blockchain in the ledger C. As a result, as shown in FIG. 17 (c), a block containing the reserved transaction data Trsv, the lending transaction data Trnt, and the returning transaction data Trntn is stored, and the local reservation, local lending, and local return of the mobile unit A are recorded. Will be done.
  • the mobile device A checks the reservation information stored in the blockchain (S620). More specifically, each of the mobile devices A, B, and C causes the blockchain to execute the reservation smart contract by connecting the block containing the return transaction data Trtn to the blockchain in its own ledger. Confirm that the reserved transaction data Trsv exists as the stored reservation information.
  • step S621 Since the process of step S621 is the same as the process of step S511 described above, the description thereof will be omitted.
  • FIG. 22 is a flowchart for explaining the block connection process of the system according to the comparative example.
  • the block connection process is performed by the mobile device A will be described as a representative.
  • the mobile device A acquires or generates transaction data (S1001), it executes a verification algorithm that verifies the acquired or generated transaction data (S1002).
  • the mobile device A stores the transaction data verified by the verification algorithm executed in step S1002 in the transaction pool (S1003).
  • the mobile device A confirms whether there is a trigger for connecting the blocks in the blockchain of the ledger A (S1004).
  • the trigger here is that a certain interval such as several minutes has passed.
  • step S1004 when there is a trigger (Yes in S1004), the mobile device A confirms whether it can communicate with another mobile (S1005). In step S1004, when there is no trigger (No in S1004), the process is repeated from step S1001.
  • step S1005 when the mobile device A cannot communicate with another mobile body, that is, when it is in an offline state (No in S1005), the mobile device A independently executes the consensus algorithm (S1006).
  • the mobile device A generates a block of the block chain including the acquired or generated transaction data, and executes a consensus algorithm to form a consensus.
  • the mobile device A may verify the validity of the acquired or generated transaction data and generate a block containing the transaction data.
  • the mobile device A connects the generated block to the blockchain of the ledger A (S1007).
  • step S1005 when the mobile device A can communicate with another mobile (Yes in S1005), the mobile device A executes a consensus algorithm jointly with the other mobile (S1008). Each of the mobile device A and the other mobiles generates a block of the block chain containing the transaction data, and executes a consensus algorithm to form a consensus on the generated block.
  • the mobile device A determines whether or not the blockchain of the ledger A and the blockchain in the ledger of another mobile are the same (S1009).
  • step S1009 in the same case (Yes in S1009), the mobile device A connects the agreed blocks to the blockchain of the ledger A (S1010).
  • step S1009 if they are not the same (No in S1009), the transaction data of the side chain block, that is, the side chain block is stored in the transaction pool (S1011).
  • the mobile device A updates the blockchain of the ledger A so that it becomes the same as the blockchain in the ledger of another mobile (S1012).
  • the mobile device A connects the blocks agreed in step S1009 to the blockchain of the ledger A (S1013).
  • FIG. 23 is a flowchart showing an outline of the operation of the illegal processing of the system according to the third example of the comparative example.
  • 24A to 27 are diagrams for conceptually explaining the blockchain stored in the ledger A of the mobile device A and the ledger B of the mobile device B.
  • FIG. 24A is a diagram conceptually showing the blocks of the block chain stored in the ledger A by the operation of step S10 of FIG. 23.
  • FIG. 24B is a diagram conceptually showing the blocks of the block chain stored in the ledger A by the operation of step S11 of FIG. 23.
  • FIG. 24C is a diagram conceptually showing the blocks of the block chain stored in the ledger A by the operation of step S12 of FIG. 23.
  • FIG. 25 and 26 are diagrams for conceptually explaining the blocks of the block chain stored in the ledger A and the ledger B by the operation of step S13 of FIG. 23.
  • FIG. 27 is a diagram conceptually showing the blocks of the block chain stored in the ledger A and the ledger B by the operation of step S14 of FIG. 23.
  • a user who wants to use the mobile body A uses the terminal A to perform illegal processing on the mobile body device A mounted on the mobile body A.
  • the terminal A performs a reservation process for the mobile device A on which the mobile device A is mounted (S10) with respect to the mobile device A in the offline state.
  • the terminal A performs a reservation process for locally reserving the mobile body A with respect to the mobile body device A in the offline state.
  • the terminal A can communicate with the mobile device A, generate reserved transaction data TrsvA for making a reservation for using the mobile device A, and transmit the reserved transaction data TrsvA to the mobile device A.
  • a block including the reservation transaction data TrsvA for making a reservation for using the mobile A is stored only in the ledger A.
  • the mobile device B in the online state is moved so as to cover the time zone of the local reservation of the mobile A performed in step S10 by some means such as using the terminal A or the user's personal smartphone.
  • the reservation process of the body A is performed (S11). That is, the conflict reservation process of the mobile body A is performed so as to conflict with the local reservation of the mobile body A for the mobile device B in the online state.
  • the user uses the terminal A to generate reserved transaction data TrsvB for competing reservation of the mobile body A and transmits the reserved transaction data TrsvB to the mobile device B in the online state.
  • the mobile device B or the like sets the reserved transaction data TrsvB for competing reservation of the mobile body A in the ledger B or the like excluding the ledger A of the mobile device A which is offline. Contains blocks are stored.
  • the terminal A communicates with the mobile device A in the offline state and performs the lending process of the mobile A (S12). That is, as described above, the terminal A performs a lending process of locally lending the mobile body A to the mobile body device A in the offline state. More specifically, the terminal A communicates with the mobile device A and transmits an unlock request for the mobile A to use the mobile A, thereby unlocking the mobile A to the mobile device A. Then, when the mobile body A is unlocked, the lending transaction data TrntA indicating the start of lending of the mobile body A is generated. In this case, for example, as shown in FIG. 24C, since the mobile device A is in the offline state, a block including the lending transaction data TrntA indicating the lending start of the mobile A is stored only in the ledger A.
  • the user supposes that the mobile device A is returned to the online state. Then, when the mobile device A returns to the online state, the return processing is performed in the system (S13).
  • steps S10 to S12 since the mobile device A is in the offline state as described above, the mobile device A has returned to the online state as shown in FIG. 25 (a). At the time, different blocks are connected to the blockchains of ledger A and ledger B. Next, when the mobile device A returns to the online state, as shown in FIG. 25 (b), the ledger A of the mobile device A and the ledger B of the mobile device B share different block chains. And a fork is generated.
  • the block connected to the blockchain of the ledger A of the mobile device A in the offline state corresponds to the side chain block
  • the block connected to the blockchain of the ledger B of the mobile device B in the online state is the main chain. Corresponds to the block. Therefore, as shown in FIGS.
  • the terminal A communicates with the mobile device A in the online state and performs a return process of the mobile device A (S14). More specifically, the user who operates the terminal A uses the unlocked mobile body A for the reserved time and then returns it. When the mobile body A is returned, the mobile body device A generates return transaction data TrtnA indicating the completion of the return of the mobile body A. In this case, for example, as shown in FIG. 27, since the mobile device A is in the online state, a block including the return transaction data TrtnA indicating the completion of the return of the mobile A is stored in all of the ledgers A, B, and the like. NS.
  • the charge calculation process is performed (S15). Since the charge calculation process in step S15 is the same process as the charge calculation process in step S7, the description thereof will be omitted.
  • the reserved transaction data TrsvA and the reserved transaction data TrsvB are in conflict, and the block containing the reserved transaction data TrsvA is concatenated later than the block containing the reserved transaction data TrsvB.
  • the fraud that the charge using the mobile body A is not paid in the reservation corresponding to the reserved transaction data TrsvA is established.
  • step S10 the details of the local reservation process in step S10, the competitive reservation process in step S11, and the local lending process in step S12 shown in FIG. 23 will be described with reference to the sequence diagram.
  • FIG. 28 is a sequence diagram showing a process when a local reservation of the system according to the third example of the comparative example is performed.
  • the same elements as those in FIG. 18 are designated by the same reference numerals, and detailed description thereof will be omitted.
  • the terminal A generates the reserved transaction data TrsvA for making a reservation for using the mobile body A based on the operation of the user who wants to use the mobile body A (S101B), and uses the generated reserved transaction data TrsvA for the mobile device A. (S102B).
  • the mobile device A when the mobile device A receives the reserved transaction data TrsvA transmitted in step S102B, it attempts to transfer the reserved transaction data TrsvA to the mobile devices B and C, which are other mobile devices, but fails. (S103B). This is because the mobile device A is in the offline state, so that the reserved transaction data TrsvA cannot be transferred to the mobile devices B and C.
  • the mobile device A executes a verification algorithm that performs verification including the validity of the acquired reserved transaction data TrsvA (S104B).
  • the mobile device A stores the reserved transaction data TrsvA verified by the verification algorithm executed in step S104B in the transaction pool a (S105B).
  • the mobile device A generates a block Blc (TrsvA) including the verified reserved transaction data TrsvA (S107B).
  • the mobile device A attempts to transmit the block Blc (TrsvA) generated in step S107B to the mobile devices B and C, which are other mobile devices, but fails (S108B). This is because the mobile device A cannot transmit the block Blc (TrsvA) to the mobile devices B and C because it is in the offline state.
  • step S109B the mobile device A independently executes the consensus algorithm (S109B).
  • the process of step S107B may be performed when the consensus algorithm is executed independently in step S109B.
  • the mobile device A connects the block Blc (TrsvA) agreed in step S109B to the blockchain in the ledger A (S110B).
  • a block including the reservation transaction data TrsvA for making a reservation for using the mobile body A is stored only in the ledger A, and the local reservation is confirmed.
  • FIG. 29 is a sequence diagram showing a process when competing reservation of the system according to the third example of the comparative example is performed.
  • the user uses, for example, the terminal A to generate the reservation transaction data TrsvB for competing reservation of the mobile body A (S101C).
  • the user uses, for example, the terminal A to transmit the reserved transaction data TrsvB generated in step S101C to the mobile device B (S102C).
  • the mobile device B since the mobile device B is in the online state, when the reserved transaction data TrsvB transmitted in step S102C is received, the reserved transaction data TrsvB is transferred to the mobile device C, which is another mobile device (S103C). ). As a result, the mobile device C excluding the mobile device A acquires the reserved transaction data TrsvB.
  • the mobile devices B and C each execute a verification algorithm that performs verification including the validity of the acquired reserved transaction data TrsvB (S104C).
  • the mobile devices B and C each store the reserved transaction data TrsvB verified by the verification algorithm executed in step S104C in the transaction pool (S105C). More specifically, the mobile device B stores the verified reserved transaction data TrsvB in the transaction pool b, and the mobile device C stores the verified reserved transaction data TrsvB in the transaction pool c.
  • the mobile devices B and C are in a state of being able to communicate with each other, information on transaction data to be stored in the block to be generated next is exchanged (S106C).
  • the mobile devices B and C confirm that the transaction data to be stored in the block to be generated next includes the verified reserved transaction data TrsvB.
  • the mobile devices B and C each generate a block Blc (TrsvB) containing the verified reserved transaction data TrsvB (S107C).
  • the mobile devices B and C each transmit the block Blc (TrsvB) generated in step S107C to the other mobile devices other than the mobile device A (S108C).
  • the mobile devices B and C each notify the other mobile devices other than the mobile device A of the report that the verification of the validity of the reserved transaction data TrsvB included in the block Blc (TrsvB) has been successful. can do.
  • the mobile devices B and C jointly execute the consensus algorithm (S109C). Specifically, the mobile devices B and C each agree that the reserved transaction data TrsvB is legitimate transaction data (that is, legitimacy) based on the report notified in step S108C, and block Blc (TrsvB). Agree on the legitimacy of.
  • the processes of steps S107C and S108C may be performed when the consensus algorithm is executed in step S109C.
  • the mobile devices B and C each connect the block Blc (TrsvB) agreed in step S109C to the blockchain in the distributed ledger (S110C). More specifically, the mobile device B connects the agreed block Blc (TrsvB) to the blockchain in the ledger B, and the mobile device C connects the agreed block Blc (TrsvB) in the ledger C. Connect to the blockchain.
  • a block containing the reserved transaction data TrsvB is stored in both the ledger B and the ledger C.
  • FIG. 30 is a sequence diagram showing the processing of local lending of the system according to the third example of the comparative example.
  • the same elements as those in FIG. 19 are designated by the same reference numerals, and detailed description thereof will be omitted.
  • the terminal A transmits an unlock request for the mobile body A to the mobile body device A based on the operation of the user who uses the mobile body A (S301B).
  • step S301B when the mobile device A receives the unlock request transmitted in step S301B, it confirms whether the blockchain of the ledger A has a reservation corresponding to the unlock request (S302B), and locks the mobile A. Is released (S303B).
  • the mobile device A generates lending transaction data TrntA indicating the start of lending of the mobile A, triggered by the unlocking of the mobile A (S304B).
  • the mobile device A attempts to transfer the lending transaction data TrntA to the other mobile devices B and C, but fails (S305B). This is because the mobile device A is in the offline state, so that the loan transaction data TrntA cannot be transferred to the mobile devices B and C.
  • the mobile device A executes a verification algorithm that performs verification including the validity of the loan transaction data TrntA (S306B).
  • the mobile device A stores the loan transaction data TrntA verified by the verification algorithm executed in step S306B in the transaction pool a (S307B).
  • each mobile device A generates a block Blc (TrntA) containing the verified lending transaction data TrntA (S309B).
  • the mobile device A attempts to transmit the block Blc (TrntA) generated in step S309B to the mobile devices B and C, which are other mobile devices, but fails (S310B). This is because the mobile device A cannot transmit the block Blc (TrntA) to the mobile devices B and C because it is in the offline state.
  • the mobile device A independently executes the consensus algorithm (S311B). Specifically, the mobile device A independently agrees that the loan transaction data TrntA is legitimate transaction data (that is, legitimacy), and independently agrees on the legitimacy of the block Blc (TrntA).
  • the process of step S309B may be performed when the consensus algorithm is executed in step S311B.
  • the mobile device A connects the block Blc (TrntA) agreed in step S311B to the blockchain in the ledger A (S312B).
  • the block including the lending transaction data TrntA is stored only in the ledger A, and it is recorded that the mobile A is locally lent.
  • FIG. 31 is a sequence diagram showing the processing of the system performed when the communication of the mobile device A according to the third example of the comparative example is restored.
  • the same elements as those in FIG. 21 are designated by the same reference numerals, and detailed description thereof will be omitted.
  • the mobile device A has returned to a communicable state (online state) with the mobile devices B and C, which are other mobile devices (S601B).
  • the mobile device A transmits a signal indicating that the mobile device A is online to the other mobile devices B and C (S602B).
  • the mobile devices A, B, and C determine the difference between the blockchains in each ledger (S603B). More specifically, the mobile device A determines the difference between the blockchain in the ledger A and the blockchain in the ledgers B and C of the other mobile devices B and C. The mobile devices B and C determine the difference between the blockchain in the ledgers B and C and the blockchain in the ledger A of the mobile device A which is another mobile device.
  • different blocks are connected to the blockchains of the ledger A and the ledgers B and C, and the blockchain in the ledger A and the ledgers B and C are included. It is different from the blockchain of. Therefore, as shown in the example shown in FIG. 25 (b), in the mobile devices A, B, and C, different blockchains are shared in the ledgers A, B, and C, so that a fork is generated.
  • the mobile devices A, B, and C transmit information about the blocks corresponding to the side chain block and the main chain block (S604B, S605B).
  • the block connected to the blockchain of the ledger A of the mobile device A that has been offline for a certain period of time corresponds to the side chain block Blc (TrsvA, TrntA).
  • the block connected to the blockchain of the ledgers B and C of the mobile devices B and C corresponds to the main chain block Blc (TrsvB).
  • the mobile devices A, B, and C each store the reserved transaction data TrsvA and the lending transaction data TrntA included in the side chain block obtained in step S604B in the transaction pool (S606B). More specifically, the mobile device A stores in the transaction pool a a copy of the transaction data TrsvA and TrntA of the side chain blocks connected to the blockchain of the ledger A.
  • the mobile device B stores the transaction data TrsvA and TrntA of the side chain block in the transaction pool b, and the mobile device C stores the transaction data TrsvA and TrntA of the side chain block in the transaction pool c.
  • the mobile devices A, B, and C are updated so that they are the same as the blockchains of the ledgers A, B, and C, respectively (S607B). More specifically, the mobile device A deletes the side chain block connected to the blockchain of the ledger A and leaves the main chain block so that it becomes the same as the blockchain of the ledgers B and C. Update the blockchain of ledger A.
  • the mobile device B deletes the side chain block connected to the blockchain of the ledger B and leaves the main chain block, so that the blockchain of the ledger B becomes the same as the blockchain of the ledger A and C. Update.
  • the mobile device C deletes the side chain block connected to the blockchain of the ledger C and leaves the main chain block, so that the blockchain of the ledger C becomes the same as the blockchain of the ledger A and B. Update.
  • the mobile devices A, B, and C generate blocks Blc (TrsvA, TrntA) including transaction data TrsvA and TrntA stored in the transaction pool, respectively (S614B). ..
  • the mobile devices A, B, and C each transmit the block Blc (TrsvA, TrntA) generated in step S614B to the other mobile devices (S615B).
  • the mobile devices A, B, and C notify the other mobile devices of the successful verification of the validity of the transaction data TrsvA and TrntA contained in the block Blc (TrsvA, TrntA), respectively. be able to.
  • the mobile devices A, B, and C jointly execute the consensus algorithm (S616B). Specifically, the mobile devices A, B, and C each agree that the transaction data TrsvA and TrntA are legitimate transaction data (that is, legitimacy) based on the report notified in step S615B, and block Blc. Agree on the legitimacy of (TrsvA, TrntA).
  • the processing of steps S614B and S615B may be performed when the consensus algorithm is executed in step S616B.
  • each of the mobile devices A, B, and C connects the block Blc (TrsvA, TrntA) agreed in step S616B to the blockchain in the distributed ledger (S617B). More specifically, the mobile device A connects the agreed block Blc (TrsvA, TrntA) to the blockchain in the ledger A, and the mobile device B connects the agreed block Blc (TrsvA, TrntA). Connect to the blockchain in ledger B. The mobile device C connects the agreed block Blc (TrsvA, TrntA) to the blockchain in the ledger C. As a result, as shown in FIG. 26 (c), a block including the reserved transaction data TrsvA, the reserved transaction data TrsvB, and the lending transaction data TrntA is stored, and the local reservation, the competitive reservation, and the local lending of the mobile body A are recorded. Will be done.
  • FIG. 32 is a sequence diagram showing the return processing of the system according to the third example of the comparative example.
  • the same elements as those in FIG. 12 are designated by the same reference numerals, and detailed description thereof will be omitted.
  • the moving body device A confirms that the moving body A has been returned (S501B).
  • the mobile device A generates the return transaction data TrtnA indicating the completion of the return of the mobile A, triggered by the confirmation that the mobile A has been returned (S502B).
  • the mobile device A transfers the return transaction data TrtnA to the mobile devices B and C, which are other mobile devices (S503B). As a result, the mobile devices B and C acquire the return transaction data TrtnA.
  • the mobile devices A, B, and C each execute a verification algorithm that performs verification including the validity of the acquired return transaction data TrtnA (S504B).
  • the mobile devices A, B, and C each store the returned transaction data TrtnA verified by the verification algorithm executed in step S504B in the transaction pool (S505B). More specifically, the mobile device A stores the verified return transaction data TrtnA in the transaction pool a, and the mobile device B stores the verified return transaction data TrtnA in the transaction pool b. The mobile device C stores the verified return transaction data TrtnA in the transaction pool c.
  • the mobile devices A, B, and C are in a state of being able to communicate with each other, information on transaction data to be stored in the block to be generated next is exchanged. In the example shown in FIG. 32, the mobile devices A, B, and C confirm that the transaction data to be stored in the block to be generated next includes the verified return transaction data TrtnA.
  • the mobile devices A, B, and C each generate a block Blc (TrtnA) containing the verified return transaction data TrtnA (S506B).
  • the mobile devices A, B, and C each transmit the block Blc (TrtnA) generated in step S506B to the other mobile devices (S507B).
  • each of the mobile devices A, B, and C can notify the other mobile device of the report that the verification of the validity of the return transaction data TrtnA contained in the block Blc (TrtnA) has been successful. ..
  • the mobile devices A, B, and C jointly execute the consensus algorithm (S508B). Specifically, the mobile devices A, B, and C each agree that the returned transaction data TrtnA is legitimate transaction data (that is, legitimacy) based on the report notified in step S507B, and block Blc (that is, legitimacy). Agree on the legitimacy of TrtnA).
  • the processes of steps S506B and S507B may be performed when the consensus algorithm is executed in step S508B.
  • each of the mobile devices A, B, and C connects the block Blc (TrntA) agreed in step S508B to the blockchain in the distributed ledger (S509B). More specifically, the mobile device A connects the agreed block Blc (TrtnA) to the blockchain in the ledger A, and the mobile device B connects the agreed block Blc (TrtnA) in the ledger B. Connect to the blockchain. The mobile device C connects the agreed block Blc (TrtnA) to the blockchain in the ledger C. As a result, as shown in FIG. 27, the block including the return transaction data TrtnA is stored in each of the ledger A, the ledger B, and the ledger C, and the completion of the return of the mobile body A is recorded.
  • the mobile devices A, B, and C each check the reservation information stored in the blockchain (S510B). More specifically, the mobile devices A, B, and C each execute the reservation smart contract by connecting the block including the block containing the return transaction data TrtnA to the blockchain in its own ledger. Confirm that the reserved transaction data Trsv exists as the reserved information stored in the blockchain.
  • the mobile devices A, B, and C each execute a charge calculation algorithm (S511B).
  • a charge calculation algorithm S511B
  • the reserved transaction data TrsvA and the reserved transaction data TrsvB compete with each other, and the block containing the reserved transaction data TrsvA is temporally more than the block containing the reserved transaction data TrsvB. It is connected to the back behind. Therefore, even if the charge calculation algorithm is executed, the charge for the reservation corresponding to the reserved transaction data TrsvA is not collected, and only the charge for the reservation corresponding to the reserved transaction data TrsvB is collected. Become.
  • FIG. 33 is a flowchart showing an outline of the operation of the illegal processing of the system according to the fourth example of the comparative example.
  • 34A to 36 are diagrams for conceptually explaining the blockchain stored in the ledger A of the mobile device A and the ledger B of the mobile device B.
  • FIG. 34A is a diagram conceptually showing the blocks of the block chain stored in the ledger A by the operation of step S10 of FIG. 33.
  • FIG. 34B is a diagram conceptually showing the blocks of the block chain stored in the ledger A by the operation of step S11 of FIG. 33.
  • FIG. 34C is a diagram conceptually showing the blocks of the block chain stored in the ledger A by the operation of step S12 of FIG. 33.
  • 34D is a diagram conceptually showing the blocks of the block chain stored in the ledger A by the operation of step S13A of FIG. 33.
  • 35 and 36 are diagrams for conceptually explaining the blocks of the block chain stored in the ledger A and the ledger B by the operation of step S14A of FIG. 33.
  • the user who wants to use the mobile body A uses the terminal A to perform illegal processing on the mobile body device A mounted on the mobile body A.
  • steps S10 to S12 shown in FIG. 33 are the same processes as steps S10 to S12 described with reference to FIG. 23, the description thereof will be omitted. Further, since FIGS. 34A to 34C are the same views as those of FIGS. 24A to 24C, the description thereof will be omitted.
  • step S13A the terminal A communicates with the mobile device A in the offline state and performs a return process of the mobile device A. That is, the terminal A performs a return process for locally returning the mobile device A to the mobile device A in the offline state. More specifically, the user who operates the terminal A uses the unlocked mobile body A for the reserved time and then returns it. When the mobile body A is returned, the mobile body device A generates return transaction data TrtnA indicating the completion of the return of the mobile body A. In this case, for example, as shown in FIG. 34D, since the mobile device A is in the offline state, a block including the return transaction data TrtnA indicating the completion of the return of the mobile A is stored only in the ledger A.
  • the user supposes that the mobile device A is returned to the online state. Then, when the mobile device A returns to the online state, the return processing is performed in the system (S14A). More specifically, in steps S10 to S13A, since the mobile device A is in the offline state, when the mobile device A returns to the online state, for example, as shown in FIG. 34D, the ledger A and the ledger B Different blocks are connected to the blockchain of. Next, when the mobile device A returns to the online state, as shown in FIG. 35, the ledger A of the mobile device A and the ledger B of the mobile device B share different block chains, and a fork is provided. appear.
  • the block connected to the blockchain of the ledger A of the mobile device A in the offline state is shorter, it corresponds to the side chain block and is connected to the blockchain of the ledger B of the mobile device B in the online state. Since the block is long, it corresponds to the main chain block. Therefore, as shown in FIGS. 36A and 36B, in the ledger A of the mobile device A and the ledger B of the mobile device B, the side chain block is deleted and the transaction data included in the side chain block is deleted. Is stored in the transaction pool, which eliminates the fork. In FIG. 36B, the reserved transaction data TrsvA, the lending transaction data TrntA, and the returned transaction data TrtnA are stored in the transaction pool. After that, as shown in FIG. 36 (c), in the blockchain of the ledger A of the mobile device A and the ledger B of the mobile device B, the transaction data stored in the transaction pool is stored at the timing of generating a new block. Blocks containing are generated and concatenated.
  • the charge calculation process is performed (S15). Similar to the third example of the comparative example, the reserved transaction data TrsvA and the reserved transaction data TrsvB are in conflict, and the block containing the reserved transaction data TrsvA is concatenated after the block containing the reserved transaction data TrsvB. .. As a result, since the charge for the reservation corresponding to the reserved transaction data TrsvA is not collected, the fraud that the charge using the mobile body A is not paid in the reservation corresponding to the reserved transaction data TrsvA is established.
  • FIG. 37 is a sequence diagram showing a local return process of the system according to the fourth example of the comparative example.
  • the same elements as those in FIG. 20 are designated by the same reference numerals, and detailed description thereof will be omitted.
  • the moving body device A confirms that the moving body A has been returned (S501C).
  • the mobile device A generates the return transaction data TrtnA indicating the completion of the return of the mobile A, triggered by the confirmation that the mobile A has been returned (S502C).
  • the mobile device A attempts to transfer the return transaction data TrtnA to the other mobile devices B and C, but fails (S503C). This is because the mobile device A is in the offline state, so that the return transaction data TrtnA cannot be transferred to the mobile devices B and C.
  • the mobile device A executes a verification algorithm that performs verification including the validity of the acquired return transaction data TrtnA (S504C).
  • the mobile device A stores the returned transaction data TrtnA verified by the verification algorithm executed in step S504C in the transaction pool a (S505C).
  • the mobile device A generates a block Blc (TrtnA) including the verified return transaction data TrtnA (S506C).
  • the mobile device A attempts to transmit the block Blc (TrtnA) generated in step S506C to the mobile devices B and C, which are other mobile devices, but fails (S507C). This is because the mobile device A cannot transmit the block Blc (TrtnA) to the mobile devices B and C because it is in the offline state.
  • the mobile device A independently executes the consensus algorithm (S508C). Specifically, the mobile device A independently agrees that the returned transaction data TrtnA is legitimate transaction data (that is, legitimacy), and independently agrees on the legitimacy of the block Blc (TrtnA).
  • the process of step S506C may be performed when the consensus algorithm is executed in step S508C.
  • the mobile device A connects the block Blc (TrtnA) agreed in step S508C to the blockchain in the ledger A (S509C).
  • the block including the return transaction data TrtnA is stored only in the ledger A, and the local return of the mobile body A is recorded.
  • the mobile device A checks the reservation information stored in the blockchain (S510C). More specifically, each of the mobile devices A, B, and C executes the reservation smart contract by connecting the return transaction data TrtnA to the blockchain in its own ledger, and is stored in the blockchain. Confirm that the reserved transaction data TrsvA exists as the reserved information.
  • each mobile device A executes the charge calculation algorithm (S511C). Since the mobile device A is in the offline state, the charge calculation algorithm calculates the charge for the reservation corresponding to the reservation transaction data TrsvA.
  • FIG. 38 is a sequence diagram showing the processing of the system performed when the communication of the mobile device A according to the fourth example of the comparative example is restored.
  • the same elements as those in FIG. 21 are designated by the same reference numerals, and detailed description thereof will be omitted.
  • the mobile device A has returned to a communicable state (online state) with the mobile devices B and C, which are other mobile devices (S601C).
  • the mobile device A transmits a signal indicating that the mobile device A is online to the other mobile devices B and C (S602C).
  • the mobile devices A, B, and C determine the difference between the blockchains in each ledger (S603C).
  • different blocks are connected to the blockchains of the ledger A and the ledgers B and C, as shown in the example shown in FIG. 34D, so that the blockchain in the ledger A is connected. Is different from the blockchain in ledgers B and C. Therefore, when the communication of the mobile device A is restored, for example, as shown in the example shown in FIG. 35, the ledgers A, B, and C of the mobile devices A, B, and C share different block chains, so that a fork is generated. do.
  • the mobile devices A, B, and C transmit information about the blocks corresponding to the side chain block and the main chain block (S604C, S605C).
  • the block connected to the blockchain of the ledger A of the mobile device A that has been offline for a certain period of time corresponds to the side chain block Blc (TrsvA, TrntA, TrtnA).
  • the block connected to the blockchain of the ledgers B and C of the mobile devices B and C corresponds to the main chain block Blc (TrsvB).
  • the mobile devices A, B, and C each store the transaction data TrsvA, TrntA, and TrtnA of the side chain blocks obtained in step S604C in the transaction pool (S606C).
  • the mobile devices A, B, and C are updated so that they are the same as the blockchains of the ledgers A, B, and C, respectively (S607C). More specifically, each of the mobile devices A, B, and C deletes the side chain block connected to the block chain and leaves the main chain block, so that the block chains of the ledgers A, B, and C are the same. Update the blockchain of ledger A so that
  • the mobile devices A, B, and C generate blocks Blc (TrsvA, TrntA, TrtnA) including transaction data TrsvA, TrntA, and TrtnA stored in the transaction pool, respectively. (S614C).
  • the mobile devices A, B, and C each transmit the block Blc (TrsvA, TrntA, TrtnA) generated in step S614C to the other mobile devices (S615C).
  • the mobile devices A, B, and C have succeeded in verifying the validity of the transaction data TrsvA, TrntA, and TrtnA contained in the block Blc (TrsvA, TrntA, TrtnA) in the other mobile devices, respectively. You can notify the report.
  • the mobile devices A, B, and C jointly execute the consensus algorithm (S616C). Specifically, the mobile devices A, B, and C each agree that the transaction data TrsvA, TrntA, and TrtnA are legitimate transaction data (that is, legitimacy) based on the report notified in step S615C. Then, the legitimacy of the block Blc (TrsvA, TrntA, TrtnA) is agreed. The processes of steps S614C and S615C may be performed when the consensus algorithm is executed in step S616C.
  • each of the mobile devices A, B, and C connects the block Blc (TrsvA, TrntA, TrtnA) agreed in step S616 to the blockchain in the distributed ledger (S617C). More specifically, the mobile device A connects the agreed block Blc (TrsvA, TrntA, TrntA) to the blockchain in the ledger A, and the mobile device B connects the agreed block Blc (TrsvA, TrntA). , TrtnA) is connected to the blockchain in the ledger B. The mobile device C connects the agreed block Blc (TrsvA, TrntA, TrtnA) to the blockchain in the ledger C. As a result, as shown in FIG. 36 (c), a block containing the reserved transaction data TrsvA, the lending transaction data TrntA, and the returned transaction data TrntA is stored, and the local reservation, local lending, and local return of the mobile body A are recorded. Will be done.
  • the mobile device A checks the reservation information stored in the blockchain (S620C). More specifically, each of the mobile devices A, B, and C executes the reservation smart contract by connecting the block containing the return transaction data TrtnA to the blockchain in its own ledger, and causes the blockchain to execute the reservation smart contract. It is confirmed that there are reserved transaction data TrsvA and reserved transaction data TrsvB as the stored reservation information.
  • step S621C the mobile devices A, B, and C do not execute the charge calculation algorithm, respectively. More specifically, the mobile devices A, B, and C each execute the charge calculation algorithm, but the charge for the reservation corresponding to the reservation transaction data TrsvA is not collected. Since the process of step S621C is the same as the process of step S511B described above, the description thereof will be omitted.
  • the reservation corresponding to the reserved transaction data TrsvA and the reservation corresponding to the reserved transaction data TrsvB are in conflict. Further, the block containing the reserved transaction data TrsvA is connected behind the block containing the reserved transaction data TrsvB. Therefore, even if the charge calculation algorithm is executed, the charge for the reservation corresponding to the reserved transaction data TrsvA is not collected, and only the charge for the reservation corresponding to the reserved transaction data TrsvB is collected. Become.
  • step S10 In the fraudulent processing shown in FIGS. 23 and 33, the fee for the local reservation processed in step S10 was not collected because the competitive reservation was made in step S11.
  • step S11 even if the competitive reservation is made in step S11, the fee is surely collected for the local reservation processed in step S10, so that the fee is surely collected in step S12 of FIGS. 23 and 33.
  • the unlocking completion transaction data indicating that the unlocking of the mobile body A is completed is generated and stored in the blockchain of the offline ledger A.
  • the competitive reservation is made in step S11, even if the charge for the local reservation itself reserved in step S10 cannot be collected by the method of the comparative example, the mobile body A is used for the local reservation with the unlocking completion transaction data. Collect the fee.
  • FIG. 39 is a sequence diagram showing the processing of local lending of the system according to the embodiment.
  • the same elements as those in FIG. 30 are designated by the same reference numerals, and detailed description thereof will be omitted.
  • FIG. 40 is a diagram conceptually showing a block of a blockchain stored in the ledger A by the processing of the local lending of FIG. 39.
  • the terminal A transmits an unlock request for the mobile body A to the mobile body device A based on the operation of the user who uses the mobile body A (S301D).
  • step S301D when the mobile device A receives the unlock request transmitted in step S301D, it confirms whether the blockchain of the ledger A has a reservation corresponding to the unlock request (S302D), and locks the mobile A. Is released (S303D).
  • the mobile device A generates unlocking completion transaction data Tunl indicating that the unlocking of the mobile body A is completed, triggered by the unlocking of the mobile body A (S3031).
  • the unlocking completion transaction data Tun includes at least the user ID that unlocked the mobile body A, the device ID of the mobile device A that unlocked the mobile body A, the corresponding reservation ID, and the unlocked date and time.
  • a blockchain ID that can specify the user ID and the device ID may be used.
  • a reservation transaction data ID capable of identifying the reservation transaction data including the reservation ID may be used.
  • the mobile device A attempts to transfer the unlocking completion transaction data Tun to the other mobile devices B and C, but fails (S3032). This is because the mobile device A is in the offline state, so that the loan transaction data Tun cannot be transferred to the mobile devices B and C.
  • the mobile device A generates lending transaction data TrntA indicating the start of lending of the mobile A, triggered by the unlocking of the mobile A (S304D).
  • the mobile device A attempts to transfer the lending transaction data TrntA to the other mobile devices B and C, but fails (S305D). This is because the mobile device A is in the offline state, so that the loan transaction data TrntA cannot be transferred to the mobile devices B and C.
  • the mobile device A executes a verification algorithm that performs verification including the validity of the unlocked transaction data Tun and the lending transaction data TrntA, that is, the transaction data Tunl and TrntA (S306D).
  • the mobile device A stores the transaction data Tunl and TrntA verified by the verification algorithm executed in step S306D in the transaction pool a (S307D).
  • the mobile device A generates a block Blc (Tunl, TrntA) containing the verified transaction data Tunl and TrntA, respectively (S309D).
  • the mobile device A attempts to transmit the block Blc (Tunl, TrntA) generated in step S309D to the mobile devices B and C, which are other mobile devices, but fails (S310D). This is because the mobile device A cannot transmit the block Blc (Tunl, TrntA) to the mobile devices B and C because it is in the offline state.
  • the mobile device A independently executes the consensus algorithm (S311D). Specifically, the mobile device A independently agrees that the transaction data Tunl and TrntA are legitimate transaction data (that is, legitimacy), and independently agrees on the legitimacy of the block Blc (Tunl, TrntA). ..
  • the process of step S309D may be performed when the consensus algorithm is executed in step S311D.
  • the mobile device A connects the block Blc (Tunl, TrntA) agreed in step S311D to the blockchain in the ledger A (S312D).
  • the block containing the reserved transaction data TrsvA and the block containing the lending transaction data TrntA and the unlocking completed transaction data Tunl are concatenated.
  • FIG. 41 is a diagram conceptually showing the blocks of the blockchain stored in the ledger A and the ledger B when the charge calculation process according to the embodiment is performed.
  • FIG. 41 shows the blocks of the blockchain stored in the ledger A and the ledger B during the operation of step S15 of FIGS. 23 and 33.
  • the blocks containing the transaction data Tunl and TrntA are concatenated after the blocks containing the lending transaction data TrntB in order to eliminate the occurrence of the fork as described above. That is, the block connected to the blockchain of the ledger A of the mobile device A in the offline state by the offline lending process shown in FIG. 39 is later than the block connected to the blockchain of the ledger B by the process of competing reservation. Be connected.
  • the charge for the reservation corresponding to the reserved transaction data TrsvA is charged. Not collected.
  • the mobile body A is used by the local reservation because the unlocked transaction data Tunl is stored in the blockchain. Collect the fee.
  • the unlocked transaction data exists in the blockchain, even if there are competing reservations and local reservations and it seems that duplicate collection is performed, the local reservations that are not collected by the method of the comparative example are not collected. This is because it can be seen that the moving body A was certainly used.
  • FIG. 42 is a flowchart for explaining the details of the charge calculation process according to the embodiment.
  • the charge calculation process according to the present embodiment shown in FIG. 42 is executed in step S15 of FIGS. 23 and 33.
  • the charge calculation process is performed by the mobile device A will be described as a representative.
  • step S15 of FIGS. 23 and 33 the mobile device A first confirms whether or not there is a trigger for collecting charges (S6211).
  • This trigger may be that a certain interval has elapsed, or that the return transaction data TrtnA is included in the block newly connected to the blockchain of the ledger A.
  • step S6211 when there is a trigger (Yes in S6211), the mobile device A searches the blockchain of the ledger A (S6212). In step S6211, when there is no trigger (No in S6211), the mobile device A returns to step S6211.
  • the mobile device A determines whether or not there is uncollected reserved transaction data even though there is unlocking completed transaction data in the blockchain of ledger A (S6213).
  • the reserved transaction data TrsvA conflicts with the reserved transaction data TrsvB and is concatenated after the block including the reserved transaction data TrsvB, it can be determined that there is uncollected reserved transaction data.
  • step S6213 when there is a duplicate reservation (Yes in S6213), the mobile device A executes the charge calculation algorithm (S6214). As a result, the charge for the reservation ID including the reservation included in the unlocking completion transaction data, that is, the reservation ID indicating the usage reservation of the mobile body A included in the reservation transaction data TrsvA is calculated.
  • the mobile device A executes the charge collection process (S6215). As a result, the charge using the mobile body A in the reservation included in the reservation transaction data TrsvA is collected.
  • the unlocking completion transaction data indicating that the lock of the mobile body A has been released is stored in each block chain of the distributed ledger.
  • the charge using the mobile body A is triggered by the unlocking completion transaction data stored in each block chain of the distributed ledger. Can be collected.
  • the mobile body A is an example of the service target
  • the usage reservation of the mobile body A is an example of the service target contract.
  • the unlocking completion transaction data indicating that the lock of the service target has been released is stored in the first blockchain.
  • the fraud countermeasure processing is not limited to the case where the unlocking transaction data is generated. Further, the fraudulent reservation detection process may be executed in the process when the mobile terminal A returns to communication. In this modification, a case where the fraudulent reservation detection process is executed when the consensus algorithm is executed in the process when the mobile terminal A returns to communication will be described.
  • FIG. 43 is a sequence diagram showing the processing of the system performed when the communication of the mobile device A according to the modified example of the embodiment is restored.
  • the same elements as those in FIG. 21 are designated by the same reference numerals, and detailed description thereof will be omitted.
  • the sequence diagram shown in FIG. 43 is different from the sequence diagram shown in FIG. 21 in that the fraudulent reservation detection process is executed when the consensus algorithm is executed. That is, since the processes of steps 601E to S615E shown in FIG. 43 are the same as the processes of steps 601 to S615 shown in FIG. 21, the description thereof is omitted here.
  • step S616E the mobile devices A, B, and C jointly execute the consensus algorithm.
  • the mobile devices A, B, and C each execute a consensus algorithm that agrees that the transaction data Tpol is legitimate transaction data (that is, legitimacy) based on the report notified in step S615. At that time, the fraudulent reservation detection process is executed.
  • each of the mobile devices A, B, and C searches in the blockchain of its own ledger and determines whether or not there is unlocking completion transaction data including a reservation ID that is said to have no corresponding reservation. Detect. As described above, if there is unlocking completion transaction data including a reservation ID in which there is a competing reservation and there is no corresponding reservation, it is possible to detect that there is an illegal reservation for which the charge is not collected by the existing charge calculation algorithm.
  • each of the mobile devices A, B, and C searches the blockchain of their own ledger and detects whether or not there is unlocking completion transaction data issued at a time when there is no reservation. You may.
  • a fork is generated in the blockchain.
  • the reservation transaction data corresponding to the local reservation and the unlocking completion transaction data issued in connection with the local lending are stored in the blockchain of the distributed ledger at the time after the mobile device A is returned to the online state. Will be. That is, the reserved transaction data and the unlocked transaction data are stored in the blockchain of the distributed ledger after the time of local reservation and local lending.
  • the reservation transaction data and the unlocking completion transaction data are stored in the blockchain of the distributed ledger, so that the unlocking completion transaction data is issued at the time when there is no reservation. Looks like. As a result, it is possible to detect whether or not unauthorized processing has been performed by detecting the unlocking completion transaction data at a time when there is no reservation.
  • the mobile devices A, B, and C each transfer the block Blc (Tpolv) agreed in step S616E to the blockchain in the distributed ledger. Connect (S617E).
  • fraudulent information indicating that fraudulent transaction data has been detected may be created and saved.
  • FIG. 44 is a flowchart showing a fraudulent reservation detection process according to a modified example of the embodiment.
  • the fraudulent reservation detection process is performed by the mobile device A will be described as an example.
  • the fraudulent reservation detection process according to the embodiment is not limited to the case where the consensus algorithm is executed as described above, and may be executed independently.
  • the mobile device A confirms whether or not there is a trigger for fraud check (S6161).
  • This trigger may be the execution of the consensus algorithm as described above, the elapse of a fixed interval such as 10 minutes, or the timing at which a new block is generated.
  • step S6161 when there is a trigger (Yes in S6161), the mobile device A searches the blockchain of the ledger A (S6162). In step S6161, when there is no trigger (No in S6161), the mobile device A returns to step S6161.
  • the mobile device A confirms whether or not there is unlocking completion transaction data linked at a time when there is no reservation in the blockchain of the ledger A (S6163).
  • step S6163 when there is unlocking completion transaction data linked at a time when there is no reservation (Yes in S6163), an incident report is created and saved (S6164). In step S6163, when there is no unlocking completion transaction data linked at a time when there is no reservation (No in S6163), this fraudulent reservation detection process is terminated.
  • FIG. 45 is a sequence diagram showing system processing performed when an incident report is created by executing fraudulent reservation detection processing according to a modified example of the embodiment.
  • the same operation as in FIG. 43 is designated by the same reference numerals, and detailed description thereof will be omitted.
  • the mobile devices A, B, and C show the processing after creating the incident report in the fraudulent reservation detection processing performed when the consensus algorithm is jointly executed.
  • step S616E the mobile devices A, B, and C jointly execute the consensus algorithm.
  • each of the mobile devices A, B, and C executes the fraudulent reservation detection process when the consensus algorithm is executed.
  • the mobile devices A, B, and C create an incident report indicating that the unlocking completion transaction data has been detected.
  • the mobile terminal B on behalf of the mobile terminal B, generates transaction data Tinc for recording the created incident report (S622E). Not only when the mobile terminal B generates the transaction data Tin, the mobile terminal A or the mobile terminal C may generate the transaction data Tin.
  • the mobile device B transfers the transaction data Tinc to the mobile devices A and C, which are other mobile devices (S623E). As a result, the mobile devices A and C acquire the transaction data Tinc.
  • the mobile devices A, B, and C each execute a verification algorithm for verifying the transaction data Tin (S624E).
  • each of the mobile devices A, B, and C stores the transaction data Tinc verified in step S624E in the ledger (S625E). More specifically, the mobile device A stores the verified transaction data Tin in the ledger A, and the mobile device B stores the verified transaction data Tin in the ledger B. The mobile device C stores the verified transaction data Tin in the ledger C.
  • transaction data Tinc is stored in ledger A, ledger B, and ledger C, and an incident report is recorded.
  • a mobile body has been described as an example of a service target, but the present invention is not limited to this.
  • the service target may be a hotel room or an electronic locker as long as it is locked so that it cannot be used by other users when the service is not used and is unlocked when the service is used.
  • the contract is not limited to, for example, a reservation for the use of the mobile body 10, and may be, for example, a reservation for the use of a hotel room or a reservation for the use of an electronic locker.
  • the unlocking completion transaction data is transaction data indicating that the lock of the service target is released when the service target is used, and the first contract ID that uniquely identifies the first contract for using the service target is used. Any transaction data may be included.
  • the unlocking completion transaction data is generated when the reserved transaction data is stored in the blockchain and the user is permitted to unlock the lock to be serviced during the reserved time zone.
  • a charge collection smart contract for collecting the usage charge for the service may be executed.
  • the unlocking completion transaction data is stored in the blockchain in the distributed ledger, and the usage fee for the first contract identified by the first contract ID included in the unlocking completion transaction data is not collected. You may ask the toll collection smart contract to confirm.
  • the smart contract execution unit 106 may cause the charge collection smart contract to collect the usage fee for the first contract when the unlocking completion transaction data is stored and has not been collected. If it is not collected, the second transaction data for making the first contract and the third transaction data for making the second contract for using the service target are sent to the first blockchain and the second blockchain. Is stored. If it is not collected, the time zone for using the service target included in the first contract and the time zone for using the service target included in the second contract partially overlap.
  • Each device in the above embodiment is specifically a computer system composed of a microprocessor, a ROM, a RAM, a hard disk unit, a display unit, a keyboard, a mouse, and the like.
  • a computer program is recorded in the RAM or the hard disk unit.
  • the microprocessor operates according to the computer program, each device achieves its function.
  • the computer program is configured by combining a plurality of instruction codes indicating instructions to the computer in order to achieve a predetermined function.
  • Each device in the above embodiment may be composed of a part or all of the constituent elements of one system LSI (Large Scale Integration).
  • the system LSI is an ultra-multifunctional LSI manufactured by integrating a plurality of components on one chip, and specifically, is a computer system including a microprocessor, a ROM, a RAM, and the like. .. A computer program is recorded in the RAM. When the microprocessor operates according to the computer program, the system LSI achieves its function.
  • each part of the constituent elements constituting each of the above devices may be individually integrated into one chip, or may be integrated into one chip so as to include a part or all of them.
  • system LSI Although it is referred to as a system LSI here, it may be referred to as an IC, an LSI, a super LSI, or an ultra LSI due to the difference in the degree of integration. Further, the method of making an integrated circuit is not limited to LSI, and may be realized by a dedicated circuit or a general-purpose processor. An FPGA (Field Programmable Gate Array) that can be programmed after the LSI is manufactured, or a reconfigurable processor that can reconfigure the connection and settings of the circuit cells inside the LSI may be used.
  • FPGA Field Programmable Gate Array
  • each of the above devices may be composed of an IC card or a single module that can be attached to and detached from each device.
  • the IC card or the module is a computer system composed of a microprocessor, a ROM, a RAM, and the like.
  • the IC card or the module may include the above-mentioned super multifunctional LSI.
  • the microprocessor operates according to a computer program, the IC card or the module achieves its function. This IC card or this module may have tamper resistance.
  • the present disclosure may be the method shown above. Further, it may be a computer program that realizes these methods by a computer, or it may be a digital signal composed of the computer program.
  • the present disclosure discloses a recording medium in which the computer program or the digital signal can be read by a computer, for example, a flexible disk, a hard disk, a CD-ROM, an MO, a DVD, a DVD-ROM, a DVD-RAM, or a BD (Blu-ray). (Registered trademark) Disc), may be recorded in a semiconductor memory or the like. Further, it may be the digital signal recorded on these recording media.
  • a computer for example, a flexible disk, a hard disk, a CD-ROM, an MO, a DVD, a DVD-ROM, a DVD-RAM, or a BD (Blu-ray). (Registered trademark) Disc), may be recorded in a semiconductor memory or the like. Further, it may be the digital signal recorded on these recording media.
  • BD Blu-ray
  • the computer program or the digital signal may be transmitted via a telecommunication line, a wireless or wired communication line, a network typified by the Internet, data broadcasting, or the like.
  • the present disclosure is a computer system including a microprocessor and a memory, in which the memory records the computer program, and the microprocessor may operate according to the computer program.
  • This disclosure can be used for control methods, control devices, and programs, and does not pay a fee when a user makes a contract for using a mobile body, for example, in a mobile body sharing service such as a bicycle or a motorcycle. It can be used for control methods, control devices, programs, etc. that can suppress unauthorized use.

Landscapes

  • Business, Economics & Management (AREA)
  • Engineering & Computer Science (AREA)
  • Accounting & Taxation (AREA)
  • Theoretical Computer Science (AREA)
  • Finance (AREA)
  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • Strategic Management (AREA)
  • Development Economics (AREA)
  • Economics (AREA)
  • Tourism & Hospitality (AREA)
  • Marketing (AREA)
  • Computer Security & Cryptography (AREA)
  • Operations Research (AREA)
  • Human Resources & Organizations (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Quality & Reliability (AREA)
  • General Engineering & Computer Science (AREA)
  • Health & Medical Sciences (AREA)
  • Databases & Information Systems (AREA)
  • Data Mining & Analysis (AREA)
  • Bioethics (AREA)
  • General Health & Medical Sciences (AREA)
  • Computer Hardware Design (AREA)
  • Software Systems (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

第１分散台帳で第１ブロックチェーンを管理する第１ノードと、それぞれ第２分散台帳で第２ブロックチェーンを管理する複数の第２ノードとを含み、サービス対象の利用に用いられるシステムにおける第１ノードの制御方法であって、サービス対象の利用に際してサービス対象のロックを解除したことを示す第１トランザクションデータであって、サービス対象の利用を行う第１契約を一意に識別する第１契約ＩＤを含む第１トランザクションデータを生成し（Ｓ３０３１）、第１トランザクションデータを含むブロックを第１ブロックチェーンに格納する（Ｓ３１２Ｄ）。

Description

制御方法、制御装置、及び、プログラム
　本開示は、制御方法、制御装置、及び、プログラムに関する。
　例えば特許文献１には、車両端末とユーザ端末との間で送受信される利用予約に関する情報をブロックチェーンで適切に管理する技術が開示されている。
特開２０１９－２５３１３０号公報
　しかしながら、物体の利用予約などの契約または取引の管理にブロックチェーンを用いる場合、特許文献１に開示されている技術では、フォークが発生したときのブロックチェーンの振る舞いを悪用して、物体を不正に利用することができてしまうという問題がある。
　本開示は、上述の事情を鑑みてなされたもので、ブロックチェーンを悪用したサービス対象の不正利用を抑制できる制御方法、制御装置、及び、プログラムを提供することを目的とする。
　本開示の一態様に係る制御方法は、第１分散台帳で第１ブロックチェーンを管理する第１ノードと、それぞれ第２分散台帳で第２ブロックチェーンを管理する複数の第２ノードとを含み、サービス対象の利用に用いられるシステムにおける前記第１ノードの制御方法であって、前記サービス対象の利用に際して前記サービス対象のロックを解除したことを示す第１トランザクションデータであって、前記サービス対象の利用を行う第１契約を一意に識別する第１契約ＩＤを含む第１トランザクションデータを生成し、前記第１トランザクションデータを含むブロックを前記第１ブロックチェーンに格納する。
　なお、これらの包括的または具体的な態様は、システム、方法、集積回路、コンピュータプログラムまたはコンピュータで読み取り可能なＣＤ－ＲＯＭなどの記録媒体で実現されてもよく、システム、方法、集積回路、コンピュータプログラム及び記録媒体の任意な組み合わせで実現されてもよい。
　本開示によれば、ブロックチェーンを悪用したサービス対象の不正利用を抑制できる。
図１は、不正利用を行う方法の手順を説明するための図である。 図２Ａは、図１に示すステップ１が行われる場面の一例を示す図である。 図２Ｂは、図１に示すステップ２、３が行われる場面の一例を示す図である。 図２Ｃは、図１に示すステップ４が行われる場面の一例を示す図である。 図２Ｄは、図１に示すステップ５が行われる場面の一例を示す図である。 図２Ｅは、図１に示すステップ６が行われる場面の一例を示す図である。 図２Ｆは、図１に示すステップ６の後に行われる場面の一例を示す図である。 図３Ａは、フォークが発生したときのブロックチェーンの振る舞いを説明するための図である。 図３Ｂは、フォークが発生したときのブロックチェーンの振る舞いを説明するための図である。 図３Ｃは、フォークが発生したときのブロックチェーンの振る舞いを説明するための図である。 図４は、実施の形態に係るシステムの構成の一例を示す図である。 図５Ａは、実施の形態に係るシステムの構成の他の一例を示す図である。 図５Ｂは、実施の形態に係るシステムの構成の他の一例を示す図である。 図５Ｃは、実施の形態に係るシステムの構成の他の一例を示す図である。 図６は、実施の形態に係る移動体装置の構成の一例を示す図である。 図７は、実施の形態に係る端末の構成の一例を示す図である。 図８は、比較例の第１例に係るシステムの正常処理の動作概要を示すフローチャートである。 図９Ａは、図８のステップＳ１の動作により台帳Ａ及び台帳Ｂに格納されるブロックチェーンのブロックを概念的に示す図である。 図９Ｂは、図８のステップＳ３の動作により台帳Ａ及び台帳Ｂに格納されるブロックチェーンのブロックを概念的に示す図である。 図９Ｃは、図８のステップＳ５の動作により台帳Ａ及び台帳Ｂにに格納されるブロックチェーンのブロックを概念的に説明するための図である。 図１０は、比較例の第１例に係るシステムの予約処理を示すシーケンス図である。 図１１は、比較例の第１例に係るシステムの貸出処理を示すシーケンス図である。 図１２は、比較例の第１例に係るシステムの返却処理を示すシーケンス図である。 図１３は、比較例に係るシステムの料金算定処理の詳細を説明するためのフローチャートである。 図１４は、比較例の第２例に係るシステムの正常処理の動作概要を示すフローチャートである。 図１５Ａは、図１４のステップＳ１Ａの動作により台帳Ａに格納されるブロックチェーンのブロックを概念的に示す図である。 図１５Ｂは、図１４のステップＳ３Ａの動作により台帳Ａに格納されるブロックチェーンのブロックを概念的に示す図である。 図１５Ｃは、図１４のステップＳ５Ａの動作により台帳Ａに格納されるブロックチェーンのブロックを概念的に示す図である。 図１６は、図１４のステップＳ６Ａの動作により台帳Ａ及び台帳Ｂに格納されるブロックチェーンのブロックを概念的に説明するための図である。 図１７は、図１４のステップＳ６Ａの動作により台帳Ａ及び台帳Ｂに格納されるブロックチェーンのブロックを概念的に説明するための図である。 図１８は、比較例の第２例に係るシステムの予約処理を示すシーケンス図である。 図１９は、比較例の第２例に係るシステムの貸出処理を示すシーケンス図である。 図２０は、比較例の第２例に係るシステムの返却処理を示すシーケンス図である。 図２１は、比較例の第２例に係る移動体装置Ａの通信復帰時に行われるシステムの処理を示すシーケンス図である。 図２２は、比較例に係るシステムのブロック連結処理を説明するためのフローチャートである。 図２３は、比較例の第３例に係るシステムの不正処理の動作概要を示すフローチャートである。 図２４Ａは、図２３のステップＳ１０の動作により台帳Ａに格納されるブロックチェーンのブロックを概念的に示す図である。 図２４Ｂは、図２３のステップＳ１１の動作により台帳Ａに格納されるブロックチェーンのブロックを概念的に示す図である。 図２４Ｃは、図２３のステップＳ１２の動作により台帳Ａに格納されるブロックチェーンのブロックを概念的に示す図である。 図２５は、図２３のステップＳ１３の動作により台帳Ａ及び台帳Ｂに格納されるブロックチェーンのブロックを概念的に説明するための図である。 図２６は、図２３のステップＳ１３の動作により台帳Ａ及び台帳Ｂに格納されるブロックチェーンのブロックを概念的に説明するための図である。 図２７は、図２３のステップＳ１４の動作により台帳Ａ及び台帳Ｂに格納されるブロックチェーンのブロックを概念的に示す図である。 図２８は、比較例の第３例に係るシステムのローカル予約を行う場合の処理を示すシーケンス図である。 図２９は、比較例の第３例に係るシステムの競合予約を行う場合の処理を示すシーケンス図である。 図３０は、比較例の第３例に係るシステムのローカル貸出の処理を示すシーケンス図である。 図３１は、比較例の第３例に係る移動体装置Ａの通信復帰時に行われるシステムの処理を示すシーケンス図である。 図３２は、比較例の第３例に係るシステムの返却処理を示すシーケンス図である。 図３３は、比較例の第４例に係るシステムの不正処理の動作概要を示すフローチャートである。 図３４Ａは、図３３のステップＳ１０の動作により台帳Ａに格納されるブロックチェーンのブロックを概念的に示す図である。 図３４Ｂは、図３３のステップＳ１１の動作により台帳Ａに格納されるブロックチェーンのブロックを概念的に示す図である。 図３４Ｃは、図３３のステップＳ１２の動作により台帳Ａに格納されるブロックチェーンのブロックを概念的に示す図である。 図３４Ｄは、図３３のステップＳ１３Ａの動作により台帳Ａに格納されるブロックチェーンのブロックを概念的に示す図である。 図３５は、図３３のステップＳ１４Ａの動作により台帳Ａ及び台帳Ｂに格納されるブロックチェーンのブロックを概念的に説明するための図である。 図３６は、図３３のステップＳ１４Ａの動作により台帳Ａ及び台帳Ｂに格納されるブロックチェーンのブロックを概念的に説明するための図である。 図３７は、比較例の第４例に係るシステムのローカル返却の処理を示すシーケンス図である。 図３８は、比較例の第４例に係る移動体装置Ａの通信復帰時に行われるシステムの処理を示すシーケンス図である。 図３９は、実施の形態に係るシステムのローカル貸出の処理を示すシーケンス図である。 図４０は、図３９のローカル貸出の処理により台帳Ａに格納されるブロックチェーンのブロックを概念的に示す図である。 図４１は、実施の形態に係る料金算定処理が行われる際に台帳Ａ及び台帳Ｂに格納されているブロックチェーンのブロックを概念的に示す図である。 図４２は、本実施の形態に係る料金算定処理の詳細を説明するためのフローチャートである。 図４３は、実施の形態の変形例に係る移動体装置Ａの通信復帰時に行われるシステムの処理を示すシーケンス図である。 図４４は、実施の形態の変形例に係る不正予約検知処理を示すフローチャートである。 図４５は、実施の形態の変形例に係る不正予約検知処理を実行してインシデントレポートを作成したときに行われるシステムの処理を示すシーケンス図である。
　（本開示の一態様を得るに至った経緯）
　上述したように特許文献１には、車両端末とユーザ端末との間で送受信される利用予約に関する情報をブロックチェーンで適切に管理する技術が開示されている。
　しかしながら、特許文献１に開示されている技術では、ブロックチェーンの仕組みを悪用して不正利用できる。以下、例を挙げて説明する。
　図１は、不正利用を行う方法の手順を説明するための図である。図２Ａ～図２Ｆは、図１に示す手順が行われる場面の一例を示す図である。図１には、複数のバイクをシェアリングするサービスにおけるバイクＡに対する利用予約を行い、バイクＡを不正利用する場合の手順が示されている。なお、矢印は現在時刻を示す。また、複数のバイクはそれぞれ、ブロックチェーンで予約が管理された台帳を持っているとしている。図２Ａは図１に示すステップ１が行われる場面の一例を示す図であり、図２Ｂは図１に示すステップ２、３が行われる場面の一例を示す図である。図２Ｃは図１に示すステップ４が行われる場面の一例を示す図であり、図２Ｄは図１に示すステップ５が行われる場面の一例を示す図である。図２Ｅは図１に示すステップ６が行われる場面の一例を示す図であり、図２Ｆは図１に示すステップ６の後に行われるステップ７の場面の一例を示す図である。
　不正利用を企てるユーザは、図２Ａに示すように、ステップ１において例えば１２：００～１２：１５の間の１５分だけ、バイクＡを利用する第１予約を行う。すると、バイクＡの台帳Ａは他のバイクの台帳Ｂ、Ｃと通信可能（オンライン）な状態であるので、図１のステップ１に示すように、黒色で示される第１予約Ｔｘが、すべての台帳（台帳Ａ、Ｂ及びＣ）に格納される。この結果、バイクＡを解錠して、ユーザは、１２：００～１２：１５の間の１５分だけ利用できる。
　次に、不正利用を企てるユーザは、図２Ｂに示すように、ステップ２及び３において、バイクＡの台帳Ａを他のバイクの台帳Ｂ、Ｃと通信不可な（オフライン）状態にする。続いて、不正利用を企てるユーザは、例えば１６：００～１６：１５の間の１５分だけ、バイクＡを利用する第２予約を、他のバイクの台帳Ｂ、Ｃに対して行う。すると、バイクＡの台帳Ａはオフライン状態であるので、図１のステップ３に示すように黒色で示される第２予約Ｔｘが、オンライン状態の台帳Ｂ及びＣのみに格納される。
　次に、不正利用を企てるユーザは、図２Ｃに示すように、ステップ４において、例えば１２：１５～１６：１５の間、バイクＡを利用する不正予約をバイクＡの台帳Ａに対して行う。すると、バイクＡの台帳Ａは他のバイクの台帳Ｂ、Ｃと通信不可な（オフライン）状態であるので、図１のステップ４に示すように、ハッチングで示される不正予約Ｔｘが、バイクＡの台帳Ａのみに格納される。この結果、１２：１５にはバイクＡが解錠されるので、図２Ｄに示すステップ５に示すように、そのユーザは、１２：１５～１６：１５の間、オフライン状態のままバイクＡを不正利用することができる。この場合、図１のステップ５に示すように、黒色で示される第２予約Ｔｘが、オンライン状態の台帳Ｂ及びＣのみに格納される。
　次に、そのユーザは、図２Ｅに示すように、ステップ６において、１６：００～１６：１５の間に、バイクＡの台帳Ａを他のバイクの台帳Ｂ、Ｃと通信可能な（オンライン）状態に復帰させる。すると、詳細は後述するが、台帳Ａ、Ｂ、Ｃのブロックチェーンでフォークが発生し、図１のステップ６に示すように台帳Ａのブロックチェーンでは、台帳Ｂ、Ｃのブロックチェーンと同じように、第２予約Ｔｘが格納されることになる。そして、不正予約Ｔｘが第２予約Ｔｘの後に格納されることになる。
　ここで、ステップ６においてバイクＡの台帳Ａがオンライン状態に復帰すると、不正予約Ｔｘは、第２予約Ｔｘより後に台帳Ａ、Ｂ、Ｃに格納されるというように、フォークが発生したときのブロックチェーンの振る舞いについて説明する。
　図３Ａ～図３Ｃは、フォークが発生したときのブロックチェーンの振る舞いを説明するための図である。図３Ａ～図３Ｃには、移動体Ａの台帳Ａと移動体Ｂの台帳Ｂとに格納されるトランザクションデータが概念的に示されている。Ｔｘは、トランザクションデータを示す。移動体Ａは、例えばバイクＡであってもよい。
　まず、図３Ａの左側に示すように、移動体Ａの台帳Ａと移動体Ｂの台帳Ｂとが他の移動体（不図示）と通信可能な（オンライン）状態である場合、台帳Ａ及び台帳Ｂには、同じＴｘ１を含むブロック１と、当該ブロック１に連結されてＴｘ２を含むブロック２が格納される。Ｔｘ２は、例えば、上記の第１予約Ｔｘに該当させてもよい。
　このように、台帳Ａ及び台帳Ｂでは、Ｔｘ２を含むブロック２が生成されると、前回生成されたブロック１に連結される。台帳Ａ及び台帳Ｂでは、同一のブロックチェーンが構成されている。
　次に、図３Ａの右側に示すように、移動体Ａの台帳Ａが他の移動体と通信断絶の（オフライン）状態になっている場合、台帳Ａ及び台帳Ｂには、異なるＴｘを含むブロックが格納される。図３Ａの右側に示す例では、台帳Ａには、当該ブロック２に連結されるＴｘαを含むブロックαが格納されている一方で、台帳Ｂには、当該ブロック２に連結されるＴｘ３を含むブロック３と当該ブロック３に連結されるＴｘ４を含むブロック４とが格納されている。Ｔｘ３は、例えば、上記の第２予約Ｔｘに該当させ、Ｔｘαは、例えば、上記の不正予約Ｔｘに該当させてもよい。
　このように、台帳Ａがオフライン状態になると、台帳Ａ及び台帳Ｂの通信が断絶されるので、台帳Ａ及び台帳Ｂは独自にブロックチェーンを更新することになる。
　次に、図３Ｂの左側に示すように、移動体Ａの台帳Ａが他の移動体との通信可能な状態に復帰（オフライン復帰）させると、台帳Ａ及び台帳Ｂは、異なるブロックチェーンを共有し合う。図３Ｂの左側に示す例における台帳Ａ及び台帳Ｂでは、当該ブロック２に連結されるブロックが分岐し、当該ブロック２にＴｘαを含むブロックαが連結され、かつ、当該ブロック２にＴｘ３を含むブロック３とＴｘ４を含むブロック４とが連結される。以下、ブロックに分岐して連結されるブロックチェーンのうち最も長いブロックチェーンを主鎖と称し、それ以外のブロックチェーンを側鎖と称する。図３Ｂの左側に示す例では、Ｔｘ３を含むブロック３とＴｘ４を含むブロック４とがブロック２の主鎖に該当し、Ｔｘαを含むブロックαがブロック２の側鎖に該当する。
　このように、台帳Ａが再びオンライン状態になると、ブロック２に連結されるブロックチェーンが分岐し、フォークが発生する。
　次に、図３Ｂの右側に示すように、ブロック２の側鎖であるＴｘαを含むブロックαが削除され、フォークが解消されている。このとき、ブロックαに含まれていたＴｘαは削除されず、各移動体に搭載されている移動体装置のトランザクションプールに保存される。図３Ｂの右側に示す例では、移動体装置Ａと移動体装置ＢのトランザクションプールにＴｘαが保存される。
　次に、図３Ｃに示すように、台帳Ａ及び台帳Ｂでは、新たなブロックを生成するタイミングで、Ｔｘαが含まれて格納される。図３Ｃに示す例では、台帳Ａ及び台帳Ｂには、同じＴｘαを含むブロック５が、当該ブロック４に連結されて格納される。
　このようにして、台帳Ａ及び台帳Ｂでは、フォークが解消されて、同じブロックチェーンを持つようになる。以下、図２Ｆに戻って説明を続ける。
　最後に、不正利用を企てたユーザは、図２Ｆに示すように、ステップ７において、バイクＡを返却する。その後、料金徴収アルゴリズムが実行されて、バイクＡの利用料金が徴収される。しかし、第１予約分と第２予約分のみの料金が徴収され、１２：１５～１６：１５の間の利用分すなわち不正利用分の料金については徴収されない。
　これは、ステップ６においてバイクＡの台帳Ａがオンライン状態に復帰すると、不正予約Ｔｘは、第２予約Ｔｘより後に台帳Ａ、Ｂ、Ｃに格納され、さらに第２予約Ｔｘの予約時間帯と不正予約Ｔｘの予約時間帯とはブッキングしているからである。また、料金徴収アルゴリズムは、ブッキングしている予約（つまり、競合予約）であり後の予約である不正予約に対する料金徴収はされない。このようにして、そのユーザは、料金を支払わずにバイクＡを４時間利用できることになる。
　以上のように、物体の利用予約などの管理にブロックチェーンを用いる場合、フォークが発生したときのブロックチェーンの振る舞いを悪用して、物体を不正に利用することができてしまうという問題がある。
　それに対して、本開示の一態様に係る制御方法は、第１分散台帳で第１ブロックチェーンを管理する第１ノードと、それぞれ第２分散台帳で第２ブロックチェーンを管理する複数の第２ノードとを含み、サービス対象の利用に用いられるシステムにおける前記第１ノードの制御方法であって、前記サービス対象の利用に際して前記サービス対象のロックを解除したことを示す第１トランザクションデータであって、前記サービス対象の利用を行う第１契約を一意に識別する第１契約ＩＤを含む第１トランザクションデータを生成し、前記第１トランザクションデータを含むブロックを前記第１ブロックチェーンに格納する。
　このようにして、サービス対象のロックを解除したことを示す第１トランザクションデータが第１ブロックチェーンに格納される。これにより、第１トランザクションデータに対応するサービス対象の第１契約が競合していても、第１ブロックチェーン及び第２ブロックチェーンに格納される第１トランザクションデータをトリガにサービス対象を利用した料金を徴収することができる。よって、ブロックチェーンを悪用したサービス対象の不正利用を抑制できる。
　また、例えば、さらに、前記サービス対象の利用料金の徴収を行うための料金徴収スマートコントラクトを実行し、前記料金徴収スマートコントラクトを実行する際、前記第１ブロックチェーン及び前記第２ブロックチェーンに前記第１トランザクションデータが格納され、かつ、前記第１トランザクションデータに含まれる前記第１契約ＩＤにより識別される前記第１契約であって前記サービス対象の利用における前記第１契約に対する利用料金が未徴収であるか否かを前記料金徴収スマートコントラクトに確認させ、前記第１トランザクションデータが格納され、かつ、前記未徴収である場合、前記料金徴収スマートコントラクトに前記第１契約に対する利用料金の徴収を実行させてもよい。
　このように、料金徴収スマートコントラクトを実行させることで、第１トランザクションデータに対応するサービス対象の第１契約が競合していても、第１契約におけるサービス対象を利用した料金を徴収することができる。
　また、例えば、前記未徴収である場合とは、前記第１ブロックチェーン及び前記第２ブロックチェーンに、前記第１契約を行うための第２トランザクションデータと、前記サービス対象の利用を行う第２契約を行うための第３トランザクションデータとが格納されており、さらに、前記第１契約に含まれる前記サービス対象の利用を行う時間帯と前記第２契約に含まれる前記サービス対象の利用を行う時間帯とが一部重複する場合であるとしてもよい。
　また、例えば、さらに、前記料金徴収スマートコントラクトに、前記第１契約に含まれる前記サービス対象の利用に不正があった旨を示すインシデントレポートを作成させてもよい。
　また、例えば、さらに、前記第１ブロックチェーン及び前記第２ブロックチェーンに、前記第１契約を行うための第２トランザクションデータと、前記サービス対象の利用を行う第２契約を行うための第３トランザクションデータとが格納されており、かつ、前記第１契約に含まれる前記サービス対象の利用を行う時間帯と前記第２契約に含まれる前記サービス対象の利用を行う時間帯とが一部重複する競合契約が存在するか否かを不正検知スマートコントラクトに確認させ、前記競合契約が存在する場合、前記不正検知スマートコントラクトに、利用金の徴収が未徴収である旨のフラグを前記第１契約に付与させ、前記サービス対象の利用料金の徴収を行うための料金徴収スマートコントラクトに、前記フラグが付与された前記第１契約に対する料金徴収を実行させてもよい。
　このように、料金徴収スマートコントラクトを実行させることで、第１トランザクションデータに対応するサービス対象の第１契約が競合していても、第１契約におけるサービス対象を利用した料金を徴収することができる。
　また、例えば、前記システムは、複数の移動体をシェアリングするサービスに用いられ、前記サービス対象は、前記複数の移動体であり、前記第１契約及び前記第２契約は、第１の移動体の利用予約であり、前記第２トランザクションデータ及び前記第３トランザクションデータは、ユーザが前記第１ノードを介して前記第１の移動体の利用予約を行うための予約トランザクションデータであり、前記ユーザのＩＤと、前記ユーザが前記第１の移動体を利用する時間帯を示す予約時間帯と、前記利用予約を識別するための予約番号とを含むとしてもよい。
　このように、第１トランザクションデータに対応するサービス対象の利用予約が競合していても、第１ブロックチェーン及び第２ブロックチェーンに格納される第１トランザクションデータをトリガに第１契約におけるサービス対象を利用した料金を徴収することができる。よって、ブロックチェーンを悪用したサービス対象の不正利用を抑制できる。
　また、例えば、さらに、前記第１ノードが、前記ユーザから前記第１の移動体の利用を開始するための要求として前記第１の移動体の解錠要求を受信し、前記第１ノードが、前記解錠要求に対応する前記予約トランザクションデータが前記第１ブロックチェーンに格納されているか確認し、前記予約トランザクションデータが格納されている場合、前記時間帯に前記第１の移動体の解錠を前記ユーザに許可して、前記第１トランザクションデータを生成するとしてもよい。
　また、例えば、さらに、前記ユーザに前記第１の移動体を貸し出したことを示す貸出トランザクションデータであって、前記ユーザのＩＤと、前記予約番号と、前記ユーザに前記第１の移動体を貸し出した時刻のタイムスタンプとを含む貸出トランザクションデータを取得し、前記貸出トランザクションデータを含む第２ブロックを、前記第１ブロックチェーンに格納し、前記ユーザが前記第１の移動体を返却したことを示す返却トランザクションデータであって、前記ユーザのＩＤと、前記予約番号と、前記ユーザが前記第１の移動体を返却した時刻のタイムスタンプとを含む返却トランザクションデータを取得し、前記返却トランザクションデータを含む第３ブロックを、前記第１ブロックチェーンに格納し、前記予約トランザクションデータに含まれる前記ユーザのＩＤに対して、前記第１の移動体の利用料金の徴収を実行するとしてもよい。
　本開示の一態様に係る制御装置は、第１分散台帳で第１ブロックチェーンを管理する制御装置と、それぞれ第２分散台帳で第２ブロックチェーンを管理する複数の別の制御装置とを備え、サービス対象の利用に用いられるシステムにおける制御装置であって、プロセッサと、メモリと、を備え、前記プロセッサは、前記サービス対象の利用に際して前記サービス対象のロックを解除したことを示す第１トランザクションデータであって、前記サービス対象の利用を行う第１契約を一意に識別する第１契約ＩＤを含む第１トランザクションデータを生成し、前記プロセッサは、前記第１トランザクションデータを含むブロックを前記第１ブロックチェーンに格納する。
　本開示の一態様に係るプログラムは、第１分散台帳で第１ブロックチェーンを管理する第１ノードと、それぞれ第２分散台帳で第２ブロックチェーンを管理する複数の第２ノードとを含み、サービス対象の利用に用いられるシステムにおける前記第１ノードの制御方法をコンピュータに実行させるためのプログラムであって、前記サービス対象の利用に際して前記サービス対象のロックを解除したことを示す第１トランザクションデータであって、前記サービス対象の利用を行う第１契約を一意に識別する第１契約ＩＤを含む第１トランザクションデータを生成し、前記第１トランザクションデータを含むブロックを前記第１ブロックチェーンに格納することを、コンピュータに実行させるためのプログラムである。
　以下、図面を参照しながら、実施の形態について説明する。なお、以下で説明する実施の形態は、いずれも本開示の一具体例を示すものである。つまり、以下の実施の形態で示される数値、形状、材料、構成要素、構成要素の配置及び接続形態、ステップ、ステップの順序などは、一例であり、本開示を限定する主旨ではない。また、以下の実施の形態における構成要素のうち、最上位概念を示す独立請求項に記載されていない構成要素は、本開示の課題を達成するために必ずしも必要ではないが、より好ましい形態を構成する構成要素として説明される。
　（実施の形態）
　まず、本開示に係るシステム構成について説明する。システムは、第１分散台帳で第１ブロックチェーンを管理する第１ノードと、それぞれ第２分散台帳で第２ブロックチェーンを管理する複数の第２ノードとを含み、サービス対象の利用に用いられる。システムは、例えば、複数の移動体をシェアリングするサービスに用いられてもよく、この場合のサービス対象は、複数の移動体である。本実施の形態では、システムは、端末（または移動体）を介してユーザから特定の移動体の利用予約を受け付けて、受け付けた利用予約に応じて特定の移動体をユーザに貸し出す。システムは、受け付けた利用予約での予約時間帯において、端末（または移動体）を介してユーザから、予約されている特定の移動体に対する貸出要求を受け付けると、ユーザへの特定の移動体の貸出を許可する。具体的には、システムは、ユーザから特定の移動体の解錠要求を受け付けると、事前に為されている利用予約を確認し、確認結果に応じて予約時間帯に特定の移動体を解錠することをユーザに許可する。
　なお、シェアリングするサービスにおける移動体は、例えば、自転車、バイク、自動車、船舶、飛行体などを含む。
　図４は、実施の形態に係るシステムの構成の一例を示す図である。
　システム１は、図４に示すように、例えば、移動体１０Ａ～１０Ｃと、端末１１Ａ～１１Ｃとを備える。この例では、移動体１０Ａ～１０Ｃのそれぞれは、同じ内容のデータを共有するための分散台帳を保有している。これらの分散台帳では、例えば、同じ構成のブロックチェーンが共有されている。
　移動体１０Ａ～１０Ｃと、端末１１Ａ～１１Ｃとは、ネットワークで接続されている。ネットワークは、例えば、インターネット、携帯電話のキャリアネットワークなどであるが、どのような通信回線またはネットワークから構成されてもよい。
　なお、以下では、移動体１０Ａ～１０Ｃのそれぞれを移動体１０とも称するが、移動体１０Ａ～１０Ｃを移動体Ａ～移動体Ｃと称する場合もある。また、端末１１Ａ～１１Ｃのそれぞれを端末１１とも称するが、端末１１Ａ～１１Ｃを端末Ａ～端末Ｃと称する場合もある。また、移動体１０Ａ～１０Ｃがそれぞれ備える分散台帳を台帳Ａ～台帳Ｃと称する場合もある。
　なお、ブロックチェーンを格納する分散台帳を管理するシステムは、パブリック型、プライベート型及びコンソーシアム型のいずれの形態であってもよい。
　図５Ａは、実施の形態に係るシステムの構成の他の一例を示す図である。
　図５Ａでは、例えば、移動体１０Ａ、１０Ｂと、端末１１Ａ、１１Ｂと、管理サーバ２０とが示されている。この例では、移動体１０Ａ、１０Ｂと、管理サーバ２０とのそれぞれは、同じ内容のデータを共有するための分散台帳を保有している。これらの分散台帳では、例えば、同じ構成のブロックチェーンが共有されている。
　移動体１０Ａ、１０Ｂと、端末１１Ａ、１１Ｂと、管理サーバ２０とは、ネットワークで接続されている。ネットワークは、例えば、インターネット、携帯電話のキャリアネットワークなどであるが、どのような通信回線またはネットワークから構成されてもよい。
　図５Ｂは、実施の形態に係るシステムの構成の他の一例を示す図である。
　図５Ｂでは、例えば、移動体１０Ａ～１０Ｃと、端末１１Ａ～１１Ｃとが示されている。この例では、端末１１Ａ～１１Ｃのそれぞれは、同じ内容のデータを共有するための分散台帳を保有している。これらの分散台帳では、例えば、同じ構成のブロックチェーンが共有されている。
　移動体１０Ａ～１０Ｃと、端末１１Ａ～１１Ｃとは、ネットワークで接続されている。ネットワークは、例えば、インターネット、携帯電話のキャリアネットワークなどであるが、どのような通信回線またはネットワークから構成されてもよい。
　図５Ｃは、実施の形態に係るシステムの構成の他の一例を示す図である。
　図５Ｃでは、例えば、移動体１０Ａ～１０Ｃと、端末１１Ａ～１１Ｃとが示されている。この例では、移動体１０Ａ～１０Ｃと、端末１１Ａ～１１Ｃとのそれぞれは、同じ内容のデータを共有するための分散台帳を保有している。これらの分散台帳では、例えば、同じ構成のブロックチェーンが共有されている。
　移動体１０Ａ～１０Ｃと、端末１１Ａ～１１Ｃとは、ネットワークで接続されている。ネットワークは、例えば、インターネット、携帯電話のキャリアネットワークなどであるが、どのような通信回線またはネットワークから構成されてもよい。
　以下では、図４のシステムにおける各構成について説明する。なお、図５Ａ～図５Ｃのシステムの構成については、図４のシステムと比較して分散台帳を保有する装置または端末が異なるだけであり、同様に適用可能である。
　まず、移動体１０Ａ～１０Ｃに搭載されている移動体装置について説明する。なお、以下では、移動体１０Ａ～１０Ｃに搭載されている移動体装置を、それぞれ移動体装置Ａ～移動体装置Ｃと称する場合もある。
　［移動体装置１００］
　移動体装置１００は、分散台帳でブロックチェーンを管理するノードの一例である。なお、ノードは制御装置と言い換えることができる。
　移動体装置１００は、移動体１０に搭載されている情報処理装置であり、分散台帳を保有している。移動体装置１００は、スマートフォン及びタブレットなどの携帯端末であってもよい。
　図６は、実施の形態に係る移動体装置１００の構成の一例を示す図である。
　本実施の形態に係る移動体装置１００は、入力部１０１と、トランザクションデータ生成部１０２と、トランザクションデータ検証部１０３と、ブロック生成部１０４と、同期部１０５と、スマートコントラクト実行部１０６と、ブロックチェーン管理部１０７と、分散台帳記憶部１０８と、状態記憶部１０９と、不正検知部１１０と、通信部１１１と、表示部１１２とを備える。
　＜入力部１０１＞
　入力部１０１は、ユーザからの入力を受け付ける。入力部１０１は、受け付けた情報入力を、表示部１１２に表示したり、トランザクションデータ生成部１０２に送信したり、通信部１１１に送信したりする。例えば、入力部１０１は、返却を示す情報入力をユーザから受け付けてもよい。
　＜トランザクションデータ生成部１０２＞
　トランザクションデータ生成部１０２は、トランザクションデータを生成する。
　本実施の形態では、トランザクションデータ生成部１０２は、ユーザに移動体１０を貸し出したことを示す貸出トランザクションデータを生成する。具体的には、トランザクションデータ生成部１０２は、ユーザへの移動体１０の貸出が行われた場合、ユーザに移動体１０を貸し出したことを示す貸出トランザクションデータを生成する。トランザクションデータ生成部１０２は、例えば、ユーザからの解錠要求を受け付けて移動体の解錠が行われた場合、貸出トランザクションデータを生成する。貸出トランザクションデータは、ユーザＩＤと、利用予約を識別するための予約番号（予約ＩＤ）と、ユーザに移動体１０を貸し出した時刻のタイムスタンプとを含む。
　また、本実施の形態では、トランザクションデータ生成部１０２は、ユーザに移動体１０の解錠が完了したことを示す解錠完了トランザクションデータを生成する。具体的には、トランザクションデータ生成部１０２は、例えば、ユーザからの解錠要求を受け付けて移動体１０の解錠が行われた場合、解錠完了トランザクションデータを生成する。解錠完了トランザクションデータは、移動体１０を解錠したユーザＩＤと、移動体１０を解錠した移動体装置１００の装置ＩＤ、対応する予約番号（予約ＩＤ）と、移動体１０が解錠された日時とを含む。移動体１０が解錠された日時は、移動体１０が解錠された時刻のタイムスタンプであってもよい。
　つまり、本実施の形態では、トランザクションデータ生成部１０２は、例えば、ユーザからの解錠要求を受け付けて移動体１０の解錠が行われた場合、解錠完了トランザクションデータを生成し、その後、貸出トランザクションデータを生成する。
　また、トランザクションデータ生成部１０２は、ユーザが移動体１０を返却したことを示す返却トランザクションデータを生成する。具体的には、トランザクションデータ生成部１０２は、ユーザにより移動体１０の返却が行われた場合、ユーザが移動体１０を返却したことを示す返却トランザクションデータを生成する。ユーザにより移動体１０の返却が行われたことは、入力部１０１が返却を示す情報入力をユーザから受け付けることで判断されてもよいし、端末１１を介して返却を示す情報入力をユーザから受け付ける（つまり、端末１１から情報入力を通信部１１１が受信する）ことで判断されてもよいし、ユーザにより移動体１０に対して施錠が行われたことで判断されてもよいし、予め定められている移動体１０の返却施設において移動体の返却が受け付けられたときに返却施設から送信される通知を通信部１１１が受信することで判断されてもよい。返却トランザクションデータは、ユーザＩＤと、予約番号（予約ＩＤ）と、ユーザが移動体１０を返却した時刻のタイムスタンプとを含む。
　なお、予約トランザクションデータは、端末１１Ａによって生成されるが、移動体装置１００がユーザから利用予約を受け付ける場合には、トランザクションデータ生成部１０２は、利用予約を行うための予約トランザクションデータを生成してもよい。具体的には、トランザクションデータ生成部１０２は、ユーザから利用予約のための入力が入力部１０１に行われた場合、利用予約を示す予約情報を含む予約トランザクションデータを生成する。予約情報は、ユーザＩＤと、利用予約を識別するための予約番号（予約ＩＤ）と、ユーザが移動体１０を利用する時間帯を示す予約時間帯とを含む。予約情報には、さらに、利用予約が行われた移動体１０を識別するための装置ＩＤが含まれてもよい。
　また、トランザクションデータ生成部１０２は、不正検知部１１０により、所定条件を満たす解錠完了トランザクションデータが検知された場合、サービス対象である移動体１０の利用に不正があった旨を示すインシデントレポートを含むトランザクションデータを生成してもよい。
　＜トランザクションデータ検証部１０３＞
　トランザクションデータ検証部１０３は、通信部１１１がトランザクションデータを受信したとき検証アルゴリズムを実行し、そのトランザクションデータの正当性を検証する。そして、トランザクションデータ検証部１０３は、正当性が検証されたトランザクションデータを状態記憶部１０９のトランザクションプールの領域に格納する。状態記憶部１０９に格納された正当性が検証されたトランザクションデータは、通信部１１１によって、次に生成するブロックに格納すべきトランザクションデータの情報として、他の移動体装置１００に送信される。
　例えば、トランザクションデータ検証部１０３は、通信部１１１が受信したトランザクションデータに、正しい方法で生成された電子署名が付与されているかなどを検証する。ここで、通信部１１１が受信するトランザクションデータは、予約トランザクションデータ、解錠完了トランザクションデータ、貸出トランザクションデータ、及び、返却トランザクションデータのいずれかである。つまり、トランザクションデータ検証部１０３は、予約トランザクションデータ、解錠完了トランザクションデータ、貸出トランザクションデータ、及び、返却トランザクションデータの正当性を検証する。
　なお、トランザクションデータ検証部１０３は、トランザクションデータがトランザクションデータ生成部１０２により生成される場合には、トランザクションデータの正当性の検証を行わなくてもよい。
　＜ブロック生成部１０４＞
　ブロック生成部１０４は、トランザクションデータ検証部１０３により正当性が検証されたトランザクションデータを含むブロックを生成する。ブロック生成部１０４は、状態記憶部１０９に記憶されている検証済みの複数のトランザクションデータの中から所定の数のトランザクションデータを含むブロックを生成する。ブロック生成部１０４は、複数のトランザクションデータのうちのまだブロック生成の対象となっていない複数のトランザクションデータの中から、ブロック生成の対象とする複数のブロックを選択する。ブロック生成部１０４は、既にブロック生成の対象となった複数のトランザクションデータを状態記憶部１０９から削除してもよい。
　なお、移動体装置１００のブロック生成部１０４で生成されるブロックと、他の移動体装置１００のブロック生成部１０４で生成されるブロックとは異なっていてもよい。これは、各移動体装置１００の通信状態によって状態記憶部１０９に格納されている検証済みのトランザクションデータが移動体装置１００毎に異なっていたり、ブロック生成部１０４におけるブロック生成の判断基準が異なっていたりするためである。
　なお、ブロック生成の判断基準（ブロックに格納すべきトランザクションデータに関するルール）は、各移動体装置１００が保持していてもよい。ブロック生成部１０４は、ブロック生成部１０４を備える移動体装置１００が保持しているブロック生成の判断基準に基づいて、状態記憶部１０９に格納されている検証済みの複数のトランザクションデータから、複数のトランザクションデータを選択し、選択した複数のトランザクションデータを含むブロックを生成する。
　＜同期部１０５＞
　同期部１０５は、他の移動体装置１００との間で、ブロック生成部１０４において生成されたブロックの同期を行う。
　本実施の形態では、同期部１０５は、他の移動体装置１００に、通信部１１１を介してブロック生成部１０４において生成されたブロックを送信する。そして、同期部１０５は、送信したブロックについて、他の移動体装置１００との間で共同でコンセンサスアルゴリズムを実行する。コンセンサスアルゴリズムには、ＰＢＦＴ（Practical Byzantine Fault Tolerance）とよばれるコンセンサスアルゴリズムを用いてもよいし、その他の公知のコンセンサスアルゴリズムを用いてもよい。公知のコンセンサスアルゴリズムとしては、例えばＰＯＷ（Proof Of Work）またはＰＯＳ（Proof Of Stake）などがある。なお、ＰＢＦＴを用いる場合、同期部１０５は、まず、他の移動体装置１００のそれぞれからトランザクションデータの検証が成功したか否かを示す報告を受け取り、当該報告の数が所定の数を超えたか否かを判定する。そして、同期部１０５は、当該報告の数が所定の数を超えたとき、コンセンサスアルゴリズムによってトランザクションデータの正当性が検証された場合であると判定してもよい。このように、同期部１０５は、他の移動体装置１００のそれぞれから通知された報告に基づき、トランザクションデータが正当なトランザクションデータであること（つまり正当性）を合意し、ブロックの正当性を合意する。
　また、同期部１０５は、合意済みのブロックを分散台帳記憶部１０８に記憶されている分散台帳で管理されている第１ブロックチェーンに連結する。
　＜スマートコントラクト実行部１０６＞
　スマートコントラクト実行部１０６は、分散台帳記憶部１０８の分散台帳に格納されたトランザクションデータに含まれるコントラクトコードなどを実行することで、スマートコントラクトを動作させる。
　《予約ＳＣ》
　本実施の形態では、スマートコントラクト実行部１０６は、予約スマートコントラクトを動作させることで、サービス対象である移動体の利用予約を行う予約処理を行わせてもよい。スマートコントラクト実行部１０６は、分散台帳記憶部１０８に記憶される分散台帳内のブロックチェーンに予約トランザクションデータを含むブロックが追加された場合、予約処理を行わせてもよい。
　《料金徴収ＳＣ》
　本実施の形態では、スマートコントラクト実行部１０６は、料金徴収スマートコントラクトを動作させることで、料金算定処理を行わせてもよい。スマートコントラクト実行部１０６は、分散台帳記憶部１０８に記憶される分散台帳内のブロックチェーンに返却トランザクションデータを含むブロックが追加された場合、料金算定処理を行わせる。なお、料金算定処理は、後述するブロックチェーン管理部１０７により行われる処理と同じである。
　また、スマートコントラクト実行部１０６は、分散台帳内のブロックチェーンに解錠完了トランザクションデータが格納され、かつ、解錠完了トランザクションデータに含まれる予約ＩＤに対応する予約に対する利用料金が未徴収であるかを料金徴収スマートコントラクトに確認させてもよい。さらに、スマートコントラクト実行部１０６は、解錠完了トランザクションデータが格納され、かつ、未徴収である場合、料金徴収スマートコントラクトに当該予約に対する利用料金の徴収を実行させてもよい。
　《不正検知ＳＣ》
　また、本実施の形態では、スマートコントラクト実行部１０６は、不正検知スマートコントラクトを動作させることで、不正検知処理を行わせてもよい。スマートコントラクト実行部１０６は、分散台帳記憶部１０８に記憶される分散台帳内のブロックチェーンに予約トランザクションデータを含むブロックが追加された場合、不正検知処理を行わせる。なお、不正検知処理は、後述する不正検知部１１０により行われる処理と同じである。
　このように、スマートコントラクト実行部１０６は、スマートコントラクトを動作させることで、利用料金の徴収、不正な予約の検知などを分散台帳によって管理することができる。なお、料金徴収スマートコントラクト、及び、不正検知スマートコントラクトは、例えば、ユーザにより端末１１のアプリケーションにより生成され、これらのスマートコントラクトを含むブロックが予めブロックチェーンに格納されているものとする。
　＜ブロックチェーン管理部１０７＞
　ブロックチェーン管理部１０７は、分散台帳記憶部１０８に記憶される分散台帳（以下、第１分散台帳と称する）で管理されているブロックチェーン（以下、第１ブロックチェーンと称する）を管理する。
　《主鎖・側鎖》
　本実施の形態では、ブロックチェーン管理部１０７は、通信部１１１を介して他の移動体装置１００が保有する分散台帳（以下、第２分散台帳と称する）で管理されているブロックチェーン（以下、第２ブロックチェーンと称する）を取得し、分散台帳記憶部１０８の第１分散台帳で管理されている第１ブロックチェーンと、取得した第２ブロックチェーンとを比較する。ブロックチェーン管理部１０７は、比較によって、第１ブロックチェーンを構成している複数のブロックと、第２ブロックチェーンを構成している複数のブロックとが同じであるか否かを判定する。ブロックチェーン管理部１０７は、第１ブロックチェーンを構成している複数のブロックと、第２ブロックチェーンを構成している複数のブロックとが同じでない場合、第１ブロックチェーンに含まれ、かつ、第２ブロックチェーンに含まれていない１以上の第１差異ブロックの数と、第２ブロックチェーンに含まれ、かつ、第１ブロックチェーンに含まれていない１以上の第２差異ブロックの数とのどちらが多いか（長いか）を判定する。つまり、ブロックチェーン管理部１０７は、１以上の第１差異ブロックの数と、１以上の第２差異ブロックの数とを比較することで、どちらが主鎖ブロックであるか、及び、どちらが側鎖ブロックであるかを決定する。なお、この決定は、第１ブロックチェーン及び第２ブロックチェーンの比較の結果、第１ブロックチェーンが１以上の第１差異ブロックを有し、かつ、第２ブロックチェーンが１以上の第２差異ブロックを有する場合に行われる。
　ブロックチェーン管理部１０７は、１以上の第１差異ブロック及び１以上の第２差異ブロックのうち多い方（長い方）を、第１ブロックチェーン及び第２ブロックチェーンで互いに共通する１以上の共通ブロックの後に追加する。そして、ブロックチェーン管理部１０７は、さらに、追加した多い方の後に１以上の第１差異ブロック及び１以上の第２差異ブロックのうち少ない方（短い方）に含まれる１以上のトランザクションデータを含む１以上のブロックを追加する。つまり、ブロックチェーン管理部１０７は、１以上の第１差異ブロック及び１以上の第２差異ブロックのうち多い方を主鎖ブロックとして決定し、１以上の第１差異ブロック及び１以上の第２差異ブロックのうち少ない方を側鎖ブロックとして決定する。そして、ブロックチェーン管理部１０７は、１以上の共通ブロックの後に、主鎖ブロック、側鎖ブロックに含まれる１以上のトランザクションデータから生成される追加ブロックの順で、主鎖ブロック及び追加ブロックを追加する。
　このようにして、ブロックチェーン管理部１０７は、分散台帳記憶部１０８の第１分散台帳で管理されている第１ブロックチェーンを更新する。つまり、ブロックチェーン管理部１０７は、第１ブロックチェーンと、他の移動体装置１００が保有する第２分散台帳で管理されている第２ブロックチェーンとを比較して、これらのブロックチェーンの構成が異なる場合には、構成が互いに同じになるように第１ブロックチェーンを更新する。
　なお、ブロックチェーン管理部１０７は、第１ブロックチェーン及び第２ブロックチェーンの比較の結果、第１ブロックチェーンが１以上の第１差異ブロックを有していない場合、第１ブロックチェーンに１以上の第２差異ブロックを追加することで第１ブロックチェーンを更新する。
　ここで、１以上の第１差異ブロックは、例えば、移動体装置１００が他の移動体装置１００と通信できない状態で第１ブロックチェーンに追加されることで生じた、第２ブロックチェーンには含まれていないブロックである。なお、１以上の第１差異ブロックの数は、複数の他の移動体装置１００が互いに通信可能な状態である場合、１以上の第２差異ブロックの数よりも少ない可能性が高い。これは、第２ブロックチェーンは、第１ブロックチェーンを管理している移動体装置１００よりも多い台数の複数の他の移動体装置１００のそれぞれが保有する第２分散台帳で同期されて管理されているからであり、複数の他の移動体装置１００において１台の移動体装置１００よりもブロックを生成する機会が多く発生すると考えられるからである。このため、他の移動体装置１００との間で通信できない１台の移動体装置１００で生じた１以上の第１差異ブロックは、主鎖ブロックよりも側鎖ブロックとなる可能性が高い。
　１以上の第１差異ブロックは、契約に関する情報を含むトランザクションデータを含むブロックを有していてもよい。契約は、例えば移動体１０の利用予約である。契約に関する情報を含むトランザクションデータは、例えば予約トランザクションデータ、解錠完了トランザクションデータ、貸出トランザクションデータ、及び、返却トランザクションデータである。
　なお、ブロックチェーン管理部１０７は、第２ブロックチェーンの全てを取得しなくてもよく、一部を取得すればよい。例えば、ここでブロックチェーン管理部１０７に取得される第２ブロックチェーンの一部とは、前回の第１ブロックチェーンの更新が実行された後の最後のブロックより後のブロック以降の１以上のブロックである。
　《貸出処理》
　また、ブロックチェーン管理部１０７は、移動体１０をユーザに貸し出すための貸出処理を行ってもよい。この場合、ブロックチェーン管理部１０７は、通信部１１１が解錠要求を受信すると、分散台帳記憶部１０８に記憶されている第１分散台帳内の第１ブロックチェーンを参照することで、解錠要求に基づく予約が為されているか否かを確認する。具体的には、ブロックチェーン管理部１０７は、解錠要求に含まれる予約番号と同じ予約番号を含む予約トランザクションデータが第１ブロックチェーンに格納されているか否かを判定する。ブロックチェーン管理部１０７は、解錠要求に含まれる予約番号と同じ予約番号を含む予約トランザクションデータが第１ブロックチェーンに格納されている場合、解錠要求に基づく予約が為されていると判断し、移動体１０に解錠指示する。移動体１０は、解錠指示を取得すると、解錠指示に基づいて、施錠を行っているアクチュエータを動作させ、移動体の施錠を解除（解錠）する。
　解錠要求は、ユーザが利用予約において利用を予約した移動体１０のロックを解除するための情報である。解錠要求は、利用予約を特定するために少なくとも予約番号を含んでいればよい。解錠要求は、さらに、利用予約したユーザを示すユーザＩＤ、利用予約の対象の移動体１０の移動体ＩＤ、移動体１０を予約した移動体装置１００の装置ＩＤ、予約時間帯などを含んでいてもよい。
　なお、ブロックチェーン管理部１０７は、解錠要求を受信する代わりに、第１ブロックチェーンに格納されている利用予約の予約時間帯の開始時刻になった場合に、移動体装置１００が設けられている移動体に解錠指示してもよい。
　《料金算定処理》
　また、ブロックチェーン管理部１０７は、スマートコントラクト実行部１０６に実行されるスマートコントラクトの代わりに、料金算定処理を行ってもよい。ブロックチェーン管理部１０７は、前回の処理の実行から一定間隔が経過したこと、または、分散台帳記憶部１０８に記憶されている第１分散台帳内の第１ブロックチェーンに新たに連結されたブロックに返却トランザクションデータが含まれていることをトリガとして、料金算定処理を行う。ブロックチェーン管理部１０７は、分散台帳記憶部１０８の第１ブロックチェーンを検索し、互いに競合する契約をそれぞれ含む２以上のトランザクションデータが、第１分散台帳で管理されている第１ブロックチェーンに含まれるか否かを判定する。互いに競合する契約とは、例えば第１契約に含まれるサービス対象の利用を行う時間帯と第２契約に含まれるサービス対象の利用を行う時間帯とが一部重複するような契約である。本実施の形態では、互いに競合する契約としては、例えば、互いに同じ移動体ＩＤと、互いに一部の時間帯が重複している２以上の予約時間帯とを含むような第１予約と第１予約と競合する第２予約がある場合を挙げることができる。ブロックチェーン管理部１０７は、第１ブロックチェーンに競合予約が含まれる場合、第１予約を含むトランザクションデータと競合予約を含むトランザクションデータのうち、第１ブロックチェーンに先に追加されたトランザクションデータに含まれる第１予約または競合予約を履行する。つまり、ブロックチェーン管理部１０７は、重複予約があったときには、重複予約の中で最先の利用予約に対して料金を算定し、算定した料金をユーザから徴収する料金徴収処理を実行する。換言すると、ブロックチェーン管理部１０７は、重複予約の中で最先の利用予約以外の利用予約に対しては、同一ユーザからの二重徴収を防ぐために、料金算定を行わず料金徴収処理を実行しない。
　本実施の形態では、ブロックチェーン管理部１０７は、第１ブロックチェーンに所定条件を満足する解錠完了トランザクションデータがあると、解錠完了トランザクションデータをもって料金が未徴収の第１予約または競合予約の料金を徴収する。解錠完了トランザクションデータが第１ブロックチェーンに存在することから、第１予約または競合予約とがあったとしても、料金が未徴収の第１予約または競合予約により確かに移動体１０が利用されたことがわかるので、料金を徴収しても二重徴収とならないからである。
　なお、料金算定の対象となる利用予約は、第１ブロックチェーンに格納されている返却トランザクションデータに含まれる予約番号の利用予約であって、まだ料金の算定が行われていない利用予約である。つまり、既に料金の算定が行われた利用予約は、料金算定の対象から除外される。また、仮に返却トランザクションデータに含まれる予約番号に対応する利用予約が第１ブロックチェーンに格納されていない場合、返却トランザクションデータに対する料金算定は行われない。
　＜分散台帳記憶部１０８＞
　分散台帳記憶部１０８は、第１ブロックチェーンで管理されている第１分散台帳を記憶している。本実施の形態では、第１分散台帳は、予約トランザクションデータ、解錠完了トランザクションデータ、貸出トランザクションデータ、及び、返却トランザクションデータを含むブロックを第１ブロックチェーンに格納している。
　＜状態記憶部１０９＞
　状態記憶部１０９は、分散台帳の最新版のデータを記憶している記憶部である。状態記憶部１０９に記憶されているデータは、コンピュータにより変更されたり、削除されたりすることが可能なデータである。状態記憶部１０９は、例えばスマートコントラクトを実行するための変数、関数などが格納されるオンメモリの領域とトランザクションデータを格納するトランザクションプールの領域とを含む。状態記憶部１０９は、トランザクションデータ検証部１０３により正当性が検証されたトランザクションデータを記憶してもよい。状態記憶部１０９は、通信部１１１を介して取得された第２ブロックチェーンを記憶してもよい。状態記憶部１０９は、第２ブロックチェーンのうちの１以上の第２差異ブロックを記憶してもよい。状態記憶部１０９は、分散台帳記憶部１０８に記憶されている第１ブロックチェーンを記憶してもよい。状態記憶部１０９は、分散台帳に格納される前のトランザクションデータを記憶してもよい。状態記憶部１０９は、トランザクションデータにより呼び出されたスマートコントラクトを記憶してもよい。また、状態記憶部１０９は、分散台帳に格納されているスマートコントラクトの変数を記憶していてもよい。状態記憶部１０９は、トランザクションデータ生成部１０２により生成されたトランザクションデータを記憶してもよい。状態記憶部１０９は、通信部１１１により受信されたトランザクションデータを記憶してもよい。
　状態記憶部１０９は、上述した各データを一時的に記憶してもよい。
　＜不正検知部１１０＞
　不正検知部１１０は、スマートコントラクト実行部１０６に実行されるスマートコントラクトの代わりに、分散台帳記憶部１０８に記憶されている第１分散台帳で管理されている第１ブロックチェーンに、所定条件を満たす解錠完了トランザクションデータが格納されているか否かを検知する不正予約検知処理を行ってもよい。所定条件を満たす解錠完了トランザクションデータとは、例えば対応する予約がないとされる予約ＩＤを含む解錠完了トランザクションデータであってもよいし、予約がない時間に発行された解錠完了トランザクションデータであってもよい。不正検知部１１０は、不正予約検知処理において、所定条件を満たす解錠完了トランザクションデータが格納されていることを検知することで、既存の料金算定アルゴリズムでは料金徴収がされない不正予約があったことを検知できる。
　《インシデントレポート》
　また、不正検知部１１０は、所定条件を満たす解錠完了トランザクションデータが格納されていると判定した場合、サービス対象である移動体１０の利用に不正があった旨を示すインシデントレポートを作成し、トランザクションデータ生成部１０２に通知してもよい。インシデントレポートには、不正があったと判断した理由、検知した解錠完了トランザクションデータまたは解錠完了トランザクションデータを含むブロックが記載されていてもよい。不正があったと判断した理由としては、予約が競合していたこと、ブロック生成時間とブロックが連結された時間の差が大きいこと、及び、返却トランザクションデータと対応する予約が複数あること、解錠完了トランザクションデータが所定条件を満たすことなどがある。解錠完了トランザクションデータまたはそれを含むブロックは、当該解錠完了トランザクションデータに関連する１以上のトランザクションデータを含んでいてもよい。関連するトランザクションデータとは、解錠完了トランザクションデータが含む予約ＩＤを有する貸出トランザクションデータ、予約トランザクションデータなどである。
　インシデントレポートには、さらに、検知時間、対象ユーザのユーザＩＤ、及び、対象移動体に搭載された端末ＩＤのいずれかを含んでいてもよい。検知時間は、不正検知部１１０が第１ブロックチェーンに解錠完了トランザクションデータが格納されていると判定した時刻、または、解錠完了トランザクションデータを生成した時刻を示す。対象ユーザは、競合する予約トランザクションデータに含まれる予約を行ったユーザを示す。端末ＩＤは、解錠完了トランザクションデータに含まれる移動体１０の予約を行った移動体装置１００を示す。
　《不正フラグ》
　また、不正検知部１１０は、不正予約があったことを検知した場合、利用金の徴収が未徴収である旨のフラグを不正予約または不正予約に該当する予約トランザクションデータに対して付与してもよい。不正検知部１１０は、不正予約または不正予約に該当する予約トランザクションデータに、さらに、不正予約があったことを検知した移動体装置１００の装置ＩＤあるいは不正を検知した端末１１の端末ＩＤと、不正予約があったことを検知した時刻とを付与してもよい。不正検知部１１０は、フラグなどを付与したフラグ付きの不正予約または不正予約に該当する予約トランザクションデータを同期部１０５に通知する。これにより、フラグ付きの不正予約または不正予約に該当する予約トランザクションデータは、他の移動体装置１００との間で、コンセンサスアルゴリズムが実行され、各移動体装置１００のブロックチェーンに格納される。この結果、後述する料金徴収スマートコントラクトに、フラグが付与された不正予約に対する料金徴収を実行させることができる。
　＜通信部１１１＞
　通信部１１１は、ネットワークを介して情報を他の移動体装置１００または端末１１に送信したり、他の移動体装置１００または端末１１から情報を受信したりする。通信部１１１は、ネットワークを介して他の移動体装置１００または端末１１との間で通信を行う。なお、この通信は、ＴＬＳ（Transport Layer Security）によりなされてもよく、ＴＬＳ通信用の暗号鍵は通信部１１１で保持してもよい。
　本実施の形態では、通信部１１１は、端末１１から予約トランザクションデータを受信する。また、通信部１１１は、端末１１から解錠要求を受信する。また、通信部１１１は、他の移動体装置１００から、他の移動体装置１００において検証済みのトランザクションデータを受信する。通信部１１１は、他の移動体装置１００との間で、共同でコンセンサスアルゴリズムを実行するために、ブロックの送受信を行う。
　＜表示部１１２＞
　表示部１１２は、入力部１０１が受け付けた情報入力を表示する。表示部１１２は、端末１１から送信された情報を表示してもよい。表示部１１２は、移動体装置１００の返却をユーザから受け付けるための表示（ＵＩ：User Interface）を表示してもよい。
　続いて、端末１１Ａ～１１Ｃについて説明する。なお、端末１１Ａ～端末１１Ｃの構成は共通しているので、端末１１と称して説明する。
　［端末１１］
　端末１１は、ユーザにより使用される端末の一例である。端末１１は、例えばパーソナルコンピュータであってもよいし、スマートフォン及びタブレットなどの携帯端末であってもよい。
　図７は、実施の形態１に係る端末１１の構成の一例を示す図である。
　本実施の形態に係る端末１１は、入力部１１０１と、表示部１１０２と、通信部１１０３とを備える。
　＜入力部１１０１＞
　入力部１１０１は、ユーザの操作による情報入力を受け付ける。入力部１１０１は、受け付けた情報入力を、表示部１１０２に表示したり、通信部１１０３に送信したりする。
　例えば、入力部１１０１は、利用予約を行うためのアプリケーションが導入されており、利用予約を行うための表示（ＵＩ）への入力を受け付ける。この表示（ＵＩ）は、表示部１１０２に表示される。入力部１１０１は、端末１１を保有しているユーザの電子署名を受け付けて、受け付けた利用予約のための入力と電子署名とを含む予約トランザクションデータを生成する。
　また、入力部１１０１は、予約した移動体装置１００に対して解錠要求のための表示（ＵＩ）への入力を受け付ける。この表示（ＵＩ）は、表示部１１０２に表示される。入力部１１０１は、解錠要求のための入力を受け付けて、解錠要求を生成する。
　＜表示部１１０２＞
　表示部１１０２は、入力部１１０１が受け付けた情報入力を表示する。表示部１１０２は、利用予約を行うための表示（ＵＩ）を表示する。また、表示部１１０２は、解錠要求のための表示（ＵＩ）を表示する。
　＜通信部１１０３＞
　通信部１１０３は、ネットワークを介して情報を移動体装置１００に送信したり、移動体装置１００から情報を受信したりまたは通知されたりする。また、通信部１１０３は、ネットワークを介して、他の端末１１に情報を送信したり、他の端末１１からの情報を受信したりしてもよい。
　このように、通信部１１０３は、ネットワークを介して移動体装置１００または他の端末１１との間で通信を行う。なお、この通信は、ＴＬＳによりなされてもよく、ＴＬＳ通信用の暗号鍵は通信部１１０３で保持してもよい。
　例えば、通信部１１０３は、予約トランザクションデータを移動体装置１００へ送信する。また、通信部１１０３は、解錠要求を予約した移動体装置１００へ送信する。
　［システムの動作等］
　次に、以上のように構成されたシステムの動作について説明する。
　まず、比較例として、複数の移動体をシェアリングするサービスにおける移動体Ａに対する処理を正常に行う正常処理について説明し、ブロックチェーンの仕組みを悪用して移動体Ａを不正利用する場合の当該処理すなわち不正処理について説明する。その後に、不正対策した本開示の当該処理について説明する。
　［比較例の第１例］
　移動体Ａが常にオンライン状態である場合の処理を比較例の第１例として説明する。
　図８は、比較例の第１例に係るシステムの正常処理の動作概要を示すフローチャートである。図８には、移動体装置Ａ、Ｂ、Ｃがオンライン状態で移動体Ａに対する処理を正常に行う正常処理の動作の概要が示されている。図９Ａ～図９Ｃは、移動体装置Ａの台帳Ａ及び移動体装置Ｂの台帳Ｂに格納されるブロックチェーンのブロックを概念的に説明するための図である。図９Ａは、図８のステップＳ１の動作により台帳Ａ及び台帳Ｂに格納されるブロックチェーンのブロックを概念的に示す図である。図９Ｂは、図８のステップＳ３の動作により台帳Ａ及び台帳Ｂに格納されるブロックチェーンのブロックを概念的に示す図である。図９Ｃは、図８のステップＳ５の動作により台帳Ａ及び台帳Ｂに格納されるブロックチェーンのブロックを概念的に示す図である。以下では、移動体Ａを利用したいユーザが端末Ａを用いて、移動体Ａに搭載されている移動体装置Ａに対して処理を行うとして説明する。
　図８に示すように、まず、例えば端末Ａは、移動体装置Ａと通信し、移動体装置Ａが搭載されている移動体Ａの予約処理を行う（Ｓ１）。より具体的には、端末Ａは、移動体装置Ａと通信し、移動体Ａを利用予約するための予約トランザクションデータＴｒｓｖを生成して、移動体装置Ａに送信する。この場合、例えば、図９Ａに示すように、移動体装置Ａと移動体装置Ｂとが他の移動体装置と通信可能な（オンライン）状態であるので、台帳Ａ及び台帳Ｂには共に、移動体Ａを利用予約するための予約トランザクションデータＴｒｓｖを含むブロックが格納される。
　次に、例えば端末Ａは、移動体装置Ａと通信し、移動体Ａの貸出処理を行う（Ｓ３）。より具体的には、端末Ａは、移動体装置Ａと通信し、移動体Ａを利用するため移動体Ａの解錠要求を送信する。すると、移動体装置Ａは、移動体Ａを解錠させ、移動体Ａが解錠されたことをトリガに移動体Ａの貸出開始を示す貸出トランザクションデータＴｒｎｔを生成する。この場合、例えば、図９Ｂに示すように、移動体装置Ａと移動体装置Ｂとが他の移動体装置と通信可能な（オンライン）状態であるので、台帳Ａ及び台帳Ｂには共に、移動体Ａの貸出開始を示す貸出トランザクションデータＴｒｎｔを含むブロックが格納される。
　次に、例えば端末Ａは、移動体装置Ａと通信し、移動体Ａの返却処理を行う（Ｓ５）。より具体的には、端末Ａを操作したユーザは、解錠された移動体Ａを、利用予約した時間利用して、その後返却する。移動体装置Ａは、移動体Ａが返却されると、移動体Ａの返却完了を示す返却トランザクションデータＴｒｔｎを生成する。この場合、例えば、図９Ｃに示すように、移動体装置Ａと移動体装置Ｂとが他の移動体装置と通信可能な（オンライン）状態であるので、台帳Ａ及び台帳Ｂには共に、移動体Ａの返却完了を示す返却トランザクションデータＴｒｔｎを含むブロックが格納される。
　次に、移動体装置Ａなどでは、料金算定処理を行う（Ｓ７）。より具体的には、移動体装置Ａなどでは、料金算定アルゴリズムが実行されて、ユーザが行った移動体Ａの利用予約に対して移動体Ａを利用した料金が徴収される。
　続いて、図８に示すステップＳ１～Ｓ５の処理詳細すなわち予約処理、貸出処理及び返却処理の詳細についてシーケンス図を用いて説明する。以下でも、移動体Ａを利用したいユーザが端末Ａを用いて、移動体Ａに搭載されている移動体装置Ａに対して移動体Ａの予約処理、貸出処理及び返却処理を行うとして説明する。
　［比較例の第１例に係る予約処理］
　図１０は、比較例の第１例に係るシステムの予約処理を示すシーケンス図である。
　まず、端末Ａは、移動体Ａを利用したいユーザの操作に基づいて、移動体Ａを利用予約するための予約トランザクションデータＴｒｓｖを生成する（Ｓ１０１）。ここで、端末Ａすなわち端末１１Ａには、入力部１１０１としてアプリケーションが導入されており、アプリケーションがユーザの操作に基づいて予約トランザクションデータＴｒｓｖを生成してよい。
　次に、端末Ａは、移動体Ａの移動体装置Ａと通信し、ステップＳ１０１で生成した予約トランザクションデータＴｒｓｖを移動体装置Ａに送信する（Ｓ１０２）。
　次に、移動体装置Ａは、ステップＳ１０２で送信された予約トランザクションデータＴｒｓｖを受信すると、他の移動体装置である移動体装置Ｂ、Ｃに予約トランザクションデータＴｒｓｖを転送する（Ｓ１０３）。これにより、移動体装置Ｂ、Ｃは、予約トランザクションデータＴｒｓｖを取得する。
　次に、移動体装置Ａ、Ｂ、Ｃはそれぞれ、取得した予約トランザクションデータＴｒｓｖの正当性を含む検証を行う検証アルゴリズムを実行する（Ｓ１０４）。なお、予約トランザクションデータＴｒｓｖの検証が成功しなかった場合、予約処理を終了することになる。
　次に、移動体装置Ａ、Ｂ、Ｃはそれぞれ、ステップＳ１０４で実行された検証アルゴリズムにより検証済みの予約トランザクションデータＴｒｓｖをトランザクションプールに格納する（Ｓ１０５）。より具体的には、移動体装置Ａは、検証済みの予約トランザクションデータＴｒｓｖをトランザクションプールａに格納し、移動体装置Ｂは、検証済みの予約トランザクションデータＴｒｓｖをトランザクションプールｂに格納する。移動体装置Ｃは、検証済みの予約トランザクションデータＴｒｓｖをトランザクションプールｃに格納する。
　次に、移動体装置Ａ、Ｂ、Ｃは互いに、通信可能な状態であるので、次に生成するブロックに格納すべきトランザクションデータの情報をやりとりする（Ｓ１０６）。図１０に示す例では、移動体装置Ａ、Ｂ、Ｃは、次に生成するブロックに格納すべきトランザクションデータに、検証済みの予約トランザクションデータＴｒｓｖがあることを確認する。
　次に、移動体装置Ａ、Ｂ、Ｃはそれぞれ、検証済みの予約トランザクションデータＴｒｓｖを含むブロックＢｌｃ（Ｔｒｓｖ）を生成する（Ｓ１０７）。
　次に、移動体装置Ａ、Ｂ、Ｃはそれぞれ、他の移動体装置に、ステップＳ１０７で生成したブロックＢｌｃ（Ｔｒｓｖ）を送信する（Ｓ１０８）。これにより、移動体装置Ａ、Ｂ、Ｃはそれぞれ、他の移動体装置に、ブロックＢｌｃ（Ｔｒｓｖ）に含まれる予約トランザクションデータＴｒｓｖの正当性の検証が成功したことの報告を通知することができる。
　次に、移動体装置Ａ、Ｂ、Ｃは、共同でコンセンサスアルゴリズムを実行する（Ｓ１０９）。具体的には、移動体装置Ａ、Ｂ、Ｃはそれぞれ、ステップＳ１０８で通知された報告に基づき、予約トランザクションデータＴｒｓｖが正当なトランザクションデータであること（つまり正当性）を合意し、ブロックＢｌｃ（Ｔｒｓｖ）の正当性を合意する。図１０に示す例では、ブロックＢｌｃ（Ｔｒｓｖ）に含まれる予約トランザクションデータＴｒｓｖが正当なトランザクションデータであること（つまり正当性）が合意され、ブロックＢｌｃ（Ｔｒｓｖ）の正当性も合意される。なお、ステップＳ１０７及びステップＳ１０８の処理は、ステップＳ１０９でコンセンサスアルゴリズムを実行する際に行われてもよい。
　次に、移動体装置Ａ、Ｂ、Ｃはそれぞれ、ステップＳ１０９で合意済みのブロックＢｌｃ（Ｔｒｓｖ）を分散台帳内のブロックチェーンに連結する（Ｓ１１０）。より具体的には、移動体装置Ａは、合意済みのブロックＢｌｃ（Ｔｒｓｖ）を台帳Ａ内のブロックチェーンに連結し、移動体装置Ｂは、合意済みのブロックＢｌｃ（Ｔｒｓｖ）を台帳Ｂ内のブロックチェーンに連結する。移動体装置Ｃは、合意済みのブロックＢｌｃ（Ｔｒｓｖ）を台帳Ｃ内のブロックチェーンに連結する。
　これにより、図９Ａに示すように、台帳Ａ、台帳Ｂ及び台帳Ｃには共に、移動体Ａを利用予約するための予約トランザクションデータＴｒｓｖを含むブロックが格納される。
　［比較例の第１例に係る貸出処理］
　図１１は、比較例の第１例に係るシステムの貸出処理を示すシーケンス図である。
　まず、端末Ａは、移動体Ａを利用したいユーザの操作に基づいて、移動体Ａの解錠要求を移動体装置Ａに送信する（Ｓ３０１）。ここで、端末Ａすなわち端末１１Ａには、入力部１１０１としてアプリケーションが導入されており、アプリケーションがユーザの操作に基づいて移動体Ａの解錠要求を生成して送信してもよい。移動体Ａの解錠要求には、ユーザの予約ＩＤなど、対応する移動体Ａへの予約を識別できる情報が含まれている。
　次に、移動体装置Ａは、ステップＳ３０１で送信された解錠要求を受信すると、台帳Ａのブロックチェーンに解錠要求に対応する予約があるかを確認する（Ｓ３０２）。ここで、移動体装置Ａは、台帳Ａのブロックチェーンに、予約トランザクションデータＴｒｓｖがあるか否かを確認することで、解錠要求に対応する予約があるかを確認してもよい。図１０に示す例では、台帳Ａのブロックチェーンに、予約トランザクションデータＴｒｓｖが含まれているため、移動体装置Ａは台帳Ａのブロックチェーンに解錠要求に対応する予約があることを確認できる。
　次に、移動体装置Ａは、移動体Ａのロックを解除する（Ｓ３０３）。ここで、移動体装置Ａは、移動体Ａのロックを管理する機器に対して、解除指示をすることで、移動体Ａのロックを解除してもよいし、直接移動体Ａのロックを解除してもよい。
　次に、移動体装置Ａは、移動体Ａのロックが解除されたことをトリガに、移動体Ａの貸出開始を示す貸出トランザクションデータＴｒｎｔを生成する（Ｓ３０４）。貸出トランザクションデータＴｒｎｔには、移動体Ａを利用するユーザＩＤとともに貸出開始時刻とが含まれる。貸出開始時刻は、例えばロックが解除された時刻である。
　次に、移動体装置Ａは、他の移動体装置である移動体装置Ｂ、Ｃに貸出トランザクションデータＴｒｎｔを転送する（Ｓ３０５）。これにより、移動体装置Ｂ、Ｃは、貸出トランザクションデータＴｒｎｔを取得する。
　次に、移動体装置Ａ、Ｂ、Ｃはそれぞれ、貸出トランザクションデータＴｒｎｔの正当性を含む検証を行う検証アルゴリズムを実行する（Ｓ３０６）。
　次に、移動体装置Ａ、Ｂ、Ｃはそれぞれ、ステップＳ３０６で実行された検証アルゴリズムにより検証済みの貸出トランザクションデータＴｒｎｔをトランザクションプールに格納する（Ｓ３０７）。より具体的には、移動体装置Ａは、検証済みの貸出トランザクションデータＴｒｎｔをトランザクションプールａに格納し、移動体装置Ｂは、検証済みの貸出トランザクションデータＴｒｎｔをトランザクションプールｂに格納する。移動体装置Ｃは、検証済みの貸出トランザクションデータＴｒｎｔをトランザクションプールｃに格納する。
　次に、移動体装置Ａ、Ｂ、Ｃは互いに、通信可能な状態であるので、次に生成するブロックに格納すべきトランザクションデータの情報をやりとりする（Ｓ３０８）。図１１に示す例では、移動体装置Ａ、Ｂ、Ｃは、次に生成するブロックに格納すべきトランザクションデータに、検証済みの貸出トランザクションデータＴｒｎｔがあることを確認する。
　次に、移動体装置Ａ、Ｂ、Ｃはそれぞれ、検証済みの貸出トランザクションデータＴｒｎｔを含むブロックＢｌｃ（Ｔｒｎｔ）を生成する（Ｓ３０９）。
　次に、移動体装置Ａ、Ｂ、Ｃはそれぞれ、他の移動体装置に、ステップＳ３０９で生成したブロックＢｌｃ（Ｔｒｎｔ）を送信する（Ｓ３１０）。これにより、移動体装置Ａ、Ｂ、Ｃはそれぞれ、他の移動体装置に、ブロックＢｌｃ（Ｔｒｎｔ）に含まれる貸出トランザクションデータＴｒｎｔの正当性の検証が成功したことの報告を通知することができる。
　次に、移動体装置Ａ、Ｂ、Ｃは、共同でコンセンサスアルゴリズムを実行する（Ｓ３１１）。具体的には、移動体装置Ａ、Ｂ、Ｃはそれぞれ、ステップＳ３１０で通知された報告に基づき、貸出トランザクションデータＴｒｎｔが正当なトランザクションデータであること（つまり正当性）を合意し、ブロックＢｌｃ（Ｔｒｎｔ）の正当性を合意する。図１１に示す例では、ブロックＢｌｃ（Ｔｒｎｔ）に含まれる貸出トランザクションデータＴｒｎｔが正当なトランザクションデータであること（つまり正当性）が合意され、ブロックＢｌｃ（Ｔｒｎｔ）の正当性も合意される。なお、ステップＳ３０９及びステップＳ３１０の処理は、ステップＳ３１１でコンセンサスアルゴリズムを実行する際に行われてもよい。
　次に、移動体装置Ａ、Ｂ、Ｃはそれぞれ、ステップＳ３１１で合意済みのブロックＢｌｃ（Ｔｒｎｔ）を分散台帳内のブロックチェーンに連結する（Ｓ３１２）。より具体的には、移動体装置Ａは、合意済みのブロックＢｌｃ（Ｔｒｎｔ）を台帳Ａ内のブロックチェーンに連結し、移動体装置Ｂは、合意済みのブロックＢｌｃ（Ｔｒｎｔ）を台帳Ｂ内のブロックチェーンに連結する。移動体装置Ｃは、合意済みのブロックＢｌｃ（Ｔｒｎｔ）を台帳Ｃ内のブロックチェーンに連結する。
　これにより、図９Ｂに示すように、台帳Ａ、台帳Ｂ及び台帳Ｃには共に、貸出トランザクションデータＴｒｎｔを含むブロックが格納され、移動体Ａが貸出開始されたことが記録されることになる。
　［比較例の第１例に係る返却処理］
　図１２は、比較例の第１例に係るシステムの返却処理を示すシーケンス図である。
　まず、移動体Ａを利用したユーザにより移動体Ａが返却されると、移動体装置Ａは、移動体Ａが返却されたことを確認する（Ｓ５０１）。ここで、例えば、ユーザＡは、移動体Ａを所定の返却施設に置いたり、移動体Ａを所定の位置に置いて移動体装置ＡのＵＩの返却ボタンを押したりすることで、移動体Ａを返却できる。ユーザＡは、端末Ａに表示されるＵＩの返却ボタンを押して移動体Ａを返却してもよい。移動体装置Ａは、所定の返却施設または端末Ａにより移動体Ａが返却された旨のメッセージが入力されることで、移動体Ａが返却されたことを確認してもよいし、移動体装置ＡのＵＩの返却ボタンが押されたことで、移動体Ａが返却されたことを確認してもよい。
　次に、移動体装置Ａは、移動体Ａが返却されたことを確認したことをトリガに、移動体Ａの返却完了を示す返却トランザクションデータＴｒｔｎを生成する（Ｓ５０２）。返却トランザクションデータＴｒｔｎには、移動体Ａを利用するユーザＩＤと返却時刻と移動体Ａを利用したときの予約ＩＤとが含まれる。返却時刻は、例えば、移動体Ａが返却されたことを移動体装置Ａが確認した時刻である。なお、返却トランザクションデータＴｒｔｎに、予約ＩＤに含める場合に限られず、ユーザの移動体Ａの利用料金を算定できる情報を含んでいればよい。
　次に、移動体装置Ａは、他の移動体装置である移動体装置Ｂ、Ｃに返却トランザクションデータＴｒｔｎを転送する（Ｓ５０３）。これにより、移動体装置Ｂ、Ｃは、返却トランザクションデータＴｒｔｎを取得する。
　次に、移動体装置Ａ、Ｂ、Ｃはそれぞれ、取得した返却トランザクションデータＴｒｔｎの正当性を含む検証を行う検証アルゴリズムを実行する（Ｓ５０４）。
　次に、移動体装置Ａ、Ｂ、Ｃはそれぞれ、ステップＳ５０４で実行された検証アルゴリズムにより検証済みの返却トランザクションデータＴｒｔｎをトランザクションプールに格納する（Ｓ５０５）。より具体的には、移動体装置Ａは、検証済みの返却トランザクションデータＴｒｔｎをトランザクションプールａに格納し、移動体装置Ｂは、検証済みの返却トランザクションデータＴｒｔｎをトランザクションプールｂに格納する。移動体装置Ｃは、検証済みの返却トランザクションデータＴｒｔｎをトランザクションプールｃに格納する。なお、図示していないが、移動体装置Ａ、Ｂ、Ｃは互いに、通信可能な状態であるので、次に生成するブロックに格納すべきトランザクションデータの情報をやりとりする。図１２に示す例では、移動体装置Ａ、Ｂ、Ｃは、次に生成するブロックに格納すべきトランザクションデータに、検証済みの返却トランザクションデータＴｒｔｎがあることを確認する。
　次に、移動体装置Ａ、Ｂ、Ｃはそれぞれ、検証済みの返却トランザクションデータＴｒｔｎを含むブロックＢｌｃ（Ｔｒｔｎ）を生成する（Ｓ５０６）。
　次に、移動体装置Ａ、Ｂ、Ｃはそれぞれ、他の移動体装置に、ステップＳ５０６で生成したブロックＢｌｃ（Ｔｒｔｎ）を送信する（Ｓ５０７）。これにより、移動体装置Ａ、Ｂ、Ｃはそれぞれ、他の移動体装置に、ブロックＢｌｃ（Ｔｒｔｎ）に含まれる返却トランザクションデータＴｒｔｎの正当性の検証が成功したことの報告を通知することができる。
　次に、移動体装置Ａ、Ｂ、Ｃは、共同でコンセンサスアルゴリズムを実行する（Ｓ５０８）。具体的には、移動体装置Ａ、Ｂ、Ｃはそれぞれ、ステップＳ５０７で通知された報告に基づき、返却トランザクションデータＴｒｔｎが正当なトランザクションデータであること（つまり正当性）を合意し、ブロックＢｌｃ（Ｔｒｔｎ）の正当性を合意する。図１２に示す例では、ブロックＢｌｃ（Ｔｒｔｎ）に含まれる返却トランザクションデータＴｒｔｎが正当なトランザクションデータであること（つまり正当性）が合意され、ブロックＢｌｃ（Ｔｒｔｎ）の正当性も合意される。なお、ステップＳ５０６及びステップＳ５０７の処理は、ステップＳ５０８でコンセンサスアルゴリズムを実行する際に行われてもよい。
　次に、移動体装置Ａ、Ｂ、Ｃはそれぞれ、ステップＳ５０８で合意済みのブロックＢｌｃ（Ｔｒｎｔ）を分散台帳内のブロックチェーンに連結する（Ｓ５０９）。より具体的には、移動体装置Ａは、合意済みのブロックＢｌｃ（Ｔｒｔｎ）を台帳Ａ内のブロックチェーンに連結し、移動体装置Ｂは、合意済みのブロックＢｌｃ（Ｔｒｔｎ）を台帳Ｂ内のブロックチェーンに連結する。移動体装置Ｃは、合意済みのブロックＢｌｃ（Ｔｒｔｎ）を台帳Ｃ内のブロックチェーンに連結する。これにより、図９Ｃに示すように、台帳Ａ、台帳Ｂ及び台帳Ｃには共に、返却トランザクションデータＴｒｔｎを含むブロックが格納され、移動体Ａの返却完了が記録されることになる。
　次に、移動体装置Ａ、Ｂ、Ｃはそれぞれ、ブロックチェーンに格納された予約情報をチェックする（Ｓ５１０）。より具体的には、移動体装置Ａ、Ｂ、Ｃはそれぞれ、返却トランザクションデータＴｒｔｎを含むブロックが自身の台帳内のブロックチェーンに連結されることで、予約スマートコントラクトを実行させて、ブロックチェーンに格納された予約情報として予約トランザクションデータＴｒｓｖがあることを確認する。
　次に、移動体装置Ａ、Ｂ、Ｃはそれぞれ、料金算定アルゴリズムを実行する（Ｓ５１１）。図１２に示す例では、移動体Ａを利用した料金の徴収が実行される。ここで、料金算定アルゴリズムは予約スマートコントラクトに含まれるとしてもよいし、料金徴収スマートコントラクトに含まれるとしてもよい。移動体装置Ａ、Ｂ、Ｃはそれぞれ、料金徴収スマートコントラクトまたは予約スマートコントラクトを実行させて、予約トランザクションデータＴｒｓｖに含まれる移動体Ａの利用予約に対して、料金を徴収する処理を行わせてもよい。なお、料金算定アルゴリズムの実行を、図１２に示す例では返却処理の一部として説明したが、これに限らない。図８に示す料金算定処理で行われてもよい。
　［比較例に係る料金算定処理］
　続いて、図８に示すステップＳ７の料金算定処理の詳細についてフローチャートを用いて説明する。
　図１３は、比較例に係るシステムの料金算定処理の詳細を説明するためのフローチャートである。以下では、代表して移動体装置Ａで当該処理が行われる場合について説明する。
　図８に示すステップＳ７において、まず、移動体装置Ａは、料金徴収のトリガがあるかを確認する（Ｓ７１）。このトリガは、一定間隔が経過したことでもよいし、台帳Ａのブロックチェーンに新たに連結されたブロックに返却トランザクションデータＴｒｔｎが含まれていることであってもよい。
　ステップＳ７１において、トリガがあったときには（Ｓ７１でＹｅｓ）、移動体装置Ａは、台帳Ａのブロックチェーン内を検索する（Ｓ７２）。なお、ステップＳ７１において、トリガがないときには（Ｓ７１でＮｏ）、移動体装置Ａは、ステップＳ７１に戻る。
　次に、移動体装置Ａは、台帳Ａのブロックチェーン内に他にも予約（つまり重複予約）があるかどうかを確認する（Ｓ７３）。
　ステップＳ７３において、重複予約があったときには（Ｓ７３でＹｅｓ）、予約すなわち返却トランザクションデータＴｒｔｎに含まれる予約ＩＤが重複予約の中で最先かどうかを確認する（Ｓ７４）。なお、ステップＳ７３において、重複予約がないときには（Ｓ７３でＮｏ）、ステップＳ７５に進む。
　ステップＳ７４において、重複予約の中で最先であったときには（Ｓ７４でＹｅｓ）、移動体装置Ａは、料金算定アルゴリズムを実行する（Ｓ７５）。これにより、予約すなわち返却トランザクションデータＴｒｔｎに含まれる移動体Ａの利用予約を示す予約ＩＤに対する料金が算定される。なお、ステップＳ７４において、重複予約の中で最先でないときには（Ｓ７４でＮｏ）、料金算定処理を終了する。
　次に、移動体装置Ａは、料金徴収処理を実行する（Ｓ７６）。これにより、ユーザが行った移動体Ａの利用予約を示す予約ＩＤに対して移動体Ａを利用した料金が徴収される。予約トランザクションデータＴｒｓｖに含まれる移動体Ａの利用予約に対して、料金を徴収する処理を行わせてもよい。
　［比較例の第２例］
　比較例の第１例では、移動体Ａがオンライン状態である場合に、複数の移動体をシェアリングするサービスにおける移動体Ａに対する予約処理、貸出処理及び返却処理を正常に行う場合について説明した。続いて、比較例の第２例として、移動体装置Ａがオフライン状態である場合に、移動体Ａに対する予約処理、貸出処理及び返却処理を正常に行い、その後、移動体装置Ａがオンライン状態に復帰する場合に行われる処理について説明する。
　図１４は、比較例の第２例に係るシステムの正常処理の動作概要を示すフローチャートである。図１４には、移動体装置Ａがオフライン状態である一方で、移動体装置Ｂ、Ｃとがオンライン状態である場合の移動体Ａに対する予約処理、貸出処理及び返却処理を正常に行う正常処理の動作の概要が示されている。図１５Ａ～図１７は、移動体装置Ａの台帳Ａ及び移動体装置Ｂの台帳Ｂに格納されるブロックチェーンを概念的に説明するための図である。図１５Ａは、図１４のステップＳ１Ａの動作により台帳Ａに格納されるブロックチェーンのブロックを概念的に示す図である。図１５Ｂは、図１４のステップＳ３Ａの動作により台帳Ａに格納されるブロックチェーンのブロックを概念的に示す図である。図１５Ｃは、図１４のステップＳ５Ａの動作により台帳Ａに格納されるブロックチェーンのブロックを概念的に示す図である。図１６及び図１７は、図１４のステップＳ６Ａの動作により台帳Ａ及び台帳Ｂに格納されるブロックチェーンのブロックを概念的に説明するための図である。以下では、移動体Ａを利用したいユーザが端末Ａを用いて、移動体Ａに搭載されている移動体装置Ａに対して処理を行うとして説明する。
　図１４に示すように、まず、例えば端末Ａは、他の移動体装置Ｂ、Ｃと通信可能でない（オフライン）状態の移動体装置Ａと通信し、オフライン状態の移動体装置Ａが搭載されている移動体Ａの予約処理を行う（Ｓ１Ａ）。つまり、端末Ａは、オフライン状態の移動体装置Ａに対して移動体Ａをローカル予約する予約処理を行う。より具体的には、端末Ａは、移動体装置Ａと通信し、移動体Ａを利用予約するための予約トランザクションデータＴｒｓｖを生成して、移動体装置Ａに送信する。この場合、例えば、図１５Ａに示すように、移動体装置Ａは移動体装置Ｂと通信可能でない（オフライン）状態であるので、台帳Ａのみに、移動体Ａを利用予約するための予約トランザクションデータＴｒｓｖを含むブロックが格納される。
　次に、例えば端末Ａは、オフライン状態の移動体装置Ａと通信し、移動体Ａの貸出処理を行う（Ｓ３Ａ）。つまり、端末Ａは、オフライン状態の移動体装置Ａに対して移動体Ａをローカル貸出する貸出処理を行う。より具体的には、端末Ａは、移動体装置Ａと通信し、移動体Ａを利用するため移動体Ａの解錠要求を送信することができる。すると、移動体装置Ａは、移動体Ａを解錠させ、移動体Ａが解錠されて移動体Ａの貸出開始を示す貸出トランザクションデータＴｒｎｔを生成する。この場合、例えば、図１５Ｂに示すように、移動体装置Ａはオフライン状態であるので、台帳Ａのみに、移動体Ａの貸出開始を示す貸出トランザクションデータＴｒｎｔを含むブロックが格納される。
　次に、例えば端末Ａは、オフライン状態の移動体装置Ａと通信し、移動体Ａの返却処理を行う（Ｓ５Ａ）。つまり、端末Ａは、オフライン状態の移動体装置Ａに対して移動体Ａをローカル返却する返却処理を行う。より具体的には、端末Ａを操作したユーザは、解錠された移動体Ａを、利用予約した時間利用して、その後返却する。移動体装置Ａは、移動体Ａが返却されると、移動体Ａの返却完了を示す返却トランザクションデータＴｒｔｎを生成する。この場合、例えば、図１５Ｃに示すように、移動体装置Ａはオフライン状態であるので、台帳Ａのみに、移動体Ａの返却完了を示す返却トランザクションデータＴｒｔｎを含むブロックが格納される。
　その後、移動体装置Ａがオンライン状態に復帰するとする。すると、移動体装置Ａがオンライン状態に復帰した時に、システムにおいて復帰時処理が行われる（Ｓ６Ａ）。より具体的には、ステップＳ１Ａ～ステップＳ５Ａでは、上述したように、移動体装置Ａが移動体装置Ｂと通信不可の（オフライン）状態になっている。このため、図１６の（ａ）に示すように、移動体装置Ａがオンライン状態に復帰した時点では、台帳Ａ及び台帳Ｂのブロックチェーンには、異なるブロックが連結されている。次いで、移動体装置Ａがオンライン状態に復帰すると、図１６の（ｂ）に示すように、移動体装置Ａの台帳Ａ及び移動体装置Ｂの台帳Ｂには、異なるブロックチェーンを共有し合うことになりフォークが発生する。ここで、オフライン状態の移動体装置Ａの台帳Ａのブロックチェーンに連結されたブロックが側鎖ブロックに該当し、オンライン状態の移動体装置Ｂの台帳Ｂのブロックチェーンに連結されたブロックが主鎖ブロックに該当する。このため、図１７の（ａ）及び（ｂ）に示すように、移動体装置Ａの台帳Ａ及び移動体装置Ｂの台帳Ｂでは、側鎖ブロックが削除され、側鎖ブロックに含まれるトランザクションデータがトランザクションプールに保存されることで、フォークが解消される。なお、図１７の（ｂ）では、予約トランザクションデータＴｒｓｖと貸出トランザクションデータＴｒｎｔと返却トランザクションデータＴｒｔｎとがトランザクションプールに保存されている。その後、図１７の（ｃ）に示すように、移動体装置Ａの台帳Ａ及び移動体装置Ｂの台帳Ｂのブロックチェーンでは、新たなブロックを生成するタイミングで、トランザクションプールに保存されたトランザクションデータを含むブロックが生成されて連結される。
　次に、移動体装置Ａなどでは、料金算定処理を行う（Ｓ７）。ステップＳ７の料金算定処理は、上述した通りであるので説明を省略する。
　続いて、図１４に示すステップＳ１Ａの予約処理、ステップＳ３Ａの貸出処理及びＳ５Ａの返却処理の詳細すなわちローカル予約、ローカル貸出及びローカル返却の詳細処理についてシーケンス図を用いて説明する。また、図１４に示すステップＳ６Ａの移動体装置Ａの通信復帰時の処理の詳細についてもシーケンス図を用いて説明する。以下、移動体Ａを利用したいユーザが端末Ａを用いて、移動体Ａに搭載されている移動体装置Ａに対して移動体Ａの予約処理、貸出処理及び返却処理を行うとして説明する。
　［比較例の第２例に係る予約処理］
　図１８は、比較例の第２例に係るシステムの予約処理すなわちローカル予約の処理を示すシーケンス図である。図１０と同様の要素には同一の符号を付しており、詳細な説明は省略する。
　まず、端末Ａは、移動体Ａを利用したいユーザの操作に基づいて、移動体Ａを利用予約するための予約トランザクションデータＴｒｓｖを生成し（Ｓ１０１）、生成した予約トランザクションデータＴｒｓｖを移動体装置Ａに送信する（Ｓ１０２）。
　次に、移動体装置Ａは、ステップＳ１０２で送信された予約トランザクションデータＴｒｓｖを受信すると、他の移動体装置である移動体装置Ｂ、Ｃに予約トランザクションデータＴｒｓｖを転送することを試みるが、失敗する（Ｓ１０３Ａ）。移動体装置Ａはオフライン状態であるため、移動体装置Ｂ、Ｃに予約トランザクションデータＴｒｓｖを転送できないからである。このため、移動体装置Ｂ、Ｃは、予約トランザクションデータＴｒｓｖを取得しない。
　次に、移動体装置Ａは、取得した予約トランザクションデータＴｒｓｖの正当性を含む検証を行う検証アルゴリズムを実行する（Ｓ１０４）。なお、予約トランザクションデータＴｒｓｖの検証が成功しなかった場合、予約処理を終了することになる。
　次に、移動体装置Ａは、ステップＳ１０４で実行された検証アルゴリズムにより検証済みの予約トランザクションデータＴｒｓｖをトランザクションプールａに格納する（Ｓ１０５）。
　次に、移動体装置Ａは、検証済みの予約トランザクションデータＴｒｓｖを含むブロックＢｌｃ（Ｔｒｓｖ）を生成する（Ｓ１０７）。なお、移動体装置Ａは、オフライン状態であるので移動体装置Ｂ、Ｃとは、次に生成するブロックに格納すべきトランザクションデータの情報をやりとりしないで、ブロックＢｌｃ（Ｔｒｓｖ）を生成する。
　次に、移動体装置Ａは、他の移動体装置である移動体装置Ｂ、Ｃに、ステップＳ１０７で生成したブロックＢｌｃ（Ｔｒｓｖ）を送信することを試みるが、失敗する（Ｓ１０８Ａ）。移動体装置Ａはオフライン状態であるため、移動体装置Ｂ、ＣにブロックＢｌｃ（Ｔｒｓｖ）を送信できないからである。
　次に、移動体装置Ａは、単独でコンセンサスアルゴリズムを実行する（Ｓ１０９Ａ）。具体的には、移動体装置Ａは、予約トランザクションデータＴｒｓｖが正当なトランザクションデータであること（つまり正当性）を単独で合意し、ブロックＢｌｃ（Ｔｒｓｖ）の正当性を単独で合意する。図１８に示す例では、移動体装置Ａは、ブロックＢｌｃ（Ｔｒｓｖ）に含まれる予約トランザクションデータＴｒｓｖが正当なトランザクションデータであること（つまり正当性）を合意することで、ブロックＢｌｃ（Ｔｒｓｖ）の正当性も合意する。なお、ステップＳ１０７の処理は、ステップＳ１０９Ａで単独でコンセンサスアルゴリズムを実行する際に行われてもよい。
　次に、移動体装置Ａは、ステップＳ１０９Ａで合意済みのブロックＢｌｃ（Ｔｒｓｖ）を台帳Ａ内のブロックチェーンに連結する（Ｓ１１０）。
　これにより、図１５Ａに示すように、台帳Ａのみに、移動体Ａを利用予約するための予約トランザクションデータＴｒｓｖを含むブロックが格納され、予約が確定されることになる。このように、オフライン状態の台帳Ａのみで自己完結して予約が確定されることを以下ではローカル予約と称する。
　［比較例の第２例に係る貸出処理］
　図１９は、比較例の第２例に係るシステムの貸出処理すなわちローカル貸出の処理を示すシーケンス図である。図１１と同様の要素には同一の符号を付しており、詳細な説明は省略する。
　まず、端末Ａは、移動体Ａを利用したいユーザの操作に基づいて、移動体Ａの解錠要求を移動体装置Ａに送信する（Ｓ３０１）。
　次に、移動体装置Ａは、ステップＳ３０１で送信された解錠要求を受信すると、台帳Ａのブロックチェーンに解錠要求に対応する予約があるかを確認し（Ｓ３０２）、移動体Ａのロックを解除する（Ｓ３０３）。
　次に、移動体装置Ａは、移動体Ａのロックが解除されたことをトリガに、移動体Ａの貸出開始を示す貸出トランザクションデータＴｒｎｔを生成する（Ｓ３０４）。
　次に、移動体装置Ａは、他の移動体装置である移動体装置Ｂ、Ｃに貸出トランザクションデータＴｒｎｔを転送することを試みるが、失敗する（Ｓ３０５Ａ）。移動体装置Ａはオフライン状態であるため、移動体装置Ｂ、Ｃに貸出トランザクションデータＴｒｎｔを転送できないからである。このため、移動体装置Ｂ、Ｃは、貸出トランザクションデータＴｒｎｔを取得しない。
　次に、移動体装置Ａは、貸出トランザクションデータＴｒｎｔの正当性を含む検証を行う検証アルゴリズムを実行する（Ｓ３０６）。
　次に、移動体装置Ａは、ステップＳ３０６で実行された検証アルゴリズムにより検証済みの貸出トランザクションデータＴｒｎｔをトランザクションプールａに格納する（Ｓ３０７）。
　次に、移動体装置Ａはそれぞれ、検証済みの貸出トランザクションデータＴｒｎｔを含むブロックＢｌｃ（Ｔｒｎｔ）を生成する（Ｓ３０９）。なお、移動体装置Ａは、オフライン状態であるので移動体装置Ｂ、Ｃとは、次に生成するブロックに格納すべきトランザクションデータの情報をやりとりしないで、ブロックＢｌｃ（Ｔｒｎｔ）を生成する。
　次に、移動体装置Ａは、他の移動体装置である移動体装置Ｂ、Ｃに、ステップＳ３０９で生成したブロックＢｌｃ（Ｔｒｎｔ）を送信することを試みるが、失敗する（Ｓ３１０Ａ）。移動体装置Ａはオフライン状態であるため、移動体装置Ｂ、ＣにブロックＢｌｃ（Ｔｒｎｔ）を送信できないからである。
　次に、移動体装置Ａは、単独でコンセンサスアルゴリズムを実行する（Ｓ３１１Ａ）。具体的には、移動体装置Ａは、貸出トランザクションデータＴｒｎｔが正当なトランザクションデータであること（つまり正当性）を単独で合意し、ブロックＢｌｃ（Ｔｒｎｔ）の正当性を単独で合意する。図１９に示す例では、移動体装置Ａは、ブロックＢｌｃ（Ｔｒｎｔ）に含まれる貸出トランザクションデータＴｒｎｔが正当なトランザクションデータであること（つまり正当性）を合意することで、ブロックＢｌｃ（Ｔｒｎｔ）の正当性も合意する。なお、ステップＳ３０９の処理は、ステップＳ３１１でコンセンサスアルゴリズムを実行する際に行われてもよい。
　次に、移動体装置Ａは、ステップＳ３１１Ａで合意済みのブロックＢｌｃ（Ｔｒｎｔ）を台帳Ａ内のブロックチェーンに連結する（Ｓ３１２）。
　これにより、図１５Ｂに示すように、台帳Ａのみに、貸出トランザクションデータＴｒｎｔを含むブロックが格納され、移動体Ａが貸出開始されたことが記録されることになる。このように、オフライン状態の台帳Ａのみで自己完結して移動体Ａが貸出開始されたことが記録されることを以下ではローカル貸出と称する。
　［比較例の第２例に係る返却処理］
　図２０は、比較例の第２例に係るシステムの返却処理を示すシーケンス図である。図１２と同様の要素には同一の符号を付しており、詳細な説明は省略する。
　まず、移動体Ａを利用したユーザにより移動体Ａが返却されると、移動体装置Ａは、移動体Ａが返却されたことを確認する（Ｓ５０１）。
　次に、移動体装置Ａは、移動体Ａが返却されたことを確認したことをトリガに、移動体Ａの返却完了を示す返却トランザクションデータＴｒｔｎを生成する（Ｓ５０２）。
　次に、移動体装置Ａは、他の移動体装置である移動体装置Ｂ、Ｃに返却トランザクションデータＴｒｔｎを転送することを試みるが、失敗する（Ｓ５０３Ａ）。移動体装置Ａはオフライン状態であるため、移動体装置Ｂ、Ｃに返却トランザクションデータＴｒｔｎを転送できないからである。このため、移動体装置Ｂ、Ｃは、返却トランザクションデータＴｒｔｎを取得しない。
　次に、移動体装置Ａは、取得した返却トランザクションデータＴｒｔｎの正当性を含む検証を行う検証アルゴリズムを実行する（Ｓ５０４）。
　次に、移動体装置Ａは、ステップＳ５０４で実行された検証アルゴリズムにより検証済みの返却トランザクションデータＴｒｔｎをトランザクションプールａに格納する（Ｓ５０５）。
　次に、移動体装置Ａは、検証済みの返却トランザクションデータＴｒｔｎを含むブロックＢｌｃ（Ｔｒｔｎ）を生成する（Ｓ５０６）。なお、移動体装置Ａは、オフライン状態であるので移動体装置Ｂ、Ｃとは、次に生成するブロックに格納すべきトランザクションデータの情報をやりとりしないで、ブロックＢｌｃ（Ｔｒｔｎ）を生成する。
　次に、移動体装置Ａは、他の移動体装置である移動体装置Ｂ、Ｃに、ステップＳ５０６で生成したブロックＢｌｃ（Ｔｒｔｎ）を送信することを試みるが、失敗する（Ｓ５０７Ａ）。移動体装置Ａはオフライン状態であるため、移動体装置Ｂ、ＣにブロックＢｌｃ（Ｔｒｔｎ）を送信できないからである。
　次に、移動体装置Ａは、単独でコンセンサスアルゴリズムを実行する（Ｓ５０８Ａ）。具体的には、移動体装置Ａは、返却トランザクションデータＴｒｔｎが正当なトランザクションデータであること（つまり正当性）を単独で合意し、ブロックＢｌｃ（Ｔｒｔｎ）の正当性を単独で合意する。図２０に示す例では、移動体装置Ａは、ブロックＢｌｃ（Ｔｒｔｎ）に含まれる返却トランザクションデータＴｒｔｎが正当なトランザクションデータであること（つまり正当性）を合意することで、ブロックＢｌｃ（Ｔｒｔｎ）の正当性も合意する。なお、ステップＳ５０６の処理は、ステップＳ５０８Ａでコンセンサスアルゴリズムを実行する際に行われてもよい。
　次に、移動体装置Ａは、ステップＳ５０８Ａで合意済みのブロックＢｌｃ（Ｔｒｔｎ）を台帳Ａ内のブロックチェーンに連結する（Ｓ５０９）。これにより、図１５Ｃに示すように、台帳Ａのみに、返却トランザクションデータＴｒｔｎを含むブロックが格納され、移動体Ａの返却完了が記録されることになる。このように、オフライン状態の台帳Ａのみで自己完結して移動体Ａの返却完了が記録されることを以下ではローカル返却と称する。
　次に、移動体装置Ａは、ブロックチェーンに格納された予約情報をチェックする（Ｓ５１０）。より具体的には、移動体装置Ａ、Ｂ、Ｃはそれぞれ、返却トランザクションデータＴｒｔｎが自身の台帳内のブロックチェーンに連結されることで、予約スマートコントラクトを実行させて、ブロックチェーンに格納された予約情報として予約トランザクションデータＴｒｓｖがあることを確認する。
　そして、移動体装置Ａは、料金算定アルゴリズムを実行する（Ｓ５１１）。
　［比較例の第２例に係る移動体装置Ａの通信復帰時の処理］
　続いて、図１４に示すステップＳ６Ａの移動体装置Ａの通信復帰時の処理の詳細について説明する。
　図２１は、比較例の第２例に係る移動体装置Ａの通信復帰時に行われるシステムの処理を示すシーケンス図である。
　まず、移動体装置Ａは、他の移動体装置である移動体装置Ｂ、Ｃと通信可能（オンライン状態）に復帰したとする（Ｓ６０１）。移動体装置Ａは、移動体Ａに搭載されているので、移動体Ａの所在位置によってはオフライン状態となったり、オンライン状態になったりし得る。
　すると、移動体装置Ａは、他の移動体装置である移動体装置Ｂ、Ｃに、信号を送信する（Ｓ６０２）。信号は、移動体装置Ａがオンライン状態になったことを通知できるなんらかの信号であればよい。
　次に、移動体装置Ａ、Ｂ、Ｃは、各台帳内のブロックチェーンの異同判定を行う（Ｓ６０３）。より具体的には、移動体装置Ａは、台帳Ａ内のブロックチェーンと他の移動体装置である移動体装置Ｂ、Ｃの台帳Ｂ、Ｃ内のブロックチェーンとの異同を判定する。移動体装置Ｂ、Ｃは、台帳Ｂ、Ｃ内のブロックチェーンと他の移動体装置である移動体装置Ａの台帳Ａ内のブロックチェーンとの異同を判定する。ここでは、図１６の（ａ）に示す例のように、台帳Ａと、台帳Ｂ、Ｃとのブロックチェーンには異なるブロックが連結されており、台帳Ａ内のブロックチェーンと台帳Ｂ、Ｃ内のブロックチェーンとは異なる。このため、図１６の（ｂ）に示す例のように、移動体装置Ａ、Ｂ、Ｃでは、台帳Ａ、Ｂ、Ｃにおいて、異なるブロックチェーンを共有し合うのでフォークが発生する。
　次に、移動体装置Ａ、Ｂ、Ｃは、側鎖ブロックと主鎖ブロックとに該当するブロックについての情報を送信しあう（Ｓ６０４、Ｓ６０５）。本比較例では、一定時間オフライン状態であった移動体装置Ａの台帳Ａのブロックチェーンに連結されたブロックが側鎖ブロックに該当する。移動体装置Ｂ、Ｃの台帳Ｂ、Ｃのブロックチェーンに連結されたブロックは主鎖ブロックに該当することになる。
　次に、移動体装置Ａ、Ｂ、Ｃはそれぞれ、ステップＳ６０４で得た側鎖ブロックのトランザクションデータＴｐｏｌをトランザクションプールに格納する（Ｓ６０６）。より具体的には、移動体装置Ａは、台帳Ａのブロックチェーンに連結された側鎖ブロックのトランザクションデータＴｐｏｌのコピーをトランザクションプールａに格納する。移動体装置Ｂは、側鎖ブロックのトランザクションデータＴｐｏｌをトランザクションプールｂに格納し、移動体装置Ｃは、側鎖ブロックのトランザクションデータＴｐｏｌをトランザクションプールｃに格納する。
　次に、移動体装置Ａ、Ｂ、Ｃはそれぞれ、台帳Ａ、Ｂ、Ｃのブロックチェーンと同一となるように更新する（Ｓ６０７）。より具体的には、移動体装置Ａは、台帳Ａのブロックチェーンに連結されていた側鎖ブロックを削除し、主鎖ブロックを残すことで、台帳Ｂ、Ｃのブロックチェーンと同一となるように台帳Ａのブロックチェーンを更新する。移動体装置Ｂは、台帳Ｂのブロックチェーンに連結されていた側鎖ブロックを削除し、主鎖ブロックを残すことで、台帳Ａ、Ｃのブロックチェーンと同一となるように台帳Ｂのブロックチェーンを更新する。移動体装置Ｃは、台帳Ｃのブロックチェーンに連結されていた側鎖ブロックを削除し、主鎖ブロックを残すことで、台帳Ａ、Ｂのブロックチェーンと同一となるように台帳Ｃのブロックチェーンを更新する。
　次に、所定時間後のブロック生成タイミングにおいて、移動体装置Ａ、Ｂ、Ｃはそれぞれ、トランザクションプールに格納しているトランザクションデータＴｐｏｌを含むブロックＢｌｃ（Ｔｐｏｌ）を生成する（Ｓ６１４）。
　次に、移動体装置Ａ、Ｂ、Ｃはそれぞれ、他の移動体装置に、ステップＳ６１４で生成したブロックＢｌｃ（Ｔｐｏｌ）を送信する（Ｓ６１５）。
　次に、移動体装置Ａ、Ｂ、Ｃは、共同でコンセンサスアルゴリズムを実行する（Ｓ６１６）。具体的には、移動体装置Ａ、Ｂ、Ｃはそれぞれ、トランザクションデータＴｐｏｌが正当なトランザクションデータであること（つまり正当性）を合意し、ブロックＢｌｃ（Ｔｐｏｌ）の正当性を合意する。図２１に示す例では、ブロックＢｌｃ（Ｔｐｏｌ）に含まれるトランザクションデータＴｐｏｌが正当なトランザクションデータであること（つまり正当性）が合意され、ブロックＢｌｃ（Ｔｐｏｌ）の正当性も合意される。なお、ステップＳ６１４及びステップＳ６１５の処理は、ステップＳ６１６でコンセンサスアルゴリズムを実行する際に行われてもよい。
　次に、移動体装置Ａ、Ｂ、Ｃはそれぞれ、ステップＳ６１６で合意済みのブロックＢｌｃ（Ｔｐｏｌ）を分散台帳内のブロックチェーンに連結する（Ｓ６１７）。より具体的には、移動体装置Ａは、合意済みのブロックＢｌｃ（Ｔｐｏｌ）を台帳Ａ内のブロックチェーンに連結し、移動体装置Ｂは、合意済みのブロックＢｌｃ（Ｔｐｏｌ）を台帳Ｂ内のブロックチェーンに連結する。移動体装置Ｃは、合意済みのブロックＢｌｃ（Ｔｐｏｌ）を台帳Ｃ内のブロックチェーンに連結する。これにより、図１７の（ｃ）に示すように、予約トランザクションデータＴｒｓｖと貸出トランザクションデータＴｒｎｔと返却トランザクションデータＴｒｔｎとを含むブロックが格納され、移動体Ａのローカル予約、ローカル貸出及びローカル返却が記録されることになる。
　次に、移動体装置Ａは、ブロックチェーンに格納された予約情報をチェックする（Ｓ６２０）。より具体的には、移動体装置Ａ、Ｂ、Ｃはそれぞれ、返却トランザクションデータＴｒｔｎを含むブロックが自身の台帳内のブロックチェーンに連結されることで、予約スマートコントラクトを実行させて、ブロックチェーンに格納された予約情報として予約トランザクションデータＴｒｓｖがあることを確認する。
　そして、移動体装置Ａ、Ｂ、Ｃはそれぞれ、料金算定アルゴリズムを実行する（Ｓ６２１）。なお、ステップＳ６２１の処理は、上述したステップＳ５１１の処理と同じであるので説明を省略する。
　［比較例に係るブロック連結処理］
　続いて、ブロックチェーンに生成したブロックを連結するブロック連結処理の比較例について説明する。
　図２２は、比較例に係るシステムのブロック連結処理を説明するためのフローチャートである。以下では、代表して移動体装置Ａでブロック連結処理が行われる場合について説明する。
　まず、移動体装置Ａは、トランザクションデータを取得または生成した場合（Ｓ１００１）、取得または生成したトランザクションデータの検証を行う検証アルゴリズムを実行する（Ｓ１００２）。
　次に、移動体装置Ａは、ステップＳ１００２で実行された検証アルゴリズムにより検証済みのトランザクションデータをトランザクションプールに格納する（Ｓ１００３）。
　次に、移動体装置Ａは、台帳Ａのブロックチェーンにブロックを連結するトリガが有るかを確認する（Ｓ１００４）。ここでのトリガは、例えば数分間などの一定間隔が経過したことである。
　ステップＳ１００４において、トリガが有ったときには（Ｓ１００４でＹｅｓ）、移動体装置Ａは、他の移動体と通信可能かを確認する（Ｓ１００５）。なお、ステップＳ１００４において、トリガがないときには（Ｓ１００４でＮｏ）、ステップＳ１００１から処理を繰り返す。
　ステップＳ１００５において、移動体装置Ａは、他の移動体と通信可能でない場合すなわちオフライン状態である場合（Ｓ１００５でＮｏ）、移動体装置Ａは、単独でコンセンサスアルゴリズムを実行する（Ｓ１００６）。移動体装置Ａは、取得または生成したトランザクションデータを含むブロックチェーンのブロックを生成し、コンセンサスアルゴリズムを実行することで合意形成を行う。なお、移動体装置Ａは、取得または生成したトランザクションデータの正当性を検証し、当該トランザクションデータを含むブロックを生成してもよい。
　次に、移動体装置Ａは、生成したブロックを、台帳Ａのブロックチェーンに連結する（Ｓ１００７）。
　一方、ステップＳ１００５において、移動体装置Ａは、他の移動体と通信可能である場合（Ｓ１００５でＹｅｓ）、移動体装置Ａは、他の移動体と共同でコンセンサスアルゴリズムを実行する（Ｓ１００８）。移動体装置Ａ及び他の移動体のそれぞれは、当該トランザクションデータを含むブロックチェーンのブロックを生成し、コンセンサスアルゴリズムを実行することで生成したブロックに対する合意形成を行う。
　次に、移動体装置Ａは、台帳Ａのブロックチェーンと他の移動体の台帳内のブロックチェーンとが同じか否かを判定する（Ｓ１００９）。
　ステップＳ１００９において、同じ場合には（Ｓ１００９でＹｅｓ）、移動体装置Ａは、台帳Ａのブロックチェーンに合意済のブロックを連結する（Ｓ１０１０）。
　一方、ステップＳ１００９において、同じでない場合には（Ｓ１００９でＮｏ）、側鎖となる方のブロックすなわち側鎖ブロックの当該トランザクションデータをトランザクションプールに格納する（Ｓ１０１１）。
　次に、移動体装置Ａは、他の移動体の台帳内のブロックチェーンと同じになるように台帳Ａのブロックチェーンを更新する（Ｓ１０１２）。
　次に、移動体装置Ａは、ステップＳ１００９で合意済のブロックを台帳Ａのブロックチェーンに連結する（Ｓ１０１３）。
　［比較例の第３例］
　続いて、ブロックチェーンの仕組みを悪用して移動体Ａを不正利用する不正処理について説明する。比較例の第３例では、移動体装置Ａがオフライン状態である場合に、移動体Ａに対して不正な予約処理と正常な貸出処理を行い、その後、移動体装置Ａをオンライン状態に復帰させて返却処理を行う場合について説明する。
　図２３は、比較例の第３例に係るシステムの不正処理の動作概要を示すフローチャートである。図２４Ａ～図２７は、移動体装置Ａの台帳Ａ及び移動体装置Ｂの台帳Ｂに格納されるブロックチェーンを概念的に説明するための図である。図２４Ａは、図２３のステップＳ１０の動作により台帳Ａに格納されるブロックチェーンのブロックを概念的に示す図である。図２４Ｂは、図２３のステップＳ１１の動作により台帳Ａに格納されるブロックチェーンのブロックを概念的に示す図である。図２４Ｃは、図２３のステップＳ１２の動作により台帳Ａに格納されるブロックチェーンのブロックを概念的に示す図である。図２５及び図２６は、図２３のステップＳ１３の動作により台帳Ａ及び台帳Ｂに格納されるブロックチェーンのブロックを概念的に説明するための図である。図２７は、図２３のステップＳ１４の動作により台帳Ａ及び台帳Ｂに格納されるブロックチェーンのブロックを概念的に示す図である。以下では、移動体Ａを利用したいユーザが端末Ａを用いて、移動体Ａに搭載されている移動体装置Ａに対して不正処理を行うとして説明する。
　図２３に示すように、まず、例えば端末Ａは、オフライン状態の移動体装置Ａに対して、当該移動体装置Ａが搭載されている移動体Ａの予約処理を行う（Ｓ１０）。ここでは、上述したように、端末Ａは、オフライン状態の移動体装置Ａに対して移動体Ａをローカル予約する予約処理を行う。より具体的には、端末Ａは、移動体装置Ａと通信し、移動体Ａを利用予約するための予約トランザクションデータＴｒｓｖＡを生成して、移動体装置Ａに送信することができる。この場合、例えば、図２４Ａに示すように、移動体装置Ａはオフライン状態であるので、台帳Ａのみに、移動体Ａを利用予約するための予約トランザクションデータＴｒｓｖＡを含むブロックが格納される。
　次に、端末Ａを用いたりユーザ個人のスマートフォンを用いたりなどなんらかの手段により、オンライン状態の移動体装置Ｂに対して、ステップＳ１０で行った移動体Ａのローカル予約の時間帯が被るように移動体Ａの予約処理を行う（Ｓ１１）。つまり、オンライン状態の移動体装置Ｂに対して移動体Ａのローカル予約と競合するように移動体Ａの競合予約処理を行う。本比較例では、ユーザは、端末Ａを用いて、移動体Ａを競合予約するための予約トランザクションデータＴｒｓｖＢを生成して、オンライン状態の移動体装置Ｂに対して送信する。この場合、例えば、図２４Ｂに示すように、移動体装置Ｂ等は、オフラインである移動体装置Ａの台帳Ａを除く台帳Ｂ等に、移動体Ａを競合予約するための予約トランザクションデータＴｒｓｖＢを含むブロックが格納される。
　次に、例えば端末Ａは、オフライン状態の移動体装置Ａと通信し、移動体Ａの貸出処理を行う（Ｓ１２）。つまり、上述したが、端末Ａは、オフライン状態の移動体装置Ａに対して移動体Ａをローカル貸出する貸出処理を行う。より具体的には、端末Ａは、移動体装置Ａと通信し、移動体Ａを利用するため移動体Ａの解錠要求を送信することで、移動体装置Ａに、移動体Ａを解錠させ、移動体Ａが解錠されたことをトリガに移動体Ａの貸出開始を示す貸出トランザクションデータＴｒｎｔＡを生成させる。この場合、例えば、図２４Ｃに示すように、移動体装置Ａはオフライン状態であるので、台帳Ａのみに、移動体Ａの貸出開始を示す貸出トランザクションデータＴｒｎｔＡを含むブロックが格納される。
　次に、ユーザは移動体装置Ａをオンライン状態に復帰させるとする。すると、移動体装置Ａがオンライン状態に復帰した時に、システムにおいて復帰時処理が行われる（Ｓ１３）。
　より具体的には、ステップＳ１０～ステップＳ１２では、上述したように、移動体装置Ａがオフライン状態であるため、図２５の（ａ）に示すように、移動体装置Ａがオンライン状態に復帰した時点では、台帳Ａ及び台帳Ｂのブロックチェーンには、異なるブロックが連結されている。次いで、移動体装置Ａがオンライン状態に復帰すると、図２５の（ｂ）に示すように、移動体装置Ａの台帳Ａ及び移動体装置Ｂの台帳Ｂには、異なるブロックチェーンを共有し合うことになりフォークが発生する。ここで、オフライン状態の移動体装置Ａの台帳Ａのブロックチェーンに連結されたブロックが側鎖ブロックに該当し、オンライン状態の移動体装置Ｂの台帳Ｂのブロックチェーンに連結されたブロックが主鎖ブロックに該当する。このため、図２６の（ａ）及び（ｂ）に示すように、移動体装置Ａの台帳Ａ及び移動体装置Ｂの台帳Ｂでは、側鎖ブロックが削除され、側鎖ブロックに含まれるトランザクションデータがトランザクションプールに保存されることで、フォークが解消される。なお、図２６の（ｂ）では、予約トランザクションデータＴｒｓｖＡと貸出トランザクションデータＴｒｎｔＡとがトランザクションプールに保存されている。その後、図２６の（ｃ）に示すように、移動体装置Ａの台帳Ａ及び移動体装置Ｂの台帳Ｂのブロックチェーンでは、新たなブロックを生成するタイミングで、トランザクションプールに保存されたトランザクションデータを含むブロックが生成されて連結される。
　次に、例えば端末Ａは、オンライン状態の移動体装置Ａと通信し、移動体Ａの返却処理を行う（Ｓ１４）。より具体的には、端末Ａを操作したユーザは、解錠された移動体Ａを、利用予約した時間利用して、その後返却する。移動体装置Ａは、移動体Ａが返却されると、移動体Ａの返却完了を示す返却トランザクションデータＴｒｔｎＡを生成する。この場合、例えば、図２７に示すように、移動体装置Ａはオンライン状態であるので、台帳Ａ、Ｂ等のすべてに、移動体Ａの返却完了を示す返却トランザクションデータＴｒｔｎＡを含むブロックが格納される。
　次に、移動体装置Ａなどでは、料金算定処理を行う（Ｓ１５）。ステップＳ１５の料金算定処理は、ステップＳ７の料金算定処理と同じ処理であるので説明を省略する。予約トランザクションデータＴｒｓｖＡと予約トランザクションデータＴｒｓｖＢとが競合しており、予約トランザクションデータＴｒｓｖＡを含むブロックの方が、予約トランザクションデータＴｒｓｖＢを含むブロックよりも時間的に後となる後ろに連結される。この結果、予約トランザクションデータＴｒｓｖＡに対応する予約に対しての料金は徴収されないので、予約トランザクションデータＴｒｓｖＡに対応する予約において移動体Ａを利用した料金を払わないという不正が成立してしまう。
　続いて、図２３に示すステップＳ１０のローカル予約の処理、ステップＳ１１の競合予約の処理、及びステップＳ１２のローカル貸出の処理の詳細についてシーケンス図を用いて説明する。
　［比較例の第３例に係る予約処理］
　図２８は、比較例の第３例に係るシステムのローカル予約を行う場合の処理を示すシーケンス図である。図１８と同様の要素には同様の符号を付しており、詳細な説明は省略する。
　まず、端末Ａは、移動体Ａを利用したいユーザの操作に基づいて、移動体Ａを利用予約するための予約トランザクションデータＴｒｓｖＡを生成し（Ｓ１０１Ｂ）、生成した予約トランザクションデータＴｒｓｖＡを移動体装置Ａに送信する（Ｓ１０２Ｂ）。
　次に、移動体装置Ａは、ステップＳ１０２Ｂで送信された予約トランザクションデータＴｒｓｖＡを受信すると、他の移動体装置である移動体装置Ｂ、Ｃに予約トランザクションデータＴｒｓｖＡを転送することを試みるが、失敗する（Ｓ１０３Ｂ）。移動体装置Ａはオフライン状態であるため、移動体装置Ｂ、Ｃに予約トランザクションデータＴｒｓｖＡを転送できないからである。
　次に、移動体装置Ａは、取得した予約トランザクションデータＴｒｓｖＡの正当性を含む検証を行う検証アルゴリズムを実行する（Ｓ１０４Ｂ）。
　次に、移動体装置Ａは、ステップＳ１０４Ｂで実行された検証アルゴリズムにより検証済みの予約トランザクションデータＴｒｓｖＡをトランザクションプールａに格納する（Ｓ１０５Ｂ）。
　次に、移動体装置Ａは、検証済みの予約トランザクションデータＴｒｓｖＡを含むブロックＢｌｃ（ＴｒｓｖＡ）を生成する（Ｓ１０７Ｂ）。
　次に、移動体装置Ａは、他の移動体装置である移動体装置Ｂ、Ｃに、ステップＳ１０７Ｂで生成したブロックＢｌｃ（ＴｒｓｖＡ）を送信することを試みるが、失敗する（Ｓ１０８Ｂ）。移動体装置Ａはオフライン状態であるため、移動体装置Ｂ、ＣにブロックＢｌｃ（ＴｒｓｖＡ）を送信できないからである。
　次に、移動体装置Ａは、単独でコンセンサスアルゴリズムを実行する（Ｓ１０９Ｂ）。なお、ステップＳ１０７Ｂの処理は、ステップＳ１０９Ｂで単独でコンセンサスアルゴリズムを実行する際に行われてもよい。
　次に、移動体装置Ａは、ステップＳ１０９Ｂで合意済みのブロックＢｌｃ（ＴｒｓｖＡ）を台帳Ａ内のブロックチェーンに連結する（Ｓ１１０Ｂ）。
　これにより、図２４Ａに示すように、台帳Ａのみに、移動体Ａを利用予約するための予約トランザクションデータＴｒｓｖＡを含むブロックが格納され、ローカル予約が確定されることになる。
　図２９は、比較例の第３例に係るシステムの競合予約を行う場合の処理を示すシーケンス図である。
　まず、ユーザは例えば端末Ａを用いて、移動体Ａを競合予約するための予約トランザクションデータＴｒｓｖＢを生成する（Ｓ１０１Ｃ）。
　次に、ユーザは例えば端末Ａを用いて、移動体装置Ｂに対して、ステップＳ１０１Ｃで生成した予約トランザクションデータＴｒｓｖＢを送信する（Ｓ１０２Ｃ）。
　次に、移動体装置Ｂは、オンライン状態であるので、ステップＳ１０２Ｃで送信された予約トランザクションデータＴｒｓｖＢを受信すると、他の移動体装置である移動体装置Ｃに予約トランザクションデータＴｒｓｖＢを転送する（Ｓ１０３Ｃ）。これにより、移動体装置Ａを除く移動体装置Ｃは、予約トランザクションデータＴｒｓｖＢを取得する。
　次に、移動体装置Ｂ、Ｃはそれぞれ、取得した予約トランザクションデータＴｒｓｖＢの正当性を含む検証を行う検証アルゴリズムを実行する（Ｓ１０４Ｃ）。
　次に、移動体装置Ｂ、Ｃはそれぞれ、ステップＳ１０４Ｃで実行された検証アルゴリズムにより検証済みの予約トランザクションデータＴｒｓｖＢをトランザクションプールに格納する（Ｓ１０５Ｃ）。より具体的には、移動体装置Ｂは、検証済みの予約トランザクションデータＴｒｓｖＢをトランザクションプールｂに格納し、移動体装置Ｃは、検証済みの予約トランザクションデータＴｒｓｖＢをトランザクションプールｃに格納する。
　次に、移動体装置Ｂ、Ｃは互いに、通信可能な状態であるので、次に生成するブロックに格納すべきトランザクションデータの情報をやりとりする（Ｓ１０６Ｃ）。図２９に示す例では、移動体装置Ｂ、Ｃは、次に生成するブロックに格納すべきトランザクションデータに、検証済みの予約トランザクションデータＴｒｓｖＢがあることを確認する。
　次に、移動体装置Ｂ、Ｃはそれぞれ、検証済みの予約トランザクションデータＴｒｓｖＢを含むブロックＢｌｃ（ＴｒｓｖＢ）を生成する（Ｓ１０７Ｃ）。
　次に、移動体装置Ｂ、Ｃはそれぞれ、移動体装置Ａを除く他の移動体装置に、ステップＳ１０７Ｃで生成したブロックＢｌｃ（ＴｒｓｖＢ）を送信する（Ｓ１０８Ｃ）。これにより、移動体装置Ｂ、Ｃはそれぞれ、移動体装置Ａを除く他の移動体装置に、ブロックＢｌｃ（ＴｒｓｖＢ）に含まれる予約トランザクションデータＴｒｓｖＢの正当性の検証が成功したことの報告を通知することができる。
　次に、移動体装置Ｂ、Ｃは、共同でコンセンサスアルゴリズムを実行する（Ｓ１０９Ｃ）。具体的には、移動体装置Ｂ、Ｃはそれぞれ、ステップＳ１０８Ｃで通知された報告に基づき、予約トランザクションデータＴｒｓｖＢが正当なトランザクションデータであること（つまり正当性）を合意し、ブロックＢｌｃ（ＴｒｓｖＢ）の正当性を合意する。なお、ステップＳ１０７Ｃ及びステップＳ１０８Ｃの処理は、ステップＳ１０９Ｃでコンセンサスアルゴリズムを実行する際に行われてもよい。
　次に、移動体装置Ｂ、Ｃはそれぞれ、ステップＳ１０９Ｃで合意済みのブロックＢｌｃ（ＴｒｓｖＢ）を分散台帳内のブロックチェーンに連結する（Ｓ１１０Ｃ）。より具体的には、移動体装置Ｂは、合意済みのブロックＢｌｃ（ＴｒｓｖＢ）を台帳Ｂ内のブロックチェーンに連結し、移動体装置Ｃは、合意済みのブロックＢｌｃ（ＴｒｓｖＢ）を台帳Ｃ内のブロックチェーンに連結する。
　これにより、図２４Ｂに示すように、台帳Ｂ及び台帳Ｃには共に、予約トランザクションデータＴｒｓｖＢを含むブロックが格納される。
　［比較例の第３例に係る貸出処理］
　図３０は、比較例の第３例に係るシステムのローカル貸出の処理を示すシーケンス図である。図１９と同様の要素には同様の符号を付しており、詳細な説明は省略する。
　まず、端末Ａは、移動体Ａを利用するユーザの操作に基づいて、移動体Ａの解錠要求を移動体装置Ａに送信する（Ｓ３０１Ｂ）。
　次に、移動体装置Ａは、ステップＳ３０１Ｂで送信された解錠要求を受信すると、台帳Ａのブロックチェーンに解錠要求に対応する予約があるかを確認し（Ｓ３０２Ｂ）、移動体Ａのロックを解除する（Ｓ３０３Ｂ）。
　次に、移動体装置Ａは、移動体Ａのロックが解除されたことをトリガに、移動体Ａの貸出開始を示す貸出トランザクションデータＴｒｎｔＡを生成する（Ｓ３０４Ｂ）。
　次に、移動体装置Ａは、他の移動体装置である移動体装置Ｂ、Ｃに貸出トランザクションデータＴｒｎｔＡを転送することを試みるが、失敗する（Ｓ３０５Ｂ）。移動体装置Ａはオフライン状態であるため、移動体装置Ｂ、Ｃに貸出トランザクションデータＴｒｎｔＡを転送できないからである。
　次に、移動体装置Ａは、貸出トランザクションデータＴｒｎｔＡの正当性を含む検証を行う検証アルゴリズムを実行する（Ｓ３０６Ｂ）。
　次に、移動体装置Ａは、ステップＳ３０６Ｂで実行された検証アルゴリズムにより検証済みの貸出トランザクションデータＴｒｎｔＡをトランザクションプールａに格納する（Ｓ３０７Ｂ）。
　次に、移動体装置Ａはそれぞれ、検証済みの貸出トランザクションデータＴｒｎｔＡを含むブロックＢｌｃ（ＴｒｎｔＡ）を生成する（Ｓ３０９Ｂ）。
　次に、移動体装置Ａは、他の移動体装置である移動体装置Ｂ、Ｃに、ステップＳ３０９Ｂで生成したブロックＢｌｃ（ＴｒｎｔＡ）を送信することを試みるが、失敗する（Ｓ３１０Ｂ）。移動体装置Ａはオフライン状態であるため、移動体装置Ｂ、ＣにブロックＢｌｃ（ＴｒｎｔＡ）を送信できないからである。
　次に、移動体装置Ａは、単独でコンセンサスアルゴリズムを実行する（Ｓ３１１Ｂ）。具体的には、移動体装置Ａは、貸出トランザクションデータＴｒｎｔＡが正当なトランザクションデータであること（つまり正当性）を単独で合意し、ブロックＢｌｃ（ＴｒｎｔＡ）の正当性を単独で合意する。なお、ステップＳ３０９Ｂの処理は、ステップＳ３１１Ｂでコンセンサスアルゴリズムを実行する際に行われてもよい。
　次に、移動体装置Ａは、ステップＳ３１１Ｂで合意済みのブロックＢｌｃ（ＴｒｎｔＡ）を台帳Ａ内のブロックチェーンに連結する（Ｓ３１２Ｂ）。
　これにより、図２４Ｃに示すように、台帳Ａのみに、貸出トランザクションデータＴｒｎｔＡを含むブロックが格納され、移動体Ａのローカル貸出が行われたことが記録される。
　［比較例の第３例に係る移動体装置Ａの通信復帰時の処理］
　続いて、図２３に示すステップＳ１３の移動体装置Ａの通信復帰時の処理の詳細について説明する。
　図３１は、比較例の第３例に係る移動体装置Ａの通信復帰時に行われるシステムの処理を示すシーケンス図である。図２１と同様の要素には同様の符号を付しており、詳細な説明は省略する。
　まず、移動体装置Ａは、他の移動体装置である移動体装置Ｂ、Ｃと通信可能（オンライン状態）に復帰したとする（Ｓ６０１Ｂ）。
　すると、移動体装置Ａは、他の移動体装置である移動体装置Ｂ、Ｃに、移動体装置Ａがオンライン状態になったことを示す信号を送信する（Ｓ６０２Ｂ）。
　次に、移動体装置Ａ、Ｂ、Ｃは、各台帳内のブロックチェーンの異同判定を行う（Ｓ６０３Ｂ）。より具体的には、移動体装置Ａは、台帳Ａ内のブロックチェーンと他の移動体装置である移動体装置Ｂ、Ｃの台帳Ｂ、Ｃ内のブロックチェーンとの異同を判定する。移動体装置Ｂ、Ｃは、台帳Ｂ、Ｃ内のブロックチェーンと他の移動体装置である移動体装置Ａの台帳Ａ内のブロックチェーンとの異同を判定する。ここでは、図２５の（ａ）に示す例のように、台帳Ａと、台帳Ｂ、Ｃとのブロックチェーンには異なるブロックが連結されており、台帳Ａ内のブロックチェーンと台帳Ｂ、Ｃ内のブロックチェーンとは異なる。このため、図２５の（ｂ）に示す例のように、移動体装置Ａ、Ｂ、Ｃでは、台帳Ａ、Ｂ、Ｃにおいて、異なるブロックチェーンを共有し合うのでフォークが発生する。
　次に、移動体装置Ａ、Ｂ、Ｃは、側鎖ブロックと主鎖ブロックとに該当するブロックについての情報を送信しあう（Ｓ６０４Ｂ、Ｓ６０５Ｂ）。本比較例では、一定時間オフライン状態であった移動体装置Ａの台帳Ａのブロックチェーンに連結されたブロックが側鎖ブロックＢｌｃ（ＴｒｓｖＡ、ＴｒｎｔＡ）に該当する。移動体装置Ｂ、Ｃの台帳Ｂ、Ｃのブロックチェーンに連結されてたブロックは主鎖ブロックＢｌｃ（ＴｒｓｖＢ）に該当する。
　次に、移動体装置Ａ、Ｂ、Ｃはそれぞれ、ステップＳ６０４Ｂで得た側鎖ブロックに含まれる予約トランザクションデータＴｒｓｖＡ、貸出トランザクションデータＴｒｎｔＡを、トランザクションプールに格納する（Ｓ６０６Ｂ）。より具体的には、移動体装置Ａは、台帳Ａのブロックチェーンに連結された側鎖ブロックのトランザクションデータＴｒｓｖＡ、ＴｒｎｔＡのコピーをトランザクションプールａに格納する。移動体装置Ｂは、側鎖ブロックのトランザクションデータＴｒｓｖＡ、ＴｒｎｔＡをトランザクションプールｂに格納し、移動体装置Ｃは、側鎖ブロックのトランザクションデータＴｒｓｖＡ、ＴｒｎｔＡをトランザクションプールｃに格納する。
　次に、移動体装置Ａ、Ｂ、Ｃはそれぞれ、台帳Ａ、Ｂ、Ｃのブロックチェーンと同一となるように更新する（Ｓ６０７Ｂ）。より具体的には、移動体装置Ａは、台帳Ａのブロックチェーンに連結されていた側鎖ブロックを削除し、主鎖ブロックを残すことで、台帳Ｂ、Ｃのブロックチェーンと同一となるように台帳Ａのブロックチェーンを更新する。移動体装置Ｂは、台帳Ｂのブロックチェーンに連結されていた側鎖ブロックを削除し、主鎖ブロックを残すことで、台帳Ａ、Ｃのブロックチェーンと同一となるように台帳Ｂのブロックチェーンを更新する。移動体装置Ｃは、台帳Ｃのブロックチェーンに連結されていた側鎖ブロックを削除し、主鎖ブロックを残すことで、台帳Ａ、Ｂのブロックチェーンと同一となるように台帳Ｃのブロックチェーンを更新する。
　次に、所定時間後のブロック生成タイミングにおいて、移動体装置Ａ、Ｂ、Ｃはそれぞれ、トランザクションプールに格納しているトランザクションデータＴｒｓｖＡ、ＴｒｎｔＡを含むブロックＢｌｃ（ＴｒｓｖＡ、ＴｒｎｔＡ）を生成する（Ｓ６１４Ｂ）。
　次に、移動体装置Ａ、Ｂ、Ｃはそれぞれ、他の移動体装置に、ステップＳ６１４Ｂで生成したブロックＢｌｃ（ＴｒｓｖＡ、ＴｒｎｔＡ）を送信する（Ｓ６１５Ｂ）。これにより、移動体装置Ａ、Ｂ、Ｃはそれぞれ、他の移動体装置に、ブロックＢｌｃ（ＴｒｓｖＡ、ＴｒｎｔＡ）に含まれるトランザクションデータＴｒｓｖＡ、ＴｒｎｔＡの正当性の検証が成功したことの報告を通知することができる。
　次に、移動体装置Ａ、Ｂ、Ｃは、共同でコンセンサスアルゴリズムを実行する（Ｓ６１６Ｂ）。具体的には、移動体装置Ａ、Ｂ、Ｃはそれぞれ、ステップＳ６１５Ｂで通知された報告に基づき、トランザクションデータＴｒｓｖＡ、ＴｒｎｔＡが正当なトランザクションデータであること（つまり正当性）を合意し、ブロックＢｌｃ（ＴｒｓｖＡ、ＴｒｎｔＡ）の正当性を合意する。なお、ステップＳ６１４Ｂ及びステップＳ６１５Ｂの処理は、ステップＳ６１６Ｂでコンセンサスアルゴリズムを実行する際に行われてもよい。
　次に、移動体装置Ａ、Ｂ、Ｃはそれぞれ、ステップＳ６１６Ｂで合意済みのブロックＢｌｃ（ＴｒｓｖＡ、ＴｒｎｔＡ）を分散台帳内のブロックチェーンに連結する（Ｓ６１７Ｂ）。より具体的には、移動体装置Ａは、合意済みのブロックＢｌｃ（ＴｒｓｖＡ、ＴｒｎｔＡ）を台帳Ａ内のブロックチェーンに連結し、移動体装置Ｂは、合意済みのブロックＢｌｃ（ＴｒｓｖＡ、ＴｒｎｔＡ）を台帳Ｂ内のブロックチェーンに連結する。移動体装置Ｃは、合意済みのブロックＢｌｃ（ＴｒｓｖＡ、ＴｒｎｔＡ）を台帳Ｃ内のブロックチェーンに連結する。これにより、図２６の（ｃ）に示すように、予約トランザクションデータＴｒｓｖＡと予約トランザクションデータＴｒｓｖＢと貸出トランザクションデータＴｒｎｔＡとを含むブロックが格納され、移動体Ａのローカル予約、競合予約及びローカル貸出が記録されることになる。
　［比較例の第３例に係る返却処理］
　続いて、図２３に示すステップＳ１４の移動体装置Ａの返却処理の詳細について説明する。
　図３２は、比較例の第３例に係るシステムの返却処理を示すシーケンス図である。図１２と同様の要素には同様の符号を付しており、詳細な説明は省略する。
　まず、移動体Ａを利用したユーザにより移動体Ａが返却されると、移動体装置Ａは、移動体Ａが返却されたことを確認する（Ｓ５０１Ｂ）。
　次に、移動体装置Ａは、移動体Ａが返却されたことを確認したことをトリガに、移動体Ａの返却完了を示す返却トランザクションデータＴｒｔｎＡを生成する（Ｓ５０２Ｂ）。
　次に、移動体装置Ａは、他の移動体装置である移動体装置Ｂ、Ｃに返却トランザクションデータＴｒｔｎＡを転送する（Ｓ５０３Ｂ）。これにより、移動体装置Ｂ、Ｃは、返却トランザクションデータＴｒｔｎＡを取得する。
　次に、移動体装置Ａ、Ｂ、Ｃはそれぞれ、取得した返却トランザクションデータＴｒｔｎＡの正当性を含む検証を行う検証アルゴリズムを実行する（Ｓ５０４Ｂ）。
　次に、移動体装置Ａ、Ｂ、Ｃはそれぞれ、ステップＳ５０４Ｂで実行された検証アルゴリズムにより検証済みの返却トランザクションデータＴｒｔｎＡをトランザクションプールに格納する（Ｓ５０５Ｂ）。より具体的には、移動体装置Ａは、検証済みの返却トランザクションデータＴｒｔｎＡをトランザクションプールａに格納し、移動体装置Ｂは、検証済みの返却トランザクションデータＴｒｔｎＡをトランザクションプールｂに格納する。移動体装置Ｃは、検証済みの返却トランザクションデータＴｒｔｎＡをトランザクションプールｃに格納する。なお、図示していないが、移動体装置Ａ、Ｂ、Ｃは互いに、通信可能な状態であるので、次に生成するブロックに格納すべきトランザクションデータの情報をやりとりする。図３２に示す例では、移動体装置Ａ、Ｂ、Ｃは、次に生成するブロックに格納すべきトランザクションデータに、検証済みの返却トランザクションデータＴｒｔｎＡがあることを確認する。
　次に、移動体装置Ａ、Ｂ、Ｃはそれぞれ、検証済みの返却トランザクションデータＴｒｔｎＡを含むブロックＢｌｃ（ＴｒｔｎＡ）を生成する（Ｓ５０６Ｂ）。
　次に、移動体装置Ａ、Ｂ、Ｃはそれぞれ、他の移動体装置に、ステップＳ５０６Ｂで生成したブロックＢｌｃ（ＴｒｔｎＡ）を送信する（Ｓ５０７Ｂ）。これにより、移動体装置Ａ、Ｂ、Ｃはそれぞれ、他の移動体装置に、ブロックＢｌｃ（ＴｒｔｎＡ）に含まれる返却トランザクションデータＴｒｔｎＡの正当性の検証が成功したことの報告を通知することができる。
　次に、移動体装置Ａ、Ｂ、Ｃは、共同でコンセンサスアルゴリズムを実行する（Ｓ５０８Ｂ）。具体的には、移動体装置Ａ、Ｂ、Ｃはそれぞれ、ステップＳ５０７Ｂで通知された報告に基づき、返却トランザクションデータＴｒｔｎＡが正当なトランザクションデータであること（つまり正当性）を合意し、ブロックＢｌｃ（ＴｒｔｎＡ）の正当性を合意する。なお、ステップＳ５０６Ｂ及びステップＳ５０７Ｂの処理は、ステップＳ５０８Ｂでコンセンサスアルゴリズムを実行する際に行われてもよい。
　次に、移動体装置Ａ、Ｂ、Ｃはそれぞれ、ステップＳ５０８Ｂで合意済みのブロックＢｌｃ（ＴｒｎｔＡ）を分散台帳内のブロックチェーンに連結する（Ｓ５０９Ｂ）。より具体的には、移動体装置Ａは、合意済みのブロックＢｌｃ（ＴｒｔｎＡ）を台帳Ａ内のブロックチェーンに連結し、移動体装置Ｂは、合意済みのブロックＢｌｃ（ＴｒｔｎＡ）を台帳Ｂ内のブロックチェーンに連結する。移動体装置Ｃは、合意済みのブロックＢｌｃ（ＴｒｔｎＡ）を台帳Ｃ内のブロックチェーンに連結する。これにより、図２７に示すように、台帳Ａ、台帳Ｂ及び台帳Ｃには共に、返却トランザクションデータＴｒｔｎＡを含むブロックが格納され、移動体Ａの返却完了が記録されることになる。
　次に、移動体装置Ａ、Ｂ、Ｃはそれぞれ、ブロックチェーンに格納された予約情報をチェックする（Ｓ５１０Ｂ）。より具体的には、移動体装置Ａ、Ｂ、Ｃはそれぞれ、返却トランザクションデータＴｒｔｎＡを含むブロックを含むブロックが自身の台帳内のブロックチェーンに連結されることで、予約スマートコントラクトを実行させて、ブロックチェーンに格納された予約情報として予約トランザクションデータＴｒｓｖがあることを確認する。
　次に、移動体装置Ａ、Ｂ、Ｃはそれぞれ、料金算定アルゴリズムを実行する（Ｓ５１１Ｂ）。ここでは、例えば図２７に示すように、予約トランザクションデータＴｒｓｖＡと予約トランザクションデータＴｒｓｖＢとが競合しており、予約トランザクションデータＴｒｓｖＡを含むブロックの方が、予約トランザクションデータＴｒｓｖＢを含むブロックよりも時間的に後となる後ろに連結されている。このため、料金算定アルゴリズムを実行されても、予約トランザクションデータＴｒｓｖＡに対応する予約に対しての料金は徴収されず、予約トランザクションデータＴｒｓｖＢに対応する予約に対しての料金のみが徴収されることになる。
　このように、予約トランザクションデータＴｒｓｖＡに対応する予約に対しての料金は徴収されないので、予約トランザクションデータＴｒｓｖＡに対応する予約において移動体Ａを利用した料金を払わないという不正が成立する。
　［比較例の第４例］
　比較例の第３例では、移動体装置Ａをオンライン状態に復帰させてから返却処理を行う場合の不正処理について説明したが、これに限らない。移動体装置Ａがオフライン状態である場合に、返却処理を行った後に移動体装置Ａをオンライン状態に復帰させてもよい。この場合の不正処理を比較例の第４例として以下説明する。
　図３３は、比較例の第４例に係るシステムの不正処理の動作概要を示すフローチャートである。図３４Ａ～図３６は、移動体装置Ａの台帳Ａ及び移動体装置Ｂの台帳Ｂに格納されるブロックチェーンを概念的に説明するための図である。図３４Ａは、図３３のステップＳ１０の動作により台帳Ａに格納されるブロックチェーンのブロックを概念的に示す図である。図３４Ｂは、図３３のステップＳ１１の動作により台帳Ａに格納されるブロックチェーンのブロックを概念的に示す図である。図３４Ｃは、図３３のステップＳ１２の動作により台帳Ａに格納されるブロックチェーンのブロックを概念的に示す図である。図３４Ｄは、図３３のステップＳ１３Ａの動作により台帳Ａに格納されるブロックチェーンのブロックを概念的に示す図である。図３５及び図３６は、図３３のステップＳ１４Ａの動作により台帳Ａ及び台帳Ｂに格納されるブロックチェーンのブロックを概念的に説明するための図である。以下でも、移動体Ａを利用したいユーザが端末Ａを用いて、移動体Ａに搭載されている移動体装置Ａに対して不正処理を行うとして説明する。
　図３３に示すステップＳ１０～ステップＳ１２は、図２３で説明したステップＳ１０～ステップＳ１２と同じ処理であるので説明を省略する。また、図３４Ａ～図３４Ｃは、図２４Ａ～図２４Ｃと同一の図であるので説明を省略する。
　次に、ステップＳ１３Ａにおいて、例えば端末Ａは、オフライン状態の移動体装置Ａと通信し、移動体Ａの返却処理を行う。つまり、端末Ａは、オフライン状態の移動体装置Ａに対して移動体Ａをローカル返却する返却処理を行う。より具体的には、端末Ａを操作したユーザは、解錠された移動体Ａを、利用予約した時間利用して、その後返却する。移動体装置Ａは、移動体Ａが返却されると、移動体Ａの返却完了を示す返却トランザクションデータＴｒｔｎＡを生成する。この場合、例えば、図３４Ｄに示すように、移動体装置Ａはオフライン状態であるので、台帳Ａのみに、移動体Ａの返却完了を示す返却トランザクションデータＴｒｔｎＡを含むブロックが格納される。
　次に、ユーザは移動体装置Ａをオンライン状態に復帰させるとする。すると、移動体装置Ａがオンライン状態に復帰した時に、システムにおいて復帰時処理が行われる（Ｓ１４Ａ）。より具体的には、ステップＳ１０～ステップＳ１３Ａでは、移動体装置Ａがオフライン状態であるため、移動体装置Ａがオンライン状態に復帰した時点では、例えば図３４Ｄに示すように、台帳Ａ及び台帳Ｂのブロックチェーンには、異なるブロックが連結されている。次いで、移動体装置Ａがオンライン状態に復帰すると、図３５に示すように、移動体装置Ａの台帳Ａ及び移動体装置Ｂの台帳Ｂには、異なるブロックチェーンを共有し合うことになりフォークが発生する。ここで、オフライン状態の移動体装置Ａの台帳Ａのブロックチェーンに連結されたブロックの方が短いため側鎖ブロックに該当し、オンライン状態の移動体装置Ｂの台帳Ｂのブロックチェーンに連結されたブロックが長いので主鎖ブロックに該当する。このため、図３６の（ａ）及び（ｂ）に示すように、移動体装置Ａの台帳Ａ及び移動体装置Ｂの台帳Ｂでは、側鎖ブロックが削除され、側鎖ブロックに含まれるトランザクションデータがトランザクションプールに保存されることで、フォークが解消される。なお、図３６の（ｂ）では、予約トランザクションデータＴｒｓｖＡと貸出トランザクションデータＴｒｎｔＡと返却トランザクションデータＴｒｔｎＡとがトランザクションプールに保存されている。その後、図３６の（ｃ）に示すように、移動体装置Ａの台帳Ａ及び移動体装置Ｂの台帳Ｂのブロックチェーンでは、新たなブロックを生成するタイミングで、トランザクションプールに保存されたトランザクションデータを含むブロックが生成されて連結される。
　次に、移動体装置Ａなどでは、料金算定処理を行う（Ｓ１５）。比較例の第３例と同様、予約トランザクションデータＴｒｓｖＡと予約トランザクションデータＴｒｓｖＢとが競合しており、予約トランザクションデータＴｒｓｖＡを含むブロックの方が、予約トランザクションデータＴｒｓｖＢを含むブロックよりも後ろに連結される。この結果、予約トランザクションデータＴｒｓｖＡに対応する予約に対しての料金は徴収されないので、予約トランザクションデータＴｒｓｖＡに対応する予約において移動体Ａを利用した料金を払わないという不正が成立する。
　続いて、図３３に示すステップＳ１３Ａのローカル返却の処理、ステップＳ１４Ａの移動体装置Ａの通信復帰時の処理の詳細についてシーケンス図を用いて説明する。
　［比較例の第４例に係る返却処理］
　図３７は、比較例の第４例に係るシステムのローカル返却の処理を示すシーケンス図である。図２０と同様の要素には同様の符号を付しており、詳細な説明は省略する。
　まず、移動体Ａを利用したユーザにより移動体Ａが返却されると、移動体装置Ａは、移動体Ａが返却されたことを確認する（Ｓ５０１Ｃ）。
　次に、移動体装置Ａは、移動体Ａが返却されたことを確認したことをトリガに、移動体Ａの返却完了を示す返却トランザクションデータＴｒｔｎＡを生成する（Ｓ５０２Ｃ）。
　次に、移動体装置Ａは、他の移動体装置である移動体装置Ｂ、Ｃに返却トランザクションデータＴｒｔｎＡを転送することを試みるが、失敗する（Ｓ５０３Ｃ）。移動体装置Ａはオフライン状態であるため、移動体装置Ｂ、Ｃに返却トランザクションデータＴｒｔｎＡを転送できないからである。
　次に、移動体装置Ａは、取得した返却トランザクションデータＴｒｔｎＡの正当性を含む検証を行う検証アルゴリズムを実行する（Ｓ５０４Ｃ）。
　次に、移動体装置Ａは、ステップＳ５０４Ｃで実行された検証アルゴリズムにより検証済みの返却トランザクションデータＴｒｔｎＡをトランザクションプールａに格納する（Ｓ５０５Ｃ）。
　次に、移動体装置Ａは、検証済みの返却トランザクションデータＴｒｔｎＡを含むブロックＢｌｃ（ＴｒｔｎＡ）を生成する（Ｓ５０６Ｃ）。
　次に、移動体装置Ａは、他の移動体装置である移動体装置Ｂ、Ｃに、ステップＳ５０６Ｃで生成したブロックＢｌｃ（ＴｒｔｎＡ）を送信することを試みるが、失敗する（Ｓ５０７Ｃ）。移動体装置Ａはオフライン状態であるため、移動体装置Ｂ、ＣにブロックＢｌｃ（ＴｒｔｎＡ）を送信できないからである。
　次に、移動体装置Ａは、単独でコンセンサスアルゴリズムを実行する（Ｓ５０８Ｃ）。具体的には、移動体装置Ａは、返却トランザクションデータＴｒｔｎＡが正当なトランザクションデータであること（つまり正当性）を単独で合意し、ブロックＢｌｃ（ＴｒｔｎＡ）の正当性を単独で合意する。なお、ステップＳ５０６Ｃの処理は、ステップＳ５０８Ｃでコンセンサスアルゴリズムを実行する際に行われてもよい。
　次に、移動体装置Ａは、ステップＳ５０８Ｃで合意済みのブロックＢｌｃ（ＴｒｔｎＡ）を台帳Ａ内のブロックチェーンに連結する（Ｓ５０９Ｃ）。これにより、図３４Ｄに示すように、台帳Ａのみに、返却トランザクションデータＴｒｔｎＡを含むブロックが格納され、移動体Ａのローカル返却が記録されることになる。
　次に、移動体装置Ａは、ブロックチェーンに格納された予約情報をチェックする（Ｓ５１０Ｃ）。より具体的には、移動体装置Ａ、Ｂ、Ｃはそれぞれ、返却トランザクションデータＴｒｔｎＡが自身の台帳内のブロックチェーンに連結されることで、予約スマートコントラクトを実行させて、ブロックチェーンに格納された予約情報として予約トランザクションデータＴｒｓｖＡがあることを確認する。
　そして、移動体装置Ａはそれぞれ、料金算定アルゴリズムを実行する（Ｓ５１１Ｃ）。移動体装置Ａはオフライン状態であるので、料金算定アルゴリズムにより、予約トランザクションデータＴｒｓｖＡに対応する予約に対しての料金が算定されることになる。
　［比較例の第４例に係る移動体装置Ａの通信復帰時の処理］
　続いて、図３３に示すステップＳ１４Ａの移動体装置Ａの通信復帰時の処理の詳細について説明する。
　図３８は、比較例の第４例に係る移動体装置Ａの通信復帰時に行われるシステムの処理を示すシーケンス図である。図２１と同様の要素には同様の符号を付しており、詳細な説明は省略する。
　まず、移動体装置Ａは、他の移動体装置である移動体装置Ｂ、Ｃと通信可能（オンライン状態）に復帰したとする（Ｓ６０１Ｃ）。
　すると、移動体装置Ａは、他の移動体装置である移動体装置Ｂ、Ｃに、移動体装置Ａがオンライン状態になったことを示す信号を送信する（Ｓ６０２Ｃ）。
　次に、移動体装置Ａ、Ｂ、Ｃは、各台帳内のブロックチェーンの異同判定を行う（Ｓ６０３Ｃ）。移動体装置Ａの通信復帰の前では、例えば図３４Ｄに示す例のように、台帳Ａと、台帳Ｂ、Ｃとのブロックチェーンには異なるブロックが連結されているので、台帳Ａ内のブロックチェーンと台帳Ｂ、Ｃ内のブロックチェーンとは異なる。このため、移動体装置Ａの通信復帰時には、例えば図３５に示す例のように、移動体装置Ａ、Ｂ、Ｃの台帳Ａ、Ｂ、Ｃでは、異なるブロックチェーンを共有し合うのでフォークが発生する。
　次に、移動体装置Ａ、Ｂ、Ｃは、側鎖ブロックと主鎖ブロックとに該当するブロックについての情報を送信しあう（Ｓ６０４Ｃ、Ｓ６０５Ｃ）。本比較例では、一定時間オフライン状態であった移動体装置Ａの台帳Ａのブロックチェーンに連結されたブロックは側鎖ブロックＢｌｃ（ＴｒｓｖＡ、ＴｒｎｔＡ、ＴｒｔｎＡ）に該当する。一方、移動体装置Ｂ、Ｃの台帳Ｂ、Ｃのブロックチェーンに連結されたブロックは主鎖ブロックＢｌｃ（ＴｒｓｖＢ）に該当することになる。
　次に、移動体装置Ａ、Ｂ、Ｃはそれぞれ、ステップＳ６０４Ｃで得た側鎖ブロックのトランザクションデータＴｒｓｖＡ、ＴｒｎｔＡ、ＴｒｔｎＡをトランザクションプールに格納する（Ｓ６０６Ｃ）。
　次に、移動体装置Ａ、Ｂ、Ｃはそれぞれ、台帳Ａ、Ｂ、Ｃのブロックチェーンと同一となるように更新する（Ｓ６０７Ｃ）。より具体的には、移動体装置Ａ、Ｂ、Ｃはそれぞれ、ブロックチェーンに連結されていた側鎖ブロックを削除し、主鎖ブロックを残すことで、台帳Ａ、Ｂ、Ｃのブロックチェーンが同一となるように台帳Ａのブロックチェーンを更新する。
　次に、所定時間後のブロック生成タイミングにおいて、移動体装置Ａ、Ｂ、Ｃはそれぞれ、トランザクションプールに格納しているトランザクションデータＴｒｓｖＡ、ＴｒｎｔＡ、ＴｒｔｎＡを含むブロックＢｌｃ（ＴｒｓｖＡ、ＴｒｎｔＡ、ＴｒｔｎＡ）を生成する（Ｓ６１４Ｃ）。
　次に、移動体装置Ａ、Ｂ、Ｃはそれぞれ、他の移動体装置に、ステップＳ６１４Ｃで生成したブロックＢｌｃ（ＴｒｓｖＡ、ＴｒｎｔＡ、ＴｒｔｎＡ）を送信する（Ｓ６１５Ｃ）。これにより、移動体装置Ａ、Ｂ、Ｃはそれぞれ、他の移動体装置に、ブロックＢｌｃ（ＴｒｓｖＡ、ＴｒｎｔＡ、ＴｒｔｎＡ）に含まれるトランザクションデータＴｒｓｖＡ、ＴｒｎｔＡ、ＴｒｔｎＡの正当性の検証が成功したことの報告を通知することができる。
　次に、移動体装置Ａ、Ｂ、Ｃは、共同でコンセンサスアルゴリズムを実行する（Ｓ６１６Ｃ）。具体的には、移動体装置Ａ、Ｂ、Ｃはそれぞれ、ステップＳ６１５Ｃで通知された報告に基づき、トランザクションデータＴｒｓｖＡ、ＴｒｎｔＡ、ＴｒｔｎＡが正当なトランザクションデータであること（つまり正当性）を合意する。そして、ブロックＢｌｃ（ＴｒｓｖＡ、ＴｒｎｔＡ、ＴｒｔｎＡ）の正当性を合意する。なお、ステップＳ６１４Ｃ及びステップＳ６１５Ｃの処理は、ステップＳ６１６Ｃでコンセンサスアルゴリズムを実行する際に行われてもよい。
　次に、移動体装置Ａ、Ｂ、Ｃはそれぞれ、ステップＳ６１６で合意済みのブロックＢｌｃ（ＴｒｓｖＡ、ＴｒｎｔＡ、ＴｒｔｎＡ）を分散台帳内のブロックチェーンに連結する（Ｓ６１７Ｃ）。より具体的には、移動体装置Ａは、合意済みのブロックＢｌｃ（ＴｒｓｖＡ、ＴｒｎｔＡ、ＴｒｔｎＡ）を台帳Ａ内のブロックチェーンに連結し、移動体装置Ｂは、合意済みのブロックＢｌｃ（ＴｒｓｖＡ、ＴｒｎｔＡ、ＴｒｔｎＡ）を台帳Ｂ内のブロックチェーンに連結する。移動体装置Ｃは、合意済みのブロックＢｌｃ（ＴｒｓｖＡ、ＴｒｎｔＡ、ＴｒｔｎＡ）を台帳Ｃ内のブロックチェーンに連結する。これにより、図３６の（ｃ）に示すように、予約トランザクションデータＴｒｓｖＡと貸出トランザクションデータＴｒｎｔＡと返却トランザクションデータＴｒｔｎＡとを含むブロックが格納され、移動体Ａのローカル予約、ローカル貸出及びローカル返却が記録されることになる。
　次に、移動体装置Ａは、ブロックチェーンに格納された予約情報をチェックする（Ｓ６２０Ｃ）。より具体的には、移動体装置Ａ、Ｂ、Ｃはそれぞれ、返却トランザクションデータＴｒｔｎＡを含むブロックが自身の台帳内のブロックチェーンに連結されることで、予約スマートコントラクトを実行させて、ブロックチェーンに格納された予約情報として予約トランザクションデータＴｒｓｖＡと予約トランザクションデータＴｒｓｖＢとがあることを確認する。
　そして、移動体装置Ａ、Ｂ、Ｃはそれぞれ、料金算定アルゴリズムを実行しない（Ｓ６２１Ｃ）。より具体的には、移動体装置Ａ、Ｂ、Ｃはそれぞれ、料金算定アルゴリズムを実行するが、予約トランザクションデータＴｒｓｖＡに対応する予約に対しての料金は徴収されない。なお、ステップＳ６２１Ｃの処理は、上述したステップＳ５１１Ｂの処理と同じであるので説明を省略する。
　ここでは、例えば図３６の（ｃ）に示すように、予約トランザクションデータＴｒｓｖＡに対応する予約と予約トランザクションデータＴｒｓｖＢとに対応する予約とが競合している。また、予約トランザクションデータＴｒｓｖＡを含むブロックの方が、予約トランザクションデータＴｒｓｖＢを含むブロックよりも後ろに連結されている。このため、料金算定アルゴリズムを実行されても、予約トランザクションデータＴｒｓｖＡに対応する予約に対しての料金は徴収されず、予約トランザクションデータＴｒｓｖＢに対応する予約に対しての料金のみが徴収されることになる。
　このように、予約トランザクションデータＴｒｓｖＡに対応する予約に対しての料金は徴収されないので、予約トランザクションデータＴｒｓｖＡに対応する予約において移動体Ａを利用した料金を払わないという不正が成立する。
　［本実施の形態に係る不正対策後の処理］
　続いて、不正処理の対策を行った本実施の形態に係る不正対策処理について説明する。
　図２３及び図３３に示される不正処理では、ステップＳ１１で競合予約が行われることにより、ステップＳ１０で予約処理されたローカル予約に対する料金が徴収されなかった。
　そこで、本実施の形態では、ステップＳ１１で競合予約が行われたとしても、ステップＳ１０で予約処理されたローカル予約に対して確実に料金が徴収されるように、図２３及び図３３のステップＳ１２において、移動体Ａが解錠されたときに、移動体Ａの解錠が完了したことを示す解錠完了トランザクションデータを生成させて、オフラインの台帳Ａのブロックチェーンに格納させる。そして、ステップＳ１１で競合予約が行われることにより、ステップＳ１０で予約処理されたローカル予約そのものに対する料金が比較例の方法では徴収できないとしても、解錠完了トランザクションデータをもってローカル予約で移動体Ａを利用した料金を徴収する。競合予約とローカル予約とがあり重複徴収してしまうように見えたとしても、解錠完了トランザクションデータがブロックチェーンに存在することから、比較例の方法では未徴収となるローカル予約により確かに移動体Ａが利用されたことがわかるからである。
　以下、不正対策処理として解錠トランザクションデータを生成させる処理について説明する。
　図３９は、実施の形態に係るシステムのローカル貸出の処理を示すシーケンス図である。図３０と同様の要素には同様の符号を付しており、詳細な説明は省略する。図４０は、図３９のローカル貸出の処理により台帳Ａに格納されるブロックチェーンのブロックを概念的に示す図である。
　まず、端末Ａは、移動体Ａを利用するユーザの操作に基づいて、移動体Ａの解錠要求を移動体装置Ａに送信する（Ｓ３０１Ｄ）。
　次に、移動体装置Ａは、ステップＳ３０１Ｄで送信された解錠要求を受信すると、台帳Ａのブロックチェーンに解錠要求に対応する予約があるかを確認し（Ｓ３０２Ｄ）、移動体Ａのロックを解除する（Ｓ３０３Ｄ）。
　次に、移動体装置Ａは、移動体Ａのロックが解除されたことをトリガに、移動体Ａの解錠が完了したことを示す解錠完了トランザクションデータＴｕｎｌを生成する（Ｓ３０３１）。この解錠完了トランザクションデータＴｕｎｌには、少なくとも移動体Ａを解錠したユーザＩＤ、移動体Ａを解錠した移動体装置Ａの装置ＩＤ、対応する予約ＩＤ及び解錠した日時とが含まれる。なお、ユーザＩＤ及び装置ＩＤの代わりに、ユーザＩＤ及び装置ＩＤを特定可能なブロックチェーンＩＤが用いられてもよい。また、対応する予約ＩＤの代わりに、当該予約ＩＤを含む予約トランザクションデータを識別できる予約トランザクションデータＩＤが用いられてもよい。
　次に、移動体装置Ａは、他の移動体装置である移動体装置Ｂ、Ｃに解錠完了トランザクションデータＴｕｎｌを転送することを試みるが、失敗する（Ｓ３０３２）。移動体装置Ａはオフライン状態であるため、移動体装置Ｂ、Ｃに貸出トランザクションデータＴｕｎｌを転送できないからである。
　また、移動体装置Ａは、移動体Ａのロックが解除されたことをトリガに、移動体Ａの貸出開始を示す貸出トランザクションデータＴｒｎｔＡを生成する（Ｓ３０４Ｄ）。
　次に、移動体装置Ａは、他の移動体装置である移動体装置Ｂ、Ｃに貸出トランザクションデータＴｒｎｔＡを転送することを試みるが、失敗する（Ｓ３０５Ｄ）。移動体装置Ａはオフライン状態であるため、移動体装置Ｂ、Ｃに貸出トランザクションデータＴｒｎｔＡを転送できないからである。
　次に、移動体装置Ａは、解錠完了トランザクションデータＴｕｎｌ及び貸出トランザクションデータＴｒｎｔＡすなわちトランザクションデータＴｕｎｌ、ＴｒｎｔＡの正当性を含む検証を行う検証アルゴリズムを実行する（Ｓ３０６Ｄ）。
　次に、移動体装置Ａは、ステップＳ３０６Ｄで実行された検証アルゴリズムにより検証済みのトランザクションデータＴｕｎｌ、ＴｒｎｔＡをトランザクションプールａに格納する（Ｓ３０７Ｄ）。
　次に、移動体装置Ａはそれぞれ、検証済みのトランザクションデータＴｕｎｌ、ＴｒｎｔＡを含むブロックＢｌｃ（Ｔｕｎｌ、ＴｒｎｔＡ）を生成する（Ｓ３０９Ｄ）。
　次に、移動体装置Ａは、他の移動体装置である移動体装置Ｂ、Ｃに、ステップＳ３０９Ｄで生成したブロックＢｌｃ（Ｔｕｎｌ、ＴｒｎｔＡ）を送信することを試みるが、失敗する（Ｓ３１０Ｄ）。移動体装置Ａはオフライン状態であるため、移動体装置Ｂ、ＣにブロックＢｌｃ（Ｔｕｎｌ、ＴｒｎｔＡ）を送信できないからである。
　次に、移動体装置Ａは、単独でコンセンサスアルゴリズムを実行する（Ｓ３１１Ｄ）。具体的には、移動体装置Ａは、トランザクションデータＴｕｎｌ、ＴｒｎｔＡが正当なトランザクションデータであること（つまり正当性）を単独で合意し、ブロックＢｌｃ（Ｔｕｎｌ、ＴｒｎｔＡ）の正当性を単独で合意する。なお、ステップＳ３０９Ｄの処理は、ステップＳ３１１Ｄでコンセンサスアルゴリズムを実行する際に行われてもよい。
　次に、移動体装置Ａは、ステップＳ３１１Ｄで合意済みのブロックＢｌｃ（Ｔｕｎｌ、ＴｒｎｔＡ）を台帳Ａ内のブロックチェーンに連結する（Ｓ３１２Ｄ）。
　これにより、図４０に示すように、予約トランザクションデータＴｒｓｖＡを含むブロックに、貸出トランザクションデータＴｒｎｔＡと解錠完了トランザクションデータＴｕｎｌとを含むブロックが連結される。
　図４１は、実施の形態に係る料金算定処理が行われる際に台帳Ａ及び台帳Ｂに格納されているブロックチェーンのブロックを概念的に示す図である。図４１には、図２３及び図３３のステップＳ１５の動作時において台帳Ａ及び台帳Ｂに格納されているブロックチェーンのブロックが示されている。
　図４１に示すように、トランザクションデータＴｕｎｌ、ＴｒｎｔＡを含むブロックは、上述したようにフォークの発生を解消するため、貸出トランザクションデータＴｒｎｔＢを含むブロックよりも後に連結されることになる。つまり、図３９に示されるオフライン貸出の処理によりオフライン状態の移動体装置Ａの台帳Ａのブロックチェーンに連結されたブロックは、競合予約の処理により台帳Ｂのブロックチェーンに連結されたブロックよりも後に連結される。
　比較例では、予約トランザクションデータＴｒｓｖＡが、予約トランザクションデータＴｒｓｖＢと競合し、予約トランザクションデータＴｒｓｖＢを含むブロックよりも後ろに連結される場合には、予約トランザクションデータＴｒｓｖＡに対応する予約に対しての料金は徴収されない。一方、本実施の形態では、予約トランザクションデータＴｒｓｖＡに対応する予約に対しての料金は徴収できないものの、解錠完了トランザクションデータＴｕｎｌがブロックチェーンに格納されていることをもってローカル予約により移動体Ａを利用した料金を徴収する。上述したように、解錠完了トランザクションデータがブロックチェーンに存在することから、競合予約とローカル予約とがあり重複徴収してしまうように見えたとしても、比較例の方法では未徴収となるローカル予約により確かに移動体Ａが利用されたことがわかるからである。
　図４２は、実施の形態に係る料金算定処理の詳細を説明するためのフローチャートである。図４２に示す本実施の形態に係る料金算定処理は、図２３及び図３３のステップＳ１５において実行される。以下では、代表して移動体装置Ａで料金算定処理が行われる場合について説明する。
　本実施の形態では、図２３及び図３３のステップＳ１５において、まず、移動体装置Ａは、料金徴収のトリガがあるかを確認する（Ｓ６２１１）。このトリガは、一定間隔が経過したことでもよいし、台帳Ａのブロックチェーンに新たに連結されたブロックに返却トランザクションデータＴｒｔｎＡが含まれていることであってもよい。
　ステップＳ６２１１において、トリガがあったときには（Ｓ６２１１でＹｅｓ）、移動体装置Ａは、台帳Ａのブロックチェーン内を検索する（Ｓ６２１２）。なお、ステップＳ６２１１において、トリガがないときには（Ｓ６２１１でＮｏ）、移動体装置Ａは、ステップＳ６２１１に戻る。
　次に、移動体装置Ａは、台帳Ａのブロックチェーン内に、解錠完了トランザクションデータがあるのに、未徴収の予約トランザクションデータがあるかどうかを判定する（Ｓ６２１３）。本実施の形態では、予約トランザクションデータＴｒｓｖＡが、予約トランザクションデータＴｒｓｖＢと競合し、予約トランザクションデータＴｒｓｖＢを含むブロックよりも後ろに連結される場合には、未徴収の予約トランザクションデータがあると判定できる。
　ステップＳ６２１３において、重複予約があったときには（Ｓ６２１３でＹｅｓ）、移動体装置Ａは、料金算定アルゴリズムを実行する（Ｓ６２１４）。これにより、解錠完了トランザクションデータに含まれる予約すなわち予約トランザクションデータＴｒｓｖＡに含まれる移動体Ａの利用予約を示す予約ＩＤに対する料金が算定される。
　次に、移動体装置Ａは、料金徴収処理を実行する（Ｓ６２１５）。これにより、予約トランザクションデータＴｒｓｖＡに含まれる予約において移動体Ａを利用した料金が徴収される。
　［効果等］
　以上のように、本実施の形態によれば、移動体Ａのロックを解除したことを示す解錠完了トランザクションデータが分散台帳それぞれのブロックチェーンに格納される。これにより、解錠完了トランザクションデータに対応する移動体Ａの利用予約が競合していても、分散台帳それぞれのブロックチェーンに格納される解錠完了トランザクションデータをトリガに移動体Ａを利用した料金を徴収することができる。
　なお、移動体Ａは、上述したように、サービス対象の一例であり、移動体Ａの利用予約は、サービス対象の契約の一例である。サービス対象のロックを解除したことを示す解錠完了トランザクションデータが第１ブロックチェーンに格納される。これにより、解錠完了トランザクションデータに対応するサービス対象の契約が競合していても、分散台帳それぞれのブロックチェーンに格納される解錠完了トランザクションデータをトリガにサービス対象を利用した料金を徴収することができる。よって、ブロックチェーンを悪用したサービス対象の不正利用を抑制できる。
　（変形例）
　なお、不正対策処理としては、解錠トランザクションデータを生成させる処理を行う場合に限られない。さらに、移動体端末Ａの通信復帰時の処理において、不正予約検知処理を実行させてもよい。本変形例では、移動体端末Ａの通信復帰時の処理におけるコンセンサスアルゴリズムの実行の際に、不正予約検知処理を実行する場合について説明する。
　図４３は、実施の形態の変形例に係る移動体装置Ａの通信復帰時に行われるシステムの処理を示すシーケンス図である。図２１と同様の要素には同様の符号を付しており、詳細な説明は省略する。図４３に示すシーケンス図は、図２１に示すシーケンス図と比較すると、コンセンサスアルゴリズムの実行の際に、不正予約検知処理を実行している点が異なる。すなわち、図４３に示すステップ６０１Ｅ～ステップＳ６１５Ｅの処理は、図２１に示すステップ６０１～ステップＳ６１５の処理と同様のため、ここでの説明を省略する。
　ステップＳ６１６Ｅにおいて、移動体装置Ａ、Ｂ、Ｃは、共同でコンセンサスアルゴリズムを実行する。本実施の形態では、移動体装置Ａ、Ｂ、Ｃはそれぞれ、ステップＳ６１５で通知された報告に基づき、トランザクションデータＴｐｏｌが正当なトランザクションデータであること（つまり正当性）を合意するコンセンサスアルゴリズムの実行の際に、不正予約検知処理を実行する。
　不正予約検知処理では、移動体装置Ａ、Ｂ、Ｃはそれぞれ、自身の台帳のブロックチェーン内を検索し、対応する予約がないとされる予約ＩＤを含む解錠完了トランザクションデータがあるかどうかを検知する。上述したように競合予約があり対応する予約がないとされる予約ＩＤを含む解錠完了トランザクションデータがあれば、既存の料金算定アルゴリズムでは料金徴収がされない不正予約があったことを検知できる。
　なお、不正予約検知処理では、移動体装置Ａ、Ｂ、Ｃはそれぞれ、自身の台帳のブロックチェーン内を検索し、予約がない時間に発行された解錠完了トランザクションデータがあるかどうかを検知してもよい。上述したように、オフライン状態の移動体装置Ａに対してローカル予約を行い、ローカル貸出を行った後、移動体装置Ａをオンライン状態に復帰させた場合には、ブロックチェーンにフォークを発生させることになる。このため、ローカル予約に対応する予約トランザクションデータとローカル貸出に伴い発行された解錠完了トランザクションデータは、移動体装置Ａをオンライン状態に復帰させた後の時間に、分散台帳のブロックチェーンに格納されることになる。つまり、ローカル予約及びローカル貸出した時間より後に、予約トランザクションデータと解錠完了トランザクションデータとが分散台帳のブロックチェーンに格納される。そして、ローカル予約及びローカル貸出した時間より後に、予約トランザクションデータと解錠完了トランザクションデータとが分散台帳のブロックチェーンに格納されることで、予約がない時間に解錠完了トランザクションデータが発行されたように見える。この結果、予約がない時間に解錠完了トランザクションデータを検知することで、不正処理が行われたかを検知することができる。
　次に、コンセンサスアルゴリズムの実行の際に、不正予約が検知されなかった場合、移動体装置Ａ、Ｂ、Ｃはそれぞれ、ステップＳ６１６Ｅで合意済みのブロックＢｌｃ（Ｔｐｏｌｖ）を分散台帳内のブロックチェーンに連結する（Ｓ６１７Ｅ）。
　なお、不正予約があったことを検知した場合には、不正なトランザクションデータが検知されたことを示す不正情報（インシデントレポート）を作成して保存してもよい。
　図４４は、実施の形態の変形例に係る不正予約検知処理を示すフローチャートである。以下でも、移動体装置Ａで不正予約検知処理が行われる場合を例に挙げて説明する。なお、実施の形態に係る不正予約検知処理は、上記のようにコンセンサスアルゴリズムを実行の際に行われる場合に限らず、独立して実行されてもよい。
　図４４に示すように、まず、移動体装置Ａは、不正チェックのトリガがあるかを確認する（Ｓ６１６１）。このトリガは、上記のようにコンセンサスアルゴリズムを実行されたことでもよいし、１０分間など一定間隔が経過したことでもよいし、ブロックを新たに生成したタイミングであってもよい。
　ステップＳ６１６１において、トリガがあったときには（Ｓ６１６１でＹｅｓ）、移動体装置Ａは、台帳Ａのブロックチェーン内を検索する（Ｓ６１６２）。なお、ステップＳ６１６１において、トリガがないときには（Ｓ６１６１でＮｏ）、移動体装置Ａは、ステップＳ６１６１に戻る。
　次に、移動体装置Ａは、台帳Ａのブロックチェーン内に、予約がない時間に連結された解錠完了トランザクションデータがあるかどうかを確認する（Ｓ６１６３）。
　ステップＳ６１６３において、予約がない時間に連結された解錠完了トランザクションデータがあったときには（Ｓ６１６３でＹｅｓ）、インシデントレポートを作成して保存する（Ｓ６１６４）。なお、ステップＳ６１６３において、予約がない時間に連結された解錠完了トランザクションデータがないときには（Ｓ６１６３でＮｏ）、この不正予約検知処理を終了する。
　図４５は、実施の形態の変形例に係る不正予約検知処理を実行してインシデントレポートを作成したときに行われるシステムの処理を示すシーケンス図である。図４３と同じ動作には同一の符号を付しており、詳細な説明は省略する。図４５では、ステップＳ６１６Ｅにおいて、移動体装置Ａ、Ｂ、Ｃは、共同でコンセンサスアルゴリズムを実行した際に行われた不正予約検知処理においてインシデントレポートを作成した後の処理が示されている。
　すなわち、図４５に示すように、ステップＳ６１６Ｅにおいて、移動体装置Ａ、Ｂ、Ｃは、共同でコンセンサスアルゴリズムを実行する。本変形例では、移動体装置Ａ、Ｂ、Ｃはそれぞれ、コンセンサスアルゴリズムの実行の際に、不正予約検知処理を実行する。図４５に示す例では、不正予約検知処理を実行すると、予約のない時間に発行された解錠完了トランザクションデータが検知され、不正予約があったことを検知したとしている。このため、移動体装置Ａ、Ｂ、Ｃは、解錠完了トランザクションデータが検知されたことを示すインシデントレポートを作成する。
　次に、例えば移動体端末Ｂは、代表して、作成したインシデントレポートを記録するためのトランザクションデータＴｉｎｃを生成する（Ｓ６２２Ｅ）。なお、移動体端末ＢがトランザクションデータＴｉｎｃを生成する場合に限らず、移動体端末Ａまたは移動体端末ＣがトランザクションデータＴｉｎｃを生成してもよい。
　次に、移動体装置Ｂは、他の移動体装置である移動体装置Ａ、ＣにトランザクションデータＴｉｎｃを転送する（Ｓ６２３Ｅ）。これにより、移動体装置Ａ、Ｃは、トランザクションデータＴｉｎｃを取得する。
　次に、移動体装置Ａ、Ｂ、Ｃはそれぞれ、トランザクションデータＴｉｎｃの検証を行う検証アルゴリズムを実行する（Ｓ６２４Ｅ）。
　次に、移動体装置Ａ、Ｂ、Ｃはそれぞれ、ステップＳ６２４Ｅで検証済みのトランザクションデータＴｉｎｃを台帳に格納する（Ｓ６２５Ｅ）。より具体的には、移動体装置Ａは、検証済みのトランザクションデータＴｉｎｃを台帳Ａに格納し、移動体装置Ｂは、検証済みのトランザクションデータＴｉｎｃを台帳Ｂに格納する。移動体装置Ｃは、検証済みのトランザクションデータＴｉｎｃを台帳Ｃ内に格納する。
　これにより、台帳Ａ、台帳Ｂ及び台帳Ｃには共に、トランザクションデータＴｉｎｃが格納され、インシデントレポートが記録されることになる。
　［その他の実施の形態等］
　以上のように、本開示について上記の実施の形態に基づいて説明してきたが、本開示は、上記の実施の形態に限定されないのはもちろんである。以下のような場合も本開示に含まれる。
　（１）上記の実施の形態では、サービス対象として、移動体を例に挙げて説明したがこれに限らない。サービス対象は、サービスが利用されないときには他のユーザが利用できないようにロックされていて、サービスを利用する際にロックが解除されるものであればよく、例えばホテルの部屋、電子ロッカーでもよい。また、契約は、例えば移動体１０の利用予約に限らず、例えばホテルの部屋の利用予約、電子ロッカーの利用予約でもよい。この場合、解錠完了トランザクションデータは、サービス対象の利用に際してサービス対象のロックを解除したことを示すトランザクションデータであって、サービス対象の利用を行う第１契約を一意に識別する第１契約ＩＤを含むトランザクションデータであればよい。また、解錠完了トランザクションデータは、予約トランザクションデータがブロックチェーンに格納され、予約時間帯にサービス対象のロックの解錠をユーザに許可したときに生成される。
　また、サービス対象の利用料金の徴収を行うための料金徴収スマートコントラクトを実行してもよい。この際、例えば、分散台帳内のブロックチェーンに解錠完了トランザクションデータが格納され、かつ、解錠完了トランザクションデータに含まれる第１契約ＩＤにより識別される第１契約に対する利用料金が未徴収であるかを料金徴収スマートコントラクトに確認させてもよい。さらに、スマートコントラクト実行部１０６は、解錠完了トランザクションデータが格納され、かつ、未徴収である場合、料金徴収スマートコントラクトに当該第１契約に対する利用料金の徴収を実行させてもよい。なお、未徴収である場合は、第１ブロックチェーン及び第２ブロックチェーンに、第１契約を行うための第２トランザクションデータと、サービス対象の利用を行う第２契約を行うための第３トランザクションデータとが格納されている場合である。そして、未徴収である場合には、第１契約に含まれるサービス対象の利用を行う時間帯と第２契約に含まれるサービス対象の利用を行う時間帯とが一部重複する場合である。
　（２）上記の実施の形態における各装置は、具体的には、マイクロプロセッサ、ＲＯＭ、ＲＡＭ、ハードディスクユニット、ディスプレイユニット、キーボード、マウスなどから構成されるコンピュータシステムである。前記ＲＡＭまたはハードディスクユニットには、コンピュータプログラムが記録されている。前記マイクロプロセッサが、前記コンピュータプログラムにしたがって動作することにより、各装置は、その機能を達成する。ここでコンピュータプログラムは、所定の機能を達成するために、コンピュータに対する指令を示す命令コードが複数個組み合わされて構成されたものである。
　（３）上記の実施の形態における各装置は、構成する構成要素の一部または全部は、１個のシステムＬＳＩ（Large Scale Integration：大規模集積回路）から構成されているとしてもよい。システムＬＳＩは、複数の構成部を１個のチップ上に集積して製造された超多機能ＬＳＩであり、具体的には、マイクロプロセッサ、ＲＯＭ、ＲＡＭなどを含んで構成されるコンピュータシステムである。前記ＲＡＭには、コンピュータプログラムが記録されている。前記マイクロプロセッサが、前記コンピュータプログラムにしたがって動作することにより、システムＬＳＩは、その機能を達成する。
　また、上記の各装置を構成する構成要素の各部は、個別に１チップ化されていても良いし、一部またはすべてを含むように１チップ化されてもよい。
　また、ここでは、システムＬＳＩとしたが、集積度の違いにより、ＩＣ、ＬＳＩ、スーパーＬＳＩ、ウルトラＬＳＩと呼称されることもある。また、集積回路化の手法はＬＳＩに限るものではなく、専用回路または汎用プロセッサで実現してもよい。ＬＳＩ製造後に、プログラムすることが可能なＦＰＧＡ（Field Programmable Gate Array）や、ＬＳＩ内部の回路セルの接続や設定を再構成可能なリコンフィギュラブル・プロセッサを利用しても良い。
　さらには、半導体技術の進歩または派生する別技術によりＬＳＩに置き換わる集積回路化の技術が登場すれば、当然、その技術を用いて機能ブロックの集積化を行ってもよい。バイオ技術の適用等が可能性としてありえる。
　（４）上記の各装置を構成する構成要素の一部または全部は、各装置に脱着可能なＩＣカードまたは単体のモジュールから構成されているとしてもよい。前記ＩＣカードまたは前記モジュールは、マイクロプロセッサ、ＲＯＭ、ＲＡＭなどから構成されるコンピュータシステムである。前記ＩＣカードまたは前記モジュールは、上記の超多機能ＬＳＩを含むとしてもよい。マイクロプロセッサが、コンピュータプログラムにしたがって動作することにより、前記ＩＣカードまたは前記モジュールは、その機能を達成する。このＩＣカードまたはこのモジュールは、耐タンパ性を有するとしてもよい。
　（５）本開示は、上記に示す方法であるとしてもよい。また、これらの方法をコンピュータにより実現するコンピュータプログラムであるとしてもよいし、前記コンピュータプログラムからなるデジタル信号であるとしてもよい。
　また、本開示は、前記コンピュータプログラムまたは前記デジタル信号をコンピュータで読み取り可能な記録媒体、例えば、フレキシブルディスク、ハードディスク、ＣＤ－ＲＯＭ、ＭＯ、ＤＶＤ、ＤＶＤ－ＲＯＭ、ＤＶＤ－ＲＡＭ、ＢＤ（Ｂｌｕ－ｒａｙ（登録商標）　Ｄｉｓｃ）、半導体メモリなどに記録したものとしてもよい。また、これらの記録媒体に記録されている前記デジタル信号であるとしてもよい。
　また、本開示は、前記コンピュータプログラムまたは前記デジタル信号を、電気通信回線、無線または有線通信回線、インターネットを代表とするネットワーク、データ放送等を経由して伝送するものとしてもよい。
　また、本開示は、マイクロプロセッサとメモリを備えたコンピュータシステムであって、前記メモリは、上記コンピュータプログラムを記録しており、前記マイクロプロセッサは、前記コンピュータプログラムにしたがって動作するとしてもよい。
　また、前記プログラムまたは前記デジタル信号を前記記録媒体に記録して移送することにより、または前記プログラムまたは前記デジタル信号を、前記ネットワーク等を経由して移送することにより、独立した他のコンピュータシステムにより実施するとしてもよい。
　（６）上記実施の形態及び上記変形例をそれぞれ組み合わせるとしてもよい。
　本開示は、制御方法、制御装置、及び、プログラムに利用でき、例えば自転車、自動二輪車などの移動体のシェアリングサービスなどでユーザが移動体利用のための契約を行う場合に、料金を払わない不正利用を抑制することができる制御方法、制御装置、及び、プログラムなどに利用可能である。
　１　システム
　１０、１０Ａ、１０Ｂ、１０Ｃ　移動体
　１１、１１Ａ、１１Ｂ、１１Ｃ　端末
　２０　管理サーバ
　１００　移動体装置
　１０１、１１０１　入力部
　１０２　トランザクションデータ生成部
　１０３　トランザクションデータ検証部
　１０４　ブロック生成部
　１０５　同期部
　１０６　スマートコントラクト実行部
　１０７　ブロックチェーン管理部
　１０８　分散台帳記憶部
　１０９　状態記憶部
　１１０　不正検知部
　１１１、１１０３　通信部
　１１２、１１０２　表示部

Claims (10)

  1. 　第１分散台帳で第１ブロックチェーンを管理する第１ノードと、それぞれ第２分散台帳で第２ブロックチェーンを管理する複数の第２ノードとを含み、サービス対象の利用に用いられるシステムにおける前記第１ノードの制御方法であって、
    　前記サービス対象の利用に際して前記サービス対象のロックを解除したことを示す第１トランザクションデータであって、前記サービス対象の利用を行う第１契約を一意に識別する第１契約ＩＤを含む第１トランザクションデータを生成し、
    　前記第１トランザクションデータを含むブロックを前記第１ブロックチェーンに格納する、
    　制御方法。
  2. 　さらに、前記サービス対象の利用料金の徴収を行うための料金徴収スマートコントラクトを実行し、
    　前記料金徴収スマートコントラクトを実行する際、
    　前記第１ブロックチェーン及び前記第２ブロックチェーンに前記第１トランザクションデータが格納され、かつ、前記第１トランザクションデータに含まれる前記第１契約ＩＤにより識別される前記第１契約であって前記サービス対象の利用における前記第１契約に対する利用料金が未徴収であるか否かを前記料金徴収スマートコントラクトに確認させ、
    　前記第１トランザクションデータが格納され、かつ、前記未徴収である場合、前記料金徴収スマートコントラクトに前記第１契約に対する利用料金の徴収を実行させる、
    　請求項１に記載の制御方法。
  3. 　前記未徴収である場合とは、
    　前記第１ブロックチェーン及び前記第２ブロックチェーンに、前記第１契約を行うための第２トランザクションデータと、前記サービス対象の利用を行う第２契約を行うための第３トランザクションデータとが格納されており、さらに、前記第１契約に含まれる前記サービス対象の利用を行う時間帯と前記第２契約に含まれる前記サービス対象の利用を行う時間帯とが一部重複する場合である、
    　請求項２に記載の制御方法。
  4. 　さらに、前記料金徴収スマートコントラクトに、前記第１契約に含まれる前記サービス対象の利用に不正があった旨を示すインシデントレポートを作成させる、
    　請求項２または３に記載の制御方法。
  5. 　さらに、
    　前記第１ブロックチェーン及び前記第２ブロックチェーンに、前記第１契約を行うための第２トランザクションデータと、前記サービス対象の利用を行う第２契約を行うための第３トランザクションデータとが格納されており、かつ、前記第１契約に含まれる前記サービス対象の利用を行う時間帯と前記第２契約に含まれる前記サービス対象の利用を行う時間帯とが一部重複する競合契約が存在するか否かを不正検知スマートコントラクトに確認させ、
    　前記競合契約が存在する場合、前記不正検知スマートコントラクトに、利用金の徴収が未徴収である旨のフラグを前記第１契約に付与させ、
    　前記サービス対象の利用料金の徴収を行うための料金徴収スマートコントラクトに、前記フラグが付与された前記第１契約に対する料金徴収を実行させる、
    　請求項１に記載の制御方法。
  6. 　前記システムは、複数の移動体をシェアリングするサービスに用いられ、
    　前記サービス対象は、前記複数の移動体であり、
    　前記第１契約及び前記第２契約は、第１の移動体の利用予約であり、
    　前記第２トランザクションデータ及び前記第３トランザクションデータは、ユーザが前記第１ノードを介して前記第１の移動体の利用予約を行うための予約トランザクションデータであり、前記ユーザのＩＤと、前記ユーザが前記第１の移動体を利用する時間帯を示す予約時間帯と、前記利用予約を識別するための予約番号とを含む、
    　請求項３または５に記載の制御方法。
  7. 　さらに、
    　前記第１ノードが、前記ユーザから前記第１の移動体の利用を開始するための要求として前記第１の移動体の解錠要求を受信し、
    　前記第１ノードが、前記解錠要求に対応する前記予約トランザクションデータが前記第１ブロックチェーンに格納されているか確認し、
    　前記予約トランザクションデータが格納されている場合、前記時間帯に前記第１の移動体の解錠を前記ユーザに許可して、前記第１トランザクションデータを生成する、
    　請求項６に記載の制御方法。
  8. 　さらに、
    　前記ユーザに前記第１の移動体を貸し出したことを示す貸出トランザクションデータであって、前記ユーザのＩＤと、前記予約番号と、前記ユーザに前記第１の移動体を貸し出した時刻のタイムスタンプとを含む貸出トランザクションデータを取得し、
    　前記貸出トランザクションデータを含む第２ブロックを、前記第１ブロックチェーンに格納し、
    　前記ユーザが前記第１の移動体を返却したことを示す返却トランザクションデータであって、前記ユーザのＩＤと、前記予約番号と、前記ユーザが前記第１の移動体を返却した時刻のタイムスタンプとを含む返却トランザクションデータを取得し、
    　前記返却トランザクションデータを含む第３ブロックを、前記第１ブロックチェーンに格納し、
    　前記予約トランザクションデータに含まれる前記ユーザのＩＤに対して、前記第１の移動体の利用料金の徴収を実行する、
    　請求項６または７に記載の制御方法。
  9. 　第１分散台帳で第１ブロックチェーンを管理する制御装置と、それぞれ第２分散台帳で第２ブロックチェーンを管理する複数の別の制御装置とを備え、サービス対象の利用に用いられるシステムにおける制御装置であって、
    　プロセッサと、
    　メモリと、を備え、
    　前記プロセッサは、前記サービス対象の利用に際して前記サービス対象のロックを解除したことを示す第１トランザクションデータであって、前記サービス対象の利用を行う第１契約を一意に識別する第１契約ＩＤを含む第１トランザクションデータを生成し、
    　前記プロセッサは、前記第１トランザクションデータを含むブロックを前記第１ブロックチェーンに格納する、
    　制御装置。
  10. 　第１分散台帳で第１ブロックチェーンを管理する第１ノードと、それぞれ第２分散台帳で第２ブロックチェーンを管理する複数の第２ノードとを含み、サービス対象の利用に用いられるシステムにおける前記第１ノードの制御方法をコンピュータに実行させるためのプログラムであって、
    　前記サービス対象の利用に際して前記サービス対象のロックを解除したことを示す第１トランザクションデータであって、前記サービス対象の利用を行う第１契約を一意に識別する第１契約ＩＤを含む第１トランザクションデータを生成し、
    　前記第１トランザクションデータを含むブロックを前記第１ブロックチェーンに格納することを、
    　コンピュータに実行させるためのプログラム。
PCT/JP2021/005833 2020-02-21 2021-02-17 制御方法、制御装置、及び、プログラム WO2021166932A1 (ja)

Priority Applications (3)

Application Number Priority Date Filing Date Title
CN202180014836.5A CN115104117A (zh) 2020-02-21 2021-02-17 控制方法、控制装置及程序
JP2022501922A JPWO2021166932A1 (ja) 2020-02-21 2021-02-17
US17/888,702 US20220391902A1 (en) 2020-02-21 2022-08-16 Control method, control device, and recording medium

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US202062979620P 2020-02-21 2020-02-21
US62/979,620 2020-02-21

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US17/888,702 Continuation US20220391902A1 (en) 2020-02-21 2022-08-16 Control method, control device, and recording medium

Publications (1)

Publication Number Publication Date
WO2021166932A1 true WO2021166932A1 (ja) 2021-08-26

Family

ID=77391286

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2021/005833 WO2021166932A1 (ja) 2020-02-21 2021-02-17 制御方法、制御装置、及び、プログラム

Country Status (4)

Country Link
US (1) US20220391902A1 (ja)
JP (1) JPWO2021166932A1 (ja)
CN (1) CN115104117A (ja)
WO (1) WO2021166932A1 (ja)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114596092A (zh) * 2022-02-24 2022-06-07 成都质数斯达克科技有限公司 一种基于区块链的计费方法、装置、设备及可读存储介质

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP6469920B1 (ja) * 2018-05-11 2019-02-13 株式会社 ディー・エヌ・エー 対象物の利用を管理するためのシステム、方法、及びプログラム
JP2019153130A (ja) * 2018-03-05 2019-09-12 株式会社Ｌｕｆｔホールディングス データ管理システム及びデータ管理アプリケーション
JP2020030610A (ja) * 2018-08-22 2020-02-27 ブロックチェーンロック株式会社 スマートロック装置及びプラットフォーム

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2019153130A (ja) * 2018-03-05 2019-09-12 株式会社Ｌｕｆｔホールディングス データ管理システム及びデータ管理アプリケーション
JP6469920B1 (ja) * 2018-05-11 2019-02-13 株式会社 ディー・エヌ・エー 対象物の利用を管理するためのシステム、方法、及びプログラム
JP2020030610A (ja) * 2018-08-22 2020-02-27 ブロックチェーンロック株式会社 スマートロック装置及びプラットフォーム

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114596092A (zh) * 2022-02-24 2022-06-07 成都质数斯达克科技有限公司 一种基于区块链的计费方法、装置、设备及可读存储介质
CN114596092B (zh) * 2022-02-24 2024-05-28 成都质数斯达克科技有限公司 一种基于区块链的计费方法、装置、设备及可读存储介质

Also Published As

Publication number Publication date
JPWO2021166932A1 (ja) 2021-08-26
CN115104117A (zh) 2022-09-23
US20220391902A1 (en) 2022-12-08

Similar Documents

Publication Publication Date Title
US10901983B2 (en) System and method for universal blockchain interoperability
EP3719758B1 (en) Parking charging method and system
US11909881B2 (en) Digital asset management
US20190392536A1 (en) Method and System for Creating and Managing a Smart Contract on a Distributed Ledger
CN109150943B (zh) 信息的传输方法、装置和系统
US20190172057A1 (en) Blockchain-implemented method and system
CN100587729C (zh) 认证装置、认证系统、以及认证装置的装置确认方法
US20190392178A1 (en) Method and System for Monitoring a Smart Contract on a Distributed Ledger
EP3557459B1 (en) Method, information processing device, management system, and program to control locking and unlocking of storage
WO2021166932A1 (ja) 制御方法、制御装置、及び、プログラム
CN101479752A (zh) 用于执行安全事务的便携式设备和方法
US20230410101A1 (en) Blockchain
WO2021166931A1 (ja) 制御方法、制御装置、及び、プログラム
WO2021166926A1 (ja) 制御方法、制御装置、及び、プログラム
WO2021166928A1 (ja) 制御方法、制御装置、及び、プログラム
EP3321874A1 (en) System and method for processing a rental of a secured asset
CN112513907A (zh) 提供数字资产交换协议的装置和方法
JP2006309355A (ja) サービスシステム及び同システムのサーバ装置の動作方法
EP3340157A1 (en) Systems and methods for automated leasing of unattended assets
CN112511651B (zh) 一种基于区块链的服务准入方法及装置
JP2005157497A (ja) 電子マネーチャージ機、及び電子マネーチャージシステム
EP4336776A1 (en) Method and system for facilitating a secure transfer of assets
JP5114172B2 (ja) 遊技媒体貸出システム及びその解錠許可方法
Baratella Decentralized Carpooling with Algorand Blockchain
WO2022163457A1 (ja) 制御方法、サーバ、及びプログラム

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

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2022501922

Country of ref document: JP

Kind code of ref document: A

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 21757992

Country of ref document: EP

Kind code of ref document: A1