DETAILED ACTION
Responsive to the Applicant’s reply filed on 07/28/2026, Applicant’s amendments to claims have been entered and respective arguments carefully considered and responded in the following. Claims 11-19 are pending with claims 1, 10, and 11 being in independent form.
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 .
Examiner's Instructions for filing Response to this Office Action
When the Applicant submits amendments regarding the claims in response the Office Action, the Examiner would like Applicant to provide a clean copy of the claims to facilitate the prosecution which otherwise requires extra time in editing the marked-up claims from OCR.
Please submit two sets of claims:
Set #1 as in a typical filing which includes indicators for the status of claim and all marked amendments to the claims; and
Set #2 as an appendix to the Arguments/Remarks for a clean version of the claims which has all the markups removed for entry by the Examiner.
Response to Arguments
The claim amendments and remarks filed by the Applicant on 07/28/2026, have been carefully considered and are responded in the following.
In response to the Applicant arguments, page(s) 1, regarding claim objections for informality, the amendments have resolved the issues. Accordingly, the objections are withdrawn.
In response to the Applicant arguments, page(s) 1, regarding claim rejections under 35 U.S.C. 112(b) because of each reciting a limitation that lacks sufficient antecedent basis, the amendments have resolved the issues. Therefore, the rejections are withdrawn.
Applicant’s arguments, page(s) 8-9 of the Remarks, with regards to claim rejections under 35 U.S.C. § 103 have been considered carefully.
First, Applicant argues the Lut reference with respect to the teaching of how Lut’s escalation path corresponds to the particular network path recited in claim 1. Applicant argues that, “By contrast, the cited escalation path may be based on privilege relationships between cloud objects, including permissions, identities, roles, secrets, APIs, or control relationships, rather than a network path originating at an external network.”
This argument is not persuasive. Lut discloses in the background (par. 0002-0003) that an attacker may be able to gain access to protected cloud accounts, such as an administrator-role account for an online shopping platform, by gaining similar access to an unprotected, external system and, using access keys made accessible by vulnerabilities included in the external system, maneuver through one or more systems of the network environment to ultimately gain administrator access. Evidently, Lut contemplates the problem of a particular network path that may be used by an attacker to maneuver through a series of network connections (or a path) to gain access to protected cloud accounts. Lut further describes the “attack escalation” and the related escalation path wherein attackers may seek to compromise an auxiliary or external system from the compromised system and move laterally within a network to collect sensitive data and compromise more-secure systems. The Office action cites par. 0005-0006 and 0043-0048 of Lut to show the teaching of receiving an escalation path when the privilege escalation in one object allows to access another object connected thereto. It is noted that the escalation path is the network path that allows the act of exploiting a bug, design flaw, or configuration oversight in an operating system or software application in order to gain elevated access to resources that are normally protected from an application or user. Lut uses security graphs to analyze the network path that allows network privilege escalation in one object to access another connected object in network to exploit network vulnerabilities, such as misconfiguration that allows privilege escalation paths to reach a network port. Lut further discloses potential escalation paths of privilege escalations are detected by traversing the security graph 200. An escalation path is determined when there is access to an object hosting sensitive data or resources. See par. 0047. A potential privilege escalation is determined by analyzing the EDSs associated with each cloud object in the graph to determine if privilege escalations can be achieved to access another node, connected thereto. The detection of a potential path is further performed by analyzing reachability parameters, identity, secrets, and risk factors (vulnerabilities) of each encountered object [along] a particular network path. The analysis can start at a source object and end at a destination object, by traversing the graph, searching the graph, and so; par. 0048. As such, Lut discloses “receiving at least one network path to access the first resource, wherein the first resource is deployed in the cloud computing environment and is potentially accessible from an external network which is external to the cloud computing environment via the at least on network path.”
Secondly, the Applicant argues, pages 3-4, that the combination of the cited references does not discloses “actively inspecting the at least one network path utilizing a network access instruction” as recited in claim 1.
In response, the Examiner respectfully disagrees. Lut discloses detecting reachability parameters, which may include a source IP address, a destination IP address, a port number, a security group, and so on. The reachability parameters allow to determine how one object can be reached or can access another object through one or more hops.; par. 0041. As such, using reachability parameters for network analysis is closely related to utilizing a network access instruction. In network engineering, cloud computing, and software development, a "network access instruction" represents any command, configuration, API call, or rule designed to initiate, route, or permit a connection. Lut discloses techniques for detecting reachability parameters and reachability of cloud objects which include using network access instructions can execute successfully or apply to correctly communicating for using a source IP address, a destination IP address, a port number, a security group, and so on. Network access instructions can also be rules and configurations used to control, permit, or block communication to specific logical endpoints (ports) on a computer network, for example, managing or interacting with open ports—which are TCP or UDP endpoints configured to accept incoming data. Therefore, Applicant arguments are not persuasive.
Thirdly, the Applicant argues, at pages 5-7, that the Office Action identifies only analysis of possible reachability and does not identify execution of a network access instruction to test whether the identified path is actually viable.
In response, the Examiner respectfully disagrees. Claim 1 is broadly defined for a method for active inspection of vulnerability exploitation in a cloud computing environment without explicitly include instruction to test whether the identified path is actually viable. It is noted that the features upon which applicant relies (i.e., testing whether the identified path is actually viable) are not recited in the rejected claims. Although the claims are interpreted in light of the specification, limitations from the specification are not read into the claims. See In re Van Geuns, 988 F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 1993).
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries 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.
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.
Claims 1-19 are rejected under 35 U.S.C. 103 as being unpatentable over Luttwak (US 20230123477 A1; hereinafter “Lut”) in view of Narayan (US 20240039927 A1; hereinafter “Nara”).
As per claim 1, Lut teaches a method for active inspection of vulnerability exploitation in a cloud computing environment (Lut, the Abstract: detecting escalation paths in a cloud environment … accessing a security graph representing cloud objects and their connections and analyzing each cloud object to detect an escalation hop from a current cloud object to a next cloud object; par. 0005, 0019, and 0054: a typical cloud environment may include many cloud objects that participate in … service of an application wherein there are a number of vulnerable points which can be exploited by an attacker), comprising:
inspecting a first resource to detect a cybersecurity vulnerability (Lut, par. 0060-0062: a vulnerability check is for inspecting a first resource, which may be a cloud object. For vulnerability check, it is determined a cloud object is found to have a validated (known) vulnerability and a reachability parameter);
receiving at least one network path to access the first resource, wherein the first resource is deployed in the cloud computing environment and is potentially accessible from an external network which is external to the cloud computing environment via the at least one network path (Lut, par. 0005-0006 and 0043-0048: receiving an escalation path when privilege escalation in one object allows to access another object connected thereto; misconfiguration that allows privilege escalation paths; par. 0019-0020: Privilege escalation is the act of exploiting a bug, design flaw, or configuration oversight in an operating system or software application);
actively inspecting the at least one network path utilizing a network access instruction (Lut, par. 0010-0011: marking the security graph with each identified escalation path in the security graph is actively inspecting the at least one network path, wherein an escalation path is a collection of escalation hops from a source cloud object to a destination cloud object; par. 0041: determining that one object can be reached or can access another object through one or more hops. For example, an object 210-4 (gateway) is currently active, and is connected to an object 210-5 (VM) via the port 8080, using the HTTP protocol);
generating a trigger instruction, based on at least one predetermined triggering instruction, wherein the at least one predetermined triggering instruction is configured to trigger the cybersecurity vulnerability (Lut, par. 0054: traversing the security graph and analyzing each encounter node (object) in the graph to determine if any risk factors can be exploited to reach another cloud object. It is further determined if a reached object in the path holds, contains, or provides access to sensitive information that can harm the organization).
However, Lut does not disclose initiating the generated trigger instruction over the at least one network path, in response to determining that the first resource is accessible from the external network. This aspect of the claim is identified as a further difference.
In a related art, Nara teaches:
initiating the generated trigger instruction over the at least one network path, in response to determining that the first resource is accessible from the external network (Nara, par. 0021-0022: a trigger from the policy author 101; par. 0024-0025: running a cloud policy misconfiguration detection model, which triggers instructions that allow the cloud policy scan engine 104 to communicate the cloud policy misconfigurations 123 to the incident management system 106 and the resource relationship engine 108. Nara discloses generating misconfigurations by software instructions, when triggered by a cloud policy misconfiguration, implementing above a threshold probability for detecting cloud policy misconfigurations from cloud policy logs).
Lut and Nara are analogous art to the claimed invention, because they are in a similar field of endeavor in improving analysis of network vulnerability as the claimed invention. Thus, it would have been obvious to one of ordinary in the art, before the effective filing date of the claimed invention, to combine them and to modify Lut’s system with Nara’s teachings implementing misconfigurations in response to receiveing the cloud policy misconfigurations. For this combination, the motivation would have been to improve the level of security with a known vulnerability.
As per claim 2, the references as combined above teach the method of claim 1, further comprising:
selecting the at least one predetermined triggering instruction from a plurality of predetermined triggering instructions, each predetermined triggering instruction configured to trigger the cybersecurity vulnerability (Nara, par. 0036: performs a graph structure analysis of all possible attack chains via these misconfigurations to identify possible paths through resources for malicious attacks. In some embodiments, cycles of attack chain paths are avoided because each resource in an attack chain has a subsequent attack stage to prior resources, thus an attack chain can have length at most the number of attack stages in a corresponding attack stage framework; herein visiting and revisiting is for selecting; par. 0068: select the top-N adjacent resources according to heuristics for ranking resources).
As per claim 3, the references as combined above teach the method of claim 1, further comprising:
detecting a result of executing the generated trigger instruction, wherein the trigger instruction is configured to generate a predetermined outcome (Lut, par. 0009-0010: detect an escalation-hop from a current cloud object to a next cloud object; par. 0047-0050: potential escalation paths of privilege escalations are detected by traversing the security graph 200; par. 0068-0070: At S360, detected escalation paths are reported).
As per claim 4, the references as combined above teach the method of claim 3, further comprising:
detecting the result over the at least one network path (Nara, par. 0014: the attack chain analyzer logs and generates diagnostics for attack par. 0068-0070: At S360, detected escalation paths are reported).
As per claim 5, the references as combined above teach the method of claim 3, further comprising:
determining that the cybersecurity vulnerability is triggered, in response to detecting the predetermined outcome from the first resource (Lut, par. 0009-0010: a security graph representing cloud objects…. to detect an escalation-hop from a current cloud object to a next cloud object; par. 0047-0050: potential escalation paths).
As per claim 6, the references as combined above teach the method of claim 1, further comprising:
generating the at least one trigger instruction to include a remote code execution instruction (Lut, par. 0031-0033: a remote cloud environment; the graph database stores graph-related data features of one or more types or formats, including, without limitation, raw data, graphs, graph edges, graph vertices, graph schemas, and the like, as well as any combination thereof, including those types or formats description).
As per claim 7, the references as combined above teach the method of claim 1, further comprising:
querying a security database to detect a vulnerability associated with the first resource, wherein the security database includes a representation of the first resource connected to a representation of the vulnerability, and wherein the security database further includes a representation of the cloud computing environment (Lut, par. 0068-0070: querying the security graphs, once the detected paths are marked thereto. searching the graph, analyzing different sections of the graph in parallel, and so on.); and
generating the at least one network path based on a result of querying the security database (Lut, par. 0044-0049: determining an escalation path when there is access to an object hosting sensitive data or resources; generating network path; potential escalation paths of privilege escalations are detected by traversing the security graph 200. An escalation path is when privilege escalation in one object allows to access another object connected thereto).
As per claim 8, the references as combined above teach the method of claim 7, further comprising:
updating the security database based on an outcome of triggering the cybersecurity vulnerability (Lut, par. 0047-0050: the security graph 200… start at a source object and end at a destination object, by traversing the graph, searching the graph, and so on as a way of updating; par. 0065-0066: updating one or more data features to include descriptions of the escalation paths identified at S310).
As per claim 9, the references as combined above teach the method of claim 7, further comprising:
querying the security database to detect a representation of a second resource connected to the representation of the first resource (Lut, par. 0035-0039: security graph 200 describing … escalation paths in a cloud environment; par. 0068-0070: querying the security graphs, once the detected paths are marked thereto. searching the graph, analyzing different sections of the graph in parallel, and so on);
generating a network path to access the second resource (Lut, par. 0064-0066: each escalation path is recorded and ranked based on severity. The ranking may be based on the type of objects in the path being exposited, the type of data that can be accessed); and
initiating active inspection of the second resource over the generated network path (Lut, par. 0058-0060: vulnerability check; par. 0067-0070: analyzing and checking, which are active inspection of vulnerability exploitation … reporting… escalation paths can be obtained by querying the security graphs).
Regarding claims 10 and 11, they are like claim 1 in view of the inventive features recited, respectively; and thus, the claims are rejected for the same reasons discussed above.
Regarding claims 12-19, they are like claims 2-9 and thus, the claims 12-19 are rejected for the same reasons discussed in claims 2-9.
Conclusion
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 extension fee 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 Don Zhao whose telephone number is (571)272-9953. The examiner can normally be reached on 9 am to 5 pm Monday thru Friday.
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, Carl Colin can be reached on 571-272-3862. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/Don G Zhao/
Examiner, Art Unit 2493
09/18/2026
Prosecution Insights