JP7844651B2 - Method and system for transferring ownership of NFTs (non-fungible tokens) in refund transactions on a payment network - Google Patents

Description

This disclosure relates to enabling the automatic redemption of non-fungible tokens (NFTs), and in particular to implementing the redemption of NFTs following the redemption in connection with the payment transaction relating to the initial transfer of ownership of the NFTs.

Cross-reference of related applications: This application claims the interests of U.S. Patent Application No. 17/667,246, filed on 8 February 2022, the entire contents of which are incorporated by reference for all uses.

Since its development, blockchain and other distributed ledgers have been used for a wide range of applications. Most commonly, blockchain is used for the management and transfer of digital currencies. The advantages of using blockchain, which has been a major factor in the popularity of digital currencies, include its general immutability, high level of transaction anonymity, and decentralized nature. Because of these advantages, blockchain has been used for a variety of applications, such as voting, data storage, and supply chain management.

Recently, NFTs have gained popularity as an example of blockchain technology. NFTs are digital assets whose ownership can be tracked using blockchain technology. Digital assets can be any type of asset, such as text, data, images, music, or videos. The original creator of the asset creates an NFT for the asset stored on a blockchain such as Ethereum (registered trademark). The creator can then freely transfer the NFT to any other interested party, and the transfer of ownership is registered via a blockchain transaction from the creator to the transferee. In many cases, recipients purchase NFTs through traditional payment transactions using fiat currency.

However, relying on blockchain technology for NFT registration (also known as NFT minting) and transfer does not mean that there are no difficulties. In particular, one drawback is that, unlike traditional payment transactions, blockchain transactions are irreversible due to the decentralization of the blockchain. In traditional payment transactions processed through payment networks such as credit card transactions, if a buyer believes they have been defrauded or fails to receive the purchased product, the payment network can enforce a refund of the payment transaction, guaranteeing that the buyer will recover their payment. However, because blockchain does not have centralized management, there is no function to reverse or refund transactions. Therefore, if either party is forced to rely on the other party to perform a predetermined transaction (e.g., the transfer of the NFT back to the seller or the payment transaction when refunding it to the buyer), both the buyer and seller can be placed in a dangerous position.

Technical improvements to existing technologies are needed to enable reliable and secure redemption of NFTs in connection with their purchase or transfer.

This disclosure provides a description of a system and method for enabling refunds for non-fungible tokens (NFTs) using smart contracts. When an NFT is purchased, a payment transaction is processed for the payment made for the purchase, and an associated identifier is generated. The identifier of the payment transaction is stored in a smart contract, which is added to the blockchain, along with the identifier for the NFT and the blockchain addresses of the buyer and seller. If either party wishes to refund for the transaction, a refund request is submitted to a processing server, which includes the transaction identifier. The processing server initiates the refund for the payment transaction and submits the transaction identifier as input to the smart contract. The smart contract executes a new transaction on the blockchain, transferring ownership back from the buyer to the seller. As a result, both the original payment transaction and the transfer of the NFT are reversed, and both parties return to their original positions. By using smart contracts in conjunction with processing servers, NFT purchases can be reversed, minimizing the actions of both parties and ensuring that the reversal occurs without providing the other party with an opportunity to commit fraud. This provides a significant advantage over existing systems used for transferring NFT ownership.

A method for enabling a refund for a non-fungible token (NFT) includes the following steps: receiving a transaction message for a payment transaction by a receiver on a processing server; processing the payment transaction using at least the transaction message by a processor on the processing server, the processing including the identification of a transaction identifier for the payment transaction; transmitting the transaction identifier to a first computing device by a transmitter on the processing server; receiving a notification message by the receiver on the processing server, the transaction identifier including at least the transaction identifier and the token identifier, the token identifier being associated with the NFT; receiving a refund request message from a second computing device by the receiver on the processing server, the refund request message including at least one of the transaction identifier and the token identifier; processing a refund transaction for the payment transaction by the processor on the processing server; and submitting at least the transaction identifier as input to a smart contract stored in the blockchain associated with the NFT by the transmitter on the processing server.

A system enabling refunds for non-fungible tokens (NFTs) comprises: a first computing device, a second computing device, a blockchain associated with the NFTs, and a processing server, wherein the processing server includes: a receiver that receives a transaction message for a payment transaction; a processor that processes the payment transaction using at least the transaction message, the processing of which includes identifying a transaction identifier for the payment transaction; and a transmitter that transmits the transaction identifier to the first computing device; the receiver of the processing server further receives: a notification message including at least the transaction identifier and a token identifier, wherein the token identifier is associated with the NFTs; a refund request message from the second computing device, wherein the refund request message includes at least one of the transaction identifier and the token identifiers; the processor of the processing server further processes a refund transaction for the payment transaction; and the transmitter of the processing server further submits at least the transaction identifier as input to a smart contract stored in the blockchain associated with the NFTs.

The scope of this disclosure, when interpreted together with the accompanying drawings, will be best understood from the following detailed description of exemplary embodiments. The drawings include the following figures:

This is a block diagram showing a high-level system architecture enabling NFT redemption according to an exemplary embodiment. This is a block diagram showing a processing server that enables NFT refunds in the system shown in Figure 1, according to an exemplary embodiment. This flowchart illustrates the process of transferring ownership of an NFT following a payment transaction in the system shown in Figure 1, according to an exemplary embodiment. This flowchart illustrates the process of transferring ownership of an NFT following a payment transaction in the system shown in Figure 1, according to an exemplary embodiment. This flowchart illustrates the process for performing NFT refunds and associated payment transactions in the system shown in Figure 1, according to an exemplary embodiment. This flowchart illustrates an exemplary method for enabling NFT refunds according to an exemplary embodiment. This block shows a computer system architecture according to an exemplary embodiment.

Further application areas of this disclosure will be obvious from the detailed description below. The detailed description of exemplary embodiments is for illustrative purposes only and is not necessarily intended to limit the scope of this disclosure.

System Enabling Redemption of Non-Fungible Tokens Figure 1 shows a system 100 that provides automatic redemption and reversal of transactions relating to the transfer of ownership of non-fungible tokens (NFTs). System 100 may include a processing server 102. The processing server 102, described below, may be configured to support automatic redemption and reversal of transfers of NFT ownership through the use of smart contracts. In system 100, a party such as the creator of an NFT may own the NFT through a seller device 104, or another party may acquire ownership of the NFT through any suitable method. A party associated with a buyer device 106 may have an interest in purchasing an NFT from a party associated with a seller device 104. In this specification, the parties associated with the seller device 104 and the buyer device 106 may be referred to by the name of their respective associated devices. The seller device 104 and the buyer device 106 can be any type of computing device suitable for performing the functions referred to in this application, such as a cellular phone, smartphone, smartwatch, smart TV, desktop computer, laptop computer, notebook computer, tablet computer, wearable computing device, etc.

