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 .
Claims 1-20 are pending in this application.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 06/18/2025. The submission is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
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.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1, 4-8, 11-15 and 18-20 are rejected under 35 U.S.C. 103 as being unpatentable over Seibert, Jr. et al. (US 11,539,698 B2) (hereinafter, “Seibert”) in view of Nowak et al. (US 10,917,405 B2) (hereinafter, “Nowak”).
As to claim 1, Seibert discloses a method for authenticating a user to an application, comprising:
receiving, from an authentication service, a message, the message being encrypted and comprising a software identifier, a first hash identifier, … (“When transmitting requests to the authentication module 131, the trusted and the untrusted application generate a hash of the application identifier of the untrusted application based on the most recently received nonce.” -e.g., see, col. 6, lines 20-29; see also: “Application T 111, in turn, transmits 205 a verification request to the authentication module 131 on behalf of application U 112. Again, application T 111 transmits the verification request using functionality provided by the authentication engine 114 that allows an application that integrates with the authentication engine 114 to bi-directionally communicate with the authentication module 131. The verification request transmitted by application T 111 includes the application identifier associated with application U 112. Optionally, to indicate the source of the verification request, application T 111 hashes the application identifier included in the verification request using nonce A and signs the request using the private key of application T 111.” -e.g., see col. 7, lines 17-30; herein, Seibert teaches the verification request which is processed by the authentication module 131 (authentication service/identity server); it is signed using the private key (encrypted/signed message); it comprises the software/application identifier and the first hash identifier (hashed application identifier), after successful hash match, the system provides the authentication code: “The authentication module 131 transmits 211 the access token and the keys to application U 112” -e.g., see, col. 8, lines 2-7);
decrypting the message to extract the software identifier, the first hash identifier, … (“… the authentication module 131 decrypts the signed verification request using the public key of application T 111. The public key is included in the application profile of application T 111 stored in the device profile store 140. The authentication module 131 also determines whether the request is timely (for example, is not a replay attack) by comparing the hashed application identifier (hashed using the nonce transmitted to the trusted application) included in the verification request with a locally-generated hash of the application identifier. If the two values match, then the authentication module 131 determines that the request is timely. When the request is received from a trusted source and is timely, the authentication module 131 authorizes the verification request.” -e.g., see, col. 7, lines 31-49; herein, Client-side/authentication module decryption extracts the identifiers and auth data);
performing a hash operation using the software identifier as an input, to generate a second hash identifier as an output (“… determines whether the request is timely (for example, is not a replay attack) by comparing the hashed application identifier (hashed using the nonce transmitted to the trusted application) included in the verification request with a locally-generated hash of the application identifier. If the two values match, then the authentication module 131 determines that the request is timely. When the request is received from a trusted source and is timely, the authentication module 131 authorizes the verification request.” -e.g., see, col. 7, lines 31-49; herein, local hash generation from software/application identifier); and
based on a determination that the first hash identifier matches the generated second hash identifier (“… determines whether the request is timely (for example, is not a replay attack) by comparing the hashed application identifier (hashed using the nonce transmitted to the trusted application) included in the verification request with a locally-generated hash of the application identifier. If the two values match, then the authentication module 131 determines that the request is timely. When the request is received from a trusted source and is timely, the authentication module 131 authorizes the verification request.” -e.g., see, col. 7, lines 31-49), providing the authentication code to the application (“The authentication module 131 transmits 211 the access token and the keys to application U 112, which is now a trusted application. The authentication module 131 also updates the device profile associated with the client device 110 to indicate that application U 112 is a trusted application.” -e.g., see, col. 8, lines 2-7; herein, successful match enables provision of the access token/authentication code).
Seibert teaches signed/encrypted messages with software identifier, first hash identifier and subsequent provision of access token/authentication code, but does not explicitly disclose the receiving message as containing all three elements (software identifier, first hash identifier and authentication code) in one transmission.
However, in an analogous art, Nowak discloses the full encrypted message structure from an authentication service containing software identifier, hash-like identifier, and authentication code/response (“The FIDO IS computer system then receives 412 a challenge message from the selected FIDO-certified server (which challenge message is based on the application identifier and FIDO facet. The FIDO IS computer system then encrypts 414 the entire payload of the challenge message by, for example, using a JavaScript object signing and encryption (“JOSE”) standard, and transmits 416 the encrypted challenge message along with an authentication response to the user device.” -e.g., see, col. 10, lines 9-18; herein, FIDO is computer system is equivalent to authentication service; message is explicitly encrypted; based on application identifier (software identifier) and FIDO facet (hash-like first hash identifier); transmitted “along with an authentication response” (authentication code/response)).
Therefore, it would have been obvious to one of ordinary skill in the art before effective filing date of the invention was to modify the teaching of Seibert’s delegated authentication system (signed/encrypted messages with application/software identifiers and hashed identifiers, followed by a access token provision after match) with Nowak’s encrypted challenge message from the authentication service (explicitly combining application identifier, facet/hash-like element and authentication response/code) in order to produce a more complete system for receiving an encrypted message that reliably includes the software identifier, first hash identifier, and authentication code while preventing spoofing and ensuring correct delivery.
As to claims 8 and 15, these are rejected using the similar rationale as for the rejection of claim 1.
As to claim 4, Seibert in view of Nowak discloses the method of claim 1, Nowak further discloses comprising: providing to the user, on a user interface, a prompt to provide the authentication code to the application; and receiving from the user, through the user interface, a user selection of the prompt, wherein providing the authentication code to the application is in response to receiving the user selection of the prompt (“The public key is registered with the online service, and during authentication the client device proves possession of the private key to the service by signing a challenge. Signing a challenge typically involves a user-friendly action such as providing a fingerprint, entering a PIN, or speaking into a microphone.” -e.g., see, Nowak: col. 2, lines 29-47; see also: “The user's device registers the user to a server by registering a public key, and to authenticate the user, the device signs a challenge from the server using the private key that it holds. The keys on the device are unlocked by a local user gesture such as a biometric or pressing a button.” -e.g., see, Nowak: col. 2, lines 5-10; see also: “The user then interacts with the SDK of the user device 110 and provides FIDO authentication data (by interacting with one or more FIDO authenticators associated with the user's smartphone, for example) to satisfy the native authentication application (for example, a biometric application requiring fingerprint data from a FIDO fingerprint reader component).” -e.g., see, Nowak: col. 8, lines 53-67 to col. 9, lines 1-6; see also: “… the user device 110, which typically then displays an “authentication successful” message to the user on a display component.” -e.g., see, col. 9, lines 11-24; herein, the system presents a prompt/requirement for user action (biometric, PIN, gesture, or button press) on the device UI. The user performs the selection/action (“user selection of the prompt”), which unlocks the key and generates the FIDO authentication response. This response is then provided/used as the authentication code for the application. The device UI displays confirmation after successful provision).
Therefore, it would have been obvious to one of ordinary skill in the art before effective filing date of the invention was to modify the teaching of Seibert as taught by Nowak in order to securely trigger and deliver the authentication code, improving both security (user confirmation) and usability.
As to claims 11 and 18, these are rejected using the similar rationale as for the rejection of claim 4.
As to claim 5, Seibert in view of Nowak discloses the method of claim 4, Nowak further discloses wherein the prompt is a first prompt, the user selection is a first user selection, and the method further comprises: providing to the user, through the user interface, a second prompt to provide user education content; receiving from the user, through the user interface, a second user selection of the second prompt; and in response to the second user selection, providing to the user, through the user interface, the user education content, wherein the second prompt is provided to the user prior to providing the first prompt or simultaneously with the first prompt (“The public key is registered with the online service, and during authentication the client device proves possession of the private key to the service by signing a challenge. Signing a challenge typically involves a user-friendly action such as providing a fingerprint, entering a PIN, or speaking into a microphone.” -e.g., see, Nowak: col. 2, lines 29-47; see also: “When the authentication process is successful, in some embodiments the user device displays an “authentication successful” message to the user on a display component.” -e.g., see, Nowak: col. 10, lines 41-50; herein, the system presents user-friendly guidance/actions (which can include contextual/educational information) prior to or alongside the main authentication step; user performs the action/selection, and the device UI provides feedback/content).
Therefore, it would have been obvious to one of ordinary skill in the art before effective filing date of the invention was to modify the teaching of Seibert as taught by Nowak in order to securely trigger and deliver the authentication code, improving both security (user confirmation) and usability.
As to claims 12 and 19, these are rejected using the similar rationale as for the rejection of claim 5.
As to claim 6, Seibert in view of Nowak discloses the method of claim 4, Nowak further discloses wherein the user interface is a first user interface external to the application, and the method further comprises: providing to the user, through the first user interface, the authentication code; and receiving from the user, through the user interface, a copy command to store the authentication code, wherein the application comprises a second user interface, and providing the authentication code to the application comprises receiving from the user, through the second user interface, a paste command of the authentication code to the application (“The user then interacts with the SDK of the user device 110 and provides FIDO authentication data (by interacting with one or more FIDO authenticators associated with the user's smartphone, for example) to satisfy the native authentication application …” -e.g., see, Nowak: col. 7, lines 20-55; see also: “When the authentication process is successful, in some embodiments the user device displays an “authentication successful” message to the user on a display component.” -e.g., see, Nowak: col. 10, lines 41-50; herein, the first UI (device/authenticator) handles generation and display of the response/code; the user interacts (selection/action equivalent to copy), and it is provided to the second UI (the application) via standard transfer (paste equivalent)).
Therefore, it would have been obvious to one of ordinary skill in the art before effective filing date of the invention was to modify the teaching of Seibert as taught by Nowak in order to securely trigger and deliver the authentication code, improving both security (user confirmation) and usability.
As to claims 13 and 20, these are rejected using the similar rationale as for the rejection of claim 6.
As to claim 7, Seibert in view of Nowak discloses the method of claim 6, Nowak further discloses wherein the first user interface is provided to the user as an overlay to the application (“When the authentication process is successful, in some embodiments the user device displays an “authentication successful” message to the user on a display component.” -e.g., see, Nowak: col. 10, lines 41-50; herein, the authentication UI (first user interface) appears on the device display in conjunction with (i.e., overlaying or alongside) the running application).
Therefore, it would have been obvious to one of ordinary skill in the art before effective filing date of the invention was to modify the teaching of Seibert as taught by Nowak in order to securely trigger and deliver the authentication code, improving both security (user confirmation) and usability.
As to claim 14, it is rejected using the similar rationale as for the rejection of claim 7.
Claims 2-3, 9-10 and 16-17 are rejected under 35 U.S.C. 103 as being unpatentable over Seibert in view of Nowak as applied to claim 1, 8 and 15 above, and further in view of Hallam-Baker (US 8,402,519 B2).
As to claim 2, Seibert in view of Nowak discloses the method of claim 1, Seibert further discloses wherein the software identifier is a first software identifier, the message is a first message, the determination is a first determination, and the method further comprises: receiving, from the application, a … message comprising a second software identifier that corresponds to the application; and making a … determination that the first software identifier matches the … software identifier, wherein generating the … hash identifier is based on the second determination (“The authentication module 131 maintains a history of nonces transmitted to a trusted application during the delegated authentication process of an untrusted application. When transmitting requests to the authentication module 131, the trusted and the untrusted application generate a hash of the application identifier of the untrusted application based on the most recently received nonce. The hashed identifier is included in the request.” -e.g., see, Seibert: col. 6, lines 20-36; herein a message from the application with software identifier; match determination enables subsequent hash processing).
Seibert in view of Nowak doesn’t explicitly disclose “the second message from the application” conditioning hash generation for the received auth message.
However, in an analogous art, Hallam-Baker discloses the second message from the application (“FIG. 3 shows an authentication message flow in accordance with an embodiment of the present invention. When the client requests access to the service after completion of the registration phase, the server can use the information generated and stored during registration to easily authenticate the client. The client can obtain and authenticate the service identifier Is and then generate Ics, which can be based upon Is and Ic. For example, the client can generate Ics=MAC(Is,Ic) Ics can be sent from the client to the server. The server can use Ics to lookup the registration nonce, Rc, used for the registration of the client to the particular service. The server can send Rc to the client.” -e.g., see, Hallam-Baker: col. 4, lines 20-52; herein, App-to-service identifier exchange and hash/MAC computation after matching (Ics=MAC(Is,Ic) after service identifier receipt).
Therefore, it would have been obvious to one of ordinary skill in the art before effective filing date of the invention was to modify the teaching of Seibert and Nowak as taught by Hallam-Baker in order to ensure correct app binding before hash/code handling.
As to claims 9 and 16, these are rejected using the similar rationale as for the rejection of claim 2.
As to claim 3, Seibert in view of Nowak and Hallam-Baker discloses the method of claim 2, Seibert further discloses comprising: receiving, from the authentication service, a … message, the … message comprising a … software identifier; making a … determination that the first software identifier does not match the … software identifier; and based on the .. determination, … (“The verification request transmitted by application T 111 includes the application identifier associated with application U 112. Optionally, to indicate the source of the verification request, application T 111 hashes the application identifier included in the verification request using nonce A and signs the request using the private key of application T 111.” -e.g., see col. 7, lines 17-30; herein, Multiple verification/authentication requests (messages) are received containing application/software identifiers; the system performs comparison, if the identifiers/hashes do not match (or request is invalid), the request is not authorized/processed (i.e., discarded/rejected)).
Seibert teaches identifier comparison and rejection of invalid/mismatched requests but does not explicitly describe a “third message” from the authentication service with a non-matching software identifier and explicit “discard” action in all flows.
However, in an analogous art, Nowak discloses mismatched identifier handling leading discarding the third message (“The routing engine 108 also retrieves 314 the application identifier (which should match the application identifier generated during the registration process), generates 316 a correlation identifier, and transmits 318 an “update facets” command to the facet manager 106 (which includes the unique application identifier and the FIDO facet). The correlation identifier is used to bind the FIDO registration request with a FIDO registration response, as the IS core routing logic needs to provide a mapping in order to correctly find where to send subsequent messages.” -e.g., see, Nowak: col. 8, lines 3-34; herein, third message with non-matching software identifier is rejected/discards as part of secure identifier verification in encrypted auth flows)
Therefore, it would have been obvious to one of ordinary skill in the art before effective filing date of the invention was to modify the teaching of Seibert as taught by Nowak in order to improve robustness against spoofed or mismatched messages from the authentication service.
As to claims 10 and 17, these are rejected using the similar rationale as for the rejection of claim 3.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SUMAN DEBNATH whose telephone number is (571)270-1256. The examiner can normally be reached Mon-Fri; 9:00am-5:00pm.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Farid Homayounmehr can be reached at 571-272-3739. 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.
SUMAN DEBNATH
Patent Examiner
Art Unit 2495
/S.D/Examiner, Art Unit 2495
/FARID HOMAYOUNMEHR/Supervisory Patent Examiner, Art Unit 2495
Prosecution Insights