Prosecution Insights
Last updated: July 17, 2026
Application No. 18/894,974

SYSTEMS AND TECHNIQUES FOR ANONYMOUS DATA TRANSFERS

Non-Final OA §102§103
Filed
Sep 24, 2024
Priority
Jun 05, 2024 — provisional 63/656,521
Examiner
OLAEGBE, MUDASIRU K
Art Unit
2431
Tech Center
2400 — Computer Networks
Assignee
Apple Inc.
OA Round
1 (Non-Final)
74%
Grant Probability
Favorable
1-2
OA Rounds
1y 4m
Est. Remaining
91%
With Interview

Examiner Intelligence

Grants 74% — above average
74%
Career Allowance Rate
63 granted / 85 resolved
+16.1% vs TC avg
Strong +17% interview lift
Without
With
+17.2%
Interview Lift
resolved cases with interview
Typical timeline
3y 2m
Avg Prosecution
27 currently pending
Career history
116
Total Applications
across all art units

Statute-Specific Performance

§101
1.2%
-38.8% vs TC avg
§103
93.6%
+53.6% vs TC avg
§102
3.5%
-36.5% vs TC avg
§112
0.9%
-39.1% vs TC avg
Black line = Tech Center average estimate • Based on career data from 85 resolved cases

Office Action

