Segmentable non-homogenous token and application thereof

Abstract

The patent invents a method of renting rentable items using a non-homogenous token (NFT), the method comprising: receiving a request from an owner to list rentable items for renting; a distributed ledger system is urged to cast inheritable rental non-homogenized tokens (NFTs) and distribute the rental non-homogenized tokens (NFTs) to an owner. The method lists an item for renting and receives a request from a renter to rent the item for a first set of time periods. The method then causes the distributed ledger system to cast a first set of sub-lease non-homogenized tokens (NFTs), where each sub-lease non-homogenized token (NFT) is associated with one of the first set of time periods, and assigns the first set of sub-lease non-homogenized tokens (NFTs) to the tenant. Further, the method casts a second set of one or more sub-lease non-homogenized tokens (NFTs) to encompass time periods other than the first set of time periods, and allocates the second set of sub-lease non-homogenized tokens (NFTs) to the owner while destroying the original lease non-homogenized tokens (NFTs).

Description

[0001] Priority claim

[0002] This application claims priority to U.S. Provisional Patent Application Serial No. 63 / 503,964, filed May 24, 2023, and U.S. Provisional Patent Application Serial No. 63 / 415,895, filed October 13, 2022. The contents of U.S. Provisional Patent Application 63 / 503,964 and U.S. Provisional Patent Application 63 / 415,895 are incorporated herein by reference. Technical Background

[0003] A non-fungible token (NFT) is a cryptographic asset that uses blockchain technology to provide verified ownership of physical or non-physical assets. NFTs typically contain a reference to an identifiable and unique asset, and their transaction history is permanently recorded on the blockchain and managed by smart contracts.

[0004] A smart contract is a program published and executed on a blockchain. It is a set of code and data stored at a specific address on the blockchain and attributed to a specific user or organization. This code is open source, and its execution results are predictable, ensuring that the inputs are deterministic. The code executes automatically and cannot be stopped. Smart contracts enforce agreements or contractual terms external to the blockchain and automatically perform actions that would otherwise require manual work between parties, eliminating the need for trust between the parties.

[0005] Furthermore, due to the nature of blockchain, code or data cannot be modified without notifying other users on the chain. This feature provides fairness to both parties involved in the transaction and prevents data manipulation.

[0006] Smart contracts on the blockchain are open to all nodes, and the results of transactions are predictable and can be verified and proven through modern cryptography. These characteristics make non-fungible tokens an ideal choice for secure, immutable, and traceable transactions. BRIEF DESCRIPTION OF THE DRAWINGS

[0007] Various divisible non-fungible tokens and their applications of the present invention will now be discussed in detail, with a focus on their advantageous features. These embodiments demonstrate novel and non-obvious divisible non-fungible tokens and their applications, and are illustrated in the accompanying drawings for illustrative purposes only. The drawings include the following figures, wherein like numbers represent like parts:

[0008] FIG1A is a functional block diagram illustrating an example system for processing divisible non-fungible tokens.

[0009] FIG1B is a functional block diagram illustrating some components of the platform of FIG1A.

[0010] Figure 2 is a functional block diagram that provides an overview of the system structure, request flow, and interactions between components related to non-fungible tokens in accordance with various aspects of the disclosure.

[0011] Figure 3A is a functional diagram illustrating the metadata stored when performing a split operation on an inheritable non-fungible token.

[0012] Figure 3B is a functional diagram illustrating the metadata stored when performing a merge operation on two inheritable non-fungible tokens.

[0013] Figure 3C is a functional diagram illustrating an example of metadata stored for a non-inheritable non-fungible token.

[0014] Figure 4 is a functional diagram illustrating an example of automatic splitting of a non-fungible token into equal parts.

[0015] Figures 5A and 5B are functional diagrams illustrating an example of on-demand splitting and merging of inheritable non-fungible tokens.

[0016] Figure 6 is a sequence diagram illustrating the data exchange process for minting new non-fungible tokens.

[0017] Figure 7 is a sequence diagram illustrating the data exchange process for splitting an inheritable parent non-fungible token and generating child tokens.

[0018] Figure 8 is a sequence diagram illustrating the data exchange process for merging multiple non-fungible tokens into a new token.

[0019] Figure 9 is a sequence diagram illustrating the data exchange process when destroying non-fungible tokens.

[0020] FIG10 is a flow chart illustrating an example process for registering real estate or a vehicle.

[0021] Figure 11 is a flow chart illustrating an example process for automatic splitting of leased non-fungible tokens.

[0022] Figure 12 This is a flowchart illustrating an example on-demand splitting process for leasing non-fungible tokens.

[0023] Figure 13A It is a functional block diagram illustrating the system design of a decentralized real estate and vehicle rental system.

[0024] Figure 13B This is a functional block diagram illustrating the database architecture of real estate data in a decentralized real estate and vehicle rental system.

[0025] Figure 13CThis is a functional block diagram illustrating the database architecture for vehicle data in a decentralized real estate and vehicle rental system.

[0026] Figure 14 is a sequence diagram that illustrates the data exchange process that occurs when an owner lists a property or vehicle for rent.

[0027] FIG15 is a sequence diagram illustrating the data exchange process when a tenant successfully rents a listed property or vehicle.

[0028] Figure 16 is a flow chart illustrating an example process for an electronic device to automatically split inheritable non-fungible tokens.

[0029] Figure 17 is a flow chart illustrating an example process for an electronic device to split inheritable non-fungible tokens on demand.

[0030] Figure 18 A is a functional diagram illustrating the high-level structure of a peer-to-peer housing rental management system.

[0031] Figure 18 Figure B is a functional diagram illustrating how parent and child tokens can build a trusted and applicable peer-to-peer housing rental system.

[0032] Figure 19 This is a flowchart illustrating an example process where a landlord rents out all or part of a property using a non-fungible token (NFT).

[0033] 20A-20D are schematic front views illustrating a user interface (UI) of a client device for a landlord to manage property rentals on a display screen of the device.

[0034] Figure 21 is a flow chart illustrating an example process for a new tenant to lease a property through a decentralized real estate platform.

[0035] Figure 22 A-22B is a schematic front view showing a user interface (UI) of a client device for a tenant to operate during the leasing process.

[0036] Figure 23A Illustrated are two examples of the types of non-fungible tokens (NFTs) that might be used in a decentralized real estate platform.

[0037] Figure 23B An example of renting out the same room but for different time periods is illustrated, along with the corresponding rental NFT splitting process.

[0038] Figure 23Cis a time diagram illustrating an example of time-sliced ​​invalidation where the authorized time period exceeds the current available timeframe for leasing the NFT.

[0039] Figure 23D is another timeline diagram further illustrating an example of time-segmented invalidation where the authorization period exceeds the current available timeframe for leasing the NFT.

[0040] Figure 24 A is a functional diagram illustrating an example of a smart door lock equipped with a fingerprint reader and a keypad.

[0041] Figure 24 B is a functional diagram illustrating an example of using facial recognition technology to enter a property.

[0042] Figure 24 C is a functional diagram illustrating an example of using a QR code or NFC (Near Field Communication) home access security lock to enter a property.

[0043] Figure 24 D is a functional diagram illustrating how a tenant can access a rented property using NFC (Near Field Communication).

[0044] Figure 24 E is a functional diagram illustrating how a tenant can use a QR code to enter a rented property.

[0045] Figure 25 is a functional block diagram illustrating how custom services are integrated into the platform and how the exchange and sharing of these services are facilitated through the open source marketplace.

[0046] Figure 26 This is a flowchart illustrating an example process for vehicle leasing using non-fungible tokens.

[0047] Figure 27 A-27D is a schematic front view illustrating a user interface (UI) of a client device for operation by a tenant on a display screen of the device during a vehicle rental process.

[0048] Figure 28 Figure A is a functional diagram illustrating the application of the non-fungible token (NFT) concept in vehicle trading and highlighting the different types of non-fungible tokens used in the system.

[0049] Figure 28 B illustrates an example of a vehicle lease with two separate time periods and shows the corresponding lease NFT splitting process.

[0050] Figure 28 C is a time diagram illustrating an example process segmented by time.

[0051] Figure 29 This is a flowchart illustrating the execution of the NFT workflow in the new leasing process.

[0052] Figure 30 is a flow chart illustrating the steps that need to be performed after the vehicle lease ends.

[0053] FIG31 is a flow chart illustrating the vehicle access process under different circumstances.

[0054] Figure 32 A and 32B are functional schematics illustrating the design of the smart vehicle lock.

[0055] FIG33 is a functional diagram illustrating the vehicle tracking hardware and user interface.

[0056] Figure 34 It is a flow chart that illustrates the process of how a vehicle owner can track and control his vehicle.

[0057] FIG35 is a flow chart illustrating the process of how a vehicle renter tracks and controls a vehicle.

[0058] Figure 36 An electronic system is conceptually illustrated that may be used to implement some embodiments of the present invention. DETAILED DESCRIPTION

[0059] One aspect of the present invention is the recognition that non-fungible tokens (NFTs) can be easily linked to real-world assets (such as real estate, tickets, and cars) or virtual items (such as pictures and in-game rights). While these NFTs may be highly valuable, not everyone can afford them. However, the cost of temporarily leasing these NFTs is much lower and may be sufficient for some users. Therefore, there is a significant demand for partial use or leasing of NFTs in real-world applications. However, the mechanisms and standards for leasing NFTs are not yet fully developed or established. Current on-chain transactions only allow for the transfer of ownership of the entire NFT and cannot support the complex functionality required by leasing systems. If a system design uses only off-chain operations for leasing, without actually transferring ownership of the NFT during the lease period, it could create vulnerabilities for attackers, and the tenant's ownership during the lease period may not be fully protected and verified. Furthermore, within a specified period of time, ownership of a leased NFT cannot be re-entered the market unless the tenant actively revokes or returns ownership, and the owner then sells the leased NFT again on the market.

[0060] One of the major challenges facing the current real estate market is limited access to key information about properties, such as basic details and prices. Another challenge is the complexity of real estate transactions, which can be daunting for both tenants and landlords, especially for newcomers to the market. Real estate has unique characteristics, such as multi-family buildings or duplexes, which may be rented by the room or block. The vehicle rental market faces similar issues and challenges.

[0061] Some embodiments of the present invention solve the above problems by providing a mechanism that allows the generation of small non-fungible tokens (child non-fungible tokens) that belong to the original non-fungible token (parent non-fungible token) and establishes a non-fungible token leasing standard. The mechanism provides child non-fungible token holders with some rights and interests related to the parent non-fungible token within the effective time or space scope of the child non-fungible token, such as the right to use the object referred to by the parent non-fungible token. The present invention provides a reliable and applicable non-fungible token leasing method. Child non-fungible tokens cannot overlap with each other in time or space, nor can they overlap with the parent non-fungible token. Therefore, after the child non-fungible token is minted, the parent non-fungible token is destroyed to avoid overlapping properties with the child non-fungible token.

[0062] Some embodiments of the present invention provide a parent-child non-fungible token mechanism that can be applied to existing peer-to-peer product and service rental applications, such as housing or vehicle rental management systems. These embodiments utilize parent-child non-fungible tokens to build a trustworthy and adaptable peer-to-peer rental management system that eliminates the need for an intermediary. Simultaneously, smart contracts act as oracles, defining transaction transfer rules and executing programs to handle all operations within the rental management system. In these embodiments, tenants can search, rent, or bid on products, while owners can rent or confirm bids through this system, without the need for any intermediary.

[0063] Some embodiments of the present invention provide a decentralized trading system based on blockchain technology. By eliminating intermediaries such as agents and brokers, the decentralized trading platform leverages the transparency provided by blockchain to provide valuable information, such as transaction history and market statistics, to tenants and owners. Users can directly access this data, streamlining the real estate purchasing and leasing process.

[0064] Simplifying the complexities of real estate transactions will greatly benefit all parties involved. Leveraging the non-fungible and non-copyable properties of non-fungible tokens, they can serve as secure and tamper-proof digital representations of real estate titles, potentially replacing traditional title deeds as proof of ownership.

[0065] The decentralized trading platform of this invention enables non-fungible tokens to be divided based on specific characteristics of real estate, such as time and space. By allowing tenants to purchase non-fungible tokens representing specific spaces (such as specific units or rooms) and the time they are available, the platform of this invention simplifies the leasing process and provides greater flexibility for landlords and tenants. The use of non-fungible tokens has become a valuable tool in the real estate market, changing the way properties are leased and managed.

[0066] Some embodiments of the present invention apply non-fungible tokens to the real estate industry and provide a novel method for splitting non-fungible tokens in real estate transactions. This method can partition a single non-fungible token into multiple non-fungible tokens, each of which acts as a subset of its parent non-fungible token and contains a portion of the parent's property rights. This non-fungible token splitting method enables more efficient transfers of property ownership and use rights, while creating new real estate ownership and investment opportunities. The application of blockchain technology and non-fungible tokens in real estate transactions offers a novel solution to the challenges of traditional real estate transactions, enabling all parties involved to enjoy greater transparency, lower costs, and improved accessibility.

[0067] The platform seamlessly integrates innovative hardware components, such as smart locks and cameras, to further enhance the overall user experience and ensure the highest level of security. The platform provides flexibility for built-in system components and services through open application programming interfaces (APIs). Furthermore, the platform offers a component marketplace, enabling users to easily share and utilize community plug-ins, further expanding the system's versatility and customization options.

[0068] Another aspect of the present invention is the recognition that in the field of vehicle transactions, the integrity of records and history is crucial, and decentralization is key to maintaining this integrity. Existing centralized service providers often lack transparency, making it difficult to obtain critical information.

[0069] Some embodiments of the present invention address these issues by providing a decentralized peer-to-peer marketplace. Leveraging blockchain technology, this platform provides valuable information, such as comprehensive vehicle history and market analysis. The application of blockchain technology reduces the friction faced by people when buying or leasing a vehicle.

[0070] This decentralized approach ensures that records of repairs, maintenance, accidents, and other events cannot be altered once uploaded, eliminating the possibility of forgery or tampering. Furthermore, rental histories, including information such as tenants, owners, and rental prices, are publicly available, ensuring complete transparency for all parties involved.

[0071] Some embodiments of the present invention utilize non-fungible tokens in the automotive and other vehicle industries. This decentralized platform simplifies and automates leasing operations. Furthermore, the platform eliminates agents or intermediaries in the transaction process, thereby reducing transaction costs for both parties.

[0072] The platform can integrate intelligent hardware devices, such as smart car keys and vehicle tracking devices, to provide a seamless car rental experience. Users can easily access their rented vehicles without having to physically visit a counter to collect the keys. Individual car owners and rental companies can easily track the location of their vehicles to avoid violations or misuse during the rental period.

[0073] Thanks to this decentralized vehicle trading platform, the leasing process is streamlined, delivering greater value to users. The leasing process can be completed by exchanging ownership of a leased non-fungible token attached to the vehicle. The leasing process can be abstracted to a simple split of a non-fungible token based on authorization time. The non-fungible token itself can also be used directly as a vehicle key, allowing users to complete their lease without the tedious process of communicating with a counterparty.

[0074] The remaining detailed description will illustrate embodiments of the present invention in conjunction with the accompanying drawings. In the accompanying drawings, reference numbers are used to identify various components of the present invention, and these reference numbers will appear again in the subsequent discussion of the corresponding drawing features.

[0075] I. Divisible Non-Fungible Tokens

[0076] FIG1A is a functional block diagram illustrating an example system 100 for processing divisible non-fungible tokens. Various aspects of the present invention relate to implementations of this system. FIG1B is a functional block diagram illustrating some example components of the platform 105 of FIG1A.

[0077] As shown in Figure 1A, system 100 may include a platform 105, multiple electronic devices 120, and a blockchain network 150. In some embodiments, platform 105 may be deployed on one or more electronic devices, such as a backend server 115. Backend server 115 may access one or more databases 191-193.

[0078] User 101 may be the owner or tenant of products and services, and may interact with network services 116 and backend servers 115 through a user interface (UI) 102 on their electronic device 120. User 101 accesses different services of platform 105 through UI 102 on their electronic device 120. Network services 116 may access various functions of platform 105 to provide different services to user 101.

[0079] In some cases, if the products and services involve real estate, the owner may also be a landlord who wishes to rent out his property. A tenant is a user who is willing to pay a fee to obtain the right to use the property. In this manual, the terms "lease" and "rent" are used interchangeably to refer to a contract between a landlord and a tenant, which stipulates the lease term, rent amount, and the rights and obligations of the landlord and tenant. In addition, the terms "real property", "real estate" and "property" are used interchangeably to refer to land and its ancillary buildings, including residential or commercial properties such as houses, rooms, apartments, office buildings, shops, etc.

[0080] A blockchain network provides a distributed, immutable ledger. Blockchain networks can be public, private, or government-owned. Examples of blockchain networks include Bitcoin, Ethereum, IBM Blockchain, and Corda. Blockchain networks provide the infrastructure for applications to access the ledger and smart contract services. Smart contracts can be used to initiate transactions, which are transmitted to each node in the blockchain network and recorded on their copies of the ledger.

[0081] Referring to FIG1A , a blockchain network 150 may be a decentralized network consisting of multiple blockchain nodes 151. Each blockchain node 151 may include at least one server 152 and a storage medium 153. Nodes 151 in the blockchain network 150 may communicate via one or more networks 103. Networks 103 may include the Internet, a user's local network (e.g., Wi-Fi, Ethernet, etc.), a telecommunications network (e.g., a public switched telephone network (PSTN), a packet-switched network, etc.), a server network, and a backend device network.

[0082] The blockchain smart contract application 107 can run on any blockchain node 151. For example, the blockchain smart contract application 107 may run in a virtual machine (VM) deployed on any node 151. A virtual machine is a simulation (or software implementation) of a specific computer system.

[0083] Blockchain smart contract applications 107 can be accessed through an application binary interface (ABI), such as the blockchain smart contract ABI 108 shown in FIG1B . An ABI is an interface between two program modules, one of which is typically a machine code-level interface. This interface is used to encode and decode data between machine codes. For example, in the Ethereum blockchain network, programmers can use the ABI to encode Solidity smart contract calls for the Ethereum Virtual Machine (EVM). Programmers can use the ABI to read data in transactions. The ABI acts as a function selector, defining the smart contract functions that can be called.

[0084] 1A and 1B , when a function of platform 105 (e.g., list function 131 in FIG. 1B ) needs to call a smart contract function (e.g., casting function 154 in FIG. 1A ), platform 105 may trigger a corresponding ABI call (e.g., casting ABI 121 in FIG. 1B ). This ABI call will execute the corresponding ABI function (e.g., casting function 154) in blockchain smart contract application 107 . When this function executes, it may trigger events. These events are permanently stored on the blockchain. Simultaneously, platform 105 constantly monitors blockchain events, obtains results upon detecting corresponding events, and provides the required responses.

[0085] In the example blockchain smart contract application 107 shown in Figure 1A, the functions provided by the smart contract application include minting 154, dividing 155, combining 156, burning 157, validating 158, and transferring 159. These functions can be selectively executed through corresponding application binary interfaces (ABIs), such as minting ABI 121, dividing ABI 122, combining ABI 123, destroying ABI 124, validating ABI 125, and transferring ABI 126. ABI 108 encodes function signatures and variable declarations as information, allowing the virtual machine (VM) hosting blockchain smart contract application 107 to identify the function to be executed and the parameters to be passed. This smart contract application 107 can be used to process leasing or purchasing transactions for various products and services, such as real estate and vehicles.

[0086] Referring to Figure 1B , platform 105 may include multiple functional components, each of which may be implemented as executable machine instructions. In some embodiments, these functional components may include an account services component 106, an owner marketplace component 130, a buyer marketplace component 136, a rental marketplace component 142, and a smart contract ABI component 108. Platform 105 includes a blockchain smart contract ABI component 108, as previously described.

[0087] The account service component 106 is responsible for account management backend services, including account registration function 109 (for creating an account), login function 111 (for logging into an existing account), profile function 112 (for viewing and updating user account information, such as name, address, photo, associated payment method, credit information), and wallet connection function 113 (for connecting to a digital wallet, such as making a payment, making a payment, or providing a signature).

[0088] The Owner Marketplace component 130 allows owners of products and services to rent or sell their assets. Owners can post rental or sale information through the Listing function 131 or cancel listed products and services through the Unlisting function 132. If a product or service is already listed and one or more tenants or buyers have made bids on it, the owner can choose to accept a bid through the Confirm Bid function 133. Additionally, the Contract Management function 134 allows property owners to sign, receive, and renew contracts, and the Search function 135 allows owners to retrieve information about their assets.

[0089] The rental marketplace component 142 allows tenants to rent products and services. For example, tenants can rent real estate through the rental feature 143 (which supports cryptocurrency payments). Tenants can also bid for rentals through the bid feature 144 or cancel a submitted bid using the cancel bid feature 145. The contract management feature 146 allows tenants to sign, receive, and renew contracts, while the search feature 147 allows tenants to search for properties or other rental products based on time, location, price, owner, and other criteria. In addition, tenants can search for single or multiple room rentals.

