Method, system, and device for executing property transactions involving distributed ledger technologies

Abstract

Systems, methods, computer programs, and devices for property transaction management, involving storing / managing a copy of blockchain records corresponding to blockchain records of a trusted entity, each of the blockchain records associated with a corresponding property; and recording a transaction associated with the corresponding property associated with one of the blockchain records by generating a transaction certificate to certify the transaction, the transaction certificate being in a form of a non-fungible token (NFT) that is recorded onto the one of the blockchain records in the local memory associated with the corresponding property; providing the transaction certificate to one or more participants of the transaction; and for a network connection between the device and the trusted entity being available, submitting the certificate to the trusted entity for recordation onto the one of the blockchain records managed by the trusted entity associated with the corresponding property.

Description

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

[0001] The present application claims priority toU.S. Provisional Application No. 63 / 669,543, titled “METHOD, SYSTEM, AND DEVICEFOR 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”, filed on July 10, 2024, 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 executing property transactions 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 theenvironment, obtaining approvals for a transaction can be very time-consuming and / or oftentimes inaccurate. The transaction may be concluded between two parties (such as through execution 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 areimplemented using a network of nodes that interact with each other to enable transactions to be 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 to facilitate verifiable credentials and decentralized identities to establish ownership. In such related art implementations, an owner presents their verifiable credentials and then, to transfer ownership of goods in an offline manner, transfers an ownership verifiable credential to facilitate credential chaining from the previous owner to the new owner, which is then used to transfer ownership to the buyer oncethe buyer provides the ownership verifiable credential to the blockchain. However, while such ownership verifiable credentials are useful for environments such as factory floors in which ownership can change rapidly along a supply chain, it is not appropriate for real estate transactions in which a lengthy period of time may occur between transactions, thereby increasing the risk of a malicious third party obtaining a copy of the ownership verifiable credential and utilizing the credential to make malicious transactions.SUMMARY

[0010] Aspects of the present disclosure can involve a device for property transaction management, which can include a local memory, configured to store a copy of blockchain records corresponding to blockchain records of a trusted entity, each of the blockchain records associated with a corresponding property; and a processor, configured to, for recording a transaction associated with the corresponding property associated with one of the blockchain records, generate a transaction certificate to certify the transaction, the transaction certificate being in a form of a non-fungible token (NFT) that is recorded onto the one of the blockchain records in the local memory associated with the corresponding property; provide the transaction certificate to one or more participants of the transaction; and for a network connection between the device and the trusted entity being available, submit the NFT to the trusted entity for recordation onto the one of the blockchain records managed by the trusted entity associated with the corresponding property.

[0011] Aspects of the present disclosure can involve a method for property transaction management, involving, storing a copy of blockchain records corresponding to blockchain records of a trusted entity, each of the blockchain records associated with a corresponding property; and recording a transaction associated with the corresponding property associated with one of the blockchain records, the recording the transaction involving, generating a transaction certificate to certify the transaction, the transaction certificate being in a form of anon-fungible token (NFT) that is recorded onto the one of the stored blockchain records associated with the corresponding property; providing the transaction certificate to one or more participants of the transaction; and for detection of a network connection to the trusted entity being available, submitting the NFT to the trusted entity for recordation onto the one of the blockchain records managed by the trusted entity associated with the corresponding property.

[0012] Aspects of the present disclosure can include a system for property transaction management, which can involve, storing means for storing a copy of blockchain records corresponding to blockchain records of a trusted entity, each of the blockchain records associated with a corresponding property; and recording means for recording a transaction associated with the corresponding property associated with one of the blockchain records, including generating means for generating a transaction certificate to certify the transaction, the transaction certificate being in a form of a non-fungible token (NFT) that is recorded onto the one of the blockchain records in the storing means associated with the corresponding property; providing means for providing the transaction certificate to one or more participants of the transaction; and submitting means for, for a network connection to the trusted entity being available, submitting the NFT to the trusted entity for recordation onto the one of the blockchain records managed by the trusted entity associated with the corresponding property.

[0013] Aspects of the present disclosure can involve a computer program, storing instructions for property transaction management, involving, managing a local copy of blockchain records corresponding to blockchain records of a trusted entity, each of the blockchain records associated with a corresponding property; and recording a transaction associated with the corresponding property associated with one of the blockchain records, the recording the transaction involving, generating a transaction certificate to certify the transaction, the transaction certificate being in a form of a non-fungible token (NFT) that is recorded onto the one of the managed blockchain records associated with the corresponding property; providing the transaction certificate to one or more participants of the transaction;and for detection of a network connection to the trusted entity being available, submitting the NFT to the trusted entity for recordation onto the one of the blockchain records managed by the trusted entity associated with the corresponding property. The computer program and instructions can be stored on a non-transitory computer readable medium and executed by one or more processors.BRIEF DESCRIPTION OF DRAWINGS

[0014] 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:

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

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

[0017] FIG. 3 A illustrates an example flow for execution and recordation of a transaction, in accordance with an example implementation.

[0018] FIG. 3B illustrates an example flow for verifying and recording the transaction certificate, in accordance with an example implementation.

[0019] FIG. 4 illustrates an example flow of the proof of ownership, in accordance with an example implementation.

[0020] FIG. 5 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.

[0021] FIG. 6 illustrates an example interface and process for validating a digital stamp code, in accordance with an example implementation.

[0022] FIGS. 7 A and 7B illustrate an example flow for execution of a transaction between the transaction participant(s) device and the property transaction management device, in accordance with an example implementation.

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

[0024] FIG. 9A and 9B illustrate an example of tokenization of the assets, such as property, in accordance with an example implementation.DETAILED DESCRIPTION

[0025] 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 or administrator 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.

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

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

[0028] 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 information regarding 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.

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

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

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

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

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

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

[0035] 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 managementdevice 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.

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

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

[0038] 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 publiccommunication 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.

[0039] FIG. 3 A illustrates an example flow for execution and recordation of a transaction, in accordance with an example implementation. In an example implementation to facilitate a transaction, the property transaction management device transmits an initiation signal 172 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.

[0040] Transaction parti cipant(s) device 103 then verifies the ownership 174 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.

[0041] Once the transaction parti cipant(s) are satisfied with the proof of ownership, a transaction is executed at 176. 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 180 by the property transaction management device 101. The property transaction management device 101 can then transmit the transaction certificate 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 the trusted entity blockchain management system 105 either by the internet or by LAN, it can transmit the execution signal at 178 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 178 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 verify and record the transaction certificate on the blockchain records corresponding to the property to record the transaction at 182.

[0042] FIG. 3B 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 toexecute a checklist for the underlying jurisdiction to verify that all requirements are met before recordation. At 300, 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 302, otherwise (No), the flow can proceed to 301 to reject the certificate and transmit a message indicating that the certificate was rejected for being sent by an unauthorized party.

[0043] At 302, the compliance check is executed. The compliance check can be a purely automated check that checks for requisite documents or signatures having been provided, or can 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 301 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 303 to verify that the certificate has been recorded on the blockchain.

[0044] FIG. 4 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 401, the transaction parti cipant(s) device 103 submits a request for proof of ownership to the trusted entity blockchain management system 105. At 402, 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 403, 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 404, wherein a copy of the NFT is issued to the property transaction management device 101 as the proof of ownership 283 at 405. Depending on the desired implementation, a copy of the NFT can also be issued to the transaction participant s) device 103 as well.

