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 .
Information Disclosure Statement
The Information Disclosure Statements filed 09/12/2025 and 05/30/2014 have been considered. Initialed copies of the forms PTO-1449 are enclosed herewith.
Drawings
The drawings are objected to because of the following informalities:
Figs. 8-11: Numbers, letters, and reference characters must measure at least .32 cm. (1/8 inch) in height. See MPEP 608.02 V (p) (3). Examiner notes multiple text instances in these drawings do not comply with these requirements, particularly with respect to size and color (i.e. multiple text elements are smaller than the required height).
Acknowledgements
This Office Action addresses the response filed on 08/12/2026.
Claim 49 was amended.
Claims 33-54 are pending.
Claims 36-40, 47, 48 and 50-54 were previously withdrawn.
Claims 33-35, 41-46 and 49 were examined.
Claim Objections
Claims 42-44 are objected to because of the following informalities: Claims 42-44 depend on claim 33 and recite a “first financial institution”. Claim 33 recite a “financial institution”. Therefore, since no “second financial institution” is recited by the claims, these claim elements are being treated as directed to the same financial institution. For claim precision purposes, Examiner suggests removal of the term “first” in claims 42-44. Appropriate correction is required.
Admitted prior art
The common knowledge or well-known in the art statement(s) in the previous Applicant’s remarks dated 08/12/2026 taken to be admitted prior art includes:
“The Office Action's key argument - that Asbe lacks a feature of "storing the transaction data for later settlement" is therefore incorrect. The entire architecture in Asbe is built on processing individual transactions in real-time while deferring the inter-bank settlement to a batch process at the "end of the day". This inherently requires storing the data from each transaction until such settlement occurs.”
In other words, Applicant admits that a “batch process” inherently requires storing data from each transaction.
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 33-35, 41-46 and 49 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. Claim 49 is rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter.
According to MPEP 2106 II, It is essential that the broadest reasonable interpretation (BRI) of the claim be established prior to examining a claim for eligibility. Further, MPEP 2103 I C establishes that the subject matter of a properly construed claim is defined by the terms that limit the scope of the claim when given their broadest reasonable interpretation. It is this subject matter that must be examined. Regarding the independent claims, claims 33 and 45 recite “the transaction data comprising an alias of the payer, an alias of the payee”, language directed to non-functional descriptive material. See MPEP 2111.05. In addition, claims 33 and 45 recite “initiating settlement… to cause release of the payment amount from the reservation of funds, deduction of funds from a balance of the payer account and addition of funds to a payee account associated with the payee, wherein the deduction and addition of funds correspond to the payment amount. ” , a statement of intended use or field use. See MPEP 2114 II. Lastly, claim 33 is a method claim and recites “the payment amount being deducted from the balance of the digital wallet...” language directed to not positively recited method steps.
With respect to the Eligibility Step 1 of the Alice/Mayo two-part test of the subject matter eligibility analysis (see MPEP 2106), in the instant case, claims 33-35 and 41-44 are directed to a method, claim 45 is directed to a system, claim 46 is directed to a server-based computing resource and claim 49 is directed to a non-transitory computer readable medium. Therefore, these claims fall within the four statutory categories of invention.
Following step 2A, prong one of the analysis, the language of the independent claims reciting an abstract idea are marked in bold below:
a. maintaining, at a financial institution, a reservation of funds in a payer account, the payer account being associated with the payer;b. maintaining, by a computerized digital wallet server function, a digital wallet for the payer, the digital wallet having a balance corresponding to the reservation of funds in the payer account;c. making, by a payer communication device usable by the payer, a payment request for the digital payment at the digital wallet server function;d. by the digital wallet server function: registering transaction data for the digital payment, the transaction data comprising an alias of the payer, an alias of the payee, and a representation of a payment amount, the payment amount being deducted from the balance of the digital wallet;e. causing a digital notification of the digital payment to a payee communication device usable by the payee; f. storing the transaction data for later settlement; andg. subsequently initiating settlement of the digital payment based on the stored transaction data to cause release of the payment amount from the reservation of funds, deduction of funds from a balance of the payer account and addition of funds to a payee account associated with the payee, wherein the deduction and addition of funds correspond to the payment amount.
Therefore, the portions highlighted in bold above recite intermediated settlement, which is an abstract idea grouped within the certain methods of organizing human activity grouping of abstract ideas in prong one of step 2A. The claims are grouped within certain methods of organizing human activity because the steps recited describe the fundamental economic practice of intermediating settlement of a payment transaction between two entities (i.e. payer and payee). Accordingly, the claims recite an abstract idea.
With respect to step 2A, prong two of the analysis, this judicial exception is not integrated into a practical application. Specifically, with respect to using financial institution, payer communication device, digital wallet server to perform the recited steps/functions, these additional elements performs the steps or functions such as: “maintaining… funds…”, “maintaining… wallet…”, “making… payment request…”, “registering… data…”, “causing… notification…”, “storing… data…”, “initiating… settlement…”. These additional elements are recited at a high-level of generality such that it represents no more than mere instructions to apply the exception using a generic computer component, which only serves to use computers as a tool to perform the abstract idea. Therefore, these elements do not integrate the abstract idea into a practical application because they require no more than a computer performing functions that correspond to acts required to carry out the abstract idea. The additional element(s) of digital wallet, digital notification, digital payment amount to generally linking the use of the judicial exception to a particular technological environment or field of use. Accordingly, these additional elements do not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea. Therefore, following the analysis of step 2A, prong two, the claims are still directed to an abstract idea.
With respect to step 2B of the analysis, the claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to the integration of the abstract idea into a practical application, the additional computer elements, such as financial institution, payer communication device, digital wallet server, digital wallet, digital notification, digital payment. The financial institution, payer communication device, digital wallet server perform the steps/functions of “maintaining… funds…”, “maintaining… wallet…”, “making… payment request…”, “registering… data…”, “causing… notification…”, “storing… data…”, “initiating… settlement…”, and amount to no more than mere instructions to apply the exception using generic computer components. Mere instructions to apply an exception using generic computer components cannot provide an inventive concept beyond the abstract idea of intermediated settlement. The additional element(s) of digital wallet, digital notification, digital payment amount to generally linking the use of the judicial exception to a particular technological environment or field of use. As discussed above, taking the claim elements separately, these additional elements perform the steps or functions that correspond to the actions required to perform the abstract idea. Viewed as a whole, the combination of elements recited in the claims merely recite the concept of intermediated settlement. Therefore, the independent claims are not eligible.
Examiner notes that, for elements recited in the dependent claims which were previously analyzed as additional elements of the independent claims above (i.e. financial institution, payer communication device, digital wallet server), the assessment of these elements under step 2A and step 2B for the dependent claims is inherited from the analysis of the independent claims and omitted for brevity, unless noted by Examiner below. Dependent claims 34, 35, 41-46 and 49 further recite the following additional language, in which elements which merely further define the identified abstract idea are marked in bold below:
h) wherein the digital notification of the digital payment to the payee communication device serves as an instant notification to the payee that the payment amount has been logically transferred from the payer, even though the digital payment has not yet been settled, and wherein upon being instantly notified by the digital notification of the digital payment, the payee communication device provides a goods or performs a service associated with the digital payment, or enables the payee to do so. i) wherein: the digital wallet server function initiates settlement of the digital payment by communicating the stored transaction data to a computerized payment switch functionality; the payment switch functionality maintains cross-reference data that links payer aliases and payee aliases of payers and payees to user accounts at financial institutions or payment service providers; and the payment switch functionality uses the communicated transaction data and the cross-reference data to cause settlement of the digital payment. j) further involving the digital wallet server function: initially determining that the payment amount of the payment request for the digital payment exceeds the balance of the digital wallet for the payer; and splitting the digital payment into two parts, a first part of the digital payment being performed by the steps recited in claim 33 in a first payment amount which does not exceed the balance of the digital wallet for the payer, and a second part of the digital payment being performed by initiating immediate settlement of the digital payment based on the alias of the payer, the alias of the payee and a representation of a second payment amount to cause deduction of funds from the balance of the payer account and addition of funds to the payee account, wherein the deduction and addition of funds correspond to the second payment amount, and wherein the second payment amount is the difference between the payment amount and the first payment amount. k) wherein the computerized digital wallet server function takes the form of a complementary or additional layer of computerized core banking resources of the first financial institution. l) wherein the computerized digital wallet server function is hosted by the first financial institution. m) the first financial institution having a computerized core banking system, wherein the method further involves: the computerized core banking system detecting that the digital wallet is in need of a top-up; and in response performing a top-up by reserving an appropriate top-up amount in the payer account and increasing the balance of the digital wallet accordingly. n) A server-based computing resource configured to perform the functionality of the computerized digital wallet server function in the method as defined by claim 33. o) A non-volatile computer readable medium having stored thereon a computer program comprising computer program code for performing the functionality of the computerized digital wallet server function in the method as defined by claim 33 when the computer program code is executed by a processing device.
With respect to claim 34, the claim recites item h) above, language which does not introduce additional elements/functions. The additional language merely represents statements directed to directed to non-functional descriptive material by describing what the notification "serves as". Those statements are insufficient to significantly alter the eligibility analysis. This language further elaborates the abstract idea of intermediated settlement identified in the analysis of independent claims 33 and 45. Therefore, this language does not significantly alter the analysis with respect to the independent claim 33. The additional elements/functions, alone or in combination, are insufficient to integrate the abstract idea into a practical application because the additional elements/functions do not pertain to an improvement to the functioning of a computer or to another technology. The additional elements/functions, alone or in combination, do not offer significantly more than the abstract idea, because the additional elements/functions merely further recite additional instructions to implement the abstract idea on a computer.
With respect to the eligibility analysis of claim 35, Item i) above introduces the additional elements/functions of communicating data and maintaining data. This language further elaborates the abstract idea of intermediated settlement identified in the analysis of independent claims 33 and 45. Therefore, this language does not significantly alter the analysis with respect to the independent claim 33. The additional elements/functions, alone or in combination, are insufficient to integrate the abstract idea into a practical application because the additional elements/functions do not pertain to an improvement to the functioning of a computer or to another technology. The additional elements/functions, alone or in combination, do not offer significantly more than the abstract idea, because the additional elements/functions merely further recite additional instructions to implement the abstract idea on a computer.
With respect to the eligibility analysis of claim 41, Item j) above introduces the additional elements/functions of allocating payment amounts. This language further elaborates the abstract idea of intermediated settlement identified in the analysis of independent claims 33 and 45. Therefore, this language does not significantly alter the analysis with respect to the independent claim 33. The additional elements/functions, alone or in combination, are insufficient to integrate the abstract idea into a practical application because the additional elements/functions do not pertain to an improvement to the functioning of a computer or to another technology. The additional elements/functions, alone or in combination, do not offer significantly more than the abstract idea, because the additional elements/functions merely further recite additional instructions to implement the abstract idea on a computer.
With respect to the eligibility analysis of claim 42, this language further elaborates the abstract idea of intermediated settlement identified in the analysis of independent claims 33 and 45. Therefore, this language does not significantly alter the analysis with respect to the independent claim 33. The additional elements/functions, alone or in combination, are insufficient to integrate the abstract idea into a practical application because the additional elements/functions do not pertain to an improvement to the functioning of a computer or to another technology. The additional elements/functions, alone or in combination, do not offer significantly more than the abstract idea, because the additional elements/functions merely further recite additional instructions to implement the abstract idea on a computer.
With respect to the eligibility analysis of claim 43, this language further elaborates the abstract idea of intermediated settlement identified in the analysis of independent claims 33 and 45. Therefore, this language does not significantly alter the analysis with respect to the independent claim 33. The additional elements/functions, alone or in combination, are insufficient to integrate the abstract idea into a practical application because the additional elements/functions do not pertain to an improvement to the functioning of a computer or to another technology. The additional elements/functions, alone or in combination, do not offer significantly more than the abstract idea, because the additional elements/functions merely further recite additional instructions to implement the abstract idea on a computer.
With respect to the eligibility analysis of claim 44, Item m) above introduces the additional elements/functions of detecting… need of a top-up and performing a top-up. This language is representative of the additional abstract idea of maintaining an account balance. Adding one abstract idea (maintaining an account balance) to another abstract idea (intermediated settlement) does not render the claim non-abstract. The additional elements/functions, alone or in combination, are insufficient to integrate the abstract idea into a practical application because the additional elements/functions do not pertain to an improvement to the functioning of a computer or to another technology. The additional elements/functions, alone or in combination, do not offer significantly more than the abstract idea, because the additional elements/functions merely further recite additional instructions to implement the abstract idea on a computer.
With respect to the eligibility analysis of claim 46, this language further elaborates the abstract idea of intermediated settlement identified in the analysis of independent claims 33 and 45. Therefore, this language does not significantly alter the analysis with respect to the independent claim 33. The additional elements/functions, alone or in combination, are insufficient to integrate the abstract idea into a practical application because the additional elements/functions do not pertain to an improvement to the functioning of a computer or to another technology. The additional elements/functions, alone or in combination, do not offer significantly more than the abstract idea, because the additional elements/functions merely further recite additional instructions to implement the abstract idea on a computer (i.e. computing resource).
With respect to the eligibility analysis of claim 49, this language further elaborates the abstract idea of intermediated settlement identified in the analysis of independent claims 33 and 45. Therefore, this language does not significantly alter the analysis with respect to the independent claim 33. The additional elements/functions, alone or in combination, are insufficient to integrate the abstract idea into a practical application because the additional elements/functions do not pertain to an improvement to the functioning of a computer or to another technology. The additional elements/functions, alone or in combination, do not offer significantly more than the abstract idea, because the additional elements/functions merely further recite additional instructions to implement the abstract idea on a computer (i.e. medium).
Therefore, while the additional language h)-o) of dependent claims 34, 35, 41-44, 46 and 49 slightly modify the analysis provided with respect to independent claim 33, these additional elements/functions are insufficient to render the dependent claims eligible, as detailed above. Therefore, these dependent claims are also ineligible.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 33-35, 41-43, 45, 46 and 49 are rejected under AIA 35 U.S.C. 103 as being unpatentable over Asbe et al. (US 2019/0303910 A1), hereinafter Asbe in view of Schleicher et al. (US 2006/0235758 A1), hereinafter Schleicher.
With respect to claims 33, 45, 46 and 49, Asbe teaches a digital payment system comprising: a computerized digital wallet server function; and a payer communication device usable by a payer (Claim 45), a server-based computing resource configured to perform the functionality of the computerized digital wallet server function in the method as defined by claim 33 (Claim 46); and a non-volatile computer readable medium having stored thereon a computer program comprising computer program code for performing the functionality of the computerized digital wallet server function in the method as defined by claim 33 when the computer program code is executed by a processing device (Claim 49) (see Fig. 1, paragraphs [0041]-[0044]. See also user devices 1006.); and a computerized method of performing a digital payment by a payer to a payee (An electronic payment system and method thereof) comprising:
maintaining, at a financial institution, a reservation of funds in a payer account, the payer account being associated with the payer (see paragraph [0040]: “The present disclosure addresses interoperability of banking mobile applications and/or bank web-portals for payment transactions. Using the system of the present disclosure, users and/or bank customers are not restricted to use the web-portals and/or mobile-webs of the banks in which they have their account(s). Instead, the users (both payer and payee) and/or customers can choose any bank's web-portal or mobile-web for their payment transactions without knowing bank account details of other user/person. The users (payer or payee) are required to know only a unique ID or virtual payment address (VPA) to make financial/electronic payment transactions.”; paragraph [0058]: “... In the abovementioned step ‘a’ of ‘registering with a PSPS’, users register with a bank of their choice by opening an account in the bank. If a user already has an account in a bank he can register for mobile banking by providing necessary details including details of his user device, in order to register the user device...");
maintaining, by a computerized digital wallet server function, a digital wallet for the payer, the digital wallet having a balance corresponding to the reservation of funds in the payer account (Claim 33) /wherein the computerized digital wallet server function is configured for: maintaining a digital wallet for the payer, the digital wallet having a balance corresponding to a reservation of funds in a payer account maintained at a financial institution, the payer account being associated with the payer (Claim 45) (see VPAs, paragraph [0058]: “... In step ‘d’, the user is required to create a VPA. Screen for VPA creation is illustrated in FIG. 8A. As the user is registered with his bank, and provides details of the same to use the PSPA tool. The user account number is automatically displayed on the VPA creation screen of FIG. 8A. Thus, the user does not need to remember his account details. The user is then prompted to create new VPA or use VPAs registered by him (if he has done VPA creation previously).”);
making, by a payer communication device usable by the payer, a payment request for the digital payment at the digital wallet server function (Claim 33) / wherein the payer communication device is configured for making a payment request for a digital payment at the digital wallet server function (Claim 45) (see paragraph [0060]: “After completion of the registration and VPA creation process, the users (payers and payees) have respective VPAs. The payer or payee uses the VPAs/unique IDs, without knowing bank names or bank account details of another person, for carrying out payment transactions. The VPA and bank details of all users are maintained by the respective local storage devices and processed by respective PSPS servers, and are not to be shared by the UPI (100).”; paragraph [0061]: “The payment transactions include collect transactions (collect request) and pay transactions (pay request).."paragraph [0084]: “When a payer wants to send money to a payee (i.e. Push money or Pay transaction or Push request) (FIG. 2B), the payer uses a payer's user device (104) to access and operate a PSPA tool to provide an authorized VPA of the payee along with the amount that the payer wants to send to the payee (step 1). The display screen displayed to the payer, in one embodiment of this case, is illustrated in FIG. 8C. This screen is displayed on the initiation of a push/pay request (i.e. ‘pay to VPA’ of FIG. 8B). In the pay to VPA, the user's/payer's VPA is automatically populated as he has already registered with the PSPA tool with details of his PSPS. The payer then needs to enter VPA of the payee, amount that is required to be collected, and remarks if any... The payer's authentication routes to the UPI (100) along with the payer's registered bank details and payee's VPA, via the Payer's PSPS (108) (step 2)...");
by the digital wallet server function: registering transaction data for the digital payment, the transaction data comprising an alias of the payer, an alias of the payee, and a representation of a payment amount, the payment amount being deducted from the balance of the digital wallet (Claim 33) / registering transaction data for the digital payment, the transaction data comprising an alias of the payer, an alias of a payee, and a representation of a payment amount, the payment amount being deducted from the balance of the digital wallet (Claim 45) (see . The UPI (100) identifies a payee's PSPS (106) based on the suffix code of the payee's VPA, and sends request to the payee's PSPS (106) (step 3). The payee's PSPS (106) authorizes the bank details registered with the payee PSPA tool on the payee's PSPS (106) via the payee's paragraph [0084]: “...The UPI (100) now has bank details of both the payer and the payee based on their VPA's/unique IDs. The UPI (100) uses the bank details to communicate with the remitter bank (110) (i.e., the payer's bank) and debit the desired amount (step 5 and 6) and then communicate with the beneficiary bank (112) (i.e., the payee's bank) to credit that 1amount to complete the transaction (step 7 and 8). After successful transaction, the UPI (100) sends transaction success information to PSPA tools of the payer (step 9a, 9b and 10) and the payee, which is accessed by the payer's user device (104) and the payee's user device (102) respectively, wherein the transaction details popup on displays of respective user devices via respective PSPA tools.”);
causing a digital notification of the digital payment to a payee communication device usable by the payee (see paragraph [0092]: “Step 406—The UPI (100) resolves the payee Address in the following two ways [0093] a. If the address has global identifiers (for example, Mobile number, unique ID, account number, etc.) then the payee address can be resolved by the UPI (100) central mapper. [0094] b. If the address has virtual address offered by payee's PSPS (106), then the UPI (100) sends the request to the payee's PSPS (106) for address translation.”; paragraph [0095]: “Step 407—In case of 406b, the payee's PSPS (106) accepts or rejects the request based on the rules set at his end.”; paragraph [0096]: “Step 408—In case of 406b, on accepting the Pay request, the payee's PSPS (106) populates the payee details and responds to the UPI (100).”);
subsequently initiating settlement of the digital payment based on the stored transaction data to cause release of the payment amount from the reservation of funds, deduction of funds from a balance of the payer account and addition of funds to a payee account associated with the payee, wherein the deduction and addition of funds correspond to the payment amount (see paragraph [0048]: “The UPI (100) facilitates registration of a PSPS (1004) with the EPS (1000), and further facilitates controlled movement of transactional data signals selectively between PSPSs, to effect payment from one registered user to another registered user in same or different PSPSs. The UPI (100) comprises a settlement module (100a) which cooperates with the plurality of PSPSs to periodically collate credit and debit transactions, and generate net credit and debit instructions between the registered PSPSs. In an embodiment, the settlement module (100a) is a settlement server.”; paragraph [0051]: “...In an embodiment, the transaction processing is carried out with the help of the transaction server. The payment settlements among the banks and the PSPSs at the end of the day are done by using the settlement server. In one embodiment, the PSPS server hosts a PSPA tool which can be used by registered users to transmit payment requests. The payment requests can be pay/push request or collect/pull request.”; paragraph [0085]: “The UPI (100), at the end of the day when all the financial and non-financial transactions are complete, does the settlement of the all the payment transactions which have taken place between all the PSPSs that are registered with the EPS (1000). In an embodiment, the payer uses a PSPA tool which is different than PSPA tool of the payee. In another embodiment, the payer uses same PSPA tool as that of the payee.”).
Although Asbe discloses The UPI (100) now has bank details of both the payer and the payee based on their VPA's/unique IDs. The UPI (100) uses the bank details to communicate with the remitter bank (110) (i.e., the payer's bank) and debit the desired amount (step 5 and 6) and then communicate with the beneficiary bank (112) (i.e., the payee's bank) to credit that amount to complete the transaction (step 7 and 8) and later settlement (see paragraphs [0084] and [0085]), Asbe does not explicitly disclose a method and system comprising: storing the transaction data for later settlement.
However, Schleicher discloses a method and system (Authorization techniques) comprising: storing the transaction data for later settlement (see Fig. 3, 320, paragraph [0058]: “At 320, the authorization and settlement service attempts to authorize the amount against one or more funding sources associated with a buyer to a merchant-buyer transaction. Funding sources include CC accounts, bank saving accounts, checking accounts, debit card accounts, loyalty accounts, gift certificate positive balances, and positive balance accounts. Information regarding the funding sources is retained by the authorization and settlement service...").
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to incorporate the authorization and settlement service as disclosed by Schleicher in the method and system of Asbe, the motivation being to permit a merchant to lock funds for buyer transactions against funding sources that traditionally do not support fund locking, such as ACH, iACH, and/or checking accounts (see Schleicher, paragraph [0067]).
With respect to the BRI of the claims, Examiner notes that claims 33 and 45 recite “the transaction data comprising an alias of the payer, an alias of the payee”, language directed to non-functional descriptive material. See MPEP 2111.05. In addition, claims 33 and 45 recite “initiating settlement… to cause release of the payment amount from the reservation of funds, deduction of funds from a balance of the payer account and addition of funds to a payee account associated with the payee, wherein the deduction and addition of funds correspond to the payment amount” , a statement of intended use or field use. See MPEP 2114 II. Lastly, claim 33 is a method claim and recites “the payment amount being deducted from the balance of the digital wallet...” language directed to not positively recited method steps.
With respect to claim 34, the combination of Asbe and Schleicher teaches all the subject matter of the method as described above with respect to claim 33. Furthermore, Schleicher discloses a method wherein the digital notification of the digital payment to the payee communication device serves as an instant notification to the payee that the payment amount has been logically transferred from the payer, even though the digital payment has not yet been settled, and wherein upon being instantly notified by the digital notification of the digital payment, the payee communication device provides a goods or performs a service associated with the digital payment, or enables the payee to do so (see paragraph [0059]: “The authorization and settlement service may authorize portions of the amount from one funding source (such as a positive balance account) and authorize the remaining portions of the amount from a different funding source (such as a CC). In addition, the authorization and settlement service may permit an authorization to occur or appear to occur for a merchant even when the primary funding source of the buyer is associated with a funding source that is not capable of being locked or reserved, such as an ACH, iACH, or checking account. In these situations, the authorization and settlement service assumes the risk that a settlement will be successful. It should also be noted that the selection of funding sources can dynamically change during a reauthorization and/or during a settlement. In this manner any available positive funds can be acquired if previous identified funding sources associated with an authorization do not have any funds or lack funds to sufficiently permit a settlement.”; paragraph [0060]: “If an authorization is successful, then, at 330, the authorization and settlement service sends a confirmation to the merchant that the authorization was successful. This confirmation permits the merchant to begin processing the order of the buyer to hopefully eventually consummate the merchant-buyer transaction. If an authorization is not successful, then, at 330, the authorization and settlement service notifies the merchant of such a failure.”). The motivation for combining the references remain unaltered from the motivation described above in conjunction with the rejection of the independent claims.
With respect to claim 35, the combination of Asbe and Schleicher teaches all the subject matter of the method as described above with respect to claim 33. Furthermore, Schleicher discloses a method wherein:
the digital wallet server function initiates settlement of the digital payment by communicating the stored transaction data to a computerized payment switch functionality; the payment switch functionality maintains cross-reference data that links payer aliases and payee aliases of payers and payees to user accounts at financial institutions or payment service providers (see one or more external interfaces to financial or payment services,, paragraph [0064]: “When a settlement is processed, the authorization and settlement service transfers currency or loyalty points from funding sources of a buyer to accounts of the merchant. The merchant sends settlement requests to the authorization and settlement service during valid authorization periods and assuming honor conditions are met, the actual transfer takes place. To achieve this, the authorization and settlement service may include one or more external interfaces to financial or payment services, such as ACH, iACH, CC processing services, etc. In some embodiments, the authorization and settlement service may also have an interface to loyalty services for purposes of crediting and debiting loyalty points from loyalty accounts.”); and
the payment switch functionality uses the communicated transaction data and the cross- reference data to cause settlement of the digital payment (see paragraph [0065]: “In an embodiment, at 350, the authorization and settlement service settles for the initial authorization amount from two or more different funding sources associated with a buyer after the authorization and settlement service receives a settlement request. In another embodiment, at 360, the authorization and settlement service may honor and process multiple settlement requests occurring at different time intervals against the initial authorization. ). Regarding the BRI of the claim, Examiner notes that claim 35 is a method claim and recites “he payment switch functionality maintains cross-reference data that links payer aliases and payee aliases of payers and payees to user accounts at financial institutions or payment service providers; and the payment switch functionality uses the communicated transaction data and the cross- reference data to cause settlement of the digital payment....”; language directed to not positively recited method steps. The motivation for combining the references remain unaltered from the motivation described above in conjunction with the rejection of the independent claims.
With respect to claim 41, the combination of Asbe and Schleicher teaches all the subject matter of the method as described above with respect to claim 33. Furthermore, Schleicher discloses a method further involving the digital wallet server function:
initially determining that the payment amount of the payment request for the digital payment exceeds the balance of the digital wallet for the payer (see paragraph [0039]: “Another novel feature of the network-based authorization and settlement service 103 is that it may provide and authorization and/or settlement from multiple funding sources. In other words, suppose a merchant (M) wants to authorize $100 for a given buyer (B), suppose further that the B has two funding sources a positive balance account of $50 and a CC..."); and
splitting the digital payment into two parts, a first part of the digital payment being performed by the steps recited in claim 33 in a first payment amount which does not exceed the balance of the digital wallet for the payer, and a second part of the digital payment being performed by initiating immediate settlement of the digital payment based on the alias of the payer, the alias of the payee and a representation of a second payment amount to cause deduction of funds from the balance of the payer account and addition of funds to the payee account, wherein the deduction and addition of funds correspond to the second payment amount, and wherein the second payment amount is the difference between the payment amount and the first payment amount (see paragraph [0039]: “...The network-based authorization and settlement service 103 may lock the $50 (since this is within the control of the network-based authorization and settlement service 103) and then lock via traditional CC processing services $50 against the CC. Although the above-provided example used two funding sources, it should be apparent that more than two funding sources may be used for a single authorization. In fact, various combinations of different funding sources may be used to perform authorization with the network-based authorization and settlement service 103.”).
Regarding the BRI of the claim, Examiner notes that claim 41 recites “wherein the deduction and addition of funds correspond to the second payment amount, and wherein the second payment amount is the difference between the payment amount and the first payment amount”, language directed to non-functional descriptive material. See MPEP 2111.05. In addition, claim 41 recites “initiating settlement… to cause deduction of funds from the balance of the payer account and addition of funds to the payee account” , a statement of intended use or field use. See MPEP 2114 II. Lastly, claim 41 is a method claim and recites “a first part of the digital payment being performed by the steps recited in claim 33 in a first payment amount which does not exceed the balance of the digital wallet for the payer, and a second part of the digital payment being performed by initiating immediate settlement of the digital payment based on the alias of the payer, the alias of the payee and a representation of a second payment amount to cause deduction of funds from the balance of the payer account and addition of funds to the payee account...”; language directed to not positively recited method steps. The motivation for combining the references remain unaltered from the motivation described above in conjunction with the rejection of the independent claims.
With respect to claim 42, the combination of Asbe and Schleicher teaches all the subject matter of the method as described above with respect to claim 33. Furthermore, Asbe discloses a method wherein the computerized digital wallet server function takes the form of a complementary or additional layer of computerized core banking resources of the first financial institution (see paragraph [0040]: “The present disclosure addresses interoperability of banking mobile applications and/or bank web-portals for payment transactions. Using the system of the present disclosure, users and/or bank customers are not restricted to use the web-portals and/or mobile-webs of the banks in which they have their account(s). Instead, the users (both payer and payee) and/or customers can choose any bank's web-portal or mobile-web for their payment transactions without knowing bank account details of other user/person. The users (payer or payee) are required to know only a unique ID or virtual payment address (VPA) to make financial/electronic payment transactions.”;). Regarding the BRI of the claim, Examiner notes that claim 42 is a method claim and recites “wherein the computerized digital wallet server function takes the form of a complementary or additional layer of computerized core banking resources of the first financial institution...”; language directed to not positively recited method steps. The motivation for combining the references remain unaltered from the motivation described above in conjunction with the rejection of the independent claims.
With respect to claim 43, the combination of Asbe and Schleicher teaches all the subject matter of the method as described above with respect to claim 33. Furthermore, Asbe discloses a method wherein the computerized digital wallet server function is hosted by the first financial institution (see paragraph [0059]: “In one embodiment, if the user is registered with a ‘xyz’ bank, his VPA has a suffix code ‘@xyz’. Rules for deciding suffix code for VPAs for particular PSPS are decided by the UPI (100) and/or the PSPS, which is stored in the UPI server and/or the PSPS server. So the VPA will have a username selected by the user with a suffix code associated to the PSPS to which the user is registered. Therefore, in case of ‘abc@xyz’, ‘abc’ is a unique name/User name selected by the user and ‘xyz’ is the name of the user's PSPS. Other examples include Unique name@HDFC, Unique name@SBI, Unique name@Corporation, Unique name@PNB, etc. The user's PSPS then stores details of his VPA and other non-financial details created using the PSPA tool in the local storage device of the PSPS. In an embodiment, the user registers to at least one bank with account details like user account name, account number, Aadhaar number, IFSC code, and the like using the PSPA tool, which is necessary for identifying the user's bank account to carry out payment transactions. On successful creation of the VPA, the user can use the VPA while transmitting push or pull payment requests/transactional data through the PSPA tool. Further, the user can also use Account Number along with the IFSC, Aadhaar number, Aadhaar number +IIN and Mobile number, and MMID, or just his mobile number (if and as & when included) for payment by the UPI (100).”;). Regarding the BRI of the claim, Examiner notes that claim 43 is a method claim and recites “wherein the computerized digital wallet server function is hosted by the first financial institution. ...” language directed to not positively recited method steps. The motivation for combining the references remain unaltered from the motivation described above in conjunction with the rejection of the independent claims.
Claim 44 is rejected under 35 U.S.C. 103 as being unpatentable over Asbe (US 2019/0303910 A1), in view of Schleicher (US 2006/0235758 A1), in view of Cole (US 9,378,492 B1)
With respect to claim 44, the combination of Asbe and Schleicher teaches all the subject matter of the method as described above with respect to claim 33. The combination of Asbe and Schleicher does not explicitly teach a method the first financial institution having a computerized core banking system, wherein the method further involves: the computerized core banking system detecting that the digital wallet is in need of a top-up; and in response performing a top-up by reserving an appropriate top-up amount in the payer account and increasing the balance of the digital wallet accordingly.
However, Cole discloses a method (System, method, and computer program for automatically resolving non-sufficient funds (NSF) errors in a network) the first financial institution having a computerized core banking system, wherein the method further involves: the computerized core banking system detecting that the digital wallet is in need of a top-up; and in response performing a top-up by reserving an appropriate top-up amount in the payer account and increasing the balance of the digital wallet accordingly (see col. 2 lines 48-54: “FIG. 3 illustrates a method 300 for automatically resolving non-sufficient funds (NSF) errors in a network, in accordance with one embodiment...."; col. 3 lines 35-45: “...it may be determined that the at least one alternative second account includes a top-up system. In the context of the present description, a top-up system refers to any system capable of topping-up, or refilling a card or account, etc. In this case, in response to determining that the at least one alternative second account includes the top-up system, the top-up system may be automatically invoked to add funds to the first account. Further, the first account may be automatically charged to complete the transaction, in response to the top-up system to adding funds to the first account.”).
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to incorporate the automatically resolving non-sufficient funds (NSF) errors as disclosed by Cole in the method of Asbe and Schleicher, the motivation being to prevent potential revenue losses if the available balance is less than the transaction amount (see Cole, summary).
Response to Arguments/Amendments
Drawing Objections
The drawings submitted on 08/12/2026 do not cure the deficiencies identified in the Office Action dated 05/19/2026. Specifically, multiple text elements in Figures 8-11 do not comply with the requirements established (see MPEP 608.02 , specifically section V (p) (3)). Therefore, the drawing objections are maintained. Examiner notes the “best available versions” submitted by Applicant still do not comply with these requirements.
Claim rejections under 35 U.S.C. § 101
The rejection of claim 49 as being directed to non-statutory subject matter was withdrawn in view of the claim amendments.
Examiner acknowledges Applicant’s arguments with respect to the rejection under 35 U.S.C. § 101 as being directed to a judicial exception (i.e. an abstract idea without significantly more), see remarks dated 08/12/2026, pages 10-13. With respect to step 2A of the analysis, Applicant asserts that “the claims are not directed at the abstract idea of "intermediated settlement"”. Examiner respectfully disagrees. The claims are directed to the steps/functions of maintaining a wallet/balance, making a payment request, registering transaction data, causing a notification, storing transaction data and initiating settlement. Examiner is in the position that the recited functions/steps are directed to settlement of a transaction as intermediated by a third-party, and therefore the claims are directed to the abstract idea of intermediated settlement under step 2A, prong one. With respect to the “two-layer technical architecture/process” recited by Applicant, Examiner reminds Applicants that the analysis is performed on the subject matter of the claims. For instance, Examiner disagrees that aspects of the “financial institutions” are part of the BRI of the claims, as an initial matter, this entity is recited generally as describing where funds are maintained. The BRI of apparatus claim 45, for instance, is directed to a “a computerized digital wallet server function; and a payer communication device usable by a payer”, and the financial institution is merely recited as the description of a balance of a digital wallet (i.e. “the digital wallet having a balance corresponding to a reservation of funds in a payer account maintained at a financial institution”). Therefore, Examiner is unpersuaded by Applicant’s arguments directed to elements not part of the BRI of the claims. Further, when asserting that the current claims are directed to improvement to the “payment system itself”, Applicant asserts that “The claimed invention creates a trusted "digital cash" layer on top of the traditional banking layer” Examiner respectfully disagrees with this interpretation of the BRI of the current claims, as the BRI of the claims do not encompass a “traditional banking layer” in addition to a “digital cash layer”. The claims merely recite a computerized digital wallet server function intermediating settlement of a transaction involving a payment communication device. It also appears Applicants place undue weight to some of the language in the claims, particularly with respect to language directed to the intended use of the “settlement” (i.e. “initiating settlement… to cause release of the payment amount from the reservation of funds, deduction of funds from a balance of the payer account and addition of funds to a payee account associated with the payee, wherein the deduction and addition of funds correspond to the payment amount.”). Specifically, when Applicant asserts in the remarks that “The actual, slower inter-bank settlement is offloaded to a later time.”, this feature is not part of the BRI of the independent claims. The claims merely require a settlement to be “initiated”, and no later “offloading” is required by the claims. Therefore, Examiner disagrees with Applicants arguments directed to technical improvement, as the technical improvements argued by Applicant are not part of the BRI of the examined claims. Examiner notes the BRI of the claim was thoroughly discussed at least in section 12, page 4 of the previous Non-Final Office Action dated 05/19/2026.
With respect to step 2B of the analysis, Applicant asserts that “The inventive concept lies in the unconventional arrangement of components that provides a tangible technical improvement to the functioning of the payment system itself” without specifically addressing which unconventional arrangement Applicant interprets as “significantly more” than the abstract idea. Examiner notes the additional elements were evaluated and Examiner is still in the position that the additional elements amount to no more than mere instructions to apply the exception using generic computer components and/or to generally linking the use of the judicial exception to a particular technological environment or field of use. These additional elements cannot provide an inventive concept beyond the abstract idea of intermediated settlement, both separately and in combination. Lastly, Applicant asserts that “This architecture improves the speed, reliability and load-balancing capabilities of the entire payment system by offloading functions from core banking resources, which is a specific improvement to computer technology in the field of digital payments”. As discussed above, this “architecture” as argued by Applicant is not fully captured by the BRI of the claims and therefore those arguments are not persuasive and the rejections were maintained.
Claim rejections under 35 U.S.C. § 103
Applicant’s arguments and amendments filed on 08/12/2026 are acknowledged. With respect to the combination of references, Applicant asserts: “Applicants respectfully submit that the Office Action's position is based on a factual error. The Office Action asserts that Asbe fails to teach "storing the transaction data for later settlement". As such, this does not seem correct. Asbe explicitly and repeatedly describes a system that stores transaction data for later, batched settlement. Asbe, at [0048], discloses a "settlement module (1OOa)" within its Unified Payment Interface (UPI) that "periodically collate[s] credit and debit transactions" to generate settlement instructions. At [0051], Asbe further describes that "payment settlements among the banks and the PSPSs at the end of the day are done by using the settlement server". Also, at [0085], Asbe explains: "The UPI (100), at the end of the day when all the financial and non-financial transactions are complete, does the settlement of the all the payment transactions...". The Office Action's key argument - that Asbe lacks a feature of "storing the transaction data for later settlement" is therefore incorrect.” Examiner respectfully disagrees. Examiner notes the rejection is clear in disclosing that Asbe does not explicitly disclose the feature of “storing the transaction data for later settlement”. It appears Applicants are in the position that Asbe inherently teaches this feature – see Applicant’s arguments: “This inherently requires storing the data from each transaction until such settlement occurs”. Therefore, Examiner acknowledges Applicants’ arguments as admitted prior art. Examiner notes the claims were evaluated under compact prosecution and “It is never appropriate to rely solely on common knowledge in the art without evidentiary support in the record as the principal evidence upon which a rejection was based. See Zurko, 258 F.3d at 1386, 59 USPQ2d at 1697; Ahlert, 424 F.2d at 1092, 165 USPQ 421.” Therefore, in view of Applicant’s admitted prior art, at least independent claims 33, 45, 46 and 49 could alternatively be rejected under AIA 35 U.S.C. 103 as being unpatentable over Asbe et al. (US 2019/0303910 A1) in view of common knowledge or well-known in the art statement(s) in the previous Applicant’s remarks dated 058/12/2026 as admitted prior art, as, according to Applicants’ own admission, the reference inherently discloses the claimed feature of "storing the transaction data for later settlement", further evidenced by Applicants’ arguments reciting “Since the primary reference, Asbe, already teaches the feature that the Office Action seeks to import from Schleicher, there is no reason for one of ordinary skill in the art to make the proposed combination.” Emphasis added by Examiner. Therefore, Examiner disagrees that the combination of references is improper, as it is clear the reference does not explicitly teaches the feature of “storing” the data. Therefore, for compact prosecution purposes, Examiner maintains the previous rejections.
Applicant further asserts that “the Office Action does not seem to appreciate the key distinction of the claimed invention, namely its specific two-layer architecture which links a reservation of funds at a bank to a corresponding digital wallet balance. This structure is not taught or suggested by Asbe.” Examiner respectfully disagrees. It appears there is a severe disagreement regarding the Broadest interpretation of the claims, as Examiner is unpersuaded that the claim language encompasses such “architecture”. Particularly, it appears Applicant places undue weight to certain language in the claims. Regarding the primary reference “Asbe”, Applicant asserts “While the net settlement between banks is batched, the transaction itself is not executed against a pre-reserved, wallet-specific balance. The claimed invention introduces a distinct "digital cash" layer that is segregated from the main account balance via a reservation, providing a technical advantage in speed, reliability and load-balancing that Asbe does not contemplate in any way”. Examiner reminds Applicants, however, that the independent claims don’t even require a “settlement” to be performed, but rather disclose “initiating” a settlement, followed by the intended goal of this step/ function (see claim language “initiating settlement of the digital payment based on the stored transaction data to cause release of the payment amount from the reservation of funds, deduction of funds from a balance of the payer account and addition of funds to a payee account associated with the payee, wherein the deduction and addition of funds correspond to the payment amount.”) Therefore, Examiner is still in the position that the reference discloses the subject matter of the claims, as it discloses the settlement being initiated. While the intended result of this step/function in Asbe might differ from the intended use of “initiating settlement” in the current Application, Examiner is in the position that it would be improper to grant patentable weight to language that carries none, such as the intended use recitations found in the claims. Therefore, Examiner is unpersuaded by Applicant’s arguments, especially in view of the established Broadest Reasonable interpretation of the claims, which was unaddressed by Applicant. Examiner notes these aspects of the BRI of the claims were thoroughly discussed in the previous Non-Final Office Action dated 05/19/2026.– see, for instance, section 35 in page 22.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
Kumar et al. (US 2021/0097521 A1) disclose electronic device and computerized method for offline payment transfer, including instructions for payment transfer in an offline mode.
Giordano (US 2007/0168282 A1) discloses systems and/or methods for simplifying payment systems, and payment instruments implementing the same, including a debit transaction which may or may not be a real-time settlement, depending on the network.
Levenson et al. (US 2003/0028492 A1) disclose system and method for the payment and accounting of petty disbursements, including maintaining a structure to facilitate the modification of the expenditure limits for the purchasing cards and the movement of cash between a master account and the accounts of each of the purchasing cards.
Rodrigues et al. (US 2018/0232732 A1) disclose offline transaction system and method, including storing a transaction confirmation for later settlement.
Gadewar et al. (US 2022/0180346 A1) disclose cached balance inspection in real-time card transactions, including card issuer-processors responding to authorization requests of merchants and/or card networks when supplier computers are offline and without accessing true card balance data for cards.
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 EDUARDO D CASTILHO whose telephone number is (571)270-1592. The examiner can normally be reached Mon-Fri 8-5.
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, Patrick McAtee can be reached at (571) 272-7575. 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.
/EDUARDO CASTILHO/ Primary Examiner, Art Unit 3698