[0090] The Buyer Marketplace component 136 allows buyers to purchase real estate or other assets. Buyers can purchase a property directly through the Buy function 137 or submit a purchase offer through the Bid function 138. If necessary, buyers can withdraw their offer using the Cancel Bid function 139. The Contract Management function 140 allows buyers to sign, receive, and update contracts, while the Search function 141 allows buyers to search for all relevant property information. The Non-Fungible Token Title Management component 148 is used to interact with the Smart Contract Application 107 after the transaction is completed to transfer the non-fungible token representing the title and legal ownership to the buyer or tenant.

[0091] The property access management component 165 allows tenants or buyers to access properties through a variety of methods, including facial recognition, fingerprint, voice, 3D facial point cloud, QR code (QR code), barcode, near-field communication (NFC), etc. A 3D facial point cloud is a set of data points in a 3D coordinate system that represents a person's 3D facial geometry. Furthermore, the platform 105 may also include a vehicle access and usage management component specifically for managing vehicle transactions.

[0092] Smart contract services provide a range of core functions, including minting, dividing, combining, burning, validating, and transferring. The minting function 154 allows for the generation of two types of non-fungible tokens: non-inheritable non-fungible tokens 171 and inheritable non-fungible tokens 172. Non-inheritable non-fungible tokens 171 cannot generate child non-fungible tokens. For example, a driver's license non-fungible token cannot be split or combined with other driver's licenses.

[0093] Inheritable non-fungible token 172 can serve as a parent non-fungible token for generating child non-fungible tokens that inherit temporal or spatial portions of the parent non-fungible token. For example, in the example shown in FIG1A , inheritable non-fungible token 172 may be split into three child non-fungible tokens based on time: non-fungible token 173, non-fungible token 174, and non-fungible token 175.

[0094] The merge function 156 allows two non-conflicting inheritable non-fungible tokens (e.g., non-fungible token 173 and non-fungible token 174) to be merged into a new inheritable non-fungible token 176, and destroys non-fungible token 173 and non-fungible token 174. The destroy function 157 is used to disable a non-fungible token that cannot be reused, for example, by transferring the destroyed non-fungible token 177 to an inaccessible address 178 to ensure that it cannot be used again. Each time a non-fungible token is changed, the verification function 158 is responsible for performing non-fungible token authentication to ensure its integrity. The transfer function 159 allows non-fungible tokens to be transferred between different owners.

[0095] Newly minted non-fungible tokens may be sent to a blockchain network 150, and the corresponding metadata may be stored in a non-fungible token (NFT) metadata database 195 on decentralized storage 190. Decentralized storage 190 may be distributed across multiple servers or multiple physical locations, such as servers in different locations. Once stored in a decentralized storage system, data can be accessed from any device and any network location. For example, the Interdomain File System (IPFS) is a decentralized storage solution.

[0096] It is important to note that storing non-fungible token (NFT) metadata in decentralized storage rather than directly on the blockchain can avoid high blockchain transaction fees. Storing large non-fungible tokens (NFTs) (such as audio, image, or video files) on the blockchain may incur high transaction costs, and a decentralized database 190 is more cost-effective. Some embodiments may use communication protocols such as BitTorrent to host and receive non-fungible tokens (NFTs). BitTorrent is a peer-to-peer (P2P) file sharing protocol that allows users to distribute data and electronic files in a decentralized manner in an Internet environment. After the non-fungible token (NFT) is stored, the non-fungible token (NFT) address will be uniquely associated with the non-fungible token (NFT) content through a hash function to ensure that the address will not change if the file content is changed without authorization.

[0097] The system 100 may include multiple databases 180 that can be customized according to different application requirements and store various types of data. In some embodiments, the product and service database 191 may store product and service information related to inheritable non-fungible tokens (NFTs) (such as NFTs 172-176). For example, an inheritable rental non-fungible token (NFT) may be defined for a product or service, which, as a parent non-fungible token (NFT), can generate a child non-fungible token (NFT) that inherits the non-overlapping portion of the parent non-fungible token (NFT) in time and / or space. The owner of a product or service can use the functions in the owner market component 130, such as the listing function 131, the cancel listing function 132, the confirm bid function 133, the contract management function 134, and the search function 135, to list the product or service for rental at a specific time and / or space. Tenants can use functions in the rental marketplace component 142, such as the leasing function 143, the bidding function 144, the cancel bidding function 145, the contract management function 146 and the search function 147, to search, bid and lease one or more time periods and / or spaces for products or services.

[0098] Products and services may include rentable items that can be leased by units of space or time. For example, rentable items may include physical products such as real estate (e.g., houses, offices, buildings, stadiums, theaters, event venues, etc.), which can be leased by space (e.g., rooms, floors, areas, etc.) and / or time (e.g., hours, days, months, years, etc.).

[0099] Rentable items may also include vehicles (e.g., cars, trucks, off-road vehicles (SUVs), airplanes, drones, helicopters, boats, all-terrain vehicles (ATVs), motorcycles, bicycles, etc.), which are typically rented on a time basis (e.g., hours, days, months, years, etc.). Rentable items may also include any product that can be rented on a time or space basis. For example, rentable items may include tools, sports equipment, construction equipment, etc., which can be rented on a time basis.

[0100] Rentable items may include intangible services. Rentable items may include any intangible service that can be rented on a time-based basis. For example, rentable items may include the services of one or more professionals or skilled workers, such as consultants, contractors, inspectors, appraisers, bookkeepers, information technology (IT) professionals, cleaners, etc., whose services can be rented on a time-based basis. Rentable items may also include the services of a moving team, whose time can be rented to move furniture or equipment.

[0101] Products and services may include products that can have split ownership shares. For example, products and services may include artwork or collectibles whose ownership can be split into multiple shares. An inheritable non-fungible token (NFT) can be defined to represent the ownership of the artwork or collectible, and the non-fungible token (NFT) serves as a parent non-fungible token (NFT) that can generate child non-fungible tokens (NFTs) that inherit non-overlapping portions of the product ownership. These child non-fungible tokens (NFTs) can then be searched, bid on, and purchased through the buyer marketplace component 136 of the platform 105, including purchase functionality 137, bid functionality 138, cancel bid functionality 139, contract management functionality 140, and search functionality. Another example of a product that can have split ownership is a rare book or magazine series. An inheritable NFT could be defined to represent ownership of the entire series, which acts as a parent NFT that can be used to generate child NFTs for each book, magazine, etc., which can then be sold individually.

[0102] The products and services database 191 may contain pointers to the storage location of metadata for non-fungible tokens (NFTs) (e.g., as further described in Figures 3A-3C). This data may include the unique identifier, type, location, status, and other relevant information for the non-fungible token (NFT). In addition, the products and services database 191 may store current and historical listing information for assets such as real estate and vehicles.

[0103] In some embodiments, a contract database 192 may be used to store contract records and their corresponding status. A transaction database 193 may be used to store detailed information about each transaction, including new purchases, sales, and leases of real estate, vehicles, and the like. A tracking history database 194 may be used to store historical vehicle location records, allowing users to define the time range for data storage. Other databases 196 may be used to store vehicle-related data (described further in subsequent sections), as well as optional custom databases, allowing developers to provide more flexible and personalized features.

[0104] Figure 2 is a functional block diagram that provides a conceptual overview of the system architecture, request flow, and component interactions related to non-fungible tokens (NFTs). This diagram schematically illustrates the actions taken by the owner, tenant, or buyer of a product or service. It is important to note that all actions taken by the owner, buyer, and tenant communicate with the backend server 115 through their respective electronic devices 120 (as shown in Figure 1A). For example, Figure 2 conceptually shows that a product and service request 208 sent by a tenant / buyer electronic device 220 reaches the owner electronic device 210 directly. However, in actual execution, the request must traverse the network 103 and the backend server 115 before being forwarded to the owner's electronic device 210. As another example, Figure 2 conceptually shows instructions 201 sent from the owner electronic device 210 to the smart contract application 107. In reality, these instructions traverse the network 103 and the backend server 115 before ultimately reaching the smart contract application 107. For the sake of brevity, these intermediate steps are not shown in Figure 2.

[0105] 2 , a non-fungible token (NFT)-related operation instruction 201 initially comes from the owner's electronic device 210 and is then sent to the smart contract application 107 via a request call. The smart contract application 107 may trigger corresponding services (e.g., minting 154, splitting 155, merging 156, destroying 157, verifying 158, and transferring 159 functions in FIG1A ) to process the incoming request. The newly minted non-fungible token (NFT) 230 may be sent to a blockchain (e.g., blockchain network 150 in FIG1A ), and the corresponding metadata 202 may be stored in a decentralized storage 190 (e.g., non-fungible token (NFT) metadata database 195 in FIG1A ).

[0106] The smart contract application 107 may return (see 203 and 204) the address where the metadata is stored to the owner's electronic device 210. The owner's electronic device 210 may then update (see 211) the product and service database 191 to store detailed information about the product or service.

[0107] The smart contract application 107 may update (see 205) the non-fungible token (NFT) metadata storage address of the product or service in the product and service database 191. The owner electronic device 211 may obtain (see 212) detailed information of the product or service and store (see 213) the attribute information in the product and service database 191.

[0108] From the perspective of a tenant or buyer, they can search for and acquire existing products or services for lease or purchase (as shown in 209), or they can send a new order request to the owner's electronic device 210 (as shown in 208), such as requesting a new lease period or a closing date for a purchase contract. If the owner approves the tenant's or buyer's request, the owner's electronic device 210 may request the generation of one or more new non-fungible tokens (NFTs) and store additional records in the database. If the tenant or buyer 221 finds a product or service they are interested in, the system may send a verification request to the smart contract (as shown in 206) to verify that the specific product or service is actually available. The tenant's or buyer's electronic device 220 may retrieve detailed product information from the product and service database 191 (as shown in 209). The tenant's or buyer's electronic device 220 may also use the address retrieved from the real estate database 191 to retrieve non-fungible token (NFT) metadata from decentralized storage 190 (as shown in 207).

[0109] Figure 3A is a functional diagram illustrating an example of metadata stored when performing a split operation on an inheritable non-fungible token (NFT), to which various aspects of the present invention relate. Figure 3B is a functional diagram illustrating an example of metadata stored when performing a merge operation on two inheritable non-fungible tokens (NFTs), to which various aspects of the present invention relate. Figure 3C is a functional diagram illustrating an example of metadata stored for a non-inheritable non-fungible token (NFT), to which various aspects of the present invention relate.

[0110] In the examples of Figures 3A and 3B, each non-fungible token (NFT) 320-325 may contain the following product-related metadata. Similar discussions apply to services. Token identifier (token_id) 331 is a unique identifier for the non-fungible token (NFT). Product identifier (product_id) 332 is a pointer to the original product. Properties 333 contains all properties that describe the non-fungible token (NFT), including time limit (such as the product's useful life), space (such as the product's location or region), coverage (such as insurance or license for legal use of the product), etc.

[0111] The non-fungible token (NFT) type (nft_type) 334 is a Boolean value indicating whether the non-fungible token (NFT) is inheritable. For example, a non-fungible token (NFT) generated for the purpose of house or vehicle rental may be inheritable, while a non-fungible token (NFT) used to represent a vehicle renter's driver's license may not be inheritable. The storage address (storage_address) 335 indicates the storage location of the non-fungible token (NFT) in the non-fungible token (NFT) metadata database 195. Inheritable non-fungible tokens (NFTs) can be split into smaller non-fungible tokens (NFTs) or merged into larger non-fungible tokens (NFTs). All types of non-fungible tokens (NFTs) (inheritable and non-inheritable) can be stored in decentralized storage 190.

[0112] To retrieve NFTs from the database, some embodiments may include a product and service database 191 storing a key-value pair that maps a product identifier (product_id) to a list of non-fungible tokens (NFTs) associated with the product. For example, a homeowner may divide the home into different rooms and generate multiple non-fungible tokens (NFTs). These non-fungible tokens (NFTs) may have the same product identifier (product_id), and the addresses of all of these non-fungible tokens (NFTs) may be stored in a value field of the product and service database 191. The design pattern 340 shows a key-value pair where the product identifier (product_id) corresponds to multiple non-fungible tokens (NFTs) storage address 1 (storage_addr1) to storage address x (storage_addrx).

[0113] Each non-fungible token (NFT) may contain its corresponding real estate information (such as a house, room, etc.). Inheritable non-fungible tokens (NFTs) can be split or merged at the request of the owner. In the example of Figure 3A, the inheritable non-fungible token (NFT) 320 is split into two inheritable non-fungible tokens (NFTs) 321 and 322. The expanded view 370 illustrates how the metadata stored in the decentralized storage 190 is split into non-fungible tokens (NFTs) 321 and 322, which are generated from the metadata of the non-fungible token (NFT) 320.

[0114] In the example of Figure 3B, two inheritable non-fungible tokens (NFTs) 323 and 324 are merged into one inheritable non-fungible token (NFT) 325. Expanded view 380 illustrates how the metadata for non-fungible token (NFT) 325 stored in decentralized storage 190 is generated from the metadata for non-fungible tokens (NFTs) 323 and 324.

[0115] In Figure 3A, based on the splitting criteria, the original non-fungible token (NFT) 320 has multiple divisible sub-attributes 331-335. For each sub-attribute, the sum of all split non-fungible tokens (NFTs) 321-322 should be equal to the original non-fungible token (NFT) 320, and there should be no overlap between the split non-fungible tokens (NFTs). For example, in Figure 3A, the sum of the time sub-attribute t1 of the non-fungible token (NFT) 321 and the time sub-attribute t2 of the non-fungible token (NFT) 322 is equal to the time sub-attribute t of the non-fungible token (NFT) 320. The sum of the space sub-attribute s1 of the non-fungible token (NFT) 321 and the space sub-attribute s2 of the non-fungible token (NFT) 322 is equal to the space sub-attribute s of the non-fungible token (NFT) 320. The sum of the coverage sub-attribute c1 of the non-fungible token (NFT) 321 and the coverage sub-attribute c2 of the non-fungible token (NFT) 322 is equal to the coverage sub-attribute c of the non-fungible token (NFT) 320.

[0116] In FIG3B , the split non-fungible tokens (NFTs) 323-324 can be merged into a larger non-fungible token (NFT) 325 according to the merging criteria. Each sub-attribute 331-335 in the non-fungible token (NFT) 325 should be the union of the same attributes of the non-fungible tokens (NFTs) 323-324. For example, in FIG3B , the sum of the time sub-attribute t1 of the non-fungible token (NFT) 323 and the time sub-attribute t2 of the non-fungible token (NFT) 324 is equal to the time sub-attribute t of the non-fungible token (NFT) 325. The sum of the space sub-attribute s1 of the non-fungible token (NFT) 323 and the space sub-attribute s2 of the non-fungible token (NFT) 324 is equal to the space sub-attribute s of the non-fungible token (NFT) 325. The sum of the coverage sub-attribute c1 of the non-fungible token (NFT) 323 and the coverage sub-attribute c2 of the non-fungible token (NFT) 324 is equal to the coverage sub-attribute c of the non-fungible token (NFT) 325.

[0117] In Figure 3C, the non-fungible token (NFT) type 334 indicates that the NFT is non-inheritable. The design pattern 345 shows a key-value pair in the product and service database 191, where the product identifier (product_id) corresponds to a non-fungible token (NFT) storage address 1 (storage_addr1). The corresponding product may be, for example, a driver's license issued by a particular state. In this example, the time attribute may be the validity period of the driver's license, the spatial attribute may be empty, and the coverage attribute may indicate the driving privileges in which areas the driver's license is applicable. The expanded view 385 illustrates an example of metadata for a non-fungible token (NFT) 333 stored in the decentralized storage 190.

[0118] Some embodiments provide two NFT splitting mechanisms: automatic splitting and on-demand splitting. Real estate owners can choose the splitting mechanism that best suits their needs. Figure 4 is a functional diagram illustrating an example of how the automatic splitting mechanism divides a NFT into equal shares, a feature related to various aspects of the present invention.

[0119] In the example of FIG4 , an automatic splitting mechanism is selected for a non-fungible token (NFT) represented by a product or service (e.g., real estate). Horizontal line 430 represents the timeline, and vertical line 435 represents the current time. As shown in FIG4 , the example includes two operational stages 401 and 402. In stage 401, platform 105 (see FIG1A-1B ) may automatically split the non-fungible token (NFT) equally into multiple inheritable non-fungible tokens (NFTs) 411-416 based on the time interval or spatial division criteria specified by the owner.

[0120] For example, if a property owner chooses to rent the property for six equal time periods (one cycle per week), six non-fungible tokens (NFTs) 411-416 can be generated, each corresponding to a one-week rental period. In addition to dividing the property into multiple rental periods, the owner can also divide the property into multiple rentable spaces (for example, a house can be divided into multiple rooms), and each space can then be rented for equal time periods. In this case, each independent space will generate a non-fungible token (NFT) for each specified time period. Under the automatic division mechanism, the owner also needs to specify the maximum length of time the property can be rented. In the example of Figure 4, the maximum rental length of the property is six weeks (i.e., six equal weekly cycles).

[0121] If the total time or space of the parent NFT is greater than the interval or split share specified by the owner, the original NFT (parent NFT) will be split. As shown in stage 401, all child NFTs are initially held by the owner (as shown in 410), and the first leased NFT begins at the time point 405 specified by the owner.

[0122] Stage 402 shows the status of the non-fungible token (NFT) at time t1 (i.e., a point in time after time t0). At stage 402, non-fungible tokens (NFTs) 413 and 415 have been purchased by the tenant (see 425), non-fungible tokens (NFTs) 414 and 416 are still held by the property owner (see 420), and non-fungible tokens (NFTs) 411 and 412 have expired (see 450). The storage address of the non-fungible token (NFT) metadata can be stored in, for example, the product and service database 191 in Figure 1A.

[0123] Expired non-fungible tokens (NFTs) 411-412 may have been transferred to the tenant and the lease has ended, or may not have been rented to anyone. Some implementations may set up an automatic cleanup task to automatically clean up expired non-fungible tokens (NFTs) and other non-fungible tokens (NFTs) that do not meet the share size at regular intervals to optimize database storage.

[0124] In the example of FIG4 , the product or service represented by the non-fungible token (NFT) may be a house or a vehicle, and if the tenant no longer uses the non-fungible token (NFT) 415, they can send a request to the owner of the property or vehicle to return the non-fungible token (NFT) 415 to the owner. The request may be verified, and if approved by the owner, the non-fungible token (NFT) 415 will be transferred back to the owner, and the tenant may receive a full or partial refund of the rent in accordance with the lease agreement.

[0125] It is important to note that non-fungible tokens (NFTs) 413 and 415 belong to the tenant throughout the lease period and automatically expire at the end of the lease period. Depending on the terms of the smart contract between the property owner and the tenant, the tenant may be allowed to resell non-fungible tokens (NFTs) 413 and 415 before their expiration, for example, to sublease the property (i.e., conduct a secondary lease).

[0126] Figures 5A and 5B are functional diagrams illustrating examples of on-demand splitting and merging of inheritable non-fungible tokens (NFTs), to which various aspects of the present invention relate. Horizontal line 530 represents the timeline, and vertical line 535 represents the current time. In the examples of Figures 5A-5B, the owner of a product or service (such as real estate) may choose to list the property on a rental market in an on-demand rental manner. In some embodiments, the owner can also specify a minimum term for the lease. For example, if the owner does not want the property to be rented out on a daily basis, a minimum lease term (e.g., five days, one week, one year, etc.) can be specified.

[0127] Figures 5A-5B illustrate three operational stages 501-503. In stage 501, when a property owner lists a property on the rental market according to the on-demand segmentation mechanism, a parent non-fungible token (NFT) 510 may be generated. For example, the owner may provide the necessary instructions, including the time period requested by the tenant (if segmented by time) or the space to be leased (if segmented by space).

[0128] At stage 502, the system receives a request from a tenant to lease two parts of a parent non-fungible token (NFT) 510. The request may be verified and approved by the owner of the parent non-fungible token (NFT) 510. The backend server 115 ( FIG. 1A ) may then activate the smart contract application 107 to perform the non-fungible token (NFT) splitting task 591.

[0129] The two parts 531 and 532 may be two separate time periods, or different rooms in a house. After the split task is completed, a new non-fungible token (NFT) 581 may be created, which contains the requested parts 531 and 532 of the original non-fungible token (NFT) 510. At the same time, a new non-fungible token (NFT) 582 may be generated to store the remaining part of the original non-fungible token (NFT) 510. At stage 502, the left part 588 of the original non-fungible token (NFT) 510 has expired, so the new non-fungible token (NFT) 582 generated for the owner does not contain the expired part.

[0130] It is important to note that NFT 582 is not the original NFT 510, but a new copy of the remaining portion of the original NFT 510, as NFTs do not natively support split operations. Therefore, the system creates a new NFT 582 as the successor of the original NFT 510. At the end of stage 502, the new NFT 581 is owned by the tenant, while the new NFT 582 is owned by the owner of the original NFT 510. The original NFT 510 is destroyed in the background to ensure that there is no overlap between NFTs.

[0131] At stage 503, the tenant has only used the first portion 531 of the non-fungible token (NFT) 581, while the second portion 532 remains unused. In addition, the two portions 587 and 588 of the non-fungible token (NFT) 582 have expired. In the example of Figures 5A-5B, the tenant sends a request to the owner of the non-fungible token (NFT) 582 at stage 503, hoping to return the second portion 532 of the non-fungible token (NFT) 581, and the request may be verified and approved by the owner of the non-fungible token (NFT) 582.

