System and method for matching and processing interaction data

Abstract

A method is disclosed. The method includes receiving from the storage application server storing additional data from an authorizing entity computer, a token cryptogram request message comprising a token associated with a credential. The method further includes transmitting, to the storage application server, a token cryptogram, receiving, by the processing network computer, action data for an action to be taken with respect to the additional data, and storing the action data, the token, and a token cryptogram associated with the token in a database. The method also includes performing an authorization process using the token and the token cryptogram, and then performing additional processing with respect to the action.

Description

PATENT Attorney Docket No.079900-1509106 Client Ref. No.: 9722WO01 SYSTEM AND METHOD FOR MATCHING AND PROCESSING INTERACTION DATA CROSS REFERENCE TO RELATED APPLICATIONS

[0001] This is a PCT application which claims priority to U.S. Provisional Application No. 63 / 693,652, filed on September 11, 2024, which is herein incorporated by reference in its entirety. BACKGROUND

[0002] Additional actions can take place in conjunction with primary interactions. An example of an additional action may be the initiation of a portioning plan in association with an interaction such as a transaction. In a typical portioning plan involving a device such as a payment device, a user could conduct a transaction for a resource at a resource provider using the device. The device may have sensitive data such as a credential associated with it and this data is provided to the resource provider. After the transaction is completed, the user may be asked if they wish to execute the portioning plan with respect to the credential. The user may then need to provide action data to a server computer to initiate the execution of the portioning plan.

[0003] A number of problems exist with respect to existing methods. For example, the above-described method may involve the use of processing network computer to coordinate communication between a storage application server seeking to present portioning plans to users and the authorizing entities that sponsor the portioning plans. This can be problematic since two communications are required for data sharing; one between the processing network computer and the authorizing entity computer; and another between the processing network computer and the storage application computer. Another problem that exists is with respect to data security. Credentials that are used in interactions such as payment transactions can be sensitive information. When such credentials are passed to resource provider computers, such credentials can be obtained by unauthorized persons in hacking or man-in-the-middle attacks. If unauthorized persons obtain the credentials, then theyPATENT Attorney Docket No.079900-1509106 Client Ref. No.: 9722WO01 can be used to conduct illegitimate interactions. Another problem that exists is with respect to the ability to transmit action data with respect to additional data such as a portioning plan from a resource provider computer to an authorizing entity computer. Existing authorization request messages cannot be easily modified to accommodate significant formatting changes, since they are transmitted through a transaction network with many computers that are specifically programmed to process authorization request messages according to standard formats.

[0004] Embodiments of the invention address these and other embodiments individually and collectively. SUMMARY

[0005] One embodiment of the invention includes a method, the method comprising: receiving, by the processing network computer from the storage application server storing additional data from an authorizing entity computer, a token cryptogram request message comprising a token associated with a credential; transmitting, by the processing network computer to the storage application server, a token cryptogram; receiving, by the processing network computer, action data for an action to be taken with respect to the additional data; storing, by the processing network computer, the action data, the token, and a token cryptogram associated with the token in a database; receiving, by the processing network computer from a resource provider computer, an authorization request message comprising the token and the token cryptogram; and performing, by the processing network computer, additional processing with respect to the action.

[0006] Another embodiment of the invention includes a processing network computer comprising: a processor; and a computer readable medium, the computer readable medium comprising code, executable by the processor, for performing a method comprising, receiving, from the storage application server storing additional data from an authorizing entity computer, a token cryptogram request message comprising a token associated with a credential; transmitting, to the storage application server, a token cryptogram; receiving action data for an action to be taken with respect to the additional data; storing the action data, the token, and aPATENT Attorney Docket No.079900-1509106 Client Ref. No.: 9722WO01 token cryptogram associated with the token in a database; receiving, from a resource provider computer, an authorization request message comprising the token and the token cryptogram; and performing additional processing with respect to the action.

[0007] Another embodiment of the invention includes a method comprising: receiving, by a storage application server from an authorizing entity computer, additional data associated with a credential; providing, by the storage application server to the processing network computer, a token cryptogram request message comprising a token associated with the credential; receiving, by the storage application server from the processing network computer, the token cryptogram; providing, by the storage application server, action data for an action to be taken with respect to the additional data, wherein the processing network computer stores the action data, the token, and a token cryptogram associated with the token in a database; receiving, by the storage application server from the processing network computer, the token cryptogram; and providing, by the storage application server to a user device comprising a storage application, the token cryptogram.

[0008] Another embodiment of the invention includes a storage application server comprising a processor and a computer readable medium. The computer readable medium comprises code, executable by the processor, for performing a method comprising: receiving, from an authorizing entity computer, additional data associated with a credential; providing, to the processing network computer, a token cryptogram request message comprising a token associated with the credential; receiving, from the processing network computer, the token cryptogram; providing action data for an action to be taken with respect to the additional data, wherein the processing network computer stores the action data, the token, and a token cryptogram associated with the token in a database; receiving, from the processing network computer, the token cryptogram; and providing, to a user device comprising a storage application, the token cryptogram.

[0009] These and other embodiments of the invention are described in further detail below.PATENT Attorney Docket No.079900-1509106 Client Ref. No.: 9722WO01 BRIEF DESCRIPTION OF THE DRAWINGS

[0010] FIG.1 shows a system according to an embodiment.

[0011] FIG. 2 shows a flow diagram illustrating methods according to embodiments of the invention.

[0012] FIG. 3 shows a block diagram of a user device according to embodiments.

[0013] FIG. 4 shows a block diagram of a processing network computer according to an embodiment.

[0014] FIG. 5 shows a storage application server according to an embodiment. DETAILED DESCRIPTION

[0015] Before discussing embodiments of the invention, some description of some terms may be helpful.

[0016] A “user” may include an individual. In some embodiments, a user may be associated with one or more personal accounts and / or mobile devices. The user may also be referred to as a cardholder, account holder, or consumer in some embodiments.

