CROSS-REFERENCE TO RELATED APPLICATIONS
This application claims priority to and the benefit of the filing date of U.S. Application Serial No. 14/957,444, filed December 2, 2015, which is hereby incorporated by reference in its entirety.
FIELD
The present disclosure relates to the enhanced validation of a token requestor, specifically the use of a unique identification value conveyed via a specially formatted data message using a specified protocol and communication infrastructure to validate an entity providing a token as an authorized entity for usage of the token.
BACKGROUND
As more and more data exchanges and other transactions of information occur online, more and more entities configure their systems for the storage of sensitive user information and other data that is regularly used and transmitted, to provide for faster, more convenient usage by users, as well as in an effort to increase user security by not requiring the user to continuously resubmit the information. In many instances, having the entity store the sensitive data may be beneficial, as the entity's security and network may be greater than that of the user's. For instance, an entity might store payment card information, and be a Card-On-File (COF) entity. However, as entities begin to store more and more data for more and more users, they become a higher profile target of nefarious parties hoping to compromise the stored data. Such date may be highly valuable to a nefarious party, while the theft of such data may be exceedingly detrimental to the user, such as in instances where a social security number of credit card number are stolen.

Thus, mere is a need for a technical solution where an entity can store sensitive user data for future transmission and use while rendering the data itself unusable in the hands of a non-authorized entity. By associating the sensitive data with the entity to which it is provided, future usage of that data can be prohibited unless being used by the entity or an authorized party, thus negating the detrimental effects of the compromise of the data. Particularly in the realm of electronic

transactions and payment networks, the use of specialized payment tokens and entity-specific identifiers may enable a merchant, wallet provider, or other entity to store data suitable for use in a transaction that enables a user to transact without continuously resubmitting their information, while at the same time protecting the user from harm should the data be compromised.

SUMMARY

The present disclosure provides a description of systems and methods for enhanced validation of an entity associated with a Card-On-File (COF)-specific token,

A method for enhanced validation of an entity associated with a COF token includes: storing, in a memory of a processing server, at least transaction data, a token requester identifier (TRID), and a COF token identifier, receiving, by a receiving device of the processing server, payment credentials, wherein the payment credentials include at least a COF-specific payment token; generating, by a generation module of the processing server, a transaction message, wherein the transaction message is formatted based on one or more standards and includes at least a plurality of data elements including at least a first data element configured to store the COF-specific payment token, a second data element configured to store the COF token identifier, a third data element configured to store the token requester identifier

(TRID), and one or more additional data elements configured to store the transaction data; and electronically transmitting, by a transrmtting device of the processing server, the generated transaction message to a financial institution via a payment network.

Another method for enhanced validation of an entity associated with a COF token includes: storing, in a COF entity database of a processing server, a plurality of COF entity profiles, wherein each COF entity profile includes a structured data set related to an entity associated with a COF token including at least a COF token identifier and at least one token requester identifier (TRID) and/or COF-specific payment token; storing, in a token database of the processing server, a plurality of token profiles, wherein each token profile includes a structured data set related to a COF-specific payment token including at least the related COF-specific payment token and a transaction account number; receiving, by a receiving device of the processing server, a transaction message, wherein the transaction message is formatted based on one or more standards and includes a plurality of data elements

including at least, a first data element configured to store a specific payment token, a second data element configured to store a specific COF token identifier, a third data element configured to store a specific token requester identifier (TRID), and one or more additional data elements configured to store transaction data; executing, by a querying module of the processing server, a query on the COF entity database to identify a specific COF entity profile where the included COF token identifier corresponds to the specific COF token identifier stored in the second data element included in the received transaction message; executing, by the querying module of the processing server, a query on the token database to identify a specific token profile where the included payment token corresponds to the specific COF-specific payment token stored in the first data element included in the received transaction message; validating, by a validation module of the processing server, the entity related to the identified specific COF entity profile as genuine based on a correspondence between an included token requester identifier (TRID) and the specific token requester identifier (TRID) stored in the third data element included in the received transaction message or an included COF-specific payment token and the specific COF-specific payment token stored in me first data element included in the received transaction message; modifying, by a generation module of the processing server, the received transaction message by replacing the specific payment token stored in the first data element with the transaction account number stored in the identified specific token profile; and electronically transmitting, by a transmitting device of the processing server, the modified transaction message to a financial institution via a payment network.

A system for enhanced validation of an entity associated with a COF token includes: a memory of a processing server configured to store at least transaction data, a token requester identifier (TRID), and a COF token identifier; a receiving device of the processing server configured to receive payment credentials, wherein the payment credentials include at least a payment token; a generation module of the processing server configured to generate a transaction message, wherein the transaction message is formatted based on one or more standards and includes at least a plurality of data elements including at least a first data element configured to store the payment token, a second data element configured to store the COF token identifier, a third data element configured to store the token requester identifier (TRID), and one or more additional data elements configured to store the transaction data; and a transmitting device of the processing server configured to electronically transmit the generated transaction message to a financial institution via a payment network.

Another system for enhanced validation of an entity associated with a COF token includes: a COF entity database of a processing server configured to store a plurality of COF entity profiles, wherein each COF entity profile includes a structured data set related to an entity associated with a COF token including at least a COF token identifier and at least one token requester identifier (TRID) and/or payment token; a token database of the processing server configured store a plurality of token profiles, wherein each token profile includes a structured data set related to a payment token including at least the related payment token and a transaction account number; a receiving device of the processing server configured to receive a transaction message, wherein the transaction message is formatted based on one or more standards and includes a plurality of data elements including at least a first data element configured to store a specific payment token, a second data element configured to store a specific COF token identifier, a third data element configured to store a specific token requester identifier (TRID), and one or more additional data elements configured to store transaction data; a querying module of the processing server configured to execute a query on the COF entity database to identify a specific COF entity profile where the included COF token identifier corresponds to the specific COF token identifier stored in the second data element included in the received transaction message, and execute a query on the token database to identify a specific token profile where the included payment token corresponds to the specific payment token stored in the first data element included in the received transaction message; a validation module of the processing server configured to validate the entity related to the identified specific COF entity profile as genuine based on a correspondence between an included token requester identifier (TRID) and the specific token requester identifier (TRID) stored in the third data element included in the received transaction message or an included payment token and the specific payment token stored in the first data element included in the received transaction message; a generation module of the processing server configured to modify the received transaction message by replacing the specific payment token stored in the first data element with the transaction account number stored in the identified specific token profile; and a transmitting device of the processing server configured to

