Control method, control device, and program

Abstract

This control method is for a first node in a system that is configured to be utilized by a service object and that includes the first node and a plurality of second nodes. The first node is for managing a first block chain with a first distributed ledger and the second node is for managing a second block chain with a second distributed ledger. The control method: acquires first transaction data; determines whether the number of second nodes capable of communicating, from among the plurality of second nodes, exceeds a prescribed number (S10712); and generates a first block including the first transaction data only if the number of the second nodes capable of communicating exceeds the prescribed number (S10713).

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 related 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] JP 2019-153130 A 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 a first node in a system used to utilize a service target, the control method 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 control method acquiring first transaction data, determining whether a number of communicable second nodes among the multiple second nodes exceeds a predetermined value, and generating a first block including the first transaction data only if the number of communicable second nodes exceeds the predetermined value.

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

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

[0009] [Figure 1] FIG. 1 is a diagram for explaining the steps of a method for committing fraud. [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 moving body 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 blocks of a 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 the system according to the first example of the comparative example. [Figure 13] FIG. 13 is a flowchart for explaining details of the fee calculation process in 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 blocks of a blockchain stored in ledger A by the operation of step S1A in FIG. 14. [Figure 15B] FIG. 15B is a diagram conceptually illustrating blocks of a blockchain stored in ledger A by the operation of step S3A in FIG. 14. [Figure 15C] FIG. 15C is a diagram conceptually illustrating blocks of a 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. 14. [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. 14. [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 mobile device A according to the second example of the comparative example restores communication. [Figure 22]FIG. 22 is a flowchart for explaining block connection processing in a system according to a comparative example. [Figure 23] FIG. 23 is a flowchart showing an outline of fraud processing operations of the system according to the third example of the comparative example. [Figure 24A] FIG. 24A is a conceptual diagram showing blocks of a blockchain stored in ledger A by the operation of step S10 in FIG. 23. [Figure 24B] FIG. 24B is a conceptual diagram showing blocks of a blockchain stored in ledger A by the operation of step S11 in FIG. 23. [Figure 24C] FIG. 24C is a conceptual diagram showing blocks of a blockchain stored in ledger A by the operation of step S12 in FIG. 23. [Diagram 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. 23. [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. 23. [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. 23. [Figure 28] FIG. 28 is a sequence diagram showing a process for 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. [Diagram 30] FIG. 30 is a sequence diagram showing a local lending process in a system according to a third example of the comparative example. [Diagram 31] FIG. 31 is a sequence diagram showing system processing performed when mobile body device A according to a third example of the comparative example restores communication. [Diagram 32] FIG. 32 is a sequence diagram showing a return process of the system according to the third example of the comparative example. [Diagram 33] FIG. 33 is a flowchart showing an outline of fraud processing operations of the system according to the fourth example of the comparative example. [Figure 34A] FIG. 34A is a diagram conceptually showing blocks of a blockchain stored in ledger A by the operation of step S10 in FIG. 33. [Figure 34B] FIG. 34B is a conceptual diagram showing blocks of a blockchain stored in ledger A by the operation of step S11 in FIG. 33. [Figure 34C] FIG. 34C is a conceptual diagram showing blocks of a blockchain stored in ledger A by the operation of step S12 in FIG. 33. [Fig. 34D] FIG. 34D is a conceptual diagram showing blocks of a blockchain stored in ledger A by the operation of step S13A in FIG. 33. [Diagram 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. 33. [Diagram 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. 33. [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 mobile body device A according to the fourth example of the comparative example resumes communication. [Figure 39] FIG. 39 is a sequence diagram showing processing for disabling local reservation in the system according to the embodiment. [Diagram 40] FIG. 40 is a flowchart illustrating an example of a block generation determination process according to the embodiment. [Diagram 41] FIG. 41 is a flowchart illustrating another example of the block generation determination process according to the embodiment. [Diagram 42] FIG. 42 is a flowchart for explaining the block connection process of the system according to the embodiment. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0010] (How one aspect of the present disclosure was achieved) As mentioned above, Patent Document 1 discloses a technology for appropriately managing information related 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 unauthorized use by misusing the blockchain mechanism. An example will be described below.

[0012] FIG. 1 is a diagram for explaining the procedure of a method for fraudulent use. FIG. 2A to FIG. 2F are diagrams showing an example of a scene in which the procedure shown in FIG. 1 is performed. FIG. 1 shows the procedure in the case where a reservation for use of a bike A in a service for sharing multiple bikes is made and the bike A is fraudulently used. The arrow indicates the current time. Also, each of the multiple bikes has a ledger in which reservations are managed by a blockchain. FIG. 2A is a diagram showing an example of a scene in which step 1 shown in FIG. 1 is performed, and FIG. 2B is a diagram showing an example of a scene in which steps 2 and 3 shown in FIG. 1 are performed. FIG. 2C is a diagram showing an example of a scene in which step 4 shown in FIG. 1 is performed, and FIG. 2D is a diagram showing an example of a scene in which step 5 shown in FIG. 1 is performed. FIG. 2E is a diagram showing an example of a scene in which step 6 shown in FIG. 1 is performed, and FIG. 2F is a diagram showing an example of a scene in which step 7 is performed after step 6 shown in FIG. 1.

[0013] A user attempting fraudulent use makes a first reservation to use bike A for 15 minutes between 12:00 and 12:15 in step 1, as shown in Figure 2A. Then, since ledger A of bike A is able to communicate (online) with ledgers B and C of other bikes, 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, in steps 2 and 3, the user attempting fraudulent use sets ledger A of bike A to a state in which it cannot communicate with ledgers B and C of the other bikes (offline). Next, the user attempting fraudulent use makes a second reservation to use bike A for only 15 minutes between 16:00 and 16:15, for example, in the ledgers B and C of the other bikes. Then, because ledger A of bike A is in an offline state, the second reservation Tx, shown in black as shown in step 3 of Figure 1, is stored only in the online ledgers B and C.

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

[0016] Next, as shown in FIG. 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. Then, as will be described in detail later, a fork occurs in the blockchain of ledgers A, B, and C, and the second reservation Tx is stored in the blockchain of ledger A as in the blockchains of ledgers B and C, as shown in step 6 of FIG. 1. Then, the fraudulent reservation Tx is 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 comes back online in step 6, the fraudulent reservation Tx is stored in ledgers 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. In FIG. 3A to 3C, transaction data stored in ledger A of a mobile object A and ledger B of a mobile object B are conceptually shown. Tx indicates transaction data. Mobile object A may be, for example, a 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 in which they can communicate (are online) with other mobile units (not shown), ledger A and ledger B store block 1 including the same Tx1 and block 2 including Tx2 linked to block 1. 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 communication cut off (offline) with other mobile units, blocks including different Tx are stored in ledger A and ledger B. In the example shown on the right side of Fig. 3A, ledger A stores block α including Txα linked to block 2, while ledger B stores block 3 including Tx3 linked to block 2 and block 4 including Tx4 linked to block 3. Tx3 may be, for example, the second reservation Tx described above, and Txα may be, for example, the fraudulent reservation Tx described above.

[0022] In this way, when Ledgers A and B go offline, communication between them is cut off, and Ledgers A and B update the blockchain independently.

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

[0024] Thus, when ledger A comes back online, the blockchain connected to block 2 will diverge, causing a fork.

[0025] Next, as shown on the right side of Figure 3B, block α including Txα, which is a side chain of block 2, is deleted, and the fork is resolved. At this time, Txα included in block α is not deleted, but is stored in the transaction pool of the mobile device mounted on 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, Txα is included and stored at the timing of generating a new block 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 in Ledgers A and B, and they now have the same blockchain. Let's return to Figure 2F to continue the explanation.

[0028] Finally, the user who attempted fraudulent use returns Bike A in step 7, as shown in FIG. 2F. The fee collection algorithm is then executed to collect the fee for use of Bike A. 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 ledger A for bike A returns to an online state in step 6, the fraudulent reservation Tx is stored in ledgers A, B, and C after the second reservation Tx, and furthermore the reservation time slot of the second reservation Tx and the reservation time slot of the fraudulent reservation Tx are booked together. Furthermore, 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 reservations for objects, there is a problem that the behavior of the blockchain when a fork occurs can be exploited to illegally use the object.

[0031] In contrast, a control method according to one embodiment of the present disclosure is a control method for a first node in a system used to utilize a service target, the control method 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 control method acquiring first transaction data, determining whether the number of communicable second nodes among the multiple second nodes exceeds a predetermined value, and generating a first block including the first transaction data only if the number of communicable second nodes exceeds the predetermined value.

[0032] In this way, if communication with more than a certain number of second nodes is not possible, a block including the acquired first transaction data cannot be generated. This makes it possible to prevent processes that could lead to unauthorized use of the service target, such as causing the first node to be unable to communicate with the second node and storing a block including the first transaction data only in the first distributed ledger. This makes it possible to prevent unauthorized use of the service target by misusing the blockchain.

[0033] Also, for example, when determining whether the number of second nodes exceeds the predetermined value, a signal requesting a reply may be sent to the multiple second nodes, and the second nodes that have received a reply to the signal may be determined to be capable of communication, and whether the number of second nodes that can communicate exceeds the predetermined value may be determined based on whether the number of second nodes that have received a reply to the signal exceeds the predetermined value.

[0034] In this manner, it is possible to determine whether the first node is in a state in which it can communicate with more than a predetermined number of second nodes.

[0035] Also, for example, the signal may be the first transaction data, and when determining whether the predetermined value is exceeded, if the number of second nodes with which communication is possible is equal to or less than the predetermined value, the first transaction data may be transmitted as the signal to the multiple second nodes at a predetermined interval.

[0036] This allows the first node to generate a block including the acquired first transaction data while being able to communicate with more than a certain number of second nodes, thereby preventing processing that could lead to fraudulent use of the service, such as storing a block including the first transaction data only in the first distributed ledger by disabling communication between the first node and the second node.

[0037] Also, for example, when acquiring the first transaction data, the first transaction data may be acquired by receiving the first transaction data from at least one second node among the plurality of second nodes, and when determining whether the first transaction data exceeds the predetermined value, the determination of whether the first transaction data exceeds the predetermined value may be made based on whether the first transaction data has been received from a number of second nodes among the plurality of second nodes that exceeds the predetermined value.

[0038] In this manner, it is possible to determine whether the first node is in a state in which it can communicate with more than a predetermined number of second nodes.

[0039] Also, for example, the generated first block may be transmitted to a number of the second nodes exceeding the predetermined value, a consensus algorithm may be executed together with the number of the second nodes exceeding the predetermined value, and the first block may be stored in the first blockchain.

[0040] Furthermore, for example, the first transaction data may include information regarding a first contract for utilizing the service object.

[0041] Furthermore, for example, when the first transaction data is stored in the first blockchain, the service target corresponding to the first contract may be used.

[0042] Also, for example, the system may be used for a service for sharing multiple mobile objects, the service targets may be the multiple mobile objects, and the first transaction data may be reservation transaction data for a user to make a reservation for use of the first mobile object via the first node, and may 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.

[0043] As described above, if communication with more than a predetermined number of second nodes is not possible, a block including reservation transaction data for using the first mobile object cannot be generated. This makes it possible to suppress lending of the first mobile object itself, since blocks including reservation transaction data are not stored only in the first distributed ledger, even if the first node is made unable to communicate with the second node. Therefore, by preventing the use of the first mobile object itself, which could lead to fraudulent use of the service target, it is possible to suppress fraudulent use of the service target that exploits the blockchain.

[0044] Furthermore, for example, the first node may further receive a request to unlock the first mobile body as a request from the user 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 permit the user to unlock the first mobile body during the time period and generate the first transaction data.

[0045] Furthermore, for example, the method may further include obtaining 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, obtaining 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.

[0046] A control device according to one embodiment of the present disclosure is a control device in a system used for utilizing a service target, comprising a control device that manages a first blockchain in a first distributed ledger and multiple other control devices that each manage a second blockchain in a second distributed ledger, and comprising a processor and a memory, wherein the processor acquires first transaction data, determines whether the number of other control devices with which communication is possible among the multiple other control devices exceeds a predetermined value, and generates a first block including the first transaction data only if the number of second nodes with which communication is possible exceeds the predetermined value.

[0047] 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 utilize a service target, 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 the computer to execute the following steps: acquire first transaction data; determine whether a number of communicable second nodes among the multiple second nodes exceeds a predetermined value; and generate a first block including the first transaction data only if the number of communicable second nodes exceeds the predetermined value.

[0048] Hereinafter, the embodiments will be described with reference to the drawings. Note that each of the embodiments described below shows a specific example of the present disclosure. In other words, the numerical values, shapes, materials, components, arrangement and connection of the components, steps, and order of steps shown in the following embodiments are merely examples and are not intended to limit the present disclosure. In addition, among the components in the following embodiments, components that are not described in the independent claims showing the highest concept are not necessarily required to achieve the object of the present disclosure, but are described as components constituting a more preferred embodiment.

[0049] (Embodiment) First, a system configuration according to the present disclosure will be described. The system includes a first node that manages a first blockchain in a first distributed ledger and a plurality of second nodes that manage a second blockchain in a second distributed ledger, and is used for use of a service target. For example, the system may be used for a service for sharing a plurality of mobile objects, and the service target in this case is a plurality of mobile objects. In this embodiment, the system accepts a reservation for use of a specific mobile object from a user via a terminal (or a mobile object), and lends the specific mobile object to the user according to the accepted reservation for use. When the system accepts a request for lending the reserved specific mobile object from the user via the terminal (or a mobile object) during a reserved time period of the accepted reservation for use, the system permits lending of the specific mobile object to the user. Specifically, when the system accepts a request for unlocking the specific mobile object from the user, the system checks the reservation made in advance, and permits the user to unlock the specific mobile object during the reserved time period according to the confirmation result.

[0050] In addition, examples of mobile objects used in sharing services include bicycles, motorbikes, cars, ships, and aircraft.

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

[0052] 4, the system 1 includes, for example, mobile entities 10A to 10C and terminals 11A to 11C. In this example, each of the mobile entities 10A to 10C has a distributed ledger for sharing data of the same content. In these distributed ledgers, for example, a blockchain with the same configuration is shared.

[0053] The mobile objects 10A to 10C and the 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.

[0054] 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 terminals 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.

[0055] In addition, the system for managing the distributed ledger that stores the blockchain may be in any of the following forms: public, private, or consortium.

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

[0057] 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 data of the same content. In these distributed ledgers, for example, a blockchain of the same configuration is shared.

[0058] 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.

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

[0060] 5B shows, for example, moving objects 10A to 10C and terminals 11A to 11C. In this example, each of the terminals 11A to 11C has a distributed ledger for sharing data of the same content. In these distributed ledgers, for example, a blockchain with the same configuration is shared.

[0061] The mobile objects 10A to 10C and the 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] FIG. 5C is a diagram illustrating another example of the configuration of the system according to the embodiment.

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

[0064] The mobile objects 10A to 10C and the 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.

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

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

[0067] [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 called a control device.

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

[0069] FIG. 6 is a diagram showing an example of a configuration of a moving object device 100 according to an embodiment.

[0070] The mobile device 100 of 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 memory unit 108, a state memory unit 109, a fraud detection unit 110, a communication unit 111, and a display unit 112.

[0071] <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 the information input to the transaction data generation unit 102, or transmits the information input to the communication unit 111. For example, the input unit 101 may accept an information input indicating a return from the user.

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

[0073] In this embodiment, the transaction data generating 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 generating 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 generating unit 102 generates rental transaction data. The rental transaction data includes a user ID, a reservation number (reservation ID) for identifying a usage reservation, and a timestamp of the time when the mobile body 10 is rented to the user.

[0074] Furthermore, the transaction data generating unit 102 generates return transaction data indicating that the user has returned the mobile object 10. Specifically, when the user has returned the mobile object 10, the transaction data generating 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 accepting information input indicating the return from the user, by accepting 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 return facility when the return of the mobile object is accepted at a predetermined return facility for the mobile object 10. 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.

[0075] The reservation transaction data is generated by the terminal 11A, but when the mobile device 100 accepts a usage reservation from a user, the transaction data generating unit 102 may generate reservation transaction data for making the usage reservation. Specifically, when the user inputs a usage reservation into the input unit 101, the transaction data generating 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 the mobile device 10. The reservation information may further include a device ID for identifying the mobile device 10 for which the usage reservation has been made.

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

[0077] For example, the transaction data verification unit 103 verifies whether an electronic 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, lending transaction data, and return transaction data. In other words, the transaction data verification unit 103 verifies the validity of the reservation transaction data, lending transaction data, and return transaction data.

[0078] When the transaction data is generated by the transaction data generation unit 102, the transaction data verification unit 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 including transaction data whose legitimacy has been verified by the transaction data verification unit 103. The block generation unit 104 generates a block including a predetermined number of transaction data from among the multiple verified transaction data 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 be different 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 section 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 device 100 via the communication unit 111. Then, the synchronization unit 105 executes a consensus algorithm for the transmitted block together with the other mobile device 100. As the consensus algorithm, a consensus algorithm called PBFT (Practical Byzantine Fault Tolerance) may be used, or other known consensus algorithms may be used. 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 has been successful, and determines whether or not the number of such reports has exceeded a predetermined number. Then, the synchronization unit 105 may determine that the validity of the transaction data has been verified by the consensus algorithm when the number of such reports exceeds a predetermined number. In this manner, the synchronizer 105 agrees that the transaction data is valid (ie, validity) based on reports 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 in 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, etc. contained 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 target of the service 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 operating 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. The fee calculation processing is the same as the processing performed by the blockchain management unit 107 described later.

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

[0089] {Main chain / 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 of the distributed ledger storage unit 108. The blockchain management unit 107 determines whether or not the multiple blocks constituting the first blockchain are the same as the multiple blocks constituting the second blockchain through the comparison. 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 included in the first blockchain and not included in the second blockchain, or the number of one or more second difference blocks included in the second blockchain and not included 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 the comparison of the first blockchain and the second blockchain shows that the first blockchain has one or more first difference blocks and the second blockchain has one or more second difference blocks.

[0090] 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 one or more common blocks common to the first blockchain and the second blockchain. Then, the blockchain management unit 107 further adds one or more blocks including one or more transaction data included in the fewer number (shorter number) of one or more first difference blocks and one or more second difference blocks to the greater number added. 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 lesser number of one or more first difference blocks and one or more second difference blocks as the side chain block. Then, the blockchain management unit 107 adds the main chain block and the additional block generated from one or more transaction data included in the main chain block and the side chain block, in that order, to the one or more common blocks.

[0091] 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.

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

[0093] Here, the one or more first difference blocks are, for example, blocks that are not included in the second blockchain, generated by a mobile device 100 being added to the first blockchain in a state where 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 the multiple other mobile devices 100 are in a state where they can communicate with each other. This is because the second blockchain is managed in synchronization with the second distributed ledger held by each of the multiple other mobile devices 100, which is greater than the mobile device 100 that manages the first blockchain, and it is considered that there are more opportunities to generate blocks in the multiple other mobile devices 100 than in one mobile device 100. For this reason, the one or more first difference blocks generated in one mobile device 100 that cannot communicate with the other mobile devices 100 are more likely to become side chain blocks than main chain blocks.

[0094] The one or more first difference blocks may include a block including transaction data including information related to a contract, such as a reservation for use of the mobile unit 10. The transaction data including information related to the contract may include reservation transaction data, rental transaction data, and return transaction data.

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

[0096] Loan Processing The blockchain management unit 107 may also perform a lending process for lending 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. When 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 acquires the unlocking instruction, the actuator that is performing the locking is operated based on the unlocking instruction, and the mobile body is unlocked.

[0097] 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 has 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.

[0098] 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 located to unlock when the start time of the reserved time period for the usage reservation stored in the first blockchain arrives.

[0099] <Fee calculation process> The blockchain management unit 107 may perform the fee calculation process instead of the smart contract executed by the smart contract execution unit 106. The blockchain management unit 107 performs the fee calculation process when a certain interval has elapsed since the execution of the previous process or when the 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 or not two or more transaction data including contracts that conflict with each other are included in the first blockchain managed in the first distributed ledger. A contract that conflicts with each other is, for example, a contract in which 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. In this embodiment, an example of a contract that conflicts with each other is a first reservation and a second reservation that conflicts with the first reservation, which include the same mobile ID and two or more reservation time periods that partially overlap with each other. When the first blockchain contains a competing reservation, the blockchain management unit 107 fulfills the first reservation or the competing reservation included in the transaction data added to the first blockchain first among the transaction data including the first reservation and the transaction data including the competing reservation. 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.

[0100] The reservations subject to fee calculation are reservations for which the reservation number is included in the return transaction data stored in the first blockchain, and for which the fee has not yet been calculated. In other words, reservations for which the fee has already been calculated are excluded from the subject of fee calculation. In addition, if a reservation corresponding to the reservation number included in the return transaction data is not stored in the first blockchain, the fee for the return transaction data is not calculated.

[0101] <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, lending transaction data, and return transaction data in the first blockchain.

[0102] <Status Storage Unit 109> The state storage unit 109 is a storage unit that stores the latest version of the data of the distributed ledger. The data stored in the state storage unit 109 is data that can be changed or deleted by a computer. The state storage unit 109 includes, for example, an on-memory area in which variables, functions, etc. for executing a smart contract are stored, and an area of ​​a transaction pool in which transaction data is stored. The state storage unit 109 may store transaction data whose validity has been verified by the transaction data verification unit 103. The state storage unit 109 may store 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 called by the transaction data. The state storage unit 109 may also store variables of the smart contract stored in the distributed ledger. The state storage unit 109 may store transaction data generated by the transaction data generation unit 102. The state storage unit 109 may store transaction data received by the communication unit 111.

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

[0104] <Fraud detection unit 110> When the transaction data verified by the transaction data verification unit 103 is stored in the transaction pool area of ​​the state storage unit 109, the fraud detection unit 110 performs a block generation determination process. The fraud detection unit 110 may perform the block generation determination process by executing a block generation determination algorithm that is stored in advance in the on-memory area of ​​the state storage unit 109 or in the first distributed ledger of the distributed ledger storage unit 108. The fraud detection unit 110 performs a fraud detection process in which the number of other mobile devices 100 that can communicate among the multiple other mobile devices 100 exceeds a predetermined value, and permits block generation only when the number of other mobile devices 100 that can communicate exceeds the predetermined value. The fraud detection unit 110 may transmit a signal requesting a reply to the multiple other mobile devices 100, and determine that the other mobile devices 100 that have received a reply to the signal are capable of communication. In this case, the fraud detection unit 110 may determine whether the number of other mobile devices 100 that can communicate exceeds a predetermined value depending on whether the number of other mobile devices 100 that have received a reply to the signal exceeds a predetermined value. Furthermore, the fraud detection unit 110 may determine whether the predetermined value is exceeded based on whether transaction data or signals have been received from a number of other mobile devices 100 that exceeds a predetermined value among the multiple other mobile devices 100. In this way, if communication with more than a predetermined number of other mobile devices 100 is not possible, a block including transaction data is not generated, so transaction data that may lead to fraudulent use of the mobile device 10 is prevented from being stored in the blockchain. As a result, even if reservation transaction data that may lead to fraudulent use of the mobile device 10 is stored in the transaction pool, it is not stored in the blockchain, and the mobile device 10 can be prevented from being used. Therefore, the fee calculation algorithm can prevent fraudulent reservations for which fees are not collected in the first place.

[0105] <Communication 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 communication unit 111 may hold an encryption key for TLS communication.

[0106] In this embodiment, the communication unit 111 receives reservation transaction data from the terminal 11. Also, the communication unit 111 receives an unlocking request from the terminal 11. Also, the communication unit 111 receives, from another mobile device 100, transaction data that has been verified in 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.

[0107] <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 to return the mobile device 100 from the user.

[0108] 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 the terminal 11 in the description.

[0109] [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.

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

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

[0112] <Input section 1101> The input unit 1101 accepts information input by a user operation. The input unit 1101 displays the accepted information input on the display unit 1102 and transmits it to the communication unit 1103.

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

[0114] Furthermore, the input unit 1101 accepts an input to a display (UI: User Interface) for an unlocking 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 unlocking request and generates the unlocking request.

[0115] <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.

[0116] <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 other terminals 11 and receive information from other terminals 11 via the network.

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

[0118] 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.

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

[0120] First, as a comparative example, normal processing for a mobile object A in a service for sharing multiple mobile objects will be described, and then processing for a case where the mobile object A is fraudulently used by misusing the blockchain mechanism, i.e. fraudulent processing, will be described. After that, processing according to the present disclosure with fraud countermeasures will be described.

[0121] [First Comparative Example] A process in which the mobile unit A is always online will be described as a first comparative example.

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

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

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

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

[0126] Next, the mobile device A etc. performs a fee calculation process (S7). More specifically, the mobile device A etc. executes a fee calculation algorithm and collects a fee for using the mobile device A for the reservation for using the mobile device A made by the user.

[0127] Next, the details of the processes in steps S1 to S5 shown in Fig. 8, i.e., the reservation process, the rental process, and the return process, will be described with reference to a sequence diagram. In the following, it will be described that a user who wishes to use moving body A uses terminal A to perform reservation process, rental process, and return process for moving body A with respect to moving body device A mounted on moving body A.

[0128] [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.

[0129] First, terminal A generates reservation transaction data Trsv for reserving the use of mobile body A based on an operation of a user who wishes to use mobile body 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.

[0130] 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).

[0131] 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 obtain the reservation transaction data Trsv.

[0132] Next, each of the mobile devices A, B, and C executes a verification algorithm to verify the validity 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.

[0133] 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.

[0134] Next, since mobile devices A, B, and C are in a state where they can communicate with each other, they exchange information on 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 includes verified reserved transaction data Trsv.

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

[0136] Next, each of the 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 the mobile devices A, B, and C to report to the other mobile devices that the validity of the reservation transaction data Trsv included in the block Blc(Trsv) has been successfully verified.

[0137] Next, the mobile devices A, B, and C jointly execute a consensus algorithm (S109). Specifically, based on the report notified in step S108, the mobile devices A, B, and C each agree that the reservation transaction data Trsv is valid transaction data (i.e., validity), and agree on the validity of the block Blc(Trsv). In the example shown in Fig. 10, it is agreed that the reservation transaction data Trsv included in the block Blc(Trsv) is valid transaction data (i.e., validity), and the validity of the 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.

[0138] Next, mobile devices A, B, and C each link the agreed-upon block Blc (Trsv) in step S109 to the 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.

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

[0140] [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.

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

[0142] Next, when the mobile device A receives the unlock request transmitted in step S301, it checks whether there is a reservation corresponding to the unlock request in the blockchain of ledger A (S302). Here, the 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 the reservation transaction data Trsv, the mobile device A can check whether there is a reservation corresponding to the unlock request in the blockchain of ledger A.

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

[0144] 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 together 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.

[0145] 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.

[0146] 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).

[0147] 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.

[0148] Next, since the mobile devices A, B, and C are in a state where they can communicate with each other, they exchange information on the transaction data to be stored in the next block to be generated (S308). In the example shown in Fig. 11, the mobile devices A, B, and C confirm that the verified loan transaction data Trnt is included in the transaction data to be stored in the next block to be generated.

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

[0150] Next, each of the mobile devices A, B, and C transmits the block Blc(Trnt) generated in step S309 to the other mobile devices (S310). This allows each of the mobile devices A, B, and C to notify the other mobile devices of the successful verification of the validity of the lending transaction data Trnt included in the block Blc(Trnt).

[0151] 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 valid transaction data (i.e., validity), and agree on the validity 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 valid transaction data (i.e., validity), and the validity 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.

[0152] Next, mobile devices A, B, and C each link the agreed-upon block Blc (Trnt) in step S311 to the 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.

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

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

[0155] First, when the user who used the mobile object A returns the mobile object A, the mobile object 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 specified return facility, or by placing the mobile object A at a specified location and pressing a return button on the UI of the mobile object device 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 object device A may confirm that the mobile object A has been returned by receiving a message indicating that the mobile object A has been returned at the specified return facility or by the terminal A, or by pressing the return button on the UI of the mobile object device A.

[0156] 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). 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 confirmed 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.

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

[0158] Next, each of the mobile devices A, B, and C executes a verification algorithm for verifying the validity of the acquired return transaction data Trtn (S504).

[0159] Next, each of the mobile devices A, B, and C stores the verified return transaction data Trtn in a transaction pool by the verification algorithm executed in step S504 (S505). More specifically, the mobile device A stores the verified return transaction data Trtn in a transaction pool a, and the mobile device B stores the verified return transaction data Trtn in a transaction pool b. The mobile device C stores the verified return transaction data Trtn in a transaction pool c. Although not shown, the mobile devices A, B, and C are in a state where they can communicate with each other, so they exchange information on transaction data to be stored in a block to be generated next. In the example shown in FIG. 12, the mobile devices A, B, and C confirm that the verified return transaction data Trtn is included in the transaction data to be stored in a block to be generated next.

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

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

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

[0163] 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, blocks including the return transaction data Trtn are stored in all of ledger A, ledger B, and ledger C, and the completion of the return of mobile device A is recorded.

[0164] Next, each of the mobile devices A, B, and C checks the reservation information stored in the blockchain (S510). More specifically, each of the mobile devices A, B, and C executes the reservation smart contract by linking the block including the return transaction data Trtn to the blockchain in its own ledger, and verifies that the reservation transaction data Trsv exists as the reservation information stored in the blockchain.

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

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

[0167] 13 is a flowchart for explaining details of fee calculation processing in a system according to a comparative example. In the following, a case where the processing is performed by mobile device A will be explained as a representative example.

[0168] 8, first, the 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.

[0169] 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.

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

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

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

[0173] 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. A process for collecting the fee may be performed for the reservation for use of the mobile device A included in the reservation transaction data Trsv.

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

[0175] FIG. 14 is a flowchart showing an outline of normal processing of a system according to a second example of the comparative example. FIG. 14 shows an outline of normal processing for normally performing reservation processing, rental processing, and return processing for a mobile body A when the mobile body device A is offline while the mobile body devices B and C are online. FIGS. 15A to 17 are diagrams for conceptually explaining the block chain stored in the ledger A of the mobile body device A and the ledger B of the mobile body device B. FIG. 15A is a diagram conceptually showing the block chain stored in the ledger A by the operation of step S1A in FIG. 14. FIG. 15B is a diagram conceptually showing the block chain stored in the ledger A by the operation of step S3A in FIG. 14. FIG. 15C is a diagram conceptually showing the block chain stored in the ledger A by the operation of step S5A in FIG. 14. FIGS. 16 and 17 are diagrams conceptually explaining the block chain stored in the ledger A and the ledger B by the operation of step S6A in FIG. 14. In the following, 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.

[0176] As shown in FIG. 14, first, for example, terminal A communicates with mobile device A, which is not capable of communicating with other mobile devices B and C (offline), and performs reservation processing for mobile device A in which offline mobile device A is mounted (S1A). That is, terminal A performs reservation processing for locally reserving 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 not capable of communicating with mobile device B (offline), a block including reservation transaction data Trsv for reserving mobile device A is stored only in ledger A.

[0177] Next, for example, terminal A communicates with mobile body device A in an offline state and performs lending processing of mobile body A (S3A). That is, terminal A performs lending processing to locally lend mobile body A to offline mobile body device A. More specifically, terminal A communicates with mobile body device A and can transmit an unlocking request for mobile body A in order to use mobile body A. Then, mobile body device A unlocks mobile body A, and generates lending transaction data Trnt indicating that mobile body A is unlocked and lending of mobile body A has begun. In this case, for example, as shown in FIG. 15B, since mobile body device A is in an offline state, a block including lending transaction data Trnt indicating lending of mobile body A has begun is stored only in ledger A.

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

[0179] After that, it is assumed that the mobile device A returns to the online state. Then, when the mobile device A returns to the online state, the system performs a return process (S6A). More specifically, in steps S1A to S5A, as described above, the mobile device A is in a state in which communication with the mobile device B is not possible (offline). Therefore, as shown in (a) of FIG. 16, when the mobile device A returns to the online state, different blocks are linked to the blockchains of the ledgers A and B. Next, when the mobile device A returns to the online state, as shown in (b) of FIG. 16, the ledger A of the mobile device A and the ledger B of the mobile device B share different blockchains, and a fork occurs. Here, the block linked to the blockchain of the ledger A of the offline mobile device A corresponds to the side chain block, and the block linked to the blockchain of the ledger B of the online mobile device B corresponds to the main chain block. 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 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 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 at the timing of generating a new block.

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

[0181] Next, the details of the reservation process in step S1A, the rental process in step S3A, and the return process in step 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 body 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 wishes to use mobile body A uses terminal A to perform reservation process, rental process, and return process for mobile body device A mounted on mobile body A.

[0182] [Reservation process according to the second example of the comparative example] Fig. 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 will be omitted.

[0183] First, terminal A generates reservation transaction data Trsv for reserving the 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 A (S102).

[0184] 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. For this reason, mobile devices B and C do not obtain the reservation transaction data Trsv.

[0185] Next, the mobile device A executes a verification algorithm to verify the validity 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.

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

[0187] Next, mobile device A generates a 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 on transaction data to be stored in the next block to be generated with mobile devices B and C.

[0188] 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.

[0189] 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), thereby also agreeing on the validity of block Blc(Trsv). Note that the process of step S107 may be performed when mobile device A independently executes the consensus algorithm in step S109A.

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

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

[0192] [Lending process according to the second example of the comparative example] Fig. 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.

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

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

[0195] 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).

[0196] 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. For this reason, mobile devices B and C do not obtain the lending transaction data Trnt.

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

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

[0199] 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.

[0200] 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). This is because mobile device A is offline and cannot transmit the block Blc(Trnt) to mobile devices B and C.

[0201] 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), thereby also agreeing on the validity of block Blc(Trnt). Note that the process of step S309 may be performed when executing the consensus algorithm in step S311.

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

[0203] As a result, as shown in Fig. 15B, a block including 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 the following, this self-contained recording of the fact that lending of mobile entity A has begun in ledger A in an offline state is referred to as local lending.

[0204] [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 those in Fig. 12 are given the same reference numerals, and detailed description thereof will be omitted.

[0205] First, when the moving object A is returned by the user who used the moving object A, the moving object device A confirms that the moving object A has been returned (S501).

[0206] 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).

[0207] 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. For this reason, mobile devices B and C do not obtain the return transaction data Trtn.

[0208] Next, the mobile device A executes a verification algorithm to verify the validity of the obtained return transaction data Trtn (S504).

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

[0210] 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 on transaction data to be stored in the next block to be generated with mobile devices B and C.

[0211] 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.

[0212] 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), thereby also agreeing on the validity of block Blc(Trtn). Note that the process of step S506 may be performed when executing the consensus algorithm in step S508A.

[0213] 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. In this way, the self-contained recording of the completion of the return of mobile device A only in ledger A in an offline state is referred to as a local return below.

[0214] Next, the mobile device A checks the reservation information stored in the blockchain (S510). More specifically, the 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 the reservation information stored in the blockchain.

[0215] Mobile device A then executes a fee calculation algorithm (S511).

[0216] [Processing when communication is restored by 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.

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

[0218] 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). Since 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.

[0219] Then, mobile device A 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.

[0220] Next, the mobile devices A, B, and C perform a similarity / difference determination of the blockchains in each ledger (S603). More specifically, the mobile device A determines whether the blockchain in the ledger A is different from the blockchains in the ledger B and C of the other mobile devices, which are mobile devices B and C. The mobile devices B and C determine whether the blockchains in the ledger B and C are different from the blockchain in the ledger A of the other mobile device, which is mobile device A. Here, as shown in the example of FIG. 16(a), different blocks are linked to the blockchains in the ledger A and the ledger B and C, and the blockchain in the ledger A is different from the blockchains in the ledger B and C. For this reason, as shown in the example of FIG. 16(b), the mobile devices A, B, and C share different blockchains in the ledgers A, B, and C, and a fork occurs.

[0221] Next, mobile devices A, B, and C transmit information about blocks that correspond to side chain blocks and main chain blocks to each other (S604, S605). 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 the side chain block. The block linked to the blockchain of ledgers B and C of mobile devices B and C corresponds to the main chain block.

[0222] 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.

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

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

[0225] 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).

[0226] 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.

[0227] 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, the lending transaction data Trnt, and the return transaction data Trtn is stored, and the local reservation, local lending, and local return of mobile device A are recorded.

[0228] Next, the mobile device A checks the reservation information stored in the blockchain (S620). More specifically, each of the mobile devices A, B, and C executes the reservation smart contract by linking the block including the return transaction data Trtn to the blockchain in its own ledger, and verifies that the reservation transaction data Trsv exists as the reservation information stored in the blockchain.

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

[0230] [Block connection process according to a comparative example] Next, we will explain a comparative example of a block linking process that links blocks generated in a blockchain.

[0231] 22 is a flowchart for explaining block connection processing in 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 example.

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

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

[0234] 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.

[0235] In step S1004, if there is a trigger (Yes in S1004), mobile device A checks whether communication with other mobile devices is possible (S1005). In step S1004, if there is no trigger (No in S1004), the process is repeated from step S1001.

[0236] 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 block of a blockchain 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.

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

[0238] 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 execute the consensus algorithm to reach a consensus on the generated block.

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

[0240] 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).

[0241] On the other hand, in step S1009, if they are not the same (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).

[0242] Next, mobile device A updates the blockchain of ledger A to be the same as the blockchain in the ledgers of other mobile devices (S1012).

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

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

[0245] FIG. 23 is a flowchart showing an outline of the operation of the fraudulent processing of the system according to the third example of the comparative example. FIGS. 24A to 27 are diagrams for conceptually explaining the block chain stored in the ledger A of the mobile body device A and the ledger B of the mobile body device B. FIG. 24A is a diagram conceptually showing the block chain stored in the ledger A by the operation of step S10 in FIG. 23. FIG. 24B is a diagram conceptually showing the block chain stored in the ledger A by the operation of step S11 in FIG. 23. FIG. 24C is a diagram conceptually showing the block chain stored in the ledger A by the operation of step S12 in FIG. 23. FIGS. 25 and 26 are diagrams for conceptually explaining the block chain stored in the ledger A and the ledger B by the operation of step S13 in FIG. 23. FIG. 27 is a diagram conceptually showing the block chain stored in the ledger A and the ledger B by the operation of step S14 in FIG. 23. In the following, it is assumed that a user who wants to use the mobile body A uses the terminal A to perform fraudulent processing on the mobile body device A mounted on the mobile body A.

[0246] As shown in Fig. 23, first, for example, terminal A performs a reservation process for mobile body A on which mobile body device 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, a block including reservation transaction data TrsvA for reserving the use of mobile body A is stored only in ledger A.

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

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

[0249] Next, the user returns mobile device A to an online state. Then, when mobile device A returns to an online state, a return process is performed in the system (S13).

[0250] More specifically, in steps S10 to S12, as described above, since the mobile device A is in an offline state, different blocks are linked to the blockchains of ledgers A and B when the mobile device A returns to an online state, as shown in (a) of FIG. 25. Next, when the mobile device A returns to an online state, as shown in (b) of FIG. 25, the ledger A of the mobile device A and the ledger B of the mobile device B share different blockchains, resulting in a fork. Here, the block linked to the blockchain of the ledger A of the offline mobile device A corresponds to the side chain block, and the block linked to the blockchain of the ledger B of the online mobile device B corresponds to the main chain block. For this reason, as shown in (a) and (b) of FIG. 26, in the ledger A of the mobile device A and the ledger B of the mobile device B, the side chain block is deleted, and the transaction data included in the side chain block is stored in the transaction pool, thereby resolving the fork. In addition, in (b) of Fig. 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 Fig. 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.

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

[0252] Next, the mobile device A etc. performs fee calculation processing (S15). The fee calculation processing in step S15 is the same as the fee calculation processing in step S7, so a description thereof will be omitted. The reservation transaction data TrsvA and the reservation transaction data TrsvB are in conflict with each other, and the block including the reservation transaction data TrsvA is linked chronologically 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, and therefore, fraud of not paying the fee for using the mobile device A in the reservation corresponding to the reservation transaction data TrsvA is established.

[0253] 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 sequence diagrams.

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

[0255] First, terminal A generates reservation transaction data TrsvA for reserving the 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 A (S102B).

[0256] 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). This is because mobile device A is offline and cannot transfer the reservation transaction data TrsvA to mobile devices B and C.

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

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

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

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

[0261] 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.

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

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

[0264] 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.

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

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

[0267] Next, since mobile device B is online, when it receives 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, except for mobile device A, acquires the reservation transaction data TrsvB.

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

[0269] 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.

[0270] Next, since mobile devices B and C are in a state where they can communicate with each other, they exchange information on 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 verified reservation transaction data TrsvB is included in the transaction data to be stored in the next block to be generated.

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

[0272] 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 a report that the validity of the reservation transaction data TrsvB included in block Blc(TrsvB) has been successfully verified.

[0273] 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 in steps S107C and S108C may be performed when executing the consensus algorithm in step S109C.

[0274] 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.

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

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

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

[0278] 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).

