DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
This communication is in response to the application filed on 09/25/2024. Claims 1-20 are currently pending in the application.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 08/19/2025 is 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 § 103
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.
Claims 1-6, 8-13, and 15-20 are rejected under 35 U.S.C. 103 as being unpatentable over PGPub. No. 20230060707 to DUNJIC et al. (hereinafter DUNJIC) in view of PGPub. No. 20210365942 to Williams; Otto (hereinafter Williams).
Regarding claim 1, DUNJIC discloses a method, comprising:
receiving, by a first computing system, a transfer request from an
application executed on a user device, the transfer request comprising a sender identifier (ID) (¶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;…”), (¶0030, “ a non-transitory computer-readable storage medium comprising processor-executable instructions which, when executed, configure a processor to: 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.”), (¶0037, “A request to transfer is a message that is sent on behalf of a recipient to initiate a transfer from a sender to the recipient. That is, the request to transfer is sent, on behalf of the recipient, from the database management system associated with the recipient to the database management system associated with the sender. The request to transfer requests a transfer from a record in the database that is associated with the sender to a record in the database that is associated with the recipient. 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. The identifier(s) may be or include an account number. The request to transfer may also include one or more identifiers that identify the database management system associated with the sender and/or that identify the database management system associated with the recipient. Such identifiers may be or include one or more of: a transit number and an institution number.”) and indicating a desired data transfer (¶0095-¶0103, “…identification information of the type of data transfer proposal (e.g. payment, or request for payment)…”);
accessing, by the first computing system, a second computing system
to verify data associated with the desired data transfer comprised in a first data store of the second computing system and associated with the sender ID (¶0037, “… the request to transfer is sent, on behalf of the recipient, from the database management system associated with the recipient to the database management system associated with the sender. The request to transfer requests a transfer from a record in the database that is associated with the sender to a record in the database that is associated with the recipient. 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…”), (¶0104, “The data store 600 may further store data regarding an account holder in a user account object 604. A user account object 604 may be a data structure and may include details regarding an individual or entity holding an account or other logical storage area. Example details include a user account identifier indicating a particular person or entity, identification information (e.g. first and last name), an alias (e.g. email address, phone number), contact information (e.g. home address), date of birth, date of incorporation, and sign in or authentication credentials (e.g. user name, password, access card number). The account holder may be or represent a transferor, recipient, payor, payee, customer or user.”), (¶0042, “…the database management system that receives the request to transfer message may be configured to execute a process for obtaining authorization to complete a transfer in response to receiving the request to transfer... 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.”), (¶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.”);
in response to verifying the data comprised in the first data store associated with the sender ID:
generating, by the first computing system, a transfer approval for the desired data transfer (¶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.”), (¶0030, “…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 ¶0142; and
transmitting, by the first computing system, the transfer approval for the desired data transfer to the application executed on the user device (¶0139-¶0140, “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…”), (¶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.”).
However, DUNJIC does not explicitly disclose accessing, by the first computing system,
a second computing system via an application programming interface (API) to verify data associated with the desired data transfer comprised in a first data store of the second computing system,
Williams discloses accessing, by the first computing system,
a second computing system via an application programming interface (API) to verify data associated with the desired data transfer comprised in a first data store of the second computing system and associated with the sender ID (¶0049-¶0052, “…The verification request message (also referred to as “a verification request”) may be in any suitable format. The verification request message can be transmitted from the server computer 108 to the wallet aggregator computer 110 via any suitable application programming interface (API) call. In some embodiments, the server computer 108 may store particular API calls to be utilized to transmit verification requests to particular wallet providers. The verification request message may request the wallet aggregator computer 110 to verify the receiver's information, such as mobile number and name. The verification request may also indicate and/or include a request for the receiver's account identifier (e.g., a PAN associated with the receiver 104).”):
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 accessing a computer system via API to verify data as disclosed by Williams and be motivated in doing so in order to increase the security of the system and thereby prevent fraudulent data transfer.
Regarding claim 8, DUNJIC discloses a first computing system for performing anonymous data transfers (abstract, “a transfer message for a transfer between a first account associated with a first computing system and a second account associated with the second computing system), the system comprising:
one or more processors (¶0031, “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.”); 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.”):
receive, by the first computing system, a transfer request from an application executed on a user device, the transfer request comprising a sender identifier (ID) and indicating a desired data transfer (¶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;…”), (¶0030, “ a non-transitory computer-readable storage medium comprising processor-executable instructions which, when executed, configure a processor to: 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.”), (¶0037, “A request to transfer is a message that is sent on behalf of a recipient to initiate a transfer from a sender to the recipient. That is, the request to transfer is sent, on behalf of the recipient, from the database management system associated with the recipient to the database management system associated with the sender. The request to transfer requests a transfer from a record in the database that is associated with the sender to a record in the database that is associated with the recipient. 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. The identifier(s) may be or include an account number. The request to transfer may also include one or more identifiers that identify the database management system associated with the sender and/or that identify the database management system associated with the recipient. Such identifiers may be or include one or more of: a transit number and an institution number.”) and indicating a desired data transfer (¶0095-¶0103, “…identification information of the type of data transfer proposal (e.g. payment, or request for payment)…”);
access, by the first computing system, a second computing system to verify data associated with the desired data transfer comprised in a first data store of the second computing system and associated with the sender ID (¶0037, “… the request to transfer is sent, on behalf of the recipient, from the database management system associated with the recipient to the database management system associated with the sender. The request to transfer requests a transfer from a record in the database that is associated with the sender to a record in the database that is associated with the recipient. 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…”), (¶0104, “The data store 600 may further store data regarding an account holder in a user account object 604. A user account object 604 may be a data structure and may include details regarding an individual or entity holding an account or other logical storage area. Example details include a user account identifier indicating a particular person or entity, identification information (e.g. first and last name), an alias (e.g. email address, phone number), contact information (e.g. home address), date of birth, date of incorporation, and sign in or authentication credentials (e.g. user name, password, access card number). The account holder may be or represent a transferor, recipient, payor, payee, customer or user.”), (¶0042, “…the database management system that receives the request to transfer message may be configured to execute a process for obtaining authorization to complete a transfer in response to receiving the request to transfer... 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.”), (¶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.”);
in response to verifying the data comprised in the first data store associated with the sender ID:
generate, by the first computing system, a transfer approval for the desired data transfer (¶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.”), (¶0030, “…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 ¶0142; and
transmit, by the first computing system, the transfer approval for the desired data transfer to the application executed on the user device (¶0139-¶0140, “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…”), (¶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.”).
However, DUNJIC does not explicitly disclose the following limitation:
wherein the desired data transfer is an anonymous data transfer,
accessing, by the first computing system, a second computing system via an application programming interface (API) to verify data associated with the desired data transfer comprised in a first data store of the second computing system,
Williams discloses:
wherein the data transfer is an anonymous data transfer (¶0064, “…The OCT can include the account number of the recipient and no information about the sender…”).
accessing, by the first computing system,
a second computing system via an application programming interface (API) to verify data associated with the desired data transfer comprised in a first data store of the second computing system and associated with the sender ID (¶0049-¶0052, “…The verification request message (also referred to as “a verification request”) may be in any suitable format. The verification request message can be transmitted from the server computer 108 to the wallet aggregator computer 110 via any suitable application programming interface (API) call. In some embodiments, the server computer 108 may store particular API calls to be utilized to transmit verification requests to particular wallet providers. The verification request message may request the wallet aggregator computer 110 to verify the receiver's information, such as mobile number and name. The verification request may also indicate and/or include a request for the receiver's account identifier (e.g., a PAN associated with the receiver 104).”):
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 accessing a computer system via API to verify data as disclosed by Williams and be motivated in doing so in order to increase the security of the system and thereby prevent fraudulent data transfer.
Regarding claim 15, DUNJIC discloses a non-transitory computer-readable medium comprising instructions that, when executed by one or more processors, cause the one or more processors to perform operations (¶0030, “present application describes a non-transitory computer-readable storage medium comprising processor-executable instructions which, when executed, configure a processor to…”): comprising:
receiving, by a first computing system, a transfer request from an application executed on a user device, the transfer request comprising a sender identifier (ID) and indicating a desired data transfer (¶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;…”), (¶0030, “ a non-transitory computer-readable storage medium comprising processor-executable instructions which, when executed, configure a processor to: 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.”), (¶0037, “A request to transfer is a message that is sent on behalf of a recipient to initiate a transfer from a sender to the recipient. That is, the request to transfer is sent, on behalf of the recipient, from the database management system associated with the recipient to the database management system associated with the sender. The request to transfer requests a transfer from a record in the database that is associated with the sender to a record in the database that is associated with the recipient. 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. The identifier(s) may be or include an account number. The request to transfer may also include one or more identifiers that identify the database management system associated with the sender and/or that identify the database management system associated with the recipient. Such identifiers may be or include one or more of: a transit number and an institution number.”) and indicating a desired data transfer (¶0095-¶0103, “…identification information of the type of data transfer proposal (e.g. payment, or request for payment)…”);
accessing, by the first computing system, a second computing system to verify data associated with the desired data transfer comprised in a first data store of the second computing system and associated with the sender ID (¶0037, “… the request to transfer is sent, on behalf of the recipient, from the database management system associated with the recipient to the database management system associated with the sender. The request to transfer requests a transfer from a record in the database that is associated with the sender to a record in the database that is associated with the recipient. 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…”), (¶0104, “The data store 600 may further store data regarding an account holder in a user account object 604. A user account object 604 may be a data structure and may include details regarding an individual or entity holding an account or other logical storage area. Example details include a user account identifier indicating a particular person or entity, identification information (e.g. first and last name), an alias (e.g. email address, phone number), contact information (e.g. home address), date of birth, date of incorporation, and sign in or authentication credentials (e.g. user name, password, access card number). The account holder may be or represent a transferor, recipient, payor, payee, customer or user.”), (¶0042, “…the database management system that receives the request to transfer message may be configured to execute a process for obtaining authorization to complete a transfer in response to receiving the request to transfer... 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.”), (¶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.”);
in response to verifying the data comprised in the first data store associated with the sender ID:
generating, by the first computing system, a transfer approval for the desired data transfer (¶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.”), (¶0030, “…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 ¶0142; and
transmitting, by the first computing system, the transfer approval for the desired data transfer to the application executed on the user device (¶0139-¶0140, “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…”), (¶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.”).
However, DUNJIC does not explicitly disclose the following limitation:
accessing, by the first computing system, a second computing system via an application programming interface (API) to verify data associated with the desired data transfer comprised in a first data store of the second computing system,
Williams discloses:
wherein the data transfer is an anonymous data transfer (¶0064, “…The OCT can include the account number of the recipient and no information about the sender…”).
accessing, by the first computing system, a second computing system via an application
programming interface (API) to verify data associated with the desired data transfer comprised in a first data store of the second computing system and associated with the sender ID (¶0049-¶0052, “…The verification request message (also referred to as “a verification request”) may be in any suitable format. The verification request message can be transmitted from the server computer 108 to the wallet aggregator computer 110 via any suitable application programming interface (API) call. In some embodiments, the server computer 108 may store particular API calls to be utilized to transmit verification requests to particular wallet providers. The verification request message may request the wallet aggregator computer 110 to verify the receiver's information, such as mobile number and name. The verification request may also indicate and/or include a request for the receiver's account identifier (e.g., a PAN associated with the receiver 104).”):
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 accessing a computer system via API to verify data as disclosed by Williams and be motivated in doing so in order to increase the security of the system and thereby prevent fraudulent data transfer.
Regarding claim 2, DUNJIC in view of Williams discloses the method of claim 1.
DUNJIC further discloses further comprising:
receiving, by the first computing system, an acceptance packet from the application executed on the user device, the acceptance packet comprising a recipient ID and indicating that the desired data transfer is accepted (¶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…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.”), (¶0043-¶0044, “…The notification may include a selectable option to authorize the transfer… 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…”);
transmitting, by the first computing system, transfer data indicating that the data associated with the desired data transfer is to be transferred from the first data store to a second data store, the second data store associated with the recipient ID (¶0037, “…the request to transfer is sent, on behalf of the recipient, from the database management system associated with the recipient to the database management system associated with the sender. The request to transfer requests a transfer from a record in the database that is associated with the sender to a record in the database that is associated with the recipient. 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. The identifier(s) may be or include an account number. The request to transfer may also include one or more identifiers that identify the database management system associated with the sender and/or that identify the database management system associated with the recipient. Such identifiers may be or include one or more of: a transit number and an institution number.”);
receiving, by the first computing system, a confirmation packet from the second computing system, the confirmation packet indicating that the desired data transfer has been completed (¶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.”); and
transmitting, by the first computing system, the confirmation packet to the application executed on the user device (¶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.”), (¶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.”).
Regarding claim 9, DUNJIC in view of Williams discloses the system of claim 8.
DUNJIC further discloses wherein the system further performs operations to:
receive, by the first computing system, an acceptance packet from the application executed on the user device, the acceptance packet comprising a recipient ID and indicating that the desired data transfer is accepted (¶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…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.”), (¶0043-¶0044, “…The notification may include a selectable option to authorize the transfer… 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…”);
transmit, by the first computing system, transfer data indicating that the data associated with the desired data transfer is to be transferred from the first data store to a second data store, the second data store associated with the recipient ID (¶0037, “…the request to transfer is sent, on behalf of the recipient, from the database management system associated with the recipient to the database management system associated with the sender. The request to transfer requests a transfer from a record in the database that is associated with the sender to a record in the database that is associated with the recipient. 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. The identifier(s) may be or include an account number. The request to transfer may also include one or more identifiers that identify the database management system associated with the sender and/or that identify the database management system associated with the recipient. Such identifiers may be or include one or more of: a transit number and an institution number.”);
receive, by the first computing system, a confirmation packet from the second computing system, the confirmation packet indicating that the desired data transfer has been completed (¶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.”); and
transmit, by the first computing system, the confirmation packet to the application executed on the user device (¶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.”), (¶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.”).
Regarding claim 16, DUNJIC in view of Williams discloses the non-transitory computer-readable medium of claim 15.
the operations further comprising:
receiving, by the first computing system, an acceptance packet from the application executed on the user device, the acceptance packet comprising a recipient ID and indicating that the desired data transfer is accepted (¶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…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.”), (¶0043-¶0044, “…The notification may include a selectable option to authorize the transfer… 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…”);
transmitting, by the first computing system, data indicating that the data associated with the desired data transfer is to be transferred from the first data store to a second data store, the second data store associated with the recipient ID (¶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.”), (¶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.”);
receiving, by the first computing system, a confirmation packet from the second computing system, the confirmation packet indicating that the desired data transfer has been completed; and transmitting, by the first computing system, the confirmation packet to the application executed on the user device (¶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.”), (¶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.”).
Regarding claim 3, DUNJIC in view of Williams discloses the method of claim 2.
DUNJIC further discloses wherein the confirmation packet comprises public usernames associated with the sender ID and/or the recipient ID (¶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.”), (¶0104, “…details include a user account identifier indicating a particular person or entity, identification information (e.g. first and last name), an alias (e.g. email address, phone number), contact information (e.g. home address), date of birth, date of incorporation, and sign in or authentication credentials (e.g. user name, password, access card number). The account holder may be or represent a transferor, recipient, payor, payee, customer or user.”).
Regarding claim 10, DUNJIC in view of Williams discloses the system of claim 9.
DUNJIC further discloses wherein the confirmation packet comprises public usernames associated with the sender ID and/or the recipient ID (¶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.”), (¶0104, “…details include a user account identifier indicating a particular person or entity, identification information (e.g. first and last name), an alias (e.g. email address, phone number), contact information (e.g. home address), date of birth, date of incorporation, and sign in or authentication credentials (e.g. user name, password, access card number). The account holder may be or represent a transferor, recipient, payor, payee, customer or user.”).
Regarding claim 17, DUNJIC in view of Williams discloses the method of claim 16.
DUNJIC further discloses wherein the confirmation packet comprises public usernames associated with the sender ID and/or the recipient ID (¶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.”), (¶0104, “…details include a user account identifier indicating a particular person or entity, identification information (e.g. first and last name), an alias (e.g. email address, phone number), contact information (e.g. home address), date of birth, date of incorporation, and sign in or authentication credentials (e.g. user name, password, access card number). The account holder may be or represent a transferor, recipient, payor, payee, customer or user.”).
Regarding claim 4, DUNJIC in view of Williams discloses the method of claim 2.
DUNJIC further discloses further comprising: verifying, by the first computing system, the recipient ID via an authentication service in (¶0042 and ¶0138).
Williams further discloses verifying, by the first computing system, the recipient ID via an authentication service accessed via a second API (¶0052, “The verification request message (also referred to as “a verification request”) may be in any suitable format. The verification request message can be transmitted from the server computer 108 to the wallet aggregator computer 110 via any suitable application programming interface (API) call. In some embodiments, the server computer 108 may store particular API calls to be utilized to transmit verification requests to particular wallet providers. The verification request message may request the wallet aggregator computer 110 to verify the receiver's information, such as mobile number and name. The verification request may also indicate and/or include a request for the receiver's account identifier (e.g., a PAN associated with the receiver 104).”), ¶0059.
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 Williams to include verifying the recipient ID via API as disclosed by Williams and be motivated in doing so in order to prevent data from being transferred to wrong recipients/receivers.
Regarding claim 11, DUNJIC in view of Williams discloses the system of claim 9.
DUNJIC further discloses further comprising: verifying, by the first computing system, the recipient ID via an authentication service (¶0042 and ¶0138).
Williams further discloses verifying, by the first computing system, the recipient ID via an authentication service accessed via a second API (¶0052, “The verification request message (also referred to as “a verification request”) may be in any suitable format. The verification request message can be transmitted from the server computer 108 to the wallet aggregator computer 110 via any suitable application programming interface (API) call. In some embodiments, the server computer 108 may store particular API calls to be utilized to transmit verification requests to particular wallet providers. The verification request message may request the wallet aggregator computer 110 to verify the receiver's information, such as mobile number and name. The verification request may also indicate and/or include a request for the receiver's account identifier (e.g., a PAN associated with the receiver 104).”), ¶0059.
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 Williams to include verifying the recipient ID via API as disclosed by Williams and be motivated in doing so in order to prevent data from being transferred to wrong recipients/receivers.
Regarding claim 18, DUNJIC in view of Williams discloses the non-transitory computer-readable medium of claim 16.
DUNJIC further discloses further comprising: verifying, by the first computing system, the recipient ID via an authentication service (¶0042 and ¶0138).
Williams further discloses verifying, by the first computing system, the recipient ID via an authentication service accessed via a second API (¶0052, “The verification request message (also referred to as “a verification request”) may be in any suitable format. The verification request message can be transmitted from the server computer 108 to the wallet aggregator computer 110 via any suitable application programming interface (API) call. In some embodiments, the server computer 108 may store particular API calls to be utilized to transmit verification requests to particular wallet providers. The verification request message may request the wallet aggregator computer 110 to verify the receiver's information, such as mobile number and name. The verification request may also indicate and/or include a request for the receiver's account identifier (e.g., a PAN associated with the receiver 104).”), ¶0059.
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 Williams to include verifying the recipient ID via API as disclosed by Williams and be motivated in doing so in order to prevent data from being transferred to wrong recipients/receivers.
Regarding claim 5, DUNJIC in view of Williams discloses the method of claim 1.
Williams further discloses further comprising: verifying, by the first computing system, the sender ID via an authentication service accessed via a second API (¶0059, “… In some embodiments, the processing network computer 114 (e.g., performing a Verified by Visa Service) may authenticate the sender 102. In some embodiments, for security reasons, it may be preferable that only fully authenticated transactions are supported.”), (¶0075, “…The verification request message can be transmitted via any suitable application programming interface (API) call. In some embodiments, the processing network computer 114 may store particular API calls to be utilized to transmit verification requests to particular wallet providers.”), (¶0079, “…The confirmation request may comprise the mobile number and the name. In some embodiments, the confirmation request may comprise additional data such as an address, an email address, a country, a wallet identifier, a username, and/or the like depending on the transfer data provided at step 1. The information transmitted in the confirmation request may be provided to the sender 102 via user interface 120.”).
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 Williams to include verifying the sender’s ID via API as disclosed by Williams and be motivated in doing so in order to increase transaction security by supporting only fully authenticated transactions-Williams ¶0059 in parts.
Regarding claim 12, DUNJIC in view of Williams discloses the system of claim 8.
Williams further discloses further comprising: verifying, by the first computing system, the sender ID via an authentication service accessed via a second API (¶0059, “… In some embodiments, the processing network computer 114 (e.g., performing a Verified by Visa Service) may authenticate the sender 102. In some embodiments, for security reasons, it may be preferable that only fully authenticated transactions are supported.”), (¶0075, “…The verification request message can be transmitted via any suitable application programming interface (API) call. In some embodiments, the processing network computer 114 may store particular API calls to be utilized to transmit verification requests to particular wallet providers.”), (¶0079, “…The confirmation request may comprise the mobile number and the name. In some embodiments, the confirmation request may comprise additional data such as an address, an email address, a country, a wallet identifier, a username, and/or the like depending on the transfer data provided at step 1. The information transmitted in the confirmation request may be provided to the sender 102 via user interface 120.”).
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 Williams to include verifying the sender’s ID via API as disclosed by Williams and be motivated in doing so in order to increase transaction security by supporting only fully authenticated transactions-Williams ¶0059 in parts.
Regarding claim 19, DUNJIC in view of Williams discloses the non-transitory computer-readable medium of claim 15.
Williams further discloses further comprising: verifying, by the first computing system, the sender ID via an authentication service accessed via a second API (¶0059, “… In some embodiments, the processing network computer 114 (e.g., performing a Verified by Visa Service) may authenticate the sender 102. In some embodiments, for security reasons, it may be preferable that only fully authenticated transactions are supported.”), (¶0075, “…The verification request message can be transmitted via any suitable application programming interface (API) call. In some embodiments, the processing network computer 114 may store particular API calls to be utilized to transmit verification requests to particular wallet providers.”), (¶0079, “…The confirmation request may comprise the mobile number and the name. In some embodiments, the confirmation request may comprise additional data such as an address, an email address, a country, a wallet identifier, a username, and/or the like depending on the transfer data provided at step 1. The information transmitted in the confirmation request may be provided to the sender 102 via user interface 120.”).
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 Williams to include verifying the sender’s ID via API as disclosed by Williams and be motivated in doing so in order to increase transaction security by supporting only fully authenticated transactions-Williams ¶0059 in parts.
Regarding claim 6, DUNJIC in view of Williams discloses the method of claim 1.
Williams further discloses wherein the desired data transfer is an anonymous data transfer (¶0064, “…The OCT can include the account number of the recipient and no information about the sender…”).
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 Williams to include anonymous data transfer as disclosed by Williams and be motivated in doing so in order not to expose users’ private data to strangers.
Regarding claim 13, DUNJIC in view of Williams discloses the system of claim 8. Williams further discloses wherein the desired data transfer is an anonymous data transfer (¶0064, “…The OCT can include the account number of the recipient and no information about the sender…”).
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 Williams to include anonymous data transfer as disclosed by Williams and be motivated in doing so in order not to expose users’ private data to strangers.
Regarding claim 20, DUNJIC in view of Williams discloses the non-transitory computer-readable medium of claim 15.
Williams further discloses wherein the desired data transfer is an anonymous data transfer (¶0064, “…The OCT can include the account number of the recipient and no information about the sender…”).
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 Williams to include anonymous data transfer as disclosed by Williams and be motivated in doing so in order not to expose users’ private data to strangers.
Claims 7 and 14 are rejected under 35 U.S.C. 103 as being unpatentable over PGPub. No. 20230060707 to DUNJIC et al (hereinafter DUNJIC) in view of PGPub. No. 20210365942 to Williams; Otto (hereinafter Williams) and further in view of PGPub. No. 20150319144 to Barton et al. (hereinafter Barton).
Regarding claim 7, DUNJIC in view of Williams discloses the method of claim 1.
However, DUNJIC in view of Williams does not explicitly disclose the following limitation:
wherein the first computing system is configured to communicate with a secure partition of the user device.
Barton discloses wherein the first computing system is configured to communicate with a secure partition of the user device (¶0050, “The secure applications may access data stored in a secure data container 328 in the managed partition 310 of the mobile device...”), see also ¶0124, ¶0136, ¶0138 to mention just a few.
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 Williams to include first computing system is configured to communicate with a secure partition of the user device as disclosed by Barton and be motivated in doing so in order to ensure confidentiality, integrity, and authenticity of the data being transferred.
Regarding claim 14, DUNJIC in view of Williams discloses the system of claim 8.
However, DUNJIC in view of Williams does not explicitly disclose the following limitation:
wherein the first computing system is configured to communicate with a secure partition of the user device.
Barton discloses wherein the first computing system is configured to communicate with a secure partition of the user device (¶0050, “The secure applications may access data stored in a secure data container 328 in the managed partition 310 of the mobile device...”), see also ¶0124, ¶0136, ¶0138 to mention just a few.
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 Williams to include first computing system is configured to communicate with a secure partition of the user device as disclosed by Barton and be motivated in doing so in order to ensure confidentiality, integrity, and authenticity of the data being transferred.
Conclusion
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