electronically transmit the modified transaction message to a financial institution via a payment network.

BRIEF DESCRIPTION OF THE DRAWING FIGURES

The scope of the present disclosure is best understood from the following detailed description of exemplary embodiments when read in conjunction with the accompanying drawings. Included in the drawings are the following figures:

FIG. 1 is a block diagram illustrating a high level system architecture for the enhanced validation of a token requesting entity in accordance with exemplary embodiments.

FIG.2 is a block diagram illustrating the COF entity server of FIG. 1 for the use of a COF token identifier for validation of transaction messages originating therefrom in accordance with exemplary embodiments.

FIG. 3 is a block diagram illustrating the validation server of FIG. 1 for the enhanced validation of transaction messages originating from COF entity servers using COF token identifiers in accordance with exemplary embodiments.

FIG.4 is a flow diagram illustrating a process for registration of a COF token and identifier for use in enhanced validation in the system of FIG. 1 in accordance with exemplary embodiments.

FIGS. SA and SB are a flow diagram illustrating a process for enhanced validation of a transaction message and associated COF entity using COF tokens and identifiers in accordance with exemplary embodiments.

FIGS. 6 and 7 are flow charts illustrating exemplary methods for conducting of an offline data exchange associated with a blockchain in accordance with exemplary embodiments.

FIG. 8 is a flow diagram illustrating the processing of a payment transaction in accordance with exemplary embodiments.

FIG. 9 is a block diagram illustrating a computer system architecture in accordance with exemplary embodiments.

Further areas of applicability of the present disclosure will become apparent from the detailed description provided hereinafter. It should be understood that the detailed description of exemplary embodiments are intended for illustration purposes only and are, therefore, not intended to necessarily limit the scope of the disclosure.

DETAILED DESCRIPTION

Glossary of Terms

Payment Network - A system or network used for the transfer of money via the use of cash-substitutes. Payment networks may use a variety of different protocols and procedures in order to process the transfer of money for various types of transactions. Transactions that may be performed via a payment network may include product or service purchases, credit purchases, debit transactions, fund transfers, account withdrawals, etc. Payment networks may be configured to perform transactions via cash-substitutes, which may include payment cards, letters of credit, checks, transaction accounts, etc. Examples of networks or systems configured to perform as payment networks include those operated by MasterCard*, VISA* Discover*, American Express*, PayPal* etc. Use of the term "payment network" herein may refer to both the payment network as an entity, and the physical payment network, such as the equipment, hardware, and software comprising the payment network.

Payment Rails - Infrastructure associated with a payment network used in the processing of payment transactions and the communication of transaction messages and other similar data between the payment network and other entities interconnected with the payment network The payment rails may be comprised of the hardware used to establish the payment network and the interconnections between the payment network and other associated entities, such as financial institutions, gateway processors, etc. In some instances, payment rails may also be affected by software, such as via special programming of the communication hardware and devices that comprise the payment rails. For example, the payment rails may include specifically configured computing devices that are specially configured for the routing of transaction messages, which may be specially formatted data messages mat are electronically transmitted via the payment rails, as discussed in more detail below.

Payment Card - A card or data associated with a transaction account that may be provided to a merchant in order to fund a financial transaction via the associated transaction account. Payment cards may include credit cards, debit cards, charge cards, stored-value cards, prepaid cards, fleet cards, virtual payment numbers, virtual card numbers, controlled payment numbers, etc. A payment card may be a physical card that may be provided to a merchant, or may be data representing the associated transaction account (e.g., as stored in a communication device, such as a smart phone or computer). For example, in some instances, data including a payment account number may be considered a payment card for the processing of a transaction funded by the associated transaction account In some instances, a check may be considered a payment card where applicable.

COF entity - a COF entity may be a merchant, acquirer, payment service provide (PSP) and wallet, and any other computer system of that might otherwise hold payment card information for future transactions.

System for Enhanced Validation of Token Holding Entities

FIG. 1 illustrates a system 100 for the enhanced validation of a token holding entity and of transaction messages and other sensitive data originating therefrom.

The system 100 may include a COF entity server 102. The COF entity server 102, discussed in more detail below, may be configured to store sensitive data for use in electronic transactions. For example, the COF entity server 102 may be a specially configured computing system of a COF entity, which may be configured to store payment details associated with a transaction account for use in funding electronic transactions. The system 100 may also include a validation server 104. The validation server 104, discussed in more detail below, may be configured to validate the sensitive data originating from the COF entity server 102 as genuine. Using the methods and systems discussed herein, the COF entity server 102 may be configured to register with the validation server 104 for a COF-specific payment token, which may be issued to the COF entity server 102 or an entity associated therewith, referred to herein as a "token requesting entity" or "token requestor" in place of a primary account number and/or other payment details along with a COF entity -specific identifier for use in validation of the COF-specific payment token.