[0017] A “user device” may be a device that is operated by a user. Examples of user devices may include a mobile phone, a smart phone, a card, a personal digital assistant (PDA), a laptop computer, a desktop computer, a server computer, a vehicle such as an automobile, a thin-client device, a tablet PC, etc. Additionally, user devices may be any type of wearable technology device, such as a watch, earpiece, glasses, etc. The user device may include one or more processors capable of processing user input. The user device may also include one or more input sensors for receiving user input. As is known in the art, there are a variety of input sensors capable of detecting user input, such as accelerometers, cameras, microphones, etc. The user input obtained by the input sensors may be from a variety of data input types, including, but not limited to, audio data, visual data, orPATENT Attorney Docket No.079900-1509106 Client Ref. No.: 9722WO01 biometric data. The user device may comprise any electronic device that may be operated by a user, which may also provide remote communication capabilities to a network. Examples of remote communication capabilities include using a mobile phone (wireless) network, wireless data network (e.g., 3G, 4G or similar networks), Wi-Fi, Wi-Max, or any other communication medium that may provide access to a network such as the Internet or a private network.

[0018] A "communication device" may comprise any suitable electronic device that may be operated by a user, which may also provide remote communication capabilities to a network. A "mobile communication device" may be an example of a "communication device" that can be easily transported. Examples of remote communication capabilities include using a mobile phone (wireless) network, wireless data network (e.g., 3G, 4G or similar networks), Wi-Fi, Wi-Max, or any other communication medium that may provide access to a network such as the Internet or a private network. Examples of mobile communication devices include mobile phones (e.g., cellular phones), PDAs, tablet computers, net books, laptop computers, personal music players, hand-held specialized readers, etc. Further examples of mobile communication devices include wearable devices, such as smart watches, fitness bands, ankle bracelets, rings, earrings, etc., as well as automobiles with remote communication capabilities. In some embodiments, a mobile communication device can function as a payment device (e.g., a mobile communication device can store and be able to transmit payment credentials for a transaction).

[0019] A “payment device” may include any suitable device that may be used to conduct a financial transaction, such as to provide payment credentials to a merchant. The payment device may be a software object, a hardware object, or a physical object. As examples of physical objects, the payment device may comprise a substrate such as a paper or plastic card, and information that is printed, embossed, encoded, or otherwise included at or near a surface of an object. A hardware object can relate to circuitry (e.g., permanent voltage values), and a software object can relate to non-permanent data stored on a device. A payment device may be associated with a value such as a monetary value, a discount, or store credit, and a payment device may be associated with an entity such as a bank,PATENT Attorney Docket No.079900-1509106 Client Ref. No.: 9722WO01 a merchant, a payment processing network, or a person. Suitable payment devices can be hand-held and compact so that they can fit into a user's wallet and / or pocket (e.g., pocket-sized). Example payment devices may include smart cards, magnetic stripe cards, keychain devices, etc. Other examples of payment devices include payment cards, smart media, transponders, and the like. If the payment device is in the form of a debit, credit, or smartcard, the payment device may also optionally have features such as magnetic stripes. Such devices can operate in either a contact or contactless mode.

[0020] A “credential” may be any suitable information that serves as reliable evidence of worth, ownership, identity, or authority. A credential may be a string of numbers, letters, or any other suitable characters, as well as any object or document that can serve as confirmation. Examples of credentials include value credentials, identification cards, certified documents, access cards, passcodes, and other login information, etc.

[0021] “Payment credentials” may include any suitable information associated with an account (e.g., a payment account and / or payment device associated with the account). Such information may be related to the account or may be derived from information related to the account. Examples of account information may include a PAN (primary account number or “account number”), username, expiration date, and verification values such as CVV, dCVV, CVV2, dCVV2, and CVC3 values.

[0022] A “digital wallet” can include an electronic device that allows an individual to conduct electronic commerce transactions. A digital wallet may store user profile information, payment credentials, bank account information, one or more digital wallet identifiers and / or the like and can be used in a variety of transactions, such as but not limited to eCommerce, social networks, money transfer / personal payments, mobile commerce, proximity payments, gaming, and / or the like for retail purchases, digital goods purchases, utility payments, purchasing games or gaming credits from gaming websites, transferring funds between users, and / or the like. A digital wallet may be designed to streamline the purchase and payment process. A digital wallet may allow the user to load one or more payment cards onto the digitalPATENT Attorney Docket No.079900-1509106 Client Ref. No.: 9722WO01 wallet so as to make a payment without having to enter an account number or present a physical card.

[0023] A “token” may be a substitute value for a credential. A token may be a string of numbers, letters, or any other suitable characters. Examples of tokens include payment tokens, access tokens, personal identification tokens, etc.

[0024] A "payment token” may include an identifier for a payment account that is a substitute for an account identifier, such as a primary account number (PAN). For example, a payment token may include a series of alphanumeric characters that may be used as a substitute for an original account identifier. For example, a token “4900 0000 0000 0001” may be used in place of a PAN “4147 0900 0000 1234.” In some embodiments, a payment token may be “format preserving” and may have a numeric format that conforms to the account identifiers used in existing transaction processing networks (e.g., ISO 8583 financial transaction message format). In some embodiments, a payment token may be used in place of a PAN to initiate, authorize, settle, or resolve a payment transaction or represent the original credential in other systems where the original credential would typically be provided. In some embodiments, a payment token may be generated such that the recovery of the original PAN or other account identifier from the token value may not be computationally derived. Further, in some embodiments, the token format may be configured to allow the entity receiving the token to identify it as a token and recognize the entity that issued the token.

[0025] “Tokenization” is a process by which data is replaced with substitute data. For example, a payment account identifier (e.g., a primary account number (PAN)) may be tokenized by replacing the primary account identifier with a substitute number (e.g., a token) that may be associated with the payment account identifier. Further, tokenization may be applied to any other information that may be replaced with a substitute value (i.e., token). Tokenization enhances transaction efficiency and security.

[0026] A "token issuer," token provider” or “token service system” can include a system that services tokens. In some embodiments, a token service system can facilitate requesting, determining (e.g., generating) and / or issuing tokens, as well asPATENT Attorney Docket No.079900-1509106 Client Ref. No.: 9722WO01 maintaining an established mapping of tokens to primary account numbers (PANs) in a repository (e.g., token vault). In some embodiments, the token service system may establish a token assurance level for a given token to indicate the confidence level of the token to PAN binding. The token service system may include or be in communication with a token vault where the generated tokens are stored. The token service system may support token processing of payment transactions submitted using tokens by de-tokenizing the tokens to obtain the actual PANs. In some embodiments, a token service system may include a tokenization computer alone, or in combination with other computers such as a transaction processing network computer. Various entities of a tokenization ecosystem may assume the roles of the token service provider. For example, payment networks and issuers or their agents may become the token service provider by implementing the token services according to embodiments of the present invention.

