CN115485707A

CN115485707A - Digital currency aggregation process

Info

Publication number: CN115485707A
Application number: CN202180021210.7A
Authority: CN
Inventors: R·帕雷克; L·库里恩; C·谢菲尔德
Original assignee: Visa International Service Association
Current assignee: Visa International Service Association
Priority date: 2020-06-26
Filing date: 2021-06-24
Publication date: 2022-12-16
Also published as: WO2021263032A1; AU2021296890A1; US20230109085A1

Abstract

A method is disclosed. The method includes receiving, by a processing network computer, a plurality of clearing files from a plurality of transmitting computers. The processing network computer may then generate a settlement file based on data in the plurality of settlement files, the settlement file including the first settlement amount and a first destination associated with the account at the depository computer. The processing network computer may then send the settlement file to an authorized entity computer. The processing network computer may then send a transfer instruction file to a escrow computer, the transfer instruction file including the first destination, a second settlement amount, and a second destination associated with the transfer computer. Subsequently, the authorizing entity computer sends the first settlement amount to the first destination at the depository computer. The escrow computer or the processing network computer then transmits the second settlement amount to the second destination associated with the transfer computer.

Description

Digital currency aggregation process

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a PCT application claiming priority and benefit of U.S. provisional patent application No. 63/044,828, filed on 26/6/2020, which is incorporated herein by reference in its entirety for all purposes.

Background

The number of transactions performed in digital currency has increased significantly. Digital currency provides a number of different benefits compared to legal currency. For example, digital currency transactions do not require conversion to physical currency. Financial institutions such as banks may wish to extend their ability to take advantage of the benefits provided by digital currency. Many methods and systems exist for banks to process transactions and to provide settlement in legal currency. However, conventional settlement systems are not configured to process settlement using digital currency.

Providing a system that can process common transactions using digital currency is difficult, particularly since there are currently many different types of digital currency with different attributes.

In addition, since many digital currencies (e.g., cryptocurrency) use a common ledger, settling digital currencies may present problems if a large financial institution publicly records their settlement payments or collections on the common ledger.

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

Disclosure of Invention

Embodiments of the present invention relate to a method and system for performing settlement between an acquirer and an issuer using digital money.

One embodiment relates to a method comprising: receiving, by a processing network computer, a plurality of clearing files from a plurality of transmitting computers; generating, by the processing network computer, a settlement file based on data in the plurality of settlement files, the settlement file including a first settlement amount and a first destination at a vault associated with the processing network computer; sending, by the processing network computer, the settlement file including the first settlement amount and the first destination to an authorizing entity computer; and sending, by the processing network computer, a transfer instruction file to the escrow computer, the transfer instruction file including the first destination, a second settlement amount, and a second destination associated with one of the plurality of transfer computers; and wherein the authorizing entity computer subsequently sends the first calculated amount or an amount equal to the first calculated amount to the first destination at the escrow computer, and wherein the escrow computer or the processing network computer sends the second settlement amount to the second destination associated with the transfer computer.

Another embodiment relates to a server computer comprising: receiving a plurality of clearing files from a plurality of transmitting computers; generating a settlement file based on data in the plurality of settlement files, the settlement file including a first settlement amount and a first destination at a depository computer associated with a digital vault associated with the server computer; sending the settlement file including the first settlement amount and the first destination to an authorized entity computer; and sending a transfer instruction file to the escrow computer, the transfer instruction file including the first destination, a second settlement amount, and a second destination associated with one of the plurality of transfer computers; and wherein the authorizing entity computer subsequently sends the first settlement amount or an amount equal to the first settlement amount to the first destination at the escrow computer, and wherein the escrow computer or the server computer sends the second settlement amount to the second destination associated with the transfer computer.

Yet another embodiment relates to a method comprising: receiving, by the escrow computer, a transfer instruction file from the processing network computer, the transfer instruction file including a second settlement amount, a first destination at the escrow computer associated with the digital vault, and a second destination associated with the transport computer, wherein the processing network computer further sends a settlement file including the first settlement amount and the first destination to an authorized entity computer; receiving, at the digital vault associated with the first destination at the escrow computer, the first settlement amount or an amount equivalent to the first settlement amount from an authorizing entity computer, the first settlement amount or the amount equivalent to the first settlement amount being equal to the second settlement amount; and sending, by the escrow computer to the processing network computer, a notification that the escrow computer received the first calculated amount or the amount equivalent to the first calculated amount.

More detailed information about embodiments of the invention can be found in the detailed description and the figures.

Drawings

FIG. 1 shows a block diagram illustrating a payment processing system.

FIG. 2 shows a block diagram of a settlement system and an overlaid process flow in which transactions are cleared and settled in digital currency.

FIG. 3 shows a block diagram of another settlement system and an overlaid process flow in which transactions are cleared and settled in both digital and legal currencies.

Fig. 4 shows a block diagram of a settlement system using a digital vault that provides settlement capabilities in both digital and legal currencies.

Figure 5 shows a block diagram of a system for converting digital currency to fiat currency.

FIG. 6 shows a block diagram of a system for converting legal currency to digital currency.

FIG. 7 shows a block diagram of a digital vault.

Fig. 8 shows a block diagram of a blockchain.

FIG. 9 shows a block diagram of a retention computer.

FIG. 10 shows a block diagram of a processing network computer.

Detailed Description

Before discussing embodiments of the invention, some terms may be described in further detail.

The "user" may comprise an individual. In some embodiments, a user may be associated with one or more user devices. In some embodiments, the user may also be referred to as a cardholder, account holder, or consumer.

The "user device" may be any suitable device operated by a user. The user device may take any suitable form. Some examples of user devices include cellular phones, cards (e.g., payment cards), PDAs, personal Computers (PCs), tablet computers, and the like. In some embodiments, where the user device is a mobile device, the mobile device may include a display, a memory, a processor, a computer-readable medium, and any other suitable components.

A "mobile device" (sometimes referred to as a mobile communication device) may include any electronic device that a user may transport or otherwise operate, which may also provide remote communication capabilities with a network. The mobile communication device may communicate using a mobile telephone (wireless) network, a wireless data network (e.g., 3G, 4G, or the like), wi-Fi, bluetooth Low Energy (BLE), wi-Max, or any other communication medium that may provide access to a network such as the internet or a private network. Examples of mobile devices include mobile phones (e.g., cellular phones), PDAs, tablet computers, netbooks, laptop computers, wearable devices (e.g., watches), vehicles (e.g., cars and motorcycles), personal music players, handheld application-specific readers, and so forth. A mobile device may include any suitable hardware and software for performing such functions, and may also include multiple devices or components (e.g., two devices used together may be considered a single mobile device when the devices remotely access a network by being tethered to another device, i.e., using the other device as a modem).

A "resource provider" may be any suitable entity that provides resources (e.g., goods, services, access to secure data, access to locations, etc.) during a transaction. For example, the resource providing entity may be a merchant, a venue operator, a building owner, a government entity, 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.

An "access device" may be any suitable device for providing access to an external computer system. The access means may be in any suitable form. Some examples of access devices include point-of-sale (POS) devices, cellular telephones, PDAs, personal Computers (PCs), tablet PCs, 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 may use any suitable contact or contactless mode of operation to send or receive data to or from the mobile device or to associate with the 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, 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 to interact with a mobile device.

