server

Abstract

To avoid the situation where an improper storage record of an object is registered in a distributed ledger when the object is stored by an administrator different from the owner of the object.SOLUTION: A server 10 communicates with a holder terminal 40, which is a terminal device of a holder of an NFT 605. The NFT 605 is associated with a vehicle 30. The vehicle 30 is stored by a dealer DLR. The server 10 includes a communication device 110 and a processing device 115. The communication device 110 obtains a monitoring record of the condition of the vehicle 30, created by a monitoring device that monitors the condition of the vehicle 30 while the vehicle 30 is in storage. The processing device 115 generates transaction data triggered by receipt of a generation request to generate transaction data including the monitoring record. The processing device 115 generates the transaction data triggered by receipt of the generation request from the holder terminal 40.SELECTED DRAWING: Figure 1

Description

[Technical Field]

[0001] The present disclosure relates to a server. [Background technology]

[0002] Japanese Patent Application Laid-Open Publication No. 2020-027592 (Patent Document 1) discloses a system for managing rights information related to assets on a blockchain. The system includes first and second computer systems. The first computer system manages the rights information using blockchain technology. The second computer system converts the rights information into tokens. Holders of the tokens can own the assets corresponding to the tokens. [Prior art documents] [Patent documents]

[0003] [Patent Document 1] Japanese Patent Publication No. 2020-027592 Summary of the Invention [Problem to be solved by the invention]

[0004] Non-fungible tokens (NFTs) are attracting attention as an example of tokens issued using distributed ledger technologies such as blockchain technology. NFTs are extremely difficult to counterfeit or tamper with. NFTs can be linked to objects and used as certificates to prove the right to own or use the object.

[0005] An object may not be stored by its owner, but by a different administrator. This administrator is expected to properly store (e.g., maintain) the object and properly create a storage record of the object. If such a storage record is registered in a distributed ledger, users who can access the distributed ledger can verify the storage record. However, there is a possibility that the administrator may create (e.g., forge) a storage record improperly and register this storage record in the distributed ledger.

[0006] The present disclosure has been made to solve the above-mentioned problems, and its purpose is to prevent a situation in which an improper storage record of an object is registered in a distributed ledger when the object is stored by a manager other than its owner. [Means for solving the problem]

[0007] The server of the present disclosure is configured to communicate with a holder terminal, which is a terminal device of a holder of a non-fungible token issued using distributed ledger technology. The non-fungible token is linked to an object. The object is stored by an administrator who manages the object. The server includes a communication device and a processing device. The communication device is configured to acquire a monitoring record of the state of the object created by a monitoring device that monitors the state of the object while it is being stored. The processing device generates transaction data triggered by receiving a generation request to generate transaction data including the monitoring record. The processing device generates transaction data triggered by receiving the generation request from the holder terminal.

[0008] With the above configuration, transaction data is generated at a timing preferred by the holder, and therefore at a timing not predicted by the administrator. This prompts the administrator to properly store (e.g., maintain) the object so that the monitoring record is determined to be appropriate regardless of the timing of the generation request. As a result, the administrator can be made to store the object appropriately. In addition, with the above configuration, the monitoring record is objectively created by the monitoring device and then registered as an archived record in the distributed ledger. As a result, it is possible to prevent a situation in which an administrator creates an inappropriate archived record and such an archived record is registered in the distributed ledger.

[0009] The processing device may be further configured to generate the transaction data when triggered by receiving a generation request from an administrator terminal, which is a terminal device of the administrator.

[0010] With the above configuration, transaction data is generated triggered by the receipt of a generation request from the owner terminal and the receipt of a generation request from the administrator terminal. This increases the frequency with which transaction data is generated. As a result, the granularity of monitoring records can be increased. Furthermore, convenience for administrators can be improved.

[0011] The processing device may be further configured to generate the transaction data again when a predetermined time has elapsed since the previous generation of the transaction data.

[0012] With the above configuration, transaction data is generated triggered by receiving a generation request from the owner terminal and by the passage of a predetermined time. This increases the frequency with which transaction data is generated. As a result, the granularity of monitoring records can be increased. Furthermore, since monitoring records can be created without using the owner terminal, convenience for the owner can be improved.

