Techniques for performing safe operations

Abstract

The systems and methods described herein can be used to perform operations in a faster and less complex manner than provided by conventional systems. An encrypted record can be stored at a user device. The encrypted record can include entries related to operations previously requested by the user device. The encrypted record can be encrypted using a dynamic value and a key associated with an entity associated with a user. A recipient computer of a request from the user device can be configured to use the dynamic value provided in the request and the key associated with the entity to derive one or more encryption keys that were ultimately used to encrypt the record. The recipient computer can decrypt the decrypted record and modify it to perform the requested operation, while the user device cannot do so.

Description

[0001] Cross-reference to related applications

[0002] This international application claims priority to U.S. Provisional Patent Application No. 62 / 664,675, filed on April 30, 2018, the disclosure of which is incorporated herein by reference in its entirety for all purposes. Background Art

[0003] Conventional authorization systems typically require the transmission of authorization request messages through resource provider computers to a transmission computer and then to a processing network computer. The processing network computer is conventionally configured to route the message to an authorization entity computer for authorization processing. This conventional transmission path includes a certain amount of inherent delay. Improvements can be made to reduce the delay of the authorization system while maintaining a high degree of security.

[0004] Embodiments of the invention address these and other problems individually and collectively. Summary of the invention

[0005] One embodiment of the present invention relates to a method, the method comprising receiving a request to perform an operation from a requesting device. In some embodiments, the request is received in a request message including an encrypted record and a first dynamic value. The encrypted record may include a set of one or more entries corresponding to one or more previously performed operations associated with a user of the requesting device. The method may further include authorizing the request using the encrypted record, a first cryptographic key derived from a unique key associated with an authorization entity, and a first dynamic value. The method may further include performing one or more operations based at least in part on the request being authorized. The method may further include generating a modified encrypted record, the modified encrypted record including data associated with the one or more operations performed. The method may further include transmitting at least the modified encrypted record and an indication that the operation has been performed to the requesting device.

[0006] Another embodiment of the present invention relates to a secure processing computer, which includes one or more processors and one or more memories storing executable instructions, which when executed by the one or more processors cause the secure processing computer to perform the above method. In some embodiments, one or memories include a first secure memory space and a second secure memory space. The first secure memory space can store code, which when executed by the one or more processors causes the secure processing computer to derive and generate one or more cryptographic keys. In some embodiments, the second secure memory space stores code, which when executed by the one or more processors causes the secure processing computer to decrypt encrypted records to generate decrypted records and perform authorization processing using the decrypted records. In some embodiments, the first secure memory space and the second secure memory space can be the same secure memory space.

[0007] Another embodiment of the present invention relates to an authorization entity computer, which includes one or more processors and one or more memories storing executable instructions, which when executed by the one or more processors cause the authorization entity computer to perform a method. The method may include generating a unique key associated with the authorization entity. The method may further include receiving a first request to perform a first operation from a user device. In some embodiments, the first request may be received in a first request message including a first cryptographic key derived from the unique key. The method may further include performing the first operation based at least in part on the first request. The method may further include generating a record corresponding to a user associated with the first request. In some embodiments, the record may include a record entry indicating that the first operation has been performed. The method may further include generating a second cryptographic key based at least in part on the unique key and the first dynamic value. The method may further include generating an encrypted record based at least in part on the record, the first cryptographic key, and the second cryptographic key. The method may further include transmitting the encrypted record, the first dynamic value, and an indication that the first operation has been performed to the user device.

[0008] Another embodiment of the present invention relates to a user device, comprising one or more processors and one or more memories storing executable instructions, which when executed by the one or more processors cause the user device to perform a method. The method may include storing a first cryptographic key associated with an authorized entity in the one or more memories. In some embodiments, the first cryptographic key may be derived from a unique key associated with the authorized entity. The unique key may be unknown to the user device. The method may further include receiving a user input indicating a request for a first operation. The method may further include transmitting a first request to perform the first operation to an authorized entity computer. In some embodiments, the first request may be transmitted in a first request message including the first cryptographic key. The method may further include receiving a first response to the first request, the first response being received in a response message including a first encrypted record, an indication that the first operation has been performed, and a first dynamic value associated with the first encrypted record. The method may further include displaying data indicating that the first operation has been performed. The method may further include storing the first encrypted record and the first dynamic value in one or more memories of the user device.

[0009] These and other embodiments of the invention are described in further detail below. BRIEF DESCRIPTION OF THE DRAWINGS

[0010] Figure 1 A block diagram illustrating two authorization systems and methods that may be used to reduce authorization processing delays according to some embodiments of the present invention.

[0011] Figure 2 A block diagram of a secure processing computer is shown in accordance with at least one embodiment.

[0012] Figure 3A and 3B Each illustrates a registration process according to some embodiments.

[0013] Figure 4 A method for performing an operation (eg, a load operation) using an encrypted record is shown in accordance with some embodiments.

[0014] Figure 5 An exemplary plain text record is shown in accordance with some embodiments.

[0015] Figure 6 Another method for performing an operation (eg, an authorization operation) using an encrypted record in accordance with some embodiments is shown. DETAILED DESCRIPTION

[0016] Embodiments of the present invention may provide exemplary systems, devices, and methods for performing authorization processing and related activities. Although reference may be made to transactions of a payment system in the examples provided below, the embodiments are not limited thereto. That is, the systems, methods, and devices described herein may be used for any suitable purpose.

[0017] Before discussing embodiments of the present invention, describing some terms may help in understanding embodiments of the present invention.

[0018] A "server computer" may generally be a single powerful computer or a cluster of computers. For example, a server computer may be a mainframe, a cluster of small computers, or a group of servers that function as a unit. In one example, a server computer may be a database server coupled to a network server. A server computer may be associated with an entity such as a merchant, a payment processing network, a wallet provider, a merchant, an authentication cloud, an acquirer, or an issuer.

[0019] A "user device" may be any suitable electronic device that can process information and communicate the information to other electronic devices. A user device may include a processor and a computer-readable medium coupled to the processor, the computer-readable medium including code executable by the processor. The user devices may also each include an external communication interface for communicating with each other and other entities. Examples of user devices may include mobile devices, laptop or desktop computers, wearable devices, vehicles with remote communication capabilities, and the like.

[0020] A "resource provider" may be an entity that makes resources available to users. Examples of resource providers include merchants, vendors, suppliers, owners, traders, etc. In some embodiments, such entities may be a single individual, a small group of individuals, or a larger group of individuals (e.g., a company). A resource provider may be associated with one or more physical locations (e.g., supermarkets, shopping malls, stores, etc.) and online platforms (e.g., mobile applications, e-commerce websites, online companies, etc.). In some embodiments, a resource provider may make physical items (e.g., goods, products, etc.) available to users. In other embodiments, a resource provider may make digital resources (e.g., electronic documents, electronic files, etc.) available to users (e.g., provide access rights to users). In other embodiments, a resource provider may manage user access to certain resources (e.g., passwords, codes, etc.).

[0021] A "resource provider computing device" may include any system associated with a resource providing entity. In some embodiments, a resource provider computer may handle functionality of a mobile application and / or website associated with a resource providing entity from which a user may conduct online transactions. A resource provider computing device may also be referred to as a "resource provider computer." A "resource provider computer" may be any suitable computing device that may be operated by or on behalf of a resource provider.

[0022] A "communication device" may be an example of a "user device" and may include any suitable electronic device that can be operated by a user, which may also provide the ability to communicate remotely with a network. A "mobile communication device" may be an example of a "communication device" that can be easily transferred. Examples of remote communication capabilities include the use of a mobile phone (wireless) network, a wireless data network (e.g., 3G, 4G or similar network), Wi-Fi, Wi-Max, or any other communication medium that can 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, laptops, personal music players, handheld dedicated readers, etc. Other examples of mobile communication devices include wearable devices, such as smart watches, fitness bracelets, anklets, rings, earrings, etc., and cars with remote communication capabilities. In some embodiments, the mobile communication device can act as a payment device (e.g., the mobile communication device can store and be able to transmit payment credentials for transactions).

