Patent Grant
10552834
The payments industry is evolving to support payment form factors that provide increased protection against counterfeit, account misuse, and other forms of fraud. While chip cards can provide substantial protection for card-present transactions, a similar need exists for further protections for card-not-present and hybrid transaction environments to minimize unauthorized use of account holder data and to prevent cross-channel fraud. Tokenization systems hold substantial promise to address these needs.
In a traditional electronic payment transaction, a consumer's primary account number (PAN) information is exposed to various entities involved during the transaction lifecycle. The PAN is passed from a merchant terminal, to an acquirer system, a payment processing network, payment gateways, etc.
Because the PAN can be exposed at various points in the transaction lifecycle, payment “tokens” have been developed to conduct payment transactions. A payment token serves as an additional security layer to the PAN and in effect becomes a proxy/surrogate to the PAN. Thus, the payment token may be used in place of PAN while initiating payment or submitting transactions. The use of payment tokens instead of PANs can reduce the risk of fraudulent activity since the real PAN is not exposed.
However, in the conventional tokenization systems, the issuer is not able to perform consumer authentication before the financial transaction begins. Consumer authentication is the process of verifying a consumer's ownership of an account. Accordingly, the issuer only confirms that the payment account provided to the issuer in a transaction request message can be used to conduct the transaction. The issuer is unable to confirm that the account is being used by the rightful owner or assignee. Thus, it is desirable to authenticate the consumer in a transaction (e.g. a tokenized transaction) before the transaction is authorized. This will benefit all payment system participants including consumers, merchants, and financial institutions. Authenticating consumers will reduce the levels of fraud, disputes, retrievals, and chargebacks, which subsequently will reduce the costs associated with each of these events.
Moreover, for tokenized transactions, the token(s) can be provided by a plurality of token service providers. Thus, it is desirable for an authentication entity performing consumer authentication to be able to work with a plurality of token service providers.
Embodiments of the invention address these and other problems, individually and collectively.
Embodiments of the invention are directed to systems and methods related to performing consumer authentication in a tokenized transaction. According to various embodiments, the token in an authentication request message may be resolved to corresponding credentials before the consumer authentication process is initiated. In an exemplary embodiment, a consumer may provide a token to a merchant computer to conduct a transaction with the merchant using a user device. As part of an authentication system, the merchant computer may include a merchant plug-in module as a proxy between the merchant computer and an issuer access control server or other components within the system. The merchant plug-in module may communicate with the issuer access control server by sending verification and authentication messages to the issuer access control server via a directory server. It may be desirable to resolve the token before the authentication request reaches the issuer access computer for authentication. According to various embodiments, the merchant plug-in module, the directory server or a token router coupled to the issuer access control server may each be in communication with one or more token service providers to de-tokenize the token provided by the consumer or the consumer's user device.
In one embodiment, the present invention is directed to a method including receiving, by a first server computer transaction data. The first server computer may be a merchant plug-in module at a merchant computer, a directory server or a token router module coupled to (or integrated with) the issuer access control server. The method further includes determining, by the first server computer, that the transaction data includes a token and identifying, by the first server computer, a token service provider among a plurality of token service providers. The method also includes sending, by the first server computer, the token to the token service provider and receiving, by the first server computer, credentials associated with the token from the token service provider. The method includes forwarding, by the first server computer, the credentials to a second server computer for authentication. The second server computer may be the issuer access control server. The method also includes receiving, by the first server computer, the credentials and an authentication value from the second server computer upon the second server computer authenticating the credentials. For example, the authentication value may include cardholder authentication verification value. The authentication value is incorporated into a transaction authorization request message. In some embodiments, the first server computer may send the token and the authentication value to a third server computer for initiating a transaction authorization request using the token and the authentication value. For example, the third server computer may include a merchant server computer. The third server computer may generate the transaction authorization request message incorporating the token and the authentication value. In various embodiments, the transaction authorization request message may be de-tokenized using the token service provider and sent to an authorization computer for transaction authorization. The authorization computer may include an issuer computer.
In another embodiment, the present invention is directed to a server computer comprising a processor and a computer readable medium coupled to the processor, the computer readable medium comprising instructions for causing the processor to receive transaction data and determine that the transaction data includes a token. The computer readable medium further comprises instructions for causing the processor to identify a token service provider among a plurality of token service providers. The computer readable medium further comprises instructions for causing the processor to send the token to the token service provider and receive credentials associated with the token from the token service provider. The computer readable medium further comprises instructions for causing the processor to forward the credentials to a second server computer for authentication. The computer readable medium also comprises instructions for causing the processor to receive the credentials and an authentication value from the second server computer upon the second server computer authenticating the credentials, wherein the authentication value is incorporated into a transaction authorization request message.
In another embodiment, the present invention is directed to a system comprising a first server computer comprising a first processor and a first computer readable medium coupled to the first processor, and a second server computer comprising a second processor and a second computer readable medium coupled to the second processor. The first computer readable medium comprising instructions for causing the first processor to receive transaction data; determine that the transaction data includes a token; identify a token service provider among a plurality of token service providers; send the token to a token service provider; and receive credentials associated with the token from the token service provider. The second computer readable medium comprising instructions for causing the second processor to receive the credentials directly or indirectly from the first server computer for authentication; authenticate the credentials; generate an authentication value upon authenticating the credentials; and send the credentials and the authentication value to the first server computer. The credentials and the authentication value are incorporated into a modified transaction authorization request message.
In yet another embodiment, the present invention is directed to a method comprising receiving, by a first server computer transaction data. The first server computer may include a merchant plug-in module at a merchant computer, a directory server or a token router module coupled to (or integrated with) an issuer access control server. The method includes determining, by the first server, that the transaction data includes a token and identifying, by the first server computer, a token service provider among a plurality of token service providers. The method further includes sending, by the first server, the token to a token service provider; and receiving, by the first server, credentials associated with the token from the token service provider. The method also includes receiving, by a second server computer the credentials directly or indirectly from the first server computer for authentication. The second server computer may include the issuer access control server. The method further includes authenticating, by the second server computer, the credentials; and generating, by the second server computer, an authentication value upon authenticating the credentials. The method also includes sending, by the second server computer, the credentials and the authentication value to the first server computer, wherein the credentials and the authentication value are incorporated into a transaction authorization request message.
These and other embodiments of the invention are described in further detail below. Other objects and advantages of the present invention will be apparent to one of ordinary skill in the art upon review of the detailed description of the present invention and the included figures.
Embodiments of the present invention are directed to systems and methods related to performing consumer authentication in a tokenized transaction. According to various embodiments, the token in an authentication request may be resolved to corresponding credentials (e.g. a unique primary account number) before the consumer authentication process is initiated. In an exemplary embodiment, a consumer may provide a token to a merchant computer to conduct a transaction with the merchant using a user device. As part of an authentication system, in some embodiments, the merchant computer may include a merchant plug-in module as a proxy between the merchant computer and an issuer access control server or other components within the system. The merchant plug-in module may communicate with the issuer access control server by sending verification, enrollment request and authentication messages to the issuer access control server via a directory server. It may be desirable to resolve the token before the authentication request reaches the issuer access computer for authentication. According to various embodiments, the merchant plug-in module, the directory server or a token router coupled to (or integrated with) the issuer access control server may each be in communication with one or more token service providers to de-tokenize the token provided by the consumer or the consumer's user device.
Upon the consumer initiating a transaction request with the merchant, the merchant computer may generate an authentication request to authenticate the user. The authentication request may include transaction data provided by the consumer when a user device is presented/used for the transaction with the merchant. The transaction data may include a token, an account number (e.g. a primary account number (PAN)), user name, user billing address, etc. The merchant may forward the authentication request message to other servers in the system. Upon receipt of the authentication request message, the merchant plug-in module, the directory server or a token router may determine whether the authentication request message includes a token. If the authentication request message includes a token, the merchant plug-in module, the directory server or the token router may determine a token service provider among a plurality of token service providers that issued and/or manages the token in the authentication request message. The merchant plug-in module, the directory server or the token router may interact with the identified token service provider to de-tokenize the token (i.e. to resolve the token to the corresponding credentials, such as an account number). The authentication request message may be modified by the merchant plug-in module, the directory server or the token router before being forwarded to the issuer access server computer. The issuer access server computer may perform consumer authentication using the data in the authentication request message and may generate an authentication response message indicating whether the consumer is authenticated.
The authentication response message may be forwarded from the issuer access control server to the merchant computer after being routed through one or more of the merchant plug-in module, the directory server and the token router. According to various embodiments, before sending the authentication response message to the merchant computer, the merchant plug-in module, the directory server or the token router may re-tokenize the credentials (e.g. the account number) provided in the authentication response message using the identified token service provider. Upon receipt of the authentication response message, the merchant computer may initiate a transaction request message to perform the transaction requested by now-authenticated consumer.
Before discussing specific embodiments and examples, some descriptions of terms used herein are provided below.
A “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 token may include a series of numeric and/or 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 token may be “format preserving” and may have a numeric format that conforms to the account identifiers used in existing payment processing networks (e.g., ISO 8583 financial transaction message format). In some embodiments, a 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 token value 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.
A “token service provider” may refer to an entity including one or more server computers that generates, processes and maintains tokens. The token service provider may include or be in communication with a token vault where the generated tokens are stored. Specifically, the token vault may maintain one-to-one mapping between a token and a primary account number (PAN) represented by the token.
A “token vault” may refer to a repository that maintains established token-to-PAN mappings. According to various embodiments, the token vault may also maintain other attributes of a token requestor that may be determined at the time of registration and that may be used by the token service provider to apply domain restrictions or other controls during transaction processing. In some embodiments, the token vault may be provided as a part of the token service provider. Alternatively, the token vault may be a remote repository accessible by the token service provider. The token vault, due to the sensitive nature of the data mappings that are stored and managed in it, may be protected by strong underlying physical and logical security.
“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 which may be replaced with a substitute value (i.e., token). Tokenization may be used to enhance transaction efficiency, improve transaction security, increase service transparency, or to provide a method for third-party enablement.
“Token exchange” or “de-tokenization” is a process of restoring the data that was substituted during tokenization. For example, a token exchange may include replacing a payment token with a corresponding primary account number (PAN) that was associated with the payment token during tokenization of the PAN. Thus, the de-tokenization may refer to the process of redeeming a token for the associated PAN value based on a token-to-PAN mapping stored, for example, in a token vault. The ability to retrieve a PAN in exchange for the associated token may be restricted to specifically authorized entities, individuals, applications, or systems. Further, de-tokenization or token exchange may be applied to any other information. In some embodiments, token exchange may be achieved via a transactional message, such as an ISO message, an application programming interface (API), or another type of web interface (e.g., web request).
A “merchant computer” or “merchant server computer” may refer to one or more computer servers used by a merchant to conduct payment transactions. For example, the merchant computer may be used to provide an online storefront for consumers to shop and also to conduct online transactions with consumers once the consumers have decided to purchase goods from the merchant. The merchant computer may include or may be in communication with an access device.
An “access device” may be any suitable device for accessing a remote computer. In some embodiments of the invention, an access device may communicate with a merchant computer or a payment processing network, and may interact with a portable device, a user computer apparatus, and/or a user mobile device. 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 point of sale (POS) devices, 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, Websites, and the like. An access device may use any suitable contact or contactless mode of operation to send or receive data from, or associated with, a portable 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 portable device.
A “merchant plug-in” (or “MPI”) may refer to a proxy provided between the merchant computer and other computer servers in a payment system. For example, the merchant plug-in may be a component that performs various authentication functions on behalf of the merchant. The merchant plug-in may be embodied by suitable hardware and/or software that are accessible to a merchant. For example, the merchant plug-in may be software running on the merchant server or it may be a component run on a different server accessible by the merchant. The merchant plug-in may be able to perform functions such as determining whether authentication is available for a card number, validating a digital signature in an authentication message, tokenization of payment data, detokenization of tokens, and other functions.
An “access control server” (or “ACS”) may refer to a server computer that provides issuers, or other entities capable of authenticating a consumer conducting an online transaction, with the ability to authenticate consumers during a transaction. An access control server performs the requested authentication services and provides digitally signed responses to entities requesting authentication. An access control server may be shared by multiple parties. Alternatively, a party may have multiple access control servers, each associated with a different subset of the consumers.
A “directory server” may refer to a server computer that can be used to route messages in a payment system. The messages routed by the directory server may contain enrolment and authentication information between a merchant plug-in (MPI) and issuer access control server. The directory server can also determine whether a consumer can utilize the authentication services. In some embodiments, the directory server can be operated by a service organization such as Visa. According to various embodiments, the directory server may tokenize payment data or may detokenize tokens.
A “user device” may refer to any device that may be used to conduct a financial transaction, such as to provide payment information to a merchant. A user device may be in any suitable form. For example, suitable user devices may be hand-held and compact so that they can fit into a consumer's wallet and/or pocket (e.g., pocket-sized). They may include smart cards, magnetic stripe cards, keychain devices (such as the Speedpass™ commercially available from Exxon-Mobil Corp.), etc. Other examples of user devices include cellular phones, personal digital assistants (PDAs), pagers, payment cards, security cards, access cards, smart media, transponders, 2-D barcodes, an electronic or digital wallet, wearable devices such as smart watches, fitness bands, ankle bracelets, rings, earrings, and the like. If the user device is in the form of a debit, credit, or smartcard, the user device may also optionally have features such as magnetic stripes. Such devices can operate in either a contact or contactless mode. In some embodiments, the user device may include a mobile device comprising any electronic device that may be transported and 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. Examples of mobile devices include mobile phones (e.g. cellular phones), PDAs, tablet computers, net books, laptop computers, personal music players, hand-held specialized readers, etc. In some embodiments, the user device may include a stand-alone computer for conducting e-commerce transactions. Yet it other embodiments, the user device may include a vehicle, such as a car or a motorcycle having a processor and a memory storing payment information of the user.
An “authorization computer” may be a computer that is programmed to determine whether or not transactions can be authorized. An authorization computer may be programmed to perform various checks including fraud checks, account balance checks, etc.
An “issuer” may typically refer to a business entity (e.g., a bank) that maintains financial accounts for a user and often issues a credit or debit card to the user. An issuer can include a payment account issuer. The issuer may be responsible to make a credit limit available to account holders and may also be responsible for sending payments to merchants for purchases made with payment accounts issued by the issuer. The issuer may authorize a requested load amount to be uploaded to a user device. The issuer may operate an “authorization computer” to perform the foregoing actions.
A “payment account” or a “financial account” (which may be associated with one or more portable devices) may include any suitable payment account including a credit card account, a checking account, a savings account, a merchant account assigned to a accountholder, or a prepaid account.
A “server computer” or a “server” can be a powerful computer or a 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.
A “payment processor” may refer to an electronic payment system used to accept, transmit, or process transactions made by user devices for money, goods, or services. The payment processor may transfer information and funds among issuers, acquirers, merchants, and user device users.
A “transaction authorization request message” may be an electronic message that is transmitted to an authorization computer and requests authorization for a transaction. In some embodiments, a transaction authorization request message is sent to a payment processing network and/or an issuer (i.e., an issuer computer) of a payment account to request authorization for a payment transaction. A transaction 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 consumer using a user device or a payment account.
A “transaction authorization response message” may be an electronic message reply to a transaction authorization request message. It may be generated by an issuing financial institution (i.e. using an issuer computer) or a payment processing network. The transaction authorization response message may include an authorization code, which may be a code that an account issuing bank returns in response to an transaction request message in an electronic message (either directly or through the payment processing network) to the merchant's access device (e.g. POS terminal) that indicates approval of the transaction. The code may serve as proof of authorization. In some embodiments, the transaction authorization response message may include a script that, when received at the acquirer device, may cause/enable the acquirer device to load a required load amount on to the portable device. In other embodiments, the transaction authorization response message may include a script that can be used by a processor of the portable device to load a required load amount on to memory chip of the portable device.
An “authentication request message” may be an electronic message that is transmitted to an authentication server such as an issuer access control server (ACS) and requests authentication for a consumer. The data sent in the authentication request message may include consumer computing device data (e.g., operating system data, browser data, mobile application data, geo-location data), consumer data (e.g., user name, user address data, user email address, user phone number), and transaction data (e.g., shopping cart data, user device data, payment account number, token), and/or other comparable data. In some embodiments, while some elements in the authentication request message are tokenized, the other elements may be in plain text (e.g. not tokenized).
An “authentication response message” may be an electronic message reply to an authentication request message. It may be generated by an authentication computer at an issuing financial institution (i.e. using an issuer access control server (ACS)). The authentication response message may include an authentication value, which may be a code that an account issuing bank returns in response to an authentication request message in an electronic message (either directly or through a directory server) to the merchant computer or merchant plug-in (MPI) that indicates authentication of the consumer (i.e. whether the consumer is the rightful owner or assignee of the payment account identified in the authentication request message). The code may serve as proof of authentication. Alternatively, the authentication response message can include data indicating that the authentication process failed. In some embodiments, the authentication response message may include an error code identifying the reason for failure of the authentication process.
Embodiments of the present invention may be used to provide tokenization capability in a consumer authentication process. Embodiments may receive an account number from a user device at a merchant computer, initiate a consumer authentication process, subsequently tokenize the account number and return an authentication value along with the token to the merchant computer. Alternatively, embodiments may receive a token from a user device at a merchant computer, detokenize the token to obtain the account number represented by the token, initiate a consumer authentication process, subsequently re-tokenize the account number and return the authentication value along with the token to the merchant computer. The detokenization and/or the re-tokenization may be done by a merchant plug-in (MPI), a directory server or a token router coupled to an issuer access control server (ACS). The MPI, the directory server and the token router may communicate with a plurality of token service providers to detokenize the tokens provided in authentication request messages or to re-tokenize the credentials provided in authentication response messages.
The consumer user device 202 may be associated with a consumer. The consumer (e.g. user) may be any individual or business using the consumer user device 202 to conduct a transaction with a merchant. The consumer user device 202 may be configured to send transaction data as part of a transaction. The transaction data may include computing device data, user device data, geolocation data, consumer address, consumer email address, consumer phone number, transaction amount, account data (e.g. account number or token), merchant data, or other comparable data. In some embodiments, the consumer user device 202 may provide the transaction data upon request from another entity, such as the merchant computer 204. For example, the transaction data may be obtained via a shopping cart for a merchant. In some embodiments, the consumer user device 202 may be configured to send the transaction data automatically as part of conducting a transaction.
The merchant computer 204 may include any suitable computational apparatus operated by a merchant. Examples of merchant computers 204 may include an access device or an Internet merchant computer. In some embodiments, the merchant computer 204 may include a web server computer that may host a plurality of websites that are established for one or more countries. In some embodiments, the merchant computer 204 may be configured to send data as part of a payment verification and authentication process for a transaction between the consumer and the merchant. The merchant computer 204 may also be configured to generate authentication request messages for transactions between the merchant and consumer, and route the authentication request messages to an issuer access control server 218 for additional transaction processing. The authentication request messages sent by the merchant computer 204 may be sent by the merchant plug-in module 206.
The merchant plug-in (MPI) module 206 may be a proxy between the merchant computer 204 and the issuer access control server 218 or other components within the system 200 (e.g. the directory server 216). The merchant plug-in module 206 may be in communication with a tokenization environment 208 including a plurality of token service providers, such as a first token service provider 210, a second token service provider 212 and a third token service provider 214. When the merchant plug-in module 206 determines that the data received from the consumer user device 202 or the authentication request message generated by the merchant computer 204 includes a token, the merchant plug-in module 206 may identify the token service provider among the plurality of token service providers as the issuer/manager of the token. The merchant plug-in module 206 may interact with the identified token service provider to detokenize the token, i.e. to retrieve credentials (e.g. the account number) corresponding to the token. The merchant plug-in module 206 may then modify the authentication request message generated by the merchant computer 204 to replace the token with the retrieved credentials.
The merchant plug-in module 206 may communicate with the issuer access control server 218 by sending the modified authentication message to the issuer access control server 218 via the directory server 216.
The directory server 216 may be a server computer configured to route messages from the merchant plug-in module 206 to the issuer access control server computer 218, as well as messages back from the issuer access control server 218 to the merchant plug-in module 206. In other embodiments, the directory server 216 may route authentication request and response messages between the merchant computer 204 and the issuer access control server 218 as part of a transaction. In some embodiments, the directory server computer 216 may be operated by a payment processing network.
The issuer access control server 218 may comprise a server computer that may be configured to conduct authentication and authorization processes. The issuer access control server 218 may be associated with an issuer, which can be any bank that issues and maintains a financial account for the consumer. The issuer access control server 218 may validate (or authenticate) the PAN or an account associated with the consumer. The issuer access control server 218 may use the PAN, computing device data, user device data, geolocation data, consumer data, transaction data, account data, or other comparable data, in order to authenticate the consumer and PAN. When the issuer access control server 218 performs user authentication, the issuer access control server 218 may provide a digitally signed authentication response message to the merchant computer 204 through the directory server 216. In other embodiments, the issuer access control server 218 may send the authentication response message back to a consumer user device 202 directly. The authentication response message may include at least the credentials and an authentication value, such as a cardholder/consumer authentication verification value (CAVV), indicating the authentication results.
In some embodiments, the issuer access control server 218 may communicate with an authentication history server. The authentication history server may be a database connected to the issuer access control server 218 that can be accessed as part of the authentication process. For example, the authentication history server may store user authentication data associated with user device or primary account numbers (“PAN”). The authentication history server may further store computing device authentication for consumers enrolled in account authentication services. The issuer access control server 218 may query the authentication history server to access and use the previously performed authentication results.
In some embodiments, the issuer access control server 218 may conduct a risk analysis based on the data received from the consumer user device 202. As noted above, the data may include computing device data, user device data, geolocation data, consumer data, transaction data, account data, or other comparable data. The issuer access control server 218 may use this data to determine a risk associated with the user device 202 or payment account that is being used for the transaction. The issuer access control server 218 may query third party sources in order to retrieve additional data for performing the risk analysis. In other embodiments, the third party sources may conduct the risk analysis and send the risk analysis to the issuer access control server 218.
The authentication response message generated by the issuer access control server 218 may be based on the risk analysis conducted by the issuer access control server 218. The authentication response message may provide an indication to the merchant computer 204 that the consumer has been authenticated, not authenticated, or that authentication processes should be “stepped up” (e.g., the issuer access control server 218 is not sure whether the rightful consumer is conducting the transaction). In such cases, the issuer access control server 218 may suggest that further authentication processes should be performed.
The issuer access control server 218 may have pre-defined or user-defined risk thresholds. When the risk level is below the risk threshold, the issuer access control server 218 may provide an indication that the consumer and user device are authenticated and that the transaction may proceed. When the risk level is above the risk thresholds, the issuer access control server 218 may provide an indication that the consumer and user device are not authenticated and that the transaction should not proceed. In other embodiments, the issuer access control server 218 may determine that it has insufficient data to make a decision and may indicate that stepped-up authentication processes should be conducted (e.g., challenge question or password request). In such embodiments, the stepped-up authentication may be performed by the issuer access control server 218, or by another entity, such as the merchant computer 204.
The authentication response message generated by the issuer access server computer 218 may be sent to the merchant plug-in module 206 via the directory server 216. The authentication response message may include the credentials retrieved by the merchant plug-in module 206 from the identified token service provider. Before forwarding the authentication response message to the merchant computer 204, the merchant plug-in module 206 may communicate with the identified token service provider to re-tokenize the credentials, e.g. the merchant plug-in module 206 may send the account number to the token service provider and obtain the token corresponding to the account number. In some embodiments, the merchant plug-in module 206 may store the token and/or the mapping between the token and the credentials. In such embodiments, the merchant plug-in module 206 may re-tokenize the credentials without communicating with the token service provider. The merchant plug-in module 206 may then modify the authentication response message to replace the credentials with the token. The modified authentication response message may include, at least, the token and the authentication value.
If the authentication response message indicates that the consumer has been authenticated by the issuer's access control server 218, the merchant computer 204 may start the transaction by generating a transaction request message. The transaction request message may include a token along with other transaction and/or consumer identifying data. The transaction request message may be for conducting a payment transaction using the primary account number represented by the token included in the transaction request message. The merchant computer 204 may route the transaction request message to an issuer authorization computer 224 for additional transaction processing. The merchant computer 204 may send the transaction request message to an acquirer computer 220, which then forwards the transaction request message to a financial switch 222. The financial switch 222 may be a payment processor (e.g. a payment processing network). The acquirer 202 or the financial switch 222 may identify the token service provider that issued and/or manages the token. The acquirer 202 or the financial switch 222 may then interact with the identified token provider to detokenize the token (i.e. send the token to the token service provider and receive the account number represented by the token). The acquirer 202 or the financial switch 222 may modify the transaction request message to replace the token with the corresponding account number. The modified transaction request message may be sent to an issuer authorization computer 224 for authorization.
The issuer authorization computer 224 may authorize or deny the transaction. The issuer authorization computer 224 may generate a transaction response message indicating whether the transaction is authorized or denied. The issuer authorization computer 224 may send the transaction response message to the merchant computer 204 via the financial switch 222 and the acquirer 220. The transaction response message may include at least the account number and an indicator indicating whether the transaction has been authorized or denied. The financial switch 222 or the acquirer 220 may re-tokenize the account number (i.e. send the account number to the token service provider and receive the token representing the account number). The acquirer 202 or the financial switch 222 may modify the transaction request message to replace the account number with the received token before forwarding the transaction response message to the merchant computer 204.
According to various embodiments, the directory server 216 and the financial switch 222 may be the same entity or may be managed by the same entity, such as a payment processing network. In some embodiments, the issuer's access server computer 218 and the issuer authorization computer 224 may be same device or may be part of a same cluster of computers.
At step 251, the consumer provides data, such as transaction data, identification data, payment data, and the like to the merchant device 204 using the user device 202. The data may include a token representing an account number issued to the consumer by an issuer of consumer's payment account. The merchant computer 204 may generate an authentication request message to be forwarded to an issuer access control server 218 in order to authenticate that the consumer is the rightful owner or assignee of a payment account associated with the data transmitted by the consumer. At step 252, the merchant computer 204 may send the authentication request message including at least the token to a merchant plug-in module 206.
At step 253, the merchant plug-in module 206 may analyze the authentication request message and determine that the message includes a token. For example, the merchant plug-in module 206 may parse the authentication request message and determine that data provided in a first field, such as the account data field, has a special format. According to various embodiments, the token may have a format that conforms to an industry standard. For example, the token may start, end or contain one or more specific characters. In some embodiments, the token may consist of truncated account number (e.g. first 6 digits and last 4 digits of the account number are retained) with alphabetic and numeric characters replacing middle digits.
Upon determining that the authentication request message includes a token, the merchant plug-in module 206 may determine a token service provider 210 among the plurality of token service providers as the issuer and/or manager of the token. For example, the merchant plug-in module 206 may determine the token service provider 210 based on analyzing a format of the token. The format of the token may include a series of predetermined characters that are assigned to a specific token service provider. The merchant plug-in module 206 may have access to a table or database storing the correspondence between the token service providers and predetermined format used by the token service providers. The merchant plug-in module 206 may interact with the identified token service provider 210 to de-tokenize the token in the authentication request message. In some embodiments, the merchant plug-in 206 may store the token.
At step 254, the merchant plug-in module 206 may send the token to the token service provider 210. The token service provider 210 may interact with a token vault where tokens and corresponding account numbers are stored. For example, the tokens and corresponding account numbers may be stored in forms of tables or in databases. The token service provider 210 may query the token vault (e.g. the tables or the databases) and retrieve the account number (e.g. a primary account number (PAN)) corresponding to the token. At step 255, the token service provider 210 may send the account number represented by the token to the merchant plug-in module 206. The merchant plug-in module 206 may modify the authentication request message to replace the token with the corresponding account number. Alternatively, the merchant plug-in module 206 may send the received account number to the merchant computer 204 so that the merchant computer may modify the authentication request message to replace the token with the corresponding account number. At step 256, the modified authentication request message including at least the account number may be sent to a directory server 216.
At step 257, the directory server may identify the issuer access control server 218 based on the account number and send the modified authentication request message to the issuer access control server 218 for authentication. For example, the directory server 216 may parse the modified authentication request message to identify the account number provided in a predetermined field of the modified authentication request message. Based on the format of the account number, the directory server may query a table or a database to identify the issuer access control server for the issuer that may have generated and/or manage the account number.
In some embodiments, the consumer data provided to the merchant at step 251 may include the account number instead of the token. In such embodiments, the merchant computer 204 or the merchant plug-in module 206 may generate the authentication request message including at least the account number without interacting with the token service provider 210. The authentication request message may be sent to the access control server 218 via the directory server 216 for authentication.
At step 258, the issuer access control server may perform authentication using the data in the modified authentication request message to determine whether the user is the rightful owner or assignee of the indicated account number. In some embodiments, the issuer access control server 218 may interact with the consumer so that the consumer may authenticate his or her identity by presenting authentication information to the access control server 218. In some embodiments, the consumer authenticates his or her identity by providing a password, credential, or other identifying information previously associated with their account.
For example, the access control server may generate an authentication message for the consumer. The authentication message may be sent to a consumer's user device. The authentication message may cause the consumer's user device to display an “authentication challenge” user interface, and thus the consumer may be authenticated using processes applicable to the account number (e.g., password, PIN entry, etc.). The consumer's user device may send a reply message including consumer's response to the authentication challenge (e.g. a password) to the access control server. The access control server may determine whether the provided password is correct.
At step 258, upon authenticating the consumer, the access control server 218 generates an authentication response message including at least the account number and an authentication value indicating whether the consumer has been authenticated by the access server computer 218. If the authentication information provided by the consumer matches the authentication information previously associated with the account being used for the proposed transaction, then the authentication response message may include data indicating that the authentication process was successful. Alternatively, the authentication response message can include data indicating that the authentication process failed. In some embodiments, the authentication response message may include an error code identifying the reason for failure of the authentication process.
At step 259, the access control server 218 sends the authentication response message including the account number and the authentication value to the directory server 216. The directory server 216 sends the authentication response message to the merchant plug-in module 206 at step 260. The merchant plug-in module 206 may re-tokenize the account number included in the authentication response message by interacting with the token service provider 210. In some embodiments, the merchant plug-in module 206 may store the token and/or the mapping between the token and the credentials. In such embodiments, the merchant plug-in module 206 may re-tokenize the credentials without communicating with the token service provider. At step 261, the merchant plug-in module 206 may send the account number to the token service provider 210 and receive the corresponding token from the token service provider 210. The merchant plug-in module 206 may modify the authentication response message to replace the account number with the retrieved token. At step 262, the merchant plug-in module 206 may send the modified authentication response message including at least the token and the authentication value to the merchant computer 204.
If the consumer has been authenticated by the access control server 218 (i.e. the authentication value included in the authentication response message indicates that the consumer has been authenticated by the access control server), the merchant computer 204 may start the payment transaction by generating a transaction authorization request message including at least the authentication value and the token. The transaction authorization request message may also include the transaction amount, user identifying information, merchant identifying information, etc.
At step 263, the merchant computer 204 may send the transaction authorization request message including the token and the authentication value to the acquirer 220. The acquirer 220 may send the transaction authorization request message to an authorization computer 224 via a payment processing network 222. Prior to sending the transaction authorization request message to the authorization computer 224, the acquirer 220 or the payment processing network 222 may detokenize the token.
At step 264, the acquirer may send the token to the token service provider 210. At step 265, the token service provider 210 may send the account number associated with the token to the acquirer 220. The acquirer 220 may modify the transaction authorization request message to replace the token with the corresponding account number and send the modified transaction authorization request message to the payment processing network at step 266. At step 267, the payment processing network may send the modified transaction authorization request message to the authorization computer 224 for authorization.
The authorization computer 224, may process the modified transaction authorization request message and generate a transaction authorization response message. The transaction authorization response message may include at least the account number and an indication of whether the transaction has been authorized. At step 268, the authorization computer 224 may send the transaction authorization response message to the payment processing network 222. At step 269, the payment processing network 222 may forward the transaction authorization response message to the acquirer 220. The acquirer 220 may interact with the token service provider 210 to re-tokenize the transaction authorization response message (steps 270 and 271). Upon receiving the token from the token service provider 210, the acquirer 220 may modify the transaction authorization response message to replace the account number with the token. At step 272, the acquirer 220 may send the modified transaction authorization response message to the merchant 204 informing the merchant 204 whether the transaction has been authorized by the authorization computer 224.
The system and the flowchart discussed above in connection with
A tokenization/detokenization merchant plug-in module requires very limited or no changes to be implemented in the transaction ecosystem. That is, the issuer and the payment processing network do not need to be modified to work with tokens. In addition, allowing merchant plug-in modules to detokenize tokens may require the merchants to comply with various industry standards. That, in return, would bring increased levels of security at the merchant level.
The merchant plug-in module may not be the only component in the system that is capable of interacting with token service providers. For example, the directory server may interact with a tokenization environment including a plurality of token service providers, as illustrated in
The merchant plug-in (MPI) module 306 illustrated in
The directory server 316 may be in communication with a tokenization environment 208 including a plurality of token service providers, such as a first token service provider 210, a second token service provider 212 and a third token service provider 214. When the directory server 316 determines that the authentication request message generated by the merchant computer 204 (and received from the merchant plug-in module 306) includes a token, the directory server 316 may identify the token service provider among the plurality of token service providers as the issuer/manager of the token. The directory server 316 may interact with the identified token service provider to detokenize the token, i.e. to retrieve the account number corresponding to the token. The directory server 316 may then modify the authentication request message generated by the merchant computer 204 to replace the token with the retrieved account number. The directory server 316 may forward the modified authentication request message to the access control server 218 for authentication.
The directory server 316 may be a server computer configured to route messages from the merchant plug-in module 306 to the issuer access control server computer 218, as well as messages back from the issuer access control server 218 to the merchant plug-in module 306. In other embodiments, the directory server 316 may route authentication request and response messages between the merchant computer 204 and the issuer access control server 218 as part of a transaction. In some embodiments, the directory server computer 316 may be operated by a payment processing network.
The issuer access control server 218 may perform an authentication process, such as one discussed above in connection with
If the authentication response message indicates that the consumer has been authenticated by the issuer's access control server 218, the merchant computer 204 may start the transaction by generating a transaction request message, as discussed above in connection with
According to various embodiments, the directory server 316 and the financial switch 222 may be the same entity or may be managed by the same entity, such as a payment processing network. In some embodiments, the issuer's access server computer 218 and the issuer authorization computer 224 may be same device or may be part of a same cluster of computers.
At step 351, the consumer provides data, such as transaction data, identification data, payment data, etc. to the merchant device 204 using the user device 202. The data may include a token representing an account number issued to the consumer by an issuer of consumer's payment account. The merchant computer 204 may generate an authentication request message to be forwarded to an issuer access control server 218 in order to authenticate that the consumer is the rightful owner or assignee of a payment account associated with the data transmitted by the consumer. At step 352, the merchant computer 204 may send the authentication request message including at least the token to a merchant plug-in module 306.
At step 353, the merchant plug-in module 306 forwards the authentication request message to the directory server 316. At step 354, the directory server 316 may analyze the authentication request message and determine that the message includes a token. For example, the directory server 316 may parse the authentication request message and determine that data provided in a first field, such as the account data field, has a special format. According to various embodiments, the token may have a format that conforms to an industry standard. For example, the token may start, end or contain one or more specific characters. In some embodiments, the token may consist of truncated account number (e.g. first 6 digits and last 4 digits of the account number are retained) with alphabetic and numeric characters replacing middle digits.
Upon determining that the authentication request message includes a token, the directory server 316 may determine a token service provider 210 among the plurality of token service providers as the issuer and/or manager of the token. For example, the directory server 316 may determine the token service provider 210 based on a format of the token. The format of the token may include a series of predetermined characters that are assigned to a specific token service provider. The directory server 316 may have access to a table or database storing the correspondence between the token service providers and predetermined format used by the token service providers. The directory server 316 may interact with the identified token service provider 210 to de-tokenize the token in the authentication request message. In some embodiments, the directory server 316 may store the token.
At step 355, the directory server 316 may send the token to the token service provider 210. The token service provider 210 may interact with a token vault where tokens and corresponding account numbers are stored. For example, the tokens and corresponding account numbers may be stored in forms of tables or in databases. The token service provider 210 may query the token vault (e.g. the tables or the databases) and retrieve the account number (e.g. a primary account number (PAN)) corresponding to the token. At step 356, the token service provider 210 may send the account number represented by the token to directory server 316. The directory server 316 may modify the authentication request message to replace the token with the corresponding account number.
At step 357, the directory server 316 may identify the issuer access control server 218 based on the account number and send the modified authentication request message including at least the account number to the issuer access control server 218 for authentication. For example, based on the format of the account number received from the token service provider 210, the directory server 316 may query a table or a database to identify the issuer access control server for the issuer that may have generated and/or manage the account number.
In some embodiments, the consumer data provided to the merchant at step 251 may include the account number instead of the token. In such embodiments, the merchant computer 204 may generate the authentication request message including at least the account number. The authentication request message may be sent to the access control server 218 via the directory server 316 for authentication without interacting with the token service provider 210.
At step 358, the issuer access control server may perform authentication using the data in the modified authentication request message to determine whether the user is the rightful owner or assignee of the indicated account number. In some embodiments, the issuer access control server 218 may interact with the consumer so that the consumer may authenticate his or her identity by presenting authentication information to the access control server 218. In some embodiments, the consumer authenticates his or her identity by providing a password, credential, or other identifying information previously associated with their account. Upon authenticating the consumer, the access control server 218 generates an authentication response message including at least the account number and an authentication value indicating whether the consumer has been authenticated by the access server computer 218. If the authentication information provided by the consumer matches the authentication information previously associated with the account being used for the proposed transaction, then the authentication response message may include data indicating that the authentication process was successful. Alternatively, the authentication response message can include data indicating that the authentication process failed. In some embodiments, the authentication response message may include an error code identifying the reason for failure of the authentication process.
At step 359, the access control server 218 sends the authentication response message including the account number and the authentication value to the directory server 316. The directory server 316 may re-tokenize the account number included in the authentication response message by interacting with the token service provider 210. In some embodiments, the directory server 316 may store the token and/or the mapping between the token and the credentials. In such embodiments, the directory server 316 may re-tokenize the credentials without communicating with the token service provider. At step 360, the directory server 316 may send the account number to the token service provider 210 and receive the corresponding token from the token service provider 210. The directory server 316 may modify the authentication response message to replace the account number with the retrieved token. At step 361, the directory server 316 may send the modified authentication response message including at least the token and the authentication value to the merchant plug-in module 306. The merchant plug-in module 306 may forward the modified authentication response message to the merchant computer 204 at step 362.
If the consumer has been authenticated by the access control server 218 (i.e. the authentication value included in the authentication response message indicates that the consumer has been authenticated by the access control server), the merchant computer 204 may start the payment transaction by generating a transaction authorization request message including at least the authentication value and the token. The transaction authorization request message may also include the transaction amount, user identifying information, merchant identifying information, etc. Steps 263-272 directed to transaction authorization process illustrated in
The system and the flowchart discussed above in connection with
A tokenization and/or detokenization capable directory server may be desirable as the directory server can work with multiple (e.g. all) issuers in communication with the payment network associated with the directory server. Moreover, since the directory server receives additional data going through the transaction ecosystem, the directory server may be better suited at detokenizing the tokens. For example, the directory server may recognize that the transaction started using a token. Accordingly, the directory server may assign a risk score (e.g. a favorable score if the transaction uses a token instead of an account number) to the transaction. Placing the detokenization intelligence on the directory server requires minor changes to the transaction ecosystem.
The directory server may not be the only component in the system that is capable of interacting with token service providers. For example, a token router provided in proximity of the access control server may interact with a tokenization environment including a plurality of token service providers, as illustrated in
The merchant plug-in (MPI) module 406 illustrated in
The directory server 416 may be a server computer configured to route messages from the merchant plug-in module 406 to the issuer access control server computer 218, as well as messages back from the issuer access control server 218 to the merchant plug-in module 406. In other embodiments, the directory server 416 may route authentication request and response messages between the merchant computer 204 and the issuer access control server 218 as part of a transaction. In some embodiments, the directory server computer 416 may be operated by a payment processing network.
The system 400 illustrated in
When the token router module 402 determines that the authentication request message generated by the merchant computer 204 (and received from the directory server 416) includes a token, the token router module 402 may identify the token service provider among the plurality of token service providers as the issuer/manager of the token. The token router module 402 may identify the relevant token server provider based on rules that may have been configured by the issuer. The rules may be based on, for example, bank identification number (BIN) range, payment card brand, etc. The token router module 402 may interact with the identified token service provider to detokenize the token, i.e. to retrieve the account number corresponding to the token. The token router module 402 may then modify the authentication request message generated by the merchant computer 204 to replace the token with the retrieved account number. The token router module 402 may forward the modified authentication request message to the access control server 218 for authentication.
The issuer access control server 218 may perform an authentication process, such as one discussed above in connection with
If the authentication response message indicates that the consumer has been authenticated by the issuer's access control server 218, the merchant computer 204 may start the transaction by generating a transaction request message, as discussed above in connection with
According to various embodiments, the directory server 416 and the financial switch 222 may be the same entity or may be managed by the same entity, such as a payment processing network. In some embodiments, the issuer's access server computer 218, the token router module 402 and the issuer authorization computer 224 may be same device or may be part of a same cluster of computers.
At step 451, the consumer provides data, such as transaction data, identification data, payment data, etc. to the merchant device 204 using the user device 202. The data may include a token representing an account number issued to the consumer by an issuer of consumer's payment account. The merchant computer 204 may generate an authentication request message to be forwarded to an issuer access control server 218 in order to authenticate that the consumer is the rightful owner or assignee of a payment account associated with the data transmitted by the consumer. At step 452, the merchant computer 204 may send the authentication request message including at least the token to a merchant plug-in module 406.
At step 453, the merchant plug-in module 406 forwards the authentication request message to the directory server 416. At step 454, the directory server 416 forwards the authentication request message to the token router module 402. In some embodiments, the directory server 416 may forward the authentication request message to the access control server 218 and the message may be intercepted by the token router module 402.
At step 455, the token router module 402 may analyze the authentication request message and determine that the message includes a token. For example, the token router module 402 may parse the authentication request message and determine that data provided in a first field, such as the account data field, has a special format. According to various embodiments, the token may have a format that conforms to an industry standard. For example, the token may start, end or contain one or more specific characters. In some embodiments, the token may consist of truncated account number (e.g. first 6 digits and last 4 digits of the account number are retained) with alphabetic and numeric characters replacing middle digits.
Upon determining that the authentication request message includes a token, the token router module 402 may determine a token service provider 210 among the plurality of token service providers as the issuer and/or manager of the token. For example, the token router module 402 may determine the token service provider 210 based on a format of the token. The format of the token may include a series of predetermined characters that are assigned to a specific token service provider. The token router module 402 may have access to a table or database storing the correspondence between the token service providers and predetermined format used by the token service providers. In other embodiments, the token router module 402 may determine the token service provider 210 based on one or more rules configured by the issuer. The token router module 402 may interact with the identified token service provider 210 to de-tokenize the token in the authentication request message. In some embodiments, the token router module 402 may store the token.
At step 456, the token router module 402 may send the token to the token service provider 210. The token service provider 210 may interact with a token vault where tokens and corresponding account numbers are stored. At step 457, the token service provider 210 may send an account number (e.g. a primary account number (PAN)) represented by the token to the token router module 402. The token router module 402 may modify the authentication request message to replace the token with the corresponding account number.
At step 458, the token router module 402 sends the modified authentication request message including at least the account number to the issuer access control server 218 for authentication.
At step 459, the issuer access control server 218 may perform authentication using the data in the modified authentication request message to determine whether the user is the rightful owner or assignee of the indicated account number. In some embodiments, the issuer access control server 218 may interact with the consumer so that the consumer may authenticate his or her identity by presenting authentication information to the access control server 218. In some embodiments, the consumer authenticates his or her identity by providing a password, credential, or other identifying information previously associated with their account. Upon authenticating the consumer, the access control server 218 generates an authentication response message including at least the account number and an authentication value indicating whether the consumer has been authenticated by the access server computer 218. If the authentication information provided by the consumer matches the authentication information previously associated with the account being used for the proposed transaction, then the authentication response message may include data indicating that the authentication process was successful. Alternatively, the authentication response message can include data indicating that the authentication process failed. In some embodiments, the authentication response message may include an error code identifying the reason for failure of the authentication process.
At step 460, the access control server 218 sends the authentication response message including the account number and the authentication value to the token router module 402. The token router module 402 may re-tokenize the account number included in the authentication response message by interacting with the token service provider 210. In some embodiments, the token router module 402 may store the token and/or the mapping between the token and the credentials. In such embodiments, the token router module 402 may re-tokenize the credentials without communicating with the token service provider. At step 461, the token router module 402 may send the account number to the token service provider 210 and receive the corresponding token from the token service provider 210. The token router module 402 may modify the authentication response message to replace the account number with the retrieved token. At step 462, the token router module 402 may send the modified authentication response message including at least the token and the authentication value to the directory server 416. At step 463, the directory server 416 may forward the modified authentication response message to the merchant plug-in module 406. The merchant plug-in module 406 may forward the modified authentication response message to the merchant computer 204 at step 464.
If the consumer has been authenticated by the access control server 218 (i.e. the authentication value included in the authentication response message indicates that the consumer has been authenticated by the access control server), the merchant computer 204 may start the payment transaction by generating a transaction authorization request message including at least the authentication value and the token. The transaction authorization request message may also include the transaction amount, user identifying information, merchant identifying information, etc. Steps 263-272 directed to transaction authorization process illustrated in
A tokenization and/or detokenization capable token router module may be desirable as it confines related changes to the payment ecosystem to the access control server, or the issuer. In addition, placing the detokenization intelligence at the token router allows issuers to better control the transaction flow.
Embodiments discussed herein allow for resolving the tokens provided in authentication request messages prior to performing authentication. When merchants or wallet providers send tokenized authentication request messages to the issuers it desirable to resolve the token to the corresponding account number before the authentication request reaches the issuer. Embodiments allow for a merchant plug-in module, a directory server or a token router provided in a transaction system to interact with a plurality of token service providers to detokenize and/or re-tokenize the data provided in the authentication messages.
The various participants and elements described herein may operate one or more computer apparatuses to facilitate the functions described herein. Any of the elements in the above-described
Examples of such subsystems or components are shown in
Storage media and computer-readable media for containing code, or portions of code, can include any appropriate media known or used in the art, including storage media and communication media, such as but not limited to volatile and non-volatile, removable and non-removable media implemented in any method or technology for storage and/or transmission of data such as computer-readable instructions, data structures, program modules, or other data, including RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disk (DVD) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, data signals, data transmissions, or any other medium which can be used to store or transmit the desired data and which can be accessed by the computer. Based on the disclosure and teachings provided herein, a person of ordinary skill in the art will appreciate other ways and/or methods to implement the various embodiments.
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 may, therefore, be determined not with reference to the above description, but instead may be determined with reference to the pending claims along with their full scope or equivalents. It may be understood that the present invention as described above can be implemented in the form of control logic using computer software in a modular or integrated manner. Based on the disclosure and teachings provided herein, a person of ordinary skill in the art may know and appreciate other ways and/or methods to implement the present invention using hardware and a combination of hardware and software. 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, C++, Python or Perl using, for example, conventional or object-oriented techniques. The software code may be stored as a series of instructions, or commands on a computer readable medium, 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.
Although many embodiments were described above as comprising different features and/or combination of features, a person of ordinary skill in the art after reading this disclosure may understand that in some instances, one or more of these components could be combined with any of the components or features described above. That is, one or more features from any embodiment can be combined with one or more features of any other embodiment without departing from the scope of the invention.
A recitation of “a”, “an” or “the” is intended to mean “one or more” unless specifically indicated to the contrary. Reference to a “first” component does not necessarily require that a second component be provided. Moreover reference to a “first” or a “second” component does not limit the referenced component to a particular location unless expressly stated.
| Number | Name | Date | Kind |
|---|---|---|---|
| 5613012 | Hoffman et al. | Mar 1997 | A |
| 5781438 | Lee et al. | Jul 1998 | A |
| 5883810 | Franklin et al. | Mar 1999 | A |
| 5953710 | Fleming | Sep 1999 | A |
| 5956699 | Wong et al. | Sep 1999 | A |
| 6000832 | Franklin et al. | Dec 1999 | A |
| 6014635 | Harris et al. | Jan 2000 | A |
| 6044360 | Picciallo | Mar 2000 | A |
| 6163771 | Walker et al. | Dec 2000 | A |
| 6227447 | Campisano | May 2001 | B1 |
| 6236981 | Hill | May 2001 | B1 |
| 6267292 | Walker et al. | Jul 2001 | B1 |
| 6327578 | Linehan | Dec 2001 | B1 |
| 6341724 | Campisano | Jan 2002 | B2 |
| 6385596 | Wiser et al. | May 2002 | B1 |
| 6422462 | Cohen | Jul 2002 | B1 |
| 6425523 | Shem-Ur et al. | Jul 2002 | B1 |
| 6592044 | Wong et al. | Jul 2003 | B1 |
| 6636833 | Flitcroft et al. | Oct 2003 | B1 |
| 6748367 | Lee | Jun 2004 | B1 |
| 6805287 | Bishop et al. | Oct 2004 | B2 |
| 6879965 | Fung et al. | Apr 2005 | B2 |
| 6891953 | DeMello et al. | May 2005 | B1 |
| 6901387 | Wells et al. | May 2005 | B2 |
| 6931382 | Laage et al. | Aug 2005 | B2 |
| 6938019 | Uzo | Aug 2005 | B1 |
| 6941285 | Sarcanin | Sep 2005 | B2 |
| 6980670 | Hoffman et al. | Dec 2005 | B1 |
| 6990470 | Hogan et al. | Jan 2006 | B2 |
| 6991157 | Bishop et al. | Jan 2006 | B2 |
| 7051929 | Li | May 2006 | B2 |
| 7069249 | Stolfo et al. | Jun 2006 | B2 |
| 7103576 | Mann, III et al. | Sep 2006 | B2 |
| 7113930 | Eccles et al. | Sep 2006 | B2 |
| 7136835 | Flitcroft et al. | Nov 2006 | B1 |
| 7177835 | Walker et al. | Feb 2007 | B1 |
| 7177848 | Hogan et al. | Feb 2007 | B2 |
| 7194437 | Britto et al. | Mar 2007 | B1 |
| 7209561 | Shankar et al. | Apr 2007 | B1 |
| 7264154 | Harris | Sep 2007 | B2 |
| 7287692 | Patel et al. | Oct 2007 | B1 |
| 7292999 | Hobson et al. | Nov 2007 | B2 |
| 7350230 | Forrest | Mar 2008 | B2 |
| 7353382 | Labrou et al. | Apr 2008 | B2 |
| 7379919 | Hogan et al. | May 2008 | B2 |
| RE40444 | Linehan | Jul 2008 | E |
| 7415443 | Hobson et al. | Aug 2008 | B2 |
| 7444676 | Asghari-Kamrani et al. | Oct 2008 | B1 |
| 7469151 | Khan et al. | Dec 2008 | B2 |
| 7548889 | Bhambri et al. | Jun 2009 | B2 |
| 7567934 | Flitcroft et al. | Jul 2009 | B2 |
| 7567936 | Peckover et al. | Jul 2009 | B1 |
| 7571139 | Giordano et al. | Aug 2009 | B1 |
| 7571142 | Flitcroft et al. | Aug 2009 | B1 |
| 7580898 | Brown et al. | Aug 2009 | B2 |
| 7584153 | Brown et al. | Sep 2009 | B2 |
| 7593896 | Flitcroft et al. | Sep 2009 | B1 |
| 7606560 | Labrou et al. | Oct 2009 | B2 |
| 7627531 | Breck et al. | Dec 2009 | B2 |
| 7627895 | Gifford et al. | Dec 2009 | B2 |
| 7650314 | Saunders | Jan 2010 | B1 |
| 7685037 | Reiners et al. | Mar 2010 | B2 |
| 7702578 | Fung et al. | Apr 2010 | B2 |
| 7707120 | Dominguez et al. | Apr 2010 | B2 |
| 7712655 | Wong | May 2010 | B2 |
| 7734527 | Uzo | Jun 2010 | B2 |
| 7753265 | Harris | Jul 2010 | B2 |
| 7770789 | Oder, II et al. | Aug 2010 | B2 |
| 7784685 | Hopkins, III | Aug 2010 | B1 |
| 7793851 | Mullen | Sep 2010 | B2 |
| 7801826 | Labrou et al. | Sep 2010 | B2 |
| 7805376 | Smith | Sep 2010 | B2 |
| 7805378 | Berardi et al. | Sep 2010 | B2 |
| 7818264 | Hammad | Oct 2010 | B2 |
| 7828220 | Mullen | Nov 2010 | B2 |
| 7835960 | Breck et al. | Nov 2010 | B2 |
| 7841523 | Oder, II et al. | Nov 2010 | B2 |
| 7841539 | Newton | Nov 2010 | B2 |
| 7844550 | Walker et al. | Nov 2010 | B2 |
| 7848980 | Carlson | Dec 2010 | B2 |
| 7849020 | Johnson | Dec 2010 | B2 |
| 7853529 | Walker et al. | Dec 2010 | B1 |
| 7853995 | Chow et al. | Dec 2010 | B2 |
| 7865414 | Fung et al. | Jan 2011 | B2 |
| 7873579 | Hobson et al. | Jan 2011 | B2 |
| 7873580 | Hobson et al. | Jan 2011 | B2 |
| 7890393 | Talbert et al. | Feb 2011 | B2 |
| 7891563 | Oder, II et al. | Feb 2011 | B2 |
| 7896238 | Fein et al. | Mar 2011 | B2 |
| 7908216 | Davis et al. | Mar 2011 | B1 |
| 7922082 | Muscato | Apr 2011 | B2 |
| 7931195 | Mullen | Apr 2011 | B2 |
| 7937324 | Patterson | May 2011 | B2 |
| 7938318 | Fein et al. | May 2011 | B2 |
| 7954705 | Mullen | Jun 2011 | B2 |
| 7959076 | Hopkins, III | Jun 2011 | B1 |
| 7996288 | Stolfo | Aug 2011 | B1 |
| 8025223 | Saunders et al. | Sep 2011 | B2 |
| 8046256 | Chien et al. | Oct 2011 | B2 |
| 8060448 | Jones | Nov 2011 | B2 |
| 8060449 | Zhu | Nov 2011 | B1 |
| 8074877 | Mullen et al. | Dec 2011 | B2 |
| 8074879 | Harris | Dec 2011 | B2 |
| 8082210 | Hansen | Dec 2011 | B2 |
| 8095113 | Kean et al. | Jan 2012 | B2 |
| 8104679 | Brown | Jan 2012 | B2 |
| RE43157 | Bishop et al. | Feb 2012 | E |
| 8109436 | Hopkins, III | Feb 2012 | B1 |
| 8121942 | Carlson et al. | Feb 2012 | B2 |
| 8121956 | Carlson et al. | Feb 2012 | B2 |
| 8126449 | Beenau et al. | Feb 2012 | B2 |
| 8171525 | Pelly et al. | May 2012 | B1 |
| 8175973 | Davis et al. | May 2012 | B2 |
| 8190523 | Patterson | May 2012 | B2 |
| 8196813 | Vadhri | Jun 2012 | B2 |
| 8205791 | Randazza et al. | Jun 2012 | B2 |
| 8219489 | Patterson | Jul 2012 | B2 |
| 8224702 | Mengerink et al. | Jul 2012 | B2 |
| 8225385 | Chow et al. | Jul 2012 | B2 |
| 8229852 | Carlson | Jul 2012 | B2 |
| 8265993 | Chien et al. | Sep 2012 | B2 |
| 8280777 | Mengerink et al. | Oct 2012 | B2 |
| 8281991 | Wentker et al. | Oct 2012 | B2 |
| 8328095 | Oder, II et al. | Dec 2012 | B2 |
| 8336088 | Raj et al. | Dec 2012 | B2 |
| 8346666 | Lindelsee et al. | Jan 2013 | B2 |
| 8376225 | Hopkins, III | Feb 2013 | B1 |
| 8380177 | Laracey | Feb 2013 | B2 |
| 8387873 | Saunders et al. | Mar 2013 | B2 |
| 8401539 | Beenau et al. | Mar 2013 | B2 |
| 8401898 | Chien et al. | Mar 2013 | B2 |
| 8402555 | Grecia | Mar 2013 | B2 |
| 8403211 | Brooks et al. | Mar 2013 | B2 |
| 8412623 | Moon et al. | Apr 2013 | B2 |
| 8412837 | Emigh et al. | Apr 2013 | B1 |
| 8417642 | Oren et al. | Apr 2013 | B2 |
| 8447699 | Batada et al. | May 2013 | B2 |
| 8453223 | Svigals et al. | May 2013 | B2 |
| 8453925 | Fisher et al. | Jun 2013 | B2 |
| 8458487 | Palgon et al. | Jun 2013 | B1 |
| 8484134 | Hobson et al. | Jul 2013 | B2 |
| 8485437 | Mullen et al. | Jul 2013 | B2 |
| 8494959 | Hathaway et al. | Jul 2013 | B2 |
| 8498908 | Mengerink et al. | Jul 2013 | B2 |
| 8504475 | Brand et al. | Aug 2013 | B2 |
| 8504478 | Saunders et al. | Aug 2013 | B2 |
| 8510816 | Quach et al. | Aug 2013 | B2 |
| 8433116 | Davis et al. | Sep 2013 | B2 |
| 8533860 | Grecia | Sep 2013 | B1 |
| 8538845 | Liberty | Sep 2013 | B2 |
| 8555079 | Shablygin et al. | Oct 2013 | B2 |
| 8566168 | Bierbaum et al. | Oct 2013 | B1 |
| 8567670 | Stanfield et al. | Oct 2013 | B2 |
| 8571939 | Lindsey et al. | Oct 2013 | B2 |
| 8577336 | Mechaley, Jr. | Nov 2013 | B2 |
| 8577803 | Chatterjee et al. | Nov 2013 | B2 |
| 8577813 | Weiss | Nov 2013 | B2 |
| 8578176 | Mattsson | Nov 2013 | B2 |
| 8583494 | Fisher | Nov 2013 | B2 |
| 8584251 | Mcguire et al. | Nov 2013 | B2 |
| 8589237 | Fisher | Nov 2013 | B2 |
| 8589271 | Evans | Nov 2013 | B2 |
| 8589291 | Carlson et al. | Nov 2013 | B2 |
| 8595098 | Starai et al. | Nov 2013 | B2 |
| 8595812 | Bomar et al. | Nov 2013 | B2 |
| 8595850 | Spies et al. | Nov 2013 | B2 |
| 8606638 | Dragt | Dec 2013 | B2 |
| 8606700 | Carlson et al. | Dec 2013 | B2 |
| 8606720 | Baker et al. | Dec 2013 | B1 |
| 8615468 | Varadarajan | Dec 2013 | B2 |
| 8620754 | Fisher | Dec 2013 | B2 |
| 8635157 | Smith et al. | Jan 2014 | B2 |
| 8646059 | Von Behren et al. | Feb 2014 | B1 |
| 8651374 | Brabson et al. | Feb 2014 | B2 |
| 8656180 | Shablygin et al. | Feb 2014 | B2 |
| 8751391 | Freund | Jun 2014 | B2 |
| 8762263 | Gauthier et al. | Jun 2014 | B2 |
| 8793186 | Patterson | Jul 2014 | B2 |
| 8838982 | Carlson et al. | Sep 2014 | B2 |
| 8856539 | Weiss | Oct 2014 | B2 |
| 8887308 | Grecia | Nov 2014 | B2 |
| 9065643 | Hurry et al. | Jun 2015 | B2 |
| 9070129 | Sheets et al. | Jun 2015 | B2 |
| 9100826 | Weiss | Aug 2015 | B2 |
| 9160741 | Wentker et al. | Oct 2015 | B2 |
| 9229964 | Stevelinck | Jan 2016 | B2 |
| 9245267 | Singh | Jan 2016 | B2 |
| 9249241 | Dai et al. | Feb 2016 | B2 |
| 9256871 | Anderson et al. | Feb 2016 | B2 |
| 9280765 | Hammad | Mar 2016 | B2 |
| 9530137 | Weiss | Dec 2016 | B2 |
| 20010029485 | Brody et al. | Oct 2001 | A1 |
| 20010034720 | Armes | Oct 2001 | A1 |
| 20010054003 | Chien et al. | Dec 2001 | A1 |
| 20020007320 | Hogan et al. | Jan 2002 | A1 |
| 20020016749 | Borecki et al. | Feb 2002 | A1 |
| 20020029193 | Ranjan et al. | Mar 2002 | A1 |
| 20020035548 | Hogan et al. | Mar 2002 | A1 |
| 20020073045 | Rubin et al. | Jun 2002 | A1 |
| 20020116341 | Hogan et al. | Aug 2002 | A1 |
| 20020133467 | Hobson et al. | Sep 2002 | A1 |
| 20020147913 | Lun Yip | Oct 2002 | A1 |
| 20030028481 | Flitcroft et al. | Feb 2003 | A1 |
| 20030130955 | Hawthorne | Jul 2003 | A1 |
| 20030191709 | Elston et al. | Oct 2003 | A1 |
| 20030191945 | Keech | Oct 2003 | A1 |
| 20040010462 | Moon et al. | Jan 2004 | A1 |
| 20040050928 | Bishop et al. | Mar 2004 | A1 |
| 20040059682 | Hasumi et al. | Mar 2004 | A1 |
| 20040093281 | Silverstein et al. | May 2004 | A1 |
| 20040139008 | Mascavage, III | Jul 2004 | A1 |
| 20040143532 | Lee | Jul 2004 | A1 |
| 20040158532 | Breck et al. | Aug 2004 | A1 |
| 20040210449 | Breck et al. | Oct 2004 | A1 |
| 20040210498 | Freund | Oct 2004 | A1 |
| 20040232225 | Bishop et al. | Nov 2004 | A1 |
| 20040260646 | Berardi et al. | Dec 2004 | A1 |
| 20050037735 | Coutts | Feb 2005 | A1 |
| 20050080730 | Sorrentino | Apr 2005 | A1 |
| 20050108178 | York | May 2005 | A1 |
| 20050199709 | Linlor | Sep 2005 | A1 |
| 20050246293 | Ong | Nov 2005 | A1 |
| 20050269401 | Spitzer et al. | Dec 2005 | A1 |
| 20050269402 | Spitzer et al. | Dec 2005 | A1 |
| 20060015358 | Chua | Jan 2006 | A1 |
| 20060235795 | Johnson et al. | Oct 2006 | A1 |
| 20060237528 | Bishop et al. | Oct 2006 | A1 |
| 20060278704 | Saunders et al. | Dec 2006 | A1 |
| 20070107044 | Yuen et al. | May 2007 | A1 |
| 20070129955 | Dalmia et al. | Jun 2007 | A1 |
| 20070136193 | Starr | Jun 2007 | A1 |
| 20070136211 | Brown et al. | Jun 2007 | A1 |
| 20070170247 | Friedman | Jul 2007 | A1 |
| 20070179885 | Bird et al. | Aug 2007 | A1 |
| 20070208671 | Brown et al. | Sep 2007 | A1 |
| 20070245414 | Chan et al. | Oct 2007 | A1 |
| 20070288377 | Shaked | Dec 2007 | A1 |
| 20070291995 | Rivera | Dec 2007 | A1 |
| 20080015988 | Brown et al. | Jan 2008 | A1 |
| 20080029607 | Mullen | Feb 2008 | A1 |
| 20080035738 | Mullen | Feb 2008 | A1 |
| 20080052226 | Agarwal et al. | Feb 2008 | A1 |
| 20080054068 | Mullen | Mar 2008 | A1 |
| 20080054079 | Mullen | Mar 2008 | A1 |
| 20080054081 | Mullen | Mar 2008 | A1 |
| 20080065554 | Hogan et al. | Mar 2008 | A1 |
| 20080065555 | Mullen | Mar 2008 | A1 |
| 20080201264 | Brown et al. | Aug 2008 | A1 |
| 20080201265 | Newton | Aug 2008 | A1 |
| 20080228646 | Myers et al. | Sep 2008 | A1 |
| 20080243702 | Hart et al. | Oct 2008 | A1 |
| 20080245855 | Fein et al. | Oct 2008 | A1 |
| 20080245861 | Fein et al. | Oct 2008 | A1 |
| 20080283591 | Oder, II et al. | Nov 2008 | A1 |
| 20080302869 | Mullen | Dec 2008 | A1 |
| 20080302876 | Mullen | Dec 2008 | A1 |
| 20080313264 | Pestoni | Dec 2008 | A1 |
| 20090006262 | Brown et al. | Jan 2009 | A1 |
| 20090010488 | Matsuoka et al. | Jan 2009 | A1 |
| 20090037333 | Flitcroft et al. | Feb 2009 | A1 |
| 20090037388 | Cooper et al. | Feb 2009 | A1 |
| 20090043702 | Bennett | Feb 2009 | A1 |
| 20090048971 | Hathaway et al. | Feb 2009 | A1 |
| 20090106112 | Dalmia et al. | Apr 2009 | A1 |
| 20090106160 | Skowronek | Apr 2009 | A1 |
| 20090134217 | Flitcroft et al. | May 2009 | A1 |
| 20090157555 | Biffle et al. | Jun 2009 | A1 |
| 20090159673 | Mullen et al. | Jun 2009 | A1 |
| 20090159700 | Mullen et al. | Jun 2009 | A1 |
| 20090159707 | Mullen et al. | Jun 2009 | A1 |
| 20090173782 | Muscato | Jul 2009 | A1 |
| 20090200371 | Kean et al. | Aug 2009 | A1 |
| 20090248583 | Chhabra | Oct 2009 | A1 |
| 20090276347 | Kargman | Nov 2009 | A1 |
| 20090281948 | Carlson | Nov 2009 | A1 |
| 20090294527 | Brabson et al. | Dec 2009 | A1 |
| 20090307139 | Mardikar et al. | Dec 2009 | A1 |
| 20090308921 | Mullen | Dec 2009 | A1 |
| 20090327131 | Beenau et al. | Dec 2009 | A1 |
| 20100008535 | Abulafia et al. | Jan 2010 | A1 |
| 20100088237 | Wankmueller | Apr 2010 | A1 |
| 20100094755 | Kloster | Apr 2010 | A1 |
| 20100106644 | Annan et al. | Apr 2010 | A1 |
| 20100120408 | Beenau et al. | May 2010 | A1 |
| 20100133334 | Vadhri | Jun 2010 | A1 |
| 20100138347 | Chen | Jun 2010 | A1 |
| 20100145860 | Pelegero | Jun 2010 | A1 |
| 20100161433 | White | Jun 2010 | A1 |
| 20100185545 | Royyuru et al. | Jul 2010 | A1 |
| 20100211505 | Saunders et al. | Aug 2010 | A1 |
| 20100223186 | Hogan et al. | Sep 2010 | A1 |
| 20100228668 | Hogan et al. | Sep 2010 | A1 |
| 20100235284 | Moore | Sep 2010 | A1 |
| 20100258620 | Torreyson et al. | Oct 2010 | A1 |
| 20100291904 | Musfeldt et al. | Nov 2010 | A1 |
| 20100299267 | Faith et al. | Nov 2010 | A1 |
| 20100306076 | Taveau et al. | Dec 2010 | A1 |
| 20100325041 | Berardi et al. | Dec 2010 | A1 |
| 20110010292 | Giordano et al. | Jan 2011 | A1 |
| 20110016047 | Wu et al. | Jan 2011 | A1 |
| 20110016320 | Bergsten et al. | Jan 2011 | A1 |
| 20110040640 | Erikson | Feb 2011 | A1 |
| 20110047076 | Carlson et al. | Feb 2011 | A1 |
| 20110083018 | Kesanupalli et al. | Apr 2011 | A1 |
| 20110087596 | Dorsey | Apr 2011 | A1 |
| 20110093397 | Carlson et al. | Apr 2011 | A1 |
| 20110125597 | Oder, II et al. | May 2011 | A1 |
| 20110153437 | Archer et al. | Jun 2011 | A1 |
| 20110153498 | Makhotin et al. | Jun 2011 | A1 |
| 20110154466 | Harper et al. | Jun 2011 | A1 |
| 20110161233 | Tieken | Jun 2011 | A1 |
| 20110178926 | Lindelsee et al. | Jul 2011 | A1 |
| 20110191244 | Dai | Aug 2011 | A1 |
| 20110238511 | Park et al. | Sep 2011 | A1 |
| 20110238573 | Varadarajan | Sep 2011 | A1 |
| 20110246317 | Coppinger | Oct 2011 | A1 |
| 20110258111 | Raj et al. | Oct 2011 | A1 |
| 20110272471 | Mullen | Nov 2011 | A1 |
| 20110272478 | Mullen | Nov 2011 | A1 |
| 20110276380 | Mullen et al. | Nov 2011 | A1 |
| 20110276381 | Mullen et al. | Nov 2011 | A1 |
| 20110276424 | Mullen | Nov 2011 | A1 |
| 20110276425 | Mullen | Nov 2011 | A1 |
| 20110295745 | White et al. | Dec 2011 | A1 |
| 20110302081 | Saunders et al. | Dec 2011 | A1 |
| 20120023567 | Hammad | Jan 2012 | A1 |
| 20120028609 | Hruska | Feb 2012 | A1 |
| 20120030047 | Fuentes et al. | Feb 2012 | A1 |
| 20120035998 | Chien et al. | Feb 2012 | A1 |
| 20120041881 | Basu et al. | Feb 2012 | A1 |
| 20120047237 | Arvidsson et al. | Feb 2012 | A1 |
| 20120066078 | Kingston et al. | Mar 2012 | A1 |
| 20120072350 | Goldthwaite et al. | Mar 2012 | A1 |
| 20120078735 | Bauer et al. | Mar 2012 | A1 |
| 20120078798 | Downing et al. | Mar 2012 | A1 |
| 20120078799 | Jackson et al. | Mar 2012 | A1 |
| 20120095852 | Bauer et al. | Apr 2012 | A1 |
| 20120095865 | Doherty et al. | Apr 2012 | A1 |
| 20120116902 | Cardina et al. | May 2012 | A1 |
| 20120123882 | Carlson et al. | May 2012 | A1 |
| 20120123940 | Killian et al. | May 2012 | A1 |
| 20120129514 | Beenau et al. | May 2012 | A1 |
| 20120143767 | Abadir | Jun 2012 | A1 |
| 20120143772 | Abadir | Jun 2012 | A1 |
| 20120158580 | Eram et al. | Jun 2012 | A1 |
| 20120158593 | Garfinkle et al. | Jun 2012 | A1 |
| 20120173431 | Ritchie et al. | Jul 2012 | A1 |
| 20120185386 | Salama et al. | Jul 2012 | A1 |
| 20120197807 | Schlesser et al. | Aug 2012 | A1 |
| 20120203664 | Torossian et al. | Aug 2012 | A1 |
| 20120203666 | Torossian et al. | Aug 2012 | A1 |
| 20120215688 | Musser et al. | Aug 2012 | A1 |
| 20120215696 | Salonen | Aug 2012 | A1 |
| 20120221421 | Hammad | Aug 2012 | A1 |
| 20120226582 | Hammad | Sep 2012 | A1 |
| 20120231844 | Coppinger | Sep 2012 | A1 |
| 20120233004 | Bercaw | Sep 2012 | A1 |
| 20120246070 | Vadhri | Sep 2012 | A1 |
| 20120246071 | Jain et al. | Sep 2012 | A1 |
| 20120246079 | Wilson et al. | Sep 2012 | A1 |
| 20120265631 | Cronic et al. | Oct 2012 | A1 |
| 20120271770 | Harris et al. | Oct 2012 | A1 |
| 20120297446 | Webb et al. | Nov 2012 | A1 |
| 20120300932 | Cambridge et al. | Nov 2012 | A1 |
| 20120303503 | Cambridge et al. | Nov 2012 | A1 |
| 20120303961 | Kean et al. | Nov 2012 | A1 |
| 20120304273 | Bailey | Nov 2012 | A1 |
| 20120310725 | Chien et al. | Dec 2012 | A1 |
| 20120310831 | Harris et al. | Dec 2012 | A1 |
| 20120316992 | Oborne | Dec 2012 | A1 |
| 20120317035 | Royyuru et al. | Dec 2012 | A1 |
| 20120317036 | Bower et al. | Dec 2012 | A1 |
| 20130017784 | Fisher | Jan 2013 | A1 |
| 20130018757 | Anderson et al. | Jan 2013 | A1 |
| 20130019098 | Gupta et al. | Jan 2013 | A1 |
| 20130031006 | Mccullagh et al. | Jan 2013 | A1 |
| 20130054337 | Brendell et al. | Feb 2013 | A1 |
| 20130054466 | Muscato | Feb 2013 | A1 |
| 20130054474 | Yeager | Feb 2013 | A1 |
| 20130081122 | Svigals et al. | Mar 2013 | A1 |
| 20130091028 | Oder ("J.D."), II et al. | Apr 2013 | A1 |
| 20130110658 | Lyman et al. | May 2013 | A1 |
| 20130111599 | Gargiulo | May 2013 | A1 |
| 20130117185 | Collison et al. | May 2013 | A1 |
| 20130124290 | Fisher | May 2013 | A1 |
| 20130124291 | Fisher | May 2013 | A1 |
| 20130124364 | Mittal | May 2013 | A1 |
| 20130138525 | Bercaw | May 2013 | A1 |
| 20130144888 | Faith et al. | Jun 2013 | A1 |
| 20130145148 | Shablygin et al. | Jun 2013 | A1 |
| 20130145172 | Shablygin et al. | Jun 2013 | A1 |
| 20130159178 | Colon et al. | Jun 2013 | A1 |
| 20130159184 | Thaw | Jun 2013 | A1 |
| 20130166402 | Parento et al. | Jun 2013 | A1 |
| 20130166456 | Zhang et al. | Jun 2013 | A1 |
| 20130173736 | Krzeminski et al. | Jul 2013 | A1 |
| 20130185202 | Goldthwaite et al. | Jul 2013 | A1 |
| 20130191286 | Cronic et al. | Jul 2013 | A1 |
| 20130191289 | Cronic et al. | Jul 2013 | A1 |
| 20130198071 | Jurss | Aug 2013 | A1 |
| 20130198080 | Anderson et al. | Aug 2013 | A1 |
| 20130200146 | Moghadam | Aug 2013 | A1 |
| 20130204787 | Dubois | Aug 2013 | A1 |
| 20130204793 | Kerridge et al. | Aug 2013 | A1 |
| 20130212007 | Mattsson et al. | Aug 2013 | A1 |
| 20130212017 | Bangia | Aug 2013 | A1 |
| 20130212019 | Mattsson et al. | Aug 2013 | A1 |
| 20130212024 | Mattsson et al. | Aug 2013 | A1 |
| 20130212026 | Powell et al. | Aug 2013 | A1 |
| 20130212666 | Mattsson et al. | Aug 2013 | A1 |
| 20130218698 | Moon et al. | Aug 2013 | A1 |
| 20130218769 | Pourfallah et al. | Aug 2013 | A1 |
| 20130226799 | Raj | Aug 2013 | A1 |
| 20130226813 | Voltz | Aug 2013 | A1 |
| 20130246199 | Carlson | Sep 2013 | A1 |
| 20130246202 | Tobin | Sep 2013 | A1 |
| 20130246203 | Laracey | Sep 2013 | A1 |
| 20130246258 | Dessert | Sep 2013 | A1 |
| 20130246259 | Dessert | Sep 2013 | A1 |
| 20130246261 | Purves et al. | Sep 2013 | A1 |
| 20130246267 | Tobin | Sep 2013 | A1 |
| 20130254028 | Salci | Sep 2013 | A1 |
| 20130254052 | Royyuru et al. | Sep 2013 | A1 |
| 20130254102 | Royyuru | Sep 2013 | A1 |
| 20130254117 | Von Mueller et al. | Sep 2013 | A1 |
| 20130262296 | Thomas et al. | Oct 2013 | A1 |
| 20130262302 | Lettow et al. | Oct 2013 | A1 |
| 20130262315 | Hruska | Oct 2013 | A1 |
| 20130262316 | Hruska | Oct 2013 | A1 |
| 20130262317 | Collinge et al. | Oct 2013 | A1 |
| 20130275300 | Killian et al. | Oct 2013 | A1 |
| 20130275307 | Khan | Oct 2013 | A1 |
| 20130275308 | Paraskeva et al. | Oct 2013 | A1 |
| 20130282502 | Jooste | Oct 2013 | A1 |
| 20130282575 | Mullen et al. | Oct 2013 | A1 |
| 20130282588 | Hruska | Oct 2013 | A1 |
| 20130297501 | Monk et al. | Nov 2013 | A1 |
| 20130297504 | Nwokolo et al. | Nov 2013 | A1 |
| 20130297508 | Belamant | Nov 2013 | A1 |
| 20130304649 | Cronic et al. | Nov 2013 | A1 |
| 20130308778 | Fosmark et al. | Nov 2013 | A1 |
| 20130311382 | Fosmark et al. | Nov 2013 | A1 |
| 20130317982 | Mengerink et al. | Nov 2013 | A1 |
| 20130332344 | Weber | Dec 2013 | A1 |
| 20130339253 | Sincai | Dec 2013 | A1 |
| 20130346314 | Mogollon et al. | Dec 2013 | A1 |
| 20140007213 | Sanin et al. | Jan 2014 | A1 |
| 20140013106 | Redpath | Jan 2014 | A1 |
| 20140013114 | Redpath | Jan 2014 | A1 |
| 20140013452 | Aissi et al. | Jan 2014 | A1 |
| 20140019352 | Shrivastava | Jan 2014 | A1 |
| 20140025581 | Calman | Jan 2014 | A1 |
| 20140025585 | Calman | Jan 2014 | A1 |
| 20140025958 | Calman | Jan 2014 | A1 |
| 20140032417 | Mattsson | Jan 2014 | A1 |
| 20140032418 | Weber | Jan 2014 | A1 |
| 20140040137 | Carlson et al. | Feb 2014 | A1 |
| 20140040139 | Brudnicki et al. | Feb 2014 | A1 |
| 20140040144 | Plomske et al. | Feb 2014 | A1 |
| 20140040145 | Ozvat et al. | Feb 2014 | A1 |
| 20140040148 | Ozvat et al. | Feb 2014 | A1 |
| 20140040628 | Fort et al. | Feb 2014 | A1 |
| 20140041018 | Bomar et al. | Feb 2014 | A1 |
| 20140046853 | Spies et al. | Feb 2014 | A1 |
| 20140047551 | Nagasundaram et al. | Feb 2014 | A1 |
| 20140052532 | Tsai et al. | Feb 2014 | A1 |
| 20140052620 | Rogers et al. | Feb 2014 | A1 |
| 20140052637 | Jooste et al. | Feb 2014 | A1 |
| 20140068706 | Aissi | Mar 2014 | A1 |
| 20140074637 | Hammad | Mar 2014 | A1 |
| 20140108172 | Weber et al. | Apr 2014 | A1 |
| 20140114857 | Griggs et al. | Apr 2014 | A1 |
| 20140143137 | Carlson | May 2014 | A1 |
| 20140164243 | Aabye et al. | Jun 2014 | A1 |
| 20140188586 | Carpenter et al. | Jul 2014 | A1 |
| 20140294701 | Dai et al. | Oct 2014 | A1 |
| 20140297534 | Patterson | Oct 2014 | A1 |
| 20140310183 | Weber | Oct 2014 | A1 |
| 20140330721 | Wang | Nov 2014 | A1 |
| 20140330722 | Laxminarayanan et al. | Nov 2014 | A1 |
| 20140331265 | Mozell et al. | Nov 2014 | A1 |
| 20140337236 | Wong et al. | Nov 2014 | A1 |
| 20140344153 | Raj et al. | Nov 2014 | A1 |
| 20140372308 | Sheets | Dec 2014 | A1 |
| 20150019443 | Sheets et al. | Jan 2015 | A1 |
| 20150032625 | Dill et al. | Jan 2015 | A1 |
| 20150032626 | Dill et al. | Jan 2015 | A1 |
| 20150032627 | Dill et al. | Jan 2015 | A1 |
| 20150046327 | Taupitz | Feb 2015 | A1 |
| 20150046338 | Laxminarayanan et al. | Feb 2015 | A1 |
| 20150046339 | Wong et al. | Feb 2015 | A1 |
| 20150052064 | Karpenko et al. | Feb 2015 | A1 |
| 20150088756 | Makhotin et al. | Mar 2015 | A1 |
| 20150106239 | Gaddam et al. | Apr 2015 | A1 |
| 20150112870 | Nagasundaram et al. | Apr 2015 | A1 |
| 20150112871 | Kumnick | Apr 2015 | A1 |
| 20150120472 | Aabye et al. | Apr 2015 | A1 |
| 20150127529 | Makhotin et al. | May 2015 | A1 |
| 20150127547 | Powell et al. | May 2015 | A1 |
| 20150140960 | Powell et al. | May 2015 | A1 |
| 20150142673 | Nelsen et al. | May 2015 | A1 |
| 20150161597 | Subramanian et al. | Jun 2015 | A1 |
| 20150161608 | Gilbert | Jun 2015 | A1 |
| 20150178724 | Ngo et al. | Jun 2015 | A1 |
| 20150180836 | Wong et al. | Jun 2015 | A1 |
| 20150186864 | Jones et al. | Jul 2015 | A1 |
| 20150193222 | Pirzadeh et al. | Jul 2015 | A1 |
| 20150195133 | Sheets et al. | Jul 2015 | A1 |
| 20150199679 | Palanisamy et al. | Jul 2015 | A1 |
| 20150199689 | Kumnick et al. | Jul 2015 | A1 |
| 20150220917 | Aabye et al. | Aug 2015 | A1 |
| 20150269566 | Gaddam et al. | Sep 2015 | A1 |
| 20150312038 | Palanisamy | Oct 2015 | A1 |
| 20150319158 | Kumnick | Nov 2015 | A1 |
| 20150332262 | Lingappa | Nov 2015 | A1 |
| 20150356560 | Shastry et al. | Dec 2015 | A1 |
| 20160028550 | Gaddam et al. | Jan 2016 | A1 |
| 20160042263 | Gaddam et al. | Feb 2016 | A1 |
| 20160065370 | Le Saint et al. | Mar 2016 | A1 |
| 20160092696 | Guglani et al. | Mar 2016 | A1 |
| 20160092872 | Prakash et al. | Mar 2016 | A1 |
| 20160103675 | Aabye et al. | Apr 2016 | A1 |
| 20160119296 | Laxminarayanan et al. | Apr 2016 | A1 |
| 20160224976 | Basu | Aug 2016 | A1 |
| 20170046696 | Powell et al. | Feb 2017 | A1 |
| 20170103387 | Weber | Apr 2017 | A1 |
| 20170220818 | Nagasundaram et al. | Aug 2017 | A1 |
| 20170228723 | Taylor | Aug 2017 | A1 |
| Number | Date | Country |
|---|---|---|
| 2156397 | Feb 2010 | EP |
| 2001035304 | May 2001 | WO |
| 2001035304 | May 2001 | WO |
| 2004042536 | May 2004 | WO |
| 2006113834 | Oct 2006 | WO |
| 2009032523 | Mar 2009 | WO |
| 2010078522 | Jul 2010 | WO |
| 2012068078 | May 2012 | WO |
| 2012098556 | Jul 2012 | WO |
| 2012142370 | Oct 2012 | WO |
| 2012167941 | Dec 2012 | WO |
| 2013048538 | Apr 2013 | WO |
| 2013056104 | Apr 2013 | WO |
| 2013119914 | Aug 2013 | WO |
| 2013179271 | Dec 2013 | WO |
| 2015054697 | Apr 2015 | WO |
| Entry |
|---|
| PCI DSS Tokenization Guidelines Information Supplement, Aug. 2011, (hereafter ‘PCI’), https://www.pcisecuritystandards.org/documents/Tokenization_Guidelines_Info_Supplement.pdf, attached as PDF file), (Year: 2011). |
| Verified by VISA, (hereafter VV, https://usa.visa.com/dam/VCOM/download/merchants/verified-by-visa-acquirer-merchant-implementation-guide.pdf, attached as PDF file), (Year: 2011). |
| EMV Payment Tokenisation Specification, (hereafter “EMV”, https://media.scmagazine.com/documents/95/emvco_payment_tokenisation_spe_23619.pdf, attached as PDF file). (Year: 2014). |
| PCI DSS Tokenization Guidelines Information Supplement, Aug. 2011, (hereafter ‘PCI’), https://www.pcisecuritystandards.org/documents/Tokenization_Guidelines_Info_Supplement.pdf, previously attached as PDF file), (Year: 2011). |
| Verified by VISA, (hereafter VV, https://usa.visa.com/dam/VCOM/download/merchants/verified-by-visa-acquirer-merchant-implementation-guide.pdf, previously attached as PDF file), (Year: 2011). |
| EMV Payment Tokenisation Specification, (hereafter “EMV”, https://media.scmagazine.com/documents/95/emvco_payment_tokenisation_spe_23619.pdf, previously attached as PDF file). (Year: 2014). |
| Petition for Inter Partes Review of U.S. Pat. No. 8,533,860 Challenging Claims 1-30 Under 35 U.S.C. § 312 and 37 C.F.R. § 42.104, filed Feb. 17, 2016, Before the USPTO Patent Trial and Appeal Board, IPR 2016-00600, 65 pages. |
| Wang, U.S. Appl. No. 62/000,288 (unpublished), Payment System Canonical Address Format filed May 19, 2014. |
| Sharma et al., U.S. Appl. No. 62/003,717 (unpublished), Mobile Merchant Application filed May 28, 2014. |
| Kalgi et al., U.S. Appl. No. 62/024,426, (unpublished) Secure Transactions Using Mobile Devices filed Jul. 14, 2014. |
| Prakash et al., U.S. Appl. No. 62/037,033 (unpublished), Sharing Payment Token filed Aug. 13, 2014. |
| Hoverson et al., U.S. Appl. No. 62/038,174 (unpublished), Customized Payment Gateway filed Aug. 15, 2014. |
| Wang, U.S. Appl. No. 62/042,050 (unpublished), Payment Device Authentication and Authorization System filed Aug. 26, 2014. |
| Gaddam et al., U.S. Appl. No. 62/053,736 (unpublished), Completing Transactions Without a User Payment Device filed Sep. 22, 2014. |
| Patterson, U.S. Appl. No. 62/054,346 (unpublished), Mirrored Token Vault filed Sep. 23, 2014. |
| Dimmick, U.S. Appl. No. 14/952,514 (unpublished), Systems Communications With Non-Sensitive Identifiers filed Nov. 25, 2015. |
| Dimmick, U.S. Appl. No. 14/952,444 (unpublished), Tokenization Request Via Access Device filed Nov. 25, 2015. |
| Prakash et al., U.S. Appl. No. 14/955,716 (unpublished), Provisioning Platform for Machine-To-Machine Devices filed Dec. 1, 2015. |
| Wong et al., U.S. Appl. No. 14/966,948 (unpublished), Automated Access Data Provisioning filed Dec. 11, 2015. |
| Stubbs et al., U.S. Appl. No. 62/103,522 (unpublished), Methods and Systems for Wallet Provider Provisioning filed Jan. 14, 2015. |
| McGuire, U.S. Appl. No. 14/600,523 (unpublished), Secure Payment Processing Using Authorization Request filed Jan. 20, 2015. |
| Flurscheim et al., U.S. Appl. No. 15/004,705 (unpublished), Cloud-Based Transactions With Magnetic Secure Transmission filed Jan. 22, 2016. |
| Flurscheim et al., U.S. Appl. No. 62/108,403 (unpublished), Wearables With NFC HCE filed Jan. 27, 2015. |
| Sabba et al., U.S. Appl. No. 15/011,366 (unpublished), Token Check Offline filed Jan. 29, 2016. |
| Patterson, U.S. Appl. No. 15/019,157 (unpublished), Token Processing Utilizing Multiple Authorizations filed Feb. 9, 2016. |
| Cash et al., U.S. Appl. No. 15/041,495 (unpublished), Peer Forward Authorization of Digital Requests filed Feb. 11, 2016. |
| Le Saint et al., U.S. Appl. No. 15/008,388 (unpublished), Methods for Secure Credential Provisioning filed Jan. 27, 2016. |
| Kinagi, U.S. Appl. No. 62/117,291 (unpublished), Token and Cryptogram Using Transaction Specific Information filed Feb. 17, 2015. |
| Galland et al. U.S. Appl. No. 62/128,709 (unpublished), Tokenizing Transaction Amounts filed Mar. 5, 2015. |
| Rangarajan et al., U.S. Appl. No. 61/751,763 (unpublished), Payments Bridge filed Jan. 11, 2013. |
| Li, U.S. Appl. No. 61/894,749 (unpublished), Methods and Systems for Authentication and Issuance of Tokens in a Secure Environment filed Oct. 23, 2013. |
| Aissi et al., U.S. Appl. No. 61/738,832 (unpublished), Management of Sensitive Data filed Dec. 18, 2012. |
| Wong et al., U.S. Appl. No. 61/879,362 (unpublished), Systems and Methods for Managing Mobile Cardholder Verification Methods filed Sep. 18, 2013. |
| Powell, U.S. Appl. No. 61/892,407 (unpublished), Issuer Over-The-Air Update Method and System filed Oct. 17, 2013. |
| Powell, U.S. Appl. No. 61/926,236 (unpublished), Methods and Systems for Provisioning Mobile Devices With Payment Credentials and Payment Token Identifiers filed Jan. 10, 2014. |
| Chipman, et al., U.S. Appl. No. 15/265,282 (Unpublished), Self-Cleaning Token Vault, filed Sep. 14, 2016. |
| Lopez, et al., U.S. Appl. No. 15/462,658 (Unpublished), Replacing Token on a Multi-Token User Device, filed Mar. 17, 2017. |
| International Search Report dated Jul. 18, 2016, PCT Application No. PCT/US2016/029586 (13 pages). |
| European Search Report dated Nov. 14, 2018 in Europe Application No. 16787076.5, 8 pages. |
| Number | Date | Country | |
|---|---|---|---|
| 20160321652 A1 | Nov 2016 | US |
