DETAILED ACTION
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 .
Status of Claims
The following is a Non-Final Office Action in response to applicant’s filing on April 28, 2025. Claims 1-20 are pending, of which claims 1, 11 and 19 are in independent form.
Specification
The specification is objected to because in paragraph [0003] “…hacking attacks of they are stored…” should change to “…hacking attacks if they are stored…”. Proper correction is required.
Claim Rejections - 35 USC § 103
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-8, 10-11, 13, 15-18 are rejected under 35 U.S.C. 103 as being unpatentable over Narayan et al. (US 10,664,844 B2), hereinafter Narayan in view of Lindelsee et al. (US 2011/0178927 A1), hereinafter Lindelsee.
Regarding claim 1, Narayan discloses a method comprising:
receiving, by a sending entity computer from a user, a request for an interaction with a resource provider (Narayan, Col. 8, Lines 20-24, an “authorization request message” may be an electronic message that requests authorization for a transaction. In some embodiments, it is sent to a transaction processing computer and/or an issuer of a payment card to request authorization for a transaction), the request comprising a resource provider identifier associated with the resource provider (Narayan, Col. 8, Lines 29-45, the authorization request message may include an issuer account identifier that may be associated with a payment device or payment account… An authorization request message may also comprise “transaction information,” such as any information associated with a current transaction, such as the transaction amount, merchant identifier, merchant location, acquirer bank identification number (BIN), card acceptor ID, information identifying items being purchased, etc., as well as any other information that may be utilized in determining whether to identify and/or authorize a transaction);
receiving, by the sending entity computer from the alias directory, a resolve response message comprising a token and a key (Narayan, Col. 4, Lines 35-45, this involves storing a cryptogram and/or multiple encryption keys for each token transaction, as well as passing a cryptogram in authorization request messages. In some embodiments, a cryptogram may be a large string of data, such as a string of 40 characters. Storing cryptograms and/or specific keys for each transaction can create a need for a large storage database. In contrast, embodiments of the invention allow the central token provider to store as little as a dynamic data element for each transaction. A dynamic data element can be 1-5 characters, or any other suitable length), the key derived from a plurality of data elements associated with the interaction (Narayan, Col. 18, Lines 14-27, FIG. 6 shows the methodology for deriving two unique keys which can be utilized in the preferred embodiment. The payment token 201… the concatenated value 210 may be padded with zeroes, or some other value 211, to create a string of a predetermined fixed length. In a preferred embodiment, the concatenated value 210 may be 128 bits in length, although the concatenated value is not limited to being this length. The concatenated value 210 may then be encrypted 220 using the master derivation key 221 as the encryption key for each encryption stage);
transmitting, by the sending entity computer to a user device operated by the user, the key (Narayan, Col. 1, Lines 41-43, embodiments enable a central server computer to generate a verification value and then provide the verification value to a user device) and (Narayan, Col. 21, Lines 37-46, the token provider computer 570 may also generate a verification value. The verification value may be generated based on the dynamic data element, the payment token, the token expiration date, the token requestor ID, an acquirer BIN, one or more cryptographic keys, and/or any other suitable information. In some embodiments, the verification value can have one or more static inputs (e.g., a payment token, an expiration date, and a token requestor ID) and one or more dynamic inputs (e.g., a unique hex value, an ATC, a timestamp, and a transaction amount)); and
Narayan does not explicitly disclose transmitting, by the sending entity computer to an alias directory, a resolve request message comprising the resource provider identifier;
transmitting, by the sending entity computer to a receiving entity computer, an interaction request message comprising the token, the key, and a value,
wherein the receiving entity computer provides the key to the resource provider computer, which validates the key.
However, Lindelsee teaches transmitting, by the sending entity computer to an alias directory, a resolve request message comprising the resource provider identifier (Lindelsee, Para. 0052, Upon receiving a request from the consumer to enroll an account, the first issuer 110 can transmit an enroll account request (or alternatively referred to as a create consumer request; see message 6) to the enrollment module 132 using the consumer key and account nickname and account identifier information);
transmitting, by the sending entity computer to a receiving entity computer, an interaction request message comprising the token, the key, and a value (Lindelsee, Para. 0032, the first issuer 110 can transmit an enroll account request (or alternatively referred to as a create consumer request; see message 6) to the enrollment module 132 using the consumer key and account nickname and account identifier information. The consumer record and its associated records are retrieved based on the consumer key), wherein the receiving entity computer provides the key to the resource provider computer, which validates the key (Lindelsee, Para. 0069, The validate consumer request may also include a consumer key that identifies the specific record to use in the validation) and (Lindelsee, Para. 0046, a consumer key (described below) can be used by the enrollment module 132 to identify the matching record. To return a positive indication that a consumer record is found, the enrollment module 132 can return the consumer key).
Narayan and Lindelsee are considered to be analogues to the claim invention because they are in the same field of an interaction including a payment transaction in which two devices may interact with each other to facilitate a payment. Therefore, it would have been obvious to someone ordinary skill in the art before the effective filling date of the claimed invention to have modified Narayan to incorporate the teachings of Lindelsee to include transmitting, by the sending entity computer to an alias directory, a resolve request message comprising the resource provider identifier (Lindelsee, Para. 0052); transmitting, by the sending entity computer to a receiving entity computer, an interaction request message comprising the token, the key, and a value (Lindelsee, Para. 0032), wherein the receiving entity computer provides the key to the resource provider computer, which validates the key (Lindelsee, Para. 0069). Doing so would aid to Obtain and transmit a partial account identifier during an enrollment process to reduces the risk that a fraudster may obtain sensitive information. This is an advantage because, as described above, a third party may provide the enrollment interface on behalf of the issuer (Lindelsee, Para. 0069).
Regarding claim 2, the combination of Narayan in view of Lindelsee teaches the method of claim 1, wherein prior to the receiving entity computer receiving the interaction request message (Narayan, Col. 23, Lines 7-11, the resource provider computer 530 may send the authorization request message to the transport computer 540. At step S526, the transport computer 540 may forward the authorization request message to the transaction processing computer 550), a processing network computer detokenizes the token to obtain a credential and forwards the interaction request message comprising the credential, the key, and the value to the receiving entity computer (Narayan, Col. 23, Lines 64-67, if the verification value is validated and the domain controls are met, the token provider computer 570 may proceed to detokenize the payment token) and (Narayan, Col. 24, Lines 6-9, the detokenization response message may include the payment credentials, the payment token, a transaction ID, and/or any other suitable information).
Regarding claim 3, the combination of Narayan in view of Lindelsee teaches the method of claim 1, wherein the alias directory comprises a plurality of tokens associated with a plurality of resource providers (Narayan, Col. 14, Lines 41-47, a token record may then be stored in the token record database 170C indicating that the payment token is associated with certain set of payment credentials, a certain user 110, and/or a certain resource provider (e.g., via a certain token requestor ID). In some embodiments, a static token (e.g., a token that can be used for multiple transactions) can be provided to a resource provider).
Regarding claim 4, the combination of Narayan in view of Lindelsee teaches the method of claim 1, wherein the plurality of data elements comprise an identifier for the sending entity computer, the value, a date when the key was requested or issued, and a key request transaction identifier (Narayan, Col. 21, Lines 10-17, the verification value request message may include the payment token, the token expiration date, and/or any other suitable user information or payment information. The verification value request message may also include information about the resource provider computer 531, such as a token requestor ID, a merchant ID, an IP address or physical address, an acquirer BIN, and/or any other suitable information).
Regarding claim 5, the combination of Narayan in view of Lindelsee teaches the method of claim 4, wherein the key is a hash value (Narayan, Col. 8, Lines 3-19, a dCVV2 can be generated using one or more dynamic data elements, payment data (e.g., a token, a token expiry date, etc.), transaction data associated with a current transaction (e.g., a transaction amount, a transaction identifier, an acquirer bank identification number (BIN), a token requestor ID, etc.), one or more cryptographic keys, a cryptogram, a digital signature, a hash value (e.g., based on transaction data), and/or any other suitable information).
Regarding claim 6, the combination of Narayan in view of Lindelsee teaches the method of claim 1, wherein the key is cryptographically derived from plurality of data elements (Narayan, Col. 18, Lines 14-27, FIG. 6 shows the methodology for deriving two unique keys which can be utilized in the preferred embodiment. The payment token 201… the concatenated value 210 may be padded with zeroes, or some other value 211, to create a string of a predetermined fixed length. In a preferred embodiment, the concatenated value 210 may be 128 bits in length, although the concatenated value is not limited to being this length. The concatenated value 210 may then be encrypted 220 using the master derivation key 221 as the encryption key for each encryption stage).
Regarding claim 7, the combination of Narayan in view of Lindelsee teaches the method of claim 1, wherein the key is provided by the receiving entity computer to the resource provider computer after the receiving entity computer detokenizes the token to obtain a credential associated with the token (Narayan, Col. 24, Lines 4-9, the token provider computer 570 can send a detokenization response message back to the transaction processing computer 550. The detokenization response message may include the payment credentials, the payment token, a transaction ID, and/or any other suitable information).
Regarding claim 8, the combination of Narayan in view of Lindelsee teaches the method of claim 1, wherein the user obtains a resource from the resource provider after the resource provider computer verifies the key by determining that the key received from the receiving entity computer matches a key received from the user device of the user (Lindelsee, Para. 0046, a consumer key (described below) can be used by the enrollment module 132 to identify the matching record. To return a positive indication that a consumer record is found, the enrollment module 132 can return the consumer key). Therefore, it would have been obvious to someone ordinary skill in the art before the effective filling date of the claimed invention to have modified Narayan to incorporate the teachings of Lindelsee to include wherein the user obtains a resource from the resource provider after the resource provider computer verifies the key by determining that the key received from the receiving entity computer matches a key received from the user device of the user (Lindelsee, Para. 0046). Doing so would aid to Obtain and transmit a partial account identifier during an enrollment process to reduces the risk that a fraudster may obtain sensitive information. This is an advantage because, as described above, a third party may provide the enrollment interface on behalf of the issuer (Lindelsee, Para. 0069).
Regarding claim 10, the combination of Narayan in view of Lindelsee teaches the method of claim 1, wherein the interaction request message comprising the token, the key (Narayan, Col. 22, Lines 65-68, and Col. 23, Lines 1-6, the payment token may be placed in an existing PAN field, the verification value may be placed in an existing CVV2 field, and/or the token expiration date may be placed in an existing PAN expiration date field. Additionally, the payment token, verification value, and any other suitable information may be encrypted using any suitable encryption technique (e.g., using a public key associated with the token provider computer 570 or transaction processing computer 550)), and the value is received by the receiving entity computer and the receiving entity computer thereafter detokenizes the token to obtain a credential, the credential associated with a record managed by the receiving entity computer (Narayan, Col. 24, Lines 6-9, the detokenization response message may include the payment credentials, the payment token, a transaction ID, and/or any other suitable information) and (Narayan, Col. 23, Lines 11-13, the transaction processing computer 550 may then interact with the token provider computer 570 in order to detokenize the payment token).
Regarding claim 11, the claim is interpreted and rejected for the same rational set forth
in claim 1.
Regarding claim 13, the combination of Narayan in view of Lindelsee teaches the computer of claim 11, wherein the plurality of data elements comprise a sending entity identifier and the value (Narayan, Col. 18, Lines 14-27, FIG. 6 shows the methodology for deriving two unique keys which can be utilized in the preferred embodiment. The payment token 201… the concatenated value 210 may be padded with zeroes, or some other value 211, to create a string of a predetermined fixed length. In a preferred embodiment, the concatenated value 210 may be 128 bits in length, although the concatenated value is not limited to being this length. The concatenated value 210 may then be encrypted 220 using the master derivation key 221 as the encryption key for each encryption stage).
Regarding claim 15, the combination of Narayan in view of Lindelsee teaches the computer of claim 11, wherein the computer is a sending entity computer (Lindelsee, Para. 0030, the consumer 106 may communicate with the client computer 108).
Regarding claim 16, the combination of Narayan in view of Lindelsee teaches the computer of claim 11, wherein the key is a hash value (Narayan, Col. 8, Lines 3-19, a dCVV2 can be generated using one or more dynamic data elements, payment data (e.g., a token, a token expiry date, etc.), transaction data associated with a current transaction (e.g., a transaction amount, a transaction identifier, an acquirer bank identification number (BIN), a token requestor ID, etc.), one or more cryptographic keys, a cryptogram, a digital signature, a hash value (e.g., based on transaction data), and/or any other suitable information).
Regarding claim 17, the combination of Narayan in view of Lindelsee teaches the computer of claim 11, wherein the resource provider identifier is an alias for the token (Narayan, Col. 14, Lines 41-47, a token record may then be stored in the token record database 170C indicating that the payment token is associated with certain set of payment credentials, a certain user 110, and/or a certain resource provider (e.g., via a certain token requestor ID). In some embodiments, a static token (e.g., a token that can be used for multiple transactions) can be provided to a resource provider).
Regarding claim 18, the combination of Narayan in view of Lindelsee teaches the computer of claim 11, wherein the token is associated with a credential, which is associated with a record managed by a receiving entity computer (Narayan, Col. 10, Lines 52-67, and Col. 11, Lines 1-4, a request for a verification value associated with a transaction, the request including a token and a token requestor identifier…the second computer determines that the second verification value matches the first verification value, and wherein the second computer provides, to the third computer, a value credential associated with the token).
Claims 19-20 are rejected under 35 U.S.C. 103 as being unpatentable over Lindelsee et al. (US 2011/0178927 A1), hereinafter Lindelsee in view of Narayan et al. (US 10,664,844 B2), hereinafter Narayan.
Regarding claim 19, Lindelsee discloses a method comprising:
receiving, by an alias directory from a sending entity computer (Lindelsee, Para. 0062, Once the remote payment service receives the request to purchase the items, the remote service can provide the merchant website various nicknames associated with accounts of the consumer),
a resolve request message comprising a resource provider identifier and a sending entity identifier (Lindelsee, Para. 0062, the consumer can then select an account nickname when they purchase an item through the merchant website. The selection of the account nickname is transmitted to the remote payment service and the remote payment service then provides the merchant with account details for the account associated with the selected nickname);
cryptographically altering, by the alias directory, at least the resource provider identifier or data associated with the resource provider identifier, the sending entity identifier (Lindelsee, Para. 0052, In adding an account to the consumer record, the consumer may create one or more new nickname and account identifier combinations at the issuer's enrollment web site. The first issuer 110 may validate the account identifier using CVV2, address verification, or any other suitable method. Upon receiving a request from the consumer to enroll an account, the first issuer 110 can transmit an enroll account request (or alternatively referred to as a create consumer request; see message 6) to the enrollment module 132 using the consumer key and account nickname and account identifier information. The consumer record and its associated records are retrieved based on the consumer key), and a value associated with an interaction between a resource provider associated with the resource provider identifier and a user to form a key (Lindelsee, Para. 0064, the search request may include the consumer key and verification information of a currently enrolled account associated with the consumer); and transmitting, by the alias directory, the resolve response message to the sending entity computer (Lindelsee, Para. 0062, the enrollment module 132 can match the phone number transmitted in message 23 of FIG. 4 with the consumer record created based on message 16 of FIG. 2. Upon matching the consumer phone number with the consumer record, the enrollment module 132 returns an indication that consumer is already enrolled with the service).
Lindelsee does not explicitly disclose retrieving, by the alias directory, a token associated with the resource provider identifier; generating, by the alias directory, a resolve response message comprising the token and the key.
However, Narayan teaches retrieving, by the alias directory, a token associated with the resource provider identifier; generating, by the alias directory, a resolve response message comprising the token and the key (Narayan, Col. 4, Lines 35-45, this involves storing a cryptogram and/or multiple encryption keys for each token transaction, as well as passing a cryptogram in authorization request messages. In some embodiments, a cryptogram may be a large string of data, such as a string of 40 characters. Storing cryptograms and/or specific keys for each transaction can create a need for a large storage database. In contrast, embodiments of the invention allow the central token provider to store as little as a dynamic data element for each transaction. A dynamic data element can be 1-5 characters, or any other suitable length);
Lindelsee and Narayan are considered to be analogues to the claim invention because they are in the same field of an interaction including a payment transaction in which two devices may interact with each other to facilitate a payment. Therefore, it would have been obvious to someone ordinary skill in the art before the effective filling date of the claimed invention to have modified Lindelsee to incorporate the teachings of Narayan to include retrieving, by the alias directory, a token associated with the resource provider identifier; generating, by the alias directory, a resolve response message comprising the token and the key (Narayan, Col. 4, Lines 35-45).
Doing so would aid to validate the verification value by regenerating the verification value based on the stored dynamic data element. Forgoing storage of the verification value improves security, as the verification value is less vulnerable to hacking and compromise. In some embodiments, the dynamic data element can be smaller than the verification value. Accordingly, storing the dynamic data element instead of the verification value reduces the central server computer's data storage burden (Lindelsee, Col. 1, Lines 58-67).
Regarding claim 20, the combination of Lindelsee in view of Narayan teaches the method of claim 19, wherein the sending entity computer generates an interaction request message comprising the token and the value and transmits the interaction request message to a receiving entity computer associated with the resource provider (Narayan, Col. 23, Lines 7-11, the resource provider computer 530 may send the authorization request message to the transport computer 540. At step S526, the transport computer 540 may forward the authorization request message to the transaction processing computer 550), and (Narayan, Col. 23, Lines 64-67, if the verification value is validated and the domain controls are met, the token provider computer 570 may proceed to detokenize the payment token) and (Narayan, Col. 24, Lines 6-9, the detokenization response message may include the payment credentials, the payment token, a transaction ID, and/or any other suitable information). Therefore, it would have been obvious to someone ordinary skill in the art before the effective filling date of the claimed invention to have modified Lindelsee to incorporate the teachings of Narayan to include wherein the sending entity computer generates an interaction request message comprising the token and the value and transmits the interaction request message to a receiving entity computer associated with the resource provider (Narayan, Col. 23, Lines 7-11), and (Narayan, Col. 23, Lines 64-67) and (Narayan, Col. 24, Lines 6-9).
Doing so would aid to validate the verification value by regenerating the verification value based on the stored dynamic data element. Forgoing storage of the verification value improves security, as the verification value is less vulnerable to hacking and compromise. In some embodiments, the dynamic data element can be smaller than the verification value. Accordingly, storing the dynamic data element instead of the verification value reduces the central server computer's data storage burden (Narayan, Col. 1, Lines 58-67).
Claims 9, 12 and 14 are rejected under 35 U.S.C. 103 as being unpatentable over Narayan et al. (US 10,664,844 B2), hereinafter Narayan in view of Lindelsee et al. (US 2011/0178927 A1), hereinafter Lindelsee and further in view of Lindelsee et al. (US 2011/0178926 A1), hereinafter Lindelsee.
Regarding claim 9, Narayan in view of Lindelsee (US 2011/0178927 A1) does not explicitly teach the method of claim 1, wherein the interaction request message is an OCT message.
However, Lindelsee (US 2011/0178926 A1) teaches wherein the interaction request message is an OCT message (Lindelsee (US 2011/0178926 A1), Para. 0044, the payment processing network 106 may send account funding transaction/original credit transaction messages to the issuer 108 and the merchant's bank in order to effectuate a money transfer).
Narayan, Lindelsee (US 2011/0178927 A1) and Lindelsee (US 2011/0178926 A1) are considered to be analogues to the claim invention because they are in the same field of an interaction including a payment transaction in which two devices may interact with each other to facilitate a payment. Therefore, it would have been obvious to someone ordinary skill in the art before the effective filling date of the claimed invention to have modified Narayan and Lindelsee (US 2011/0178927 A1) to incorporate the teachings of Lindelsee (US 2011/0178926 A1) to include wherein the interaction request message is an OCT message (Lindelsee (US 2011/0178926 A1), Para. 0044). Doing so would aid to determines a portable consumer device and an authentication channel selected by the sending entity out of a potential plurality of portable consumer devices and authentication channels, and conducts the authentication via the selected authentication channel, without exposing sensitive information to the merchant (Lindelsee (US 2011/0178926 A1), Para. 0018).
Regarding claim 12, the computer of claim 11, Narayan in view of Lindelsee (US 2011/0178927 A1) does not explicitly teach wherein the resolve request message is an API request message.
However, Lindelsee (US 2011/0178926 A1) teaches wherein the resolve request message is an API request message (Lindelsee, Para. 0056, communications between entities in the remote variable authentication process system 100 may also be conducted via the web, a mobile network, an intranet, SMS/IVR, a plain old telephone system, email, USSD-2, APIs, tailored messages, a specialized application, a communications network or any of the listed initiation or authentication channels).
Narayan, Lindelsee (US 2011/0178927 A1) and Lindelsee (US 2011/0178926 A1) are considered to be analogues to the claim invention because they are in the same field of an interaction including a payment transaction in which two devices may interact with each other to facilitate a payment. Therefore, it would have been obvious to someone ordinary skill in the art before the effective filling date of the claimed invention to have modified Narayan and Lindelsee (US 2011/0178927 A1) to incorporate the teachings of Lindelsee (US 2011/0178926 A1) to include wherein the resolve request message is an API request message (Lindelsee (US 2011/0178926 A1), Para. 0056). Doing so would aid to determines a portable consumer device and an authentication channel selected by the sending entity out of a potential plurality of portable consumer devices and authentication channels, and conducts the authentication via the selected authentication channel, without exposing sensitive information to the merchant (Lindelsee (US 2011/0178926 A1), Para. 0018).
Regarding claim 14, the claim is interpreted and rejected for the same rational set forth
in claim 9.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. See PTO-892.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to GITA FARAMARZI whose telephone number is (571)272-0248. The examiner can normally be reached Monday- Friday 9:00 am- 6:00 pm.
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, Jorge L. Ortiz-Criado can be reached at (571)272-7624. 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.
/GITA FARAMARZI/Examiner, Art Unit 2496
/KEVIN AYALA/Primary Examiner, Art Unit 2496
Prosecution Insights