[0279] 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).

[0280] 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.

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

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

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

[0284] Next, mobile device A attempts to transmit the 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 the block Blc(TrntA) to mobile devices B and C.

[0285] 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 process of step S309B may be performed when executing the consensus algorithm in step S311B.

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

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

[0288] [Processing when communication is restored by 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.

[0289] 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. Elements similar to those in Fig. 21 are given similar reference numerals, and detailed description thereof will be omitted.

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

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

[0292] Next, the mobile device A, B, and C perform a difference / similar determination of the blockchains in each ledger (S603B). More specifically, the mobile device A determines whether the blockchain in the ledger A is different from the blockchains in the ledger B and C of the other mobile device, the mobile device B and C. The mobile device B and C determine whether the blockchains in the ledger B and C are different from the blockchain in the ledger A of the other mobile device, the mobile device A. Here, as shown in the example of FIG. 25(a), different blocks are linked to the blockchains in the ledger A and the ledger B and C, and the blockchain in the ledger A is different from the blockchains in the ledger B and C. For this reason, as shown in the example of FIG. 25(b), the mobile device A, B, and C share different blockchains in the ledgers A, B, and C, and a fork occurs.

[0293] Next, mobile devices A, B, and C transmit information about blocks corresponding to side chain blocks and main chain blocks to each other (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).

[0294] Next, mobile devices A, B, and C each store the reservation transaction data TrsvA and the 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.

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

[0296] 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).

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