"Access data" may include any suitable data that may be used to access a resource or create data that may access a resource. In some embodiments, the access data may be account information for a payment account. The account information may include a Primary Account Number (PAN), a payment token, an expiration date and verification value (e.g., CVV2, dCVV 2), and the like. In other embodiments, the access data may be data that may be used to activate account data. For example, in some cases, account information may be stored on the mobile device, but may not be activated until the mobile device receives specific information. In other embodiments, the access data may include data that may be used to access the location. Such access data may be ticket information for an event, data for accessing a building, transportation ticket information, and the like. In other embodiments, the access data may include data for gaining access to sensitive data. Examples of access data may include code or other data needed by the server computer to grant access to sensitive data.

An "authorizing entity" may be an entity that typically uses an authorizing computer to authorize a request. The authorized entity may be an issuer, government agency, file repository, access administrator, etc. An "issuer" may typically include a business entity (e.g., a bank) that maintains a user account. The issuer may also issue payment credentials to the user that are stored on a user device, such as a cell phone, smart card, tablet, or laptop.

The "token" may be a substitute value for the credential. The token may be a string of numbers, letters, or any other suitable character. Examples of tokens include payment tokens, access tokens, personal identification tokens, and the like.

The "payment token" may include a payment account identifier in place of an account identifier such as a Primary Account Number (PAN). For example, the token may include a series of alphanumeric characters that may be used as a substitute for the original account identifier. For example, the token "4900 0000 0000 0001" may be used in place of PAN "4147 0900 0000 1234". In some embodiments, the token may be "format-preserved" and may have a numeric format (e.g., ISO 8583 financial transaction message format) consistent with account identifiers used in existing transaction processing networks. In some embodiments, the token may be used in place of the PAN to initiate, authorize, settle, or resolve a payment transaction, or represent the original credential in other systems that would normally provide the original credential. In some embodiments, the token value may be generated such that a recovery of the original PAN or other account identifier may not be computationally derivable from the token value. Further, in some embodiments, the token format may be configured to allow an entity receiving the token to identify it as a token and identify the entity that issued the token.

An "authorization request message" may be an electronic message sent to the payment processing network and/or the issuer of the payment card to request authorization for a transaction. The authorization request message according to some embodiments may conform to ISO 8583, which is a standard for systems that exchange electronic transaction information associated with payments made by users 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 an additional data element 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 current transaction, e.g., transaction amount, merchant identifier, merchant location, etc., as well as 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. By way of example only, the authorization response message may include one or more of the following status indicators: approval-the transaction is approved; decline-transaction not approved; or call center-in response to more information pending, 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 be used 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.

A "blockchain" may be a distributed database that maintains an ever-increasing list of records to protect against tampering and revision. The block chain may include a plurality of interactive recording blocks. Each tile in the tile chain may also contain a timestamp and a link to the previous tile. In other words, the interaction records in a blockchain may be stored as a series of "blocks" or persistent files that include records of multiple interactions that occurred within a given time period. After completing the block and verifying the block, the block may be appended to the block chain by the appropriate node. Each block may be associated with a block header. In embodiments of the invention, the blockchain may be distributed and a copy of the blockchain may be maintained at each complete node in the verification network. Any node within the authentication network may then use the blockchain to authenticate an interaction.

A "node" may be a point where a line or path intersects or branches, or may be a central point or connection point. The node may also be a "computer node," which may be any computer or device connected to the authentication network. Each tile in the chain of tiles and the node at which interaction is fully verifiable may be a full node. The "full node" may store the complete blockchain (i.e., each block and each interaction). In some embodiments, a "user device" may be a computer node in an authentication network.

The "block header" may be a header including information on a block. The block header may be used to identify a particular block in a block chain. The block header may include any suitable information, such as a previous hash, a mekerr root, a timestamp, and a nonce. In some embodiments, the block header may also include a difficulty value.

The "nonce" may include any number. In some embodiments, the nonce may be a value that is adjustable by the full node when performing the workload attestation process. The nonce may be input into a hash function along with the chunk data to determine an output hash value. The correct nonce (also known as the golden nonce) results in an output hash value that meets a predetermined criterion, e.g., is less than a difficulty value. The nonce may be of any suitable length (e.g., 32 bits).

A "server computer" is typically a powerful computer or cluster of computers. For example, a server computer may be a mainframe, a minicomputer cluster, or a group of servers acting as a unit. In one example, the server computer may be a database server coupled to a network server.

A "processor" may include any suitable data computing device or devices. The processor may include one or more microprocessors that work together to achieve a desired functionality. The processor may comprise a CPU including at least one high speed data processor sufficient to execute program components for performing user and/or system generated requests. The CPU may be a microprocessor, such as Athlon, duron, and/or Opteron, of AMD; powerPC from IBM and/or Motorola (Motorola); cell processors by IBM and Sony (Sony); celeron, itanium, pentium, xeon, and/or XScale of Intel; and/or the like.

The "memory" may be any suitable device that can store electronic data. Suitable memory may include a non-transitory computer-readable medium that stores instructions executable by a processor to implement a desired method. Examples of memory may include one or more memory chips, disk drives, and the like. Such memories may operate using any suitable electrical, optical, and/or magnetic mode of operation.

Fig. 1 shows a block diagram illustrating a payment processing system 100. Fig. 1 shows three user-operated user devices (e.g., a first user operating a first user device 102A) conducting a transaction. However, any number of transactions (by any suitable number of users) may be performed and processed by the system. For example, a first user may pay for goods and/or services at a first resource provider using a first user device 102A. The resource provider may operate a first resource provider computer 104A. The first resource provider computer 104A may communicate with a first authorization entity computer 110A operated by an authorizing entity, such as an issuer, via a first transfer computer 106A operated by an acquirer and a processing network computer 108 operated by a payment processing network. The second user and the third user may use similar methods to pay for goods and/or services at different or the same resource provider.

The first user device 102A, the first resource provider computer 104A, the first transport computer 106A, the processing network computer 108, and the first authorized entity computer 110A may all be in operative communication with one another over any suitable communication channel or communication network. Suitable communication networks may be any one and/or combination of the following: direct interconnects, the internet, local Area Networks (LANs), metropolitan Area Networks (MANs), an operational task as an internet node (OMNI), a secure customized connection, a Wide Area Network (WAN), a wireless network (e.g., using a protocol such as, but not limited to, wireless Application Protocol (WAP), I-mode, etc.), and so forth. Secure communication protocols may be used, such as, but not limited to: file Transfer Protocol (FTP), hypertext transfer protocol (HTTP), secure hypertext transfer protocol (HTTPs), secure Sockets Layer (SSL), ISO (e.g., ISO 8583), etc. to send messages between computers, networks, and devices.

As described above, the processing network computer 108 may be a computer in a payment processing network. An exemplary payment processing network may include data processing subsystems, networks, and operations for supporting and delivering authorization services, exception file services, and clearing and settlement services. An exemplary payment processing network may include VisaNet ^TM . Such as VisaNet ^TM Such payment processing networks are capable of processing credit card transactions, debit card transactions, and other types of commercial transactions. Visanet ^TM Specifically including a VIP system (Visa integrated payment system) that processes authorization requests, and a Base II system that performs clearing and settlement services. The payment processing network may use any suitable wired or wireless network, including the internet.

In step S100, a first user may pay for goods and/or services at a first resource provider computer 104A using a first user device 102A. The user may choose to provide payment in any type of currency (e.g., legal currency or digital currency). In some embodiments, the first resource provider computer 104A may include or be associated with an access device. The first user device 102A and the access device may interact such that access data (e.g., PAN, payment token, verification value, expiration date, etc.) from the user device 102A is received by the access device. The access data may be received by the first resource provider computer 104A.

