server

Abstract

To improve user convenience with respect to the rental of tangible objects when an NFT is used as a certificate to prove authority to rent a tangible object.SOLUTION: A server 10 includes a storage device 105 and a processing device 115. The processing device 115 is configured to receive an issuance request to issue one or more second non-fungible tokens in association with an issued first non-fungible token (NFT 605) recorded in a distributed ledger, and execute an issuance process to issue the one or more second non-fungible tokens in response to the reception of the issuance request. Each of the first non-fungible token and the one or more second non-fungible tokens includes information that indicates the authority to rent a vehicle 30 and represents points to be consumed at the time of rental of the vehicle 30. The points are shared among the first non-fungible token and the one or more second non-fungible tokens.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. 2022-34652 (Patent Document 1) discloses an information processing system. This system manages the authority to use an object. Information regarding such authority can be managed using tokens issued on a blockchain. [Prior art documents] [Patent documents]

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

[0004] Non-fungible tokens (NFTs) are attracting attention as an example of tokens minted using distributed ledger technology such as blockchain technology. NFTs are extremely difficult to counterfeit or tamper with. NFTs can be linked to tangible objects and used as certificates to prove the authority to rent the tangible object. There is a demand for technology that improves user convenience regarding the rental of tangible objects based on NFTs.

[0005] The present disclosure has been made to solve the above-mentioned problems, and its purpose is to improve user convenience regarding the rental of tangible objects when NFTs are used as certificates to prove authority to rent tangible objects. [Means for solving the problem]

[0006] The server of the present disclosure includes a storage device and a processing device. The storage device holds a distributed ledger that records non-fungible tokens. The processing device is configured to receive an issuance request to issue one or more second non-fungible tokens in association with an issued first non-fungible token recorded on the distributed ledger, and to execute an issuance process to issue the one or more second non-fungible tokens in response to the issuance request. Each of the first non-fungible token and the one or more second non-fungible tokens includes information indicating authority to rent an object and representing points to be consumed when renting the object. The points are shared between the first non-fungible token and the one or more second non-fungible tokens. [Effects of the Invention]

[0007] According to the present disclosure, when an NFT is used as a certificate to prove authority to rent a tangible object, it is possible to improve user convenience regarding the rental of tangible objects. [Brief explanation of the drawings]