[0298] 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 in steps S614B and S615B may be performed when executing the consensus algorithm in step S616B.

[0299] 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 the reservation transaction data TrsvA, the reservation transaction data TrsvB, and the lending transaction data TrntA is stored, and the local reservation, the competing reservation, and the local lending of mobile device A are recorded.

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

[0301] Fig. 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.

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

[0303] 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).

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

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

[0306] Next, each of the mobile devices A, B, and C stores the verified return transaction data TrtnA in the transaction pool by the verification algorithm executed in step S504B (S505B). More specifically, the mobile device A stores the verified return transaction data TrtnA in the transaction pool a, and the mobile device B stores the verified return transaction data TrtnA in the transaction pool b. The mobile device C stores the verified return transaction data TrtnA in the transaction pool c. Although not shown, the mobile devices A, B, and C are in a state where they can communicate with each other, so they exchange information on transaction data to be stored in the next block to be generated. In the example shown in FIG. 32, the 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.

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

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

[0309] 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 in steps S506B and S507B may be performed when executing the consensus algorithm in step S508B.

[0310] Next, mobile device 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, blocks including the return transaction data TrtnA are stored in all of ledger A, ledger B, and ledger C, and the completion of the return of mobile device A is recorded.

[0311] Next, each of the mobile devices A, B, and C checks the reservation information stored in the blockchain (S510B). More specifically, each of the mobile devices A, B, and C executes the reservation smart contract by linking a block including the block including the return transaction data TrtnA to the blockchain in its own ledger, and verifies that the reservation transaction data Trsv exists as the reservation information stored in the blockchain.

