阅读说明：本技术 用于受限制交易处理的系统和方法 (system and method for restricted transaction processing ) 是由 M·阿尔滕霍芬 C·特鲁尔森 Q·王 于 2018-05-02 设计创作，主要内容包括：根据本发明的一些实施例,交易处理器可以既实施开环处理又实施闭环处理。对于一般的不受限制交易,交易处理器可以将授权引导到与主账号(PAN)相关联的开环主授权实体。对于受限制交易,交易处理器可以确定适当的闭环授权实体(例如,交通机构、保险公司、零售商等)。交易处理器还可以在多路存取区块链中创建条目,以证明在所述授权实体的闭环或受限制账户上的交易。因此,多路存取区块链可以及时更新,从而允许闭环授权实体立即验证交易和账户余额。(According to some embodiments of the invention, the transaction processor may implement both open-loop and closed-loop processing. For a general unlimited transaction, the transaction processor may direct authorization to an open-loop primary authorization entity associated with a Primary Account Number (PAN). For restricted transactions, the transaction processor may determine the appropriate closed-loop authorization entity (e.g., transportation, insurance company, retailer, etc.). The transaction processor may also create an entry in the multi-access blockchain to document a transaction on a closed loop or restricted account of the authorized entity. Thus, the multiple access blockchain can be updated in time, allowing a closed loop authorization entity to immediately verify transaction and account balances.)

1. A method, comprising:

Receiving, at a server computer, a request to process an interaction between a user and a first authorized entity computer, the request including a first value, a credential, and a token;

determining, by the server computer, that the flag is in the request;

Responsive to determining that the flag is in the request, determining, by the server computer, an identity of the first authorized entity computer using the flag;

Accessing, by the server computer, a multiple access blockchain storing data representing a plurality of interactions between a plurality of authorized entity computers and a plurality of users;

Retrieving, by the server computer, a second value associated with the user and the first authorized entity computer from the multi-access blockchain based on the identity;

Determining, by the server computer, that the second value is less than the first value;

Determining, by the server computer, a master authorizing entity computer based on the credentials;

Determining, by the server computer, that the master authorizing entity computer is capable of authorizing a third value, wherein the third value is a difference between the first value and the second value;

Creating, by the server computer, an entry in the multi-access blockchain that records the interaction, wherein the entry includes the second value and the third value; and

facilitating, by the server computer, processing of the third value by the master authorization entity computer.

2. The method of claim 1, wherein the credential comprises an EID.

3. The method of claim 1, further comprising:

Converting the credentials to an account identifier associated with the user and the first authorized entity computer, wherein the account identifier is used to retrieve the second value associated with the user and the first authorized entity computer from the multi-access blockchain.

4. The method of claim 1, further comprising:

Coordinating fulfillment of the third value from the master authorizing entity computer to the first authorizing entity computer.

5. The method of claim 1, wherein the user initiates a fund request to associate a fourth value with the user and the first authorized entity computer, and wherein the first authorized entity computer thereafter creates a new entry in the multi-access blockchain that records the fourth value.

6. the method of claim 5, wherein the request for funds is fulfilled by the master authorizing entity computer against the first authorizing entity computer.

7. the method of claim 1, wherein the master authorizing entity computer implements an open loop process, and wherein the first authorizing entity computer implements a closed loop process.

8. The method of claim 1, wherein the master authorizing entity computer is associated with an issuer of the credential.

9. The method of claim 1, wherein the first authorized entity computer is associated with an entity identified by the token.

10. A server computer, comprising:

A processor; and

A memory coupled to the processor, the memory storing instructions that, when executed by the processor, cause the server computer to perform operations comprising:

receiving, at a server computer, a request to process an interaction between a user and a first authorized entity computer, the request including a first value, a credential, and a token;

Determining, by the server computer, that the flag is in the request;

Responsive to determining that the flag is in the request, determining, by the server computer, an identity of the first authorized entity computer using the flag;

Accessing, by the server computer, a multiple access blockchain storing data representing a plurality of interactions between a plurality of authorized entity computers and a plurality of users;

Retrieving, by the server computer, a second value associated with the user and the first authorized entity computer from the multi-access blockchain based on the identity;

Determining, by the server computer, that the second value is less than the first value;

Determining, by the server computer, a master authorizing entity computer based on the credentials;

Determining, by the server computer, that the master authorizing entity computer is capable of authorizing a third value,

Wherein the third value is a difference between the first value and the second value;

Creating, by the server computer, an entry in the multi-access blockchain that records the interaction, wherein the entry includes the second value and the third value; and

Facilitating, by the server computer, processing of the third value by the master authorization entity computer.

11. The server computer of claim 10, wherein the credentials comprise an EID.

12. the server computer of claim 10, wherein the operations further comprise:

Converting the credentials to an account identifier associated with the user and the first authorized entity computer, wherein the account identifier is used to retrieve the second value associated with the user and the first authorized entity computer from the multi-access blockchain.

13. The server computer of claim 10, wherein the operations further comprise:

Coordinating fulfillment of the third value from the master authorizing entity computer to the first authorizing entity computer.

14. the server computer of claim 10 wherein the user initiates a request for funds to associate a fourth value with the user and the first authorized entity computer, and wherein the first authorized entity computer thereafter creates a new entry in the multi-access blockchain that records the fourth value.

15. The server computer of claim 14, wherein the request for funds is fulfilled by the master authorizing entity computer against the first authorizing entity computer.

16. The server computer of claim 10 wherein the master authorizing entity computer implements an open loop process and wherein the first authorizing entity computer implements a closed loop process.

17. the server computer of claim 10, wherein the master authorizing entity computer is associated with an issuer of the credential.

18. The server computer of claim 10, wherein the first authorized entity computer is associated with an entity identified by the token.

Background

Many entities implement closed loop systems using single-use membership cards. A closed loop system may be one that limits the use of the card to a particular entity and requires the user to hold a unique dedicated account maintained by that entity. This may make it easy for an entity to track and limit the use of membership cards. Limited use of the loyalty card may be required in order to associate restricted government or employer subsidized equity with the card in order to ensure that the equity is not used for improper purposes. Exemplary entities that may conventionally implement a closed loop system include transportation agencies and insurance companies. Due to the nature of closed-loop systems, a user may need to carry a large number of different loyalty cards for different uses (e.g., at least one separate loyalty card per closed-loop entity).

In response, some entities have evolved to implement open-loop systems using multi-purpose membership cards. An open loop system may be one that allows a user to use a single loyalty card for multiple uses and/or at multiple entities. The open loop transaction may be run through a conventional transaction processing channel (e.g., by the transaction processor sending an authorization request message to the authorizing entity). Such open loop systems allow users to reduce the number of loyalty cards that need to be carried. However, restricted equity (e.g., government and employers subsidizing equity) cannot be added to existing open-loop multi-purpose cards because the use of equity would be unlimited and unsupervised.

In addition, neither existing closed-loop systems nor existing open-loop systems are capable of handling combined restricted and unrestricted transactions. For example, a membership card associated with a transit account cannot be used to both gain access to a transit station and initiate a transaction with a retailer at the transit station. In fact, two separate transactions would need to be performed: the first transaction is for gaining access to the transit station with a closed loop transit card and the second transaction is for completing the transaction with the retailer with an open loop card. In an open loop system, a single open loop card may be used to both access the transit station and conduct transactions with the retailer. However, both the access transaction and the retailer transaction will be executed as unrestricted transactions, leaving the restricted rights unused.

in addition, both closed-loop and open-loop entities may use conventional databases to maintain records of transactions performed on user accounts. Each entity may own and/or control its own centralized database. These databases may be easily changed, updated, and/or rewritten such that transaction data may be tampered with or lost. Thus, a history of completion of all transactions performed on the account may not be maintained.

Embodiments of the present invention address this and other problems, individually and collectively.

disclosure of Invention

