DETAILED ACTION
Acknowledgements
This action is in response to Applicant’s filing on Dec. 29, 2025, 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 Dec. 29, 2025 has been entered.
Claim Status
The status of claims is as follows:
Claims 1–20 remain pending and examined Claims 1, 8, and 15 in independent form.
Claims 1, 6, 8, 15, and 19 are presently amended.
No Claims are added or cancelled.
Response to Amendment
Applicant's Amendment has been reviewed against Applicant’s Specification filed Dec. 29, 2016, [“Applicant’s Specification”] and accepted for examination.
Response to Arguments
35 U.S.C. § 101 Argument
Applicant argues the Office Action relies on outdated legal standards from 2019. Applicant cites multiple recent guidance documents including MPEP 9th Ed. Rev. 01.2024 (Nov 2024), July 2024 AI-SME Update, July 2024 Subject Matter Eligibility Examples, and August 4, 2025 USPTO Memo on 101 rejections. Applicant’s Reply at 8–9.
Examiner respectfully disagrees.
Examiner is familiar with recent guidance and has applied current standards in evaluating the claims. The guidance does not change the fundamental Alice/Mayo framework, and regardless of when standards were articulated, the claims remain directed to an abstract idea of managing financial information in retail transactions. Recent guidance emphasizes proper application of existing law, not wholesale changes to eligibility analysis.
Applicant argues the August 4, 2025 memo establishes that examiners should only reject claims when it is "more likely than not (>50%)" that claims are ineligible. This creates a preponderance of evidence standard and presumption in favor of eligibility for close calls. Applicant’s Reply at 9–10.
Examiner respectfully disagrees.
The claims are not a close call. Examiner has evaluated the claims under the preponderance standard and concludes it is more likely than not (>50%) that the claims are directed to an abstract idea without significantly more. The claims recite generic computer components performing data collection, transmission, and display activities that are fundamental commercial practices. This is not a close call—the claims clearly fall within the abstract idea exception.
Applicant argues the Examiner incorrectly required explicit description of how compartmentalization works. Under the August 2025 memo, "the specification does not need to explicitly set forth the improvement" but must describe it such that improvement would be apparent to one of ordinary skill in the art. Applicant’s Reply at 10–11.
Examiner maintains that even under this standard, no improvement to computer functionality is apparent from the specification. The specification describes a business objective (regulatory compliance for data separation) and labels the solution a "plugin," but provides no technical details distinguishing this from conventional data isolation techniques. A person of ordinary skill would not recognize a technological improvement, only a different implementation of known security practices.
Applicant argues italicized portions allegedly recite fundamental economic principles (receiving financial information, interacting with servers, presenting information) and identifies remainder as "additional elements" including mobile device, launching applications, compartmentalized plugin, and secure data handling to argue the additional elements supply an inventive concept. Applicant’s Reply at 13–5.
Examiner respectfully disagrees.
All recited elements work together to perform the abstract idea of managing financial account information in retail transactions. The alleged "additional elements" are generic computer components (mobile device, processor, memory, servers, GUI) and well-understood data security techniques. The August 2025 memo specifically cautions against evaluating limitations in a vacuum separate from the judicial exception.
Applicant compares claims to Core Wireless, where claims were eligible because they improved "speed of user's navigation through various views and windows." Applicant argues their claims similarly improve navigation by nesting the financial plugin within the retail app framework without requiring launch of another application, addressing the specification's stated need to avoid "numerous pop-ups, tabs, pages" on mobile devices. Applicant’s Reply at 15–6.
Examiner respectfully disagrees.
Core Wireless is distinguishable. That case involved specific structural limitations for displaying an "application summary" with a "limited list of data" in an "un-launched state" that provided concrete improvements to UI efficiency. Here, the claims broadly recite displaying financial information using generic compartmentalization—they do not specify the particular manner of presentation or structural UI improvements. The specification's reference to avoiding pop-ups is a desired result, not a claimed technological improvement. Moreover, data isolation for regulatory compliance is a business requirement implemented using conventional security techniques, not a technical UI innovation.
Applicant argues the additional elements (plugin architecture, compartmentalization, avoiding separate application launch) provide an inventive concept that amounts to significantly more than the judicial exception because they improve computer functioning similar to Core Wireless. Applicant’s Reply at 16–7.
Examiner respectfully disagrees.
The additional elements do not amount to significantly more. Launching applications, compartmentalizing data, and communicating with servers are all routine, well-understood, and conventional activities in software development. The specification provides no evidence these elements represent unconventional implementations. Merely applying abstract ideas using generic computer components does not provide an inventive concept sufficient for patent eligibility.
Applicant argues dependent claims are not directed to an abstract idea for the same reasons as independent claims 1, 8, and 15. Applicant’s Reply at 17.
Examiner respectfully disagrees.
The dependent claims add only conventional types of financial information (credit history, purchase history, remaining credit, rewards) or fundamental economic practices (adjusting credit limits). These additions do not change the abstract nature of the underlying independent claims.
35 U.S.C. § 103 Argument
Applicant argues Examiner concedes at page 25 of the Office Action that prior art Ayyagari does not explicitly disclose compartmentalization where the financial plugin prevents the mobile retail application from accessing financial information. Ayyagari teaches receiving financial data but not the secure isolation preventing retail app access. Applicant’s Reply at 18–9.
Examiner agrees that Ayyagari alone does not explicitly teach compartmentalization, which is why Collison was cited. This argument does not address the combination of Ayyagari and Collison. The rejection is based on the combined teachings, not Ayyagari alone, so this argument is unpersuasive.
Applicant argues Examiner's rejection shows prior art Collison prevents payment information from reaching the merchant's servers (server-side compartmentalization) but is "silent with regards to any part of the client-side application of Collison not seeing the payment information." The claims require that the mobile retail application operating on the mobile device cannot access the financial information—a client-side limitation distinct from server-side data protection. Applicant’s Reply at 19–21.
Collison's Stripe.js implementation provides client-side compartmentalization. The Stripe.js plugin operates within the merchant's application but maintains data isolation through browser security mechanisms (same-origin policy, iframe isolation). The merchant application cannot access payment information entered into Stripe.js elements—this is fundamental to PCI-compliant payment processing. Even if the text emphasizes server-side benefits, the necessary operation of Stripe.js involves the claimed client-side compartmentalization. What Collison teaches is inherent in how the disclosed system operates.
Applicant argues The claims specifically require "a financial plugin, wherein said financial plugin is not an application program interface (API)." Neither Ayyagari nor Collison disclose a plugin that is explicitly not an API. Applicant’s Reply at 20–21.
Examiner finds the negative limitation "not an API" is a conclusory label that does not meaningfully limit claim scope. The claims do not define what structural or functional characteristics distinguish a "plugin" from an "API." Under broadest reasonable interpretation, Collison's Stripe.js library/plugin teaches the substantive functionality regardless of what label is applied. Even if Stripe could technically be called an API, it performs the claimed function of compartmentalized financial data handling within a retail application framework.
Applicant argues the Office Action argues that Collison's "client-side application does not send the payment information to the server-side retail application," but is silent on whether the client-side application itself can see or access the payment information. The claims require the mobile retail application is "unable to access" the financial information. Applicant’s Reply at 21.
Examiner finds this argument conflates "sending data to server" with "accessing data locally." In Collison's Stripe.js architecture, the client-side merchant application cannot access payment data due to browser security policies and Stripe's implementation design. The payment information is captured in isolated form elements and transmitted directly to Stripe servers without exposure to the merchant's JavaScript. A person of ordinary skill in payment processing security would understand that preventing server transmission necessarily involves preventing client-side access. Additionally, the Examiner takes official notice that isolating sensitive payment data from merchant applications (both client-side and server-side) is well-known for regulatory compliance.
Applicant argues the claims require "a data window compartmentalized from said mobile retail application" where the plugin "does not share said financial information with said mobile retail application operating on said mobile device." Collison does not explicitly disclose a compartmentalized data window structure on the mobile device. Applicant’s Reply at 18, 20–1.
Examiner respectfully disagrees.
Under broadest reasonable interpretation, Collison's Stripe.js form elements or iframe that capture payment information constitute a "data window" that is compartmentalized from the merchant application through browser security mechanisms. The term "data window" is broad and reasonably encompasses any UI element or container that displays and processes financial data separately from the host application. Collison teaches this structure through its secure payment capture interface.
Applicant argues the combination of Ayyagari and Collison fails to teach or suggest the complete claimed invention: launching a financial plugin (not an API) within the retail application framework, where the plugin comprises a compartmentalized data window, and the mobile retail application is unable to access the financial information. Applicant’s Reply at 21.
Examiner respectfully disagrees.
The combination teaches all claimed limitations. Ayyagari teaches integrating financial information display within a mobile retail application framework. Collison teaches the compartmentalized security architecture via Stripe.js operating within merchant applications while maintaining data isolation. The combination would have been obvious to provide secure financial functionality within retail apps, addressing the well-known need for PCI-compliant payment processing. The motivation to combine is strong given both references address the same technical problem of integrating financial services into retail applications.
Applicant argues Dependent Claims 2-4, 6-7, 9-11, 13-14, 16-17, 19-20 recite additional features and are patentable over the applied references for at least the same reasons the independent claims are patentable. Applicant’s Reply at 21.
Examiner respectfully disagrees.
The dependent claims merely specify types of financial information (credit history, purchase history, remaining credit, rewards) or add fundamental economic practices (adjusting credit limits). These conventional data types and business practices do not distinguish the claims from the prior art combination. The rejection is maintained for the same reasons as the independent claims.
Applicant argues Dependent Claims 5, 12, 18 Patentable Over Ayyagari + Collison + Kalgi are patentable over the three-reference combination for the same reasons independent claims are patentable over Ayyagari and Collison. Applicant’s Reply at 22.
Examiner respectfully disagrees.
The argument does not address the third reference (Kalgi) or explain why adding Kalgi's teachings makes the combination non-obvious. The claims fail for the same reasons as the independent claims—the base combination of Ayyagari and Collison teaches the claimed subject matter, and adding Kalgi to teach rewards information does not cure the deficiencies alleged in the base combination.
For the foregoing reasons, the current amendments do not alter the prior § 103 rejection and therefore, it is maintained.
Claim Interpretation
An “such that” clause that merely states the intended result of the claim limitations adds nothing to the claims substance. Accordingly, statements of an intended result fail to limit the scope of the claim under BRI. MPEP § 2103(I)(C). Here, the language after “such that” merely indicates the result the function accomplishes. The two clauses affected from Independent Claims are:
“such that said financial plug in does not share said financial information with said mobile retail application”
“such that said mobile retail application is unable to access said financial information received by said financial plugin”
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.
securely compartmentalized and compartmentalized means “separate.” Spec. ¶ 14.
presentation methodology means “display”. Spec. ¶ 79.
Framework, as recited by the claims, means “a native mobile retail application having a financial plugin.” E.g., Claims 1, 8, 15.
data window means “access to the specified data type”. Spec. ¶ 29 (“the plugin on the application would provide a window into the information from the credit account.”).
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1–20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (i.e., an abstract idea) without significantly more.
Analysis
Step 1: Claims 1–20 are directed to a statutory category. Claims 1–7 recite a “method” and are therefore, directed to the statutory category of a “process.” Claims 8–14 recite a “mobile device” and are therefore, directed to the statutory category of a “machine.” Claims 15–20 recite a “non-transitory computer-readable medium” and are therefore, directed to the statutory category of an "article of manufacture.”
Representative Claim
Claim 8 is representative [“Rep. Claim 8”] 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] 8. A mobile device comprising: a memory storing instructions; and a processor, when executing the instructions, to:
[B] launch, on said mobile device, a native mobile retail application,
[B1] said native mobile retail application operating on said mobile device and configured to interact with a retail application server and obtain retail information,
[B2] said retail application server distinct from said mobile device;
[C] receive, from within the native mobile retail application operating on said mobile device, a request for financial information from a credit account associated with the native mobile retail application operating on said mobile device;
[D] launch, within a framework of said native mobile retail application operating on said mobile device, a financial plugin,
[D1] wherein said financial plugin is not an application program interface (API),
[D2] said financial plugin comprising a data window compartmentalized from said native mobile retail application operating on said mobile device and said financial plugin does not share said financial information with said native mobile retail application operating on said mobile device,
[D3] said financial plugin configured to interact with a financial server,
[D4] said financial server distinct from said retail mobile application server and said mobile device,
[D5] the financial plugin launched on said mobile device within said framework of said native mobile retail application operating on said mobile device and without requiring a launch of another application on said mobile device;
[E] receive, at the financial plugin and from the financial server, the financial information comprising: financial data and credit account management information,
[F] wherein said financial information received at said financial plugin is securely compartmentalized from said native mobile retail application operating on said mobile device and said native mobile retail application operating on said mobile device is unable to access said financial information received by said financial plugin; and
[G] present, on a graphical user interface, the financial information via a presentation methodology of the financial plugin operating within said framework of said native mobile retail application operating on said mobile device and without providing the native mobile retail application operating on said mobile device access to the financial information.
Claims are directed to an abstract idea exception.
Step 2A, Prong One: Rep. Claim 8 recites “present … the financial information,” in Limitation G, which recites commercial or legal interactions under the organizing human activity exception because presenting financial information recites “sales activities or behaviors, and business relations” between two people, MPEP § 2106.04(a)(2)(II)(B). Additionally, presenting financial information in Limitation G “comprising financial data and credit management information” as recited in Limitation E recites commercial or legal interactions under the organizing human activity exception because “credit management information” “includes agreements in the form of contracts and legal obligations.” MPEP § 2106.04(a)(2)(II)(B). Limitations B–F are the requested steps and data communications to present the financial information “comprising financial data and credit account management information” in Limitation E and therefore, recite the same exception. Id.
Alternatively, presenting financial information in Limitation G “comprising financial data and credit management information” as recited in Limitation E recites a fundamental economic practice under the organizing human activity exception because it relates to concepts involving the economy and commerce, such as “local processing of payments for remotely purchased goods,” citing Inventor Holdings, LLC v. Bed Bath Beyond, 876 F.3d 1372, 1378-79, 125 USPQ2d 1019, 1023 (Fed. Cir. 2017) or such as, extending “credit.” MPEP § 2106.04(a)(2)(II)(A). Presenting financial information being old and well known “indicates that the practice is fundamental.” MPEP § 2106.04(a)(2)(II)(A) (citing Intellectual Ventures I LLC v. Symantec Corp., 838 F.3d 1307, 1313, 120 USPQ2d 1353, 1356 (Fed. Cir. 2016) ("The category of abstract ideas embraces ‘fundamental economic practice[s] long prevalent in our system of commerce,’ … including ‘longstanding commercial practice[s]’") Limitations B–F are the requested steps and data communications and therefore, recite the same exception. Id.
Step 2A, Prong Two: Rep. Claim 8 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 mobile device comprising: a memory storing instructions, a processor, a native mobile retail application, a financial plugin, and a graphical user interface; a retail application server; a financial server.2
Regarding mobile device comprising: a memory storing instructions, a processor, a native mobile retail application, a financial plugin, and a graphical user interface; a retail application server; a financial server, 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. ¶¶ 8, 94, 102, 103 (known and generic (exemplary) mobile device, memory, processor, servers); ¶ 103 (known and generic (exemplary) instructions (software)); ¶ 8 (“FIG. 4 is a block diagram of an example computer system with which or upon which various embodiments of the present invention may be implemented.”); ¶ 94 (“It is appreciated that system 400 of FIG. 4 can operate on or within a number of different computer systems including general purpose networked computer systems, computer-readable and computer-executable instructions that reside, for example, in non-transitory computer- readable medium, embedded computer systems, routers, switches, server devices, user devices, various intermediate devices/artifacts, stand-alone computer systems, mobile phones, personal data assistants, televisions and the like.”); ¶ 102 (“The computing system 400 is only one example of a suitable computing environment and is not intended to suggest any limitation as to the scope of use or functionality of the present technology. Neither should the computing environment be interpreted as having any dependency or requirement relating to any one or combination of components illustrated in the example computing system 400.”); ¶ 103 (“The present technology may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network.”); ¶ 100 (known and generic application); ¶¶ 37, 38, 39, 42, 43, 45, (known and generic (exemplary) plugin (code); ¶ 30 (known and generic (exemplary) GUI “of mobile device 101”); Fig. 4; ¶ 74 (“Processors 406A, 406B, and 406C may be any of various types of microprocessors.”); ¶ 80 (“The computing system 400 is only one example of a suitable computing environment and is not intended to suggest any limitation as to the scope of use or functionality of the present technology. Neither should the computing environment be interpreted as having any dependency or requirement relating to any one or combination of components illustrated in the example computing system 400”); ¶ 82 (“any two or more embodiments may be combined.”). The generic processor, here, appears to perform calculations (functions) that are programmed by software. E.g., Spec.¶ 103. This is a computer doing what it is designed to do—performing directions it is given to follow.
Limitation A describes the processor, memory, and instructions communicating in some unspecified way to perform the steps of the claimed invention, which merely invokes computers or other machinery in its ordinary capacity to receive, store, or transmit data. MPEP § 2106.05(f)(2). Limitation A further describes memory, processor, and instructions performing the steps of the claimed invention, Limitations B–G, 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).
The claims recite the mobile device performing the functions of “launch[ing] … a native mobile retail application (software) (Limitation B) and “launch[ing]” the financial plugin (software) (Limitations D, D5). This takes a generic piece of hardware (i.e., the mobile device) and describe the functions of receiving, storing, and sending data (instructions) between the processor and memory, which merely invokes computers or other machinery in its ordinary capacity to receive, store, or transmit data. MPEP § 2106.05(f)(2).
The claims recite the native mobile retail application performing the functions of receiving a request for financial information (Limitation C) and configured to interact (transmitting and receiving) with a retail application server (Limitation B1), which merely invokes computers or other machinery in its ordinary capacity to receive, store, or transmit data. MPEP § 2106.05(f)(2).
The claims recite the financial plugin performing the functions of interacting with (transmitting and receiving) (Limitation D3), receiving financial information from a financial server (Limitation E), and “securely compartmentali[ing]” or keeping separate the received financial information from the native mobile retail application (Limitations F, G (part)) using “a data window” (Limitation D2), which reasonably suggests that the financial plugin has access to the secure data storage but the native mobile retail application does not (storing and retrieving information), which merely invokes computers or other machinery in its ordinary capacity to receive, store, or transmit data. MPEP § 2106.05(f)(2). The functional restriction on the retail application’s access to the “data window” where the financial information is stored, under BRI, covers any solution to restricting access with no restriction on how the result is accomplished and no description of the mechanism for accomplishing the result. MPEP § 2106.05(f)(1).
The claims recite the GUI performing the functions of presenting financial information (Limitation G (part)), which merely invokes computers or other machinery in its ordinary capacity to receive, display, store, or transmit data. MPEP § 2106.05(f)(2). The displaying step fails to transform the claims into patent eligible material, as this is part of the field of use and technical environment in which the abstract idea is being implement and does not result in an improvement to additional elements, a practical application, or inventive concept. MPEP 2106.05(h) (citing Electric Power Group, LLC v. Alstom S.A., 830 F.3d 1350, 1354, 119 USPQ2d 1739, 1742 (Fed. Cir. 2016)).
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 8 is directed to an abstract idea.
Rep. Claim 8 is not substantially different than Independent Claims 1 and 15 and includes all the limitations of Rep. Claim 8. Independent Claims 1 and 15 contain no additional elements not otherwise analyzed. Therefore, Independent Claim 1 and 15 are also directed to the same abstract idea.
The claims do not provide an inventive concept.
Step 2B: Rep. Claim 8 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 in their combination of additional elements is not inventive. First, the claims are directed to an abstract idea. Second, each additional element represents a currently available generic computer technology, used in the way in which it is commonly used (individually generic). Last, Applicant’s Specification discloses that the combination of additional elements is not inventive. Spec., ¶ 104 (steps/functions may be performed in any order); ¶¶ 8, 30, 37, 38, 39, 42, 43, 45, 74, 80, 82, 94, 100, 102, 103, Fig. 4 (known and generic (exemplary) computer equipment as explained and cited supra.)
Regarding the claimed functions of the native mobile retail application (transmitting and receiving), the financial plugin (transmitting, receiving, storing and retrieving information), the retail application server (transmitting and receiving) and the financial server (transmitting and receiving), courts have recognized receiving and transmitting data, as here, and storing and retrieving information in memory, also as here, in a generic manner are well‐understood, routine, and conventional computer functions. MPEP § 2106.05(d)(II)(i), (iv).
Thus, Examiner finds the additional elements of Rep. Claim 8 are elements that have been recognized as well-understood, routine, and conventional (“WURC”) activity in the particular field of this invention based on Applicant’s own disclosure3. Spec. ¶¶ 8, 30, 37, 38, 39, 42, 43, 45, 74, 80, 82, 94, 100, 102, 103, Fig. 4; MPEP § 2106.05(d). Specifically, Applicant’s Specification discloses the recited additional elements, i.e., mobile device comprising: a memory storing instructions, a processor, a native mobile retail application, a financial plugin, and a graphical user interface; a retail application server; a financial server are generic computer components. The Examiner also finds the functions of receiving, storing, transmitting, displaying, and processing (e.g., performing mathematical operations on) data, described in Limitations A–G are all normal functions of a generic computer.
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 8 does not provide an inventive concept.
Rep. Claim 8 is not substantially different than Independent Claims 1 and 15 and includes all the limitations of Rep. Claim 8. Independent Claims 1 and 15 contain no additional elements not otherwise analyzed. Therefore, Independent Claim 1 and 15 are also directed to the same abstract idea.
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 2, 3, 4, 5, 9, 10, 11, 12, 16, 17, and 18 all recite “wherein” clauses or limitations that further limit the abstract idea of the Independent Claims and contain no additional elements. Further, the specific type of financial information received in each of these claims is printed matter because it is claimed for what it communicates to a human user and has no functional relationship with the claimed mobile device or financial server. Thus, it is not entitled to patentable weight. MPEP § 2111.05; Praxair Distrib., Inc. v. Mallinckrodt Hosp. Prod. IP Ltd., 890 F.3d 1024, 1032 (Fed. Cir. 2018) (“Claim limitations directed to the content of information and lacking a requisite functional relationship are not entitled to patentable weight because such information is not patent eligible subject matter under 35 U.S.C. § 101.”)
Dependent Claims 6, 7, 13, 14, 19 and 20 recite additional limitations that form part of the same abstract idea exception as recited in Independent Claims and contain no additional elements. Dependent Claims 6, 7, 13, 14, 19, and 20, as drafted, recite a mental process that under the broadest reasonable interpretation, cover performance in the human mind or with pen and paper, but for the recitation of the generic computer components.
Claims recite a mental process when they contain limitations that can practically be performed in the human mind, including for example, observations, evaluations, judgments, and opinions. Examples of claims that recite mental processes include:
• a claim to "collecting information, analyzing it, and displaying certain results of the collection and analysis," where the data analysis steps are recited at a high level of generality such that they could practically be performed in the human mind, Electric Power Group v. Alstom, S.A., 830 F.3d 1350, 1353-54, 119 USPQ2d 1739, 1741-42 (Fed. Cir. 2016).
MPEP § 2106.04(a)(2)(III)(A). “[U]tilizing the financial information in conjunction with a purchase request … to adjust a credit limit based on said purchase request” as recited in Claims 6, 13, and 19 is a mental process that are practically performed in the human mind or with pen and paper because it requires mere “observation, evaluation, judgment, and/or opinion” to adjust a credit limit utilizing financial information and a purchase request. Likewise, “wherein adjusting said credit limit comprises: increasing the credit limit to allow a purchase of a product at an amount higher than a present credit limit” as recited in Claims 7, 14, and 20 is a mental process that are practically performed in the human mind or with pen and paper because it requires mere “observation, evaluation, judgment, and/or opinion” to increase a credit limit to permit a purchase. An inventive concept or practical application cannot be furnished by the abstract idea exception itself. MPEP §§ 2106.05(I), 2106.04(d)(III).
Conclusion
Claims 1–20 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 8 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 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 1, 8, and 15 are rejected under 35 U.S.C. 103 as being unpatentable over Ayyagari et al. (U.S. Pat. Pub. No. 2018/0047009) (Filed: Aug. 12, 2016) [“Ayyagari”] in view of Collison et al. (U.S. Pat. Pub. No. 2013/0117185) [“Collison”]
Regarding Claim 1, Ayyagari discloses
A method for seamless integration of financial information within a mobile retail application framework operating on said mobile device, the method comprising:
(See at least Fig. 1, disclosing “Retail App 131” “Event Plug-in 132” and “computer 130,” which may be a smartphone. ¶ 15. The “framework” is defined by the subsequent claim language as “a native retail application [Retail App 131] and a financial plugin [Event Plug-in 132].” The integration is “seemless” because “Event Plug-in 132 requests mobile OS 133 to monitor the operations of computer 130 for various events significant to the ability to complete a desired e-commerce transaction such as a mobile payment in a timely manner … [and] monitor[s] for events.” ¶ 18. The italicized limitations are interpreted as intended use. Statements of intended use fail to limit the scope of the claim under BRI. MPEP § 2103(I)(C).)
launching, on a mobile device, said mobile retail application operating on said mobile device and,
(See at least Fig. 1 and associated text ¶ 17, “Retail app 131 using event plug-in 132 initiates and provides the ability to execute e-commerce transactions such as mobile payments.” “Event plug-in 132 is a software extension to retail app 131. In various embodiments, an event plug-in performing the operations and function of event plug-in 132 is included in other mobile applications (e.g., in mobile banking apps, mobile wallet apps, net banking apps, and the like) that provide the ability to perform mobile financial transactions or mobile payments).” ¶ 18.)
said mobile retail application operating on said mobile device configured to interact with a retail application server [merchant website] and obtain retail information, said retail application server distinct from said mobile device;
(See at least Fig. 1 and associated text ¶ 17, “Retail app 131 may provide access to a merchant website or other on-line shopping website, allowing browsing and the selection of products for purchase.” See also, ¶ 21. A merchant website is hosted on a computer or server). The retail application 131 and computer 130 are distinct. Fig. 1.)
receiving, at said mobile device, a request for said financial information; launching, on the mobile device and within a framework of said mobile retail application operating on said mobile device, a financial plugin [event plug-in 132],
(See at least ¶ 17, “retail app 131 is any mobile application or app configured with event plug-in 132 used for mobile payments, e-commerce transactions, mobile or online banking.” “Event plug-in 132 is a software extension to retail app 131 … an event plug-in performing the operations and function of event plug-in 132 is included in other mobile applications (e.g., in mobile banking apps, mobile wallet apps, net banking apps, and the like).” ¶ 18. A framework is a native mobile retail application having a financial plugin.)
wherein said financial plugin is not an application program interface (API),
(Applicant’s Specification teaches a “plugin is used in order to comply with the regulations and maintain the proper separation/compartmentalization/security of the customer financial information” instead of “an application program interface (API) or a software development kit (SDK).” Spec. ¶¶ 14, 32. The “event plug-in 132” is a “plug-in” as contemplated by the disclosure and therefore, is not an API of said native retail application. Ayyagari explains that “Program instructions and data used to practice embodiments of the present invention.” Ayyagari, ¶¶ 49, 51, 56.)
[…]
said financial plugin configured to interact with a financial server [server 160], said financial server distinct from said retail mobile application server and said mobile device,
(see at least ¶ 23, “server 160 is a server used in a financial institution or a financial services system such as a bank or a credit card corporation.” The server 160 is distinct from “a merchant website or other on-line shopping website” as described in the rejection of the prior limitation. ¶¶ 17, 21.)
the financial plugin launched within said framework of said mobile retail application operating on said mobile device without requiring a launching of another application on said mobile device;
(A framework is a native mobile retail application having a financial plugin. Fig. identifies an “event plug-in 132,” which is part of “retail app 131,” which is a framework. Another application is not launched because the “Event plug-in 132 is a software extension to retail app 131 … an event plug-in performing the operations and function of event plug-in 132 is included in other mobile applications (e.g., in mobile banking apps, mobile wallet apps, net banking apps, and the like).” ¶ 18.)
receiving, at the financial plugin operating on said mobile device and from the financial server, the financial information comprising: financial data [mobile or online banking information] and account management information [transfer of funds],
(The retail app 131 used, for example, in “mobile or online banking,” ¶¶ 10, 11, 12, 17, 18, and “a server 160 … used in … a credit card corporation,” ¶ 23, reasonably teaches or suggests “receiving at the financial plugin on said mobile device and from the financial server, the financial information comprising financial data and account management information.” A PHOSITA would not access online banking, for example, without being able to view the requested account information and “transfer funds”. ¶¶ 11, 17, 18, 21, 23, 32.)
[…]
presenting, on a graphical user interface of the mobile device, the financial information via a presentation methodology of the financial plugin operating within said framework of said mobile retail application operating on said mobile device on said mobile device and […]
(The retail app 131 used, for example, in “mobile or online banking,” ¶¶ 10, 11, 12, 17, 18, and “a server 160 … used in … a credit card corporation,” ¶ 23, reasonably teaches or suggests “presenting, on a graphical user interface of the mobile device, the financial information via a presentation methodology of the financial plugin operating within said framework of said mobile retail application on said mobile device.” A PHOSITA would not access online banking, for example, without being able to view the requested account information and “transfer funds”. ¶¶ 11, 17, 18, 21, 23, 32.)
Ayyagari discloses a financial plugin. Ayyagari does not explicitly disclose the financial plugin comprising a secure data storage compartmentalized from said mobile retail application such that said financial plug in does not share said financial information with said mobile retail application. Ayyagari discloses receiving, at the financial plugin operating on said mobile device and from the financial server, the financial information comprising: financial data and account management information. Ayyagari does not disclose wherein said financial information received at said financial plugin is securely compartmentalized from said mobile retail application such that said mobile retail application is unable to access said financial information received by said financial plugin and without providing the mobile retail application operating on said mobile device access to the financial information. Therefore, Ayyagari does not disclose but Collison discloses:
said financial plugin comprising a secure data storage compartmentalized from said mobile retail application operating on said mobile device such that said financial plug in does not share said financial information with said mobile retail application operating on said mobile device,
(See at least ¶ 13, “Stripe (300) will generate and return a secure, Single-use Token (350) to the Customer's Browser (210) that represents the customer's payment information (220) but doesn't leak any sensitive information.” See also, ¶¶ 5 (secure storge of customer’s sensitive payment information), ¶ 6 The tokenization of the payment information by the financial plugin (stripe) reasonably suggests not sharing payment information with the retail application (merchant). ¶¶ 5, 6.)
wherein said financial information received at said financial plugin is securely compartmentalized from said mobile retail application operating on said mobile device and said mobile retail application is unable to access said financial information received by said financial plugin; and […] without providing the mobile retail application operating on said mobile device access to the financial information.
(In view of Applicant’s Specification, Examiner interprets “without providing the mobile retail application operating on said mobile device access to the financial information” as “the native retail application is not provided access to the financial information”. The native retail application resides on the user’s mobile device. ¶¶ 36, 38. The financial plugin [“Stripe.js”] resides on the mobile device and within the native retail application. ¶¶ 7, 8. “The Customer's payment information (220) is sent from the Customer's browser (210) to Stripe (300), never touching the Merchant's Servers (120). In this manner, the client-side application electronically sends payment information retrieved from the customer's electronic device to the payment processor. The client-side application does not send the payment information (220) to the server-side [retail] application.” ¶ 11; see also ¶¶ 82, 85, 86 (redacts PAN and CVC), 279. “However, in an alternative embodiment, the client-side application does not run in a web browser. Instead, the merchant's client-side application runs in a native mobile application (for example, in an Android™ or iPhone® app).” ¶ 142.))
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 said financial plugin comprising a secure data storage compartmentalized from said mobile retail application such that said financial plug in does not share said financial information with said mobile retail application and wherein said financial information received at said financial plugin is securely compartmentalized from said mobile retail application such that said mobile retail application is unable to access said financial information received by said financial plugin; and […] without providing the mobile retail application operating on said mobile device access to the financial information as explained in Collison, to the known invention of Ayyagari, in the same field of invention, with the motivation to comply with industry data protection standards. Collison, ¶ 6.
Regarding Claim 8, Ayyagari, discloses
One or more devices of a customer, comprising: a memory storing instructions; and a processor, when executing the instructions, to:
(See at least Fig. 4 and associated text ¶ 49.)
The remaining limitations of Claim 8 the limitations are not substantively different than that presented in Claim 1 and are therefore, rejected, mutatis mutandis, based on Ayyagari and Collison for the same rationale presented in Claim 1 supra.
Regarding Claim 15, Ayyagari, discloses
A non-transitory computer-readable medium for storing instructions, the instructions comprising: one or more instructions which, when executed by one or more processors, cause one or more processors to:
(See at least Fig. 4 and associated text ¶ 49.)
The remaining limitations of Claim 15 the limitations are not substantively different than that presented in Claim 1 and are therefore, rejected, mutatis mutandis, based on Ayyagari and Collison for the same rationale presented in Claim 1 supra.
Claims 2, 3, 4, 6, 7, 9, 10, 11, 13, 14, 16, 17, 19, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Ayyagari and Collison and further in view of Numata (U.S. Pat. Pub. No. 2006/0080231) [“Numata”]
Regarding Claim 2, Ayyagari and Collison disclose
The method of Claim 1 and the receiving of the financial information.
Ayyagari does not disclose but Numata discloses
wherein the receiving of the financial information comprises: receiving a credit history.
(This limitation is interpreted as printed matter because it is claimed for what it communicates to a human user and has no functional relationship with the claimed mobile device or financial server. Thus, it is not entitled to patentable weight. MPEP § 2111.05. However, should a reviewing court disagree, See at least Fig. 3 and associated text ¶ 35 disclosing “FIG. 3 shows an example of a customer's credit history information table in the credit sales system of the embodiment”)
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 receiving a credit history as explained in Numata, to the known invention of Ayyagari, in the same field of invention, with the motivation to “permit[ ] [the] purchase of a commodity or service beyond a credit limit and preventing a one-sided increase in the risk of the credit sales company.” Numata, ¶ 5.
Regarding Claim 3, Ayyagari and Collison disclose
The method of Claim 1 and the receiving of the financial information.
Ayyagari does not disclose but Numata discloses
wherein the receiving of the financial information comprises: receiving a purchase history.
(This limitation is interpreted as printed matter because it is claimed for what it communicates to a human user and has no functional relationship with the claimed mobile device or financial server. Thus, it is not entitled to patentable weight. MPEP § 2111.05. However, should a reviewing court disagree, See at least Abstract.)
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 2 supra, and is incorporated in its entirety herein, mutatis mutandis, to support the rejection of Claim 3.
Regarding Claim 4, Ayyagari and Collison disclose
The method of Claim 1 and the receiving of the financial information.
Ayyagari does not disclose but Numata discloses
wherein the receiving of the financial information comprises: receiving a remaining credit available.
(This limitation is interpreted as printed matter because it is claimed for what it communicates to a human user and has no functional relationship with the claimed mobile device or financial server. Thus, it is not entitled to patentable weight. MPEP § 2111.05. However, should a reviewing court disagree, See at least Fig. 2, element 123, “credit limit”)
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 2 supra, and is incorporated in its entirety herein, mutatis mutandis, to support the rejection of Claim 4.
Regarding Claim 6, Ayyagari, Collison, and Kalgi disclose
The method of Claim 1 as discussed above.
Ayyagari does not disclose but Numata discloses
further comprising: utilizing the financial information in conjunction with a purchase request of said mobile retail application operating on said mobile device to adjust a credit limit based on said purchase request.
(See at least Abstract disclosing “If the purchase history information satisfies the credit balance increment condition, the member store calculates a credit balance increment rate on its own risk. The member store approves a payment by the credit card when the requested payment price is lower than the product of the credit balance by the credit balance increment rate even if the requested payment price is higher than the credit balance.”)
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 2 supra, and is incorporated in its entirety herein, mutatis mutandis, to support the rejection of Claim 6.
Regarding Claim 7, Ayyagari, Collison and Numata disclose
[t]he method of Claim 6 and adjusting said credit limit as discussed above.
Ayyagari does not disclose but Numata discloses
increasing the credit limit to allow a purchase of a product at an amount higher than a present credit limit.
(See at least Abstract, disclosing “If the purchase history information satisfies the credit balance increment condition, the member store calculates a credit balance increment rate on its own risk. The member store approves a payment by the credit card when the requested payment price is lower than the product of the credit balance by the credit balance increment rate even if the requested payment price is higher than the credit balance.”)
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 2 supra, and is incorporated in its entirety herein, mutatis mutandis, to support the rejection of Claim 7.
Regarding Claims 9, 10, 11, 13, and 14, Ayyagari and Collison disclose
[t]he one or more devices of claim 8 as discussed above.
The remaining limitations of Claims 9, 10, 11, 13, and 14 are not substantively different than those presented in Claims 2, 3, 4, 6, and 7, respectively, and are therefore, rejected, mutatis mutandis, based on Ayyagari, Collison, and Numata for the same rationale presented in Claims 2, 3, 4, 6, and 7, respectively, supra.
Regarding Claims 16, 17, 19, and 20, Ayyagari and Collison disclose
The non-transitory computer-readable medium of claim 15 as discussed above.
The remaining limitations of Claims 16, 17, 19, and 20 are not substantively different than those presented in Claims 3, 4, 6, and 7, respectively, and are therefore, rejected, mutatis mutandis, based on Ayyagari, Collison, and Numata for the same rationale presented in Claims 3, 4, 6, and 7, respectively, supra.
Claims 5, 12, and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Ayyagari, and Collision, and further in view of Kalgi (U.S. Pat. Pub. No. 2013/0013499) [“Kalgi”]
Regarding Claim 5, Ayyagari and Collison disclose
[t]he method of Claim 1 and receiving of the financial information.
Ayyagari does not disclose but Kalgi discloses:
wherein the receiving of the financial information comprises: receiving a rewards information.
(See at least Fig. 15A, element 1518, and associated text ¶ 118, where in the left most figure, the remaining reward points are displayed. Fig. 2, upper left figure (same). It is axiomatic that to display these remaining credit balances the device of Kalgi must receive them.)
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 receiving a rewards information as explained in Kalgi, to the known invention of Ayyagari, in the same field of invention, with the motivation to review your online credit account to determine if there are any rewards associated with using the selected payment card. Kalgi, ¶ 58.
Regarding Claim 12, Ayyagari and Collison disclose
[t]he one or more devices of claim 8 as discussed above.
The remaining limitations of Claim 12 are not substantively different than those presented in Claim 5, and are therefore, rejected, mutatis mutandis, based on Ayyagari, Collison, and Kalgi for the same rationale presented in Claim 5, supra.
Regarding Claim 18, Ayyagari and Collison disclose
The non-transitory computer-readable medium of claim 15.
The remaining limitations of Claim 18 are not substantively different than those presented in Claim 5, and are therefore, rejected, mutatis mutandis, based on Ayyagari, Collison, and Kalgi for the same rationale presented in Claim 18, supra.
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 The API is not listed as an additional element because the API is a negative limitation and not required.
3 See Changes in Examination Procedure Pertaining to Subject Matter Eligibility, Recent Subject Matter Eligibility Decision (Berkheimer v. HP, Inc.), 3-4, https://www.uspto.gov/sites/default/files/documents/memo-berkheimer-20180419.PDF (April, 18, 2018) (That additional elements are well-understood, routine, or conventional may be supported by various forms of evidence, including "[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).").