Patent Description:
This disclosure relates generally to encrypted communications and secured transactions and, in non-limiting embodiments or aspects, systems, methods, and computer program products, for conducting secured, encrypted transactions between computing devices while obfuscating transaction data from a central processing system.

Cryptocurrency transaction schemes often have the advantage of privacy due to non-centralized processing, but they can be computationally slow due to using a non-trust consensus protocol. Cryptocurrencies may also lack security protocols against the loss of private keys or third party attacks. Transactions via electronic checking accounts provide the advantage of security controls of associated issuer institutions and transaction service providers, but these methods may be subject to the lack of privacy and dependency of the issuer institution that holds the funds of the checking account. Transaction values and account balances remain visible to transaction processing systems. There is a need in the art for a technical solution that provides privacy often associated with non-centralized cryptocurrency schemes while also enhancing security and speed in computation often provided by centralized, electronic banking schemes.

<CIT> describes a method and system for implementing confidential and anonymous transactions in a blockchain, in particular for protecting privacy with respect to transaction amounts. <CIT> describes a zero-knowledge data management network for implementing secure financial transactions.

According to non-limiting embodiments or aspects, provided is a computer-implemented method for secured, encrypted transaction processing. The method includes receiving, with a transaction processing system, a transaction request initiated by at least one of a first computing device associated with a first user and a second computing device associated with a second user. The transaction request includes a first user token including a first token identifier and a first account balance. The first account balance is encrypted with a public key of a public/private key pair associated with the first user. The transaction request also includes a second user token including a second token identifier and a second account balance. The second account balance is encrypted with a public key of a public/private key pair associated with the second user. The transaction request also includes a transaction value. The method includes, in response to verifying the transaction request, generating, with the transaction processing system using a zero-knowledge computation, a new first account balance and a new second account balance based on the first account balance, the second account balance, and the transaction value. The method includes generating, with the transaction processing system, a new first user token including the new first account balance, the new first account balance encrypted with the public key of the public/private key pair associated with the first user. The method includes generating, with the transaction processing system, a new second user token including the new second account balance, the new second account balance encrypted with the public key of the public/private key pair associated with the second user.

In some non-limiting embodiments or aspects, the method may include, in response to receiving, from an issuer system associated with the first user, a first initial account balance encrypted with the public key of the public/private key pair associated with the first user, generating, with the transaction processing system, the first user token, and communicating, with the transaction processing system, the first user token to the first computing device associated with the first user.

In some non-limiting embodiments or aspects, the method may include, in response to receiving, from an issuer system associated with the second user, a second initial account balance encrypted with the public key of the public/private key pair associated with the second user, generating with the transaction processing system, the second user token, and communicating, with the transaction processing system, the second user token to the second computing device associated with the second user.

In some non-limiting embodiments or aspects, the transaction value may be encrypted with the public key of the public/private key pair associated with the first user. Generating the new first account balance may include executing, by the transaction processing system, a zero-knowledge subtraction of the transaction value from the first account balance. The new first user token may be digitally signed by the transaction processing system. Generating the new second account balance may include executing, by the transaction processing system, a zero-knowledge addition of the transaction value to the second account balance. The new second user token may be digitally signed by the transaction processing system.

In some non-limiting embodiments or aspects, the transaction request may be digitally signed with a private key of the public/private key pair associated with the first user. Verifying the transaction request may include decrypting, by the transaction processing system, the transaction request using the public key of the public/private key pair associated with the first user. The transaction request may be further digitally signed with a private key of the public/private key pair associated with the second user. Verifying the transaction request may further include decrypting, by the transaction processing system, the transaction request using the public key of the public/private key pair associated with the second user.

According to non-limiting embodiments or aspects, provided is a system including at least one transaction processing server including at least one processor. The at least one transaction processing server is programmed or configured to receive a transaction request initiated by at least one of a first computing device associated with a first user and a second computing device associated with a second user. The transaction request includes a first user token including a first token identifier and a first account balance. The first account balance is encrypted with a public key of a public/private key pair associated with the first user. The transaction request includes a second user token including a second token identifier and a second account balance. The second account balance is encrypted with a public key of a public/private key pair associated with the second user. The transaction request also includes a transaction value. The at least one transaction processing server is programmed or configured to, in response to verifying the transaction request, generate, using a zero-knowledge computation, a new first account balance and a new second account balance based on the first account balance, the second account balance, and the transaction value. The at least one transaction processing server is programmed or configured to generate a new first user token including the new first account balance, the new first account balance encrypted with the public key of the public/private key pair associated with the first user. The at least one transaction processing server is programmed or configured to generate a new second user token including the new second account balance, the new second account balance encrypted with the public key of the public/private key pair associated with the second user.