according to some embodiments of the invention, a method is provided. The method includes receiving, at a server computer, a request to process an interaction between a user and a first authorized entity computer. The request includes a first value, a credential, and a flag (flag). The method also includes determining, by the server computer, that a token is in the request. In response to determining that the token is in the request, the method further includes determining, by the server computer, an identity of the first authorized entity computer using the token. The method also includes accessing, by the server computer, a multi-access (multi-access) blockchain. The multiple access block chain stores data representing a plurality of interactions between the plurality of first authorized entity computers and the plurality of users. The method also includes retrieving, by the server computer, a second value associated with the user and the first authorized entity computer from the multi-access blockchain based on the identity. The method also includes determining, by the server computer, that the second value is less than the first value. The method also includes determining, by the server computer, a master authorized entity computer based on the credentials. The method also includes determining, by the server computer, that the master authorizing entity computer is capable of authorizing the third value. The third value is a difference between the first value and the second value. The method also includes creating, by the server computer, an entry in the multi-access blockchain that records the interaction. The entry includes the second value and a third value. The method also includes facilitating, by the server computer, processing of the third value by the master authorizing entity computer.

embodiments of the present invention are also directed to a server computer including a processor and a memory coupled to the processor. The memory may store instructions executable by the processor for implementing the methods described herein.

These and other embodiments of the invention are described in further detail below.

Drawings

Fig. 1 illustrates a block diagram of a closed loop system according to some embodiments of the invention.

Fig. 2 illustrates a flow diagram of a method for funding and processing transactions using a closed-loop payment card in a closed-loop system, according to some embodiments of the invention.

Fig. 3 illustrates a block diagram of a system for dual transaction processing, according to some embodiments of the invention.

FIG. 4 illustrates a block diagram of a transaction processing computer, according to some embodiments of the invention.

FIG. 5 illustrates a block diagram of an authentication engine according to some embodiments of the invention.

FIG. 6 illustrates a block diagram of a message routing engine, according to some embodiments of the invention.

FIG. 7 illustrates a block diagram of a translation engine, according to some embodiments of the invention.

FIG. 8 shows a block diagram of a first authorizing entity computer in accordance with some embodiments of the invention.

Fig. 9 illustrates a block diagram of a multiple access block chain in accordance with some embodiments of the invention.

FIG. 10 illustrates a flow diagram of a method for dual transaction processing according to some embodiments of the invention.

Detailed Description

According to some embodiments of the invention, the open-loop and closed-loop processing may be implemented by a transaction processor in a dual processing system. For a general unlimited transaction, the transaction processor may direct authorization to an open-loop primary authorization entity associated with a Primary Account Number (PAN). For restricted transactions, the transaction processor may determine the appropriate closed-loop authorization entity (e.g., transportation, insurance company, retailer, etc.). The transaction processor may also create an entry in the multi-access blockchain to document a transaction on a closed loop or restricted account of the authorized entity. Thus, the multiple access blockchain can be updated in time, allowing a closed loop authorization entity to immediately verify transaction and account balances. In some embodiments, the open-loop authorizing entity may also maintain its transactions on the multiple access blockchain.

Before discussing specific embodiments and examples, some description of the terms used herein is provided below.

An "access device" may be any suitable device that provides access to a remote system. The access device may also be used to communicate with a merchant computer, a transaction processing computer, an authentication computer, or any other suitable system. The access device may generally be located at any suitable location, such as at a merchant location. The access means may be of any suitable form. Some examples of access devices include POS or point-of-sale devices (e.g., POS terminals), cellular phones, PDAs, Personal Computers (PCs), tablet PCs, hand-held application-specific readers, set-top boxes, Electronic Cash Registers (ECRs), Automated Teller Machines (ATMs), Virtual Cash Registers (VCRs), kiosks, security systems, access systems, and the like. The access device may use any suitable contact or contactless mode of operation to send or receive data to or from the user's mobile device or to associate with the user's mobile device. In some embodiments where the access device may comprise a POS terminal, any suitable POS terminal may be used and may include a reader, a processor, and a computer readable medium. The reader may include any suitable contact or contactless mode of operation. For example, an exemplary reader may include a Radio Frequency (RF) antenna, an optical scanner, a barcode reader, or a magnetic stripe reader to interact with a payment device and/or a mobile device. The POS terminal may or may not initiate processing of the transaction.

The "authorization request message" may be a message requesting authorization for a specific event. For example, the authorization request message may request authorization to perform a payment transaction. In some embodiments, the authorization request message may conform to international organization for standardization (ISO)8583, ISO 8583 being a standard for systems that exchange electronic transaction information associated with payments made by consumers using payment devices or payment accounts. The authorization request message may include an issuer account identifier that may be associated with the payment device or the payment account. The authorization request message may also include additional data elements corresponding to "identification information," including (by way of example only): a service code, a CVV (card verification value), a dCVV (dynamic card verification value), an expiration date, etc. The authorization request message may also include "transaction information," such as any information associated with the mobile transaction, such as the transaction amount, merchant identifier, merchant location, etc., and any other information that may be used to determine whether to identify and/or authorize the transaction.

The "authorization response message" may be an electronic message reply to the authorization request message generated by the issuing financial institution or the payment processing network. The authorization response message may include (by way of example only) one or more of the following status indicators: approval-the transaction is approved; decline-transaction not approved; or call center-in response to waiting for more information, the merchant must call the toll free authorization phone number. The authorization response message may also include an authorization code, which may be a code indicating that the transaction is approved that the credit card issuing bank returned to the merchant's access device (e.g., POS device) in response to the authorization request message in the electronic message (either directly or through the payment processing network). The code may act as proof of authorization. As described above, in some embodiments, the payment processing network may generate or forward an authorization response message to the merchant.

An "authorizing entity" may be the entity that authorizes the request. Examples of authorized entities may be issuers, government agencies, document repositories, access administrators, and the like.

a "blockchain" may be a distributed database that maintains an ever-increasing list of records to protect against tampering and revision. The blockchain may include a plurality of interactive recording blocks. Each block in the blockchain may also include a timestamp and a link to a previous block. For example, each chunk may include or be appended to a hash of the last chunk. In other words, the transaction records in the blockchain may be stored as a series of "blocks" or permanent files that include records of several transactions that occur within a given time period. The block may be appended to the blockchain by an appropriate node after the block is completed and verified. In embodiments of the invention, the blockchain may be distributed and a copy of the blockchain may be maintained at each node in the verification network. Any node in the authentication network may then use the blockchain to authenticate the transaction. The security of the blockchain may be obtained using an encryption scheme. For example, individuals may be prevented from adding blocks to a blockchain unless they use an encryption algorithm to encrypt the blocks. The encryption algorithm may be a function that receives a message or hash and a cryptographic key, and then outputs an encrypted message.

a "credential" may include any evidence of a right (authority), right (right), or privileged right (entity to privilege). For example, an access credential may include a permission (permission) to access certain tangible or intangible assets, such as buildings or files. In another example, the payment credentials may include any suitable information associated with and/or identifying an account (e.g., a payment account and/or a payment device associated with the account). Such information may be directly related to the account, or may be derived from information related to the account. Examples of account information may include an "account identifier," such as a primary account number or "account number" (PAN), eID, token, sub-token, gift card number or code, prepaid card number or code, username, expiration date, Card Verification Value (CVV), dynamic card verification value (dCVV), card verification value 2(CVV2), CVC3 card verification value, and so forth. An example of a PAN is a 16-digit number, such as "4147090000001234". In some embodiments, credentials may be considered sensitive information.

An "electronic identity" or "eID" may be any suitable string of characters or symbols for identifying an entity (e.g., a person or device). In some embodiments, the electronic identity may be mathematically derived from information associated with the user. For example, in some embodiments, the electronic identity may be a value calculated by hashing one or more input values (e.g., name, country code, etc.) available to multiple entities. In this way, the electronic identity may be generated independently by any entity having prerequisite information. The electronic identity may be information associated with the user that is altered (e.g., hashed and/or encrypted). For example, in some embodiments, the electronic identity may be derived from a combination of the country code, name, date of birth, and the last four digits of a social security number, such as SHA256(USA × JOHN SMITH 19700101 × 1234). Hashing this value may produce a seemingly random string, such as 754WD2E2513BF546050C2D079FF5D65AB6E 318E. In some embodiments, the electronic identity is associated with a password that must be provided in order to access any interaction records associated with the electronic identity. Electronic identities may sometimes be referred to as "eids" or electronic identifiers.

A "token" can be any letter, number, and/or symbol, or combination thereof, that can be used to identify the presence of a condition or an action to be taken. For example, the token may be a check mark under a given transaction category. In another example, the indicia may be a code (e.g., "4111") corresponding to a particular transaction category, such as a merchant category code or merchant identifier.

A "portable device" is any device that can be used to initiate a transaction. In a payment context, for example, the portable device may be a credit card, debit card, gift card, electronic device (e.g., a communication device such as a mobile phone, wearable device, etc.) provided with payment credentials, and the like.