[0132] In this case, the backend server 115 (Figures 1A-1B) may activate the merge function of the smart contract 107 to merge (see 592) the remaining portion 432 of the non-fungible token (NFT) 581 and the remaining portion of the non-fungible token (NFT) 582. Before performing the merge, the system will perform a verification process to check whether the non-fungible token (NFT) is invalid, expired, or conflicting. If the verification is successful, the system will generate a new non-fungible token (NFT) 489, which contains the unused portions of the non-fungible tokens (NFTs) 482 and 481 and merges all their details. At the same time, the non-fungible tokens (NFTs) 482 and 481 are destroyed (for example, by activating the destroy function 157 in the smart contract 107 (Figure 1A)).

[0133] It is important to note that, whether split automatically (as shown in Figure 4) or on-demand (as shown in Figures 5A-5B), all non-fungible tokens (NFTs), including parent non-fungible tokens (NFTs) and child non-fungible tokens (NFTs), must not overlap in time and space. This ensures the uniqueness of each non-fungible token (NFT), making the tenant the only legitimate user within the time and space specified by the non-fungible token (NFT).

[0134] 6 is an example sequence diagram 600 illustrating the data exchange process when minting a new non-fungible token (NFT) in various aspects of the present invention. Referring to FIG6 , the client device 120 may be any electronic device 120 in FIG1A , and the device may belong to the original owner of a product or service (e.g., real estate, a vehicle, etc.). The backend server 115 may be the backend server 115 in FIG1A . The minting function 154 and the verification function 158 of the smart contract may be similar to the corresponding functions in FIG1A . The non-fungible token (NFT) property management service 148 may be similar to the non-fungible token (NFT) property management service 148 in FIG1B .

[0135] The client device 120 may send a request to the backend server 115 (e.g., to the non-fungible token (NFT) property management service 148) in step 605 to mint a new non-fungible token (NFT). For example, the user of the client device 120 may own real estate or a vehicle and need to mint a property non-fungible token (NFT) to put the asset on the blockchain. In another case, the user of the client device 120 may own a registered property non-fungible token (NFT) but need to mint an inheritable non-fungible token (NFT) to rent the asset.

[0136] The backend server 115 may send a request at step 610 to provide necessary verification information. For example, if a property non-fungible token (NFT) is minted, a building certificate, title certificate, or proof of ownership may be required. If a lease non-fungible token (NFT) is minted, a property non-fungible token (NFT) may be required to prove ownership of the asset. The client device 120 may provide the required verification information at step 615.

[0137] The backend server 115 may send the verification information to the verification function 158 of the smart contract 107 to perform the verification process at step 620. For example, the backend server 115 may activate the verification function 158 of the smart contract 107 and call the verification ABI interface 125 through the platform 105 of Figure 1B.

[0138] The verification function 158 may perform verification at step 625. After the verification is completed, the smart contract verification function 158 may send the verification result to the non-fungible token (NFT) title management service 148 at step 630. If the verification fails, the non-fungible token (NFT) title management service 148 may send a verification failure notification to the client device 120 at step 635. If the verification passes, the non-fungible token (NFT) title management service 148 may send the minting parameters to the minting function 154 of the smart contract at step 640. For example, the non-fungible token (NFT) title management service 148 may activate the minting function 154 of the smart contract 107 and call the minting ABI interface 121 through the platform 105 of Figure 1B.

[0139] The identifier may be, for example, a unique address assigned to each individual, entity, token, or non-fungible token (NFT) by the blockchain network 150 of Figure 1A. A non-limiting example is an Ethereum (ETH) address, such as 0x4866328DA1FE4FEAC2081942BBC0C6A053726483, where 0x represents a hexadecimal number.

[0140] The minting function 154 may mint a new non-fungible token (NFT) (e.g., a new title non-fungible token (NFT) or a lease non-fungible token (NFT), as the case may be) in step 645. The smart contract minting function 154 may send the minted non-fungible token identifier (NFTID) to the backend server 115 in step 650. The minted non-fungible token identifier (NFTID) may be a unique identifier generated by the blockchain network 150, as described in step 640. It should be noted that if the minting function 154 fails to successfully mint the non-fungible token (NFT), then it may not send the minted non-fungible token identifier (NFTID), but may send an error message (not shown) to the backend server.

[0141] The backend server 115 may send the minted non-fungible token identifier (NFTID) to the client device 120 at step 655. Alternatively, if the minting function fails, the backend server 115 may send an error message (not shown) to the client device 120.

[0142] 7 is an example sequence diagram 700 illustrating the data exchange process for splitting an inheritable parent non-fungible token (NFT) and generating a child non-fungible token (NFT) in various aspects of the present invention. Referring to FIG7 , the client device 120 may be any electronic device 120 in FIG1A , and the device may belong to the owner of an inheritable non-fungible token (NFT) (e.g., a property or a vehicle). The backend server 115 may be the backend server 115 in FIG1A-1B . The split function 155 , the minting function 154 , the destruction function 157 , and the verification function 158 may be similar to the corresponding functions in FIG1A .

[0143] The client device 120 may send a request to the backend server 115 (e.g., to the non-fungible token (NFT) property management function 148 of the backend server 115) in step 705 to request the splitting of a parent non-fungible token (NFT). For example, an inheritable non-fungible token (NFT) may have been minted to represent a real estate or vehicle (as described in FIG6 ), and the client device 120 may request that the non-fungible token (NFT) be split into multiple child non-fungible tokens (NFTs) based on dimensions such as time and space in order to lease these child non-fungible tokens (NFTs). In some embodiments, when the client device 120 needs to create a rental listing to rent a portion of a property or to rent an entire property or vehicle for a specific period of time, a request to split a rental non-fungible token (NFT) may be sent.

[0144] The backend server 115 may send a request at step 710 for information needed to perform the NFT split. For example, the backend server 115 may need to know how a rental property is divided by time or space, or how a vehicle is divided by time. This information may include the ownership NFT and / or lease NFT, the specific allocated space or time period, or the coverage of the product or service. The client device 120 may provide the required information at step 715.

[0145] The NFT title management service 148 may send a request to perform verification on the split of the leased NFT at step 720. This verification may include verifying whether the title NFT has been modified since the leased NFT was minted, verifying the current authorization details of the leased NFT, and determining whether there are any spatial or temporal conflicts.

[0146] The smart contract verification function 158 may verify the splitting of the leased non-fungible token (NFT) at step 725. The smart contract verification function 158 may send the verification result to the non-fungible token (NFT) title management service 148 at step 730. If the verification fails, the non-fungible token (NFT) title management service 148 may notify the client device 120 of the verification failure at step 735. If the verification passes, the non-fungible token (NFT) title management service 148 may send a request to the smart contract's split function 155 at step 740 to perform the non-fungible token (NFT) split operation. For example, the non-fungible token (NFT) title management service 148 may activate the smart contract's split function 155 by calling the split ABI interface 122 of the platform 105 in FIG. 1B . The split request may include the following parameters: the leased non-fungible token identifier (NFTID), the number of child non-fungible tokens (NFTs), and the time-based and / or space-based splitting method.

[0147] The split function 155 of the smart contract may request the minting function 154 of the smart contract to mint child non-fungible tokens (NFTs). Prior to doing so, the system verifies the information provided by the client device 120 to ensure that the request is valid and there are no conflicts. The minting function 154 may generate new child rental non-fungible tokens (NFTs) in step 745, where each child non-fungible token (NFT) is a unique subset of the parent non-fungible token (NFT) in time or space dimensions. If the parent non-fungible token (NFT) cannot be split, the minting function 154 of the smart contract may generate an error message (not shown).

[0148] The smart contract minting function 154 may send the ID of the child non-fungible token (NFT) to the non-fungible token (NFT) title management service 148 of the backend server 115 at step 750. The child non-fungible token identification (NFTID) may be a unique identifier generated by the blockchain network 150, as described in step 640.

[0149] The non-fungible token (NFT) property management service 148 of the backend server 115 may send the identifier of the child non-fungible token (NFT) to the client device 120 in step 755. In addition, the split function 155 of the smart contract may request the destruction function 157 of the smart contract to destroy the parent leased non-fungible token (NFT) (i.e., the undivided leased non-fungible token (NFT)). The destruction function 157 of the smart contract may destroy the parent non-fungible token (NFT) in step 760. More details about the destruction function will be described in Figure 9. It should be noted that step 760 may be performed before or at the same time as step 750 or 755.

[0150] Figure 8 is an example sequence diagram 800 illustrating the data exchange process when merging multiple non-fungible tokens (NFTs) to generate a merged non-fungible token (NFT) in various aspects of the present invention. Referring to Figure 8, the client device 120 may be any electronic device 120 in Figure 1A, which may belong to the owner of multiple inheritable non-fungible tokens (NFTs), and these non-fungible tokens (NFTs) may be merged into a larger non-fungible token (NFT). The backend server 115 may be the backend server 115 in Figures 1A-1B. The merge function 156, the minting function 154, the destruction function 157 and the verification function 158 may be the same as the corresponding functions in Figure 1A.

[0151] In step 805, the client device 120 may send a request to the backend server 115 (e.g., to the non-fungible token (NFT) title management service 148) to merge multiple child non-fungible tokens (NFTs) into a single merged NFT. For example, there may be multiple inheritable NFTs (e.g., multiple rooms in a house, multiple time-period leases on a house, multiple time-period leases on a vehicle, etc.), and the client device 120 may wish to merge these NFTs into a larger NFT based on factors such as time or space. The backend server 115 may send a request in step 810 for information necessary to merge the NFTs. For example, the backend server 115 may need to understand the attributes or aspects of the products or services to be merged. This information may include a specific allocated space or time period and the coverage of the products or services. The client device 120 may provide the information necessary to merge the NFTs in step 815.

[0152] The backend server 115 may send a request to verify the merge request at step 820. For example, the backend server 115 may activate the verification function 158 of the smart contract 107 of FIG. 1A to perform the verification process by calling the verification ABI interface 125 of the platform 105 of FIG. 1B.

[0153] The verification function 158 of the blockchain smart contract application 107 may verify the merge request at step 825. This verification may include ensuring that there is no temporal or spatial overlap between the non-fungible tokens (NFTs) to be merged. The smart contract verification function 158 may send the verification result to the non-fungible token (NFT) title management service 148 at step 830. If the verification fails, the non-fungible token (NFT) title management service 148 may notify the client device 120 of the verification failure at step 835. If the verification passes, the non-fungible token (NFT) title management function 148 of the backend server 115 may send a request to merge the non-fungible tokens (NFTs) to the smart contract's merge function 156 at step 840. For example, the backend server 115 may submit the information required to merge the non-fungible tokens (NFTs) to the smart contract's merge function 156 by calling the merge ABI interface 123 of the platform 105 of Figures 1A-1B. The information required to merge a non-fungible token (NFT) may include the identity of the child NFT, the specific allocated space or time period, and the coverage of the product or service.

[0154] The smart contract's merge function 156 may request the smart contract's minting function 154 to merge multiple non-fungible tokens (NFTs) into one merged non-fungible token (NFT) and perform the merge operation based on the received information. The minting function 154 may generate a new merged non-fungible token (NFT) in step 855, where each merged non-fungible token (NFT) may contain merged properties of the child non-fungible tokens (NFTs), such as time and space information. If the child non-fungible tokens (NFTs) cannot be merged, the smart contract's minting function 154 may generate an error message (not shown). The smart contract's minting function 154 may send the ID of the merged non-fungible token (NFT) to the non-fungible token (NFT) property management service 148 of the backend server 115 in step 850. The identifier of the merged non-fungible token (NFT) may be a unique identifier generated by the blockchain network 150, as described in step 640. The non-fungible token (NFT) title management service 148 may send an identifier of the merged non-fungible token (NFT) to the client device at step 855 .

[0155] The smart contract's merge function 156 may request the smart contract's destroy function 157 to destroy the child non-fungible token (NFT). The smart contract's destroy function 157 may destroy the child non-fungible token (NFT) in step 860. More details about the destroy function are described in Figure 9. It is important to note that step 860 may be executed before or simultaneously with steps 850 or 855.

[0156] Figure 9 is an example sequence diagram 900 illustrating the data exchange process when destroying a non-fungible token (NFT) in various aspects of the present invention. The destruction request may come from a client device (e.g., as shown in Figure 9) or from other internal services of the smart contract (e.g., as shown in Figures 7-8). The destruction function of the smart contract may perform specific operations to remove the discarded non-fungible token (NFT) from the blockchain. Technically, non-fungible tokens (NFTs) that have been on the chain cannot be tampered with or directly deleted. A solution widely adopted by the decentralized community may be applied to the smart contract logic of this embodiment. For example, the destruction function of the smart contract may send the discarded non-fungible token (NFT) to an empty address that is not used by any other user on the blockchain. In this case, this technique is equivalent to deleting the non-fungible token (NFT) from the blockchain.

[0157] 9 , client device 120 may be any electronic device 120 in FIG. 1A , and the device may belong to the owner of a non-fungible token (NFT) that needs to be destroyed. Backend server 115 may be backend server 115 in FIG. 1A-1B . Destroy function 157 may be smart contract destroy function 157 in FIG. 1A .

[0158] The client device 120 may send a request to the backend server 115 (e.g., to the non-fungible token (NFT) title management service 148) in step 905 to request the destruction of a non-fungible token (NFT). The backend server 115 may send a request in step 910 to provide information required to destroy the non-fungible token (NFT). For example, the backend server 115 may request authorization to ensure that the non-fungible token (NFT) can be destroyed. The client device 120 may provide the requested information in step 915, for example, authorization information to destroy the non-fungible token (NFT).

[0159] The backend server 115 may submit a request to the destruction function 157 of the smart contract to execute the destruction of the non-fungible token (NFT) at step 920. For example, the backend server 115 may submit the information required to destroy the non-fungible token (NFT) to the destruction function 157 of the smart contract by calling the destruction ABI interface 124 of the platform 105 in Figure 1B.

[0160] The destroy function 157 of the smart contract may destroy the non-fungible token (NFT) based on the received information at step 925. The destroy function 157 may send a destruction confirmation message to the backend server 115 at step 930. The backend server 115 may send the destruction confirmation message to the client device 120 at step 935.

[0161] FIG10 is a flow chart illustrating an example process 1000 for registering real estate or vehicles on a blockchain in various aspects of the present invention. In some cases of this embodiment, the process 1000 may be executed by a processor of the backend server 115 of FIG1A-1B.

[0162] Referring to Figure 10 , the system may receive a request from the electronic device of a real estate or rental vehicle owner to register the leased real estate or rental vehicle on the blockchain at step 1005. The system may send a request to the owner's electronic device at step 1010 to obtain information necessary to verify the registration request. The system may receive information from the owner's electronic device used to verify the registration request at step 1015. For example, this information may include, but is not limited to, ownership information of the real estate or vehicle.

[0163] The system may determine whether the registration verification is successful at step 1020. If the registration verification fails, the system may send a failure message to the owner's electronic device at step 1025. Process 1000 may return to step 1010, as described above.

[0164] If the registration verification is successful, the system may determine in step 1030 whether a non-fungible token (NFT) already exists for the real estate or vehicle to be put on the chain. If so, process 1000 may continue to step 1040, as described below. Otherwise, the system may mint a non-fungible token (NFT) for the real estate or vehicle in step 1035. For example, as described in Figure 6, a non-fungible token (NFT) may be minted for the real estate or vehicle. In step 1040, the system may update the product and service database to store information about the real estate or vehicle that has been put on the chain. Process 1000 may end.

[0165] 11 is a flow chart illustrating an example process 1100 for performing automatic splitting of a leased non-fungible token (NFT) in various aspects of the present invention. In some cases of this embodiment, process 1100 may be executed by a processor of the backend server 115 of FIG. 1A-1B .

[0166] 11 , the system may receive a request from a client device of a leased non-fungible token (NFT) owner at step 1105 specifying criteria for automatic splitting of the leased non-fungible token (NFT). For example, the client device may request that a rentable item be listed for rent and may define splitting criteria, such as the lease time interval for real estate or a vehicle and indivisible portions (if applicable). The system may send a request to a split function of a blockchain smart contract at step 1110 to split the leased non-fungible token (NFT) based on the received criteria (e.g., as described in FIG. 7 ). For example, the backend server 115 of FIG. 1A-1B may use the split ABI interface 122 to activate the split function 155 of the smart contract application 107 and send the splitting criteria to the split function 155.

[0167] The identifier of the minted child non-fungible token (NFT) may be received at step 1115. The identifier of the child non-fungible token (NFT) may be a unique identifier as described in Figure 7. The unique identifier can be used to locate the storage location of the split non-fungible token (NFT) metadata, for example, as described in Figures 3A-3B.

[0168] The ID of the child NFT may be sent to the NFT owner's client device at step 1120. For example, upon completion of the task, a list of newly minted NFTs may be returned to the parent NFT owner along with confirmation that the parent NFT was destroyed.

[0169] Product and service publication information and corresponding automatically split non-fungible tokens (NFTs) may be received from the client device of the non-fungible token (NFT) owner at step 1125. For example, the client device of the non-fungible token (NFT) owner may publish its products and services to the product and service database 191 of Figure 1A, along with the non-fungible token (NFT) metadata address, making it searchable by the client devices of tenants and buyers.

[0170] Rentable items may be listed on the rental marketplace, and search criteria for products and services may be received from the tenant's client device at step 1130. The search results may be sent to the tenant's client device at step 1135. An order request may be received from the tenant's client device at step 1140 to purchase one or more child non-fungible tokens (NFTs). For example, the tenant's client device may search for newly released services and products and send an order request to the backend server.

[0171] Authorization for the order may be received from the owner of the child NFT at step 1145. For example, the backend server may send the order request to the client device of the child NFT owner for approval and may receive authorization information from the owner's client device to complete the order.

[0172] The order request may be sent to one or more functions of the smart contract at step 1150 to execute the transaction. For example, depending on the type of order, the backend server 115 may activate the appropriate function of the smart contract via the corresponding ABI. The smart contract may validate the request and notify the backend server 115. The backend server 115 may then activate the smart contract's transfer function 159 to complete the transfer of the child non-fungible token (NFT) and credit any prepaid rental fees to the owner's account. For example, the backend server may call the transfer ABI 126 of Figure 1B to activate the smart contract's transfer function 159.

[0173] A confirmation of order completion may be received from the smart contract at step 1155. For example, backend server 115 may receive confirmation of order completion from smart contract application 107 of FIG. 1A. Subsequently, the product and service database may be updated at step 1160 to record the new owner of the child non-fungible token (NFT). Process 1100 may end at this point.

[0174] Figure 12 1A-1B , the process 1200 may be executed by a processor of the backend server 115 of FIG. 1A-1B , in some cases of the present embodiment.

[0175] refer to Figure 12 , the product or service release information and its detailed attributes may be received from the client device of the owner of the product or service in step 1205. For example, the client device may send a detailed description of the property or vehicle and the desired usage (e.g., lease) time interval to the backend server 115. In step 1210, a request may be sent to the minting function of the blockchain smart contract to mint a new inheritable lease non-fungible token (NFT) based on the detailed description. For example, the backend server 115 of Figures 1A-1B may call the minting ABI 121 to activate the minting function 154 of the smart contract to mint the parent lease non-fungible token (NFT), as described in Figure 6.

[0176] The identifier of the parent rental NFT may be received and the products and services database updated at step 1215. The identifier of the parent rental NFT may be sent to the owner's client device at step 1220 and the rentable item may be listed on the rental marketplace.

[0177] The search criteria may be received from the tenant's client device and matched to products or services associated with a non-fungible token (NFT) at step 1225. The search results may be sent to the tenant's client device at step 1230. An order request may be received from the tenant's client device at step 1235 to purchase a sub-lease NFT.

[0178] The order request may be sent to the split function of the smart contract at step 1240 to mint the child NFT and destroy the parent non-fungible token (NFT). For example, the backend server 115 may receive approval from the owner's client device and call the split ABI interface 123 to activate the split function 155 of the smart contract application 107 to mint the child non-fungible token (NFT) and destroy the parent non-fungible token (NFT), as described in Figure 7.

[0179] The order completion confirmation may be received from the smart contract at step 1245. The product and service database may be updated at step 1250 to record the owner information of the sub-rental non-fungible token (NFT) and notify the owner's client device. For example, the new owner of one sub-non-fungible token (NFT) may be a tenant who rents a portion of a property or a period of time, while the owner of another sub-non-fungible token (NFT) may be the original owner of the property or vehicle who retains the sub-non-fungible token (NFT) to represent the unrented time or space of the property or vehicle.

[0180] Afterwards, the owner and tenant can continue their transactions, and the client device can access the storage address of the non-fungible token (NFT) metadata it requested. Flow 1200 may end here.

[0181] Figure 13A FIG1 is a functional block diagram illustrating the system design of a decentralized real estate and vehicle rental system in various aspects of the present invention. Client devices 1301-1303 may be any of the client devices 120 in FIG1A . Platform 105, smart contract application 107, product and service database 191, contract database 192, and backend server 115 may be the same as their counterparts in FIG1A .