[0008] [Figure 1] 1 is a diagram schematically illustrating a configuration of an information processing system according to an embodiment. [Figure 2] A diagram explaining the data structure of a sub-NFT. [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. DETAILED DESCRIPTION OF THE INVENTION

[0009] 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 tangible object is a vehicle.

[0010] Fig. 1 is a diagram schematically illustrating the configuration of an information processing system according to an embodiment. Referring to Fig. 1, the information processing system 1 includes servers 10 and 20, vehicles 30 and 35, and user terminals 40 and 65. The information processing system 1 further includes a market server 50 and a blockchain network 60 (more specifically, a plurality of nodes thereof). The blockchain network 60 is also referred to as "BLC-NW60."

[0011] The server 10 is operated by the operator ENT. The operator ENT manages NFTs issued on the BLC-NW 60. The operator ENT uses the NFTs to provide rental services for vehicles 30 and 35. The vehicle 30 is a non-premium vehicle, and the vehicle 35 is a luxury vehicle. In the following description, the vehicle 30 is mainly used. The server 10 can also function as a node of the BLC-NW 60. The server 10 corresponds to the "server" in this disclosure. The server 10 includes a storage device 105, a communication device 110, and a processing device 115.

[0012] The storage device 105 stores programs and data executed by the processing device 115. The storage device 105 further holds a distributed ledger (described later) that records NFTs. The communication device 110 is configured to be able to receive a request RE-RQ requesting rental of a vehicle 30 from any terminal device (e.g., user terminal 40). The request RE-RQ includes sender information indicating the sender. Upon receiving the request RE-RQ, the communication device 110 transmits an arrangement command AR-IN to the server 20 instructing arrangement (including maintenance and cleaning) of the vehicle 30.

[0013] The processing device 115 includes a central processing unit (CPU) and a memory, which includes a read-only memory (ROM) and a random access memory (RAM).

[0014] The processing device 115 transmits transaction data (also abbreviated as "TX data") for issuing an NFT on the BLC-NW 60 to the BLC-NW 60 via the communication device 110. Sending the TX data to the BLC-NW 60 corresponds to broadcasting the TX data to each node (not shown) of the BLC-NW 60. After broadcasting, the TX data is propagated to, incorporated into, and approved by other nodes of the BLC-NW 60.

[0015] The server 20 is operated by the rental car store RCS that stores the vehicles 30 and 35. In response to the arrangement command AR-IN, the server 20 instructs an employee to arrange for the vehicle 30.

[0016] The vehicle 30 includes an HMI device 310, a camera 315, a start / stop switch (SW) 317, and communication devices 320A and 320B. The vehicle 30 further includes a door 325, a locking / unlocking device 330, and an ECU (Electronic Control Unit) 335.

[0017] The HMI device 310 is a notification device that displays various screens. The camera 315 captures an image of an object. The SW 317 is turned on / off to start / stop the driving system of the vehicle 30.

[0018] The communication device 320A is configured to communicate with the server 10 via a network (not shown). The communication device 320A is configured to be able to receive, from the server 10, a permission signal PS1 for permitting unlocking and locking of the vehicle 30 (more specifically, the door 325). The communication device 320A is configured to be able to receive, from the server 10, a start permission signal PS2 for permitting start of the vehicle 30 (more specifically, the driving system).

[0019] The communication device 320B is configured to communicate with a mobile terminal device (e.g., the user terminal 40) around the vehicle 30 via short-range wireless communication. The communication device 320B is further configured to communicate with the user terminal 40 via at least one of short-range wireless communication and wired communication. For example, the communication device 320B is configured to receive, from the user terminal 40, an unlock request signal requesting unlocking of the vehicle 30 or a lock request signal requesting locking. The door 325 is locked before receiving the unlock request signal. The communication device 320B is configured to receive, from the user terminal 40, an activation request signal requesting activation of the vehicle 30. The locking / unlocking device 330 is controlled to lock or unlock the door 325.

[0020] The ECU 335 controls the unlocking and locking of the vehicle 30. The ECU 335 is configured to execute the unlocking or locking of the vehicle 30 in response to receiving an unlock request signal or a lock request signal from the user terminal 40 via the communication device 320B after receiving the permission signal PS1 via the communication device 320A.

[0021] The ECU 335 controls the start and stop of the vehicle 30. The ECU 335 is configured to prohibit the start of the vehicle 30 before receiving the start permission signal PS2 through the communication device 320A. After receiving the start permission signal PS2, the ECU 335 is configured to start the vehicle 30 in response to receiving a start request signal from the user terminal 40 through the communication device 320B.

[0022] The user terminal 40 is a terminal device including an HMI device 410 and a communication device 460. The HMI device 410 receives input of user operations and displays various setting screens. The communication device 460 communicates with external devices of the user terminal 40, such as the servers 10 and 20 or the market server 50. When the user U2 performs an operation to rent the vehicle 30 using the HMI device 410, the communication device 460 transmits a request RE-RQ to the server 10.

[0023] The market server 50 functions to provide an NFT marketplace used for buying and selling (listing and bidding) of NFTs. When the conditions for bidding on a listed NFT are met, the market server 50 transfers the NFT from the NFT seller (NFT transferor) to the NFT successful bidder (NFT transferee). Transferring an NFT means transferring an NFT from the wallet of the NFT transferor to the wallet of the NFT transferee.

[0024] The user terminal 65 is configured to communicate with the market server 50 and is used by the user U2 to buy and sell various NFTs through the marketplace. The user terminal 65 is configured to be able to communicate with each node of the BLC-NW60.

[0025] The BLC-NW 60 is a public blockchain network. Each node of the BLC-NW 60 maintains a distributed ledger that can be accessed by the server 10, each of the user terminals 40 and 65, and other terminal devices. This distributed ledger contains TX data related to NFTs and is verified by the server 10.

[0026] NFT 605 is an issued NFT recorded in the distributed ledger of a node of BLC-NW60. NFT 605 is linked to vehicle 30. NFT 605 is used as a certificate to prove the authority to rent vehicle 30 (rental authority). NFT 605 is held by user U1. In other words, user U1 has rental authority based on NFT 605.

[0027] The NFT 605 includes ID (Identification) information 610, tangible object information 612, holder information 615, point information 620, expiration date information 622, lock information 624, and related NFT information 625. This information can be referenced by any terminal device that can access the BLC-NW 60.

[0028] The ID information 610 is used to identify the NFT 605. The tangible object information 612 indicates the identification information of the tangible object (in this example, vehicle 30) linked to the NFT 605. The holder information 615 indicates the identification information of the holder (NFT holder) of the NFT 605. In this example, the NFT holder is user U1.

[0029] The point information 620 represents points consumed when renting the vehicle 30 (for example, by an NFT holder). The points indicate the authority to rent the vehicle 30. The points represented by the point information 620 are also referred to as "points P1." Points P1 are, for example, information indicating the rental time of the vehicle 30, the distance that the vehicle 30 can be driven when rented, or the number of times the vehicle 30 can be rented, but are not limited to these.

[0030] The expiration date information 622 indicates the expiration date of the points P1. The expiration date can motivate the NFT holder to use up the points P1 before the expiration date. The lock information 624 indicates whether the NFT 605 is locked. Locking an NFT means that the NFT cannot be transferred from the wallet of the NFT holder to another wallet. When an NFT is locked, the transfer of the NFT is prohibited. The related NFT information 625 indicates information about another NFT associated with the NFT 605 (described in more detail below).

[0031] The NFT 605 is used as a certificate for proving the right to rent (rental authority) the vehicle 30. It is preferable to improve the convenience for users regarding the rental authority based on the NFT 605.

[0032] According to the embodiment, the processing device 115 of the server 10 receives an issuance request from the user terminal 40 via the communication device 320A to issue one or more sub-NFTs on the BLC-NW60 in association with the NFT 605. The issuance request includes issuance number information indicating the number of sub-NFTs to be issued and first amount information indicating a first amount (described below). The issuance number and the first amount are specified by the user U1 using the HMI device 410. The processing device 115 executes an issuance process in response to receiving the issuance request. The issuance process is a process for issuing one or more sub-NFTs and recording the one or more sub-NFTs in the distributed ledger. Each sub-NFT, like the NFT 605, includes information representing points. The processing device 115 executes the issuance process so that points P1 are shared between the NFT 605 and one or more sub-NFTs. "Sharing points" means that points P1 can be consumed when renting a vehicle 30 by either the NFT holder or the holder of a sub-NFT (sub-NFT holder).

[0033] According to the issuance process, the authority to rent the vehicle 30 is shared between the NFT holder and the sub-NFT holder. The NFT holder can then spend the points P1 themselves or allow the sub-NFT holder to spend the points P1. This improves the convenience of the NFT holder and the sub-NFT holder when renting the vehicle 30.

[0034] In an embodiment, a sub-NFT is issued to divide the rental authority (original rental authority) that user U1 originally has based on NFT 605 and transfer a portion of this authority to another person (e.g., user U2). The sub-NFT can be transferred separately from NFT 605. The sub-NFT is used as a certificate that proves that the sub-NFT holder has rental authority related to the sub-NFT. When a sub-NFT is issued and transferred from user U1 to user U2, user U1 loses a portion of his or her original rental authority, while a portion of the rental authority is inherited from user U1 to user U2. The sub-NFT holder can operate the user device to send a request RE-RQ to server 10 to rent vehicle 30.

[0035] 2 is a diagram illustrating the data structure of a sub-NFT. Referring to FIG. 2, in this example, n sub-NFTs 650 are issued (n is a natural number). The number of sub-NFTs 650 to be issued (n) is specified by user U1 using the HMI device 410 and is included in the issuance request.

[0036] The sub-NFT 650 includes ID information 660, tangible object information 665, owner information 670, point information 675, expiration date information 677, lock information 679, related NFT information 680, and allowable consumption amount information 685. This information can be referenced by any terminal device that can access the BLC-NW 60.

[0037] The ID information 660 is used to identify the sub-NFT 650. The tangible object information 665 indicates the identification information of the tangible object (vehicle 30 in this example) linked to the sub-NFT 650. The holder information 670 indicates the identification information of the holder (sub-NFT holder) of the sub-NFT 650. The sub-NFT holder is user U1 at the time the sub-NFT 650 is issued, but can later be changed from user U1 to another person (e.g., user U2) due to a transfer of the sub-NFT 650.

[0038] The point information 675 represents points consumed when renting the vehicle 30 (for example, by a sub-NFT holder). The points indicate the authority to rent the vehicle 30. The points represented by the point information 675 are also referred to as "points P2." Like points P1, points P2 are information indicating, for example, the rental time of the vehicle 30, the mileage that can be driven when rented, or the number of times that it can be rented.

[0039] The expiration date information 677 indicates the expiration date of the sub-NFT 650. The lock information 679 indicates whether the sub-NFT 650 is locked or not.

[0040] The related NFT information 680 includes information indicating that the sub-NFT 650 is associated with (derived from) the NFT 605, and ID information 610 of the NFT 605. Similarly, the related NFT information 625 of the NFT 605 includes information indicating that the NFT 605 is the source from which the sub-NFT 650 is derived, and ID information 660 of the sub-NFT 650. In this way, each of the related NFT information 625, 680 indicates that the NFT 605 and the sub-NFT 650 are associated with (linked to) each other.

[0041] The allowable consumption information 685 indicates the allowable consumption of the point P1. The allowable consumption will be described in detail later in the third modification.

[0042] In an embodiment, sharing point P1 is performed by allocating point P1 between NFT 605 and n sub-NFTs 650 by transferring at least a portion of point P1 (P0) indicated by point information 620 included in NFT 605 at the time the issuance request is received to each of the n sub-NFTs 650.

[0043] The above-mentioned issuing process will be described in detail below. The issuing process includes a first determination process, a first generation process, a first transmission process, a second generation process, and a second transmission process.

[0044] The first determination process is to determine, for each of the n sub-NFTs 650, a first amount of points P1 to be transferred from the NFT 650 to that sub-NFT 650. The first amount is equal to points P2 at the time of issuance of the sub-NFT 650. The first amount may be different for each sub-NFT 650 or may be constant for all sub-NFTs 650. The first amount is included in the issuance request as a predetermined value set by default or a value specified by user U1 using the HMI device 410.

[0045] The first generation process is to generate first TX data for updating the point information 620 (point P1) included in the NFT 605 by subtracting from the point P1 a first amount (more specifically, the sum thereof) determined corresponding to each of the n sub-NFTs 650. The first transmission process is to transmit the first TX data to the BLC-NW 60.

[0046] The second generation process is to generate second TX data for issuing n sub-NFTs 650, each of which includes point information 675 indicating the determined point P2. The second transmission process is to transmit the second TX data to the BLC-NW 60.

[0047] According to the issuance process, the update of point P1 and the issuance of sub-NFT 650 are approved on the BLC-NW60. As a result, a portion of point P1 can be included in sub-NFT 650 as point P2. Sub-NFT 650 can be transferred separately from NFT 605. When sub-NFT 650 is transferred from user U1 to user U2, point P2 is also transferred to user U2. As a result, a portion of point P1 is transferred to user U2 as point P2 without transferring NFT 605. As a result, a portion of the rental authority for vehicle 30 can be allocated from user U1 to user U2 without transferring NFT 605.

[0048] The second TX data may be generated to issue a single sub-NFT 650, or may be generated to issue multiple sub-NFTs 650 in bulk. When second TX data for issuing multiple sub-NFTs 650 in bulk is generated, it is easier to issue N sub-NFTs 650 without errors than when second TX data for issuing a single sub-NFT 650 is generated multiple times. Furthermore, the amount of data processing required to issue N sub-NFTs 650 can be reduced.

[0049] In response to receiving the request RE-RQ (FIG. 1), the server 10 executes a locking process to lock the NFT held by the sender of this request. This NFT may be either the NFT 605 or a sub-NFT 650. The locking process corresponds to a request process that requests the terminal device (e.g., user terminal 40 or 65) of the NFT holder to lock this NFT.

[0050] In response to the request processing, the terminal device transmits TX data for locking the NFT to the BLC-NW 60. This causes the TX data to be recorded on the distributed ledger, prohibiting the transfer of the NFT.

[0051] Locking the NFT can prevent the NFT from being sold by the holder (NFT seller) to another person through the marketplace while the vehicle 30 is being rented. As a result, it can prevent an NFT seller from unfairly renting the vehicle 30 without the NFT after selling the NFT.

[0052] 3 is a flowchart illustrating a process executed by the server 10 according to the embodiment. Referring to FIG. 3, the server 10 receives the issuance request (S105). The issuance request includes the issuance number information and the first amount information.

[0053] The server 10 determines a first amount (Q1) for each of the n sub-NFTs 650 (S107). The server 10 generates first TX data for updating the point P1 by subtracting the first amount (more specifically, its sum) from the point P1 (S110). The server 10 transmits the first TX data to the BLC-NW 60 (S112). The server 10 refers to the distributed ledger recorded in the node of the BLC-NW 60 and confirms the update of the point P1 (S114).

[0054] The server 10 generates second TX data for issuing n sub-NFTs 650 (S115). The server 10 transmits the second TX data to the BLC-NW 60 (S117). The server 10 confirms the issuance of n sub-NFTs 650 by referencing the distributed ledger (S119). The server 10 notifies the user terminal 40 of the issuance of n sub-NFTs 650 (S130), and ends the process.

[0055] In this way, according to the embodiment, it is possible to improve the convenience of transferring rental authority. [Variation 1] The server 10 may be configured to transmit a permission signal PS1 to the ECU 335 via the communication device 320A in response to the NFT 605 and the target NFT among the n sub-NFTs 650 being locked (first permission process). The target NFT is an NFT held by the sender of the request RE-RQ (more specifically, the user of the terminal device that sent the request RE-RQ). The terminal device of the holder (target holder) of the target NFT is also referred to as the "holder terminal." In this example, the holder terminal is the user terminal 40 or 65.

[0056] The server 10 determines the target NFT according to the sender information of the request RE-RQ and the holder information 615 or 670. For example, the server 10 determines an NFT (NFT 605 or sub-NFT 650) having holder information 615 or 670 that matches the sender information as the target NFT. The server 10 determines whether the target NFT is locked based on the lock information 624 or 679 of the target NFT.

[0057] After the first permission process, the door 325 is locked or unlocked in accordance with an unlock request signal or a lock request signal sent from the owner terminal to the vehicle 30.

[0058] After the first authorization process, when an unlock request signal is received, the ECU 335 may activate the camera 315. The camera 315 captures a captured image of the driver's license presented by the target owner, including a facial photograph of the target owner, and the target owner's actual face. The ECU 335 then verifies that the target owner has a driver's license by determining whether the facial photograph matches the actual face according to the captured image. The ECU 335 then controls the locking / unlocking device 330 to unlock the door 325. This allows the target owner to rent the vehicle 30 only if it is confirmed after the first authorization process that the target owner has a driver's license. After confirmation, the ECU 335 may send a confirmation notification to the server 20 indicating that it has confirmed that the target owner has a driver's license.

[0059] 4 is a flowchart illustrating the processing executed by the server 10 of Modification 1. This flowchart starts when the server 10 receives a request RE-RQ.

[0060] Referring to FIG. 4, the server 10 determines the target NFT according to the sender information of the request RE-RQ and the holder information 615 or 670 (S210). The server 10 refers to the distributed ledger recorded in the node of the BLC-NW 60 and determines whether the target NFT is locked or not based on the lock information 624 or 679 of the target NFT (S212). If the target NFT is not locked (NO in S212), the server 10 ends the processing. If the target NFT is locked (YES in S212), it sends a permission signal PS1 to the vehicle 30 (S215). Then, the processing ends.

[0061] According to the first permission process, only when the target NFT is locked, the target owner is permitted to unlock and lock the door 325. This allows appropriate permission to rent the vehicle 30 while avoiding a situation in which the target NFT is sold while the vehicle 30 is being rented.

[0062] The server 10 may be configured to transmit, in response to the target NFT being locked, a start-up permission signal PS2 to the ECU 335 via the communication device 320A to permit the start-up of the vehicle 30 (second permission process). In this case, the server 10 transmits the start-up permission signal PS2 to the vehicle 30 in place of the permission signal PS1 in S215.

[0063] According to the second permission process, activation of the vehicle 30 is permitted only when the target NFT is locked. This allows appropriate permission to rent the vehicle 30, similar to the first permission process.

[0064] [Variation 2] The server 10 may execute a point transfer process in response to receiving a point transfer request to transfer (return) at least a portion of the points P2 to the points P1. This transfer request is a request to return at least a portion of the points P2 indicated by the point information 675 included in each of at least one of the n issued sub-NFTs 650 (i.e., m of the n sub-NFTs 650 (1≦m≦n)) to the NFT 605. The point transfer request is generated by the holder of the sub-NFT 650 using their terminal device (e.g., user terminal 65) and transmitted from this terminal device to the server 10.

[0065] The point transfer process includes a second determination process, a third generation process, a third transmission process, a fourth generation process, and a fourth transmission process.

[0066] The second determination process is to determine a second amount of points to be returned to the NFT 650 from each of the m sub-NFTs 650. The second amount may be different for each sub-NFT 650 or may be constant for all sub-NFTs 650. The second amount is included in the point transfer request as the total remaining amount of points P2, a predetermined value set by default, or a value specified by the holder of the sub-NFT 650.

[0067] The third generation process is to generate third TX data for updating the point information 675 (points P2) included in each of the m sub-NFTs 650 by subtracting the second amount of the sub-NFT 650 from the points P2 (P2A) of the sub-NFT 650. The third transmission process is to transmit the third TX data to the BLC-NW60.

[0068] The fourth generation process is to generate fourth TX data for updating the point information 620 (point P1) included in the NFT 605 by adding the second amount (more specifically, the sum thereof) determined corresponding to each of the m sub NFTs 650 to the point P1 (P1A). The fourth transmission process is to transmit the fourth TX data to the BLC-NW 60.

[0069] FIG. 5 is a flowchart illustrating processing executed by the server 10 in Modification 2. Referring to FIG. 5, the server 10 receives a point transfer request (S505). The server 10 determines a second amount (Q2) for each of the m sub-NFTs 650 (S507). The server 10 generates third TX data for updating the points P2 for each of the m sub-NFTs 650 (S510). The server 10 transmits the third TX data to the BLC-NW 60 (S512). The server 10 refers to the distributed ledger and confirms the update of the points P2 for each of the m sub-NFTs 650 (S514).

[0070] The server 10 generates fourth TX data for updating point P1 (S515). The server 10 transmits the fourth TX data to the BLC-NW 60 (S517). The server 10 refers to the distributed ledger and confirms the update of point P1 (S519). The server 10 notifies the user terminals 40 and 65 of the updates to points P1 and P2 (S530).

[0071] According to Variation 3, at least a portion of the authority regarding the sub-NFT 650 can be reallocated to the NFT holder. As a result, convenience for the NFT holder and sub-NFT holder can be further improved.

[0072] [Variation 3] The concept of "sharing points" may also include the consumption of points P1 without consuming points P2 when a sub-NFT holder rents a vehicle 30. In this case, even if the remaining amount of points P2 is 0, the sub-NFT holder can rent a vehicle 30 by consuming points P1.

[0073] The amount of points P1 consumed by a sub-NFT holder may be limited to less than the aforementioned allowable consumption amount. If there are multiple sub-NFT holders, the allowable consumption amount may be set, for example, for each sub-NFT holder. Alternatively, the total amount of points P2 consumed by a group of multiple sub-NFT holders may be limited to be less than the allowable consumption amount. This allowable consumption amount is set by user U1 (NFT holder) using the HMI device 410 to be less than points P1.

[0074] [Other variations] The amount of points P1 and P2 consumed may vary depending on the type of vehicle being rented. For example, the amount of points P1 or P2 consumed (first consumption amount) when renting vehicle 30 (non-premium car) may be less than the amount of points P1 or P2 consumed (second consumption amount) when renting vehicle 35 (luxury car).

[0075] Upon receiving the confirmation notification, the server 10 may transmit a notification command to the vehicle 30 to notify the target holder of the point information (point information 620 or 675) of the target NFT. In response to the notification command, the HMI device 310 displays a screen displaying the point information of the target NFT. The notification command allows the target holder to be made aware of this before the points indicated by the point information (points P1 or P2) reach 0 (i.e., before the target holder is no longer able to drive the vehicle 30 satisfactorily).

[0076] "Sharing points" may be a concept that includes the possibility that each of points P1 and P2 can be consumed by either the NFT holder or the sub-NFT holder. In this case, even if the remaining amount of points P1 is 0, the NFT holder can rent the vehicle 30 by consuming points P2.

[0077] When the expiration dates indicated by the expiration date information 622 and 677 have expired, the server 10 may generate TX data for burning the NFT 605 and the sub 650, respectively, and transmit the TX data to the BLC-NW 60.

[0078] Tangible objects that can be linked to NFTs are not limited to vehicles 30, 35. Such tangible objects may also be other types of tangible objects, such as paintings, antiques, jewelry, precious metals, or moving objects, including ships or aircraft.

[0079] 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]