[0045] Accordingly, when the parties meet, the verification of ownership 174 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.

[0046] 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 entityblockchain 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.

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

[0048] Through the example implementations described herein, an improvement is made in contrast to the use of ownership verifiable credentials as there is no ownership credential or verifiable credential for an unscrupulous party to copy or phish to fake the identity of the owner or proof of ownership, nor is there any ownership verifiable credential to provide to the purchaser. Instead, a temporary proof of ownership is generated only when the property owner authorizes permission to the trusted entity to do so, making it more difficult to obtain or phish, and is only usable in the context with a particular transaction between particular entities. In addition, the purchaser and seller parties issue a transaction certificate to the trusted blockchain entity to record the transaction, whereupon the seller party can subsequently receive a copy ofthe blockchain ledger associated with the real property. Further, as the property transaction management device maintains a copy of the blockchain ledger concerning the real property transaction, any transaction certificates issued to the trusted blockchain entity can be undone from the copy stored at the property transaction management device if the property transaction management device was not associated with the transaction certificate.

[0049] FIG. 5 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.

[0050] Entity Category 501 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.

[0051] Type 502 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.

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

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

[0054] Algorithm Encode Type 505 can include the internal technical code

[0055] Date Code 506 is date code or time stamp of the object creation.

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

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

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