[0182] Some embodiments may include multiple backend servers 115 and may use load balancers 1331-1334 to distribute network traffic to the backend servers 115. Other embodiments may not use load balancers 1331-1334.

[0183] Figure 13A Two workflows for different clients are shown. In the first workflow, an owner's client device 1301 (e.g., a real estate or vehicle owner's client device) may publish new products and services, such as rental information for real estate, vehicles, etc. The client device 1301 may also list inheritable non-fungible tokens (NFTs) for sale.

[0184] The request sent by the client device 1301 may be sent to the listing service 131 through an available API, and the corresponding metadata is stored in the non-fungible token (NFT) metadata database 195 of the decentralized storage 190 (Figure 1A) using the specified mode 1350 or 1370 ( Figures 13B-13C During this process, the smart contract application 107 may verify the format and legitimacy of the non-fungible token (NFT) provided by the client device 1301, and then store its token identifier (Token ID) in the product and service database 191 through the listing service 131.

[0185] In a second workflow, a tenant's client device 1302 (e.g., a tenant's client device of real estate or a vehicle) and a buyer's client device 1303 (e.g., a buyer's client device that can inherit a non-fungible token (NFT)) may send an interface API request to a search service 1306 to search for rental information for real estate or a vehicle. The search service 1306 may be the search component 141 or 147 of FIG. 1B . The search service 1306 may query the product and service database 191 to obtain matching results that meet the specified search filter criteria and keyword parameters. These results may be returned to the client devices 1302-1303 for the user to view.

[0186] After finding a property or vehicle that meets their requirements, the tenant's client device 1302-1303 may submit an application request through a contract service 1307, which is configured to manage rental applications, quotes, and contracts. The contract service 1307 may be the contract component 134, 140, or 146 of Figure 1B.

[0187] Once the owner accepts the offer or approves the application, a contract may be created and shared with both parties. After the contract is signed, the transaction service may pass the request to the non-fungible token (NFT) title management service 148, which calls the non-fungible token (NFT) smart contract application 107 to perform operations related to the non-fungible token (NFT), such as generating a new child non-fungible token (NFT) for the tenant or transferring an existing child non-fungible token (NFT) to the tenant. The tracking history database 194 may record the movement history of the rental vehicle.

[0188] When the lease ends, or if the tenant needs to terminate the lease early, the tenant must return the child NFT, which triggers a call to the smart contract application 107. This action then triggers the NFT property management service 148 and the smart contract component 107 to execute the destruction of the child NFT (e.g., via a merge function). The metadata of the real estate may be stored in the NFT metadata database 195.

[0189] Figure 13B is a functional block diagram illustrating the real estate data database architecture of a decentralized real estate and vehicle rental system in various aspects of the present invention. Figure 13B As shown in the product and services database schema 1350, property identifier 1351 may be generated by combining the first two digits of the property type identifier with a random unique identifier to ensure uniqueness. In some embodiments, property identifier 1351 may be used as the primary key for property database 1310. Property type 1352 may indicate the type of property, such as residential or commercial. Location 1353 may be used as a sort key (or partition key) for database queries. Address field 1354 may store the address of the property.

[0190] The property token identifier (entity_token_id) 1355 is only required if the property is fully on-chain on the platform. The status field 1356 may indicate whether the property is currently listed or unlisted. The multiple listing identifier 1357 may indicate the property's identifier in a third-party multiple listing database.

[0191] The contract database 192 may store contract details between sellers and buyers, or landlords and tenants. Figure 13BAs shown in contract database schema 1360 , contract database 192 may include a contract identifier 1361 as a primary key, which serves as an identifier and is linked to the associated property identifier (entity_id) 1362 . Contract database 192 may also include a contract owner identifier 1363 as a partition key to store all properties owned by the same person and avoid network overhead. Contract database 192 may also include a tenant identifier 1364 . Additionally, an enumeration class (enum) parameter 1365 may indicate the status of the contract, such as signed, unsigned, or completed. An enumeration type is a special data type that allows a variable to be a collection of predefined constants.

[0192] Figure 13C 1 is a functional block diagram illustrating the vehicle data database architecture of a decentralized real estate and vehicle rental system in various aspects of the present invention. The metadata of the vehicle may be stored in the product and service database 191. Figure 13B As shown in the vehicle table of the products and services database schema 1370, a vehicle identifier 1371, a vehicle identification number (VIN) 1372, a vehicle type 1373, an ownership token number 1374, a lease token number 1375, an insurance token number 1376, and a status 1377 may be stored in the products and services database.

[0193] As shown in the figure, in the listing information table architecture 1380 of the product and service database, the listing number 1381, vehicle number 1371, owner number 1382, listing type 1383, status 1384 and price 1385 of the vehicle may be stored in the product and service database.

[0194] As shown in the figure, in the transaction record table schema 1390 of the contract database, a transaction number 1391, an associated shelf number 1381, an owner number 1382, a customer number 1392, a status 1393 and a price 1385 may be stored in the contract database.

[0195] Figure 14 is an example sequence diagram 1400 illustrating the data exchange process when a property or vehicle owner lists their asset for lease in various aspects of the present invention. Figure 14 , the owner client device 120, the backend server 115, and the smart contract application 107 may be the same as the corresponding components in Figures 1A-1B.

[0196] As shown, the owner's client device 120 may send a request to the backend server 115 to list a property or vehicle for rent at step 1405. The backend server 115 may send a confirmation request to the owner's client device 120 at step 1410. The owner's client device 120 may send and sign the confirmation at step 1415. For example, the confirmation request may trigger a Web3 wallet (such as MetaMask) to request the owner's digital signature.

[0197] If the owner confirms and signs, the backend server 115 may activate one or more functions of the smart contract application 107 (e.g., the minting function 155 of Figure 1A) through the smart contract minting ABI interface 121 (Figure 1B) in step 1420 to mint one or more child non-fungible tokens (NFTs) for leasing real estate or vehicles.

[0198] The smart contract application 107 may mint one or more child leased non-fungible tokens (NFTs) at step 1425. The smart contract application 107 may send the IDs of the child non-fungible tokens (NFTs) to the backend server 115 at step 1430. The backend server 115 may list the non-fungible tokens (NFTs) on the platform at step 1435. The backend server 115 may send confirmation of the successful listing to the owner's client device 120 at step 1440. For example, the backend server 115 may notify the owner that the child non-fungible tokens (NFTs) have been successfully generated and listed on the platform.

[0199] FIG15 is an example sequence diagram 1500 illustrating the data exchange process when a tenant successfully rents a listed property or vehicle, in accordance with various aspects of the present invention. Referring to FIG15 , the owner client device 1502 may be one of the electronic devices 120 in FIG1A , and the tenant client device 1504 may be another electronic device 120 in FIG1A . The smart contract application 107 and the backend server 115 may be the same as their counterparts in FIG1A-1B .

[0200] As shown, backend server 115 may receive a request to search for properties or vehicles from a tenant's client device 1504 at step 1505 . The request may include search criteria such as location, price, property or vehicle type, and rental duration. The search results may be sent from backend server 115 to tenant's client device 1504 at step 1510 .

[0201] The backend server 115 may receive a request to rent a property or vehicle from the tenant's client device 1504 at step 1515. The backend server 115 may send a confirmation request at step 1520. The tenant's client device 1504 may send and sign the confirmation at step 1525. For example, the confirmation request may trigger a Web3 wallet (such as MetaMask) to request the tenant's digital signature.

[0202] Backend server 115 may activate one or more functions of smart contract application 107 via smart contract ABI 108 ( FIG. 1A ) at step 1530 to complete the rental transaction. Smart contract application 107 may send payment information to backend server 115 at step 1535. For example, smart contract application 107 may send payment in the form of cryptocurrency, fiat currency, credit, etc. Smart contract application 107 may transfer ownership of one or more child non-fungible tokens (NFTs) to the tenant at step 1540. Smart contract application 107 may send a notification of successful rental completion to the owner's client device 1502 at step 1545. Smart contract application 107 may send a notification of successful rental completion to the tenant's client device 1504 at step 1550. Depending on the terms of the smart contract, the tenant may be able to re-lease (e.g., sublease) the child non-fungible tokens (NFTs) to continue renting the corresponding property or vehicle.

[0203] Figure 16 1A-1B is a flowchart 1600 illustrating how an electronic device may perform automatic division of an inheritable non-fungible token (NFT) in various aspects of the present invention. In some cases of this embodiment, process 1600 may be performed by a processor of a backend server 115 or an electronic device 120 of FIG. 1A-1B , which may be in communication with a distributed ledger system (e.g., a blockchain network 150).

[0204] refer to Figure 16 , the system may receive a request from the owner of a rentable item to list the item for rent at step 1605. For example, a rentable item may be any tangible product or intangible service that can be divided into non-overlapping time intervals and / or spaces, such as any of the products or services described above. The system may trigger the distributed ledger system to mint a rental non-fungible token (NFT) for the rentable item at step 1610 and assign it to the owner of the item. For example, the system may activate the minting function 154 of the smart contract 107 in Figure 1A to mint a rental non-fungible token (NFT) and assign it to the owner, as described in Figures 4, 6, and 11.

[0205] The system may receive a request from the owner of the rentable item to list the rentable item for a first time period, including instructions to further divide the time period into a plurality of rental time periods, at step 1615. For example, the request may come from the owner's electronic device, as described in step 1105 of FIG. 11 .

[0206] In response to the lease request, the system may trigger the distributed ledger system to mint a plurality of sub-lease non-fungible tokens (NFTs) at step 1620, where each sub-lease non-fungible token (NFT) is associated with one of the plurality of time periods. For example, the system may activate the split function 155 of the smart contract application 107 to mint the sub-lease non-fungible tokens (NFTs), as described in FIG3A , FIG7 , and step 1110 of FIG11 . The system may assign the sub-lease non-fungible tokens (NFTs) to the owner at step 1625 and destroy the original lease non-fungible token (NFT). For example, the system may activate the split function 155 of the smart contract application 107 to assign the sub-lease non-fungible tokens (NFTs) to the owner, as described in FIG9 and steps 1115-1120 of FIG11 .

[0207] The rentable items may be listed for rent in step 1715. For example, the rentable items may be listed as shown in Figures 1A-1B and Figure 12 The system may receive a request from a rental applicant to lease a second time period in the plurality of time periods at step 1720. For example, the rental request may be received as described in steps 1235-1240 of FIG. 11 .

[0208] In response to the lease request, the system may trigger the distributed ledger system to transfer the sub-lease non-fungible token (NFT) associated with the second time period to the lease applicant at step 1640. For example, the system may activate the transfer function 159 of the smart contract application 107 to transfer the sub-lease non-fungible token (NFT) associated with the second time period to the lease applicant. When the sub-lease non-fungible token (NFT) is successfully transferred to the lease applicant, the system may provide a lease success confirmation to the lease applicant and the owner of the rentable item. For example, the owner's and the tenant's electronic devices may receive a notification after the sub-non-fungible token (NFT) is successfully transferred. Process 1600 may end here.

[0209] Figure 17FIG1 is a flowchart 1700 illustrating how an electronic device may perform on-demand splitting of an inheritable non-fungible token (NFT) in various aspects of the present invention. In some cases of this embodiment, process 1700 may be performed by a processor of a backend server 115 or an electronic device 120 of FIG1A-1B , which may be in communication with a distributed ledger system (e.g., a blockchain network 150).

[0210] refer to Figure 17 , the system may receive a request from the owner of a rentable item at step 1705 to list the item for rent. For example, the rentable item may be any tangible product or intangible service that can be divided into non-overlapping time intervals and / or spaces, such as any of the products or services described above. The system may trigger the distributed ledger system at step 1710 to mint a rental non-fungible token (NFT) for the rentable item and assign it to the owner of the item. For example, the system may activate the minting function 154 of the smart contract 107 in Figure 1A to mint a rental non-fungible token (NFT) and assign it to the owner, as shown in Figures 5A, 6, and Figure 12 As stated.

[0211] The rentable items may be listed for rent in step 1715. For example, the rentable items may be listed as shown in Figures 1A-1B and Figure 12 The system may receive a request from a rental applicant at step 1720 to rent a first set of rentable items for one or more time periods. For example, the rental request may be as follows: Figure 12 Received in the manner described in steps 1225-1235.

[0212] In response to the lease request, the system may trigger the distributed ledger system to mint a first set of one or more sub-lease non-fungible tokens (NFTs) at step 1725, where each sub-lease non-fungible token (NFT) is associated with one of the first set of time periods. For example, the system may activate the split function 155 of the smart contract application 107 to mint the sub-lease non-fungible tokens (NFTs), as shown in Figures 3A, 7, and Figure 12 as described in step 1240.

[0213] The system may trigger the distributed ledger system to perform the following operations at step 1730: assign the first set of sub-lease non-fungible tokens (NFTs) to the lease applicant, mint a second set of one or more sub-lease non-fungible tokens (NFTs) for the leaseable item, which are valid for time periods other than the first set of time periods, assign the second set of sub-lease non-fungible tokens (NFTs) to the owner of the leaseable item, and destroy the original lease non-fungible token (NFT). For example, the system may activate the split function 155 of the smart contract application 107 to perform these operations, as shown in Figures 3A, 7, and 8. Figure 12 After the leased NFT is successfully minted and allocated, the system may send a confirmation of successful lease to the owner's and tenant's electronic devices. For example, after the leased NFT is successfully minted and allocated, the system may send a notification to the owner's and tenant's electronic devices confirming that the leased item for the first set of time periods has been successfully completed. Process 1700 may end at this point.

[0214] Although the above examples are primarily directed to leasing products and services using inheritable non-fungible tokens (NFTs), the methods, processes, and user interfaces described in this disclosure, such as the processes and methods described in Figures 1A-1B, 2, 3A-3C, and 4-17, can also be used to sell products and services with divisible ownership, such as artwork or collectibles. For the sale of products and services with divisible ownership, the system can mint inheritable ownership non-fungible tokens (NFTs) and inheritable sub-ownership non-fungible tokens (NFTs) to execute the processes and methods of this disclosure, rather than minting inheritable lease non-fungible tokens (NFTs) and inheritable sub-lease non-fungible tokens (NFTs). During the sales process, each sub-ownership non-fungible token (NFT) represents a portion of the ownership of the asset and can be traded or held independently to ensure a more flexible asset management approach and be suitable for property rights sharing models in decentralized markets.

[0215] The disclosed embodiments provide a technical advantage by utilizing the concept of inheritable parent non-fungible tokens (NFTs) and child non-fungible tokens (NFTs), which far exceeds the current state of the art. The inheritable structure of non-fungible tokens (NFTs) in this embodiment ensures refined control of asset rights and clearly distinguishes ownership from temporary use rights. In addition, the technical advantages of this solution also include the immutable records of the blockchain, which ensure a transparent and tamper-proof transaction history, thereby improving market trust and transaction security. The decentralized architecture reduces dependence on traditional intermediaries, reduces intermediary costs, and provides a standardized, secure, and globally accessible platform that allows users to directly manage and trade their digital assets without going through third-party agents, thereby improving market liquidity and promoting the development of digital property rights.

[0216] II. Decentralized Real Estate Platform

[0217] Renting a property typically involves an agreement whereby the tenant pays the landlord a fee for temporary use of the property. With the development of the internet, more and more online rental services are gradually replacing traditional offline ones, as their convenience and efficiency make the rental process smoother.

[0218] However, most online rental services still employ an intermediary model, in which a middleman (which can be a platform, an agency, or a real person) charges tenants and landlords a service fee to help them find the right tenant or property. This intermediary model presents numerous problems, one of which is the high service fees that both tenants and landlords pay, increasing rental costs for tenants and reducing landlords' profits. A more serious issue is that the middleman can be untrustworthy, and some may be scammers intent on defrauding tenants or landlords, leading to financial losses and misunderstandings on both sides.

[0219] The application of blockchain technology can address these issues and drawbacks. As a peer-to-peer decentralized distributed ledger, blockchain makes the record of any digital asset transparent and immutable, and operates without relying on third-party intermediaries. Blockchain is an emerging and revolutionary technology that has attracted significant public attention due to its ability to reduce risk and fraud in large-scale applications.

[0220] As mentioned above, NFTs (non-fungible tokens) are blockchain-based crypto assets that inherit all the advantages of blockchain, such as decentralization and security, while also possessing uniqueness and indivisibility. Each NFT is a crypto asset with unique characteristics that distinguish it from other NFTs on the blockchain. NFTs can represent objects such as artwork, music, videos, and game props. The most significant advantage of NFTs is provable ownership. Because NFTs are stored on a blockchain network, they can effectively tie ownership to a specific account. Most importantly, NFTs are indivisible and cannot be shared by multiple owners. Furthermore, the transparency of NFT ownership ensures that buyers (such as those leasing NFTs) are protected from fraudulent activity through counterfeit NFTs. In addition, non-fungible tokens (NFTs) are transferable and can be bought, sold, or traded on different platforms. Common non-fungible token (NFT) trading platforms include OpenSea, Rarible, etc.

[0221] While blockchain and non-fungible tokens (NFTs) have solved many problems in home rentals, applying blockchain / NFT technology to these applications still faces numerous challenges, primarily because the mechanisms and standards for leasing NFTs have yet to be fully developed or established. On the blockchain, users can easily transfer NFTs to another user, thereby changing ownership of the NFT. However, there is currently no existing technology or mechanism that can automatically return NFTs to their original owners at the end of the lease period, making the application of NFTs in rental scenarios still somewhat technically challenging.

[0222] To solve this problem, the present embodiment provides a credible and applicable mechanism, called the "parent-child non-fungible token (NFT)" mechanism, for non-fungible token (NFT) leasing, and applies the mechanism to house and vehicle leasing. The parent-child non-fungible token (NFT) mechanism in this embodiment has a technical advantage, namely, it allows the generation of time-based small non-fungible tokens (NFTs) (child non-fungible tokens (NFTs)) from the original non-fungible token (NFT) (parent non-fungible token (NFT)). During the validity period of the child non-fungible token (NFT), the child non-fungible token (NFT) holder can enjoy some rights and interests related to the parent non-fungible token (NFT), such as the right to use the real item (such as a house or vehicle) corresponding to the parent non-fungible token (NFT).

[0223] Figure 18 A is a functional diagram illustrating the high-level structure of a peer-to-peer housing rental management system 1810, according to various embodiments of the present disclosure. Figure 18 A. Landlord 1830 may be a property owner who wishes to rent out property 1840. Tenant 1850 may be a tenant who wishes to pay rent to obtain the right to lease property 1840. Platform 105 and blockchain network 150 can serve as a bridge between landlord 1830 and tenant 1850. The platform can call blockchain smart contract ABI interfaces (e.g., ABI interfaces 122-124 in Figure 1) to write and store information and records to the blockchain. Landlord 1830 and tenant 1850 can interact with platform 105 and blockchain network 150 via electronic device 120 and one or more networks 103 (e.g., as shown in Figure 1A).

[0224] Figure 18 B is a functional diagram showing how the parent-child non-fungible token (NFT) mechanism can build a trustworthy and applicable peer-to-peer house rental system 1820 according to various embodiments of the present disclosure. Figure 18B. After completing ownership verification, landlord 1830 can generate a parent non-fungible token (NFT) 1860 for their house 1840. Parent non-fungible token (NFT) 1860 may be used to represent the ownership and verification information of house 1840. Therefore, parent non-fungible token (NFT) 1860 may contain basic information about house 1840, such as address, owner, and house description (such as the number of rooms, number of bathrooms, and other amenities).

[0225] Whenever a landlord 1830 wants to rent out a property 1840, he or she can use the parent non-fungible token (NFT) 1860 to generate one or more child non-fungible tokens (NFTs) (1871-1872). These child non-fungible tokens (NFTs) 1871-1872 may represent certain temporary use rights of the property 1840. Therefore, the child non-fungible tokens (NFTs) 1871-1872 may contain rental information, such as the start time, end time, and rental price. Once a suitable tenant 1850 is found, the tenant 1850 may acquire the child non-fungible token (NFT) 1871 by purchasing or bidding. The landlord 1830 can then use the child non-fungible token (NFT) 1871 to rent the physical property 1840 to the tenant 1850. The landlord 1830 may retain the child non-fungible token (NFT) 1872 until the next tenant is found. At the same time, the original NFT 1860 may be destroyed (i.e., "burned") after the child non-fungible tokens (NFTs) 1871-1872 are generated.

[0226] Since only the child NFT 1871 is transferred during the lease, the tenant 1850 does not need to return the NFT 1871 to the landlord 1830. Because the child NFT 1871 contains an "end time" attribute 1873, when the lease expires, the child NFT 1871 automatically expires and may be destroyed (burned). Therefore, when the lease expires, the tenant 1850 must leave the house 1840 and ensure that the house is returned to the landlord 1830 on time, avoiding the breach of contract and disputes in the traditional rental model.

[0227] a. Real estate transaction process

[0228] Figure 19 An example process 1900 is shown for a landlord to rent out all or part of a property using a sub-NFT, according to various aspects of the present disclosure. In certain embodiments, process 1900 may be executed by a processor of a server, such as backend server 115 in Figures 1A-1B. Process 1900 is described in conjunction with Figures 20A-20D.

