DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
This communication is in response to an RCE filed on 02/12/2026. Claims 1-19 are currently pending in the application.
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114, Applicant’s submission filed on 02/12/2026 has been entered.
Response to Arguments
Applicant's arguments filed 01/20/2026 have been fully considered but they are moot in view of the rejections made below which addresses applicant’s concern.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1, 3, 5, 7-10, 12, 14, and 16-19-are rejected under 35 U.S.C. 103 as being unpatentable over US. PGPub. No. 20140007202 to ZHAO; Ye (hereinafter ZHAO) in view of US. Pat. No. 11516240 to Tan et al. (hereinafter Tan).
Regarding claim 1, ZHAO discloses a method comprising:
receiving a network access request for a first client device to access a network, (¶0065, “Process 500 may begin with receiving user, role, and/or authorization information (block 505). For example, as illustrated in FIG. 1B, user 105 may attempt to access network 115…”), (¶0022, “a security device may receive user, role, and/or authorization information associated with a network access request by a user and a network access grant…”), (¶0023, “By way of example, user 105 may access a network with a user device 110…”);
obtaining fingerprinting information of the first client device associated with the network access request (¶0032, “…Access device 120 may obtain user information, role information, and/or authentication information, as well as other types of information, such as, for example, user device security state information, and/or location data…”), (¶0065, “…Access device 120 may also obtain other types of information based on communication with user device 110, such as, for example, source network address, source port, destination network address, destination port, protocol (e.g., transport level), as well as other information, such as, for example, ingression interface, type of service (TOS), quality of service (QOS), timestamps, and number of packets/bytes of a traffic flow…”), wherein the fingerprinting information comprises information specifying network behavior and location information of the first client device associated with the network access request (¶0032, “…Access device 120 may obtain user information, role information, and/or authentication information, as well as other types of information, such as, for example, user device security state information, and/or location data…”), (¶0067, FIG. 5, “…Security device 125 (e.g., profiler 315) may detect, select, and/or monitor traffic from user 105 based on the user, role, and/or authorization information. For example, as illustrated in FIG. 1A, security device 125 may monitor traffic 135 associated with user 105 and user device 110…”), (¶0069, “An updated traffic behavior pattern may be obtained (block 525)…”);
determining whether a network address of the first client device associated with the network access request is recognized (¶0058, “Traffic behavior pattern information field 435 may include source address, destination address, source port, destination port, and transport protocol information (e.g., 5-tuple information (SIP, DIP, PRO, SPORT, DPORT)) and content information, which is typically conveyed in a traffic flow, as well as other information, such as, for example, ingression interface, TOS, QOS, timestamps, and number of packets/bytes of a traffic flow… a source address and/or a destination address may be used to formulate a history regarding the user device that the user, the role, and/or the corresponding authorization information normally uses to access the network, or which destination devices the user, the role, and/or the corresponding authorization information normally accesses or utilizes. Thus, in general, traffic information captured by security device 125 (e.g., profiler 315) may be used to construct the traffic behavior pattern and associate this with user, role, and/or authorization information.”, wherein using the source and destination addresses of the traffic Pattern information to formulate a history regarding the user device that the user,… is an indication that the network address of the client device is recognized), (¶0067, “…as illustrated in FIG. 1A, security device 125 may monitor traffic 135 associated with user 105 and user device 110. In one implementation, security device 125 may identify which traffic belongs to user 105 based on source network address, source port, etc., and/or the user, role, and/or authorization information provided by access device 120…”), (¶0079, “It may be determined whether a traffic behavior pattern exists (block 565). For example, network traffic analyzer 405 may consult database 410 to determine whether a traffic behavior pattern exists with respect to the user, role, and/or authorization…”);
based on determining that the network address of the first client device associated with the network access request is recognized (¶0081, “If it is determined that the traffic behavior pattern does exist (wherein the traffic behavior pattern information field 435 may include source address, destination address as cited in ¶0058 above) (block 565-YES), then network traffic analyzer 405 may update the traffic behavior pattern based on the traffic profile (block 575). For example, network traffic analyzer 405 may utilize the information associated with the traffic profile to update values, range of values, parameters, etc. relating to traffic flow.”),
However, ZHAO does not explicitly disclose the following limitation:
determining whether the fingerprinting information of the first client device associated with the network access request has an anomaly to previously obtained fingerprinting information of a different, second client device that has been authorized, wherein the previously obtained fingerprinting information of the second client device comprises information specifying network behavior and location information of the second client device; and
executing, based on determining that the fingerprinting information of the first client device associated with the network access request has an anomaly to previously obtained fingerprinting information of the second client device, an access policy to manage access to the network by the first client device associated with the network access request.
Tan discloses determining whether the fingerprinting information of the first client device associated with the network access request has an anomaly to previously obtained fingerprinting information of a different, second client device that has been authorized, (Col. 2, lines 63-67 to Col. 3, lines 1-13, “, a malicious actor may attack (e.g., by fraudulently gaining access to, utilizing, and/or altering) a client system and/or a service platform by posing as an authorized client. For example, a malicious actor that gained access to client-specific information of an authorized client system (e.g., via one or more hacking techniques) may use the client-specific information to fraudulently obtain and/or gather sensitive information associated with the client or the service platform…”), (Col.7, lines 38-67 to Col.8, lines 1-4, “As shown in FIG. 1C, and by reference number 130, the service platform monitoring system may detect access associated with the client system by an acting device. The acting device may be a user device, a server device, or the like that is attempting to access the service platform (e.g., via an API call). For example, the acting device may indicate that the acting device is associated with the client system by including the client identifier (ABC123) within a request to the service platform (e.g., with an API call to an API of the service platform). The service platform monitoring system may receive an API call from the service platform. For example, the service platform may forward requests to the service platform monitoring system to cause the service platform monitoring system to perform an analysis to determine whether the request is associated with anomalous activity as described herein. In some implementations, the service platform monitoring system may be configured to intercept and/or preprocess requests or API calls from devices to detect anomalies associated with the requests and/or the API calls.”, wherein the acting device that is posing as an authorized client by including the client identifier (ABC123) within a request to the service is interpreted as the first client while the original client that has been spoofed is interpreted as the authorized second client the identifier), wherein the previously obtained fingerprinting information of the second client device comprises information specifying network behavior and location information of the second client device (Col. 3, lines 37-57, “…The machine learning model may be trained to detect anomalies based on service usage patterns of previous accesses by the client system. Additionally, or alternatively, the machine learning model may be trained based on source data associated with the previous accesses by the client system. The source data may identify client addresses of devices that performed the previous accesses and/or client locations (e.g., areas and/or regions) of the devices when performing the previous accesses.”), (Col. 8, lines 24-46, “…the anomaly detection model may analyze a comparison of client location information identified in the source data and device location information (e.g., identified or included in the access information), that identifies a location of the acting device (e.g., to determine whether the location is within a known area or location of the client system). Additionally, or alternatively, the anomaly detection model may analyze a comparison of a client address identified in the source data and a device address of the acting device that is identified in the access information (e.g., to determine whether the acting device is a known device of the client system)…”); and
executing, based on determining that the fingerprinting information of the first client device associated with the network access request has an anomaly to previously obtained fingerprinting information of the second client device, an access policy to manage access to the network by the first client device associated with the network access request. (Col. 10, lines 6-30, “… the service platform monitoring system may prevent the service platform from engaging in further activity with the acting device. For example, based on the probability of the access being associated with anomalous activity and/or based on the feedback from the system user device, the anomaly detection model may block the API call (and/or future API calls) from the acting device and/or prevent the API call from reaching the service platform and/or a corresponding API of the service platform (e.g., to prevent a malicious attack via the API call and/or subsequent API calls from the acting device). In such cases, the service platform monitoring system may drop the API call and/or any subsequent API calls received from the acting device.”). see also Col. 15, lines 17-31.
Thus, one of ordinary skill in the art would have found it obvious before the effective filing date of applicant’s claimed invention to modify the method of ZHAO to include determining whether the fingerprinting information of the first client device associated with the network access request has an anomaly to previously obtained fingerprinting information of a different, second client device that has been authorized as disclosed by Tan and be motivated in doing so in order to determine that the acting device has spoofed the information of the client device previously authorized to access the services of the service platform-Tan abstract in parts.
Regarding claim 10, ZHAO discloses a network access control (NAC) system, comprising:
memory (FIG. 2, a memory 230);
one or more processors (FIG. 2, processor 220) in communication with the memory (¶0040, FIG. 2, “Bus 210 may permit communication among the other components of security device 125.”), the one or more processors configured to:
receive a network access request for a first client device to access a network, (¶0022, “a security device may receive user, role, and/or authorization information associated with a network access request by a user and a network access grant…”), (¶0023, “By way of example, user 105 may access a network with a user device 110…”);
obtain fingerprinting information of the first client device associated with the network access request (¶0032, “…Access device 120 may obtain user information, role information, and/or authentication information, as well as other types of information, such as, for example, user device security state information, and/or location data…”), (¶0065, “…Access device 120 may also obtain other types of information based on communication with user device 110, such as, for example, source network address, source port, destination network address, destination port, protocol (e.g., transport level), as well as other information, such as, for example, ingression interface, type of service (TOS), quality of service (QOS), timestamps, and number of packets/bytes of a traffic flow…”), wherein the fingerprinting information comprises information specifying network behavior and location information of the first client device associated with the network access request (¶0032, “…Access device 120 may obtain user information, role information, and/or authentication information, as well as other types of information, such as, for example, user device security state information, and/or location data…”), (¶0067, FIG. 5, “…Security device 125 (e.g., profiler 315) may detect, select, and/or monitor traffic from user 105 based on the user, role, and/or authorization information. For example, as illustrated in FIG. 1A, security device 125 may monitor traffic 135 associated with user 105 and user device 110…”), (¶0069, “An updated traffic behavior pattern may be obtained (block 525)…”);
determine whether a network address of the first client device associated with the network access request is recognized (¶0058, “Traffic behavior pattern information field 435 may include source address, destination address, source port, destination port, and transport protocol information (e.g., 5-tuple information (SIP, DIP, PRO, SPORT, DPORT)) and content information, which is typically conveyed in a traffic flow, as well as other information, such as, for example, ingression interface, TOS, QOS, timestamps, and number of packets/bytes of a traffic flow… a source address and/or a destination address may be used to formulate a history regarding the user device that the user, the role, and/or the corresponding authorization information normally uses to access the network, or which destination devices the user, the role, and/or the corresponding authorization information normally accesses or utilizes. Thus, in general, traffic information captured by security device 125 (e.g., profiler 315) may be used to construct the traffic behavior pattern and associate this with user, role, and/or authorization information.”, wherein using the source and destination addresses of the traffic Pattern information to formulate a history regarding the user device that the user,… is an indication that the network address of the client device is recognized), (¶0067, “…as illustrated in FIG. 1A, security device 125 may monitor traffic 135 associated with user 105 and user device 110. In one implementation, security device 125 may identify which traffic belongs to user 105 based on source network address, source port, etc., and/or the user, role, and/or authorization information provided by access device 120…”), (¶0079, “It may be determined whether a traffic behavior pattern exists (block 565). For example, network traffic analyzer 405 may consult database 410 to determine whether a traffic behavior pattern exists with respect to the user, role, and/or authorization…”);
based on determining that the first client device associated with the network access request is recognized (¶0081, “If it is determined that the traffic behavior pattern does exist (wherein the traffic behavior pattern information field 435 may include source address, destination address as cited in ¶0058 above) (block 565-YES), then network traffic analyzer 405 may update the traffic behavior pattern based on the traffic profile (block 575). For example, network traffic analyzer 405 may utilize the information associated with the traffic profile to update values, range of values, parameters, etc. relating to traffic flow.”),
However, ZHAO does not explicitly disclose the following limitation:
determine whether the fingerprinting information of the first client device associated with the network access request has an anomaly to previously obtained fingerprinting information of a different, second client device that has been authorized, wherein the previously obtained fingerprinting information of the second client device comprises information specifying network behavior and location information of the second client device; and
execute, based on determining that the fingerprinting information of the first client device associated with the network access request has an anomaly to previously obtained fingerprinting information of the second client device, an access policy to manage access to the network by the first client device associated with the network access request.
Tan discloses determine whether the fingerprinting information of the first client device associated with the network access request has an anomaly to previously obtained fingerprinting information of a different, second client device that has been authorized, (Col. 2, lines 63-67 to Col. 3, lines 1-13, “, a malicious actor may attack (e.g., by fraudulently gaining access to, utilizing, and/or altering) a client system and/or a service platform by posing as an authorized client. For example, a malicious actor that gained access to client-specific information of an authorized client system (e.g., via one or more hacking techniques) may use the client-specific information to fraudulently obtain and/or gather sensitive information associated with the client or the service platform…”), (Col.7, lines 38-67 to Col.8, lines 1-4, “As shown in FIG. 1C, and by reference number 130, the service platform monitoring system may detect access associated with the client system by an acting device. The acting device may be a user device, a server device, or the like that is attempting to access the service platform (e.g., via an API call). For example, the acting device may indicate that the acting device is associated with the client system by including the client identifier (ABC123) within a request to the service platform (e.g., with an API call to an API of the service platform). The service platform monitoring system may receive an API call from the service platform. For example, the service platform may forward requests to the service platform monitoring system to cause the service platform monitoring system to perform an analysis to determine whether the request is associated with anomalous activity as described herein. In some implementations, the service platform monitoring system may be configured to intercept and/or preprocess requests or API calls from devices to detect anomalies associated with the requests and/or the API calls.”, wherein the acting device that is posing as an authorized client by including the client identifier (ABC123) within a request to the service is interpreted as the first client while the original client that has been spoofed is interpreted as the authorized second client the identifier), wherein the previously obtained fingerprinting information of the second client device comprises information specifying network behavior and location information of the second client device (Col. 3, lines 37-57, “…The machine learning model may be trained to detect anomalies based on service usage patterns of previous accesses by the client system. Additionally, or alternatively, the machine learning model may be trained based on source data associated with the previous accesses by the client system. The source data may identify client addresses of devices that performed the previous accesses and/or client locations (e.g., areas and/or regions) of the devices when performing the previous accesses.”), (Col. 8, lines 24-46, “…the anomaly detection model may analyze a comparison of client location information identified in the source data and device location information (e.g., identified or included in the access information), that identifies a location of the acting device (e.g., to determine whether the location is within a known area or location of the client system). Additionally, or alternatively, the anomaly detection model may analyze a comparison of a client address identified in the source data and a device address of the acting device that is identified in the access information (e.g., to determine whether the acting device is a known device of the client system)…”); and
execute, based on determining that the fingerprinting information of the first client device associated with the network access request has an anomaly to previously obtained fingerprinting information of the second client device, an access policy to manage access to the network by the first client device associated with the network access request. (Col. 10, lines 6-30, “… the service platform monitoring system may prevent the service platform from engaging in further activity with the acting device. For example, based on the probability of the access being associated with anomalous activity and/or based on the feedback from the system user device, the anomaly detection model may block the API call (and/or future API calls) from the acting device and/or prevent the API call from reaching the service platform and/or a corresponding API of the service platform (e.g., to prevent a malicious attack via the API call and/or subsequent API calls from the acting device). In such cases, the service platform monitoring system may drop the API call and/or any subsequent API calls received from the acting device.”). see also Col. 15, lines 17-31.
Thus, one of ordinary skill in the art would have found it obvious before the effective filing date of applicant’s claimed invention to modify the method of ZHAO to include determining whether the fingerprinting information of the first client device associated with the network access request has an anomaly to previously obtained fingerprinting information of a different, second client device that has been authorized as disclosed by Tan and be motivated in doing so in order to determine that the acting device has spoofed the information of the client device previously authorized to access the services of the service platform-Tan abstract in parts.
Regarding claim 19, ZHAO discloses non-transitory computer readable media comprising instructions (¶0043, “Storage 240 may store data, instructions, and/or applications. For example, storage 240 may include a hard disk (e.g., a magnetic disk, an optical disk, a magneto-optic disk, etc.), a compact disc (CD), a digital versatile disc (DVD), a floppy disk, a cartridge, a magnetic tape, a flash drive, or another type of computer-readable medium, along with a corresponding drive. The term "computer-readable medium" is intended to be broadly interpreted to include, for example, memory, storage or the like. A computer-readable medium may be implemented in a single device, in multiple devices, in a centralized manner, or in a distributed manner.”) that when executed cause one or more processors to:
obtain fingerprinting information of a first client device associated with the network access request (¶0032, “…Access device 120 may obtain user information, role information, and/or authentication information, as well as other types of information, such as, for example, user device security state information, and/or location data…”), (¶0065, “…Access device 120 may also obtain other types of information based on communication with user device 110, such as, for example, source network address, source port, destination network address, destination port, protocol (e.g., transport level), as well as other information, such as, for example, ingression interface, type of service (TOS), quality of service (QOS), timestamps, and number of packets/bytes of a traffic flow…”), wherein the fingerprinting information comprises information specifying network behavior and location information of the first client device associated with the network access request (¶0032, “…Access device 120 may obtain user information, role information, and/or authentication information, as well as other types of information, such as, for example, user device security state information, and/or location data…”), (¶0067, FIG. 5, “…Security device 125 (e.g., profiler 315) may detect, select, and/or monitor traffic from user 105 based on the user, role, and/or authorization information. For example, as illustrated in FIG. 1A, security device 125 may monitor traffic 135 associated with user 105 and user device 110…”), (¶0069, “An updated traffic behavior pattern may be obtained (block 525)…”);
determine whether a network address of the first client device associated with the network access request is recognized (¶0058, “Traffic behavior pattern information field 435 may include source address, destination address, source port, destination port, and transport protocol information (e.g., 5-tuple information (SIP, DIP, PRO, SPORT, DPORT)) and content information, which is typically conveyed in a traffic flow, as well as other information, such as, for example, ingression interface, TOS, QOS, timestamps, and number of packets/bytes of a traffic flow… a source address and/or a destination address may be used to formulate a history regarding the user device that the user, the role, and/or the corresponding authorization information normally uses to access the network, or which destination devices the user, the role, and/or the corresponding authorization information normally accesses or utilizes. Thus, in general, traffic information captured by security device 125 (e.g., profiler 315) may be used to construct the traffic behavior pattern and associate this with user, role, and/or authorization information.”, wherein using the source and destination addresses of the traffic Pattern information to formulate a history regarding the user device that the user,… is an indication that the network address of the client device is recognized), (¶0067, “…as illustrated in FIG. 1A, security device 125 may monitor traffic 135 associated with user 105 and user device 110. In one implementation, security device 125 may identify which traffic belongs to user 105 based on source network address, source port, etc., and/or the user, role, and/or authorization information provided by access device 120…”), (¶0079, “It may be determined whether a traffic behavior pattern exists (block 565). For example, network traffic analyzer 405 may consult database 410 to determine whether a traffic behavior pattern exists with respect to the user, role, and/or authorization…”);
based on determining that the first client device associated with the network access request is recognized (¶0081, “If it is determined that the traffic behavior pattern does exist (wherein the traffic behavior pattern information field 435 may include source address, destination address as cited in ¶0058 above) (block 565-YES), then network traffic analyzer 405 may update the traffic behavior pattern based on the traffic profile (block 575). For example, network traffic analyzer 405 may utilize the information associated with the traffic profile to update values, range of values, parameters, etc. relating to traffic flow.”),
However, ZHAO does not explicitly disclose the following limitation:
determine whether the fingerprinting information of the first client device associated with the network access request has an anomaly to previously obtained fingerprinting information of a different, second client device that has been authorized, wherein the previously obtained fingerprinting information of the second client device comprises information specifying network behavior and location information of the second client device; and
execute, based on determining that the fingerprinting information of the first client device associated with the network access request has an anomaly to previously obtained fingerprinting information of the second client device, an access policy to manage access to the network by the first client device associated with the network access request.
Tan discloses determine whether the fingerprinting information of the first client device associated with the network access request has an anomaly to previously obtained fingerprinting information of a different, second client device that has been authorized, (Col. 2, lines 63-67 to Col. 3, lines 1-13, “, a malicious actor may attack (e.g., by fraudulently gaining access to, utilizing, and/or altering) a client system and/or a service platform by posing as an authorized client. For example, a malicious actor that gained access to client-specific information of an authorized client system (e.g., via one or more hacking techniques) may use the client-specific information to fraudulently obtain and/or gather sensitive information associated with the client or the service platform…”), (Col.7, lines 38-67 to Col.8, lines 1-4, “As shown in FIG. 1C, and by reference number 130, the service platform monitoring system may detect access associated with the client system by an acting device. The acting device may be a user device, a server device, or the like that is attempting to access the service platform (e.g., via an API call). For example, the acting device may indicate that the acting device is associated with the client system by including the client identifier (ABC123) within a request to the service platform (e.g., with an API call to an API of the service platform). The service platform monitoring system may receive an API call from the service platform. For example, the service platform may forward requests to the service platform monitoring system to cause the service platform monitoring system to perform an analysis to determine whether the request is associated with anomalous activity as described herein. In some implementations, the service platform monitoring system may be configured to intercept and/or preprocess requests or API calls from devices to detect anomalies associated with the requests and/or the API calls.”, wherein the acting device that is posing as an authorized client by including the client identifier (ABC123) within a request to the service is interpreted as the first client while the original client that has been spoofed is interpreted as the authorized second client the identifier), wherein the previously obtained fingerprinting information of the second client device comprises information specifying network behavior and location information of the second client device (Col. 3, lines 37-57, “…The machine learning model may be trained to detect anomalies based on service usage patterns of previous accesses by the client system. Additionally, or alternatively, the machine learning model may be trained based on source data associated with the previous accesses by the client system. The source data may identify client addresses of devices that performed the previous accesses and/or client locations (e.g., areas and/or regions) of the devices when performing the previous accesses.”), (Col. 8, lines 24-46, “…the anomaly detection model may analyze a comparison of client location information identified in the source data and device location information (e.g., identified or included in the access information), that identifies a location of the acting device (e.g., to determine whether the location is within a known area or location of the client system). Additionally, or alternatively, the anomaly detection model may analyze a comparison of a client address identified in the source data and a device address of the acting device that is identified in the access information (e.g., to determine whether the acting device is a known device of the client system)…”); and
execute, based on determining that the fingerprinting information of the first client device associated with the network access request has an anomaly to previously obtained fingerprinting information of the second client device, an access policy to manage access to the network by the first client device associated with the network access request (Col. 10, lines 6-30, “… the service platform monitoring system may prevent the service platform from engaging in further activity with the acting device. For example, based on the probability of the access being associated with anomalous activity and/or based on the feedback from the system user device, the anomaly detection model may block the API call (and/or future API calls) from the acting device and/or prevent the API call from reaching the service platform and/or a corresponding API of the service platform (e.g., to prevent a malicious attack via the API call and/or subsequent API calls from the acting device). In such cases, the service platform monitoring system may drop the API call and/or any subsequent API calls received from the acting device.”). see also Col. 15, lines 17-31.
Thus, one of ordinary skill in the art would have found it obvious before the effective filing date of applicant’s claimed invention to modify the computer readable media of ZHAO to include determining whether the fingerprinting information of the first client device associated with the network access request has an anomaly to previously obtained fingerprinting information of a different, second client device that has been authorized as disclosed by Tan and be motivated in doing so in order to determine that the acting device has spoofed the information of the client device previously authorized to access the services of the service platform-Tan abstract in parts.
Regarding claims 3 and 12, ZHAO in view of Tan discloses the method of claim 1 and NAC system of claim 10.
ZHAO further discloses wherein obtaining fingerprinting information of the first client device associated with the network access request comprises obtaining fingerprinting information of the first client device associated with the network access request from one or more network access server (NAS) devices (¶0023, “…Device 120 may share the user, role, and/or authentication information 130 with security device 125. Device 120 may also provide security device 125 with, for example, source network address information. In other implementations, device 120 may provide security device 125 with other information (e.g., source port, destination network address, etc.), in addition to, or instead of, source network address information.”), (¶0032, “…Access device 120 may obtain user information, role information, and/or authentication information, as well as other types of information, such as, for example, user device security state information, and/or location data…”), (¶0065, “…Access device 120 may also obtain other types of information based on communication with user device 110, such as, for example, source network address, source port, destination network address, destination port, protocol (e.g., transport level), as well as other information, such as, for example, ingression interface, type of service (TOS), quality of service (QOS), timestamps, and number of packets/bytes of a traffic flow…”), wherein the one or more NAS devices comprise one or more of an access point device, a switch, or a router (¶0032, “…access device 120 may include an application authentication server, a policy server, an enforcement point, and/or some other type of access control device or a device (e.g., a switch, a gateway, a bridge) that may process and/or forward network traffic…”).
Regarding claims 5, and 14, ZHAO in view of Tan discloses the method of claim 1 and the NAC system of claim 10.
ZHAO further discloses wherein the second client device comprises a wireless client device (¶0029, “…Environment 100 may include wired and/or wireless connections among the devices”), (¶0045, “Communication interface 260 may enable security device 125 to communicate with another device, a network, another system, and/or the like. For example, communication interface 260 may include a wireless interface and/or a wired interface, such as, an Ethernet interface, an optical interface, etc.”), wherein the location information of the previously obtained fingerprinting information of the second client device comprises a geolocation of the second client device (¶0032, “…Access device 120 may obtain user information, role information, and/or authentication information, as well as other types of information, such as, for example, user device security state information, and/or location data…”), (¶0065, “…Access device 120 may also obtain other types of information based on communication with user device 110, such as, for example, source network address, source port, destination network address, destination port, protocol (e.g., transport level), as well as other information, such as, for example, ingression interface, type of service (TOS), quality of service (QOS), timestamps, and number of packets/bytes of a traffic flow…”), and
Tan further discloses wherein determining whether the fingerprinting information of the first client device associated with the network access request has an anomaly to previously obtained fingerprinting information of the second client device comprises determining whether a geolocation of the client device associated with the network access request does not match the geolocation of the second client device (Col. 6, lines 5-15, “…The service platform monitoring system may use the client addresses and/or client locations to detect and/or analyze anomalous activity involving requests that indicate that the request is associated with the client system (e.g., to detect malicious activity and/or to detect new authorized devices associated with the client system).”), (Col. 7, lines 58-67 to Col. 8, lines 1-5, “…Additionally, or alternatively, the access information may include source data associated with the acting device, such as information identifying a location of the acting device and/or a source address of the acting device.”), (Col. 8, lines 24-46, “…the anomaly detection model may analyze a comparison of client location information identified in the source data and device location information (e.g., identified or included in the access information), that identifies a location of the acting device (e.g., to determine whether the location is within a known area or location of the client system)…”), (Col. 9, lines 6-47, “the anomaly detection model may then analyze the source location of the request to determine whether the request was made from a known location (or area) of the client system (e.g., a learned client location or client region of the client system maintained by the client feature generation model and/or the anomaly detection model). If the source location is outside of a threshold distance of a known client location, the service platform monitoring system may determine that the access is indicative of a malicious attack…”), (Col. 5, lines 58-67-Col. 6 lines 1-4, “The client feature generation model may identify client location information associated with locations of the client devices from where the client devices accessed the service platform (e.g., locations from where the client devices transmitted the API calls). In some implementations, the location information includes geolocation information (e.g., geographical coordinates) and/or a location name (e.g., a name of a jurisdiction or region). In some implementations, the client feature generation model determines the location information based on the client address (e.g., using a mapping of geolocation information to IP addresses of a network associated with the client system) and/or an address of a network device of a network that is communicatively coupled to the client system and/or the service platform.”).
Thus, one of ordinary skill in the art would have found it obvious before the effective filing date of applicant’s claimed invention to modify the method and NAC system of ZHAO to include determining whether a geolocation of the client device associated with the network access request does not match the geolocation of the second client device as disclosed by Tan and be motivated in doing so in order to map the geolocation information to IP addresses of a network associated with the client system) and/or an address of a network device of a network that is communicatively coupled to the client system and/or the service platform-Tan Col. 5, lines 58-67-Col. 6 lines 1-4 in parts.
Regarding claims 7 and 16, ZHAO in view of Tan discloses the method of claim 1 and the NAC system of claim 10.
Tan further discloses further comprising, storing the previously obtained fingerprinting information of the second client device mapped to a Media Access Control (MAC) address of the second client device (Col. 9, lines 6-47, “…the anomaly detection model may analyze the source address to determine whether the source address is a known address of the client system (e.g., a learned IP address and/or MAC address of the client system maintained by the client feature generation model and/or anomaly detection model)…”), (Col. 12, line 65-67 to Col.13, lines 1-21, “… the feature set may include one or more of the following features: an IP address (e.g., a source IP address), a client device identifier (e.g., an international mobile equipment identifier (IMEI) and/or a MAC address, such as a source MAC address), one or more user credentials associated with an authorized user of the client system, a parameter of a service request (described elsewhere herein), an API identifier, a type of an API call, a type of output requested from the service platform, and/or any other suitable variable involving access to a service platform described elsewhere herein.”).
Thus, one of ordinary skill in the art would have found it obvious before the effective filing date of applicant’s claimed invention to modify the method and NAC system of ZHAO and Tan to include MAC address information storage (maintained) as disclosed by Tan and be motivated in doing so in order to provide network security by restricting access to an unauthorized device.
Regarding claims 8 and 17, ZHAO in view of Tan discloses the method of claim 1 and the NAC system of claim 10.
Tan further discloses wherein determining that the network address of the first client device associated with the network access request is recognized comprises determining that a Media Access Control (MAC) address of the first client device associated with the network access request matches a MAC address of the second client device (Col. 9, lines 6-57, “… the anomaly detection model may analyze the source address to determine whether the source address is a known address of the client system (e.g., a learned IP address and/or MAC address of the client system maintained by the client feature generation model and/or anomaly detection model). If the source address does not match a client address of the client system (which is indicative of an anomaly, such as a malicious attack or a new client device being added to the client system)… the anomaly detection model may detect anomalies (and/or a probability of anomalies) based on whether timing of the device accessing the service is outside of a usage threshold of the service usage pattern, based on whether a source address of the acting device in the access information matches a client address of the respective client addresses, and/or based on whether a source location of the acting device is within a distance threshold of a client location of the respective client locations.”)
Thus, one of ordinary skill in the art would have found it obvious before the effective filing date of applicant’s claimed invention to modify the method and NAC system of ZHAO and Tan to include MAC address matching between two devices as disclosed by Tan and be motivated in doing so in order to determine anomalies associated with access to the service platform-Tan (Col. 9, lines 6-47 in parts.
Regarding claims 9 and 18, ZHAO in view of Tan discloses the method of claim 1 and the NAC system of claim 10.
ZHAO further discloses further comprising: based on executing the access policy to manage access to the network by the first client device associated with the network access request, sending, based on the access policy, a notification to an administrator (¶0035, “… Security device 125 may also provide logging (e.g., collecting network traffic information, traffic pattern information, etc.), and reporting/notification (e.g., providing real-time reports)…”).
Claims 2 and 11 are rejected under 35 U.S.C. 103 as being unpatentable over US. PGPub. No. 20140007202 to ZHAO; Ye (hereinafter ZHAO) in view of US. Pat. No. 11516240 to Tan et al. (hereinafter Tan) and further in view of US. PGPub. No. 20150373015 to Mary et al. (hereinafter Mary).
Regarding claims 2 and 11, ZHAO in view of Tan discloses the method of claim 1 and the NAC system of claim 10.
However, ZHAO in view of Tan does not explicitly disclose the limitation of:
wherein the previously obtained fingerprinting information of the second client device comprises one or more of a Dynamic Host Configuration Protocol (DHCP) option, information included in a Link Layer Discovery Protocol (LLDP), information included in a CiscoTM Discovery Protocol (CDP), or a Hypertext Transfer Protocol (HTTP) user agent.
Mary in the same field of invention (user authentication using device properties) discloses wherein the previously obtained fingerprinting information of the authorized client device comprises one or more of a Dynamic Host Configuration Protocol (DHCP) option, information included in a Link Layer Discovery Protocol (LLDP), information included in a CiscoTM Discovery Protocol (CDP), or a Hypertext Transfer Protocol (HTTP) user agent (¶0073, “In certain embodiments of the present disclosure, device fingerprints based on the HTTP browser context and session state information from an HTTP cookie. Such device fingerprints may be referred to as device DNA. Thus, attacks may be statistically more difficult to launch because the attacker is now forced to mimic the original session cookie holder's HTTP browser context in order to successfully gain access to the system. Thus, it is no longer sufficient to merely gain access to a protected system by hijacking a user's cookie.”).
Thus, one of ordinary skill in the art would have found it obvious before the effective filing date of applicant’s claimed invention to modify the method and NAC system of ZHAO and Tan to include the concept of HTTP browser as disclosed by Mary and be motivated in doing so in order to prevent attacks on network through browsers as attacker will be forced to mimic the original session cookie holder's HTTP browser context in order to successfully gain access to the system and thereby increases the security level of the system-Mary ¶0073-¶0074 in parts.
Claims 4 and 13 are rejected under 35 U.S.C. 103 as being unpatentable over US. PGPub. No. 20140007202 to ZHAO; Ye (hereinafter ZHAO) in view of US. Pat. No. 11516240 to Tan et al. (hereinafter Tan) and further in view of US. PGPub. No. 20190007441 to Kesin et al. (hereinafter Kesin).
Regarding claims 4 and 13, ZHAO in view of Tan discloses the method of claim 1 and the NAC system of claim 10.
ZHAO further discloses wherein the second client device comprises a wired client device (¶0029, “Environment 100 may include wired and/or wireless connections among the devices…”), (¶0045, “Communication interface 260 may enable security device 125 to communicate with another device, a network, another system, and/or the like. For example, communication interface 260 may include a wireless interface and/or a wired interface, such as, an Ethernet interface, an optical interface, etc…”), (¶0058
wherein the location information of the previously obtained fingerprinting information of the second client device comprises information identifying a port that connects a switch to the second client device (¶0058, “Traffic behavior pattern information field 435 may include source address, destination address, source port, destination port, and transport protocol information (e.g., 5-tuple information (SIP, DIP, PRO, SPORT, DPORT)) and content information, which is typically conveyed in a traffic flow, as well as other information, such as, for example, ingression interface, TOS, QOS, timestamps, and number of packets/bytes of a traffic flow…”), (¶0065, “…Access device 120 may also obtain other types of information based on communication with user device 110, such as, for example, source network address, source port, destination network address, destination port, protocol (e.g., transport level), as well as other information, such as, for example, ingression interface, type of service (TOS), quality of service (QOS), timestamps, and number of packets/bytes of a traffic flow…”), and
However, ZHAO in view of Tan does not explicitly disclose:
wherein determining whether the fingerprinting information of the first client device associated with the network access request has an anomaly to previously obtained fingerprinting information of the second client device comprises determining whether information identifying a port that connects the switch to the first client device associated with the network access request does not match the information identifying the port that connects the switch to the second client device.
Kesin in the field of network anomaly detection discloses wherein determining whether the fingerprinting information of the first client device associated with the network access request has an anomaly to previously obtained fingerprinting information of the second client device comprises determining whether information identifying a port that connects the switch to the first client device associated with the network access request does not match the information identifying the port that connects the switch to the second client device (¶0058, “…An anomaly detection system, such as the anomaly detection system 101 of FIG. 1, logs the user ID, port 20 of the user machine, the IP address 192.168.0.2 of the server, and the port 22 of the server. When the user attempts to access resource 207 at a later time, it can get routed instead to a second server 211 having IP address 192.168.0.3, for example, if the first server crashes. The user can access the duplicate tax data 207b through a port 215 of the second server having port address 22. The anomaly detection system 101 can log the user ID, port 20 of the user machine, the IP address 192.168.0.3 of the server, and the port 22 of the server for this second activity. The anomaly detection system can analyze to the logged data to determine that the same user, through the same user port 20 and same server port 22 is accessing the same data because the port numbers for two different servers match despite the servers having different IP addresses…”).
Thus, one of ordinary skill would have found it obvious before the effective filing date of applicant’s claimed invention to modify the method and NAC system of ZHAO and Tan to include matching a port that connects the switch to the first client device associated with the network access request with the port that connects the switch to the second client device as disclosed by Kesin and be motivated in doing so in order to allow the system to determine whether source and /or destination ports of a client device match previously used ports so that the user or device may be allowed access-Kesin ¶0058 in parts.
Claims 6 and 15 are rejected under 35 U.S.C. 103 as being unpatentable over US. PGPub. No. 20140007202 to ZHAO; Ye (hereinafter ZHAO) in view of US. Pat. No. 11516240 to Tan et al. (hereinafter Tan) and further in view of US. PGPub. No. 20120164982 to Klein; Elliot (hereinafter Klein).
Regarding claim 6, and 15, ZHAO in view of Tan discloses the method of claim 5 and the NAC system of claim 13.
However, ZHAO in view of Tan does not explicitly disclose:
wherein determining whether a geolocation of the first client device associated with the network access request has an anomaly to the geolocation of the second client device comprises:
determining whether the geolocation of the first client device associated with the network access request is within an expected geolocation of a mobility pattern of the second client device.
Klein in the field of authenticating voters using device location data (abstract) discloses:
determining whether the geolocation of the first client device associated with the network access request is within an expected geolocation of a mobility pattern of the second client device (¶0042-¶0045, “The voting authority provides the permissible GPS address location information to the computer server (step 220) where it is stored for matching by exact location or range within (i.e., permitted location may be within 2 miles radius of the GPS location address stored in the voter server and related database). The device cell tower triangulation geolocation information may identify the location of the voter at the time of vote or may include alternate GPS address locations such as the GPS coordinates of a polling location where voters can choose to vote with or without a consumer device. The mobile communication device provides the voter location information to the processing network (step 230). Thus, the processing network may identify the voting location where the vote is being initiated by the mobile communication device. The location of the mobile communication device is identified using a global positioning system (step 240). The global positioning system provides the cell tower triangulation location of the mobile communication device to the voter database and remote computer server processing network. A determination is made whether the location of the mobile communication device corresponds to the voter's pre-designated Postal Service mail location (step 250). The vote casting and serving network considers the mobile communication device to be authentic when the voter location corresponds to the cell tower triangulation geolocation (or locations and/or radius there from) of the mobile communication device…”).
Thus, one of ordinary skill in the art would have found it obvious before the effective filing date of applicant’s claimed invention to modify the method and NAC system of ZHAO and Tan to include geolocation range as disclosed by Klein and be motivated in doing so in order to allow the system to authenticate a user and /or device based on the location of the device within a specified range-Klein ¶0042-¶0045 in parts.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MUDASIRU K OLAEGBE whose telephone number is (571)272-2082. The examiner can normally be reached MON-FRI. 7.30AM-5.30PM.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Farid Homayounmehr can be reached at 5712723739. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/MUDASIRU K OLAEGBE/Examiner, Art Unit 2495
Prosecution Insights