[0013] Receipt of the generation request may trigger the communication device to acquire the monitoring records, and the processing device to generate the transaction data so that the transaction data includes the acquired monitoring records.

[0014] With the above configuration, both the acquisition of monitoring records and the generation of transaction data are executed in response to the receipt of a generation request, thereby enabling the transaction data to be generated immediately.

[0015] The server may further include a storage device that stores the monitoring records acquired by the communication device. Triggered by receiving the generation request, the processing device may generate transaction data such that the transaction data includes the monitoring records stored in the storage device.

[0016] With the above configuration, after the monitoring record is temporarily stored in the storage device, the generation of transaction data including this monitoring record is triggered by the reception of a generation request. As a result, even if it is difficult to immediately obtain the monitoring record from the monitoring device when the generation request is received (for example, if communication between the monitoring device and the communication device is interrupted), the transaction data can be immediately generated based on the monitoring record stored in the storage device. [Effects of the Invention]

[0017] According to the present disclosure, when an object is stored by an administrator other than its owner, it is possible to prevent an improper storage record of the object from being registered in a distributed ledger. [Brief explanation of the drawings]

[0018] [Figure 1] FIG. 1 is a diagram schematically illustrating a configuration of an information processing system according to an embodiment. [Figure 2]FIG. 1 is a diagram illustrating an example of a configuration of a monitoring system according to an embodiment. [Figure 3] 10 is a flowchart illustrating a process executed by a server according to an embodiment. [Figure 4] 10 is a flowchart illustrating a process executed by a server according to a first modification. [Figure 5] 10 is a flowchart illustrating a process executed by a server according to a second modification. [Figure 6] 13 is a flowchart illustrating a process executed by a server according to a third modification. DETAILED DESCRIPTION OF THE INVENTION

[0019] Hereinafter, embodiments of the present disclosure will be described in detail with reference to the drawings. The same or corresponding parts in the drawings are designated by the same reference numerals, and description thereof will not be repeated. In the embodiments, as an example, the object is a vehicle.

[0020] Fig. 1 is a diagram schematically illustrating a configuration of an information processing system according to an embodiment. Referring to Fig. 1, information processing system 1 includes a server 10, an administrator terminal 25, a vehicle 30, and an owner terminal 40. Information processing system 1 further includes a public blockchain network 60 (more specifically, a plurality of nodes thereof, not shown) and a private blockchain network 70 (more specifically, a plurality of nodes thereof, not shown).

[0021] Hereinafter, the public blockchain network 60 and the private blockchain network 70 will be referred to as PBB-NW60 and PRB-NW70, respectively.

[0022] The server 10 is operated by the operator ENT. The server 10 includes a storage device 105, a communication device 110, and a processing device 115.

[0023] The storage device 105 stores programs and data executed by the processing device 115. The storage device 105 further holds a distributed ledger that records the history of transactions in the PBB-NW 60 and a distributed ledger that records the history of transactions in the PRB-NW 70. This allows the server 10 to function as a node of the PBB-NW 60 and a node of the PRB-NW 70.

[0024] The communication device 110 communicates with external devices of the server 10, such as the administrator terminal 25, the owner terminal 40, each node of the PBB-NW 60, or each node of the PRB-NW 70.

[0025] The processing device 115 includes a central processing unit (CPU) and a memory (neither of which is shown). The memory includes a read-only memory (ROM) and a random access memory (RAM).

[0026] The processing device 115 executes various processes according to the programs and data stored in the storage device 105. The processing device 115 generates transaction data (TX data) including, for example, monitoring records (described later) of the vehicle 30. The processing device 115 transmits the TX data to the PRB-NW 70 via the communication device 110. Transmitting the TX data to the PRB-NW 70 corresponds to broadcasting the TX data to each node of the PRB-NW 70. After broadcasting, the TX data is propagated to the other nodes of the PRB-NW 70, where it is incorporated and acknowledged.

[0027] The manager terminal 25 is an example of a terminal device of the dealer DLR, and is carried by an employee EMP of the dealer DLR. The dealer DLR manages the vehicle 30 and stores it in its garage (not shown). The employee EMP is expected to properly store (e.g., maintain) the vehicle 30 and properly create a storage record of the vehicle 30.

