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 .
Information Disclosure Statement
The information disclosure statement (IDS) submitted by applicant dated 07/22/2025 has been considered by the examiner.
Claim Rejections - 35 USC § 103
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 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, 6, 8, 10, 15, 17, 19 is/are rejected under 35 U.S.C. 103 as being unpatentable over Gupta (US 20250373516 A1) in view of Neystadt (US 20260135874 A1).
Regarding claim 1, Gupta teaches a method comprising:
accessing, by a network security system executing in a computer network, network details comprising one or more of: a network scope; a network definition; or an existing security policy associated with the computer network (Para [0063]-[0066]. Para [0096]. Fig. 2. Fig. 5: process 500 may monitor network traffic at one or more network devices connected to a network (block 510). The traffic monitoring device 202 may be configured to extract information from the packets flowing across the network as the network traffic and traffic data at flow level, including source and destination Internet Protocol (IP) addresses.);
accessing, by the network security system, network flow logs comprising metadata that describes network traffic associated with the computer network (Para [0063]-[0066]. Para [0097]. Fig. 2. Fig. 5: the process 500 may identify one or more patterns associated with the network traffic (block 520). In many embodiments, process 500 may analyze traffic patterns or network behavior associated with one or more network devices connected to the network.);
prompting, by the network security system, a machine learning model to (b) generate new network security policies when anomalous network activity is detected (Para [0022]. Para [0078]. Para [0098]-[0100]: When a change is detected in one or more patterns, process 500 can transmit a new policy recommendation (block 530) to address or correct violations in network policies. To do this, the recommendation model 208 sends the machine learning (ML) model outputs to a policy suggestions module.);
receiving, by the network security system from the machine learning model, a new network security policy that addresses anomalous activity detected by the machine learning model (Para [0022]. Para [0078]. Para [0098]-[0100]: When a change is detected in one or more patterns, process 500 can transmit a new policy recommendation (block 530) to address or correct violations in network policies. To do this, the recommendation model 208 sends the machine learning (ML) model outputs to a policy suggestions module.); and
deploying, by the network security system, the new security policy to the computer network without human review or approval of the new security policy (Fig. 5. Para [0100]: the process 500 may dynamically update the at least one network policy based on the one or more pattern changes in the network traffic without transmitting the policy recommendation to a user device.),
wherein the method is performed by at least one device including a hardware processor (Para [0112]- [0119]).
Gupta does not explicitly disclose (perform an action by) machine learning model to (a) identify anomalous network activity based at least in part on the network details and the network flow logs.
Neystadt teaches (perform an action by) machine learning model to (a) identify anomalous network activity based at least in part on the network details and the network flow logs (Claim 1. [0085]: method for Automated Mitigation of Anomalies, or for automatically or semi-automatically mitigating anomalies in an organizational network, comprising: detecting an anomaly using a machine learning model enriched with organizational context.).
Thus it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the invention of Gupta with the teachings of Neystadt to include (perform an action by) machine learning model to (a) identify anomalous network activity based at least in part on the network details and the network flow logs in order to protect the network from abnormal activity.
Regarding claim 6, Gupta in view of Neystadt teaches the method of claim 1, wherein the network flow logs comprise one or more of: timestamps; source Internet Protocol (IP) addresses; or cloud service region identifiers associated with network traffic (Gupta Para [0128]: The network flow data 730 may provide information regarding source and destination IP addresses, timestamps.).
Regarding claim 8, Gupta in view of Neystadt teaches the method of claim 1, wherein the machine learning model is a generative artificial intelligence (GenAI) model (Neystadt Para [0062]: the LLM may include OpenAI's ChatGPT.).
As per claims 10,15 17, the claims claim the non-transitory computer readable media to the method claims 1, 6, 8 above, and they are rejected, at least for the same reasons.
As per claims 19, the claims claim the system to method claim 1 above, and they are rejected, at least for the same reasons.
Claim(s) 2, 11, 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Gupta (US 20250373516 A1) in view of Neystadt (US 20260135874 A1) in view of Hillis (US 20250097198 A1).
Regarding claim 2, Gupta in view of Neystadt teaches the method of claim 1.l
Gupta in view of Neystadt does not explicitly disclose further comprising: inspecting, by a zero trust policy packet routing (ZPR) network layer, a plurality of packets entering the computer network; and storing the network flow logs, by the ZPR network layer, based at least in part on inspecting the plurality of packets.
Hillis teaches inspecting, by a zero trust policy packet routing (ZPR) network layer, a plurality of packets entering the computer network (Para [0066]. Para [0098]: ZPR keeps traffic counts of the traffic that flows under each visa, which it stores in traffic counters that are allocated along with the forwarding tables and at the egress dock.); and
storing the network flow logs, by the ZPR network layer, based at least in part on inspecting the plurality of packets (Para [0066]. Para [0098]: ZPR keeps traffic counts of the traffic that flows under each visa, which it stores in traffic counters that are allocated along with the forwarding tables and at the egress dock. A ZPRnet can store multiple concurrent configurations. Each configuration is associated with a unique configuration ID and a configuration status. Configurations can be changed while the network continues to operate. Packets continue to be transported through the network under the policies of the configuration under which they entered the network At least two configurations can be stored in a ZPRnet concurrently.).
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the invention of Gupta in view of Neystadt with the teachings of Hillis to include further comprising: inspecting, by a zero trust policy packet routing (ZPR) network layer, a plurality of packets entering the computer network; and storing the network flow logs, by the ZPR network layer, based at least in part on inspecting the plurality of packets in order to prevent unauthorized access.
As per claims 11, the claim claiming the non-transitory computer readable media to the method claim 2 above, and they are rejected, at least for the same reasons.
As per claims 20, the claims claiming the system to method claim 2 above, and they are rejected, at least for the same reasons.
Claim(s) 3, 4, 12, 13 is/are rejected under 35 U.S.C. 103 as being unpatentable over Gupta (US 20250373516 A1) in view of Neystadt (US 20260135874 A1) in view of Gupta (2) (US 20070124797 A1).
Regarding claim 3, Gupta in view of Neystadt teaches the method of claim 1.
Gupta in view of Neystadt does not explicitly receiving, by the network security system, an instruction to roll back the new security policy; and responsive to receiving the instruction to roll back the new security policy: performing, by the network security system, one or more of: (a) taking the new security policy offline; or (b) replacing the new security policy with an earlier security policy.
Gupta (2) teaches further comprising:
receiving, by the network security system, an instruction to roll back the new security policy (Claim 15. Claim 16: a process for enforcing policies created from a policy management tool, the process comprising: Rolling back the policy committed in response to reverting to a prior version of a policy.); and
responsive to receiving the instruction to roll back the new security policy: performing, by the network security system, one or more of:
(a) taking the new security policy offline; or
(b) replacing the new security policy with an earlier security policy (Claim 15. Claim 16: a process for enforcing policies created from a policy management tool, the process comprising: Rolling back the policy committed in response to reverting to a prior version of a policy.).
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the invention of Gupta in view of Neystadt with the teachings of Gupta (2) to include receiving, by the network security system, an instruction to roll back the new security policy; and responsive to receiving the instruction to roll back the new security policy: performing, by the network security system, one or more of: (a) taking the new security policy offline; or (b) replacing the new security policy with an earlier security policy in order to maintain a consistent level of cyber hygiene by reverting to a previous version.
Regarding claim 4, Gupta in view of Neystadt in view of Gupta (2) teaches the method of claim 3, further comprising:
uploading, by the network security system, the new security policy into a version control application (Gupta (2) Claim 15. Claim 16. Para [0069]: Locally committed policies in the policy enforcer may also be updated. The new version metapolicy 730 and the update metapolicy 740 combinations provide a rollback process 725 for previously committed policies.);
wherein replacing the new security policy with the earlier security policy comprises:
accessing the earlier security policy from the version control application (Gupta (2) Claim 15. Claim 16: a process for enforcing policies created from a policy management tool, the process comprising: Rolling back the policy committed in response to reverting to a prior version of a policy.); and
deploying the earlier security policy to the computer network (Gupta (2) Claim 15. Claim 16: a process for enforcing policies created from a policy management tool, the process comprising: Rolling back the policy committed in response to reverting to a prior version of a policy.).
As per claims 12, 13, the claims claim the non-transitory computer readable media to the method claims 3, 4 above, and they are rejected, at least for the same reasons.
Claim(s) 5, 14 is/are rejected under 35 U.S.C. 103 as being unpatentable over Gupta (US 20250373516 A1) in view of Neystadt (US 20260135874 A1) in view of Eyada (US 20100071024 A1) in view of Shaw (US 20230209353 A1).
Regarding claim 5, Gupta in view of Neystadt the method of claim 1.
Gupta in view of Neystadt does not explicitly further comprising: determining that network traffic associated with a first subset of the network flow logs has a higher susceptibility to attacks than network traffic associated with a second subset of the network flow logs.
Eyada teaches further comprising:
determining that network traffic associated with a first subset of the network flow logs has a higher susceptibility to attacks than network traffic associated with a second subset of the network flow logs (Para [0033]. Para [0040]. Para [0086]-[0087]: an end-point device or group of endpoint devices having a high level of security (or one that has few security vulnerabilities), while a low security class value may indicate an end-point device or group of endpoint devices having a low level of security (or one that has many security vulnerabilities).).
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the invention of Gupta in view of Neystadt with the teachings of Eyada to include further comprising: determining that network traffic associated with a first subset of the network flow logs has a higher susceptibility to attacks than network traffic associated with a second subset of the network flow logs in order to classify network connections and evaluate potential threats based on risk and impact.
Gupta in view of Neystadt in view of Eyada does not explicitly filtering the network flow logs to include the first subset of the network flow logs without including the second subset of the network flow logs.
Shaw teaches filtering the network flow logs to include the first subset of the network flow logs without including the second subset of the network flow logs (Para [0034]. Para [0046]: The security system of can sort through incoming network traffic at the edge of a 5G network to proactively mitigate cyberattacks. For example, the security system can sort network traffic into categories of traffic types (e.g., user, control, or management traffic), which are further classified by security levels (e.g., high, medium, low).).
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the invention Gupta in view of Neystadt in view of Eyada with the teachings of Shaw to include filtering the network flow logs to include the first subset of the network flow logs without including the second subset of the network flow logs in order to evaluates risk levels by categorizing data flows and prioritizing threats based on severity.
As per claims 14, the claims claiming the non-transitory computer readable media to the method claims 5 above, and they are rejected, at least for the same reasons.
Claim(s) 7, 16 is/are rejected under 35 U.S.C. 103 as being unpatentable over Gupta (US 20250373516 A1) in view of Neystadt (US 20260135874 A1) in view of Degioanni (US 11544124 B1).
Regarding claim 7, Gupta in view of Neystadt teaches the method of claim 1.
Gupta in view of Neystadt does not explicitly disclose wherein the new security policy comprises:(a) a human readable rule that defines anomalous activity; and(b) a definition of an action to perform responsive to detecting the anomalous activity.
Degioanni teaches wherein the new security policy comprises:
(a) a human readable rule that defines anomalous activity (Col 8 lines 60-67: As shown in FIG. 3, each policy rule 156A and 156B may include various definition fields, including rule name, human-readable description, condition for triggering, remedial action to carry out after triggering, and notification text. The condition for triggering may be written in a simplified and human-readable script language.); and
(b) a definition of an action to perform responsive to detecting the anomalous activity (Col 8 lines 60-67: As shown in FIG. 3, each policy rule 156A and 156B may include various definition fields, including rule name, human-readable description, condition for triggering, remedial action to carry out after triggering, and notification text. The condition for triggering may be written in a simplified and human-readable script language.).
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the invention of Gupta in view of Neystadt with the teachings of Degioanni to include wherein the new security policy comprises:(a) a human readable rule that defines anomalous activity; and (b) a definition of an action to perform responsive to detecting the anomalous activity in order to provide common language for security protocols.
As per claims 16, the claims claiming the non-transitory computer readable media to the method claims 7 above, and they are rejected, at least for the same reasons.
Claim(s) 9, 18 is/are rejected under 35 U.S.C. 103 as being unpatentable over Gupta (US 20250373516 A1) in view of Neystadt (US 20260135874 A1) in view of Rund (US 20240414204 A1).
Regarding claim 9, Gupta in view of Neystadt teaches the method of claim 1, wherein the machine learning model is a large language model (LLM) (Neystadt Para [0106]).
Gupta in view of Neystadt does not explicitly disclose wherein prompting the machine learning model to identify anomalous network activity and generate new network security policies comprises: generating a natural language prompt; submitting the natural language prompt.
Rund teaches wherein prompting the machine learning model to identify anomalous network activity and generate new network security policies (Para [0054]- [0055]: the AI user interface includes a natural language processing (NLP) user interface 362. The machine learning engine 352 can analyze the cybersecurity network compliance requirements that are input through the AI user interface 360 and the input data, logs, reports, and so on from the cybersecurity threat protection applications 320 to generate cybersecurity workflows 350 for the SOAR-managed network 312 based on the cybersecurity compliance requirements.) comprises:
generating a natural language prompt (Para [0054]- [0055]: the AI user interface includes a natural language processing (NLP) user interface 362. The machine learning engine 352 can analyze the cybersecurity network compliance requirements that are input through the AI user interface 360 and the input data, logs, reports, and so on from the cybersecurity threat protection applications 320 to generate cybersecurity workflows 350 for the SOAR-managed network 312 based on the cybersecurity compliance requirements.); and
submitting the natural language prompt (Para [0054]- [0055]: the AI user interface includes a natural language processing (NLP) user interface 362. The machine learning engine 352 can analyze the cybersecurity network compliance requirements that are input through the AI user interface 360 and the input data, logs, reports, and so on from the cybersecurity threat protection applications 320 to generate cybersecurity workflows 350 for the SOAR-managed network 312 based on the cybersecurity compliance requirements.).
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the invention of Gupta in view of Neystadt with the teachings of wherein prompting the machine learning model to identify anomalous network activity and generate new network security policies comprises: generating a natural language prompt; submitting the natural language prompt in order to manage cybersecurity network compliance and threat detection data using machine learning.
As per claims 18, the claims claiming the non-transitory computer media readable to the method claims 9 above, and they are rejected, at least for the same reasons.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JUDY BAZNA whose telephone number is (703)756-1258. The examiner can normally be reached Monday - Friday 08:30 AM-05: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, Farid Homayounmehr can be reached at (571) 272-3739. 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.
/JUDY BAZNA/ Examiner, Art Unit 2495
/FARID HOMAYOUNMEHR/Supervisory Patent Examiner, Art Unit 2495
Prosecution Insights