[0229] 20A-20D illustrate schematic front views of a client device 120 displaying an interface UI for a landlord renting out a property, according to various aspects of the present disclosure. The client device 120 may be any electronic device 120 shown in FIG. 1A , and the interface UIs 2001-2005 may be part of the interface UI 102.

[0230] refer to Figure 19 , a new listing and a list of available time periods may be received from the landlord's client device (step 1905). The landlord can decide whether to rent out the entire property or rent out one or more rooms or spaces for a specific time period. For example, option 2060 in FIG. 20A may be selected to display UI 2003 in FIG. 20C to create a new listing for the entire property or a portion of the property.

[0231] 20A , UI 2002 may include a banner 2030 and a display area 2050 for displaying one or more thumbnail images of a property. Selecting any thumbnail may enlarge the selected image in display area 2055. UI 2002 may also include a display area 2040 for entering property information and a display area 2045 for entering notes. UI 2002 may also include a list of rooms or spaces for rent 2065.

[0232] UI 2003 may include a banner 2070 and a display area 2075 for uploading a high-resolution image of the property. UI 2003 may include a display area 2080 for specifying detailed information about the property, such as a detailed description 2082 of the room being rented. UI 2003 may include a display area 2085 for setting the rent, a display area 2087 for setting the rental period, and a display area 2090 for selecting an authentication method. UI 2003 may include an option (e.g., a button) 2095 for submitting the property listing after all details have been entered.

[0233] refer to Figure 19 Depending on the intended listing, the parent rental NFT may be divided by property, time, space, etc. (step 1910). For example, as shown in FIG20B , the parent NFT 2091 of a property may be divided into child NFTs 2091-2093 to cover different parts of the property (e.g., different rooms or suites) or different rental time periods.

[0234] The parent rental NFT may be destroyed (step 1915). Access designation information, such as facial recognition, fingerprint, NFC home key, etc., may be received from the landlord (step 1920). For example, if the landlord has installed the required equipment on the available rooms and / or house, they can assign access methods, such as fingerprint or NFC key, in the display area 2090 of Figure 20B. The child rental NFT may be listed as a searchable rental item (step 1925).

[0235] It may be necessary to determine whether there are any rental applications (step 1930). If not, process 1900 may end. Otherwise, the application may be sent to the landlord for review (step 1935). Interface UI 2004 of Figure 20C displays the applications or bids received by the property. Interface UI 2004 includes a banner 2095 and a display area 2097, which may display a list of applications and bids received by the property. The landlord can accept any application or bid by selecting the corresponding accept option 2098.

[0236] It may be necessary to determine whether an acceptance has been received from the landlord (step 1940). For example, whether the landlord has selected any of the options 2098 in Figure 20D. If no acceptance has been received, the process 1900 may return to step 1930, as described above.

[0237] Otherwise, upon receiving the landlord's acceptance, the lease agreement may be finalized (step 1945). For example, the system may automatically generate a lease contract ready for signing. The interface UI 2005 of Figure 20D may be displayed on the landlord portal for processing the property lease contract. The interface UI 2005 may include a banner 2072 and a display area 2073 for displaying the property lease contract. To ensure that the transaction is seamless, the system may generate an editable contract draft 2074 for the landlord, accompanied by a slider in the display area 2076. The slider is used to allow the landlord to transfer sub-lease non-fungible token (NFT) tokens from the landlord to the tenant.

[0238] The tenant and landlord can use the connected wallet component of the smart contract application to connect a Web3 wallet (e.g., MetaMask or Coinbase Wallet) to provide their identity and / or signature to approve the contract. Any payment from the tenant to the landlord can be transferred directly to the landlord. The rental non-fungible token (NFT) may be transferred from the landlord to the tenant (step 1950). Then, process 1900 may end.

[0239] FIG21 illustrates an example process 2100 for a new tenant to lease a property using a decentralized real estate platform, according to various aspects of the present disclosure. The process 2100 may be executed by a processor of a server, such as the backend server 115 in FIG1A-1B , in some embodiments. The process 2100 may be combined with Figure 22 A-22B is described.

[0240] Figure 22 A-22B shows a schematic front view of a client device, with a screen displaying an interface UI for a tenant in the process of renting a property, according to various aspects of the present disclosure. Figure 22 A-22B, the client device 120 may be any electronic device 120 in FIG. 1A , and the UIs 2203 - 2204 may be part of the UI 102 .

[0241] Referring to FIG. 21 , search keywords and filter criteria may be received from the tenant's client device (step 2110). For example, the search keywords and filter criteria may include location, number of bedrooms and bathrooms, price range, etc. The search results may be sent (step 2117) to the tenant's client device. For example, the system may query different databases to find results that match the search keywords and filter criteria. An example of a search result returned by process 2100 is as follows: Figure 22 A. UI 2203 may include a banner 2260 and a display area 2265 for displaying one or more thumbnail images of the property. Selecting any thumbnail may enlarge the selected image in display area 2266. UI 2203 may also include a display area 2280 for displaying a property description. In embodiments where the property is divided by space, UI 2203 may display additional information, such as photos of each space (e.g., photos of each room) and the rental price of that space.

[0242] It may be necessary to determine whether the tenant wants to apply to rent the property (at step 2120 of Figure 21). Figure 22 A's UI 2203 illustrates different possible rental actions that a tenant may take. UI 2203 may include a display area 2270 for displaying the requested rental price, a display area 2275 for displaying an access method (e.g., facial recognition, non-fungible token (NFT) key, fingerprint, QR code, etc., selected by the landlord), and a description 2280 of the property.

[0243] If the tenant does not wish to apply to rent the property, process 2100 may return to step 2110, as described above. Otherwise, a request from the tenant for more information or to schedule a viewing may be received (step 2125). For example, the tenant may choose Figure 22A, option 2282 to view the property or seek further assistance from the landlord.

[0244] It may be necessary to determine whether the tenant is interested in applying for the lease (at step 2130 of FIG. 21 ). For example, it may be necessary to determine option 2284 ( Figure 22 A) is selected. If not, process 2100 may return to block 2110 as described above. Otherwise, tenant identity verification may be required (step 2130). For example, the tenant may use the smart contract application's Connect Wallet component to connect a Web3 wallet (e.g., MetaMask or Coinbase Wallet) to verify the tenant's identity. The tenant may provide photo identification, biometric information (e.g., fingerprint), etc. Confidential information may be securely stored on the blockchain network and destroyed immediately after the tenant moves out.

[0245] The tenant's lease application may be received (step 2145) and may be forwarded (step 2145) to the landlord. Figure 22 B's interface UI 2204 may be displayed to process the property purchase contract. Interface UI 2204 may include a banner 2290 and a display area 2291 for displaying the property purchase contract. Interface UI 2204 may include a slider in display area 2292. The slider is configured to allow the landlord to transfer a sub-lease non-fungible token (NFT) token to the tenant. If the tenant accepts the details of the contract, they can sign the contract online through the interface in display area 2292. Once the tenant signs the contract, they may receive a sub-lease non-fungible token (NFT) provided by the landlord.

[0246] The landlord and tenant may also use the connected wallet component of the smart contract application to connect a Web3 wallet (e.g., MetaMask or Coinbase Wallet) to provide their signatures to sign the contract (e.g., as shown in display areas 2293 and 2294). Any payments made by the tenant to the landlord may be transferred directly to the landlord.

[0247] It may be necessary to determine whether a confirmation of acceptance has been received from the landlord (at step 2150 of Figure 21). If no confirmation is received, process 2100 may return to step 2145, as described above. Otherwise, when the landlord's confirmation of acceptance is received, the lease contract may be finalized (step 2155). For example, a lease contract may be automatically generated and ready for signing. The tenant and landlord may use the connected wallet component of the smart contract application to connect a Web3 wallet (such as MetaMask or Coinbase Wallet) to provide their signatures to sign the contract. Any payments made by the tenant to the landlord may be transferred to the landlord. Ownership of the lease non-fungible token (NFT) may be transferred from the landlord to the tenant (step 2160). Process 2100 may then end.

[0248] b. Non-fungible token (NFT) classification concepts and examples

[0249] Non-fungible tokens (NFTs) representing real estate have several key properties, including token identifiers, property identifiers, token status, availability, etc. To ensure the uniqueness of token identifiers, some implementations use the SHA-256 hash algorithm based on the original property when minting. The property identifier is a unique identifier for a house, starting with one or two digits indicating the property type, followed by a code of approximately six alphanumeric characters, enabling it to support more than 10 9 (10 billion) properties. The token state is represented by an enumeration value indicating whether the token is active, inactive, or invalid.

[0250] Figure 23A -23D illustrates an example of a non-fungible token (NFT) partitioning for real estate rentals, a concept that is applicable to this specific use case because properties can be partitioned by time or space. Figure 23A Examples of two types of non-fungible tokens (NFTs) that may be used in a decentralized real estate platform are shown. According to various aspects of the present disclosure, property metadata 2360 may include a property identifier 2351, an address 2352, and a property location 2353 (e.g., GPS or latitude and longitude coordinates).

[0251] The property non-fungible token (NFT) 2301 can be used as proof of ownership of the property, while the rental non-fungible token (NFT) 2302 can be used when the property is ready to be rented out. Landlords have the flexibility to rent out part of the space and choose to rent out only a single room instead of the entire house (as shown in 2301).

[0252] Further references Figure 23A, non-fungible tokens (NFTs) 2301 and 2302 are functional diagrams that illustrate how property non-fungible tokens (NFTs) and lease non-fungible tokens (NFTs) work. According to various aspects of the present disclosure, property non-fungible tokens (NFTs) 2301 can be attached by a builder when a new house is built, or attached when an existing property is first registered on the platform of this embodiment.

[0253] A non-fungible token (NFT) 2301 serves as a property's title certificate, providing buyers with indisputable proof of ownership. The NFT 2301 may include a token identifier 2311, a property identifier (or entity identifier) ​​2312, a type 2313, and a token state 2314.

[0254] When a homeowner decides to rent out their property for the first time, a rental non-fungible token (NFT) 2302 may be generated. The rental non-fungible token (NFT) 2302 may include a token identifier 2321, a property identifier (or entity identifier) ​​2312, a type 2323, and a token state 2324.

[0255] In addition to all the properties of the property non-fungible token (NFT) 2301, the rental non-fungible token (NFT) 2302 may also include an important "availability" attribute 2325. The "availability" attribute 2325 may be a mapping table that provides a complete layout of available spaces, including information such as space name, identifier, and available time period.

[0256] Figure 23B The present invention illustrates an example of leasing a room in two different time periods and the corresponding leasing non-fungible token (NFT) division process, according to various aspects of the present disclosure. Figure 23B As shown, to identify each available space, the system may rely on the property identifier 2312 of the parent non-fungible token (NFT) 2302 and add a unique or sequential identifier to generate an identifier 2371, such as Figure 23B 2773 for each additional room. For example, if the property identifier 2312 of the house is reac0b5v, then Room B might be assigned an identifier 2372 of reac0b5v_002. Additionally, during the NFT splitting process, the availability data of the parent NFT is used to generate new child NFTs upon request, as a child NFT is always a subset of the parent NFT.

[0257] refer to Figure 23B, shows an example of partitioning a rental NFT 2303 into two mutually exclusive NFTs based on spatial and temporal availability. As shown in the upper half, the rental NFT 2302 is first partitioned by space (as shown at 2386) into multiple child NFTs (for clarity, only the child NFT 2303 for room B is shown). The child NFTs 2303 can be further partitioned by time (as shown at 2387) to be used to rent room B during different time periods. Thus, the parent NFT and the child NFTs form a hierarchical NFT structure, where each NFT can contain one or more child NFTs, and each child NFT can also contain one or more other child NFTs to cover different spatial and temporal aspects of the rental property.

[0258] Leased NFT 2304 represents Room B and has two available time periods: April 1st to April 14th, and May 15th to May 31st. This NFT is further divided into two other leased NFTs 2304 and 2305, each with mutually exclusive available time periods. The number of generations of NFTs is virtually infinite, as each NFT may have the ability to generate new offspring. Figure 23B In the example of , non-fungible token (NFT) 2304 and non-fungible token (NFT) 2305 are descendants of non-fungible token (NFT) 2303 and may represent the sublease of room B.

[0259] Figure 23C is a time diagram illustrating an example of an invalid time-partitioned non-fungible token (NFT) where the authorization time exceeds the available time range for existing leased non-fungible tokens (NFTs). In accordance with various aspects of the present disclosure, Figure 23C In the example above, the owner of NFT 2303 attempts to publish a listing authorizing Room B to be rented out from April 1 to April 19, 2023, but this time period is outside the availability of NFT 2303. This scenario is invalid because new NFTs generated from a parent NFT must always be a subset of their parent NFT.

[0260] Figure 23D is another time diagram illustrating another example of an invalid time-partitioned non-fungible token (NFT) that violates the mutual exclusivity principle of child non-fungible tokens (NFTs). In Figure 23D, both leased non-fungible token (NFT) 2306 and non-fungible token (NFT) 2303 are split from leased non-fungible token (NFT) 2302, so they should share the same time authorization. However, in this example, the partial time period allocated for non-fungible token (NFT) 2303 conflicts with the April 15th to April 19th time period between non-fungible token (NFT) 2306, which is logically impossible and therefore invalid.

[0261] c. Property access (hardware)

[0262] Due to the characteristics of house rental, the existing platform lacks automation, so landlords and tenants may encounter cumbersome processes when obtaining access rights to the house. Therefore, landlords usually need to hand over the keys to the tenants in person, or use remote-controlled door locks, but this poses a security risk to both parties. The decentralized real estate platform of the present invention provides a variety of identity authentication methods, including face recognition, fingerprint authentication, password input, QR code and NFC home access key. Landlords and tenants can flexibly choose the access method for their house or room. Specifically, landlords can select an available identity authentication method when posting a house (for example, as shown in display area 2090 of Figure 20C). Similarly, tenants can choose their preferred verification method and provide the necessary biometric information for authentication in advance.

[0263] The house door lock of the present invention provides a technical advantage in that the door lock is controlled and managed by the platform rather than the landlord. The door lock can be automatically set after the lease contract is signed and authorized by the tenant's lease non-fungible token (NFT) details. Figure 24 A-24E illustrate different ways of accessing a house, providing an automated and secure solution. Security locks 2410, 2420, and 2430 may include a processor and a computer-readable medium, and may be remotely connected to the backend server 115 of Figures 1A-1B via one or more networks 103.

[0264] Figure 24 A is a functional diagram showing an example of a door lock equipped with a fingerprint reader 2403 and a numeric keypad 2402, according to various aspects of the present invention. Figure 24 A. When signing the lease agreement, the tenant can agree to provide their fingerprint to the backend server 115. The platform 105 can remotely program the lock 2410 to recognize the fingerprint as a valid entry method during the lease period. After the lease period ends, the backend server 115 can remotely configure the lock 2410 to no longer allow access using the tenant's fingerprint.

[0265] Further references Figure 24 A, the tenant can select a character sequence as the door lock password, and the backend server 115 can remotely program the keypad 2402 to recognize the character sequence during the rental period and allow the security lock 2410 to be unlocked.

[0266] Figure 24 B is a functional diagram showing an example of using facial recognition to access a house, according to various aspects of the present invention. As shown, the security lock 2420 may include a high-resolution camera 2404 and an optional display screen 2405. The high-resolution camera 2404 must meet the minimum requirements for facial recognition, for example, not less than 1080p (1920x 1080 pixels). In some embodiments, the security lock 2420 may be equipped with a higher-end camera system, such as one that supports 4K resolution, night vision, or a depth sensor for 3D facial recognition. The optional display screen 2405 may be used to help the user adjust their position for better authentication, and may also be used for video calls so that the landlord can provide guidance and assistance.

[0267] When signing the lease agreement, the tenant can agree to provide a facial photo to the backend server 115. The platform 105 can then remotely program the lock 2420 to recognize the face as a valid entry method during the lease period. After the lease period ends, the backend server 115 can remotely configure the lock 2420 to no longer allow the tenant to enter the property using facial recognition.

[0268] Figure 24 C is a functional diagram showing how to use a QR code (QR code) or NFC home access key to access a house, according to various aspects of the present invention. Figure 24 As shown in Figure C, the security lock 2430 may include a QR code scanner 2431. The QR code scanner 2431 can be used to scan the QR code provided by the tenant, enabling the system to identify their identity. It should be noted that in some embodiments, other codes, such as barcodes, can also be used. Therefore, the scanner can also be configured as a barcode scanner. In addition to, or instead of the QR code (or barcode) scanner 2431, the security lock 2430 can also include an NFC scanner 2432, which can be used to scan NFC tags or signals from NFC-enabled smartphones, enabling the system to accurately identify the tenant's identity.

[0269] The tenant can provide or be assigned a QR code, barcode, and / or NFC tag when signing the lease. Platform 105 can remotely program lock 2430 to recognize the designated QR code, barcode, and / or NFC tag as a valid entry method during the lease period. After the lease period ends, backend server 115 can remotely configure lock 2430 to no longer allow the tenant to enter the property using the designated QR code, barcode, and / or NFC tag.

[0270] Figure 24 D is a functional diagram illustrating how a tenant can access their rental property using NFC, according to various aspects of the present invention. Mobile device 120 may be the tenant's mobile device. Lease agreement information, such as the property address and lease term, may be displayed on mobile device 120 by clicking on a non-fungible token (NFT) icon 2490.

[0271] Figure 24 D has four operational stages 2441-2444. In stage 2441, after purchasing a rental non-fungible token (NFT) and generating a contract, the tenant receives an email or text message (e.g., sent to mobile device 120) from platform 105 (Figures 1A-1B). Option 2447 allows the tenant to set a password and obtain an NFC tag.

[0272] At stage 2442, the renter may select option 2448 (e.g., a button) to add the NFC tag to the wallet of the mobile device. At stage 2443, the NFC tag is successfully added to the wallet 2449. At stage 2444, the renter may bring the mobile device 120 close to the security lock 2430, causing the mobile device 120 to provide an NFC signal, thereby unlocking the security lock 2430.

[0273] Figure 24 E is a functional diagram showing how a tenant can use a QR code (QR code) to access his / her rental property according to various aspects of the present invention. Figure 24 In E, the tenant can click a button to obtain the QR code required to enter the house. Mobile device 120 may be the tenant's mobile device. Figure 24 E has two operational stages 2461-2462. In stage 2461, after purchasing a rental non-fungible token (NFT) and generating a contract, the tenant receives an email or text message (e.g., sent to mobile device 120) from platform 105 (Figures 1A-1B).

[0274] In stage 2461, after purchasing a rental non-fungible token (NFT) and generating a contract, the tenant receives an email or text message from platform 105 (Figures 1A-1B) (e.g., sent to mobile device 120). Option 2467 may allow the tenant to set a password and obtain a QR code. In stage 2462, by selecting option 2469 (e.g., a button), a QR code 2468 may be displayed on the screen display 2470 of mobile device 120. The tenant can bring the mobile device 120 close to the security lock 2430 so that the QR code 2468 is scanned and recognized by the QR code scanner 2469 on the security lock 2430.

[0275] As mentioned above, landlords and tenants can flexibly choose any type of authentication method based on their own circumstances. Some implementations may require at least two authentication methods, one as the primary method and the other as a backup method in case of partial system failure.

[0276] d. Customer service components and marketing platform

[0277] In certain embodiments, the platform 105 of Figures 1A-1B is customizable. In these embodiments, users can implement their own services under specific conditions. It is important to note that the platform 105 is not limited to real estate or vehicle transactions, but is highly scalable and can adapt to different industry needs. The range of available functionality is extended to meet various needs. For example, in a situation where a property owner is unable to repay the outstanding mortgage, or a large number of buyers show interest in the same property, an auction may be required, which requires a bidding service. Bidding services are similar to ordinary contract services in some aspects, but the property does not have a fixed selling price. Therefore, additional logic needs to be added to the traditional transaction process. The following example provides a non-limiting example of customizing the platform 105 to accommodate real estate transactions.

[0278] To support this use case, users can extend the transaction logic of the contract service by inheriting the logic code. This allows them to create custom implementations without having to conform to standard transaction types. The technical advantage of providing this flexibility is that it allows users to tailor the real estate transaction process to their needs.

[0279] Figure 25 is a functional block diagram illustrating how custom services can be integrated into the platform and introducing an open source marketplace to facilitate the exchange and sharing of these services. The diagram shows the platform 105's built-in (or standard) services 2501, which can be extended, as well as user-defined services 2521. A matching service 2502 provides basic search functionality, but users may require a more advanced search engine to find ideal properties or attract more buyers. Therefore, a machine learning recommendation service 2504 based on a user's historical search history and interests can be implemented. Furthermore, there may be transaction methods beyond the scope of standard contract services. For example, an individual could enter into a transaction with a financial institution that allows a homeowner to apply for a home equity loan 2505 or a home improvement loan 2507 based on the current value of their property. Furthermore, additional services can be created from scratch, such as a rating service 2506 (supporting customer or property ratings and reviews) and a bidding and auction service 2508 (supporting bidding and auctions).

[0280] Custom services can access existing databases in the database cluster 2515, including the Products and Services database 191 and the Contracts database 192, but by default, access is limited to read-only permissions. Optional databases 2510 can be assigned upon request if necessary. Data partitioning can be handled automatically by the system or specified by the developer.

