Detailed Action
Claims 1-20 are pending and are examined.
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, 8, and 15 are currently amended.
Response to Remarks
U.S.C. § 101
Remark 1: Applicant argues “The Office Action indicates on page 2 that claims 1-20 stand rejected under 35 U.S.C. § 101 as allegedly being directed to non-statutory subject matter. However, Step 2A of the Alice/Mayo framework demands that a claim be deemed subject-matter eligible under 35 U.S.C § 101 if the claim is not directed toward a natural phenomenon, product of nature, or an abstract idea. MPEP § 2106 (III). The Examiner has the initial burden to "clearly and specifically" explain why a claim is directed toward a judicial exception. MPEP § 2106.07. For a claim to be directed toward a judicial exception, the claim must both (1) recite a judicial exception, and (2) fail to integrate the judicial exception into a practical application. MPEP § 2106.04 (II)(A). Applicant respectfully submits that neither of these prongs have been met for claims 1-20 as amended.” (Applicant Arguments, 2026-02-04).
Response to Remark 1: The claim limitations directed to detecting a merchant checkout interface, tokenizing a payment card, retrieving user/customer information, and populating checkout fields are properly treated as commercial interactions and sales activities, which fall within the certain methods of organizing human activity grouping. Further, the additional computer-related limitations do not integrate the abstract idea into a practical application because they merely use generic computing components, web view functionality, and form-population operations to automate the underlying commercial transaction. Accordingly, this contention is unpersuasive.
Remark 2: Applicant argues that the Office Action improperly characterizes claim language such as ‘interaction’, ‘merchant experience’, ‘detecting a checkout’, ‘tokenizing a payment card’, retrieving user information, and populating checkout fields as ‘certain methods of organizing human activity’. Applicant further argues that automated checkout autofill using tokenized payment credentials is too technically oriented to fit within commercial or legal interactions.
Response to Remark 2: The rejection is maintained as the limitations are reasonably characterized as commercial interaction, sales activity, and electronic payment activity, which fall within the certain methods of organizing human activity. The use of a computing device, application, web view, and tokenized credential does not prevent the claim from reciting the abstract idea, because those components merely implement and automate the underlying commercial payment workflow.
Remark 3: Applicant argues that the claims integrate the alleged exception into a practical application. Applicant relies on the specifications discussion of a technical problem involving secure merchant transactions, cumbersome virtual card workflows, and the need to void manual copy-paste entry of virtual card numbers. Applicant further argues that claim limitations involving evaluating HTML code, identifying known e-commerce libraries, detecting checkout form elements, and automatically populating checkout fields provide a technical solution that improves a technical field.
Response to Remark 3: The rejection is maintained because the additional elements apply the abstract commercial checkout/payment process using generic computer components and routine web-page/form-processing functions rather than improving the operation of the computer, web-view, tokenization system, or network itself. The asserted benefits, reducing user effort, obfuscating payment card details, and streamlining checkout, are benefits to the commercial transaction and user experience, not a specific technological improvement in computer functionality. Although the specification describes convenience and security advantages, the claims do not recite a particular unconventional technological mechanism beyond detecting checkout-related page elements, obtaining a token, and automatically entering payment/user information into checkout fields.
Remark 4: Applicant argues “Step 2B of the Alice/Mayo framework is "a search for an inventive concept" and establishes that that if "the claim as a whole does recite significantly more than the exception itself, the claim is eligible." MPEP § 2106.05 (II). In evaluating a claim under Step 2B, Examiners should consider whether there "is an unconventional step that confines the claim to a particular useful application of the judicial exception." MPEP § 2106.05 (d). If this step is not a "well-understood, routine, conventional activity previously known to the industry," the step "favors eligibility." See id. Applicant respectfully submits that Applicant's claim 1 contains language that is not "well-understood, routine, conventional activity previously known to the industry." For example, claim 1 as amended recites in part, "a merchant experience" and "evaluating the web view user interface element for hypertext markup language code to determine a presence of known e-commerce application libraries." Applicant submits that "merchant experience[s]" and "evaluating... hypertext markup language code to determine a presence of known e-commerce application libraries" do not constitute "conventional activity" for the relevant "industry."” (id).
Response to Remark 4: The cited limitations, including a merchant experience and evaluating HTML code for known e-commerce application libraries, amount to routine identification and processing of webpage content in the context automation. The claim does not recite a specific unconventional improvement to computer functionality web rendering, token generation, or network security. Instead, it applies conventional computer operations to facilitate payment entry and checkout completion.
35 U.S.C. § 102 and § 103
Remark 1: Applicant argues “Applicant respectfully submits that Benkreira neither teaches nor is alleged to teach, "determine a presence of known e-commerce application libraries," or "detect that the checkout user interface element contains form elements corresponding to the user information." For at least these reasons, Applicant submits that claim 1 is patentable over Benkreira.” (id).
Response to Remark 1: Examiner respectfully disagrees, as the cited references (e.g. Benkreira, Dellostritto, Gaspar, and Kusnanto) still teach the currently amended independent claims, as shown at least in paragraphs 21, 23, and 32 of Benkreira, and as further outlined in paragraph 40 of this action. Benkreira’s plug-in/extension evaluates the merchant webpages DOM/HTML to identify checkout-related elements, including by searching through the input fields in the DOM and/or URL to look for certain tags in order to determine that the page is configured to accept payments. Accordingly, this contention is unpersuasive.
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 an abstract idea without significantly more.
Step 1
Step 1 of the eligibility analysis asks is the claim to a process, machine, manufacture or composition of matter (See MPEP § 2106.03, subsections I and II). Claims 1-7 are directed to a computer-implemented system/apparatus (i.e., machine, and manufacture). Claims 8-14 are directed to a computer-implemented method (i.e., process). Claims 15-20 are directed to a non-transitory computer-readable storage medium (i.e., manufacture). Therefore, these claims fall within the four statutory categories of invention.
Step 2A Prong One
In Prong One examiners evaluate whether the claim recites a judicial exception, i.e., whether a law of nature, natural phenomenon, or abstract idea is set forth or described in the claim. Claims 1, 8 and 15 recite (i.e., sets forth or describes) an abstract idea of automated checkout autofill using tokenized payment credentials, grouped within the “certain methods of organizing human activity” grouping of abstract ideas. The certain method of organizing human activity grouping is used to describe fundamental economic principles or practices, commercial or legal interactions, and managing personal behavior or relationships or interactions between people. Fundamental economic principles or practices are relating to the economy and commerce, or recite hedging, insurance, and mitigating risks. Commercial or legal interactions recite agreements in the form of contracts, legal obligations, advertising, marketing or sales activities or behaviors, and business relations. Managing personal behavior or relationships or interactions between people recite social activities, teaching, and following rules or instructions. See MPEP § 2106.04(a)(2), subsection II. Here, the claim limitations reciting the abstract idea of automated checkout autofill using tokenized payment credentials are grouped within the “certain methods of organizing human activity” grouping of abstract ideas because the limitations recite commercial or legal interactions, as they recite sales activities or behaviors (e.g., sale activities/behaviors of online retail environments). More specifically, the following underlined claim elements recite the abstract idea(s) while the non-underlined claim elements recite additional elements according to MPEP 2106.04(a).
Claim 1:
A system, comprising:
a computing device comprising a processor and a memory; and
an application stored in the memory that, when executed by the processor, causes the computing device to at least:
in response to an interaction with a user interface element for the application, wherein the user interface element corresponds to a merchant experience, generate a web view user interface (UI) element in the application;
render a merchant specific page within the web view UI element;
detect a checkout user interface element in the merchant specific page by at least evaluating the web view user interface element for hypertext markup language code to determine a presence of known e-commerce application libraries;
tokenize a payment card associated with a user account in response to detecting the checkout user interface element to create a tokenized form of the payment card;
retrieve user information associated with the user account, the user information obtained from a card issuer application and comprising at least one of: a shipping address, a name, or a phone number;
detect that the checkout user interface element contains form elements corresponding to the user information; and
automatically populate the checkout user interface element with the user information and the tokenized form of the payment card.
Claim 8:
A method, comprising:
in response to an interaction with a user interface element, wherein the user interface element corresponds to a merchant experience, generating a web view user interface (UI) element;
rendering a merchant specific page within the web view UI element;
detecting a checkout user interface element in the merchant specific page by at least evaluating the web view user interface element for hypertext markup language code to determine a presence of known e-commerce application libraries;
tokenizing a payment card obtained from a card issuer application and associated with a user account in response to detecting the checkout user interface element to create a tokenized form of the payment card;
retrieving user information associated with the user account, the user information comprising at least one of: a shipping address, a name, or a phone number;
detecting that the checkout user interface element contains form elements corresponding to the user information; and
automatically populating the checkout user interface element with the user information and the tokenized form of the payment card.
Claim 15:
A non-transitory, computer-readable medium, comprising machine-readable instructions that, when executed by a processor of a computing device, cause the computing device to at least:
in response to an interaction with a user interface element for an application, wherein the user interface element corresponds to a merchant experience, generate a web view user interface (UI) element in the application;
render a merchant specific page within the web view UI element;
detect a checkout user interface element in the merchant specific page by at least evaluating the web view user interface element for hypertext markup language code to determine a presence of known e-commerce application libraries;
tokenize a payment card associated with a user account in response to detecting the checkout user interface element to create a tokenized form of the payment card;
retrieve user information obtained from a card issuer application and associated with the user account, the user information comprising at least one of: a shipping address, a name, or a phone number;
detect that the checkout user interface element contains form elements corresponding to the user information; and
automatically populate the checkout user interface element with the user information and the tokenized form of the payment card.
Step 2A, Prong Two
Prong Two asks does the claim recite additional elements that integrate the judicial exception into a practical application (MPEP § 2106.04(II)(A)(2)). Here, the additional elements of computing device, user interface (UI) element, individually and in combination, are recited at a high level of generality as generic and conventional elements merely serving as a tool to perform the abstract idea (MPEP § 2106.05(f)) and generally linking the use of the abstract idea to a particular technological environment (MPEP § 2106.05(h)). The description of the additional elements evidences that they are generic and conventional elements used as tools to perform the abstract idea. The computing device may be a generic and conventional computer/processor (See Spec. 0062). The application may be a generic and conventional application (See Spec. 0019). The user interface (UI) element(s) may be a generic and conventional UI (See Spec. 0042-0044, 0055, etc). The payment card may be a generic and conventional card (See Spec. 0022). These additional elements do not improve the functioning of computers, another technology, or a technical field (MPEP §§ 2106.04(d)(1) and 2106.05(a)). They do not apply the abstract idea to effect a particular treatment or prophylaxis for a disease or medical condition (MPEP § 2106.04(d)(2)). They do not implement the abstract idea with a particular machine or manufacture that is integral to the claim (MPEP § 2106.05(b)). They do not transform or reduce a particular article to a different state or thing (MPEP § 2106.05(c)). Nor do they apply the abstract idea in a meaningful way or impose a meaningful limit on it beyond linking its use to a particular technological environment (MPEP § 2106.05(e)). Such a generic computer implementation does not make the abstract idea patent eligible because a wholly generic computer implementation is not generally the sort of additional feature that provides any practical assurance that the process is more than a drafting effort designed to monopolize the abstract idea itself. The Specification and the claim language provide evidence that the focus of the claim is not on a specific improvement in computer/processor, UI, and/or card technology but rather on a scheme, i.e., abstract idea, for which a generic computer/processor, UI, and/or card is invoked merely as a tool to implement the abstract idea and link it to a particular field of use. Even if the Specification describes technical improvements, they are not claimed. Thus, the additional elements do not integrate the abstract idea into a practical application. Accordingly, the claims are directed to the abstract idea identified above.
Step 2B
Step 2B determines whether the claim as a whole amount to significantly more than the abstract idea itself (MPEP § 2106.05). Evaluating additional elements to determine whether they amount to an inventive concept requires considering them both individually and in combination to ensure that they amount to significantly more than the abstract idea itself. Individually, the additional elements do not amount to significantly more than the abstract idea. As discussed previously, the description of the additional elements evidences that they are generic and conventional elements used as tools to perform the abstract idea (See Spec. 0019, 0062, 0042-0044, 0055, and 0022). As such, the additional elements merely serve as a tool to perform the abstract idea and generally link the use of the abstract idea to a particular technological environment. The ordered combination recites no more than the individual elements do. Thus, the additional elements are not significantly more than the abstract idea. Accordingly, the claims are directed to the abstract idea identified above without significantly more. The claims are not eligible, warranting a rejection for lack of subject matter eligibility and concluding the eligibility analysis.
Dependent Claims
Claims 2-7, 9-14, and 16-20 have also been analyzed. However, the subject matter of these claims also fails to recite patent eligible subject matter for the following reasons:
Claim 2 recites an abstract idea because the claim describes automated checkout autofill using tokenized payment credentials, grouped within the “certain methods of organizing human activity” grouping of abstract ideas. The additional elements do not integrate the abstract idea into a practical application because individually and in combination, the additional elements are recited at a high level of generality as generic and conventional computers and components merely serving as a tool to perform the abstract idea and generally linking the use of the abstract idea to a particular technological environment. The additional elements are not significantly more than the abstract idea because individually and in combination, the additional elements are recited at a high level of generality as generic and conventional computers and components merely serving as a tool to perform the abstract idea and generally linking the use of the abstract idea to a particular technological environment. Therefore, the claim is not eligible. The following underlined claim limitations recite the abstract idea. The non-underlined claim limitations recite additional elements.
wherein the payment card is tokenized by generating a randomized string that is associated with the payment card, wherein the randomized string is submitted to a merchant payment portal instead of a payment card number.
Claim 3 recites an abstract idea because the claim describes automated checkout autofill using tokenized payment credentials, grouped within the “certain methods of organizing human activity” grouping of abstract ideas. The additional elements do not integrate the abstract idea into a practical application because individually and in combination, the additional elements are recited at a high level of generality as generic and conventional computers and components merely serving as a tool to perform the abstract idea and generally linking the use of the abstract idea to a particular technological environment. The additional elements are not significantly more than the abstract idea because individually and in combination, the additional elements are recited at a high level of generality as generic and conventional computers and components merely serving as a tool to perform the abstract idea and generally linking the use of the abstract idea to a particular technological environment. Therefore, the claim is not eligible. The following underlined claim limitations recite the abstract idea. The non-underlined claim limitations recite additional elements.
wherein the application tokenizes the payment card by causing the computing device to at least: transmit a request to a card issuer system for a token corresponding to a payment card, the request comprising an identifier corresponding to merchant associated with merchant specific page; and obtain the token from the card issuer system, wherein the token can only be used for transactions with the merchant.
Claim 4 recites an abstract idea because the claim describes automated checkout autofill using tokenized payment credentials, grouped within the “certain methods of organizing human activity” grouping of abstract ideas. The additional elements do not integrate the abstract idea into a practical application because individually and in combination, the additional elements are recited at a high level of generality as generic and conventional computers and components merely serving as a tool to perform the abstract idea and generally linking the use of the abstract idea to a particular technological environment. The additional elements are not significantly more than the abstract idea because individually and in combination, the additional elements are recited at a high level of generality as generic and conventional computers and components merely serving as a tool to perform the abstract idea and generally linking the use of the abstract idea to a particular technological environment. Therefore, the claim is not eligible. The following underlined claim limitations recite the abstract idea. The non-underlined claim limitations recite additional elements.
wherein the application tokenizes the payment card by causing the computing device to at least: obtain a token corresponding to the payment card, wherein the token is associated with a spending limit that is less than a respective spending limit of the payment card.
Claim 5 recites an abstract idea because the claim describes automated checkout autofill using tokenized payment credentials, grouped within the “certain methods of organizing human activity” grouping of abstract ideas. The additional elements do not integrate the abstract idea into a practical application because individually and in combination, the additional elements are recited at a high level of generality as generic and conventional computers and components merely serving as a tool to perform the abstract idea and generally linking the use of the abstract idea to a particular technological environment. The additional elements are not significantly more than the abstract idea because individually and in combination, the additional elements are recited at a high level of generality as generic and conventional computers and components merely serving as a tool to perform the abstract idea and generally linking the use of the abstract idea to a particular technological environment. Therefore, the claim is not eligible. The following underlined claim limitations recite the abstract idea. The non-underlined claim limitations recite additional elements.
wherein the application populates the checkout user interface element with the tokenized form of the payment card and the user information without user interaction.
Claim 6 recites an abstract idea because the claim describes automated checkout autofill using tokenized payment credentials, grouped within the “certain methods of organizing human activity” grouping of abstract ideas. The additional elements do not integrate the abstract idea into a practical application because individually and in combination, the additional elements are recited at a high level of generality as generic and conventional computers and components merely serving as a tool to perform the abstract idea and generally linking the use of the abstract idea to a particular technological environment. The additional elements are not significantly more than the abstract idea because individually and in combination, the additional elements are recited at a high level of generality as generic and conventional computers and components merely serving as a tool to perform the abstract idea and generally linking the use of the abstract idea to a particular technological environment. Therefore, the claim is not eligible. The following underlined claim limitations recite the abstract idea. The non-underlined claim limitations recite additional elements.
wherein the application further causes the computing device to generate a recommendation for an alternative payment card associated with the user account for the checkout user interface element.
Claim 7 recites an abstract idea because the claim describes automated checkout autofill using tokenized payment credentials, grouped within the “certain methods of organizing human activity” grouping of abstract ideas. The additional elements do not integrate the abstract idea into a practical application because individually and in combination, the additional elements are recited at a high level of generality as generic and conventional computers and components merely serving as a tool to perform the abstract idea and generally linking the use of the abstract idea to a particular technological environment. The additional elements are not significantly more than the abstract idea because individually and in combination, the additional elements are recited at a high level of generality as generic and conventional computers and components merely serving as a tool to perform the abstract idea and generally linking the use of the abstract idea to a particular technological environment. Therefore, the claim is not eligible. The following underlined claim limitations recite the abstract idea. The non-underlined claim limitations recite additional elements.
wherein the recommendation is based at least in part upon a merchant-specific reward associated with the alternative payment card.
Claim 9 recites an abstract idea because the claim describes automated checkout autofill using tokenized payment credentials, grouped within the “certain methods of organizing human activity” grouping of abstract ideas. The additional elements do not integrate the abstract idea into a practical application because individually and in combination, the additional elements are recited at a high level of generality as generic and conventional computers and components merely serving as a tool to perform the abstract idea and generally linking the use of the abstract idea to a particular technological environment. The additional elements are not significantly more than the abstract idea because individually and in combination, the additional elements are recited at a high level of generality as generic and conventional computers and components merely serving as a tool to perform the abstract idea and generally linking the use of the abstract idea to a particular technological environment. Therefore, the claim is not eligible. The following underlined claim limitations recite the abstract idea. The non-underlined claim limitations recite additional elements.
wherein the payment card is tokenized by generating a randomized string that is associated with the payment card, wherein the randomized string is submitted to a merchant payment portal instead of a payment card number.
Claim 10 recites an abstract idea because the claim describes automated checkout autofill using tokenized payment credentials, grouped within the “certain methods of organizing human activity” grouping of abstract ideas. The additional elements do not integrate the abstract idea into a practical application because individually and in combination, the additional elements are recited at a high level of generality as generic and conventional computers and components merely serving as a tool to perform the abstract idea and generally linking the use of the abstract idea to a particular technological environment. The additional elements are not significantly more than the abstract idea because individually and in combination, the additional elements are recited at a high level of generality as generic and conventional computers and components merely serving as a tool to perform the abstract idea and generally linking the use of the abstract idea to a particular technological environment. Therefore, the claim is not eligible. The following underlined claim limitations recite the abstract idea. The non-underlined claim limitations recite additional elements.
wherein tokenizing the payment card further comprises: transmitting a request to a card issuer system for a token corresponding to a payment card, the request comprising an identifier corresponding to merchant associated with merchant specific page; and obtaining the token from the card issuer system, wherein the token can only be used for transactions with the merchant.
Claim 11 recites an abstract idea because the claim describes automated checkout autofill using tokenized payment credentials, grouped within the “certain methods of organizing human activity” grouping of abstract ideas. The additional elements do not integrate the abstract idea into a practical application because individually and in combination, the additional elements are recited at a high level of generality as generic and conventional computers and components merely serving as a tool to perform the abstract idea and generally linking the use of the abstract idea to a particular technological environment. The additional elements are not significantly more than the abstract idea because individually and in combination, the additional elements are recited at a high level of generality as generic and conventional computers and components merely serving as a tool to perform the abstract idea and generally linking the use of the abstract idea to a particular technological environment. Therefore, the claim is not eligible. The following underlined claim limitations recite the abstract idea. The non-underlined claim limitations recite additional elements.
wherein tokenizing the payment card further comprises: obtaining a token corresponding to the payment card, wherein the token is associated with a spending limit that is less than a respective spending limit of the payment card.
Claim 12 recites an abstract idea because the claim describes automated checkout autofill using tokenized payment credentials, grouped within the “certain methods of organizing human activity” grouping of abstract ideas. The additional elements do not integrate the abstract idea into a practical application because individually and in combination, the additional elements are recited at a high level of generality as generic and conventional computers and components merely serving as a tool to perform the abstract idea and generally linking the use of the abstract idea to a particular technological environment. The additional elements are not significantly more than the abstract idea because individually and in combination, the additional elements are recited at a high level of generality as generic and conventional computers and components merely serving as a tool to perform the abstract idea and generally linking the use of the abstract idea to a particular technological environment. Therefore, the claim is not eligible. The following underlined claim limitations recite the abstract idea. The non-underlined claim limitations recite additional elements.
further comprising populating the checkout user interface element with the tokenized form of the payment card and the user information without user interaction.
Claim 13 recites an abstract idea because the claim describes automated checkout autofill using tokenized payment credentials, grouped within the “certain methods of organizing human activity” grouping of abstract ideas. The additional elements do not integrate the abstract idea into a practical application because individually and in combination, the additional elements are recited at a high level of generality as generic and conventional computers and components merely serving as a tool to perform the abstract idea and generally linking the use of the abstract idea to a particular technological environment. The additional elements are not significantly more than the abstract idea because individually and in combination, the additional elements are recited at a high level of generality as generic and conventional computers and components merely serving as a tool to perform the abstract idea and generally linking the use of the abstract idea to a particular technological environment. Therefore, the claim is not eligible. The following underlined claim limitations recite the abstract idea. The non-underlined claim limitations recite additional elements.
further comprising generating a recommendation for an alternative payment card associated with the user account for the checkout user interface element.
Claim 14 recites an abstract idea because the claim describes automated checkout autofill using tokenized payment credentials, grouped within the “certain methods of organizing human activity” grouping of abstract ideas. The additional elements do not integrate the abstract idea into a practical application because individually and in combination, the additional elements are recited at a high level of generality as generic and conventional computers and components merely serving as a tool to perform the abstract idea and generally linking the use of the abstract idea to a particular technological environment. The additional elements are not significantly more than the abstract idea because individually and in combination, the additional elements are recited at a high level of generality as generic and conventional computers and components merely serving as a tool to perform the abstract idea and generally linking the use of the abstract idea to a particular technological environment. Therefore, the claim is not eligible. The following underlined claim limitations recite the abstract idea. The non-underlined claim limitations recite additional elements.
wherein the recommendation is based at least in part upon a merchant-specific reward associated with the alternative payment card.
Claim 16 recites an abstract idea because the claim describes automated checkout autofill using tokenized payment credentials, grouped within the “certain methods of organizing human activity” grouping of abstract ideas. The additional elements do not integrate the abstract idea into a practical application because individually and in combination, the additional elements are recited at a high level of generality as generic and conventional computers and components merely serving as a tool to perform the abstract idea and generally linking the use of the abstract idea to a particular technological environment. The additional elements are not significantly more than the abstract idea because individually and in combination, the additional elements are recited at a high level of generality as generic and conventional computers and components merely serving as a tool to perform the abstract idea and generally linking the use of the abstract idea to a particular technological environment. Therefore, the claim is not eligible. The following underlined claim limitations recite the abstract idea. The non-underlined claim limitations recite additional elements.
wherein the payment card is tokenized by generating a randomized string that is associated with the payment card, wherein the randomized string is submitted to a merchant payment portal instead of a payment card number.
Claim 17 recites an abstract idea because the claim describes automated checkout autofill using tokenized payment credentials, grouped within the “certain methods of organizing human activity” grouping of abstract ideas. The additional elements do not integrate the abstract idea into a practical application because individually and in combination, the additional elements are recited at a high level of generality as generic and conventional computers and components merely serving as a tool to perform the abstract idea and generally linking the use of the abstract idea to a particular technological environment. The additional elements are not significantly more than the abstract idea because individually and in combination, the additional elements are recited at a high level of generality as generic and conventional computers and components merely serving as a tool to perform the abstract idea and generally linking the use of the abstract idea to a particular technological environment. Therefore, the claim is not eligible. The following underlined claim limitations recite the abstract idea. The non-underlined claim limitations recite additional elements.
wherein the machine-readable instructions tokenize the payment card by causing the computing device to at least: transmit a request to a card issuer system for a token corresponding to a payment card, the request comprising an identifier corresponding to merchant associated with merchant specific page; and obtain the token from the card issuer system, wherein the token can only be used for transactions with the merchant.
Claim 18 recites an abstract idea because the claim describes automated checkout autofill using tokenized payment credentials, grouped within the “certain methods of organizing human activity” grouping of abstract ideas. The additional elements do not integrate the abstract idea into a practical application because individually and in combination, the additional elements are recited at a high level of generality as generic and conventional computers and components merely serving as a tool to perform the abstract idea and generally linking the use of the abstract idea to a particular technological environment. The additional elements are not significantly more than the abstract idea because individually and in combination, the additional elements are recited at a high level of generality as generic and conventional computers and components merely serving as a tool to perform the abstract idea and generally linking the use of the abstract idea to a particular technological environment. Therefore, the claim is not eligible. The following underlined claim limitations recite the abstract idea. The non-underlined claim limitations recite additional elements.
wherein the machine-readable instructions tokenize the payment card by causing the computing device to at least: obtain a token corresponding to the payment card, wherein the token is associated with a spending limit that is less than a respective spending limit of the payment card.
Claim 19 recites an abstract idea because the claim describes automated checkout autofill using tokenized payment credentials, grouped within the “certain methods of organizing human activity” grouping of abstract ideas. The additional elements do not integrate the abstract idea into a practical application because individually and in combination, the additional elements are recited at a high level of generality as generic and conventional computers and components merely serving as a tool to perform the abstract idea and generally linking the use of the abstract idea to a particular technological environment. The additional elements are not significantly more than the abstract idea because individually and in combination, the additional elements are recited at a high level of generality as generic and conventional computers and components merely serving as a tool to perform the abstract idea and generally linking the use of the abstract idea to a particular technological environment. Therefore, the claim is not eligible. The following underlined claim limitations recite the abstract idea. The non-underlined claim limitations recite additional elements.
wherein the machine-readable instructions populate the checkout user interface element with the tokenized form of the payment card and the user information without user interaction.
Claim 20 recites an abstract idea because the claim describes automated checkout autofill using tokenized payment credentials, grouped within the “certain methods of organizing human activity” grouping of abstract ideas. The additional elements do not integrate the abstract idea into a practical application because individually and in combination, the additional elements are recited at a high level of generality as generic and conventional computers and components merely serving as a tool to perform the abstract idea and generally linking the use of the abstract idea to a particular technological environment. The additional elements are not significantly more than the abstract idea because individually and in combination, the additional elements are recited at a high level of generality as generic and conventional computers and components merely serving as a tool to perform the abstract idea and generally linking the use of the abstract idea to a particular technological environment. Therefore, the claim is not eligible. The following underlined claim limitations recite the abstract idea. The non-underlined claim limitations recite additional elements.
wherein the machine-readable instructions further cause the computing device to generate a recommendation for an alternative payment card associated with the user account for the checkout user interface element.
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claims 1, 4-5, 8, 11-12, 15 and 19 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Benkreira et al. (US20190318343A1) (hereinafter “Benkreira”).
As per Claim 1, 8, and 15, Benkreira teaches:
A system, comprising: a computing device comprising a processor and a memory; and an application stored in the memory that, when executed by the processor, causes the computing device to at least: (“A system is disclosed that includes a processing system and a memory system.” (Para. 0003); (“the hardware system 800 may include a computer 801. The computer 801 may include a processor 810, a memory 820, a storage 830” (Para. 0057); (“The memory system includes one or more computer-readable media that contain instructions that, when executed by the processing system, cause the processing system to perform operations.” (Para. 0003); (“may proceed by operation of the user device 120 e.g., executing the web browser with the plug-in or extension 124.” (Para. 0030)
in response to an interaction with a user interface element for the application, wherein the user interface element corresponds to a merchant experience, (“The user 110 may then select one or more items or services on the webpage to purchase.” (Para. 0017); (“Once the items or services have been selected, the user 110 and the user device 120 may then proceed to a checkout webpage 122 provided by the merchant server 140.” (Para. 0017)
generate a web view user interface (UI) element in the application; (“The user device 120 may display a webpage generated/provided by the merchant server 140.” (Para. 0016); (“The method 500 may proceed by operation of the user device 120 e.g., executing the web browser with the plug-in or extension 124.” (Para. 0030)
render a merchant specific page within the web view UI element; (“The user device 120 may display a webpage generated/provided by the merchant server 140. The webpage may be one that the user 110 and the user device 120 have visited before, or it may be one that the user 110 and the use device 120 have not visited before. . . Once the items or services have been selected, the user 110 and the user device 120 may then proceed to a checkout webpage 122 provided by the merchant server 140. The checkout webpage 122 may include a plurality of fields that need to be populated/filled-in with the user's information to complete the purchase. The user information may be or include the user's name, billing address (e.g., name, address, city, state, zip code), credit card number, credit card expiration date, credit card verification value (CCV) number, etc.” (Para. 0016-0017)
detect a checkout user interface element in the merchant specific page; (“detecting a loading of a webpage comprising a document object model (DOM); analyzing the DOM to identify a first element in the DOM; determining, based on the first element, that the webpage is configured to accept payments.” (Claim 1); “The method 500 may also include analyzing/searching the DOM to identify one or more first elements in the DOM, as at 504. . . determining that the webpage is configured to accept payments and/or payment information (i.e., that the webpage is a checkout webpage 122), as at 508.” (Para. 0030-0033))
at least evaluating the web view user interface element for hypertext markup language code to determine a presence of known e-commerce application libraries; (“The analysis may include searching through the input fields in the DOM and/or URL to look for certain tags, attributes, names, styles, naming patterns, placeholders, text, numbers, etc.” (Para. 0032); “For example, the term “onepage” in the URL 200 may be an element, and the plug-in or extension 124 may determine that a third-party tool was used to generate the checkout portion of the DOM 210 in response to this element.” (Para. 0021); “a data-braintree-name of “number” in the DOM 210 may be an element, and the plug-in or extension 124 may determine that the DOM 210 is linked to a checkout webpage in response to identifying this element. More particularly, this may indicate that a third-party tool, such as the BRAINTREE® tool, is being used and tagging this as one or more of the fields that need to be populated with the user's information.” (Para. 0023))
tokenize a payment card associated with the user account in response to detecting the checkout user interface element; (“the plug-in or extension 124 on the user device 120 may request the virtual token from the provider server 150 in response to determining that the webpage is configured to accept payments.” (Para. 0038); “The method 600 may also include the provider server 150 receiving a request for a virtual token from the (plug-in or extension 124 on the) user device 120, as at 608. . . generating the virtual token in response to the request, as at 610.” (Para. 0046-0047))
retrieve user information associated with the user account, the user information obtained from a card issuer application and comprising at least one of: a shipping address, a name, or a phone number; and detect that the checkout user interface element contains form elements corresponding to the user information; and (“The checkout webpage 122 may include a plurality of fields that need to be populated/filled-in with the user's information to complete the purchase. The user information may be or include the user's name, billing address (e.g., name, address, city, state, zip code), credit card number, credit card expiration date, credit card verification value (CCV) number, etc.” (Para. 0017); “virtual token may also or instead include the user's name, billing address.” (Para. 0038)
automatically populate the checkout user interface element with the user information and the tokenized form of the payment card. (“The plug-in or extension 124 may then automatically populate some or all of the fields on the checkout webpage 122 with the information in the virtual token . . . may also or instead include the user's name, billing address, expiration date for the virtual credit card number, CCV for the virtual credit card number, bank account number, routing number, etc.” (Para. 0018); “The method 500 may also include (e.g., automatically) injecting/placing the virtual token into the account number field, as at 514. As described above, the account number field may include one or more fields that are configured to be populated/filled-in with the user's payment information, such as the user's name, billing address, (e.g., virtual) credit card number expiration date for the (e.g., virtual) credit card number, CCV for the (e.g., virtual) credit card number, bank account number, routing number, etc . . . As such, step 514 may include injecting/placing some or all of the information in the virtual token into the one or more fields that are configured to be populated/filled-in with the user's payment information as a webpage is rendered for display.” (Para. 0041); See also Fig. 5.
As per Claim 4, 11, and 18 Benkreira teaches:
The system of claim 1, wherein the application tokenizes the payment card by causing the computing device to at least: obtain a token corresponding to the payment card, wherein the token is associated with a spending limit that is less than a respective spending limit of the payment card. (“the virtual token may be. . . used to pay up to (but not more than) $100.” (Para. 0039); “taxes and/or shipping fees may be estimated (e.g., by the plug-in or extension 124), and the virtual credit card number may be loaded with a predetermined amount of credit that is sufficient to purchase the item, plus the estimated tax and/or shipping fees.” (Para. 0039); “The method 600 may also include the provider server 150 placing limitations on the use of the virtual token, as at 612.” (Para. 0048))
As per Claim 5, 12, and 19, Benkreira teaches:
The system of claim 1, wherein the application populates the checkout user interface element with the tokenized form of the payment card and the user information without user interaction. (“The plug-in or extension 124 may then automatically populate some or all of the fields on the checkout webpage 122 with the information in the virtual token.” (Para. 0018); “The operations also include automatically placing the virtual token into one or more fields for the payment information in the webpage.” (Para. 0004); “The virtual token may be injected by the plug-in or extension 124 in response to determining that the webpage is configured to accept payments and/or authenticating the identity of the user 110. Thus, the user 110 may not have to click and/or type to enter the information from the virtual token into the account number field on the checkout webpage.” (Para. 0041)).
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 2, 9, and 16 are rejected under 35 U.S.C. 103 as being unpatentable over Benkreira et al. in view of Gaspar et al. (US9092777) (hereinafter “Gaspar”).
As per Claim 2, 9, and 16, Benkreira teaches:
The system of claim 1, wherein the payment card is tokenized by generating a randomized string that is associated with the payment card, wherein . . . is submitted to a merchant payment portal instead of a payment card number. (“receiving, from a provider server, a virtual token which corresponds to a user account . . . injecting information from the virtual token into one or more account number fields on the webpage.” (Abstract); “the virtual token may be or include a (e.g., new) virtual credit card number that corresponds to the user's pre-existing credit card account. The virtual token may also or instead include the user's name, billing address, expiration date for the virtual credit card number, CCV for the virtual credit card number, bank account number, routing number, etc.” (Para. 0018); “the systems 100 and methods 500, 600 described above function differently than conventional autocomplete systems and methods because the systems 100 and methods 500, 600 described above generate new virtual tokens which can include all of the information needed to be entered in place of a physical credit card.” (Para. 0055)).
Benkreira does not disclose:
“the randomized string.” (claim 2).
However, as per Claim 2, Gaspar in the analogous art of credit-card/token based online purchasing systems teaches: “the randomized string”. (See “The token may be randomized, including alphanumeric characters, be of equal length to the credit card number, and include a configurable character sequence.” (Abstract); “Step 610 includes, using one or more computers, the non-merchant entity generating and storing a token in association with the payment card number and with information specifying the desired transaction. The token includes a randomized, alphanumeric character set, equal in amount of characters to an amount of characters in the payment card number. The token has a configurable amount of time between generation and expiry.” (Col. 5, ln. 47-56); “A token may be used and stored by a merchant, for example, instead of, or in place of, a credit card number for a particular transaction, or desired or attempted transaction.” (Col. 1, ln. 7-9))
It would have been obvious to one of ordinary skill in the art before the effective filing date to combine the method of Benkreira, auto-detecting a checkout page and automatically populate checkout fields with a virtual token carrying cardholder data, with the technique of Gaspar, generating and using a randomized, PAN-length token in place of the primary account number, to include tokenizing the payment card by generating a randomized string submitted to the merchant instead of the PAN. Therefore, the incentives of reducing merchant PCI exposure and fraud risk while preserving form compatibility provided a reason to make an adaptation, and the invention resulted from application of the prior knowledge in a predictable manner.
Claims 3, 10, and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Benkreira et al. in view of Kusnanto et al. (US20170193499A1) (hereinafter “Kusnanto”).
As per Claim 3, 10, and 17, Benkreira teaches:
The system of claim 1, wherein the application tokenizes the payment card by causing the computing device to at least: . . .. (“The method 600 may also include the provider server 150 receiving a request for a virtual token from the (plug-in or extension 124 on the) user device 120, as at 608. The (plug-in or extension 124 on the) user device 120.” (Para. 0046); “the element may be a signature of a merchant in the URL 200 or DOM 210 that indicates to the plug-in or extension 124 that the merchant has either built or hosts the webpage linked to the URL 200.” (Para. 0021); “The method 600 may also include the provider server 150 placing limitations on the use of the virtual token, as at 612. The limitations may be merchant-specific.” (Para. 0048)).
Benkreira does not disclose:
“transmit a request to a card issuer system for a token corresponding to a payment card, the request comprising an identifier corresponding to merchant associated with merchant specific page; and obtain the token from the card issuer system, wherein the token can only be used for transactions with the merchant.” (claim 3).
However, as per Claim 3, Kusnanto in the analogous art of online purchasing systems/wallets teaches: “transmit a request to a card issuer system for a token corresponding to a payment card, the request comprising an identifier corresponding to merchant associated with merchant specific page; and obtain the token from the card issuer system, wherein the token can only be used for transactions with the merchant”. (See “The contact message 110 may also include a merchant identifier.” (Para. 0018); “The cart details, merchant id and contact, such as a phone number of the purchaser, may be communicated 110 to the Service Server 115.” (Para. 0031); “If the user is verified, a payment token may be created 150. The token may contain a one-time use personal account number (PAN) which is related to an existing personal account number (PAN). The payment token may be provided by specifically designed token server which may track the relationship between the one time use PAN and the existing PAN such that the one time use PAN may be communicated to a vendor where it may be authorized and used to connect to the existing PAN.” (Para. 0035))
It would have been obvious to one of ordinary skill in the art before the effective filing date to combine the method of Benkreira, auto-detecting a checkout page and automatically populate checkout fields with a virtual token carrying cardholder data, with the technique of Kusnanto, transmitting a request that comprises a merchant identifier to a server and obtaining a payment token in return, to include sending a token request that includes the merchant identifier and receiving a token usable only with that merchant. Therefore, the incentives of enabling merchant-scoped tokens for fraud control, correct routing, and PCI scope reduction provided a reason to make an adaptation, and the invention resulted from application of the prior knowledge in a predictable manner.
Claims 6-7, 13-14, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Benkreira et al. (US20190318343A1) (hereinafter “Benkreira”) in view of Dellostitto et al. (US20180114223A1) (hereinafter “Dellostitto”).
As per Claim 6, 13 and 20, Benkreira teaches:
Benkreira discloses all limitations of claims 6, 13, and 20, except the limitation noted below.
Benkreira does not disclose:
“wherein the application further causes the computing device to generate a recommendation for an alternative payment card associated with the user account for the checkout user interface element.” (claim 6).
However, as per Claim 6, Dellostritto in the analogous art of online purchasing systems teaches: “wherein the application further causes the computing device to generate a recommendation for an alternative payment card associated with the user account for the checkout user interface element”. (See “In some embodiments, the cardholder may also be presented with a display screen that enables viewing of offers and/or rewards associated with the one or more of the available payment card accounts and the option to apply such offers and/or rewards to the purchase transaction.” (Para. 0018); “displaying, by the mobile device processor on a touch screen component of the consumer mobile device, a single screen checkout user interface that partially overlays a merchant checkout webpage that comprises purchase transaction options and a cardholder verification method (CVM) request message.” (Claim 1); “In some embodiments, during an enrollment or registration process the cardholder specifies a particular payment card account (resident in a particular digital wallet) for use in conducting purchase transactions with one or more designated merchants.” (Para. 0019))
It would have been obvious to one of ordinary skill in the art before the effective filing date to combine the method of Benkreira, anchoring checkout with a particular merchant via virtual token, with the technique of Dellostritto, with a screen-based UI displaying offers and/or rewards associated with available payment card accounts, to include generating a recommendation of an alternative card at checkout. Therefore, the incentives of maximizing cardholder savings and issuer/merchant program utilization at an identified merchant provided a reason to make an adaptation, and the invention resulted from application of the prior knowledge in a predictable manner.
As per Claim 7 and 14, Benkreira teaches:
Benkreira discloses all limitations of claims 7 and 14, except the limitation noted below.
Benkreira does not disclose:
“wherein the recommendation is based at least in part upon a merchant-specific reward associated with the alternative payment card” (claim 7).
However, as per Claim 7, Dellostritto in the analogous art of online purchasing systems, teaches: “wherein the recommendation is based at least in part upon a merchant-specific reward associated with the alternative payment card”. (See “In some embodiments, the cardholder may also be presented with a display screen that enables viewing of offers and/or rewards associated with the one or more of the available payment card accounts and the option to apply such offers and/or rewards to the purchase transaction.” (Para. 0018); “displaying, by the mobile device processor on a touch screen component of the consumer mobile device, a single screen checkout user interface that partially overlays a merchant checkout webpage that comprises purchase transaction options and a cardholder verification method (CVM) request message.” (Claim 1); “In some embodiments, during an enrollment or registration process the cardholder specifies a particular payment card account (resident in a particular digital wallet) for use in conducting purchase transactions with one or more designated merchants.” (Para. 0019))
It would have been obvious to one of ordinary skill in the art before the effective filing date to combine the method of Benkreira, anchoring checkout with a particular merchant via virtual token, with the technique of Dellostritto, with a screen-based UI displaying offers and/or rewards associated with available payment card accounts, to include generating a recommendation of an alternative card at checkout. Therefore, the incentives of maximizing cardholder savings and issuer/merchant program utilization at an identified merchant provided a reason to make an adaptation, and the invention resulted from application of the prior knowledge in a predictable manner.
Conclusion
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a). A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
The following prior art made of record and not relied upon is considered pertinent to applicant's disclosure: US20170132624A1 (Muchang), discussing “In some embodiments, the payment data 213 may include a payment token. A payment token may be a one-time use code that is known to the payment processor. In some embodiments, the payment token may be specific to the merchant in question. . .. the payment data 213 may also include a name, a billing address and a shipping address which may be auto-filled in the underlying browser 201.” (Para. 0030-0031).
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Justin A. Jimenez whose telephone number is (571) 270-3080. The examiner can normally be reached on 8:30 AM - 5:00 PM.
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.
/Justin Jimenez/
Patent Examiner, Art Unit 3697
/ARI SHAHABI/Primary Examiner, Art Unit 3697
Prosecution Insights