In system 100, information regarding the ownership of NFTs can be stored within the blockchain. The blockchain can be managed by a blockchain network 108 included in system 100. The blockchain network 108 can consist of multiple blockchain nodes 110. Each blockchain node 110 can be a computing system, as shown in Figure 2 or 6 and detailed below, configured to perform functions related to the processing and management of the blockchain, and can perform, for example, the following: generating blockchain data values, verifying proposed blockchain transactions, verifying digital signatures, generating new blocks, validating new blocks, and maintaining copies of the blockchain.

A blockchain can be a distributed ledger comprising at least several blocks. Each block may contain at least a block header and one or more data values. Each block header may contain at least a timestamp, a block reference value, and a data reference value. The timestamp may be the time the block header was generated and can be represented using any suitable method (e.g., UNIX timestamp, DateTime notation). The block reference value may be a value that references a preceding block in the blockchain (e.g., based on the timestamp). In some embodiments, the block reference value in the block header may be a reference to the block header of the most recently added block preceding each block. In exemplary embodiments, the block reference value may be a hash value generated by hashing the block header of the most recently added block. Similarly, the data reference value may be a reference to one or more data values stored within the block containing the block header. In exemplary embodiments, the data reference value may be a hash value generated by hashing one or more data values. For example, the block reference value may be the root of a Merkle tree generated using one or more data values.

The use of block reference values and data reference values within each block header can give the blockchain immutability. Attempting to change a data value requires the generation of a new data reference value for that block, which in turn requires the generation of a new block reference value for subsequent blocks, and further requires the generation of a new block reference value for each subsequent block. For the change to be permanent, the above steps must be performed and updated for each blockchain node 110 within the blockchain network 108 before the generation of a new block and its addition to the blockchain. Due to the limitations of computing and communication capabilities, such changes can be extremely difficult or even impossible, and therefore the blockchain acquires immutability.

In some embodiments, a blockchain can be used to store information about blockchain transactions conducted between two different blockchain wallets. A blockchain wallet may contain the private key of a cryptographic key pair, which is used to generate a digital signature, which may serve as an endorsement by the payer for a blockchain transaction, and which can be verified by the blockchain network 108 using the public key of the cryptographic key pair. In some cases, the term “blockchain wallet” may specifically refer to the private key. In other cases, the term “blockchain wallet” may refer to a computing device (e.g., seller device 104, buyer device 106, etc.) that stores the private key for use in blockchain transactions. For example, each computing device may have its own private key for its respective cryptographic key pair, and each may be a blockchain wallet for use in transactions with a blockchain associated with the blockchain network. The computing device can be any type of device suitable for storing and utilizing blockchain wallets, such as a desktop computer, laptop computer, notebook computer, tablet computer, mobile phone, smartphone, smartwatch, smart TV, wearable computing device, embedded computing device, etc.

Each blockchain data value stored within the blockchain may correspond to a blockchain transaction or, where applicable, the storage of other data. A blockchain transaction may comprise at least: a digital signature of the currency sender (e.g., buyer device 106) generated using the sender's private key; a blockchain address of the currency recipient (e.g., seller device 104) generated using the recipient's public key; and the amount of blockchain currency to be transferred or other data to be stored. In some blockchain transactions, the transaction may also include: one or more sender blockchain addresses where the blockchain currency is currently stored (e.g., where access to such currency is verified by a digital signature); and an address generated using the sender's public key for any changes to be held by the sender. The address to which cryptocurrency usable in a future transaction has been sent is referred to as an "output" address because each address has been previously used to capture the output of a preceding blockchain transaction, and is also referred to as an "unspent transaction" because there is currency to be sent to the address in a preceding transaction in which that currency is still unspent. In some cases, a blockchain transaction may also include a sender's public key for the entity to use to verify the transaction. For the traditional processing of blockchain transactions, such data may be provided to a blockchain node 110 within the blockchain network 108 by either the sender or the recipient. The node can verify the digital signature using the public key in the sender's wallet's cryptographic key pair and can also verify access to the sender's funds (for example, if an unspent transaction has not yet been consumed and has been sent to an address associated with the sender's wallet). This is known as the transaction "confirmation" process, and the blockchain transaction is then included in a new block. In a traditional blockchain implementation, a new block may be verified by other nodes within the blockchain network 108 before being added to the blockchain and distributed to all blockchain nodes 110 within the blockchain network 108. If the blockchain data value is not related to a blockchain transaction but instead to the storage of other types of data, the blockchain data value may still include or otherwise involve verification of the digital signature.

In system 100, records of NFT ownership can be stored within blockchain data entries in the blockchain associated with the blockchain network 108. The data value representing the NFT is stored in a blockchain data entry, and ownership transfers are recorded within the blockchain. This is done by adding a new blockchain data entry containing the NFT's data value and the recipient's blockchain wallet address to a new block. The recipient can then transfer ownership of the NFT further by proving their ownership, which can be done by generating a digital signature of their blockchain wallet's cryptographic key pair. The corresponding public key is used to generate the NFT's recipient address.

In System 100, a buyer device 106 can agree to purchase an NFT owned by a seller device 104 for a predetermined amount of currency. In some embodiments, the buyer device 106 can purchase the NFT using a traditional payment transaction processed by a payment network 112, etc., using a credit card, debit card, or other suitable type of payment method. In other embodiments, the buyer device 106 can purchase the NFT using digital currency transferred via a blockchain, which can be the same blockchain used to record the transfer of ownership of the NFT, or a separate blockchain that may be managed by the blockchain network 108 or an additional blockchain network 108 within System 100.

When traditional payment transactions are used, the buyer device 106 can submit the payment using any appropriate method. For example, the processing server 102 can provide services that allow the buyer device 106 to submit payment details (e.g., transaction amount provided by the seller device 104, account details for the paying transaction account, account details for the recipient transaction account, etc.) or allow the buyer device 106 to use an appropriate website or application program, etc. An approval request for a payment transaction can be electronically transmitted to the payment network 112 using the settlement rail associated with it. The approval request may be a specially formatted transaction message formatted in accordance with one or more standards governing the exchange of financial transaction messages, such as the International Organization for Standardization's ISO 8583 or ISO 20022 standards. The approval request may include payment details for the payment transaction stored in its data elements, such as the transaction amount, account details for the paying transaction account, and account details for the receiving transaction account, etc. The payment network 112 can process payment transactions using traditional systems and methods.

