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 .
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 the 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 23 January 2026 has been entered.
Response to Arguments
Applicant’s arguments, see pages 13-17, filed 23 January 2026, with respect to the rejection of claims 1, 9, and 16 under 35 U.S.C. 103 have been fully considered and are persuasive in view of the new claim amendments. Therefore, the rejection has been withdrawn. However, upon further consideration, a new ground of rejection is made in view of Koutenaei et al. (US 2016/0269403 A1) and Lynn et al. (US 2020/0322330 A1).
Koutenaei et al. discloses setting up multi-factor authentication involves establishing a secure communication channel between the browsing device and the authentication device. The user is then able to be authenticate for specific applications and other resources using the secure communication channel.
Lynn et al. discloses a multi-factor authentication system that includes an access device 110 (Fig. 1, el. 110), and a secondary device, e.g., continuous multifactor authentication (CMFA) device 120 (Fig. 1, el. 120), wherein the CMFA device includes a CMFA application 150 (Fig. 1, el. 150). CMFA Device 120 to continually ensure that User 100 is authenticated, and if not, to terminate the session or change the access level of User 100 (Para. 88). Trusted Authentication Provider 160 compares a newly received IDActivKey with a stored version and if the variation too large, then Trusted Authentication Provider 160 can fail to authenticate a session or terminate the current session through Access Policy Compliance Service 220, or change the access level of User 100, wherein for instance, having great certainty in the identity and compliance of User 100 can result in full access to an Application Provider 170, but lesser certainty can result in restricted access, while low certainty can result in authentication failure or session termination (Para. 49).
See the 35 U.S.C. 103 section below for detailed analysis.
Claim Objections
Claim 5 is objected to because of the following informalities:
Regarding claim 5, line 5—“primary device”, it is unclear as to whether “primary device” is referring to “the primary device” of line 3. For examination purposes, the “primary device” of lines 3 and 5 will be interpreted to be the same. In order to overcome this objection, line 5 may be amended to state --the primary device--, for example.
Appropriate correction is required.
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.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claims 1, 2, 4, 5, 8-10, 12, 13, 16, 17, 19, 20, and 24 are rejected under 35 U.S.C. 103 as being unpatentable over by Koutenaei et al. (US 2016/0269403 A1) in view of Lynn et al. (US 2020/0322330 A1).
Regarding claim 1, Koutenaei teaches a method comprising:
monitoring a proximity-based direct networking connection between a primary device, e.g., browsing device 10 (Fig. 1, el. 10), and a secondary device, e.g., authentication device 20 (Fig. 1, el. 20), associated with a multi-factor authentication (MFA) application executing on the secondary device, the proximity-based direct networking connection established in association with an authentication of the primary device as a MFA-authenticated primary device to access a resource and using the secondary device associated with the MFA application, e.g., prior to process 200, in order to set up this multi-factor authentication (MFA), the user needs to assign a device as the browsing device 10 and another device as the authentication device 20 (Fig. 2, el. 200; Para. 25);
at 203, the user downloads and installs the authentication application—MFA application-- on the assigned authentication device 20 (Fig. 2, el. 203; Para. 27);
once the authentication application is downloaded and opened for the first time, the authentication application acquires the user's biometric information, and once the user is locally authenticated for the first time based on the acquired biometric, at 207, the application on the authentication device 20 and the browsing device 10 must be registered and paired (Fig. 2, el. 207; Para. 29);
at 209, a secure communication channel is established between the user's browsing device 10 and the authentication device 20 (Fig. 2, el. 209; Para. 30);
at 211, the authentication device 20 and the browsing device 10 are registered with the authentication server 30 thereby to complete the initial setup process (Fig. 1, el. 30; Fig. 2, el. 211; Para. 31);
an authentication or authorization process 300 after the user has completed the initial setup, therefore, the browsing device 10 and the authentication device 20 are already paired and a secure communication channel has been setup between them, and the user takes (at 301) an action on his/her browsing device 10 that requires authentication or authorization (for instance, log into an application, online account, webpage, VPN, a computing device, the browsing device and the like) the browsing device 10 requests to start communicating with the authentication device 20 (Fig. 3, el. 300, 301; Para. 33);
after the user is authenticated and access to the account is granted, the browser device constantly checks if the authentication device 20 is in its proximity (items 401 and 403), wherein this process of checking proximity varies based on the method of connection between the browsing device 10 and the authentication device 20, via any number of protocols or techniques, such as Wi-Fi, Bluetooth, cable, NFC, and the like (Fig. 4, el. 401, 403; Para. 53),
determining, based at least in part on the monitoring, that a proximity between the MFA-authenticated primary device and the secondary device exceeds a threshold proximity subsequent to the authentication, e.g., after the user is authenticated and access to the account is granted, the browser device constantly checks if the authentication device 20 is in its proximity (items 401 and 403) (Fig. 4, el. 401, 403; Para. 53);
if the browsing device 10 cannot detect the presence of authentication device 20, the authentication expires and the user's access to accounts, website, and the like is denied (Para. 54);
sending, to a monitoring service, e.g., authentication server 30 (Fig. 1, el. 30), an indication that the proximity exceeds the threshold proximity subsequent to the authentication, e.g., after the user is authenticated and access to the account is granted, the browser device constantly checks if the authentication device 20 is in its proximity (items 401 and 403) (Fig. 4, el. 401, 403; Para. 53);
a message (405) may be sent from the browsing device 10 to authentication server 30 indicating the authentication device 20 is not in proximity of the browsing device (Fig. 4, el. 405; Para. 54);
receiving…based at least in part on the proximity exceeding the threshold proximity subsequent to the authentication, a logout instruction to restrict the access to the resource for the MFA-authenticated primary device, e.g., the authentication device 20 not being in the proximity of the browsing device 10 means that the user has left the browsing device 10 taking the authentication device 20 (e.g. smartphone or smart wearable) with them, and that session must be expired and the user must be logged out, as the user is not present, and therefore as long as auto-logout based on proximity of two device is enabled on a secured account, application or website, there is no need to use auto-logout based on time (Para. 55); and
based at least in part on the logout instruction, causing a logout event for the resource, the logout event including restriction of the access to…the resource for the MFA-authenticated primary device subsequent to the authentication…, e.g., the authentication device 20 not being in the proximity of the browsing device 10 means that the user has left the browsing device 10 taking the authentication device 20 (e.g. smartphone or smart wearable) with them, and that session must be expired and the user must be logged out, as the user is not present, and therefore as long as auto-logout based on proximity of two device is enabled on a secured account, application or website, there is no need to use auto-logout based on time (Para. 55).
Koutenaei does not clearly teach receiving, from the monitoring service and based at least in part on the proximity exceeding the threshold proximity subsequent to the authentication, a logout instruction to restrict the access to the resource for the MFA-authenticated primary device; and
based at least in part on the logout instruction, causing a logout event for the resource, the logout event including restriction of the access to a first portion of the resource for the MFA-authenticated primary device subsequent to the authentication and while maintaining the access to a second portion of the resource subsequent to the proximity exceeding the threshold proximity.
Lynn teaches monitoring a proximity-based direct networking connection between a primary device, e.g., access device 110 (Fig. 1, el. 110), and a secondary device, e.g., continuous multifactor authentication (CMFA) device 120 (Fig. 1, el. 120), associated with a multi-factor authentication (MFA) application, e.g., CMFA application 150 (Fig. 1, el. 150), executing on the secondary device, the proximity-based direct networking connection established in association with an authentication of the primary device as a MFA-authenticated primary device to access a resource and using the secondary device associated with the MFA application, e.g., the system illustrated in FIG. 14 can allow User 100 to bind their digital identity with the devices used to authenticate and connect to a service or resource, wherein such binding can increase a trust score provided by a CMFA Device 120 when the user is accessing a service using Access Device 110, wherein the system can ensure with high trust the physical proximity of User 100 to Access Device 110, and CMFA Device 120 can act as a trusted proxy in verifying this physical presence (Fig. 14; Para. 119);
Trusted Authentication Provider 160 binds (1590) Access Device 110 and CMFA Device 120, wherein this binding can signify using the identification credential to verify the physical proximity of Access Device 110 to CMFA Device 120 (Fig. 1, el. 160; Fig. 15, el. 1590; Para. 124);
CMFA Device 120 collects (800) a plurality of types of identifying data from User 100 and contextual information from applications on CMFA Device 120, wherein this can include biometric data like fingerprints or retinal scans, behavioral data like movement or browsing activity, or contextual data like geospatial location or proximity to another device (Fig. 8, el. 800; Para. 85);
in addition to using Trust Score 710 to permit access (to initiate a session) with a service, Trust Score 710 can be repeatedly refreshed, and a session can be permitted to continue as long as Trust Score 710 remains above the threshold specified by the application or service provider policy (Para. 92);
trust factors can include contextual information (such as location or proximate device information, device orientation, background applications, etc.), biometric information, or behavioral information (Para. 94);
determining, based at least in part on the monitoring, that a proximity between the MFA-authenticated primary device and the secondary device exceeds a threshold proximity subsequent to the authentication, e.g., Trusted Authentication Provider 160 binds (1590) Access Device 110 and CMFA Device 120, wherein this binding can signify using the identification credential to verify the physical proximity of Access Device 110 to CMFA Device 120 (Fig. 1, el. 160; Fig. 15, el. 1590; Para. 124);
in addition to using Trust Score 710 to permit access (to initiate a session) with a service, Trust Score 710 can be repeatedly refreshed, and a session can be permitted to continue as long as Trust Score 710 remains above the threshold specified by the application or service provider policy (Para. 92);
trust factors can include contextual information (such as location or proximate device information, device orientation, background applications, etc.), biometric information, or behavioral information (Para. 94);
sending, to a monitoring service, e.g., Trusted Authentication Provider 160 (Fig. 1, el. 160), an indication that the proximity exceeds the threshold proximity subsequent to the authentication, e.g., upon receiving an IDActivKey and a trust score—an indication that the proximity exceeds the threshold proximity--, Trusted Authentication Provider 160 can use this information in tandem with the access requirements received from Application Provider 170 to authenticate a session with Application Provider 170 on behalf of Application Provider 170 (Par. 44);
the identification credential is derived by combining a user's biometric information and hardware cryptographic information given the appropriate “context” of the user (such as location, proximity to another device, or other contextual information) (Para. 28);
in response CMFA Device 120 can then collect (304) biometric and behavior information from the user and any contextual information, and can create (306) an IDActivKey (Para. 53);
CMFA Device 120 collects (800) a plurality of types of identifying data from User 100 and contextual information from applications on CMFA Device 120, wherein this can include biometric data like fingerprints or retinal scans, behavioral data like movement or browsing activity, or contextual data like geospatial location or proximity to another device (Para. 85);
in addition to using Trust Score 710 to permit access (to initiate a session) with a service, Trust Score 710 can be repeatedly refreshed, and a session can be permitted to continue as long as Trust Score 710 remains above the threshold specified by the application or service provider policy (Para. 92);
trust factors can include contextual information (such as location or proximate device information, device orientation, background applications, etc.), biometric information, or behavioral information (Para. 94);
receiving, from the monitoring service and based at least in part on the proximity exceeding the threshold proximity subsequent to the authentication, a logout instruction to restrict the access to the resource for the MFA-authenticated primary device, e.g., IDActivKey Comparison Service 210 can compare an IDActivKey stored on Trusted Authentication Provider 160 with the updated IDActivKey sent across Secure Dual-VPN Tunnel 200, wherein if the variation too large, then Trusted Authentication Provider 160 can fail to authenticate a session or terminate the current session through Access Policy Compliance Service 220, or change the access level of User 100 (Para. 49);
Access Policy Compliance Service 220 takes information from IDActivKey Comparison Service 210 and the updated trust score to make any needed changes to the existing access policy—such as to terminate or suspend an active session, or alter access levels (Para. 50);
Trusted Authentication Provider 160 can send new access policies in response to new information during a session (Para. 45);
this allows CMFA Device 120 to continually ensure that User 100 is authenticated, and if not, to terminate the session or change the access level of User 100 (Para. 88); and
based at least in part on the logout instruction, causing a logout event for the resource, the logout event including restriction of the access to a first portion of the resource for the MFA-authenticated primary device subsequent to the authentication and while maintaining the access to a second portion of the resource subsequent to the proximity exceeding the threshold proximity, e.g., if the variation too large, then Trusted Authentication Provider 160 can fail to authenticate a session or terminate the current session through Access Policy Compliance Service 220, or change the access level of User 100, wherein for instance, having great certainty in the identity and compliance of User 100 can result in full access to an Application Provider 170, but lesser certainty can result in restricted access, while low certainty can result in authentication failure or session termination (Para. 49);
Access Policy Compliance Service 220 takes information from IDActivKey Comparison Service 210 and the updated trust score to make any needed changes to the existing access policy—such as to terminate or suspend an active session, or alter access levels (Para. 50);
Trusted Authentication Provider 160 can send new access policies in response to new information during a session (Para. 45);
this allows CMFA Device 120 to continually ensure that User 100 is authenticated, and if not, to terminate the session or change the access level of User 100 (Para. 88).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Koutenaei to include receiving, from the monitoring service and based at least in part on the proximity exceeding the threshold proximity subsequent to the authentication, a logout instruction to restrict the access to the resource for the MFA-authenticated primary device; and based at least in part on the logout instruction, causing a logout event for the resource, the logout event including restriction of the access to a first portion of the resource for the MFA-authenticated primary device subsequent to the authentication and while maintaining the access to a second portion of the resource subsequent to the proximity exceeding the threshold proximity, using the known method of generating an IDActivKey from proximity data, sending the IDActivKey to the Trusted Authentication Provider, determining, at the Provider, that the IDActivKey has too much variation from a stored IDActivKey, and altering access levels, as taught by Lynn, in combination with the MFA system of Koutenaei, for the purpose of continuously utilizing multi-factor authentication techniques to verify the identity of a user and authenticate access devices to ensure device and networking security, and doing so in such a way that sensitive information is shielded from data collection practices (Lynn-Para. 26).
Regarding claim 2, Koutenaei in view of Lynn teaches the method of claim 1, further comprising detecting a disconnection in the proximity-based direct networking connection between the MFA-authenticated primary device and the secondary device, wherein determining that the proximity between the MFA-authenticated primary device and the secondary device exceeds the threshold proximity is based at least in part on detecting the disconnection, e.g., a pair of devices may be considered to be in each other's proximity if they are within a predefined range of each other, and a pair of devices may be considered to be in each other's proximity if they are connected to the same WiFi/LAN network, same cellular network, and the like, and a pair of devices may be considered to be in each other's proximity if they are able to send and receive Bluetooth beacons (Koutenaei-Para. 20);
after the user is authenticated and access to the account is granted, the browser device constantly checks if the authentication device 20 is in its proximity (items 401 and 403), wherein for example, the browser device 10, may send a ping (401) to authentication device 20 over Bluetooth, and if the authentication device 20 is in close proximity to receive the Bluetooth transmission, the authentication device 20 responds (403) to the browser device (Koutenaei-Para. 53).
Regarding claim 4, Koutenaei in view of Lynn teaches the method of claim 1, wherein a communication protocol associated with the proximity-based direct networking connection is at least one of a short-range wireless communication protocol or a near-field communication (NFC) protocol, e.g., a pair of devices may be considered to be in each other's proximity if they are within a predefined range of each other, and a pair of devices may be considered to be in each other's proximity if they are connected to the same WiFi/LAN network, same cellular network, and the like, and a pair of devices may be considered to be in each other's proximity if they are able to send and receive Bluetooth beacons (Koutenaei-Para. 20).
Regarding claim 5, Koutenaei in view of Lynn teaches the method of claim 1, further comprising: determining that the proximity-based direct networking connection has been established between the primary device and the secondary device; and responsive to determining that the proximity-based direct networking connection has been established between the primary device and the secondary device, causing the primary device to be authenticated as the MFA-authenticated primary device to access the resource, e.g., a pair of devices may be considered to be in each other's proximity if they are within a predefined range of each other, and a pair of devices may be considered to be in each other's proximity if they are connected to the same WiFi/LAN network, same cellular network, and the like, and a pair of devices may be considered to be in each other's proximity if they are able to send and receive Bluetooth beacons (Koutenaei-Para. 20);
an authentication or authorization process 300 after the user has completed the initial setup, therefore, the browsing device 10 and the authentication device 20 are already paired and a secure communication channel has been setup between them, and the user takes (at 301) an action on his/her browsing device 10 that requires authentication or authorization (for instance, log into an application, online account, webpage, VPN, a computing device, the browsing device and the like) the browsing device 10 requests to start communicating with the authentication device 20 (Koutenaei-Fig. 3, el. 300, 301; Para. 33);
after the user is authenticated and access to the account is granted, the browser device constantly checks if the authentication device 20 is in its proximity (items 401 and 403), wherein for example, the browser device 10, may send a ping (401) to authentication device 20 over Bluetooth, and if the authentication device 20 is in close proximity to receive the Bluetooth transmission, the authentication device 20 responds (403) to the browser device (Koutenaei-Para. 53);
the system illustrated in FIG. 14 can allow User 100 to bind their digital identity with the devices used to authenticate and connect to a service or resource, wherein such binding can increase a trust score provided by a CMFA Device 120 when the user is accessing a service using Access Device 110, wherein the system can ensure with high trust the physical proximity of User 100 to Access Device 110, and CMFA Device 120 can act as a trusted proxy in verifying this physical presence (Lynn-Fig. 14; Para. 119);
Trusted Authentication Provider 160 binds (1590) Access Device 110 and CMFA Device 120, wherein this binding can signify using the identification credential to verify the physical proximity of Access Device 110 to CMFA Device 120 (Lynn-Fig. 1, el. 160; Fig. 15, el. 1590; Para. 124).
Regarding claim 8, Koutenaei in view of Lynn teaches the method of claim 1, wherein the proximity is at least one of a physical proximity or a networking proximity, e.g., after the user is authenticated and access to the account is granted, the browser device constantly checks if the authentication device 20 is in its proximity (items 401 and 403), wherein this process of checking proximity varies based on the method of connection between the browsing device 10 and the authentication device 20, via any number of protocols or techniques, such as Wi-Fi, Bluetooth, cable, NFC, and the like (Koutenaei-Fig. 4, el. 401, 403; Para. 53), the method further comprising:
monitoring additional data associated with the MFA-authenticated primary device and the secondary device, the additional data indicative of either the physical proximity or the networking proximity, e.g., a pair of devices may be considered to be in each other's proximity if they are within a predefined range of each other, and a pair of devices may be considered to be in each other's proximity if they are connected to the same WiFi/LAN network, same cellular network, and the like, and a pair of devices may be considered to be in each other's proximity if they are able to send and receive Bluetooth beacons (Koutenaei-Para. 20);
after the user is authenticated and access to the account is granted, the browser device constantly checks if the authentication device 20 is in its proximity (items 401 and 403), wherein for example, the browser device 10, may send a ping (401) to authentication device 20 over Bluetooth, and if the authentication device 20 is in close proximity to receive the Bluetooth transmission, the authentication device 20 responds (403) to the browser device (Koutenaei-Para. 53),
the additional data including at least one of: global positioning system (GPS) data associated with each of the MFA-authenticated primary device and the secondary device, the GPS data indicative of the physical proximity between the MFA-authenticated primary device and the secondary device; network connection data associated with each of the MFA-authenticated primary device and the secondary device, the network connection data indicative of at least one of the physical proximity or the networking proximity between the MFA-authenticated primary device and the secondary device; network interface data associated with each of the MFA-authenticated primary device and the secondary device, the network interface data indicative of at least one of the physical proximity or the networking proximity between the MFA-authenticated primary device and the secondary device, e.g., a pair of devices may be considered to be in each other's proximity if they are within a predefined range of each other, and a pair of devices may be considered to be in each other's proximity if they are connected to the same WiFi/LAN network, same cellular network, and the like, and a pair of devices may be considered to be in each other's proximity if they are able to send and receive Bluetooth beacons (Koutenaei-Para. 20);
after the user is authenticated and access to the account is granted, the browser device constantly checks if the authentication device 20 is in its proximity (items 401 and 403), wherein for example, the browser device 10, may send a ping (401) to authentication device 20 over Bluetooth, and if the authentication device 20 is in close proximity to receive the Bluetooth transmission, the authentication device 20 responds (403) to the browser device (Koutenaei-Para. 53).
Regarding claim 9, it is a system claim that recites limitations similar to the ones of the method claim 1. Therefore, claim 9 is rejected for the same rationale and motivation as applied against claim 1.
Koutenaei in view of Lynn further teaches a system comprising: one or more processors, e.g., processor 1202 (Koutenaei-Fig. 12, el. 1202); circuitry 1200, some or all of which may be included in, for example, authentication device 20, browsing device 10, and/or authentication server 30, wherein circuitry 1200 can include various means, such as processor 1202 (Koutenaei-Para. 153); and
one or more non-transitory computer-readable media storing instructions that, when executed, cause the one or more processors to perform operations, e.g., memory 1204 (Koutenaei-Fig. 12, el. 1204); circuitry 1200, some or all of which may be included in, for example, authentication device 20, browsing device 10, and/or authentication server 30, wherein circuitry 1200 can include various means, such as memory 1204 (Koutenaei-Para. 153).
Regarding claim 10, Koutenaei in view of Lynn teaches the system of claim 9 as outlined above. In addition, Claim 10 is a system claim that recites limitations similar to the ones of the method claim 2. Therefore, claim 10 is rejected for the same rationale and motivation as applied against claim 2.
Regarding claim 12, Koutenaei in view of Lynn teaches the system of claim 9 as outlined above. In addition, claim 12 is a system claim that recites limitations similar to the ones of the method claim 4. Therefore, claim 12 is rejected for the same rationale and motivation as applied against claim 4.
Regarding claim 13, Koutenaei in view of Lynn teaches the system of claim 9 as outlined above. In addition, claim 13 is a system claim that recites limitations similar to the ones of the method claim 5. Therefore, claim 13 is rejected for the same rationale and motivation as applied against claim 5.
Regarding claim 16, it is a non-transitory computer-readable media claim that recites limitations similar to the ones of the method claim 1. Therefore, claim 16 is rejected for the same rationale and motivation as applied against claim 1.
Koutenaei in view of Lynn further teaches one or more non-transitory computer-readable media, e.g., memory 1204 (Koutenaei-Fig. 12, el. 1204); circuitry 1200, some or all of which may be included in, for example, authentication device 20, browsing device 10, and/or authentication server 30, wherein circuitry 1200 can include various means, such as memory 1204 (Koutenaei-Para. 153), storing instructions that, when executed, cause one or more processors, e.g., processor 1202 (Koutenaei-Fig. 12, el. 1202); circuitry 1200, some or all of which may be included in, for example, authentication device 20, browsing device 10, and/or authentication server 30, wherein circuitry 1200 can include various means, such as processor 1202 (Koutenaei-Para. 153), to perform operations.
Regarding claim 17, Koutenaei in view of Lynn teaches the non-transitory computer-readable media of claim 16 as outlined above. In addition, Claim 17 is a non-transitory computer-readable media claim that recites limitations similar to the ones of the method claim 2. Therefore, claim 17 is rejected for the same rationale and motivation as applied against claim 2.
Regarding claim 19, Koutenaei in view of Lynn teaches the non-transitory computer-readable media of claim 16 as outlined above. In addition, claim 19 is a non-transitory computer-readable media claim that recites limitations similar to the ones of the method claim 4. Therefore, claim 19 is rejected for the same rationale and motivation as applied against claim 4.
Regarding claim 20, Koutenaei in view of Lynn teaches the non-transitory computer-readable media of claim 16 as outlined above. In addition, claim 20 is a non-transitory computer-readable media claim that recites limitations similar to the ones of the method claim 5. Therefore, claim 20 is rejected for the same rationale and motivation as applied against claim 5.
Regarding claim 24, Koutenaei in view of Lynn teaches the method of claim 1, wherein the authentication is an initial session authentication, the method further comprising: determining that the proximity between the MFA-authenticated primary device and the secondary device exceeds the threshold proximity during an existing session, e.g., after the user is authenticated and access to the account is granted, the browser device constantly checks if the authentication device 20 is in its proximity (items 401 and 403) (Koutenaei-Fig. 4, el. 401, 403; Para. 53);
if the browsing device 10 cannot detect the presence of authentication device 20, the authentication expires and the user's access to accounts, website, and the like is denied (Koutenaei-Para. 54);
Also note Lynn discloses in addition to using Trust Score 710 to permit access (to initiate a session) with a service, Trust Score 710 can be repeatedly refreshed, and a session can be permitted to continue as long as Trust Score 710 remains above the threshold specified by the application or service provider policy (Lynn-Para. 92); and
trust factors can include contextual information (such as location or proximate device information, device orientation, background applications, etc.), biometric information, or behavioral information (Lynn-Para. 94);
wherein receiving the logout instruction is further based at least in part on the proximity exceeding the threshold proximity subsequent to the initial session authentication and during the existing session, e.g., the authentication device 20 not being in the proximity of the browsing device 10 means that the user has left the browsing device 10 taking the authentication device 20 (e.g. smartphone or smart wearable) with them, and that session must be expired and the user must be logged out, as the user is not present, and therefore as long as auto-logout based on proximity of two device is enabled on a secured account, application or website, there is no need to use auto-logout based on time (Koutenaei-Para. 55);
Also note Lynn discloses IDActivKey Comparison Service 210 can compare an IDActivKey stored on Trusted Authentication Provider 160 with the updated IDActivKey sent across Secure Dual-VPN Tunnel 200, wherein if the variation too large, then Trusted Authentication Provider 160 can fail to authenticate a session or terminate the current session through Access Policy Compliance Service 220, or change the access level of User 100 (Lynn-Para. 49);
Access Policy Compliance Service 220 takes information from IDActivKey Comparison Service 210 and the updated trust score to make any needed changes to the existing access policy—such as to terminate or suspend an active session, or alter access levels (Lynn-Para. 50);
Trusted Authentication Provider 160 can send new access policies in response to new information during a session (Lynn-Para. 45); and
this allows CMFA Device 120 to continually ensure that User 100 is authenticated, and if not, to terminate the session or change the access level of User 100 (Lynn-Para. 88).
Claims 6, 14, and 21-23 are rejected under 35 U.S.C. 103 as being unpatentable over Koutenaei in view of Lynn and further in view of Xia et al. (US 2020/0233949 A1).
Regarding claim 6, Koutenaei in view of Lynn teaches the method of claim 1.
Koutenaei in view of Lynn further teaches …the MFA-authenticated primary device…, e.g., the system illustrated in FIG. 14 can allow User 100 to bind their digital identity with the devices used to authenticate and connect to a service or resource, wherein such binding can increase a trust score provided by a CMFA Device 120 when the user is accessing a service using Access Device 110, wherein the system can ensure with high trust the physical proximity of User 100 to Access Device 110, and CMFA Device 120 can act as a trusted proxy in verifying this physical presence (Lynn-Fig. 14; Para. 119);
Trusted Authentication Provider 160 binds (1590) Access Device 110 and CMFA Device 120, wherein this binding can signify using the identification credential to verify the physical proximity of Access Device 110 to CMFA Device 120 (Lynn-Fig. 1, el. 160; Fig. 15, el. 1590; Para. 124); and
wherein causing the restriction of the access to the first portion of the resource for the MFA-authenticated primary device…, e.g., if the variation too large, then Trusted Authentication Provider 160 can fail to authenticate a session or terminate the current session through Access Policy Compliance Service 220, or change the access level of User 100, wherein for instance, having great certainty in the identity and compliance of User 100 can result in full access to an Application Provider 170, but lesser certainty can result in restricted access, while low certainty can result in authentication failure or session termination (Lynn-Para. 49);
Access Policy Compliance Service 220 takes information from IDActivKey Comparison Service 210 and the updated trust score to make any needed changes to the existing access policy—such as to terminate or suspend an active session, or alter access levels (Lynn-Para. 50);
Trusted Authentication Provider 160 can send new access policies in response to new information during a session (Lynn-Para. 45);
this allows CMFA Device 120 to continually ensure that User 100 is authenticated, and if not, to terminate the session or change the access level of User 100 (Lynn-Para. 88).
Koutenaei in view of Lynn does not clearly teach further comprising: determining, based at least in part on the monitoring, a period of time in which the proximity between the MFA-authenticated primary device and the secondary device has exceeded the threshold proximity;
determining that the period of time meets or exceeds a threshold period of time; and
wherein causing the restriction of the access to the first portion of the resource for the MFA-authenticated primary device is further based at least in part on the period of time meeting or exceeding the threshold period of time.
Xia teaches determining, based at least in part on the monitoring, a period of time in which the proximity between the…primary device and the secondary device has exceeded the threshold proximity, e.g., (Xia [0126] In addition to verifying that the same mobile device 110 both sends the authentication data 230 and enters proximity of the resource 120, the resource 120 may enforce a time limit between the transmission of the authentication data 230 and the detection of proximity of the device 110. For example, when the mobile device 110 sends the authentication data 230, the server system 130 or resource 120 may determine a time when the authentication data 230 is received. The resource 120 may then require the same mobile device 110 that sent the authentication data 230 to enter the predetermined level of proximity within a predetermined time period, e.g., 5 seconds, 15 seconds, 1 minute, etc.);
determining that the period of time meets or exceeds a threshold period of time, e.g., (Xia [0126] If the proximity of the mobile device 110 cannot be verified within an appropriate time window before and/or after the transmission of the authentication data 230 or the sending of the message 210, the resource 120 may deny access);
wherein causing the restriction of the access to…the resource for the…primary device is further based at least in part on the period of time meeting or exceeding the threshold period of time, e.g., (Xia [0126] If the proximity of the mobile device 110 cannot be verified within an appropriate time window before and/or after the transmission of the authentication data 230 or the sending of the message 210, the resource 120 may deny access).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Koutenaei in view of Lynn to include determining, based at least in part on the monitoring, a period of time in which the proximity between the MFA-authenticated primary device and the secondary device has exceeded the threshold proximity; determining that the period of time meets or exceeds a threshold period of time; and wherein causing the restriction of the access to the first portion of the resource for the primary device is further based at least in part on the period of time meeting or exceeding the threshold period of time, using the known method of verifying the proximity of the device within a time window, as taught by Xia, in combination with the MFA system of Koutenaei in view of Lynn, for the purpose of providing the user with more flexibility regarding proximity and when the system restricts the user’s access.
Regarding claim 14, claim 14 is rejected for the same rationale and motivation as applied against claim 6.
Regarding claim 21, Koutenaei in view of Lynn teaches the method of claim 1.
Koutenaei further teaches wherein the proximity-based direct networking connection is a first proximity-based direct networking connection, the primary device is a first primary device, the secondary device is a first secondary device, the proximity is a first proximity, and the logout instruction is a first logout instruction, the method further comprising: monitoring a…proximity-based direct networking connection between a…primary device and a…secondary device, the…proximity-based direct networking connection established in association with the authentication of the…primary device as a MFA-authenticated…primary device to access a first application, e.g., prior to process 200, in order to set up this multi-factor authentication (MFA), the user needs to assign a device as the browsing device 10 and another device as the authentication device 20 (Fig. 2, el. 200; Para. 25);
at 203, the user downloads and installs the authentication application—MFA application-- on the assigned authentication device 20 (Fig. 2, el. 203; Para. 27);
once the authentication application is downloaded and opened for the first time, the authentication application acquires the user's biometric information, and once the user is locally authenticated for the first time based on the acquired biometric, at 207, the application on the authentication device 20 and the browsing device 10 must be registered and paired (Fig. 2, el. 207; Para. 29);
at 209, a secure communication channel is established between the user's browsing device 10 and the authentication device 20 (Fig. 2, el. 209; Para. 30);
at 211, the authentication device 20 and the browsing device 10 are registered with the authentication server 30 thereby to complete the initial setup process (Fig. 1, el. 30; Fig. 2, el. 211; Para. 31);
an authentication or authorization process 300 after the user has completed the initial setup, therefore, the browsing device 10 and the authentication device 20 are already paired and a secure communication channel has been setup between them, and the user takes (at 301) an action on his/her browsing device 10 that requires authentication or authorization (for instance, log into an application, online account, webpage, VPN, a computing device, the browsing device and the like) the browsing device 10 requests to start communicating with the authentication device 20 (Fig. 3, el. 300, 301; Para. 33);
after the user is authenticated and access to the account is granted, the browser device constantly checks if the authentication device 20 is in its proximity (items 401 and 403), wherein this process of checking proximity varies based on the method of connection between the browsing device 10 and the authentication device 20, via any number of protocols or techniques, such as Wi-Fi, Bluetooth, cable, NFC, and the like (Fig. 4, el. 401, 403; Para. 53);
determining, based at least in part on the monitoring, that a…proximity between the MFA-authenticated…primary device and the…secondary device exceeds the threshold proximity, e.g., after the user is authenticated and access to the account is granted, the browser device constantly checks if the authentication device 20 is in its proximity (items 401 and 403) (Fig. 4, el. 401, 403; Para. 53);
if the browsing device 10 cannot detect the presence of authentication device 20, the authentication expires and the user's access to accounts, website, and the like is denied (Para. 54);
sending, to the monitoring service, an indication that the…proximity exceeds the threshold proximity, e.g., after the user is authenticated and access to the account is granted, the browser device constantly checks if the authentication device 20 is in its proximity (items 401 and 403) (Fig. 4, el. 401, 403; Para. 53);
a message (405) may be sent from the browsing device 10 to authentication server 30 indicating the authentication device 20 is not in proximity of the browsing device (Fig. 4, el. 405; Para. 54);
receiving…based at least in part on the…proximity exceeding the threshold proximity, a…logout instruction to restrict the access to the first application…associated with the MFA-authenticated…primary device, e.g., the authentication device 20 not being in the proximity of the browsing device 10 means that the user has left the browsing device 10 taking the authentication device 20 (e.g. smartphone or smart wearable) with them, and that session must be expired and the user must be logged out, as the user is not present, and therefore as long as auto-logout based on proximity of two device is enabled on a secured account, application or website, there is no need to use auto-logout based on time (Para. 55); and
based at least in part on the…logout instruction, causing a logout event for the first application, e.g., the authentication device 20 not being in the proximity of the browsing device 10 means that the user has left the browsing device 10 taking the authentication device 20 (e.g. smartphone or smart wearable) with them, and that session must be expired and the user must be logged out, as the user is not present, and therefore as long as auto-logout based on proximity of two device is enabled on a secured account, application or website, there is no need to use auto-logout based on time (Para. 55).
Koutenaei does not clearly teach monitoring a second proximity-based direct networking connection between a second primary device and a second secondary device, the second proximity-based direct networking connection established in association with the authentication of authenticating the second primary device as a MFA-authenticated second primary device to access a first application associated with the second primary device;
determining, based at least in part on the monitoring, that a second proximity between the MFA-authenticated second primary device and the second secondary device exceeds the threshold proximity;
sending, to the monitoring service, an indication that the second proximity exceeds the threshold proximity;
receiving, from the monitoring service and based at least in part on the second proximity exceeding the threshold proximity, a second logout instruction to restrict the access to the first application while maintaining the access to a second application associated with the MFA-authenticated second primary device; and
based at least in part on the second logout instruction, causing a logout event for the first application.
Lynn further teaches wherein the proximity-based direct networking connection is a first proximity-based direct networking connection, the primary device is a first primary device, the secondary device is a first secondary device, the proximity is a first proximity, and the logout instruction is a first logout instruction, the method further comprising: monitoring a…proximity-based direct networking connection between a…primary device and a…secondary device, the…proximity-based direct networking connection established in association with the authentication of the…primary device as a MFA-authenticated…primary device to access a first application, e.g., Application Provider 170 can be accessed through Application 190 on Access Device 110, wherein Application 190 can be an application that is specifically for accessing Application Provider 170 or can be a more general application (Fig. 1, el. 190; Para. 38);
the system illustrated in FIG. 14 can allow User 100 to bind their digital identity with the devices used to authenticate and connect to a service or resource, wherein such binding can increase a trust score provided by a CMFA Device 120 when the user is accessing a service using Access Device 110, wherein the system can ensure with high trust the physical proximity of User 100 to Access Device 110, and CMFA Device 120 can act as a trusted proxy in verifying this physical presence (Fig. 14; Para. 119);
Trusted Authentication Provider 160 binds (1590) Access Device 110 and CMFA Device 120, wherein this binding can signify using the identification credential to verify the physical proximity of Access Device 110 to CMFA Device 120 (Fig. 1, el. 160; Fig. 15, el. 1590; Para. 124);
CMFA Device 120 collects (800) a plurality of types of identifying data from User 100 and contextual information from applications on CMFA Device 120, wherein this can include biometric data like fingerprints or retinal scans, behavioral data like movement or browsing activity, or contextual data like geospatial location or proximity to another device (Fig. 8, el. 800; Para. 85);
in addition to using Trust Score 710 to permit access (to initiate a session) with a service, Trust Score 710 can be repeatedly refreshed, and a session can be permitted to continue as long as Trust Score 710 remains above the threshold specified by the application or service provider policy (Para. 92);
trust factors can include contextual information (such as location or proximate device information, device orientation, background applications, etc.), biometric information, or behavioral information (Para. 94);
determining, based at least in part on the monitoring, that a…proximity between the MFA-authenticated…primary device and the…secondary device exceeds the threshold proximity, e.g., Trusted Authentication Provider 160 binds (1590) Access Device 110 and CMFA Device 120, wherein this binding can signify using the identification credential to verify the physical proximity of Access Device 110 to CMFA Device 120 (Fig. 1, el. 160; Fig. 15, el. 1590; Para. 124);
in addition to using Trust Score 710 to permit access (to initiate a session) with a service, Trust Score 710 can be repeatedly refreshed, and a session can be permitted to continue as long as Trust Score 710 remains above the threshold specified by the application or service provider policy (Para. 92);
trust factors can include contextual information (such as location or proximate device information, device orientation, background applications, etc.), biometric information, or behavioral information (Para. 94);
sending, to the monitoring service, an indication that the…proximity exceeds the threshold proximity, e.g., upon receiving an IDActivKey and a trust score—an indication that the proximity exceeds the threshold proximity--, Trusted Authentication Provider 160 can use this information in tandem with the access requirements received from Application Provider 170 to authenticate a session with Application Provider 170 on behalf of Application Provider 170 (Par. 44);
the identification credential is derived by combining a user's biometric information and hardware cryptographic information given the appropriate “context” of the user (such as location, proximity to another device, or other contextual information) (Para. 28);
in response CMFA Device 120 can then collect (304) biometric and behavior information from the user and any contextual information, and can create (306) an IDActivKey (Para. 53);
CMFA Device 120 collects (800) a plurality of types of identifying data from User 100 and contextual information from applications on CMFA Device 120, wherein this can include biometric data like fingerprints or retinal scans, behavioral data like movement or browsing activity, or contextual data like geospatial location or proximity to another device (Para. 85);
in addition to using Trust Score 710 to permit access (to initiate a session) with a service, Trust Score 710 can be repeatedly refreshed, and a session can be permitted to continue as long as Trust Score 710 remains above the threshold specified by the application or service provider policy (Para. 92);
trust factors can include contextual information (such as location or proximate device information, device orientation, background applications, etc.), biometric information, or behavioral information (Para. 94);
receiving, from the monitoring service and based at least in part on the…proximity exceeding the threshold proximity, a…logout instruction to restrict the access to the first application while maintaining the access to a second application associated with the MFA-authenticated…primary device, e.g., there can be any number of Applications 190 or Application Providers 170, wherein each Application Provider 170 can have its own access policy, and any IDActivKey will be unique to each respective Application Provider 170 (Para. 46);
IDActivKey Comparison Service 210 can compare an IDActivKey stored on Trusted Authentication Provider 160 with the updated IDActivKey sent across Secure Dual-VPN Tunnel 200, wherein if the variation too large, then Trusted Authentication Provider 160 can fail to authenticate a session or terminate the current session through Access Policy Compliance Service 220, or change the access level of User 100 (Para. 49);
Access Policy Compliance Service 220 takes information from IDActivKey Comparison Service 210 and the updated trust score to make any needed changes to the existing access policy—such as to terminate or suspend an active session, or alter access levels (Para. 50);
Trusted Authentication Provider 160 can send new access policies in response to new information during a session (Para. 45);
this allows CMFA Device 120 to continually ensure that User 100 is authenticated, and if not, to terminate the session or change the access level of User 100 (Para. 88);
based at least in part on the…logout instruction, causing a logout event for the first application, e.g., if the variation too large, then Trusted Authentication Provider 160 can fail to authenticate a session or terminate the current session through Access Policy Compliance Service 220, or change the access level of User 100, wherein for instance, having great certainty in the identity and compliance of User 100 can result in full access to an Application Provider 170, but lesser certainty can result in restricted access, while low certainty can result in authentication failure or session termination (Para. 49);
Access Policy Compliance Service 220 takes information from IDActivKey Comparison Service 210 and the updated trust score to make any needed changes to the existing access policy—such as to terminate or suspend an active session, or alter access levels (Para. 50);
Trusted Authentication Provider 160 can send new access policies in response to new information during a session (Para. 45);
this allows CMFA Device 120 to continually ensure that User 100 is authenticated, and if not, to terminate the session or change the access level of User 100 (Para. 88).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Koutenaei to include receiving, from the monitoring service and based at least in part on the proximity exceeding the threshold proximity, a logout instruction to restrict the access to the first application while maintaining the access to a second application associated with the MFA-authenticated primary device, using the known method of generating an IDActivKey from proximity data, sending the IDActivKey to the Trusted Authentication Provider, determining, at the Provider, that the IDActivKey has too much variation from a stored IDActivKey, and altering access levels, as taught by Lynn, in combination with the MFA system of Koutenaei, using the same motivation as in claim 1.
Koutenaei in view of Lynn does not explicitly teach monitoring a second proximity-based direct networking connection between a second primary device and a second secondary device, the second proximity-based direct networking connection established in association with the authentication of authenticating the second primary device as a MFA-authenticated second primary device to access a first application associated with the second primary device;
determining, based at least in part on the monitoring, that a second proximity between the MFA-authenticated second primary device and the second secondary device exceeds the threshold proximity;
sending, to the monitoring service, an indication that the second proximity exceeds the threshold proximity;
receiving, from the monitoring service and based at least in part on the second proximity exceeding the threshold proximity, a second logout instruction to restrict the access to the first application while maintaining the access to a second application associated with the MFA-authenticated second primary device; and
based at least in part on the second logout instruction, causing a logout event for the first application.
Xia further teaches wherein the proximity-based direct networking connection is a first proximity-based direct networking connection, the primary device is a first primary device, the secondary device is a first secondary device, the proximity is a first proximity, and the logout instruction is a first logout instruction, the method further comprising: monitoring a second proximity-based direct networking connection between a second primary device and a second secondary device, the second proximity-based direct networking connection established in association with the authentication of the second primary device…to access a first application associated with the second primary device, e.g., (Xia [0070] FIG. 1 is a diagram that illustrates an example of a system 100 for proximity-based access. The system 100 includes a resource 120, such as a personal computer or other device, and a trusted device 110, such as the mobile phone of a user 102. The system 100 also includes one or more server systems, represented by server 130, to communicate with the resource 120 and the trusted device 110. In the example, the user 102 has previously associated or registered the trusted device 110 as a security token for the user 102, to be used for gaining access to the resource 120. When the user 102 later brings the trusted device 110 into physical proximity of the resource 120, the resource 120 and the trusted device 110 detect each other and communicate to provide the user 102 access to the resource 120 and/or logical resources (e.g., web pages, files, virtual private networks (VPNs), etc.) accessed using the resource 120); a user performs an action that requires authentication, such as attempting to access a secured web site, web application, or VPN (Para. 219); users can set up associations between resources and devices so that proximity triggers automatic access without action by a system administrator (Para. 60);
determining, based at least in part on the monitoring, that a second proximity between the…second primary device and the second secondary device exceeds the threshold proximity, e.g., (Xia [0120] The resource 120 compares the signal strength of received messages with a predetermined signal strength threshold representing a minimum distance at which automatic proximity-based authentication is permitted. When the signal strength meets or exceeds the signal strength threshold, the resource 120 determines that the device 110 is within the predetermined level of proximity needed to authorize access to the resource 120. The resource 120 may use multiple transmissions received from the device 110 to evaluate the signal strength over the wireless communication channel 105. For example, the resource 120 may compare an average of multiple signal strength values to the threshold to determine whether the device 110 is sufficiently near to justify providing access); users can set up associations between resources and devices so that proximity triggers automatic access without action by a system administrator (Para. 60);
sending, to the monitoring service, an indication that the second proximity exceeds the threshold proximity, e.g., (Xia [0217] FIG. 9 is a diagram that illustrates an example of a system 900 for providing logical access based on proximity of a device. The system includes a mobile device 910, a computer 920, and a server 930. These elements can have the features discussed above for the mobile device 110, resource 120, and server 130; [0244] If the device 910 determines that one or more conditions on the credential are not satisfied, or that the computer 920 is not within the required level of proximity, then the device 910 may indicate to the server 930 that the authentication is not approved);
receiving, from the monitoring service and based at least in part on the…threshold proximity, a second…instruction…, e.g., (Xia [0230] In step (953) the server 930 causes a message 932, such as a silent push notification, to be sent to the device 910. The message 932 can include a request for the device 910 to authenticate the session or verify that one or more conditions for authenticating the session are met. For example, the message 932 can instruct the device 910 to determine which devices are nearby. In some instances, the message 932 can instruct the device 910 to determine whether a specific device, e.g., the computer 920, is within a threshold level of proximity); and
based at least in part on the second logout instruction, causing a logout event for the first application, e.g., as the second electronic device moves away, the first electronic device may lock itself or otherwise restrict access in response, wherein an access control agent can restrict access to the first electronic device (e.g., by locking a user session, logging out the user, etc.) in response to determining that the signal strength satisfies the threshold level that corresponds to automatically restricting access to the first electronic device (Para. 193); (Xia [0181] The first electronic device receives, over the wireless communication link, a message from a second electronic device, e.g., device 110, that is in proximity to the first electronic device (604). The first electronic device, e.g., resource 120, determines whether the second electronic device is within a threshold level of proximity based on signal strength of one or more signals received from the second electronic device over the wireless communication link. For example, the first electronic device can determine whether the signal strength satisfies a predetermined signal strength threshold, e.g., whether the signal strength is greater than a minimum amount. If the first electronic device determines that the threshold is satisfied, and thus that the minimum level of proximity is achieved, the process continues. If the first electronic device determines that the threshold is not satisfied, and thus the second electronic device is too far away, then the first electronic device does not continue the process and does not allow automatic access).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Koutenaei in view of Lynn to include monitoring a second proximity-based direct networking connection between a second primary device and a second secondary device, the second proximity-based direct networking connection established in association with the authentication of authenticating the second primary device as a MFA-authenticated second primary device to access a first application associated with the second primary device; determining, based at least in part on the monitoring, that a second proximity between the MFA-authenticated second primary device and the second secondary device exceeds the threshold proximity; sending, to the monitoring service, an indication that the second proximity exceeds the threshold proximity; receiving, from the monitoring service and based at least in part on the second proximity exceeding the threshold proximity, a second logout instruction to restrict the access to the first application while maintaining the access to a second application associated with the MFA-authenticated second primary device; and based at least in part on the second logout instruction, causing a logout event for the first application, using the known method of allowing multiple users to set up associations between resources and devices so that proximity triggers automatic access, as taught by Xia, in combination with the MFA system of Koutenaei in view of Lynn, for the purpose of providing the user with more flexibility regarding proximity and when the system restricts the user’s access.
Regarding claim 22, the claim is analyzed with respect to claim 21.
Regarding claim 23, the claim is analyzed with respect to claim 21.
Claim 15 is rejected under 35 U.S.C. 103 as being unpatentable over Koutenaei in view of Lynn further in view of Gladstone et al. (US 20130097318 A1).
Regarding claim 15, Koutenaei in view of Lynn teaches the system of claim 9.
Koutenaei in view of Lynn further teaches wherein the resource is a virtual private network (VPN)…and causing restriction of the access to the first portion of the resource for the MFA-authenticated primary device comprises restricting access to one or more data flows between the MFA-authenticated primary device and the VPN…, e.g., every time the two devices are in proximity of each other and the user takes (at 301) an action on his/her browsing device 10 that requires authentication or authorization (for instance, log into an application, online account, webpage, VPN, a computing device, the browsing device and the like) the browsing device 10 requests to start communicating with the authentication device 20 (Koutenaei-Para. 33);
if the variation too large, then Trusted Authentication Provider 160 can fail to authenticate a session or terminate the current session through Access Policy Compliance Service 220, or change the access level of User 100, wherein for instance, having great certainty in the identity and compliance of User 100 can result in full access to an Application Provider 170, but lesser certainty can result in restricted access, while low certainty can result in authentication failure or session termination (Lynn-Para. 49);
Access Policy Compliance Service 220 takes information from IDActivKey Comparison Service 210 and the updated trust score to make any needed changes to the existing access policy—such as to terminate or suspend an active session, or alter access levels (Lynn-Para. 50);
Trusted Authentication Provider 160 can send new access policies in response to new information during a session (Lynn-Para. 45);
this allows CMFA Device 120 to continually ensure that User 100 is authenticated, and if not, to terminate the session or change the access level of User 100 (Lynn-Para. 88).
Koutenaei in view of Lynn does not explicitly teach wherein the resource is a virtual private network (VPN) headend and causing restriction of the access to the first portion of the resource for the MFA-authenticated primary device comprises restricting access to one or more data flows between the MFA-authenticated primary device and the VPN headend.
Gladstone teaches wherein the resource is a virtual private network (VPN) headend, e.g., (Gladstone [0014] FIG. 1 also includes an enterprise environment 40, which can include an access point 32, a finance server 34, and a set of virtual private network (VPN) headends 36, 38, which have connections to Internet 30. In certain implementations, VPN headends 36 and 38 are consolidated into a single element).
Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to modify Koutenaei in view of Lynn to include wherein the resource is a virtual private network (VPN) headend and causing restriction of the access to the first portion of the resource for the MFA-authenticated primary device comprises restricting access to one or more data flows between the MFA-authenticated primary device and the VPN headend, using the known method of enabling a device to communicate with a VPN headend, as taught by Gladstone, in combination with the proximity authentication system of Koutenaei in view of Lynn, for the purpose of utilizing a VPN headend to maintain and manage the VPN tunnels, thereby enabling the VPN to be offloaded to a third party reducing costs and resources.
Relevant Prior Art
The prior art made of record and not relief upon is considered pertinent to applicant’s disclosure.
Parla et al. (US 2013/0091537 A1)—Parla discloses a technique that applies a network policy responsive to specified events, or triggers, to a networked device. If a specified event occurs, the network policy may restrict the device's access to the network. For example, if a user walks away from their networked device, such as a laptop, the device's network access changes. For example, depending upon the policy, network traffic may be blocked or otherwise restricted (Abstract).
Khosravi et al. (US 2017/0289118 A1)—Khosravi discloses a mechanism to detect user proximity to a compute device using Bluetooth latency. User proximity or presence near a computer or other secured computing resource, is an important factor in determining whether the user should be authenticated to the computer (e.g., logged in or allowed to use different enterprise apps) in a Multi-factor Authentication (MFA) system. The systems and methods described here provide for detection of user proximity based on Bluetooth (BT) protocol latency (Para. 11).
D’Souza et al. (US 20180241577 A1)—D’Souza discloses a layered spatial gap may use multiple means to ensure that a user is continuously within a threshold proximity to the access point and may log the user out if the user moves away from the access point for a defined period of time (Para. 83).
Goyal et al. (US 2019/0320407 A1)—Goyal discloses the Wi-Fi link manager 902 is configured to terminate a BSS link with a second wireless communication device that is a client of the wireless communication device 900 responsive to a notification or instruction from the P2P communications module 908 indicating that the second wireless communication device is no longer within a proximity threshold of the wireless communication device 900 (Para. 85).
Goss et al. (EP 3537322 A1) – Goss discloses that Bluetooth or NFC may be used in short-range communication in order to detect computing devices within a proximity of a mobile computing device [0016].
Sagui et al. (US 20190325035 A1) – Sagui discloses that a device may transmit a user identifier once a user is a certain proximity. In order to determine the proximity, a GPS sensor, or network interface to determine information related to the network connection may be utilized [0092].
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JEREMY DUFFIELD whose telephone number is (571)270-1643. The examiner can normally be reached Monday - Friday, 7:00 AM - 3:00 PM (ET).
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, Yin-Chen Shaw can be reached at (571) 272-8878. 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.
06 February 2026
/Jeremy S Duffield/Primary Examiner, Art Unit 2498