Notice of Pre-AIA or AIA Status
1. The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
2. EXAMINER’S NOTE: The claims have been reviewed and considered under the new guidance pursuant to the 2019 Revised Patent Subject Matter Eligibility Guidance (PEG 2019) issued January 7, 2019.
3. This communication is in response to Applicant’s Amendment filed on 30 March 2026. Claims 1,11, and 20 have been amended. Claims 1-20 remain pending.
Information Disclosure Statement
4. The Information Disclosure Statement respectfully submitted on 10 April 2026 has been considered by the Examiner.
Response to Arguments
5. Applicant’s arguments, see pages 7-10, filed 20 March 2026, with respect to the rejection of claims 1-20 in view of Law et al. and Pravetz et al. has been fully considered, but are moot in view of the new grounds of rejection. In light of the newly amended claim limitations, a new ground of rejection is hereby presented in view of Shah et al. (Pub No. 2017/0374070).
6. In light of the previous double patenting rejection, the Applicant has failed to file a terminal disclaimer to overcome the rejection, therefore, the rejection will be maintained.
7. In light of the previous claim objection for claims 1, 11, and 20, the Applicant has amended the claims to overcome the objection, therefore, the claim objection has been withdrawn.
Double Patenting
8. The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The filing of a terminal disclaimer by itself is not a complete reply to a nonstatutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer.
Instant Application 18/735,899
Issued Application 12,034,851
1. A system to verify a transaction between a computing device and a resource platform, the system comprising: at least one processor; and memory storing instructions that, when executed by the at least one processor, causes the system to perform a set of operations, the set of operations comprising: receiving, by the resource platform from the computing device, a request to initiate a transaction for a resource of the resource platform; providing, by the resource platform to the computing device, a response to the request that includes an indication of verification instructions that, when executed by the computing device, causes the computing device to generate verification information that is inaccessible by the resource platform; receiving, by the resource platform from the computing device, the verification information; triggering, by the resource platform, a verification process at an authorization processor without redirecting the computing device to the authorization processor, the triggering including providing the verification information to the authorization processor; and in response to receiving an indication from the authorization processor that the verification information is verified, completing, by the resource platform, the transaction.
2. The system of claim 1, wherein the verification instructions further cause the computing device to encrypt the verification information using a public key associated with a private key of the authorization processor.
3. The system of claim 1, wherein the operations further comprise providing a notification of successful completion of the transaction to the computing device.
4. The system of claim 1, wherein the indication of the verification instructions comprises a URL or identifier from which the computing device can retrieve the verification instructions.
5. The system of claim 1, wherein the operations further comprise: receiving the verification instructions in an encrypted form from the authorization processor; and storing the verification instructions at the resource platform.
6. The system of claim 1, wherein completing the transaction comprises granting access to information.
7. The system of claim 1, wherein completing the transaction comprises associating a resource for which a user of the computing device is transacting with an account of the user.
8. The system of claim 1, wherein the verification instructions further comprise instructions to: determine whether a user has opted into supplemental verification; and based on determining the user has opted into supplemental verification, generate additional verification information.
9. The system of claim 1, wherein providing the response to the request that includes the verification instructions comprises accessing the verification instructions from a data store based on an indication of the authorization processor.
10. The system of claim 1, wherein the request to initiate the transaction includes an indication of the authorization processor.
11. A method to verify a transaction between a computing device and a resource platform, the method comprising: receiving, by the resource platform from the computing device, a request to initiate a transaction for a resource of the resource platform; providing, by the resource platform to the computing device, a response to the request that includes an indication of verification instructions that, when executed by the computing device, causes the computing device to generate verification information that is inaccessible by the resource platform; receiving, by the resource platform from the computing device, the verification information; triggering, by the resource platform, a verification process at an authorization processor without redirecting the computing device to the authorization processor, the triggering including providing the verification information to the authorization processor; and in response to receiving an indication from the authorization processor that the verification information is verified, completing, by the resource platform, the transaction.
12. The method of claim 11, wherein the verification instructions further cause the computing device to encrypt the verification information using a public key associated with a private key of the authorization processor.
13. The method of claim 11, further comprising providing a notification of successful completion of the transaction to the computing device.
14. The method of claim 11, wherein the indication of the verification instructions comprises a URL or identifier from which the computing device can retrieve the verification instructions.
15. The method of claim 11, further comprising: receiving the verification instructions in an encrypted form from the authorization processor; and storing the verification instructions at the resource platform.
16. The method of claim 11, wherein completing the transaction comprises granting access to information.
17. The method of claim 11, wherein completing the transaction comprises associating a resource for which a user of the computing device is transacting with an account of the user.
18. The method of claim 11, wherein the verification instructions further comprise instructions to: determine whether a user has opted into supplemental verification; and based on determining the user has opted into supplemental verification, generate additional verification information.
19. The method of claim 11, wherein providing the response to the request that includes the verification instructions comprises accessing the verification information from a data store based on an indication of the authorization processor receives as part of the request.
20. A non-transitory computer-storage medium storing instructions that, when executed by at least one hardware processor of a machine, cause the machine to perform operations to verify a transaction between a computing device and a resource platform, the operations comprising: receiving, by the resource platform from the computing device, a request to initiate a transaction for a resource of the resource platform; providing, by the resource platform to the computing device, a response to the request that includes an indication of verification instructions that, when executed by the computing device, causes the computing device to generate verification information that is inaccessible by the resource platform; receiving, by the resource platform from the computing device, the verification information; triggering, by the resource platform, a verification process at an authorization processor without redirecting the computing device to the authorization processor, the triggering including providing the verification information to the authorization processor; and in response to receiving an indication from the authorization processor that the verification information is verified, completing, by the resource platform, the transaction.
1. A system to verify a transaction between a computing device and a resource platform, the system comprising: at least one processor; and memory storing instructions that, when executed by the at least one processor, causes the system to perform a set of operations, the set of operations comprising: receiving, by the resource platform from a computing device, a request to initiate a transaction for a resource of the resource platform; providing, by the resource platform to the computing device, a response to the request comprising verification instructions associated with an authorization processor that, when executed by the computing device, causes the computing device to generate verification information that is encrypted using a public key associated with a private key of the authorization processor such that the verification information is inaccessible by the resource platform, the resource platform triggering a verification process without redirecting the computing device to the authorization processor; receiving, by the resource platform from the computing device, the verification information; providing, by the resource platform, the verification information to the authorization processor, the authorization processor decrypting and verifying the verification information; and based on receiving an indication from the authorization processor that the verification information is verified, completing, by the resource platform, the transaction and providing, by the resource platform, a notification of successful completion of the transaction.
2. The system of claim 1, wherein providing the notification comprises: generating and providing an email confirmation; or providing a webpage indicating the completion of the transaction.
3. The system of claim 1, wherein the verification instructions further comprise an instruction to access stored data associated with a user of the computing device.
4. The system of claim 3, wherein the stored data is further associated with another resource platform.
5. The system of claim 1, wherein the verification instructions further comprise instructions to: determine whether a user has opted into supplemental verification; and based on determining the user has opted into supplemental verification, generate additional verification information.
6. The system of claim 1, wherein receiving the verification information further comprises receiving an indication of user input at the computing device.
7. The system of claim 1, wherein the request to initiate the transaction comprises an indication of the authorization processor.
8. The system of claim 1, wherein the operations further comprise: in response to completing the transaction, associating a resource of the transaction with an account of a user associated with the computing device.
9. A method for verifying a transaction verification by between a user computing device and a resource platform, the method comprising: receiving, by the user computing device from the resource platform, verification instructions associated with an authorization processor; executing, by the user computing device, the verification instructions to generate verification information that is encrypted using a cryptographic key associated with the authorization processor such that the verification information is inaccessible by the resource platform the resource platform triggering a verification process without redirecting the computing device to the authorization processor; providing the verification information to the resource platform, the resource platform transmitting the verification information onto the authorization processor, the authorization processor decrypting and verifying the verification information; and receiving, from the resource platform, a notification of successful completion of the transaction, the notification being generated by the resource platform in response to the verifying by the authorization processor and completion of the transaction by the resource platform.
10. The method of claim 9, further comprising: prior to the transaction, providing, to the authorization processor, authentication information; and receiving, from the authorization processor, session information comprising the cryptographic key.
11. The method of claim 10, wherein executing the verification instructions comprises decrypting the verification instructions using the cryptographic key of the session information.
12. The method of claim 10, wherein executing the verification instructions comprises encrypting the verification information using the cryptographic key to protect the verification information from access by the resource platform.
13. The method of claim 10, further comprising verifying an association between the verification instructions and the authorization processor based on the session information and at least one of: a cryptographic signature of the verification instructions; or a cryptographic hash of the verification instructions.
14. The method of claim 9, wherein executing the verification instructions comprises: determining whether a user has opted into supplemental verification; and based on determining the user has opted into supplemental verification, generating additional verification information.
15. The method of claim 9, wherein the cryptographic key comprises a public key of a key pair, wherein the authorization processor retains the associated private key.
16. A method for verifying a transaction between a user computing device and a resource platform, the method comprising: receiving, by a resource platform from a computing device, a request to initiate a transaction for a resource of the resource platform; providing, by the resource platform to the computing device, a response to the request comprising verification instructions associated with an authorization processor that, when executed by the computing device, causes the computing device to generate verification information that is encrypted using a public key associated with a private key of the authorization processor such that the verification information is inaccessible by the resource platform, the resource platform triggering a verification process without redirecting the computing device to the authorization processor; receiving, by the resource platform from the computing device, the verification information; providing, by the resource platform, the verification information to the authorization processor, the authorization processor decrypting and verifying the verification information; and based on receiving an indication from the authorization processor that the verification information is verified, completing, by the resource platform, the transaction and providing, by the resource platform, a notification of successful completion of the transaction.
17. The method of claim 16, wherein the verification instructions further comprise an instruction to access stored data associated with another resource platform.
18. The method of claim 16, wherein the verification instructions further comprise instructions to: determine whether a user has opted into supplemental verification; and based on determining the user has opted into supplemental verification, generate additional verification information.
19. The method of claim 16, wherein receiving the verification information further comprises receiving an indication of user input at the computing device.
20. The method of claim 16, wherein the request to initiate the transaction comprises an indication of the authorization processor.
9. Claims 1-20 is rejected on the ground of non-statutory double patenting as being unpatentable over claims 1-20 of U.S. Patent No. 12,034,851. Although the claims at issue are not identical, they are not patentably distinct from each other because in both instances, the claims are drawn towards transaction security techniques. The omission of “encrypted using a public key associated with a private key of the authorization processor such that the verification information is inaccessible by the resource platform” does not change the scope of the claims for the instant application and the issued application. Similarly, in both instances, a similarity measure may be attained wherein providing verifying users and authorizing transactions between users facilitated by resource platforms is being performed.
Claim Rejections - 35 USC § 103
10. 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.
11. 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.
12. Claims 1-20 are rejected under 35 U.S.C. 103 as being unpatentable over Law et al. (US Patent No. 9,596,237) in view of Shah et al. (Pub No. 2017/0374070).
Referring to the rejection of claim 1, Law et al. discloses a system comprising a resource platform to verify a transaction between a computing device and a resource platform, the system comprising:
at least one processor; (See Law et al., Fig. 27, i.e. main processor, item 352)
and memory storing instructions that, when executed by the at least one processor, causes the system to perform operations comprising: (See Law et al., Fig. 27, i.e. RAM memory, item 374)
receiving, by the resource platform from the computing device, a request to initiate a transaction for a resource of the resource platform; (See Law et al., Col. 9, lines 43-52, i.e. initiating a payment transaction for a resource on a mobile device)
providing, by the resource platform to the computing device, a response to the request that includes an indication of verification instructions generated by an authorized processor that, when executed by the computing device, causes the computing device to generate verification information that is inaccessible by the resource platform; (See Law et al., Col. 9, lines 53-56, Col. 10, lines 10, lines 10-28, and Col. 15, lines 1-10, i.e. in response to the request generating verification information associated with the computing device and if the transaction is unsuccessful for any reason to verify information, access is denied and the transaction is deemed a transaction risk and the mobile device is notified and during the transaction process, the payment gateway sends the payment ID and supplemental ID to the supplemental server 22 includes a request for supplemental verification. The payment server 20 then sends a request for authorization for payment, payment ID and verification result to the supplemental server 22. The supplemental server 22, based on the verification result and payment ID, then issues or sends an authorization result for payment to the payment server 20)
receiving, by the resource platform from the computing device, the verification information; (See Law et al., Col. 9, lines 56-61, i.e. generated verification information is received from the computing device)
and in response to receiving an indication from the authorization processor that the verification information is verified, completing, by the resource platform, the transaction. (See Law et al., Col. 11, lines 52-67 and Col. 12, lines 1-12, i.e. verification information has been verified and a successful transaction is provided to the computing device)
However, Law et al. fail to explicitly disclose triggering, by the resource platform, a verification process at the authorization processor without redirecting the computing device to the authorization processor, the triggering including providing the verification information to the authorization processor.
Shah et al. discloses methods, devices, and systems that provide for robust and scalable multi-factor authentication using a combination of network-based and device-based authentications.
Shah et al. discloses triggering, by the resource platform, a verification process at the authorization processor without redirecting the computing device to the authorization processor, the triggering including providing the verification information to the authorization processor. (See Shah et al., para. 38, 127-128 and 130, i.e., an authentication is considered local when a given authentication factor does not require interaction with the network for a normal authentication operation using the factor. Another example of a local authentication is a continuous authentication in which the user 110 is continuously being authenticated, for example using behavioral characteristics such as keyboard dynamics or facial recognition. A local authentication may also be used for access to local resources on the user device 112 (e.g., via the MFAP 106) without interaction with the MFAS 102. The application may trigger the MFAP 106 for authentication using the locally provisioned policies without connecting to the MFAS 102, for example, because the device does not have a network connection at the time of the authentication request. The MFAP 106 may follow the same or similar process (as the MFAS 102 may follow) to determine authentication factors that are selected for execution. In some cases, however, the MFAP 106 may determine the authentication factors based on only local authentication factors that are available to the user and the device. In some cases, previously run authentication factors (both local and network-based) may be considered (for the authentication) based on their freshness. In an example, once the user device moves from offline to online mode, information regarding local authentication factors that were executed during offline mode may be shared between the MFAP 106 and the MFAS 102 through previously established secure communication channels. The MFAS 102 may determine that AL requirements from a given RP may be met using only local authentication factors. In this case, the MFAS 102 may trigger the MFAP 106 to perform the local authentication factors and, rather than return the outcome back to the MFAS 102, may have the MFAP 106 return an OpenID assertion back to the RP directly, thus using smart Open ID functionality in the MFAP 106)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date the claimed invention was made to combine Law et al.’s system and method for initiating transactions on a mobile device modified with Shah et al.’s methods, devices, and systems that provide for robust and scalable multi-factor authentication using a combination of network-based and device-based authentications.
Motivation for such an implementation would enable the MFAS to trigger the MFAP to perform the local authentication factors and, rather than return the outcome back to the MFAS, may have the MFAP return an OpenID assertion back to the RP directly, thus using smart Open ID functionality in the MFAP. (See Shah et al., para. 130)
Referring to the rejection of claim 2, (Law et al. modified by Shah et al.) discloses wherein the verification instructions further cause the computing device to encrypt the verification information using a public key associated with a private key of the authorization processor. (See Law et al., Col. 20, lines 53-67, Col. 21, lines 1-2, Col. 32, lines 65-67, and Col. 33, lines 1-6 and lines 35-47, i.e., the mobile device generates a key pair (public key/private key) and send its public key to the payment gateway, registers the mobile device. When the mobile device makes a subsequent transaction, the mobile device digitally sign either a portion or complete set of data associated with the transaction. When the payment gateway receives the data associated with the transaction request, payment gateway verifies the signed data, either continuing as normal or denying the transaction request in accordance to the verification result.)
Referring to the rejection of claim 3, (Law et al. modified by Shah et al.) discloses wherein the operations further comprise providing a notification of successful completion of the transaction to the computing device. (See Law et al., Col. 13, lines 9-21, i.e., the payment server authenticates or determines if the verification result is successful and, if authenticated, uses the payment ID to execute the payment. The payment gateway generates a new mobile device ID, mobile device ID.sub.2, which replaces mobile device ID.sub.1, and is associated with the same payment ID, stores mobile device ID.sub.2 and sends the same to the mobile device. The mobile device stores mobile device ID.sub.2, and delete mobile device ID.sub.1, therefore, a new mobile device ID is generated during each transaction to replace the previous mobile device ID in order to prevent replay attacks)
Referring to the rejection of claim 4, (Law et al. modified by Shah et al.) discloses wherein the indication of the verification instructions comprises a URL or identifier from which the computing device can retrieve the verification instructions. (See Law et al., Col. 25, lines 59-67, Col. 26, lines 1-9, i.e., when a known mobile device has successfully been used to complete the registration process requests to access such protected data, the mobile device submits, from a “log-in” page, along with the original request containing a username and password, as an HTTPS (or, less likely, HTTP) cookie, its mobile device ID to the payment gateway. The payment gateway uses the mobile device ID to retrieve profile of information associated with the mobile device ID and an URL of an authentication supplemental system is associated with the mobile device ID, and the URL is used to direct the transmission of the personally identifiable information to the supplemental server, which is used to verify the provided personally identifiable information)
Referring to the rejection of claim 5, (Law et al. modified by Shah et al.) discloses wherein the operations further comprise: receiving the verification instructions in an encrypted form from the authorization processor; and storing the verification instructions at the resource platform. (See Law et al., Col. 16, lines 35-42, i.e., during the transaction process, the payment gateway compares the mobile device ID received from the mobile device to the mobile device ID previously stored during the registration process to determine if they are similar, and if so, authenticates the transaction for execution (e.g. through the payment server, item 20) and the payment gateway, item 8 stores the mobile device ID using a relational database, object database, or “NoSQL” data store. The mobile device IDs are protected by adequate access controls and stored in a strongly encrypted form)
Referring to the rejection of claim 6, (Law et al. modified by Shah et al.) discloses wherein completing the transaction comprises granting access to information. (See Law et al., Col. 13, lines 24-33, i.e., upon the verification module successfully verifying the supplemental ID and payment ID are authentic, the verification module sends the payment ID and verification result to the payment server, the payment server executes the payment, generates mobile device ID.sub.2 and access is granted)
Referring to the rejection of claim 7, (Law et al. modified by Shah et al.) discloses wherein completing the transaction comprises associating a resource for which a user of the computing device is transacting with an account of the user. (See Law et al., Col. 28, lines 59-67, i.e., a transaction is dependent on the physical mobile device from which the transaction is being initiated, using the mobile device ID, only one physical mobile device is able to log-in to or perform authorized commands in relation to the payment gateway with a user's account. Thus, an attacker cannot use another mobile device 10 to commit fraudulent activities)
Referring to the rejection of claim 8, (Law et al. modified by Shah et al.) discloses wherein the verification instructions further comprise instructions to: determine whether a user has opted into supplemental verification; (See Law et al., Col. 10, lines 10-16, i.e., during the transaction process, the payment gateway sends the payment ID and supplemental ID to the supplemental server, upon receiving the request for supplemental verification and verifying the IDs, sends a verification result to the payment gateway) and based on determining the user has opted into supplemental verification, generate additional verification information. (See Law et al., Col. 10, lines 17-24, i.e., the payment gateway then sends the payment ID and verification result to the payment server, then sends a request for authorization for payment, payment ID and verification result to the supplemental server. The supplemental server, based on the verification result and payment ID, then issues or sends an authorization result for payment to the payment server)
Referring to the rejection of claim 9, (Law et al. modified by Shah et al.) discloses wherein providing the response to the request that includes the verification instructions comprises accessing the verification instructions from a data store based on an indication of the authorization processor. (See Law et al., Col. 9, lines 43-67, i.e., the user may initiate a payment from a payment account, only enters the supplemental ID into the mobile device in order to complete the transaction and authentication. The mobile device ID, automatically retrieved from the mobile device's memory and the supplemental ID are transferred from the mobile device to the payment gateway. If the verification result confirms the supplemental ID provided by the mobile device 10 is correct or authentic, then the payment gateway 8 sends the verification result and payment ID to the payment server)
Referring to the rejection of claim 10, (Law et al. modified by Shah et al.) discloses wherein the request to initiate the transaction includes an indication of the authorization processor. (See Law et al., Col. 9, lines 42-67, i.e., transaction has been initiated and authorization is disclosed in a transaction, the user may initiate a payment from a payment account, as identified by the registered payment ID. The payment gateway retrieves the payment ID, corresponding to the received mobile device ID, and sends both the supplemental ID and payment ID to the verification module, verifying the received payment ID and supplemental ID are authentic or correct as compared with the IDs stored in memory, confirms the supplemental ID provided by the mobile device 10 is correct or authentic, thereby allowing the payment server 20 to complete the payment from the payment account)
Referring to the rejection of claim 11, (Law et al. modified by Shah et al.) discloses a method to verify a transaction between a computing device and a resource platform, the method comprising:
receiving, by the resource platform from the computing device, a request to initiate a transaction for a resource of the resource platform; (See Law et al., Col. 9, lines 43-52, i.e. initiating a payment transaction for a resource on a mobile device)
providing, by the resource platform to the computing device, a response to the request that includes an indication of verification instructions generated by an authorization processor that, when executed by the computing device, causes the computing device to generate verification information that is inaccessible by the resource platform; (See Law et al., Col. 9, lines 53-56, Col. 10, lines 10, lines 10-28, and Col. 15, lines 1-10, i.e. in response to the request generating verification information associated with the computing device and if the transaction is unsuccessful for any reason to verify information, access is denied and the transaction is deemed a transaction risk and the mobile device is notified and during the transaction process, the payment gateway sends the payment ID and supplemental ID to the supplemental server 22 includes a request for supplemental verification. The payment server 20 then sends a request for authorization for payment, payment ID and verification result to the supplemental server 22. The supplemental server 22, based on the verification result and payment ID, then issues or sends an authorization result for payment to the payment server 20)
receiving, by the resource platform from the computing device, the verification information; (See Law et al., Col. 9, lines 56-61, i.e. generated verification information is received from the computing device)
and in response to receiving an indication from the authorization processor that the verification information is verified, completing, by the resource platform, the transaction. (See Law et al., Col. 11, lines 52-67 and Col. 12, lines 1-12, i.e. verification information has been verified and a successful transaction is provided to the computing device)
However, Law et al. fail to explicitly disclose triggering, by the resource platform, a verification process at the authorization processor without redirecting the computing device to the authorization processor, the triggering including providing the verification information to the authorization processor.
Shah et al. discloses methods, devices, and systems that provide for robust and scalable multi-factor authentication using a combination of network-based and device-based authentications.
Shah et al. discloses triggering, by the resource platform, a verification process at the authorization processor without redirecting the computing device to the authorization processor, the triggering including providing the verification information to the authorization processor. (See Shah et al., para. 38, 127-128 and 130, i.e., an authentication is considered local when a given authentication factor does not require interaction with the network for a normal authentication operation using the factor. Another example of a local authentication is a continuous authentication in which the user 110 is continuously being authenticated, for example using behavioral characteristics such as keyboard dynamics or facial recognition. A local authentication may also be used for access to local resources on the user device 112 (e.g., via the MFAP 106) without interaction with the MFAS 102. The application may trigger the MFAP 106 for authentication using the locally provisioned policies without connecting to the MFAS 102, for example, because the device does not have a network connection at the time of the authentication request. The MFAP 106 may follow the same or similar process (as the MFAS 102 may follow) to determine authentication factors that are selected for execution. In some cases, however, the MFAP 106 may determine the authentication factors based on only local authentication factors that are available to the user and the device. In some cases, previously run authentication factors (both local and network-based) may be considered (for the authentication) based on their freshness. In an example, once the user device moves from offline to online mode, information regarding local authentication factors that were executed during offline mode may be shared between the MFAP 106 and the MFAS 102 through previously established secure communication channels. The MFAS 102 may determine that AL requirements from a given RP may be met using only local authentication factors. In this case, the MFAS 102 may trigger the MFAP 106 to perform the local authentication factors and, rather than return the outcome back to the MFAS 102, may have the MFAP 106 return an OpenID assertion back to the RP directly, thus using smart Open ID functionality in the MFAP 106)
The rationale for combining Law et al. in view of Shah et al. is the same as claim 1.
Referring to the rejection of claim 12, (Law et al. modified by Shah et al.) discloses wherein the verification instructions further cause the computing device to encrypt the verification information using a public key associated with a private key of the authorization processor. (See Law et al., Col. 20, lines 53-67, Col. 21, lines 1-2, Col. 32, lines 65-67, and Col. 33, lines 1-6 and lines 35-47, i.e., the mobile device generates a key pair (public key/private key) and send its public key to the payment gateway, registers the mobile device. When the mobile device makes a subsequent transaction, the mobile device digitally sign either a portion or complete set of data associated with the transaction. When the payment gateway receives the data associated with the transaction request, payment gateway verifies the signed data, either continuing as normal or denying the transaction request in accordance to the verification result.)
Referring to the rejection of claim 13, (Law et al. modified by Shah et al.) discloses further comprising providing a notification of successful completion of the transaction to the computing device. (See Law et al., Col. 13, lines 9-21, i.e., the payment server authenticates or determines if the verification result is successful and, if authenticated, uses the payment ID to execute the payment. The payment gateway generates a new mobile device ID, mobile device ID.sub.2, which replaces mobile device ID.sub.1, and is associated with the same payment ID, stores mobile device ID.sub.2 and sends the same to the mobile device. The mobile device stores mobile device ID.sub.2, and delete mobile device ID.sub.1, therefore, a new mobile device ID is generated during each transaction to replace the previous mobile device ID in order to prevent replay attacks)
Referring to the rejection of claim 14, (Law et al. modified by Shah et al.) discloses wherein the indication of the verification instructions comprises a URL or identifier from which the computing device can retrieve the verification instructions. (See Law et al., Col. 25, lines 59-67, Col. 26, lines 1-9, i.e., when a known mobile device has successfully been used to complete the registration process requests to access such protected data, the mobile device submits, from a “log-in” page, along with the original request containing a username and password, as an HTTPS (or, less likely, HTTP) cookie, its mobile device ID to the payment gateway. The payment gateway uses the mobile device ID to retrieve profile of information associated with the mobile device ID and an URL of an authentication supplemental system is associated with the mobile device ID, and the URL is used to direct the transmission of the personally identifiable information to the supplemental server, which is used to verify the provided personally identifiable information)
Referring to the rejection of claim 15, (Law et al. modified by Shah et al.) discloses further comprising: receiving the verification instructions in an encrypted form from the authorization processor; and storing the verification instructions at the resource platform. (See Law et al., Col. 16, lines 35-42, i.e., during the transaction process, the payment gateway compares the mobile device ID received from the mobile device to the mobile device ID previously stored during the registration process to determine if they are similar, and if so, authenticates the transaction for execution (e.g. through the payment server, item 20) and the payment gateway, item 8 stores the mobile device ID using a relational database, object database, or “NoSQL” data store. The mobile device IDs are protected by adequate access controls and stored in a strongly encrypted form)
Referring to the rejection of claim 16, (Law et al. modified by Shah et al.) discloses wherein completing the transaction comprises granting access to information. (See Law et al., Col. 13, lines 24-33, i.e., upon the verification module successfully verifying the supplemental ID and payment ID are authentic, the verification module sends the payment ID and verification result to the payment server, the payment server executes the payment, generates mobile device ID.sub.2 and access is granted)
Referring to the rejection of claim 17, (Law et al. modified by Shah et al.) discloses wherein completing the transaction comprises associating a resource for which a user of the computing device is transacting with an account of the user. (See Law et al., Col. 28, lines 59-67, i.e., a transaction is dependent on the physical mobile device from which the transaction is being initiated, using the mobile device ID, only one physical mobile device is able to log-in to or perform authorized commands in relation to the payment gateway with a user's account. Thus, an attacker cannot use another mobile device 10 to commit fraudulent activities)
Referring to the rejection of claim 18, (Law et al. modified by Shah et al.) discloses wherein the verification instructions further comprise instructions to: determine whether a user has opted into supplemental verification; (See Law et al., Col. 10, lines 10-16, i.e., during the transaction process, the payment gateway sends the payment ID and supplemental ID to the supplemental server, upon receiving the request for supplemental verification and verifying the IDs, sends a verification result to the payment gateway) and based on determining the user has opted into supplemental verification, generate additional verification information. (See Law et al., Col. 10, lines 17-24, i.e., the payment gateway then sends the payment ID and verification result to the payment server, then sends a request for authorization for payment, payment ID and verification result to the supplemental server. The supplemental server, based on the verification result and payment ID, then issues or sends an authorization result for payment to the payment server)
Referring to the rejection of claim 19, (Law et al. modified by Shah et al.) discloses wherein providing the response to the request that includes the verification instructions comprises accessing the verification information from a data store based on an indication of the authorization processor receives as part of the request. (See Law et al., Col. 9, lines 43-67, i.e., the user may initiate a payment from a payment account, only enters the supplemental ID into the mobile device in order to complete the transaction and authentication. The mobile device ID, automatically retrieved from the mobile device's memory and the supplemental ID are transferred from the mobile device to the payment gateway. If the verification result confirms the supplemental ID provided by the mobile device 10 is correct or authentic, then the payment gateway 8 sends the verification result and payment ID to the payment server)
Referring to the rejection of claim 20, (Law et al. modified by Shah et al.) discloses a non-transitory computer-storage medium storing instructions that, when executed by at least one hardware processor of a machine, cause the machine to perform operations to verify a transaction between a computing device and a resource platform, the operations comprising:
receiving, by the resource platform from the computing device, a request to initiate a transaction for a resource of the resource platform; (See Law et al., Col. 9, lines 43-52, i.e. initiating a payment transaction for a resource on a mobile device)
providing, by the resource platform to the computing device, a response to the request that includes an indication of verification instructions generated by an authorization processor that, when executed by the computing device, causes the computing device to generate verification information that is inaccessible by the resource platform; (See Law et al., Col. 9, lines 53-56, Col. 10, lines 10, lines 10-28, and Col. 15, lines 1-10, i.e. in response to the request generating verification information associated with the computing device and if the transaction is unsuccessful for any reason to verify information, access is denied and the transaction is deemed a transaction risk and the mobile device is notified and during the transaction process, the payment gateway sends the payment ID and supplemental ID to the supplemental server 22 includes a request for supplemental verification. The payment server 20 then sends a request for authorization for payment, payment ID and verification result to the supplemental server 22. The supplemental server 22, based on the verification result and payment ID, then issues or sends an authorization result for payment to the payment server 20)
receiving, by the resource platform from the computing device, the verification information; (See Law et al., Col. 9, lines 56-61, i.e. generated verification information is received from the computing device)
and in response to receiving an indication from the authorization processor that the verification information is verified, completing, by the resource platform, the transaction. (See Law et al., Col. 11, lines 52-67 and Col. 12, lines 1-12, i.e. verification information has been verified and a successful transaction is provided to the computing device)
However, Law et al. fail to explicitly disclose triggering, by the resource platform, a verification process at the authorization processor without redirecting the computing device to the authorization processor, the triggering including providing the verification information to the authorization processor.
Shah et al. discloses methods, devices, and systems that provide for robust and scalable multi-factor authentication using a combination of network-based and device-based authentications.
Shah et al. discloses triggering, by the resource platform, a verification process at the authorization processor without redirecting the computing device to the authorization processor, the triggering including providing the verification information to the authorization processor. (See Shah et al., para. 38, 127-128 and 130, i.e., an authentication is considered local when a given authentication factor does not require interaction with the network for a normal authentication operation using the factor. Another example of a local authentication is a continuous authentication in which the user 110 is continuously being authenticated, for example using behavioral characteristics such as keyboard dynamics or facial recognition. A local authentication may also be used for access to local resources on the user device 112 (e.g., via the MFAP 106) without interaction with the MFAS 102. The application may trigger the MFAP 106 for authentication using the locally provisioned policies without connecting to the MFAS 102, for example, because the device does not have a network connection at the time of the authentication request. The MFAP 106 may follow the same or similar process (as the MFAS 102 may follow) to determine authentication factors that are selected for execution. In some cases, however, the MFAP 106 may determine the authentication factors based on only local authentication factors that are available to the user and the device. In some cases, previously run authentication factors (both local and network-based) may be considered (for the authentication) based on their freshness. In an example, once the user device moves from offline to online mode, information regarding local authentication factors that were executed during offline mode may be shared between the MFAP 106 and the MFAS 102 through previously established secure communication channels. The MFAS 102 may determine that AL requirements from a given RP may be met using only local authentication factors. In this case, the MFAS 102 may trigger the MFAP 106 to perform the local authentication factors and, rather than return the outcome back to the MFAS 102, may have the MFAP 106 return an OpenID assertion back to the RP directly, thus using smart Open ID functionality in the MFAP 106)
The rationale for combining Law et al. in view of Shah et al. is the same as claim 1.
Conclusion
13. Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to COURTNEY D FIELDS whose telephone number is (571)272-3871. The examiner can normally be reached IFP M-F 8am-4: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, SHEWAYE GELAGAY can be reached at (571)272-4219. 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.
/COURTNEY D FIELDS/Examiner, Art Unit 2436 June 14, 2026
/SHEWAYE GELAGAY/Supervisory Patent Examiner, Art Unit 2436
Prosecution Insights