Method, system, and device for property transaction management involving distributed ledger technologies

Abstract

Systems and methods involving managing a plurality of encrypted blockchain records, each of the plurality of encrypted blockchain records associated with a corresponding property; for receipt of a stamp code directed at the corresponding property of one of the plurality of encrypted blockchain records, associated with a non-fungible token (NFT) stored in one of the encrypted blockchain records, determining validity of the stamp code with the one of the encrypted blockchain records associated with the NFT; and providing a result indicative of proof of ownership of the corresponding property of the one of the encrypted blockchain records to a device that submitted the stamp code, based on the determination of validity.

Description

METHOD, SYSTEM, AND DEVICE FOR PROPERTY TRANSACTION MANAGEMENT INVOLVING DISTRIBUTED LEDGER TECHNOLOGIESBACKGROUNDCross-Reference to Related Applications

[0001] The present application claims priority to:U.S. Provisional Application No. 63 / 669,543, titled “METHOD, SYSTEM, AND DEVICE FOR PROPERTY TRANSACTION MANAGEMENT INVOLVING DISTRIBUTED LEDGER TECHNOLOGIES”, filed on July 10, 2024,Dutch Patent Application No. 2038183, titled “METHOD, SYSTEM, AND DEVICE FOR PROPERTY TRANSACTION MANAGEMENT INVOLVING DISTRIBUTED LEDGER TECHNOLOGIES”, filed on July 10, 2024,U.S. Provisional Application No. 63 / 669,559, titled “METHOD, SYSTEM, AND DEVICE FOR EXECUTING PROPERTY TRANSACTIONS INVOLVING DISTRIBUTED LEDGER TECHNOLOGIES”, filed on July 10, 2024, andDutch Patent Application No. 2038184, titled “METHOD, SYSTEM, AND DEVICE FOR EXECUTING PROPERTY TRANSACTIONS INVOLVING DISTRIBUTED LEDGER TECHNOLOGIES”, the contents of which are herein incorporated by reference in their entirety for all purposes.Field

[0002] The present disclosure relates to the field of distributed ledger technologies. In particular, the present disclosure relates to methods, systems and devices for property transaction management involving distributed ledger technologies such as blockchain.Related Art

[0003] For significant property or legal transactions (e.g., real estate, vehicles, intellectual property, and so on), there is a need for an infrastructure to support all of the legal documentation and title recordation required for such transactions. However, depending on the environment, obtaining approvals for a transaction can be very time-consuming and / or oftentimes inaccurate. The transaction may be concluded between two parties (such as throughexecution of contracts). Many times, the documentation required to complete the transaction goes through multiple revisions, or stages of due diligence and / or approvals, making the task of closing on the transaction difficult. Further, after the transaction has been completed, the responsibility (and risks associated therewith) of storing accurate information confirming the transactions details are placed on the participants, especially if the underlying government does not have proper infrastructure to record such transactions, requires specialized notaries that are in short supply, or the records maintained by such governments are inaccurate.

[0004] In the related art, the participants may lose paperwork or remember details of the transaction differently. Further, if the participants fail to store the paperwork and the details of the transaction, problems may arise when questions on the details of the transaction are raised. Storing secure and verifiable documents / records of the transactions is not only a challenge for transactions taking place between two or more entities, but also for any approvals, licenses, certifications, briefs, orders, notifications, and other legal and non-legal documents issued by third-party entities, such as government or judicial bodies.

[0005] In the related art, digital transactions also involve issues with respect to closing transactions as documents and details of a transaction can be easily changed. Digitizing physical transactions presents several unique technical challenges. For example, digital records of transactions are generally easy to forge or tamper in comparison to physical records. Moreover, it is easy to change the transaction value of the digital record of the transaction (such as a contract on a text editor of a computer in comparison to printed forms of the contract indiscemibly). Such records also need to be kept safe from unauthorized access, and tampering from miscreants.

[0006] Distributed Ledger Technologies (DLTs), such as blockchain, create and store verifiable records of transactions in digital form in a decentralized manner. DLTs are implemented using a network of nodes that interact with each other to enable transactions tobe concluded therebetween, and record, validate, and store the concluded transactions in the ledger. Blockchain, for example, stores and records a list of transactions as blocks which are linked together through cryptographic hashes. When the transaction is concluded, other nodes in the network validate the transaction before storing a block having said transaction into the (block)chain. After validating the transactions, other nodes in the network must reach an agreement / consensus to synchronously update the validated transaction on their copies of the distributed ledger. Blockchain uses proof-of-work consensus protocols to validate transactions, while other DLTs may use other consensus protocols / algorithms such as, for example, proof- of-stake, proof of space, proof of burn, and so on.

[0007] However, commonly used consensus protocols are known to consume significant amounts of energy and computational resources, which are often wasteful and redundant for many applications. Such consensus protocols may be impractical for certain types of transactions. For instance, if the transaction corresponds to a license or a permit issued by the government (such as for driving, for example), it is inappropriate to expect consensus from other nodes in the network. In addition, the recordation of transactions requires an internet connection to post the transaction onto the blockchain. However, in certain circumstances (e.g., transaction occurring in a remote location), there may not be any internet or network connection available for the participants to record their transaction.

[0008] Therefore, a need exists for a system for digitizing a transaction and storing the details of the transaction, which takes into account the above-mentioned problems.

[0009] In the related art, there are implementations involving issuing a liveness hash with a nonce from a user to receive an encrypted image from a smart contract registry to use as a proof of ownership. However, such implementations result in an encrypted image that can be phished by unscrupulous third parties and then utilized by the third party to fake ownership. Such implementations are unacceptable for real property transactions, as there can be a long lengthof time between each transaction, thereby increasing the risk that the encrypted image can be phished.SUMMARY

[0010] Aspects of the present disclosure can include a method, which can include managing a plurality of encrypted blockchain records, each of the plurality of encrypted blockchain records associated with a corresponding property; and for receipt of a stamp code directed at the corresponding property of one of the plurality of encrypted blockchain records, associated with a non-fungible token (NFT) stored in one of the encrypted blockchain records, determining validity of the stamp code with the one of the encrypted blockchain records associated with the NFT; and providing a result indicative of proof of ownership of the corresponding property of the one of the encrypted blockchain records to a device that submitted the stamp code, based on the determination of validity.

[0011] Aspects of the present disclosure can include a computer program, which can include instructions involving managing a plurality of encrypted blockchain records, each of the plurality of encrypted blockchain records associated with a corresponding property; and for receipt of a stamp code directed at the corresponding property of one of the plurality of encrypted blockchain records, associated with a non-fungible token (NFT) stored in one of the encrypted blockchain records, determining validity of the stamp code with the one of the encrypted blockchain records associated with the NFT; and providing a result indicative of proof of ownership of the corresponding property of the one of the encrypted blockchain records to a device that submitted the stamp code, based on the determination of validity. The computer program and instructions can be stored on a non-transitory computer readable medium and executed by one or more processors.

[0012] Aspects of the present disclosure can include a system, which can include means for managing a plurality of encrypted blockchain records, each of the plurality of encrypted blockchain records associated with a corresponding property; and for receipt of a stamp code directed at the corresponding property of one of the plurality of encrypted blockchain records, associated with a non-fungible token (NFT) stored in one of the encrypted blockchain records, means for determining validity of the stamp code with the one of the encrypted blockchain records associated with the NFT; and means for providing a result indicative of proof of ownership of the corresponding property of the one of the encrypted blockchain records to a device that submitted the stamp code, based on the determination of validity.BRIEF DESCRIPTION OF DRAWINGS

[0013] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate an implementation of the present disclosure and, together with the description, serve to explain the advantages and principles of the present disclosure. In the drawings:

[0014] FIG. 1 illustrates an example system upon which the example implementations may be applied.

[0015] FIG. 2 illustrates an example configuration of the property transaction management device, in accordance with an example implementation.

[0016] FIG. 3 illustrates an example architecture of the trusted entity blockchain management system, in accordance with an example implementation.

[0017] FIG. 4 depicts an example implementation for a blockchain node, in accordance with an example implementation.

[0018] FIG. 5 illustrates an example implementation for a block and a transaction proposal.

[0019] FIG. 6 A and 6B illustrate an example of tokenization of the assets, such as property, in accordance with an example implementation.

[0020] FIGS. 7 A and 7B illustrate an example flow for execution and recordation of a transaction, in accordance with an example implementation.

