CTNF 18/995,699 CTNF 85676 DETAILED ACTION The instant application having Application No. 18/995,699 filed on 01/16/2025 is presented for examination by the Examiner. Notice of Pre-AIA or AIA Status 07-03-aia AIA 15-10-aia The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA. Claim Rejections - 35 USC § 112 07-30-02 AIA The following is a quotation of 35 U.S.C. 112(b): (b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention. The following is a quotation of 35 U.S.C. 112 (pre-AIA), second paragraph: The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention. 07-34-01 Claims 1, 3 and 16 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention. Claim 1 recites the limitation “.. the verification …” in line 10. There is a lack of antecedent basis for this limitation in the claim. Claim 3 recites the limitation “.. an authorization request message comprising the security data; modifying the authorization request message to include the security data ;” As recited, the authorization request message already comprising the security data, so it is unclear why the authorization request message needs to be modified to include the security data. Claim 3 also recites the limitation “.. the modified authorization request message ..” in line 6. There is a lack of antecedent basis for this limitation in the claim. Claim 16 recites the limitation “.. the received client data ..” There is a lack of antecedent basis for this limitation in the claim. Claim Rejections - 35 USC § 102 07-06 AIA 15-10-15 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. 07-07-aia AIA 07-07 The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action: A person shall be entitled to a patent unless – 07-08-aia AIA (a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention. 07-15 AIA Claim s 1-5, 13 and 15 are rejected under 35 U.S.C. 102( a)(1 ) as being anticipated by WIPO (WO 2020/041594 A1-hereinafter Fuhrmann) . Regarding claim 1, Fuhrmann discloses a method comprising: receiving, by a server computer, an authentication data packet comprising authentication data from a relying party computer in communication with an authenticator associated with a user device (at least figure 6, [0107][0110]-[0112], first authorization computer receives token request message (authentication data packet), the token request message comprises initial access identifier/ID & user identifier/ID from token provider computer (relying party computer) in communication with issuer application associated with token requestor computer (user device)) ; verifying, by the server computer, the authentication data in the authentication data packet (at least figure 6, [0112], i.e.: the user ID and the initial access ID are validated/verified) ; storing, by the server computer, the authentication data packet in a database (at least [0023][0026], the initial access ID & user ID are stored) ; and transmitting, by the server computer to an authorizing entity computer, a data packet comprising data relating to the verification of the authentication data (at least figure 8, [0134], a modified message including the initial access ID and/or intermediate access ID is transmitted/sent to 2 nd authorization computer) . Regarding claim 2, Fuhrmann discloses the method of claim 1. Fuhrmann also discloses based on the verifying, obtaining, by the server computer, security data (at least figure 6, [0112], based on the validation/verification, intermediate account ID is obtained) ; and transmitting the security data to the relying party computer (at least [0114], the intermediate access ID is transmitted to the token provider computer) . Regarding claim 3, Fuhrmann discloses the method of claim 2. Fuhrmann also discloses receiving, by the server computer from the relying party computer, an authorization request message comprising the security data (at least figure 8, [0131]-[0134], authorization request message is received from the processing/token provider computer) ; modifying the authorization request message to include the security data (at least figure 8, [0134], the authorization request message is modified to include the intermediate access ID) ; and transmitting, by the server computer, the modified authorization request message comprising the authentication data packet and the security data to the authorizing entity computer for authorization (at least figure 8, [0134], modified authorization request message including the initial access ID and the intermediate access ID are transmitted to the second authorization computer for authorizing transaction) . Regarding claim 4, Fuhrmann discloses the method of claim 2. Fuhrmann also discloses the security data is an authentication cryptogram (at least [0045], the intermediate access ID which identifies an account is encrypted to derive obtain a cryptogram) . Regarding claim 5, Fuhrmann discloses the method of claim 4. Fuhrmann also discloses the authentication cryptogram indicates a successful verification of the authentication data included in the authentication data packet (at least figure 6, [0045][0110]-[0112], the intermediate access ID indicates that verification of the initial access ID has been successful) , and wherein the obtaining the security data further comprises: generating, by the server computer, the authentication cryptogram based on the verification of the authentication data by the server computer (at least figure 6, [0112], the first authorization computer generates the intermediate access identifier) . Regarding claim 13, Fuhrmann discloses the method of claim 1. Fuhrmann also discloses the server computer includes a directory server computer (at least figures 6-8, first authorization computer) . Claim 15 is rejected for the same rationale as claim 1 above . Claim Rejections - 35 USC § 103 07-06 AIA 15-10-15 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. 07-20-aia AIA The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action: A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made. 07-21-aia AIA Claim s 6-8, 11-12, 14 and 16-20 are rejected under 35 U.S.C. 103 as being unpatentable over Fuhrmann and in view of Stocker et al. (US 2023/0171252 A1-hereinafter Stocker) . Regarding claim 6, Fuhrmann discloses the method of claim 1. Fuhrmann does not explicitly disclose the authenticator has a public-private key pair associated therewith, and the authentication data comprises data signed by a private key of the public-private key pair. However, Stocker discloses an authenticator has a public-private key pair associated therewith, and authentication data comprises data signed by a private key of the public-private key pair (at least [0044], client data is signed using a private key of WebAuthn authenticator) . It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to include the teachings of Stocker into the method of Fuhrmann to improve authentication by protecting communications from interception and unauthorized access and securely and quickly identifying the originator and determining their authenticity. Regarding claim 7, Fuhrmann and Stocker disclose the method of claim 6. Fuhrmann and Stocker also disclose the authentication data further comprises an authentication time (Fuhrmann-at least [0108], i.e.: payment credential includes time when user logs in; Stocker-at least [0023][0025][0029], timeout) , a relying party identifier (ID) (Fuhrmann-[0043][0056], merchant identifier; Stocker-at least [0023], RPID ) , an authenticator ID (Fuhrmann-[0107], i.e.: issuer application corresponds to banking account) , a user verification flag (Fuhrmann-[0060], user biometric, Stocker-at least [0044], biometric or PIN); and a user present flag (Stocker-at least [0044], PIN or biometric)) . Regarding claim 8, Fuhrmann and Stocker disclose the method of claim 7. Fuhrmann also discloses prior to the receiving the authentication data packet, performing, by the server computer, an enrollment process by which the relying party computer and the authenticator facilitate an enrollment of the user device (at least figures 6 & 7, [0107]-[0115], enrollment of the user device is performed by the token provider computer and issuer application) . Regarding claim 11, Fuhrmann and Stocker disclose the method of claim 6. Stocker also discloses the authentication data further comprises a client data including a hash algorithm and an authenticator data including a public key of the public-private key pair (at least [0044], authentication data includes client data hash, and public key of the public-private key pair) , and the data that is signed by the private key is a digital signature that is obtained by signing, by the private key, a concatenated value that is a concatenation of the client data and the authenticator data (at least [0033][0044], client data hash and authenticator data are signed with private key) . Regarding claim 12, Fuhrmann and Stocker disclose the method of claim 11. Stocker also discloses the verifying comprises verifying the digital signature using the public key (at least [0034], signature is verified using public key) . Regarding claim 14, Fuhrmann discloses the method of claim 1. Fuhrmann does not explicitly disclose the authenticator is a Fast Identity Online (FIDO) authenticator. However, Stocker discloses the authenticator is a (FIDO) authenticator (at least [0015], WebAuthn authenticator is a core component of FIDO) . Regarding claim 16, Fuhrman discloses a method comprising: sending, by the user device, a data packet including the client data, to a relying party computer (at least figures 6 & 8, [0110] token request message is sent from token requestor to token provider computer) , wherein the relying party computer validates the client data and generates an authentication data packet comprising an authentication data, the authentication data including authentication data and sends the authentication data packet to a server computer (at least figure 6, [0103][0111], the token provider computer validates the token request message and generates a modified token request message to include intermediate access ID and sends the modified token request message to the first authorization computer) , and wherein the server computer thereafter receives the authentication data packet, verifies the authentication data in the authentication data packet, stores the authentication data packet in a database, and transmits, to an authorizing entity computer, a data packet comprising data relating to the verification of the authentication data (at least figure 6, [0112], the modified token request message is received, the intermediate access ID is stored and transmit the modified token request message to 2 nd authorization computer) ). Fuhrmann does not explicitly disclose generating, by an authenticator associated with a user device, a public-private key pair; authenticating, by the authenticator, a user of the user device; generating, by the authenticator, a client data and an authenticator data, the authenticator data including an indication that the user has been authenticated by the authenticator; generating, by the authenticator, an assertion signature by signing a concatenated value with a private key of the public-private key pair, wherein the concatenated value is formed by concatenating the client data and the authenticator data; and sending, by the user device, a data packet including the authenticator data, and the assertion signature to a relying party computer, the relying party validates the assertion signature using the received client data and authenticator data and a public key of the public-private key pair, and, based at least on the assertion signature being validated, generates an authentication data packet comprising an authentication data, the authentication data including the assertion signature, the client data, and the authenticator data, and sends the authentication data packet to a server computer, and However, Stocker discloses generating, by an authenticator associated with a user device, a public-private key pair (at least [0044], [0031][0044], public-private key pair is generated for user during registration) ; authenticating, by the authenticator, a user of the user device (at least [0044], biometric or PIN is used to authenticate user) ; generating, by the authenticator, a client data and an authenticator data, the authenticator data including an indication that the user has been authenticated by the authenticator (at least [0033], i.e.: authenticator assertion is generated) ; generating, by the authenticator, an assertion signature by signing a concatenated value with a private key of the public-private key pair, wherein the concatenated value is formed by concatenating the client data and the authenticator data (at least [0044], client data and authenticator data are signed using a private key) ; and a data packet including the client data, the authenticator data, and the assertion signature (at least [0033][0044], WebAuthn response includes client data, authenticator data and signature) , the relying party computer validates the assertion signature using the received client data and authenticator data and a public key of the public-private key pair, and, based at least on the assertion signature being validated, generates an authentication data packet comprising an authentication data, the authentication data including the assertion signature, the client data, and the authenticator data (at least [0023][0034][0036], signature is verified by authentication service using public key, and the authentication service generates login prompt information ) , and It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to include the teachings of Stocker into the method of Fuhrmann to improve authentication by protecting communications from interception and unauthorized access and securely and quickly identifying the originator and determining their authenticity. Regarding claim 17, Fuhrmann and Stocker disclose the method of claim 16. Fuhrmann and Stock also disclose the user device is a mobile phone (Fuhrmann-at least [0030], mobile communication device; Stock-at least [0020], i.e.: smartphone) . Regarding claim 18, Fuhrmann and Stocker disclose the method of claim 16. Stock also discloses the authenticator is a Fast Identity Online (FIDO) authenticator ([0015], WebAuthn authenticator is a core component of FIDO) . Regarding claim 19, Fuhrmann and Stocker disclose the method of claim 16. Stocker also discloses storing the private key in a database within the authenticator ([002][0010][0044], private key is stored on the user’s device) ; and generating a credential identifier (ID) that contains information about a location of the private key in the database (at least [0025][0033]-[0034], credential ID is used to locate user’s identity/private key) . Regarding claim 20, Fuhrmann and Stocker also disclose the method of claim 19. Stocker also discloses sending the public key and the credential ID to the relying party computer as a part of the authenticator data ([0025], public key and credential ID are sent) . ALLOWABLE SUBJECT MATTER 07-43 Claims 9 & 10 are objected to as being dependent upon rejected based claim, but would be allowed if rewritten in independent form including all the limitations of the base claim and any intervening claims. Conclusion Any inquiry concerning this communication or earlier communications from the examiner should be directed to PHY ANH TRAN VU whose telephone number is (571)270-7317. The examiner can normally be reached Monday-Friday 7 am-1 pm. 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, Taghi T Arani can be reached at (571) 272-3787. 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. /PHY ANH T VU/Primary Examiner, Art Unit 2438 Application/Control Number: 18/995,699 Page 2 Art Unit: 2438 Application/Control Number: 18/995,699 Page 3 Art Unit: 2438 Application/Control Number: 18/995,699 Page 4 Art Unit: 2438 Application/Control Number: 18/995,699 Page 5 Art Unit: 2438 Application/Control Number: 18/995,699 Page 6 Art Unit: 2438 Application/Control Number: 18/995,699 Page 7 Art Unit: 2438 Application/Control Number: 18/995,699 Page 8 Art Unit: 2438 Application/Control Number: 18/995,699 Page 9 Art Unit: 2438 Application/Control Number: 18/995,699 Page 10 Art Unit: 2438 Application/Control Number: 18/995,699 Page 11 Art Unit: 2438 Application/Control Number: 18/995,699 Page 12 Art Unit: 2438 Application/Control Number: 18/995,699 Page 13 Art Unit: 2438 Application/Control Number: 18/995,699 Page 14 Art Unit: 2438
Prosecution Insights