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 .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission, filed on 06/16/2025, has been entered.
Response to Amendment
The following detailed action acknowledges the amendments of the response filed on 05/12/2025. The amendments in the filed response have been entered.
Claims 21-22, 27-29 and 34-36 have been amended.
Claims 1-20 are confirmed to have been cancelled.
Claims 21-40 are pending in the application and the status of the application is currently pending.
Response to Arguments
Applicant’s arguments, filed 05/12/2025, with respect to the rejections under 35_USC 103 have been fully considered.
Regarding the rejection under 35 USC 103, the Applicant argues: Applicant respectfully notes that the introductory paragraph of the Section 103 rejection (see page 6 of the Office Action) rejects Claims 21-23, 25-30, 32-37, 39, and 40 as allegedly being unpatentable over U.S. Patent Application Publication No. 2014/0143137 to Carlson in view of U.S. Patent Application Publication No. 2015/0195311 to Lemonik et al. ("Lemonik") further in view of U.S. Patent Application Publication No. 2003/0220927 to Iverson et al. ("Iverson") and further in view of U.S. Patent Application Publication No. 2013/0191289 to Cronic et al. ("Cronic"). Claims 24, 31, and 38 are not cited in the introductory paragraph.
However, in the body of the rejection (see page 15 of the Office Action), Claims 24, 31, and 38 are rejected as allegedly being unpatentable over Carlson in view of Lemonik, Iverson, and Cronic. Accordingly, Applicant will address the Section 103 rejection of Claims 21-23, 25-30, 32-37, 39, and 40 as the rejection of Claims 21-40.
Claim 21 recites a "value-added services (VAS) computer system for accessing anonymized transaction data, the VAS computer system comprising at least one processor in communication with a memory device, the at least one processor configured to: generate a secure identifier identifying a VAS account established between the VAS computer system and a cardholder computing device associated with a cardholder, the secure identifier including information not directly identifying the cardholder, the secure identifier generated according to a format associated with a VAS application executing on the VAS computer system . . . embed the secure identifier in a request for access to the anonymized transaction data . . . transmit, via the VAS application, the request to a payment processor computer system . . . in response to transmitting the request to the payment processor computer system, receive and present a request form generated and served by the payment processor computer system, the request form generated to be presented as an embeddable frame integrated with the VAS application executing on the cardholder computing device, the request form configured to (a) present, prior to receiving cardholder authentication information associated with the cardholder, the embeddable frame as an authentication screen on the cardholder computing device via the VAS application, (b) request and receive the cardholder authentication information from the cardholder, the cardholder authentication information inputted by the cardholder via the embeddable frame, (c) create a secure channel to transmit the cardholder authentication information from the authentication screen directly to the payment processor computer system by bypassing the VAS application and the VAS computer system, and (d) communicate, via the secure channel, the cardholder authentication information inputted on the authentication screen directly to the payment processor computer system . . . and serve the request form to the cardholder computing device."
Carlson describes "systems, apparatuses, and methods for indirect device pairing through a trusted intermediary." (See Abstract.). Carlson also describes a "trusted device 120 [that] may generate and send a pairing request including the pairing identifier to the trusted intermediary computer. The pairing request message may include any suitable information to allow the trusted intermediary computer 150 to identify the untrusted device controller 140 and pairing identifier associated with the pairing request. For example, the pairing request message may include the pairing identifier and an untrusted device identifier, the city, state, zip code, form factor of the trusted device 120 or untrusted device 130, etc., in order for the trusted intermediary computer 150 to identify the untrusted device controller 140 or the untrusted device 130 that the user is attempting to pair with." (See paragraph [0103].)
Additionally, Carlson explicitly describes an that "online website service provider computer 840 may use the indirect pairing system to receive user credentials, compare the user credentials to stored user information, authenticate the user, and provide access to secure information to an untrusted computer." (See Carlson at para. [0168]; emphasis added.)
Notably, Carlson does not describe or suggest (i) generating a secure identifier identifying a VAS account established between the VAS computer system and a cardholder computing device associated with a cardholder, the secure identifier including information not directly identifying the cardholder, the secure identifier generated according to a format associated with a VAS application executing on the VAS computer system, (ii) embedding the secure identifier in a request for access to the anonymized transaction data, and (iii) in response to transmitting the request to the payment processor computer system, receiving and presenting a request form generated and served by the payment processor computer system, the request form generated to be presented as an embeddable frame integrated with the VAS application executing on the cardholder computing device, the request form configured to (a) present, prior to receiving cardholder authentication information associated with the cardholder, the embeddable frame as an authentication screen on the cardholder computing device via the VAS application, and (b) request and receive the cardholder authentication information from the cardholder, the cardholder authentication information inputted by the cardholder via the embeddable frame, recited in Claim 21.
Lemonik does not cure the deficiencies of Carlson. Lemonik, describes a system that enables collaborative editing in a separate document-editing application by presenting a single document from the document-editing application to multiple users in embedded frames, reconciling multiple changes to the single document from the respective embedded frames through a parent frame, and then updating the document views of all the users with the reconciled changes Lemonik also describes that the document appears as a separate document or a separate application, and data associated with the document is shared with other users via a parent frame. (See paragraphs [0141] and [0160].) In other words, Lemonik merely describes a system that provides a URL to users who may click on the URL to access a third party application for collaborative document editing. (See paragraph [0141].)
Notably, Lemonik does not describe or suggest (i) generating a secure identifier identifying a VAS account established between the VAS computer system and a cardholder computing device associated with a cardholder, the secure identifier including information not directly identifying the cardholder, the secure identifier generated according to a format associated with a VAS application executing on the VAS computer system, (ii) embedding the secure identifier in a request for access to the anonymized transaction data, and (iii) in response to transmitting the request to the payment processor computer system, receiving and presenting a request form generated and served by the payment processor computer system, the request form generated to be presented as an embeddable frame integrated with the VAS application executing on the cardholder computing device, the request form configured to (a) present, prior to receiving cardholder authentication information associated with the cardholder, the embeddable frame as an authentication screen on the cardholder computing device via the VAS application, and (b) request and receive the cardholder authentication information from the cardholder, the cardholder authentication information inputted by the cardholder via the embeddable frame, as recited in Claim 21.
Iverson does not cure the deficiencies of Carlson and Lemonik. Iverson describes generating a random de-identification pointer for a medical patient, adding the de-identification pointer into the patient's record in a secure cross-reference table 202, linking the de-identification pointer to the patient's transactions in an index table 204, and using the transaction ID in a nonprotected table 205 which contains only de-identified information and is accessible to a user.
Notably, Iverson does not describe or suggest (i) generating a secure identifier identifying a VAS account established between the VAS computer system and a cardholder computing device associated with a cardholder, the secure identifier including information not directly identifying the cardholder, the secure identifier generated according to a format associated with a VAS application executing on the VAS computer system, (ii) embedding the secure identifier in a request for access to the anonymized transaction data, and (iii) in response to transmitting the request to the payment processor computer system, receiving and presenting a request form generated and served by the payment processor computer system, the request form generated to be presented as an embeddable frame integrated with the VAS application executing on the cardholder computing device, the request form configured to (a) present, prior to receiving cardholder authentication information associated with the cardholder, the embeddable frame as an authentication screen on the cardholder computing device via the VAS application, and (b) request and receive the cardholder authentication information from the cardholder, the cardholder authentication information inputted by the cardholder via the embeddable frame, as recited in Claim 21.
Cronic does not cure the deficiencies of Carlson, Lemonik, and Iverson. Cronic describes a system that enables merchants to share cardholder data using tokenization. A merchant identifies to the tokenization provider system a desire to share cardholder data, associated with a token, with a second merchant. The merchant and/or the tokenization provider system then invites the second merchant to register with the tokenization provider system. Once registered, the second merchant can access cardholder data that the original merchant has associated with the second merchant.
Notably, Cronic does not describe or suggest (i) generating a secure identifier identifying a VAS account established between the VAS computer system and a cardholder computing device associated with a cardholder, the secure identifier including information not directly identifying the cardholder, the secure identifier generated according to a format associated with a VAS application executing on the VAS computer system, (ii) embedding the secure identifier in a request for access to the anonymized transaction data, and (iii) in response to transmitting the request to the payment processor computer system, receiving and presenting a request form generated and served by the payment processor computer system, the request form generated to be presented as an embeddable frame integrated with the VAS application executing on the cardholder computing device, the request form configured to (a) present, prior to receiving cardholder authentication information associated with the cardholder, the embeddable frame as an authentication screen on the cardholder computing device via the VAS application, and (b) request and receive the cardholder authentication information from the cardholder, the cardholder authentication information inputted by the cardholder via the embeddable frame, as recited in Claim 21.
In summary, no combination of Carlson, Lemonik, Iverson, and Cronic describes or suggests the computer system of Claim 21. More specifically, no combination of Carlson, Lemonik, Iverson, and Cronic describes or suggests (i) generating a secure identifier identifying a VAS account established between the VAS computer system and a cardholder computing device associated with a cardholder, the secure identifier including information not directly identifying the cardholder, the secure identifier generated according to a format associated with a VAS application executing on the VAS computer system, (ii) embedding the secure identifier in a request for access to the anonymized transaction data, and (iii) in response to transmitting the request to the payment processor computer system, receiving and presenting a request form generated and served by the payment processor computer system, the request form generated to be presented as an embeddable frame integrated with the VAS application executing on the cardholder computing device, the request form configured to (a) present, prior to receiving cardholder authentication information associated with the cardholder, the embeddable frame as an authentication screen on the cardholder computing device via the VAS application, and (b) request and receive the cardholder authentication information from the cardholder, the cardholder authentication information inputted by the cardholder via the embeddable frame.
In response: Of the arguments against Carlson, the only limitations not shown to be taught by Carlson is embedding the secure identifier in a request for access to the anonymized transaction data. The art of Carlson does reasonably teach the major elements of the claim, but does not expressly teach embedding an identifier into a request.
Lemonik, Iverson and Cronic do not cure the deficiencies of Carlson. However, after further search and consideration, new grounds of rejection as needed by the amendments are shown in the rejection below. The claims 21-40 remain rejected under 35 USC 103 as obvious over the prior art.
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.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claims 21-23, 25-30 and 32-37 and 39-40 are rejected under 35 U.S.C. 103 as being unpatentable over US_2014/0143137 (hereinafter “Carlson”), in view of US_2015/0032627 (hereinafter “Dill”), in view of US_2015/0195311 (hereinafter “Lemonik”), in view of US_2003/0220927 (hereinafter “Iverson”) and further in view of US-_2013/0191289 (hereinafter "Cronic").
Regarding Claims 21, 28 and 35, Carlson teaches
generate a secure identifier identifying a VAS account established between the VAS computer system and a cardholder computing device associated with a cardholder, […]; (“In step 303, the untrusted device controller 140 receives the pairing identifier request and generates a unique pairing identifier for the indirect pairing. Alternatively, the untrusted device controller 140 may identify an available pairing identifier in a pairing identifier database. The untrusted device controller 140 may control a large number of untrusted devices and thus, many different pairing identifiers may be generated and/or outstanding at any particular time.” See Carlson in [0090])
transmit, via the VAS application the request to a payment processor computer system; (“In step 312, assuming the user is authenticated, the user may provide the pairing identifier to the trusted device 120. In some embodiments, the user may also provide any additional information at this step. For example, the user may provide an untrusted device identifier (if there is one) as a second form of validation for ensuring the correct untrusted device 130 is being indirectly paired. In such embodiments, the trusted intermediary computer 150 may then compare the received untrusted device identifier to the pairing identifiers database entry associated with the pairing identifier to ensure a received untrusted device identifier received from the untrusted device controller 140 matches the received untrusted device identifier from the trusted device 120.” See Carlson in [0102])
in response to transmitting the request to the payment processor computer system, receive and present a request form generated and served by the payment processor computer system, […] (“In step 403, the user provides transaction details to the trusted device 120 to initiate a transaction request...”, “In step 404, the trusted device 120 may generate a transaction request based on the provided transaction details and send the transaction request (or other command request) to the trusted intermediary computer 150 …in some embodiments, a trusted intermediary computer 150 may store consumer details including financial information and other sensitive information in a user information database 152 at the trusted intermediary computer 150 and thus, the transaction request may merely include an account designation that corresponds to a enrolled user identifier or trusted device identifier (e.g., a username, device serial number, or phone number), an transaction type (e.g., withdraw or transfer), an account type (e.g., checking, savings, etc.), and an amount (e.g., $100) ...”, “Alternatively, some trusted intermediaries may merely be a third party trusted gateway to an untrusted device controller 140 and as such, may not have any pre-enrolled information about the user. In this instance, the command or transaction request may include all of the account information and sensitive information that may be necessary in order to complete the transaction. This information may include the user’s account number, PIN, expiration date, track 2 credit card data, etc.” See Carlson in [0119]-[0122])
the request form generated to be presented as an embeddable frame integrated with the VAS application executing on the cardholder computing device, the request form configured to (a) present, prior to receiving cardholder authentication information associated with the cardholder, […] an authentication screen on the cardholder computing device via the VAS application (App open 308 – Authentication Request 309), (b) request and receive the cardholder authentication information from the cardholder, the cardholder authentication information inputted by the cardholder via the embeddable frame, (Authentication Response 311) (c) […] transmit the set of cardholder authentication information from the authentication screen directly to the payment processor computer system by bypassing the VAS application and the VAS computer system (Pairing request 315 – Pairing Confirmation 322), and (d) communicate, via the secure channel, the set of cardholder authentication information inputted on the authentication screen directly to the payment processor computer system (User Details 403 – Transaction Request 404) (See Carlson in Figures 3 and 4, and in respective paragraphs; describe the payment processing server, see Carlson in [0059])
serve the request form to the cardholder computing device (“As shown in steps 401 and 402, before the method of FIG. 4 may be initiated, the trusted device 120 may receive and display a pairing confirmation informing the user and the trusted device 120 that the trusted device 120 is indirectly paired with the untrusted device 130. … In step 403, the user provides transaction details to the trusted device 120 to initiate a transaction request. The user has now received confirmation from both the trusted intermediary computer 150 as well as the untrusted device 130 that their trusted device 120 is paired. Accordingly, the consumer may now be shown a number of options for performing a transaction or other actions with the untrusted device 130. The options provided by the trusted intermediary computer 150 application may be determined by information included in the pairing confirmation message. For example, the trusted intermediary computer may include a transaction template or transaction template identifier in the pairing confirmation that includes the appropriate transaction request possibilities associated with the untrusted device controller 140 that is indirectly paired with the trusted device 120.” See Carlson in [0119])
The limitation the secure identifier including information not directly identifying the cardholder, the secure identifier generated according to a format associated with a VAS application executing on the VAS computer system is descriptive of the functional elements recited.
Carlson does not explicitly teach a secure identifier generated by the third-party computer system and embed the secure identifier in a request for access to the anonymized transaction data.
Carlson does teach the untrusted device generates a pairing identifier that is part of the secure connection between the untrusted device and the cardholder computing device, where the untrusted computing system receives the pairing identifier from the untrusted device for confirmation when the trusted computing system provides the pairing identifier ("In step 308, the user is presented with the pairing identifier displayed on the ATM and may activate their trusted device 120 to begin contact with the trusted intermediary computer 150. This contact may occur in any suitable manner." See Carlson in [0098]). The secure identifier is recited as identifying a third-party account that is associated to the cardholder computing device, where the prior art teaches the secure identifier is requested by the cardholder and provided to the third-party computing system. It would have been obvious to one having ordinary skill in the art, before the effective filing date of the claimed invention, to "provide the secure identifier to the third-party computing system from the cardholder computing device" as an equivalence to "the secure identifier is generated by the third-party computer system", where the selection of any of these equivalences would be within the level of ordinary skill in the art.
However, Dill does teach an unidentified identifier (“A "payment token issuer identifier" may include any series of characters, numbers, or other identifiers that may be used to identify an issuer associated with a payment token. For example, a payment token issuer identifier may include a token BIN that identifies a particular issuer associated with an account identified using the token. In some embodiments, a payment token issuer identifier may be mapped to a real issuer identifier (e.g., a BIN) for an issuer. For example, a payment token issuer identifier may include a six-digit numerical value that may be associated with an issuer. For instance, any token including the payment token issuer identifier may be associated with a particular issuer. As such, the issuer may be identified using the corresponding issuer identifier range associated with the token issuer identifier.” See Dill in [0065]); and
Dill does teach embedding a code into a request (“For example, in one implementation, a token may be embedded in machine-readable code which may be generated by a wallet provider, mobile application, or other application on mobile device and displayed on a display of the mobile device. The machine-readable code can be scanned at the POS through which the token is passed to the merchant. A mobile contactless mode may include passing the token through NFC in a contactless message.” See Dill in [0067]).
It would have been obvious to a person having ordinary skill in the art, before the effective filing date of the claimed invention, to modify the teachings of Carlson to include “anonymous identifier” and “embedded code”, as taught by Dill, because the application associated with the third-party is prevented from receiving the information from the user of the device by using the embedded code to securely receive the data that is securely provided to the payment processing computer system.
Carlson, in view of Dill, does not expressly teach the request form presented in an embeddable frame within the VAS application executing on the cardholder computing device.
However, Lemonik does teach providing an embeddable frame to allow a user to provide information ("At step 1602, a developer creates a data model and constructs a third party application in a manner such as that described above. The developer then provides a URL to users who wish to access the third party application. At step 1603, the users select the third party application (e.g., by clicking on the URL) and execute the application. Collaborative development service 130 causes the third party software application to be executed and provides access to the application via an embedded frame. For example, the users may create a document using the application which is embedded as an IFrame on a web page. At step 1604, the users interact with collaborative development service 130 via the embedded IFrame, using interframe communication through a parent frame . ... At step 1608, updates to the data are displayed within embedded IFrame in each user's display. At step 1609, a determination is made whether or not the users wish to make additional changes in the document. If so, the process returns to step 1605. If not, the process ends at step 1610." See Lemonik in [0141] in reference to Figure 16B).
It would have been obvious to a person having ordinary skill in the art, before the effective filing date of the claimed invention, to modify the teachings of Carlson to include “serving an embeddable frame”, as taught by Lemonik, because the application associated with the third-party is prevented from receiving the information from the user of the device by using the embedded frame to receive the data that is securely provided to the payment processing computer system.
Carlson, in view of Dill, in view of Lemonik, would reasonably teach embed the request form for presentation as an authentication screen on the cardholder computing device via the VAS application by the combination of Carlson and Lemonik shown above. Carlson is shown to teach communicate the set of cardholder authentication information input at the cardholder computing device directly to the payment processor computer system such that the set of cardholder authentication information input at the cardholder computing device bypasses the VAS application and the VAS computer system and serve the request form to the cardholder computing device as shown above, which can be combined to be executed through the embeddable frame, as shown with Lemonik.
Carlson, in view of Dill, in view of Lemonik, does not expressly teach the secure identifier does not contain any information directly identifying the cardholder account and does not contain any information directly identifying a cardholder associated with the cardholder account. Carlson recites the secure identifier is used as part of the pairing identification; thus it will not include any cardholder information; and further recites the third-party system is a trusted system that does not require a secure identifier to connect with the consumer.
However, Iverson does teach the use of a pseudo-random number (interpreting the creation of a secure identifier by the payment processor system: "Next if the record is not already stored in secure cross-reference table 202 (step 503), de-identify software 402 may generate a random de-identification pointer not related to information in the associated record (step 504). For example, software 402 may use a "Random class" or "SecureRandom class" both available in the JAVA standard APL Both classes produce sequences of pseudorandom numbers based on a seed value. Since the Random and SecureRandom classes may generate a same random number more than one time, software 402 also verifies that each generated random number has not been used in secure cross-reference table 202. The de-identification pointer is an index key and, as such, the deidentification pointer may not be duplicated in secure cross-reference table 202. Each deidentification pointer generated by software 402 may be checked against all other deidentification pointers in secure cross-reference table 202 to ensure that the deidentification pointer is not duplicated. One skilled in the art will appreciate that other methods may be used to generate the de-identification pointer, such as a shuffling algorithm." See Iverson in [0032]).
It would have been obvious to a person having ordinary skill in the art, before the effective filing date of the claimed invention, to modify the teachings of Carlson to include “pseudo-random number for secure de-identification”, as taught by Iverson, because the additional security for the customer's account improves the process transmission during and after the transaction.
Carlson, in view of Dill, in view of Lemonik, in view of Iverson, does not explicitly teach (b) present the embeddable frame as an authentication screen on the cardholder computing device via the VAS application.
However, Cronic does teach providing a screen for authentication (“The third-party merchant 162 can provide a user name and password using the login panel 702 to authenticate with the token access system 122. Other authentication mechanisms are possible. For example, the login panel 702 can present the third-party merchant 162 with an opportunity to present a unique cryptographic identifier or key. This key, in certain embodiments, can then be matched to or decrypted with a corresponding public key to authenticate the third-party merchant 162.” See Cronic in [0120] and reference Figure 7).
It would have been obvious to a person having ordinary skill in the art at the time the invention was filed to modify the teachings of Carlson to include "providing an authentication screen", as taught by Cronic, because the additional security for the customer's account improves the security of the process during and after the transaction.
Regarding Claims 22, 29 and 36, Carlson, in view of Dill, in view of Lemonik, in view of Iverson, in view of Cronic, teaches the limitations of claims 21, 28 and 35. Carlson further teaches wherein the secure identifier does not contain any information directly identifying a cardholder account of the cardholder and does not contain any information directly identifying the cardholder. (Secure identifier, See Carlson in [0098])
Regarding Claims 23, 30 and 37, Carlson, in view of Dill, in view of Lemonik, in view of Iverson, in view of Cronic, teaches the limitations of claims 21, 28 and 35. Carlson, further teaches wherein the at least one processor is further configured to:
receive a registration request from the cardholder computing device, the registration request including a set of information associated with the cardholder; (“A consumer may enroll for pairing services with the trusted intermediary 150 or may send sensitive information to the trusted intermediary 150 without enrolling with the trusted intermediary 150, using the trusted intermediary 150 as a secure gateway for their sensitive information. Where the user or consumer does not enroll with the trusted intermediary 150, the trusted intermediary 150 may not store their data or may only store data temporarily for the duration of completing a particular transaction and then delete the information.” See Carlson in [0083]; “In step 302, the untrusted device 130 informs the untrusted device controller 140 that secure entry has been requested. The untrusted device 130 may generate and send a pairing identifier request to the untrusted device controller 140 to ask for an available pairing identifier from the untrusted device controller 140. The pairing identifier request may include an untrusted device identifier and any expiration conditions input by the user.” See Carlson in [0089])
create, using the set of information, the VAS account. (See Carlson in [0090])
Regarding Claims 24, 31 and 38, Carlson, in view of Dill, in view of Lemonik, in view of Iverson, in view of Cronic, teaches the limitations of claims 21, 28 and 35. Carlson, in view of Cronic, further teaches create, using the set of information, the VAS account and transmit the set of information to the cardholder computing device (See Carlson in [0099] and [0102]) and automatically generate a set of information associated with the cardholder ("If the third-party merchant 162 is authorized to access the tokenization provider system 102, the CHD access system 124 receives a token from the third-party merchant 162 at block 308. Alternatively, at block 308, the CHD access system 124 accesses the token pre-associated with the third-party merchant 162 by the merchant 142 from the token access repository 134. In one embodiment, receiving the token comprises receiving a token identifier associated with the token. In one embodiment, receiving the token includes receiving a request to access CHD associated with the token." See Cronic in [0081])
Regarding Claims 25, 32 and 39, Carlson, in view of Dill, in view of Lemonik, in view of Iverson, in view of Cronic, teaches the limitations of claims 21, 28 and 35. Carlson further teaches wherein the at least one processor is further configured to:
receive, from the cardholder computing device, a designation of a particular payment network associated with a cardholder account of the cardholder; (“In step 313, the trusted device 120 may generate and send a pairing request including the pairing identifier to the trusted intermediary computer. The pairing request message may include any suitable information to allow the trusted intermediary computer 150 to identify the untrusted device controller 140 and pairing identifier associated with the pairing request. For example, the pairing request message may include the pairing identifier and an untrusted device identifier, the city, state, zip code, form factor of the trusted device 120 or untrusted device 130, etc., in order for the trusted intermediary computer 150 to identify the untrusted device controller 140 or the untrusted device 130 that the user is attempting to pair with. Although it is possible to determine the untrusted device 130 upon the pairing identifier alone, such a system may identify an incorrect untrusted device controller 140 if the pairing identifier is not unique across all possible untrusted devices and untrusted device controllers that the trusted intermediary computer 150 may possibly communicate with. Accordingly, the pairing request may include secondary information about the untrusted device 130 or the pairing request to help the pairing identifier or trusted intermediary computer 150 to determine the correct untrusted device controller 140.” See Carlson in [0103])
identify the payment processor computer system based on the designation; (“In step 314, the trusted intermediary computer 150 determines the untrusted device controller 140 associated with the pairing request. The trusted intermediary computer 150 may receive the pairing request, extract the pairing identifier from the pairing request, and search a pairing identifiers database 151 for a matching pairing identifier. Further, in some embodiments, the trusted intermediary computer 150 may verify the pairing identifier is active, valid, and/or unlocked by searching a pairing identifiers database 151 for status information associated with the pairing identifier. In some embodiments (not shown in FIG. 3) the trusted intermediary computer 150 may send a verification request to the determined untrusted device controller 140 to determine if the pairing identifier is still active, has not been requested by the trusted intermediary computer 150 or a different trusted intermediary (not shown) previously, or has not met an expiration condition. If the pairing identifier is associated with a triggered expiration condition or is otherwise locked or unavailable, the pairing identifier cannot be used by the untrusted device controller 140 and the pairing request may be declined.” See Carlson in [0104])
transmit the request to the payment processor computer system based on the particular payment network designated. (“In step 315, the trusted intermediary computer 150 sends the pairing request to the untrusted device controller 140. The pairing request may be the same as the previously received pairing request from the trusted device 120 or the trusted intermediary computer 150 may update information, provide new formatting, or provide additional information in the pairing request. For example, in some embodiments, the trusted intermediary computer 150 may exchange a username provided in the pairing request.” See Carlson in [0105])
Regarding Claims 26, 33 and 40, Carlson, in view of Dill, in view of Lemonik, in view of Iverson, in view of Cronic, teaches the limitations of claims 21, 28 and 35. Carlson, in view of Iverson, further teaches wherein the at least one processor is further configured to associate the VAS account with the secure identifier by writing a record in account records stored in a database in communication with the at least one processor. ("Next if the record is not already stored in secure cross-reference table 202 (step 503), de-identify software 402 may generate a random de-identification pointer not related to information in the associated record (step 504). For example, software 402 may use a "Random class" or "SecureRandom class" both available in the JAVA standard APL Both classes produce sequences of pseudorandom numbers based on a seed value. Since the Random and SecureRandom classes may generate a same random number more than one time, software 402 also verifies that each generated random number has not been used in secure cross-reference table 202. The de-identification pointer is an index key and, as such, the de-identification pointer may not be duplicated in secure cross-reference table 202. Each deidentification pointer generated by software 402 may be checked against all other deidentification pointers in secure cross-reference table 202 to ensure that the deidentification pointer is not duplicated. One skilled in the art will appreciate that other methods may be used to generate the de-identification pointer, such as a shuffling algorithm." See Iverson in [0032])
Regarding Claims 27 and 34, Carlson, in view of Dill, in view of Lemonik, in view of Iverson, in view of Cronic, teaches the limitations of claims 21 and 28. Carlson, in view of Lemonik, and in view of Iverson, further teaches wherein the VAS application provides an interface between the cardholder computing device and the at least one processor, and wherein the at least one processor is further configured to serve the request form to the cardholder computing device in a format integrated with the VAS application. (“For example, in some embodiments, a consumer may use their mobile communication device (e.g., a mobile phone, smart phone, tablet, etc.) to pair with an untrusted automatic teller machine ("ATM") by requesting a pairing identifier from the ATM. The ATM may request a pairing identifier from an ATM device controller/driver that controls the ATM and makes transaction decisions on behalf of the ATM device. The ATM device controller may identify an available pairing identifier and may send a response with the pairing identifier to the untrusted ATM device. The ATM device may then display the pairing identifier for use by the consumer. The ATM device controller may also send the pairing identifier and an expiration time to a trusted intermediary computer which stores the pairing identifier along with a reference to the ATM device controller.” “The user may then activate a connection with the trusted intermediary through their mobile communication device (trusted device) and authenticate themselves to the trusted intermediary. The user may then enter the displayed pairing identifier, and optionally some ATM identification information, into their mobile communication device (trusted device) which may generate a pairing request that is sent to the trusted intermediary. The trusted intermediary may then determine the relevant ATM device controller based on the ATM identification information and/or the pairing identifier, and may send a pairing request to the corresponding ATM controller.” See Carlson in [0028]-[0029]).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to EDGAR R. MARTINEZ-HERNANDEZ whose telephone number is (571)270-0658. The examiner can normally be reached M-F from 9:00 am - 5: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, John W. Hayes can be reached on 571-272-6708. 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.
/ERM/Examiner, Art Unit 3685
/JOHN W HAYES/Supervisory Patent Examiner, Art Unit 3697
Prosecution Insights