DETAILED ACTION
Authorization for Internet Communications
The examiner encourages Applicant to submit an authorization to communicate with the examiner via the Internet by making the following statement (from MPEP 502.03):
“Recognizing that Internet communications are not secure, I hereby authorize the USPTO to communicate with the undersigned and practitioners in accordance with 37 CFR 1.33 and 37 CFR 1.34 concerning any subject matter of this application by video conferencing, instant messaging, or electronic mail. I understand that a copy of these communications will be made of record in the application file.”
Please note that the above statement can only be submitted via Central Fax (not Examiner's Fax), Regular postal mail, or EFS Web using PTO/SB/439.
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
The information disclosure statement (IDS) submitted on 08/25/2025 is being considered by the examiner.
Drawings
The drawings are objected to as failing to comply with 37 CFR 1.84(p)(4) because reference character “1375” has been used to designate both “Next Threat Scenario” and “Re-iterate TARA process” (see figure 13) and (See Specification; para 0415 – 0416).
Corrected drawing sheets in compliance with 37 CFR 1.121(d) are required in reply to the Office action to avoid abandonment of the application. Any amended replacement drawing sheet should include all of the figures appearing on the immediate prior version of the sheet, even if only one figure is being amended. Each drawing sheet submitted after the filing date of an application must be labeled in the top margin as either “Replacement Sheet” or “New Sheet” pursuant to 37 CFR 1.121(d). If the changes are not accepted by the examiner, the applicant will be notified and informed of any required corrective action in the next Office action. The objection to the drawings will not be held in abeyance.
Claim Objections
Claim 15 is objected to because of the following informalities:
Regarding claim 15; the limitation “the item” lacks proper antecedent basis.
Appropriate correction is required.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claim 9 is rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claim 9 recites “…in accordance with ISO 21434”. The recitation of “ISO 21434 standard” renders the claim indefinite because the scope of the claim cannot be determined with reasonable certainty by one of ordinary skill in the art. The ISO 21434 is not explicitly identified as to its version or publication date, and it is unclear whether the claim refers to the entire standard or only to selected portions thereof.
Furthermore, the specification does not clearly incorporate ISO 21434 by reference in accordance with 37 C.F.R. 1.57 or MPEP 608.01(p), nor does it describe with specificality the portions of standard that are relevant to the claimed invention. As such, one of ordinary skill in the art cannot determine the metes and bounds of the claimed subject matter without resorting to speculation as to which provisions or revisions of the ISO standard are intended.
For the purpose of the following rejection, the claim has been treated on its merit.
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 – 5, 8, 9 and 11 - 20 are rejected under 25 U.S.C. 101 because the claimed invention is directed to judicial exception (an abstract idea) without significantly more. The following is Examiner’s analysis of the claimed invention.
the claimed invention is directed to non-statutory subject matter because the claim(s) as a whole, considering all claim elements both individually and in combination, do not amount to significantly more than an abstract idea. For example, claim 12 is directed to an abstract idea because the above claim is directed to a human activity. More specifically, the "identifying a threat scenario implemented against an asset, wherein the asset is protected by a cybersecurity control; determining feasibility of success of the threat scenario being successfully implemented against the asset; and in response to determining the feasibility of success is above a threshold level, modifying, at least one of the asset, or the cybersecurity control, to reduce the feasibility of success of the threat scenario” which fall within the “Mental Processes” grouping as concepts performed in the human mind (including observation, evaluation, judgment, and opinion). Each of these steps is a mental process that can practically be performed in the human mind; therefore, the claimed limitations fall within the mental processes grouping, and the claims recite an abstract idea found by the courts to be an abstract idea (Bilski and Alice).
The additional element(s) or combination of elements in the claim(s) other than the abstract idea per se amount(s) to no more than the judicial exception because the additional elements i.e., “by a device comprising a processor”, “memory” and “threat analysis and risk assessment (TARA) tool (claim 1) is simply a generic recitation of a computer. The claims amount to no more than performing a human activity by using a computer. Taking the elements both individually and as a combination, the computer components in the claims perform purely generic computer functions. Thus, the claim as a whole does not amount to significantly more than the abstract idea itself. Accordingly, the above claims are ineligible.
Viewed as a whole, these additional claim element(s) do not provide meaningful limitation(s) to transform the abstract idea into a patent eligible application of the abstract idea such that the claim(s) amounts to significantly more than the abstract idea itself. Therefore, the claim(s) are rejected under 35 U.S.C. 101 as being directed to non-statutory subject matter.
Claims 1 and 17 are the system and product claims of the abstract method claim 12.
Claims 2 – 5, 8, 9, 13 – 16 and 18 - 20 do not include elements that amount to significantly more than the abstract idea because all of the elements in those claims merely adds pre/post extra-solution activity to the abstract idea.
Claims 6 – 7, and 10, include elements that amount to significantly more than the abstract idea
Claim Rejections - 35 USC § 102
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 (i.e., changing from AIA to pre-AIA ) 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 the appropriate paragraphs of 35 U.S.C. 102 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.
Claim(s) 1 - 20 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Klein et al., (US 2022/0150270 A1) (hereinafter “Klein”).
Klein discloses;
Regarding claim 1, a system [i.e., system (page 2, para 0009)], comprising:
a memory that stores computer executable components [i.e., the system includes a computer-readable storage medium (page 2, para 0009)]; and
a processor that executes the computer executable components stored in the memory [i.e., the system includes one or more processor executes the instructions stored in the medium (page 2, para 0008 - 0009)], wherein the computer executable components comprise:
a threat analysis and risk assessment (TARA) tool configured to:
generate a threat scenario [i.e., generates analytical attack graph (AAGs) (page 1, para 0005) i.e., each AAG representative of potential lateral movement within the connected vehicle ecosystem (page 2, para 0018), (page 6, para 0047), (see figure 3) i.e., an AAG can be used to understand how a network can be hacked (page 6, para 0045)] to be implemented [i.e., simulation (page 2, para 0018)] against an asset [i.e., the AAG include different node types to show how a set of component and system configurations result in unauthorized actions to specific targets (page 6, para 0047), (see figure 3) i.e., between components (page 2, para 0018) Note; the attack graph depicts scenarios of how an adversary can move laterally between components or to a specific targets], wherein the asset is protected by a cybersecurity control [i.e., at least one security control that had been previously implemented (page 8, para 0064)];
determine feasibility of success of the threat scenario being successfully implemented against the asset [i.e., determining a risk value based on the AAG, the risk value representing a relative risk that a particular impact can occur (emphasis added). An example risk value is discussed Process Risk Calculation based on hardness of Attack Paths (emphasis added) (page 8, para 0064), (see ref. 410 of figure 4) i.e., an AAG can be used to identify the most vulnerable component (emphasis added) (“threat scenario being successfully implemented”) within a network (page 6, para 0045 and 0048) i.e., checking a path exists (page 6, para 0051) Note; the risk score is based on hardness score i.e., a metric of “difficulty” if a scenario is harder for the attacker, then implicitly the feasibility of success is lower and vice versa]; and
in response to determining the feasibility of success is above a threshold level, modifying at least one of the asset [i.e., updating or patching a component (page 8, para 0064)], or the cybersecurity control [i.e., one or more security control (page 8, para 0064)], to reduce the feasibility of success of the threat scenario [i.e., in response to determining that the risk value exceeds a threshold risk value, one or more security control can be selectively adjusted within the connected vehicle ecosystem in an effort to mitigate risk (page 8, para 0064)].
Regarding claim 2, the system of claim 1, wherein the asset is a property of an item, and the item is one of a software application [i.e., software systems (components) (page 5, para 0038)], an electronic control unit (ECU) [i.e., the components include ECU (page 7, para 0054 and 0061)], or a network architecture [i.e., a computer network (page 6, para 0049) i.e., network layers (page 6, para 0045), (see figures 1 and 3)].
Regarding claim 3, the system of claim 2, wherein the item is located in a computer-system configured for implementation on a vehicle [i.e., directed to a connected vehicle ecosystem (page 2, para 0017 – 0018)].
Regarding claim 4, the system of claim 3, wherein the TARA tool is further configured to:
identify a threat path for the threat scenario [i.e., identify attack path (page 4, para 0033), (see figure 3) i.e., check whether there exists an attack path (page 6, para 0051)], wherein the threat path is directed at the network architecture [i.e., AAGs can be used in cyber-threat analysis to determine attach paths of external attackers and through a computer network (page 6, para 0049)]; and
modify the asset comprises modifying the network architecture to prevent the threat scenario from being implemented on the threat path [i.e., one or more security control can be selectively adjusted within the connected vehicle ecosystem in an effort to mitigate risk (page 8, para 0064)].
Regarding claim 5, the system of claim 4, wherein the threat path is one of a branch attack path [i.e., attack path (page 4, para 0033), (see figure 3), (page 6, para 0051) i.e., each AAG representative of potential lateral movement within the connected vehicle ecosystem (page 2, para 0018), (page 6, para 0047), (see figure 3) Note; it teaches attack path which means branch-like paths or routes through a network to an asset].
Regarding claim 6, the system of claim 2, wherein the TARA tool is further configured to:
identify a threat vector for the threat scenario, wherein the threat vector is directed at the ECU [i.e., the constructed AAG represents multiple attack path towards critical asset (page 6, para 0048) i.e., an AAG can be used to understand how a network can be hacked and undesirable consequences of the network being hacked (page 6, para 0049) Note; these paragraphs show that the system identifies concrete paths, each a specific vector, through which a attacker can reach target asset i.e., an infotainment system can cross a gateway and communicate with a break ECU (page 7, para 0054) Note; this is a specific attack vector between network segments within the vehicle architecture]; and
modifying the asset comprises modifying a configuration of the ECU to prevent the threat vector from successfully accessing the ECU [i.e., one or more security control can be selectively adjusted within the connected vehicle ecosystem in an effort to mitigate risk (page 8, para 0064)].
Regarding claim 7, the system of claim 2, wherein the TARA tool is further configured to:
identify a threat included in the threat scenario, wherein the threat is configured to modify operation of the software application [i.e., determining a risk value based on the AAG, the risk value representing a relative risk that a particular impact can occur (emphasis added). An example risk value is discussed Process Risk Calculation based on hardness of Attack Paths (emphasis added) (page 8, para 0064), (see ref. 410 of figure 4) i.e., an AAG can be used to identify the most vulnerable component (emphasis added) (“threat scenario being successfully implemented”) within a network (page 6, para 0045 and 0048) i.e., checking a path exists (page 6, para 0051)]; and
modifying the asset comprises modifying a configuration of the software application to prevent the threat from successfully modifying operation of the software application [i.e., updating or patching a component (page 8, para 0064)].
Regarding claim 8, the system of claim 1, wherein the system is a centralized TARA system, and the TARA tool is further configured to:
retrieve the asset from a product design database communicatively coupled to the centralized TARA system [i.e., a database object to store data regarding the component…a digital twin of an entity can be constructed using the structured representation of respective components from the database and can be used to execute simulation (page 5, para 0043)]; and
update the product design database with the modified asset [i.e., one or more security control can be selectively adjusted within the connected vehicle ecosystem in an effort to mitigate risk (page 8, para 0064) Note; late the system updates/remedies component configuration, logically the database must be updated].
Regarding claim 9, the system of claim 1, wherein the TARA tool is further configured to determine the feasibility of success of the threat scenario being successfully implemented against the asset in accordance with ISO 21434 [i.e., determining a risk value based on the AAG, the risk value representing a relative risk that a particular impact can occur (emphasis added). An example risk value is discussed Process Risk Calculation based on hardness of Attack Paths (emphasis added) (page 8, para 0064), (see ref. 410 of figure 4) i.e., an AAG can be used to identify the most vulnerable component (emphasis added) (“threat scenario being successfully implemented”) within a network (page 6, para 0045 and 0048) i.e., checking a path exists (page 6, para 0051) Note; the risk score is based on hardness score i.e., a metric of “difficulty” if a scenario is harder for the attacker, then implicitly the feasibility of success is lower and vice versa].
Regarding claim 10, the system of claim 1, wherein the TARA tool is further configured to:
configure an attack vector for inclusion in the threat scenario, wherein the attack vector is configured to be implemented at a logical layer of a computer system that includes the asset, wherein the logical layer pertains to a software application, or at a physical layer of a computer system that includes the asset, wherein the physical layer pertains to an electronic control unit or a network device included in the computer system [i.e., determining a risk value based on the AAG, the risk value representing a relative risk that a particular impact can occur (emphasis added). An example risk value is discussed Process Risk Calculation based on hardness of Attack Paths (emphasis added) (page 8, para 0064), (see ref. 410 of figure 4) i.e., an AAG can be used to identify the most vulnerable component (emphasis added) (“threat scenario being successfully implemented”) within a network (page 6, para 0045 and 0048) i.e., checking a path exists (page 6, para 0051)].
Regarding claim 11, the system of claim 1, wherein the system is a centralized TARA system, and the TARA tool is further configured to retrieve the threat scenario from a product design database communicatively coupled to the centralized TARA system [i.e., a database object to store data regarding the component…a digital twin of an entity can be constructed using the structured representation of respective components from the database and can be used to execute simulation (page 5, para 0043)].
Regarding claim 12, a computer-implemented method [i.e., method (page 2, para 0009)], comprising:
identifying, by a device comprising a processor [i.e., the system includes one or more processor (page 2, para 0009)], a threat scenario [i.e., generates at least one analytical attack graph (AAGs) (page 1, para 0005) i.e., each AAG representative of potential lateral movement within the connected vehicle ecosystem (page 2, para 0018), (page 6, para 0047), (see figure 3) i.e., an AAG can be used to understand how a network can be hacked (page 6, para 0045)] implemented [i.e., simulation (page 2, para 0018)] against an asset [i.e., the AAG include different node types to show how a set of component and system configurations result in unauthorized actions to specific targets (page 6, para 0047), (see figure 3) i.e., between components (page 2, para 0018) Note; the attack graph depicts scenarios of how an adversary can move laterally between components or to a specific targets], wherein the asset is protected by a cybersecurity control [i.e., at least one security control that had been previously implemented (page 8, para 0064)];
determine, by the device, feasibility of success of the threat scenario being successfully implemented against the asset [i.e., determining a risk value based on the AAG, the risk value representing a relative risk that a particular impact can occur (emphasis added). An example risk value is discussed Process Risk Calculation based on hardness of Attack Paths (emphasis added) (page 8, para 0064), (see ref. 410 of figure 4) i.e., an AAG can be used to identify the most vulnerable component (emphasis added) (“threat scenario being successfully implemented”) within a network (page 6, para 0045 and 0048) i.e., checking a path exists (page 6, para 0051) Note; the risk score is based on hardness score i.e., a metric of “difficulty” if a scenario is harder for the attacker, then implicitly the feasibility of success is lower and vice versa]; and
in response to determining the feasibility of success is above a threshold level, modifying, by the device, at least one of the asset [i.e., updating or patching a component (page 8, para 0064)], or the cybersecurity control [i.e., one or more security control (page 8, para 0064)], to reduce the feasibility of success of the threat scenario [i.e., in response to determining that the risk value exceeds a threshold risk value, one or more security control can be selectively adjusted within the connected vehicle ecosystem in an effort to mitigate risk (page 8, para 0064)].
Regarding claim 13, the computer-implemented method of claim 12, wherein the device is located in a threat analysis and risk assessment (TARA) system, the computer-implemented method further comprising:
retrieving, by the device, the threat scenario from a product design database communicatively coupled to the TARA system [i.e., a database object to store data regarding the component…a digital twin of an entity can be constructed using the structured representation of respective components from the database and can be used to execute simulation (page 5, para 0043)]; and
updating, by the device, the product design database with the modified asset [i.e., one or more security control can be selectively adjusted within the connected vehicle ecosystem in an effort to mitigate risk (page 8, para 0064) Note; late the system updates/remedies component configuration, logically the database must be updated].
Regarding claim 14, the computer-implemented method of claim 12, wherein the asset is a property of an item, and the item is included in a computer-system configured to be implemented on a software-defined vehicle [i.e., directed to a connected vehicle ecosystem (page 2, para 0017 – 0018)].
Regarding claim 15, the computer-implemented method of claim 12, wherein the item is one of a software application [i.e., software systems (components) (page 5, para 0038)], an electronic control unit (ECU) [i.e., the components include ECU (page 7, para 0054 and 0061)], or a network architecture [i.e., a computer network (page 6, para 0049) i.e., network layers (page 6, para 0045), (see figures 1 and 3)].
Regarding claim 16, the computer-implemented method of claim 12, wherein the threat scenario comprises at least one of:
a threat path, wherein the threat path is directed at network architecture that includes the asset [i.e., attack path (page 4, para 0033), (see figure 3), (page 6, para 0051) i.e., each AAG representative of potential lateral movement within the connected vehicle ecosystem (page 2, para 0018), (page 6, para 0047), (see figure 3) Note; it teaches attack path which means branch-like paths or routes through a network to an asset];
a threat vector, wherein the threat vector is directed at an electronic control unit that includes the asset [i.e., the constructed AAG represents multiple attack path towards critical asset (page 6, para 0048) i.e., an AAG can be used to understand how a network can be hacked and undesirable consequences of the network being hacked (page 6, para 0049) i.e., an infotainment system can cross a gateway and communicate with a break ECU (page 7, para 0054)]; or
a threat, wherein the threat is configured to modify operation of a software application that includes the asset [i.e., determining a risk value based on the AAG, the risk value representing a relative risk that a particular impact can occur (emphasis added). An example risk value is discussed Process Risk Calculation based on hardness of Attack Paths (emphasis added) (page 8, para 0064), (see ref. 410 of figure 4) i.e., an AAG can be used to identify the most vulnerable component (emphasis added) (“threat scenario being successfully implemented”) within a network (page 6, para 0045 and 0048) i.e., checking a path exists (page 6, para 0051)].
Regarding claim 17, a computer program product stored on a non-transitory computer-readable medium and comprising machine-executable instructions, wherein, in response to being executed, the machine-executable instructions cause computing equipment to perform operations [i.e., a computer readable storage medium coupled…perform operations in accordance with…(page 2, para 0008)], comprising:
identifying a threat scenario [i.e., generates at least one or more analytical attack graph (AAGs) (page 1, para 0005) i.e., each AAG representative of potential lateral movement within the connected vehicle ecosystem (page 2, para 0018), (page 6, para 0047), (see figure 3) i.e., an AAG can be used to understand how a network can be hacked (page 6, para 0045)] implemented [i.e., simulation (page 2, para 0018)] against an asset [i.e., the AAG include different node types to show how a set of component and system configurations result in unauthorized actions to specific targets (page 6, para 0047), (see figure 3) i.e., between components (page 2, para 0018) Note; the attack graph depicts scenarios of how an adversary can move laterally between components or to a specific targets], wherein the asset is protected by a cybersecurity control [i.e., at least one security control that had been previously implemented (page 8, para 0064)];
determine feasibility of success of the threat scenario being successfully implemented against the asset [i.e., determining a risk value based on the AAG, the risk value representing a relative risk that a particular impact can occur (emphasis added). An example risk value is discussed Process Risk Calculation based on hardness of Attack Paths (emphasis added) (page 8, para 0064), (see ref. 410 of figure 4) i.e., an AAG can be used to identify the most vulnerable component (emphasis added) (“threat scenario being successfully implemented”) within a network (page 6, para 0045 and 0048) i.e., checking a path exists (page 6, para 0051) Note; the risk score is based on hardness score i.e., a metric of “difficulty” if a scenario is harder for the attacker, then implicitly the feasibility of success is lower and vice versa]; and
in response to determining the feasibility of success is above a threshold level, modifying at least one of the asset [i.e., updating or patching a component (page 8, para 0064)], or the cybersecurity control [i.e., one or more security control (page 8, para 0064)], to reduce the feasibility of success of the threat scenario [i.e., in response to determining that the risk value exceeds a threshold risk value, one or more security control can be selectively adjusted within the connected vehicle ecosystem in an effort to mitigate risk (page 8, para 0064)].
Regarding claim 18, the computer program product according to claim 17, wherein the asset is a property of an item, and the item is included in a computer-system configured to be implemented on a software-defined vehicle [i.e., directed to a connected vehicle ecosystem (page 2, para 0017 – 0018)], and the item is one of a software application [i.e., software systems (components) (page 5, para 0038)], an electronic control unit (ECU) [i.e., the components include ECU (page 7, para 0054 and 0061)], or a network architecture [i.e., a computer network (page 6, para 0049) i.e., network layers (page 6, para 0045), (see figures 1 and 3)].
Regarding claim 19, the computer program product according to claim 17, wherein the non-transitory computer-readable medium is located in a centralized threat analysis and risk assessment (TARA) system communicatively coupled to a product design database, the operations further comprising:
retrieving the threat scenario from the product design database [i.e., a database object to store data regarding the component…a digital twin of an entity can be constructed using the structured representation of respective components from the database and can be used to execute simulation (page 5, para 0043)]; and
updating the product design database with the modified asset [i.e., one or more security control can be selectively adjusted within the connected vehicle ecosystem in an effort to mitigate risk (page 8, para 0064) Note; late the system updates/remedies component configuration, logically the database must be updated].
Regarding claim 20, the computer program product according to claim 17, wherein the threat scenario comprises at least one of:
a threat path, wherein the threat path is directed at network architecture that includes the asset [i.e., attack path (page 4, para 0033), (see figure 3), (page 6, para 0051) i.e., each AAG representative of potential lateral movement within the connected vehicle ecosystem (page 2, para 0018), (page 6, para 0047), (see figure 3) Note; it teaches attack path which means branch-like paths or routes through a network to an asset];
a threat vector, wherein the threat vector is directed at an electronic control unit that includes the asset [i.e., the constructed AAG represents multiple attack path towards critical asset (page 6, para 0048) i.e., an AAG can be used to understand how a network can be hacked and undesirable consequences of the network being hacked (page 6, para 0049) i.e., an infotainment system can cross a gateway and communicate with a break ECU (page 7, para 0054)]; or
a threat, wherein the threat is configured to modify operation of a software application that includes the asset [i.e., determining a risk value based on the AAG, the risk value representing a relative risk that a particular impact can occur (emphasis added). An example risk value is discussed Process Risk Calculation based on hardness of Attack Paths (emphasis added) (page 8, para 0064), (see ref. 410 of figure 4) i.e., an AAG can be used to identify the most vulnerable component (emphasis added) (“threat scenario being successfully implemented”) within a network (page 6, para 0045 and 0048) i.e., checking a path exists (page 6, para 0051)].
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Hover (US 2017/0048266 A1) discloses receiving an asset topology that identifies an entity's computer-related assets, how the computer-related assets are connected together via one or more networks controlled by the entity, and an identifier for each computer-related asset that is an external facing asset, wherein the asset topology identifies one or more first computer-related assets each of which is an external facing asset and one or more second computer-related assets each of which is not an external facing asset; receiving threat data that identifies vulnerabilities of computer-related assets; determining, using the identifiers for the computer-related assets that may be an entry point for an attack simulation, a first computer-related asset that is one of the first computer-related assets; identifying, using the threat data, one or more first vulnerabilities of the first computer-related asset; determining, using the asset topology and the threat data, a path from the first computer-related asset to a second computer-related asset that is one of the second computer-related assets; determining, using the threat data, one or more second vulnerabilities of the second computer-related asset; determining, using the one or more second vulnerabilities of the second computer-related asset, a probability that the second computer-related asset will be compromised by an adversary's device; determining, using the asset topology and the threat data, a change to the asset topology to reduce the probability that the second computer-related asset will be compromised by an adversary's device; and providing information about the change to the asset topology for presentation to a user or implementing the change to the asset topology.
Risoldi (US 2020/0167705 A1) discloses retrieving data corresponding to an asset, wherein the asset is a computing device or software application of an enterprise system; identifying a set of vulnerabilities of the asset; determining, for each identified vulnerability, a likelihood of a threat actor successfully exploiting the vulnerability; determining, based on the likelihoods, a risk score for the asset; and sending the risk score for display.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SYED A RONI whose telephone number is (571)270-7806. The examiner can normally be reached M-F 9:00-5:00 pm (EST).
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, Jeffrey L Nickerson can be reached at (469) 295-9235. 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.
/SYED A RONI/Primary Examiner, Art Unit 2432