[0021] FIG. 8 illustrates an example of a transaction certificate, in accordance with an example implementation.

[0022] FIG. 9 illustrates an example flow for providing proof of ownership to the property transaction management device, in accordance with an example implementation.

[0023] FIG. 10A illustrates an example flow of a transaction parti cipant(s) device initiating a request for the proof of ownership to be generated, in accordance with an example implementation.

[0024] FIG. 10B illustrates example flow for transactions, in accordance with an example implementation.

[0025] FIG. 11 illustrates an example of a digital stamp that can be used to confirm and validate the authenticity of digitized or tokenized values, in accordance with an example implementation.

[0026] FIG. 12 illustrates an example interface and process for validating a digital stamp code, in accordance with an example implementation.DETAILED DESCRIPTION

[0027] The following detailed description provides details of the figures and example implementations of the present application. Reference numerals and descriptions of redundant elements between figures are omitted for clarity. Terms used throughout the description are provided as examples and are not intended to be limiting. For example, the use of the term “automatic” may involve fully automatic or semi-automatic implementations involving user oradministrator control over certain aspects of the implementation, depending on the desired implementation of one of the ordinary skills in the art practicing implementations of the present application. Selection can be conducted by a user through a user interface or other input means, or can be implemented through a desired algorithm. Example implementations as described herein can be utilized either singularly or in combination, and the functionality of the example implementations can be implemented through any means according to the desired implementations.

[0028] FIG. 1 illustrates an example system upon which the example implementations may be applied. In an example implementation, the system can involve the property transaction management device 101, a local area network (LAN) 102, one or more transaction participant device(s) 103, a wide area network (WAN) 104, and a blockchain management system 105 of a trusted entity.

[0029] Property transaction management device 101 can be the device of the property owner associated with the underlying transaction, or the device a third party designated to manage the property transaction (e.g., a notary, a government agent, an agent of the trusted entity, etc.). As will be described herein, the property transaction management device can be in the form of a user equipment (UE) or mobile device such as a smartphone, tablet, phablet, laptop, and so on, or can be a special purpose device (e.g., a special device issued by the trusted entity, the government, and so on). One or more transaction participant device(s) 103 are devices owned by interested party participating in the transaction (e.g., a purchaser of the property, a creditor to record or remove a lien on the property, and so on).

[0030] Blockchain management system 105 manages records for the property in the form of blockchain records. Depending on the desired implementation, the blockchain records may be encrypted. Blockchain records are managed by a trusted entity (e.g., a government entity, a third party operating on behalf of a government entity, etc.) which includes informationregarding ownership, records involving a given property, and so on. A copy of the blockchain records corresponding to the property undergoing a transaction can also be stored in the property transaction management device 101 as will be described herein.

[0031] In example implementations, the location of the transaction may not have an internet connection available to facilitate the transaction to the blockchain ledger. To ensure connectivity between the devices in question, a local area network (LAN) 102 can be formed between the property transaction management device 101 and the one or more transaction participant device(s) 103 to facilitate short-range communication such as via Bluetooth®, local Ethernet connection, cable connection, or any other short-range communication to facilitate the desired implementation. Further, the short-range communication can be used as additional proof that the parties in question are in proximity to each other for executing the transaction, which can be used to verify proof of transaction as will be described herein.

[0032] Once the transaction is completed, the transaction can then be submitted to the blockchain management system 105 of the trusted entity for recordation over Wide Area Network (WAN) 104. The transaction can be submitted by either the property transaction management device 101, or by the one or more transaction participant device(s) 103 in accordance with the desired implementation. As the transaction may have been executed without an internet connection being available, the transaction can be submitted to the blockchain management system 105 via WAN 104 when the property transaction management device 101 or the one or more transaction participant device(s) 103 detect an internet or cellular connection to be available. Depending on the desired implementation, for certain transactions that require physical validation by one of the parties (e.g., by visiting a specific facility), the blockchain management system 105 can also require that the transaction be submitted by a LAN (not shown) associated with the blockchain management system 105.

[0033] FIG. 2 illustrates an example configuration of the property transaction management device 101, in accordance with an example implementation. A similar configuration may be used by the one or more transaction parti cipant(s) device 103 to facilitate the desired implementation, as the owner of the property may also be represented as the transaction parti cipant(s) device 103. Property transaction management device 101 can involve one or more processor(s) 202, a local interface 204, a display 206, local memory 208, a network interface 210, and a graphical user interface (GUI) 212.

[0034] One or more processor(s) 202 can be in the form of any hardware processor such as a Central Processing Unit (CPU) or any combination of hardware and software processors to facilitate the desired implementation. Examples of such hardware processors can include an application-specific integrated circuit (“ASIC”), a microprocessor, a microcontroller, an electronic circuit, a digital signal processor, or any other suitable processing device.

[0035] Local interface 204 facilitates communication between the user of the device and the device itself. Such interface can include, but is not limited to, touchscreens, microphones, keyboard, mouse, and so on in accordance with the desired implementation.

[0036] The local memory 208 may include any type of physical memory storage or combination thereof for the device 101 to facilitate the desired implementation. Such local memory 208 can include persistent memory storage, such as Solid-State Drives (SSDs), hard drives, memory chips, magnetic tapes, and so on in accordance with the desired implementation. The local memory 208 may use any type of volatile or non-volatile storage techniques and mediums. The local memory 208 can also involve a Random Access Memory (RAM), or any other dynamic storage device commonly known in the art. The local memory 208 may also include a Read-Only Memory (ROM), which may be any static storage device(s) e.g., but not limited to, a Programmable Read-Only Memory (PROM) chip for storing static information. Any combination above thereof may also be used to facilitate local memory 208.One or more processor(s) 202 may also be integrated with one or more storage of local memory 208 to facilitate the desired implementation.

[0037] Local memory 208 may also facilitate the execution of a graphical user interface (GUI) 212 for display on the display 206. Further, local memory 208 may store application 281, blockchain copy 282, and proof of ownership 283. Application 281 can be executed by the one or more processor(s) 202 to record and execute a transaction, which can include to generate a transaction certificate to certify the transaction as will be described herein. Blockchain copy 282 may include a copy of the blockchain records 282 associated with the property undergoing the transaction. Depending on the device configuration, the copy of the blockchain records 282 can be a copy of only the records associated with the property (e.g., in the case in which the property transaction management device 101 is directed to a government agent or other agent who is only authorized to facilitate the particular transaction), or can be a copy of all of the records associated with the owner of the property transaction management device 101. Thus, depending on the desired implementation, the property transaction management device 101 can be the device of the owner of the property undergoing the transaction. In example implementations in which the property transaction management device 101 is not the device of the owner of the property but some agent (e.g., government agent, notary, agent operating on behalf of the owner), the owner of the property can still participate in the transaction with their own transaction participant(s) device 103.

[0038] The network interface 204 may be a network interface card, a cellular interface card, a plain old telephone service (“POTS”) interface card, an American Standard Code for Information Interchange (ASCII) interface card, or any other suitable network interface device to facilitate short-range communication with a device or system over a LAN or connection to the internet over a WAN.

[0039] The components of device 101 may also communicate with each other using a shared bus. The bus communicatively couples the processor(s) 202 with the other memory, storage, and communication blocks. The bus may be a Peripheral Component Interconnect (PCI) / PCI Extended (PCI-X) bus, Small Computer System Interface (SCSI), Universal Serial Bus (USB), or so on to facilitate the desired implementation, for connecting expansion cards, drives, and other subsystems as well as other buses, such a front side bus (FSB), which connects the processor 202 to facilitate the desired implementation. Proof of ownership 283 can be an indicia of ownership that the device holder is the person who either owns the property or is authorized to act on behalf of the owner. Further details of the proof of ownership 283 will be described herein.

[0040] The device 101 may also involve a communication port (not shown), which may be any of a Recommended Standard 232 port for use with a modem-based dialup connection, a 10 / 100 Ethernet port, a Gigabit or 10 Gigabit port using copper or fiber, a serial port, a parallel port, a universal serial bus (USB) port, or other existing or future ports. Depending on the desired implementation, the networks used by the device 101 may be any private or public communication network known to one skilled in the art such as a Local Area Network (“LAN”) 102, Wide Area Network (“WAN”) 104, or other networks such as Peer-to-Peer Network, Cellular network, Bluetooth connection, nearfield communication or any suitable network or communication connection, using standard communication protocols. The networks can include hardwired as well as wireless branches. The communication port may be chosen depending on a network, such as a LAN, a WAN, or any network to which the device 101 can connect.

