Prosecution Insights
Last updated: April 17, 2026
Application No. 17/925,701

METHOD AND SYSTEM FOR SECURE DIGITAL PAYMENT SPLIT BETWEEN ON-ORDER AND ON-DELIVERY

Non-Final OA §101§102
Filed
May 25, 2023
Examiner
CHAKRAVARTI, ARUNAVA
Art Unit
3692
Tech Center
3600 — Transportation & Electronic Commerce
Assignee
unknown
OA Round
3 (Non-Final)
9%
Grant Probability
At Risk
3-4
OA Rounds
4y 2m
To Grant
22%
With Interview

Examiner Intelligence

Grants only 9% of cases
9%
Career Allow Rate
37 granted / 409 resolved
-43.0% vs TC avg
Moderate +13% lift
Without
With
+12.7%
Interview Lift
resolved cases with interview
Typical timeline
4y 2m
Avg Prosecution
39 currently pending
Career history
448
Total Applications
across all art units

Statute-Specific Performance

§101
44.7%
+4.7% vs TC avg
§103
41.6%
+1.6% vs TC avg
§102
0.8%
-39.2% vs TC avg
§112
10.6%
-29.4% vs TC avg
Black line = Tech Center average estimate • Based on career data from 409 resolved cases

Office Action

§101 §102
DETAILED ACTION Status of Claims 1. This office action is in response to RCE filed 10/6/2025. 2. Claims 1-5, 9 are pending. 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 10/6/2025 has been entered. 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-5, 9 Claims 1-5, 9 are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more. Step 1: Claims 1-4 are directed to a system, 5, 9 are directed to a method – each of which is one of the statutory categories of inventions. Step 2A: A claim is eligible at revised Step 2A unless it recites a judicial exception and the exception is not integrated into a practical application of the application. Prong 1: Prong One of Step 2A evaluates whether the claim recites a judicial exception (an abstract idea enumerated in the 2019 PEG, a law of nature, or a natural phenomenon). Groupings of Abstract Ideas: I. MATHEMATICAL CONCEPTS A. Mathematical Relationships B. Mathematical Formulas or Equations C. Mathematical Calculations II. CERTAIN METHODS OF ORGANIZING HUMAN ACTIVITY A. Fundamental Economic Practices or Principles (including hedging, insurance, mitigating risk) B. Commercial or Legal Interactions (including agreements in the form of contracts; legal obligations; advertising, marketing or sales activities or behaviors; business relations) C. Managing Personal Behavior or Relationships or Interactions between People (including social activities, teaching, and following rules or instructions) III. MENTAL PROCESSES. Concepts performed in the human mind (including an observation, evaluation, judgment, opinion). See MPEP 2106.04 (a) (2) Abstract Idea Groupings [R-10.2019] Independent claim 1 recites digital payment processing for electronic commerce by splitting payment between On-Order and On-Delivery payment split policy (PSP) comprising: A Payment Orchestrator interacting with E-Wallets and Merchants’ System configured to: i) receive, from an e-Wallet system, a prepared payment (PP) for an amount associated with a PP reference (PPR), a merchant identifier, a customer identifier, and an identifier for said e-wallet system, create a hold, and add the customer identifier as a holder for the PP using a Multi- Hold Technique (MHT) Engine by sending the amount and identifiers to the MHT Engine; ii) receive and store, from a merchant system, a PPR and a PSP for an order, then if the merchant identifier is associated with the PPR and the PP amount has a Customer Hold (CH) as a state, forward said PSP and PPR to the e-wallet system, whose identifier is associated with said PPR, to get confirmation from customer whose identifier is associated with said PPR: iii) receive, from said e-wallet system, an indication for said confirmation associated with said PPR and the customer identifier, and the merchant identifier to add as another holder for the PP referenced by said PPR using the Multi-Hold Technique (MHT) Engine by sending the PPR and merchant identifier to the MHT engine; iv) based on the confirmation, split said PP amount into split 1 and split 2 according to said PSP by sending the PPR and PSPT to the MHT engine and remove the customer as a holder from the split 1 using the Multi-Hold Technique Engine by sending the PPR customer identifier, and the amount of the split to the MHT engine; v) receive, from the merchant system, a PPR and a delivery note, then if PPR split 2 amount has CH as part of the state, forward said note to the e-wallet system, whose identifier is associated with the PPR, to get confirmation from customer whose identifier is associated with said PPR: and vi) receive, from the e-wallet system, an indication for the confirmation associated with the PPR and customer identifier, then remove the customer as a holder from the split 2 using the Multi-Hold Technique Engine by sending the PPR, customer identifier, and the amount of the split to the MHT engine; Prepared-Payment Reference or PPR Generator, for unifying the format of generated PPR across all E-Wallets, configured to receive, from an e-wallet system, an e-wallet system identifier and a merchant identifier, generate a unique identifier, form the PPR to be containing the received identifiers and the generated identifier, then return the formed PPR; and the Multi-Hold Technique Engine, for managing the state transitions of the Prepared Payment or PP; according to a Multi-Hold Technique, wherein the MHT Engine is configured to: i) receive, from the Payment Orchestrator, the PP amount associated with the PPR, the merchant identifier, the customer identifier, and the identifier for e-wallet system, and create a hold record for said identifiers and said amount as a single split (Al), then add the Customer Hold (CH) for said single split so Al becomes CH: ii) receive, from the Payment Orchestrator, the PPR and the merchant identifier to add Merchant-Hold (MH) as another holder for said single split (Al), wherein if Al state is CH, the engine changes it to CH-MH; iii) receive, from the Payment Orchestrator, the PPR and the PSP that has two splits whose total is equal to the PP amount, split said single split amount into two split amounts Al and A2 according to received PSP, and set the state as CH-MH for Al and A2; and iv) receive, from the Payment Orchestrator, the PPR, the customer identifier, and the split amount Al or A2 to remove CH from the received split amount, so split amount state becomes MH, then the engine automatically changes it to Released-to-Merchant (RM). that constitutes Commercial/Legal Interactions and/or Managing Interaction between People and hence falls under the abstract idea category Certain Methods of Organizing Human Activity. The dependent claims further limit the abstract idea to – (claim 2) a PSP is decided for each PP; the PSP determines the PP amount of money, required by the Merchant to be paid On-Order (split 1), and the PP amount of money, required by the Merchant to be paid On-Delivery (split 2). (claim 3) wherein the Prepare-Payment Reference Generator generates a PPR for each PP; the PPR is a global unique identifier that contains a fully qualified electronic-address for a PP; PPR is global unique identifier as it has a generated unique identifier contained with the combination of e-wallet identifier and merchant identifier, said unique identifier format must be unified for PNS e-wallets and merchants, a Payment is considered Prepared when the controlling-system of the payer-account puts the payment amount on-hold with determination for the receiver of the payment, the payer account is the customer account referred here by the customer identifier. (claim 4) wherein the Multi-Hold Technique Engine manages PP state according to the MHT; the MHT enables multiple parties to add a hold for each party independently on the same PP; adding multiple holds on PP creates a multi-hold state for the PP; at the state, any of the parties can claim a whole/part-of the PP amount, the MHT mandates that the rest of parties must agree to remove their hold from the claimed amount to be released to the claiming party, wherein the MHT is carried out by the MHT Engine. that constitutes Commercial/Legal Interactions and/or Managing Interactions between People and hence falls under the abstract idea category Certain Methods of Organizing Human Activity. Independent claim 5 is directed to a method for digital payment processing for electronic commerce, characterized by splitting a digital payment amount into On-Order payment and On-Delivery payment based on a Payment-Split policy (PSP) comprising: setting payment attributes, wherein a Customer uses an E-Wallet to prepare a payment for a Merchant to pay for an order; the Customer sets the payment amount and the receiving Merchant for the payment; preparing the payment, wherein the E-Wallet creates a Prepared Payment (PP) record by marking the whole payment amount as 'on-hold' if the amount is available for said customer, and associates said amount with the identifier of said merchant and the identifier of said customer, without transferring said amount to any other party; generating the PPR, wherein the E-Wallet generates a Prepared Payment Reference (PPR) by sending the e-wallet system identifier and said merchant identifier to the PNS PPR Generator, receives generated PPR, and associates said PPR with said amount 'on-hold'; adding customer hold, wherein the E-Wallet adds Customer-Hold (CH) on the PP according to a Multi-Hold Technique (MHT) by sending said PPR, merchant identifier, customer identifier, and e-wallet system identifier to the PNS Payment Orchestrator; using PPR to pay, wherein the E-Wallet and displays the generated PPR to the Customer, then the Customer submits the PPR to the receiving Merchant's system via any e-commerce channel of said merchant; deciding PSP, wherein the Merchant's system decides the PSP for the order payment, then sends the decided PSP along with the PPR to a Payment Network System (the PNS)Payment Orchestrator; receiving sending the PSP in the E-Wallet, wherein the PNS forwards the PPR and the PSP, received from the Merchant's system, back to the E-Wallet that had originally generated the PPR; confirming the PSP, wherein the E-Wallet notifies the Customer to confirm acceptance for the PSP; once confirmed, the E-Wallet adds Merchant-Hold on the PP according to the MHT by sending an indication for said confirmation associated with the PPR, customer identifier, and merchant identifier to the PNS Payment Orchestrator; collecting on-order payment, wherein the E-Wallet makes a transfer of the on-order payment to the receiving Merchant; the transfer actually takes place via the PNS; claiming on-delivery payment, wherein the Merchant's system sends a delivery note along with the PPR to the PNS Payment Orchestrator to collect the on-delivery payment; receiving delivery note in the E-Wallet, wherein the PNS forwards the delivery note along with the PPR to the E-Wallet; confirming delivery, wherein the E-Wallet notifies the Customer to confirm order acceptance; once confirmed, E-Wallet removes the CH from the on-delivery payment according to the MHT by sending an indication for said confirmation associated with said PPR and customer identifier to the PNS Payment Orchestrator; and collecting on-delivery payment, wherein the E-Wallet makes a transfer of the on-delivery payment to the Merchant; the transfer actually takes place via the PNS. (claim 9) wherein two parties; E-Wallets and Merchants' Systems, interact with the PNS; wherein the parties must be registered in the PNS, by E-Wallet system identifier and merchant identifier respectively, so PNS can identify and validate them to be allowed to participate in payment processing. – that also constitute Certain Methods of Organizing Human Activity. Hence under Prong One of Step 2A, claims 1-5, 9 recite a judicial exception. Prong 2: Prong Two of Step 2A evaluates whether the claim recites additional elements that integrate the judicial exception into a practical application of the exception. Limitations that are indicative of integration into a practical application include: Improvements to the functioning of a computer or to any other technology or technical field – see MPEP 2106.05(a) Applying the judicial exception with, or by use of, a particular machine – see MPEP 2106.05(b) Effecting a transformation or reduction of a particular article to a different state or thing – see MPEP 2106.05(c) Applying or using the judicial exception in some other meaningful way beyond generally linking the use of the judicial exception to a particular technological environment, such that the claim as a whole is more than a drafting effort designed to monopolize the exception – see MPEP 2106.05(e) Limitations that are not indicative of integration into a practical application include: Adding the words “apply it” (or an equivalent) with the judicial exception, or mere instructions to implement an abstract idea on a computer, or merely uses a computer as a tool to perform an abstract idea – see MPEP 2106.05(f) Adding insignificant extra-solution activity to the judicial exception – see MPEP 2106.05(g) Generally linking the use of the judicial exception to a particular technological environment or field of use – see MPEP 2106.05(h) Additional elements recited by the claims, beyond the abstract idea, include: E-Wallet Gateway; Merchant Gateway; Payment Orchestrator; E-Wallets; Merchant System(s); Multi-Hold Technique (MHT) Engine; Prepare-Payment Reference (PPR) Generator. Figs. 1-4 display only a series of empty boxes with no descriptions. Examiner thus finds that any additional element(s), beyond the judicial exception, has been recited at a high level of generality such that the claim limitations amount to no more than mere instructions to apply the exception using generic components (see MPEP 2106.05(f)) or insignificant extra solution activities (see MPEP 2106.05(g)). The combination of limitations – (claim 1) receive, split, send, store, forward, remove, (claim 5) setting, preparing, generating, adding, displays, submits, deciding, confirming, collecting, claiming, receiving – does not purport to improve the functioning of a computer or effect an improvement in any other technology or technical field. Instead, the additional elements do no more than “use the computer as a tool” and/or “link the use of the judicial exception to a particular technological environment or field of use.” The focus of the claims is not on improvement in computers, but on certain independently abstract ideas – payment processing for electronic commerce by splitting payment between on-order and on-delivery payment split policy – that merely uses generic computers as tools. Each of the limitations constitute either executing Commercial/Legal Interactions on generic components or insignificant data gathering activities such as receiving and forwarding. See MPEP 2106.05 (g) (“all uses of the recited judicial exception require such data gathering or data output”). Steps that do no more than spell out what it means to “apply it on a computer” cannot confer patent eligibility. Indeed, nothing in claim 1 improves the functioning of the computer, makes it operate more efficiently, or solves any technological problem. See Trading Techs. Int’l, Inc. v. IBG LLC, 921 F.3d 1378, 1384-85 (Fed. Cir. 2019). Hence, the additional elements, when considered individually or in combination, do not integrate the judicial exception into a practical application. Hence, the claims are ineligible under Step 2A. Step 2B: In Step 2B, the evaluation consists of whether the claim recites additional elements that amount to an inventive concept (aka “significantly more”) than the recited judicial exception. As discussed in Prong Two, the additional elements in the claims amount to no more than mere instructions to apply the exception using generic components, which is insufficient to provide an inventive concept. When considered individually or as an ordered combination, the additional elements fail to transform the abstract idea of – digital payment processing for electronic commerce by splitting payment between on-order and on-delivery payment split policy – into significantly more. See MPEP 2106.05(f) Mere Instructions To Apply An Exception [R-10.2019]. (2) Whether the claim invokes computers or other machinery merely as a tool to perform an existing process. Use of a computer or other machinery in its ordinary capacity for economic or other tasks (e.g., to receive, store, or transmit data) or simply adding a general purpose computer or computer components after the fact to an abstract idea (e.g., a fundamental economic practice or mathematical equation) does not integrate a judicial exception into a practical application or provide significantly more. Hence, the claims are ineligible under Step 2B. Therefore, the claim(s) are rejected under 35 U.S.C. 101 as being directed to a judicial exception without significantly more. Response to Arguments Applicant's arguments filed 10/6/2025 have been fully considered but they are not persuasive. 101 Applicant argues that a Single-Hold/Multi-Split Architecture with Multi-Party Control is an improvement to Computer Performance. Examiner finds this unpersuasive because the alleged improvement is only in payment processing and not to computer performance. Furthermore, the various assertions made on pages 10 (duplication of ledger entries, redundant authorization logic, increased storage, memory and CPU), 11-12 (improves processing performance, data storage efficiency, simplifying storage processing, network utilization and operational overhead) are purely speculative and completely unsupported by the specification. Examiner notes that any alleged reduction of computing resources a) merely reflects an effect or result, b) represents speculative relative reduction over a hypothetical situation that may never materialize, and c) does not provide a meaningful limitation because it merely applies the abstract idea to aim for an aspirational result. See MPEP 2106.05(f) (1) (cautioning against claims “so result focused, so functional, as to effectively cover any solution to an identified problem”), (3) (“describes “the effect or result dissociated from any method by which maintaining the state is accomplished” and does not provide a meaningful limitation because it merely states that the abstract idea should be applied to achieve a desired result”). Applicant argues that customer-initiated authorization without credential exposure is an improvement to transactional security. Examiner finds this unpersuasive because transmitting non-sensitive identifier (PPR) to merchants instead of card, wallet, or account data, is a part of the abstract idea of Certain Methods of Organizing Human Activity as opposed to technical improvement. Similarly, with respect to the applicant’s argument that dynamic payment splitting based on enforced flexible policy is an improvement to transaction workflows, Examiner notes that this argument, at best, pertains to the abstract idea as opposed to improvement in the functioning of the computer or technology. See Trading Tech. Int’l, Inc. v. IBG LLC, 921 F.3d 1378, 1385 (Fed. Cir. 2019) (“The abstract idea itself cannot supply the inventive concept.”). The alleged improvement lies in the abstract idea itself, not to any technological improvement. See Customedia Techs., LLC v. Dish Network Corp., 951 F.3d 1359, 1364 (Fed. Cir. 2020) (“To be a patent-eligible improvement to computer functionality, we have required the claims to be directed to an improvement in the functionality of the computer or network platform itself.”). The combination of additional elements in claims 1, 5-9 does not recite (i) an improvement to the functionality of a computer or other technology or technical field; (ii) a “particular machine” to apply or use the judicial exception; (iii) a particular transformation of an article to a different thing or state; or (iv) any other meaningful limitation. See MPEP 2106.05 (a)-(c), (e)-(h). Hence, the additional elements, individually or in combination, do not integrate the abstract idea into a practical application or provide significantly more. See MPEP 2106.05(f) (“Use of a computer or other machinery in its ordinary capacity for economic or other tasks (e.g., to receive, store, or transmit data) or simply adding a general purpose computer or computer components after the fact to an abstract idea (e.g., a fundamental economic practice or mathematical equation) does not provide significantly more.”). Previously Addressed Arguments Applicant argues that the claims do not recite abstract ideas but instead recite an improved method for secure digital payment processing for electronic commerce comprising specific methods. Applicant argues, citing para [0088] – [0100] that, in contrast to conventional methods, the current invention allows for improved computer-implemented process addressing drawbacks of existing system and provides technical advantages related to security, decoupled connectivity, networking, and the like. Examiner respectfully disagrees. Examiner notes that splitting a payment between On-Order and On-Delivery payment split policy constitutes Commercial/Legal Interactions. In claim 1, payment data is received from e-wallet system; payment split policy is received from merchant system and forwarded to e-wallet system to get confirmation from customer; after receiving an indication of confirmation from the e-wallet system, merchant identifier is added as a holder; payment is split into two amounts and customer identifier is removed as a holder from on-order split; a delivery note is received from merchant system and forwarded to e-wallet system to get confirmation from customer; customer confirmation is received and customer identifier is removed as a holder from on-delivery split. Each of the limitations of the independent claims constitute either Commercial/Legal Interactions or insignificant data gathering activities such as receiving and forwarding. See MPEP 2106.05 (g) (“all uses of the recited judicial exception require such data gathering or data output”). The pending claims are directed to splitting payment between on-order payment and on-delivery payment based on a payment-split policy, and merely use the additional elements to implement this payment splitting arrangement. The improvement recited in the claim does not improve the e-wallet or the merchant system. Instead, the alleged improvement recited in the claims is an abstract idea, i.e., payment spilt for an electronic commerce order between on-order payment and on-delivery payment. See SAP America, Inc. v. InvestPic, LLC, 898 F.3d 1161, 1170 (Fed. Cir. 2018) (“[P]atent law does not protect such claims[, i.e., claims to an asserted advance in the realm of abstract ideas], without more, no matter how groundbreaking the advance.”). Indeed, nothing in the claims improves the functioning of a computer, makes it operate more efficiently, or solves any technological problem. See Trading Techs. Int’l, Inc. v. IBG LLC, (Fed. Cir. 2019). Finally, Applicant’s argument regarding the absence of a prior art rejection is unpersuasive, because a prior art rejection is determined under 35 U.S.C. § 102 and § 103, which are distinct statutes with different statutory requirements from 35 U.S.C. § 101. As the Supreme Court observed in Diamond v. Diehr, 450 U.S. 175, 188-89 (1981) (“[t]he ‘novelty’ of any element or steps in a process, or even of the process itself, is of no relevance in determining whether the subject matter of a claim falls within the § 101 categories of possibly patentable subject matter.”) See also Two-Way Media Ltd. v. Comcast Cable Commc’ns, LLC, 874 F.3d 1329, 1340 (Fed. Cir. 2017) (“[e]ligibility and novelty are separate inquiries.”). Conclusion Any inquiry concerning this communication or earlier communications from the examiner should be directed to ARUNAVA CHAKRAVARTI whose telephone number is (571)270-1646. The examiner can normally be reached 9 AM - 5 PM ET. Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice. If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Ryan Donlon can be reached at 571-270-3602. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300. Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000. /ARUNAVA CHAKRAVARTI/Primary Examiner, Art Unit 3692
Read full office action

