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

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

Info

Publication number
WO2021166931A1
WO2021166931A1 PCT/JP2021/005830 JP2021005830W WO2021166931A1 WO 2021166931 A1 WO2021166931 A1 WO 2021166931A1 JP 2021005830 W JP2021005830 W JP 2021005830W WO 2021166931 A1 WO2021166931 A1 WO 2021166931A1
Authority
WO
WIPO (PCT)
Prior art keywords
transaction data
mobile device
block
blockchain
mobile
Prior art date
Legal status (The legal status 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 status listed.)
Ceased
Application number
PCT/JP2021/005830
Other languages
English (en)
French (fr)
Japanese (ja)
Inventor
直央 西田
勇二 海上
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Panasonic Intellectual Property Corp of America
Original Assignee
Panasonic Intellectual Property Corp of America
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 Panasonic Intellectual Property Corp of America filed Critical Panasonic Intellectual Property Corp of America
Priority to CN202180014835.0A priority Critical patent/CN115104111A/zh
Priority to JP2022501921A priority patent/JP7637464B2/ja
Publication of WO2021166931A1 publication Critical patent/WO2021166931A1/ja
Priority to US17/886,638 priority patent/US20220383320A1/en
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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
    • G06Q20/4014—Identity check for transactions
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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 OR CALCULATING; 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/02—Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP]
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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/085—Payment architectures involving remote charge determination or related payment systems
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3825—Use of electronic signatures
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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
    • G06Q50/00—Information and communication technology [ICT] specially adapted for implementation of business processes of specific business sectors, e.g. utilities or tourism
    • G06Q50/10—Services
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07F—COIN-FREED OR LIKE APPARATUS
    • G07F17/00—Coin-freed apparatus for hiring articles; Coin-freed facilities or services
    • G07F17/0042—Coin-freed apparatus for hiring articles; Coin-freed facilities or services for hiring of objects
    • G07F17/0057—Coin-freed apparatus for hiring articles; Coin-freed facilities or services for hiring of objects for the hiring or rent of vehicles, e.g. cars, bicycles or wheelchairs

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. Whether the number of communicable second nodes among the plurality of second nodes exceeds a predetermined value by acquiring the first transaction data in the control method of the first node in the system used for the use of the service target. Is determined, and only when the number of communicable second nodes exceeds a predetermined value, the first block including the first transaction data is generated.
  • 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 a process in which local reservation is not possible for the system according to the embodiment.
  • FIG. 40 is a flowchart showing an example of the block generation determination process according to the embodiment.
  • FIG. 41 is a flowchart showing another example of the block generation determination process according to the embodiment.
  • FIG. 42 is a flowchart for explaining the block connection process of the system according to the embodiment.
  • 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 the number of the second nodes capable of acquiring the first transaction data and communicating among the plurality of second nodes is predetermined. It is determined whether the value is exceeded, and the first block including the first transaction data is generated only when the number of the second communicable nodes exceeds a predetermined value.
  • a signal requesting a reply is transmitted to the plurality of second nodes, and the second node that has obtained a reply to the signal is determined to be communicable. It may be determined whether the number of communicable second nodes exceeds the predetermined value depending on whether the number of the second nodes that have acquired the reply to the signal exceeds the predetermined value.
  • the signal is the first transaction data and the number of the second communicable nodes is equal to or less than the predetermined value when determining whether the signal exceeds the predetermined value
  • the plurality of the signals are at predetermined intervals.
  • the first transaction data may be transmitted as the signal to the second node of the above.
  • the first transaction data when acquiring the first transaction data, is acquired by receiving the first transaction data from at least one second node of the plurality of second nodes.
  • the predetermined value when determining whether or not the predetermined value is exceeded, whether or not the predetermined value is exceeded depends on whether or not the first transaction data is received from a number of second nodes exceeding the predetermined value among the plurality of second nodes. May be determined.
  • the generated first block is transmitted to the second node having a number exceeding the predetermined value, and the consensus algorithm is executed together with the second node having the number exceeding the predetermined value.
  • One block may be stored in the first block chain.
  • the first transaction data may include information regarding a first contract for using the service target.
  • the service target corresponding to the first contract may be used.
  • the system is used for a service of sharing a plurality of mobile bodies
  • the service target is the plurality of mobile bodies
  • the user can use the first transaction data via the first node.
  • 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 other control devices that manage the second blockchain in the second distributed ledger, respectively.
  • a control device in a system used for use of a service target comprising a processor and a memory, the processor acquires first transaction data and is a communicable other of the plurality of other control devices. It is determined whether the number of control devices exceeds a predetermined value, and only when the number of communicable second nodes exceeds the predetermined value, the first block including the first transaction data is generated.
  • 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.
  • 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 a program for acquiring the first transaction data and communicating with the second node among the plurality of second nodes. For determining whether the number exceeds a predetermined value and causing the computer to generate the first block containing the first transaction data only when the number of communicable second nodes exceeds the predetermined value. It is a program.
  • 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 provided on the mobiles 10A to 10C will be described.
  • the moving body devices provided in 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 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.
  • 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 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 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 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, 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 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 reservation transaction data, lending transaction data, and 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.
  • ⁇ Fraud detection unit 110 When the transaction data verified by the transaction data verification unit 103 is stored in the transaction pool area of the state storage unit 109, the fraud detection unit 110 performs the block generation determination process. Even if the fraud detection unit 110 performs the block generation determination process by executing the block generation determination algorithm stored in the on-memory area of the state storage unit 109 or the first distributed ledger of the distributed ledger storage unit 108 in advance. good.
  • the fraud detection unit 110 determines whether the number of communicable other mobile devices 100 among the plurality of other mobile devices 100 exceeds a predetermined value, and the number of communicable other mobile devices 100 is predetermined. Performs fraud detection processing that allows block generation only when the value is exceeded.
  • the fraud detection unit 110 may transmit a signal requesting a reply to the plurality of other mobile devices 100, and may determine that the other mobile device 100 that has obtained the reply to the signal can communicate. In this case, the fraud detection unit 110 determines whether the number of other mobile devices 100 capable of communicating exceeds a predetermined value depending on whether the number of other mobile devices 100 that have acquired a reply to the signal exceeds a predetermined value. You just have to judge. Further, the fraud detection unit 110 determines whether or not the value exceeds the predetermined value depending on whether or not transaction data or a signal is received from the number of other mobile devices 100 that exceeds the predetermined value among the plurality of other mobile devices 100. You may judge.
  • 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: User Interface) 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.
  • the processing of the local reservation in step S10 is not completed. If the processing of the local reservation is not completed, the mobile body A cannot be rented by the local reservation and the mobile body A cannot be used. That is, by suppressing the processing that leads to the unauthorized use of the mobile body A that is the service target, it is possible to suppress the unauthorized use of the service target that abuses the blockchain.
  • FIG. 39 is a sequence diagram showing a process in which local reservation is not possible for the system according to the embodiment.
  • the same elements as those in FIG. 28 are designated by the same reference numerals, and detailed description thereof will be omitted.
  • a case where the local reservation countermeasure processing is performed by the mobile device A will be described as a representative.
  • 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 (S101D), and uses the generated reserved transaction data TrsvA for the mobile device A. (S102D).
  • the mobile device A when the mobile device A receives the reserved transaction data TrsvA transmitted in step S102D, it attempts to transfer the reserved transaction data TrsvA to the mobile devices B and C, which are other mobile devices, but fails. (S103D). 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 (S104D).
  • the mobile device A stores the reserved transaction data TrsvA verified by the verification algorithm executed in step S104D in the transaction pool a (S105D).
  • the mobile device A executes the block generation determination algorithm, which is the fraud countermeasure processing according to the present embodiment (S1071). Specifically, the mobile device A determines whether the number of other mobile devices that can communicate among the plurality of other mobile devices exceeds a predetermined value, and determines whether the number of other mobile devices that can communicate exceeds a predetermined value. Executes a block generation determination algorithm that allows block generation only when exceeds a predetermined value. This is because when the number of other mobile devices that can communicate exceeds a predetermined value, it can be considered that the mobile device A has returned to the online state.
  • the main reservation process that is, the local reservation process is terminated.
  • the mobile device A when block generation is permitted as a result of executing the block generation determination algorithm, the mobile device A generates a block Blc (TrsvA) including the verified reserved transaction data TrsvA (S107D).
  • FIG. 40 is a flowchart showing an example of the block generation determination process according to the embodiment. In the following, the case where the block generation determination process is performed by the mobile device A will be described as an example.
  • the mobile device A transmits transaction data to another mobile device (S10711).
  • the transaction data to be sent may be the reserved transaction data TrsvA or another transaction data.
  • what is sent to another mobile device is not limited to transaction data, but may be a signal requesting a reply such as ac.
  • the mobile device A determines whether or not the number of other mobile devices that can communicate exceeds a predetermined value (S10712).
  • step S10712 when the number of other mobile devices that can communicate exceeds a predetermined value (Yes in S10712), the mobile device A selects transaction data from the transaction pool a and generates a block (S10713). .. More specifically, the mobile device A selects the reserved transaction data TrsvA from the transaction pool a and generates a block.
  • the block generation may be permitted only in step S10713, and the process may proceed to step S107D, or the process of step S107D may be performed by step S1071. ..
  • FIG. 41 is a flowchart showing another example of the block generation determination process according to the embodiment.
  • the case where the block generation determination process is performed by the mobile device A will be described as an example.
  • the mobile device A first, the mobile device A generates transaction data (S10714).
  • the transaction data to be generated may be the reserved transaction data TrsvA or another transaction data. Not limited to transaction data, a signal requesting a reply such as ac may be generated.
  • the mobile device A transmits transaction data to another mobile device (S10715).
  • the mobile device A transmits transaction data to each other as long as it is in a communicable (online) state with another mobile device.
  • the mobile device A determines whether or not transaction data has been received from the number of other mobile devices exceeding a predetermined number (S10716).
  • step S10716 when transaction data is received from the number of other mobile devices exceeding a predetermined number (Yes in S10716), the mobile device A selects transaction data from the transaction pool a and generates a block (Yes). S10717). More specifically, the mobile device A selects the reserved transaction data TrsvA from the transaction pool a and generates a block.
  • the block generation may be permitted only in step S10717, and the process may proceed to step S107D, or the process of step S107D may be performed by step S10717. ..
  • FIG. 42 is a flowchart for explaining the block connection process of the system according to the embodiment.
  • the same elements as those in FIG. 22 are designated by the same reference numerals, and detailed description thereof will be omitted.
  • a case where the block connection process is performed by the mobile device A will be described as a representative.
  • step S1005D is added to the block connection process shown in FIG. 22, and the processes of steps S1005 to S1007 of the block connection process shown in FIG. 22 are deleted. That is, since steps S1001 to S1004 and steps S1008 to S1013 shown in FIG. 42 are as described in the block connection process shown in FIG. 22, the description thereof is omitted here.
  • step S1004 when there is a trigger (Yes in S1004), the mobile device A determines whether or not block generation is permitted (step S1005D).
  • the detailed processing of step S1005D is the processing shown in FIGS. 40 and 41. Since the processes shown in FIGS. 40 and 41 have been described above, the detailed processing in step S1005D will also be omitted.
  • step S1005D If block generation is permitted in step S1005D (OK in step S1005D), the process proceeds to step S1008. If the block generation is not permitted in step S1005D (NG in step S1005D), the process of step S1005D may be performed again. In this case, transaction data as a signal is continuously transmitted to a plurality of other mobile devices at predetermined intervals until the number of other mobile devices that can communicate exceeds a predetermined value.
  • 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 processing after the fraud countermeasure is the same. That is, if the block generation determination process cannot communicate with the second node exceeding a predetermined number, the block including the acquired first transaction data is not generated.
  • the block generation determination process cannot communicate with the second node exceeding a predetermined number
  • the block including the acquired first transaction data is not generated.
  • it is possible to suppress processing that leads to unauthorized use of the service target such as making the first node unable to communicate with the second node and storing the block containing the first transaction data only in the first distributed ledger. .. Therefore, it is possible to suppress unauthorized use of the service target that abuses the blockchain.
  • 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.
  • 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, methods, control devices, programs, etc. that can suppress unauthorized use.