[0028] The owner terminal 40 includes an HMI device 410 and a communication device 460. The HMI device 410 receives input of a user operation by the owner HLD. The owner HLD is the owner of the NFT 605 (described later). The user operation includes an operation to instruct the PRB-NW 70 to register the storage record of the vehicle 30 (registration instruction operation).

[0029] The communication device 460 communicates with devices external to the owner terminal 40, such as the server 10, each node of the PBB-NW 60, and each node of the PRB-NW 70.

[0030] The PBB-NW60 is a distributed ledger network that can be accessed by each of the server 10, the administrator terminal 25, and the owner terminal 40. Each of the server 10, the administrator terminal 25, and the owner terminal 40 can check the distributed ledger stored in the node of the PBB-NW60 by referring to it.

[0031] The NFT 605 is issued on the PBB-NW 60 using distributed ledger technology. The NFT 605 is linked to the vehicle 30 and is used as a certificate to prove the authority to own or use the vehicle 30. The holder HLD is the owner or user of the vehicle 30 who has the authority to own or use the vehicle 30 based on the NFT 605. "Using the vehicle 30" may mean that the owner of the vehicle 30 uses the vehicle 30, or may mean that a person other than the owner of the vehicle 30 temporarily uses (e.g., rents) the vehicle 30.

[0032] Like the PBB-NW60, the PRB-NW70 is a distributed ledger network accessible by each of the server 10, the administrator terminal 25, and the owner terminal 40. Each of the server 10, the administrator terminal 25, and the owner terminal 40 can check the distributed ledger stored in the node of the PRB-NW70. The PRB-NW70 is operated by the operator ENT.

[0033] 2 is a diagram illustrating an example of the configuration of a monitoring system according to an embodiment. Referring to FIG. 2, the monitoring system 5 includes a vehicle 30, a monitoring unit 345, and a server 10.

[0034] The vehicle 30 includes a GPS receiver 305, an on-board camera 315, a communication device 320, an engine 322, a group of sensors 325, a battery 327, an odometer 330, and an ECU (Electronic Control Unit) 335.

[0035] The GPS receiver 305 monitors the current location of the vehicle 30 by acquiring location information of the vehicle 30. The monitoring results (location information) of the GPS receiver 305 can be used to ensure that the vehicle 30 is stored in the garage of the dealer DLR.

[0036] The on-board camera 315 captures images of the surroundings of the vehicle 30. The images captured by the on-board camera 315 are also referred to as "first images." The first images are used to ensure that the vehicle 30 is not struck by an external object while being driven outside the DLR dealer's garage. The first images may be either still images or video images. The communication device 320 is configured to communicate with the server 10.

[0037] The sensor group 325 includes a voltage sensor 325A, an air pressure sensor 325B, an oil level sensor 325C, and a viscosity sensor 325D. The voltage sensor 325A, the air pressure sensor 325B, the oil level sensor 325C, and the viscosity sensor 325D monitor (measure) the voltage of the battery 327, the air pressure of the tires of the vehicle 30, the amount of oil remaining for the engine 322, and the viscosity of the oil, respectively. In this way, the sensor group 325 monitors the state of the vehicle 30 (in this example, the measurement target) and creates a monitoring record of the state of the vehicle 30. The sensor group 325 is an example of a "monitoring device" of the present disclosure.

[0038] The battery 327 stores power for running the vehicle 30. The odometer 330 monitors (measures) the distance traveled by the vehicle 30 based on the number of tire rotations of the vehicle 30. The monitoring results (measurements) of the odometer 330 can be used to ensure that the vehicle 30 is not moving.

[0039] The ECU 335 acquires, as vehicle information, information including the position information, the first image, the results of monitoring by the sensor group 325, and the measurement values ​​of the odometer 330. The ECU 335 controls various devices of the vehicle 30, such as the communication device 320 and the engine 322. The ECU 335 transmits the vehicle information to the server 10 via the communication device 320.

[0040] The monitoring unit 345 is installed in the garage of the dealer DLR on the outside of the vehicle 30. The monitoring unit 345 includes a camera 350, a microphone 355, and a communication device 360.

