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
Claims 1-20 are pending in this instant application per original claims filed on 07/25/2025 by Applicant. Claims 1, 8 and 15 are three independent claims reciting method, system and non-transitory computer-readable media claims. Claims 2-7, 9-14 and 16-20 are respective dependent claims.
Two/2 IDSs have been filed by the Applicant so far on 10-27-2025 and 03-02-2026 that have been considered and entered.
This Office Action is a non-final rejection on merits in response to the original claims filed by the Applicant on 25 JULY 2025 for its original application of the same date that is titled: “SYSTEMS AND METHODS FOR PROCESSING ONLINE CHECKOUT WITH BROWSER AUTOFILL USING A SHARED WALLET”.
Accordingly, pending Claims 1-20 are now being rejected herein.
Claim Rejections - 35 USC §101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (abstract idea) without significantly more, wherein Claims 1, 8 and 15 are independent method, system and non-transitory computer-readable media claims respectively.
Exemplary Analysis.
Claim 1: Ineligible.
The claim recites a series of steps. The claim is directed to a computer-implemented method reciting a series of steps, which is a statutory category of invention (Step 1 -- YES).
The claim is analyzed to determine whether it is directed to a judicial exception. The claim recites the limitations of: receiving a request for payload information associated with an online checkout transaction; performing a risk assessment; determining whether to perform a step-up authentication based on the risk assessment, and upon determining to proceed with the online checkout transaction; creating a secure payload; and sending the secure payload for autofill in a browser. In other words, the claim describes a procedure for generally processing online checkout transactions within browser autofill using a shared wallet (see para [0002], Technical Field). These limitations, as drafted, are steps of a method that, under its broadest reasonable interpretation, covers performance of the limitations via a method of organizing human activity such as fundamental economic principles or practices to include at least “checkout transactions” and “risk assessments”; and/or commercial or legal interactions to include agreements in the form of contracts between “various merchants” for “electronic payments by users/buyers”; and/or managing behavior or relationships or interactions between people to include rules or instructions to be followed by “users utilizing electronic wallets and payment instruments” for making a purchase via “online checkout transactions”; but for the recitation of generic computer/s and/or computer component/s such as the wallet server, browser server, payment instrument and token service providers (devices). These limitations, as drafted, are steps of a method that, under its broadest reasonable interpretation, recites steps for processing payments in form of shared wallets (server) in online checkout transactions using autofill in browser (server); and this is a certain method of organizing human activity. These limitations fall under the “certain methods of organizing human activity” group (Step 2A1 -- YES).
Next, the claim is analyzed to determine if it is integrated into a practical application. The claim recites additional elements of: wallet server; browser server; payment instrument; and token service provider; to carry out steps such as: receiving, at a wallet server, a request from a browser server for payload information associated with a selected payment instrument; performing, by the wallet server, a risk assessment for the selected payment instrument; requesting, by the wallet server, token information from a token service provider; receiving, at the wallet server, the token information from the token service provider; etc. The other two independent claims recite “processors”, and dependent claims in all three categories recite “user device”. The servers, instruments, service providers, processors and devices in these steps are hardware recited at a high level of generality, i.e., as generic processors performing generic computer/s functions of processing data. These generic processors are no more than mere instructions to apply the exception using generic computer/s and/or computer component/s. Accordingly, these additional elements do not integrate the abstract idea into a practical application, because they do not impose any meaningful limits on practicing the abstract idea. Thus, the claim is directed to the abstract idea (Step 2A2 -- NO).
Next, the claim is analyzed to determine if there are additional elements in this claim that individually, or as an ordered combination, ensure that the claim amounts to significantly more than the abstract ideas (whether claim provides inventive concept). As discussed with respect to Step 2A2 above, the additional elements in the claim amount to no more than mere instructions to apply the exception using generic computer/s and/or computer component/s. The same analysis applies here in Step 2B, i.e., mere instructions to apply an exception using a generic computer and/or computer components over a network cannot integrate a judicial exception into a practical application at Step 2A or provide an inventive concept in Step 2B. Because the additional elements described above in Step 2A, they are re-evaluated in Step 2B to determine if they are extra-solution activities. The disclosure does not provide any indication that these system (processors) are anything other than generic processors and the Symantec, TLI, and OIP Techs. court decisions (MPEP 2106.05 (d) (II)) indicate that mere collection or receipt of data over a network is a well‐understood, routine, and conventional function when it is claimed in a merely generic manner (as it is here).
Viewing the limitations as an ordered combination does not add anything further than looking at the limitations individually. When viewed either individually, or as an ordered combination, the additional elements do not amount to a claim as a whole that is significantly more than the abstract idea itself. Therefore, the claim does not amount to significantly more than the recited abstract idea (Step 2B -- NO), and the claim is not patent eligible.
The analysis above applies to all statutory categories of the invention including independent system Claim 8 and independent non-transitory computer-readable media Claim 16, which perform the steps similar to those of the independent method Claim 1. Furthermore, the limitations of dependent method Claims 2-7, further narrow the independent method Claim 1 with additional steps and limitations (e.g., wherein the step-up authentication comprises sending a one-time passcode to a user device associated with the selected payment instrument; receiving, at the wallet server, the one-time passcode entered by a user of the user device; and validating, by the wallet server, the one-time passcode; wherein the step-up authentication comprises requesting a verification value associated with the selected payment instrument;
receiving, at the wallet server, the verification value entered by a user; sending, by the wallet server, a request to a card network to validate the verification value; and receiving, at the wallet server, a validation response from the card network; wherein the secure payload comprises a token, an expiration date, and a dynamic verification value; and wherein the dynamic verification value is unique for the online checkout transaction; etc.), and do not resolve the issues raised in rejection of the independent method Claim 1. Similarly, dependent system Claims 9-14 and dependent non-transitory computer-readable media Claims 16-20 also further narrow their independent Claims 8 and 15 respectively, which are rejected as ineligible for patenting under 35 U.S.C. 101 based upon the same analysis.
Therefore, said Claims 1-20 are rejected under 35 U.S.C. 101 as being directed to non-statutory subject matter.
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 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.
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. The 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.
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 set forth in Graham v. John Deere Co., 383 U.S.1,148 USPQ 459 (1966), that are applied 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.
Claims 1-20 are rejected under 35 USC 103 as unpatentable over a combination of references (Ferenczi, Chitalia, Deliwala and Laxminarayan) as described below for each claim/ limitation.
Exemplary Analysis for Rejection of Claims 1-7
Independent Claim 1 is rejected under 35 USC 103 as unpatentable over Pub. No. US 2017/ 0300897 filed by Ferenczi et al. (hereinafter “Ferenczi”) in view of Pub. No. US 2017/ 0278096 filed by Chitalia et al. (hereinafter “Chitalia”), and further in view of Pub. No. US 2016/ 0379208 filed by Deliwala et al. (hereinafter “Deliwala”), and further in view of Pub. No. US 2016/ 0301683 filed by Laxminarayan et al. (hereinafter “Laxminarayan”), and as described below for each claim/ limitation.
Examiner notes that all claims have been copied as recited by the Applicant to keep them readable and whole, even if the limitations within a claim that are not taught explicitly by the primary/previous reference (are noted in parentheses), but these limitations are noted explicitly as taught by a secondary/new reference whenever a secondary/new reference has been used.
Examiner notes that, for brevity in this rejection, the motivation statement has not been repeated herein every time a secondary reference has been used.
With respect to Claim 1, Ferenczi teaches ---
1. A computer-implemented method comprising:
receiving, at a wallet server, a request from a browser server for (payload information) associated with a selected payment instrument for an online checkout transaction;
(see at least: Ferenczi Abstract and Summary in paras [0003]-[0004]; and para [0037] for a method for protecting a computer; and para [0018] for wallet provider server 150, and PSP server 130 may be integrated with browser 122; and para [0019] for wallet provider server 50, and merchant server 140 may be integrated with browser 122; and para [0020] for wallet provider server 150, PSP server 30, merchant server 40 and browser 122; and para [0029] for PSP server 130 and browser 122 may be integrated, and wallet provider server 150; and para [0030] for wallet provider server 150, and web client 120, browser 122, PSP server 130, and merchant server 140; and para [0032] for wallet provider server150 including electronic wallet 152, browser 122, merchant server 140, and/or PSP server 130; and para [0098] about {“The terms “payment vehicle,” “financial transaction account,” “transaction account” and/or the plural form of these terms may be used interchangeably throughout to refer to a financial instrument.”}; and para [0025] for online store 142, and about {“Merchant checkout page 302 may list transaction information such as the goods and/or services to be purchased …”}; which together are the same as claimed limitations above to include ‘computer-implemented method’, ‘a wallet server’, ‘a browser server’, ‘a selected payment instrument’ and ‘an online checkout transaction’)
Ferenczi teaches as disclosed above, but it may be argued that it may not explicitly disclose about ‘payload information’. However, Chitalia teaches it explicitly.
(see at least: Chitalia Abstract and Summary in paras [0005]-[0012]; and paras [0010], [0087] and [0090] for “payload of the transaction information”; and para [0098] for “ provided token information included in the payload to the merchant server 512”; and para [0101] for “appropriate additional wallet provider server computer 510 to complete the transaction based on information provided in the payload of the authorization request” and “additional wallet provider server computer 510(2) receives the information provided in the payload,”; and para [0102] for “the first wallet provider server computer 506 may generate a second authorization request message using the information provided in the payload of the received authorization request.” and “the payload information may include a second PAN”; which together are the same as claimed limitations above to include ‘payload information’)
It would have been obvious prior to the time of the effective filing date of the claimed invention to have an ordinary person of skill in the art to modify the teachings of Ferenczi with the teachings of Chitalia. The motivation to combine these references would be to provide for completion of transactions using an electronic wallet, the consumer may be required to provide personal information or transaction account information to initiate the payment process (see para [0002] of Ferenczi, and to allow digital wallets for only one way to authenticate the user, when a user needs to provide a user name and password; and the digital wallet may link to different payment sources, and may be used with different merchants (see para [0004] of Chitalia).
Ferenczi and Chitalia teach ---
performing, by the wallet server, (a risk assessment) for the selected payment instrument;
(see at least: Ferenczi ibidem and citations listed above to include ‘computer-implemented method’, ‘a wallet server’, ‘a browser server’, ‘a selected payment instrument’ and ‘an online checkout transaction’)
(see at least: Chitalia ibidem and citations listed above to include ‘payload information’)
Ferenczi and Chitalia teach as disclosed above, but they may not explicitly disclose about ‘a risk assessment’. However, Deliwala teaches it explicitly.
(see at least: Deliwala Abstract and Summary in paras [0005]-[0006]; and para [0024] about {“…… For example, payment network systems 122 may conduct risk assessments on in-app transactions and terminate transactions with unacceptable risk of fraud. …”}; and para [0029] about {“In various embodiments, payment network systems 122 may perform a risk assessment at least partially based on the inputs passed by wallet provider 110 in the function call and other transaction parameters. …… Payment network systems 122 may also consider factors such as the age of the token on user device 100, the a separate risk assessment by wallet provider 110, …”}; and para [0043] about {“…… Payment network 120 may approve the transaction, in response to the cryptogram matching and a risk assessment passing (Step 282).”}; and para [0044] about {“In various embodiments, payment network systems 122 may perform the risk assessment at least partially based on the token, token expiry, cryptogram reference ID, …… Payment network systems 122 may also consider factors such as the age of the token on user device 100, the separate risk assessment by wallet provider 110, the user's history, …”}; and para [0045] about {“In various embodiments, payment network 120 may request that user device 100 refresh the LUPCs on user device 100, in response to risk assessment results (Step 284)…”}; which together are the same as claimed limitations above to include ‘a risk assessment’)
It would have been obvious prior to the time of the effective filing date of the claimed invention to have an ordinary person of skill in the art to modify the teachings of Ferenczi and Chitalia with the teachings of Deliwala. The motivation to combine these references would be to provide for completion of transactions using an electronic wallet, the consumer may be required to provide personal information or transaction account information to initiate the payment process (see para [0002] of Ferenczi, and to allow digital wallets for only one way to authenticate the user, when a user needs to provide a username and password; and the digital wallet may link to different payment sources, and may be used with different merchants (see para [0004] of Chitalia), and the use of digital wallets may streamline the payment protocol in some instances and avoid some of the potential pitfalls of traditional web transactions (see para [0004] of Deliwala).
Ferenczi, Chitalia and Deliwala teach ---
determining whether to perform a step-up authentication based on the risk assessment;
(see at least: Ferenczi ibidem and citations listed above to include ‘computer-implemented method’, ‘a wallet server’, ‘a browser server’, ‘a selected payment instrument’ and ‘an online checkout transaction’)
(see at least: Chitalia ibidem and citations listed above to include ‘payload information’; and para [0055] about {“…… and perform other payment-related functions via the digital wallet application. In some embodiments, different payments account at the digital wallet application may be associated with different authentication applications, and each authentication application may be associated with an Application Identifier (AID). …”}; and para [0069] about {“…… In FIG. 2, an authentication technique may be performed by a wallet application in accordance with requirements set forth by that wallet application.”}; and para [0071] about {“Element 204 illustrates a biometric authentication prompt 204A caused by an authentication application that may be used with some instances of wallet applications. …… In some embodiments, the authentication prompt 204A may provide instructions to perform any one or a combination of actions related to authentication of the user.”}; and para [0125] about {“At 810, the computing device may initiate an authentication process in accordance with the selected additional wallet provider. …… In some embodiments, the first wallet application may be provided with a set of authentication requirements by the additional wallet provider and may perform the authentication process on behalf of the additional wallet provider using those authentication requirements.”}; and para [0159] about {“...... Additionally, by providing the wallet applications with the ability to perform their own authentication processes, the disclosed system enables each wallet application to ensure the authentication of each transaction in a manner suited to that wallet application. This increases the overall security of the transaction.”}; which together are the same as claimed limitations above to include ‘perform a step-up authentication’ per BRI rules)
(see at least: Deliwala ibidem and citations listed above to include ‘a risk assessment’)
Ferenczi, Chitalia and Deliwala teach ---
upon determining to proceed with the online checkout transaction, requesting, by the wallet server, token information from a token service provider;
(see at least: Ferenczi ibidem and citations listed above to include ‘computer-implemented method’, ‘a wallet server’, ‘a browser server’, ‘a selected payment instrument’ and ‘an online checkout transaction’; and para [0003] about {“…… receiving a virtual token from the payment service provider in response to transmitting the transaction account information; and/or transmitting the virtual token to payment service provider script integrated in a browser used by the consumer, the payment service provider script being configured to receive the virtual token and provide the virtual token to the merchant server.”}; which together are the same as claimed limitations above to include ‘token information’)
(see at least: Chitalia ibidem and citations listed above to include ‘payload information’ and ‘perform a step-up authentication’; and para [0098] about {“Irrespective of which entity generates the token, the token may subsequently be provided to the first wallet application 502. Upon receiving the token to be used to complete the transaction, the first wallet application 502 may generate transaction information to be provided to the merchant server 512. …… The transaction information may also include additional user information (e.g., a shipping address for the user) as well as the provided token information included in the payload to the merchant server 512.”}; and para [0114] about {“…… For each payment option associated with the user, the first wallet application may maintain account information, such as a token, PAN, shipping address, or any other suitable consumer-related information. …”}; and para [0119] about {“…… For example, the additional wallet application may provide a token generated from the payment information to the first wallet application to be used to complete the transaction.”}; which are the same as claimed limitations above to include ‘token information’; AND para [0047] about {“A “token provider” or “token service system” can include one or more computers that service payment tokens. In some embodiments, a token service system can facilitate requesting, determining (e.g., generating) and/or issuing tokens, as well as maintaining an established mapping of tokens to primary account numbers (PANs) in a repository (e.g. token vault). …… Various entities of a tokenization ecosystem may assume the roles of the token service provider. For example, payment networks and issuers or their agents may become the token service provider by implementing the token services according to embodiments of the present invention.”}; and para [0048] about {“…… A set of parameters (i.e. token domain restriction controls) may be established as part of token issuance by the token service provider that may allow for enforcing appropriate usage of the token in payment transactions. For example, the token domain restriction controls may restrict the use of the token with particular presentment modes, such as contactless or e-commerce presentment modes. …”}; and para [0056] about {“The system in FIG. 1 also shows a token service computer 140. The token service computer 140 may be operated by a token service provider, and may be in communication with or may be incorporated within the processing network 160. In some embodiments, the token service computer 140 may also be used to provide the computing device 106 with a token.”}; and paras [0090] & [0097]-[0098]; which together are the same as claimed limitations above to include ‘token information from a service provider’)
(see at least: Deliwala ibidem and citations listed above to include ‘a risk assessment’)
Ferenczi, Chitalia and Deliwala teach ---
receiving, at the wallet server, the token information from the token service provider;
(see at least: Ferenczi ibidem and citations listed above to include ‘computer-implemented method’, ‘a wallet server’, ‘a browser server’, ‘a selected payment instrument’ and ‘an online checkout transaction’ plus ‘token information’)
(see at least: Chitalia ibidem and citations listed above to include ‘payload information’, ‘token information’ and ‘token information from a service provider’)
(see at least: Deliwala ibidem and citations listed above to include ‘a risk assessment’)
Ferenczi, Chitalia and Deliwala teach ---
creating, by the wallet server, a secure payload comprising the token information; and
(see at least: Ferenczi ibidem and citations listed above to include ‘computer-implemented method’, ‘a wallet server’, ‘a browser server’, ‘a selected payment instrument’ and ‘an online checkout transaction’ plus ‘token information’)
(see at least: Chitalia ibidem and citations listed above to include ‘payload information’, ‘token information’ and ‘token information from a service provider’)
(see at least: Deliwala ibidem and citations listed above to include ‘a risk assessment’; and para [0006] about {“…… The system may be configured to perform further operations including generating a payment payload including the token, the token expiry, the ATC, and the in-app cryptogram; encrypting the payment payload using a merchant key; and transmitting, by the wallet provider, the payment payload to a merchant associated with the merchant key. The system may also compute at least one of a signature or a message authentication code on the payment payload using a wallet provider key. A refreshed LUPC may be received from the payment network in response to the attesting the user device is secure. The system may also receive a rejection in response to the attesting the user device is secure, and retry to refresh the LUPC in response to the receiving the rejection. …”}; and para [0035] about {“In various embodiments, CAS 124 may compute the in-app payment cryptogram based on the token, unpredictable number, MUN, ATC, security code, and/or session key and approve the transaction if the cryptograms match and the security risk is acceptable (Step 218). CAS 124 may check each bit of the calculated in-app payment cryptogram to verify an exact match with the cryptogram provided in the payment payload. …”}; which together are the same as claimed limitations above to include ‘a secure payload’ per BRI rules)
Ferenczi, Chitalia and Deliwala teach ---
sending, by the wallet server, the secure payload to the browser server for (autofill in a browser).
(see at least: Ferenczi ibidem and citations listed above to include ‘computer-implemented method’, ‘a wallet server’, ‘a browser server’, ‘a selected payment instrument’ and ‘an online checkout transaction’ plus ‘token information’)
(see at least: Chitalia ibidem and citations listed above to include ‘payload information’, ‘token information’ and ‘token information from a service provider’)
(see at least: Deliwala ibidem and citations listed above to include ‘a risk assessment’ and ‘a secure payload’)
Ferenczi, Chitalia and Deliwala teach as disclosed above, but they may not explicitly disclose about ‘autofill in a browser’. However, Laxminarayan teaches it explicitly.
(see at least: Laxminarayan Abstract and Summary in paras [0004]-[0006]; and para [0048] about {“…… In some embodiments, user 101 may be offered a choice to utilize auto-filled information such as billing address 325, shipping address 335, email address 345, and/or phone number 355. The auto-filled information is generally rendered on the website for viewing by user 101. The auto-filled information may be provided by server computer 105. User 101 may agree with and confirm the form-filled information (e.g., by activating a software button) and trigger a confirmation to be sent to server computer 105 (S304). …”}; which together are the same as claimed limitations above to include ‘autofill in a browser’ per BRI rules)
It would have been obvious prior to the time of the effective filing date of the claimed invention to have an ordinary person of skill in the art to modify the teachings of Ferenczi, Chitalia and Deliwala with the teachings of Laxminarayan. The motivation to combine these references would be to provide for completion of transactions using an electronic wallet, the consumer may be required to provide personal information or transaction account information to initiate the payment process (see para [0002] of Ferenczi), and to allow digital wallets for only one way to authenticate the user, when a user needs to provide a username and password; and the digital wallet may link to different payment sources, and may be used with different merchants (see para [0004] of Chitalia), and the use of digital wallets may streamline the payment protocol in some instances and avoid some of the potential pitfalls of traditional web transactions (see para [0004] of Deliwala), and to provide desirable that the number of networks, computing devices, and/or entities that have access to such sensitive data be reduced in order to limit the access to the sensitive data (see para [0002] of Laxminarayan).
Dependent Claims 2-3 are rejected under 35 USC 103 as unpatentable over Ferenczi in view of Chitalia, Deliwala and Laxminarayan as applied to the rejection of independent Claim 1 above, and further in view of Pub. No. US 2023/ 0222504 filed by Phillips et al. (hereinafter “Phillips”), and as described below for each claim/ limitation.
With respect to Claim 2, Ferenczi, Chitalia, Deliwala and Laxminarayan teach ---
2. The computer-implemented method of claim 1, wherein the step-up authentication comprises (sending a one-time passcode) to a user device associated with the selected payment instrument.
(see at least: Ferenczi ibidem and citations listed above to include ‘computer-implemented method’, ‘a wallet server’, ‘a browser server’, ‘a selected payment instrument’ and ‘an online checkout transaction’ plus ‘token information’)
(see at least: Chitalia ibidem and citations listed above to include ‘payload information’, ‘token information’, ‘perform a step-up authentication’ and ‘token information from a service provider’)
(see at least: Deliwala ibidem and citations listed above to include ‘a risk assessment’ and ‘a secure payload’)
(see at least: Laxminarayan ibidem and citations listed above to include ‘autofill in a browser’)
Ferenczi, Chitalia, Deliwala and Laxminarayan teach as disclosed above, but they may not explicitly disclose about authentication comprises ‘sending a one-time passcode’. However, Phillips teaches them explicitly.
(see at least: Phillips Abstract; and para [0033] about {“FIGS. 2A through 2J illustrate wire-frames of mobile device interactions with a cardless ATM system including a one-time passcode authentication process, in accordance with an embodiment. These wireframes are merely exemplary, …… FIGS. 2I and 2J illustrate the reception and entering of a one-time passcode, i.e., one form of secondary authentication provided via authorization engine 109.”}; and para [0037] about {“FIGS. 2I and 2J show the reception and entering of a one-time passcode, i.e., one secondary authentication method provided by authorization engine 109. …… Authorization engine 109 may then determine, based on the medium risk tier that a secondary authentication method is necessary and that verifying a one-time passcode will elevate the token level for the account holder to satisfy a medium risk tier. Authorization engine 109 may settle on the one-time passcode as the appropriate secondary authentication method based on a variety of factors including user preferences, past user behaviors, technical capabilities of mobile device 102, and other suitable considerations. FIG. 21 shows a one-time passcode screen sent to an account holder upon a determination that a secondary authentication method is needed to complete the desired transaction. FIG. 2J shows a screen by which the account holder may enter the received one-time passcode to secondarily authenticate their identity.”}; and para [0055] about {“In 412, authorization engine 109 may determine if the secondary authentication method determined in 402 requires the creation and verification of a one-time passcode. If yes, then method 400 proceeds to 414. Otherwise, method 400 proceeds to 420.”}; and para [0058] about {“…… If the one-time passcodes match, then the account holder has successfully verified their identity via this secondary authentication method. …”}; and para [0070] about {“…… For example, authorization engine 109 may send a user a one-time passcode, send the user security questions, perform one of the other secondary authentication methods described above with reference to FIG. 4, or perform other suitable authentication method. …”}; which together are the same as claimed limitations above to include authentication comprises ‘sending a one-time passcode’)
It would have been obvious prior to the time of the effective filing date of the claimed invention to have an ordinary person of skill in the art to modify the teachings of Ferenczi, Chitalia, Deliwala and Laxminarayan with the teachings of Phillips. The motivation to combine these references would be to provide for completion of transactions using an electronic wallet, the consumer may be required to provide personal information or transaction account information to initiate the payment process (see para [0002] of Ferenczi), and to allow digital wallets for only one way to authenticate the user, when a user needs to provide a username and password; and the digital wallet may link to different payment sources, and may be used with different merchants (see para [0004] of Chitalia), and the use of digital wallets may streamline the payment protocol in some instances and avoid some of the potential pitfalls of traditional web transactions (see para [0004] of Deliwala), and to provide desirable that the number of networks, computing devices, and/or entities that have access to such sensitive data be reduced in order to limit the access to the sensitive data (see para [0002] of Laxminarayan), and to allow banks to protect against various forms of bank fraud to defend stored assets and maintain the confidence of account holders, and thus, banks take special care to vet and authenticate mobile transactions (see para [0003] of Phillips).
With respect to Claim 3, Ferenczi, Chitalia, Deliwala, Laxminarayan and Phillips teach---
3. The computer-implemented method of claim 2, further comprising:
receiving, at the wallet server, the one-time passcode entered by a user of the user device; and
validating, by the wallet server, the one-time passcode.
(see at least: Ferenczi ibidem and citations listed above to include ‘computer-implemented method’, ‘a wallet server’, ‘a browser server’, ‘a selected payment instrument’ and ‘an online checkout transaction’ plus ‘token information’)
(see at least: Chitalia ibidem and citations listed above to include ‘payload information’, ‘token information’ and ‘token information from a service provider’)
(see at least: Deliwala ibidem and citations listed above to include ‘a risk assessment’ and ‘a secure payload’)
(see at least: Laxminarayan ibidem and citations listed above to include ‘autofill in a browser’)
(see at least: Phillips ibidem and citations listed above to include authentication comprises ‘sending a one-time passcode’)
Dependent Claims 4-7 are rejected under 35 USC 103 as unpatentable over Ferenczi in view of Chitalia, Deliwala and Laxminarayan as applied to the rejection of independent Claim 1 above, and as described below for each claim/ limitation.
With respect to Claim 4, Ferenczi, Chitalia, Deliwala and Laxminarayan teach ---
4. The computer-implemented method of claim 1, wherein the step-up authentication comprises requesting a verification value associated with the selected payment instrument.
(see at least: Ferenczi ibidem and citations listed above to include ‘computer-implemented method’, ‘a wallet server’, ‘a browser server’, ‘a selected payment instrument’ and ‘an online
checkout transaction’ plus ‘token information’)
(see at least: Chitalia ibidem and citations listed above to include ‘payload information’, ‘token information’ and ‘token information from a service provider’; and para [0037] about {“…… An authorization request message may also comprise additional data elements including one or more of: a service code, a CVV (card verification value), a dCW (dynamic card verification value), a PAN (primary account number or “account number”), a payment token, a user name, an expiration date, etc. An authorization request message may also comprise “transaction information,”…”}; and para [0042] about {“…… Examples of account information may include a PAN (primary account number or “account number”), user name, expiration date, CW (card verification value), dCVV (dynamic card verification value), CVV2 (card verification value 2), CVC3 card verification values, etc.”}; which together are the same as claimed limitations above to include ‘requesting a verification value’)
(see at least: Deliwala ibidem and citations listed above to include ‘a risk assessment’ and ‘a secure payload’)
(see at least: Laxminarayan ibidem and citations listed above to include ‘autofill in a browser’; and para [0015] about {“…… An authorization request message may also comprise additional data elements corresponding to “identification information” including, by way of example only: a service code, a CVV (card verification value), a dCVV (dynamic card verification value), an expiration date, etc. An authorization request message may also comprise “transaction information,”…”}; and para [0019] about {“…… Examples of account information may include a PAN (primary account number or “account number”), user name, expiration date, CVV (card verification value), dCVV (dynamic card verification value); CVV2 (card verification value 2), CVC3 card verification values, etc. CVV2 is generally understood to be a static verification value associated with a payment device. …”}; and para [0053] about {“...... In one embodiment, the token cryptogram is a Token Authentication Verification Value (TAW).…”}; which together are the same as claimed limitations above to include ‘requesting a verification value’)
With respect to Claim 5, Ferenczi, Chitalia, Deliwala and Laxminarayan teach ---
5. The computer-implemented method of claim 4, further comprising:
receiving, at the wallet server, the verification value entered by a user;
sending, by the wallet server, a request to a card network to validate the verification value; and
receiving, at the wallet server, a validation response from the card network.
(see at least: Ferenczi ibidem and citations listed above to include ‘computer-implemented method’, ‘a wallet server’, ‘a browser server’, ‘a selected payment instrument’ and ‘an online checkout transaction’ plus ‘token information’; and paras [0075]-[0076] & [0081] for “user/s”; and para [0080] about {“As used herein, the term “user”, “consumer”, “customer”, “cardmember”, “business” or “merchant” may be used interchangeably with each other, …”}; which together are the same as claimed limitations above to include ‘a user’; AND para [0054] about {“…… Examples of communications interface may include a modem, a network interface (such as an Ethernet card), a communications port, a Personal Computer Memory Card International Association (PCMCIA) slot and card, etc. …”}; and para [0082] about {“…… The payment network which may be part of certain transactions represents existing proprietary networks that presently accommodate transactions for credit cards, debit cards, and other types of financial/banking cards. …”}; which together are the same as claimed limitations above to include ‘a request to a card network’ per BRI rules)
(see at least: Chitalia ibidem and citations listed above to include ‘payload information’, ‘token information’ and ‘token information from a service provider’ plus ‘requesting a verification value’; and para [0031] about {“…… (c) participating issuers, optionally, send cards to the processing network so that their cardholder data is automatically provisioned for payments in a specified subset of wallets.”}; and para [0112] about {“…… For example, if the first wallet application is affiliated with a Visa™ transaction processing network (e.g., VisaNet™), it may still present credit card payment devices associated with Mastercard™ or American Express™. …”}; and para [0116] about {“…… initiate the generation of an authorization request to be submitted to a processing network and routed to an authorization entity affiliated with the credit card (e.g., an issuer). …”}; which together are the same as claimed limitations above to include ‘a request to a card network’ per BRI rules; AND para [0051] about {“A “user” may include an individual. In some embodiments, a user may be associated with one or more personal accounts and/or mobile devices. The user may also be referred to as a cardholder, account holder, or consumer.”}; which together are the same as claimed limitations above to include ‘a user’)
(see at least: Deliwala ibidem and citations listed above to include ‘a risk assessment’ and ‘a secure payload’; and paras [0072]-[0073] for “user/s”; which together are the same as claimed limitations above to include ‘a user’)
(see at least: Laxminarayan ibidem and citations listed above to include ‘autofill in a browser’ and ‘requesting a verification value’)
With respect to Claim 6, Ferenczi, Chitalia, Deliwala and Laxminarayan teach ---
6. The computer-implemented method of claim 1, wherein the secure payload comprises a token, an expiration date, and a dynamic verification value.
(see at least: Ferenczi ibidem and citations listed above to include ‘computer-implemented method’, ‘a wallet server’, ‘a browser server’, ‘a selected payment instrument’ and ‘an online checkout transaction’ plus ‘token information’)
(see at least: Chitalia ibidem and citations listed above to include ‘payload information’, ‘token information’ and ‘token information from a service provider’; and para [0037] about {“…… An authorization request message may also comprise additional data elements including one or more of: a service code, a CVV (card verification value), a dCW (dynamic card verification value), a PAN (primary account number or “account number”), a payment token, a user name, an expiration date, etc. An authorization request message may also comprise “transaction information,” …”}; which together are the same as claimed limitations above to include ‘a token’, ‘an expiration date’ and ‘a dynamic verification value’ per BRI rules)
(see at least: Deliwala ibidem and citations listed above to include ‘a risk assessment’ and ‘a secure payload’; and Abstract and paras [0005] & [0041] for ‘a/the token’; which together are the same as claimed limitations above to include ‘a token’)
(see at least: Laxminarayan ibidem and citations listed above to include ‘autofill in a browser’)
With respect to Claim 7, Ferenczi, Chitalia, Deliwala and Laxminarayan teach ---
7. The computer-implemented method of claim 6, wherein the dynamic verification value is unique for the online checkout transaction.
(see at least: Ferenczi ibidem and citations listed above to include ‘computer-implemented method’, ‘a wallet server’, ‘a browser server’, ‘a selected payment instrument’ and ‘an online checkout transaction’ plus ‘token information’)
(see at least: Chitalia ibidem and citations listed above to include ‘payload information’, ‘token information’ and ‘token information from a service provider’, plus ‘a dynamic verification value’ in Claim 6 above)
(see at least: Deliwala ibidem and citations listed above to include ‘a risk assessment’ and ‘a secure payload’)
(see at least: Laxminarayan ibidem and citations listed above to include ‘autofill in a browser’)
With respect to Claims 9-14, the limitations of these system claims are rejected under 35 USC 103 based on the exemplary analysis above for the rejection of method Claims 1-7 as described above using cited references of Ferenczi, Chitalia, Deliwala, Laxminarayan and Phillips, because the limitations of these system Claims 9-14 are commensurate in scope to limitations, and thus duplicates, of the above rejected method Claims 1-8 as described above.
With respect to Claims 15-20, the limitations of these non-transitory computer-readable media claims are rejected under 35 USC 103 based on the exemplary analysis above for the rejection of non-transitory computer-readable media Claims 15-20 as described above using cited references of Ferenczi, Chitalia, Deliwala, Laxminarayan and Phillips, because the limitations of these non-transitory computer-readable media Claims 15-20 are commensurate in scope to limitations, and thus duplicates, of the above rejected methos Claims 1-7 as described above.
Conclusion
The prior art made of record and not relied upon, listed in Form 892, that is considered pertinent to the Applicant's disclosure and review for not traversing already issued patents and/or claimed inventions by the claims of the current invention of the Applicant. Examiner notes that Form 892 contains more references than those cited in the rejection above under 35 USC 103, and that all the references cited on said Form 892 are relevant to this application and form a part of the body of prior art.
The Examiner has pointed out particular references contained in the prior art of record in the body of this action for the convenience of the Applicant. Although the specified citations are representative of the teachings in the art and are applied to the specific limitations within the individual claim, other passages and figures may apply as well. The Applicant should consider the entire prior art as applicable as to the limitations of the claims; and said prior art includes references with synonyms for terms used in the claims that have been interpreted under the BRI (broad reasonable interpretation) procedures of the Office. It is respectfully requested from the Applicant, in preparing the response, to consider fully the entire references as potentially teaching all or part of the claimed invention, as well as the context of the passage as taught by the prior art or disclosed by the Examiner.
Any inquiry concerning this communication or earlier communications from the Examiner should be directed to Sanjeev Malhotra whose telephone number is (571) 272-7292. The Examiner can normally be reached during Monday-Friday between 8:30-17:00 hours on a Flexible schedule.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, the Applicant is encouraged to contact the Examiner directly.
If attempts to reach the Examiner by telephone are unsuccessful, the examiner’s supervisor, Abhishek Vyas, can be reached on (571) 270-1836. The facsimile/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 & 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.
Electronic Communications
Prior to initiating the first e-mail correspondence with an Examiner, Applicant is
responsible for filing a written statement with the USPTO in accordance with MPEP §502.03(II). All received e-mail messages including e-mail attachments shall be placed into this application’s record. The Examiner’s e-mail address is provided below at the end of this Office Action.
/S.M./
PSA Examiner, Art Unit 3691
sanjeev.malhotra@uspto.gov
/SANJEEV MALHOTRA/Examiner, Art Unit 3691
Prosecution Insights