In some instances, the system 100 may include a wallet provider 106. The wallet provider 106 may be an entity configured to provide an electronic wallet, which would hold a token, for use by a consumer 108 via a computing device 110 for the storage of payment details associated with a transaction account for use in funding electronic transactions. The computing device 110 may be a desktop computer, laptop computer, notebook computer, tablet computer, cellular phone, smart phone, smart watch, smart television, wearable computing device, implantable computing device, or any other computing device suitable to store and use an electronic wallet. As discussed herein, the wallet provider 106 may be a token requesting entity such that a wallet would be a COF entity. In such instances, the wallet provider 106 may register for an entity-specific payment token from the validation server 104 and associated entity-specific identifier for use in place of payment details to be stored in the computing device 110 and conveyed to the validation server 104 for validation as part of an electronic transaction. Accordingly, the functions, configurations, and specifications of the merchant server 102 may be applicable to the wallet provider 106. For example, the registration and use of merchant-specific tokens and identifiers discussed herein may be applicable to a wallet provider 106 as a COF entity.

A consumer 108 may, using a computing device 110, provide payment details to a COF entity server 102 for storage and future use in electronic payment transactions. In some embodiments, the payment details may be stored specifically for use in electronic commerce ("e-commerce") transactions, such as may be conducted using the Internet, a cellular communication network, or other suitable communication method for the conducting of e-commerce transactions as will be apparent to persons having skill in the relevant art The payment details may be associated with a transaction account issued to the consumer 108 by an issuer 112. The issuer 112 may be a financial institution, such as an issuing bank, or other entity configured to store, manage, issue, or otherwise be associated with transaction accounts suitable for use in funding e-commerce transactions.

Once the consumer 108 has supplied payment details for a transaction account to the COF entity server 102, the COF entity server 102 may register with the validation server 102 for a COF-specific payment token in place of the payment details. In some cases, the payment details may comprise the transaction account number of the transaction account In other cases, the payment details may include additional data associated therewith for use in processing e-commerce transactions and/or authentication in the registration of the transaction account by the issuer 112. In some embodiments, the COF entity server 102 may electronically transmit the payment details to be replaced directly to the validation server 104. In other embodiments, the COF entity server 102 may electronically transmit authentication data associated with the transaction account to the validation server 104. In such an embodiment the validation server 104 may be configured to retrieve the payment

details from the corresponding issuer 112 by supplying the authentication data and any other necessary information, such as an indication of the transaction account for instances where the consumer 108 may have multiple transaction accounts with the issuer 112.

The validation server 104 may be configured to generate a COF-specific payment token. The COF-specific payment token may be a unique value suitable for use as a primary account number in e-commerce transactions. For example, the COF-specific payment token may be a 16-19 digit number, which may be formatted using standards associated with primary account numbers, such as by including a bank identification number associated with the validation server 104 for use in the routing of transaction messages thereto. The validation server 104 may also generate a specific TRID. The specific TRID may be a unique identification value associated with the COF entity server 102 or an entity associated therewith. In some embodiments, the validation server 104 may generate a COF token identifier, which may be a unique to the COF entity server 102 as well as the COF-specific payment token. In such instances, the COF entity server 102 may receive a different COF token identifier for each transaction account registered with the validation server 104.

When conducting an e-commerce transaction, the consumer 108 may select one or more products (e.g., goods or services) for purchase from a merchant associated with the COF entity server 102 (and therefore a COF entity), such as via a website accessed by or specially configured application program executed by the computing device 110. The consumer 108 may indicate for the usage of previously-provided payment details in funding the e-commerce transaction. For example, the consumer 108 may be provided with a prompt, drop-down box, or other selection tool for the selection of a previously-registered transaction account, such as by selecting a transaction account identified using the last four numbers of the corresponding transaction account number.

The COF entity server 102 may then electronically transmit transaction data for the e-commerce transaction, as well as the merchant-specific payment token indicated by the consumer 108 and the merchant-specific identifier (e.g., or COF token identifier, as applicable) to an acquirer 114. The transaction data may be any additional data suitable for use in the processing of an e-commerce transaction, such as a transaction amount, transaction time, transaction data, geographic location, merchant identifier, point of sale data, product data, offer data, reward data, loyalty data, etc. The acquirer 114 may be a financial institution, such as an acquiring bank, or other entity configured to store, manage, issue, or otherwise be associated with a transaction account issued to the COF entity server 102 or entity associated therewith for use in receiving funds in an e-commerce transaction.

The acquirer 114 may then generate a transaction message for the payment transaction. The transaction message may be a data message specially formatted pursuant to one or more standards governing the exchange of financial transaction messages, such as the International Organization for Standardization's ISO 8S83 standard. The transaction message may include a plurality of data elements configured to store data associated with the payment transaction, such as a first data element configured to store a transaction amount, a second data element configured to store a transaction time, etc. The transaction message may also include a message type indicator indicative of a type of the transaction message, such as a message type indicator indicative of an authorization request for transaction messages originating from the acquirer 114 seeking authorization of the related payment transaction. The transaction message may also include a bitmap, which may indicate the data elements included therein and the data values the data elements are configured to store.

The transaction message generated by the acquirer 114 may include, in addition to other data elements used in the processing of the payment transaction, a data element configured to store the COF-specific payment token and a data element configured to store the specific TRID or token identifier. In some instances, the transaction message may also include a data element configured to store data indicating mat the payment transaction is an e-commerce transaction. The acquirer 114 may electronically transmit the generated transaction message to a payment network 116 using payment rails. As discussed in more detail below with respect to the process illustrating in FIG. 8, the payment rails may be a specialized

communication network and infrastructure associated with a payment network 116 for the conveyance of transaction messages.

The payment network 116 may receive the transaction message and may parse the data stored in the data elements included therein. The payment network 116 may identify the COF-specific payment token stored in the

corresponding data element, and then forward the transaction message to the validation server 104. In some embodiments, the payment network 116 may only forward the COF-specific payment token and identifier or token identifier, as well as any other data suitable for use in performing the functions discussed herein (e.g., such as a cryptogram, as discussed below), to the validation server 104. In some embodiments, the data may be electronically transmitted to the validation server 104 using the payment rails. In other embodiments, a suitable alternative communication network may be used, such as the Internet In some cases, the validation server 104 may be a part of the payment network 116. In such cases, the validation server 104 may receive the transaction message or data using internal communication networks and methods, or, in some instances, may receive the transaction message directly from the acquirer 114 using the payment rails.

