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 04/09/2026, 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 § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claims 1,5 8, 12, 15 and 19 are rejected under 35 U.S.C. 102a1,a2 as being anticipated by Kaplan US 2016/0255088.
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(client app, running local host receives request and verifies the source of the request, including verifying using origin header that request comes from same domain as content system, ¶s8, 30,36)
[0008] The content management system can direct the web browser to establish a connection with the client-side application to obtain some user account identifying information for the user account. The web browser can try to open such a connection, such as a local host connection, to the client-side application. The client-side application may be constantly running a local web host server that listens in for a potential connection request from web browsers. Once the client-side application receives a request from the web browser to open a local host connection, the application can first verify that the request comes from a legitimate source. For example, the client application can examine the list of processes that are running on the client device, examine the origin header of the connection request, compare the signature of the web browser against a list of known browsers, etc., to make sure that it is safe to give out identifying information.
[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.
in response to determining the authorization request is valid, obtaining a credential associated with the authorization request from a second device(responsive to verification steps that verify the origin request and colocation requesting process and the client application, user identification information such as token(security token), username/password is provided by the client application ¶s 9,50)
[0009] The client-side application can provide the user account identifying information, such as a username, a password, an email address, a token, and/or a nonce, to the web browser. Optionally, the browser can also give the user an option to choose between continuing on the web browser as the same user account as the client application or logging in as a different user. If the user chooses to continue as the same user, the web browser can use the user account identifying information, received from the application client, to sign into the user account and allow the user to access content in the content management system via the user account.
[0050] After the optional verification steps are performed, system 900 can establish the communication channel between the web browser and the client application (808). System 900 can then provide user account identifying information to the web browser via the established communication channel, thereby enabling the web browser to log into the user account using the user account identifying information (810). The user account identifying information can be a name, a username, an email address, a password, a token, a cryptographic nonce, or a combination of one or more of these items. The web browser can provide this information, received from the client application, to the content management system in order to authenticate itself and sign into the same user account as the client application. The user of the client device may not have to provide additional user credentials to the web browser because the web browser already has enough information (i.e., user account identifying information) to authenticate itself to the content management system.
performing a second verification indication by validating proximity of the first device that sent the authentication request and the second device that provided the credentials associated with the authorization request(client application/local listener also verifies source of request by verifying the request is from a process local to the device by examining the list of processes that are running on the client device, ¶s 8, 30)
[0008] The content management system can direct the web browser to establish a connection with the client-side application to obtain some user account identifying information for the user account. The web browser can try to open such a connection, such as a local host connection, to the client-side application. The client-side application may be constantly running a local web host server that listens in for a potential connection request from web browsers. Once the client-side application receives a request from the web browser to open a local host connection, the application can first verify that the request comes from a legitimate source. For example, the client application can examine the list of processes that are running on the client device, examine the origin header of the connection request, compare the signature of the web browser against a list of known browsers, etc., to make sure that it is safe to give out identifying information.
[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.
and in response to determining the first device is co-located with the second device, approving the authorization request(if requesting browser and client application are on same device as evidence by examining the list of processes, then request is legitimate, ¶s 30, 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.
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.
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 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 as applied to claims 18 and 15 above, and further in view of Lind US 20250226985.
Regarding claims 2, 9, and 16, Kaplan does 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 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 does 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 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 running a local host server but does not specifically teach that the local server is spun upon receiving the request thus Kaplan 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 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 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 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 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 username/password authentication with adding multifactor authentication taught by Lind. The reason for this modification would be to implement stronger validation methods in addition to origin header and request source validation of Kaplan that increases security.
Applicant Remarks
Applicant’s amendments have overcome 112 1st and 2nd ¶ rejections, they are therefore withdrawn.
Applicant's arguments filed 04/09/2026 have been fully considered but they are not persuasive. The applicant argues that Kaplan/Chen do not each validating the proximity of the first device that sent the authorization request and the second device that provided the credentials associated with the authorization request. The examiner disagrees and contends that Kaplan teaches such limitations as presented in the rejection above. Kaplan teaches a web browser(i.e. first device) request credentials from a client application. The client application acts as an authentication proxy and performs one or more validation methods to verify the source of the request. One method include checking the that the request is from a process located on the client device. The examiner contends such verification of the process identity verifies that the web browser making the request and the client application are on the same device or in other words that the client application and the web browser are in proximity based on the co-location on the same device. Thus, examiner contends that Kaplan teaches the claims as amended.
Prior Art Cited But Not Used in the Rejection
US 20240275786 - Systems And Methods For WebAuthn Transport Via A WebAuthn Proxy.
Conclusion
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
Prosecution Insights