As part of the processing of a payment transaction, a transaction identifier may be generated (for example, by the payment network 112, the processing server 102, or other entities or systems involved in processing the payment transaction). The transaction identifier may be provided to the buyer's device 106 in a confirmation message confirming the successful processing of the payment transaction. If the processing server 102 is involved in processing the payment transaction, it may receive the transaction identifier as part of its involvement in processing the payment transaction. In some such cases, the processing server 102 may provide the confirmation message to the buyer's device 106 using an appropriate communication network and method. In other cases, the buyer's device 106 and/or the seller's device 104 may provide the transaction identifier to the processing server 102 after receiving the confirmation message.

In embodiments where digital currency is used for payment in connection with the purchase of NFTs, the buyer device 106 can electronically submit transaction details relating to the blockchain transaction. These details can be submitted directly to the blockchain node 110, submitted to the processing server 102 for transfer to the blockchain node 110 on behalf of the buyer device 106, or submitted to the processing server 102 for processing if the processing server 102 is a blockchain node 110 within the blockchain network 108. Using the methods described above, a new blockchain transaction can be processed and added to the blockchain for a transfer of a specified amount of digital currency from the buyer device 106's blockchain wallet to the seller device 104's blockchain wallet.

In some embodiments, the seller device 104 can initiate processing of a traditional payment transaction or a blockchain payment transaction using the transaction details provided by the buyer device 106.

The seller device 104 can submit a request to the blockchain network 108 regarding the transfer of ownership of the purchased NFT, which can be submitted directly to the blockchain node 110, submitted to the processing server 102 for forwarding to the blockchain node 110 on behalf of the seller device 104, or submitted to the processing server 102 for processing if the processing server 102 is a blockchain node 110 within the blockchain network 108. The request may include a digital signature generated by the private key of the cryptographic key pair, including the seller device's blockchain wallet, which may correspond to the public key used to generate the address that actually owns the NFT, as registered on the blockchain. Verification of the seller device's ownership of the NFT can be performed through verification of the digital signature, which can be done using the same public key used to generate the address that actually owns the NFT. The request may also include the destination address to which ownership of the NFT will be transferred, which can be generated via the public key of a cryptographic key pair, including the blockchain wallet of the buyer's device, and which may be sent by the buyer's device 106 to the seller's device 104 before the ownership transfer. The blockchain node 110 can validate the necessary data and generate a new blockchain data item, including the ownership transfer, which is included in a new block that is generated and validated using traditional methods and systems and added to the blockchain. A transaction identifier can be generated for the blockchain transaction, which is returned to the buyer's device 106 in a confirmation message or identified by the buyer's device 106 within a blockchain data item for the blockchain transaction stored in the blockchain.

In some embodiments, the payment transaction may be processed before the NFT ownership transfer on the blockchain. In other embodiments, the NFT ownership transfer may occur before the payment transaction is processed. In yet another embodiment, the payment transaction and the NFT ownership transfer may occur simultaneously.

System 100 can generate smart contracts and store them in a blockchain associated with the blockchain network 108, which can be used to facilitate the automatic rewinding of the NFT ownership transfer from the buyer device 106 to the seller device 104. In some embodiments, as described above, smart contracts can be generated after processing the payment transaction and/or after the NFT ownership transfer. In other embodiments, smart contracts can be generated after processing the payment transaction and before the NFT ownership transfer. In such embodiments, the smart contract can be configured to execute a function that processes the NFT ownership transfer once the payment transaction is processed. In such embodiments, the smart contract can execute a function using the transaction identifier for the processed payment transaction as input, and as described above, the execution of the smart contract can result in the generation of a blockchain transaction for the NFT ownership transfer from the seller device 104 to the buyer device 106.

A smart contract may be configured to store at least the token identifier for the NFT, the blockchain address associated with the seller device 104 that initially owned the NFT, and the blockchain address associated with the buyer device 106 to which ownership of the NFT was transferred. The token identifier may be a data value (e.g., a hash of an image, video, etc.) that is the value associated with the NFT or the digital asset itself. When a smart contract is executed to process an ownership transfer, it may store the received transaction identifier as input. If the smart contract is generated after the NFT ownership transfer, the transaction identifier may be included within the smart contract as part of its own generation process.

In System 100, the seller's device 104 or the buyer's device 106 may wish to have a rollback of the payment transaction and the transfer of ownership of the NFT. For example, the buyer may have made an incorrect payment, and if the proper payment is not made, the seller may wish to have the transaction rolled back. Another example is that the NFT transferred to the buyer may be a different asset than the one initially discussed between the parties. Yet another example is that the seller may offer the buyer a return policy, and the buyer may wish to exercise this policy, utilizing System 100 to provide a faster, safer, and simpler return process.

If a rewind is desired, the seller's device 104 or the buyer's device 106 can electronically submit a refund request to the processing server 102 using an appropriate communication network and method, such as a web page, application program, or application programming interface (API). In some cases, the processing server 102 may request confirmation from both the buyer's device 106 and the seller's device 104 before processing the refund request. In such cases, the seller's device 104 and/or the buyer's device 106 can be authenticated before processing, for example, using a digital signature generated by the device's private key and verified using the corresponding public key.

A refund request may include a transaction identifier for the payment transaction to be refunded. The processing server 102 can use the transaction identifier to identify the payment transaction. The processing server 102 can then initiate processing of the refund transaction for the payment transaction. In some cases, when the processing server 102 receives a refund request, dispute resolution processing may occur. For example, the processing server 102 may perform dispute resolution processing directly or through a third-party service (e.g., provided by the payment network 112) to determine whether the refund should be approved, for example, by collecting evidence from the seller device 104 and the buyer device 106 based on the requested refund grounds. For example, the seller device 104 may request a refund claiming that an insufficient payment was made and may present as evidence past communications from the buyer device 106 agreeing on a different price. Similarly, if the NFT is defective (e.g., damaged, incorrect, or misleading), the buyer may present evidence of such defect. If the dispute resolution process determines that a refund request should be denied, a notification message indicating this can be sent to the person who submitted the refund request. If the dispute resolution process approves the refund, the processing server 102 can proceed by refunding the original payment transaction. If a traditional payment transaction was used, a transaction message containing the transaction identifier can be submitted to the payment network 112 using its associated settlement rail, which may result in a refund of the original transaction amount from the original recipient transaction account to the original paying transaction account. In some cases, the refund transaction can be processed through an approval request for a new payment transaction for the same transaction amount, where the payment details for the transaction accounts are swapped, and the original payment from the buyer to the seller is returned from the seller to the buyer.