[0281] To enable users to fully utilize the custom services created by other developers, certain implementations may establish an open-source service marketplace 2511 to promote sharing and reduce the development effort required to customize the platform. Developers may choose to open-source their code, in keeping with the transparency principles of blockchain applications. Developers are also encouraged to provide intuitive APIs and detailed documentation to facilitate user experience. Furthermore, this marketplace may incorporate a rating system to reward high-quality developers and encourage the community to contribute high-quality custom services.

[0282] III. Decentralized Vehicle Trading Platform

[0283] The implementation in this invention provides a decentralized vehicle trading and record-keeping platform that provides transparency and integrity to market and historical data. The platform utilizes non-fungible tokens (NFTs) to assign vehicle ownership and control access rights. The platform also integrates remote tracking devices and smart car keys and locks.

[0284] The decentralized vehicle trading platform in this example facilitates vehicle transactions and record management, ensuring market transparency and data integrity. The platform utilizes non-fungible tokens (NFTs) to assign vehicle ownership and control access rights. Furthermore, the platform integrates with remote tracking devices and smart keys and locks, providing a seamless user experience.

[0285] a. System Overview

[0286] Vehicles, such as cars, yachts, drones, airplanes, and helicopters, are movable objects and therefore well-suited for blockchain technology. The decentralized vehicle trading platform in this embodiment provides solutions for buying, selling, renting, and restricting access to vehicles, while eliminating intermediaries in the transaction process. The technical advantage of blockchain technology is that all transaction details are stored on the blockchain, providing a transparent and secure system.

[0287] Vehicle leasing utilizes the aforementioned non-fungible token (NFT) segmentation technology. To facilitate vehicle leasing, leased non-fungible tokens (NFTs) can be divided based on the time of authorized use. The vehicle's ownership NFT and lease NFT are used in conjunction with two other NFTs: insurance NFTs and driver's license NFTs. The specific use of NFTs in vehicle leasing will be described in detail below in some embodiments.

[0288] The decentralized vehicle trading system 100 of an embodiment of the present invention may include the components shown in Figures 1A-1B. Maintaining a vehicle database is crucial for recording vehicle metadata. Stored information includes vehicle type, such as automobiles (sedans, sport utility vehicles (SUVs), trucks), watercraft (yachts, private passenger boats), motorcycles, recreational vehicles (RVs), all-terrain vehicles (ATVs), drones, airplanes, helicopters, etc. In addition, the database should also record the vehicle's status to indicate whether the vehicle is currently being leased, sold, or delisted. The vehicle identification number (VIN) can be used as a unique identifier for each entity, or a new unique identifier can be created for the record. Four different non-fungible token identifiers (NFT IDs) associated with the vehicle (property non-fungible token (NFT), lease non-fungible token (NFT), insurance non-fungible token (NFT), and driver's license non-fungible token (NFT)) can also be stored in the database. If the non-fungible token identifier (NFTID) has been generated, it can be recorded directly; otherwise, its value may be empty. Additionally, the database schema should include the status of the vehicle to identify whether the vehicle is in good condition or has been written off after an accident.

[0289] Products and Services Database 191 in Figure 1A can be used to store all current and historical vehicle listing information. Products and Services Database 191 may include a unique identifier as a primary key and a vehicle identifier in the vehicle database as a foreign key to facilitate linking back to the vehicle record. A Listing Type field can be used to determine whether a listing is a rental or sale listing. A Status field may display "On Market" to indicate that the vehicle is currently available on the market, or "Off Market" to store historical records. A Price field can be used to store the price of a specific vehicle listing.

[0290] Transaction database 193 in Figure 1A can be used to store detailed information about all transactions, including new purchases, sales, and leases. A UUID can be used to generate a unique identifier for each record. A vehicle identifier may be referenced as a foreign key from product and service database 191 to track the specific vehicle involved in a transaction. A type field may indicate the transaction category, including lease, purchase, or test drive. Lessee and buyer identifiers can be used to identify the two parties or users involved in the transaction. Finally, a status field may be used to indicate whether the transaction has been completed.

[0291] Tracking history database 194 in FIG1A can be used to store the vehicle's location history, with the recording period specified by the user. Tracking service 162 of vehicle access and usage component 160 in FIG1B can utilize this database. Preset refresh rates and storage limits can be defined, and outdated location data can be periodically cleared by automated tasks.

[0292] b. Vehicle transaction process

[0293] Figure 26 1A-1B . FIGURE 26 is a flowchart illustrating a process 2600 for renting a vehicle using a non-fungible token (NFT), in accordance with various aspects of the present disclosure. In certain embodiments, process 2600 may be executed by a processor of a server, such as backend server 115 in FIGURES 1A-1B . Process 2600 illustrates the process of renting a vehicle using a non-fungible token (NFT). All communications with the vehicle owner and renter in process 2600 are conducted via their respective electronic devices.

[0294] Reference Figure 26 The tenant may provide search keywords and filter criteria (at step 2610). For example, the search keywords and filter criteria may include vehicle type, color, price range, etc. The search results may be sent to the seller (at step 2615). For example, different databases may be queried to find matching results that meet the search keywords and filter criteria.

[0295] In some embodiments, a renter may search for a vehicle using the search component 141 in FIG. 1B . Figure 27 A-27D shows a schematic front view of a client device, showing the UI on the client device during the vehicle rental process, according to various aspects of the present disclosure. Figure 27 A-27D, the client device 120 can be any electronic device in FIG. 1A , and the UIs 2701 - 2704 can be part of the UI 102 in FIG. 1A .

[0296] Figure 27 UI 2701 of A shows a vehicle renter's landing page, where the renter can select the vehicle type and body style of their preference. It should be noted that the platform is designed to support transactions of a variety of vehicles, not just cars. Therefore, users can use the system of the present invention to rent cars 2711, boats 2712, motorcycles 2713, airplanes 2714, and other types of vehicles. Figure 27 In example A, a customer is looking for a car rental and may click on car icon 2711 to begin their vehicle search. As shown, car icon 2711 is displayed in solid lines, while icons for other types of vehicles 2712-2714 are displayed in dashed lines. Selecting car icon 2711 may reveal additional options 2715-2717 for searching by style. For example, a buyer can select from multiple subcategories, including sedans 2715, sport utility vehicles (SUVs) 2716, and electric vehicles (EVs) 2717, to narrow their search. Additionally, the user can enter search criteria in search area 2710.

[0297] After selecting the vehicle that best meets the renter's needs, Figure 27 B's UI 2702 may provide detailed information about the vehicle. UI 2702 may include a title, price, and a brief description 2760. A picture of the vehicle may be displayed in a display area 2765. More information 2770, such as vehicle information, onboard equipment, and owner notes, may be listed on the page. The renter may be provided with options (e.g., buttons) to rent the vehicle 2771, schedule a test drive 2772, or contact 2773 the owner for more information.

[0298] Reference Figure 26 , it can be determined (at step 2620) whether the tenant wishes to schedule a test drive. For example, it can be determined whether Figure 27 B. Schedule a test drive option 2772. If the buyer does not want to schedule a test drive, process 2600 may continue to step 2635 (described below).

[0299] Otherwise, the smart contract application may be activated to mint (at step 2625) a test drive rental NFT. The test drive rental NFT may be sent (at step 2630) to the renter's electronic device. The test drive rental NFT may be a short-term rental NFT provided by the vehicle owner that, along with the insurance NFT and the driver's license NFT, authorizes the buyer to access the vehicle for a specified period of time. A similar Figure 27 D's interface UI 2704 (described below) may be displayed to process a non-fungible token (NFT) vehicle test drive lease contract.

[0300] At step 2635, an offer may be received from a buyer. The system then determines whether the vehicle owner has accepted the offer at step 2640. If not, process 2600 returns to step 2610, as described above. Otherwise, if the vehicle owner accepts the offer, the renter's insurance policy is received at step 2645.

[0301] Figure 27 C's UI 2703 may be displayed on the renter's client device to provide proof of insurance coverage. In some embodiments, the renter is required to purchase or provide proof of insurance, as every vehicle requires valid insurance before it can be legally operated. Vehicle insurance is typically provided by the vehicle owner, while liability insurance and personal injury insurance may need to be provided through Figure 27 The display area 2792 of the interface UI 2703 in C is purchased. If the tenant has insurance that meets the requirements, option 2791 can be selected to upload and verify the insurance declaration page.

[0302] The lease agreement may be finalized at step 2650. For example, the agreement may be automatically generated by the agreement component 146 in FIG. 1B and prepared for the tenant to sign.

[0303] Figure 27 D's UI 2704 may be displayed to process a vehicle lease contract. UI 2704 may include a display area 2742 for displaying the vehicle lease contract. In addition, UI 2704 may include option 2746 for entering personal information, option 2747 for providing a driver's license photo, option 2744 for entering payment terms, and option 2743 for signing the contract to obtain a vehicle sub-lease non-fungible token (NFT) covering the lease period. Once the renter signs the contract, they can obtain the sub-lease non-fungible token (NFT) from the vehicle owner.

[0304] The renter and owner can also use the smart contract application's connected wallet component to connect a Web3 wallet (such as Metamask or Coinbase Wallet) to provide signatures to sign the contract. The buyer's payment may be transferred to the owner, and financial documents and other operations may be completed. At step 2655, the vehicle's sub-lease non-fungible token (NFT) may be transferred from the owner to the renter, and process 2600 may then end.