[0080] 1 Information processing system, 10, 20 Server, 30, 35 Vehicle, 40, 65 User terminal, 50 Market server, 60 Blockchain network.

Claims

1. a storage device that maintains a distributed ledger that records the non-fungible tokens; and processing equipment, A server comprising: The processing device includes: receiving an issuance request to issue one or more second non-fungible tokens in association with an issued first non-fungible token recorded on the distributed ledger; and performing an issuance process to issue the one or more second non-fungible tokens in response to receiving the issuance request; It is configured as follows: each of the first non-fungible token and the one or more second non-fungible tokens indicates authority to rent an object and includes information representing points to be consumed when renting the object; the points are shared between the first non-fungible token and the one or more second non-fungible tokens; server.

2. sharing the points is performed by allocating the first points between the first non-fungible token and the one or more second non-fungible tokens by transferring at least a portion of the first points indicated by the information included in the first non-fungible token at the time the issuance request is received to each of the one or more second non-fungible tokens; The issuing process includes: for each of the one or more second non-fungible tokens, determining a first amount of points to transfer from the first non-fungible token to the second non-fungible token; subtracting the first amount determined corresponding to each of the one or more second non-fungible tokens from the first points to generate first transaction data for updating the information included in the first non-fungible tokens; and generating second transaction data for issuing the one or more second non-fungible tokens, each including the information indicative of the determined first amount of points; Including, The server of claim 1 .