[0041] FIG. 3 illustrates an example architecture of the trusted entity blockchain management system 105, in accordance with an example implementation. The system in FIG. 3 forms a consortium blockchain with known participants, which are grouped into multipleorganizations. An organization can be a government office, an office of the trusted entity blockchain management system 105, and so on in accordance with the desired implementation, each independent enough to establish its own trust. The example of FIG. 3 shows two organizations 300-1 and 300-2 and one read-only organization 301 that will function as a validation server / interface. The number of organizations and the number of read-only organizations can be any number equal to or larger than one. A read-only organization 301 is a special type of organization, and has the same structures and logics as other organizations. The major difference is that members in a read-only organization are not allowed to invoke transactions, which make changes in data stored in the blockchain. An organization can have one or more blockchain nodes 310, one or more blockchain clients 320, and one or more certificate authorities (CAs) 350.

[0042] A blockchain node 310 is a computer that has computation capability, memory, persistent storage and communication capability via network. It can be a physical computer server, a virtual machine, a container, or any other form that has the similar capabilities to a computer to facilitate the desired implementation. As described herein, it persists ledger, state database, and private data, executes a smart contract (a program to which the participants agreed) according to a received transaction proposal, and validates and updates transactions after they get ordered by the ordering service 330.

[0043] The ordering service 330 is a service provided by one or multiple computers, which can be physical computers, virtual machines, containers, any other similar machines, in singular or in combination in accordance with the desired implementation. The ordering service 330 is responsible for deciding the full order of the transactions issued in the system, for creating the blocks each of which include the one or multiple transactions in the order decided, and for delivering the blocks to all the blockchain nodes 310. Blockchain client 320 and CA 350 are programs executed in a computer, which can be a physical computer, a virtual machine,a container or any other similar machine in accordance with the desired implementation. It may be executed in the same computer as any of the blockchain nodes 310, or may be executed in a separate computer. A blockchain client 320 initiates transactions by sending the transaction proposal to one or more of the blockchain nodes 310, and sending the responses as transactions to the ordering service 330, which in turn delivers the blocks that contain the transactions to the blockchain nodes 310. A read-only organization 301 does not have blockchain clients because it is not allowed to invoke transactions.

[0044] A CA 350 is a computer program which issues verifiable identities and can be executed in a physical computer, virtual machine, container, and so on, in accordance with the desired implementation. The CA 350 can use a cryptographic method such as issuing a digital certificate signed with the CA's private key with a cryptographic algorithm such as RSA and ECDS A. A CA 350 also has its own identity such as a digital certificate signed by itself or by another superior CA, the public key of which corresponds to the private key used for signing the certificates it issued. The blockchain nodes 310, the blockchain clients 320, the ordering service 330, and optionally CAs 350 are connected by the network 340 and can communicate with one another in a peer-to-peer fashion. The network 340 can be a local area network (LAN), wide area network (WAN), or virtual private network (VPN), and can be wired or wireless depending on the desired implementation. The communication between them can be encrypted and / or secured, for example, by using Transport Layer Security (TLS).

[0045] FIG. 4 depicts an example implementation for a blockchain node 310, in accordance with an example implementation. Blockchain node 310 can include executable programs such as endorsing logic 410, committing logic 420, validation logic 430, and a smart contract 440. It has persistence storage that stores ledger 450, state database 470, private data store 480, and temporary private data 490. The endorsing logic 410 implements the endorsing phase of the consensus. The committing logic 420 implements the validation phase of the consensus, and itinternally calls the validation logic 430 for the core of the validation of the transaction. The smart contract 440 is a program that defines the behavior of the transactions, and calculates the result based on the current data stored in the ledger. The smart contract 440 defines several functions which optionally take one or multiple parameters, and the blockchain client 320 sends a transaction proposal specifying the identifier of one of the functions and the parameter(s) if any.

[0046] The data shared in the system is stored in the ledger 450. The data is stored as a chain with the blocks 460. The state database 470 is a snapshot of the latest version of data in the ledger 450. Because each transaction in the block 460 typically only has information for the values that are involved in the transaction, the blockchain node 310 maintains and updates the snapshot of the latest state after every valid transaction is committed to obtain the latest state. The private data store 480 holds private data that is not to be shared outside of specified organizations. The private data is stored in the private data store 480 and generally has the same data model as the non-private data (e.g., public data stored in the ledger 450 and the state database 470). A transaction contains values for the non-private data, and hashes of the values for the private data. There can be multiple private data stores 480, so that the blockchain node 310 can have different data stores, each of which involving different set of organizations that are granted access.

[0047] The temporary private data store 490 holds private data that are not committed yet. Private data are written to the private data store 480 once the transaction involving the data is committed. In the endorsement phase, when the endorsement logic 410 invokes the smart contract 440 upon receiving a transaction proposal involving private data from the blockchain client 320, the smart contract 440 returns the result including values for the private data as well as for the non-private data. Due to their nature, the values of the private data cannot be shared with all the participants, and the endorsement logic 410 does not return the values for theprivate data but the hashes of the values. Because there is a need to hold the new values for the private data until it is committed in the validation phase, the endorsement logic 410 stores private data in the temporary private data store 490. Once the transaction is validated in the validation phase, the committing logic 420 updates the state database 470 for the non-private data, and updates the private data store 480 for the private data.

[0048] FIG. 5 illustrates an example implementation for a block 460 and a transaction proposal 570. Blocks 460 are connected linearly to one another with hash values. Hash values are values obtained by a one-way function such as SHA-1, SHA-256 and MD5. Previous hash value 501 is a hash value for the previous block. Block hash value 502 is a hash value for the block itself 460. Both hash values may be calculated for the whole bytes of the target block or the bytes of some portion of the target block, such as the header part of the block depending on the desired implementation. A block 460 contains one or more transactions which can involve multiple types of transactions. The example of FIG. 5 illustrates a normal transaction 510 which is a transaction which changes data as a result from invoking a smart contract 440.

[0049] A normal transaction 510 has the proposer identity 511, the function and parameters 512, the result 513, and one or more endorsements 515. The proposer identity 511 contains information to identify the entity which requested the transaction, or that sent the transaction proposal 570. The proposer identity 511 can contain a certificate issued for the blockchain client 320 and a digital signature for the contents of the transaction.

[0050] The function and parameters 512 represent the name or identifier of the function and the parameters that are used to execute a smart contract 440. The result 513 contains the result obtained by executing the smart contract 440 with the function and parameters 512. The result 513 can contain identifiers such as addresses and keys of the data in the ledger 450 with their respective new values. The result 513 can have the old values or the values read during execution of the smart contract to detect conflicts with other transactions by comparing thevalues read with the latest values in the validation phase to prevent read-after-write (RAW) data hazards. The result 513 can have the versions of the old values or the values read instead of their actual values. When private data is used, the result 513 may contain values for nonprivate data as well as hashes for values for private data. The endorsements 515 contain verifiable evidence that blockchain nodes 310 have agreed to obtain the result 513 by executing the smart contract 440 with the function and parameters 512. For example, an endorsement can include a digital signature for the result 513 using the private key of a blockchain node 310 and an identity of the entity, specifically the blockchain node 310 that created the signature.

[0051] Data 514 can include any other data that is needed to facilitate the transaction in accordance with the desired implementation. Such data can include, but is not limited to legal documents, proof of money exchanged, or so on in accordance with the desired implementation.

[0052] A transaction proposal 570 is sent from the blockchain client 320 to the blockchain nodes 310 in order to request execution of the smart contract 440 during the endorsement phase. It contains the proposer identity 511 and the function and parameters 512 for the smart contract to be invoked in the transaction.

[0053] Depending on the desired implementation, each of the blocks 460 can be encrypted while stored in its respective blockchain node 310 for added security. The encryption scheme can be conducted by any encryption scheme in accordance with the desired implementation. Decryption can be conducted for a given block in accordance with recording a transaction, to provide information from a block 460 to an API as described herein, or other reasons in accordance with the desired implementation.

[0054] FIG. 6A and 6B illustrate an example of tokenization of the assets, such as property, in accordance with an example implementation. The trusted entity blockchain management system 105 may manage blockchain records, and provide a blockchain copy 282 involvingtokenized assets. The tokens may correspond to real-world assets, such as real-estate property. The tokenized asset can be represented as an NFT in a block 460, as stored in a normal transaction 510.