[0059] FIG. 6 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. 6 can be validated by any third-party entity. As illustrated, the transaction parti cipant(s) device 103 transmits a request signal to a validation interface at 604 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 system 105, or can be a node in the decentralized network facilitating the blockchain. The validation interface 404 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 604 may verify the validity of the NFT. In some embodiments, the validation interface 604 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 604 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 responsesignal from the validation interface 404. 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.

[0060] FIGS. 7 A and 7B illustrate an example flow for execution of a transaction between the transaction parti cipant(s) device 103 and the property transaction management device 101, in accordance with an example implementation. The one or more transaction participant(s) device 103 submit transaction context information to the property transaction management device 101 at 701. Such transaction contexts can include signed documents (e.g., physically or digitally signed), contracts, or other information that is used to execute the transaction. Depending on the desired implementation, the owner of the property may also submit such transaction contexts to the property transaction management device 101 if the owner / user of the device of the property transaction management device is not the owner of the property. In example implementations in which the owner of the property is also the owner of the property transaction management device 101, the owner of the property can also digitally review, sign, or execute any contracts received in the transaction context information through application 281 to complete the transaction. In another example implementation, the agent operating the property transaction management device 101 can also sign, review the transaction context information, or finalize the transaction through application 281 to indicate that the transaction is complete depending on the desired implementation and the nature of the property transaction.

[0061] Once the transaction is completed between the parties (e.g., all transaction context information is received by the property transaction management device 101, or the owner / agent of the property transaction management device 101 finalizes the transaction through application 281), the application 281 can then generate a transaction certificate at 702 to certify the transaction in the form of an NFT.

[0062] The transaction certificate serves as proof of a transaction for each of the transaction parti cipant(s) device 103. Once the transaction certificate is generated by the property transaction management device 101, it is recorded on the copy of the blockchain records 282 associated with the property stored in the local memory 208 at 703. A copy of the transaction certificate is then provided to the transaction parti cipant(s) device 103 at 704. When the application 281 of the transaction parti cipant(s) device 103 and / or the property transaction management device 101 can establish a connection to the trusted entity blockchain management system 105 (e.g., either by internet, or by LAN depending on the desired implementation and the nature of the transaction), the transaction certificate can be recorded onto the blockchain record of the corresponding property at the trusted entity blockchain management system 105 as shown at 178.

[0063] In example implementations in which the property transaction management device 101 is managed by someone other than the owner (e.g., a government agent, a notary, etc.), the transaction certificate and copy of blockchain records 282 can also be deleted from the property transaction management device 101 once completed. Through such an example implementation, the property transaction management device 101 is then cleared of all potentially hackable or leakable information from its memory.

[0064] Further, through such example implementations, blockchain records can be restored by the trusted entity blockchain management system 105 in situations in which the trusted entity blockchain management system 105 is hacked or otherwise brought down. Because the property transaction management device 101 was validated by the trusted entity beforehand, the transaction certificate along with the copy of the blockchain records 282 can be used by the trusted entity blockchain management system 105 to restore blockchain records associated with the property to the correct truth.

[0065] Further, as such transactions may be conducted in areas without an immediate internet or LAN connection to the trusted entity blockchain management system 105, once a transactioncertificate is generated by property transaction management device 101, application 281 can disable the generation of any further transaction certificates with respect to the property until the transaction certificate is recorded by the blockchain management system 105. Through such an example implementation, conflicting or malicious subsequent transactions associated with the property can thereby be prevented.