[0305] Figure 27 Figure E is a functional diagram illustrating how a renter can access important documents and non-fungible tokens (NFTs) through their electronic device, in accordance with various aspects of this specification. As shown, the user may first see a dashboard interface 2795 containing NFT information and a vehicle access tool 2796. All NFTs controlled by the user (e.g., driver's license NFT 2797, insurance NFT 2798, and rental NFT 2799) are displayed as solid lines within the NFT area. The user can click on each NFT to view more detailed information, such as insurance coverage, driver's license number, and expiration date. Upon signing the lease, the rental NFT can be transferred to the renter. In this example, the insurance NFT is missing, so the renter only has limited access to the vehicle and may not be able to start it. Insurance non-fungible tokens (NFTs) can be generated after the vehicle is rented by uploading documents. The new renter can complete the generation by uploading their ID and insurance coverage declaration page. Once the three necessary NFTs (lease, insurance, and driver's license) are ready, the renter will gain full access to their new vehicle.

[0306] When the renter taps the vehicle unlock button, the system may present a digital key card that supports NFC and / or ultra-wideband (UWB) technology, depending on their mobile device. The renter can choose to save the key card to their phone's built-in mobile wallet for easier access. Once on this page, the vehicle automatically unlocks by simply holding the phone to the vehicle's lock or, if UWB technology is supported, simply walking toward the door.

[0307] The tracking dashboard 2794 allows the renter to view the real-time location of the vehicle, set an alarm to help them find the vehicle, or capture images of the vehicle's surroundings. In addition, if the renter discovers that the vehicle has been stolen, they can also remotely lock the vehicle at any time. In this case, the vehicle's access rights will be revoked immediately. If the vehicle is still moving, the system may cause it to gradually slow down for safety reasons. For aircraft, if supported, an automatic landing procedure may also be triggered. A tracking interface similar to the tracking dashboard 2794 can also be provided to the vehicle owner's client device to help them locate the vehicle. If the owner discovers that the vehicle has been stolen or abused by the renter (for example, the vehicle has not been returned at the end of the lease period, or the renter has driven to a non-agreed area), the owner can also remotely lock the vehicle at any time.

[0308] Renters can click on the icon to view the corresponding non-fungible token (NFT) details, such as driver's license information, currently effective insurance coverage, and rental information including validity period or other rules. The interface of the vehicle access tool may be similar to the owner's version. Renters can track the vehicle's location at any time by clicking the positioning button, including real-time location, setting alarms to better find the vehicle, or taking pictures of the surrounding environment through the on-board camera. The vehicle locking function provides access to the vehicle key. If the owner manually locks the vehicle remotely, the renter will not be able to unlock or start the vehicle. At this time, the lock button may turn gray to indicate that it cannot be operated.

[0309] c. Application of the concept of non-fungible token (NFT) segmentation in vehicle transactions

[0310] The NFT splitting process involves splitting a NFT into two parts, each containing a portion of the original NFT's information and mutually exclusive. This theorem is particularly important in vehicle leasing use cases, where authorized usage time can serve as a divisible attribute. In addition, other basic NFT operations, such as ownership transfer and merging, can be used to manage vehicle ownership and access rights by serving as proof of ownership or usage rights.

[0311] Vehicle market applications may utilize various types of non-fungible tokens (NFTs), such as title / lease NFTs, insurance NFTs, and driver's license NFTs. Title NFTs may serve as virtual proof of ownership of a vehicle and can be used as proof of ownership. Lease NFTs may serve as licenses for test drives and leases and are typically separate from the title NFT. Driver's license NFTs can be used to prove that someone holds a valid driver's license. Because operating a vehicle requires proof of insurance and a driver's license, insurance NFTs and driver's license NFTs may serve as crucial tokens throughout the process.

[0312] When breaking down the details of a non-fungible token (NFT), each non-fungible token (NFT) type may have a "type" attribute in its schema to indicate its specific token type. Additionally, a "status" field may indicate whether the non-fungible token (NFT) is active or inactive. A property non-fungible token (NFT) may include a vehicle ID, while a rental non-fungible token (NFT) may also include an "availability" attribute that lists the time periods specified by the owner for which it can be rented. Similar to a rental non-fungible token (NFT), an insurance non-fungible token (NFT) may have a specific "coverage" attribute that may specify the authorized time period, as well as coverage details including coverage amount and deductible information.

[0313] Figure 28 A is a functional diagram illustrating the application of the concept of non-fungible tokens (NFTs) in vehicle transactions and highlighting the different types of non-fungible tokens (NFTs) used in the system. According to various aspects of the present disclosure, property non-fungible tokens (NFTs) may serve as proof of vehicle ownership, leasing non-fungible tokens (NFTs) may be used to confirm the legal right to use the vehicle lease, and insurance non-fungible tokens (NFTs) and driver's license non-fungible tokens (NFTs) may be used to prove the user's legal driving qualifications.

[0314] like Figure 28 As shown in Figure A, each vehicle 2805 may be assigned a title non-fungible token (NFT) 2810 when it leaves the factory or is newly added to the platform. This serves as proof of ownership and may be transferred from the manufacturer to the dealer during transportation. When the vehicle arrives at the dealer, an insurance non-fungible token (NFT) 2820 may be attached to the vehicle to provide insurance coverage while it is in the dealership.

[0315] When a vehicle is ready for rental by an individual owner or a rental company (as shown at 2825), a rental NFT 2830 for the vehicle may be minted, containing a list of available times indicated by the owner. Additionally, since most vehicles require insurance during operation, the owner may also segment the insurance NFT 2820 based on the time period for which the NFT 2830 is leased. For example, an insurance NFT 2835 may be minted to cover the insurance needs of the vehicle during the lease period. The renter may pay a fee to the owner to insure the vehicle and may purchase or provide their own insurance to cover personal injury, financial protection, and liability coverage.

[0316] To access a vehicle, a user may need to provide multiple non-fungible tokens (NFTs), such as a title / lease NFT, an insurance NFT, and a driver's license NFT. During the authentication process to unlock the vehicle or press the start button, the user needs to provide all required NFTs, and the requirements for these NFTs may vary depending on the use case. In other words, possessing different NFTs may grant users different access rights. In this way, it can be ensured that the vehicle operator always has the correct authorization to use the vehicle.

[0317] Figure 28 B shows an example of a vehicle lease that includes two separate time periods and their corresponding lease non-fungible token (NFT) splitting process, assuming that the original lease non-fungible token (NFT) specifies an available period of April 1 to April 14 and May 15 to May 31, according to various aspects of the present disclosure. In this case, the owner can split the lease non-fungible token (NFT) 2840 into two separate lease non-fungible tokens (NFTs) 2841 and 2842, each of which occupies a different time period, thereby allowing two different renters to use the vehicle.

[0318] To rent a vehicle, the renter may be required to provide a valid driver's license 2851-2852, as well as the insurance declaration page 2853-2854 of their insurance policy, whether purchasing a new policy or using existing insurance. New driver's license non-fungible tokens (NFTs) 2843-2844 may be minted from the corresponding driver's license 2851-2852. New insurance non-fungible tokens (NFTs) 2845-2846 may be minted from the corresponding insurance policy 2853-2854. Vehicle insurance non-fungible tokens (NFTs) 2847 may be minted from the owner's insurance policy 2857. The owner's vehicle insurance and the renter's personal liability insurance may then be combined into a combined insurance non-fungible token (NFT) 2848-2849, which can serve as virtual vehicle keys for later access and use of the vehicle.

[0319] Figure 28 C is a timeline chart illustrating an example of time-based segmentation of non-fungible tokens (NFTs), according to various aspects of the present disclosure, where the initial rental non-fungible token (NFT) 2890 is available from April 1 to April 14 and from May 15 to May 31, as shown in 2895, as indicated by authorized time periods 2870 and 2880. The dashed portion may represent the time period when the owner decides to remove the vehicle from the market. The two available time periods, one in April and one in May, are further segmented into two separate rental non-fungible tokens (NFTs), designated as rental non-fungible token (NFT) 2891 and rental non-fungible token (NFT) 2892. These two non-fungible tokens (NFTs) 2891-2892 may be assigned to the same customer or different customers. Once each rental non-fungible token (NFT) 2891-2892 is combined with the corresponding insurance non-fungible token (NFT) 2896-2897 and the corresponding driver's license non-fungible token (NFT) 2898-2899, the renter will have full access to the vehicle.

[0320] Non-fungible token (NFT) smart contract services play an important role in all non-fungible token (NFT) operations. The workflow and logic of common use cases are shown in the following flowchart. Figure 29 An example non-fungible token (NFT) workflow process 2900 for executing a new lease process is shown, which may be executed by a server processor, such as the backend server 115 in Figures 1A-1B, in accordance with various aspects of the present disclosure.

[0321] After the vehicle lease contract is signed, the non-fungible token (NFT) title management service may request a sales agreement and contract. For a lease transaction, operating the vehicle may require insurance and a driver's license. Regarding insurance, the platform 105 (Figures 1A-1B) may offer the renter two options: purchase new insurance or upload existing insurance.

[0322] refer to Figure 29 , it may be determined in step 2905 whether the lessee already has insurance. If so, the lessee's insurance non-fungible token (NFT) may be retrieved from the blockchain network (step 2910), and the process then proceeds to step 2920. Otherwise, a request may be sent to the lessee (step 2915) to purchase new insurance. In step 2920, a new insurance non-fungible token (NFT) may be minted. For example, after the lessee purchases liability insurance, the vehicle insurance and the liability insurance purchased by the lessee may be merged to mint a new insurance non-fungible token (NFT).

[0323] A determination may be made at step 2925 as to whether the lessee possesses a valid driver's license. If not, the process may terminate; otherwise, at step 2930, a new driver's license NFT may be minted or an existing driver's license NFT may be retrieved from the blockchain network. The signed lease contract may be received at step 2935. The lease NFT may be received from the blockchain network at step 2940. The lease NFT and insurance NFT may be transferred to the lessee at step 2945, and process 2900 may terminate. The test drive process may be similar to process 2900, but may be a simplified version of the lease process; for example, the test driver may not be required to sign a formal contract.

[0324] FIG30 illustrates an example process 3000 of steps that may be performed after a vehicle lease ends, which may be performed by a server processor, such as backend server 115 of FIG1A-1B, according to various aspects of the present disclosure. Referring to FIG30, the lessee's sub-lease NFT may be received from the blockchain network at step 3005. The lessee's insurance NFT may be received from the blockchain network at step 3010.

[0325] A determination may be made at step 3015 as to whether the lessee's sub-lease NFT has expired. If so, the lessee's sub-lease NFT may be destroyed at step 3020 and process 3000 proceeds to step 3030. Otherwise, a new lease NFT may be minted at step 3025 as a result of the combination of the lessee's sub-lease NFT and the vehicle owner's sub-lease NFT.

[0326] At step 3030, a determination may be made as to whether the lessee's insurance NFT has expired. If so, the lessee's insurance NFT may be destroyed at step 3035, with process 3000 terminating. Otherwise, at step 3040, a new insurance NFT may be minted as a result of combining the lessee's insurance NFT and the vehicle owner's insurance NFT, with process 3000 terminating.

[0327] Due to the specific nature of vehicle access, both the operator and passengers should be able to enter the vehicle, but only someone with a valid driver's license and insurance can start and operate the vehicle. Some implementations may provide limited access or full access, and these two different levels of access may have different requirements. Someone can unlock the car door by simply providing a property non-fungible token (NFT) (such as when the person is the vehicle owner) or a sub-lease non-fungible token (NFT) (such as when the person is a lessee). When someone decides to start the vehicle, the person may need to provide an insurance non-fungible token (NFT) and a driver's license non-fungible token (NFT). The system may generate a virtual vehicle key based on these three pieces of information.

[0328] FIG31 illustrates an example process 3100 for allowing a person to access a vehicle under different circumstances, which may be performed by a server processor, such as the backend server 115 of FIG1A-1B, according to various aspects of the present disclosure. Referring to FIG31 , a determination may be made at step 3125 as to whether a person possesses a valid title non-fungible token (NFT). For example, the person may be the owner of the vehicle and may provide a valid title non-fungible token (NFT) to the backend server 115. If so, the process proceeds to step 3130.

[0329] Otherwise, a determination may be made at step 3130 as to whether the person possesses a valid sub-lease NFT. For example, the person may be a vehicle lessee and may provide a valid sub-lease NFT to the backend server 115. If not, the person is neither the vehicle owner nor possesses a valid sub-lease NFT, and process 3100 may terminate.

[0330] At step 3135, it may be determined whether the person possesses a valid driver's license non-fungible token (NFT) and a valid insurance non-fungible token (NFT). If so, process 3100 proceeds to step 3145. Otherwise, at step 3140, an electronic key may be remotely generated that unlocks the vehicle's entry locks but does not activate the vehicle's ignition. Subsequently, process 3100 proceeds to step 3155.

[0331] At step 3145, an electronic key may be generated that can not only unlock the vehicle but also start the vehicle's ignition. The vehicle's remote programmable entry lock may be remotely programmed at step 3150 to allow the electronic key to start the vehicle. At step 3155, the vehicle's remote programmable entry lock may be remotely programmed to allow the electronic key to unlock the vehicle. Subsequently, at step 3160, the electronic key may be provided to the person's electronic device to access the vehicle. Process 3100 then ends.

[0332] d. Vehicle access hardware for applications

[0333] The hardware used in this system may include locks and tracking devices. Figure 32 A and 32B are functional diagrams illustrating the design of a smart vehicle lock, according to various aspects of the present disclosure, Figure 32 A shows two types of vehicle locks: an exterior lock 3210 and an interior lock 3220. The exterior lock 3210 may be mounted near an applicable vehicle door, such as a door pillar or door handle on a car, a door lock on a boat, or a door lock on another type of vehicle. The exterior lock 3210 may include a keypad 3211, an NFC reader 3212, and / or an ultra-wideband (UWB) sensor 3213 to provide a seamless and convenient user experience.

[0334] The interior lock 3220 may typically be located near the driver's seat and may be integrated into the vehicle's engine start button. Similar to the exterior lock 3210, the interior lock 3220 may include a UWB sensor 3221 or an NFC reader 3222 to ensure smooth functioning.

[0335] Details of the authentication steps are in Figure 32As shown in Figure B. The user may be able to access the key by clicking on the lock button 3231 and may add the key to their mobile wallet 3232 by clicking on the “Add to Wallet” button 3233. The key may automatically update if the information of the non-fungible token (NFT) in hand changes. The access level of the key may vary depending on the type of non-fungible token (NFT) held by the user. For example, the key may have full access rights, including the ability to unlock the car doors and start the vehicle, only when the operator holds all three valid non-fungible tokens (NFTs) (i.e., the title / lease non-fungible token (NFT) 3291, the insurance non-fungible token (NFT) 3234, and the driver's license non-fungible token (NFT) 3292). Figure 32 In example B, the insurance non-fungible token (NFT) 3234 is missing (indicated by the dotted line), which may limit the user's full access to the vehicle (as shown in 3290).

[0336] On supported devices, the user may simply walk up to the vehicle, and the ultra-wideband sensor 3235 may automatically detect the signal and unlock the doors. Based on the details of the non-fungible token (NFT), the locks and buttons on the vehicle may exhibit different behaviors as described above. If the mobile device or vehicle does not support UWB technology, NFC 3236 may be used as a backup access method. As with many vehicles currently on the market, the user may simply tap their phone to the NFC reader to unlock the vehicle.

[0337] Figure 33 is a functional diagram illustrating vehicle tracking hardware and user interfaces. According to various aspects of the present disclosure, tracking can be a key function for movable assets, such as vehicles. To ensure optimal tracking, each vehicle included in the system may be equipped with a basic driving camera 3310 (facing forward) and a high-precision GPS receiver 3320 (collectively shown as 3325). The GPS receiver 3320 may be precisely aligned with a network access device to efficiently transmit location information. The vehicle-mounted system may capture location information and camera feeds at user-defined or system-default intervals. The device may automatically adjust the accuracy of the location information and the resolution of the camera feeds to ensure optimal tracking capabilities. This allows the system to effectively provide accurate information to users. The tracking system can make the rental experience more seamless, allowing both owners and renters to stay synchronized throughout the rental period. The camera 2410 may be mounted anywhere on the vehicle as needed. Existing vehicle-installed cameras and GPS chips may also be used with the system by providing an API for the vehicle-mounted system to upload data.

[0338] Figure 33 shows an example of a tracking user interface 3330. Authorized users can tap the location icon 3325 to access the tracking dashboard 3340. Here, they can view the vehicle's location 3350 in real time, as location data may be updated more frequently in tracking mode. Furthermore, users can remotely lock the vehicle or set an alarm at any time, and even take images to more accurately pinpoint the vehicle's location.

[0339] Figure 34 and Figure 35 The vehicle tracking and control workflows for both owners and renters are shown separately. Control rights over the vehicle may vary depending on the user role. As previously mentioned, a user's access level is determined by the non-fungible token (NFT) they own. Vehicle owners holding a property NFT can track a vehicle reported stolen and take necessary action. If a non-owner (such as a renter) remotely requests a lock, the vehicle may be deauthorized unless the owner reauthenticates. After the deauthorization request is deauthorized, the vehicle may gradually slow down to ensure the safety of its passengers and eventually come to a complete stop. The system may also take the same action if any associated NFT expires, such as if a renter has used the vehicle for an extended period without returning it. Users can locate the vehicle just like owners. If the vehicle is stolen, users can immediately report it to the owner, who can then take further action.

[0340] Figure 34 1A-1B , the backend server 115 may be executed by a processor on a server according to various aspects of the present disclosure.

[0341] refer to Figure 34 The system first determines the type of tracking or control required (at step 3405). If vehicle tracking is requested, the system will enable tracking and locate the vehicle at step 3410, and the process will then end. If the vehicle has been reported stolen, the system will deauthorize the vehicle at step 3415, and the vehicle will gradually slow to a complete stop at step 3420, and the process will then end.

[0342] If the vehicle is still used after the lease period ends, the system will cancel the vehicle authorization at step 3425 after the non-fungible token (NFT) lease expires and continue to perform the operations described at step 3420.

[0343] FIG35 is a flow chart illustrating how a renter performs vehicle tracking and control (process 3500 ), which process 3500 may be executed by a processor on a server (eg, the backend server 115 shown in FIG1A-1B ) according to various aspects of the present disclosure.

[0344] Referring to Figure 35, the system first determines the type of tracking or control required (at step 3505). If vehicle tracking is requested, the system will enable the tracking function at step 3510 and locate the vehicle, and then the process ends. If the vehicle is reported as stolen, the system will send a message to the owner at step 3515 so that the owner can take further action. For example, the owner can follow Figure 34 Follow the process described in , report the vehicle stolen, and the process ends.

[0345] The embodiments of the present disclosure provide the technical advantages of integrating bio-contracts, standardizing transactions and ensuring a secure and consistent user experience. In addition, the automated process of the embodiments can achieve instant settlement, reduce management overhead, and support dynamic pricing. The inheritable non-fungible token (NFT) mechanism also has the technical advantage of promoting interoperability with other platforms, which may expand the asset ecosystem. The digital nature of such transactions reduces environmental impact and supports global use, completely changing the traditional way of real estate and vehicle transactions, making the embodiments of the present disclosure more advantageous than previous methods.

[0346] Some of the functions and applications described above can be implemented as software processes, which are specified as a set of instructions recorded on a computer-readable storage medium (also referred to as computer-readable media). When these instructions are executed by one or more processing units (e.g., one or more processors, processor cores, or other processing units), they cause the processing units to perform the operations specified in the instructions. Examples of computer-readable media include, but are not limited to, CD-ROMs, flash drives, RAM chips, hard disks, EPROMs, etc. Computer-readable media do not include carrier signals and electronic signals transmitted wirelessly or by wire.

[0347] In this specification, the term "software" includes firmware stored in a read-only memory (ROM) or application programs stored in a magnetic storage device, which can be read into memory for execution by a processor. In addition, in some embodiments, multiple software inventions can be implemented as sub-parts of a larger program while still remaining independent software inventions. In some embodiments, multiple software inventions can also be implemented as separate programs. Ultimately, any method of combining multiple independent programs to jointly implement the software inventions described in this specification falls within the scope of the present invention. In some embodiments, when software programs are installed and run on one or more electronic systems, they define one or more specific machine implementations that execute and complete the operations of the software programs.

[0348] Figure 36An electronic system 3600 is conceptually illustrated that can be used to implement some embodiments of the present invention (e.g., the aforementioned video game platform, server, client device, etc.). Electronic system 3600 can be used to execute any of the control, virtualization, or operating system applications described above. Electronic system 3600 can be a computer (e.g., a desktop computer, a personal computer, a tablet computer, a server computer, a mainframe, a blade computer, etc.), a phone, a PDA, or any other type of electronic device. Such an electronic system includes various types of computer-readable media and provides interfaces for various computer-readable media. Electronic system 3600 includes a bus 3605, a processing unit 3610, a system memory 3620, a read-only memory (ROM) 3630, a permanent storage device 3635, an input device 3640, and an output device 3645.

[0349] Bus 3605 represents all system buses, peripheral buses, and chipset buses used to connect multiple devices within electronic system 3600. For example, bus 3605 communicatively connects processing unit 3610 to read-only memory 3630, system memory 3620, and permanent storage device 3635.

[0350] The processing unit 3610 retrieves instructions from these different storage units to perform corresponding operations and processes data to perform various processes of the present invention. In different embodiments, the processing unit 3610 can be a single-core processor or a multi-core processor.

[0351] Read-only memory (ROM) 3630 stores static data and instructions required by processing unit 3610 and other modules of the electronic system. Permanent storage device 3635 is a read-write memory device, a non-volatile storage unit that can store instructions and data even when electronic system 3600 is turned off. In some embodiments, the present invention uses a mass storage device (e.g., a magnetic disk or optical disk and its corresponding disk drive) as permanent storage device 3635.

[0352] In other embodiments, permanent storage device 3635 may be a removable storage device (e.g., a floppy disk, a flash drive, etc.). Similar to permanent storage device 3635, system memory 3620 is also a read-write storage device. However, unlike storage device 3635, system memory 3620 is a volatile read-write memory, such as random access memory (RAM). System memory stores certain instructions and data required by the processor during operation. In certain embodiments, the processes of the present invention are stored in system memory 3620, permanent storage device 3635, and / or read-only memory 3630. Processing unit 3610 can retrieve instructions from these storage units and process data to execute the processes of certain embodiments of the present invention.

[0353] Bus 3605 also connects input devices 3640 and output devices 3645. Input devices allow a user to communicate information and select commands to the electronic system. Input devices 3640 include an alphanumeric keyboard and a pointing device (also known as a "cursor control device"). Output devices 3645 are used to display images generated by the electronic system and include printers and display devices, such as cathode ray tubes (CRTs) or liquid crystal displays (LCDs). Certain embodiments include devices that function as both input and output devices, such as touch screens.

[0354] Finally, if Figure 36 As shown, bus 3605 also connects electronic system 3600 to network 3625 via a network adapter (not shown). In this way, the computer can become part of a computer network (e.g., a collection of networks such as a local area network (LAN), a wide area network (WAN), an intranet, or the Internet). Any or all components of electronic system 3600 may be used in conjunction with the present invention.

[0355] Certain embodiments include electronic components, such as microprocessors, memories, and storage devices, which can store computer program instructions in machine-readable or computer-readable media (also referred to as computer-readable storage media, machine-readable media, or machine-readable storage media). Examples of such computer-readable media include RAM, ROM, compact disc-read only media (CD-ROM), compact disc-recordable media (CD-R), compact disc-rewritable media (CD-RW), read-only digital versatile discs (e.g., DVD-ROM, dual-layer DVD-ROM), various recordable / rewritable DVDs (e.g., DVD-RAM, DVD-RW, DVD+RW, etc.), flash memory (e.g., SD cards, mini-SD cards, micro-SD cards, etc.), magnetic and / or solid-state drives, read-only and recordable Blu-ray discs. Ultra-high-density optical discs and any other optical or magnetic media. Computer-readable media can store a computer program that is executed by at least one processing unit, the program including a set of instructions for performing various operations. Examples of computer programs or computer code include machine code generated by a compiler and high-level code files that can be executed by a computer, electronic component, or microprocessor using an interpreter.

[0356] While the above discussion primarily refers to microprocessors or multi-core processors executing software, some embodiments may be performed by one or more integrated circuits, such as application-specific integrated circuits (ASICs) or field-programmable gate arrays (FPGAs). In some embodiments, such integrated circuits may execute instructions stored on the circuits themselves.

[0357] In this specification, "computer," "server," "processor," and "memory" refer to electronic or other technological devices. These terms do not include individuals or groups of people. For the purposes of this specification, "display" or "displaying process" refers to displaying on an electronic device. In this specification, "computer-readable medium," "computer-readable storage medium," and "machine-readable medium" are limited to tangible, physical objects that store information in a computer-readable form. These terms do not include any wireless signals, wired download signals, or other transient or short-lived signals.

[0358] In a first aspect, a method for leasing a rentable item using a non-fungible token (NFT) is provided. The method receives a request from an owner of a rentable item via a server in communication with a distributed ledger system to list the rentable item for leasing. The method causes the distributed ledger system to mint a rental non-fungible token (NFT) for the rentable item and distribute the rental NFT to the owner of the rentable item. The method lists the rentable item for leasing via the server and receives a rental request from a rental applicant, where the rental request relates to one or more time periods. In response to the rental request, the method causes the distributed ledger system to mint one or more child rental NFTs, each associated with the requested time period, and distribute the group of child rental NFTs to the rental applicant. Furthermore, the method mints a group of child rental NFTs for the remaining time periods and distributes them to the owner of the rentable item. Finally, the original rental NFT is destroyed. The method also provides confirmation of successful leasing to the leasing applicant and the owner of the rentable item.

[0359] In an embodiment of the first aspect, when the leased non-fungible token (NFT) is a first leased non-fungible token (NFT), the method further receives a request from the lease applicant to return a non-fungible token (NFT) in a first set of sub-leased non-fungible tokens (NFTs). The method determines that a time period associated with the sub-leased non-fungible token (NFT) has not expired, and that there is at least one non-fungible token (NFT) associated with an unexpired time period in a second set of sub-leased non-fungible tokens (NFTs). After determining these conditions, the method sends an authorization request to the owner to authorize the return of at least one sub-non-fungible token (NFT), and receives authorization information from the owner. Subsequently, the method causes the distributed ledger system to mint a new leased non-fungible token (NFT) through the server, which combines the time period of the returned first sub-lease non-fungible token (NFT) and at least one second sub-lease non-fungible token (NFT), and distributes the new leased non-fungible token (NFT) to the owner, while destroying the original first sub-lease non-fungible token (NFT) and at least one second sub-lease non-fungible token (NFT).

[0360] In another embodiment of the first aspect, when the rentable item is real estate including a remotely programmable entry lock, the method further receives, through a server, facial images, fingerprints, voice recordings, or three-dimensional facial point cloud data from an electronic device associated with the rental applicant, and remotely programs, through the server, the entry lock of the real estate so that it automatically unlocks upon recognizing the facial image, fingerprint, voice recording, or facial point cloud of the rental applicant during the rental period.

[0361] In another embodiment of the first aspect, when the rentable item is real estate with a remotely programmable entry lock, the method further distributes a barcode or NFC tag to the rental applicant via the server, and remotely programs the real estate entry lock to automatically unlock upon recognizing the rental applicant's barcode or NFC tag during the rental period. Furthermore, the method further transmits the barcode or NFC tag to an electronic device associated with the rental applicant.

[0362] In another embodiment of the first aspect, when the rentable item is a vehicle including a remotely programmable ignition switch, and the ignition switch requires an electronic key provided by a mobile electronic device to start the vehicle, the method further provides the electronic key to the rental applicant's mobile electronic device to start the vehicle, and at the same time, the server determines that the rental applicant has not provided proof of insurance, and after this determination, remotely programs the ignition switch of the vehicle so that it cannot be started by the electronic key provided to the rental applicant's mobile electronic device.

[0363] In another embodiment of the first aspect, the method further receives proof of insurance from the rental applicant via the server, and after receiving the proof of insurance, remotely programs the ignition switch of the vehicle via the server so that it can be started using an electronic key provided to the rental applicant's mobile electronic device.

[0364] In another embodiment of the first aspect, after receiving the insurance certificate, the method causes the distributed ledger system to mint an insurance non-fungible token (NFT) through the server, and distributes the insurance non-fungible token (NFT) to the rental applicant so that the rental applicant can use it as an insurance certificate in the future.

[0365] In another embodiment of the first aspect, when the rentable item is a vehicle including a remotely programmable ignition switch, and the ignition switch requires an electronic key provided by a mobile electronic device to start the vehicle, the method further provides, via a server, the electronic key to the mobile electronic device of the rental applicant to start the vehicle, while the server determines that the rental applicant has not provided proof of a valid driver's license, and upon this determination, remotely programs the ignition switch of the vehicle so that it cannot be started by the electronic key provided to the mobile electronic device of the rental applicant.

[0366] In another embodiment of the first aspect, the method further receives, through the server, a driver's license certificate from the rental applicant, and after receiving the driver's license certificate, remotely programs, through the server, an ignition switch of the vehicle so that it can be started using an electronic key provided to a mobile electronic device of the rental applicant.

[0367] In another embodiment of the first aspect, after receiving the driver's license certificate, the method causes the distributed ledger system to mint a driver's license non-fungible token (NFT) through the server, and allocates the driver's license non-fungible token (NFT) to the rental applicant so that the rental applicant can use it as proof of driving qualification in the future.

[0368] In another embodiment of the first aspect, when the rentable item is a vehicle including a remotely programmable entry lock, the method further receives, through a server, facial images, fingerprints, voice recordings, or three-dimensional facial point cloud data provided by an electronic device associated with the rental applicant, and remotely programs, through the server, the entry lock of the vehicle so that it automatically unlocks after recognizing the facial image, fingerprint, voice recording, or facial point cloud of the rental applicant within a specified rental time period.

[0369] In another embodiment of the first aspect, when the rentable item is a vehicle including a remotely programmable entry lock, the method further assigns a barcode or NFC tag to the rental applicant through the server, and remotely programs the vehicle's entry lock through the server to automatically unlock after recognizing the barcode or NFC tag within a set time period or time periods, and simultaneously sends the barcode or NFC tag to an electronic device associated with the rental applicant.

[0370] In a second aspect, a method for leasing a rentable item using a non-fungible token (NFT) is provided. The method receives a request from an owner of a rentable item via a server in communication with a distributed ledger system to list the rentable item for leasing. The method causes the distributed ledger system to mint a rental non-fungible token (NFT) for the rentable item and distribute the rental non-fungible token (NFT) to the owner of the rentable item. The method receives a request from the owner of the rentable item via the server to list the rentable item as a rentable item during a first time period, the request including an instruction to divide the first time period into a plurality of rentable time periods. In response to the rental listing request, the method causes the distributed ledger system to mint a plurality of child rental non-fungible tokens (NFTs), each child rental non-fungible token (NFT) associated with one of the plurality of time periods, distribute the child rental non-fungible tokens (NFTs) to the owner, and simultaneously destroy the original rental non-fungible token (NFT). The method lists a rentable item as available for rent during multiple time periods and receives, via a server, a request from a rental applicant to rent the rentable item for a second time period among the multiple time periods. In response to the rental applicant's rental request, the method causes the server to cause a distributed ledger system to transfer a sub-lease non-fungible token (NFT) associated with the second time period to the rental applicant. The method then provides rental confirmation information to the rental applicant and the owner of the rentable item, confirming the rental status of the item during the second time period.

[0371] In an embodiment of the second aspect, the method further receives a request from the lease applicant to return a sub-lease non-fungible token (NFT) from the first set of sub-lease non-fungible tokens (NFTs), and determines that a time period associated with the sub-lease non-fungible token (NFT) has not expired. Upon this determination, the method sends an authorization request to the owner to authorize the return of at least one sub-lease non-fungible token (NFT), and receives authorization from the owner to return the non-fungible token (NFT). Upon receiving the authorization, the method causes the distributed ledger system, via the server, to transfer a second lease non-fungible token (NFT) to the owner.

[0372] In another embodiment of the second aspect, when the rentable item is a real estate with a remotely programmable entrance lock, the method further assigns a barcode or NFC tag to the rental applicant through the server, and remotely programs the entrance lock of the real estate through the server to automatically unlock after recognizing the barcode or NFC tag within one or more set time periods, and simultaneously sends the barcode or NFC tag to an electronic device associated with the rental applicant.

[0373] In another embodiment of the second aspect, when the rentable item is a vehicle including a remotely programmable ignition switch, and the ignition switch requires an electronic key provided by a mobile electronic device to start the vehicle, the method further provides the electronic key to the rental applicant's mobile electronic device through the server to start the vehicle, and at the same time, the server determines that the rental applicant has not provided proof of insurance, and after this determination, remotely programs the ignition switch of the vehicle so that it cannot be started by the electronic key provided to the rental applicant's mobile electronic device.

[0374] In another embodiment of the second aspect, the method further receives, through the server, proof of insurance from the rental applicant, and upon receiving the proof of insurance, remotely programs the ignition switch of the vehicle so that it can be started using an electronic key provided to the rental applicant's mobile electronic device.

[0375] In another embodiment of the second aspect, after receiving the insurance certificate, the method causes the distributed ledger system to mint an insurance non-fungible token (NFT) through the server, and allocates the insurance non-fungible token (NFT) to the lease applicant so that the lease applicant can use the non-fungible token (NFT) as insurance certificate in the future.

[0376] In another embodiment of the second aspect, when the rentable item is a vehicle including a remotely programmable ignition switch, and the ignition switch requires an electronic key provided by a mobile electronic device to start the vehicle, the method further provides the electronic key to the mobile electronic device of the rental applicant to start the vehicle, and at the same time, the server determines that the rental applicant has not provided proof of a driver's license, and after this determination, remotely programs the ignition switch of the vehicle so that it cannot be started by the electronic key provided to the mobile electronic device of the rental applicant.

[0377] In another embodiment of the second aspect, the method further receives, through the server, proof of the rental applicant's driver's license, and upon receiving the proof of the driver's license, remotely programs the ignition switch of the vehicle so that it can be started using an electronic key provided to the rental applicant's mobile electronic device.

[0378] In another embodiment of the second aspect, after receiving the driver's license certificate, the method causes the distributed ledger system to mint a driver's license non-fungible token (NFT) through the server, and allocates the driver's license non-fungible token (NFT) to the lease applicant, so that the lease applicant can use the non-fungible token (NFT) as proof of driving qualification in the future.

[0379] In another embodiment of the second aspect, when the rentable item is a vehicle including a remotely programmable entry lock, the method further receives, via a server, a facial image, fingerprint, voice recording, or 3D facial point cloud of the rental applicant from an electronic device associated with the rental applicant, and remotely programs, via the server, the entry lock of the vehicle so that it automatically unlocks upon recognizing the facial image, fingerprint, voice recording, or 3D facial point cloud within a set time period or time periods.

[0380] In another embodiment of the second aspect, when the rentable item is a vehicle including a remotely programmable entry lock, the method further assigns a barcode or NFC tag to the rental applicant through the server, and remotely programs the vehicle's entry lock through the server to automatically unlock after recognizing the barcode or NFC tag within a set one or more time periods, and simultaneously sends the barcode or NFC tag to an electronic device associated with the rental applicant.

[0381] In a third aspect, a method for real estate leasing using non-fungible tokens (NFTs) is provided. The method receives a request from a real estate owner via a server in communication with a distributed ledger system to list the real estate as a leaseable asset. The method then causes the distributed ledger system to mint a lease non-fungible token (NFT) for the real estate via the server and distribute the lease non-fungible token (NFT) to the real estate owner. The method receives a request from a real estate owner via the server to list the real estate as a leaseable asset, the request including instructions to divide the real estate into a plurality of leaseable spaces, each space being leaseable for one or more corresponding time periods. The method lists a plurality of real estate spaces for lease and receives a request from a lease applicant on the server to lease a first space among the plurality of spaces and to lease it for one or more corresponding time periods. Upon receiving a request from a lease applicant, the method causes a distributed ledger system to mint a plurality of sub-lease non-fungible tokens (NFTs), each of which is associated with a space among a plurality of spaces and its corresponding time period, and to allocate a first sub-lease non-fungible token (NFT) associated with the first space and the first time period to the lease applicant, and to allocate sub-lease non-fungible tokens (NFTs) other than the first sub-lease non-fungible token (NFT) from the plurality of sub-lease non-fungible tokens (NFTs) to the real estate owner, and to destroy the lease non-fungible tokens (NFTs). The method provides a lease confirmation of the first space to the lease applicant and the real estate owner.

[0382] In a fourth aspect, a method for leasing real estate using non-fungible tokens (NFTs) is provided. The method receives a request from a real estate owner, via a server in communication with a distributed ledger system, to list the real estate as a leaseable asset. The method then causes the distributed ledger system, via the server, to mint a lease non-fungible token (NFT) for the real estate and distribute the lease non-fungible token (NFT) to the real estate owner. The method receives a request from the real estate owner, via the server, to list the real estate as a leaseable asset, the request including instructions to divide the real estate into a plurality of leaseable spaces, each of which is leaseable for one or more time periods. In response to the lease request, the method causes the distributed ledger system, via the server, to mint a plurality of sub-lease non-fungible tokens (NFTs), each associated with one of the plurality of spaces and its corresponding one or more time periods, distributes the plurality of sub-lease non-fungible tokens (NFTs) to the owner, and destroys the lease non-fungible tokens (NFTs). The method lists a plurality of real estate spaces for lease and receives a request from a lease applicant, via the server, to lease a first space from the plurality of spaces for the corresponding one or more time periods. After receiving a request from a lease applicant, the method causes a distributed ledger system to transfer a first sub-lease non-fungible token (NFT) associated with a first space and a first time period to the lease applicant through a server, and provides a lease confirmation of the leaseable asset to the lease applicant and the real estate owner.

[0383] In a fifth aspect, a non-transitory computer-readable medium storing a program for leasing a rentable asset using a non-fungible token (NFT) is provided. The program is executable by at least one server processor that communicates with a distributed ledger system over a network. The program includes a set of instructions for receiving a request from a rentable asset owner to list the rentable asset as a rentable asset, causing the distributed ledger system to mint a lease non-fungible token (NFT) for the rentable asset, and assigning the lease non-fungible token (NFT) to the rentable asset owner, listing the rentable asset as a rentable asset, receiving a request from a lease applicant to lease the rentable asset for one or more time periods, and in response to the lease request, causing the distributed ledger system to mint a first set of one or more sub-lease non-fungible tokens (NFTs), wherein the first set of sub-lease non-fungible tokens Each sub-lease non-fungible token (NFT) in the coin (NFT) is associated with a time period in the first one or more time periods, a first set of sub-lease non-fungible tokens (NFTs) are allocated to the lease applicant, a second set of one or more sub-lease non-fungible tokens (NFTs) are minted for use in time periods other than the first one or more time periods, the second set of sub-lease non-fungible tokens (NFTs) are allocated to the owner of the rentable asset, and the lease non-fungible tokens (NFTs) are destroyed, and a lease confirmation of the rentable asset in the first one or more time periods is provided to the lease applicant and the owner of the rentable asset.

Claims

1. A method for leasing a rentable item using a non-fungible token (NFT), the method comprising: receiving, via a server in communication with the distributed ledger system, a request from an owner of a rentable item to list the rentable item as a rental item; The distributed ledger system is enabled by the server: Minting a rental non-fungible token (NFT) of the rentable item; and Distribute the rental non-fungible token (NFT) to the owner of the rentable item; Listing of rentable items by the server for rent; receiving, by the server, a request from a rental applicant to rent the rentable item for a first set of one or more time periods; In response to a request from a rental applicant, the server causes the distributed ledger system to: minting a first set of one or more sub-lease non-fungible tokens (NFTs), wherein each sub-lease non-fungible token (NFT) in the first set of sub-lease non-fungible tokens (NFTs) is associated with a time period in the first set of time periods; Allocate the first set of sub-lease non-fungible tokens (NFTs) to the lease applicants; Minting a second set of one or more sub-lease non-fungible tokens (NFTs) for time periods outside of the first set of time periods; Distributing a second set of sub-rental non-fungible tokens (NFTs) to owners of the rentable items; as well as Destroy leased non-fungible tokens (NFTs); as well as Confirmation of leasing the rentable item for the first set of time periods is provided to the rental applicant and the owner of the rentable item.

2. The method of claim 1, wherein the leased non-fungible token (NFT) is a first leased non-fungible token (NFT), the method further comprising: Receiving a request from a lease applicant to return a first sub-lease non-fungible token (NFT) in a first set of sub-lease non-fungible tokens (NFTs); Determining that the time period associated with the first sub-lease NFT has not expired, and at least one NFT in the second set of sub-lease NFTs is associated with an unexpired time period; After making the above determination, sending an authorization request to the owner to authorize the return of at least one sub-lease non-fungible token (NFT); Receive authorization from the owner to return at least one sub-lease non-fungible token (NFT); After receiving the authorization, the server enables the distributed ledger system to: minting a second lease NFT for the combined time period of the first and at least a second sub-lease NFT; Allocate the second lease non-fungible token (NFT) to the owner; and destroy the first and at least the second sub-lease non-fungible token (NFT).

3. The method of claim 1 , wherein the rentable item is real estate including a remotely programmable entry lock, the method further comprising: Receiving, by the server, from an electronic device associated with the rental applicant, any one of: a facial image, a fingerprint, a voice recording, or a three-dimensional (3D) facial point cloud of the rental applicant; and The server remotely programs the entrance lock of the real estate to unlock within one or more time periods after recognizing the facial image, fingerprint, voice recording or facial point cloud of the rental applicant.

4. The method of claim 1 , wherein the rentable item is real estate including a remotely programmable entry lock, the method further comprising: Assigning, by the server, one of a barcode or a near field communication (NFC) tag to the rental applicant; Remotely programming, by the server, an entry lock to the property to unlock within one or more time periods upon recognition of the barcode or NFC tag; and The barcode or NFC tag is sent to an electronic device associated with the rental applicant.

5. The method of claim 1 , wherein the rentable item is a vehicle including a remotely programmable ignition switch that requires an electronic key provided by a mobile electronic device for start-up, the method further comprising: The server provides an electronic key to the mobile electronic device of the rental applicant to start the vehicle; The server determined that the rental applicant did not provide proof of insurance; as well as After making the above determination, the server remotely programs the ignition switch of the vehicle so that it cannot be started using the electronic key provided to the rental applicant's mobile electronic device.

6. The method of claim 5, further comprising: The server receives the insurance certificate of the rental applicant; as well as After receiving proof of insurance, the server remotely programs the vehicle's ignition switch to enable it to be started using the electronic key provided to the rental applicant's mobile electronic device.

7. The method of claim 6, further comprising: After receiving the insurance certificate, the server causes the distributed ledger system to mint the insurance non-fungible token (NFT); as well as Insurance non-fungible tokens (NFTs) are distributed to rental applicants for future use as proof of insurance.

8. The method of claim 1 , wherein the rentable item is a vehicle including a remotely programmable ignition switch that requires an electronic key provided by a mobile electronic device for start-up, the method further comprising: The server provides an electronic key to the mobile electronic device of the rental applicant to start the vehicle; The rental applicant did not provide proof of a driver's license, as determined by the server; as well as After making the above determination, the server remotely programs the ignition switch of the vehicle so that it cannot be started using the electronic key provided to the rental applicant's mobile electronic device.

9. The method of claim 5, further comprising: The server receives the driver's license certificate of the rental applicant; as well as After receiving proof of driver's license, the server remotely programs the vehicle's ignition switch to enable it to be started using the electronic key provided to the rental applicant's mobile electronic device.

10. The method of claim 6, further comprising: After receiving the driver's license certificate, the server causes the distributed ledger system to mint a driver's license non-fungible token (NFT); as well as A driver’s license non-fungible token (NFT) is allocated to the rental applicant for future use as proof of driving.

11. The method of claim 1 , wherein the rentable item is a vehicle including a remotely programmable entry lock, the method further comprising: Receiving, by the server, any one of the following from an electronic device associated with the rental applicant: a facial image, a fingerprint, a voice recording, or a three-dimensional facial point cloud of the rental applicant; as well as The vehicle's entry lock is remotely programmed by the server to unlock within one or more time periods after recognizing the rental applicant's facial image, fingerprint, voice recording, or facial point cloud.

12. The method of claim 1 , wherein the rentable item is a vehicle including a remotely programmable entry lock, the method further comprising: Assigning, by the server, one of a barcode or a near field communication (NFC) tag to the rental applicant; Remotely programming, by the server, the vehicle's entry lock to unlock within one or more time periods after recognizing the barcode or NFC tag; and The barcode or NFC tag is sent to an electronic device associated with the rental applicant.

13. A method for leasing a rentable item using a non-fungible token (NFT), the method comprising: receiving, by a server in communication with the distributed ledger system over a network, a request from an owner of a rentable item to list the rentable item for rent; The distributed ledger system is facilitated by the server: Minting a rental non-fungible token (NFT) for the rentable item; and Distribute a rental non-fungible token (NFT) to the owner of the rentable item; Receiving, by the server, a request from an owner of a rentable item to list the rentable item for rent, the request including an instruction to divide a first time period into a plurality of time periods for renting; In response to a request to list a rentable item, the server causes the distributed ledger system to: Minting multiple sub-lease non-fungible tokens (NFTs), each sub-lease non-fungible token (NFT) is associated with one of the multiple time periods; Allocate multiple sub-lease non-fungible tokens (NFTs) to owners; as well as Destroy the leased non-fungible token (NFT); List the rentable item for rental over multiple time periods; receiving, by the server, a request from a rental applicant to rent a rentable item for a second time period among the plurality of time periods; In response to a lease request from the lease applicant for a second time period, causing the distributed ledger system to transfer, by the server, a sub-lease non-fungible token (NFT) associated with the second time period to the lease applicant; and Confirmation of the lease of the rentable item for the second time period is provided to the lease applicant and the owner of the rentable item.

14. The method of claim 13, further comprising: Receiving a request from the lease applicant to return a first sub-lease non-fungible token (NFT) in the first set of sub-lease non-fungible tokens (NFTs); Confirming that the time period associated with the first sub-lease NFT has not expired; After making the above determination, sending an authorization request to the owner to authorize the return of at least one child non-fungible token (NFT); Receive authorization from the owner to return at least one child non-fungible token (NFT); as well as Upon receiving the authorization, the server causes the distributed ledger system to transfer the second leased non-fungible token (NFT) to the owner.

15. The method of claim 12, wherein the rentable item is real estate including a remotely programmable entry lock, the method further comprising: Receiving, by the server, any one of the following from an electronic device associated with the rental applicant: a facial image, a fingerprint, a voice recording, or a three-dimensional facial point cloud of the rental applicant; as well as The server remotely programs the entrance lock of the real estate to unlock within one or more time periods after recognizing the facial image, fingerprint, voice recording or facial point cloud of the rental applicant.

16. The method of claim 12, wherein the rentable item is real estate including a remotely programmable entry lock, the method further comprising: Assigning, by the server, one of a barcode or a near field communication (NFC) tag to the rental applicant; Remotely programming, by the server, an entry lock to the property to unlock within one or more time periods upon recognition of the barcode or NFC tag; and The barcode or NFC tag is sent to an electronic device associated with the rental applicant.

17. The method of claim 12, wherein the rentable item is a vehicle including a remotely programmable ignition switch that requires an electronic key provided by a mobile electronic device for activation, the method further comprising: The server provides an electronic key to the mobile electronic device of the rental applicant to start the vehicle; The server determined that the rental applicant did not provide proof of insurance; as well as After making the above determination, the server remotely programs the ignition switch of the vehicle so that it cannot be started using the electronic key provided to the rental applicant's mobile electronic device.

18. The method of claim 17, further comprising: The server receives the insurance certificate of the rental applicant; as well as After proof of insurance is received, the server remotely programs the vehicle's ignition switch to enable it to be started using an electronic key provided to the rental applicant's mobile electronic device.

19. The method of claim 18, further comprising: After receiving the insurance certificate, the server prompts the distributed ledger system to mint the insurance non-fungible token (NFT); as well as Insurance non-fungible tokens (NFTs) are allocated to rental applicants for use as proof of insurance in the future.

20. The method of claim 12, wherein the rentable item is a vehicle including a remotely programmable ignition switch that requires an electronic key provided by a mobile electronic device for activation, the method further comprising: The server provides an electronic key to the mobile electronic device of the rental applicant to start the vehicle; The rental applicant did not provide proof of a driver's license, as determined by the server; as well as After making the above determination, the server remotely programs the ignition switch of the vehicle so that it cannot be started using the electronic key provided to the rental applicant's mobile electronic device.

21. The method of claim 20, further comprising: The server receives the driver's license certificate of the rental applicant; as well as After receiving proof of driver's license, the server remotely programs the vehicle's ignition switch to enable it to be started using the electronic key provided to the rental applicant's mobile electronic device.

22. The method of claim 21, further comprising: After receiving the driver's license certificate, the server prompts the distributed ledger system to mint the driver's license non-fungible token (NFT); as well as A driver's license non-fungible token (NFT) is allocated to the rental applicant for use as a driving certificate in the future.

23. The method of claim 12, wherein the rentable item is a vehicle including a remotely programmable entry lock, the method further comprising: Receiving, by the server, any one of the following from an electronic device associated with the rental applicant: a facial image, a fingerprint, a voice recording, or a three-dimensional facial point cloud of the rental applicant; as well as The vehicle's entry lock is remotely programmed by the server to unlock within one or more time periods after recognizing the rental applicant's facial image, fingerprint, voice recording, or facial point cloud.

24. The method of claim 12, wherein the rentable item is a vehicle including a remotely programmable entry lock, the method further comprising: Assigning, by the server, one of a barcode or a near field communication (NFC) tag to the rental applicant; The server remotely programs the vehicle's entry lock to unlock within one or more time periods after recognizing a barcode or near field communication (NFC) tag; and transmits the barcode or near field communication (NFC) tag to an electronic device associated with the rental applicant.

25. A method for leasing real estate using a non-fungible token (NFT), the method comprising: The server communicates with the distributed ledger system via a network to receive a request from a real estate owner to list the real estate for rent; A distributed ledger system facilitated by a server: minting and leasing non-fungible tokens (NFTs) for real estate; and the distribution of leasehold non-fungible tokens (NFTs) to real estate owners; Receiving, by a server, a request from a real estate owner to list the real estate for rent, the request including instructions to divide the real estate into a plurality of rentable spaces, each space being rented for one or more time periods; Listing multiple spaces on real property for rent for one or more corresponding time periods; Receiving, by the server, a request from a leasing applicant to lease a first space among the plurality of spaces for a first time period among the corresponding one or more time periods; After receiving the request from the rental applicant, the server prompts the distributed ledger system to: minting a plurality of sub-lease non-fungible tokens (NFTs), each sub-lease non-fungible token (NFT) being associated with a space in the plurality of spaces and a time period in one or more time periods corresponding to the space; Allocate a first sub-lease non-fungible token (NFT) associated with the first space and the first time period from among the plurality of sub-lease non-fungible tokens (NFTs) to the lease applicant; Allocate the sub-lease NFTs other than the first sub-lease NFT to the real estate owner; as well as Destroy leased non-fungible tokens (NFTs); and Provide confirmation of first space leases to lease applicants and real property owners.

26. A method for renting a rentable item using a non-fungible token (NFT), the method comprising: The server communicates with the distributed ledger system via a network to receive a request from a real estate owner to list the real estate for rent; The distributed ledger system is facilitated by the server: Minting and leasing non-fungible tokens (NFTs) for real estate; and Distribute leasehold non-fungible tokens (NFTs) to real estate owners; Receiving, by a server, a request from a real estate owner to list the real estate for rent, the request including instructions to divide the real estate into a plurality of rentable spaces, each space being rented for one or more time periods; Upon receiving a request to list a property for rent, the server causes the distributed ledger system to: minting a plurality of sub-lease non-fungible tokens (NFTs), each sub-lease non-fungible token (NFT) being associated with a space in the plurality of spaces and a time period in one or more time periods corresponding to the space; Allocate multiple sub-lease non-fungible tokens (NFTs) to real estate owners; as well as Destroy leased non-fungible tokens (NFTs); Listing multiple spaces on real property for rent for one or more corresponding time periods; Receiving, by the server, a request from a leasing applicant to lease a first space among the plurality of spaces for a first time period among the corresponding one or more time periods; Upon receiving the request from the lease applicant, the server causes the distributed ledger system to transfer a first sub-lease non-fungible token (NFT) associated with the first space and the first time period from the plurality of sub-lease non-fungible tokens (NFTs) to the lease applicant; and Lease confirmation information for the leaseable item during the second time period is provided to the lease applicant and the real property owner.

27. A non-transitory computer-readable medium storing a program for renting a rentable item using a non-fungible token (NFT), the program executable by at least one server processor in communication with a distributed ledger system over a network, the program comprising a set of instructions for: receiving a request from an owner of a rentable item to list the rentable item for rent; Enable distributed ledger systems to: Minting rental non-fungible tokens (NFTs) for rentable items; and Distribute rental non-fungible tokens (NFTs) to owners of rentable items; Listing rentable items for rent; receiving a request from a rental applicant to rent the rentable item for one or more time periods; Upon receiving a request to lease a rentable item, causing the distributed ledger system to: minting a first set of one or more sub-lease non-fungible tokens (NFTs), each sub-lease non-fungible token (NFT) associated with a time period in the one or more time periods; Allocate the first set of sub-lease non-fungible tokens (NFTs) to the lease applicants; minting a second set of one or more sub-lease non-fungible tokens (NFTs) for time periods other than the first one or more time periods; Allocate a second set of sub-rental non-fungible tokens (NFTs) to the owners of the rentable items; as well as Destroy leased non-fungible tokens (NFTs); as well as Confirmation of the lease of the rentable item during the first set of time periods is provided to the lease applicant and the owner of the rentable item.

Images