DETAILED ACTION
This Final Office Action is in response to amendment filed on 01/09/2026. Claims 1-2, 4, 6-7, 9-11, 14-20. Claim 5 has been canceled. Claim 21 has been newly added. Claims 1-4 and 6-21 filed on 01/09/2026 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 .
The drawings filed on 05/30/2024 are accepted.
Response to Amendment
Applicant’s claims amendments has overcome the claims USC 112 rejections and claims objections previously set forth in the Non-Final Office Action mailed on 09/12/2025.
Response to Arguments
Applicant stated in Pages 10-11 “Applicant respectfully submits that claim 1 is patentable over Luttwak and Burle, alone or in combination. For example, Luttwak and Burle, taken alone or in combination, fail to teach or suggest the features of "determine a first level of uniqueness of a configuration of the first asset in comparison to configurations of other assets in the group of assets" and "determine the first asset is a critical asset based on the first level of uniqueness being higher than a threshold… For instance, Luttwak fails to teach or suggest the combined claim 1 features of
programming instructions structured to cause a processor to:
• "determine a first level of uniqueness of a configuration of the first asset in
comparison to configurations of other assets in the group of assets" and
• "determine the first asset is a critical asset based on the first level of uniqueness being higher than a threshold."
( emphasis added)" as recited in presently amended claim 1… In claim 1, a critical asset is determined based on that asset having a level of uniqueness in
comparison to other assets within a group that is higher than a threshold. In contrast, Luttwak merely states that cloud objects can be different types. See, e.g., [0049]. However, Luttwak is silent with respect to determining a first asset is a critical asset based on its level of uniqueness being higher than a threshold where the level of uniqueness is determined in comparison to other assets of a group of assets, as in claim 1… Accordingly, for at least these reasons, Applicant respectfully asserts that Luttwak and Burle, alone or in combination, fail to teach or suggest each and every feature of claim 1.”
With respect to the limitation “determine a first level of uniqueness of a configuration of the first asset in comparison to configurations of other assets in the group of assets”, examiner respectfully disagrees and asserts that LUTTWAK discloses this limitation. Particularly, LUTTWAK discloses in [0041-0043] each object is being analyzed for the object’s parameters, risk factors and eventually associating a score with each object, where these risk and vulnerability analysis with each object/asset is construed as a level of uniqueness. The level of uniqueness allows for broader interpretations. The analysis of each object/asset to determine certain characteristics/properties/attributes of an object that is reflected by each object’s parameters and risk factors and score and distinguish each object from another object can be construed as a level of uniqueness compared to other level of uniqueness in other objects/assets, LUTTWAK discloses in [0066] determining that the first risk factor/score (level of uniqueness) of one object is higher than the other risk factor (level of uniqueness) of other object/asset and accordingly perform ranking of escalation path based on severity scores for each object along the paths, where the high severity score associated with the object along the path the critical the object is.
With respect to the limitation “…critical asset based on the first level of uniqueness being higher than a threshold”, the argument is considered moot, since a new prior art is relied upon to disclose this limitation. Please see detailed rejection below.
With respect to the arguments pertaining claims 9 and 17 in Pages 12-14, the applicant’s arguments are considered moot in light of a newly found and relied upon prior art. Please see detailed rejection below.
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, 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-4, 8, 11-14, 18-20 are rejected under 35 U.S.C. 103 as being unpatentable over LUTTWAK (US 20230123477 A1), hereinafter LUTTWAK in view of Burle et. al. (US 20210234889 A1), hereinafter Burle and Hamdi (US 20220109689 A1), hereinafter Hamdi.
Regarding claim 1, LUTTWAK teaches a system comprising: a processor; and a memory comprising programming instructions structured to cause the processor (LUTTWAK [0069] Figure 1 cybersecurity system 150) to:
receive configuration data associated with a first asset of a group of assets (LUTTWAK [0052] “At S310, a security graph stored in a graph database is accessed. As described hereinabove, a security graph lists all cloud objects and their connections in the cloud environment. Further, each node (representing an object) in the security graph lists the EDSs for the object. An EDS may include object properties, readability parameters, risk factors, and so on. Detailed description of the EDSs are discussed in greater detail above. In an embodiment, the graph may designate a seed (or source) node.”, objects corresponds to assets, consistent with description of assets in the instant application in [0034]),
determine a first level of uniqueness of a configuration of the first asset in comparison to configurations of other assets in the group of assets, determine the first asset is a critical asset based on the first level of uniqueness [[being higher than a threshold]] (LUTTWAK [0042] “The risk factors are generated by performing risk analysis on each cloud object 220. A risk factor can be represented using a score, description, or combination thereof. According to the disclosed embodiments, the risk analysis may include vulnerability analysis to detect any known or unknown vulnerabilities identified in the object.”, [0053] “At S320, the accessed security graph is analyzed to identify potential escalation paths. An escalation path is when privilege escalation in one object allows to access another object connected thereto, where a connection may be data, network, or control connection. That is, an escalation path is a combination of privilege escalations from a source object to a destination object in the security graph. In an embodiment, an escalation path is determined when there is access to an object hosting sensitive data or resources.”. where the result of the analysis is a generated risk factor/score and identifying associated escalation path in an object/asset allows to access another object/asset holding sensitive/critical data or resources, where [0041-0043] discloses determining parameters and risk factors/scores of each object/asset, which is interpreted as a first level of uniqueness for one first asset in comparison to the parameters and risk factors/scores of other objects/assets, where [0066] discloses determining that the first risk factor/score (level of uniqueness) of one object is higher than the other risk factor (level of uniqueness) of other object/asset and accordingly perform ranking of escalation path based on severity scores for each object along the paths, where the high severity score associated with the object along the path the critical the object is), [[and]]
responsive to determining the first asset is a critical asset, determine a level of risk with respect to the first asset and a potential cyberattack[[;]], identify a security vulnerability of the first asset based on the level of risk and the configuration data (LUTTWAK [0042] “The risk factors are generated by performing risk analysis on each cloud object 220. A risk factor can be represented using a score, description, or combination thereof…the risk analysis may include vulnerability analysis to detect any known or unknown vulnerabilities identified in the object.”, [0065] “[0065] At S330, any escalation path detected or identified at S320 is recorded. Escalation paths may be recorded by creating or updating one or more data features to include descriptions of the escalation paths identified at S310. This may include marking nodes (cloud objects) that are part escalation paths, listing all paths and their objects, updating an object's EDS to note that such object is part of an escalation path.”, [0066] “At S340, optionally, each recorded escalation path is 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, how objects in a detected path can be reached (e.g., for external network or internal network), who can access objects in a detected path (e.g., any public access on organization access), the type of destination object of a path (i.e., if it is a designated object or a “sensitive” object), and so on. Such parameters can be weighted to compute a severity score for each detected escalation path. In an embodiment, the rank is determined based on a probability that a detected escalation path indeed causes privilege escalation. To this end, the escalation paths detection may be operated in two different modes: deterministic (where the probability of detection is high) and undeterministic (where the probability of detection is low).”).
LUTTWAK discloses in the background “[0004] Various solutions may be employed to identify potential attack vectors, by which attackers may execute such movements, and restrict the access of such attackers, such as by remedying vulnerabilities leading to potential escalation paths, and otherwise mitigate potential damage.” further discloses mitigating solutions in [0006], and further discloses reports generated and displayed to the user as disclosed in [0050, 0068] and Figure 3A S360, which would make it obvious for one of ordinary skill in the art to conceive of the user performing mitigating actions in response, to the report or interpreting the generated report displayed to the user as a mitigating action. However, LUTTWAK does not explicitly disclose performing mitigating action in the body of the description.
Burle discloses perform a remedial action to remove the security vulnerability (Burle [0007] “a method for securing the networked computer system hosting an application includes identifying a vulnerable computer resource in the networked computer system and identifying a remediation action. The method further includes determining whether the remediation action is an unsafe remediation action that reduces availability of the application on the networked computer system or is a safe remediation action that does not reduce availability of the application on the networked computer system is, and implementing the remediation action to secure the networked computer system if it is the safe remediation action.”).
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 LUTTWAK to incorporate the teaching of Burle to utilize the above feature, with the motivation of securing the vulnerable computer resource as a safe remediation action that does not impact availability of the application executing on the networked computer system., as recognized by (Burle Abstract ).
LUTTWAK in view of Burle does not explicitly disclose the below limitation. Emphasis in italic.
Hamdi discloses determine the first asset is a critical asset based on the first level of uniqueness being higher than a threshold (Hamdi [0076] “…the risk score management module 306 can determine, for each monitored asset, a respective risk score based on the respective current context. The risk score management module 306 can assign a value to each attribute or characteristic of the predefined list of attributes or characteristics defining the context of the context of the asset. The risk score management module 306 can determine the asset risk score as a weighted sum of the values assigned to attributes or characteristics of the predefined list of attributes. ”, [0077] “ The risk mitigation module 208 can compare the risk score to a threshold value and decide based on the comparison whether to take any action or what actions or measures, if any, to take…the risk mitigation module 208 can take such action responsive to the geolocation of the asset or a user thereof, an asset connection to a non-secure network, or a suspicious attempt to change (or a change of) a configuration parameter of the asset, a suspicious activity associated with the asset or a combination of both.”).
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 LUTTWAK in view of Burle to incorporate the teaching of Hamdi to utilize the above feature, with the motivation of limiting access to sensitive data, as recognized by (Hamdi [0077]).
Regarding claim 11, claim 11 recites similar limitations to claim 1, therefore rejected with the same rationale and motivation applied to claim 1.
Regarding claim 18, claim 18 recites similar limitations to claim 1, therefore rejected with the same rationale and motivation applied to claim 1.
Regarding claim 2, LUTTWAK in view of Burle and Hamdi teaches the system of claim 1, wherein the programming instructions are further structured to cause the processor to: receive attack data; and filter the attack data based on the first asset, resulting in the attack path data (LUTTWAK Figure 3A illustrates accessing security graph data, i.e. attack data, for object/asset, as disclosed in [0052] “…the security graph lists the EDSs for the object. An EDS may include object properties, readability parameters, risk factors, and so on.”, analyze security graph, record and rank escalation paths, i.e. attack path data, as disclosed in [0053-0054, 0065] and further in [0066], where the security graph is selected for each object/asset, i.e. filter object properties and data disclosed above in [0052] in order to determine the escalation hops from the source to destination object, where the interpretation of the attack path is consistent with the instant application interpretation in [0085]),
wherein the security vulnerability is identified based on the level of risk, the configuration data, and the attack path data.(LUTTWAK [0042] “The risk factors are generated by performing risk analysis on each cloud object 220. A risk factor can be represented using a score, description, or combination thereof…the risk analysis may include vulnerability analysis to detect any known or unknown vulnerabilities identified in the object.”, [0065] “[0065] At S330, any escalation path detected or identified at S320 is recorded. Escalation paths may be recorded by creating or updating one or more data features to include descriptions of the escalation paths identified at S310. This may include marking nodes (cloud objects) that are part escalation paths, listing all paths and their objects, updating an object's EDS to note that such object is part of an escalation path.”, [0048] “ The detection of a potential path is further performed by analyzing reachability parameters, identity, secrets, and risk factors (vulnerabilities) of each encountered object. ”, [0060] “[0060] For vulnerability check, it is determined a cloud object is found to have a validated (known) vulnerability and a reachability parameter to a different cloud object. For example, a compute object with a configured network access validated vulnerability provides access to a VM.”, [0066] “At S340, optionally, each recorded escalation path is 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, how objects in a detected path can be reached (e.g., for external network or internal network), who can access objects in a detected path (e.g., any public access on organization access), the type of destination object of a path (i.e., if it is a designated object or a “sensitive” object), and so on. Such parameters can be weighted to compute a severity score for each detected escalation path. In an embodiment, the rank is determined based on a probability that a detected escalation path indeed causes privilege escalation. To this end, the escalation paths detection may be operated in two different modes: deterministic (where the probability of detection is high) and undeterministic (where the probability of detection is low).”, where vulnerability/severity is identified by escalation paths, score or risk factors and data/parameters, etc.).
Regarding claim 3, LUTTWAK in view of Burle and Hamdi teaches the system of claim 2, wherein the programming instructions are further structured to cause the processor to receive the attack path data responsive to the first asset being determined as a critical asset (LUTTWAK [0054] “In an embodiment, S320 includes 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. This would allow to rank detected escalation paths according to the severity of the exposed data. The analysis of cloud objects may include analyzing EDS associated with each object in the security graph. In an example embodiment, the analysis can start at a designated source security object, and end at a destination object.”, [0065] “At S330, any escalation path detected or identified at S320 is recorded. Escalation paths may be recorded by creating or updating one or more data features to include descriptions of the escalation paths identified at S310. This may include marking nodes (cloud objects) that are part escalation paths, listing all paths and their objects, updating an object's EDS to note that such object is part of an escalation path.”).
Regarding claim 4, LUTTWAK in view of Burle and Hamdi teaches the system of claim 1, wherein the configuration data comprises configuration data of the first asset and, to generate the analysis result, the programming instructions are further structured to cause the processor to: generate an asset analysis result based on an analysis of the configuration data of the first asset (LUTTWAK [0039, 0048, 0052] discloses the object property data, i.e. configuration data, which is part of the security graph in Figure 3A S310 being accessed/received and analyzed for the object),
wherein the first level of uniqueness is determined based on the asset analysis result (LUTTWAK [0042] “The risk factors are generated by performing risk analysis on each cloud object 220. A risk factor can be represented using a score, description, or combination thereof. According to the disclosed embodiments, the risk analysis may include vulnerability analysis to detect any known or unknown vulnerabilities identified in the object.”, [0053] “At S320, the accessed security graph is analyzed to identify potential escalation paths).
Regarding claim 8, LUTTWAK in view of Burle and Hamdi teaches the system of claim 1, wherein to determine the first asset is a critical asset, the programming instructions are further structured to cause the processor to: determine a criticality score of the first asset based on the analysis result; and determine the criticality score satisfies a critical asset criterion (LUTTWAK [0066] and [0042] “The risk factors are generated by performing risk analysis on each cloud object 220. A risk factor can be represented using a score, description, or combination thereof. According to the disclosed embodiments, the risk analysis may include vulnerability analysis to detect any known or unknown vulnerabilities identified in the object.”, [0043] “The risk analysis may further include identity analysis to detect any misconfiguration or other issues of an identity in an object (i.e. critical asset criterion).”, [0035, 0044-0046] further discloses different criteria for determining risk factors/scores).
Regarding claim 12, LUTTWAK in view of Burle and Hamdi teaches the method of claim 11, further comprising: receiving attack path data associated with a potential cyberattack corresponding to the first asset; and determining a level of risk with respect to the first asset and the potential cyberattack, wherein the security vulnerability is identified based on the level of risk (LUTTWAK [0054] “In an embodiment, S320 includes 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. This would allow to rank detected escalation paths according to the severity of the exposed data. The analysis of cloud objects may include analyzing EDS associated with each object in the security graph. In an example embodiment, the analysis can start at a designated source security object, and end at a destination object.”, [0065] “At S330, any escalation path detected or identified at S320 is recorded. Escalation paths may be recorded by creating or updating one or more data features to include descriptions of the escalation paths identified at S310. This may include marking nodes (cloud objects) that are part escalation paths, listing all paths and their objects, updating an object's EDS to note that such object is part of an escalation path.”, [0042] “The risk factors are generated by performing risk analysis on each cloud object 220. A risk factor can be represented using a score, description, or combination thereof. According to the disclosed embodiments, the risk analysis may include vulnerability analysis to detect any known or unknown vulnerabilities identified in the object.”).
Regarding claim 13, LUTTWAK in view of Burle and Hamdi teaches the method of claim 11, further comprising: scanning a computing environment comprising the first asset; and detecting a change in the computing environment based on said scanning (LUTTWAK [0054] “In an embodiment, S320 includes 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. This would allow to rank detected escalation paths according to the severity of the exposed data. The analysis of cloud objects may include analyzing EDS associated with each object in the security graph. In an example embodiment, the analysis can start at a designated source security object, and end at a destination object.”, [0065] “At S330, any escalation path detected or identified at S320 is recorded. Escalation paths may be recorded by creating or updating one or more data features to include descriptions of the escalation paths identified at S310. This may include marking nodes (cloud objects) that are part escalation paths, listing all paths and their objects, updating an object's EDS to note that such object is part of an escalation path.”, [0065] “…updating an object's EDS to note that such object is part of an escalation path.”, Figure 3A illustrates scanning/analyzing all objects).
Regarding claim 14, LUTTWAK in view of Burle and Hamdi teaches the method of claim 11, wherein said generating the analysis result comprises: generating an asset analysis result based on an analysis of the configuration data; measuring a level of uniqueness between the first asset and a second asset, the first and second assets in a same group of assets; or generating an environment analysis result based on an analysis of the configuration data (LUTTWAK [0042] “The risk factors are generated by performing risk analysis on each cloud object 220. A risk factor can be represented using a score, description, or combination thereof. According to the disclosed embodiments, the risk analysis may include vulnerability analysis to detect any known or unknown vulnerabilities identified in the object.”, [0053] “At S320, the accessed security graph is analyzed to identify potential escalation paths. An escalation path is when privilege escalation in one object allows to access another object connected thereto, where a connection may be data, network, or control connection. That is, an escalation path is a combination of privilege escalations from a source object to a destination object in the security graph. In an embodiment, an escalation path is determined when there is access to an object hosting sensitive data or resources.”. where the result of the analysis is a generated risk factor/score and identifying escalation path in an object/asset allows to access another object/asset holding sensitive/critical data or resources, where the escalation path across all objects in the security graph).
Regarding claim 19, LUTTWAK in view of Burle and Hamdi teaches the computer-readable storage medium of claim 18, wherein said performing the prioritization action comprises: identifying a security vulnerability of the first asset based on the analysis result (LUTTWAK [0042] “The risk factors are generated by performing risk analysis on each cloud object 220. A risk factor can be represented using a score, description, or combination thereof…the risk analysis may include vulnerability analysis to detect any known or unknown vulnerabilities identified in the object.”, [0066] “At S340, optionally, each recorded escalation path is 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, how objects in a detected path can be reached (e.g., for external network or internal network), who can access objects in a detected path (e.g., any public access on organization access), the type of destination object of a path (i.e., if it is a designated object or a “sensitive” object), and so on. Such parameters can be weighted to compute a severity score for each detected escalation path. In an embodiment, the rank is determined based on a probability that a detected escalation path indeed causes privilege escalation. To this end, the escalation paths detection may be operated in two different modes: deterministic (where the probability of detection is high) and undeterministic (where the probability of detection is low).”).
LUTTWAK discloses in the background “[0004] Various solutions may be employed to identify potential attack vectors, by which attackers may execute such movements, and restrict the access of such attackers, such as by remedying vulnerabilities leading to potential escalation paths, and otherwise mitigate potential damage.” further discloses mitigating solutions in [0006], and further discloses reports generated and displayed to the user as disclosed in [0050, 0068] and Figure 3A S360, which would make it obvious for one of ordinary skill in the art to conceive of the user performing mitigating actions in response, to the report or interpreting the generated report displayed to the user as a mitigating action. However, LUTTWAK does not explicitly disclose performing mitigating action in the body of the description.
Burle discloses perform a remedial action to remove the security vulnerability (Burle [0007] “a method for securing the networked computer system hosting an application includes identifying a vulnerable computer resource in the networked computer system and identifying a remediation action. The method further includes determining whether the remediation action is an unsafe remediation action that reduces availability of the application on the networked computer system or is a safe remediation action that does not reduce availability of the application on the networked computer system is, and implementing the remediation action to secure the networked computer system if it is the safe remediation action.”).
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 LUTTWAK to incorporate the teaching of Burle to utilize the above feature, with the motivation of securing the vulnerable computer resource as a safe remediation action that does not impact availability of the application executing on the networked computer system., as recognized by (Burle Abstract ).
Regarding claim 20, LUTTWAK in view of Burle and Hamdi teaches the method of claim 19.
LUTTWAK does not disclose the below limitation.
Burle discloses wherein the group of assets are assets within the same computing environment and said performing the prioritization action further comprises:
prioritizing the remedial action over another remedial action corresponding to a second asset of the group of assets (Burle [0010] “The computer system can also include a remediation implementer prioritizing implementation of a remediation action to secure the computer resource when a vulnerability path extends from a vulnerable computer resource (i.e. second asset) to the critical computer resource (i.e. first asset).”).
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 LUTTWAK to incorporate the teaching of Burle to utilize the above feature, with the motivation of securing the vulnerable computer resource as a safe remediation action that does not impact availability of the application executing on the networked computer system., as recognized by (Burle Abstract ).
Claims 6 and 15 are rejected under 35 U.S.C. 103 as being unpatentable over LUTTWAK (US 20230123477 A1), hereinafter LUTTWAK in view of Burle et. al. (US 20210234889 A1), hereinafter Burle, Hamdi (US 20220109689 A1), hereinafter Hamdi and MAOR (US 20210203684 A1), hereinafter MAOR.
Regarding claim 6, LUTTWAK in view of Burle and Hamdi teaches the system of claim 1, wherein the configuration data comprises configuration data of a computing environment comprising the first asset and, to generate the analysis result, the programming instructions are further structured to cause the processor to:
LUTTWAK in view of Burle does not disclose but Hamdi discloses and the first level of uniqueness being higher than the threshold see rationale and motivation in claim 1.
LUTTWAK in view of Burle and Hamdi does not explicitly disclose the below limitation.
MAOR discloses generate, based on the configuration data of the computing environment, an environment analysis result indicating an asset lock is applied to the first asset; and wherein the first asset is determined to be a critical asset based on the asset lock (MAOR [0004] “A lateral movement graph is a directed acyclic graph having nodes representing user accounts, devices, and groups and edges representing the relationship between the two nodes connected to an edge. Each node is classified as sensitive or non-sensitive depending on the permissions, roles, and credentials associated with the entity of the node.”, where permission and roles applied to nodes, where sensitive/critical node depending on/based on the permission and roles corresponding to asset lock, [0031] “…the LMP graph generation component 124 may be generated from a tool that monitors the users' behavior and activities and obtains information about each tenant, such as permissions and group memberships. Examples of such software tools include Microsoft® Azure® ATP and the Microsoft® Advanced Threat Analytics.” ).
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 LUTTWAK in view of Burle and Hamdi to incorporate the teaching of MAOR to utilize the above feature, with the motivation of identifying a weak connection and potential target for a lateral movement attack, as recognized by (MAOR Abstract ).
Regarding claim 15, claim 15 recites similar limitations to claim 6, therefore rejected with the same rationale and motivation applied to claim 6.
Claims 7 and 16 are rejected under 35 U.S.C. 103 as being unpatentable over LUTTWAK (US 20230123477 A1), hereinafter LUTTWAK in view of Burle et. al. (US 20210234889 A1), hereinafter Burle, Hamdi (US 20220109689 A1), hereinafter Hamdi and Wilshinsky (US 20210173854 A1), hereinafter Wilshinsky.
Regarding claim 7, LUTTWAK in view of Burle and Hamdi teaches the system of claim 1, wherein the configuration data comprises configuration data of a computing environment comprising the first asset and,
LUTTWAK in view of Burle does not disclose but Hamdi discloses and the first level of uniqueness being higher than the threshold see rationale and motivation in claim 1.
LUTTWAK in view of Burle and Hamdi does not explicitly disclose the below limitations.
Wilshinsky generate, based on the configuration data of the computing environment, an environmental analysis result indicating the first asset is subject to an immutable storage protocol; and wherein the first asset is determined to be a critical asset based on the first asset being subject to the immutable storage protocol (Wilshinsky [0152] “The AI/algorithm/rules module 43 may analyze and classify the data. For example, the logic layer processor 40 may encrypt the data if identified as highly descriptive sensitive financial data such as a bank statement based on classifications from the AI/algorithm/rules module 43. In other embodiments, the classification may also include a determination of the storage type and security to be used. If the bank statement is in a PDF format, the bank statement may be stored as immutable encrypted distributed storage. A W2 or 1099 form from a prior year may be stored in immutable encrypted distributed storage.”).
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 LUTTWAK in view of Burle and Hamdi and Hamdi to incorporate the teaching of Wilshinsky to utilize the above feature, with the motivation of ensuring accuracy, as recognized by (Wilshinsky [0049] ).
Regarding claim 16, claim 16 recites similar limitations to claim 7, therefore rejected with the same rationale and motivation applied to claim 7.
Claims 9 and 17 are rejected under 35 U.S.C. 103 as being unpatentable over LUTTWAK (US 20230123477 A1), hereinafter LUTTWAK in view of Burle et. al. (US 20210234889 A1), hereinafter Burle and Hamdi (US 20220109689 A1), hereinafter Hamdi and Di (US 20160028750 A1).
Regarding claim 9, LUTTWAK in view of Burle and Hamdi teaches the system of claim 1, wherein the group of the assets are assets within the same computing environment and the programming instructions are further structured to cause the processor circuit to:
LUTTWAK does not explicitly disclose ethe below limitation.
Burle discloses prioritize the remedial action over another remedial action corresponding to a second asset within the same computing environment as the first asset (Burle [0010] “The computer system can also include a remediation implementer prioritizing implementation of a remediation action to secure the computer resource when a vulnerability path extends from a vulnerable computer resource (i.e. second asset) to the critical computer resource (i.e. first asset).”).
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 LUTTWAK to incorporate the teaching of Burle to utilize the above feature, with the motivation of securing the vulnerable computer resource as a safe remediation action that does not impact availability of the application executing on the networked computer system., as recognized by (Burle Abstract ).
LUTTWAK in view of Burle and Hamdi does not explicitly disclose the below limitations.
Di discloses determine an average value of a configuration of assets within the group of assets (Di discloses a plurality of nodes with known/expected/average values of network traffic behavior ([0052, 0057]) in a network and illustrated in Figure 1, i.e. group of nodes in a network, [0060] “An anomaly score threshold—In some embodiments, message 404 may include an anomaly score threshold that may be used by a device/node to denote how far an observed behavior may stray from the expected traffic (i.e. average value) model before being labeled as unexpected. In particular, each model can provide an anomaly score threshold for an observed feature vector that defines how far a vector can be with respect to the modeled behavior that was used to train the ANN before being considered anomalous.”);
determine the first level of uniqueness based on a comparison of the value of the configuration of the first asset to the average value (Di [0060] “An anomaly score threshold—In some embodiments, message 404 may include an anomaly score threshold that may be used by a device/node to denote how far an observed behavior may stray (i.e. first level of uniqueness) from the expected traffic (i.e. average value) model before being labeled as unexpected. In particular, each model can provide an anomaly score threshold for an observed feature vector that defines how far a vector can be with respect to the modeled behavior that was used to train the ANN before being considered anomalous…”);
determine a second level of uniqueness of a configuration of a second asset of the group of assets; determine the second level of uniqueness is below the threshold (i.e. Di discloses [0059-0060] discloses different nodes within the network with their respective score associated with the traffic behavior, [0063] “FIGS. 5A-5B, a particular node 104 may filter its input features/observations, detect an unexpected behavior by comparing this observed behavior to its installed expected traffic model, compute an anomaly score based on the comparison, and determine that the anomaly score meets or exceeds an anomaly score threshold.”)
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 LUTTWAK in view of Burle and Hamdi and Hamdi and Hamdi to incorporate the teaching of Di to utilize the above feature, with the motivation of detecting and notifying a device of unexpected type traffic behavior, as recognized by (Di Abstract).
Regarding claim 17, claim 17 recites similar limitations to claim 9, therefore rejected with the same rationale and motivation applied to claim 9.
Claims 10 is rejected under 35 U.S.C. 103 as being unpatentable over LUTTWAK (US 20230123477 A1), hereinafter LUTTWAK in view of Burle et. al. (US 20210234889 A1), hereinafter Burle, Hamdi (US 20220109689 A1), hereinafter Hamdi and Lin et. al. (US 11503061 B1), hereinafter Lin.
Regarding claim 10, LUTTWAK in view of Burle and Hamdi teaches the system of claim 1, wherein to perform the remedial action, the programming instructions are further structured to cause the processor to::
LUTTWAK in view of Burle and Hamdi does not explicitly disclose the below limitations.
Lin discloses determine a protective action based on the analysis of the configuration data (Lin Col. 5 line 5-11 “The remediation planning system may then use the ranking metric to rank candidate remediation plans or recommend selected plans to the user. In this manner, the remediation planning system is able to use the ER model to programmatically determine remediation plans with the optimal balance of security gains and associated costs.”, Figure 8 illustrates remediation plans listed on a graphical user interface based on the analysis illustrated in Figure 11 1110, Col. 22 line 9-15 “The process begins at operation 1110, where a risk score is determined for a set of machines using the ER model and based on the characteristics data of the set of machines. Operation 1110 may be performed by the machine risk assessment system 162 or the machine assessment service 346 of FIG. 3, using a deployed version of the ER model (e.g. ER model 160).”, Col. 23 line 8-21 “At operation 1170, a list of selected remediation action plans is provided as output. The selected plans are selected and ranked based on their respective risk score reductions and costs. In some embodiments, for each remediation plan, the cost and the risk score reduction may be combined to determine a rank metric for the plan (e.g. a security gain per unit of cost) that is used to rank the plan. In some embodiments, the output may include only a single best plan determined based on the rank metric. In some embodiments, the output may include a subset of candidate plans whose rank metric values exceed a specified threshold. In some embodiments, the output may be provided as recommendations on a graphical user interface such as the GUI 800 of FIG. 8.”).
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 LUTTWAK in view of Burle and Hamdi and Hamdi to incorporate the teaching of Lin to utilize the above feature, with the motivation of comparing the effectiveness of different remediation actions to protect against the set of attacks., as recognized by (Lin Abstract ).
Claim 21 is rejected under 35 U.S.C. 103 as being unpatentable over LUTTWAK (US 20230123477 A1), hereinafter LUTTWAK in view of Burle et. al. (US 20210234889 A1), hereinafter Burle and Hamdi (US 20220109689 A1), hereinafter Hamdi and Dodge (US 20200007569 A1), hereinafter Dodge.
Regarding claim 21 (New), LUTTWAK in view of Burle and Hamdi teaches the method of claim 11.
LUTTWAK in view of Burle and Hamdi does not explicitly disclose the below limitations.
Dodge discloses wherein the group of assets is a cluster of nodes in a networked computing system and said determining the level of uniqueness further comprises: determining the first level of uniqueness based at least on the first asset having access to a virtual network separate from a second asset of the cluster of nodes (Dodge [0074] “obtain answers to questions (posed as queries that specify constraints) about their virtual network on the provider network. Example questions that may be posed as queries include, but are not limited to: [0075] Which instances in the virtual network are accessible from the Internet? [0076] Which instances can access specified resources on the virtual network (e.g., a database, a cache, a storage endpoint, another instance, etc.)? [0077] Does the virtual network conform to best practices of a networking security standard? [0078] Does the virtual network comply with my company's best practices as encoded in this set of rules?”, [0080] “Verifying that a pipe between a resource and other resources in the virtual network or a pipe between a resource in the virtual network and external entities is open may include verifying that there is a path or route over the network (i.e., that there is network connectivity) between the resources or between a resource and the external entities (e.g., a path from the resource to an HTTPS gateway via which external entities may access resources on the virtual network). A path may be a direct path over the network that provides network connectivity between endpoints, or alternatively may be a transitive path that passes through one or more hops on a route and that provides network connectivity between endpoints.”, verifying which nodes/endpoints/instances, interpreted as entities in a cluster has access to resources in a virtual network).
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 LUTTWAK in view of Burle and Hamdi to incorporate the teaching of Dodge to utilize the above feature, with the motivation of complying with best practices as encoded in a set of rules, as recognized by (Dodge [0078]).
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.
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