[0023] "User" may include an individual. In some embodiments, a user may be associated with one or more personal accounts and / or mobile devices. In some embodiments, a user may also be referred to as a cardholder, account holder, or consumer.

[0024] An "acquirer" may generally be a business entity (e.g., a commercial bank) that has a business relationship with a particular merchant or other entity. Some entities may perform both issuer and acquirer functions. Some embodiments may encompass such a single entity issuer-acquirer. An acquirer may operate an acquirer computer, which may also be generally referred to as a "transmitting computer."

[0025] An "authorized entity" may be an entity that authorizes a request. Examples of authorized entities may be issuers, government agencies, document repositories, access administrators, etc. An "authorized entity computer" may be any suitable computing device operable by or on behalf of an authorized entity.

[0026] An "issuer" may generally refer to a business entity (e.g., a bank) that maintains a user account. An issuer may also issue payment credentials to a consumer that are stored on a user device such as a cell phone, smart card, tablet computer, or laptop computer. An issuer may be an example of an authorized entity.

[0027] A "record" may be a container for data. A record may be a list, a database, or a record may be in any suitable form. An "encrypted record" refers to a record that has been encrypted using any suitable cryptographic algorithm. "Encryption" refers to the process of converting data into code to prevent unauthorized access. As used herein, encryption may include providing input to any suitable encryption algorithm to obtain an encrypted version of the input. Similarly, "decryption" is the process of converting encrypted code into data to enable access to the data. As used herein, decryption may include providing input to any suitable decryption algorithm to obtain a decrypted version of the input.

[0028] A "processing network computer" may include a server computer for processing network data. In some embodiments, the processing network computer may be coupled to a database and may include any hardware, software, other logic, or combination of the foregoing items for servicing requests from one or more client computers. The processing network computer may include one or more computing devices and may use any of a variety of computing structures, arrangements, and compilations to service requests from one or more client computers. In some embodiments, the processing network computer may operate multiple server computers. In such embodiments, each server computer may be configured to process transactions for a given area or to process a specific type of transaction based on transaction data.

[0029] The processing network computer may include data processing subsystems, networks, and operations for supporting and delivering authorization services, exception file services, and clearing and settlement services. Exemplary processing network computers may include VisaNet TM . Including VisaNet TM The network includes the ability to process credit card transactions, debit card transactions and other types of commercial transactions. VisaNet TM Specifically include the integrated payment system (integrated payment system) that processes authorization requests and the BaseII system that performs clearing and settlement services. The processing network computer can use any suitable wired or wireless network, including the Internet.

[0030] An "authorization request message" may be an electronic message sent to a transaction processing computer and / or an authorization entity computer (e.g., the issuer of a payment card) to request authorization of a transaction. The authorization request message according to some embodiments may comply with ISO 8583, which is a standard for systems for exchanging electronic transaction information associated with payments made by consumers using payment devices or payment accounts. The authorization request message may include an issuer account identifier that may be associated with the payment device or payment account. The authorization request message may also include additional data elements corresponding to "identification information", including, by way of example only: service code, CVV (card verification value), dCVV (dynamic card verification value), expiration date, etc. The authorization request message may also include "transaction information", such as any information associated with the current transaction, such as the 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.

[0031] An "authorization response message" may be an electronic message reply to an authorization request message generated by an authorization entity computer or a processing network computer. By way of example only, the authorization response message may include one or more of the following status indicators: approved - the transaction is approved; rejected - the transaction is not approved; or call center - the response is pending and more information, the merchant must call a toll-free authorization phone number. The authorization response message may also include an authorization code, which may be a code that the authorization entity (e.g., an issuer bank) transmits back to the resource provider computer in response to the authorization request message in an electronic message (directly or through a transaction processing computer) indicating that the transaction is approved. The code may serve as evidence of authorization. In some embodiments, the processing network computer may generate the authorization response message or forward the authorization response message to the resource provider.

[0032] A "digital signature" can include a value that can be used to verify the authenticity of digital data. A valid digital signature can give the recipient reason to believe that the data was created by a known entity, that the creator cannot deny having created the data, and that the data has not been altered.

[0033] "Processor" may refer to any suitable one or more data computing devices. A processor may include one or more microprocessors working together to perform the desired functions. A processor may include a CPU including at least one high-speed data processor sufficient to execute program components for executing user and / or system generated requests. A CPU may be a microprocessor such as AMD's Athlon, Duron, and / or Opteron; IBM and / or Motorola's PowerPC; IBM and Sony's Cell processor; Intel's Celeron, Itanium, Pentium, Xeon, and / or XScale; and / or similar one or more processors.

[0034] "Memory" may be any suitable device or devices that can store electronic data. Suitable memory may include a non-transitory computer-readable medium that stores instructions executable by a processor to implement the desired method. Examples of memory may include one or more memory chips, disk drives, etc. Such memory may operate using any suitable electrical, optical, and / or magnetic operating modes.

[0035] In the following examples, various encryption and decryption processes are described. Suitable encryption and / or decryption processes may include the use of AES, DES, triple DES, etc.

[0036] In the following examples, payment is discussed as an exemplary use case. However, it should be understood that the methods and systems can be used in other contexts, including access to secure data on a network or any other suitable interaction between two entities.

[0037] Figure 1 A block diagram showing an exemplary authorization system 100 and a method for reducing authorization processing delay according to some embodiments of the present invention is shown. Figure 1As shown, conventional authorization systems may include several components. For example, conventional authorization systems may include a user (e.g., user 102) who can operate a user device 104. User 102 may use user device 104 to pay for a website for goods or services hosted by a resource provider computer 106. Resource provider computer 106 may be operated by or on behalf of a resource provider (e.g., a merchant). It should be understood that a website associated with a resource provider may be hosted by a computing device (not shown) that is separate from resource provider computer 106 but communicates with resource provider computer 106. Resource provider computer 106 may communicate with an authorization entity computer (e.g., authorization entity computer 108) that is operated by or on behalf of an authorization entity (e.g., an issuer) via a transmission computer (e.g., transmission computer 110) operated by or on behalf of an acquirer and a processing network computer (e.g., a processing network computer) that operates as part of a processing network (e.g., a payment processing network).

[0038] The 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 processing network may include VisaNet TM For example, VisaNet TM VisaNet is a processing network that processes credit card transactions, debit card transactions, and other types of commercial transactions. TM Specifically include the VIP system (Visa Integrated Payment System) that processes authorization requests and the Base II system that performs clearing and settlement services. The processing network can use any suitable wired or wireless network including the Internet.

[0039] A conventional authorization flow using the user device 104 can be described as follows. The user device 104 can interact with a website or other external interface provided / hosted by the resource provider computer 106 to initiate a request to perform an operation (e.g., a request to authorize a transaction). For example, the user device 104 can initiate a transaction (e.g., a payment transaction) at a website or external interface provided by the resource provider computer 106. Among other things, the user device 104 can provide transaction data (e.g., transaction amount, payment data, etc.) to be used to perform the transaction. The payment data may include an account number, expiration date, code, password, PIN, etc.

[0040] The resource provider computer 106 may receive this transaction data from the user device 104 via the external communication interface. The resource provider computer 106 may then generate an authorization request message including at least a portion of the information received from the user device 104 and electronically transmit this message to the transmitting computer 110. The transmitting computer 110 may then receive, process, and forward the authorization request message to the processing network computer 112 for authorization.

[0041] Generally, before a credit or debit card transaction occurs, the processing network computer 112 has established an agreement with each issuer regarding how to authorize transactions with the issuer. In some cases, such as when the transaction amount is below a threshold, the processing network computer 112 can be configured to authorize the transaction based on the information it has about the user's account without generating an authorization request message and transmitting the authorization request message to the authorization entity computer 108. In other cases, such as when the transaction amount is above a threshold, the processing network computer 112 can receive the authorization request message, determine the authorization entity associated with the user device 104 (or the account associated with the user 102), and forward the authorization request message for the transaction to the authorization entity computer 108 for verification and authorization. Once the transaction is authorized, the authorization entity computer 108 can generate an authorization response message (which can include an authorization code indicating that the transaction is approved or denied) and transmit this electronic message to the processing network computer 112 via its external communication interface. Processing network computer 112 may then forward the authorization response message to transmitting computer 110 , which in turn may transmit an electronic message including an authorization indication to resource provider computer 106 and then, in some cases, to user device 104 .

