Control method, control device, and program

Abstract

The present invention provides a method for controlling a first node in a system that is used for using an item under service, the system including the first node, which manages a first blockchain by using a first distributed ledger, and a plurality of second nodes, which individually manage second blockchains by using second distributed ledgers, wherein, when the item under service is used, first transaction data indicating that the item under service has been unlocked and including a first contract ID uniquely identifying a first contract for using the item under service is generated (S3031), and a block including the first transaction data is stored in the first blockchain (S312D).

Description

[Technical Field]

[0001] The present disclosure relates to a control method, a control device, and a program. [Background technology]

[0002] For example, Patent Document 1 discloses a technology for appropriately managing information relating to reservations transmitted and received between a vehicle terminal and a user terminal using a blockchain. [Prior art documents] [Patent documents]

[0003] [Patent Document 1] Japanese Patent Application Laid-Open No. 2019-153130 Summary of the Invention [Problem to be solved by the invention]

[0004] However, when using blockchain to manage contracts or transactions such as reserving the use of an object, the technology disclosed in Patent Document 1 has the problem that the behavior of the blockchain when a fork occurs can be exploited to allow the object to be used fraudulently.

[0005] The present disclosure has been made in consideration of the above-mentioned circumstances, and aims to provide a control method, a control device, and a program that can prevent fraudulent use of service targets by misusing blockchain. [Means for solving the problem]

[0006] A control method according to one embodiment of the present disclosure is a control method for the first node in a system used for using a service object, the control method including a first node that manages a first blockchain using a first distributed ledger and a plurality of second nodes that each manage a second blockchain using a second distributed ledger, the control method including generating first transaction data indicating that the service object has been unlocked when the service object is used, the first transaction data including a first contract ID that uniquely identifies a first contract for using the service object, and storing a block including the first transaction data in the first blockchain. and executes a fee collection smart contract for collecting a usage fee for the service target, and when executing the fee collection smart contract, causes the fee collection smart contract to check whether the first transaction data is stored in the first blockchain and the second blockchain, and whether the usage fee for the first contract, which is identified by the first contract ID included in the first transaction data, for the use of the service target has not yet been collected, and if the first transaction data is stored and the usage fee has not yet been collected, causes the fee collection smart contract to collect the usage fee for the first contract. . Furthermore, a control method according to another aspect of the present disclosure is a control method of the first node in a system used for using a service object, the control method including a first node that manages a first blockchain using a first distributed ledger and a plurality of second nodes that each manage a second blockchain using a second distributed ledger, the control method comprising: generating first transaction data indicating that the service object has been unlocked when the service object is used, the first transaction data including a first contract ID that uniquely identifies a first contract for using the service object; storing a block including the first transaction data in the first blockchain; The second transaction data for executing the first contract and the third transaction data for executing the second contract for using the service object are stored, and the fraud detection smart contract is made to check whether there is a competing contract in which the time period for using the service object included in the first contract partially overlaps with the time period for using the service object included in the second contract, and if the competing contract exists, the fraud detection smart contract is made to assign a flag to the first contract indicating that the usage fee has not yet been collected, and the fee collection smart contract for collecting the usage fee for the service object is made to collect the fee for the first contract to which the flag has been assigned.

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

[0008] According to the present disclosure, it is possible to prevent fraudulent use of service targets by misusing blockchain. [Brief explanation of the drawings]

[0009] [Figure 1] FIG. 1 is a diagram for explaining the steps of a method for fraudulent use. [Figure 2A] FIG. 2A is a diagram showing an example of a scene in which step 1 shown in FIG. 1 is performed. [Figure 2B] FIG. 2B is a diagram showing an example of a scene in which steps 2 and 3 shown in FIG. 1 are performed. [Figure 2C] FIG. 2C is a diagram showing an example of a scene in which step 4 shown in FIG. 1 is performed. [Figure 2D] FIG. 2D is a diagram showing an example of a scene in which step 5 shown in FIG. 1 is performed. [Figure 2E]FIG. 2E is a diagram showing an example of a scene in which step 6 shown in FIG. 1 is performed. [Figure 2F] FIG. 2F shows an example of a scene that occurs after step 6 shown in FIG. [Figure 3A] Figure 3A is a diagram to explain the behavior of a blockchain when a fork occurs. [Figure 3B] Figure 3B is a diagram to explain the behavior of a blockchain when a fork occurs. [Figure 3C] Figure 3C is a diagram to explain the behavior of a blockchain when a fork occurs. [Figure 4] FIG. 4 is a diagram illustrating an example of a configuration of a system according to an embodiment. [Figure 5A] FIG. 5A is a diagram illustrating another example of the configuration of the system according to the embodiment. [Figure 5B] FIG. 5B is a diagram illustrating another example of the configuration of the system according to the embodiment. [Figure 5C] FIG. 5C is a diagram illustrating another example of the configuration of the system according to the embodiment. [Figure 6] FIG. 6 is a diagram illustrating an example of a configuration of a mobile device according to an embodiment. [Figure 7] FIG. 7 is a diagram illustrating an example of a configuration of a terminal according to an embodiment. [Figure 8] FIG. 8 is a flowchart showing an outline of normal processing operations of a system according to a first example of the comparative example. [Figure 9A] FIG. 9A is a diagram conceptually illustrating the blocks of the blockchain stored in Ledgers A and B by the operation of step S1 in FIG. 8. [Figure 9B] FIG. 9B is a diagram conceptually illustrating the blocks of the blockchain stored in Ledgers A and B by the operation of step S3 in FIG. 8. [Figure 9C] FIG. 9C is a diagram for conceptually explaining the blocks of the blockchain stored in Ledgers A and B by the operation of step S5 in FIG. 8. [Figure 10]FIG. 10 is a sequence diagram showing a reservation process of a system according to a first example of the comparative example. [Figure 11] FIG. 11 is a sequence diagram showing a lending process of a system according to a first example of the comparative example. [Figure 12] FIG. 12 is a sequence diagram showing a return process of a system according to a first example of the comparative example. [Figure 13] FIG. 13 is a flowchart for explaining details of the fee calculation process of the system according to the comparative example. [Figure 14] FIG. 14 is a flowchart showing an outline of normal processing operations of a system according to a second example of the comparative example. [Figure 15A] FIG. 15A is a diagram conceptually illustrating a block of a blockchain stored in ledger A by the operation of step S1A in FIG. [Figure 15B] FIG. 15B is a diagram conceptually illustrating the blocks of the blockchain stored in ledger A by the operation of step S3A in FIG. 14. [Figure 15C] FIG. 15C is a diagram conceptually illustrating the blocks of the blockchain stored in ledger A by the operation of step S5A in FIG. 14. [Figure 16] FIG. 16 is a diagram for conceptually explaining the blocks of the blockchain stored in Ledgers A and B by the operation of step S6A in FIG. [Figure 17] FIG. 17 is a diagram for conceptually explaining the blocks of the blockchain stored in Ledgers A and B by the operation of step S6A in FIG. [Figure 18] FIG. 18 is a sequence diagram showing a reservation process of a system according to a second example of the comparative example. [Figure 19] FIG. 19 is a sequence diagram showing a lending process of a system according to a second example of the comparative example. [Figure 20] FIG. 20 is a sequence diagram showing a return process of a system according to a second example of the comparative example. [Figure 21]FIG. 21 is a sequence diagram showing system processing performed when communication is restored for mobile device A according to the second example of the comparative example. [Figure 22] FIG. 22 is a flowchart for explaining the block connection process of the system according to the comparative example. [Figure 23] FIG. 23 is a flowchart showing an outline of fraud processing operations of a system according to a third example of the comparative example. [Figure 24A] FIG. 24A is a diagram conceptually illustrating the blocks of the blockchain stored in ledger A by the operation of step S10 in FIG. 23. [Figure 24B] FIG. 24B is a diagram conceptually illustrating the blocks of the blockchain stored in ledger A by the operation of step S11 in FIG. 23. [Figure 24C] FIG. 24C is a diagram conceptually illustrating the blocks of the blockchain stored in ledger A by the operation of step S12 in FIG. 23. [Figure 25] FIG. 25 is a diagram for conceptually explaining the blocks of the blockchain stored in Ledgers A and B by the operation of step S13 in FIG. [Figure 26] FIG. 26 is a diagram for conceptually explaining the blocks of the blockchain stored in Ledgers A and B by the operation of step S13 in FIG. [Figure 27] FIG. 27 is a diagram conceptually illustrating the blocks of the blockchain stored in Ledgers A and B by the operation of step S14 in FIG. [Figure 28] FIG. 28 is a sequence diagram showing a process when making a local reservation in a system according to a third example of the comparative example. [Figure 29] FIG. 29 is a sequence diagram showing a process for making a competitive reservation in a system according to a third example of the comparative example. [Figure 30] FIG. 30 is a sequence diagram showing a local lending process in a system according to a third example of the comparative example. [Figure 31] FIG. 31 is a sequence diagram showing system processing performed when communication is restored for mobile device A according to a third example of the comparative example. [Figure 32] FIG. 32 is a sequence diagram showing the return process of the system according to the third example of the comparative example. [Figure 33] FIG. 33 is a flowchart showing an outline of fraud processing operations of a system according to a fourth example of the comparative example. [Figure 34A] FIG. 34A is a diagram conceptually illustrating the blocks of the blockchain stored in ledger A by the operation of step S10 in FIG. 33. [Figure 34B] FIG. 34B is a diagram conceptually illustrating the blocks of the blockchain stored in ledger A by the operation of step S11 in FIG. 33. [Figure 34C] FIG. 34C is a diagram conceptually illustrating the blocks of the blockchain stored in ledger A by the operation of step S12 in FIG. 33. [Figure 34D] FIG. 34D is a diagram conceptually illustrating the blocks of the blockchain stored in ledger A by the operation of step S13A in FIG. 33. [Figure 35] FIG. 35 is a diagram for conceptually explaining the blocks of the blockchain stored in Ledgers A and B by the operation of step S14A in FIG. [Figure 36] FIG. 36 is a diagram for conceptually explaining the blocks of the blockchain stored in Ledgers A and B by the operation of step S14A in FIG. [Figure 37] FIG. 37 is a sequence diagram showing a local return process of a system according to a fourth example of the comparative example. [Figure 38] FIG. 38 is a sequence diagram showing system processing performed when communication is restored for mobile device A according to a fourth example of the comparative example. [Figure 39] FIG. 39 is a sequence diagram showing the local lending process of the system according to the embodiment. [Figure 40] FIG. 40 is a conceptual diagram showing the blockchain blocks stored in Ledger A through the local lending process of FIG. 39. [Figure 41]FIG. 41 is a diagram conceptually illustrating the blocks of the blockchain stored in Ledger A and Ledger B when the fee calculation process according to the embodiment is performed. [Figure 42] FIG. 42 is a flowchart for explaining the details of the fee calculation process according to this embodiment. [Figure 43] FIG. 43 is a sequence diagram showing system processing performed when mobile body apparatus A returns to communication according to the modification of the embodiment. [Figure 44] FIG. 44 is a flowchart showing fraudulent reservation detection processing according to the modified example of the embodiment. [Figure 45] FIG. 45 is a sequence diagram showing the processing of the system that is carried out when an incident report is created by executing the fraudulent reservation detection processing according to the modified embodiment. DETAILED DESCRIPTION OF THE INVENTION

[0010] (How one aspect of the present disclosure was achieved) As mentioned above, Patent Document 1 discloses a technology for appropriately managing information relating to reservations transmitted and received between a vehicle terminal and a user terminal using a blockchain.

[0011] However, the technology disclosed in Patent Document 1 allows for the mechanism of blockchain to be exploited and used fraudulently. An example will be explained below.

[0012] FIG. 1 is a diagram illustrating the steps of a method for fraudulent use. FIGS. 2A to 2F are diagrams illustrating an example of a scenario in which the steps shown in FIG. 1 are performed. FIG. 1 illustrates the steps for making a reservation for bike A in a service that shares multiple bikes, and then fraudulently using bike A. The arrows indicate the current time. Each of the multiple bikes has a ledger in which reservations are managed using a blockchain. FIG. 2A is a diagram illustrating an example of a scenario in which step 1 shown in FIG. 1 is performed, and FIG. 2B is a diagram illustrating an example of a scenario in which steps 2 and 3 shown in FIG. 1 are performed. FIG. 2C is a diagram illustrating an example of a scenario in which step 4 shown in FIG. 1 is performed, and FIG. 2D is a diagram illustrating an example of a scenario in which step 5 shown in FIG. 1 is performed. FIG. 2E is a diagram illustrating an example of a scenario in which step 6 shown in FIG. 1 is performed, and FIG. 2F is a diagram illustrating an example of a scenario in which step 7 is performed after step 6 shown in FIG. 1.

[0013] As shown in Figure 2A, a user attempting fraudulent use makes a first reservation in step 1 to use bike A for 15 minutes between 12:00 and 12:15. Then, since bike A's ledger A is able to communicate (be online) with the other bikes' ledgers B and C, the first reservation Tx shown in black is stored in all ledgers (ledgers A, B, and C) as shown in step 1 of Figure 1. As a result, bike A can be unlocked and the user can use it for 15 minutes between 12:00 and 12:15.

[0014] Next, as shown in Figure 2B, the user attempting fraudulent use places ledger A for motorcycle A in an offline state (disables communication with ledgers B and C of other motorcycles) in steps 2 and 3. The user then makes a second reservation to use motorcycle A for 15 minutes, for example, between 16:00 and 16:15, in the ledgers B and C of other motorcycles. Then, because ledger A for motorcycle A is offline, the second reservation Tx, shown in black in step 3 of Figure 1, is stored only in ledgers B and C, which are online.

[0015] Next, as shown in Figure 2C, in step 4, the user attempting fraudulent use makes a fraudulent reservation in Bike A's ledger A to use Bike A, for example, from 12:15 to 16:15. Then, because Bike A's ledger A is unable to communicate (offline) with the other bikes' ledgers B and C, the fraudulent reservation Tx shown in hatching is stored only in Bike A's ledger A, as shown in step 4 of Figure 1. As a result, Bike A is unlocked at 12:15, so the user can fraudulently use Bike A while remaining offline between 12:15 and 16:15, as shown in step 5 of Figure 2D. In this case, the second reservation Tx shown in black is stored only in the online ledgers B and C, as shown in step 5 of Figure 1.

[0016] Next, as shown in Figure 2E, in step 6, the user restores ledger A of bike A to a state where it can communicate (online) with ledgers B and C of other bikes between 16:00 and 16:15. As a result, a fork occurs in the blockchain of ledgers A, B, and C, as will be described in detail later, and the second reservation Tx is stored in the blockchain of ledger A, just like the blockchains of ledgers B and C, as shown in step 6 of Figure 1. The fraudulent reservation Tx is then stored after the second reservation Tx.

[0017] Here, we explain the behavior of the blockchain when a fork occurs, such that when Ledger A for Bike A returns to online status in step 6, the fraudulent reservation Tx is stored in Ledger A, B, and C after the second reservation Tx.

[0018] 3A to 3C are diagrams for explaining the behavior of a blockchain when a fork occurs. 3A to 3C conceptually show transaction data stored in ledger A of mobile entity A and ledger B of mobile entity B. Tx indicates transaction data. Mobile entity A may be, for example, motorcycle A.

[0019] First, as shown on the left side of Fig. 3A, when ledger A of mobile unit A and ledger B of mobile unit B are in a state where they can communicate (are online) with other mobile units (not shown), ledger A and ledger B store block 1 containing the same Tx1 and block 2 linked to block 1 and containing Tx2. Tx2 may correspond to, for example, the above-mentioned first reservation Tx.

[0020] In this way, when block 2 containing Tx2 is generated in Ledgers A and B, it is linked to the previously generated block 1. Ledgers A and B constitute the same blockchain.

[0021] Next, as shown on the right side of Fig. 3A, when ledger A of mobile unit A is in a state of being disconnected from other mobile units (offline), ledger A and ledger B store blocks containing different Tx. In the example shown on the right side of Fig. 3A, ledger A stores block α containing Txα linked to block 2, while ledger B stores block 3 containing Tx3 linked to block 2 and block 4 containing Tx4 linked to block 3. Tx3 may correspond to the above-mentioned second reservation Tx, for example, and Txα may correspond to the above-mentioned fraudulent reservation Tx, for example.

[0022] In this way, when Ledger A goes offline, communication between Ledger A and Ledger B is cut off, and Ledger A and Ledger B will update the blockchain independently.

[0023] Next, as shown on the left side of Figure 3B, when Ledger A of mobile entity A returns to a state where it can communicate with other mobile entities (returns offline), Ledger A and Ledger B share different blockchains. In Ledger A and Ledger B in the example shown on the left side of Figure 3B, the block connected to Block 2 branches, and Block α containing Txα is connected to Block 2, and Block 3 containing Tx3 and Block 4 containing Tx4 are connected to Block 2. Hereinafter, the longest blockchain among the blockchains that branch and connect to blocks will be referred to as the main chain, and the other blockchains will be referred to as side chains. In the example shown on the left side of Figure 3B, Block 3 containing Tx3 and Block 4 containing Tx4 correspond to the main chain of Block 2, and Block α containing Txα corresponds to the side chain of Block 2.

[0024] Thus, when Ledger A comes back online, the blockchain connected to Block 2 will diverge, resulting in a fork.

[0025] Next, as shown on the right side of Figure 3B, block α, which includes Txα, a side chain of block 2, is deleted, and the fork is resolved. At this time, Txα, which was included in block α, is not deleted but is stored in the transaction pool of the mobile device installed in each mobile device. In the example shown on the right side of Figure 3B, Txα is stored in the transaction pools of mobile device A and mobile device B.

[0026] Next, as shown in Fig. 3C, when a new block is generated, Txα is included and stored in Ledgers A and B. In the example shown in Fig. 3C, block 5 including the same Txα is linked to block 4 and stored in Ledgers A and B.

[0027] In this way, the fork is resolved and Ledgers A and B now have the same blockchain. Returning to Figure 2F, we will continue with the explanation below.

[0028] Finally, in step 7, as shown in Figure 2F, the user who attempted fraudulent use returns Bike A. The fee collection algorithm is then executed, and the fee for using Bike A is collected. However, only the fees for the first and second reservations are collected, and the fee for the use between 12:15 and 16:15, i.e., the fraudulent use, is not collected.