[0066] As described herein, both the property transaction management device 101 and the transaction parti cipant(s) device 103 attempts to upload a copy of the certificate to the trusted entity blockchain management system 105 on a competitive basis. If the certificate has already been uploaded, then the blockchain records are affixed with a confirmation token for uploading a copy of the certificate by the transaction participant. Thus, the transaction can be recorded and certified without requiring a consensus from all devices associated with the transaction, including the property transaction management device 101. The transaction can be completed, even if one of the transaction parti cipant(s) device 103 or the property transaction management device 101 is lost or broken in the interim, or otherwise unable to transmit to the trusted entity blockchain management system 105.

[0067] FIG. 7B 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.

[0068] In an example flow, a transaction participant device 103 transmits the transaction context to the trusted entity blockchain management system 105 at 711 to fulfill a requirement placed upon the transaction participant. The trusted entity blockchain management system 105then contacts the property transaction management device 101 at 712 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 713.

[0069] 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 714, and then distribute the confirmation to the participants at 715. 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 714 to record the transaction context on the blockchain by the owner and then distributed to the participants at 715.

[0070] 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. 7B, and the seller provides the signature and confirmation of the contract from the property transaction management device 101.

[0071] 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. 7B from the property transaction management device 101 and records the confirmation on the blockchain.

[0072] 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 approval documentation using the flow of FIG. 7B from the property transaction management device101 and records the confirmation on the blockchain.

[0073] 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. 7B 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.

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

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

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

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

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

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

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

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

[0082] 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 the desired implementation, the coordinates may be approximate in the case of the individuals or asset being movable.

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

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

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

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

[0087] 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”]}

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

[0089] 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 thetransaction 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.

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

[0091] FIG. 9 A and 9B 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 involving tokenized assets. The tokens may correspond to real-world assets, such as real-estate property.

[0092] As shown, real-world assets may correspond to tangible or intangible assets. FIGs. 9A to 9B illustrate examples where the asset is indicative of an immovable property, such asan 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.

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

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

[0095] In some embodiments, a single token may be generated for the real-world asset, such as an NFT 904 for a building 902, as shown in FIG. 9A. In such embodiments, the single tokenmay 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. 9B. 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 905-1, 905-2, and 905- 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.

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

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

[0098] As described herein, local memory 208 can be configured to store a copy of blockchain records (e.g., blockchain copy 282) corresponding to blockchain records of a trusted entity, each of the blockchain records associated with a corresponding property.

[0099] Processor(s) 202 can be configured to execute a method or instructions which can include, for recording a transaction associated with the corresponding property associated with one of the blockchain records, generate a transaction certificate 800 to certify the transaction, the transaction certificate 800 being in a form of a non-fungible token (NFT) that is recorded onto the one of the blockchain records in the local memory 208 associated with the corresponding property; provide the transaction certificate 800 to one or more participants of the transaction (e.g., transaction parti cipant(s) device 103); and for a network connection between the device and the trusted entity being available, submit the transaction certificate 800 to the trusted entity 105 for recordation onto the one of the blockchain records managed by the trusted entity 105 associated with the corresponding property. Through such a device and its methods or instructions, the example implementations described herein can facilitate asset transactions, even if there is no internet and / or no third-party notary available. Further, because the recorded transaction certificates are managed in local memory, they can be used as the ground truth for property conveyance, even if the trusted entity blockchain management system 105 gets compromised.

[0100] As described herein, the transaction certificate 800 can include a timestamp 806 of the generation of the transaction certificate 800 and location information 808 associated with the device 101 at the timestamp 806. Depending on the desired implementation, the location information 808 can be derived from Global Positioning Satellite (GPS) coordinates of the device 101 and devices 103 associated with one or more participants of the transaction. Even if a malicious party attempts to forge a transaction certificate 800, because it would not havethe correct timestamp 806 or location information 808, the trusted entity blockchain management system 105 can determine that the forged transaction certificates are fraudulent due to having an unexpected timestamp 806 or location information 808.