The validation server 104 may then validate the COF entity server 102 from which the transaction originated as authorized to use the COF-specific payment token. The validation may be based on the specific TRID or token identifier stored in the corresponding data element included in the transaction message. The validation server 104 may validate that the COF entity server 102 (e.g., via the acquirer 114) provided the specific TRID or token identifier that is associated with the specific COF-specific payment token used in the e-commerce transaction. If an incorrect specific TRID or token identifier is provided, men the validation server 104 may indicate to the payment network 116 that the payment transaction is to be denied. The payment network 116 may then process the payment transaction accordingly using traditional methods and systems for the processing of a denied payment transaction.

If the correct specific TRID or token identifier is provided, then the validation server 104 may swap the COF-specific payment token for the

corresponding transaction account number that was provided or otherwise acquired in the registration process for the COF-specific payment token. In some embodiments, the validation server 104 may provide the transaction account number to the payment network 116, which may then replace the COF-specific payment token with the transaction account number in the corresponding data element of the transaction message. In other embodiments, the validation server 104 may directly replace the COF-specific payment token with the transaction account number and return the transaction message, now with the transaction account number, to the payment network 116.

Once the payment network 116 has the transaction message with the transaction account number, the payment network 116 may process the payment transaction using traditional methods and systems, such as using the process 800

illustrated in FIG. 8 and discussed in more detail below. In an exemplary

embodiment, the transaction account number may be replaced with the COF-specific payment token (e.g., by the payment network 116 or validation server 104) prior to the transmission of a return transaction message (e.g., an authorization response) to the acquirer 114 indicating of the payment transaction was approved or denied by the issuer 112. In such an embodiment, the acquirer 114 and COF entity server 102 may not possess, see, or otherwise be exposed to the transaction account number during the processing of e-commerce transactions. In instances where the registration was performed without using the transaction account number (e.g., using authentication data), the COF entity server 102 and acquirer 114 may never be exposed to the transaction account number, thereby increasing account security, which may, in turn, decrease the likelihood of an attack on the COF entity server 102.

Using the methods and systems discussed herein, e-commerce transactions may be conducted with payment data stored in a COF entity server 102 with a significantly higher level of security via the use of COF-specific payment tokens. By using payment tokens that are COF entity-specific and validated to the specific COF entity from which the token originates in a transaction, a consumer's transaction account number may be at a significantly lower risk of compromise, as the transaction account number may never be known to any entity or system outside of the payment network 116, validation server 104, and issuer 112. As a result, a consumer 108, COF entity server 102, and acquirer 114 may have a significantly lower chance of being compromised due to the ongoing storage of payment details, while still being provided with the ease and convenience of using stored payment details via the use of stored COF-specific payment tokens.

In some embodiments, a wallet provider 106 may be a token requesting entity. In such embodiments, the wallet provider 106 may be associated with an electronic wallet application program stored on and/or executed by the computing device 110. The electronic wallet program may be configured to store payment details associated with a transaction account for conveyance to a COF entity server 102 for use in funding a payment transaction. In some cases, the computing device 110 may electronically transmit payment details from an electronic wallet application program to the COF entity server 102 using a suitable communication method and network, such as via submission through a web page using the Internet for an e-commerce transaction. In other cases, the computing device 110 may electronically transmit a request to the wallet provider 106, which may in turn electronically transmit payment details to the COF entity server 102. In such an embodiment, the wallet provider 106 may register the transaction account with the validation server 104 and receive a COF-specific payment token and specific TRID or token identifier in return for use in place of the transaction account number.

In some embodiments, a cryptogram may be used for even greater enhancement in the validation of a token requesting entity. In such embodiments, the validation server 104 may generate a key. The key may be a private key in a key pair, or may be another type of key suitable for use in the generation of the cryptogram. The key may be provided to the COF entity server 102 (e.g., or other token requesting entity, as applicable, such as the wallet provider 106). The COF entity server 102 may use the key in conjunction with one or more cryptogram generation algorithms known to the validation server 104 to generate a cryptogram. The generated cryptogram may be included in the transaction message submitted to the payment network 116 and conveyed to the validation server 104 during the processing of the payment transaction. The cryptogram may be stored in an additional data element of the transaction message. In some cases, the data element may be a data element reserved for private use according to the associated standards. A bitmap included in the transaction message may indicate the existence of the token requestor validation cryptogram and the corresponding data element. In some instances, the validation server 104 may independently generate the cryptogram using the same key and cryptogram generation algorithm(s) for validation of the cryptogram provided by the COF entity server 102 for enhanced validation of the COF entity server 102 as an authorized user of the COF-specific payment token. In other instances, the validation server 104 may use a public key corresponding to the private key used by the COF entity server 102 to generate the cryptogram in order to validate the generated cryptogram.

In such embodiments, the validation provided by the validation server 104 in the usage of the COF-specific payment token may be further enhanced. Use of the cryptogram may provide greater assurance of the authenticity of the COF entity server 102 that provides a COF-specific payment token to the payment network 116 for use in a payment transaction. The greater assurance may also provide even greater security to the consumer 108, as it may make the compromising of the payment token even more difficult

COF Entity Server

PIG. 2 illustrates an embodiment of the COF entity server 102 of the system 100. It will be apparent to persons having skill in the relevant art that the embodiment of the COF entity server 102 illustrated in FIG.2 is provided as illustration only and may not be exhaustive to all possible configurations of the COF entity server 102 suitable for performing the functions as discussed herein. For example, the computer system 900 illustrated in FIG. 9 and discussed in more detail below may be a suitable configuration of the COF entity server 102.