[0029] This is because when Bike A's ledger A returns to online status in step 6, the fraudulent reservation Tx is stored in ledgers A, B, and C after the second reservation Tx, and the reservation time slot of the second reservation Tx and the reservation time slot of the fraudulent reservation Tx are booked together. Also, the fee collection algorithm does not collect the fee for the fraudulent reservation, which is a booked reservation (i.e., a competing reservation) and is a later reservation. In this way, the user can use Bike A for four hours without paying the fee.

[0030] As described above, when using blockchain to manage things like object reservations, there is a problem in that the behavior of the blockchain when a fork occurs can be exploited to allow the object to be used fraudulently.

[0031] In contrast, a control method according to one embodiment of the present disclosure is a control method for the first node in a system used to use a service target, which includes a first node that manages a first blockchain using a first distributed ledger and multiple second nodes that each manage a second blockchain using a second distributed ledger, and which generates first transaction data indicating that the service target has been unlocked when the service target is used, the first transaction data including a first contract ID that uniquely identifies a first contract for use of the service target, and stores a block including the first transaction data in the first blockchain.

[0032] In this way, the first transaction data indicating that the service object has been unlocked is stored in the first blockchain. As a result, even if there is a conflict between the first contracts for the service object corresponding to the first transaction data, the first transaction data stored in the first and second blockchains can be used as a trigger to collect fees for using the service object. This makes it possible to prevent fraudulent use of the service object through the misuse of the blockchain.

[0033] Furthermore, for example, a fee collection smart contract for collecting the usage fee for the service target may be executed, and when executing the fee collection smart contract, the first transaction data may be stored in the first blockchain and the second blockchain, and the fee collection smart contract may be caused to check whether the usage fee for the first contract, which is the first contract identified by the first contract ID included in the first transaction data, for the use of the service target has not yet been collected, and if the first transaction data is stored and has not yet been collected, the fee collection smart contract may be caused to collect the usage fee for the first contract.

[0034] In this way, by executing the fee collection smart contract, it is possible to collect fees for using the service object in the first contract, even if there is a conflict between the first contracts for the service object corresponding to the first transaction data.

[0035] Furthermore, for example, the case where the amount has not been collected may be a case where the first blockchain and the second blockchain store second transaction data for executing the first contract and third transaction data for executing the second contract for using the service target, and further, the time period for using the service target included in the first contract partially overlaps with the time period for using the service target included in the second contract.

[0036] Furthermore, for example, the fee collection smart contract may be further configured to create an incident report indicating that there has been fraud in the use of the service object included in the first contract.

[0037] Furthermore, for example, the first blockchain and the second blockchain may further store second transaction data for executing the first contract and third transaction data for executing a second contract for using the service target, and the fraud detection smart contract may be made to check whether there is a competing contract in which the time period for using the service target included in the first contract partially overlaps with the time period for using the service target included in the second contract, and if there is a competing contract, the fraud detection smart contract may be made to assign a flag to the first contract indicating that the usage fee has not yet been collected, and a fee collection smart contract for collecting the usage fee for the service target may be made to collect the fee for the first contract to which the flag has been assigned.

[0038] In this way, by executing the fee collection smart contract, it is possible to collect fees for using the service object in the first contract, even if there is a conflict between the first contracts for the service object corresponding to the first transaction data.

[0039] Furthermore, for example, the system may be used for a service for sharing multiple mobile objects, the service targets being the multiple mobile objects, the first contract and the second contract being reservations for use of the first mobile object, and the second transaction data and the third transaction data being reservation transaction data for a user to make a reservation for use of the first mobile object via the first node, and may include the user's ID, a reservation time period indicating a time period during which the user will use the first mobile object, and a reservation number for identifying the reservation for use.

[0040] In this way, even if there is a conflict in the reservation of the service object corresponding to the first transaction data, the fee for using the service object in the first contract can be collected using the first transaction data stored in the first blockchain and the second blockchain as a trigger. Therefore, it is possible to prevent fraudulent use of the service object by misusing the blockchain.

[0041] Furthermore, for example, the first node may further receive a request to unlock the first mobile body from the user as a request to start using the first mobile body, and the first node may check whether the reservation transaction data corresponding to the unlocking request is stored in the first blockchain, and if the reservation transaction data is stored, may allow the user to unlock the first mobile body during the time period and generate the first transaction data.

[0042] Furthermore, for example, the method may further include acquiring rental transaction data indicating that the first mobile object has been rented to the user, the rental transaction data including the user's ID, the reservation number, and a timestamp of the time the first mobile object was rented to the user, storing a second block including the rental transaction data in the first blockchain, acquiring return transaction data indicating that the user has returned the first mobile object, the return transaction data including the user's ID, the reservation number, and a timestamp of the time the user returned the first mobile object, storing a third block including the return transaction data in the first blockchain, and collecting the usage fee for the first mobile object against the user's ID included in the reservation transaction data.

[0043] A control device according to one embodiment of the present disclosure is a control device in a system used for using a service object, comprising a control device that manages a first blockchain using a first distributed ledger and a plurality of other control devices that each manage a second blockchain using a second distributed ledger, the control device comprising a processor and a memory, wherein the processor generates first transaction data indicating that the service object has been unlocked when the service object is used, the first transaction data including a first contract ID that uniquely identifies a first contract for using the service object, and the processor stores a block including the first transaction data in the first blockchain.

[0044] A program according to one embodiment of the present disclosure is a program for causing a computer to execute a control method for a first node in a system used to use a service object, the system including a first node that manages a first blockchain in a first distributed ledger and multiple second nodes that each manage a second blockchain in a second distributed ledger, the program causing a computer to execute the following steps: generate first transaction data indicating that the service object has been unlocked when the service object is used, the first transaction data including a first contract ID that uniquely identifies a first contract that uses the service object; and store a block including the first transaction data in the first blockchain.

[0045] Hereinafter, embodiments will be described with reference to the drawings. Note that each of the embodiments described below represents a specific example of the present disclosure. In other words, the numerical values, shapes, materials, components, component arrangements and connection forms, steps, and step orders shown in the following embodiments are merely examples and are not intended to limit the present disclosure. Furthermore, among the components in the following embodiments, components that are not recited in the independent claims that represent the highest concepts are not necessarily required to achieve the objectives of the present disclosure, but are described as components that constitute more preferred embodiments.

[0046] (Embodiment) First, a system configuration according to the present disclosure will be described. The system includes a first node that manages a first blockchain using a first distributed ledger and multiple second nodes that each manage a second blockchain using a second distributed ledger, and is used to utilize service targets. The system may be used, for example, for a service that shares multiple mobile objects, in which case the service targets are multiple mobile objects. In this embodiment, the system accepts a reservation for use of a specific mobile object from a user via a terminal (or mobile object) and rents the specific mobile object to the user in accordance with the accepted reservation. When the system accepts a rental request for the reserved specific mobile object from the user via the terminal (or mobile object) during the reserved time slot of the accepted reservation, the system permits the rental of the specific mobile object to the user. Specifically, when the system accepts a request to unlock the specific mobile object from the user, the system confirms the reservation made in advance and permits the user to unlock the specific mobile object during the reserved time slot according to the confirmation result.

[0047] Note that examples of mobile objects in sharing services include bicycles, motorbikes, automobiles, ships, and aircraft.

[0048] FIG. 4 is a diagram illustrating an example of a configuration of a system according to an embodiment.

[0049] 4, the system 1 includes, for example, mobile entities 10A to 10C and terminals 11A to 11C. In this example, the mobile entities 10A to 10C each have a distributed ledger for sharing data of the same content. These distributed ledgers share, for example, a blockchain with the same configuration.

[0050] Mobile objects 10A to 10C and terminals 11A to 11C are connected via a network. The network may be, for example, the Internet or a mobile phone carrier network, but may be configured from any communication line or network.

[0051] In the following, each of the moving bodies 10A to 10C will also be referred to as moving body 10, but the moving bodies 10A to 10C may also be referred to as moving bodies A to C. Furthermore, each of the terminals 11A to 11C will also be referred to as terminal 11, but the terminals 11A to 11C may also be referred to as terminals A to C. Furthermore, the distributed ledgers provided in the moving bodies 10A to 10C, respectively, may also be referred to as ledgers A to C.

[0052] The system for managing the distributed ledger that stores the blockchain may be of any type: public, private, or consortium.

[0053] FIG. 5A is a diagram illustrating another example of the configuration of the system according to the embodiment.

[0054] 5A shows, for example, mobile entities 10A and 10B, terminals 11A and 11B, and a management server 20. In this example, the mobile entities 10A and 10B and the management server 20 each have a distributed ledger for sharing the same data. These distributed ledgers share, for example, a blockchain with the same configuration.

[0055] The mobile objects 10A and 10B, the terminals 11A and 11B, and the management server 20 are connected via a network. The network may be, for example, the Internet or a mobile phone carrier network, but may be configured from any communication line or network.

[0056] FIG. 5B is a diagram illustrating another example of the configuration of the system according to the embodiment.

[0057] 5B shows, for example, mobile entities 10A to 10C and terminals 11A to 11C. In this example, each of the terminals 11A to 11C holds a distributed ledger for sharing data of the same content. These distributed ledgers share, for example, a blockchain with the same configuration.

[0058] Mobile objects 10A to 10C and terminals 11A to 11C are connected via a network. The network may be, for example, the Internet or a mobile phone carrier network, but may be configured from any communication line or network.

[0059] FIG. 5C is a diagram illustrating another example of the configuration of the system according to the embodiment.

[0060] 5C shows, for example, mobile entities 10A to 10C and terminals 11A to 11C. In this example, the mobile entities 10A to 10C and terminals 11A to 11C each have a distributed ledger for sharing the same data. These distributed ledgers share, for example, a blockchain with the same configuration.

[0061] Mobile objects 10A to 10C and terminals 11A to 11C are connected via a network. The network may be, for example, the Internet or a mobile phone carrier network, but may be configured from any communication line or network.

[0062] Below, we will explain each component of the system in Fig. 4. The system configurations in Fig. 5A to Fig. 5C are similarly applicable to the system in Fig. 4, except that the device or terminal that holds the distributed ledger is different.

[0063] First, a description will be given of the mobile body devices mounted on the mobile bodies 10A to 10C. Note that, hereinafter, the mobile body devices mounted on the mobile bodies 10A to 10C may also be referred to as mobile body device A to mobile body device C, respectively.

[0064] [Mobile device 100] The mobile device 100 is an example of a node that manages a blockchain in a distributed ledger. Note that a node can also be referred to as a control device.

[0065] The mobile device 100 is an information processing device mounted on the mobile device 10 and holds a distributed ledger. The mobile device 100 may be a mobile terminal such as a smartphone or a tablet.

[0066] FIG. 6 is a diagram illustrating an example of the configuration of a mobile device 100 according to an embodiment.

[0067] The mobile device 100 according to this embodiment 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, a blockchain 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.

[0068] <Input section 101> The input unit 101 accepts input from a user. The input unit 101 displays the accepted information input on the display unit 112, transmits it to the transaction data generation unit 102, or transmits it to the communication unit 111. For example, the input unit 101 may accept an information input indicating a return from the user.

[0069] <Transaction Data Generator 102> The transaction data generator 102 generates transaction data.

[0070] In this embodiment, the transaction data generation unit 102 generates rental transaction data indicating that the mobile body 10 has been rented to a user. Specifically, when the mobile body 10 is rented to a user, the transaction data generation unit 102 generates rental transaction data indicating that the mobile body 10 has been rented to the user. For example, when an unlocking request from the user is received and the mobile body is unlocked, the transaction data generation unit 102 generates rental transaction data. The rental transaction data includes a user ID, a reservation number (reservation ID) for identifying the usage reservation, and a timestamp of the time when the mobile body 10 was rented to the user.

[0071] Furthermore, in this embodiment, the transaction data generation unit 102 generates unlocking completion transaction data that indicates to the user that unlocking of the mobile body 10 has been completed. Specifically, for example, when an unlocking request from the user is received and the mobile body 10 is unlocked, the transaction data generation unit 102 generates the unlocking completion transaction data. The unlocking completion transaction data includes the user ID that unlocked the mobile body 10, the device ID of the mobile body device 100 that unlocked the mobile body 10, the corresponding reservation number (reservation ID), and the date and time when the mobile body 10 was unlocked. The date and time when the mobile body 10 was unlocked may be a timestamp of the time when the mobile body 10 was unlocked.

[0072] In other words, in this embodiment, when the transaction data generation unit 102 receives an unlocking request from a user and unlocks the mobile object 10, it generates unlocking completion transaction data, and then generates lending transaction data.

[0073] Furthermore, the transaction data generation unit 102 generates return transaction data indicating that the user has returned the mobile object 10. Specifically, when the user returns the mobile object 10, the transaction data generation unit 102 generates return transaction data indicating that the user has returned the mobile object 10. The fact that the user has returned the mobile object 10 may be determined by the input unit 101 receiving information input indicating the return from the user, by the input unit 101 receiving information input indicating the return from the user via the terminal 11 (i.e., the communication unit 111 receiving information input from the terminal 11), by the user locking the mobile object 10, or by the communication unit 111 receiving a notification transmitted from a predetermined return facility when the return of the mobile object 10 is accepted at the return facility. The return transaction data includes a user ID, a reservation number (reservation ID), and a timestamp of the time when the user returned the mobile object 10.

[0074] Note that the reservation transaction data is generated by terminal 11A, but when mobile device 100 accepts a usage reservation from a user, transaction data generation unit 102 may generate reservation transaction data for making the usage reservation. Specifically, when the user inputs a usage reservation into input unit 101, transaction data generation unit 102 generates reservation transaction data including reservation information indicating the usage reservation. The reservation information includes a user ID, a reservation number (reservation ID) for identifying the usage reservation, and a reservation time period indicating the time period during which the user will use mobile device 10. The reservation information may further include a device ID for identifying mobile device 10 for which the usage reservation has been made.

[0075] In addition, when the fraud detection unit 110 detects unlocking completion transaction data that satisfies specified conditions, the transaction data generation unit 102 may generate transaction data that includes an incident report indicating that there has been fraud in the use of the mobile object 10 that is the target of the service.

[0076] <Transaction Data Verification Unit 103> When the communication unit 111 receives transaction data, the transaction data verification unit 103 executes a verification algorithm to verify the validity of the transaction data. The transaction data verification unit 103 then stores the verified transaction data in a transaction pool area of the state storage unit 109. The verified transaction data stored in the state storage unit 109 is transmitted by the communication unit 111 to other mobile devices 100 as information on transaction data to be stored in the next block to be generated.

[0077] For example, the transaction data verification unit 103 verifies whether a digital signature generated by a correct method is attached to the transaction data received by the communication unit 111. Here, the transaction data received by the communication unit 111 is any one of reservation transaction data, unlocking completion transaction data, lending transaction data, and return transaction data. In other words, the transaction data verification unit 103 verifies the legitimacy of the reservation transaction data, unlocking completion transaction data, lending transaction data, and return transaction data.

[0078] When transaction data is generated by transaction data generator 102, transaction data verifier 103 does not need to verify the validity of the transaction data.

[0079] <Block Generation Unit 104> The block generation unit 104 generates a block containing transaction data whose legitimacy 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 among the multiple transaction data that have been verified and are stored in the state storage unit 109. The block generation unit 104 selects multiple blocks to be used for block generation from among the multiple transaction data that have not yet been used for block generation. The block generation unit 104 may delete multiple transaction data that have already been used for block generation from the state storage unit 109.

[0080] Note that the blocks generated by the block generator 104 of one mobile device 100 may differ from the blocks generated by the block generator 104 of another mobile device 100. This is because the verified transaction data stored in the state storage unit 109 may differ for each mobile device 100 depending on the communication state of each mobile device 100, and the criteria for block generation in the block generator 104 may differ.

[0081] The block generation criteria (rules regarding transaction data to be stored in a block) may be held by each mobile device 100. The block generator 104 selects multiple transaction data from the verified transaction data stored in the state storage unit 109 based on the block generation criteria held by the mobile device 100 having the block generator 104, and generates a block including the selected multiple transaction data.

[0082] <Synchronization unit 105> The synchronization unit 105 synchronizes the blocks generated by the block generation unit 104 with other mobile devices 100 .

[0083] In this embodiment, the synchronization unit 105 transmits the block generated by the block generation unit 104 to the other mobile devices 100 via the communication unit 111. Then, the synchronization unit 105 executes a consensus algorithm for the transmitted block in collaboration with the other mobile devices 100. The consensus algorithm may be a consensus algorithm called PBFT (Practical Byzantine Fault Tolerance), or any other known consensus algorithm. Examples of known consensus algorithms include POW (Proof of Work) and POS (Proof of Stake). When PBFT is used, the synchronization unit 105 first receives reports from each of the other mobile devices 100 indicating whether or not the verification of the transaction data was successful, and determines whether or not the number of such reports exceeds a predetermined number. The synchronization unit 105 may then determine that the authenticity of the transaction data has been verified by the consensus algorithm when the number of such reports exceeds the predetermined number. In this way, the synchronizer 105 agrees that the transaction data is valid (i.e., validity) based on the reports sent from each of the other mobile devices 100, and agrees on the validity of the block.

[0084] In addition, the synchronization unit 105 links the agreed-upon block to the first blockchain managed by the distributed ledger stored in the distributed ledger storage unit 108.

[0085] <Smart contract execution unit 106> The smart contract execution unit 106 operates the smart contract by executing the contract code and the like included in the transaction data stored in the distributed ledger of the distributed ledger storage unit 108.

[0086] 《Pre-order SC》 In this embodiment, the smart contract execution unit 106 may execute a reservation process for reserving the use of a mobile object that is the service target by operating a reservation smart contract. The smart contract execution unit 106 may execute the reservation process when a block including reservation transaction data is added to the blockchain in the distributed ledger stored in the distributed ledger storage unit 108.

[0087] 《Fee Collection SC》 In this embodiment, the smart contract execution unit 106 may perform fee calculation processing by running a fee collection smart contract. The smart contract execution unit 106 performs fee calculation processing when a block including return transaction data is added to the blockchain in the distributed ledger stored in the distributed ledger storage unit 108. Note that the fee calculation processing is the same as the processing performed by the blockchain management unit 107, which will be described later.