[0312] Next, each of the mobile devices A, B, and C executes a fee calculation algorithm (S511B). Here, for example, as shown in Fig. 27, the reservation transaction data TrsvA and the reservation transaction data TrsvB compete with each other, and the block including the reservation transaction data TrsvA is linked chronologically after the block including 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 is not collected, and only the fee for the reservation corresponding to the reservation transaction data TrsvB is collected.

[0313] In this way, since the fee for the reservation corresponding to the reservation transaction data TrsvA is not collected, the fraud of not paying the fee for using mobile unit A in the reservation corresponding to the reservation transaction data TrsvA is established.

[0314] [Fourth Comparative Example] In the third comparative example, the fraudulent processing in the case where the return process is performed after the mobile device A is restored to the online state has been described, but this is not limited to the above. When the mobile device A is in an offline state, the mobile device A may be restored to the online state after the return process is performed. The fraudulent processing in this case will be described below as a fourth comparative example.

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

[0316] 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.

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

[0318] Next, the user returns the mobile device A to the online state. Then, when the mobile device A returns to the online state, the system performs a return process (S14A). More specifically, since the mobile device A is in the offline state in steps S10 to S13A, when the mobile device A returns to the online state, different blocks are linked to the blockchains of the ledgers A and B, for example, as shown in FIG. 34D. Next, when the mobile device A returns to the online state, as shown in FIG. 35, the ledger A of the mobile device A and the ledger B of the mobile device B share different blockchains, and a fork occurs. Here, the block linked to the blockchain of the ledger A of the offline mobile device A is shorter and therefore corresponds to a side chain block, and the block linked to the blockchain of the ledger B of the 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. After that, 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 at the timing of generating a new block.