[0041] The camera 350 monitors (takes pictures of) the condition (surrounding conditions) of the vehicle 30 while the vehicle 30 is stored. The images taken by the camera 350 are also referred to as "second images." The second images can be used to ensure that the vehicle 30 has not been hit by an external object (or damaged by an intruder in the garage) while the vehicle 30 is stored. The second images can also be used to capture the results of maintenance work. In this case, the second images can be used to ensure that maintenance on the vehicle 30 has been performed by an employee EMP. The second images can be either still images or video images.

[0042] The microphone 355 monitors (detects) and records the sounds around the vehicle 30. The sounds are used to ensure that the vehicle 30 has not been struck by an external object (that loud sounds such as impact noises have not been detected) while the vehicle 30 is in storage.

[0043] The communication device 360 ​​is configured to transmit the results of the monitoring of each of the camera 350 and microphone 355 to the server 10 .

[0044] The dealer DLR (more specifically, the employee EMP) is expected to properly store (e.g., maintain) the vehicle 30 and properly create a storage record of the vehicle 30. When such a storage record is registered in the distributed ledger of the PBB-NW60 or PRB-NW70, a user who can access the distributed ledger can verify the storage record. However, there is a possibility that the dealer DLR may create a storage record improperly (e.g., manually forge) and register this storage record in the distributed ledger.

[0045] The server 10 according to the embodiment has a configuration for addressing the above-mentioned problem. Specifically, the communication device 110 acquires monitoring records (in this example, measurement values ​​of each sensor) created by the sensor group 325 while the vehicle 30 is in storage from the sensor group 325 via the communication device 320. The processing device 115 is configured to generate TX data including the monitoring records when triggered by receiving a generation request RQ for generating the TX data. The generation request RQ is transmitted from the owner terminal 40 to the server 10 in response to the above-mentioned registration instruction operation. The processing device 115 generates TX data when triggered by receiving the generation request RQ from the owner terminal 40, and then transmits the TX data to the PRB-NW 70 via the communication device 110.

[0046] With this configuration, the TX data is generated at a timing preferred by the holder HLD. As a result, the TX data is generated at a timing not predicted by the employee EMP, and then transmitted to the PRB-NW70 and registered in its distributed ledger. As a result, the employee EMP is prompted to properly store (e.g., maintain) the vehicle 30 so that the monitoring record is determined to be appropriate regardless of the timing of the generation request. This allows the dealer DLR to properly store the vehicle 30. Additionally, with the above configuration, the monitoring record is registered in the distributed ledger as an objective storage record based on the measurement results of the sensor group 325, unlike a storage record manually created by the employee EMP. As a result, it is possible to prevent a storage record created improperly by the employee EMP from being registered in the distributed ledger of the PRB-NW70. Furthermore, because the monitoring record is registered in the distributed ledger, it is difficult to tamper with.

[0047] The communication device 110 acquires the monitoring records from the sensor group 325, triggered by receiving the generation request RQ. The processing device 115 generates TX data so that the TX data includes the monitoring records acquired in this manner. That is, the server 10 acquires the monitoring records and generates the TX data, triggered by receiving the generation request RQ.

[0048] With this configuration, in response to the generation request RQ, TX data can be immediately generated and transmitted to the PRB-NW 70. As a result, the TX data (monitoring record) can be registered in the distributed ledger as quickly as possible.

[0049] The server 10 may execute a process for registering a portion of the monitoring records registered in the distributed ledger of the PRB-NW70 in the distributed ledger of the PBB-NW60. Specifically, the server 10 may calculate a hash value of the monitoring records registered in the distributed ledger of the PRB-NW70 at predetermined intervals, generate TX data for registering the hash value as a snapshot in the distributed ledger of the PRB-NW60, and transmit the TX data to the PBB-NW60. Information indicating the predetermined time is determined in advance as appropriate by the operator ENT and stored in the storage device 105.

[0050] According to this process, the minimum necessary data from the monitoring records registered in the distributed ledger of the PRB-NW 70 is registered as a snapshot in the distributed ledger of the PBB-NW 60. This allows any user of a terminal device that can access the PBB-NW 60 to check part of the monitoring records.