[0088] The smart contract execution unit 106 may also cause the fee collection smart contract to check whether the unlocking completion transaction data is stored in the blockchain in the distributed ledger and whether the usage fee for the reservation corresponding to the reservation ID included in the unlocking completion transaction data has not yet been collected. Furthermore, if the unlocking completion transaction data is stored and has not yet been collected, the smart contract execution unit 106 may cause the fee collection smart contract to collect the usage fee for the reservation.

[0089] "Fraud Detection SC" Furthermore, in this embodiment, the smart contract execution unit 106 may perform fraud detection processing by running a fraud detection smart contract. The smart contract execution unit 106 performs fraud detection processing when a block including reservation transaction data is added to the blockchain in the distributed ledger stored in the distributed ledger storage unit 108. Note that the fraud detection processing is the same as the processing performed by the fraud detection unit 110, which will be described later.

[0090] In this way, the smart contract execution unit 106 can manage the collection of usage fees, the detection of fraudulent reservations, etc., using a distributed ledger by running smart contracts. Note that the fee collection smart contract and the fraud detection smart contract are generated by the user using an application on the terminal 11, for example, and blocks containing these smart contracts are stored in advance in the blockchain.

[0091] <Blockchain Management Department 107> The blockchain management unit 107 manages a blockchain (hereinafter referred to as the first blockchain) managed by a distributed ledger (hereinafter referred to as the first distributed ledger) stored in the distributed ledger storage unit 108.

[0092] Main chain and side chain In this embodiment, the blockchain management unit 107 acquires a blockchain (hereinafter referred to as the second blockchain) managed in a distributed ledger (hereinafter referred to as the second distributed ledger) held by another mobile device 100 via the communication unit 111, and compares the acquired second blockchain with the first blockchain managed in the first distributed ledger in the distributed ledger storage unit 108. The blockchain management unit 107 determines, through the comparison, whether the multiple blocks constituting the first blockchain are the same as the multiple blocks constituting the second blockchain. If the multiple blocks constituting the first blockchain are not the same as the multiple blocks constituting the second blockchain, the blockchain management unit 107 determines which is larger (longer): the number of one or more first difference blocks that are included in the first blockchain but not in the second blockchain, or the number of one or more second difference blocks that are included in the second blockchain but not in the first blockchain. 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. Note that this determination is made when, as a result of comparing the first and second blockchains, the first blockchain has one or more first difference blocks and the second blockchain has one or more second difference blocks.

[0093] The blockchain management unit 107 adds the greater number (longer number) of one or more first difference blocks and one or more second difference blocks to the end of one or more common blocks common to the first blockchain and the second blockchain. The blockchain management unit 107 then adds one or more blocks containing one or more transaction data contained in the fewer number (shorter number) of one or more first difference blocks and one or more second difference blocks to the end of the greater number of added blocks. In other words, the blockchain management unit 107 determines the greater number of one or more first difference blocks and one or more second difference blocks as the main chain block, and determines the fewer number of one or more first difference blocks and one or more second difference blocks as the side chain block. The blockchain management unit 107 then adds the main chain block and the additional block generated from one or more transaction data contained in the side chain block to the end of the one or more common blocks, in that order: the main chain block, then the additional block.

[0094] In this way, the blockchain management unit 107 updates the first blockchain managed in the first distributed ledger in the distributed ledger storage unit 108. In other words, the blockchain management unit 107 compares the first blockchain with the second blockchain managed in the second distributed ledger held by another mobile device 100, and if the configurations of these blockchains are different, updates the first blockchain so that the configurations are the same.

[0095] In addition, if, as a result of comparing the first blockchain and the second blockchain, the first blockchain does not have one or more first difference blocks, the blockchain management unit 107 updates the first blockchain by adding one or more second difference blocks to the first blockchain.

[0096] Here, the one or more first difference blocks are blocks that are not included in the second blockchain, for example, generated when a mobile device 100 is added to the first blockchain while it cannot communicate with other mobile devices 100. Note that the number of the one or more first difference blocks is likely to be less than the number of the one or more second difference blocks when multiple other mobile devices 100 can communicate with each other. This is because the second blockchain is synchronized and managed by a second distributed ledger held by multiple other mobile devices 100, which is greater in number than the mobile device 100 that manages the first blockchain. Therefore, it is considered that the multiple other mobile devices 100 have more opportunities to generate blocks than a single mobile device 100. Therefore, the one or more first difference blocks generated by a single mobile device 100 that cannot communicate with other mobile devices 100 are more likely to become side chain blocks than main chain blocks.

[0097] The one or more first difference blocks may include a block containing transaction data including information about a contract, such as a reservation for use of the mobile unit 10. The transaction data including information about the contract may be, for example, reservation transaction data, unlocking completion transaction data, lending transaction data, and return transaction data.

[0098] It should be noted that the blockchain management unit 107 does not need to acquire the entire second blockchain, but may acquire only a portion of it. For example, the portion of the second blockchain acquired by the blockchain management unit 107 here is one or more blocks subsequent to the block after the last block after the previous update of the first blockchain was executed.

[0099] Loan Processing The blockchain management unit 107 may also perform a rental process to rent the mobile body 10 to a user. In this case, when the communication unit 111 receives an unlocking request, the blockchain management unit 107 checks whether a reservation based on the unlocking request has been made by referring to the first blockchain in the first distributed ledger stored in the distributed ledger storage unit 108. Specifically, the blockchain management unit 107 determines whether reservation transaction data including the same reservation number as the reservation number included in the unlocking request is stored in the first blockchain. If reservation transaction data including the same reservation number as the reservation number included in the unlocking request is stored in the first blockchain, the blockchain management unit 107 determines that a reservation based on the unlocking request has been made and instructs the mobile body 10 to unlock. When the mobile body 10 receives the unlocking instruction, it operates the actuator that is currently locking the mobile body based on the unlocking instruction, thereby unlocking the mobile body.

[0100] The unlock request is information for unlocking the mobile body 10 that the user has reserved in the usage reservation. The unlock request only needs to include at least a reservation number to identify the usage reservation. The unlock request may further include a user ID indicating the user who made the usage reservation, a mobile body ID of the mobile body 10 that is the subject of the usage reservation, a device ID of the mobile body device 100 that has reserved the mobile body 10, a reserved time period, etc.

[0101] In addition, instead of receiving an unlocking request, the blockchain management unit 107 may instruct the mobile body in which the mobile device 100 is installed to unlock when the start time of the reserved time period for use reservation stored in the first blockchain arrives.

[0102] <<Fee calculation process>> Furthermore, the blockchain management unit 107 may perform fee calculation processing instead of the smart contract executed by the smart contract execution unit 106. The blockchain management unit 107 performs fee calculation processing when a certain interval has elapsed since the previous processing execution or when return transaction data is included in a block newly linked to the first blockchain in the first distributed ledger stored in the distributed ledger storage unit 108. The blockchain management unit 107 searches the first blockchain in the distributed ledger storage unit 108 and determines whether two or more transaction data each containing conflicting contracts are included in the first blockchain managed in the first distributed ledger. A conflicting contract is, for example, a contract in which the time period for using a service object included in the first contract partially overlaps with the time period for using a service object included in the second contract. In this embodiment, an example of a conflicting contract may be a first reservation and a second reservation that conflict with the first reservation, both of which include the same mobile entity ID and two or more reservation time periods that partially overlap. When the first blockchain contains competing reservations, the blockchain management unit 107 fulfills the first reservation or the competing reservation included in the transaction data added to the first blockchain first, out of the transaction data including the first reservation and the transaction data including the competing reservations. In other words, when there are overlapping reservations, the blockchain management unit 107 calculates a fee for the earliest usage reservation among the overlapping reservations and executes a fee collection process to collect the calculated fee from the user. In other words, the blockchain management unit 107 does not calculate a fee or execute a fee collection process for usage reservations other than the earliest usage reservation among the overlapping reservations, in order to prevent duplicate collection from the same user.

[0103] In this embodiment, when the first blockchain contains unlocking completion transaction data that satisfies predetermined conditions, the blockchain management unit 107 uses the unlocking completion transaction data to collect the fee for the first reservation or competing reservation for which the fee has not yet been collected. Because the unlocking completion transaction data exists in the first blockchain, even if there is a first reservation or competing reservation, it is clear that the mobile object 10 was certainly used by the first reservation or competing reservation for which the fee has not yet been collected, so collecting the fee will not result in double collection.

[0104] Note that the usage reservations that are subject to fee calculation are those with reservation numbers included in the return transaction data stored in the first blockchain, for which fees have not yet been calculated. In other words, usage reservations for which fees have already been calculated are excluded from the scope of fee calculation. Furthermore, if a usage reservation corresponding to the reservation number included in the return transaction data is not stored in the first blockchain, fee calculation for the return transaction data will not be performed.

[0105] <Distributed ledger storage unit 108> The distributed ledger storage unit 108 stores the first distributed ledger managed by the first blockchain. In this embodiment, the first distributed ledger stores blocks including reservation transaction data, unlocking completion transaction data, lending transaction data, and return transaction data in the first blockchain.

[0106] <Status storage unit 109> The state storage unit 109 is a storage unit that stores the latest version of the distributed ledger data. The data stored in the state storage unit 109 can be changed or deleted by a computer. The state storage unit 109 includes, for example, an on-memory area for storing variables, functions, etc. for executing smart contracts, and a transaction pool area for storing transaction data. 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 a second blockchain acquired via the communication unit 111. The state storage unit 109 may store one or more second difference blocks of the second blockchain. The state storage unit 109 may store a 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 a smart contract invoked by the transaction data. The state storage unit 109 may also store variables of smart contracts stored in the distributed ledger. The state storage unit 109 may also store transaction data generated by the transaction data generation unit 102. The state storage unit 109 may also store transaction data received by the communication unit 111.

[0107] The state storage unit 109 may temporarily store the above-mentioned data.

[0108] <Fraud detection unit 110> Instead of a smart contract executed by the smart contract execution unit 106, the fraud detection unit 110 may perform a fraudulent reservation detection process that detects whether unlocking completion transaction data that satisfies a predetermined condition is stored in the first blockchain managed by the first distributed ledger stored in the distributed ledger storage unit 108. The unlocking completion transaction data that satisfies the predetermined condition may be, for example, unlocking completion transaction data that includes a reservation ID that is considered to have no corresponding reservation, or unlocking completion transaction data that was issued at a time when no reservation exists. By detecting that unlocking completion transaction data that satisfies the predetermined condition is stored in the fraudulent reservation detection process, the fraud detection unit 110 can detect that there has been a fraudulent reservation for which a fee would not be collected using an existing fee calculation algorithm.

[0109] Incident Report Furthermore, if the fraud detection unit 110 determines that unlocking completion transaction data satisfying a predetermined condition has been stored, it may create an incident report indicating that fraud has occurred in the use of the mobile object 10 that is the service target, and notify the transaction data generation unit 102 of the incident report. The incident report may include the reason for determining that fraud has occurred, and the detected unlocking completion transaction data or the block containing the unlocking completion transaction data. Reasons for determining that fraud has occurred include conflicting reservations, a large difference between the block generation time and the block linkage time, the existence of multiple reservations corresponding to the return transaction data, or the unlocking completion transaction data satisfying a predetermined condition. The unlocking completion transaction data or the block containing it may include one or more transaction data related to the unlocking completion transaction data. The related transaction data may be rental transaction data or reservation transaction data having a reservation ID included in the unlocking completion transaction data.

[0110] The incident report may further include any one of the detection time, the user ID of the target user, and the terminal ID installed in the target mobile object. The detection time indicates the time when the fraud detection unit 110 determines that the unlocking completion transaction data is stored in the first blockchain, or the time when the unlocking completion transaction data is generated. The target user indicates the user who made the reservation included in the conflicting reservation transaction data. The terminal ID indicates the mobile object device 100 that made the reservation for the mobile object 10 included in the unlocking completion transaction data.

[0111] 《Fraud Flag》 Furthermore, when the fraud detection unit 110 detects a fraudulent reservation, it may flag the fraudulent reservation or reservation transaction data corresponding to the fraudulent reservation to indicate that the fee has not yet been collected. The fraud detection unit 110 may further flag the fraudulent reservation or reservation transaction data corresponding to the fraudulent reservation, including the device ID of the mobile device 100 that detected the fraudulent reservation or the terminal ID of the terminal 11 that detected the fraud, and the time when the fraudulent reservation was detected. The fraud detection unit 110 notifies the synchronization unit 105 of the flagged fraudulent reservation or reservation transaction data corresponding to the fraudulent reservation. As a result, a consensus algorithm is executed between the flagged fraudulent reservation or reservation transaction data corresponding to the fraudulent reservation and other mobile devices 100, and the flagged fraudulent reservation or reservation transaction data corresponding to the fraudulent reservation is stored in the blockchain of each mobile device 100. As a result, the fee collection smart contract (described later) can be caused to collect fees for the flagged fraudulent reservations.

[0112] <Communications Department 111> The communication unit 111 transmits information to other mobile devices 100 or terminals 11 via the network, and receives information from other mobile devices 100 or terminals 11. The communication unit 111 communicates with other mobile devices 100 or terminals 11 via the network. This communication may be performed using TLS (Transport Layer Security), and the encryption key for TLS communication may be held in the communication unit 111.

[0113] In this embodiment, the communication unit 111 receives reservation transaction data from the terminal 11. The communication unit 111 also receives an unlock request from the terminal 11. The communication unit 111 also receives transaction data that has been verified in the other mobile device 100 from the other mobile device 100. The communication unit 111 transmits and receives blocks to and from the other mobile device 100 in order to jointly execute a consensus algorithm.

[0114] <Display section 112> The display unit 112 displays information input received by the input unit 101. The display unit 112 may display information transmitted from the terminal 11. The display unit 112 may display a display (UI: User Interface) for receiving a request from the user to return the mobile device 100.

[0115] Next, a description will be given of the terminals 11A to 11C. Since the terminals 11A to 11C have the same configuration, they will be referred to as terminal 11 in the description.

[0116] [Terminal 11] 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 a tablet.

[0117] FIG. 7 is a diagram illustrating an example of the configuration of the terminal 11 according to the first embodiment.

[0118] The terminal 11 according to this embodiment includes an input unit 1101 , a display unit 1102 , and a communication unit 1103 .

[0119] <Input section 1101> The input unit 1101 receives information input through user operations, and displays the received information input on the display unit 1102 or transmits it to the communication unit 1103.

[0120] For example, an application for making a reservation for use is installed in the input unit 1101, and the input unit 1101 accepts input to a display (UI) for making a reservation for use. This display (UI) is displayed on the display unit 1102. The input unit 1101 accepts the digital signature of the user who owns the terminal 11, and generates reservation transaction data including the accepted input for the reservation for use and the digital signature.

[0121] Furthermore, the input unit 1101 accepts input to a display (UI) for an unlock request for the reserved mobile device 100. This display (UI) is displayed on the display unit 1102. The input unit 1101 accepts the input for the unlock request and generates the unlock request.

[0122] <Display section 1102> 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 reservation for use. The display unit 1102 also displays a display (UI) for an unlocking request.

[0123] <Communication Unit 1103> The communication unit 1103 transmits information to the mobile device 100 via the network, and receives or is notified of information from the mobile device 100. The communication unit 1103 may also transmit information to or receive information from other terminals 11 via the network.

[0124] In this way, communication unit 1103 communicates with mobile device 100 or other terminals 11 via the network. This communication may be performed using TLS, and an encryption key for TLS communication may be held by communication unit 1103.

[0125] For example, the communication unit 1103 transmits reservation transaction data to the mobile device 100. The communication unit 1103 also transmits an unlock request to the mobile device 100 that made the reservation.

[0126] [System operation, etc.] Next, the operation of the system configured as above will be described.

[0127] First, as a comparative example, normal processing for mobile object A in a service for sharing multiple mobile objects will be described, followed by a description of the processing when the blockchain mechanism is abused to fraudulently use mobile object A, i.e., fraudulent processing. After that, the processing of the present disclosure with anti-fraud measures will be described.

[0128] [First Example of Comparative Example] A process in which mobile object A is always online will be described as a first example of a comparative example.

[0129] FIG. 8 is a flowchart showing an outline of normal processing operations of a system according to a first example of the comparative example. FIG. 8 shows an outline of normal processing operations in which mobile body devices A, B, and C normally perform processing for mobile body A while they are online. FIGS. 9A to 9C are diagrams conceptually illustrating blockchain blocks stored in ledger A of mobile body device A and ledger B of mobile body device B. FIG. 9A is a diagram conceptually illustrating blockchain blocks stored in ledger A and ledger B by the operation of step S1 in FIG. 8. FIG. 9B is a diagram conceptually illustrating blockchain blocks stored in ledgers A and B by the operation of step S3 in FIG. 8. FIG. 9C is a diagram conceptually illustrating blockchain blocks stored in ledgers A and B by the operation of step S5 in FIG. 8. In the following, the description will be given assuming that a user who wants to use mobile body A uses terminal A to perform processing on mobile body device A mounted on mobile body A.

[0130] As shown in Fig. 8, first, for example, terminal A communicates with mobile device A and performs a reservation process for mobile device A on which mobile device A is mounted (S1). More specifically, terminal A communicates with mobile device A, generates reservation transaction data Trsv for reserving the use of mobile device A, and transmits it to mobile device A. In this case, for example, as shown in Fig. 9A, since mobile device A and mobile device B are in a state where they can communicate with other mobile devices (are online), both ledger A and ledger B store blocks including reservation transaction data Trsv for reserving the use of mobile device A.

[0131] Next, for example, terminal A communicates with mobile device A and performs a lending process for mobile device A (S3). More specifically, terminal A communicates with mobile device A and transmits a request to unlock mobile device A in order to use mobile device A. Mobile device A then unlocks mobile device A, and generates lending transaction data Trnt indicating the start of lending of mobile device A, triggered by the unlocking of mobile device A. In this case, for example, as shown in FIG. 9B, since mobile device A and mobile device B are in a state where they can communicate with other mobile devices (are online), both ledger A and ledger B store a block including lending transaction data Trnt indicating the start of lending of mobile device A.