In some embodiments, the access device may be a point of sale terminal, and the access device may be used to conduct an in-person transaction with the user. In other embodiments, the resource provider computer 104A may be a remote web server, and the first user device 102 may be remotely located with respect to the first user device 102A (e.g., in the case of an e-commerce transaction).

In step S102, first resource provider computer 104A may generate an authorization request message that includes information received from the access device (e.g., information corresponding to user device 102A) and transaction information (e.g., transaction amount, merchant-specific information, etc.) and send the authorization request message to first transmission computer 106A.

After receiving the authorization request message, the first transport computer 106A may process the authorization request message and forward the authorization request message to the processing network computer 108 to continue the transaction authorization process in step S104.

After receiving the authorization request message, the processing network computer 108 may proceed with the authorization process in step S106. In some cases, prior to a credit or debit transaction (e.g., a credit or debit card transaction) occurring, the processing network computer 108 has an agreement established with each authorizing entity (e.g., each issuer) regarding how the transaction of the authorizing entity will be authorized. In some cases, such as when the transaction amount is below a threshold, the processing network computer 108 may be configured to authorize the transaction based on information it has about the first user account without generating and sending an authorization request message to the first authorizing entity computer 110A. In other cases, such as when the transaction amount is above a threshold, the processing network computer 108 may receive the authorization request message, determine the authorizing entity associated with the first user device 102A (e.g., by performing a lookup in a database that correlates the authorizing entity computer with a Bank Identification Number (BIN) in the account number), and forward the authorization request message for the transaction to the authorizing entity computer 110A for verification and authorization. In other embodiments, there is no threshold, and the processing network computer 108 may determine the authorizing entity associated with the first user device 102A (e.g., by performing a lookup in a database that correlates the authorizing entity computer with a Bank Identification Number (BIN) in the account number) and forward an authorization request message for the transaction to the authorizing entity computer 110A for verification and authorization.

In step S108, upon receiving the authorization request message, the first authorizing entity computer 110A may generate an authorization response message (which may include an authorization code indicating that the transaction is approved or denied) and send the authorization response message to the processing network computer 108. The processing network computer 108 may then forward the authorization response message to the first resource provider computer 104A and any associated access devices via the first transmission computer 106A.

If the access data received by the processing network computer 108 in the authorization request message in step S106 is in the form of a token, the processing network computer 108 may exchange the token for a real credential (e.g., PAN). Any subsequent authorization request message may then be modified to include the authentic credential, and the subsequent authorization request message may be forwarded to the first authorizing entity computer 110A for verification. After receiving the authorization response message with approval or denial from the first authorization entity computer 110A, the processing network computer 108 may replace the authentic credential with the token in the authorization response message and forward the authorization response message to the first resource provider computer 104A and any associated access devices via the first transmission computer 106A.

At the end of the day or at some other suitable time interval, clearing and settlement processing between at least the first transfer computer 106A, the processing network computer 108 and the first authorizing entity computer 110A may be performed on the transaction and other transactions. As shown in fig. 1, multiple users may conduct transactions, and they may eventually settle and settle. One or more files may be generated, including, for example, a net amount of funds transferred between the issuer (i.e., the issuer operating the authorized

entity computers

110A, 110B, 110C) and the acquirer (i.e., the acquirer operating the transfer computers 106A, 106B, 106C).

Fig. 2 shows a block diagram of a settlement system 200 and an overlay process flow according to an embodiment of the invention. The system 200 may include a processing network computer 202, an authorized entity computer 204, a retention computer 206, and a transmission computer 208. The processing network computer 202, the authorization entity computer 204, and the transport computer 208 may maintain accounts, which may be digital vaults that may store digital currency. The digital currency may be central bank's digital currency or legally supported cryptocurrency, such as dollar currency (USD Coin), USD tyad (USD Tether), true dollars (TrueUSD), gold-stabilized currency (DGX), or other stabilized currency.

The processing network computer 202 may include data processing subsystems, networks, and operations for supporting and delivering authorization services, exception file services, and clearing and settlement services. An exemplary processing network may include VisaNet ^TM . Such as VisaNet ^TM Can process credit card transactions, debit card transactions, and other types of commercial transactions. Authorization, settlement, and clearing can occur simultaneously (substantially simultaneously, e.g., within minutes or hours), or can occur as part of a batch settlement process (e.g., at the end of a day or week).

Processing network computer 202 may have or be associated with a processing network account computer (not shown in FIG. 2), which may be a bank account. The processing network may also have one or more digital vault managed by the depository computer 206 for storing one or more digital currencies.