[0051] 3 is a flowchart illustrating a process executed by server 10 according to an embodiment. This flowchart is executed at predetermined time intervals. This time interval is stored in storage device 105, for example. Hereinafter, step will be abbreviated as "S".

[0052] 3, server 10 determines whether or not it receives a creation request RQ from owner terminal 40 (S105). If server 10 does not receive a creation request RQ (NO in S105), the process proceeds to RETURN. If server 10 receives a creation request RQ (YES in S105), the process proceeds to S110.

[0053] The server 10 acquires monitoring records from the sensor group 325 through the communication devices 320 and 110 (S110). The server 10 generates TX data so that the TX data includes the monitoring records acquired in this manner (S115), and transmits the TX data to the PRB-NW 70 (S120).

[0054] As described above, according to the embodiment, when a vehicle 30 is stored by an administrator other than its owner (in this example, the dealer DLR), it is possible to avoid a situation in which an improper storage record of the vehicle 30 is registered in the distributed ledger.

[0055] In addition, any user of a terminal device that can access the distributed ledger can recognize the appropriate timing for maintenance of vehicle 30 by checking the monitoring records registered in the distributed ledger.

[0056] [Variation 1] In this first modification, the server 10 (communication device 110) acquires monitoring records from the sensor group 325 at predetermined time intervals. The server 10 stores the acquired monitoring records in the storage device 105. Triggered by receiving a generation request RQ, the server 10 generates TX data and transmits it to the PRB-NW 70 so that the TX data includes the monitoring records stored in the storage device 105.

[0057] With this configuration, after the monitoring records are stored once in the storage device 105, TX data including the monitoring records in the storage device 105 is generated and transmitted to the PRB-NW 70, triggered by the reception of a creation request RQ. As a result, the monitoring records accumulated in the storage device 105 until the reception of the creation request RQ are registered collectively in the distributed ledger of the PRB-NW 70, triggered by the reception of the creation request RQ. As a result, the efficiency of data processing is improved, and monitoring records even when a creation request RQ is not received can be registered in the distributed ledger.

[0058] 4 is a flowchart illustrating a process executed by the server 10 according to Modification 1. This flowchart is executed at predetermined time intervals.

[0059] 4, the server 10 acquires monitoring records from the sensor group 325 through the communication devices 320 and 110 (S202). The server 10 stores the acquired monitoring records in the storage device 105 (S204).

[0060] The server 10 determines whether or not to receive a creation request RQ from the owner terminal 40 (S205). If the server 10 does not receive a creation request RQ (NO in S205), the process proceeds to RETURN. As a result, the monitoring record is accumulated in the storage device 105 (S202 and S204 are repeated) until a creation request RQ is received (until YES in S205).

[0061] When the server 10 receives the generation request RQ (YES in S205), it retrieves the monitoring record stored (accumulated) in the storage device 105 (S207). Then, the server 10 generates TX data including the retrieved monitoring record (S209) and transmits the TX data to the PRB-NW 60 (S220).

[0062] The monitoring records of the sensor group 325 may be stored in a storage device (not shown) external to the server 10 until the server 10 receives the generation request RQ. In this case, the server 10 accesses the external storage device as a trigger for receiving the generation request RQ, generates TX data so that the TX data includes the monitoring records stored in the external storage device, and transmits the TX data to the PRB-NW 60. This makes it possible to register the monitoring records in the PRB-NW 70 while preventing an increase in the amount of data in the storage device 105.

[0063] According to variant example 1, even if it is difficult to immediately obtain monitoring records from the sensor group 325 when a generation request RQ is received (for example, if communication is interrupted between the communication devices 110 and 320), TX data can be immediately generated and transmitted based on the monitoring records stored in the memory device 105 or an external memory device.

[0064] [Variation 2] The server 10 may be further configured to generate TX data triggered by receiving a generation request RQ from the manager terminal 25. In this case, the generation request RQ is transmitted from the manager terminal 25 to the server 10 in response to a registration instruction operation by the employee EMP using the manager terminal 25. This registration instruction operation is performed, for example, when the employee EMP completes maintenance of the vehicle 30.

