DETAILED ACTION
This action is in response to communication filed on 11/25/2025.
Claims 1-20 are pending.
Claims 1, 3, 11, and 13 have been amended.
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, see pages 10-11, filed 11/20/2025, with respect to the rejection(s) of claim(s) 1 and 11 under 35 USC § 102 have been fully considered and are persuasive. Therefore, the rejection has been withdrawn. However, upon further consideration, a new ground(s) of rejection is made in view of Useckas et al. (US 2024/0333756) in view of Mohanty (US 9,692,778).
Claim Objections
The objection presented in the previous office action is withdrawn in view of response filed 11/20/2025.
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 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 of this title, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1-6, 8-16, 18-20 are rejected under 35 U.S.C. 103 as being unpatentable over Useckas et al. (US 2024/0333756) in view of Mohanty (US 9,692,778).
Regarding claim 1, Useckas discloses a method for dynamically placing security controls in a network infrastructure, the method comprising:
wherein the workload is arranged downstream from a network component such that ingress traffic passes through the network component before reaching the workload (Useckas discloses the network architecture with the workload (protected application) downstream from the network component (sensor module using eBPF subsystem) where ingress traffic (IP network flow) passes through the component before teaching the workload; see [0014] “the system 200 of FIG. 2 receives an IP network flow 202 that has, as its destination, an application 220, referred to herein as the “protected application 220.” The IP network flow 202 may be any type of IP network flow, such as any unicast, multicast, or broadcast network flow, an IP network flow using any version of IP (e.g., IPv4 or IPv6), an HTTP flow, an SMTP flow, an IMAP flow, a TCP flow, or a UDP flow” and “The traffic inspection subsystem 206 may capture raw Internet Protocol (IP) packets 208 from the IP network flow 202”);
analyzing the input values to determine one or more security vulnerabilities of the workload (Useckas analyzes the reassembled Layer 7 flows using dynamic contextual rules to identify vulnerabilities and malicious intent, such as SQL injections, XSS, command injections, path traversal, or buffer overflows that could exploit the downstream application. See [0044], for example, if the reassembled Layer 7 flow 212 is an HTTP flow, the dynamic contextual rule engine 214 may apply rules that are specific to the HTTP protocol. These rules may, for example, include checks for SQL injection attacks in URL parameters, cross-site scripting (XSS) in form submissions, or other HTTP-specific anomalies. This analyzes inputs for vulnerabilities tied to the protected workload);
in response to the analysis of the input values, selecting one or more compensating controls that protect the workload from the one or more security vulnerabilities of the workload (Useckas selects protocol-specific dynamic rules as controls based on the analysis, leading to decisions on whether to block (a compensating action) malicious flows. Rules are updated dynamically from the threat intelligence feeds, implying selection responsive to vulnerabilities. See [0058], for example, the sensor module 204 determines whether any blocking rules in the applied rules match the stream (FIG. 1, operation 112). If any blocking rules are determined to match the stream in operation 112, then the sensor module 204 blocks the stream, thereby preventing the stream from being provided (within the filtered Layer 7 flows 218) to the protected application 220 (FIG. 1, operation 114). This select blocking controls in response to vulnerability matches); and
performing instructions in the network component that dynamically placing the one or more compensating controls that are applied to data traffic passing through the network component to the workload (Useckas discloses performing instructions in the network component (eBPF in sensor module) to dynamically place compensating controls (dynamic contextual rules that block/drop traffic) on data traffic to the workload, based on analysis (of reassembled flows) see [0012] “Once the Layer 7 protocol flows (e.g., HTTP, FTP, SMTP) are reassembled, the system may apply dynamic contextual rules to the reassembled flows to determine whether the client communicating with an application being protected has any malicious intent. If the system identifies any such malicious intent, the system blocks further communications from the client, such as by dropping requests, rejecting requests with a custom response, or other means” and [0028-0029] “The dynamic contextual rules 216 are dynamic in the sense that they may change over time…the system 200 may automatically update the dynamic contextual rules 216 based on data such as threat intelligence feeds, updates from a central management server, or cloud-based services that provide information on emerging threats” and [0022] “the traffic inspection subsystem 206 may use technology such as one or more extended Berkeley packet filter (eBPF) subsystems to perform functions such as disassembling the IP network flow 202 into the raw IP packets 208”).
However, the prior art does not explicitly disclose the following:
ingesting a plurality of different types of input values from different sources that represent a workload in a network architecture; and
performing instructions in the network component that dynamically placing, based on the analysis of the input values.
Mohanty in the field of the same endeavor discloses techniques for prioritizing vulnerabilities of an asset in a virtual computing environment by determining a vulnerability score for the asset, based on at least one of a base vulnerability score or a temporal vulnerability score and receiving information about a threat. In particular, Mohanty teaches the following:
ingesting a plurality of different types of input values from different sources that represent a workload in a network architecture, (Mohanty discloses ingesting different types of input values (treat information, vulnerability data, tag information) from different sources (threat intelligence systems, scanners, virtualization ecosystem) that represent a workload (asset/virtual machine in virtual environment) for analysis; see col. 4/lines 24-58; detx 12 “Threat information 208 comes from one or more threat intelligence systems (see FIG. 3). Vulnerability data 210 comes from one or more scanners (see FIG. 3). Tag information 204, 206 comes from one or more tags 202 in the virtualization ecosystem like VMware of the asset 224” and “col. 4/lines 1-23; detx 11 “When an asset (e.g., a virtual machine or a virtual application) is created and deployed in a virtual environment, information about the asset can be written as metadata to one or more tags (see FIGS. 2 and 3). Further information can be written to tags as situations occur. Static tags 104 have information about tag categories, i.e., each tag category could have one or more tags as information about the asset. These static tags 104 could also be referred to as operational tags, in that the static tag 104 specifies aspects of the operation of the asset. Static tag information affects the workload context 102 of the asset. Dynamic tags 106 have information that is subject to change during the lifespan of the asset”) and;
performing instructions in the network component that dynamically placing, based on the analysis of the input values (Mohanty discloses analysis of input values (correlating threats, vulnerabilities, tags) to select compensating controls (remediations like patching or encryption); see col. 10/lines 9-34; detx 29; “A prioritization score is determined for the asset, in an action 414 of FIG. 4. The prioritization score is based on the vulnerability score, the threat score and the contextual score. The vulnerability score, the threat score and the contextual score, and the prioritization score, are specific to the asset, and are specific to a particular vulnerability, e.g. the vulnerability identified by or associated with the CVSS score and/or the CVE ID, in various embodiments…Remediation is applied for the asset, in an action 420. For example, remediation could include updating or patching an operating system, applying a stronger encryption to sensitive data, investigating a data transfer, updating or upgrading equipment, etc.”).
Therefore, it would have been obvious to a person of ordinary skill in the art at the time the invention was effectively filed to modify the prior art with the teaching of Mohanty to incorporate techniques for prioritizing vulnerabilities of an asset in a virtual computing environment. One would have been motivated because Mohanty teaches would predictably enhance workload-specific security by integrating diverse input to tailor compensating controls, thereby improving protection against threats in virtualized environments.
Regarding claim 2, Useckas-Mohanty discloses the method of claim 1, wherein in the step of performing the instructions in the network component that implement the one or more compensating controls, the network component performing the instructions is a data processing unit (DPU), a Berkley packet filter (BPF), and/or an extended BPF (eBPF) capability (see Useckas; [0017]; For example, the sensor module 204 may include a traffic inspection subsystem 204. The traffic inspection subsystem 204 may, for example, use one or more extended Berkeley packet filter (eBPF) subsystems 206).
Regarding claim 3, Useckas discloses the method of claim 1, further comprising:
analyzing the input values to determine an asset criticality of the workload (see Mohanty; col. 4/lines 24-58; detx 12; FIG. 2 is a schematic diagram, showing how threat information 208, scanned vulnerability data 210 and workload context as tags, information 204, 206 for the asset 224 are combined into a contextual correlation, so that a prioritization score 218 is produced. For example, a vulnerability found on a web server facing to internet with a CVSS score of “10” may have a serious impact if exposed to an external threat, as compared to the same vulnerability existing on a web server that is sitting in a LAN (local area network) with an exposure to the same threat but with a low impact); and
in response to the analysis of the input values, selecting the one or more compensating controls based on both the asset criticality and the one or more security vulnerabilities of the workload (see Mohanty; col. 9/lines 10-25; detx 26; a remediation module 326 performs such analysis, and generates a remediation recommendation. For example, a remediation module 326 could respond to a prioritization score 218 reaching a predetermined threshold, and produce a message, a report, an alert or a file, etc. This could be in various formats and include various types of information, such as indicating the correlation of the asset 224, the vulnerability (e.g., as identified by a CVE ID 220), one or more applicable threats, and relevant information from tags 202. Information technology personnel could then perform an appropriate remediation, based on this information).
Regarding claim 4, Useckas-Mohanty discloses the method of claim 1, wherein the input values comprise one or more vulnerability scores and/or one or more asset criticality scores, the vulnerability scores representing a degree to the workload is at risk of compromise due to predefined vulnerability, and the asset criticality scores representing a degree to which a compromise of the workload would impact a predefined goal (see Mohanty; col. 4/lines 24-58; detx 12; FIG. 2 is a schematic diagram, showing how threat information 208, scanned vulnerability data 210 and workload context as tags, information 204, 206 for the asset 224 are combined into a contextual correlation, so that a prioritization score 218 is produced. For example, a vulnerability found on a web server facing to internet with a CVSS score of “10” may have a serious impact if exposed to an external threat, as compared to the same vulnerability existing on a web server that is sitting in a LAN (local area network) with an exposure to the same threat but with a low impact).
Regarding claim 5, Useckas-Mohanty discloses the method of claim 1, further comprising:
receiving updated input values are updates to the input values that represent the workload (see Useckas; [0027]; receiving new incoming raw IP packets 208);
updating, based on the updated input values, the analysis of the input values to determine the one or more security vulnerabilities of the workload (see Useckas; [0028]; the sensor module 204 also includes a dynamic contextual rule engine 214 and dynamic contextual rules 216. The dynamic contextual rules 216 are dynamic in the sense that they may change over time. At any point in time, the dynamic contextual rule engine 214 applies the current version of the dynamic contextual rules 216);
based on the updated analysis, updating the one or more compensating controls that are selected to protect the workload from the one or more security vulnerabilities (see Useckas; [0028]; if a first version of the dynamic contextual rules 216 exists at a first time and the sensor module 204 calls the dynamic contextual rule engine 214 to process the reassembled Layer 7 flows 212 at that time, then the dynamic contextual rule engine 214 will apply the first version of the dynamic contextual rules 216 to those reassembled Layer 7 flows 212); and
updating the instructions performed in the network component that implement the updated one or more compensating controls (see Useckas; [0028]; If the dynamic contextual rules 216 subsequently change (e.g., by adding, deleting, or modifying one or more rules within the dynamic contextual rules 216), thereby creating a second version of the dynamic contextual rules 216 at a second time, and the sensor module 204 calls the dynamic contextual rule engine 214 to process the reassembled Layer 7 flows 212 at that time, then the dynamic contextual rule engine 214 will apply the second version of the dynamic contextual rules 216 to those reassembled Layer 7 flows 212.).
Regarding claim 6, Useckas-Mohanty discloses the method of claim 5, wherein, when updating the analysis of the input values results in a determination to remove a first security vulnerability from the one or more security vulnerabilities, a compensating control corresponding to the first security vulnerability is removed from the one or more compensating controls that are implemented by the instructions performed in the network component (Useckas can “allow” flows if no vulnerabilities are detected after analysis, effectively removing blocking controls for non-malicious traffic. See [0058]; If no blocking rules are determined to match the stream in operation 112, then the sensor module 204, then the sensor module 204 allows the stream to pass (within the filtered Layer 7 flows 218) to the protected application 220. This implies removal of controls when vulnerabilities are not present or resolved in updated analysis).
Regarding claim 8, Useckas-Mohanty discloses the method of claim 1, further comprising: ingesting other input values that represent another workload in the network architecture, wherein the another workload is arranged downstream from another network component such that other ingress traffic passes through the network component before reaching the workload; analyzing the other input values to determine another one or more security vulnerabilities of the another workload; in response to the analysis of the another input values, selecting another one or more compensating controls that protect the another workload from the another one or more security vulnerabilities of the another workload; and performing another instructions in the another network component that implement the another one or more compensating controls that are applied to data traffic passing through the another network component to the workload, wherein the another one or more compensating controls differ from the one or more compensating controls due to differences between the another workload and the workload (Useckas can handle multiple protected applications (workloads) via scalable sensor modules, applying distinct rules based on flow characteristics, leading to tailored blocking. Similar mapping to claim 1 above).
Regarding claim 9, Useckas-Mohanty discloses the method of claim 1, wherein the network component is directly before the workload such that all data traffic to the workload, including east-west data traffic, passes through the network component before reaching the workload (Useckas’s sensor module intercepts all ingress traffic before it reaches the protected application, ensuring comprehensive coverage. See [0032], the sensor module 204 may use the traffic inspection subsystem 206 to capture raw Internet Protocol (IP) packets 208 from the IP network flow 202 (FIG. 1, operation 101)).
Regarding claim 10, Useckas-Mohanty discloses the method of claim 1, further comprising: applying a firewall to the data traffic before the data traffic reaches the network component, the firewall performing one or more firewall functions on the data traffic, and selecting the one or more compensating controls to avoid redundancy with firewall functions performed on the data traffic by the firewall (see Useckas operates alongside or after traditional firewalls, focusing on Layer 7 threats not caught by lower-layer filters, implying non-redundant selection of rules. See [0001-0003], The sensor module 204 may be deployed inline or in a tap/span port configuration, allowing inspection of traffic post-firewall).
Regarding claim(s) 11-12, 15-16 and 18-20, do(es) not teach or further define over the limitation in claim(s) 1-2, 5-6, and 8-10 respectively. Therefore claim(s) 11-12, 15-16 and 18-20, is/are rejected for the same rationale of rejection as set forth in claim(s) 1-2, 5-6, and 8-10 respectively.
Regarding claim(s) 13-14, do(es) not teach or further define over the limitation in claim(s) 3-4 respectively. Therefore claim(s) 13-14 is/are rejected for the same rationale of rejection as set forth in claim(s) 3-4 respectively.
Allowable Subject Matter
Claims 7 and 17 are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
For the reason above, claims 1-20 have been rejected and remain pending.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JIMMY H TRAN whose telephone number is (571)270-5638. The examiner can normally be reached Monday-Friday 9am-5pm PST.
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, Chris Parry can be reached at 571-272-8328. 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.
JIMMY H TRAN
Primary Examiner
Art Unit 2451
/JIMMY H TRAN/Primary Examiner, Art Unit 2451