In some non-limiting embodiments or aspects, the at least one transaction processing server may be further programmed or configured to, in response to receiving, from an issuer system associated with the first user, a first initial account balance encrypted with the public key of the public/private key pair associated with the first user, generate the first user token and communicate the first user token to the first computing device associated with the first user. The at least one transaction processing server may be further programmed or configured to, in response to receiving, from an issuer system associated with the second user, a second initial account balance encrypted with the public key of the public/private key pair associated with the second user, generate the second user token and communicate the second user token to the second computing device associated with the second user.

In some non-limiting embodiments or aspects, the transaction value may be encrypted with the public key of the public/private key pair associated with the first user. Generating the new first account balance may include executing a zero-knowledge subtraction of the transaction value from the first account balance. Generating the new second account balance may include executing a zero-knowledge addition of the transaction value to the second account balance. The new first user token and the new second user token may be digitally signed by the at least one transaction processing server.

In some non-limiting embodiments or aspects, the transaction request may be digitally signed with a private key of the public/private key pair associated with the first user. Verifying the transaction request may include decrypting the transaction request using the public key of the public/private key pair associated with the first user. The transaction request may be further digitally signed with a private key of the public/private key pair associated with the second user. Verifying the transaction request may further include decrypting the transaction request using the public key of the public/private key pair associated with the second user.

According to non-limiting embodiments or aspects, provided is a computer program product including at least one non-transitory computer-readable medium including program instructions that, when executed by at least one processor, cause the at least one processor to receive a transaction request initiated by at least one of a first computing device associated with a first user and a second computing device associated with a second user. The transaction request includes a first user token including a first token identifier and a first account balance, the first account balance encrypted with a public key of a public/private key pair associated with the first user. The transaction request includes a second user token including a second token identifier and a second account balance, the second account balance encrypted with a public key of a public/private key pair associated with the second user. The transaction request further includes a transaction value. The program instructions further cause the at least one processor to, in response to verifying the transaction request, generate, using a zero-knowledge computation, a new first account balance and a new second account balance based on the first account balance, the second account balance, and the transaction value. The program instructions further cause the at least one processor to generate a new first user token including the new first account balance, the new first account balance encrypted with the public key of the public/private key pair associated with the first user. The program instructions further cause the at least one processor to generate a new second user token including the new second account balance, the new second account balance encrypted with the public key of the public/private key pair associated with the second user.

In some non-limiting embodiments or aspects, the program instructions may further cause the at least one processor to, in response to receiving, from an issuer system associated with the first user, a first initial account balance encrypted with the public key of the public/private key pair associated with the first user, generate the first user token, and communicate the first user token to the first computing device associated with the first user. The program instructions may further cause the at least one processor to, in response to receiving, from an issuer system associated with the second user, a second initial account balance encrypted with the public key of the public/private key pair associated with the second user, generate the second user token, and communicate the second user token to the second computing device associated with the second user.

These and other features and characteristics of the present disclosure, as well as the methods of operation and functions of the related elements of structures and the combination of parts and economies of manufacture, will become more apparent upon consideration of the following description and the appended claims with reference to the accompanying drawings, all of which form a part of this specification, wherein like reference numerals designate corresponding parts in the various figures. It is to be expressly understood, however, that the drawings are for the purpose of illustration and description only and are not intended as a definition of the limits of the disclosure.

Additional advantages and details are explained in greater detail below with reference to the non-limiting, exemplary embodiments that are illustrated in the accompanying schematic figures, in which:.

For purposes of the description hereinafter, the terms "end," "upper," "lower," "right," "left," "vertical," "horizontal," "top," "bottom," "lateral," "longitudinal," and derivatives thereof shall relate to the embodiments as they are oriented in the drawing figures. However, it is to be understood that the embodiments may assume various alternative variations and step sequences, except where expressly specified to the contrary. It is also to be understood that the specific devices and processes illustrated in the attached drawings, and described in the following specification, are simply exemplary embodiments or aspects of the disclosure. Hence, specific dimensions and other physical characteristics related to the embodiments or aspects disclosed herein are not to be considered as limiting.

No aspect, component, element, structure, act, step, function, instruction, and/or the like used herein should be construed as critical or essential unless explicitly described as such. Also, as used herein, the articles "a" and "an" are intended to include one or more items and may be used interchangeably with "one or more" and "at least one. " Furthermore, as used herein, the term "set" is intended to include one or more items (e.g., related items, unrelated items, a combination of related and unrelated items, and/or the like) and may be used interchangeably with "one or more" or "at least one. " Where only one item is intended, the term "one" or similar language is used. Also, as used herein, the terms "has," "have," "having," or the like are intended to be open-ended terms. Further, the phrase "based on" is intended to mean "based at least partially on" unless explicitly stated otherwise.