[0042] At the end of the day or at some other suitable time interval, a clearing and settlement process between resource provider computer 106, transfer computer 110, processing network computer 112, and / or authorized entity computer 108 may be performed for the transaction.

[0043] In some embodiments, the authorization system 100 may include a user 102, a user device 104, a resource provider computer 106, an authorization entity computer 108, and a security processing computer 114. In some cases, the security processing computer may be one of many security processing computers. For example, the security processing computer 114 may be started and / or operated by the authorization entity computer 108, or started and / or operated on behalf of the authorization entity computer 108. Any suitable number of instances of the security processing computer 114 may be used in the authorization system 100. For example, one instance of the security processing computer 114 may be configured to manage operations (e.g., authorized transactions, authorized operations, etc.) involving a specific authorized entity (e.g., financial institution 1), while another instance of the security processing computer 114 may be configured to manage operations involving another authorized entity (e.g., financial institution 2). A mapping between an account range and an address of the security processing computer 114 may be maintained at any suitable location, and the security processing computer is configured to perform operations associated with a specific authorized entity associated with the account range. For example, the resource provider computer 106 may be configured to store such mappings. The resource provider computer 106 can be configured to use the mapping to route a request to perform an operation (e.g., via a request message, via an authorization request message) to a security processing computer 114 associated with an authorization entity corresponding to the request (e.g., an authorization entity that manages an account associated with the user 102).

[0044] Using the techniques described herein, the authorization system 100 can omit routing through a conventional authorization path including a transmitting computer 110, a processing network computer 112, and an authorization entity computer 108. For example, in some embodiments, an authorization request message will no longer need to be transmitted to the transmitting computer 110, the processing network computer 112, and the authorization entity computer 108 as required by conventional systems. Similarly, an authorization response message will no longer need to be transmitted from the authorization entity computer 108 to the processing network computer 112 to the transmitting computer 110 in order to be received by the resource provider computer 106. As shown, a request for an operation such as authorization to perform a transaction (e.g., a load operation, a spend operation) can be transmitted directly to a trusted computer (e.g., a secure processing computer 114) (e.g., via an authorization request message), and can be authorized directly by the trusted computer in a secure and trusted manner. Similarly, a response (e.g., an authorization response message) can be transmitted directly by the secure processing computer 114 to the resource provider computer 106 instead of through a conventional response path. As a result, the embodiments disclosed herein can be executed much faster than conventional authorization systems.

[0045] At the end of the day or at some other suitable time interval, a clearing and settlement process between resource provider computer 106, transfer computer 110, processing network computer 112, and / or authorized entity computer 108 may be performed for the transaction.

[0046] Figure 2 According to at least one embodiment Figure 1 A block diagram of the security processing computer 114 is shown.

[0047] The secure processing computer 114 may include a central processor 204. The central processor 204 may be coupled to a system memory 206 and an external communication interface 208. The secure processing computer 114 may include a chipset 210. The chipset 210 may include a chipset processor 212 that may be coupled to a chipset memory 214. The chipset memory 214 may be configured to store chipset instructions (e.g., firmware or configuration logic) for performing the functions described herein with respect to chipset operation.

[0048] Chipset memory 214 may include code executable by chipset processor 212 for initializing and managing one or more secure memory spaces (e.g., Intel SGX enclaves), such as secure memory space 218. Secure memory space 218 may be operably coupled to chipset processor 212, and secure memory space 218 may include key manager 220 and / or authorization manager 222. Although Figure 5 The key manager 220 and the authorization manager 222 are depicted as being stored in a single memory space (e.g., secure memory space 218), but it should be appreciated that the key manager 220 and the authorization manager 222 may be stored in separate memory spaces and not necessarily on the same secure processing computer. Thus, the key manager 220 may reside in a secure memory space on one secure processing computer, while the authorization manager 222 may reside on a different memory space on another secure processing computer. The chipset processor 212 may be configured to enforce access control protocols to restrict access to the secure memory space 218. Using these access control protocols, the chipset processor 212 may restrict access to the secure memory space 218 so that only software components of the secure memory space 218 (e.g., the key manager 220, the authorization manager 222, etc.) may access the contents within the secure memory space 218 (e.g., the data storage area 224). In at least one embodiment, the data storage area 224 may be configured to store one or more cryptographic keys, as discussed in more detail below. In this manner, the secure memory space 218 may be inaccessible to all other software running on the secure processing computer 114 , including the operating system of the secure processing computer 114 .

[0049] The data store 224 may be implemented using a variety of data structures, such as arrays, hash maps, (linked) lists, structured text files (e.g., XML), tables, etc. Such data structures may be stored in memory and / or in structured files. The data store 224 may be configured to reside within the secure memory space 218. Access to the data store 224 may be performed according to an access control protocol implemented by the chipset processor 212. In some embodiments, the data store 224 may be configured to store one or more cryptographic keys. The chipset processor 212, when executing code contained in the chipset memory 214, may implement access control to the data store 224 so that the contents of the data store 224 may be accessed by the chipset processor 212 via execution of function calls of the key manager 220 and may not be accessed by any other means.

[0050] The chipset memory 214 may include code that, when executed by the chipset processor 212, may create and manage secure memory spaces, such as one or more instances of the secure memory space 218. In some embodiments, the central processor 204 may initially load the code and data of the key manager 220 and / or the authorization manager 222. During initialization or at another suitable time, the central processor 204 may transmit a secure memory space request to the chipset processor 212. Upon receipt, the chipset processor 212 may execute instructions stored in the chipset memory 214 to initialize and configure the secure memory space 218. In some embodiments, the chipset processor 212 may then copy the code and data of the key manager 220 and / or the authorization manager 222 from unprotected memory (e.g., not depicted) to the secure memory space 218. The chipset processor 512 may then be configured to encrypt (e.g., cryptographically hash) the contents of the secure memory space 218 using an encryption key stored in the chipset memory 214 and accessible only by the chipset processor 212. In some embodiments, the encryption key may be hard-coded into the chipset memory 214. Encryption ensures that code and data stored in the secure memory space 218 cannot be accessed by other software or other devices, including system software. In some embodiments, the chipset processor 212 can support multiple secure memory spaces at a time. Alternatively, the secure memory space 218 can be referred to as an "enclave". It should be understood that in some embodiments, the functions of the chipset processor 212 can be alternatively performed by the central processor 204 using security-related instruction code built into the central processor 204. An example of such code can include Intel Software Guard Extensions.

