DETAILED ACTION
Claims 1-18 are pending in the present application and are under examination on the merits. This communication is the first action on the merits (FAOM).
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 .
Information Disclosure Statement
Applicant has not yet filed an IDS for this Application. As such, no IDS has been considered.
Drawings
The drawings filed on 6/6/2025 are acceptable as filed.
Claim Rejections - 35 USC§ 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-18 are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more. Here, under considerations of the broadest reasonable interpretation of the claimed invention, Examiner finds that the Applicant invented a method and system for determining a system’s vulnerability to cyberattacks by evaluating system sectors and assets. Examiner formulates an abstract idea analysis, following the framework described in the MPEP as follows:
Step 1: The claims are directed to a statutory category, namely a "method" (claims 1-9) and "system" (claims 10-18).
Step 2A - Prong 1: The claims are found to recite limitations that set forth the abstract idea(s), namely, regarding claim 1:
identifying… a system sector of a system under test for an analysis regarding the system sector's vulnerability to cybersecurity threats;
analyzing… the system sector to determine a plurality of system assets of the system sector;
evaluating… the plurality of system assets from a cybersecurity operation perspective to identify a cybersecurity status of the plurality of system assets;
when a system asset of the plurality of system assets has an unfavorable cybersecurity status: determining… a level of vulnerability to business operations of the system sector;
determining… a level of threat to business operations of the system sector based on the level of vulnerability and the plurality of system assets
outputting… the level of vulnerability and the level of threat
Independent claim 10 recites substantially similar claim language.
Dependent claims 2-9, and 11-18 recite the same or similar abstract idea(s) as independent claims 1 and 10 with merely a further narrowing of the abstract idea(s) to particular data characterization and/or additional data analyses performed as part of the abstract idea.
The limitations in claims 1-18 above falling well-within the groupings of subject matter identified by the courts as being abstract concepts, specifically the claims are found to correspond to the category of:
"Certain methods of organizing human activity- fundamental economic principles or practices (including hedging, insurance, mitigating risk); commercial or legal interactions (including agreements in the form of contracts; legal obligations; advertising, marketing or sales activities or behaviors; business relations); managing personal behavior or relationships or interactions between people (including social activities, teaching, and following rules or instructions)" as the limitations identified above are directed to determining a system’s vulnerability to cyberattacks by evaluating system sectors and assets and thus is a method of organizing human activity including at least commercial or business interactions or relations and/or a management of user personal behavior; and/or
"Mental processes - concepts performed in the human mind (including an observation, evaluation, judgement, opinion)" as the limitations identified above include mere data observations, evaluations, judgements, and/or opinions, e.g. including user observation and evaluation of a system’s vulnerability to cyberattacks by evaluating system sectors and assets, which is capable of being performed mentally and/or using pen and paper.
Step 2A - Prong 2: Claims 1-18 are found to clearly be directed to the abstract idea identified above because the claims, as a whole, fail to integrate the claimed judicial exception into a practical application, specifically the claims recite the additional elements of:
" an analysis computing entity / A computer-readable memory comprises: a first storage section that stores operational instructions that, when executed by an analysis computing entity, causes the analysis computing entity to: … a second storage section that stores operational instructions that, when executed by the analysis computing entity, causes the analysis computing entity to: " (claims 1 and 10) however the aforementioned elements merely amount to generic components of a general purpose computer used to "apply" the abstract idea (MPEP 2106.0S(f)) and thus fails to integrate the recited abstract idea into a practical application, furthermore the high-level recitation of receiving data from a generic " computing entity" is at most an attempt to limit the abstract to a particular field of use (MPEP 2106.0S(h), e.g.: "For instance, a data gathering step that is limited to a particular data source (such as the Internet) or a particular type of data (such as power grid data or XML tags) could be considered to be both insignificant extra-solution activity and a field of use limitation. See, e.g., Ultramercial, 772 F.3d at 716, 112 USPQ2d at 1755 (limiting use of abstract idea to the Internet); Electric Power, 830 F.3d at 1354, 119 USPQ2d at 1742 (limiting application of abstract idea to power grid data); Intellectual Ventures I LLC v. Erie lndem. Co., 850 F.3d 1315, 1328-29, 121 USPQ2d 1928, 1939 (Fed. Cir. 2017) (limiting use of abstract idea to use with XML tags).") and/or merely insignificant extra-solution activity (MPE 2106.05(g)) and thus further fails to integrate the abstract idea into a practical application;
Step 2B: Claims 1-18 do not include additional elements that are sufficient to amount to significantly more than the judicial exception because the additional elements as described above with respect to Step 2A Prong 2 merely amount to a general purpose computer that attempts to apply the abstract idea in a technological environment (MPEP 2106.0S(f)), including merely limiting the abstract idea to a particular field of use of cybersecurity analysis of a "system" via a "computing entity", as explained above, and/or performs insignificant extra-solution activity, e.g. data gathering or output, (MPEP 2106.0S(g)), as identified above, which is further found under step 2B to be merely well-understood, routine, and conventional activities as evidenced by MPEP 2106.0S(d)(II) (describing conventional activities that include transmitting and receiving data over a network, electronic recordkeeping, storing and retrieving information from memory, electronically scanning or extracting data from a physical document, and a web browser's back and forward button functionality). Therefore, similarly the combination and arrangement of the above identified additional elements when analyzed under Step 2B also fails to necessitate a conclusion that the claims amount to significantly more than the abstract idea directed to determining a system’s vulnerability to cyberattacks by evaluating system sectors and assets.
Claims 1-18 are accordingly rejected under 35 USC§ 101 because the claimed invention is directed to a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea(s)) without significantly more.
Note: The analysis above applies to all statutory categories of invention. As such, the presentment of any claim otherwise styled as a machine or manufacture, for example, would be subject to the same analysis
For further authority and guidance, see:
MPEP § 2106
https://www.uspto.gov/patents/laws/examination-policy/subject-matter-eligibility
Additionally, claims 10-18 are rejected under 35 U. S. C. 101 because the claimed invention is directed to non-statutory subject matter. These claims are directed towards a computer readable medium, and the applicant's specification does not specifically disclaim that a computer readable medium does not include carrier waves and signals which are non-statutory forms of patentable subject matter because these are transitory media which are not tangible. To overcome this rejection, the Office recommends amending the claims so that they recite only tangible, non-transitory media.
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102(A)(1) that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(A)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claims 1-3, 8-12, and 17-18 are rejected under 35 U.S.C. 102(A)(1) as being anticipated by U.S. Patent Application Publication Number 2014/0137257 to Martinez et al. (hereafter referred to as Martinez).
As per claim 1, Martinez teaches:
A method comprises: identifying, by an analysis computing entity, a system sector of a system under test for an analysis regarding the system sector's vulnerability to cybersecurity threats (Paragraph Number [0203] teaches the threat assessment process 1906 begins in block 2600. Sector threat level and sources are identified in block 1602 using sector historical threat data 2604. The goal of this step is to obtain a threat level for the type of sector being evaluated and to identify the potential threat sources that might be interested in compromising such sector. In this context, a sector is defined as a group of infrastructures, cyber and physical, that conducts a similar mission through similar operations, equipment, and personnel capabilities. Examples of sectors include utilities, higher education institutions, military bases, etc. Paragraph Number [0204] teaches every sector has a specific threat level according to the sector's mission, economic, or critical impact as perceived by the threat sources. A sector's threat level can be determined by analyzing historical cyber-attack data 2604 associated with the different sectors. Paragraph Number [0205] teaches cyber-attack patterns can be identified using data analytics, and such patterns can be used to determine which sectors are perceived as more appealing to threat sources. Such attack patterns change with time, so a sector's threat level must be updated as frequently as possible. When a sector is more appealing, the threat level is higher for this specific sector. The sector threat level becomes the maximum value that any critical asset that belongs to an infrastructure within an identified sector can have. (See also Paragraph Number [0230])).
analyzing, by the analysis computing entity, the system sector to determine a plurality of system assets of the system sector (Paragraph Number [0205] teaches cyber-attack patterns can be identified using data analytics, and such patterns can be used to determine which sectors are perceived as more appealing to threat sources. Such attack patterns change with time, so a sector's threat level must be updated as frequently as possible. When a sector is more appealing, the threat level is higher for this specific sector. The sector threat level becomes the maximum value that any critical asset that belongs to an infrastructure within an identified sector can have. Paragraph Number [0206] teaches analysis of historical cyber-attack data 2604 can also identify threat sources applicable to specific sectors. This work focuses on hacktivism, cybercrime, cyber warfare, and cyber espionage activities. Table 17 defines each of the threat sources categories. The applicable threat sources will be used to determine the types of attacks that can be used to exploit the cyber vulnerabilities in the CCAs that support the critical assets. (See also Paragraph Number [0230])).
evaluating, by the analysis computing entity, the plurality of system assets from a cybersecurity operation perspective to identify a cybersecurity status of the plurality of system assets (Paragraph Number [0147] teaches the mobile data collection characterization system 1308 allows users to capture metadata 1310 and analyze critical levels for physical assets as they are discovered by an operator conducting physical inspections. The mobile application system 1304 allows operators to capture metadata 1310 such as geospatial location and graphical representation of the physical assets in addition to other general information. To determine the criticality of an asset, the mobile data collection characterization system 1304 guides the user through a series of questions, based on the initial impact analysis step of the VARM process, an automatically calculate a criticality level for the asset. Once the process is completed, the critical infrastructure analysis results are used as input to the critical infrastructure data analysis and aggregation system 1306. Paragraph Number [0208] teaches the threat likelihood calculations (blocks 2610-2620) will now be described. COTI data 2608 supporting the critical assets is retrieved in block 2610, a vulnerability factor for the cyber critical asset is calculated in block 2612, and a threat likelihood for the cyber critical asset is calculated in block 2614 (see details below). If other critical cyber assets exist, as determined in decision block 2616, the process returns to block 2612 to calculate a vulnerability factor for the next cyber critical asset. If, however, no other cyber critical assets exist, as determined in decision block 2616, and if another COTI asset exists, as determined in decision block 2618, the process returns to block 2610 to retrieve COTI data for the next COTI asset. If, however, no other COTI assets exist, as determined in decision block 2618, a threat likelihood for the critical assets is calculated in block 2620 and the process proceeds to step 4 for the risk determination 1908. (Examiner asserts that a threat likelihood is functionally equivalent to a status in that it provides for information relating to risk determination)).
when a system asset of the plurality of system assets has an unfavorable cybersecurity status: determining, by the analysis computing entity, a level of vulnerability to business operations of the system sector (Paragraph Number [0095] teaches these vulnerabilities can be completed, whether as an accidental trigger or intentional exploit, causing an event with undesirable consequences or unfavorable impacts on organizational operations and assets, individuals, and other organizations. Paragraph Number [0125] teaches with respect to determining the vulnerability score in block 722, the Common Vulnerability Scoring System (CVSS) provides an open framework for communicating the characteristics and impacts of IT vulnerabilities. The CVSS is made up of three main metric groups and each consisting with a set of metrics for calculating the vulnerability score as seen in FIG. 9. It is not required to evaluate all three metric groups. Optionally, the base score can be refined by assigning values to the temporal and environmental metrics. Depending on the type of assessment required, the base score calculation and vector may be sufficient [6]. The vulnerability score will range from 0 to 10. Paragraph Number [0128] teaches the last primary step, Step 4 (108) of the VARM process 100 (risk determination), is the calculation of the risk of a critical asset being compromised by a threat-source. In most references, risk is calculated as a function of threat, vulnerability, and impact. The magnitude of the risk is directly dependent on the value for the obtained impact, threat, and vulnerability score. Therefore, the increase or decrease in the value for the impact, threat, or vulnerability will directly affect the magnitude of the risk from cyber and physical attacks).
determining, by the analysis computing entity, a level of threat to business operations of the system sector based on the level of vulnerability and the plurality of system assets (Paragraph Number [0106] teaches the threat impact score is determined in block 616 in order to calculate the overall threat score. Threat impact score will consist of the evaluation of a set of metrics and determination of their corresponding quantitative values. The metrics being evaluated for identification of the threat impact score are the intent, motivation, and capability of a threat-source attacking a critical asset. The NIST SP 800-30 Revision 1 document was used as reference for determining metric descriptions shown in Table 5 for the intent, motivation, and capability [10]. Paragraph Number [0108] teaches a threat score is calculated in block 618 for the threat-source and critical asset pair. The calculation is divided into two sections: the likelihood of an attack and the system effectiveness and threat impact. Therefore, the previously calculated values in Step 4 for likelihood and system effectiveness will be used to calculate the threat score).
outputting, by the analysis computing entity, the level of vulnerability and the level of threat (Paragraph Number [0155] and FIG. 18A depicts an example of a geospatial visualization 1234 of risk factors for the critical assets. In the geospatial representation 1234, critical assets are represented as circles with an icon in the center. The icon colors are modified at near-real time based on the risk level for the critical asset; Red is used for high risk, Yellow for medium risk and Green for low risk level. Each circle, when clicked, displays a dialog box 1802 that allows users to visualize detailed risk information about the asset. Paragraph Number [0157] teaches the risk analysis hyperlink 1810, when clicked, aggregates the final values from the threat, vulnerability and impact and displays the resulting risk level and index 1826. The view mitigation button 1814 on the detailed information dialog 1802, allows users to see a list of possible mitigation response processes that can be used to address the critical infrastructure risk 1828. The send mitigation button 1816, allows users to select a set of mitigation response processes 1830 and send them directly to dispatched emergency teams 1240 or to social networks users 1242).
As per claim 10, Martinez teaches:
A computer-readable memory comprises: a first storage section that stores operational instructions that, when executed by an analysis computing entity, causes the analysis computing entity to: … a second storage section that stores operational instructions that, when executed by the analysis computing entity, causes the analysis computing entity to: (Paragraph Number [0010] teaches the present invention provides a method for assessing a risk of one or more assets within an operational technology infrastructure by providing a database containing data relating to the one or more assets, calculating a threat score for the one or more assets using one or more processors communicably coupled to the database, calculating a vulnerability score for the one or more assets using the one or more processors, calculating an impact score for the one or more assets using the one or more processors, and determining the risk of the one or more assets based on the threat score, the vulnerability score and the impact score using the one or more processors. The foregoing method can be implemented as a computer program embodied on a non-transitory computer readable medium wherein the steps are executed by one or more code segments. Paragraph Number [0050] teaches the VARM process simplifies vulnerability assessment and risk management processes, applies to critical assets in OT (specifically energy systems), addresses threats and vulnerabilities in both information technology (IT) control planes and OT infrastructures, includes an impact analysis at each of the first three steps (as described below) rather than a single impact analysis, and provides a quantitative approach for risk determination based on a summation of weighted variables. Moreover, the VARM process provides software architecture for automated data collection, storage, and analytics at each VARM step using a Common Information Model (CIM). (Examiner asserts that each step utilizes data collection and storage and thus has multiple storage sections)).
The remainder of the claim limitations are substantially similar to those found in claim 1 and are rejected for the same reasons put forth in regard to claim 1.
As per claims 2 and 11, Martinez teaches each of the limitations of claims 1 and 10 respectively.
In addition, Martinez teaches:
establishing, by the analysis computing entity, a secure connection with the system under test for the analysis (Paragraph Number [0080] teaches Note: This data will be accessed from the secure Integrated Data Storage location. Different types of tools can be utilized for identifying the OT control plane (e.g., Network Discovery Tool, SCADA/Modbus Tool, Network Flow Analysis Tools, etc.)).
As per claims 3 and 12, Martinez teaches each of the limitations of claims 1 and 10 respectively.
In addition, Martinez teaches:
implementing, by the analysis computing entity, corrective measures to improve the unfavorable cybersecurity status of the system asset (Paragraph Number [0134] teaches with respect to determining if the risk level is high in decision block 1008, the magnitude of the risk is evaluated to determine if the risk is high on a critical asset. This consists of the consolidation of multiple risks on a critical asset. If risk is high, then proceed to next step for identifying and evaluating security countermeasures to mitigate risk. General security countermeasures are applied to critical assets with a low risk. Paragraph Numbers [0135]-[0138] teach with respect to identifying and evaluating strategies, treatments, or security countermeasures in order reduce or eliminate risk in block 1010, strategies, treatments, or countermeasures that could mitigate or eliminate the identified risks are provided. Risks can be managed by one of four distinct methods: Risk acceptance, Risk avoidance, Risk control, Risk transfer [14]. These Risk Management Strategies are defined as follows: Risk Acceptance: An explicit or implicit decision not to take an action that would affect a particular risk. Risk Avoidance: A strategy or measure which effectively removes the exposure of an organization to a risk. Risk Control (or reduction): Deliberate actions taken to reduce a risk's potential for harm or maintain the risk at an acceptable level).
As per claims 8 and 17, Martinez teaches each of the limitations of claims 1 and 10 respectively.
In addition, Martinez teaches:
when the plurality of system assets has an unfavorable cybersecurity status: determining, by the analysis computing entity, that the unfavorable cybersecurity status is based on one or more of: the system sectors lack of compliance with system guidelines; one or more deficiencies in system requirements of the system sector; and one or more deficiencies in system design of the system sector. (Paragraph Number [0123] teaches with respect to security test and evaluation, cyber physical systems for ICS (Industrial Control Systems)/SCADA (supervisory control and data acquisition) must be evaluated and tested for possible air-gaps (a physical gap between the control network and the business network), lack of security policies, faulty architectures, poor or nonexistent contingency plans, poor staff training, deficient cyber security culture and ethics. Multiple certified methods and analysis assist to rate the deficiencies on the security of the client critical infrastructures. (Examiner asserts that this teaches at least the alternatives of deficiencies in system requirements and deficiencies in system design)).
As per claims 9 and 18, Martinez teaches each of the limitations of claims 1 and 10 respectively.
In addition, Martinez teaches:
receiving, by the analysis computing entity, an input, wherein the input identifies at least one of: the system sector; and at least one evaluation viewpoint (Paragraph Number [0147] teaches the mobile data collection characterization system 1308 allows users to capture metadata 1310 and analyze critical levels for physical assets as they are discovered by an operator conducting physical inspections. The mobile application system 1304 allows operators to capture metadata 1310 such as geospatial location and graphical representation of the physical assets in addition to other general information. To determine the criticality of an asset, the mobile data collection characterization system 1304 guides the user through a series of questions, based on the initial impact analysis step of the VARM process, an automatically calculate a criticality level for the asset. Once the process is completed, the critical infrastructure analysis results are used as input to the critical infrastructure data analysis and aggregation system 1306. (See also Paragraph Numbers [0203]-[0205] in regard to determining identification of system sectors and associated threat levels)).
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102 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 4-7 and 13-16 are rejected under 35 U.S.C. 103 as being unpatentable over U.S. Patent Application Publication Number 2014/0137257 to Martinez et al. (hereafter referred to as Martinez) in view of U.S. Patent Application Publication Number 2021/0035116 to Berrington et al. (hereafter referred to as Berrington).
As per claims 4 and 13, Martinez teaches each of the limitations of claims 1 and 3, and 10 respectively.
Martinez teaches determining a system’s vulnerability to cyberattacks by evaluating system sectors and assets but does not explicitly teach an indication of the system assets compliance with prescribed cybersecurity standards as described by the following citations from Berrington:
generating, by the analysis computing entity, a system asset compliancy evaluation rating based on the level of threat, wherein the system asset compliancy evaluation rating is an indication of the system assets compliancy with prescribed cybersecurity standards (Paragraph Number [0004] teaches strict adherence to a single comprehensive standard is often wasteful and not useful for all organizations that might be subject to the audit. Imposing strict uniform compliance requirements can likewise cause the organization to seek to meet the letter of the requirements rather than its spirit, defeating much of the purpose of the standard and impairing efficiency. As such, it may in some cases be preferable to measure a level of standards compliance based on a percentage of the standard with which the organization in question complies (such as, for example, 70% compliance) or structuring the standard to provide certain “levels” of compliance, which the business or other organization can choose to pursue. (For example, there may be a “bronze,” “silver,” and “gold” level of compliance, each one indicating that the business meets certain further or more stringent requirements.) Paragraph Number [0013] teaches certain systems that businesses or other organizations may be operating can significantly complicate analysis. For example, further challenges and problems arise with larger groups which are made up of multiple entities with a high number of employees, covering a range of industries, located on a number of different sites, with a large number of domains and using different IT systems. There is often no common infrastructure and no baseline standards, and the IT environments or landscapes vary in size, complexity, posture and maturity. There are also limitations with regards to budget, scalability and capacity of the IT assurance function, meaning that the complexity of the system often exceeds the capacity of the auditor to perform the audit. Due to the costs and limitations of manual review, the auditor often must perform a risk-based auditing approach, effectively a “good-enough” approach, that might determine whether the system has met certain minimum standards or that might determine that particularly critical systems are compliant, without analyzing the system for compliance with other requirements or analyzing less apparently critical systems. This can mean that major, unexpected security holes can be missed in their entirety by an auditor who would have caught them if they were in a more critical-appearing system. (Examiner asserts that this section teaches a system asset compliancy and a sector compliance evaluation in that it teaches monitoring of IT systems (Assets) as well as sites and domains (sectors) associated with a particular company)).
Both Martinez and Berrington are directed to cybersecurity risk assessment. Martinez discloses determining a system’s vulnerability to cyberattacks by evaluating system sectors and assets. Berrington improves upon Martinez by disclosing an indication of the system assets compliance with prescribed cybersecurity standards. One of ordinary skill in the art would be motivated to further include an indication of the system assets compliance with prescribed cybersecurity standards, to efficiently determine a likelihood of risk related to cyberattack based on whether security measures are actually being followed. Accordingly, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the system and method of determining a system’s vulnerability to cyberattacks by evaluating system sectors and assets in Martinez to further utilize an indication of the system assets compliance with prescribed cybersecurity standards in Berrington, since the claimed invention is merely a combination of old elements, and in combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable.
As per claims 5 and 14, the combination of Martinez and Barrington teaches each of the limitations of claims 1 and 3, and 10 respectively.
Martinez teaches determining a system’s vulnerability to cyberattacks by evaluating system sectors and assets but does not explicitly teach an indication of the system assets compliancy with prescribed cybersecurity standards as described by the following citations from Berrington:
when the system asset compliancy evaluation rating compares unfavorably to a prescribed cybersecurity standards threshold: generating, by the analysis computing entity, a system asset threat evaluation rating based on the level of vulnerability and the system asset compliancy evaluation rating, wherein the system asset threat evaluation rating indicates how compromising the system asset is to the system under test (Paragraph Number [0004] teaches strict adherence to a single comprehensive standard is often wasteful and not useful for all organizations that might be subject to the audit. Imposing strict uniform compliance requirements can likewise cause the organization to seek to meet the letter of the requirements rather than its spirit, defeating much of the purpose of the standard and impairing efficiency. As such, it may in some cases be preferable to measure a level of standards compliance based on a percentage of the standard with which the organization in question complies (such as, for example, 70% compliance) or structuring the standard to provide certain “levels” of compliance, which the business or other organization can choose to pursue. (For example, there may be a “bronze,” “silver,” and “gold” level of compliance, each one indicating that the business meets certain further or more stringent requirements.) Paragraph Number [0013] teaches certain systems that businesses or other organizations may be operating can significantly complicate analysis. For example, further challenges and problems arise with larger groups which are made up of multiple entities with a high number of employees, covering a range of industries, located on a number of different sites, with a large number of domains and using different IT systems. There is often no common infrastructure and no baseline standards, and the IT environments or landscapes vary in size, complexity, posture and maturity. There are also limitations with regards to budget, scalability and capacity of the IT assurance function, meaning that the complexity of the system often exceeds the capacity of the auditor to perform the audit. Due to the costs and limitations of manual review, the auditor often must perform a risk-based auditing approach, effectively a “good-enough” approach, that might determine whether the system has met certain minimum standards or that might determine that particularly critical systems are compliant, without analyzing the system for compliance with other requirements or analyzing less apparently critical systems. This can mean that major, unexpected security holes can be missed in their entirety by an auditor who would have caught them if they were in a more critical-appearing system).
A person of ordinary skill would have been motivated to combine these references as described in regard to claim 4.
As per claims 6 and 15, Martinez teaches each of the limitations of claims 1 and 10 respectively.
Martinez teaches determining a system’s vulnerability to cyberattacks by evaluating system sectors and assets but does not explicitly teach an indication of the system assets compliancy with prescribed cybersecurity standards as described by the following citations from Berrington:
generating, by the analysis computing entity, a system sector compliancy evaluation rating based on the level of vulnerability, wherein the system sector compliancy evaluation rating is an indication of the plurality of system assets compliancy with prescribed cybersecurity standards (Paragraph Number [0004] teaches strict adherence to a single comprehensive standard is often wasteful and not useful for all organizations that might be subject to the audit. Imposing strict uniform compliance requirements can likewise cause the organization to seek to meet the letter of the requirements rather than its spirit, defeating much of the purpose of the standard and impairing efficiency. As such, it may in some cases be preferable to measure a level of standards compliance based on a percentage of the standard with which the organization in question complies (such as, for example, 70% compliance) or structuring the standard to provide certain “levels” of compliance, which the business or other organization can choose to pursue. (For example, there may be a “bronze,” “silver,” and “gold” level of compliance, each one indicating that the business meets certain further or more stringent requirements.) Paragraph Number [0013] teaches certain systems that businesses or other organizations may be operating can significantly complicate analysis. For example, further challenges and problems arise with larger groups which are made up of multiple entities with a high number of employees, covering a range of industries, located on a number of different sites, with a large number of domains and using different IT systems. There is often no common infrastructure and no baseline standards, and the IT environments or landscapes vary in size, complexity, posture and maturity. There are also limitations with regards to budget, scalability and capacity of the IT assurance function, meaning that the complexity of the system often exceeds the capacity of the auditor to perform the audit. Due to the costs and limitations of manual review, the auditor often must perform a risk-based auditing approach, effectively a “good-enough” approach, that might determine whether the system has met certain minimum standards or that might determine that particularly critical systems are compliant, without analyzing the system for compliance with other requirements or analyzing less apparently critical systems. This can mean that major, unexpected security holes can be missed in their entirety by an auditor who would have caught them if they were in a more critical-appearing system. (Examiner asserts that this section teaches a system asset compliancy and a sector compliance evaluation in that it teaches monitoring of IT systems (Assets) as well as sites and domains (sectors) associated with a particular company)).
A person of ordinary skill would have been motivated to combine these references as described in regard to claim 4.
As per claims 7 and 16, the combination of Martinez and Barrington teaches each of the limitations of claims 1 and 6, and 10 and 15 respectively.
Martinez teaches determining a system’s vulnerability to cyberattacks by evaluating system sectors and assets but does not explicitly teach an indication of the system assets compliancy with prescribed cybersecurity standards as described by the following citations from Berrington:
when the system sector compliancy evaluation rating compares unfavorably with the prescribed cybersecurity standards threshold: generating, by the analysis computing entity, a system sector threat evaluation rating based on the level of vulnerability and the system sector compliancy evaluation rating, wherein the system sector threat evaluation rating indicates how compromising the plurality of system assets of the system sector are to the system under test (Paragraph Number [0004] teaches strict adherence to a single comprehensive standard is often wasteful and not useful for all organizations that might be subject to the audit. Imposing strict uniform compliance requirements can likewise cause the organization to seek to meet the letter of the requirements rather than its spirit, defeating much of the purpose of the standard and impairing efficiency. As such, it may in some cases be preferable to measure a level of standards compliance based on a percentage of the standard with which the organization in question complies (such as, for example, 70% compliance) or structuring the standard to provide certain “levels” of compliance, which the business or other organization can choose to pursue. (For example, there may be a “bronze,” “silver,” and “gold” level of compliance, each one indicating that the business meets certain further or more stringent requirements.) Paragraph Number [0013] teaches certain systems that businesses or other organizations may be operating can significantly complicate analysis. For example, further challenges and problems arise with larger groups which are made up of multiple entities with a high number of employees, covering a range of industries, located on a number of different sites, with a large number of domains and using different IT systems. There is often no common infrastructure and no baseline standards, and the IT environments or landscapes vary in size, complexity, posture and maturity. There are also limitations with regards to budget, scalability and capacity of the IT assurance function, meaning that the complexity of the system often exceeds the capacity of the auditor to perform the audit. Due to the costs and limitations of manual review, the auditor often must perform a risk-based auditing approach, effectively a “good-enough” approach, that might determine whether the system has met certain minimum standards or that might determine that particularly critical systems are compliant, without analyzing the system for compliance with other requirements or analyzing less apparently critical systems. This can mean that major, unexpected security holes can be missed in their entirety by an auditor who would have caught them if they were in a more critical-appearing system).
A person of ordinary skill would have been motivated to combine these references as described in regard to claim 4.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MATTHEW H. DIVELBISS whose telephone number is (571) 270-0166. The fax phone number is 571-483-7110. The examiner can normally be reached on M-Th, 7:00 - 5:00. 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, Jerry O'Connor can be reached on (571) 272-6787.
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.
/MATTHEW H DIVELBISS/Examiner, Art Unit 3624
Prosecution Insights