DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
This communication is in response to the RCE filed on 03/19/2026. Claims 1-3, 5-9, 11, 15-17, and 19-23 are currently pending in the application.
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114, Applicant’s submission filed on 03/19/2026 has been entered.
Response to Arguments
Applicant’s arguments with respect to claims 1, 7, and 15 have been considered but are not persuasive. Applicant argued that Xu (US 20200220853) does not disclose verifying by relying party as claimed, but instead discloses verifying by authorization server. This argument is not correct because the authorization server 606 is used in the implementation of Oauth standard which allows an end user to selectively provide the software applications with access to some of the resources stored by a resource server on behalf of the end user without sharing the end user's username or password-see ¶0001. The examiner asserts that the authorization server that receives the verifier and validates the authentication result as disclosed in ¶0029-¶0031, and FIG. 6A is the relying party. This is contained in the final office action pages 3-5. Although, the authorization server 606 is not designated a relying party, it performs the functions of a relying party as claimed by the applicant. An in-depth examination of the Xu reference also reveals that the authorization server in addition to verifying the authentication result through generation and provision of token is an entity that provides access to secure resources as claimed by the applicant. This is disclosed in ¶0001 which states in parts “…The authorization server may be configured to provide the access token based on the end user successfully authenticating with the authorization server and granting permission to a particular software application to access the information.”). The Xu reference does not explicitly disclose a user is being authenticated based on a request from the relying party (authorization server) via the user agent by sending a challenge from the relying party to the authenticator via the user agent and digitally signing, by the authenticator, the challenge before sending the signed challenge to the user agent which in turn forward the signed challenge to the relying party (authorization server). These undisclosed limitations necessitate combination of Xu reference with Stocker reference which discloses these limitations. The motivation for the combination would be for the user with valid WebAuthn authenticator to log into an embedded browser. The use of cryptographic keys to verify user identity such as with WebAuthn authenticator serves as multi-factor authentication (MFA) to resist phishing attack across websites.
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-3, 5-9, 11, 15-17, and 19-23 are rejected under 35 U.S.C. 103 as being unpatentable over US PGPub. No. 20200220853 to Xu et al. (hereinafter Xu) in view of US Pat. No. 11997090 to Stocker et al. (hereinafter Stocker).
Regarding claims 1, 7, and 15, Xu discloses a method, a web authentication system, and a non-transitory computer-readable medium for performing web authentication for a native application (¶0115, FIG. 6A, “login and logout process for a native software application…”) the method comprising:
generating a verifier (¶0127, “at block 610, native application 600 may additionally generate a code verifier and a code challenge. The code verifier may be a random alphanumeric string having a predetermined length, a predetermined minimum length, or another predetermined attribute…”);
deriving a first safety parameter from the verifier (¶0127-¶0128, “…The code challenge may comprise a hash value of the code verifier…”, wherein the code challenge which is a hash value of the code verifier is interpreted as the first safety parameter);
delivering the verifier to a relying party (¶0129, “…At arrow 628, native application 600 may provide the first authorization code and the code verifier. Authorization server 606 may then use this code verifier to compute another code challenge. When the code challenge provided by native application 600 at arrows 612 and 614 matches that computed by authorization server 606, authorization server 606 may generate and provide the access token at block 630…”), wherein the relying party is an entity providing access to secure resources (¶0001, “…The authorization server may be configured to provide the access token based on the end user successfully authenticating with the authorization server and granting permission to a particular software application to access the information.”);
starting a user agent including delivering the first safety parameter to the user agent (¶0120-¶0121, “Based on or in response to receiving the first authorization request at arrow 612, web browser 602 may be configured to transmit the first authorization request to authorization server 606 on behalf of native application 600, as indicated by arrow 614. Additionally, reception of the first authorization request at arrow 612 by web browser 602 may cause web browser application 602 to be brought to a foreground of computing device 608 such that a user interface of web browser application 602 is visible (e.g., this user interface may appear to pop up over that of native application 600)…”, wherein the web browser is interpreted as the claimed user agent), (¶0129, FIG. 6A (612), “The code challenge may be provided by application 600 to authorization server 606 at arrows 612 and 614…”), (¶0113, “A native software application executing on a computing device may utilize a web browser application executing on the same computing device during a login procedure (e.g., OAuth)…”, wherein OAuth is interpreted as a user agent), (¶0180, “the native software application may be further configured to, based on receiving the second instructions, generate a code verifier and a code challenge. The native software application may provide the code challenge to the authorization server by way of the web browser application…”);
performing web authentication with safety controls including (FIG. 6A (614-622), wherein login credentials are considered the claimed safety controls and use of them in 6A (620) for authentication is performing web authentication):
validating the authentication result with the relying party (¶0129-¶0131, FIG. 6A (628-635, wherein the FIRST AUTHORIZATION CODE AND SESSION COOKIE in step 622 sent with code verifier to the authorization server (relying party) in step 628 are the outcomes/result of the authentication process, and the access token is generated after its validation in step 630), wherein validating the authentication result comprises the native application sending the authentication result and the verifier to the relying party, and the relying party validating authentication result received from the native application and the first safety parameter based on a first safety parameter backup derived from the verifier received from the native application (¶0180, “the native software application may be further configured to, based on receiving the second instructions, generate a code verifier and a code challenge. The native software application may provide the code challenge to the authorization server by way of the web browser application. The authorization server may be configured to generate the authorization code based on receiving the code challenge. The native software application may be configured to, based on receiving the authorization code, provide the authorization code and the code verifier to the authorization server. The authorization server may be configured to determine that the authorization code has been transmitted by the native software application based on the code verifier and the code challenge (validation). The native software application may be configured to receive, from the authorization server, the second access token.”), (¶0181, “the code verifier may include a random string having a predetermined minimum length. The code challenge may include a cryptographic hash value of the code verifier.”, wherein the cryptographic hash value of the code verifier serves as safety parameter backup since it is very difficult to reverse the process, see ¶0128), see also ¶0129 wherein the authorization server stores the code challenge(backup);
However, Xu does not explicitly disclose the following limitation:
authenticating a user by an authenticator in response to a request from the relying party via the user agent by:
sending a challenge from the relying party to the authenticator via the user agent;
digitally signing, by the authenticator, the challenge and sending the signed challenge to the user agent;
delivering an authentication result comprising the signed challenge to the relying party from the user agent;
Stocker discloses wherein the relying party is an entity providing access to secure resources (Coln.2, lines 32-40, “the login prompt information includes a challenge and a Relying Party (RP) identifier (RPID)…”), (COLn.5, lines 8-21, “the challenge is a nonce that is unique to each transaction. The challenge may include a random value generated by the RP for WebAuthn authenticator 160 to sign as part of the authentication assertion. In some embodiments, the RPID refers to the server that provides access to a secure software application…”);
authenticating a user by an authenticator in response to a request from the relying party via the user agent (Coln.4, lines 63-67-Coln.5, lines 1-7, “authentication service 130 generates login prompt information 132. Login prompt information 132 is any information that may be used to generate a WebAuthn request…”), (Coln.7, lines 3-23, “…After processing WebAuthn credential requests 152, WebAuthn authenticators 160 generate WebAuthn responses 162. WebAuthn responses 162 include the metadata required to validate an authenticator assertion…”) by:
sending a challenge from the relying party to the authenticator via the user agent (FIG. 2, Coln.9, lines 3-16, “Upon receiving login prompt information 132 from local browser 140a, local WebAuthn proxy 150a generates WebAuthn credential request 152 using login prompt information 132. For example, local WebAuthn proxy 150a may format WebAuthn credential request 152 using login prompt information 132. WebAuthn credential request 152 may include the RPID, the challenge, a client data hash, etc. At step 225 of flow diagram 200, local WebAuthn proxy 150a requests WebAuthn response 162 on behalf of local browser 140a by communicating WebAuthn credential request 152 to WebAuthn authenticator 160a…”, wherein the Authentication service 130 is interpreted as the claimed relying party (RP), Local Browser 140a and Local WebAuthn Proxy are the user agents, and WebAuthn Authenticator 160a is the claimed authenticator);
digitally signing, by the authenticator, the challenge and sending the signed challenge to the user agent (FIG.2, Coln.7, lines 3-23, “…For example, WebAuthn responses 162 may include an authenticator assertion, a reply TXID, authenticator data, client data, a signature, a credential ID, a combination thereof, or any other suitable information. The authenticator data is a structure that encodes contextual bindings made by WebAuthn authenticators 160. The client data is an attribute that includes a JSON-compatible serialization of the client data. The signature includes the raw signature returned from WebAuthn authenticators 160…”)
delivering an authentication result comprising the signed challenge to the relying party from the user agent (FIG.2, steps 235-245, “Coln.9, lines 29-45, “At step 235 of flow diagram 200, WebAuthn authenticator 160a communicates WebAuthn response 162 to local WebAuthn proxy 150a. Local WebAuthn proxy 150a then communicates WebAuthn response 162 to local browser 140a over the HTTPS connection at step 240 of flow diagram 200. When the login prompt in local browser 140a receives WebAuthn response 162, local browser 140a communicates WebAuthn response 162 to authentication service 130 at step 245 of flow diagram 200. Authentication service 130 finalizes the authentication by verifying WebAuthn response 162 at step 250 of flow diagram 200…”);
Thus, one of ordinary skill in the art would have found it obvious before the effective filing date of applicant’s claimed invention to modify the method, the web authentication system, and the non-transitory computer-readable medium of Xu to include authenticating a user by an authenticator in response to a request from a relying party via the user agent as disclosed by Stocker and be motivated in doing so in order to allow a user with a valid WebAuthn authenticator to log into an embedded browser and/or remote computer via a WebAuthn proxy-Stocker Coln.3, lines 21-30 in parts. The use of cryptographic keys to verify user identity such as with WebAuthn authenticator serves as multi-factor authentication (MFA) to resist phishing attack across websites.
Regarding claims 2, 8, and 16, Xu in view of Stocker discloses the method, the web authentication system, and the non-transitory computer-readable medium of claims 1, 7, and 15 respectively.
Xu further discloses wherein the performing of the web authentication includes the native application obtaining a second safety parameter backup from the relying party via the user agent (¶0137, “Based on or in response to receiving the second authorization code (second safety parameter), web browser 602 (user agent) may be configured to transmit, to native application 600, the second authorization code received from authorization server 606, as indicated by arrow 650. In some implementations, authorization server 606 may provide the second authorization code to native application 600 directly, thus consolidating the operations of arrows 650 and 648…”), and
the starting a user agent further includes generating a second safety parameter and delivering the second safety parameter to the user agent (¶0122, “…Based on or in response to validating the login credentials at block 620, authorization server 606 may be configured to generate and transmit, to web browser 602, (i) a first authorization code and (ii) a session cookie.”, wherein the session cookie is interpreted as the second safety parameter, the web browser 602 being the user agent based on applicant’s specification in paragraph 20 wherein a web browser is a user agent), see also ¶0143-¶0144 wherein the authorization server 606 may provide web browser 602 with an updated session cookie at arrow 714, and
the method further comprises:
the native application validating the second safety parameter based on the second safety parameter backup (¶0127, “in another implementation, native application 600 may utilize the Proof Key for Code Exchange standard instead of storing the client secret on computing device 608. Namely, at block 610, native application 600 may additionally generate a code verifier and a code challenge.”), (¶0134-¶0137, FIG. 6B (652-659).
Regarding claims 3, 9, and 17, Xu in view of Stocker discloses the method, the web authentication system, and the non-transitory computer-readable medium of claims 2, 8, and 16 respectively.
Xu further discloses wherein the validating of the authentication result includes the native application obtaining a third safety parameter backup directly from the relying party (¶0137, “…authorization server 606 may provide the second authorization code to native application 600 directly, thus consolidating the operations of arrows 650 and 648…”), (¶0136, FIG. 6B, “…authorization server 606 may be configured to transmit, to web browser 602, a second authorization code, as indicated by arrow 648…”, wherein the authorization server that allow access to requested resource is interpreted as the relying party in accordance with ¶0026 of applicant’s specification)
the starting a user agent further includes generating a third safety parameter (¶0137, “… Authorization server 606 may in turn generate a second access token, as indicated by block 654,…”, wherein the second access token is the same as the second authorization code as disclosed in ¶0144, 172, 12, and 13) and delivering the third safety parameter to the user agent (¶0136, FIG. 6B, “…authorization server 606 may be configured to transmit, to web browser 602, a second authorization code, as indicated by arrow 648…”), and
the method further comprises:
the native application validating the third safety parameter based on the third safety parameter backup (¶0127, “in another implementation, native application 600 may utilize the Proof Key for Code Exchange standard instead of storing the client secret on computing device 608. Namely, at block 610, native application 600 may additionally generate a code verifier and a code challenge.”), (¶0134-¶0137, FIG. 6B (652-659).
Regarding claims 5, 11, and 19, Xu in view of Stocker discloses the method, the web authentication system, and the non-transitory computer-readable medium of claims 3, 9, and 17 respectively.
Xu further discloses:
wherein the performing of the web authentication includes the native application obtaining a status from the user agent (¶0124, FIG. 6A, steps 620-626, “…Similarly, based on or in response to receiving the authorization code at arrow 622, web browser 602 may be configured to forward the authorization code to native application 600, as indicated by arrow 626…”, wherein the native application obtain the status of the login credential in form of authorization code from the web browse (user agent), see also ¶0143, FIG. 7, steps 712-718), (¶0092, “remote network management platform 320 may first determine what devices are present in managed network 300, the configurations and operational statuses of these devices…”), the method further comprising:
the native application conducting error handling when the status is indicative of a user agent error (¶0006-¶0007, “… once the native software application has been logged out, it may be configured to cause the authorization server to log the web browser application out before initiating a subsequent login procedure. That is, the native software application may generate and transmit, by way of the web browser application and to the authorization server, instructions configured to cause the authorization server to terminate any active browser-server sessions before starting another login procedure.”), (¶0067, “virtual machines 308 may be managed by a centralized server device or application that facilitates allocation of physical computing resources to individual virtual machines, as well as performance and error reporting…”)
wherein the web authentication is complete when the authentication result, the second safety parameter, and the third safety parameter are validated, and the status is indicative of no user agent error (FIG. 6A and FIG. 6B, ¶0115-¶0138, wherein the native application 600 is provided with the requested resource after the validation/verification of session cookie (second safety parameter) at step 646 and second access token (third safety parameter) at step 659, and providing the requested resource to the native application is an indication of no user agent error.
Regarding claims 6 and 20 Xu in view of Stocker discloses the method, the web authentication system, and the non-transitory computer-readable medium of claims 1 and 15 respectively.
Xu further discloses further comprising:
the native application starting a first session with the relying party (¶0173, “…The first session may also include an application-server session established between the native software application and the authorization server…”);
the native application launching the user agent to establish a second session with the relying party (¶0012, “…The method may additionally involve, at a second time later than the first time, receiving, by the native software application, second instructions to authorize a second session by way of the authorization server…”), (¶0169, FIG. 9, “Block 904 involves, at a second time later than the first time, receiving, by the native software application, second instructions to authorize a second session by way of the authorization server.”), (¶0176, “…The native software application may be further configured to, at a third time later than the second time and while the native software application has not been logged out of the second session, receive fourth instructions to authorize a third session by way of the authorization server…”);
registering a web authentication credential (¶0121, FIG. 6A, “…Reception of the login page at arrow 616 may cause web browser 602 to display the login page in the user interface displayed when web browser 602 is brought into the foreground. The login page may define one or more text input regions configured to receive login credentials (e.g., username and password) associated with authorization server 606…”); and
the user agent redirecting back to the native application (¶0002, “…Namely, the native software application may, by way of the web browser, transmit to the authorization server a request for an authorization code. The web browser may then be used to provide login credentials to the authorization server, receive therefrom an authorization code, and pass this authorization code back to the native software application…”).
Regarding claim 21, Xu in view of Stocker discloses the method of claim 1.
Xu further discloses wherein the authenticating of the user by the authenticator is performed during a login process between the user agent and the relying party (¶0121-¶0123, FIG. 6A, steps 614-622, “…The session cookie may be an HTTP cookie that includes an identifier which authorization server 606 associates with web browser 602. The cookie allows authorization server 606 to remember information about web browser 602. In this case, the session cookie allows authorization server 606 to remember that web browser 602 provided valid login credentials and is thus logged in for a predetermined period of time (e.g., 30 minutes)”, wherein the authorization server that determines whether web browser and/or native application should be allowed to log in or proceed further in the login process based on login credentials is interpreted as the authenticator and the relying party and wherein the web browser 602 is the user agent as explained earlier based on applicant disclosure on user agent being a web browser.).
Regarding claim 22, Xu in view of Stocker discloses the method of claim 21.
Stocker further discloses wherein the authenticator is built in a device where the native application is built (FIG. 3, Coln.10, lines 16-32, wherein the Local WebAuthn proxy 150a which is a device health application (native application) and the authenticator 160 are both installed on local device 160a).
Thus, one of ordinary skill in the art would have found it obvious before the effective filing date of applicant’s claimed invention to modify the method of Xu and Stocker to include building an authenticator in the mobile device hosting the native application as disclosed by Stocker and be motivated in doing so in order to have a compacted system that allows a user to access multiple applications with one set of login credentials.
Regarding claim 23, Xu in view of Stocker discloses the method of claim 21.
Xu further discloses wherein the authenticating of the user is performed between the authenticator and the user agent (¶0121-¶0123, FIG. 6A, steps 614-622, “…The session cookie may be an HTTP cookie that includes an identifier which authorization server 606 associates with web browser 602. The cookie allows authorization server 606 to remember information about web browser 602. In this case, the session cookie allows authorization server 606 to remember that web browser 602 provided valid login credentials and is thus logged in for a predetermined period of time (e.g., 30 minutes)”, wherein the authorization server that determines whether web browser and/or native application should be allowed to log in or proceed further in the login process based on login credentials is interpreted as the authenticator/relying party and wherein the web browser 602 is the user agent as explained earlier based on applicant disclosure on user agent being a web browser.).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. US. 20200213297.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MUDASIRU K OLAEGBE whose telephone number is (571)272-2082. The examiner can normally be reached MON-FRI. 7.30AM-5.30PM.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Farid Homayounmehr can be reached at 5712723739. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/MUDASIRU K OLAEGBE/Examiner, Art Unit 2495
/FARID HOMAYOUNMEHR/Supervisory Patent Examiner, Art Unit 2495
Prosecution Insights