Method and system for integrating blockchain technology with existing computer architecture
The integration of blockchain technology with traditional payment networks through specially formatted transaction messages allows for the execution of smart contracts, enhancing payment transaction capabilities without altering existing infrastructure.
Patent Information
- Application Number
- JP2024535904
- Authority / Receiving Office
- JP · JP
- Patent Type
- Applications
- Current Assignee / Owner
- Priority Date
- 2021-12-17
- Filing Date
- 2022-12-06
- Publication Date
- 2025-01-23
- Estimated Expiration
- 2042-12-06
AI Technical Summary
Existing payment networks lack integration with blockchain technology, preventing the use of smart contracts for traditional payment transactions without requiring significant system changes.
A system that integrates blockchain technology with traditional payment networks by using specially formatted transaction messages, allowing data to be routed to both traditional authorization processing and blockchain nodes, enabling smart contracts to be executed without altering existing payment processing infrastructure.
Enables the use of blockchain smart contracts within traditional payment transactions, expanding services offered to customers while maintaining security and minimizing disruption to existing systems.
Smart Images

Figure 2025501724000001_ABST
Abstract
Description
[Technical field]
[0001] The present disclosure relates to integrating blockchain technology with existing computer architectures, and in particular to integrating blockchain with traditional payment networks to enable smart contracts to be executed using data from formatted transaction messages.
[0002] CROSS-REFERENCE TO RELATED APPLICATIONS This application claims the benefit of U.S. Patent Application No. 17 / 554,525, filed December 17, 2021, the entire contents of which are incorporated by reference for all purposes. [Background technology]
[0003] A consumer wishing to make a payment transaction can use several payment methods, such as cash, check, debit card, or credit card. In recent years, consumers overwhelmingly prefer to use debit or credit cards because of the benefits they offer over cash or check, such as consumer protection, analytical capabilities, spending control, and loyalty and reward programs. Payment transactions funded with debit or credit cards are typically processed using a payment processor, and data about the transaction itself is included in a transaction message, which consists of specially formatted data messages sent along a payment rail, which is a specialized infrastructure used by the payment processor that is inaccessible by other systems and entities. By using a specialized payment rail and infrastructure, the payment processor can ensure that the data remains both private and secure, and that the transaction is processed with extreme speed, far beyond what can be achieved using the general-purpose Internet.
[0004] Recently, blockchain technology has emerged as an alternative means for making payment transactions, where digital currency that is tracked and transferred using blockchain can be used in place of traditional fiat currency. Blockchain can also have additional functionality beyond the transfer of digital currency, which can be useful for various entities. In some cases, two parties may wish to make a traditional payment transaction with a payment processor, but also wish to leverage blockchain technology for purposes related to the payment transaction. However, there is no system that integrates blockchain technology with traditional payment processing architectures. Thus, there is a need for a technical solution that integrates traditional payment networks and settlement rails with blockchain technology. Summary of the Invention
[0005] The present disclosure provides a description of a system and method for enabling the use of blockchain smart contracts as part of a traditional payment transaction. An integrated or central processor as part of a traditional payment network architecture can receive a transaction message that is specially formatted as part of a traditional payment transaction. The processor can identify data in the transaction message and determine a routing plan for the transaction, which can include leveraging blockchain functionality. The processor can forward the transaction message to an issuing financial institution for traditional approval processing using a first port of the processor and to a blockchain node using a second port of the processor. The blockchain node can perform any necessary actions upon receipt of the transaction message, such as executing a smart contract stored on the blockchain using data from the transaction message. As a result, the two entities involved in a traditional payment transaction can benefit from blockchain functionality while using the existing payment processing architecture without changes for the majority of systems involved in the transaction processing, thus providing a significant technical improvement with minimal disruption to standard processing.
[0006] A method for enabling the use of a blockchain smart contract as part of a traditional payment transaction includes the steps of: receiving, by a receiver of a processing server, a transaction message for the payment transaction, the transaction message being formatted according to one or more standards and including a plurality of data elements that store transaction data, the transaction data including at least a bank identification value; determining, by a processor of the processing server, a routing plan for the transaction message based on at least the bank identification value; and transmitting, by a transmitter of the processing server, based on the determined routing plan, the transaction message to (i) a first computing system using a first communication port of the processing server and (ii) a second computing system using a second communication port of the processing server.
[0007] A system that enables the use of blockchain smart contracts as part of a traditional payment transaction includes: a first computing system, a second computing system, and a processing server, the processing server including a receiver that receives a transaction message for the payment transaction, the transaction message being formatted according to one or more standards and including a plurality of data elements that store transaction data, the transaction data including at least a bank identification value; a processor that determines a routing plan for the transaction message based on at least the bank identification value; and a transmitter that transmits the transaction message (i) to the first computing system using a first communication port of the processing server and (ii) to the second computing system using a second communication port of the processing server based on the determined routing plan. [Brief description of the drawings]
[0008] The scope of the present disclosure is best understood from the following detailed description of illustrative embodiments when taken in conjunction with the accompanying drawing figures, which include:
[0009] [Figure 1] FIG. 1 is a block diagram illustrating a high-level system architecture for enabling the use of blockchain smart contracts in traditional payment transactions, according to an example embodiment. [Diagram 2] FIG. 1 is a block diagram illustrating a computing device for enabling the use of blockchain smart contracts in traditional payment transactions, according to an example embodiment. [Diagram 3] 2 is a flow diagram for enabling the use of blockchain smart contracts in traditional payment transactions in the system of FIG. 1 , according to an example embodiment. [Figure 4] FIG. 1 is a block diagram illustrating an example method for enabling blockchain smart contracts to be used in traditional payment transactions, according to an example embodiment. [Diagram 5] FIG. 1 is a block diagram illustrating a computer system architecture in accordance with an exemplary embodiment.
[0010] Further areas of applicability of the present disclosure will become apparent from the following detailed description. The detailed description of the exemplary embodiments is intended for purposes of illustration only and is not intended to necessarily limit the scope of the present disclosure. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS
[0011] A system for integrating blockchain into payment processing architectures FIG. 1 illustrates a system 100 that integrates blockchain technology with traditional payment processing architecture and infrastructure to enable blockchain features, such as smart contracts, to be used as part of traditional payment transactions.
[0012] Traditionally, payment transactions are processed by a payment network. As discussed herein, a "payment network" may refer to a system or network used to transfer funds through the use of cash alternatives for thousands, millions, or billions of transactions during a given period of time. A payment network may process the transfer of funds for various types of transactions using a variety of different protocols and procedures. Transactions performed through a payment network may include purchases of goods or services, credit purchases, debit transactions, fund transfers, direct debits, and the like. A payment network may be configured to perform transactions through cash alternatives, which may include payment cards, letters of credit, checks, transaction accounts, and the like. Examples of networks or systems configured to perform as a payment network include those operated by Mastercard®, VISA®, Discover®, American Express®, PayPal®, and the like. The term "payment network" in this document may refer to both a payment network as an entity and a physical payment network (e.g., the equipment, hardware, and software that make up a payment network).
[0013] As discussed herein, a "payment transaction" may refer to a transaction between two entities in which funds or other monetary benefits are exchanged from one entity to another. As will be appreciated by those skilled in the art, a payment transaction may be a transfer of funds for the purchase of goods or services, the repayment of a debt, or any other transaction for monetary benefits. In some embodiments, a payment transaction may refer to a transaction funded via a payment card and / or payment account, such as a credit card transaction. Such payment transactions may be processed through an issuer, a payment network, and an acquirer. The processes for processing such payment transactions may include at least one of the following: authorization, batching, clearing, settlement, and funding. Authorization may include: a consumer providing payment details to a merchant, submitting transaction details (e.g., including payment details) from the merchant to an acquirer, and verifying the payment details with the issuer of the consumer's payment account used to fund the transaction. Batching may refer to storing an authorized transaction with other authorized transactions for forwarding to an acquirer. Clearing may include sending batched transactions from the acquirer to a payment network for processing. Settlement may include debiting the issuer by the payment network for transactions involving beneficiaries of the issuer. In some embodiments, the issuer may make a payment to the acquirer via the payment network. In other embodiments, the issuer may make a payment directly to the acquirer. Funding may include a payment from the acquirer to the merchant for a cleared and settled payment transaction. Those skilled in the art will appreciate that any ordering and / or classification of the above steps as part of payment transaction processing may be chosen. A "transaction account" may refer to a financial account (e.g., a checking account, a savings account, a credit account, a virtual payment account, etc.) used to fund a transaction.A transaction account may be associated with a consumer, which may be any suitable type of entity associated with a payment account (which may include a person, a family, a company, a corporation, a government entity, etc.). In some embodiments, the transaction account may be virtual (e.g., an account operated by PayPal®, etc.).
[0014] The system 100 shown in FIG. 1 illustrates systems for an acquirer and an issuer involved in a payment transaction, which may be represented as an acquirer system 102 and an issuer system 104. As used herein, the term "acquirer" may refer to an entity that can process payment card transactions on behalf of a merchant. An acquirer may be a bank or other financial institution authorized to process payment card transactions on behalf of a merchant. In many cases, an acquirer may open a line of credit where the merchant serves as the beneficiary. An acquirer may exchange funds with an issuer when a consumer, who may be the beneficiary of a line of credit provided by the issuer, transacts with a merchant represented by the acquirer via a payment card. As used herein, an "issuer" may refer to an entity that establishes (e.g., opens) a letter of credit or line of credit for a beneficiary and accepts notes drawn by the beneficiary for the amount specified in the letter of credit or line of credit. In many embodiments, an issuer may be a bank or other financial institution authorized to open a line of credit. In some embodiments, any entity that can extend credit to a beneficiary may be considered an issuer. Credit facilities opened by issuers may be presented in the form of payment accounts and may be drawn by beneficiaries by using payment cards. Issuers may also offer additional types of payment accounts to consumers (e.g., debit accounts, prepaid accounts, e-wallet accounts, savings accounts, checking accounts, etc.) and may offer consumers physical or non-physical means to access and / or use such accounts (e.g., debit cards, prepaid cards, cash machine cards, e-wallets, checks, etc.), as would be apparent to one of ordinary skill in the art.
[0015] In a traditional payment transaction such as that processed by the system 100, the acquirer system 102 may receive transaction details for the payment transaction from the merchant's Point of Sale system or other suitable source. In some cases, the transaction details may be formatted in a transaction message by the merchant's Point of Sale system before being sent to the acquirer system 102. In other cases, the transaction details may be sent to the acquirer system 102 in a different format, and the acquirer system 102 may be configured to generate a transaction message for the payment transaction. The transaction message may be a specially formatted data message, which may be formatted according to one or more standards governing the exchange of financial transaction messages, which may be specified by the payment network through which the payment transaction is processed. Such standards may be, for example, the International Organization for Standardization's ISO 8583 or ISO 20022 standards. The transaction message may include multiple data elements, each of which may be configured to store data as specified in the applicable standard. For example, one data element may be configured to store the account number of the transaction account being used to fund the payment transaction, while another data element may be configured to store a timestamp and another element may be configured to store a merchant identification value. The transaction message may also include a message type indicator, which may be indicative of the type of transaction message. For example, a message type indicator for a transaction message received or generated by the acquirer system 102 may indicate that the transaction message is an authorization request.
[0016] When the acquirer system 102 obtains or generates a transaction message, the transaction message can be sent electronically to the interface processor 106. The interface processor 106 can be a physical computing device connected to the acquirer system 102 or the issuer system 104, or can be used to connect external systems to the payment network, which can provide the interface processor 106 at the point for all acquirers and issuers that have their transactions processed through the payment network. In many cases, the interface processor 106 is a closed system and cannot be accessed by unauthorized entities. In such cases, only authorized personnel (typically employed or otherwise contracted by the payment network itself) can access the interface processor 106 (physically or by software or other means). The acquirer system 102 electronically sends a payment message for a new payment transaction to its local interface processor 106 using an appropriate communication network and method. The interface processor 106a then performs any necessary actions on the transaction message (e.g., stand-in processing, value-added services, fraud detection, etc.) before sending the transaction message to the central processor 108 using the payment rail, which is a special network infrastructure on the payment network that is accessible only by authorized devices (e.g., the interface processor 106 and the central processor 108).
[0017] The central processor 108 can receive the transaction message from the interface processors 106 and analyze the data contained in the data elements thereof to determine a routing plan for the transaction message. In a traditional payment transaction, the central processor 108 can identify a value stored in a data element configured to store a transaction account number for a transaction account used to fund the payment transaction (e.g., swiping a debit or credit card by a merchant), where part of the transaction account number may include a bank identification number. The central processor 108 can use the bank identification number to identify the issuer system 104 associated with the financial institution that issued the transaction account for routing the transaction message. The central processor 108 can then forward the transaction message using a settlement rail to the appropriate interface processor 106 in the payment network that can communicate with the issuer system 104. In many cases, the central processor 108 can be configured to perform additional services or functions that leverage the transaction message prior to forwarding, such as applying transaction controls, performing fraud detection, initiating consumer protection measures, etc.
[0018] The interface processor 106b can receive transaction messages from the central processor 108 and can forward the transaction messages to the issuer system 104 using an appropriate communication network and method (e.g., LAN, radio frequency network, Internet, etc.). The issuer system 104 can receive the transaction messages and determine whether the corresponding payment transaction should be approved or denied using traditional techniques, such as ensuring that the credit limit or balance of the transaction account is sufficient to cover the cost of the payment transaction as indicated in a data element configured to store the transaction amount. The issuer system 104 can generate an authorization response for the payment transaction, which can be a new transaction message or a modified version of the received authorization request, including an indication of a message type indicating an authorization response, and also including a response code indicating the approval or decline of the payment transaction and a data element configured to store the reason for the decline, if applicable in some cases.
[0019] The issuer system 104 can send an approval response to the interface processor 106b, which can then forward the approval response to the central processor 108 using the settlement rail. The central processor 108 can perform any necessary functions (e.g., updating values for transaction control, recording data for compliance, etc.) and forward the approval response to the interface processor 106a using the settlement rail. The interface processor 106a can then electronically transmit the approval response to the acquirer system 102 using an appropriate communications network and method. The acquirer system 102 can use the approval response to identify whether the payment transaction was approved or rejected and can appropriately notify the merchant and finalize the payment transaction (e.g., if approved, providing the purchased goods or services to the consumer). The acquirer system 102 can then appropriately credit the transaction account for the merchant (e.g., as identified in the appropriate data element in the transaction message) that is being used to receive funds for the payment transaction.
[0020] In the system 100, one of the entities involved in a payment transaction processed using the payment network may be interested in taking advantage of the features offered by the blockchain, such as smart contracts. A smart contract is a self-executing function that can execute using data provided to it and can perform one or more actions as a result. For example, a smart contract can be provided with transaction data for a payment transaction and, if the transaction data meets expectations, can submit an item ownership transfer instruction to another system or record the transfer on the blockchain. By way of example, two parties can proceed with a transaction for the sale of a property, the deed for which is stored on the blockchain, and a smart contract is used to transfer the deed to the buyer on the blockchain if a traditional payment transaction for the sale is positively verified.
[0021] To take advantage of such functionality, the system 100 can include a blockchain network 110. The blockchain network 110 can be comprised of a number of blockchain nodes 112. Each blockchain node 112 can be a computing system, as shown in FIG. 2 or FIG. 5, configured to perform functions related to blockchain processing and management, such as those described in detail below, which may include, for example: generating blockchain data values, validating proposed blockchain transactions, verifying digital signatures, generating new blocks, validating new blocks, and maintaining a copy of the blockchain.
[0022] A blockchain may be a distributed ledger that includes at least a number of blocks. Each block may include at least a block header and one or more data values. Each block header may include at least a timestamp, a block reference value, and a data reference value. The timestamp may be the time when the block header is generated and may be expressed using any suitable method (e.g., UNIX timestamp, Date Time notation, etc.). The block reference value may be a value that references (e.g., based on the timestamp) a preceding block in the blockchain. 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 an exemplary embodiment, 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 in the block that includes the block header. In an exemplary embodiment, 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.
[0023] As a result of using a block reference value and a data reference value in each block header, the blockchain can be given immutability. Any attempt to change the data value requires the generation of a new data reference value for the block, which in turn requires the generation of a new block reference value for the subsequent block, which in turn requires the generation of a new block reference value for each subsequent block. To make the change permanent, the above must be performed and updated for every single blockchain node 112 in the blockchain network 110 before a new block is created and added to the blockchain. Computing and communication capacity limitations can make such changes extremely difficult or impossible, and thus the blockchain achieves immutability.
[0024] In some embodiments, a blockchain can be used to store information about blockchain transactions made between two different blockchain wallets. A blockchain wallet can contain a private key of a cryptographic key pair that can be used to generate a digital signature that can serve as a payer's authorization for a blockchain transaction, and the digital signature can be verified by the blockchain network 110 using the public key of the cryptographic key pair. In some cases, the term "blockchain wallet" can refer specifically to a private key. In other cases, the term "blockchain wallet" can refer to a computing device (e.g., the acquirer system 102, etc.) that stores a private key for use in blockchain transactions. For example, each computing device can have its own private key for each cryptographic key pair, and each can 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 a blockchain wallet, such as a desktop computer, a laptop computer, a notebook computer, a tablet computer, a mobile phone, a smartphone, a smart watch, a smart TV, a wearable computing device, an embeddable computing device, etc.
[0025] Each blockchain data value stored in the blockchain may correspond to a blockchain transaction or storage of other data, if applicable. A blockchain transaction may comprise at least the following: a digital signature of the currency sender (e.g., issuer system 104) generated using the sender's private key, a blockchain address of the currency recipient (e.g., acquirer system 102) 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., if access to such currency is evidenced by a digital signature); and an address for any changes to be held by the sender, generated using the sender public key. Addresses to which cryptocurrency that can be used in future transactions is sent are referred to as "output" addresses because they were previously used to capture the output of a previous blockchain transaction, and are also referred to as "unspent transactions" because there is currency sent to the address in a previous transaction where that currency has not yet been spent. In some cases, a blockchain transaction may also include a sender public key for an entity to use in validating the transaction. For traditional processing of blockchain transactions, such data may be provided by either the sender or the recipient to a blockchain node 112 in the blockchain network 110. The node can verify the digital signature using the public key in the sender's wallet cryptographic key pair and verify access to the sender's funds (e.g., if an unspent transaction has not yet been spent and was sent to an address associated with the sender's wallet), a process known as "confirming" the transaction, 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 in the blockchain network 110 before being added to the blockchain and distributed to all blockchain nodes 112 in the blockchain network 110. If the blockchain data value does not relate to a blockchain transaction but instead relates to the storage of other types of data, the blockchain data value may still include or involve verification of a digital signature.
[0026] In the system 100, the transaction message can be sent to a blockchain node 112 in the blockchain network 110. In some embodiments, the interface processor 106 (either the interface processor 106a or 106b) can electronically transmit the transaction message to the blockchain node 112. In some such embodiments, the interface processor 106 can have two communication ports, a first communication port connected to a settlement rail of the payment network for communicating with the central processor 108, and a second communication port connected to a different communication network (e.g., the Internet) for communicating with the blockchain node 112. In some cases, the communication ports can use different communication protocols or other technologies. In other embodiments, the central processor 108 can electronically transmit the transaction message to the blockchain node 112. In some such embodiments, the central processor 108 can also have multiple communication ports, such as a communication port configured to communicate with the interface processor 106 using a settlement rail and a communication port configured to communicate with one or more blockchain nodes 112 over another communication network (e.g., the Internet). In some embodiments, the acquirer system 102 and / or the issuer system 104 may be configured to transmit transaction messages to the blockchain node 112 electronically using any suitable communications network and method.
[0027] In some cases, the transaction message electronically sent to the blockchain node 112 can be an approval response. In other cases, an approval request can be sent electronically to the blockchain node 112. In some cases, the issuer system 104 can be required to provide explicit approval when forwarding a transaction message involving a payment account associated with the issuer to the blockchain node 112. In some cases, an approval response indicating approval for the payment transaction can be sufficient for approval. In other cases, the interface processor 106b can electronically send a request message requesting approval to the issuer system 104 and can send the transaction message to the blockchain node 112 only after receiving a return message indicating approval from the issuer system 104.
[0028] In some embodiments, the central processor 108 or the interface processor 106 may determine a routing plan for the received transaction message. The routing plan may include sending a copy of the transaction message to the blockchain node 112 prior to such transmission. In such embodiments, the determination may be based on a bank identification number or other value stored in an appropriate data element, such as a data element reserved for private use, included in an appropriate data element included in the transaction message. For example, the data element reserved for private use may be used to store a flag value that may be used by the interface processor 106a or the central processor 108 to determine whether the transaction message is sent to the blockchain node 112. In some cases, the issuer system 104 may provide instructions to the interface processor 106 or the central processor 108 regarding sending the transaction message to the blockchain node 112, which may be included in, for example, an acknowledgement response or a separate message.
[0029] When a blockchain node 112 receives a transaction message, the blockchain node 112 can identify a blockchain data item stored in the blockchain or data contained therein that is associated with the transaction message. In some cases, the transaction message can include a value stored in a data element reserved for private use that can be used by the blockchain node 112 to identify the blockchain data item or data contained therein. For example, a smart contract stored in a blockchain data item in the blockchain can be assigned a unique identifier, or a blockchain data item that includes a smart contract can be assigned a unique identifier, where the unique identifier can be included in a data element stored in the transaction message. In such an example, the blockchain node 112 can identify the blockchain data item or smart contract using the unique identifier.
[0030] The blockchain node 112 can then execute the identified smart contract or perform other functions (e.g., verifying and executing new blockchain transactions). In some cases, the smart contract may require input data that can be parsed from the received transaction message. In such cases, the blockchain node 112 can parse the appropriate data from the transaction message (e.g., identified via applicable criteria and data elements in the transaction message) and provide the identified data as input to the smart contract. In other cases, the transaction message itself can be used as input to the smart contract, and the smart contract can identify the necessary data within the transaction message itself. The smart contract can then self-execute any necessary functions designed by the contract.
[0031] In some embodiments, the system 100 may be implemented with the interface processors 106a and 106b combined into a single interface processor 106. In some embodiments, the central processor 108 may be configured to perform the functions of the interface processor 106 as described herein. In some embodiments, one or more of the interface processors 106 may be configured to perform the functions of the central processor 108. In some embodiments, the acquirer system 102 and / or the issuer system 104 may be a blockchain node 112 in the blockchain network 110. In some embodiments, the interface processor 106 may be a blockchain node 112 in the blockchain network 110. In such embodiments, one or more components depicted in the system 100 may be configured to perform the functions of other components in the system 100, if applicable.
[0032] The above described method and system allows for the exploitation of blockchain functionality, such as smart contracts, in traditional payment transactions. By sending transaction messages to the blockchain node 112 during the processing of the associated payment transaction, blockchain functionality can be introduced without affecting the processing of payment transactions using traditional payment network architectures and infrastructures or requiring changes to the acquirer system 102 or issuer system 104. For example, by utilizing a new communication port on the interface processor 106, the use of blockchain functionality can be introduced in traditional payment transactions, without affecting the processing of traditional payment transactions and while preserving the isolation and security of the payment network's settlement rails. This can result in an expansion of the services that can be offered to customers of the payment network, requiring minimal changes to the processors and systems that customers are already familiar with, and providing a significant technical improvement over existing systems.
[0033] Computing Device FIG. 2 illustrates an embodiment of a computing device 200. It will be apparent to those skilled in the art that the embodiment of the computing device 200 illustrated in FIG. 2 is provided for illustrative purposes only and is not an exhaustive list of all possible configurations of a computing device 200 suitable for performing the functions of the present disclosure. For example, computer system 500 illustrated in FIG. 5 and described in more detail below may be a suitable configuration of a computing device 200. The computing device 200 may be configured to function as one or more components of a system 100, which may include an acquirer system 102, an issuer system 104, an interface processor 106, a central processor 108, and a blockchain node 112.
[0034] The computing device 200 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 acquirer system 102, the issuer system 104, the interface processor 106, the central processor 108, the blockchain node 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, the Internet, etc. In some embodiments, the receiving device 202 may include multiple devices (e.g., different receiving devices receiving data over different networks, such as a first receiving device receiving data over a local area network and a second receiving device receiving data over the Internet). The receiving device 202 may receive a transmitted electronic data signal. Then, upon receipt of the data signal by the receiving device 202, data may be superimposed on the data signal and decoded, parsed, read, or obtained. In some embodiments, the receiving device 202 may include an analysis module for analyzing the received data signal to obtain data overlaid thereon. For example, the receiving device 202 may include an analysis program configured to receive and convert the received data signal into usable input for functions performed by the processing device to implement the methods and systems of the present disclosure.
[0035] The receiving device 202 can be configured to receive data signals electronically transmitted by the acquirer system 102, which can be superimposed or encoded with a transaction message including an authorization request message. The receiving device 202 can be configured to receive data signals electronically transmitted by the issuer system 104, which can be superimposed or encoded with a transaction message, which includes an authorization response message, a response message indicating approval of the blockchain transfer, and instructions regarding the blockchain transfer. The receiving device 202 can further be configured to receive data signals electronically transmitted by the interface processor 106 and / or the central processor 108, which can be superimposed or encoded with a transaction message, which can include an authorization request and an authorization response. The receiving device 202 can be configured to receive data signals electronically transmitted by the blockchain node 112, which can be superimposed or encoded with blockchain data, a new block, a blockchain data value, a confirmation message, etc.
[0036] The computing device 200 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 computing device 200 for use in performing the functions of the present 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 a bus, a connection pin connector, wires, etc. In some embodiments, the communication module 204 may also be configured to communicate between internal components of the computing device 200 and external components of the computing device 200 (e.g., an externally connected database, a display device, an input device, etc.). The computing device 200 may also include a processing device. The processing device may be configured to perform the functions of the computing device 200 of the present disclosure. This will be apparent to one of ordinary skill in the art. In some embodiments, the processing device may include multiple engines and / or modules (e.g., the query module 216, the generation module 218, the validation module 220, etc.) that are specifically configured to perform one or more functions of the processing device. As used in this disclosure, the term "module" may refer to software or hardware that is specifically programmed to receive an input, perform one or more operations using the input, and provide an output. The inputs, outputs, and operations performed by the various modules will be apparent to one of ordinary skill in the art based on this disclosure.
[0037] The computing device 200 may include a routing database 206. The routing database 206 may be configured to store a number of routing profiles 208 using a suitable data storage format and schema. The routing database 206 may be a relational database that uses a structured query language to store, identify, modify, update, access, etc., stored structured data sets. Each routing profile 208 may be configured to store data related to the routing of transaction messages. For example, the routing profile 208 may include bank identification numbers or other values stored in data elements in transaction messages as well as other information such as communication addresses (e.g., for the issuer system 104, the acquirer system 102, the interface processor 106, etc.) regarding where such values should be routed. The routing profile 208 may also include rules or criteria for sending transaction messages to the blockchain nodes 112.
[0038] Computing device 200 may also include blockchain data 212, which may be stored in memory 214 of computing device 200 or stored in a separate area within computing device 200 or made accessible by it. Blockchain data 212 may include a blockchain, which may comprise a number of blocks, and may be associated with blockchain network 110. In some cases, blockchain data 212 may further include any other data associated with the blockchain and its management and performance, such as block generation algorithms, digital signature generation and verification algorithms, communication data for blockchain nodes 112, etc.
[0039] Computing device 200 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 computing device 200 in performing the functions of the present 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, program code for modules and application programs for the processing device, and other appropriate data used by computing device 200 in performing the functions of the present disclosure. This will be apparent to those of skill in the art upon reading this disclosure. In some embodiments, memory 214 may include a relational database using Structured Query Language (SQL) to store, identify, modify, update, access, etc., stored structured data sets. Memory 214 may be configured to store, for example, cryptographic keys, cryptographic key pairs, communication information, data formatting rules, blockchain data, signature generation algorithms, transaction message standards, etc.
[0040] The computing device 200 may also include a query module 216. The query module 216 may be configured to perform a query on a database to identify information. The query module 216 may receive one or more data values or a query string, and based thereon, may perform the query string on an indicated database (e.g., the memory 214 of the computing device 200) to identify information stored therein. The query module 216 may then output the identified information to an appropriate engine or module of the computing device 200 as needed. The query module 216 may, for example, perform a query on the routing database 206 to identify a routing profile 208 for a received transaction message for use in determining a routing plan for the transaction message.
[0041] Computing device 200 may also include a generation module 218. The generation module 218 may be configured to generate data for use by computing device 200 in performing functions of the present disclosure. The generation module 218 may receive instructions as input values, generate data based on the instructions, and output the generated data to one or more modules of computing device 200. For example, the generation module 218 may be configured to generate notification messages, confirmation messages, digital signatures, blockchain data values, blocks, routing profiles, transaction messages, unique identifiers, etc.
[0042] Computing device 200 may also include a validation module 220. Validation module 220 may be configured to perform validation on computing device 200 as part of the functionality of the present disclosure. Validation module 220 may receive as input instructions, which may include data used in performing the validation, perform the validation as requested, and output the results of the validation to another module or engine of computing device 200. Validation module 220 may be configured, for example, to: verify digital signatures using appropriate signature generation algorithms and keys, verify data objects and / or data contained therein, verify transaction messages for authorization, verify values stored in data elements of transaction messages, etc.
[0043] The computing device 200 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 acquirer system 102, the issuer system 104, the interface processor 106, the central processor 108, the blockchain node 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, the Internet, etc. 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 transmitting data over a local area network and a second transmitting device transmitting data over the Internet)). The transmitting device 222 may electronically transmit a data signal having the superimposed data, the data being analyzed by the receiving computing device. In some embodiments, the transmitting device 222 may include one or more modules for superimposing, encoding, or formatting data into a data signal suitable for transmission.
[0044] The sending device 222 can electronically send a data signal to the acquirer device 102, the data signal being superimposed or encoded with a transaction message, such as an authorization response message for an approved or rejected payment transaction. The sending device 222 can also be configured to electronically send a data signal to the issuer system 104, the data signal being superimposed or encoded with a transaction message, including an authorization request message, a request for approval of a blockchain transfer, and the like. The sending device 222 can further be configured to electronically send a data signal to the interface processor 106 and / or the central processor 108, the data signal being superimposed or encoded with a transaction message, including an authorization request and authorization response message, a response message indicating approval or rejection of a blockchain transfer, and the like. The sending device 222 can also be configured to electronically send a data signal to the blockchain node 112, the data signal being superimposed or encoded with a transaction message, blockchain data, blockchain data values, new blocks, confirmation messages, response messages, and the like.
[0045] Executing smart contracts for payment transactions FIG. 3 illustrates the execution of smart contracts stored on a blockchain by integrating blockchain technology with the payment processing architecture in system 100 of FIG. 1 as part of traditional payment transaction processing.
[0046] At S302, the receiving device 202 of the interface processor 106 can receive a transaction message for a payment transaction via a settlement rail. The transaction message can be an authorization request message (e.g., as indicated in an indication of a message type in the transaction message), which can be specially formatted according to one or more standards governing the exchange of financial transaction messages. The transaction message can include a plurality of data elements configured to store data as indicated in the applicable standard, the plurality of data elements storing transaction data for the payment transaction, including at least a bank identification value. At S304, the generating module 218 of the interface processor 106 can generate a routing plan for the transaction message based on at least the bank identification value. For example, the query module 216 of the interface processor 106 can perform a query on the routing database 206 of the interface processor to identify a routing profile 208 stored therein that includes a bank identification value. The generating module 218 can generate a routing plan based on the data included in the routing profile 208.
[0047] At S306, the sending device 222 of the interface processor 106 can forward the transaction message to the issuer system 104 based on the routing plan. The transaction message can be forwarded using a first communication port of the interface processor 106. At S308, the receiving device 202 of the issuer system 104 can receive the transaction message from the interface processor 106. At S310, the verification module 220 of the issuer system 104 can decide to approve or reject the payment transaction based on the data included in the transaction message, for example, by identifying the transaction account using an account number stored in a corresponding data element in the transaction message and determining whether the balance or credit limit of the transaction account is adequate to cover the transaction amount for the payment transaction stored in another corresponding data element in the transaction message. If the approval is approved, the generation module 218 of the issuer system 104 can generate an approval response. The approval response can be a modified version of the approval request or a new transaction message, which includes a data element storing an indication of a message type indicating an approval response as well as a response code indicating approval of the payment transaction.
[0048] At S312, the sending device 222 of the issuer system 104 may electronically send the authorization response message to the interface processor 106. At S314, the receiving device 202 of the interface processor 106 may receive the authorization response. At S316, the sending device 222 of the interface processor 106 may electronically send a transaction message (e.g., the authorization request received at S302 or the authorization response received at S314) to the blockchain node 112. The transaction message may be sent using a second communication port of the interface processor 106. At S318, the sending device 222 of the interface processor 106 may forward the authorization response to the acquirer system 102 for use in finalizing the associated payment transaction.
[0049] At S320, the receiving device 202 of the blockchain node 112 can receive the transaction message from the interface processor 106. At S322, the query module 216 of the blockchain node 112 can identify a smart contract stored in a blockchain data value in a blockchain of the blockchain network 110 including the blockchain node 112, and the smart contract can be stored locally in the blockchain data 212 in the blockchain node 112. In some cases, the smart contract can be identified using a value stored in a data element reserved for private use included in the received transaction message. At S324, the blockchain node 112 can use the transaction message or the data included therein as input and can execute the smart contract on the blockchain, which can result in one or more actions being performed as programmed in the smart contract.
[0050] Exemplary Methods for Integrating Blockchain into Payment Network Architectures FIG. 4 illustrates a method 400 for integrating blockchain technology with a payment network architecture through enabling the use of blockchain smart contracts as part of traditional payment transactions.
[0051] At S402, a transaction message for a payment transaction can be received by a receiver (e.g., receiving device 202) of a processing server (e.g., acquirer system 102, issuer system 104, interface processor 106, central processor 108, etc.). The transaction message is formatted according to one or more standards and includes a number of data elements that store transaction data. The transaction data includes at least a bank identification value. At S404, a routing plan for the transaction message can be determined by a processor (e.g., generating module 218) of the processing server based on at least the bank identification value. At S406, the transaction message can be transmitted by a transmitter (e.g., sending device 222) of the processing server to (i) a first computing system (e.g., issuer system 104, interface processor 106, central processor 108) using a first communication port of the processing server, and (ii) a second computing system (e.g., blockchain node 112) using a second communication port of the processing server based on the determined routing plan.
[0052] In one embodiment, the transaction message sent using the first communication port can use a first communication network and protocol, and the transaction message sent using the second communication port can use a second communication network and protocol. In some embodiments, the first computing system can be associated with a financial institution. In one embodiment, the plurality of data elements can include a data element reserved for private use that stores a routing value, and the routing plan can be further determined based on the routing value. In some embodiments, the method 400 further includes receiving, by the receiver of the processing server, a confirmation message from the first computing system indicating approval of the payment transaction, the confirmation being received prior to sending the transaction message to the second computing system.
[0053] In one embodiment, the second computing system may be a blockchain node in the blockchain network (e.g., blockchain network 110). In a further embodiment, the method 400 also includes identifying, by a processor of the second computing system (e.g., query module 216), a smart contract stored on a blockchain associated with the blockchain network based on at least the transaction data, and executing, by the processor of the second computing system, the identified smart contract using one or more values included in the transaction data as inputs for the smart contract. In a further embodiment, the plurality of data elements may include a data element reserved for private use that stores a unique identification value, and the smart contract may be identified using the unique identification value.
[0054] Computer System Architecture 5 illustrates a computer system 500, in which an embodiment of the present disclosure or a portion thereof may be implemented as computer readable code. For example, the acquirer system 102, the issuer system 104, the interface processor 106, the central processor 108, and the blockchain node 112 of FIG. 1 and the computing device 200 of FIG. 2 may be implemented in the computer system 500 using hardware, a non-transitory 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 may embody modules and components used to implement the methods of FIGS. 3 and 4.
[0055] Where programmable logic is used, such logic may be executed on commercially available processing platforms configured with executable software code, and may be dedicated or special purpose devices (e.g., programmable logic arrays (PGAs), application specific integrated circuits (ASICs), etc.). Those skilled in the art will appreciate that embodiments of the disclosed subject matter may be implemented in a variety of computer system configurations, including multi-core, multi-processor systems, minicomputers, mainframe computers, distributed functionality linked or clustered computers, and general purpose or miniature computers that may be implemented in virtually any device. For example, at least one processor unit and memory may be used to implement the above embodiments.
[0056] A processor unit or device of the present disclosure may be a single processor, multiple processors, or a combination thereof. A processor device may have one or more processor “cores.” The terms “computer program medium,” “non-transitory computer readable medium,” and “computer usable medium” of the present disclosure are generally used to refer to tangible media (e.g., removable storage unit 518, removable storage unit 522, and a hard disk installed in hard disk drive 512, etc.).
[0057] Various embodiments of the present disclosure are described with respect to this exemplary computer system 500. After reading this disclosure, it will be obvious to one of ordinary skill in the art how to implement the present disclosure using other computer systems and / or computer architectures. Although operations are disclosed as sequential processes, some operations may in fact be performed in parallel, concurrently and / or in a distributed environment, where the program code is stored locally or remotely for access by a single processor or multi-processor machine. Furthermore, in some embodiments, the order of operations can be rearranged without departing from the spirit of the disclosed subject matter.
[0058] The processor unit 504 may be a special purpose or general purpose processor unit that is specially configured to perform the functions of the present disclosure. The processor unit 504 may be connected to a communication infrastructure 506 (e.g., a bus, a message queue, a network, a multi-core message passing scheme, etc.). The network may be any network suitable for performing the functions of the present disclosure, and may include a local area network (LAN), a wide area network (WAN), a wireless network (e.g., Wifi), a mobile communication network, a satellite network, the Internet, optical fiber, coaxial cable, infrared, radio frequency (RF), or any combination thereof. Other suitable network types and configurations will be apparent to those skilled in the art. The computer system 500 may also include a main memory 508 (e.g., random access memory, read only memory, etc.) and may also include a secondary memory 510. The secondary memory 510 may include a hard disk drive 512 and a removable storage drive 514 (e.g., a floppy disk drive, a magnetic tape drive, an optical disk drive, a flash memory, etc.).
[0059] The removable storage drive 514 may read from and / or write to the removable storage unit 518 in a well-known manner. The removable storage unit 518 may include a removable storage medium that can be read from and written to by the removable storage drive 514. For example, if the removable storage drive 514 is a floppy disk drive or a USB port, the removable storage unit 518 may be a floppy disk or a portable flash drive, respectively. In one embodiment, the removable storage unit 518 may be a non-transitory readable recording medium.
[0060] In some embodiments, secondary memory 510 may include alternative means for allowing computer programs or other instructions to be loaded into computer system 500 (e.g., removable storage unit 522 and interface 520). Examples of such means may include program cartridges and cartridge interfaces (e.g., as found in video game systems), removable memory chips (e.g., EEPROM, PROM, etc.) and associated sockets, other removable storage units 522 and interfaces 520, as will be apparent to those skilled in the art.
[0061] Data stored in computer system 500 (e.g., in main memory 508 and / or secondary memory 510) may be stored on any type of suitable computer-readable medium, such as optical storage (compact disc, digital versatile disc, Blu-ray disc, etc.) or magnetic tape storage (e.g., hard disk drive). The data may be organized in any type of suitable database structure (e.g., a relational database, a Structured Query Language (SQL) database, a distributed database, an object database, etc.). Suitable structures and storage types will be apparent to those skilled in the art.
[0062] Computer system 500 may also include a communications interface 524. Communications interface 524 may allow software and data to be sent and received between computer system 500 and external devices. Exemplary communications interface 524 may include a modem, a network interface (e.g., an Ethernet card), a communications port, a PCMCIA slot and card, and the like. The software and data transferred through communications interface 524 may be in the form of signals. The signals may be electronic, electromagnetic, optical, or other signals as would be apparent to one skilled in the art. The signals propagate through communications path 526. The paths are configured to carry the signals and may be implemented using wire, cable, fiber optics, a phone line, a cellular phone link, a radio frequency link, and the like.
[0063] Computer system 500 may further include a display interface 502. Display interface 502 may be configured to allow data to be transferred between computer system 500 and an external display 530. Exemplary display interfaces 502 may include a high-definition multimedia interface (HDMI), a digital visual interface (DVI), a video graphics array (VGA), etc. Display 530 may be any suitable type of display to display data transferred via display interface 502 of computer system 500, including a cathode ray tube (CRT) display, a liquid crystal display (LCD), a light emitting diode (LED) display, a capacitive touch display, a thin film transistor (TFT) display, etc.
[0064] The computer program medium and computer usable medium may refer to memory (e.g., main memory 508 and secondary memory 510), which may be semiconductor memory (DRAM, etc.). These computer program products may be means for providing software to the computer system 500. Computer programs (e.g., computer control logic) may be stored in the main memory 508 and / or secondary memory 510. Computer programs may also be received via the communication interface 524. Such computer programs, when executed, may enable the computer system 500 to perform the methods of the present disclosure. In particular, the computer programs, when executed, may enable the processor unit 504 to perform the methods shown in Figures 3 and 4 as described herein. Thus, such computer programs represent the controller of the computer system 500. The present disclosure is implemented using software. The software may be stored in the computer program product and loaded into the computer system 500 using the removable storage drive 514, the interface 520, and the hard disk drive 512 or the communication interface 524.
[0065] The processor unit 504 may include one or more modules or engines configured to perform the functions of the computer system 500. Each module or engine may be implemented using hardware and in some embodiments using software (e.g., which corresponds to a program code or program stored in the main memory 508 or the secondary memory 510). In such embodiments, the program code may be compiled by the processor unit 504 (e.g., by a compilation module or engine) before execution by the hardware of the computer system 500. 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 lower-level language for execution by the processor unit 504 and / or any additional hardware components of the computer system 500. The compilation process may include the use of lexical analysis, preprocessing, syntax analysis, semantic analysis, syntax-driven translation, code generation, code optimization, and any other techniques suitable for translating the program code into a lower-level language for control of the computer system 500 to perform the functions of the present disclosure. Those skilled in the art will appreciate that such processing results in computer system 500 being a specially configured computer system 500 that is uniquely programmed to perform the functions described above.
[0066] Among other features, technology consistent with the present disclosure provides systems and methods for enabling the use of blockchain smart contracts as part of traditional payment transactions. While various exemplary embodiments of the systems and methods of the present disclosure have been described above, it should be understood that they are presented for purposes of illustration only and not limitation. It is not exhaustive and does not limit the present disclosure to the precise forms disclosed. Modifications and variations are possible in light of the above teachings. Modifications and variations may be made from implementations of the present disclosure without departing from the scope or spirit of the present disclosure.
Claims
1. 1. A method for enabling a blockchain smart contract to be used as part of a traditional payment transaction, comprising: receiving, by a receiver of a processing server, a transaction message for a payment transaction, the transaction message being formatted according to one or more standards and including a plurality of data elements storing transaction data, the transaction data including at least a bank identification value; determining, by a processor of the processing server, a routing plan for the transaction message based at least on the bank identification value; transmitting, by a transmitter of the processing server, the transaction message based on the determined routing plan (i) to a first computing system using a first communication port of the processing server, and (ii) to a second computing system using a second communication port of the processing server; A method comprising:
2. 10. The method of claim 1 , the transaction message transmitted using the first communication port uses a first communication network and protocol; The method, wherein the transaction message sent using the second communication port uses a second communication network and protocol.
3. The method of claim 1 , wherein the first computing system is associated with a financial institution.
4. 10. The method of claim 1, wherein the second computing system is a blockchain node in a blockchain network.
5. The method of claim 4 further comprising: identifying, by a processor of the second computing system, a smart contract stored on a blockchain associated with the blockchain network based at least on the transaction data; executing, by the processor of the second computing system, the identified smart contract using one or more values included in the transaction data as inputs to the smart contract; A method comprising:
6. 6. The method of claim 5, the plurality of data elements includes a data element reserved for private use storing a unique identification value; The smart contract is identified using the unique identification value.
7. 10. The method of claim 1 , the plurality of data elements includes a data element reserved for private use storing a routing value; The routing plan is further determined based on the routing values.
8. The method of claim 1 further comprising: The method further includes receiving, by the receiver of the processing server, a confirmation message from the first computing system indicating approval of the payment transaction, the confirmation being received prior to sending the transaction message to the second computing system.
9. 1. A system that enables the use of blockchain smart contracts as part of a traditional payment transaction, comprising: a first computing system; a second computing system; and A processing server, the processing server comprising: a receiver for receiving a transaction message for a payment transaction, the transaction message being formatted according to one or more standards and including a plurality of data elements storing transaction data, the transaction data including at least a bank identification value; a processor for determining a routing plan for the transaction message based at least on the bank identification value; a transmitter that transmits the transaction message (i) to the first computing system using a first communication port of the processing server and (ii) to the second computing system using a second communication port of the processing server based on the determined routing plan; Including, the system.
10. 10. The system of claim 9, the transaction message transmitted using the first communication port uses a first communication network and protocol; The transaction message sent using the second communication port uses a second communication network and protocol.
11. 10. The system of claim 9, wherein the first computing system is associated with a financial institution.
12. 10. The system of claim 9, further comprising: Equipped with a blockchain network, The second computing system is a blockchain node in a blockchain network.
13. 13. The system of claim 12, wherein the second computing system includes a processor, the processor comprising: Identifying a smart contract stored on a blockchain associated with the blockchain network based on at least the transaction data; Executing the identified smart contract using one or more values included in the transaction data as inputs to the smart contract.
14. 14. The system of claim 13, the plurality of data elements includes a data element reserved for private use storing a unique identification value; The smart contract is identified using the unique identification value.
15. 10. The system of claim 9, the plurality of data elements includes a data element reserved for private use storing a routing value; The routing plan is further determined based on the routing values.
16. 10. The system of claim 9, wherein the receiver of the processing server further receives a confirmation message from the first computing system indicating approval of the payment transaction, the confirmation being received prior to sending the transaction message to the second computing system.
Citation Information
Patent Citations
Improved methods and systems for processing secure payments over computer networks without pseudo or proxy account numbers
JP2003536181A
Method and apparatus for classifying flows for compression
JP2016503254A
Blockchain-based Universal Tokenization System
JP2019508951A
System for improved transaction processing and routing
JP2020528605A