DETAILED ACTION
This Final Office Action is in response to amendment filed on 01/23/2026.
Claims 1-22 remain pending in the application.
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 01/23/2026 have been fully considered but they are not persuasive.
Applicant argued in Pages 1-5, that Burle does not disclose vulnerability path between a cloud environment and external network environment.
Applicant indicated 1) Burle explicitly discloses the lateral movements and the security vulnerability across different objects, where the objects are graphed and the accessible path via e.g. the internet, over which the security vulnerability can propagate from an attack surface (i.e., a publicly exposed (e.g., an internet-exposed) vulnerable computer resource) to other computer resources, as disclosed in [0035], and 2) the instant application in [0047] explicitly discloses “The network analysis may include determining if a cloud (network) object is accessible from an external network (e.g., the Internet)”, emphasis in italic, where external network is associated with internet access. Applicant further indicated that Burle does not explicitly disclose security vulnerability across different objects, i.e. between a computing environment and an external network environment, because elements having public access is different from elements being different from the cloud system and belong to an external network environment. Examiner agrees and relies on Baker to disclose the “external network environment”.
The applicant further stated that “An external network environment is discussed for example in paragraphs 47 and 67 of the instant specification. This term is also well understood in the art to mean "a network not controlled by the organization". See, for example, the Computer Security Resource Center of the National Institute of Standards and Technology (N 1ST) https://csrc.nist.gov/glossary/term/external_network. Therefore, the external network environment is a network which is outside of the control of the organization which controls the cloud computing environment.”
Examiner respectfully disagrees with the above assertion. An external network environment does not exclusively mean a network not controlled by an environment. There is no clear and exclusive definition in the field on how an “external network environment” is defined. Based on the claim limitation, as drafted and given the broadest reasonable interpretations, there is a first object deployed in a cloud computing environment and a second object in an external network environment that is external to the cloud computing environment. There is nowhere in the claim that clarify what “external network environment” entails.
Applicant further stated in Page 6 “Turning to Baker, Baker does not teach that for which it is cited. The Office Action cites Baker as allegedly teaching the claim elements of 1) an external network environment and 2) exposed to a device capable of having a vulnerability enabling a lateral movement path to a second object in the external network environment. Baker does not teach or suggest either limitation. Rather, Baker is directed to ingesting and correlating control-plane events originating from multiple cloud environments for purposes of monitoring and alerting, not to analyzing network connectivity, reachability, or escalation paths with regard to an external network environment.”
Examiner respectfully disagrees. Baker discloses in [0028] “These threats can move back-and-forth from the cloud infrastructure control plane to the host. Threats can also migrate from infrastructure used by a target that is managed by one cloud provider (a first cloud environment) to infrastructure used by the target that is managed by a second cloud provider (a second cloud environment). In some cases, many different cloud environments can be involved. Examples of different cloud environments include Amazon AWS cloud, Microsoft Azure cloud, Google cloud, etc. Private and public/private clouds may also be cloud environments that are part of an attack.”
Applicant further stated in Pages 6-8 “In this regard, like Burle, Baker does not disclose an external network environment as described in paragraphs 47 and 67 of the instant specification. Again, as noted above, this term is also well understood in the art to mean "a network not controlled by the organization". See, for example, the Computer Security Resource Center of the National Institute of Standards and Technology (NIST) https://csrc.nist.gov/glossary/term/external_network. Therefore, the external network environment is a network which is outside of the control of the organization which controls the cloud computing environment. By contrast, in Baker, each cloud environment is a monitored cloud computing environment whose control-plane events are collected, ingested, and evaluated by a centralized monitoring system. Baker does not describe any network that is external to, or not controlled by, the organization operating the monitored cloud environments. Rather, Baker treats all cloud environments as internal managed domains that function as parallel sources of control-plane event data, without identifying any environment as external to another or outside an organizational control boundary…As such, Baker cannot teach or suggest the claim elements for which it is cited, namely, a plurality of network paths between a cloud computing environment and an external network environment, wherein the external network environment is external to the cloud computing environment ... exposed to a device capable of having a vulnerability enabling a lateral movement path to a second object in the external network environment by a network path, and detecting existence of an available lateral movement path to the second object, given that the second object is in the external network environment which Baker does not teach or suggest. In addition, Baker's entire system operates on control-plane event ingestion,
normalization, and rule-based evaluation. As such, Baker does not perform network path reachability, exposure, or lateral-movement analysis via such paths…”
Examiner respectfully disagrees. Applicant relies on how the “external network environment” is understood by the applicant where the “external network environment” cannot be controlled by one organization. Examiner respectfully disagrees as discussed above and examiner asserted that this not an exclusive definition. Baker discloses a monitoring system for detecting attacks that involve lateral movement across hosts that are in two different cloud environments as disclosed in [0071] and illustrated in Figures 6A-E. Examiner asserts that based on the claim limitations, as drafted and based on the broadest reasonable interpretations, the different cloud environments of Baker can be construed as environments that are external from each other and can be mapped to the claim limitations irrespective of whether the multiple cloud environments are controlled or not controlled by one organization.
Examiner recommends further clarification to the claim limitations such that the claimed invention teaches away from the currently cited prior art.
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 for establishing a background for determining obviousness
under 35 U.S.C. 103 are summarized as follows:
Determining the scope and contents of the prior art.
Ascertaining the differences between the prior art and the claims at issue.
Resolving the level of ordinary skill in the pertinent art.
Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claim 1, 2, 4, 5, 9-11-13, 15-16 and 20-21 are rejected under 35 U.S.C. 103 as being unpatentable over Burle et al. (US 20210234889 A1) in view of Baker(US 20200204465 A1).
Regarding claim 1 (Previously Presented), Burle teaches a method for detecting escalation paths in a cloud environment (Abstract Lines 1-10; “A method for securing a networked computer system executing an application includes identifying a vulnerable computer resource in the networked computer system, determining all computer resources in the networked computer system that are accessible from, or are accessed by, the vulnerable computer resource, and prioritizing implementation of a remediation action to secure the vulnerable computer resource if a vulnerability path extends from the vulnerable computer resource to a critical computer resource that contains sensitive information.” [0027] Lines 1-3; “A networked computer system (e.g., a public cloud, a private cloud, or an on-premise system) can provide a platform for executing one or more applications.”, [0043] “providing multi-layered remediation, the solutions described herein, are likely to protect the critical computer resources from breach via the vulnerable traversal paths (e.g., Internet paths) from an attack surface.”), comprising:
detecting a plurality of network paths between a cloud computing environment and an [external] network environment, wherein the [external] network environment is [external] to the cloud computing environment (Burle [0075] “Determining whether any critical computer resources are impacted by the vulnerable computer resource may involve determining if paths (“vulnerability paths”) exist over which the critical computer resources can be reached from the vulnerable computer resource. The reachable critical computer resources may be within the blast radius of the vulnerable resource or may be indirectly accessible via another computer resource within the blast radius. Reachability analysis is used to determine which critical computer resources are reachable and are potentially impacted (i.e., rendered vulnerable over the vulnerability path from the vulnerable resource).”, Figure 8 further illustrates paths and identifying vulnerable paths, bolded lines, as disclosed in [0098], where the paths are between the application server security group 101, i.e. cloud environment, and network environment accessed via internet paths as disclosed in [0035] “…The graph-based reachability analysis can determine accessible paths (e.g., internet or network paths) over which the security vulnerability can propagate from an attack surface (i.e., a publicly exposed (e.g., an internet-exposed) vulnerable computer resource) to other computer resources (such as a database, a storage bucket, or a server) in the networked computer system…”, [0039] “As shown in FIG. 1B, layer 1 of networked computer system 100 may, for example, include an application server security group 101 that can provide narrow access or broad access via the public internet to applications (launched, for example, from application servers (not shown)) to other computer resources (sites) in computer system 100.”, [0043] “By providing multi-layered remediation, the solutions described herein, are likely to protect the critical computer resources from breach via the vulnerable traversal paths (e.g., Internet paths) from an attack surface.”, examiner notes that the cloud environment and network are reasonably interpreted as two entities that are network accessible in the cloud and are separate from each other);
determining that a first object deployed in a cloud computing environment is exposed to [a device capable of having a vulnerability enabling a lateral movement path to a second object in the external] network environment by a network path of the plurality of network paths ([0073] Lines 1-8; “The graph-based reachability analysis may include determining links (i.e. paths) between different computer resources beginning, for example, with a vulnerable computer resource.” [0072] Lines 1-11; “As shown in FIG. 1B, networked computer system 100 includes two vulnerable computer resources ……… as being computer resources that are vulnerable to external attack.” [0074] Lines 12-18; “For example, as shown in FIG. 1B, the vulnerable computer resource-application server security group 101, is attached to four computer resources (i.e., virtual servers 102 (e.g., Amazon's Elastic Compute Cloud (EC2), one or more relational databases 103 (e.g., an open source Postgres RDS relational database.”, [0044] “ The security vulnerability of application server security group 101 may arise, for example, from an “open port 22” (i.e. ) condition on its communications interface. Further, in the example shown in FIG. 1B, object storage service 106 (e.g., an Amazon Simple Storage Service (S3) bucket) may be a computer resource having a security vulnerability because of the public access to the resource.”, [0079, 0098] discloses vulnerability path illustrated in Figure 8 in bold,
Figure 8 illustrates bolded path from the plurality of paths, representing vulnerability as disclosed in [0098]);
inspecting the first object for a cybersecurity object indicating a vulnerability ([0044] “ The security vulnerability of application server security group 101 may arise, for example, from an “open port 22” (i.e. cybersecurity object) condition on its communications interface. Further, in the example shown in FIG. 1B, object storage service 106 (e.g., an Amazon Simple Storage Service (S3) bucket) may be a computer resource having a security vulnerability because of the public access to the resource.”);
detecting the vulnerability on the first object ([0061] Lines 1-12; “Method 200 may include, at step 201, scanning the networked computer system (e.g., networked computer system 100) to identify one or more vulnerable computer resources (e.g., Vulnerable Resource Nos. 1-M 21). The scanning may be performed by commercially-available vulnerability detection and reporting systems..…… that can automatically scan, detect, and report security vulnerabilities.”, Figure 8 illustrates the vulnerability); and
detecting a potential lateral movement path to the second object ([0075] Lines 1-12; “Determining whether any critical computer resources are impacted by the vulnerable computer resource may involve determining if paths (“vulnerability paths”) exist over which the critical computer resources can be reached from the vulnerable computer resource. The reachable critical computer resources may be within the blast radius of the vulnerable resource or may be indirectly accessible via another computer resource within the blast radius. Reachability analysis is used to determine which critical computer resources are reachable and are potentially impacted (i.e., rendered vulnerable over the vulnerability path from the vulnerable resource).”, further illustrated in Figure 8 and [0098]), based on the exposure and the vulnerability ([0075] Lines 9-12; “Reachability analysis is used to determine which critical computer resources are reachable and are potentially impacted (i.e., rendered vulnerable over the vulnerability path from the vulnerable resource).”, further illustrated in Figure 8 and [0098]).
Burle discloses the aforementioned limitations. Burle further discloses in e.g. [0004, 0035, 0039, 0043] and Figures 1B and 8 cloud network environments and vulnerability lateral movement paths, internet paths, which is obvious to conceive of the internet as external network to e.g. 101 group server. However, Burle does not explicitly discloses lateral movement path between network environment and external network environment. Emphasis in italic below
Baker discloses plurality of network paths between a computing environment and an external network environment, wherein the external network environment is external to the cloud computing environment… exposed to a device capable of having a vulnerability enabling a lateral movement path to a second object in the external network environment by a network path, detecting a potential lateral movement path to the second object (Baker [0028] “In more sophisticated attacks, the bad actors present threats that incorporate multiple steps and can traverse the target's infrastructure. These threats can move back-and-forth from the cloud infrastructure control plane to the host. Threats can also migrate from infrastructure used by a target that is managed by one cloud provider (a first cloud environment) to infrastructure used by the target that is managed by a second cloud provider (a second cloud environment). In some cases, many different cloud environments can be involved. Examples of different cloud environments include Amazon AWS cloud, Microsoft Azure cloud, Google cloud, etc. Private and public/private clouds may also be cloud environments that are part of an attack.”, [0061-0066] and Figures 6A-E illustrates “One feature of the system and methods of the present teaching is that it is able to uncover threats and/or activities in one cloud environment that have an impact on threats and/or activities in another… changing access levels anywhere in one environment can potentially open a hole in another environment…an attacker and/or an employee compromising the cloud-based environment 622 by finding credentials that also provide limited access to the other cloud-based environment 624…the control-plane event monitoring systems and methods of the present teaching are capable of detecting attacks that involve lateral movement across hosts that are in two different service provider domains.”, [071] “…As such, the control-pane event monitoring system and method of the present teaching is an important tool to be able to detect these attacks that involve “lateral moves” and activity in a cloud infrastructure that comprises at least two different cloud environments that should be correlated to successfully and/or efficiently detect the attack.”)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Burle to incorporate the teaching of Baker to utilize the above feature, with the motivation of monitor potential lateral movements across different cloud environments, as recognized by (Baker Abstract [0071] ).
Regarding claim 2, Burle in view of Baker teaches the method of claim 1, further comprising:
detecting a permission associated with the first object ([0076] Lines 1-7; “As an example of the reachability analysis consider, a resource-virtual server 102 (e.g., Amazon's Elastic Compute Cloud (EC2)), shown in FIG. 1B. Determining whether any critical computer resources can be impacted via virtual server 102 involves a check of what resources are accessed by virtual server 102, and to what resources virtual server 102 has permission access.” [0075] Lines 1-12; “Reachability analysis is used to determine which critical computer resources are reachable and are potentially impacted (i.e., rendered vulnerable over the vulnerability path from the vulnerable resource).”); and
detecting the potential lateral movement path further based on the detected permission ([0076] Lines 1-7; “As an example of the reachability analysis consider, a resource-virtual server 102 (e.g., Amazon's Elastic Compute Cloud (EC2)), shown in FIG. 1B. Determining whether any critical computer resources can be impacted via virtual server 102 involves a check of what resources are accessed by virtual server 102, and to what resources virtual server 102 has permission access.”).
Regarding claim 4, Burle in view of Baker teaches the method of claim 1, wherein the vulnerability is associated with a software version ([0116] Lines 1-3; “For purposes of generating safe remediation action chains, application 720 may consider “vulnerabilities” to include software vulnerabilities”).
Regarding claim 5, Burle in view of Baker teaches the method of claim 1, further comprising:
detecting sensitive data accessible by any one of: the first object, the second object, and a combination thereof ([0115] Lines 1-5; “Application 720 may generate safe remediation action chains to secure vulnerable computer resources along vulnerability paths in the networked computer system and to protect and safeguard critical computer resources that contain sensitive or highly private data.”).
Regarding claim 11, claim 11 is directed to an apparatus claim that recites a similar limitation as the system of claim 1. Therefore claim 11 is rejected based on the same rational as claim 1 above.
Regarding claim 12, claim 12 is directed to a system claim that recites a similar limitation as the system of claim 1. Therefore claim 12 is rejected based on the same rational as claim 1 above.
Regarding claim 13, claim 13 is directed to a system claim that recites a similar limitation as the system of claim 2. Therefore claim 13 is rejected based on the same rational as claim 2 above.
Regarding claim 15, claim 15 is directed to a system claim that recites a similar limitation as the system of claim 4. Therefore claim 15 is rejected based on the same rational as claim 4 above.
Regarding claim 16, claim 16 is directed to a system claim that recites a similar limitation as the system of claim 5. Therefore claim 16 is rejected based on the same rational as claim 5 above.
Regarding claim 9, Burle in view of Baker teaches the method of claim 1.
However, Burle does not explicitly wherein the second object is deployed in a second cloud computing environment.
Baker teaches wherein the second object is deployed in a second cloud computing environment (Baker [0028] “In more sophisticated attacks, the bad actors present threats that incorporate multiple steps and can traverse the target's infrastructure. These threats can move back-and-forth from the cloud infrastructure control plane to the host. Threats can also migrate from infrastructure used by a target that is managed by one cloud provider (a first cloud environment) to infrastructure used by the target that is managed by a second cloud provider (a second cloud environment). In some cases, many different cloud environments can be involved. Examples of different cloud environments include Amazon AWS cloud, Microsoft Azure cloud, Google cloud, etc. Private and public/private clouds may also be cloud environments that are part of an attack.”, [0061-0066] and Figures 6A-E illustrates “One feature of the system and methods of the present teaching is that it is able to uncover threats and/or activities in one cloud environment that have an impact on threats and/or activities in another… changing access levels anywhere in one environment can potentially open a hole in another environment…an attacker and/or an employee compromising the cloud-based environment 622 by finding credentials that also provide limited access to the other cloud-based environment 624…the control-plane event monitoring systems and methods of the present teaching are capable of detecting attacks that involve lateral movement across hosts that are in two different service provider domains.”, [071] “…As such, the control-pane event monitoring system and method of the present teaching is an important tool to be able to detect these attacks that involve “lateral moves” and activity in a cloud infrastructure that comprises at least two different cloud environments that should be correlated to successfully and/or efficiently detect the attack.”)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Burle to incorporate the teaching of Baker to utilize the above feature, with the motivation of monitor potential lateral movements across different cloud environments, as recognized by (Baker Abstract [0071] ).
Regarding claim 10, Burle in view of Baker teaches the method of claim 9.
However, Burle does not explicitly wherein the second cloud computing environment is deployed on a second cloud computing infrastructure and the cloud computing environment is deployed on a first cloud computing infrastructure.
Baker teaches wherein the second cloud computing environment is deployed on a second cloud computing infrastructure and the cloud computing environment is deployed on a first cloud computing infrastructure (Baker [0028] “In more sophisticated attacks, the bad actors present threats that incorporate multiple steps and can traverse the target's infrastructure. These threats can move back-and-forth from the cloud infrastructure control plane to the host. Threats can also migrate from infrastructure used by a target that is managed by one cloud provider (a first cloud environment) to infrastructure used by the target that is managed by a second cloud provider (a second cloud environment). In some cases, many different cloud environments can be involved. Examples of different cloud environments include Amazon AWS cloud, Microsoft Azure cloud, Google cloud, etc. Private and public/private clouds may also be cloud environments that are part of an attack.”, [0061-0066] and Figures 6A-E illustrates “One feature of the system and methods of the present teaching is that it is able to uncover threats and/or activities in one cloud environment that have an impact on threats and/or activities in another… changing access levels anywhere in one environment can potentially open a hole in another environment…an attacker and/or an employee compromising the cloud-based environment 622 by finding credentials that also provide limited access to the other cloud-based environment 624…the control-plane event monitoring systems and methods of the present teaching are capable of detecting attacks that involve lateral movement across hosts that are in two different service provider domains.”, [071] “…As such, the control-pane event monitoring system and method of the present teaching is an important tool to be able to detect these attacks that involve “lateral moves” and activity in a cloud infrastructure that comprises at least two different cloud environments that should be correlated to successfully and/or efficiently detect the attack.”)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Burle to incorporate the teaching of Baker to utilize the above feature, with the motivation of monitor potential lateral movements across different cloud environments, as recognized by (Baker Abstract [0071] ).
Regarding claim 20, claim 20 is directed to a system claim that recites a similar limitation as the system of claim 9. Therefore claim 20 is rejected based on the same rational as claim 9 above.
Regarding claim 21, claim 21 is directed to a system claim that recites a similar limitation as the system of claim 10. Therefore claim 21 is rejected based on the same rational as claim 10 above.
Claims 3 and 14 are rejected under 35 U.S.C. 103 as being unpatentable over Burle et al. (US 20210234889 A1) in view of Baker as stated in claims 1, 2, 4, 5, 11-13, 15 and 16 above, and further in view of Chari et al. (US 10108803 B2).
Regarding claim 3, Burle in view of Baker teaches the method of claim 1.
However, Burle in view of Baker does not explicitly teach wherein the vulnerability is a known exploit.
Chari teaches wherein the vulnerability is a known exploit (Col 13 Lines 9-16; “Aggregation of information regarding distributed components of the regulated service may include, for example, common vulnerabilities and exposures (CVE) identifiers; Common Vulnerability Scoring System (CVSS) scores, Confidentiality, Integrity, and Availability (CIA) ratings, data flow and control flow of each component; and the like. CVE identifiers provide identification of known data security vulnerabilities and exposures in software packages.”).
Chari (Vulnerability and risk metrics corresponding to each component in the set of components of the regulated service is identified.) is a similar application to Burle. It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified in view of Baker to incorporate the teachings of Chari by incorporating that the vulnerability is a known exploit. This will allow the system to identify known security weaknesses that may allow an attacker to access or control sensitive data located on the clouds or networks.
Regarding claim 14, claim 14 is directed to a system claim that recites a similar limitation as the system of claim 3. Therefore claim 14 is rejected based on the same rational as claim 3 above.
Claims 6 and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Burle et al. (US 20210234889 A1) in view of Baker as stated in claims 1, 2, 4, 5, 11-13, 15 and 16 above, and further in view of Hecht et al. (US 20190260754 A1).
Regarding claim 6, Burle in view of Baker teaches the method of claim 1.
However, Burle does not explicitly wherein the vulnerability is a access permission.
Hecht teaches wherein the vulnerability is a access permission ([0072] Lines 3-23; “In some embodiments, detection system 120 can be configured to determine a network resource sensitivity factor that addresses the sensitivity of particular resources in the network environment that the plurality of network entities are able to access..…… As a non-limiting example, when 50% of the available resources are affected, detection system 120 can assign a value of 5 as the network resource sensitivity factor for the permission. When the permission policy targets all the available resources (e.g., when the network environment is AWS, a permission using a “*” to indicate the acceptable resources), detection system 120 can assign a value of 10 for the permission.”).
Hecht (Systems and methods are provided for automatically discovering and evaluating privileged entities in a network environment.) is a similar application to Burle. It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Burle in view of Baker to incorporate the teachings of Hecht by incorporating that the vulnerability is a access permission. This will allow the permission policy to target all available resources that could present a potential threat.
Regarding claim 17, claim 17 is directed to a system claim that recites a similar limitation as the system of claim 6. Therefore claim 17 is rejected based on the same rational as claim 6 above.
Claims 7 and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Burle et al. (US 20210234889 A1) in view of Baker as stated in claims 1, 2, 4, 5, 11-13, 15 and 16 above, and further in view of Rossman et al. (US 11785051 B1).
Regarding claim 7, Burle in view of Baker teaches the method of claim 1.
However, Burle-Baker does not explicitly wherein the vulnerability is a cloud object configured with a cluster admin role.
Rossman teaches wherein the vulnerability is a cloud object configured with a cluster admin role (Col 4 Lines 54-67; “In doing this, identity ecosystem analyzer 150 can derive groups of users with similar sets of credentials (which can later be visually inspected and named or categorized). For example, users with multiple high-access credentials might be manually labeled “Administrators.” These clusters can be used to guide granting of permissions in the future to new employees, or to identify potential threats and vulnerabilities. To do the latter, for the users in each cluster, identity ecosystem analyzer 150 can cross-reference additional metadata about those users (e.g., from the relational database). For example, there might be a cluster of users with access to financial resources. By cross-referencing metadata about those users’ organizational department(s), identity ecosystem analyzer 150 might identify outlier users in that cluster that do not belong to any of the traditional financial organizational groups.”; Col 1 Lines 66-67 & Col 2 Line 1; “The present disclosure relates to an identity and credential ecosystem to coordinate actions across multiple web services in a cloud computing context.”).
Rossman (Cloud computing identity ecosystem.) is a similar application to Burle. It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Burle in view of Baker to incorporate the teachings of Rossman by incorporating the vulnerability is a cloud object configured with a cluster admin role. By incorporating a group of users clustered together. This allows the system to cross-referencing metadata about those users’ organizational department(s), identifying users in that cluster that do not belong to any of the groups.
Regarding claim 18, claim 18 is directed to a system claim that recites a similar limitation as the system of claim 7. Therefore claim 18 is rejected based on the same rational as claim 7 above.
Claims 8 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Burle et al. (US 20210234889 A1) in view of Baker as stated in claims 1, 2, 4, 5, 11-13, 15 and 16 above, and further in view of Shimony et al. (US 10963583 B1).
Regarding claim 8, Burle in view of Baker teaches the method of claim 1.
However, Burle in view of Baker does not explicitly wherein the vulnerability is a cloud access key on a disk of the first object.
Shimony teaches wherein the vulnerability is a cloud access key on a disk of the first object (Col 6 Lines 41-67 & Col 7 Lines 1-13; “In some embodiments, computing system 130 may be a cloud-based system, such as Dropbox™, Google Docs™, or iCloud™.” “Memory 220 may include one or more storage devices configured to store instructions used by the processor 210 to perform functions related to computing system 130.…….. Memory 220 may include a privileged file system 224 that may be scanned or monitored by privilege escalation monitor 120.……. Privileged file system 224 may be privileged such that access to one or more files within privileged file system 224 is restricted to users or identities that have been granted access. For example, a client identity 110 may be required to provide credentials (e.g., a username, password, security token, encryption key, biometric data, or other security credentials) in order to access one or more files within privileged file system 224. While privileged file system 224 is shown within the same memory 220 as kernel 222, it is to be understood that privileged file system 224 may be included in a separate memory device, which may include, but is not limited to a separate hard drive, a solid state drive, a CD-ROM drive, a peripheral storage device (e.g., an external hard drive, a USB drive, etc.), a database, a network drive, a cloud storage device, or any other storage device.”).
Shimony (Detecting a privileged file operation involving the file system and determining that a target of the path is writable by a non-privileged identity.) is a similar application to Burle. It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Burle in view of Baker to incorporate the teachings of Shimony by incorporating the vulnerability is a cloud access key on a disk of the first object. This will limit and prevent unwanted access to the cloud system.
Regarding claim 19, claim 19 is directed to a system claim that recites a similar limitation as the system of claim 8. Therefore claim 19 is rejected based on the same rational as claim 8 above.
Claim 22 are rejected under 35 U.S.C. 103 as being unpatentable over Burle et al. (US 20210234889 A1) in view of Baker and Ben et. al. (US 20210218770 A1), hereinafter Ben.
Regarding claim 22 (Previously presented), Burle in view of Baker teaches the method of claim 1, further comprising.
Burle-Baker does not explicitly disclose the below limitations.
Ben discloses determining a plurality of reachability parameters for the first object; and generating a representation of the first object in a security graph, the representation including the plurality of reachability parameters stored as an enriched data set (EDS) in the security graph (Ben [0004] “obtaining a graph (security graph) of lateral movements…” illustrates in Figure 2A-D storing data set, i.e. EDS, associated with each node, where each node is represented with 1) [0088] probability of being penetrated and further represented with 2) [0015] payload utility of nodes that are reachable from the node, [0015] “…the estimated loss from penetration is computed as a summation of estimated loss from penetration to each node of the graph, wherein an estimated loss from penetration to a node is computed based on probability of penetration directly to the node and based on payload utility of nodes that are reachable from the node.”, where the utility of nodes that are reachable from the node corresponds to the reachability parameters determined for each node and are associated with other nodes reachable by the node, where such values are stored in order to perform computations related to estimated loss from penetration as disclosed in [0015, 0089-0094).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Burle- Baker to incorporate the teaching of Ben to utilize the above feature, with the motivation of monitoring and analyzing security threats, as recognized by (Ben Abstract ).
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 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 BASSAM A NOAMAN whose telephone number is (571)272-2705. The examiner can normally be reached Monday-Friday 8:30 AM-5:00PM.
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, Eleni A. Shiferaw can be reached at (571) 272-3867. 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.
/BASSAM A NOAMAN/Primary Examiner, Art Unit 2497
Prosecution Insights