Hie COF entity server 102 may include a receiving device 202. The receiving device 202 may be configured to receive data over one or more networks via one or more network protocols. In some embodiments, the receiving device 202 may be configured to receive data over the payment rails, such as using specially configured infrastructure associated with payment networks 116 for the transmission of transaction messages that include sensitive financial data and information. In some instances, the receiving device 202 may also be configured to receive data from computing devices 110, validation servers 104, wallet providers 106, payment networks 116, acquirers 114, and other entities via alternative networks, such as the Internet In some embodiments, the receiving device 202 may be comprised of multiple devices, such as different receiving devices for receiving data over different networks, such as a first receiving device for receiving data over payment rails and a second receiving device for receiving data over the Internet. The receiving device 202 may receive electronically data signals that are transmitted, where data may be superimposed on the data signal and decoded, parsed, read, or otherwise obtained via receipt of me data signal by the receiving device 202. In some instances, the receiving device 202 may include a parsing module for parsing the received data signal to obtain the data superimposed thereon. For example, the receiving device 202 may include a parser program configured to receive and transform the received data signal into usable input for the functions performed by the processing device to carry out the methods and systems described herein.

The receiving device 202 may be configured to receive data signals electronically transmitted by the validation server 104, which may be superimposed with COF-specific payment tokens, specific TRIDs and/or token identifiers,

cryptogram generation keys, etc. The receiving device 202 may also be configured to receive data signals electronically transmitted by computing devices 110 and/or wallet providers 106, such as may be superimposed with a COF-specific payment token (e.g., for use in funding a transaction account) or a transaction account number or other registration data, such as authentication data, such as may be used in a registration process for a COF-specific payment token.

The COF entity server 102 may also include a communication module 204. The communication module 204 may be configured to transmit data between modules, engines, databases, memories, and other components of the COF entity server 102 for use in performing the functions discussed herein. The communication module 204 may be comprised of one or more communication types and utilize various communication methods for communications within a computing device. For example, the communication module 204 may be comprised of a bus, contact pin connectors, wires, etc. In some embodiments, the communication module 204 may also be configured to communicate between internal components of the COF entity server 102 and external components of the COF entity server 102, such as externally connected databases, display devices, input devices, etc., as well as being configured to establish communication channels with outside systems and devices, such as the electronic point of sale device 104. The COF entity server 102 may also include a processing device. The processing device may be configured to perform the functions of the COF entity server 102 discussed herein as will be apparent to persons having skill in the relevant art. In some embodiments, the processing device may include and/or be comprised of a plurality of engines and/or modules specially configured to perform one or more functions of the processing device, such as a querying module 206, validation module 208, generation module 210, transaction processing module 212, etc. As used herein, the term "module" may be software or hardware particularly programmed to receive an input, perform one or more processes using the input, and provide an output. The input, output, and processes performed by various modules will be apparent to one skilled in the art based upon the present disclosure.

The COF entity server 102 may include a memory 216. The memory 216 may be configured to store data for use by the COF entity server 102 in performing the functions discussed herein. The memory 216 may be configured to store data using suitable data formatting methods and schema and may be any suitable type of memory, such as read-only memory, random access memory, etc. The

memory 216 may include, for example, encryption keys and algorithms,

communication protocols and standards, data formatting standards and protocols, program code for modules and application programs of the processing device, and other data that may be suitable for use by the COF entity server 102 in the performance of the functions disclosed herein as will be apparent to persons having skill in the relevant art The memory 216 may also include or be comprised of a relational database that utilizes structured query language for the storage,

identification, modifying, updating, accessing, etc. of structured data sets stored therein.

The memory 216 may be configured to store data suitable for use in performing the functions of the COF entity server 102 discussed herein. The data may include, for example, transaction data for payment transactions being conducted, specific TRIDs and/or token identifiers, and COF-specific payment tokens. In some instances, the memory 216 may only temporarily store a COF-specific payment token, such as in instances where a COF-specific payment token is provided by a wallet provider 106 only for use in a single payment transaction.

The COF entity server 102 may also include a querying module 206. The querying module 206 may be configured to execute queries on databases to identify information. The querying module 206 may receive one or more data values or query strings, and may execute a query string based thereon on an indicated database, such as the memory 216, to identify information stored therein. The querying module 206 may then output the identified information to an appropriate engine or module of the COF entity server 102 as necessary. The querying module 206 may, for example, execute a query on the memory 206 to identify a structured data set For instance, when an e-commerce transaction is initiated by a consumer 108, the querying module 206 may execute a query on the memory 216 to identify a COF-specific payment token and COF token identifier to convey to the acquirer 114 for the transaction. The COF-specific payment token may be identified based on data submitted by the consumer 108, such as account information (e.g., used for authentication, such as a username, password, e-mail address, etc.) and an indicator associated with the COF-specific payment token, such as an identification value (e.g., the last four digits of the COF-specific payment token).

The COF entity server 102 may also include a validation module 208. The validation module 208 may receive data as input, may validate the data, and may then output a result of the validation (e.g., success or failure) to one or more modules or engines of the COF entity server 102 for use thereof. The validation module 208 may be configured, for example, to validate authentication information submitted by a consumer 108 prior to selection and use of a COF-specific payment token. For example, each consumer 108 for whom a COF-specific payment token is registered and stored in or on behalf of the COF entity server 102 may have an account registered with the COF entity server 102. The validation module 208 may validate authentication information provided by the consumer 108 (e.g., via the computing device 110) prior to conveyance of the indicated COF-specific payment token to the acquirer 114, such as to ensure that the consumer 108 attempting to use the COF-specific payment token is an authorized party.