As used herein, the term "communication" may refer to the reception, receipt, transmission, transfer, provision, and/or the like, of data (e.g., information, signals, messages, instructions, commands, and/or the like). For one unit (e.g., a device, a system, a component of a device or system, combinations thereof, and/or the like) to be in communication with another unit means that the one unit is able to directly or indirectly receive information from and/or transmit information to the other unit. This may refer to a direct or indirect connection (e.g., a direct communication connection, an indirect communication connection, and/or the like) that is wired and/or wireless in nature. Additionally, two units may be in communication with each other even though the information transmitted may be modified, processed, relayed, and/or routed between the first and second unit. For example, a first unit may be in communication with a second unit even though the first unit passively receives information and does not actively transmit information to the second unit. As another example, a first unit may be in communication with a second unit if at least one intermediary unit processes information received from the first unit and communicates the processed information to the second unit.

As used herein, the term "computing device" may refer to one or more electronic devices configured to process data. A computing device may, in some examples, include the necessary components to receive, process, and output data, such as a processor, a display, a memory, an input device, a network interface, and/or the like. A computing device may be a mobile device. As an example, a mobile device may include a cellular phone (e.g., a smartphone or standard cellular phone), a portable computer, a wearable device (e.g., watches, glasses, lenses, clothing, and/or the like), a personal digital assistant (PDA), and/or other like devices. A computing device may also be a desktop computer or other form of non-mobile computer.

As used herein, the term "server" may refer to or include one or more computing devices that are operated by or facilitate communication and processing for multiple parties in a network environment, such as the Internet, although it will be appreciated that communication may be facilitated over one or more public or private network environments and that various other arrangements are possible. Further, multiple computing devices (e.g., servers, point-of-sale (POS) devices, mobile devices, etc.) directly or indirectly communicating in the network environment may constitute a "system. " Reference to "a server" or "a processor," as used herein, may refer to a previously-recited server and/or processor that is recited as performing a previous step or function, a different server and/or processor, and/or a combination of servers and/or processors. For example, as used in the specification and the claims, a first server and/or a first processor that is recited as performing a first step or function may refer to the same or different server and/or a processor recited as performing a second step or function.

As used herein, the term "transaction service provider" may refer to an entity that receives transaction authorization requests from merchants or other entities and provides guarantees of payment, in some cases through an agreement between the transaction service provider and an issuer institution. For example, a transaction service provider may include a payment network such as Visa® or any other entity that processes transactions. The term "transaction processing system" may refer to one or more computing devices operated by or on behalf of a transaction service provider, such as a transaction processing server executing one or more software applications. A transaction processing system may include one or more processors and, in some non-limiting embodiments or aspects, may be operated by or on behalf of a transaction service provider.

As used herein, the term "issuer institution" may refer to one or more entities, such as a bank, that provide accounts to customers for conducting transactions (e.g., payment transactions), such as initiating credit and/or debit payments. For example, an issuer institution may provide an account identifier, such as a primary account number (PAN), to a customer that uniquely identifies one or more accounts associated with that customer. The account identifier may be embodied on a portable financial device, such as a physical financial instrument, e.g., a payment card, and/or may be electronic and used for electronic payments. The term "issuer system" refers to one or more computer systems operated by or on behalf of an issuer institution, such as a server computer executing one or more software applications. For example, an issuer system may include one or more authorization servers for authorizing a transaction.

The term "account data," as used herein, refers to any data concerning one or more accounts for one or more users. Account data may include, for example, one or more account identifiers, user identifiers, transaction histories, balances, credit limits, issuer institution identifiers, and/or the like.

As used herein, the term "digital signature" refers to data generated based on an input (e.g., a message) that can be used to validate the authenticity of that input. For example, a digital signature may be generated based on processing input data with a cryptographic key (e.g., a private key in a public/private key pair, shared symmetric keys, etc.) and according to a cryptographic algorithm. The input data may be encrypted with a private key, may be hashed and then encrypted with a private key, and/or may be otherwise altered based on a key to produce the digital signature. To "digitally sign" data refers to the process of generating a digital signature based on that data. In some examples, a digital signature may be appended to or accompany the original input (which may be encrypted) for communication. A digital signature may be validated by processing it with a corresponding cryptographic key (e.g., a public key from the public/private key pair used to generate it) and according to a corresponding cryptographic algorithm. For example, a system receiving a message and a digital signature based on that message may input the message, the digital signature, and a corresponding public key to a cryptographic algorithm to determine if the digital signature is valid (e.g., and that the sender was in possession of the private key). It will be appreciated that other variations are possible for generating and validating a digital signature.