[0027] A “token domain” may indicate an area and / or circumstance in which a token can be used. Examples of token domains may include, but are not limited to, payment channels (e.g., e-commerce, physical point of sale, etc.), POS entry modes (e.g., contactless, magnetic stripe, etc.), and merchant identifiers to uniquely identify where the token can be used. A set of parameters (i.e., token domain restriction controls) may be established as part of token issuance by the token service provider that may allow for enforcing appropriate usage of the token in payment transactions. For example, the token domain restriction controls may restrict the use of the token with particular presentment modes, such as contactless or e-commerce presentment modes. In some embodiments, the token domain restriction controls may restrict the use of the token at a particular merchant that can be uniquely identified. Some exemplary token domain restriction controls may require the verification of the presence of a token cryptogram that is unique to a given transaction. In some embodiments, a token domain can be associated with a token requestor.

[0028] A “token expiry date” may refer to the expiration date / time of the token. The token expiry date may be passed among the entities of the tokenization ecosystem during transaction processing to ensure interoperability. The token expiration date may be a numeric value (e.g., a 4-digit numeric value). In somePATENT Attorney Docket No.079900-1509106 Client Ref. No.: 9722WO01 embodiments, the token expiry date can be expressed as a time duration as measured from the time of issuance.

[0029] A “token request message” may be an electronic message for requesting a token. A token request message may include information usable for identifying a payment account or digital wallet, and / or information for generating a payment token. For example, a token request message may include payment credentials, mobile device identification information (e.g., a phone number or MSISDN), a digital wallet identifier, information identifying a tokenization service provider, a merchant identifier, a cryptogram, and / or any other suitable information. Information included in a token request message can be encrypted (e.g., with an issuer-specific key).

[0030] A “token response message” may be a message that responds to a token request. A token response message may include an indication that a token request was approved or denied. A token response message may also include a payment token, mobile device identification information (e.g., a phone number or MSISDN), a digital wallet identifier, information identifying a tokenization service provider, a merchant identifier, a cryptogram, and / or any other suitable information. Information included in a token response message can be encrypted (e.g., with an issuer-specific key).

[0031] A “token requestor identifier” may include any characters, numerals, or other identifiers associated with an entity associated with a network token system. For example, a token requestor identifier may be associated with an entity that is registered with the network token system. In some embodiments, a unique token requestor identifier may be assigned for each domain for a token request associated with the same token requestor. For example, a token requestor identifier can identify a pairing of a token requestor (e.g., a mobile device, a mobile wallet provider, etc.) with a token domain (e.g., e-commerce, contactless, etc.). A token requestor identifier may include any format or type of information. For example, in one embodiment, the token requestor identifier may include a numerical value such as a ten digit or an eleven digit number (e.g., 4678012345).PATENT Attorney Docket No.079900-1509106 Client Ref. No.: 9722WO01

[0032] A “resource provider” may be an entity that can provide a resource such as goods, services, information, and / or access. Examples of resource providers includes merchants, data providers, transit agencies, governmental entities, venue, and dwelling operators, etc.

[0033] A “merchant” may typically be an entity that engages in transactions and can sell goods or services, or provide access to goods or services.

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

[0035] An “authorizing entity” may be an entity that authorizes a request. Examples of an authorizing entity may be an issuer, a governmental agency, a document repository, an access administrator, etc.

[0036] An “issuer” may typically refer to a business entity (e.g., a bank) that maintains an account for a user. An issuer may also issue payment credentials stored on a user device, such as a cellular telephone, smart card, tablet, or laptop to the consumer.

[0037] An “access device” may be any suitable device that provides access to a remote system. An access device may also be used for communicating with a merchant computer, a transaction processing network computer, an authentication computer, or any other suitable system. An access device may generally be located in any suitable location, such as at the location of a merchant. An access device may be in any suitable form. Some examples of access devices include POS or point of sale devices (e.g., POS terminals), cellular phones, PDAs, personal computers (PCs), tablet PCs, hand-held specialized readers, set-top boxes, electronic cash registers (ECRs), automated teller machines (ATMs), virtual cash registers (VCRs), kiosks, security systems, access systems, and the like. An access device may use any suitable contact or contactless mode of operation to send or receive data from,PATENT Attorney Docket No.079900-1509106 Client Ref. No.: 9722WO01 or associated with, a mobile communication or payment device. In some embodiments, where an access device may comprise a POS terminal, any suitable POS terminal may be used and may include a reader, a processor, and a computer- readable medium. A reader may include any suitable contact or contactless mode of operation. For example, exemplary card readers can include radio frequency (RF) antennas, optical scanners, bar code readers, or magnetic stripe readers to interact with a payment device and / or mobile device. In some embodiments, a cellular phone, tablet, or other dedicated wireless device used as a POS terminal may be referred to as a mobile point of sale or an “mPOS” terminal.

[0038] An “authorization request message” may be an electronic message that requests authorization for a transaction. In some embodiments, it is sent to a transaction processing network computer and / or an issuer of a payment card to request authorization for a transaction. An authorization request message according to some embodiments may comply with ISO 8583, which is a standard for systems that exchange electronic transaction information associated with a payment made by a user using a payment device or payment account. The authorization request message may include an issuer account identifier that may be associated with a payment device or payment account. An authorization request message may also comprise additional data elements corresponding to “identification information” including, by way of example only: a service code, a CVV (card verification value), a dCVV (dynamic card verification value), a PAN (primary account number or “account number”), a payment token, a username, an expiration date, etc. An authorization request message may also comprise “transaction information,” such as any information associated with a current transaction, such as the transaction amount, merchant identifier, merchant location, acquirer bank identification number (BIN), card acceptor ID, information identifying items being purchased, etc., as well as any other information that may be utilized in determining whether to identify and / or authorize a transaction.