§102 §103
CTNF 18/894,974 CTNF 96700 Notice of Pre-AIA or AIA Status 07-03-aia AIA 15-10-aia The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA. This communication is in response to the application filed on 09/24/2024. Claims 1-20 are currently pending in the application. Information Disclosure Statement The information disclosure statements (IDSs) submitted on 08/19/2025 and 02/24/2026 are in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner. Claim Rejections - 35 USC § 102 07-07-aia AIA 07-07 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 – 07-08-aia AIA (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. 07-15 AIA Claim s 1-2, 5-6, 8-10, 12, 14-16, 18, and 20 are rejected under 35 U.S.C. 102( a)(1 ) as being anticipated by US. PGPub. No. 20230060707 to DUNJIC et al. (hereinafter DUNJIC) . Regarding claim 1, DUNJIC discloses a method of performing an anonymous data transfer (¶0044-¶0045, “ The notification may allow the transfer to be made without requiring input of one or more parameters that are typically required when a transfer is initiated by the sender rather than the recipient …” ), comprising: transmitting, by an application executed on a user device (¶0081, “ The application software 310 adapts the remote device 102 , in combination with the operating system 300 , to operate as a device for facilitating data transfers and data transfer proposals. ”), a transfer request associated with a desired data transfer to a first computing system (¶0057, “ the first system 104 is in communication with the second system 106 via the network 110 . The first system 104 may be configured to transmit to the second system 106 a message and a data transfer proposal. The second system 106 may be further configured to receive a message and a data transfer proposal from the first system 104 .”), (¶0148, “ The remote device transmits to the recipient system a request for payment instruction with respect to the request for payment …”), the transfer request comprising a sender identifier (ID) (¶0037, “…The request to transfer includes one or more identifiers that identify the record associated with the sender and/or the record associated with the recipient …”); receiving, by the application executed on the user device, a transfer approval from the first computing system (¶0042, “… Authorization may, for example, require authenticated approval using a credential such as one or more of a username, password, biometric authentication data or other credential .”), the transfer approval indicating that the desired data transfer is approved (¶0030, “… receive, from a second computing system, a transfer message for a transfer between the first account associated with the first computing system and a second account associated with the second computing system, the transfer message including routing data, an amount of resources to be transferred, and a condition associated with the transfer; evaluate the condition associated with the data transfer based on a comparison between data included in the transfer message and one or more parameters associated with the first account; and when the condition is determined to be satisfied, complete the transfer. ”), see also ¶0139-¶0140, and ¶0142; receiving, by the application executed on the user device, an acceptance packet from a recipient device, the acceptance packet indicating that the desired data transfer is accepted and comprising a recipient ID (¶0138-¶0139, “ the deposit or acceptance condition feature 816 may be used to indicate an acceptance condition whereby the first operand is “recipient name”, the operand is “matches”, and the second operand is “John Doe”, which may be evaluated by a second system to confirm that “John Doe” is the account holder of the account specified in the routing data …”), (¶0142, “ When the payment instruction is received by the transferor system, the transferor system may transmit a payment message including the payment details to the recipient system. The recipient system may then process the payment message according to the method 700 of FIG. 7 . If the condition is satisfied, the indicated amount may be transferred from the transferor’s account to the account specified in the routing data.” ), (¶0145, “ When the transferor system receives the payment instruction from the remote device, the transferor system may use the recipient alias to lookup routing data associated with the recipient and send the payment message to the recipient system…” ), see also ¶0145 ; transmitting, by the application executed on the user device, at least a portion of the acceptance packet to the first computing system (¶0139, “ The remote device transmits to the transferor system a payment instruction with respect to the payment. The instruction is received by the transferor system via the money transfer interface 800 , through the selection of a confirmation element 824 . The payment message may include the selection and configuration details of one or more options or features, including the transferor’s account, transfer amount, routing data, and acceptance condition. ” ), (¶0062-¶0063, “… The remote device 102 may be used, for example, to receive user input that includes an indication of a data acceptance condition in a data transfer proposal. The user input may further include an indication of routing data, intended transferor, recipient, an account associated with the intended transferor, an account associated with the recipient, and other information to be included in or used to construct the data transfer proposal.” ), (¶0131-¶0133, “… The first operand element 818 provides user selectable options to receive data indicating a first operand. As illustrated, the first operand element 818 offers selection of a first operand from a list of operands. The first operand may be, include or indicate a variable, data type, or placeholder. The placeholder may be a placeholder for a property of the recipient or recipient account. The list of operands may include, for example, a “recipient age”, “recipient name”, “recipient address”, “account age”, “account type” and “account value” operand” ); and receiving, by the application executed on the user device, a transfer confirmation confirming that the desired data transfer is based at least in part on the acceptance packet and/or the transfer approval (¶0148-¶0149, “ The remote device transmits to the recipient system a request for payment instruction with respect to the request for payment. The instruction is received by the recipient system via the request for payment interface 1000 , through the selection of a confirmation element 824 . The request for payment message may include the selection and configuration details of one or more options or features, including the transferee’s account, transfer amount, routing data, and acceptance condition…When the request for payment instruction is received by the recipient system, the recipient system may transmit a request for payment message including the request for payment details to the transferor system. The transferor system may then process the request for payment message according to the method 700 of FIG. 7 . If the condition is satisfied, the indicated amount may be transferred from the transferor’s account to the recipient’s account… ”). Regarding claim 8, DUNJIC discloses a system of performing an anonymous data transfer (¶0044-¶0045, “ The notification may allow the transfer to be made without requiring input of one or more parameters that are typically required when a transfer is initiated by the sender rather than the recipient …” ), the system comprising: one or more processors (¶0031, “… cause the one or more processors to carry out at least some of the operations of a method described herein ”); and a computer-readable medium comprising instructions that, when executed by the one or more processors, cause the one or more processors to perform operations to (¶0031, “ the present application discloses a non-transitory, computer-readable medium storing processor-executable instructions that, when executed by one or more processors, are to cause the one or more processors to carry out at least some of the operations of a method described herein. ”): transmit, by an application executed on a user device (¶0081, “ The application software 310 adapts the remote device 102 , in combination with the operating system 300 , to operate as a device for facilitating data transfers and data transfer proposals. ”), a transfer request associated with a desired data transfer to a first computing system (¶0057, “ the first system 104 is in communication with the second system 106 via the network 110 . The first system 104 may be configured to transmit to the second system 106 a message and a data transfer proposal. The second system 106 may be further configured to receive a message and a data transfer proposal from the first system 104 .”), (¶0148, “ The remote device transmits to the recipient system a request for payment instruction with respect to the request for payment …”), the transfer request comprising a sender identifier (ID) (¶ 0037, “…The request to transfer includes one or more identifiers that identify the record associated with the sender and/or the record associated with the recipient …”); receive, by the application executed on the user device, a transfer approval from the first computing system (¶0042, “… Authorization may, for example, require authenticated approval using a credential such as one or more of a username, password, biometric authentication data or other credential .”), the transfer approval indicating that the desired data transfer is approved (¶0030, “… receive, from a second computing system, a transfer message for a transfer between the first account associated with the first computing system and a second account associated with the second computing system, the transfer message including routing data, an amount of resources to be transferred, and a condition associated with the transfer; evaluate the condition associated with the data transfer based on a comparison between data included in the transfer message and one or more parameters associated with the first account; and when the condition is determined to be satisfied, complete the transfer. ”), see also ¶0139-¶0140, and ¶0142; receive, by the application executed on the user device, an acceptance packet from a recipient device, the acceptance packet indicating that the desired data transfer is accepted and comprising a recipient ID (¶0138-¶0139, “ the deposit or acceptance condition feature 816 may be used to indicate an acceptance condition whereby the first operand is “recipient name”, the operand is “matches”, and the second operand is “John Doe”, which may be evaluated by a second system to confirm that “John Doe” is the account holder of the account specified in the routing data …”), (¶0142, “ When the payment instruction is received by the transferor system, the transferor system may transmit a payment message including the payment details to the recipient system. The recipient system may then process the payment message according to the method 700 of FIG. 7 . If the condition is satisfied, the indicated amount may be transferred from the transferor’s account to the account specified in the routing data.” ), (¶0145, “ When the transferor system receives the payment instruction from the remote device, the transferor system may use the recipient alias to lookup routing data associated with the recipient and send the payment message to the recipient system…” ), see also ¶0145 ; transmit, by the application executed on the user device, at least a portion of the acceptance packet to the first computing system (¶0139, “ The remote device transmits to the transferor system a payment instruction with respect to the payment. The instruction is received by the transferor system via the money transfer interface 800 , through the selection of a confirmation element 824 . The payment message may include the selection and configuration details of one or more options or features, including the transferor’s account, transfer amount, routing data, and acceptance condition. ” ), (¶0062-¶0063, “… The remote device 102 may be used, for example, to receive user input that includes an indication of a data acceptance condition in a data transfer proposal. The user input may further include an indication of routing data, intended transferor, recipient, an account associated with the intended transferor, an account associated with the recipient, and other information to be included in or used to construct the data transfer proposal.” ), (¶0131-¶0133, “… The first operand element 818 provides user selectable options to receive data indicating a first operand. As illustrated, the first operand element 818 offers selection of a first operand from a list of operands. The first operand may be, include or indicate a variable, data type, or placeholder. The placeholder may be a placeholder for a property of the recipient or recipient account. The list of operands may include, for example, a “recipient age”, “recipient name”, “recipient address”, “account age”, “account type” and “account value” operand” ); and receive, by the application executed on the user device, a transfer confirmation confirming that the desired data transfer is based at least in part on the acceptance packet and/or the transfer approval (¶0148-¶0149, “ The remote device transmits to the recipient system a request for payment instruction with respect to the request for payment. The instruction is received by the recipient system via the request for payment interface 1000 , through the selection of a confirmation element 824 . The request for payment message may include the selection and configuration details of one or more options or features, including the transferee’s account, transfer amount, routing data, and acceptance condition…When the request for payment instruction is received by the recipient system, the recipient system may transmit a request for payment message including the request for payment details to the transferor system. The transferor system may then process the request for payment message according to the method 700 of FIG. 7 . If the condition is satisfied, the indicated amount may be transferred from the transferor’s account to the recipient’s account… ”). Regarding claim 15, DUNJIC discloses a non-transitory computer-readable medium comprising instructions that, when executed by one or more processors to perform operations comprising (¶0031, “ the present application discloses a non-transitory, computer-readable medium storing processor-executable instructions that, when executed by one or more processors, are to cause the one or more processors to carry out at least some of the operations of a method described herein. ”): transmitting, by an application executed on a user device (¶0081, “ The application software 310 adapts the remote device 102 , in combination with the operating system 300 , to operate as a device for facilitating data transfers and data transfer proposals. ”), a transfer request associated with a desired data transfer to a first computing system (¶0057, “ the first system 104 is in communication with the second system 106 via the network 110 . The first system 104 may be configured to transmit to the second system 106 a message and a data transfer proposal. The second system 106 may be further configured to receive a message and a data transfer proposal from the first system 104 .”), (¶0148, “ The remote device transmits to the recipient system a request for payment instruction with respect to the request for payment …”), the transfer request comprising a sender identifier (ID) (¶0037 , “…The request to transfer includes one or more identifiers that identify the record associated with the sender and/or the record associated with the recipient …”); receiving, by the application executed on the user device, a transfer approval from the first computing system (¶0042, “… Authorization may, for example, require authenticated approval using a credential such as one or more of a username, password, biometric authentication data or other credential .”), the transfer approval indicating that the desired data transfer is approved (¶0030, “… receive, from a second computing system, a transfer message for a transfer between the first account associated with the first computing system and a second account associated with the second computing system, the transfer message including routing data, an amount of resources to be transferred, and a condition associated with the transfer; evaluate the condition associated with the data transfer based on a comparison between data included in the transfer message and one or more parameters associated with the first account; and when the condition is determined to be satisfied, complete the transfer. ”), see also ¶0139-¶0140, and ¶0142; receiving, by the application executed on the user device, an acceptance packet from a recipient device, the acceptance packet indicating that the desired data transfer is accepted and comprising a recipient ID (¶0138-¶0139, “ the deposit or acceptance condition feature 816 may be used to indicate an acceptance condition whereby the first operand is “recipient name”, the operand is “matches”, and the second operand is “John Doe”, which may be evaluated by a second system to confirm that “John Doe” is the account holder of the account specified in the routing data …”), (¶0142, “ When the payment instruction is received by the transferor system, the transferor system may transmit a payment message including the payment details to the recipient system. The recipient system may then process the payment message according to the method 700 of FIG. 7 . If the condition is satisfied, the indicated amount may be transferred from the transferor’s account to the account specified in the routing data.” ), (¶0145, “ When the transferor system receives the payment instruction from the remote device, the transferor system may use the recipient alias to lookup routing data associated with the recipient and send the payment message to the recipient system…” ), see also ¶0145 ; transmitting, by the application executed on the user device, at least a portion of the acceptance packet to the first computing system (¶0139, “ The remote device transmits to the transferor system a payment instruction with respect to the payment. The instruction is received by the transferor system via the money transfer interface 800 , through the selection of a confirmation element 824 . The payment message may include the selection and configuration details of one or more options or features, including the transferor’s account, transfer amount, routing data, and acceptance condition. ” ), (¶0062-¶0063, “… The remote device 102 may be used, for example, to receive user input that includes an indication of a data acceptance condition in a data transfer proposal. The user input may further include an indication of routing data, intended transferor, recipient, an account associated with the intended transferor, an account associated with the recipient, and other information to be included in or used to construct the data transfer proposal.” ), (¶0131-¶0133, “… The first operand element 818 provides user selectable options to receive data indicating a first operand. As illustrated, the first operand element 818 offers selection of a first operand from a list of operands. The first operand may be, include or indicate a variable, data type, or placeholder. The placeholder may be a placeholder for a property of the recipient or recipient account. The list of operands may include, for example, a “recipient age”, “recipient name”, “recipient address”, “account age”, “account type” and “account value” operand” ); and receiving, by the application executed on the user device, a transfer confirmation confirming that the desired data transfer is based at least in part on the acceptance packet and/or the transfer approval (¶0148-¶0149, “ The remote device transmits to the recipient system a request for payment instruction with respect to the request for payment. The instruction is received by the recipient system via the request for payment interface 1000 , through the selection of a confirmation element 824 . The request for payment message may include the selection and configuration details of one or more options or features, including the transferee’s account, transfer amount, routing data, and acceptance condition…When the request for payment instruction is received by the recipient system, the recipient system may transmit a request for payment message including the request for payment details to the transferor system. The transferor system may then process the request for payment message according to the method 700 of FIG. 7 . If the condition is satisfied, the indicated amount may be transferred from the transferor’s account to the recipient’s account… ”). Regarding claim 2, DUNJIC discloses the method of claim 1, wherein the transfer approval comprises the sender ID (¶0124, “ The first system may present the reply to a user of a remote device via a user interface. The user interface may be that of a messaging application, such as an email application, text and/or voice message application, instant message application, or an application relating to a transferor identifier or recipient identifier included in the transfer message … ”), the method further comprising: transmitting, by the first computing system via a first application programming interface (API), the sender ID to an authentication service (¶0124, “… The user interface may be that of a messaging application, such as an email application, text and/or voice message application, instant message application, or an application relating to a transferor identifier or recipient identifier included in the transfer message…” ), (¶0042, “… the database stores account data for a plurality of accounts and a database management system will only allow a transfer out of an account if the transfer is authorized by an authorization entity for that account, such as an account holder . Authorization may, for example , require authenticated approval using a credential such as one or more of a username, password, biometric authentication data or other credential .”); receiving, by the first computing system via the first API, a validation response from the authentication service (¶0042-¶0043, “… in response to receiving the transfer message, a database management system may identify an affected account using an identifier defined by the transfer message. Then, the database management system may send an electronic notification to a client device associated with the identified account. This notification may be provided as an in-application notification or operating system level notification. The notification may include a selectable option to authorize the transfer .”), see also ¶0123 and FIG. 7 ; transmitting, by the first computing system via a second API, the data transfer request to a second computing system ¶0027, “ The method may include receiving, from a second computing system, a transfer message for a transfer between the first account associated with the first computing system and a second account associated with the second computing system, the transfer message including routing data, an amount of resources to be transferred, and a condition associated with the transfer; evaluating the condition associated with the data transfer based on a comparison between data included in the transfer message and one or more parameters associated with the first account; and when the condition is determined to be satisfied, completing the transfer .”); and receiving, by the first computing system via the second API, an approval response from the second computing system (¶0148, “ The remote device transmits to the recipient system a request for payment instruction with respect to the request for payment. The instruction is received by the recipient system via the request for payment interface 1000 , through the selection of a confirmation element 824 . The request for payment message may include the selection and configuration details of one or more options or features, including the transferee’s account, transfer amount, routing data, and acceptance condition .”), (¶0016, “… receive, from a second computing system, a transfer message for a transfer between the first account associated with the first computing system and a second account associated with the second computing system, the transfer message including routing data, an amount of resources to be transferred, and a condition associated with the transfer; evaluate the condition associated with the data transfer based on a comparison between data included in the transfer message and one or more parameters associated with the first account; and when the condition is determined to be satisfied, complete the transfer. ”), see ¶0027 and ¶0030 . Regarding claim 12, DUNJIC discloses the system of claim 8, wherein the quote comprises the sender ID (¶0095-¶0103, “ Example parameters that may be included in a data transfer proposal include: a proposal identifier identifying the particular data transfer proposal ; identification information of the type of data transfer proposal (e.g. payment, or request for payment ); identification information of the first and/or second account holders (e.g. full name, postal address, contact details, telephone number, email address, alias); an amount of resources to be transferred … ”), and the system further performs operations to: transmit, by the first computing system via a first application programming interface (API), the sender ID to an authentication service (¶0124, “… The user interface may be that of a messaging application, such as an email application, text and/or voice message application, instant message application, or an application relating to a transferor identifier or recipient identifier included in the transfer message…” ), (¶0042, “… the database stores account data for a plurality of accounts and a database management system will only allow a transfer out of an account if the transfer is authorized by an authorization entity for that account, such as an account holder . Authorization may, for example , require authenticated approval using a credential such as one or more of a username, password, biometric authentication data or other credential .”); receive, by the first computing system via the first API, a validation response from the authentication service (¶0042-¶0043, “… in response to receiving the transfer message, a database management system may identify an affected account using an identifier defined by the transfer message. Then, the database management system may send an electronic notification to a client device associated with the identified account. This notification may be provided as an in- application notification or operating system level notification. The notification may include a selectable option to authorize the transfer .”), see also ¶0123 and FIG. 7 ; transmit, by the first computing system via a second API, the data transfer request to a second computing system (¶0027, “ The method may include receiving, from a second computing system, a transfer message for a transfer between the first account associated with the first computing system and a second account associated with the second computing system, the transfer message including routing data, an amount of resources to be transferred, and a condition associated with the transfer; evaluating the condition associated with the data transfer based on a comparison between data included in the transfer message and one or more parameters associated with the first account; and when the condition is determined to be satisfied, completing the transfer .”); and receive, by the first computing system via the second API, an approval response from the second computing system (¶0148, “ The remote device transmits to the recipient system a request for payment instruction with respect to the request for payment. The instruction is received by the recipient system via the request for payment interface 1000 , through the selection of a confirmation element 824 . The request for payment message may include the selection and configuration details of one or more options or features, including the transferee’s account, transfer amount, routing data, and acceptance condition .”), (¶0016, “… receive, from a second computing system, a transfer message for a transfer between the first account associated with the first computing system and a second account associated with the second computing system, the transfer message including routing data, an amount of resources to be transferred, and a condition associated with the transfer; evaluate the condition associated with the data transfer based on a comparison between data included in the transfer message and one or more parameters associated with the first account; and when the condition is determined to be satisfied, complete the transfer. ”), see ¶0027 and ¶0030 . Regarding claim 16, DUNJIC discloses the non-transitory computer-readable medium of claim 15, wherein the quote comprises the sender ID (¶0095-¶0103, “ Example parameters that may be included in a data transfer proposal include: a proposal identifier identifying the particular data transfer proposal ; identification information of the type of data transfer proposal (e.g. payment, or request for payment ); identification information of the first and/or second account holders (e.g. full name, postal address, contact details, telephone number, email address, alias); an amount of resources to be transferred … ”), the operations further comprising: transmitting, by the first computing system via a first application programming interface (API), the sender ID to an authentication service (¶0124, “… The user interface may be that of a messaging application, such as an email application, text and/or voice message application, instant message application, or an application relating to a transferor identifier or recipient identifier included in the transfer message…” ), (¶0042, “… the database stores account data for a plurality of accounts and a database management system will only allow a transfer out of an account if the transfer is authorized by an authorization entity for that account, such as an account holder . Authorization may, for example , require authenticated approval using a credential such as one or more of a username, password, biometric authentication data or other credential .”); receiving, by the first computing system via the first API, a validation response from the authentication service (¶0042-¶0043, “… in response to receiving the transfer message, a database management system may identify an affected account using an identifier defined by the transfer message. Then, the database management system may send an electronic notification to a client device associated with the identified account. This notification may be provided as an in-application notification or operating system level notification. The notification may include a selectable option to authorize the transfer .”), see also ¶0123 and FIG. 7 ; transmitting, by the first computing system via a second API, the data transfer request to a second computing system (¶0027, “ The method may include receiving, from a second computing system, a transfer message for a transfer between the first account associated with the first computing system and a second account associated with the second computing system, the transfer message including routing data, an amount of resources to be transferred, and a condition associated with the transfer; evaluating the condition associated with the data transfer based on a comparison between data included in the transfer message and one or more parameters associated with the first account; and when the condition is determined to be satisfied, completing the transfer .”); and receiving, by the first computing system via the second API, an approval response from the second computing system (¶0148, “ The remote device transmits to the recipient system a request for payment instruction with respect to the request for payment. The instruction is received by the recipient system via the request for payment interface 1000 , through the selection of a confirmation element 824 . The request for payment message may include the selection and configuration details of one or more options or features, including the transferee’s account, transfer amount, routing data, and acceptance condition .”), (¶0016, “… receive, from a second computing system, a transfer message for a transfer between the first account associated with the first computing system and a second account associated with the second computing system, the transfer message including routing data, an amount of resources to be transferred, and a condition associated with the transfer; evaluate the condition associated with the data transfer based on a comparison between data included in the transfer message and one or more parameters associated with the first account; and when the condition is determined to be satisfied, complete the transfer. ”), see ¶0027 and ¶0030 . Regarding claim 5, DUNJIC discloses the method of claim 1, further comprising: determining, by the application executed on the user device, a public ID associated with the recipient device, based at least in part on the acceptance packet (¶0144-¶0145, “ The money transfer interface 900 may further include a recipient alias feature 902 for providing an input area to receive an alias of the recipient (e.g. email address or phone number). The recipient alias feature 902 includes an email element 904 and a phone number element 906 that provide input areas to data indicating an email address and phone number that each identify and are associated with the recipient …”); generating, by the application executed on the user device, a confirmation notification indicating the public ID associated with the associated recipient device (¶0145, “ When the transferor system receives the payment instruction from the remote device, the transferor system may use the recipient alias to lookup routing data associated with the recipient and send the payment message to the recipient system, or the transferor system may send the recipient alias in a payment message to a separate system that can replace the recipient alias with routing data in order to forward the payment message to the recipient system. ”), see also ¶0148 ; and displaying, by the application executed on the user devices, the confirmation notification (¶0043, “ in response to receiving the transfer message, a database management system may identify an affected account using an identifier defined by the transfer message. Then, the database management system may send an electronic notification to a client device associated with the identified account. This notification may be provided as an in-application notification or operating system level notification. The notification may include a selectable option to authorize the transfer. ”), (¶0124, “ The first system may present the reply to a user of a remote device via a user interface. The user interface may be that of a messaging application, such as an email application, text and/or voice message application, instant message application, or an application relating to a transferor identifier or recipient identifier included in the transfer message. In some embodiments, the user interface may be a graphical user interface that presents the notification via pop-up, alert, or in any other suitable manner .”). Regarding claim 14, DUNJIC discloses the system of claim 8, further performs operations to: determine, by the application executed on the user device, a public ID associated with the recipient device, based at least in part on the acceptance packet (¶0144-¶0145, “ The money transfer interface 900 may further include a recipient alias feature 902 for providing an input area to receive an alias of the recipient (e.g. email address or phone number). The recipient alias feature 902 includes an email element 904 and a phone number element 906 that provide input areas to data indicating an email address and phone number that each identify and are associated with the recipient …”); generate, by the application executed on the user device, a confirmation notification indicating the public ID associated with the associated recipient device (¶0145, “ When the transferor system receives the payment instruction from the remote device, the transferor system may use the recipient alias to lookup routing data associated with the recipient and send the payment message to the recipient system, or the transferor system may send the recipient alias in a payment message to a separate system that can replace the recipient alias with routing data in order to forward the payment message to the recipient system. ”), see also ¶0148 ; and display, by the application executed on the user devices, the confirmation notification (¶0043, “ in response to receiving the transfer message, a database management system may identify an affected account using an identifier defined by the transfer message. Then, the database management system may send an electronic notification to a client device associated with the identified account. This notification may be provided as an in-application notification or operating system level notification. The notification may include a selectable option to authorize the transfer. ”), (¶0124, “ The first system may present the reply to a user of a remote device via a user interface. The user interface may be that of a messaging application, such as an email application, text and/or voice message application, instant message application, or an application relating to a transferor identifier or recipient identifier included in the transfer message. In some embodiments, the user interface may be a graphical user interface that presents the notification via pop-up, alert, or in any other suitable manner .”). Regarding claim 18, DUNJIC discloses the non-transitory computer-readable medium of claim 15, the operations further comprising: determining, by the application executed on the user device, a public ID associated with the recipient device, based at least in part on the acceptance packet (¶0144-¶0145, “ The money transfer interface 900 may further include a recipient alias feature 902 for providing an input area to receive an alias of the recipient (e.g. email address or phone number). The recipient alias feature 902 includes an email element 904 and a phone number element 906 that provide input areas to data indicating an email address and phone number that each identify and are associated with the recipient …”); generating, by the application executed on the user device, a confirmation notification indicating the public ID associated with the associated recipient device (¶0145, “ When the transferor system receives the payment instruction from the remote device, the transferor system may use the recipient alias to lookup routing data associated with the recipient and send the payment message to the recipient system, or the transferor system may send the recipient alias in a payment message to a separate system that can replace the recipient alias with routing data in order to forward the payment message to the recipient system. ”), see also ¶0148 ; and displaying, by the application executed on the user devices, the confirmation notification (¶0043, “ in response to receiving the transfer message, a database management system may identify an affected account using an identifier defined by the transfer message. Then, the database management system may send an electronic notification to a client device associated with the identified account. This notification may be provided as an in-application notification or operating system level notification. The notification may include a selectable option to authorize the transfer. ”), (¶0124, “ The first system may present the reply to a user of a remote device via a user interface. The user interface may be that of a messaging application, such as an email application, text and/or voice message application, instant message application, or an application relating to a transferor identifier or recipient identifier included in the transfer message. In some embodiments, the user interface may be a graphical user interface that presents the notification via pop-up, alert, or in any other suitable manner .”). Regarding claim 6, DUNJIC discloses the method of claim 1, wherein the transfer approval comprises a quote ID (¶0095-¶0103, “Example parameters that may be included in a data transfer proposal include: a proposal identifier identifying the particular data transfer proposal ; identification information of the type of data transfer proposal (e.g. payment, or request for payment ); identification information of the first and/or second account holders (e.g. full name, postal address, contact details, telephone number, email address, alias); an amount of resources to be transferred …”). Regarding claim 20, DUNJIC discloses the non-transitory computer-readable medium of claim 15, wherein the transfer approval comprises a quote ID (¶0095-¶0103, “Example parameters that may be included in a data transfer proposal include: a proposal identifier identifying the particular data transfer proposal ; identification information of the type of data transfer proposal (e.g. payment, or request for payment ); identification information of the first and/or second account holders (e.g. full name, postal address, contact details, telephone number, email address, alias); an amount of resources to be transferred …”). Regarding claim 9, DUNJIC discloses the system of claim 8, wherein the user device and the recipient device communicate via a wireless connection initiated via near field communication (¶0074, “… the communications module 230 may allow the remote device 102 to communicate using near-field communication (NFC), via Wi-Fi (TM), using Bluetooth (TM) or via some combination of one or more networks or protocols… ”). Regarding claim 10, DUNJIC discloses the system of claim 8, wherein the anonymous data transfer is a peer-to-peer data transfer (¶0030, “… receive, from a second computing system , a transfer message for a transfer between the first account associated with the first computing system and a second account associated with the second computing system …”), (¶0057, FIG. 1, “ the first system 104 is in communication with the second system 106 via the network 110 . The first system 104 may be configured to transmit to the second system 106 a message and a data transfer proposal. The second system 106 may be further configured to receive a message and a data transfer proposal from the first system 104 .”) . Claim Rejections - 35 USC § 103 07-20-aia AIA 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. 07-23-aia AIA 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. 07-21-aia AIA Claim s 3-4, 13, and 17 are rejected under 35 U.S.C. 103 as being unpatentable over US. PGPub. No. 20230060707 to DUNJIC et al. (hereinafter DUNJIC) in view of US. Pat. No. 10270587 to Wu; Frank (hereinafter Wu) and further in view of US. PGPub. No. 20020184485 to Dray et al. (hereinafter Dray) . Regarding claim 3, DUNJIC discloses the method of claim 1. However, DUNJIC does not explicitly disclose the following limitation: further comprising: transmitting, by the application executed on the user device, a registration request to the first computing system; and receiving, by the application executed on the user device, a user certificate signed with a public key of a public-private key pair. Wu discloses further comprising: transmitting, by the application executed on the user device, a registration request to the first computing system (Coln. 13, lines 24-67 to Coln. 14, line 1-33, FIG.7, steps S7-S9, “ FIG. 7 is a flow chart that illustrates an example of the account activation and card registration process for embodiments of the invention. Referring to FIG. 7, at S 1 , a card account owner may receive a QR code-imprinted card and the activation code in separate deliveries, such as postal service deliveries and not via online or email. At S 2 , if the card owner's mobile device does not have the mobile application installed, the card owner may download the mobile application, for example, from the card issuer's support site for the specific device which may be used for all future transactions…” ); Thus, one of ordinary skill in the art would have found it obvious before the effective filing date of applicant’s claimed invention to modify the method of DUNJIC to include registration request to a computing system as disclosed by Wu and be motivated in doing so in order to redefine security parameters used to authenticate clients and maximizes transaction efficiency-Wu Coln. 5, lines 1-19 in parts. Although, Wu discloses generation of cryptographic key pairs and construct certificate signing request messages (Coln. 11, lines 29-39), the combination of DUNJIC and WU does not explicitly disclose the following limitation: receiving, by the application executed on the user device, a user certificate signed with a public key of a public-private key pair. Dray discloses receiving, by the application executed on the user device, a user certificate signed with a public key of a public-private key pair (¶0069, “ The existing public key scheme described above requires that a public/private key pair be generated for each user during the initial registration process. The private key is encrypted under a password known only to the user, and stored in encrypted form on a floppy disk supplied to the user, e.g., as illustrated at 56 in FIG. 5. The corresponding public key, along with other identifying information about the user, is assembled into a Certificate Signing Request (CSR) and sent to a Certificate Authority (CA). In response, the CA creates a public key certificate for the user, signs this certificate with the private key of the CA, and stores the signed certificate in a publicly accessible certificate database. The CA signature thus validates the link between the user's identity and the user's private key . ”), (¶0077, “ Clicking on the VERIFY button executes the signature processing program within the document. More specifically, the verifier "servlet" 68 forming part of the signature program verifies the authenticity of the user's public key certificate, by obtaining the public key of the CA that signed the user's certificate and verifying the CA's signature on the certificate, as indicated above, and extracts the user's public key from the CA's certificate database, or from local cache 66. The host document is converted to a data structure and then to a canonical bit sequence, which is passed to a signature verification algorithm along with the user's public key… ”). Thus, one of ordinary skill in the art would have found it obvious before the effective filing date of applicant’s claimed invention to modify the method of DUNJIC and Wu to include user certificate signing as disclosed by Dray and be motivated in doing so in order to ascertain that the document was created by the user associated with the public key which also confirms that the document was not altered as it was signed-Dray ¶0077 in parts. Regarding claim 13, DUNJIC discloses the system of claim 8. However, DUNJIC does not explicitly disclose the following limitation: Further performs operation to: transmit, by the application executed on the user device, a registration request to the first computing system; and receive, by the application executed on the user device, a user certificate signed with a public key of a public-private key pair. Wu discloses further perform the operation to: transmit, by the application executed on the user device, a registration request to the first computing system (Coln. 13, lines 24-67 to Coln. 14, line 1-33, FIG.7, steps S7-S9, “ FIG. 7 is a flow chart that illustrates an example of the account activation and card registration process for embodiments of the invention. Referring to FIG. 7, at S 1 , a card account owner may receive a QR code-imprinted card and the activation code in separate deliveries, such as postal service deliveries and not via online or email. At S 2 , if the card owner's mobile device does not have the mobile application installed, the card owner may download the mobile application, for example, from the card issuer's support site for the specific device which may be used for all future transactions…” ); Thus, one of ordinary skill in the art would have found it obvious before the effective filing date of applicant’s claimed invention to modify the system of DUNJIC to include registration request to a computing system as disclosed by Wu and be motivated in doing so in order to redefine security parameters used to authenticate clients and maximizes transaction efficiency-Wu Coln. 5, lines 1-19 in parts. Although, Wu discloses generation of cryptographic key pairs and construct certificate signing request messages (Coln. 11, lines 29-39), the combination of DUNJIC and WU does not explicitly disclose the following limitation: receive, by the application executed on the user device, a user certificate signed with a public key of a public-private key pair. Dray discloses receive, by the application executed on the user device, a user certificate signed with a public key of a public-private key pair (¶0069, “ The existing public key scheme described above requires that a public/private key pair be generated for each user during the initial registration process. The private key is encrypted under a password known only to the user, and stored in encrypted form on a floppy disk supplied to the user, e.g., as illustrated at 56 in FIG. 5. The corresponding public key, along with other identifying information about the user, is assembled into a Certificate Signing Request (CSR) and sent to a Certificate Authority (CA). In response, the CA creates a public key certificate for the user, signs this certificate with the private key of the CA, and stores the signed certificate in a publicly accessible certificate database. The CA signature thus validates the link between the user's identity and the user's private key . ”), (¶0077, “ Clicking on the VERIFY button executes the signature processing program within the document. More specifically, the verifier "servlet" 68 forming part of the signature program verifies the authenticity of the user's public key certificate, by obtaining the public key of the CA that signed the user's certificate and verifying the CA's signature on the certificate, as indicated above, and extracts the user's public key from the CA's certificate database, or from local cache 66. The host document is converted to a data structure and then to a canonical bit sequence, which is passed to a signature verification algorithm along with the user's public key… ”). Thus, one of ordinary skill in the art would have found it obvious before the effective filing date of applicant’s claimed invention to modify the system of DUNJIC and Wu to include user certificate signing as disclosed by Dray and be motivated in doing so in order to ascertain that the document was created by the user associated with the public key which also confirms that the document was not altered as it was signed-Dray ¶0077 in parts. Regarding claim 17, DUNJIC discloses the non-transitory computer-readable medium of claim 15. However, DUNJIC does not explicitly disclose the following limitation: the operations further comprising: transmitting, by the application executed on the user device, a registration request to the first computing system; and receiving, by the application executed on the user device, a user certificate signed with a public key of a public-private key pair. Wu discloses the operations further comprising: transmitting, by the application executed on the user device, a registration request to the first computing system (Coln. 13, lines 24-67 to Coln. 14, line 1-33, FIG.7, steps S7-S9, “ FIG. 7 is a flow chart that illustrates an example of the account activation and card registration process for embodiments of the invention. Referring to FIG. 7, at S 1 , a card account owner may receive a QR code-imprinted card and the activation code in separate deliveries, such as postal service deliveries and not via online or email. At S 2 , if the card owner's mobile device does not have the mobile application installed, the card owner may download the mobile application, for example, from the card issuer's support site for the specific device which may be used for all future transactions…” ); Thus, one of ordinary skill in the art would have found it obvious before the effective filing date of applicant’s claimed invention to modify the non-transitory computer-readable medium of DUNJIC to include registration request to a computing system as disclosed by Wu and be motivated in doing so in order to redefine security parameters used to authenticate clients and maximizes transaction efficiency-Wu Coln. 5, lines 1-19 in parts. Although, Wu discloses generation of cryptographic key pairs and construct certificate signing request messages (Coln. 11, lines 29-39), the combination of DUNJIC and WU does not explicitly disclose the following limitation: receiving, by the application executed on the user device, a user certificate signed with a public key of a public-private key pair. Dray discloses receiving, by the application executed on the user device, a user certificate signed with a public key of a public-private key pair (¶0069, “ The existing public key scheme described above requires that a public/private key pair be generated for each user during the initial registration process. The private key is encrypted under a password known only to the user, and stored in encrypted form on a floppy disk supplied to the user, e.g., as illustrated at 56 in FIG. 5. The corresponding public key, along with other identifying information about the user, is assembled into a Certificate Signing Request (CSR) and sent to a Certificate Authority (CA). In response, the CA creates a public key certificate for the user, signs this certificate with the private key of the CA, and stores the signed certificate in a publicly accessible certificate database. The CA signature thus validates the link between the user's identity and the user's private key . ”), (¶0077, “ Clicking on the VERIFY button executes the signature processing program within the document. More specifically, the verifier "servlet" 68 forming part of the signature program verifies the authenticity of the user's public key certificate, by obtaining the public key of the CA that signed the user's certificate and verifying the CA's signature on the certificate, as indicated above, and extracts the user's public key from the CA's certificate database, or from local cache 66. The host document is converted to a data structure and then to a canonical bit sequence, which is passed to a signature verification algorithm along with the user's public key… ”). Thus, one of ordinary skill in the art would have found it obvious before the effective filing date of applicant’s claimed invention to modify the non-transitory computer-readable medium of DUNJIC and Wu to include user certificate signing as disclosed by Dray and be motivated in doing so in order to ascertain that the document was created by the user associated with the public key which also confirms that the document was not altered as it was signed-Dray ¶0077 in parts. Regarding claim 4, DUNJIC in view of Wu and further in view of Dray discloses the method of claim 3. DUNJIC further discloses validating, by the first computing system, the recipient ID via one or more APIs (¶0138-¶0139, “ the deposit or acceptance condition feature 816 may be used to indicate an acceptance condition whereby the first operand is “recipient name”, the operand is “matches”, and the second operand is “John Doe”, which may be evaluated by a second system to confirm that “John Doe” is the account holder of the account specified in the routing data …”), (¶0148, “ The remote device transmits to the recipient system a request for payment instruction with respect to the request for payment. The instruction is received by the recipient system via the request for payment interface 1000, through the selection of a confirmation element 824. The request for payment message may include the selection and configuration details of one or more options or features, including the transferee’s account, transfer amount, routing data, and acceptance condition .” ), (¶0145, “ When the transferor system receives the payment instruction from the remote device, the transferor system may use the recipient alias to lookup routing data associated with the recipient and send the payment message to the recipient system, or the transferor system may send the recipient alias in a payment message to a separate system that can replace the recipient alias with routing data in order to forward the payment message to the recipient system.”, wherein using the recipient alias to lookup routing data associated with the recipient and send the payment message to the recipient system is an indication of confirmation/validating the recipient ID before sending the payment to the recipient ); and in response to validating the recipient ID, performing the desired data transfer (¶0030, “… evaluate the condition associated with the data transfer based on a comparison between data included in the transfer message and one or more parameters associated with the first account; and when the condition is determined to be satisfied, complete the transfer.” ), (¶0142, “… The recipient system may then process the payment message according to the method 700 of FIG. 7 . If the condition is satisfied, the indicated amount may be transferred from the transferor’s account to the account specified in the routing data. ”); and Wu further discloses wherein the acceptance packet is encrypted with the public key of the public-private key pair, the method further comprising: decrypting, by the first computing system, the acceptance packet using a private key of the public-private key pair (Coln. 2, lines 29-44, “… receiving the fund transfer transaction request message may involve receiving a fund transfer amount for the fund transfer transaction. In further aspects, receiving the fund transfer transaction request message many involve receiving a fund transfer receiver identifier for the fund transfer transaction…”), (Coln. 3, lines 19-31, “ receiving the transaction message may involve receiving the transaction message encrypted by the mobile application with a public key of the card issuer. Other aspects may involve decrypting, using the processor, the encrypted transaction message with the card issuer's private key of a public/private key pair of the card issuer. In further aspects, verifying the user's account information may involve checking the user's account balance, decrementing the user's account by a transaction request amount, and updating a user's account record. In other aspects, updating the user's account record may involve updating electronic wallet account records for both a sender and a receiver in a fund transfer transaction.” ); Thus, one of ordinary skill in the art would have found it obvious before the effective filing date of applicant’s claimed invention to modify the method of DUNJIC, Wu, and Dreay to include encrypting the acceptance packet with the public key of the public-private key pair and decrypting, by the first computing system, the acceptance packet using a private key of the public-private key pair as disclosed by Wu and be motivated in doing so in order to guaranteeing total confidentiality of the message in transit . 07-21-aia AIA Claim s 11 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over US. PGPub. No. 20230060707 to DUNJIC et al. (hereinafter DUNJIC) in view of US. Pat. No. 10270587 to Wu; Frank (hereinafter Wu) Regarding claim 11, DUNJIC discloses the system of claim 8, and further discloses validate, by the first computing system, the recipient ID via one or more APIs (¶0138-¶0139, “ the deposit or acceptance condition feature 816 may be used to indicate an acceptance condition whereby the first operand is “recipient name”, the operand is “matches”, and the second operand is “John Doe”, which may be evaluated by a second system to confirm that “John Doe” is the account holder of the account specified in the routing data …”), (¶0148, “ The remote device transmits to the recipient system a request for payment instruction with respect to the request for payment. The instruction is received by the recipient system via the request for payment interface 1000, through the selection of a confirmation element 824. The request for payment message may include the selection and configuration details of one or more options or features, including the transferee’s account, transfer amount, routing data, and acceptance condition .” ), (¶0145, “ When the transferor system receives the payment instruction from the remote device, the transferor system may use the recipient alias to lookup routing data associated with the recipient and send the payment message to the recipient system, or the transferor system may send the recipient alias in a payment message to a separate system that can replace the recipient alias with routing data in order to forward the payment message to the recipient system.”, wherein using the recipient alias to lookup routing data associated with the recipient and send the payment message to the recipient system is an indication of confirmation/validating the recipient ID before sending the payment to the recipient ); and in response to validating the recipient ID, perform the desired data transfer (¶0030, “… evaluate the condition associated with the data transfer based on a comparison between data included in the transfer message and one or more parameters associated with the first account; and when the condition is determined to be satisfied, complete the transfer.” ), (¶0142, “… The recipient system may then process the payment message according to the method 700 of FIG. 7 . If the condition is satisfied, the indicated amount may be transferred from the transferor’s account to the account specified in the routing data. ”). However, DUNJIC does not explicitly disclose the following limitation: wherein the acceptance packet is encrypted with a public key of the public-private key pair and the system further performs operations to: decrypt, by the first computing system, the acceptance packet using a private key of the public-private key pair; Wu discloses wherein the acceptance packet is encrypted with a public key of the public-private key pair and the system further performs operations to: decrypt, by the first computing system, the acceptance packet using a private key of the public-private key pair (Coln. 2, lines 29-44, “… receiving the fund transfer transaction request message may involve receiving a fund transfer amount for the fund transfer transaction. In further aspects, receiving the fund transfer transaction request message many involve receiving a fund transfer receiver identifier for the fund transfer transaction…”), (Coln. 3, lines 19-31, “ receiving the transaction message may involve receiving the transaction message encrypted by the mobile application with a public key of the card issuer. Other aspects may involve decrypting, using the processor, the encrypted transaction message with the card issuer's private key of a public/private key pair of the card issuer. In further aspects, verifying the user's account information may involve checking the user's account balance, decrementing the user's account by a transaction request amount, and updating a user's account record. In other aspects, updating the user's account record may involve updating electronic wallet account records for both a sender and a receiver in a fund transfer transaction.” ); Thus, one of ordinary skill in the art would have found it obvious before the effective filing date of applicant’s claimed invention to modify the method of DUNJIC to include encrypting the acceptance packet with the public key of the public-private key pair and decrypting, by the first computing system, the acceptance packet using a private key of the public-private key pair as disclosed by Wu and be motivated in doing so in order to guaranteeing total confidentiality of the message in transit. Regarding claim 19, DUNJIC discloses the non-transitory computer-readable medium of claim 15, and further discloses validating, by the first computing system, the recipient ID via one or more APIs (¶0138-¶0139, “ the deposit or acceptance condition feature 816 may be used to indicate an acceptance condition whereby the first operand is “recipient name”, the operand is “matches”, and the second operand is “John Doe”, which may be evaluated by a second system to confirm that “John Doe” is the account holder of the account specified in the routing data …”), (¶0148, “ The remote device transmits to the recipient system a request for payment instruction with respect to the request for payment. The instruction is received by the recipient system via the request for payment interface 1000, through the selection of a confirmation element 824. The request for payment message may include the selection and configuration details of one or more options or features, including the transferee’s account, transfer amount, routing data, and acceptance condition .” ), (¶0145, “ When the transferor system receives the payment instruction from the remote device, the transferor system may use the recipient alias to lookup routing data associated with the recipient and send the payment message to the recipient system, or the transferor system may send the recipient alias in a payment message to a separate system that can replace the recipient alias with routing data in order to forward the payment message to the recipient system.”, wherein using the recipient alias to lookup routing data associated with the recipient and send the payment message to the recipient system is an indication of confirmation/validating the recipient ID before sending the payment to the recipient ); and in response to validating the recipient ID, performing the desired data transfer (¶0030, “… evaluate the condition associated with the data transfer based on a comparison between data included in the transfer message and one or more parameters associated with the first account; and when the condition is determined to be satisfied, complete the transfer.” ), (¶0142, “… The recipient system may then process the payment message according to the method 700 of FIG. 7 . If the condition is satisfied, the indicated amount may be transferred from the transferor’s account to the account specified in the routing data. ”). However, DUNJIC does not explicitly disclose the following limitation: wherein the acceptance packet is encrypted with a public key of the public-private key pair and the system further performs operations to: decrypting, by the first computing system, the acceptance packet using a private key of the public-private key pair; Wu discloses wherein the acceptance packet is encrypted with a public key of the public-private key pair and the system further performs operations to: decrypting, by the first computing system, the acceptance packet using a private key of the public-private key pair (Coln. 2, lines 29-44, “… receiving the fund transfer transaction request message may involve receiving a fund transfer amount for the fund transfer transaction. In further aspects, receiving the fund transfer transaction request message many involve receiving a fund transfer receiver identifier for the fund transfer transaction…”), (Coln. 3, lines 19-31, “ receiving the transaction message may involve receiving the transaction message encrypted by the mobile application with a public key of the card issuer. Other aspects may involve decrypting, using the processor, the encrypted transaction message with the card issuer's private key of a public/private key pair of the card issuer. In further aspects, verifying the user's account information may involve checking the user's account balance, decrementing the user's account by a transaction request amount, and updating a user's account record. In other aspects, updating the user's account record may involve updating electronic wallet account records for both a sender and a receiver in a fund transfer transaction.” ); Thus, one of ordinary skill in the art would have found it obvious before the effective filing date of applicant’s claimed invention to modify the non-transitory computer-readable medium of DUNJIC to include encrypting the acceptance packet with the public key of the public-private key pair and decrypting, by the first computing system, the acceptance packet using a private key of the public-private key pair as disclosed by Wu and be motivated in doing so in order to guaranteeing total confidentiality of the message in transit . 07-21-aia AIA Claim 7 is rejected under 35 U.S.C. 103 as being unpatentable over US. PGPub. No. 20230060707 to DUNJIC et al. (hereinafter DUNJIC) in view of US. Pat. No. 10270587 to Wu; Frank (hereinafter Wu) and further in view of US. PGPub. No. 20200117690 to Tran et al. (hereinafter Tran) . Regarding claim 7, DUNJIC discloses the method of claim 1 further comprising: receiving, by the application executed on the user device, a transfer confirmation from the first computing system (¶0138-¶0139, “ The remote device transmits to the transferor system a payment instruction with respect to the payment. The instruction is received by the transferor system via the money transfer interface 800 , through the selection of a confirmation element 824 . The payment message may include the selection and configuration details of one or more options or features, including the transferor’s account, transfer amount, routing data, and acceptance condition. ”), see also ¶0148, However, DUNJIC does not explicitly disclose the following limitation: the transfer confirmation comprising a random ID and a transfer signature signed with the private key of a public-private key pair; transmitting, by the application executed on the user device, the transfer signature to the recipient device; and decrypting, by a recipient application executed on the recipient device, the transfer signature using a public key of the public-private key pair to verify the random ID. Wu discloses the transfer confirmation comprising a random ID (Coln. 1, lines 65-67 to Coln. 2, lines 1-11, “… Using the processor, the user's account information is verified and a transaction confirmation message is generated and sent to the mobile application on the user's mobile device processor” ), (Coln. 7, lines 38-55, “… the QR code 20 shown in FIG. 2 contains a 16 digit account number in text format; random data fields of 68 characters: 128 bits Advanced Encryption Standard (AES) encrypted, base 64 encoded; a key identifier; the issuer's URL; and the issuer's telephone number… ” ) and a transfer signature signed with the private key of a public-private key pair; transmitting, by the application executed on the user device, the transfer signature to the recipient device (FIG. 7, Coln. 13, lines 57-67 to Coln. 14, lines 1-8, “ the card issuer application may retrieve a unique symmetric key for the account and encrypt a message to the mobile device with a public key for the mobile device that contains the symmetric key and a one-time confirmation code and sends the message to the mobile device. At S 6 , Upon receipt of the message, the mobile application may use its private key to decrypt message and unveil the unique symmetric key for the high density code and the one-time confirmation code…”, wherein the one-time confirmation code is interpreted as the claimed transfer signature ). Thus, one of ordinary skill in the art would have found it obvious before the effective filing date of applicant’s claimed invention to modify the method of DUNJIC to include the transfer confirmation comprising a random ID a transfer signature as disclosed by Wu, and be motivated in doing so in order to establish a solid foundation for secure transactions and addresses issues, such as economic losses due to the current rate of increase in fraudulent ATM transactions, credit card transactions, online purchasing transactions, and mobile payment transactions-WU Coln. 5, lines 1-19 in parts. However, the combination of DUNJIC and Wu does not explicitly disclose the following limitation: a transfer signature signed with the private key of a public-private key pair; transmitting, by the application executed on the user device, the transfer signature to the recipient device; and decrypting, by a recipient application executed on the recipient device, the transfer signature using a public key of the public-private key pair to verify the random ID. Tran discloses a transfer signature signed with the private key of a public-private key pair; transmitting, by the application executed on the user device, the transfer signature to the recipient device; and decrypting, by a recipient application executed on the recipient device, the transfer signature using a public key of the public-private key pair to verify the random ID (¶0177, “… The transaction message, in various embodiments, is digitally signed by the sender's private key to authenticate the sender's identity to the network nodes, e.g., by decrypting the sender's digitally signed transaction message using the sender's public key to verify that the sender originated the transaction .”), (¶0184, “… the transaction 323 is digitally signed by the sender's private key to create a digital signature 332 for verifying the sender's identity to the network nodes. The network nodes decrypt the digital signature 332, via the sender's previously exchanged public key , and compare the unencrypted information to the transaction 323 . If they match, the sender's authenticity is verified and, after a proper chain of ownership is verified via the ledgers (as explained above), the receiver is recorded in the ledgers as the new Blockchain token 329 owner .”), see also ¶0185 and ¶0252 . Thus, one of ordinary skill in the art would have found it obvious before the effective filing date of applicant’s claimed invention to modify the method of DUNJIC and Wu to include a transfer signature signed with the private key of a public-private key pair and decrypting, by a recipient application executed on the recipient device, the transfer signature using a public key of the public-private key pair to verify the random ID as disclosed by Tran and be motivated in doing so in order to verify that the sender originated the transaction-Tran ¶0177 in parts . Conclusion 07-96 AIA The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. US. 20210365942, US. 10497037, US. 20190327223, US. 20130232336 . Any inquiry concerning this communication or earlier communications from the examiner should be directed to MUDASIRU K OLAEGBE whose telephone number is (571)272-2082. The examiner can normally be reached MON-FRI. 7.30AM-5.30PM. 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, Farid Homayounmehr can be reached at 5712723739. 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. /MUDASIRU K OLAEGBE/Examiner, Art Unit 2495 /FARID HOMAYOUNMEHR/Supervisory Patent Examiner, Art Unit 2495 Application/Control Number: 18/894,974 Page 2 Art Unit: 2495 Application/Control Number: 18/894,974 Page 3 Art Unit: 2495 Application/Control Number: 18/894,974 Page 4 Art Unit: 2495 Application/Control Number: 18/894,974 Page 5 Art Unit: 2495 Application/Control Number: 18/894,974 Page 6 Art Unit: 2495 Application/Control Number: 18/894,974 Page 7 Art Unit: 2495 Application/Control Number: 18/894,974 Page 8 Art Unit: 2495 Application/Control Number: 18/894,974 Page 9 Art Unit: 2495 Application/Control Number: 18/894,974 Page 10 Art Unit: 2495 Application/Control Number: 18/894,974 Page 11 Art Unit: 2495 Application/Control Number: 18/894,974 Page 12 Art Unit: 2495 Application/Control Number: 18/894,974 Page 13 Art Unit: 2495 Application/Control Number: 18/894,974 Page 14 Art Unit: 2495 Application/Control Number: 18/894,974 Page 15 Art Unit: 2495 Application/Control Number: 18/894,974 Page 16 Art Unit: 2495 Application/Control Number: 18/894,974 Page 17 Art Unit: 2495 Application/Control Number: 18/894,974 Page 18 Art Unit: 2495 Application/Control Number: 18/894,974 Page 19 Art Unit: 2495 Application/Control Number: 18/894,974 Page 20 Art Unit: 2495 Application/Control Number: 18/894,974 Page 21 Art Unit: 2495 Application/Control Number: 18/894,974 Page 22 Art Unit: 2495 Application/Control Number: 18/894,974 Page 23 Art Unit: 2495 Application/Control Number: 18/894,974 Page 25 Art Unit: 2495 Application/Control Number: 18/894,974 Page 26 Art Unit: 2495 Application/Control Number: 18/894,974 Page 27 Art Unit: 2495 Application/Control Number: 18/894,974 Page 28 Art Unit: 2495 Application/Control Number: 18/894,974 Page 29 Art Unit: 2495 Application/Control Number: 18/894,974 Page 30 Art Unit: 2495 Application/Control Number: 18/894,974 Page 31 Art Unit: 2495 Application/Control Number: 18/894,974 Page 32 Art Unit: 2495 Application/Control Number: 18/894,974 Page 34 Art Unit: 2495 Application/Control Number: 18/894,974 Page 35 Art Unit: 2495 Application/Control Number: 18/894,974 Page 36 Art Unit: 2495 Application/Control Number: 18/894,974 Page 37 Art Unit: 2495 Application/Control Number: 18/894,974 Page 38 Art Unit: 2495 Application/Control Number: 18/894,974 Page 39 Art Unit: 2495 Application/Control Number: 18/894,974 Page 40 Art Unit: 2495
Read full office action

