DETAILED ACTION
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, Remarks filed on 03/23/2026, with respect to the rejection of independent claims 1, 8 and 15 under 35 USC § 103 has been fully considered and was persuasive. However, upon further search and read the Examiner is issuing a second non-final based on a newly found prior art, Martinez, US 2014/0137257, and thus the Applicant’s argument is moot.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1, 3, 6-8, 10, 13-15, 17 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over US-PGPUB No. 2022/0391793 A1 to Latimer et al. (hereinafter “Latimer”), US-PGPUB No. 2014/0137257 A1 to Martinez et al. (hereinafter “Martinez”), US-PGPUB No. 2020/0351295 A1 to Nhlabatsi et al. (hereinafter “Nhlabatsi”), and further in view of US-PGPUB No. 2022/0382713 A1 to Sadiq et al. (hereinafter “Sadiq”)
Regarding claim 1:
Latimer discloses:
A cybersecurity system (see Fig. 1, Risk Assessment System 100), comprising:
a memory (see Fig. 5, Memory 504);
a processor (see Fig. 5, Processor 502) coupled to the memory;
a cybersecurity software module (see Fig. 1, Risk Assessment Server 118, ¶62: “Fig. 5 is … a computing device 500, which can be used to implement the risk assessment server 118,”) executed by the processor, the cybersecurity software module configured to:
receive an indication to execute an integration run to perform a risk assessment (¶25: “… the risk assessment server 118 receives a request for evaluating a risk associated with an element or entity”), wherein the risk assessment evaluates a cybersecurity risk (¶28: “Based on the obtained information of the element or entity, an initial risk evaluation can be performed for the element or entity.”) associate with a (1) device operated or controlled by an organization that is a customer of the cybersecurity system or (2) software operated or controlled by the organization (¶28: “the risk assessment server 118 or another computing device can execute a cybersecurity tool to evaluate a website associated with the element or entity (e.g., a website describing the element or entity, a website hosted by the entity) and to generate a cybersecurity report.”);
However, Latimer does not explicitly teach the following limitations taught by Martinez:
determine a risk of interest (Martinez, ¶207: “determine the type of a) attacks that each of the applicable threat sources could use to attack the cyber vulnerabilities …”), of a plurality of different risk of interests (Martinez, ¶207: “A sample list of the type of attacks used by threat sources is provided in Table 18.”), based on one or more of (1) a selection, (2) organizational data that defines the organization (Martinez, ¶207: “Current threat vectors (type of attacks) can be determined based on the historical cyber-attack data 2604.”), (3) data that defines characteristics of the device or the software.
identify one or more cybersecurity controls, of one or more frameworks, that are related to the risk of interest (Martinez, ¶58: “Once the VARM is completed, there is the need to provide the recommended cyber security solutions and countermeasures so they can be reviewed and implemented by the customer.”);
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention, to modify the teachings of Latimer to incorporate the functionality of the method to determine the type attack that threat sources could use to attack cyber vulnerabilities, and provide recommended cyber security solutions and countermeasures so they can be reviewed and implemented by the customer, as disclosed by Martinez, such modification would provide quantitative processes for conducting cyber security risk assessments to identify and prioritize critical assets, cyber threats, and cyber vulnerabilities.
The combination of Latimer and Martinez does not explicitly teach the following limitations taught by Nhlabatsi:
define the risk of interest by defining one or more parameters for the one or more cybersecurity controls (Nhlabatsi, ¶77: “when considering Spoofing and Elevation of Privilege threats 132, 134, 136, 138, the optimal countermeasure (i.e., the countermeasure with the lowest risk on the graph) differed based on the number of hosts in the client networked system 102. … must consider the network configuration/topology in addition to the threat category of interest when determining an optimal countermeasure.”);
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention, to modify the teachings of the combination of Latimer and Martinez to incorporate the functionality of the method to determine and assign a threat impact weighting values for threats and identify a threat with the highest impact, as disclosed by Nhlabatsi, such modification would enable to implement a proactive, rather than reactive, security posture, allowing organizations to anticipate attacks, reduce risk, and minimize potential damage.
The combination of Latimer, Martinez and Nhlabatsi does not explicitly disclose the following limitation taught by Sadiq:
determine a level of compliance, of the device or the software, for each of the one or more cybersecurity controls utilizing the one or more parameters for the one or more cybersecurity controls (Sadiq, ¶410: “… the governance component can determine the extent or level of compliance of the set of data stores, and associated entity, with the set of rules and corresponding set of obligations, …”); and
generate a risk score for the device or the software utilizing the determined level of compliance for each of the one or more cybersecurity controls, wherein the risk score indicates a level of cybersecurity risk of the device or the software in relation to the risk of interest (Sadiq, ¶415: “At 4202, KRI metrics can be analyzed in relation to … a level of compliance with a set of rules and corresponding set of obligations. … At 4204, respective risk scores can be determined with regard to the respective KRI metrics based at least in part on the results of the analysis at reference numeral 4202.”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention, to modify the teachings of the combination of Latimer, Martinez and Nhlabatsi to incorporate the functionality of the governance component can perform a compliance assessment on the set of data stores to determine the extent or level of compliance of the set of data stores with the set of rules and correspondingly the set of obligations, as disclosed by Sadiq, such modification would provide proactive risk management, and strengthens defenses against evolving cyber threats.
Regarding claim 3:
The combination of Latimer, Martinez, Nhlabatsi and Sadiq discloses:
The cybersecurity system of claim 1, wherein the data that defines the characteristics of the device or the software includes one or more policies, one or more settings, or one or more configurations associated with the device or the software (Nhlabatsi, ¶36: “a VM that acts as a Web Server in a medical records management application could be assigned the highest weighting value 122, 124, 126, 128 for Denial-of-Service threats”, Note: the VM is configured as a web server).
The same motivation which is applied to claim 1 with respect to Nhlabatsi applies to claim 3.
Regarding claim 6:
The combination of Latimer, Martinez, Nhlabatsi and Sadiq discloses:
The cybersecurity system of claim 1, wherein the level of compliance indicates that the device or the software is either (1) compliant with a particular control, (2) non-compliant with the particular control, or (3) partially compliant with the particular control (Sadiq, ¶59: “The governance platform that can determine, and present to authorized users (e.g., via a user interface), information relating to key risk indicator (KRI) metrics, which can be or can comprise risk scores relating to levels of compliance (e.g., levels of adherence), non-compliance (e.g., non-adherence), or risks associated with non-compliance or potential non-compliance of the DLDP, … with regard to applicable laws, regulations, or agreements.”).
The same motivation which is applied to claim 1 with respect to Sadiq applies to claim 6.
Regarding claim 7:
The combination of Latimer, Martinez, Nhlabatsi and Sadiq discloses:
The cybersecurity system of claim 1, wherein the cybersecurity software module is, when the level of compliance indicates that the device or the software is either non-compliant or partially compliant with the particular control, further configured:
determine one or more remediations that when implemented (1) cause the device or the software to become compliant with the particular control (Sadiq, ¶59: “the governance platform (or rights management platform) can determine non-compliance issues associated with the set of platforms, or the data stores, and can remediate or facilitate remediating issues involving non-compliance.”), (2) cause the risk score to decrease, or (3) cause a cybersecurity of the device or the software to improve when compared to the device or the software without implementing the one or more remediations.
The same motivation which is applied to claim 1 with respect to Sadiq applies to claim 7.
Regarding claims 8, 10 and 13-14:
Claims 8, 10 and 13-14 recite substantially the same limitations as claims 1,3 and 6-7, respectively, in the form of a method implementing the corresponding functionality. Therefore, they are rejected by the same rationale.
Regarding claims 15, 17 and 20:
Claims 15, 17 and 20 recite substantially the same limitations as claims 1,3 and 6, respectively, in the form of a non-transitory computer-readable media for storing the corresponding instructions. Therefore, they are rejected by the same rationale.
Claims 2, 9 and 16 are rejected under 35 U.S.C. 103 as being unpatentable over Latimer, Martinez, Nhlabatsi, Sadiq, and further in view of US-PGPUB No. 2022/0232031 A1 to Bogren et al. (hereinafter “Bogren”)
Regarding claim 2:
The combination of Latimer, Martinez, Nhlabatsi and Sadiq discloses the cybersecurity system of claim 1, but does not explicitly teach the following limitation taught by Bogren:
wherein the organizational data indicates one or more of (1) a type of the organization (Bogren, ¶32: “Information in the report is used to identify common attack patterns ... The report also describes how often each of the attack vectors is involved in a data breach. For each type of attack, the DBIR maps out the threat actors, types of organizations targeted and the security controls that can best enable enterprises to prevent attacks that result in data breaches.”), (2) one or more sectors that the organization operates in, (3) a number of employees of the organization, (4) one or more locations where the organization operates.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the teachings of the combination of Latimer, Martinez, Nhlabatsi and Sadiq to incorporate the functionality of the method to obtain an annual Data Breach Investigation Reports (DBIRs) which combines data from public and private organizations, wherein the DBIR maps out the threat actors, types of organizations targeted and the security controls that can best enable enterprises to prevent attacks that result in data breaches, as disclosed by Bogren, such modification allows for tailored threat modeling, which optimizes resource allocation, ensures regulatory compliance, and enables proactive defense against industry-specific attacks like ransomware or data theft.
Regarding claim 9:
Claim 9 recites substantially the same limitation as claim 2, in the form of a method implementing the corresponding functionality. Therefore, it is rejected by the same rationale.
Regarding claim 16:
Claim 16 recites substantially the same limitations as claim 2 in the form of a non-transitory computer-readable media for storing the corresponding instructions. Therefore, it is rejected by the same rationale.
Claims 4-5, 11-12 and 18-19 are rejected under 35 U.S.C. 103 as being unpatentable over Latimer, Martinez, Nhlabatsi, Sadiq, and further in view of US-PGPUB No. 2018/0351987 A1 to Patel et al. (hereinafter “Patel”)
Regarding claim 4:
The combination of Latimer, Martinez, Nhlabatsi and Sadiq discloses the cybersecurity system of claim 1, but does not explicitly teach the following limitation taught by Patel:
wherein the cybersecurity software module is further configured to index into a static mapping data structure utilizing the data that defines the device or the software to identify the one or more cybersecurity controls (Patel, ¶131: “… use the … medical device type to index into the mitigative action data source 226 to identify a proper remediation/mitigation”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention, to modify the teachings of the combination of Latimer, Martinez, Nhlabatsi and Sadiq to incorporate the functionality of the workflow trigger to derive information based pulling a medical device from a medical device master catalog, using the medical device type to index into a medical device threat and vulnerability library to identify a known issue, then use the looked up issue and/or medical device type to index into the mitigative action data source to identify a proper remediation/mitigation, as disclosed by Patel, such modification ensures that security controls are appropriate for the specific device, and enables targeted, automated mitigation, minimizing attack surface.
Regarding claim 5:
The combination of Latimer, Martinez, Nhlabatsi and Sadiq discloses the cybersecurity system of claim 1, but does not explicitly teach the following limitation taught by Patel:
wherein the cybersecurity software module is further configured to index into a dynamic mapping data structure utilizing vulnerability scan data associated with the device or the software to identify the one or more cybersecurity controls (Patel, ¶131: “using the medical device type to index into the medical device threat and vulnerability library 224 to identify a known issue (e.g., threat, vulnerability, security issue, etc.), then use the looked up issue … to index into the mitigative action data source 226 to identify a proper remediation/mitigation”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention, to modify the teachings of the combination of Latimer, Martinez, Nhlabatsi and Sadiq to incorporate the functionality of the method to produce a calculated hash for each component and compare the calculated hash to a stored hash of each component, as disclosed by Patel, such modification would enable the system to verify the authenticity of each component.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention, to modify the teachings of the combination of Latimer, Martinez, Nhlabatsi and Sadiq to incorporate the functionality of the workflow trigger to derive information based pulling a medical device from a medical device master catalog, using the medical device type to index into a medical device threat and vulnerability library to identify a known issue, then use the looked up issue and/or medical device type to index into the mitigative action data source to identify a proper remediation/mitigation, as disclosed by Patel, such modification ensures that security controls are appropriate for the specific device, and enables targeted, automated mitigation, minimizing attack surface.
Regarding claims 11-12:
Claims 11-12 recite substantially the same limitations as claims 4-5, respectively, in the form of a method implementing the corresponding functionality. Therefore, they are rejected by the same rationale.
Regarding claims 18-19:
Claims 18-19 recite substantially the same limitations as claims 4-5, respectively, in the form of a non-transitory computer-readable media for storing the corresponding instructions. Therefore, they are rejected by the same rationale.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Belfiore, Jr. et al. (US 2018/0146004 A1)- disclosed methods and systems for cybersecurity assessment of an organization's technology infrastructure include identifying features of the technology infrastructure and automatically generating a threat profile relevant to both the technology infrastructure and the organization's business (and/or business objectives), where the threat profile includes potential threat actors and threat scenarios applicable to the technology infrastructure.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MATTHIAS HABTEGEORGIS whose telephone number is (571)272-1916. The examiner can normally be reached M-F 8am-5pm ET.
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, William R. Korzuch can be reached at (571)272-7589. 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.
/M.H./Examiner, Art Unit 2491
Prosecution Insights