[0039] An “authorization response message” may be a message that responds to an authorization request. In some cases, it may be an electronic message reply to an authorization request message generated by an issuing financial institution or a transaction processing network computer. The authorizationPATENT Attorney Docket No.079900-1509106 Client Ref. No.: 9722WO01 response message may include, by way of example only, one or more of the following status indicators: Approval -- transaction was approved; Decline -- transaction was not approved; or Call Center -- response pending more information, merchant must call the toll-free authorization phone number. The authorization response message may also include an authorization code, which may be a code that a credit card issuing bank returns in response to an authorization request message in an electronic message (either directly or through the transaction processing network computer) to the merchant's access device (e.g., POS equipment) that indicates approval of the transaction. The code may serve as proof of authorization.

[0040] A “server computer” may include a powerful computer or cluster of computers. For example, the server computer can be a large mainframe, a minicomputer cluster, or a group of servers functioning as a unit. In one example, the server computer may be a database server coupled to a Web server. The server computer may comprise one or more computational apparatuses and may use any of a variety of computing structures, arrangements, and compilations for servicing the requests from one or more client computers.

[0041] An “Application Programming Interface” or “API” may include software specifying how components of a system should interact. The API may comprise a set of routines, protocols, and tools on which software applications may be built. An API may be used for a web-based system, operating system, database system, computer hardware or software library, and may include specifications for routines, data structures, object classes, variables, and / or remote calls.

[0042] A “plan” can include a proposal for doing or achieving something. A plan can include one or more actions, events, or methods that can be proposed to occur in the future. A plan can include an intention to perform the actions, events, or methods. A plan can include any suitable type of plan, for example, an installment plan (e.g., a payment plan), a data plan, a digital or physical asset transfer plan, and / or any other actions, events, or methods that can be planned to do or achieve a goal. A plan can relate to an interaction. In some embodiments, a plan can alter anPATENT Attorney Docket No.079900-1509106 Client Ref. No.: 9722WO01 interaction in a particular predefined manner (e.g., an installment plan can separate a transaction total into a plurality of payments).

[0043] A “portioning plan” or “portion plan” may be a scheme for dividing something across two or more events based on an installment time. For example, the event may be paying for a portion of a total amount, and the portioning time may be a month (e.g., for monthly payments). In some cases, a portioning plan may be linked to a new, unique line of credit. In some cases, a portioning plan may be linked to a particular payment instrument such as a debit card.

[0044] A “plan identifier” can include a sequence of characters used to identify or refer to a plan such as a portioning plan. A plan identifier can be associated with a particular plan. For example, a first plan identifier can identify and be associated with a first plan, while a second plan identifier can identify and be associated with a second plan. A plan identifier can include alphanumeric characters that may refer to a plan. For example, a plan identifier can be “001” or “plan1,” which may refer to a first plan. As another example, a plan identifier can be “GX834KL” which may refer to plan.

[0045] A method is disclosed. The method includes receiving from the storage application server storing additional data from an authorizing entity computer, a token cryptogram request message comprising a token associated with a credential. The method further includes transmitting, to the storage application server, a token cryptogram, receiving, by the processing network computer, action data for an action to be taken with respect to the additional data, and storing the action data, the token, and a token cryptogram associated with the token in a database. The method also includes performing an authorization process using the token and the token cryptogram, and then performing additional processing with respect to the action.

[0046] FIG. 1 show a block diagram of a system that can implement the method according to an embodiment of the invention. The system includes a user device 10 comprising a storage application 10A managed by and in communication with a storage application server 60. The storage application 10A and / or the storage application server 60 can store a token or a token reference identifier. The storagePATENT Attorney Docket No.079900-1509106 Client Ref. No.: 9722WO01 application server 60 can be in communication with the user device 10 via a long range communication medium.

[0047] In some embodiments, the storage application server 60 may transmit an identifier for a token or an identifier for the underlying credential to the storage application 10A instead of the token itself. This can be advantageous, since such identifiers cannot be used to conduct interactions such as payment transactions. Thus, if they are somehow stolen by an unauthorized entity through hacking or the like, then they would be useless to the unauthorized entity. In other embodiments, the one or more tokens associated with the one or more credentials may be provided to the storage application 10A by the storage application server 60.

[0048] A resource provider computer 20 operated by a resource provider can be in communication with the user device 10. The resource provider computer 20 can be in communication with the user device 10 via a long range communication medium such a cellular network or the Internet, or a short range communication medium such as NFC (near field communications), Bluetooth™, or Wi-Fi™.

[0049] The resource provider computer 20 can be in communication with an authorizing entity computer 50 via a transport computer 30 and a processing network computer 40. The processing network computer 40 can be in communication with the storage application server 60.

[0050] The resource provider computer 20 may be associated with a merchant. The resource provider computer 20 may be an access device such as a POS terminal at a merchant location, a computer coupled with an access device of a merchant, or a remote server computer that operates a web site operated by the merchant. In some embodiments, the merchant operating the resource provider computer 20 may be a card-on-file (COF) merchant. The card-on-file merchant may store consumer account information in a remote database for future payments (e.g., recurring, or periodic payments). The resource provider computer 20 may be configured to generate an authorization request message for a transaction that is initiated by the user.PATENT Attorney Docket No.079900-1509106 Client Ref. No.: 9722WO01

[0051] The transport computer 30 may be operated by an acquirer. An acquirer is typically a system for an entity (e.g., a bank) that has a business relationship with a particular merchant, a wallet provider, or another entity. The transport computer 30 may be communicatively coupled to the resource provider computer 20 and the processing network computer 150 and may issue and manage an account of the merchant.

[0052] The processing network computer 40 may be configured to provide authorization services, and clearing and settlement services for payment transactions. The processing network computer 40 may include data processing subsystems, networks, and operations used to support and deliver authorization services, exception file services, and clearing and settlement services. An exemplary payment processing network may include VisaNet™. Payment processing networks such as VisaNet™ are able to process credit card transactions, debit card transactions, and other types of commercial transactions. VisaNet™, in particular includes a Visa Integrated Payments (VIP) system which processes authorization requests and a Base II system which performs clearing and settlement services. Furthermore, the payment processing network may include a server computer and may use any suitable wired or wireless telecommunications network, including the Internet.

[0053] The processing network computer 40 may also include a token processing module. The token processing module of the processing network computer 40 may be programmed to generate and verify token cryptograms, exchange tokens for real credentials (e.g., PAN), exchange real credentials for tokens, etc. The processing network computer 40 can also be programmed to exchange tokens for credentials in authorization request messages. The processing network computer 40 can also be programmed to exchange credentials for tokens in authorization response messages.