Prosecution Timeline

May 25, 2023
Application Filed
Sep 13, 2024
Non-Final Rejection — §101, §102
Jan 29, 2025
Response Filed
Jun 06, 2025
Response Filed
Jul 03, 2025
Final Rejection — §101, §102
Sep 14, 2025
Examiner Interview Summary
Oct 10, 2025
Response after Non-Final Action
Nov 06, 2025
Request for Continued Examination
Nov 10, 2025
Response after Non-Final Action
Feb 25, 2026
Non-Final Rejection — §101, §102 (current)

Precedent Cases

Applications granted by this same examiner with similar technology

Patent 12561676
SYSTEMS AND METHODS FOR IMPROVING DATA PROCESSING AND MANAGEMENT
2y 5m to grant Granted Feb 24, 2026
Patent 12541747
METHOD AND APPARATUS FOR CONDUCTING SECURE FINANCIAL AND INFORMATIONAL TRANSACTIONS VIA PORTABLE SMART DEVICES
2y 5m to grant Granted Feb 03, 2026
Patent 12536549
TRANSACTION CARDS AND COMPUTER-BASED SYSTEMS THAT PROVIDE FRAUD DETECTION AT POS DEVICES BASED ON ANALYSIS OF FEATURE SETS AND METHODS OF USE THEREOF
2y 5m to grant Granted Jan 27, 2026
Patent 12518270
METHOD AND SYSTEM FOR COMPLETING A DATA TRANSFER
2y 5m to grant Granted Jan 06, 2026
Patent 12314932
HANDOFF BETWEEN APPLICATIONS ON A PAYMENT TERMINAL
2y 5m to grant Granted May 27, 2025
Study what changed to get past this examiner. Based on 5 most recent grants.

AI Strategy Recommendation

Get an AI-powered prosecution strategy using examiner precedents, rejection analysis, and claim mapping.
Powered by AI — typically takes 5-10 seconds

Prosecution Projections

3-4
Expected OA Rounds
9%
Grant Probability
22%
With Interview (+12.7%)
4y 2m
Median Time to Grant
High
PTA Risk
Based on 409 resolved cases by this examiner. Grant probability derived from career allow rate.

Sign in for Full Analysis

Enter your email to receive a magic link. No password needed.

Free tier: 3 strategy analyses per month