DETAILED ACTION
This action is in response to communication filed on 7/7/2026.
Claims 1-30 are pending.
Claims 1, 19, 20, and 29 have been amended.
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Response to Arguments
Applicant's arguments filed 7/7/2026 have been fully considered. Claims 1, 19, 20, and 29 were amended. The amendments and arguments have been reviewed. The rejection of claims 1-28 and 30 under 35 USC § 103 as being unpatentable over Semel at al. (US 2022/0103592) in view of Baikalov et al. (US 2016/0226905) is maintained. The remaining claims continue to be rejected under 35 USC § 103 based on the combination of Semel and Baikalov further combined with one or more additional references as previously set forth. Claim 29 remains objected to for the reasons previously stated.
Applicant’s principal argument is that Semel and Baikalov, individually or in combination, fail to disclose or render obvious the features of independent claim 1 (and correspondingly independent claims 27 and 28) that “the particular incident is determined based at least in part on (i) one or more alert scores associated with a set of risk factors for the particular incident, wherein each alert score is based on a risk score impact value and an alert criticality for the corresponding risk factor, and (II) a vulnerability score for the particular incident, wherein the vulnerability score is based at least in part on exploit intelligence score.” Applicants further contend that dependent claims 2-26 and 30 are patentable by virtue of their dependence on claim 1. This argument is not persuasive.
Under the broadest reasonable interpretation consistent with the specification, the phrase “the particular incident is determined based at least in part on …” is reasonably construed as the calculation or determination of an incident risk score associated with that incident. An “alert score … based on a risk score impact value and an alert criticality for the corresponding risk factor” is met by any scoring of a risk factor that incorporates an impact or weighting value together with a severity or criticality level. A “vulnerability score … based at least in part on exploit intelligence score” is met by any vulnerability scoring that incorporates data concerning exploit existence, availability, maturity, prevalence in the wild, or temporal exploitation activity.
Semel teaches determining risk scores for entities and associated incidents using multiple categories of risk factors (functional, configurational, and behavioral). See Semel [0078], FIG. 3, and the accompanying discussion of example categories of factors for determining a risk score, including functional factors (asset criticality and related impact), configurational factors (known vulnerabilities scored using CVSS severity levels together with available exploits and exploit popularity), and behavioral factors (including alert-like indicators such as malicious activity detection, traffic reputation, and anomaly detection). Asset criticality functions as an impact multiplier or weighting value. Vulnerability scoring in Semel expressly incorporates CVSS severity (criticality) and further adjusts for available exploits and exploit popularity (forms of exploits intelligence). These teachings disclose, or at minimum render obvious, the determination of an incident risk score formed from one or more alert scores (each based on a risk score impact value and an alert criticality for the corresponding risk factor) plus a vulnerability score based at least in part on exploit intelligence.
Baikalov teaches hierarchical aggregation of singular threat (incident) risk scores into composite threats, entity risks, and ultimately an organizational or enterprise level risk score that represents the security posture of the network or attack surface with particular emphasis on higher weight or more significant risks (a subset of risks). See Baikalov [0024-0025] (“At the next level, entity risks 140 may be determined … by aggregating … dynamic threat risks from singular threats 112 and composite threats 130 … Entity risks may further be aggregated to determine the organizational risk 150 … as well as for the enterprise 156 itself” and the discussion of weighting and combining risk scores of threat indicators).
Therefore, it would have been obvious to a person of ordinary skill in the art at the time the invention was effectively filed to modify the pre-entity, multi-factor incident risk scoring system of Semel (which already combines impact/criticality weighted factors with exploit aware vulnerability scoring) with Baikalov’s hierarchical aggregation of singular incident risk scores into a network or organization level security rating focused on a subset of the most significant risks. One of ordinary skill would have been motivated to combine to obtain a holistic security rating for the entire network’s attack surface that prioritizes the most significant risks, thereby enabling improved overall threat prioritization, resource allocation, and remediation across the organization. Both references are directed to the same field of cybersecurity risk assessment that employs multi-factor scoring of incidents or threats and weighted aggregation. The combination yields predictable results of a more comprehensive attack surface level security rating and does not produce any unexpected results.
Applicant’s argument consists essentially of a bare assertion that the cited references fail to disclose the recited features. No detailed comparison of the specific teachings of Semel or Baikalov against the claim language is provided, nor is any explanation offered as to why the multi-factor scoring framework of Semel (impact/criticality and CVSS/exploit data) fails to meet or render obvious the claimed alert score and vulnerability score structure under the broadest reasonable interpretation. Conclusory assertion of this nature is insufficient to overcome a properly supported obviousness rejection (see MPEP § 2145).
Dependent claims 2-26 and 30 stand rejected for the same reason as independent claim 1 and the additional reasons previously set forth in the prior Office Action. The features recited in those dependent claims are taught by the cited combination or would have been obvious modification thereof for the reasons previously explained. No separate arguments traversing those features have been presented. Accordingly, the rejection under 35 USC § 103 are maintained.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102 of this title, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1-10 and 14-28 and 30 are rejected under 35 U.S.C. 103 as being unpatentable over Semel at al. (US 2022/0103592).in view of Baikalov et al. (US 2016/0226905).
Regarding claim 1, Semel discloses a system for identifying network incident risk, comprising: one or more processors configured to:
determine a set of incident risk scores for a set of incidents on a network (Semel [0078]; FIG. 3 depicts example categories of factors for determining a risk score. Example diagram 300 depicts various potential and actual factors in relation to functional, configurational, and behavioral categories and their respective weights within each category);
wherein the particular incident is determined based at least in part on (i) one or more alert scores associated with a set of risk factors for the particular incident, wherein each alert score is based on a risk score impact value and an alert criticality for the corresponding risk factor, and (ii) a vulnerability score for the particular incident, wherein the vulnerability score is based at least in part on exploit intelligence score (Semel discloses determining risk scores for entities and associated incidents using multiple risk factors (Functional, configuration, and behavioral). The functional factors include asset criticality, which functions as an impact value/coefficient that multiplies or weighs the overall score. Individual factors are scored with severity/impact levels (criticality). The overall risk score combines these factor scores. Known vulnerabilities are scored using available exploits, exploit databases, popularity, and related intelligence; [0095] “the functional category 302 may represent the impact of an asset or entity. The functional category value associated with an entity may act a coefficient to normalize the resulting risk score computed using a value based on configurational category 304 or behavioral category 306, or a combination thereof”, [0101] “Known vulnerabilities 322 is based on a weakness or vulnerability which can be exploited by a threat actor (e.g., attacker), to perform unauthorized actions within a system or entity. Known vulnerabilities 322 may take into consideration the vulnerabilities' available exploits, remediation (e.g., whether a vendor has released a patch or update that will fix the vulnerability), information related to the vulnerability from the deep or dark web (e.g., a hacker forum, Git-Hub repository, an exploit database, etc., mentioning of a vulnerability, exploits, etc.), or a combination thereof”, [0104] “remediation level, available exploit(s), and the known vulnerability popularity (e.g., trending level) aspects associated with a vulnerability . The more exploits (e.g., scripts or other utilities) that are available to take advantage of a vulnerability may increase the risk score associated with the known vulnerabilities 322. The popularity of a vulnerability may increase the known vulnerability 322 value based on mentions by threat actors, presence in an exploit database (e.g., Metasploit), GitHub, or on social media, etc.”, [0193] “The risk score or value for an entity can then be computed using the equations:”
PNG
media_image1.png
539
666
media_image1.png
Greyscale
); and
provide the security rating (see Semel [0196]; At block 418, the risk value for the entity is stored); and a memory coupled to the one or more processors and configured to provide the one or more processors with instructions.
However, the prior art does not explicitly disclose generate a security rating for an attack surface for the network, wherein the security rating is an aggregation of the incident risk scores associated with a subset of risks on the network.
Baikalov in field of the same endeavor discloses techniques for assessing threats based on a mix of behavioral and direct indicators. In particular, Baikalov teaches the following:
generate a security rating for an attack surface for the network, wherein the security rating is an aggregation of the incident risk scores associated with a subset of risks on the network (Baikalov discloses determining singular-threat risk scores (incident risk scores) and aggregating them into composite threats and entity risk, then further aggregating those entity risks (a subset of the highest-weight or most significant ones) into an organizational risk score that represents the holistic security rating for the network/enterprise attack surface; [0024-0025] “At the next level, entity risks 140 may be determined, as will be described in more detail below, by aggregating, as shown, dynamic threat risks from singular threats 112 and composite threats 130 attributed to a specific entity, such as a user 142, an application 144, or a system 146. Entity risks may further be aggregated to determine the organizational risk 150 for departments or groups such as sales 152 and engineering 154 within the organization, as well as for the enterprise 156 itself” and [0025] “Combining behavioral and direct indicators to determine composite risk… Behavioral indicators have an anomaly probability, P.sub.I, that is generally less than 1.0… Where there are multiple behavioral and direct indicators that may be indicative of an actual threat, some indicators may be more important and more critical than others in indicating the threat... The invention affords a method for accomplishing this by enabling risk scores to be determined for each threat indicator, and by enabling the risk scores to be aggregated and combined to determine a composite threat score as a weighted probability of all associated threat indicators”).
Therefore, it would have been obvious to a person of ordinary skill in the art at the time the invention was effectively filed to modify the per-entity incident-factor risk scoring and weighted aggregation system of Semel with Baikalov’s hierarchical aggregation of entity-level threat risk (from singular incidents) into an organizational/network-level score. One would have been motivated to obtain a holistic security rating for the entire network’s attack surface that focuses on a subset of the most significant risk, thereby enabling better overall threat prioritization, resource allocation, and remediation across the organization. Both references are directed to the same field of cybersecurity risk assessment using incident indicators and weighted aggregation and combining them yields predictable improvements in network-wide visibility without undue experimentation.
Regarding claim 2, Semel-Baikalov discloses the system of claim 1, wherein providing the security rating comprises providing the security rating to a service that is configured to automatically perform a remediation of one or more issues contributing to the security rating (see Semel [0212]; policy component 518 is operable for initiating or triggering one or more remediation actions or security actions according to one or more policies, e.g., based on one or more risk values, as described herein. Policy component 518 may further be configured to perform other operations including checking compliance status, finding open ports, etc. Policy component 518 may restrict network access, signal a patch system or service, signal an update system or service, etc., as described herein. The policy component 518 may thus, among other things, invoke automatically patching, automatically updating, and automatically restrict network access of an entity (e.g., that has out-of-date software or based on access rule violation or attempted violation)).
Regarding claim 3, Semel-Baikalov discloses the system of claim 1, wherein the one or more processors are further configured to: generate instructions for performing a remediation of one or more issues contributing to the security rating (see Semel [0212]; policy component 518 is operable for initiating or triggering one or more remediation actions or security actions according to one or more policies, e.g., based on one or more risk values, as described herein. Policy component 518 may further be configured to perform other operations including checking compliance status, finding open ports, etc. Policy component 518 may restrict network access, signal a patch system or service, signal an update system or service, etc., as described herein. The policy component 518 may thus, among other things, invoke automatically patching, automatically updating, and automatically restrict network access of an entity (e.g., that has out-of-date software or based on access rule violation or attempted violation)).
Regarding claim 4, Semel-Baikalov discloses the system of claim 1, wherein the security rating is dynamic and is recalculated when an incident risk score for an underlying risk changes (see Semel [0198-0199]; a recalculation of the risk value may be performed based on a change in a property value associated with an entity, a change in classification associated with the entity, etc.).
Regarding claim 5, Semel-Baikalov discloses the system of claim 1, wherein the incident risk score for the underlying risk changes in response to a change to a risk property (see Semel [0198-0199]; at block 420, a change is detected with respect to the entity. The change may be detected based on a change in information associated with the entity).
Regarding claim 6, Semel-Baikalov discloses the system of claim 1, wherein the one or more processors are further configured to:
obtain information pertaining to a set of risk properties for a network or services consumed or provided within the network, wherein the set of risk properties comprises the underlying risk property (see Semel [0192]; at block 416, a risk value for the entity is determined based on a functional factor and at least one of a configurational factor or a behavioral factor); and
determine that the underlying risk property has changed (see Semel [0195]; The use of the sliding time window allows risk scores and values (e.g., associated with factors) to change (e.g., increase or decrease) based on changes to entities (e.g., patches of vulnerabilities, opening/closing of one or more ports, new vulnerabilities, new connections from the Internet, EoL proximity, etc.)); and
in response to determining that the underlying risk has changed, recomputing the security rating (see Semel [0199]; block 420 may be performed as part of an automatic (e.g., without user involvement), periodic, continuous, or combination thereof computation or recalculation of one or more risk values associated with one or more entities. A recalculation of the risk value may be performed based on a change in a property value associated with an entity, a change in classification associated with the entity, etc.).
Regarding claim 7, Semel-Baikalov discloses the system of claim 1, wherein one or more of the set of incident risk scores is periodically recalculated (see Semel [0199]; block 420 may be performed as part of an automatic (e.g., without user involvement), periodic, continuous, or combination thereof computation or recalculation of one or more risk values associated with one or more entities).
Regarding claim 8, Semel-Baikalov discloses the system of claim 1, wherein the security rating is calculated as a weighted average of the incident risk score (see Semel [0065]; the risk factors, risk factor weights, and factor scores for the above examples are depicted in Table I below. Table I shows values for each factor that can be used in determining a respective risk score for device 260 and device 234).
a set of incidents of a set of incidents that would result from an enablement of all high and medium-severity attack surface rules on an attack surface for the network (Baikalov teaches explicit classification of risk into high, medium and low severity categories and aggregates weighted risk scores (threat indicators) that correspond to specific incidents or threats on a network. Baikalov’s threat indicators functions as the “incident risk scores” and the system focuses the composite rating on high and medium severity threats while de-emphasizing low severity ones; [0040] “assuming that an enterprise has raw risk scores for an entity distributed between 0 and 270, the enterprise may determine in its judgment that raw scores between 0-130 (54%) represent low risks; raw scores between 130 and 210 (33%) represent medium risks; raw scores between 210 and 250 (10%) represent high risks; and scores above 250 (3%) are classified as being critical risks”)
Regarding claim 9, Semel-Baikalov discloses the system of claim 8, wherein a predefined percentage of the set of incidents having a highest incident risk scores are disproportionally weighted more heavily than other incidents comprised in the set of incidents (see Semel [0066-0077]; Using the weights for each factor and the factor score, the risk score or value for an entity can then be computed using the equation).
Regarding claim 10, Semel-Baikalov discloses the system of claim 8, wherein low-severity policies are excluded from calculation of the security rating (see Semel [0066-0077]; Using the weights for each factor and the factor score, the risk score or value for an entity can then be computed using the equation. In other words, low-severity polices contributes little, akin to exclusion).
Regarding claim 14, Semel-Baikalov discloses the system of claim 1, wherein the security rating represents an adversarial view of an external-facing attack surface of the network (Semel calculates pre-entity risk score by incorporating configurational and behavioral factors that expressly evaluate the network’s external-facing assets from the perspective of a threat actor or remote attacker. These factors include open ports and Internet exposure, which define points of engagements on the attack surface that an external adversary can exploit. The risk assessment therefore represents an adversarial view because it quantifies risk precisely as a threat actor would perceive and target the public facing portions of the network; [0093] “An attack surface of an entity may include any security point of engagement, where a threat actor (e.g., attacker which may include a compromised entity) can initiate attack. For example, each new open port, open share, vulnerability, etc., may give the attacker another point (e.g., the new open port) where he or she can try to compromise an entity” and [0176] “An Internet-facing entity is exposed to remote threat actors (e.g., attackers outside an organization and may be located anywhere on the planet). Remote threat actors can be increasingly dangerous. A remote attacker may exploit one or more one day or zero days vulnerabilities to gather intelligence, access sensitive data, and in some cases gain full control of one or more entities, which eventually might threaten an entire organizational network”).
Regarding claim 15, Semel-Baikalov discloses the system of claim 1, wherein the one or more processors are further configured to: generate a graphical visualization of the security rating (see Semel [0041]; Network monitor device 102 may provide an interface (e.g., a graphical user interface (GUI)) for viewing, monitoring, modifying, and configuring risk determination (e.g., user configuration of one or more parameters or factors used for determining a risk score). In some embodiments, network monitor device 102 is operable to perform visualization (e.g., including tables or matrixes) of risk values for each entity and groups of entities (e.g., a segment, a location, etc.)).
Regarding claim 16, Semel-Baikalov discloses the system of claim 15, wherein the graphical visualization comprises security ratings of attack surfaces for the network based on geography (see Semel [0041]; Network monitor device 102 may provide an interface (e.g., a graphical user interface (GUI)) for viewing, monitoring, modifying, and configuring risk determination (e.g., user configuration of one or more parameters or factors used for determining a risk score). In some embodiments, network monitor device 102 is operable to perform visualization (e.g., including tables or matrixes) of risk values for each entity and groups of entities (e.g., a segment, a location, etc.)).
Regarding claim 17, Semel-Baikalov discloses the system of claim 1, wherein the one or more processors are further configured to:
determine whether the security rating exceeds a predefined threshold (see Semel [0212]; Policy component 518 is operable for initiating or triggering one or more remediation actions or security actions according to one or more policies, e.g., based on one or more risk values); and
in response to determining that the security rating exceeds the predefined threshold, causing an active measure to be performed (see Semel [0212]; Policy component 518 may further be configured to perform other operations including checking compliance status, finding open ports, etc. Policy component 518 may restrict network access, signal a patch system or service, signal an update system or service, etc).
Regarding claim 18, Semel-Baikalov discloses the system of claim 17, wherein the active measure comprises one or more of:
(i) triggering a playbook, (ii) generating an alert, and (iii) causing a remediation action to be performed with respect to a particular vulnerability (see Semel [0212]; policy component 518 is operable for initiating or triggering one or more remediation actions or security actions according to one or more policies, e.g., based on one or more risk values, as described herein. Policy component 518 may further be configured to perform other operations including checking compliance status, finding open ports, etc. Policy component 518 may restrict network access, signal a patch system or service, signal an update system or service, etc., as described herein. The policy component 518 may thus, among other things, invoke automatically patching, automatically updating, and automatically restrict network access of an entity (e.g., that has out-of-date software or based on access rule violation or attempted violation)).
Regarding claim 19, Semel-Baikalov discloses the system of claim 1, wherein the security rating is decomposable into a set of network components that contributed to the computed security rating (see Semel [0131]; FIG. 4 depicts a flow diagram of aspects of a method for determining a risk score in accordance with one implementation of the present disclosure. Various portions of flowchart 400 may be performed by different components (e.g., components of system 500) of an entity (e.g., network monitor device 102 or network monitor device 280). Flowchart 400 depicts a process for determining a risk score or value based on one or more factors (e.g., of FIG. 3)).
Regarding claim 20, Semel-Baikalov discloses the system of claim 19, wherein the one or more processors are further configured to:
configure a user interface based at least in part on the security rating, the user interface comprising a selectable element (see Semel [0041]; network monitor device 102 is operable to perform visualization (e.g., including tables or matrixes) of risk values for each entity and groups of entities (e.g., a segment, a location, etc.)); and
in response to determining that the selectable element is selected, providing an indication of the set of network components that contributed to the security rating (see Semel [0210]; Display component 514 is configured to optionally display one or more graphical user interfaces or other interfaces (e.g., command line interface) for depicting various information associated with entities or devices, alerts, asset management, and compliance with standards and other policies, as described herein. In some embodiments, display component 514 may display or render a network graph of entities, attributes associated with each entity or device, risk values, and indications of security policy alerts, compliance alerts, etc).
Regarding claim 21, Semel-Baikalov discloses the system of claim 1, wherein the security rating aggregates scores for risks associated with a set of one or more of incidents, common vulnerabilities and exposures (CVEs), and misconfigurations (see Semel [0083]; At a high level, embodiments provide an aggregative formula for a risk score or value based on a combination or conjunction of one or more factors (e.g., from one or more different categories). The formula may thus incorporate risk aspects from the several layers including by category (e.g., functional, configurational, and behavioral), by actual or potential factors, and by a formula for each factor (e.g., within a category)).
Regarding claim 22, Semel-Baikalov discloses the system of claim 1, wherein the network comprises one or more of a service, a cloud-based service, a node, a security entity, a network-connected device, a client system, or a website (see Semel [0013]; the systems and methods disclosed can be employed with respect to network security, among other fields. More particularly, it can be appreciated that devices with vulnerabilities are a significant and growing problem. At the same time, the proliferation of network-connected devices (e.g., internet of things (IoT) devices such as televisions, security cameras (IP cameras), wearable devices, medical devices, etc.) in both IT and OT (Operational Technology) environments can make it difficult to effectively ensure that network security is maintained. Accordingly, described herein in various implementations are systems, methods, techniques, and related technologies, which allow for determining a risk (e.g., score or value) for an entity based on a plurality of factors thereby allowing prioritization of risks).
Regarding claim 23, Semel-Baikalov discloses the system of claim 1, wherein an incident risk score for a particular incident on the network is determined using a combination of various data sources, including expert domain knowledge, commercial and reputable open-source threat and exploit intelligence relevant to the CVEs on the network (see Semel [0028]; embodiments may combine data from third party threat feeds thereby enabling up to date risk scores based on the latest vulnerabilities. This can include combining information from (a user's) existing vulnerability analyses tools, combining risk for Internet of Medical Things (IoMT) entities, and combining risk for OT entities. Embodiments may also integrate third party threat feeds for blacklisted IPs (e.g., for IP reputation) and feeds for vulnerabilities (e.g., CVEs) and exploits).
Regarding claim 24, Semel-Baikalov discloses the system of claim 1, wherein an incident risk score for a particular incident on the network is determined using a machine learning model or artificial intelligence process (see Semel [0030]; Embodiments may base a risk score on detecting suspicious anomalies in IoT devices' behavior using machine learning (ML) techniques).
Regarding claim 25, Semel-Baikalov discloses the system of claim 24, wherein the machine learning model is trained using one or more of expert domain knowledge, commercial and reputable open-source threat and exploit intelligence relevant to the CVEs on the network (see Semel [0030]; detection of a device deviating from a learned baseline of their target destination service (e.g., via service enumeration), from a learned baseline of their target destination (e.g. lateral movement or command and control (C2) communication, for instance, with a bot net), or from a learned baseline of their normal traffic throughput (e.g., an infected device in exfiltration phase may involve significantly increased traffic throughput)).
Regarding claim 26, Semel-Baikalov discloses the system of claim 1, wherein the one or more processors are further configured to:
causing a remediation of one or more issues contributing to the security rating to be performed according to a prioritization of risks, wherein the prioritization is determined based at least in part on corresponding security ratings (see Semel [0029]; prioritizing of risks based on real threats to an enterprise or organization thereby enabling reducing risk (e.g., more rapidly) to the business. In some embodiments, the risk calculation may be cloud based. Embodiments may further work in conjunction with network visibility and control capability products. For example, visibility functionality may be used to collect risk indicators (e.g., associated with various factors, communications, traffic flow, vulnerabilities, etc.)).
Regarding claim(s) 27-28, do(es) not teach or further define over the limitation in claim(s) 1 respectively. Therefore claim(s) 27-28 is/are rejected for the same rationale of rejection as set forth in claim(s) 1 respectively.
Regarding claim 30, Semel-Baikalov discloses the system of claim 8, wherein the weighted average of the incident risk scores is determined by assigning weights to the set of incidents according to a weighting function (Semel’s risk-score calculation for network assets/entities is performed by assigning fixed category-specific weights to the various risk factors and then computing a weighted sum that functions as a weighted average bounded by a maximum value; [0193-0194] “The risk score or value for an entity can then be computed using the equations… the weight for the functional factors may be one (100%) applied to asset criticality and asset acquittance values. The weight applied to potential configurational factors may be 0.6 (60%) for known vulnerabilities and EoL proximity. The weight applied to actual configurational factors may be 0.4 (40%) for open shares, default credentials, and open ports. The weight applied to potential behavioral factors may be 0.2 (20%) for Internet exposure, secure traffic posture, anomaly detection. The weight applied to actual behavioral may be 0.8 (80%) for SSL/TLS analysis, traffic reputation, and malicious activity detection”)
a weighting function that disproportionately assigns higher weights to a predefined percentage of the set of incidents having the highest incident risk scores, such that at least ninety percent of collective weights are distributed to a top fifty percent of the set of incidents ranked by incident risk score (Baikalov teaches a risk-scoring system that explicitly ranks threat indicators by risk score and then applies a non-linear, disproportionate weighting/aggregation scheme that emphasizes the highest ranked (most severe) threats while de-emphasizing lower ones. Baikalov further parameterizes its normalization and composite scoring using statistics derived from the top 50% of the risk-score distribution, thereby effectively concentrating the majority of the scoring influence on the highest ranked incidents; [0042-0044] “the invention uses a normal cumulative distribution function for normalization. This distribution, which is illustrated in FIG. 9 for the classification levels of FIG. 8, is defined as… organizational risk may be determined as the arithmetic average of the top 25% of the risk score values of entities to avoid losing track of a small percentage of non-zero risk entities. Accordingly, organizational risk as determined by the invention is sensitive to high-risk entities, but is also stable relative to changes such as adding or removing entities to the enterprise or to significant changes in entity risk score”).
Therefore, it would have been obvious to one of ordinary skill in the art at the time the invention was effectively filed to modify Semel’s weighted-average security-rating calculation with Baikalov’s rank-based, disproportionate weighting function in order to make the overall security rating more sensitive to the most severe incident while de-emphasizing low-severity noise. The combination requires no more than routine implementation of known risk-aggregation techniques and yields no unexpected results.
Claims 11-13 are rejected under 35 U.S.C. 103 as being unpatentable over Semel at al. (US 2022/0103592) in view of Baikalov et al. (US 2016/0226905) in view of Yampolskiy et al. (US 2016/0173521).
Regarding claim 11, Semel-Baikalov discloses the invention substantially, however the prior art does not explicitly disclose the system of claim 1, wherein the security rating is normalized across attack surfaces for a set of networks.
Yampolskiy in the field of the same endeavor discloses techniques for calculating and benchmarking an entity’s cybersecurity risk score by non-intrusively collecting external data signals, computing components security scores, weighting them based on correlations with previously breached entities in the same industry, and aggregating into a normalized overall score for industry peer comparisons. In particular, Yampolskiy discloses the following:
wherein the security rating is normalized across attack surfaces for a set of networks (see Yampolskiy [0078]; Scorecard system 200 may utilize the benchmarking module 230 to further process the calculated individual scores for each type of data, which may incorporate any normalization or weights assigned to the calculated scores, to calculate an overall cybersecurity risk score for an entity. In other words, the scorecard system 200 can employ benchmarking module 230 to calculate a cybersecurity risk score for the entity based on data collected from the one or more data sources using security signal collection module 210 and processed with contextualization module 220).
Therefore, it would have been obvious to a person of ordinary skill in the art at the time the invention was effectively filed to modify the prior art with the teaching of Yampolskiy to incorporate techniques for calculating and benchmarking an entity’s cybersecurity risk score. One would have been motivated to incorporate Yampolskiy’ s normalization and benchmarking into Semele’s system to enable comparative risk evaluation, thereby improving prioritization of remediation efforts across diverse network segments. This combination would yield predictable results without requiring undue experimentation.
Regarding claim 12, Semel-Baikalov-Yampolskiy discloses the system of claim 11, wherein the one or more processors are further configured to:
determine a benchmarking of the attack surface for the network based on normalized security ratings across the attack surfaces for the set of networks (Yampolskiy discloses calculating normalized overall cybersecurity risk score across a benchmark group of companies/entities and then determining benchmarking by comparing/ranking those normalized score to create a percentile reference. The benchmarking is directly “based on” the normalized ratings, and the cybersecurity risk score corresponds to the claimed security rating for the attack surface; [0079] “To create the benchmark percentile reference for an industry, the scorecard system 200 may select a benchmark group of companies to represent an industry. For each of the companies in the benchmark group, the scorecard system 200 may calculate a normalized overall cybersecurity risk score in addition to normalized security scores for each of the different types of data that impacts overall cybersecurity. The scorecard system 200 can compare the scores for all the companies in the benchmark group to rank each of the scores and to establish the benchmark percentile reference to which to compare security scores calculated for companies by the scorecard system 200”); and
provide an indication of a benchmark for the security rating of the attack surface for the network (Yampolskiy disclose providing the benchmark indication for the entity’s overall cybersecurity risk score. The output is an explicitly indication that allows comparison of the entity’s rating to the normalized ratings of the set of other entities/networks; [0080] “the scorecard system 200 may use the percentiles submodule 234 of benchmarking module 230 to cross-reference each of the security scores to the benchmark percentile reference established for that industry to determine the entity's cybersecurity posture with respect to its peers. In other words, the scorecard system 200 may determine an industry cybersecurity percentile ranking for the entity based on the benchmarking of the calculated overall cybersecurity risk score against one or more cybersecurity risk scores for one or more other entities in the same industry as the entity”).
Regarding claim 13, Semel-Baikalov-Yampolskiy discloses the system of claim 12, wherein the benchmarking is determined with respect to attack surfaces across a selected industry segment (see Yampolskiy [0079]; to create the benchmark percentile reference for an industry, the scorecard system 200 may select a benchmark group of companies to represent an industry. For each of the companies in the benchmark group, the scorecard system 200 may calculate a normalized overall cybersecurity risk score in addition to normalized security scores for each of the different types of data that impacts overall cybersecurity).
Allowable Subject Matter
Claim 29 is objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
For the reasons above, claims 1-30 have been rejected and remain pending.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JIMMY H TRAN whose telephone number is (571)270-5638. The examiner can normally be reached Monday-Friday 9am-5pm PST.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Chris Parry can be reached at 571-272-8328. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
JIMMY H TRAN
Primary Examiner
Art Unit 2451
/JIMMY H TRAN/Primary Examiner, Art Unit 2451
Prosecution Insights