[0132] Next, for example, terminal A communicates with mobile device A and performs a process for returning mobile device A (S5). More specifically, the user who operates terminal A uses the unlocked mobile device A for the reserved time and then returns it. When mobile device A is returned, it generates return transaction data Trtn indicating the completion of the return of mobile device A. In this case, for example, as shown in FIG. 9C , since mobile device A and mobile device B are in a state where they can communicate with other mobile devices (are online), both ledger A and ledger B store a block including return transaction data Trtn indicating the completion of the return of mobile device A.

[0133] Next, the mobile device A or the like performs a fee calculation process (S7). More specifically, the mobile device A or the like executes a fee calculation algorithm, and collects a fee for using the mobile device A in response to a reservation for use of the mobile device A made by the user.

[0134] Next, the details of the processes of steps S1 to S5 shown in Fig. 8, i.e., the reservation process, rental process, and return process, will be described using a sequence diagram. In the following, the description will be made assuming that a user who wants to use mobile object A uses terminal A to perform the reservation process, rental process, and return process of mobile object A on mobile object device A mounted on mobile object A.

[0135] [Reservation process according to the first example of the comparative example] FIG. 10 is a sequence diagram showing a reservation process of a system according to a first example of the comparative example.

[0136] First, terminal A generates reservation transaction data Trsv for reserving use of mobile object A based on the operation of a user who wants to use mobile object A (S101). Here, an application is installed as input unit 1101 in terminal A, i.e., terminal 11A, and the application may generate reservation transaction data Trsv based on the user's operation.

[0137] Next, terminal A communicates with mobile unit A of mobile unit A, and transmits the reservation transaction data Trsv generated in step S101 to mobile unit A (S102).

[0138] Next, when mobile device A receives the reservation transaction data Trsv transmitted in step S102, it transfers the reservation transaction data Trsv to other mobile devices, mobile devices B and C (S103). As a result, mobile devices B and C acquire the reservation transaction data Trsv.

[0139] Next, each of the mobile devices A, B, and C executes a verification algorithm to verify the authenticity of the acquired reservation transaction data Trsv (S104). If the verification of the reservation transaction data Trsv is not successful, the reservation process is terminated.

[0140] Next, mobile devices A, B, and C each store the reservation transaction data Trsv verified by the verification algorithm executed in step S104 in a transaction pool (S105). More specifically, mobile device A stores the verified reservation transaction data Trsv in transaction pool a, mobile device B stores the verified reservation transaction data Trsv in transaction pool b, and mobile device C stores the verified reservation transaction data Trsv in transaction pool c.

[0141] Next, since mobile devices A, B, and C are able to communicate with each other, they exchange information about transaction data to be stored in the next block to be generated (S106). In the example shown in Fig. 10, mobile devices A, B, and C confirm that the transaction data to be stored in the next block to be generated contains verified reserved transaction data Trsv.

[0142] Next, each of the mobile devices A, B, and C generates a block Blc(Trsv) including the verified reservation transaction data Trsv (S107).

[0143] Next, each of mobile devices A, B, and C transmits the block Blc(Trsv) generated in step S107 to the other mobile devices (S108). This allows each of mobile devices A, B, and C to notify the other mobile devices that the validity of the reservation transaction data Trsv included in the block Blc(Trsv) has been successfully verified.

[0144] Next, mobile devices A, B, and C jointly execute a consensus algorithm (S109). Specifically, based on the report notified in step S108, mobile devices A, B, and C each agree that the reservation transaction data Trsv is legitimate transaction data (i.e., legitimacy), and agree on the legitimacy of block Blc(Trsv). In the example shown in FIG. 10, it is agreed that the reservation transaction data Trsv included in block Blc(Trsv) is legitimate transaction data (i.e., legitimacy), and the legitimacy of block Blc(Trsv) is also agreed on. Note that the processes of steps S107 and S108 may be performed when executing the consensus algorithm in step S109.

[0145] Next, mobile devices A, B, and C each link the agreed-upon block Blc (Trsv) in step S109 to a blockchain in the distributed ledger (S110). More specifically, mobile device A links the agreed-upon block Blc (Trsv) to the blockchain in ledger A, and mobile device B links the agreed-upon block Blc (Trsv) to the blockchain in ledger B. Mobile device C links the agreed-upon block Blc (Trsv) to the blockchain in ledger C.

[0146] As a result, as shown in FIG. 9A, ledgers A, B, and C all store a block including reservation transaction data Trsv for reserving use of mobile unit A.

[0147] [Lending process according to the first example of the comparative example] FIG. 11 is a sequence diagram showing a lending process of a system according to a first example of the comparative example.

[0148] First, terminal A transmits a request to unlock mobile body A to mobile body device A based on an operation of a user who wishes to use mobile body A (S301). Here, an application may be installed in terminal A, i.e., terminal 11A, as input unit 1101, and the application may generate and transmit a request to unlock mobile body A based on the user's operation. The request to unlock mobile body A includes information that can identify the reservation for the corresponding mobile body A, such as the user's reservation ID.

[0149] Next, when mobile device A receives the unlock request sent in step S301, it checks whether there is a reservation corresponding to the unlock request in the blockchain of ledger A (S302). Here, mobile device A may check whether there is a reservation corresponding to the unlock request by checking whether there is reservation transaction data Trsv in the blockchain of ledger A. In the example shown in Fig. 10, since the blockchain of ledger A includes reservation transaction data Trsv, mobile device A can check whether there is a reservation corresponding to the unlock request in the blockchain of ledger A.

[0150] Next, mobile device A unlocks mobile device A (S303). Here, mobile device A may unlock mobile device A by issuing an unlock instruction to a device that manages the lock on mobile device A, or may unlock mobile device A directly.

[0151] Next, the mobile device A generates rental transaction data Trnt indicating the start of rental of the mobile device A, triggered by the unlocking of the mobile device A (S304). The rental transaction data Trnt includes the rental start time along with the user ID of the user who uses the mobile device A. The rental start time is, for example, the time when the lock is released.

[0152] Next, mobile device A transfers the lending transaction data Trnt to other mobile devices B and C (S305). As a result, mobile devices B and C acquire the lending transaction data Trnt.

[0153] Next, each of the mobile devices A, B, and C executes a verification algorithm to verify the validity of the lending transaction data Trnt (S306).

[0154] Next, mobile devices A, B, and C each store the verified loan transaction data Trnt in a transaction pool using the verification algorithm executed in step S306 (S307). More specifically, mobile device A stores the verified loan transaction data Trnt in transaction pool a, mobile device B stores the verified loan transaction data Trnt in transaction pool b, and mobile device C stores the verified loan transaction data Trnt in transaction pool c.

[0155] Next, since mobile devices A, B, and C are able to communicate with each other, they exchange information about the transaction data to be stored in the next block to be generated (S308). In the example shown in Fig. 11, mobile devices A, B, and C confirm that the transaction data to be stored in the next block to be generated includes verified lending transaction data Trnt.

[0156] Next, each of the mobile devices A, B, and C generates a block Blc(Trnt) including the verified lending transaction data Trnt (S309).

[0157] Next, mobile devices A, B, and C each transmit the block Blc(Trnt) generated in step S309 to the other mobile devices (S310). This allows mobile devices A, B, and C to each notify the other mobile devices that the validity of the lending transaction data Trnt included in block Blc(Trnt) has been successfully verified.

[0158] Next, mobile devices A, B, and C jointly execute a consensus algorithm (S311). Specifically, based on the report notified in step S310, mobile devices A, B, and C each agree that the loan transaction data Trnt is legitimate transaction data (i.e., legitimacy), and agree on the legitimacy of block Blc(Trnt). In the example shown in FIG. 11, it is agreed that the loan transaction data Trnt included in block Blc(Trnt) is legitimate transaction data (i.e., legitimacy), and the legitimacy of block Blc(Trnt) is also agreed on. Note that the processes of steps S309 and S310 may be performed when executing the consensus algorithm in step S311.

[0159] Next, mobile devices A, B, and C each link the agreed-upon block Blc (Trnt) in step S311 to a blockchain in the distributed ledger (S312). More specifically, mobile device A links the agreed-upon block Blc (Trnt) to the blockchain in ledger A, and mobile device B links the agreed-upon block Blc (Trnt) to the blockchain in ledger B. Mobile device C links the agreed-upon block Blc (Trnt) to the blockchain in ledger C.

[0160] As a result, as shown in FIG. 9B, ledgers A, B, and C all store a block including the lending transaction data Trnt, and it is recorded that the lending of mobile unit A has begun.

[0161] [Return process according to the first example of the comparative example] FIG. 12 is a sequence diagram showing a return process of a system according to a first example of the comparative example.

[0162] First, when the user who used the mobile object A returns the mobile object A, the mobile device A confirms that the mobile object A has been returned (S501). Here, for example, the user A can return the mobile object A by placing the mobile object A at a predetermined return facility, or by placing the mobile object A in a predetermined location and pressing a return button on the UI of the mobile object A. The user A may return the mobile object A by pressing a return button on the UI displayed on the terminal A. The mobile device A may confirm that the mobile object A has been returned by receiving a message from the predetermined return facility or the terminal A indicating that the mobile object A has been returned, or by pressing the return button on the UI of the mobile device A.

[0163] Next, when the mobile device A confirms that the mobile device A has been returned, it generates return transaction data Trtn indicating the completion of the return of the mobile device A (S502). The return transaction data Trtn includes the user ID of the user using the mobile device A, the return time, and the reservation ID when the mobile device A was used. The return time is, for example, the time when the mobile device A confirms that the mobile device A has been returned. Note that the return transaction data Trtn is not limited to being included in the reservation ID, and may include any information that can be used to calculate the usage fee for the user's mobile device A.

[0164] Next, mobile device A transfers the return transaction data Trtn to other mobile devices B and C (S503). As a result, mobile devices B and C acquire the return transaction data Trtn.

[0165] Next, each of the mobile devices A, B, and C executes a verification algorithm to verify the authenticity of the acquired return transaction data Trtn (S504).

[0166] Next, mobile devices A, B, and C each store the verified return transaction data Trtn in a transaction pool using the verification algorithm executed in step S504 (S505). More specifically, mobile device A stores the verified return transaction data Trtn in transaction pool a, and mobile device B stores the verified return transaction data Trtn in transaction pool b. Mobile device C stores the verified return transaction data Trtn in transaction pool c. Although not shown, mobile devices A, B, and C are able to communicate with each other, and therefore exchange information about transaction data to be stored in the next block to be generated. In the example shown in FIG. 12, mobile devices A, B, and C confirm that the verified return transaction data Trtn is included in the transaction data to be stored in the next block to be generated.

[0167] Next, each of the mobile devices A, B, and C generates a block Blc(Trtn) including the verified return transaction data Trtn (S506).

[0168] Next, mobile devices A, B, and C each transmit the block Blc(Trtn) generated in step S506 to the other mobile devices (S507). This allows mobile devices A, B, and C to each notify the other mobile devices that the validity of the return transaction data Trtn included in block Blc(Trtn) has been successfully verified.

[0169] Next, mobile devices A, B, and C jointly execute a consensus algorithm (S508). Specifically, based on the report notified in step S507, mobile devices A, B, and C each agree that the returned transaction data Trtn is valid transaction data (i.e., validity), and agree on the validity of block Blc(Trtn). In the example shown in FIG. 12, it is agreed that the returned transaction data Trtn included in block Blc(Trtn) is valid transaction data (i.e., validity), and the validity of block Blc(Trtn) is also agreed on. Note that the processes of steps S506 and S507 may be performed when executing the consensus algorithm in step S508.

[0170] Next, mobile devices A, B, and C each link the agreed-upon block Blc (Trnt) in step S508 to the blockchain in the distributed ledger (S509). More specifically, mobile device A links the agreed-upon block Blc (Trtn) to the blockchain in ledger A, and mobile device B links the agreed-upon block Blc (Trtn) to the blockchain in ledger B. Mobile device C links the agreed-upon block Blc (Trtn) to the blockchain in ledger C. As a result, as shown in FIG. 9C , ledgers A, B, and C all store a block including the return transaction data Trtn, and the completion of the return of mobile device A is recorded.

[0171] Next, mobile devices A, B, and C each check the reservation information stored in the blockchain (S510). More specifically, mobile devices A, B, and C each execute the reservation smart contract by linking the block including the return transaction data Trtn to the blockchain in their own ledgers, and confirm that the reservation transaction data Trsv exists as reservation information stored in the blockchain.

[0172] Next, mobile devices A, B, and C each execute a fee calculation algorithm (S511). In the example shown in FIG. 12, the fee for using mobile device A is collected. Here, the fee calculation algorithm may be included in the reservation smart contract or the fee collection smart contract. Mobile devices A, B, and C may each execute the fee collection smart contract or the reservation smart contract to collect the fee for the reservation of use of mobile device A included in the reservation transaction data Trsv. Note that, although the execution of the fee calculation algorithm is described as part of the return process in the example shown in FIG. 12, it is not limited to this. It may also be executed in the fee calculation process shown in FIG. 8.

[0173] [Fee calculation process according to comparative example] Next, the fee calculation process in step S7 shown in FIG. 8 will be described in detail with reference to a flowchart.

[0174] 13 is a flowchart for explaining details of the fee calculation process in the system according to the comparative example. The following describes the case where the process is performed by mobile device A as a representative.

[0175] 8, first, mobile device A checks whether there is a trigger for toll collection (S71). This trigger may be the passage of a certain interval, or the inclusion of return transaction data Trtn in a block newly linked to the blockchain of ledger A.

[0176] In step S71, if there is a trigger (Yes in S71), mobile device A searches the blockchain of ledger A (S72). Note that in step S71, if there is no trigger (No in S71), mobile device A returns to step S71.

[0177] Next, mobile device A checks whether there are any other reservations (i.e., overlapping reservations) in the blockchain of ledger A (S73).

[0178] In step S73, if there is a duplicate reservation (Yes in S73), it is checked whether the reservation, i.e., the reservation ID included in the return transaction data Trtn, is the earliest among the duplicate reservations (S74). Note that in step S73, if there is no duplicate reservation (No in S73), the process proceeds to step S75.

[0179] In step S74, if the reservation is the earliest among the overlapping reservations (Yes in S74), mobile device A executes the fee calculation algorithm (S75). This calculates the fee for the reservation, i.e., the reservation ID indicating the reservation for use of mobile device A included in the return transaction data Trtn. Note that in step S74, if the reservation is not the earliest among the overlapping reservations (No in S74), the fee calculation process ends.

[0180] Next, the mobile device A executes a fee collection process (S76). As a result, the fee for using the mobile device A is collected for the reservation ID indicating the reservation for use of the mobile device A made by the user. The fee collection process may be performed for the reservation for use of the mobile device A included in the reservation transaction data Trsv.

[0181] [Second Example of Comparative Example] In the first example of the comparative example, a case where reservation processing, rental processing, and return processing for mobile object A in a service for sharing multiple mobile objects is performed normally when mobile object A is online is described. Next, as a second example of the comparative example, a case where reservation processing, rental processing, and return processing for mobile object A are performed normally when mobile object device A is offline, and then mobile object device A returns to an online state is described.

[0182] FIG. 14 is a flowchart showing an outline of normal processing operations of a system according to a second example of the comparative example. FIG. 14 shows an outline of normal processing operations for normally performing reservation processing, rental processing, and return processing for mobile device A when mobile device A is offline while mobile devices B and C are online. FIGS. 15A to 17 are diagrams conceptually illustrating blockchains stored in ledger A of mobile device A and ledger B of mobile device B. FIG. 15A is a diagram conceptually illustrating blockchain blocks stored in ledger A by the operation of step S1A in FIG. 14. FIG. 15B is a diagram conceptually illustrating blockchain blocks stored in ledger A by the operation of step S3A in FIG. 14. FIG. 15C is a diagram conceptually illustrating blockchain blocks stored in ledger A by the operation of step S5A in FIG. 14. FIGS. 16 and 17 are diagrams conceptually illustrating blockchain blocks stored in ledger A and ledger B by the operation of step S6A in FIG. 14. In the following description, it is assumed that a user who wishes to use moving body A uses terminal A to perform processing on moving body device A mounted on moving body A.

[0183] As shown in FIG. 14, first, for example, terminal A communicates with mobile device A, which is offline (not capable of communicating with other mobile devices B and C), and performs reservation processing for mobile device A, in which offline mobile device A is installed (S1A). That is, terminal A performs reservation processing for local reservation of mobile device A for offline mobile device A. More specifically, terminal A communicates with mobile device A, generates reservation transaction data Trsv for reserving mobile device A, and transmits it to mobile device A. In this case, for example, as shown in FIG. 15A, since mobile device A is offline (not capable of communicating with mobile device B), a block including reservation transaction data Trsv for reserving mobile device A is stored only in ledger A.

[0184] Next, for example, terminal A communicates with offline mobile device A and performs a lending process for mobile device A (S3A). That is, terminal A performs a lending process for locally lending mobile device A to offline mobile device A. More specifically, terminal A communicates with mobile device A and can transmit a request to unlock mobile device A in order to use mobile device A. Then, mobile device A unlocks mobile device A, and generates lending transaction data Trnt indicating the start of lending of mobile device A. In this case, for example, as shown in FIG. 15B, since mobile device A is offline, only ledger A stores a block including lending transaction data Trnt indicating the start of lending of mobile device A.

[0185] Next, for example, terminal A communicates with offline mobile device A and performs a return process for mobile device A (S5A). That is, terminal A performs a return process for locally returning mobile device A to offline mobile device A. More specifically, a user operating terminal A uses the unlocked mobile device A for the reserved usage time and then returns it. When mobile device A is returned, it generates return transaction data Trtn indicating the completion of the return of mobile device A. In this case, for example, as shown in FIG. 15C, since mobile device A is offline, only ledger A stores a block including return transaction data Trtn indicating the completion of the return of mobile device A.