[0065] With this configuration, TX data is generated triggered by the receipt of a generation request RQ from the owner terminal 40 and the receipt of a generation request RQ from the administrator terminal 25. This increases the frequency with which TX data is generated.

[0066] 5 is a flowchart illustrating a process executed by the server 10 according to the second modification. This flowchart is executed at predetermined time intervals.

[0067] 5, this flowchart differs from the flowchart of the above-described embodiment (FIG. 3) in that S307 is added. S305, and S310 to S320 are the same as S105, and S110 to S120, respectively.

[0068] If the server 10 does not receive a creation request RQ from the owner terminal 40 (NO in S305), it determines whether or not to receive a creation request RQ from the administrator terminal 25 (S307). If the server 10 does not receive a creation request RQ from the administrator terminal 25 (NO in S307), the process proceeds to RETURN. If the server 10 receives a creation request RQ from the administrator terminal 25 (YES in S307), the process proceeds to S310.

[0069] According to the second modification, the granularity of the monitoring record can be increased. In addition, the TX data can be generated at a timing preferred by the dealer DLR, which increases the convenience of the dealer DLR.

[0070] [Variation 3] The server 10 may be further configured to generate the TX data again when a predetermined time has elapsed since the previous generation of the TX data. Information indicating the predetermined time is appropriately determined in advance by the provider ENT and stored in the storage device 105.

[0071] With this configuration, the TX data is generated by being triggered by the receipt of a generation request RQ from the owner terminal 40 and the passage of a predetermined time. This increases the frequency with which TX data is generated, similar to the third modification.

[0072] 6 is a flowchart illustrating a process executed by the server 10 according to Modification 3. This flowchart is executed at predetermined time intervals.

[0073] 6, this flowchart differs from the flowchart of the above-described embodiment (FIG. 3) in that S408 is added. S405, and S410 to S420 are the same as S105, and S110 to S120, respectively.

[0074] If the server 10 has not received a generation request RQ from the owner terminal 40 (NO in S405), it determines whether a predetermined time has passed since the previous generation of TX data (S408). The previous generation of TX data corresponds to the previous execution of S415. If the predetermined time has not passed (NO in S408), the process proceeds to RETURN. If the predetermined time has passed (YES in S408), the process proceeds to S410.

[0075] According to the third modification, the granularity of the monitoring record can be increased. Furthermore, since the monitoring record can be created without using the owner terminal 40 (YES in S408), the owner HLD does not necessarily need to issue a registration instruction. As a result, the convenience of the owner HLD can be improved.

[0076] [Variation 4] The server 10 may execute a usage record registration process for registering a usage record of the vehicle 30 during the usage period in the distributed ledger of the PRB-NW 70. The usage period is the period during which the vehicle 30 is used and traveling outside the garage. In this example, the usage record is a driving record of the vehicle 30 during the usage period. This driving record is created to ensure that the vehicle 30 is not hit by an external object during the usage period. The driving record includes, for example, location information of the vehicle 30 and a first image. The usage record registration process corresponds to transmitting TX data including the usage record to the PRB-NW 70, and is executed sequentially during the usage period. For example, the server 10 sequentially acquires location information of the vehicle 30 and determines whether the vehicle 30 has left the garage (storage location) based on the location information of the vehicle 30. The server 10 starts the usage record registration process when triggered by the result of determining that the vehicle 30 has left the garage.

[0077] Once the usage record is registered, any user of a device that can access the PRB-NW70 can check the status of the vehicle 30 during the usage period by referencing the PRB-NW70's distributed ledger.

[0078] The server 10 may execute a process for registering a portion of the usage records registered in the distributed ledger of the PRB-NW70 in the distributed ledger of the PBB-NW60. Specifically, the server 10 may calculate a hash value of the usage records registered in the distributed ledger of the PRB-NW70 at predetermined intervals, generate TX data for registering the hash value as a snapshot in the distributed ledger of the PBB-NW60, and transmit the TX data to the PBB-NW60. Information indicating the above-mentioned predetermined time is determined in advance as appropriate by the operator ENT and stored in the storage device 105.

