DETAILED ACTION
This office action is in response to the application filed on 05/14/2026. Claim(s) 1-17 is/are pending and are examined.
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 .
Response to Arguments
Applicant's arguments filed on 05/14/2026 have been fully considered but they are not persuasive for the following reasons:
Applicant’s Argument:
Kommula describes the management of firewall policies using SmartNICs (smart
network interface cards) and machine learning within cloud data center environments. A variety of telemetry data is collected about applications running in the data center, and that telemetry data is analyzed to determine a firewall policy to install in the data center. Paras. 0105 to 0117. The analysis determines whether there is "a change in the regular communication patterns of an application" in the data center. Para 0137. The telemetry data in Kommula does not mention telemetry collected from clients, nor client signatures. Rather, the telemetry data refers to traffic and performance data collected from internal infrastructure components in the data center, such as the SmartNICs, switches and routers. Para. 006, 0086, Abstract, see also 0008 (mentioning the use of SNMP for monitoring packet flows). In sum, Kommula merely teaches that traffic from applications running in a data center can be analyzed via machine learning to determine what firewall policy to use in the data center. There is no notion of the combination of first determining whether site traffic is abnormally high for the time period, and then determining whether the high traffic is due to a subset of clients (as indicated by the client signatures), and if so restricting traffic.
(Applicant’s response filed on 05/14/2026, page 5-7).
Examiner’s Response:
The Examiner respectfully disagrees. In the cited portion of Kommoula ¶ 114 teaches, “execute a machine learning model to determine a traffic prediction based on traffic session metrics data collected over a first period of time. The system may be configured to determine an anomaly in traffic based on a comparison of the traffic prediction to traffic session metrics data collected over a second period of time or at a second time (e.g., current traffic session metrics data). For example, the anomaly may represent a domain name service (DNS) attack, a TCP flood attack, etc. The system may be configured to, based on the determination of the anomaly, generate an indication of the anomaly.” If the machine learning model is able to identify a TCP flood attack it must have an understanding of the normal and abnormal amount of TCP handshake requests being made in a time frame as a TCP flood attack is an attack that deals specifically with sending an overwhelming amount of traffic at once towards a target. Therefore, Kommoula must be gathering metrics that are understanding the normal and abnormal traffic volume as such Kommoula does teach that aspect of the limitation. Further, the cited portion of Kommula ¶ 6 teaches, “This disclosure presents a close-loop framework for implementing application-aware network services using SmartNICs (also referred to herein as DPUs). In some examples, a machine learning model executing on a device and one or more SmartNICs may create a self-correcting network for management and observability of microservice-based applications.” And later in Kommoula ¶ 115 Fig. 11A teaches, “a distributed firewall (e.g., DF 650) may run on every SmartNIC (e.g., POD 1, POD 2, and POD 3) attached to every node of the Kubernetes platform. The distributed firewall may monitor service mesh traffic exiting out and entering each node of the Kubernetes cluster.” Shows that the network traffic is being collected at thes SmartNIC devices and services that Applicant has pointed out. However, if Fig. 11A is scene the SmartNIC pods that are being discussed clearly contain clients as such the information that is being collected includes client data that is being used to build a normal routine pattern for that client in other words a signature for the clients usage. Even if Kommoula did not teach the specific client devices the limitations of claim 1 are taught by Kommoula and Lin and Lin Col. 7 Ln. 55-64 teaches, “A client device 106 can correspond to a distinct computing device that can configure, manage, or sends queries to the system 102. Examples of client devices 106 may include, without limitation, smart phones, tablet computers, handheld computers, wearable devices, laptop computers, desktop computers, servers, portable media players, gaming devices, or other device that includes computer hardware (e.g., processors, non-transitory, computer-readable media, etc.) and so forth.” Which clearly teaches the client devices that the Applicant has pointed out. As such it would be obvious for one ordinarily skilled in the art having the teachings of Kommoula and Lin in front of them to combine the network traffic analysis of Kommoula with the client devices of Lin. The motivation to do so, Lin Col. 30 Ln. 7-10, to help improve the performance of components in the IT environment. As such separately and in combination Kommoula in view of Lin teaches the claimed limitations.
Applicant’s Argument:
Hence, Lin merely teaches that two successive machine learning models can be used to see if a device is infected with malware. One model looks at the IP traffic, and another at the URLs. There is no notion of the combination of first determining whether site traffic is abnormally high for the time period, and then determining whether the high traffic is due to a subset of clients (as indicated by the client signatures), and if so restricting traffic. (Applicant’s response filed on 05/14/2025, page 7).
Examiner’s Response:
The Examiner respectfully disagrees. The cited portion of Lin claim 5 teaches, “responsive to the subset of network traffic metrics being classified as highly suspicious or suspicious, applying a second machine learning model to metrics of the URL traffic data, the second machine learning model configured to: generate a second feature vector through feature extraction of the metrics of the URL traffic data, and evaluate the second feature vector for the presence of beaconing and classify the metrics of the URL traffic data.” Which clearly teaches the concept of taking identified network traffic that has been deemed suspicious from a prior classifier to be fed into a second machine learning model to it being labeled as such. When taken in combination with the teachings of Kommoula as discussed above it would be obvious for that suspicious classification to be applied to abnormaly high traffic flow. As such Kommoula in view of Lin teaches the claimed limitation.
Applicant’s Argument:
Hence, these paragraphs merely describe in more detail the telemetry data collected from the internal infrastructure components about data center traffic. These paragraphs certainly don't teach that such telemetry data are client signatures hitting a site or that such telemetry data is used in a combination involving first determining whether site traffic is abnormally high for the time period, and then determining whether the high traffic is due to a subset of clients (as identified by the client signatures), and if so restricting traffic. (Applicant’s response filed on 05/14/2026, page 8).
Examiner’s Response:
The Examiner respectfully disagrees. The cited portion of Kommoula ¶ 199-200 teaches, “Example labels include source and destination IP address, source and destination port number, source workload name (which may include a pod or container name), connection protocol and direction, cluster node name and identification (ID), and/or the like. (i.e., protocol and network characteristics)”. Clearly teaches that the gathered data collected from the pods contain information including network and protocol characteristics. As established above Kommoula and Kommoula in view of Lin teaches the claimed idea of client with the data gathered being used to determine normal behavior also known as a signature of the client, as such Kommoula in view of Lin teaches the claimed limitation above.
Applicant’s Argument:
Stefan describes a way to detect malware on a device. A malware detector runs on a
device to analyze the "derived feature values" of software executing on a device, and determine whether the features look like malware. Abstract. Stefan mentions that the detector may not be able to collect all of the "derived feature values", so it can substitute feature values in such instances so that the analysis does not fail. The substitute feature values, referred to as "surrogates", are "harvested" separately from different devices. In paragraph 0068, cited by the Office Action, Stefan says that the harvested feature values can be associated with a given device profile. In this way, the system will know which harvested feature values to use as the substitutes, when needed.
Hence, Stefan's paragraph 0068 merely says that a device profile can be used to supply typical device characteristics when they are missing. This is not part of a method of managing site traffic as recited in claim 1 and incorporated into claim 3. Moreover, Stefan's device profile does not appear to have any obvious relation to Kommura's firewall policy selector for a data center, or to Lin's use of machine learning to find malware beacons, both of which are looking at network traffic not device profiles. That suggests the combination is based on impermissible hindsight reasoning using Applicant's claim as a template. (Applicant’s response filed on 05/14/2026, page 9).
Examiner’s Response:
The Examiner respectfully disagrees. The cited portion of Stefan ¶ 68 teaches, “Server may further receive a device profile from each client, including a client identifier and a set of data characterizing a hardware and/or software configuration of the respective client (e.g., device type, make, model, OS version, various current settings, etc.). Server may then use such information in associating harvested feature values with a specific device type and/or configuration.” Which clearly teaches collecting the specific client information that is stated in claim 3 that being an operating system, user agent information, and hardware type. Applicant seems to be focusing on the harvesting feature of Stefan and not the cited information collected from Stefan which is the focus of the cited portion and combination with Kommoula and Lin. It would have been obvious to one with ordinary skill the art, prior to the applicant's earliest effective filing date, to combine the teachings of Kommula in view of Lin with Stefan, to modify the intelligent firewall policy system of Kommula with the multiple machine learning models of Lin with the client characteristics of Stefan. The motivation to do so constitutes applying a known technique of collecting client data to known devices and/or methods for network security ready for improvement to yield predictable results of gathering attacker information. As such the combination of Kommoula-Lin-Stefan is apparent and teaches the claimed limitation.
Applicant's arguments with respect to amended claim 1 have been fully considered and the 112(b) rejection is withdrawn.
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.
Claim(s) 1-2, 5-6, 9-10, 13-14, and 17 is/are rejected under 35 U.S.C. 103 as being unpatentable over Kommula (US 2025/0211575 A1), hereinafter Kommula in view of Lin (US 12,199,997 B1), hereinafter Lin.
Regarding Claim(s) 1, 9, and 17 Kommula teaches:
A method to manage traffic to a site, comprising: (Kommula ¶ 6 teaches, a machine learning model executing on a device and one or more SmartNICs may create a self-correcting network for management and observability of microservice-based applications. Along with, or through, the use of machine learning techniques, SmartNICs may perform continuous monitoring of application performance metrics and can take corrective actions to remediate security or performance issues in real-time (or near real-time). ¶ 225-230 teaches, a method and the computer-readable media for executing the method.)
applying current site traffic against a first machine learning model that has been trained against past traffic patterns at the site to predict traffic volume; (Kommula ¶ 6, This disclosure presents a close-loop framework for implementing application-aware network services using SmartNICs (also referred to herein as DPUs). In some examples, a machine learning model executing on a device and one or more SmartNICs may create a self-correcting network for management and observability of microservice-based applications. ¶ 48, Although customer sites 11 and public network 4 are illustrated and described primarily as edge networks of service provider network 7, in some examples, one or more of customer sites 11 and public network 4 are tenant networks within data center 10 or another data center. ¶ 114 teaches, execute a machine learning model to determine a traffic prediction based on traffic session metrics data collected over a first period of time. The system may be configured to determine an anomaly in traffic based on a comparison of the traffic prediction to traffic session metrics data collected over a second period of time or at a second time (e.g., current traffic session metrics data). For example, the anomaly may represent a domain name service (DNS) attack, a TCP flood attack, etc. The system may be configured to, based on the determination of the anomaly, generate an indication of the anomaly.)
(Kommula ¶ 109-110 and 114 teaches, Anomaly detection service may include one or more machine learning model(s) , stored in model server. execute a machine learning model to determine a traffic prediction based on traffic session metrics data collected over a first period of time. The system may be configured to determine an anomaly in traffic based on a comparison of the traffic prediction to traffic session metrics data collected over a second period of time or at a second time (e.g., current traffic session metrics data). For example, the anomaly may represent a domain name service (DNS) attack, a TCP flood attack, etc. The system may be configured to, based on the determination of the anomaly, generate an indication of the anomaly.)
based on an indication that the deviation from predicted traffic volume is being driven by a subset of the plurality of client signatures, taking an action to restrict traffic to the site. (Kommula ¶ 13 teaches, determining of subset of applications of the plurality of applications that run on a first host of the plurality of hosts; determining a subset of firewall policies of a plurality of firewall polices, each of the subset of firewall policies applying to at least one respective application of the subset of applications; (i.e., client signatures) generating an indication of the subset of firewall policies; and sending the indication to a management plane of a distributed firewall. ¶ 117 teaches, action unit 612 (FIG. 8) may dynamically create and/or select a distributed firewall policy to mitigate the anomaly. As shown in FIG. 11B, any traffic originating from the compromised service of pod 654 may be blocked by the distributed firewall.)
Kommula does not appear to explicitly teach but in related art:
based on an indication that current traffic volume deviates from the predicted traffic volume for a current time period, (Lin claim 1, applying a first trained machine learning model to the subset of network traffic metrics to: generate a feature vector through feature extraction of the subset of network traffic metrics, and evaluate the feature vector for a presence of beaconing and classify the subset of network traffic metrics)applying current site traffic against a second machine learning model that has been trained against past traffic patterns at the site to predict a traffic volume from each of a plurality of client signatures; and, (Lin claim 5, responsive to the subset of network traffic metrics being classified as highly suspicious or suspicious, applying a second machine learning model to metrics of the URL traffic data, the second machine learning model configured to: generate a second feature vector through feature extraction of the metrics of the URL traffic data, and evaluate the second feature vector for the presence of beaconing and classify the metrics of the URL traffic data.)
It would have been obvious to one with ordinary skill the art, prior to the applicant's earliest effective filing date, to combine the teachings of Kommula with Lin, to modify the intelligent firewall policy system of Kommula with the multiple machine learning models of Lin. The motivation to do so, Lin Col. 30 Ln. 7-10, to help improve the performance of components in the IT environment.
Regarding Claim(s) 2 and 10 Kommula in view of Lin teaches:
The method of claim 1, wherein client signatures are characterized by one or more of: (Kommula in view of Lin teaches the parent claim above.) (i) hardware characteristics, (ii) software characteristics, (iii) user preferences, (iv) protocol characteristics, and (v) network characteristics. (Kommula ¶ 199-200 teaches, Example labels include source and destination IP address, source and destination port number, source workload name (which may include a pod or container name), connection protocol and direction, cluster node name and identification (ID), and/or the like. (i.e., protocol and network characteristics))
Regarding Claim(s) 5 and 13 Kommula in view of Lin teaches:
The method of claim 1, (Kommula in view of Lin teaches the parent claim above.) wherein the action comprises at least one of: applying a traffic filter, issuing an alert, and issuing a challenge to clients. (Kommula ¶ 117 teaches, any traffic originating from the compromised service of pod 654 may be blocked by the distributed firewall. (i.e., traffic filter))
Regarding Claim(s) 6 and 14 Kommula in view of Lin teaches:
The method of claim 1, (Kommula in view of Lin teaches the parent claim above.) wherein the site is defined by one or more domains. (Kommula ¶ 48 teaches, Although customer sites 11 and public network 4 are illustrated and described primarily as edge networks of service provider network 7, in some examples, one or more of customer sites 11 and public network 4 are tenant networks within data center 10 or another data center. ¶ 133 teaches, the second traffic sessions metrics data includes a number of domain name service requests by a virtual network endpoint of a host device within a period of time.)
Claim(s) 3 and 11 is/are rejected under 35 U.S.C. 103 as being unpatentable over Kommula in view of Lin as applied to claim 1 and 9 above, and further in view of Stefan (US 2024/0143760 A1), hereinafter Stefan.
Regarding Claim(s) 3 Kommula in view of Lin teaches:
The method of claim 1, (Kommula in view of Lin teaches the parent claim above.)
Kommula in view of Lin does not appear to explicitly teach but in related art:
wherein the client signatures are characterized by a closed set of characteristics selected only from the group consisting of: (operating system, user agent information, hardware type. (Stefan ¶ 68 teaches, Server may further receive a device profile from each client, including a client identifier and a set of data characterizing a hardware and/or software configuration of the respective client (e.g., device type, make, model, OS version, various current settings, etc.). Server may then use such information in associating harvested feature values with a specific device type and/or configuration.)
It would have been obvious to one with ordinary skill the art, prior to the applicant's earliest effective filing date, to combine the teachings of Kommula in view of Lin with Stefan, to modify the intelligent firewall policy system of Kommula with the multiple machine learning models of Lin with the client characteristics of Stefan. The motivation to do so constitutes applying a known technique of collecting client data to known devices and/or methods for network security ready for improvement to yield predictable results of gathering attacker information.
Claim(s) 4 and 12 is/are rejected under 35 U.S.C. 103 as being unpatentable over Kommula in view of Lin as applied to claim 1 and 9 above, and further in view of Sharifi Mehr (US 10,812,521 B1), hereinafter Sharifi.
Regarding Claim(s) 4 Kommula in view of Lin teaches:
The method of claim 1, (Kommula in view of Lin teaches the parent claim above.)
Kommula in view of Lin does not appear to explicitly teach but in related art:
where a size of the subset of the plurality of client signatures that triggers the action is configurable. (Sharifi Col. 25-26 Ln. 67 and 1-2 teaches, A security alert can be configured to trigger at different threshold levels (for example, whenever a breach likelihood score exceeds thirty percent).)
It would have been obvious to one with ordinary skill the art, prior to the applicant's earliest effective filing date, to combine the teachings of Kommula in view of Lin with Sharifi, to modify the intelligent firewall policy system of Kommula with the multiple machine learning models of Lin with the adjustable threshold of Sharifi. The motivation to do so, Sharifi Col. 4 Ln. 17-20, helps to not lose the value of otherwise seemingly minor facilitators and low-confidence indicators so as to not miss slow-paced security attacks.
Claim(s) 7 and 15 is/are rejected under 35 U.S.C. 103 as being unpatentable over Kommula in view of Lin as applied to claim 1 and 9 above, and further in view of Xiao(US 2024/0420013 A1), hereinafter Xiao.
Regarding Claim(s) 7 Kommula in view of Lin teaches:
The method of claim 1, (Kommula in view of Lin)
Kommula in view of Lin does not appear to explicitly teach but in related art:
wherein the past traffic patterns used to train at least one of the first and second machine learning models comprise the last 24 hours of traffic. (Xiao ¶ 28 teaches, if the machine learning model is to be trained daily, the data that was served by the machine learning model during the previous day may be utilized as the initial dataset.)
It would have been obvious to one with ordinary skill the art, prior to the applicant's earliest effective filing date, to combine the teachings of Kommula in view of Lin with Xiao, to modify the intelligent firewall policy system of Kommula with the multiple machine learning models of Lin with the machine learning training schedule of Xiao. The motivation to do so, Xiao ¶ 55, to improve its performance, and processing returns to step 506, where a new set of training data is selected, and the process repeats.
Claim(s) 8 and 16 is/are rejected under 35 U.S.C. 103 as being unpatentable over Kommula in view of Lin as applied to claim 1 and 9 above, and further in view of Dash (US 2026/0010570 A1), hereinafter Dash.
Regarding Claim(s) 8 Kommula in view of Lin teaches: The method of claim 1, further comprising: (Kommula in view of Lin teaches the parent claim above.)
Kommula does not appear to explicitly teach but in related art:
merging statistics for a plurality of narrow client fingerprints into a signature. (Dash ¶ 65 teaches, A signature of an operator may include, for example, an identifier for the operator combined with an identification of any parameters referenced by the operator, and may be based on the representation of an operator in hypergraph or in hierarchical state machine (as a collection of tasks and states))
It would have been obvious to one with ordinary skill the art, prior to the applicant's earliest effective filing date, to combine the teachings of Kommula in view of Lin with Dash, to modify the intelligent firewall policy system of Kommula with the multiple machine learning models of Lin with the signature based on a combination of operator data of Dash. The motivation to do so constitutes applying a known of generating a user signature from a combination of data technique to known devices and/or methods of network traffic security ready for improvement to yield predictable results for creating indicators of an attack or suspicious activity.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
US 12,519,814 B2 - A network attack prediction method includes: performing preprocessing, time series modeling and data feature analysis on the network traffic data set; dividing the network traffic data set into a normal traffic data set and an attack traffic data set
THIS ACTION IS MADE FINAL. 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 JACOB BENEDICT KNACKSTEDT whose telephone number is (703)756-5608. The examiner can normally be reached Monday-Friday 8:00 am - 5:00 pm.
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, Linglan Edwards can be reached on (571) 270-5440. 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.
/J.B.K./Examiner, Art Unit 2408
/LINGLAN EDWARDS/Supervisory Patent Examiner, Art Unit 2408
Prosecution Insights