[0055] As shown, real-world assets may correspond to tangible or intangible assets. FIGs. 6A to 6B illustrate examples where the asset is indicative of an immovable property, such as an apartment. The tokenized asset may be stored in a distributed storage system, such as including, but not limited to, a cloud storage, an Interplanetary File System (IPFS), an on-chain data storage, a distributed ledger, and the like.

[0056] In some embodiments, the real-world assets may be tokenized into any one or combination of including, but not be limited to, non-fungible tokens (NFTs), utility tokens, securities tokens, crypto-collectibles, digital assets, digital records, tokenized securities, utility tokens, digital currencies, virtual goods, or the like, that may be used to represent assets that are held by the entities. In some embodiments, the tokens may be any one of a soul bound token or a tradable token. In embodiments where the tokens are indicative of soul bound tokens, the tokens may not be transferable from one entity to another. For example, a token indicative of a driving permit of an entity may not be transferable or tradable to an entity, and may be issued by a governmental entity to an individual entity. In embodiments where the tokens are indicative of tradable tokens, the decentralized network may allow transfer of said tokens held by one entity to another. For example, a token corresponding to an immovable property, the decentralized network may allow an entity holding said token to transfer the token to another entity.

[0057] In some embodiments, the real-world assets may be tokenized using any tokenization technique known in the art. In some embodiments, the asset may be generated using a smart contract. In some embodiments, the smart contract may be configured to receive one or more metadata associated with the asset. The smart contract may be compliant with NFT standards,such as NFT Ethereum® Request for Comments 721 (ERC721). The token may be generated using a hash of the metadata. In some embodiments, the token may be stored in the distributed storage system. In some embodiments, the tokens may have built-in mechanisms for verifying authenticity and ensuring proper authorization before any transaction can take place.

[0058] In some embodiments, a single token may be generated for the real -world asset, such as an NFT 604 for a building 602, as shown in FIG. 6A. In such embodiments, the single token may have the metadata associated therewith. The metadata may correspond to attributes associated with the asset, such as including, but not limited to, ownership information, property history, property information (such as address, floor area, type of building, scanned copies of the property documents, etc.), for example. In other embodiments, one or more fractional tokens may be generated for the real -world asset, such as an individual token for each apartment in the building, as shown in FIG. 6B. In such embodiments, each fractional token may have the one or more metadata associated therewith. In further embodiments, both a main token, such as the main NFT, and one or more fractional tokens, such as sub-NFTs 605-1, 605-2, and 605- 3, may be generated, where the fractional tokens are subordinate to the main token. Fractional tokens may allow for granular control of the asset, where different parts or aspects of the asset can be managed independently. In some embodiments, the tokens may be fractionalized into other forms of publicly traded cryptocurrencies or tokens, such as through staking, for example.

[0059] The metadata stored in the tokens may be used for transparency and verification of ownership claims, among others, over the assets. In some embodiments, at least one metadata of the tokens may be modifiable. The metadata of the token may be modified as a result of a transaction between two or more entities. The modifications to the metadata may be specified in the transaction context.

[0060] FIG. 7A illustrates an example flow for execution and recordation of a transaction, in accordance with an example implementation. In an example implementation to facilitate atransaction, the property transaction management device transmits an initiation signal 772 to the transaction parti cipant(s) device 103. The transaction initiation signal can involve the transfer or display of a digital stamp or other representation of the proof of ownership 283 to establish to the owner(s) of the transaction parti cipant(s) device 103 that the user of the property transaction management device 101 is the owner of the property associated with the transaction.

[0061] Transaction parti cipant(s) device 103 then verifies the ownership 774 from the proof of ownership 283. If an internet connection is available, or if the transaction participant device 103 is otherwise connected to the trusted entity blockchain management system 105, then information associated with the proof of ownership 283 can be provided from the transaction parti cipant(s) device 103 to receive a decision from the trusted entity blockchain management system 105 as to whether the proof of ownership 283 is valid or invalid. Such information can include a code in the digital stamp, or so on, in accordance with the desired implementation. In another example implementation in which it is expected that no internet connection may be available, the trusted entity blockchain management system 105 may provide a code or other information associated with the proof of ownership beforehand to the transaction participant(s) device 103, which can be used to verify the proof of ownership.

[0062] Once the transaction participant(s) are satisfied with the proof of ownership, a transaction is executed at 776. The transaction depends on the underlying property. For example, documents can be digitally signed exchanged by the property owner or the transaction participant over the short-range communication, exchange of money can be facilitated (e.g., either by crypto-currency or by bank / wire transfer), and so on depending on the desired implementation. The transaction details, transaction documents, and so on are memorialized in a transaction certificate which is generated at 780 by the property transaction management device 101. The property transaction management device 101 can then transmit the transactioncertificate to the transaction parti cipant(s) device 103 as proof of transaction. The transaction certificate can be recorded on the blockchain copy 282 of the property transaction management device 101, so that when the property transaction management device 101 is connected to the trusted entity blockchain management system 105 either by the internet or by LAN, it can transmit the execution signal at 778 to record the transaction certificate with the trusted entity blockchain management system 105. Additionally, the transaction participant(s) device 103 is similarly configured to transmit the execution signal at 778 to record the transaction certificate with the trusted entity blockchain management system 105. Once the trusted entity blockchain management system 105 receives the transaction certificate, it will record the transaction certificate on the blockchain records corresponding to the property to record the transaction 782.

[0063] FIG. 7B illustrates an example flow for verifying and recording the transaction certificate, in accordance with an example implementation. In an example implementation, a property transaction must meet several requirements, often set by the local or federal government, before a property transaction is considered to be valid. Such requirements can include confirmation of signatures, particular documents to close the transaction, particular notary requirements, and so on depending on the underlying jurisdiction. In example implementations, the trusted entity blockchain management system 105 can be configured to execute a checklist for the underlying jurisdiction to verify that all requirements are met before recordation. At 710, a check can be made to determine if the parties submitting the transaction certificate are authorized to do so. If so (Yes), then the flow proceeds to 712, otherwise (No), the flow can proceed to 711 to reject the certificate and transmit a message indicating that the certificate was rejected for being sent by an unauthorized party.

[0064] At 712, the compliance check is executed. The compliance check can be a purely automated check that checks for requisite documents or signatures having been provided, orcan involve a human in the loop, such as a government official, to verify points of the checklist as needed. In an example implementation, a recordation clerk can do a final review and sign off as a final check, or can check one or more points according to jurisdictional requirements. If the compliance check fails, then the certificate is rejected at 711 and a message can be sent to the parties to indicate why the certificate was rejected so the transaction can be re-submitted. Otherwise (success), the certificate is recorded on to the blockchain and a message can be transmitted at 713 to verify that the certificate has been recorded on the blockchain.

[0065] FIG. 8 illustrates an example of a transaction certificate 800, in accordance with an example implementation. Transaction certificate 800 may include information such as, but not limited to, transaction context information 802, transaction status 804, transaction status date / time 806, transaction location 808, preceding certificate ID 810 and preceding certificate assignment date 812. Upon execution of a transaction, the transaction certificate 800 can be stored as a new block 460 for the blockchain records corresponding to the property undergoing the transaction.

[0066] Transaction context information 802 can include a binary data structure containing a description of the transaction itself in a way that is accessible for reading and understanding by the parties.

[0067] Transaction status 804 can indicate the current status of the deal. Example of status can include, but is not limited to, Active (normal state of the certificate), Retired (certificate has been revoked), Suspended, Pending (e.g., process of being renewed) and so on, in accordance with the desired implementation. The status can be changed by the consent of the participants in the transaction at once, or set by the property transaction management device 101 if the device is managed by a government agent or other trusted party.

[0068] Transaction status date / time 806 can indicate the timestamp of the transaction. Depending on the desired implementation, the timestamp can be a function of the time thetransaction is completed from each of the property transaction management device 101 and the one or more transaction parti cipant(s) device 103. For example, the timestamp averaging algorithm can ensure the accuracy of date time comparison with an accuracy of up to a certain time period (e.g., 30 seconds). In such an example, if the accuracy of the hours of the participants in the transaction differs by less than five minutes, the average of the sum of minutes and the average of the sum of seconds of the time stamps of each participant in the transaction is taken.

[0069] If the accuracy of the hours of the participants in the transaction differs by more than five minutes, then the time stamp of the property transaction management device 101 can be utilized.