[0186] Suppose that mobile device A subsequently returns to an online state. Then, when mobile device A returns to an online state, a recovery process is performed in the system (S6A). More specifically, in steps S1A to S5A, as described above, mobile device A is in an offline state where it cannot communicate with mobile device B. Therefore, as shown in FIG. 16(a), different blocks are linked to the blockchains of Ledger A and Ledger B when mobile device A returns to an online state. Next, when mobile device A returns to an online state, Ledger A of mobile device A and Ledger B of mobile device B share different blockchains, resulting in a fork, as shown in FIG. 16(b). Here, the blocks linked to the blockchain of Ledger A of offline mobile device A correspond to side chain blocks, and the blocks linked to the blockchain of Ledger B of online mobile device B correspond to main chain blocks. For this reason, as shown in (a) and (b) of Figure 17, in Ledger A of mobile device A and Ledger B of mobile device B, the side chain blocks are deleted and the transaction data included in the side chain blocks are stored in the transaction pool, thereby resolving the fork. Note that in (b) of Figure 17, the reservation transaction data Trsv, the lending transaction data Trnt, and the return transaction data Trtn are stored in the transaction pool. After that, as shown in (c) of Figure 17, in the blockchains of Ledger A of mobile device A and Ledger B of mobile device B, a block including the transaction data stored in the transaction pool is generated and linked when a new block is generated.

[0187] Next, the mobile device A etc. performs fee calculation processing (S7). The fee calculation processing in step S7 is as described above, and therefore a description thereof will be omitted.

[0188] Next, the details of the reservation process in step S1A, the rental process in step S3A, and the return process in S5A shown in Fig. 14, i.e., the detailed processes of local reservation, local rental, and local return, will be explained using sequence diagrams. In addition, the details of the process when communication is restored for mobile device A in step S6A shown in Fig. 14 will also be explained using sequence diagrams. In the following, it is assumed that a user who wants to use mobile device A uses terminal A to perform reservation process, rental process, and return process for mobile device A mounted on mobile device A.

[0189] [Reservation process according to the second example of the comparative example] 18 is a sequence diagram showing the reservation process of the system according to the second example of the comparative example, that is, the process of local reservation. The same elements as those in FIG. 10 are given the same reference numerals, and detailed description thereof will be omitted.

[0190] First, terminal A generates reservation transaction data Trsv for reserving use of mobile body A based on the operation of a user who wants to use mobile body A (S101), and transmits the generated reservation transaction data Trsv to mobile body device A (S102).

[0191] Next, when mobile device A receives the reservation transaction data Trsv transmitted in step S102, it attempts to transfer the reservation transaction data Trsv to other mobile devices, mobile devices B and C, but fails (S103A). This is because mobile device A is offline and cannot transfer the reservation transaction data Trsv to mobile devices B and C. As a result, mobile devices B and C do not obtain the reservation transaction data Trsv.

[0192] Next, the mobile device A executes a verification algorithm to verify the authenticity of the acquired reservation transaction data Trsv (S104). If the verification of the reservation transaction data Trsv is not successful, the reservation process is terminated.

[0193] Next, mobile device A stores the reservation transaction data Trsv verified by the verification algorithm executed in step S104 in transaction pool a (S105).

[0194] Next, mobile device A generates block Blc(Trsv) including the verified reservation transaction data Trsv (S107). Note that, since mobile device A is offline, it generates block Blc(Trsv) without exchanging information about transaction data to be stored in the next block to be generated with mobile devices B and C.

[0195] Next, mobile device A attempts to transmit the block Blc(Trsv) generated in step S107 to other mobile devices, mobile devices B and C, but fails (S108A) because mobile device A is offline and cannot transmit the block Blc(Trsv) to mobile devices B and C.

[0196] Next, mobile device A independently executes the consensus algorithm (S109A). Specifically, mobile device A independently agrees that the reservation transaction data Trsv is valid transaction data (i.e., validity), and independently agrees on the validity of block Blc(Trsv). In the example shown in FIG. 18, mobile device A independently agrees that the reservation transaction data Trsv included in block Blc(Trsv) is valid transaction data (i.e., validity), and thereby also agrees on the validity of block Blc(Trsv). Note that the processing of step S107 may be performed when independently executing the consensus algorithm in step S109A.

[0197] Next, mobile device A links the block Blc(Trsv) agreed upon in step S109A to the blockchain in ledger A (S110).

[0198] As a result, as shown in Fig. 15A, a block containing reservation transaction data Trsv for reserving use of mobile unit A is stored only in ledger A, and the reservation is confirmed. In the following, this self-contained confirmation of a reservation using only ledger A in an offline state will be referred to as a local reservation.

[0199] [Lending process according to the second example of the comparative example] 19 is a sequence diagram showing the lending process of the system according to the second example of the comparative example, that is, the local lending process. The same elements as those in FIG. 11 are given the same reference numerals, and detailed description thereof will be omitted.

[0200] First, terminal A transmits a request to unlock mobile body A to mobile device A based on an operation by a user who wishes to use mobile body A (S301).

[0201] Next, when mobile device A receives the unlock request sent in step S301, it checks whether there is a reservation corresponding to the unlock request in the blockchain of ledger A (S302), and unlocks mobile device A (S303).

[0202] Next, the mobile device A generates rental transaction data Trnt indicating the start of rental of the mobile device A, triggered by the unlocking of the mobile device A (S304).

[0203] Next, mobile device A attempts to transfer the lending transaction data Trnt to other mobile devices, mobile devices B and C, but fails (S305A). This is because mobile device A is offline and cannot transfer the lending transaction data Trnt to mobile devices B and C. As a result, mobile devices B and C do not obtain the lending transaction data Trnt.

[0204] Next, the mobile device A executes a verification algorithm to verify the validity of the lending transaction data Trnt (S306).

[0205] Next, mobile device A stores the lending transaction data Trnt verified by the verification algorithm executed in step S306 in transaction pool a (S307).

[0206] Next, mobile device A generates block Blc(Trnt) including the verified lending transaction data Trnt (S309). Note that, since mobile device A is offline, it generates block Blc(Trnt) without exchanging information on transaction data to be stored in the next block to be generated with mobile devices B and C.

[0207] Next, mobile device A attempts to transmit the block Blc(Trnt) generated in step S309 to other mobile devices, mobile devices B and C, but fails (S310A) because mobile device A is offline and cannot transmit the block Blc(Trnt) to mobile devices B and C.

[0208] Next, mobile device A independently executes the consensus algorithm (S311A). Specifically, mobile device A independently agrees that the lending transaction data Trnt is valid transaction data (i.e., validity), and independently agrees on the validity of block Blc(Trnt). In the example shown in FIG. 19, mobile device A independently agrees that the lending transaction data Trnt included in block Blc(Trnt) is valid transaction data (i.e., validity), and thereby also agrees on the validity of block Blc(Trnt). Note that the processing of step S309 may be performed when executing the consensus algorithm in step S311.

[0209] Next, mobile device A links the block Blc(Trnt) agreed upon in step S311A to the blockchain in ledger A (S312).

[0210] As a result, as shown in Figure 15B, a block containing the lending transaction data Trnt is stored only in ledger A, and the fact that lending of mobile entity A has begun is recorded. In this way, the fact that lending of mobile entity A has begun is recorded self-containedly only in ledger A in an offline state, and this will be referred to as local lending below.

[0211] [Return process according to the second example of the comparative example] Fig. 20 is a sequence diagram showing the return process of the system according to the second example of the comparative example. The same elements as in Fig. 12 are given the same reference numerals, and detailed description thereof will be omitted.

[0212] First, when the user who used the mobile object A returns the mobile object A, the mobile apparatus A confirms that the mobile object A has been returned (S501).

[0213] Next, the mobile device A, upon confirmation that the mobile device A has been returned, generates return transaction data Trtn indicating the completion of the return of the mobile device A (S502).

[0214] Next, mobile device A attempts to transfer the return transaction data Trtn to other mobile devices, mobile devices B and C, but fails (S503A). This is because mobile device A is offline and cannot transfer the return transaction data Trtn to mobile devices B and C. As a result, mobile devices B and C do not obtain the return transaction data Trtn.

[0215] Next, the mobile device A executes a verification algorithm to verify the authenticity of the acquired return transaction data Trtn (S504).

[0216] Next, mobile device A stores the return transaction data Trtn verified by the verification algorithm executed in step S504 in transaction pool a (S505).

[0217] Next, mobile device A generates block Blc(Trtn) including the verified return transaction data Trtn (S506). Note that, since mobile device A is offline, it generates block Blc(Trtn) without exchanging information about transaction data to be stored in the next block to be generated with mobile devices B and C.

[0218] Next, mobile device A attempts to transmit the block Blc(Trtn) generated in step S506 to other mobile devices, mobile devices B and C, but fails (S507A) because mobile device A is offline and cannot transmit the block Blc(Trtn) to mobile devices B and C.

[0219] Next, mobile device A independently executes the consensus algorithm (S508A). Specifically, mobile device A independently agrees that the return transaction data Trtn is valid transaction data (i.e., validity), and independently agrees on the validity of block Blc(Trtn). In the example shown in FIG. 20, mobile device A independently agrees that the return transaction data Trtn included in block Blc(Trtn) is valid transaction data (i.e., validity), and thereby also agrees on the validity of block Blc(Trtn). Note that the processing of step S506 may be performed when executing the consensus algorithm in step S508A.

[0220] Next, mobile device A links the block Blc(Trtn) agreed upon in step S508A to the blockchain in ledger A (S509). As a result, as shown in Fig. 15C, a block including the return transaction data Trtn is stored only in ledger A, and the completion of the return of mobile device A is recorded. This self-contained recording of the completion of the return of mobile device A only in ledger A in an offline state is hereinafter referred to as a local return.

[0221] Next, mobile device A checks the reservation information stored in the blockchain (S510). More specifically, mobile devices A, B, and C each execute the reservation smart contract by linking the return transaction data Trtn to the blockchain in their own ledgers, and confirm that the reservation transaction data Trsv exists as reservation information stored in the blockchain.

[0222] Then, mobile device A executes the fee calculation algorithm (S511).

[0223] [Processing when communication resumes in mobile device A according to a second example of the comparative example] Next, the process of step S6A shown in FIG. 14 when mobile apparatus A resumes communication will be described in detail.

[0224] FIG. 21 is a sequence diagram showing system processing performed when communication is restored for mobile device A according to the second example of the comparative example.

[0225] First, it is assumed that mobile device A has returned to being able to communicate (online state) with other mobile devices B and C (S601). Because mobile device A is mounted on mobile device A, it may be in an offline state or an online state depending on the location of mobile device A.

[0226] Mobile device A then transmits a signal to other mobile devices B and C (S602). The signal may be any signal that can notify that mobile device A has become online.

[0227] Next, mobile devices A, B, and C determine whether the blockchains in each ledger are the same or different (S603). More specifically, mobile device A determines whether the blockchain in ledger A is the same or different from the blockchains in ledgers B and C of other mobile devices, mobile devices B and C. Mobile devices B and C determine whether the blockchains in ledgers B and C are the same or different from the blockchain in ledger A of other mobile device, mobile device A. Here, as in the example shown in FIG. 16(a), different blocks are linked to the blockchains in ledger A and ledgers B and C, and the blockchain in ledger A is different from the blockchains in ledgers B and C. For this reason, as in the example shown in FIG. 16(b), mobile devices A, B, and C share different blockchains in ledgers A, B, and C, resulting in a fork.

[0228] Next, mobile devices A, B, and C exchange information about blocks that correspond to side chain blocks and main chain blocks (S604, S605). In this comparative example, the blocks linked to the blockchain of ledger A of mobile device A, which has been offline for a certain period of time, correspond to side chain blocks. The blocks linked to the blockchains of ledgers B and C of mobile devices B and C correspond to main chain blocks.

[0229] Next, mobile devices A, B, and C each store the transaction data Tpol of the side chain block obtained in step S604 in a transaction pool (S606). More specifically, mobile device A stores a copy of the transaction data Tpol of the side chain block linked to the blockchain of ledger A in transaction pool a. Mobile device B stores the transaction data Tpol of the side chain block in transaction pool b, and mobile device C stores the transaction data Tpol of the side chain block in transaction pool c.

[0230] Next, mobile devices A, B, and C update the blockchains of ledgers A, B, and C, respectively, to be identical to those of ledgers A, B, and C (S607). More specifically, mobile device A updates the blockchain of ledger A by deleting the side chain blocks that were linked to the blockchain of ledger A and leaving the main chain blocks, thereby making it identical to the blockchains of ledgers B and C. Mobile device B updates the blockchain of ledger B by deleting the side chain blocks that were linked to the blockchain of ledger B and leaving the main chain blocks, thereby making it identical to the blockchains of ledgers A and C. Mobile device C updates the blockchain of ledger C by deleting the side chain blocks that were linked to the blockchain of ledger C and leaving the main chain blocks, thereby making it identical to the blockchains of ledgers A and B.

[0231] Next, at the block generation timing after a predetermined time, mobile devices A, B, and C each generate a block Blc(Tpol) including the transaction data Tpol stored in the transaction pool (S614).

[0232] Next, each of the mobile devices A, B, and C transmits the block Blc(Tpol) generated in step S614 to the other mobile devices (S615).

[0233] Next, mobile devices A, B, and C jointly execute a consensus algorithm (S616). Specifically, mobile devices A, B, and C each agree that transaction data Tpol is valid transaction data (i.e., validity), and agree on the validity of block Blc(Tpol). In the example shown in FIG. 21, it is agreed that transaction data Tpol included in block Blc(Tpol) is valid transaction data (i.e., validity), and the validity of block Blc(Tpol) is also agreed on. Note that the processes of steps S614 and S615 may be performed when executing the consensus algorithm in step S616.

[0234] Next, mobile devices A, B, and C each link the agreed-upon block Blc (Tpol) in step S616 to the blockchain in the distributed ledger (S617). More specifically, mobile device A links the agreed-upon block Blc (Tpol) to the blockchain in ledger A, and mobile device B links the agreed-upon block Blc (Tpol) to the blockchain in ledger B. Mobile device C links the agreed-upon block Blc (Tpol) to the blockchain in ledger C. As a result, as shown in (c) of FIG. 17, a block including the reservation transaction data Trsv, lending transaction data Trnt, and return transaction data Trtn is stored, and the local reservation, local lending, and local return of mobile device A are recorded.

[0235] Next, mobile device A checks the reservation information stored in the blockchain (S620). More specifically, mobile devices A, B, and C each execute the reservation smart contract by linking the block containing the return transaction data Trtn to the blockchain in their own ledgers, and confirm that the reservation transaction data Trsv exists as reservation information stored in the blockchain.

[0236] Then, each of the mobile devices A, B, and C executes the fee calculation algorithm (S621). Note that the processing in step S621 is the same as the processing in step S511 described above, and therefore a description thereof will be omitted.

[0237] [Block Concatenation Processing According to Comparative Example] Next, a comparative example of a block linking process for linking blocks generated in a blockchain will be described.

[0238] 22 is a flowchart for explaining the block connection processing of a system according to a comparative example. In the following, a case where the block connection processing is performed by mobile body apparatus A will be explained as a representative.

[0239] First, when mobile device A acquires or generates transaction data (S1001), it executes a verification algorithm to verify the acquired or generated transaction data (S1002).

[0240] Next, mobile device A stores the transaction data verified by the verification algorithm executed in step S1002 in a transaction pool (S1003).

[0241] Next, mobile device A checks whether there is a trigger to link a block to the blockchain of ledger A (S1004). The trigger here is the lapse of a certain interval, such as several minutes.

[0242] If there is a trigger in step S1004 (Yes in S1004), mobile device A checks whether it can communicate with other mobile devices (S1005). If there is no trigger in step S1004 (No in S1004), the process repeats from step S1001.

[0243] In step S1005, if mobile device A cannot communicate with other mobile devices, i.e., if it is offline (No in S1005), mobile device A executes the consensus algorithm by itself (S1006). Mobile device A generates a blockchain block including the acquired or generated transaction data and executes the consensus algorithm to reach a consensus. Mobile device A may also verify the validity of the acquired or generated transaction data and generate a block including the transaction data.

[0244] Next, mobile device A links the generated block to the blockchain of ledger A (S1007).

[0245] On the other hand, in step S1005, if mobile device A can communicate with other mobile devices (Yes in S1005), mobile device A executes a consensus algorithm together with the other mobile devices (S1008). Mobile device A and the other mobile devices each generate a block of a blockchain including the transaction data, and reach consensus on the generated block by executing the consensus algorithm.

[0246] Next, mobile device A determines whether the blockchain of ledger A is the same as the blockchain in the ledger of another mobile device (S1009).

[0247] In step S1009, if the blocks are the same (Yes in S1009), mobile device A links the agreed-upon block to the blockchain of ledger A (S1010).

[0248] On the other hand, if they are not the same in step S1009 (No in S1009), the transaction data of the block that will become the side chain, i.e., the side chain block, is stored in the transaction pool (S1011).

[0249] Next, mobile device A updates the blockchain of ledger A so that it is the same as the blockchain in the ledger of the other mobile device (S1012).

[0250] Next, mobile device A links the block agreed upon in step S1009 to the blockchain of ledger A (S1013).

[0251] [Third Comparative Example] Next, we will explain fraudulent processing that exploits the blockchain mechanism to fraudulently use mobile object A. In the third example of the comparative example, we will explain a case where, when mobile object device A is offline, fraudulent reservation processing and normal rental processing are performed for mobile object A, and then mobile object device A is returned to the online state and return processing is performed.

[0252] FIG. 23 is a flowchart showing an outline of the operation of fraud processing in a system according to a third example of the comparative example. FIGS. 24A to 27 are diagrams conceptually illustrating blockchains stored in ledger A of mobile body device A and ledger B of mobile body device B. FIG. 24A is a diagram conceptually illustrating blockchain blocks stored in ledger A by the operation of step S10 in FIG. 23. FIG. 24B is a diagram conceptually illustrating blockchain blocks stored in ledger A by the operation of step S11 in FIG. 23. FIG. 24C is a diagram conceptually illustrating blockchain blocks stored in ledger A by the operation of step S12 in FIG. 23. FIGS. 25 and 26 are diagrams conceptually illustrating blockchain blocks stored in ledger A and ledger B by the operation of step S13 in FIG. 23. FIG. 27 is a diagram conceptually illustrating blockchain blocks stored in ledger A and ledger B by the operation of step S14 in FIG. 23. In the following, the following description will be given assuming that a user who wishes to use mobile body A uses terminal A to perform fraud processing on mobile body device A mounted on mobile body A.

