stDETAILED ACTION
Notice of Pre-AIA or AIA Status
1. 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 the Claims
2. Applicant filed the Request for Continued Examination on 03/30/2026. Claims 1-2, 4-5, and 7-22 are pending. Claims 1-2, 7-11, 16-17, and 21 are amended. Claim 22 is newly added.
Claim Objections
3. Claim 9 is objected to because of the following informalities:
Claim recites “transmitting, by the merchant system, client token”, wherein article “the” is omitted before the word “client”.
Appropriate correction is required.
Claim Interpretation
Intended Use
4. Intended use language is generally not given patentable weight. See MPEP 2114(II) ("A claim containing a 'recitation with respect to the manner in which a claimed apparatus is intended to be employed does not differentiate the claimed apparatus from a prior art apparatus’ if the prior art apparatus teaches all the structural limitations of the claim. Ex parte Masham, 2 USPQ2d 1647 (Bd. Pat. App. & Inter. 1987).”); see also MPEP 2103(C). Examples of claim limitations that are often found to precede intended use include “adapted to,” “capable of,” “sufficient to,” “whereby,” and “for.”
5. Claim 1 recites “receiving … to authenticate the merchant system” and “transmitting … to process the secure transaction…”
Claim 11 recites “…facilitating … to allow the merchant system to settle …”.
Claims 14 and 20 recite “… processing the client information to confirm …”
Claim 17 recites “wherein the instructions further cause … for facilitating … to allow the merchant system to settle …”
Claim Rejections - 35 USC §101
6. 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.
7. Claims 1-2, 4-5, and 7-22 are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more.
8. In the instant case, claims 1, 9, and 16 are directed to a “method, system, and a non-transitory computer readable storage medium for data security with modular website integration”.
9. Claim 1 recites “transmitting a tokenized account number for processing a transaction”. Specifically, claim recites [emphasized in bold] “receiving, by a merchant system, a selection of a checkout element; transmitting, by the merchant system, a checkout communication associated with a secure transaction, wherein the checkout communication does not include client information; receiving, by the merchant system, a client token that uses the checkout communication to authenticate the merchant system; transmitting, by the merchant system, the client token; activating, by the merchant system, a modal as an overlay on top of an interface, wherein the modal establishes a separate communication channel between a client device and an account security system, such that the client information is communicated to the account security system and is isolated from the merchant system; receiving, through the modal, the client information; receiving, by the merchant system, an indication that the modal has been closed; accessing, by the merchant system, a tokenized account number associated with the client device and the account security system, wherein access to the tokenized account number is based on the received indication; and transmitting, by the merchant system, the tokenized account number for processing the secure transaction, wherein the tokenized account number allows the merchant system to process the secure transaction without access to the client information”. Subject matter grouped under “Certain methods of organizing human activity” (e.g., commercial or legal interactions) and an abstract idea in prong one of step 2A (MPEP 2106.04(a)).
10. This judicial exception is not integrated into a practical application because, when analyzed under prong two of step 2A (MPEP 2106.04 II), the additional elements of claim 1 such as “a merchant system”, “a checkout element”, “a checkout communication”, “a client token”, “an interface”, and “a separate communication channel between a client device and an account security system” represent the use of a computer as a tool to perform an abstract idea and/or does no more than generally link the abstract idea to a particular field of use. With respect to “activating, by the merchant system, a modal as an overlay on top of an interface, wherein the modal establishes a separate communication channel between a client device and an account security system, such that the client information is communicated to the account security system and is isolated from the merchant system”, the claim lacks details regarding what “the modal establishes a separate communication channel between a client device and an account security system” and “that the client information… is isolated from the merchant system” comprises. Therefore, as Applicant has neither placed a restriction on how “the modal establishing a separate communication channel” and “isolating the client information” are performed nor described how the functions are accomplished, the limitations do not integrate the abstract idea into a practical application and does not improve the functioning of a computer, or to another technology or technical field, as it is no more than “apply it” (MPEP2106.05(f)(1)). Additionally, with respect to “transmitting … a checkout communication associated with a secure transaction, wherein the checkout communication does not include client information”, “transmitting … the client token”, and “transmitting … the tokenized account number for processing the secure transaction, wherein the tokenized account number allows the merchant system to process the secure transaction without access to the client information” is simply transmitting data, “[use] of a computer or other machinery in its ordinary capacity for economic or other tasks (e.g., to receive, store, or transmit data) (e.g., a fundamental economic practice) does not integrate a judicial exception into a practical application or provide significantly more, (MPEP 2106.05(f)(2)). The additional elements do not integrate the abstract idea into a practical application as they do no more than represent a computer performing functions that correspond to (i.e., automate) the acts of transmitting a tokenized account number for processing the transaction.
11. When analyzed under step 2B (MPEP 2106.04 II), the claim does not include additional elements that are sufficient to amount to significantly more than the judicial exception itself. Viewed as a whole, the combination of elements recited in the claim merely describes the concept of transmitting a tokenized account number for processing the transaction using computer technology. Therefore, as the use of these additional elements do no more than employ a computer as a tool to automate and/or implement the abstract idea, they cannot provide significantly more than the abstract idea itself (MPEP 2106.05(I)(A)(f) & (h)).
12. Hence, claim 1 is not patent eligible.
13. Claims 9 and 16 also recite “transmitting a tokenized account number for processing the transaction”. Subject matter grouped under “Certain methods of organizing human activity” (e.g., commercial or legal interactions) and an abstract idea in prong one of step 2A (MPEP 2106.04(a)).
14. This judicial exception is not integrated into a practical application because, when analyzed under prong two of step 2A (MPEP 2106.04 II), the additional elements of the claims 9 and 16 such as “a system”, “a memory”, “one or more processors”, “a merchant system”, “a checkout element”, “a checkout communication”, “a client token”, “an interface”, “a separate communication channel between a client device and an account security system”, “a non-transitory computer readable storage medium”, and “a processor” represent the use of a computer as a tool to perform an abstract idea and/or do no more than generally link the abstract idea to a particular field of use. With respect to “activating, by the merchant system, a modal as an overlay on top of an interface, wherein the modal establishes a separate communication channel between a client device and an account security system, such that the client information is communicated to the account security system and is isolated from the merchant system”, the claim lacks details regarding what “the modal establishes a separate communication channel between a client device and an account security system” and “that the client information… is isolated from the merchant system” comprises. Therefore, as Applicant has neither placed a restriction on how “the modal establishing a separate communication channel” and “isolating the client information” are performed nor described how the functions are accomplished, the limitations do not integrate the abstract idea into a practical application and does not improve the functioning of a computer, or to another technology or technical field, as it is no more than “apply it” (MPEP2106.05(f)(1)). Additionally, with respect to “transmitting … a checkout communication associated with a secure transaction, wherein the checkout communication does not include client information”, “transmitting … the client token”, and “transmitting … the tokenized account number for processing the secure transaction, wherein the tokenized account number allows the merchant system to process the secure transaction without access to the client information” is simply transmitting data, “[use] of a computer or other machinery in its ordinary capacity for economic or other tasks (e.g., to receive, store, or transmit data) (e.g., a fundamental economic practice) does not integrate a judicial exception into a practical application or provide significantly more, (MPEP 2106.05(f)(2)). The additional elements do not integrate the abstract idea into a practical application as they do no more than represent a computer performing functions that correspond to (i.e., automate) the acts of transmitting a tokenized account number for processing the transaction. The additional elements do not integrate the abstract idea into a practical application as they do no more than represent a computer performing functions that correspond to (i.e., automate) the acts of transmitting a tokenized account number for processing the transaction.
15. When analyzed under step 2B (MPEP 2106.04 II), the claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception itself. Viewed as a whole, the combination of elements recited in the claims merely describe the concept of transmitting a tokenized account number for processing the transaction using computer technology. Therefore, as the use of these additional elements do no more than employ a computer as a tool to automate and/or implement the abstract idea, they cannot provide significantly more than the abstract idea itself (MPEP 2106.05(I)(A)(f) & (h)).
16. Hence, claims 9 and 16 are not patent eligible.
17. The following dependent claims recent additional elements not addressed above:
claims 2, 10, and 17 recite “a system independent of the account security system”;
claim 7 recites “a secure channel” and “a merchant device”;
claim 8 recites “a secured post channel”;
claims 14 and 20 recite “a secure client device”;
claim 15 recites “a secure channel”, “a merchant device”, and “a secured post channel”; and
claim 22 recites “a display” and “an interface within a website on a client device”
When considered individually, and as a whole, each of these additional elements amount to merely "apply it", as they are merely applying the abstract idea to the technical environment of the system independent of the account security system, the secure channel, the merchant device, the secured post channel, the secure client device, the display, and the interface within the website on the client device.
Dependent claims 2, 4-5, and 7-8, 10-15, and 17-22 merely expand upon the abstract ideas of the independent claims, and are therefore rejected under the same rationale as claims 1, 9, and 16 respectively.
Conclusion of 35 USC §101
18. The claims as a whole do not amount to significantly more than the abstract idea itself. This is because the claims do not effect an improvement to another technology or technical field; the claims do not amount to an improvement to the functioning of a computer system itself; and the claims do not move beyond a general link of the use of an abstract idea to a particular technological environment.
19. Accordingly, there are no meaningful limitations in the claims that transform the judicial exception into a patent eligible application such that the claims amount to significantly more than the judicial exception itself.
Claim Rejections - 35 USC § 103
20. In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
21. 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.
22. 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.
23. Claims 1-2, 7-11, 15-17, and 22 are rejected under 35 U.S.C. 103 as being unpatentable over US20130117185A1 to Collison et al. in view of US20140052617A1 to Chawla et al.
24. As per claim 1:
Collison et al. discloses the following limitations:
A computer-implemented method, comprising ([claim 1] discloses computer-implemented method for transactions between a merchant and customer over a network)
receiving, by a merchant system, a selection of a checkout element ([0010] discloses that the customer visits the merchant site and submits a payment form, constituting a checkout element selection)
transmitting, by the merchant system, a checkout communication associated with a secure transaction, wherein the checkout communication does not include client information ([0011], [0045] discloses that the merchant initiates a checkout flow using the publishable key to communicate with Stripe (the account security system) without transmitting client payment information and the publishable key call is a checkout communication that authenticates the merchant without including client data)
receiving, by the merchant system, a client token that uses the checkout communication to authenticate the merchant system ([0152]-[0153] discloses that the publishable key is a client token received by the merchant (upon account creation) that authenticates/identifies the merchant to Stripe (the account security system)
transmitting, by the merchant system, the client token ([0044], [0079] discloses that the publishable key is set on the client-side and is transmitted to Stripe with every createToken API call, and the code shows the publishableKey is passed as a parameter in the API call to Stripe’ server)
accessing, by the merchant system, a tokenized account number associated with the client device and the account security system… ([0049], [0072] discloses that Stripe creates token and converts payment information into a tokenized account number and the tokenized account number provided to merchant system)
transmitting, by the merchant system, the tokenized account number for processing the secure transaction, wherein the tokenized account number allows the merchant system to process the secure transaction without access to the client information ([0015] discloses that the merchant submits the token to Stripe to charge the customer and the merchant’s server-side application uses the token as a proxy for payment information without ever being exposed to the actual payment data)
Collison et al. does not disclose, however, Chawla et al., as shown, teaches the following limitations:
activating, by the merchant system, a modal as an overlay on top of an interface, wherein the modal establishes a separate communication channel between a client device and an account security system, such that the client information is communicated to the account security system and is isolated from the merchant system (Discloses: [0198] a payment lightbox overlay on top of the merchant’s web page, [0065] activation of modal lightbox overlay on merchant UI, [0196] instantiation of payment lightbox as separate processing channel, fig.13B, [0194] lightbox overlays merchant site and collects payment info directly, establishing separate channel)
receiving, through the modal, the client information (Discloses: [0199] that client enters payment information directly through the lightbox overlay, [0196] the payment platform receives client information through the lightbox modal, fig.13B, [0194] lightbox collects wallet credentials (client information) from consumer)
receiving, by the merchant system, an indication that the modal has been closed (Discloses: [0196] after lightbox checkout, merchant obtains purchase order confirmation (post-close indication), [0008] merchant receives payment completion confirmation (lightbox closure triggers this flow), [0199] after lightbox closes, merchant proceeds with settlement)
[accessing] … wherein access to the tokenized account number is based on the received indication ([0196] after lightbox checkout, merchant obtains purchase order confirmation (post-close indication)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate a method that addresses payment widget creation, configuration and management, electronic payment application programming interface of Chawla et al. (‘617, [0007]) with teaching of Collison et al. wherein merchants have complete control of their customer's payment experience without ever handling, processing, or storing sensitive payment information (‘185, [0008]) for displaying, when the checkout widget is clicked, overlaying on top of the merchant site: shipping information, shipping type, payment information, purchase summary and details and the like, requesting the consumer's wallet credentials to use information in the wallet to conduct the purchase transaction, inputting payment and other details necessary for the purchase, and for receiving by the customer the item, and closing the transaction by settlement through the merchant's account (‘617, [0194], [0196], [0199]).
Claims 9 and 16 are rejected using the same rationale that was used for the rejection of claim 1.
As per claim 9 Collison et al. additionally discloses the following limitations:
a memory ([0449] “The storage media can be any known media, such as computer memory…”)
one or more processors (Fig.1, item 400, [0012] “In one preferred embodiment, Stripe (300) submits the relevant transaction to a Processor (400) …”)
As per claim 16 Collison et al. additionally discloses the following limitations:
A non-transitory computer readable storage medium ([0449] “The storage media can be any known media, such as…other tangible computer storage medium…”)
one or more processors (Fig.1, item 400, [0012] “In one preferred embodiment, Stripe (300) submits the relevant transaction to a Processor (400) …”)
25. As per claim 2:
Collison et al. discloses the following limitations:
The computer-implemented method of claim 1, wherein the merchant system authorizes payment with a system independent of the account security system as part of the secure transaction ([0016], [0115] discloses that Stripe operates as independent payment processing system, separate from card account security and merchant authorizes payment through independent Stripe system using token)
Claim 10 is rejected using the same rationale that was used for the rejection of claim 2.
26. As per claim 7:
Collison et al. does not disclose, however, Chawla et al., as shown, teaches the following limitations:
The computer-implemented method of claim 1 further comprising: opening a secure channel with the client device prior to receipt of the client token ([0065] discloses that the lightbox component activated; secure HTTPS channel inherent in API-Tool platform communication), wherein the client token is received from the client device via the modal on the client device using the secure channel ([0205] discloses that the client token created via MD5 hash, communicated through lightbox modal overlay)
receiving a request for the tokenized account number from a merchant device ([0196] discloses that after lightbox interaction, merchant obtains purchase order/token data), wherein the request is generated by the merchant device subsequent to an indication that the modal on the client device is closed ([0008] discloses that merchant receives payment completion confirmation after lightbox checkout concludes), and wherein the tokenized account number is transmitted to the merchant device subsequent to the request ([0214] discloses that merchant receives transaction data for settlement after lightbox)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate a method that addresses payment widget creation, configuration and management, electronic payment application programming interface of Chawla et al. (‘617, [0007]) with teaching of Collison et al. wherein merchants have complete control of their customer's payment experience without ever handling, processing, or storing sensitive payment information (‘185, [0008]) for generating by the XML component the checkout lightbox, encrypting the user account into the token utilizing by the MD5 Message Digest Algorithm hash, generating a confirmation page to the consumer showing a summary of the transaction and generating a payment authorization message using the purchase request (‘617, [0008], [0065], [0205], [0214]).
27. As per claim 8:
Collison et al. does not disclose, however, Chawla et al., as shown, teaches the following limitations:
The computer-implemented method of claim 7, wherein the checkout communication is received as using a secured post channel ([0078] discloses that HTTPS POST is similar to secured post channel for checkout communication)
wherein the client token is transmitted to the merchant device with a postback identifier using the secured post channel ([0217], [0297] discloses postback URL mechanism for sending data to merchant and postback URL is a stored field per merchant)
wherein the modal is opened on the client device and the secure channel is established between the account security system and the client device subsequent to the client token as communicated to the client device from the merchant device ([0212] discloses that the lightbox modal opened after merchant widget interaction, with secure HTTPS channel to API-Tool server)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate a method that addresses payment widget creation, configuration and management, electronic payment application programming interface of Chawla et al. (‘617, [0007]) with teaching of Collison et al. wherein merchants have complete control of their customer's payment experience without ever handling, processing, or storing sensitive payment information (‘185, [0008]) for generating a HTTP(S) POST message including XML-formatted data, determining whether a postback URL has been specified by the seller and generating and sending a notification message postback when URL has been specified, and opening the lightbox modal after merchant widget interaction with secure HTTPS channel to API-Tool server (‘617, [0078], [0217], [0212]).
28. As per claim 11:
Collison et al. discloses the following limitations:
The system of claim 10, wherein the one or more processors are further configured to perform operations comprising facilitating the secure transaction by sharing the tokenized account number with the system to allow the merchant system to settle payment for the secure transaction with the system ([0016], [0123] discloses that Stripe processes settlement using token (Magic Card Number) and settlement via token-based batch processing) without the merchant system having access to client information ([0011] discloses that payment information goes directly to Stripe, merchant never handles card numbers, merchant only receives token)
29. As per claim 15:
Collison et al. does not disclose, however, Chawla et al., as shown, teaches the following limitations:
The system of claim 9, wherein the one or more processors are further configured to perform operations comprising: opening a secure channel with the client device prior to receipt of the client token, wherein the client token is received from the client device via a modal on the client device using the secure channel ([0196], [0198] discloses that lightbox modal instantiated with secure HTTPS channel for payment processing and lightbox overlay is a modal on client device)
receiving a request for the tokenized account number from a merchant device, wherein the request is generated by the merchant device subsequent to closure of the modal on the client device, and wherein the tokenized account number is transmitted to the merchant device subsequent to the request ([0196] discloses that after lightbox closes, merchant obtains purchase order/transaction data), wherein the checkout communication is received as using a secured post channel ([0217] discloses that postback URL is analogous for secured post channel notification)
wherein the client token is transmitted to the merchant device with a postback identifier using the secured post channel ([0078] discloses that HTTPS POST is analogous to secured post channel)
wherein the modal is opened on the client device and the secure channel is established between the account security system and the client device subsequent to the client token as communicated to the client device from the merchant device ([0212] discloses that lightbox modal opened after merchant widget interaction)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate a method that addresses payment widget creation, configuration and management, electronic payment application programming interface of Chawla et al. (‘617, [0007]) with teaching of Collison et al. wherein merchants have complete control of their customer's payment experience without ever handling, processing, or storing sensitive payment information (‘185, [0008]) for generating a HTTP(S) POST message including XML-formatted data, determining whether a postback URL has been specified by the seller and generating and sending a notification message postback when URL has been specified, and opening the lightbox modal after merchant widget interaction with secure HTTPS channel to API-Tool server (‘617, [0078], [0217], [0212]).
30. As per claim 17:
Collison et al. discloses the following limitations:
The non-transitory computer readable storage medium of claim 16, wherein the merchant system authorizes payment with a system independent of the account security system as part of the secure transaction ([0016] discloses that Stripe is the independent payment system)
wherein when executed by the processor, the instructions further cause the processor to perform operations for facilitating the secure transaction by sharing the tokenized account number with the system to allow the merchant system to settle payment for the secure transaction with the system without the merchant system having access to client information ([0011], [0016] discloses that merchant never handles card numbers and settlement with token, merchant never sees card numbers)
31. As per claim 22:
Collison et al. does not disclose, however, Chawla et al., as shown, teaches the following limitations:
The computer-implemented method of claim 1, further comprising: facilitating a display, by the merchant system, wherein the display is facilitated on an interface within a website on a client device ([0054] discloses that widget displayed on merchant website interface on client device), and wherein the interface includes the checkout element associated with the account security system ([0065], [0404] discloses that checkout lightbox component associated with payment system and widget types such as checkout elements associated with API-Tool payment system).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate a method that addresses payment widget creation, configuration and management, electronic payment application programming interface of Chawla et al. (‘617, [0007]) with teaching of Collison et al. wherein merchants have complete control of their customer's payment experience without ever handling, processing, or storing sensitive payment information (‘185, [0008]) for generating user interface widget that is applicable to different merchants and incorporating API-Tool generated XML component the merchant site that prompt a lightbox checkout component upon a consumer triggering the “checkout now” button (‘617, [0054], [0065]).
32. Claims 4-5, 12-13, and 18-19 are rejected under 35 U.S.C. 103 as being unpatentable over US20130117185A1 to Collison et al. in view of US20140052617A1 to Chawla et al. and US20090325542A1 to Wentker et al.
33. As per claim 4:
Neither Collison et al. nor Chawla et al. disclose, however, Wentker et al., as shown, teaches the following limitations:
The computer-implemented method of claim 1, further comprising receiving, at the account security system, an account lookup request without an account number associated with the tokenized account number ([0052], [0054], [0073], [0077] discloses that merchant receives alias identifier (phone number) instead of account number, system performs issuer lookup using the alias identifier, not an account number, that merchant never possesses the account number, and transaction initiated with phone number/alias, not card number)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate a method that addresses payment widget creation, configuration and management, electronic payment application programming interface of Chawla et al. (‘617, [0007]) and a method for authenticating the identity of an individual and validating the profile data of the individual who presents himself or herself to another party as having a certain identity and having certain corresponding profile data of Wentker et al. (‘542, [0007]) with teaching of Collison et al. wherein merchants have complete control of their customer's payment experience without ever handling, processing, or storing sensitive payment information (‘185, [0008]) for providing an identity number, such as a cellular phone number, and additional identification information such as a bank identification number, receiving by the issuer look-up system the identity number and determining the issuer that is associated with the identity number, and authenticating a buyer even though the merchant never sees or possesses the actual account number of the credit card that the buyer is using (‘542, [0052], [0054], [0073]).
Claims 12 and 18 are rejected using the same rationale that was used for the rejection of claim 4.
34. As per claim 5:
Neither Collison et al. nor Chawla et al. disclose, however, Wentker et al., as shown, teaches the following limitations:
The computer-implemented method of claim 1, further comprising receiving, at the account security system, an account verification request and an account number associated with the tokenized account number ([0054], [0060], [0067], [claim 1] discloses that account number is resolved and forwarded to the MPI for verification, MPI sends verification request to ACS with the account number and card data attached, and the verification request and response message exchange)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate a method that addresses payment widget creation, configuration and management, electronic payment application programming interface of Chawla et al. (‘617, [0007]) and a method for authenticating the identity of an individual and validating the profile data of the individual who presents himself or herself to another party as having a certain identity and having certain corresponding profile data of Wentker et al. (‘542, [0007]) with teaching of Collison et al. wherein merchants have complete control of their customer's payment experience without ever handling, processing, or storing sensitive payment information (‘185, [0008]) for receiving by the issuer look-up system the identity number and determining the issuer that is associated with the identity number, and authenticating a buyer even though the merchant never sees or possesses the actual account number of the credit card that the buyer is using, sending to the issuer's access control server the buyer’s authentication data upon receiving transaction data (e.g., card data including a card account number and expiration data) at the merchant plug-in (‘542, [0054], [0060]).
Claims 13 and 19 are rejected using the same rationale that was used for the rejection of claim 5.
35. Claims 14 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over US20130117185A1 to Collison et al. in view of US20140052617A1 to Chawla et al. and US20130013499A1 to Kalgi.
36. As per claim 14:
Neither Collison et al. nor Chawla et al. disclose, however, Kalgi, as shown, teaches the following limitations:
The system of claim 9, wherein the one or more processors are further configured to perform operations comprising processing client information to confirm that the client information is from a secure client device ([0029], [0145] discloses that biometric recognition confirms client identity from client device and client authentication/authorization information processed)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate a method that addresses payment widget creation, configuration and management, electronic payment application programming interface of Chawla et al. (‘617, [0007]) and a checkout platform that transforms customer purchase requests triggering electronic wallet applications into electronic purchase confirmation and receipts of Kalgi (‘499, [0027]) with teaching of Collison et al. wherein merchants have complete control of their customer's payment experience without ever handling, processing, or storing sensitive payment information (‘185, [0008]) for facilitating payment for the item without revealing the customer's personal information to the merchant and utilizing face, biometric and/or like recognition (e.g., using pattern classification techniques) to determine the identity of the customer (‘499, [0029], [0145]).
Claim 20 is rejected using the same rationale that was used for the rejection of claim 14.
37. Claim 21 is rejected under 35 U.S.C. 103 as being unpatentable over US20130117185A1 to Collison et al. in view of US20140052617A1 to Chawla et al. and US20150134537A1 to Hammad.
38. As per claim 21:
Neither Collison et al. nor Chawla et al. disclose, however, Hammad, as shown, teaches the following limitations:
The computer-implemented method of claim 1, wherein the client token is used to verify the merchant system at the client device, and wherein verification includes using the separate communication channel to verify the merchant system at the client device ([0011], [0043], [0051], [0118], [claim 54] discloses that validation entity verifies merchants and establishes separate secure channel, that verification token obtains and sends merchant identifier to validation entity, that server receives request with merchant identifier and identifies the merchant, that merchant computer is a separate secure channel with mutual authentication between merchant and validation entity, and that validation tests are token authenticates itself to validation entity using encrypted messages via separate channel)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate a method that addresses payment widget creation, configuration and management, electronic payment application programming interface of Chawla et al. (‘617, [0007]) and a method for securely providing the identification information to a validation entity of Hammad (‘537, [0011]) with teaching of Collison et al. wherein merchants have complete control of their customer's payment experience without ever handling, processing, or storing sensitive payment information (‘185, [0008]) for transmitting identification information in encrypted form, establishing secure communication channels between entity and the verified merchants, checking the token serial numbers and/or the IP addresses for preventing replay attacks by fraudsters, and selecting the merchant comprises identifying the selected merchant from the received merchant identifier (‘537, [0011], [0043], [0051], [claim 54]).
Response to Arguments
Rejection under 35 USC § 101
39. Applicant is of the opinion that the amended independent claims 1, 9, and 16 overcome 35 U.S.C. § 101 rejection.
Examiner respectfully disagrees.
Analysis of claims show that the amended claims 1, 9, and 16 directed to the abstract idea grouped under “Certain methods of organizing human activity” (e.g., commercial or legal interactions) and an abstract idea in prong one of step 2A (MPEP 2106.04(a)).
Rejections under 35 U.S.C. § 103
40. Applicant is of the opinion that the prior art references Oborne and McGuire et al. do not teach the amended independent claims 1, 9, and 16 limitations.
Applicant arguments are no longer applicable because they are moot in light of the new ground of rejection.
Conclusion
41. The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
US20120316992A1 – Oborne – Discloses the payment privacy tokenization apparatuses, methods and systems that transform payment token-based purchase orders into multi-issuer purchase payment funds transfers.
US8763142B2 – McGuire et al. – Discloses a payment processing system for accepting manually-entered payment-card numbers wherein rather than entering a payment-card account number into an application module, the card number is instead captured and stored within a tokenizer prior to being sent to the application module.
42. Any inquiry concerning this communication or earlier communications from the examiner should be directed to AMANULLA ABDULLAEV whose telephone number is (571)272-4367. The examiner can normally be reached Monday-Friday 9:30AM -4:30PM ET.
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, Ryan D Donlon can be reached at 571-270-3602. 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.
/AMANULLA ABDULLAEV/ Examiner, Art Unit 3692
/RYAN D DONLON/Supervisory Patent Examiner, Art Unit 3692
July 23, 2026
Prosecution Insights