[0070] Transaction location 808 can indicate the location of the transaction. Depending on the desired implementation, the location 808 can be the location of the property transaction management device 101, or it can be any sort of function involving the location of the property transaction management device 101 and the one or more transaction parti cipant(s) device 103 (e.g., an average of the global positioning satellite (GPS) coordinates of all of the devices).

[0071] In an example implementation, the transaction location 808 can be determined by an algorithm for averaging the GPS coordinates of the location of each participant in the transaction. Such an algorithm determines the common meeting point of all participants in the transaction, which can be assigned a conditional legal address and jurisdiction from the place of the transaction. In this case, there are the following rules for determining the place of the transaction.

[0072] If there are two participants in the transaction, both individuals will have their individual coordinates recorded and stored as part of the transaction as well as the coordinates of the asset being transacted, be it movable or immovable. Depending on thedesired implementation, the coordinates may be approximate in the case of the individuals or asset being movable.

[0073] If there are more than two participants in the transaction, a shell of a geometric figure is formed from the points of GPS coordinates, which must fit into a square with a side of a predetermined distance (e.g., 5 sq.m). In all other cases, the transaction participants are invited to select the GPS coordinates of the property transaction management device 101.

[0074] Preceding certificate ID 810 can be an identifier pointing to the preceding certificate of the blockchain records for the property associated with the transaction.

[0075] Preceding certificate assignment date 812 can indicate the date of the preceding certificate.

[0076] Consensus is considered reached when each party has confirmed participation (e.g., by transferring a digital signature) and has received its own copy of the transaction certificate 800 (hereinafter referred to as the certificate). After that, the parties to the transaction will ensure the transfer of the digital certificate to the decentralized storage. The transaction certificate is stored in a decentralized storage, and each copy of it is stored in the local storage of the transaction parti cipant(s) device 103 participating in the consensus. Any attempt to remove or replace the certificate will result in automatic recovery from local storage and notification of all parties about the fact of fabrication. Depending on the desired implementation, a push notification to all participants in the transaction is conducted and automatic comparison of signatures and timestamps is conducted with the local copies of the participants. If the values of the transaction context information 802 or the other fields differ from the local copies, then the certificate can be automatically restored from the local copy of any available participant, according to the decentralized storage consensus rules.

[0077] An example transaction certificate 800 in JavaScript Object Notation (JSON) is as follows:{“id”: [100,101,102,103,103,105,106,107,108,109,110,111],“gps”: [12343.4333, 432423.34311, 1000],“stamp”: ‘2022-06-15T13:45:30.0000000Z’,“creator” :”4BFF314672DA45E280A916FCE2C2E 1E68A2110D4F736D97344C 1”, “certifying node”:“4BF 1672D A45E280 A916FCE2C2E 1E68 A2110D4F736D97344C 1 ”,“context” :”Rjk20ENGOEYlMkI5NEM3RUIxMkE4QOEOQzJGMOJCMzQ=”, “device”:”FFF968CF8F52B94C7EB12A8CA4C2F3BB34”, “participants”:[“2CCBBC69267C4B85BB06B22D71DED7170A87337AB39E46473 3”, “C4AC657976324C0BBB850952E848E50F22085BD85CDC42DAB46”,“C635C3308273459BA0B89513474D133E1AF1793FB43441F293B9919A3B2”]}

[0078] In some examples, the timestamp may be indicative of an average of the sum of minutes and an average of sum of seconds of the timestamp of each node of the set of nodes. The location attribute may denote an average of Global Positioning System (GPS) coordinates of the set of nodes. The timestamp and the location attribute may allow the time and place of the transaction to be recorded. In examples where the location of transactions is indiscernible, such as when a property does not have a local street address, the coordinates of the entities signing the transaction context may be stored in the location attribute. In such examples, the coordinates may allowjudicial entities to resolve jurisdictional challenges, if a dispute is raised. In some examples, the time of transaction may be stored in the timestamp attribute for future validations of the transaction, such as when a dispute over the transaction is taken to judicial entities where time of concluding the transaction is required.

[0079] The proposed consensus protocol guarantees the possibility of participation of more than one party and the fact of confirmation of familiarization with the context of the transaction. Further, such confirmation can be achieved without access to the Internet. Further, the example implementations allow for the transfer of a copy of the certificate to each party to the transaction, and depending on the desired implementation, the subsequent deletion of the transaction data from the memory of the property transaction management device 101. In addition, the transaction parti cipant(s) device 103 and the property transaction management device 101 can conduct competitive transfer of the certificate to the decentralized storage of the trusted entity blockchain management system 105 upon detection of a connection to the trusted entity blockchain management system 105 (e.g., via internet or by LAN at a facility for the trusted entity blockchain management system 105). Recovery of a lost or fabricated certificate from a local copy of one of the property transaction management device 101 and the transaction participant(s) device 103 is also possible. Further, comparison of the date, time, and place of the transaction of all parties can be conducted.

[0080] Thus, when transactions are conducted between the property transaction management device 101 and the one or more transaction participant s) device 103, the consensus members are predetermined and their participation is confirmed by digital signature transmission by hardware and short-range protocols. The creation of the certificate can also thereby take place on a stand-alone hardware device without access to the Internet. A sample of the Certificate is transferred to the decentralized storage by the participants of the transaction on a competitive basis and is restored only from a copy of the certificate of the participants in the transaction. The proposed protocol allows the participation of an independent legal party - the guarantor of the transaction for two fixed functions of the centralized control of the transaction: the approval of the certificate or its restoration based on the decision of the legal institutions of the jurisdiction.

[0081] In some embodiments, the transaction context may include information about a transaction concluded between two or more entities. In some embodiments, the transaction context may be executed as the smart contract. In other embodiments, the transaction context may be indicative of a tokenized text document. In further embodiments, the transaction context may be indicative of images, videos, audio files, or any other media files that have been tokenized. The transaction context may include information on the transaction, such as identity of the entities, instructions associated with the transaction (such as transfer of tokens corresponding to assets from a first entity to a second entity), and the like. In some examples, the images of a physical contract may be tokenized to indicate conclusion of the transaction between two or more entities.

[0082] FIG. 9 illustrates an example flow for providing proof of ownership to the property transaction management device 101, in accordance with an example implementation. At first at 900, the owner / user of the property transaction management device 101 is authenticated. The owner / user of the property transaction management device 101 can be the actual owner of the underlying property in question, an agent working on behalf of the actual owner, a government agent, an agent working for the trusted entity blockchain management system 105 to facilitate the transaction, or otherwise depending on the desired implementation. Such authentication can be conducted through the application 281, which can include the submission of biometrics or a video call online over the internet through the application 281, along with an identification of the property in question. In another example implementation, application 281 can be used in conjunction with a LAN connection with a facility of the trusted entity blockchain management system 105 so that the user of the property transaction management device 101 can be authenticated in person. In another example implementation, the authentication can be sent by other means (e.g., via mail, via e-mail, via text) to the trusted entity blockchain management system 105, which can then be processed accordingly.

[0083] Once authenticated, the trusted entity blockchain management system 105 can then generate the proof of ownership at 901. The proof of ownership 902 can then be distributed to the property transaction management device 101 as the proof of ownership 283. Subsequently, the trusted entity blockchain management system 105 can record the proof of ownership onto the blockchain records corresponding to the property to undergo the transaction at 903. A copy of the blockchain records with the proof of ownership recorded thereon can be transmitted at 904 as blockchain copy 282. Depending on the desired implementation, such a blockchain copy can be transmitted as encrypted blockchain records.

[0084] FIG. 10 illustrates an example flow of the proof of ownership, in accordance with an example implementation. In an example implementation, the trusted entity blockchain management system 105 manages a public interface (e.g., a website, a local office with a secure LAN that is connectable via the transaction participant(s) device 103, and so on in accordance with the desired implementation) that indicates the properties managed by the trusted entity blockchain management system 105. At 1001, the transaction parti cipant(s) device 103 submits a request for proof of ownership to the trusted entity blockchain management system 105. At 1002, the trusted entity blockchain management system 105 transmits a request to the property transaction management device 101 managing the property associated with the request for authorization for forming a proof of ownership. Such a request can be in the form of a Uniform Resource Locator (URL) provided to the property transaction management device 101 to authorize formation of proof of ownership for the transaction (e.g., via e-mail, by text message, or by other methods in accordance with the desired implementation). Once authorized by the property transaction management device 101 at 1003, a non-fungible token (NFT) is generated by the trusted entity blockchain management system 105 to be recorded on the blockchain records associated with the property that a proof of ownership is to be authorized at 1004, wherein a copy of the NFT is issued to the property transaction management device 101 as theproof of ownership 283 at 1005. Depending on the desired implementation, a copy of the NFT can also be issued to the transaction participant s) device 103 as well.

