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 action is responsive to communication received on 12/15/2025 Claims 1-20 are pending of which claims 1, 8 and 15 are amended.
The Examiner recommends filing a written authorization for Internet communication in response to the present action. Doing so permits the USPTO to communicate with Applicant using Internet email to schedule interviews or discuss other aspects of the application. Without a written authorization in place, the USPTO cannot respond to Internet correspondence received from Applicant. The preferred method of providing authorization is by filing form PTO/SB/439, available at: https://www.uspto.gov/patent/forms/forms. See MPEP § 502.03 for other methods of providing written authorization.
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claims 1-20 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention. The claims recited “performing a second verification indication by validating, based at least in part on the credential obtained from the second device, proximity of the first device and the second device;”. There is no support in the specification for the use of a credential to validate the proximity of the first device and the second device. The specification describes that a local host listener is used to determine that the first and second device are on(i.e. co-located) the same device but there is nothing in the specification that ascribes determination of proximity between he first and second device using a credential in a second verification. Thus claims 1,8 and 15 are rejected for reciting new matter and based on their dependence claims 2-7, 9-14 and 16-20 are rejected based on their dependence to claims 1, 8 and 15.
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.
Claims 1-20 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. . The claims recited “performing a second verification indication by validating, based at least in part on the credential obtained from the second device, proximity of the first device and the second device;”. The claim appears to combine tow different elements of the disclosure that are separate and distinct. The specification(¶28) describes a second verification using a local listener and a first verification by verifying origin. Thus the first and second verifications are with respect to verifying origin and verifying the local host and while the paragraph mentions a credential provided by the second device. The specification recites obtaining a credential for use in authentication but is this appears to be separate from the verification of origin and local-host listener. Thus it is unclear to the examiner the metes and bounds of the claim and thus the claims are indefinite.
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.
Claims 1,5 8, 12, 15 and 19 is/are rejected under 35 U.S.C. 103 as being unpatentable over Kaplan US 2016/0255088 , and further in view of Chen 2016/0156700.
Regarding claims 1, 8 and 15, Kaplan teaches a method , non-transitory CRM and an apparatus, comprising: one or more processors; and one or more computer-readable non-transitory storage media comprising instructions that, when executed by the one or more processors, cause one or more components of the apparatus to perform operations comprising: receiving an authorization request from a first device to access a resource(user initiates login request to content management system request content access, ¶23 )
[0023] The disclosed technology addresses the need in the art for authenticating users of online content management systems. FIG. 1 shows a block diagram of an exemplary login process with content management system 102. Exemplary system 100 consists of content management system 102 and one or more client devices, including client device 104. Content management system 102, as will be discussed later, can run on server 106 or a group of servers. Server 106 can store information for various user accounts that are registered with content management system 102. The user accounts may be managed by an account management module or user account database of content management system 102. The user accounts are tied to individual users, clients, members, or subscribers that use the services provided by content management system 102. The user accounts hold information about respective users' profiles, credentials, synchronized data, membership information, etc. For example, user A's account 108 may hold information about the exemplary user A's profiles (e.g., name, address, email address, phone number, etc.), login credentials (e.g., username, password, security questions, cryptographic nonces, etc.), synchronized data (e.g., files, folders, documents, etc.), and membership information (e.g., date joined, membership tier, subscription status, billing information, standing, etc.). Server 106 can also have web server 110 that can generate and service static and dynamic webpages for any client software, such as a web browser, that may attempt to access content management system 102 via a web interface and/or the Hypertext Transfer Protocol (HTTP). Web server 110 can be part of content management system's 102 communications interface and/or user interface module.
performing a first verification indication by validating, using a localhost listener, the authorization request by verifying an origin header of the authorization request based on a plurality of Uniform Resource Locators (URLs) in a trusted domain(verify using origin header that request comes from same domain as content system, ¶30,36)
[0030] After client application 112 receives the request for the user account identifying information, client application 112 may attempt to verify whether the request originates from a legitimate source. In other words, client application 112 may try to find out if the request actually comes from within client device 104 and presumably from user A, who owns client device 104, and not from any malicious entity outside client device 104. This determination can be done in several ways. For instance, web browser 116 can simply announce its identity to client application 112. In other situations, client application 112 can examine the list of processes that are running on client device 104 and determine the identity of the application that sent the request. The identity of the application may be compared against a list of known web browsers. Client application 112 can locate the executable file of web browser 116, compute its cryptographic signature, and confirm that it is, in fact, signed by a known publisher of web browser, such as Google®, Microsoft®, Apple®, etc. This can prevent a malicious attacker from creating a bogus executable with the same name and trying to pass it off as a legitimate web browser. Client application 112 may also examine the origin header associated with the request from web browser 116 to make sure that the webpage that is referencing local host server 114 originates from a domain name associated with content management system 102 (e.g., examplecms.com). Client application 112 can also cross-reference any information that it collected about the originator of the request with any information that content management system 102 may be able to provide. For example, content management system 102 may be able to provide to client application 112 any identifying information about web browser 116 when it navigated to web server 110 earlier. In certain situations, client application 112 may omit the request verification steps.
[0036] Client application 310 can operate a local web server (not shown). The local web server can be a component of client application 310 that runs in the background and hidden from the view of the user. Other applications 304 running on client device 202, such as a web browser, can make a local host connection to the local web server by referencing the localhost IP address (i.e., 127.0.0.1). The local web server can be configured to listen in on the specific port number (e.g., 5500) or a range of port numbers for any incoming local connection request.
performing a second verification indication by validating based at least in part on the credential obtained from the second device proximity of the first device and the second device(in addition to verifying domain(first verification) the system determines if request is from local connection i.e. received from local listener, second verification, indicating that request originates locally within the device, ¶49)
and in response to determining the first device is co-located with the second device, approving the authorization request(if both domain and requester and client application are on same device then request is legitimate, ¶s49).
[0049] System 900 can receive a request from a web browser to establish a communication channel between the web browser and the client application (804). The request can be received by the client application. The client application and the web browser may be both running on the same client device. The client application can run a local web server, and the communication channel can be a local host connection between the web browser and the local web server. The client application can verify that the request comes from a legitimate source (806) prior to establishing the local connection (806). Alternatively, the verification may take place after the establishment of the local connection (806), but prior to providing user account identifying information (810). In either case, the client application may refuse to provide the user account identifying information to the web browser if the verification is unsuccessful. The determination of the legitimacy of the source of request can be performed by, for example, verifying that the request originates from a local connection within the client device. It can be also determined by checking to see whether the request comes from a website associated with the content management system (e.g., examplecms.com). Since the request may be contained in a webpage generated by the content management system and downloaded by the web browser, the client application can, for example, examine the origin header included in the webpage document to determine the request's legitimacy. System 900 can also verify the legitimacy of the request's originator by determining whether the request comes from a known web browser. For example, the content management system can assist with this determination because the content management system may have already communicated with the web browser that is making the request.
Kaplan teaches validating the authorization request but does no teach in response to determining the authorization request is valid, obtaining a credential associated with the authorization request from a second device. Chen in the same field of endeavor as the invention teaches a system for authentication secure network access. Chen teaches in response to determining the authorization request is valid, obtaining a credential associated with the authorization request from a second device(a CSRF token is granted to the user/client as a second additional step to verification of origin to authenticate the request, ¶s44,45,46,53).
[0044] The validation process 540, in one implementation, checks for the origin of the request. For example, the request, which originates from the App on the cloud, sent by the browser is checked for its origination. This is to determine if the request originating from the browser on the client device (client or requestor) from the App in the application server is authorized to access the local resource server. In one implementation, the origin of the request or the requestor is checked using cross-origin resource sharing (CORS). For example, a determination may be made as to whether the requestor is authorized to access the local server. The validation process using, for example, CORS, improves security as compared to if any requestor can access the local resource server. Other types of authorization process may also be useful.
[0045] The authentication process 550 is used to authenticate the client request. For example, the authentication process is a secondary security process which is performed. In one implementation, the authentication process may include HTTP Basic Authentication, Digest, client certificate, SAML Token Profile or Hawk authentication. Other authentication processes by the local server may also be useful. For example, if a certificate is not available, authentication can be based on public/private keys.
[0046] As for the fraud prevention process 560, in one implementation, it employs cross-site-request forgery (CSRF) protection. For example, CSRF is performed for HTTP(S) requests. CSRF includes generating a token and granting it to the client. The client then sends the request along with the token to the local server.
[0053] The local server performs authentication. For example, the local server performs an analysis process, as described in step 535 or FIG. 5. Other types of analysis or authentication processes may also be useful. Once the local server authenticates the initial request, it may generate a CSRF token to the client at step 650. Providing other types of security may also be useful. If the initial request is not authenticated, it is rejected and the process returns to step 620.
It would have been obvious to a person of ordinary skill in the art at the time of the effective filing of the instant application to modify Kaplan with transmission of a security token such as a CSRF token as taught by Chen. The reason for this modification would be to provide additional security authentication step(i.e multi factor authentication) that provide stronger authentication against cross-site request forgery.
Regarding claims 5, 12 and 19, Kaplan teaches sending a request to the localhost listener to check an origin header on the authorization request using the plurality of URLs in the trusted domain(verify using origin header that request comes from same domain as content system, ¶s30,49)
comparing, using the localhost listener, the origin header of the authorization request to the plurality of URLs in the trusted domain(verify using origin header that request comes from same domain as content system, ¶s30,49)
and in response to determining the origin header of the authorization request matches the plurality of URLs in the trusted domain, determining the authorization request is valid(verify using origin header that request comes from same domain as content system, ¶s30,49)
[0030] After client application 112 receives the request for the user account identifying information, client application 112 may attempt to verify whether the request originates from a legitimate source. In other words, client application 112 may try to find out if the request actually comes from within client device 104 and presumably from user A, who owns client device 104, and not from any malicious entity outside client device 104. This determination can be done in several ways. For instance, web browser 116 can simply announce its identity to client application 112. In other situations, client application 112 can examine the list of processes that are running on client device 104 and determine the identity of the application that sent the request. The identity of the application may be compared against a list of known web browsers. Client application 112 can locate the executable file of web browser 116, compute its cryptographic signature, and confirm that it is, in fact, signed by a known publisher of web browser, such as Google®, Microsoft®, Apple®, etc. This can prevent a malicious attacker from creating a bogus executable with the same name and trying to pass it off as a legitimate web browser. Client application 112 may also examine the origin header associated with the request from web browser 116 to make sure that the webpage that is referencing local host server 114 originates from a domain name associated with content management system 102 (e.g., examplecms.com). Client application 112 can also cross-reference any information that it collected about the originator of the request with any information that content management system 102 may be able to provide. For example, content management system 102 may be able to provide to client application 112 any identifying information about web browser 116 when it navigated to web server 110 earlier. In certain situations, client application 112 may omit the request verification steps.
[0049] System 900 can receive a request from a web browser to establish a communication channel between the web browser and the client application (804). The request can be received by the client application. The client application and the web browser may be both running on the same client device. The client application can run a local web server, and the communication channel can be a local host connection between the web browser and the local web server. The client application can verify that the request comes from a legitimate source (806) prior to establishing the local connection (806). Alternatively, the verification may take place after the establishment of the local connection (806), but prior to providing user account identifying information (810). In either case, the client application may refuse to provide the user account identifying information to the web browser if the verification is unsuccessful. The determination of the legitimacy of the source of request can be performed by, for example, verifying that the request originates from a local connection within the client device. It can be also determined by checking to see whether the request comes from a website associated with the content management system (e.g., examplecms.com). Since the request may be contained in a webpage generated by the content management system and downloaded by the web browser, the client application can, for example, examine the origin header included in the webpage document to determine the request's legitimacy. System 900 can also verify the legitimacy of the request's originator by determining whether the request comes from a known web browser. For example, the content management system can assist with this determination because the content management system may have already communicated with the web browser that is making the request.
Claims 2-4, 6-7, 9-11,13-14, 16-18 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Kaplan/Chen as applied to claims 18 and 15 above, and further in view of Lind US 20250226985.
Regarding claims 2, 9, and 16, Kaplan/Chen do not teach in response to determining the authorization request is invalid, rejecting the authorization request and stopping the localhost listener. Lind in the same field of endeavor as the invention teaches a system for phishing resistant authentication. Lind teaches in response to determining the authorization request is invalid, rejecting the authorization request and stopping the localhost listener(the local server is ephemeral implying that it is meant to be removed upon after a period of time, or as implied that its removed after the authentication processes succeeds or fails ie. it is tarted for the authentication process and closed afterwards., ¶s114,115,116).
[0114] In some examples, at 560, the authenticator application 510 may stop (e.g., deactivate, destroy, discard) the ephemeral server. That is, the authenticator application 510 may create the ephemeral server at 545, use the ephemeral server for a threshold duration (e.g., to resolve the second authentication challenge received at 550), and then may discard the ephemeral server at 560. In some examples, the authenticator application 510 may transition from the active state to an inactive state after stopping the ephemeral server (e.g., to reduce a quantity of time during which the authenticator application 510 may be running in the background of the client device 505)..
[0115] At 565, the authentication service 520 may transmit an access response based on the authentication response received at 555. In some examples, the access response may be responsive to the first access request and the second access request. For example, the authentication service 520 may include an authentication token (e.g., requested via the second access request) for access to the resource (e.g., request via the first access request) based on a determination of whether the origin is authorized for requesting access to the resource. In some examples, the authentication service 520 may determine that the website 525 (e.g., the origin of the first access request) is not included in the allow list and, as such, may determine that the website 525 is not authorized for requesting access to the resource. In such an example, the access response transmitted at 565 may include an error. Alternatively, the authentication service 520 may determine that the website 525 is included in the allow list and, as such, may determine that the website 525 is authorized for requesting access to the resource (e.g., is a proper authentication server site). In such an example, the access response transmitted at 565 may include the authentication token (e.g., an access token, a token usable for authenticating the identity of the end-user), which the authenticating application 511 may use to gain access to (e.g., get) the resource.
[0116] In some examples, at 570, the authenticating application 511 may transmit the authentication token to the resource server 515, such that the end-user may access the resource on the website 525. In some examples, using the ephemeral server to resolve the authentication challenge may provide a phishing-resistant authenticator flow for unmanaged devices (e.g., using HTTPS). Additionally, a quantity of time during which an application may be run in the background on a mobile device may be constrained. As such, running an always-on solution on the mobile device may be impractical due to resource constraints. Accordingly, using the ephemeral server, which may be active for a threshold quantity of time (e.g., a fixed quantity of time, a pre-configured quantity of time), to resolve authentication challenges may consume less resources and improve the performance of the client device 505 (e.g., a mobile device), among other benefits.
It would have been obvious to a person of ordinary skill in the art at the time of the effective filing of the instant application to modify Kaplan/Chen with an ephemeral local host listener as taught by Lind. The reason for this modification would be to recover computing resources after the authentication process fails or is completed.
Regarding claims 3, 10, and 17, Kaplan/Chen do not teach in response to determining the first device is not co-located with the second device, rejecting the authorization request and stopping the localhost listener. Lind in the same field of endeavor as the invention teaches a system for phishing resistant authentication. Lind teaches in response to determining the first device is not co-located with the second device, rejecting the authorization request and stopping the localhost listener(the local server is ephemeral implying that it is meant to be removed upon after a period of time, or as implied that its removed after the authentication processes succeeds or fails ie. it is tarted for the authentication process and closed afterwards., ¶s114,115,116).
[0114] In some examples, at 560, the authenticator application 510 may stop (e.g., deactivate, destroy, discard) the ephemeral server. That is, the authenticator application 510 may create the ephemeral server at 545, use the ephemeral server for a threshold duration (e.g., to resolve the second authentication challenge received at 550), and then may discard the ephemeral server at 560. In some examples, the authenticator application 510 may transition from the active state to an inactive state after stopping the ephemeral server (e.g., to reduce a quantity of time during which the authenticator application 510 may be running in the background of the client device 505)..
[0115] At 565, the authentication service 520 may transmit an access response based on the authentication response received at 555. In some examples, the access response may be responsive to the first access request and the second access request. For example, the authentication service 520 may include an authentication token (e.g., requested via the second access request) for access to the resource (e.g., request via the first access request) based on a determination of whether the origin is authorized for requesting access to the resource. In some examples, the authentication service 520 may determine that the website 525 (e.g., the origin of the first access request) is not included in the allow list and, as such, may determine that the website 525 is not authorized for requesting access to the resource. In such an example, the access response transmitted at 565 may include an error. Alternatively, the authentication service 520 may determine that the website 525 is included in the allow list and, as such, may determine that the website 525 is authorized for requesting access to the resource (e.g., is a proper authentication server site). In such an example, the access response transmitted at 565 may include the authentication token (e.g., an access token, a token usable for authenticating the identity of the end-user), which the authenticating application 511 may use to gain access to (e.g., get) the resource.
[0116] In some examples, at 570, the authenticating application 511 may transmit the authentication token to the resource server 515, such that the end-user may access the resource on the website 525. In some examples, using the ephemeral server to resolve the authentication challenge may provide a phishing-resistant authenticator flow for unmanaged devices (e.g., using HTTPS). Additionally, a quantity of time during which an application may be run in the background on a mobile device may be constrained. As such, running an always-on solution on the mobile device may be impractical due to resource constraints. Accordingly, using the ephemeral server, which may be active for a threshold quantity of time (e.g., a fixed quantity of time, a pre-configured quantity of time), to resolve authentication challenges may consume less resources and improve the performance of the client device 505 (e.g., a mobile device), among other benefits.
It would have been obvious to a person of ordinary skill in the art at the time of the effective filing of the instant application to modify Kaplan/Chen with an ephemeral local host listener as taught by Lind. The reason for this modification would be to recover computing resources after the authentication process fails or is completed.
Regarding claims 4, 11, and 18, Kaplan/Chen running a local host server but does not specifically teach that the local server is spun upon receiving the request thus Kaplan/Chen do not teach in response to receiving the authorization request, spinning up the localhost listener inside a mobile application of the first device, wherein the localhost listener is a web server. Lind in the same field of endeavor as the invention teaches a system for phishing resistant authentication. Lind teaches in response to receiving the authorization request, spinning up the localhost listener inside a mobile application of the first device, wherein the localhost listener is a web server(an ephemeral server is started i.e. spun up upon the authentication request, ¶95).
[0095] In some other examples, the authentication service 420 (and the authenticator application 410) may support on-device authentication using an ephemeral server 415. For example, as illustrated in the example of FIG. 4, the end-user may open a website 425 via the authenticating application 411. Additionally, the end-user may attempt to access a resource protected by the authentication service 420 via the website 425. Accordingly, while on the website 425, the authenticating application 411 may transmit an access request 435 to the authentication service 420. The access request 435 may request access (by the end-user) to the protected resource. In response to receiving the access request 435, the authentication service 420 may issue an authentication challenge 440-a to the authenticating application 411 via a connection 430-a (e.g., a network connection). The authentication challenge 440-a may request that the authenticating application verify (e.g., prove) the identity of the end-user using an authenticator (e.g., a phishing-resistant authenticator, such as the authenticator application 410) for access to the resource in accordance with the access request 435. Accordingly, to satisfy the authentication challenge, the authenticating application 411 may use the authenticator application 410 to verify the identity of the end-user for access to the resource. For example, the authenticating application 411 may transmit an indication to the authenticator application 410 to activate (e.g., generate, start) an ephemeral server 415 for authenticating (e.g., validating) the identity of the end-user for access to the resource. That is, the authenticating application 411 may trigger (e.g., using an indication or some other mechanism) the authenticator application 410 to activate the ephemeral server 415 for authenticating the identity of the end-user. In some examples, the authenticating application 411 may trigger activation of the authenticator application 410 on the client device 405 (e.g., may trigger the authenticator application 410 to transition from an idle state to an active state) and, while operating in the active state (e.g., after starting up), the authenticator application 410 may generate (e.g., start) the ephemeral server 415.
It would have been obvious to a person of ordinary skill in the art at the time of the effective filing of the instant application to modify Kaplan/Chen with starting ephemeral server as taught by Lind for the local host listener of Kaplan. The reason for this modification would be to preserve computing resources by running an ephemeral server for authentication on demand.
Regarding claims 6, and 13, Kaplan/Chen do not teach in response to determining the origin header of the authorization request does not match the plurality of URLs in the trusted domain, determining the authorization request is invalid and stopping the localhost listener. Lind in the same field of endeavor as the invention teaches a system for phishing resistant authentication. Lind teaches in response to determining the origin header of the authorization request does not match the plurality of URLs in the trusted domain, determining the authorization request is invalid and stopping the localhost listener(the local server is ephemeral implying that it is meant to be removed upon after a period of time, or as implied that its removed after the authentication processes succeeds or fails ie. it is tarted for the authentication process and closed afterwards., ¶s114,115,116).
[0114] In some examples, at 560, the authenticator application 510 may stop (e.g., deactivate, destroy, discard) the ephemeral server. That is, the authenticator application 510 may create the ephemeral server at 545, use the ephemeral server for a threshold duration (e.g., to resolve the second authentication challenge received at 550), and then may discard the ephemeral server at 560. In some examples, the authenticator application 510 may transition from the active state to an inactive state after stopping the ephemeral server (e.g., to reduce a quantity of time during which the authenticator application 510 may be running in the background of the client device 505)..
[0115] At 565, the authentication service 520 may transmit an access response based on the authentication response received at 555. In some examples, the access response may be responsive to the first access request and the second access request. For example, the authentication service 520 may include an authentication token (e.g., requested via the second access request) for access to the resource (e.g., request via the first access request) based on a determination of whether the origin is authorized for requesting access to the resource. In some examples, the authentication service 520 may determine that the website 525 (e.g., the origin of the first access request) is not included in the allow list and, as such, may determine that the website 525 is not authorized for requesting access to the resource. In such an example, the access response transmitted at 565 may include an error. Alternatively, the authentication service 520 may determine that the website 525 is included in the allow list and, as such, may determine that the website 525 is authorized for requesting access to the resource (e.g., is a proper authentication server site). In such an example, the access response transmitted at 565 may include the authentication token (e.g., an access token, a token usable for authenticating the identity of the end-user), which the authenticating application 511 may use to gain access to (e.g., get) the resource.
[0116] In some examples, at 570, the authenticating application 511 may transmit the authentication token to the resource server 515, such that the end-user may access the resource on the website 525. In some examples, using the ephemeral server to resolve the authentication challenge may provide a phishing-resistant authenticator flow for unmanaged devices (e.g., using HTTPS). Additionally, a quantity of time during which an application may be run in the background on a mobile device may be constrained. As such, running an always-on solution on the mobile device may be impractical due to resource constraints. Accordingly, using the ephemeral server, which may be active for a threshold quantity of time (e.g., a fixed quantity of time, a pre-configured quantity of time), to resolve authentication challenges may consume less resources and improve the performance of the client device 505 (e.g., a mobile device), among other benefits.
It would have been obvious to a person of ordinary skill in the art at the time of the effective filing of the instant application to modify Kaplan/Chen with an ephemeral local host listener as taught by Lind. The reason for this modification would be to recover computing resources after the authentication process fails or is completed.
Regarding claims 7, 14 and 20 Kaplan/Chen do not teach performing a two-factor authentication approach to obtain the credential from the second device. Lind in the same field of endeavor as the invention teaches a system for phishing resistant authentication. Lind teaches performing a two-factor authentication approach to obtain the credential from the second device(multifactor authentication is supported for access authentication, ¶47,52).
[0047] The identity management system 120 may support one or more services, such as a single sign-on (SSO) service 155, a multi-factor authentication (MFA) service 160, an application programming interface (API) service 165, a directory management service 170, or a provisioning service 175 for various on-premises applications 110 (e.g., applications 110 running on compute resources of the on-premises system 115) and/or cloud applications 110 (e.g., applications 110 running on compute resources of the cloud system 125), among other examples of services. The SSO service 155, the MFA service 160, the API service 165, the directory management service 170, and/or the provisioning service 175 may be individually or collectively provided (e.g., hosted) by one or more physical machines, virtual machines, physical servers, virtual (e.g., cloud) servers, data centers, or other compute resources managed by or otherwise accessible to the identity management system 120. In some examples, the identity management system 120 may support a database system such as a multi-tenant database system. In such cases, the identity management system may serve multiple client devices 105 with a single instance of software. However, other types of systems may be implemented, including—but not limited to—client-server systems, mobile device systems, and mobile network systems. The identity management system 120 may receive data associated with various interactions from the client device 105-a (or the client device 105-b) over a network connection, and may store and analyze the data. In some examples, the identity management system 120 may receive data directly from an interaction between an application 110 and the client device 105-a. In some examples, the client device 105-a may develop applications to run on the identity management system 120. The identity management system 120 (e.g., one or more services of the identity management system 120) may be implemented using remote servers.
[0052] In some examples, the access gateway 130 may support integrations with legacy applications 110 using hypertext transfer protocol (HTTP) headers and Kerberos tokens, which may offer universal resource locator (URL)-based authorization, among other functionalities. In some examples, such as in response to the user's request, the IdP may prompt the user 185 for one or more credentials (such as a password, PIN, biometric information, or the like) and the user 185 may provide the requested authentication credentials to the IdP. In some implementations, the IdP may leverage the MFA service 160 for added security. The IdP may verify the user's identity by comparing the credentials provided by the user 185 to credentials associated with the user's account. For example, one or more credentials associated with the user's account may be registered with the IdP (e.g., previously registered, or otherwise authorized for authentication of the user's identity via the IdP). The IdP may generate a security token (such as a SAML token or Oath 2.0 token) containing information associated with the identity and/or authentication status of the user 185 based on successful authentication of the user's identity.
It would have been obvious to a person of ordinary skill in the art at the time of the effective filing of the instant application to modify Kaplan/Chen username/password authentication with adding multifactor authentication taught by Lind. The reason for this modification would be to implement stronger authentication method that increases security.
Applicant Remarks
Applicant's arguments filed 12/15/2025 have been fully considered but they are not persuasive. Claims as recited fail the written description requirement and indefiniteness as presented above. The claims are unsupported thus arguments that the prior art references do not teach the claims are moot.
Prior Art Cited But Not Used in Rejection
US 2017/0366547 - REMOTELY DEAUTHENTICATING A USER FROM A WEB-BASED APPLICATION USING A CENTRALIZED LOGIN SERVER
Conclusion
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 Tom Y. Chang whose telephone number is 571-270-5938. The examiner can normally be reached on Monday-Friday from 9am to 5pm.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Emmanuel Moise, can be reached on (571)272-3865. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from Patent Center. Status information for published applications may be obtained from Patent Center. Status information for unpublished applications is available through Patent Center for authorized users only. Should you have questions about access to Patent Center, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free).
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) Form at https://www.uspto.gov/patents/uspto-automated- interview-request-air-form.
/TOM Y CHANG/
Primary Examiner, Art Unit 2455