[0253] As shown in Fig. 23, first, for example, terminal A performs a reservation process for mobile body A on which mobile body A is mounted, for offline mobile body device A (S10). Here, as described above, terminal A performs a reservation process for locally reserving mobile body A for offline mobile body device A. More specifically, terminal A can communicate with mobile body device A, generate reservation transaction data TrsvA for reserving the use of mobile body A, and transmit it to mobile body device A. In this case, for example, as shown in Fig. 24A, since mobile body device A is offline, only ledger A stores a block including reservation transaction data TrsvA for reserving the use of mobile body A.

[0254] Next, using some means such as terminal A or the user's personal smartphone, a reservation process for mobile unit A is performed for online mobile unit B so that the time slot for the local reservation of mobile unit A made in step S10 overlaps with the time slot for the local reservation of mobile unit A (S11). In other words, a competitive reservation process for mobile unit A is performed for online mobile unit B so that the local reservation of mobile unit A competes with the local reservation of mobile unit A. In this comparative example, the user uses terminal A to generate reservation transaction data TrsvB for competitively reserving mobile unit A and transmits it to online mobile unit B. In this case, for example, as shown in FIG. 24B , mobile unit B stores a block including reservation transaction data TrsvB for competitively reserving mobile unit A in ledger B, etc., excluding ledger A for offline mobile unit A.

[0255] Next, for example, terminal A communicates with offline mobile device A and performs lending processing for mobile device A (S12). That is, as described above, terminal A performs lending processing to locally lend mobile device A to offline mobile device A. More specifically, terminal A communicates with mobile device A and transmits a request to unlock mobile device A in order to use mobile device A, thereby causing mobile device A to unlock mobile device A and triggering the generation of lending transaction data TrntA indicating the start of lending of mobile device A. In this case, for example, as shown in FIG. 24C , since mobile device A is offline, only ledger A stores a block including lending transaction data TrntA indicating the start of lending of mobile device A.

[0256] Next, the user returns mobile device A to the online state. When mobile device A returns to the online state, the system performs a return process (S13).

[0257] More specifically, in steps S10 to S12, as described above, mobile device A is in an offline state, and therefore, when mobile device A returns to an online state, different blocks are linked to the blockchains of Ledger A and Ledger B, as shown in (a) of FIG. 25. Next, when mobile device A returns to an online state, Ledger A of mobile device A and Ledger B of mobile device B share different blockchains, resulting in a fork, as shown in (b) of FIG. 25. Here, the blocks linked to the blockchain of Ledger A of offline mobile device A correspond to side chain blocks, and the blocks linked to the blockchain of Ledger B of online mobile device B correspond to main chain blocks. Therefore, as shown in (a) and (b) of FIG. 26, side chain blocks are deleted from Ledger A of mobile device A and Ledger B of mobile device B, and the transaction data included in the side chain blocks is stored in the transaction pool, thereby resolving the fork. In (b) of Figure 26, the reservation transaction data TrsvA and the lending transaction data TrntA are stored in the transaction pool. After that, as shown in (c) of Figure 26, in the blockchains of ledger A of mobile device A and ledger B of mobile device B, a block including the transaction data stored in the transaction pool is generated and linked at the timing of generating a new block.

[0258] Next, for example, terminal A communicates with mobile device A, which is online, and performs a process for returning mobile device A (S14). More specifically, the user who operates terminal A uses the unlocked mobile device A for the reserved time and then returns it. When mobile device A is returned, mobile device A generates return transaction data TrtnA indicating the completion of the return of mobile device A. In this case, for example, as shown in FIG. 27, since mobile device A is online, a block including return transaction data TrtnA indicating the completion of the return of mobile device A is stored in all of ledgers A, B, etc.

[0259] Next, mobile device A or the like performs a fee calculation process (S15). The fee calculation process in step S15 is the same as the fee calculation process in step S7, so a description thereof will be omitted. There is a conflict between the reservation transaction data TrsvA and the reservation transaction data TrsvB, and the block containing the reservation transaction data TrsvA is linked chronologically after the block containing the reservation transaction data TrsvB. As a result, no fee is collected for the reservation corresponding to the reservation transaction data TrsvA, resulting in fraudulent refusal to pay the fee for using mobile device A for the reservation corresponding to the reservation transaction data TrsvA.

[0260] Next, the details of the local reservation process in step S10, the competing reservation process in step S11, and the local lending process in step S12 shown in FIG. 23 will be described with reference to a sequence diagram.

[0261] [Reservation process according to the third example of the comparative example] 28 is a sequence diagram showing the process of making a local reservation in a system according to a third example of the comparative example. The same elements as those in FIG. 18 are given the same reference numerals, and detailed description thereof will be omitted.

[0262] First, terminal A generates reservation transaction data TrsvA for reserving use of mobile body A based on the operation of a user who wants to use mobile body A (S101B), and transmits the generated reservation transaction data TrsvA to mobile body device A (S102B).

[0263] Next, when mobile device A receives the reservation transaction data TrsvA transmitted in step S102B, it attempts to transfer the reservation transaction data TrsvA to other mobile devices, mobile devices B and C, but fails (S103B) because mobile device A is offline and therefore cannot transfer the reservation transaction data TrsvA to mobile devices B and C.

[0264] Next, mobile device A executes a verification algorithm to verify the authenticity of the acquired reservation transaction data TrsvA (S104B).

[0265] Next, mobile device A stores reservation transaction data TrsvA verified by the verification algorithm executed in step S104B in transaction pool a (S105B).

[0266] Next, mobile device A generates a block Blc(TrsvA) including the verified reservation transaction data TrsvA (S107B).

[0267] Next, mobile device A attempts to transmit block Blc(TrsvA) generated in step S107B to other mobile devices, mobile devices B and C, but fails (S108B) because mobile device A is offline and cannot transmit block Blc(TrsvA) to mobile devices B and C.

[0268] Next, mobile device A independently executes the consensus algorithm (S109B). Note that the process of step S107B may be performed when mobile device A independently executes the consensus algorithm in step S109B.

[0269] Next, mobile device A links the block Blc(TrsvA) agreed upon in step S109B to the blockchain in ledger A (S110B).

[0270] As a result, as shown in FIG. 24A, only ledger A stores a block including reservation transaction data TrsvA for reserving use of mobile unit A, and the local reservation is confirmed.

[0271] FIG. 29 is a sequence diagram showing a process for making a competitive reservation in a system according to a third example of the comparative example.

[0272] First, the user uses, for example, terminal A to generate reservation transaction data TrsvB for making a contention reservation for mobile unit A (S101C).

[0273] Next, the user uses, for example, terminal A to transmit the reservation transaction data TrsvB generated in step S101C to mobile device B (S102C).

[0274] Next, since mobile device B is online, upon receiving the reservation transaction data TrsvB transmitted in step S102C, it transfers the reservation transaction data TrsvB to another mobile device, mobile device C (S103C). As a result, mobile device C, excluding mobile device A, acquires the reservation transaction data TrsvB.

[0275] Next, each of the mobile devices B and C executes a verification algorithm to verify the authenticity of the acquired reservation transaction data TrsvB (S104C).

[0276] Next, mobile devices B and C each store the reservation transaction data TrsvB verified by the verification algorithm executed in step S104C in a transaction pool (S105C). More specifically, mobile device B stores the verified reservation transaction data TrsvB in transaction pool b, and mobile device C stores the verified reservation transaction data TrsvB in transaction pool c.

[0277] Next, since mobile devices B and C are able to communicate with each other, they exchange information about transaction data to be stored in the next block to be generated (S106C). In the example shown in Fig. 29, mobile devices B and C confirm that the transaction data to be stored in the next block to be generated includes verified reserved transaction data TrsvB.

[0278] Next, mobile devices B and C each generate a block Blc(TrsvB) including the verified reservation transaction data TrsvB (S107C).

[0279] Next, mobile devices B and C each transmit (S108C) the block Blc(TrsvB) generated in step S107C to the other mobile devices except for mobile device A. This allows mobile devices B and C to each notify the other mobile devices except for mobile device A of successful verification of the validity of the reservation transaction data TrsvB included in block Blc(TrsvB).

[0280] Next, mobile devices B and C jointly execute a consensus algorithm (S109C). Specifically, based on the report notified in step S108C, mobile devices B and C each agree that the reservation transaction data TrsvB is valid transaction data (i.e., validity), and agree on the validity of block Blc(TrsvB). Note that the processes of steps S107C and S108C may be performed when executing the consensus algorithm in step S109C.

[0281] Next, mobile devices B and C each link the agreed-upon block Blc (TrsvB) in step S109C to the blockchain in the distributed ledger (S110C). More specifically, mobile device B links the agreed-upon block Blc (TrsvB) to the blockchain in ledger B, and mobile device C links the agreed-upon block Blc (TrsvB) to the blockchain in ledger C.

[0282] As a result, as shown in FIG. 24B, a block including reservation transaction data TrsvB is stored in both ledger B and ledger C.

[0283] [Lending process according to the third example of the comparative example] 30 is a sequence diagram showing the local lending process of the system according to the third example of the comparative example. The same elements as those in FIG. 19 are given the same reference numerals, and detailed description thereof will be omitted.

[0284] First, terminal A transmits a request to unlock mobile body A to mobile device A based on an operation by a user who uses mobile body A (S301B).

[0285] Next, when mobile device A receives the unlock request sent in step S301B, it checks whether there is a reservation corresponding to the unlock request in the blockchain of ledger A (S302B), and unlocks mobile device A (S303B).

[0286] Next, the mobile device A generates rental transaction data TrntA indicating the start of rental of the mobile device A, triggered by the unlocking of the mobile device A (S304B).

[0287] Next, mobile device A attempts to transfer the lending transaction data TrntA to other mobile devices, mobile devices B and C, but fails (S305B). This is because mobile device A is offline and cannot transfer the lending transaction data TrntA to mobile devices B and C.

[0288] Next, the mobile device A executes a verification algorithm to verify the validity of the lending transaction data TrntA (S306B).

[0289] Next, mobile device A stores the lending transaction data TrntA verified by the verification algorithm executed in step S306B in transaction pool a (S307B).

[0290] Next, each mobile device A generates a block Blc(TrntA) including the verified lending transaction data TrntA (S309B).

[0291] Next, mobile device A attempts to transmit block Blc(TrntA) generated in step S309B to other mobile devices, mobile devices B and C, but fails (S310B) because mobile device A is offline and cannot transmit block Blc(TrntA) to mobile devices B and C.

[0292] Next, mobile device A independently executes the consensus algorithm (S311B). Specifically, mobile device A independently agrees that the lending transaction data TrntA is valid transaction data (i.e., validity), and independently agrees on the validity of block Blc(TrntA). Note that the processing of step S309B may be performed when executing the consensus algorithm in step S311B.

[0293] Next, mobile device A links the block Blc(TrntA) agreed upon in step S311B to the blockchain in ledger A (S312B).

[0294] As a result, as shown in FIG. 24C, a block including lending transaction data TrntA is stored only in ledger A, and it is recorded that local lending of mobile unit A has been carried out.

[0295] [Processing when communication resumes in mobile device A according to a third example of the comparative example] Next, the process of step S13 shown in FIG. 23 when mobile apparatus A resumes communication will be described in detail.

[0296] 31 is a sequence diagram showing system processing performed when communication is restored for mobile device A according to a third example of the comparative example. Elements similar to those in FIG. 21 are assigned the same reference numerals, and detailed description thereof will be omitted.

[0297] First, it is assumed that mobile device A has returned to a state where it can communicate with other mobile devices B and C (online state) (S601B).

[0298] Mobile device A then transmits a signal to other mobile devices B and C indicating that mobile device A has gone online (S602B).

[0299] Next, mobile devices A, B, and C determine whether the blockchains in each ledger are the same or different (S603B). More specifically, mobile device A determines whether the blockchain in ledger A is the same or different from the blockchains in ledgers B and C of other mobile devices, mobile devices B and C. Mobile devices B and C determine whether the blockchains in ledgers B and C are the same or different from the blockchain in ledger A of other mobile device, mobile device A. Here, as in the example shown in FIG. 25(a), different blocks are linked to the blockchains in ledger A and ledgers B and C, and the blockchain in ledger A is different from the blockchains in ledgers B and C. For this reason, as in the example shown in FIG. 25(b), mobile devices A, B, and C share different blockchains in ledgers A, B, and C, resulting in a fork.

[0300] Next, mobile devices A, B, and C exchange information about blocks corresponding to side chain blocks and main chain blocks (S604B, S605B). In this comparative example, the block linked to the blockchain of ledger A of mobile device A, which has been offline for a certain period of time, corresponds to side chain block Blc (TrsvA, TrntA). The block linked to the blockchain of ledgers B and C of mobile devices B and C corresponds to main chain block Blc (TrsvB).

[0301] Next, mobile devices A, B, and C each store the reservation transaction data TrsvA and lending transaction data TrntA included in the side chain block obtained in step S604B in a transaction pool (S606B). More specifically, mobile device A stores copies of the transaction data TrsvA and TrntA of the side chain block linked to the blockchain of ledger A in transaction pool a. Mobile device B stores the transaction data TrsvA and TrntA of the side chain block in transaction pool b, and mobile device C stores the transaction data TrsvA and TrntA of the side chain block in transaction pool c.

[0302] Next, mobile devices A, B, and C update the blockchains of ledgers A, B, and C, respectively, to be identical to those of ledgers A, B, and C (S607B). More specifically, mobile device A updates the blockchain of ledger A by deleting the side chain blocks that were linked to the blockchain of ledger A and leaving the main chain blocks, thereby making it identical to the blockchains of ledgers B and C. Mobile device B updates the blockchain of ledger B by deleting the side chain blocks that were linked to the blockchain of ledger B and leaving the main chain blocks, thereby making it identical to the blockchains of ledgers A and C. Mobile device C updates the blockchain of ledger C by deleting the side chain blocks that were linked to the blockchain of ledger C and leaving the main chain blocks, thereby making it identical to the blockchains of ledgers A and B.

[0303] Next, at the block generation timing after a predetermined time, mobile devices A, B, and C each generate a block Blc(TrsvA, TrntA) including the transaction data TrsvA and TrntA stored in the transaction pool (S614B).

[0304] Next, mobile devices A, B, and C each transmit block Blc(TrsvA, TrntA) generated in step S614B to the other mobile devices (S615B). This allows mobile devices A, B, and C to each notify the other mobile devices that the validity of transaction data TrsvA and TrntA included in block Blc(TrsvA, TrntA) has been successfully verified.

[0305] Next, mobile devices A, B, and C jointly execute a consensus algorithm (S616B). Specifically, based on the report notified in step S615B, mobile devices A, B, and C each agree that the transaction data TrsvA and TrntA are valid transaction data (i.e., validity), and agree on the validity of block Blc(TrsvA, TrntA). Note that the processes of steps S614B and S615B may be performed when executing the consensus algorithm in step S616B.

[0306] Next, mobile devices A, B, and C each link the agreed-upon block Blc (TrsvA, TrntA) in step S616B to the blockchain in the distributed ledger (S617B). More specifically, mobile device A links the agreed-upon block Blc (TrsvA, TrntA) to the blockchain in ledger A, and mobile device B links the agreed-upon block Blc (TrsvA, TrntA) to the blockchain in ledger B. Mobile device C links the agreed-upon block Blc (TrsvA, TrntA) to the blockchain in ledger C. As a result, as shown in (c) of FIG. 26, a block including reservation transaction data TrsvA, reservation transaction data TrsvB, and lending transaction data TrntA is stored, and mobile device A's local reservation, competing reservation, and local lending are recorded.

[0307] [Return process according to the third example of the comparative example] Next, the return process of the mobile apparatus A in step S14 shown in FIG. 23 will be described in detail.

[0308] 32 is a sequence diagram showing the return process of the system according to the third example of the comparative example. The same elements as those in FIG. 12 are given the same reference numerals, and detailed description thereof will be omitted.

[0309] First, when the user who used the moving object A returns the moving object A, the moving object device A confirms that the moving object A has been returned (S501B).

[0310] Next, the mobile device A, upon confirmation that the mobile device A has been returned, generates return transaction data TrtnA indicating the completion of the return of the mobile device A (S502B).

[0311] Next, mobile device A transfers the return transaction data TrtnA to other mobile devices B and C (S503B). As a result, mobile devices B and C acquire the return transaction data TrtnA.

[0312] Next, each of the mobile devices A, B, and C executes a verification algorithm to verify the authenticity of the acquired return transaction data TrtnA (S504B).

[0313] Next, mobile devices A, B, and C each store the verified return transaction data TrtnA in a transaction pool using the verification algorithm executed in step S504B (S505B). More specifically, mobile device A stores the verified return transaction data TrtnA in transaction pool a, and mobile device B stores the verified return transaction data TrtnA in transaction pool b. Mobile device C stores the verified return transaction data TrtnA in transaction pool c. Although not shown, mobile devices A, B, and C are able to communicate with each other, and therefore exchange information about transaction data to be stored in the next block to be generated. In the example shown in FIG. 32, mobile devices A, B, and C confirm that the verified return transaction data TrtnA is included in the transaction data to be stored in the next block to be generated.

[0314] Next, each of the mobile devices A, B, and C generates a block Blc(TrtnA) including the verified return transaction data TrtnA (S506B).

[0315] Next, mobile devices A, B, and C each transmit the block Blc(TrtnA) generated in step S506B to the other mobile devices (S507B). This allows mobile devices A, B, and C to each notify the other mobile devices that the validity of the return transaction data TrtnA included in block Blc(TrtnA) has been successfully verified.

[0316] Next, mobile devices A, B, and C jointly execute a consensus algorithm (S508B). Specifically, based on the report notified in step S507B, mobile devices A, B, and C each agree that the returned transaction data TrtnA is valid transaction data (i.e., validity), and agree on the validity of block Blc(TrtnA). Note that the processes of steps S506B and S507B may be performed when executing the consensus algorithm in step S508B.

[0317] Next, mobile devices A, B, and C each link the agreed-upon block Blc (TrntA) in step S508B to the blockchain in the distributed ledger (S509B). More specifically, mobile device A links the agreed-upon block Blc (TrtnA) to the blockchain in ledger A, and mobile device B links the agreed-upon block Blc (TrtnA) to the blockchain in ledger B. Mobile device C links the agreed-upon block Blc (TrtnA) to the blockchain in ledger C. As a result, as shown in FIG. 27, ledgers A, B, and C all store a block including return transaction data TrtnA, and the completion of the return by mobile device A is recorded.