[0085] Accordingly, when the parties meet, the verification of ownership 774 can be established in several ways. In example implementations in which the copy of the NFT is transmitted to the transaction parti cipant(s) device 103, the copy of the NFT representing the proof of ownership 283 can be displayed on the property management device 101 and verified with the copy of the NFT provided to the transaction parti cipant(s) device 103. Such a verification can be, for example, a display of an image associated with the NFT. In another example implementation, the copy of the NFT can be displayed on the display 206 of the property management device 101 in the form of a scannable code (e.g., a Quick Release (QR) code, a bar code, and so on in accordance with the desired implementation). Once scanned by the transaction parti cipant(s) device 103, the application 281 stored on the transaction parti cipant(s) device 103 can verify if the copy of the NFT corresponding to the scannable code corresponds to the copy of the NFT provided to the transaction participant s) device 103, and provide the result on the display 206 of the transaction participant(s) device 103.

[0086] In example implementations in which the copy of the NFT is not provided to the transaction participant(s) device 103, a digital stamp code represented of the copy of the NFT can also displayed as the proof of ownership 283, or otherwise provided to the transaction parti cipant(s) device 103 by some means of communication (e.g., by e-mail, by text message, by voice mail, and so on, in accordance with the desired implementation). The transaction parti cipant(s) device 103 can then provide the digital stamp code to the trusted entity blockchain management system 105 (e.g., via LAN or WAN) to receive a result as to whether the digital stamp code is valid or invalid. Further explanation of the digital stamp code is provided herein.

[0087] Through such an example implementation, proof of ownership can be established by the property owner or an agent acting on behalf of the property owner without having to divulge any private information or even the identity of the owner at this preliminary stage of the transaction. This can prevent phishing attempts from unscrupulous parties trying to identify the owner of a particular property without having any intent to make a transaction. Further, as the NFT is maintained by the trusted entity blockchain management system 105, even if an unscrupulous third party manages to obtain a copy of the NFT for the proof of ownership, the proof of ownership would only be valid for a particular transaction or in response to a particular request, and would not be usable as proof of ownership in any other contexts. Additionally, the NFT associated with the proof of ownership can be set to expire after a certain time period (e.g., as set by the trusted entity blockchain management system 105 or by the owner / user of the property transaction management device 101). The time period can also be used by application 281 to delete the NFT or proof of ownership 283 from the property transaction management device 101 and / or the transaction parti cipant(s) device 103.

[0088] FIG. 10B illustrates an example flow for execution of transactions between the transaction participant(s) device and the property transaction management device, in accordance with an example implementation. In a typical real estate registration workflow, there can be various steps that need to be taken by the parties ahead of time before the closing and recordation of the transaction certificate can take place. In such an example, the authorized parties transmit transaction context to the trusted entity blockchain management system 105, which can record the confirmation of the transaction context and distribute the confirmation to the associated parties.

[0089] In an example flow, a transaction participant device 103 transmits the transaction context to the trusted entity blockchain management system 105 at 1011 to fulfill a requirement placed upon the transaction participant. The trusted entity blockchain management system 105then contacts the property transaction management device 101 at 1012 to request authorization for generating and recording a confirmation of the transaction context. This flow can include providing documents for the owner of the property transaction management device 101 to review and sign to provide the authorization 1013.

[0090] At 713, once the authorization is provided, the trusted entity blockchain management system 105 can then generate and record the confirmation on the blockchain at 1014, and then distribute the confirmation to the participants at 1015. Depending on the desired implementation, the transaction context can also be initiated by the property transaction management device 101 for obligations imposed on the owner’s side. In which case, the flow proceeds directly to 1014 to record the transaction context on the blockchain by the owner and then distributed to the participants at 1015.

[0091] Taking a purchase sales agreement as an example, suppose the purchaser has executed the contract and needs the seller to execute the contract. The transaction participant device 103 of the purchaser provides the purchase sales agreement as the transaction context for recordation on to the blockchain using the flow of FIG. 10B, and the seller provides the signature and confirmation of the contract from the property transaction management device 101.

[0092] In another example implementation involving an earnest money deposit, the transaction participant device 103 of the purchaser places an earnest money deposit, and then submits a request for confirmation of receipt of the deposit as the transaction context. The seller provides the confirmation using the flow of FIG. 10B from the property transaction management device 101 and records the confirmation on the blockchain.

[0093] In another example implementation involving mortgage approval, the transaction participant device 103 of the purchaser provides the loan approval documentation as the transaction context, wherein the seller provides the confirmation of the loan approvaldocumentation using the flow of FIG. 10B from the property transaction management device 101 and records the confirmation on the blockchain.

[0094] In another example implementation involving title insurance, the transaction participant device 103 of the title insurance company or the purchaser provides the title search as the transaction context, wherein the seller provides the confirmation of the title search being satisfactory using the flow of FIG. 10B from the property transaction management device 101 and records the confirmation on the blockchain. If there is a dispute in the title search, then the transaction participant device 103 can provide a request to resolve the disputes in the title search, and the seller provides the confirmation with the resolutions from the property transaction management device 101.

[0095] Other flows are also possible in view of the above depending on jurisdictional rules and the present disclosure is not limited thereto.

[0096] FIG. 11 illustrates an example of a digital stamp that can be used to confirm and validate the authenticity of digitized or tokenized values, in accordance with an example implementation. In particular, such example implementations can be used to confirm and validate the authenticity of non-fungible tokens (NFTs) to establish proof of ownership or proof of transaction as described herein. Such a digital stamp can include fields as follows.

[0097] Entity Category 1101 can indicate a property category represented as a number or other code. Examples of entity categories can include, but are not limited to, real property, intellectual property, art works, music, and so on depending on the desired implementation.

[0098] Type 1102 indicates the object virtualization method used, such as digital (a stamp on a digital object not stored in the blockchain), tokenized (a stamp on a digital object stored in the blockchain), collection (stamp on a collection of identical items), and so on. Depending on the type, the way of generating and validating other parts of the stamp can change.

[0099] Original Storage (Blockchain) 1103 can be a blockchain code for tokenized objects (e.g., Ethereum, Solena, etc.).

[0100] Data Binary Sequence 1104 is the binary index code based on the binary data of tokenized object (e.g., media file and collection of stamp attributes)

[0101] Algorithm Encode Type 1105 can include the internal technical code

[0102] Date Code 1106 is date code or time stamp of the object creation.

[0103] Owner (issuer) 1107 is the object creator encoded payment address shortcode, which should be the same as the tokenized object issuer.

[0104] Although it is possible to duplicate stamp codes, clone NFT data or digital data, the stamp code as described herein will be valid only for an original asset, because conflicting results will have different timestamps for the creation of the digital stamp code and for the identity of the original issuer or parties involved.

[0105] The stamp code can also be checked by the trusted entity blockchain management system 105. If the metadata of the NFT and other data does not correspond to the property, then the trusted entity blockchain management system 105 will indicate that the stamp code is invalid. Depending on the desired implementation, participants can also validate tokenized objects by providing just a blockchain address of the tokenized object, from which the trusted entity blockchain management system 105 parses the metadata, finds stamp code and validates the stamp code.

[0106] FIG. 12 illustrates an example interface and process for validating a digital stamp code, in accordance with an example implementation. The digital stamp code described in FIG. 12 can be validated by any third-party entity. As illustrated, the transaction participant(s) device 103 transmits a request signal to a validation interface at 1204 as provided by the trusted entity blockchain management system 105. In some embodiments, the validation interface can be in the form of a validation server managed by the trusted entity blockchain management system105, or can be a node in the decentralized network facilitating the blockchain. The validation interface 1204 may be configured to receive the request signals any third-party entity. The request signal may include an identifier associated with an NFT. The validation interface 1204 may verify the validity of the NFT. In some embodiments, the validation interface 1204 may be configured to retrieve the NFT in the blockchain records having the same identifier provided in the request signal. Based on attributes of the NFT retrieved from the blockchain records matching those of the NFT with the transaction parti cipant(s) device 103, the validation interface 1204 may transmit a response signal to indicate whether the transaction certificate is either “valid” or “invalid”. The transaction parti cipant(s) device 103 may receive the response signal from the validation interface 1204. In some embodiments, the request signal and the response signal may be transmitted through Application Programming Interfaces (APIs). In other embodiments, the request signal and the response signal may be transmitted using other communication protocols.