[0054] The authorizing entity computer 50 may be operated by an authorizing entity such as an account issuer. Typically the issuer is an entity (e.g., a bank) that issues and maintains an account of the user. The account may be a credit, debit, prepaid, or any other type of account. The authorizing entity computer 50 can bePATENT Attorney Docket No.079900-1509106 Client Ref. No.: 9722WO01 programmed to generate an authorization response message with an approval or decline of an authorization response message.

[0055] The entities in FIG. 1 and the other Figures may communication using any suitable communications networks. Suitable communications networks may be any one and / or the combination of the following: a direct interconnection; the Internet; a Local Area Network (LAN); a Metropolitan Area Network (MAN); an Operating Missions as Nodes on the Internet (OMNI); mesh networks, a secured custom connection; a Wide Area Network (WAN); a wireless network (e.g., employing protocols such as, but not limited to a Wireless Application Protocol (WAP), I-mode, and / or the like); and / or the like.

[0056] FIG. 2 shows a flow diagram illustrating methods according to embodiments of the invention using a system similar to the one illustrated in FIG.1. For clarity of illustration, the transport computer 30 is not illustrated in FIG.2.

[0057] Prior to step S1, the authorizing entity computer 50 may manage credentials for its users and may store additional data associated with those credentials. For example, the credentials may be real credentials such as account identifiers. The account identifiers may be account numbers such as credit account numbers or debit account numbers associated with credit or debit cards. The additional data may be data that can be used with interactions conducted with the credentials. For example, the additional data may be details of portioning plans (e.g., different portioning plan identifiers such as installment payment plan identifiers) that have been pre-approved by the authorizing entity operating the authorizing entity computer 50. The additional data can include one or more flags associated with portioning plans and or points enrollment information associated with the enrolled one or more credentials. In another example, additional data may relate to values such as point values associated with the credentials. For example, the additional data for a credit card account number may be the number of available points that have been accumulated to date through the use of the credit card account number.

[0058] In some embodiments, the authorizing entity computer 50 can send the additional data to the storage application server 60 before the users conduct interactions using the credentials or token associated with the credentials. In otherPATENT Attorney Docket No.079900-1509106 Client Ref. No.: 9722WO01 embodiments, the authorizing entity computer 50 can send additional data to the storage application server 60 during an interaction that is conducted using a credential or a token associated with the credential.

[0059] At some point in time, the user of the user device 10 may wish to conduct an interaction with a resource provider operating the resource provider computer 20. The interaction may be, for example, an e-commerce transaction. For example, in step S1, the resource provider computer 20 can present a checkout page to the user of the user device 10. The user may select resources (e.g., goods, services, access to secure locations, etc.) to obtain from the resource provider computer 20. When the user is finished, in step S2, the user may select a checkout button to pay for the resources.

[0060] In step S3, before or when the user device 10 is in communication with the resource provider computer 20, the user can select the storage application 10A (e.g., a wallet application), and can then select an identifier for a credential (e.g., the last four digits of an account number) associated with the storage application 10A. The selected credential can be used to use to pay for the purchase. The selection of the credential can then be communicated by the resource provider computer 20 to the storage application server 60.

[0061] In step S4, the storage application server 60 may perform an identity and verification process (ID&V) or other authentication process with respect to the user of the user device 10.

[0062] In some embodiments, the storage application 10A may receive and store the additional data associated with the credential. The additional data may be received by the storage application server 60 from the authorizing entity computer 50 before the start of the interaction. The additional data may include, for example, points or installment plans associated with the credentials, and details thereof, in the storage application 10A.

[0063] In other embodiments, the additional data may not be pre-stored in the storage application 10A, but may be obtained from the authorizing entity computer 50 during the interaction in steps S5 and S6.PATENT Attorney Docket No.079900-1509106 Client Ref. No.: 9722WO01

[0064] In step S5, the storage application server 60 can transmit an additional data request to the authorizing entity computer 50. In response to the additional data request, the authorizing entity computer 50 can determine additional data associated with the user of the user device 10. In some embodiments, the additional data may be based on an account number range or a token. Thus, if a portion of an account number or a token is provided by the storage application server 60 to the authorizing entity computer 50, the authorizing entity computer 50 can determine a set of additional data to return to the storage application server 60. For example, if a portion of a sixteen digit account number starting with “4132832,” then this may be associated with portioning plans A, B, and C, while the portion of the sixteen digit account number starting with “4132833,” may be associated with portioning plans D, E, and F. The additional data could be identifiers for these portioning plans. In some cases, the portioning plan identifiers may be characterized as offer IDs.

[0065] In step S6, authorizing entity computer 50 transmits, and the storage application server 60 receives the additional data. In step S7, after receiving the additional data, the storage application server 60 provides the additional data to the storage application 10A on the user device 10.

[0066] The user can then select an action to be taken with respect to the additional data to create action data. For example, the action may be to accept or initiate an installment plan for the current interaction using the selected credential. In another example, the action may be to use loyalty points in conjunction with the current interaction that will be conducted with the selected credential.

[0067] In step S8, the user device 10, using the storage application 10A, can transmit the selected credential and the action data to the storage application server 60. In some embodiments, the actual credential may not be stored in the storage application 10A. The selected credential may be selected by selecting a button associated with the credential, and the user device 10 can transmit a credential identifier (e.g., the last four digits of a credit card number and the credit card brand) or a token reference identifier to the storage application server 60 in response to the selection.PATENT Attorney Docket No.079900-1509106 Client Ref. No.: 9722WO01

[0068] In step S9, after receiving the action data, the storage application server 60 can provide the token associated with the token reference identifier or the credential identifier, or the token reference identifier, to the processing network computer 40 in a token cryptogram request message.

[0069] After receiving the cryptogram request message, the processing network computer 40 then obtain a cryptogram (e.g., a token cryptogram) for the current interaction using a token processing module (which may be in the form of a token system). In some embodiments, the processing network computer 40 can generate the cryptogram by encrypting, using a cryptographic key, data including two or more of the token, a channel indicator, a transaction amount, a transaction identifier, variable data such as a timestamp or a counter, a resource provider identifier, etc.

[0070] In step S10, the processing network computer 40 can transmit the token cryptogram to the storage application server 60.