Non-limiting embodiments or aspects of the present disclosure improve over existing systems by providing secured transactions resistant to brute force and man-in-the-middle attacks. Furthermore, the described systems and methods allow for central transaction processing without requiring access to the actual values involved in the underlying transactions, promoting data privacy. Non-limiting embodiments or aspects of the described systems and methods improve computational efficiency by reducing time to validate and process transactions, facilitated by a centralizing processing authority. Non-limiting embodiments also reduce the number of discrete computing devices required for processing a transaction, as compared to decentralized cryptocurrency schemes. Users may continue to be associated with issuer institutions, allowing for enhanced security protocols provided by such institutions, while user token account balances remain obfuscated after initial setup, thereby enhancing security. Furthermore, issuer institutions may store protected/encrypted backups of user private keys, thereby preventing the complete loss of token funds if a private key is lost by the user.

Referring to <FIG>, provided is a system <NUM> for secured, encrypted transaction processing according to non-limiting embodiments or aspects. The system <NUM> may include a first computing device <NUM> associated with a first user <NUM> and a second computing device <NUM> associated with a second user <NUM>. The first user <NUM> may be associated with an issuer system <NUM> of a first issuer institution, whereby the first user's <NUM> ability to transact in the system <NUM> was initialized. The second user <NUM> may be associated with an issuer system <NUM> of a second issuer institution, which may be the same as the first issuer institution, whereby the second user's <NUM> ability to transact in the system <NUM> was initialized. The first computing device <NUM> is programmed or configured to store, in a local memory, a first user token <NUM> (e.g., an encrypted data object representative of a present state of a digital account of the first user <NUM>). The first user token <NUM> includes a token identifier <NUM> (e.g., a unique value or code that identifies the first user token <NUM>), a serial number <NUM> (e.g., an incremental value representative of the iteration of the first user token <NUM>), and a first account balance <NUM> (e.g., an amount or value associated with the first user token <NUM>). The first account balance <NUM> and/or other token data may be encrypted with a public key <NUM> of a public/private key pair associated with the first user <NUM>, so as to obfuscate the value associated with the first user token <NUM>.

The second computing device <NUM> is programmed or configured to store, in a local memory, a second user token <NUM> (e.g., an encrypted data object representative of a present state of a digital account of the second user <NUM>). The second user token <NUM> includes a token identifier <NUM> (e.g., a unique value or code that identifies the second user token <NUM>), a serial number <NUM> (e.g., an incremental value representative of the iteration of the second user token <NUM>), and a second account balance <NUM> (e.g., an amount or value associated with the second user token <NUM>). The second account balance <NUM> and/or other token data may be encrypted with a public key <NUM> of a public/private key pair associated with the second user <NUM>, so as to obfuscate the value associated with the second user token <NUM>.

The first user <NUM> may communicate with the second user <NUM> via messages (e.g., data packets) between the first computing device <NUM> and the second computing device <NUM>. The first user <NUM> and the second user <NUM> may agree to transact for a payment, such as from the first user <NUM> to the second user <NUM> or from the second user <NUM> to the first user <NUM>. When the users <NUM>, <NUM> agree, a transaction request <NUM> may be transmitted to the transaction processing system <NUM> (or to another system such as a payment gateway that subsequently communicates the transaction request <NUM> to the transaction processing system <NUM>) by the first computing device <NUM> and/or the second computing device <NUM>. The transaction request <NUM> may include the first user token <NUM>, the second user token <NUM>, and a transaction value. The transaction request <NUM> may include additional data and/or may arrange the order of the tokens <NUM>, <NUM> so as to indicate the payee and the payor of the transaction to be completed. The transaction request <NUM> may be digitally signed using a private key of another public/private key pair of the user associated with the submission of the transaction request <NUM>. For example, the first computing device <NUM> may communicate the transaction request <NUM> to the transaction processing system <NUM> after digitally signing the transaction request <NUM> with the private key of the public/private key pair associated with (e.g., possessed by) the first user <NUM> to generate a digital signature.

The transaction processing system <NUM>, in response to receiving the transaction request <NUM>, may verify the transaction request <NUM> (e.g., determine the validity/authenticity of the request for a transaction between the first user <NUM> and the second user <NUM>). Verification of the transaction request <NUM> may be based on validating the digital signature using the public key of the public/private key pair associated with the digital signature of the transaction request <NUM>. For example, if the transaction request <NUM> is digitally signed with the private key of the public/private key pair of the first user <NUM>, the transaction processing system <NUM> may verify the transaction request <NUM> by decrypting the digital signature using the corresponding public key. The transaction request <NUM> may be digitally signed with the private key of the first user <NUM> and/or the second user <NUM>. The transaction request <NUM> may include additional data, or the transaction processing system <NUM> may permute through the limited arrangements, to verify which or both parties that digitally signed the transaction request <NUM>.