[0107] FIG. 13 illustrates an example of provision of authorized information from the trusted entity blockchain management system 105, in accordance with an example implementation. Such an example implementation can be used to authorize the trusted entity blockchain management system 105 to provide details about a property or other managed asset as permitted by the owner or by the property transaction management device.

[0108] At 1301, the property transaction management device 101 can indicate the type of data that is authorized to be made public by the trusted entity blockchain management system 105. Such information can include, but is not limited to, details regarding previous transactions, identity of the owner of the property, previous purchase price, location or boundaries of the property, legal documents, and so on in accordance with the desired implementation. The authorization can also be limited by time period (e.g., accessible only for a certain time period), by user (e.g., accessible only by people who provide the correct credentials) and so on, inaccordance with the desired implementation., At 1302, the trusted entity blockchain management system 105 can generate and record an NFT on the blockchain record reflective of the authorization, which is used to define the authorized information available for decryption.

[0109] In another example implementation, certain aspects of the property can also be always accessible to the public by the trusted entity blockchain management system 105 in exchange for a fee. Such information can include, for example, whether the property is available for purchase, specific government legal documents, inspection reports, or other information depending on the property and the desired implementation.

[0110] At 1303, the transaction participant(s) device 103 utilizes their application 281, visits the website or webserver of the trusted entity blockchain management system 105, or through other desired implementations to request specific information regarding the property. At 1304, the trusted entity blockchain management system 105 determines whether authorization is granted for the information, and if so, decrypts the authorized information 1304 from the blockchain records and provides the authorized information 1305 to the transaction participant device 103. In another example implementation, the trusted entity blockchain management system 105 may perform 1304 and 1305 in response to receipt of a fee from the transaction parti cipant(s) device 103.

[0111] Depending on the desired implementation, the above can also be combined with the request for the proof of ownership 1001. That is, proof of ownership can be requested along with the submission of the fee along with additional requested information regarding the property. The trusted entity blockchain management system 105 can provide the authorized information 1305 alongside the distribution of the proof of ownership 1005, in accordance with the desired implementation.

[0112] FIG. 14 illustrates an example computing environment with an example computer device suitable for use in some example implementations, such as functionality to provide blockchain node 310, ordering service 330, webserver or validation interface 1204, and so on. Computer device 1405 in computing environment 1400 can include one or more processing units, cores, or processors 1410, memory 1415 (e.g., RAM, ROM, and / or the like), internal storage 1420 (e.g., magnetic, optical, solid-state storage, and / or organic), and / or IO interface 1425, any of which can be coupled on a communication mechanism or bus 1430 for communicating information or embedded in the computer device 1405. IO interface 1425 is also configured to receive images from cameras or provide images to projectors or displays, depending on the desired implementation.

[0113] Computer device 1405 can be communicatively coupled to input / user interface 1435 and output device / interface 1440. Either one or both of the input / user interface 1435 and output device / interface 1440 can be a wired or wireless interface and can be detachable. Input / user interface 1435 may include any device, component, sensor, or interface, physical or virtual, that can be used to provide input (e.g., buttons, touch-screen interface, keyboard, a pointing / cursor control, microphone, camera, braille, motion sensor, accelerometer, optical reader, and / or the like). Output device / interface 1440 may include a display, television, monitor, printer, speaker, braille, or the like. In some example implementations, input / user interface 1435 and output device / interface 1440 can be embedded with or physically coupled to the computer device 1405. In other example implementations, other computer devices may function as or provide the functions of input / user interface 1435 and output device / interface 1440 for a computer device 1405.

[0114] Examples of computer device 1405 may include, but are not limited to, highly mobile devices (e.g., smartphones, devices in vehicles and other machines, devices carried by humans and animals, and the like), mobile devices (e.g., tablets, notebooks, laptops, personalcomputers, portable televisions, radios, and the like), and devices not designed for mobility (e.g., desktop computers, other computers, information kiosks, televisions with one or more processors embedded therein and / or coupled thereto, radios, and the like).

[0115] Computer device 1405 can be communicatively coupled (e.g., via IO interface 1425) to external storage 1445 and network 1450 for communicating with any number of networked components, devices, and systems, including one or more computer devices of the same or different configuration. Computer device 1405 or any connected computer device can be functioning as, providing services of, or referred to as a server, client, thin server, general machine, special-purpose machine, or another label.

[0116] IO interface 1425 can include but is not limited to, wired and / or wireless interfaces using any communication or IO protocols or standards (e.g., Ethernet, 802.1 lx, Universal System Bus, WiMAX, modem, a cellular network protocol, and the like) for communicating information to and / or from at least all the connected components, devices, and network in computing environment 1400. Network 1450 can be any network or combination of networks (e.g., the Internet, local area network, wide area network, a telephonic network, a cellular network, satellite network, and the like).

[0117] Computer device 1405 can use and / or communicate using computer-usable or computer readable media, including transitory media and non-transitory media. Transitory media include transmission media (e.g., metal cables, fiber optics), signals, carrier waves, and the like. Non-transitory media include magnetic media (e.g., disks and tapes), optical media (e.g., CD ROM, digital video disks, Blu-ray disks), solid-state media (e.g., RAM, ROM, flash memory, solid-state storage), and other non-volatile storage or memory.