Prosecution Timeline

Sep 24, 2024
Application Filed
Jun 18, 2026
Non-Final Rejection mailed — §102, §103 (current)

Precedent Cases

Applications granted by this same examiner with similar technology

Patent 12683932
DYNAMIC ROUTING OF APPLICATION TRAFFIC TO ZTNA CONNECTORS
3y 6m to grant Granted Jul 14, 2026
Patent 12676887
METHOD AND SYSTEM FOR GENERATING DECOY FILES USING A DEEP LEARNING ENGINE FOR PROTECTION AGAINST RANSOMWARE ATTACKS
3y 4m to grant Granted Jul 07, 2026
Patent 12621320
SYSTEMS, METHODS, AND APPARATUSES FOR DETERMINING RESOURCE MISAPPROPRIATION BASED ON DISTRIBUTION FREQUENCY IN AN ELECTRONIC NETWORK
3y 5m to grant Granted May 05, 2026
Patent 12574406
SYSTEM AND METHOD FOR DATA FILTERING IN MACHINE LEARNING MODEL TO DETECT IMPERSONATION ATTACKS
5y 3m to grant Granted Mar 10, 2026
Patent 12489623
SYSTEMS AND COMPUTER-IMPLEMENTED METHODS FOR GENERATING PSEUDO RANDOM NUMBERS
3y 4m to grant Granted Dec 02, 2025
Study what changed to get past this examiner. Based on 5 most recent grants.

Strategy Recommendation AI-generated — please review before filing

Get a prosecution strategy drawn from examiner precedents, rejection analysis, and claim mapping.
Typically takes 5-10 seconds — AI-generated, attorney review required before filing

Prosecution Projections

1-2
Expected OA Rounds
74%
Grant Probability
91%
With Interview (+17.2%)
3y 2m (~1y 4m remaining)
Median Time to Grant
Low
PTA Risk
Based on 85 resolved cases by this examiner. Grant probability derived from career allowance 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