[0318] Next, mobile devices A, B, and C each check the reservation information stored in the blockchain (S510B). More specifically, mobile devices A, B, and C each execute the reservation smart contract by linking a block including the block containing the return transaction data TrtnA to the blockchain in their own ledgers, and confirm that the reservation transaction data Trsv exists as reservation information stored in the blockchain.

[0319] Next, mobile devices A, B, and C each execute a fee calculation algorithm (S511B). Here, for example, as shown in Fig. 27, there is a conflict between reservation transaction data TrsvA and reservation transaction data TrsvB, and the block including reservation transaction data TrsvA is linked chronologically after the block including reservation transaction data TrsvB. Therefore, even if the fee calculation algorithm is executed, the fee for the reservation corresponding to reservation transaction data TrsvA will not be collected, and only the fee for the reservation corresponding to reservation transaction data TrsvB will be collected.

[0320] In this way, the fee for the reservation corresponding to the reservation transaction data TrsvA is not collected, and therefore, fraud occurs in which the fee for using mobile unit A in the reservation corresponding to the reservation transaction data TrsvA is not paid.

[0321] [Fourth Comparative Example] In the third comparative example, fraudulent processing was described when returning mobile device A to an online state and then performing the return process, but this is not limited to this. If mobile device A is offline, mobile device A may be returned to an online state after performing the return process. Fraudulent processing in this case will be described below as a fourth comparative example.

[0322] FIG. 33 is a flowchart showing an outline of the operation of fraud processing in a system according to a fourth example of the comparative example. FIGS. 34A to 36 are diagrams conceptually illustrating blockchains stored in ledger A of mobile body device A and ledger B of mobile body device B. FIG. 34A is a diagram conceptually illustrating blockchain blocks stored in ledger A by the operation of step S10 in FIG. 33. FIG. 34B is a diagram conceptually illustrating blockchain blocks stored in ledger A by the operation of step S11 in FIG. 33. FIG. 34C is a diagram conceptually illustrating blockchain blocks stored in ledger A by the operation of step S12 in FIG. 33. FIG. 34D is a diagram conceptually illustrating blockchain blocks stored in ledger A by the operation of step S13A in FIG. 33. FIGS. 35 and 36 are diagrams conceptually illustrating blockchain blocks stored in ledger A and ledger B by the operation of step S14A in FIG. 33. In the following description, it is assumed that a user who wants to use mobile body A uses terminal A to perform fraud processing on mobile body device A mounted on mobile body A.

[0323] Steps S10 to S12 shown in Fig. 33 are the same processes as steps S10 to S12 described in Fig. 23, and therefore their explanation will be omitted. Also, Figs. 34A to 34C are the same as Figs. 24A to 24C, and therefore their explanation will be omitted.

[0324] Next, in step S13A, for example, terminal A communicates with offline mobile device A and performs a return process for mobile device A. That is, terminal A performs a return process for locally returning mobile device A to offline mobile device A. More specifically, a user operating terminal A uses the unlocked mobile device A for the reserved usage time and then returns it. When mobile device A is returned, it generates return transaction data TrtnA indicating the completion of the return of mobile device A. In this case, for example, as shown in FIG. 34D, since mobile device A is offline, only ledger A stores a block including return transaction data TrtnA indicating the completion of the return of mobile device A.

[0325] Next, suppose the user returns mobile device A to an online state. Then, when mobile device A returns to an online state, the system performs a restoration process (S14A). More specifically, because mobile device A is offline in steps S10 to S13A, when mobile device A returns to an online state, different blocks are linked to the blockchains of Ledger A and Ledger B, as shown in FIG. 34D, for example. Next, when mobile device A returns to an online state, Ledger A of mobile device A and Ledger B of mobile device B share different blockchains, resulting in a fork, as shown in FIG. 35. Here, the block linked to the blockchain of Ledger A of offline mobile device A is shorter and therefore corresponds to a side chain block, while the block linked to the blockchain of Ledger B of online mobile device B is longer and therefore corresponds to a main chain block. For this reason, as shown in (a) and (b) of Figure 36, in Ledger A of mobile device A and Ledger B of mobile device B, the side chain block is deleted and the transaction data included in the side chain block is stored in the transaction pool, thereby resolving the fork. Note that in (b) of Figure 36, the reservation transaction data TrsvA, the lending transaction data TrntA, and the return transaction data TrtnA are stored in the transaction pool. Thereafter, as shown in (c) of Figure 36, in the blockchains of Ledger A of mobile device A and Ledger B of mobile device B, a block including the transaction data stored in the transaction pool is generated and linked when a new block is generated.

[0326] Next, the mobile device A or the like performs a fee calculation process (S15). As in the third example of the comparative example, there is a conflict between the reservation transaction data TrsvA and the reservation transaction data TrsvB, and the block including the reservation transaction data TrsvA is linked after the block including the reservation transaction data TrsvB. As a result, the fee for the reservation corresponding to the reservation transaction data TrsvA is not collected, resulting in fraud in which the fee for using mobile device A for the reservation corresponding to the reservation transaction data TrsvA is not paid.

[0327] Next, the local return process in step S13A and the process when mobile apparatus A resumes communication in step S14A shown in FIG. 33 will be described in detail with reference to a sequence diagram.

[0328] [Return process according to the fourth example of the comparative example] 37 is a sequence diagram showing the local return process of the system according to the fourth example of the comparative example. The same elements as those in FIG. 20 are assigned the same reference numerals, and detailed description thereof will be omitted.

[0329] First, when the user who used the moving object A returns the moving object A, the moving object device A confirms that the moving object A has been returned (S501C).

[0330] Next, the mobile device A, upon confirmation that the mobile device A has been returned, generates return transaction data TrtnA indicating the completion of the return of the mobile device A (S502C).

[0331] Next, mobile device A attempts to transfer the return transaction data TrtnA to other mobile devices B and C, but fails (S503C). This is because mobile device A is offline and cannot transfer the return transaction data TrtnA to mobile devices B and C.

[0332] Next, mobile device A executes a verification algorithm to verify the authenticity of the acquired return transaction data TrtnA (S504C).

[0333] Next, mobile device A stores the return transaction data TrtnA verified by the verification algorithm executed in step S504C in transaction pool a (S505C).

[0334] Next, mobile device A generates a block Blc(TrtnA) including the verified return transaction data TrtnA (S506C).

[0335] Next, mobile device A attempts to transmit block Blc(TrtnA) generated in step S506C to other mobile devices, mobile devices B and C, but fails (S507C) because mobile device A is offline and cannot transmit block Blc(TrtnA) to mobile devices B and C.

[0336] Next, mobile device A independently executes the consensus algorithm (S508C). Specifically, mobile device A independently agrees that the returned transaction data TrtnA is valid transaction data (i.e., validity), and independently agrees on the validity of block Blc(TrtnA). Note that the processing of step S506C may be performed when executing the consensus algorithm in step S508C.

[0337] Next, mobile device A links the block Blc(TrtnA) agreed upon in step S508C to the blockchain in ledger A (S509C). As a result, as shown in FIG. 34D, a block including the return transaction data TrtnA is stored only in ledger A, and the local return of mobile device A is recorded.

[0338] Next, mobile device A checks the reservation information stored in the blockchain (S510C). More specifically, mobile devices A, B, and C each execute the reservation smart contract by linking the return transaction data TrtnA to the blockchain in their own ledgers, and confirm that the reservation transaction data TrsvA exists as reservation information stored in the blockchain.

[0339] Then, each mobile device A executes the fee calculation algorithm (S511C). Because mobile device A is offline, the fee calculation algorithm calculates the fee for the reservation corresponding to the reservation transaction data TrsvA.

[0340] [Processing when communication is restored by mobile device A according to a fourth example of the comparative example] Next, the process of step S14A shown in FIG. 33 when mobile apparatus A resumes communication will be described in detail.

[0341] 38 is a sequence diagram showing system processing performed when communication is restored for mobile device A according to a fourth example of the comparative example. Elements similar to those in FIG. 21 are assigned the same reference numerals, and detailed description thereof will be omitted.

[0342] First, it is assumed that mobile device A has returned to a state where it can communicate with other mobile devices B and C (online state) (S601C).

[0343] Mobile device A then transmits a signal to other mobile devices B and C indicating that mobile device A has gone online (S602C).

[0344] Next, mobile devices A, B, and C determine whether the blockchains in each ledger are the same or different (S603C). Before mobile device A resumes communication, different blocks are linked to the blockchains of ledger A and ledgers B and C, as shown in the example of FIG. 34D, for example, and therefore the blockchain in ledger A is different from the blockchains in ledgers B and C. Therefore, when mobile device A resumes communication, a fork occurs because ledgers A, B, and C of mobile devices A, B, and C share different blockchains, as shown in the example of FIG. 35, for example.

[0345] Next, mobile devices A, B, and C exchange information about blocks corresponding to side chain blocks and main chain blocks (S604C, S605C). In this comparative example, the blocks linked to the blockchain of ledger A of mobile device A, which has been offline for a certain period of time, correspond to side chain blocks Blc (TrsvA, TrntA, TrtnA). On the other hand, the blocks linked to the blockchains of ledgers B and C of mobile devices B and C correspond to main chain block Blc (TrsvB).

[0346] Next, mobile devices A, B, and C each store the transaction data TrsvA, TrntA, and TrtnA of the side chain block obtained in step S604C in a transaction pool (S606C).

[0347] Next, mobile devices A, B, and C update the blockchain of ledger A to be identical to the blockchain of ledgers A, B, and C, respectively (S607C). More specifically, mobile devices A, B, and C update the blockchain of ledger A to be identical to the blockchain of ledgers A, B, and C, respectively, by deleting the side chain blocks that were linked to the blockchain and leaving the main chain blocks.

[0348] Next, at the block generation timing after a predetermined time, mobile devices A, B, and C each generate block Blc(TrsvA, TrntA, TrtnA) including the transaction data TrsvA, TrntA, and TrtnA stored in the transaction pool (S614C).

[0349] Next, mobile devices A, B, and C each transmit block Blc (TrsvA, TrntA, TrtnA) generated in step S614C to the other mobile devices (S615C). This allows mobile devices A, B, and C to each notify the other mobile devices that the validity of the transaction data TrsvA, TrntA, and TrtnA included in block Blc (TrsvA, TrntA, TrtnA) has been successfully verified.

[0350] Next, mobile devices A, B, and C jointly execute a consensus algorithm (S616C). Specifically, based on the report notified in step S615C, mobile devices A, B, and C each agree that the transaction data TrsvA, TrntA, and TrtnA are valid transaction data (i.e., validity). Then, they agree on the validity of block Blc (TrsvA, TrntA, TrtnA). Note that the processes of steps S614C and S615C may be performed when executing the consensus algorithm in step S616C.

[0351] Next, mobile devices A, B, and C each link the agreed-upon block Blc (TrsvA, TrntA, TrtnA) in step S616 to the blockchain in the distributed ledger (S617C). More specifically, mobile device A links the agreed-upon block Blc (TrsvA, TrntA, TrtnA) to the blockchain in ledger A, and mobile device B links the agreed-upon block Blc (TrsvA, TrntA, TrtnA) to the blockchain in ledger B. Mobile device C links the agreed-upon block Blc (TrsvA, TrntA, TrtnA) to the blockchain in ledger C. As a result, as shown in (c) of FIG. 36, a block including the reservation transaction data TrsvA, lending transaction data TrntA, and return transaction data TrtnA is stored, and the local reservation, local lending, and local return of mobile device A are recorded.

[0352] Next, mobile device A checks the reservation information stored in the blockchain (S620C). More specifically, mobile devices A, B, and C each execute the reservation smart contract by linking the block including the return transaction data TrtnA to the blockchain in their own ledgers, and confirm that the reservation transaction data TrsvA and TrsvB are present as reservation information stored in the blockchain.

[0353] Then, mobile devices A, B, and C do not execute the fee calculation algorithm (S621C). More specifically, mobile devices A, B, and C execute the fee calculation algorithm, but do not collect the fee for the reservation corresponding to the reservation transaction data TrsvA. Note that the processing of step S621C is the same as the processing of step S511B described above, and therefore description thereof will be omitted.

[0354] 36(c), for example, a conflict exists between the reservation corresponding to the reservation transaction data TrsvA and the reservation corresponding to the reservation transaction data TrsvB. Also, the block containing the reservation transaction data TrsvA is linked after the block containing the reservation transaction data TrsvB. Therefore, even if the fee calculation algorithm is executed, the fee for the reservation corresponding to the reservation transaction data TrsvA will not be collected, and only the fee for the reservation corresponding to the reservation transaction data TrsvB will be collected.

[0355] In this way, the fee for the reservation corresponding to the reservation transaction data TrsvA is not collected, and therefore, fraud occurs in which the fee for using mobile unit A in the reservation corresponding to the reservation transaction data TrsvA is not paid.

[0356] [Processing after fraud prevention measures according to this embodiment] Next, a fraud prevention process according to this embodiment, which takes measures against fraudulent processing, will be described.

[0357] In the fraudulent processing shown in FIGS. 23 and 33, a competing reservation was made in step S11, and therefore the fee for the local reservation processed in step S10 was not collected.

[0358] Therefore, in this embodiment, even if a competing reservation is made in step S11, in order to ensure that a fee is collected for the local reservation booked in step S10, when mobile unit A is unlocked in step S12 in Figures 23 and 33, unlocking completion transaction data indicating that unlocking of mobile unit A has been completed is generated and stored in the blockchain of offline ledger A. Then, even if a fee for the local reservation booked in step S10 cannot be collected using the method of the comparative example because a competing reservation is made in step S11, the unlocking completion transaction data is used to collect the fee for using mobile unit A with the local reservation. This is because even if there is a competing reservation and a local reservation and it appears that duplicate fees are being collected, the existence of the unlocking completion transaction data in the blockchain indicates that mobile unit A was indeed used with the local reservation, for which fees would not have been collected using the method of the comparative example.

[0359] The following describes the process of generating unlocking transaction data as an anti-fraud process.

[0360] Figure 39 is a sequence diagram showing the local lending process of the system according to the embodiment. Elements similar to those in Figure 30 are given the same reference numerals, and detailed explanations will be omitted. Figure 40 is a conceptual diagram showing the blockchain blocks stored in ledger A by the local lending process of Figure 39.

[0361] First, terminal A transmits a request to unlock mobile body A to mobile device A based on an operation by a user who uses mobile body A (S301D).

[0362] Next, when mobile device A receives the unlock request sent in step S301D, it checks whether there is a reservation corresponding to the unlock request in the blockchain of ledger A (S302D), and unlocks mobile device A (S303D).

[0363] Next, triggered by the unlocking of mobile body A, mobile body device A generates unlocking completion transaction data Tunl indicating that unlocking of mobile body A has been completed (S3031). This unlocking completion transaction data Tunl includes at least the user ID who unlocked mobile body A, the device ID of mobile body device A that unlocked mobile body A, the corresponding reservation ID, and the date and time of unlocking. Note that instead of the user ID and device ID, a blockchain ID that can identify the user ID and device ID may be used. Also, instead of the corresponding reservation ID, a reservation transaction data ID that can identify reservation transaction data including the reservation ID may be used.

[0364] Next, mobile device A attempts to transfer the unlocking completion transaction data Tunl to other mobile devices B and C, but fails (S3032). This is because mobile device A is offline and cannot transfer the lending transaction data Tunl to mobile devices B and C.

[0365] Furthermore, the mobile body device A generates rental transaction data TrntA indicating the start of rental of the mobile body A, triggered by the unlocking of the mobile body A (S304D).

[0366] Next, mobile device A attempts to transfer the lending transaction data TrntA to other mobile devices, mobile devices B and C, but fails (S305D). This is because mobile device A is offline and cannot transfer the lending transaction data TrntA to mobile devices B and C.

[0367] Next, mobile device A executes a verification algorithm to verify the validity of the unlocking completion transaction data Tunl and the lending transaction data TrntA, that is, the transaction data Tunl and TrntA (S306D).

[0368] Next, mobile device A stores the transaction data Tunl and TrntA verified by the verification algorithm executed in step S306D in transaction pool a (S307D).

[0369] Next, each mobile device A generates a block Blc(Tunl, TrntA) including the verified transaction data Tunl, TrntA (S309D).

[0370] Next, mobile device A attempts to transmit the block Blc(Tunl, TrntA) generated in step S309D to other mobile devices, mobile devices B and C, but fails (S310D) because mobile device A is offline and cannot transmit the block Blc(Tunl, TrntA) to mobile devices B and C.

[0371] Next, mobile device A independently executes the consensus algorithm (S311D). Specifically, mobile device A independently agrees that the transaction data Tunl and TrntA are valid transaction data (i.e., validity), and independently agrees on the validity of block Blc(Tunl, TrntA). Note that the processing of step S309D may be performed when executing the consensus algorithm in step S311D.

[0372] Next, mobile device A links the block Blc(Tunl, TrntA) agreed upon in step S311D to the blockchain in ledger A (S312D).

[0373] As a result, as shown in FIG. 40, the block including the reservation transaction data TrsvA is linked to the block including the lending transaction data TrntA and the unlocking completion transaction data Tunl.

[0374] Fig. 41 is a diagram conceptually showing the blocks of the blockchain stored in Ledgers A and B when the fee calculation process according to the embodiment is performed. Fig. 41 shows the blocks of the blockchain stored in Ledgers A and B when step S15 in Figs. 23 and 33 is performed.

[0375] As shown in Figure 41, the block including the transaction data Tunl and TrntA will be linked after the block including the lending transaction data TrntB in order to eliminate the occurrence of a fork as described above. In other words, the block linked to the blockchain of ledger A of offline mobile device A by the offline lending process shown in Figure 39 will be linked after the block linked to the blockchain of ledger B by the competing reservation process.

[0376] In the comparative example, if reservation transaction data TrsvA conflicts with reservation transaction data TrsvB and is linked after the block containing reservation transaction data TrsvB, no fee will be collected for the reservation corresponding to reservation transaction data TrsvA. On the other hand, in this embodiment, although no fee can be collected for the reservation corresponding to reservation transaction data TrsvA, a fee for using mobile unit A through a local reservation is collected because unlocking completion transaction data Tunl is stored in the blockchain. As described above, since the unlocking completion transaction data exists in the blockchain, even if it appears that there is a competing reservation and a local reservation and that duplicate fees are being collected, it is clear that mobile unit A was indeed used through a local reservation that would not have been collected using the method of the comparative example.