In response to verifying the transaction request <NUM>, the transaction processing system <NUM> may generate, using a zero-knowledge computation, a new first account balance and a new second account balance based on the first account balance <NUM>, the second account balance <NUM>, and the transaction value of the transaction request <NUM>. The zero-knowledge computation provides for the subtraction or addition of the encrypted transaction value from the encrypted account balances <NUM>, <NUM> without revealing the values to the transaction processing system <NUM>, thus maintaining security and privacy of the users <NUM>, <NUM> involved with the transaction. For example, for an agreed transaction for payment from the first user <NUM> to the second user <NUM>, the transaction processing system <NUM> may execute a zero-knowledge subtraction of the encrypted transaction value from the first account balance <NUM> to generate a new encrypted first account balance, and the transaction processing system <NUM> may execute a zero-knowledge addition of the encrypted transaction value to the second account balance <NUM> to generate a new encrypted second account balance. Example schemes that may be used for zero-knowledge computation include, but are not limited to, the Benaloh cryptosystem, the Paillier cryptosystem, and zero-knowledge accumulators and set operations.

In non-limiting embodiments, the transaction processing system <NUM> may generate a new first user token <NUM> including the new first account balance that remains encrypted with the public key of the public/private key pair associated with the first user <NUM>. The transaction processing system <NUM> may digitally sign the new first user token <NUM> to provide a verification of the authenticity of the new first user token <NUM>. The new first user token <NUM> may have a same token identifier <NUM> as the previous first user token <NUM> but a new serial number (e.g., incremented by one) to identify the new first user token <NUM> and indicate a state/version of the new first user token <NUM>, respectively. The transaction processing system <NUM> may generate a new second user token <NUM> including the new second account balance that remains encrypted with the public key of the public/private key pair associated with the second user <NUM>. The transaction processing system <NUM> may digitally sign the new second user token <NUM> to provide a verification of the authenticity of the new second user token <NUM>. The new second user token <NUM> may have the same token identifier <NUM> as the previous second user token <NUM> but a new serial number (e.g., incremented by one) to identify the new second user token <NUM> and indicate a state/version of the new second user token <NUM>, respectively. The transaction processing system <NUM> may communicate the new first user token <NUM> to the first computing device <NUM> and the new second user token <NUM> to the second computing device <NUM>, either directly or indirectly (e.g., through an issuer institution associated with the respective computing device <NUM>, <NUM>, or through the computing device <NUM>, <NUM> that communicated the transaction request <NUM> to the transaction processing system <NUM>). For directly communicated new tokens <NUM>, <NUM>, the transaction processing system <NUM> may communicate a confirmation to one computing device (e.g., <NUM>) when the other computing device (e.g., <NUM>) has confirmed receipt of its respective new token <NUM>, <NUM>.

Referring to <FIG>, provided is a system <NUM> for secured, encrypted transaction processing according to non-limiting embodiments or aspects. When transacting users agree, a transaction request <NUM> may be transmitted to the transaction processing system <NUM> by one or more computing devices of the users. The transaction request <NUM> may include the first user token <NUM>, the second user token <NUM>, and a transaction value <NUM>. The transaction request <NUM> may include additional data or arrange the order of the tokens <NUM>, <NUM> so as to indicate the payee and the payor of the transaction to be completed. The transaction request <NUM> may be digitally signed using a private key of a public/private key pair of the user associated with (e.g., possessed by) the submission of the transaction request <NUM> to generate a digital signature.

The transaction processing system <NUM>, in response to receiving the transaction request <NUM>, may verify the transaction request <NUM> (e.g., determine the validity/authenticity of the request for a transaction between the users). Verification may include validation of the signatures of the tokens (e.g., keys are operational and not revoked), validation of the signature of the transaction, verification of consistent currencies used in token account balances and transaction value <NUM>, and/or verification that the transaction value <NUM> is less than the amount of the account balance of the token of the paying party (e.g., through a zero-knowledge computation). Verification of the transaction request <NUM> may be based on validating the digital signature using the public key of the public/private key pair associated with the digital signing of the transaction request <NUM>. The transaction request <NUM> may include additional data, or the transaction processing system <NUM> may permute through the limited arrangements, to verify which or both parties that digitally signed the transaction request <NUM>. In response to verifying the transaction request <NUM>, the transaction processing system <NUM> may generate, using a zero-knowledge computation, a new first account balance <NUM> and a new second account balance <NUM> based on the first account balance <NUM>, the second account balance <NUM>, and the transaction value <NUM> of the transaction request <NUM>. The zero-knowledge computation provides for the subtraction or addition of the encrypted transaction value <NUM> from the encrypted account balances <NUM>, <NUM> without revealing the values to the transaction processing system <NUM>, maintaining security and privacy of the users involved with the transaction.