[0101] Depending on the desired implementation, the transaction certificate can include a transaction context 802 indicating the transaction conducted on the corresponding property.

[0102] Depending on the desired implementation, the transaction certificate 800 can also include a representative of unique signatures of one or more participants in the transaction (e.g., as stored in transaction context information 802 or as managed separately in the transaction certificate 800).

[0103] As described herein, the corresponding property can be real property; wherein the transaction can include a conveyance of the real property to another party. Through such an example implementation, even if the underlying government jurisdiction lacks the proper infrastructure to maintain physical property records, transactions regarding physical property can still be conducted through a blockchain management system 105 and the devices as described herein in a trusted manner.

[0104] As described herein, the device 101 can be a mobile device, wherein the copy of the blockchain records 282 is retrieved by a mobile device application 281 from the trusted entity blockchain management system 105 in response to authentication of ownership of the corresponding property through the mobile device application 281. Such authentication can include, but is not limited to, biometric information, through physical verification at an office of the trusted entity blockchain management system 105, through entering identification, password and / or other credentials, and so on in accordance with the desired implementation.

[0105] As described herein, the device 101 can be a special purpose device corresponding to an owner of the corresponding property, wherein the copy of the blockchain records 282 is preset in the local memory 208. In such an example implementation, the special purpose device can be a device that is issued from an office of the trusted entity blockchain management system105 physically to the user with the preset copy of the blockchain records 282. Such a special purpose device can be issued to the true owner of the property, or can be issued to an agent of the trusted entity blockchain management system 105 or the government to conduct the transaction.

[0106] As described herein, processor(s) 202 can be configured to, for providing proof of ownership of the corresponding property associated with the one of the blockchain nodes: generate a digital stamp in the form of another NFT (e.g., as shown in FIG. 5), the digital stamp configured to authorize access to information associated with the corresponding property as managed in the one of the blockchain records when submitted to the trusted entity as shown in FIG. 6.

[0107] As described herein, processor(s) 202 can be configured to, upon generation of the transaction certificate 800 to certify the transaction, disable subsequent generation of transaction certificates for the corresponding property associated with one of the blockchain records. Such an example implementation can prevent race conditions involving subsequent fraudulent transactions involving the property.

[0108] As described herein, processor(s) 202 can be configured to provide the transaction certificate 800 to devices of one or more participants of the transaction using short-range communication, such as BLUETOOTH, serial cable connections, or other communication methods depending on the desired implementation.

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

[0110] 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 and memories into other data similarly represented as physical quantities within the computer system’s memories or registers or other information storage, transmission or display devices.

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

[0112] 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 theprogramming language(s) may be executed by one or more processing devices, e.g., central processing units (CPUs), processors, or controllers.

[0113] 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 example implementations 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.

[0114] 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 device for property transaction management, comprising: a local memory, configured to store a copy of blockchain records corresponding to the blockchain records of a trusted entity, each of the blockchain records associated with a corresponding property; a processor, configured to, for recording a transaction associated with the corresponding property associated with one of the blockchain records: generate a transaction certificate to certify the transaction, the transaction certificate being in a form of a non-fungible token (NFT) that is recorded onto the one of the blockchain records in the local memory associated with the corresponding property; provide the transaction certificate to one or more participants of the transaction; and for a network connection between the device and the trusted entity being available, submit the transaction certificate to the trusted entity for recordation onto the one of the blockchain records managed by the trusted entity associated with the corresponding property.

2. The device of claim 1, wherein the transaction certificate comprises a timestamp of the generation of the transaction certificate and location information associated with the device at the timestamp.

3. The device of claim 2, wherein the location information is derived from Global Positioning Satellite (GPS) coordinates of the device and devices associated with the one or more participants of the transaction.

4. The device of claim 1, wherein the transaction certificate comprises a transaction context indicating the transaction conducted on the corresponding property.