A "resource provider" may be an entity that may provide resources, such as goods, services, information, and/or access. Examples of resource providers include merchants, access devices, secure data access points, and the like. A "merchant" may generally be an entity that participates in a transaction and may sell or provide access to goods or services.

A "server computer" may include a powerful computer or cluster of computers. For example, a server computer may be a mainframe, a minicomputer cluster, or a group of servers that function as a unit. In one example, the server computer may be a database server coupled to a network server. The server computer may include one or more computing devices and may use any of a variety of computing structures, arrangements, and compilations to service requests from one or more client computers.

a "transaction processing computer" may include a network of one or more devices capable of processing and routing transaction request messages. An exemplary transaction processing computer may include data processing subsystems, networks, and operations to support and provide authorization services, exception file services, transaction scoring services, and clearing and settlement services. An exemplary transaction processing system may include VisaNet^TM. Such as VisaNet^TMetc. transaction processing systems are capable of processing credit card transactions, debit card transactions, and other types of commercial transactions. In particular, VisaNet^TMA VIP system (Visa integrated payment system) that processes authorization requests, and a Base II system that performs clearing and settlement services may be included.

I. Closed loop system

Many institutions employ closed-loop systems that require a user to maintain a dedicated institution card associated with an account maintained by the institution. For example, fig. 1 shows a block diagram of a conventional closed loop system. User 105 has three payment devices: a traffic card 110, a portable device 120, and a healthcare expense card 130.

The traffic card 110 may be used by the user 105 at a traffic access device 113 (e.g., gate, turnstile, etc.). For example, the user 105 may wave or touch the traffic card 110 at the traffic access device 113 to gain access to the traffic stop. The traffic access device 113 may initiate a debit of the traffic account 117 to obtain the cost of the traffic upon the user 105 entering the traffic stop or upon the user 105 exiting the traffic stop. The transit account 117 is held and operated by the transit agency 115. The transportation account 117 may hold subsidized funds and/or unpaid funds designated for transportation fees. The transportation facility 115 may be the operator of the transportation station and the issuer of the transportation card 110.