When blockchain transactions are used, a new blockchain transaction can be generated, which is submitted to the blockchain node 110 for payment, returning the original digital currency amount from the seller device 104's blockchain wallet to the buyer device 106's blockchain wallet. In some embodiments, the seller device 104 can generate a digital signature for the unused transaction output of the original blockchain transaction provided to the processing server 102 or provided in a smart contract. The digital signature is used in relation to the submission of the new blockchain transaction to ensure that the blockchain transaction is successfully verified and processed. If the digital signature is included in the smart contract, the refund of the blockchain transaction can be performed by executing an appropriate function within the smart contract using the transaction identifier as input. The smart contract can generate the blockchain transaction and submit the transaction to the blockchain node 110.

In addition to processing refunds, the processing server 102 can submit a transaction identifier as input to the smart contract. In some cases, the smart contract can be configured to initiate a rollback of the NFT ownership transfer once the transaction identifier is submitted, and this can only occur after other functions related to the receipt of the transaction identifier as input have been executed (e.g., the initial ownership transfer of the NFT). In other cases, the smart contract can include a function for rolling back the NFT ownership transfer (e.g., a refund() function), and the transaction identifier can be provided as input to this function. The smart contract can execute the function to identify the token identifier associated with the NFT and can also generate a new blockchain transaction for the ownership transfer back from the buyer device 106 to the seller device 104. If a digital signature is required for the transfer, the buyer device 106 can supply a digital signature generated using its own private key as part of the initial processing (e.g., when submitting a payment transaction, when submitting a transaction identifier for a payment transaction, when provided to the seller device 104 and submitted thereafter, etc.). The new blockchain transaction is then automatically submitted to blockchain node 110 for verification and addition to the blockchain. Once added to the blockchain, the seller device 104 will regain ownership of the NFT.

In some embodiments, the blockchain network 108 may be configured to allow multiple entities to initiate the transfer of ownership of an NFT. For example, an entity that owns an NFT through control over the address to which the NFT was transferred (e.g., indicated by a digital signature generated using a private key corresponding to the public key used to generate the address) may also designate another entity using a blockchain address (e.g., authenticated in a similar manner using a cryptographic key) or other data used for authentication. In such a case, a processing server 102 may be designated as the other entity permitted to transfer ownership of the NFT. The processing server 102 may include its own digital signature or other authentication data, which can be supplied along with a transaction identifier as input to a smart contract, thereby achieving the unwinding of the NFT ownership transfer.

The methods and systems discussed herein enable the automatic reversal of NFT ownership transfers. By using a processing server, smart contracts, and appropriate inputs, payment transactions using either traditional or digital currencies can be automatically refunded, and the NFT ownership can be automatically reversed back to its original owner with only a single submission of the transaction identifier by the seller's device 104 or the buyer's device 106. This results in rapid and secure processing of refunds and reversals, requiring minimal interaction for the parties involved and eliminating any possibility of fraud. Consequently, entities gain unprecedented flexibility when conducting transactions involving NFT ownership transfers.

Processing Server Figure 2 shows an embodiment of the processing server 102. It will be obvious to those skilled in the art that the embodiment of the processing server 102 shown in Figure 2 is provided for illustrative purposes only and does not thoroughly represent all possible configurations of the processing server 102 suitable for performing the functions of the disclosure. For example, the computer system 600 shown in Figure 6 and described in more detail below may be a suitable configuration of the processing server 102. In some cases, additional components of the system 100, such as the seller unit 104, the buyer unit 106, and the blockchain node 110, may include components shown in Figure 2 and described later.

The processing server 102 may include a receiving device 202. The receiving device 202 may be configured to receive data over one or more networks via one or more network protocols. In some examples, the receiving device 202 may be configured to receive data from the seller device 104, the buyer device 106, the blockchain node 110, the payment network 112, and other systems and entities via one or more communication methods such as radio frequency, local area network, wireless area network, cellular communication network, Bluetooth, and the internet. In some embodiments, the receiving device 202 may include multiple devices (for example, different receiving devices that receive data over different networks (e.g., a first receiving device that receives data over a local area network and a second receiving device that receives data over the internet)). The receiving device 202 may receive transmitted electronic data signals. Upon reception of the data signal by the receiving device 202, the data may be superimposed on the data signal and decoded, parsed, read, or acquired. In some embodiments, the receiving device 202 may include an analysis module for analyzing the received data signal and acquiring the superimposed data thereon. For example, the receiving device 202 may include an analysis program configured to receive the received data signal and convert it into available inputs for a function to be performed by the processing unit, thereby executing the method and system of this disclosure.

The receiving device 202 may be configured to receive data signals electronically transmitted by the seller device 104 and/or the buyer device 106, where the data signals may be superimposed or encoded with payment transaction data, transaction identifiers, token identifiers, smart contract data, refund requests, etc. The receiving device 202 may also be configured to receive data signals electronically transmitted by the blockchain node 110 within the blockchain network 108, where the data signals may be superimposed or encoded with blockchain data, transaction identifiers, notification messages, etc. The receiving device 202 may be further configured to receive data signals electronically transmitted by the payment network 112 (e.g., via the associated settlement rail), where the data signals may be superimposed or encoded with transaction messages, notification messages, etc.

The processing server 102 may also include a communication module 204. The communication module 204 may be configured to transfer data between modules, engines, databases, memory, and other components of the processing server 102 for use when performing the functions of the disclosure. The communication module 204 may include one or more communication types and may use various communication methods for communication within the computing device. For example, the communication module 204 may include buses, connection pin connectors, wires, etc. In some embodiments, the communication module 204 may also be configured to communicate between internal components of the processing server 102 and external components of the processing server 102 (e.g., externally connected databases, display devices, input devices, etc.). The processing server 102 may also include a processing unit. The processing unit may be configured to perform the functions of the processing server 102 of the disclosure. This will be obvious to those skilled in the art. In some embodiments, the processing unit may include a plurality of engines and/or modules (e.g., query module 216, generation module 218, verification module 220, etc.) specifically configured to perform one or more functions of the processing unit. As in this disclosure, the term “module” may refer to software or hardware specifically programmed to receive an input, use that input to perform one or more processes, and provide an output. The inputs, outputs, and processes performed by various modules are obvious to those skilled in the art based on this disclosure.