3. The processing device includes: receiving, for each of at least one second non-fungible token among the one or more issued second non-fungible tokens, a transfer request to transfer at least a portion of second points indicated by the information included in the second non-fungible token back to the first non-fungible token; and In response to receiving the transfer request, determining, for each of the at least one second non-fungible token, a second amount of points from the second non-fungible token back to the first non-fungible token; generating, for each of the at least one second non-fungible token, third transaction data for updating the information included in the second non-fungible token by subtracting the second amount of the second non-fungible token from the second points of the second non-fungible token; and generating fourth transaction data for updating the information included in the first non-fungible tokens by adding the second amount determined corresponding to each of the at least one second non-fungible token to the first points; and further configured to perform The server of claim 2.

4. the object includes a vehicle equipped with a first communication device, a second communication device, and an in-vehicle device; the first communication device is configured to connect to the server via a network; the second communication device is configured to connect to a user terminal via short-range wireless communication; the processing device is further configured to, in response to a target non-fungible token held by a user of the user terminal among the first non-fungible token and the one or more second non-fungible tokens being locked, transmit an authorization signal to the in-vehicle device via the first communication device to authorize unlocking and locking of the vehicle; the in-vehicle device is configured to, after receiving the permission signal, execute unlocking or locking of the vehicle in response to receiving a request signal requesting unlocking or locking of the vehicle from the user terminal via the second communication device. The server according to any one of claims 1 to 3.

5. the object includes a vehicle equipped with a first communication device, a second communication device, and an in-vehicle device; the first communication device is configured to connect to the server via a network; the second communication device is configured to connect to a user terminal via at least one of short-range wireless communication and wired communication; the processing device is further configured to, in response to a target non-fungible token held by a user of the user terminal out of the first non-fungible token and the one or more second non-fungible tokens being locked, transmit a start-up permission signal to the in-vehicle device via the first communication device to allow start-up of the vehicle; The in-vehicle device prohibiting the vehicle from starting before receiving the start-up permission signal; and after receiving the activation permission signal, in response to receiving an activation request signal requesting activation of the vehicle from the user terminal via the second communication device, activate the vehicle; It is configured as follows: The server according to any one of claims 1 to 3.

Images