[0071] In step S11, after receiving the token cryptogram, the storage application server 60 can then transmit the action data (e.g., an installment plan offer ID), and optionally the token or the token reference identifier, and the token cryptogram for the current interaction to the processing network computer 40. The token and the cryptogram are examples of “dynamic data” (e.g., dynamic payment data). Other types of dynamic data can be used instead of the token and / or cryptogram.

[0072] The transmission of data in step S11 may occur using an API request such as an offer API request. The API request may also include a unique key that identifies the API request and a program identifier (e.g., an identifier for the program, such as installments or points, associated with the action data). The processing network computer 40 can then store the action data, the token, and the token cryptogram associated with the token in a database.

[0073] In step S12, the processing network computer 40 can generate a success response message indicating that the action data, the token, and the tokenPATENT Attorney Docket No.079900-1509106 Client Ref. No.: 9722WO01 cryptogram were successfully stored. The processing network computer 40 can then transmit the success response message to the storage application server 60.

[0074] In step S13, the storage application server 60 can transmit the token and the token cryptogram to the resource provider computer 20. Alternatively, the token and the token cryptogram are provided by the storage application 10A on the user device 10 to the resource provider computer 20. In some embodiments, the user device 10 may have a general purpose application such as a browser and the resource provider computer 20 may operate a resource provider Website. The user device 10 may provide the token and the token cryptogram to the resource provider computer 20 via the browser. In other embodiments, the user device 10 may comprise a resource provider application and the storage application 10A may provide the token and the token cryptogram to the resource provider application, which may then provide them to the resource provider computer 20.

[0075] In step S14, after receiving the token and the token cryptogram, the resource provider computer generates and transmits an authorization request message comprising the token, the token cryptogram, and an amount for a transaction to the processing network computer 40 via a transport computer (not shown in FIG. 2). The processing network computer 40 subsequently receives the authorization request message comprising the token, the token cryptogram, and the amount.

[0076] The processing network computer 40 can then validate the token cryptogram. In some embodiments, the token cryptogram is a first cryptogram, and wherein the method further comprises validating, by the processing network computer 40, the first token cryptogram. The processing network computer 40 can encrypt a set of inputs using a cryptographic key to obtain a second cryptogram and comparing the first cryptogram with the second cryptogram to determine if they match. In other embodiments, the processing network computer 40 can decrypt the first cryptogram to recover its inputs. The processing network computer 40 can compare the obtained inputs to other inputs to validate the cryptogram. In both situations, the channel identifier in the token cryptogram can be validated to ensure that the token is being used in the correct interaction channel. For example, thePATENT Attorney Docket No.079900-1509106 Client Ref. No.: 9722WO01 channel indicator of “1” may indicate that the current transaction is an e-commerce transaction, while the channel indicator of “2” may indicate that the current transaction is an in person transaction. The cryptogram may encrypt the channel indicator “1” along with other data. If the channel indicator in the first and second token cryptograms match and the cryptograms themselves match, then the first token cryptogram is valid. The use of channel indicators in token cryptograms limits the token’s use to a specific interaction channel, thereby improving data security. If the token is stolen and is used in the wrong interaction channel, then the token cryptogram would not be validated.

[0077] The processing network computer 40 can also perform additional processing with respect to the action. In some embodiments, the action can be an action related to the selected installment plan or the points. The additional processing can be in response to the processing network computer matching the received token cryptogram to the previously generated token cryptogram. The processing network computer 40 may determine that additional processing is to be performed for the current interaction by recognizing the token cryptogram (or a different type of transaction identifier) in the authorization request message. For example, the additional processing may be to include data in the authorization request message informing the authorizing entity computer 50 to apply a certain number of loyalty points to the current interaction. In another example, the additional processing may be to include data in the authorization request message regarding a selected portioning plan before transmitting it to the authorizing entity computer. The additional processing may also include executing a particular portioning plan with respect to the current interaction. In other embodiments, the processing network computer 40 can perform additional processing by passing the action data or the additional data to the authorizing entity computer 50 via a different communication channel (via an API) than the authorization request channel.

[0078] In step S15, after validating the token cryptogram, the processing network computer 40 can obtain a credential associated with the token from a database, modify the authorization request message to include the credential instead of the token and possible other data including some of the action data or additionalPATENT Attorney Docket No.079900-1509106 Client Ref. No.: 9722WO01 data, and transmit the modified authorization request message to the authorizing entity computer 50.

[0079] The authorizing entity computer 50 can review the modified authorization request message and can determine whether or not it should be authorized. It can review the account associated with the credential to determine if there is sufficient funds or credit in it. It can also conduct a fraud analysis on the transaction. It can also take any action with respect to any action data or additional data that it received. For example, if the action data relates to the selection of a portioning plan identifier or the application of points, then the authorizing entity computer 50 can initiate the portioning plan or apply any points after the interaction is completed. For example, if the transaction is for $100, then a portioning plan may bill the user of the user device 10 in 2 installments of $50 each. In another example, if the transaction is for $100 and the user has requested that $20 worth of points be applied to the transaction, then the authorizing entity computer 50 may debit the user’s points account for $20 worth of points and may invoice the user for $80.

[0080] After reviewing the authorization request message, the authorizing entity computer 50 can generate an authorization response message. The authorization response message may include an approval indicator indicating that the interaction was or was not approved, and the credential.

[0081] In step S16, the authorizing entity computer 50 can then transmit the authorization response message to the processing network computer 40. The processing network computer 40 can then re-tokenize the credential to obtain the token associated with the credential.

[0082] In step S17, the processing network computer 40 can then modify the authorization response message and transmit it to the resource provider computer 20 via the transport computer.

[0083] In step S18, the resource provider computer 20 can notify the user operating the user device 10 that the interaction was successful.PATENT Attorney Docket No.079900-1509106 Client Ref. No.: 9722WO01

[0084] At the end of the day or any other suitable period of time, a clearing and settlement process can occur between the transport computer, the processing network computer 40, and the authorizing entity computer 50.

[0085] The steps in FIG. 2 can be performed in different orders in embodiments of the invention. For example, in some embodiments, steps S5 and S6 can occur before steps S1 and S2.

[0086] Although the example above describes a remote interaction such as an e-commerce transaction, other embodiments of the invention can include cross- border transactions and in-store use cases.

[0087] The solutions according to embodiments of the invention can be network-agnostic, and can apply to multiple seller-side entities, including token requestors, digital wallets, merchant aggregators, and merchants.