the healthcare expense card 130 can be used by the user 105 at a healthcare access device 133 (e.g., a POS device at a doctor's office). For example, the user 105 may wave or touch the healthcare expense card 130 at the healthcare access device 133 to pay for healthcare-related or medical expenses. The healthcare access device 133 can initiate a debit of the healthcare expenditure account 137 for healthcare-related expenses. The healthcare expenditure account 137 is held and operated by, for example, an insurance company 135. The healthcare expenditure account 137 may hold subsidy funds designated for healthcare expenses. The insurance company 135 may be the issuer of the healthcare expense card 130.

The portable device 120 may be used by the user 105 at a resource provider access device 123 (e.g., a POS device at the resource provider). For example, the user 105 may wave or touch the portable device 120 at the resource provider access device 123 to pay for the resource (e.g., goods, services, etc.). In some embodiments, portable device 120 may be a credit card or debit card. In some embodiments, portable device 120 is a communication device equipped with a payment account. The resource provider access device 123 may initiate a debit of the primary account 127 for the resource fee. The primary account 127 is held and operated by, for example, an authorization entity 125. The primary account 127 may hold unpaid funds that may be used for any purpose. The authorized entity 125 may be an issuer associated with the portable device 120.

As shown in fig. 1, user 105 needs three separate cards: a transportation card 110 for accessing and paying transportation services, a healthcare expense card 130 for paying healthcare fees, and a portable device 120 for paying general fees. The transportation card 110 is not available at the resource provider access device 123 or the healthcare access device 133 and the healthcare expense card is not available at the transportation access device 113 or the resource provider access device 123. While the portable device 120 may also be used to pay transportation services (e.g., at the transportation access device 113) and/or healthcare fees (e.g., at the healthcare access device 133) in some instances, the user 105 may prefer to pay such fees using the transportation card 110 and/or the healthcare expense card 130 because funds in their associated account may be subsidized (e.g., paid or taxed by the employer). The primary account 127 may only hold unpaid funds in conventional systems.

FIG. 2 illustrates a flow chart of a conventional method for funding a closed-loop transit card 110 in a closed-loop system (steps S205-S260) and processing a transaction using the closed-loop transit card 110 (steps S265-S290). At step S205, the user 105 accesses the portable device 120 to fund the transportation card 110. The portable device 120 may be, for example, a credit card or a debit card. In some examples, portable device 120 may be a communication device (e.g., a mobile device) equipped with a payment account.

At step S210, the portable device 120 is provided to the transportation facility 115 as a funding source to add an amount of funds to the transportation card 110. At step S215, the transportation facility 115 generates an authorization request message for the amount of funds, and includes details received from the portable device 120 (e.g., primary account number, verification value, expiration date, etc.). At step S220, the transportation facility 115 sends an authorization request message to the transfer computer 140, which may be, for example, a bank associated with the transportation facility 115. The transfer computer 140 forwards the authorization request message to the transaction processing computer 150 at step S225. At step S230, the transaction processing computer 150 forwards the authorization request message to the authorizing entity 125. The authorized entity 125 may be an issuer associated with the portable device 120.

At step S235, the authorizing entity 125 determines whether the transaction is authorized (e.g., whether sufficient funds exist in an account associated with the portable device 120), and generates an authorization response message. At step S240, the authorizing entity 125 sends an authorization response message to the transaction processing computer 150. At step S245, the transaction processing computer 150 sends an authorization response message to the transmitting computer 140. At step S250, the transmitting computer 140 forwards the authorization response message to the transportation facility 115. If the authorization response message indicates that the transaction is authorized, the transit agency 115 loads the amount of funds on the transit card 110 at step S255. At step S260, the user 105 is notified that funds have been successfully loaded on the transportation card 110 for use by the user 105. Although shown and described as the user 105 funding the transportation card 110, it is contemplated that a third party (e.g., an employer) may actually funding the transportation card 110 for use by the user 105 according to a similar approach.

thereafter, at step S265, the user 105 accesses the transportation card 110 to gain access to transportation services. At step S270, the user 105 uses the traffic card 110 at the traffic access device 113 (e.g., by waving or touching the traffic card 110 at a gate or turnstile). At step S275, the transit access device 113 generates an internal authorization request with the identifier of the transit card 110 and the calculated fare for the user 105 and sends the internal authorization request to the transit agency 115. At step S280, the transit agency 115 debits the transit account associated with the transit card 110 for the fare. If the fee is successfully unloaded from the transit card 110, the transit agency 115 sends a success message to the transit access device 113 at step S285. At step S290, the traffic access device 113 may allow the user 105 to access the traffic service (e.g., by opening a gate).

Thus, closed loop systems such as those used by transportation facilities have a number of drawbacks. For example, a dedicated transit card associated with an account maintained by a transit agency is required. In order to recharge the transit card, an open loop payment must be made (i.e., through a conventional payment system, including a payment processing network and an issuer) using another portable device, such as a credit card, debit card, or a provided communication device. When the transit card is used, a closed loop payment may then be used to deduct a fee (i.e., by the transit agency) from the balance associated with the transit card. Thus, not only are two separate cards required to fund and use a transit system (e.g., a transit card and a credit card), but two separate processes must be used to fund (open loop) and use (closed loop) a transit card. In addition, any non-subsidized funds added to the transportation card are typically not refundable, even if they are not used.

Double open-loop-closed-loop system

Embodiments of the present invention improve upon conventional closed-loop systems by providing a dual open-closed-loop system that can take advantage of limited and unrestricted open or normal transaction processing. The indicia associated with the transaction may be used to determine a usage category for the resource (e.g., unlimited or restricted funds). In one example, the designated subsidized funds may be used with restrictions on using traditional portable devices or vouchers without requiring the accumulation of subsidized and unpaid funds. Thus, a single portable device may be used to access both open funds and restricted funds. Additionally, the required processing power is reduced compared to traditional traffic system models, for example, because the transaction processor can maintain a blockchain to certify transactions on traffic accounts rather than on traffic agencies. This may allow the transit agency to immediately verify the transaction and account balance.

FIG. 3 shows a block diagram of a system for dual transaction processing according to an embodiment of the invention. The system includes a portable device 120, an access device 135, a resource provider computer 137, a transmission computer 150, a transaction processing computer 150, a master authorization entity computer 125, a first authorization entity computer 365A, a second authorization entity computer 365B, a third authorization entity computer 365C, and a multiple access blockchain 370. Each of these entities may communicate with each other, for example, over a network.

In use, a user (not shown) may operate the portable device 120. For example, the user may wave, touch, or shake the portable device 120 at the access device 135. The access device 135 may be any access device including the traffic access device 113, the resource provider access device 123, the healthcare access device 133, and/or the like. The portable device 120 may interact with the access device 135 to initiate a transaction.

The access device 135 may be any device that provides access to a resource. The access device 135 may be generally located at any suitable location, such as at a resource provider location. The access device 135 may take any suitable form. Examples include POS devices, cellular phones, PDAs, Personal Computers (PCs), tablets, handheld application specific readers, set-top boxes, Electronic Cash Registers (ECRs), Automated Teller Machines (ATMs), Virtual Cash Registers (VCRs), kiosk machines, security systems, access systems, websites, and the like. The access device 135 may transmit or receive data from or associated with a portable device (e.g., portable device 120) using any suitable contact or contactless mode of operation. In some embodiments where the access device 135 may comprise a POS terminal, any suitable POS terminal may be used and may include a reader, processor, and computer-readable medium. The reader may include any suitable contact or contactless mode of operation. For example, an exemplary card reader may include a Radio Frequency (RF) antenna, an optical scanner, a bar code reader, or a magnetic stripe reader for interacting with a portable device (e.g., portable device 120).

In some embodiments, the access device 135 may be part of or in communication with a resource provider computer 137. The resource provider computer 137 may be a computer associated with any resource provider, such as a merchant, transportation facility, insurance company, visiting operator, and/or the like. This computer may be configured to receive transaction data from the access device 135. For example, the resource provider computer 137 may enable a resource provider (e.g., a merchant) to participate in transactions, sell goods or services, or provide consumers with access to goods or services. The computer may accept multiple forms of payment and may use multiple instruments to conduct different types of transactions. For example, the resource provider computer 137 may communicate with, include, or be the access device 135 at a brick and mortar store operated by the resource provider for personal transactions. The resource provider computer 137 may also enable the resource provider to sell goods and/or services via a website and may accept payments over the internet. The access device 135 may include a server computer to facilitate the performance of the transaction processing functions described herein. The server computer may include a processor and a computer-readable medium coupled to the processor, the computer-readable medium including code executable by the processor.

Once the transaction has been initiated with the portable device 120, the access device 135 and/or the resource provider computer 137 may generate an authorization request message for the transaction. The authorization request message may include credentials associated with the portable device 120 (e.g., an account number), a transaction amount, and an indication specifying a transaction category (e.g., transportation, healthcare, clothing, food, etc.). In some embodiments, the credential may be an electronic identifier (eID). The eID may be a universal identifier (containing any combination of letters, numbers, and/or symbols) that uniquely identifies an individual. eID may be used instead of an account number to make the transaction more secure. For example, by using eIDs instead, the Primary Account Number (PAN) of a portable device may be protected from interception and/or fraud by unauthorized parties, thereby eliminating the need for sensitive information to be transmitted over the network by multiple parties.

The resource provider computer 137 may forward the authorization request message to the transport computer 140. The resource provider computer 137 may include a server computer to facilitate performance of the transaction processing functions described herein. The server computer may include a processor and a computer-readable medium coupled to the processor, the computer-readable medium including code executable by the processor.

In some embodiments, a transmission computer 140 is provided between the access device 135 and the transaction processing computer 150. The transmission computer may be associated with a purchaser. A "buyer" can generally be a business entity (e.g., a business bank) that has a business relationship with a particular resource provider (e.g., a merchant, transportation facility, insurance company, healthcare provider, etc.) or other entity. In some embodiments, a transport computer 140 is not provided. Some entities may perform the functions of both the issuer and the purchaser. Some embodiments may encompass such a single entity issuer-purchaser. The transfer computer 140 is configured to route authorization request messages from the access device 135 to the transaction processing computer 150. The transport computer 140 may include a server computer to facilitate performance of the transaction processing functions described herein. The server computer may include a processor and a computer-readable medium coupled to the processor, the computer-readable medium including code executable by the processor.

The transaction processing computer 150 may be associated with one or more payment service providers. The transaction processing computer 150 may be configured to determine the appropriate authorizing entity computer 365A, 365B, 365C, 125 associated with the credentials and/or flags in the authorization request message and route the authorization request message to the authorizing entity computer 365A, 365B, 365C, 125. The transaction processing computer 150 may also include a server computer. The server computer may include a processor and a computer-readable medium coupled to the processor, the computer-readable medium including code executable by the processor.

In use, the transaction processing computer 150 may receive an authorization request message that includes a value (e.g., transaction amount), a credential (e.g., PAN), and a token. In some embodiments, the flag may be, for example, a code (e.g., "4111") corresponding to a particular transaction category (e.g., traffic). In some embodiments, the indicia may be, for example, a merchant identifier that uniquely identifies the merchant. The associated transaction category may be determined using the merchant identifier. In some embodiments, the flag may be included in an existing field (e.g., a merchant category code field) of the authorization request message, such that no changes to the structure of the existing authorization request message are required.

the transaction processing computer 150 may determine that a flag is included in the request and, in response, determine the identity of the authorized entity computer required to process the transaction. The flag may be used by the transaction processing computer 150 to determine whether the transaction is: (1) a closed loop transaction that is carried forward to an open loop transaction (if needed), or (2) an open loop transaction. For example, if the flag is a category code indicating traffic, the transaction processing computer 150 may access a lookup table stored in a database to identify the first authorized entity computer 365A, which may be a closed loop transit agency, as being associated with the category code. In another example, if the flag indicates healthcare, the transaction processing computer 150 may identify a second authorized entity computer 365B, which may be a closed loop insurance company. In yet another example, if the flag indicates a particular resource provider, the transaction processing computer 150 may identify a third authorized entity computer 365C that may be associated with the closed loop resource provider. If insufficient funds are present in the closed loop account, the remainder of the transaction may be run as an open loop transaction, as described further herein.

Otherwise, in some embodiments, if the flag is not associated with the first, second or third authorizing entity computer 365A, 365B or 365C, or if the flag is not present in the authorization request message, the transaction processing computer 150 may identify the open-loop master authorizing entity computer 125. The master authorizing entity computer 125 may be identified based on the credentials included in the authorization request message (i.e., the master authorizing entity computer 125 may be associated with the issuer of the credentials). The identification may be made by searching a lookup table in the database for the BIN included in the credential to determine the identity of the master authorized entity computer 125.

If the authorizing entity is identified as a first authorizing entity computer 365A, a second authorizing entity computer 365B, or a third authorizing entity computer 365C, the transaction processing computer 150 can verify that the transaction can be processed by the first authorizing entity computer 365A, the second authorizing entity computer 365B, or the third authorizing entity computer 365C (e.g., the user and/or credentials are enrolled in a closed-loop processing program and/or hold an account for the first authorizing entity computer 365A, the second authorizing entity computer 365B, or the third authorizing entity computer 365C).

In some embodiments, the transaction processing computer 150 may also, in some embodiments, convert fields of the authorization request message into data and/or formats usable by the first, second or third authorization entity computers 365A, 365B, 365C, as further described herein. The transaction processing computer 150 may transmit the converted data to the first, second or third authorizing entity computer 365A, 365B, 365C.

At the same time, transaction processing computer 150 may update multiple access block chain 370 with the transaction data. Multiple access block chain 370 may store data representing multiple interactions (e.g., transactions) between multiple authorized entities and multiple users. The transaction processing computer 150 may calculate from the multiple access blockchain 370 the balance held by the user for the identified authorizing entity computer (e.g., the first authorizing entity computer 365A). The transaction processing computer 150 may make this calculation by summing all transactions associated with an account number representing the user's account with the identified authorizing entity computer, as further described herein. The balance may be calculated as all unspent transaction outputs (UTXOs) on the user account, i.e., all transfers into the user account that have not been used in the transfer out of the user account.

if the balance is greater than or equal to the transaction value, then the transaction processing computer 150 may create an entry in the multiple access block chain 370 that records the transaction for the transaction value. Thus, the transaction processing computer 150 may create an entry in the multiple access block chain 370 that results in a decrement of the balance. In some embodiments, the first, second, and/or third authorization entity computers 365A, 365B, 365C may create an entry in the multiple access block chain 370 that results in an increment in the balance (e.g., withdraw, return, credit, etc.).

As shown, it is contemplated that a single multiple access blockchain 370 may be implemented by and accessible to a first, second and third authorizing entity computers 365A, 365B, 365C. In these embodiments, it is contemplated that different data corresponding to different authorized entity computers may be distinguished by the data included in the blockchain. For example, a single block chain may be maintained per credential across multiple authorized entity computers holding different balances, with a particular authorized entity computer and a particular balance being identified in each block. Further, it is contemplated that in some embodiments, different authorized entity computers may access blocks that they are not associated with (e.g., a first authorized entity computer 365A may access blocks related to transactions with a second authorized entity computer 365B). However, in other embodiments, it is contemplated that the multiple access blockchain 370 may actually be separate such that each authorized entity computer accesses its own blockchain, with the transaction processing computer 150 accessing all of the blockchains.

If the authorizing entity is identified as the master authorizing entity computer 125, the transaction processing computer 150 may forward the authorization request message to the master authorizing entity computer 125. The master authorization entity computer 125 may communicate with the transaction processing computer 150 to conduct transactions. The master authorization entity computer 125 may also write the decrement to the multiple access block chain 370.

the master authorization entity computer 125 is typically run by a business entity (e.g., a bank) that can issue portable devices 120, credentials, or payment tokens for transactions. Some systems may perform the functions of the master authorization entity computer 125 and the transport computer 140. When the transaction involves a payment account associated with the master authorizing entity computer 125, the master authorizing entity computer 125 may verify the account and verify the funds available in the account. The master authorizing entity computer 125 may respond to the transaction processing computer 150 with an authorization response message that may be forwarded to the transfer computer 140, the resource provider computer 137, the access device 135, and the portable device 120 (if applicable). The master authorizing entity computer 125 may comprise a server computer. The server computer may include a processor and a computer-readable medium coupled to the processor, the computer-readable medium including code executable by the processor.

At a later time (e.g., at the end of the day), clearing and settlement processes may occur between the transfer computer 140, the transaction processing computer 150, and the master authorizing entity computer 125. Conventional clearing and settlement processes may not need to occur for the first, second and/or third authorizing entity computers 365A, 365B, 365C because they are closed loop systems.

As an example, the access device 135 may be a traffic access device 113. The user may wave or touch the portable device 120 at the traffic access device 113 to gain access to the traffic stop. The calculated cost may be $ 2. The traffic access device 113 may generate an authorization request message using a credential (e.g., PAN), a transaction value ($2), and a flag (e.g., a code representing traffic) associated with the portable device 120. The traffic access device 113 may transmit the authorization request message to a resource provider computer 137 (e.g., a transportation facility computer). The resource provider computer 137 may transmit the authorization request message to the transport computer 140. The transmission computer 140 may transmit the authorization request message to the transaction processing computer 150.

The transaction processing computer 150 may determine that the token is present and that the token is associated with traffic. For example, the flag may exist as a merchant category code "4111" in the authorization request message. The transaction processing computer 150 may access a look-up table in the database that correlates the merchant category code "4111" with traffic.

The transaction processing computer 150 may also identify the first authorizing entity computer 365A as being associated with traffic. For example, the transaction processing computer 150 may access a lookup table in a database relating traffic to the first authorized entity computer 365A. In some embodiments, the transaction processing computer 150 may combine these two steps. For example, the transaction processing computer 150 may determine that the token is present and that the first authorized entity computer 365A is associated with the token. For example, the flag may exist as a merchant category code "4111" in the authorization request message. The transaction processing computer 150 may access a look-up table in the database relating the merchant category code "4111" to the first authorizing entity computer 365A.

In another example, the token may exist as a merchant identifier in the authorization request message. The entity may register with the transaction processing computer 150 so as to be assigned a unique merchant identifier. When the entity initiates the transaction, the unique merchant identifier may be included in the authorization request message and may be extracted by the transaction processing computer 150. The transaction processing computer 150 may access a lookup table in the database that correlates unique merchant identifiers to specific categories (e.g., traffic) and/or specific authorizing entity computers 365A (e.g., first authorizing entity computer 365A).

The transaction processing computer 150 may also determine that the credentials included in the authorization request message hold an account with the first authorizing entity computer 365A. For example, the transaction processing computer 150 may access a lookup table in a database that stores credentials in conjunction with one or more closed-loop account identifiers (e.g., an account number associated with and unique to the first authorized entity computer 365A, which may be different from the credentials). Thus, the transaction processing computer 150 may forward the authorization request message to the first authorizing entity computer 365A. The transaction processing computer 150 may also create an entry in the multiple access blockchain 370 that records the transaction. For example, the transaction processing computer 150 may record the transaction in a new block in the multiple access blockchain 370 and a decrement of $2 reflected in the transaction (e.g., decrease the UTXO by $2) relative to the first authorizing entity computer 365A.

As shown in fig. 3, the user only needs one card: portable device 120 for paying for closed loop purchases (e.g., traffic, healthcare, etc.) and open loop purchases (e.g., general fees). The portable device 120 may also be used at a plurality of closed loop and open loop access devices, such as a traffic access device 113, a resource provider access device 123, and/or a healthcare access device 133.

For simplicity of illustration, a certain number of components are shown in FIG. 3. However, it should be understood that embodiments of the invention may include more than one of each component. Additionally, some embodiments of the invention may include fewer or more than all of the components shown in FIG. 4. In addition, the components in FIG. 3 may communicate over any suitable communication medium, including the Internet, using any suitable communication protocol.

Fig. 4 illustrates a block diagram of a transaction processing computer 400 according to some embodiments of the invention. For example, the transaction processing computer 400 may be the transaction processing computer 150 of FIG. 3, which provides transaction processing and forwarding services for a plurality of users and a plurality of authorized entities. The transaction processing computer 400 may include a processor 401 coupled to a network interface 402 and a message coordination engine 406. The message coordination engine 406 may be recorded on a computer-readable medium. The transaction processing computer 400 may also include or otherwise have access to a database 403 that may be internal or external to the transaction processing computer 400.

The processor 401 may include one or more microprocessors to execute program components for performing the open-loop and closed-loop transaction processing functions of the transaction processing computer 400. The network interface 402 may be configured to connect to one or more communication networks to allow the transaction processing computer 400 to communicate with other entities, such as a transport computer, a multiple access block chain, an authorizing entity, and so on. The message coordination engine 406 may be implemented on any combination of one or more volatile and/or non-volatile memories, such as RAM, DRAM, SRAM, ROM, flash memory, or any other suitable memory component. The message coordination engine 406 may include code executable by the processor 401 for implementing some or all of the transaction processing and routing functions of the transaction processing computer 400. For example, the message coordination engine 406 may include code that implements the authentication engine 410, the message routing engine 415, and the translation engine 420.

in use, the authorization request message 421 is received from an entity (e.g., a transmitting computer) at the transaction processing computer 400 and routed to the authentication engine 410. Authentication engine 410 may, in conjunction with processor 401, extract credentials (or any other identifying information) from authorization request message 421. The authentication engine 410 may be coupled with the processor 401 to determine whether the credential is enrolled in a closed-loop process and/or holds an account of a closed-loop authorization entity. For example, the authentication engine 410 may extract PAN "1234567890123456" from the authorization request message 421. The authentication engine 410 may then, in conjunction with the processor 401, access a lookup table in the database 403 that includes a list of credentials and an indication of whether each credential is enrolled in a closed-loop process, which closed-loop authorized entities accounts each credential has, and/or the like.

Fig. 5 illustrates a block diagram of an authentication engine 500 according to some embodiments of the invention. Authentication engine 500 may be implemented, for example, as authentication engine 410 of fig. 4. As shown in fig. 5, the authentication engine 500 may include a look-up table 505. The lookup table 505 may include a list of credentials and an indicator of whether each credential is eligible for closed loop processing. Although shown as a lookup table, it is contemplated that the credentials (and/or other identifying information) and their associated enrollment information may be stored or accessed by the authentication engine 500 in any format.

Turning back to fig. 4, the authentication engine 410 may transmit an indicator 422 of whether the credential is eligible for closed loop processing to the message routing engine 415 along with the authorization request message. Fig. 6 illustrates a block diagram of a message routing engine 600 according to some embodiments of the invention. Message routing engine 600 may be implemented, for example, as message routing engine 415 of fig. 4. As shown in fig. 6, the message routing engine 600 may include a closed-loop transaction identification module 605, an open-loop transaction identification module 610, a hybrid transaction identification module 615, and an authorizing entity identification module 620. The closed-loop transaction identification module 605, the open-loop transaction identification module 610, the hybrid transaction identification module 615, and the authorizing entity identification module 620 may comprise code executable by the processor 401 for performing some or all of the functions described herein.

The closed loop transaction identification module 605 may be configured to determine whether a particular authorization request message is associated with a closed loop transaction. For example, the closed loop transaction identification module 605 may extract a flag from the authorization request message. The flag may be, for example, a code (e.g., "4111") corresponding to a particular transaction category (e.g., traffic). The flag may be included in an existing field of the authorization request message (e.g., a merchant category code field) so that no changes to the structure of the existing authorization request message are required. In some embodiments, the closed-loop transaction identification module 605 may determine that the transaction is a closed-loop transaction based on the presence of the flag in the authorization request message (i.e., if any flag is present, then the transaction is a closed-loop transaction). In some embodiments, the closed loop transaction identification module 605 may determine that the transaction is a closed loop transaction based on the data included in the flag (i.e., some data such as "1" or some value such as "4111" may indicate a closed loop transaction, while other data such as "0" or some value such as "open" may indicate an open loop transaction).

The open loop transaction identification module 610 may be configured to determine whether a particular authorization request message is associated with an open loop transaction. For example, the open-loop transaction identification module 610 may attempt to extract a flag from the authorization request message. In some embodiments, the open-loop transaction identification module 610 may determine that the transaction is an open-loop transaction based on the absence of a flag in the authorization request message (i.e., if no flag is present, then the transaction is an open-loop transaction). In some embodiments, the open-loop transaction identification module 610 may determine that the transaction is an open-loop transaction based on data included in the flag (e.g., certain data such as "no," "0," "1400," etc. may indicate an open-loop transaction). In some embodiments, the open-loop transaction identification module 610 may automatically determine that the authorization request message is associated with an open-loop transaction if the closed-loop transaction identification module 605 determines that the authorization request message is not associated with a closed-loop transaction. In some embodiments, this determination may be made by the closed loop transaction identification module 605 and the open loop transaction identification module 610 may be omitted.

The hybrid transaction identification module 615 may be configured to determine whether a particular authorization request message is associated with a hybrid open-loop and closed-loop transaction. For example, a user may purchase prescriptions and magazines at a pharmacy. Prescriptions may be qualified for closed loop processing from a health savings account, while magazines are only qualified for open loop processing from a general account. Accordingly, an authorization request message may be generated that includes flags indicating both closed-loop and open-loop processing, where each flag has an associated value (e.g., $10.00 for a prescription via closed-loop processing and $3.99 for a magazine via open-loop processing). This is advantageous because only one authorization request message is required to process a hybrid transaction of two separate parts of a single account, thereby improving efficiency and resource usage.

in another example, a hybrid transaction may be generated for additional closed-loop transactions in which closed-loop accounts are insufficient funds. In this example, the remaining closed loop funds (e.g., $6 of $9 in the traffic cost) may be utilized first, with the balance being taken from the open loop funds (e.g., $3 of the traffic cost remaining). In the latter example, the authorization request message may not include a flag indicating both closed-loop and open-loop transactions. In practice, the authorization request message may include a flag indicating a closed loop transaction, and upon identification of the closed loop authorizing entity and the account, a determination may be made that insufficient funds are available in the closed loop account. The hybrid transaction identification module 615 may mark the transaction as a hybrid transaction.

The authorizing entity identification module 620 may be configured to receive an indication of whether the authorization request message relates to an open-loop and/or closed-loop transaction from the closed-loop transaction identification module 605, the open-loop transaction identification module 610, and/or the hybrid transaction identification module 615. The authorizing entity identification module 620 may be configured to determine the identity of the authorizing entity computer needed to process the transaction. For example, if the flag indicates traffic, the authorization entity identification module 620 may identify a particular closed-loop authorization entity computer that may be operated by the transit agency by querying a lookup table stored in a database, as further described herein. If the flag indicates healthcare, the authorizing entity identification module 620 may identify another particular closed-loop authorizing entity computer that may be operated by the insurance company. If the transaction is indicated as an open loop transaction (and/or no flag is present in the authorization request message), the authorization entity identification module 620 may identify the master authorization entity computer associated with the credentials included in the authorization request message. In a hybrid transaction (e.g., a transaction with multiple tokens), the authorizing entity identification module 620 can identify a closed-loop authorizing entity that uses the tokens and an open-loop authorizing entity that uses the credentials. For example, the authorization entity identification module 620 may identify a closed-loop authorization entity by querying a lookup table stored in a database, as further described herein, and may identify an open-loop authorization entity by extracting a BIN from the credential and retrieving its identity from the database using the BIN.

Turning back to FIG. 4, if the transaction (or a portion of the transaction) is an open loop transaction, the authorization request message 424 may be routed to the appropriate host authorization entity computer. The message routing engine 415 may also route the authorization request message 428 to the blockchain docket engine 425 to post the decrement to the blockchain and master authorization entity computer associated with the credential, as discussed further herein. If the transaction (or a portion of the transaction) is a closed-loop transaction, the authorization request message 423 along with the identified closed-loop authorization entity may be routed to the conversion engine 420.

FIG. 7 illustrates a block diagram of a translation engine 700 according to some embodiments of the invention. The translation engine 700 may be implemented by, for example, the translation engine 420 of fig. 4. The transformation engine 700 may include a digital asset exchange module 705 and a credential exchange module 710.

Digital asset exchange module 705 may be configured to receive the authorization request message and extract the value of the transaction (e.g., $ 15). Based on the identity of the closed-loop authorizing entity received from the message routing engine, the digital asset exchange module 705 may convert from the currency used in the authorization request message to the currency used by the closed-loop authorizing entity using a look-up table or applying stored rules. For example, the authorization request message may include $15, which may be associated with two one-way commute fees. Accordingly, digital asset exchange module 705 may convert "$ 15" to "2". It is contemplated that in some embodiments, the closed-loop authorization entity may use the same currency (e.g., U.S. dollars) as used in the authorization request message. In these embodiments, the digital asset exchange module 705 may be omitted.

The credential exchange module 710 may be configured to receive the authorization request message and extract credentials for the transaction. Based on the identity of the closed-loop authorizing entity received from the message routing engine, the credential exchange module 710 may convert the credential into an account identifier used by the closed-loop authorizing entity using a lookup table or applying stored rules. In some embodiments, the account identifier may be identified using other information included in the authorization request message, such as the user's name, instead of or in addition to the credentials. In some embodiments, the closed-loop authorization entity may use the credential as an account identifier. In these embodiments, credential exchange module 710 may be omitted.

Turning back to fig. 4, once the credentials and/or values in the authorization request message 423 have been converted, the authorization request message 423 may be updated with the converted values and the authorization request message 425 may be transmitted to the appropriate closed-loop authorization entity. The authorization request message 426 may also be transmitted to the blockchain docket engine 425 to post the transaction 427 to the blockchain and closed-loop authorizing entity computers associated with the account identifier, as discussed further herein. Transaction 427 may indicate a decrement (e.g., a decrease in UTXO). In some embodiments, the blockchain may be maintained with the converted credentials and/or values. In some embodiments, the blockchain may be maintained with the original credential and/or value.

Figure 8 shows a block diagram of a first authorizing entity computer 800 according to some embodiments of the present invention. For example, the first authorizing entity computer 800 may be any of the first authorizing entity computer 365A, the second authorizing entity computer 365B, or the third authorizing entity computer 365C of fig. 3, which may act as an issuer of a closed loop account associated with a user. The first authorized entity computer 800 may include a processor 801 coupled to a network interface 802 and a computer-readable medium 806. The first authorized entity computer 800 may also include or otherwise have access to a database 803, which may be internal or external to the first authorized entity computer 800.

The processor 801 may include one or more microprocessors to execute program components for performing the authorization functions of the first authorization entity computer 800. The network interface 802 may be configured to connect to one or more communication networks to allow the first authorized entity computer 800 to communicate with other entities, such as a transaction processing computer, a multiple access blockchain, and so forth. The computer-readable medium 806 may include any combination of one or more volatile and/or nonvolatile memories, such as RAM, DRAM, SRAM, ROM, flash memory, or any other suitable memory component. The computer readable medium 806 may store code executable by the processor 801 for implementing some or all of the authorization functions of the first authorization entity computer 800. For example, the computer-readable medium 806 may include code that implements the authorization module 810 and the blockchain update module 815.

The authorization module 810 may receive, in conjunction with the processor 801, an authorization request message from the transaction processing computer that includes an account identifier and a value. The authorization module 810 may, in conjunction with the processor 801, access the multiple access block chain associated with the account identifier and determine whether there is a sufficient balance in the account to decrement the value. If there is a sufficient balance, the authorization module 810 may authorize the transaction in conjunction with the processor 801 and transmit instructions to the transaction processing computer to update the blockchain with the decrement. In some embodiments, the authorization function may instead be performed by the transaction processing computer, which may determine whether there are sufficient funds available in the blockchain and deliver the decrement to the account without further input from the first authorizing entity computer 800.

The blockchain update module 815 may be coupled with the processor 801 to post an increment to an account on the multi-access blockchain associated with the account identifier. Such increments may include returns, withdrawals, credits, deposits, transfers, wire transfers, combinations thereof, and the like. The increments may be added to the blockchain by any method, such as by payment into a closed loop account from a primary account or an open loop account.

Fig. 9 illustrates a block diagram of a multiple access block chain 970, according to some embodiments of the invention. The multiple access block chain 970 may be used, for example, to implement the multiple access block chain 370 of fig. 3. The multiple access block chain 970 illustrates three consecutive blocks in an exemplary block chain: block 902, block 908, and block 914. The block chain 970 may be an ordered linked list of blocks. Each block 902, 908, 914 may be a data structure aggregated for transactions included in blockchain 970. Each block may include a header and a list of transactions. For example, block 902 may include a header 904 and a transaction 906. Block 908 may include a header 910 and a transaction 912. Block 914 may include a header 916 and a transaction 918.

The headers 904, 910, 916 may include at least three sets of metadata: previous block header hash, timestamp, and merkle root. The previous block header hash may connect each block to the previous block. For example, in header 910 of block 908, "00000 fh 5689" may be a hash of header 904 of block 902. In other words, the cryptographic hash algorithm (e.g., SHA256) may be applied to header 904 any number of times to obtain a value of "00000 fh5689," which may be included in header 910 of block 908. The timestamp may be the creation time of the block. For example, block 908 may have been created at 5:43:36 PM on 1 st 4 months in 2017. The merkle root may be a hash of the root of the merkle tree for each block of transactions. The merkle tree may be an overview of all transactions in a block constructed by hashing node pairs until there is only one hash. The last remaining hash is the merkle root.

Transactions 906, 912, 918 may include at least three sets of metadata per transaction: input, amount, and output. Transactions 906, 912, 918 may be data structures that encode transitions of values from input and output. In some embodiments, multiple inputs and/or multiple outputs may be specified. The input may be the source of the value to be transferred. The amount may be a value to be transferred. The output may be the destination of the value to be transferred. A previously unspent output to the multiple access blockchain 970 (i.e., a value from an entity or user to the multiple access blockchain 970 that has not been used elsewhere as an input) may result in an unspent transaction output (UTXO). This UTXO may be used as an input from the multiple access block chain 970 to other entities or users. As shown in fig. 9, there may not be a cumulative balance maintained by the multiple access block chain 970; in fact, the available balance may be spread across multiple transactions and multiple blocks as a UTXO.

For example, the transaction 906 may include a single transaction sent from the user's closed-loop transit account to a first authorized entity computer (e.g., operating a transit agency) in an amount of $ 10.11. Transaction 912 may include a single transaction sent from the user's closed loop transit account to the first authorizing entity computer in an amount of $ 5.40. The transaction 918 may include two transactions: a first transaction sent from the user's closed loop transit account to the first authorizing entity computer in an amount of $4.60, and a second transaction sent from the user's primary account (e.g., open loop account) to the first authorizing entity computer in an amount of $ 3.00. The transaction 918 may result, for example, from an insufficient UTXO in the traffic account block chain, resulting in a balance of traffic charges being drawn from the primary account.

Although only the transaction of decrementing the UTXO for the user's blockchain is illustrated in fig. 9, it is contemplated that the transaction of incrementing the UTXO may be similarly delivered to the user's blockchain. The incrementing may include similar headers with similar types of metadata. However, the transaction metadata may be revoked. For example, the transaction input may be an entity funding the blockchain (e.g., a transportation facility), and the transaction output may be associated with the user (e.g., the user's transportation account). The transaction amount may be the amount of UTXO added to the blockchain.

Implementing the multiple access block chain 970 in the disclosed embodiment in place of a conventional database has a number of advantages. The multiple access blockchain 970 may allow decentralized and/or shared control of blockchains. For example, as shown in FIG. 3, multiple authorizing entity computers and/or transaction processing computers may all have access to the blockchain, allowing each entity to verify transactions on multiple accounts that may be related. For example, a transit agency requiring a $5 fee may confirm that an additional $2 has been decremented from the user's open loop account if there is only $3 in the user's transit account. This allows for transparency and ecosystem simplification between entities by adding all transactions to a single blockchain. This spreading also prevents malicious attacks because the multiple access blockchain 970 has no central point of failure. In addition, data written to the multiple access block chain 970, once written, cannot be changed, replaced, and/or updated, thereby reducing the likelihood of fraud and errors. The multiple access blockchain 970 may also allow for faster transactions (e.g., by reducing clearing and settlement time to minutes rather than days) and lower transaction costs (e.g., by eliminating third party intermediary and overhead costs).

FIG. 10 illustrates a flow diagram of a method for dual transaction processing according to some embodiments of the invention. The method may be performed by the portable device 120, the access device 135, the resource provider computer 137, the transmission computer 140, the transaction processing computer 150, the multiple access blockchain 370, the first authorizing entity computer 365, and the master authorizing entity computer 125. The first authorizing entity computer 365 may be implemented as any of the first authorizing entity computer 365A, the second authorizing entity computer 365B, and/or the third authorizing entity computer 365C.

In step S1005, the user may access the portable device 120 and may interact with the access device 135 using the portable device 120. For example, the portable device 120 may be swiped, rocked, or touched at the access device 135. The access device 135 may be any access device, including any of the access devices described herein (e.g., the traffic access device 113, the resource provider access device 123, the healthcare access device 133, etc.). The interaction may be, for example, a request for a transaction between the user and the first authorized entity computer 365.

At step S1010, the access device 135 may generate an authorization request message for the transaction and transmit the authorization request message to the resource provider computer 137. The authorization request message may include at least a first value (e.g., transaction amount, fee amount, etc.), credentials associated with the portable device 120 (e.g., account number), and a flag. In some embodiments, the credential may be an eID. The flag may specify a category of the transaction (e.g., traffic, healthcare, resource provider identifier, resource provider type, etc.). The indicia may be generated by the access device 135 based on the type of access device (e.g., traffic access device, healthcare access device, etc.), the type of goods or services for which it is orthogonal (e.g., doctor's visit, traffic costs, etc.), and the like. In some embodiments, the flag may be omitted from the authorization request message unless it corresponds to a particular category (e.g., a subsidy portion such as traffic or healthcare, or another restricted portion such as a certain resource provider, etc.) that may provide closed loop processing. In some embodiments, the authorization request message generated by the access device 135 may omit the flag, and the flag may be provided by another entity, such as the resource provider computer 137 or the transaction processing computer 150. The flag may be provided in a certain category (e.g., 0 or 1) or as a code in a certain field (e.g., "4112") indicating a particular category. In some embodiments, the flag may be provided in an existing authorization request message field, such as a Merchant Category Code (MCC), a Merchant Verification Value (MVV), a service indicator, combinations thereof, and/or the like.

At step S1015, the resource provider computer 137 may send an authorization request message to the transport computer 140. At step S1020, the transmission computer 140 may forward the authorization request message to the transaction processing computer 150. In some embodiments, the flag may be omitted from the authorization request message received by the transaction processing computer 150. In some embodiments, the transaction processing computer 150 may determine whether and/or which indicia should be included and/or modify the authorization request message to include indicia based on other information contained in or associated with the authorization request message, such as an access device identifier, a resource provider identifier, a goods or services identifier, and the like.

In step S1025, the transaction processing computer 150 may determine that the flag is in the authorization request message. At step S1030, the transaction processing computer 150 may use the flag to determine the identity of the first authorizing entity computer 365. For example, if the token corresponds to traffic, the transaction processing computer 150 may determine a first authorized entity computer 365 corresponding to the transit agency.

At step S1035, the transaction processing computer 150 may access the multiple access blockchain 370 to obtain a second value associated with the first authorizing entity computer 365 and the user, the portable device 120, the credential, and/or the account identifier associated with the user. The multiple access block chain 370 may store data representing a plurality of interactions between a plurality of authorized entity computers and a plurality of users. The second value may be the UTXO associated with the user's blockchain and the first authorized entity computer 365. In step S1040, the multiple access block chain 370 may return the second value to the transaction processing computer 150.

At step S1045, the transaction processing computer 150 may determine that the second value (e.g., UTXO) is less than the first value (e.g., transaction amount). Thus, at step S1050, the transaction processing computer 150 may determine the master authorizing entity computer 125 based on the credentials in the authorization request message. The master authorization entity computer 125 may be associated with an open-loop authorization entity that is capable of authorizing transactions regardless of category. The master authorized entity computer 125 may be the issuer of the portable device 120.

At step S1055, the transaction processing computer 150 may determine that the master authorization entity computer 125 is capable of authorizing a third value that is the difference between the first value and the second value. In other words, the transaction processing computer 150 may determine whether the main authorizing entity computer 125 is capable of authorizing a balance of the first value that may not be paid from the account of the first authorizing entity computer 365. In some embodiments, the transaction processing computer 150 may make this determination by transmitting a query to the master authorizing entity computer 125. In some embodiments, the transaction processing computer 150 may make this determination by accessing the multiple access block chain 370 for the UTXO associated with the credential and the master authorizing entity computer 125.

at step S1060, the transaction processing computer 150 may create an entry to record the interaction in the multiple access blockchain 370. The entry may include the second value and the third value. The second and third values may be recorded in the multiple access block chain 370 as separate transactions in a single block (e.g., as in block 914 of fig. 9). At step S1065, the transaction processing computer 150 may send a message to the first authorizing entity computer 365 confirming the transaction. In some embodiments, an authorization response message from the first authorizing entity computer 365 may not be needed because the transaction processing computer 150 has updated the account associated with the first authorizing entity computer 365 over the multiple access blockchain 370.

At step S1070, in some embodiments, the transaction processing computer 150 may send a message to the master authorizing entity computer 125 confirming the transaction. The master authorizing entity computer 125 may generate and send an authorization response message to the transaction processing computer 150 at step S1075, which may acknowledge the entry in the multiple access block chain 370. At step S1080, the transaction processing computer 150 may forward an authorization response message to the transmitting computer 140 (e.g., with respect to the third value) along with a response message indicating that the closed loop transaction was successfully completed (e.g., with respect to the second value). At step S1085, the transmitting computer 150 may forward the response message to the resource provider computer 137. At step S1090, resource provider computer 137 may forward the response message to access device 135. If the response message indicates that the transaction is authorized, the access device 135 may allow the user to access the resource. For example, if the transaction is for an access location or transit station, the access device 135 may open a gate or turnstile.

At a later time (e.g., at the end of the day), clearing and settlement processes (i.e., fulfillment) may occur between the transfer computer 140, the transaction processing computer 150, and the first authorizing entity computer 365, and the master authorizing entity computer 125. The clearing may be initiated by the transfer computer 140 to inform the host authorized entity computer 125 of the transaction performed by the user. In settlement, the master authorizing entity computer 125 may bill the transaction amount to the appropriate account and may settle its debt with the transfer computer 140. In other words, funds may be transferred from the appropriate account at the master authorized entity computer 125 to the transfer computer 140. In some embodiments, the clearing record may be validated from the multi-access blockchain.

More specifically, during clearing, the access device 135 may transmit the transaction record to the transmission computer 140. The transfer computer 140 may generate financial notification messages from the transaction records, all of which are intended for the master authorizing entity computer 125, and clear the batch file. The financial notification message may include a unique transaction reference number. The transfer computer 150 may then transfer the clearing batch file to the transaction processing computer 150. The transaction processing computer 150 may route the batch files to the master authorizing entity computer 125.

the master authorization entity computer 125 may extract the transaction reference number from the financial notification message and match the message with the original authorization request message. From the original authorization request message, the primary authorization entity computer 125 retrieves a Primary Account Number (PAN) associated with the transaction. The master authorizing entity computer 125 may calculate the total amount to be charged to the user's account. The total amount may then be debited directly from the user's account. The master authorized entity computer 125 may then be considered as reimbursed by the user.

The master authorized entity computer 125 may then route the funds to the transaction processing computer 150. The transaction processing computer 150 may route the funds to the transfer computer 140. The transfer computer 140 may then credit the amount of funds to the account associated with the access device 135, thereby completing the settlement process. These processes may not be necessary with respect to the first authorizing entity computer 365 because it is part of a closed loop processing system (i.e., funds are credited back to the first authorizing entity computer 365 from an account held by the first authorizing entity computer 365).

The computer system may be used to implement any of the entities or components described above. The subsystems of the computer system may be interconnected via a system bus. Additional subsystems such as a printer, keyboard, fixed disk (or other memory including computer readable media), monitor coupled to a display adapter, and others may be used. Peripheral devices and input/output (I/O) devices coupled to an I/O controller (which may be a processor or any suitable controller) may be connected to the computer system by any number of means known in the art, such as a serial port. For example, a serial port or external interface may be used to connect the computer device to a wide area network, such as the internet, a mouse input device, or a scanner. The interconnection via the system bus allows the central processor to communicate with each subsystem and to control the execution of instructions from the system memory or the fixed disk and the exchange of information between subsystems. The system memory and/or fixed disk may embody a computer readable medium. In some embodiments, the monitor may be a touch-sensitive display screen.

A computer system may include multiple identical components or subsystems connected together, for example, through an external interface or through an internal interface. In some embodiments, computer systems, subsystems, or devices may communicate over a network. In that case, one computer may be considered a client and the other a server, each of which may be part of the same computer system. The client and server may each include multiple systems, subsystems, or components.

It will be appreciated that any of the embodiments of the invention may be implemented in the form of control logic using hardware (e.g. an application specific integrated circuit or a field programmable gate array) and/or using computer software, wherein the general purpose programmable processor is modular or integrated. As used herein, a processor includes a single-core processor, a multi-core processor on the same integrated chip, or multiple processing units on a single circuit board or networked. Based on the disclosure and teachings provided herein, a person of ordinary skill in the art will know and appreciate other ways and/or methods to implement embodiments of the present invention using hardware and a combination of hardware and software.

Any of the software components or functions described in this application may be implemented as software code to be executed by a processor using, for example, conventional or object-oriented techniques, using any suitable computer language, such as Java, C + +, C #, object-oriented C language, Swift, or a scripting language such as Perl or Python. The software code may be stored as a series of instructions or commands on a computer readable medium for storage and/or transmission, suitable media including Random Access Memory (RAM), Read Only Memory (ROM), magnetic media such as a hard drive or floppy disk or optical media such as a Compact Disc (CD) or DVD (digital versatile disc), flash memory, and so forth. A computer readable medium may be any combination of such storage or transmission devices.

Such programs may also be encoded and transmitted using carrier wave signals suitable for transmission over wired, optical, and/or wireless networks conforming to a variety of protocols, including the internet. Thus, computer-readable media according to embodiments of the invention may be created using data signals encoded with such programs. The computer readable medium encoded with the program code may be packaged with a compatible device or provided separately from other devices (e.g., via internet download). Any such computer-readable media may reside on or within a single computer product (e.g., a hard drive, a CD, or an entire computer system), and may be present on or within different computer products within a system or network. The computer system may include a monitor, printer, or other suitable display for providing any of the results mentioned herein to a user.

The above description is illustrative and not restrictive. Many variations of the invention will become apparent to those skilled in the art upon reading the present disclosure. The scope of the invention should, therefore, be determined not with reference to the above description, but instead should be determined with reference to the pending claims along with their full scope or equivalents.

One or more features of any embodiment may be combined with one or more features of any other embodiment without departing from the scope of the invention.

Recitation of "a" or "the" is intended to mean "one or more" unless specifically indicated to the contrary.

All patents, patent applications, publications, and descriptions mentioned above are incorporated herein by reference in their entirety for all purposes. No admission is made that they are prior art.