Prosecution Insights
Last updated: April 18, 2026
Application No. 18/769,291

TRANSACTION METHOD AND SYSTEM

Final Rejection §101§102§103
Filed
Jul 10, 2024
Examiner
KANAAN, TONY P
Art Unit
3696
Tech Center
3600 — Transportation & Electronic Commerce
Assignee
Ipco 2012 Limited
OA Round
2 (Final)
28%
Grant Probability
At Risk
3-4
OA Rounds
4y 0m
To Grant
56%
With Interview

Examiner Intelligence

Grants only 28% of cases
28%
Career Allow Rate
51 granted / 179 resolved
-23.5% vs TC avg
Strong +28% interview lift
Without
With
+28.0%
Interview Lift
resolved cases with interview
Typical timeline
4y 0m
Avg Prosecution
34 currently pending
Career history
213
Total Applications
across all art units

Statute-Specific Performance

§101
50.5%
+10.5% vs TC avg
§103
29.6%
-10.4% vs TC avg
§102
13.9%
-26.1% vs TC avg
§112
4.8%
-35.2% vs TC avg
Black line = Tech Center average estimate • Based on career data from 179 resolved cases

Office Action

§101 §102 §103
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 Claims This action is in response to remarks received 03/26/2026 for application 18/769,291 which claims earliest priority from EP 23/187,948 filed 07/26/2023. Claims 1, 12 & 14 are independent claims and claims 2-11, 13 & 15-20 are dependent. Claims 1-20 are currently pending and have been examined. Response to Arguments Applicant’s arguments filed 03/26/2026 have been fully considered but are not persuasive. With respect to applicant’s arguments under 35 U.S.C. § 101 have been considered, however, the examiner respectfully disagrees. Under Step 2A, Prong 1, Applicant argues that the claims are not directed to an abstract idea and instead recite a specific technical improvement to computer networking; however, the Examiner respectfully disagrees. The claims are directed to facilitating a transaction between users, including establishing communication, sending transaction data, validating the data and confirming the transaction. Such activities constitute certain methods of organizing human activity, including commercial interactions and agreements between parties, as well as mental processes that can be performed conceptually or with pen and paper. The additional recitation of devices (e.g., user devices, communication channels, transaction systems) does not alter the focus of the claims, but instead represents the use of generic computer components to perform the abstract idea. Under Step 2A, Prong 2, Applicant contends that the claims provide a technical solution involving a peer-to-peer communication channel and improved resilience; however, the Examiner respectfully disagrees. the claimed steps of establishing a communication channel, sending and receiving messages, validating transaction data, and sending a confirmation; are generic data transmission and processing steps that do not impose a meaningful limit on the abstract idea. The alleged “peer-to-peer” nature of the communication is not recited with sufficient technical detail to constitute a specific improvement in computer functionality, but instead represents a generic networking environment in which the abstract idea is carried out. Further, the claims do not recite any specific networking protocol, improvement to data transmission techniques, or technical mechanism for overcoming network failures; but instead rely on functional results. Accordingly, the claims merely use a computer as a tool to perform an abstract idea and do not integrate the exception into a practical application. Under Step 2B, Applicant argues that the ordered combination of steps amounts to significantly more than the abstract idea; however, the Examiner respectfully disagrees. The additional elements, considered individually and as an ordered combination, amount to well-understood, routine and conventional activities including transmitting data between devices, receiving and validating data and sending confirmation messages; which are basic computer functions that are routinely performed in conventional transaction systems. The claimed sequence of steps reflects a conventional flow of transaction processing, and does not amount to an inventive concept. Further, the claims do not recite any unconventional hardware, software, or algorithm that would transform the nature of the claim into patent-eligible subject matter. With respect to the dependent claims, the additional limitations directed to, for example, use of a distributed ledger (claim 2), preauthorization limits and banking entity interactions (claims 3-5), cryptocurrency wallets (claim 6), specific communication channels (claim 7), cryptographic signing and encryption (claims 8-9), third-party authorization (claim 10), and connectivity data exchange (claim 11), merely recite additional features that are well-understood, routine, and conventional features that are well-understood, routine, and conventional in the field and/or further limit the abstract idea to particular environments or implementations without integrating the exception into a practical application or amounting to significantly more. For the above reasoning, the claims remain directed to an abstract idea, do not integrate the abstract idea into a practical application and do not include additional elements that amount to significantly more. Accordingly, the rejection of claims under 35 U.S.C. § 101 is maintained. With respect to applicant’s arguments under 35 U.S.C. § 102 have been considered, however, the examiner respectfully disagrees. Applicant contends that Nichani fails to disclose (i) validation occurring locally at the second user device and (ii) a peer-to-peer confirmation message sent form the second user device to the first user device to submission to a transaction system; however, Nichani discloses a transaction system in which transaction data is exchanged between devices and validated as part of the transaction process (e.g. Nichani ¶¶ [176 & 199-205]). The Examiner notes that the claims do not require any particular implementation of “local” validation beyond receiving and validation transaction data at a device. Nichani’s disclosure of performing validation based on transaction data received from user or merchant devices reasonably teaches or suggests the claimed “validation transaction data within the received transaction message”. Regarding the “confirmation transaction message”, Nichani discloses transmitting transaction results and confirmations between system components and user/merchant devices (see, e.g., Nichani ¶¶ [206-208]). The Examiner finds that such disclosures teach or reasonably suggest sending confirmation information between participating devices, as claimed. The claims do not preclude the involvement of intermediary components, nor do they require a purely direct communication path excluding backend systems. Furthermore, Nichani explicitly discloses transmitting the confirmation message to user devices (e.g., merchant device 106 and/or user device 104; see Nichani ¶ [208]), thereby teaching delivery of confirmation information to participating devices as broadly recited in the claims. Applicant’s argument that Nichani requires the confirmation to originate only from a backend system is not commensurate with the scope of the claims, which broadly recite sending a confirmation message without restricting how the system architecture implements that transmission. Accordingly, Nichani teaches or at least inherently discloses the claimed limitations, and the rejections under 35 U.S.C. § 102 is maintained. With respect to applicant’s arguments under 35 U.S.C. § 103 have been considered, however, the examiner respectfully disagrees. Applicant argues that neither Higgins nor Mayblum cures the alleged deficiencies of Nichani regarding peer-to-peer validation and confirmation messaging. However, as discussed above, the Examiner maintains Nichani teaches the core transaction processing limitations. Higgins is relied upon for publishing transaction data to a distributed ledger in response to transaction conditions, as recited in claim 2. Mayblum is relied upon for teaching preauthorization limits and transaction controls associated with financial accounts, as recited in claims 3-6 and 16-17. The combination of Nichani with Higgins and/or Mayblum merely applies known techniques (distributed ledger recording and preauthorization controls) to the transaction framework of Nichani to improve reliability, security, and financial control; which is an application that would have been obvious to one of ordinary skill in the art. Applicant’s arguments attack the references individually rather than the combination. When properly combined, the references collectively teach all claimed limitations. Accordingly, the rejection of claim 2 under 35 U.S.C. § 103 over Nichani in view of Higgins is maintained. Accordingly, the rejection of claim 3-6 & 16-17 under 35 U.S.C. § 103 over Nichani in view of Mayblum is maintained. Claim Rejections – 35 USC § 101 35 U.S.C. 101 reads as follows: Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title. Claims 1-20 are rejected under 35 USC 101 because the claimed invention is directed to an abstract idea without significantly more. The claims do fall within at least one of the four categories of patent eligible subject matter because claims 1 & 12 are directed to a method and claim 14 is directed to apparatus; Step 1-yes. Under Step 2A, prong 1, representative claim 1 recites a series of steps for initiating a transaction, i.e. sales activities or behaviors, and thus grouped as “Certain Methods of Organizing Human Activity”; and also can concepts performed in the human mind and thus grouped as “Mental processes”. The claim as a whole and the limitations in combination recite this abstract idea. Specifically, the limitations of representative claim 1, stripped of all additional elements, recite the abstract idea as follows: a method of processing a transaction between a first user and a second user within a transaction system, the method comprising: establishing a communication channel between the first and second user; sending over the communication channel, a transaction message to initiate the transaction between the first and second users, the transaction message comprising transaction data; receiving the transaction message; validating the transaction data within the received transaction message; sending over the communication channel, a confirmation transaction message, the confirmation transaction message confirming that the transaction has been approved by the first user and second user; sending the confirmation transaction message to the transaction system. These steps relate to commercial or legal interaction and grouped under certain methods of organizing human activity abstract ideas, see MPEP 2106.04(a)(2), subsection II i.e. business relation; and concepts performed in the human mind under mental process grouping of abstract idea, see MPEP § 2106.04(a)(2), subsection III.) The claimed limitations, identified above, recite a process that, under its broadest reasonable interpretation, covers performance of a commercial or legal interaction and mental processes, but for the recitation of generic computer components. There is nothing in the claim element which takes the steps out of the methods of organizing human activity abstract idea grouping. Claims 12 and 14 recite analogous limitations and interpreted under the same premise. Under step 2A, Prong 2, this judicial exception is not integrated into a practical application. In particular, the claim only recites using generic, commercially available, off-the-shelf computing devices, i.e. processors suitably programmed communicating over a generic network, to perform the steps of establishing, sending, receiving and validating data. The additional elements (i.e. a first user device and a second user device) are recited at a high-level of generality (i.e. as generic processors with memory suitably programmed communication information over a generic network, see at least Fig.’s 1-3 and page 9 paragraphs 2-3 of the specifications) such that it amounts no more than 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 computer as a tool to perform the abstract idea, see MPEP 2106.05(f) and generally linking the use of the judicial exception to a particular technological environment or field of use, see PEPE 2106.05(h). Furthermore, the steps for receiving and sending data are considered adding insignificant extra-solution activity to the judicial exception, see MPEP 2106.05(g). Accordingly, the additional elements claimed do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea. Claims 1, 12 and 14 are directed to an abstract idea. Under step 2B, the claim does not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to integration of the abstract idea into a practical application, the additional elements of using generic computer processors with memory suitably programmed communicating over a generic network to perform the limitation steps amounts no more than 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 the abstract idea, see MPEP 2106.05(f) and generally linking the use of the judicial exception to a particular technological environment or field of use, see MPEP 2106.05 (h). Furthermore, the step for receiving and sending data are considered adding insignificant extra-solution activity to the judicial exception, see MPEP 2106.05(g). Mere instructions to apply an exception using generic computer components interacting in a conventional manner cannot provide an inventive concept. Claims 1, 12 and 14 are not patent eligible. Applicant has leveraged generic computing elements to perform the abstract idea of without significantly more. The dependent claims when analyzed as a whole an in an ordered combination are held to be patent ineligible under 35 USC 101 because the additional recited limitations fail to establish that the claims are not directed to an abstract idea. The additional recited limitations in the dependent claims only refine the abstract idea. Further refinement of an abstract idea does not convert an abstract idea into something concrete. The claims merely amount to the application or instructions to apply the abstract idea (i.e. a series of steps for initiating a transaction) on one or more computers, and are considered to amount to nothing more than requiring a generic computer system (e.g. processors suitably programmed and communicating over a network) to merely carry out the abstract idea itself. As such, the claims, when considered as a whole, are nothing more than the instruction to implement the abstract idea (i.e. a series of steps for initiating a transaction) in a particular, albeit well-understood, routine and conventional technological environment. Accordingly, the Examiner concludes that there are no meaningful limitations in the claims that transform the judicial exception into a patent eligible application such that the claims amount to significantly more than the judicial exception itself or integrate the judicial exception into a practical application. Claim Rejections - 35 USC § 102 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 the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action: A person shall be entitled to a patent unless – (a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention. (a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention. Claims 1, 7-15 & 18-20 are rejected under 35 U.S.C. 102 (a)(1) & (a)(2) as being anticipated by Roshankumar Vishin Nichani et al. (US 2022/0044234 A1, herein Nichani). As per claim 1, Nichani teaches a method of processing a transaction between a first user, associated with a first user device, and a second user, associated with a second user device, within a transaction system, the method comprising: establishing a communication channel between the first and second user devices (Nichani ¶¶ [105 & 129-131]); sending, from the first user device to the second user device over the communication channel, a transaction message to initiate the transaction between the first and second users, the transaction message comprising transaction data (Nichani ¶¶ [105, 133-136 & 161]); receiving the transaction message at the second user device (Nichani ¶¶ [89, 118, 128 & 134-136]); validating the transaction data within the received transaction message (Nichani ¶¶ [199, 201 & 203-205]); sending, from the second user device to the first user device over the communication channel, a confirmation transaction message, the confirmation transaction message confirming that the transaction has been approved by the first user and second user (Nichani ¶ [208]); sending the confirmation transaction message to the transaction system (Nichani ¶ [174] and Fig. 7 at step 718). As per claim 7, Nichani teaches a method as claimed in Claim 1, Nichani further teaches: wherein the communication channel comprises one of: a point-to-point WiFi channel between the first and second user devices; a point-to-point Bluetooth® channel between the first and second user devices; a communication channel between the first and second user devices using near-field communications protocols; the display of visual data on a display screen of one of the first and second user devices and subsequent capture using a camera device on the other user device of the visual data; an audio communication channel (Nichani ¶¶ [94, 101, 105, 118 & 124-125]). As per claim 8, Nichani teaches a method as claimed in Claim 1, Nichani further teaches: wherein the transaction message is signed using a private key associated with the first user device and encrypted using a public key associated with the first user device, a public key associated with the second user device, a public key associated with a first user banking entity and a public key associated with a second user banking entity (Nichani ¶¶ [30, 124-125, 141, 150, 155, 157 & 170]). As per claim 9, Nichani teaches a method as claimed in Claim 8, Nichani further teaches: wherein the confirmation transaction message is signed using a private key associated with the second user device and encrypted using the public key associated with the first user device, the public key associated with the second user device, the public key associated with a first user banking entity and the public key associated with a second user banking entity (Nichani ¶¶ [141, 150 & 169-170]). As per claim 10, Nichani teaches a method as claimed in Claim 1, Nichani further teaches: comprising, subsequent to setting up the communication channel, the first and second user devices checking with a third party authorization system that the other party is authorized to process a transaction (Nichani ¶¶ [187-188 & 207-208]). As per claim 11, Nichani teaches a method as claimed in Claim 1, Nichani further teaches: wherein the first and second user devices exchange user device connectivity data during establishment of the communication channel and wherein, in the event user device connectivity data does not meet predefined connectivity requirements, communicating with the transaction system to update the user device connectivity data (Nichani ¶¶ [105 & 144-147]). As per claim 12, Nichani teaches a method of processing a transaction between a first user, associated with a first user device, and a second user, associated with a second user device, within a transaction system, the method comprising; establishing a communication channel between the first and second user devices (Nichani ¶¶ [105 & 129-131]); sending, from the first device to the second device over the communication channel, a transaction message to initiate the transaction between the first and second users, the transaction message comprising transaction data wherein the transaction message is received at the second user device and the transaction data within the transaction message is received by the second user device (Nichani ¶¶ [105, 133-136 & 161]); receiving, at the first device over the communication channel, a confirmation transaction message from the second device, the confirmation transaction message confirming that the transaction has been approved by the first user and second user (Nichani ¶¶ [89, 118, 128, 134-136 & 208]); sending the confirmation transaction message to the transaction system (Nichani ¶ [174] and Fig. 7 at step 718]). As per claim 13, Nichani teaches a method as claimed in Claim 12, Nichani further teaches: comprising; establishing the communication channel between the first and second user devices (Nichani ¶¶ [105 & 129-131]); receiving at the second user device over the communication channel the transaction message from the first user device, the transaction message comprising transaction data to enable the transaction between the first and second users to be initiated (Nichani ¶¶ [105, 133-136 & 161]); validating the transaction data within the received transaction message (Nichani ¶¶ [199, 201 & 203-205]); sending, from the second user device to the first user device over the communication channel, the confirmation transaction message, the confirmation transaction message confirming that the transaction has been approved by the first user and second user (Nichani ¶ [208]); sending the confirmation transaction message to the transaction system (Nichani ¶ [174] and Fig. 7 at step 718). As per claim 14, Nichani teaches a first user device configured to process a transaction with a second user device, the first user device being associated with a first user and the second user device being associated with a second user, the first user device comprising; a communication module configured to connect to and send and receive data from a corresponding communication module on the second user device (Nichani ¶¶ [105, 129, 131, 133-136 & 161]); a processor arranged to: establish a communication channel via the communication module with the second user device (Nichani ¶¶ [105 & 129-131]); generate a transaction message comprising transaction data to enable the transaction between the first and second users to be initiated (Nichani ¶¶ [105 & 129-131]); send the transaction message via the communication module to the second user device (Nichani ¶¶ [105, 133-136 & 161]); receive a confirmation transaction message from the second user device via the communication module, the confirmation module confirming that the transaction has been approved by the second user (Nichani ¶¶ [89, 118, 128, 134-136 & 203-205]); send, via a network communication module, the confirmation transaction message to a transaction system (Nichani ¶¶ [174 & 208]). As per claim 15, Nichani teaches the first user device as claimed in Claim 14, Nichani further teaches: in combination with the second user device configured to process the transaction with the first user device, the second user device comprising: the corresponding communication module configured to connect to and send and receive data from the communication module on the second first user device (Nichani ¶¶ [89, 105, 118, 128, 133-136 & 161]); a corresponding processor arranged to: establish the communication channel via the corresponding communication module with the first user device (Nichani ¶¶ [105 & 129-131]); receive the transaction message via the corresponding communication module from the first user device, the first user device comprising the transaction data to enable the transaction between the first and second users to be initiated (Nichani ¶¶ [105, 133-136 & 161]); validate the transaction data within the received transaction message (Nichani ¶¶ [199, 201 & 203-205]); generate the confirmation transaction message, the confirmation transaction message confirming that the transaction has been approved (Nichani ¶ [208]); send, from the second user device to the first user device over the communication channel, the confirmation transaction message (Nichani ¶¶ [141, 150 & 208]); send, via a corresponding network communication module, the confirmation transaction message to the transaction system (Nichani ¶¶ [169-170 & 208]). As per claim 18, Nichani teaches a method as claimed in Claim 6, Nichani further teaches: wherein the communication channel comprises one of: a point-to-point WiFi channel between the first and second user devices; a point-to-point Bluetooth® channel between the first and second user devices; a communication channel between the first and second user devices using near- field communications protocols; the display of visual data on a display screen of one of the first and second user devices and subsequent capture using a camera device on the other user device of the visual data; an audio communication channel (Nichani ¶¶ [094, 101, 105, 118 & 124-125]). As per claim 19, Nichani teaches a method as claimed in Claim 7, Nichani further teaches: wherein the transaction message is signed using a private key associated with the first user device and encrypted using a public key associated with the first user device, a public key associated with the second user device, a public key associated with a first user banking entity and a public key associated with a second user banking entity (Nichani ¶¶ [30, 124-125, 141, 150, 155, 157 & 170]). As per claim 20, Nichani teaches a method as claimed in Claim 10, Nichani further teaches: wherein the first and second user devices exchange user device connectivity data during establishment of the communication channel and wherein, in the event user device connectivity data does not meet predefined connectivity requirements, communicating with the transaction system to update the user device connectivity data (Nichani ¶¶ [105 & 144-147]). 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. The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows: 1. Determining the scope and contents of the prior art. 2. Ascertaining the differences between the prior art and the claims at issue. 3. Resolving the level of ordinary skill in the pertinent art. 4. Considering objective evidence present in the application indicating obviousness or nonobviousness. This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention. Claim 2 is rejected under 35 U.S.C. 103 as being unpatentable over Nichani in view of Stephen Higgins (US 2022/0318794 A1, herein Higgins). As per claim 2, Nichani teaches a method as claimed in Claim 1 wherein, it can be argued Nichani does not explicitly teach, however, Higgins further teaches: in the event of a processing failure, waiting a predefined period and then publishing the confirmation transaction message to a distributed ledger (Higgins ¶¶ [30-33 & 44]). It would have been obvious to one of ordinary skill in the art to combine with system, method, and computer program product for exchanging transaction data of Nichani with the method and system for secure and verifiable offline blockchain transaction of Higgins in order to update the asset state of the transaction for new blockchain transactions, see Higgins ¶¶ [30-33 & 44]. Claims 3-6 & 16-17 are rejected under 35 U.S.C. 103 as being unpatentable over Nichani in view of Jonathan Mayblum et al. (US 2022/0122062 A1, herein Mayblum). As per claim 3, Nichani teaches a method as claimed in Claim 1, it can be argued Nichani does not explicitly teach, however, Mayblum further teaches wherein either the first user or the second user is a debtor in the transaction and the debtor is associated with a debtor banking entity and wherein the debtor banking entity has preauthorized transactions up to a preauthorization limit, the transaction system being configured to automatically reconcile the transaction on receipt of the confirmation transaction message (Mayblum ¶¶ [258, 275, 344-346 & 365]). It would have been obvious to one of ordinary skill in the art to combine with system, method, and computer program product for exchanging transaction data of Nichani with the systems and methods for facilitating transactions using a digital currency of Mayblum in order to determine appropriate timing for completing transactions, limiting spending on specific products and/or vendors, and limit the credit amount (e.g., credit limit), for example, the customer may only be able to borrow a set amount of digital currency or fiat which may be an available credit of the digital wallet and exceeding this limit may result in a fee; see Mayblum ¶¶ [258, 346 & 365]. As per claim 4, Nichani teaches a method as claimed in Claim 3, it can be argued Nichani does not explicitly teach, however, Mayblum further teaches wherein the user device of the debtor comprises a banking application that is configured to store the preauthorization limit and the method comprises subtracting transaction amounts from the preauthorization limit to determine an available transaction amount and limiting future transactions to the available transaction amount (Mayblum ¶¶ [198, 288-289 & 413-414]). The motivation to combine the references is the same as seen above in claim 3. As per claim 5, Nichani teaches a method as claimed in Claim 1, it can be argued Nichani does not explicitly teach, however, Mayblum further teaches wherein either the first user or the second user is a debtor in the transaction and the debtor is associated with a debtor banking entity, and (Mayblum ¶¶ [145, 147, 150-151, 163 & 165]); wherein the debtor banking entity has preauthorized transactions up to a preauthorization limit, and (Mayblum ¶¶ [198, 252, 289, 294 & 344]); wherein, in the event the transaction exceeds the preauthorization limit, prior to sending the transaction message from the first user device to the second user device, the method comprises contacting the debtor banking entity for authorization to proceed with the transaction (Mayblum ¶¶ [212, 275, 282 & 365]). The motivation to combine the references is the same as seen above in claim 3. As per claim 6, Nichani teaches a method as claimed in Claim 1, it can be argued Nichani does not explicitly teach, however, Mayblum further teaches wherein the first user device and the second user device comprises a secure environment configured to store a cryptocurrency wallet and the transaction comprises transferring cryptocurrency assets between the first and second user devices (Mayblum ¶¶ [382-385]). The motivation to combine the references is the same as seen above in claim 3. As per claim 16, Nichani teaches a method as claimed in Claim 2, it can be argued Nichani does not explicitly teach, however, Mayblum further teaches wherein either the first user or the second user is a debtor in the transaction and the debtor is associated with a debtor banking entity and wherein the debtor banking entity has preauthorized transactions up to a preauthorization limit, the transaction system being configured to automatically reconcile the transaction on receipt of the confirmation transaction message (Mayblum ¶¶ [344-345 & 365]). The motivation to combine the references is the same as seen above in claim 3. As per claim 17, Nichani teaches a method as claimed in Claim 16, it can be argued Nichani does not explicitly teach, however, Mayblum further teaches wherein either the first user or the second user is a debtor in the transaction and the debtor is associated with a debtor banking entity, and (Mayblum ¶¶ [145, 147, 150-151, 163 & 165]); wherein the debtor banking entity has preauthorized transactions up to a preauthorization limit, and (Mayblum ¶¶ [198, 252, 289, 294 & 344]); wherein, in the event the transaction exceeds the preauthorization limit, prior to sending the transaction message from the first user device to the second user device, the method comprises contacting the debtor banking entity for authorization to proceed with the transaction (Mayblum ¶¶ [212, 275, 282 & 365]). The motivation to combine the references is the same as seen above in claim 3. Conclusion 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 TONY P KANAAN whose telephone number is (571)272-2481. The examiner can normally be reached Monday- Friday 7:30am - 3:30 pm EST. Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice. If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Matthew Gart can be reached at 5712723955. 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. /T.P.K./Examiner, Art Unit 3696 /MATTHEW S GART/Supervisory Patent Examiner, Art Unit 3696
Read full office action

Prosecution Timeline

Jul 10, 2024
Application Filed
Dec 31, 2025
Non-Final Rejection — §101, §102, §103
Mar 26, 2026
Response Filed
Apr 04, 2026
Final Rejection — §101, §102, §103 (current)

Precedent Cases

Applications granted by this same examiner with similar technology

Patent 12591871
UNIVERSAL PAYMENT INTENT
2y 5m to grant Granted Mar 31, 2026
Patent 12548010
Voice Controlled Systems and Methods for Onboarding Users and Exchanging Data
2y 5m to grant Granted Feb 10, 2026
Patent 12536593
RISK QUANTIFICATION FOR INSURANCE PROCESS MANAGEMENT EMPLOYING AN ADVANCED INSURANCE MANAGEMENT AND DECISION PLATFORM
2y 5m to grant Granted Jan 27, 2026
Patent 12475459
AUTHORIZATION FLOW MANAGEMENT SYSTEM
2y 5m to grant Granted Nov 18, 2025
Patent 12423748
PAYMENT PROCESSING METHOD AND APPARATUS WITH ADVANCED FUNDS
2y 5m to grant Granted Sep 23, 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
28%
Grant Probability
56%
With Interview (+28.0%)
4y 0m
Median Time to Grant
Moderate
PTA Risk
Based on 179 resolved cases by this examiner. Grant probability derived from career allow rate.

Sign in with your work email

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

Personal email addresses (Gmail, Yahoo, etc.) are not accepted.

Free tier: 3 strategy analyses per month