[0319] Next, the mobile device A etc. performs fee calculation processing (S15). As in the third example of the comparative example, the reservation transaction data TrsvA and the reservation transaction data TrsvB conflict with each other, 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, and therefore, fraud occurs in which the fee for using the mobile device A for the reservation corresponding to the reservation transaction data TrsvA is not paid.

[0320] 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.

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

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

[0323] 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).

[0324] 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.

[0325] Next, mobile device A executes a verification algorithm to verify the validity of the obtained return transaction data TrtnA (S504C).

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

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

[0328] Next, mobile device A attempts to transmit the 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 the block Blc(TrtnA) to mobile devices B and C.

[0329] 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 process of step S506C may be performed when executing the consensus algorithm in step S508C.

[0330] 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.

[0331] 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.

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

[0333] [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.

[0334] 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. Elements similar to those in Fig. 21 are given similar reference numerals, and detailed description thereof will be omitted.

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

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

[0337] Next, mobile devices A, B, and C perform a determination of whether the blockchains in each ledger are the same or different (S603C). Before mobile device A resumes communication, for example, as shown in the example of FIG. 34D, different blocks are linked to the blockchains in ledger A and ledgers B and C, so the blockchains in ledger A are different from the blockchains in ledgers B and C. For this reason, when mobile device A resumes communication, for example, as shown in the example of FIG. 35, the ledgers A, B, and C of mobile devices A, B, and C share different blockchains, so a fork occurs.

[0338] Next, mobile devices A, B, and C transmit information about blocks corresponding to side chain blocks and main chain blocks to each other (S604C, S605C). 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, TrtnA). On the other hand, the block linked to the blockchain of ledgers B and C of mobile devices B and C corresponds to main chain block Blc (TrsvB).