5. The device of claim 1, wherein the transaction certificate comprises a representative of unique signatures of the one or more participants in the transaction.

6. The device of claim 1, wherein the corresponding property is real property; wherein the transaction comprises a conveyance of the real property to another party.

7. The device of claim 1, wherein the device is a mobile device, wherein the copy of the blockchain records is retrieved by a mobile device application from the trusted entity in response to authentication of ownership of the corresponding property through the mobile device application.

8. The device of claim 1, wherein the device is a special purpose device corresponding to an owner of the corresponding property, wherein the copy of the blockchain records is preset in the local memory.

9. The device of claim 1, wherein the processor is configured to, for providing proof of ownership of the corresponding property associated with the one of the blockchain records: generate a digital stamp in the form of another NFT, the digital stamp configured to authorize access to information associated with the corresponding property as managed in the one of the blockchain records when submitted to the trusted entity.

10. The device of claim 1, wherein the processor is configured to, upon generation of the transaction certificate to certify the transaction, disable subsequent generation oftransaction certificates for the corresponding property associated with one of the blockchain records.

11. The device of claim 1, wherein the processor is configured to provide the transaction certificate to devices of the one or more participants of the transaction using short- range communication.

12. A method for property transaction management, comprising: storing a copy of blockchain records corresponding to the blockchain records of a trusted entity, each of the blockchain records associated with a corresponding property; and recording a transaction associated with the corresponding property associated with one of the blockchain records, the recording the transaction comprising: generating a transaction certificate to certify the transaction, the transaction certificate being in a form of a non-fungible token (NFT) that is recorded onto the stored one of the blockchain records associated with the corresponding property; providing the transaction certificate to one or more participants of the transaction; and for detection of a network connection to the trusted entity being available, submitting the transaction certificate to the trusted entity for recordation onto the one of the blockchain records managed by the trusted entity associated with the corresponding property.

13. The method of claim 12, wherein the transaction certificate comprises a timestamp of the generation of the transaction certificate and location information associated with the device at the timestamp.

14. The method of claim 13, wherein the location information is derived from GlobalPositioning Satellite (GPS) coordinates of the device and devices associated with the one or more participants of the transaction.

15. The method of claim 12, wherein the transaction certificate comprises a transaction context indicating the transaction conducted on the corresponding property.

16. The method of claim 12, wherein the transaction certificate comprises a representative of unique signatures of the one or more participants in the transaction.

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

18. The method of claim 12, wherein the method is executed by a mobile device, wherein the copy of the blockchain records is retrieved by a mobile device application from the trusted entity in response to authentication of ownership of the corresponding property through the mobile device application.

19. The method of claim 12, wherein the method is executed by a special purpose device corresponding to an owner of the corresponding property, wherein the copy of the blockchain records is preset in the local memory.

20. The method of claim 12, further comprising providing proof of ownership of the corresponding property associated with the one of the blockchain records, the providing proof of ownership comprising: generating a digital stamp in the form of another NFT, the digital stamp configured to authorize access to information associated with the corresponding property as managed in the one of the blockchain records when submitted to the trusted entity.

21. The method of claim 12, further comprising, upon generation of the transaction certificate to certify the transaction, disabling subsequent generation of transaction certificates for the corresponding property associated with one of the blockchain records.

22. The method of claim 12, further comprising providing the transaction certificate to the one or more participants of the transaction using short-range communication.

23. A system for property transaction management, comprising: storing means for storing a copy of blockchain records corresponding to the blockchain records of a trusted entity, each of the blockchain records associated with a corresponding property; and recording means for recording a transaction associated with the corresponding property associated with one of the blockchain records, comprising: generating means for generating a transaction certificate to certify the transaction, the transaction certificate being in a form of a non-fungible token (NFT) that is recorded onto the one of the blockchain records in the storing means associated with the corresponding property; providing means for providing the transaction certificate to one or more participants of the transaction; and submitting means for, for a network connection to the trusted entity being available, submitting the transaction certificate to the trusted entity for recordation onto the one of the blockchain records managed by the trusted entity associated with the corresponding property.

Images