The COF entity server 102 may also include a generation module 210. The generation module 210 may be configured to receive instructions as input, which may include data for use in association with the instructions, may generate data based on the instructions, and may be configured to output the generated data to one or more modules or engines of me COF entity server 102 for use in conjunction with the functions discussed herein. For example, the generation module 210 may be configured to generate data signals superimposed with data for electronic transmission to other entities in the system 100, such as a data message for registration of a transaction account for a COF-specific payment token and a data message for providing transaction data and COF entity-specific data for use in processing a payment transaction. The generation module 210 may also be configured to generate token validation cryptograms. The cryptograms may be generated using a COF entity-specific key issued by the validation module 104 that corresponds to a COF-specific payment token. The generation module 210 may apply one or more cryptogram generation algorithms (e.g., specified by the validation module 104 when issuing the key(s)) to a key to generate a token requestor validation cryptogram, which may be included in the data conveyed to the acquirer 114 for inclusion in a transaction message for the payment transaction.

The COF entity server 102 may also include a transaction processing module 212. The transaction processing module 212 may be configured to perform additional functions of the COF entity server 102 suitable for use in the initiation and processing of e-commerce payment transactions. For example, the transaction processing module 212 may be configured to calculate transaction amounts, apply

taxes to a transaction, calculate fraud scores, display notifications to employees and consumers 108, etc. Additional functions that may be performed by the transaction processing module 212 in conjunction with the initiation and processing of payment transactions will be apparent to persons having skill in the relevant art.

The COF entity server 102 may also include a transmitting device 214.

The transmitting device 214 may be configured to transmit data over one or more networks via one or more network protocols. In some embodiments, the transmitting device 214 may be configured to transmit data over the payment rails, such as using specially configured infrastructure associated with payment networks 116 for the transmission of transaction messages that include sensitive financial data and information, such as identified payment credentials. In some instances, the transmitting device 214 may be configured to transmit data to validation servers 104, wallet providers 106, computing devices 110, acquirers 114, payment networks 116, and other entities via alternative networks, such as the Internet In some

embodiments, the transmitting device 214 may be comprised of multiple devices, such as different transmitting devices for transmitting data over different networks, such as a first transmitting device for transmitting data over the payment rails and a second transmitting device for transmitting data over the Internet. The transmitting device 214 may electronically transmit data signals mat have data superimposed that may be parsed by a receiving computing device. In some instances, me transmitting device 214 may include one or more modules for superimposing, encoding, or otherwise formatting data into data signals suitable for transmission.

The transmitting device 214 may be configured to electronically transmit data signals to the validation server 104, which may be superimposed with registration data. Registration data may include, for example, a transaction account number for a transaction account being registered, authentication data for

authentication of the COF entity server 102 as authorized to register a transaction account; such as username and password combination used by the consumer 108 in association with the transaction account being registered. The transmitting device 214 may also be configured to electronically transmit data signals to acquirers 114, which may be superimposed with data used in the processing of payment transactions, such as transaction data (e.g., transaction amounts, transaction times, transaction dates, etc.) and COF entity-specific data, such as a COF-specific payment token, specific TRID or token identifier, and a COF token requestor validation cryptogram, if applicable.

Validation Server

FIG. 3 illustrates an embodiment of the validation server 104 of the system 100. It will be apparent to persons having skill in the relevant art that the embodiment of the validation server 104 illustrated in FIG. 3 is provided as illustration only and may not be exhaustive to all possible configurations of the validation server 104 suitable for performing the functions as discussed herein. For example, the computer system 900 illustrated in FIG. 9 and discussed in more detail below may be a suitable configuration of the validation server 104.

The validation server 104 may include a receiving device 302. The receiving device 302 may be configured to receive data over one or more networks via one or more network protocols. In some embodiments, the receiving device 302 may be configured to receive data over the payment rails, such as using specially configured infrastructure associated with payment networks 116 for the transmission of transaction messages that include sensitive financial data and information. In some instances, the receiving device 302 may also be configured to receive data from COF entity servers 102, wallet providers 106, computing devices 110, issuers 112, acquirers 114, payment networks 116, and other entities via alternative networks, such as the Internet. In some embodiments, the receiving device 302 may be comprised of multiple devices, such as different receiving devices for receiving data over different networks, such as a first receiving device for receiving data over payment rails and a second receiving device for receiving data over the Internet. The receiving device 302 may receive electronically data signals that are transmitted, where data may be superimposed on the data signal and decoded, parsed, read, or otherwise obtained via receipt of the data signal by the receiving device 302. In some instances, the receiving device 302 may include a parsing module for parsing the received data signal to obtain the data superimposed thereon. For example, the receiving device 302 may include a parser program configured to receive and transform the received data signal into usable input for the functions performed by the processing device to carry out the methods and systems described herein.

The receiving device 302 may be configured to receive data signals electronically transmitted by COF entity servers 102 or wallet providers 106, which may include data suitable for use in the registration of a transaction account by a token requesting entity, such as a transaction account number or authentication data associated with a transaction account. The receiving device 302 may also be configured to receive data signals electronically transmitted by a payment network 116, which may be superimposed with a transaction message or data stored therein, such as COF entity-specific data used in the validation of a token requesting entity.

The validation server 104 may also include a communication module 304. The communication module 304 may be configured to transmit data between modules, engines, databases, memories, and other components of the validation server 104 for use in performing the functions discussed herein. The communication module 304 may be comprised of one or more communication types and utilize various communication methods for communications within a computing device. For example, the communication module 304 may be comprised of a bus, contact pin connectors, wires, etc. In some embodiments, the communication module 304 may also be configured to communicate between internal components of the validation server 104 and external components of the validation server 104, such as externally connected databases, display devices, input devices, etc., as well as being configured to establish communication channels with outside systems and devices, such as the electronic point of sale device 104. The validation server 104 may also include a processing device. The processing device may be configured to perform the functions of the validation server 104 discussed herein as will be apparent to persons having skill in the relevant art. In some embodiments, the processing device may include and/or be comprised of a plurality of engines and/or modules specially configured to perform one or more functions of the processing device, such as a querying module 314, validation module 316, generation module 318, transaction processing module 320, etc. As used herein, the term "module" may be software or hardware particularly programmed to receive an input, perform one or more processes using the input, and provide an output. The input, output, and processes performed by various modules will be apparent to one skilled in the art based upon the present disclosure.

