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 04/02/2026 has been entered.
Response to Amendment
The following is a non-final office action in response to applicant’s amendment filed on 04/02/2026 for response of the office action mailed on 09/24/2025. Claims 1, 10 and 11 have been amended. Claims 1-11 are pending in this application.
Response to Arguments
Applicant's arguments filed 04/02/2026 have been fully considered but they are not persuasive/are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
Argument - III. Di Pietro and Chandrasekaran do not teach the amended independent claims
The Final Office Action relies on Di Pietro for monitoring an SSID, collecting statistics, and discussing health status rules involving buckets such as Association, Authentication, Mobility, and DHCP, and relies on Chandrasekaran for weighted averages, outlier detection, and issue analysis. Applicant respectfully submits that, even if those teachings are accepted for their respective general propositions, the cited art still does not teach or suggest the amended claims.
The amended claims now require that the tracked time intervals are not generic onboarding or roaming times and are not merely counters associated with broad categories. Instead, the claims require tracking a respective time interval for each respective phase where the phases are expressly defined by packet pairs:
association request / association response
M1-handshake / M4-handshake
DHCP-Discover / DHCP-Acknowledge
That is a materially more specific protocol-level construction than the generalized disclosures relied upon in the Final Office Action.
Response:
Examiner has considered the applicant’s arguments and respectfully disagrees. Due to the amendment(s) made on the independent claims, the Office no longer relies on the teachings of Di Pietro and Chandrasekaran but instead introduces Gaonkar (US 2020/0133815 A1) and Dherange (US 2020/0379868 A1). Gaonkar teaches tracking distinct wireless connection transactions including association, authentication and DHCP. Transactions are recorded with start and end timestamps, where the time required to complete the transaction is calculated and separately identifies association time, authentication time and DHCP time. Gaonkar further teaches different timeout thresholds for different transaction phases and determining corresponding failures when a threshold is exceeded (¶0012, ¶0015, ¶0037, ¶0045-¶0056).
Argument - A. Di Pietro does not teach packet-pair timing for the claimed phases
The Final Office Action points to Di Pietro’s discussion of health status rules and buckets such as Association, Authentication, and DHCP, and further states that onboarding time and DHCP/AAA times render the claimed phases tracked. However, the cited Di Pietro disclosures do not teach measuring, for each connection, a respective time interval between samples of collected data packets for each phase as now claimed, much less where each phase is expressly defined by the claimed packet pairs. At most, Di Pietro discusses issue categorization and network health monitoring at a more generalized level. It does not teach:
defining an association phase by association request and association response data packets,
defining an authentication phase by M1-handshake and M4-handshake data packets, or
defining a DHCP phase by DHCP-Discover and DHCP-Acknowledge data packets,
and then deriving a separate threshold for each such packet-defined phase.
Response:
Examiner has considered the applicant’s arguments and respectfully disagrees. Due to the amendment(s) made on the independent claims, the Office no longer relies on the teachings of Di Pietro and Chandrasekaran but instead introduces Gaonkar (US 2020/0133815 A1) and Dherange (US 2020/0379868 A1). Gaonkar teaches separately tracking association, authentication, and DHCP transactions, measuring the time for each transaction using time stamps or timers, and applying transaction-specific thresholds, including different thresholds for authentication and DHCP (¶0045-¶0056). Dherange is replied upon for the unsupervised machine-learning, clustering, weighted averages and dynamic threshold limitations. Applicant’s further arguments regarding association request/association response, M1/M4 handshake, and DHCP discover/DHCP acknowledge packet pairs are not corresponding with the scope of independent claims 1, 10 and 11, which only recite association, authentication, and DHCP phases but do not require those specific packet pairs. The packet-pair limitations are recited in dependent claim 5 and are addressed separately in the rejection of claim 5.
Argument - B. Chandrasekaran does not cure this deficiency
The Final Office Action cites Chandrasekaran for weighted averages using time difference, cluster means, and number of samples, and for outlier-based issue detection. Even if Chandrasekaran is accepted as teaching weighted averaging generally, Chandrasekaran still does not cure the missing protocol-phase limitations above. Chandrasekaran’s cited disclosures are directed to connectivity-event timing, packet-level protocol information, and analytical grouping of incidents. But the rejection still does not identify any teaching of:
separately timing the specific packet-pair intervals recited above for the three claimed phases, and
deriving a respective dynamic threshold for each such packet-defined phase from phase-specific clustering and weighting.
Generic analytical treatment of connectivity event information is not the same as the presently claimed phase-by-phase packet-pair threshold derivation.
Response:
Examiner has considered the applicant’s arguments and respectfully disagrees. Due to the amendment(s) made on the independent claims, the Office no longer relies on the teachings of Di Pietro and Chandrasekaran but instead introduces Gaonkar (US 2020/0133815 A1) and Dherange (US 2020/0379868 A1). Gaonkar teaches separately tracking association, authentication, and DHCP transactions, measuring the time for each transaction using time stamps or timers, and applying transaction-specific thresholds, including different thresholds for authentication and DHCP (¶0045-¶0056). Dherange is replied upon for the unsupervised machine-learning, clustering, weighted averages and dynamic threshold limitations. Applying Dherange’s clustering and threshold techniques to Gaonkar’s separately collected phase-timing data teaches deriving a respective dynamic threshold for each connection phase. Applicant’s further arguments regarding association request/association response, M1/M4 handshake, and DHCP discover/DHCP acknowledge packet pairs are not corresponding with the scope of independent claims 1, 10 and 11, which only recite association, authentication, and DHCP phases but do not require those specific packet pairs. The packet-pair limitations are recited in dependent claim 5 and are addressed separately in the rejection of claim 5.
Argument - C. The rejection still depends on hindsight reconstruction
The earlier response and supplemental response repeatedly pointed out that the references were “completely silent with respect to the different connection phases,” and that “mere appearance of terms does not amount to disclosure of functionality.” The pre-appeal remarks made the same point: cited vocabulary alone does not establish the claimed granularity of time intervals and clustering for each phase. The present amendment makes that distinction sharper, not weaker. The Examiner’s prior combination may arguably approach broad “connection-phase” terminology, but it still does not teach the now-claimed packet-defined phase timing architecture. Reaching the amended claims would require using Applicant’s disclosure as a roadmap.
Response:
Applicant’s hindsight argument has been considered but is not persuasive. The present rejection does not rely on the mere appearance of connection-phase terminology. Gaonkar teaches measuring separate association, authentication, and DHCP transaction times and applies phase-specific thresholds (¶0045-¶0056). Dherange teaches applying unsupervised KMeans clustering, cluster-based weighted averages, and learned anomaly thresholds to collect data (¶0146-¶0161). Therefore, the combination applies Dherange’s known anomaly-detection technique to the connection phase-specific timing data already collected in Gaonkar, rather than using the Applicant’s disclosure.
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.
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
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 non-obviousness.
Claims 1 and 10-11 are rejected under 35 U.S.C. 103 as being unpatentable over Di Gaonkar et al. (US 2020/0133815 A1), Gaonkar hereinafter, and further in view of Dherange et al. (US 2020/0379868 A1), Dherange hereinafter.
Re. Claim 1, Gaonkar teaches a computer-implemented method in a network management device, (Fig. 1-4 & ¶0059 - For example, a request is received from a client device to connect to a wireless network associated with a cloud computing device. The process can be performed by a computing device that is different from the cloud computing device. In some embodiments, the computing device can be an edge computing device such as a router or switch, or a network management station);
as a baseline for identifying issues for new connections at different connection phases, the method comprising: (Fig. 1A & ¶0012 - The first transaction can include any of a wireless networking access point association request, an authentication request, a roaming request or a Dynamic Host Configuration Protocol (DHCP) request. ¶0044 - Each column includes a value for corresponding transaction information such as a start time, an association time, an authentication time, a DHCP time, a transaction type, a result type, or a type of failure. ¶0051 - In some embodiments, the computing device performs analytics to track real-time issues with the wireless connection to minimize computation efforts at the cloud computing device. Please also see ¶0056);
monitoring a Service Set Identifier (SSID), (¶0036 - In an embodiment, client events generated in the foregoing manner are stored in a Redis cache. An analytics module consumes these events pushed into a Redis DB and creates a transaction based on the above definition. ¶0037 (Please see accompanying table) - a data model for a transaction may be defined as: … leaf ssid { type string; description “SSID of the client”; });
with an exchange of data packets over the enterprise network between network devices associated with stations utilizing the SSID, (¶0037 (Please see accompanying table) - a data model for a transaction may be defined as: … description “Describes the reason due to which the event is triggered.”; } leaf slot-id { type uint8; description “Slot ID for a client event”; } leaf ap-mac { type yang:mac-address; description “MAC address of the Access point”; } leaf ssid { type string; description “SSID of the client”; } leaf ipv4 { type inet:ipv4-address; description “IPv4 address of the client”; } leaf ipv6 { type inet:ipv6-address; description “ipv6 address of the client”);
to collect real-time network device connection statistics associated with the SSID as a whole and each station utilizing the SSID including exchange of data packets over the enterprise network between network devices associated with stations utilizing the SSID, to collect real-time network device connection statistics associated with the SSID as a whole and with each station utilizing the SSID; (¶0018 - In a wireless network, the most relevant insights are based on real-time tracking of issues with the client from the perspective of end-user experience. Fig. 3 & ¶0061 - Using the real-time statistics such as the first timestamp can accurately track the client state and minimize the traffic that gets lost in the transmission. Please also see the table in ¶0037 which records client identity, AP, SSID, authentication time and DHCP time);
tracking a time interval between samples of the collected data packets for each phase of the connection, including the association phase, the authentication phase and the DHCP phase of a connection; (¶0045 - In an embodiment, upon receiving a wireless networking access point association request from a client device, the time series table is generated. The client event may include a series of transactions that may comprise an association transaction, an authentication transaction, a DHCP transaction, or mobility transaction. The order and the number of transactions in the client event sequence can vary based on the network configuration. Please also see ¶0046-¶0048);
detecting that a specific one of the respective dynamic thresholds for one of the respective connection phases is out of range; (Fig. 1A & ¶0047 - As shown in FIG. 1A, upon receiving the request, a time value for the association time is stored in the time series table. The time value can be calculated using a timer associated with the association transaction. Each transaction is associated with a configurable timer that is set to a certain threshold. When the timer expires (i.e., meeting the threshold), the transaction is considered as a “failed transaction” and the process ends. Please also see ¶0051);
and responsive to the out-of-range detection, checking for network issues corresponding to the phase of the specific dynamic threshold (¶0055 - At step 220, if it is determined that the authentication transaction is successfully performed, the process proceeds to the next transaction (e.g., DHCP transaction). On the other hand, upon determining that the authentication is not successfully performed, the process ends with a failure and a data frame with a type of failure is determined by the computing device and sent to the cloud computing device at step 250. The computing device determines the transaction type (e.g., failed transaction), result type (e.g., failed) and failed reason (e.g., wrong password). ¶0056 - Therefore, the timeout threshold for the DHCP transaction can be different from the timeout threshold for the authentication transaction. When the timer for the DHCP process expires, the computing device determines that the process ends with a failure (e.g., failed transaction) and the data frame with the analytics for failure is sent to the cloud computing device at step 250. The data frame for the DHCP failure may include different information from the data frame for the authentication failure. Please also see ¶0051);
Yet, Gaokar does not explicitly teach for using unsupervised machine learning to derive thresholds for respective connection phase, unique for an enterprise network, identifying, for each respective connection phase, cluster means for the tracked time intervals; calculating, for each respective connection phase, a weighted average using the tracked time intervals, the cluster means, and a number of samples in each cluster; deriving, with a processor of the network management device,
However, in the analogous art, Dherange explicitly teaches for using unsupervised machine learning to derive thresholds for respective connection phase, unique for an enterprise network, (Fig. 1, 3, 8-12 & ¶0029 - an unsupervised method (or clustering) may be used for anomaly detection. ¶0075 - 405: Threshold value t is subject to the data being analyzed. ¶0146 - Deep learning models are designed to emulate unsupervised machine learning models where no data munging or pre-processing is required for input data. Fig. 3 & ¶0040 - A ML model may be used to create the baseline behavior of a user with parameter guidance from Feature Selection);
identifying, for each respective connection phase, cluster means for the tracked time intervals; (¶0149 - 3. KMeans transform LDA topic features into clustering features where cluster centers and cluster prediction are done. ¶0153 - The vector features that facilitates the cosine similarity computation from the LDA topic features against KMeans cluster centers. ¶0155 - The mechanism of anomaly detection that depends on the concept of model training process to establish a norm represented by the KMeans clustering centers and a mathematical threshold based on the statistical summary derived from the training dataset);
calculating, for each respective connection phase, a weighted average using the tracked time intervals, the cluster means, and a number of samples in each cluster; deriving, with a processor of the network management device, (¶0153 - The vector features that facilitates the cosine similarity computation from the LDA topic features against KMeans cluster centers. ¶0155 - The mechanism of anomaly detection that depends on the concept of model training process to establish a norm represented by the KMeans clustering centers and a mathematical threshold based on the statistical summary derived from the training dataset. ¶0157 - Anomalies that are based on distance/similarity deviation from the norm can then be identified by the prediction process that is described as follows. The prediction section of the pipeline is carried out by the implementation of KMeans Anomaly Detector or Random Forest Anomaly Detector. The difference between these two detectors is how the weights are assigned to the distance/similarity average that represents a raw anomaly score: ¶0158 - 1. KMeans Anomaly Detector: the distance/similarity average is a weighted average that takes into account the sizes of clusters from the cluster prediction of the KMeans model. ¶0160 - During the training phase, the goal is to find an optimal threshold that is used as a scalar to establish the threshold for anomaly detection based on the formula as follows: Anomaly thresholding score=min+threshold*std ¶0161 - The distance/similarity averages of unseen data are then compared against the threshold established in the training process. A linear transformation is applied to the anomalous distance/similarity averages that map the raw scores to a numerical range of [50, 100]).
Therefore, it would have been obvious to one of the ordinary skilled in the art before the effective filing date of the claimed invention to add the teaching of Dherange to the teaching of Gaonkar. The motivation would be because the invention provides techniques that can be used to build computer software and devices that monitor a computer network or analyze data to detect anomaly in the usage or occurrence of a potentially fraudulent event (¶0003, Dherange).
Re. Claim 10, Gaonkar teaches a non-transitory computer-readable medium storing instructions that, when executed by a processor, perform a computer-implemented method (Claim 9);
as a baseline for identifying issues for new connections at different phases, the method comprising: (Fig. 1A & ¶0012 - The first transaction can include any of a wireless networking access point association request, an authentication request, a roaming request or a Dynamic Host Configuration Protocol (DHCP) request. ¶0044 - Each column includes a value for corresponding transaction information such as a start time, an association time, an authentication time, a DHCP time, a transaction type, a result type, or a type of failure. ¶0051 - In some embodiments, the computing device performs analytics to track real-time issues with the wireless connection to minimize computation efforts at the cloud computing device. Please also see ¶0056);
monitoring a Service Set Identifier (SSID), (¶0036 - In an embodiment, client events generated in the foregoing manner are stored in a Redis cache. An analytics module consumes these events pushed into a Redis DB and creates a transaction based on the above definition. ¶0037 (Please see accompanying table) - a data model for a transaction may be defined as: … leaf ssid { type string; description “SSID of the client”; });
with an exchange of data packets over the enterprise network between network devices associated with stations utilizing the SSID, (¶0037 (Please see accompanying table) - a data model for a transaction may be defined as: … description “Describes the reason due to which the event is triggered.”; } leaf slot-id { type uint8; description “Slot ID for a client event”; } leaf ap-mac { type yang:mac-address; description “MAC address of the Access point”; } leaf ssid { type string; description “SSID of the client”; } leaf ipv4 { type inet:ipv4-address; description “IPv4 address of the client”; } leaf ipv6 { type inet:ipv6-address; description “ipv6 address of the client”);
to collect real-time network device connection statistics associated with the SSID as a whole and each station utilizing the SSID including exchange of data packets over the enterprise network between network devices associated with stations utilizing the SSID, to collect real-time network device connection statistics associated with the SSID as a whole and with each station utilizing the SSID; (¶0018 - In a wireless network, the most relevant insights are based on real-time tracking of issues with the client from the perspective of end-user experience. Fig. 3 & ¶0061 - Using the real-time statistics such as the first timestamp can accurately track the client state and minimize the traffic that gets lost in the transmission. Please also see the table in ¶0037 which records client identity, AP, SSID, authentication time and DHCP time);
tracking a time interval between samples of the collected data packets for each phase of the connection, including the association phase, the authentication phase and the DHCP phase of a connection; (¶0045 - In an embodiment, upon receiving a wireless networking access point association request from a client device, the time series table is generated. The client event may include a series of transactions that may comprise an association transaction, an authentication transaction, a DHCP transaction, or mobility transaction. The order and the number of transactions in the client event sequence can vary based on the network configuration. Please also see ¶0046-¶0048);
detecting that a specific one of the respective dynamic thresholds for one of the respective connection phases is out of range; (Fig. 1A & ¶0047 - As shown in FIG. 1A, upon receiving the request, a time value for the association time is stored in the time series table. The time value can be calculated using a timer associated with the association transaction. Each transaction is associated with a configurable timer that is set to a certain threshold. When the timer expires (i.e., meeting the threshold), the transaction is considered as a “failed transaction” and the process ends. Please also see ¶0051);
and responsive to the out-of-range detection, checking for network issues corresponding to the phase of the specific dynamic threshold (¶0055 - At step 220, if it is determined that the authentication transaction is successfully performed, the process proceeds to the next transaction (e.g., DHCP transaction). On the other hand, upon determining that the authentication is not successfully performed, the process ends with a failure and a data frame with a type of failure is determined by the computing device and sent to the cloud computing device at step 250. The computing device determines the transaction type (e.g., failed transaction), result type (e.g., failed) and failed reason (e.g., wrong password). ¶0056 - Therefore, the timeout threshold for the DHCP transaction can be different from the timeout threshold for the authentication transaction. When the timer for the DHCP process expires, the computing device determines that the process ends with a failure (e.g., failed transaction) and the data frame with the analytics for failure is sent to the cloud computing device at step 250. The data frame for the DHCP failure may include different information from the data frame for the authentication failure. Please also see ¶0051);
Yet, Gaokar does not explicitly teach for using unsupervised machine learning to derive thresholds for each connection phase, unique for an enterprise network, identifying, for each respective connection phase, cluster means for the tracked time intervals; calculating , for each respective connection phase, a weighted average using the tracked time intervals, the cluster means, and a number of samples in each cluster; deriving, with a processor of the network management device,
However, in the analogous art, Dherange explicitly teaches for using unsupervised machine learning to derive thresholds for each connection phase, unique for an enterprise network, (Fig. 1, 3, 8-12 & ¶0029 - an unsupervised method (or clustering) may be used for anomaly detection. ¶0075 - 405: Threshold value t is subject to the data being analyzed. ¶0146 - Deep learning models are designed to emulate unsupervised machine learning models where no data munging or pre-processing is required for input data. Fig. 3 & ¶0040 - A ML model may be used to create the baseline behavior of a user with parameter guidance from Feature Selection);
identifying, for each respective connection phase, cluster means for the tracked time intervals; (¶0149 - 3. KMeans transform LDA topic features into clustering features where cluster centers and cluster prediction are done. ¶0153 - The vector features that facilitates the cosine similarity computation from the LDA topic features against KMeans cluster centers. ¶0155 - The mechanism of anomaly detection that depends on the concept of model training process to establish a norm represented by the KMeans clustering centers and a mathematical threshold based on the statistical summary derived from the training dataset);
calculating, for each respective connection phase, a weighted average using the tracked time intervals, the cluster means, and a number of samples in each cluster; deriving, with a processor of the network management device, (¶0153 - The vector features that facilitates the cosine similarity computation from the LDA topic features against KMeans cluster centers. ¶0155 - The mechanism of anomaly detection that depends on the concept of model training process to establish a norm represented by the KMeans clustering centers and a mathematical threshold based on the statistical summary derived from the training dataset. ¶0157 - Anomalies that are based on distance/similarity deviation from the norm can then be identified by the prediction process that is described as follows. The prediction section of the pipeline is carried out by the implementation of KMeans Anomaly Detector or Random Forest Anomaly Detector. The difference between these two detectors is how the weights are assigned to the distance/similarity average that represents a raw anomaly score: ¶0158 - 1. KMeans Anomaly Detector: the distance/similarity average is a weighted average that takes into account the sizes of clusters from the cluster prediction of the KMeans model. ¶0160 - During the training phase, the goal is to find an optimal threshold that is used as a scalar to establish the threshold for anomaly detection based on the formula as follows: Anomaly thresholding score=min+threshold*std ¶0161 - The distance/similarity averages of unseen data are then compared against the threshold established in the training process. A linear transformation is applied to the anomalous distance/similarity averages that map the raw scores to a numerical range of [50, 100]).
Therefore, it would have been obvious to one of the ordinary skilled in the art before the effective filing date of the claimed invention to add the teaching of Dherange to the teaching of Gaonkar. The motivation would be because the invention provides techniques that can be used to build computer software and devices that monitor a computer network or analyze data to detect anomaly in the usage or occurrence of a potentially fraudulent event (¶0003, Dherange).
Re. Claim 11, Gaonkar teaches a network device (Fig. 1-4 & ¶0059 - … the computing device can be an edge computing device such as a router or switch, or a network management station);
as a baseline for identifying issues for new connections at different phases, (Fig. 1A & ¶0012 - The first transaction can include any of a wireless networking access point association request, an authentication request, a roaming request or a Dynamic Host Configuration Protocol (DHCP) request. ¶0044 - Each column includes a value for corresponding transaction information such as a start time, an association time, an authentication time, a DHCP time, a transaction type, a result type, or a type of failure. ¶0051 - In some embodiments, the computing device performs analytics to track real-time issues with the wireless connection to minimize computation efforts at the cloud computing device. Please also see ¶0056);
the network device comprising: a processor; a network interface communicatively coupled to the processor and to the enterprise network; and a memory, communicatively coupled to the processor and storing instructions that, when executed by a processor: (Fig. 4 & ¶0071-¶0073);
track a Service Set Identifier (SSID), (¶0036 - In an embodiment, client events generated in the foregoing manner are stored in a Redis cache. An analytics module consumes these events pushed into a Redis DB and creates a transaction based on the above definition. ¶0037 (Please see accompanying table) - a data model for a transaction may be defined as: … leaf ssid { type string; description “SSID of the client”; });
with an exchange of data packets over the enterprise network between network devices associated with stations utilizing the SSID, (¶0037 (Please see accompanying table) - a data model for a transaction may be defined as: … description “Describes the reason due to which the event is triggered.”; } leaf slot-id { type uint8; description “Slot ID for a client event”; } leaf ap-mac { type yang:mac-address; description “MAC address of the Access point”; } leaf ssid { type string; description “SSID of the client”; } leaf ipv4 { type inet:ipv4-address; description “IPv4 address of the client”; } leaf ipv6 { type inet:ipv6-address; description “ipv6 address of the client”);
to collect real-time network device connection statistics associated with the SSID as a whole and each station utilizing the SSID; (¶0018 - In a wireless network, the most relevant insights are based on real-time tracking of issues with the client from the perspective of end-user experience. Fig. 3 & ¶0061 - Using the real-time statistics such as the first timestamp can accurately track the client state and minimize the traffic that gets lost in the transmission. Please also see the table in ¶0037 which records client identity, AP, SSID, authentication time and DHCP time);
measure a time interval between samples of the collected data packets for each phase of the connection, including the association phase, the authentication phase and the DHCP phase of a connection; (¶0045 - In an embodiment, upon receiving a wireless networking access point association request from a client device, the time series table is generated. The client event may include a series of transactions that may comprise an association transaction, an authentication transaction, a DHCP transaction, or mobility transaction. The order and the number of transactions in the client event sequence can vary based on the network configuration. Please also see ¶0046-¶0048);
and detect a specific dynamic threshold for phase of the connection is out of range, and responsive to the out-of-range detection, (Fig. 1A & ¶0047 - As shown in FIG. 1A, upon receiving the request, a time value for the association time is stored in the time series table. The time value can be calculated using a timer associated with the association transaction. Each transaction is associated with a configurable timer that is set to a certain threshold. When the timer expires (i.e., meeting the threshold), the transaction is considered as a “failed transaction” and the process ends. Please also see ¶0051);
and check for network issues corresponding to the phase of the specific dynamic threshold (¶0055 - At step 220, if it is determined that the authentication transaction is successfully performed, the process proceeds to the next transaction (e.g., DHCP transaction). On the other hand, upon determining that the authentication is not successfully performed, the process ends with a failure and a data frame with a type of failure is determined by the computing device and sent to the cloud computing device at step 250. The computing device determines the transaction type (e.g., failed transaction), result type (e.g., failed) and failed reason (e.g., wrong password). ¶0056 - Therefore, the timeout threshold for the DHCP transaction can be different from the timeout threshold for the authentication transaction. When the timer for the DHCP process expires, the computing device determines that the process ends with a failure (e.g., failed transaction) and the data frame with the analytics for failure is sent to the cloud computing device at step 250. The data frame for the DHCP failure may include different information from the data frame for the authentication failure. Please also see ¶0051);
Yet, Gaokar does not explicitly teach to use unsupervised machine learning to derive thresholds for each connection phase, unique for an enterprise network, find cluster means for the tracked time differences for each of the connection phases; calculate weighted averages for each phase of the connection using the time difference, the cluster means and the number of samples in each cluster; derive the dynamic thresholds for each phase of connections from the weighted averages;
However, in the analogous art, Dherange explicitly teaches to use unsupervised machine learning to derive thresholds for each connection phase, unique for an enterprise network, (Fig. 1, 3, 8-12 & ¶0029 - an unsupervised method (or clustering) may be used for anomaly detection. ¶0075 - 405: Threshold value t is subject to the data being analyzed. ¶0146 - Deep learning models are designed to emulate unsupervised machine learning models where no data munging or pre-processing is required for input data. Fig. 3 & ¶0040 - A ML model may be used to create the baseline behavior of a user with parameter guidance from Feature Selection);
find cluster means for the tracked time differences for each of the connection phases; (¶0149 - 3. KMeans transform LDA topic features into clustering features where cluster centers and cluster prediction are done. ¶0153 - The vector features that facilitates the cosine similarity computation from the LDA topic features against KMeans cluster centers. ¶0155 - The mechanism of anomaly detection that depends on the concept of model training process to establish a norm represented by the KMeans clustering centers and a mathematical threshold based on the statistical summary derived from the training dataset);
calculate weighted averages for each phase of the connection using the time difference, the cluster means and the number of samples in each cluster; derive the dynamic thresholds for each phase of connections from the weighted averages; (¶0153 - The vector features that facilitates the cosine similarity computation from the LDA topic features against KMeans cluster centers. ¶0155 - The mechanism of anomaly detection that depends on the concept of model training process to establish a norm represented by the KMeans clustering centers and a mathematical threshold based on the statistical summary derived from the training dataset. ¶0157 - Anomalies that are based on distance/similarity deviation from the norm can then be identified by the prediction process that is described as follows. The prediction section of the pipeline is carried out by the implementation of KMeans Anomaly Detector or Random Forest Anomaly Detector. The difference between these two detectors is how the weights are assigned to the distance/similarity average that represents a raw anomaly score: ¶0158 - 1. KMeans Anomaly Detector: the distance/similarity average is a weighted average that takes into account the sizes of clusters from the cluster prediction of the KMeans model. ¶0160 - During the training phase, the goal is to find an optimal threshold that is used as a scalar to establish the threshold for anomaly detection based on the formula as follows: Anomaly thresholding score=min+threshold*std ¶0161 - The distance/similarity averages of unseen data are then compared against the threshold established in the training process. A linear transformation is applied to the anomalous distance/similarity averages that map the raw scores to a numerical range of [50, 100]).
Therefore, it would have been obvious to one of the ordinary skilled in the art before the effective filing date of the claimed invention to add the teaching of Dherange to the teaching of Gaonkar. The motivation would be because the invention provides techniques that can be used to build computer software and devices that monitor a computer network or analyze data to detect anomaly in the usage or occurrence of a potentially fraudulent event (¶0003, Dherange).
Claims 2 and 4 are rejected under 35 U.S.C. 103 as being unpatentable over Gaonkar and Dherange, as applied to Claims 1 and 10-11 above, and further in view of Sane, Rushikesh, Using Densities to Detect Nested Clusters, Master’s Thesis, University of Eastern Finland, School of Computing, Computer Science, April 2020, Sane hereinafter.
Re. Claim 2, Gaonkar and Dherange teach Claim 1.
Yet, Gaonkar does not explicitly teach assigned weights for calculating the weighted averages comprises the number of samples for the connection phases divided by the cluster means for the connection phases.
However, in the analogous art, Dherange explicitly teaches assigned weights for calculating the weighted averages (Fig. 1, 3, 8-12 & ¶0157-¶0158);
Therefore, it would have been obvious to one of the ordinary skilled in the art before the effective filing date of the claimed invention to add the teaching of Dherange to the teaching of Gaonkar. The motivation would be because the invention provides techniques that can be used to build computer software and devices that monitor a computer network or analyze data to detect anomaly in the usage or occurrence of a potentially fraudulent event (¶0003, Dherange).
Yet, Gaonkar and Dherange do not explicitly teach comprises the number of samples for the connection phases divided by the cluster means for the connection phases.
However, in the analogous art, Sane explicitly discloses comprises the number of samples for the connection phases divided by the cluster means for the connection phases (Fig. 26 & Page 26, Section 5.3.2 – Please see equation 9. - Where n is the number of data vectors in a cluster. Page 26, Section 5.3.3 - Updating weights change the power of centroids to attract data points. Centroids with lower weights can attract points from larger distances and centroids with higher weights can attract points from smaller distances. Centroid weights are calculated using the formula: Please see equation 10).
Therefore, it would have been obvious to one of the ordinary skills in the art before the effective filling date of the claimed invention to add the teaching of Sane to the teachings of Gaonkar and Dherange. The motivation would be because the paper discusses different methods of clustering, distances used in clustering and other technicalities related to clustering (Page 2, 1.3 Thesis Structure, Sane).
Re. Claim 4, Gaonkar and Dherange teach Claim 1.
Yet, Gaonkar and Dherange does not explicitly teach the weighted averages are inversely proportional to the cluster means.
However, in the analogous art, Sane explicitly teaches the weighted averages are inversely proportional to the cluster means (Fig. 26 & Page 26, Section 5.3.2 – Please see equation 9. - Where n is the number of data vectors in a cluster. Page 26, Section 5.3.3 - Updating weights change the power of centroids to attract data points. Centroids with lower weights can attract points from larger distances and centroids with higher weights can attract points from smaller distances. Centroid weights are calculated using the formula: Please see equation 10). Examiner interprets the cluster weight is derived from equation 9, so weighting will decrease as the mean-distance term increases, therefore making the weighting inversely proportional to the mean cluster quantity).
Therefore, it would have been obvious to one of the ordinary skills in the art before the effective filling date of the claimed invention to add the teaching of Sane to the teachings of Gaonkar and Dherange. The motivation would be because the paper discusses different methods of clustering, distances used in clustering and other technicalities related to clustering (Page 2, 1.3 Thesis Structure, Sane).
Claim 3 is rejected under 35 U.S.C. 103 as being unpatentable over Gaonkar and Dherange, as applied to Claims 1 and 10-11 above, and further in view of Wang et al. (US 2014/0143251 A1), Wang hereinafter.
Re. Claim 3, Gaonkar and Dherange teach Claim 1.
Yet, Gaonkar and Dherange do not explicitly teach the weighted averages are proportional to the number of samples.
However, in the analogous art, Wang explicitly discloses the weighted averages are proportional to the number of samples (Fig. 1-3 & ¶0066 - … we simply use the number of original data points assigned to each centroid as its weight. Please see ¶0064-¶0066).
Therefore, it would have been obvious to one of the ordinary skills in the art before the effective filling date of the claimed invention to add the teaching of Wang to the teachings of Gaonkar and Dherange. The motivation would be because clustering at a certain level usually produces unbalanced clusters containing possibly quite different numbers of data points. If we intend to keep equal contribution from each original data point, the cluster centroids passed to a higher level in the hierarchy should be weighted and the clustering method should take those weights into account (¶0063, Wang).
Claim 5 is rejected under 35 U.S.C. 103 as being unpatentable over Gaonkar and Dherange and Sane, as applied to Claims 2 and 4 above, and further in view of Alavudin et al. (US 2014/0254500 A1), Alavudin hereinafter.
Re. Claim 5, Gaonkar and Dherange and Sane teach Claim 4.
Yet, Gaonkar and Dherange and Sane do not explicitly teach the association phase comprises association request and association request data packets, the authentication phase comprises Mi-handshake and M4- handshake data packets, and the DHCP phase comprises DHCP- Discover and DHCP-Acknowledge data packets.
However, in the analogous art, Alavudin explicitly discloses the association phase comprises association request and association request data packets, (Fig. 2-3, 7 & ¶0017 - The Association Request may be transmitted by the wireless device to an access point for the WLAN. Fig. 2-3, 7 & ¶0022 - packet format 200 may represent an IEEE 802.11 WLAN frame or packet generated by a wireless device (e.g., wireless device 112-1) and used to transmit an Association Request to an access point for a WLAN. Please also see Claim 10);
the authentication phase comprises Mi-handshake and M4- handshake data packets, (Fig. 3, 7 & ¶0030 - the security handshake may include the logic and/or features of wireless device 112-1 generating and transmitting a first Authentication Frame having identification information to initiate the security handshake to allow access point 114 to authenticate wireless device 112-1. In some other examples, the security handshake may include the logic and/or features of wireless device 112-1 initiating a more security intensive four-way handshake process to authenticate wireless device 112-1.The four-way handshake process may be initiated as described in IEEE 802.11i-2004, "Amendment 6: Medium Access Control (MAC) Security Enhancements", published July 2004 ("IEEE 802.11i").);
and the DHCP phase comprises DHCP- Discover and DHCP-Acknowledge data packets (Fig. 3, 7 & ¶0100 - A DHCP discover message may then be sent to the DHCP server for the wireless device. A DHCP request message to indicate a request for a given IP address may then be sent and a DHCP ACK message may then be received from the DHCP server that grants the given IP address).
Therefore, it would have been obvious to one of the ordinary skills in the art before the effective filling date of the claimed invention to add the teaching of Alavudin to the teachings of Dherange and Gaonkar and Sane. The motivation would be because it provides examples directed to improvements for wireless devices to couple to a WLAN and obtain an IP address using wireless technologies associated with Wi-Fi. These wireless technologies may include wireless technologies suitable for use with access points deployed in a WLAN (¶0013, Alavudin).
Claim 6 is rejected under 35 U.S.C. 103 as being unpatentable over Gaonkar and Dherange, as applied to Claims 1 and 10-11 above, and further in view of Abraham (US 2005/0203978 A1), Abraham hereinafter.
Re. Claim 6, Gaonkar and Dherange teach Claim 1.
Yet, Gaonkar and Dherange do not explicitly teach storing the cluster means and the weighted averages; tracking time intervals between data packets collected for new samples of collected data; and recalculating the dynamic thresholds using the stored cluster means and weighted averages with the new time intervals.
However, in the analogous art, Abraham explicitly discloses storing the cluster means and the weighted averages; (Fig. 3 & ¶0012 - The mean can be calculated if the full set of data points is stored. ¶0021 - …an existing ongoing weighted average based upon at least one earlier data sample and stored in a memory of the computer);
tracking time intervals between data packets collected for new samples of collected data; (¶0069 - Therefore, it is useful if the processing means 210 monitors the data transfer rate by taking a data sample of the transfer rate at predetermined time intervals);
and recalculating the dynamic thresholds using the stored cluster means and weighted averages with the new time intervals (¶0012 - With each new data point gathered, this weighted average will have to be recalculated using the full set of data points as the weight associated with each data point changes with each further data point collected. Further, the standard deviation would also have to be recalculated. ¶0017 - the processing means is further arranged to calculate an acceptable discrepancy limit for each new data sample that is received based on the ongoing weighted average that has been calculated for that new data sample. ¶0021 - cause a computer to collect at least one new data sample and using the new data sample and an existing ongoing weighted average based upon at least one earlier data sample… to calculate a new ongoing weighted average. ¶0069 - The data samples taken by the processing means 210 can then be applied to the method as described in relation to FIG. 3 to determine whether any of the data samples are outside the predetermined parameters).
Therefore, it would have been obvious to one of the ordinary skill in the art before the effective filling date of the claimed invention to add the teaching of Abraham to the teachings of Dherange and Gaonkar. The motivation would be because the invention relates to an analysis apparatus arranged to analyse data and detect change and related methods, and an apparatus which detects significant changes in a system has many uses (¶0001-¶0002, Abraham).
Claim 7 is rejected under 35 U.S.C. 103 as being unpatentable over Gaonkar and Dherange, as applied to Claims 1 and 10-11 above, and further in view of Sydir et al. (US 2014/0045536 A1), Sydir hereinafter.
Re. Claim 7, Gaonkar and Dherange teach Claim 1.
Yet, Gaonkar and Dherange do not explicitly teach the SSID is configured to an access point.
However, in the analogous art, Sydir explicitly discloses the SSID is configured to an access point (Fig. 1 & ¶0022 - Each of the APs may have an associated service set identifier (SSID)…).
Therefore, it would have been obvious to one of the ordinary skills in the art before the effective filling date of the claimed invention to add the teaching of Sydir to the teachings of Gaonkar and Dherange. The motivation would be because it provides systems and methods for providing location information, with the location information being determined based at least in part on service set identifiers (SSIDs) and/or basic service set identifiers (BSSIDs) associated with wireless communication access points (APs) (¶0011, Sydir).
Claim 8 is rejected under 35 U.S.C. 103 as being unpatentable over Gaonkar and Dherange, as applied to Claims 1 and 10-11 above, and in further view of Sydir, and Crandall et al. (US 2006/0072502 A1), Crandall hereinafter.
Re. Claim 8, Gaonkar and Dherange teach Claim 1.
Yet, Gaonkar and Dherange do not explicitly teach the SSID is configured to a plurality of access points, wherein throughput and multicast rate are monitored individually for each access point.
However, in the analogous art, Sydir explicitly teaches the SSID is configured to a plurality of access points (Fig. 1 & ¶0023 - Multiple APs 106 may share the same SSID. For example, if several APs 106 are controlled by the same entity, those APs 106 may share a common SSID);
Yet, Sydir does not explicitly teach throughput and multicast rate are monitored individually for each access point.
However, in the analogous art, Crandall explicitly discloses throughput and multicast rate are monitored individually for each access point (Fig. 2 & ¶0024 - By monitoring these multicasts, each AP will again have their own traffic load information and the traffic load information for any adjacent APs. Fig. 2 & ¶0017 - Every AP may then predict its potential throughput on each channel based on the traffic load information collected, and find a best channel which corresponds to a maximum predicted throughput).
Therefore, it would have been obvious to one of the ordinary skills in the art before the effective filling date of the claimed invention to add the teaching of Crandall to the teachings of Gaonkar, Dherange and Sydir. The motivation would be because deploying a plurality of APs in a WLAN, while minimizing interference and maximizing overall throughput, is desired (¶0004, Crandall).
Claim 9 is rejected under 35 U.S.C. 103 as being unpatentable over Gaonkar and Dherange, as applied to Claims 1 and 10-11 above, and further in view of Chandrasekaran et al. (US 2021/0385143 A1), Chandrasekaran hereinafter.
Re. Claim 9, Gaonkar and Dherange teach Claim 1.
Yet, Gaonkar and Dherange do not explicitly teach identifying at least one network issue of the network issues comprising at least one of: high access point density, Wi-Fi interference, high client density, slow cryptographic algorithm, poor uplink and high channel utilization.
However, in the analogous art, Chandrasekaran explicitly teaches identifying at least one network issue of the network issues comprising at least one of: high access point density, Wi-Fi interference, high client density, slow cryptographic algorithm, poor uplink and high channel utilization (Fig. 16-19 & ¶0009 - … the wireless metrics include SNR (signal to noise ratio), packet loss/retransmits, connected access points, channel utilization at the access points, neighboring access points information, rogue/outside-network access points information, interference information in the RF (Radio Frequency) bands… Fig. 16-19 & ¶0072 - For example at a particular time interval, a user/device may have poor page load times, high transmission control protocol (TCP) retransmits, low signal-to-noise ratio (SNR), high AP channel utilization. Examiner interprets that only one of the claimed features to be mapped because of the presence of “at least one of”).
Therefore, it would have been obvious to one of the ordinary skills in the art before the effective filling date of the claimed invention to add the teaching of Chandrasekaran to the teachings of Gaonkar and Dherange. The motivation would be because traditional performance monitoring or analytics tools work in silos on individual layers of the network stack and do not analyze correlated information across the multiple layers of the network stack to provide a comprehensive view of the network performance from end-user perspective (¶0004, Chandrasekaran).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Mermoud et al. (US 2019/0342195 A1) – Please see Abstract and Fig. 1-6.
Vasseur et al. (US 2020/0162341 A1) – Please see Abstract and Fig. 1-5.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ALYSSA WILLIAMS whose telephone number is (571)270-7673. The examiner can normally be reached Mon-Fri 8-5pm. 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, Ayman Abaza can be reached on (571) 270-0422. 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.
/ALYSSA WILLIAMS/Examiner, Art Unit 2465B
/CHRISTOPHER T WYLLIE/Examiner, Art Unit 2465
Prosecution Insights