[0079] According to this process, the minimum necessary data from the usage records registered in the distributed ledger of the PRB-NW 70 is registered as a snapshot in the distributed ledger of the PBB-NW 60. This allows any user of a terminal device that can access the PBB-NW 60 to check part of the usage records.

[0080] [Other variations] The "monitoring device" of the present disclosure is not limited to the sensor group 325, but may be the camera 350. In this case, the server 10 acquires the second image created by the camera 350 from the monitoring unit 345 as a monitoring record.

[0081] The "monitoring device" may be a microphone 355. In this case, the server 10 obtains the audio recording made by the microphone 355 from the monitoring unit 345 as the monitoring record.

[0082] The "monitoring device" may be a GPS receiver 305. In this case, the location information of the vehicle 30 is used as the monitoring record. The "monitoring device" may be an odometer 330. In this case, the measurement value of the odometer 330 is used as the monitoring record.

[0083] To ensure that the vehicle 30 is not being driven (not being used) and is stored in the garage of the dealer DLR, it is preferable to use each of the GPS receiver 305 and the odometer 330 as a "monitoring device." For example, if the vehicle 30 is moved by a tow truck, the location information changes, but the measurement value of the odometer 330 does not change. In such a case, it is possible to ensure that the vehicle 30 is not being used (e.g., rented) based on the measurement value of the odometer 330. Furthermore, if the tires of the vehicle 30 are spun during maintenance, the measurement value of the odometer 330 changes, but the location information does not change. In such a case, it is possible to ensure that the vehicle 30 itself is not being moved and is therefore stored in the garage based on the location information.

[0084] The object is not limited to a vehicle 30, but may be other types of tangible objects such as paintings, antiques, jewels, precious metals, or moving objects including ships or aircraft.

[0085] The embodiments disclosed herein should be considered to be illustrative in all respects and not restrictive. The scope of the present invention is defined by the claims, not by the above description, and is intended to include all modifications within the meaning and scope of the claims. [Explanation of symbols]

[0086] 1 information processing system, 5 monitoring systems, 10 servers, 25 administrator terminals, 30 vehicles, 40 owner terminals, 60 public blockchain networks, 70 private blockchain networks.

Claims

1. A server configured to communicate with a holder terminal, which is a terminal device of a holder of a non-fungible token issued using distributed ledger technology, The non-fungible token is used as a certificate of authority to own or use a vehicle; The vehicle is managed by a vehicle manager who is different from the owner, The server a communication device configured to obtain a monitoring record of the vehicle state created by a monitoring device that monitors the vehicle state; a processing device that acquires the monitoring records from the communication device, and generates the transaction data in response to a request to generate transaction data including the acquired monitoring records; the state of the vehicle is the current location of the vehicle, the voltage of the battery of the vehicle, the air pressure of the tires of the vehicle, the amount of oil remaining for the engine of the vehicle, the viscosity of the oil, the mileage of the vehicle, or whether or not the vehicle has been hit by an object around the vehicle; The monitoring device comprises: a GPS receiver for acquiring the current location, a voltage sensor for measuring the voltage, an air pressure sensor for measuring the air pressure, an oil level sensor for measuring the remaining amount, a viscosity sensor for measuring the viscosity, an odometer for measuring the mileage, a camera for taking an image of the surroundings, or a microphone for detecting the sound of the surroundings, The processing device generates the transaction data in response to reception of the generation request from the holder terminal.

2. The server according to claim 1 , wherein the processing device is further configured to generate the transaction data in response to a trigger of receiving the generation request from an administrator terminal that is a terminal device of the administrator.

3. 3. The server according to claim 1, wherein the processing device is further configured to generate the transaction data again when a predetermined time has elapsed since the transaction data was previously generated.

4. Triggered by receiving the generation request, The communication device acquires the monitoring record, 3. The server according to claim 1, wherein the processing device acquires the monitoring records from the communication device, and generates the transaction data so that the transaction data includes the acquired monitoring records.

5. a storage device that stores the monitoring record acquired by the communication device; The server of claim 1 or claim 2, wherein the processing device, triggered by receiving the generation request, retrieves the monitoring records stored in the storage device and generates the transaction data so that the transaction data includes the retrieved monitoring records.

Images