The validation server 104 may include a memory 316. The memory 316 may be configured to store data for use by the validation server 104 in performing the functions discussed herein. The memory 316 may be configured to store data

using suitable data formatting methods and schema and may be any suitable type of memory, such as read-only memory, random access memory, etc. The memory 316 may include, for example, encryption keys and algorithms, communication protocols and standards, data formatting standards and protocols, program code for modules and application programs of the processing device, and other data that may be suitable for use by the validation server 104 in the performance of the functions disclosed herein as will be apparent to persons having skill in the relevant art. The memory 316 may also include or be comprised of a relational database that utilizes structured query language for the storage, identification, modifying, updating, accessing, etc. of structured data sets stored therein.

The validation server 104 may also include a requestor database 306. The requestor database 306 may be configured to store a plurality of requestor profiles 308 using a suitable data storage format and schema. The requestor database 306 may be a relational database that utilizes structured query language for the storage, identification, modifying, updating, accessing, etc. of structured data sets stored therein. Each requestor profile 308 may be a structured data set configured to store data associated with a token requesting entity. Each requestor profile 308 may include a COF-specific payment token and an associated specific TRID or token identifier. In some instances, a single specific TRID may be associated with multiple COF-specific payment tokens. In some embodiments, a requestor profile 308 may also include a key distributed to the associated token requesting entity for use in generating token requestor validation cryptograms.

The validation server 104 may also include a token database 310. The token database 310 may be configured to store a plurality of token profiles 312 using a suitable data storage format and schema. The token database 310 may be a relational database that utilizes structured query language for the storage,

identification, modifying, updating, accessing, etc. of structured data sets stored therein. Each token profile 312 may be a structured data set configured to store data associated with an issued COF-specific payment token. Specifically, a token profile 312 may include a COF-specific payment token and the associated transaction account number. In some embodiments, token profiles 312 may be stored in the corresponding requestor profiles 308, such as in a requestor profile 308 that includes or is otherwise associated with the COF-specific payment token included in the token profile 312.

The validation server 104 may also include a querying module 314. The querying module 314 may be configured to execute queries on databases to identify information. The querying module 314 may receive one or more data values or query strings, and may execute a query string based thereon on an indicated database, such as the memory 316, to identify information stored merein. The querying module 314 may then output the identified information to an appropriate engine or module of the validation server 104 as necessary. The querying module 314 may, for example, execute a query on the requestor database 306 to identify a requestor profile 308 mat includes a COF-specific payment token received by the receiving device 302, such as from the payment network 116. The querying module 314 may also execute queries on the token database 310 to identify specific token profiles 312, or on any database in the validation server 104 to perform database management functions, such as for the storage, modification, editing, etc. of structured data sets stored therein.

The validation server 104 may also include a validation module 316.

The validation module 316 may receive data as input, may validate the data, and may then output a result of the validation (e.g., success or failure) to one or moire modules or engines of the validation server 104 for use thereof. The validation module 316 may be configured, for example, to validate authentication information submitted by a COF entity server 102 in authenticating the COF entity server 102 as authorized access to a transaction account with an issuer 112, for registration of the transaction account with a COF-specific payment token. The validation module 316 may also be configured to validate COF entity-specific data received in conjunction with a payment transaction. For example, the validation module 316 may validate that a specific TRID or token identifier received in a payment transaction (e.g., stored in a corresponding data element included in a submitted transaction message) is correctly associated with a COF-specific payment token also received in the payment transaction. In instances where a token requestor validation cryptogram may be used, the validation module 316 may also be configured to validate that the cryptogram received in the payment transaction, such as by comparison to an independently generated cryptogram or validation using a public key corresponding to a private key used in the generation of the cryptogram.

WHAT IS CLAIMED:
1. A method for enhanced validation of an entity associated with a Card-On-File (COF) token, comprising:
storing, in a memory of a processing server, at least transaction data, a token requester identifier (TRID), and a COF token identifier;

receiving, by a receiving device of the processing server, payment credentials, wherein the payment credentials include at least a COF-specific payment token; generating, by a generation module of the processing server, a transaction message, wherein the transaction message is formatted based on one or more standards and includes at least a plurality of data elements including at least a first data element configured to store the COF-specific payment token, a second data element configured to store the COF token identifier, a third data element configured to store the TRID, and one or more additional data elements configured to store the transaction data; and

electronically transmitting, by a transmitting device of the processing server, the generated transaction message to a financial institution via a payment network.

2. The method of claim 1, further comprising:

generating, by the generation module of the processing server, a COF entity validation cryptogram based on application of one or more algorithms to data associated with the COF token identifier, wherein

the generated transaction message further includes a fourth data element configured to store the generated COF entity validation cryptogram.

3. The method of claim 2, further comprising:

storing, in the memory of the processing server, a key corresponding to a key pair, wherein

the key is associated with the COF token identifier and is used in generating the COF entity validation cryptogram.

4. The method of claim 2, wherein the fourth data element is reserved for private use in the one or more standards.

5. The method of claim 1 , wherein the generated transaction message further includes a fifth data element configured to store an indicator indicating that the generated transaction message is related to an e-commerce transaction.

6. A method for enhanced validation of an entity associated with a Card- On-File (COF) token, comprising:

storing, in a COF entity database of a processing server, a plurality of COF entity profiles, wherein each COF entity profile includes a structured data set related to an entity associated with a COF token including at least a COF token identifier and at least one token requester identifier (TRID) and/or COF-specific payment token; storing, in a token database of the processing server, a plurality of token profiles, wherein each token profile includes a structured data set related to a COF-specific payment token including at least the related COF-specific payment token and a transaction account number;