The transaction processing system <NUM> may generate a new first user token <NUM> including the new first account balance <NUM> that remains encrypted with the public key of the public/private key pair associated with the first user. The transaction processing system <NUM> may digitally sign the new first user token <NUM> to provide verification of the authenticity of the new first user token <NUM>. The new first user token <NUM> may have a same token identifier <NUM> as the previous first user token <NUM> but a new serial number <NUM> (e.g., incremented by one) to identify the new first user token <NUM> and indicate a state/version of the new first user token <NUM>, respectively. The transaction processing system <NUM> may generate a new second user token <NUM> including the new second account balance <NUM> that remains encrypted with the public key of the public/private key pair associated with the second user. The transaction processing system <NUM> may digitally sign the new second user token <NUM> to provide verification of the authenticity of the new second user token <NUM>. The new second user token <NUM> may have the same token identifier <NUM> as the previous second user token <NUM> but a new serial number <NUM> (e.g., incremented by one) to identify the new second user token <NUM> and indicate a state/version of the new second user token <NUM>, respectively. The transaction processing system <NUM> may include a database of token identifiers and corresponding serial numbers representative of current, valid tokens. For example, if a transaction request <NUM> is received that includes a token having a serial number that is not the most up-to-date serial number for the token, the transaction request <NUM> may be declined, thereby maintaining security and efficacy of the system.

The tokens <NUM>, <NUM>, <NUM>, <NUM> may further contain personal information associated with the identity or address of the corresponding user, which may enable transactions in certain instances where a transaction might otherwise be prohibited by regulation. The personal information may be provided by a trusted entity (e.g., as part of a public key hierarchy) so that the root of the trust (e.g., a transaction system) could certify which entities (e.g., issuer institutions) are trusted to issue personal information attributes. The transaction request <NUM> may further contain additional data relevant to the execution of the transaction, including identity of the payee user, identity of the payor user, currency, date of transaction, time of transaction, expiry of transaction (e.g., a date and/or time after which the transaction cannot be validly processed). The additional transaction information may be encrypted along with the transaction value.

Referring to <FIG>, provided is a system <NUM> for secured, encrypted transaction processing according to non-limiting embodiments or aspects, depicting an architecture for issuer institutions <NUM> to request digital money from a central reserve <NUM> (e.g., the Federal Reserve or some other like entity). The system includes one or more issuer institutions <NUM>, each associated with a digital holding account <NUM> including one or more tokens having a balance of digital currency for the issuer institution <NUM>. Issuer institutions <NUM> may assign digital currency to tokens of users from their own digital holding account <NUM> of one or more tokens. To convert regular currency to digital currency, an issuer institution <NUM> communicates a transfer request <NUM> to the central reserve <NUM> for an amount of regular currency to be converted to an equivalent value in digital currency. The transfer request <NUM> may include a token of the issuer institution <NUM>. The central reserve <NUM> validates <NUM> that the requesting issuer institution <NUM> has sufficient funds in a corresponding issuer institution account <NUM> held with the central reserve <NUM>, and validates <NUM> that the central reserve <NUM> has sufficient equivalent digital funds in a central reserve digital holding account <NUM>, which may include one or more tokens of the central reserve <NUM>. If the issuer institution <NUM> does not have sufficient funds in its corresponding issuer institution account <NUM>, the central reserve <NUM> may decline the transfer request <NUM>. If the issuer institution <NUM> does have sufficient funds in its corresponding issuer institution account <NUM>, the central reserve <NUM> may subtract <NUM> the requested amount to be transferred from the balance of the issuer institution account <NUM>.

With continued reference to <FIG>, if the central reserve <NUM> does not have sufficient equivalent digital funds in the central reserve digital holding account <NUM>, the central reserve <NUM> may communicate a minting request <NUM> to a digital mint <NUM> for an amount equal to or greater than the deficiency in digital funds. The digital mint <NUM> may be an entity operated and/or controlled by the central reserve <NUM>. In response to the minting request <NUM>, the digital mint <NUM> may generate and transfer <NUM> the requested digital funds from the minting request <NUM> to the central reserve digital holding account <NUM>. Once the central reserve <NUM> verifies that the central reserve digital holding account <NUM> has sufficient equivalent funds to satisfy the transfer request <NUM> from the issuer institution <NUM>, the central reserve <NUM> may communicate a transaction request <NUM> to a transaction processing system <NUM> to subtract the requested value of digital funds from the central reserve digital holding account <NUM> and add the requested value of digital funds to the issuer institution digital holding account <NUM>. The transaction request <NUM> may include the token of the issuer institution <NUM> and a token of the central reserve <NUM>.