[0339] 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).

[0340] 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 by deleting the side chain blocks that were linked to the blockchain and leaving the main chain blocks, so that the blockchains of ledgers A, B, and C are identical.

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

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

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

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

[0345] Next, the mobile device A checks the reservation information stored in the blockchain (S620C). More specifically, each of the mobile devices A, B, and C executes the reservation smart contract by linking the block including the return transaction data TrtnA to the blockchain in its own ledger, and verifies that the reservation transaction data TrsvA and the reservation transaction data TrsvB exist as reservation information stored in the blockchain.

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

[0347] Here, for example, as shown in (c) of Fig. 36, a conflict occurs between a reservation corresponding to the reservation transaction data TrsvA and a reservation corresponding to the reservation transaction data TrsvB. Also, the block including the reservation transaction data TrsvA is linked after the block including 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 is not collected, and only the fee for the reservation corresponding to the reservation transaction data TrsvB is collected.

[0348] In this way, since the fee for the reservation corresponding to the reservation transaction data TrsvA is not collected, the fraud of not paying the fee for using mobile unit A in the reservation corresponding to the reservation transaction data TrsvA is established.

[0349] [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.

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

[0351] Therefore, in this embodiment, the processing of the local reservation in step S10 is not completed. If the processing of the local reservation is not completed, the mobile object A cannot be rented out by local reservation and the mobile object A cannot be used. In other words, by suppressing the processing that leads to the fraudulent use of the mobile object A, which is the object of the service, it is possible to suppress the fraudulent use of the object of the service that abuses the blockchain.

[0352] The following describes the process of not completing a local reservation as an anti-fraud measure.

[0353] Fig. 39 is a sequence diagram showing processing for local reservation disabling in the system according to the embodiment. The same elements as those in Fig. 28 are given the same reference numerals, and detailed explanations are omitted. Below, a case where the processing for local reservation is performed by mobile device A as a representative will be described.

[0354] First, terminal A generates reservation transaction data TrsvA for reserving the use of mobile body A based on the operation of a user who wishes to use mobile body A (S101D), and transmits the generated reservation transaction data TrsvA to mobile body A (S102D).

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

[0356] Next, mobile device A executes a verification algorithm to verify the validity of the acquired reservation transaction data TrsvA (S104D).

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

[0358] Next, mobile device A executes a block generation determination algorithm, which is an anti-fraud process according to this embodiment (S1071). Specifically, mobile device A executes the block generation determination algorithm, which determines whether the number of other mobile devices with which it can communicate among multiple other mobile devices exceeds a predetermined value, and permits block generation only if the number of other mobile devices with which it can communicate exceeds the predetermined value. This is because when the number of other mobile devices with which it can communicate exceeds the predetermined value, it can be considered that mobile device A has returned to an online state. Here, if the number of other mobile devices with which it can communicate is equal to or less than the predetermined value, this reservation process, i.e., the local reservation process, is terminated.

[0359] Next, if block generation is permitted as a result of execution of the block generation determination algorithm, mobile device A generates block Blc(TrsvA) including verified reservation transaction data TrsvA (S107D).

[0360] The subsequent processing is the same as that described with reference to FIG. 28, and therefore will not be described again.

[0361] In this way, if communication with more than a predetermined number of other mobile devices is not possible, a block including the acquired reservation transaction data TrsvA is not generated. This makes it possible to prevent a block including the reservation transaction data TrsvA for reserving the use of mobile device A from being stored only in ledger A, thereby preventing a local reservation from being confirmed.

[0362] Next, the flow of the block generation determination process performed by executing the block generation determination algorithm will be described.

[0363] 40 is a flowchart showing an example of the block generation determination process according to the embodiment. In the following, the case where the block generation determination process is performed by mobile device A will be described as an example.

[0364] As shown in Fig. 40, first, mobile device A transmits transaction data to another mobile device (S10711). The transaction data to be transmitted may be reservation transaction data TrsvA, or may be other transaction data. Moreover, the data transmitted to the other mobile device is not limited to transaction data, and may be a signal such as ack that requests a reply.

[0365] Next, mobile device A determines whether the number of other mobile devices with which it can communicate exceeds a predetermined value (S10712).

[0366] In step S10712, if the number of other mobile devices with which communication is possible exceeds a predetermined value (Yes in S10712), mobile device A selects transaction data from transaction pool a and generates a block (S10713). More specifically, mobile device A selects reservation transaction data TrsvA from transaction pool a and generates a block. Note that, when executed in step S1071 of FIG. 39, in step S10713, block generation may simply be permitted, and the process may proceed to step S107D, or the process of step S107D may be performed by step S1071.

[0367] 41 is a flowchart showing another example of the block generation determination process according to the embodiment. In the following, the case where the block generation determination process is performed by mobile device A will be described as an example.

[0368] As shown in Fig. 41, first, mobile device A generates transaction data (S10714). The generated transaction data may be reservation transaction data TrsvA or other transaction data. In addition to transaction data, a signal requesting a reply such as ack may be generated.

[0369] Next, mobile device A transmits the transaction data to the other mobile devices (S10715). In this example, if mobile device A is in a state where it can communicate with the other mobile devices (online), it transmits transaction data to each other.

[0370] Next, mobile device A determines whether transaction data has been received from the number of other mobile devices that exceeds a predetermined number (S10716).

[0371] In step S10716, if transaction data is received from more than a predetermined number of other mobile devices (Yes in S10716), mobile device A selects transaction data from transaction pool a and generates a block (S10717). More specifically, mobile device A selects reservation transaction data TrsvA from transaction pool a and generates a block. Note that, when executed in step S1071 of FIG. 39, step S10717 may simply permit block generation and proceed to step S107D, or step S10717 may perform the processing of step S107D.

[0372] Finally, the block connection process according to the embodiment will be described.

[0373] Fig. 42 is a flowchart for explaining the block connection process of the system according to the embodiment. The same elements as those in Fig. 22 are given the same reference numerals, and detailed explanations are omitted. Below, the case where the block connection process is performed by the mobile body device A will be explained as a representative.

[0374] In the block connection processing shown in Fig. 42, step S1005D is added to the block connection processing shown in Fig. 22, and steps S1005 to S1007 of the block connection processing shown in Fig. 22 are deleted. That is, steps S1001 to S1004 and steps S1008 to S1013 shown in Fig. 42 are the same as those described in the block connection processing shown in Fig. 22, and therefore description thereof will be omitted here.

[0375] In step S1004, when a trigger has been generated (Yes in S1004), mobile device A determines whether or not block generation is permitted (step S1005D). Note that detailed processing of step S1005D is shown in Figures 40 and 41. Since the processing shown in Figures 40 and 41 has been described above, detailed processing of step S1005D will also not be described.

[0376] In step S1005D, if block generation is permitted (OK in step S1005D), proceed to step S1008. In step S1005D, if block generation is not permitted (NG in step S1005D), the process of step S1005D may be performed again. In this case, the transaction data will continue to be transmitted as a signal to multiple other mobile devices at a predetermined interval until the number of other mobile devices with which communication is possible exceeds a predetermined value.

[0377] [Effects, etc.] As described above, according to this embodiment, for example, a first node, which is a mobile body device A, cannot generate a block including reservation transaction data for using the mobile body A unless it can communicate with a predetermined number of other second nodes, which are mobile body devices. As a result, even if the first node is made unable to communicate with the second node, a block including reservation transaction data is not stored only in ledger A, so that the mobile body A cannot be rented out. Therefore, it is possible to prevent the very use of the mobile body that could lead to unauthorized use of the mobile body in the sharing service. Therefore, unauthorized use of the mobile body A through the misuse of the blockchain can be suppressed.

[0378] As described above, the mobile object A is an example of a service target, and the reservation for use of the mobile object A is an example of a contract for a service target. The processing after the fraud countermeasure is similar for a contract for a service target other than the reservation for use of the mobile object A. That is, by performing the block generation determination processing, if communication with more than a predetermined number of second nodes is not possible, a block including the acquired first transaction data is not generated. This makes it possible to suppress processing that leads to fraudulent use of the service target, such as making the first node unable to communicate with the second node and storing a block including the first transaction data only in the first distributed ledger. Therefore, it is possible to suppress fraudulent use of the service target by misusing the blockchain.

[0379] [Other embodiments, etc.] As described above, the present disclosure has been described based on the above-mentioned embodiment, but the present disclosure is not limited to the above-mentioned embodiment. The following cases are also included in the present disclosure.

[0380] (1) In the above embodiment, a mobile object is used as an example of the service target, but the present invention is not limited to this. The service target may be, for example, a hotel room or an electronic locker, as long as it is locked so that other users cannot use it when the service is not being used and is unlocked when the service is used. In addition, the contract is not limited to a reservation for use of the mobile object 10, but may be, for example, a reservation for use of a hotel room or an electronic locker.

[0381] (2) Each device in the above embodiments is specifically a computer system composed of a microprocessor, a ROM, a RAM, a hard disk unit, a display unit, a keyboard, a mouse, etc. A computer program is recorded in the RAM or the 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 for a computer to achieve a specified function.

[0382] (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). The system LSI is a super multi-function LSI manufactured by integrating multiple components on a single chip, and specifically, is a computer system including a microprocessor, ROM, RAM, etc. A computer program is recorded in the RAM. The system LSI achieves its functions by the microprocessor operating in accordance with the computer program.

[0383] Furthermore, each of the components constituting each of the above devices may be implemented as a single chip, or some or all of the components may be included in a single chip.

[0384] In addition, although we have referred to it as a system LSI here, it may also be called an IC, LSI, super LSI, or ultra LSI depending on the degree of integration. Also, the method of integration is not limited to LSI, but may be realized by a dedicated circuit or a general-purpose processor. It is also possible to use an FPGA (Field Programmable Gate Array) that can be programmed after the LSI is manufactured, or a reconfigurable processor that can reconfigure the connections and settings of the circuit cells inside the LSI.

[0385] Furthermore, if an integrated circuit technology that can replace LSI appears due to the progress of semiconductor technology or a different derived technology, it is natural that such technology may be used to integrate the functional blocks. The application of biotechnology, etc. is also a possibility.

[0386] (4) Some or all of the components constituting each of the above devices may be composed of an IC card or a standalone module that is detachable from each device. The IC card or the module is a computer system composed of a microprocessor, ROM, RAM, etc. The IC card or the module may include the above-mentioned ultra-multifunction LSI. The microprocessor operates according to a computer program, causing the IC card or the module to achieve its functions. The IC card or the module may be tamper-resistant.

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

[0388] Furthermore, the present disclosure may 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. Also, the present disclosure may be a digital signal recorded on such a recording medium.

[0389] 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.

[0390] The present disclosure may also provide 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.

[0391] In addition, the program or the digital signal may 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, etc.

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

[0393] The present disclosure can be used for a control method, a control device, and a program, and can be used for a control method, a control device, and a program that can prevent fraudulent use without paying the fee when a user enters into a contract for the use of a mobile object such as a sharing service for a mobile object such as a bicycle or a motorcycle. [Explanation of symbols]

[0394] 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 Department 104 Block Generation Unit 105 Synchronization section 106 Smart Contract Execution Department 107 Blockchain Management Department 108 Distributed Ledger Storage Unit 109 Status 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: Obtaining first transaction data; determining whether a number of second nodes that can communicate among the plurality of second nodes exceeds a predetermined value; generating a first block including the first transaction data only if the number of the second nodes with which communication is possible exceeds a predetermined value; When determining whether the predetermined value is exceeded, Transmitting a signal to the plurality of second nodes requesting a reply; determining that the second node that has received a reply to the signal is capable of communication; determining whether the number of the second nodes with which communication is possible exceeds a predetermined value based on whether the number of the second nodes from which replies to the signal have been obtained exceeds the predetermined value; Control methods.

2. the signal is the first transaction data; When determining whether the predetermined value is exceeded, transmitting the first transaction data as the signal to the second nodes at a predetermined interval when the number of the second nodes with which communication is possible is equal to or less than the predetermined value; The control method according to claim 1 .

3. When acquiring the first transaction data, the first transaction data is acquired by receiving the first transaction data from at least one second node among the plurality of second nodes; When determining whether the predetermined value is exceeded, determining whether the predetermined value is exceeded based on whether the first transaction data is received from a number of second nodes that exceeds the predetermined value among the plurality of second nodes; The control method according to claim 1 .

4. Furthermore, the generated first block is transmitted to a number of the second nodes that exceeds the predetermined value; Executing a consensus algorithm with the second nodes that exceed the predetermined value, and storing the first block in the first blockchain; The control method according to any one of claims 1 to 3.

5. The first transaction data includes information regarding a first contract for using the service object. The control method according to any one of claims 1 to 4.

6. moreover, When the first transaction data is stored in the first blockchain, the service target corresponding to the first contract is utilized. The control method according to claim 5.

7. The system is used for a service for sharing a plurality of moving objects, the service targets are the plurality of moving objects, the first transaction data is reservation transaction data for a user to make a reservation for using a first mobile object via the first node, and includes 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 any one of claims 1 to 6.

8. moreover, the first node receives a request to unlock the first moving body from the user as a request to start using the first moving body; 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, permitting the user to unlock the first mobile object during the time period, and generating the first transaction data; The control method according to claim 7.

9. moreover, acquiring rental transaction data indicating that the first moving object has been rented to the user, the rental transaction data including an ID of the user, the reservation number, and a timestamp of the time when the first moving 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 an ID of the user, 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 moving object from the ID of the user included in the reservation transaction data; 9. The control method according to claim 7 or 8.

10. A control device in a system used for utilizing a service target, the control device including: 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 obtains first transaction data; determining whether a number of other control devices with which communication can be performed among the plurality of other control devices exceeds a predetermined value; generating a first block including the first transaction data only when the number of the other control devices capable of communicating with the first control device exceeds a predetermined value; When determining whether the predetermined value is exceeded, Transmitting a signal to the other control devices requesting a reply; determining that the other control device that has received a reply to the signal is capable of communication; determining whether the number of the other control devices capable of communication exceeds a predetermined value based on whether the number of the other control devices from which replies to the signal have been obtained exceeds the predetermined value; 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 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: Obtaining first transaction data; determining whether a number of second nodes that can communicate among the plurality of second nodes exceeds a predetermined value; generating a first block including the first transaction data only if the number of the second nodes with which communication is possible exceeds a predetermined value; When determining whether the predetermined value is exceeded, Transmitting a signal to the plurality of second nodes requesting a reply; determining that the second node that has received a reply to the signal is capable of communication; determining whether the number of the second nodes with which communication is possible exceeds a predetermined value based on whether the number of the second nodes from which replies to the signal have been obtained exceeds the predetermined value; A program for a computer to execute.

Images