[0377] Fig. 42 is a flowchart for explaining details of the fee calculation process according to the embodiment. The fee calculation process according to the embodiment shown in Fig. 42 is executed in step S15 in Fig. 23 and Fig. 33. Below, a case where the fee calculation process is performed by mobile device A will be described as a representative.

[0378] 23 and 33, first, mobile device A checks whether there is a trigger for toll collection (S6211). This trigger may be the passage of a certain interval, or the inclusion of return transaction data TrtnA in a block newly linked to the blockchain of ledger A.

[0379] If a trigger is detected in step S6211 (Yes in S6211), mobile device A searches the blockchain of ledger A (S6212). If a trigger is not detected in step S6211 (No in S6211), mobile device A returns to step S6211.

[0380] Next, mobile device A determines whether there is any reservation transaction data that has not yet been collected even though there is unlocking completion transaction data in the blockchain of ledger A (S6213). In this embodiment, if reservation transaction data TrsvA conflicts with reservation transaction data TrsvB and is linked after the block containing reservation transaction data TrsvB, it can be determined that there is any reservation transaction data that has not yet been collected.

[0381] In step S6213, if there is a duplicate reservation (Yes in S6213), mobile device A executes the fee calculation algorithm (S6214), thereby calculating the fee for the reservation included in the unlocking completion transaction data, i.e., the reservation ID indicating the use reservation of mobile device A included in the reservation transaction data TrsvA.

[0382] Next, mobile device A executes a fee collection process (S6215), thereby collecting the fee for using mobile device A in the reservation included in the reservation transaction data TrsvA.

[0383] [Effects, etc.] As described above, according to this embodiment, unlocking completion transaction data indicating that mobile body A has been unlocked is stored in the blockchain of each distributed ledger. As a result, even if there is a conflict in the reservation of use of mobile body A corresponding to the unlocking completion transaction data, the unlocking completion transaction data stored in the blockchain of each distributed ledger can be used as a trigger to collect the fee for using mobile body A.

[0384] As described above, mobile object A is an example of a service target, and a reservation for use of mobile object A is an example of a contract for the service target. Unlocking completion transaction data indicating that the service target has been unlocked is stored in the first blockchain. As a result, even if there are conflicting contracts for service targets corresponding to the unlocking completion transaction data, the unlocking completion transaction data stored in each blockchain in the distributed ledger can be used as a trigger to collect fees for using the service target. This makes it possible to prevent fraudulent use of service targets through the misuse of blockchains.

[0385] (Variation) The fraud prevention process is not limited to generating unlocking transaction data. Furthermore, fraudulent reservation detection process may be executed when mobile terminal A resumes communication. In this modification, a case where fraudulent reservation detection process is executed when a consensus algorithm is executed when mobile terminal A resumes communication will be described.

[0386] Figure 43 is a sequence diagram showing the system processing performed when mobile device A according to a variation of the embodiment resumes communication. Elements similar to those in Figure 21 are assigned the same reference numerals, and detailed description thereof will be omitted. The sequence diagram shown in Figure 43 differs from the sequence diagram shown in Figure 21 in that fraudulent reservation detection processing is performed when the consensus algorithm is executed. That is, the processing from step S601E to step S615E shown in Figure 43 is similar to the processing from step S601 to step S615 shown in Figure 21, and therefore description thereof will be omitted here.

[0387] In step S616E, mobile devices A, B, and C jointly execute a consensus algorithm. In this embodiment, mobile devices A, B, and C each execute a fraudulent reservation detection process when executing the consensus algorithm to agree that the transaction data Tpol is legitimate transaction data (i.e., legitimacy) based on the report notified in step S615.

[0388] In the fraudulent reservation detection process, mobile devices A, B, and C each search the blockchain of their own ledger to detect whether there is unlocking completion transaction data including a reservation ID that is said to have no corresponding reservation. As described above, if there is a conflicting reservation and there is unlocking completion transaction data including a reservation ID that is said to have no corresponding reservation, it can detect that there has been a fraudulent reservation for which a fee would not be collected using the existing fee calculation algorithm.

[0389] In the fraudulent reservation detection process, mobile devices A, B, and C may each search the blockchain of their own ledger to detect whether there is unlocking completion transaction data issued at a time when there is no reservation. As described above, if a local reservation is made for offline mobile device A, the mobile device A is locally rented, and then the mobile device A is restored to an online state, a fork occurs in the blockchain. Therefore, the reservation transaction data corresponding to the local reservation and the unlocking completion transaction data issued in conjunction with the local renting are stored in the blockchain of the distributed ledger at a time after mobile device A is restored to an online state. In other words, the reservation transaction data and the unlocking completion transaction data are stored in the blockchain of the distributed ledger after the time of the local reservation and local renting. Then, since the reservation transaction data and the unlocking completion transaction data are stored in the blockchain of the distributed ledger after the time of the local reservation and local renting, it appears that the unlocking completion transaction data was issued at a time when there is no reservation. As a result, by detecting the unlocking completion transaction data at a time when there is no reservation, it is possible to detect whether fraudulent processing has occurred.

[0390] Next, if no fraudulent reservation is detected during execution of the consensus algorithm, mobile devices A, B, and C each link the agreed-upon block Blc(Tpolv) in step S616E to the blockchain in the distributed ledger (S617E).

[0391] If a fraudulent reservation is detected, fraud information (incident report) indicating that fraudulent transaction data has been detected may be created and saved.

[0392] 44 is a flowchart showing fraudulent reservation detection processing according to a modified example of the embodiment. The following description will be given taking as an example a case where fraudulent reservation detection processing is performed by mobile device A. Note that the fraudulent reservation detection processing according to the embodiment is not limited to being performed when executing the consensus algorithm as described above, but may also be performed independently.

[0393] 44, first, mobile device A checks whether there is a trigger for a fraud check (S6161). This trigger may be the execution of the consensus algorithm as described above, the passage of a fixed interval such as 10 minutes, or the timing of the generation of a new block.

[0394] In step S6161, if there is a trigger (Yes in S6161), mobile device A searches the blockchain of ledger A (S6162). Note that in step S6161, if there is no trigger (No in S6161), mobile device A returns to step S6161.

[0395] Next, mobile device A checks whether there is unlocking completion transaction data linked to a time when there is no reservation in the blockchain of ledger A (S6163).

[0396] In step S6163, if there is unlocking completion transaction data linked to a time when there is no reservation (Yes in S6163), an incident report is created and saved (S6164). Note that in step S6163, if there is no unlocking completion transaction data linked to a time when there is no reservation (No in S6163), this fraudulent reservation detection process ends.

[0397] Figure 45 is a sequence diagram showing the system processing performed when an incident report is created by executing fraudulent reservation detection processing according to a modified embodiment. The same operations as in Figure 43 are assigned the same reference numerals, and detailed explanations will be omitted. Figure 45 shows the processing after mobile devices A, B, and C create an incident report in the fraudulent reservation detection processing performed when they jointly execute the consensus algorithm in step S616E.

[0398] That is, as shown in FIG. 45, in step S616E, mobile devices A, B, and C jointly execute a consensus algorithm. In this modification, mobile devices A, B, and C each execute a fraudulent reservation detection process when executing the consensus algorithm. In the example shown in FIG. 45, when the fraudulent reservation detection process is executed, unlocking completion transaction data issued at a time when no reservation was made is detected, and it is determined that a fraudulent reservation has occurred. Therefore, mobile devices A, B, and C create an incident report indicating that unlocking completion transaction data has been detected.

[0399] Next, for example, mobile terminal B generates transaction data Tinc for recording the created incident report as a representative (S622E). Note that the generation of the transaction data Tinc is not limited to mobile terminal B, and mobile terminal A or mobile terminal C may also generate the transaction data Tinc.

[0400] Next, mobile device B transfers the transaction data Tinc to other mobile devices, mobile devices A and C (S623E). As a result, mobile devices A and C obtain the transaction data Tinc.

[0401] Next, each of the mobile devices A, B, and C executes a verification algorithm to verify the transaction data Tinc (S624E).

[0402] Next, mobile devices A, B, and C each store the verified transaction data Tinc in their ledgers in step S624E (S625E). More specifically, mobile device A stores the verified transaction data Tinc in ledger A, and mobile device B stores the verified transaction data Tinc in ledger B. Mobile device C stores the verified transaction data Tinc in ledger C.

[0403] As a result, transaction data Tinc is stored in Ledgers A, B, and C, and incident reports are recorded.

[0404] [Other embodiments] As described above, the present disclosure has been described based on the above-mentioned embodiment, but it goes without saying that the present disclosure is not limited to the above-mentioned embodiment. The following cases are also included in the present disclosure.

[0405] (1) In the above embodiment, a mobile object is used as an example of a service target, but this is not limiting. The service target may be anything that is locked to prevent other users from using the service when the service is not in use and is unlocked when the service is used, such as a hotel room or an electronic locker. Furthermore, the contract is not limited to a reservation for use of a mobile object 10, but may also be a reservation for use of a hotel room or an electronic locker. In this case, the unlocking completion transaction data is transaction data indicating that the service target has been unlocked when the service target is used, and may include a first contract ID that uniquely identifies the first contract that uses the service target. Furthermore, the unlocking completion transaction data is generated when the reservation transaction data is stored in the blockchain and the user is permitted to unlock the service target during the reserved time slot.

[0406] Furthermore, a fee collection smart contract may be executed to collect the usage fee for the service target. In this case, for example, unlocking completion transaction data may be stored in a blockchain in the distributed ledger, and the fee collection smart contract may be made to check whether the usage fee for the first contract identified by the first contract ID included in the unlocking completion transaction data has not yet been collected. Furthermore, when unlocking completion transaction data is stored and the fee has not yet been collected, the smart contract execution unit 106 may make the fee collection smart contract collect the usage fee for the first contract. The fee has not yet been collected when the first blockchain and the second blockchain store second transaction data for executing the first contract and third transaction data for executing the second contract for using the service target. The fee has not yet been collected when the time period during which the service target included in the first contract is used partially overlaps with the time period during which the service target included in the second contract is used.

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

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

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

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

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

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

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

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

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

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

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

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

[0419] The present disclosure can be used for control methods, control devices, and programs, and can be used for control methods, control devices, and programs that can prevent fraudulent use without paying fees when users sign a contract to use a vehicle, such as a sharing service for a vehicle such as a bicycle or motorcycle. [Explanation of symbols]

[0420] 1 System 10, 10A, 10B, 10C Mobile 11, 11A, 11B, 11C terminals 20 Management Server 100 Mobile device 101, 1101 input section 102 Transaction Data Generation Unit 103 Transaction Data Verification Unit 104 Block Generation Unit 105 Synchronization section 106 Smart Contract Execution Department 107 Blockchain Management Department 108 Distributed Ledger Storage Unit 109 State memory unit 110 Fraud detection unit 111, 1103 Communications Department 112, 1102 Display section

Claims

1. A method for controlling a first node in a system used for utilizing a service target, the system including a first node that manages a first blockchain using a first distributed ledger and a plurality of second nodes that each manage a second blockchain using a second distributed ledger, the method comprising: generating first transaction data indicating that the service object has been unlocked when the service object is used, the first transaction data including a first contract ID that uniquely identifies a first contract under which the service object is used; storing a block including the first transaction data in the first blockchain; Execute a fee collection smart contract to collect the usage fee for the service target; When executing the fee collection smart contract, The first transaction data is stored in the first blockchain and the second blockchain, and the fee collection smart contract is caused to confirm whether or not the usage fee for the first contract, which is the first contract identified by the first contract ID included in the first transaction data, for the use of the service target has not yet been collected; If the first transaction data is stored and the fee has not been collected, cause the fee collection smart contract to collect the usage fee for the first contract; Control method.

2. The above-mentioned cases of non-collection are as follows: The first blockchain and the second blockchain store second transaction data for executing the first contract and third transaction data for executing the second contract for using the service object, and further, the time period for using the service object included in the first contract partially overlaps with the time period for using the service object included in the second contract. The control method according to claim 1 .

3. Furthermore, the fee collection smart contract is caused to create an incident report indicating that there has been fraud in the use of the service target included in the first contract. The control method according to claim 1 or 2.

4. A method for controlling a first node in a system used for utilizing a service target, the system including a first node that manages a first blockchain using a first distributed ledger and a plurality of second nodes that each manage a second blockchain using a second distributed ledger, the method comprising: generating first transaction data indicating that the service object has been unlocked when the service object is used, the first transaction data including a first contract ID that uniquely identifies a first contract under which the service object is used; storing a block including the first transaction data in the first blockchain; second transaction data for executing the first contract and third transaction data for executing the second contract for using the service object are stored in the first blockchain and the second blockchain, and a fraud detection smart contract is caused to confirm whether or not there is a competing contract in which the time period for using the service object included in the first contract partially overlaps with the time period for using the service object included in the second contract; If the competing contract exists, the fraud detection smart contract is caused to assign a flag to the first contract indicating that the usage fee has not yet been collected; causing a fee collection smart contract for collecting a usage fee for the service target to collect a fee for the first contract to which the flag is assigned; Control method.

5. The system is used for a service for sharing a plurality of moving objects, the service targets are the plurality of mobile objects, the first contract and the second contract are reservations for use of a first mobile object; the second transaction data and the third transaction data are reservation transaction data for a user to make a reservation for use of the first mobile object via the first node, and include an ID of the user, a reservation time period indicating a time period during which the user will use the first mobile object, and a reservation number for identifying the reservation for use; The control method according to claim 2 or 4.

6. moreover, the first node receives a request to unlock the first mobile object from the user as a request to start using the first mobile object; The first node checks whether the reservation transaction data corresponding to the unlock request is stored in the first blockchain; If the reservation transaction data is stored, the first transaction data is generated by permitting the user to unlock the first mobile body during the time period. The control method according to claim 5.

7. moreover, acquiring rental transaction data indicating that the first mobile object has been rented to the user, the rental transaction data including the user's ID, the reservation number, and a timestamp of the time when the first mobile object was rented to the user; storing a second block including the lending transaction data in the first blockchain; acquiring return transaction data indicating that the user has returned the first moving object, the return transaction data including the user's ID, the reservation number, and a timestamp of the time when the user returned the first moving object; storing a third block including the return transaction data in the first blockchain; collecting a usage fee for the first mobile object from the ID of the user included in the reservation transaction data; The control method according to claim 5 or 6.

8. A control device in a system used for utilizing a service target, the control device comprising: a control device that manages a first blockchain using a first distributed ledger; and a plurality of other control devices that each manage a second blockchain using a second distributed ledger, a processor; a memory; the processor generates first transaction data indicating that the service object has been unlocked when the service object is used, the first transaction data including a first contract ID that uniquely identifies a first contract that uses the service object; The processor stores a block including the first transaction data in the first blockchain; Execute a fee collection smart contract to collect the usage fee for the service target; When executing the fee collection smart contract, The first transaction data is stored in the first blockchain and the second blockchain, and the fee collection smart contract is caused to confirm whether or not the usage fee for the first contract, which is the first contract identified by the first contract ID included in the first transaction data, for the use of the service target has not yet been collected; If the first transaction data is stored and the fee has not been collected, cause the fee collection smart contract to collect the usage fee for the first contract; Control device.

9. A program for causing a computer to execute a control method for the first node in a system used for utilizing a service target, the system including a first node that manages a first blockchain using a first distributed ledger and a plurality of second nodes that each manage a second blockchain using a second distributed ledger, the program comprising: generating first transaction data indicating that the service object has been unlocked when the service object is used, the first transaction data including a first contract ID that uniquely identifies a first contract under which the service object is used; storing a block including the first transaction data in the first blockchain; Execute a fee collection smart contract to collect the usage fee for the service target; When executing the fee collection smart contract, The first transaction data is stored in the first blockchain and the second blockchain, and the fee collection smart contract is caused to confirm whether or not the usage fee for the first contract, which is the first contract identified by the first contract ID included in the first transaction data, for the use of the service target has not yet been collected; When the first transaction data is stored and the fee has not been collected, causing the fee collection smart contract to collect the usage fee for the first contract; A program that is executed by a computer.

10. A control device in a system used for utilizing a service target, comprising a first node that manages a first blockchain using a first distributed ledger and a plurality of second nodes that each manage a second blockchain using a second distributed ledger, a processor; a memory; the processor generates first transaction data indicating that the service object has been unlocked when the service object is used, the first transaction data including a first contract ID that uniquely identifies a first contract that uses the service object; storing a block including the first transaction data in the first blockchain; second transaction data for executing the first contract and third transaction data for executing the second contract for using the service object are stored in the first blockchain and the second blockchain, and a fraud detection smart contract is caused to confirm whether or not there is a competing contract in which the time period for using the service object included in the first contract partially overlaps with the time period for using the service object included in the second contract; If the competing contract exists, the fraud detection smart contract is caused to assign a flag to the first contract indicating that the usage fee has not yet been collected; causing a fee collection smart contract for collecting a usage fee for the service target to collect a fee for the first contract to which the flag is assigned; Control device.

11. A program for causing a computer to execute a control method for the first node in a system used for utilizing a service target, the system including a first node that manages a first blockchain in a first distributed ledger and a plurality of second nodes that each manage a second blockchain in a second distributed ledger, the program comprising: generating first transaction data indicating that the service object has been unlocked when the service object is used, the first transaction data including a first contract ID that uniquely identifies a first contract under which the service object is used; storing a block including the first transaction data in the first blockchain; second transaction data for executing the first contract and third transaction data for executing the second contract for using the service object are stored in the first blockchain and the second blockchain, and a fraud detection smart contract is caused to confirm whether or not there is a competing contract in which the time period for using the service object included in the first contract partially overlaps with the time period for using the service object included in the second contract; If the competing contract exists, the fraud detection smart contract is caused to assign a flag to the first contract indicating that the usage fee has not yet been collected; causing a fee collection smart contract for collecting a usage fee for the service target to collect a fee for the first contract to which the flag is assigned; A program that is executed by a computer.

Images