In non-limiting embodiments or aspects, in response to receiving the transaction request <NUM> from the central reserve <NUM> and verifying the transaction request <NUM>, the transaction processing system <NUM> may process <NUM> the transaction request <NUM> to debit the reserve digital holding account <NUM> and credit the issuer institution digital holding account <NUM> using a zero-knowledge computation and the provided tokens of the issuer institution <NUM> and the central reserve <NUM>. In doing so, the transaction processing system <NUM> may generate a new token for the issuer institution <NUM> and a new token for the central reserve <NUM>. The transaction processing system <NUM> may then communicate <NUM> the new token for the central reserve <NUM> back to the central reserve <NUM>. The transaction processing system <NUM> may also communicate <NUM> the new token for the issuer institution <NUM> back to the issuer institution <NUM>. The new token of the central reserve <NUM> will include a balance that is reduced the amount of the transfer request <NUM>, and the new token of the issuer institution <NUM> will include a balance that is increased the amount of the transfer request <NUM>.

Referring to <FIG>, provided is a method <NUM> for secured, encrypted transaction processing according to non-limiting embodiments or aspects. The method <NUM> may be executed by one or more processors of a transaction processing system <NUM>, a first computing device <NUM>, a second computing device <NUM>, and/or other computing device. In step <NUM>, the transaction processing system <NUM> receives a transaction request initiated by at least one of a first computing device associated with a first user and a second computing device associated with a second user. The transaction request represents a request for a transfer of value from one user token to another. The transaction request includes a first user token <NUM> including a first token identifier and a first account balance. The first account balance is encrypted with a public key of a public/private key pair associated with the first user. The transaction request also includes a second user token <NUM>. The second user token includes a second token identifier and a second account balance. The second account balance is encrypted with a public key of a public/private key pair associated with the second user. The transaction request further includes a transaction value <NUM>. The transaction value <NUM> may be encrypted with the public key of the public/private key pair associated with the first user. The transaction request may be digitally signed with a private key of the public/private key pair associated with the first user and/or a private key of the public/private key pair associated with the second user.

In step <NUM>, the transaction processing system may verify the transaction request. Verifying the transaction request may include validating the digital signature of the transaction request, or an attribute thereof, using the public key of the public/private key pair associated with the first user and/or the second user. Further in step <NUM>, in response to verifying the transaction request, the transaction processing system generates, using a zero-knowledge computation, a new first account balance and a new second account balance based on the first account balance, the second account balance, and the transaction value. For example, the transaction processing system may, in the encryption domain, compute a subtraction of the encrypted transaction value from the encrypted account balance of the payor, and compute an addition to the encrypted transaction value of the payee. In step <NUM>, the transaction processing system may generate a new first user token including the new first account balance. The new first account balance may continue to be encrypted with the public key of the public/private key pair associated with the first user. The new first user token may be digitally signed by the transaction processing system. In step <NUM>, the transaction processing system may generate a new second user token including the new second account balance. The new second account balance may continue to be encrypted with the public key of the public/private key pair associated with the second user. The new second user token may be digitally signed by the transaction processing system.

Referring to <FIG>, provided is a method <NUM> for secured, encrypted transaction processing according to non-limiting embodiments or aspects. The method <NUM> may be executed by one or more processors of a transaction processing system <NUM>, a first computing device <NUM>, a second computing device <NUM>, a first issuer system <NUM>, a second issuer system <NUM>, and/or other computing device. Method <NUM> depicts an example initialization process to generate initial tokens for users, after which users may transact using the tokens. In step <NUM>, the transaction processing system may receive, from an issuer system associated with the first user, a first initial account balance encrypted with the public key of the public/private key pair associated with the first user. The first initial account balance may be generated and verified in funds by the issuer system so as to allow a first user token to be generated including the first initial account balance. In response to receiving the first initial account balance, the transaction processing system may, in step <NUM>, generate the first user token including the first initial account balance and communicate, in step <NUM>, the first user token to the first computing device associated with the first user.

