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 .
Election/Restrictions
Applicant’s election without traverse of Group III in the reply filed on May 19, 2025, is acknowledged.
Information Disclosure Statement
The information disclosure statement(s) (IDS) submitted on October 17, 2023, is/are in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement(s) has/have been considered by the examiner.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 18-37 are rejected under 35 U.S.C. 101 because the claimed invention is directed to abstract ideas without significantly more. There are two criteria for subject matter eligibility. The first is that the claimed invention must be to one of the four statutory categories, i.e., a process, machine, manufacture, or composition of matter. See MPEP 2106(I). Second, the claimed invention also must qualify as patent-eligible subject matter, i.e., the claim must not be directed to a judicial exception unless the claim as a whole includes additional limitations amounting to significantly more than the exception. See MPEP 2106(I). Here, claims 18-37 are directed towards a machine. Therefore, the analysis proceeds to determine whether the claims recite abstract ideas.
Per Claim 18: Claim 18, as a whole, is directed towards the abstract idea of generating a transaction request with recipient authentication information. In particular, the claim recites receiving an encryption key and using the encryption key to generate an encrypted transaction. The system generates a model hash key including an answer to a challenge, a payor identifier, and payee identifier. The claim transmits the encrypted transaction and model hash key to an authentication entity and receives a notification from the authentication entity of a confirmation of a successful validation or failed validation. In other words, the claim recites Certain Methods of Organizing Human Activities recognized as reciting abstract ideas. More specifically, the following underlined claim elements recite abstract ideas while the non-underlined claim elements recite additional elements according to MPEP 2106.04(a).
a processor and a memory storing instructions, the instructions executable by the processor to:
send a request to an authentication server for a public key of a recipient account or device;
receive the public key from the authentication server;
encrypt a transaction to generate an encrypted message, wherein the encrypted message comprises a challenge, the public key of the recipient account or device, and transaction details;
generate a model hash key, the model hash key comprising a model answer to the challenge, an initiator user account identifier, and a recipient user account identifier; and
transmit the encrypted message and the model hash key to the authentication server; and
receive a notification from the authentication server, wherein the notification comprises at least one of a confirmation of a successful validation or a failed validation.
Because the claim recites abstract ideas, the analysis proceeds to determine whether the claim recites additional elements that recite a practical application of the abstract ideas. According to MPEP 2106.04(d), additional elements that recite an instruction to apply the abstract ideas using a computer, that recite insignificant extra-solution activities, or that generally link the use of the abstract ideas to a particular technological environment or field of use are not indicative of a practical application. Here, the additional elements of a processor, memory, and server are used to implement the abstract ideas using computers. In other words, these additional elements are instructions to apply the abstract ideas using computers. Therefore, the claim as a whole fails to recite a practical application of the abstract ideas.
The analysis then proceeds to determine whether the additional elements, when considered individually and in combination, recite significantly more than the abstract ideas. According to MPEP 2106.05, additional elements that recite an instructions to apply the abstract ideas using a computer, that recite insignificant extra-solution activities, that generally link the use of the abstract ideas to a particular technological environment or field of use, or that recite well-understood, routine, and conventional activities are not indicative of reciting significantly more than the abstract ideas. Claim elements previously considered to recite insignificant extra-solution activities are reevaluated at this step to determine whether they recite well-understood, routine, and conventional activities. Such findings must be supported by the evidentiary requirements set forth in the Berkheimer Memo. Here, the additional elements of a processor, memory, and server are used to implement the abstract ideas using computers. In other words, these additional elements are instructions to apply the abstract ideas using computers. Therefore, the additional claim elements, when considered individually and in combination, fail to recite significantly more than the abstract ideas.
Accordingly, claim 18 is rejected as being directed towards patent ineligible subject matter.
Per Claims 19-37: Claims 19-37 have also been analyzed for subject matter eligibility. However, these claims also fail to recite patent eligible subject matter for the following reasons:
Claim 19 recites the abstract idea of transferring funds from an initiator user account to an escrow account, which is a Certain Method of Organizing Human Activities.
Claim 20 recites the abstract idea that the transaction details include amount of funds sent, amount of funds requested, type of funds send, type of funds requested, currency, bank account details, payment platform details, or transaction type, which is a Certain Method of Organizing Human Activities.
Claim 21 recites the abstract idea of transferring funds from the escrow account to a recipient account based on a successful validation, which is a Certain Method of Organizing Human Activities.
Claim 22 recites the abstract idea of transferring funds from the escrow account to an initiator account based on a failed validation, which is a Certain Method of Organizing Human Activities.
Claim 23 recites the abstract idea that a successful validation is based on a match between the model answer and response from the recipient account within a time limit, which is a Certain Method of Organizing Human Activities.
Claim 24 recites the abstract idea that a successful validation is based on a response from the recipient account satisfying an accuracy threshold corresponding to the model answer, which is a Certain Method of Organizing Human Activities.
Claim 25 recites the abstract idea that a failed validation is based on an absence of a match between the model answer and response from the recipient account within a time limit, which is a Certain Method of Organizing Human Activities.
Claim 26 recites the abstract idea of generating a second encrypted message and a second model hash key, i.e., a second transaction, which is a Certain Method of Organizing Human Activities.
Claim 27 recites the abstract idea of that the first encrypted message and model hash key correspond to a first transaction and the second encrypted message and model hash key correspond to a second transaction, which is a Certain Method of Organizing Human Activities.
Claim 28 recites the abstract idea that the first transaction is a pseudo transaction and the second transaction is a real transaction, which is a Certain Method of Organizing Human Activities.
Claim 29 recites the abstract idea that the first and second transactions are real transactions, which is a Certain Method of Organizing Human Activities.
Claim 30 recites the abstract idea that the two encrypted messages are identical and the two model hash keys are identical, which is a Certain Method of Organizing Human Activities.
Claim 31 recites the abstract idea that the two encrypted messages are different and the two model hash keys are different, which is a Certain Method of Organizing Human Activities.
Claim 32 recites the abstract idea that the recipient or the authentication entity store the public encryption key, which is a Certain Method of Organizing Human Activities.
Claim 33 recites the abstract idea that the encrypted message and model hash key are stored by the authentication entity, which is a Certain Method of Organizing Human Activities.
Claim 34 recites the abstract idea that the encrypted message and model hash key are stored for a certain amount of time, which is a Certain Method of Organizing Human Activities.
Claim 35 recites the abstract idea that the transaction is completed based on a successful validation and the transaction is canceled based on a failed validation, which is a Certain Method of Organizing Human Activities.
Claim 36 recites the abstract idea that a transaction is completed based on a successful negotiation between the client and recipient, which is a Certain Method of Organizing Human Activities.
Claim 37 recites the abstract idea that a transaction is canceled based on an unsuccessful negotiation between the client and recipient, which is a Certain Method of Organizing Human Activities.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claim(s) 18-33 and 35 is/are rejected under 35 U.S.C. 103 as being unpatentable over U.S. Patent Pub. No. 2010/0106644 to Annan et al. in view of U.S. Patent No. 10,057,061 to Maeng et al., U.S. Patent Pub. No. 2011/0125644 to Fleishman et al., and U.S. Patent Pub. No. 2016/0342976 to Davis.
Per Claim 18: Annan discloses:
A client device to initiate and conduct secure peer to peer payments, the client device comprising a processor and a memory storing instructions, the instructions executable by the processor to: (see Annan at ¶ 48: he mobile device 20 also includes memory 68 for storing an operating system that controls the main functionality of the mobile device 20, along with a number of applications that are run on the mobile device 20, and data. A processor 72 executes the operating system and applications.)
encrypt a transaction to generate an encrypted message, wherein the encrypted message comprises [[a challenge, the public key of the recipient account or device]], and transaction details; (see Annan at ¶ 59: Once the transfer authorization application on the mobile device 20 has generated the OTP, it encrypts and sends the transfer request to the mobile transaction server 32. The transfer request includes the transfer information (i.e., the recipient's name and telephone number, and the transfer amount and currency), the OTP and the telephone number associated with the mobile device 20.)
generate a model hash key, the model hash key comprising [[a model answer to the challenge]], an initiator user account identifier, and a recipient user account identifier; and (see Annan at ¶ 59: The transfer request includes the transfer information (i.e., the recipient's name and telephone number, and the transfer amount and currency), the OTP and the telephone number associated with the mobile device 20.)
transmit the encrypted message and the model hash key to the authentication server; and (see Annan at ¶ 59: The transfer authorization module transmits the encrypted transfer request using a wireless bearer system such as User Datagram Protocol (“UDP”) to a proximate one of the cellular base stations 24 for forwarding to the mobile transaction server 32.)
receive a notification from the authentication server, wherein the notification comprises at least one of a confirmation of a successful validation or a failed validation. (see Annan at ¶ 71: Once the transfer is complete, the mobile transaction server sends a transfer completion notice to the mobile devices 20 of both the transferor and the transferee (step 210).)
However, Annan fails to disclose but Maeng, an analogous art of public key encryption, discloses:
send a request to an authentication server for a public key of a recipient account or device; (see Maeng at 8:21-25: At operation 6020 the MTA may contact a Domain Name Server (DNS) for the IP address of the Public Key Server (PKS) of the recipient mobile wallet domain. At operation 6030 the MTA sends a request to the PKS of the recipient's mobile wallet domain.)
receive the public key from the authentication server; (see Maeng at 8:25-27: At operation 6040 the MTA receives the public key from the PKS. At operation 6050 the MTA sends this public key to the MUA.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Annan so that the mobile device retrieves a public key of the recipient of the transaction using the techniques disclosed in Maeng. One of ordinary skill in the art would have been motivated to do so to increase the security of the system.
However, the combination of Annan and Maeng fails to disclose but Fleishman, an analogous art of transaction recipient verification, discloses:
the encrypted message comprises a challenge (see Fleishman at ¶ 91: To add an additional security measure to validate the recipient before fluids are disbursed, the customer can create one or more challenge-response questions and provide the requisite answers as shown at 911 in FIG. 9 b.)
generate a model hash key, the model hash key comprising a model answer to the challenge (see Fleishman at ¶ 91: To add an additional security measure to validate the recipient before fluids are disbursed, the customer can create one or more challenge-response questions and provide the requisite answers as shown at 911 in FIG. 9 b.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Annan so that the payer generates a challenge-response using the techniques disclosed in Fleishman. One of ordinary skill in the art would have been motivated to do so to increase the security of the transactions.
However, the combination of Annan, Maeng, and Fleishman fails to disclose but Davis, an analogous art of peer-to-peer transactions, discloses:
wherein the encrypted message comprises the public key of the recipient account or device (see Davis at ¶ 79: The transaction request may include at least a network identifier associated with a blockchain network 106, a transaction amount for a blockchain currency associated with the blockchain network 106, and a public key and/or an address identifier associated with a payee 104.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Annan so that the transfer request includes a public key of the payee using the teachings disclosed in Davis. One of ordinary skill in the art would have been motivated to do so to ensure the transfer is addressed to the correct payee.
Per Claim 19: The combination of Annan, Maeng, Fleishman, and Davis discloses the subject matter of claim 18, from which claim 19 depends. Annan further discloses:
cause a transfer of funds from an initiator user financial account to an escrow account, wherein the escrow account is associated or in communication with the authentication server. (see Annan at ¶ 70: If, instead, the validation of the OTP is successful, the mobile transaction server 32 transfers the transfer amount from the escrow account to the account of the recipient (step 200).)
Per Claim 20: The combination of Annan, Maeng, Fleishman, and Davis discloses the subject matter of claim 18, from which claim 20 depends. Annan further discloses:
wherein the transaction details comprise at least one of an amount of funds to be sent, amount of funds requested, type of funds to be sent, type of funds requested, currency, bank account details, peer to peer platform account details, or a transaction type. (see Annan at ¶ 59: Once the transfer authorization application on the mobile device 20 has generated the OTP, it encrypts and sends the transfer request to the mobile transaction server 32. The transfer request includes the transfer information (i.e., the recipient's name and telephone number, and the transfer amount and currency), the OTP and the telephone number associated with the mobile device 20.)
Per Claim 21: The combination of Annan, Maeng, Fleishman, and Davis discloses the subject matter of claim 19, from which claim 21 depends. Annan further discloses:
wherein the funds in the escrow account are transferred to the recipient account based on a successful validation. (see Annan at ¶ 70: If, instead, the validation of the OTP is successful, the mobile transaction server 32 transfers the transfer amount from the escrow account to the account of the recipient (step 200).)
Per Claim 22: The combination of Annan, Maeng, Fleishman, and Davis discloses the subject matter of claim 19, from which claim 22 depends. Annan further discloses:
wherein the funds in the escrow account are transferred to an initiator account based on a failed validation. (see Annan at ¶ 72: If a transfer is commenced by a transferor but not completed by the recipient within a set period of time, the mobile transaction server 32 performs a “fail-back” transaction reversal by transferring the amount held in the escrow account back to the transferor's account.)
Per Claim 23: The combination of Annan, Maeng, Fleishman, and Davis discloses the subject matter of claim 18, from which claim 23 depends. Annan further discloses:
wherein a successful validation is based on a match [[between the model answer and a response from the recipient account or device]] occurring within a validation time limit. (see Annan at ¶ 61: The OATH validation server 36 validates the OTP using the credentials and counter associated with the TokenID passed on by the mobile transaction server 32 using the OATH standard validation methodology. See also ¶ 33: The transferring can include transferring said transfer amount to said second account if said confirmation reply confirms said transfer within a pre-set period of time.)
However, the combination of Annan and Maeng fails to disclose but Fleishman discloses:
wherein a successful validation is based on a match between the model answer and a response from the recipient account or device (see Fleishman at ¶ 79: c) Receiving payments: The recipient must authenticate and correctly answer one or more challenge-response questions before the retrieval of funds is allowed. The partner institution controls the number and type of challenge-response questions the payee must answer before the relationship is authenticated.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Annan so that the validation is based on a response received from the payee using the techniques disclosed in Fleishman. One of ordinary skill in the art would have been motivated to do so to increase the security of the transaction.
Per Claim 24: The combination of Annan, Maeng, Fleishman, and Davis discloses the subject matter of claim 18, from which claim 24 depends. However, the combination of Annan and Maeng fails to disclose but Fleishman discloses:
wherein a successful validation is based on a response from the recipient account satisfying an accuracy threshold corresponding to the model answer. (see Fleishman at ¶ 79: c) Receiving payments: The recipient must authenticate and correctly answer one or more challenge-response questions before the retrieval of funds is allowed. The partner institution controls the number and type of challenge-response questions the payee must answer before the relationship is authenticated.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Annan so that the validation is based on a response received from the payee using the techniques disclosed in Fleishman. One of ordinary skill in the art would have been motivated to do so to increase the security of the transaction.
Per Claim 25: The combination of Annan, Maeng, Fleishman, and Davis discloses the subject matter of claim 18, from which claim 25 depends. Annan further discloses:
wherein a failed validation is based on an absence of a match [[between the model answer and a response from the recipient account or device]] occurring within a validation time limit. (see Annan at ¶ 72: If a transfer is commenced by a transferor but not completed by the recipient within a set period of time, the mobile transaction server 32 performs a “fail-back” transaction reversal by transferring the amount held in the escrow account back to the transferor's account.)
However, the combination of Annan and Maeng fails to disclose but Fleishman discloses:
wherein a failed validation is based on an absence of a match between the model answer and a response from the recipient account or device (see Fleishman at ¶ 79: c) Receiving payments: The recipient must authenticate and correctly answer one or more challenge-response questions before the retrieval of funds is allowed. The partner institution controls the number and type of challenge-response questions the payee must answer before the relationship is authenticated.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Annan so that the validation is based on a response received from the payee using the techniques disclosed in Fleishman. One of ordinary skill in the art would have been motivated to do so to increase the security of the transaction.
Per Claim 26: The combination of Annan, Maeng, Fleishman, and Davis discloses the subject matter of claim 18, from which claim 26 depends. Annan further discloses:
wherein the encrypted message is a first encrypted message, wherein the model hash key is a first model hash key, and wherein the instructions are further executable by the processor to: (see Annan at ¶ 59: Once the transfer authorization application on the mobile device 20 has generated the OTP, it encrypts and sends the transfer request to the mobile transaction server 32. The transfer request includes the transfer information (i.e., the recipient's name and telephone number, and the transfer amount and currency), the OTP and the telephone number associated with the mobile device 20.)
generate a second encrypted message, the second encrypted message comprising [[a new challenge, the public key of the recipient account or device]], and transaction details; and (see Annan at ¶ 59: Once the transfer authorization application on the mobile device 20 has generated the OTP, it encrypts and sends the transfer request to the mobile transaction server 32. The transfer request includes the transfer information (i.e., the recipient's name and telephone number, and the transfer amount and currency), the OTP and the telephone number associated with the mobile device 20.
generate a second model hash key, the second model hash key comprising [[a new model answer to the new challenge]], an initiator user account identifier, and a recipient user account identifier. (see Annan at ¶ 59: The transfer request includes the transfer information (i.e., the recipient's name and telephone number, and the transfer amount and currency), the OTP and the telephone number associated with the mobile device 20.)
However, the combination of Annan and Maeng fails to disclose but Fleishman discloses:
the second encrypted message comprising a new challenge (see Fleishman at ¶ 91: To add an additional security measure to validate the recipient before fluids are disbursed, the customer can create one or more challenge-response questions and provide the requisite answers as shown at 911 in FIG. 9 b.)
generate a second model hash key, the second model hash key comprising a new model answer to the new challenge (see Fleishman at ¶ 91: To add an additional security measure to validate the recipient before fluids are disbursed, the customer can create one or more challenge-response questions and provide the requisite answers as shown at 911 in FIG. 9 b.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Annan so that the payer generates a challenge-response for multiple transactions using the techniques disclosed in Fleishman. One of ordinary skill in the art would have been motivated to do so to increase the security of the transactions.
However, the combination of Annan, Maeng, and Fleishman fails to disclose but Davis discloses:
the second encrypted message comprising the public key of the recipient account or device (see Davis at ¶ 79: The transaction request may include at least a network identifier associated with a blockchain network 106, a transaction amount for a blockchain currency associated with the blockchain network 106, and a public key and/or an address identifier associated with a payee 104.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Annan so that the transfer request includes a public key of the payee using the teachings disclosed in Davis. One of ordinary skill in the art would have been motivated to do so to ensure the transfer is addressed to the correct payee.
Per Claim 27: The combination of Annan, Maeng, Fleishman, and Davis discloses the subject matter of claim 26 from which claim 27 depends. Annan further discloses:
wherein the first encrypted message and the first model hash key correspond to a first transaction, and wherein the second encrypted message and the second model hash key correspond to a second transaction. (see Annan at ¶ 59: Returning to FIG. 3, once the transferor enters the transfer information and activates the transfer button 432, the mobile device 20 generates and sends a transfer request to the mobile transaction server 32 (step 120). In order to enable authentication of the transfer, the transfer authorization software generates an OTP for the transfer. In particular, the transfer authorization application uses the stored counter and credential received during the setup of the transfer authorization application to generate the OTP using the standard OATH algorithm, as set out in IETF “HOTP: An HMAC-Based OTP Algorithm (RFC 4226)”.)
Per Claim 28: The combination of Annan, Maeng, Fleishman, and Davis discloses the subject matter of claim 27, from which claim 28 depends. Annan further discloses:
wherein the first transaction is a pseudo transaction, and wherein the second transaction is a real transaction. (see Annan at ¶ 59: Returning to FIG. 3, once the transferor enters the transfer information and activates the transfer button 432, the mobile device 20 generates and sends a transfer request to the mobile transaction server 32 (step 120). In order to enable authentication of the transfer, the transfer authorization software generates an OTP for the transfer. In particular, the transfer authorization application uses the stored counter and credential received during the setup of the transfer authorization application to generate the OTP using the standard OATH algorithm, as set out in IETF “HOTP: An HMAC-Based OTP Algorithm (RFC 4226)”.)
Per Claim 29: The combination of Annan, Maeng, Fleishman, and Davis discloses the subject matter of claim 27, from which claim 29 depends. Annan further discloses:
wherein the first transaction is a first real transaction, and wherein the second transaction is a second real transaction. (see Annan at ¶ 59: Returning to FIG. 3, once the transferor enters the transfer information and activates the transfer button 432, the mobile device 20 generates and sends a transfer request to the mobile transaction server 32 (step 120). In order to enable authentication of the transfer, the transfer authorization software generates an OTP for the transfer. In particular, the transfer authorization application uses the stored counter and credential received during the setup of the transfer authorization application to generate the OTP using the standard OATH algorithm, as set out in IETF “HOTP: An HMAC-Based OTP Algorithm (RFC 4226)”.)
Per Claim 30: The combination of Annan, Maeng, Fleishman, and Davis discloses the subject matter of claim 26, from which claim 30 depends. Annan further discloses:
wherein the first encrypted message is identical to the second encrypted message, and wherein the first model hash key is identical to the second model hash key. (see Annan at ¶ 59: Returning to FIG. 3, once the transferor enters the transfer information and activates the transfer button 432, the mobile device 20 generates and sends a transfer request to the mobile transaction server 32 (step 120). In order to enable authentication of the transfer, the transfer authorization software generates an OTP for the transfer. In particular, the transfer authorization application uses the stored counter and credential received during the setup of the transfer authorization application to generate the OTP using the standard OATH algorithm, as set out in IETF “HOTP: An HMAC-Based OTP Algorithm (RFC 4226)”.)
Claim 30 recites that the first and second encrypted messages are identical and the first and second model hash keys are identical, i.e., they are a duplication. According to MPEP 2144.04(VI)(B), a duplication of parts is obvious.
Per Claim 31: The combination of Annan, Maeng, Fleishman, and Davis discloses the subject matter of claim 26, from which claim 31 depends. Annan further discloses:
wherein the first encrypted message is different than the second encrypted message, and wherein the first model hash key is different than the second model hash key. (see Annan at ¶ 59: Returning to FIG. 3, once the transferor enters the transfer information and activates the transfer button 432, the mobile device 20 generates and sends a transfer request to the mobile transaction server 32 (step 120). In order to enable authentication of the transfer, the transfer authorization software generates an OTP for the transfer. In particular, the transfer authorization application uses the stored counter and credential received during the setup of the transfer authorization application to generate the OTP using the standard OATH algorithm, as set out in IETF “HOTP: An HMAC-Based OTP Algorithm (RFC 4226)”.)
Per Claim 32: The combination of Annan, Maeng, Fleishman, and Davis discloses the subject matter of claim 18, from which claim 32 depends. However, the combination of Annan, Maeng, and Fleishman fails to disclose but Davis discloses:
wherein the public key is stored on at least one of the authentication server or the recipient device. (see Davis at ¶ 34: The destination address may be generated using an encryption key stored in the computing device of the payee 104. The encryption key may be part of a key pair, such as a public key corresponding to a private key stored in the computing device.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Annan so that the recipient stores his/her own public key using the techniques disclosed in Davis. One of ordinary skill in the art would have been motivated to do so to enable the payee to give the correct payee information to the payer.
Per Claim 33: The combination of Annan, Maeng, Fleishman, and Davis discloses the subject matter of claim 18, from which claim 33 depends. Annan further discloses:
wherein the encrypted message and the model hash key are stored on the authentication server. (see Annan at ¶¶ 59-60: The transfer authorization module transmits the encrypted transfer request using a wireless bearer system such as User Datagram Protocol (“UDP”) to a proximate one of the cellular base stations 24 for forwarding to the mobile transaction server 32. Upon receipt of the encrypted transfer request, the mobile transaction server 32 decrypts and validates the transfer request, and calculates the converted currency amount, if required, and service charge associated with the transfer (step 130).)
Per Claim 35: The combination of Annan, Maeng, Fleishman, and Davis discloses the subject matter of claim 18, from which claim 35 depends. Annan further discloses:
wherein a transaction is completed based on a successful validation, and wherein a transaction is canceled based on a failed validation. (see Annan at ¶ 70: If, instead, the validation of the OTP is successful, the mobile transaction server 32 transfers the transfer amount from the escrow account to the account of the recipient (step 200). If desired or required by jurisdictional laws, further non-repudiation checks and money-laundering checks can be performed before the transfer is completed. See also ¶ 72: If a transfer is commenced by a transferor but not completed by the recipient within a set period of time, the mobile transaction server 32 performs a “fail-back” transaction reversal by transferring the amount held in the escrow account back to the transferor's account.)
Claim(s) 34 is/are rejected under 35 U.S.C. 103 as being unpatentable over Annan, Maeng, Fleishman, and Davis as applied to claim 33 above, and further in view of U.S. Patent Pub. No. 2018/0114219 to Setchell et al.
Per Claim 34: The combination of Annan, Maeng, Fleishman, and Davis fails to disclose the subject matter of claim 33, from which claim 34 depends. However, the combination of Annan, Maeng, Fleishman, and Davis fails to disclose but Setchell, an analogous art of transaction validation, discloses:
wherein the encrypted message and the model hash key are stored on the authentication server for a validation time limit, and wherein the encrypted message and the model hash key are removed from the authentication server after the validation time limit. (see Setchell at ¶ 23: In another example, after a length of time passes beginning at the time at which a facial template is added to the current customer log, for example 20 minutes, if the facial template has not been used to verify an identity, the facial template is deleted from the current customer log.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Annan so that the authentication data is deleted after a period of time using the technique of deleting authentication data after a period of time disclosed in Setchell. One of ordinary skill in the art would have been motivated to do so to conserve memory resources.
Claim(s) 36-37 is/are rejected under 35 U.S.C. 103 as being unpatentable over Annan, Maeng, Fleishman, and Davis as applied to claim 33 above, and further in view of U.S. Patent Pub. No. 2016/0125460 to Zellner et al.
Per Claim 36: The combination of Annan, Maeng, Fleishman, and Davis discloses the subject matter of claim 18, from which claim 36 depends. However, the combination of Annan, Maeng, Fleishman, and Davis fails to disclose but Zellner, an analogous art of negotiating transactions, discloses:
wherein a transaction is completed based on a successful negotiation between the client device and the recipient device based on a successful validation. (see Zellner at ¶ 40: At step D, the purchasing bot 210 can present information to the user such as a purchase approval or successful negotiation with the seller bot 250, a purchase denial or unsuccessful negotiation with the seller bot, reports describing the negotiation between the purchase bot and the seller bot, and so forth.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Annan so that the transaction occurs only if the parties successfully negotiate with each other. One of ordinary skill in the art would have been motivated to do so to ensure both parties agree to the terms of the transaction.
Per Claim 37: The combination of Annan, Maeng, Fleishman, and Davis discloses the subject matter of claim 18, from which claim 37 depends. However, the combination of Annan, Maeng, Fleishman, and Davis fails to disclose but Zellner discloses:
wherein a transaction is canceled based on an unsuccessful negotiation between the client device and the recipient device based on a successful validation. (see Zellner at ¶ 40: At step D, the purchasing bot 210 can present information to the user such as a purchase approval or successful negotiation with the seller bot 250, a purchase denial or unsuccessful negotiation with the seller bot, reports describing the negotiation between the purchase bot and the seller bot, and so forth.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Annan so that the transaction is canceled when there is an unsuccessful negotiation between the parties. One of ordinary skill in the art would have been motivated to do so to ensure that a transaction does not occur if the parties do not agree to terms of the transaction.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
U.S. Patent Pub. No. 2013/0317965 discloses a computer-implemented system and method for constructing a negotiation blueprint for a business negotiation. The system and method is designed to facilitate the organized and consistent execution of the process by a single individual or team of individuals working on the negotiation. The method can be organized into two phases: analysis; and execution. The analysis consists of a structured review of the situation surrounding the negotiation from the perspective of each party or counterpart while the execution provides negotiators a structured means of presenting alternatives to the counterpart. The system is preferably a computer based program available over a network that facilitates the execution of the business method by presenting data related to typical negotiations of the type the user is executing.
U.S. Patent Pub. No. 2013/0046674 discloses systems and methods are provided for conducting securities lending transactions using an electronic trading platform. In accordance with an implementation, the electronic trading platform receives, from a trader, information identifying initial terms of a transaction to lend or borrow shares of a security. The electronic trading platform may generate an instruction to broadcast the initial terms to one or more counterparties, and may subsequently facilitate negotiations between the trader and the one or more counterparties for terms of the transaction. The electronic trading platform may execute the transaction in accordance with the negotiated terms.
U.S. Patent Pub. No. 2010/0174646 systems and methods are illustrated for performing a person-to-person funds transfer. A person-to-person funds transfer process may be divided into a funds transfer initiation process to receive the funds to be transferred and recipient information from a sender and a funds retrieval process to provide the funds to a recipient. The funds transfer initiation process may include a customizable authentication step that provides the sender an opportunity to determine the level of authentication. The funds transfer retrieval process may include determining whether the recipient is authenticated based on the authentication level chosen by the sender.
U.S. Patent Pub. No. 2003/0084003 discloses systems and methods are provided for managing the transfer of electronic files. In one embodiment, a sender transfers an encrypted version of a file (such as a digitally encoded audio track, movie, document, or the like) to someone who wishes to receive it. The receiver computes a hash of the encrypted file, and sends it to a trusted third party. The trusted third party compares the hash that was computed by the receiver with another hash computed by the sender. If the two hashes match, the third party sends the file decryption key to the receiver. In some embodiments, the receiver may also send the third party payment information so that the sender, the content owner, and/or the third party can be paid for their role in the transaction. In a preferred embodiment, the payment information is only sent to, and/or used by, the third party once the third party has confirmed to the satisfaction of the receiver that the encrypted file in the receiver's possession will decrypt correctly. In some embodiments, the sender computes a hash of the encrypted version of the file and sends it directly to the third party. In other embodiments, the sender encrypts this hash using a key associated with the third party and sends the encrypted hash to the receiver, who then forwards it to the third party.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to NILESH B KHATRI whose telephone number is (571)270-7083. The examiner can normally be reached 8:30 AM - 5:30 PM Monday-Friday, alternating Fridays off.
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, Neha Patel can be reached at (571) 270-1492. 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.
/NILESH B KHATRI/Primary Examiner, Art Unit 3699