receiving, by a receiving device of the processing server, a transaction message, wherein the transaction message is formatted based on one or more standards and includes a plurality of data elements including at least a first data element configured to store a specific payment token, a second data element configured to store a specific COF token identifier, a third data element configured to store a specific TRID, and one or more additional data elements configured to store transaction data;

executing, by a querying module of the processing server, a query on the COF entity database to identify a specific COF entity profile where the included COF token identifier corresponds to the specific COF token identifier stored in the second data element included in the received transaction message;

executing, by the querying module of the processing server, a query on the token database to identify a specific token profile where the included payment token corresponds to the specific COF-specific payment token stored in the first data element included in the received transaction message;

validating, by a validation module of the processing server, the entity related to the identified specific COF entity profile as genuine based on a correspondence between an included TRID and the specific TRID stored in the third data element included in the received transaction message or an included COF-specific payment

token and the specific COF-specific payment token stored in the first data element included in the received transaction message;

modifying, by a generation module of the processing server, the received transaction message by replacing the specific payment token stored in the first data element with the transaction account number stored in the identified specific token profile; and

electronically transmitting, by a transmitting device of the processing server, the modified transaction message to a financial institution via a payment network.

7. The method of claim 6, further comprising:

generating, by the generation module of the processing server, a COF entity validation cryptogram based on application of one or more algorithms to data associated with the specific COF token identifier, wherein

the received transaction message further includes a fourth data element configured to store a supplied COF entity validation cryptogram, and

validation of the entity related to the identified specific COF entity profile as genuine further includes validating the supplied COF entity validation cryptogram based on the generated COF entity validation cryptogram.

8. The method of claim 7, further comprising:

storing, in the specific COF entity profile, a key corresponding to a key pair, wherein

the key is associated whh the specific COF token identifier and is used in generating the COF entity validation cryptogram.

9. The method of claim 7, wherein the fourth data element is reserved for private use in the one or more standards.

10. The method of claim 6, wherein the generated transaction message further includes a fifth data element configured to store an indicator indicating that the generated transaction message is related to an e-commerce transaction.

11. A system for enhanced validation of an entity associated with a Card-On-File (COF) token, comprising:

a memory of a processing server configured to store at least transaction data, a token requester identifier (TRID), and a COF token identifier;

a receiving device of the processing server configured to receive payment credentials, wherein the payment credentials include at least a payment token;

a generation module of the processing server configured to generate a transaction message, wherein the transaction message is formatted based on one or more standards and includes at least a plurality of data elements including at least a first data element configured to store the payment token, a second data element configured to store the COF token identifier, a third data element configured to store the TRID, and one or more additional data elements configured to store the transaction data; and

a transmitting device of the processing server configured to electronically transmit the generated transaction message to a financial institution via a payment network.

12. The system of claim 11, wherein

the generation module of the processing server is further configured to generate a COF entity validation cryptogram based on application of one or more algorithms to data associated with the COF token identifier, and

the generated transaction message further includes a fourth data element configured to store the generated COF entity validation cryptogram.

13. The system of claim 12, wherein

the memory of the processing server is further configured to store a key corresponding to a key pair, and

the key is associated with the COF token identifier and is used in generating the COF entity validation cryptogram.

14. The system of claim 12, wherein the fourth data element is reserved for private use in the one or more standards.

15. The system of claim 11, wherein the generated transaction message further includes a fifth data element configured to store an indicator indicating that the generated transaction message is related to an e-commerce transaction,

16. A system for enhanced validation of an entity associated with a Card-On-File (COF) token, comprising:

a COF entity database of a processing server configured to store a plurality of COF entity profiles, wherein each COF entity profile includes a structured data set related to an entity associated with a COF token including at least a COF token identifier and at least one token requester identifier (TRID) and/or payment token; a token database of the processing server configured store a plurality of token profiles, wherein each token profile includes a structured data set related to a payment token including at least the related payment token and a transaction account number, a receiving device of the processing server configured to receive a transaction message, wherein the transaction message is formatted based on one or more standards and includes a plurality of data elements including at least a first data element configured to store a specific payment token, a second data element configured to store a specific COF token identifier, a third data element configured to store a specific TRID, and one or more additional data elements configured to store transaction data;

a querying module of the processing server configured to

execute a query on the COF entity database to identify a specific COF entity profile where the included COF token identifier corresponds to the specific COF token identifier stored in the second data element included in the received transaction message, and

execute a query on the token database to identify a specific token profile where the included payment token corresponds to the specific payment token stored in the first data element included in the received transaction message;

a validation module of the processing server configured to validate the entity related to the identified specific COF entity profile as genuine based on a

correspondence between an included TRID and the specific TRID stored in the third data element included in the received transaction message or an included payment token and the specific payment token stored in the first data element included in the received transaction message;

a generation module of the processing server configured to modify the received transaction message by replacing the specific payment token stored in the first data element with the transaction account number stored in the identified specific token profile; and

a transmitting device of the processing server configured to electronically transmit the modified transaction message to a financial institution via a payment network.

17. The system of claim 16, wherein

the generation module of the processing server is further configured to generate a COF entity validation cryptogram based on application of one or more algorithms to data associated with the specific COF token identifier,

the received transaction message further includes a fourth data element configured to store a supplied COF entity validation cryptogram, and

validation of the entity related to the identified specific COF entity profile as genuine further includes validating the supplied COF entity validation cryptogram based on the generated COF entity validation cryptogram.

18. The system of claim 17, wherein

the specific COF entity profile further includes a key corresponding to a key pair, and

the key is associated with the specific COF token identifier and is used in generating the COF entity validation cryptogram.

19. The system of claim 17, wherein the fourth data element is reserved for private use in the one or more standards.

20. The system of claim 16, wherein the generated transaction message further includes a fifth data element configured to store an indicator indicating that the generated transaction message is related to an e-commerce transaction.