The processing server 102 may include blockchain data 206, which may be stored in the processing server 102's memory 214 or in a separate area within the processing server 102, or thereby made accessible. The blockchain data 206 may include a blockchain, which may comprise multiple blocks and may be associated with the blockchain network 108. In some cases, the blockchain data 206 may further include any other data associated with the blockchain and its management and performance, such as block generation algorithms, digital signature generation and confirmation algorithms, communication data about blockchain nodes 110, smart contracts, cryptographic key pairs, public keys, etc.

The processing server 102 may also include memory 214. Memory 214 may be configured to store data (e.g., public keys, private keys, symmetric keys, etc.) for use by the processing server 102 when performing the functions of the Disclosure. Memory 214 may be configured to store data using appropriate data formatting methods and schemas, and may be any appropriate type of memory (e.g., read-only memory, random access memory, etc.). Memory 214 may include, for example, cryptographic keys and algorithms, communication protocols and standards, data formatting standards and protocols, module program code and application programs for the processing unit, and other appropriate data used by the processing server 102 when performing the functions of the Disclosure. This will be obvious to those skilled in the art who read this Disclosure. In some embodiments, memory 214 may include a relational database using Structured Query Language (SQL) and may store, identify, modify, update, access, etc., stored structured datasets. Memory 214 may be configured to store, for example, encryption keys, encryption key pairs, encryption algorithms, encryption keys, data formatting rules, signature generation algorithms, standards, public databases, private databases, payment network processing rules, transaction message standard data, etc.

The processing server 102 may also include a query module 216. The query module 216 may be configured to execute queries on a database to identify information. The query module 216 may receive one or more data values or query columns and, based on these, execute the query columns on the indicated database (e.g., the memory 214 of the processing server 102) to identify the information stored therein. The query module 216 may then output the identified information to the appropriate engine or module of the processing server 102, as needed. For example, the query module 216 can execute queries on memory 214 to identify a private key for use in generating a digital signature, for submission to a smart contract as input for reversing the transfer of NFT ownership.

The processing server 102 may also include a generation module 218. The generation module 218 may be configured to generate data used by the processing server 102 when performing the functions of this disclosure. The generation module 218 may receive instructions as input values, generate data based on instructions, and output the generated data to one or more modules of the processing server 102. For example, the generation module 218 may be configured to generate transaction messages, blockchain transactions, blockchain data items, digital signatures, blocks, response messages, notification messages, etc.

The processing server 102 may also include a verification module 220. The verification module 220 may be configured to perform verification for the processing server 102 as part of the functions described in this disclosure. The verification module 220 may receive instructions as input, which may also include data used for verification; it may perform verification as requested; and it may output the verification results to another module or engine of the processing server 102. The verification module 220 may be configured, for example, to verify digital signatures using appropriate signature generation algorithms and keys; to verify hash values by hashing provided data using appropriate one-way hashing algorithms; to verify NFT ownership based on blockchain address and cryptographic key data; or to verify payment transactions.

The processing server 102 may also include a transmitting device 222. The transmitting device 222 may be configured to transmit data over one or more networks via one or more network protocols. In some examples, the transmitting device 222 may be configured to transmit data to the seller device 104, the buyer device 106, the blockchain node 110, the payment network 112, and other entities via one or more communication methods such as a local area network, a wireless area network, cellular communication, Bluetooth, radio frequency, or the internet. In some embodiments, the transmitting device 222 may include multiple devices (e.g., different transmitting devices for transmitting data over different networks, e.g., a first transmitting device for transmitting data over a local area network and a second transmitting device for transmitting data over the internet). The transmitting device 222 may electronically transmit a data signal having superimposed data that is parsed by a receiving computing device. In some embodiments, the transmitting device 222 may include one or more modules for superimposing, encoding, or shaping data into a data signal suitable for transmission.

The transmitting device 222 may be configured to electronically transmit data signals to the seller device 104 and/or the buyer device 106, and the data signals may be superimposed or encoded with notification messages about payment transactions, requests for digital signatures, notification messages about blockchain transactions, requests for smart contract data, etc. The transmitting device 222 may also be configured to electronically transmit data signals to the blockchain node 110, and the data signals may be superimposed or encoded with blockchain transactions, blockchain data items, blocks, response messages, smart contract data, inputs about smart contracts, etc. The transmitting device 222 may further be configured to electronically transmit data signals to the payment network 112 (e.g., via the associated settlement rail), and the data signals may be superimposed or encoded with transaction messages, acknowledgment requests, refund messages, etc.

Processing for Transfer of Ownership of Nonfungible Tokens Figures 3A and 3B illustrate the process of transferring ownership of nonfungible tokens (NFTs) from seller device 104 to buyer device 106 within system 100 when exchanging payments via traditional payment transactions that allow for automatic redemption and rewinding.

In S302, the buyer device 106 can electronically send a message to the seller device 104, using an appropriate communication network and method, proposing the purchase of an NFT owned by the seller device 104. In S304, the seller device 104 can receive the message, which may include transaction conditions such as the transaction amount, currency type, and token identifier for the NFT to be purchased. In some cases, the conditions may also include a blockchain address for the buyer device 106 for receiving the NFT. The conditions may be presented to a user of the seller device 104, who can decide whether to proceed with the transaction and can provide input confirming the transaction. In S306, the seller device 104 can send its confirmation of the proposed transaction to the buyer device 106 using an appropriate communication network and method. The confirmation may include at least account details for the transaction account to which the payment is to be made, such as an account number, username, email address, telephone number, or other data that may depend on the service and/or payment method used for the payment transaction. In S308, the buyer device 106 can receive the confirmation message and the included account details.

In S310, the buyer device 106 can electronically transmit a message about the desired payment transaction to the processing server 102 using an appropriate communication network and method. The message may include at least account details for the seller's transaction account, account details for the buyer's transaction account used to fund the payment transaction, and the transaction amount. In some cases, the message may also include a token identifier for the NFT. In S312, the receiving device 202 of the processing server 102 can receive the message about the payment transaction. In S314, the processing server 102 can process the payment transaction using an appropriate method. In some cases, the processing server 102 can generate an approval request for the payment transaction (e.g., via the generation module 218), and the approval request is submitted to the payment network 112 using the associated settlement rail. In other cases, the processing server 102 can submit the payment details and transaction account for the transaction account to another payment service to facilitate the transfer of funds and complete the payment transaction. As part of processing the payment transaction, in S314, the processing server 102 can identify a transaction identifier for the payment transaction, and this transaction identifier can be a value (e.g., a number) unique to the payment transaction.