Landscapes

  • Business, Economics & Management (AREA)
  • Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Accounting & Taxation (AREA)
  • Strategic Management (AREA)
  • General Business, Economics & Management (AREA)
  • Theoretical Computer Science (AREA)
  • Tourism & Hospitality (AREA)
  • Computer Security & Cryptography (AREA)
  • Finance (AREA)
  • Economics (AREA)
  • Human Resources & Organizations (AREA)
  • Marketing (AREA)
  • Development Economics (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Operations Research (AREA)
  • Quality & Reliability (AREA)
  • Health & Medical Sciences (AREA)
  • General Health & Medical Sciences (AREA)
  • Primary Health Care (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
PCT/JP2021/005830 2020-02-21 2021-02-17 制御方法、制御装置、及び、プログラム Ceased WO2021166931A1 (ja)

Priority Applications (3)

Application Number Priority Date Filing Date Title
CN202180014835.0A CN115104111A (zh) 2020-02-21 2021-02-17 控制方法、控制装置及程序
JP2022501921A JP7637464B2 (ja) 2020-02-21 2021-02-17 制御方法、制御装置、及び、プログラム
US17/886,638 US20220383320A1 (en) 2020-02-21 2022-08-12 Control method, control device, and recording medium

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US202062979634P 2020-02-21 2020-02-21
US62/979,634 2020-02-21

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US17/886,638 Continuation US20220383320A1 (en) 2020-02-21 2022-08-12 Control method, control device, and recording medium

Publications (1)

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

Family

ID=77391282

Family Applications (1)

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

Country Status (4)

Country Link
US (1) US20220383320A1 (https=)
JP (1) JP7637464B2 (https=)
CN (1) CN115104111A (https=)
WO (1) WO2021166931A1 (https=)

Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2018111295A1 (en) * 2016-12-16 2018-06-21 Hitachi, Ltd. Blockchain monitoring and management
JP2018196097A (ja) * 2017-05-22 2018-12-06 Kddi株式会社 生成装置、合意形成システム、プログラム、及び生成方法
JP2019028525A (ja) * 2017-07-26 2019-02-21 株式会社日立製作所 運用管理方法、運用管理システム、および、運用管理プログラム
US20190259093A1 (en) * 2017-12-15 2019-08-22 Avis Budget Car Rental, LLC Blockchain-based connected user communication and interface system
JP2019153130A (ja) * 2018-03-05 2019-09-12 株式会社Ｌｕｆｔホールディングス データ管理システム及びデータ管理アプリケーション
US20190324867A1 (en) * 2017-03-28 2019-10-24 Alibaba Group Holding Limited Blockchain-based consensus method and device
JP2019184908A (ja) * 2018-04-13 2019-10-24 株式会社ｂｉｔＦｌｙｅｒ Ｂｌｏｃｋｃｈａｉｎ ブロックチェーン・ネットワーク及びそのための確定方法
US20200005388A1 (en) * 2018-06-28 2020-01-02 International Business Machines Corporation Rental asset processing for blockchain

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10356745B2 (en) * 2016-06-08 2019-07-16 T-Mobile Usa, Inc. Device and/or line event awareness and smart synchronization
CN110163004B (zh) * 2018-02-14 2023-02-03 华为技术有限公司 一种区块链生成的方法、相关设备及系统
WO2019190916A1 (en) * 2018-03-30 2019-10-03 Walmart Apollo, Llc Systems and methods for distributing merchandise and merchandise kits at emergency locations
CN108776929A (zh) * 2018-04-02 2018-11-09 成都云创智融科技有限公司 基于区块链数据库的账单处理方法、系统和可读存储介质
GB2596941A (en) * 2019-04-09 2022-01-12 David Tucker Luke Systems and processes for management of digital or physical assets via distributed ledger
CN114391241B (zh) * 2019-09-11 2024-06-11 维萨国际服务协会 具有可调整法定数量的区块链分片
US11820529B2 (en) * 2019-10-29 2023-11-21 Ga Telesis, Llc System and method for monitoring and certifying aircrafts and components of aircrafts

Patent Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2018111295A1 (en) * 2016-12-16 2018-06-21 Hitachi, Ltd. Blockchain monitoring and management
US20190324867A1 (en) * 2017-03-28 2019-10-24 Alibaba Group Holding Limited Blockchain-based consensus method and device
JP2018196097A (ja) * 2017-05-22 2018-12-06 Kddi株式会社 生成装置、合意形成システム、プログラム、及び生成方法
JP2019028525A (ja) * 2017-07-26 2019-02-21 株式会社日立製作所 運用管理方法、運用管理システム、および、運用管理プログラム
US20190259093A1 (en) * 2017-12-15 2019-08-22 Avis Budget Car Rental, LLC Blockchain-based connected user communication and interface system
JP2019153130A (ja) * 2018-03-05 2019-09-12 株式会社Ｌｕｆｔホールディングス データ管理システム及びデータ管理アプリケーション
JP2019184908A (ja) * 2018-04-13 2019-10-24 株式会社ｂｉｔＦｌｙｅｒ Ｂｌｏｃｋｃｈａｉｎ ブロックチェーン・ネットワーク及びそのための確定方法
US20200005388A1 (en) * 2018-06-28 2020-01-02 International Business Machines Corporation Rental asset processing for blockchain

Also Published As

Publication number Publication date
JP7637464B2 (ja) 2025-02-28
US20220383320A1 (en) 2022-12-01
CN115104111A (zh) 2022-09-23
JPWO2021166931A1 (https=) 2021-08-26

Similar Documents

Publication Publication Date Title
US12321928B2 (en) Blockchain-implemented method and system for access control on remote internet-enabled resources
US11159306B2 (en) Autonomous exchange via entrusted ledger token and transaction management
CN109150943A (zh) 信息的传输方法、装置和系统
EP3989151A1 (en) System and method for the secure peer-to-peer transmission of content in distributed ledger networks
US20230410101A1 (en) Blockchain
CN112511651B (zh) 一种基于区块链的服务准入方法及装置
US20240104642A1 (en) Apparatus for processing non-fungible token
JP7573592B2 (ja) 制御方法、制御装置、及び、プログラム
JP7723651B2 (ja) 制御方法、制御装置、及び、プログラム
JP7637464B2 (ja) 制御方法、制御装置、及び、プログラム
EP3340157A1 (en) Systems and methods for automated leasing of unattended assets
JP7595058B2 (ja) 制御方法、制御装置、及び、プログラム
EP3321874A1 (en) System and method for processing a rental of a secured asset
CN112513907A (zh) 提供数字资产交换协议的装置和方法
JP7595000B2 (ja) 故障監視方法、監視装置及びプログラム
EP4336776A1 (en) Method and system for facilitating a secure transfer of assets
EP4517575A1 (en) Electronic device using blockchain and control method thereof
CN120031554A (zh) 一种数据处理方法、装置、设备及介质
CN119998806A (zh) 信息处理方法、信息处理装置以及信息处理系统
GUERROUDJ et al. An approach to improve Blockchain authentication protocol for Internet of Things
CN117951143A (zh) 服务器以及方法
HK40049159B (en) Service admission method and device based on blockchain
HK40049159A (en) Service admission method and device based on blockchain
CN121746052A (zh) 账户管理方法、电子设备及程序产品
HK40060988A (en) Apparatus and method for providing protocol for digital asset trading

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

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2022501921

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

Country of ref document: EP

Kind code of ref document: A1