Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Response to Arguments
Applicant’s arguments, see page 1, filed on 02/20/2026, with respect to the rejection(s) of claims 1-5, 7-13, 15-16 and 18-23 under 35 U.S.C. 103 as being unpatentable over Powell et al. (US 20150127547 A1 ---hereinafter—“Powell”) in view of Maddukuri et al. (US 20170255937 A1---hereinafter---" Maddukuri”) have been fully considered and are persuasive. Therefore, the rejection has been withdrawn. However, upon further consideration, a new ground(s) of rejection is made in view of WAGNER (US 20170134375 A1).
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-23 are rejected under 35 U.S.C. 103 as being unpatentable over Powell et al. (US 20150127547 A1 ---hereinafter—“Powell”) in view of WAGNER (US 20170134375 A1) and in further view of Maddukuri et al. (US 20170255937 A1---hereinafter---" Maddukuri”).
As per claim 1: Powell discloses a method comprising:
receiving, by a token requestor computer from a point of interaction device, verification of authentication data, and linking data ([0026] Tokens include surrogate values that replace the Primary Account Numbers (PANs) in a payment ecosystem. Payment tokens may be used to originate payment transactions. [0033] 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. [0041] An "identification and verification (ID&V) method" may be used to ensure that the payment token is replacing a PAN that was legitimately being used by the token requestor. Examples of ID&V methods may include, but are not limited to, an account verification message, a risk score based on assessment of the primary account number (PAN) and use of one time password by the issuer or its agent to verify the account holder. Exemplary ID&V methods may be performed using information such as a user signature, a password, an offline or online personal identification number (PIN), an offline or online enciphered PIN, a combination of offline PIN and signature, a combination of offline enciphered PIN and signature, user biometrics (e.g. voice recognition, fingerprint matching, etc.), a pattern, a glyph, knowledge-based challenge-responses, hardware tokens (multiple solution options), one time passwords (OTPs) with limited use, software tokens, two-channel authentication processes (e.g., via phone), etc. Using the ID&V, a confidence level may be established with respect to the token to PAN binding. [0050] A "token requestor" may refer to an entity that is seeking to implement tokenization according to embodiments of the present invention. The token requestor may initiate a request that a primary account number (PAN) be tokenized by submitting a token request message to the token service provider. According to various embodiments discussed herein, a token requestor may no longer need to store a PAN associated with a token once the requestor have received the token in response to a token request message. The requestor may be an application, a device, a process, or a system that is configured to perform actions associated with tokens. For example, a requestor can request registration with a network token system, request token generation, token activation, token de-activation, token exchange, other token lifecycle management related processes, and/or any other token related processes. A requestor may interface with a network token system through any suitable communication networks and/or protocols (e.g., using HTTPS, SOAP and/or an XML interface among others). Some non-limiting examples of token requestors may include, for example, card-on-file merchants, acquirers, acquirer processors, and payment gateways acting on behalf of merchants, payment enablers (e.g., original equipment manufacturers, mobile network operators, etc.), digital wallet providers, issuers, third party wallet providers, and/or payment processing networks. In some embodiments, a token requestor can request tokens for multiple domains and/or channels. A token requestor may be registered and identified uniquely by the token service provider within the tokenization ecosystem. During token requestor registration, the token service provider may formally process token requestor's application to participate in the token service system. The token service provider may collect information pertaining to the nature of the requestor and relevant use of tokens to validate and formally approve the token requestor and establish appropriate domain restriction controls. Successfully registered token requestors may be assigned a token requestor identifier that may also be entered and maintained within the token vault. Token requestors be revoked or assigned new token requestor identifiers. This information may be subject to reporting and audit by the token service provider);
determining, by the token requestor computer, a token based on the linking data after analyzing the verification of the authentication data ([0040] 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 the 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. The token vault may be a part of the token service system. 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. Token vaults, due to the sensitive nature of the data mappings that are stored and managed in them, may be protected by strong underlying physical and logical security. [0042] A "token assurance level" may refer to an indicator or a value that allows the token service provider to indicate the confidence level of the token to PAN binding. The token assurance level may be determined by the token service provider based on the type of identification and verification (ID&V) performed and the entity that performed the ID&V. The token assurance level may be set when issuing the token. The token assurance level may be updated if additional ID&V is performed);
transmitting, by the token requestor computer to a token service computer, a cryptogram request message ([0135] The payment network 412 acting as the token service provider, may process the transaction. The processing may include interfacing (or interacting) with the token vault 413 to retrieve the PAN represented by the received token. The payment network 412 may verify state of the token-to-PAN mapping in the token vault 413 to ensure that the token is in an active state. The payment network 412 may validate the token cryptogram, when a cryptogram is received in the authorization request message 414. The payment network 412 may also validate the domain restriction controls stored in the token vault 413 for the received token. The payment network 412 may also retrieve from the token vault 413 the token assurance level and data used in generating the token assurance level associated with the received token. The payment network 412 may then modify the authorization request message 414 to generate a modified authorization request message 418. In the modified authorization message, the token may be replaced with the PAN; the token expiry date may be replaced with the PAN expiry date; an indicator may be added to convey to the issuer that an on-behalf-of validation has been completed by the token service provider of the token; and the token-related fields may be passed in the authorization request message. The token-related fields may include the token, token expiry date, token assurance level, token assurance data, and token requestor ID. Upon generating the modified authorization request message 418, the payment network 412 may send the modified authorization request message 418 to the issuer 416);
transmitting, by the token requestor computer, an authorization request message comprising the token to a processor computer ([0060] An "authorization request message" may be an electronic message that is sent to a payment processing network and/or an issuer of a payment account to request authorization for a payment transaction. An authorization request message according to some embodiments may comply with ISO 8583, which is a standard for systems that exchange electronic transaction information associated with a payment made by a consumer using a payment device or a payment account. In some embodiments of the invention, an authorization request message may include a payment token, an expiration date, a token presentment mode, a token requestor identifier, a token cryptogram, a token assurance level, and data used to generate the token assurance level. The payment token may include a payment token issuer identifier that may be a substitute for a real issuer identifier for an issuer. An authorization request message may also comprise additional data elements corresponding to "identification information" including, for example, a service code, a CVV or CVC (card verification value or code), a dCVV or dCVC (dynamic card verification value or code), token cryptogram, an expiration date, etc. An authorization request message may also comprise "transaction information," such as any information associated with a current transaction (e.g. the transaction amount, merchant identifier, merchant location, etc.) as well as any other information that may be utilized in determining whether to identify and/or authorize a payment transaction); and
receiving, by the token requestor computer, an authorization response message from the processor computer ([0100] The payment network 110 may receive an authorization response message from the issuer computer 170 and forward the received authorization response message to the acquirer 108. In some embodiments, the payment network 110 may modify the authorization response message received from the issuer 104 before forwarding the authorization response message to the acquirer 108. For example, the payment network 110 may modify the authorization response message to remove the PAN (e.g. replace the PAN with the token), if the PAN was included in the authorization response message and may include the last 4 digits of the PAN in the authorization response message);
wherein the processor computer is programmed to modify the authorization request message by at least replacing the token with the credential to form a modified authorization request message and forward the modified authorization request message to an authorizing entity computer, which is programmed to generate the authorization response message ( [0124] The payment network 312 may verify the state of token-to-PAN mapping in the token vault 313 to ensure that the token is in an active state. The payment network 312 may validate the token cryptogram received in the authorization request message 314. The payment network 312 may also validate the domain restriction controls stored in the token vault 313 for the received token. The payment network 312 may also retrieve from the token vault 313 the token assurance level and data used in generating the token assurance level associated with the received token. The payment network 312 may then modify the authorization request message 314 to generate a modified authorization request message 318. [0135] In the modified authorization message, the token may be replaced with the PAN in data field F2; the token expiry date may be replaced with the PAN expiry date in data field F14. The payment network 412 may then modify the authorization request message 414 to generate a modified authorization request message 418. In the modified authorization message, the token may be replaced with the PAN; the token expiry date may be replaced with the PAN expiry date; an indicator may be added to convey to the issuer that an on-behalf-of validation has been completed by the token service provider of the token; and the token-related fields may be passed in the authorization request message. The token-related fields may include the token, token expiry date, token assurance level, token assurance data, and token requestor ID. Upon generating the modified authorization request message 418, the payment network 412 may send the modified authorization request message 418 to the issuer 416).
Powell does not explicitly disclose the linking data uniquely identifying a linkage between the authentication data and a credential and being a string of alphanumeric characters, the authentication data comprising biometric data and the credential comprising a primary account number. WAGNER, in analogous art however, discloses…... the linking data uniquely identifying a linkage between the authentication data and a credential and being a string of alphanumeric characters, the authentication data comprising biometric data and the credential comprising a primary account number ([0029] “Biometric data” includes data that can be used to uniquely identify an individual based upon one or more intrinsic physical or behavioral traits. For example, biometric data may include fingerprint data and retinal scan data. Further examples of biometric data include digital photographic data (e.g., facial recognition data), deoxyribonucleic acid (DNA) data, palm print data, hand geometry data, and iris recognition data. [0030] A “biometric template” can be a digital reference of distinct characteristics that have been extracted from a biometric sample provided by a user. Biometric templates are used during the biometric authentication process. Data from a biometric sample provided by a user at the time of authentication can be compared against the biometric template to determine whether the provided biometric sample closely matches the biometric template. [0032] “User identifying information” can be any information associated with a user and that can identify the user. User identifying information can include, but is not limited to, a primary account number (PAN), telephone, e-mail address, zip code, mailing address, photo identification, personal identification number (PIN), etc.
WAGNER further discloses the above limitation in ([0053] At step s3, after the user provides some user identifying information to the access device 130, the access device 130 may generate a point-of-sale (PoS) transaction ID (PoStx_ID) and transmit the PoS transaction ID, user identifying information, and an identifier of a matcher computer 220 (ID_Matcher) associated with the access device 130 or merchant, to the ID manager computer 170. The identifier of the matcher computer 220 can be a Uniform Resource Locator (URL) that points to the matcher computer 220. The transmission of the information from the access device 130 to the ID manager computer 170 may be encrypted with a public key of the ID manager computer 170. Alternatively, transport layer security (TLS) may be used where the ID manager computer 170 has authenticated, to ensure that the personally identifiable information (PII) data is only sent to a legitimate party. [0054] At step s4, the ID manager computer 170 may generate a transaction ID (e.g., tx_ID) specific to the transaction taking place. The ID manager computer 170 may transmit the generated transaction ID along with the PoS transaction id (PoS_tx_ID) to the to the access device 130, such that the access device 130 is aware of which transaction ID to associate with the current transaction. The generated transaction ID may be a large random number, big enough that there probability of reusing the same transaction ID is greatly reduced. In some embodiments, the generated transaction ID may be 20 bytes in length)
Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to modify the above claimed limitations disclosed by Powell to include he linking data uniquely identifying a linkage between the authentication data and a credential and being a string of alphanumeric characters, the authentication data comprising biometric data and the credential comprising a primary account number. This modification would have been obvious because a person having ordinary skill in the art would have been motivated by the desire to provide a server-side biometric authentication system that is split data knowledge and processes, so that extensive collusion would be required in order for a fraudster to compromise the system as suggested by WAGNER ([0004-0006…….).
Powell and WAGNER do not explicitly disclose transmitting, by the token requestor computer, the authorization request message including a cryptogram and receiving, by the token requestor computer from the token service computer, the cryptogram associated with the token. Maddukuri, in analogous art however, discloses transmitting, by the token requestor computer, the authorization request message including a cryptogram and receiving, by the token requestor computer from the token service computer, the cryptogram associated with the token ([0020] Issuer authorization system 128 may compute payment cryptograms and/or run a risk assessment of the transaction. Issuer authorization system 128 may decline a transaction or a tokenization request in response to an incorrect cryptogram and/or an unfavorable risk assessment, as described in greater detail below. [0021] System 90 may further include a payment network 120 in electronic communication with merchant 130 and/or token requestor 110. Payment network may provide an orchestration layer 122 serving as a communication point for token requestor systems 112 for both token provisioning as well as payment support using tokens. Orchestration layer 122 may thus include an API interface that returns a token and/or cryptogram in response to requests made by token requestor systems 112, as discussed in greater detail below. Orchestration layer 122 may pass data and/or requests to payment network systems 124 for processing. Payment network systems 124 may perform risk assessment, token generation, cryptogram generation, and otherwise support token-based payments. [0024] In various embodiments, token requestor systems 112 may receive the transaction account details for use in further communication with payment network 120 and merchant 130. Token requestor systems 112 may securely transmit a request for a payment payload and/or tokenization to a payment network 120 (Step 204). Token requestor systems 112 may transmit the request by way of orchestration layer 122. [0037] In various embodiments, the one-time-use cryptogram may be generated by payment network 120 on cloud payment network systems 122 (e.g., a payment network cloud) using the token and transaction information received from token requestor 110. Tokens may be deleted for the card issuer and payment network in response to card cancellation and/or token-requestor-triggered token cancellation. Payment network 110 may send the payment payload in an encrypted form in the response to aggregate API calls made by token requestor 110). Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to modify the claimed limitations of the token requestor computer from the token service computer disclosed by Powell and WAGNER to include transmitting, by the token requestor computer, the authorization request message including a cryptogram and receiving, by the token requestor computer from the token service computer, the cryptogram associated with the token. This modification would have been obvious because a person having ordinary skill in the art would have been motivated by the desire to provide a system that assess a risk of fraud associated with transaction account and payment transaction that may return a payment payload in response to a favorable risk assessment. The payment payload may be passed to a merchant and from the merchant to a payment network for evaluation. The payment transaction may be approved or declined based on the contents of the received payment payload matching the contents of a generated payment payload as suggested by Maddukuri (0003).
As per claim 2. Powell in view of WAGNER in further view of Maddukuri discloses the method of claim 1, wherein the the point of interaction device (Powell: [0041] Exemplary ID&V methods may be performed using information such as a user signature, a password, an offline or online personal identification number (PIN), an offline or online enciphered PIN, a combination of offline PIN and signature, a combination of offline enciphered PIN and signature, user biometrics (e.g. voice recognition, fingerprint matching, etc.), a pattern, a glyph, knowledge-based challenge-responses, hardware tokens (multiple solution options), one time passwords (OTPs) with limited use, software tokens, two-channel authentication processes (e.g., via phone), etc. Using the ID&V, a confidence level may be established with respect to the token to PAN binding).
As per claim 3. Powell in view of WAGNER in further view of Maddukuri discloses the method of claim 1, further comprising: receiving, by the token requestor computer from the point of interaction device, interaction data along with the authentication data and the linking data (Powell [0122] The mobile device 302 may pass the contactless transaction 306 including the foregoing data fields to the merchant point-of-sale terminal 304 via an NFC interface. The merchant terminal 304 may send an authorization request message 310 to the acquirer 308. The authorization request message 310 sent by the merchant terminal 304 to the acquirer 308 may include the same data elements as the contactless transaction 306 sent by the mobile device 302 to the merchant terminal 304. [0124] The payment network 312 acting as the token service provider, may process the token transaction. The processing may include interfacing (or interacting) with the token vault 313 to retrieve the PAN represented by the received token. The payment network 312 may verify the state of token-to-PAN mapping in the token vault 313 to ensure that the token is in an active state. The payment network 312 may validate the token cryptogram received in the authorization request message 314. The payment network 312 may also validate the domain restriction controls stored in the token vault 313 for the received token. The payment network 312 may also retrieve from the token vault 313 the token assurance level and data used in generating the token assurance level associated with the received token. The payment network 312 may then modify the authorization request message 314 to generate a modified authorization request message 318).
As per claim 4. Powell in view of WAGNER in further view of Maddukuri discloses the method of claim 3, wherein the interaction data was obtained by the point of interaction device from an access device operated by a resource provider that conducts an interaction with a user interacting with the point of interaction device (Powell [0122] The mobile device 302 may pass the contactless transaction 306 including the foregoing data fields to the merchant point-of-sale terminal 304 via an NFC interface. The merchant terminal 304 may send an authorization request message 310 to the acquirer 308. The authorization request message 310 sent by the merchant terminal 304 to the acquirer 308 may include the same data elements as the contactless transaction 306 sent by the mobile device 302 to the merchant terminal 304).
As per claim 5. Powell in view of WAGNER in further view of Maddukuri discloses the method of claim 4, further comprising: providing, by the token requestor computer, a notification regarding the authorization response message after receiving the authorization response message from the processing computer (Powell [0153] The authorization response message 619 and the modified authorization response message 620 (and 622) may indicate whether the issuer 616 approved the transaction initiated by the account holder 602. After the authentication response message 622 is provided to the merchant terminal 604, the account holder may be notified of the success or failure of the transaction).
As per claim 7. Powell in view of WAGNER in further view of Maddukuri discloses the method of claim 1, wherein the point of interaction device provided authentication data to an identity service provider computer and received the verification of the authentication data before the token requestor computer receives the verification of the authentication data from the point of interaction device (Powell [0085] The account verification may represent an ID&V assurance method which provides a basic account verification check to validate if the PAN is active and valid. In various embodiments, the account verification may include: $0 authorization, card verification number validation, and postal code and address verification. The account verification method may be performed, for example, by the token requestor 114 and reported to the token service provider 116 through token service API. The account verification method may also be performed by the token service provider 116 at the time of the token issuance. When a token is issued by performing account verification at the time of token issuance, the token assurance level may indicate (e.g. the token assurance level value may be set to) "token requestor verification performed" or "token requestor assured".
As per claim 8. Powell in view of WAGNER in further view of Maddukuri discloses the method of claim 1, wherein the point of interaction device is a mobile phone (Powell [0132] When a transaction is initiated, a merchant application/digital wallet in a mobile device of the account holder 402 may interact with a payment application to pass data elements to the merchant 404 in a payment transaction request message 406).
As per claim 9. Powell in view of WAGNER in further view of Maddukuri discloses the method of claim 1, wherein the cryptogram request message comprises the token (Maddukuri [0021] System 90 may further include a payment network 120 in electronic communication with merchant 130 and/or token requestor 110. Payment network may provide an orchestration layer 122 serving as a communication point for token requestor systems 112 for both token provisioning as well as payment support using tokens. Orchestration layer 122 may thus include an API interface that returns a token and/or cryptogram in response to requests made by token requestor systems 112).
As per claim 10. Powell in view of WAGNER in further view of Maddukuri discloses the method of claim 1, wherein the biometric is of a user operating the point of interaction device (Maddukuri [0082] Phrases and terms similar to “account”, “account number”, “account code” or “consumer account” as used herein, may include any device, code (e.g., one or more of an authorization/access code, personal identification number (“PIN”), Internet code, other identification code, and/or the like), number, letter, symbol, digital certificate, smart chip, digital signal, analog signal, biometric or other identifier/indicia suitably configured to allow the consumer to access, interact with or communicate with the system. The account number may optionally be located on or associated with a rewards account, charge account, credit account, debit account, prepaid account, telephone card, embossed card, smart card, magnetic stripe card, bar code card, transponder, radio frequency card or an associated account).
As per claim 11. Powell in view of WAGNER in further view of Maddukuri discloses the method of claim 1, wherein the point of interaction device provided authentication data to an identity service provider computer and received the verification of the authentication data before the token requestor computer receives the verification of the authentication data from the point of interaction device, and (Powell [0171] As discussed above, the token service provider 904 may provide an interface 912 that a registered token requestor 902 can use to submit a token request message including original payment credentials and receive a token response message including a token from the token service provider 904. The token request message and the token response message may be passed between the token requestor 902 and the token service provider 904 through the token request and issuance interface 912);
wherein the method further comprises, before the token requestor computer receives the verification of the authentication data, and the linking data: (Powell [0060] An authorization request message may also comprise additional data elements corresponding to "identification information" including, for example, a service code, a CVV or CVC (card verification value or code), a dCVV or dCVC (dynamic card verification value or code), token cryptogram, an expiration date, etc);
receiving, by the token requestor computer from the identity service provider computer, the linking data and a credential (Powell [0046] The token attributes may identify a type of token indicating how the token may be used. A payment token may include a high value token that can be used in place of a real account identifier (e.g., PAN) to generate original and/or subsequent transactions for a consumer account and/or card. Another token type may be a "static" or "dynamic" token type for static and dynamic tokens, respectively);
transmitting, by the token requestor computer to the token service computer, the credential (Powell [0033] 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); and
receiving, by the token requestor computer from the token service computer, the token (Powell [0038] A "token service system" refers to a system that facilitates requesting, generating and issuing tokens, as well as maintaining an established mapping of tokens to primary account numbers (PANs) in a repository (e.g. token vault). The token service system may establish a token assurance level for a given token to indicate the confidence level of the token to PAN binding. The token service system may support token processing of payment transactions submitted using tokens by de-tokenizing the token to obtain the actual PAN. In various embodiments, the token service system may include a token requestor and a token service provider interacting with the token requestor).
As per claim 12. Powell in view of WAGNER in further view of Maddukuri discloses the method of claim 11, further comprising: storing the token (Powell [0040] 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 the 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. The token vault may be a part of the token service system. 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. Token vaults, due to the sensitive nature of the data mappings that are stored and managed in them, may be protected by strong underlying physical and logical security).
As per claim 13. Powell in view of WAGNER in further view of Maddukuri discloses the method of claim 1, wherein the token requestor computer is a cloud based computer system (Powell [0062] A "server computer" may typically be a powerful computer or cluster of computers. For example, the server computer can be a large mainframe, a minicomputer cluster, or a group of servers functioning as a unit. The server computer may be associated with an entity such as a payment processing network, a wallet provider, a merchant, an authentication cloud, an acquirer or an issuer Powell [0103] For example, in some embodiments, a mobile device may be used to initiate a remote transaction with a token provisioned onto a secure element, other secure memory of the mobile device, or in "the cloud" such as with host card emulation).
As per claim 15. Claim 15 is directed to a token requestor computer comprising: a processor; and a non-transitory computer readable medium, the non-transitory computer readable medium comprising code executable by the processor to perform a method having substantially similar corresponding limitation features of claim 1 and therefore, claim 15 is rejected with the same rationale given above to reject claim 1.
As per claim 16. Powell discloses a method, comprising:
receiving, by a point of interaction device (Figure 3: 302 NFC Device with 305 POS, Merchant Terminal; Figure 6: 602 Mobile QRC with 604 Merchant Terminal), authentication data from a user ([0026] Tokens include surrogate values that replace the Primary Account Numbers (PANs) in a payment ecosystem. Payment tokens may be used to originate payment transactions. [0033] 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 ([0119] Use Case 1: Mobile NFC at Point of Sale. [0120] Referring now to FIG. 3, the mobile NFC at point-of-sale use case 300 refers to using a NFC-enabled mobile device 302 to initiate contactless payment at a merchant terminal 302. The mobile device 302 may be provisioned with a token that is stored within a secure memory, such as a secure element, of the mobile device 302. According to various embodiments, the token provisioning may be accomplished by the token requestor interfacing with the token service provider, as discussed above. [0121] When a transaction is initiated, the mobile device 302 may generate a contactless transaction 306 including the token, token expiry date, token cryptogram, and other chip data elements. These data elements may be included in the contactless transaction 306 at dedicated data fields, as illustrated in FIG. 3. According to various embodiments, the mobile device 302 may pass the token data elements to the merchant terminal 304 as follows: token may be passed in the PAN data field F2; token expiry date may be passed in the PAN expiry date data field F14; token cryptogram may be generated based on the token data elements and may be passed in the chip cryptogram data field F55; token presentment mode may be set to a POS entry mode for contactless transactions in data field F22; and all other contactless data elements may be created and passed following typical contactless communications. The token cryptogram generated from the mobile device 302 may serve as the domain restriction control field that may be used by the token service provider to validate the integrity of the transaction using the token). [0146] Use Case 4: Scan at Point of Sale);
initiating, by the point of interaction device (Figure 3: 302 NFC Device with 305 POS, Merchant Terminal; Figure 6: 602 Mobile QRC with 604 Merchant Terminal), verifying the authentication data with an identity service provider computer ([0041] An "identification and verification (ID&V) method" may be used to ensure that the payment token is replacing a PAN that was legitimately being used by the token requestor. Examples of ID&V methods may include, but are not limited to, an account verification message, a risk score based on assessment of the primary account number (PAN) and use of one time password by the issuer or its agent to verify the account holder. Exemplary ID&V methods may be performed using information such as a user signature, a password, an offline or online personal identification number (PIN), an offline or online enciphered PIN, a combination of offline PIN and signature, a combination of offline enciphered PIN and signature, user biometrics (e.g. voice recognition, fingerprint matching, etc.), a pattern, a glyph, knowledge-based challenge-responses, hardware tokens (multiple solution options), one time passwords (OTPs) with limited use, software tokens, two-channel authentication processes (e.g., via phone), etc. Using the ID&V, a confidence level may be established with respect to the token to PAN binding. [0050] A "token requestor" may refer to an entity that is seeking to implement tokenization according to embodiments of the present invention. The token requestor may initiate a request that a primary account number (PAN) be tokenized by submitting a token request message to the token service provider. According to various embodiments discussed herein, a token requestor may no longer need to store a PAN associated with a token once the requestor have received the token in response to a token request message. The requestor may be an application, a device, a process, or a system that is configured to perform actions associated with tokens. For example, a requestor can request registration with a network token system, request token generation, token activation, token de-activation, token exchange, other token lifecycle management related processes, and/or any other token related processes. A requestor may interface with a network token system through any suitable communication networks and/or protocols (e.g., using HTTPS, SOAP and/or an XML interface among others). Some non-limiting examples of token requestors may include, for example, card-on-file merchants, acquirers, acquirer processors, and payment gateways acting on behalf of merchants, payment enablers (e.g., original equipment manufacturers, mobile network operators, etc.), digital wallet providers, issuers, third party wallet providers, and/or payment processing networks. In some embodiments, a token requestor can request tokens for multiple domains and/or channels. A token requestor may be registered and identified uniquely by the token service provider within the tokenization ecosystem. During token requestor registration, the token service provider may formally process token requestor's application to participate in the token service system. The token service provider may collect information pertaining to the nature of the requestor and relevant use of tokens to validate and formally approve the token requestor and establish appropriate domain restriction controls. Successfully registered token requestors may be assigned a token requestor identifier that may also be entered and maintained within the token vault. Token requestors be revoked or assigned new token requestor identifiers. This information may be subject to reporting and audit by the token service provider);
receiving, by the point of interaction device (Figure 3: 302 NFC Device with 305 POS, Merchant Terminal; Figure 6: 602 Mobile QRC with 604 Merchant Terminal), verification of the authentication data and linking data associated with the authentication data ([0040] 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 the 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. The token vault may be a part of the token service system. 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. Token vaults, due to the sensitive nature of the data mappings that are stored and managed in them, may be protected by strong underlying physical and logical security. [0042] A "token assurance level" may refer to an indicator or a value that allows the token service provider to indicate the confidence level of the token to PAN binding. The token assurance level may be determined by the token service provider based on the type of identification and verification (ID&V) performed and the entity that performed the ID&V. The token assurance level may be set when issuing the token. The token assurance level may be updated if additional ID&V is performed); and
providing, by the point of interaction device (Figure 3: 302 NFC Device with 305 POS, Merchant Terminal; Figure 6: 602 Mobile QRC with 604 Merchant Terminal), the verification of the authentication data, and the linking data to a token requestor computer ([0042] A "token assurance level" may refer to an indicator or a value that allows the token service provider to indicate the confidence level of the token to PAN binding. The token assurance level may be determined by the token service provider based on the type of identification and verification (ID&V) performed and the entity that performed the ID&V. The token assurance level may be set when issuing the token. The token assurance level may be updated if additional ID&V is performed),
wherein the token requestor computer determines a token based on the linking data after analyzing the verification of the authentication data ([0060] An "authorization request message" may be an electronic message that is sent to a payment processing network and/or an issuer of a payment account to request authorization for a payment transaction. An authorization request message according to some embodiments may comply with ISO 8583, which is a standard for systems that exchange electronic transaction information associated with a payment made by a consumer using a payment device or a payment account. In some embodiments of the invention, an authorization request message may include a payment token, an expiration date, a token presentment mode, a token requestor identifier, a token cryptogram, a token assurance level, and data used to generate the token assurance level. The payment token may include a payment token issuer identifier that may be a substitute for a real issuer identifier for an issuer. An authorization request message may also comprise additional data elements corresponding to "identification information" including, for example, a service code, a CVV or CVC (card verification value or code), a dCVV or dCVC (dynamic card verification value or code), token cryptogram, an expiration date, etc. An authorization request message may also comprise "transaction information," such as any information associated with a current transaction (e.g. the transaction amount, merchant identifier, merchant location, etc.) as well as any other information that may be utilized in determining whether to identify and/or authorize a payment transaction); and
transmits an authorization request message comprising the token and the cryptogram to a processor computer ([0100] The payment network 110 may receive an authorization response message from the issuer computer 170 and forward the received authorization response message to the acquirer 108. In some embodiments, the payment network 110 may modify the authorization response message received from the issuer 104 before forwarding the authorization response message to the acquirer 108. For example, the payment network 110 may modify the authorization response message to remove the PAN (e.g. replace the PAN with the token), if the PAN was included in the authorization response message and may include the last 4 digits of the PAN in the authorization response message).
Powell does not explicitly disclose the linking data uniquely identifying a linkage between the authentication data and a credential and being a string of alphanumeric characters, the authentication data comprising biometric data and the credential comprising a primary account number. WAGNER, in analogous art however, discloses…... the linking data uniquely identifying a linkage between the authentication data and a credential and being a string of alphanumeric characters, the authentication data comprising biometric data and the credential comprising a primary account number ([0029] “Biometric data” includes data that can be used to uniquely identify an individual based upon one or more intrinsic physical or behavioral traits. For example, biometric data may include fingerprint data and retinal scan data. Further examples of biometric data include digital photographic data (e.g., facial recognition data), deoxyribonucleic acid (DNA) data, palm print data, hand geometry data, and iris recognition data. [0030] A “biometric template” can be a digital reference of distinct characteristics that have been extracted from a biometric sample provided by a user. Biometric templates are used during the biometric authentication process. Data from a biometric sample provided by a user at the time of authentication can be compared against the biometric template to determine whether the provided biometric sample closely matches the biometric template. [0032] “User identifying information” can be any information associated with a user and that can identify the user. User identifying information can include, but is not limited to, a primary account number (PAN), telephone, e-mail address, zip code, mailing address, photo identification, personal identification number (PIN), etc.
WAGNER further discloses the above limitation in ([0053] At step s3, after the user provides some user identifying information to the access device 130, the access device 130 may generate a point-of-sale (PoS) transaction ID (PoStx_ID) and transmit the PoS transaction ID, user identifying information, and an identifier of a matcher computer 220 (ID_Matcher) associated with the access device 130 or merchant, to the ID manager computer 170. The identifier of the matcher computer 220 can be a Uniform Resource Locator (URL) that points to the matcher computer 220. The transmission of the information from the access device 130 to the ID manager computer 170 may be encrypted with a public key of the ID manager computer 170. Alternatively, transport layer security (TLS) may be used where the ID manager computer 170 has authenticated, to ensure that the personally identifiable information (PII) data is only sent to a legitimate party. [0054] At step s4, the ID manager computer 170 may generate a transaction ID (e.g., tx_ID) specific to the transaction taking place. The ID manager computer 170 may transmit the generated transaction ID along with the PoS transaction id (PoS_tx_ID) to the to the access device 130, such that the access device 130 is aware of which transaction ID to associate with the current transaction. The generated transaction ID may be a large random number, big enough that there probability of reusing the same transaction ID is greatly reduced. In some embodiments, the generated transaction ID may be 20 bytes in length)
Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to modify the above claimed limitations disclosed by Powell to include he linking data uniquely identifying a linkage between the authentication data and a credential and being a string of alphanumeric characters, the authentication data comprising biometric data and the credential comprising a primary account number. This modification would have been obvious because a person having ordinary skill in the art would have been motivated by the desire to provide a server-side biometric authentication system that is split data knowledge and processes, so that extensive collusion would be required in order for a fraudster to compromise the system as suggested by WAGNER ([0004-0006…….).
Powell and WAGNER do not explicitly disclose requests and receives a cryptogram associated with the token from a token service computer. Maddukuri, in analogous art however, discloses requests and receives a cryptogram associated with the token from a token service computer ([0020] Issuer authorization system 128 may compute payment cryptograms and/or run a risk assessment of the transaction. Issuer authorization system 128 may decline a transaction or a tokenization request in response to an incorrect cryptogram and/or an unfavorable risk assessment, as described in greater detail below. [0021] System 90 may further include a payment network 120 in electronic communication with merchant 130 and/or token requestor 110. Payment network may provide an orchestration layer 122 serving as a communication point for token requestor systems 112 for both token provisioning as well as payment support using tokens. Orchestration layer 122 may thus include an API interface that returns a token and/or cryptogram in response to requests made by token requestor systems 112, as discussed in greater detail below. Orchestration layer 122 may pass data and/or requests to payment network systems 124 for processing. Payment network systems 124 may perform risk assessment, token generation, cryptogram generation, and otherwise support token-based payments. [0024] In various embodiments, token requestor systems 112 may receive the transaction account details for use in further communication with payment network 120 and merchant 130. Token requestor systems 112 may securely transmit a request for a payment payload and/or tokenization to a payment network 120 (Step 204). Token requestor systems 112 may transmit the request by way of orchestration layer 122. [0037] In various embodiments, the one-time-use cryptogram may be generated by payment network 120 on cloud payment network systems 122 (e.g., a payment network cloud) using the token and transaction information received from token requestor 110. Tokens may be deleted for the card issuer and payment network in response to card cancellation and/or token-requestor-triggered token cancellation. Payment network 110 may send the payment payload in an encrypted form in the response to aggregate API calls made by token requestor 110). Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to modify the claimed limitations of the token requestor computer from the token service computer disclosed by Powell and WAGNER to include requests and receives a cryptogram associated with the token from a token service computer. This modification would have been obvious because a person having ordinary skill in the art would have been motivated by the desire to provide a system that assess a risk of fraud associated with transaction account and payment transaction that may return a payment payload in response to a favorable risk assessment. The payment payload may be passed to a merchant and from the merchant to a payment network for evaluation. The payment transaction may be approved or declined based on the contents of the received payment payload matching the contents of a generated payment payload as suggested by Maddukuri (0003).
As per claim 18. Powell in view of Maddukuri discloses the method of claim 16, further comprising: receiving, by the point of interaction device, interaction data from an access device, and providing the interaction data along with the authentication data and the linking data to the token requestor computer (Powell [0122] The mobile device 302 may pass the contactless transaction 306 including the foregoing data fields to the merchant point-of-sale terminal 304 via an NFC interface. The merchant terminal 304 may send an authorization request message 310 to the acquirer 308. The authorization request message 310 sent by the merchant terminal 304 to the acquirer 308 may include the same data elements as the contactless transaction 306 sent by the mobile device 302 to the merchant terminal 304. [0124] The payment network 312 acting as the token service provider, may process the token transaction. The processing may include interfacing (or interacting) with the token vault 313 to retrieve the PAN represented by the received token. The payment network 312 may verify the state of token-to-PAN mapping in the token vault 313 to ensure that the token is in an active state. The payment network 312 may validate the token cryptogram received in the authorization request message 314. The payment network 312 may also validate the domain restriction controls stored in the token vault 313 for the received token. The payment network 312 may also retrieve from the token vault 313 the token assurance level and data used in generating the token assurance level associated with the received token. The payment network 312 may then modify the authorization request message 314 to generate a modified authorization request message 318).
As per claim 19. Powell in view of Maddukuri discloses the method of claim 18, further comprising: initiating communication with the access device prior to receiving the interaction data from the access device (Powell [0085] The account verification may represent an ID&V assurance method which provides a basic account verification check to validate if the PAN is active and valid. In various embodiments, the account verification may include: $0 authorization, card verification number validation, and postal code and address verification. The account verification method may be performed, for example, by the token requestor 114 and reported to the token service provider 116 through token service API. The account verification method may also be performed by the token service provider 116 at the time of the token issuance. When a token is issued by performing account verification at the time of token issuance, the token assurance level may indicate (e.g. the token assurance level value may be set to) "token requestor verification performed" or "token requestor assured").
As per claim 20. Powell in view of WAGNER in further view of Maddukuri discloses method of claim 19, wherein the access device provides access to a resource (Powell [0062] A "server computer" may typically be a powerful computer or cluster of computers. For example, the server computer can be a large mainframe, a minicomputer cluster, or a group of servers functioning as a unit. The server computer may be associated with an entity such as a payment processing network, a wallet provider, a merchant, an authentication cloud, an acquirer or an issuer Powell [0103] For example, in some embodiments, a mobile device may be used to initiate a remote transaction with a token provisioned onto a secure element, other secure memory of the mobile device, or in "the cloud" such as with host card emulation).
As per claim 21: Powell in view of WAGNER in further view of Maddukuri discloses the method of claim 20, wherein the resource is a good or a service (WAGNER [0024] A “payment processing network” (e.g., VisaNet™) may include data processing subsystems, networks, and operations used to support and deliver authorization services, exception file services, and clearing and settlement services. An exemplary payment processing network may include VisaNet™. Payment processing networks such as VisaNet™ are able to process credit card transactions, debit card transactions, and other types of commercial transactions. VisaNet™ in particular, includes a VIP system (Visa Integrated Payments system) which processes authorization requests and a Base II system which performs clearing and settlement services).
As per claim 22: Powell in view of WAGNER in further view of Maddukuri discloses the method of claim 1, wherein the authorization request message comprises a transaction amount and is for a payment transaction ( WAGNER [0023] A “payment device” may include any suitable device capable of making a payment. For example, a payment device can include a card including a credit card, debit card, charge card, gift card, or any combination thereof. A payment device can be used in conjunction with a consumer device, as further defined below).
As per claim 23: Powell in view of WAGNER in further view of Maddukuri discloses the method of claim 1, wherein the biometric data comprises a face image (WAGNER [0029] “Biometric data” includes data that can be used to uniquely identify an individual based upon one or more intrinsic physical or behavioral traits. For example, biometric data may include fingerprint data and retinal scan data. Further examples of biometric data include digital photographic data (e.g., facial recognition data), deoxyribonucleic acid (DNA) data, palm print data, hand geometry data, and iris recognition data).
BRI (Broadest Reasonable Interpretation) Considerations
The above claims under examination have been given to them their BRI considerations consistent with the applicant’s disclosure as they would be interpreted by ordinary skill in the art (POSITA) at the time of filing of the invention. In order to construe, appraise boundary and scope of the claimed limitations, the following claim words or terms or phrases or languages have been given to them their BRI considerations and context in view of the applicant’s disclosure. For record clarity, BRI for the following claim words or terms or phrases or languages, the examiner recites descriptions from the applicant’s disclosure as follows:
A Point-of-Interaction device [Applicant’s Disclosure: [0018] A “user device” may be any suitable device operated by a user. User devices may be in any suitable form. Some examples of user devices include cellular phones, smartphones, mobile phones, PDAs, personal computers (PCs), tablet computers, and the like. In some embodiments, where a user device is a mobile device, the mobile device may include a display, a memory, a processor, a computer-readable medium, and any other suitable component. Specific examples of user devices can include a point of interaction device or biometric enrollment device. A point-of-interaction device can be a user device that is used at a point of interaction or can be a user device that initiates an interaction. A biometric enrollment device can be a device that can be used to enroll a biometric into an interaction processing system.
Cryptogram [Applicant’s Disclosure: 0040] A “cryptogram” may include an encrypted representation of some information. A cryptogram may include a token authentication verification value (TAVV) associated with a token. A cryptogram can be used by a recipient to determine if the generator of the cryptogram is in possession of a proper key, for example, by encrypting the underlying information with a valid key, and comparing the result to the received cryptogram. A cryptogram may include encrypted characters. Cryptograms can be of any suitable length and may be formed using any suitable data transformation process. Exemplary data transformation processes include encryption, and encryption processes such as DES, triple DES, AES, and ECC may be used. Keys used with such encryption process can be of any appropriate length and may have any suitable characteristics. In some embodiments, a cryptogram may include encrypted token data associated with a token (e.g., a token domain, a token expiry date, etc.). In some embodiments, a cryptogram may be used to validate the token. For example, a cryptogram may be used to validate that the token is being used within a token domain and/or by a token expiry date associated with the token. In some embodiments, a cryptogram may be used in a payment process, and may be generated by a card or device with the unique derivation key (UDK) or a limited-use key (LUK) and additional information (e.g., a primary account number, token, and/or information from a chip and point-of-sale (POS)). Different types of payment cryptograms can be used in different settings.
Conclusion
The prior arts made of record and not relied upon are considered pertinent to applicant's disclosure. See the notice of reference cited in form PTO-892 for additional prior arts.
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Contact Information
Any inquiry concerning this communication or earlier communications from the examiner should be directed to TECHANE GERGISO whose telephone number is (571)272-3784. The examiner can normally be reached 9:30am to 6:30pm.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, LINGLAN EDWARDS can be reached at (571) 270-5440. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/TECHANE GERGISO/Primary Examiner, Art Unit 2408