DETAILED ACTION
Acknowledgements
This action is in response to Applicant’s filing on Mar. 27, 2026, and is made Non-Final. This action is being examined by James H. Miller, who is in the eastern time zone (EST), and who can be reached by email at James.Miller1@uspto.gov or by telephone at (469) 295-9082.
Interviews
Examiner interviews are available by telephone or, preferably, by video conferencing using the USPTO’s web-based collaboration platform. Applicants are strongly encouraged to schedule via the USPTO Automated Interview Request (AIR) portal at http://www.uspto.gov/interviewpractice. Interviews conducted solely for the purpose of “sounding out” the examiner, including by local counsel acting only as a conduit for another practitioner, are not permitted under MPEP § 713.03. The Office is strictly enforcing established interview practice, and applicants should ensure that every interview request is directed toward advancing prosecution on the merits in compliance with MPEP §§ 713 and 713.03.
For after-final Interview requests, supervisory approval is required before an interview may be granted. Each AIR should specifically explain how the After-Final Interview request will advance prosecution—for example, by identifying targeted arguments responsive to the rejection of record, alleged defects in the examiner’s analysis, proposed claim amendments, or another concrete basis for discussion. See MPEP § 713. If the AIR form’s character limits prevent inclusion of all pertinent details, Applicants may send a contemporaneous email to the examiner at James.Miller1@uspto.gov.
The examiner is generally available Monday through Friday, 10:00 a.m. to 4:00 p.m. EST.
For any GRANTED Interview Request, Applicant can expect an email within 24 hours confirming an interview slot from the dates/times proposed and providing collaboration tool access instructions. For any DENIED Interview Request, the record will include a communication explaining the reason for the denial.
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on Mar. 27, 2026, has been entered.
Claim Status
The status of claims is as follows:
Claims 21–41 are now pending and examined with Claims 21, 31, and 40 in independent form.
Claims 21, 31, and 40 are presently amended.
No Claims are presently cancelled.
Claim 41 is presently added.
Response to Amendment
Applicant's Amendment has been reviewed against Applicant’s Specification filed Apr. 29, 2024, [“Applicant’s Specification”] and accepted for examination.
Response to Arguments
Double Patenting
Applicant argues the amendments to Independent Claims obviates the double patenting rejection of the Non-Final Office Action. Applicant’s Reply at 7. Examiner agrees. The double patenting rejection of Claims 21, 31, and 40 as set forth in the Final Office Action mailed Jan. 6, 2026, [“Final Office Action”] is withdrawn.
35 U.S.C. § 101 Argument
Generally, the core deficiency in nearly all of Applicant’s § 101 arguments is that the claim elements are drafted functionally, i.e., the claims recite what the extension does but not how it does it.
Applicant argues that merchant plug-in proliferation (Spec. ¶ 57), difficulty and risk from manual form fatigue (Spec. ¶ 58), and user distrust of unfamiliar payment interfaces (Spec. ¶ 59) are technical, not business problems. Applicant’s Reply at 8–10. Applicant argues these technical problems are with how browsers and merchant web pages interact.
Examiner respectfully disagrees.
The problems identified in Spec. ¶¶ 57–59 are business and user experience concerns. Specifically, reducing merchant integration burden (Spec ¶ 57), minimizing user annoyance from repetitive data entry (Spec. ¶ 58), and formatting displays to compel user trust. These are human behavioral and commercial concerns that happen to be implemented on a computer, not an improvement to the computer itself. MPEP 2106.05(a). Further, under MPEP 2106.05(a), identifying the problem in the specification is insufficient unless the claims itself recites the technical solution with sufficient specificity – not merely the result or outcome. Amended Claim 31 recites, for example, “receive payment data,” and “execute a transaction” and are all purely functional without specifying the structural or algorithmic means by which those outcomes are achieved. The problems in Spec ¶¶ 57–59 do not therefor, establish integration of the abstract idea into a practical application.
Applicant argues that the amendments to independent claims now represent a concrete technical solution by shifting payment logic into a reusable browser-side extension, eliminating per-merchant plug-ins as described in Spec. ¶ 57. Applicant’s Reply at 10–11.
Examiner respectfully disagrees.
While Spec. ¶¶ 33–45 describe an example implementation, the claim language itself is drafted at a purely functional, results-orientated level that does not recite the specific rules, data structures, algorithms, or steps that constitute the alleged improvement. In McRO the claims themselves recited a specific set of rules for setting morph weights and not merely described in the specification. Here, by contrast, the amended claim limitation merely states that analysis will be performed “against known commerce fields and logical alternatives” without defining what those fields are, what the rules for comparison are, how logical alternatives are identified or stored, or what specific algorithm governs the mapping. Under MPEP 2106.05(f), a claim that recites only the idea of a solution or outcome – i.e., the claim fails to recite details of how a solution to a problem is accomplished – does not integrate a judicial exception into a practical application. The amended limitation of Independent Claims, therefore, claims the result of field identification without restricting how that identification is accomplished. The algorithmic detail in Spec ¶¶ 33-45 cannot substitute for claim language under McRO and MPEP § 2106.05(a).
Applicant argues that the payment token “unique to a merchant” is a technical security mechanism improving security by isolating credentials to individual merchants, citing Spec. ¶ 31. Applicant argues the merchant specific characteristic distinguishes the token from generic tokenization and provides a concrete security improvement. Applicant’s Reply at 11.
Examiner respectfully disagrees.
The recitation of a “payment token that is unique to a merchant” is merely a functional description because it describes a property of the token without reciting any structural or algorithmic mechanism for generating, validating, or utilizing the token in a way hat improves computer technology. The specification itself acknowledges that payment tokens are known in the art, which conforms this feature relies on pre-existing, well understood technology rather than a novel technical contribution. Spec. ¶ 31 (“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.”). Further the claim merely recites receiving the payment token from an authentication authority and auto-filling it into a field, which is receiving and storing data that use a computer in its ordinary way. MPEP § 2106.05(f). Claiming a data element with a particular characteristic (merchant-specificity) without specifying the technical mechanism by which the characteristic improves computer operation is analogous to claiming a “barcode affixed to a mail object” without specifying how it is generated or processed, found insufficient in Secured Mail Sols. LLC v. Universal Wilde, Inc., 873 F.3d 905 (Fed. Cir. 2017).
Applicant argues the autofill step is not generic because it operates on fields “dynamically identified” through field analysis process, citing Spec. ¶¶ 44, 45, distinguishing it from insertion into pre-known fields. Applicant’s Reply at 12. Applicant argues this dynamic, analysis driven autofill represents a non-generic technical operation tied to a specific algorithmic output of the field analysis mechanism, which is an integrated process.
Examiner respectfully disagrees.
The “autofill” limitation is purely functional and recites only the result if the alleged field identification process (a field filled with payment data) without specifying in the claim itself how the dynamic field identification is performed, or which technical mechanism links the analysis output to the autofill action. Under MPEP 2106.05(f), a claim that recites only the idea of a solution or outcome – i.e., the claim fails to recite details of how a solution to a problem is accomplished – does not integrate a judicial exception into a practical application. The algorithmic detail in Spec ¶¶ 44, 45 cannot substitute for claim language under MPEP § 2106.05(a).
Applicant argues the ordered combination of extension-based architecture (Spec. ¶ 57), field mapping logic (Spec. ¶¶ 33-45) and merchant specific tokens (Spec ¶ 31) collectively improve computer technology and address the problems of browser scalability, interoperability, and security. Applicant’s Reply at 12.
Examiner respectfully disagrees.
The cumulative effect of the purely functional claim limitations does not become a specific technical improvement simply by aggregating them and pointing to implementation details in the specification that are absent from the claims themselves. The extension-based architecture, field analysis logic and merchant specific tokens recited in Independent Claims are merely functional. The claim says what the extension does bit not how it does any of these things in terms of specific code, data structures, or algorithms. Under MPEP § 2106.05(a), the claims must recite details regarding how a computer aids the method. It is not sufficient for the specification to supply those details if the claims do not recite them.
Applicant agues under Berkheimer, that Step 2B must focus on the ordered combination, not individual components, and that no cited specification paragraph describes the combination of dynamic field analysis, merchant-agnostic extension operation, and merchant specific tokens as routine or conventional. Applicant argues the Examiner has not citer prior art or taken official notice establishing this combination as conventional. Applicant also challenges the assertion that the claimed sequence is “the only logical order” noting that alternative architectures exist. Applicant’s Reply at 13–14.
Examiner respectfully disagrees.
The Berkheimer standard requires that the ordered combination of additional elements present a non-conventional arrangement. Examiner identified the additional elements, Final Act at 20 (“user device comprising processor and a memory comprising instructions; merchant website; web browser; an expedited payment extension; network; and a payment token”), but Applicant appears to create a sua sponte list of additional elements that the Examiner identified as forming part of the abstract idea without any explanation, which is conclusory. 37 CFR 1.111(b). Assuming, arguendo, Applicant’s identified features are in fact additional elements, which Examiner does not concede, when each element of the claimed invention combination is recited purely functionally (i.e., without structure or algorithmic specificity), there is no concrete combination of technical features to evaluate for conventionality. An ordered combination of functional outcomes (execute, obtain, communicate, receive, autofill, execute transaction) is not the same as an ordered combination of specific technical features and the former does not create an inventive concept simply because the specification describes a more detailed implementation. On the merits, Spec. ¶¶ 19, 20, 21, 24, 25, 29, 31, 43, 44, 45, 47, 48, 55, 56, 57, as explained in the Final Office Action (Final Act. at 25) demonstrate the individual elements – browser extensions, form autofill, authentication process, and payment tokens – are all acknowledged as known techniques. Applicant bears the burden of demonstrating the particular combination is non-conventional when the specification itself does not establish that the combination at the functional level recited in the claims is unconventional. Applicant’s Reply at 14.
Applicant argues that the ordered combination of (1) browser-resident extension for multiple merchant systems, (2) field analysis against known commerce fields and logical alternatives, and (3) merchant specific tokens auto filled into dynamically identified fields constitutes significantly more that using a token to pay and an improvement in browser-based payment processing and security.
Examiner respectfully disagrees.
This argument is unpersuasive for the same reasons as the prior response, supra, and adds that under Step 2B the questions is not whether the specification describes a non-conventional arrangement but whether the claimed elements – as an ordered combination – amount to significantly more that the abstract idea. Under Alice, merely requiring generic computer implementation fails to transform an abstract idea into a patent-eligible invention and the functional recitations in representative Claim 31, for example, amount to nothing more than applying the abstract idea of processing a payment applied using a browser extension, a network, and an authentication authority – all conventional components performing conventional functions. Applicant has not identified any specific structural arrangement, algorithm, or code level implementation in the claims themselves that would constitute an inventive concept and the specifications more detailed description cannot substitute for claim language that actually captures that detail.
Applicant agues hat dependent claims including Claims 22/32 (merchant identification), 27/30/39 (fraud analysis), and new Claim 41 (content script executing in the context of the merchant website, configured to analyze open fields and autofill payment data per Spec. ¶ 21) add technical implementation beyond the abstract idea. Applicant argues the content script is not a mental process or printed matter.
Examiner respectfully disagrees.
Under Step 2B, the dependent claims do not add significantly more because they continue the pattern of purely functional language without structural or algorithmic specificity. New Claim 41 is still functional language describing what the content script does (analyzes open fields, autofills) without specifying the structure, algorithm, or technical implementation by which it does so. While Spec. ¶ 21 generally describes conte scripts as JavaScript executing in the page context, the claim adds only the label “content script” and the same functioning outcomes of field analysis and autofill already recited in the independent claim. Under MPEP § 2106.05(a), the claims must include the components or steps that provide the improvement. Stating that a content script is “configured to” perform the same abstract functional steps as the base claim does not cure the lack of algorithmic or structural specificity. It is not sufficient for the specification to supply those details if the claims do not recite them.
35 U.S.C. § 103 Argument
Applicant’s arguments with respect to Claims 21–40 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
Claim Interpretation
Under the broadest reasonable interpretation, the following claim terms are presumed to have their plain meaning consistent with the specification as it would be interpreted by one of ordinary skill in the art. MPEP § 2111.
Claim term logical alternatives was considered for rejection under 112(b) as a relative term but the specification provides a basis. Spec. ¶ 43 (“‘Town’ may also mean ‘City’ or ‘Village’ and the system may have the intelligence to know that City data may be inserted where the web site in the browser 201 asks for Town data.”). Thus, under BRI in view of Applicant’s Specification ¶ 44, “logical alternatives” are synonyms in checkout form labels.
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 21–41 are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (i.e., an abstract idea) without significantly more.
Analysis
Step 1: Claims 21–41 are directed to a statutory category. Claims 21–30 and 41 recite a “method” and are therefore, directed to the statutory category of a “process.” Claims 31–39 recite a “device” and are therefore, directed to the statutory category of a “machine.” Claim 40 recites a “method” and is therefore, directed to the statutory category of a "process.”
Representative Claim
Claim 31 is representative [“Rep. Claim 31”] of the subject matter under examination and recites, in part, emphasis added by Examiner to identify limitations with normal font indicating the abstract idea exception, bold limitations indicating additional elements. Each limitation is identified by a letter for later use as a shorthand notation in referencing/describing each limitation. Portions of the claim use italics to identify intended use limitations1 and underline, as needed, in further describing the abstract idea exception:
[A] 31. A device comprising processor and a memory, wherein the memory comprises instructions executable by the processor to:
[B] access a merchant website2 via a web browser;
[C] receive an execute action [request to make a payment transaction] to start an expedited payment extension in the web browser;
[D] execute the expedited payment extension in the web browser based on receiving the execute action [request to make a payment transaction],
[D1] wherein the expedited payment extension comprises computer instructions downloadable to the web browser and is configured to work with a plurality of online merchant systems having different checkout [web] pages by analyzing open fields of merchant websites against known commerce fields and logical alternatives to identify fields for autofilling payment data;
[E] obtain, via the expedited payment extension executing in the web browser, authentication data;
[F] communicate the authentication data to an authentication authority [computer] over a network;
[G] receive an authentication approval and payment data from the authentication authority [computer] based on communicating the authentication data to the authentication authority [computer],
[G1] wherein the payment data comprises a payment token that is unique to a merchant associated with the merchant website;
[H] autofill, via the expedited payment extension, the payment data comprising the payment token into a field of the web browser; and
[I] execute a [payment] transaction in the web browser based on receiving the authentication approval and autofilling the payment data comprising the payment token.
Claims are directed to an abstract idea exception.
Step 2A, Prong One: Rep. Claim 31 recites “execute a [payment] transaction … based on receiving the authentication approval and autofilling the payment data,” in Limitation I, which recites commercial or legal interactions under the organizing human activity exception because “execut[ing] a [payment] transaction” with “payment data” describes “sales activities or behaviors, and business relations.” MPEP § 2106.04(a)(2)(II)(B). Conducting an online payment transaction with an intermediary using a tokenized payment token is analogous to Alice, where “intermediated settlement” was treated as a fundamental economic practice. Limitations B–H are the required steps and data gathering inputs required to “execute a [payment] transaction” and therefore, recites the same exception. Id.
Step 2A, Prong Two: Rep. Claim 31 does not contain additional elements that integrate the abstract idea exception into a practical application because the additional elements are mere instructions to apply the abstract idea exception. MPEP § 2106.05(f). The additional elements are limited to the computer components and indicated in bold, supra. The additional elements are: A device comprising processor and a memory comprising instructions; web browser; an expedited payment extension; Limitation D1, am authentication authority [computer]; network; and a payment token that is unique to a merchant associated with the merchant website.
Regarding the device comprising processor and a memory comprising instructions; web browser; an expedited payment extension; Limitation D1, am authentication authority [computer]; network; and a payment token that is unique to a merchant associated with the merchant website, Applicant’s Specification does not otherwise describe them or describes them using exemplary language as a general-purpose computer, as a part of a general-purpose computer, or as any known and exemplary (generic) computer component known in the prior art. Thus, Applicant takes the position that such hardware/software is so well known to those of ordinary skill in the art that no explanation is needed under 35 U.S.C. § 112(a). Lindemann Maschinenfabrik GMBH v. Am. Hoist & Derrick Co., 730 F.2d 1452, 1463 (Fed. Cir. 1984) (citing In re Meyers, 410 F.2d 420, 424 (CCPA 1969) (“[T]he specification need not disclose what is well known in the art”). E.g., Spec. ¶ 19 (“The figures depict a preferred embodiment for purposes of illustration only. One skilled in the art may readily recognize from the following discussion that alternative embodiments of the structures and methods illustrated herein may be employed without departing from the principles described herein.”); ¶ 20 (web browser described generically as assisting user interaction with networks including the World Wide Web, with extensions adding functionality); ¶¶ 20, 21 (generic, known, and exemplary extension written in almost any computer language); ¶ 55 (“For example, a user that needs large print may be able to configure the payment extension to use a large and easy to read font.”); ¶ 24 (“the extension 207 may allow a plurality of payment devices 209 (Fig. 2c) (for example and not limitation, a credit card, a loyalty card, a debit card, a brokerage account, etc.) to be used”); ¶ 21 (“an extension may be a zipped bundle of files-HTML, CSS, JavaScript, images, and anything else needed-that adds functionality to the browser.”); ¶ 23 (extension described as integrated into browser “or other computing application” without limitation); ¶ 47 (“a plurality of payment devices 209 may be added to the expedited payment system such as credit cards, debit cards, loyalty cards, coupons, airline miles, bitcoins, etc. Any of these forms of value may be selected and used.”); ¶ 57 (“First, using an expedited payment service requires that a merchant add a plug in (or additional computer instructions) to the merchant web site to make the expedited payment service operate with the merchant web site. Considering the extreme number of merchant web sites, the addition of the expedited payment service computer instructions would require an extreme amount of work by many, many parties. By creating an extension 207, sufficient computer instructions can be downloaded into a browser 201 and may be able to work with virtually any online merchant system with no work from the merchant.”); ¶ 56 (browser and extension described as using “a processor, a memory and an input-output circuit” generically, noting processors “not shown” and may be any processor “in communication with a network of computing devices”), ¶ 57 (generic, known, and exemplary computer-executable instructions mentioned by name only), ¶¶ 20, 21 (generic, known, and exemplary extension written in almost any computer language), ¶ 29 (authentication authority described as a payment processing network, a “dedicated network” presented as a known entity (computer)); ¶ 31 (payment token described as “becoming more and more common” and known to the payment processor)
Regarding a payment token that is unique to a merchant associated with the merchant website, Applicant’s Specification does not otherwise describe them or describes them using exemplary language as part of a general-purpose computer, so Examiner concludes Applicant intended merely generic computer components. E.g., Spec., ¶ 31 (generic, known, and exemplary payment token). Limitation G describes the function of the “payment token” being received, without further describing how it is generated, encoded, or decoded, except that it is unique to a merchant website. Applicant’s Specification further describes the payment token as “common” or known in the prior art at the time of filing for the invention. Spec., ¶ 31. Limitation H “auto-fill[s]” the payment token into at one least field of the web browser. The claims do not describe how this occurs. Applicant’s Specification teaches “the text of the website in the browser 201 may be read and may be compared to known open fields and logical alternatives.” Spec., ¶ 43. Further, field data “may be stored remotely but be available to be used to auto-fill the open fields on the website in the browser.” Id. Thus, the “auto-fill” of the payment token identifies field data, comparing it to known open fields and logical alternatives, receives the identified data from a remote storage location and auto-populates the fields with the received and remotely stored data “as if they were typed by the user.” Id. at ¶ 45. These Limitations merely invoke computers or other machinery in its ordinary capacity to receive, store, display, or transmit data. MPEP § 2106.05(f)(2). The auto-fill functions also recited at a high-level such that they could be reasonably performed in the human mind but for the recitation of the computer elements.
Regarding Limitation D1, is functional at the result level without any specific algorithm, data structure or improvement to how a browser or extension actually operates at a technical level. Results-orientated, functional descriptions that simply instruct a practitioner to implement the abstract idea on a computer are not enough to count as a practical application. Conceptually, this limitation is carrying out the core business idea: making online checkout work across many different merchant pages by mapping fields and auto filling payment data, like a human could do by reading form labels. This limitation is more of the abstract idea at this high level.
The generic processor, here, appears to perform calculations (functions) that are programmed by software. Spec. ¶¶ 21, 56, 57. This is a computer doing what it is designed to do—performing directions it is given to follow.
Limitation A recites the functions of the aforementioned computer components working together to transmit, receive, and store data between them, which merely invokes computers or other machinery in its ordinary capacity to receive, store, or transmit data in no particular way. MPEP § 2106.05(f)(2). Limitation A further describes the computer components performing the steps of the claimed invention, Limitations B–I, which represents the abstract idea exception itself. Performing the steps of the abstract idea exception itself simply adds a general-purpose computer after the fact to an abstract idea exception, MPEP § 2106.05(f)(2), or generically recites an effect of the judicial exception. MPEP § 2106.05(f)(3).
Therefore, the claim as a whole, looking at the additional elements individually and in combination, are no more than mere instructions to apply the exception using generic computer components and is not a practical application. MPEP § 2106.05(f). The additional elements do not integrate the abstract idea exception into a practical application because they do not impose any meaningful limits on the abstract idea exception. Accordingly, Rep. Claim 31 is directed to an abstract idea.
Rep. Claim 31 is not substantially different than Independent Claims 21 and 40 and includes all the limitations of Rep. Claim 31. Independent Claims 21 and 40 contain no additional elements not otherwise analyzed. Therefore, Independent Claims 21 and 40 are also directed to the same abstract idea.
The claims do not provide an inventive concept.
Step 2B: Rep. Claim 31 fails Step 2B because the claim as whole, looking at the additional elements individually and in combination, are not sufficient to amount to significantly more than the recited judicial exception. As discussed with respect to Step 2A, Prong Two, the additional elements in the claim amount to no more than mere instructions to apply the exception using a generic computer and/or generic computer components. MPEP § 2106.05(f). The same analysis applies here in Step 2B. Mere instructions to apply an exception using a generic computer and/or generic computer components cannot provide an inventive concept. MPEP § 2106.05(I).
The additional elements, taken individually and in combination, do not result in the claim, as a whole, amounting to significantly more than the identified judicial exception.
The pending claims, even when all additional elements are considered in combination, do not recite an inventive concept. First, as explained above, the claims are directed to an abstract idea (a method of organizing human activity related to online payment and checkout). Second, each additional element reflects generic, currently available computer technology used only in its ordinary manner (i.e., individually generic). Third, Applicant’s Specification confirms that the recited sequence and arrangement of these additional elements is merely exemplary and not technically specialized. See, e.g., Spec. ¶ 19 (figures depict only “a preferred embodiment” and alternative embodiments of the methods and structures may be employed) and ¶ 60 (invention can be “practiced otherwise than as specifically illustrated and described”). The Specification further describes the computer equipment and networks in purely generic terms, such as standard web browsers and browser extensions implemented with familiar web technologies (HTML, CSS, JavaScript) (Spec. ¶¶ 20, 21), a payment processing network characterized only as a “dedicated network” for routing payment data (Spec. ¶ 29), merchant-specific payment tokens that are “becoming more and more common” (Spec. ¶ 31), and a browser/extension using a conventional processor, memory, I/O circuitry and networks to execute “computer executable instructions” (Spec. ¶ 56).
Thus, the Examiner finds that the additional elements of representative Claim 31 are elements that have been recognized as well-understood, routine, and conventional (“WURC”) in the relevant field, based on Applicant’s own disclosure3 and the nature of the recited functionality. See, Spec. Spec. ¶¶ 19, 20, 21, 22, 24, 25, 29, 31, 43, 44, 45, 47, 48, 55, 56, 57; MPEP § 2106.05(d). Specifically, Applicant’s Specification makes clear that the additional elements—i.e., the device comprising processor and a memory comprising instructions; web browser; an expedited payment extension; Limitation D1, am authentication authority [computer]; network; and a payment token that is unique to a merchant associated with the merchant website—are all implemented using generic computer components and conventional network/payment infrastructure. These elements merely “apply” the abstract idea of conducting an online payment transaction and autofilling checkout forms using known computing platforms (e.g., a processor, memory, browser, extension, and payment network), rather than providing any technological improvement to those platforms.
The Examiner also finds that the recited operations of receiving, communicating/transmitting, receiving (again), autofilling, and executing a transaction based on payment and authentication data in Claim 31 amount to nothing more than routine computer functions of receiving, storing, transmitting, displaying, and processing data, as performed by generic processors, memory, browsers, and networks. Courts and the MPEP identify such generic computer functions—when claimed at a high level of generality, as here—as examples of WURC activity that do not add “significantly more” to an abstract idea. MPEP § 2106.05(d).
There is no indication that the combination of elements improves the functioning of a computer or improves any other technology. Thus, taken alone, the additional elements do not amount to significantly more than the above-identified judicial exception (the abstract idea). Looking at the additional elements in combination adds nothing that is not already present when looking at the elements individually. Their collective functions merely provide conventional computer implementation of the abstract idea at a high level of generality. Thus, Rep. Claim 31 does not provide an inventive concept.
Rep. Claim 31 is not substantially different than Independent Claims 21 and 40 and includes all the limitations of Rep. Claim 31. Independent Claims 21 and 40 contain no additional elements not otherwise analyzed. Therefore, Independent Claims 21 and 40 also do not recite an inventive concept.
Dependent Claims Not Significantly More
The dependent claims have been given the full two-part analysis including analyzing the additional limitations both individually and in combination. The dependent claim(s) when analyzed both individually and in combination are also held to be patent ineligible under 35 U.S.C. § 101. Dependent claims are dependent on Independent Claims and include all the limitations of the Independent Claims. Therefore, all dependent claims recite the same Abstract Idea. Dependent claims do not contain additional elements that integrate the abstract idea exception into a practical application or recite an inventive concept because the additional elements: (1) are mere instructions to apply the abstract idea exception; and/or (2) further limit the abstract idea exception of the Independent Claims. The abstract idea itself cannot provide the inventive concept or practical application. MPEP §§ 2106.05(I), 2106.04(d)(III).
Dependent Claims 22, 23, 24, 25, 27, 28, 30, 32, 33, 34, 35, 36, 37, 38, and 39 all recite “wherein” clauses or limitations that further limit the abstract idea of the Independent Claims and contain no additional elements. The “analyze” or “analysis” steps recited in Dependent Claims 27, 30, and 39, recite mental processes that are practically performed in the human mind or with pen and paper because it requires mere “observation, evaluation, judgment, and/or opinion.” The “analyze” or “analysis” steps recited in Dependent Claims 27, 30, and 39 cover any solution to analyzing/analysis with no restriction on how the result is accomplished and no description of the mechanism for accomplishing the result, which is so broad as to encompass mental processes. The further limiting of authentication data in Dependent Claims 22, 24, 32, 34, and 36, is printed matter not functionally related to the computer and given no patentable weight. MPEP § 2111.05. An inventive concept or practical application cannot be furnished by an abstract idea exception itself. MPEP §§ 2106.05(I), 2106.04(d)(III).
Dependent Claims 26 and 29 recite additional limitations that form part of the same abstract idea exception as recited in Independent Claims and contain no additional elements. The further limiting of authentication data in Dependent Claim 26 is printed matter not functionally related to the computer and given no patentable weight. MPEP § 2111.05. An inventive concept or practical application cannot be furnished by an abstract idea exception itself. MPEP §§ 2106.05(I), 2106.04(d)(III).
Dependent Claim 41 recites a “wherein” clause or limitation that further limits the abstract idea of the Independent Claims and contains the additional elements of: a content script. Applicant’s Specification teaches that browser extensions can use “content scripts” that execute in the context of a loaded page, can read page details, and change the page. Spec. ¶ 21. A content script is described as a familiar generic mechanism implemented with HTML, CSS, and JavaScript. Claim 41 is not a practical application because it is merely functional/results-orientated with no algorithm, data structure, or browser improvement. It merely narrows where the in the browser architecture the same abstract idea runs (i.e., in a content script versus some other extension code). The specification itself characterizes content scripts as the standard way extensions interact with web pages, and thus, well understood routine and conventional.
Conclusion
Claims 21–41 are therefore drawn to ineligible subject matter as they are directed to an abstract idea without significantly more. The analysis above applies to all statutory categories of invention. As such, the presentment of Rep. Claim 31 otherwise styled as another statutory category is subject to the same analysis.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (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.
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 21–41 are rejected under 35 U.S.C. 103 as being unpatentable over Siegal et al. (U.S. Pat. Pub. No. 2009/0177587) [“Siegal”] in view of Oborne (U.S. Pat. No. 2012/0316992) [“Oborne”] and further in view of Rawat et al. (U.S. Pat. Pub. No. 2020/0156846) [“Rawat”]
Regarding Claim 21, Siegal discloses:
A method comprising:
(See at least ¶ 11, “one of the payment methods taught herein comprises receiving from the e-commerce merchant payment transaction details relating to an e-commerce purchase being conducted by the user at the e-commerce merchant website.” “Online terminal 102 contains software necessary for an online authentication process such as the one described herein. Such software may include a web browser 106, device drivers 108 to communicate with BSD 104, and a downloaded web browser component 110 (e.g., ActiveX controls, Java applets, and/or other ''plug-in" components etc.) for managing BSD 104 and enabling communication between BSD 104 and APS 100.” ¶ 19.)
receiving, by a user device, an execute action to start an expedited payment extension in a web browser, wherein the web browser is accessing a merchant website;
(Examiner interprets “execute action” as “mouse click” in view of Applicant’s Specification, ¶ 22. See at least ¶ 32, “During an e-commerce payment transaction, the user may peruse the merchant's e-commerce website, adding goods to his electronic shopping cart (as managed by merchant web server 112) until he is ready to checkout. When the user engages the merchant's checkout process (e.g., by clicking a checkout button) (step 402), the merchant web server 112 may transmit a payment message to the payment management component 128 of the APS 100 (step 404).” The user performs checkout on “a user’s personal computer” using “a web browser 106.” ¶ 19.)
executing, by the user device, the expedited payment extension in the web browser based on receiving the execute action,
(See at least Fig. 4, step 404, and associated text ¶ 32, cited supra, where after clicking the checkout button, “the merchant web server 112 may transmit a payment message to the payment management component 128 of the APS 100 (step 404).” “Online terminal 102 contains software necessary for an online authentication process such as the one described herein. Such software may include a web browser 106, device drivers 108 to communicate with BSD 104, and a downloaded web browser component 110 (e.g., ActiveX controls, Java applets, and/or other ''plug-in" components etc.) for managing BSD 104 and enabling communication between BSD 104 and APS 100. … The web browser component 110 in the web browser 106.” ¶ 19; see also ¶¶ 24, 31.)
wherein the expedited payment extension comprises computer instructions downloadable to the web browser and
(See at least ¶ 19, “Online terminal 102 contains software necessary for an online authentication process such as the one described herein. Such software may include a web browser 106, device drivers 108 to communicate with BSD 104, and a downloaded web browser component 110 (e.g., ActiveX controls, Java applets, and/or other ''plug-in" components etc.) for managing BSD 104 and enabling communication between BSD 104 and APS 100. … The web browser component 110 in the web browser 106.” ¶ 19; see also ¶ 24 (“the user then downloads … and installs a web browser component 110 (e.g., ActiveX control or other browser plug-in or browser helper object) (step 204)”).
[…, Rawat]
obtaining, by the expedited payment extension executing in the web browser, authentication data;
(See at least ¶ 19, “Online terminal 102 contains software necessary for an online authentication process such as the one described herein. Such software may include a web browser 106, device drivers 108 to communicate with BSD 104, and a downloaded web browser component 110 (e.g., ActiveX controls, Java applets, and/or other ''plug-in" components etc.) for managing [biometric sensor device] BSD 104 and enabling communication between BSD 104 and APS 100.” See also, ¶¶ 29, 30 where “a biometric authentication enabled website” triggers the “biometric sensor device (BSD)” attached to a user’s computer to collect a biometric sample from the user for authentication.)
communicating, by the user device, the authentication data to an authentication authority over a network;
(See at least ¶ 30 where the “biometric sensor device (BSD) transmits biometric information to the authentication sever 118 of the “Authentication Provider System (APS) 100.” See also, Figs. 1, 3. “BSD 104 may alternatively be integrated into online terminal 102 … Online terminal 102 contains software necessary for an online authentication process … enabling communication between BSD 104 and APS 100.Online terminal 102 is connected via a network, such as the Internet.” ¶ 19.)
receiving, by the user device, an authentication approval and payment data from the authentication authority based on communicating the authentication data to the authentication authority, wherein the payment data comprises a payment token that is unique to a merchant associated with the merchant website;
(See at least ¶ 30, “If a matching stored user identity is found, the OSP web server 112 establishes a secure connection (e.g., SSL connection) with the user's web browser 106 on online terminal 102 and the user is logged in (step 318). … The authenticated user may now proceed to utilize logged in functionality on the OSP website.” Figs. 1, 3.
For the payment data features, see at least ¶ 33, where the payment management component 128 [of the Authentication Provider System 100, Fig. 1] transmits an approval message to the merchant web server 112, including the transaction identifier and the user's federated identity, thereby indicating to the merchant web server 112 that the transaction has been approved.” The “user’s federated identify” is a token. ¶ 30 (“The federated identity could be communicated or encoded, for example, as a SAML token.”). The user’s federated identify (or token) comprises payment data. Applicant’s Specification teaches “payment data 213” may be “Card number,” “expiration,” “Billing Address,” “Order” Information including “Product” and “Price” information, “Ship to” address, and “name”. Spec., ¶ 32, Figs. 2a, 4d. The user’s federated identify may contain, for example, similar data elements such as, “a user's name, email address, phone number, shipping address or other user information. In one embodiment, such federated identity and user information may be submitted to the merchant web server 112 in the payment transaction approval message in step 418.” ¶ 35. The “payment token” is unique to the merchant website. ¶ 35 (“the payment management component 128 may interact with federated identity directory 122 to generate a new federated identity for the user that is particular to this merchant and transmit relevant user information”). See also, ¶ 25.)
autofilling, by the user device executing the expedited payment extension in the web browser, the payment data […] into a field of the web browser; and
(See at least ¶ 36, “the authenticated user's electronic wallet information could be transmitted by the payment management component 128 to web browser 106 in order to populate required fields (e.g., in an OSP web page residing on user web browser 106) for payment authorization, such as full user name, account number, expiration date, billing address, etc.” ¶ 21 (same). Applicant’s Specification teaches “payment data 213” may be “Card number,” “expiration,” “Billing Address,” “Order” Information including “Product” and “Price” information, “Ship to” address, and “name”. Spec., ¶ 32, Figs. 2a, 4d.)
executing, by the user device executing the expedited payment extension in the web browser, a transaction in the web browser based on receiving the authentication approval and autofilling the payment data […].
(See at least ¶¶ 33, 34, where payment details are presented and selected in a web browser executing the merchant’s checkout process (payment extension). The payment management component receives approval from the web browser 106 and the payment details are sent to a payment processor 130. The transaction is executed in based on “establishes a secure connection (e.g., SSL connection) with the user's web browser 106 on online terminal 102 and the user is logged in (step 318)” (authentication approval), ¶ 30, and “the authenticated user's electronic wallet information could be transmitted by the payment management component 128 to web browser 106 in order to populate required fields (e.g., in an OSP web page residing on user web browser 106) for payment authorization” (auto-filling payment data). ¶ 36.)
Siegal discloses receiving payment data from the authentication authority, wherein the payment data comprises a payment token that is unique to the merchant website. Segal discloses auto-filling payment data but not auto-filling payment data comprising the payment token. Siegal discloses executing a transaction based on auto-filling the payment data but not executing a transaction based on auto-filling the payment data comprising the payment token. Thus, Siegal does not disclose but Oborne discloses:
receiving, by the user device, an authentication approval and payment data from the authentication authority based on communicating the authentication data to the authentication authority, wherein the payment data comprises a payment token that is unique to the merchant website;
(Siegal discloses this limitation but alternatively, Oborne, see at least Fig. 2A and associate text ¶ 26, “a user may be required to provide a user name and password to activate a payment token [authentication approval; see also ¶ 33] … Thus, the system provides an authenticity shield preventing others who may know of the user's payment token from utilizing the user's payment token in a fraudulent transaction.” One the user is authenticated, “the PPT may generate, e.g., in real-time, a one-time anonymous set of card details to securely complete the purchase transaction (e.g., "Anon It IX").” ¶ 28. “[T]he user may select to conduct the transaction using a one-time token, e.g., an anonymized credit card number, see e.g., 205b. For example, the PPT may utilize a tokenized and anonymized set of card details (see, e.g., "AnonCardl," "AnonCard2").” ¶ 28. As described in ¶ 28, the payment token is received at the user device as shown in Fig. 2A, element 205b. A “one-time anonymous set of card detail to securely complete the purchase transaction” is unique to the merchant website.)
the payment data comprising the payment token
(See at least Fig. 1A, where a user provides a payment token in step 115a from their client user device 111a, on a merchant website 113 to make a purchase. Figs. 4, 6A–E.)
It would have been obvious to one of ordinary skill in the art as of the effective filing date of the claimed invention, to have combined payment data comprising a payment token as explained in Oborne, to the known invention of Siegal, with the motivation to “secur[e] user data and prevent[ ] fraud,” Oborne, ¶ 8, and to maintain user anonymity for compliance with “privacy regulations specific to the country code” for routing “the token and payment processing to payment servers in the appropriate country” to “prevent [ ] the user’s private information from being seen in inappropriate jurisdictions.” Oborne, ¶ 23.)
It would have been obvious to one of ordinary skill in the art as of the effective filing date of the claimed invention, to have combined payment data comprising a payment token as explained in Oborne, to the known invention of Siegal, with the motivation to “secur[e] user data and prevent[ ] fraud,” Oborne, ¶ 8, and to maintain user anonymity for compliance with “privacy regulations specific to the country code” for routing “the token and payment processing to payment servers in the appropriate country” to “prevent [ ] the user’s private information from being seen in inappropriate jurisdictions.” Oborne, ¶ 23.)
Siegal does not disclose but Rawat disclose:
the expedited payment extension … is configured to work with a plurality of online merchant systems having different checkout pages
(See at least ¶ 20, “a typical HTML form 100 includes a plurality of fields 101 that must be filled out by the user, for example, when making an online purchase, or registering at a web site.” “[A]n intelligent form-filler that does not require any prior mapping or examination of the forms. Client-side program code examines electronic documents such as web pages and automatically fills in fields of forms contained in the document with the appropriate data from a user profile, without requiring prior mapping or examination of the form.” ¶ 15. Rawat emphasize that it can populate “any web-based form: without stored templates or prior mapping. ¶¶ 13–15.)
by analyzing open fields of merchant websites
(See at least ¶ 23, “by analyzing open fields of merchant websites against known commerce fields and logical alternatives to identify fields for autofilling payment data. In a first step, the logic traverses the form from beginning to end, locating the field labels, associating them with a field, and then mapping the field to the correct metadata based on a best match from a field label dictionary 304.” “In a preferred embodiment, the method
is implemented as a JAVASCRIPT function that analyzes forms in a target window and maps each identified form element to the correct user data.” ¶ 25. “Checkout Form Detection, [0075] The program code object has a flag, which is set whenever a Billing or Shipping Address field or a Credit Card field is identified to indicate the form is a checkout form.” ¶ 75.)
against known commerce fields and logical alternatives to identify fields for autofilling payment data;
(See at least ¶¶ 30–35, “The invention matches the values with the dictionaries previously described to map the fields to metadata, wherein metadata comprises a data type, such as [0031] Last name; [0032] First name; [0033] AddressLine 1; [0034] AddressLine 2; and [0035] City.” “[T]he analyzed expression is compared with a listing of similar expressions in the field label dictionary to find the closest match. The dictionary expressions, analogs of the analyzed expression, are organized according to metadata. Thus, when a match is found, the field corresponding to the field label is mapped to that metadata 404.” See also, ¶¶ 54–61 (mapping). Context and rules are used to infer labels that are missing or ambiguous. “There may be cases when a field doesn't have a label. For example, two or three fields may be provided for street address. Often they are labeled "Address l" and "Address 2," or something similar. But the first field may only be labeled "Address" and the second address field may not bear a label at all. In such a case, it is possible to map the second field according to its context. Mapping according to context requires that the field immediately preceding the field of interest have been mapped. As fields are mapped during the first pass, the algorithm assumes maximum granularity of the data. Thus, in the case of an unlabeled field that follows a field labeled 'address;' the 'address' field would have been mapped to the metadata "AddressLine l." It is probable that an unlabeled field following a "AddressLine l" field is an "AddressLine 2" field. Accordingly, the unlabeled field will be mapped to the metadata "AddressLine 2." ¶ 48. See also ¶¶ 23, 24, 50–53, 70, 71. “Client-side program code examines electronic documents such as web pages and automatically fills in fields of forms contained in the document with the appropriate data from a user profile,” ¶ 15. Example forms include “making an online purchase. ¶ 20; see also ¶¶ 55–58. “The program code object has a flag, which is set whenever a Billing or Shipping Address field or a Credit Card field is identified to indicate the form is a checkout form. Thus, the invention also provides checkout form detection functionality.”
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, to have combined the expedited payment extension configured to work with a plurality of online merchant systems having different checkout pages by analyzing open fields of merchant websites against known commerce fields and logical alternatives to identify fields for autofilling payment data, as explained in Rawat, to the known invention of Siegal, in the same field of invention, with the motivation to eliminate per-merchant integration work and user re-keying of payment information by enabling Siegal’s browser components to automatically recognize and populate arbitrary checkout forms across many merchants in a predictable, scalable way.
Regarding Claim 22, Siegal, Oborne, and Rawat disclose:
The method of claim 21 and authentication data
Siegal further discloses
further comprising identifying, by the expedited payment extension executing in the web browser, the merchant associated with the merchant website.
(See at least ¶ 20, “Such a federated identity and a session ID (e.g., related to the user's particular transaction and obtained by the APS 100 via communication with the web browser component 110 … may utilize such user identification information to obtain from the federated identity directory 122 a federated identity … associated with the user and the particular OSP [merchant] (e.g., as identified by an OSP ID and certificate or other OSP identifying information received by the APS 100 through the web browser component 110) pertaining to the transaction at hand.”)
Regarding Claim 23, Siegal, Oborne, and Rawat disclose:
The method of claim 21 and receiving the execute action
Siegal further discloses
wherein receiving the execute action comprises receiving, by the user device, a mouse click.
(See at least ¶ 32, “During an e-commerce payment transaction, the user may peruse the merchant's e-commerce website, adding goods to his electronic shopping cart (as managed by merchant web server 112) until he is ready to checkout. When the user engages the merchant's checkout process (e.g., by clicking a checkout button) (step 402), the merchant web server 112 may transmit a payment message to the payment management component 128 of the APS 100 (step 404).”)
Regarding Claim 24, Siegal, Oborne, and Rawat disclose:
The method of claim 21 and the authentication data
Siegal further discloses
wherein the authentication data comprises a password for a sign in name that is stored by the user device.
(Examiner interprets the italicized limitation as intended use because it describes the purpose of the function being claimed (i.e., authentication data comprises a password). Accordingly, statements of intended use fail to limit the scope of the claim under BRI. MPEP § 2103(I)(C). See at least ¶ 24, “the user navigates to the OSP website and logs in using his existing username and password (step 202).”)
Regarding Claim 25, Siegal, Oborne, and Rawat disclose:
The method of claim 21 and the network
Siegal further discloses
wherein the network comprises a dedicated network that receives the payment data and communicates the payment data to entities of the transaction.
(See at least ¶ 22, “a dedicated TCP/IP connection between the payment processor 130 and the ASP 100 may be used.”)
Regarding Claim 26, Siegal, Oborne, and Rawat disclose:
The method of claim 21 and the authentication data
Siegal further discloses
further comprising receiving, by the user device, a selection of a payment device from a plurality of payment devices,
(See at least ¶ 33, “the payment management component 128 is able to present the payment details (e.g., user's credit card or debit card or eCheck information, etc.) to the web browser 106 and request selection of a desired payment type (e.g., where multiple payment types are available and/or the user has not already predefined a default payment type) and a confirmation from the user of the transaction details (e.g., amount, description of purchase, etc.) (step 414). Once the payment management component 128 receives approval from the web browser 106, it is able to mark the transaction in the queue as approved and forward the payment details (e.g., user's credit card or debit card or eCheck information, merchant's account, etc.) to payment processor 130 to accept the transaction (step 416).”
Siegal discloses authentication data. Siegal does not disclose authentication data comprises an amount available to spend on the selected payment device. Thus, Siegal does not disclose but Oborne discloses:
wherein the authentication data comprises an amount available to spend on the selected payment device.
(Examiner interprets the italicized limitation as intended use because it describes the purpose of the function being claimed (i.e., the authentication data comprises an amount available). Accordingly, statements of intended use fail to limit the scope of the claim under BRI. MPEP § 2103(I)(C).
See at least Fig. 2A (right view), element 207, “Rewards1: $128” and “Rewards2: $256,” which are amounts available. See also, ¶¶ 61, 71.
It would have been obvious to one of ordinary skill in the art as of the effective filing date of the claimed invention, to have combined authentication data comprises an amount available as explained in Oborne, to the known invention of Siegal, with the motivation to
“determine whether the user has a sufficient balance remaining in the account, sufficient credit associated with the account, and/or the like.” Oborne, ¶¶ 61, 71.)
Regarding Claim 27, Siegal, Oborne, and Rawat disclose:
The method of claim 21 and the authentication authority
Siegal further discloses
wherein the authentication authority analyzes the authentication data for fraud.
(Examiner interprets the italicized limitation as intended use because it describes the purpose of the function being claimed (i.e., the authentication authority analyzes the authentication). Accordingly, statements of intended use fail to limit the scope of the claim under BRI. MPEP § 2103(I)(C).
See at least ¶ 30, “The BSD 104 is instructed by the web browser component 110 … to collect a biometric sample … (step 308). … BSD 104 returns a biometric sample template to the web browser component 110, which may relay the template to the authentication server 118 … (step 310). The authentication server 118 utilizes the previously received BSD 104 device identification information to locate registered user biometric templates stored in the biometric directory 120 in association with the BSD 104 device identification information (e.g., unique device number) and compares the registered user biometric templates with the collected biometric sample templates … (step 312). If the comparison results in a match, the internal user identifier (e.g., user identification number) associated with the matched bio-metric template is used in combination with the OSP 112 identifier to locate in federated identity directory 122 a federated identity for that user particular to the OSP website being accessed, and the federated identity is transmitted to OSP web server 112 via web browser component 110 (step 314). … The OSP web server 112 maps the federated identity to a previously stored user identity in OSP database 114 ( step 316). If a matching stored user identity is found, the OSP web server 112 establishes a secure connection (e.g., SSL connection) with the user's web browser 106 on online terminal 102 and the user is logged in (step 318). The OSP web server 112 may send a completion response to identity management component 116. The authenticated user may now proceed to utilize logged in functionality on the OSP website.”)
Regarding Claim 28, Siegal, Oborne, and Rawat disclose:
The method of claim 21 and receiving the execute action
Siegal further discloses
wherein receiving the execute action to start the expedited payment extension in the web browser comprises receiving a selection [clicking] at a sidebar, a button, or a graphical user interface, or a combination thereof.
(Examiner interprets the italicized limitation as intended use because it describes the purpose of the function being claimed (i.e., receiving the execute action). Accordingly, statements of intended use fail to limit the scope of the claim under BRI. MPEP § 2103(I)(C).
See at least ¶ 32, “During an e-commerce payment transaction, the user may peruse the merchant's e-commerce website, adding goods to his electronic shopping cart (as managed by merchant web server 112) until he is ready to checkout. When the user engages the merchant's checkout process (e.g., by clicking a checkout button) (step 402), the merchant web server 112 may transmit a payment message to the payment management component 128 of the APS 100 (step 404).”
Regrading the location of the selection identified by underline, rearrangement of parts to a different location without modifying the operation of the device or without producing a novel or unexpected result, would be an obvious matter of design choice within the ordinary skill of the art. MPEP § 2144.04(VI)(C). Here, the underlined features describe the location of receiving the execute action to start the expedited payment extension in the web browser comprises receiving a selection and does not modify the operation of the selection or produce a novel or unexpected result by its location. Applicant’s Specification further teaches that the location of the “execute area” is a design choice not affecting its function. For example, Applicant’s Specification teaches the “extension area 205 … in a browser action bar”; Spec., ¶ 22; “integrated into a browser 201 or other computing application”; Spec., ¶ 23; “a sidebar such as in Figs. 4a–47, a miniature area such as in Figs. 3a–3c[,] and a miniature entry graphical user interface such as in Figs. 2a–2e.” Spec., ¶ 23. “The format of the extension 207 may take on a variety of forms.” ¶ 24. Thus, Applicant takes the position that the location of the extension area is merely a design choice, its location not affecting the function selection. Thus, these claimed features would be an prima facie obvious matter of design choice within the ordinary skill of the art. MPEP § 2144.04(VI)(C). However, should a reviewing court disagree, Siegal discloses said limitation. See Siegal, ¶ 32, “During an e-commerce payment transaction, the user may peruse the merchant's e-commerce website, adding goods to his electronic shopping cart (as managed by merchant web server 112) until he is ready to checkout. When the user engages the merchant's checkout process (e.g., by clicking a checkout button) (step 402).” Only one of the limitations is required.)
Regarding Claim 29, Siegal, Oborne, and Rawat disclose:
The method of claim 21 and autofilling
Siegal further discloses
further comprising autofilling, by the user device executing the expedited payment extension, a name, a billing address, [electronic wallet].
(See at least ¶ 36, the authenticated user's electronic wallet information could be transmitted by the payment management component 128 to web browser 106 in order to populate required fields (e.g., in an OSP web page residing on user web browser 106) for payment authorization, such as full user name, account number, expiration date, billing address, etc.” Only one limitation is required. Limitations not explicitly rejected are indicated by
Regarding Claim 30, Siegal, Oborne, and Rawat disclose:
The method of claim 21, executing the transaction in the web browser, and network
Siegal further discloses
wherein executing the transaction in the web browser comprises sending the payment data to the network, and
(See at least ¶ 33, “Once the payment management component 128 receives approval from the web browser 106, it is able to mark the transaction in the queue as approved and forward the payment details (e.g., user's credit card or debit card or eCheck information, merchant's account, etc.) to payment processor 130.”)
Siegal does not disclose but Oborne discloses:
wherein the network performs a verification analysis, a sufficient funds analysis, or a fraud analysis, or a combination thereof based on the payment data.
(See at least ¶ 61, “on obtaining the user data, e.g., 640a-n, the issuer server may determine whether the user can pay for the transaction using funds available in the account, e.g., 64la-n. For example, the issuer server may determine whether the user has a sufficient balance remaining in the account, sufficient credit associated with the account, and/or the like. Based on the determination, the issuer server (s) may provide an authorization response, e.g., 642a-n, to the pay network server.”)
It would have been obvious to one of ordinary skill in the art as of the effective filing date of the claimed invention, to have combined the network performs a verification analysis, a sufficient funds analysis, or a fraud analysis, or a combination thereof based on the payment data as explained in Oborne, to the known invention of Siegal, with the motivation to “determine whether the user has a sufficient balance remaining in the account, sufficient credit associated with the account, and/or the like.” Oborne, ¶¶ 61, 71.)
Regarding Claim 31, Siegal discloses
A device comprising processor and a memory, wherein the memory comprises instructions executable [software] by the processor to:
See at least Fig. 1, “online terminal 102” and associated text ¶ 19, “Online terminal 102 contains software necessary for an online authentication process such as the one described herein.” Oborne, ¶¶ 120, 169 (memory, processor, instructions))
The remaining limitations of Claim 31 are not substantively different than those presented in Claim 21 and are therefore, rejected, mutatis mutandis, based on Siegal, Oborne, and Rawat for the same rationale presented in Claim 21 supra.
The resolution of the remaining Graham factual inquiries to support a conclusion of obviousness that a particular known technique was recognized as part of the ordinary skill in the pertinent art is substantively the same as that presented in Claim 21 supra, and is incorporated in its entirety herein, mutatis mutandis, to support the rejection of Claim 31.
Regarding Claims 32, 33, 34, 35, 36, 38, and 39, Siegal, Oborne, and Rawat disclose:
The device of claim 31
The remaining limitations of Claims 32, 33, 34, 35, 36, 38, and 39, are not substantively different than those presented in Claims 22, 23, 24, 25, 26, 29, and 30, respectively, and are therefore, rejected, mutatis mutandis, based on Siegal, Oborne, and Rawat for the same rationale presented in Claims 22, 23, 24, 25, 26, 29, and 30, respectively, supra.
Regarding Claim 37, Siegal, Oborne, and Rawat disclose:
The device of claim 31 and the memory further comprises instructions executable by the processor
Siegal further discloses
wherein the memory further comprises instructions executable by the processor to display a sidebar, a button, or a graphical user interface [web browser 106], or a combination thereof in the web browser to receive the execute action to start the expedited payment extension.
(Examiner interprets the italicized limitation as intended use because it describes the purpose of the function being claimed (i.e., display a sidebar, a button, or a graphical user interface, or a combination thereof in the web browser). Accordingly, statements of intended use fail to limit the scope of the claim under BRI. MPEP § 2103(I)(C).
See at least ¶ 32, “When the user engages the merchant's checkout process (e.g., by clicking a checkout button) (step 402).” Fig. 1, “web browser 106”. Only one of the limitations is required.)
Regarding Claim 40, Siegal discloses
A method comprising:
(See at least ¶ 11)
The remaining limitations of Claim 40 are not substantively different than those presented in Claim 21 and are therefore, rejected, mutatis mutandis, based on Siegal, Oborne, and Rawat for the same rationale presented in Claim 21 supra.
The resolution of the remaining Graham factual inquiries to support a conclusion of obviousness that a particular known technique was recognized as part of the ordinary skill in the pertinent art is substantively the same as that presented in Claim 21 supra, and is incorporated in its entirety herein, mutatis mutandis, to support the rejection of Claim 40.
Regarding Claim 41, Siegal, Oborne, and Rawat disclose:
The method of claim 21 and executing the expedited payment extension in the web browser
Siegal does not disclose but Rawat discloses:
wherein executing the expedited payment extension in the web browser comprises executing a content script in a context of the merchant website,
(See at least Abstract, “Client side program code examines electronic documents such as web pages and automatically fills out fields of forms contained in the document with the appropriate data from a user profile, without requiring prior mapping or examination of the form.” “A client 301, in communication with a network 307, retrieves an HTML page
containing a web form 308 from a remote site on the network.” ¶ 22. “In a preferred embodiment, the method is implemented as a JAVASCRIPT function that analyzes forms in a target window and maps each identified form element to the correct user data.” Rawat’s forms are those for “making an online purchase.” ¶ 20.)
the content script being configured to analyze open fields of the merchant website and to autofill the payment data.
(See at least ¶ 23, “Logic 303 stored and executed on the client implements a probabilistic, rule-based method of analyzing the form in separate steps. In a first step, the logic traverses the form from beginning to end, locating the field labels, associating them with a field, and then mapping the field to the correct metadata based on a best match from a field label dictionary 304.” “In a preferred embodiment, the method is implemented as a JAVASCRIPT function that analyzes forms in a target window and maps each identified form element to the correct user data.” ¶ 25. Rawat’s forms include ecommerce forms, ¶ 20, and a checkout form detection flag set when billing/shipping/credit card fields are present. ¶ 75. After mapping, Rawat autofills the user profile. ¶ 24 (Finally, after the visible elements of the form have been completely mapped the correct user data is retrieved from a stored user profile 302, a data file stored on the client, and concatenated, truncated or re-formatted as required by the display format, and the form fields are populated with the data.”; see also ¶¶ 78. The metadata and form block types explicitly include commerce. ¶¶ 30–36, ¶¶ 55–58.)
The resolution of the remaining Graham factual inquiries to support a conclusion of obviousness that a particular known technique was recognized as part of the ordinary skill in the pertinent art is substantively the same as that presented in Claim 1 supra, and is incorporated in its entirety herein, mutatis mutandis, to support the rejection of Claim 41.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JAMES H MILLER whose telephone number is (469)295-9082. The examiner can normally be reached M-F: 10- 4 PM (EST).
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, Bennett M Sigmond can be reached at (303) 297-4411. 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.
/JAMES H MILLER/Primary Examiner, Art Unit 3694
1 Statements of intended use fail to limit the scope of the claim under BRI. MPEP § 2103(I)(C).
2 Identification of who you are paying, the commercial setting of the transaction.
3 See Changes in Examination Procedure Pertaining to Subject Matter Eligibility, Recent Subject Matter Eligibility Decision (Berkheimer v. HP, Inc.), 3–4 (Apr. 19, 2018) (USPTO Berkheimer Memorandum) (explaining that a finding that additional elements are well-understood, routine, and conventional may be supported by “a citation to an express statement in the specification or to a statement made by an applicant during prosecution that demonstrates the well-understood, routine, conventional nature of the additional element(s)”)
Prosecution Insights