[0051] In some embodiments, the key manager 220 may include code that, when executed by the chipset processor 212, causes the key manager 220 (e.g., from, for example, Figure 1 The cryptographic key may be received by an authorized entity computer (such as an authorized entity computer 108 of the authorized entity computer). The cryptographic key may be received via a registration request message during a registration process performed by the authorized entity computer. The registration request message may have any suitable format and may include at least a cryptographic key associated with the authorized entity and identification data (e.g., the name of the authorized entity, a public key associated with the authorized entity, a certificate associated with the authorized entity, etc.). The cryptographic key may be unique to the authorized entity. The key manager 220 may be configured to cause the chipset processor 212 to store any suitable number of received cryptographic keys in the data storage area 224. In some embodiments, each cryptographic key may correspond to a specific authorized entity (e.g., a specific financial institution). In some cases, the key manager 220 may be configured to cause the chipset processor 212 to transmit a registration response message in response to receiving and / or storing the cryptographic key. For example, the key manager 220 may cause the chipset processor 212 to transmit any suitable data to the sender of the cryptographic key (e.g., the authorized entity computer), the data indicating that the cryptographic key was successfully received and / or registered and / or stored. Once a cryptographic key associated with an authorized entity is stored in data store 224, the key associated with the authorized entity may be considered registered.

[0052] In some embodiments, key manager 220 may be configured to cause chipset processor 212 to receive (e.g., as in conjunction with Figure 6 In some embodiments, the key manager 220 may be configured to cause the chipset processor 212 to perform a key derivation function with specific inputs to generate a cryptographic key as described in the following figures. In some embodiments, the key manager 220 may be communicatively coupled to the authorization manager 222, and the functions of the key manager 220 may be triggered via one or more function calls from the authorization manager 222. After generating the cryptographic key, the key manager 220 may cause the chipset processor 212 to transmit the cryptographic key back to the requesting device / component (e.g., the authorization manager 222).

[0053] In some embodiments, key manager 220 may be configured to cause chipset processor 212 to receive one or more digital certificates (e.g., as part of a cryptographic key generation request or otherwise) and use the digital certificates to perform any suitable verification technique in conjunction with FIGS. 3 , 4 , and 6 to verify the identity of one or more entities associated with the request (e.g., a user, an authorized entity, a resource provider, etc.). Key manager 220 may be further configured to verify that the dynamic value received from authorization manager 222 has not been previously used to generate a previously generated cryptographic key.

[0054] In some embodiments, authorization manager 222 may be configured with code that, when executed by chipset processor 212, causes chipset processor 212 to receive and process requests to perform operations. In some embodiments, requests to perform operations (e.g., requesting authorization to spend $10 at a particular merchant) may be formatted as authorization request messages. These requests may be initiated by a user device (e.g., user device 104) and received by authorization manager 222 from a resource provider computer (e.g., Figure 1 In some embodiments, the receipt of the authorization request message may be considered a request to perform an operation. The authorization request message may include a payload including information related to the user (e.g., Figure 1 The encrypted record may be associated with an authorized entity (e.g., an authorized entity that manages an account associated with the user). The encrypted record may include one or more entries indicating previous operations requested by the user device 104 and successfully performed by the authorized entity computer 108 or an instance of the authorization manager 222. The payload may further include one or more digital certificates, cryptographic keys (e.g., cryptographic keys associated with the authorized entity), amounts, dynamic values, addresses associated with the secure processing computer 114 by which the authorization request message is processed, or any suitable combination thereof. The authorization manager 222 may be configured to cause the chipset processor 212 to request and / or receive one or more cryptographic keys from the key manager 220. In some embodiments, the authorization manager 222 may be configured to generate any suitable number of dynamic values ​​(e.g., temporary values, random numbers, counters that change with each request, etc.).

[0055] In some embodiments, as part of the authorization process, the authorization manager 222 may be configured to cause the chipset processor 212 to decrypt the received encrypted record using one or more encryption keys received via the request message and / or the key manager 220. In some embodiments, the authorization manager 222 may be configured to cause the chipset processor 212 to aggregate common data fields associated with a set of entries of the decrypted record. As a non-limiting example, a record may include data entries corresponding to previously performed load operations and / or spend operations associated with the user 102. The authorization manager 222 may be configured, for example, to aggregate the load values ​​of all load operations of the record to determine a first value (e.g., the total value of all load operations of the record). As another example, the authorization manager 222 may be configured to aggregate the spend values ​​of all spend operations of the record to determine a second value (e.g., the total value of all spend operations of the record). The authorization manager 222 may be configured to authorize the request when the first value is greater than or equal to the sum of the second value and the amount included in the request.

[0056] If the first value is less than the sum of the second value and the amount included in the request, the authorization manager 222 can be configured to deny the request and can transmit a response message (e.g., an authorization response message) back to the requesting device (e.g., the resource provider computer 106). In addition, the authorization manager 222 can be configured to cause the chipset processor 212 to perform one or more operations corresponding to the request. For example, the authorization manager 222 can cause the chipset processor 212 to add / append data corresponding to and / or related to the request to the record.

[0057] Once the data has been added or appended to the record, the authorization manager 222 may be configured to cause the chipset processor 212 to request one or more additional encryption keys (e.g., from the key manager 220). The encryption keys may be derived / generated based at least in part on a unique key associated with the authorization entity (e.g., a key received by the key manager 220 during a registration process performed by the authorization entity computer 108) and a dynamic value generated by the authorization manager 222 or the key manager 220. For example, the encryption keys may be generated by submitting a request using Figure 1The authorization manager 222 may be configured to cause the chipset processor 212 to transmit the encrypted record and a dynamic value for deriving / generating at least one encryption key for encrypting the record to the requesting device. In some embodiments, the encrypted record and the dynamic value may be transmitted via an authorization response message. The transmission may also include an indication that the request is authorized and / or that the requested operation (e.g., an authorization operation) has been performed.

[0058] Figure 3A and 3B Each illustrates a registration method according to some embodiments. Figure 3A Shown by Figure 1 The authorized entity computer 108 and Figure 2 An exemplary registration method 300A performed by the key manager 220 of FIG. Figure 3B Shown by Figure 1 The exemplary registration method 300B is performed by the user device 104 and the authorization entity computer 108.

[0059] It should be appreciated that prior to executing method 300A, both the authorized entity computer 108 and the key manager 220 may obtain and / or store a key derivation function (e.g., KDF 302). Thus, in the examples provided herein, the authorized entity computer 108 and the key manager 220 may use the same key derivation function to derive one or more cryptographic keys. In some embodiments, the authorized entity computer 108 may also have access to a master secret key 304. In some embodiments, the key manager 220 may be pre-configured with a public key of a trusted certificate authority (not depicted).

[0060] Method 300A may begin at step 1, where authorized entity computer 108 may generate a key (e.g., AE key 306) using KDF 302. As a non-limiting example, authorized entity computer 108 may provide master secret key 304 as an input into KDF 302 to generated AE key 306. In some embodiments, only the authorized entity knows master secret key 304. The following function describes the operation, where "AE key" is AE key 306, "KDF" is KDF 302, and "MSK" is master secret key 304.

[0061] AE Key=KDF(MSK)

[0062] It should be appreciated that the inputs may be used with the KDF 302 to generate the AE key 306. The AE key 306 may be generated to ensure that the AE key is unique to the authorized entity. Using the master secret key 304 as an input in the KDF 302 is an example of how uniqueness is achieved, because the master secret key 304 is also unique to the authorized entity, and therefore, the output of the KDF 302 (e.g., the AE key 306) will also be unique to the authorized entity. Using the AE key 306 generated from the master secret key 304 ensures uniqueness while also eliminating the security risk that would likely occur if the authorized entity transmitted its master secret key 304.

[0063] At step 2, the authorized entity computer 108 may transmit the AE key 306 to the key manager 220 to register the AE key 306. For example, the authorized entity computer 108 may call an API call to call the key manager 220 (as Figure 2 The API call (e.g., message) may include a payload that includes the AE key 306. In some embodiments, the payload may additionally include a certificate. For example, a certificate associated with an authorized entity (e.g., an AE CERT 308) may be included in the payload. The certificate associated with the authorized entity may have been previously generated and signed by a certificate authority (not depicted) trusted by the key manager 220 using a private key associated with the certificate authority. As described above, the key manager 220 may be pre-configured with the certificate authority's (CA's) public key 310. The certificate associated with the authorized entity may include any suitable data by which the identity of the authorized entity may be verified.

[0064] After receiving the payload of the API call, or at another suitable time, the key manager 220 can be configured to perform one or more verification processes. For example, the key manager 220 can use the CA's public key 310 to verify the certificate (AE CERT 308). In other words, the CA's public key 310 can be used to verify the AE generated by the certificate authority. CERT 308.

[0065] In some embodiments, the payload may further include a digital signature generated by the authorization entity computer 108 using a private key associated with the authorization entity (e.g., in Figure 3A The key manager 220 may be configured to use the CA's public key 310 to obtain the AE's CERT308 obtains the public key of the authorized entity. The public key of the authorized entity can then be used to verify that the digital signature provided in the payload was provided by the authorized entity computer 108. In some embodiments, the digital signature is generated by the authorized entity computer 108 based on other payload data. For example, the AE key 306 or any portion of the payload data can be signed by the authorized entity computer 108 using a private key associated with the authorized entity to generate a digital signature. Therefore, the public key associated with the authorized entity and the digital signature can be used by the key manager 220 to verify the integrity of the message (e.g., the payload data has not been altered and the payload data was sent by the authorized entity computer 108).

[0066] An exemplary payload provided by the authorization entity computer 108 to the key manager 220 at step 2 is provided below.

[0067] Payload=<AE Key,AE CERT ,Sign AE (AE Key)

[0068] Wherein “AE key” indicates AE key 306, CERT ” means AE CERT 308, and Sign AE (AE Key) represents the digital signature of the AE Key 306 digitally signed by the authorized entity computer 108 using the private key associated with the authorized entity.

[0069] At step 3, the key manager 220 may be configured to register the AE key 306. Registering the AE key 306 may include storing the AE key 306 in Figure 2 224, which is a data store accessible to the key manager 220. In some embodiments, the key manager 220 may register / store the AE key 306 in response to determining to verify the identity of the authorized entity associated with the authorized entity computer 108 and / or in response to determining based on the digital signature that the message has not been altered. The key manager 220 may be configured to store the public key of the authorized entity and / or the AE key 306. CERT The association between 308 and the public key of AE key 306.

[0070] Although not depicted, the key manager 220 may be configured to provide a response message to the authorized entity computer 108 to indicate that the AE key provided to the key manager 220 has been successfully registered. If at any point in the method 300A, the key manager 220 determines that the provided AE key cannot be registered (e.g., the identity of the authorized entity cannot be verified), the key manager 220 may provide a response message to the authorized entity computer 108 to indicate that the AE key provided to the key manager 220 has not been successfully registered.

[0071] The method 300B may be performed after the AE key 306 is successfully registered / stored by the key manager 220. The method 300B may begin at step 1, where a user may install an application on their user device 104. The user device 104 may generate a public / private key pair (e.g., a key pair 320 including a private key 322 and a public key 324).

[0072] At step 2, the user device 104 may transmit user-specific data 326 and a public key of the user device (e.g., public key 324) to the authorization entity computer 108. The user-specific data 326 may include, for example, a user profile (e.g., user information such as name, address, phone number, bank account number, etc.) associated with the user of the user device 104. The user device 104 may be pre-configured with the user-specific data 326 in advance via user input or in any suitable manner.

[0073] At step 3, the authorization entity computer 108 may be configured to verify the public key 324 in response to receiving the user-specific data 326. If the identity of the user is verified based on the user-specific data 326, the authorization entity computer 108 may be configured to generate a certificate (e.g., a U CERT 328). In some embodiments, the authorization entity computer 108 may generate a certificate associated with the user device 104 by digitally signing the public key associated with the user device 104 (e.g., public key 324) and any portion of the user-specific data that may have been received at step 2 using its own private key. Thus, the certificate generated for the user device 104 may include the public key 324 and the user-specific data 326, such as the user's name, address, telephone number, bank account number, etc. If the user's identity cannot be verified, the authorization entity computer 108 may transmit any suitable data to the user device 104 to indicate that the registration was unsuccessful and / or the authorization entity computer 108 may stop processing data received from the user device 104.

[0074] At step 4, after verifying the identity of the user, the authorization entity computer 108 may be configured to generate a cryptographic key (e.g., K1 330). As an example, K1 330 may be generated using the AE key generated by the authorization entity computer 108 during method 300A and the public key 324 received by the authorization entity computer 108 in step 2 as inputs to the KDF 302. In some embodiments, the authorization entity computer 108 may hash the public key 324 using any suitable hashing algorithm. In some embodiments, the hash of the public key 324 may be provided as an input into the KDF 302 along with the AE key 206 to generate K1 330 (e.g., the output of the KDF 302). The function for generating K1 is described below.

[0075] K1=KDF(AE Key,H(Upub))

[0076] Where "K1" represents K1 330, "KDF" represents KDF 302, "AE key" represents AE key 306, and "H (Upub)" represents the hash value generated by inputting public key 324 (the public key associated with the user) into hash function "H." In some embodiments, the authorization entity computer 108 may maintain a list of public keys including Upub. CERT 328, AE CERT 308, K1 330, user-specific data 326, etc.

[0077] At step 5, the authorization entity computer 108 may transmit a message having a payload including the URL CERT 328, AE CERT 308 and K1 330. In some embodiments, the payload may further include a certificate associated with a certificate authority, which is received by the authorization entity computer 108 during execution of the method 300A. Upon receipt or at another suitable time, the user device 104 may CERT 328, AE CERT 308 and K1 330 are stored in the local memory.

[0078] Figure 4 A method 400 for performing an operation (eg, a load operation) using an encrypted record is shown according to some embodiments. The method 400 may be performed after the methods 300A and 300B are completed.

[0079] Method 400 may begin at step 1, where an application may be launched using user device 104. Any suitable interface of the application and / or user device 104 may be used to indicate a request to perform an operation. As a non-limiting example, an interface of the application may be used to request that an amount of $100 be transferred to an account associated with a user. This account may be different from a financial account managed by authorized entity computer 108 on behalf of the user (e.g., a separate checking or savings account).

[0080] At step 2, user device 104 may transmit a message (e.g., a payload message in any suitable format) including a payload of a requested amount (e.g., $100), one or more certificates (e.g., the U of FIG. 3 ), and a certificate of authenticity. CERT 328, U CERT 328 and AE CERT 308) and from Figure 3B Execution of method 300B results in K1 330 .

[0081] At step 3, the authorization entity computer 108 may be configured to verify the identity of the user device. As a non-limiting example, the authorization entity computer 108 may use its own public key to verify the identity of the user device. CERT 328 is generated by the authorized entity computer 108 using its private key. Additionally or alternatively, the authorized entity computer 108 may (e.g., via a combination of Figure 3B The mapping) verifies K1 330 and U CERT 328 (and / or AE CERT 308 (if provided) associated. In either case, if U CERT 328 is not generated by the authorized entity computer 108, or K1 330 is unknown or not associated with U CERT 328, the authorization entity computer 108 may be configured to deny the request. Otherwise, the method may continue to step 4.

[0082] At step 4, the authorization entity computer 108 may be configured to identify the user's financial account (eg, CERT The authorized entity computer 108 may determine whether the bank account number (e.g., the bank account number of the authorized entity 108) has a balance that exceeds the amount (e.g., $100) provided in the payload at step 2. If not, the authorized entity computer 108 may transmit an indication to the user device 104 that its request has been denied. Alternatively, if the balance of the financial account exceeds the amount provided in the payload, the authorized entity computer 108 may perform any suitable operation to transfer the requested amount.

[0083] At step 5, if the balance of the financial account exceeds the amount provided in the payload, the authorization entity computer 108 may generate a record associated with the user. Figure 5 An exemplary record 500 is shown according to some embodiments. The record 500 may be generated and associated with a corresponding CERT 328 and / or a user of the user device 104. The record 500 may be in any suitable format and include any suitable data. Return to Figure 4 , the authorized entity computer 108 may perform any suitable operations to transfer the requested amount from the user's financial account to another account associated with the record (e.g., a transaction account, a digital wallet account). The account associated with the record may pre-exist, or may be generated as part of the operations performed by the authorized entity computer 108. The authorized entity computer 108 may modify the record 500 to include an entry associated with the requested operation. In the current example, the authorized entity computer 108 may generate, modify the record 500 to include an entry that includes an amount (e.g., 100 indicating $100), a public key of the authorized entity, a public key of the user device (e.g., public key 324 received during execution of method 300B), and an indication of the type of operation performed (e.g., "payload"). The entry may also include a digital signature generated by the authorized entity by signing the remaining entry data using the authorized entity's private key (e.g., Figure 5 AE of Entry 1 SIG ). Figure 5 Item 1 is intended to describe Figure 4 The entry added to record 500 at step 5.

[0084] exist Figure 4 At step 6 of , the authorized entity computer 108 may be configured to generate another cryptographic key (e.g., K2 402). In some embodiments, the authorized entity computer 108 may generate a dynamic value 404 (e.g., a temporary value, a random number, a counter, any suitable unique value, etc.), and use the dynamic value 404 and the AE key 306 as inputs to the KDF 302 to generate K2 402. A function for generating K2 is provided below, where "K2" represents K2 402, "KDF" represents KDF 302, "AE key" represents AE key 306, and "DV" represents the dynamic value 404 generated by the authorized entity computer 108.

[0085] K2=KDF(AE key, DV)

[0086] At step 7, the authorization entity computer 108 may be configured to generate another cryptographic key (eg, K3 406). In some embodiments, K3 406 may be formed by concatenating K1 330 and K2 402.

[0087] At step 8, the authorized entity computer 108 may generate the encrypted record 408. For example, the authorized entity computer 108 may encrypt the record 500 using K3 406 by providing K3 406 and the record 500 as inputs in an encryption algorithm to obtain the encrypted record 408.

[0088] At step 9, the authorization entity computer 108 may transmit a message back to the user device in response to the request received at step 2. The message may include a payload including the encrypted record 408 and the dynamic value 404. After receipt or at any suitable time, the user device 104 may store the encrypted record 408 and the dynamic value 404 in local memory. It should be understood that according to the current example, the encrypted record 408 only includes Figure 5 1. It should be appreciated that the user device 104 may be configured to use any suitable number of authorized entity computers to perform the above method, and therefore, it is contemplated that the user device 104 may store multiple encrypted records, each corresponding to a specific authorized entity. The encrypted record 408 is stored at the user device 104 but is protected because the user device 104 cannot access K2 or generate K2, and both K1 and K2 are required for decryption of the encrypted record 408.

[0089] Figure 6 A method for using an encrypted record (e.g., Figure 4 Another method 600 of performing an operation (e.g., an operation associated with authorization) using an encrypted record 408 of the present invention. Figure 4 Method 600 is executed after method 400 .

[0090] Method 600 may begin at step 1, where a user (e.g., Figure 1 A user 102 of a user device 104 may launch an application (e.g., a digital wallet application, a web browser, etc.) on the user device 104. The user device 104 may be used to navigate to an interface provided / hosted by an authorized entity or a resource provider. As a non-limiting example, the interface may be provided as part of an application (e.g., a digital wallet application) hosted by an authorized entity (e.g., using an authorized entity computer 108 or a separate server computer), or may be accessed at a website hosted by a resource provider (e.g., using a resource provider computer 106). The user device may receive input provided via the interface. The input may indicate a request to perform an operation. For example, the input may indicate that the user wishes to spend $10 at a particular resource provider (e.g., a merchant associated with the resource provider computer 106). Thus, the request to perform an operation may be a request to authorize a $10 transaction between the user and the resource provider.

[0091] In step 2, the user device 104 may transmit a payload to the resource provider computer 106, including one or more credentials (eg, the U CERT 328, U CERT 328 and AE CERT 308, etc.), a cryptographic key (e.g., K1 330 of FIG. 3), an encrypted record E REC (For example, Figure 4 encrypted record 408), dynamic values ​​(e.g., Figure 4 Dynamic value 404) and H(SPC ADD ). H(SPC ADD ) may represent a hash of the address of a secure processing computer (e.g., secure processing computer 114) that will handle the transaction. In some embodiments, user device 104 may be pre-configured with a mapping indicating the address of an appropriate secure processing computer 114. For example, as part of performing method 300A, Figure 3A The mapping and / or address of the secure processing computer 114 is provided to the authorized entity computer 108. The secure processing computer 114 may be included in a larger network of secure processing computers. A hash table associated with the network may include identifiers of secure processing computers and their corresponding addresses (IP addresses). Any message sent to this network of secure processing computers may be routed to the appropriate secure processing computer based on the identifiers and hash tables provided.

[0092] At step 3, the resource provider computer 106 may send its own certificate (e.g., R CERT 602. A certificate generated and digitally signed by a certificate authority that can be used to verify the identity of the resource provider) and the amount of the transaction (e.g., $10) are appended to the payload.

[0093] At step 4, the resource provider computer 106 may forward the modified payload to the authorization manager 222. Figure 6 In the example provided in FIG. 2 , authorization manager 222 may execute the authorization in a secure memory space (e.g., Figure 2 218) in the secure memory space. Figure 6 Key manager 220 may execute in the same or different secure memory space as the secure processing computer on which authorization manager 222 runs, or key manager 220 may operate in a separate memory space provided on a separate secure processing computer at an address known to authorization manager 222.

[0094] At step 5, authorization manager 222 may request a cryptographic key from key manager 220. Authorization manager 222 may include any suitable portion of the payload received at step 4 in the request.

[0095] At step 6, in response to the request provided by authorization manager 222, key manager 220 may verify any suitable combination of certificates provided in the payload. As a non-limiting example, key manager 220 may retrieve the public key of the certificate authority from local storage. Using the public key of the certificate authority (e.g., public key 310 of CA of FIG. 3 ), key manager 220 may verify the AE provided in the payload data. CERT 308 is originally generated by the certificate authority. The CA's public key 310 can also be used to obtain CERT 308 extracts the public key associated with the authorized entity (or AE CERT 308). Using the public key of the authorized entity, key manager 220 may verify the public key of the key provided in the payload data. CERT 328 is originally generated by an authorized entity. The authorized entity's public key can also be used to obtain CERT 328 extracts the user-specific data 326 and the public key associated with the user device 104. Using the public key of the certificate authority (e.g., the public key 310 of the CA of FIG. 3), the key manager 220 can verify the R provided in the payload data. CERT 602 is originally generated by the certificate authority and can be extracted in R CERT Any suitable data provided in 602.

[0096] At step 7, the key manager 220 may generate K2 604. The key manager 220 may generate K2 604 in combination with Figure 4 The description is that K2 604 is generated in the same manner as K2 402 is generated by the authorized entity computer 108. Specifically, the key manager 220 may use the authorized entity's public key (or AE CERT 308) to retrieve the registration key associated with the authorized entity (e.g., AE key 306 of FIG. 3) using the mapping generated during execution of method 300A. The key manager 220 can then generate K2 604 using the following function, where "KDF" represents KDF 302 of FIGS. 3 and 4, "AE key" represents AE key 306, and "DV" represents a dynamic value provided in the payload data (e.g., dynamic value 404).

[0097] K2=KDF(AE key, DV)

[0098] In some embodiments, the key manager 220 may be configured to maintain a list of previously used dynamic values. The key manager 220 may verify that the dynamic value 404 has not been previously used by the key manager 220 to generate a cryptographic key. This enables the key manager 220 to prevent relay and / or replay attacks by ensuring that each request must be accompanied by a different dynamic value. If the key manager 220 identifies that the dynamic value 404 has been previously used, K2 604 may not be generated, and the key manager 220 may pass an indicator of this back to the authorization manager 220, which may then deny the request of the user device 104. If the key manager 220 has not used the dynamic value to generate a cryptographic key, K2 604 may be generated. Once K2 604 is generated, it may be returned to the authorization manager 222 at step 9.

[0099] At step 10, authorization manager 222 may be configured to perform encryption of the encrypted record (eg, the E REC ) to obtain the plaintext record (for example, including Figure 5 1 instead of entries 2-6 as depicted in record 500). For example, authorization manager 222 may concatenate K1 provided in the payload data with K2 provided from key manager 220 at step 9 to generate cryptographic key K3 (e.g., with Figure 4 K3 406 is the same as the cryptographic key of K3 406). K3 can be used to encrypt the record E REC Decryption is performed to obtain record 500.

[0100] At step 11, authorization manager 222 may aggregate all amounts of entries of record 500 associated with the first type of operation (e.g., the "L" entry corresponding to the previously performed load operation) to determine a first value (e.g., the total amount of all entries associated with the "L" operation). Before aggregating the amounts of the first type of operation, authorization manager 222 may first use the public key of the authorized entity (the AEpub-key of entry 1) and the digital signature of each entry of the first type of operation (e.g., the AEpub-key of entry 1) to determine a first value (e.g., the total amount of all entries associated with the "L" operation). SIG ) to verify that the data of each entry has not been modified. As long as it is determined that each of those entries has not been modified, the authorization manager 222 can continue to summarize the amount of the first type of operation.

[0101] The authorization manager 222 may also aggregate all amounts of entries of the record 500 associated with the second type of operation (e.g., "S" entries corresponding to previously performed spend operations) to determine a second value (e.g., the total amount of all entries associated with the "S" operations). The authorization manager 222 may determine whether the first value is greater than or equal to the sum of the second value and the amount provided in the payload data. If so, the authorization manager 222 may determine that the request is authorized and the requested operation should be performed. Thus, the authorization manager may add any suitable portion of the payload data (e.g., the amount), the public key of the authority, the public key of the user device 104, and the public key of the resource provider to the record 500. For example, the authorization manager 222 may Figure 5 Entry 2 of is appended to record 500. At this time, record 500 includes Figure 5 Items 1 and 2, but not Items 3-6.

[0102] At step 12 , authorization manager 222 may be configured to generate a new dynamic value (eg, dynamic value 606 ) using any suitable method. Authorization manager 222 may send dynamic value 606 to key manager 220 .

[0103] At step 13, the key manager 220 may generate a new cryptographic key (e.g., K4 608) using the dynamic value 606 and the AE key 308 associated with the authorized entity according to the following formula, where “KDF” represents KDF 302, “AE key” represents AE key 308, and “DV” represents dynamic value 606.

[0104] K4=KDF(AE key,DV′)

[0105] Alternatively, authorization manager 222 may simply generate a request for a new encryption key to key manager 220 , and key manager 220 may generate dynamic value 606 as part of the process of generating K4 608 .

[0106] At step 14 , key manager 220 may return K4 608 to authorization manager 222 .

[0107] At step 15, authorization manager 222 may encrypt the modified record 500 (e.g., the record 500 including entries 1 and 2) using K4 608. In some embodiments, authorization manager 222 may generate a new cryptographic key by concatenating K1 and K4 608 from the payload data originally received at step 4. Authorization manager 222 may encrypt the record 500 modified at step 10 using the new cryptographic key it generated by concatenation to generate encrypted record 610. Encrypted record 610 may include Figure 5Entries 1 and 2 are encrypted versions of record 500.

[0108] At step 16, the authorization manager 222 may REC The transaction (e.g., encrypted record 610), DV' (e.g., dynamic value 606), and indicator are transmitted to the resource provider computer 106, which in turn may forward the same data to the user device 104. In some embodiments, the indicator may be used to indicate that the requested operation was successful or unsuccessful. In the current example, the indicator may indicate that the operation was successful (e.g., $10 was spent at resource provider 1 associated with Rpub_key 1 indicated in entry 2 of record 500).

[0109] Subsequently, method 400 and / or method 600 may be repeated any suitable number of times to increase the balance of the user's transaction account by loading additional amounts to the record or to spend additional amounts at a resource provider, respectively. For each subsequent successful operation (e.g., load or spend), a new entry may be appended to record 500, and a new dynamic value may be generated (by the computer performing the operation) and used to generate a new cryptographic key to generate an encrypted version of record 500. By transmitting the new encrypted record with the dynamic value of one or more encryption keys used to generate the encrypted record, a recipient (e.g., an authorized entity computer 108 for a load operation, an authorization manager 222 for a spend operation) may be enabled to derive / generate one or more keys used to encrypt the record. Thus, the recipient is subsequently able to decrypt the encrypted record as part of an operation to perform a request as described above. As Figure 5 As depicted in , record 500 includes additional entries showing modifications to record 500 due to subsequent operations.

[0110] For example, continuing with the above example, the user may then request a load operation for an amount of $20. The authorization entity computer 108 may receive the request, verify the funds associated with the user's bank account, decrypt the encrypted record provided by the user device 104, modify the decrypted record (e.g., record 500) to include entry 3, generate a new dynamic value, generate a new cryptographic key using the AE key and the new dynamic value, encrypt the record 500 including entries 1-3 with the newly generated cryptographic key, and send the new dynamic value and the new encrypted record to the user device 104 for storage.

[0111] At a later time, the user may request a spending operation at resource provider 2 for an amount of $30. This may cause authorization manager 222 to execute method 600 again. In summary, authorization manager 222 may provide the payload data of the request, including the dynamic value generated by authorization entity computer 108, to key manager 220. Key manager 220 may generate one or more keys using the provided dynamic value and AE key 308 (a key provided by authorization entity computer 108 during execution of method 300A). The encrypted record may be decrypted using the keys. Authorization manager 222 may perform a combined Figure 6 The method described in step 11 of , to determine whether the summary of the load operations is greater than or equal to the sum of the summary of the spend operations and the amount indicated in the current request. If so, then the authorization manager 222 can generate a new dynamic value, request a new cryptographic key from the key manager 220, append entry 4 to the record 500, and encrypt the encrypted record 500 modified to include entries 1-4. The encryption can use a key that includes a concatenation of K1 and the new cryptographic key provided by the key manager 220. The authorization manager 222 can then transmit the new dynamic value and the new encrypted record to the user device 104 for storage. Each new dynamic value received can replace a previous dynamic value stored at the user device 104. Similarly, each new encrypted record received at the user device 104 can replace an encrypted record previously stored by the user device 104.

[0112] Methods 400 and 600 may then be performed any suitable number of times in any suitable order.

[0113] At a later time, authorization manager 222 (having executed multiple transactions corresponding to one or more users and one or more resource providers) can be configured to determine the amount to be debited from each user and the amount to be credited to each resource provider. This information can then be provided to a settlement service, which can transfer the appropriate amount between a financial institution representing the user (e.g., an authorization entity associated with authorization entity computer 108) and a financial institution representing the resource provider (e.g., a transfer computer 110 associated with a financial institution that manages financial accounts on behalf of the resource provider). In some embodiments, a blockchain system can be used in this settlement process.

[0114] Although the examples provided herein are provided in the context of payment transactions (e.g., fund transfers between authorized entity banks and user accounts, payment transactions between users and resource providers such as merchants), it should be appreciated that the techniques described herein can be used in the context of other payment authorization systems. For example, in some embodiments, the encrypted records stored by the user device 104 of the above diagrams may include entries that provide any suitable operational data. As a non-limiting example, the user device 104 may be used to request access to resources (e.g., electronic software, services, etc.) provided by a resource provider. The unique key of the resource provider may be registered by a key manager running on a secure processing computer.

[0115] Each time a user requests access (a request to perform an operation), the details of the access (e.g., information about the user, the user's device, the location of the user's device, the time of access, the duration of access, etc.) can be appended to a record encrypted using the above method (e.g., using a unique key and a dynamic value of a resource provider) and transmitted to the user device for storage. Each time a user requests access, an authorization manager operating on a secure processing computer can be configured to receive the request. The authorization manager can be configured to decrypt the record received in the request to determine whether the user is allowed to access. As an example, the authorization manager can analyze any suitable data contained in the decrypted record to determine whether the user is allowed to access the resource. Access rights can be provided to the user device based on this determination. If the user is allowed access or denied access, the authorization manager can be configured to append data associated with the request and / or output to the record. The authorization manager can then request one or more encryption keys from the key manager in the manner described above, and use at least one of the keys (e.g., derived from a unique key and a dynamic value associated with a resource provider) to encrypt the record. The encrypted record can then be transmitted back to the user device for storage.

[0116] Technical advantages

[0117] Embodiments of the present invention have a number of advantages. For example, transaction authorization is faster and simpler than conventional authorization processing using messages transmitted to the issuer via an acquirer computer and a processing network computer. Since the message does not need to traverse many components, embodiments of the present invention provide faster processing speeds. In addition, the process is also secure and eliminates double spending as described above. In addition, the record is encrypted on the user device so that the entries of the record are inaccessible to the user device, which can prevent fraudulent modification of the record. Each user device can store an encrypted record of its own previously performed operations (e.g., load and / or spend operations / transactions), thereby eliminating the need to use conventional authorization processing. Specifically, as described in the above figure, a faster authorization process can be used.

[0118] The above description is illustrative rather than restrictive. Many changes of the present invention may become apparent to those skilled in the art when consulting this disclosure. Therefore, the scope of the present invention may be determined without reference to the above description, but may be determined with reference to the pending claims and their full scope or equivalents. It should be understood that the present invention as described above can be implemented in a modular or integrated manner using computer software in the form of control logic. Based on the disclosure and the teachings provided herein, a person of ordinary skill in the art will know and understand other ways and / or methods of implementing the present invention using hardware and a combination of hardware and software. Any software component or function described in this application may be implemented as a software code executed by a processor using any suitable computer language such as Java, C, C++, Python or Perl using, for example, conventional or object-oriented techniques. The software code may be stored as a series of instructions or commands on a computer-readable medium (e.g., a random access memory (RAM), a read-only memory (ROM), a magnetic medium (e.g., a hard disk drive or a floppy disk) or an optical medium (e.g., a CD-ROM)). Any such computer-readable medium may reside on or inside a single computing device, and may exist on or inside different computing devices within a system or network.

[0119] Although many embodiments are described above as including different features and / or combinations of features, those skilled in the art will appreciate after reading this disclosure that, in some cases, one or more of these components may be combined with any of the components or features described above. That is, one or more features from any embodiment may be combined with one or more features of any other embodiment without departing from the scope of the present invention.

[0120] Any computer system mentioned herein may use any suitable number of subsystems. In some embodiments, the computer system includes a single computer device, wherein the subsystem may be a component of the computer device. In other embodiments, the computer system may include multiple computer devices with internal components, each of which is a subsystem. The computer system may include desktop computers and laptop computers, tablet computers, mobile phones, and other mobile devices.

[0121] The subsystems may be interconnected via a system bus. Additional subsystems may be used, such as a printer, a keyboard, one or more storage devices, a monitor coupled to a display adapter, and other subsystems. Peripheral devices and input / output (I / O) devices coupled to the I / O controller may be connected via any number of means known in the art, such as input / output (I / O) ports (e.g., USB, )) is connected to the computer system. For example, an I / O port or external interface (e.g., Ethernet, Wi-Fi, etc.) can be used to connect the computer system to a wide area network such as the Internet, a mouse input device, or a scanner. The interconnection through the system bus can allow the central processor to communicate with each subsystem and control the execution of instructions from the system memory or one or more storage devices (e.g., fixed disks such as hard drives or optical disks), as well as the exchange of information between the subsystems. The system memory and / or storage device can embody a computer readable medium. Another subsystem is a data collection device, such as a camera, a microphone, an accelerometer, etc. Any data mentioned in this article can be output from one component to another component and can be output to a user.

[0122] A computer system may include multiple identical components or subsystems connected together, for example, by external interfaces or by internal interfaces. In some embodiments, computer systems, subsystems, or devices may communicate over a network. In such cases, one computer may be considered a client and another computer may be considered a server, where each computer may be part of the same computer system. The client and server may each include multiple systems, subsystems, or components.

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

[0124] Any software component or function described in this application can be implemented as a software code executed by a processor using any suitable computer language such as Java, C, C++, C#, Objective-C, Swift or a scripting language such as Perl or Python using, for example, conventional or object-oriented techniques. The software code can be stored on a computer-readable medium as a series of instructions or commands for storage and / or transmission. Suitable non-transient computer-readable media may include random access memory (RAM), read-only memory (ROM), magnetic media such as hard disk drives or floppy disks, or optical media such as compact disks (CDs) or DVDs (digital versatile disks), flash memory, etc. Computer-readable media may be any combination of such storage or transmission devices.

[0125] Such programs can also be encoded and transmitted using carrier signals, which are suitable for transmitting via wired, optical and / or wireless networks that meet multiple protocols including the Internet. Therefore, the computer-readable medium according to an embodiment of the present invention can be created using data signals encoded with such programs. The computer-readable medium encoded with program code can be encapsulated with compatible devices or provided separately with other devices (for example, downloaded via the Internet). Any such computer-readable medium can reside on or inside a single computer product (for example, hard drive, CD or entire computer system), and can be present on or inside different computer products in a system or network. The computer system can include a monitor, a printer, or other suitable displays for providing any result mentioned herein to the user.

[0126] Any method described herein can be performed in whole or in part with a computer system, and the computer system includes one or more processors that can be configured to perform the steps. Therefore, an embodiment can relate to a computer system that is configured to perform the steps of any method described herein, and may have different components that perform corresponding steps or corresponding step groups. Although presented with numbered steps, the method steps herein can also be performed simultaneously or in different orders. In addition, the parts of these steps can be used together with the parts of other steps of other methods. And all or part of the steps can be optional. In addition, any step of any method can be performed with the module, unit, circuit or other components that perform these steps.

[0127] Without departing from the spirit and scope of the embodiments of the invention, the specific details of the particular embodiments may be combined in any suitable manner. However, other embodiments of the invention may be directed to specific embodiments related to each individual aspect or specific combinations of these individual aspects.

[0128] The above description of example embodiments of the present invention has been presented for purposes of illustration and description. It is not intended to be exhaustive or to limit the invention to the precise form described, and many modifications and variations are possible in light of the above teaching.

[0129] Unless expressly indicated to the contrary, the recitation of "a", "an" or "the" is intended to mean "one or more". Unless expressly indicated to the contrary, the use of "or" is intended to mean an "inclusive or" rather than an "exclusive or". Reference to a "first" component does not necessarily require the provision of a second component. Furthermore, reference to a "first" or "second" component does not limit the referenced component to a particular location unless expressly stated.

Claims

1. A computer-implemented method comprising: receiving, from a requesting device, a request to perform an operation, the request being received in a request message including an encrypted record and a first dynamic value, the encrypted record including a set of one or more entries corresponding to one or more previously performed operations associated with a user of the requesting device; Authorizing the request using the encrypted record, a first cryptographic key derived from a unique key associated with an authorized entity, and the first dynamic value, the authorization comprising: obtaining a second cryptographic key derived from the unique key associated with the authorization entity, wherein the second cryptographic key is obtained from the request message, generating a third cryptographic key based on the first cryptographic key and the second cryptographic key, generating a decrypted record from the encrypted record using the third cryptographic key, wherein authorizing the request is based at least in part on the decrypted record, aggregating a first set of entries in the decrypted record to generate a first value; and aggregating a second set of entries in the decrypted record to generate a second value, wherein the request is authorized based at least in part on the first value and the second value; performing one or more operations based at least in part on the request being authorized; generating a modified encrypted record comprising data associated with the one or more operations performed; and At least the modified encrypted record and an indication that the operation has been performed are transmitted to the requesting device. 2 . The computer-implemented method of claim 1 , wherein authorizing the request is based at least in part on determining that the first value is greater than or equal to a sum of the second value and an amount included in the request message.

3. The computer-implemented method of claim 1 , wherein generating the modified encrypted record comprises: generating a decrypted record based on the encrypted record using the first dynamic value; modifying the decryption record to include data indicating that the request has been authorized; generating a second dynamic value; generating a new cryptographic key based at least in part on the second dynamic value and the unique key associated with the authorized entity; as well as The modified decrypted record is encrypted to generate the modified encrypted record, wherein encrypting the decrypted record uses the new cryptographic key generated at least in part based on the unique key and the second dynamic value, wherein the second dynamic value is transmitted using the modified encrypted record.

4. The computer-implemented method of claim 3, wherein generating the new cryptographic key is further based at least in part on concatenating the first cryptographic key to the new cryptographic key prior to using the new cryptographic key to encrypt the decrypted record.

5. A secure processing computer comprising: one or more processors; as well as One or more memories storing executable instructions which, when executed by the one or more processors, cause the security processing computer to perform a computer-implemented method according to any one of the preceding claims.

6. The secure processing computer of claim 5, wherein the one or more memories include a first secure memory space and a second secure memory space.

7. The secure processing computer of claim 6, wherein the first secure memory space stores code that, when executed by the one or more processors, causes the secure processing computer to derive and generate one or more cryptographic keys.

8. The secure processing computer of claim 6, wherein the second secure memory space stores code that, when executed by the one or more processors, causes the secure processing computer to decrypt an encrypted record to generate a decrypted record and to perform authorization processing using the decrypted record.

Images