[0118] Computer device 1405 can be used to implement techniques, methods, applications, processes, or computer-executable instructions in some example computing environments. Computer-executable instructions can be retrieved from transitory media and stored on andretrieved from non-transitory media. The executable instructions can originate from one or more of any programming, scripting, and machine languages (e.g., C, C++, C#, Java, Visual Basic, Python, Perl, JavaScript, and others).

[0119] Processor(s) 1410 can execute under any operating system (OS) (not shown), in a native or virtual environment. One or more applications can be deployed that include logic unit 1460, application programming interface (API) unit 1465, input unit 1470, output unit 1475, and inter-unit communication mechanism 1495 for the different units to communicate with each other, with the OS, and with other applications (not shown). The described units and elements can be varied in design, function, configuration, or implementation and are not limited to the descriptions provided. Processor(s) 1410 can be in the form of hardware processors such as central processing units (CPUs) or in a combination of hardware and software units.

[0120] In some example implementations, when information or an execution instruction is received by API unit 1465, it may be communicated to one or more other units (e.g., logic unit 1460, input unit 1470, output unit 1475). In some instances, logic unit 1460 may be configured to control the information flow among the units and direct the services provided by API unit 1465, the input unit 1470, the output unit 1475, in some example implementations described above. For example, the flow of one or more processes or implementations may be controlled by logic unit 1460 alone or in conjunction with API unit 1465. The input unit 1470 may be configured to obtain input for the calculations described in the example implementations, and the output unit 1475 may be configured to provide an output based on the calculations described in example implementations.

[0121] As described herein, processor(s) 1410 can be configured to execute a method or computer instructions involving managing a plurality of encrypted blockchain records, each of the plurality of encrypted blockchain records associated with a corresponding property; and for receipt of a stamp code directed at the corresponding property of one of the plurality ofencrypted blockchain records, associated with a non-fungible token (NFT) stored in one of the encrypted blockchain records, determining validity of the stamp code with the one of the encrypted blockchain records associated with the NFT; and providing a result indicative of proof of ownership of the corresponding property of the one of the encrypted blockchain records to a device that submitted the stamp code, based on the determination of validity. The proposed implementation is an improvement over related art implementations using a liveness hash, as the NFT is a conditional proof of ownership that is temporary in nature and as only directed to a particular entity that is interested in the proof of ownership. Thus, even if the stamp code is copied and utilized by an unscrupulous third party, it cannot be used as a general proof of ownership against any other entity as the stamp code is only valid to the parties of interest. Further, the NFT record can indicate that the stamp code is only valid for one time use when the proof of ownership is validated and not against subsequent attempts to validate, depending on the desired implementation.

[0122] Processor(s) 1410 can be configured to execute the method or instructions described above, wherein the result comprises an indication of the proof of ownership being valid or invalid.

[0123] Processor(s) 1410 can be configured to execute the method or instructions as described above, wherein the determining the validity of the stamp code with one of the encrypted blockchain records associated with the NFT comprises determining whether the stamp code corresponds with the NFT stored in the one of the encrypted blockchain records.

[0124] Processor(s) 1410 can be configured to execute the method or instructions as described above, and further involve, for the determination of the validity of the stamp code being determined to be valid, decrypting authorized information in the corresponding blockchain records based on the NFT stored in the one of the encrypted blockchain records;wherein the providing the result indicative of the proof of ownership of the corresponding property comprises providing the decrypted authorized information to the device.

[0125] Processor(s) 1410 can be configured to execute the method or instructions as described above, wherein the NFT stored in the one of the encrypted blockchain records defines the authorized information available for decryption.

[0126] Processor(s) 1410 can be configured to execute the method or instructions as described above, wherein the NFT stored in the one of the encrypted blockchain records defines a period of time for which the authorized information is available for decryption.

[0127] Processor(s) 1410 can be configured to execute the method or instructions as described above, and further involve, for receipt of a transaction certificate in a form of the NFT directed to the corresponding property of the one of the encrypted blockchain records; verifying ownership information of the transaction certificate with ownership information stored in the one of the encrypted blockchain records; and recording the transaction certificate in the one of the encrypted blockchain records associated with the corresponding property.

[0128] Processor(s) 1410 can be configured to execute the method or instructions as described above, and further involve returning a receipt of the recordation of the transaction certificate to devices of one or more participants indicated in the transaction certificate.

[0129] Processor(s) 1410 can be configured to execute the method or instructions as described above, wherein the corresponding property is real property; wherein the transaction comprises a conveyance of the real property to another party.

[0130] Processor(s) 1410 can be configured to execute the method or instructions as described above, and further include, for receipt of a request for property information directed at the corresponding property of one of the plurality of encrypted blockchain records, determining whether authorization is permitted for the request, and for the authorization being permitted, decrypting authorized information from the one of the plurality of encryptedblockchain records, and providing the decrypted authorized information to a device that submitted the request.

[0131] Processor(s) 1410 can be configured to execute the method or instructions as described above, wherein the determining whether authorization is permitted for the request comprises determining whether a fee has been received and whether the requested property information is directed to public information, and wherein the authorization is permitted for receipt of the fee and for a determination that the requested property information is directed to public information.

[0132] Processor(s) 1410 can be configured to execute the method or instructions as described above, wherein the determining whether authorization is permitted for the request comprises determining whether authorization is recorded on the one of the plurality of encrypted blockchain records; and wherein the authorization is permitted for the determination that the authorization is recorded on the one of the plurality of encrypted blockchain records.

[0133] Some portions of the detailed description are presented in terms of algorithms and symbolic representations of operations within a computer. These algorithmic descriptions and symbolic representations are the means used by those skilled in the data processing arts to convey the essence of their innovations to others skilled in the art. An algorithm is a series of defined steps leading to a desired end state or result. In example implementations, the steps carried out require physical manipulations of tangible quantities for achieving a tangible result.

[0134] Unless specifically stated otherwise, as apparent from the discussion, it is appreciated that throughout the description, discussions utilizing terms such as “processing,” “computing,” “calculating,” “determining,” “displaying,” or the like, can include the actions and processes of a computer system or other information processing device that manipulates and transforms data represented as physical (electronic) quantities within the computer system’s registers andmemories into other data similarly represented as physical quantities within the computer system’s memories or registers or other information storage, transmission or display devices.

[0135] Example implementations may also relate to an apparatus for performing the operations herein. This apparatus may be specially constructed for the required purposes, or it may include one or more general-purpose computers selectively activated or reconfigured by one or more computer programs. Such computer programs may be stored in a computer readable medium, such as a computer-readable storage medium or a computer-readable signal medium. A computer-readable storage medium may involve tangible mediums such as, but not limited to optical disks, magnetic disks, read-only memories, random access memories, solid state devices and drives, or any other types of tangible or non-transitory media suitable for storing electronic information. A computer readable signal medium may include mediums such as carrier waves. The algorithms and displays presented herein are not inherently related to any particular computer or other apparatus. Computer programs can involve pure software implementations that involve instructions that perform the operations of the desired implementation.

[0136] Various general-purpose systems may be used with programs and modules in accordance with the examples herein, or it may prove convenient to construct a more specialized apparatus to perform desired method steps. In addition, the example implementations are not described with reference to any particular programming language. It will be appreciated that a variety of programming languages may be used to implement the techniques of the example implementations as described herein. The instructions of the programming language(s) may be executed by one or more processing devices, e.g., central processing units (CPUs), processors, or controllers.

[0137] As is known in the art, the operations described above can be performed by hardware, software, or some combination of software and hardware. Various aspects of the exampleimplementations may be implemented using circuits and logic devices (hardware), while other aspects may be implemented using instructions stored on a machine-readable medium (software), which if executed by a processor, would cause the processor to perform a method to carry out implementations of the present application. Further, some example implementations of the present application may be performed solely in hardware, whereas other example implementations may be performed solely in software. Moreover, the various functions described can be performed in a single unit, or can be spread across a number of components in any number of ways. When performed by software, the methods may be executed by a processor, such as a general-purpose computer, based on instructions stored on a computer-readable medium. If desired, the instructions can be stored on the medium in a compressed and / or encrypted format.

[0138] Moreover, other implementations of the present application will be apparent to those skilled in the art from consideration of the specification and practice of the techniques of the present application. Various aspects and / or components of the described example implementations may be used singly or in any combination. It is intended that the specification and example implementations be considered as examples only, with the true scope and spirit of the present application being indicated by the following claims.

Claims

CLAIMSWhat is claimed is:

1. A method, comprising: managing a plurality of encrypted blockchain records, each of the plurality of encrypted blockchain records associated with a corresponding property; and for receipt of a stamp code directed at the corresponding property of one of the plurality of encrypted blockchain records, associated with a non-fungible token (NFT) stored in one of the encrypted blockchain records: determining validity of the stamp code with the one of the encrypted blockchain records associated with the NFT; and providing a result indicative of proof of ownership of the corresponding property of the one of the encrypted blockchain records to a device that submitted the stamp code, based on the determination of validity.

2. The method of claim 1, wherein the result comprises an indication of the proof of ownership being valid or invalid.

3. The method of claim 1, wherein the determining the validity of the stamp code with one of the encrypted blockchain records associated with the NFT comprises determining whether the stamp code corresponds with the NFT stored in the one of the encrypted blockchain records.

4. The method of claim 1, further comprising, for the determination of the validity of the stamp code being determined to be valid, decrypting authorized information inthe corresponding blockchain records based on the NFT stored in the one of the encrypted blockchain records; wherein the providing the result indicative of the proof of ownership of the corresponding property comprises providing the decrypted authorized information to the device.

5. The method of claim 4, wherein the NFT stored in the one of the encrypted blockchain records defines the authorized information available for decryption.

6. The method of claim 4, wherein the NFT stored in the one of the encrypted blockchain records defines a period of time for which the authorized information is available for decryption.

7. The method of claim 1, further comprising: for receipt of a transaction certificate in a form of the NFT directed to the corresponding property of the one of the encrypted blockchain records: verifying ownership information of the transaction certificate with ownership information stored in the one of the encrypted blockchain records; and recording the transaction certificate in the one of the encrypted blockchain records associated with the corresponding property.

8. The method of claim 7, further comprising: returning a receipt of the recordation of the transaction certificate to devices of one or more participants indicated in the transaction certificate.

9. The method of claim 7, wherein the corresponding property is real property; wherein the transaction comprises a conveyance of the real property to another party.

10. The method of claim 1, further comprising: for receipt of a request for property information directed at the corresponding property of one of the plurality of encrypted blockchain records: determining whether authorization is permitted for the request, and for the authorization being permitted, decrypting authorized information from the one of the plurality of encrypted blockchain records, and providing the decrypted authorized information to a device that submitted the request.

11. The method of claim 10, wherein the determining whether authorization is permitted for the request comprises determining whether a fee has been received and whether the requested property information is directed to public information, and wherein the authorization is permitted for receipt of the fee and for a determination that the requested property information is directed to public information.

12. The method of claim 10, wherein the determining whether authorization is permitted for the request comprises determining whether authorization is recorded on the one of the plurality of encrypted blockchain records; and wherein the authorization is permitted for the determination that the authorization is recorded on the one of the plurality of encrypted blockchain records.

13. A computer program, storing instructions that when executed by one or more processors, execute the method as described in claims 1-12.

14. An apparatus, comprising a processor configured to execute the method as described in claims 1-12.

Images