[0088] FIG. 3 is a block diagram illustrating a user device 300 according to certain embodiments. The user device 300 can include a device (e.g., mobile phone) executing a number of mobile applications and capable of performing processing tasks as described herein. The user device 300 may include device hardware 304 coupled to a system memory 302.

[0089] Device hardware 304 may include a processor 306, a short range antenna 314, a long range antenna 316, input elements 310, a user interface 308, and output elements 312 (which may be part of the user interface 308). Examples of input elements may include microphones, keypads, touchscreens, sensors, etc. Examples of output elements may include speakers, display screens, and tactile devices. The processor 306 can be implemented as one or more integrated circuits (e.g., one or more single core or multicore microprocessors and / or microcontrollers), and is used to control the operation of mobile device 102. The processor 306 can execute a variety of programs in response to program code or computer-readable code stored in the system memory 302, and can maintain multiple concurrently executing programs or processes.

[0090] The long range antenna 316 may include one or more RF transceivers and / or connectors that can be used by user device 300 to communicate with otherPATENT Attorney Docket No.079900-1509106 Client Ref. No.: 9722WO01 devices and / or to connect with external networks. The user interface 308 can include any combination of input and output elements to allow a user to interact with and invoke the functionalities of user device 300. The short range antenna 314 may be configured to communicate with external entities through a short range communication medium (e.g., using Bluetooth, Wi-Fi, infrared, NFC, etc.). The long range antenna 216 may be configured to communicate with a remote base station and a remote cellular or data network, over the air.

[0091] The system memory 302 can be implemented using any combination of any number of non-volatile memories (e.g., flash memory) and volatile memories (e.g., DRAM, SRAM), or any other non-transitory storage medium, or a combination thereof media. The system memory 302 may store computer code, executable by the processor 306, for performing any of the functions described herein. For example, the system memory 302 may comprise a computer readable medium comprising code, executable by the processor 306, for implementing a method as described herein.

[0092] The system memory 302 can have a storage application 306A, a resource provider application 306B, tokens / credentials 306C, and an authentication application 306D.

[0093] FIG. 4 is an illustration of an example processing network computer 140 according to certain embodiments. The processing network computer 140 can include a processor 402 and a computer readable medium 404, a data storage 406, and a network interface 408 coupled to the processor 402.

[0094] The data storage 406 can store credentials, tokens, additional data, and action data as described above.

[0095] The computer readable medium 404 can implement an information processing module 404A. The information processing module 404A and the processor 402 can receive information such as tokens, token cryptograms, and action data, store it, and transfer it to the data storage 406. This information can be stored for later retrieval by the authorization module 404D during authorization processing.PATENT Attorney Docket No.079900-1509106 Client Ref. No.: 9722WO01

[0096] The computer readable medium 404 can also implement a cryptographic processing module 404B. The cryptographic processing module 404B can, in conjunction with the processor 402, perform encryption, decryption, signature validation, and digital signing.

[0097] The computer readable medium 404 can also implement a token processing module 404C. The token processing module 404C can generate or obtain a token for provisioning. The token processing module 404C can also exchange the token for a credential, and vice versa. The token processing module 404C may also maintain rules or restrictions on how tokens may be used. The mapping between each generated token and a credential for each provisioned user device can be maintained by the data storage 406. The token processing module 404C may also comprise code, executable by the processor 402 for performing cryptogram validation (as described above).

[0098] The computer readable medium 404 can also implement an authorization module 404D and a clearing and settlement module 404E. The authorization module 404D and the processor 402 can receive, modify, and transmit authorization request and response messages. The clearing and settlement module 404E and the processor 402 can perform clearing and settlement processing with respect to many authorizing entity computers and many transport computers.

[0099] The computer readable medium 404 can also comprise code, executable by the processor for implementing a method comprising: receiving, from the storage application server storing additional data from an authorizing entity computer, a token cryptogram request message comprising a token associated with a credential; transmitting, to the storage application server, a token cryptogram; receiving action data for an action to be taken with respect to the additional data; storing the action data, the token, and a token cryptogram associated with the token in a database; receiving, from a resource provider computer, an authorization request message comprising the token and the token cryptogram; and performing additional processing with respect to the action.

[0100] FIG.5 is an illustration of a storage application server 500 according to certain embodiments. The storage application server 500 can include a processorPATENT Attorney Docket No.079900-1509106 Client Ref. No.: 9722WO01 502 and a computer readable medium 504, a data storage 506, and a network interface 508 coupled to the processor 502.

[0101] The computer readable medium 504 can implement a device registration module 504A. The device registration module 504A and the processor 502 can register one or more user devices associated with a user.

[0102] The computer readable medium 504 can also implement a storage application management module 504B. The storage application management module 504B can comprise code for managing storage applications on user devices.

[0103] The computer readable medium 504 can also comprise a cryptographic processing module 504C. The cryptographic processing module 504C and the processor 502 can perform cryptographic operations including encryption, decryption, signing, and signature validation.

[0104] The computer readable medium 504 can also implement a communication module 504D. The communication module 504D and the processor 502 can allow the storage application server 500 to communicate with external entities such as user devices and the above described processing network computer.

[0105] The data storage 506 can securely store various data relating to user devices. For example, the data storage 506 can store user device details, tokens, token reference identifiers, credential identifiers, additional data, action data, usernames, passwords, etc.

[0106] The computer readable medium 504 can comprise code, executable by the processor 502 for implementing a method comprising: receiving, from an authorizing entity computer, additional data associated with a credential; providing, to the processing network computer, a token cryptogram request message comprising a token associated with the credential; receiving, from the processing network computer, the token cryptogram; providing action data for an action to be taken with respect to the additional data, wherein the processing network computer stores the action data, the token, and a token cryptogram associated with the token in a database; receiving, from the processing network computer, the tokenPATENT Attorney Docket No.079900-1509106 Client Ref. No.: 9722WO01 cryptogram; and providing, to a user device comprising a storage application, the token cryptogram.

[0107] Embodiments of the invention have a number of advantages. Embodiments of the invention can allow for the sharing of additional data between an authorizing entity computer and a storage application server, without requiring a processing network computer as an intermediary. This reduces the number of communications relative to other systems and simplifies data processing and reduces the need for additional computational resources. In addition, embodiments of the invention can use token cryptograms and / or tokens to identify action data that was provided via a different channel than an authorization request channel. Once identified, the action data can be included in a message that can be provided to an authorizing entity computer. This can be done without significant changes to the format of existing authorization request messages. Further, the use of tokens and token cryptograms provides for improved data security, relative to transactions that are conducted with sensitive credentials such as account numbers.