The authorizing entity computer 204 may be a computer operated by an authorizing entity, such as an issuer, which may be a financial institution, such as a bank, that creates and maintains financial accounts for account holders. An issuer or issuing bank may issue and maintain financial accounts for consumers. An issuer of a particular consumer account for a consumer may determine whether to approve or deny a particular transaction for the consumer. If the transaction is approved (e.g., the consumer's account has a sufficient balance available and meets other authorization or authentication criteria), the issuer may authenticate the consumer and issue funds to the acquirer. An issuer may have one or more issuer accounts, which may include bank or credit accounts (e.g., for holding legal currencies such as U.S. dollars) and/or digital currency vaults (e.g., for holding cryptocurrency based on legal currencies).

The escrow computer 206 may be a computer that manages digital assets of other entities. Escrow computer 206 can securely store digital currency, provide access to the digital currency, and transfer assets for the entity using escrow computer 206. The escrow computer 206 can also manage multiple digital vaults for various entities. The plurality of digital vaults may include a main vault, a receiving vault to receive external funds, and a transaction vault to send funds and convert the funds between digital and legal currencies.

The transport computer 208 may be operated by an acquirer that may be a financial institution associated with the resource provider. The acquirer typically provides a bank account for the resource provider and, in some cases, also provides the transaction acceptance infrastructure. Generally, after a transaction is authorized, funds are transferred from the issuer to the acquirer's resource provider account as part of the settlement process. The acquirer may also communicate the payment transaction status with the resource provider. The acquirer may also operate the transmitting computer 208. In embodiments of the invention, an acquirer may have one or more acquirer accounts, which may include bank accounts (e.g., for legal currencies such as U.S. dollars) and/or digital currency vaults (e.g., for cryptocurrency with or without legal currency).

Returning to fig. 2, a digital currency settlement process according to an embodiment of the present invention may be described. In a digital currency settlement process according to an embodiment of the present invention, both parties of the settlement will settle in digital currency (e.g., cryptocurrency).

In step S200, the transfer computer 208 operated by the acquirer may send the clearing file to the processing network computer 202. The clearing file may include data regarding a plurality of transactions (e.g., account numbers used to conduct the transactions, transaction type codes, transaction amounts, transaction dates, resource provider identifiers, authorization codes, authorization methods, authentication methods, etc.), such as the transactions performed in fig. 1, and digital addresses (e.g., 0x 394893453) associated with the digital vault of the transport computer 208. For example, the clearing file may contain data regarding the resource provider and transactions made by the resource provider's resource provider computer associated with its acquirer. In some embodiments, the clearance file may also contain the net amount of funds (e.g., the second settlement amount) requested from various authorized entities (e.g., issuers) associated with users conducting transactions with those resource providers and/or resource provider computers. The transfer computer 208 may additionally provide an indication in the clearing document that digital currency settlement is requested.

In step 202A, the processing network computer 202 may generate a settlement file and send the settlement file to the authorizing entity computer 204, including instructions to begin a digital currency settlement. The processing network computer 202 may send other settlement files to other authorized physical computers. The settlement file sent to the authorizing entity computer 204 may include a first settlement amount (e.g., the amount of digital currency to be sent) and a first destination (e.g., a digital address such as 0x 93498394) associated with the payment network computer 202 to which the settlement funds should be transferred. The first destination may be a digital address (e.g., a public cryptographic key) of a digital vault at the vault security computer 206 associated with the processing network computer 202 (e.g., a processing network vault).

In step S202B, the processing network computer 202 may also generate a transfer instruction file and transmit the transfer instruction file to the retention computer 206, including the settlement instruction. The transfer instruction file may include a second settlement amount to be transferred (e.g., the amount of digital currency to be transferred), a second destination for the amount (e.g., the digital address received in step S200 associated with the digital vault of the transfer computer 208), and a starting address associated with the account number associated with the payment network computer 202. In some embodiments, the second destination may be a numerical address in the form of a public cryptographic key. The second settlement amount may be the same as the first settlement amount or have a value equivalent to the first settlement amount. For example, the first settlement amount may be ten units of the first digital currency, and the second settlement amount may be ten units of the equivalent amount of the same or a second digital currency. In some embodiments, each of the first settlement amount and the second settlement amount is digital currency.

In step S204, the authorizing entity computer 204 may transfer the first settlement amount from the issuer account (e.g., a digital currency account at the authorizing entity computer 204 or elsewhere (e.g., the escrow computer 206)) to a processing network vault managed by the escrow computer 206 at a first destination provided by the processing network computer 202.

In step S206, the escrow computer 206 may transfer the second settlement amount from the processing network vault to a second destination associated with the acquirer account associated with the transport computer 208. In some embodiments, this may include withdrawing money from a processing network vault, followed by debiting the money to an acquirer account associated with the transfer computer 208.

In step S208, the escrow computer 206 may send a message to the processing network computer 202 indicating that the settlement has been completed. The message may specifically send a confirmation of the payment sent, the funds received from the authorizing entity computer 204, and the balance of the processing network vault back to the processing network computer 202.

FIG. 3 shows a block diagram of another clearing and settlement system 300 and an overlying process flow in which transactions are cleared and settled in both digital and legal currencies according to another embodiment of the invention. The settlement system 300 shares common components with the settlement system of figure 2. However, FIG. 3 also shows a process network account computer 310. Processing network accounts computer 310 may maintain accounts of the processing network associated with processing network computer 302, which may include bank accounts (e.g., for legal currencies such as U.S. dollars). In some embodiments, processing network account computer 310 may be operated by a financial institution. The settlement system 300 of fig. 3 includes a transmitting computer 308 that requests fiat currency settlement. The underlying transaction by the merchant associated with the acquirer operating transfer computer 308 may have been conducted in either legal or digital currency.

In step S300, the transfer computer 308 may send the clearing file to the processing network computer 302. The clearing file may be similar to that described with respect to step S200 of fig. 2, including data regarding a plurality of transactions and account identifiers or addresses of the transfer computer 308. In this embodiment, multiple transactions may have been conducted in a particular type of digital currency, or may have been conducted in a legal currency. As in the embodiment of fig. 2, the clearing file may contain a net amount of funds (e.g., a second settlement amount) requested from the issuer operating the authorizing entity computer 304. Transfer computer 308 may additionally include an indication in the clearing file that a fiat currency settlement is requested.

In step 302A, the processing network computer 302 may send a settlement file to the authorizing entity computer 304, including instructions to begin digital currency settlement. The settlement file may include a first settlement amount (e.g., an amount of digital currency to be sent by the authorizing entity computer 304) and a first destination (e.g., a digital address such as 0x 93498394) associated with the payment network computer 302 to which the settlement funds should be transferred. The first destination may be a digital address (e.g., a public cryptographic key) of a digital vault (processing network vault) associated with the processing network computer 302 at the vault computer 306.

In step S302B, the processing network computer 302 may send a transfer instruction file, including settlement instructions, to the escrow computer 306. The transfer instruction file may include a second settlement amount to be transferred (e.g., the amount of fiat currency to be sent by the processing network account computer 310 to the transfer computer 308), a second destination associated with the authorizing entity computer 304. In some embodiments, the second destination may be a digital address of a digital vault associated with the authorizing entity computer 304, such as a public cryptographic key. In some embodiments, the second settlement amount may have a value equal to the first settlement amount. For example, the first settlement amount may be ten units of the first digital currency, and the second settlement amount may be ten units of the equivalent amount of the fiat currency. The transfer instruction file may include a request that escrow computer 306 send a notification to processing network computer 302 when escrow computer 306 receives the first calculated amount from the second destination (e.g., an address associated with an authorized entity computer). For example, in step S306, the escrow computer 306 may send a notification when digital currency (e.g., a first amount of settlement) is received from the authorizing entity computer 304 (e.g., a second destination).

In step S304, the authorizing entity computer 304 may transfer the first settlement amount (e.g., in digital currency) from the issuer account (e.g., the digital currency account at the authorizing entity computer 304) to a processing network vault managed by the escrow computer 306 at a first destination provided by the processing network computer 302. In some embodiments, the authorizing entity computer 304 may send an amount equal to the first settlement amount to the depository computer. For example, in step S302A, the processing network computer 302 may send a message to the authorizing entity computer 304 to conduct the legal tender settlement. However, the authorizing entity computer 304 may send the equivalent amount of digital currency to escrow computer 306 to settle the debt to the acquirer associated with transfer computer 308.

In step S306, after receiving the first settlement amount or the equivalent amount, escrow computer 306 may transmit a message indicating that the first step of settlement has been completed to processing network computer 302. Escrow computer 306 may verify that the first settlement amount and the second settlement amount have equal value before sending the message to processing network computer 302. The message may include the balance of the digital vault that received the first settlement amount. In some embodiments, escrow computer 306 may transfer the second settlement amount to a transaction vault in escrow computer 306 for conversion to fiat currency. The transaction vault may be an account holding funds that are converted between digital legal-supported currency and legal currency.

In steps S308A and S308B, the processing network 302 may transfer the second settlement amount as fiat currency from the account at the processing network account computer 310 to the acquirer account at the transmission computer 308, thereby completing the settlement process.

The settlement system of fig. 2 and 3 allows an issuer operating the authorizing entity computer and an acquirer operating the transmitting computer to settle using digital currency. The acquirer may request payment in digital currency (e.g., the system of fig. 2) or legal currency (e.g., the system of fig. 3), and the issuer can fund the payment in the digital currency or legal currency.

Fig. 4 shows a block diagram of a settlement system 400 that provides settlement capabilities in both digital and legal currencies using a digital vault. The settlement system 400 can be used in conjunction with the methods and systems described with respect to fig. 2-3.

The system shown in fig. 4 includes several common components with respect to fig. 3, and the description thereof need not be repeated here. The escrow computer 406 maintains a plurality of vaults associated with the processing network, including a master vault 407B, a receiving vault 407A, and/or a transaction vault 407C. The vaults may be collectively referred to as process network vaults 407.

Redemption computer 410 may be associated with retention computer 406. The exchange computer 410 may communicate with an external device (not shown) to exchange the legal currency for digital currency or vice versa. If both the issuer and the acquirer choose to use legal currency for settlement, a conventional settlement system may be used. If the acquirer wishes to settle in digital currency and the issuer chooses to use fiat currency for settlement, the authorizing entity computer 404 may send the amount of the fiat currency to the processing network account computer 412 instead of the escrow computer 406. The escrow computer 406 can then receive notification from the process network account computer 412 regarding the legal tender payment, and then proceed with the method of FIG. 3.

In step S400, the processing network computer 402 may receive a number of clearing files, similar to those described above with respect to FIGS. 2 and 3. Similar to step S202A of fig. 2, the processing network computer 402 may then generate a settlement file describing the settlement transaction to be completed. The processing network computer 402 then sends a message to the authorizing entity computer 404 indicating the amount owed by the authorizing entity computer 404 to the processing network computer 402. Similar to the methods and systems described above with respect to fig. 2 and 3, the authorizing entity computer 404 may be operated by an issuer.

In step S402, the authorizing entity computer 404 may transfer funds as digital currency to a member receiving vault 407A of a processing network vault 407 maintained by the escrow computer 406. Digital currency is transferred from an issuer vault (e.g., a digital currency account associated with the authorizing entity computer 404) to the member receiving vault 407A. In some embodiments, the numerical address of the member receiving vault 407A or the member receiving vault 407A itself may be unique to the authorizing entity computer 404. The unique numerical address may provide privacy as many digital currency transactions are visible on the common blockchain. Since the numerical address may be unique, the issuer operating the authorized entity computer 404 will not be able to easily view processing transactions between the network and different external entities.

In step S404, the escrow computer 406 may transfer funds from the member receiving vault 407A in the processing network vault 407 to the primary vault 407B. The master vault 407B may be a digital currency account of the processing network computer 402. The main vault 407B may store multiple types of digital currency. The master value 407B may also receive funds from or provide funds to other members receiving the vault from other authorized entities (e.g., the issuer) or the acquirer.

The value transfer from the member specifically associated with the authorized entity computer 404 to receive the vault 407A and the master value 407B specifically associated with the processing network computer may occur within the processing network vault 407 in the vault computer 406. This has the advantage that any particular funds (e.g., digital funds or legal funds) provided by the master vault to an external entity, such as the transfer computer 408, are anonymous with respect to the authorized entity computer 404. For example, the authorizing entity computer S402 may transfer one million USDCs to the member receiving vault 407A for settlement of debts to one or more acquirers. Then, at some point in time, one million USDCs from the authorizing entity computer 404 are transferred to the master vault 407B (assuming the member receiving vault 407A has not obtained funds to settle the debts of the authorizing entity computer). The master vault 407B may then transfer funds to one or more acquirers for repayment of any debt owed by the respective issuer. Since the master value 407B receives funds from many member receiving vaults intended for different members and provides funds to the various acquirers operating their transfer computers, there is no direct link between the funds transfer sent by the authorizing entity computer 404 in step S402 and the funds ultimately provided to the transfer computer 408. Thus, the amount ultimately paid by each authorized physical computer may be obscured to the intended recipient of the funds transfer. This can be compared to the following case: one million USDCs are paid from authorizing entity computer 404 to transmission computer 408 for settlement of the debt, and the payment is written to the public ledger. In this case, the public can determine the details of the transaction. Accordingly, embodiments of the present invention may provide an efficient way of maintaining transaction privacy between entities, such as issuers and acquirers, even when conducting transactions using digital currency.

If the funds are paid as digital currency to an acquirer operating the transfer computer 408 (e.g., during the settlement process described in FIG. 2), the settlement process may proceed to step S406. In step S406, the escrow computer 406 may transfer funds from the master vault 407B to the acquirer vault at the transfer computer 408, or to an acquirer vault stored at the escrow computer 406 on behalf of the transfer computer 408 or the acquirer operating the transfer computer 408. The acquirer vault may be, for example, the digital currency vault of the acquirer operating the transport computer 408.

If the processing network computer 402 wishes to convert some of the digital currency in the master vault 407A to legal currency, for example, to pay funds as legal currency to an acquirer (e.g., during the settlement process described in FIG. 3), the process may proceed from step S404 to step S408. In step S408, the escrow computer 406 may transfer a certain amount of digital money from the main vault 407B to the transaction vault 407C that processes the network vault 407.

In step S410, funds in the transaction vault may be converted to fiat currency and deposited into accounts maintained at the processing network accounts computer 412 via the conversion computer 410. Redemption computer 410 may be associated with (e.g., operated by the same party as) escrow computer 406. The redemption computer 410 may communicate with external devices to convert between digital currency and legal currency. For example, the exchange computer 410 may be a digital currency exchange that may trade digital currency (e.g., bitcoin (Bitcoin), etherhouse (Etherium), etc.) on various digital currency platforms via network interaction with the various digital currency platforms.

After the conversion of the currency type by the conversion computer 410, the conversion computer 410 sends the currency amount of the processed currency type to the processing network account computer 412 in step S412. This allows funds received as digital currency (e.g., from the authorizing entity computer 404) to be converted into fiat currency that can be used as payment to the acquirer operating the transmitting computer, as in step S308B of fig. 3.

Alternatively, the processing network account computer 412 may provide funds to the redemption computer 410. For example, the processing network account computer 412 may provide a monetary amount of legal currency to be converted to digital currency via the conversion computer 410. The conversion computer 410 may then send the digital currency to the transaction vault 407C. The transaction vault 407C may then transfer the digital currency to the primary vault 407B. This allows the processing network to receive payments settled in the fiat currency from the issuer operating the authorizing entity computer 404 and provide the settlement amount in digital currency to the acquirer operating the transport computer 408.

FIG. 5 shows a block diagram of a system 500 that can be used to exchange digital currency for fiat currency, according to an embodiment of the invention. The process shown in fig. 5 may be performed, for example, after step S306 in fig. 3 but before step 308A. This process may be used in situations where the processing network computer or the account of the processing network computer does not have sufficient funds to pay the acquirer.

In step S500, the processing network computer 502 may send a message including the first redemption amount and the second redemption amount to the escrow computer 504. In some embodiments, the message may further include a numerical address associated with the processing network computer 502 such that the second redemption amount may be added to the account associated with the processing network computer 502. The depository computer 504 may store a numerical address to be used in subsequent redemptions. In this example, the first exchange amount may be an amount of digital currency to be converted to the fiat currency of the second exchange amount. For example, the processing network may instruct 100 ten thousand USDCs (an example of a first redemption amount) to be redeemed for 100 ten thousand dollars (an example of a second redemption amount).

In step S502, the escrow computer 504 can exchange a digital currency of a certain amount of money to a legal currency of an equivalent amount of money via the exchange computer 506 operated by one side of the operation of the escrow computer 504. In some embodiments, the escrow computer 504 first transfers an amount of digital currency from the main vault of the processing network vault into the transaction vault, and then completes the transaction.

In step S504, the escrow computer 504 can notify the processing network computer 502 via a notification message that the digital money has been transferred out of the processing network vault maintained by the escrow computer 504. The notification message may also include a balance for processing the network vault.

In step S506, the redemption computer 504 can deposit an amount of legal currency (e.g., $ 100 million) into the escrow account maintained at the escrow account computer 508. The escrow account may be a bank account associated with escrow computer 504. Custody account computer 508 may be a financial institution computer, such as a bank computer, that holds an account of the custody party operating custody computer 504.

In step S508, the depository account computer 504 may transfer an amount of fiat currency from the depository account into a processing network account (e.g., a bank account) at the processing network account computer 510. In some embodiments, the wire or ACH transfers may be made from the escrow computer to an account associated with the processing network (e.g., a settlement account).

FIG. 6 illustrates a block diagram of a system 600 for converting legal currency to digital currency. The process shown in fig. 6 may be performed, for example, before step S206 in fig. 2. This process may be used in the event that the processing network computer or the account (or vault) of the processing network computer does not have sufficient funds to pay the acquirer.

In step S600, the processing network computer 602 may send a message to the redemption computer 604 including instructions to redeem the first redemption amount for the second redemption amount. In some embodiments, the message may further include a numeric address of the processing network computer 602, similar to the message seen in step S500 of fig. 5. For example, the processing network computer 602 may send instructions to the exchange computer 604 associated with the escrow computer 606 to exchange an amount of legal currency to an equivalent amount of digital currency. For example, the processing network computer 602 may instruct the redemption computer 604 to redeem 100 ten thousand dollars for 100 ten thousand USDC.

In step S602, the exchange computer 604 may exchange an amount of legal currency to an equivalent amount of digital currency. For example, the redemption computer 604 may communicate with one or more external computers (e.g., a cryptocurrency blockchain network not shown in the figures) to facilitate converting an amount of fiat currency to an equivalent amount of digital currency.

In step S604, the redemption computer 604 may notify the processing network computer 602 that the redemption is complete.

In step S606, a certain amount of digital money may be deposited into the processing network vault at the escrow computer 606. For example, 100 million USDCs may be stored in a processing network vault. In some embodiments, digital currency is deposited into the transaction vault and then transferred to the main vault.

In steps S608A and S608B, after receiving the notification from the exchange computer 604 that the exchange has been completed, the processing network computer 602 may transfer an amount of legal currency from the processing network account at the processing network account computer 608 (e.g., the bank account of the processing network) to a depository account at the depository account computer 610 (e.g., the bank account of the depository computer). For example, the processing network may transfer $ 100 million to a custody account, where wire transfers or ACH transfers may be used.

The systems of fig. 5 and 6 enable the processing network to process settlement regardless of the type of currency received. The processing network can receive payment settled in legal or digital currency from an issuer and can send payment to an acquirer in legal or digital currency.

FIG. 7 illustrates a block diagram of an exemplary digital vault 706 according to an embodiment of the invention.

The digital vault 706 may be a digital currency vault associated with a vault ID. The vault ID may be a string of alphanumeric characters that identifies a particular vault, e.g., 091fj81283mafz1888x78. For example, a processing network computer or a depository computer may use the vault ID to identify a particular vault. The digital currency vault may store multiple digital currencies as different asset types. For example, a digital currency vault may store a first asset type 703, a second asset type 704, and a third asset type 705. The asset type may be digital currency.

Each asset type may be associated with an asset ID. The asset ID may be an alphanumeric identifier that identifies a particular digital currency type. In some embodiments, the asset ID may be unique to the digital currency vault.

In some embodiments, each asset in the digital currency vault may be further divided into a plurality of sub-vaults. For example, a second asset type 704 received from one external entity may be stored in a first sub-vault second asset type ID A704A, while a second asset type 704 received from a different external entity may be stored in a second sub-vault second asset type ID B704B. Each sub-vault may be associated with a unique numerical address. For example, the first asset type ID 703C may have a numerical address of 0x 93498394. The numeric address may point to an account on the blockchain. After an external entity (e.g., an issuer or acquirer) receives a digital address (e.g., as part of a settlement message), the external entity is able to see all digital currency transactions into and out of the sub-vault via the blockchain. By providing each external entity with a unique numerical address to a unique sub-vault, the transaction information of each external entity may be kept secret from other external entities.

In some embodiments, data security may be further enhanced by periodically rotating digital addresses. For example, the processing network computer or the escrow computer may change the numerical address for the sub-vault after a set period of time or after a set number of deposit transactions.

The processing network (or escrow computer) can also determine a first digital address associated with the asset in the digital currency vault. The processing network may then transmit the first numerical address (e.g., 0x 93498394) to the authorizing entity computer in a first settlement file, thereby allowing the authorizing entity computer and the processing network computer to perform a first settlement using the first numerical address.

Fig. 8 shows a block diagram of a blockchain. As described above, a blockchain may be used when transferring digital currency from one digital vault to another digital vault, or from one entity to another entity. For example, the transitions seen in steps S204 and S206 of fig. 2 may be performed on a blockchain. Fig. 8 includes a block chain 800 including a first block 810 and a second block 840. The block chain 800 may include any suitable number of blocks (e.g., 10, 500, 2000, 500000, etc.).

Current blockchain techniques, such as bitcoin and ether house, maintain only additional ledgers (appended-only headers) in the network. The ledger includes a list of blocks of transaction data that are cryptographically linked together. Blocks are created by a computationally intensive process called workload proof, where valid blocks need to exhibit sufficient "difficulty" (i.e., sufficient computational power to average the creation). If there is more than one available block chain, a network participant, i.e., a node, can download all blocks in all chains and follow the chain with the highest overall difficulty. This mechanism ensures that, in the long run, the network will agree on a single and valid chain, see Garay et al, bitcoin backbone protocol: analysis and application. In the advancement of cryptography-the european society of Cryptology (Advances in cryptography-eurocypt 2015), pages 281-310, year 2015, [ bitcoin site ]. http:// www.bitcoin. Org/], and [ Rafael Pass, color Seeman, and Abhi Shell. A blockchain protocol in an asynchronous network is analyzed. Pages 643-673, cham,2017, in the Cryptographic Advance edited as Jean-S.Basien Coron and Jesper Buus Nielsen, european Union of 2017 (Advances in cryptography-EUROCRYPT 2017). Schpringer International publication (Springer International Publishing). The above documents are incorporated herein by reference for all purposes.

Blockchain 800 may create a history of data deposits, messages, or entries in a series of chunks, where each chunk contains a mathematical summary (referred to as a hash) of the previous chunk. This creates a chain in which any change made to a chunk alters the hash of that chunk, which must be recalculated and stored in the next chunk. This changes the hash of the next chunk, which must also be recomputed, and so on, up to the end of the chain.

Although the hash may be computationally simple, a rule may be applied that requires the value of the hash to be below a certain threshold (i.e., a difficulty value). In addition, hashing is based on a class of irreversible mathematical functions. One cannot predict what inputs can be used to produce the desired output. A valid hash can be found by iteratively adjusting the variable values in the blocks and recomputing the hash until it meets the validity requirement. The freely changeable value may be a temporary number. The unpredictability of the hash greatly increases the difficulty of finding the nonce that produces a valid hash for the block.

For example, the first block 810 may include a block header 820 and a block entry 830. The chunk header 820 of the first chunk 810 may include the previous hash 812, the timestamp 814, the merkel root 816, and the nonce 818.

The previous hash 812 may be a hash of the header of the previous block. The previous hash 812 may be the result of an irreversible mathematical computation using data from the previous tile as input. According to some embodiments, the computation used may include a SHA256 hash function. It will be appreciated by those of ordinary skill in the art that any suitable hash function may be used without departing from the spirit and scope of the present invention. The hash function may be designed such that any change to the data in the previous tile causes an unpredictable change to the hash of the tile. The previous hash 812 may be a link between tiles that are linked together to form the blockchain 800.

When computing the previous hash 812 of the previous tile, the node may determine whether the previous hash 812 may satisfy some criterion defined by a difficulty value. In some embodiments, the difficulty value may include a number below which the computed hash must be smaller. However, since the output of the hash function is unpredictable, it is not possible to determine, prior to computing the hash, which input the output is unpredictable would result in an output that is less than the difficulty value. The nonce 818 may be used to change the data content of the chunk, allowing the hash function to produce a large number of different outputs in pursuit of an output that satisfies the difficulty value. This makes it computationally expensive to utilize nonce 818 to generate valid blocks that produce hash values that satisfy the difficulty value criteria.

The hashing algorithm used for the previous hash 812 may include MD5, SHA-1, SHA-224, SHA-256, SHA-384, SHA-512/224, SHA-512/256, SHA-3, or any suitable hashing function. Nor does it require that the hash be computed only once. The result of the hash function may be reused multiple times as an input to another or the same hash function to produce a final result. One of ordinary skill in the art will recognize that any hash function may be used to compute the desired hash without departing from the spirit and scope of the present invention.

The Meckel root 816 may be the root of a Meckel tree, which may include a tree in which each leaf node is labeled with a hash of a data chunk, such as an entry. Each leaf of the mekerr tree may represent one of the entries. Each entry may be hashed with a peer node (i.e., an entry) in the merkel tree. Successive hashing of sibling nodes in the Merkel tree may result in a Merkel root 816.

The block entry 830 may include settlement data and/or redemption data. For example, entry 1 may be a settlement between an authorized entity computer and a escrow computer, entry 2 may be a redemption between the escrow computer and an external computer, and so on. Chunk entry 830 may include any suitable number of entries. In some embodiments, the number of entries in block entries 830 may be limited by the overall size of the block (e.g., first block 810). For example, a block on a block chain may be limited by a certain amount of data (e.g., 1/2MB, 1MB, 2MB, 5MB, 10MB, etc.). In other embodiments, the number of entries in chunk entry 830 may be a predetermined number of entries. For example, a node in the authentication network may determine that 1 entry, 10 entries, 150 entries, 500 entries, 1000 entries, etc. may be included in tile entry 830.

Timestamp 814 may include the time at which the block was created within a certain error range. According to some embodiments of the invention, all nodes of the verification network may check the timestamp 814 against their own known times and may reject any blocks that appear to have an erroneous timestamp 814.

Nonce 818 may be a value that is adjusted by the full node when performing the workload attestation process as described herein. The nonce may be input into a hash function along with the chunk data to determine an output hash value. The correct nonce (also known as the golden nonce) results in an output hash value that meets a predetermined criterion, e.g., is less than a difficulty value.

Second block 840 may be similar to first block 810. For example, the second block 840 may include a block header 850 and a block entry 860. The chunk header 850 of the second chunk 840 may include a previous hash 852, a timestamp 854, a mekerr root 856, and a nonce 858. Chunk entry 860 may include settlement data and/or redemption data, and may be similar to chunk entry 830.

FIG. 9 illustrates a block diagram of an exemplary retention management computer 900. The depository computer 900 may be operated by a financial institution, such as a bank, payment processing network, digital asset bank, or the like. The depository computer 900 may maintain a digital vault of external entities. For example, the escrow computer 900 may maintain a digital currency vault for the payment processing network. The depository computer 900 may include a processor 902. The processor 902 may be coupled to memory 904, a network interface 906, and a computer-readable medium 908. Computer-readable media 908 may include any suitable number and type of software modules.

The memory 904 may be used for storing data and code. The memory 604 may be coupled to the processor 902 internally or externally (e.g., via cloud-based data storage) and may include any combination of volatile and/or non-volatile memory, such as RAM, DRAM, ROM, flash, or any other suitable memory device. In some embodiments, the memory 904 may store data items of the payload.

Network interface 906 may include an interface that may allow the depository computer 900 to communicate with external computers and/or devices. Network interface 906 may enable the depository computer 900 to transfer data to and from another device, such as a processing network computer, a processing network account computer, a transfer computer, an authorized entity computer, or the like. Some examples of network interface 906 may include a modem, a physical network interface (such as an ethernet card or other Network Interface Card (NIC)), a virtual network interface, a communications port, a Personal Computer Memory Card International Association (PCMCIA) slot and card, and so forth. Wireless protocols enabled through network interface 906 may include Wi-Fi ^TM . Data transferred via network interface 906 may be in the form of signals, which may be electrical, electromagnetic, optical, or any other signal capable of being received by an external communication interface(s) ((Collectively referred to as "electronic signals" or "electronic messages"). These electronic messages, which may include data or instructions, may be provided between network interface 906 and other devices via a communication path or channel. As noted above, any suitable communication path or channel may be used, such as wire or cable, fiber optics, a phone line, a cellular link, a Radio Frequency (RF) link, a WAN or LAN network, the Internet, or any other suitable medium.

The computer-readable medium 908 may include code executable by the processor 902 for performing a method comprising: receiving a transfer instruction file from the processing network computer, the transfer instruction file including a second settlement amount, a first destination associated with the digital vault at the escrow computer, and a second destination associated with the transport computer, wherein the processing network computer further transmits a settlement file to the authorizing entity computer, the settlement file including the first settlement amount and the first destination; receiving, at a digital vault associated with a first destination, a first settlement amount or an amount equal to the first settlement amount from an authorizing entity computer, the first settlement amount or the amount equal to the first settlement amount being equal to a second settlement amount; and sending a notification to the processing network computer that the escrow computer received the first calculated amount or the amount equivalent to the first calculated amount.

The computer-readable media 908 may include a number of software modules including, but not limited to, a vault management module 908A, a transfer module 908B, and a redemption module 908C.

The vault management module 908A may include code that causes the processor 902 to generate and maintain a digital vault. For example, the vault management module 908A may enable the vault computer 900 to generate digital currency vaults for processing networks. The vault management module 908A may add, roll out, or transfer digital assets stored in the digital vault. In some embodiments, the vault management module 908A enables the escrow computer 900 to generate a digital vault for processing networks that is unique to an external entity (e.g., an acquirer or an issuer).

The transfer module 908B may include code to cause the processor 902 to receive and execute the transfer. For example, the branch instruction file may be received by the retention management computer 900. The transfer module 908B may communicate with the vault management module 908A to transfer digital assets to and from different digital vaults. The transfer module 908B can identify the digital vault maintained by the vault management module 908A via a digital address or vault ID. The transfer module 908B can enable the retention computer 900 to communicate with the blockchain to complete the transfer of digital assets between digital vaults. The transfer module 908B can transfer the fiat currency to and from an external computer.

The conversion module 908C may include code that causes the processor 902 to convert between digital currency and legal currency. For example, the redemption module 908C may include or be in communication with a escrow account computer. The redemption module 908C may receive instructions to convert between the two types of currency and perform the conversion. For example, the redemption module 908C may receive instructions to convert 100 ten thousand dollars to 100 ten thousand USDC. The redemption module 908C may communicate with an external computer to complete the conversion. The conversion may include sending a monetary amount of the digital asset from the digital vault to another digital vault, or sending fiat currency to and from accounts maintained at different computers.

Fig. 10 shows a block diagram of a processing network computer 1000. The processing network computer 100 may facilitate settlement between an issuer and an acquirer. The processing network computer 100 may include a processor 1002. The processor 1002 may be coupled to memory 1002, a network interface 1006, and a computer-readable medium 1008. Computer-readable media 1008 may include any suitable number and type of software modules.

The memory 1002 and the network interface 1006 may have the same features or different features than the memory 902 and the network interface 906 previously described.

The computer-readable medium 1008 may include code executable by the processor 1002 for performing a method comprising: receiving a plurality of clearing files from a plurality of transmitting computers; generating a settlement file based on data in a plurality of clearing files, the settlement file including a first settlement amount and a first destination at a vault at an escrow computer associated with a digital vault associated with a server computer; sending a settlement file including the first settlement amount and the first destination to the authorized entity computer; and sending a transfer instruction file to the escrow computer, the transfer instruction file including a first destination, a second settlement amount, and a second destination associated with one of the plurality of transfer computers; and wherein the authorizing entity computer subsequently sends the first settlement amount or an amount equal to the first settlement amount to a first destination at the escrow computer, and wherein the escrow computer or the server computer sends a second settlement amount to a second destination associated with the transfer computer.

The computer-readable medium 1008 may include several software modules including, but not limited to, a settlement module 1008A, an account management module 1008B, and a communication module 1008C.

Settlement module 1008A may include code to cause processor 1002 to complete settlement. For example, settlement module 1008A may receive a clearing file from an acquirer and generate a settlement file and a transfer instruction file. Settlement module 1008A may identify a settlement amount and destination needed to complete the settlement.

The account management module 1008B may include code to cause the processor 1002 to maintain a process network account. For example, the account management module 1008B may cause the processor 1002 to communicate with a processing network account computer. In some embodiments, the account management module 1008B may allow the processing network computer 1000 to maintain processing network accounts. Account management module 1008B may communicate with settlement module 1008A to transfer digital currency and/or fiat currency to and from accounts associated with processing network computer 1000.

The communication module 1008C, in conjunction with the processor 1002, may generate messages, forward messages, reformat messages, and/or otherwise communicate with other entities. For example, the communication module 1008C may be used to facilitate handling communications between the network computer 1000 and other computers.

Embodiments of the present invention provide several advantages. Embodiments of the present invention allow transactions generated by a user associated with an issuer operating an authorizing entity computer and a resource provider associated with an acquirer operating a transmitting computer to be cleared and settled in different currency types. By way of illustration, the acquirer may indicate a currency type (e.g., legal currency type or digital currency type) that it wishes to receive settlement payments. The processing network computer and escrow computer may then allow the issuer to provide payment in the same or different currency types via several digital vaults. The digital vault may send and receive digital currency to and from other digital vaults by writing transactions to the blockchain. As described above, embodiments of the present invention may also make settlement payments anonymous between an issuer and an acquirer using multiple digital vaults with unique digital addresses on the blockchain. In addition, because some settlement processes according to embodiments may use digital currency, such settlement processes may be faster than purely conventional statutory settlement processes. Because embodiments may use blockchains to transfer value between the vault and external entities, the records associated with such transfers may be immutable, unlike traditional methods for storing such value transfers.

Any of the software components or functions described in this application may be implemented as software code executed by a processor using, for example, conventional or object-oriented techniques, and using any suitable computer language (e.g., java, C + +, or Perl). The software code may be stored as a series of instructions or commands on a computer readable medium such as Random Access Memory (RAM), read Only Memory (ROM), magnetic media such as a hard drive, or optical media such as a CD-ROM. Any such computer-readable media may reside on or within a single computing device, and may be present on or within different computing devices within a system or network.

The above description is illustrative and not restrictive. Many variations of the invention will become apparent to those skilled in the art upon review of the present disclosure. The scope of the invention may, 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 by reference in their entirety for all purposes. They are not admitted to be prior art.

Claims

1. A method, comprising:

receiving, by a processing network computer, a plurality of clearing files from a plurality of transmitting computers;

generating, by the processing network computer, a settlement file based on data in the plurality of settlement files, the settlement file including a first settlement amount and a first destination at a vault associated with the processing network computer;

sending, by the processing network computer, the settlement file including the first settlement amount and the first destination to an authorizing entity computer; and

sending, by the processing network computer, a transfer instruction file to the escrow computer, the transfer instruction file including the first destination, a second settlement amount, and a second destination associated with one of the plurality of transfer computers; and is

Wherein the authorizing entity computer subsequently sends the first settlement amount or an amount equal to the first settlement amount to the first destination at the escrow computer, and wherein the escrow computer or the processing network computer sends the second settlement amount to the second destination associated with the transfer computer.

2. The method of claim 1, wherein the second settlement amount is an amount of digital currency and the second destination is a second digital address.

3. The method of claim 1, wherein the second settlement amount is a fiat currency amount and the second destination is a bank account, and wherein the processing network computer sends the second settlement amount to the second destination associated with the transport computer.

4. The method of claim 1, wherein the processing network computer sends the second settlement amount to the second destination associated with the transport computer, and wherein the method further comprises:

sending, by the processing network computer, a message including a first redemption amount to the escrow computer, followed by the escrow computer providing a second redemption amount to a processing network account of the processing network computer, after which the processing network computer sends the second settlement amount to the second destination associated with the transfer computer.

5. The method of claim 1 wherein the authorizing entity computer subsequently sends the first calculated amount or an amount equal to the first calculated amount to the first destination at the escrow computer, and wherein the escrow computer sends the second settlement amount to the second destination associated with the transfer computer.

6. The method of claim 1, further comprising:

receiving, by the processing network computer from the escrow computer, confirmation of transfer of the second settlement amount to the second destination.

7. The method of claim 1, wherein the first settlement amount and the second settlement amount are digital currencies.

8. The method of claim 1, wherein the escrow computer transfers the first settlement amount from the authorizing entity computer to the digital vault of the processing network computer at the escrow computer via a blockchain.

9. The method of claim 1, wherein the processing network computer further generates and maintains a processing network account for payment to the transfer computer in legal currency.

10. The method of claim 1, wherein the plurality of clearing files contain transaction data associated with transactions conducted between a plurality of users and a resource provider using digital currency.

11. The method of claim 10, wherein the digital currency is a cryptocurrency.

12. A server computer, comprising:

a processor; and

a non-transitory computer-readable medium comprising code executable by the processor for performing:

receiving a plurality of clearing files from a plurality of transmitting computers;

generating a settlement file based on data in the plurality of clearing files, the settlement file including a first settlement amount and a first destination at a vault associated with the server computer;

sending the settlement file including the first settlement amount and the first destination to an authorized entity computer; and

sending a transfer instruction file to the escrow computer, the transfer instruction file including the first destination, a second settlement amount, and a second destination associated with one of the plurality of transfer computers; and is provided with

Wherein the authorizing entity computer subsequently sends the first settlement amount or an amount equal to the first settlement amount to the first destination at the escrow computer, and wherein the escrow computer or the server computer sends the second settlement amount to the second destination associated with the transfer computer.

13. The server computer of claim 14, wherein the server computer is a processing network.

14. The server computer of claim 14, wherein the authorizing entity computer subsequently sends the first settlement amount or an amount equivalent to the first settlement amount to the first destination at the escrow computer, and wherein the escrow computer sends the second settlement amount to the second destination associated with the transfer computer.

15. A method, comprising:

receiving, by the escrow computer, a transfer instruction file from the processing network computer, the transfer instruction file including a second settlement amount, a first destination associated with the digital vault at the escrow computer, and a second destination associated with the transport computer, wherein the processing network computer further sends a settlement file including the first settlement amount and the first destination to an authorizing entity computer;

receiving, at the digital vault associated with the first destination at the escrow computer, the first settlement amount or an amount equivalent to the first settlement amount from an authorizing entity computer, the first settlement amount or the amount equivalent to the first settlement amount being equal to the second settlement amount; and

sending, by the escrow computer to the processing network computer, a notification that the escrow computer received the first calculated amount or the amount equivalent to the first calculated amount.

16. The method of claim 16, wherein the first settlement amount and the second settlement amount are digital currencies.

17. The method of claim 16, wherein the transmitting computer is operated by an acquirer and the authorizing entity computer is operated by an issuer.

18. The method of claim 16, wherein the escrow computer receives the first settlement amount by transferring the first settlement amount from the authorizing entity computer to the digital vault of the processing network computer at the escrow computer via a blockchain.

19. The method of claim 16, wherein the processing network computer is configured to process credit card transactions and debit card transactions.

20. The method of claim 16, wherein the second settlement amount is an amount of digital currency and the second destination is a second digital address.