In step <NUM>, the transaction processing system may receive, from an issuer system associated with the second user, a second initial account balance encrypted with the public key of the public/private key pair associated with the second user. The second initial account balance may be generated and verified in funds by the issuer system so as to allow a second user token to be generated including the second initial account balance. In response to receiving the second initial account balance, the transaction processing system may, in step <NUM>, generate the second user token including the second initial account balance and communicate, in step <NUM>, the second user token to the second computing device associated with the second user. Thereafter, users may interact via respective computing devices and communicate a transaction request to the transaction processing system, in step <NUM>.

Referring now to <FIG>, illustrated is a diagram of example components of device <NUM>. Device <NUM> may correspond to one or more devices of first computing device <NUM>, second computing device <NUM>, transaction processing system <NUM>, issuer system <NUM>, issuer system <NUM>, issuer institution <NUM>, central reserve <NUM>, and/or digital mint <NUM>. In some non-limiting embodiments or aspects, one or more devices of the foregoing may include at least one device <NUM> and/or at least one component of device <NUM>. As shown in <FIG>, device <NUM> may include a bus <NUM>, a processor <NUM>, memory <NUM>, a storage component <NUM>, an input component <NUM>, an output component <NUM>, and a communication interface <NUM>. Bus <NUM> may include a component that permits communication among the components of device <NUM>. In some non-limiting embodiments or aspects, processor <NUM> may be implemented in hardware, firmware, or a combination of hardware and software. For example, processor <NUM> may include a processor (e.g., a central processing unit (CPU), a graphics processing unit (GPU), an accelerated processing unit (APU), etc.), a microprocessor, a digital signal processor (DSP), and/or any processing component (e.g., a field-programmable gate array (FPGA), an application-specific integrated circuit (ASIC), etc.) that can be programmed to perform a function. Memory <NUM> may include random access memory (RAM), read only memory (ROM), and/or another type of dynamic or static storage device (e.g., flash memory, magnetic memory, optical memory, etc.) that stores information and/or instructions for use by processor <NUM>.

With continued reference to <FIG>, storage component <NUM> may store information and/or software related to the operation and use of device <NUM>. For example, storage component <NUM> may include a hard disk (e.g., a magnetic disk, an optical disk, a magneto-optic disk, a solid state disk, etc.) and/or another type of computer-readable medium. Input component <NUM> may include a component that permits device <NUM> to receive information, such as via user input (e.g., a touch screen display, a keyboard, a keypad, a mouse, a button, a switch, a microphone, etc.). Additionally, or alternatively, input component <NUM> may include a sensor for sensing information (e.g., a global positioning system (GPS) component, an accelerometer, a gyroscope, an actuator, etc.). Output component <NUM> may include a component that provides output information from device <NUM> (e.g., a display, a speaker, one or more light-emitting diodes (LEDs), etc.). Communication interface <NUM> may include a transceiver-like component (e.g., a transceiver, a separate receiver and transmitter, etc.) that enables device <NUM> to communicate with other devices, such as via a wired connection, a wireless connection, or a combination of wired and wireless connections. Communication interface <NUM> may permit device <NUM> to receive information from another device and/or provide information to another device. For example, communication interface <NUM> may include an Ethernet interface, an optical interface, a coaxial interface, an infrared interface, a radio frequency (RF) interface, a universal serial bus (USB) interface, a Wi-Fi® interface, a cellular network interface, and/or the like.

Claim 1:
A computer-implemented method comprising:
receiving (<NUM>), with a transaction processing system, a transaction request initiated by at least one of a first computing device associated with a first user and a second computing device associated with a second user, the transaction request being digitally signed using a private key of a public/private key pair of a user associated with the initiation of the transaction request to generate a digital signature, the transaction request comprising:
a first user token (<NUM>) comprising a first token identifier and a first account balance, the first account balance encrypted with a public key of a public/private key pair associated with the first user;
a second user token (<NUM>) comprising a second token identifier and a second account balance, the second account balance encrypted with a public key of a public/private key pair associated with the second user; and
a transaction value (<NUM>);
verifying, in response to receiving the transaction request, the transaction request by validating the digital signature using the public key of the public/private key pair of the user associated with the initiation of the transaction request;
in response to verifying the transaction request, generating (<NUM>), with the transaction processing system using a zero-knowledge computation, a new first account balance and a new second account balance based on the first account balance, the second account balance, and the transaction value;
generating (<NUM>), with the transaction processing system, a new first user token comprising the new first account balance, the new first account balance encrypted with the public key of the public/private key pair associated with the first user;
generating (<NUM>), with the transaction processing system, a new second user token comprising the new second account balance, the new second account balance encrypted with the public key of the public/private key pair associated with the second user; and
communicating the new first user token to the first computing device and the new second user token to the second computing device.