[0108] Any of the software components or functions described in this application, may be implemented as software code to be executed by a processor using any suitable computer language such as, for example, Java, C++, 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, such as a random access memory (RAM), a read only memory (ROM), a magnetic medium such as a hard-drive or a floppy disk, or an optical medium such as a CD-ROM. Any such computer readable medium may reside on or within a single computational apparatus, and may be present on or within different computational apparatuses within a system or network.

[0109] The above description is illustrative and is not restrictive. Many variations of the invention may become apparent to those skilled in the art upon review of the disclosure. The scope of the invention can, therefore, be determined not with reference to the above description, but instead can be determined with reference to the pending claims along with their full scope or equivalents.PATENT Attorney Docket No.079900-1509106 Client Ref. No.: 9722WO01

[0110] 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 invention.

[0111] A recitation of "a", "an" or "the" is intended to mean "one or more" unless specifically indicated to the contrary.

[0112] All patents, patent applications, publications, and descriptions mentioned above are herein incorporated by reference in their entirety for all purposes. None is admitted to be prior art.

Claims

PATENT Attorney Docket No.079900-1509106 Client Ref. No.: 9722WO01 WHAT IS CLAIMED IS:

1. A method comprising: receiving, by the processing network computer from the storage application server storing additional data from an authorizing entity computer, a token cryptogram request message comprising a token associated with a credential; transmitting, by the processing network computer to the storage application server, a token cryptogram; receiving, by the processing network computer, action data for an action to be taken with respect to the additional data; storing, by the processing network computer, the action data, the token, and a token cryptogram associated with the token in a database; receiving, by the processing network computer from a resource provider computer, an authorization request message comprising the token and the token cryptogram; and performing, by the processing network computer, additional processing with respect to the action.

2. The method of claim 1, wherein the action is an instantiation of a portioning plan, and the additional data relates to portioning plan identifiers and / or points.

3. The method of claim 1, wherein the storage application server provides the token cryptogram and the token to the resource provider computer.

4. The method of claim 1, further comprising: validating, by the processing network computer, the token cryptogram; obtaining, by the processing network computer, the credential associated with the token; modifying, by the processing network computer, the authorization request message to include the credential instead of the token; and transmitting, by the processing network computer, the modified authorization request message to an authorizing entity computer.PATENT Attorney Docket No.079900-1509106 Client Ref. No.: 9722WO01 5. The method of claim 4, further comprising: receiving, by the processing network computer from the authorizing entity computer, an authorization response message comprising the credential; obtaining, by the processing network computer, the token using the credential; modifying, by the processing network computer, the authorization response message to include the token instead of the credential; and transmitting, by the processing network computer, the modified authorization response message to the resource provider computer.

6. The method of claim 1, wherein the action is an instantiation of a portioning plan, and the additional data relates to portioning plan identifiers, and wherein performing additional processing initiating execution of the portioning plan.

7. The method of claim 1, wherein the token cryptogram is a first token cryptogram, and wherein the method further comprises: validating, by the processing network computer, the first token cryptogram by encrypting a set of inputs using a cryptographic key to obtain a second cryptogram and comparing the first token cryptogram with the second cryptogram to determine if they match.

8. The method of claim 1, wherein the additional data is received from the authorizing entity computer without the involvement of the processing network computer.

9. The method of claim 1, wherein the storage application server provides the token cryptogram and the token to a storage application on a user device, and the user device provides the token and the token cryptogram to the resource provider computer.

10. The method of claim 1, wherein the storage application server provides the token cryptogram and the token to a storage application on a user device, and thePATENT Attorney Docket No.079900-1509106 Client Ref. No.: 9722WO01 user device provides the token and the token cryptogram to the resource provider computer via a resource provider application on the user device.

11. The method of claim 10, wherein the user device is a mobile phone.

12. A processing network computer comprising: a processor; and a computer readable medium, the computer readable medium comprising code, executable by the processor, for performing a method comprising, receiving, from the storage application server storing additional data from an authorizing entity computer, a token cryptogram request message comprising a token associated with a credential; transmitting, to the storage application server, a token cryptogram; receiving action data for an action to be taken with respect to the additional data; storing the action data, the token, and a token cryptogram associated with the token in a database; receiving, from a resource provider computer, an authorization request message comprising the token and the token cryptogram; and performing additional processing with respect to the action.

13. The processing network computer of claim 12, wherein the method further comprises: validating the token cryptogram; obtaining, by the processing network computer, the credential associated with the token; modifying the authorization request message to include the credential instead of the token; and transmitting the modified authorization request message to an authorizing entity computer.

14. A method comprising:PATENT Attorney Docket No.079900-1509106 Client Ref. No.: 9722WO01 receiving, by a storage application server from an authorizing entity computer, additional data associated with a credential; providing, by the storage application server to the processing network computer, a token cryptogram request message comprising a token associated with the credential; receiving, by the storage application server from the processing network computer, the token cryptogram; providing, by the storage application server, action data for an action to be taken with respect to the additional data, wherein the processing network computer stores the action data, the token, and a token cryptogram associated with the token in a database; receiving, by the storage application server from the processing network computer, the token cryptogram; and providing, by the storage application server to a user device comprising a storage application, the token cryptogram.

15. The method of claim 14, wherein the token is provided by the storage application server to the user device along with the token cryptogram.

16. The method of claim 15, wherein the processing network computer is programmed to: receive from a resource provider computer an authorization request message comprising the token and the token cryptogram; and performing additional processing with respect to the action.

17. The method of claim 14, wherein the action is an instantiation of a portioning plan, and the additional data relates to portioning plan identifiers.

18. The method of claim 14, wherein the user device further comprises a resource provider application, and in the method, the storage application provides the token and the token cryptogram to the storage application.PATENT Attorney Docket No.079900-1509106 Client Ref. No.: 9722WO01 19. The method of claim 14, wherein the token is a substitute for the credential.

20. The method of claim 14, wherein the additional data is received from the authorizing entity computer without the involvement of the processing network computer.

Images