DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Status of the Application
This Office Action is being examined in response to the amendments submitted by the Applicant on November 6, 2025
Claims 1, 2, 4, 7, 10, and 13 have been amended and are hereby entered.
Claim 11 is cancelled.
Claims 1–10 and 12–18 are pending and have been examined.
This action is made FINAL.
The examiner would like to note that this application is now being handled by examiner Michael Anderson.
Response to Arguments
I. Claim Objection — MOOT
The objection to Claim 2 is withdrawn in view of Applicant’s amendment specifying “the second SDK.” Applicant’s correction is acknowledged and appreciated.
II. § 101 Arguments — NOT PERSUASIVE
Applicant’s arguments regarding the § 101 rejection have been fully considered but are not persuasive for the following reasons:
A. Applicant’s Argument: The Claims Recite a “Technical Solution to a Technical Problem”
Applicant argues that the claims address a technical problem — specifically, the “lack of integration of installment providers with the merchants involved in the underlying transactions” (citing Spec. ¶ [0012]) — and provide a technical solution through “the specific integration of software-development kits (SDKs) at the first party.”
Examiner’s Response:
The Examiner respectfully disagrees. The “problem” identified by Applicant — friction in coordinating installment payment options between users, merchants, and installment providers — is a business problem, not a technical problem rooted in computer technology. The specification itself frames the problem in business/commercial terms: “installment options may be limited and cumbersome for users, and for merchants, often resulting in friction in coordinating the transactions” (Spec. ¶ [0012]). Reducing “friction” in a commercial transaction is not an improvement to computer functionality — it is an improvement to a business process that happens to be implemented on a computer.
The claimed “solution” — integrating SDKs at the merchant to facilitate installment option presentation — does not solve a technical problem (e.g., processor inefficiency, network latency, memory constraints, data corruption, security vulnerabilities). Rather, it solves a business problem (limited installment options at checkout, friction in coordinating between parties) by applying conventional computing tools (SDKs, APIs, computing devices) to automate and streamline the business process.
Under the 2019 PEG, a claimed improvement must be to the functioning of the computer itself or to another technology, not merely to the efficiency of a business process performed on a computer. See MPEP § 2106.05(a); Enfish, LLC v. Microsoft Corp., 822 F.3d 1327 (Fed. Cir. 2016) (improvement to how data is stored in a self-referential table — a technical improvement); contrast BSG Tech LLC v. BuySeasons, Inc., 899 F.3d 1281 (Fed. Cir. 2018) (collecting and storing data to improve accuracy of a search — improvement to business process, not technology).
Here, the SDKs function in their ordinary, well-known capacity as software integration tools. No improvement to SDK technology itself is claimed. The SDKs are not recited as performing a function beyond their conventional purpose of enabling communication between software components.
B. Applicant’s Argument: The Claims Are Analogous to DDR Holdings
Applicant argues that the claims are analogous to DDR Holdings, LLC v. Hotels.com, L.P., 773 F.3d 1245 (Fed. Cir. 2014), because (like the hybrid webpage in DDR) the SDKs “retain the user at the first party” while providing access to installment functionality from a remote installment host.
Examiner’s Response:
The Examiner respectfully disagrees. The analogy to DDR Holdings is inapt for several reasons:
DDR addressed a problem unique to the Internet. In DDR, the problem was that clicking a hyperlink on a host website would transport the user away to a third-party’s website — a problem that “does not arise in the pre-Internet context.” DDR, 773 F.3d at 1257. The Federal Circuit found the claims eligible because they provided a technical solution (dynamically generating a hybrid webpage that combined visual elements of the host page with content from the third party) that was “necessarily rooted in computer technology in order to overcome a problem specifically arising in the realm of computer networks.” Id.
The instant claims do not address an Internet-specific technical problem. The problem addressed here — limited installment payment options at merchant checkout — is not a problem unique to the Internet. Installment payment coordination between merchants, lenders, and consumers has existed since well before the Internet. The claims automate and streamline this pre-existing business process using conventional web technology, but do not solve a problem “specifically arising in the realm of computer networks.”
The SDKs are not analogous to the hybrid webpage. In DDR, the hybrid webpage was a specific technical mechanism that modified how web content was generated and displayed to solve the transport-away problem. Here, the SDKs are generic software tools that serve as communication channels. The claims do not recite how the SDKs modify conventional Internet protocols, generate novel user interface elements, or alter how the merchant’s platform functions at a technical level. The SDKs merely transmit requests and receive responses — their conventional function.
Post-DDR case law narrows its holding. The Federal Circuit has consistently distinguished DDR and cautioned against overreliance on it. See, e.g., In re TLI Commc’ns LLC Patent Litig., 823 F.3d 607, 613 (Fed. Cir. 2016) (rejecting DDR analogy where claims merely used conventional technology to perform conventional functions); Affinity Labs of Tex., LLC v. DIRECTV, LLC, 838 F.3d 1253, 1264 (Fed. Cir. 2016) (same).
The claims here do not present the “something more” that DDR required. Keeping a user “at” the merchant’s website while communicating with a remote server is simply how conventional web applications work (e.g., AJAX calls, embedded iframes, API calls from merchant front-end to back-end services). This is not analogous to the novel hybrid webpage generation in DDR.
C. Applicant’s Argument: The SDKs Are “Additional Elements” Beyond the Abstract Idea That Provide Meaningful Limitations
Applicant argues that the SDKs are additional elements that provide more than “mere instructions to apply” the abstract idea, because they “provide for the specific integration of the added technology” and “technologically alter” the first party’s computing device.
Examiner’s Response:
The Examiner acknowledges that the SDKs are identified as additional elements in the § 101 analysis (see Step 2A, Prong 2 above). However, the Examiner maintains that these additional elements do not integrate the abstract idea into a practical application because:
SDKs are generic software tools. Under the broadest reasonable interpretation, a “software development kit” (SDK) is a collection of pre-built software libraries, APIs, documentation, and tools that developers use to build applications or integrate functionality. SDKs are ubiquitous in software development — payment SDKs, wallet SDKs, analytics SDKs, advertising SDKs, and authentication SDKs are routinely integrated into merchant platforms. The mere labeling of the communication channel as an “SDK” does not transform it into a particular machine or specific technological improvement. See MPEP § 2106.05(f) (reciting a generic computer component performing generic computer functions does not integrate the exception into a practical application).
The claims do not recite what makes the SDKs technically novel. The claims do not specify any particular internal architecture, protocol, data structure, communication mechanism, or operational characteristic of the SDKs that distinguishes them from conventional SDKs. They are recited functionally — as conduits for “receiving” requests and “responding” with data. Any SDK integrated at a merchant’s platform could perform these functions.
“Technologically altering” the first party is conclusory. Applicant’s assertion that the SDKs “technologically alter” the first party’s computing device is a conclusory statement not supported by the claim language. Every software application “alters” a general-purpose computer in some sense — that is what software does. The relevant inquiry under Alice is whether the claims recite a specific improvement to computer functionality or merely use the computer as a tool to implement an abstract idea. Here, the SDKs are used as tools to implement the business process of extending installment options.
Having two SDKs vs. one does not constitute a technical improvement. The architectural decision to use two separate SDKs (wallet SDK and installment SDK) rather than one is a design choice in how to organize the software components that implement the business process. It does not improve the speed, efficiency, accuracy, or capability of the underlying computing hardware. The specification does not describe any technical advantage of using two SDKs versus one (indeed, dependent claims 6 and 9 recite that the two SDKs may be “integrated into a single SDK,” underscoring that this is a matter of software organization rather than technical improvement).
D. Applicant’s Argument: The Ordered Combination of Steps Provides Integration/Significantly More
Applicant argues that the “specific ordered combination of steps” integrates the abstract idea into a practical application.
Examiner’s Response:
The ordered combination has been considered. The combination of: (1) receiving a request via SDK → (2) determining eligibility → (3) returning types → (4) receiving a second request via second SDK → (5) determining options → (6) returning options → (7) creating/storing a plan — is simply the ordered steps of a two-round commercial negotiation (first narrowing by category, then selecting specific terms). The fact that each step is mediated by a different named SDK does not transform the business process into a technological improvement. The ordered combination merely recites the sequential steps of the business method, implemented using generic computing tools (SDKs, computing device, memory).
An ordered combination can demonstrate integration into a practical application when the combination produces a technical effect beyond what any individual element achieves (e.g., a specific data processing pipeline that reduces computational load). Here, the ordered combination produces only the expected result of each step: receiving requests and returning data. No synergistic technical effect arises from the combination.
E. Applicant’s Argument: Under Uniloc, Compatibility with Conventional Computers Does Not Render Claims Abstract
Applicant cites Uniloc USA, Inc. v. LG Electronics USA, Inc., No. 2019-1835 (Fed. Cir. 2020), for the proposition that claims are not rendered abstract merely because they are compatible with conventional computers.
Examiner’s Response:
The Examiner does not dispute this legal principle. However, the rejection is not based solely on the claims’ “compatibility with conventional computers.” Rather, the rejection is based on the determination that:
The claims recite an abstract idea (organizing installment payment options — a commercial interaction/fundamental economic practice);
The additional elements (SDKs, computing device, memory) are generic computing tools that do not integrate the abstract idea into a practical application; and
The additional elements do not provide an inventive concept (significantly more) because integrating SDKs at merchant platforms for payment processing is well-understood, routine, and conventional activity.
In Uniloc, the Federal Circuit found eligibility because the claims recited a specific technical solution (a particular sequence of communications in a wireless network that reduced latency in call setup by eliminating conventional signaling steps). Here, no analogous specific technical mechanism is claimed. The claims recite what is done (receive request, determine eligibility, return types, receive selection, determine options, return options, create plan) but not how it is done in a way that constitutes a technical improvement.
F. Applicant’s Argument: The Claims Provide “A Technical Solution Where None Had Existed”
Applicant asserts that “the claims integrate specific technology with the claimed subject matter to provide a technical solution, where none had existed.”
Examiner’s Response:
The assertion that “no technical solution existed” conflates a business problem with a technical problem. Prior to the instant application, merchants could and did offer installment options at checkout through various mechanisms (web interfaces, APIs, payment gateways). See Pinto (2020), Macedo (2017), Atieque (2021), among many others. The claims do not create a new technical capability — rather, they organize existing capabilities (SDKs, APIs, databases) into a particular business workflow for managing installment payments.
The test under the 2019 PEG is not whether the specific business workflow is new (it may well be), but whether the claims are directed to patent-eligible subject matter under § 101. A novel abstract idea is still abstract. See SAP Am., Inc. v. InvestPic, LLC, 898 F.3d 1161, 1163 (Fed. Cir. 2018) (“no matter how groundbreaking, innovative, or even brilliant [a] discovery may be,” if it falls within an abstract idea category, it is not eligible unless integrated or with significantly more).
III. § 102 Arguments — PERSUASIVE; REJECTION WITHDRAWN
Applicant’s arguments regarding the § 102 rejection are persuasive. As discussed in the “Withdrawal of Prior Art Rejection” section above, the amended claims introduce limitations not disclosed by Pinto (two-stage dual-SDK architecture, intermediate user type selection, multi-issuer aggregation, and separate repayment credential). The § 102 rejection is withdrawn.
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–10, 12–18 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.
Claim 1
Step 1 — Statutory Category
Claim 1 is directed to a “non-transitory computer-readable storage medium comprising executable instructions,” which falls within the statutory category of a manufacture. The claim satisfies Step 1.
Step 2A, Prong 1 — Does the Claim Recite a Judicial Exception?
Yes. Claim 1 recites an abstract idea falling within the “Certain Methods of Organizing Human Activity” grouping—specifically, fundamental economic practices and commercial interactions (coordinating installment lending options among merchants, issuers, and consumers at point-of-checkout).
The claim recites the following abstract idea limitations (with additional elements bolded):
[A non-transitory computer-readable storage medium comprising executable instructions, which when executed by at least one processor, cause the at least one processor to:]
[1] receive a first request for an action, from a user, via a first software development kit (SDK) integrated at a first party, wherein the action is between the user and the first party, the first request including identifying information for the first party;
[2] determine an eligibility of the first party for the action based on the identifying information for the first party and at least one parameter defined by the first party;
[3] respond to the first request with one or more eligibility types;
[4] receive a second request, via a second SDK integrated at the first party, for one or more installment options consistent with a first selection of one of the one or more eligibility types by the user;
[5] determine, based on one or more rules and the user selection, the one or more installment options, from a plurality of installment options offered by multiple issuers;
[6] respond to the second request with the one or more installment options; and
[7] in response to a second selection of one of the one or more installment options by the user, create a plan consistent with the one of one or more multiple options and store the plan in a memory, the plan including an account credential for an account associated with the plan.
The abstract idea is the process of: (i) receiving a request from a user for a financial action involving a merchant; (ii) determining the merchant’s eligibility for that financial action based on merchant-identifying information and merchant-defined parameters; (iii) presenting eligible installment types; (iv) receiving a further user selection from those types; (v) determining specific installment options from multiple issuers based on rules and the user’s selection; (vi) presenting the installment options; and (vii) upon user selection, creating an installment plan with an associated repayment account credential.
These limitations, when stripped of the computer implementation, describe a fundamental economic practice and commercial interaction—namely, a financial intermediary coordinating between a consumer and multiple lenders to determine eligibility and extend installment credit offers at a merchant’s point of sale, and then memorializing the selected plan. Such intermediary coordination of credit/installment products is a longstanding commercial practice (analogous to the abstract ideas identified in Alice Corp., Bilski, buySAFE, In re Salwan, and Lending Tree v. Zillow). The claim is directed to “who is eligible, what options are available, let the consumer pick one, and record the deal”—which is fundamentally an economic/commercial organizing activity.
Accordingly, the claim recites a judicial exception under Step 2A, Prong 1.
Step 2A, Prong 2 — Is the Judicial Exception Integrated into a Practical Application?
No. The claim does not integrate the abstract idea into a practical application.
The additional elements identified in the claim are:
#
Additional Element
Analysis
1
A non-transitory computer-readable storage medium comprising executable instructions, which when executed by at least one processor, cause the at least one processor to…
Generic computer components recited at a high level of generality. Amounts to “apply it” on a computer. See Spec. ¶¶ [0038]–[0040], [0056] (describing general-purpose processors, memories, standard computing environments).
2
via a first software development kit (SDK) integrated at a first party
An SDK is a generic software tool/interface for enabling communication between software components. Reciting that the SDK is “integrated at” a merchant’s platform describes a conventional software integration pattern (i.e., a merchant embedding a third-party library into their website/app). This does not impose a meaningful limit—it merely describes the technological environment/conduit through which the abstract commercial steps are performed. See Spec. ¶ [0017] (describing the SDK as a standard component integrated into an e-commerce platform).
3
via a second SDK integrated at the first party
Same analysis as above. A second SDK (or the same SDK) is another generic software interface at the merchant.
4
store the plan in a memory
Generic data storage function. Storing data in memory is a basic computer function. See Alice, 573 U.S. at 226; MPEP § 2106.05(d)(II) (storing and retrieving information in memory is well-understood, routine, and conventional).
None of the additional elements, individually or in combination, reflect:
An improvement to the functioning of a computer or to another technology — The claim does not recite any technical improvement to SDK architecture, network protocols, data structures, processing speed, memory efficiency, security mechanisms, or any other technological metric. The specification does not describe the claimed invention as solving a technical problem; rather, it solves a business problem of providing users with more installment options at checkout with “limited friction” (Spec. ¶ [0013])—a commercial convenience, not a technological improvement.
Application of the judicial exception with a particular machine — The recited processor and memory are generic. The SDKs are generic software tools. No particular machine architecture is claimed.
Transformation of an article to a different state or thing — No physical article is transformed.
Any other meaningful limitation — The SDKs and storage medium serve as generic conduits and repositories for the abstract commercial steps. They are analogous to using the Internet to perform an abstract business method (DDR Holdings distinguished; Ultramercial not).
The claimed SDKs are invoked as mere data-passing interfaces. The specification at ¶ [0017] confirms that the “installment SDK 120” and “wallet SDK 122” are standard software development kits that “may be included in a single SDK” or “otherwise included in the e-commerce platform”—confirming their generic, interchangeable nature. Reciting an SDK as the communication conduit is no different than reciting “via a network,” “via an API,” or “via a web browser”—all of which courts have found to be insignificant extra-solution activity or mere technological environment. See Intellectual Ventures I v. Capital One, 792 F.3d 1363, 1370 (Fed. Cir. 2015); Two-Way Media Ltd. v. Comcast Cable Commc’ns, 874 F.3d 1329 (Fed. Cir. 2017).
The additional limitation “from a plurality of installment options offered by multiple issuers” does not constitute a technical element—it merely describes the source of the financial products being organized (a field-of-use/business context limitation).
Accordingly, the judicial exception is not integrated into a practical application, and the claim is directed to an abstract idea.
Step 2B — Does the Claim Provide Significantly More (an “Inventive Concept”)?
No. The additional elements, considered individually and as an ordered combination, do not amount to significantly more than the abstract idea.
Additional Element
Significantly More?
Rationale
Non-transitory computer-readable storage medium / processor
No
Well-understood, routine, conventional (WURC). See Alice, 573 U.S. at 226; Spec. ¶¶ [0038]–[0040], [0056] (acknowledging general-purpose computing). MPEP § 2106.05(d)(II).
First SDK integrated at a first party
No
Integrating a third-party SDK into a merchant’s e-commerce platform is a well-known, routine software practice (akin to embedding a JavaScript library or API client). See Spec. ¶ [0017]. The specification does not allege that SDK integration itself is unconventional. Berkheimer consideration: the specification describes SDK integration as a known practice without elaboration on any novel technical implementation.
Second SDK integrated at the first party
No
Same as above.
Store the plan in a memory
No
Storing data in memory is one of the most basic computer operations. See MPEP § 2106.05(d)(II) (citing Versata Dev. Grp. v. SAP Am., Inc., 793 F.3d 1306, 1334 (Fed. Cir. 2015); OIP Techs., 788 F.3d at 1363).
Considered as an ordered combination, the additional elements merely link the abstract business method steps to a generic computing environment in a conventional manner: receive data via SDK → process data on a processor → store result in memory. This is the paradigmatic “apply it on a computer” implementation that the Supreme Court found insufficient in Alice. The ordered combination does not reveal any unconventional arrangement of components or any technical synergy that would amount to “significantly more.”
Claim 1 is NOT patent eligible under 35 U.S.C. § 101.
Claim 7
Step 1 — Statutory Category
Claim 7 is directed to a “computer-implemented method,” which falls within the statutory category of a process. The claim satisfies Step 1.
Step 2A, Prong 1 — Does the Claim Recite a Judicial Exception?
Yes. Claim 7 recites substantially the same abstract idea as Claim 1—coordinating installment lending options between merchants, issuers, and consumers—falling within the “Certain Methods of Organizing Human Activity” grouping (fundamental economic practices / commercial interactions).
The abstract idea limitations are:
[1] receiving a first request for an installment payment, from a user, via a wallet software development kit (SDK) integrated at a first party, wherein the installment payment is for a transaction between the user and the first party, the first request including identifying information for the first party;
[2] determining…an eligibility of the first party for the installment payment based on the identifying information for the first party and at least one installment parameter defined by the first party;
[3] responding…to the first request, with one or more eligible installment types;
[4] receiving a second request, via an installment SDK integrated at the first party, for one or more installment options consistent with a first selection of one of the one or more eligible installment types by the user;
[5] determining…based on one or more rules and the user selection of one of the one or more eligible installment types, the one or more installment options for the transaction;
[6] responding…to the second request, with the one or more installment options, from a plurality of installment options offered by multiple issuers; and
[7] in response to a second selection of the one or more installment options by the user, creating…an installment plan for the one or more installment options and storing the installment plan in a memory, the installment plan including a payment account credential for a repayment account for the instalment plan.
The additional elements are:
via a wallet software development kit (SDK) integrated at a first party
by an installment host computing device (recited as performing the determining, responding, and creating steps)
via an installment SDK integrated at the first party
storing the installment plan in a memory
The abstract idea itself is identical in substance to that of Claim 1.
Step 2A, Prong 2 — Is the Judicial Exception Integrated into a Practical Application?
No.
The additional element “by an installment host computing device” is a generic computing device. The specification at ¶ [0021] describes the installment host 116 as a server associated with the processing network, and ¶¶ [0038]–[0040] confirm it may be implemented by any general-purpose computing device (server, workstation, PC, etc.). Naming the computer an “installment host computing device” does not transform a generic computer into a particular machine—it merely labels the computer by its business function.
The “wallet SDK” and “installment SDK” are, as discussed above in the Claim 1 analysis, generic software interfaces. Specifying the type of SDK (wallet vs. installment) describes the business/functional role of the interface, not a particular technical architecture. This is a field-of-use limitation.
The phrase “integrated at a first party” describes where the SDK is deployed (at the merchant’s platform)—a description of the technological environment, not a meaningful technical limitation. See MPEP § 2106.05(h).
There is no improvement to computer functionality, no particular machine, no transformation, and no other meaningful limitation beyond applying the abstract idea using generic computing tools.
The judicial exception is not integrated into a practical application.
Step 2B — Does the Claim Provide Significantly More?
No. The analysis mirrors Claim 1. The “installment host computing device” is generic (Spec. ¶¶ [0038]–[0040]); wallet/installment SDKs are conventional software tools (Spec. ¶ [0017]); storing data in memory is WURC (MPEP § 2106.05(d)(II)). The ordered combination (receive via SDK → determine on server → respond via SDK → store in memory) is conventional client-server processing.
Claim 7 is NOT patent eligible under 35 U.S.C. § 101.
Claim 13
Step 1 — Statutory Category
Claim 13 is directed to a “system…comprising at least one computing device,” which falls within the statutory category of a machine. The claim satisfies Step 1.
Step 2A, Prong 1 — Does the Claim Recite a Judicial Exception?
Yes. Claim 13 recites substantially the same abstract idea as Claims 1 and 7. The abstract idea is the coordination of installment payment eligibility determination, option presentation, and plan creation between merchants, issuers, and users—a method of organizing human activity (commercial/financial interaction).
Additional elements:
A system…comprising at least one computing device configured to:
via a wallet software development kit (SDK) integrated at a first party
via an installment SDK integrated at the first party
storing the installment plan in a memory
Step 2A, Prong 2 — Is the Judicial Exception Integrated into a Practical Application?
No. The analysis is identical to Claims 1 and 7. The “at least one computing device” is generic (Spec. ¶¶ [0038]–[0040]); the SDKs are generic software interfaces (Spec. ¶ [0017]); the memory is generic storage. No technological improvement is claimed. The claim merely automates the commercial/financial coordination process on generic hardware.
Step 2B — Does the Claim Provide Significantly More?
No. Same analysis as Claims 1 and 7. Generic system components performing conventional computing functions.
Claim 13 is NOT patent eligible under 35 U.S.C. § 101.
Dependent Claims
Claims 2 and 8 and 14
These claims add:
solicit the account credential from the user, via the [installment/second] SDK; and receive the account credential, from the user, via the [installment/second] SDK, prior to creating the plan.
The additional act of soliciting/receiving a payment credential from a user is part of the abstract commercial interaction (collecting repayment information is a fundamental part of extending credit). The SDK is, as discussed, a generic software interface. These limitations do not integrate the abstract idea into a practical application or provide significantly more. Not patent eligible.
Claim 3
This claim narrows the field of use: “the action includes an installment payment; the plan includes an installment plan; the account credential includes a payment account credential.” These are mere field-of-use/labeling limitations that further describe the nature of the commercial interaction. No additional elements are introduced. Not patent eligible.
Claims 4, 12, and 18
These claims specify: “the identifying information for the first party includes a merchant acceptor ID (MAID) for the first party.” This further defines the type of identifying data used in the abstract eligibility determination—a data characterization that does not add a technical feature. A MAID is a conventional identifier in payment processing. Not patent eligible.
Claims 5, 10, 15, and 16
These claims add: “cause at least one payment account transaction, based on the payment account credential, consistent with the installment plan” / “initiating…at least one payment account transaction…”
Initiating a payment transaction based on stored account credentials is a fundamental economic/commercial activity (executing a financial transaction). It adds further abstract commercial steps without any technical improvement. Not patent eligible.
Claims 6 and 9
These claims specify: “the first SDK and the second SDK are integrated into a single SDK” / “the wallet SDK and the installment SDK are the same SDK.”
Combining two software interfaces into one is a routine design choice in software engineering and does not impose a meaningful technical limitation. It is merely an implementation detail of the generic software environment. Not patent eligible.
Claim 17
This claim adds: “prior to receipt of the first request, to provide a second payment account credential to a wallet application of the user for use in funding a full amount of the transaction between the user and the first party, the second payment account credential different from the payment account credential of the installment plan.”
This describes provisioning a payment credential to a user’s wallet application for funding the merchant transaction (separate from the repayment credential). Provisioning payment credentials to digital wallets is a well-known, routine financial/commercial practice. The “wallet application” is a generic software application. This limitation adds further abstract commercial/financial steps (pre-funding a transaction through a separate credential) without any claimed technical improvement to wallet technology or credential provisioning mechanisms. Not patent eligible.
Offending Clauses (Summary)
The following claim language recites the judicial exception without integration or significantly more:
“receive a first request for an action, from a user…the first request including identifying information for the first party” — receiving commercial data (data gathering / organizing human activity)
“determine an eligibility of the first party for the action based on the identifying information for the first party and at least one parameter defined by the first party” — evaluating business eligibility (commercial interaction / mental process capable of human performance with pen and paper)
“respond to the first request with one or more eligibility types” — communicating eligibility results (commercial interaction)
“receive a second request…for one or more installment options consistent with a first selection of one of the one or more eligibility types by the user” — receiving user selection (commercial interaction)
“determine, based on one or more rules and the user selection, the one or more installment options, from a plurality of installment options offered by multiple issuers” — applying business rules to select financial products (fundamental economic practice)
“respond to the second request with the one or more installment options” — communicating financial offers (commercial interaction)
“in response to a second selection…create a plan consistent with the one of one or more multiple options…the plan including an account credential for an account associated with the plan” — memorializing a financial agreement (commercial/legal interaction)
Conclusion
Claims 1–10, 12–18 are NOT patent eligible under 35 U.S.C. § 101.
The claims are directed to the abstract idea of coordinating installment payment options between merchants, issuers, and consumers (a method of organizing human activity—specifically, a fundamental economic practice and commercial interaction). The additional elements—a non-transitory computer-readable storage medium, a processor, an installment host computing device, a wallet SDK, an installment SDK, a memory, and a wallet application—are generic computing components recited at a high level of generality that amount to no more than mere instructions to apply the abstract idea using conventional computer technology. The claims do not recite an improvement to computer functionality or any other technology, a particular machine, or a transformation of an article. Therefore, the claims are directed to an abstract idea without significantly more.
Examiner Note
Withdrawal of § 102(a)(1) Rejection Over Pinto (US 2020/0151697)
The § 102(a)(1) rejection of claims 1–18 as anticipated by Pinto is withdrawn for the following reasons:
1. Amended Claims Introduce Distinguishing Limitations Not Disclosed by Pinto
Applicant’s amendment to independent claims 1, 7, and 13 introduces the following limitations that are not explicitly or inherently disclosed by Pinto:
(a) Two-stage SDK architecture at the merchant’s platform:
The amended claims require a first request received “via a wallet software development kit (SDK) at a first party” and a second request received “via an installment SDK at the first party.” Pinto discloses a network computer receiving requests via APIs from a resource provider computer or transport computer (¶¶ [0080]–[0087], [0100]–[0104]), but does not disclose or suggest two distinct SDKs (wallet SDK and installment SDK) integrated at the merchant’s e-commerce platform that mediate two sequential, distinct request-response interactions with an installment host.
(b) Two-stage interaction flow with intermediate user selection:
The amended claims require that the first request results in “one or more eligible installment types” being returned, followed by a user selection of one type, which triggers the second request for “installment options consistent with a selected one of the one or more eligible installment types.” Pinto’s disclosed flow (FIG. 4, steps 420–448) is a single-stage process: the network computer receives interaction data, identifies eligible plan options, and returns them directly. There is no intermediate step in which broad “types” (e.g., Pay-in-4, installments flex, extended tenure) are presented first, followed by a second, separate request for specific options within a user-selected type.
© Installment options from multiple issuers:
Independent claim 7, as amended, recites determining “at least one installment option for the transaction” based on rules, which, in the context of the specification (¶¶ [0013]–[0015], describing options from “various providers” and issuers 108a-c), encompasses aggregating options from multiple issuers for the same transaction. While Pinto’s ¶ [0084] mentions that the eligibility check API is “extendible to look-up eligibility across different issuer systems,” this is aspirational language describing potential future API capability — not a disclosed embodiment. Pinto’s actual described system (FIGS. 4–5) involves a single authorizing computer (112/412/512) per transaction.
(d) Separate repayment account credential stored in the installment plan:
The amended claims require “the installment plan including a payment account credential for a repayment account for the instalment plan.” In Pinto, the transaction is processed using the same payment account credential (e.g., PAN) provided at checkout (¶ [0107]–[0109]). Pinto does not disclose the user separately designating a distinct repayment account credential that is stored as part of the installment plan record, where that repayment credential is different from the credential used to fund the merchant transaction.
2. No Reasonable § 103 Combination Available
The Examiner considered whether a § 103 rejection could be maintained using Pinto in combination with one or more secondary references, including:
Macedo (US 2017/0193497) — wallet-mediated installments at merchant checkout
Atieque (US 2021/0012417) — SDK at merchant e-commerce platform; merchant-defined parameters
Steinmetz (US 2019/0378110) — separate repayment funding source
Mitchell (US 2020/0387923) — separate repayment account (different from transaction account)
Don et al. (US 2015/0278946, US 2015/0278948, US 2015/0278949) — securitized installment funding
Pinto (US 2020/0151697) — primary reference for eligibility and plan creation
After thorough consideration, the Examiner determined that no reasonable combination of the available prior art teaches or suggests:
(i) The two-stage dual-SDK architecture wherein a first SDK (wallet SDK) mediates a first request/response for installment types, and a second SDK (installment SDK) mediates a second request/response for specific installment options within a user-selected type. No reference discloses two distinct SDKs integrated at a merchant’s platform with different functional roles operating in sequence with an intermediate user selection between them.
(ii) Aggregation of installment options from multiple different issuers for presentation to a user in a single checkout session for a single transaction. While individual references disclose single-issuer/single-provider installment flows, none of the available references explicitly teach or suggest an installment host that aggregates and returns options from a plurality of different issuers (e.g., Issuer A, Issuer B, Issuer C) for the same transaction at the same merchant at the same time.
These two limitations, in combination with the other claimed steps, define a specific installment payment coordination architecture that is not disclosed, taught, or rendered obvious by the prior art of record. Combining the references to arrive at the claimed invention would require impermissible hindsight reconstruction, as:
No reference provides motivation to split a single eligibility API call into two distinct SDK-mediated interactions with an intermediate user selection step;
The “design choice” rationale would be insufficient without evidentiary support showing that one of ordinary skill would have reason to structure the checkout flow in this specific two-stage manner; and
Pinto’s ¶ [0084] language about extensibility to “different issuer systems” does not constitute a teaching or suggestion of actually implementing multi-issuer aggregation for a single transaction.
3. Art Cited but Not Relied Upon
The references identified during prosecution are listed in the “Prior Art Not Relied Upon” section of this Office Action as pertinent to the general field of installment payment systems but insufficient to support a rejection of the amended claims.
Accordingly, the prior art rejection is withdrawn, and the § 101 rejection is the sole remaining ground of rejection.
PRIOR ART NOT RELIED UPON BUT CONSIDERED PERTINENT
The following prior art references are made of record but are not relied upon in any rejection:
Pinto (US 2020/0151697 A1) — Installment eligibility determination, plan creation, and management by a network computer.
Macedo (US 2017/0193497 A1) — Digital wallet with installment options at merchant checkout.
Atieque (US 2021/0012417 A1) — Installment payment eligibility based on product-specific, merchant-specific, and customer-specific variables; SDK at e-commerce platform.
Steinmetz (US 2019/0378110 A1) — Consumer installment payment system with verified funding source linked to consumer account.
Mitchell (US 2020/0387923 A1) — Tracking transactions across payment networks; financing offers with separate repayment account; multiple enrolled payment accounts.
Don (US 2015/0278949 A1; US 2015/0278946 A1; US 2015/0278948 A1; US 2015/0278947 A1) — Securitized installment funding methods.
Conclusion
Art cited but not relied upon pertinent to application disclosure includes Macedo et al., U.S. 10,929,839 generally identifying a wallet, installment options and payments; Jagalpure et al., U.S. 2020/0160295 generally identifying installment transaction processing and installment plans; Atieque et al., U.S. 2021/0012417 generally identifying product specific data and merchant specific data; Ladds et al., U.S. 10,867,317 generally identifying user account data, installment arrangements and loyalty earnings; and George et al., U.S. 2019/0354950 generally identifying transactions, installment plans and eligibility.
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MICHAEL W ANDERSON whose telephone number is (571)270-0508. The examiner can normally be reached Monday - Thursday 9am-4pm.
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, Tariq Hafiz can be reached at (571) 272-5350. 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.
Mike Anderson
Supervisor Patent Examiner
Art Unit 3693
/Mike Anderson/Supervisory Patent Examiner, Art Unit 3693
Prosecution Insights