In S316, the transmitting device 222 of the processing server 102 can electronically send a confirmation message about the successful payment transaction to the buyer's device 106. The confirmation message may include at least a transaction identifier and may also include optional additional transaction details, such as the transaction amount and some account details regarding the seller's transaction account. In S318, the buyer's device 106 can receive the confirmation message. In S320, the buyer's device 106 forwards the confirmation message to the seller's device 104, which can then receive it in S322. The confirmation message is presented to the user of the seller's device 104 to notify the seller that the payment for the proposed amount has been successfully transferred to the seller's transaction account. If the buyer's device 106 has not previously provided the seller's device 104 with a destination address for the NFT, the buyer's device 106 can append the destination address to the confirmation message.

In S324, the seller device 104 can electronically transmit data about the smart contract to the blockchain node 110 in the blockchain network 108 using an appropriate communication network and method. The data may include at least a transaction identifier for the processed payment transaction, a token identifier associated with the NFT, the blockchain address of the seller who owns the NFT (and, for example, a digital signature generated by the seller's private key, if applicable), and the destination address for the NFT generated by the buyer device 106. In S326, the blockchain node 110 can receive the smart contract data. In S328, the blockchain node 110 can verify the seller's ability to transfer ownership of the specified NFT, generate a smart contract using the provided data, generate a new block containing the smart contract, and have the new block confirmed and added (i.e., posted to the blockchain). In S330, the blockchain node 110 can send a notification message to the seller device 104 indicating that the smart contract has been successfully added to the blockchain.

In S332, the seller device 104 can receive a notification message from the blockchain node 110. In S334, the seller device 104 can forward the notification message to the buyer device 106 and the processing server 102 to inform the parties that the transfer of NFT ownership was successful. In S336, the buyer device 106 can receive the notification message, which can be displayed to its user, informing the user that it has acquired ownership of the NFT. In S338, the receiving device 202 of the processing server 102 can receive the notification message from the seller device 104. In S340, the processing server 102 can identify that the smart contract is stored in the blockchain, which can be done, for example, by using a transaction identifier. In S342, the verification module 220 of the processing server 102 can verify the data contained in the smart contract, ensuring its accuracy by checking that the token identifier corresponds to the one submitted with the payment transaction data, and by checking the accuracy of the transaction identifier.

As a result of the processes shown in Figures 3A and 3B, the negotiated amount of fiat currency is transferred from the buyer to the seller, and the agreed-upon NFT is transferred from the seller to the buyer. The corresponding data is registered within a smart contract stored on the blockchain and can be used to facilitate the reversal of NFT ownership transfers if desired, as detailed below in conjunction with the processes shown in Figure 4.

Processing for refunds and rollbacks of ownership transfers of non-fungible tokens Figure 4 shows the processing in system 100 for automatic refunds of traditional payment transactions and rollbacks of NFT ownership transfers, such as when a transfer is made using the processing shown in Figures 3A and 3B described above.

In S402, the buyer device 106 (or, for example, the seller device 104, if desired) can electronically transmit requests to the processing server regarding refunds for payment transactions and rollbacks for the transfer of ownership of NFTs, using appropriate communication networks and methods. A refund request may include at least a transaction identifier associated with a payment transaction for transferring a specified amount of fiat currency from the buyer to the seller. In S404, the receiving device 202 of the processing server 102 can receive the refund request. In S406, the processing server 102 can begin processing the refund of the payment transaction. If the processing server 102 directly initiated the payment transaction, it can generate an appropriate transaction message (for example, via the generation module 218), which is submitted to the payment network 112 using the associated settlement rail and includes a transaction identifier. In other cases, the processing server 102 can submit the transaction identifier to the payment service to facilitate a transfer back from the seller's transaction account to the buyer's transaction account using appropriate methods. In some embodiments, the processing server 102 can perform dispute resolution processing to determine whether the refund should be approved, and S406 is initiated only after the refund request has been approved as a result of the dispute resolution processing.

In S408, the transmitting device 222 of the processing server 102 can submit a transaction identifier as input to a smart contract associated with the transfer of ownership of the NFT, which can be identified using a transaction identifier stored in the blockchain associated with the blockchain network 108. In S410, the blockchain node 110 in the blockchain network 108 can receive the transaction identifier, which can be submitted in S412 as input to the smart contract for execution. Alternatively, in S412, the smart contract can initiate the dispute resolution process described above, wait for the result, and then post a rollback transaction. Execution of the smart contract may include the generation of a new blockchain transaction for the transfer of ownership of the NFT, which is identified via a transaction identifier submitted to the blockchain node 110 and a token identifier stored in the smart contract associated with it. In S414, the blockchain node 110 can generate a new block containing the new blockchain transaction and have the new block confirmed and added to the blockchain. In S416, the blockchain node 110 can send a notification message to the processing server 102, indicating that a new transfer of ownership back to the seller device 104 has been successfully added to the blockchain.

In S418, the receiving device 202 of the processing server 102 can receive a notification message from the blockchain node 110. In S420, the generating module 218 of the processing server 102 can generate a new notification message indicating that the payment transaction has been refunded and ownership of the NFT has been transferred back to the seller device 104. This message can be transmitted to the buyer device 106 by the transmitting device 222 of the processing server 102. In S422, the buyer device 106 can receive the notification message, which can be presented to its user and/or forwarded to the seller device 104, thus informing the seller of the refund and rollback.

As a result of the processing shown in Figure 4 and described above, fiat currency payment transactions are automatically refunded to the buyer, and the transfer of ownership of NFTs is automatically reversed to the seller. This is done in a manner that ensures the elimination of any possibility of fraud, and can be initiated via a single message submitted by the buyer device 106 or the seller device 104, and is achieved through the use of the processing server 102 and a specially configured smart contract.

Exemplary Method for Enabling Refunds for Non-Fungible Tokens Figure 5 illustrates a method 500 for automatically refunding NFTs and rolling back ownership, and for refunding corresponding payment transactions, through the use of a processing server and a smart contract.

In S502, a transaction message for the payment transaction can be received by a receiver (e.g., receiving device 202) of the processing server (e.g., processing server 102). In S504, the processing server's processor can process the payment transaction using at least the transaction message, and this processing includes identifying a transaction identifier for the payment transaction. In S506, the transaction identifier can be transmitted by the processing server's transmitter (e.g., transmitting device 222) to the first computing device (e.g., seller device 104, buyer device 106, blockchain node 110, etc.).

In S508, a notification message can be received by the processing server's receiver, and the notification message includes at least a transaction identifier and a token identifier, the token identifier being associated with the NFT. In S510, a refund request message from a second computing device (e.g., seller device 104, buyer device 106, etc.) can be received by the processing server's receiver, and this refund request message includes at least one of a transaction identifier and a token identifier. In S512, a refund transaction for a payment transaction can be processed by the processing server's processor. In S514, at least the transaction identifier can be submitted by the processing server's transmitter as input to a smart contract stored in the blockchain associated with the NFT.

In one embodiment, a transaction message may be an approval request formatted according to one or more standards, and a payment transaction may relate to a payment using fiat currency from a first transaction account to a second transaction account. In some embodiments, a transaction message may be a data message about a blockchain transaction, and a payment transaction may be processed using one or more blockchain nodes (e.g., blockchain node 110) within a blockchain network (e.g., blockchain network 108). In a further embodiment, a blockchain transaction may be added to a second blockchain distinct from the blockchain associated with the NFT.

In one embodiment, a smart contract can be executed using a transaction identifier as input to reverse a prior transfer of ownership of an NFT on the blockchain associated with the NFT. In some embodiments, a smart contract may include at least a transaction identifier, a token identifier, a buyer address, and a seller address. In one embodiment, method 500 may further include the following steps: a processing server processor (e.g., verification module 220) verifies the transfer of ownership of the NFT after receiving a notification message, wherein the verification of the transfer of ownership of the NFT includes identifying a block in the blockchain associated with the NFT that includes a blockchain data item containing at least a token identifier and a transaction identifier. In some embodiments, the transaction identifier may be submitted to the smart contract as input in a function call included in the smart contract.

Computer System Architecture Figure 6 shows a computer system 600, in which embodiments or parts thereof of the present disclosure may be implemented as computer-readable code. For example, the processing server 102 in Figures 1 and 2 may be implemented in the computer system 600 using hardware, a non-temporary computer-readable medium having stored instructions, or a combination thereof, and may be implemented in one or more computer systems or other processing systems. The hardware can embody modules and components used to implement the methods in Figures 3A, 3B, 4, and 5.

When programmable logic is used, such logic runs on a commercially available processing platform consisting of executable software code and may be an application-specific or special-purpose device (e.g., a programmable logic array (PGA), an application-specific integrated circuit (ASIC), etc.). Those skilled in the art will understand that embodiments of the disclosed subject matter are executable in a variety of computer system configurations. Such configurations include multi-core multiprocessor systems, minicomputers, mainframe computers, computers linked or clustered with distributed functions, and general-purpose or miniature computers that can be implemented in substantially almost any device. For example, at least one processor device and memory may be used to implement the above embodiments.

The processor unit or device of this disclosure may be a single processor, multiple processors, or a combination thereof. The processor device may have one or more processor "cores." The terms “computer program medium,” “non-temporary computer-readable medium,” and “computer-usable medium” in this disclosure are generally used to refer to tangible media (e.g., hard disks installed in removable storage unit 618, removable storage unit 622, and hard disk drive 612).

Various embodiments of this disclosure are described in relation to this exemplary computer system 600. After reading this disclosure, it will be obvious to those skilled in the art how to implement this disclosure using other computer systems and/or computer architectures. While the operations are disclosed as sequential processing, some operations may actually be executed in parallel, simultaneously, and/or in a distributed environment. In this case, the program code is stored locally or remotely for access by single-processor or multi-processor machines. Furthermore, in some embodiments, the order of operations can be rearranged without departing from the spirit of the disclosure.

The processor device 604 may be a purpose-specific or general-purpose processor device specifically configured to perform the functions of the Disclosure. The processor device 604 may be connected to a communication infrastructure 606 (e.g., a bus, message queue, network, multicore message path scheme, etc.). The network may be any network suitable for performing the functions of the Disclosure and may include a local area network (LAN), wide area network (WAN), wireless network (e.g., Wi-Fi), mobile communication network, satellite network, internet, optical fiber, coaxial cable, infrared, radio frequency (RF), or any combination thereof. Other suitable network types and configurations will be obvious to those skilled in the art. The computer system 600 may also include main memory 608 (e.g., random access memory, read-only memory, etc.) and auxiliary memory 610. The auxiliary memory 610 may include a hard disk drive 612 and a removable storage drive 614 (e.g., a floppy disk drive, magnetic tape drive, optical disk drive, flash memory, etc.).

The removable storage drive 614 may read from and/or write to the removable storage unit 618 in a well-known manner. The removable storage unit 618 may include a removable storage medium that can be read from and written to by the removable storage drive 614. For example, if the removable storage drive 614 is a floppy disk drive or a USB port, the removable storage unit 618 may be a floppy disk or a portable flash drive, respectively. In one embodiment, the removable storage unit 618 may be a non-temporary readable recording medium.

In some embodiments, the auxiliary memory 610 may include alternative means to enable the loading of computer programs or other instructions into the computer system 600 (e.g., a removable storage unit 622 and interface 620). Examples of such means may include program cartridges and cartridge interfaces (as found in, for example, video game systems), removable memory chips (e.g., EEPROM, PROM, etc.), associated sockets, and other removable storage units 622 and interface 620. This will be obvious to those skilled in the art.

Data stored in the computer system 600 (for example, in main memory 608 and/or auxiliary memory 610) may be stored on any type of suitable computer-readable medium (e.g., optical storage (compact discs, digital multipurpose discs, Blu-ray discs, etc.) or magnetic tape storage (e.g., hard disk drives)). The data may be configured in any type of suitable database configuration (e.g., relational databases, structured query language (SQL) databases, distributed databases, object databases, etc.). Suitable configurations and storage types are obvious to those skilled in the art.

The computer system 600 may also include a communication interface 624. The communication interface 624 may enable software and data to be transmitted and received between the computer system 600 and external devices. An exemplary communication interface 624 may include a modem, a network interface (e.g., an Ethernet card), a communication port, a PCMCIA slot and card, etc. The software and data transmitted via the communication interface 624 may be in signal form. Such signal form may be electronic, electromagnetic, optical, or other signals obvious to those skilled in the art. The signals propagate through a communication path 626. This path is configured to carry signals and may be implemented using wires, cables, optical fibers, telephone lines, mobile phone links, radio frequency links, etc.

The computer system 600 may further include a display interface 602. The display interface 602 may be configured to allow data to be transferred between the computer system 600 and an external display 630. An exemplary display interface 602 may include a High-Definition Multimedia Interface (HDMI), a Digital Visual Interface (DVI), a Video Graphics Array (VGA), etc. The display 630 may be any suitable type of display that displays the data transferred via the display interface 602 of the computer system 600, and may include cathode ray tube (CRT) displays, liquid crystal displays (LCDs), light-emitting diode (LED) displays, capacitive touch displays, thin-film transistor (TFT) displays, etc.

The computer program medium and computer-usable medium may refer to memory (e.g., main memory 608 and auxiliary memory 610), and may be semiconductor memory (DRAM, etc.). These computer program products may be means for providing software to the computer system 600. The computer program (e.g., computer control logic) may be stored in the main memory 608 and/or auxiliary memory 610. The computer program may also be received via the communication interface 624. When executed, such a computer program may enable the computer system 600 to perform the methods of this disclosure. In particular, when executed, the computer program may enable the processor unit 604 to perform the methods shown in Figures 3A, 3B, 4, and 5 as described herein. Thus, such a computer program represents a controller of the computer system 600. This disclosure is implemented using software. The software may be stored in the computer program product and loaded into the computer system 600 using a removable storage drive 614, interface 620, and hard disk drive 612 or the communication interface 624.

The processor unit 604 may include one or more modules or engines configured to perform the functions of the computer system 600. Each module or engine may be implemented using hardware, and in some embodiments, it may use software (for example, this corresponds to program code or programs stored in main memory 608 or auxiliary memory 610). In such embodiments, the program code may be compiled by the processor unit 604 (for example, by a compilation module or engine) before execution by the hardware of the computer system 600. For example, the program code may be source code (e.g., assembly language or machine code) written in a programming language that is translated into a low-level language. This is for execution by the processor unit 604 and/or any additional hardware components of the computer system 600. The compilation process may include lexical analysis, preprocessing, syntactic analysis, semantic analysis, syntactic-driven translation, code generation, code optimization, and the use of any other techniques suitable for translating the program code into a low-level language for control of the computer system 600 and performing the functions of the disclosure. It will be obvious to those skilled in the art that such processing results in a specially configured computer system 600 uniquely programmed to perform the above-described functions.

The technology consistent with this disclosure provides a system and method for enabling redemption of non-fungible tokens, although it also has other features. Various exemplary embodiments of the system and method of this disclosure are described above, but it should be understood that they are provided for illustrative purposes only, not limiting purposes. They are not exhaustive, and this disclosure is not limited to the disclosed form itself. Modifications and variations are possible in light of the above teachings. Modifications and variations may be derived from implementations of this disclosure without departing from the scope or scope.

Claims (14)

A method for enabling refunds for non-fungible tokens (NFTs),
The processing server's receiver receives a transaction message regarding the payment transaction for the purchase of the NFT ,
A step of processing the payment transaction using at least the transaction message by the processor of the processing server, wherein the processing includes generating a transaction identifier for the payment transaction;
The process involves transmitting the transaction identifier to the first computing device via the transmitter of the processing server,
The steps include: receiving a notification message by the receiver of the processing server, the transaction identifier and the token identifier being associated with the NFT;
The steps include: receiving a refund request message from a second computing device using the receiver of the processing server, wherein the refund request message includes at least the transaction identifier ;
The processing server's processor processes the refund transaction for the payment transaction,
The process includes the step of the transmitter of the processing server identifying the smart contract using the transaction identifier, thereby submitting at least the transaction identifier as input to the smart contract stored in the blockchain associated with the NFT,
A method for reversing a prior transfer of ownership of the NFT on the blockchain associated with the NFT, by executing the smart contract using the transaction identifier as input and identifying ownership of the NFT using the token identifier stored in the identified smart contract . In the method according to claim 1,
The aforementioned transaction message is an authorization request formatted according to one or more standards.
The payment transaction is a method relating to a payment using fiat currency from a first transaction account to a second transaction account. In the method according to claim 1,
The aforementioned transaction message is a data message about a blockchain transaction.
A method wherein the payment transaction is processed using one or more blockchain nodes within a blockchain network. A method according to claim 3, wherein the blockchain transaction is added to a second blockchain different from the blockchain associated with the NFT. The method according to claim 1, wherein the smart contract comprises at least the transaction identifier, token identifier, buyer address, and seller address. The method according to claim 1, further,
A method comprising the step of verifying the transfer of ownership of the NFT after receiving the notification message by the processor of the processing server, wherein the verification of the transfer of ownership of the NFT includes identifying a block in the blockchain associated with the NFT, which includes a blockchain data item that includes at least the token identifier and the transaction identifier. The method according to claim 1, wherein the transaction identifier is submitted to the smart contract as input to a function call included in the smart contract. A system that enables refunds for non-fungible tokens (NFTs),
The first computing device and
A second computing device,
The blockchain associated with the aforementioned NFT,
A system comprising a processing server, the processing server is
A receiver that receives a transaction message regarding the payment transaction for the purchase of the aforementioned NFT ,
A processor that processes the payment transaction using at least the transaction message, wherein the processing includes generating a transaction identifier for the payment transaction,
The transmitter includes a transmitter that transmits the transaction identifier to the first computing device,
The receiver of the processing server further,
A notification message comprising at least the transaction identifier and the token identifier, wherein the token identifier is associated with the NFT,
A refund request message from the second computing device, the refund request message includes at least the transaction identifier , and the refund request message is received.
The processor of the processing server further processes a refund transaction for the payment transaction.
The transmitter of the processing server further identifies the smart contract using the transaction identifier, thereby submitting at least the transaction identifier as input to the smart contract stored in the blockchain associated with the NFT.
A system in which the smart contract is executed using the transaction identifier as input, and the ownership of the NFT is identified using the token identifier stored in the identified smart contract, thereby undoing a prior transfer of ownership of the NFT on the blockchain associated with the NFT . In the system described in claim 8 ,
The aforementioned transaction message is an authorization request formatted according to one or more standards.
The aforementioned payment transaction is a system relating to a payment using fiat currency from a first transaction account to a second transaction account. In the system described in claim 8 ,
The aforementioned transaction message is a data message about a blockchain transaction.
The aforementioned payment transaction is processed using one or more blockchain nodes within a blockchain network. The system according to claim 10 , wherein the blockchain transaction is added to a second blockchain different from the blockchain associated with the NFT. The system according to claim 8 , wherein the smart contract includes at least the transaction identifier, token identifier, buyer address, and seller address. In the system described in claim 8 ,
The processor of the processing server further verifies the transfer of ownership of the NFT after receiving the notification message.
A system for verifying the transfer of ownership of the NFT, comprising identifying a block in the blockchain associated with the NFT, which includes a blockchain data item comprising at least the token identifier and the transaction identifier. The system according to claim 8 , wherein the transaction identifier is submitted to the smart contract as input in a function call included in the smart contract.